I think I may have found the problem!!!
Looking at the source code for arstrategy, we can find this:
----------------------------- static void arstrategy(struct bio *bp) { struct ar_softc *rdp = bp->bio_disk->d_drv1; int blkno, count, chunk, lba, lbs, tmplba; int drv = 0, change = 0; caddr_t data; -----------------------------
That is, lba is an int, 32 bits!
Right below, this variable is used into a bio_pblkno, which is defined at <sys/bio.h> as (daddrt_t):
----------------------------- buf1->bp.bio_pblkno = lba; if ((buf1->drive = drv) > 0) buf1->bp.bio_pblkno += rdp->offset; -----------------------------
But note that at the /sys/dev/ata/ata-all.h file, the ata_request.u.ata.lba is defined as (u_int64_t). Also, at <sys/types.h>, (daddr_t) is defined as (__int64_t). These are the data types used at ata-disk.c
BTW: While searching for this bug, I found that a type (u_daddr_t) is defined at <sys/blist.h> as (u_int32_t). I did not care for it right now, but maybe this should be checked also.
Hope I am wrong, but if not, this may be the bug I´ve been chasing since 5.2-R.
To probe further: Should the ata-raid driver be allowed to write the disk at will? I did not even try to mount any partition, but it did overwrote my data. Maybe to update the raid information. I'm not sure, I did not search for this yet.
With a 250G disk you are not even close to using 32bits of LBA space, so thats not your problem. You could just leave ataraid out of your kernel to test if thats whats hurting you.
If you want to take this further you should try out the ATA mkIII patches on http://people.freebsd.org/~sos/ATA as that is my corrections to whats in RELENG_5...
--
-Søren
_______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
