LCDproc development and user support list

Text archives Help


[Lcdproc] Older vfd lockups


Chronological Thread 
  • From: shane at blackett.co.nz (Shane Blackett)
  • Subject: [Lcdproc] Older vfd lockups
  • Date: Thu, 21 Jan 2010 12:15:54 +1300

On 21/01/2010 10:34 a.m., Jarod Wilson wrote:
> On Wed, Jan 20, 2010 at 3:48 PM, Shane Blackett<shane at blackett.co.nz>
> wrote:
> ...
>>>> For example, what causes "send_packet: task interrupted" and
>>>> "send_packet: error submitting urb(-22)" ?
>>>
>>> Its in the imon driver's send_packet function:
>>>
>>> retval = usb_submit_urb(ictx->tx_urb, GFP_KERNEL);
>>> if (retval) {
>>> ictx->tx.busy = 0;
>>> smp_rmb(); /* ensure later readers know we're not busy */
>>> err("%s: error submitting urb(%d)", __func__, retval);
>>> } else {
>>> /* Wait for transmission to complete (or abort) */
>>> mutex_unlock(&ictx->lock);
>>> retval = wait_for_completion_interruptible(
>>> &ictx->tx.finished);
>>> if (retval)
>>> err("%s: task interrupted", __func__);
>>> mutex_lock(&ictx->lock);
>>>
>>> retval = ictx->tx.status;
>>> if (retval)
>>> err("%s: packet tx failed (%d)", __func__,
>>> retval);
>>> }
>>>
>>>
>>> -22 is -EINVAL, not quite sure what happened to the completion event
>>> there.
>>
>> [ 51.385009] lirc_imon: Writing data 32 44200707
>> [ 51.389009] lirc_imon: send_packet ffff880122632cac 8
>> [ 51.470104] lirc_imon: send_packet ffff880122632cac 8
>> [ 71.972696] lirc_imon: send_packet: task interrupted
>> [ 71.976703] lirc_imon: send_packet ffff880122632cac 8
>> [ 71.976706] lirc_imon: send_packet: error submitting urb(-22)
>> [ 71.976708] lirc_imon: vfd_write: send packet failed for packet #1
>> [ 71.980726] lirc_imon: send_packet ffff880122632cac 8
>> [ 71.980730] lirc_imon: send_packet: error submitting urb(-22)
>> [ 71.980732] lirc_imon: vfd_write: send packet failed for packet #0
>> [ 71.980737] display port closed
>>
>> I'm not sure, but I think the "task interrupted" is because I killed the
>> LCDd job, there is a significant jump in the logging number. This call
>> just
>> didn't really return and the display had locked up. After waiting ten
>> seconds or so I stopped LCDd, resulting in "task interrupted" and it
>> probably tries to write goodbye. From then on I get the urb errors as the
>> driver is locked.
>
> Okay, that much makes sense. So this sounds like the same problem a
> few people have reported over on the lirc list.
>
>>> Would be much easier to debug these problems if I actually had an imon
>>> device that exhibited them, both my (newer than ffdc) VFD and LCD work
>>> flawlessly though. :\
>>
>> I have two ideas I'm thinking about for errors at the moment. It proabably
>> seems related to the speed the data is coming, I wonder if either in the
>> actual imon device or possibly in the USB HUB that the device is connected
>> to?
>
> Dunno. I floated a test patch out there that simply added (iirc) an
> mdelay(10) to the end of send_packet() to see if stalling return from
> that function a bit effectively throttled how fast we were sending
> data to the display, to the point where it could actually keep up. I
> can't remember a definitive reply that said it didn't help, so if you
> can slap that in and test it out, it would be much appreciated.

Yep I read this thread as I got there from the urb(-22) search I did
early on.
I tried several values for mdelay in these routines (it is currently 4 I
think). I tried it exactly as suggested in the patch by the person
debugging it and in the slightly different form that you recommended.
Unfortunately it didn't seem to make much difference to me.

I'll play around with such a delay again a bit more rigourously when I
get a chance and then list what I have tried here.

>> I'm used to developing code, although not kernel/driver stuff.
>>
>> When I try to unload the lirc_imon kernel module once it has locked, not
>> only does the modprobe never finish but other usb devices lock up too.
>
> Bleah. Wedging the entire bus (or subsystem), apparently.

Shane.




Archive powered by MHonArc 2.6.18.

Top of page