From owner-freebsd-current Tue Jan 26 22:58:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA07221 for freebsd-current-outgoing; Tue, 26 Jan 1999 22:58:15 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA07215 for ; Tue, 26 Jan 1999 22:58:09 -0800 (PST) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.9.1a/8.9.1) id RAA12691; Wed, 27 Jan 1999 17:57:58 +1100 (EST) Message-ID: <19990127175758.G11595@rf900.physics.usyd.edu.au> Date: Wed, 27 Jan 1999 17:57:58 +1100 From: David Dawes To: Bruce Evans , current@FreeBSD.ORG Subject: Re: Promise FastTrack PCI IDE controller References: <199901221254.XAA23422@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199901221254.XAA23422@godzilla.zeta.org.au>; from Bruce Evans on Fri, Jan 22, 1999 at 11:54:59PM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 22, 1999 at 11:54:59PM +1100, Bruce Evans wrote: >>I've been playing with a Promise FastTrack RAID (IDE) controller with >>3.0-current as of yesterday. Although it is recognised in the PCI bus >>probe as a "Promise Ultra/33" (it has the same vendor/chip ID as the >>non-RAID card), the probes in i386/isa/wd.c fail. I added some debugging >>printfs to the code, and have found that wdreset() is failing. By >>changing the code to ignore that failure, it gets further, and correctly >>identifies the attached disks. I can even access the disks sufficiently >>to read the partition table with fdisk (but with timeouts). > >Errors in wdreset() for the Promise (at least for the Ultra/33) >probably mean that du->dk_altport is not initialized properly. (Setting >du->dk_altport is the only thing that is very special for the Promise, >and wdreset() is the only function that uses du->dk_altport for anything >except debugging.) The wrong setting of du->dk_altport may be caused by >the section of code in pci/ide_pci.c described by "/* This code below >is mighty bogus. ...". Bugs there may also break DMA capability. There is a problem with the way du->dk_altport is set in wdattach. It is set correctly in wdprobe, but incorrectly in wdattach. The following patch fixes that. However, this isn't sufficient to get the card working with the RAID BIOS is installed. The wdreset() problem is, however, more noticable in that case because it then it gets called after the attach. David -- *** wd.c.ORIG Sun Jan 17 16:46:24 1999 --- wd.c Wed Jan 27 17:55:33 1999 *************** *** 422,428 **** --- 425,432 ---- struct isa_device *wdup; struct disk *du; struct wdparams *wp; + int interface; dvp->id_intr = wdintr; if (dvp->id_unit >= NWDC) *************** *** 470,476 **** du->dk_lunit = lunit; du->dk_port = dvp->id_iobase; ! du->dk_altport = du->dk_port + wd_ctlr; /* * Use the individual device flags or the controller * flags. --- 475,490 ---- du->dk_lunit = lunit; du->dk_port = dvp->id_iobase; ! interface = dvp->id_unit / 2; ! if (wddma[interface].wdd_candma != NULL) { ! du->dk_dmacookie = ! wddma[interface].wdd_candma(dvp->id_iobase, ! du->dk_ctrlr, du->dk_unit); ! du->dk_altport = ! wddma[interface].wdd_altiobase(du->dk_dmacookie); ! } ! if (du->dk_altport == 0) ! du->dk_altport = du->dk_port + wd_ctlr; /* * Use the individual device flags or the controller * flags. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message