Subject : [BUG] Loading parport_pc kills the keyboard if ACPI is enabled
Submitter : Ozan Çağlayan <email@example.com>
Date : 2009-06-04 9:12
References : http://marc.info/?l=linux-kernel&m=124410667532558&w=4
Notify-Also : ACPI Devel Maling List <firstname.lastname@example.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
> > Submitter : Ozan Çağlayan <email@example.com>
> > 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.
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?
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 220.127.116.11 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 18.104.22.168 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.