USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
finally had time to do some digging, and the regression is caused by:

    b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups

..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
makes the card work happily again.

I don't know enough about USB protocols to speculate on whether there
may be a better fix, but hopefully someone cleverer than me can get to
the bottom of the problem?

Cheers
David

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

David wrote:
> ..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
> makes the card work happily again.
>   
Make that 2.6.30-rc5 .. my brain is obviously fried from too much .NET
this week :-(

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Pekka Enberg]

On Sat, May 23, 2009 at 12:32 AM, David <david@unsolicited.net> wrote:
> I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
> finally had time to do some digging, and the regression is caused by:
>
>    b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups
>
> ..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
> makes the card work happily again.

[ Note: David meant 2.6.30-rc5 here. ]

Thanks for doing the bisect!

On Sat, May 23, 2009 at 12:32 AM, David <david@unsolicited.net> wrote:
> I don't know enough about USB protocols to speculate on whether there
> may be a better fix, but hopefully someone cleverer than me can get to
> the bottom of the problem?

Lets start with cc'ing the right people. :-)

                                Pekka

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Sat, 23 May 2009, Pekka Enberg wrote:

> On Sat, May 23, 2009 at 12:32 AM, David <david@unsolicited.net> wrote:
> > I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
> > finally had time to do some digging, and the regression is caused by:
> >
> >    b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups
> >
> > ..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
> > makes the card work happily again.
> 
> [ Note: David meant 2.6.30-rc5 here. ]
> 
> Thanks for doing the bisect!
> 
> On Sat, May 23, 2009 at 12:32 AM, David <david@unsolicited.net> wrote:
> > I don't know enough about USB protocols to speculate on whether there
> > may be a better fix, but hopefully someone cleverer than me can get to
> > the bottom of the problem?

It's hard to see how that patch could cause any problems, provided the
hardware is working correctly.  (There was a case where the hardware
was _not_ working as expected.)  Is any more information available
about this failure?

Alan Stern

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

Alan Stern wrote:
> On Sat, 23 May 2009, Pekka Enberg wrote:
>
>   
>> On Sat, May 23, 2009 at 12:32 AM, David <david@unsolicited.net> wrote:
>>     
>>> I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
>>> finally had time to do some digging, and the regression is caused by:
>>>
>>>    b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups
>>>
>>> ..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
>>> makes the card work happily again.
>>>       
>> [ Note: David meant 2.6.30-rc5 here. ]
>>
>> Thanks for doing the bisect!
>>
>> On Sat, May 23, 2009 at 12:32 AM, David <david@unsolicited.net> wrote:
>>     
>>> I don't know enough about USB protocols to speculate on whether there
>>> may be a better fix, but hopefully someone cleverer than me can get to
>>> the bottom of the problem?
>>>       
>
> It's hard to see how that patch could cause any problems, provided the
> hardware is working correctly.  (There was a case where the hardware
> was _not_ working as expected.)  Is any more information available
> about this failure?
>   
Here's all I have. The device is a USB connected Technotrend TT-Connect
S-2400. Support for this was added in kernel 2.6.26. When I came to
upgrade my media PC beyond .26 the dmesg showed the following:-

Media PC (32-bit - Nvidia chipset. kernel 2.6.27)

19:13:18 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 6
19:13:18 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:13:18 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in
cold state, will try to load a firmware
19:13:18 s kernel: firmware: requesting dvb-usb-tt-s2400-01.fw
19:13:18 s kernel: dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
19:13:18 s kernel: usb 1-3: USB disconnect, address 6
19:13:18 s kernel: dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
19:13:20 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 7
19:13:20 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:13:20 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in
warm state.
19:13:20 s kernel: dvb-usb: will pass the complete MPEG2 transport
stream to the software demuxer.
19:13:20 s kernel: DVB: registering new adapter (Technotrend TT-connect
S-2400)
19:13:20 s kernel: DVB: registering frontend 0 (Philips TDA10086 DVB-S)...
19:13:23 s kernel: dvb-usb: recv bulk message failed: -110
19:13:23 s kernel: ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
19:13:23 s kernel: dvb-usb: Technotrend TT-connect S-2400 successfully
initialized and connected.

The device times out. Reverting b963801164618e25fbdc0cd452ce49c3628b46c8
causes it to work again

19:09:53 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 5
19:09:53 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:09:58 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in
cold state, will try to load a firmware
19:09:58 s kernel: firmware: requesting dvb-usb-tt-s2400-01.fw
19:09:59 s kernel: dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
19:09:59 s kernel: usb 1-3: USB disconnect, address 5
19:09:59 s kernel: dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
19:09:59 s kernel: usbcore: registered new interface driver dvb_usb_ttusb2
19:10:00 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 6
19:10:00 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:10:01 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in
warm state.
19:10:01 s kernel: dvb-usb: will pass the complete MPEG2 transport
stream to the software demuxer.
19:10:01 s kernel: DVB: registering new adapter (Technotrend TT-connect
S-2400)
19:10:01 s kernel: DVB: registering frontend 3 (Philips TDA10086 DVB-S)...
19:10:01 s kernel: dvb-usb: Technotrend TT-connect S-2400 successfully
initialized and connected.

My PC (64 bit - ATI chipset, using 2.6.30-rc5)

