2.4.30 - USB serial problem

2.4.30 - USB serial problem

[Ian Leonard]

Greetings,

We recently upgraded from 2.4.24 to 2.4.28 and the problem described 
below appeared. I have tested it on 2.4.30 and the fault still exists.

It is something to do with usb serial. We are actually using the 
ftdi_sio module but a quick diff suggests it hasn't changed much. I am 
not 100% sure what is going on but we are sending out various short 
commands (11 bytes) to an external device. Most work just fine but one 
using one sequence seems to cause the driver to loop and continually 
send out the same command. The application keeps sending other commands 
but eventually the write () blocks and that's that.

Examining the packet that caused the problem showed it was very similar 
to the others but it contained 0x0a. This obviously stuck out as being a 
candidate for some sort of translation problem.

I also built a 2.4.28 kernel with the ftdi_sio and usbserial code from 
the 2.4.24 release. It also failed. This was a surprise and I am 
wondering of I did it correctly.


I don't have the failing equipment with me here but will return to site 
next week. I would appreciate any words of wisdom on the problem.


-- 
Ian Leonard

Please ignore spelling and punctuation - I did.

RE: 2.4.30 - USB serial problem

[Stuart MacDonald]

From: linux-kernel-owner@vger.kernel.org 
> We recently upgraded from 2.4.24 to 2.4.28 and the problem described 
> below appeared. I have tested it on 2.4.30 and the fault still exists.
[snip]
> Examining the packet that caused the problem showed it was 
> very similar 
> to the others but it contained 0x0a. This obviously stuck out 
> as being a 
> candidate for some sort of translation problem.

That's a software flow control character, have you turned off software
flow control?

..Stu

Re: 2.4.30 - USB serial problem

[Pete Zaitcev]

On Thu, 26 May 2005 18:52:10 +0100, Ian Leonard <ian@smallworld.cx> wrote:

> We recently upgraded from 2.4.24 to 2.4.28 and the problem described 
> below appeared. I have tested it on 2.4.30 and the fault still exists.
>[...]
> Examining the packet that caused the problem showed it was very similar 
> to the others but it contained 0x0a. This obviously stuck out as being a 
> candidate for some sort of translation problem.

The above looks almost too obvious but for this:

> I also built a 2.4.28 kernel with the ftdi_sio and usbserial code from 
> the 2.4.24 release. It also failed. This was a surprise and I am 
> wondering of I did it correctly.

Did you nail down a scenario which we can debug? Frankly it's not credible
that transplanted usbserial and ftsi_sio would fail to work. I know that
I changed quite a bit between 2.4.24 and 2.4.28, but your experiment
undoes that.

-- Pete

Re: 2.4.30 - USB serial problem

[Ian Leonard]

Pete Zaitcev wrote:
> On Thu, 26 May 2005 18:52:10 +0100, Ian Leonard <ian@smallworld.cx> wrote:
> 
> 
>>We recently upgraded from 2.4.24 to 2.4.28 and the problem described 
>>below appeared. I have tested it on 2.4.30 and the fault still exists.
>>[...]
>>Examining the packet that caused the problem showed it was very similar 
>>to the others but it contained 0x0a. This obviously stuck out as being a 
>>candidate for some sort of translation problem.
> 
> 
> The above looks almost too obvious but for this:
> 
> 
>>I also built a 2.4.28 kernel with the ftdi_sio and usbserial code from 
>>the 2.4.24 release. It also failed. This was a surprise and I am 
>>wondering of I did it correctly.
> 
> 
> Did you nail down a scenario which we can debug? Frankly it's not credible

Not as yet. As I indicated I can only test the problem at a remote site 
and I don't get much time to look at it.

> that transplanted usbserial and ftsi_sio would fail to work. I know that

I agree, it can't be the case. To prove that I hadn't just made a 
mistake, I transplanted the whole usb branch and it still failed. This 
really points to the user app - which is complex and I haven't got to 
the bottom of it. It's a multi-threaded library and I see it's doing 
some sort of packet requeuing based on a timer. I can't see what has 
changed but I am guessing it's a kernel timing issue. It would explain 
everything.

> I changed quite a bit between 2.4.24 and 2.4.28, but your experiment
> undoes that.

I think the usb is red herring - sorry about that. BTW, I see you have 
cc'd Ian (hi Ian). By coincidence we are using an MEV usb device.


