LCDproc development and user support list

Text archives Help


[Lcdproc] Older vfd lockups


Chronological Thread 
  • From: fblack947 at yahoo.com (jk)
  • Subject: [Lcdproc] Older vfd lockups
  • Date: Wed, 20 Jan 2010 13:38:51 -0800 (PST)





----- Original Message ----
> From: Shane Blackett <shane at blackett.co.nz>
...
> [ 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.

Hmm, seems like a tough one.

Here's what I'd recommend for debugging:

Try to access LCDd via telnet, after killing off any running clients. This
takes the lcdproc client out of the picture, which should stop too-fast
requests coming.

Details on the telnet interface can be found here:
http://lcdproc.sourceforge.net/docs/current-dev.html#language-open-session

FWIW, this is the first driver stuff I've done too... :}

-jonathan







Archive powered by MHonArc 2.6.18.

Top of page