On Fri, 10 Aug 2012, Tomas Sokorai wrote:
> I used a very stupid/simplistic logic I already had for debugging, to
> detect the condition: at the fourth (since its normally just one) pass
> over the SF interrupt clear without being it cleared, I assume it is
> stuck, and if ed_rm_list is the only o
On Thu, Aug 9, 2012 at 10:29 PM, Alan Stern wrote:
> In theory a similar quirk could be written to fix your problem. An
> easy way to test this, if you can automatically detect the "hung"
> condition, would be to set ohci->ed_to_check to the "unkillable" ed.
>
I used a very stupid/simplistic log
On Thu, 9 Aug 2012, Tomas Sokorai wrote:
> OK, more info gathered:
>
> The skip when "Highlander" ed is unkillable, is entered from the
> "skip_ed" label jump, not from the tick_before() check.
> ed->ed_next is indeed NULL at that point.
That's what I was afraid of. This means your OHCI contro
On Wed, Aug 8, 2012 at 11:45 AM, Alan Stern wrote:
> The only way for it not be executed is if the "skip_ed" case occurs.
> Therefore your next task is to determine what's going on. Does the
> tick_before() test succeed? Does we follow the "goto skip_ed"? Or is
> the list pointer messed up?
>
On Tue, 7 Aug 2012, Tomas Sokorai wrote:
> On Tue, Aug 7, 2012 at 3:42 PM, Alan Stern wrote:
> >
> > I don't have time today to look further into this, but I'll get back to
> > you later.
>
> No hurries, in fact I was gathering a bit more info about this behavior.
> I dumped the ed_rm_list when
On Tue, Aug 7, 2012 at 3:42 PM, Alan Stern wrote:
>
> I don't have time today to look further into this, but I'll get back to
> you later.
No hurries, in fact I was gathering a bit more info about this behavior.
I dumped the ed_rm_list when it is hung, and we have only one element
that's unkillab
On Mon, 6 Aug 2012, Tomas Sokorai wrote:
> Ding, Ding, Ding!, we have a winner :-)
> I did an ugly check:
>
> if (ohci->ed_rm_list)
> finish_unlinks (ohci, ohci_frame_no(ohci));
> if ((ints & OHCI_INTR_SF) != 0
> && !ohci->ed_rm_list
>
On Mon, Aug 6, 2012 at 12:24 PM, Alan Stern wrote:
> any lines in the dmesg log from boot-up about "enabled Compaq ZFMicro
> chipset quirks"?
BTW, I printk'ed the ohci->flags just to be sure what quirks were
enabled, and only the "do not trust power" was enabled.
> My guess is that ed_rm_list is
On Mon, Aug 6, 2012 at 12:24 PM, Alan Stern wrote:
> any lines in the dmesg log from boot-up about "enabled Compaq ZFMicro
> chipset quirks"?
Nope, no quirks message at all in the boot log.
>
> Are you comfortable writing your own debugging patches, or would you
Quite comfortable, I'll gather m
On Sun, 5 Aug 2012, Tomas Sokorai wrote:
> Here's after plugging in, but before the hang:
> -
> bus pci, device :00:04.0
> OHCI Host Controller
> ohci_hcd
> OHCI 1.0, NO legacy support registers, rh state running
> control 0x68f RWE RWC HCFS=
On Sun, Aug 5, 2012 at 5:36 PM, Alan Stern wrote:
> Build a kernel with CONFIG_USB_DEBUG enabled (and also
> CONFIG_DEBUG_FS). When the hang occurs, go into the subdirectory of
> /sys/kernel/debug/usb/ohci/ corresponding to the bus the device is
> plugged into (:00:04.0 if your setup hasn't c
On Sun, 5 Aug 2012, Tomas Sokorai wrote:
> Hi guys!
>
> I think I might have hit a bug:
>
> * Description of the issue *
> Continuous (variable time 1-10 mins) small bulk transfers (between 1-6
> bytes payload) either with libusb, or generic USB serial driver, leaves the
> app in uninterruptible
12 matches
Mail list logo
