> Now, for the latest round of tests. Bill, I applied your most recent
> inode.c patches and switched back to the real ide driver from the ide ->
> scsi emulation driver. Here's the debugging output when I try to mount
> after bootup:
>
> Sep 13 21:00:18 splat kernel: isofs_read_super: last session start=0
> Sep 13 21:00:20 splat kernel: isofs_read_super: read block=32, blksize=1024
> Sep 13 21:00:20 splat kernel: isofs_read_super: saving pri, pri_bh=c3a06740, pri=c34c0400
> Sep 13 21:00:20 splat kernel: isofs_read_super: read block=34, blksize=1024
> Sep 13 21:00:20 splat kernel: isofs_read_super: read block=36, blksize=1024
> Sep 13 21:00:20 splat kernel: isofs_read_super: using pri=c34c0400, got rootp=c34c049c
> Sep 13 21:00:20 splat kernel: Max size:326502 Log zone size:2048
> Sep 13 21:00:20 splat kernel: First datazone:39 Root inode number:79872
> Sep 13 21:00:20 splat kernel: isofs_read_super: releasing bh=c3a06740
> Sep 13 21:00:20 splat kernel: ISOFS: Forcing new log zone size:2048
Blocksize has been changed ...
> Sep 13 21:00:21 splat kernel: hdd: DMA disabled
> Sep 13 21:00:21 splat kernel: hdd: dma error: status=0x58 { DriveReady SeekComplete DataRequest }
> Sep 13 21:00:21 splat kernel: hdd: ATAPI reset complete
> Sep 13 21:00:21 splat kernel: ATAPI device hdd:
> Sep 13 21:00:21 splat kernel: Error: Unit attention -- (Sense key=0x06)
> Sep 13 21:00:21 splat kernel: Power on, reset or bus device reset occurred --
The next operation after changing the device blocksize is to read the
root inode, so I would guess that this read somehow gets lost in the DMA
reset.
The changes in the isofs patch of 102 wouldn't have changed the order or
number of reads, but by keeping the buffer used for the primary
descriptor rather than releasing it, it's possible that the _physical
addresses_ used for the read buffers could have changed. (I.e.
subsequent reads could have reused the first buffer, instead of getting
a new one, though this seems unlikely.)
It looks like the interesting part is to understand why the DMA is being
reset in this case, and what happens to the pending read request.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html