[12044.364021] usb 4-10: new high speed USB device using ehci_hcd and
address 5
[12044.497561] usb 4-10: configuration #1 chosen from 1 choice
[12044.881621] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold
state, will try to load a firmware
[12044.881626] usb 4-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[12044.918854] dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
[12044.980719] usbcore: registered new interface driver dvb_usb_ttusb2
[12044.981478] usb 4-10: USB disconnect, address 5
[12044.985169] dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
[12046.744023] usb 4-10: new high speed USB device using ehci_hcd and
address 6
[12046.876980] usb 4-10: configuration #1 chosen from 1 choice
[12046.877673] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm
state.
[12046.878601] dvb-usb: will pass the complete MPEG2 transport stream to
the software demuxer.
[12046.878959] DVB: registering new adapter (Technotrend TT-connect S-2400)
[12046.886861] DVB: registering adapter 0 frontend 0 (Philips TDA10086
DVB-S)...
[12046.891434] LNBx2x attached on addr=8<3>dvb-usb: recv bulk message
failed: -110
[12048.888080] ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
[12048.888320] dvb-usb: Technotrend TT-connect S-2400 successfully
initialized and connected.

Reverting b963801164618e25fbdc0cd452ce49c3628b46c8 (manually, as there
are conflicting changes) causes it to work again. The wierd random
frontend number looks strange though.

[ 2406.492027] usb 2-10: new high speed USB device using ehci_hcd and
address 7
[ 2406.625622] usb 2-10: configuration #1 chosen from 1 choice
[ 2406.626328] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold
state, will try to load a firmware
[ 2406.626335] usb 2-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[ 2406.628650] dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
[ 2406.690868] usb 2-10: USB disconnect, address 7
[ 2406.693282] dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
[ 2408.453024] usb 2-10: new high speed USB device using ehci_hcd and
address 8
[ 2408.585983] usb 2-10: configuration #1 chosen from 1 choice
[ 2408.586652] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm
state.
[ 2408.587727] dvb-usb: will pass the complete MPEG2 transport stream to
the software demuxer.
[ 2408.588080] DVB: registering new adapter (Technotrend TT-connect S-2400)
[ 2408.591575] DVB: registering adapter 0 frontend 42056112 (Philips
TDA10086 DVB-S)...
[ 2408.595941] LNBx2x attached on addr=8<6>dvb-usb: Technotrend
TT-connect S-2400 successfully initialized and connected.

I'm happy to do any further diagnostics if it will help.

David

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

Again, hopefully with word wrap sorted out...

Media PC (32-bit - Nvidia chipset. kernel 2.6.27)

19:13:18 s kernel: usb 1-3: new high speed USB device using ehci_hcd and address 6
19:13:18 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:13:18 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware
19:13:18 s kernel: firmware: requesting dvb-usb-tt-s2400-01.fw
19:13:18 s kernel: dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw'
19:13:18 s kernel: usb 1-3: USB disconnect, address 6
19:13:18 s kernel: dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
19:13:20 s kernel: usb 1-3: new high speed USB device using ehci_hcd and address 7
19:13:20 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:13:20 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state.
19:13:20 s kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
19:13:20 s kernel: DVB: registering new adapter (Technotrend TT-connect S-2400)
19:13:20 s kernel: DVB: registering frontend 0 (Philips TDA10086 DVB-S)...
19:13:23 s kernel: dvb-usb: recv bulk message failed: -110
19:13:23 s kernel: ttusb2: there might have been an error during control message transfer. (rlen = 0, was 0)
19:13:23 s kernel: dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected.

The device times out. Reverting b963801164618e25fbdc0cd452ce49c3628b46c8
causes it to work again

19:09:53 s kernel: usb 1-3: new high speed USB device using ehci_hcd and address 5
19:09:53 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:09:58 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware
19:09:58 s kernel: firmware: requesting dvb-usb-tt-s2400-01.fw
19:09:59 s kernel: dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw'
19:09:59 s kernel: usb 1-3: USB disconnect, address 5
19:09:59 s kernel: dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
19:09:59 s kernel: usbcore: registered new interface driver dvb_usb_ttusb2
19:10:00 s kernel: usb 1-3: new high speed USB device using ehci_hcd and address 6
19:10:00 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:10:01 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state.
19:10:01 s kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
19:10:01 s kernel: DVB: registering new adapter (Technotrend TT-connect S-2400)
19:10:01 s kernel: DVB: registering frontend 3 (Philips TDA10086 DVB-S)...
19:10:01 s kernel: dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected.

My PC (64 bit - ATI chipset, using 2.6.30-rc5)

[12044.364021] usb 4-10: new high speed USB device using ehci_hcd and address 5
[12044.497561] usb 4-10: configuration #1 chosen from 1 choice
[12044.881621] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware
[12044.881626] usb 4-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[12044.918854] dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw'
[12044.980719] usbcore: registered new interface driver dvb_usb_ttusb2
[12044.981478] usb 4-10: USB disconnect, address 5
[12044.985169] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
[12046.744023] usb 4-10: new high speed USB device using ehci_hcd and address 6
[12046.876980] usb 4-10: configuration #1 chosen from 1 choice
[12046.877673] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state.
[12046.878601] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[12046.878959] DVB: registering new adapter (Technotrend TT-connect S-2400)
[12046.886861] DVB: registering adapter 0 frontend 0 (Philips TDA10086 DVB-S)...
[12046.891434] LNBx2x attached on addr=8<3>dvb-usb: recv bulk message failed: -110
[12048.888080] ttusb2: there might have been an error during control message transfer. (rlen = 0, was 0)
[12048.888320] dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected.

Reverting b963801164618e25fbdc0cd452ce49c3628b46c8 (manually, as there
are conflicting changes) causes it to work again. The wierd random
frontend number looks strange though.

[ 2406.492027] usb 2-10: new high speed USB device using ehci_hcd and address 7
[ 2406.625622] usb 2-10: configuration #1 chosen from 1 choice
[ 2406.626328] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware
[ 2406.626335] usb 2-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[ 2406.628650] dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw'
[ 2406.690868] usb 2-10: USB disconnect, address 7
[ 2406.693282] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
[ 2408.453024] usb 2-10: new high speed USB device using ehci_hcd and address 8
[ 2408.585983] usb 2-10: configuration #1 chosen from 1 choice
[ 2408.586652] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state.
[ 2408.587727] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 2408.588080] DVB: registering new adapter (Technotrend TT-connect S-2400)
[ 2408.591575] DVB: registering adapter 0 frontend 42056112 (Philips TDA10086 DVB-S)...
[ 2408.595941] LNBx2x attached on addr=8<6>dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected.

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Sat, 23 May 2009, David wrote:

> My PC (64 bit - ATI chipset, using 2.6.30-rc5)

Let's continue to work with 2.6.30-rc for testing purposes.

> [12044.364021] usb 4-10: new high speed USB device using ehci_hcd and address 5
> [12044.497561] usb 4-10: configuration #1 chosen from 1 choice
> [12044.881621] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware
> [12044.881626] usb 4-10: firmware: requesting dvb-usb-tt-s2400-01.fw
> [12044.918854] dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw'
> [12044.980719] usbcore: registered new interface driver dvb_usb_ttusb2
> [12044.981478] usb 4-10: USB disconnect, address 5
> [12044.985169] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
> [12046.744023] usb 4-10: new high speed USB device using ehci_hcd and address 6
> [12046.876980] usb 4-10: configuration #1 chosen from 1 choice
> [12046.877673] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state.
> [12046.878601] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
> [12046.878959] DVB: registering new adapter (Technotrend TT-connect S-2400)
> [12046.886861] DVB: registering adapter 0 frontend 0 (Philips TDA10086 DVB-S)...
> [12046.891434] LNBx2x attached on addr=8<3>dvb-usb: recv bulk message failed: -110
> [12048.888080] ttusb2: there might have been an error during control message transfer. (rlen = 0, was 0)
> [12048.888320] dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected.

Yes, there's an obvious problem.

> Reverting b963801164618e25fbdc0cd452ce49c3628b46c8 (manually, as there
> are conflicting changes) causes it to work again. The wierd random
> frontend number looks strange though.
> 
> [ 2406.492027] usb 2-10: new high speed USB device using ehci_hcd and address 7
> [ 2406.625622] usb 2-10: configuration #1 chosen from 1 choice
> [ 2406.626328] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware
> [ 2406.626335] usb 2-10: firmware: requesting dvb-usb-tt-s2400-01.fw
> [ 2406.628650] dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw'
> [ 2406.690868] usb 2-10: USB disconnect, address 7
> [ 2406.693282] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
> [ 2408.453024] usb 2-10: new high speed USB device using ehci_hcd and address 8
> [ 2408.585983] usb 2-10: configuration #1 chosen from 1 choice
> [ 2408.586652] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state.
> [ 2408.587727] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
> [ 2408.588080] DVB: registering new adapter (Technotrend TT-connect S-2400)
> [ 2408.591575] DVB: registering adapter 0 frontend 42056112 (Philips TDA10086 DVB-S)...
> [ 2408.595941] LNBx2x attached on addr=8<6>dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected.

I don't know what's going on with that frontend number.  In fact, I 
don't know anything about DVB in general... but I am familiar with 
EHCI.

It's not obvious what could be causing this, so let's start out easy.  
Try collecting two usbmon traces (instructions are in
Documentation/usb/usbmon.txt), showing what happens with and without
the reversion.  Maybe some difference will stick out.

Alan Stern

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

Alan Stern wrote:
> It's not obvious what could be causing this, so let's start out easy.  
> Try collecting two usbmon traces (instructions are in
> Documentation/usb/usbmon.txt), showing what happens with and without
> the reversion.  Maybe some difference will stick ou
>   
Traces attached. Took a while as my quad core hangs solid when 0u is
piped to a file (I had to compile on a laptop and take the logs there).

Cheers
David



