Re: port-i386/39086: dmesg doesn't really identifies CPU any more

[Hisashi T Fujinaka <htodd%twofifty.com@localhost>]

The following reply was made to PR port-i386/39086; it has been noted by GNATS.

From: Hisashi T Fujinaka <htodd%twofifty.com@localhost>
To: Andrew Doran <ad%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, port-i386-maintainer%NetBSD.org@localhost,
        gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
        Bernhard Moellemann <zza%serpens.de@localhost>
Subject: Re: port-i386/39086: dmesg doesn't really identifies CPU any more
Date: Thu, 3 Jul 2008 09:11:42 -0700 (PDT)

 On Thu, 3 Jul 2008, Andrew Doran wrote:
 
 > On Thu, Jul 03, 2008 at 05:50:01AM +0000, Bernd Ernesti wrote:
 >> The following reply was made to PR port-i386/39086; it has been noted by 
 >> GNATS.
 >>
 >> From: Bernd Ernesti <netbsd%lists.veego.de@localhost>
 >> To: gnats-bugs%NetBSD.org@localhost
 >> Cc:
 >> Subject: Re: port-i386/39086: dmesg doesn't really identifies CPU any more
 >> Date: Thu, 3 Jul 2008 07:46:59 +0200
 >>
 >>  On Thu, Jul 03, 2008 at 07:34:41AM +0200, Christoph Egger wrote:
 >> >
 >> > The new way is to use "cpuctl identify <cpu>".
 >> > See cpuctl(8) for more information.
 >>
 >>  That will not work if you want to just boot from a cd or usb stick to
 >>  check the supported hardware, where you also get problems with the
 >>  disabled verbose options for an 'install' kernel.
 >
 > So what? The marketing name of the CPU that was reported means nothing. If
 > you want to identify the hardware, take the ID that is printed and google
 > for it.
 
 That's a rather broad statement. I work for a large chip manufacturer
 and it's difficult to keep track of the codename vs the part number,
 etc, and having BOTH is usually the best for usability because some
 people use the marketing name and others use the (even more ambiguous)
 part number.
 
 -- 
 Hisashi T Fujinaka - htodd%twofifty.com@localhost
 BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte