LCDproc development and user support list

Text archives Help

[Lcdproc] Older vfd lockups

Chronological Thread 
  • From: jarod at (Jarod Wilson)
  • Subject: [Lcdproc] Older vfd lockups
  • Date: Thu, 21 Jan 2010 10:38:05 -0500

On Wed, Jan 20, 2010 at 6:15 PM, Shane Blackett <shane at>
>>> 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.
> Yep I read this thread as I got there from the urb(-22) search I did early
> on.
> I tried several values for mdelay in these routines (it is currently 4 I
> think). ?I tried it exactly as suggested in the patch by the person
> debugging it and in the slightly different form that you recommended.
> Unfortunately it didn't seem to make much difference to me.

Okay, good to at least have concrete confirmation of that. :)

> I'll play around with such a delay again a bit more rigourously when I get a
> chance and then list what I have tried here.

I keep forgetting... There's another change that might help... When I
sent the new input layer imon driver[*] upstream for review, it was
pointed out that the atomic_foo() calls *probably* aren't doing what
they were intended to do -- which is safeguard against having multiple
writes in flight at the same time. I rewrote that bit of code to use
memory barriers, which should properly remedy any caching effects, so
we always get a consistent picture of whether or not there's actually
write traffic in flight already... Unfortunately, I don't have a patch
against lirc_imon handy at the moment, but it should be fairly trivial
to port:;a=commitdiff;h=75c2fe9117de538386c18231fa8521dd48ef7b59

[*] I've split off support for ffdc and newer devices that do onboard
decoding into a pure input layer driver, per some lirc discussion on
lkml, leaving lirc_imon to handle only the four very very old devices
that don't do onboard decoding. Not making this change in lirc cvs yet
though, only in my git tree...

Jarod Wilson
jarod at

Archive powered by MHonArc 2.6.18.

Top of page