lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 24 Jul 2007 13:49:55 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Sébastien Dugué <sebastien.dugue@...l.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to
 platform devices - broke my serial console

Bjorn Helgaas wrote:
> On Tuesday 24 July 2007 08:28:05 am Sébastien Dugué wrote:
>>  your commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26 broke the serial console
>> on my box. Adding 'legacy_serial.force=1' to my boot param as a workaround
>> solves the issue, but this may be hiding bugs in Linux PnP support or
>> in my firmware.
> 
> Thanks for your report.  We need to figure out why the 8250_pnp driver
> didn't find your serial console device.  Can you confirm that you also
> have CONFIG_ACPI and CONFIG_PNPACPI in your .config?
> 
> If you have those, and it still doesn't work, can you collect the DSDT
> dump, the output of "grep . /sys/bus/pnp/devices/*/*", and the dmesg
> from your "legacy_serial.force=1" boot?  Then we can tell which port
> the blind probe finds and whether it's described somewhere by ACPI.

hrm...

     x86, serial: convert legacy COM ports to platform devices

     Make x86 COM ports into platform devices and don't probe for them
     if we have PNP.

This seems like it will break decades-long-working stuff, in favor of 
breaking new ground in our favorite area, "trusting the BIOS."

It's just not worth it for serial ports, IMO.  Serial ports are 
something that just shouldn't break at this late stage in the game.  My 
new Intel platform boxes don't even have serial ports, so I question the 
value of messing with serial port probing even more... because... just 
wait a year, and your box won't have a serial port either!  :)

I certainly don't object to the use of platform devices (or isa_driver), 
but the probe change seems questionable.  That's sorta analagous to 
rewriting the floppy driver probe routine.  Sure you could do it... but 
why risk all that damage and go through debugging all over again?

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.

	Jeff


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