LCDproc development and user support list

Text archives Help


[Lcdproc] Older vfd lockups


Chronological Thread 
  • From: shane at blackett.co.nz (Shane Blackett)
  • Subject: [Lcdproc] Older vfd lockups
  • Date: Wed, 07 Apr 2010 12:54:18 +1200

Sorry to take so long to get back about this.

I did try patching as described below.
The display worked for over a day, which is more like how it had been
for me with Ubuntu 9.04.
So I thought that was helping me, removed all my debug code and wrote
and email saying that this helped. Then I tried my patched version and
it locked up straight away. It turns out that the mdelay was helping me
now, and actually much larger values of delay helped more, however over
time (days) other devices (read mouse and keyboard) might get locked up
too, although this had never happened when I hadn't started the display.

Then I was trying a totally different USB device and had troubles so did
some searches for my USB hub devices and motherboard chipsets and it
seems that these are really the cause of my problems.

I have a Nvidia MCP78S chipset
http://www.gossamer-threads.com/lists/linux/kernel/1204277

In hindsight it seems obvious that I should have looked this up earlier.
So my system isn't a useful test for any of this.

Incidently, with the kernel option workarounds suggested in the thread
my vfmon display has been running a week without incident which is
easily a record.

Shane.

On 22/01/2010 4:38 a.m., Jarod Wilson wrote:
> 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...
>





Archive powered by MHonArc 2.6.18.

Top of page