Re: k10temp: ZEN3 readings are broken

Am Mi., 23. Dez. 2020 um 11:41 Uhr schrieb Jan Engelhardt : > > > On Tuesday 2020-12-22 04:58, Guenter Roeck wrote: > >On 12/21/20 5:45 PM, Gabriel C wrote: > >> Hello Guenter, > >> > >> while trying to add ZEN3 support for zenpower out of tree modules, I

Re: k10temp: ZEN3 readings are broken

Am Mi., 23. Dez. 2020 um 11:41 Uhr schrieb Jan Engelhardt : > > > On Tuesday 2020-12-22 04:58, Guenter Roeck wrote: > >On 12/21/20 5:45 PM, Gabriel C wrote: > >> Hello Guenter, > >> > >> while trying to add ZEN3 support for zenpower out of tree modules, I

Re: k10temp: ZEN3 readings are broken

Am Di., 22. Dez. 2020 um 07:16 Uhr schrieb Guenter Roeck : > > On Tue, Dec 22, 2020 at 05:33:17AM +0100, Gabriel C wrote: > [ ... ] > > At least is what the weird amd_energy driver added and since is only > > supporting > > fam 17h model 0x31 which is TR 3000 &

Re: k10temp: ZEN3 readings are broken

Am Di., 22. Dez. 2020 um 05:33 Uhr schrieb Wei Huang : > > > > On 12/21/20 9:58 PM, Guenter Roeck wrote: > > Hi, > > > > On 12/21/20 5:45 PM, Gabriel C wrote: > >> Hello Guenter, > >> > >> while trying to add ZEN3 support for zenpower

Re: k10temp: ZEN3 readings are broken

Am Di., 22. Dez. 2020 um 04:58 Uhr schrieb Guenter Roeck : > > Hi, > > On 12/21/20 5:45 PM, Gabriel C wrote: > > Hello Guenter, > > > > while trying to add ZEN3 support for zenpower out of tree modules, I find > > out > > the in-kernel k10temp driver is

k10temp: ZEN3 readings are broken

ing for both drivers: https://github.com/ocerman/zenpower/issues/39 Best Regards, Gabriel C

Re: Linux 5.9-rc7

64bit defconfig. Best Regards, Gabriel C.

Re: Kernel 5.9-rc Regression: Boot failure with nvme

Am Sa., 29. Aug. 2020 um 19:57 Uhr schrieb Christoph Hellwig : > > On Sat, Aug 29, 2020 at 10:54:47AM -0700, Linus Torvalds wrote: > > Just adding Christoph to the participants list, since at a guess it's > > due to his changes whether they came from the nvme side or the dma > > side.. > > > >

Re: nr_cpu_ids vs AMD 3970x(32 physical CPUs)

Am Fr., 3. Juli 2020 um 19:45 Uhr schrieb Peter Zijlstra : > > On Fri, Jul 03, 2020 at 07:07:39PM +0200, Gabriel C wrote: > > > I boot all the boxes restricting the cores to the correct count on the > > command line. > > This, because you're right about the wasted me

Re: nr_cpu_ids vs AMD 3970x(32 physical CPUs)

g CPUs ... [0.382122] smpboot: Max logical packages: 2 .. I boot all the boxes restricting the cores to the correct count on the command line. Wasted resource or not, this is still a bug IMO. Best Regards, Gabriel C

Re: ath9k broken [was: Linux 5.7.3]

Am Fr., 26. Juni 2020 um 15:51 Uhr schrieb Gabriel C : > > Am Fr., 26. Juni 2020 um 15:40 Uhr schrieb Greg Kroah-Hartman > : > > > > On Fri, Jun 26, 2020 at 01:48:59PM +0200, Gabriel C wrote: > > > Am Do., 25. Juni 2020 um 12:52 Uhr schrieb Gabriel C > > >

Re: ath9k broken [was: Linux 5.7.3]

Am Fr., 26. Juni 2020 um 15:40 Uhr schrieb Greg Kroah-Hartman : > > On Fri, Jun 26, 2020 at 01:48:59PM +0200, Gabriel C wrote: > > Am Do., 25. Juni 2020 um 12:52 Uhr schrieb Gabriel C > > : > > > > > > Am Do., 25. Juni 2020 um 12:48 Uhr schrieb Gabriel C >

Re: ath9k broken [was: Linux 5.7.3]

Am Do., 25. Juni 2020 um 12:52 Uhr schrieb Gabriel C : > > Am Do., 25. Juni 2020 um 12:48 Uhr schrieb Gabriel C > : > > > > Am Do., 25. Juni 2020 um 06:57 Uhr schrieb Jiri Slaby > > : > > > > > > On 25. 06. 20, 0:05, Gabriel C wrote: > > > &

Re: ath9k broken [was: Linux 5.7.3]

Am Do., 25. Juni 2020 um 12:48 Uhr schrieb Gabriel C : > > Am Do., 25. Juni 2020 um 06:57 Uhr schrieb Jiri Slaby : > > > > On 25. 06. 20, 0:05, Gabriel C wrote: > > > Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman > > > : > > >> >

Re: ath9k broken [was: Linux 5.7.3]

Am Do., 25. Juni 2020 um 06:57 Uhr schrieb Jiri Slaby : > > On 25. 06. 20, 0:05, Gabriel C wrote: > > Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman > > : > >> > >> I'm announcing the release of the 5.7.3 kernel. > >> > > > >

Re: Linux 5.7.3

ed the reporter to CC too. https://gist.github.com/AngryPenguinPL/1e545f0da3c2339e443b9e5044fcccea If you need more info, please let me know and I'll try my best to get it as fast as possible for you. Best Regards, Gabriel C

Re: Linux 5.8-rc1

Am Di., 16. Juni 2020 um 23:25 Uhr schrieb Arvind Sankar : > > On Tue, Jun 16, 2020 at 11:17:08PM +0200, Gabriel C wrote: > > Am Di., 16. Juni 2020 um 22:33 Uhr schrieb Arvind Sankar > > : > > > > > > Can you attach the output of gcc -dumpspecs and gcc -v? I

Re: Linux 5.8-rc1

Am Di., 16. Juni 2020 um 23:17 Uhr schrieb Gabriel C : > > Am Di., 16. Juni 2020 um 22:33 Uhr schrieb Arvind Sankar > : > > Does this patch help? > > > > I'll test in a bit and let you know. With the patch the kernel compiles fine. > > diff --git a/arch/

Re: Linux 5.8-rc1

Am Di., 16. Juni 2020 um 22:37 Uhr schrieb Borislav Petkov : > > On Tue, Jun 16, 2020 at 10:11:46PM +0200, Gabriel C wrote: > > I didn't look closer at that but from the error, it seems to be, > > some missing -fstack-protector* vs -fno-stack-protector* checks > > somewhere

Re: Linux 5.8-rc1

Am Di., 16. Juni 2020 um 22:33 Uhr schrieb Arvind Sankar : > > On Tue, Jun 16, 2020 at 10:11:46PM +0200, Gabriel C wrote: > > * Am So., 14. Juni 2020 um 22:44 Uhr schrieb Linus Torvalds > > : > > > > Hello, > > > > > So I didn't really expect

Re: Linux 5.8-rc1

x86/purgatory/purgatory.ro: in function `_kstrtoull': string.c:(.text+0x2107): undefined reference to `__stack_chk_fail' I didn't look closer at that but from the error, it seems to be, some missing -fstack-protector* vs -fno-stack-protector* checks somewhere. Best Regards, Gabriel C

Re: Linux 5.3.6

rch/x86/entry] Error 2 > make[1]: *** Waiting for unfinished jobs > What is your default linker ? Also does make LD=ld.bfd fixes that for you ? See https://bugzilla.kernel.org/show_bug.cgi?id=204951 BR, Gabriel C.

Re: acer_wmi: Unknown function(s) on Acer Nitro 5 (AN515-43-R8BF)

Am Mi., 25. Sept. 2019 um 09:53 Uhr schrieb Joey Lee : > > Hi Gabriel, > > On Mon, Sep 23, 2019 at 09:45:05PM +0200, Gabriel C wrote: > > Hi guys, > > > > I noticed some warning in dmesg on this Laptop. > > > > Fn+right, Fn+left is Brightnes

acer_wmi: Unknown function(s) on Acer Nitro 5 (AN515-43-R8BF)

1. I uploaded a dump of the acpi tables and dmidecode of the box. https://www.frugalware.org/~crazy/nitro5/ACPI https://www.frugalware.org/~crazy/nitro5/DMI Please let me know if you need any other informations. Best Regards, Gabriel C

Re: nvme vs. hibernation ( again )

Am Do., 12. Sept. 2019 um 02:51 Uhr schrieb Ming Lei : > > On Thu, Sep 12, 2019 at 12:27 AM Gabriel C wrote: > > > > Hi Christoph, > > > > I see this was already discussed in 2 threads: > > > > https://lists.infradead.org/pipermail/linux-nvme/2019-Ap

Re: [PATCH v2] Added QUIRKs for ADATA XPG SX8200 Pro 512GB

Am Mi., 11. Sept. 2019 um 23:33 Uhr schrieb Jens Axboe : > > On 9/11/19 3:21 PM, Gabriel C wrote: > > Booting with default_ps_max_latency_us >6000 makes the device fail. > > Also SUBNQN is NULL and gives a warning on each boot/resume. > >$ nvme id-ctr

Re: [PATCH] Added QUIRKs for ADATA XPG SX8200 Pro 512GB

Am Mi., 11. Sept. 2019 um 19:39 Uhr schrieb Gabriel C : > > Am Mi., 11. Sept. 2019 um 19:21 Uhr schrieb Sagi Grimberg : > > > > This does not apply on nvme-5.4, can you please respin a patch > > that cleanly applies? > > Sure , just tell me from where to pull nvme-5.

[PATCH v2] Added QUIRKs for ADATA XPG SX8200 Pro 512GB

Booting with default_ps_max_latency_us >6000 makes the device fail. Also SUBNQN is NULL and gives a warning on each boot/resume. $ nvme id-ctrl /dev/nvme0 | grep ^subnqn subnqn: (null) I use this device with an Acer Nitro 5 (AN515-43-R8BF) Laptop. To be sure is not a Laptop issue

Re: [PATCH] Added QUIRKs for ADATA XPG SX8200 Pro 512GB

Am Mi., 11. Sept. 2019 um 19:21 Uhr schrieb Sagi Grimberg : > > This does not apply on nvme-5.4, can you please respin a patch > that cleanly applies? Sure , just tell me from where to pull nvme-5.4 tree. My match was against current Linus tree.

nvme vs. hibernation ( again )

egards, Gabriel C

[PATCH] Added QUIRKs for ADATA XPG SX8200 Pro 512GB

Booting with default_ps_max_latency_us >6000 makes the device fail. Also SUBNQN is NULL and gives a warning on each boot/resume. $ nvme id-ctrl /dev/nvme0 | grep ^subnqn subnqn: (null) I use this device with an Acer Nitro 5 (AN515-43-R8BF) Laptop. To be sure is not a Laptop issue

Re: [Kernel 5.1] ACPI_DEBUG messages without CONFIG_ACPI_DEBUG being set

Am Di., 7. Mai 2019 um 22:17 Uhr schrieb Schmauss, Erik : > > > > > -Original Message- > > From: Gabriel C [mailto:nix.or@gmail.com] > > Sent: Tuesday, May 7, 2019 12:06 PM > > To: Schmauss, Erik > > Cc: Rafael J. Wysocki ; ACPI Devel Maling List

Re: [Kernel 5.1] ACPI_DEBUG messages without CONFIG_ACPI_DEBUG being set

Am Di., 7. Mai 2019 um 20:46 Uhr schrieb Schmauss, Erik : > > > > > -Original Message- > > From: Gabriel C [mailto:nix.or@gmail.com] > > Sent: Tuesday, May 7, 2019 2:33 AM > > To: Rafael J. Wysocki > > Cc: ACPI Devel Maling List ; LKML &g

Re: [Kernel 5.1] ACPI_DEBUG messages without CONFIG_ACPI_DEBUG being set

Am Di., 7. Mai 2019 um 10:35 Uhr schrieb Rafael J. Wysocki : > > On Tue, May 7, 2019 at 9:31 AM Gabriel C wrote: > > > > Am Di., 7. Mai 2019 um 09:01 Uhr schrieb Rafael J. Wysocki > > : > > > > > Hello Rafael , Erik > > > > > +Erik >

Re: [Kernel 5.1] ACPI_DEBUG messages without CONFIG_ACPI_DEBUG being set

Am Di., 7. Mai 2019 um 09:01 Uhr schrieb Rafael J. Wysocki : > Hello Rafael , Erik > +Erik > > On Tue, May 7, 2019 at 1:33 AM Gabriel C wrote: > > > > Hello, > > > > while testing kernel-5.1 I get on one of my Lenovo Laptops very > > strange 'ACPI Deb

