Matching problems

Bastien Nocera hadess at hadess.net
Tue Jun 5 14:54:23 PDT 2007


On Tue, 2007-06-05 at 22:50 +0100, Richard Hughes wrote:
> On Tue, 2007-06-05 at 16:13 -0400, David Zeuthen wrote:
> > On Tue, 2007-06-05 at 18:42 +0100, Richard Hughes wrote:
> > > I get yyyyyyyyy merged but not zzzzzzzzzzz or xxxxxxxxxx. I smell a
> > > matching bug somewhere, anyone got any ideas?
> > 
> > I bet laptop_panel is on the computer root device and the UDI isn't set
> > that early. So that's why only yyyyyyyyyy is merged. We should probably
> > special case that; e.g. set the UDI for the computer root device at
> > temporary device object creation time. Makes sense?
> 
> No, don't think this is correct.
> 
> I've been tracing this, and it appears that when we do the match against
> smbios.system.manufacturer then the following properties are on computer
> are as follows:
> 
>  device udi = /org/freedesktop/Hal/devices/computer
>   system.kernel.name = 'Linux'  (string)
>   system.kernel.machine = 'i686'  (string)
>   info.bus = 'unknown'  (string)
>   info.udi = '/org/freedesktop/Hal/devices/computer'  (string)
>   info.subsystem = 'unknown'  (string)
>   info.product = 'Computer'  (string)
>   system.kernel.version = '2.6.21-1.3194.fc7'  (string)
> 
> This leads me to think that we are not actually waiting for the dmi
> prober to finish before we do the fdi scanning, and are thus not
> matching.

Isn't this the same problem we talked about a couple of weeks ago? If
so, it's just that the race condition got more acute.

Hopefully, the dmi kernel code will greatly help alleviate the problem.
In the meanwhile, we should serialise those calls, or we'll constantly
get in trouble.

-- 
Bastien Nocera <hadess at hadess.net> 



More information about the hal mailing list