João Carlos Mendes Luís wrote:
Eu tava tendo problemas sérios com um disco de 250G numa controladora
promise, e acabei chegando a isto aqui, que me parece um bug.  Só para
ter certeza, alguém ai está usando ataraid (promise ou nao) com discos
de mais de 120G?  Não basta ser um array de mais de 120G, cada disco
individual tem que ter mais de 120G.

Se eu estiver certo, espero que corrijam antes do 5.4.  Estou tendo
problemas com isso desde o 5.2.


Fala Jonny, boa noite.

Nos temos alguns ambientes em producao sem problemas, com ataraid. Na verdade quando tivemos historico de problemas (foram bem poucos, e todos com solucao felizmente) em alguns clientes foi mais no suporte SATA do que com a controladora RAID.

Vou te colar os dados de um servidor com RAID1, Controladora Promise PDC20378 com discos SATA de 160G.

(eksffa:/dev/ttyp0)~# pciconf -lv | grep -B 2 RAID
[EMAIL PROTECTED]:4:0: class=0x010400 card=0x80f51043 chip=0x3373105a rev=0x02 hdr=0x00
vendor = 'Promise Technology Inc'
device = 'PDC20378? FastTrak RAID Controller'
class = mass storage
subclass = RAID


(eksffa:/dev/ttyp0)~# grep Promise /var/run/dmesg.boot
atapci0: <Promise PDC20378 SATA150 controller> port 0xd800-0xd87f,0xdfa0-0xdfaf,0xdf00-0xdf3f mem 0xfea80000-0xfea9ffff,0xfeaae000-0xfeaaefff irq 23 at device 4.0 on pci2


(eksffa:/dev/ttyp0)~# atacontrol info 2
Master:  ad4 <Maxtor 6Y160M0/YAR51BW0> Slave:       no device present
(eksffa:/dev/ttyp0)~# atacontrol info 3
Master:  ad6 <Maxtor 6Y160M0/YAR51BW0> Slave:       no device present

(eksffa:/dev/ttyp0)~# grep -i raid /var/run/dmesg.boot
ar0: 156334MB <ATA RAID1 array> [19929/255/63] status: READY subdisks:
ar0: 156334MB <ATA RAID1 array> [19929/255/63] status: READY subdisks:
ar0: 156334MB <ATA RAID1 array> [19929/255/63] status: READY subdisks:
(eksffa:/dev/ttyp0)~# atacontrol status ar0
ar0: ATA RAID1 subdisks: ad6 ad4 status: READY


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.



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 "[EMAIL PROTECTED]"

From - Mon

_______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"

=============================================================================== Este mail so pode ser lido em sistemas operacionais da Microsoft mediante o pagamento de EU45.99/msg a Open-AMS Foundation. Leia a Open-AMSF License. Lista Nacao-l (C) 2001-2005 by the Regents of the Open Ai Meu Saco Foundation, Qualquer mensagem ou texto incluindo esta mensagem deve obrigatoriamente seguir a Open-AMSF License, pela definicao de OpenSourceEmail. All Rights Reserved. Qualquer duvida: consulte o FAA desta lista. =============================================================================== Este mail esta em Contexto AiMeuSaco(TM) - (C)1994-2005 Open-AMSF O Conteudo dele NAO e' veridico. Qualquer semelhanca com fatos, eventos ou personagens e' mera coincidencia. =============================================================================== AMS, 11 anos trabalhando na democratizacao do ruido. ===============================================================================


_______________________________________________
Freebsd mailing list
Freebsd@fug.com.br
http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br


--
Atenciosamente,

Patrick Tracanelli

FreeBSD Brasil LTDA.
The FreeBSD pt_BR Documentation Project
http://www.freebsdbrasil.com.br
patrick @ freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"


_______________________________________________ Freebsd mailing list Freebsd@fug.com.br http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br

Responder a