NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

bin/52414: cpuctl(8)/cpuctl(4) shortcomings

>Number:         52414
>Category:       bin
>Synopsis:       cpuctl(8)/cpuctl(4) shortcomings
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 17 11:10:00 +0000 2017
>Originator:     Paul Goyette
>Release:        NetBSD 8.99.1
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
System: NetBSD 8.99.1 NetBSD 8.99.1 (SPEEDY 2017-06-28 12:54:24 UTC) #0: Wed Jun 28 17:26:09 UTC 2017 amd64
Architecture: x86_64
Machine: amd64
(I've marked this as a doc-bug even though there are suggestions for
improving the code itself.  Please feel free to recategorize if needed.

Current the cpuctl(8) man-page is very amd centric for the microcode update
function.  It specifies an amd-specific default filename and the FILES
section lists only the /libdata/firmware/x86/amd/ directory.  It also
provides a download URL for the microcode files only for amd!

It might also be nice for the code to be changed to detect Intel-vs-AMD
characteristic and apply different defaults.  (For Intel, the default
file could be /libdata/firmware/x86/intel/FF-MM-SS since the Intel files
as currently distributed are named for the CPU's Family-Model-Stepping.)

It certainly doesn't make sense to have an amd-specific default filename
for non-amd processors.  Preferably the code will validate that the file
used is appropriate for the processor in question.  Which brings up yet
another shortcoming of the current man-page and/or code:  are there any
reasonable DIAGNOSTICS issued if the microcode file is not appropriate
for the processor being updated?  And/or is there any iBUG/CAVEAT needed
to warn users that applying an incorrect microcode file might render the
processor unuseable?

Finally, the cpuctl(8) utility apparently uses a pseudo-device cpuctl(4).
Yet there is no man-page for cpuctl(4), so there exists no documentation
on the mechanism for retrieving or updating the information.  Since the
cpuctl(4) pseudo-device is included in all kernels by default, it only
seems reasonable to document the device interface.



Home | Main Index | Thread Index | Old Index