[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#576918: marked as done (linux-image-2.6-686: Keyboard disabled: atkbd.c: Spurious ACK on isa0060/serio0 ...)

Your message dated Fri, 10 Feb 2012 13:16:55 -0600
with message-id <20120210191655.GF19216@burratino>
and subject line Re: Keyboard disabled: atkbd.c: Spurious ACK on isa0060/serio0 ...
has caused the Debian Bug report #576918,
regarding linux-image-2.6-686: Keyboard disabled: atkbd.c: Spurious ACK on isa0060/serio0 ...
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
576918: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576918
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-2.6-686
Version: 2.6.32+25
Severity: important

With Linux 2.6.32-trunk-686 & Linux 2.6.32-3-686, at least, on this Aspire One
Netbook, the system frequently boots into a state in which the keyboard does
not respond. The mouse (Synaptics touchpad) is still active, and as far as I can
tell everything else is working. My only recourse is to hit the reset button.

So this is nondeterministic, and so probably some sort of race? I *think* that 
it happens more frequently if I happen to touch the ps/2 touchpad during boot, but
it definitely does still happen when I keep my hands well away during boot.

Looking at /var/log/messages, this seem to be correlated with the
following message:
Apr  6 09:58:56 elf kernel: [    4.789882]
   atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
    hardware directly.

So far as I can tell, this sort of message only appears when the kb is disabled.
Presumably, this interrupt is not really spurious, thus not serviced
and the kb controller waits forever for the keystoke to be handled?? Just guessing :-(

Googling showed lots of rather confused discussion of this sort of message
from 3 years and more ago, but nothing that seemed relevant. Except maybe there is
some unrecognised race lurking in there somewhere?

Boot parameters for this netbook are
 elevator=noop enable_mtrr_cleanup.
And the netbook has a Super Talent SSD which is a bit faster & larger than the 
one supplied by Acer.

The problem seems to happen more frequently with Linux 2.6.32-trunk-686
than with Linux 2.6.32-3-686. I have not collected any statistics, but my guess is
something like 40% and 30% off boots, respectively. So pretty intrusive.

# lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
03:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
04:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller
04:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller
04:00.3 System peripheral: JMicron Technology Corp. MS Host Controller
04:00.4 System peripheral: JMicron Technology Corp. xD Host Controller

I guess it would be useful to have a copy of /var/log/messages as well, but as it is 
large I will wait until I have a response in case this is something trivial/silly.


# less /proc/interrupts (necessarily when kb is working):-
            CPU0       CPU1       
   0:     241204          0   IO-APIC-edge      timer
   1:       9740          0   IO-APIC-edge      i8042
   8:          1          0   IO-APIC-edge      rtc0
   9:        116          0   IO-APIC-fasteoi   acpi
  12:     323716          0   IO-APIC-edge      i8042
  14:          0          0   IO-APIC-edge      ata_piix
  15:       6307          0   IO-APIC-edge      ata_piix
  16:       3004          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2, i915, HDA Intel
  17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
  18:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4, ath
  19:      32840          0   IO-APIC-fasteoi   mmc0, uhci_hcd:usb5, jmb38x_ms:slot0
  24:          0          0   PCI-MSI-edge      pciehp
  25:          0          0   PCI-MSI-edge      pciehp
  26:          0          0   PCI-MSI-edge      pciehp
  27:          0          0   PCI-MSI-edge      pciehp
  28:       2570          0   PCI-MSI-edge      eth0
 NMI:          0          0   Non-maskable interrupts
 LOC:      30559     165279   Local timer interrupts
 SPU:          0          0   Spurious interrupts
 PMI:          0          0   Performance monitoring interrupts
 PND:          0          0   Performance pending work
 RES:      15169      29541   Rescheduling interrupts
 CAL:         13         57   Function call interrupts
 TLB:        155        213   TLB shootdowns
 TRM:          0          0   Thermal event interrupts
 THR:          0          0   Threshold APIC interrupts
 MCE:          0          0   Machine check exceptions
 MCP:         10         10   Machine check polls
 ERR:          1
 MIS:          0

ael

------------------------------------------------------------------------------
- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-2.6-686 depends on:
ii  linux-image-2.6.32-3-686      2.6.32-9   Linux 2.6.32 for modern PCs

linux-image-2.6-686 recommends no packages.

linux-image-2.6-686 suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 3.1.8-2
tags 576918 - moreinfo
quit

ael wrote:

> Well, it really is a long time. I am running testing so I have been
> through many kernels since this report. With recent kernels - I am
> running 3.1.0-1-686-pae today - this no longer happens.

Thanks.  I was going to suggest trying a recent squeeze kernel to make
sure this is fixed there, too, but:

> *However*, there is still some nondeterministic misbehaviour with
> the driver. 
>
> 1) On maybe 10% of boots, the right button is not recognised.
[...]
>                                                        Rebooting seems
> to be the only recourse.
[...]
> 2) In X, the VerticalEdgeScroll & HorizEdgeScroll sometimes do not
>   work. That is cured by "rmmod psmouse; modprobe psmouse".

These seem unrelated to the keyboard trouble and more interesting. ;-)
Please file a separate report for them (one report is enough, since
the two symptoms re the mouse might be related, as you mentioned).

[...]
> If you have any suggestions for how to diagnose the problem, let me
> know.
> I  will try to collect a dmesg.diff for boots with working and failing
> right button recognition, but IIRC I tried that sort of thing 
> earlier and could see no useful information.

It is not so much the difference as the plain logs that are useful.
They make it possible to test guesses about what happened during the
boot process.

Hope that helps,
Jonathan

--- End Message ---
Reply to: