Intel bug incoming.

ralphbsz said:
VInstead of speculative execution and parallelism by implicitly running instructions from multiple threads at once, the parallelism is made explicit in the instruction stream.
Click to expand...

Though execution on Itanium is explicitly parallel (hence EPIC), your statement is not true. Depending on the template used in instruction encoding you can achieve instructions to be run in parallel (doesn't mean they always are).

But Itanium does speculative loads, predicts branches, ..

All my Itanium machines I own or support are HP-UX boxes. It surprised me that Intel included those microcodes (Itanium ones) under "Linux" packages.
I'm fairly confident to say HP-UX doesn't load any microcode during boot. But this microcode in general gives me headache past few days as I came to know I know less about CPUs I thought I know.
 
Thank you for that correction.

By the way, I'm sure you know, but others may not: Itanium can also run operating systems other than HP-UX, at the minimum OpenVMS (the old Digital Equipment VAX operating system, now sold and supported by HPE) and NonStop (the old Tandem operating system, again now from HPE). It also used to run Linux (I actually worked at HP a few cubicles away from the folks who did the first Linux port to Itanium in great secrecy), but Linux is no longer officially supported by RedHat, SUSE and the likes.
 
ralphbsz said:
Itanium can also run operating systems other than HP-UX,
Click to expand...

Indeed I do ; HP (hand-to-hand with Microsoft) even made an effort to sell Superdome where you can run Windows (R) in one of the npar you would create. Some of our customers had this solution few years back.

--
I think I saw you mentioned you worked for HP in ECC thread. I still work .. well, HP->HPE->DXC, so nowadays it's more tears in the eyes than not. But it was happy days 10years ago ..
 
lebarondemerde said:
For your interest, HERE.
Click to expand...
Either this x86info program is crap or devcpu-data fscked up the processor.
I guess the latter, because there was no notice in /var/log/messages about updating the microcode.
When run in root mode, x86info hangs. (It is the one from latest repos, installed just a few minutes ago)
When run in user mode, it says the processor is a tri-core processor with hyperthreading. It is a six-core processor with hyperthreading turned off in BIOS (to avoid thrashing).
As I have to exchange the keyboard for a cleaned one anyway, I'll reboot and check it again today or tomorrow.
 
Snurg

Mail the the maintainer, he is looking for feedback. Due to some Intel updates that were breaking some installations he is reworking the thing.
 
I did a pkg update/upgrade to make sure system is full up-to-date, powered off, changed keyboard, and rebooted.
Now updating microcode completely fails. ("Re-evalutation of CPU flags Failed."). :(
 
Snurg said:
I did a pkg update/upgrade to make sure system is full up-to-date, powered off, changed keyboard, and rebooted.
Now updating microcode completely fails. ("Re-evalutation of CPU flags Failed."). :(
Click to expand...
Here too. I wonder if my cpu is too old?
 
Snurg said:
I did a pkg update/upgrade to make sure system is full up-to-date, powered off, changed keyboard, and rebooted.
Now updating microcode completely fails. ("Re-evalutation of CPU flags Failed."). :(
Click to expand...

That's because the port (its rc.d script, specifically) is calling cpucontrol with flags that aren't available yet in a released system.

"-e" (re-evaluate flags) added to cpucontrol in head here:
https://svnweb.freebsd.org/base/hea...ucontrol.c?r1=327597&r2=327596&pathrev=327597

And merged into stable/11 here: (About two hours ago)
https://svnweb.freebsd.org/base/sta...ucontrol.c?r1=327871&r2=327870&pathrev=327871

So. Whenever 11.2 is cut, hopefully this will be resolved. Until then, ignore it. From the initial commit, the intent (of -e) is to "[...] allow the kernel to see the changes in the CPU features after micocode update."

The port could be patched to detect if these are available yet to mute / not execute the call when it will be certain to fail. It would be nice, but I'd rather the devs work on meltdown/spectre now and clean up these bits later... ;)
 
MarcoB said:
Here too. I wonder if my cpu is too old?
Click to expand...
How old? Mine was released in July 2012 and is listed in Intels' list of CPUs with microcode update...

Eric A. Borisch said:
That's because the port (its rc.d script, specifically) is calling cpucontrol with flags that aren't available yet in a released system.
Click to expand...
I haven't yet put it into the rc.conf... just did service microcodeblahblah onestart... does this also use the rc.d script?

Could it be possible to just download the microcode update from Intel and order devcpu-data to use that one?
 
Snurg said:
How old? Mine was released in July 2012 and is listed in Intels' list of CPUs with microcode update...
Click to expand...

Mine is a dual Xeon (nocona) from 2004. It's in the list but I have my doubts about Intel releasing patches for processors of this age...
 
arnab said:
Here is the Intel benchmarking results after Spectre & Meltdown patches
https://newsroom.intel.com/editoria...tial-performance-data-results-client-systems/
Click to expand...

Matt Dillon from DragonflyBSD would take exception to those numbers. :)
http://lists.dragonflybsd.org/pipermail/users/2018-January/335643.html

There's been a few updates to Matt's numbers that show the performance penalty shrinking, but in the workloads he's tested, the performance hit is significant.

Will be interesting to see some benchmarks next month when most of the mitigations and workarounds are in place, to see how AMD compares to Intel now. :)
 
arnab said:
Here is the Intel benchmarking results ...
Click to expand...
That should be written as the Intel on Windows benchmarking results.

At least they have the courtesy to tell us the expected error bars: +- 3%. So some benchmark improving by 3% is statistically perfectly expected.
 
Eric A. Borisch said:
Likely, but why?
Click to expand...
I was not sure whether cpucontrol took the right microcode file, so I thought maybe it could be worth a try to explicitly specify the file to use.

However, while looking into the thing and trying to understand, I got more confused.
As x86info hangs in root mode, and gives incorrect cpu information in user mode, I looked up the CPU info in dmesg. (Family=0x6 Model=0x2c Stepping=2)
Now, in the Intel download for this CPU, there is a releasenote file.
intel-ucode dirctory contains binary microcode files named in family-model-stepping pattern.
Click to expand...
So I expected to find a file 06-2c-02 there. But there is none. The nearest models present are 2a and 2d.
In /usr/local/share/cpucontrol/ I do not see a file matching these family/model/stepping either.
So I guess that the correct file might be 06-2d-06 (concluding from the code section in this post), respective /usr/local/share/cpucontrol/m6d206d6_00000619.fw (both are identical, at least for the versions before the rollback mentioned in post #189). (It might be the 06-2a-07 file instead, didn't look into this really)
So ucode-tool apparently extracts correctly from microcode.dat file, which Intel supplied to support legacy apps, to the files in /usr/local/share/cpucontrol. A better way imho would be to directly use the binary files supplied by Intel.

Then I tried cpucontrol -v -u /dev/cpuctlX -d /usr/local/share/cpucontrol, as being suggested by /usr/local/etc/rc.d/microcode_update.
I felt really disappointed. No verbosity at all (no output) and nothing in the system log.

Then I tried to find out more by looking into the code. There is no verbosity output code. Thus I conclude, that the verbosity flag is just a placebo setting an (unused) verbosity flag.
Edit: The verbosity output is done by WARN[X] macros but does not output. You must use -vvv to get meaningful output. Using this I found that the CPU model is being incorrectly identified - 0x0c instead of 0x2c.
Investigating this issue, I found that the method of identifying the processor model used in intel_update() is totally wrong. This sad fact is easy to find out when consulting Intel's instructions how to identify processors.​

I failed to find any code that does the transformation from cpu model/family/stepping to a particular filename.
Thus I guessed the microcode update fails because it does not get information what to upload to the cpu.

Looking deeper into cpucontrol.c I got the impression that do_update() walks through every file and tries passing it to intel_update() in intel.c.
In intel_update() there is a long sequence of checks, and it looks like there is something wrong in these checks, resulting in never reaching the match jump label, where the actual cpu update is being done. (See also PR 192487 - cpucontrol uses unsafe procedure to detect current microcode version)

So, in my impression the whole approach is flawed. Intel provides a method to directly find which microcode update file is to be applied.
Instead of just using this one file, cpucontrol walks through all files and fails to identify the correct one. (See also PR 219269, which requests an option for specifying a particular file directly to avoid the problems introduced by this flawed approach)

My personal guess is it's this issue why the microcode_update thing has been retracted as mentioned in post #189, until the devs decided how to fix it.
 
The AMD CPU in my machine is so old, that there will not be any microcode updates for it. Doesn't matter since it's not an Intel CPU, I'm the only one that uses the machine, and there is no GUI (ssh access only) so there is no web browser to compromise.

With that being said, back in the early to middle 1990's while MS-DOS was still a big thing, I had to write some CPU identification code for some software that I was writing. It's a straight forward procedure in ASM. There are a series of steps that need to be performed. It would detect 8086/8088, 80186/80188, 80286, 80386, 80486, and Pentium. The procedure for everything below the Pentium would place the CPU in very specific conditions and watch the behavior. Mainly, it would exploit known bugs in the design to check what it was.

The pivot is 286. It would try to set a couple of bits in the flags register. If those bit could be set, then it was at least a 286. If not, then it was a 86/88 or an 186, 188. To differentiate between the 86/186, it checks with the SHR instruction. If the result was 0, then it was a 186, else it was a 188. Then it would check for the bus width by sizing the prefetch buffer to differentiate between 88/188 or 86/186.

To detect a 386 or higher, it would check to see if bit 14 of flags could be set. If not, then it really was a 286, else we test bit 23 of flags to see if it could be set. If so, then it's at least a 486. Then it would test bit 22 in flags and toggle. If the result was 0, then it really was a 486. But it if wasn't, that meant that it was a Pentium or higher and would return 586. That's as high as it would go.

Here's the code for that function written in Turbo Assembler:

Code: 
; *** Detect Main Processor Type

PROC DETECTCPU                 ; Called as function
  LOCAL CPUTYPE:WORD
  LOCALS @@
  PUSHF                        ; Save machine status word onto stack
  POP AX                       ; Load last push into AX register from stack
  AND AX, 03FFFH               ; Clear the 2 msbs
  PUSH AX                      ; Save AX register onto stack
  POPF                         ; Restore machine status word
  PUSHF                        ; Save machine status word onto stack
  POP AX                       ; Load last push into AX register from stack
  AND AX, 0C000H               ; Mask all off but the 2 msbs
  JE @@CPU80286                ; If not set then we have a 286 or higher
  MOV CL, 021H                 ; Load CL register with shift value
  MOV AL, 0FFH                 ; Load AL with all ones
  SHR AL, CL                   ; Shift AL to the left
  CMP AL, 0                    ; Does AL = 0?
  MOV AX, 188                  ; Load AX register with 80188 cpu code
  JNE @@DOBUS                  ; If AL = 0 then jump
  MOV AX, 88                   ; Else load AX register with 8088 cpu code
 @@DOBUS:                      ; Routine to test width of data bus
  MOV BX, 1                    ; Put 1 into BX register
  MOV AL, [CS:TESTINST]        ; Get test instruction
  XOR AL, 8                    ; Change it
  MOV [CS:TESTINST], AL        ; Write it back to the code segment
  NOP                          ; These are to fill the processor queue
  NOP                          ; Processor no operation instruction
  NOP                          ; Processor no operation instruction
  NOP                          ; Processor no operation instruction
 TESTINST DB 043H              ; The test instruction
  SUB AX, BX                   ; Subtract result from cpu code for proper id
  MOV [CPUTYPE], AX            ; Put AX into CPU result variable
  JMP @@EXIT                   ; Jump to exit routine
 @@CPU80286:                   ; 80286 test begins here
P286                           ; Enable 286 instructions
  PUSHF                        ; Push flags onto stack
  POP AX                       ; Pop flags into AX register
  OR AX, 04000H                ; Set bit 14
  PUSH AX                      ; Push AX register onto stack
  POPF                         ; Pop AX register into flags
  PUSHF                        ; Save flags once again
  POP AX                       ; And put it back into AX register
  AND AH, 040H                 ; Mask all but bit 14
  CMP AH, 040H                 ; Does bit 14 = 1?
  JE @@CPU80386                ; If so then we have at least a 386
  MOV [CPUTYPE], 286           ; Load 80286 cpu code into result variable
  JMP @@EXIT                   ; Jump to exit routine
 @@CPU80386:                   ; 80386 test begins here
P386                           ; Enable 386 instructions
  PUSHFD                       ; Push extended flags onto stack
  POP EAX                      ; Load EAX register with Eflags
  MOV EBX, EAX                 ; Save to EBX register
  AND EBX, 040000H             ; Mask off all but bit 23
  XOR EAX, 040000H             ; Toggle bit 23
  PUSH EAX                     ; Save EAX to stack
  POPFD                        ; Restore flags
  PUSHFD                       ; Save flags
  POP EAX                      ; Load EAX register with Eflags from stack
  AND EAX,040000H              ; Mask off all but bit 23
  MOV [CPUTYPE], 386           ; Load 80386 cpu code into result variable
  CMP EAX, EBX                 ; Did the toggle hold?
  JE @@EXIT                    ; If not then jump to exit routine
P486                           ; Enable 486 instructions
  PUSHFD                       ; Save flags onto stack
  POP EAX                      ; And load into EAX register
  XOR EAX, 040000H             ; Toggle bit 23 of flags
  PUSH EAX                     ; Push EAX register onto stack
  POPFD                        ; And restore into Eflags register
  MOV [CPUTYPE], 486           ; Load 80486 cpu code into result variable
  PUSHFD                       ; Push extended flags onto stack
  PUSHFD                       ; Again
  POP ECX                      ; Load into ECX register
  POP EAX                      ; Load into EAX register
  XOR EAX, 020000H             ; Toggle bit 22 in EAX register
  PUSH EAX                     ; Save EAX onto stack
  POPFD                        ; Restore Eflags
  PUSHFD                       ; Save Eflags once again
  POP EAX                      ; Load back into Eflags
  XOR EAX, ECX                 ; Toggle all bits
  JZ @@EXIT                    ; Cpu really is a 486 so jump to exit routine
 @@CPU80586:                   ; Cpu is a 586 or higher
  MOV [CPUTYPE], 586           ; Put 586 into return variable
 @@EXIT:                       ; Exit routine begins here
P8086                          ; Enable 8086/8088 instructions
  MOV AX, [CPUTYPE]            ; Put result variable into AX register
  RET                          ; Return to caller
ENDP

Snurg said:
I was not sure whether cpucontrol took the right microcode file, so I thought maybe it could be worth a try to explicitly specify the file to use.
Click to expand...

As a student of computer science myself, what I do not understand is why use the shotgun approach rather than use Intel's procedure to determine which file to load? I mean, the procedure is published by the CPU vendor so why not use it? It would cause a lot less headaches if people coded to spec as documented instead of trying to do something quick and dirty, which might bite you in the long run.

But that's me.
 
You must log in or register to reply here.
Back
Top