LCDproc development and user support list

Text archives Help


[Lcdproc] Older vfd lockups


Chronological Thread 
  • From: jarod at wilsonet.com (Jarod Wilson)
  • Subject: [Lcdproc] Older vfd lockups
  • Date: Wed, 20 Jan 2010 16:34:40 -0500

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.

> 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.

--
Jarod Wilson
jarod at wilsonet.com




Archive powered by MHonArc 2.6.18.

Top of page