Bug 14030
| Summary: | aha0 probe fails 3.3.0-RELEASE install with DTC3290 EISA SCSI | ||
|---|---|---|---|
| Product: | Base System | Reporter: | bobkat <bobkat> |
| Component: | i386 | Assignee: | Warner Losh <imp> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 3.3.0-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->imp Warner wrote the aha driver. I have been successful in working on my own problem report .
I modified the following file which I refer to as aha.c.orig =
$FreeBSD: src/sys/dev/aha/aha.c,v 1.19.2.6 1999/09/14 04:07:49 gibbs Exp $
The following diff output is in the ahareset( ) function.
All I did was comment out the while loop that is polling for the DIAG_ACTIVE bit.
diff -u aha.c.orig aha.c
--- aha.c.orig Thu Oct 14 17:37:38 1999
+++ aha.c Sat Oct 16 10:26:04 1999
@@ -1496,12 +1496,14 @@
/* Wait 5sec. for Diagnostic start */
timeout = 5 * 10000;
+/*
while (--timeout) {
status = aha_inb(aha, STATUS_REG);
if ((status & DIAG_ACTIVE) != 0)
break;
DELAY(100);
}
+*/
if (timeout == 0) {
PRVERB(("%s: ahareset - Diagnostic Active failed to "
"assert. status = 0x%x\n", aha_name(aha),
I modified GENERIC kernel config file for my hardware to become KOT33A
and built a new kernel.
I deleted the gzipped kernel on the (kern.flp) installation disk and replaced it with a
gzip of the kernel I created.
Booted with new kernel on floppy and proceeded with successful install of
FreeBSD 3.3-RELEASE.
From sysinstall I ran the fixit floppy to replace the GENRIC kernel in the / (root)
directory with my modified kernel.
Finally booting from the hard drive was succesful!
Output of boot /kernel -v
dmesg
Copyright (c) 1992-1999 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 3.3-RELEASE #5: Sat Oct 16 11:10:19 MST 1999
root@atlas.tic.toc:/usr/src/sys/compile/KOT33A
/* Lines deleted */
aha0 at 0x330-0x333 irq 11 drq 5 on isa
aha0: AHA-1540/1542 64 head BIOS FW Rev. 1.0 (ID=41) SCSI Host Adapter, SCSI ID 7, 16 CCBs
/* Lines deleted */
Device configuration finished.
new masks: bio c0080040, tty c00700ba, net c00700ba
(probe0:aha0:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0
(probe0:aha0:0:0:0): ILLEGAL REQUEST asc:24,0
(probe0:aha0:0:0:0): Invalid field in CDB sks:c8,1
(probe1:aha0:0:1:0): INQUIRY. CDB: 12 1 80 0 ff 0
(probe1:aha0:0:1:0): ILLEGAL REQUEST asc:24,0
(probe1:aha0:0:1:0): Invalid field in CDB sks:c8,1
(probe2:aha0:0:2:0): INQUIRY. CDB: 12 1 80 0 ff 0
(probe2:aha0:0:2:0): ILLEGAL REQUEST asc:24,0
(probe2:aha0:0:2:0): Invalid field in CDB sks:c8,1
Considering MFS root f/s.
No MFS image available as root f/s.
da0 at aha0 bus 0 target 0 lun 0
da0: <MICROP 1624-07MZ1077801 HZ2P> Fixed Direct Access SCSI-CCS device
da0: 3.300MB/s transfers
da0: 642MB (1316751 512 byte sectors: 64H 32S/T 642C)
da1 at aha0 bus 0 target 1 lun 0
da1: <IMPRIMIS 94601-15 1250> Fixed Direct Access SCSI-CCS device
da1: 3.300MB/s transfers
da1: 990MB (2027760 512 byte sectors: 64H 32S/T 990C)
cd0 at aha0 bus 0 target 2 lun 0
cd0: <TOSHIBA CD-ROM XM-3401TA 0283> Removable CD-ROM SCSI-2 device
cd0: 3.300MB/s transfers
cd0: cd present [200882 x 2048 byte records]
Considering FFS root f/s.
changing root device to da1s1a
da1s1: type 0xa5, start 32, end = 2027519, size 2027488 : OK
start_init: trying /sbin/init
splash: image decoder found: fire_saver
/* END dmesg */
System hardware
Micronics - 50MHz EISA motherboard
DTC3290 - EISA SCSI controller ( emulating Adaptec 1542)
SCSI devices - See dmesg output above
I compiled several kernels and noted the following.
In the very first execution of the ahareset( ) function for
reset_type = HARD_RESET
or reset_type = SOFT_RESET
or reset_type = HARD_RESET | SOFT_RESET
in aha_outb(aha, CONTROL_REG, reset_type);
ALL values of status in the subsequent while loop = 0x30, even the very first one!
while (--timeout) {
status = aha_inb(aha, STATUS_REG);
if ((status & DIAG_ACTIVE) != 0)
break;
DELAY(100);
}
The DTC3290 emulation is never setting the high bit DIAG_ACTIVE(0x80) in the STATUS_REG,
or it is setting it and clearing it faster than this code can detect.
The patch shown above is one possible solution to the problem with the DTC3290
hardware/firmware. There are others, to be sure. All I request is that some commit be
made to the aha.c source that results in an equivalent result.
I am now in the position to test any tentative fix.
Please incorporate a fix to support the DTC3290 EISA SCSI host adapter emulating the AHA1542 in future releases. I have reproduced this error on my system exactly as described by Mr. Kot. The system has the DTC3290 EISA SCSI board with the AHA1542 emulation enabled. Using Linux, the board is recognized as the AHA1542, and everything boots fine. When I try to install FreeBSD, the card is not recognized. While I would prefer to use FreeBSD, I am sufficiently satisfied with the Slackware distribution of Linux to continue using it. FreeBSD may be a better OS, but it is not worth upgrading the hardware on this old system to use it. If you have any questions, please direct them to my email address. Thank you, Tom Hermann __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com Any chance this PR will be fixed prior to impending 4.0 release. The handbook ( http://www.freebsd.org/handbook/install-hw.html ) still indicates this controller is supported. This problem is a time consuming impediment for installation, and I want to put 4.0 on a machine with this controller as soon as it is released. One possible fix (mine) is on the PR audit trail. A pre-4.0 release resolution/commit would be much appreciated. Bob Kot Hello Bob, Have you had a chance to test later release of FreeBSD ? Did it work ? Thanks for your feedback, Arnaud. State Changed From-To: open->closed Original mail bounces, have no hardware to test. |
I have a DTC3290 SCSI EISA host adapter(Data Technology Corp) Its bios is Rev. 3.1.07 This bios emulates the Adaptec 154x[AB] I have used this controller as is with FreeBSD 1.1 and currently with 2.2.8-RELEASE and the aha controller has worked fine. I recently tried to install 3.3-RELEASE, but the aha0 probe failed when resetting my DTC3290. I am including information on 2.2.8-RELEASE for diagnostic purposes. FreeBSD 2.2.8-RELEASE - Where my DTC3290 SCSI controller is working. /* *dmesg output with -v kernel switch */ Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.8-RELEASE #0: Wed Mar 17 18:02:39 MST 1999 root@kot.my.domain:/usr/src/sys/compile/KERNKOTA /* * Omit non pertinent lines */ Probing for devices on the ISA bus: /* * Omit non pertinent lines */ aha0: Rev 41 (AHA-154x[AB]) V1.0, enabling residuals, target ops aha0: reading board settings, dma=5 int=11 id=7 (bus speed defaulted) aha0 at 0x330-0x333 irq 11 drq 5 on isa aha0 waiting for scsi devices to settle (aha0:0:0): "MICROP 1624-07MZ1077801 HZ2P" type 0 fixed SCSI 1 sd0(aha0:0:0): Direct-Access 642MB (1316751 512 byte sectors) sd0(aha0:0:0): with 2112 cyls, 7 heads, and an average 89 sectors/track (aha0:1:0): "IMPRIMIS 94601-15 1250" type 0 fixed SCSI 1 sd1(aha0:1:0): Direct-Access 990MB (2027760 512 byte sectors) sd1(aha0:1:0): with 1931 cyls, 15 heads, and an average 70 sectors/track (aha0:2:0): "TOSHIBA CD-ROM XM-3401TA 0283" type 5 removable SCSI 2 cd0(aha0:2:0): CD-ROM can't get the size /* * Omit non pertinent lines */ BIOS Geometries: 0:02813f20 0..641=642 cylinders, 0..63=64 heads, 1..32=32 sectors 1:03dd3f20 0..989=990 cylinders, 0..63=64 heads, 1..32=32 sectors 0 accounted for Device configuration finished. /* END 2.2.8 dmesg */ You will notice that I have rebuilt the kernel, but I assure you that the source code was as received in the 2.2.8-RELEASE. My kernel rebuild was to pare down all the default device support that is not needed in my system. My KERNKOTA is GENERIC with a lot of lines commented out. I downloaded the 3.3-RELEASE floppies (kern.flp) & (mfsroot.flp) from ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/3.3-RELEASE/floppies An attempt at installing resulted in the following. Visual kernel config with default arguments for aha0 device and elimination of all conflicts. After visual kernel config I did not let it auto reboot. I gave it the boot -v command to turn on verbose output dmesg output - (segment retyped by hand) aha0: ahareset - Diagnostic Active failed to assert. status = 0x30 aha0: Failed Reset aha0: status reg test failed ff aha0: status reg test failed ff aha0: status reg test failed ff aha0: status reg test failed 0 aha0: status reg test failed 0 aha0: not found at 0x134 Then I repeated the installation except in CLI mode I set aha0 port to 0x330 dmesg output aha0: ahareset - Diagnostic Active failed to assert. status = 0x30 aha0: Failed Reset aha0: not found at 0x330 Needless to say, with all my hard drives being SCSI, this probe failure ended my attempt at installation. Fix: I don't have an actual fix or work around but here are some observations. In the source code for 3.3-RELEASE $FreeBSD: src/sys/dev/aha/aha.c,v 1.19.2.6 1999/09/14 04:07:49 gibbs Exp $ In the ahareset() function the PRVERB that causes aha0: ahareset - Diagnostic Active failed to assert. status = 0x30 is the result of the preceding while loop never detecting the DIAG_ACTIVE (0x80) bit when it polls the STATUS_REG. The DTC3290 board is returning 0x30 This leads to the following. 1. Is the board being sent the proper reset command? I find it curious that the old $Id: aha1542.c,v 1.63.2.1 1997/01/10 09:08:46 phk Exp $ in function aha_init() issued the reset command as outb(AHA_CTRL_STAT_PORT, AHA_HRST | AHA_SRST); (0x80) (0x40) The hard and soft reset bits are or'ed which sends (0xC0). The new aha.c sends only (0x80). Is this significant? 2. Does the DTC3290 ever return status with the DIAG_ACTIVE(0x80) bit set? Perhaps DTC's emulation of Adaptec behavior is deficient, or is their reset accomplished and that bit is set and reset before being polled the first time? I don't know the answer to this. I also find it curious that the old code defined AHA_STST = 0x80 but never used that value for anything. I am willing to assist with this problem. If someone can assist me in being able to edit and compile 3.3-RELEASE sources into a kernel while executing on 2.2.8-RELEASE, I could try some variations and see if this problem is as simple as it currently seems, or if there are other problems lurking. This failure was very early in the probe. How-To-Repeat: This should be obvious from the description section above. However, you need the DTC3290 board to duplicate the problem!