hal, usbstick and IBM R40

[David Zeuthen]

Hey,

Sorry for the delay,

On Sun, 2004-09-05 at 17:20 +0200, Thomas Gufler wrote:
> Hi,
> 
> I have a strange problem using a IBM usb-stick on a IBM R40 Laptop (with 
> hal-cvs+fstab-sync). 
> 
> There are three different cases:
> 1) The usbstick is not recognized at all. hal does recognize many (all?) other 
> devices, but no usb devices though all needed usb modules are loaded. This 
> often happens when the computer was rebooted before. A /dev/sda is created by 
> udev (lshal shows 30 devices)
> 2) The usbstick is recognized but the partition on the usbstick is not 
> detected, so I get a /dev/sda but not a /dev/sda1. (lshal shows 45 devices)
> 3) The usbstick and the partition are recognized :-) (lshal shows 46 devices)
> 
> The output of 'HALD_VERBOSE=1 ./hald --daemon=no' for case 2 and 3 is attached 
> below. If the lshal output would also be interesting please let me know. 
> 
> I use this usb stick also on a desktop computer (Athlon XP 2200+, SIS 735 
> chipset) without any problem (also with hal+fstab-sync). Both computers use a 
> gentoo linux system with kernel 2.6.7, udev-030, dbus-cvs, hal-cvs (both from 
> yesterday), on the laptop usb needs the uhci_hcd and on the desktop the 
> ohci_hcd module. 
> 
> Any suggestions?
> 

Yes, your system is obviously sufficiently misconfigured to trigger some
bugs in hal - which is a good thing insofar we can make hal more
resistant :-). 

So, I'm troubled by seeing this

        14:54:20.372 [I] linux/osspec.c:1421: Queing up seqnum=165, sysfspath=/class/net/eth0, subsys=pci
        14:54:30.475 [I] linux/osspec.c:1421: Queing up seqnum=165, sysfspath=/class/net/eth0, subsys=pci
        14:54:40.599 [I] linux/osspec.c:1421: Queing up seqnum=165, sysfspath=/class/net/eth0, subsys=pci
        14:54:50.714 [I] linux/osspec.c:1421: Queing up seqnum=165, sysfspath=/class/net/eth0, subsys=pci
        14:55:00.835 [I] linux/osspec.c:1421: Queing up seqnum=165, sysfspath=/class/net/eth0, subsys=pci
        
that occurs roughly every ten seconds. The first other "real" hotplug event is 324:

        14:54:41.529 [I] linux/osspec.c:1421: Queing up seqnum=324, sysfspath=/devices/pci0000:00/0000:00:1d.1/usb2/2-1, subsys=usb
        14:54:41.529 [I] linux/osspec.c:1421: Queing up seqnum=324, sysfspath=/devices/pci0000:00/0000:00:1d.1/usb2/2-1, subsys=usb
        
and it seems you have two hal.hotplug scripts installed :-). Btw, we now
print a big annoying warning saying that duplicates are ignored. I
suppose you should bug the hal-cvs ebuild maintainer (if applicable).

The reason hal locks up is simply that we're waiting for the hotplug
event with sequence number 166; you know it may be delayed for any
amount of time (from hal's point of view). We can fix this issue only
when the kernel exports the initial sequence number, and thanks to Kay
this may be sooner than later. Until then I suppose you need to fix your
system manually.

Care to find out what is triggering the SEQNUM 165? I'm kind of curious;
it's probably something that execute the hotplug scripts.

Good luck,
David

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal