From owner-freebsd-current Fri Feb 2 15:42:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA17095 for current-outgoing; Fri, 2 Feb 1996 15:42:01 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA16991 Fri, 2 Feb 1996 15:41:14 -0800 (PST) Received: by Sysiphos id AA01725 (5.67b/IDA-1.5); Sat, 3 Feb 1996 00:40:49 +0100 Message-Id: <199602022340.AA01725@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Sat, 3 Feb 1996 00:40:48 +0100 In-Reply-To: "Marc G. Fournier" "PR: ASUS PC-SC200 panicks at _scsi_attachdevs+0x20" (Feb 2, 15:48) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "Marc G. Fournier" Subject: Re: PR: ASUS PC-SC200 panicks at _scsi_attachdevs+0x20 Cc: stable@freebsd.org, current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Feb 2, 15:48, "Marc G. Fournier" wrote: } Subject: PR: ASUS PC-SC200 panicks at _scsi_attachdevs+0x20 } } Hi... } } I just submitted a problem report for the problem I'm having } with the PCI-SC200 card, mainly because I've now got what I think is } sufficient data. Well, yes, having looked at it, I'd tend to agree :) } I'm sending this to current, as this might be a problem that } was known to be in stable, has been fixed in current, but hasn't been } brought back to stable yet...well, I'm hoping it was a known problem } at least :( Haven't checked for differences between -stable and -current in this area, but I have identified the failing instruction. See below ... } ncr0 rev 2 int a irq 12 on pci0:11 } } Fatal Trap 12: page fault while in kernel mode } fault virtual address = 0x7 } fault code = supervisor read, page not present } instruction pointer = 0x8:0xf0173724 } code segment = base 0x0, limit 0xfffff, type 0x1b } = DPL 0, pres 1, def32 1, gran 1 } processor eflags = interrupt enabled, resume, IOPL = 0 } current process = 0 () } interrupt mask = net tty bio } kernel: type 12, code = 0 } Stopped at _scsi_attachdevs+0x20: cmpb $0,0x7(%ebx) } db> tra } _scsi_attachdevs() at _scsi_attachdevs+0x20 } _ncr_attach() at _ncr_attach+0x192 } _pci_bus_config() at _pci_bus_config+0x4b8 } _pci_configure() at _pci_configure+0x51 } _configure() at _configure+0x2a } _cpu_startup() at _cpu_startup+4b6 } _main() at _main+0x36 } begin() at begin+0x6b } db> void scsi_attachdevs(scbus) struct scsibus_data *scbus; { int scsibus; struct scsi_link *sc_link_proto = scbus->adapter_link; if ( (scsibus = scsi_bus_conf(sc_link_proto)) == -1) { return; } /* * if the adapter didn't give us this, set a default * (compatibility with old adapter drivers) */ if(!(sc_link_proto->opennings)) { <=== openings is at offset 7 sc_link_proto->opennings = 1; } } Stopped at _scsi_attachdevs+0x20: cmpb $0,0x7(%ebx) <=== Looks as if scbus->adapter_link had not been correctly initialized ... But I checked the code in the NCR driver leading to scsi_attachdevs(), and it seems that np->sc_link is correctly allocated, and that it is dereferenced successfully just before the call np->sc_link.adapter = &ncr_switch; np->sc_link.device = &ncr_dev; np->sc_link.flags = 0; if(!scbus) return; scbus->adapter_link = &np->sc_link; { some unrelated code removed ... } scsi_attachdevs (scbus); And the access to scbus->opennings fails, but the flags component has been accessed just a few instructions before ... struct scsi_link { u_int8 target; /* targ of this dev */ u_int8 lun; /* lun of this dev */ u_int8 adapter_targ; /* what are we on the scsi bus */ u_int8 adapter_unit; /* e.g. the 0 in aha0 */ u_int8 adapter_bus; /* e.g. the 0 in bus0 */ u_int8 scsibus; /* the Nth scsibus */ u_int8 dev_unit; /* e.g. the 0 in sd0 */ u_int8 opennings; /* available operations */ u_int8 active; /* operations in progress */ u_int16 flags; /* flags that all devices have */ u_int16 quirks; /* device specific quirks */ ... } Don't currently understand, what's going on here ... Could you please print the value of scbus and scbus->adapter_link before the call to scsi_attachdevs() and the corresponding values within that function ? I don't see what's going on here, but I don't have a 2.1R tree checked out and can't easily build and boot a 2.1R kernel currently ... Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se