Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 24 Dec 2003 01:39:56 -0800 (PST) | From | Andre Hedrick <> | Subject | Re: 2.6.0, SiI3112, md raid1 problem: bio too big device (128 > 15) |
| |
The problem is creating a sane MOD15(bio->table). Where one has to control the FIS out the PHY and prevent a the trailing FIS to be full if it is the last FIS. Where a FIS is 8K, should one have a data segment in the final FIS which fills the FIS, one needs to break and create a new one composed of a 7.5K and 0.5K FIS.
Now in SATA 1.0, there is no control or interface to managing the "raw fis". So this is handled by creating a clever scattergather table.
So if the total transfer has a remainder on the last bh/bio, the a new nent must be created. The description starts to get mangled from now on out :-/
int remainder = MOD15(total transfer in 512b sectors);
NOT the Mickey Mouse fake sectors of 1024b !!!
do { blah_blah(SFF-8038i dma sglist);
if ((total transfer - remainder == current nent) && (the remainder will fill the final nent)) { fill_nent_fill_less_one_sector(); create_new_nent(); fill_nent_with_last_sector(): } } while();
Yeah, this is one of those emails where I need a translator. So read the documents from the working groups.
Cheers,
Andre Hedrick LAD Storage Consulting Group
On Wed, 24 Dec 2003, Jeff Garzik wrote:
> Jim Lawson wrote: > > Hi all, > > > > I am having trouble creating a raid1 array under 2.6.0. I am able to > > create raid0 and raid5 mds, but raid1s fail with "bio too big device hde3 > > (128 > 15)", which doesn't tell me a lot. I can see it's in > > drivers/block/ll_rw_blk.c, right at the boundary with the device driver, > > but I'm not enough of a kernel wonk to find out a lot more. > > > > I'm not sure if this has to do with a kernel bug, a bug in the driver for > > the controller I have (SiI3112, Silicon Image 3112), or the disks I am > > using (Seagate Barracuda 7200.7, 160 GB SATA disks) ... or the combination > > thereof :-) > > > Hum... that's kinda interesting. > > AFAICS, the basic problem is that Silicon Image's sector size limitation > means that md cannot submit stripe-sized bio's as it wishes. > > md does indeed split bio's in raid0, so it makes sense that it works (to > my naive eye). I'm amazed raid5 works, since raid5 appears to hardcode > STRIPE_SIZE. And I don't see splitting code in raid1, so it would make > sense that raid1 would fail. > > In general though, I'm surprised that each block driver has to > reimplement the pain of splitting its own bio's, to conform to the > underlying device. Since bio's can be merged after > generic_make_request(), surely it makes sense to implement bio splitting > -once- in the block layer, rather than in each block driver that has to > care about stackable block devices? > > Jeff > > > > - > 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/ >
- 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/
| ![\](/images/icornerr.gif) |