Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Apr 2005 17:59:50 -0300
From:      =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= <jonny@jonny.eng.br>
To:        sos@FreeBSD.org, hackers@freebsd.org
Subject:   URGENT for 5.4-R: ATA meister, read this now - 64/32 bits errorfound - Trouble with ataraid
Message-ID:  <42714EC6.9030105@jonny.eng.br>
In-Reply-To: <42714536.4020703@jonny.eng.br>
References:  <426D6087.7080908@jonny.eng.br> <42714536.4020703@jonny.eng.br>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



João Carlos Mendes Luís wrote:
> Followup to my message with more news.
> 
> It is not a problem with mount_ntfs.  Indeed, it seems to be a problem
> with the ataraid code.
> 
> Today I booted from 5.3RC4 install CD, and mounted NO partition on the
> problem disk.  But this was enough to corrupt the partition again.
> 
> How can I know if the ATA RAID code is LBA48 compatible?  The chipset is
> a Promise 20378, which is supported, in theory.
> 
> João Carlos Mendes Luís wrote:
> 
>>Hi all,
>>
>>    I've just bought a Seagate 250G SATA drive to run in a shared
>>desktop at home.  It should have 3 boot partitions: 16M FreeBSD 5, 16M
>>linux, 32M NTFS for Windows XP.  The remaining wil be formatted with
>>FAT32 to be used as a common data for the 3 operating systems.
>>
>>    Well, everything seemed to be fine.  I copied the FreeBSD partition
>>from the previous installed disk with dump(8), and installed XP from
>>CDs.  But suddenly, the data and NTFS partitions began to disappear.  I
>>don't know exactly what were the steps used to crash the disk, but it
>>happened at least 3 times, after 3 full windows installs (which are not
>>quick, for my sadness).  In the last one I could almost detect it.
>>
>>    I finished the initial windows instalation, and booted into FreeBSD
>>to make sure the NTFS and FAT partitions were available.  They seemed to
>>be.  Then I reboot into windows, and it crashed, with a missing HAL.DLL.
>> Boot again into FreeBSD, and the NTFS partition still seemed ok.  But I
>>gone into the \WINDOWS\system32, and did an ls.  The kernel pushed some
>>errors with "bad magic" or something like that, and the file system
>>locked.  Also, the boot information for the first FAT32 partition has
>>been completely destroyed, leaving it unreadable.
>>
>>    The mainboard is an ASUS K8V, with 1G RAM.  I'm running the 32 bit
>>version of FreeBSD, although it is an AMD64 machine.  The 250G SATA disk
>>is on the promise RAID, and I have another PATA 120G on the promise
>>RAID, and a 40G PATA on standard IDE.
>>
>>    I already had a problem with a previous ASUS board in which the
>>promise raid could not deal with disks bigger than 120G.  The symptons
>>were very similar.  Could this be the problem?  Does somebody know if
>>FreeBSD or mount_ntfs has any kind of disk size limitation in this hardware?
>>
>>    Oh, I did remember now that I was using mount_ntfs -o noatime, if
>>that matters.
>>
>>    Thanks for any help,
>>
>>	Jonny
>>
>>PS: Now it has been fully reformatted with no NTFS, using FAT32 instead.
>> But I'm afraid of getting into FreeBSD again in this machine.   Please
>>help!   :-(
>>_______________________________________________
>>freebsd-hackers@freebsd.org mailing list
>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>>From - Mon
> 
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42714EC6.9030105>