tom@tandon.UUCP (Tom Friel) (09/25/90)
Sorry this is so long, but I would like to know if users of IDE drives have experienced problems with SCO Xenix 2.3.2 and Interactive Unix 2.2. I will be nice and not mention drive manufacturers. I'm posting because, until recently, I had heard of no such field problems with IDE drives and had posted a note saying everything was hunky-dory. We saw nothing in our labs until August; we have been shipping IDE drives for over 14 months. Following are excerpts from a note by Interactive's European support group 8-16-90: "In some cases 2.2 will boot successfully and installation will appear to proceed without problems. Unfortunately, on subsequent reboot the error 'srmount panic' is displayed and you cannot proceed. Furthermore, attempts to access the IDE disk filesystems will fail; i.e., 'fsck' will not recognize the disk. "The problem was tracked to a timing problem whilst selecting and testing the presence of a drive. We have added suitable delay loops around these functions in the code." ... the note goes on to say that a replacement BOOT disk is available, and a driver update to the 'athd' driver. We have a subsequent note 8-23-90 from a drive manufacturer (in the US): "In some embedded disk drives the busy bit in the status register will go low before IRQ 14 has been asserted. This means that reading the status register when the busy bit has gone low does NOT guarantee the IRQ to be cleared. This time delay for asserting IRQ creates problems for drivers that use both polling and waiting-for-interrupt methods on different command sets. In the case of ISC HPDD, the driver will use the polling method for the SET PARAMETER command. However, for other commands such as READ AND WRITE, the driver acknowledges the command completion during interrupt. "A problem arises in the following sequence of events. The driver issues the SET PARAMETER command and polls until the busy bit has gone low. But IRQ 14 has not yet been asserted due to the time delay. The driver then starts up a READ command and waits for completion from interrupt. When IRQ 14 is finally asserted for the SET PARAMETER command, the driver will mis-interpret the interrupt as being for the completion of the READ command. The result is that ISC 2.2 cannot be installed on ... IDE drives. "It is anticipated that the next point release of ISC Unix, tentatively scheduled for 4th quarter, will fix this problem. Upgrades will be available for current ISC Unix customers." If anyone can provide insights on this whole issue, I would be grateful: ISC, SCO, drive companies, users, dealers, anyone! -- Tom Friel | Tandon Computer Corporation | (805) | tom@quad1.UUCP | 609 Science Drive Moorpark, CA 93021 | 378-7881 | tom@quad.com | Moorpark, CA 93021 |__________| UUCP: ..psivax!quad1!tandon!tom ..psivax!quad1!tom
rcd@ico.isc.com (Dick Dunn) (09/26/90)
tom@tandon.UUCP (Tom Friel) writes: > Sorry this is so long, but I would like to know if users of IDE drives > have experienced problems with SCO Xenix 2.3.2 and Interactive Unix 2.2. I've been running a pair of IDE drives on a machine with ISC 2.2 for a while now. I've occasionally pounded on them pretty hard, and I've see no failures. The drives are Maxtor (MiniScribe) 7080-A. >...I will be nice and not mention drive manufacturers... Tom - I don't think this is being "nice." The drive manufacturers need to know if there's a problem with their drives, and people on the net want to know if there is some particular device, or combination of device(s) and software, that won't work. That's what the net is here for! >...I'm posting because, > until recently, I had heard of no such field problems with IDE drives and > had posted a note saying everything was hunky-dory... I don't see any reason to worry about IDE _per_se_. It's just a drive interface, and *if it's implemented correctly* it looks and works just like a standard AT disk controller. The description later in Tom's article... ...a timing problem whilst selecting and testing the presence of a drive... ...the busy bit in the status register will go low before IRQ 14 has been asserted... ...says that it's a real hardware problem, and we need to know what hardware has the problem. Even if it's only been found in one particular manufacturer's drive so far, that drive might be using a piece of VLSI that's also used in other controllers. (Who knows; it sounds like a bus- interface logic problem...which means [pure speculation here!] that it could conceivably show up in any sort of device--not just an IDE drive; in fact, not just a disk drive.) Details, please? -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Worst-case analysis must never begin with "No one would ever want..."