On Thu, 26 Jun 2014, Dennis New wrote:
> > > I wonder if this unbind'ing and bind'ing should be done
> > > automatically, when a crash is detected?
> >
> > That's a separate discussion. To a large degree it doesn't matter,
> > because most hardware is designed not to crash during use.
> >
> > I
On Thu, 26 Jun 2014 10:57:19 -0400 (EDT), Alan Stern wrote:
> On Thu, 26 Jun 2014, Dennis New wrote:
> > [...]
> > echo :00:13.0 >/sys/bus/pci/drivers/ohci_pci/unbind
> >
> > [39522.284135] ohci-pci :00:13.0: remove, state 1
> > [39522.284152] usb usb2: USB disconnect, device number 1
On Thu, 26 Jun 2014, Dennis New wrote:
> > Here's a revised patch for you to try. This is meant to apply on top
> > of 3.15.
> >
> > As it turns out, when I tested this, it revealed a bug in the USB
> > audio driver. So I'm including a work-around for that bug at the
> > start of the patch.
>
On Tue, 24 Jun 2014 15:35:06 -0400 (EDT), Alan Stern wrote:
> On Fri, 20 Jun 2014, Dennis New wrote:
>
> > > However, lsusb does not work, and I cannot kill it -- it remains
> > > in D (uninterruptible sleep) state. I am also unable to rmmod the
> > > snd_usb_audio module -- rmmod gets stuck in D
On Fri, 20 Jun 2014, Dennis New wrote:
> > However, lsusb does not work, and I cannot kill it -- it remains in D
> > (uninterruptible sleep) state. I am also unable to rmmod the
> > snd_usb_audio module -- rmmod gets stuck in D state too.
> >
> > When I tried echoing (:00:13.0) to ohci_pci/un
On Fri, 20 Jun 2014, Dennis New wrote:
> > With the new patch, mplayer is able to close gracefully, with pcm
> > errors like "No such device". This time, my dmesg was slightly
> > different, with an "HcDoneHead" message:
> >
> > [139650.866080] ohci-pci :00:13.0: HcDoneHead not written back;
On Fri, 20 Jun 2014 17:33:14 -0400, Dennis New wrote:
> On Thu, 19 Jun 2014 17:44:39 -0400 (EDT), Alan Stern wrote:
> > On Thu, 19 Jun 2014, Dennis New wrote:
> >
> > > On Thu, 19 Jun 2014 17:03:55 -0400 (EDT), Alan Stern wrote:
> > > > On Tue, 17 Jun 2014, Dennis New wrote:
> > > >
> > > > > On
On Thu, 19 Jun 2014 17:44:39 -0400 (EDT), Alan Stern wrote:
> On Thu, 19 Jun 2014, Dennis New wrote:
>
> > On Thu, 19 Jun 2014 17:03:55 -0400 (EDT), Alan Stern wrote:
> > > On Tue, 17 Jun 2014, Dennis New wrote:
> > >
> > > > On Thu, 12 Jun 2014 10:20:54 -0400 (EDT), Alan Stern wrote:
> > > > > D
On Thu, 19 Jun 2014, Dennis New wrote:
> On Thu, 19 Jun 2014 17:03:55 -0400 (EDT), Alan Stern wrote:
> > On Tue, 17 Jun 2014, Dennis New wrote:
> >
> > > On Thu, 12 Jun 2014 10:20:54 -0400 (EDT), Alan Stern wrote:
> > > > Dennis and Matteo:
> > > >
> > > > I promised to send both of you a patch
On Thu, 19 Jun 2014 17:03:55 -0400 (EDT), Alan Stern wrote:
> On Tue, 17 Jun 2014, Dennis New wrote:
>
> > On Thu, 12 Jun 2014 10:20:54 -0400 (EDT), Alan Stern wrote:
> > > Dennis and Matteo:
> > >
> > > I promised to send both of you a patch changing the way ohci-hcd
> > > handles hardware bugs.
On Tue, 17 Jun 2014, Dennis New wrote:
> On Thu, 12 Jun 2014 10:20:54 -0400 (EDT), Alan Stern wrote:
> > Dennis and Matteo:
> >
> > I promised to send both of you a patch changing the way ohci-hcd
> > handles hardware bugs. Well, it's finally ready for testing. There's
> > only a limited amount
On Thu, 12 Jun 2014 10:20:54 -0400 (EDT), Alan Stern wrote:
> Dennis and Matteo:
>
> I promised to send both of you a patch changing the way ohci-hcd
> handles hardware bugs. Well, it's finally ready for testing. There's
> only a limited amount I can do on my own machine, so now it's up to
> you
On Sat, 26 Apr 2014, Dennis New wrote:
> On Fri, 25 Apr 2014 16:54:29 -0400 (EDT), Alan Stern wrote:
> > All right, here's a slightly different version of the patch. This one
> > should shut down the controller entirely when the problem occurs and
> > the frame pointer stops.
> >
> > After anoth
On Fri, 25 Apr 2014 16:54:29 -0400 (EDT), Alan Stern wrote:
> All right, here's a slightly different version of the patch. This one
> should shut down the controller entirely when the problem occurs and
> the frame pointer stops.
>
> After another week or so, I'll expect to see your next report..
On Thu, 24 Apr 2014, Dennis New wrote:
> So, it crashed again after almost a week. But ohci-pci seemed to have
> gotten in an infinite loop, constantly repeating about 30 times per
> second:
>
> [256283.572813] ohci-pci :00:13.1: OHCI SF watchdog triggered
> [256283.572819] ohci-pci :00:1
On Thu, 17 Apr 2014 15:36:02 -0400 (EDT), Alan Stern wrote:
> On Tue, 1 Apr 2014, Dennis New wrote:
>
> > On Tue, 1 Apr 2014 09:30:01 -0400 (EDT), Alan Stern wrote:
>
> > > I don't know that much can be done to prevent the controller from
> > > crashing, or to recover from such a crash. Maybe re
On Tue, 1 Apr 2014, Dennis New wrote:
> On Tue, 1 Apr 2014 09:30:01 -0400 (EDT), Alan Stern wrote:
> > I don't know that much can be done to prevent the controller from
> > crashing, or to recover from such a crash. Maybe resetting the
> > controller would work, maybe not.
> >
> > But at least
On Tue, 1 Apr 2014, Dennis New wrote:
> On Tue, 1 Apr 2014 22:38:39 -0400 (EDT), Alan Stern wrote:
> > On Tue, 1 Apr 2014, Dennis New wrote:
> > > > [...]
> > > > This indicates that the OHCI host controller just stopped
> > > > working. Then about a minute later, the audio device disconnected.
>
On Tue, 1 Apr 2014 22:38:39 -0400 (EDT), Alan Stern wrote:
> On Tue, 1 Apr 2014, Dennis New wrote:
> > > [...]
> > > This indicates that the OHCI host controller just stopped
> > > working. Then about a minute later, the audio device disconnected.
> >
> > Yep, that's what happened. I manually disc
On Tue, 1 Apr 2014, Dennis New wrote:
> On Tue, 1 Apr 2014 09:30:01 -0400 (EDT), Alan Stern wrote:
> > On Tue, 1 Apr 2014, Dennis New wrote:
> >
> > > I was able to capture usbmon output during the event (via a
> > > continuously rotating set of log files over a few days :p) from:
> > > /sys/ke
On Tue, 1 Apr 2014 09:30:01 -0400 (EDT), Alan Stern wrote:
> On Tue, 1 Apr 2014, Dennis New wrote:
>
> > I was able to capture usbmon output during the event (via a
> > continuously rotating set of log files over a few days :p) from:
> > /sys/kernel/debug/usb/usbmon/3u
>
> Were you using a kern
On Tue, 1 Apr 2014, Dennis New wrote:
> I was able to capture usbmon output during the event (via a
> continuously rotating set of log files over a few days :p) from:
> /sys/kernel/debug/usb/usbmon/3u
Were you using a kernel with the patch that I sent you? Did you have
CONFIG_USB_DEBUG enable
On Fri, 31 Jan 2014 21:30:03 -0500 (EST), Alan Stern wrote:
> On Thu, 30 Jan 2014, Dennis New wrote:
>
> > Indeed, "ohci_quirk_zfmicro" (as mentioned in that marc.info link)
> > would crash my kernel/system (I think when some graphics switch
> > would happen) :). So I tried "ohci_quirk_amd700",
Dennis, please use Reply-To-All so that your messages get sent to the
mailing list as well as to me.
On Wed, 26 Feb 2014, Dennis New wrote:
> Btw, I have noticed again that without the debugging patch, I get:
> 12:27:59 kernel: timeout: still 3 active urbs on EP #3
> 12:28:00 kernel: timeout:
On Wed, 26 Feb 2014, Dennis New wrote:
> > That's weird. Are you sure you were running the patched kernel?
> > There very definitely should have been a bunch of debugging output,
> > at the point where the headset was unplugged if not before.
> >
> > > Should I enable CONFIG_DEBUG_KERNEL as well
On Thu, 20 Feb 2014, Dennis New wrote:
> > Anyway, I finally got around to writing a diagnostic patch for you to
> > try. This should be applied with no other patches present. It
> > requires CONFIG_USB_DEBUG to be enabled, and it should add a fair
> > amount of debugging information to the d
On Fri, 14 Feb 2014, Dennis New wrote:
> > Hmmm. Looking again at the data you collected, it appears that those
> > quirks are not going to help. _Something_ has gone wrong, but it's
> > hard to tell what. At first I thought maybe the OHCI controller had
> > simply stopped generating interrupt
On Fri, 31 Jan 2014 21:30:03 -0500 (EST), Alan Stern wrote:
> On Thu, 30 Jan 2014, Dennis New wrote:
>
> > Indeed, "ohci_quirk_zfmicro" (as mentioned in that marc.info link)
> > would crash my kernel/system (I think when some graphics switch
> > would happen) :). So I tried "ohci_quirk_amd700", si
On Thu, 30 Jan 2014, Dennis New wrote:
> Indeed, "ohci_quirk_zfmicro" (as mentioned in that marc.info link)
> would crash my kernel/system (I think when some graphics switch would
> happen) :). So I tried "ohci_quirk_amd700", since there were already
> some PCI_VENDOR_ID_ATI quirks in ohci-pci.c t
On Thu, 23 Jan 2014 16:41:26 -0500 (EST), Alan Stern wrote:
> On Thu, 23 Jan 2014, Dennis New wrote:
>
> > On Wed, 15 Jan 2014 17:04:05 -0500 (EST), Alan Stern wrote:
> > > On Wed, 15 Jan 2014, Dennis New wrote:
> > >
> > > > When listening to my usb-bluetooth audio headset, the usb
> > > > sub
On Thu, 23 Jan 2014, Dennis New wrote:
> On Wed, 15 Jan 2014 17:04:05 -0500 (EST), Alan Stern wrote:
> > On Wed, 15 Jan 2014, Dennis New wrote:
> >
> > > When listening to my usb-bluetooth audio headset, the usb subsystem
> > > (I think) on my laptop crashes, the bluetooth/audio is lost, and my
>
On Wed, 15 Jan 2014 17:04:05 -0500 (EST), Alan Stern wrote:
> On Wed, 15 Jan 2014, Dennis New wrote:
>
> > When listening to my usb-bluetooth audio headset, the usb subsystem
> > (I think) on my laptop crashes, the bluetooth/audio is lost, and my
> > mplayer program is left in an "uninterruptibl
On Wed, 15 Jan 2014 17:04:05 -0500 (EST), Alan Stern wrote:
> On Wed, 15 Jan 2014, Dennis New wrote:
>
> > When listening to my usb-bluetooth audio headset, the usb subsystem
> > (I think) on my laptop crashes, the bluetooth/audio is lost, and my
> > mplayer program is left in an "uninterruptible
On Wed, 15 Jan 2014 17:04:05 -0500 (EST), Alan Stern wrote:
> On Wed, 15 Jan 2014, Dennis New wrote:
>
> > When listening to my usb-bluetooth audio headset, the usb subsystem
> > (I think) on my laptop crashes, the bluetooth/audio is lost, and my
> > mplayer program is left in an "uninterruptible
On Wed, 15 Jan 2014, Dennis New wrote:
> When listening to my usb-bluetooth audio headset, the usb subsystem (I
> think) on my laptop crashes, the bluetooth/audio is lost, and my
> mplayer program is left in an "uninterruptible sleep" (D) state and
> cannot be killed. The only way to get my usb-au
When listening to my usb-bluetooth audio headset, the usb subsystem (I
think) on my laptop crashes, the bluetooth/audio is lost, and my
mplayer program is left in an "uninterruptible sleep" (D) state and
cannot be killed. The only way to get my usb-audio working again is to
reboot.
Interestingly,
36 matches
Mail list logo
