Re: UBSAN: Undefined behaviour in arch/x86/events/amd/ibs.c:582:24: member access within null pointer of type 'struct perf_event'

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

UBSAN: Undefined behaviour in lib/radix-tree.c:123:14: member access within null pointer of type 'const struct radix_tree_node'

Dear Linux folks, 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. [0.958688] [

UBSAN: Undefined behaviour in lib/radix-tree.c:123:14: member access within null pointer of type 'const struct radix_tree_node'

Dear Linux folks, 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. [0.958688] [

UBSAN: Undefined behaviour in arch/x86/events/amd/ibs.c:582:24: member access within null pointer of type 'struct perf_event'

Dear Linux folks, 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] [

UBSAN: Undefined behaviour in arch/x86/events/amd/ibs.c:582:24: member access within null pointer of type 'struct perf_event'

Dear Linux folks, 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] [

UBSAN: Undefined behaviour in arch/x86/events/core.c:668:25

Dear Linux folks, 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. [1.945853] [

UBSAN: Undefined behaviour in arch/x86/events/core.c:668:25

Dear Linux folks, 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. [1.945853] [

Re: NULL pointer dereference in msi_set_mask_bit

Dear Thomas, On 07/19/18 15:48, Thomas Gleixner wrote: > On Thu, 19 Jul 2018, Paul Menzel wrote: > >> I had to copy the files, and then was able to create an archive with >> non-zero files. Please find the tar archive attached. > > Thanks for providing the data. All lo

Re: NULL pointer dereference in msi_set_mask_bit

Dear Thomas, On 07/19/18 15:48, Thomas Gleixner wrote: > On Thu, 19 Jul 2018, Paul Menzel wrote: > >> I had to copy the files, and then was able to create an archive with >> non-zero files. Please find the tar archive attached. > > Thanks for providing the data. All lo

Re: NULL pointer dereference in msi_set_mask_bit

Dear Thomas, On 07/18/18 22:05, Paul Menzel wrote: > Am 18.07.2018 um 21:00 schrieb Thomas Gleixner: > >> On Wed, 18 Jul 2018, Paul Menzel wrote: >>> On 07/18/18 17:39, Thomas Gleixner wrote: >>>> Bah. Could you please enable GENERIC_IRQ_DEBUGFS and after a s

Re: NULL pointer dereference in msi_set_mask_bit

Dear Thomas, On 07/18/18 22:05, Paul Menzel wrote: > Am 18.07.2018 um 21:00 schrieb Thomas Gleixner: > >> On Wed, 18 Jul 2018, Paul Menzel wrote: >>> On 07/18/18 17:39, Thomas Gleixner wrote: >>>> Bah. Could you please enable GENERIC_IRQ_DEBUGFS and after a s

Re: NULL pointer dereference in msi_set_mask_bit

Dear Thomas, Am 18.07.2018 um 21:00 schrieb Thomas Gleixner: On Wed, 18 Jul 2018, Paul Menzel wrote: On 07/18/18 17:39, Thomas Gleixner wrote: Bah. Could you please enable GENERIC_IRQ_DEBUGFS and after a successful boot up provide me the content of all files in /sys/kernel/debug/irq

Re: NULL pointer dereference in msi_set_mask_bit

Dear Thomas, Am 18.07.2018 um 21:00 schrieb Thomas Gleixner: On Wed, 18 Jul 2018, Paul Menzel wrote: On 07/18/18 17:39, Thomas Gleixner wrote: Bah. Could you please enable GENERIC_IRQ_DEBUGFS and after a successful boot up provide me the content of all files in /sys/kernel/debug/irq

Re: NULL pointer dereference in msi_set_mask_bit

[I removed the folks from the unrelated patches.] Dear Thomas, On 07/18/18 17:39, Thomas Gleixner wrote: > On Wed, 18 Jul 2018, Paul Menzel wrote: >> On 07/18/18 17:02, Thomas Gleixner wrote: >>>>> 93.885: [ 23.020572] BUG: unable to handle kernel NULL po

Re: NULL pointer dereference in msi_set_mask_bit

[I removed the folks from the unrelated patches.] Dear Thomas, On 07/18/18 17:39, Thomas Gleixner wrote: > On Wed, 18 Jul 2018, Paul Menzel wrote: >> On 07/18/18 17:02, Thomas Gleixner wrote: >>>>> 93.885: [ 23.020572] BUG: unable to handle kernel NULL po

Re: NULL pointer dereference in msi_set_mask_bit

Dear Thomas, dear Bjorn, Thank you for your quick responses. On 07/18/18 17:02, Thomas Gleixner wrote: > On Wed, 18 Jul 2018, Bjorn Helgaas wrote: >> [+cc Marc, Thomas] > > Uurgh. That's definitely what I need right now ... :) > >> On Wed, Jul 18, 2018 at 03:28:15PM

Re: NULL pointer dereference in msi_set_mask_bit

Dear Thomas, dear Bjorn, Thank you for your quick responses. On 07/18/18 17:02, Thomas Gleixner wrote: > On Wed, 18 Jul 2018, Bjorn Helgaas wrote: >> [+cc Marc, Thomas] > > Uurgh. That's definitely what I need right now ... :) > >> On Wed, Jul 18, 2018 at 03:28:15PM

general protection fault with prefetch_freepointer

Dear Linux, Loading the amdgpu module on Ryzen 3 2{2,4}00G (Raven) systems sometimes causes a general protection fault [1]. At least on my system I am unable to reliably reproduce the issue. ``` [ 35.265941] kfd kfd: kgd2kfd_probe failed [ 35.537445] general protection fault: [#1] SMP

general protection fault with prefetch_freepointer

Dear Linux, Loading the amdgpu module on Ryzen 3 2{2,4}00G (Raven) systems sometimes causes a general protection fault [1]. At least on my system I am unable to reliably reproduce the issue. ``` [ 35.265941] kfd kfd: kgd2kfd_probe failed [ 35.537445] general protection fault: [#1] SMP

NULL pointer dereference in msi_set_mask_bit

Dear Linux folks, On a MSI B350M MORTAR with AMD Ryzen 3 2200g (Raven) with Linux 4.18-rc5+ and Debian Sid/unstable the system freezes with the messages below. ``` $ git log --oneline -1 30b06abfb92b (HEAD -> master, origin/master, origin/HEAD) Merge tag 'pinctrl-v4.18-3' of

NULL pointer dereference in msi_set_mask_bit

Dear Linux folks, On a MSI B350M MORTAR with AMD Ryzen 3 2200g (Raven) with Linux 4.18-rc5+ and Debian Sid/unstable the system freezes with the messages below. ``` $ git log --oneline -1 30b06abfb92b (HEAD -> master, origin/master, origin/HEAD) Merge tag 'pinctrl-v4.18-3' of

[PATCH] init/main: Log init process file name

handed over control to the init process. Signed-off-by: Paul Menzel --- Ingo, hopefully it’s fine, putting you in Cc. I do not know, who the right person is. init/main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/init/main.c b/init/main.c index 3b4ada11ed52..3821bb55c787 100644

[PATCH] init/main: Log init process file name

handed over control to the init process. Signed-off-by: Paul Menzel --- Ingo, hopefully it’s fine, putting you in Cc. I do not know, who the right person is. init/main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/init/main.c b/init/main.c index 3b4ada11ed52..3821bb55c787 100644

[PATCH] ata: Only output sg element mapped number in verbose debug

Date: Sun, 8 Jul 2018 09:18:21 +0200 Defining `ATA_DEBUG` there are a lof of messages like below in the log. [ 16.345472] ata_sg_setup: 1 sg elements mapped As that is too verbose, only output these messages in verbose debug. Signed-off-by: Paul Menzel --- drivers/ata/libata-core.c | 2

[PATCH] ata: Only output sg element mapped number in verbose debug

Date: Sun, 8 Jul 2018 09:18:21 +0200 Defining `ATA_DEBUG` there are a lof of messages like below in the log. [ 16.345472] ata_sg_setup: 1 sg elements mapped As that is too verbose, only output these messages in verbose debug. Signed-off-by: Paul Menzel --- drivers/ata/libata-core.c | 2

[PATCH] ata: Guard ata_scsi_dump_cdb() by ATA_VERBOSE_DEBUG

Date: Sun, 8 Jul 2018 09:11:34 +0200 Defining `ATA_DEBUG` nothing can be really seen, as the log is spammed with CDB messages. Therefore, guard the print by `ATA_VERBOSE_DEBUG`. Signed-off-by: Paul Menzel --- drivers/ata/libata-scsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

[PATCH] ata: Guard ata_scsi_dump_cdb() by ATA_VERBOSE_DEBUG

Date: Sun, 8 Jul 2018 09:11:34 +0200 Defining `ATA_DEBUG` nothing can be really seen, as the log is spammed with CDB messages. Therefore, guard the print by `ATA_VERBOSE_DEBUG`. Signed-off-by: Paul Menzel --- drivers/ata/libata-scsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

[PATCH v3] tools/build/Build.include: fix # escaping in .cmd files for future Make

es commit 9564a8cf (Kbuild: fix # escaping in .cmd files for future Make). Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Cc: Rasmus Villemoes Cc: Masahiro Yamada Cc: sta...@vger.kernel.org Signed-off-by: Paul Menzel --- v2: Add sta...@vger.kernel.org v3: Add

[PATCH v3] tools/build/Build.include: fix # escaping in .cmd files for future Make

es commit 9564a8cf (Kbuild: fix # escaping in .cmd files for future Make). Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Cc: Rasmus Villemoes Cc: Masahiro Yamada Cc: sta...@vger.kernel.org Signed-off-by: Paul Menzel --- v2: Add sta...@vger.kernel.org v3: Add

Re: tools/build/Build.include: fix # escaping in .cmd files for future Make

es commit 9564a8cf (Kbuild: fix # escaping in .cmd files for future Make). Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Cc: Rasmus Villemoes Cc: Masahiro Yamada Cc: sta...@vger.kernel.org Signed-off-by: Paul Menzel --- v2: Added sta...@vger.kernel.org to

Re: tools/build/Build.include: fix # escaping in .cmd files for future Make

es commit 9564a8cf (Kbuild: fix # escaping in .cmd files for future Make). Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Cc: Rasmus Villemoes Cc: Masahiro Yamada Cc: sta...@vger.kernel.org Signed-off-by: Paul Menzel --- v2: Added sta...@vger.kernel.org to

tools/build/Build.include: fix # escaping in .cmd files for future Make

es commit 9564a8cf (Kbuild: fix # escaping in .cmd files for future Make). Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Cc: Rasmus Villemoes Cc: Masahiro Yamada Signed-off-by: Paul Menzel --- tools/build/Build.include | 4 ++-- 1 file changed, 2 insertions(+), 2

tools/build/Build.include: fix # escaping in .cmd files for future Make

es commit 9564a8cf (Kbuild: fix # escaping in .cmd files for future Make). Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Cc: Rasmus Villemoes Cc: Masahiro Yamada Signed-off-by: Paul Menzel --- tools/build/Build.include | 4 ++-- 1 file changed, 2 insertions(+), 2

Status of aspeed-bmc-opp-firestone (IBM S822LC)

Dear Joel, dear Linux folks, We have an IBM S822LC system (Firestone(?)). Building of OpenBMC currently fails, as the not everything was ported from dev-4.10 to dev-4.13 [1], and therefore a file cannot be found. Looking at upstream Linux, there are BMCs for Power 8 systems, like Palmetto,

Status of aspeed-bmc-opp-firestone (IBM S822LC)

Dear Joel, dear Linux folks, We have an IBM S822LC system (Firestone(?)). Building of OpenBMC currently fails, as the not everything was ported from dev-4.10 to dev-4.13 [1], and therefore a file cannot be found. Looking at upstream Linux, there are BMCs for Power 8 systems, like Palmetto,

Re: arch/powerpc/kernel/head_32.S:1106: Error: missing operand

Dear Christophe, Am 26.05.2018 um 18:02 schrieb christophe leroy: Le 26/05/2018 à 06:35, Paul Menzel a écrit : Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error below. ``` $ git describe --dirty v4.17-rc6-296

Re: arch/powerpc/kernel/head_32.S:1106: Error: missing operand

Dear Christophe, Am 26.05.2018 um 18:02 schrieb christophe leroy: Le 26/05/2018 à 06:35, Paul Menzel a écrit : Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error below. ``` $ git describe --dirty v4.17-rc6-296

arch/powerpc/kernel/head_32.S:1106: Error: missing operand

Dear Linux folks, Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error below. ``` $ git describe --dirty v4.17-rc6-296-gbc2dbc5420e8 $ git log --oneline -1 bc2dbc5420e8 (HEAD -> master, origin/master, origin/HEAD)

arch/powerpc/kernel/head_32.S:1106: Error: missing operand

Dear Linux folks, Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error below. ``` $ git describe --dirty v4.17-rc6-296-gbc2dbc5420e8 $ git log --oneline -1 bc2dbc5420e8 (HEAD -> master, origin/master, origin/HEAD)

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

Dear Heikki, On 05/16/18 13:58, Heikki Krogerus wrote: On Wed, May 16, 2018 at 10:02:26AM +0200, Greg KH wrote: On Tue, May 15, 2018 at 06:47:37PM +0200, Paul Menzel wrote: On 05/15/18 18:00, Greg KH wrote: On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote: Linux 4.17-rc5

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

Dear Heikki, On 05/16/18 13:58, Heikki Krogerus wrote: On Wed, May 16, 2018 at 10:02:26AM +0200, Greg KH wrote: On Tue, May 15, 2018 at 06:47:37PM +0200, Paul Menzel wrote: On 05/15/18 18:00, Greg KH wrote: On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote: Linux 4.17-rc5

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

Dear Greg, As always, thank you for the prompt response. On 05/15/18 18:00, Greg KH wrote: On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote: Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian Sid/unstable. ``` […] [0.440240] usb: port power management

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

Dear Greg, As always, thank you for the prompt response. On 05/15/18 18:00, Greg KH wrote: On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote: Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian Sid/unstable. ``` […] [0.440240] usb: port power management

`ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

Dear Linux folks, Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian Sid/unstable. ``` […] [0.440240] usb: port power management may be unreliable [0.441358] usbcore: registered new interface driver usb-storage [0.441367] usbcore: registered new interface

`ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

Dear Linux folks, Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian Sid/unstable. ``` […] [0.440240] usb: port power management may be unreliable [0.441358] usbcore: registered new interface driver usb-storage [0.441367] usbcore: registered new interface

Re: [solved] QEMU ATA hard disk not detected

Dear Linux folks, On 05/13/18 10:34, Paul Menzel wrote: In QEMU 2.11 a disk is only detected by the AHCI driver and not by libata. On QEMU’s Standard PC (i440FX + PIIX, 1996), that causes an attached drive not to be detected as that machine doesn’t support AHCI. Here is the output

Re: [solved] QEMU ATA hard disk not detected

Dear Linux folks, On 05/13/18 10:34, Paul Menzel wrote: In QEMU 2.11 a disk is only detected by the AHCI driver and not by libata. On QEMU’s Standard PC (i440FX + PIIX, 1996), that causes an attached drive not to be detected as that machine doesn’t support AHCI. Here is the output

QEMU ATA hard disk not detected

Dear Linux folks, In QEMU 2.11 a disk is only detected by the AHCI driver and not by libata. On QEMU’s Standard PC (i440FX + PIIX, 1996), that causes an attached drive not to be detected as that machine doesn’t support AHCI. Here is the output with the machine Standard PC (Q35 + ICH9,

QEMU ATA hard disk not detected

Dear Linux folks, In QEMU 2.11 a disk is only detected by the AHCI driver and not by libata. On QEMU’s Standard PC (i440FX + PIIX, 1996), that causes an attached drive not to be detected as that machine doesn’t support AHCI. Here is the output with the machine Standard PC (Q35 + ICH9,

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

Dear Bjorn, Am 08.05.2018 um 14:34 schrieb Bjorn Helgaas: On Tue, May 08, 2018 at 08:59:34AM +0200, Paul Menzel wrote: Am 07.05.2018 um 23:33 schrieb Bjorn Helgaas: On Fri, May 04, 2018 at 08:33:27AM -0500, Bjorn Helgaas wrote: commit b0d6f2230e12c85ae3b65a854a53c67c7c1f6406 Author: Bjorn

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

Dear Bjorn, Am 08.05.2018 um 14:34 schrieb Bjorn Helgaas: On Tue, May 08, 2018 at 08:59:34AM +0200, Paul Menzel wrote: Am 07.05.2018 um 23:33 schrieb Bjorn Helgaas: On Fri, May 04, 2018 at 08:33:27AM -0500, Bjorn Helgaas wrote: commit b0d6f2230e12c85ae3b65a854a53c67c7c1f6406 Author: Bjorn

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

t should check the Command Completed status after writing to the Slot Control register. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html Link: https://lkml.kernel.org/r/8770820b-85a0-172b-7230-3a44524e6.

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

Command Completed status after writing to the Slot Control register. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html Link: https://lkml.kernel.org/r/8770820b-85a0-172b-7230-3a44524e6...@molgen.mpg.de R

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

ps://lkml.kernel.org/r/8770820b-85a0-172b-7230-3a44524e6...@molgen.mpg.de Reported-by: Paul Menzel <pmenzel+linux-...@molgen.mpg.de> Signed-off-by: Bjorn Helgaas <bhelg...@google.com> diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c index 18a42f8f5dc5..e70e

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

172b-7230-3a44524e6...@molgen.mpg.de Reported-by: Paul Menzel Signed-off-by: Bjorn Helgaas diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c index 18a42f8f5dc5..e70eba5ea906 100644 --- a/drivers/pci/hotplug/pciehp_hpc.c +++ b/drivers/pci/hotplug/pcieh

Re: Linux messages full of `random: get_random_u32 called from`

Dear Theodore, Am 25.04.2018 um 09:41 schrieb Theodore Y. Ts'o: Does this help on your system? Thank you, after figuring out how to apply the paste, yes it helped on my Lenovo X60. commit 4e00b339e264802851aff8e73cde7d24b57b18ce Author: Theodore Ts'o Date: Wed Apr 25

Re: Linux messages full of `random: get_random_u32 called from`

Dear Theodore, Am 25.04.2018 um 09:41 schrieb Theodore Y. Ts'o: Does this help on your system? Thank you, after figuring out how to apply the paste, yes it helped on my Lenovo X60. commit 4e00b339e264802851aff8e73cde7d24b57b18ce Author: Theodore Ts'o Date: Wed Apr 25 01:12:32 2018

Probe HD-audio devices in parallel (was: azx_probe() called twice)

Dear Takashi, On 04/25/18 14:34, Takashi Iwai wrote: On Wed, 25 Apr 2018 14:29:31 +0200, Paul Menzel wrote: On 04/25/18 13:58, Takashi Iwai wrote: On Wed, 25 Apr 2018 13:48:27 +0200, Paul Menzel wrote: With the attached debug patch, `azx_probe()` seems to have been called twice

Probe HD-audio devices in parallel (was: azx_probe() called twice)

Dear Takashi, On 04/25/18 14:34, Takashi Iwai wrote: On Wed, 25 Apr 2018 14:29:31 +0200, Paul Menzel wrote: On 04/25/18 13:58, Takashi Iwai wrote: On Wed, 25 Apr 2018 13:48:27 +0200, Paul Menzel wrote: With the attached debug patch, `azx_probe()` seems to have been called twice

Re: Regression 4.17-rc1: SSD doesn’t properly resume causing system hang (NULL pointer dereference)

Dear Bart, On 04/25/18 14:26, Bart Van Assche wrote: On Wed, 2018-04-25 at 07:37 +0200, Paul Menzel wrote: Am 24.04.2018 um 23:17 schrieb Bart Van Assche: On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: I applied your change, and rebuilt the Linux kernel. Unfortunately, it looks like

Re: Regression 4.17-rc1: SSD doesn’t properly resume causing system hang (NULL pointer dereference)

Dear Bart, On 04/25/18 14:26, Bart Van Assche wrote: On Wed, 2018-04-25 at 07:37 +0200, Paul Menzel wrote: Am 24.04.2018 um 23:17 schrieb Bart Van Assche: On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: I applied your change, and rebuilt the Linux kernel. Unfortunately, it looks like

Re: Regression 4.17-rc1: SSD doesn properly resume causing system hang (NULL pointer dereference)

Dear Bart, Am 24.04.2018 um 23:17 schrieb Bart Van Assche: On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: I applied your change, and rebuilt the Linux kernel. Unfortunately, it looks like, it didn’t make a difference. In that case I don't know what is causing the failure. Can you run

Re: Regression 4.17-rc1: SSD doesn properly resume causing system hang (NULL pointer dereference)

Dear Bart, Am 24.04.2018 um 23:17 schrieb Bart Van Assche: On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: I applied your change, and rebuilt the Linux kernel. Unfortunately, it looks like, it didn’t make a difference. In that case I don't know what is causing the failure. Can you run

Re: Regression 4.17-rc1: SSD doesn properly resume causing system hang (NULL pointer dereference)

Dear Bart, On 04/24/18 19:31, Bart Van Assche wrote: On Tue, 2018-04-24 at 19:10 +0200, Paul Menzel wrote: Please find the configuration file attached. The log only has `initcall_debug no_console_suspend` added. What I was looking for in the .config is the following: CONFIG_SCSI_MQ_DEFAULT

Re: Regression 4.17-rc1: SSD doesn properly resume causing system hang (NULL pointer dereference)

Dear Bart, On 04/24/18 19:31, Bart Van Assche wrote: On Tue, 2018-04-24 at 19:10 +0200, Paul Menzel wrote: Please find the configuration file attached. The log only has `initcall_debug no_console_suspend` added. What I was looking for in the .config is the following: CONFIG_SCSI_MQ_DEFAULT

Re: Linux messages full of `random: get_random_u32 called from`

Dear Theodore, On 04/24/18 17:49, Theodore Y. Ts'o wrote: On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called from` messages. I believe

Re: Linux messages full of `random: get_random_u32 called from`

Dear Theodore, On 04/24/18 17:49, Theodore Y. Ts'o wrote: On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called from` messages. I believe

Re: [PATCH] ALSA: hda: Request driver probe from an async task

Dear Takashi, On 04/24/18 14:15, Takashi Iwai wrote: On Tue, 24 Apr 2018 13:59:58 +0200, Paul Menzel wrote: On 04/23/18 14:33, Takashi Iwai wrote: On Mon, 23 Apr 2018 14:30:36 +0200, Paul Menzel wrote: On 04/23/18 14:21, Takashi Iwai wrote: On Mon, 23 Apr 2018 14:05:52 +0200, Paul

Re: [PATCH] ALSA: hda: Request driver probe from an async task

Dear Takashi, On 04/24/18 14:15, Takashi Iwai wrote: On Tue, 24 Apr 2018 13:59:58 +0200, Paul Menzel wrote: On 04/23/18 14:33, Takashi Iwai wrote: On Mon, 23 Apr 2018 14:30:36 +0200, Paul Menzel wrote: On 04/23/18 14:21, Takashi Iwai wrote: On Mon, 23 Apr 2018 14:05:52 +0200, Paul

Re: How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

Dear Adam, Thank you very much to join the discussion. On 04/24/18 04:08, Adam Borowski wrote: On Mon, Apr 23, 2018 at 07:02:30PM +0200, Pavel Machek wrote: I try to decrease boot time, and my system has an SSD and enough space, so loading 18 instead of 12 MB doesn’t make a difference, but

Re: How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

Dear Adam, Thank you very much to join the discussion. On 04/24/18 04:08, Adam Borowski wrote: On Mon, Apr 23, 2018 at 07:02:30PM +0200, Pavel Machek wrote: I try to decrease boot time, and my system has an SSD and enough space, so loading 18 instead of 12 MB doesn’t make a difference, but

Re: [PATCH] ALSA: hda: Request driver probe from an async task

Dear Takashi, On 04/23/18 14:21, Takashi Iwai wrote: On Mon, 23 Apr 2018 14:05:52 +0200, Paul Menzel wrote: From: Paul Menzel <pmen...@molgen.mpg.de> Date: Sat, 24 Mar 2018 09:28:43 +0100 On an ASRock E350M1, with Linux 4.17-rc1 according to `initcall_debug` calling `azx_driver_init`

Re: [PATCH] ALSA: hda: Request driver probe from an async task

Dear Takashi, On 04/23/18 14:21, Takashi Iwai wrote: On Mon, 23 Apr 2018 14:05:52 +0200, Paul Menzel wrote: From: Paul Menzel Date: Sat, 24 Mar 2018 09:28:43 +0100 On an ASRock E350M1, with Linux 4.17-rc1 according to `initcall_debug` calling `azx_driver_init` takes sometimes more than

[PATCH] ALSA: hda: Request driver probe from an async task

From: Paul Menzel <pmen...@molgen.mpg.de> Date: Sat, 24 Mar 2018 09:28:43 +0100 On an ASRock E350M1, with Linux 4.17-rc1 according to `initcall_debug` calling `azx_driver_init` takes sometimes more than a few milliseconds, and up to 200 ms. ``` [2.892598] calling azx_driver_init+0x0

[PATCH] ALSA: hda: Request driver probe from an async task

From: Paul Menzel Date: Sat, 24 Mar 2018 09:28:43 +0100 On an ASRock E350M1, with Linux 4.17-rc1 according to `initcall_debug` calling `azx_driver_init` takes sometimes more than a few milliseconds, and up to 200 ms. ``` [2.892598] calling azx_driver_init+0x0/0xfe4 [snd_hda_intel] @ 218

Re: How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

Dear Pavel, Am 22.04.2018 um 12:20 schrieb Pavel Machek: On Fri 2018-04-20 16:36:00, Paul Menzel wrote: I try to decrease boot time, and my system has an SSD and enough space, so loading 18 instead of 12 MB doesn’t make a difference, but the self-extraction is noticeable. So, I like

Re: How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

Dear Pavel, Am 22.04.2018 um 12:20 schrieb Pavel Machek: On Fri 2018-04-20 16:36:00, Paul Menzel wrote: I try to decrease boot time, and my system has an SSD and enough space, so loading 18 instead of 12 MB doesn’t make a difference, but the self-extraction is noticeable. So, I like

How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

Dear Linux folks, I try to decrease boot time, and my system has an SSD and enough space, so loading 18 instead of 12 MB doesn’t make a difference, but the self-extraction is noticeable. So, I like to disable it. From `init/Kconfig`: The linux kernel is a kind of self-extracting

How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

Dear Linux folks, I try to decrease boot time, and my system has an SSD and enough space, so loading 18 instead of 12 MB doesn’t make a difference, but the self-extraction is noticeable. So, I like to disable it. From `init/Kconfig`: The linux kernel is a kind of self-extracting

How to disable tracing at runtime from the Linux kernel command line?

Dear Linux folks, I am trying to reduce the boot time of a standard Linux distribution kernel. Currently, distributions – at least Debian und Ubuntu – enable function tracing. ``` CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y CONFIG_EVENT_TRACING=y ``` This is

How to disable tracing at runtime from the Linux kernel command line?

Dear Linux folks, I am trying to reduce the boot time of a standard Linux distribution kernel. Currently, distributions – at least Debian und Ubuntu – enable function tracing. ``` CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y CONFIG_EVENT_TRACING=y ``` This is

Re: Commit *driver core: emit uevents when device is bound to a driver* causes regression

Dear Greg, On 04/06/18 15:18, Greg Kroah-Hartman wrote: On Fri, Apr 06, 2018 at 02:20:40PM +0200, Paul Menzel wrote: Commit 1455cf8 (driver core: emit uevents when device is bound to a driver) [1], introduced in Linux 4.14-rc1, causes a regression in user space. After disconnecting USB

Re: Commit *driver core: emit uevents when device is bound to a driver* causes regression

Dear Greg, On 04/06/18 15:18, Greg Kroah-Hartman wrote: On Fri, Apr 06, 2018 at 02:20:40PM +0200, Paul Menzel wrote: Commit 1455cf8 (driver core: emit uevents when device is bound to a driver) [1], introduced in Linux 4.14-rc1, causes a regression in user space. After disconnecting USB

Commit *driver core: emit uevents when device is bound to a driver* causes regression

Dear Linux folks, Commit 1455cf8 (driver core: emit uevents when device is bound to a driver) [1], introduced in Linux 4.14-rc1, causes a regression in user space. After disconnecting USB devices, they are still shown as plugged in [2][3]. I seem to be having a similar issue, but with an

Commit *driver core: emit uevents when device is bound to a driver* causes regression

Dear Linux folks, Commit 1455cf8 (driver core: emit uevents when device is bound to a driver) [1], introduced in Linux 4.14-rc1, causes a regression in user space. After disconnecting USB devices, they are still shown as plugged in [2][3]. I seem to be having a similar issue, but with an

Decrease boot time with AHCI drives?

Dear Linux folks, I am trying to decrease the boot time of the Linux kernel so the LUKS passphrase dialog (in the initrd) is shown as quickly as possible. The devices I test with is a Lenovo X60 and ASRock E350M1 both running with coreboot and the GRUB payload. The goal is to do this without

Decrease boot time with AHCI drives?

Dear Linux folks, I am trying to decrease the boot time of the Linux kernel so the LUKS passphrase dialog (in the initrd) is shown as quickly as possible. The devices I test with is a Lenovo X60 and ASRock E350M1 both running with coreboot and the GRUB payload. The goal is to do this without

How to move serial8250_init out of the critical path to decrease boot time?

Mon Sep 17 00:00:00 2001 From: Paul Menzel <pmen...@molgen.mpg.de> Date: Sun, 1 Apr 2018 08:57:53 +0200 Subject: [PATCH] tty/serial/8250: Request driver probe from an async task Currently, according to `initcall_debug` running `serial8250_init` takes around 33 ms on a Lenovo X60 and TUXEDO Bo

How to move serial8250_init out of the critical path to decrease boot time?

Mon Sep 17 00:00:00 2001 From: Paul Menzel Date: Sun, 1 Apr 2018 08:57:53 +0200 Subject: [PATCH] tty/serial/8250: Request driver probe from an async task Currently, according to `initcall_debug` running `serial8250_init` takes around 33 ms on a Lenovo X60 and TUXEDO Book BU1

Reduce init time of `lp_init()` and `ppdev_init()`

Dear Linux folks, I am trying to reduce the start-up time of the Linux kernel on an old Lenovo X60. Looking through the time stamps of Linux 4.16-rc7+, the modules `lp` and `ppdev` both take more than ten milliseconds to initialize according to `initcall_debug`. ``` [8.337692] calling

Reduce init time of `lp_init()` and `ppdev_init()`

Dear Linux folks, I am trying to reduce the start-up time of the Linux kernel on an old Lenovo X60. Looking through the time stamps of Linux 4.16-rc7+, the modules `lp` and `ppdev` both take more than ten milliseconds to initialize according to `initcall_debug`. ``` [8.337692] calling

Re: `do_IRQ: 1.55 No irq handler for vector` on ASRock E350M1

Dear Yazen, Eric, Tom, On 02/26/18 17:42, Tom Lendacky wrote: On 2/26/2018 10:37 AM, Morton, Eric wrote: Yazen dug out PLAT-21393 as sounding like this issue. I haven't had a chance to digest it. Yes, internally to AMD, that was the bug that tracked the issue I was referring to. If you

Re: `do_IRQ: 1.55 No irq handler for vector` on ASRock E350M1

Dear Yazen, Eric, Tom, On 02/26/18 17:42, Tom Lendacky wrote: On 2/26/2018 10:37 AM, Morton, Eric wrote: Yazen dug out PLAT-21393 as sounding like this issue. I haven't had a chance to digest it. Yes, internally to AMD, that was the bug that tracked the issue I was referring to. If you

Re: efisubsys_init takes more than a few milliseconds

Dear Ard, On 03/25/2018 09:41 AM, Paul Menzel wrote: On 03/24/2018 11:35 PM, Ard Biesheuvel wrote: On 24 March 2018 at 22:10, Paul Menzel wrote: According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7

Re: efisubsys_init takes more than a few milliseconds

Dear Ard, On 03/25/2018 09:41 AM, Paul Menzel wrote: On 03/24/2018 11:35 PM, Ard Biesheuvel wrote: On 24 March 2018 at 22:10, Paul Menzel wrote: According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7

Re: efisubsys_init takes more than a few milliseconds

Dear Ard, Thank you for the quick reply. On 03/24/2018 11:35 PM, Ard Biesheuvel wrote: On 24 March 2018 at 22:10, Paul Menzel <pmenzel+linux-...@molgen.mpg.de> wrote: Dear Ard, According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell

Re: efisubsys_init takes more than a few milliseconds

Dear Ard, Thank you for the quick reply. On 03/24/2018 11:35 PM, Ard Biesheuvel wrote: On 24 March 2018 at 22:10, Paul Menzel wrote: Dear Ard, According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7-8550U

efisubsys_init takes more than a few milliseconds

Dear Ard, According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz). ``` […] [0.144474] calling efisubsys_init+0x0/0x2cf @ 1 [0.144474] Registered efivars operations [0.173690]

efisubsys_init takes more than a few milliseconds

Dear Ard, According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz). ``` […] [0.144474] calling efisubsys_init+0x0/0x2cf @ 1 [0.144474] Registered efivars operations [0.173690]

Re: uvcvideo: Unknown video format,00000032-0002-0010-8000-00aa00389b71

Dear Laurent, On 03/21/2018 10:25 AM, Laurent Pinchart wrote: On Tuesday, 20 March 2018 18:46:24 EET Paul Menzel wrote: On 03/20/18 14:30, Laurent Pinchart wrote: On Tuesday, 20 March 2018 14:20:14 EET Paul Menzel wrote: On the Dell XPS 13 9370, Linux 4.16-rc6 outputs the messages below

<    1   2   3   4   5   6   >