On 9/5/05, Nick Holland <[EMAIL PROTECTED]> wrote: > The first "word" of most dmesg lines is a device driver, and in this > case, they all are: pchb, ppb, pci, vga, wsdisplay, pcib, pciide, wd. > And (get this!) they each have a man page! Is that cool or what? :) > > So, you want to learn about wsdisplay, "man 4 wsdisplay".
IMO, this is one of the best features of the *BSDs. Once when ssh'd into a Linux box and failing to remember the proper module parameter syntax for parport and parport_pc, I thought something was seriously wrong with the system when 'man 4 parport' failed to return anything, until I remembered that they didn't have man pages for every driver in Linux. (I suppose you could argue that something *is* seriously wrong with that, albeit by design.) I eventually found what I was looking for, either somewhere in the kernel tree, or by running strings on parport.ko, but a man page would have been a lot nicer! > yeah, I probably should write up a "how to read a dmesg" article, > probably be a little long for the FAQ (or maybe not, I *do* get to make > those decisions!), but there are other places it could be put. We could > end up with a whole chorus of people on misc@ beating the snot out of > people who don't post dmesgs or snip them down to only the part THEY > think we need. Might be a good thing. :) 'Twould be nice. I can parse a dmesg pretty well, but there are some esoterica in it I'm not sure about, such as the stuff at the end of the dmesg like this: === a) biomask e74d netmask ff4d ttymask ffef b) pctr: no performance counters in CPU c) dkcsum: wd0 matched BIOS disk 80 d) root on wd0a e) rootdev=0x0 rrootdev=0x300 rawdev=0x302 === a) I suppose these are masks that work much like umask, but I have no idea how to parse them. b) pctr has a man page, ok, easy enough... it's telling me a 486 lacks a TSC.. c) no man page for dkcsum but I can guess that it's computing a checksum of each [sw]d? hard disk (its MBR?) and comparing it to the BIOS disk list, which goes 0x80, 0x81, etc. to pair them up, although I thought that at this point in the boot process we're not using the BIOS INT13 routines any more, so it's purely informational. Close? d) Obvious to any competent user, I'd hope. e) The major/minor device numbers in /dev. wd0a is 0,0; rwd0a is 3,0; rwd0c is 3,2. Might not be obvious to someone not familiar with mknod, etc. (Hell, an explanation of the difference between wd0a and rwd0a would be a good FAQ entry); using device names (like wd0a) may be an improvement, unless the in-kernel device table is minimal, in which case there's no need to bloat it out. Putting an article in the FAQ would be nice, even if it's just "most drivers have a man page in section 4", as that's the first place I look after the man pages, as is occasionally more useful, such as for ppp -- it gives a nice basic config, but both the ppp.conf example file and the man page are LONG. Which isn't necessarily bad, but sometimes simple instructions are better. I see a little blip about section 4 for devices in FAQ 9.1, but it doesn't mention the dmesg there. While I'm on it, I can throw up a couple dmesgen from vastly different i386 boxen (and maybe a mac68k) and comment them, subject to your correction of course, if you'd like. Andrew
