URGENT for 5.4-R: ATA meister, read this now - 64/32 bits error found - Trouble with ataraid

[Søren Schmidt]

João Carlos Mendes Luís wrote:
> 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