Latest working kernel version: unknown Earliest failing kernel version: 2.6.24 Distribution: Debian testing/unstable Hardware Environment: LG LE50 Express laptop Software Environment: Debian i386, X.org 7.3, KDE 4 Problem Description: The keyboard stops working when I'm manipulating the Ethernet interface while in an X.org session. The session doesn't respond to keyboard input, although the magic SysReq key still works, and the mouse also works. The only way out is a reboot. The bug is triggered consistently when I bring down the eth0 interface with "ifdown eth0". (I normally use only wireless, so I didn't notice this before.) Steps to reproduce: Boot up, log in to KDE, bring up eth0, assign an address and send some traffic, then "ifdown eth0".
Created attachment 15436 [details] Output of lspci -v
Created attachment 15437 [details] Output of dmesg
~$ cat /proc/interrupts CPU0 0: 32835 local-APIC-edge-fasteoi timer 1: 10 IO-APIC-edge i8042 8: 2 IO-APIC-edge rtc 12: 138 IO-APIC-edge i8042 14: 28322 IO-APIC-edge ide0 15: 10618 IO-APIC-edge ide1 16: 334 IO-APIC-fasteoi HDA Intel 19: 19243 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 20: 20 IO-APIC-fasteoi firewire_ohci, yenta, tifm_7xx1, sdhc0:slot0, sdhc0:slot1, sdhc0:slot2 21: 1827 IO-APIC-fasteoi acpi 22: 19159 IO-APIC-fasteoi 0000:08:02.0 223: 2 PCI-MSI-edge eth0 NMI: 0 Non-maskable interrupts LOC: 1415833 Local timer interrupts TRM: 0 Thermal event interrupts SPU: 0 Spurious interrupts ERR: 0 MIS: 0
Created attachment 15438 [details] Kernel config for 2.6.24
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 25 Mar 2008 14:22:51 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10327 > > Summary: keyboard stops responding after "ifdown eth0" > Product: Drivers > Version: 2.5 > KernelVersion: 2.6.24, 2.6.25-rc6 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Network > AssignedTo: jgarzik@pobox.com > ReportedBy: marcus@better.se > > > Latest working kernel version: unknown > Earliest failing kernel version: 2.6.24 > Distribution: Debian testing/unstable > Hardware Environment: LG LE50 Express laptop > Software Environment: Debian i386, X.org 7.3, KDE 4 > Problem Description: > > The keyboard stops working when I'm manipulating the Ethernet interface while > in an X.org session. The session doesn't respond to keyboard input, although > the magic SysReq key still works, and the mouse also works. The only way out > is > a reboot. > > The bug is triggered consistently when I bring down the eth0 interface with > "ifdown eth0". (I normally use only wireless, so I didn't notice this > before.) > > Steps to reproduce: > > Boot up, log in to KDE, bring up eth0, assign an address and send some > traffic, > then "ifdown eth0". > (this is using sky2) > ~$ cat /proc/interrupts > CPU0 > 0: 32835 local-APIC-edge-fasteoi timer > 1: 10 IO-APIC-edge i8042 > 8: 2 IO-APIC-edge rtc > 12: 138 IO-APIC-edge i8042 > 14: 28322 IO-APIC-edge ide0 > 15: 10618 IO-APIC-edge ide1 > 16: 334 IO-APIC-fasteoi HDA Intel > 19: 19243 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, > ehci_hcd:usb3 > 20: 20 IO-APIC-fasteoi firewire_ohci, yenta, tifm_7xx1, > sdhc0:slot0, sdhc0:slot1, sdhc0:slot2 > 21: 1827 IO-APIC-fasteoi acpi > 22: 19159 IO-APIC-fasteoi 0000:08:02.0 > 223: 2 PCI-MSI-edge eth0 > NMI: 0 Non-maskable interrupts > LOC: 1415833 Local timer interrupts > TRM: 0 Thermal event interrupts > SPU: 0 Spurious interrupts > ERR: 0 > MIS: 0 So it's not an ill-advised disable_irq(). I guess the first question is: did the ifdown just kill the keyboard, or did more things die? Perhaps you could try ifdown eth0 ; sleep 5 ; ifup eth0 and see if the machine recovers? (I am just maxed out on bug reports at present - could someone please take this up and see if we can get it fixed?)
Andrew Morton wrote: > Perhaps you could try > > ifdown eth0 ; sleep 5 ; ifup eth0 Will try. There is also a Debian bug report of the same or a similar problem with kernels from 2.6.18: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415147
Reply-To: stefanr@s5r6.in-berlin.de One possible reason for unresponsive keyboard is a workqueue job in the shared workqueue sleeping very long or indefinitely. Sky2.c has only one workqueue job: sky2_restart().
Reply-To: akpm@linux-foundation.org On Wed, 26 Mar 2008 01:01:28 +0100 Stefan Richter <stefanr@s5r6.in-berlin.de> wrote: > One possible reason for unresponsive keyboard is a workqueue job in the > shared workqueue sleeping very long or indefinitely. > > Sky2.c has only one workqueue job: sky2_restart(). Yeah. Marcus, please try something like this: - become root - run ( sleep 10 ; echo t > /proc/sysrq-trigger ) & ifdown eth0 - wait a minute or so - reboot - See if the sysrq-t output made it to /var/log/messages If it did, please send it as reply-to-all to this email. Try to avoid wordwrapping it, as many do. Thanks.
Andrew Morton wrote: > Perhaps you could try > > ifdown eth0 ; sleep 5 ; ifup eth0 > > and see if the machine recovers? The keyboard locked up immediately, and the Konsole window where I typed the command also locked up and had to be killed forcibly. Marcus
Andrew Morton wrote: > ( sleep 10 ; echo t > /proc/sysrq-trigger ) & > ifdown eth0 > > > - See if the sysrq-t output made it to /var/log/messages No, not a word. It hung after printing this: ... DHCPRELEASE ... send_packet: Network is unreachable send_packet: please consult README ... sky2 eth0: disabling interface ~# sky2 eth0: enabling interface I'm running ifplugd, but this time there was no network cable connected. Also ran from virtual console this time, the keyboard locked up like before. SysRq keys work, so I could do sysrq-s, sysrq-b. Also pressed sysrq-t before rebooting. Any use trying netconsole? Can I run it over the wireless interface? Marcus
Reply-To: akpm@linux-foundation.org On Wed, 26 Mar 2008 10:19:40 +0100 Marcus Better <marcus@better.se> wrote: > Andrew Morton wrote: > > ( sleep 10 ; echo t > /proc/sysrq-trigger ) & > > ifdown eth0 > > > > > > - See if the sysrq-t output made it to /var/log/messages > > No, not a word. It hung after printing this: > > ... > DHCPRELEASE ... > send_packet: Network is unreachable > send_packet: please consult README ... > sky2 eth0: disabling interface > ~# sky2 eth0: enabling interface > > I'm running ifplugd, but this time there was no network cable connected. > Also ran from virtual console this time, the keyboard locked up like before. > > SysRq keys work, so I could do sysrq-s, sysrq-b. Also pressed sysrq-t > before rebooting. It certainy does sound like networking has gummed up the keventd queue(s). > Any use trying netconsole? Can I run it over the wireless interface? I don't think many (or any?) wireless drivers support netconsole. I'd suggest running (and perhaps suitably modifying) this: diff -puN drivers/net/sky2.c~a drivers/net/sky2.c --- a/drivers/net/sky2.c~a +++ a/drivers/net/sky2.c @@ -50,6 +50,8 @@ #include "sky2.h" +#define D() printk("%s:%d\n", __FILE__, __LINE__) + #define DRV_NAME "sky2" #define DRV_VERSION "1.21" #define PFX DRV_NAME " " @@ -2931,32 +2933,42 @@ static void sky2_restart(struct work_str struct net_device *dev; int i, err; + D(); rtnl_lock(); + D(); for (i = 0; i < hw->ports; i++) { + D(); dev = hw->dev[i]; if (netif_running(dev)) sky2_down(dev); } - + D(); napi_disable(&hw->napi); + D(); sky2_write32(hw, B0_IMSK, 0); sky2_reset(hw); sky2_write32(hw, B0_IMSK, Y2_IS_BASE); napi_enable(&hw->napi); - + D(); for (i = 0; i < hw->ports; i++) { + D(); dev = hw->dev[i]; if (netif_running(dev)) { + D(); err = sky2_up(dev); + D(); if (err) { + D(); printk(KERN_INFO PFX "%s: could not restart %d\n", dev->name, err); dev_close(dev); + D(); } } } - + D(); rtnl_unlock(); + D(); } static inline u8 sky2_wol_supported(const struct sky2_hw *hw) _ to see if things are getting stuck and if so, where.
Andrew Morton wrote: > I'd suggest running (and perhaps suitably modifying) this: This doesn't seem to help, it freezes without printing anything, and there is nothing in the logs either.
i have seen something like this when booting up a system without network cable attached, and i think i can remember that i also had X session with unresponsive keyboard after fiddling with the network (mouse still working). cannot tell anymore what distro/kernel this happened on..... >Also ran from virtual console this time, the keyboard locked up like before. so you mean the keyboard lockup also happens independend from X session, i.e. whithout X being startet and when working on textconsole ?
> >Also ran from virtual console this time, the keyboard locked up like > > before. > so you mean the keyboard lockup also happens independend from X session, > i.e. whithout X being startet and when working on textconsole ? Yes.
Does this still happen with 2.6.31?
(In reply to comment #15) > Does this still happen with 2.6.31? I have a different laptop now, so I cannot really check it.