Date: Tue, 05 Mar 2002 13:00:53 -0600 From: Craig Boston <craig@meoqu.gank.org> To: sos@freebsd.dk Cc: stable@freebsd.org Subject: Re: Request for testers of new ATA driver patches Message-ID: <3C8515E5.1000302@meoqu.gank.org> References: <200203042201.g24M1nU36308@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Søren Schmidt wrote: > I'm currently backporting the -current ATA driver to -stable, and > >I need some testers as to cover as much HW as possible. >The patches are new, but at least they dont panic here :) >They include atacontrol (for hotswapping, RAID control etc) and >burncd with all -current features. > Really looking forward to DAO support in burncd under -stable, but unfortunately there is no joy here. Patches apply cleanly and compile fine, but the kernel is unable to find my root partition. More detail follows. Sorry that this is a bit lengthy, but I felt it was better to include more detail on the somewhat non-standard way I have things set up so you know why I'm doing it this way :) Here is relevant kernel output from a recent (yesterday) STABLE build: atapci0: <Intel PIIX4 ATA33 controller> port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: <Promise ATA100 controller> port 0xef00-0xef3f,0xefe0-0xefe3,0xefa8-0xefaf,0xefe4-0xefe7,0xeff0-0xeff7 mem 0xfeba0000-0xfebbffff irq 10 at device 15.0 on pci0 ata2: at 0xeff0 on atapci1 ata3: at 0xefa8 on atapci1 ata1-slave: ata_command: timeout waiting for intr ata1-slave: identify failed ar0: 19092MB <ATA SPAN array> [2434/255/63] subdisks: ad4: 19092MB <WDC WD200BB-00AUA1> [38792/16/63] at ata2-master UDMA100 ar1: 19092MB <ATA SPAN array> [2434/255/63] subdisks: ad6: 19092MB <WDC WD200BB-00AUA1> [38792/16/63] at ata3-master UDMA100 acd0: DVD-ROM <CREATIVE DVD-ROM DVD1241E> at ata0-master using UDMA33 acd1: CD-RW <PHILIPS CDD3610 CD-R/RW> at ata1-master using PIO3 I know, you're probably wondering what the hell I'm doing with ar0 and ar1 set up like that :) My situation is that I have a Promise ATA RAID card with two drives attached (one per channel). I was originally mirrirong it when this was a Win2k box, but when I switched to FreeBSD I wanted to mirror /usr and stripe /tmp and swap (mirrored swap just seems like an awful waste to me). The card itself seems to not be capable of handling multiple arrays on the same drives, so I decided to use vinum instead. Since I've heard that the Promise cards use the host CPU for mirroring anyway it didn't seem like a big performance hit. Here lies the problem. I have each drive configured with its own span array covering the whole drive, mostly to get the card's firmware to shut up and not complain about not being configured. Once BSD boots I'm using it as a dumb ATA controller and accessing the subdisks directly. / is mounted from /dev/ad4s1a, and there are vinum partitions on ad4s1e and ad6s1e. I know this probably isn't supported and so I didn't really expect it to work with the new driver, but I really have no other choice. Vinum doesn't recognize ar* as a valid disk device and refuses to use it. With the patched kernel, it still saw the arrays and the subdisks, but refused to boot off of ad4s1a. I was able to coax it into mounting root from ar0s1a, which worked enough to get me a shell. Attempting to access ad4 or ad6 in any way resulted in a device not configured message. Since vinum doesn't like ar devices I had no /usr partition, so I gave up and restored the old kernel. So, I basically have two options: 1) Make sure that the ata/ar driver allows direct access to subdisks. 2) (probably the "right" option) Patch vinum to recognize ar as a valid disk prefix I could probably patch vinum without too much trouble, but since it was working as-is I've never taken the time to investigate what it would take. Actually option 3 is to pull out the RAID controller and buy a standard ATA controller, and option 4 is get a proper SCSI RAID, but cost is a big issue in this case :) Also, while I've got your attention :), there is a long (about 30 second) pause right after detecting atapci0. It seems to be present in all the 4-STABLE kernels, and the same thing happened in the patched kernel. This is an SMP kernel, but all of the ata stuff seems to be initialized long before the second CPU is brought up. The system is otherwise solid as a rock. Any clues or tips on how to get useful debugging information that might help isolate the prob^H^H^H^Hannoyance? And of course I'd be very grateful if anyone can suggest a better way of setting up this disk array so that it's not so horribly hacked up :D -- Craig Figure 1: mount table /dev/ad4s1a on / (ufs, local, noatime) /dev/vinum/usr on /usr (ufs, local, noatime, soft-updates) /dev/vinum/var on /var (ufs, local, noatime, soft-updates) /dev/vinum/obj on /usr/obj (ufs, asynchronous, local, noatime) /dev/vinum/tmp on /tmp (ufs, asynchronous, local, noatime) Figure 2: vinum config drive alpha device /dev/ad4s1e drive beta device /dev/ad6s1e volume usr volume var volume obj volume tmp plex name usr.p0 org concat vol usr plex name usr.p1 org concat vol usr plex name var.p0 org concat vol var plex name var.p1 org concat vol var plex name obj.p0 org striped 600s vol obj plex name tmp.p0 org striped 600s vol tmp sd name usr.p0.s0 drive alpha plex usr.p0 len 35731456s driveoffset 265s plexoffset 0s sd name usr.p1.s0 drive beta plex usr.p1 len 35731456s driveoffset 265s plexoffset 0s sd name var.p0.s0 drive alpha plex var.p0 len 1048576s driveoffset 35731721s plexoffset 0s sd name var.p1.s0 drive beta plex var.p1 len 1048576s driveoffset 35731721s plexoffset 0s sd name obj.p0.s0 drive alpha plex obj.p0 len 786000s driveoffset 36780297s plexoffset 0s sd name obj.p0.s1 drive beta plex obj.p0 len 786000s driveoffset 36780297s plexoffset 600s sd name tmp.p0.s0 drive alpha plex tmp.p0 len 523800s driveoffset 37566729s plexoffset 0s sd name tmp.p0.s1 drive beta plex tmp.p0 len 523800s driveoffset 37566729s plexoffset 600s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8515E5.1000302>