Due to a bug in Linux kernel messages

The place to discuss linux version of MakeMKV
Post Reply
MikeyCarter
Posts: 9
Joined: Mon Mar 18, 2013 4:05 pm

Due to a bug in Linux kernel messages

Post 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)
mike admin
Posts: 4065
Joined: Wed Nov 26, 2008 2:26 am
Contact:

Re: Due to a bug in Linux kernel messages

Post 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.
austingrd
Posts: 49
Joined: Wed Jun 05, 2013 7:14 pm

Re: Due to a bug in Linux kernel messages

Post 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.
Mistakes are learning tools. Image
Drag0nFly
Posts: 15
Joined: Sun May 19, 2013 8:48 pm

Re: Due to a bug in Linux kernel messages

Post 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
mike admin
Posts: 4065
Joined: Wed Nov 26, 2008 2:26 am
Contact:

Re: Due to a bug in Linux kernel messages

Post 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?
Drag0nFly
Posts: 15
Joined: Sun May 19, 2013 8:48 pm

Re: Due to a bug in Linux kernel messages

Post 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.
lotw01
Posts: 8
Joined: Thu Jun 04, 2015 12:25 am

Re: Due to a bug in Linux kernel messages

Post 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....
kevmitch
Posts: 72
Joined: Mon Mar 11, 2013 6:35 am

Re: Due to a bug in Linux kernel messages

Post 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.
NullNix
Posts: 25
Joined: Sat Jan 31, 2015 12:57 pm

Re: Due to a bug in Linux kernel messages

Post 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?
wchouser3
Posts: 2
Joined: Sun Jan 28, 2018 5:42 pm

Re: Due to a bug in Linux kernel messages

Post 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
mike admin
Posts: 4065
Joined: Wed Nov 26, 2008 2:26 am
Contact:

Re: Due to a bug in Linux kernel messages

Post 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.
110879e14603
Posts: 2
Joined: Wed Jun 05, 2019 8:35 pm

Re: Due to a bug in Linux kernel messages

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