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 09:30:09 -0500

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.

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.

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


--
Jarod Wilson
jarod at wilsonet.com




Archive powered by MHonArc 2.6.18.

Top of page