com1 incorrectly associated with ttyd1, com2 with ttyd0

Joe Rhett jrhett at svcolo.com
Thu Dec 15 22:42:27 PST 2005


> >On Thu, Dec 01, 2005 at 08:58:04PM +1100, Bruce Evans wrote:
> >>It's not clear that disabling in the BIOS should disable for all OSes.

> On Mon, 5 Dec 2005, Joe Rhett wrote:
> >What?  That's a fairly weird interpretation.  If I want to disable inside a
> >given OS, I do that inside the OS.  If I want to disable for _ALL_ OSes,
> >then I disable in the BIOS.  What reasonable logic can argue otherwise?

On Thu, Dec 08, 2005 at 03:13:00PM +1100, Bruce Evans wrote:
> The BIOS might not be layered under _all_ OSes, either due to its design
> or implementation, or OSes not understanding how to talk to the BIOS, or
> there being no way to talk BIOS.
 
eh?  What does this have to do with the situation at hand?  Here we can
talk to the BIOS, and the BIOS is clearly indicating that peripheral A has
1,2,3 and peripheral B has 4,5,6 and peripheral C has no resources .. why
are we ignoring this information?

I'm not being rude, I'm entirely joking, but it sounds like a technician
ignoring a customer complaint in her/his native language just because it
*might* have been given in a different language...

We see it.  It is clear.  Why are we ignoring it?

> >>Don't know.  I avoid ACPI if possible :-).  I suspect that FreeBSD can see
> >>ACPI tables but not all BIOS tables, so any soft disabling in the BIOS 
> >>gets lost.

> >Can you really use everything without ACPI?  What is lost by disabling 
> >ACPI?

> It's system-dependent.  ACPI is now essential for most portable
> computers.  I don't have one , and lose only faster interrupt handing
> via the APIC on workstations.

In any case, ACPI is also necessary to assign COM1 to port B, and COM2 to
port A, which is what started this conversation in the first place.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation


More information about the freebsd-hardware mailing list