linux-kernel - Re: Stable kernel 3.8.4/3.9-rc3 breaks PNP serial port

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] [day] [month] [year] [list]

Date:	Tue, 2 Apr 2013 23:11:48 +0100
From:	Sean Young <sean@...s.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Josh Boyer <jwboyer@...hat.com>, Jiri Slaby <jslaby@...e.cz>,
	tkil@...ye.com, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Vincent Deffontaines <vincent@...zor.com>
Subject: Re: Stable kernel 3.8.4/3.9-rc3 breaks PNP serial port

On Tue, Apr 02, 2013 at 05:34:35PM +0100, Sean Young wrote:
> On Tue, Apr 02, 2013 at 09:23:36AM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Apr 02, 2013 at 11:53:44AM -0400, Josh Boyer wrote:
> > > Hi All,
> > > 
> > > We've had a report [1] that the 3.8.4 stable kernel makes a PNP serial
> > > port stop working.  After testing 3.8.3, the reporter narrowed it down
> > > to stable commit eec98f82c637 (tty/8250_pnp: serial port detection
> > > regression since v3.7) (upstream commit 77e372a3d82).  Reverting that
> > > single commit from 3.8.5 allows the serial port to continue working.
> > > 
> > > The machine in question is using an AMI UEFI implementation as the
> > > firmware, and on 3.8.3 the serial port has the following in
> > > /sys/bus/pnp/devices/00:0a/resources
> > > 
> > > 	state = active
> > > 	io disabled
> > > 	irq 4
> > > 	dma disabled
> > > 
> > > With 3.8.[45], the same file has:
> > > 
> > > 	state = disabled
> > > 	io disabled
> > > 	irq 4
> > > 	dma disabled
> > > 
> > > In both cases, the io and dma resources are disabled, and an IRQ is
> > > assigned.  However, the state remains active for the port on 3.8.3.
> > > 
> > > The offending commit mentions this is a BIOS bug from InsydeH2O and that
> > > the port is bogus in that case, but we have something similar here with
> > > an AMI UEFI implementation (Version: 0406 Release Date: 06/06/2012)
> > > where the port isn't bogus.
> > > 
> > > I'm not sure exactly what the solution should be here.  Any thoughts?
> > 
> > Sean, should I just revert this patch now, and wait for a better fix
> > later?
> 
> Looks like although the pnp io is disabled, it does contain a valid port 
> number, else pnp detection would fail in 3.8.3. We're a little stricter
> in 3.8.4, but it should fall back to legacy port detection -- the port
> and irq are standard.

The device is disabled after pnp probe fails, so the legacy probe fails
as well. I can think of two options:

1) check if both io and irq are disabled, as they are on the bogus bios 
   for which the patch was written, but not on this board
2) try to detect the port at the pnp io/irq provided, enabled or not, and
   fail if no port can be found

I think the second is better but I'm not sure how much code needs to change
for that. I'll try over the next couple of evenings.


Sean
--
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/