www.makemkv.com

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)

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.

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.

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–

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?

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.

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

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.

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?

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

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.

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