www.makemkv.com

MakeMKV support forum
It is currently Fri Jul 20, 2018 9:01 am

All times are UTC




Post new topic Reply to topic  [ 11 posts ] 
Author Message
PostPosted: Fri Jun 21, 2013 8:33 pm 
Offline

Joined: Mon Mar 18, 2013 4:05 pm
Posts: 9
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)


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 30, 2013 6:47 am 
Offline

Joined: Wed Nov 26, 2008 2:26 am
Posts: 3386
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.


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 06, 2013 12:55 am 
Offline

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 14, 2013 7:25 pm 
Offline

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 18, 2013 6:12 am 
Offline

Joined: Wed Nov 26, 2008 2:26 am
Posts: 3386
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?


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 18, 2013 7:26 pm 
Offline

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 26, 2015 12:19 am 
Offline

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 03, 2015 1:54 am 
Offline

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 05, 2016 12:25 am 
Offline

Joined: Sat Jan 31, 2015 12:57 pm
Posts: 14
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?


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 03, 2018 7:09 pm 
Offline

Joined: Sun Jan 28, 2018 5:42 pm
Posts: 2
I'm getting this error on every rip:

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 04, 2018 12:16 am 
Offline

Joined: Wed Nov 26, 2008 2:26 am
Posts: 3386
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group