[Kernel 5.1] ACPI_DEBUG messages without CONFIG_ACPI_DEBUG being set

ot;=QUERY_65=" If ((OSYS == 0x07D9)) { If (((BTEX == One) & (BTAT == One))) { SGOV (0x0202000B, One) } Else { SGOV (0x0202000B, Zero) } } } ... Any idea what would cause this ? BR, Gabriel C

Re: Warning at drivers/net/wireless/ath/ath10k/mac.c:5625 ath10k_bss_info_changed

Am Mo., 4. März 2019 um 12:59 Uhr schrieb Kalle Valo : > > Gabriel C writes: > > > Am Mo., 4. März 2019 um 12:28 Uhr schrieb Paul Menzel > > : > > > >> Resuming from ACPI S3 on the Dell XPS 13 9370 with Debian Sid/unstable, > >> Linux 4.19.20 sh

Re: Warning at drivers/net/wireless/ath/ath10k/mac.c:5625 ath10k_bss_info_changed

984] ---[ end trace 3af618ca97bd4a0a ]--- > ``` > > Please find all Linux messages attached. I reported that twice and no one seems to care about. http://lists.infradead.org/pipermail/ath10k/2018-November/012398.html http://lists.infradead.org/pipermail/ath10k/2018-December/012658.html BR, Gabriel C

ath10_pci: WARN(() on resume from S3

f more infos are needed. BR, Gabriel C

Re: FYI: Userland breakage caused by udev bind commit

Am Mo., 24. Dez. 2018 um 11:54 Uhr schrieb Greg KH : > > On Mon, Dec 24, 2018 at 11:15:34AM +0100, Gabriel C wrote: > > Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Greg KH > > : > > > > > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > &

Re: FYI: Userland breakage caused by udev bind commit

Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Dmitry Torokhov : > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > > Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov > > : > > > > [ also added Linus to CC on that one too ] > > > > &g

Re: FYI: Userland breakage caused by udev bind commit

Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Greg KH : > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > > Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov > > : > > > > [ also added Linus to CC on that one too ] > > > > &g

Re: FYI: Userland breakage caused by udev bind commit

Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov : [ also added Linus to CC on that one too ] > > On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote: > > On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote: > > > Hi, > > > > > > I am the maintainer of libmtp

Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn

Am So., 23. Dez. 2018 um 00:02 Uhr schrieb Linus Torvalds : > > On Sat, Dec 22, 2018 at 2:49 PM Christian Brauner > wrote: > > > > To be fair, no one apart from me was pointing out that it actually > > breaks people including systemd folks > > even though I was bringing it up with them. I even

Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn

Added some people to CC that might want to see this.. Am Sa., 22. Dez. 2018 um 19:14 Uhr schrieb Ellie Reeves : > > Hi, > first off, allow me to express that this is my first time ever writing > on such a mailing list, and that if something is unclear or you would > need more information, just

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

2018-07-06 18:33 GMT+02:00 Kirill A. Shutemov : > On Fri, Jul 06, 2018 at 04:39:28PM +0200, Gabriel C wrote: >> > If not, we do not need to think about that case. >> > Just say "Do not do that". >> >> I am sorry but I have a hard time to get your

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

2018-07-06 18:33 GMT+02:00 Kirill A. Shutemov : > On Fri, Jul 06, 2018 at 04:39:28PM +0200, Gabriel C wrote: >> > If not, we do not need to think about that case. >> > Just say "Do not do that". >> >> I am sorry but I have a hard time to get your

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

2018-07-06 16:13 GMT+02:00 Masahiro Yamada : > Hi. > > 2018-07-06 19:41 GMT+09:00 Kirill A. Shutemov : >> On Fri, Jul 06, 2018 at 03:37:58PM +0900, Masahiro Yamada wrote: >>> >> > > Also see https://bugzilla.kernel.org/show_bug.cgi?id=200385 , >>> >> > > >>> >> > >

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

2018-07-06 16:13 GMT+02:00 Masahiro Yamada : > Hi. > > 2018-07-06 19:41 GMT+09:00 Kirill A. Shutemov : >> On Fri, Jul 06, 2018 at 03:37:58PM +0900, Masahiro Yamada wrote: >>> >> > > Also see https://bugzilla.kernel.org/show_bug.cgi?id=200385 , >>> >> > > >>> >> > >

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

2018-07-01 23:32 GMT+02:00 Benjamin Gilbert : > On Sun, Jul 01, 2018 at 05:15:59PM -0400, Benjamin Gilbert wrote: >> 4.17 kernels built with the CoreOS Container Linux toolchain and kconfig, >> up to and including 4.17.3, fail to boot on AMD64 running in (at least) >> QEMU/KVM. No messages are

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

2018-07-01 23:32 GMT+02:00 Benjamin Gilbert : > On Sun, Jul 01, 2018 at 05:15:59PM -0400, Benjamin Gilbert wrote: >> 4.17 kernels built with the CoreOS Container Linux toolchain and kconfig, >> up to and including 4.17.3, fail to boot on AMD64 running in (at least) >> QEMU/KVM. No messages are

Re: Linux and autoconfig of kernel on iso-image boot.

2018-05-28 22:40 GMT+02:00 Phillip Hugo : > Hi all, thanks for your work. > > Linux should have "make grab_config" that sets loaded modules to be > built in the kernel build and make modules. > make localmodconfig ?

Re: Linux and autoconfig of kernel on iso-image boot.

2018-05-28 22:40 GMT+02:00 Phillip Hugo : > Hi all, thanks for your work. > > Linux should have "make grab_config" that sets loaded modules to be > built in the kernel build and make modules. > make localmodconfig ?

Re: smpboot seems to be confused on dual EPYC system

2018-05-28 1:16 GMT+02:00 Borislav Petkov <b...@alien8.de>: > On Mon, May 28, 2018 at 12:51:17AM +0200, Gabriel C wrote: >> 128CPUs for sure not possible and for sure no way to have '2' CPUs installed. > > With that last "'2' CPUs" you mean, two physical processor

Re: smpboot seems to be confused on dual EPYC system

2018-05-28 1:16 GMT+02:00 Borislav Petkov : > On Mon, May 28, 2018 at 12:51:17AM +0200, Gabriel C wrote: >> 128CPUs for sure not possible and for sure no way to have '2' CPUs installed. > > With that last "'2' CPUs" you mean, two physical processors and thus two > socke

Re: smpboot seems to be confused on dual EPYC system

2018-05-27 23:22 GMT+02:00 Gabriel C <nix.or@gmail.com>: > > 2018-05-27 22:07 GMT+02:00 Borislav Petkov <b...@alien8.de>: >> >> On Sun, May 20, 2018 at 03:23:32PM +0200, Gabriel C wrote: >> > Hello, >> > >> > I have an H11DSi-NT boar

Re: smpboot seems to be confused on dual EPYC system

2018-05-27 23:22 GMT+02:00 Gabriel C : > > 2018-05-27 22:07 GMT+02:00 Borislav Petkov : >> >> On Sun, May 20, 2018 at 03:23:32PM +0200, Gabriel C wrote: >> > Hello, >> > >> > I have an H11DSi-NT board with 2 * EPYC 7281 16C/32T CPUs. >> &

Re: smpboot seems to be confused on dual EPYC system

( sorry I didn't noticed google changed here something , resending to the list as plain text) 2018-05-27 23:22 GMT+02:00 Gabriel C <nix.or@gmail.com>: > > 2018-05-27 22:07 GMT+02:00 Borislav Petkov <b...@alien8.de>: >> >> On Sun, May 20, 2018 at 03:23:32PM +020

Re: smpboot seems to be confused on dual EPYC system

( sorry I didn't noticed google changed here something , resending to the list as plain text) 2018-05-27 23:22 GMT+02:00 Gabriel C : > > 2018-05-27 22:07 GMT+02:00 Borislav Petkov : >> >> On Sun, May 20, 2018 at 03:23:32PM +0200, Gabriel C wrote: >> > Hello, >>

smpboot seems to be confused on dual EPYC system

s, 64 CPUs [0.562171] smpboot: Max logical packages: 4 [0.562171] smpboot: Total of 64 processors activated (268089.53 BogoMIPS) Can someone have a look ? Best Regards, Gabriel C

smpboot seems to be confused on dual EPYC system

s, 64 CPUs [0.562171] smpboot: Max logical packages: 4 [0.562171] smpboot: Total of 64 processors activated (268089.53 BogoMIPS) Can someone have a look ? Best Regards, Gabriel C

Re: commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 seems to break with intel-ucode 20180425

2018-05-14 14:58 GMT+02:00 Peter Zijlstra <pet...@infradead.org>: > On Mon, May 14, 2018 at 02:15:44PM +0200, Gabriel C wrote: >> http://ftp.frugalware.org/pub/other/people/crazy/ucode/cpuinfo-ucode-20180312 >> http://ftp.frugalware.org/pub/other/people/crazy/ucode/c

Re: commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 seems to break with intel-ucode 20180425

2018-05-14 14:58 GMT+02:00 Peter Zijlstra : > On Mon, May 14, 2018 at 02:15:44PM +0200, Gabriel C wrote: >> http://ftp.frugalware.org/pub/other/people/crazy/ucode/cpuinfo-ucode-20180312 >> http://ftp.frugalware.org/pub/other/people/crazy/ucode/cpuinfo-ucode-20180425 > >

Re: commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 seems to break with intel-ucode 20180425

2018-05-14 9:23 GMT+02:00 Peter Zijlstra <pet...@infradead.org>: > On Sat, May 12, 2018 at 12:55:35PM +0200, Gabriel C wrote: >> Hi Peter, >> >> after updating ucode to 20180425 on my laptop I always hit the >> 'TSC_DEADLINE disabled' error and so early micr

Re: commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 seems to break with intel-ucode 20180425

2018-05-14 9:23 GMT+02:00 Peter Zijlstra : > On Sat, May 12, 2018 at 12:55:35PM +0200, Gabriel C wrote: >> Hi Peter, >> >> after updating ucode to 20180425 on my laptop I always hit the >> 'TSC_DEADLINE disabled' error and so early microcode update from >> inird br

commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 seems to break with intel-ucode 20180425

cpuid _fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves ibpb ibrs stibp dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp Best Regards, Gabriel C

commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 seems to break with intel-ucode 20180425

cpuid _fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves ibpb ibrs stibp dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp Best Regards, Gabriel C

Re: [PATCH 2/2] hwmon: (k10temp) Use API function to access System Management Network

2018-04-29 19:46 GMT+02:00 Guenter Roeck : > On 04/28/2018 06:54 PM, Guenter Roeck wrote: >> >> The SMN (System Management Network) on Family 17h AMD CPUs is also >> accessed >> from other drivers, specifically EDAC. Accessing it directly is racy. >> On top of that, accessing

Re: [PATCH 2/2] hwmon: (k10temp) Use API function to access System Management Network

2018-04-29 19:46 GMT+02:00 Guenter Roeck : > On 04/28/2018 06:54 PM, Guenter Roeck wrote: >> >> The SMN (System Management Network) on Family 17h AMD CPUs is also >> accessed >> from other drivers, specifically EDAC. Accessing it directly is racy. >> On top of that, accessing the SMN through root

Re: [PATCH] hwmon: (k10temp) Add support for Stoney Ridge and Bristol Ridge CPUs

2018-04-29 18:16 GMT+02:00 Guenter Roeck : > Add support for Stoney Ridge and Bristol Ridge (Family 15h Model 0x70) > CPUs. Registers match those of Family 15h Model 0x60. > > Signed-off-by: Guenter Roeck > --- > drivers/hwmon/k10temp.c | 5 + > 1 file

Re: [PATCH] hwmon: (k10temp) Add support for Stoney Ridge and Bristol Ridge CPUs

2018-04-29 18:16 GMT+02:00 Guenter Roeck : > Add support for Stoney Ridge and Bristol Ridge (Family 15h Model 0x70) > CPUs. Registers match those of Family 15h Model 0x60. > > Signed-off-by: Guenter Roeck > --- > drivers/hwmon/k10temp.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git

Re: [PATCH 2/2] hwmon: (k10temp) Display both Tctl and Tdie

2018-04-27 5:13 GMT+02:00 Guenter Roeck : > On some AMD CPUs, there is a different between the die temperature > (Tdie) and the reported temperature (Tctl). Tdie is the real measured > temperature, and Tctl is used for fan control. Lets report both for > affected CPUs. > >

Re: [PATCH 2/2] hwmon: (k10temp) Display both Tctl and Tdie

2018-04-27 5:13 GMT+02:00 Guenter Roeck : > On some AMD CPUs, there is a different between the die temperature > (Tdie) and the reported temperature (Tctl). Tdie is the real measured > temperature, and Tctl is used for fan control. Lets report both for > affected CPUs. > > Signed-off-by: Guenter

Re: [PATCH v2] hwmon: (k10temp) Fix reading critical temperature register

2018-04-29 17:08 GMT+02:00 Guenter Roeck : > The HTC (Hardware Temperature Control) register has moved > for recent chips. > > Signed-off-by: Guenter Roeck > --- > v2: Actually call the new function pointer from show_temp_crit(). > >

Re: [PATCH v2] hwmon: (k10temp) Fix reading critical temperature register

2018-04-29 17:08 GMT+02:00 Guenter Roeck : > The HTC (Hardware Temperature Control) register has moved > for recent chips. > > Signed-off-by: Guenter Roeck > --- > v2: Actually call the new function pointer from show_temp_crit(). > > drivers/hwmon/k10temp.c | 40

Re: [PATCH 2/2] hwmon: (k10temp) Use API function to access System Management Network

2018-04-29 3:54 GMT+02:00 Guenter Roeck : > The SMN (System Management Network) on Family 17h AMD CPUs is also accessed > from other drivers, specifically EDAC. Accessing it directly is racy. > On top of that, accessing the SMN through root bridge 00:00 is wrong on > multi-die

Re: [PATCH 2/2] hwmon: (k10temp) Use API function to access System Management Network

2018-04-29 3:54 GMT+02:00 Guenter Roeck : > The SMN (System Management Network) on Family 17h AMD CPUs is also accessed > from other drivers, specifically EDAC. Accessing it directly is racy. > On top of that, accessing the SMN through root bridge 00:00 is wrong on > multi-die CPUs and may result

Re: [PATCH 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

2018-04-29 3:54 GMT+02:00 Guenter Roeck : > Add Raven Ridge root bridge and data fabric PCI IDs. > This is required for amd_pci_dev_to_node_id() and amd_smn_read(). > > Signed-off-by: Guenter Roeck > --- > This patch is a prerequisite for the second patch

Re: [PATCH 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

2018-04-29 3:54 GMT+02:00 Guenter Roeck : > Add Raven Ridge root bridge and data fabric PCI IDs. > This is required for amd_pci_dev_to_node_id() and amd_smn_read(). > > Signed-off-by: Guenter Roeck > --- > This patch is a prerequisite for the second patch in the series. > I'll be happy to apply

Re: [PATCH 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

2018-04-29 3:54 GMT+02:00 Guenter Roeck : > Add Raven Ridge root bridge and data fabric PCI IDs. > This is required for amd_pci_dev_to_node_id() and amd_smn_read(). > > Signed-off-by: Guenter Roeck > --- > This patch is a prerequisite for the second patch

Re: [PATCH 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

2018-04-29 3:54 GMT+02:00 Guenter Roeck : > Add Raven Ridge root bridge and data fabric PCI IDs. > This is required for amd_pci_dev_to_node_id() and amd_smn_read(). > > Signed-off-by: Guenter Roeck > --- > This patch is a prerequisite for the second patch in the series. > I'll be happy to apply

Re: [RFC] Passing luks passphrase from grub to systemd

ht be sensible). I'd also be thankful for comments how this might be > implemented in a better way. Somethng like this is not needed. All that is possible already from userspace. Systemd can do that on his own ( see systemd-cryptsetup-generator ) ( other init ofc too ) assuming your initrd , cryptsetup and grub is setup correctly. Regards, Gabriel C

Re: [RFC] Passing luks passphrase from grub to systemd

I'd also be thankful for comments how this might be > implemented in a better way. Somethng like this is not needed. All that is possible already from userspace. Systemd can do that on his own ( see systemd-cryptsetup-generator ) ( other init ofc too ) assuming your initrd , cryptsetup and grub is setup correctly. Regards, Gabriel C

Re: AMD graphics performance regression in 4.15 and later

2018-04-12 0:20 GMT+02:00 Gabriel C <nix.or@gmail.com>: > 2018-04-11 20:35 GMT+02:00 Jean-Marc Valin <jmva...@mozilla.com>: >> On 04/11/2018 05:37 AM, Christian König wrote: >>>> With your patches my EPYC box is unusable with 4.15++ kernels. >>>>

Re: AMD graphics performance regression in 4.15 and later

2018-04-12 0:20 GMT+02:00 Gabriel C : > 2018-04-11 20:35 GMT+02:00 Jean-Marc Valin : >> On 04/11/2018 05:37 AM, Christian König wrote: >>>> With your patches my EPYC box is unusable with 4.15++ kernels. >>>> The whole Desktop is acting weird. This one is using

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 20:35 GMT+02:00 Jean-Marc Valin : > On 04/11/2018 05:37 AM, Christian König wrote: >>> With your patches my EPYC box is unusable with 4.15++ kernels. >>> The whole Desktop is acting weird. This one is using >>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E]

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 20:35 GMT+02:00 Jean-Marc Valin : > On 04/11/2018 05:37 AM, Christian König wrote: >>> With your patches my EPYC box is unusable with 4.15++ kernels. >>> The whole Desktop is acting weird. This one is using >>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU. >>> >>> Box is 2 *

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 16:26 GMT+02:00 Gabriel C <nix.or@gmail.com>: > 2018-04-11 11:37 GMT+02:00 Christian König <christian.koe...@amd.com>: >> Am 11.04.2018 um 06:00 schrieb Gabriel C: ... >> >> Please test Alex's amd-staging-drm-next branch from >> git://peopl

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 16:26 GMT+02:00 Gabriel C : > 2018-04-11 11:37 GMT+02:00 Christian König : >> Am 11.04.2018 um 06:00 schrieb Gabriel C: ... >> >> Please test Alex's amd-staging-drm-next branch from >> git://people.freedesktop.org/~agd5f/linux. > > I'm on it just

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 11:37 GMT+02:00 Christian König <christian.koe...@amd.com>: > Am 11.04.2018 um 06:00 schrieb Gabriel C: >> >> 2018-04-09 11:42 GMT+02:00 Christian König >> <ckoenig.leichtzumer...@gmail.com>: >>> >>> Am 07.04.2018 um 00

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 11:37 GMT+02:00 Christian König : > Am 11.04.2018 um 06:00 schrieb Gabriel C: >> >> 2018-04-09 11:42 GMT+02:00 Christian König >> : >>> >>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: >>>> >>>> Hi Christian, >

Re: AMD graphics performance regression in 4.15 and later

>2018-04-11 6:00 GMT+02:00 Gabriel C <nix.or@gmail.com>: > 2018-04-09 11:42 GMT+02:00 Christian König <ckoenig.leichtzumer...@gmail.com>: >> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: ... > I can help testing code for 4.17/++ if you wish but that is *different*

Re: AMD graphics performance regression in 4.15 and later

>2018-04-11 6:00 GMT+02:00 Gabriel C : > 2018-04-09 11:42 GMT+02:00 Christian König : >> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: ... > I can help testing code for 4.17/++ if you wish but that is *different* > storry. > Quick tested an 4.16.0-11490-gb284d4d5a678 , amd

Re: AMD graphics performance regression in 4.15 and later

rland with your patches and at least please fix that for 4.16. I can help testing code for 4.17/++ if you wish but that is *different* storry. Regards, Gabriel C

Re: AMD graphics performance regression in 4.15 and later

; code path. > > Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those. > Well you really can't be serious about these suggestions ? Are you ? Telling peoples to #if 0 random code is not a solution. You broke existsing working userland with your patches and at least please fix that for 4.16. I can help testing code for 4.17/++ if you wish but that is *different* storry. Regards, Gabriel C

Re: Did kernel 3.11 never work?

2018-03-23 16:50 GMT+01:00 Gabriel C <nix.or@gmail.com>: ... > Maybe have a look there ? > https://github.com/rapier1 > Latest kernel there is an 4.10 https://github.com/rapier1/web10g/releases/tag/kis-0.12-4.10

Re: Did kernel 3.11 never work?

2018-03-23 16:50 GMT+01:00 Gabriel C : ... > Maybe have a look there ? > https://github.com/rapier1 > Latest kernel there is an 4.10 https://github.com/rapier1/web10g/releases/tag/kis-0.12-4.10

Re: Did kernel 3.11 never work?

ned by Ben. You can try this one, maybe it'll work, who > knows. > I don't really remeber but some TCP_ESTATS_* exists in 4.x kernels. So some based-on or these patches got somewho merged. Also some work is still done from Chris Rapier on github. Maybe have a look there ? https://github.com/rapier1 Regards, Gabriel C

Re: Did kernel 3.11 never work?

n try this one, maybe it'll work, who > knows. > I don't really remeber but some TCP_ESTATS_* exists in 4.x kernels. So some based-on or these patches got somewho merged. Also some work is still done from Chris Rapier on github. Maybe have a look there ? https://github.com/rapier1 Regards, Gabriel C

Re: [PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

stable-queue. Regards, Gabriel C

  1   2   3   4   5   6   7   8   9   >