Date: Fri, 2 Mar 2007 19:22:47 +0200 From: Sven Petai <hadara@bsd.ee> To: freebsd-stable@freebsd.org Cc: =?iso-8859-1?q?R=F4mulo_Lima?= <romulo.lima@wavenet.com.br>, =?iso-8859-1?q?S=F8ren_Schmidt?= <sos@deepcore.dk> Subject: Re: SATA: AHCI controller reset failure - After Upgrade Message-ID: <200703021922.47735.hadara@bsd.ee> In-Reply-To: <08e101c75cd8$3f569a40$de00a8c0@redeinterna.wavenet.com.br> References: <08e101c75cd8$3f569a40$de00a8c0@redeinterna.wavenet.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 02 March 2007 16:37, R=F4mulo Lima wrote: > Hi, > > Good morning, my name is R=F4mulo Lima, I had a problem when make an upgr= ade > in my Freebsd Server from version 6.1 to 6.2. Before upgrade my SATA disc > controller was working normally: > > atapci1: <AcerLabs M5287 SATA150 controller> port > 0xec00-0xec0f,0xe480-0xe487,0xe400-0xe40f,0xe080-0xe087,0xe000-0xe01f mem > 0xdffff800-0xdffffbff irq 21 at device 31.1 on pci0 ad4: 78167MB <Maxtor > 6Y080M0 YAR51HW0> at ata2-master SATA150 > > But after upgrade I got the following error, and my SATA disc stops, aft= er > that I proceeded with a downgrade and may Server work fine again. > > atapci1: AHCI controller reset failure > device_attach: atapci1 attach returned 6 This regression was discussed recently, see=20 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D71434+0+current/freebsd-stab= le The problem seems to be the fact that BIOS indicates AHCI availability when in reality it's not available. Do you have options in BIOS for selecting in what mode SATA works, usually the selection is something like: raid, non-raid, ahci. If there are different modes available then does selecting others than the= =20 current one make any difference ? If it doesn't help then you might try the following patch as a workaround, = it=20 will disable any attempts to try AHCI on other ALI chipsets than 5288, sinc= e=20 that's the only one I have personally used AHCI on and can be fairly certai= n=20 that it really works there.=20 Of course this is only a _workaround_ until S=F8ren or someone else figures= out=20 how to detect AHCI on ALi chipsets more reliably. diff -ru sys/dev/ata_orig/ata-chipset.c sys/dev/ata/ata-chipset.c =2D-- sys/dev/ata_orig/ata-chipset.c Mon Feb 12 01:46:45 2007 +++ sys/dev/ata/ata-chipset.c Fri Mar 2 18:47:16 2007 @@ -952,7 +952,7 @@ struct ata_chip_id *idx; static struct ata_chip_id ids[] =3D {{ ATA_ALI_5289, 0x00, 2, ALISATA, ATA_SA150, "M5289" }, =2D { ATA_ALI_5288, 0x00, 4, ALISATA, ATA_SA300, "M5288" }, + { ATA_ALI_5288, 0x00, 4, ALIAHCI, ATA_SA300, "M5288" }, { ATA_ALI_5287, 0x00, 4, ALISATA, ATA_SA150, "M5287" }, { ATA_ALI_5281, 0x00, 2, ALISATA, ATA_SA150, "M5281" }, { ATA_ALI_5229, 0xc5, 0, ALINEW, ATA_UDMA6, "M5229" }, @@ -984,6 +984,7 @@ switch (ctlr->chip->cfg2) { case ALISATA: + case ALIAHCI: ctlr->channels =3D ctlr->chip->cfg1; ctlr->allocate =3D ata_ali_sata_allocate; ctlr->setmode =3D ata_sata_setmode; @@ -991,8 +992,9 @@ /* if we have a memory resource we can likely do AHCI */ ctlr->r_type2 =3D SYS_RES_MEMORY; ctlr->r_rid2 =3D PCIR_BAR(5); =2D if ((ctlr->r_res2 =3D bus_alloc_resource_any(dev, ctlr->r_type2, =2D &ctlr->r_rid2, RF_ACTI= VE))) + if (ctlr->chip->cfg2 =3D=3D ALIAHCI && + (ctlr->r_res2 =3D bus_alloc_resource_any(dev, ctlr->r_type2, + &ctlr->r_rid2, RF_ACTIVE))) return ata_ahci_chipinit(dev); /* enable PCI interrupt */ diff -ru sys/dev/ata_orig/ata-pci.h sys/dev/ata/ata-pci.h =2D-- sys/dev/ata_orig/ata-pci.h Mon Feb 12 01:46:45 2007 +++ sys/dev/ata/ata-pci.h Fri Mar 2 18:34:23 2007 @@ -360,6 +360,7 @@ #define ALIOLD 0x01 #define ALINEW 0x02 #define ALISATA 0x04 +#define ALIAHCI 0x08 #define HPT366 0 #define HPT370 1
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703021922.47735.hadara>