NetBSD Problem Report #15835

Received: (qmail 14707 invoked from network); 8 Mar 2002 11:01:43 -0000
Message-Id: <200203081101.g28B1fZ24395@munnnari.cs.mu.OZ.AU>
Date: Fri, 8 Mar 2002 22:01:41 +1100 (EST)
From: kre@munnari.OZ.AU
To: gnats-bugs@gnats.netbsd.org
Subject: alpha sysctl hw.model is inadequate
X-Send-Pr-Version: 3.95

>Number:         15835
>Category:       port-alpha
>Synopsis:       alpha sysctl hw.model is inadequate
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    thorpej
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 08 11:02:00 +0000 2002
>Closed-Date:    Thu Oct 15 01:01:14 +0000 2020
>Last-Modified:  Thu Oct 15 01:01:14 +0000 2020
>Originator:     Robert Elz
>Release:        NetBSD-current 2002-03-08
>Organization:
	University of Melbourne
>Environment:

System: NetBSD munnnari.cs.mu.OZ.AU 1.5ZA NetBSD 1.5ZA (MUNNARI) #5: Wed Dec 26 02:08:06 EST 2001 kre@munnnari.cs.mu.OZ.AU:/usr/src/sys/arch/alpha/compile/MUNNARI alpha


>Description:
	On an alpha, the sysctl variable hw.model gives manufacturer
	model brand naming, instead of something useful.

hw.machine = alpha
hw.model = COMPAQ AlphaServer DS10 466 MHz
hw.ncpu = 1
hw.byteorder = 1234
hw.physmem = 533979136
hw.usermem = 528744448
hw.pagesize = 8192
hw.machine_arch = alpha
hw.alignbytes = 7

	If you happen to know that a "COMPAQ AlphaServer DS10 466 MHz"
	is a 21264 (or ev6) that's fine.   But pkgsrc/devel/cpuflags
	(in particular) doesn't, and shouldn't need to.   Because of
	this, cpuflags resorts to grovelling in /var/run/dmesg.boot to
	try and find the cpu model number there.

	Unfortunately, for me, dmesg.boot starts ...

sing DMA data transfers)
siop0 at pci0 dev 14 function 0: Symbios Logic 53c895 (ultra2-wide scsi)
siop0: using on-board RAM
siop0: interrupting at dec 6600 irq 35
scsibus0 at siop0: 16 targets, 8 luns per target
isp0 at pci0 dev 15 function 0
isp0: interrupting at dec 6600 irq 39
isp0: NVRAM CHAN 0 FTHRSH 3 IID 7 RESETD 1 RETRYC 0 RETRYD 1 ASD 0x9
isp0: NVRAM RAAN 0x1 DLAN 0x1 DDMAB 0x1 CDMAB 0x1 SELTIME 250 MQD 256
isp0: NVRAM CHAN 0 TGT 0 FLAGS 0xfd00 0x8/0xc

	That's because there's way more than MSGBUFSIZ bytes of kernel
	boot mesages (which is always going to be a possibility with a
	fixed size buffer).
	[In my case, this is largely caused by lots of verbose raidctl
	autoconfig messages, but that's irrelevant]

>How-To-Repeat:
	run sysctl on an alpha...  (from looking in cpuflags, the
	same might be true on a vax).

>Fix:
	As a workaround, clearly I can make MSGBUFSIZ bigger (and will).
	But while that is a good idea for other reasons, having utilities
	grovel in dmesg.boot to extract information (with the possible
	exception of something like pkgsrc/sysutils/adjustkernel) is simply
	wrong.

	So, since the kernel knows the actual hardware model number (it
	is printed during the boot sequence...) please include that in the
	sysctl hw.model output. Something like

		hw.model = ev6 (21264) COMPAQ AlphaServer DS10 466 MHz

	would be just fine (as would numerous variations of that).
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: port-alpha-maintainer->thorpej
Responsible-Changed-By: thorpej@NetBSD.org
Responsible-Changed-When: Tue, 13 Oct 2020 15:43:26 +0000
Responsible-Changed-Why:
Take.


State-Changed-From-To: open->closed
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Thu, 15 Oct 2020 01:01:14 +0000
State-Changed-Why:
Comprehensive info about the CPU is now available via "sysctl hw.cpu0".


>Unformatted:

Home	PR Database Search