-- 
Ian Leonard

Please ignore spelling and punctuation - I did.

Re: 2.4.30 - USB serial problem

[Ian Leonard]

Ian Leonard wrote:
> Pete Zaitcev wrote:
> 
>> On Thu, 26 May 2005 18:52:10 +0100, Ian Leonard <ian@smallworld.cx> 
>> wrote:
>>
>>
>>> We recently upgraded from 2.4.24 to 2.4.28 and the problem described 
>>> below appeared. I have tested it on 2.4.30 and the fault still exists.
>>> [...]
>>> Examining the packet that caused the problem showed it was very 
>>> similar to the others but it contained 0x0a. This obviously stuck out 
>>> as being a candidate for some sort of translation problem.
>>
>>
>>
>> The above looks almost too obvious but for this:
>>
>>
>>> I also built a 2.4.28 kernel with the ftdi_sio and usbserial code 
>>> from the 2.4.24 release. It also failed. This was a surprise and I am 
>>> wondering of I did it correctly.
>>
>>
>>
>> Did you nail down a scenario which we can debug? Frankly it's not 
>> credible
> 
> 
> Not as yet. As I indicated I can only test the problem at a remote site 
> and I don't get much time to look at it.
> 
>> that transplanted usbserial and ftsi_sio would fail to work. I know that
> 
> 
> I agree, it can't be the case. To prove that I hadn't just made a 
> mistake, I transplanted the whole usb branch and it still failed. This 
> really points to the user app - which is complex and I haven't got to 
> the bottom of it. It's a multi-threaded library and I see it's doing 
> some sort of packet requeuing based on a timer. I can't see what has 
> changed but I am guessing it's a kernel timing issue. It would explain 
> everything.
> 
>> I changed quite a bit between 2.4.24 and 2.4.28, but your experiment
>> undoes that.
> 
> 
> I think the usb is red herring - sorry about that. BTW, I see you have 
> cc'd Ian (hi Ian). By coincidence we are using an MEV usb device.

I finally got to the bottom of this problem (with Ian Abbotts help). I 
had the wrong usb host module loaded, ubci not usb_uhci (in fact it was 
compiled in to the kernel). The write call to the usbserial device was 
blocking. This seemed to happen when a data packet of more than 8 bytes 
was written.

Having two drivers, one which works sometimes seems to be a bit of an 
elephant trap.

This was an error that occurred when I was preparing the new config 
file. I would guess I left the usb as the default. It might me better to 
have no defaults in the config, that way you are forced to make the 
correct selection.

What is the recommended way of transferring .config files between kernel 
versions? I see there are always a lot of changes. Can you safely just 
copy the existing file and then run xconfig to include any new options?


-- 
Ian Leonard

Please ignore spelling and punctuation - I did.

Re: 2.4.30 - USB serial problem

[Ian Abbott]

On 07/06/2005 09:28, Ian Leonard wrote:
> I finally got to the bottom of this problem (with Ian Abbotts help). I 
> had the wrong usb host module loaded, ubci not usb_uhci (in fact it was 
> compiled in to the kernel). The write call to the usbserial device was 
> blocking. This seemed to happen when a data packet of more than 8 bytes 
> was written.

It's actually a problem with queuing more than one bulk URB in the uhci 
driver.  (The TTY line discipline is probably splitting your single 
write into two or more writes, and the ftdi_sio driver queues an URB for 
each of these individual writes.)

> Having two drivers, one which works sometimes seems to be a bit of an 
> elephant trap.

The recommended advice (from David Brownell) seems to be to avoid 
queueing more than one bulk URB, though the "alternate" UHCI driver 
(uhci.o) seems to be the only one with this problem as far as I can tell.

I'll probably implement a different write implementation for the 
ftdi_sio driver to avoid the problem when I get a bit of free time.

> This was an error that occurred when I was preparing the new config 
> file. I would guess I left the usb as the default. It might me better to 
> have no defaults in the config, that way you are forced to make the 
> correct selection.
> 
> What is the recommended way of transferring .config files between kernel 
> versions? I see there are always a lot of changes. Can you safely just 
> copy the existing file and then run xconfig to include any new options?

Copy the previous .config across and run 'make oldconfig'.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@mev.co.uk>        )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-