From: trussell@cwis.unomaha.edu (Tim Russell) Subject: Re: 0.97pl4 breaks SCSI extended partition code Date: Wed, 9 Sep 1992 03:14:54 GMT
ctne_ltd@uhura.cc.rochester.edu (Chris Newbold) writes:
>Maybe Drew would like to look into this as a generic SCSI problem? I don;t
>know how far off the much-awaited version 2 of the SCSI drivers are, but
>maybe this is a quick-fix.
Tonight I did lots of printk()'ing and #define DEBUG'ing and came up
with the reason my system at least won't read extended partitions.
The problem is in kernel/blk_drv/ll_rw_block.c, in function make_request().
The chain of execution is: extended_partition() calls bread() with the dev#
of the extended partition, block 0, size 1024. bread() calls ll_rw_block()
with READ, which calls make_request().
On about line 155 of ll_rw_block.c (in 0.97pl4 anyway), this if statement
gets executed:
if (blk_size[major])
if (blk_size[major][MINOR(bh->b_dev)] < (sector + count)>>1) {
bh->b_dirt = bh->b_uptodate = 0;
return;
}
and that's all she wrote, bread ends up falling through to returning an error.
Being new to Linux kernel hacking, I'm not exactly positive what's going
on here, but it doesn't seem to have anything to do with the SCSI code per
se to me. I enabled DEBUG in sd.c and never got any messages at all during
the extended_partition processing, so it isn't even getting down to issuing
a request to the SCSI driver, the problem is up in the buffer code.
Is this code to deal with variable block sizes that was added recently?
That would explain some things. I'm going to grab plain 0.97 if I can find
it and see, since I believe that's nearly the last version I got to work on
my system.