Subject : [BUG] Loading parport_pc kills the keyboard if ACPI is enabled Submitter : Ozan Çağlayan <ozan@pardus.org.tr> Date : 2009-06-04 9:12 References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 Notify-Also : ACPI Devel Maling List <linux-acpi@vger.kernel.org> This entry is being used for tracking a regression from 2.6.29. Please don't close it until the problem is fixed in the mainline.
On Sunday 07 June 2009, Ozan Çağlayan wrote: > Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.29. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13471 > > Subject : Loading parport_pc kills the keyboard if ACPI is > enabled > > Submitter : Ozan Çağlayan <ozan@pardus.org.tr> > > Date : 2009-06-04 9:12 (4 days old) > > References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4 > > > > The problem is still around, no news.
Hi, Ozan Will you please use the git-bisect to identify the first bad commit which causes the regression? Will you please also attach the output of acpidump? Thanks.
Created attachment 21821 [details] Output of acpidump
Also note that the problem still exists if you manually probe the parport_pc module on a system booted with acpi=off. So the subject can be a little misleading in terms of that. From my original e-mail to LKML: "Note that the fact that the keyboard working when acpi=off seems to be that udev don't probe parport* stuff in that case. I inserted parport by hand and the keyboard is gone again as well: [ 30.696938] parport_pc 00:0d: reported by Plug and Play BIOS [ 30.697000] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] [ 30.780388] lp0: using parport0 (interrupt-driven). [ 30.804130] ppdev: user-space parallel port driver" If you look at the related lines in dmesg after a normal boot, without acpi=off, only the first line of the above snippet changes to: parport_pc 00:09: reported by Plug and Play ACPI I'll try to bisect it.
then this seems like an parallel port driver problem re-assign to parallel port category.
I tried with 2.6.30.1 but the problem still persists. I really don't have time to bisect it, but I can help with any other debugging outputs. I also started think that my board could somehow be faulty as no other people complains about a similar issue. Finally, it seems that the problem is available with 2.6.28, so the starting point is still fuzzy to me. I remember that the keyboard was working OK with 2.6.29_rc7 but now it's not. Maybe we should drop this report from the regression list.
Dropping from the list of post-2.6.29 regressions.
On Tuesday 04 August 2009, Ozan Çağlayan wrote: > Alan Cox wrote On 31-07-2009 18:17: > > There have been few changes to parport_pc but one thing recent changed > > the probe for SuperIO chips via low addresses and that could be > > interfering. > > > > commit e2434dc1c19412639dd047a4d4eff8ed0e5d0d50 > > Author: Jens Rottmann <JRottmann@LiPPERTEmbedded.de> > > Date: Mon Jun 22 16:51:49 2009 +0100 > > > > changed the behaviour slightly (hence asking about which release if it > > was a recent breakage). Its also a code area with very few changes so if > > you can find which one worked last, you should be able to transplant that > > parport_pc into 2.6.current and see if its parport or acpi triggered > > breakage. > > > > I've tested on 2.6.30.4 which has apparently this commit, no changes. > > I've booted into Ubuntu 8.10 which has 2.6.28. The keyboard was working > correctly eventhough parport_pc was loaded. I removed and re-probed and > the keyboard is gone. > > I've set BIOS settings to default, nope.