[-- Attachment #2: good.log.bz2 --]
[-- Type: application/x-bzip, Size: 12622 bytes --]

[-- Attachment #3: bad.log.bz2 --]
[-- Type: application/x-bzip, Size: 12625 bytes --]

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[hermann pitton]

Hi,

Am Sonntag, den 24.05.2009, 01:15 +0100 schrieb David:
> Alan Stern wrote:
> > It's not obvious what could be causing this, so let's start out easy.  
> > Try collecting two usbmon traces (instructions are in
> > Documentation/usb/usbmon.txt), showing what happens with and without
> > the reversion.  Maybe some difference will stick ou
> >   
> Traces attached. Took a while as my quad core hangs solid when 0u is
> piped to a file (I had to compile on a laptop and take the logs there).
> 
> Cheers
> David
> 
> 

just a note, since you said it is some ATI chipset.

Is it the SB700?

We have lots of reports about disconnects, but then also claimed to be
fixed in between, and i don't know the current status ...

Cheers,
Hermann

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

hermann pitton wrote:
> Hi,
>
> Am Sonntag, den 24.05.2009, 01:15 +0100 schrieb David:
>   
>> Alan Stern wrote:
>>     
>>> It's not obvious what could be causing this, so let's start out easy.  
>>> Try collecting two usbmon traces (instructions are in
>>> Documentation/usb/usbmon.txt), showing what happens with and without
>>> the reversion.  Maybe some difference will stick ou
>>>   
>>>       
>> Traces attached. Took a while as my quad core hangs solid when 0u is
>> piped to a file (I had to compile on a laptop and take the logs there).
>>
>> Cheers
>> David
>>
>>
>>     
>
> just a note, since you said it is some ATI chipset.
>
> Is it the SB700?
>
> We have lots of reports about disconnects, but then also claimed to be
> fixed in between, and i don't know the current status ...
>   
The latest trace is from an Intel dual core (SL9400) laptop, so the
problem exists across Nvidia, ATI and Intel USB Hardware.

The ATI system with the quad core (AMD 790FX, Phenom)  hangs solid when
trying to use usbmon though (if that's what you are getting at)?

David

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Sun, 24 May 2009, David wrote:

> Traces attached. Took a while as my quad core hangs solid when 0u is
> piped to a file (I had to compile on a laptop and take the logs there).

Is the output file being written to a USB device?  Obviously that's not
a good thing to do; it's like running tcpdump over an ssh connection --
you end up dumping the packets containing the dump output!

But if not then this is a genuine bug and it should be reported
separately on the linux-usb mailing list.

Alan Stern

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

Alan Stern wrote:
> But if not then this is a genuine bug and it should be reported
> separately on the linux-usb mailing list.
>
>
>   

Stranger and stranger. I started usbmon on the quad core and (at the
console) cat /sys/kernel/debug/usbmon/0u worked fine for the keyboard
and mouse. I then plugged in the S-2400 and was greeted with this kernel
panic (jpg attached).

David


[-- Attachment #2: oops-09-05-24.jpg --]
[-- Type: image/jpeg, Size: 70736 bytes --]

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Sun, 24 May 2009, David wrote:

> Alan Stern wrote:
> > But if not then this is a genuine bug and it should be reported
> > separately on the linux-usb mailing list.
> >
> >
> >   
> 
> Stranger and stranger. I started usbmon on the quad core and (at the
> console) cat /sys/kernel/debug/usbmon/0u worked fine for the keyboard
> and mouse. I then plugged in the S-2400 and was greeted with this kernel
> panic (jpg attached).
> 
> David

Pete, you should look at this.  It appears to be a problem with the DMA
mapping in usbmon.  Probably the same sort of thing you were working on
about a week ago (trying to access device memory).

Alan Stern

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Pete Zaitcev]

On Sun, 24 May 2009 22:10:50 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> wrote:

> Pete, you should look at this.  It appears to be a problem with the DMA
> mapping in usbmon.  Probably the same sort of thing you were working on
> about a week ago (trying to access device memory).

Indeed it looks the same. Is this an AMD CPU?

I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
in arch/x86/Kconfig). Strange that it started happening now.

-- Pete

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

Pete Zaitcev wrote:
> On Sun, 24 May 2009 22:10:50 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> wrote:
>
>   
>> Pete, you should look at this.  It appears to be a problem with the DMA
>> mapping in usbmon.  Probably the same sort of thing you were working on
>> about a week ago (trying to access device memory).
>>     
>
> Indeed it looks the same. Is this an AMD CPU?
>   
yes, a Phenom.

> I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
> in arch/x86/Kconfig). Strange that it started happening now.
>   
That is enabled. I'll switch it off and give it another go.

David

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

David wrote:
>
>> I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
>> in arch/x86/Kconfig). Strange that it started happening now.
>>   
>>     
> That is enabled. I'll switch it off and give it another go.
>
>   
While CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, so I
guess there's nothing I can do to test?

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Pete Zaitcev]

On Mon, 25 May 2009 13:25:55 +0100, David <david@unsolicited.net> wrote:

> >> I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
> >> in arch/x86/Kconfig). Strange that it started happening now.
> >>     
> > That is enabled. I'll switch it off and give it another go.
> >   
> While CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, so I
> guess there's nothing I can do to test?

I suppose so. I misunderstood how this worked. I guessed that the
DMA API debugging was the culprit because its introduction coincided
with the recent onset of this oops.

Although usbmon does essentially illegal tricks to look at data
already mapped for DMA, the code used to work for a few releases.
Bisecting may help. I cannot be sure of it though, and it's
going to take a lot of reboots.

Unfortunately, although I have an Opteron, the issue does not
occur here, so I'm at a loss for the moment. But I'll have to
tackle it somehow. Not sure how though. Any suggestions are welcome.

-- Pete

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Mon, 25 May 2009, Pete Zaitcev wrote:

> On Mon, 25 May 2009 13:25:55 +0100, David <david@unsolicited.net> wrote:
> 
> > >> I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
> > >> in arch/x86/Kconfig). Strange that it started happening now.
> > >>     
> > > That is enabled. I'll switch it off and give it another go.
> > >   
> > While CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, so I
> > guess there's nothing I can do to test?
> 
> I suppose so. I misunderstood how this worked. I guessed that the
> DMA API debugging was the culprit because its introduction coincided
> with the recent onset of this oops.
> 
> Although usbmon does essentially illegal tricks to look at data
> already mapped for DMA, the code used to work for a few releases.
> Bisecting may help. I cannot be sure of it though, and it's
> going to take a lot of reboots.
> 
> Unfortunately, although I have an Opteron, the issue does not
> occur here, so I'm at a loss for the moment. But I'll have to
> tackle it somehow. Not sure how though. Any suggestions are welcome.

Try asking the people responsible for maintaining DMA support for help.  

And David is very good about testing new patches.

Alan Stern

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

Pete Zaitcev wrote:
> On Mon, 25 May 2009 13:25:55 +0100, David <david@unsolicited.net> wrote:
>
>   
> I suppose so. I misunderstood how this worked. I guessed that the
> DMA API debugging was the culprit because its introduction coincided
> with the recent onset of this oops.
>
> Although usbmon does essentially illegal tricks to look at data
> already mapped for DMA, the code used to work for a few releases.
> Bisecting may help. I cannot be sure of it though, and it's
> going to take a lot of reboots.
>
> Unfortunately, although I have an Opteron, the issue does not
> occur here, so I'm at a loss for the moment. But I'll have to
> tackle it somehow. Not sure how though. Any suggestions are welcome.
>
> -- Pete
>   

