Bug 7756

What's the kernel config?

Thanks

Created attachment 6446 [details]
Kernel config for x86 2.6.18-rc2

config.i386 is for the machine where hal seems to fail.

Hmm, weird. Try attaching output of lshal after hald is started... and try running 

 # service haldemon stop
 # /usr/sbin/hald --daemon=no --verbose=yes

wait for the output to finish... then plug in your device and put the new output
spew from hald in an attachment. Thanks. It would also be useful if you can test
this from git HEAD of hal. See this file for how to obtain it

 http://gitweb.freedesktop.org/?p=hal;a=blob;hb=HEAD;f=HACKING

Note you don't need to 'make install' the new HAL - you can run it via
hald/run-hald.sh (as root) from the build directory. Thanks.

Created attachment 6450 [details]
kernel config for athlon, 2.6.18-rc3

I am trying another machine that has the same problem that I have easier access
to.

This machine is running 2.6.18-rc3 and hal 0.5.8-cvs20060714rhughes from the
Fedora Utopia repo.

I rebooted this machine last night into 2.6.18-rc3, came into work this morning
plugged in the usbstick and low and behold it mounted it. I unmounted an
replugged  it but this time it didn't get mounted.

(I double checked my x86-64 workstation is still working, 2.6.18-rc3, hal
0.5.7.1-2.fc5 both i386 ans x86-64 versions it seems. Plugged the stick in, it
mounted. Unmounted, replugged and it and it mounted again.)


So onto the debugging.

Created attachment 6451 [details]
lshal outpout from hal-0.5.8cvs

This is the output of lshal from 0.5.8cvs with the usbstick plugged in.

Created attachment 6452 [details]
Output from /usr/sbin/hald --daemon=no --verbose=yes

This is the output from /usr/sbin/hald --daemon=no --verbose=yes (hal 0.5.8cvs)
from when the device was plugged in.

Created attachment 6453 [details]
Output from hald from git as of 2007-08-03

This is the output from running hald checked out from git, when the device was
plugged in (it also includes when the device was removed).

The stick didn't get mounted.

Cheers,

This looks wrong:

10:29:22.344 [E] util.c:516: Cannot open
'/sys/devices/pci0000:00/0000:00:03.2/usb1/1-5/1-5:1.0/host4/target4:0:0/4:0:0:0/model'
10:29:22.344 [E] util.c:516: Cannot open
'/sys/devices/pci0000:00/0000:00:03.2/usb1/1-5/1-5:1.0/host4/target4:0:0/4:0:0:0/vendor'
10:29:22.344 [E] util.c:324: Cannot open
'/sys/devices/pci0000:00/0000:00:03.2/usb1/1-5/1-5:1.0/host4/target4:0:0/4:0:0:0/type'
scandir: Permission denied
scandir: Permission denied
scandir: Permission denied

hald drops privileges to the unprivileged user haldaemon... and the permissions
on sysfs looks wrong because apparently the haldaemon user cannot access it...
Can a unprivileged user read e.g. 

 /sys/devices/pci0000:00/0000:00:03.2/usb1/1-5/1-5:1.0/host4/target4:0:0/4:0:0:0/model

If he can't you probably misconfigured the kernel and/or mounted /sys with wrong
permissions... Thanks.

OK, I tried again.

sysfs is mounted as

none on /sys type sysfs (rw)

from /etc/fstab

none                    /sys                    sysfs   defaults        0 0

And I as a normal user can browse around in there.

I re-ran the ./run-hald.sh and then plugged in a usb stick.

I seen the errors you pointed out.

15:34:55.556 [E] util.c:516: Cannot open
'/sys/devices/pci0000:00/0000:00:03.2/usb1/1-5/1-5:1.0/host6/target6:0:0/6:0:0:0/model'
15:34:55.556 [E] util.c:516: Cannot open
'/sys/devices/pci0000:00/0000:00:03.2/usb1/1-5/1-5:1.0/host6/target6:0:0/6:0:0:0/vendor'
15:34:55.556 [E] util.c:324: Cannot open
'/sys/devices/pci0000:00/0000:00:03.2/usb1/1-5/1-5:1.0/host6/target6:0:0/6:0:0:0/type'
scandir: Permission denied
scandir: Permission denied
scandir: Permission denied

However I (as a normal user) can read these files just fine.

i.e
[andrew@dev-c:/sys/devices/pci0000:00/0000:00:03.2/usb1/1-5/1-5:1.0/host6/target6:0:0/6:0:0:0]$
ls -l model type vendor

-r--r--r-- 1 root root 4096 Aug  4 15:34 model
-r--r--r-- 1 root root 4096 Aug  4 15:34 type
-r--r--r-- 1 root root 4096 Aug  4 15:34 vendor

and 

cat model type vendor

 USB Flash Drive
0
Imation


It's a weird one, as my x86-64 workstation with 2.6.18-rc3 is working fine.


Thanks for looking anyways...

Further down we have:


15:34:56.684 [I] blockdev.c:763: block_add: sysfs_path=/sys/block/sda/sda1
dev=/dev/sda1 is_part=1, parent=0x00000000
15:34:56.684 [W] blockdev.c:798: Unable to open /sys/block/sda/sda1/slaves:
Error opening directory '/sys/block/sda/sda1/slaves': No such file or directory
15:34:56.684 [I] blockdev.c:849: Ignoring hotplug event - no parent
15:34:56.684 [W] blockdev.c:1255: Not adding device object


True enough /sys/block/sda/sda1/slaves doesn't exist. Problem?

What we have in /sys/block/sda/sda1/ is

-r--r--r-- 1 root root 4096 Aug  4 15:34 dev
drwxr-xr-x 2 root root    0 Aug  4 15:34 holders
-r--r--r-- 1 root root 4096 Aug  4 15:45 size
-r--r--r-- 1 root root 4096 Aug  4 15:45 start
-r--r--r-- 1 root root 4096 Aug  4 15:45 stat
lrwxrwxrwx 1 root root    0 Aug  4 15:34 subsystem -> ../../../block
--w------- 1 root root 4096 Aug  4 15:45 uevent



Cheers.

> True enough /sys/block/sda/sda1/slaves doesn't exist. Problem?

Nope, this was a cosmetic error. It sounds like some issue with your kernel that
hald can't read the sysfs files. It works fine for me and others (I had Kay test
2.6.18-rc3 too) so I'm closing this bug. If you find the culprit please update
the bug! Thanks!

> Nope, this was a cosmetic error.

Which I might add is pushed to the git master repo.

I have the same bug, see also 

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175892
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200047

It looks that files are created after some delay while hal searching for them
in early beginning. It might be race condition here.

One probably needs to add WAIT_FOR_SYSFS into udev rules for hal

This line from redhat's udev patch for rules fixes the problem:

ACTION=="add", SUBSYSTEM=="scsi", WAIT_FOR_SYSFS="ioerr_cnt"

Okay, then it's not a HAL problem. Close it now.