Date: Thu, 6 Jul 1995 22:28:00 +0200 From: esser@zpr.uni-koeln.de (Stefan Esser) To: Voradesh Yenbut <yenbut@cs.washington.edu> Cc: hackers@freebsd.org Subject: Re: One cause of 2.05R instability found Message-ID: <199507062028.AA28022@FileServ1.MI.Uni-Koeln.DE> In-Reply-To: Voradesh Yenbut <yenbut@cs.washington.edu> "Re: One cause of 2.05R instability found" (Jul 5, 14:43)
next in thread | previous in thread | raw e-mail | index | archive | help
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
}
} <ncr_complete+128>
}
} > 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];
}
} >>><ncr_complete+189>
} >>> 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: <se@ZPR.Uni-Koeln.DE>
Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021
Universitaet zu Koeln FAX: +49 221 4705160
Weyertal 80
50931 Koeln
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507062028.AA28022>