Created attachment 325808 [details] emerge --info In my system symlinks in /dev/disk/by-path are wrong: # ls -l /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root root 9 Oct 6 16:28 pci-0000:00:1f.1-scsi-0:0:0:0 -> ../../sr0 lrwxrwxrwx 1 root root 10 Oct 6 15:57 pci-0000:00:1f.1-scsi-0:0:0:0-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Oct 6 15:57 pci-0000:00:1f.1-scsi-0:0:0:0-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Oct 6 15:57 pci-0000:00:1f.1-scsi-0:0:0:0-part3 -> ../../sda3 lrwxrwxrwx 1 root root 10 Oct 6 15:57 pci-0000:00:1f.1-scsi-0:0:0:0-part4 -> ../../sda4 lrwxrwxrwx 1 root root 10 Oct 6 15:57 pci-0000:00:1f.1-scsi-0:0:0:0-part5 -> ../../sda5 lrwxrwxrwx 1 root root 10 Oct 6 15:57 pci-0000:00:1f.1-scsi-0:0:0:0-part6 -> ../../sda6 lrwxrwxrwx 1 root root 9 Oct 6 16:16 pci-0000:00:1f.1-scsi-0:0:1:0 -> ../../sr1 [snipped] The devices really are: # ls -l /sys/block/ total 0 [snipped] lrwxrwxrwx 1 root root 0 Oct 6 15:57 sda -> ../devices/pci0000:00/0000:00:1f.1/ata1/host0/target0:0:0/0:0:0:0/block/sda lrwxrwxrwx 1 root root 0 Oct 6 16:53 sdb -> ../devices/pci0000:00/0000:00:1f.1/ata1/host0/target0:0:1/0:0:1:0/block/sdb lrwxrwxrwx 1 root root 0 Oct 6 16:53 sr0 -> ../devices/pci0000:00/0000:00:1f.1/ata2/host1/target1:0:0/1:0:0:0/block/sr0 lrwxrwxrwx 1 root root 0 Oct 6 16:53 sr1 -> ../devices/pci0000:00/0000:00:1f.1/ata2/host1/target1:0:1/1:0:1:0/block/sr1 /lib/udev/path_id seems to be the culprit: # /lib/udev/path_id /devices/pci0000:00/0000:00:1f.1/ata1/host0/target0:0:0/0:0:0:0/block/sda ID_PATH=pci-0000:00:1f.1-scsi-0:0:0:0 # /lib/udev/path_id /devices/pci0000:00/0000:00:1f.1/ata2/host1/target1:0:0/1:0:0:0/block/sr0 ID_PATH=pci-0000:00:1f.1-scsi-0:0:0:0 # /lib/udev/path_id /devices/pci0000:00/0000:00:1f.1/ata1/host0/target0:0:1/0:0:1:0/block/sdb ID_PATH=pci-0000:00:1f.1-scsi-0:0:1:0 # /lib/udev/path_id /devices/pci0000:00/0000:00:1f.1/ata2/host1/target1:0:1/1:0:1:0/block/sr1 ID_PATH=pci-0000:00:1f.1-scsi-0:0:1:0 Since I switched to kernel 3.3.8 I experienced several mysterious system lockups when accessing sr0. It is a headless box and logging just seems to have stopped suddenly so no more info from that side. Searching the net I found the same bug reported for udev-175: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687378
@sf, 3.3.8 is not anymore in the tree, can you reproduce this bug with any other version?
you need to upgrade udev to newer version before using such a new kernel, try the ~ərch version (I know it's not in stable yet, but that's out of my hands, sorry.)
Re comment #1: Right now I am using udev-171-r8 with the following patch: http://cgit.freedesktop.org/systemd/systemd/commit/?id=481dcf7c8fa8fd9fd181b59443b7e30e9b42add4 I removed all uses of /dev/disk/by-path/ from my system and had no more problems (currently with vanilla-sources-3.5.7).
Re comment #2: As said in comment #3 I have udev-171-r8 and vanilla-sources-3.5.7 (both latest stable). Do you mean this udev version is not suited for this kernel version?
(In reply to comment #4) > Re comment #2: > > As said in comment #3 I have udev-171-r8 and vanilla-sources-3.5.7 (both > latest stable). Do you mean this udev version is not suited for this kernel > version? as you pointed out in prev. comment, you are using the correct patch applied on top of 171 now. keep on doing that or upgrade BUT expect to hit more issues with the combination, there are numerous of already fixed bugs in the ~arch copy of udev in relationship with >=3.0.0 kernels.
I've added the patch in tree as =sys-fs/udev-171-r9 to ~arch. Only tested that it compiles.
sys-fs/udev-171-r9 works for me. Thanks.
Unfortunately this triggered bug 444604. Seems we 'need to' backport some more.
