DriveSetup hangs (in the kernel) with an unpopulated card reader present

[LSS37040]

I have a SD/MMC/MS card reader on my case that is connected to the motherboard (Asrock X570 Taichi Razer Edition) via USB header. When the card reader is unpopulated (empty), DriveSetup would not function correctly.

As of hrev55443, it takes about several minutes to show the main screen and even after that DriveSetup window looks totally frozen. I can't do anything with it, such as scrolling down to see how an empty card reader would look like, as well as closing the window. In some cases I get a vm_page_fault KDL (like this: https://dev.haiku-os.org/attachment/ticket/16794/IMG_20210921_204639.jpg).

As this appears to be caused by something different from #16794, this new ticket is created as a follow-up. For now the workaround would be to populate the card reader whenever I need to use DriveSetup (using a SD card inserted to the reader as installation medium would also do).

[waddlesplash]

This is definitely a kernel-space issue of some kind, either in the USB disk driver or somewhere else in the storage layers.

[pulkomandy]

Is there anything happening in the syslog while this happens? I assume the usb_disk driver is trying to open the device and not detecting correctly that there is no media in it.

[LSS37040]

How should I access syslog, especially when I'm inside a KDL?

I'm still new to this...

Not to mention that the usb_keyboard debugger add-on still needs to be disabled in this case, or the system would hang with a few white lines when it KDLs.

[pulkomandy]

from inside KDL you can use the "syslog" command to show the syslog.

Before it crashes, you can do this:

• Open a Terminal and run tail -f /var/log/syslog
• Run DriveSetup

See if anything shows up in the Terminal.

[LSS37040]

DriveSetup KDL and syslog.

[LSS37040]

Attached a screenshot with the KDL and the syslog.

The syslog did mention some transaction errors when the SD card slot was unpopulated.

[pulkomandy]

(sorry, edited the wrong ticket)

[pulkomandy]

The kernel stacktrace has open_vnode calling LegacyDevice::Open. I'm a bit confused, because as far as I can see, the only legacy driver we still have is the PS2 keyboard/mouse driver (I searched for calls of devfs_publish_device using a "hooks" argument, are there other places to look for?), and surely this shouldn't be involved in a scan of disk devices.

[korli]

Legacy drivers are the ones which don't use the new driver API: everything except a few in disk/ power/ and input/

[pulkomandy]

Yes, but I don't see the code path where they create a LegacyDevice instance, except for the PS2 one.

Anyway, what seems to happen is, the LegacyDevice instance ends up pointing to a "hooks" structure that doesn't exist anymore, I suspect the device hooks were released from memory because of the USB errors, but the LegacyDevice object still points to the released memory?

[korli]

Replying to pulkomandy:

Yes, but I don't see the code path where they create a LegacyDevice instance, except for the PS2 one.

It happens in legacy_driver_probe(), calling publish_devices() and find_device() on each driver to see if they support the device path.

Anyway, what seems to happen is, the LegacyDevice instance ends up pointing to a "hooks" structure that doesn't exist anymore, I suspect the device hooks were released from memory because of the USB errors, but the LegacyDevice object still points to the released memory?

Quite possible.

[waddlesplash]

Please retest after hrev57051.

[LSS37040]

Sorry for the hiatus.

Tested hrev57146 and can confirm DriveSetup is now working normally regardless of whether my card reader is populated or not.

Though I haven't done any in-depth test, at least the most critical part of the issue can be considered solved, so that now I can at least manage partitions for installing Haiku while my card reader is unpopulated.

Many thanks for the fix.