as it�s my first message in this list, I hope I�m not missing something. If so, please warn me. :)
I did some digging in here, and found the following thread, from last January. Well, I have the exact same problem, but with a FastTrack S150 SX4 (not M), with chipset PDC20621 (identified by 5.4-RELEASE as 20622) and 64MB ECC SDRAM. This board is installed in a HP ML 110 with an embedded two-channel P-ATA and a (factory-disabled) two-port S-ATA. The FastTrack is plugged to a factory-assembled 4-disk hotswap cage, and has two SATA disks on it.
Well, to cut it short, I�ll say that I already tried to pick the most recent sys/dev/ata drivers from FTP, but couldn�t find them at current.freebsd.org, nor in .br mirrors. I was preparing to try CVS, but I bumped onto another problem...
The bigger problem is, I have no other disks but these S-ATA, and this happens with P-ATA enabled or not (I would need it for the CD-ROM, but doesn�t work even with P-ATA disabled and booting with floppies). I also tried to "set hint.ata.0.disabled=1" (if such thing exists :P ), same problem again. It also seems to be irrelevant if it�s RAID 0,1, or 5. I get this message right upon install.
That prevents me from putting the entire output from dmesg, but if necessary, I can try it on VMware, then maybe I could do a copy-paste. ;)
So, what would you suggest? Is there any variable I could set upon booting that could workaround it? Or *must* we plug an ordinary P-ATA, install 5.x on it and then rework the drivers? (note: there�s no phisical space for one more HD, since the cage takes all 4 bays.) Is there any other alternative? :P
Just to add, we have another identical ML-110 that we got to put to work by changing the RAID controller to a Highpoint 1820A, but then the LEDs on the cage don�t work, though this isn�t really an issue. Apart from that, it runs almost perfectly, booting right into a RAID 5 array - "almost" goes to Highpoint�s daemon, which is slightly outdated: it�s for FBSD 5.2 and needs a few "adjustments". ;)
We tried FreeBSD 5.3-RELEASE and 5.4-RELEASE. Any ideas? Errrr... did I forgot to mention anything? :)
Anyway, thanks a lot for your time. Cheers,
Tulio G. da Silva
Dave, one last note. Be sure to copy your dmesg output when modifying the controller mode and driver as this may indicate how the chip presents itself to the kernel and provide hints if a patch is needed.
Chris
On Wed, 26 Jan 2005 ctodd at chrismiller.com wrote:
>
> On Wed, 26 Jan 2005, Dave Myron wrote:
>
> > It's not red but it is the PRI_RAID IDE connector. I have the controller set
> > to IDE in the BIOS so it should act just as any other IDE controller
> > (according to the manual and many other sources).
>
> True, but you know how that goes.
>
> > I have two hard drives on the primary IDE (not on the controller) and a CD
> > drive on the secondary IDE (also not on the controller). Then I have two
> > more hard drives on the PRI_RAID channel (which *is* the P-ATA channel on
> > the controller). Those two drives are getting the failure (or at least one
> > is - see the error messages in my original text).
> >
> > I wish I had an S-ATA drive to test with so that I could verify that it's a
> > problem with the P-ATA part of this controller.
> >
> > Any more ideas?
>
> Did you try leaving the Promise controller (in IDE mode) enabled and
> disconnecting the drives? What about setting the controller into raid mode
> with or without the drives attached? Obviously don't do anything that
> would cause any data loss on those drives (i.e. init the raid array).
>
> Sounds like something to do with Promise in the IDE mode. Perhaps the
> kernel is detecting the chip and assuming raid is enabled. You could also
> try disabling the ar driver in the kernel for grins, then perhaps the chip
> will just show up as an IDE controller.
>
> I'm suspect the SATA raid functions work fine, but I believe the
> controller also supports a non raid mode for SATA drives, unfortunately I
> don't have a spare to test this.
>
> In any event report back what you find so the driver can be fixed if
> it seems to be the problem.
>
> Chris
>
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "[EMAIL PROTECTED]"
