changes in kernel affecting savecore/dumps ...

[Marc G. Fournier]

Please note that both savecore and kernel were installed at the same time:

jupiter# ls -ld /kernel /sbin/savecore
-r-xr-xr-x  1 root  wheel  2029005 Jun 22 00:36 /kernel
-r-xr-xr-x  1 root  wheel   168364 Jun 22 00:35 /sbin/savecore

and were compiled at about the same time, so it isn't as if I forgot to do
a 'make buildworld' first:

jupiter# cd /usr/obj/usr/src/sbin/savecore/
jupiter# ls -lt
total 622
-rw-r--r--  1 root  wheel   39528 Jun 20 16:19 savecore.o
-rwxr-xr-x  1 root  wheel  571487 Jun 20 16:19 savecore
-rw-r--r--  1 root  wheel    2009 Jun 20 16:19 savecore.8.gz
-rw-r--r--  1 root  wheel    2115 Jun 20 16:10 .depend
jupiter# ls -ld /usr/obj/usr/src/sys/kernel/kernel
-rwxr-xr-x  1 root  wheel  2029005 Jun 20 18:34 /usr/obj/usr/src/sys/kernel/kernel



On Fri, 27 Jun 2003, Marc G. Fournier wrote:

>
> David gave me some suggestions to check out on the servers, but so far,
> its all drawing a blank ... I have two servers right now that are updated
> to recent 4.8-STABLE kernels ... one was June 22nd, and the other was
> upgraded June 20th ... both of them have crashed since that date, and both
> of them tell me that they are unable to produce a core file, with the same
> errors:
>
> Jun 26 04:27:14 jupiter savecore: warning: /kernel version mismatch:    "FreeBSD 4.8-STABLE #2: Fri Jun 20 18:34:14 ADT 2003 " and      ""
>
> Prior to those kernel upgrades, I had no problems generating core files,
> and nothing has changed configuration wise, except as results from
> upgrading the OS using 'installworld/installkernel/mergemaster' ...
>
> On Jupiter, previous to the Jun 20th upgrade, I was able to generate two
> cores off of a Jun 6th kernel, so something between Jun 6th and Jun 20th
> has changed ...
>
> Does anyone know of *anything* that may have been commit'd in that period
> of time that could have affected how a crash dumps to the dumpdev?
>
> Note that the servers don't make much use of swap as it is ... one of the
> machines that is exhibiting the problem has been up 4+days now, and swap
> used is:
>
> pluto# pstat -s
> Device          1K-blocks     Used    Avail Capacity  Type
> /dev/da0s1b       8388480    10652  8377828     0%    Interleaved
>
> when pluto crashed, I was able to get in just after and run 'savecore -f'
> to generate the core file, and doing a 'strings <core> | head', I compared
> it with a "good" core, and the first few bytes *look* identical, but
> neither of them show anything in the first few bytes that would come close
> to matching the above string, so am not sure where core_vers is read from
> ...
>
> Help?  Right now, jupiter is going once a night, with nothing in messages
> to indicate a problem, and no core to look at :(
>
> Thanks ...
>
>