S. Hakim Hamdani [ML] wrote: > Michael, Milan, > > This is what happens (from /var/adm/messages) when shutting down: > > May 30 17:23:07 asagao-jkk rpcbind: [ID 564983 daemon.error] rpcbind > terminating on signal. > May 30 17:23:34 asagao-jkk genunix: [ID 672855 kern.notice] syncing file > systems... > May 30 17:23:34 asagao-jkk genunix: [ID 904073 kern.notice] done > May 30 17:23:35 asagao-jkk unix: [ID 836849 kern.notice] > May 30 17:23:35 asagao-jkk ^Mpanic[cpu0]/thread=d0e9bde0: > May 30 17:23:35 asagao-jkk genunix: [ID 335743 kern.notice] BAD TRAP: type=e > (#pf Page fault) rp=d0e9bd44 addr=0 occurred in module "<unknown>" due to a > NULL pointer dereference [...]
> I had to disable the savecore feature because it ran my root filesystem full > till there was no space left (count 50 shutdowns, 25 clean, 25 dumped and > took up space and so on until one day the system complained there was no > space left on / ). a few things: - familiarise yourself with dumpadm. With that tool, you can find out where savecore writes the dumps to (defaults to /var/crash/<hostname>) and also change that to something different (eg /zpool/dumps/<hostname>) - you could also make /var/crash a seperate (bigger) filesystem, so even if that one filled up, / would still be OK. - save one or more of the dumps from the current location (unix.N and vmcore.N); if you can make them available on the internet, maybe someone will take the time and analyse them. - depending on what release vehicle you're using to acquire Nevada, you may have a well-defined channel for reporting incidents (I say "may" because I haven't looked into that). I'd suggest you use that. Include as much information as you have (including a pointer to at least one of the dumps mentioned above, and technical specs of your laptop). HTH Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion'
