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: Tue, 6 Apr 2010 22:39:52 -0400

On Tue, Apr 6, 2010 at 8:54 PM, Shane Blackett <shane at blackett.co.nz>
wrote:
> 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.

That's a plus. I still wonder if there's something we can't do within
the driver to help more. In addition to what you've already patched
in, I've got another patch in my queue that is based on one from a
launchpad ticket someone pointed me at:

http://wilsonet.com/jarod/junk/imon-delay.patch

Would be curious to see if that helps any if you're not employing the
workarounds.

--jarod


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



--
Jarod Wilson
jarod at wilsonet.com




Archive powered by MHonArc 2.6.18.

Top of page