http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c2 --- Comment #2 from Mike DeMicco <mfdemicco@gmail.com> --- I did not see a kernel log. I looked at dmesg and didn't discern anything there. I installed kdump and it locked up my computer, so I had to chroot in and uninstall it. Dracut could not create the initrd file with kernel 5.17.4-1 either, so the problem isn't with the kernel, it's probably with Dracut. Also, there should be a /var/log/dracut.log or /tmp/dracut.log file and there isn't. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c5 --- Comment #5 from Mike DeMicco <mfdemicco@gmail.com> --- The -v option for dracut doesn't produce anymore output than without it. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c7 --- Comment #7 from Thomas Blume <thomas.blume@suse.com> --- (In reply to Mike DeMicco from comment #6)

Created attachment 859635 [details] dracut --debug output screen shot

A photo of my screen after freezing using the dracut --debug command.

Ok, thanks, it seems that it freezes on an udevadm command. Could you please execute: udevadm info -a /dev/block/8:16 as root and check whether that also freezes your machine? If so, can you please provide the output of: udevadm info -e journalctl -axb --no-pager dmesg -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c9 --- Comment #9 from Mike DeMicco <mfdemicco@gmail.com> --- Created attachment 859714 --> http://bugzilla.opensuse.org/attachment.cgi?id=859714&action=edit udevadm info -e -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c11 --- Comment #11 from Mike DeMicco <mfdemicco@gmail.com> --- Created attachment 859716 --> http://bugzilla.opensuse.org/attachment.cgi?id=859716&action=edit dmesg -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c14 --- Comment #14 from Mike DeMicco <mfdemicco@gmail.com> --- (In reply to Thomas Blume from comment #13)

