Hi again,
Here is a short summary of what is missing in the microcode containers [1] [2].
I only included AMD family 15h and 17h.
Similar could be done for Intel CPUs.
I do believe having a latest microcode is a vital for the userspace security
because it provides
IBPB barrier.
Family 15h [1]
Hi Sherry,
Dne 5.6.2018 v 16:27 Hurwitz, Sherry napsal(a):
> Hi Rudolf, I have been investigating the status with the AMD release
> management, but I have not been given approval to publish any other
> microcode. I have been trying to track down why there might be a
> version in the wild that I h
Hi Sherry,
Many thanks for your efforts. Are there any technical restriction(s) of why the
OS bundled updates are not the latest available
version? I think we can't count much on hardware vendors to release microcode
updates in the BIOS in the timely manner. I also
think especially for older fam
e version issue
>> that Rudolf Marek has pointed out. Also, we still hope to see an
>> updated microcode for 16h architecture as well - it has not received
>> any updates for two years already
>
> True, but now at least it won't regress old boxes anymore, so we can
&
Commit-ID: e3811a3f74bd1ad773667b78323f396166891f3a
Gitweb: https://git.kernel.org/tip/e3811a3f74bd1ad773667b78323f396166891f3a
Author: Rudolf Marek
AuthorDate: Tue, 28 Nov 2017 22:01:06 +0100
Committer: Ingo Molnar
CommitDate: Wed, 6 Dec 2017 12:27:13 +0100
x86/cpufeatures: Make
Commit-ID: 2b67799bdf25d19690710a88c2bce9127cf3ba6f
Gitweb: https://git.kernel.org/tip/2b67799bdf25d19690710a88c2bce9127cf3ba6f
Author: Rudolf Marek
AuthorDate: Tue, 28 Nov 2017 22:01:06 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 29 Nov 2017 10:30:43 +0100
x86: Make
round obsolete on such CPUs.
Signed-Off-By: Rudolf Marek
Reviewed-and-tested-by: Borislav Petkov
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/amd.c | 7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arc
Hi Guys,
Even in "AMD Family 15h Models 60h-6Fh Processors" [1]
are ports3 and ports4 marked as "Reserved". Maybe we should limit "KERN" to 2
ports?
Thanks
Rudolf
[1] http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf
Hello all,
gives coretemp_cpu_callback -> coretemp_device_remove ->
platform_device_unregister, so coretemp seems to be what I have and you don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
careful about what it does. During a system sleep transition (suspend,
Hi,
Most likely you have distro and custom libsensors installed on the system. (and
different PATH for root)
Please check how many of libsensors libraries is installed.
Thanks,
Rudolf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
>> [ Rudolf, Mark, would it be acceptable to you to remove all the open
>> #ifdef HOTPLUG_CPU from this file and replace them with __cpuinit{data}
>> instead? That could increase size of modular builds, but would remain
>> consistent with rest of kernel, and make the file #ifdef-clean ... ]
of function coretemp_update_device()
Good catch. Thanks for the fixes.
Acked-by: Rudolf Marek <[EMAIL PROTECTED]>
Rudolf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGz0wO3J9wPJqZRNURAnerAKDiDMzqqvymSbvVuV
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
There is documentation file too. Documentation/hwmon/coretemp
Rudolf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGwzLV3J9wPJqZRNURAgdmAJ9az/Zm2rq1k+sxwivhS
Hi Rudolf,
just one more update:
When I put my machine into s2ram and make it resume, one of the coretemp
sensors gets lost. Ahh and I am already rmmod coretemp / loading
microcode after resume / insmod coretemp...
Hello, If I understand correctly you unload the driver before suspend. Resume,
Hello Soeren,
Sorry for the delay.
I'm ccing all lists maybe some other people are interested. There is known
errata AE18 which prevents coretemp from working correctly on some mobile Core
processors (family 6 model e). My driver refuses to load and now thanks to
soeren will not crash ;) Howe
Hi again,
Of course it is not there because I removed it myself :/ The "sensors" command
will just produce "general parse error" this is because of the unknown device
class (imho). So I removed that and forgot. Well now I have the sysfs files:
/sys/class/hwmon/hwmon2/device/:
bus fan0
Hello Luca,
Sorry for delay,
Ok, it makes sense :)
Name (FBUF, Package (0x06)
{
0x03,
CPUF,
CHAF,
PWRF,
CHPF,
CH2F
})
Clearly the first number is not the number of available readings (though
it matches the count in the other DSDTs I've seen); don't know what it
is :|
Hello all,
Sorry for the delay, I was hiking in the mountains.
this patch indeed fixes the problem. Thanks!
Jean, thanks for the quick fix! Well obviously my fault :/ Sorry.
Unfortunately the coretemp sensors are simply never there when that
patch is applied... which I guess was the intenti
Hi,
I have following readings:
w83627ehf-isa-0290
Adapter: ISA adapter
VCore: +1.52 V (min = +0.00 V, max = +1.74 V)
in1: +12.30 V (min = +13.46 V, max = +13.04 V) ALARM
AVCC: +3.36 V (min = +4.08 V, max = +3.95 V) ALARM
3VCC: +3.36 V (min = +4.05 V, max = +3.06 V) A
Hello all,
Sorry for the delay. Glad that someone took a look into this.
ATK0110 ATK0110:00: atk: adding...
ATK0110 ATK0110:00: board ID = A8VE-SE
ATK0110 ATK0110:00: temp 0: CPU Temperature [900-1250]
ATK0110 ATK0110:00: temp 1: MB Temperature [700-1250]
ATK0110 ATK0110:00: voltage 0: Vcore Volt
Hi all,
This did not make it into 2.6.21? Will it get into 2.6.22?
Well this does not depend on me. But this is already in mm:
+ x86-msr-add-support-for-safe-variants.patch added to -mm tree
(this night came some mail, that it has been added - same came few days back)
Rudolf
-
To unsubscrib
> Assuming no one else wants the job (ruik?) I'll start working with Jean to
> get things set up as soon as I can.
No, I already wrote that I do not have enough time :/ I will try to support you
at least with the reviews. Cool would be if someone would take a support role,
because I simply do not
Hello all,
First I would like to thank Jean for his great work even if could be seen as
"slow". He did the perfect job, allowing only just perfect code to enter the trees.
I haven't seen anything from Rudolf Marek, but he is definitely
qualified if he wants to step up. I'
Hello Mikael,
Maybe I'm in the minority here, but I for one strongly believe
that any attempt to access an MSR "which might not be there" is
inherently wrong. It implies that your HW detection is incomplete,
which in combination with MSR accesses means that you may end up
accessing MSRs that are
Hello all,
> I'm just wondering if it is right to export the functions msr_read and
> msr_write from arch/i386/kernel/msr.c, or if it would be better to put
> these functions in arch/i386/lib/msr-on-cpu.c with rdmsr_on_cpu and
> wrmsr_on_cpu.
I'm fixing this, please stay tuned. I will CC you in ne
Hello again,
I produced some code which I proposed in mail above. The patch is not for review
it is just a PoC to better show what I'm trying to do. It is a test case for my
motherboard which has W83627EHF chip and ACPI thermal method and w83627ehf
compete the device.
When no driver is loaded, ac
Hello all,
I was already thinking about some very general port forwarder,
(http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018788.html)
But I'm not able to find out how to do that painlessly. Even don't know if to
use the classes or even some new "bus" in driver model :/ some sugge
Hello all,
I got the DSDT from chuck and it seems there is nothing interesting - no
declaration of PCI_config for the registers. If someone wants to check it I can
send him the DSDT.
_TMP looks like this:
Store (\_SB.PCI0.LPC0.EC0.RTMP, Local0)
Store ("Current temp is: ", De
Hello Chuck,
I'm the author of K8temp. Please can you share with us your DSDT table?
(cat /proc/acpi/dsdt > /tmp/dsdt.bin)
> So, could ACPI and the k8temp driver be at odds?
Yes because ACPI AML code has no synchronization with Linux drivers. Second
reason is that ACPI AML code assign resource r
Hello all,
For my new coretemp driver[1], I need to execute the rdmsr on particular
processor. There is no such "global" function for that in the kernel so far.
The per CPU msr_read and msr_write are used in following drivers:
msr.c (it is static there now)
k8-edac.c (duplicated right now -
Hello,
1 Maxtor 6Y080P0 on primary IDE and 2 optical drives on secundary IDE (DVD-RW
master, CD-RW slave). all are connected with 80pin cables:
libata version 2.00 loaded.
pata_via :00:0f.1: version 0.2.0
ata1: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFC00 irq 14
ata2: PATA max UDMA/1
Hello Alan,
I would like to report my experience with new pata_via driver.
Short version: works (no data were trashed, during the investigation), but the
bits to detect the cable type are not set by BIOS.
There is also a bug in my BIOS, which kills the UDMA register.
Long version:
I have 80pi
32 matches
Mail list logo
