Chronological Thread 

< Chronological >      < Thread >

---

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.

---

• [Lcdproc] Older vfd lockups, Shane Blackett, 01/17/2010
  • [Lcdproc] Older vfd lockups, jk, 01/18/2010
    • [Lcdproc] Older vfd lockups, Shane Blackett, 01/20/2010
      • [Lcdproc] Older vfd lockups, jk, 01/20/2010
        • [Lcdproc] Older vfd lockups, Jarod Wilson, 01/20/2010
          • [Lcdproc] Older vfd lockups, Shane Blackett, 01/20/2010
            • [Lcdproc] Older vfd lockups, Jarod Wilson, 01/20/2010
              • [Lcdproc] Older vfd lockups, Shane Blackett, 01/21/2010
              • [Lcdproc] Older vfd lockups, Jarod Wilson, 01/21/2010
            • [Lcdproc] Older vfd lockups, jk, 01/20/2010
          • [Lcdproc] Older vfd lockups, jk, 01/20/2010
            • [Lcdproc] Older vfd lockups, Jarod Wilson, 01/20/2010
              • [Lcdproc] Older vfd lockups, jk, 01/20/2010

---

Archive powered by MHonArc 2.6.18.