--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Jan 28, 2006 at 11:51:19AM +0000, Darren Reed wrote:
> I'm quite dismayed that it is so hard to get information about a panic
> out of NetBSD.  Writing a crash dump doesn't appear to work (where the
> dump space is the same as swap) and nearly every time there is a panic,
> the system faults again in ddb, either locking ddb and the system up
> or just preventing you from getting what you need.

I'm sorry to say but i have to agree with Darren here. I'm using and have 
used several architectures running NetBSD but the i386 is on of the worst 
on crash information recovering. This is part due to the stated lack of 
messagebuffer survival and the wierd kernel coredump saving in the swap 
space. If the swap space is not twice the amount of memory in the machine 
dumping a kernel core is impossible. What would be better is a mechanism 
that either revovers kernel coredumps _before_ the swap is turned on or a 
mechanism that allows the swapper to recognize kernel coredumps so it can 
spare the dump as long as possible.

Can't the message buffer be saved in swap space too on each boot (voluntary 
or not) ?

I'd like to see a 3 types of objects in the current setup in swap space: 
the first few blocks of swap space for message buffer, followed by the 
kernel coredump and the rest if nessisary for swapping upto recovery is 
done.

On an other note, I also found in -current that ddb can print out correct 
stack traces but gdb can't on the kernel coredump.... we ought to get 
remote debugging working again.

Thoughts?

--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ9uxvIKcNwBDyKpoAQLmzggAsM6bah6+ivyo9Y54EJCbyrN9fQ4xWCSo
4IqEJSudWo71K3+GzfiMQt6x7GOiSphkqpOFXriwI3ljgoCv0iZpdW6twAA1KUcd
6Bs/1jjXy2c2GWJt9bB8llLCB4hijsnqYlH4sj2ihaWkE15LxOorIDTRpwDUf7Zh
4LXo+gVrMdySCKaO/IwuISmFwKnUffmR2Dc1/fu4FQAREnrn9NT0BnbXYswcjta5
1zuPxLBAr1Vceuyme9MuEXaorXYd1uweTnEQjMUqZogeIrhZgSGYnOC9fIduf14v
tihfU7bEKwwcrkRtZ5b41Br9Lyf6Acm3IjqOrbI3/9zKPO3iYWTxNQ==
=+10J
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--