From owner-freebsd-current Sun Oct 25 10:20:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA02356 for freebsd-current-outgoing; Sun, 25 Oct 1998 10:20:15 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from seawall.ninthwave.com (ninthwave.com [209.31.6.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA02265 for ; Sun, 25 Oct 1998 10:19:41 -0800 (PST) (envelope-from jdi@ninthwave.com) Received: from ninthwave.com (kuta.ninthwave.com [10.0.0.2]) by seawall.ninthwave.com (8.9.1/8.9.1) with ESMTP id KAA01236; Sun, 25 Oct 1998 10:16:13 -0800 (PST) (envelope-from jdi@ninthwave.com) Message-ID: <36336AF4.EEBFFC63@ninthwave.com> Date: Sun, 25 Oct 1998 10:16:20 -0800 From: John Irwin X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" , wolf@cologne.de, se@mi.Uni-Koeln.de CC: Michael Class , current@FreeBSD.ORG Subject: Re: CAM and quantum disc References: <199809231405.IAA21990@panzer.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kenneth D. Merry" wrote: > The Atlas II's will keep returning queue full until we have reduced the tag > count to 0. That's why we put in a lower limit of 24. We don't allow the > tag count to go below that; we just retry. Unfortunately the retry code for the NCR controller appears to have problems. I get a very consistent "page fault in kernel mode" panic when trying to restore a dumped filesystem to my Atlas II. This is with the 3.0-release tag, but ncr.c doesn't appear to have changed since then. My setup: rev 0x04 int a irq 9 on pci0.10.0 Fixed Direct Access SCSI2 device Serial Number PCB=2011300002 ; HDA=182710655437 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled Before the panic occurs, I get the expected series of kernel messages showing that the tagged openings limit is reduced in stages to 24. A while later, during the file part of the restore, I get the panic. I've been unable to get a kernel core dump as the panic doesn't complete. >From the 'ddb' output, the page fault is at 0x34, with the PC in: ncr_int_sir ncr.c 6405 pushl 0x34(%eax) from (ncr_exception, ncr.c, 5442) from (ncr_intr, ncr.c, 3912) which implies that the ccb is null. Unfortunately my knowledge of SCSI & CAM is insufficient to get much past there without a long climb up the learning curve. (Last filesystem hacking was in 4.3 era). Thanks, -- John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message