[Bug 49788] New: mountmgr is no longer detecting SCSI devices
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(a)winehq.org Reporter: winebugzilla(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 TasosSah <winebugzilla(a)tasossah.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winebugzilla(a)tasossah.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |cdavis5x(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=31592 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 --- Comment #1 from Esme Povirk <madewokherd(a)gmail.com> --- It seems like the drives are detected, there simply wasn't any code added to mountmgr to populate that registry key. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 --- Comment #2 from Esme Povirk <madewokherd(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 --- Comment #3 from Esme Povirk <madewokherd(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 --- Comment #4 from Saulius K. <saulius2(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 --- Comment #5 from TasosSah <winebugzilla(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 --- Comment #6 from TasosSah <winebugzilla(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 --- Comment #7 from TasosSah <winebugzilla(a)tasossah.com> --- Created attachment 68658 --> https://bugs.winehq.org/attachment.cgi?id=68658 wnaspi32 sysfs patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49788 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |fgouget(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla