- From: shane at blackett.co.nz (Shane Blackett)
- Subject: [Lcdproc] Older vfd lockups
- Date: Thu, 21 Jan 2010 09:48:41 +1300
On 21/01/2010 3:30 a.m., Jarod Wilson wrote:
>
On Wed, Jan 20, 2010 at 9:10 AM, jk<fblack947 at yahoo.com> wrote:
>
> I'm shooting from the hip on this one. If anyone with more imon (vfd)
>
> driver experience wants to drop in, it'd be appreciated!
>
>
>
>> I will have another go. I hadn't seen this page before, although there
>
>> is very
>
>> little in it:
>
>> https://help.ubuntu.com/community/IMON_VFD_and_LCD_Karmic_9.10
>
>> ...
>
>
>
> That's a pretty good page. Not much on troubleshooting, but I'll have to
>
> keep it in my bookmarks...
>
>
This part is rather misleading:
>
>
"But wait - Just because you no longer have to patch anything doesn't
>
mean that you don't still need to determine which display you have and
>
enable the correct settings in /etc/LCDd.conf and also add the correct
>
kernel options for lirc_imon at /etc/modrobe.d/lirc.conf."
>
>
Outside of the ffdc devices, you shouldn't have to touch a damned
>
thing, auto-detection of display type and auto-config of stuff should
>
Just Work.
>
>
> A buffer was added to the imonlcd driver, so that it wouldn't update the
>
> display if nothing changed. This apparently helped with "faster"
>
> computers. I think there also was (still is?) a parameter setting to
>
> limit the frequency of the screen refresh, which might still be there, and
>
> might help.
I'll have a look to see if there are some clues in the imonlcd driver
for me to try.
>
Is this in the lcdproc driver? Nobody ever got back to me with any
>
useful feedback on whether adding a delay in the kernel driver helped
>
with this issue...
>
>
> Is there a way you can isolate lcdproc from lirc to determine whether the
>
> issue is in lcdproc client, lcdproc server, lirc, or something else?
>
> You're lirc debugging looks to be going in that direction.
>
>
>
> 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.
>
>
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?
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.
Shane.
Archive powered by MHonArc 2.6.18.