Re: Re: Reliable unreliability with D-Link DWL-122 USB

On this whole question of hald I have good news and bad news.


I patched my copy of hal 0.4.7 to change usb_proc_parse() in usb_bus_device.c so that it just returns immediately (i.e. becomes a dummy procedure).

I am convinced that this curtails hald from reading /proc/bus/usb/devices.

The good news is that on my system, this does not appear to lose any functionality from Hal and the things that use it. The reason is that with more recent kernels (say 2.6.10 onwards), Hal can get all it needs from /sys anyway, and so the /proc/bus/usb/devices source of info is redundant (hence why I believe Hal >= 0.5.0 doesn't even bother with it). I judged this by a quick visual scan of the devices
using the hal-device-manager gui: not very scientific but probably good enough.


The bad news is that anything reading info via /sys will actually invoke the same underlying kernel calls as reading /proc/bus/usb/devices: deep down in the kernel both have to use calls such as usb_get_string or usb_get_descriptor to obtain the info to report back to the user (via the virtual filing systems of /proc or /sys). Since it is these
calls that are sending control messages to the prism card, it means that Hal using /sys will still lead to the card locking up!


So my simple hack on Hal did not remove the lock ups, it just made them slightly less probable. 


Note there are two subtleties to understand here:

1) A read of /proc/bus/usb/devices forces the kernel to re-scan all usb devices to return the result, even if you are just interested in one device. What I believe Hal 0.4.7 was doing is for every usb device it encountered (including all the motherboard hubs etc.) it was re-reading /proc/bus/usb/devices - so it was re-scanning
(and thus touching the prism card) many times over. My hack to hald has removed this.

2) The read via /sys, however, is specific to the device. I.e. you can query (and thus the kernel will scan) a specific device and this will not touch the others. This means that Hal only touches the prism card the once when it 'discovers' it and uses /sys to obtain the attributes. Thereafter, for the life of the Hal process, it leaves the prism card alone (even if other devices are plugged
and unplugged, memory cards inserted into card readers etc.).


So on the positive side, a hacked Hal 0.4.7, or Hal >= 0.5.0 will 'touch' the prism the once when hald starts or the device is plugged in. Thereafter, it is safe!


To prove this I have put in a delay into my prism network initialisation script (for me that means a sleep call in a script in /etc/hotplug.d/net), but you could put it elsewhere. I found I need to sleep by a whacking
15 seconds (ouch!) to give hald time to start on boot, scan devices and settle down, so it is then safe to let the prism driver init & use the card.

I will see how this (yukky) hack goes over the next few days - but a couple of reboots so far shows promise.


Alternatives to this are:

- Disable hald altogether (and lose the nice functionality it brings to your desktop)

- Get the kernel changed so that it caches the usb card attributes in memory - so that when hal queries via /sys it does not need to re-scan the actual card but simply returns the already known values from memory.

- Get the kernel changed so that a driver can tell the kernel 'disallow future scans', so scans become disabled (the /sys reads would then return null values).

- Get the manufacturer of the chipset to work out if this can be fixed in the firmware (after all, it does seem to be a bug in the card)


None of the above seem that likely to me!

Karl


> 
> From: Dave Jenkins <[email protected]>
> 
> --- [email protected] wrote:
> > However, its not all bad news. The main culprit
> seems
> > to be hald, which in versions before 0.5.0 is
> regularly
> > reading /proc/bus/usb/devices and thus making the
> lockup
> > highly likely. As far as I can see from the hal
> source
> > code, a major change in 0.5.0 might remove this
> behaviour -
> > it will do the lookup only the once rather than
> frequently.
> 


-----------------------------------------
Email provided by http://www.ntlhome.com/