Subject: /sys/scsi/sd.c's sddump()
To: None <email@example.com>
From: Gordon W. Ross <firstname.lastname@example.org>
Date: 12/05/1994 17:24:57
> Date: Mon, 05 Dec 1994 14:22:34 -0700
> From: Theo de Raadt <email@example.com>
> > Crash dumps don't use the new (nor the old) core dump format. Its just
> > a sequential dump of physical memory + some machine specific state and
> > is not ordered in "segments" (registers+text+data[+data*] in current core
> > format). Support for reading crash dumps is in libkvm.
How is the machine-specific state written out?
> > On the sparc, crash dumps were ok with the sd dump routine. sddump() in
> > scsi/sd.c is currently incompatible with sparc's dumpsys() usage.
> Yes -- make sure you look at the old sparc/scsi driver (in 1.0). Crash
> dumps in there definately worked.
The current sys/scsi/sc.c:sddump() assumes it knows what needs to be
written to disk, but that is machine-specific knowledge. For example,
on the sun3 one would really like dumpsys to write out a copy of the
current MMU contents (which are not in main memory).
I prefer the old sparc design for dumpsys, where the port "knows" what
should be writtn out, and xxdump just does the I/O for dumpsys.
Do any other ports needs machine-specific stuff written out when
doing a kernel crash dump?