Page 1 of 1

Due to a bug in Linux kernel messages

Posted: Fri Jun 21, 2013 8:33 pm
by MikeyCarter
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

Posted: Sun Jun 30, 2013 6:47 am
by mike admin
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)
This is Linux. If the problem doesn't affect kernel developers directly then it doesn't exist. There is no bug number.

Re: Due to a bug in Linux kernel messages

Posted: Sat Jul 06, 2013 12:55 am
by austingrd
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.

Re: Due to a bug in Linux kernel messages

Posted: Wed Aug 14, 2013 7:25 pm
by Drag0nFly

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.
I'm also getting this on a newly-compiled 0.8.4 version running the most recent 'Quantal Quetzal' kernel (3.8.0-27-generic #40-Ubuntu) on Mint 15.
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

Re: Due to a bug in Linux kernel messages

Posted: Sun Aug 18, 2013 6:12 am
by mike admin
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

Posted: Sun Aug 18, 2013 7:26 pm
by Drag0nFly
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.

Re: Due to a bug in Linux kernel messages

Posted: Fri Jun 26, 2015 12:19 am
by lotw01
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

Posted: Mon Aug 03, 2015 1:54 am
by kevmitch
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

Posted: Sat Mar 05, 2016 12:25 am
by NullNix
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?

Re: Due to a bug in Linux kernel messages

Posted: Sat Feb 03, 2018 7:09 pm
by wchouser3
I'm getting this error on every rip:

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
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

Re: Due to a bug in Linux kernel messages

Posted: Sun Feb 04, 2018 12:16 am
by mike admin
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?
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.

Re: Due to a bug in Linux kernel messages

Posted: Wed Jun 05, 2019 8:42 pm
by 110879e14603
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