From owner-freebsd-hackers Mon May 22 21:29:47 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA07198 for hackers-outgoing; Mon, 22 May 1995 21:29:47 -0700 Received: from spice.tea.org (spice.tea.org [204.182.11.244]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA07190 for ; Mon, 22 May 1995 21:29:45 -0700 Received: by spice.tea.org (8.6.9/8.6.12) id VAA00577; Mon, 22 May 1995 21:29:50 -0700 Date: Mon, 22 May 1995 21:29:50 -0700 From: Christopher Seiwald Message-Id: <199505230429.VAA00577@spice.tea.org> To: freebsd-hackers@FreeBSD.org Subject: re: NCR SCSI 810 Sender: hackers-owner@FreeBSD.org Precedence: bulk > assertion "cp == np-> header.cp" failed: file "../../pci/ncr.c", line 5395 > assertion "cp" failed: file "../../pci/ncr.c", line 5396 > sd0(ncr0:0:0): COMMAND FAILED (4 28) @f1be8e00. Just another datapoint on the NCR SCSI 810 story: I get the same assertion failure, but only when using my (E)IDE drive at the same time I use the SCSI drive. Either one in isolation works fine. Here's my setup: ASUS PVI486-SP3 motherboard, with onboard NCR BIOS (3.05, methinks) noname NCR 53C810 SCSI card Seagate ST31200 (1.04G) SCSI-II drive Seagate 5850A (850MB) EIDE drive FreeBSD 2.0 (stock) Basically, if one drive or the other is going, everything is copacetic. If both are used concurrently, all sorts of failures occur: usually hangs (with drive access lights on), but frequently the aforementioned assertion failure or just a bunch of "COMMAND FAILED" messages. I've gone so far as to turn off interrupts for the PCI slot, change the memory mapped address for the PCI slot, and try a later FreeBSD (041295 snap) kernel, but no dice. I have two theories: o The NCR BIOS (which is part of my motherboard BIOS) initializes things in a way that isn't undone by the NCR driver that is part of FreeBSD. For example, dispite the fact that the NCR driver makes no use of port mapped I/O, the PCI slot is mapped into the PCI address 0xe800 (as reported by PCI_MAP_REG 0x10). It would be interesting to hear if people without the ASUS boards (i.e. those without the NCR BIOS initializing things) have our problem. o The ncr_exception routine isn't running with the right spx(). I know that ncr_intr isn't the problem, as I turned off interrupts and everything worked (speedily too, contrary to the "reduced performance" message issued by ncr_attach()). The only other possible explanation is general memory mashing by the NCR driver, which I discount given its solid performance when it isn't contending with another disk driver. I'm still ramping up on the intricacies of the mondo bizarro PC bus architecture, so if anybody has any wisdom I'd be glad to put it to practice. Christopher