From owner-freebsd-hackers Thu Jul 6 13:28:23 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA00870 for hackers-outgoing; Thu, 6 Jul 1995 13:28:23 -0700 Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA00848 for ; Thu, 6 Jul 1995 13:28:14 -0700 Received: by FileServ1.MI.Uni-Koeln.DE id AA28022 (5.67b/IDA-1.5 for hackers@freebsd.org); Thu, 6 Jul 1995 22:28:00 +0200 Message-Id: <199507062028.AA28022@FileServ1.MI.Uni-Koeln.DE> From: esser@zpr.uni-koeln.de (Stefan Esser) Date: Thu, 6 Jul 1995 22:28:00 +0200 In-Reply-To: Voradesh Yenbut "Re: One cause of 2.05R instability found" (Jul 5, 14:43) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Voradesh Yenbut Subject: Re: One cause of 2.05R instability found Cc: hackers@freebsd.org Sender: hackers-owner@freebsd.org Precedence: bulk On Jul 5, 14:43, Voradesh Yenbut wrote: } Subject: Re: One cause of 2.05R instability found } In message <199507051552.AA06352@FileServ1.MI.Uni-Koeln.DE>, Stefan Esser writes: } >Well, since there shouldn't have been any code generated } >before, there shouldn't be any difference ... } } There are some differences. One fact is that my system no longer } crashes. The others seem to be some shifts in the code. More details } of code changes are below. Well, didn't expect that the code would come out different ... } I did make a trivial change of code in if_ed.c for it to identify my } NIC board as 8216 instead of 8416. At first I thought the problem was } with the modified ed driver, but changing it to unmodified version or } version from previous release did not make any difference to the } crash. I did not use any NCR specific kernel config file options. Ok. } >; ncb_profile (np, cp); } > pushl %ecx } > pushl 8(%ebp) } > call _ncb_profile } } } } > addl $8,%esp } > } >; if (DEBUG_FLAGS & DEBUG_TINY) } >; printf ("CCB=%x STAT=%x/%x\n", (unsigned)cp & 0xfff, } >; cp->host_status,cp->scsi_status); } > } >; xp = cp->xfer; } > movl 12(%ebp),%ecx } > movl 452(%ecx),%edi } > } >; cp->xfer = NULL; } > movl $0,452(%ecx) } } When the "if (DEBUG_FLAGS.." statement has actually been commented } out in the source code, the line "addl $8,%esp" above was moved to a } location before "if (cp->parity_status" as below. There is no change } to the code between the old and the new locations of addl. } } >All data structures should remain unchanged over the } >execution of ncr_complete(), since they are locked in a } >way that should also prevent simultanous updates by the } >NCR ... } > } > xp = cp->xfer; } > cp->xfer = NULL; } > tp = &np->target[xp->sc_link->target]; } > lp = tp->lp[xp->sc_link->lun]; } } >>> } >>> addl $8,%esp <<<<<< New location } } >ncr_complete + 195: } > if (cp->parity_status) { } > ... } > { } } Also the locations of instructions were shifted. For example, } ncr_complete is now at 0xf0168eb1 instead of at 0xf0168ec1. There } could also be other changes that are not mentioned here. Well, I'll have a look at the output of both versions of ncr.c (with and without the "if (DEBUG)"). Perhaps I'll find something ... } >It might help to send a stack trace obtained using } >the kernel debugger ... } } I am afraid it would be hard to do. My system has 64 MBs of memory } and each swap partition has only 48 MBs. Since the panic was in } ncr.c, sometimes the system was just stuck not being able to write } anything to the disks. If there is an easy way to get a dump (without } changing the system much), I might attempt to do it. Well, I thought about building a system with kernel debugger support: options DDB The system will give a debug prompt in case of a panic. To get a stack trace, you enter "trace", to reboot you can use "panic" command ... But You'll have to writ down the stack trace by hand ... Regards, STefan -- Stefan Esser Internet: Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln FAX: +49 221 4705160 Weyertal 80 50931 Koeln