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: Thu, 21 Jan 2010 10:38:05 -0500

On Wed, Jan 20, 2010 at 6:15 PM, Shane Blackett <shane at blackett.co.nz>
wrote:
...
>>> 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:

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;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 wilsonet.com




Archive powered by MHonArc 2.6.18.

Top of page