Date: 27 Jul 1998 22:09:34 +0200 From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) To: David Wolfskill <dhw@whistle.com> Cc: mike@smith.net.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Checking RAM Message-ID: <xzpogub5a4h.fsf@hrotti.ifi.uio.no> In-Reply-To: David Wolfskill's message of "Mon, 27 Jul 1998 11:42:01 -0700 (PDT)" References: <199807271842.LAA25740@pau-amma.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Wolfskill <dhw@whistle.com> writes:
> >Date: Mon, 27 Jul 1998 11:25:51 -0700
> >From: Mike Smith <mike@smith.net.au>
>
> >> However, as a follow-on to a discussion I was having with someone else
> >> (where I was doing a bunch of whining about the challenges I was having
> >> in "automatically" being able to determine the configuration of a given
> >> FreeBSD box), the random idea came up that *IF* the kernel could stash
> >> away the results of its probing in some way that might be amenable to
> >> access by suitably-privileged processes at times arbitrarily distant
> >> from re-boot (i.e, scannning logs & output of dmesg won't do the job),
> >> this *might* be sufficiently useful to warrant some effort.
>
> >Something like /var/run/dmesg.boot, perhaps?
>
> Yes, that's an excellent start -- thanks!
>
> However, unless I'm even less clueful than usual, that needs some
> augmentation if someone should be reasonably expected to take that file
> & be able to reconstruct the machine on which the file was created
> (assuming, say, "dump" backup images for all filesystems).
>
> For example, information about disk partitioning would seem to be
> necessary, as well as interpreting the "dmesg" output so someone could
> determine what cards go in what slots (assuming it makes a difference?).
If you're running a DEVFS/SLICE system, disk slices and partitions
will be probed in a manner similar to "real" devices and output from
this process will appear in dmesg.boot:
sd0: probing for MBR.. rejected.. Slice includes MBR sd0: probing for disklabel.
. part a, start=0, size=131072
part b, start=131072, size=1048576
part d, start=3932160, size=4958600
part e, start=1179648, size=131072
part f, start=1310720, size=524288
part g, start=1835008, size=1048576
part h, start=2883584, size=1048576
sd1: probing for MBR.. rejected.. Slice includes MBR sd1: probing for disklabel.
. part e, start=0, size=524288
part f, start=524288, size=1572864
part g, start=2097152, size=10560565
sd2: probing for MBR.. part 1, start=63, size=2104452
sd2s1: attaching disklabel..
part e, start=0, size=524288
part f, start=524288, size=1580164
In the non-SLICE case, I don't see any other solution than 'cat
/etc/fstab' and a few judicious disklabel(8) runs.
As to "what cards go in what slots", it's only relevant for PCI cards.
You'll notice PCI devices have "on pcix.xx.x" at the end of the probe
line:
de0: <Digital 21140A Fast Ethernet> rev 0x22 int a irq 15 on pci0.9.0
vga0: <Tseng Labs ET6000 graphics accelerator> rev 0x70 int a irq 9 on pci0.10.0
ahc0: <Adaptec 2940 Ultra SCSI host adapter> rev 0x00 int a irq 12 on pci0.11.0
ahc1: <Adaptec 2940 SCSI host adapter> rev 0x00 int a irq 11 on pci0.12.0
The first number ('0'in 'pci0') is the bus number; the second is the
slot number. In my case, the ordering of the cards is highly relevant,
since the order in which the SCSI adapters are probed determines the
order in which the disks are attached.
DES
--
Dag-Erling Smørgrav - dag-erli@ifi.uio.no
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpogub5a4h.fsf>