otconfig data from initrd while
boot")
Reported-by: Paul Menzel
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
init/main.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/init/main.c b/init/main.c
index 1a5da2c2660c..5803ecb411ab
Dear Steven,
Thank you for your quick response.
Am 11.05.20 um 20:58 schrieb Steven Rostedt:
On Sat, 9 May 2020 12:16:30 +0200 Paul Menzel wrote:
Linux master and Linux 5.6.7 (from Debian Sid/unstable) are used.
Instrumenting Linux’ start-up time, I’d like to trace the init function
[0.248383] initcall init_acpi_pm_clocksource+0x0/0x197 returned -19
after 0 usecs
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Paul Menzel
---
Please consider this a request for comments.
1. What would
Dear Thomas,
Thank you for the quick reply.
Am 11.05.20 um 09:17 schrieb Thomas Gleixner:
Paul Menzel writes:
please send patches to LKML and not offlist.
Sorry about that. From `MAINTAINERS` I thought x...@kernel.org is wanted.
Other subsystems list LKML explicitly there.
From
Dear Masami,
Commit de462e5f10 (bootconfig: Fix to remove bootconfig data from initrd
while boot) causes a cosmetic regression on my x86 system with Debian
Sid/unstable.
Despite having no `bootconfig` parameter on the Linux CLI, the warning
below is shown.
'bootconfig' found on
en
putting system into s0ix. As the NVME sleep behavior has been adjusted
in d916b1be this is expected to be now resolved.
1. Please add, that it was the Hynix(?) SSD.
2. Please add the commit message summary of d916b1be.
nvme-pci: use host managed power state for suspend
Cc: 'Paul Menzel
[CC: +affected coreboot folks, +coreboot mailing list]
Dear Thomas,
More affected people discussed this issue on the coreboot mailing list [1].
On 2019-01-14 18:37, Lendacky, Thomas wrote:
> On 1/14/19 11:09 AM, Paul Menzel wrote:
>> On 01/14/19 18:00, Lendacky, Thomas wrote:
>&
Dear Tomas,
Testing Fedora 30 with Linux 5.2.11 on an old Dell OptiPlex 980, Linux log
the message below.
[ 15.964298] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: Could not
read FW version
[ 15.964301] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: FW version
command
Dear Dave,
Thank you for your replies.
On 2019-08-13 04:54, Dave Young wrote:
> On 08/13/19 at 10:46am, Dave Young wrote:
>> On 08/13/19 at 10:43am, Dave Young wrote:
>>> On 08/12/19 at 11:50am, Michal Hocko wrote:
>>>> On Mon 12-08-19 11:42:33, Paul Menzel wro
Dear Linux folks,
No idea, if you are interested in these reports. Building Linux 5.3-rc4,
GCC 9.2.0 shows the warning below.
```
In file included from arch/x86/kernel/head64.c:35:
In function ‘sanitize_boot_params’,
inlined from ‘copy_bootdata’ at arch/x86/kernel/head64.c:391:2:
[+ INTEL IDLE DRIVER]
Dear Linux folks,
On 10.08.19 20:28, Paul Menzel wrote:
On 10.08.19 19:31, Thomas Gleixner wrote:
On Sat, 10 Aug 2019, Paul Menzel wrote:
I have no idea, who to report this to, so I please refer me to the
correct
list.
I have no idea yet either :)
With Linux
Dear Thomas,
On 10.08.19 19:31, Thomas Gleixner wrote:
On Sat, 10 Aug 2019, Paul Menzel wrote:
I have no idea, who to report this to, so I please refer me to the correct
list.
I have no idea yet either :)
With Linux 5.2.7 from Debian Sid/unstable and PowerTOP 2.10, executing
sudo
Dear Sasha,
On 07.08.19 09:23, Neftin, Sasha wrote:
> On 8/6/2019 18:53, mario.limoncie...@dell.com wrote:
>>> -Original Message-
>>> From: Paul Menzel
>>> Sent: Tuesday, August 6, 2019 10:36 AM
>>> To: Jeff Kirsher
>>> Cc: intel-wired
Dear Linux folks,
Trying to decrease the resume time of Linux 5.3-rc3 on the Dell OptiPlex
5040 with the device below
$ lspci -nn -s 00:1f.6
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection
(2) I219-V [8086:15b8] (rev 31)
pm-graph’s script `sleepgraph.py`
Dear Mika,
On 06.08.19 13:31, Mika Westerberg wrote:
> On Tue, Aug 06, 2019 at 11:57:26AM +0200, Paul Menzel wrote:
>> On 06.08.19 11:36, Mika Westerberg wrote:
>>> +Nicholas and Matthias
>>>
>>> On Tue, Aug 06, 2019 at 11:20:37AM +0200, Paul Menzel wrot
Dear Mika,
Thank you for your quick reply.
On 06.08.19 11:36, Mika Westerberg wrote:
> +Nicholas and Matthias
>
> On Tue, Aug 06, 2019 at 11:20:37AM +0200, Paul Menzel wrote:
>> Commit c2bf1fc2 (PCI: Add missing link delays required by the PCIe spec) [1]
>> increases
Dear Mika, dear Rafael,
Commit c2bf1fc2 (PCI: Add missing link delays required by the PCIe spec) [1]
increases the resume time from ACPI S3 on a desktop system Dell OptiPlex 5040
by one second. It looks like this is expected from the commit message, but
breaks existing systems with boot time
Dear Rick,
It looks like your message is unrelated to the thread at hand.
Therefore, please start a new thread by *not* using the reply feature,
but create a new message in your mail program (MUA).
Please read some mailing list etiquettes on the Web like [1].
Kind regards,
Paul
[1]:
Dear Greg,
On 02.08.19 18:02, Greg Kroah-Hartman wrote:
On Fri, Aug 02, 2019 at 03:23:08PM +0200, Paul Menzel wrote:
On a lot of devices, like servers, you have more than one serial console,
and you do not always know, how they are numbered. Therefore, we start a
console on ttyS0 and ttyS1
Dear Jinpu,
On 02.08.19 16:48, Jinpu Wang wrote:
We found a problem regarding much higher IO latency when running
kernel 4.4.131 compare to 4.14.133, tried with latest upstream
5.3-rc2, same result.
Reproducer:
1 create md raid1 with 2 ram disks:
sudo mdadm -C /dev/md0 -l1 -n2 -e1.2
Dear Linux folks,
On a lot of devices, like servers, you have more than one serial console,
and you do not always know, how they are numbered. Therefore, we start a
console on ttyS0 and ttyS1.
In user space, we also would like to write to both consoles to not worry
about the numbering. Writing
Date: Tue, 30 Jul 2019 10:53:10 +0200
Fix the error below triggered by `-Wimplicit-fallthrough`, by tagging
it as an expected fall-through.
arch/powerpc/kvm/book3s_32_mmu.c: In function
‘kvmppc_mmu_book3s_32_xlate_pte’:
arch/powerpc/kvm/book3s_32_mmu.c:241:21: error: this statement may
Dear Linux folks,
On 6/27/19 1:02 PM, Paul Menzel wrote:
> On a Dell OptiPlex 5040 with Linux 5.2-rc6 plugging in a
> head phone into the front case connector, it is detected
> just fine and Xfce shows a notification.
>
> Then logging out, turning off the monitor connected ove
Dear Eric,
Sorry for the late reply.
On 5/29/19 6:00 PM, Eric Dumazet wrote:
> On Wed, May 29, 2019 at 7:49 AM Paul Menzel wrote:
>> On 05/28/19 19:18, Eric Dumazet wrote:
>>> On 5/28/19 8:42 AM, Paul Menzel wrote:
>>
>>>> Occasionally, Linux outputs the m
Dear Linux folks,
On a MSI B350M MORTAR with AMD Ryzen 3 2200G (Raven) with Linux 5.2+,
Linux logs the message below.
Expanded resource Reserved due to conflict with PCI Bus :00
I can’t remember seeing this before. Do you know, if there were code
changes causing this new message? I
Dear Kai Heng,
(with or without hyphen?)
On 7/15/19 11:00 AM, Kai Heng Feng wrote:
> at 4:52 PM, Paul Menzel wrote:
>> On 7/15/19 10:43 AM, Kai-Heng Feng wrote:
>>> After hotplugging an 1Gbps ethernet cable with 1Gbps link partner, the
>>> MII_BMSR may reports
Dear Kai-Heng,
Thank you for the patch.
On 7/15/19 10:43 AM, Kai-Heng Feng wrote:
> After hotplugging an 1Gbps ethernet cable with 1Gbps link partner, the
> MII_BMSR may reports 10Mbps, renders the network rather slow.
s/may reports/may report/
s/renders/rendering/
> The issue has much lower
Dear Bruce,
On 7/3/19 5:56 PM, J. Bruce Fields wrote:
> Good catch! And thanks for the detailed explanation. Applying for 5.2
> and stable.
Thanks. Please note, that in the last part are some guesses, and I am not
well versed in the terminology. So please feel free to reword the commit
sta...@vger.kernel.org
Signed-off-by: Paul Menzel
---
1. No, idea if `min_t()` arguments also need updating.
2. Instead of `unsigned long`, should `size_t` be used?
fs/nfsd/nfs4state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 618e66078
Dear Bruce,
On 7/2/19 11:59 PM, Paul Menzel wrote:
> Could it be that commit c54f24e3 (nfsd: fix performance-limiting
> session calculation) causes a regression on big memory machines (1
> TB)?
>
>> From c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 Mon Sep 17 00:00:00 2001
Dear Bruce,
Could it be that commit c54f24e3 (nfsd: fix performance-limiting session
calculation) causes a regression on big memory machines (1 TB)?
From c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields"
Date: Thu, 21 Feb 2019 10:47:00 -0500
Subject:
Dear Linux folks,
On a Dell OptiPlex 5040 with Linux 5.2-rc6 plugging in a
head phone into the front case connector, it is detected
just fine and Xfce shows a notification.
Then logging out, turning off the monitor connected over
DisplayPort at the end of the day, and turning the monitor
back
Dear Linux folks,
On several systems with different network devices and drivers (e1000e, r8169,
tg3)
it looks like getting the link up takes over three seconds.
### e1000e ###
[1.999678] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[2.000374] e1000e: Copyright(c) 1999 - 2015
Dear Eric,
Thank you for the quick reply.
On 05/28/19 19:18, Eric Dumazet wrote:
> On 5/28/19 8:42 AM, Paul Menzel wrote:
>> Occasionally, Linux outputs the message below on the workstation Dell
>> OptiPlex 5040 MT.
>>
>> TCP: net00: Driver has suspect GRO impl
Dear Linux folks,
Occasionally, Linux outputs the message below on the workstation Dell
OptiPlex 5040 MT.
TCP: net00: Driver has suspect GRO implementation, TCP performance may be
compromised.
Linux 4.14.55 and Linux 5.2-rc2 show the message, and the WWW also
gives some hits [1][2].
```
Dear Linux folks,
I optimized the Linux kernel configuration on my ASRock E350M1, and it now
boots really fast.
Unfortunately, that seems to cause the network driver to hit some corner
case, so that the link is supposedly down, although it should be up. The
cable is plugged in the whole time.
Dear Christophe,
On 26.03.19 13:55, Christophe Leroy wrote:
Le 26/03/2019 à 13:49, Paul Menzel a écrit :
On 19.02.19 10:44, Paul Menzel wrote:
On a the IBM S822LC (8335-GTA) with Ubuntu 18.10, and Linux 5.0-rc5+
accessing `/sys/kernel/debug/kmemleak` takes a long time. According
Dear Linux folks,
Resuming from ACPI S3 on the Dell XPS 13 9370 with Debian Sid/unstable,
Linux 4.19.20 showed the warning below. It’s not reproducible.
```
[0.00] Linux version 4.19.0-3-amd64 (debian-ker...@lists.debian.org)
(gcc version 8.2.0 (Debian 8.2.0-20)) #1 SMP Debian
Dear Linux folks,
On a the IBM S822LC (8335-GTA) with Ubuntu 18.10, and Linux 5.0-rc5+
accessing `/sys/kernel/debug/kmemleak` takes a long time. According to
strace it takes three seconds.
```
$ sudo strace -tt -T cat /sys/kernel/debug/kmemleak
10:35:49.861641 execve("/bin/cat", ["cat",
Dear Takashi,
On 02/18/19 16:38, Takashi Iwai wrote:
> On Mon, 18 Feb 2019 16:17:30 +0100, Paul Menzel wrote:
>>
>>>> Then, I built the HDA subsystem as a module, but that also did not help.
>>>> The DRM subsystem is started after the HD-audio subsystem.
>>
Dear Takashi,
On 02/14/19 17:06, Takashi Iwai wrote:
> On Thu, 14 Feb 2019 17:00:29 +0100, Paul Menzel wrote:
>> On 02/13/19 16:56, Takashi Iwai wrote:
>>> On Wed, 13 Feb 2019 16:42:19 +0100, Paul Menzel wrote:
>>
>>>> On 02/13/19 16:12, Takashi Iwai wrote
Dear Takashi,
On 02/13/19 16:12, Takashi Iwai wrote:
> On Wed, 13 Feb 2019 15:58:44 +0100,
> Paul Menzel wrote:
>>
>>> Why the i915 driver gets initialized *so late*?
>>
>> Maybe, because it’s built as a module?
>>
>> ```
>> $ grep I915
Dear Linux folks,
On 01.02.19 22:34, Paul Menzel wrote:
[attaching Linux messages, lspci and lsusb output]
On 01.02.19 22:20, Paul Menzel wrote:
When trying to pair a Dell Latitude E7250 running Debian Sid/unstable
with Linux 4.20 and GNOME 3.30 with an LG TV, after starting the
pairing
Dear Linux folks,
When trying to pair a Dell Latitude E7250 running Debian Sid/unstable
with Linux 4.20 and GNOME 3.30 with an LG TV, after starting the pairing
process the TV is listed. in Bluetooth dialog of GNOME setting.
The TV displays the instructions below.
Complete the next three
Dear Jan,
Am 29.01.19 um 20:33 schrieb Paul Menzel:
Thank you for adding me to the CC list.
Am 29.01.19 um 11:23 schrieb Jan H. Schönherr:
My newly acquired AMD Ryzen Threadripper based system seems to have
some TSC quirks, which go away once the system is up.
Given the discussion
Dear Jan,
Thank you for adding me to the CC list.
Am 29.01.19 um 11:23 schrieb Jan H. Schönherr:
My newly acquired AMD Ryzen Threadripper based system seems to have
some TSC quirks, which go away once the system is up.
Given the discussion in https://lkml.org/lkml/2019/1/28/1356
I don't
Dear Tom,
On 01/24/19 00:33, Lendacky, Thomas wrote:
> On 1/23/19 6:56 AM, Paul Menzel wrote:
>> On 01/22/19 21:24, Lendacky, Thomas wrote:
>>> On 1/22/19 10:53 AM, Paul Menzel wrote:
>>>> [Adding Tom to CC]
>>
>>>> On 01/14/19 11:09, Paul Me
boot delay on the HP EliteDesk 705 G4 MT with Linux
4.14.94. ]
Signed-off-by: Paul Menzel
---
v2: Use tabs. Sorry for messing that up.
drivers/char/ipmi/ipmi_si_intf.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_in
boot delay on the HP EliteDesk 705 G4 MT with Linux
4.14.94. ]
Signed-off-by: Paul Menzel
---
drivers/char/ipmi/ipmi_si_intf.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index c04aa11f0e21..6d18f8090cea 100644
---
Dear Corey,
On 01/22/19 21:58, Corey Minyard wrote:
> On 1/22/19 10:17 AM, Paul Menzel wrote:
>> Using Linux 4.14.94 on a HP EliteDesk 705 G4 MT desktop system, there
>> is a 100 s delay during boot.
>>
>> ```
>> [ 0.00] Linux version 4.14.94.mx6
Dear Tom,
On 01/22/19 21:24, Lendacky, Thomas wrote:
> On 1/22/19 10:53 AM, Paul Menzel wrote:
>> [Adding Tom to CC]
>> On 01/14/19 11:09, Paul Menzel wrote:
>>
>>> On 01/11/19 21:43, Thomas Gleixner wrote:
>>>
>>>> On Mon, 7 Jan 2019, Paul Men
[Adding Tom to CC]
Dear Thomas, dear Tom,
On 01/14/19 11:09, Paul Menzel wrote:
> On 01/11/19 21:43, Thomas Gleixner wrote:
>
>> On Mon, 7 Jan 2019, Paul Menzel wrote:
>>> On 01/07/19 16:24, Thomas Gleixner wrote:
>>>>> Linux 4.19.13 from Debian
Dear Benjamin,
Thank you for chiming in.
On 01/15/19 09:57, Benjamin Tissoires wrote:
> On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov wrote:
>>
>> On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
>>> On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
On Fri, Jan 11, 2019 at
Dear Thomas,
Thank you for checking this, and coming back with the results so quickly.
On 01/14/19 18:00, Lendacky, Thomas wrote:
> On 1/10/19 12:34 PM, Lendacky, Thomas wrote:
>> On 1/10/19 10:49 AM, Paul Menzel wrote:
>>> Dear Boris, dear Thomas,
>>>
>>>
&g
Dear Thomas,
On 01/11/19 21:43, Thomas Gleixner wrote:
> On Mon, 7 Jan 2019, Paul Menzel wrote:
>> On 01/07/19 16:24, Thomas Gleixner wrote:
>>>> Linux 4.19.13 from Debian Sid/unstable logs the message below on the board
>>>> MSI
>>>> MS-7A37/B350
Dear Boris, dear Thomas,
On 01/10/19 17:00, Borislav Petkov wrote:
> On Thu, Jan 10, 2019 at 02:57:40PM +0100, Paul Menzel wrote:
>> Thank you very much. Indeed, the machine does not crash. I used Linus’
>> master branch for testing, and applied your patch on top. Please find
Dear Linux folks,
There were some PCI Kconfig changes, which seem to cause problems
with components depending on PCI. With the attached minimal config,
running `make olddefconfig` on Linux 4.20 and older caused
`SATA_AHCI` to be selected. But, with Linux 5.0-rc1 it is not
selected.
Kind
Dear Thomas,
On 01/09/19 17:15, Lendacky, Thomas wrote:
> On 1/9/19 8:34 AM, Paul Menzel wrote:
>> On 01/09/19 15:29, Lendacky, Thomas wrote:
>>> On 1/9/19 7:35 AM, Paul Menzel wrote:
>>
>>>> On 01/09/19 14:16, Thomas Gleixner wrote:
>>>>
>&
Dear Thomas,
On 01/09/19 15:29, Lendacky, Thomas wrote:
> On 1/9/19 7:35 AM, Paul Menzel wrote:
>> On 01/09/19 14:16, Thomas Gleixner wrote:
>>
>>> On Wed, 9 Jan 2019, Paul Menzel wrote:
>>>> I get the same with microcode updates applied.
>>&
Dear Thomas,
On 01/09/19 14:16, Thomas Gleixner wrote:
> On Wed, 9 Jan 2019, Paul Menzel wrote:
>> I get the same with microcode updates applied.
>>
>> $ dmesg | grep 'microcode: CPU0: patch_level'
>> [3.809210] microcode: CPU0: patch_level=0x0600063e
Dear Jiri, dear Thomas, dear Borislav,
On 01/09/19 13:06, Paul Menzel wrote:
> On 01/04/19 17:42, Jiri Kosina wrote:
>>
>> [ added some CCs ]
>
> Thank you for your reply and taking care of that. I am sorry for the
> late reply. It took a while to test this.
>
Dear Maarten,
Thank you very much for the quick response.
On 01/08/19 16:37, Maarten Lankhorst wrote:
> Op 08-01-2019 om 16:07 schreef Paul Menzel:
>> Building Linux 5.0-rc1 fails with the errors below. Please find the
>> configuration file attached.
>>
>> ```
>&g
Dear Linux folks,
Building Linux 5.0-rc1 fails with the errors below. Please find the
configuration file attached.
```
$ make -j120
[…]
drivers/gpu/vga/vgaarb.c: In function ‘__vga_tryget’:
drivers/gpu/vga/vgaarb.c:286:14: error: ‘PCI_VGA_STATE_CHANGE_DECODES’
undeclared (first use in this
Dear Thomas,
On 01/07/19 16:24, Thomas Gleixner wrote:
> On Mon, 31 Dec 2018, Paul Menzel wrote:
>
>> Linux 4.19.13 from Debian Sid/unstable logs the message below on the board
>> MSI
>> MS-7A37/B350M MORTAR with the processor AMD Ryzen 3 2200G.
>>
>> A
Dear Linux folks,
On 01/03/19 22:45, Paul Menzel wrote:
> On the server board Asus KGPE-D16 with AMD Opteron 6278 processor updating
> the microcode update in the firmware from 0x0600062e to 0x0600063e seems to
> cause a general protection fault with Linux 4.14.87 and 4.20-rc7.
>
Dear Linux folks,
Linux 4.19.13 from Debian Sid/unstable logs the message below on the
board MSI MS-7A37/B350M MORTAR with the processor AMD Ryzen 3 2200G.
As a result, the early time stamps do not seem to be working.
[0.00] Linux version 4.19.0-1-amd64
Dear Rafael,
On 12/13/18 11:39, Rafael J. Wysocki wrote:
> On Thu, Dec 13, 2018 at 10:54 AM Paul Menzel wrote:
>> On 12/13/18 00:06, Doug Smythies wrote:
>>> On 2018.12.12 13:40 Paul Menzel wrote:
>>>
>>>> Using *powersave* as P-state selection algorithm,
Dear Doug,
Thank you for your reply.
On 12/13/18 00:06, Doug Smythies wrote:
> On 2018.12.12 13:40 Paul Menzel wrote:
>
>> Using *powersave* as P-state selection algorithm, on an idle system
>
> Define "idle system".
> If your computer is running a GUI, or
Dear Linux folks,
Using *powersave* as P-state selection algorithm, on an idle system
with an Intel i7-6700 (Sandy Bridge), the frequency only goes down to
900 MHz instead of the minimum frequency of 800 MHz.
$ uname -a
Linux keineahnung.molgen.mpg.de 4.20.0-rc5.mx64.234 #1 SMP Mon Dec 3
Dear Dominik,
Thank you for your quick response.
Am 11.12.18 um 07:51 schrieb Dominik Brodowski:
On Mon, Dec 10, 2018 at 04:30:05PM +0100, Paul Menzel wrote:
With Linux 4.14.76, the scaling governor *powersave* is shown as
being available despite being disabled in the configuration
Dear Linux folks,
With Linux 4.14.76, the scaling governor *powersave* is shown as
being available despite being disabled in the configuration.
```
$ uname -a
Linux xxx.molgen.mpg.de 4.14.76.mx64.228 #1 SMP Tue Oct 16 19:20:58 CEST 2018
x86_64 GNU/Linux
$ zcat /proc/config.gz |grep
Dear Linux folks,
What driver is recommended for current AMD Ryzen based processors
like *AMD Ryzen 5 PRO 1500 Quad-Core Processor* or *AMD EPYC 7601
32-Core Processor*?
Only from the acpi-cpufreq Kconfig description, I assume, that that
driver should be used.
> config X86_ACPI_CPUFREQ
>
Dear Linux folks,
What driver is recommended for current AMD Ryzen based processors
like *AMD Ryzen 5 PRO 1500 Quad-Core Processor* or *AMD EPYC 7601
32-Core Processor*?
Only from the acpi-cpufreq Kconfig description, I assume, that that
driver should be used.
> config X86_ACPI_CPUFREQ
>
Dear Thomas,
As always thank you for the quick reply.
On 10/17/18 18:39, Thomas Gleixner wrote:
> On Wed, 17 Oct 2018, Paul Menzel wrote:
>>
>> Please find the debug patches attached. The `random: %i` messages are from
>> `crng_fast_load()`.
>>
>> My questi
Dear Thomas,
As always thank you for the quick reply.
On 10/17/18 18:39, Thomas Gleixner wrote:
> On Wed, 17 Oct 2018, Paul Menzel wrote:
>>
>> Please find the debug patches attached. The `random: %i` messages are from
>> `crng_fast_load()`.
>>
>> My questi
is not in the context of
the WX checking output.
Reported-by: Paul Menzel
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: Kees Cook
Cc: Bjorn Helgaas
---
arch/x86/mm/dump_pagetables.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
Thank you
is not in the context of
the WX checking output.
Reported-by: Paul Menzel
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: Kees Cook
Cc: Bjorn Helgaas
---
arch/x86/mm/dump_pagetables.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
Thank you
Dear Josh, dear Linux folks,
Trying to decrease the boot time of the 64-bit Linux kernel (Linux
4.19-rc7 (0238df64)) on a Asus F2A85-M PRO with an AMD processor, I
noticed `unwind_init()` called from `setup_arch()`
`arch/x86/kernel/setup.c` takes over 100 ms to initialize according to
Linux
Dear Josh, dear Linux folks,
Trying to decrease the boot time of the 64-bit Linux kernel (Linux
4.19-rc7 (0238df64)) on a Asus F2A85-M PRO with an AMD processor, I
noticed `unwind_init()` called from `setup_arch()`
`arch/x86/kernel/setup.c` takes over 100 ms to initialize according to
Linux
Dear Thomas,
On 10/05/18 11:27, Thomas Gleixner wrote:
> On Thu, 4 Oct 2018, Joerg Roedel wrote:
>
>> On Wed, Oct 03, 2018 at 11:22:55PM +0200, Borislav Petkov wrote:
>>> On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
Sorry for the delay and thanks for the data. A quick
Dear Thomas,
On 10/05/18 11:27, Thomas Gleixner wrote:
> On Thu, 4 Oct 2018, Joerg Roedel wrote:
>
>> On Wed, Oct 03, 2018 at 11:22:55PM +0200, Borislav Petkov wrote:
>>> On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
Sorry for the delay and thanks for the data. A quick
Dear Borislav,
On 10/04/18 12:54, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:59:18AM +0200, Paul Menzel wrote:
>> I meant just the test you did.
>
> https://lkml.kernel.org/r/20181003212255.gb28...@zn.tnic
I see. But there you write, the machine does boot.
While
Dear Borislav,
On 10/04/18 12:54, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:59:18AM +0200, Paul Menzel wrote:
>> I meant just the test you did.
>
> https://lkml.kernel.org/r/20181003212255.gb28...@zn.tnic
I see. But there you write, the machine does boot.
While
Dear Borislav,
On 10/04/18 10:49, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
>> Do you have a commit, I could test.
>
> Not yet
I meant just the test you did.
> but I have a question for you: why are you running 32-bit and
> ha
Dear Borislav,
On 10/04/18 10:49, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
>> Do you have a commit, I could test.
>
> Not yet
I meant just the test you did.
> but I have a question for you: why are you running 32-bit and
> ha
Dear Borislav,
On 10/04/18 10:14, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:03:21AM +0200, Joerg Roedel wrote:
>> I also triggered this when working in the PTI-x32 code. It always
>> happens on a 32-bit PAE kernel for me.
>>
>> Tracking it down I ended up in (iirc)
Dear Borislav,
On 10/04/18 10:14, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:03:21AM +0200, Joerg Roedel wrote:
>> I also triggered this when working in the PTI-x32 code. It always
>> happens on a 32-bit PAE kernel for me.
>>
>> Tracking it down I ended up in (iirc)
Dear Arnaldo,
Am 03.10.2018 um 22:57 schrieb Arnaldo Carvalho de Melo:
Em Wed, Oct 03, 2018 at 10:42:39PM +0200, Paul Menzel escreveu:
For profiling the boot on my Debian Sid/unstable system (32-bit user space),
the following service unit is used.
You forgot to mention what is the version
Dear Arnaldo,
Am 03.10.2018 um 22:57 schrieb Arnaldo Carvalho de Melo:
Em Wed, Oct 03, 2018 at 10:42:39PM +0200, Paul Menzel escreveu:
For profiling the boot on my Debian Sid/unstable system (32-bit user space),
the following service unit is used.
You forgot to mention what is the version
Dear Borislav,
Am 03.10.2018 um 23:22 schrieb Borislav Petkov:
On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
Sorry for the delay and thanks for the data. A quick diff did not reveal
anything obvious. I'll have a closer look and we probably need more (other)
information to
Dear Borislav,
Am 03.10.2018 um 23:22 schrieb Borislav Petkov:
On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
Sorry for the delay and thanks for the data. A quick diff did not reveal
anything obvious. I'll have a closer look and we probably need more (other)
information to
Dear Linux folks,
For profiling the boot on my Debian Sid/unstable system (32-bit user
space), the following service unit is used.
```
$ systemctl cat perf
# /etc/systemd/system/perf.service
[Unit]
Description=Perf 10 s
DefaultDependencies=no
[Service]
ExecStart=/usr/local/bin/perf record
Dear Linux folks,
For profiling the boot on my Debian Sid/unstable system (32-bit user
space), the following service unit is used.
```
$ systemctl cat perf
# /etc/systemd/system/perf.service
[Unit]
Description=Perf 10 s
DefaultDependencies=no
[Service]
ExecStart=/usr/local/bin/perf record
Dear Linux folks,
On 08/28/18 07:27, Paul Menzel wrote:
> Using `sleepgraph.py` [1][2] to profile the suspend to RAM (STR)
> times, shows that `ksys_enter` takes a noticeable amount of time.
>
> 13 ms on a TUXEDO Book BU1406 with the NVMe device *SAMSUNG
> MZVKW512HMJP-0*,
Dear Linux folks,
On 08/28/18 07:27, Paul Menzel wrote:
> Using `sleepgraph.py` [1][2] to profile the suspend to RAM (STR)
> times, shows that `ksys_enter` takes a noticeable amount of time.
>
> 13 ms on a TUXEDO Book BU1406 with the NVMe device *SAMSUNG
> MZVKW512HMJP-0*,
Dear Linux folks,
Using `sleepgraph.py` [1][2] to profile the suspend to RAM (STR) times,
shows that `ksys_enter` takes a noticeable amount of time.
13 ms on a TUXEDO Book BU1406 with the NVMe device *SAMSUNG
MZVKW512HMJP-0*, which is quite good, and over a 60 ms on ASRock
E350M1 with
Dear Linux folks,
Using `sleepgraph.py` [1][2] to profile the suspend to RAM (STR) times,
shows that `ksys_enter` takes a noticeable amount of time.
13 ms on a TUXEDO Book BU1406 with the NVMe device *SAMSUNG
MZVKW512HMJP-0*, which is quite good, and over a 60 ms on ASRock
E350M1 with
Dear Jörg,
On 07/20/18 14:31, Jörg Rödel wrote:
> On Tue, Jul 17, 2018 at 06:02:07PM +0200, Paul Menzel wrote:
>> $ dmesg
>> […]
>> [0.145696] calling pci_iommu_init+0x0/0x3f @ 1
>> [0.145719] AMD-Vi: Unable to write to IOMMU perf counter.
>
> This i
Dear Jörg,
On 07/20/18 14:31, Jörg Rödel wrote:
> On Tue, Jul 17, 2018 at 06:02:07PM +0200, Paul Menzel wrote:
>> $ dmesg
>> […]
>> [0.145696] calling pci_iommu_init+0x0/0x3f @ 1
>> [0.145719] AMD-Vi: Unable to write to IOMMU perf counter.
>
> This i
Dear Thomas,
Am 20.07.2018 um 10:39 schrieb Thomas Gleixner:
On Fri, 20 Jul 2018, Paul Menzel wrote:
Enabling the undefined behavior sanitizer and building GNU/Linux 4.18-rc5+
(with some unrelated commits) with GCC 8.1.0 from Debian Sid/unstable, the
warning below is shown.
[2.111913
101 - 200 of 565 matches
Mail list logo
