Date:	Wed, 7 Mar 2007 08:10:45 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>,
	Ash Milsted <thatistosayiseenem@...ab.com>
cc:	Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Jeff Chua <jeff.chua.linux@...il.com>, pavel@...e.cz,
	linux-pm@...ts.osdl.org, lenb@...nel.org,
	linux-acpi@...r.kernel.org,
	"Michael S. Tsirkin" <mst@...lanox.co.il>, luming.yu@...el.com,
	Arkadiusz Miskiewicz <arekm@...en.pl>,
	Konstantin Karasyov <konstantin.a.karasyov@...el.com>,
	Thomas Meyer <thomas.mey@....de>, Meelis Roos <mroos@...ux.ee>,
	Alexey Starikovskiy <alexey.y.starikovskiy@...ux.intel.com>,
	Janosch Machowinski <jmachowinski@....de>,
	vladimir.p.lebedev@...el.com, dmitry.torokhov@...il.com,
	linux-input@...ey.karlin.mff.cuni.cz
Subject: Re: [2/6] 2.6.21-rc2: known regressions



On Wed, 7 Mar 2007, Jeff Garzik wrote:
>
> Adrian Bunk wrote:
> > Subject    : AT keyboard only works with pci=noacpi
> > References : http://lkml.org/lkml/2007/3/3/68
> > Submitter  : Ash Milsted <thatistosayiseenem@...ab.com>
> > Status     : unknown
> 
> sounds like a BIOS bug, even though it appears to be a regression?

So?

BIOS bugs are not bugs we can fix, they are things we have to work around. 
They are like hardware bugs in a network chip: a "driver" that doesn't 
work around a BIOS bug is simply a *buggy* driver, exactly the same way a 
network driver has to work around errata in the hardware.

So it doesn't really matter if something is a BIOS bug or not. It's not 
reasonable to expect people to upgrade their BIOS'es - even if such an 
upgrade were to exist (which is fairly rare in itself). 

If it used to work, that just makes it (a) doubly important to try to fix 
it, since regressions are BAD BAD BAD and (b) a fair amount *easier* to 
fix, since we can hopefully get an idea of what broke it.

Ash, can you try to use "git bisect" to figure where it started? But 
perhaps just try -rc3 first to see if it's been fixed?

The working setups (whether with irqfixup or with pci=noacpi seem to both 
have a nice

	input: AT Translated Set 2 keyboard as /class/input/inputX

but the nonworking one does not. But even the nonworking one actually 
*found* the controller:

	PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
	PNP: PS/2 controller doesn't have AUX irq; using default 12
	serio: i8042 KBD port at 0x60,0x64 irq 1
	serio: i8042 AUX port at 0x60,0x64 irq 12
	mice: PS/2 mouse device common for all mice

which probably means that the "atkbd_probe()" function fails (probably 
because it never gets a reply, which in turn is probably because the 
interrupt routing is broken).

If you use "atkbd.reset=1" on the kernel command line, you would probably 
get a message like "keyboard reset failed"..

Now, the most likely cause is obviously just the ACPI changes that mess up 
irq routing somehow, but it would be important to figure out *what* makes 
it happen, which is why "git bisect" would be wonderful to try.

So Ash, if you get the git tree, just start with

	git bisect start
	git bisect good v2.6.20
	git bisect bad v2.6.21-rc1

and off you go.. git isn't really that hard to use any more.

		Linus
-
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