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