(In reply to Mike DeMicco from comment #12)

...

udevadm info -a /dev/block/8:16 when run as root crashes my computer, when run with my user account, it doesn't.

Could you attach the output of the udevadm info -a run as user?

/dev/block/8:16 resolves to the device sdb (major 8, minor 16). This disk shows in dmesg:

--> [ 3.780546] ata6: SATA link down (SStatus 0 SControl 300) [ 3.780904] scsi 6:0:0:0: Direct-Access ATA Samsung SSD 860 2B6Q PQ: 0 ANSI: 5 [...] [ 3.781663] sd 6:0:0:0: [sdb] 1953516911 512-byte logical blocks: (1.00 TB/932 GiB) [ 3.781678] sd 6:0:0:0: [sdb] Write Protect is off [ 3.781682] sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [...] [ 3.830980] sd 6:0:0:0: [sdb] supports TCG Opal [ 3.830983] sd 6:0:0:0: [sdb] Attached SCSI removable disk --<

The "SATA link down" message and the indication that this is a removable disk is a bit unusual. How is this disk attached to your machine?

The drive is an internal SSD drive attached to the motherboard controller port with a SATA cable. See attachment for udevadm info -a run as user. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c17 --- Comment #17 from Mike DeMicco <mfdemicco@gmail.com> --- (In reply to Thomas Blume from comment #16)

(In reply to Mike DeMicco from comment #15)

...

Created attachment 859797 [details] udevadm info -a /dev/block/8:16 run as user

Thanks, the output doesn't indicate an issue. For comparison, could you please run the udevadm command on /dev/sdc as root, e.g.:

udevadm info -a /dev/block/8:32

and attach the output? Can you confirm that sdc is attached the same way like sdb?

That command run as root locks up my computer too. Sdc is attached to the same Marvell 88SE9128 controller as well. I tried both drives on the Intel ICH10 controller, and I get the same crashes there too. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c19 --- Comment #19 from Mike DeMicco <mfdemicco@gmail.com> --- Now I've got another problem. OS-prober doesn't detect any other OS even though it's set to do so. It worked before. I wonder if changing to a generic initrd screwed this up. My old kernel was removed by a zypper dup, so I can't go back to that to verify. I was able to restore a proper grub.cfg that had all the OS's by chrooting though Arch Linux. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c23 --- Comment #23 from Mike DeMicco <mfdemicco@gmail.com> --- (In reply to Thomas Blume from comment #22)

(In reply to Mike DeMicco from comment #21)

...

No, the problem was/is that somehow, multipath was turned on and os-prober is not compatible with it. This is described in Bug 1097203, but unfortunately, that bug was closed without resolving the incompatibility with os-prober! That bug should either be reopened or a new one created. Anyhow, I chrooted in and turned off multipath so os-prober works again. I'm unsure if I inadvertently turned on multipath by messing with the kernel commandline commands, or if installation of the new kernel caused it.

I'm venting here but I've had a good experience with Tumbleweed for a number of years, but currently am running into a number of bugs with it. One other issue, I locked my old working kernel in zypper, but installation of a new kernel deleted it. I don't think that should have happened.

Incidentally, the problem with the "udevadm info -a" command is not unique to OpenSuse. It occurs in Arch and Debian on my system too, but I don't have issues with it on those systems because dracut is not being used and maybe the dracut.sh script they use doesn't invoke it.

Ok, so obviously, the udevadm commands in os-prober work, though it also gets executed as root. Are your Arch and Debian installations on the same machine like Tumbleweed? If so, the culprit might be hardware related. At least I cannot reproduce a system hang when executing udevadm info -a on any of my testmachines.

Yes, they are on the same extended partition: Disk /dev/sdb: 931.51 GiB, 1000200658432 bytes, 1953516911 sectors Disk model: Samsung SSD 860 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5a440a1e Device Boot Start End Sectors Size Id Type /dev/sdb1 * 2048 204802047 204800000 97.7G 7 HPFS/NTFS/exFAT /dev/sdb2 204804094 1091614719 886810626 422.9G 5 Extended /dev/sdb5 204804096 221188095 16384000 7.8G 82 Linux swap / Solaris /dev/sdb6 221190144 323592191 102402048 48.8G 83 Linux /dev/sdb7 323594240 425996287 102402048 48.8G 83 Linux /dev/sdb8 477200384 579600383 102400000 48.8G 83 Linux /dev/sdb9 630806528 733206527 102400000 48.8G 83 Linux /dev/sdb10 784412672 886814719 102402048 48.8G 83 Linux /dev/sdb11 579602432 630804479 51202048 24.4G 83 Linux /dev/sdb12 425998336 477198335 51200000 24.4G 83 Linux /dev/sdb13 733210624 784410623 51200000 24.4G 83 Linux /dev/sdb14 886816768 989214719 102397952 48.8G 83 Linux /dev/sdb15 989216768 1091614719 102397952 48.8G 83 Linux Partition table entries are not in disk order. There probably is some incompatibility with my hardware, as I can't find others having this problem. (In reply to Thomas Blume from comment #22)

(In reply to Mike DeMicco from comment #21)

...

No, the problem was/is that somehow, multipath was turned on and os-prober is not compatible with it. This is described in Bug 1097203, but unfortunately, that bug was closed without resolving the incompatibility with os-prober! That bug should either be reopened or a new one created. Anyhow, I chrooted in and turned off multipath so os-prober works again. I'm unsure if I inadvertently turned on multipath by messing with the kernel commandline commands, or if installation of the new kernel caused it.

I'm venting here but I've had a good experience with Tumbleweed for a number of years, but currently am running into a number of bugs with it. One other issue, I locked my old working kernel in zypper, but installation of a new kernel deleted it. I don't think that should have happened.

Incidentally, the problem with the "udevadm info -a" command is not unique to OpenSuse. It occurs in Arch and Debian on my system too, but I don't have issues with it on those systems because dracut is not being used and maybe the dracut.sh script they use doesn't invoke it.

Ok, so obviously, the udevadm commands in os-prober work, though it also gets executed as root. Are your Arch and Debian installations on the same machine like Tumbleweed? If so, the culprit might be hardware related. At least I cannot reproduce a system hang when executing udevadm info -a on any of my testmachines.

Yes, Arch and Debian are both on the same extended partition: Disk /dev/sdb: 931.51 GiB, 1000200658432 bytes, 1953516911 sectors Disk model: Samsung SSD 860 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5a440a1e Device Boot Start End Sectors Size Id Type /dev/sdb1 * 2048 204802047 204800000 97.7G 7 HPFS/NTFS/exFAT /dev/sdb2 204804094 1091614719 886810626 422.9G 5 Extended /dev/sdb5 204804096 221188095 16384000 7.8G 82 Linux swap / Solaris /dev/sdb6 221190144 323592191 102402048 48.8G 83 Linux /dev/sdb7 323594240 425996287 102402048 48.8G 83 Linux /dev/sdb8 477200384 579600383 102400000 48.8G 83 Linux /dev/sdb9 630806528 733206527 102400000 48.8G 83 Linux /dev/sdb10 784412672 886814719 102402048 48.8G 83 Linux /dev/sdb11 579602432 630804479 51202048 24.4G 83 Linux /dev/sdb12 425998336 477198335 51200000 24.4G 83 Linux /dev/sdb13 733210624 784410623 51200000 24.4G 83 Linux /dev/sdb14 886816768 989214719 102397952 48.8G 83 Linux /dev/sdb15 989216768 1091614719 102397952 48.8G 83 Linux Partition table entries are not in disk order. There probably is some incompatibility with my hardware. I do believe the computer is functioning properly as I've not had any other problems other than this issue. As mentioned above, I tried generating a new initrd with my old kernel, and got the system freeze too. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c26 --- Comment #26 from Mike DeMicco <mfdemicco@gmail.com> --- Created attachment 859968 --> http://bugzilla.opensuse.org/attachment.cgi?id=859968&action=edit dmesg log -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c28 --- Comment #28 from Mike DeMicco <mfdemicco@gmail.com> --- FYI, there was a change to dracut-functions.sh that invoked "udevadm info -a." Older versions of this shell script do not do this (e.g., the 15.3 version of Leap, vs. latter versions). This is the change that caused the problem on my system. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c31 --- Comment #31 from Mike DeMicco <mfdemicco@gmail.com> --- (In reply to Thomas Blume from comment #29)

(In reply to Mike DeMicco from comment #28)

...

FYI, there was a change to dracut-functions.sh that invoked "udevadm info -a." Older versions of this shell script do not do this (e.g., the 15.3 version of Leap, vs. latter versions). This is the change that caused the problem on my system.

Ok, still, 'updevadm info -a' should not hang your computer. Unfortunately, the udev debug logs didn't make it into the dmesg output. But I've found a resource conflict with your i/o controller:

--> [ 13.209692] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x000000000000042C-0x000000000000042D (\GP2C) (20211217/utaddress-204) [ 13.209701] ACPI: OSL: Resource conflict; ACPI support missing from driver? [ 13.211431] lpc_ich: Resource conflict(s) found affecting gpio_ich --<

Such conflicting resources could probably cause a system hang when they are accessed by udevadm via sysfs.

When I Google this error, I get a lot of hits. Mostly say the error message is informative and harmless and bugs were closed saying the same. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c34 --- Comment #34 from Mike DeMicco <mfdemicco@gmail.com> --- I could not get it to save to a text file, but took a photo of the screen. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c37 --- Comment #37 from Mike DeMicco <mfdemicco@gmail.com> --- I ran the command sudo udevadm test /sys/devices/pci0000:00/ and I get a segmentation fault. See attachment. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c46 --- Comment #46 from Mike DeMicco <mfdemicco@gmail.com> --- (In reply to Martin Wilck from comment #45)

It makes sense to read it - if you know precisely which registers are mapped at which offset. Just dumping the contents blindly doesn't make so much sense. I wonder if "lspci -vv" would also hang on that system?

No, lspci -vv run as root and user works fine. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c49 --- Comment #49 from Mike DeMicco <mfdemicco@gmail.com> --- (In reply to Martin Wilck from comment #47)

(In reply to Mike DeMicco from comment #46)

...

No, lspci -vv run as root and user works fine.

But "cat" on the "config" file hangs?

If I do a "# cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/config", the system doesn't hang. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c52 --- Comment #52 from Mike DeMicco <mfdemicco@gmail.com> --- Created attachment 860999 --> http://bugzilla.opensuse.org/attachment.cgi?id=860999&action=edit strace udevadm info -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c59 --- Comment #59 from Mike DeMicco <mfdemicco@gmail.com> --- Created attachment 861016 --> http://bugzilla.opensuse.org/attachment.cgi?id=861016&action=edit lspci -vvxxxx -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c62 --- Comment #62 from Mike DeMicco <mfdemicco@gmail.com> --- (In reply to Martin Wilck from comment #61)

I'm wondering if the strace in comment 35 is a red herring. The config space is obviously readable just fine. This is just a bridge, so my musings about VPD in comment 43 don't apply here, I suppose.

I pretty much out of ideas here. J�rg?

This is the limited contents of the directory where the crash occurs when read: mike@mike-pc:~$ ls /sys/devices/pci0000:00/ 0000:00:00.0 0000:00:10.0 0000:00:13.0 0000:00:15.0 0000:00:1a.7 0000:00:1c.3 0000:00:1d.2 0000:00:1f.2 PNP0C14:00 0000:00:01.0 0000:00:10.1 0000:00:14.0 0000:00:1a.0 0000:00:1b.0 0000:00:1c.4 0000:00:1d.7 0000:00:1f.3 power 0000:00:02.0 0000:00:11.0 0000:00:14.1 0000:00:1a.1 0000:00:1c.0 0000:00:1d.0 0000:00:1e.0 firmware_node uevent 0000:00:03.0 0000:00:11.1 0000:00:14.2 0000:00:1a.2 0000:00:1c.1 0000:00:1d.1 0000:00:1f.0 pci_bus waiting_for_supplier Perhaps it's looking for a file (config?) that isn't there and crashes when it isn't found? Why can I execute "udevadm info -a /dev/block/8:16" as a user, and no crash occurs yet when done as root, the computer crashes? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1200461 http://bugzilla.opensuse.org/show_bug.cgi?id=1200461#c71 Mike DeMicco <mfdemicco@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |SHIP_STOPPER? --- Comment #71 from Mike DeMicco <mfdemicco@gmail.com> --- (In reply to Jiri Slaby from comment #70)

(In reply to Franck Bui from comment #58)

...

or maybe simply try to dump the config attribute with dd once with "bs=4096" and once with "bs=4097" ?

This was buried and not tested, right? But it still makes sense to test...

i.e. is there any difference: strace dd if=config bs=4096 of=/dev/null # should not hang strace dd if=config bs=4097 of=/dev/null # might hang ?

config is the same you passed to cat.

Neither of those commands causes a hang. -- You are receiving this mail because: You are on the CC list for the bug.