I've been doing a bit of random rebooting (I don't really have time to
do a full bisect), and can reproduce the usbmon panic on this machine
back to 2.6.24.. so it certainly hasn't appeared that recently.

Cheers
David

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Pete Zaitcev]

On Tue, 26 May 2009 19:42:00 +0100, David <david@unsolicited.net> wrote:

> I've been doing a bit of random rebooting (I don't really have time to
> do a full bisect), and can reproduce the usbmon panic on this machine
> back to 2.6.24.. so it certainly hasn't appeared that recently.

Actually that's good to know, thanks a lot.

I can always just stub out any attempt to peek into the IOMMU
on Opterons. This would bring us back into the days of 'D' returned
from everything, although maybe not so bad as we've cut out some
unnecessary usb_buffer use. At least, no more crashing.

-- Pete

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Sun, 24 May 2009, David wrote:

> Alan Stern wrote:
> > It's not obvious what could be causing this, so let's start out easy.  
> > Try collecting two usbmon traces (instructions are in
> > Documentation/usb/usbmon.txt), showing what happens with and without
> > the reversion.  Maybe some difference will stick ou
> >   
> Traces attached. Took a while as my quad core hangs solid when 0u is
> piped to a file (I had to compile on a laptop and take the logs there).

I see a suggestive pattern, though the exact mechanism still isn't 
clear.  The log shows:

	An URB for bulk endpoint 1-in (the only URB queued) completes.

	About 150 us later, the driver does Clear-Halt on that 
	endpoint.

	About 150 us after that, the driver submits another URB.
	Without the patch this URB completes normally and transfers
	64 bytes (i.e., only one packet).  With the patch, the URB 
	times out.

We can safely conclude that the endpoint toggle setting is getting out
of sync between the device and the host, as a result of the Clear-Halt.  
There is code in ehci-hcd to prevent this from happening; the question
is why doesn't it work now when it used to work before?

I'll think about it some more...

Alan Stern

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Sun, 24 May 2009, David wrote:

> Alan Stern wrote:
> > It's not obvious what could be causing this, so let's start out easy.  
> > Try collecting two usbmon traces (instructions are in
> > Documentation/usb/usbmon.txt), showing what happens with and without
> > the reversion.  Maybe some difference will stick ou
> >   
> Traces attached. Took a while as my quad core hangs solid when 0u is
> piped to a file (I had to compile on a laptop and take the logs there).

Okay, here's a patch for you to try.  It refreshes the toggle setting 
in a linked but otherwise idle QH when a new URB is queued.

Alan Stern


Index: usb-2.6/drivers/usb/host/ehci-q.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -88,7 +88,7 @@ static inline void
 qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
 {
 	/* writes to an active overlay are unsafe */
-	BUG_ON(qh->qh_state != QH_STATE_IDLE);
+	BUG_ON(qh->qh_state != QH_STATE_IDLE && !list_empty(&qh->qtd_list));
 
 	qh->hw_qtd_next = QTD_NEXT(ehci, qtd->qtd_dma);
 	qh->hw_alt_next = EHCI_LIST_END(ehci);
@@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
 		/* can't sleep here, we have ehci->lock... */
 		qh = qh_make (ehci, urb, GFP_ATOMIC);
 		*ptr = qh;
+	} else if (list_empty(&qh->qtd_list)) {
+		/* There might have been a Clear-Halt while the QH
+		 * was linked but empty.
+		 */
+		qh_refresh(ehci, qh);
 	}
