2.6.33: Xorg+khubd lockup (D-state) BUG / ioctl EVIOCGNAME failed: Inappropriate ioctl for device / PreInit returned NULL
in [Kernel]
|
Prev: isdn: Cleanup Sections in PCMCIA driver teles
Next: [Patch 1/1 v2] pata_via: HDD of VT6410/6415/6330 cannot be detected issue
From: Justin Piszcz on 29 Mar 2010 12:40 On Mon, 29 Mar 2010, Justin Piszcz wrote: > > > On Mon, 29 Mar 2010, Alan Stern wrote: > For your patch, what does this patch against? It does not apply cleanly > for 2.6.33. It also fails against 2.6.34-rc2, can you diff -u and show the patch so I can patch manually or include a patch against 2.6.33 or 2.6.34-rc2? Thanks. > >> >> Alan Stern >> >> >> Index: usb-2.6/drivers/usb/host/ohci-hcd.c >> =================================================================== >> --- usb-2.6.orig/drivers/usb/host/ohci-hcd.c >> +++ usb-2.6/drivers/usb/host/ohci-hcd.c >> @@ -290,6 +290,8 @@ static int ohci_urb_dequeue(struct usb_h >> */ >> urb_priv = urb->hcpriv; >> if (urb_priv) { >> + ohci_info(ohci, "start unlink urb %p, ed %p\n", >> + urb, urb_priv->ed); >> if (urb_priv->ed->state == ED_OPER) >> start_ed_unlink (ohci, urb_priv->ed); >> } >> @@ -324,6 +326,9 @@ ohci_endpoint_disable (struct usb_hcd *h >> >> if (!ed) >> return; >> + ohci_info(ohci, "disable ed %p (#%02x) state %d%s\n", >> + ed, ep->desc.bEndpointAddress, ed->state, >> + list_empty(&ed->td_list) ? "" : " (has tds)"); >> >> rescan: >> spin_lock_irqsave (&ohci->lock, flags); >> @@ -770,6 +775,10 @@ static irqreturn_t ohci_irq (struct usb_ >> return IRQ_HANDLED; >> } >> >> + ohci_info(ohci, "int %x enable %x rm_list %p\n", ints, >> + ohci_readl(ohci, ®s->intrenable), >> + ohci->ed_rm_list); >> + >> /* We only care about interrupts that are enabled */ >> ints &= ohci_readl(ohci, ®s->intrenable); >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 29 Mar 2010 13:00 On Mon, 29 Mar 2010, Justin Piszcz wrote: > bus pci, device 0000:00:0b.0 > OHCI Host Controller > ohci_hcd > OHCI 1.0, NO legacy support registers > control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3 > cmdstatus 0x00000 SOC=0 > intrstatus 0x00000020 FNO > intrenable 0x8000004e MIE RHSC RD SF WDH > ed_controlhead 7bef1b90 > hcca frame 0x4657 > fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf > fmremaining 0x80002b76 FRT FR=0x2b76 > periodicstart 0x2a2f > lsthresh 0x0628 > hub poll timer off > roothub.a 01000208 POTPGT=1 NPS NDP=8(8) > roothub.b 00000000 PPCM=0000 DR=0000 > roothub.status 00008000 DRWE > roothub.portstatus [0] 0x00000100 PPS > roothub.portstatus [1] 0x00000100 PPS > roothub.portstatus [2] 0x00000100 PPS > roothub.portstatus [3] 0x00000100 PPS > roothub.portstatus [4] 0x00000303 LSDA PPS PES CCS > roothub.portstatus [5] 0x00000303 LSDA PPS PES CCS > roothub.portstatus [6] 0x00000100 PPS > roothub.portstatus [7] 0x00000100 PPS I don't notice anything suspicious there. > > At the same time, just to be increase my level of certainty, you should > > apply the following debugging patch for ohci-hcd. Let's see both the > > usbmon trace and the dmesg log for the same event. The trace and the > > debugging patch will generate plenty of output during normal operation, > > but don't worry about that. Only the part starting from shortly before > > the mouse quits really matters. > Yes, I've done this before for a bug in the Intel USB controller (P55) on > another motherboard.. Should be doable, always funny though how it does not > happen when you are trying to make it happen. > > For your patch, what does this patch against? It does not apply cleanly > for 2.6.33. Yes it does. Maybe there's something wrong with the way your email client extracted the patch from the message. > It also fails against 2.6.34-rc2, can you diff -u and show the patch so > I can patch manually or include a patch against 2.6.33 or 2.6.34-rc2? That _was_ a "diff -u"-style patch. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Justin Piszcz on 29 Mar 2010 14:50 On Mon, 29 Mar 2010, Alan Stern wrote: > On Mon, 29 Mar 2010, Justin Piszcz wrote: > > Yes it does. Maybe there's something wrong with the way your email > client extracted the patch from the message. You're correct, sorry about that, when it recurs and I have the usbmon trace output I will send it along. > >> It also fails against 2.6.34-rc2, can you diff -u and show the patch so >> I can patch manually or include a patch against 2.6.33 or 2.6.34-rc2? > > That _was_ a "diff -u"-style patch. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Justin Piszcz on 30 Mar 2010 09:00 On Mon, 29 Mar 2010, Justin Piszcz wrote: > > > On Mon, 29 Mar 2010, Alan Stern wrote: > >> On Mon, 29 Mar 2010, Justin Piszcz wrote: >> >> Yes it does. Maybe there's something wrong with the way your email >> client extracted the patch from the message. > You're correct, sorry about that, when it recurs and I have the usbmon > trace output I will send it along. > >> >>> It also fails against 2.6.34-rc2, can you diff -u and show the patch so >>> I can patch manually or include a patch against 2.6.33 or 2.6.34-rc2? >> >> That _was_ a "diff -u"-style patch. >> >> Alan Stern >> > Hello! I have all the data you asked for: 1. # cat 0u > /tmp/0u.mon.out 2. The kernel log file. Also 3. # date; cat 0u > /tmp/0u_after_disconnect_usb.mon.out Tue Mar 30 08:50:45 EDT 2010 Here, I ran this, disconnected the mouse and re-connected it. All files are here: http://home.comcast.net/~jpiszcz/20100330/0u.mon.out.bz2 http://home.comcast.net/~jpiszcz/20100330/0u_after_disconnect_usb.mon.out.bz2 http://home.comcast.net/~jpiszcz/20100330/kern.log.bz2 Hopefully something can be found! It has happened again, in addition, this is a LONG outstanding bug since 2006 or 2007, see below research: URL: http://forums.linuxmint.com/viewtopic.php?f=55&t=44951&p=259375 DESCRIPTION: Screen Randomly Freezes Sometimes the screen just freezes and the cursor will not move, and nothing responds at all. The only way (I have found so far) is to hold down the power button until the whole laptop powers off. CHIPSET: 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476633 DESCRIPTION: Debian Bug report logs - #476633 linux-image-2.6.24-1-686: USB mouse hangs system CHIPSET: 00:0b.0 USB Controller [0c03]: nVidia Corporation MCP51 USB Controller [10de:026d] (rev a2) (prog-if 10 [OHCI]) URL: https://bugzilla.redhat.com/show_bug.cgi?id=215539 DESCRIPTION: https://bugzilla.redhat.com/show_bug.cgi?id=215539 CHIPSET: Bug 215539 - Unpredictable freeze of mouse and/or keyboard on amd64 x2 nvidia chipset (Dell E521) Aliases: Summary: Unpredictable freeze of mouse and/or keyboard on amd64 x2 nvidia chipset (Del... 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) A good post here: Luis Felipe Marzagao 2006-12-04 21:57:16 EST Hello. This bug is *serious* because it happens with all nforce 430 chipsets. The problem seems to be with that specifc chipset. This bug is a duplicate of: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201445 Here is a lot of info about this issue: http://forums.fedoraforum.org/showthread.php?t=136879&page=1&pp=15 https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/67734 http://forums.us.dell.com/supportforums/board/message?board.id=sw_other&message.id=54328&view=by_date_ascending&page=1 Justin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 30 Mar 2010 13:50
On Tue, 30 Mar 2010, Justin Piszcz wrote: > Hello! > > I have all the data you asked for: > > 1. # cat 0u > /tmp/0u.mon.out > 2. The kernel log file. I prefer to get dmesg output rather than log files. Logging programs sometimes drop or skip lines. But this was okay. Also, I'd like to see the contents of your /proc/interrupts. It looks like the OHCI controller shares an IRQ line with some other device. > Also 3. > # date; cat 0u > /tmp/0u_after_disconnect_usb.mon.out > Tue Mar 30 08:50:45 EDT 2010 > > Here, I ran this, disconnected the mouse and re-connected it. > > All files are here: > > http://home.comcast.net/~jpiszcz/20100330/0u.mon.out.bz2 > http://home.comcast.net/~jpiszcz/20100330/0u_after_disconnect_usb.mon.out.bz2 > http://home.comcast.net/~jpiszcz/20100330/kern.log.bz2 > > Hopefully something can be found! Well, I'm making progress. Below is a new debugging patch to try in place of the first one. This time the dmesg log alone will be sufficient, no need for a usbmon trace. And the output should be a lot smaller, since the new patch doesn't print something every time an interrupt occurs, but rather only when you unplug the mouse. In fact, you might try unplugging the mouse while it still works and then plugging it back in. The difference between the debugging messages while everything is working and the same thing after the mouse fails should be informative. (By the way, these tests are meant to find out why your Xorg and khubd processes hang when the mouse fails, not for finding the original cause behind the mouse failure. That can be addressed later.) > It has happened again, in addition, this is a LONG outstanding bug since > 2006 or 2007, see below research: .... Some of those reports indicate that a BIOS update could fix the problem. Have you checked your BIOS version? Alan Stern Index: usb-2.6/drivers/usb/host/ohci-hcd.c =================================================================== --- usb-2.6.orig/drivers/usb/host/ohci-hcd.c +++ usb-2.6/drivers/usb/host/ohci-hcd.c @@ -292,6 +292,8 @@ static int ohci_urb_dequeue(struct usb_h if (urb_priv) { if (urb_priv->ed->state == ED_OPER) start_ed_unlink (ohci, urb_priv->ed); + ohci_info(ohci, "start unlink urb %p, ed %p tick %u\n", + urb, urb_priv->ed, urb_priv->ed->tick); } } else { /* @@ -324,6 +326,9 @@ ohci_endpoint_disable (struct usb_hcd *h if (!ed) return; + ohci_info(ohci, "disable ed %p (#%02x) state %d%s\n", + ed, ep->desc.bEndpointAddress, ed->state, + list_empty(&ed->td_list) ? "" : " (has tds)"); rescan: spin_lock_irqsave (&ohci->lock, flags); Index: usb-2.6/drivers/usb/host/ohci-q.c =================================================================== --- usb-2.6.orig/drivers/usb/host/ohci-q.c +++ usb-2.6/drivers/usb/host/ohci-q.c @@ -912,6 +912,9 @@ rescan_all: * frame counter wraps and EDs with partially retired TDs */ if (likely (HC_IS_RUNNING(ohci_to_hcd(ohci)->state))) { + ohci_info(ohci, "finish_unlinks: tick %u, ed %p %u, %d\n", + tick, ed, ed->tick, + tick_before(tick, ed->tick)); if (tick_before (tick, ed->tick)) { skip_ed: last = &ed->ed_next; @@ -928,6 +931,8 @@ skip_ed: TD_MASK; /* INTR_WDH may need to clean up first */ + ohci_info(ohci, "dma %llx head %x\n", + (unsigned long long) td->td_dma, head); if (td->td_dma != head) { if (ed == ohci->ed_to_check) ohci->ed_to_check = NULL; @@ -990,6 +995,8 @@ rescan_this: /* HC may have partly processed this TD */ td_done (ohci, urb, td); urb_priv->td_cnt++; + ohci_info(ohci, "td_cnt %d length %d\n", + urb_priv->td_cnt, urb_priv->length); /* if URB is done, clean up */ if (urb_priv->td_cnt == urb_priv->length) { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |