Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices - broke my serial console

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bjorn Helgaas wrote:
On Tuesday 24 July 2007 12:17:36 pm Maciej W. Rozycki wrote:
On Tue, 24 Jul 2007, Jeff Garzik wrote:

It seems clear from this report that we cannot, should not, trust BIOS for
something (a) so simple and (b) that has been working for over a decade.
And (c) something BIOS writers have never ever in their most unlikely imagination expected to be trusted for.

I don't think it's quite so clear-cut.  It is true that "poke at 0x3e8,
and if it responds, assume it's a 16550 with IRQ 4" is simple.  But it
doesn't always work.  Google for "irda setserial" and you'll find many
cases where the serial driver's blind probe erroneously claims an IRDA
device.  The SIR mode of IRDA devices is basically 16550-compatible,
so this wouldn't be a big problem, except that the blind probe often
assumes the wrong IRQ.  So users have to use setserial to fix up the
incorrect assumptions made by the blind probe.

We haven't debugged the problem on Sebastien's machine yet.  I suspect
we'll find that his serial port *is* described by ACPI, but that there's
some little difference in the way Linux discovers those devices compared
to how Windows does it.  If we figure out how to use ACPI more like
Windows does, I think we'll fix several little issues, including the one
on Sebastien's machine.

You have not fixed the double-probe problem either. That should have been fixed before 7e92b4fc34 was even considered for upstream.


We have a whole laundry list of minor issues because we either don't
listen to the BIOS at all, or we use it differently than Windows does.

Getting [back] to this thread, I know that most versions of Windows poke the serial port directly. It's pretty obvious when running Windows in an emulator.


Here are a few off the top of my head:

  - IRDA drivers have platform-specific code to "preconfigure" (discover
    and reprogram) bridges on the way to the IR device
  - Hardware sensor drivers conflict with ACPI embedded controller
    drivers, so every once in a while, they return bogus readings

Driver bug, completely unrelated to not "listen[ing] to the BIOS"


  - PCMCIA devices grab resources already in use by a PNP device,
    causing the PNP device to stop working

ditto


  - Linux enumerates CPUs with the MADT; I think Windows uses the ACPI
    namespace.  Sometimes there are multiple MADTs, and sometimes Linux
    uses the wrong one.

Color me skeptical. I think we would have bug reports if we were really getting this wrong a lot of the time.


If we keep papering over these problems by ignoring what ACPI is trying
to tell us, we're going to be adding machine-specific hacks forever.
Of course, there are ACPI bugs.  But Windows does rely on ACPI, and
Microsoft doesn't want to add those per-platform hacks any more than
we do.  So we might as well try to take advantage of the ACPI testing
they do.

You seem to be missing that ignoring BIOS is often a VERY GOOD thing, that has served us well many many times in the past.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux