Kernel freeze with Xorg on 5.12-rcX kernel bisected to 0175969e489aaa0522e52c7d0ac06f2cab0c1ca7

Hi My laptop (T61 c2d) can't use 5.12-rcX kernels as this commit: -- 0175969e489aaa0522e52c7d0ac06f2cab0c1ca7 Author: Chris Wilson Date: Tue Jan 19 21:43:34 2021 + drm/i915/gem: Use shrinkable status for unknown swizzle quirks -- Seems to be causing very early machine deadlock after

Unable to suspend lenovo t61

Hello Recently after trying kernels above 5.1.0-0.rc0.git4.2.fc31.x86_64 on my Fedora Rawhide - I cannot suspend Lenovo T61 laptop (2.2 C2D CPU, 4G RAM) I can only guess it can be related to this TPM reported error: PM: suspend exit PM: suspend entry (s2idle) PM: Syncing filesystems

Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 17:45 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 12:17 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 05:03 Al Viro napsal(a): On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: Hi I've noticed quite some drop of performance (around 15% in some cases) where execution

Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 17:45 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 12:17 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 05:03 Al Viro napsal(a): On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: Hi I've noticed quite some drop of performance (around 15% in some cases) where execution

Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 12:17 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 05:03 Al Viro napsal(a): On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: Hi I've noticed quite some drop of performance (around 15% in some cases) where execution of lvm2 tests took longer time - and while tests

Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 12:17 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 05:03 Al Viro napsal(a): On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: Hi I've noticed quite some drop of performance (around 15% in some cases) where execution of lvm2 tests took longer time - and while tests

Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 05:03 Al Viro napsal(a): On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: Hi I've noticed quite some drop of performance (around 15% in some cases) where execution of lvm2 tests took longer time - and while tests itself should not really load CPU system

Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 05:03 Al Viro napsal(a): On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: Hi I've noticed quite some drop of performance (around 15% in some cases) where execution of lvm2 tests took longer time - and while tests itself should not really load CPU system

Timing performance regression 4.15 to 4.16-rc1

Hi I've noticed quite some drop of performance (around 15% in some cases) where execution of lvm2 tests took longer time - and while tests itself should not really load CPU system - the overall running time just got bigger. Running bisect game pointed clearly to this commit: --- commit

Timing performance regression 4.15 to 4.16-rc1

Hi I've noticed quite some drop of performance (around 15% in some cases) where execution of lvm2 tests took longer time - and while tests itself should not really load CPU system - the overall running time just got bigger. Running bisect game pointed clearly to this commit: --- commit

Re: [PATCH 4/4] dm: convert table_device.count from atomic_t to refcount_t

Dne 20.10.2017 v 09:37 Elena Reshetova napsal(a): atomic_t variables are currently used to implement reference counters with the following properties: - counter is initialized to 1 using atomic_set() - a resource is freed upon counter reaching zero - once counter reaches zero, its further

Re: [PATCH 4/4] dm: convert table_device.count from atomic_t to refcount_t

Dne 20.10.2017 v 09:37 Elena Reshetova napsal(a): atomic_t variables are currently used to implement reference counters with the following properties: - counter is initialized to 1 using atomic_set() - a resource is freed upon counter reaching zero - once counter reaches zero, its further

Re: Detecting page cache trashing state

Dne 15.9.2017 v 02:16 Taras Kondratiuk napsal(a): Hi In our devices under low memory conditions we often get into a trashing state when system spends most of the time re-reading pages of .text sections from a file system (squashfs in our case). Working set doesn't fit into available page cache,

Re: Detecting page cache trashing state

Dne 15.9.2017 v 02:16 Taras Kondratiuk napsal(a): Hi In our devices under low memory conditions we often get into a trashing state when system spends most of the time re-reading pages of .text sections from a file system (squashfs in our case). Working set doesn't fit into available page cache,

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

22547c4cc4fe ("usb: hub: Wait for connection to be reestablished after port reset") is reverted, the disk connects correctly at high speed. On Wed, 26 Jul 2017, Zdenek Kabelac wrote: Dne 25.7.2017 v 21:50 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: 08:18 us

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

22547c4cc4fe ("usb: hub: Wait for connection to be reestablished after port reset") is reverted, the disk connects correctly at high speed. On Wed, 26 Jul 2017, Zdenek Kabelac wrote: Dne 25.7.2017 v 21:50 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: 08:18 us

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 21:50 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: 08:18 usb 2-2: USB disconnect, device number 2 08:25 usb 2-2: new high-speed USB device number 3 using ehci-pci 08:26 usb 2-2: new high-speed USB device number 4 using ehci-pci If the drive were working

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 21:50 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: 08:18 usb 2-2: USB disconnect, device number 2 08:25 usb 2-2: new high-speed USB device number 3 using ehci-pci 08:26 usb 2-2: new high-speed USB device number 4 using ehci-pci If the drive were working

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 26.7.2017 v 16:28 Alan Stern napsal(a): On Tue, 25 Jul 2017, Guenter Roeck wrote: On 07/25/2017 12:50 PM, Alan Stern wrote: On Tue, 25 Jul 2017, Zdenek Kabelac wrote: Dne 25.7.2017 v 19:02 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: And in fact it's the very same

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 26.7.2017 v 16:28 Alan Stern napsal(a): On Tue, 25 Jul 2017, Guenter Roeck wrote: On 07/25/2017 12:50 PM, Alan Stern wrote: On Tue, 25 Jul 2017, Zdenek Kabelac wrote: Dne 25.7.2017 v 19:02 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: And in fact it's the very same

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 19:02 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: And in fact it's the very same commit - which adds this message (just check current 4.13 with and without this commit reverted) So here goes usbmon trace (aka 'cat /sys/kernel/debug/usb/usbmon/0u

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 19:02 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: And in fact it's the very same commit - which adds this message (just check current 4.13 with and without this commit reverted) So here goes usbmon trace (aka 'cat /sys/kernel/debug/usb/usbmon/0u

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 16:34 Zdenek Kabelac napsal(a): Dne 25.7.2017 v 16:25 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: Dne 24.7.2017 v 16:41 Alan Stern napsal(a): On Mon, 24 Jul 2017, Zdenek Kabelac wrote: Hi I've problem with my USB storage devices: WD Elements 1TB. (Bus

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 16:34 Zdenek Kabelac napsal(a): Dne 25.7.2017 v 16:25 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: Dne 24.7.2017 v 16:41 Alan Stern napsal(a): On Mon, 24 Jul 2017, Zdenek Kabelac wrote: Hi I've problem with my USB storage devices: WD Elements 1TB. (Bus

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 16:25 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: Dne 24.7.2017 v 16:41 Alan Stern napsal(a): On Mon, 24 Jul 2017, Zdenek Kabelac wrote: Hi I've problem with my USB storage devices: WD Elements 1TB. (Bus 004 Device 002: ID 1058:10a8 Western Digital

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 16:25 Alan Stern napsal(a): On Tue, 25 Jul 2017, Zdenek Kabelac wrote: Dne 24.7.2017 v 16:41 Alan Stern napsal(a): On Mon, 24 Jul 2017, Zdenek Kabelac wrote: Hi I've problem with my USB storage devices: WD Elements 1TB. (Bus 004 Device 002: ID 1058:10a8 Western Digital

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 24.7.2017 v 16:41 Alan Stern napsal(a): On Mon, 24 Jul 2017, Zdenek Kabelac wrote: Hi I've problem with my USB storage devices: WD Elements 1TB. (Bus 004 Device 002: ID 1058:10a8 Western Digital Technologies, Inc. Elements Portable (WDBUZG)) After kernel >4.9 when disk is attached

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 24.7.2017 v 16:41 Alan Stern napsal(a): On Mon, 24 Jul 2017, Zdenek Kabelac wrote: Hi I've problem with my USB storage devices: WD Elements 1TB. (Bus 004 Device 002: ID 1058:10a8 Western Digital Technologies, Inc. Elements Portable (WDBUZG)) After kernel >4.9 when disk is attached

USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Hi I've problem with my USB storage devices: WD Elements 1TB. (Bus 004 Device 002: ID 1058:10a8 Western Digital Technologies, Inc. Elements Portable (WDBUZG)) After kernel >4.9 when disk is attached via cable it has very low speed (less then 1MB/s). It can run at full speed (>22MB/s)

USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

Hi I've problem with my USB storage devices: WD Elements 1TB. (Bus 004 Device 002: ID 1058:10a8 Western Digital Technologies, Inc. Elements Portable (WDBUZG)) After kernel >4.9 when disk is attached via cable it has very low speed (less then 1MB/s). It can run at full speed (>22MB/s)

BUG: stack guard page was hit tpm_tis_send_data

Hi I've tried to boot 4.9.0-0.rc1.git3.2.fc26.x86_64 - end experienced this BUG report (on Lenovo T61 4G) systemd[335]: systemd-udev-settle.service: Executing: /usr/bin/udevadm settle tpm_tis 00:06: 1.2 TPM (device-id 0x3203, rev-id 9) FUJITSU Extended Socket Network Device Driver - version

BUG: stack guard page was hit tpm_tis_send_data

Hi I've tried to boot 4.9.0-0.rc1.git3.2.fc26.x86_64 - end experienced this BUG report (on Lenovo T61 4G) systemd[335]: systemd-udev-settle.service: Executing: /usr/bin/udevadm settle tpm_tis 00:06: 1.2 TPM (device-id 0x3203, rev-id 9) FUJITSU Extended Socket Network Device Driver - version

Re: [dm-devel] [PATCH 0/2] Introduce the request handling for dm-crypt

Dne 3.12.2015 v 11:36 Baolin Wang napsal(a): On 3 December 2015 at 10:56, Baolin Wang wrote: On 3 December 2015 at 03:56, Alasdair G Kergon wrote: On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote: These are the benchmarks for request based dm-crypt. Please check it. Now please

Re: [dm-devel] [PATCH 0/2] Introduce the request handling for dm-crypt

Dne 3.12.2015 v 11:36 Baolin Wang napsal(a): On 3 December 2015 at 10:56, Baolin Wang wrote: On 3 December 2015 at 03:56, Alasdair G Kergon wrote: On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote: These are the benchmarks for request based

Re: [dm-devel] [PATCH 0/4] dm verity: add support for error correction

Dne 6.11.2015 v 21:27 Sami Tolvanen napsal(a): On Fri, Nov 06, 2015 at 08:20:15PM +0100, Zdenek Kabelac wrote: i.e. you have 1G of space - you want to give 250MB as 'redundancy' - so create 4 partition well data safety has it's price - user should choose what he prefers - more games

Re: [dm-devel] [PATCH 0/4] dm verity: add support for error correction

Dne 6.11.2015 v 20:06 Sami Tolvanen napsal(a): On Fri, Nov 06, 2015 at 12:23:29PM -0500, Mikulas Patocka wrote: I'm also wondering what is this patch useful for. Disks and flash controllers have their own error detection and correction I think I addressed this earlier. Some storage devices

Re: [dm-devel] [PATCH 0/4] dm verity: add support for error correction

Dne 6.11.2015 v 20:06 Sami Tolvanen napsal(a): On Fri, Nov 06, 2015 at 12:23:29PM -0500, Mikulas Patocka wrote: I'm also wondering what is this patch useful for. Disks and flash controllers have their own error detection and correction I think I addressed this earlier. Some storage devices

Re: [dm-devel] [PATCH 0/4] dm verity: add support for error correction

Dne 6.11.2015 v 21:27 Sami Tolvanen napsal(a): On Fri, Nov 06, 2015 at 08:20:15PM +0100, Zdenek Kabelac wrote: i.e. you have 1G of space - you want to give 250MB as 'redundancy' - so create 4 partition well data safety has it's price - user should choose what he prefers - more games

Re: [dm-devel] [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node

Dne 7.7.2015 v 23:41 Andrew Morton napsal(a): On Tue, 7 Jul 2015 11:10:09 -0400 (EDT) Mikulas Patocka wrote: Introduce the functions kvmalloc and kvmalloc_node. These functions provide reliable allocation of object of arbitrary size. They attempt to do allocation with kmalloc and if it

Re: [dm-devel] [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node

Dne 7.7.2015 v 23:41 Andrew Morton napsal(a): On Tue, 7 Jul 2015 11:10:09 -0400 (EDT) Mikulas Patocka mpato...@redhat.com wrote: Introduce the functions kvmalloc and kvmalloc_node. These functions provide reliable allocation of object of arbitrary size. They attempt to do allocation with

Re: Linux 3.19-rc5

Dne 30.1.2015 v 02:49 Rafael J. Wysocki napsal(a): On Thursday, January 29, 2015 05:12:11 PM Linus Torvalds wrote: On Thu, Jan 29, 2015 at 5:22 PM, Rafael J. Wysocki wrote: On Wednesday, January 21, 2015 05:54:00 PM Peter Hurley wrote: Yeah, but the debug check is triggering worse behavior,

Re: Linux 3.19-rc5

Dne 30.1.2015 v 02:49 Rafael J. Wysocki napsal(a): On Thursday, January 29, 2015 05:12:11 PM Linus Torvalds wrote: On Thu, Jan 29, 2015 at 5:22 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Wednesday, January 21, 2015 05:54:00 PM Peter Hurley wrote: Yeah, but the debug check is

WARNING: CPU: 0 PID: 2623 at drivers/pnp/pnpacpi/core.c:96 pnpacpi_set_resource

Hi I've noticed this message in my dmesg: (Possibly related to this commit?: a8d22396302b7e4e5f0a594c1c1594388c29edaf) (My vanilla git commit number for my kernel: cd79bde29f00a346eec3fe17c1c5073c37ed95e7) Zdenek [ 2174.058615] ata5: port disabled--ignoring [ 2174.059460] sd 0:0:0:0: [sda]

WARNING: CPU: 0 PID: 2623 at drivers/pnp/pnpacpi/core.c:96 pnpacpi_set_resource

Hi I've noticed this message in my dmesg: (Possibly related to this commit?: a8d22396302b7e4e5f0a594c1c1594388c29edaf) (My vanilla git commit number for my kernel: cd79bde29f00a346eec3fe17c1c5073c37ed95e7) Zdenek [ 2174.058615] ata5: port disabled--ignoring [ 2174.059460] sd 0:0:0:0: [sda]

Re: Regression with suspend resume 5a87182aa21d6d5d306840feab9321818dd3e2a3

Dne 8.12.2013 12:13, Paul Bolle napsal(a): On Sun, 2013-12-08 at 11:24 +0100, Zdenek Kabelac wrote: I'm testing recent 3.13-rc kernel - and I've notice my Lenovo T61 is not able to resume. After bisect I've found commit: 5a87182aa21d6d5d306840feab9321818dd3e2a3 That's "cpufreq: su

Re: Regression with suspend resume 5a87182aa21d6d5d306840feab9321818dd3e2a3

Dne 8.12.2013 12:13, Paul Bolle napsal(a): On Sun, 2013-12-08 at 11:24 +0100, Zdenek Kabelac wrote: I'm testing recent 3.13-rc kernel - and I've notice my Lenovo T61 is not able to resume. After bisect I've found commit: 5a87182aa21d6d5d306840feab9321818dd3e2a3 That's cpufreq: suspend

FADT errors reported by Lenovo T61

Hello I've noticed strange errors in the log - while my wifi seems to work ok, the surrounding errors do not seem normal. Is there anything I could do to fix them ? Or it will remain broken or there could workaround ? I'm attaching my boot log - with: "ACPI BIOS Warning (bug): 32/64X length

FADT errors reported by Lenovo T61

Hello I've noticed strange errors in the log - while my wifi seems to work ok, the surrounding errors do not seem normal. Is there anything I could do to fix them ? Or it will remain broken or there could workaround ? I'm attaching my boot log - with: ACPI BIOS Warning (bug): 32/64X length

Re: kobject_add_internal failed for msi_irqs with -EEXIST

Dne 27.9.2013 18:01, Veaceslav Falico napsal(a): On Fri, Sep 27, 2013 at 09:58:28AM -0600, Bjorn Helgaas wrote: [+cc Veaceslav, linux-pci] On Fri, Sep 27, 2013 at 7:34 AM, Zdenek Kabelac wrote: Hi With recent build of 3.12-rc2 I'm getting this warning report from kernel: (hw Lenovo T61, C2D

kobject_add_internal failed for msi_irqs with -EEXIST

Hi With recent build of 3.12-rc2 I'm getting this warning report from kernel: (hw Lenovo T61, C2D, 4GB Ram) (repost since linux-kernel@ rejected my gmail email) e1000e :00:19.0: irq 46 for MSI/MSI-X [ cut here ] WARNING: CPU: 1 PID: 301 at fs/sysfs/dir.c:526

Re: Crash of 3.12-rc2 BUG: unable to handle kernel NULL pointer dereference

Dne 27.9.2013 13:57, Zdenek Kabelac napsal(a): Hi I'm trying to use -rc2 kernel however I'm getting quite often regular kernel panic: Here is a BUG trace from kvm running this kernel: (I'm building kernel with some kernel debug checks) (Kernel is used in 64bit qemu and running 32bit Debian

Crash of 3.12-rc2 BUG: unable to handle kernel NULL pointer dereference

Hi I'm trying to use -rc2 kernel however I'm getting quite often regular kernel panic: Here is a BUG trace from kvm running this kernel: (I'm building kernel with some kernel debug checks) (Kernel is used in 64bit qemu and running 32bit Debian environment) linux-vanilla git:

Crash of 3.12-rc2 BUG: unable to handle kernel NULL pointer dereference

Hi I'm trying to use -rc2 kernel however I'm getting quite often regular kernel panic: Here is a BUG trace from kvm running this kernel: (I'm building kernel with some kernel debug checks) (Kernel is used in 64bit qemu and running 32bit Debian environment) linux-vanilla git:

Re: Crash of 3.12-rc2 BUG: unable to handle kernel NULL pointer dereference

Dne 27.9.2013 13:57, Zdenek Kabelac napsal(a): Hi I'm trying to use -rc2 kernel however I'm getting quite often regular kernel panic: Here is a BUG trace from kvm running this kernel: (I'm building kernel with some kernel debug checks) (Kernel is used in 64bit qemu and running 32bit Debian

kobject_add_internal failed for msi_irqs with -EEXIST

Hi With recent build of 3.12-rc2 I'm getting this warning report from kernel: (hw Lenovo T61, C2D, 4GB Ram) (repost since linux-kernel@ rejected my gmail email) e1000e :00:19.0: irq 46 for MSI/MSI-X [ cut here ] WARNING: CPU: 1 PID: 301 at fs/sysfs/dir.c:526

Re: kobject_add_internal failed for msi_irqs with -EEXIST

Dne 27.9.2013 18:01, Veaceslav Falico napsal(a): On Fri, Sep 27, 2013 at 09:58:28AM -0600, Bjorn Helgaas wrote: [+cc Veaceslav, linux-pci] On Fri, Sep 27, 2013 at 7:34 AM, Zdenek Kabelac zkabe...@redhat.com wrote: Hi With recent build of 3.12-rc2 I'm getting this warning report from kernel

Re: ACPI undocking on 3.8-rc5 no longer works with Lenovo T61

Dne 7.3.2013 23:30, Toshi Kani napsal(a): On Thu, 2013-03-07 at 22:48 +0100, Zdenek Kabelac wrote: Dne 29.1.2013 11:46, Zdenek Kabelac napsal(a): Hi No exactly sure which patch did it - but when I'm now checking 3.8-rc5 kernel, I cannot use anymore this 'undock' command: echo 1 >/sys/devi

Re: ACPI undocking on 3.8-rc5 no longer works with Lenovo T61

Dne 7.3.2013 23:30, Toshi Kani napsal(a): On Thu, 2013-03-07 at 22:48 +0100, Zdenek Kabelac wrote: Dne 29.1.2013 11:46, Zdenek Kabelac napsal(a): Hi No exactly sure which patch did it - but when I'm now checking 3.8-rc5 kernel, I cannot use anymore this 'undock' command: echo 1 /sys/devices

Re: iwl3945 prints warning

Dne 29.1.2013 14:08, Stanislaw Gruszka napsal(a): On Mon, Jan 28, 2013 at 03:09:03PM +0100, Zdenek Kabelac wrote: I'm getting tthis warning printed with current 3.8-rc kernel My hw is Lenovo T61. [5.920284] iwl3945 :03:00.0: loaded firmware version 15.32.2.9 [5.976605] systemd[1

Re: ACPI undocking on 3.8-rc5 no longer works with Lenovo T61

Dne 29.1.2013 11:46, Zdenek Kabelac napsal(a): Hi No exactly sure which patch did it - but when I'm now checking 3.8-rc5 kernel, I cannot use anymore this 'undock' command: echo 1 >/sys/devices/platform/dock.0/undock which works ok with 3.7 kernel - to properly undock my T61 before susp

Re: ACPI undocking on 3.8-rc5 no longer works with Lenovo T61

Dne 29.1.2013 11:46, Zdenek Kabelac napsal(a): Hi No exactly sure which patch did it - but when I'm now checking 3.8-rc5 kernel, I cannot use anymore this 'undock' command: echo 1 /sys/devices/platform/dock.0/undock which works ok with 3.7 kernel - to properly undock my T61 before suspend

Re: iwl3945 prints warning

Dne 29.1.2013 14:08, Stanislaw Gruszka napsal(a): On Mon, Jan 28, 2013 at 03:09:03PM +0100, Zdenek Kabelac wrote: I'm getting tthis warning printed with current 3.8-rc kernel My hw is Lenovo T61. [5.920284] iwl3945 :03:00.0: loaded firmware version 15.32.2.9 [5.976605] systemd[1

ACPI undocking on 3.8-rc5 no longer works with Lenovo T61

Hi No exactly sure which patch did it - but when I'm now checking 3.8-rc5 kernel, I cannot use anymore this 'undock' command: echo 1 >/sys/devices/platform/dock.0/undock which works ok with 3.7 kernel - to properly undock my T61 before suspend. Dmesg shows this: [ 2657.087414] ACPI:

ACPI undocking on 3.8-rc5 no longer works with Lenovo T61

Hi No exactly sure which patch did it - but when I'm now checking 3.8-rc5 kernel, I cannot use anymore this 'undock' command: echo 1 /sys/devices/platform/dock.0/undock which works ok with 3.7 kernel - to properly undock my T61 before suspend. Dmesg shows this: [ 2657.087414] ACPI:

iwl3945 prints warning

Hi I'm getting tthis warning printed with current 3.8-rc kernel My hw is Lenovo T61. [5.920284] iwl3945 :03:00.0: loaded firmware version 15.32.2.9 [5.976605] systemd[1]: Started NFS file locking service.. [5.982624] NFSD: starting 90-second grace period (net

iwl3945 prints warning

Hi I'm getting tthis warning printed with current 3.8-rc kernel My hw is Lenovo T61. [5.920284] iwl3945 :03:00.0: loaded firmware version 15.32.2.9 [5.976605] systemd[1]: Started NFS file locking service.. [5.982624] NFSD: starting 90-second grace period (net

Re: kswapd craziness in 3.7

Dne 9.12.2012 02:01, Linus Torvalds napsal(a): On Sat, 8 Dec 2012, Zlatko Calusic wrote: Or sooner... in short: nothing's changed! On a 4GB RAM system, where applications use close to 2GB, kswapd likes to keep around 1GB free (unused), leaving only 1GB for page/buffer cache. If I force

Re: kswapd craziness in 3.7

Dne 9.12.2012 02:01, Linus Torvalds napsal(a): On Sat, 8 Dec 2012, Zlatko Calusic wrote: Or sooner... in short: nothing's changed! On a 4GB RAM system, where applications use close to 2GB, kswapd likes to keep around 1GB free (unused), leaving only 1GB for page/buffer cache. If I force

Re: kswapd craziness in 3.7

Dne 4.12.2012 10:05, Zdenek Kabelac napsal(a): Dne 3.12.2012 20:18, Johannes Weiner napsal(a): Szia Zdenek, On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote: Ok, bad news - I've been hit by kswapd0 loop again - my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again

Re: kswapd craziness in 3.7

Dne 4.12.2012 10:05, Zdenek Kabelac napsal(a): Dne 3.12.2012 20:18, Johannes Weiner napsal(a): Szia Zdenek, On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote: Ok, bad news - I've been hit by kswapd0 loop again - my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again

Re: kswapd craziness in 3.7

Dne 3.12.2012 20:18, Johannes Weiner napsal(a): Szia Zdenek, On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote: Ok, bad news - I've been hit by kswapd0 loop again - my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again shown kswapd0 for couple minutes on CPU

Re: kswapd craziness in 3.7

Dne 3.12.2012 20:18, Johannes Weiner napsal(a): Szia Zdenek, On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote: Ok, bad news - I've been hit by kswapd0 loop again - my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again shown kswapd0 for couple minutes on CPU

Re: kswapd craziness in 3.7

Dne 28.11.2012 10:45, Mel Gorman napsal(a): (Adding Thorsten to cc) On Tue, Nov 27, 2012 at 03:48:34PM -0500, Johannes Weiner wrote: Hi everyone, I hope I included everybody that participated in the various threads on kswapd getting stuck / exhibiting high CPU usage. We were looking at at

Re: kswapd craziness in 3.7

Dne 28.11.2012 10:45, Mel Gorman napsal(a): (Adding Thorsten to cc) On Tue, Nov 27, 2012 at 03:48:34PM -0500, Johannes Weiner wrote: Hi everyone, I hope I included everybody that participated in the various threads on kswapd getting stuck / exhibiting high CPU usage. We were looking at at

Re: Acpi deadlocks with 3.7.0-rc4

Dne 29.11.2012 11:59, Rafael J. Wysocki napsal(a): On Thursday, November 29, 2012 11:13:10 AM Zdenek Kabelac wrote: Dne 28.11.2012 20:07, Linus Torvalds napsal(a): whole "prefix_node" pointer is bogus. It seems to have the value 0x1000. Tested also this patch with this resu

Re: Acpi deadlocks with 3.7.0-rc4

Dne 28.11.2012 20:07, Linus Torvalds napsal(a): whole "prefix_node" pointer is bogus. It seems to have the value 0x1000. Tested also this patch with this result: https://bugzilla.kernel.org/show_bug.cgi?id=51071#c8 So while it's made it pass suspend/resume, it's not really usable as docking

Re: Acpi deadlocks with 3.7.0-rc4

Dne 28.11.2012 21:31, Rafael J. Wysocki napsal(a): On Wednesday, November 28, 2012 06:27:50 PM Zdenek Kabelac wrote: Dne 28.11.2012 18:02, Linus Torvalds napsal(a): On Wed, Nov 28, 2012 at 8:21 AM, Zdenek Kabelac wrote: I've opened https://bugzilla.kernel.org/show_bug.cgi?id=51071

Re: Acpi deadlocks with 3.7.0-rc4

Dne 28.11.2012 20:07, Linus Torvalds napsal(a): whole prefix_node pointer is bogus. It seems to have the value 0x1000. Tested also this patch with this result: https://bugzilla.kernel.org/show_bug.cgi?id=51071#c8 So while it's made it pass suspend/resume, it's not really usable as docking

Re: Acpi deadlocks with 3.7.0-rc4

Dne 29.11.2012 11:59, Rafael J. Wysocki napsal(a): On Thursday, November 29, 2012 11:13:10 AM Zdenek Kabelac wrote: Dne 28.11.2012 20:07, Linus Torvalds napsal(a): whole prefix_node pointer is bogus. It seems to have the value 0x1000. Tested also this patch with this result: https

Re: Acpi deadlocks with 3.7.0-rc4

Dne 28.11.2012 21:31, Rafael J. Wysocki napsal(a): On Wednesday, November 28, 2012 06:27:50 PM Zdenek Kabelac wrote: Dne 28.11.2012 18:02, Linus Torvalds napsal(a): On Wed, Nov 28, 2012 at 8:21 AM, Zdenek Kabelac zkabe...@redhat.com wrote: I've opened https://bugzilla.kernel.org

Re: Acpi deadlocks with 3.7.0-rc4

Dne 28.11.2012 18:02, Linus Torvalds napsal(a): On Wed, Nov 28, 2012 at 8:21 AM, Zdenek Kabelac wrote: I've opened https://bugzilla.kernel.org/show_bug.cgi?id=51071 and attached picture there which is all I have. I'll try to decode exact code line. Uhhuh. It's missing much of the relevant

Re: Acpi deadlocks with 3.7.0-rc4

Dne 28.11.2012 17:01, Linus Torvalds napsal(a): Adding more people (and the acpi list) to this report. I'm seeing *very* few changes to the core suspend/resume path in 3.7, and while there are some acpia updates, they seem to be pretty mild too. I think the acpi_os_wait_semaphore thing is a

Re: kswapd craziness in 3.7

Dne 27.11.2012 21:58, Linus Torvalds napsal(a): Note that in the meantime, I've also applied (through Andrew) the patch that reverts commit c654345924f7 (see commit 82b212f40059 'Revert "mm: remove __GFP_NO_KSWAPD"'). I wonder if that revert may be bogus, and a result of this same issue. Maybe

Re: kswapd craziness in 3.7

Dne 27.11.2012 21:58, Linus Torvalds napsal(a): Note that in the meantime, I've also applied (through Andrew) the patch that reverts commit c654345924f7 (see commit 82b212f40059 'Revert mm: remove __GFP_NO_KSWAPD'). I wonder if that revert may be bogus, and a result of this same issue. Maybe

Re: Acpi deadlocks with 3.7.0-rc4

Dne 28.11.2012 17:01, Linus Torvalds napsal(a): Adding more people (and the acpi list) to this report. I'm seeing *very* few changes to the core suspend/resume path in 3.7, and while there are some acpia updates, they seem to be pretty mild too. I think the acpi_os_wait_semaphore thing is a

Re: Acpi deadlocks with 3.7.0-rc4

Dne 28.11.2012 18:02, Linus Torvalds napsal(a): On Wed, Nov 28, 2012 at 8:21 AM, Zdenek Kabelac zkabe...@redhat.com wrote: I've opened https://bugzilla.kernel.org/show_bug.cgi?id=51071 and attached picture there which is all I have. I'll try to decode exact code line. Uhhuh. It's missing

Unbalanced unlock with sysrq+SUB

Hi For some time - when I reboot via 'sysrq + SUB' I get this BUG: message My system is running rawhide (systemd) on ext4 filesystem. systemd-195-7.fc18.x86_64 Zdenek SysRq : Emergency Remount R/O = [ BUG: bad unlock balance detected! ]

Unbalanced unlock with sysrq+SUB

Hi For some time - when I reboot via 'sysrq + SUB' I get this BUG: message My system is running rawhide (systemd) on ext4 filesystem. systemd-195-7.fc18.x86_64 Zdenek SysRq : Emergency Remount R/O = [ BUG: bad unlock balance detected! ]

Re: kswapd0: excessive CPU usage

Dne 12.11.2012 14:31, Mel Gorman napsal(a): On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote: Dne 12.11.2012 13:19, Mel Gorman napsal(a): On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote: Hmm, so it's just took longer to hit the problem and observe kswapd0

Re: kswapd0: excessive CPU usage

Dne 12.11.2012 14:31, Mel Gorman napsal(a): On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote: Dne 12.11.2012 13:19, Mel Gorman napsal(a): On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote: Hmm, so it's just took longer to hit the problem and observe kswapd0

Acpi deadlocks with 3.7.0-rc4

Hello I've already seen twice this oops after resuming my Lenovo T61 in docking station. Since for some reason currently the serial line doesn't work correctly after resume (while I'm pretty sure it used to work in past) here is at least hand-written oops message from mobile camera

Acpi deadlocks with 3.7.0-rc4

Hello I've already seen twice this oops after resuming my Lenovo T61 in docking station. Since for some reason currently the serial line doesn't work correctly after resume (while I'm pretty sure it used to work in past) here is at least hand-written oops message from mobile camera

Re: kswapd0: excessive CPU usage

Dne 12.11.2012 14:31, Mel Gorman napsal(a): On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote: Dne 12.11.2012 13:19, Mel Gorman napsal(a): On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote: Hmm, so it's just took longer to hit the problem and observe kswapd0

Re: kswapd0: excessive CPU usage

Dne 12.11.2012 13:19, Mel Gorman napsal(a): On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote: Hmm, so it's just took longer to hit the problem and observe kswapd0 spinning on my CPU again - it's not as endless like before - but still it easily eats minutes - it helps to turn off

Re: kswapd0: excessive CPU usage

Dne 12.11.2012 13:19, Mel Gorman napsal(a): On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote: Hmm, so it's just took longer to hit the problem and observe kswapd0 spinning on my CPU again - it's not as endless like before - but still it easily eats minutes - it helps to turn off

Re: kswapd0: excessive CPU usage

Dne 12.11.2012 14:31, Mel Gorman napsal(a): On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote: Dne 12.11.2012 13:19, Mel Gorman napsal(a): On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote: Hmm, so it's just took longer to hit the problem and observe kswapd0

Re: kswapd0: excessive CPU usage

Dne 9.11.2012 10:06, Mel Gorman napsal(a): On Fri, Nov 09, 2012 at 09:07:45AM +0100, Zdenek Kabelac wrote: fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c Author: Rik van Riel Date: Wed Mar 21 16:33:51 2012 -0700 vmscan

Re: kswapd0: excessive CPU usage

Dne 9.11.2012 10:06, Mel Gorman napsal(a): On Fri, Nov 09, 2012 at 09:07:45AM +0100, Zdenek Kabelac wrote: fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c Author: Rik van Riel r...@redhat.com Date: Wed Mar 21 16:33:51 2012 -0700

Re: kswapd0: excessive CPU usage

Dne 9.11.2012 05:22, Seth Jennings napsal(a): On 11/02/2012 02:45 PM, Jiri Slaby wrote: On 11/02/2012 11:53 AM, Jiri Slaby wrote: On 11/02/2012 11:44 AM, Zdenek Kabelac wrote: Yes, applying this instead of the revert fixes the issue as well. I've applied this patch on 3.7.0-rc3 kernel

Re: kswapd0: excessive CPU usage

Dne 9.11.2012 05:22, Seth Jennings napsal(a): On 11/02/2012 02:45 PM, Jiri Slaby wrote: On 11/02/2012 11:53 AM, Jiri Slaby wrote: On 11/02/2012 11:44 AM, Zdenek Kabelac wrote: Yes, applying this instead of the revert fixes the issue as well. I've applied this patch on 3.7.0-rc3 kernel

  1   2   >