>
> I got another place where we might be able to stick a little bit of data,
> maybe in the CMOS. Doing something similiar to what the nvram driver
> does. So we'd be able to stuff all of 50bytes into the cmos. Now the
> question is...can we fit anything usable in there???
>
Just to poke my .02 in here.
Storing things in the CMOS is risky business. You don't know what
"undocumented" features are stored in there.
Novell dumps to floppy. It's kind of funny to watch an admin put in 180
disks for the 256MB RAM Novell server dump... Then you send the disks to
novell for "expert analysis". The recommendation - reboot the server...
;)
I would like to be able to specifiy the place that I want to dump things
to. Maybe add a kernel /proc entry: /proc/sys/kernel where I can write
the device major/minor number, a block size code and block count. E.g:
echo 1 > /proc/sys/kernel/dump-on-oops
echo 2 0 512 2880 > /proc/sys/kernel/dumpdev
A zip drive would be nice for this - I could hook up an external scsi
version, slip in a disk and let 'er oops. Once the problem is solved then
I could remove the zip drive and turn off the dump.
Right now I am wrestling with a 2.0.36 machine that is giving "Problem:
block on freelist" errors. I added some extra debugging to the kernel to
see what value was being written to the list. It turns out that there was
a bit error - bit 6 was on instead of off. So we dropped the bus speed of
the computer to see if that takes care of it. The moral to this story is
that if I would have had a dump of that kernel structure earlier, it would
have been easier to diagnose.
;-----------------------------------------;
; ; Chris Zwilling
; Don't let people drive you crazy ; chris@cloudnet.com
; when you know it's in walking distance ; System Administrator
; ; 320.240.8243
;-----------------------------------------;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/