Bug 13471
| Summary: | Loading parport_pc kills the keyboard if ACPI is enabled | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Rafael J. Wysocki (rjw) |
| Component: | Parallel | Assignee: | drivers_parallel |
| Status: | CLOSED OBSOLETE | ||
| Severity: | normal | CC: | acpi-bugzilla, alan, lenb, ozan, rui.zhang, yakui.zhao |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.30-rc1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 56331 | ||
| Attachments: | Output of acpidump | ||
|
Description
Rafael J. Wysocki
2009-06-07 11:49:05 UTC
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.
|