+
 	if (likely (qh != NULL)) {
 		struct ehci_qtd	*qtd;
 

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

Alan Stern wrote:
> Okay, here's a patch for you to try.  It refreshes the toggle setting 
> in a linked but otherwise idle QH when a new URB is queued.
>
> Alan Stern
>
>
> Index: usb-2.6/drivers/usb/host/ehci-q.c
> ===================================================================
> --- usb-2.6.orig/drivers/usb/host/ehci-q.c
> +++ usb-2.6/drivers/usb/host/ehci-q.c
> @@ -88,7 +88,7 @@ static inline void
>  qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
>  {
>  	/* writes to an active overlay are unsafe */
> -	BUG_ON(qh->qh_state != QH_STATE_IDLE);
> +	BUG_ON(qh->qh_state != QH_STATE_IDLE && !list_empty(&qh->qtd_list));
>  
>  	qh->hw_qtd_next = QTD_NEXT(ehci, qtd->qtd_dma);
>  	qh->hw_alt_next = EHCI_LIST_END(ehci);
> @@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
>  		/* can't sleep here, we have ehci->lock... */
>  		qh = qh_make (ehci, urb, GFP_ATOMIC);
>  		*ptr = qh;
> +	} else if (list_empty(&qh->qtd_list)) {
> +		/* There might have been a Clear-Halt while the QH
> +		 * was linked but empty.
> +		 */
> +		qh_refresh(ehci, qh);
>  	}
> +
>  	if (likely (qh != NULL)) {
>  		struct ehci_qtd	*qtd;
>  
>
>   
No luck I'm afraid (although there now appear to be 2 timeouts, not
one). I'm going to follow up on the laptop and get a USB log.

[  118.017016] usb 1-10: new high speed USB device using ehci_hcd and
address 5
[  118.148589] usb 1-10: configuration #1 chosen from 1 choice
[  118.452964] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold
state, will try to load a firmware
[  118.452972] usb 1-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[  118.488474] dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
[  118.550946] usbcore: registered new interface driver dvb_usb_ttusb2
[  118.552553] usb 1-10: USB disconnect, address 5
[  118.561083] dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
[  120.313020] usb 1-10: new high speed USB device using ehci_hcd and
address 6
[  120.444942] usb 1-10: configuration #1 chosen from 1 choice
[  120.445886] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm
state.
[  120.446672] dvb-usb: will pass the complete MPEG2 transport stream to
the software demuxer.
[  120.447014] DVB: registering new adapter (Technotrend TT-connect S-2400)
[  120.455026] DVB: registering adapter 0 frontend 129197120 (Philips
TDA10086 DVB-S)...
[  120.458383] LNBx2x attached on addr=8<3>dvb-usb: recv bulk message
failed: -110
[  122.457126] ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
[  124.456109] dvb-usb: recv bulk message failed: -110
[  124.456117] ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
[  124.456122] dvb-usb: Technotrend TT-connect S-2400 successfully
initialized and connected.


David

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

David wrote:
> Alan Stern wrote:
>   
>> Okay, here's a patch for you to try.  It refreshes the toggle setting 
>> in a linked but otherwise idle QH when a new URB is queued.
>>
>> Alan Stern
>>
>>
>> Index: usb-2.6/drivers/usb/host/ehci-q.c
>> ===================================================================
>> --- usb-2.6.orig/drivers/usb/host/ehci-q.c
>> +++ usb-2.6/drivers/usb/host/ehci-q.c
>> @@ -88,7 +88,7 @@ static inline void
>>  qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
>>  {
>>  	/* writes to an active overlay are unsafe */
>> -	BUG_ON(qh->qh_state != QH_STATE_IDLE);
>> +	BUG_ON(qh->qh_state != QH_STATE_IDLE && !list_empty(&qh->qtd_list));
>>  
>>  	qh->hw_qtd_next = QTD_NEXT(ehci, qtd->qtd_dma);
>>  	qh->hw_alt_next = EHCI_LIST_END(ehci);
>> @@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
>>  		/* can't sleep here, we have ehci->lock... */
>>  		qh = qh_make (ehci, urb, GFP_ATOMIC);
>>  		*ptr = qh;
>> +	} else if (list_empty(&qh->qtd_list)) {
>> +		/* There might have been a Clear-Halt while the QH
>> +		 * was linked but empty.
>> +		 */
>> +		qh_refresh(ehci, qh);
>>  	}
>> +
>>  	if (likely (qh != NULL)) {
>>  		struct ehci_qtd	*qtd;
>>  
>>
>>   
>>     
> No luck I'm afraid (although there now appear to be 2 timeouts, not
> one). I'm going to follow up on the laptop and get a USB log.
>   
USB log post-patch attached. Thanks for all the effort so far!

David

[-- Attachment #2: postpatch.log.bz2 --]
[-- Type: application/x-bzip, Size: 12697 bytes --]

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Mon, 25 May 2009, David wrote:

> David wrote:
> > Alan Stern wrote:
> >   
> >> Okay, here's a patch for you to try.  It refreshes the toggle setting 
> >> in a linked but otherwise idle QH when a new URB is queued.
> >>
> >> Alan Stern
> >>
> >>
> >> Index: usb-2.6/drivers/usb/host/ehci-q.c
> >> ===================================================================
> >> --- usb-2.6.orig/drivers/usb/host/ehci-q.c
> >> +++ usb-2.6/drivers/usb/host/ehci-q.c
> >> @@ -88,7 +88,7 @@ static inline void
> >>  qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
> >>  {
> >>  	/* writes to an active overlay are unsafe */
> >> -	BUG_ON(qh->qh_state != QH_STATE_IDLE);
> >> +	BUG_ON(qh->qh_state != QH_STATE_IDLE && !list_empty(&qh->qtd_list));
> >>  
> >>  	qh->hw_qtd_next = QTD_NEXT(ehci, qtd->qtd_dma);
> >>  	qh->hw_alt_next = EHCI_LIST_END(ehci);
> >> @@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
> >>  		/* can't sleep here, we have ehci->lock... */
> >>  		qh = qh_make (ehci, urb, GFP_ATOMIC);
> >>  		*ptr = qh;
> >> +	} else if (list_empty(&qh->qtd_list)) {
> >> +		/* There might have been a Clear-Halt while the QH
> >> +		 * was linked but empty.
> >> +		 */
> >> +		qh_refresh(ehci, qh);
> >>  	}
> >> +
> >>  	if (likely (qh != NULL)) {
> >>  		struct ehci_qtd	*qtd;
> >>  
> >>
> >>   
> >>     
> > No luck I'm afraid (although there now appear to be 2 timeouts, not
> > one). I'm going to follow up on the laptop and get a USB log.
> >   
> USB log post-patch attached. Thanks for all the effort so far!

Yes, the log shows two timeouts.  Maybe I misunderstood something and 
the patch only made the situation worse!

We may have to try a debugging patch to find out what's really 
happening here.  I'll get back to you on that...

Alan Stern

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Mon, 25 May 2009, David wrote:

> > No luck I'm afraid (although there now appear to be 2 timeouts, not
> > one). I'm going to follow up on the laptop and get a USB log.
> >   
> USB log post-patch attached. Thanks for all the effort so far!

I think the idea of the patch was good, but the endpoint direction
information got lost (because the information was taken from the dummy
qTD which is always marked as OUT -- I don't see how this could ever
have worked properly).  So let's redo it, using the new and proper
interface for resetting endpoints.

To tell the truth, I'm not entirely certain this will work either.  The 
hardware may cache the endpoint state, so it may be necessary to unlink 
the endpoint completely.  Still, try this version and see what happens.

Alan Stern



Index: usb-2.6/drivers/usb/host/ehci-q.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -84,6 +84,30 @@ qtd_fill(struct ehci_hcd *ehci, struct e
 
 /*-------------------------------------------------------------------------*/
 
+static void ehci_endpoint_reset(struct usb_hcd *hcd,
+		struct usb_host_endpoint *ep)
+{
+	struct ehci_hcd		*ehci = hcd_to_ehci(hcd);
+	struct ehci_qh		*qh;
+
+	spin_lock_irq(&ehci->lock);
+	qh = ep->hcpriv;
+
+	/* For Bulk and Interrupt endpoints we maintain the toggle state
+	 * in the hardware; the toggle bits in udev aren't used at all.
+	 * When an endpoint is reset by usb_clear_halt() we must reset
+	 * the toggle bit in the QH.
+	 */
+	if (qh && (usb_endpoint_xfer_bulk(&ep->desc) ||
+			usb_endpoint_xfer_int(&ep->desc))) {
+		if (qh->qh_state == QH_STATE_IDLE || list_empty(&qh->qtd_list))
+			qh->hw_token &= ~cpu_to_hc32(ehci, QTD_TOGGLE);
+		else
+			WARN_ONCE(1, "clear_halt for an active endpoint\n");
+	}
+	spin_unlock_irq(&ehci->lock);
+}
+
 static inline void
 qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
 {
@@ -93,22 +117,6 @@ qh_update (struct ehci_hcd *ehci, struct
 	qh->hw_qtd_next = QTD_NEXT(ehci, qtd->qtd_dma);
 	qh->hw_alt_next = EHCI_LIST_END(ehci);
 
-	/* Except for control endpoints, we make hardware maintain data
-	 * toggle (like OHCI) ... here (re)initialize the toggle in the QH,
-	 * and set the pseudo-toggle in udev. Only usb_clear_halt() will
-	 * ever clear it.
-	 */
-	if (!(qh->hw_info1 & cpu_to_hc32(ehci, 1 << 14))) {
-		unsigned	is_out, epnum;
-
-		is_out = !(qtd->hw_token & cpu_to_hc32(ehci, 1 << 8));
-		epnum = (hc32_to_cpup(ehci, &qh->hw_info1) >> 8) & 0x0f;
-		if (unlikely (!usb_gettoggle (qh->dev, epnum, is_out))) {
-			qh->hw_token &= ~cpu_to_hc32(ehci, QTD_TOGGLE);
-			usb_settoggle (qh->dev, epnum, is_out, 1);
-		}
-	}
-
 	/* HC must see latest qtd and qh data before we clear ACTIVE+HALT */
 	wmb ();
 	qh->hw_token &= cpu_to_hc32(ehci, QTD_TOGGLE | QTD_STS_PING);
@@ -893,7 +901,6 @@ done:
 	qh->qh_state = QH_STATE_IDLE;
 	qh->hw_info1 = cpu_to_hc32(ehci, info1);
 	qh->hw_info2 = cpu_to_hc32(ehci, info2);
-	usb_settoggle (urb->dev, usb_pipeendpoint (urb->pipe), !is_input, 1);
 	qh_refresh (ehci, qh);
 	return qh;
 }
@@ -928,7 +935,7 @@ static void qh_link_async (struct ehci_h
 		}
 	}
 
-	/* clear halt and/or toggle; and maybe recover from silicon quirk */
+	/* clear halt and maybe recover from silicon quirk */
 	if (qh->qh_state == QH_STATE_IDLE)
 		qh_refresh (ehci, qh);
 
Index: usb-2.6/drivers/usb/host/ehci-pci.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-pci.c
+++ usb-2.6/drivers/usb/host/ehci-pci.c
@@ -388,6 +388,7 @@ static const struct hc_driver ehci_pci_h
 	.urb_enqueue =		ehci_urb_enqueue,
 	.urb_dequeue =		ehci_urb_dequeue,
 	.endpoint_disable =	ehci_endpoint_disable,
+	.endpoint_reset =	ehci_endpoint_reset,
 
 	/*
 	 * scheduling support

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

Alan Stern wrote:
> On Mon, 25 May 2009, David wrote:
>
>   
> I think the idea of the patch was good, but the endpoint direction
> information got lost (because the information was taken from the dummy
> qTD which is always marked as OUT -- I don't see how this could ever
> have worked properly).  So let's redo it, using the new and proper
> interface for resetting endpoints.
>
> To tell the truth, I'm not entirely certain this will work either.  The 
> hardware may cache the endpoint state, so it may be necessary to unlink 
> the endpoint completely.  Still, try this version and see what happens.
>
> Alan Stern
>
>
>   
Sorry for the delay, your patch reached me just after I turned in last
night.

It looks good to me. dmesg is how I'd expect, and I've attached the usb
trace which looks pretty similar to when the original patch was reverted.

I'll test some more with some other peripherals & check that they work ok.

Thanks a lot!
David

[-- Attachment #2: patch2.log.bz2 --]
[-- Type: application/x-bzip, Size: 12603 bytes --]

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[Alan Stern]

On Wed, 27 May 2009, David wrote:

> Sorry for the delay, your patch reached me just after I turned in last
> night.
> 
> It looks good to me. dmesg is how I'd expect, and I've attached the usb
> trace which looks pretty similar to when the original patch was reverted.
> 
> I'll test some more with some other peripherals & check that they work ok.
> 
> Thanks a lot!

I'm not done yet.  That patch seemed a bit unsafe, so I revised it.  
This version is a lot more careful about modifying data structures 
while they are still in use by the hardware.

If it works okay for you, I'll submit it.

Alan Stern


Index: usb-2.6/drivers/usb/host/ehci-q.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -93,22 +93,6 @@ qh_update (struct ehci_hcd *ehci, struct
 	qh->hw_qtd_next = QTD_NEXT(ehci, qtd->qtd_dma);
 	qh->hw_alt_next = EHCI_LIST_END(ehci);
 
-	/* Except for control endpoints, we make hardware maintain data
-	 * toggle (like OHCI) ... here (re)initialize the toggle in the QH,
-	 * and set the pseudo-toggle in udev. Only usb_clear_halt() will
-	 * ever clear it.
-	 */
-	if (!(qh->hw_info1 & cpu_to_hc32(ehci, 1 << 14))) {
-		unsigned	is_out, epnum;
-
-		is_out = !(qtd->hw_token & cpu_to_hc32(ehci, 1 << 8));
-		epnum = (hc32_to_cpup(ehci, &qh->hw_info1) >> 8) & 0x0f;
-		if (unlikely (!usb_gettoggle (qh->dev, epnum, is_out))) {
-			qh->hw_token &= ~cpu_to_hc32(ehci, QTD_TOGGLE);
-			usb_settoggle (qh->dev, epnum, is_out, 1);
-		}
-	}
-
 	/* HC must see latest qtd and qh data before we clear ACTIVE+HALT */
 	wmb ();
 	qh->hw_token &= cpu_to_hc32(ehci, QTD_TOGGLE | QTD_STS_PING);
@@ -893,7 +877,6 @@ done:
 	qh->qh_state = QH_STATE_IDLE;
 	qh->hw_info1 = cpu_to_hc32(ehci, info1);
 	qh->hw_info2 = cpu_to_hc32(ehci, info2);
-	usb_settoggle (urb->dev, usb_pipeendpoint (urb->pipe), !is_input, 1);
 	qh_refresh (ehci, qh);
 	return qh;
 }
@@ -928,7 +911,7 @@ static void qh_link_async (struct ehci_h
 		}
 	}
 
