"attempt to access beyond end of device" on ide-scsi+sr_mod in 2.6.0-test3

From: Jakub Bogusz (qboosh_at_pld-linux.org)
Date: 08/15/03

  • Next message: Alan Cox: "Re: 2.6.0test3: scsi/net"
    Date:	Fri, 15 Aug 2003 00:54:37 +0200
    To: linux-kernel@vger.kernel.org
    
    

    Hello,

    I mounted my CDRW disk with isofs through ide-scsi as I used to do
    in Linux 2.4 (drive is CD recorder, and I'm using 2.6 for testing, so
    I haven't changed configuration for direct ATAPI writing).
    I successfully read some files, but when I was trying to read more,
    I/O errors occurred. Kernel said:
    kernel: attempt to access beyond end of device
    kernel: sr0: rw=0, want=315596, limit=307404
    kernel: Buffer I/O error on device sr0, logical block 78898
    kernel: attempt to access beyond end of device
    kernel: sr0: rw=0, want=315600, limit=307404
    kernel: Buffer I/O error on device sr0, logical block 78899
    [...etc., many times...]

    I unmounted and mounted again the same disk and everything was OK
    - I couldn't repeat that errors. That disk contained ~222MB of data.

    But when I inserted _larger_ CD (over 500MB of data) and tried to read
    some files, I/O errors happened again:
    kernel: attempt to access beyond end of device
    kernel: sr0: rw=0, want=1270892, limit=453448
    kernel: Buffer I/O error on device sr0, logical block 317722
    kernel: attempt to access beyond end of device
    kernel: sr0: rw=0, want=1270896, limit=453448
    kernel: Buffer I/O error on device sr0, logical block 317723
    [...]

    But see - now limit matches the _previous_ disk!
    unmounting and mounting the same disk helped again.
    (I've made even more tests to confirm this)

    It seems that kernel updates some device block count too late (after
    some data reads?), remembering count for _previous_ mounted disk, not
    the current one.

    This behaviour is specific for sr_mod and/or ide-scsi.
    When I mounted CD through plain ide-cd, such errors didn't happen.

    PS. please Cc answers to me

    -- 
    Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/
    PLD Linux       http://www.pld-linux.org/
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Alan Cox: "Re: 2.6.0test3: scsi/net"

    Relevant Pages

    • [SLE] JBD error on SLES9
      ... Nov 7 08:08:59 kernel: Buffer I/O error on device sda1, logical block ...
      (SuSE)
    • Re: Software RAID-5 attempt to access beyond end of device...
      ... The reiserfs is on top of an lvm2 on top of a raid5 ... >information that has previously been stored on disk. ... Sep 7 20:32:04 cu kernel: Buffer I/O error on device dm-0, ... PCI: PCI BIOS revision 2.10 entry at 0xf1150, ...
      (Linux-Kernel)
    • Re: Spontaneous reboots
      ... yet I keep experiencing spontaneous reboots and crashes. ... > I have postfix handling mail and use cyrus-imap with virtual ... Page fault while in kernel mode ... > Disk errors: ...
      (freebsd-questions)
    • Re: O_DIRECT question
      ... kick the disk out of the array before the OS ever notices. ... before your app ever notices any I/O error. ... order matters, you can not use fsync, which is one of the reasons why ... Semantics is a question of correct operation, ...
      (Linux-Kernel)
    • athlon-xp + fakeraid regression
      ... The build completes fine, the kernel boots fine, the machine will seem to be fine as long as it remains quiescent. ... At the beginning, just after hitting enter on the make command, one of the ad4 disk light goes on solid for several seconds. ... There is a well known thing where these cheap pata fakeraid cards will try to do ata133 if the drive says it can, when really, even if he drives are new ata133 drives and the cables are new and short and shielded, you still shouldn't try to do ata133 since the spec is too tight and you'll just get bit errors or other failures. ... The fix is use ata100 somehow, either by disabling dma entirely in loader.conf (since you have no more selective option there, and the raid card bios never has an option for controlling pio/dma mode like motherboard bios's have) and then use atacontrol in rc.early to set udma5, or by using disks that can only do ata100 and only advertise ata100 to the controller. ...
      (freebsd-current)