https://bugs.winehq.org/show_bug.cgi?id=49788
Bug ID: 49788 Summary: mountmgr is no longer detecting SCSI devices Product: Wine Version: 5.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mountmgr.sys Assignee: wine-bugs@winehq.org Reporter: winebugzilla@tasossah.com Regression SHA1: 19549d11a72f63efe0d689374446a56a68264a1f Distribution: ---
Created attachment 68104 --> https://bugs.winehq.org/attachment.cgi?id=68104 regedit screenshot
Commit 19549d11a72f63efe0d689374446a56a68264a1f switched to using udisks2 to detect devices, however this no longer detects SCSI devices. This results in ASPI_GetNumControllers always returning 0, and ASPI applications not detecting any optical drives.
Compiling wine one commit before the one mentioned above (8388ea840fedbb9b646213a26cd59ceb3a48680b) restores the ability to detect and use SCSI devices.
Tested on two different Ubuntu 20.04 installations, both with fully functional udisks2.
Steps to reproduce: Start up wine regedit Navigate to HKLM\Hardware\DEVICEMAP\Scsi Observe that it is empty
When functioning correctly, it should report all SCSI devices, including hard disks and optical drives. In general, all devices that exist in /proc/scsi/scsi should show up in the registry.
https://bugs.winehq.org/show_bug.cgi?id=31592 was opened presumably to move away from /proc/scsi, however it is now a regression.
https://bugs.winehq.org/show_bug.cgi?id=49788
TasosSah winebugzilla@tasossah.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winebugzilla@tasossah.com
https://bugs.winehq.org/show_bug.cgi?id=49788
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |cdavis5x@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=49788
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=31592
https://bugs.winehq.org/show_bug.cgi?id=49788
--- Comment #1 from Esme Povirk madewokherd@gmail.com --- It seems like the drives are detected, there simply wasn't any code added to mountmgr to populate that registry key.
https://bugs.winehq.org/show_bug.cgi?id=49788
--- Comment #2 from Esme Povirk madewokherd@gmail.com --- Correction, the code was added to do this, but it's only called from libhal code so it might as well not be there.
https://bugs.winehq.org/show_bug.cgi?id=49788
--- Comment #3 from Esme Povirk madewokherd@gmail.com --- Patch sent: https://www.winehq.org/pipermail/wine-devel/2020-November/176663.html
However, this doesn't fully fix the regression. I'm told that udisks2 does not report a /dev/sgX device, and that wnaspi32 depends on this.
Since we need Linux-specific logic somewhere to locate the correct 'sg' driver device, and it's wnaspi32's Linux-specific code that needs it, that logic should be added to wnaspi32 IMO.
https://bugs.winehq.org/show_bug.cgi?id=49788
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=49788
--- Comment #4 from Saulius K. saulius2@gmail.com --- (In reply to Esme Povirk from comment #3)
that udisks2 does not report a /dev/sgX device, and that wnaspi32 depends on this.
But maybe it should? I am not familiar with udisks2, thus my curiosity.
Since we need Linux-specific logic somewhere to locate the correct 'sg' driver device, and it's wnaspi32's Linux-specific code that needs it, that logic should be added to wnaspi32 IMO.
Ooor... it could be added to udisks2 too in case it's bug of udisks2, no?
https://bugs.winehq.org/show_bug.cgi?id=49788
--- Comment #5 from TasosSah winebugzilla@tasossah.com --- (In reply to Esme Povirk from comment #3)
Patch sent: https://www.winehq.org/pipermail/wine-devel/2020-November/176663.html
However, this doesn't fully fix the regression. I'm told that udisks2 does not report a /dev/sgX device, and that wnaspi32 depends on this.
Since we need Linux-specific logic somewhere to locate the correct 'sg' driver device, and it's wnaspi32's Linux-specific code that needs it, that logic should be added to wnaspi32 IMO.
First of all, thank you for the patch.
Only easy way I see of associating the info in regedit reported by mountmgr with that patch is to open up /sys/bus/scsi/devices and match the scsi bus and id, and then opening the "generic" symlink. I'll try making a patch for wnaspi32.
Additionally, the submitted patch only reports optical drives on my system, and with a generic name. In this case DeviceName is "CdRom1". Fixed disks are also not reported at all.
There's also a new blank key called "Initiator Id 255" which wasn't there before.
(In reply to Saulius K. from comment #4)
(In reply to Esme Povirk from comment #3)
that udisks2 does not report a /dev/sgX device, and that wnaspi32 depends on this.
But maybe it should? I am not familiar with udisks2, thus my curiosity.
Since we need Linux-specific logic somewhere to locate the correct 'sg' driver device, and it's wnaspi32's Linux-specific code that needs it, that logic should be added to wnaspi32 IMO.
Ooor... it could be added to udisks2 too in case it's bug of udisks2, no?
Ideally, I think so, yeah, but I feel like a lot of existing systems won't get an updated version of udisks2 if they add support for it. I think there should be a fallback.
The original report was about Debian not having /proc/scsi/scsi, and in the process of attempting to fix it, if I am understanding this correctly, the code was added to libhal, which is deprecated, and udisks2 doesn't support this.
https://bugs.winehq.org/show_bug.cgi?id=49788
--- Comment #6 from TasosSah winebugzilla@tasossah.com --- A few notes. It's not as easy as I thought to get the sg path from /sys/bus/scsi.
At first I assumed there would be a symlink to it, but this did not seem to be the case. It is possible to parse /sys/bus/scsi/devices/xx:0:x:0/generic/uevent to extract the DEVNAME=sgX, which doesn't seem like a great idea.
One could otherwise call readlink on /sys/bus/scsi/devices/xx:0:x:0/generic which is a symlink to a path that contains "sgX" in its name, but this is quite a terrible idea in my opinion, since we'd need to parse the path returned.
At that point, I assumed I could use libudev to go through all the devices and add a match for scsi bus, target id, and logical unit, but it appears udev did not have this information. (Checked using udevadm info -a /sys/devices/platform/[...]/scsi_generic/sgX, which is the path returned when adding a udev enum match for the scsi_generic subsystem.)
I resorted to building the path manually and calling udev to return the sgX path. Perhaps there is a better way to do this, but I was not successful in finding it.
https://bugs.winehq.org/show_bug.cgi?id=49788
--- Comment #7 from TasosSah winebugzilla@tasossah.com --- Created attachment 68658 --> https://bugs.winehq.org/attachment.cgi?id=68658 wnaspi32 sysfs patch
https://bugs.winehq.org/show_bug.cgi?id=49788
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |fgouget@codeweavers.com
-
WineHQ Bugzilla