Due to a bug in Linux kernel messages
-
- Posts: 9
- Joined: Mon Mar 18, 2013 4:05 pm
Due to a bug in Linux kernel messages
Messages like these, "Device '/dev/sr3' is partially inaccessible due to a bug in Linux kernel", would be more useful if they had the actual bug number associated to it.
I seem to be getting these a lot. Not to mention I get them intermittently for the same disks. (eg: some times a reboot and they work flawlessly. Other times I get errors like the above and everything slows to a crawl)
I seem to be getting these a lot. Not to mention I get them intermittently for the same disks. (eg: some times a reboot and they work flawlessly. Other times I get errors like the above and everything slows to a crawl)
-
- Posts: 4070
- Joined: Wed Nov 26, 2008 2:26 am
- Contact:
Re: Due to a bug in Linux kernel messages
This is Linux. If the problem doesn't affect kernel developers directly then it doesn't exist. There is no bug number.MikeyCarter wrote:Messages like these, "Device '/dev/sr3' is partially inaccessible due to a bug in Linux kernel", would be more useful if they had the actual bug number associated to it.
I seem to be getting these a lot. Not to mention I get them intermittently for the same disks. (eg: some times a reboot and they work flawlessly. Other times I get errors like the above and everything slows to a crawl)
Re: Due to a bug in Linux kernel messages
Correct. Unlike Windows, for me, you have to search for almost everything. Good thing is that with the error message that we get, we have plenty of resource to check.
Mistakes are learning tools. ![Image](https://imagicon.info/cat/13-25/1.gif)
![Image](https://imagicon.info/cat/13-25/1.gif)
Re: Due to a bug in Linux kernel messages
Code: Select all
Device '/dev/sr0' is partially inaccessible due to a bug in Linux kernel (it reports invalid block device size). This can be worked around, but read speed may be very slow.
Read speed is around 2.2X. I did numerous searches for this bug, but came up empty. The optical device (& mount) appears to be fine, and there are no particular messages in the syslog to indicate what the problem might be; apart from accessing beyond end of device–log entries included below.
Since it sounds like it might be a simple fix for it I would very much appreciate any pointers.
Relevant parts of syslog–
Code: Select all
[Wed Aug 14 21:00:55 2013] attempt to access beyond end of device
[Wed Aug 14 21:00:55 2013] sr0: rw=0, want=94397116, limit=2097151
[Wed Aug 14 21:00:55 2013] attempt to access beyond end of device
[Wed Aug 14 21:00:55 2013] sr0: rw=0, want=94397092, limit=2097151
[Wed Aug 14 21:01:02 2013] attempt to access beyond end of device
[Wed Aug 14 21:01:02 2013] sr0: rw=0, want=59748076, limit=2097151
[Wed Aug 14 21:01:02 2013] attempt to access beyond end of device
[Wed Aug 14 21:01:02 2013] sr0: rw=0, want=59748052, limit=2097151
[Wed Aug 14 21:01:11 2013] attempt to access beyond end of device
[Wed Aug 14 21:01:11 2013] sr0: rw=0, want=94397092, limit=2097151
[Wed Aug 14 21:02:12 2013] UDF-fs: Partition marked readonly; forcing readonly mount
-
- Posts: 4070
- Joined: Wed Nov 26, 2008 2:26 am
- Contact:
Re: Due to a bug in Linux kernel messages
Unfortunately, I have no idea where the bug is. Even the syslog entires show that the block device size is incorrect, even for a single-layer BD disc. Are syslog entries caused by MakeMKV or just by mounting the disc?
Re: Due to a bug in Linux kernel messages
I believe the error occurred when MakeMKV was scanning the disc. When I try to reproduce the behavior today however; I cannot. Tried with multiple discs in addition to the original one which failed yesterday. (And no, the system had not been booted in the meantime.)
The curious thing is that the disc ripped fine–albeit at a paltry 2.2X speed. This speed is consistent with the speed I get with other discs and seems to be a limitation with the driver (or firmware/riplock etc.) that this particular drive is using. For the record, the drive is a slimline "laptop" drive, Samsung Blu-Ray Writer SN-506AB (shows up as TSST BDDVDW SN-506AB in the syslog). Compared to my other BD-ROM (which usually rips at 6-7X speed) it is terribly slow)
Unsure if this is a common issue as most drives should work with the standard ATAPI CD-CDROM driver on Linux.
The curious thing is that the disc ripped fine–albeit at a paltry 2.2X speed. This speed is consistent with the speed I get with other discs and seems to be a limitation with the driver (or firmware/riplock etc.) that this particular drive is using. For the record, the drive is a slimline "laptop" drive, Samsung Blu-Ray Writer SN-506AB (shows up as TSST BDDVDW SN-506AB in the syslog). Compared to my other BD-ROM (which usually rips at 6-7X speed) it is terribly slow)
Unsure if this is a common issue as most drives should work with the standard ATAPI CD-CDROM driver on Linux.
Re: Due to a bug in Linux kernel messages
Drag0nFly wrote:I believe the error occurred when MakeMKV was scanning the disc. When I try to reproduce the behavior today however; I cannot. Tried with multiple discs in addition to the original one which failed yesterday. (And no, the system had not been booted in the meantime.)
The curious thing is that the disc ripped fine–albeit at a paltry 2.2X speed. This speed is consistent with the speed I get with other discs and seems to be a limitation with the driver (or firmware/riplock etc.) that this particular drive is using. For the record, the drive is a slimline "laptop" drive, Samsung Blu-Ray Writer SN-506AB (shows up as TSST BDDVDW SN-506AB in the syslog). Compared to my other BD-ROM (which usually rips at 6-7X speed) it is terribly slow)
Unsure if this is a common issue as most drives should work with the standard ATAPI CD-CDROM driver on Linux.
I think it is just a bug for certain discs.. I have done quite a few and only saw that error once so far....
Re: Due to a bug in Linux kernel messages
If this really is a kernel bug, then it should be filed at https://bugzilla.kernel.org/ by someone who is experiencing it (i.e., has the most available information) so that the kernel developers at least know there is a problem.
Re: Due to a bug in Linux kernel messages
Well, I've just got this message, and since I've got it on an internal libata-accessible drive but not on two USB drives we can be fairly sure that whatever this bug is, it's in libata, since USB mass storage evades it. libata definitely does not get block sizes wrong in the general case, so this must be specific to optical drives alone.
But, really, if I'm going to fix it I need more information from Mike, and preferably a replication recipe that I can compile and see go wrong and hopefully figure out what's wrong where with. Is this the logical or physical block size? What's telling you this? One presumes READ CAPACITY (16)...
-- N., feels like some kernel hacking this weekend during the long long hours while a glibc test cycle runs yet again. what else are weekends for?
But, really, if I'm going to fix it I need more information from Mike, and preferably a replication recipe that I can compile and see go wrong and hopefully figure out what's wrong where with. Is this the logical or physical block size? What's telling you this? One presumes READ CAPACITY (16)...
-- N., feels like some kernel hacking this weekend during the long long hours while a glibc test cycle runs yet again. what else are weekends for?
Re: Due to a bug in Linux kernel messages
I'm getting this error on every rip:
Rip speed is averaging 1.2x this was not a problem until I cleaned my hard drives and did a clean install of Arch Linux. I have the latest version of the firmware installed. Curiously I also have makemkv installed on my Windows 10 partition where I've seen no such errors
Code: Select all
Device '/dev/sr1' is partially inaccessible due to a bug in Linux kernel (it reports invalid block device size). This can be worked around, but read speed may be very slow
-
- Posts: 4070
- Joined: Wed Nov 26, 2008 2:26 am
- Contact:
Re: Due to a bug in Linux kernel messages
It happens on block device layer, above SCSI, on /dev/srX. BLKGETSIZE64 ioctl returns invalid size (could be from a previously-mounted disc), reads beyond this size always return error. MakeMKV in this case issues raw SCSI read command for all blocks beyond the "fake end". These commands obviously succeed but are somewhat slower than regular block device read.NullNix wrote:Well, I've just got this message, and since I've got it on an internal libata-accessible drive but not on two USB drives we can be fairly sure that whatever this bug is, it's in libata, since USB mass storage evades it. libata definitely does not get block sizes wrong in the general case, so this must be specific to optical drives alone.
But, really, if I'm going to fix it I need more information from Mike, and preferably a replication recipe that I can compile and see go wrong and hopefully figure out what's wrong where with. Is this the logical or physical block size? What's telling you this? One presumes READ CAPACITY (16)...
-- N., feels like some kernel hacking this weekend during the long long hours while a glibc test cycle runs yet again. what else are weekends for?
-
- Posts: 2
- Joined: Wed Jun 05, 2019 8:35 pm
Re: Due to a bug in Linux kernel messages
I just saw this bug report on bugzilla.kernel.org that references the issue and mentions MakeMKV:
- https://bugzilla.kernel.org/show_bug.cgi?id=194965
- https://bugzilla.kernel.org/show_bug.cgi?id=194965