[Bug 49615] New: since 5.5 : fail DVD access without any need or cause.
https://bugs.winehq.org/show_bug.cgi?id=49615 Bug ID: 49615 Summary: since 5.5 : fail DVD access without any need or cause. Product: Wine-staging Version: 5.13 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winebugs(a)evolution-hosting.eu CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 67801 --> https://bugs.winehq.org/attachment.cgi?id=67801 dmesg output OS: Fedora 31 ARCH: X86_64 CPU: FX8350 On wine-staging start, the attached log is produced, everytime a programm is started and sometimes in conjunction with NVRM Xid 31/32 errors for Nvidia gfx car. This can be observed since wine 5.5 . 3d party extension: DXVK packages installed: mingw32-wine-gecko-2.47.1-1.fc31.noarch mingw64-wine-gecko-2.47.1-1.fc31.noarch wine-5.10-1.fc31.i686 wine-5.10-1.fc31.x86_64 wine-alsa-5.10-1.fc31.i686 wine-alsa-5.10-1.fc31.x86_64 wine-arial-fonts-5.10-1.fc31.noarch wine-capi-5.10-1.fc31.i686 wine-capi-5.10-1.fc31.x86_64 wine-cms-5.10-1.fc31.i686 wine-cms-5.10-1.fc31.x86_64 wine-common-5.10-1.fc31.noarch wine-core-5.10-1.fc31.i686 wine-core-5.10-1.fc31.x86_64 wine-courier-fonts-5.10-1.fc31.noarch wine-debuginfo-2.10-1.fc25.x86_64 wine-desktop-5.10-1.fc31.noarch wine-filesystem-5.10-1.fc31.noarch wine-fixedsys-fonts-5.10-1.fc31.noarch wine-fonts-5.10-1.fc31.noarch wine-ldap-5.10-1.fc31.i686 wine-ldap-5.10-1.fc31.x86_64 wine-marlett-fonts-5.10-1.fc31.noarch wine-mono-5.0.0-1.fc31.noarch wine-ms-sans-serif-fonts-5.10-1.fc31.noarch wine-openal-5.10-1.fc31.i686 wine-openal-5.10-1.fc31.x86_64 wine-opencl-5.10-1.fc31.i686 wine-opencl-5.10-1.fc31.x86_64 wine-pulseaudio-5.10-1.fc31.i686 wine-pulseaudio-5.10-1.fc31.x86_64 wine-small-fonts-5.10-1.fc31.noarch wine-staging64-5.13-1.3.x86_64 wine-staging-common-5.13-1.3.i686 wine-symbol-fonts-5.10-1.fc31.noarch wine-systemd-5.10-1.fc31.noarch wine-system-fonts-5.10-1.fc31.noarch wine-tahoma-fonts-5.10-1.fc31.noarch wine-tahoma-fonts-system-5.10-1.fc31.noarch wine-times-new-roman-fonts-5.10-1.fc31.noarch winetricks-20200412-1.fc31.noarch wine-twain-5.10-1.fc31.i686 wine-twain-5.10-1.fc31.x86_64 wine-wingdings-fonts-5.10-1.fc31.noarch -- 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=49615 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware, regression --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- Please run a regression test: https://wiki.winehq.org/Regression_Testing -- 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=49615 --- Comment #2 from winebugs(a)evolution-hosting.eu <winebugs(a)evolution-hosting.eu> --- If your regression staging doc is uptodate, i'm unable to do this, as step 1 is removing any upstream or obsolete patches, how shall one now 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=49615 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- I'm... not sure what this is about, exactly. When a prefix is started, Wine does a brief scan of storage devices so that they can be passed through to Win32 applications. In Wine 5.6 this scan was extended in some cases to try to read e.g. DVD labels. I'm not sure if those errors in dmesg are actually symptomatic of anything, but I suspect that if they are, it's a kernel or hardware problem, that's only now been "exposed" since Wine is trying to read from the device. But unless there are visible errors, I don't think there's a valid bug here. -- 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=49615 --- Comment #4 from winebugs(a)evolution-hosting.eu <winebugs(a)evolution-hosting.eu> --- "blk_update_request: I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0" This is a READ on a Device that is not ready to be read from. People call this a bug. -- 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=49615 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|since 5.5 : fail DVD access |Device read errors logged |without any need or cause. |in dmesg when running wine | |commands with empty CD/DVD | |drive, since 5.5 Product|Wine-staging |Wine Component|-unknown |mountmgr.sys CC| |o.dierick(a)piezo-forte.be --- Comment #5 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, I confirm I get errors in dmesg too when I run 'winecfg' while the CD/DVD drive is empty. When there is a disk in the drive nothing gets logged in dmesg. Not a wine-staging bug, it happens with vanilla wine too; Component is mountmgr.sys; The bug title is misleading. → Bug updated. Still needs a regression test. Regards. -- 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=49615 --- Comment #6 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to winebugs(a)evolution-hosting.eu from comment #4)
"blk_update_request: I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0"
This is a READ on a Device that is not ready to be read from. People call this a bug.
Can you please expand on this, or provide citation? -- 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=49615 jswinebz(a)kanargh.org.uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jswinebz(a)kanargh.org.uk --- Comment #7 from jswinebz(a)kanargh.org.uk --- Created attachment 69843 --> https://bugs.winehq.org/attachment.cgi?id=69843 cdrom access demo (I've just noticed this myself.) wine is asking to read from a disc which does not exist (none is inserted into the drive.) The request is passed down to the drive, which quite correctly throws back an error. (What else could it do?) This error is logged to dmesg - often such messages are useful and interesting. Most causes of such errors are things like actual surface corruption. (Or attempting to access a protected DVD without first authenticating.) This error - not so much as it is due to an obviously unsatisfiable but perfectly avoidable request from the application. Note that if you just try to open the device in the usual way, the open attempt fails immediately with ENOMEDIUM, but no error is logged to dmesg. You have to specifically request O_NONBLOCK (an odd thing to do for a disc device, since they don't really do non-blocking I/O) to defeat that check. You are then expected to proceed very carefully... (Since wine triggers a kernel message, it is clearly doing the former and not the latter.) You can use such access to query the drive itself for capabilities and current status. You shouldn't proceed to disc access unless the drive reports this is possible. Attached is a short program that demonstrates the correct sequence. $ g++ cdromstatus.cpp -o cdromstatus $ ./cdromstatus 0 open("/dev/sr0") returned error (123) No medium found $ ./cdromstatus 1 open("/dev/sr0") returned fd 3 $ ./cdromstatus 2 open("/dev/sr0") returned fd 3 read() returned error (5) Input/output error $ ./cdromstatus 3 open("/dev/sr0") returned fd 3 CDROM_DRIVE_STATUS returned (1) CDS_NO_DISC $ And with a disc inserted: $ ./cdromstatus 3 open("/dev/sr0") returned fd 3 CDROM_DRIVE_STATUS returned (4) CDS_DISC_OK read() returned 2048 bytes $ -- 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=49615 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wamo(a)tuta.io --- Comment #8 from Zeb Figura <z.figura12(a)gmail.com> --- *** Bug 54340 has been marked as a duplicate of this bug. *** -- 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=49615 --- Comment #9 from jswinebz(a)kanargh.org.uk --- On bug 54340 you said:
Duplicate of bug 49615, but it's still not clear to me that Wine is actually doing anything wrong here.
How is it not clear from the demo code attached above that there is a clear expectation from the Linux kernel about how applications should behave and Wine is violating that? An application should either open the drive device special file in the normal way, in which case it will get an immediate error without any kernel logging in the case where no disc is inserted. *Or* it can open the device O_NONBLOCK if it wants to query device capabilities even in the absence of a disc. In that case it is specifically expected to query whether a disc is in fact inserted *before* proceeding to a data read call, if it wants to do so. If it makes that query, and there is a disc inserted, and it then does a read, the read will succeed, again without kernel logging. Only if it doesn't make that query, or ignores the return value, and attempts the read anyway without a disc inserted, will the kernel log the attempt. That distinction should be a very clear indication that that is *NOT* what applications are expected to do. And the disc-present query is utterly trivial to do - the code is right there in that attachment - I really don't understand how you could have any objection to incorporating it. (And thus clear a whole bunch of obnoxious spam from the kernel logs which get in the way of diagnosing other issues.) -- 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=49615 --- Comment #10 from jswinebz(a)kanargh.org.uk --- Just for a sense of scale here: My dmesg buffer currently contains 2890 lines, which right now go back to the last system boot. The boot process itself takes 1083 lines, at which point on most machines dmesg goes pretty quiet unless something is actually going wrong, or some noteworthy hardware change occurs. Of the remainder, 278 lines come from the nvidia binary driver which I consider spammy as hell. *1427* lines come from this issue alone. That leaves just 102 lines for "normal system operation", which is mostly USB device insertion/removal notifications which are expected, some systemd journal rotation notification (which I think is misguided of them but still small volume) and a couple of application segfaults. Now you might say that's not a large number of lines, but the dmesg ring buffer is a limited resource and eventually old records get pushed out which it would be nice to avoid if it's not necessary (which in this case it definitely isn't), and wine is still accounting for nearly 4 times everything else on my hardware, and 14 times everything else on a system without the nvidia driver and a user who isn't constantly re-inserting USB devices. -- 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=49615 --- Comment #11 from jswinebz(a)kanargh.org.uk --- Created attachment 73917 --> https://bugs.winehq.org/attachment.cgi?id=73917 don't try to read() from empty cdrom drives ...and it's a bit easier than that even. Turns out that we already use an ioctl during the enumeration which does return ENOMEDIUM(123). That gets translated by ntdll to STATUS_NO_MEDIA_IN_DEVICE (0xc0000013), which is translated to userspace as ERROR_NOT_READY (21). But then that gets ignored during the enumeration which just assumes that any error reading the TOC must mean it's a harddrive instead - or at least that it's allowed to try reading the superblock to find out. This patch catches that case and results in a blissfully silent wine startup - at least as far as the kernel log goes. -- 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=49615 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Fixed by SHA1| |90d50bc611b71688287d0ddf28c | |5babcb8e84e98 Resolution|--- |FIXED --- Comment #12 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Fixed by https://gitlab.winehq.org/wine/wine/-/commit/90d50bc611b71688287d0ddf28c5bab... -- 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=49615 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #13 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 8.1. -- 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=49615 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |8.0.x -- 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=49615 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|8.0.x |--- --- Comment #14 from Michael Stefaniuc <mstefani(a)winehq.org> --- Removing the 8.0.x milestone from bug fixes included in 8.0.1. -- 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