|
|
|
|
|
|
| Author |
Message |
Bruce Evans
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 190
|
 Posted: Sun Mar 31, 2002 4:10 am Post subject:
Re: Rewamping kernel dumps...
|
|
|
On Sat, 30 Mar 2002, Poul-Henning Kamp wrote:
| Quote: | Here is what I plan to do to the kernel dumping code.
Device drivers can provide a dumping function, which will act as
an blocked sequential write device. This _can_ be the traditional
swap-partition-on-disk, but it could also be tapes or TFTP over a
network interface.
The function has the following type:
typedef int dumper_t(
void *private, /* Private to the driver. */
void *virtual, /* Virtual (mapped) address. */
void *physical, /* Physical address of virtual. */
off_t length); /* Number of bytes to dump. */
|
The type of `physical' is bogus. It should be vm_offset_t. I'm not
sure if physical addresses are necessary or good here. It is only
useful if the memory region is contiguous. But physical addresses can
be recovered easily from virtual addresses even if the memory is
discontiguous. The memory should just be contiguous to permit dump
routines to be as simple as possible.
The type of `length' is bogus. It should be size_t or vm_size_t.
off_t is for lengths of files, not for sizes of memory. dumpstatus()
has the same bogon.
| Quote: | To register a dumping function, the driver fills out a data
structure and calls set_dumper():
struct dumperinfo {
dumper_t *dumper; /* Dumping function. */
void *private; /* Private parts. */
u_int blocksize; /* Size of block in bytes. */
off_t mediasize; /* Space available in bytes. */
};
int set_dumper(struct dumperinfo *);
Only one dumping function can be registered at a time, the current
registration can be cleared by calling set_dumper(NULL);
|
Not necessary or good. The current d_dump entry point is sufficient,
provided its type is changed to something like that above and its
semantics is changed to always do a complete intialization and
finalization for each memory region. The dump function needs to be
told where to write the dump (for each memory region) so that all dump
functions doesn't have to know about layers like slices and partitions.
You would need something like the above to handle non-disks, but I
think it should not be designed before we have experience with non-disk
dump routines. Dumps to tape probably shouldn't do a finalization for
each memory region... It's probably right for dump routines for non-disks
to make their devices look like disks (accept memory regions that are
blocked suitably for disks, and add headers and padding if necessary to
compensate for unusual block sizes).
| Quote: | The configuration mechanism for disks will change so that dumpon(
will open the device and issue an ioctl to turn dumping on this device
on/off, rather than the current sysctl based mechanism.
|
sysctls are wrong for almost everything  .
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Sun Mar 31, 2002 12:17 am Post subject:
Re: Rewamping kernel dumps...
|
|
|
Dag-Erling Smorgrav wrote:
| Quote: | Poul-Henning Kamp <phk@critter.freebsd.dk> writes:
I would probably have stuck it all into tar(1) format from the
beginning of the partition. One file for the msgbuf, one file for
a ram snapshot etc etc.
You can't put it at the beginning of the partition, because
savecore( can't run before fsck(, and fsck( may cause the system
to swap and overwrite the core dump before savecore( has had a
chance to save it.
|
You kind of want swapping to be enabled with swapon on all
devices, rather than implicitly enabled on one device at
boot time, so that unless you explicitly enable it, you do
not have *any* swap available.
IMO, fsck is just as likely to fail from a lack of 5 swap
devices as it is to fail for lack of 1. The code needs to
run in the available memory, rather than in more than the
available memory.
This would resolve the problem entirely. Also making FreeBSD
able to run swap-less without a panic would clean up a couple
other problems, which show up when you don't configure any swap
at all, or show up exceedingly rarely and are impossible to
really track down under swap exhaustion.
Matt would be a good person to comment, at this point, since
he has done a lot of work on how the system behaves under
resource exhaustion conditions.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Sat Mar 30, 2002 11:19 pm Post subject:
Re: Rewamping kernel dumps...
|
|
|
Poul-Henning Kamp <phk@critter.freebsd.dk> writes:
| Quote: | I would probably have stuck it all into tar(1) format from the
beginning of the partition. One file for the msgbuf, one file for
a ram snapshot etc etc.
|
You can't put it at the beginning of the partition, because
savecore( can't run before fsck(, and fsck( may cause the system
to swap and overwrite the core dump before savecore( has had a
chance to save it.
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Sat Mar 30, 2002 7:29 pm Post subject:
Re: Rewamping kernel dumps...
|
|
|
Poul-Henning Kamp wrote:
| Quote: | Device drivers can provide a dumping function, which will act as
an blocked sequential write device. This _can_ be the traditional
swap-partition-on-disk, but it could also be tapes or TFTP over a
network interface.
|
Did anyone else bring up "dump/restore" when Poul originally
removed block devices from FreeBSD?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Sat Mar 30, 2002 6:28 pm Post subject:
Re: Rewamping kernel dumps...
|
|
|
In message <xzpofh5svs9.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
| Quote: | Poul-Henning Kamp <phk@freebsd.org> writes:
Here is what I plan to do to the kernel dumping code.
[...]
Sounds good.
I understand that various people have some ideas about the layout of
the dump on the sequential media, this is an area I will not be involved
in, and I suggest people interested hash this out somehow.
I uphold my earlier suggestion of a block of metadata formatted as
text.
|
I would probably have stuck it all into tar(1) format from the
beginning of the partition. One file for the msgbuf, one file for
a ram snapshot etc etc.
But as I said, I'm not writing that bit.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Sat Mar 30, 2002 6:25 pm Post subject:
Re: Rewamping kernel dumps...
|
|
|
Poul-Henning Kamp <phk@freebsd.org> writes:
| Quote: | Here is what I plan to do to the kernel dumping code.
[...]
|
Sounds good.
| Quote: | I understand that various people have some ideas about the layout of
the dump on the sequential media, this is an area I will not be involved
in, and I suggest people interested hash this out somehow.
|
I uphold my earlier suggestion of a block of metadata formatted as
text. To accomodate both sequential-access and random-access media,
the size of this metadata block should be fixed (64k sound OK?), and
it should be written out before and after the dump - before so you can
read it and the dump off a tape without any seeking, and after so it
can be found in a fixed location on a disk partition (since the dump
is written at the end rather than the beginning of the partition).
This eliminates the need for libkvm, and makes it possible to save a
dump anywhere, anytime - currently, you have to run the kernel that
crashed on the system that crashed, or an identical system, for
savecore( to work.
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Sat Mar 30, 2002 3:39 pm Post subject:
Rewamping kernel dumps...
|
|
|
Here is what I plan to do to the kernel dumping code.
Device drivers can provide a dumping function, which will act as
an blocked sequential write device. This _can_ be the traditional
swap-partition-on-disk, but it could also be tapes or TFTP over a
network interface.
The function has the following type:
typedef int dumper_t(
void *private, /* Private to the driver. */
void *virtual, /* Virtual (mapped) address. */
void *physical, /* Physical address of virtual. */
off_t length); /* Number of bytes to dump. */
To register a dumping function, the driver fills out a data
structure and calls set_dumper():
struct dumperinfo {
dumper_t *dumper; /* Dumping function. */
void *private; /* Private parts. */
u_int blocksize; /* Size of block in bytes. */
off_t mediasize; /* Space available in bytes. */
};
int set_dumper(struct dumperinfo *);
Only one dumping function can be registered at a time, the current
registration can be cleared by calling set_dumper(NULL);
Once a dump is desired, a MD function is called:
void dumpsys(struct dumperinfo *);
This function must dump any magic headers and any desired memory
in whatever order the format for the platform is by repeatedly
calling the struct dumperinfo->dumper function.
If the dumper function returns non-zero, the dump should be
aborted since the hardware (presumably) failed.
The configuration mechanism for disks will change so that dumpon(
will open the device and issue an ioctl to turn dumping on this device
on/off, rather than the current sysctl based mechanism.
I understand that various people have some ideas about the layout of
the dump on the sequential media, this is an area I will not be involved
in, and I suggest people interested hash this out somehow.
Comments ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 6:03 am | All times are GMT
|
|
Credit Counseling | Bankruptcy | Credit Cards UK | Debt Consolidation | Magic the Gathering
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