-	/* clear halt and/or toggle; and maybe recover from silicon quirk */
+	/* clear halt and maybe recover from silicon quirk */
 	if (qh->qh_state == QH_STATE_IDLE)
 		qh_refresh (ehci, qh);
 
Index: usb-2.6/drivers/usb/host/ehci-pci.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-pci.c
+++ usb-2.6/drivers/usb/host/ehci-pci.c
@@ -388,6 +388,7 @@ static const struct hc_driver ehci_pci_h
 	.urb_enqueue =		ehci_urb_enqueue,
 	.urb_dequeue =		ehci_urb_dequeue,
 	.endpoint_disable =	ehci_endpoint_disable,
+	.endpoint_reset =	ehci_endpoint_reset,
 
 	/*
 	 * scheduling support
Index: usb-2.6/drivers/usb/host/ehci-hcd.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-hcd.c
+++ usb-2.6/drivers/usb/host/ehci-hcd.c
@@ -1026,6 +1026,51 @@ done:
 	return;
 }
 
+static void
+ehci_endpoint_reset(struct usb_hcd *hcd, struct usb_host_endpoint *ep)
+{
+	struct ehci_hcd		*ehci = hcd_to_ehci(hcd);
+	struct ehci_qh		*qh;
+	int			eptype = usb_endpoint_type(&ep->desc);
+
+	if (eptype != USB_ENDPOINT_XFER_BULK && eptype != USB_ENDPOINT_XFER_INT)
+		return;
+
+ rescan:
+	spin_lock_irq(&ehci->lock);
+	qh = ep->hcpriv;
+
+	/* For Bulk and Interrupt endpoints we maintain the toggle state
+	 * in the hardware; the toggle bits in udev aren't used at all.
+	 * When an endpoint is reset by usb_clear_halt() we must reset
+	 * the toggle bit in the QH.
+	 */
+	if (qh) {
+		if (!list_empty(&qh->qtd_list)) {
+			WARN_ONCE(1, "clear_halt for a busy endpoint\n");
+		} else if (qh->qh_state == QH_STATE_IDLE) {
+			qh->hw_token &= ~cpu_to_hc32(ehci, QTD_TOGGLE);
+		} else {
+			/* It's not safe to write into the overlay area
+			 * while the QH is active.  Unlink it first and
+			 * wait for the unlink to complete.
+			 */
+			if (qh->qh_state == QH_STATE_LINKED) {
+				if (eptype == USB_ENDPOINT_XFER_BULK) {
+					unlink_async(ehci, qh);
+				} else {
+					intr_deschedule(ehci, qh);
+					(void) qh_schedule(ehci, qh);
+				}
+			}
+			spin_unlock_irq(&ehci->lock);
+			schedule_timeout_uninterruptible(1);
+			goto rescan;
+		}
+	}
+	spin_unlock_irq(&ehci->lock);
+}
+
 static int ehci_get_frame (struct usb_hcd *hcd)
 {
 	struct ehci_hcd		*ehci = hcd_to_ehci (hcd);

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

[David]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

Alan Stern wrote:
> On Wed, 27 May 2009, David wrote:
>
>   
>> Sorry for the delay, your patch reached me just after I turned in last
>> night.
>>
>> It looks good to me. dmesg is how I'd expect, and I've attached the usb
>> trace which looks pretty similar to when the original patch was reverted.
>>
>> I'll test some more with some other peripherals & check that they work ok.
>>
>> Thanks a lot!
>>     
>
> I'm not done yet.  That patch seemed a bit unsafe, so I revised it.  
> This version is a lot more careful about modifying data structures 
> while they are still in use by the hardware.
>
> If it works okay for you, I'll submit it.
>
>   
Still looks good to me.

Cheers
David

[-- Attachment #2: patch3.log.bz2 --]
[-- Type: application/x-bzip, Size: 12593 bytes --]