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

[Zdenek Kabelac]

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 'startx'
(even Sysrq+B no longer works and 5s power-off need to be used).

I've opened issue here - but seems has got no traction:
https://gitlab.freedesktop.org/drm/intel/-/issues/3293

So I've played bisect game with above end result.

I'd to apply https://lkml.org/lkml/2021/1/23/75 to be able to compile
bisected kernels on my Rawhide's gcc)

Cause of kernel bug is list corruption i.e.:



kernel BUG at lib/list_debug.c:54!
invalid opcode:  [#1] SMP NOPTI
CPU: 0 PID: 1606 Comm: Xorg Tainted: G U  - --- 
5.12.0-0.rc4.175.fc35.x86_64 #1

Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
RIP: 0010:__list_del_entry_valid.cold+0x1d/0x47
Code: c7 c7 d8 29 61 84 e8 f4 2e fe ff 0f 0b 48 89 fe 48 c7 c7 68 2a 61 84 e8 
e3 2e fe ff 0f 0b 48 c7 c7 18 2b 61 84 e8 d5 2e fe ff <0f> 0b 48 89 f2 48 89 
fe 48 c7 c7 d8 2a 61 84 e8 c1 2e fe ff 0f 0b

RSP: 0018:a4f800a3bd88 EFLAGS: 00010082
RAX: 0054 RBX: a4f800a3be58 RCX: 
RDX: 9823b7826720 RSI: 9823b78185c0 RDI: 9823b78185c0
RBP: 9823ad542a40 R08:  R09: a4f800a3bbc0
R10: a4f800a3bbb8 R11: 9823bbefcfe8 R12: 982389305b28
R13:  R14: 9823ad542c30 R15: 982389305b20
FS:  7f837ababa80() GS:9823b780() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f836fac99f0 CR3: 0001234ee000 CR4: 06f0
Call Trace:
 i915_gem_madvise_ioctl+0x1fc/0x2b0 [i915]
 ? i915_gem_pwrite_ioctl+0x480/0x480 [i915]
 drm_ioctl_kernel+0x8e/0xe0 [drm]
 drm_ioctl+0x21e/0x3b0 [drm]
 ? i915_gem_pwrite_ioctl+0x480/0x480 [i915]
 __x64_sys_ioctl+0x82/0xb0
 do_syscall_64+0x33/0x40
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f837b3f52ab
Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 
1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 
01 c3 48 8b 0d 95 bb 0c 00 f7 d8 64 89 01 48

RSP: 002b:7ffe12d62cb8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7f8379dcd360 RCX: 7f837b3f52ab
RDX: 7ffe12d62d00 RSI: c00c6466 RDI: 000d
RBP: 000d R08: 55dee119e9c0 R09: 605c6199
R10: 7ffe12d7d080 R11: 0246 R12: 55dee1884ed0
R13: c00c6466 R14: 7f8379dcd000 R15: 7ffe12d62d00
Modules linked in: rfcomm ccm xt_CHECKSUM xt_MASQUERADE xt_conntrack 
ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat ip6table_filter 
ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 iptable_filter bridge stp llc cmac bnep btusb btrtl btbcm 
btintel bluetooth ecdh_generic ecc coretemp snd_hda_codec_analog 
snd_hda_codec_generic kvm_intel kvm iTCO_wdt intel_pmc_bxt iTCO_vendor_support 
iwl3945 iwlegacy snd_hda_intel irqbypass snd_intel_dspcfg snd_intel_sdw_acpi 
mac80211 snd_hda_codec snd_hda_core pcspkr snd_hwdep snd_seq snd_seq_device 
snd_pcm cfg80211 joydev i2c_i801 wmi_bmof i2c_smbus thinkpad_acpi e1000e r592 
snd_timer lpc_ich memstick platform_profile
ledtrig_audio libarc4 snd soundcore rfkill acpi_cpufreq binfmt_misc nfsd 
auth_rpcgss fuse nfs_acl lockd grace sunrpc nfs_ssc ip_tables i915 
i2c_algo_bit drm_kms_helper cec drm sdhci_pci cqhci sdhci serio_raw mmc_core 
ata_generic wmi yenta_socket pata_acpi video




Interesting to note could be also that my 5.11 kernel takes quite some time
to show xfce desktop once after 'startx' command is executed - for many 
seconds there is just black screen.


While doing bisect it seems it starts with commit:

41a9c75d0acf23f33f012d3f9535de9e9b631051

the preceding commit in my bisection 'game' seemed to be starting much faster:

30d2bfd093839cf6eef93f9c2cbdc347c7bf8b20

Anyway - the head of this message is more important to resolve.

Regards

Zdenek
<>

Unable to suspend lenovo t61

[Zdenek Kabelac]

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 ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
printk: Suspending console(s) (use no_console_suspend to debug)
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
tpm tpm0: tpm_try_transmit: send(): error -5
tpm tpm0: Error (-5) sending savestate before suspend
PM: __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x80 returns -5
PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns -5
PM: Device 00:05 failed to suspend: error -5
PM: Some devices failed to suspend, or early wake event detected
sd 0:0:0:0: [sda] Starting disk
thinkpad_acpi: ACPI backlight control delay disabled
usb 3-2: reset full-speed USB device number 2 using uhci_hcd
ata4.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered out
ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out
ata3: SATA link down (SStatus 0 SControl 300)
PM: resume devices took 1.009 seconds
OOM killer enabled.
Restarting tasks ... done.
PM: suspend exit
sleep[3690]: Failed to suspend system. System resumed again: Input/output error


Here are some other tpm message visible on 5.1.0-0.rc3.git1.2.fc31.x86_64
(but they are shown in similar way on usable & suspendable -rc0)

Non-volatile memory driver v1.3
Linux agpgart interface v0.103
battery: ACPI: Battery Slot [BAT0] (battery present)
tpm_tis 00:05: 1.2 TPM (device-id 0x, rev-id 255)
tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A 1->1us B 
1->1us C 0->75us D 0->75us

tpm tpm0: TPM is disabled/deactivated (0x6)
ahci :00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x5 impl SATA mode
ahci :00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc
scsi host0: ahci
scsi host1: ahci
scsi host2: ahci
ata1: SATA max UDMA/133 abar m2048@0xfe226000 port 0xfe226100 irq 27
ata2: DUMMY

mip6: Mobile IPv6
NET: Registered protocol family 17
RAS: Correctable Errors collector initialized.
microcode: sig=0x6fa, pf=0x80, revision=0x95
microcode: Microcode Update Driver: v2.2.
registered taskstats version 1
Loading compiled-in X.509 certificates
Loaded X.509 cert 'Fedora kernel signing key: 
1662e00568f2df66b8eaccc8f8971f03bb9d8329'

zswap: loaded using pool lzo/zbud
Key type big_key registered
Key type encrypted registered
ima: Allocated hash algorithm: sha1
ima: Error Communicating to TPM chip
ima: Error Communicating to TPM chip
ima: Error Communicating to TPM chip
ima: Error Communicating to TPM chip
ima: Error Communicating to TPM chip
ima: Error Communicating to TPM chip
ima: Error Communicating to TPM chip
ima: Error Communicating to TPM chip
No architecture policies found
PM:   Magic number: 15:928:528
rtc_cmos 00:02: setting system clock to 2019-04-04T11:31:05 UTC (1554377465)
ata4.00: ATAPI: MATSHITADVD-RAM UJ-842 z, RC01, max UDMA/33
Unstable clock detected, switching default tracing clock to "global"#012If you 
want to keep using the local clock, then add:#012  "trace_clock=local"#012on 
the kernel command line

ata3: SATA link down (SStatus 0 SControl 300)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)


If there is more info needed let me know.

Regards

Zdenek

Re: Timing performance regression 4.15 to 4.16-rc1

[Zdenek Kabelac]

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 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 44c02a2c3dc55835e9f0d8ef73966406cd805001
Author: Al Viro <v...@zeniv.linux.org.uk>
Date:   Thu Oct 5 12:59:44 2017 -0400

 dev_ioctl(): move copyin/copyout to callers


---

clear revert of this commit on top of 
3266b5bd97eaa72793df0b6e5a106c69ccc166c4

(recent  ~4.16-rc4)  restored timing of tests back.


I'm not sure why - so at this moment this is just a patch causing 15% longer
running times on lvm2 test suite.


I find it very hard to believe, TBH.  It doesn't go anywhere near drivers/md;
could you profile the damn thing and see where does it spend that extra time?

It really doesn't touch anything on non-sockets...



Hi

Well I'm 100% sure it's this patch causing slowdown of the test runtime
(just reverting this case makes it faster).

But even though I've already tried to create some much more simplified 
reproducer I'm still unclear what's behind it.


lvm2 alone is using sockets via i.e. udev communication - so the possible 
reason could be that used slows down  'new node' events processing in some way.


So for now the most visible reproducer is to run test in lvm2 build tree
in directory tests/:   'make check_local T=lvconvert-mirror-basic-0.sh'

I do have 'perf record' grabs if the would help anything - but looking at 
them myself there are not some directly visible things.


As said -  User+Sys timing of the running test reported by 'time' command 
remains the same - just 'real' time gets longer - which means it's waiting 
for something much longer then before  - lvm2 typically waits till udev 
finishes it's scanning.




Hello

Here is my update - after some time of investigation - it seems the core 
trouble is actually hidden inside  test monitoring tool which is effectively 
grabbing test output through  a PF_UNIX socket stream - there are no other 
sockets. (and via add printk() used commands are 21519  & 21505  for 
dev_ioctl() call).


Also there is no influence caused by udev as since timing is same with disable 
udev.


So ATM I'm checking, why there is such a big change in this case in the test's 
is run via internal application which is collecting logs compare with direct 
execution.




So further evaluation revealed the key issue that
'runner' tool is using:

socketpair( PF_UNIX, SOCK_STREAM, 0, fds )

to create 2 FDs for capturing output of executed program.

If just this 'socketpair()' is replaced back to 'good old' pipe(fds)
it immediately restores performance back.

So remembering lvm history here the code has been originally actually using 
pipe() and many years back and it's been upgraded to use socketpair().


So with your current kernel patch it seems some latency slowed down this 
use-case in noticeable way (any new buffering ??).


The streamed buffer during this particular test has around 400K and 5K lines
(which is not that much for ~70 second output)

So let me know if you need some more info ?

Regards

Zdenek

Re: Timing performance regression 4.15 to 4.16-rc1

[Zdenek Kabelac]

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 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 44c02a2c3dc55835e9f0d8ef73966406cd805001
Author: Al Viro 
Date:   Thu Oct 5 12:59:44 2017 -0400

 dev_ioctl(): move copyin/copyout to callers


---

clear revert of this commit on top of 
3266b5bd97eaa72793df0b6e5a106c69ccc166c4

(recent  ~4.16-rc4)  restored timing of tests back.


I'm not sure why - so at this moment this is just a patch causing 15% longer
running times on lvm2 test suite.


I find it very hard to believe, TBH.  It doesn't go anywhere near drivers/md;
could you profile the damn thing and see where does it spend that extra time?

It really doesn't touch anything on non-sockets...



Hi

Well I'm 100% sure it's this patch causing slowdown of the test runtime
(just reverting this case makes it faster).

But even though I've already tried to create some much more simplified 
reproducer I'm still unclear what's behind it.


lvm2 alone is using sockets via i.e. udev communication - so the possible 
reason could be that used slows down  'new node' events processing in some way.


So for now the most visible reproducer is to run test in lvm2 build tree
in directory tests/:   'make check_local T=lvconvert-mirror-basic-0.sh'

I do have 'perf record' grabs if the would help anything - but looking at 
them myself there are not some directly visible things.


As said -  User+Sys timing of the running test reported by 'time' command 
remains the same - just 'real' time gets longer - which means it's waiting 
for something much longer then before  - lvm2 typically waits till udev 
finishes it's scanning.




Hello

Here is my update - after some time of investigation - it seems the core 
trouble is actually hidden inside  test monitoring tool which is effectively 
grabbing test output through  a PF_UNIX socket stream - there are no other 
sockets. (and via add printk() used commands are 21519  & 21505  for 
dev_ioctl() call).


Also there is no influence caused by udev as since timing is same with disable 
udev.


So ATM I'm checking, why there is such a big change in this case in the test's 
is run via internal application which is collecting logs compare with direct 
execution.




So further evaluation revealed the key issue that
'runner' tool is using:

socketpair( PF_UNIX, SOCK_STREAM, 0, fds )

to create 2 FDs for capturing output of executed program.

If just this 'socketpair()' is replaced back to 'good old' pipe(fds)
it immediately restores performance back.

So remembering lvm history here the code has been originally actually using 
pipe() and many years back and it's been upgraded to use socketpair().


So with your current kernel patch it seems some latency slowed down this 
use-case in noticeable way (any new buffering ??).


The streamed buffer during this particular test has around 400K and 5K lines
(which is not that much for ~70 second output)

So let me know if you need some more info ?

Regards

Zdenek

Re: Timing performance regression 4.15 to 4.16-rc1

[Zdenek Kabelac]

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 itself should not
really load CPU system  - the overall running time just got bigger.

Running bisect game pointed clearly to this commit:

---

commit 44c02a2c3dc55835e9f0d8ef73966406cd805001
Author: Al Viro <v...@zeniv.linux.org.uk>
Date:   Thu Oct 5 12:59:44 2017 -0400

 dev_ioctl(): move copyin/copyout to callers


---

clear revert of this commit on top of 3266b5bd97eaa72793df0b6e5a106c69ccc166c4
(recent  ~4.16-rc4)  restored timing of tests back.


I'm not sure why - so at this moment this is just a patch causing 15% longer
running times on lvm2 test suite.


I find it very hard to believe, TBH.  It doesn't go anywhere near drivers/md;
could you profile the damn thing and see where does it spend that extra time?

It really doesn't touch anything on non-sockets...



Hi

Well I'm 100% sure it's this patch causing slowdown of the test runtime
(just reverting this case makes it faster).

But even though I've already tried to create some much more simplified 
reproducer I'm still unclear what's behind it.


lvm2 alone is using sockets via i.e. udev communication - so the possible 
reason could be that used slows down  'new node' events processing in some way.


So for now the most visible reproducer is to run test in lvm2 build tree
in directory tests/:   'make check_local T=lvconvert-mirror-basic-0.sh'

I do have 'perf record' grabs if the would help anything - but looking at them 
myself there are not some directly visible things.


As said -  User+Sys timing of the running test reported by 'time' command 
remains the same - just 'real' time gets longer - which means it's waiting for 
something much longer then before  - lvm2 typically waits till udev finishes 
it's scanning.




Hello

Here is my update - after some time of investigation - it seems the core 
trouble is actually hidden inside  test monitoring tool which is effectively 
grabbing test output through  a PF_UNIX socket stream - there are no other 
sockets. (and via add printk() used commands are 21519  & 21505  for 
dev_ioctl() call).


Also there is no influence caused by udev as since timing is same with disable 
udev.


So ATM I'm checking, why there is such a big change in this case in the test's 
is run via internal application which is collecting logs compare with direct 
execution.


One more thing that has surprised me is the influence of CPU governor - the 
difference between ondemand/performance governor is another 10 seconds.

(on a test taking slight more then 1 minute).

Regards

Zdenek

Re: Timing performance regression 4.15 to 4.16-rc1

[Zdenek Kabelac]

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 itself should not
really load CPU system  - the overall running time just got bigger.

Running bisect game pointed clearly to this commit:

---

commit 44c02a2c3dc55835e9f0d8ef73966406cd805001
Author: Al Viro 
Date:   Thu Oct 5 12:59:44 2017 -0400

 dev_ioctl(): move copyin/copyout to callers


---

clear revert of this commit on top of 3266b5bd97eaa72793df0b6e5a106c69ccc166c4
(recent  ~4.16-rc4)  restored timing of tests back.


I'm not sure why - so at this moment this is just a patch causing 15% longer
running times on lvm2 test suite.


I find it very hard to believe, TBH.  It doesn't go anywhere near drivers/md;
could you profile the damn thing and see where does it spend that extra time?

It really doesn't touch anything on non-sockets...



Hi

Well I'm 100% sure it's this patch causing slowdown of the test runtime
(just reverting this case makes it faster).

But even though I've already tried to create some much more simplified 
reproducer I'm still unclear what's behind it.


lvm2 alone is using sockets via i.e. udev communication - so the possible 
reason could be that used slows down  'new node' events processing in some way.


So for now the most visible reproducer is to run test in lvm2 build tree
in directory tests/:   'make check_local T=lvconvert-mirror-basic-0.sh'

I do have 'perf record' grabs if the would help anything - but looking at them 
myself there are not some directly visible things.


As said -  User+Sys timing of the running test reported by 'time' command 
remains the same - just 'real' time gets longer - which means it's waiting for 
something much longer then before  - lvm2 typically waits till udev finishes 
it's scanning.




Hello

Here is my update - after some time of investigation - it seems the core 
trouble is actually hidden inside  test monitoring tool which is effectively 
grabbing test output through  a PF_UNIX socket stream - there are no other 
sockets. (and via add printk() used commands are 21519  & 21505  for 
dev_ioctl() call).


Also there is no influence caused by udev as since timing is same with disable 
udev.


So ATM I'm checking, why there is such a big change in this case in the test's 
is run via internal application which is collecting logs compare with direct 
execution.


One more thing that has surprised me is the influence of CPU governor - the 
difference between ondemand/performance governor is another 10 seconds.

(on a test taking slight more then 1 minute).

Regards

Zdenek

Re: Timing performance regression 4.15 to 4.16-rc1

[Zdenek Kabelac]

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  - the overall running time just got bigger.

Running bisect game pointed clearly to this commit:

---

commit 44c02a2c3dc55835e9f0d8ef73966406cd805001
Author: Al Viro <v...@zeniv.linux.org.uk>
Date:   Thu Oct 5 12:59:44 2017 -0400

 dev_ioctl(): move copyin/copyout to callers


---

clear revert of this commit on top of 3266b5bd97eaa72793df0b6e5a106c69ccc166c4
(recent  ~4.16-rc4)  restored timing of tests back.


I'm not sure why - so at this moment this is just a patch causing 15% longer
running times on lvm2 test suite.


I find it very hard to believe, TBH.  It doesn't go anywhere near drivers/md;
could you profile the damn thing and see where does it spend that extra time?

It really doesn't touch anything on non-sockets...



Hi

Well I'm 100% sure it's this patch causing slowdown of the test runtime
(just reverting this case makes it faster).

But even though I've already tried to create some much more simplified 
reproducer I'm still unclear what's behind it.


lvm2 alone is using sockets via i.e. udev communication - so the possible 
reason could be that used slows down  'new node' events processing in some way.


So for now the most visible reproducer is to run test in lvm2 build tree
in directory tests/:   'make check_local T=lvconvert-mirror-basic-0.sh'

I do have 'perf record' grabs if the would help anything - but looking at them 
myself there are not some directly visible things.


As said -  User+Sys timing of the running test reported by 'time' command 
remains the same - just 'real' time gets longer - which means it's waiting for 
something much longer then before  - lvm2 typically waits till udev finishes 
it's scanning.


Regards


Zdenek

Re: Timing performance regression 4.15 to 4.16-rc1

[Zdenek Kabelac]

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  - the overall running time just got bigger.

Running bisect game pointed clearly to this commit:

---

commit 44c02a2c3dc55835e9f0d8ef73966406cd805001
Author: Al Viro 
Date:   Thu Oct 5 12:59:44 2017 -0400

 dev_ioctl(): move copyin/copyout to callers


---

clear revert of this commit on top of 3266b5bd97eaa72793df0b6e5a106c69ccc166c4
(recent  ~4.16-rc4)  restored timing of tests back.


I'm not sure why - so at this moment this is just a patch causing 15% longer
running times on lvm2 test suite.


I find it very hard to believe, TBH.  It doesn't go anywhere near drivers/md;
could you profile the damn thing and see where does it spend that extra time?

It really doesn't touch anything on non-sockets...



Hi

Well I'm 100% sure it's this patch causing slowdown of the test runtime
(just reverting this case makes it faster).

But even though I've already tried to create some much more simplified 
reproducer I'm still unclear what's behind it.


lvm2 alone is using sockets via i.e. udev communication - so the possible 
reason could be that used slows down  'new node' events processing in some way.


So for now the most visible reproducer is to run test in lvm2 build tree
in directory tests/:   'make check_local T=lvconvert-mirror-basic-0.sh'

I do have 'perf record' grabs if the would help anything - but looking at them 
myself there are not some directly visible things.


As said -  User+Sys timing of the running test reported by 'time' command 
remains the same - just 'real' time gets longer - which means it's waiting for 
something much longer then before  - lvm2 typically waits till udev finishes 
it's scanning.


Regards


Zdenek

Timing performance regression 4.15 to 4.16-rc1

[Zdenek Kabelac]

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 44c02a2c3dc55835e9f0d8ef73966406cd805001
Author: Al Viro 
Date:   Thu Oct 5 12:59:44 2017 -0400

dev_ioctl(): move copyin/copyout to callers


---

clear revert of this commit on top of 3266b5bd97eaa72793df0b6e5a106c69ccc166c4
(recent  ~4.16-rc4)  restored timing of tests back.


I'm not sure why - so at this moment this is just a patch causing 15% longer 
running times on lvm2 test suite.



Regards

Zdenek

Timing performance regression 4.15 to 4.16-rc1

[Zdenek Kabelac]

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 44c02a2c3dc55835e9f0d8ef73966406cd805001
Author: Al Viro 
Date:   Thu Oct 5 12:59:44 2017 -0400

dev_ioctl(): move copyin/copyout to callers


---

clear revert of this commit on top of 3266b5bd97eaa72793df0b6e5a106c69ccc166c4
(recent  ~4.16-rc4)  restored timing of tests back.


I'm not sure why - so at this moment this is just a patch causing 15% longer 
running times on lvm2 test suite.



Regards

Zdenek

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

[Zdenek Kabelac]

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
increments aren't allowed
  - counter schema uses basic atomic operations
(set, inc, inc_not_zero, dec_and_test, etc.)

Such atomic variables should be converted to a newly provided
refcount_t type and API that prevents accidental counter overflows
and underflows. This is important since overflows and underflows
can lead to use-after-free situation and be exploitable.

The variable table_device.count is used as pure reference counter.
Convert it to refcount_t and fix up the operations.

Suggested-by: Kees Cook 
Reviewed-by: David Windsor 
Reviewed-by: Hans Liljestrand 
Signed-off-by: Elena Reshetova 
---
  drivers/md/dm.c | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 4be8532..be12f3f 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define DM_MSG_PREFIX "core"
  
@@ -98,7 +99,7 @@ struct dm_md_mempools {
  
  struct table_device {

struct list_head list;
-   atomic_t count;
+   refcount_t count;
struct dm_dev dm_dev;
  };
  
@@ -685,10 +686,11 @@ int dm_get_table_device(struct mapped_device *md, dev_t dev, fmode_t mode,
  
  		format_dev_t(td->dm_dev.name, dev);
  
-		atomic_set(>count, 0);

+   refcount_set(>count, 1);
list_add(>list, >table_devices);
+   } else {
+   refcount_inc(>count);
}
-   atomic_inc(>count);
mutex_unlock(>table_devices_lock);
  



NACK

This patch (2a0b4682e09d76466f7b8f5e347ae2ff02f033af) currently breaks 
accounting of opened devices.


I.e.   multisegment device  (target with 3 segments is not properly accounted)


Patch needs reworking and users of 'dm' and 4.15-rc0 kernel should rather 
switch back to 4.14 ATM as it's unclear which other parts can be affected.


Zdenek


*result = >dm_dev;
@@ -701,7 +703,7 @@ void dm_put_table_device(struct mapped_device *md, struct 
dm_dev *d)
struct table_device *td = container_of(d, struct table_device, dm_dev);
  
  	mutex_lock(>table_devices_lock);

-   if (atomic_dec_and_test(>count)) {
+   if (refcount_dec_and_test(>count)) {
close_table_device(td, md);
list_del(>list);
kfree(td);
@@ -718,7 +720,7 @@ static void free_table_devices(struct list_head *devices)
struct table_device *td = list_entry(tmp, struct table_device, 
list);
  
  		DMWARN("dm_destroy: %s still exists with %d references",

-  td->dm_dev.name, atomic_read(>count));
+  td->dm_dev.name, refcount_read(>count));
kfree(td);
}
  }

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

[Zdenek Kabelac]

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
increments aren't allowed
  - counter schema uses basic atomic operations
(set, inc, inc_not_zero, dec_and_test, etc.)

Such atomic variables should be converted to a newly provided
refcount_t type and API that prevents accidental counter overflows
and underflows. This is important since overflows and underflows
can lead to use-after-free situation and be exploitable.

The variable table_device.count is used as pure reference counter.
Convert it to refcount_t and fix up the operations.

Suggested-by: Kees Cook 
Reviewed-by: David Windsor 
Reviewed-by: Hans Liljestrand 
Signed-off-by: Elena Reshetova 
---
  drivers/md/dm.c | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 4be8532..be12f3f 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define DM_MSG_PREFIX "core"
  
@@ -98,7 +99,7 @@ struct dm_md_mempools {
  
  struct table_device {

struct list_head list;
-   atomic_t count;
+   refcount_t count;
struct dm_dev dm_dev;
  };
  
@@ -685,10 +686,11 @@ int dm_get_table_device(struct mapped_device *md, dev_t dev, fmode_t mode,
  
  		format_dev_t(td->dm_dev.name, dev);
  
-		atomic_set(>count, 0);

+   refcount_set(>count, 1);
list_add(>list, >table_devices);
+   } else {
+   refcount_inc(>count);
}
-   atomic_inc(>count);
mutex_unlock(>table_devices_lock);
  



NACK

This patch (2a0b4682e09d76466f7b8f5e347ae2ff02f033af) currently breaks 
accounting of opened devices.


I.e.   multisegment device  (target with 3 segments is not properly accounted)


Patch needs reworking and users of 'dm' and 4.15-rc0 kernel should rather 
switch back to 4.14 ATM as it's unclear which other parts can be affected.


Zdenek


*result = >dm_dev;
@@ -701,7 +703,7 @@ void dm_put_table_device(struct mapped_device *md, struct 
dm_dev *d)
struct table_device *td = container_of(d, struct table_device, dm_dev);
  
  	mutex_lock(>table_devices_lock);

-   if (atomic_dec_and_test(>count)) {
+   if (refcount_dec_and_test(>count)) {
close_table_device(td, md);
list_del(>list);
kfree(td);
@@ -718,7 +720,7 @@ static void free_table_devices(struct list_head *devices)
struct table_device *td = list_entry(tmp, struct table_device, 
list);
  
  		DMWARN("dm_destroy: %s still exists with %d references",

-  td->dm_dev.name, atomic_read(>count));
+  td->dm_dev.name, refcount_read(>count));
kfree(td);
}
  }

Re: Detecting page cache trashing state

[Zdenek Kabelac]

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, so it is expected. The issue is that
OOM killer doesn't get triggered because there is still memory for
reclaiming. System may stuck in this state for a quite some time and
usually dies because of watchdogs.

We are trying to detect such trashing state early to take some
preventive actions. It should be a pretty common issue, but for now we
haven't find any existing VM/IO statistics that can reliably detect such
state.

Most of metrics provide absolute values: number/rate of page faults,
rate of IO operations, number of stolen pages, etc. For a specific
device configuration we can determine threshold values for those
parameters that will detect trashing state, but it is not feasible for
hundreds of device configurations.

We are looking for some relative metric like "percent of CPU time spent
handling major page faults". With such relative metric we could use a
common threshold across all devices. For now we have added such metric
to /proc/stat in our kernel, but we would like to find some mechanism
available in upstream kernel.

Has somebody faced similar issue? How are you solving it?


Hi

Well I witness this when running Firefox & Thunderbird on my desktop for a 
while on just 4G RAM machine till these 2app eat all free RAM...


It gets to the position (when I open new tab) that mouse hardly moves - 
kswapd eats  CPU  (I've no swap in fact - so likely just page-caching).


The only 'quick' solution for me as desktop user is to manually invoke OOM
with SYSRQ+F key -  and I'm also wondering why the system is not reacting 
better.  In most cases it kills one of those 2 - but sometime it kills whole 
Xsession...



Regards

Zdenek

Re: Detecting page cache trashing state

[Zdenek Kabelac]

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, so it is expected. The issue is that
OOM killer doesn't get triggered because there is still memory for
reclaiming. System may stuck in this state for a quite some time and
usually dies because of watchdogs.

We are trying to detect such trashing state early to take some
preventive actions. It should be a pretty common issue, but for now we
haven't find any existing VM/IO statistics that can reliably detect such
state.

Most of metrics provide absolute values: number/rate of page faults,
rate of IO operations, number of stolen pages, etc. For a specific
device configuration we can determine threshold values for those
parameters that will detect trashing state, but it is not feasible for
hundreds of device configurations.

We are looking for some relative metric like "percent of CPU time spent
handling major page faults". With such relative metric we could use a
common threshold across all devices. For now we have added such metric
to /proc/stat in our kernel, but we would like to find some mechanism
available in upstream kernel.

Has somebody faced similar issue? How are you solving it?


Hi

Well I witness this when running Firefox & Thunderbird on my desktop for a 
while on just 4G RAM machine till these 2app eat all free RAM...


It gets to the position (when I open new tab) that mouse hardly moves - 
kswapd eats  CPU  (I've no swap in fact - so likely just page-caching).


The only 'quick' solution for me as desktop user is to manually invoke OOM
with SYSRQ+F key -  and I'm also wondering why the system is not reacting 
better.  In most cases it kills one of those 2 - but sometime it kills whole 
Xsession...



Regards

Zdenek

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

[Zdenek Kabelac]

Dne 27.7.2017 v 03:03 Alan Stern napsal(a):

[Added linux-usb mailing list to CC:]

Short description of bug: In 4.12 or later, when Zdenek's Western
Digital disk is attached to an EHCI controller, it ends up connecting
at full speed to the companion UHCI controller instead.  But when
commit 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 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 entirely correctly, it wouldn't do that.

We could continue futzing around with hardware and driver tests for a
long time.  But there may be a shortcut: If you have a USB hub, you
could try attaching the drive through it.  It's entirely possible that
this will fix the problem.

If not, you'll have to start doing some very detailed tests.  As a
start, you can enable debugging for the usbcore and ehci_hcd drivers
immediately before the test:

echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module ehci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
dmesg -C

Then after the test, see what shows up in the dmesg output.  And again,
we'll want to do a comparison.  In fact, 4.12 with and without the
commit you identified would make a better comparison than 4.12 vs. 4.8.




Hi


So here we go with traces - made with freshly compiled recent 4.13-rc2.
OK trace is with revert patch applied.
BAD trace is the one with it (essentially vaniala master).

Trace also has KOBJECT debugging enabled - I think difference is
nicely visible between them - but I've no explanation for it.

Both traces start with cable detach followed with attachment.


Okay, I figured out the cause.

The USB stack assumes that if a high-speed device initialization fails
and the device is still connected, it means that the device can't run
properly at high speed and the computer needs to try again at full
speed.  See commit 90da096ee46b ("USB: force handover port to companion
when hub_port_connect_change fails").

In Zdenek's case, the device really does disconnect itself before the
second port reset.  If 22547c4cc4fe is present, it causes an extra
delay -- some 200 ms -- long enough for the device to reconnect again.
So we appear to be in the situation described above, and the connection
is switched over to the companion controller.

If 22547c4cc4fe is not present, the kernel sees that the device is not
connected at the end of the second reset and gives up trying to
initialize the device.  When the device reconnects about 140 ms later,
the kernel treats it as a new connection and successfully negotiates a
high-speed link.

Zdenek, you check this explanation by commenting out these last two
lines at the end of hub_port_connect() in drivers/usb/core/hub.c:

if (hcd->driver->relinquish_port && !hub->hdev->parent)
hcd->driver->relinquish_port(hcd, port1);

That should prevent the connection from being handed over to the UHCI
companion, allowing the device to operate at high speed.



Hi

Yep - seems this helped - I've dropped revert and commented those 2 lines
and I've used the very same kernel - and speed was all good:

usb 2-2: new high-speed USB device number 2 using ehci-pci
usb 2-2: new high-speed USB device number 3 using ehci-pci
usb 2-2: New USB device found, idVendor=1058, idProduct=10a8
usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3


So while I'm not sure if this is final fix for USB - this solution surely 
solved my WD Element disk attachment issue.


Regards

Zdenek

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

[Zdenek Kabelac]

Dne 27.7.2017 v 03:03 Alan Stern napsal(a):

[Added linux-usb mailing list to CC:]

Short description of bug: In 4.12 or later, when Zdenek's Western
Digital disk is attached to an EHCI controller, it ends up connecting
at full speed to the companion UHCI controller instead.  But when
commit 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 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 entirely correctly, it wouldn't do that.

We could continue futzing around with hardware and driver tests for a
long time.  But there may be a shortcut: If you have a USB hub, you
could try attaching the drive through it.  It's entirely possible that
this will fix the problem.

If not, you'll have to start doing some very detailed tests.  As a
start, you can enable debugging for the usbcore and ehci_hcd drivers
immediately before the test:

echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module ehci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
dmesg -C

Then after the test, see what shows up in the dmesg output.  And again,
we'll want to do a comparison.  In fact, 4.12 with and without the
commit you identified would make a better comparison than 4.12 vs. 4.8.




Hi


So here we go with traces - made with freshly compiled recent 4.13-rc2.
OK trace is with revert patch applied.
BAD trace is the one with it (essentially vaniala master).

Trace also has KOBJECT debugging enabled - I think difference is
nicely visible between them - but I've no explanation for it.

Both traces start with cable detach followed with attachment.


Okay, I figured out the cause.

The USB stack assumes that if a high-speed device initialization fails
and the device is still connected, it means that the device can't run
properly at high speed and the computer needs to try again at full
speed.  See commit 90da096ee46b ("USB: force handover port to companion
when hub_port_connect_change fails").

In Zdenek's case, the device really does disconnect itself before the
second port reset.  If 22547c4cc4fe is present, it causes an extra
delay -- some 200 ms -- long enough for the device to reconnect again.
So we appear to be in the situation described above, and the connection
is switched over to the companion controller.

If 22547c4cc4fe is not present, the kernel sees that the device is not
connected at the end of the second reset and gives up trying to
initialize the device.  When the device reconnects about 140 ms later,
the kernel treats it as a new connection and successfully negotiates a
high-speed link.

Zdenek, you check this explanation by commenting out these last two
lines at the end of hub_port_connect() in drivers/usb/core/hub.c:

if (hcd->driver->relinquish_port && !hub->hdev->parent)
hcd->driver->relinquish_port(hcd, port1);

That should prevent the connection from being handed over to the UHCI
companion, allowing the device to operate at high speed.



Hi

Yep - seems this helped - I've dropped revert and commented those 2 lines
and I've used the very same kernel - and speed was all good:

usb 2-2: new high-speed USB device number 2 using ehci-pci
usb 2-2: new high-speed USB device number 3 using ehci-pci
usb 2-2: New USB device found, idVendor=1058, idProduct=10a8
usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3


So while I'm not sure if this is final fix for USB - this solution surely 
solved my WD Element disk attachment issue.


Regards

Zdenek

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

[Zdenek Kabelac]

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 entirely correctly, it wouldn't do that.

We could continue futzing around with hardware and driver tests for a
long time.  But there may be a shortcut: If you have a USB hub, you
could try attaching the drive through it.  It's entirely possible that
this will fix the problem.

If not, you'll have to start doing some very detailed tests.  As a
start, you can enable debugging for the usbcore and ehci_hcd drivers
immediately before the test:

echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module ehci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
dmesg -C

Then after the test, see what shows up in the dmesg output.  And again,
we'll want to do a comparison.  In fact, 4.12 with and without the
commit you identified would make a better comparison than 4.12 vs. 4.8.




Hi


So here we go with traces - made with freshly compiled recent 4.13-rc2.
OK trace is with revert patch applied.
BAD trace is the one with it (essentially vaniala master).

Trace also has KOBJECT debugging enabled - I think difference is
nicely visible between them - but I've no explanation for it.

Both traces start with cable detach followed with attachment.

Regards

Zdenek
[  147.268628] hub 2-0:1.0: state 7 ports 6 chg  evt 0004
[  147.268768] ehci-pci :00:1d.7: GetStatus port:2 status 001002 0  ACK 
POWER sig=se0 CSC
[  147.268969] usb usb2-port2: status 0100, change 0001, 12 Mb/s
[  147.269076] usb 2-2: USB disconnect, device number 2
[  147.269168] usb 2-2: unregistering device
[  147.269244] usb 2-2: unregistering interface 2-2:1.0
[  147.269451] kobject: 'ep_8b' (88012fd60020): kobject_uevent_env
[  147.269558] kobject: 'ep_8b' (88012fd60020): kobject_uevent_env: filter 
function caused the event to drop!
[  147.269724] kobject: 'ep_8b' (88012fd60020): kobject_cleanup, parent 
  (null)
[  147.269853] kobject: 'ep_8b' (88012fd60020): calling ktype release
[  147.269966] kobject: 'ep_8b': free name
[  147.270176] kobject: 'ep_0a' (88012f440020): kobject_uevent_env
[  147.270286] kobject: 'ep_0a' (88012f440020): kobject_uevent_env: filter 
function caused the event to drop!
[  147.270452] kobject: 'ep_0a' (88012f440020): kobject_cleanup, parent 
  (null)
[  147.270582] kobject: 'ep_0a' (88012f440020): calling ktype release
[  147.270693] kobject: 'ep_0a': free name
[  147.271144] kobject: '5:0:0:0' (88012f448010): kobject_uevent_env
[  147.271269] kobject: '5:0:0:0' (88012f448010): fill_kobj_path: path = 
'/devices/pci:00/:00:1d.7/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/bsg/5:0:0:0'
[  147.271552] kobject: 'bsg' (88012f6dede0): kobject_cleanup, parent 
88012f4d3288
[  147.271686] kobject: 'bsg' (88012f6dede0): auto cleanup kobject_del
[  147.271798] kobject: 'bsg' (88012f6dede0): calling ktype release
[  147.271906] kobject: 'bsg': free name
[  147.271975] kobject: '5:0:0:0' (88012f448010): kobject_cleanup, parent   
(null)
[  147.272108] kobject: '5:0:0:0' (88012f448010): calling ktype release
[  147.27] kobject: '5:0:0:0': free name
[  147.272516] kobject: 'sg2' (88012f448810): kobject_uevent_env
[  147.272626] kobject: 'sg2' (88012f448810): fill_kobj_path: path = 
'/devices/pci:00/:00:1d.7/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/scsi_generic/sg2'
[  147.272887] kobject: 'scsi_generic' (88012f6dec60): kobject_cleanup, 
parent 88012f4d3288
[  147.273031] kobject: 'scsi_generic' (88012f6dec60): auto cleanup 
kobject_del
[  147.273159] kobject: 'scsi_generic' (88012f6dec60): calling ktype release
[  147.273275] kobject: 'scsi_generic': free name
[  147.273424] kobject: 'sg2' (88012f448810): kobject_cleanup, parent   
(null)
[  147.273555] kobject: 'sg2' (88012f448810): calling ktype release
[  147.273667] kobject: 'sg2': free name
[  147.273741] kobject: '(null)' (88013559ad80): kobject_cleanup, parent
   (null)
[  147.273877] kobject: '(null)' (88013559ad80): calling ktype release
[  147.273993] kobject: '(null)' (88012f4490b0): kobject_cleanup, parent
   (null)
[  147.274128] kobject: '(null)' (88012f4490b0): calling ktype release
[  147.274261] kobject: '5:0:0:0' (88012f4d3738): kobject_uevent_env
[  147.274377] kobject: '5:0:0:0' (88012f4d3738): fill_kobj_path: path = 
'/devices/pci:00/:00:1d.7/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/scsi_device/5:0:0:0'
[  147.274646] kobject: 'scsi_device' (88012ec95f60): kobject_cleanup, 
parent 88012f4d3288
[  147.274786] kobject: 'scsi_device' (88012ec95f60): auto cleanup 
kobject_del
[  147.274907] kobject: 'scsi_device' (88012ec95f60): calling

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

[Zdenek Kabelac]

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 entirely correctly, it wouldn't do that.

We could continue futzing around with hardware and driver tests for a
long time.  But there may be a shortcut: If you have a USB hub, you
could try attaching the drive through it.  It's entirely possible that
this will fix the problem.

If not, you'll have to start doing some very detailed tests.  As a
start, you can enable debugging for the usbcore and ehci_hcd drivers
immediately before the test:

echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module ehci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
dmesg -C

Then after the test, see what shows up in the dmesg output.  And again,
we'll want to do a comparison.  In fact, 4.12 with and without the
commit you identified would make a better comparison than 4.12 vs. 4.8.




Hi


So here we go with traces - made with freshly compiled recent 4.13-rc2.
OK trace is with revert patch applied.
BAD trace is the one with it (essentially vaniala master).

Trace also has KOBJECT debugging enabled - I think difference is
nicely visible between them - but I've no explanation for it.

Both traces start with cable detach followed with attachment.

Regards

Zdenek
[  147.268628] hub 2-0:1.0: state 7 ports 6 chg  evt 0004
[  147.268768] ehci-pci :00:1d.7: GetStatus port:2 status 001002 0  ACK 
POWER sig=se0 CSC
[  147.268969] usb usb2-port2: status 0100, change 0001, 12 Mb/s
[  147.269076] usb 2-2: USB disconnect, device number 2
[  147.269168] usb 2-2: unregistering device
[  147.269244] usb 2-2: unregistering interface 2-2:1.0
[  147.269451] kobject: 'ep_8b' (88012fd60020): kobject_uevent_env
[  147.269558] kobject: 'ep_8b' (88012fd60020): kobject_uevent_env: filter 
function caused the event to drop!
[  147.269724] kobject: 'ep_8b' (88012fd60020): kobject_cleanup, parent 
  (null)
[  147.269853] kobject: 'ep_8b' (88012fd60020): calling ktype release
[  147.269966] kobject: 'ep_8b': free name
[  147.270176] kobject: 'ep_0a' (88012f440020): kobject_uevent_env
[  147.270286] kobject: 'ep_0a' (88012f440020): kobject_uevent_env: filter 
function caused the event to drop!
[  147.270452] kobject: 'ep_0a' (88012f440020): kobject_cleanup, parent 
  (null)
[  147.270582] kobject: 'ep_0a' (88012f440020): calling ktype release
[  147.270693] kobject: 'ep_0a': free name
[  147.271144] kobject: '5:0:0:0' (88012f448010): kobject_uevent_env
[  147.271269] kobject: '5:0:0:0' (88012f448010): fill_kobj_path: path = 
'/devices/pci:00/:00:1d.7/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/bsg/5:0:0:0'
[  147.271552] kobject: 'bsg' (88012f6dede0): kobject_cleanup, parent 
88012f4d3288
[  147.271686] kobject: 'bsg' (88012f6dede0): auto cleanup kobject_del
[  147.271798] kobject: 'bsg' (88012f6dede0): calling ktype release
[  147.271906] kobject: 'bsg': free name
[  147.271975] kobject: '5:0:0:0' (88012f448010): kobject_cleanup, parent   
(null)
[  147.272108] kobject: '5:0:0:0' (88012f448010): calling ktype release
[  147.27] kobject: '5:0:0:0': free name
[  147.272516] kobject: 'sg2' (88012f448810): kobject_uevent_env
[  147.272626] kobject: 'sg2' (88012f448810): fill_kobj_path: path = 
'/devices/pci:00/:00:1d.7/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/scsi_generic/sg2'
[  147.272887] kobject: 'scsi_generic' (88012f6dec60): kobject_cleanup, 
parent 88012f4d3288
[  147.273031] kobject: 'scsi_generic' (88012f6dec60): auto cleanup 
kobject_del
[  147.273159] kobject: 'scsi_generic' (88012f6dec60): calling ktype release
[  147.273275] kobject: 'scsi_generic': free name
[  147.273424] kobject: 'sg2' (88012f448810): kobject_cleanup, parent   
(null)
[  147.273555] kobject: 'sg2' (88012f448810): calling ktype release
[  147.273667] kobject: 'sg2': free name
[  147.273741] kobject: '(null)' (88013559ad80): kobject_cleanup, parent
   (null)
[  147.273877] kobject: '(null)' (88013559ad80): calling ktype release
[  147.273993] kobject: '(null)' (88012f4490b0): kobject_cleanup, parent
   (null)
[  147.274128] kobject: '(null)' (88012f4490b0): calling ktype release
[  147.274261] kobject: '5:0:0:0' (88012f4d3738): kobject_uevent_env
[  147.274377] kobject: '5:0:0:0' (88012f4d3738): fill_kobj_path: path = 
'/devices/pci:00/:00:1d.7/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/scsi_device/5:0:0:0'
[  147.274646] kobject: 'scsi_device' (88012ec95f60): kobject_cleanup, 
parent 88012f4d3288
[  147.274786] kobject: 'scsi_device' (88012ec95f60): auto cleanup 
kobject_del
[  147.274907] kobject: 'scsi_device' (88012ec95f60): calling

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

[Zdenek Kabelac]

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 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')
no other usb device has been touch so should not hopefully interfere here.

Trace is from 4.12 kernel - so it has reported  "not running at top speed"


Can you collect an equivalent trace under 4.8?

Alan Stern



Hi


Sure - no pb.

Just attached & detached  USB disk in this trace


This is really peculiar.  The only difference is that the 4.12 trace
shows an extra 250 ms delay (including two extra Get-Port-Status


Most likely we are now catching the long reset timeout. HUB_LONG_RESET_TIME
is 200 ms. It looks like the code is catching exactly the condition
addressed in my patch, ie USB_PORT_STAT_RESET is cleared but
USB_PORT_STAT_CONNECTION is not yet set. hub_port_wait_reset() will
now wait for USB_PORT_STAT_CONNECTION, which it didn't do before.


requests) compared to the 4.8 trace.  I honestly can't tell what could
be causing the switch from high speed to full speed, or why it would
happen in one case but not the other.



We talked about this today. What is causing the switch from high speed to
full speed ? Is this triggered by the kernel, or by the USB controller ?


A little of both.  When a reset completes, if the device does not
follow the high-speed chirp protocol, the EHCI status registers show
that the port is not enabled.  When the driver sees that, it sets a bit
that causes the connection to be moved over from the high-speed EHCI
controller to the companion full-speed UHCI controller.  The code that
does this is in check_reset_complete() in ehci-hub.c.



Well I do have 4.13-rc1 kernel - where the only difference is the revert
of mentioned patched - so I can provide probably traces from this one if that
helps anything.

What is not quite clear to me - why T440 works.

Could this be in some way related to the fact that T61 is USB2 only old lenovo 
machine while T440 works with  USB3 (new SuperSpeed USB device number...)


So maybe there is some time-sensitive logic - where WD Elements
decides to be USB2 or USB3 device ???


Zdenek

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

[Zdenek Kabelac]

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 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')
no other usb device has been touch so should not hopefully interfere here.

Trace is from 4.12 kernel - so it has reported  "not running at top speed"


Can you collect an equivalent trace under 4.8?

Alan Stern



Hi


Sure - no pb.

Just attached & detached  USB disk in this trace


This is really peculiar.  The only difference is that the 4.12 trace
shows an extra 250 ms delay (including two extra Get-Port-Status


Most likely we are now catching the long reset timeout. HUB_LONG_RESET_TIME
is 200 ms. It looks like the code is catching exactly the condition
addressed in my patch, ie USB_PORT_STAT_RESET is cleared but
USB_PORT_STAT_CONNECTION is not yet set. hub_port_wait_reset() will
now wait for USB_PORT_STAT_CONNECTION, which it didn't do before.


requests) compared to the 4.8 trace.  I honestly can't tell what could
be causing the switch from high speed to full speed, or why it would
happen in one case but not the other.



We talked about this today. What is causing the switch from high speed to
full speed ? Is this triggered by the kernel, or by the USB controller ?


A little of both.  When a reset completes, if the device does not
follow the high-speed chirp protocol, the EHCI status registers show
that the port is not enabled.  When the driver sees that, it sets a bit
that causes the connection to be moved over from the high-speed EHCI
controller to the companion full-speed UHCI controller.  The code that
does this is in check_reset_complete() in ehci-hub.c.



Well I do have 4.13-rc1 kernel - where the only difference is the revert
of mentioned patched - so I can provide probably traces from this one if that
helps anything.

What is not quite clear to me - why T440 works.

Could this be in some way related to the fact that T61 is USB2 only old lenovo 
machine while T440 works with  USB3 (new SuperSpeed USB device number...)


So maybe there is some time-sensitive logic - where WD Elements
decides to be USB2 or USB3 device ???


Zdenek

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

[Zdenek Kabelac]

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')
no other usb device has been touch so should not hopefully interfere here.

Trace is from 4.12 kernel - so it has reported  "not running at top speed"


Can you collect an equivalent trace under 4.8?

Alan Stern



Hi


Sure - no pb.

Just attached & detached  USB disk in this trace

Zdenek






usmon4.8
Description: Unix manual page

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

[Zdenek Kabelac]

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')
no other usb device has been touch so should not hopefully interfere here.

Trace is from 4.12 kernel - so it has reported  "not running at top speed"


Can you collect an equivalent trace under 4.8?

Alan Stern



Hi


Sure - no pb.

Just attached & detached  USB disk in this trace

Zdenek






usmon4.8
Description: Unix manual page

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

[Zdenek Kabelac]

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 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) when the Linux kernel is fully 
rebooted (so

disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).

However when >4.9 kernel is running and disk is just attached it's very 
slow.


I've played a bisect game - and the clean result has been:

22547c4cc4fe20698a6a85a55b8788859134b8e4

When I just revert this patch with 4.13-rc1 - it's again running with full
speed even when disk is attached (thus no reboot is needed for full speed).


So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have
some unpleasant side-effect on regular USB devices.

So what else is needed to get this properly working ?
(assuming plain revert of  22547c4cc4fe20698 is unwanted).

What more info can I provide to get this storage 'normally' usable without
rebooting the machine.


Please post the dmesg logs showing what happens when the disk is
first attached and operates slowly, and what happens when the disk is
attached following a reboot and operates normally.


So I'm attaching kernel traces from  kernel 4.8  & 4.12 from T61.

Both are from full boot (all kernel: messages)

In both cases - boot was with USB WD disk attached -
then I've detached USB disk and reattached again.

On 4.8 this had normal speed all the time
On 4.12 after reattach -> slow speed.

I should also add that on Lenovo T440s - there seems to be NO slowdown
when this WD Element drive is attached it works normally all the time.

So it could be probably related to USB chipset on T61 ??

For completeness I'm also attaching boot kernel trace from T440s where USB
disk is just attached and works with normal speed.


The log shows that the drive is reconnecting at full speed (12 Mb/s)
instead of high speed (480 Mb/s), which is why the communication
becomes so slow.

I think there's some weird timing issue going on.  Hard to tell from
just the log, though.

Please collect a usbmon trace, starting from just before the unplug and
ending after the drive has reconnected at the slower speed.
Instructions are in Documentation/usb/usbmon.txt.  Use bus number 0 for
the trace, so we can see what's going on with both the high-speed and
full-speed connections.  And collect traces for both 4.8 and 4.12.

And try to avoid using any other USB devices during the test, to
minimize the amount of excess information recorded in the trace.




Ahh nice spot - I've not been checking that message in detail - so maybe I 
should actually run another bisect - where:


"new high-speed USB device number..."

turned into:

"new full-speed USB device number 2 using uhci_hcd"
"not running at top speed; connect to a high speed hub"

As I've just ended with a commit that made 'slow-speed' reality
but I need to find the commit having impact on connecting message



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')
no other usb device has been touch so should not hopefully interfere here.

Trace is from 4.12 kernel - so it has reported  "not running at top speed"

Zdenek

9165b35be900 297885991 C Ii:1:001:1 0:2048 1 = 08
9165b35be900 297886011 S Ii:1:001:1 -115:2048 4 <
916594dbdcc0 297886030 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297886052 C Ci:1:001:0 0 4 = 01050100
916594dbdcc0 297886066 S Co:1:001:0 s 23 01 0010 0003  0
916594dbdcc0 297886082 C Co:1:001:0 0 0
916594dbdcc0 297886089 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297886096 C Ci:1:001:0 0 4 = 0105
916594dbdcc0 297913101 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297913121 C Ci:1:001:0 0 4 = 0105
9165b35be900 297922410 C Ii:1:001:1 0:2048 1 = 08
9165b35be900 297922435 S Ii:1:001:1 -115:2048 4 <
916594dbdcc0 297940131 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297940157 C Ci:1:001:0 0 4 = 00010100
916594dbdcc0 297940173 S Co:1:001:0 s 23 01 0010 0003  0
916594dbdcc0 297940197 C Co:1:001:0 0 0
916594dbdcc0 297967042 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297967065 C Ci:1:001:0 0 4 = 0001
916594dbdcc0 297994085 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297994102 C Ci:1:001:0 0 4 = 0001
916594dbdcc0 298021143 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 298021162 C Ci:1:00

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

[Zdenek Kabelac]

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 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) when the Linux kernel is fully 
rebooted (so

disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).

However when >4.9 kernel is running and disk is just attached it's very 
slow.


I've played a bisect game - and the clean result has been:

22547c4cc4fe20698a6a85a55b8788859134b8e4

When I just revert this patch with 4.13-rc1 - it's again running with full
speed even when disk is attached (thus no reboot is needed for full speed).


So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have
some unpleasant side-effect on regular USB devices.

So what else is needed to get this properly working ?
(assuming plain revert of  22547c4cc4fe20698 is unwanted).

What more info can I provide to get this storage 'normally' usable without
rebooting the machine.


Please post the dmesg logs showing what happens when the disk is
first attached and operates slowly, and what happens when the disk is
attached following a reboot and operates normally.


So I'm attaching kernel traces from  kernel 4.8  & 4.12 from T61.

Both are from full boot (all kernel: messages)

In both cases - boot was with USB WD disk attached -
then I've detached USB disk and reattached again.

On 4.8 this had normal speed all the time
On 4.12 after reattach -> slow speed.

I should also add that on Lenovo T440s - there seems to be NO slowdown
when this WD Element drive is attached it works normally all the time.

So it could be probably related to USB chipset on T61 ??

For completeness I'm also attaching boot kernel trace from T440s where USB
disk is just attached and works with normal speed.


The log shows that the drive is reconnecting at full speed (12 Mb/s)
instead of high speed (480 Mb/s), which is why the communication
becomes so slow.

I think there's some weird timing issue going on.  Hard to tell from
just the log, though.

Please collect a usbmon trace, starting from just before the unplug and
ending after the drive has reconnected at the slower speed.
Instructions are in Documentation/usb/usbmon.txt.  Use bus number 0 for
the trace, so we can see what's going on with both the high-speed and
full-speed connections.  And collect traces for both 4.8 and 4.12.

And try to avoid using any other USB devices during the test, to
minimize the amount of excess information recorded in the trace.




Ahh nice spot - I've not been checking that message in detail - so maybe I 
should actually run another bisect - where:


"new high-speed USB device number..."

turned into:

"new full-speed USB device number 2 using uhci_hcd"
"not running at top speed; connect to a high speed hub"

As I've just ended with a commit that made 'slow-speed' reality
but I need to find the commit having impact on connecting message



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')
no other usb device has been touch so should not hopefully interfere here.

Trace is from 4.12 kernel - so it has reported  "not running at top speed"

Zdenek

9165b35be900 297885991 C Ii:1:001:1 0:2048 1 = 08
9165b35be900 297886011 S Ii:1:001:1 -115:2048 4 <
916594dbdcc0 297886030 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297886052 C Ci:1:001:0 0 4 = 01050100
916594dbdcc0 297886066 S Co:1:001:0 s 23 01 0010 0003  0
916594dbdcc0 297886082 C Co:1:001:0 0 0
916594dbdcc0 297886089 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297886096 C Ci:1:001:0 0 4 = 0105
916594dbdcc0 297913101 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297913121 C Ci:1:001:0 0 4 = 0105
9165b35be900 297922410 C Ii:1:001:1 0:2048 1 = 08
9165b35be900 297922435 S Ii:1:001:1 -115:2048 4 <
916594dbdcc0 297940131 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297940157 C Ci:1:001:0 0 4 = 00010100
916594dbdcc0 297940173 S Co:1:001:0 s 23 01 0010 0003  0
916594dbdcc0 297940197 C Co:1:001:0 0 0
916594dbdcc0 297967042 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297967065 C Ci:1:001:0 0 4 = 0001
916594dbdcc0 297994085 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 297994102 C Ci:1:001:0 0 4 = 0001
916594dbdcc0 298021143 S Ci:1:001:0 s a3 00  0003 0004 4 <
916594dbdcc0 298021162 C Ci:1:00

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

[Zdenek Kabelac]

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 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) when the Linux kernel is fully rebooted (so
disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).

However when >4.9 kernel is running and disk is just attached it's very slow.

I've played a bisect game - and the clean result has been:

22547c4cc4fe20698a6a85a55b8788859134b8e4

When I just revert this patch with 4.13-rc1 - it's again running with full
speed even when disk is attached (thus no reboot is needed for full speed).


So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have
some unpleasant side-effect on regular USB devices.

So what else is needed to get this properly working ?
(assuming plain revert of  22547c4cc4fe20698 is unwanted).

What more info can I provide to get this storage 'normally' usable without
rebooting the machine.


Please post the dmesg logs showing what happens when the disk is
first attached and operates slowly, and what happens when the disk is
attached following a reboot and operates normally.


So I'm attaching kernel traces from  kernel 4.8  & 4.12 from T61.

Both are from full boot (all kernel: messages)

In both cases - boot was with USB WD disk attached -
then I've detached USB disk and reattached again.

On 4.8 this had normal speed all the time
On 4.12 after reattach -> slow speed.

I should also add that on Lenovo T440s - there seems to be NO slowdown
when this WD Element drive is attached it works normally all the time.

So it could be probably related to USB chipset on T61 ??

For completeness I'm also attaching boot kernel trace from T440s where USB
disk is just attached and works with normal speed.


The log shows that the drive is reconnecting at full speed (12 Mb/s)
instead of high speed (480 Mb/s), which is why the communication
becomes so slow.

I think there's some weird timing issue going on.  Hard to tell from
just the log, though.

Please collect a usbmon trace, starting from just before the unplug and
ending after the drive has reconnected at the slower speed.
Instructions are in Documentation/usb/usbmon.txt.  Use bus number 0 for
the trace, so we can see what's going on with both the high-speed and
full-speed connections.  And collect traces for both 4.8 and 4.12.

And try to avoid using any other USB devices during the test, to
minimize the amount of excess information recorded in the trace.




Ahh nice spot - I've not been checking that message in detail - so maybe I 
should actually run another bisect - where:


"new high-speed USB device number..."

turned into:

"new full-speed USB device number 2 using uhci_hcd"
"not running at top speed; connect to a high speed hub"

As I've just ended with a commit that made 'slow-speed' reality
but I need to find the commit having impact on connecting message

Zdenek

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

[Zdenek Kabelac]

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 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) when the Linux kernel is fully rebooted (so
disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).

However when >4.9 kernel is running and disk is just attached it's very slow.

I've played a bisect game - and the clean result has been:

22547c4cc4fe20698a6a85a55b8788859134b8e4

When I just revert this patch with 4.13-rc1 - it's again running with full
speed even when disk is attached (thus no reboot is needed for full speed).


So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have
some unpleasant side-effect on regular USB devices.

So what else is needed to get this properly working ?
(assuming plain revert of  22547c4cc4fe20698 is unwanted).

What more info can I provide to get this storage 'normally' usable without
rebooting the machine.


Please post the dmesg logs showing what happens when the disk is
first attached and operates slowly, and what happens when the disk is
attached following a reboot and operates normally.


So I'm attaching kernel traces from  kernel 4.8  & 4.12 from T61.

Both are from full boot (all kernel: messages)

In both cases - boot was with USB WD disk attached -
then I've detached USB disk and reattached again.

On 4.8 this had normal speed all the time
On 4.12 after reattach -> slow speed.

I should also add that on Lenovo T440s - there seems to be NO slowdown
when this WD Element drive is attached it works normally all the time.

So it could be probably related to USB chipset on T61 ??

For completeness I'm also attaching boot kernel trace from T440s where USB
disk is just attached and works with normal speed.


The log shows that the drive is reconnecting at full speed (12 Mb/s)
instead of high speed (480 Mb/s), which is why the communication
becomes so slow.

I think there's some weird timing issue going on.  Hard to tell from
just the log, though.

Please collect a usbmon trace, starting from just before the unplug and
ending after the drive has reconnected at the slower speed.
Instructions are in Documentation/usb/usbmon.txt.  Use bus number 0 for
the trace, so we can see what's going on with both the high-speed and
full-speed connections.  And collect traces for both 4.8 and 4.12.

And try to avoid using any other USB devices during the test, to
minimize the amount of excess information recorded in the trace.




Ahh nice spot - I've not been checking that message in detail - so maybe I 
should actually run another bisect - where:


"new high-speed USB device number..."

turned into:

"new full-speed USB device number 2 using uhci_hcd"
"not running at top speed; connect to a high speed hub"

As I've just ended with a commit that made 'slow-speed' reality
but I need to find the commit having impact on connecting message

Zdenek

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

[Zdenek Kabelac]

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 via cable it has very low speed
(less then 1MB/s).

It can run at full speed (>22MB/s) when the Linux kernel is fully rebooted (so
disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).

However when >4.9 kernel is running and disk is just attached it's very slow.

I've played a bisect game - and the clean result has been:

22547c4cc4fe20698a6a85a55b8788859134b8e4

When I just revert this patch with 4.13-rc1 - it's again running with full
speed even when disk is attached (thus no reboot is needed for full speed).


So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have
some unpleasant side-effect on regular USB devices.

So what else is needed to get this properly working ?
(assuming plain revert of  22547c4cc4fe20698 is unwanted).

What more info can I provide to get this storage 'normally' usable without
rebooting the machine.


Please post the dmesg logs showing what happens when the disk is
first attached and operates slowly, and what happens when the disk is
attached following a reboot and operates normally.


So I'm attaching kernel traces from  kernel 4.8  & 4.12 from T61.

Both are from full boot (all kernel: messages)

In both cases - boot was with USB WD disk attached -
then I've detached USB disk and reattached again.

On 4.8 this had normal speed all the time
On 4.12 after reattach -> slow speed.

I should also add that on Lenovo T440s - there seems to be NO slowdown
when this WD Element drive is attached it works normally all the time.

So it could be probably related to USB chipset on T61 ??

For completeness I'm also attaching boot kernel trace from T440s where USB 
disk is just attached and works with normal speed.



Zdenek


k4.8
Description: Unix manual page
06:18 Linux version 4.12.0-1.fc27.x86_64 
(mockbu...@bkernel01.phx2.fedoraproject.org) (gcc version 7.1.1 20170526 (Red 
Hat 7.1.1-2) (GCC) ) #1 SMP Mon Jul 3 15:45:36 UTC 2017
06:18 Command line: BOOT_IMAGE=/vmlinuz-4.12.0-1.fc27.x86_64 root=/dev/sda2 ro 
selinux=0 kmemleak=off lockdep.prove_locking=0 lockdep.lock_stat=0 
systemd.log_level=info systemd.log_target=kmsg acpi_backlight=vendor 
log_buf_len=2M quiet
06:18 x86/fpu: x87 FPU will use FXSAVE
06:18 e820: BIOS-provided physical RAM map:
06:18 BIOS-e820: [mem 0x-0x0009d7ff] usable
06:18 BIOS-e820: [mem 0x0009d800-0x0009] reserved
06:18 BIOS-e820: [mem 0x000e-0x000f] reserved
06:18 BIOS-e820: [mem 0x0010-0xbf6a] usable
06:18 BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
06:18 BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
06:18 BIOS-e820: [mem 0xbf70-0xbfff] reserved
06:18 BIOS-e820: [mem 0xf000-0xf3ff] reserved
06:18 BIOS-e820: [mem 0xfec0-0xfec0] reserved
06:18 BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
06:18 BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
06:18 BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
06:18 BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
06:18 BIOS-e820: [mem 0xff00-0x] reserved
06:18 BIOS-e820: [mem 0x0001-0x00013bff] usable
06:18 NX (Execute Disable) protection: active
06:18 SMBIOS 2.4 present.
06:18 DMI: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
06:18 tsc: Fast TSC calibration failed
06:18 tsc: Using PIT calibration value
06:18 e820: last_pfn = 0x13c000 max_arch_pfn = 0x4
06:18 x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
06:18 e820: last_pfn = 0xbf6b0 max_arch_pfn = 0x4
06:18 found SMP MP-table at [mem 0x000f68f0-0x000f68ff] mapped at 
[8919400f68f0]
06:18 log_buf_len: 2097152 bytes
06:18 early log buf free: 258320(98%)
06:18 RAMDISK: [mem 0x3634d000-0x3719efff]
06:18 ACPI: Early table checksum verification disabled
06:18 ACPI: RSDP 0x000F68C0 24 (v02 LENOVO)
06:18 ACPI: XSDT 0xBF6BB496 9C (v01 LENOVO TP-7U2290  LTP 
)
06:18 ACPI: FACP 0xBF6BB600 F4 (v03 LENOVO TP-7U2290 LNVO 
0001)
06:18 ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 
(20170303/tbfadt-603)
06:18 ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid Address 
but zero Length: 0x102C/0x0 (20170303/tbfadt-658)
06:18 ACPI: DSDT 0xBF6BBA1D 01003C (v01 LENOVO TP-7U2290 MSFT 
0300)
06:18 ACPI: FACS 0xBF6E4000 40
06:18 ACPI: FACS 0xBF6E4000 40
06:18 ACPI: SSDT 0xBF6BB7B4 000269 (v01 LENOVO TP-7U2290 MSFT 
0300

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

[Zdenek Kabelac]

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 via cable it has very low speed
(less then 1MB/s).

It can run at full speed (>22MB/s) when the Linux kernel is fully rebooted (so
disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).

However when >4.9 kernel is running and disk is just attached it's very slow.

I've played a bisect game - and the clean result has been:

22547c4cc4fe20698a6a85a55b8788859134b8e4

When I just revert this patch with 4.13-rc1 - it's again running with full
speed even when disk is attached (thus no reboot is needed for full speed).


So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have
some unpleasant side-effect on regular USB devices.

So what else is needed to get this properly working ?
(assuming plain revert of  22547c4cc4fe20698 is unwanted).

What more info can I provide to get this storage 'normally' usable without
rebooting the machine.


Please post the dmesg logs showing what happens when the disk is
first attached and operates slowly, and what happens when the disk is
attached following a reboot and operates normally.


So I'm attaching kernel traces from  kernel 4.8  & 4.12 from T61.

Both are from full boot (all kernel: messages)

In both cases - boot was with USB WD disk attached -
then I've detached USB disk and reattached again.

On 4.8 this had normal speed all the time
On 4.12 after reattach -> slow speed.

I should also add that on Lenovo T440s - there seems to be NO slowdown
when this WD Element drive is attached it works normally all the time.

So it could be probably related to USB chipset on T61 ??

For completeness I'm also attaching boot kernel trace from T440s where USB 
disk is just attached and works with normal speed.



Zdenek


k4.8
Description: Unix manual page
06:18 Linux version 4.12.0-1.fc27.x86_64 
(mockbu...@bkernel01.phx2.fedoraproject.org) (gcc version 7.1.1 20170526 (Red 
Hat 7.1.1-2) (GCC) ) #1 SMP Mon Jul 3 15:45:36 UTC 2017
06:18 Command line: BOOT_IMAGE=/vmlinuz-4.12.0-1.fc27.x86_64 root=/dev/sda2 ro 
selinux=0 kmemleak=off lockdep.prove_locking=0 lockdep.lock_stat=0 
systemd.log_level=info systemd.log_target=kmsg acpi_backlight=vendor 
log_buf_len=2M quiet
06:18 x86/fpu: x87 FPU will use FXSAVE
06:18 e820: BIOS-provided physical RAM map:
06:18 BIOS-e820: [mem 0x-0x0009d7ff] usable
06:18 BIOS-e820: [mem 0x0009d800-0x0009] reserved
06:18 BIOS-e820: [mem 0x000e-0x000f] reserved
06:18 BIOS-e820: [mem 0x0010-0xbf6a] usable
06:18 BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
06:18 BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
06:18 BIOS-e820: [mem 0xbf70-0xbfff] reserved
06:18 BIOS-e820: [mem 0xf000-0xf3ff] reserved
06:18 BIOS-e820: [mem 0xfec0-0xfec0] reserved
06:18 BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
06:18 BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
06:18 BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
06:18 BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
06:18 BIOS-e820: [mem 0xff00-0x] reserved
06:18 BIOS-e820: [mem 0x0001-0x00013bff] usable
06:18 NX (Execute Disable) protection: active
06:18 SMBIOS 2.4 present.
06:18 DMI: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
06:18 tsc: Fast TSC calibration failed
06:18 tsc: Using PIT calibration value
06:18 e820: last_pfn = 0x13c000 max_arch_pfn = 0x4
06:18 x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
06:18 e820: last_pfn = 0xbf6b0 max_arch_pfn = 0x4
06:18 found SMP MP-table at [mem 0x000f68f0-0x000f68ff] mapped at 
[8919400f68f0]
06:18 log_buf_len: 2097152 bytes
06:18 early log buf free: 258320(98%)
06:18 RAMDISK: [mem 0x3634d000-0x3719efff]
06:18 ACPI: Early table checksum verification disabled
06:18 ACPI: RSDP 0x000F68C0 24 (v02 LENOVO)
06:18 ACPI: XSDT 0xBF6BB496 9C (v01 LENOVO TP-7U2290  LTP 
)
06:18 ACPI: FACP 0xBF6BB600 F4 (v03 LENOVO TP-7U2290 LNVO 
0001)
06:18 ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 
(20170303/tbfadt-603)
06:18 ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid Address 
but zero Length: 0x102C/0x0 (20170303/tbfadt-658)
06:18 ACPI: DSDT 0xBF6BBA1D 01003C (v01 LENOVO TP-7U2290 MSFT 
0300)
06:18 ACPI: FACS 0xBF6E4000 40
06:18 ACPI: FACS 0xBF6E4000 40
06:18 ACPI: SSDT 0xBF6BB7B4 000269 (v01 LENOVO TP-7U2290 MSFT 
0300

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

[Zdenek Kabelac]

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) when the Linux kernel is fully rebooted (so 
disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).


However when >4.9 kernel is running and disk is just attached it's very slow.

I've played a bisect game - and the clean result has been:

22547c4cc4fe20698a6a85a55b8788859134b8e4

When I just revert this patch with 4.13-rc1 - it's again running with full 
speed even when disk is attached (thus no reboot is needed for full speed).



So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have 
some unpleasant side-effect on regular USB devices.


So what else is needed to get this properly working ?
(assuming plain revert of  22547c4cc4fe20698 is unwanted).

What more info can I provide to get this storage 'normally' usable without 
rebooting the machine.


Regards

Zdenek

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

[Zdenek Kabelac]

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) when the Linux kernel is fully rebooted (so 
disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).


However when >4.9 kernel is running and disk is just attached it's very slow.

I've played a bisect game - and the clean result has been:

22547c4cc4fe20698a6a85a55b8788859134b8e4

When I just revert this patch with 4.13-rc1 - it's again running with full 
speed even when disk is attached (thus no reboot is needed for full speed).



So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have 
some unpleasant side-effect on regular USB devices.


So what else is needed to get this properly working ?
(assuming plain revert of  22547c4cc4fe20698 is unwanted).

What more info can I provide to get this storage 'normally' usable without 
rebooting the machine.


Regards

Zdenek

BUG: stack guard page was hit tpm_tis_send_data

[Zdenek Kabelac]

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 1.1 - Copyright (c) 
2015 FUJITSU LIMITED

wmi: Mapper loaded
BUG: stack guard page was hit at b62000ae (stack is 
b62000adc000..b62000ad)

kernel stack overflow (page fault):  [#1] SMP
Modules linked in:
systemd[383]: systemd-backlight@backlight:intel_backlight.service: Executing: 
/usr/lib/systemd/systemd-backlight load backlight:intel_backlight

 snd
 wmi soundcore fjes rfkill parport_pc parport tpm_tis(+) tpm_tis_core tpm 
nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc sunrpc loop dm_multipath i915 
i2c_algo_bit drm_kms_helper drm sdhci_pci sdhci mmc_core serio_raw ata_generic 
yenta_socket pata_acpi video

CPU: 1 PID: 350 Comm: systemd-udevd Not tainted 4.9.0-0.rc1.git3.2.fc26.x86_64 
#1
Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
task: 936f73f057c0 task.stack: b62000adc000
RIP: 0010:[]  [] 
tpm_tcg_write_bytes+0x30/0x50 [tpm_tis]

RSP: :b62000adf678  EFLAGS: 00010282
RAX: ffef RBX: b62000ae0001 RCX: b62000adf83f
RDX: fff0 RSI: 0024 RDI: 
RBP: b62000adf698 R08: eea8a8a5 R09: 
R10:  R11: 936f76411dc0 R12: 0024
R13: b62000aef82f R14: 936f7b28 R15: b62000adf83e
FS:  7ffa019f1680() GS:936f7bb0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: b62000ae CR3: 0001350c CR4: 06e0
Stack:
 0001 936f745a8000 936f7b28 fff0
 b62000adf6f8 c0472d03 936f7b40 0015
 0015 c80042ee 6813cb59 936f745a8000
Call Trace:
 [] tpm_tis_send_data+0xd3/0x2b0 [tpm_tis_core]
 [] tpm_tis_send_main+0x3a/0x120 [tpm_tis_core]
 [] tpm_tis_send+0x46/0x130 [tpm_tis_core]
 [] tpm_transmit+0x73/0x260 [tpm]
 [] tpm_transmit_cmd+0x1f/0x70 [tpm]
 [] tpm_get_timeouts.part.1+0x1e6/0x400 [tpm]
 [] ? dev_vprintk_emit+0xbf/0x230
 [] ? dev_printk_emit+0x4e/0x70
 [] ? tpm2_probe+0x77/0xb0 [tpm]
 [] ? __dev_printk+0x3c/0x80
 [] ? _dev_info+0x6c/0x90
 [] tpm_get_timeouts+0x67/0x70 [tpm]
 [] tpm_tis_core_init+0x277/0xed0 [tpm_tis_core]
 [] tpm_tis_init+0x77/0x90 [tpm_tis]
 [] ? tpm_tis_plat_probe+0x100/0x100 [tpm_tis]
 [] tpm_tis_pnp_init+0xd5/0x196 [tpm_tis]
 [] pnp_device_probe+0x65/0xc0
 [] driver_probe_device+0x223/0x430
 [] __driver_attach+0xdf/0xf0
 [] ? driver_probe_device+0x430/0x430
 [] bus_for_each_dev+0x6c/0xc0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x170/0x270
 [] ? 0xc047d000
 [] driver_register+0x60/0xe0
 [] ? 0xc047d000
 [] pnp_register_driver+0x20/0x30
 [] init_tis+0xa1/0x1000 [tpm_tis]
 [] ? do_init_module+0x27/0x1ef
 [] ? vunmap_page_range+0x215/0x380
 [] do_one_initcall+0x50/0x180
 [] ? kmem_cache_alloc_trace+0x172/0x1b0
 [] ? do_init_module+0x27/0x1ef
 [] do_init_module+0x5f/0x1ef
 [] load_module+0x25b1/0x2980
 [] ? __symbol_put+0x60/0x60
 [] SYSC_init_module+0x173/0x190
 [] SyS_init_module+0xe/0x10
 [] do_syscall_64+0x67/0x180
 [] entry_SYSCALL64_slow_path+0x25/0x25
Code: 8d 42 ff 55 66 85 d2 0f b7 c0 48 89 e5 41 56 41 55 4c 8d 6c 01 01 41 54 
53 74 22 49 89 fe 48 89 cb 41 89 f4 48 83 c3 01 4c 89 e6 <0f> b6 7b ff 49 03 
76 50 e8 a3 cc f8 d2 49 39 dd 75 e7 5b 31 c0

RIP  [] tpm_tcg_write_bytes+0x30/0x50 [tpm_tis]
 RSP 
---[ end trace 974f468696d1d0af ]---

Regards

Zdenek

BUG: stack guard page was hit tpm_tis_send_data

[Zdenek Kabelac]

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 1.1 - Copyright (c) 
2015 FUJITSU LIMITED

wmi: Mapper loaded
BUG: stack guard page was hit at b62000ae (stack is 
b62000adc000..b62000ad)

kernel stack overflow (page fault):  [#1] SMP
Modules linked in:
systemd[383]: systemd-backlight@backlight:intel_backlight.service: Executing: 
/usr/lib/systemd/systemd-backlight load backlight:intel_backlight

 snd
 wmi soundcore fjes rfkill parport_pc parport tpm_tis(+) tpm_tis_core tpm 
nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc sunrpc loop dm_multipath i915 
i2c_algo_bit drm_kms_helper drm sdhci_pci sdhci mmc_core serio_raw ata_generic 
yenta_socket pata_acpi video

CPU: 1 PID: 350 Comm: systemd-udevd Not tainted 4.9.0-0.rc1.git3.2.fc26.x86_64 
#1
Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
task: 936f73f057c0 task.stack: b62000adc000
RIP: 0010:[]  [] 
tpm_tcg_write_bytes+0x30/0x50 [tpm_tis]

RSP: :b62000adf678  EFLAGS: 00010282
RAX: ffef RBX: b62000ae0001 RCX: b62000adf83f
RDX: fff0 RSI: 0024 RDI: 
RBP: b62000adf698 R08: eea8a8a5 R09: 
R10:  R11: 936f76411dc0 R12: 0024
R13: b62000aef82f R14: 936f7b28 R15: b62000adf83e
FS:  7ffa019f1680() GS:936f7bb0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: b62000ae CR3: 0001350c CR4: 06e0
Stack:
 0001 936f745a8000 936f7b28 fff0
 b62000adf6f8 c0472d03 936f7b40 0015
 0015 c80042ee 6813cb59 936f745a8000
Call Trace:
 [] tpm_tis_send_data+0xd3/0x2b0 [tpm_tis_core]
 [] tpm_tis_send_main+0x3a/0x120 [tpm_tis_core]
 [] tpm_tis_send+0x46/0x130 [tpm_tis_core]
 [] tpm_transmit+0x73/0x260 [tpm]
 [] tpm_transmit_cmd+0x1f/0x70 [tpm]
 [] tpm_get_timeouts.part.1+0x1e6/0x400 [tpm]
 [] ? dev_vprintk_emit+0xbf/0x230
 [] ? dev_printk_emit+0x4e/0x70
 [] ? tpm2_probe+0x77/0xb0 [tpm]
 [] ? __dev_printk+0x3c/0x80
 [] ? _dev_info+0x6c/0x90
 [] tpm_get_timeouts+0x67/0x70 [tpm]
 [] tpm_tis_core_init+0x277/0xed0 [tpm_tis_core]
 [] tpm_tis_init+0x77/0x90 [tpm_tis]
 [] ? tpm_tis_plat_probe+0x100/0x100 [tpm_tis]
 [] tpm_tis_pnp_init+0xd5/0x196 [tpm_tis]
 [] pnp_device_probe+0x65/0xc0
 [] driver_probe_device+0x223/0x430
 [] __driver_attach+0xdf/0xf0
 [] ? driver_probe_device+0x430/0x430
 [] bus_for_each_dev+0x6c/0xc0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x170/0x270
 [] ? 0xc047d000
 [] driver_register+0x60/0xe0
 [] ? 0xc047d000
 [] pnp_register_driver+0x20/0x30
 [] init_tis+0xa1/0x1000 [tpm_tis]
 [] ? do_init_module+0x27/0x1ef
 [] ? vunmap_page_range+0x215/0x380
 [] do_one_initcall+0x50/0x180
 [] ? kmem_cache_alloc_trace+0x172/0x1b0
 [] ? do_init_module+0x27/0x1ef
 [] do_init_module+0x5f/0x1ef
 [] load_module+0x25b1/0x2980
 [] ? __symbol_put+0x60/0x60
 [] SYSC_init_module+0x173/0x190
 [] SyS_init_module+0xe/0x10
 [] do_syscall_64+0x67/0x180
 [] entry_SYSCALL64_slow_path+0x25/0x25
Code: 8d 42 ff 55 66 85 d2 0f b7 c0 48 89 e5 41 56 41 55 4c 8d 6c 01 01 41 54 
53 74 22 49 89 fe 48 89 cb 41 89 f4 48 83 c3 01 4c 89 e6 <0f> b6 7b ff 49 03 
76 50 e8 a3 cc f8 d2 49 39 dd 75 e7 5b 31 c0

RIP  [] tpm_tcg_write_bytes+0x30/0x50 [tpm_tis]
 RSP 
---[ end trace 974f468696d1d0af ]---

Regards

Zdenek

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

[Zdenek Kabelac]

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 put request-based dm-crypt completely to one side and focus
just on the existing bio-based code.  Why is it slower and what can be
adjusted to improve this?



OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the
request based, we can find it can not get the corresponding
performance if we just expand the IO size. Because In dm crypt, it
will map the data buffer of one request with scatterlists, and send
all scatterlists of one request to the encryption engine to encrypt or
decrypt.  I found if the scatterlist list number is small and each
scatterlist length is bigger, it will improve the encryption speed,
that helps the engine palys best performance. But a big IO size does
not mean bigger scatterlists (maybe many scatterlists with small
length), that's why we can not get the corresponding performance if we
just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine
likes bigger scatterlists to improve the performance. But for bio
based, it only send one scatterlist (the scatterlist's length is
always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It
means if the bio size is 1M, the bio based will send 2048 times (evey
time the only one scatterlist length is 512 bytes) to crypto engine to
handle, which is more time-consuming and ineffective for the crypto
engine. But for request based, it can map the whole request with many
scatterlists (not just one scatterlist), and send all the scatterlists
to the crypto engine which can improve the performance, is it right?

Another optimization solution I think is we can expand the scatterlist
entry number for bio based.



I did some testing about my assumption of expanding the scatterlist
entry number for bio based. I did some modification for the bio based
to support multiple scatterlists, then it will get the same
performance as the request based things.

1. bio based with expanding the scatterlist entry
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct
1073741824 bytes (1.1 GB) copied, 94.5458 s, 11.4 MB/s
real1m34.562s
user0m0.030s
sys 0m3.850s

2. Sequential read 1G with requset based:
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct
1073741824 bytes (1.1 GB) copied, 94.8922 s, 11.3 MB/s
real1m34.908s
user0m0.030s
sys 0m4.000s

 From the data, we can find the bio based also can get the same
performance as the request based. So if someone still don't like the
request based things, I think we can optimize the bio based by
expanding the scatterlists number. Thanks.




Hi

Do you see any performance impact if you use with cryptsetup options:

 --perf-same_cpu_crypt
 --perf-submit_from_crypt_cpus

with your regular unpatched kernel.

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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 put request-based dm-crypt completely to one side and focus
just on the existing bio-based code.  Why is it slower and what can be
adjusted to improve this?



OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the
request based, we can find it can not get the corresponding
performance if we just expand the IO size. Because In dm crypt, it
will map the data buffer of one request with scatterlists, and send
all scatterlists of one request to the encryption engine to encrypt or
decrypt.  I found if the scatterlist list number is small and each
scatterlist length is bigger, it will improve the encryption speed,
that helps the engine palys best performance. But a big IO size does
not mean bigger scatterlists (maybe many scatterlists with small
length), that's why we can not get the corresponding performance if we
just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine
likes bigger scatterlists to improve the performance. But for bio
based, it only send one scatterlist (the scatterlist's length is
always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It
means if the bio size is 1M, the bio based will send 2048 times (evey
time the only one scatterlist length is 512 bytes) to crypto engine to
handle, which is more time-consuming and ineffective for the crypto
engine. But for request based, it can map the whole request with many
scatterlists (not just one scatterlist), and send all the scatterlists
to the crypto engine which can improve the performance, is it right?

Another optimization solution I think is we can expand the scatterlist
entry number for bio based.



I did some testing about my assumption of expanding the scatterlist
entry number for bio based. I did some modification for the bio based
to support multiple scatterlists, then it will get the same
performance as the request based things.

1. bio based with expanding the scatterlist entry
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct
1073741824 bytes (1.1 GB) copied, 94.5458 s, 11.4 MB/s
real1m34.562s
user0m0.030s
sys 0m3.850s

2. Sequential read 1G with requset based:
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct
1073741824 bytes (1.1 GB) copied, 94.8922 s, 11.3 MB/s
real1m34.908s
user0m0.030s
sys 0m4.000s

 From the data, we can find the bio based also can get the same
performance as the request based. So if someone still don't like the
request based things, I think we can optimize the bio based by
expanding the scatterlists number. Thanks.




Hi

Do you see any performance impact if you use with cryptsetup options:

 --perf-same_cpu_crypt
 --perf-submit_from_crypt_cpus

with your regular unpatched kernel.

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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 and videos or more safety...



We cannot afford to set aside 25% of read-only partition space for
redundancy on mobile devices, and would rather not impact performance
any more than dm-verity already does. With error correction we have
0.8% space overhead in our use case and no performance degradation if
the partition is not corrupted.



I'm probably missing here some hw knowledge here - but if you loose
a flash block of some size  - then you typically get  'error' for
all bytes the sector/block.

So how do you want to correctly 'restore'  missing full sectors  with just 
0.8% data overhead ??


Or is the device which fails to correct block returning something 'still 
usable'  (since e.g.  SATA disk certainly not)


Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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 are able to
correct bit flips, but don't have enough redundancy to correct larger
errors. Using this patch set we can correct N MiB of consecutive
corruption anywhere on the partition with the same amount of storage
overhead.


Another point - if the read-only system partition is experiencing some
errors, than the read-write partition will probably have errors too


On mobile devices, errors in read-only partitions often lead to
bricked devices while errors in the read-write parts might only lead
to lost cat photos. There are situations where people would prefer to
have a working phone even if it fails to store some of their data.


Do you have some real case where such error corrections
increase longevity of some device?


Yes, there have been several cases where read-only partition errors
have rendered a device unusable. The sheer volume of mobile devices
means that even if a tiny fraction of them suffer from such a problem,
it's going to affect a large number of people.


But you can take raid5 in read-only mode, put it on several partitions
protected with dm-verity and you get decent error correction


I agree. Unfortunately, we don't currently have the luxury of using
raid on mobile devices.



AFAIK - you just build as much partition as need  to have some 'space'
dedicated for redundancy -  and rest of  'partitions' you join as 'writable'

i.e. you have 1G of space - you want to give 250MB as 'redundancy' -
so create 4 partition

Since phones starts to have 64GB of storage space - it looks like a way to 
go.

As no one bothers to upgrade 'old' phone - why to focus there??

And BTW - already seen couple bricked  Nexus7
(And no marhmallow in plan)
(And interestingly all killed I've seen were on Lolipop - none with Kitkat)

Zdenek



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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 are able to
correct bit flips, but don't have enough redundancy to correct larger
errors. Using this patch set we can correct N MiB of consecutive
corruption anywhere on the partition with the same amount of storage
overhead.


Another point - if the read-only system partition is experiencing some
errors, than the read-write partition will probably have errors too


On mobile devices, errors in read-only partitions often lead to
bricked devices while errors in the read-write parts might only lead
to lost cat photos. There are situations where people would prefer to
have a working phone even if it fails to store some of their data.


Do you have some real case where such error corrections
increase longevity of some device?


Yes, there have been several cases where read-only partition errors
have rendered a device unusable. The sheer volume of mobile devices
means that even if a tiny fraction of them suffer from such a problem,
it's going to affect a large number of people.


But you can take raid5 in read-only mode, put it on several partitions
protected with dm-verity and you get decent error correction


I agree. Unfortunately, we don't currently have the luxury of using
raid on mobile devices.



AFAIK - you just build as much partition as need  to have some 'space'
dedicated for redundancy -  and rest of  'partitions' you join as 'writable'

i.e. you have 1G of space - you want to give 250MB as 'redundancy' -
so create 4 partition

Since phones starts to have 64GB of storage space - it looks like a way to 
go.

As no one bothers to upgrade 'old' phone - why to focus there??

And BTW - already seen couple bricked  Nexus7
(And no marhmallow in plan)
(And interestingly all killed I've seen were on Lolipop - none with Kitkat)

Zdenek



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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 and videos or more safety...



We cannot afford to set aside 25% of read-only partition space for
redundancy on mobile devices, and would rather not impact performance
any more than dm-verity already does. With error correction we have
0.8% space overhead in our use case and no performance degradation if
the partition is not corrupted.



I'm probably missing here some hw knowledge here - but if you loose
a flash block of some size  - then you typically get  'error' for
all bytes the sector/block.

So how do you want to correctly 'restore'  missing full sectors  with just 
0.8% data overhead ??


Or is the device which fails to correct block returning something 'still 
usable'  (since e.g.  SATA disk certainly not)


Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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 fails, use vmalloc. Memory allocated
with these functions should be freed with kvfree.


Sigh.  We've resisted doing this because vmalloc() is somewhat of a bad
thing, and we don't want to make it easy for people to do bad things.

And vmalloc is bad because a) it's slow and b) it does GFP_KERNEL
allocations for page tables and c) it is susceptible to arena
fragmentation.

We'd prefer that people fix their junk so it doesn't depend upon large
contiguous allocations.  This isn't userspace - kernel space is hostile
and kernel code should be robust.

So I dunno.  Should we continue to make it a bit more awkward to use
vmalloc()?  Probably that tactic isn't being very successful - people
will just go ahead and open-code it.  And given the surprising amount
of stuff you've placed in kvmalloc_node(), they'll implement it
incorrectly...


Hi

From my naive view:  4K-128K were nice restriction in the age of 16MB Pentium 
machines - but the time has changed and now users need to work with TB of memory.


So if the kernel driver is going to maintain such a huge chunk - it could 
hardly fit its resources into KB blocks.


So there are options - you could make complex code inside the driver to 
address every little kmalloc-ed chunk (and have a lot of potential for bugs) 
or you could always use vmalloc() and leave it on 'slow/GFP_KERNEL'.


So IMHO it's quite right to have the 'middle' road here - if there is enough 
memory to proceed with kmalloc - fine and if not - then driver will be 
somewhat slower but the coder will not have to spend months of coding 
reinvention of the wheel...


Personally I even find 128K pretty small if this limit comes from MB era and 
we are in the age of commonly available 32G laptops...


IMHO also it's kind of weird when kernel is not able to satisfy  128K 
allocation if there are gigabytes of free RAM in my system - there should be 
some defrag process running behind if there is such constrained kmalloc 
interface...


Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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 kmalloc and if it fails, use vmalloc. Memory allocated
with these functions should be freed with kvfree.


Sigh.  We've resisted doing this because vmalloc() is somewhat of a bad
thing, and we don't want to make it easy for people to do bad things.

And vmalloc is bad because a) it's slow and b) it does GFP_KERNEL
allocations for page tables and c) it is susceptible to arena
fragmentation.

We'd prefer that people fix their junk so it doesn't depend upon large
contiguous allocations.  This isn't userspace - kernel space is hostile
and kernel code should be robust.

So I dunno.  Should we continue to make it a bit more awkward to use
vmalloc()?  Probably that tactic isn't being very successful - people
will just go ahead and open-code it.  And given the surprising amount
of stuff you've placed in kvmalloc_node(), they'll implement it
incorrectly...


Hi

From my naive view:  4K-128K were nice restriction in the age of 16MB Pentium 
machines - but the time has changed and now users need to work with TB of memory.


So if the kernel driver is going to maintain such a huge chunk - it could 
hardly fit its resources into KB blocks.


So there are options - you could make complex code inside the driver to 
address every little kmalloc-ed chunk (and have a lot of potential for bugs) 
or you could always use vmalloc() and leave it on 'slow/GFP_KERNEL'.


So IMHO it's quite right to have the 'middle' road here - if there is enough 
memory to proceed with kmalloc - fine and if not - then driver will be 
somewhat slower but the coder will not have to spend months of coding 
reinvention of the wheel...


Personally I even find 128K pretty small if this limit comes from MB era and 
we are in the age of commonly available 32G laptops...


IMHO also it's kind of weird when kernel is not able to satisfy  128K 
allocation if there are gigabytes of free RAM in my system - there should be 
some defrag process running behind if there is such constrained kmalloc 
interface...


Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc5

[Zdenek Kabelac]

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, requiring
bisecting back to the debug commit.


Yes, it is.

So I'm wondering is anyone is working on fixing this in any way?

It kind of sucks when this is happening on an otherwise perfectly usable
old(ish) machine ...


The WARN() was already changed to a WARN_ONCE().

So that debug check doesn't cause problems any more. If somebody is
bisecting something else, and the WARN() is a problem for those
intermediate kernels, then just disabling CONFIG_DEBUG_ATOMIC_SLEEP
should get you past that point.

IOW, this really shouldn't be an issue.

Does the pccard thing still not work?


Interestingly enough, if the kernel is built with CONFIG_DEBUG_ATOMIC_SLEEP
unset, the problem with 99+% CPU load from pccardd goes away, so thanks for
the hint.



Ok - I  can now 'use'  3.19-rc7 on T61 (C2D) without having a single core 
occupied on 100% with pccardd, but I still get this one logged:



[2.185320] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f:
[2.185363]  excluding 0xc-0xc 0xe-0xf
[2.185526] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xa000-0xa0ff:

[2.185559]  excluding 0xa000-0xa0ff
[2.185720] pcmcia_socket pcmcia_socket0: cs: memory probe 
0x6000-0x60ff:

[2.185754]  excluding 0x6000-0x60ff
[2.297692] [ cut here ]
[2.297698] WARNING: CPU: 1 PID: 185 at kernel/sched/core.c:7300 
__might_sleep+0xae/0xc0()
[2.297702] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] pccardd+0xe8/0x490
[2.297712] Modules linked in: uhci_hcd sr_mod cdrom ehci_pci ehci_hcd 
yenta_socket usbcore usb_common video backlight autofs4
[2.297715] CPU: 1 PID: 185 Comm: pccardd Not tainted 
3.19.0-rc7-2-g9afdf96 #5
[2.297716] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 
03/18/2011
[2.297719]  819e4d8a 8800b8bdbc58 8163926d 
810a9e1e
[2.297721]  8800b8bdbca8 8800b8bdbc98 810587ba 
8800
[2.297724]  819e6073 026d  
0080

[2.297725] Call Trace:
[2.297729]  [] dump_stack+0x4f/0x7b
[2.297732]  [] ? down_trylock+0x2e/0x40
[2.297736]  [] warn_slowpath_common+0x8a/0xc0
[2.297738]  [] warn_slowpath_fmt+0x46/0x50
[2.297741]  [] ? pccardd+0xe8/0x490
[2.297742]  [] ? pccardd+0xe8/0x490
[2.297744]  [] __might_sleep+0xae/0xc0
[2.297747]  [] mutex_lock_nested+0x2e/0x440
[2.297749]  [] ? _raw_spin_unlock_irqrestore+0x5d/0x80
[2.297753]  [] ? preempt_count_sub+0xab/0x100
[2.297755]  [] pccardd+0x150/0x490
[2.297757]  [] ? pcmcia_socket_dev_complete+0x40/0x40
[2.297760]  [] kthread+0x11f/0x140
[2.297763]  [] ? kthread_create_on_node+0x260/0x260
[2.297766]  [] ret_from_fork+0x7c/0xb0
[2.297768]  [] ? kthread_create_on_node+0x260/0x260
[2.297770] ---[ end trace ed9e591061d223e6 ]---
[2.464635] usb 3-1: new full-speed USB device number 2 using uhci_hcd




and of course number of these:

[   29.660708] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   29.667061] i915 :00:02.0: registered panic notifier
[   30.314206] [ cut here ]
[   30.318866] WARNING: CPU: 0 PID: 1010 at drivers/gpu/drm/drm_irq.c:1121 
drm_wait_one_vblank+0x180/0x190 [drm]()

[   30.329085] vblank not available on crtc 1, ret=-22
[   30.334003] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm 
xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun brid
ge stp llc ipv6 ebtables ip6_tables iptable_filter ip_tables x_tables bnep 
iTCO_wdt hid_generic iTCO_vendor_support snd_hda_codec_analo
g snd_hda_codec_generic coretemp kvm_intel kvm microcode usbhid psmouse 
serio_raw hid arc4 r852 sm_common nand i2c_i801 nand_ecc i2c_co
re nand_ids mtd btusb bluetooth iwl3945 sdhci_pci r592 iwlegacy memstick 
pcmcia snd_hda_intel sdhci mac80211 snd_hda_controller mmc_cor
e snd_hda_codec snd_hwdep lpc_ich snd_seq mfd_core snd_seq_device snd_pcm 
e1000e cfg80211 ptp thinkpad_acpi snd_timer pps_core wmi nvra

m
[   30.406592]  snd soundcore evdev nfsd auth_rpcgss oid_registry nfs_acl 
lockd grace binfmt_misc loop sunrpc uhci_hcd sr_mod cdrom ehc

i_pci ehci_hcd yenta_socket usbcore usb_common video backlight autofs4
[   30.424031] CPU: 1 PID: 1010 Comm: Xorg.bin Tainted: GW 
3.19.0-rc7-2-g9afdf96 #5
[   30.432930] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 
03/18/2011
[   30.440627]  a0e1017f 880135a37a28 8163926d 

Re: Linux 3.19-rc5

[Zdenek Kabelac]

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 triggering worse behavior, requiring
bisecting back to the debug commit.


Yes, it is.

So I'm wondering is anyone is working on fixing this in any way?

It kind of sucks when this is happening on an otherwise perfectly usable
old(ish) machine ...


The WARN() was already changed to a WARN_ONCE().

So that debug check doesn't cause problems any more. If somebody is
bisecting something else, and the WARN() is a problem for those
intermediate kernels, then just disabling CONFIG_DEBUG_ATOMIC_SLEEP
should get you past that point.

IOW, this really shouldn't be an issue.

Does the pccard thing still not work?


Interestingly enough, if the kernel is built with CONFIG_DEBUG_ATOMIC_SLEEP
unset, the problem with 99+% CPU load from pccardd goes away, so thanks for
the hint.



Ok - I  can now 'use'  3.19-rc7 on T61 (C2D) without having a single core 
occupied on 100% with pccardd, but I still get this one logged:



[2.185320] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f:
[2.185363]  excluding 0xc-0xc 0xe-0xf
[2.185526] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xa000-0xa0ff:

[2.185559]  excluding 0xa000-0xa0ff
[2.185720] pcmcia_socket pcmcia_socket0: cs: memory probe 
0x6000-0x60ff:

[2.185754]  excluding 0x6000-0x60ff
[2.297692] [ cut here ]
[2.297698] WARNING: CPU: 1 PID: 185 at kernel/sched/core.c:7300 
__might_sleep+0xae/0xc0()
[2.297702] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[81518e18] pccardd+0xe8/0x490
[2.297712] Modules linked in: uhci_hcd sr_mod cdrom ehci_pci ehci_hcd 
yenta_socket usbcore usb_common video backlight autofs4
[2.297715] CPU: 1 PID: 185 Comm: pccardd Not tainted 
3.19.0-rc7-2-g9afdf96 #5
[2.297716] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 
03/18/2011
[2.297719]  819e4d8a 8800b8bdbc58 8163926d 
810a9e1e
[2.297721]  8800b8bdbca8 8800b8bdbc98 810587ba 
8800
[2.297724]  819e6073 026d  
0080

[2.297725] Call Trace:
[2.297729]  [8163926d] dump_stack+0x4f/0x7b
[2.297732]  [810a9e1e] ? down_trylock+0x2e/0x40
[2.297736]  [810587ba] warn_slowpath_common+0x8a/0xc0
[2.297738]  [81058836] warn_slowpath_fmt+0x46/0x50
[2.297741]  [81518e18] ? pccardd+0xe8/0x490
[2.297742]  [81518e18] ? pccardd+0xe8/0x490
[2.297744]  [8108412e] __might_sleep+0xae/0xc0
[2.297747]  [8163cd7e] mutex_lock_nested+0x2e/0x440
[2.297749]  [8164189d] ? _raw_spin_unlock_irqrestore+0x5d/0x80
[2.297753]  [8108b42b] ? preempt_count_sub+0xab/0x100
[2.297755]  [81518e80] pccardd+0x150/0x490
[2.297757]  [81518d30] ? pcmcia_socket_dev_complete+0x40/0x40
[2.297760]  [8107db1f] kthread+0x11f/0x140
[2.297763]  [8107da00] ? kthread_create_on_node+0x260/0x260
[2.297766]  [8164242c] ret_from_fork+0x7c/0xb0
[2.297768]  [8107da00] ? kthread_create_on_node+0x260/0x260
[2.297770] ---[ end trace ed9e591061d223e6 ]---
[2.464635] usb 3-1: new full-speed USB device number 2 using uhci_hcd




and of course number of these:

[   29.660708] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   29.667061] i915 :00:02.0: registered panic notifier
[   30.314206] [ cut here ]
[   30.318866] WARNING: CPU: 0 PID: 1010 at drivers/gpu/drm/drm_irq.c:1121 
drm_wait_one_vblank+0x180/0x190 [drm]()

[   30.329085] vblank not available on crtc 1, ret=-22
[   30.334003] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm 
xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun brid
ge stp llc ipv6 ebtables ip6_tables iptable_filter ip_tables x_tables bnep 
iTCO_wdt hid_generic iTCO_vendor_support snd_hda_codec_analo
g snd_hda_codec_generic coretemp kvm_intel kvm microcode usbhid psmouse 
serio_raw hid arc4 r852 sm_common nand i2c_i801 nand_ecc i2c_co
re nand_ids mtd btusb bluetooth iwl3945 sdhci_pci r592 iwlegacy memstick 
pcmcia snd_hda_intel sdhci mac80211 snd_hda_controller mmc_cor
e snd_hda_codec snd_hwdep lpc_ich snd_seq mfd_core snd_seq_device snd_pcm 
e1000e cfg80211 ptp thinkpad_acpi snd_timer pps_core wmi nvra

m
[   30.406592]  snd soundcore evdev nfsd auth_rpcgss oid_registry nfs_acl 
lockd grace binfmt_misc loop sunrpc uhci_hcd sr_mod cdrom ehc

i_pci ehci_hcd yenta_socket usbcore 

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

[Zdenek Kabelac]

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] Starting disk
[ 2174.076342] [ cut here ]
[ 2174.076350] WARNING: CPU: 0 PID: 2623 at drivers/pnp/pnpacpi/core.c:96 
pnpacpi_set_resources+0x14f/0x160()
[ 2174.076412] Modules linked in: dm_raid raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx raid1 raid10 dm_mod md_mod xor 
raid6_pq i915 i2c_algo_bit drm_kms_helper drm xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 
xt_conntrack nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables 
x_tables tun bridge stp llc ipv6 hid_generic usbhid hid snd_hda_codec_analog 
snd_hda_codec_generic iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm 
microcode psmouse serio_raw i2c_i801 i2c_core arc4 lpc_ich mfd_core r852 
iwl3945 sm_common nand r592 nand_ecc nand_ids iwlegacy mtd memstick mac80211 
sdhci_pci pcmcia sdhci snd_hda_intel mmc_core snd_hda_controller snd_hda_codec 
snd_hwdep snd_seq snd_seq_device snd_pcm cfg80211 e1000e ptp snd_timer
[ 2174.076433]  pps_core wmi thinkpad_acpi nvram snd soundcore evdev nfsd 
auth_rpcgss oid_registry nfs_acl lockd binfmt_misc loop sunrpc uhci_hcd sr_mod 
cdrom yenta_socket ehci_pci ehci_hcd usbcore usb_common video backlight autofs4
[ 2174.076436] CPU: 0 PID: 2623 Comm: systemd-sleep Not tainted 
3.15.0-rc7-00044-g887210a #209
[ 2174.076437] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 
03/18/2011
[ 2174.076440]  0009 880095d55c40 815db694 

[ 2174.076444]  880095d55c78 8104e78d  
880136c3cd98
[ 2174.076447]  8800bac2b000 8180cb5a  
880095d55c88

[ 2174.076448] Call Trace:
[ 2174.076453]  [] dump_stack+0x4e/0x7a
[ 2174.076643]  [] warn_slowpath_common+0x7d/0xa0
[ 2174.076646]  [] warn_slowpath_null+0x1a/0x20
[ 2174.076648]  [] pnpacpi_set_resources+0x14f/0x160
[ 2174.076651]  [] pnp_start_dev+0x42/0x80
[ 2174.076655]  [] pnp_bus_resume+0x88/0xa0
[ 2174.076658]  [] ? pnp_bus_suspend+0x20/0x20
[ 2174.076662]  [] dpm_run_callback+0x49/0xa0
[ 2174.076664]  [] device_resume+0xc8/0x1f0
[ 2174.076667]  [] dpm_resume+0x119/0x250
[ 2174.076670]  [] dpm_resume_end+0x11/0x20
[ 2174.076673]  [] suspend_devices_and_enter+0xff/0x680
[ 2174.076676]  [] pm_suspend+0x1e7/0x2a0
[ 2174.076678]  [] state_store+0x7c/0xf0
[ 2174.076683]  [] kobj_attr_store+0xf/0x20
[ 2174.076686]  [] sysfs_kf_write+0x45/0x60
[ 2174.076690]  [] kernfs_fop_write+0xf9/0x180
[ 2174.076694]  [] vfs_write+0xbd/0x1e0
[ 2174.076696]  [] SyS_write+0x49/0xb0
[ 2174.076700]  [] system_call_fastpath+0x1a/0x1f
[ 2174.081587] ---[ end trace 32ffe1e61f685f01 ]---
[ 2174.082221] serial 00:09: activated
[ 2174.233290] thinkpad_acpi: ACPI backlight control delay disabled
[ 2174.323685] ata4.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered 
out
[ 2174.323688] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered 
out
[ 2174.324671] ata4.00: ACPI cmd e3/00:79:00:00:00:a0 (IDLE) succeeded
[ 2174.325651] ata4.00: ACPI cmd e3/00:01:00:00:00:a0 (IDLE) succeeded
[ 2174.345266] ata4.00: configured for UDMA/33
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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] Starting disk
[ 2174.076342] [ cut here ]
[ 2174.076350] WARNING: CPU: 0 PID: 2623 at drivers/pnp/pnpacpi/core.c:96 
pnpacpi_set_resources+0x14f/0x160()
[ 2174.076412] Modules linked in: dm_raid raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx raid1 raid10 dm_mod md_mod xor 
raid6_pq i915 i2c_algo_bit drm_kms_helper drm xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 
xt_conntrack nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables 
x_tables tun bridge stp llc ipv6 hid_generic usbhid hid snd_hda_codec_analog 
snd_hda_codec_generic iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm 
microcode psmouse serio_raw i2c_i801 i2c_core arc4 lpc_ich mfd_core r852 
iwl3945 sm_common nand r592 nand_ecc nand_ids iwlegacy mtd memstick mac80211 
sdhci_pci pcmcia sdhci snd_hda_intel mmc_core snd_hda_controller snd_hda_codec 
snd_hwdep snd_seq snd_seq_device snd_pcm cfg80211 e1000e ptp snd_timer
[ 2174.076433]  pps_core wmi thinkpad_acpi nvram snd soundcore evdev nfsd 
auth_rpcgss oid_registry nfs_acl lockd binfmt_misc loop sunrpc uhci_hcd sr_mod 
cdrom yenta_socket ehci_pci ehci_hcd usbcore usb_common video backlight autofs4
[ 2174.076436] CPU: 0 PID: 2623 Comm: systemd-sleep Not tainted 
3.15.0-rc7-00044-g887210a #209
[ 2174.076437] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 
03/18/2011
[ 2174.076440]  0009 880095d55c40 815db694 

[ 2174.076444]  880095d55c78 8104e78d  
880136c3cd98
[ 2174.076447]  8800bac2b000 8180cb5a  
880095d55c88

[ 2174.076448] Call Trace:
[ 2174.076453]  [815db694] dump_stack+0x4e/0x7a
[ 2174.076643]  [8104e78d] warn_slowpath_common+0x7d/0xa0
[ 2174.076646]  [8104e86a] warn_slowpath_null+0x1a/0x20
[ 2174.076648]  [814046cf] pnpacpi_set_resources+0x14f/0x160
[ 2174.076651]  [81401db2] pnp_start_dev+0x42/0x80
[ 2174.076655]  [81400858] pnp_bus_resume+0x88/0xa0
[ 2174.076658]  [814007d0] ? pnp_bus_suspend+0x20/0x20
[ 2174.076662]  [8145e919] dpm_run_callback+0x49/0xa0
[ 2174.076664]  [8145ec18] device_resume+0xc8/0x1f0
[ 2174.076667]  [81460639] dpm_resume+0x119/0x250
[ 2174.076670]  [814609b1] dpm_resume_end+0x11/0x20
[ 2174.076673]  [810b4b0f] suspend_devices_and_enter+0xff/0x680
[ 2174.076676]  [810b5277] pm_suspend+0x1e7/0x2a0
[ 2174.076678]  [810b3c2c] state_store+0x7c/0xf0
[ 2174.076683]  [81359f2f] kobj_attr_store+0xf/0x20
[ 2174.076686]  [8124b1b5] sysfs_kf_write+0x45/0x60
[ 2174.076690]  [8124a4d9] kernfs_fop_write+0xf9/0x180
[ 2174.076694]  [811c66bd] vfs_write+0xbd/0x1e0
[ 2174.076696]  [811c7249] SyS_write+0x49/0xb0
[ 2174.076700]  [815ecbd6] system_call_fastpath+0x1a/0x1f
[ 2174.081587] ---[ end trace 32ffe1e61f685f01 ]---
[ 2174.082221] serial 00:09: activated
[ 2174.233290] thinkpad_acpi: ACPI backlight control delay disabled
[ 2174.323685] ata4.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered 
out
[ 2174.323688] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered 
out
[ 2174.324671] ata4.00: ACPI cmd e3/00:79:00:00:00:a0 (IDLE) succeeded
[ 2174.325651] ata4.00: ACPI cmd e3/00:01:00:00:00:a0 (IDLE) succeeded
[ 2174.345266] ata4.00: configured for UDMA/33
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression with suspend resume 5a87182aa21d6d5d306840feab9321818dd3e2a3

[Zdenek Kabelac]

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 governors on system suspend/hibernate".


When I just revert this commit with 374b105797c3d4f29c685f3be535c35f5689b30e
(3.13-rc3)   suspend/resume works again.
(I'm using  ondemand CPU governor)


Rafael just asked Linus to pull a revert of that commit (see
https://lkml.org/lkml/2013/12/7/126 ).





I'm not sure - but it also could be related with another warning I'm getting
during resume:

But possibly this is result in  i915 update ?

Zdenek


PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.005 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
[ cut here ]
WARNING: CPU: 0 PID: 2042 at drivers/gpu/drm/i915/intel_display.c:9948 
intel_get_pipe_from_connector+0x49/0x50 [i915]()
Modules linked in: i915 i2c_algo_bit drm_kms_helper drm ctr ccm ipt_MASQUERADE 
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp tun bridge stp 
llc ipv6 ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables 
bnep btusb bluetooth snd_hda_codec_analog iTCO_wdt iTCO_vendor_support arc4 
coretemp kvm_intel kvm microcode iwl3945 iwlegacy psmouse serio_raw mac80211 
i2c_i801 i2c_core sdhci_pci r852 sm_common sdhci nand cfg80211 nand_ecc 
snd_hda_intel nand_ids mmc_core mtd snd_hda_codec r592 snd_hwdep snd_seq 
memstick snd_seq_device snd_pcm lpc_ich mfd_core e1000e snd_page_alloc 
snd_timer ptp pps_core thinkpad_acpi wmi nvram snd soundcore evdev binfmt_misc 
nfsd auth_rpcgss oid_registry exportfs loop nfs_acl lockd sunrpc pcmcia sr_mod 
yenta_socket cdrom ehci_pci ehci_hcd uhci_hcd usbcore usb_common video 
backlight autofs4
CPU: 0 PID: 2042 Comm: kworker/u4:3 Tainted: GW 
3.13.0-rc3-6-gee4645c #186

Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
Workqueue: events_unbound async_run_entry_fn
 0009 88009ad21af8 815a3bfe 
 88009ad21b30 8104924d 8800b5f4fe00 8800aa408000
  8800b5f4fe00 8800b5f4fe00 88009ad21b40
Call Trace:
 [] dump_stack+0x4e/0x7a
 [] warn_slowpath_common+0x7d/0xa0
 [] warn_slowpath_null+0x1a/0x20
 [] intel_get_pipe_from_connector+0x49/0x50 [i915]
 [] intel_panel_disable_backlight+0x25/0x180 [i915]
 [] intel_disable_lvds+0x4d/0x180 [i915]
 [] i9xx_crtc_disable+0x28a/0x380 [i915]
 [] i915_drm_freeze+0xca/0x150 [i915]
 [] i915_pm_suspend+0x3d/0x90 [i915]
 [] pci_pm_suspend+0x6c/0x150
 [] ? pci_pm_freeze+0xe0/0xe0
 [] dpm_run_callback+0x49/0xa0
 [] __device_suspend+0xdd/0x280
 [] async_suspend+0x1f/0xa0
 [] async_run_entry_fn+0x37/0x130
 [] process_one_work+0x1fd/0x6d0
 [] ? process_one_work+0x19b/0x6d0
 [] worker_thread+0x121/0x3a0
 [] ? process_one_work+0x6d0/0x6d0
 [] kthread+0xf0/0x110
 [] ? insert_kthread_work+0x70/0x70
 [] ret_from_fork+0x7c/0xb0
 [] ? insert_kthread_work+0x70/0x70
---[ end trace 7517bdfd550790cc ]---
PM: suspend of devices complete after 797.599 msecs
PM: late suspend of devices complete after 3.960 msecs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression with suspend resume 5a87182aa21d6d5d306840feab9321818dd3e2a3

[Zdenek Kabelac]

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 governors on system suspend/hibernate.


When I just revert this commit with 374b105797c3d4f29c685f3be535c35f5689b30e
(3.13-rc3)   suspend/resume works again.
(I'm using  ondemand CPU governor)


Rafael just asked Linus to pull a revert of that commit (see
https://lkml.org/lkml/2013/12/7/126 ).





I'm not sure - but it also could be related with another warning I'm getting
during resume:

But possibly this is result in  i915 update ?

Zdenek


PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.005 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
[ cut here ]
WARNING: CPU: 0 PID: 2042 at drivers/gpu/drm/i915/intel_display.c:9948 
intel_get_pipe_from_connector+0x49/0x50 [i915]()
Modules linked in: i915 i2c_algo_bit drm_kms_helper drm ctr ccm ipt_MASQUERADE 
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp tun bridge stp 
llc ipv6 ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables 
bnep btusb bluetooth snd_hda_codec_analog iTCO_wdt iTCO_vendor_support arc4 
coretemp kvm_intel kvm microcode iwl3945 iwlegacy psmouse serio_raw mac80211 
i2c_i801 i2c_core sdhci_pci r852 sm_common sdhci nand cfg80211 nand_ecc 
snd_hda_intel nand_ids mmc_core mtd snd_hda_codec r592 snd_hwdep snd_seq 
memstick snd_seq_device snd_pcm lpc_ich mfd_core e1000e snd_page_alloc 
snd_timer ptp pps_core thinkpad_acpi wmi nvram snd soundcore evdev binfmt_misc 
nfsd auth_rpcgss oid_registry exportfs loop nfs_acl lockd sunrpc pcmcia sr_mod 
yenta_socket cdrom ehci_pci ehci_hcd uhci_hcd usbcore usb_common video 
backlight autofs4
CPU: 0 PID: 2042 Comm: kworker/u4:3 Tainted: GW 
3.13.0-rc3-6-gee4645c #186

Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
Workqueue: events_unbound async_run_entry_fn
 0009 88009ad21af8 815a3bfe 
 88009ad21b30 8104924d 8800b5f4fe00 8800aa408000
  8800b5f4fe00 8800b5f4fe00 88009ad21b40
Call Trace:
 [815a3bfe] dump_stack+0x4e/0x7a
 [8104924d] warn_slowpath_common+0x7d/0xa0
 [8104932a] warn_slowpath_null+0x1a/0x20
 [a0c27f59] intel_get_pipe_from_connector+0x49/0x50 [i915]
 [a0c41e05] intel_panel_disable_backlight+0x25/0x180 [i915]
 [a0c2cfad] intel_disable_lvds+0x4d/0x180 [i915]
 [a0c1ceda] i9xx_crtc_disable+0x28a/0x380 [i915]
 [a0be50ca] i915_drm_freeze+0xca/0x150 [i915]
 [a0be54cd] i915_pm_suspend+0x3d/0x90 [i915]
 [813668bc] pci_pm_suspend+0x6c/0x150
 [81366850] ? pci_pm_freeze+0xe0/0xe0
 [81433e89] dpm_run_callback+0x49/0xa0
 [8143428d] __device_suspend+0xdd/0x280
 [8143444f] async_suspend+0x1f/0xa0
 [81079e87] async_run_entry_fn+0x37/0x130
 [8106a8ed] process_one_work+0x1fd/0x6d0
 [8106a88b] ? process_one_work+0x19b/0x6d0
 [8106aee1] worker_thread+0x121/0x3a0
 [8106adc0] ? process_one_work+0x6d0/0x6d0
 [81072fc0] kthread+0xf0/0x110
 [81072ed0] ? insert_kthread_work+0x70/0x70
 [815b402c] ret_from_fork+0x7c/0xb0
 [81072ed0] ? insert_kthread_work+0x70/0x70
---[ end trace 7517bdfd550790cc ]---
PM: suspend of devices complete after 797.599 msecs
PM: late suspend of devices complete after 3.960 msecs

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

FADT errors reported by Lenovo T61

[Zdenek Kabelac]

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 mismatch in FADT/Gpe1Block: 0/32 
(20130725/tbfadt-572)"


which probably leads to -

"ACPI FADT declares the system doesn't support PCIe ASPM, so disable it"

and

"acpi PNP0A08:00: Disabling ASPM (FADT indicates it is unsupported)"

and at the end after my networking is started I get this:

iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 
in-tree:ds

iwl3945: Copyright(c) 2003-2011 Intel Corporation
iwl3945 :03:00.0: can't disable ASPM; OS doesn't have ASPM control


thanks

Zdenek



Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 3.12.0-00053-g6ed31ed (kabi@linux) (gcc version 4.8.2 20131017 
(Red Hat 4.8.2-1) (GCC) ) #166 SMP PREEMPT Tue Nov 5 13:10:45 CET 2013
Command line: BOOT_IMAGE=/vmlinuz-3.12.0-00053-g6ed31ed root=/dev/sda2 ro 
selinux=0 kmemleak=off lockdep.prove_locking=0 lockdep.lock_stat=0 
ipv6.disable=1 systemd.log_level=info systemd.log_target=kmsg quiet 
console=ttyS0,115200 console=tty LANG=cs_CZ.UTF-8

e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009d7ff] usable
BIOS-e820: [mem 0x0009d800-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbf6a] usable
BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
BIOS-e820: [mem 0xbf70-0xbfff] reserved
BIOS-e820: [mem 0xf000-0xf3ff] reserved
BIOS-e820: [mem 0xfec0-0xfec0] reserved
BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xff00-0x] reserved
BIOS-e820: [mem 0x0001-0x00013bff] usable
kmemleak: Kernel memory leak detector disabled
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
DMI: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
e820: update [mem 0x-0x0fff] usable ==> reserved
e820: remove [mem 0x000a-0x000f] usable
No AGP bridge found
e820: last_pfn = 0x13c000 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C write-protect
  D-D uncachable
  E-F write-protect
MTRR variable ranges enabled:
  0 base 0C000 mask FC000 uncachable
  1 base 13C00 mask FFC00 uncachable
  2 base 0 mask F write-back
  3 base 1 mask FC000 write-back
  4 base 0BF70 mask 0 uncachable
  5 base 0BF80 mask FFF80 uncachable
  6 disabled
  7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 3GB, range: 1GB, type UC
reg 1, base: 5056MB, range: 64MB, type UC
reg 2, base: 0GB, range: 4GB, type WB
reg 3, base: 4GB, range: 1GB, type WB
reg 4, base: 3063MB, range: 1MB, type UC
reg 5, base: 3064MB, range: 8MB, type UC
total RAM covered: 4023M
Found optimal setting for mtrr clean up
 gran_size: 64K chunk_size: 128M num_reg: 6  lose 
cover RAM: 0G

New variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 2GB, range: 1GB, type WB
reg 2, base: 3063MB, range: 1MB, type UC
reg 3, base: 3064MB, range: 8MB, type UC
reg 4, base: 4GB, range: 1GB, type WB
reg 5, base: 5056MB, range: 64MB, type UC
e820: update [mem 0xbf70-0x] usable ==> reserved
e820: last_pfn = 0xbf6b0 max_arch_pfn = 0x4
found SMP MP-table at [mem 0x000f68f0-0x000f68ff] mapped at [880f68f0]
Scanning 1 areas for low memory corruption
Base memory trampoline at [88097000] 97000 size 24576
init_memory_mapping: [mem 0x-0x000f]
 [mem 0x-0x000f] page 4k
BRK [0x02847000, 0x02847fff] PGTABLE
BRK [0x02848000, 0x02848fff] PGTABLE
BRK [0x02849000, 0x02849fff] PGTABLE
init_memory_mapping: [mem 0x13be0-0x13bff]
 [mem 0x13be0-0x13bff] page 2M
BRK [0x0284a000, 0x0284afff] PGTABLE
init_memory_mapping: [mem 0x13800-0x13bdf]
 [mem 0x13800-0x13bdf] page 2M
init_memory_mapping: [mem 0x1-0x137ff]
 [mem 0x1-0x137ff] page 2M
init_memory_mapping: [mem 0x0010-0xbf6a]
 [mem 0x0010-0x001f] page 4k
 [mem 0x0020-0xbf5f] page 2M
 [mem 0xbf60-0xbf6a] page 4k
RAMDISK: [mem 0x36df2000-0x376f0fff]
ACPI: RSDP 000f68c0 00024 (v02 LENOVO)
ACPI: XSDT 

FADT errors reported by Lenovo T61

[Zdenek Kabelac]

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 mismatch in FADT/Gpe1Block: 0/32 
(20130725/tbfadt-572)


which probably leads to -

ACPI FADT declares the system doesn't support PCIe ASPM, so disable it

and

acpi PNP0A08:00: Disabling ASPM (FADT indicates it is unsupported)

and at the end after my networking is started I get this:

iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 
in-tree:ds

iwl3945: Copyright(c) 2003-2011 Intel Corporation
iwl3945 :03:00.0: can't disable ASPM; OS doesn't have ASPM control


thanks

Zdenek



Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 3.12.0-00053-g6ed31ed (kabi@linux) (gcc version 4.8.2 20131017 
(Red Hat 4.8.2-1) (GCC) ) #166 SMP PREEMPT Tue Nov 5 13:10:45 CET 2013
Command line: BOOT_IMAGE=/vmlinuz-3.12.0-00053-g6ed31ed root=/dev/sda2 ro 
selinux=0 kmemleak=off lockdep.prove_locking=0 lockdep.lock_stat=0 
ipv6.disable=1 systemd.log_level=info systemd.log_target=kmsg quiet 
console=ttyS0,115200 console=tty LANG=cs_CZ.UTF-8

e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009d7ff] usable
BIOS-e820: [mem 0x0009d800-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbf6a] usable
BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
BIOS-e820: [mem 0xbf70-0xbfff] reserved
BIOS-e820: [mem 0xf000-0xf3ff] reserved
BIOS-e820: [mem 0xfec0-0xfec0] reserved
BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xff00-0x] reserved
BIOS-e820: [mem 0x0001-0x00013bff] usable
kmemleak: Kernel memory leak detector disabled
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
DMI: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
e820: update [mem 0x-0x0fff] usable == reserved
e820: remove [mem 0x000a-0x000f] usable
No AGP bridge found
e820: last_pfn = 0x13c000 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C write-protect
  D-D uncachable
  E-F write-protect
MTRR variable ranges enabled:
  0 base 0C000 mask FC000 uncachable
  1 base 13C00 mask FFC00 uncachable
  2 base 0 mask F write-back
  3 base 1 mask FC000 write-back
  4 base 0BF70 mask 0 uncachable
  5 base 0BF80 mask FFF80 uncachable
  6 disabled
  7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 3GB, range: 1GB, type UC
reg 1, base: 5056MB, range: 64MB, type UC
reg 2, base: 0GB, range: 4GB, type WB
reg 3, base: 4GB, range: 1GB, type WB
reg 4, base: 3063MB, range: 1MB, type UC
reg 5, base: 3064MB, range: 8MB, type UC
total RAM covered: 4023M
Found optimal setting for mtrr clean up
 gran_size: 64K chunk_size: 128M num_reg: 6  lose 
cover RAM: 0G

New variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 2GB, range: 1GB, type WB
reg 2, base: 3063MB, range: 1MB, type UC
reg 3, base: 3064MB, range: 8MB, type UC
reg 4, base: 4GB, range: 1GB, type WB
reg 5, base: 5056MB, range: 64MB, type UC
e820: update [mem 0xbf70-0x] usable == reserved
e820: last_pfn = 0xbf6b0 max_arch_pfn = 0x4
found SMP MP-table at [mem 0x000f68f0-0x000f68ff] mapped at [880f68f0]
Scanning 1 areas for low memory corruption
Base memory trampoline at [88097000] 97000 size 24576
init_memory_mapping: [mem 0x-0x000f]
 [mem 0x-0x000f] page 4k
BRK [0x02847000, 0x02847fff] PGTABLE
BRK [0x02848000, 0x02848fff] PGTABLE
BRK [0x02849000, 0x02849fff] PGTABLE
init_memory_mapping: [mem 0x13be0-0x13bff]
 [mem 0x13be0-0x13bff] page 2M
BRK [0x0284a000, 0x0284afff] PGTABLE
init_memory_mapping: [mem 0x13800-0x13bdf]
 [mem 0x13800-0x13bdf] page 2M
init_memory_mapping: [mem 0x1-0x137ff]
 [mem 0x1-0x137ff] page 2M
init_memory_mapping: [mem 0x0010-0xbf6a]
 [mem 0x0010-0x001f] page 4k
 [mem 0x0020-0xbf5f] page 2M
 [mem 0xbf60-0xbf6a] page 4k
RAMDISK: [mem 0x36df2000-0x376f0fff]
ACPI: RSDP 000f68c0 00024 (v02 LENOVO)
ACPI: XSDT bf6bb496 

Re: kobject_add_internal failed for msi_irqs with -EEXIST

[Zdenek Kabelac]

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, 4GB Ram)
(repost since linux-kernel@ rejected my gmail email)


This looks related to the MSI/kobject issues Veaceslav is working on.
See
http://lkml.kernel.org/r/1379382464-7920-2-git-send-email-vfal...@redhat.com
and related messages.

We don't have a resolution yet.  If you have
CONFIG_DEBUG_KOBJECT_RELEASE=y, you could try turning that off.  I
don't know if it would help, and it would only be a temporary
workaround anyway.


I've looked at the original post -
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg510798.html
hope that's it - and it seems that it's disabling DEBUG_KOBJECT_RELEASE
won't help - the warning is about the re-registering, not about freeing it.

As a workaround I'd suggest adding some kind of delay between removing and
adding the msi - as in - rmmod e1000e; sleep 1; modprobe e1000e; - or
something like that, so that there is enough time for the /msqi_irqs/ to go
away.



I'm not readding e1000e modules myself - however I've no idea what 
NetworkManager does. Here are messages prior warning:


NetworkManager[304]:  monitoring kernel firmware directory 
'/lib/firmware'.
NetworkManager[304]:  rfkill1: found WiFi radio killswitch (at 
/sys/devices/pci:00/:00:1c.1/:03:00.0/ieee80211/phy0/rfkill1) 
(driver iwl3945)

NetworkManager[304]:  WiFi hardware radio set enabled
NetworkManager[304]:  WiFi enabled by radio killswitch; enabled by state 
file
NetworkManager[304]:  WWAN enabled by radio killswitch; disabled by 
state file
NetworkManager[304]:  WiMAX enabled by radio killswitch; enabled by 
state file

NetworkManager[304]:  Networking is enabled by state file
NetworkManager[304]:  (eth0): carrier is OFF
NetworkManager[304]:  (eth0): new Ethernet device (driver: 'e1000e' 
ifindex: 2)
NetworkManager[304]:  (eth0): exported as 
/org/freedesktop/NetworkManager/Devices/0
NetworkManager[304]:  (eth0): device state change: unmanaged -> 
unavailable (reason 'managed') [10 20 2]

NetworkManager[304]:  (eth0): bringing up device.
rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
kernel: [5.727025] WARNING! power/level is deprecated; use power/control 
instead



So it looks like  'bringing up' causes recreation of msi_irqs ?

Zdenek





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kobject_add_internal failed for msi_irqs with -EEXIST

[Zdenek Kabelac]

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 sysfs_add_one+0xa5/0xd0()
sysfs: cannot create duplicate filename 
'/devices/pci:00/:00:19.0/msi_irqs'
Modules linked in: bnep btusb bluetooth iTCO_wdt iTCO_vendor_support 
snd_hda_codec_analog hid_generic coretemp kvm_intel kvm arc4 microcode psmouse 
serio_raw i2c_i801 i2c_core iwl3945 iwlegacy sdhci_pci usbhid mac80211 hid 
r852 sm_common nand nand_ecc r592 sdhci lpc_ich nand_ids mfd_core mmc_core mtd 
memstick cfg80211 snd_hda_intel snd_hda_codec snd_seq snd_seq_device wmi 
thinkpad_acpi snd_pcm nvram e1000e snd_page_alloc snd_timer snd evdev ptp 
soundcore pps_core nfsd auth_rpcgss oid_registry exportfs nfs_acl loop lockd 
binfmt_misc sunrpc pcmcia sr_mod cdrom yenta_socket ehci_pci ehci_hcd uhci_hcd 
usbcore usb_common video backlight autofs4

CPU: 0 PID: 301 Comm: NetworkManager Not tainted 3.12.0-rc2-00088-gfcbfc0d #163
Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
 0009 8800b85fb558 81595d57 8800b85fb5a0
 8800b85fb590 810491ad ffef 8800b79a8c80
 8800b85fb638 8800b87df000  8800b85fb5f0
Call Trace:
 [] dump_stack+0x4e/0x82
 [] warn_slowpath_common+0x7d/0xa0
 [] warn_slowpath_fmt+0x4c/0x50
 [] sysfs_add_one+0xa5/0xd0
 [] create_dir+0x74/0xd0
 [] sysfs_create_dir+0x89/0xe0
 [] kobject_add_internal+0xc8/0x320
 [] ? __raw_spin_lock_init+0x2d/0x50
 [] kset_register+0x20/0x50
 [] kset_create_and_add+0x71/0xb0
 [] populate_msi_sysfs+0x2a/0x120
 [] pci_enable_msi_block+0x1b8/0x2c0
 [] e1000_open+0x225/0x5b0 [e1000e]
 [] __dev_open+0xbf/0x140
 [] __dev_change_flags+0x92/0x170
 [] dev_change_flags+0x1d/0x60
 [] do_setlink+0x342/0xa00
 [] ? native_sched_clock+0x24/0x80
 [] ? local_clock+0x3f/0x50
 [] ? nla_parse+0x32/0xe0
 [] rtnl_newlink+0x38f/0x5d0
 [] ? native_sched_clock+0x24/0x80
 [] ? trace_hardirqs_off_caller+0x1f/0xc0
 [] rtnetlink_rcv_msg+0x9c/0x260
 [] ? mutex_lock_nested+0x2f7/0x440
 [] ? rtnetlink_rcv+0x1b/0x40
 [] ? get_parent_ip+0xd/0x50
 [] ? rtnetlink_rcv+0x1b/0x40
 [] ? rtnetlink_rcv+0x40/0x40
 [] netlink_rcv_skb+0xa9/0xc0
 [] rtnetlink_rcv+0x2a/0x40
 [] netlink_unicast+0xdd/0x190
 [] netlink_sendmsg+0x329/0x750
 [] ? local_clock+0x3f/0x50
 [] ? might_fault+0x57/0xb0
 [] sock_sendmsg+0xa8/0x180
 [] ? might_fault+0x57/0xb0
 [] ? might_fault+0xa0/0xb0
 [] ? might_fault+0x57/0xb0
 [] ? verify_iovec+0x56/0xd0
 [] ___sys_sendmsg+0x35e/0x370
 [] ? lock_release_holdtime.part.29+0x9d/0x160
 [] ? local_clock+0x3f/0x50
 [] ? fget_light+0xd2/0x4f0
 [] ? get_parent_ip+0xd/0x50
 [] ? get_parent_ip+0xd/0x50
 [] ? sub_preempt_count+0x71/0x100
 [] ? put_lock_stats.isra.28+0xe/0x40
 [] ? fget_light+0xef/0x4f0
 [] ? fget_light+0x3c/0x4f0
 [] __sys_sendmsg+0x42/0x80
 [] SyS_sendmsg+0x12/0x20
 [] system_call_fastpath+0x1a/0x1f
---[ end trace 881f4293213af6b4 ]---
[ cut here ]
WARNING: CPU: 1 PID: 301 at lib/kobject.c:196 kobject_add_internal+0x204/0x320()
kobject_add_internal failed for msi_irqs with -EEXIST, don't try to register 
things with the same name in the same directory.
Modules linked in: bnep btusb bluetooth iTCO_wdt iTCO_vendor_support 
snd_hda_codec_analog hid_generic coretemp kvm_intel kvm arc4 microcode psmouse 
serio_raw i2c_i801 i2c_core iwl3945 iwlegacy sdhci_pci usbhid mac80211 hid 
r852 sm_common nand nand_ecc r592 sdhci lpc_ich nand_ids mfd_core mmc_core mtd 
memstick cfg80211 snd_hda_intel snd_hda_codec snd_seq snd_seq_device wmi 
thinkpad_acpi snd_pcm nvram e1000e snd_page_alloc snd_timer snd evdev ptp 
soundcore pps_core nfsd auth_rpcgss oid_registry exportfs nfs_acl loop lockd 
binfmt_misc sunrpc pcmcia sr_mod cdrom yenta_socket ehci_pci ehci_hcd uhci_hcd 
usbcore usb_common video backlight autofs4
CPU: 0 PID: 301 Comm: NetworkManager Tainted: GW 
3.12.0-rc2-00088-gfcbfc0d #163

Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
 0009 8800b85fb608 81595d57 8800b85fb650
 8800b85fb640 810491ad 880036e7c258 ffef
 880135b6c0a8 880135b6c0a8 8800ba074000 8800b85fb6a0
Call Trace:
 [] dump_stack+0x4e/0x82
 [] warn_slowpath_common+0x7d/0xa0
 [] warn_slowpath_fmt+0x4c/0x50
 [] ? sysfs_create_dir+0x89/0xe0
 [] kobject_add_internal+0x204/0x320
 [] ? __raw_spin_lock_init+0x2d/0x50
 [] kset_register+0x20/0x50
 [] kset_create_and_add+0x71/0xb0
 [] populate_msi_sysfs+0x2a/0x120
 [] pci_enable_msi_block+0x1b8/0x2c0
 [] e1000_open+0x225/0x5b0 [e1000e]
 [] __dev_open+0xbf/0x140
 [] __dev_change_flags+0x92/0x170
 [] dev_change_flags+0x1d/0x60
 [] do_setlink+0x342/0xa00
 [] ? native_sched_clock+0x24/0x80
 [] ? local_clock+0x3f/0x50
 [] ? nla_parse+0x32/0xe0
 [] 

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

[Zdenek Kabelac]

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 environment)
linux-vanilla git: 4b97280675f45c1650ee4e388bd711ecbb18c4b4
(on top of that there are few minor unrelated patches)


[  235.631952] loop: module loaded
[  235.971853] bio: create slab  at 1
[  237.355014] bio: create slab  at 2
[  237.671371] BUG: unable to handle kernel NULL pointer dereference at
0018
[  237.674537] IP: [] get_next_timer_interrupt+0x168/0x250
[  237.674537] PGD 16939067 PUD 14257067 PMD 0
[  237.674537] Oops:  [#1] PREEMPT SMP
[  237.674537] Modules linked in: loop dm_thin_pool dm_persistent_data



Here is the same trace from my native  HW   Lenovo T61:

I'm suspecting new debug option:
 CONFIG_DEBUG_KOBJECT_RELEASE which I've recently enabled)

I've also noticed there are much older reports for this problem:
i.e. https://lkml.org/lkml/2013/3/9/3

I can trigger this bug very easily (makes 3.12-rc2 unusable for my desktop)


[  120.327263] bio: create slab  at 1
[  120.633731] bio: create slab  at 2
[  120.662856] BUG: unable to handle kernel NULL pointer dereference at 
0018

[  120.666137] IP: [] get_next_timer_interrupt+0x168/0x250
[  120.666137] PGD 0
[  120.666137] Oops:  [#1] PREEMPT SMP
[  120.666137] Modules linked in: dm_thin_pool dm_persistent_data dm_bufio 
dm_bio_prison dm_mod libcrc32c ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
xt_CHECKSUM iptable_mangle xt_tcpudp tun bridge stp llc ipv6 ip6_tables 
iptable_filter ip_tables ebtable_nat ebtables x_tables bnep btusb bluetooth 
hid_generic usbhid hid snd_hda_codec_analog arc4 iTCO_wdt iTCO_vendor_support 
coretemp iwl3945 kvm_intel iwlegacy kvm mac80211 snd_hda_intel snd_hda_codec 
snd_seq microcode snd_seq_device sdhci_pci r852 cfg80211 sm_common psmouse 
nand sdhci i2c_i801 e1000e nand_ecc snd_pcm nand_ids i2c_core serio_raw r592 
mmc_core mtd lpc_ich memstick mfd_core ptp snd_page_alloc snd_timer 
thinkpad_acpi pps_core wmi nvram snd soundcore evdev binfmt_misc nfsd 
auth_rpcgss oid_registry exportfs nfs_acl lockd loop sunrpc pcmcia sr_mod 
cdrom yenta_socket ehci_pci uhci_hcd ehci_hcd usbcore usb_common video 
backlight autofs4
[  120.666137] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 
3.12.0-rc2-00088-gfcbfc0d #163
[  120.666137] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 
03/18/2011
[  120.666137] task: 81a114c0 ti: 81a0 task.ti: 
81a0
[  120.666137] RIP: 0010:[]  [] 
get_next_timer_interrupt+0x168/0x250

[  120.666137] RSP: 0018:81a01e50  EFLAGS: 00010013
[  120.666137] RAX:  RBX: 2dd6 RCX: 
[  120.666137] RDX:  RSI: 81dfc508 RDI: 002e
[  120.666137] RBP: 81a01e98 R08: 0001 R09: 002e
[  120.666137] R10: 002e R11: 81dfc228 R12: 00013fff2dd5
[  120.666137] R13: 81dfb1c0 R14: 81a01e58 R15: 81a01e70
[  120.666137] FS:  () GS:88013720() 
knlGS:

[  120.666137] CS:  0010 DS:  ES:  CR0: 8005003b
[  120.666137] CR2: 0018 CR3: 0001341c3000 CR4: 07f0
[  120.666137] Stack:
[  120.666137]  81dfc228 81dfc628 81dfca28 
81dfce28
[  120.666137]   001c18108669 2dd6 
88013720d080
[  120.666137]  88013720de40 81a01f00 810bdce5 
001b31c77648

[  120.666137] Call Trace:
[  120.666137]  [] __tick_nohz_idle_enter+0x2e5/0x550
[  120.666137]  [] tick_nohz_idle_enter+0x41/0x70
[  120.666137]  [] cpu_startup_entry+0x3c/0x400
[  120.666137]  [] rest_init+0x132/0x140
[  120.666137]  [] ? rest_init+0x5/0x140
[  120.666137]  [] start_kernel+0x3c2/0x3cf
[  120.666137]  [] ? repair_env_string+0x5c/0x5c
[  120.666137]  [] x86_64_start_reservations+0x2a/0x2c
[  120.666137]  [] x86_64_start_kernel+0xf1/0xf4
[  120.666137] Code: 89 fa 41 83 e2 3f 45 89 d1 66 2e 0f 1f 84 00 00 00 00 00 
49 63 f1 48 c1 e6 04 4c 01 de 48 8b 06 48 39 f0 74 25 66 0f 1f 44 00 00  
40 18 01 75 11 48 8b 48 10 41 b8 01 00 00 00 48 39 d1 48 0f

[  120.666137] RIP  [] get_next_timer_interrupt+0x168/0x250
[  120.666137]  RSP 
[  120.666137] CR2: 0018
[  120.666137] ---[ end trace c4429f55908a7532 ]---
[  120.666137] Kernel panic - not syncing: Attempted to kill the idle task!
[  121.005821] BUG: spinlock lockup suspected on CPU#0, swapper/0/0
[  121.005821]  lock: boot_tvec_bases+0x0/0x2080, .magic: dead4ead, .owner: 
swapper/0/0, .owner_cpu: 0
[  121.005821] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G  D W 
3.12.0-rc2-00088-gfcbfc0d #163
[  121.005821] Hardware

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

[Zdenek Kabelac]

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: 4b97280675f45c1650ee4e388bd711ecbb18c4b4
(on top of that there are few minor unrelated patches)


[  235.631952] loop: module loaded
[  235.971853] bio: create slab  at 1
[  237.355014] bio: create slab  at 2
[  237.671371] BUG: unable to handle kernel NULL pointer dereference at 
0018

[  237.674537] IP: [] get_next_timer_interrupt+0x168/0x250
[  237.674537] PGD 16939067 PUD 14257067 PMD 0
[  237.674537] Oops:  [#1] PREEMPT SMP
[  237.674537] Modules linked in: loop dm_thin_pool dm_persistent_data 
dm_bufio dm_bio_prison libcrc32c nfsv4 nfs nfsd auth_rpcgss oid_registry 
exportfs nfs_acl lockd sunrpc autofs4 fuse dm_crypt dm_mod uhci_hcd ehci_hcd 
virtio_net serio_raw usbcore floppy i2c_piix4 i2c_core usb_common evdev
[  237.674537] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
3.12.0-rc2-00088-gfcbfc0d #163

[  237.674537] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  237.674537] task: 81a114c0 ti: 81a0 task.ti: 
81a0
[  237.674537] RIP: 0010:[]  [] 
get_next_timer_interrupt+0x168/0x250

[  237.674537] RSP: :81a01e50  EFLAGS: 00010013
[  237.674537] RAX:  RBX: b6f5 RCX: 0001
[  237.674537] RDX: 0001 RSI: 81dfc598 RDI: 00b7
[  237.674537] RBP: 81a01e98 R08: 0001 R09: 0037
[  237.674537] R10: 0037 R11: 81dfc228 R12: 00013fffb6f4
[  237.674537] R13: 81dfb1c0 R14: 81a01e58 R15: 81a01e70
[  237.674537] FS:  () GS:88001fc0() 
knlGS:

[  237.674537] CS:  0010 DS:  ES:  CR0: 8005003b
[  237.674537] CR2: 0018 CR3: 1c799000 CR4: 06f0
[  237.674537] Stack:
[  237.674537]  81dfc228 81dfc628 81dfca28 
81dfce28
[  237.674537]   0037564f1895 b6f5 
88001fc0d080
[  237.674537]  88001fc0de40 81a01f00 810bdce5 
002d6bc39000

[  237.674537] Call Trace:
[  237.674537]  [] __tick_nohz_idle_enter+0x2e5/0x550
[  237.674537]  [] tick_nohz_idle_enter+0x41/0x70
[  237.674537]  [] cpu_startup_entry+0x3c/0x400
[  237.674537]  [] rest_init+0x132/0x140
[  237.674537]  [] ? rest_init+0x5/0x140
[  237.674537]  [] start_kernel+0x3c2/0x3cf
[  237.674537]  [] ? repair_env_string+0x5c/0x5c
[  237.674537]  [] x86_64_start_reservations+0x2a/0x2c
[  237.674537]  [] x86_64_start_kernel+0xf1/0xf4
[  237.674537] Code: 89 fa 41 83 e2 3f 45 89 d1 66 2e 0f 1f 84 00 00 00 00 00 
49 63 f1 48 c1 e6 04 4c 01 de 48 8b 06 48 39 f0 74 25 66 0f 1f 44 00 00  
40 18 01 75 11 48 8b 48 10 41 b8 01 00 00 00 48 39 d1 48 0f

[  237.674537] RIP  [] get_next_timer_interrupt+0x168/0x250
[  237.674537]  RSP 
[  237.674537] CR2: 0018
[  237.674537] ---[ end trace 4cd6f72a56546bde ]---




Kernel config:


CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_RCU_FAST_NO_HZ=y
CONFIG_TREE_RCU_TRACE=y
CONFIG_IKCONFIG=m
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_MM_OWNER=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y

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

[Zdenek Kabelac]

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: 4b97280675f45c1650ee4e388bd711ecbb18c4b4
(on top of that there are few minor unrelated patches)


[  235.631952] loop: module loaded
[  235.971853] bio: create slab bio-1 at 1
[  237.355014] bio: create slab bio-2 at 2
[  237.671371] BUG: unable to handle kernel NULL pointer dereference at 
0018

[  237.674537] IP: [8105a008] get_next_timer_interrupt+0x168/0x250
[  237.674537] PGD 16939067 PUD 14257067 PMD 0
[  237.674537] Oops:  [#1] PREEMPT SMP
[  237.674537] Modules linked in: loop dm_thin_pool dm_persistent_data 
dm_bufio dm_bio_prison libcrc32c nfsv4 nfs nfsd auth_rpcgss oid_registry 
exportfs nfs_acl lockd sunrpc autofs4 fuse dm_crypt dm_mod uhci_hcd ehci_hcd 
virtio_net serio_raw usbcore floppy i2c_piix4 i2c_core usb_common evdev
[  237.674537] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
3.12.0-rc2-00088-gfcbfc0d #163

[  237.674537] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  237.674537] task: 81a114c0 ti: 81a0 task.ti: 
81a0
[  237.674537] RIP: 0010:[8105a008]  [8105a008] 
get_next_timer_interrupt+0x168/0x250

[  237.674537] RSP: :81a01e50  EFLAGS: 00010013
[  237.674537] RAX:  RBX: b6f5 RCX: 0001
[  237.674537] RDX: 0001 RSI: 81dfc598 RDI: 00b7
[  237.674537] RBP: 81a01e98 R08: 0001 R09: 0037
[  237.674537] R10: 0037 R11: 81dfc228 R12: 00013fffb6f4
[  237.674537] R13: 81dfb1c0 R14: 81a01e58 R15: 81a01e70
[  237.674537] FS:  () GS:88001fc0() 
knlGS:

[  237.674537] CS:  0010 DS:  ES:  CR0: 8005003b
[  237.674537] CR2: 0018 CR3: 1c799000 CR4: 06f0
[  237.674537] Stack:
[  237.674537]  81dfc228 81dfc628 81dfca28 
81dfce28
[  237.674537]   0037564f1895 b6f5 
88001fc0d080
[  237.674537]  88001fc0de40 81a01f00 810bdce5 
002d6bc39000

[  237.674537] Call Trace:
[  237.674537]  [810bdce5] __tick_nohz_idle_enter+0x2e5/0x550
[  237.674537]  [810bdf91] tick_nohz_idle_enter+0x41/0x70
[  237.674537]  [810ac89c] cpu_startup_entry+0x3c/0x400
[  237.674537]  [8158bce2] rest_init+0x132/0x140
[  237.674537]  [8158bbb5] ? rest_init+0x5/0x140
[  237.674537]  [81cb1e49] start_kernel+0x3c2/0x3cf
[  237.674537]  [81cb188f] ? repair_env_string+0x5c/0x5c
[  237.674537]  [81cb15a3] x86_64_start_reservations+0x2a/0x2c
[  237.674537]  [81cb1696] x86_64_start_kernel+0xf1/0xf4
[  237.674537] Code: 89 fa 41 83 e2 3f 45 89 d1 66 2e 0f 1f 84 00 00 00 00 00 
49 63 f1 48 c1 e6 04 4c 01 de 48 8b 06 48 39 f0 74 25 66 0f 1f 44 00 00 f6 
40 18 01 75 11 48 8b 48 10 41 b8 01 00 00 00 48 39 d1 48 0f

[  237.674537] RIP  [8105a008] get_next_timer_interrupt+0x168/0x250
[  237.674537]  RSP 81a01e50
[  237.674537] CR2: 0018
[  237.674537] ---[ end trace 4cd6f72a56546bde ]---




Kernel config:


CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_RCU_FAST_NO_HZ=y
CONFIG_TREE_RCU_TRACE=y
CONFIG_IKCONFIG=m
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_MM_OWNER=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y

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

[Zdenek Kabelac]

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 environment)
linux-vanilla git: 4b97280675f45c1650ee4e388bd711ecbb18c4b4
(on top of that there are few minor unrelated patches)


[  235.631952] loop: module loaded
[  235.971853] bio: create slab bio-1 at 1
[  237.355014] bio: create slab bio-2 at 2
[  237.671371] BUG: unable to handle kernel NULL pointer dereference at
0018
[  237.674537] IP: [8105a008] get_next_timer_interrupt+0x168/0x250
[  237.674537] PGD 16939067 PUD 14257067 PMD 0
[  237.674537] Oops:  [#1] PREEMPT SMP
[  237.674537] Modules linked in: loop dm_thin_pool dm_persistent_data



Here is the same trace from my native  HW   Lenovo T61:

I'm suspecting new debug option:
 CONFIG_DEBUG_KOBJECT_RELEASE which I've recently enabled)

I've also noticed there are much older reports for this problem:
i.e. https://lkml.org/lkml/2013/3/9/3

I can trigger this bug very easily (makes 3.12-rc2 unusable for my desktop)


[  120.327263] bio: create slab bio-1 at 1
[  120.633731] bio: create slab bio-2 at 2
[  120.662856] BUG: unable to handle kernel NULL pointer dereference at 
0018

[  120.666137] IP: [8105a008] get_next_timer_interrupt+0x168/0x250
[  120.666137] PGD 0
[  120.666137] Oops:  [#1] PREEMPT SMP
[  120.666137] Modules linked in: dm_thin_pool dm_persistent_data dm_bufio 
dm_bio_prison dm_mod libcrc32c ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
xt_CHECKSUM iptable_mangle xt_tcpudp tun bridge stp llc ipv6 ip6_tables 
iptable_filter ip_tables ebtable_nat ebtables x_tables bnep btusb bluetooth 
hid_generic usbhid hid snd_hda_codec_analog arc4 iTCO_wdt iTCO_vendor_support 
coretemp iwl3945 kvm_intel iwlegacy kvm mac80211 snd_hda_intel snd_hda_codec 
snd_seq microcode snd_seq_device sdhci_pci r852 cfg80211 sm_common psmouse 
nand sdhci i2c_i801 e1000e nand_ecc snd_pcm nand_ids i2c_core serio_raw r592 
mmc_core mtd lpc_ich memstick mfd_core ptp snd_page_alloc snd_timer 
thinkpad_acpi pps_core wmi nvram snd soundcore evdev binfmt_misc nfsd 
auth_rpcgss oid_registry exportfs nfs_acl lockd loop sunrpc pcmcia sr_mod 
cdrom yenta_socket ehci_pci uhci_hcd ehci_hcd usbcore usb_common video 
backlight autofs4
[  120.666137] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 
3.12.0-rc2-00088-gfcbfc0d #163
[  120.666137] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 
03/18/2011
[  120.666137] task: 81a114c0 ti: 81a0 task.ti: 
81a0
[  120.666137] RIP: 0010:[8105a008]  [8105a008] 
get_next_timer_interrupt+0x168/0x250

[  120.666137] RSP: 0018:81a01e50  EFLAGS: 00010013
[  120.666137] RAX:  RBX: 2dd6 RCX: 
[  120.666137] RDX:  RSI: 81dfc508 RDI: 002e
[  120.666137] RBP: 81a01e98 R08: 0001 R09: 002e
[  120.666137] R10: 002e R11: 81dfc228 R12: 00013fff2dd5
[  120.666137] R13: 81dfb1c0 R14: 81a01e58 R15: 81a01e70
[  120.666137] FS:  () GS:88013720() 
knlGS:

[  120.666137] CS:  0010 DS:  ES:  CR0: 8005003b
[  120.666137] CR2: 0018 CR3: 0001341c3000 CR4: 07f0
[  120.666137] Stack:
[  120.666137]  81dfc228 81dfc628 81dfca28 
81dfce28
[  120.666137]   001c18108669 2dd6 
88013720d080
[  120.666137]  88013720de40 81a01f00 810bdce5 
001b31c77648

[  120.666137] Call Trace:
[  120.666137]  [810bdce5] __tick_nohz_idle_enter+0x2e5/0x550
[  120.666137]  [810bdf91] tick_nohz_idle_enter+0x41/0x70
[  120.666137]  [810ac89c] cpu_startup_entry+0x3c/0x400
[  120.666137]  [8158bce2] rest_init+0x132/0x140
[  120.666137]  [8158bbb5] ? rest_init+0x5/0x140
[  120.666137]  [81cb1e49] start_kernel+0x3c2/0x3cf
[  120.666137]  [81cb188f] ? repair_env_string+0x5c/0x5c
[  120.666137]  [81cb15a3] x86_64_start_reservations+0x2a/0x2c
[  120.666137]  [81cb1696] x86_64_start_kernel+0xf1/0xf4
[  120.666137] Code: 89 fa 41 83 e2 3f 45 89 d1 66 2e 0f 1f 84 00 00 00 00 00 
49 63 f1 48 c1 e6 04 4c 01 de 48 8b 06 48 39 f0 74 25 66 0f 1f 44 00 00 f6 
40 18 01 75 11 48 8b 48 10 41 b8 01 00 00 00 48 39 d1 48 0f

[  120.666137] RIP  [8105a008] get_next_timer_interrupt+0x168/0x250
[  120.666137]  RSP 81a01e50
[  120.666137] CR2: 0018
[  120.666137] ---[ end trace c4429f55908a7532 ]---
[  120.666137] Kernel panic - not syncing: Attempted to kill the idle task!
[  121.005821] BUG: spinlock

kobject_add_internal failed for msi_irqs with -EEXIST

[Zdenek Kabelac]

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 sysfs_add_one+0xa5/0xd0()
sysfs: cannot create duplicate filename 
'/devices/pci:00/:00:19.0/msi_irqs'
Modules linked in: bnep btusb bluetooth iTCO_wdt iTCO_vendor_support 
snd_hda_codec_analog hid_generic coretemp kvm_intel kvm arc4 microcode psmouse 
serio_raw i2c_i801 i2c_core iwl3945 iwlegacy sdhci_pci usbhid mac80211 hid 
r852 sm_common nand nand_ecc r592 sdhci lpc_ich nand_ids mfd_core mmc_core mtd 
memstick cfg80211 snd_hda_intel snd_hda_codec snd_seq snd_seq_device wmi 
thinkpad_acpi snd_pcm nvram e1000e snd_page_alloc snd_timer snd evdev ptp 
soundcore pps_core nfsd auth_rpcgss oid_registry exportfs nfs_acl loop lockd 
binfmt_misc sunrpc pcmcia sr_mod cdrom yenta_socket ehci_pci ehci_hcd uhci_hcd 
usbcore usb_common video backlight autofs4

CPU: 0 PID: 301 Comm: NetworkManager Not tainted 3.12.0-rc2-00088-gfcbfc0d #163
Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
 0009 8800b85fb558 81595d57 8800b85fb5a0
 8800b85fb590 810491ad ffef 8800b79a8c80
 8800b85fb638 8800b87df000  8800b85fb5f0
Call Trace:
 [81595d57] dump_stack+0x4e/0x82
 [810491ad] warn_slowpath_common+0x7d/0xa0
 [8104921c] warn_slowpath_fmt+0x4c/0x50
 [812258c5] sysfs_add_one+0xa5/0xd0
 [81225a44] create_dir+0x74/0xd0
 [81225db9] sysfs_create_dir+0x89/0xe0
 [8132fba8] kobject_add_internal+0xc8/0x320
 [8134320d] ? __raw_spin_lock_init+0x2d/0x50
 [813302d0] kset_register+0x20/0x50
 [81330371] kset_create_and_add+0x71/0xb0
 [8136ce0a] populate_msi_sysfs+0x2a/0x120
 [8136d598] pci_enable_msi_block+0x1b8/0x2c0
 [a03493c5] e1000_open+0x225/0x5b0 [e1000e]
 [814db50f] __dev_open+0xbf/0x140
 [814db7d2] __dev_change_flags+0x92/0x170
 [814db95d] dev_change_flags+0x1d/0x60
 [814e9ff2] do_setlink+0x342/0xa00
 [8100ac94] ? native_sched_clock+0x24/0x80
 [8108c01f] ? local_clock+0x3f/0x50
 [8134dfb2] ? nla_parse+0x32/0xe0
 [814eb2df] rtnl_newlink+0x38f/0x5d0
 [8100ac94] ? native_sched_clock+0x24/0x80
 [810bf70f] ? trace_hardirqs_off_caller+0x1f/0xc0
 [814e814c] rtnetlink_rcv_msg+0x9c/0x260
 [81598447] ? mutex_lock_nested+0x2f7/0x440
 [814e808b] ? rtnetlink_rcv+0x1b/0x40
 [8108624d] ? get_parent_ip+0xd/0x50
 [814e808b] ? rtnetlink_rcv+0x1b/0x40
 [814e80b0] ? rtnetlink_rcv+0x40/0x40
 [81500279] netlink_rcv_skb+0xa9/0xc0
 [814e809a] rtnetlink_rcv+0x2a/0x40
 [814ff8bd] netlink_unicast+0xdd/0x190
 [814ffc99] netlink_sendmsg+0x329/0x750
 [8108c01f] ? local_clock+0x3f/0x50
 [81169e47] ? might_fault+0x57/0xb0
 [814bc5d8] sock_sendmsg+0xa8/0x180
 [81169e47] ? might_fault+0x57/0xb0
 [81169e90] ? might_fault+0xa0/0xb0
 [81169e47] ? might_fault+0x57/0xb0
 [814ca736] ? verify_iovec+0x56/0xd0
 [814bd05e] ___sys_sendmsg+0x35e/0x370
 [810c039d] ? lock_release_holdtime.part.29+0x9d/0x160
 [8108c01f] ? local_clock+0x3f/0x50
 [811c9bc2] ? fget_light+0xd2/0x4f0
 [8108624d] ? get_parent_ip+0xd/0x50
 [8108624d] ? get_parent_ip+0xd/0x50
 [815a2141] ? sub_preempt_count+0x71/0x100
 [810bfefe] ? put_lock_stats.isra.28+0xe/0x40
 [811c9bdf] ? fget_light+0xef/0x4f0
 [811c9b2c] ? fget_light+0x3c/0x4f0
 [814bd762] __sys_sendmsg+0x42/0x80
 [814bd7b2] SyS_sendmsg+0x12/0x20
 [815a6556] system_call_fastpath+0x1a/0x1f
---[ end trace 881f4293213af6b4 ]---
[ cut here ]
WARNING: CPU: 1 PID: 301 at lib/kobject.c:196 kobject_add_internal+0x204/0x320()
kobject_add_internal failed for msi_irqs with -EEXIST, don't try to register 
things with the same name in the same directory.
Modules linked in: bnep btusb bluetooth iTCO_wdt iTCO_vendor_support 
snd_hda_codec_analog hid_generic coretemp kvm_intel kvm arc4 microcode psmouse 
serio_raw i2c_i801 i2c_core iwl3945 iwlegacy sdhci_pci usbhid mac80211 hid 
r852 sm_common nand nand_ecc r592 sdhci lpc_ich nand_ids mfd_core mmc_core mtd 
memstick cfg80211 snd_hda_intel snd_hda_codec snd_seq snd_seq_device wmi 
thinkpad_acpi snd_pcm nvram e1000e snd_page_alloc snd_timer snd evdev ptp 
soundcore pps_core nfsd auth_rpcgss oid_registry exportfs nfs_acl loop lockd 
binfmt_misc sunrpc pcmcia sr_mod cdrom yenta_socket ehci_pci ehci_hcd uhci_hcd 
usbcore usb_common video backlight autofs4
CPU: 0 PID: 301 Comm: NetworkManager Tainted: GW 
3.12.0-rc2-00088-gfcbfc0d #163

Hardware name: LENOVO 6464CTO/6464CTO, 

Re: kobject_add_internal failed for msi_irqs with -EEXIST

[Zdenek Kabelac]

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:
(hw Lenovo T61, C2D, 4GB Ram)
(repost since linux-kernel@ rejected my gmail email)


This looks related to the MSI/kobject issues Veaceslav is working on.
See
http://lkml.kernel.org/r/1379382464-7920-2-git-send-email-vfal...@redhat.com
and related messages.

We don't have a resolution yet.  If you have
CONFIG_DEBUG_KOBJECT_RELEASE=y, you could try turning that off.  I
don't know if it would help, and it would only be a temporary
workaround anyway.


I've looked at the original post -
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg510798.html
hope that's it - and it seems that it's disabling DEBUG_KOBJECT_RELEASE
won't help - the warning is about the re-registering, not about freeing it.

As a workaround I'd suggest adding some kind of delay between removing and
adding the msi - as in - rmmod e1000e; sleep 1; modprobe e1000e; - or
something like that, so that there is enough time for the /msqi_irqs/ to go
away.



I'm not readding e1000e modules myself - however I've no idea what 
NetworkManager does. Here are messages prior warning:


NetworkManager[304]: info monitoring kernel firmware directory 
'/lib/firmware'.
NetworkManager[304]: info rfkill1: found WiFi radio killswitch (at 
/sys/devices/pci:00/:00:1c.1/:03:00.0/ieee80211/phy0/rfkill1) 
(driver iwl3945)

NetworkManager[304]: info WiFi hardware radio set enabled
NetworkManager[304]: info WiFi enabled by radio killswitch; enabled by state 
file
NetworkManager[304]: info WWAN enabled by radio killswitch; disabled by 
state file
NetworkManager[304]: info WiMAX enabled by radio killswitch; enabled by 
state file

NetworkManager[304]: info Networking is enabled by state file
NetworkManager[304]: info (eth0): carrier is OFF
NetworkManager[304]: info (eth0): new Ethernet device (driver: 'e1000e' 
ifindex: 2)
NetworkManager[304]: info (eth0): exported as 
/org/freedesktop/NetworkManager/Devices/0
NetworkManager[304]: info (eth0): device state change: unmanaged - 
unavailable (reason 'managed') [10 20 2]

NetworkManager[304]: info (eth0): bringing up device.
rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
kernel: [5.727025] WARNING! power/level is deprecated; use power/control 
instead



So it looks like  'bringing up' causes recreation of msi_irqs ?

Zdenek





--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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/platform/dock.0/undock

which works ok with 3.7 kernel - to properly undock my T61 before suspend.


Dmesg shows this:

[ 2657.087414] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: undocking
[ 2658.613494] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 2658.613508] ata4.00: ST_FIRST: !(DRQ|ERR|DF)
[ 2658.613522] sr 3:0:0:0: CDB:
[ 2658.613530] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
[ 2658.613583] ata4.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio
16392 in
   res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
[ 2658.613670] ata4: soft resetting link
[ 2658.766888] ata4.00: NODEV after polling detection
[ 2658.766900] ata4.00: revalidation failed (errno=-2)


Here is boot log attached, my HW is Lenovo T61, C2D




I've run 'bisect'  and found out commit which has broken  'undock' support on
my Lenovo:

commit 8ab0ab2570cfc48303e545944f53690a6983a898
Author: Toshi Kani 
Date:   Tue Oct 23 01:30:26 2012 +0200

  ACPI: dock: Remove redundant ACPI NS walk

  Combined two ACPI namespace walks, which look for dock stations
  and then bays separately, into a single walk.

  Signed-off-by: Toshi Kani 
  Reviewed-by: Yasuaki Ishimatsu 
  Signed-off-by: Rafael J. Wysocki 


After doin plain revert of this commit undock 'support' is back -
I've tested this with 3.9-rc1  (though on this kernel it seems wifi is
again horribly broken for now)

Any idea about proper fix here ?


Sorry for the trouble.  I suspect that your Lenovo has both doc station
and battery bay.  Since the above patch combined HW scans for doc
station and battery bay into a single scan, it may have changed
instance# of the sysfs "dock.%d" files on your Lenovo.  You can verify
the type by doing:

   cat /sys/devices/platform/dock*/type

dock.0 on your Lenovo likely shows as "battery_bay", which I think you
cannot undock regardless of this patch.  Can you try to undock the one
with "dock_station"?



Thanks - you are correct here - and I've not had though about that
before I've started bisect.

So while before this patch  dock.0 had type dock_station, it's now battery_bay 
and dock_station becomes dock.2 and I need to update my undocking script.


Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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/platform/dock.0/undock

which works ok with 3.7 kernel - to properly undock my T61 before suspend.


Dmesg shows this:

[ 2657.087414] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: undocking
[ 2658.613494] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 2658.613508] ata4.00: ST_FIRST: !(DRQ|ERR|DF)
[ 2658.613522] sr 3:0:0:0: CDB:
[ 2658.613530] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
[ 2658.613583] ata4.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio
16392 in
   res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
[ 2658.613670] ata4: soft resetting link
[ 2658.766888] ata4.00: NODEV after polling detection
[ 2658.766900] ata4.00: revalidation failed (errno=-2)


Here is boot log attached, my HW is Lenovo T61, C2D




I've run 'bisect'  and found out commit which has broken  'undock' support on
my Lenovo:

commit 8ab0ab2570cfc48303e545944f53690a6983a898
Author: Toshi Kani toshi.k...@hp.com
Date:   Tue Oct 23 01:30:26 2012 +0200

  ACPI: dock: Remove redundant ACPI NS walk

  Combined two ACPI namespace walks, which look for dock stations
  and then bays separately, into a single walk.

  Signed-off-by: Toshi Kani toshi.k...@hp.com
  Reviewed-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
  Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com


After doin plain revert of this commit undock 'support' is back -
I've tested this with 3.9-rc1  (though on this kernel it seems wifi is
again horribly broken for now)

Any idea about proper fix here ?


Sorry for the trouble.  I suspect that your Lenovo has both doc station
and battery bay.  Since the above patch combined HW scans for doc
station and battery bay into a single scan, it may have changed
instance# of the sysfs dock.%d files on your Lenovo.  You can verify
the type by doing:

   cat /sys/devices/platform/dock*/type

dock.0 on your Lenovo likely shows as battery_bay, which I think you
cannot undock regardless of this patch.  Can you try to undock the one
with dock_station?



Thanks - you are correct here - and I've not had though about that
before I've started bisect.

So while before this patch  dock.0 had type dock_station, it's now battery_bay 
and dock_station becomes dock.2 and I need to update my undocking script.


Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: iwl3945 prints warning

[Zdenek Kabelac]

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]: Started NFS file locking service..
[5.982624] NFSD: starting 90-second grace period (net 81aa08c0)
[5.987930] [ cut here ]
[5.988026] WARNING: at lib/dma-debug.c:933 check_unmap+0x4ae/0x9a0()
[5.988111] Hardware name: 6464CTO
[5.988194] iwl3945 :03:00.0: DMA-API: device driver failed
to check map error[device address=0xbb7a7800] [size=4096
bytes] [mapped as page]


We have to check dma_map_*() error. Fixing all of calls to dma_map* in
iwlegacy is not so simple. For now, you can just ignore this WARNING or
disable CONFIG_DMA_API_DEBUG.




I've now tested  3.9-rc1  and it seems to be getting even worse.
(and 3.8 is not really good either)

iwl3945 :03:00.0: Error sending C_RXON: time out after 500ms.
iwl3945 :03:00.0: Error setting new configuration (-110).
[ cut here ]
WARNING: at lib/dma-debug.c:883 check_unmap+0xfb/0x9a0()
Hardware name: 6464CTO
iwl3945 :03:00.0: DMA-API: device driver frees DMA memory with different 
size [device address=0xbb8e5000] [map size=80 bytes] [unmap size=21 bytes]
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge 
stp llc rfcomm bnep btusb bluetooth snd_hda_codec_analog arc4 iwl3945 iTCO_wdt 
iTCO_vendor_support iwlegacy mac80211 snd_hda_intel snd_hda_codec psmouse 
snd_seq serio_raw coretemp snd_seq_device microcode cfg80211 snd_pcm e1000e 
i2c_i801 r852 i2c_core sm_common nand ipv6 nand_ecc ptp nand_ids r592 mtd 
memstick snd_page_alloc ehci_pci ehci_hcd lpc_ich snd_timer pps_core mfd_core 
thinkpad_acpi nvram snd soundcore wmi evdev binfmt_misc loop vhost_net tun 
kvm_intel kvm nfsd exportfs auth_rpcgss nfs_acl lockd sunrpc dm_mod pcmcia 
sr_mod cdrom sdhci_pci yenta_socket sdhci mmc_core uhci_hcd usbcore usb_common 
video backlight autofs4

Pid: 50, comm: kworker/u:3 Not tainted 3.9.0-rc1-00114-gd356175 #144
Call Trace:
 [] warn_slowpath_common+0x70/0xa0
 [] warn_slowpath_fmt+0x4c/0x50
 [] check_unmap+0xfb/0x9a0
 [] debug_dma_unmap_page+0x5f/0x70
 [] il3945_hw_txq_free_tfd+0xc8/0x1f0 [iwl3945]
 [] il_tx_queue_unmap+0x46/0x60 [iwlegacy]
 [] il_tx_queue_free+0x3d/0x130 [iwlegacy]
 [] il3945_hw_txq_ctx_free+0x3d/0x80 [iwl3945]
 [] __il3945_down+0x308/0x330 [iwl3945]
 [] il3945_down+0x28/0x60 [iwl3945]
 [] il3945_bg_restart+0x99/0xb0 [iwl3945]
 [] process_one_work+0x1f6/0x690
 [] ? process_one_work+0x194/0x690
 [] worker_thread+0x115/0x3d0
 [] ? rescuer_thread+0x260/0x260
 [] kthread+0xde/0xf0
 [] ? insert_kthread_work+0x70/0x70
 [] ret_from_fork+0x7c/0xb0
 [] ? insert_kthread_work+0x70/0x70
---[ end trace af4ae3f2874322ec ]---
Mapped at:
 [] debug_dma_map_page+0x91/0x140
 [] il3945_mac_tx+0x404/0xa50 [iwl3945]
 [] __ieee80211_tx+0x121/0x3e0 [mac80211]
 [] ieee80211_tx+0xd8/0x100 [mac80211]
 [] ieee80211_xmit+0x8b/0xb0 [mac80211]
ieee80211 phy0: Hardware restart was requested
Ebtables v2.0 registered


Meanwhile  Network manager is getting confused

 iwl3945 :03:00.0: Microcode SW error detected. Restarting 0x8208.
 iwl3945 :03:00.0: Loaded firmware version: 15.32.2.9
 iwl3945 :03:00.0: Start IWL Error Log Dump:
 iwl3945 :03:00.0: Status: 0x000202E4, count: 1
 iwl3945 :03:00.0: Desc   Time   asrtPC  blink2 ilink1  nmiPC   Line
 iwl3945 :03:00.0: SYSASSERT (0x5) 201255 0x008B6 0x00274 0x00320 
0x04CA6 116


 iwl3945 :03:00.0: Error Reply type 0x0005 cmd C_TX (0x1C) seq 0x 
ser 0x0074

 iwl3945 :03:00.0: Error: Response NULL in 'C_ADD_STA'
 iwl3945 :03:00.0: Adding station ff:ff:ff:ff:ff:ff failed.
 iwl3945 :03:00.0: Error setting Tx power (-5).
 iwl3945 :03:00.0: Can't stop Rx DMA.
 ieee80211 phy0: Hardware restart was requested


And driver is effectively unusable - since it's just restarting

Also 'state' of iwl3945 in  3.8 is quite 'far' from stable as well.
quite often I can see, that I'm disconnected from AP, and while
network manager shows other 'visible' AP available for connection,
my home AP is not listed anymore - and to see it again I'd to switch
wifi support on/off - just after this I'd reattach to my home AP - so quite 
annoying - and major reason to stay with 3.7 kernel for stable wifi.


Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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.


Dmesg shows this:

[ 2657.087414] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: undocking
[ 2658.613494] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 2658.613508] ata4.00: ST_FIRST: !(DRQ|ERR|DF)
[ 2658.613522] sr 3:0:0:0: CDB:
[ 2658.613530] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
[ 2658.613583] ata4.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio
16392 in
  res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
[ 2658.613670] ata4: soft resetting link
[ 2658.766888] ata4.00: NODEV after polling detection
[ 2658.766900] ata4.00: revalidation failed (errno=-2)


Here is boot log attached, my HW is Lenovo T61, C2D




I've run 'bisect'  and found out commit which has broken  'undock' support on
my Lenovo:

commit 8ab0ab2570cfc48303e545944f53690a6983a898
Author: Toshi Kani 
Date:   Tue Oct 23 01:30:26 2012 +0200

ACPI: dock: Remove redundant ACPI NS walk

Combined two ACPI namespace walks, which look for dock stations
and then bays separately, into a single walk.

Signed-off-by: Toshi Kani 
Reviewed-by: Yasuaki Ishimatsu 
Signed-off-by: Rafael J. Wysocki 


After doin plain revert of this commit undock 'support' is back -
I've tested this with 3.9-rc1  (though on this kernel it seems wifi is
again horribly broken for now)

Any idea about proper fix here ?

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Zdenek Kabelac]

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.


Dmesg shows this:

[ 2657.087414] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: undocking
[ 2658.613494] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 2658.613508] ata4.00: ST_FIRST: !(DRQ|ERR|DF)
[ 2658.613522] sr 3:0:0:0: CDB:
[ 2658.613530] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
[ 2658.613583] ata4.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio
16392 in
  res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
[ 2658.613670] ata4: soft resetting link
[ 2658.766888] ata4.00: NODEV after polling detection
[ 2658.766900] ata4.00: revalidation failed (errno=-2)


Here is boot log attached, my HW is Lenovo T61, C2D




I've run 'bisect'  and found out commit which has broken  'undock' support on
my Lenovo:

commit 8ab0ab2570cfc48303e545944f53690a6983a898
Author: Toshi Kani toshi.k...@hp.com
Date:   Tue Oct 23 01:30:26 2012 +0200

ACPI: dock: Remove redundant ACPI NS walk

Combined two ACPI namespace walks, which look for dock stations
and then bays separately, into a single walk.

Signed-off-by: Toshi Kani toshi.k...@hp.com
Reviewed-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com


After doin plain revert of this commit undock 'support' is back -
I've tested this with 3.9-rc1  (though on this kernel it seems wifi is
again horribly broken for now)

Any idea about proper fix here ?

Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: iwl3945 prints warning

[Zdenek Kabelac]

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]: Started NFS file locking service..
[5.982624] NFSD: starting 90-second grace period (net 81aa08c0)
[5.987930] [ cut here ]
[5.988026] WARNING: at lib/dma-debug.c:933 check_unmap+0x4ae/0x9a0()
[5.988111] Hardware name: 6464CTO
[5.988194] iwl3945 :03:00.0: DMA-API: device driver failed
to check map error[device address=0xbb7a7800] [size=4096
bytes] [mapped as page]


We have to check dma_map_*() error. Fixing all of calls to dma_map* in
iwlegacy is not so simple. For now, you can just ignore this WARNING or
disable CONFIG_DMA_API_DEBUG.




I've now tested  3.9-rc1  and it seems to be getting even worse.
(and 3.8 is not really good either)

iwl3945 :03:00.0: Error sending C_RXON: time out after 500ms.
iwl3945 :03:00.0: Error setting new configuration (-110).
[ cut here ]
WARNING: at lib/dma-debug.c:883 check_unmap+0xfb/0x9a0()
Hardware name: 6464CTO
iwl3945 :03:00.0: DMA-API: device driver frees DMA memory with different 
size [device address=0xbb8e5000] [map size=80 bytes] [unmap size=21 bytes]
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge 
stp llc rfcomm bnep btusb bluetooth snd_hda_codec_analog arc4 iwl3945 iTCO_wdt 
iTCO_vendor_support iwlegacy mac80211 snd_hda_intel snd_hda_codec psmouse 
snd_seq serio_raw coretemp snd_seq_device microcode cfg80211 snd_pcm e1000e 
i2c_i801 r852 i2c_core sm_common nand ipv6 nand_ecc ptp nand_ids r592 mtd 
memstick snd_page_alloc ehci_pci ehci_hcd lpc_ich snd_timer pps_core mfd_core 
thinkpad_acpi nvram snd soundcore wmi evdev binfmt_misc loop vhost_net tun 
kvm_intel kvm nfsd exportfs auth_rpcgss nfs_acl lockd sunrpc dm_mod pcmcia 
sr_mod cdrom sdhci_pci yenta_socket sdhci mmc_core uhci_hcd usbcore usb_common 
video backlight autofs4

Pid: 50, comm: kworker/u:3 Not tainted 3.9.0-rc1-00114-gd356175 #144
Call Trace:
 [81040440] warn_slowpath_common+0x70/0xa0
 [810404bc] warn_slowpath_fmt+0x4c/0x50
 [8133922b] check_unmap+0xfb/0x9a0
 [81339b2f] debug_dma_unmap_page+0x5f/0x70
 [a05a3108] il3945_hw_txq_free_tfd+0xc8/0x1f0 [iwl3945]
 [a04b02a6] il_tx_queue_unmap+0x46/0x60 [iwlegacy]
 [a04b435d] il_tx_queue_free+0x3d/0x130 [iwlegacy]
 [a05a366d] il3945_hw_txq_ctx_free+0x3d/0x80 [iwl3945]
 [a059e6b8] __il3945_down+0x308/0x330 [iwl3945]
 [a059e708] il3945_down+0x28/0x60 [iwl3945]
 [a059eb09] il3945_bg_restart+0x99/0xb0 [iwl3945]
 [81064486] process_one_work+0x1f6/0x690
 [81064424] ? process_one_work+0x194/0x690
 [81064c95] worker_thread+0x115/0x3d0
 [81064b80] ? rescuer_thread+0x260/0x260
 [8106e8ce] kthread+0xde/0xf0
 [8106e7f0] ? insert_kthread_work+0x70/0x70
 [8157eedc] ret_from_fork+0x7c/0xb0
 [8106e7f0] ? insert_kthread_work+0x70/0x70
---[ end trace af4ae3f2874322ec ]---
Mapped at:
 [813385b1] debug_dma_map_page+0x91/0x140
 [a059fde4] il3945_mac_tx+0x404/0xa50 [iwl3945]
 [a0528e81] __ieee80211_tx+0x121/0x3e0 [mac80211]
 [a052b458] ieee80211_tx+0xd8/0x100 [mac80211]
 [a052b81b] ieee80211_xmit+0x8b/0xb0 [mac80211]
ieee80211 phy0: Hardware restart was requested
Ebtables v2.0 registered


Meanwhile  Network manager is getting confused

 iwl3945 :03:00.0: Microcode SW error detected. Restarting 0x8208.
 iwl3945 :03:00.0: Loaded firmware version: 15.32.2.9
 iwl3945 :03:00.0: Start IWL Error Log Dump:
 iwl3945 :03:00.0: Status: 0x000202E4, count: 1
 iwl3945 :03:00.0: Desc   Time   asrtPC  blink2 ilink1  nmiPC   Line
 iwl3945 :03:00.0: SYSASSERT (0x5) 201255 0x008B6 0x00274 0x00320 
0x04CA6 116


 iwl3945 :03:00.0: Error Reply type 0x0005 cmd C_TX (0x1C) seq 0x 
ser 0x0074

 iwl3945 :03:00.0: Error: Response NULL in 'C_ADD_STA'
 iwl3945 :03:00.0: Adding station ff:ff:ff:ff:ff:ff failed.
 iwl3945 :03:00.0: Error setting Tx power (-5).
 iwl3945 :03:00.0: Can't stop Rx DMA.
 ieee80211 phy0: Hardware restart was requested


And driver is effectively unusable - since it's just restarting

Also 'state' of iwl3945 in  3.8 is quite 'far' from stable as well.
quite often I can see, that I'm disconnected from AP, and while
network manager shows other 'visible' AP available for connection,
my home AP is not listed anymore - and to see it again I'd to switch
wifi support on/off - just after this I'd reattach to my home AP - so quite 
annoying - and major

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

[Zdenek Kabelac]

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: \_SB_.PCI0.LPC_.EC__.BAT1: undocking
[ 2658.613494] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 2658.613508] ata4.00: ST_FIRST: !(DRQ|ERR|DF)
[ 2658.613522] sr 3:0:0:0: CDB:
[ 2658.613530] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
[ 2658.613583] ata4.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 
in
 res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
[ 2658.613670] ata4: soft resetting link
[ 2658.766888] ata4.00: NODEV after polling detection
[ 2658.766900] ata4.00: revalidation failed (errno=-2)


Here is boot log attached, my HW is Lenovo T61, C2D


Zdenek


boot log:

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.8.0-rc5-6-g0e5e62f (@linux) (gcc version 4.8.0 20130124 
(Red Hat 4.8.0-0.6) (GCC) ) #119 SMP PREEMPT Mon Jan 28 14:36:02 CET 2013
Command line: ro root=/dev/sda2 selinux=0 intel_iommu=on kmemleak=off 
lockdep.prove_locking=0 lockdep.lock_stat=0 SYSFONT=latarcyrheb-sun16 
LANG=cs_CZ.UTF-8 KEYTABLE=us systemd.log_level=info systemd.log_target=kmsg 
ipv6.disable=1

e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009d7ff] usable
BIOS-e820: [mem 0x0009d800-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbf6a] usable
BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
BIOS-e820: [mem 0xbf70-0xbfff] reserved
BIOS-e820: [mem 0xf000-0xf3ff] reserved
BIOS-e820: [mem 0xfec0-0xfec0] reserved
BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xff00-0x] reserved
BIOS-e820: [mem 0x0001-0x00013bff] usable
kmemleak: Kernel memory leak detector disabled
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
DMI: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
e820: update [mem 0x-0x] usable ==> reserved
e820: remove [mem 0x000a-0x000f] usable
No AGP bridge found
e820: last_pfn = 0x13c000 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C write-protect
  D-D uncachable
  E-F write-protect
MTRR variable ranges enabled:
  0 base 0C000 mask FC000 uncachable
  1 base 13C00 mask FFC00 uncachable
  2 base 0 mask F write-back
  3 base 1 mask FC000 write-back
  4 base 0BF70 mask 0 uncachable
  5 base 0BF80 mask FFF80 uncachable
  6 disabled
  7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 3GB, range: 1GB, type UC
reg 1, base: 5056MB, range: 64MB, type UC
reg 2, base: 0GB, range: 4GB, type WB
reg 3, base: 4GB, range: 1GB, type WB
reg 4, base: 3063MB, range: 1MB, type UC
reg 5, base: 3064MB, range: 8MB, type UC
total RAM covered: 4023M
Found optimal setting for mtrr clean up
 gran_size: 64K chunk_size: 128Mnum_reg: 6  lose cover RAM: 
0G
New variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 2GB, range: 1GB, type WB
reg 2, base: 3063MB, range: 1MB, type UC
reg 3, base: 3064MB, range: 8MB, type UC
reg 4, base: 4GB, range: 1GB, type WB
reg 5, base: 5056MB, range: 64MB, type UC
e820: update [mem 0xbf70-0x] usable ==> reserved
e820: last_pfn = 0xbf6b0 max_arch_pfn = 0x4
found SMP MP-table at [mem 0x000f68f0-0x000f68ff] mapped at [880f68f0]
initial memory mapped: [mem 0x-0x1fff]
Base memory trampoline at [88097000] 97000 size 24576
init_memory_mapping: [mem 0x-0xbf6a]
 [mem 0x-0xbf5f] page 2M
 [mem 0xbf60-0xbf6a] page 4k
kernel direct mapping tables up to 0xbf6a @ [mem 0x1fffb000-0x1fff]
init_memory_mapping: [mem 0x1-0x13bff]
 [mem 0x1-0x13bff] page 2M
kernel direct mapping tables up to 0x13bff @ [mem 0xbf6ae000-0xbf6a]
RAMDISK: [mem 0x37824000-0x37fe]
ACPI: RSDP 000f68c0 00024 (v02 LENOVO)
ACPI: XSDT bf6bb496 0009C (v01 LENOVO TP-7U2290  LTP )
ACPI: FACP bf6bb600 000F4 (v03 LENOVO TP-7U2290 LNVO 0001)
ACPI BIOS Bug: Warning: 32/64X length mismatch in FADT/Gpe1Block: 0/32 
(20121018/tbfadt-567)

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

[Zdenek Kabelac]

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: \_SB_.PCI0.LPC_.EC__.BAT1: undocking
[ 2658.613494] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 2658.613508] ata4.00: ST_FIRST: !(DRQ|ERR|DF)
[ 2658.613522] sr 3:0:0:0: CDB:
[ 2658.613530] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
[ 2658.613583] ata4.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 
in
 res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
[ 2658.613670] ata4: soft resetting link
[ 2658.766888] ata4.00: NODEV after polling detection
[ 2658.766900] ata4.00: revalidation failed (errno=-2)


Here is boot log attached, my HW is Lenovo T61, C2D


Zdenek


boot log:

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.8.0-rc5-6-g0e5e62f (@linux) (gcc version 4.8.0 20130124 
(Red Hat 4.8.0-0.6) (GCC) ) #119 SMP PREEMPT Mon Jan 28 14:36:02 CET 2013
Command line: ro root=/dev/sda2 selinux=0 intel_iommu=on kmemleak=off 
lockdep.prove_locking=0 lockdep.lock_stat=0 SYSFONT=latarcyrheb-sun16 
LANG=cs_CZ.UTF-8 KEYTABLE=us systemd.log_level=info systemd.log_target=kmsg 
ipv6.disable=1

e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009d7ff] usable
BIOS-e820: [mem 0x0009d800-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbf6a] usable
BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
BIOS-e820: [mem 0xbf70-0xbfff] reserved
BIOS-e820: [mem 0xf000-0xf3ff] reserved
BIOS-e820: [mem 0xfec0-0xfec0] reserved
BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xff00-0x] reserved
BIOS-e820: [mem 0x0001-0x00013bff] usable
kmemleak: Kernel memory leak detector disabled
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
DMI: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011
e820: update [mem 0x-0x] usable == reserved
e820: remove [mem 0x000a-0x000f] usable
No AGP bridge found
e820: last_pfn = 0x13c000 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C write-protect
  D-D uncachable
  E-F write-protect
MTRR variable ranges enabled:
  0 base 0C000 mask FC000 uncachable
  1 base 13C00 mask FFC00 uncachable
  2 base 0 mask F write-back
  3 base 1 mask FC000 write-back
  4 base 0BF70 mask 0 uncachable
  5 base 0BF80 mask FFF80 uncachable
  6 disabled
  7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 3GB, range: 1GB, type UC
reg 1, base: 5056MB, range: 64MB, type UC
reg 2, base: 0GB, range: 4GB, type WB
reg 3, base: 4GB, range: 1GB, type WB
reg 4, base: 3063MB, range: 1MB, type UC
reg 5, base: 3064MB, range: 8MB, type UC
total RAM covered: 4023M
Found optimal setting for mtrr clean up
 gran_size: 64K chunk_size: 128Mnum_reg: 6  lose cover RAM: 
0G
New variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 2GB, range: 1GB, type WB
reg 2, base: 3063MB, range: 1MB, type UC
reg 3, base: 3064MB, range: 8MB, type UC
reg 4, base: 4GB, range: 1GB, type WB
reg 5, base: 5056MB, range: 64MB, type UC
e820: update [mem 0xbf70-0x] usable == reserved
e820: last_pfn = 0xbf6b0 max_arch_pfn = 0x4
found SMP MP-table at [mem 0x000f68f0-0x000f68ff] mapped at [880f68f0]
initial memory mapped: [mem 0x-0x1fff]
Base memory trampoline at [88097000] 97000 size 24576
init_memory_mapping: [mem 0x-0xbf6a]
 [mem 0x-0xbf5f] page 2M
 [mem 0xbf60-0xbf6a] page 4k
kernel direct mapping tables up to 0xbf6a @ [mem 0x1fffb000-0x1fff]
init_memory_mapping: [mem 0x1-0x13bff]
 [mem 0x1-0x13bff] page 2M
kernel direct mapping tables up to 0x13bff @ [mem 0xbf6ae000-0xbf6a]
RAMDISK: [mem 0x37824000-0x37fe]
ACPI: RSDP 000f68c0 00024 (v02 LENOVO)
ACPI: XSDT bf6bb496 0009C (v01 LENOVO TP-7U2290  LTP )
ACPI: FACP bf6bb600 000F4 (v03 LENOVO TP-7U2290 LNVO 0001)
ACPI BIOS Bug: Warning: 32/64X length mismatch in FADT/Gpe1Block: 0/32 
(20121018/tbfadt-567)

iwl3945 prints warning

[Zdenek Kabelac]

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 81aa08c0)
[5.987930] [ cut here ]
[5.988026] WARNING: at lib/dma-debug.c:933 check_unmap+0x4ae/0x9a0()
[5.988111] Hardware name: 6464CTO
[5.988194] iwl3945 :03:00.0: DMA-API: device driver failed to check 
map error[device address=0xbb7a7800] [size=4096 bytes] [mapped as page]

[5.988286] Modules linked in:
[5.988411]  rfcomm bnep btusb bluetooth snd_hda_codec_analog iTCO_wdt 
iTCO_vendor_support arc4 hid_generic iwl3945 iwlegacy mac80211 snd_hda_intel 
snd_hda_codec coretemp snd_seq psmouse i2c_i801 serio_raw microcode i2c_core 
snd_seq_device r852 sm_common cfg80211 nand snd_pcm nand_ecc r592 nand_ids mtd 
memstick lpc_ich mfd_core e1000e thinkpad_acpi snd_page_alloc ehci_pci 
snd_timer ehci_hcd nvram wmi snd soundcore evdev binfmt_misc usbhid hid loop 
vhost_net tun kvm_intel kvm nfsd exportfs auth_rpcgss nfs_acl lockd sunrpc 
dm_mod pcmcia sr_mod cdrom sdhci_pci sdhci mmc_core yenta_socket uhci_hcd 
usbcore usb_common video backlight autofs4

[5.992114] Pid: 635, comm: libvirtd Not tainted 3.8.0-rc5-6-g0e5e62f 
#119
[5.992177] Call Trace:
[5.992177][] warn_slowpath_common+0x70/0xa0
[5.992177]  [] warn_slowpath_fmt+0x4c/0x50
[5.992177]  [] check_unmap+0x4ae/0x9a0
[5.992177]  [] debug_dma_unmap_page+0x5f/0x70
[5.992177]  [] ? unmap_single+0x20/0x30
[5.992177]  [] il3945_irq_tasklet+0x392/0x710 [iwl3945]
[5.992177]  [] tasklet_action+0x98/0x220
[5.992177]  [] __do_softirq+0xdf/0x3f0
[5.992177]  [] call_softirq+0x1c/0x30
[5.992177]  [] do_softirq+0x65/0xa0
[5.992177]  [] irq_exit+0xc5/0xd0
[5.992177]  [] do_IRQ+0x56/0xc0
[5.992177]  [] ? __do_page_fault+0x20c/0x5b0
[5.992177]  [] common_interrupt+0x6f/0x6f
[5.992177][] ? lock_release+0xae/0x300
[5.992177]  [] up_read+0x1f/0x40
[5.992177]  [] __do_page_fault+0x20c/0x5b0
[5.992177]  [] ? trace_hardirqs_on_caller+0x115/0x1a0
[5.992177]  [] ? error_sti+0x5/0x6
[5.992177]  [] ? trace_hardirqs_off_thunk+0x3a/0x3c
[5.992177]  [] do_page_fault+0xe/0x10
[5.992177]  [] page_fault+0x22/0x30
[5.992177] ---[ end trace c0d06cdbbf41cb39 ]---
[5.992177] Mapped at:
[5.992177]  [] debug_dma_map_page+0x91/0x140
[5.992177]  [] il3945_rx_allocate+0xaa/0x270 [iwl3945]
[5.992177]  [] il3945_rx_replenish+0x1b/0x50 [iwl3945]
[5.992177]  [] il3945_hw_nic_init+0x1a1/0x5e0 [iwl3945]
[5.992177]  [] __il3945_up+0xc0/0x2d0 [iwl3945]


Zdenek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

iwl3945 prints warning

[Zdenek Kabelac]

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 81aa08c0)
[5.987930] [ cut here ]
[5.988026] WARNING: at lib/dma-debug.c:933 check_unmap+0x4ae/0x9a0()
[5.988111] Hardware name: 6464CTO
[5.988194] iwl3945 :03:00.0: DMA-API: device driver failed to check 
map error[device address=0xbb7a7800] [size=4096 bytes] [mapped as page]

[5.988286] Modules linked in:
[5.988411]  rfcomm bnep btusb bluetooth snd_hda_codec_analog iTCO_wdt 
iTCO_vendor_support arc4 hid_generic iwl3945 iwlegacy mac80211 snd_hda_intel 
snd_hda_codec coretemp snd_seq psmouse i2c_i801 serio_raw microcode i2c_core 
snd_seq_device r852 sm_common cfg80211 nand snd_pcm nand_ecc r592 nand_ids mtd 
memstick lpc_ich mfd_core e1000e thinkpad_acpi snd_page_alloc ehci_pci 
snd_timer ehci_hcd nvram wmi snd soundcore evdev binfmt_misc usbhid hid loop 
vhost_net tun kvm_intel kvm nfsd exportfs auth_rpcgss nfs_acl lockd sunrpc 
dm_mod pcmcia sr_mod cdrom sdhci_pci sdhci mmc_core yenta_socket uhci_hcd 
usbcore usb_common video backlight autofs4

[5.992114] Pid: 635, comm: libvirtd Not tainted 3.8.0-rc5-6-g0e5e62f 
#119
[5.992177] Call Trace:
[5.992177]  IRQ  [8103fcd0] warn_slowpath_common+0x70/0xa0
[5.992177]  [8103fd4c] warn_slowpath_fmt+0x4c/0x50
[5.992177]  [8132e18e] check_unmap+0x4ae/0x9a0
[5.992177]  [8132e6df] debug_dma_unmap_page+0x5f/0x70
[5.992177]  [81329b50] ? unmap_single+0x20/0x30
[5.992177]  [a05584b2] il3945_irq_tasklet+0x392/0x710 [iwl3945]
[5.992177]  [810498e8] tasklet_action+0x98/0x220
[5.992177]  [8104a10f] __do_softirq+0xdf/0x3f0
[5.992177]  [8156adcc] call_softirq+0x1c/0x30
[5.992177]  [810045f5] do_softirq+0x65/0xa0
[5.992177]  [8104a5d5] irq_exit+0xc5/0xd0
[5.992177]  [8156b486] do_IRQ+0x56/0xc0
[5.992177]  [81564ffc] ? __do_page_fault+0x20c/0x5b0
[5.992177]  [81561def] common_interrupt+0x6f/0x6f
[5.992177]  EOI  [810b1a9e] ? lock_release+0xae/0x300
[5.992177]  [81073aef] up_read+0x1f/0x40
[5.992177]  [81564ffc] __do_page_fault+0x20c/0x5b0
[5.992177]  [810af0b5] ? trace_hardirqs_on_caller+0x115/0x1a0
[5.992177]  [815622e3] ? error_sti+0x5/0x6
[5.992177]  [8131c1cd] ? trace_hardirqs_off_thunk+0x3a/0x3c
[5.992177]  [815653ae] do_page_fault+0xe/0x10
[5.992177]  [815620e2] page_fault+0x22/0x30
[5.992177] ---[ end trace c0d06cdbbf41cb39 ]---
[5.992177] Mapped at:
[5.992177]  [8132eab1] debug_dma_map_page+0x91/0x140
[5.992177]  [a0fa] il3945_rx_allocate+0xaa/0x270 [iwl3945]
[5.992177]  [a0558efb] il3945_rx_replenish+0x1b/0x50 [iwl3945]
[5.992177]  [a055b4b1] il3945_hw_nic_init+0x1a1/0x5e0 [iwl3945]
[5.992177]  [a0556790] __il3945_up+0xc0/0x2d0 [iwl3945]


Zdenek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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
bigger page cache by reading a big file and thus use the unused 1GB of RAM,
kswapd will soon (in a matter of minutes) evict those (or other) pages out and
once again keep unused memory close to 1GB.


Ok, guys, what was the reclaim or kswapd patch during the merge window
that actually caused all of these insane problems? It seems it was more
fundamentally buggered than the fifteen-million fixes for kswapd we have
already picked up.

(Ok, I may be exaggerating the number of patches, but it's starting to
feel that way - I thought that 3.7 was going to be a calm and easy
release, but the kswapd issues seem to just keep happening. We've been
fighting the kswapd changes for a while now.)

Trying to keep a gigabyte free (presumably because that way we have lots
of high-order alloction pages) is ridiculous. Is it one of the compaction
changes?

Mel? Ideas?



Very true

It's just as simple a making

dd if=/dev/zero of=/tmp/zero bs=1M count=0 seek=100

and now

dd if=/tmp/zero of=/dev/null bs=1M

and kswapd fights with dd  for CPU time


Zdenek


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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
bigger page cache by reading a big file and thus use the unused 1GB of RAM,
kswapd will soon (in a matter of minutes) evict those (or other) pages out and
once again keep unused memory close to 1GB.


Ok, guys, what was the reclaim or kswapd patch during the merge window
that actually caused all of these insane problems? It seems it was more
fundamentally buggered than the fifteen-million fixes for kswapd we have
already picked up.

(Ok, I may be exaggerating the number of patches, but it's starting to
feel that way - I thought that 3.7 was going to be a calm and easy
release, but the kswapd issues seem to just keep happening. We've been
fighting the kswapd changes for a while now.)

Trying to keep a gigabyte free (presumably because that way we have lots
of high-order alloction pages) is ridiculous. Is it one of the compaction
changes?

Mel? Ideas?



Very true

It's just as simple a making

dd if=/dev/zero of=/tmp/zero bs=1M count=0 seek=100

and now

dd if=/tmp/zero of=/dev/null bs=1M

and kswapd fights with dd  for CPU time


Zdenek


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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
shown kswapd0 for couple minutes on CPU.

It seemed to go instantly away when I've drop caches
(echo 3 >/proc/sys/vm/drop_cache)
(After that I've had over 1G free memory)


Any chance you could retry with this patch on top?

---
From: Johannes Weiner 
Subject: [patch] mm: vmscan: do not keep kswapd looping forever due
  to individual uncompactable zones

---
  mm/vmscan.c | 16 
  1 file changed, 16 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c



Ok, I'm running now b69f0859dc8e633c5d8c06845811588fe17e68b3 (-rc8)
with your patch.  I'll be able to give some feedback after couple
days (if I keep my machine running without reboot - since before


So to just give some positive info -

with  2 1/2 day uptime, several suspend/resumes, ff at 1.4GB
I still have just 29 seconds for kswapd0 process.

So the patch above might have helped - but I'll look for a few more days.

Zdenek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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
shown kswapd0 for couple minutes on CPU.

It seemed to go instantly away when I've drop caches
(echo 3 /proc/sys/vm/drop_cache)
(After that I've had over 1G free memory)


Any chance you could retry with this patch on top?

---
From: Johannes Weiner han...@cmpxchg.org
Subject: [patch] mm: vmscan: do not keep kswapd looping forever due
  to individual uncompactable zones

---
  mm/vmscan.c | 16 
  1 file changed, 16 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c



Ok, I'm running now b69f0859dc8e633c5d8c06845811588fe17e68b3 (-rc8)
with your patch.  I'll be able to give some feedback after couple
days (if I keep my machine running without reboot - since before


So to just give some positive info -

with  2 1/2 day uptime, several suspend/resumes, ff at 1.4GB
I still have just 29 seconds for kswapd0 process.

So the patch above might have helped - but I'll look for a few more days.

Zdenek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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.

It seemed to go instantly away when I've drop caches
(echo 3 >/proc/sys/vm/drop_cache)
(After that I've had over 1G free memory)


Any chance you could retry with this patch on top?

---
From: Johannes Weiner 
Subject: [patch] mm: vmscan: do not keep kswapd looping forever due
  to individual uncompactable zones

---
  mm/vmscan.c | 16 
  1 file changed, 16 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c



Ok, I'm running now b69f0859dc8e633c5d8c06845811588fe17e68b3 (-rc8)
with your patch.  I'll be able to give some feedback after couple
days (if I keep my machine running without reboot - since before
I had occasional problems with ACPI now resolved.
(https://bugzilla.kernel.org/show_bug.cgi?id=51071)
(patch not yet in -rc8)
I'm also using this extra patch: https://patchwork.kernel.org/patch/1792531/

What seems to be triggering condition on my machine - running laptop for some 
days - and having   Thunderbird reaching 0.8G (I guess they must keep all my 
news messages in memory to consume that size) and Firefox 1.3GB of consumed

memory (assuming massive leaking with combination of flash)

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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.

It seemed to go instantly away when I've drop caches
(echo 3 /proc/sys/vm/drop_cache)
(After that I've had over 1G free memory)


Any chance you could retry with this patch on top?

---
From: Johannes Weiner han...@cmpxchg.org
Subject: [patch] mm: vmscan: do not keep kswapd looping forever due
  to individual uncompactable zones

---
  mm/vmscan.c | 16 
  1 file changed, 16 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c



Ok, I'm running now b69f0859dc8e633c5d8c06845811588fe17e68b3 (-rc8)
with your patch.  I'll be able to give some feedback after couple
days (if I keep my machine running without reboot - since before
I had occasional problems with ACPI now resolved.
(https://bugzilla.kernel.org/show_bug.cgi?id=51071)
(patch not yet in -rc8)
I'm also using this extra patch: https://patchwork.kernel.org/patch/1792531/

What seems to be triggering condition on my machine - running laptop for some 
days - and having   Thunderbird reaching 0.8G (I guess they must keep all my 
news messages in memory to consume that size) and Firefox 1.3GB of consumed

memory (assuming massive leaking with combination of flash)

Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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 least three root causes as far as I can see, so it's not really
clear who observed which problem.  Please correct me if the
reported-by, tested-by, bisected-by tags are incomplete.

One problem was, as it seems, overly aggressive reclaim due to scaling
up reclaim goals based on compaction failures.  This one was reverted
in 9671009 mm: revert "mm: vmscan: scale number of pages reclaimed by
reclaim/compaction based on failures".



This particular one would have been made worse by the accounting bug and
if kswapd was staying awake longer than necessary. As scaling the amount
of reclaim only for direct reclaim helped this problem a lot, I strongly
suspect the accounting bug was a factor.

However the benefit for this is marginal -- it primarily affects how
many THP pages we can allocate under stress. There is already a graceful
fallback path and a system under heavy reclaim pressure is not going to
notice the performance benefit of THP.


Another one was an accounting problem where a freed higher order page
was underreported, and so kswapd had trouble restoring watermarks.
This one was fixed in ef6c5be fix incorrect NR_FREE_PAGES accounting
(appears like memory leak).



This almost certainly also requires the follow-on fix at
https://lkml.org/lkml/2012/11/26/225 for reasons I explained in
https://lkml.org/lkml/2012/11/27/190 .


The third one is a problem with small zones, like the DMA zone, where
the high watermark is lower than the low watermark plus compaction gap
(2 * allocation size).  The zonelist reclaim in kswapd would do
nothing because all high watermarks are met, but the compaction logic
would find its own requirements unmet and loop over the zones again.
Indefinitely, until some third party would free enough memory to help
meet the higher compaction watermark.  The problematic code has been
there since the 3.4 merge window for non-THP higher order allocations
but has been more prominent since the 3.7 merge window, where kswapd
is also woken up for the much more common THP allocations.



Yes.


The following patch should fix the third issue by making both reclaim
and compaction code in kswapd use the same predicate to determine
whether a zone is balanced or not.

Hopefully, the sum of all three fixes should tame kswapd enough for
3.7.



Not exactly sure of that. With just those patches it is possible for
allocations for THP entering the slow path to keep kswapd continually awake
doing busy work. This was an alternative to the revert that covered that
https://lkml.org/lkml/2012/11/12/151 but it was not enough because kswapd
would stay awake due to the bug you identified and fixed.

I went with the __GFP_NO_KSWAPD patch in this cycle because 3.6 was/is
very poor in how it handles THP after the removal of lumpy reclaim. 3.7
was shaping up to be even worse with multiple root causes too close to the
release date.  Taking kswapd out of the equation covered some of the
problems (yes, by hiding them) so it could be revisited but Johannes may
have finally squashed it.

However, if we revert the revert then I strongly recommend that it be
replaced with "Avoid waking kswapd for THP allocations when compaction is
deferred or contended".




Ok, bad news - I've been hit by  kswapd0 loop again -
my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again shown 
kswapd0 for couple minutes on CPU.


It seemed to go instantly away when I've drop caches
(echo 3 >/proc/sys/vm/drop_cache)
(After that I've had over 1G free memory)

Here are some stats before drop while kswapd0 was running:

kswapd0 R  running task030  2 0x
 880133207b08 0082 880133207b18 0246
 880135b92340 880133207fd8 880133207fd8 880133207fd8
 880103098000 880135b92340  880133206000
Call Trace:
 [] preempt_schedule+0x42/0x60
 [] _raw_spin_unlock+0x55/0x60
 [] grab_super_passive+0x3c/0x90
 [] prune_super+0x46/0x1b0
 [] shrink_slab+0xba/0x510
 [] ? mem_cgroup_iter+0x17a/0x2e0
 [] ? mem_cgroup_iter+0xca/0x2e0
 [] balance_pgdat+0x621/0x7e0
 [] kswapd+0x174/0x640
 [] ? __init_waitqueue_head+0x60/0x60
 [] ? balance_pgdat+0x7e0/0x7e0
 [] kthread+0xdb/0xe0
 [] ? kthread_create_on_node+0x140/0x140
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x140/0x140

runnable tasks:
task   PID tree-key  switches  prio exec-runtime 
sum-execsum-sleep

--
 kswapd030   8087056.792356 30543   120   8087056.792356 
158938.479290 137131605.711862 /
 kworker/0:3 29833   8087050.792356526664   120  

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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 least three root causes as far as I can see, so it's not really
clear who observed which problem.  Please correct me if the
reported-by, tested-by, bisected-by tags are incomplete.

One problem was, as it seems, overly aggressive reclaim due to scaling
up reclaim goals based on compaction failures.  This one was reverted
in 9671009 mm: revert mm: vmscan: scale number of pages reclaimed by
reclaim/compaction based on failures.



This particular one would have been made worse by the accounting bug and
if kswapd was staying awake longer than necessary. As scaling the amount
of reclaim only for direct reclaim helped this problem a lot, I strongly
suspect the accounting bug was a factor.

However the benefit for this is marginal -- it primarily affects how
many THP pages we can allocate under stress. There is already a graceful
fallback path and a system under heavy reclaim pressure is not going to
notice the performance benefit of THP.


Another one was an accounting problem where a freed higher order page
was underreported, and so kswapd had trouble restoring watermarks.
This one was fixed in ef6c5be fix incorrect NR_FREE_PAGES accounting
(appears like memory leak).



This almost certainly also requires the follow-on fix at
https://lkml.org/lkml/2012/11/26/225 for reasons I explained in
https://lkml.org/lkml/2012/11/27/190 .


The third one is a problem with small zones, like the DMA zone, where
the high watermark is lower than the low watermark plus compaction gap
(2 * allocation size).  The zonelist reclaim in kswapd would do
nothing because all high watermarks are met, but the compaction logic
would find its own requirements unmet and loop over the zones again.
Indefinitely, until some third party would free enough memory to help
meet the higher compaction watermark.  The problematic code has been
there since the 3.4 merge window for non-THP higher order allocations
but has been more prominent since the 3.7 merge window, where kswapd
is also woken up for the much more common THP allocations.



Yes.


The following patch should fix the third issue by making both reclaim
and compaction code in kswapd use the same predicate to determine
whether a zone is balanced or not.

Hopefully, the sum of all three fixes should tame kswapd enough for
3.7.



Not exactly sure of that. With just those patches it is possible for
allocations for THP entering the slow path to keep kswapd continually awake
doing busy work. This was an alternative to the revert that covered that
https://lkml.org/lkml/2012/11/12/151 but it was not enough because kswapd
would stay awake due to the bug you identified and fixed.

I went with the __GFP_NO_KSWAPD patch in this cycle because 3.6 was/is
very poor in how it handles THP after the removal of lumpy reclaim. 3.7
was shaping up to be even worse with multiple root causes too close to the
release date.  Taking kswapd out of the equation covered some of the
problems (yes, by hiding them) so it could be revisited but Johannes may
have finally squashed it.

However, if we revert the revert then I strongly recommend that it be
replaced with Avoid waking kswapd for THP allocations when compaction is
deferred or contended.




Ok, bad news - I've been hit by  kswapd0 loop again -
my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again shown 
kswapd0 for couple minutes on CPU.


It seemed to go instantly away when I've drop caches
(echo 3 /proc/sys/vm/drop_cache)
(After that I've had over 1G free memory)

Here are some stats before drop while kswapd0 was running:

kswapd0 R  running task030  2 0x
 880133207b08 0082 880133207b18 0246
 880135b92340 880133207fd8 880133207fd8 880133207fd8
 880103098000 880135b92340  880133206000
Call Trace:
 [815566b2] preempt_schedule+0x42/0x60
 [81558555] _raw_spin_unlock+0x55/0x60
 [81193b3c] grab_super_passive+0x3c/0x90
 [81193bd6] prune_super+0x46/0x1b0
 [81141eda] shrink_slab+0xba/0x510
 [81185c3a] ? mem_cgroup_iter+0x17a/0x2e0
 [81185b8a] ? mem_cgroup_iter+0xca/0x2e0
 [81145141] balance_pgdat+0x621/0x7e0
 [81145474] kswapd+0x174/0x640
 [8106fd40] ? __init_waitqueue_head+0x60/0x60
 [81145300] ? balance_pgdat+0x7e0/0x7e0
 [8106f52b] kthread+0xdb/0xe0
 [8106f450] ? kthread_create_on_node+0x140/0x140
 [815604dc] ret_from_fork+0x7c/0xb0
 [8106f450] ? kthread_create_on_node+0x140/0x140

runnable tasks:
task   PID tree-key  switches  prio exec-runtime 
sum-execsum-sleep

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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://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 then.


This just makes acpi_ns_lookup() always return acpi_gbl_root_node
for things looked up by acpi_ns_get_node() as far as I can say.

Hmm.

If my theory correct, the patch below should catch the bug.  Can you please
test it?



Ok now crashing right after 'undock' button press:

https://bugzilla.kernel.org/show_bug.cgi?id=51071#c10


Zdenek


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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 then.

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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
and attached picture there which is all I have.


I wonder if you can try to apply the patch below and see if that makes any
difference?



Yep - extended BZ with 2 new pictures - it's now crashing earlier within
the call of acpi_bus_get_device().

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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 then.

Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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://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 then.


This just makes acpi_ns_lookup() always return acpi_gbl_root_node
for things looked up by acpi_ns_get_node() as far as I can say.

Hmm.

If my theory correct, the patch below should catch the bug.  Can you please
test it?



Ok now crashing right after 'undock' button press:

https://bugzilla.kernel.org/show_bug.cgi?id=51071#c10


Zdenek


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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/show_bug.cgi?id=51071
and attached picture there which is all I have.


I wonder if you can try to apply the patch below and see if that makes any
difference?



Yep - extended BZ with 2 new pictures - it's now crashing earlier within
the call of acpi_bus_get_device().

Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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 parts of the code line, in
particular the actual oopsing instruction. But what is there decodes
to

 41 b8 10 00 00 00   mov$0x10,%r8d
 48 c7 c1 88 52 64 81mov$0x81645288,%rcx
 31 c0   xor%eax,%eax
 48 c7 c2 98 52 64 81mov$0x81645298,%rdx
 bf 00 04 00 0.  mov$0x0.00400,%edi

 .. oops in here ..

 74 33   je 0x50
 48 89 dfmov%rbx,%rdi
 e8 4d c9 00 00  callq  ? 
 48 89 d9mov%rbx,%rcx
 48 c7 c2 0a .. .. ..mov$0x..0a,%rdx

which isn't really very obvious. Do you have that kernel around (or at
least the same compiler and configuration)? Doing a

   objdump --disassemble  drivers/acpi/acpica/nsaccess.o


I've attached bigger disasfun script output to BZ 51071.
https://bugzilla.kernel.org/show_bug.cgi?id=51071#c1


if (ACPI_GET_DESCRIPTOR_TYPE(prefix_node) !=
00a1  cmpb   $0xf,0x8(%rbx)
00a5  je   0da  

seems to be going out of bounds.

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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 red herring - that's
just stale on the stack.

Do you have the register state from the oops? Or at least the "Code:"
line? It would be nice to see exactly where the oops happens, and I
cannot line up your "acpi_ns_lookup  + 0xa1/0x5b9" with any code due
to different compilers (and configurations etc).

Linus




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.


In all cases - I've played even with 3.4 kernel - which also does not survive 
multiple resumes in docking station - though it just leaves black screen - so 
this oops is rather 'progress' and it also could be false path.


It's probably not a regression from 3.6 - since this problem was there for 
much longer - but now it has just become much more visible.


As I usually do not have reason to make multiple suspend/resumes in dock I've 
not noticed it until now when I've tried to capture this ACPI trace.


Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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 that revert should be reverted, and replaced with your patch?

Mel? Zdenek? What's the status here?




I've tried for longer term:

https://lkml.org/lkml/2012/11/5/308
https://lkml.org/lkml/2012/11/12/113

these 2 seems to be now merge in -rc7
(since they disappeared after my git rebase)


and added slightly modified patch from Jiri
(https://lkml.org/lkml/2012/11/15/950
(Unsure where it still applies for -rc7??)

Also I've Jan Kara 
fs: Fix imbalance in freeze protection in mark_files_ro()
(which is still not applied to upstream)

And I think I'm NOT seeing huge load from kswapd0.
(At least related to my not really long uptimes)


But also I'm now  frequent victim of my other report:

https://lkml.org/lkml/2012/11/15/369

Which turns into a problem, that if my T61 docking station
has enabled support for 'old hw' for docking in BIOS - i.e. serial output'
it becomes unstable and either 1st. or 2nd. resume deadlocks
machine - and serial port gives just garbage)

Zdenek



  Linus

On Tue, Nov 27, 2012 at 12:48 PM, 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 least three root causes as far as I can see, so it's not really
clear who observed which problem.  Please correct me if the
reported-by, tested-by, bisected-by tags are incomplete.

One problem was, as it seems, overly aggressive reclaim due to scaling
up reclaim goals based on compaction failures.  This one was reverted
in 9671009 mm: revert "mm: vmscan: scale number of pages reclaimed by
reclaim/compaction based on failures".

Another one was an accounting problem where a freed higher order page
was underreported, and so kswapd had trouble restoring watermarks.
This one was fixed in ef6c5be fix incorrect NR_FREE_PAGES accounting
(appears like memory leak).

The third one is a problem with small zones, like the DMA zone, where
the high watermark is lower than the low watermark plus compaction gap
(2 * allocation size).  The zonelist reclaim in kswapd would do
nothing because all high watermarks are met, but the compaction logic
would find its own requirements unmet and loop over the zones again.
Indefinitely, until some third party would free enough memory to help
meet the higher compaction watermark.  The problematic code has been
there since the 3.4 merge window for non-THP higher order allocations
but has been more prominent since the 3.7 merge window, where kswapd
is also woken up for the much more common THP allocations.

The following patch should fix the third issue by making both reclaim
and compaction code in kswapd use the same predicate to determine
whether a zone is balanced or not.

Hopefully, the sum of all three fixes should tame kswapd enough for
3.7.

Johannes



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd craziness in 3.7

[Zdenek Kabelac]

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 that revert should be reverted, and replaced with your patch?

Mel? Zdenek? What's the status here?




I've tried for longer term:

https://lkml.org/lkml/2012/11/5/308
https://lkml.org/lkml/2012/11/12/113

these 2 seems to be now merge in -rc7
(since they disappeared after my git rebase)


and added slightly modified patch from Jiri
(https://lkml.org/lkml/2012/11/15/950
(Unsure where it still applies for -rc7??)

Also I've Jan Kara j...@suse.cz
fs: Fix imbalance in freeze protection in mark_files_ro()
(which is still not applied to upstream)

And I think I'm NOT seeing huge load from kswapd0.
(At least related to my not really long uptimes)


But also I'm now  frequent victim of my other report:

https://lkml.org/lkml/2012/11/15/369

Which turns into a problem, that if my T61 docking station
has enabled support for 'old hw' for docking in BIOS - i.e. serial output'
it becomes unstable and either 1st. or 2nd. resume deadlocks
machine - and serial port gives just garbage)

Zdenek



  Linus

On Tue, Nov 27, 2012 at 12:48 PM, Johannes Weiner han...@cmpxchg.org 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 least three root causes as far as I can see, so it's not really
clear who observed which problem.  Please correct me if the
reported-by, tested-by, bisected-by tags are incomplete.

One problem was, as it seems, overly aggressive reclaim due to scaling
up reclaim goals based on compaction failures.  This one was reverted
in 9671009 mm: revert mm: vmscan: scale number of pages reclaimed by
reclaim/compaction based on failures.

Another one was an accounting problem where a freed higher order page
was underreported, and so kswapd had trouble restoring watermarks.
This one was fixed in ef6c5be fix incorrect NR_FREE_PAGES accounting
(appears like memory leak).

The third one is a problem with small zones, like the DMA zone, where
the high watermark is lower than the low watermark plus compaction gap
(2 * allocation size).  The zonelist reclaim in kswapd would do
nothing because all high watermarks are met, but the compaction logic
would find its own requirements unmet and loop over the zones again.
Indefinitely, until some third party would free enough memory to help
meet the higher compaction watermark.  The problematic code has been
there since the 3.4 merge window for non-THP higher order allocations
but has been more prominent since the 3.7 merge window, where kswapd
is also woken up for the much more common THP allocations.

The following patch should fix the third issue by making both reclaim
and compaction code in kswapd use the same predicate to determine
whether a zone is balanced or not.

Hopefully, the sum of all three fixes should tame kswapd enough for
3.7.

Johannes



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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 red herring - that's
just stale on the stack.

Do you have the register state from the oops? Or at least the Code:
line? It would be nice to see exactly where the oops happens, and I
cannot line up your acpi_ns_lookup  + 0xa1/0x5b9 with any code due
to different compilers (and configurations etc).

Linus




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.


In all cases - I've played even with 3.4 kernel - which also does not survive 
multiple resumes in docking station - though it just leaves black screen - so 
this oops is rather 'progress' and it also could be false path.


It's probably not a regression from 3.6 - since this problem was there for 
much longer - but now it has just become much more visible.


As I usually do not have reason to make multiple suspend/resumes in dock I've 
not noticed it until now when I've tried to capture this ACPI trace.


Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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 much of the relevant parts of the code line, in
particular the actual oopsing instruction. But what is there decodes
to

 41 b8 10 00 00 00   mov$0x10,%r8d
 48 c7 c1 88 52 64 81mov$0x81645288,%rcx
 31 c0   xor%eax,%eax
 48 c7 c2 98 52 64 81mov$0x81645298,%rdx
 bf 00 04 00 0.  mov$0x0.00400,%edi

 .. oops in here ..

 74 33   je 0x50
 48 89 dfmov%rbx,%rdi
 e8 4d c9 00 00  callq  ? offset 0xc972
 48 89 d9mov%rbx,%rcx
 48 c7 c2 0a .. .. ..mov$0x..0a,%rdx

which isn't really very obvious. Do you have that kernel around (or at
least the same compiler and configuration)? Doing a

   objdump --disassemble  drivers/acpi/acpica/nsaccess.o


I've attached bigger disasfun script output to BZ 51071.
https://bugzilla.kernel.org/show_bug.cgi?id=51071#c1


if (ACPI_GET_DESCRIPTOR_TYPE(prefix_node) !=
00a1 acpi_ns_lookup+0xa1 cmpb   $0xf,0x8(%rbx)
00a5 acpi_ns_lookup+0xa5 je   0da  acpi_ns_lookup+0xda

seems to be going out of bounds.

Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Unbalanced unlock with sysrq+SUB

[Zdenek Kabelac]

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! ]
3.7.0-rc6-00028-g88e75b6 #101 Not tainted
-
kworker/1:2/79 is trying to release lock (sb_writers) at:
[] mnt_drop_write+0x24/0x30
but there are no more locks to release!

other info that might help us debug this:
4 locks held by kworker/1:2/79:
 #0:  (events){.+.+.+}, at: [] process_one_work+0x149/0x750
 #1:  ((work)#3){+.+...}, at: [] process_one_work+0x149/0x750
 #2:  (>s_umount_key#19){+.}, at: [] 
do_emergency_remount+0x80/0x120

 #3:  (files_lglock){.+.+..}, at: [] mark_files_ro+0x2b/0x100

stack backtrace:
Pid: 79, comm: kworker/1:2 Not tainted 3.7.0-rc6-00028-g88e75b6 #101
Call Trace:
 [] ? mnt_drop_write+0x24/0x30
 [] print_unlock_inbalance_bug+0xfe/0x110
 [] lock_release_non_nested+0x21e/0x320
 [] ? pagevec_lookup_tag+0x25/0x40
 [] ? mnt_drop_write+0x24/0x30
 [] lock_release+0x97/0x300
 [] __sb_end_write+0x81/0x90
 [] mnt_drop_write+0x24/0x30
 [] mnt_drop_write_file+0x12/0x20
 [] mark_files_ro+0xf7/0x100
 [] do_remount_sb+0x13d/0x1b0
 [] ? do_emergency_remount+0x80/0x120
 [] do_emergency_remount+0x11c/0x120
 [] process_one_work+0x1ad/0x750
 [] ? process_one_work+0x149/0x750
 [] ? worker_thread+0x21b/0x450
 [] ? _raw_spin_lock_irq+0x19/0x80
 [] ? mount_single+0xe0/0xe0
 [] worker_thread+0x15d/0x450
 [] ? rescuer_thread+0x230/0x230
 [] kthread+0xdb/0xe0
 [] ? kthread_create_on_node+0x140/0x140
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x140/0x140
EXT4-fs (sda2): re-mounted. Opts: (null)
EXT4-fs (sda5): re-mounted. Opts: (null)
Emergency Remount complete
systemd[1]: Stopping Sendmail Mail Transport Client...
systemd[1]: Stopping Sendmail Mail Transport Agent...
systemd[1]: Starting Sendmail Mail Transport Agent...
systemd[1]: Started Sendmail Mail Transport Agent.
systemd[1]: Starting Sendmail Mail Transport Client...
systemd[1]: Started Sendmail Mail Transport Client.
SysRq : Resetting
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Unbalanced unlock with sysrq+SUB

[Zdenek Kabelac]

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! ]
3.7.0-rc6-00028-g88e75b6 #101 Not tainted
-
kworker/1:2/79 is trying to release lock (sb_writers) at:
[811b33b4] mnt_drop_write+0x24/0x30
but there are no more locks to release!

other info that might help us debug this:
4 locks held by kworker/1:2/79:
 #0:  (events){.+.+.+}, at: [81064a79] process_one_work+0x149/0x750
 #1:  ((work)#3){+.+...}, at: [81064a79] process_one_work+0x149/0x750
 #2:  (type-s_umount_key#19){+.}, at: [81194140] 
do_emergency_remount+0x80/0x120

 #3:  (files_lglock){.+.+..}, at: [8119202b] mark_files_ro+0x2b/0x100

stack backtrace:
Pid: 79, comm: kworker/1:2 Not tainted 3.7.0-rc6-00028-g88e75b6 #101
Call Trace:
 [811b33b4] ? mnt_drop_write+0x24/0x30
 [810ae52e] print_unlock_inbalance_bug+0xfe/0x110
 [810b10fe] lock_release_non_nested+0x21e/0x320
 [8113c9a5] ? pagevec_lookup_tag+0x25/0x40
 [811b33b4] ? mnt_drop_write+0x24/0x30
 [810b1297] lock_release+0x97/0x300
 [811926b1] __sb_end_write+0x81/0x90
 [811b33b4] mnt_drop_write+0x24/0x30
 [811b33d2] mnt_drop_write_file+0x12/0x20
 [811920f7] mark_files_ro+0xf7/0x100
 [81193f6d] do_remount_sb+0x13d/0x1b0
 [81194140] ? do_emergency_remount+0x80/0x120
 [811941dc] do_emergency_remount+0x11c/0x120
 [81064add] process_one_work+0x1ad/0x750
 [81064a79] ? process_one_work+0x149/0x750
 [8106550b] ? worker_thread+0x21b/0x450
 [81557219] ? _raw_spin_lock_irq+0x19/0x80
 [811940c0] ? mount_single+0xe0/0xe0
 [8106544d] worker_thread+0x15d/0x450
 [810652f0] ? rescuer_thread+0x230/0x230
 [8106f50b] kthread+0xdb/0xe0
 [8106f430] ? kthread_create_on_node+0x140/0x140
 [8155fe1c] ret_from_fork+0x7c/0xb0
 [8106f430] ? kthread_create_on_node+0x140/0x140
EXT4-fs (sda2): re-mounted. Opts: (null)
EXT4-fs (sda5): re-mounted. Opts: (null)
Emergency Remount complete
systemd[1]: Stopping Sendmail Mail Transport Client...
systemd[1]: Stopping Sendmail Mail Transport Agent...
systemd[1]: Starting Sendmail Mail Transport Agent...
systemd[1]: Started Sendmail Mail Transport Agent.
systemd[1]: Starting Sendmail Mail Transport Client...
systemd[1]: Started Sendmail Mail Transport Client.
SysRq : Resetting
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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
spinning on my CPU again - it's not as endless like before - but
still it easily eats minutes - it helps to  turn off  Firefox or TB
(memory hungry apps) so kswapd0 stops soon - and restart those apps
again.
(And I still have like >1GB of cached memory)



I posted a "safe" patch that I believe explains why you are seeing what
you are seeing. It does mean that there will still be some stalls due to
THP because kswapd is not helping and it's avoiding the problem rather
than trying to deal with it.

Hence, I'm also going to post this patch even though I have not tested
it myself. If you find it fixes the problem then it would be a
preferable patch to the revert. It still is the case that the
balance_pgdat() logic is in sort need of a rethink as it's pretty
twisted right now.




Should I apply them all together for 3.7-rc5 ?

1) https://lkml.org/lkml/2012/11/5/308
2) https://lkml.org/lkml/2012/11/12/113
3) https://lkml.org/lkml/2012/11/12/151



Not all together. Test either 1+2 or 1+3. 1+2 is the safer choice but
does nothing about THP stalls. 1+3 is a riskier version but depends on
me being correct on what the root cause of the problem you see it.

If both 1+2 and 1+3 work for you, I'd choose 1+3 for merging. If you only
have the time to test one combination then it would be preferred that you
test the safe option of 1+2.


So I've tested  1+2 for a few days - once I've rebooted for another reason,
but today happened this to me (with ~2day uptime)

For some reason my machine went ouf of memory and OOM killed
firefox and then even whole Xsession.

Unsure whether it's related to those 2 patches - but I've never had
such OOM failure before.

Should I experiment now with 1+3 - or is there newer thing to test ?

Zdenek

 X: page allocation failure: order:0, mode:0x200da
 Pid: 1126, comm: X Not tainted 3.7.0-rc5-7-g95e21c5 #100
 Call Trace:
  [] warn_alloc_failed+0xe9/0x140
  [] __alloc_pages_nodemask+0x7fa/0xa40
  [] shmem_getpage_gfp+0x603/0x9d0
  [] ? native_sched_clock+0x26/0x90
  [] shmem_fault+0x4f/0xa0
  [] shm_fault+0x1e/0x20
  [] __do_fault+0x73/0x4d0
  [] ? generic_file_aio_write+0xb0/0x100
  [] handle_pte_fault+0x97/0x9a0
  [] ? __lock_is_held+0x5f/0x90
  [] ? get_parent_ip+0x11/0x50
 rsyslogd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
 rsyslogd cpuset=/ mems_allowed=0
 Pid: 571, comm: rsyslogd Not tainted 3.7.0-rc5-7-g95e21c5 #100
 Call Trace:
  [] dump_header.isra.12+0x78/0x224
  [] ? sub_preempt_count+0x79/0xd0
  [] ? _raw_spin_unlock_irqrestore+0x42/0x80
  [] ? ___ratelimit+0x9e/0x130
  [] oom_kill_process+0x1d3/0x330
  [] out_of_memory+0x439/0x4a0
  [] __alloc_pages_nodemask+0x976/0xa40
  [] ? find_get_page+0x5/0x230
  [] filemap_fault+0x2d0/0x480
  [] __do_fault+0x73/0x4d0
  [] handle_pte_fault+0x97/0x9a0
  [] ? __lock_is_held+0x5f/0x90
  [] ? get_parent_ip+0x11/0x50
  [] handle_mm_fault+0x22f/0x2f0
  [] __do_page_fault+0x15d/0x4e0
  [] ? sub_preempt_count+0x79/0xd0
  [] ? _raw_spin_unlock+0x35/0x60
  [] ? proc_reg_read+0x8c/0xc0
  [] ? error_sti+0x5/0x6
  [] ? trace_hardirqs_off_thunk+0x3a/0x3c
  [] do_page_fault+0xe/0x10
  [] page_fault+0x22/0x30
 Mem-Info:
 DMA per-cpu:
 CPU0: hi:0, btch:   1 usd:   0
 CPU1: hi:0, btch:   1 usd:   0
 DMA32 per-cpu:
 CPU0: hi:  186, btch:  31 usd:  30
 CPU1: hi:  186, btch:  31 usd:   6
 Normal per-cpu:
 CPU0: hi:  186, btch:  31 usd:  30
 CPU1: hi:  186, btch:  31 usd:   0
 active_anon:900420 inactive_anon:28835 isolated_anon:0
  active_file:43 inactive_file:21 isolated_file:0
  unevictable:4 dirty:34 writeback:2 unstable:0
  free:20731 slab_reclaimable:8641 slab_unreclaimable:10446
  mapped:18325 shmem:243662 pagetables:7705 bounce:0
  free_cma:0
 DMA free:12120kB min:272kB low:340kB high:408kB active_anon:2892kB 
inactive_anon:872kB active_file:0kB inactive_file:0kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15900kB mlocked:0kB dirty:0kB 
writeback:0kB mapped:1672kB shmem:3596kB slab_reclaimable:0kB 
slab_unreclaimable:16kB kernel_stack:0kB pagetables:0kB unstable:0kB 
bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes

 lowmem_reserve[]: 0 2951 3836 3836
 DMA32 free:55296kB min:51776kB low:64720kB high:77664kB 
active_anon:2834992kB inactive_anon:107924kB active_file:92kB 
inactive_file:52kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:3021968kB mlocked:0kB dirty:88kB writeback:0kB mapped:65460kB 
shmem:943100kB slab_reclaimable:11700kB slab_unreclaimable:8968kB 
kernel_stack:592kB pagetables:11852kB unstable:0kB bounce:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:180 all_unreclaimable? yes

 lowmem_reserve[]: 0 0 885 885

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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
spinning on my CPU again - it's not as endless like before - but
still it easily eats minutes - it helps to  turn off  Firefox or TB
(memory hungry apps) so kswapd0 stops soon - and restart those apps
again.
(And I still have like 1GB of cached memory)



I posted a safe patch that I believe explains why you are seeing what
you are seeing. It does mean that there will still be some stalls due to
THP because kswapd is not helping and it's avoiding the problem rather
than trying to deal with it.

Hence, I'm also going to post this patch even though I have not tested
it myself. If you find it fixes the problem then it would be a
preferable patch to the revert. It still is the case that the
balance_pgdat() logic is in sort need of a rethink as it's pretty
twisted right now.




Should I apply them all together for 3.7-rc5 ?

1) https://lkml.org/lkml/2012/11/5/308
2) https://lkml.org/lkml/2012/11/12/113
3) https://lkml.org/lkml/2012/11/12/151



Not all together. Test either 1+2 or 1+3. 1+2 is the safer choice but
does nothing about THP stalls. 1+3 is a riskier version but depends on
me being correct on what the root cause of the problem you see it.

If both 1+2 and 1+3 work for you, I'd choose 1+3 for merging. If you only
have the time to test one combination then it would be preferred that you
test the safe option of 1+2.


So I've tested  1+2 for a few days - once I've rebooted for another reason,
but today happened this to me (with ~2day uptime)

For some reason my machine went ouf of memory and OOM killed
firefox and then even whole Xsession.

Unsure whether it's related to those 2 patches - but I've never had
such OOM failure before.

Should I experiment now with 1+3 - or is there newer thing to test ?

Zdenek

 X: page allocation failure: order:0, mode:0x200da
 Pid: 1126, comm: X Not tainted 3.7.0-rc5-7-g95e21c5 #100
 Call Trace:
  [811354e9] warn_alloc_failed+0xe9/0x140
  [81138eda] __alloc_pages_nodemask+0x7fa/0xa40
  [81148fc3] shmem_getpage_gfp+0x603/0x9d0
  [8100a166] ? native_sched_clock+0x26/0x90
  [81149d6f] shmem_fault+0x4f/0xa0
  [812ad69e] shm_fault+0x1e/0x20
  [811571d3] __do_fault+0x73/0x4d0
  [81131640] ? generic_file_aio_write+0xb0/0x100
  [81159d67] handle_pte_fault+0x97/0x9a0
  [810aca4f] ? __lock_is_held+0x5f/0x90
  [81081711] ? get_parent_ip+0x11/0x50
 rsyslogd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
 rsyslogd cpuset=/ mems_allowed=0
 Pid: 571, comm: rsyslogd Not tainted 3.7.0-rc5-7-g95e21c5 #100
 Call Trace:
  [8154dfcb] dump_header.isra.12+0x78/0x224
  [8155b529] ? sub_preempt_count+0x79/0xd0
  [81557842] ? _raw_spin_unlock_irqrestore+0x42/0x80
  [81317c0e] ? ___ratelimit+0x9e/0x130
  [81133ac3] oom_kill_process+0x1d3/0x330
  [81134219] out_of_memory+0x439/0x4a0
  [81139056] __alloc_pages_nodemask+0x976/0xa40
  [811304b5] ? find_get_page+0x5/0x230
  [811322a0] filemap_fault+0x2d0/0x480
  [811571d3] __do_fault+0x73/0x4d0
  [81159d67] handle_pte_fault+0x97/0x9a0
  [810aca4f] ? __lock_is_held+0x5f/0x90
  [81081711] ? get_parent_ip+0x11/0x50
  [8115ae6f] handle_mm_fault+0x22f/0x2f0
  [8155ae7d] __do_page_fault+0x15d/0x4e0
  [8155b529] ? sub_preempt_count+0x79/0xd0
  [815578b5] ? _raw_spin_unlock+0x35/0x60
  [811f8d9c] ? proc_reg_read+0x8c/0xc0
  [815580a3] ? error_sti+0x5/0x6
  [8131f55d] ? trace_hardirqs_off_thunk+0x3a/0x3c
  [8155b20e] do_page_fault+0xe/0x10
  [81557ea2] page_fault+0x22/0x30
 Mem-Info:
 DMA per-cpu:
 CPU0: hi:0, btch:   1 usd:   0
 CPU1: hi:0, btch:   1 usd:   0
 DMA32 per-cpu:
 CPU0: hi:  186, btch:  31 usd:  30
 CPU1: hi:  186, btch:  31 usd:   6
 Normal per-cpu:
 CPU0: hi:  186, btch:  31 usd:  30
 CPU1: hi:  186, btch:  31 usd:   0
 active_anon:900420 inactive_anon:28835 isolated_anon:0
  active_file:43 inactive_file:21 isolated_file:0
  unevictable:4 dirty:34 writeback:2 unstable:0
  free:20731 slab_reclaimable:8641 slab_unreclaimable:10446
  mapped:18325 shmem:243662 pagetables:7705 bounce:0
  free_cma:0
 DMA free:12120kB min:272kB low:340kB high:408kB active_anon:2892kB 
inactive_anon:872kB active_file:0kB inactive_file:0kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15900kB mlocked:0kB dirty:0kB 
writeback:0kB mapped:1672kB shmem:3596kB slab_reclaimable:0kB 
slab_unreclaimable:16kB kernel_stack:0kB pagetables:0kB unstable:0kB 
bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes

 lowmem_reserve[]: 0 2951

Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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 picture.

From the trace it seem os_wait semaphore is accessed twice.
Unsure which device is behind it - but it seem docking station is need to hit 
this issue.



kernel 3.7.0-rc4

Pid:  pm-suspend

RIP:   acpi_ns_lookup  + 0xa1/0x5b9

Call Trace:

? acpi_os_wait_semaphore + 0x136/0x149
acpi_ns_get_mode + 0x96/0x102
? __lock_is_held +0x5f/0x90
acpi_ns_evaluate +0x47/0x2de
? _raw_spin_lock_irqsave
? acpi_ut_evaluate_object
? sub_preempt_count
? pnpacpi_can_wakeup
acpi_rs_get_method_data
? acpi_os_signal_semaphore
acpi_walk_resources
? acpi_ut_release_mutex
pnpacpi_build_resource_template
? acpi_bus_get_device
pnpacpi_set_resources
? pnp_device_shutdown
pnp_start_dev
pnp_bus_resume
dpm_run_callback
device_resume
dpm_resume
dpm_resume_end
? acpi_suspend_begin_old
suspend_devices_and_enter
pm_suspend
state_store
kobj_attr_store
sysfs_write_file
vgs_write
sys_write
system_call_fastpath

Zdenek


PS: jpg on request
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Acpi deadlocks with 3.7.0-rc4

[Zdenek Kabelac]

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 picture.

From the trace it seem os_wait semaphore is accessed twice.
Unsure which device is behind it - but it seem docking station is need to hit 
this issue.



kernel 3.7.0-rc4

Pid:  pm-suspend

RIP:   acpi_ns_lookup  + 0xa1/0x5b9

Call Trace:

? acpi_os_wait_semaphore + 0x136/0x149
acpi_ns_get_mode + 0x96/0x102
? __lock_is_held +0x5f/0x90
acpi_ns_evaluate +0x47/0x2de
? _raw_spin_lock_irqsave
? acpi_ut_evaluate_object
? sub_preempt_count
? pnpacpi_can_wakeup
acpi_rs_get_method_data
? acpi_os_signal_semaphore
acpi_walk_resources
? acpi_ut_release_mutex
pnpacpi_build_resource_template
? acpi_bus_get_device
pnpacpi_set_resources
? pnp_device_shutdown
pnp_start_dev
pnp_bus_resume
dpm_run_callback
device_resume
dpm_resume
dpm_resume_end
? acpi_suspend_begin_old
suspend_devices_and_enter
pm_suspend
state_store
kobj_attr_store
sysfs_write_file
vgs_write
sys_write
system_call_fastpath

Zdenek


PS: jpg on request
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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
spinning on my CPU again - it's not as endless like before - but
still it easily eats minutes - it helps to  turn off  Firefox or TB
(memory hungry apps) so kswapd0 stops soon - and restart those apps
again.
(And I still have like >1GB of cached memory)



I posted a "safe" patch that I believe explains why you are seeing what
you are seeing. It does mean that there will still be some stalls due to
THP because kswapd is not helping and it's avoiding the problem rather
than trying to deal with it.

Hence, I'm also going to post this patch even though I have not tested
it myself. If you find it fixes the problem then it would be a
preferable patch to the revert. It still is the case that the
balance_pgdat() logic is in sort need of a rethink as it's pretty
twisted right now.




Should I apply them all together for 3.7-rc5 ?

1) https://lkml.org/lkml/2012/11/5/308
2) https://lkml.org/lkml/2012/11/12/113
3) https://lkml.org/lkml/2012/11/12/151



Not all together. Test either 1+2 or 1+3. 1+2 is the safer choice but
does nothing about THP stalls. 1+3 is a riskier version but depends on
me being correct on what the root cause of the problem you see it.

If both 1+2 and 1+3 work for you, I'd choose 1+3 for merging. If you only
have the time to test one combination then it would be preferred that you
test the safe option of 1+2.




I'll go with 1+2 for couple days - the issue is  - I've no idea how it gets
suddenly triggered - it seemed to be running fine for 2-3 days even with
just 1) - but then kswapd0 started to occupy CPU for minutes.
Looks like some intensive workload on firefox (flash) may lead to that.

Anyway it's hard to tell quickly if it helped.

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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  Firefox or TB
(memory hungry apps) so kswapd0 stops soon - and restart those apps
again.
(And I still have like >1GB of cached memory)



I posted a "safe" patch that I believe explains why you are seeing what
you are seeing. It does mean that there will still be some stalls due to
THP because kswapd is not helping and it's avoiding the problem rather
than trying to deal with it.

Hence, I'm also going to post this patch even though I have not tested
it myself. If you find it fixes the problem then it would be a
preferable patch to the revert. It still is the case that the
balance_pgdat() logic is in sort need of a rethink as it's pretty
twisted right now.




Should I apply them all together for 3.7-rc5 ?

1) https://lkml.org/lkml/2012/11/5/308
2) https://lkml.org/lkml/2012/11/12/113
3) https://lkml.org/lkml/2012/11/12/151

Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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  Firefox or TB
(memory hungry apps) so kswapd0 stops soon - and restart those apps
again.
(And I still have like 1GB of cached memory)



I posted a safe patch that I believe explains why you are seeing what
you are seeing. It does mean that there will still be some stalls due to
THP because kswapd is not helping and it's avoiding the problem rather
than trying to deal with it.

Hence, I'm also going to post this patch even though I have not tested
it myself. If you find it fixes the problem then it would be a
preferable patch to the revert. It still is the case that the
balance_pgdat() logic is in sort need of a rethink as it's pretty
twisted right now.




Should I apply them all together for 3.7-rc5 ?

1) https://lkml.org/lkml/2012/11/5/308
2) https://lkml.org/lkml/2012/11/12/113
3) https://lkml.org/lkml/2012/11/12/151

Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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
spinning on my CPU again - it's not as endless like before - but
still it easily eats minutes - it helps to  turn off  Firefox or TB
(memory hungry apps) so kswapd0 stops soon - and restart those apps
again.
(And I still have like 1GB of cached memory)



I posted a safe patch that I believe explains why you are seeing what
you are seeing. It does mean that there will still be some stalls due to
THP because kswapd is not helping and it's avoiding the problem rather
than trying to deal with it.

Hence, I'm also going to post this patch even though I have not tested
it myself. If you find it fixes the problem then it would be a
preferable patch to the revert. It still is the case that the
balance_pgdat() logic is in sort need of a rethink as it's pretty
twisted right now.




Should I apply them all together for 3.7-rc5 ?

1) https://lkml.org/lkml/2012/11/5/308
2) https://lkml.org/lkml/2012/11/12/113
3) https://lkml.org/lkml/2012/11/12/151



Not all together. Test either 1+2 or 1+3. 1+2 is the safer choice but
does nothing about THP stalls. 1+3 is a riskier version but depends on
me being correct on what the root cause of the problem you see it.

If both 1+2 and 1+3 work for you, I'd choose 1+3 for merging. If you only
have the time to test one combination then it would be preferred that you
test the safe option of 1+2.




I'll go with 1+2 for couple days - the issue is  - I've no idea how it gets
suddenly triggered - it seemed to be running fine for 2-3 days even with
just 1) - but then kswapd0 started to occupy CPU for minutes.
Looks like some intensive workload on firefox (flash) may lead to that.

Anyway it's hard to tell quickly if it helped.

Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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: reclaim at order 0 when compaction is enabled
...

This is plausible since the issue seems to be in the kswapd + compaction
realm.  I've yet to figure out exactly what about this commit results in
kswapd spinning.

I would be interested if someone can confirm this finding.

--
Seth




On my system 3.7-rc4 the problem seems to be effectively solved by
revert patch: https://lkml.org/lkml/2012/11/5/308



Ok, while there is still a question on whether it's enough I think it's
sensible to at least start with the obvious one.




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  Firefox or TB  (memory hungry 
apps) so kswapd0 stops soon - and restart those apps again.

(And I still have like >1GB of cached memory)

kswapd0 R  running task030  2 0x
 8801331efae8 0082 0018 0246
 880135b9a340 8801331effd8 8801331effd8 8801331effd8
 880055dfa340 880135b9a340 331efad8 8801331ee000
Call Trace:
 [] preempt_schedule+0x42/0x60
 [] _raw_spin_unlock+0x55/0x60
 [] put_super+0x31/0x40
 [] drop_super+0x22/0x30
 [] prune_super+0x149/0x1b0
 [] shrink_slab+0xba/0x510
 [] ? mem_cgroup_iter+0x17a/0x2e0
 [] ? mem_cgroup_iter+0xca/0x2e0
 [] balance_pgdat+0x629/0x7f0
 [] kswapd+0x174/0x620
 [] ? __init_waitqueue_head+0x60/0x60
 [] ? balance_pgdat+0x7f0/0x7f0
 [] kthread+0xdb/0xe0
 [] ? kthread_create_on_node+0x140/0x140
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x140/0x140


runnable tasks:
task   PID tree-key  switches  prio exec-runtime 
sum-execsum-sleep

--
 kswapd030   8689943.729790 36266   120   8689943.729790 
201495.640629  56609485.489414 /
 kworker/0:1 14790   8689937.729790 16969   120   8689937.729790 
  374.385996150405.181652 /
R   bash 14855   821.74926850   120   821.749268 
  24.027535  5252.291128 /autogroup-304





Mem-Info:
DMA per-cpu:
CPU0: hi:0, btch:   1 usd:   0
CPU1: hi:0, btch:   1 usd:   0
DMA32 per-cpu:
CPU0: hi:  186, btch:  31 usd: 146
CPU1: hi:  186, btch:  31 usd: 135
Normal per-cpu:
CPU0: hi:  186, btch:  31 usd: 131
CPU1: hi:  186, btch:  31 usd: 132
active_anon:726521 inactive_anon:26442 isolated_anon:0
 active_file:77765 inactive_file:76890 isolated_file:0
 unevictable:12 dirty:4 writeback:0 unstable:0
 free:40261 slab_reclaimable:12414 slab_unreclaimable:9694
 mapped:26382 shmem:162712 pagetables:6618 bounce:0
 free_cma:0
DMA free:15676kB min:272kB low:340kB high:408kB active_anon:208kB 
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15900kB mlocked:0kB dirty:0kB 
writeback:0kB mapped:0kB shmem:208kB slab_reclaimable:8kB 
slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB 
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes

lowmem_reserve[]: 0 2951 3836 3836
DMA32 free:126072kB min:51776kB low:64720kB high:77664kB active_anon:2175104kB 
inactive_anon:98976kB active_file:296252kB inactive_file:297648kB 
unevictable:48kB isolated(anon):0kB isolated(file):0kB present:3021960kB 
mlocked:48kB dirty:12kB writeback:0kB mapped:77664kB shmem:620388kB 
slab_reclaimable:19128kB slab_unreclaimable:6292kB kernel_stack:624kB 
pagetables:8900kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 885 885
Normal free:19296kB min:15532kB low:19412kB high:23296kB active_anon:730772kB 
inactive_anon:6792kB active_file:14808kB inactive_file:9912kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:906664kB mlocked:0kB dirty:4kB 
writeback:0kB mapped:27864kB shmem:30252kB slab_reclaimable:30520kB 
slab_unreclaimable:32476kB kernel_stack:2496kB pagetables:17572kB unstable:0kB 
bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 0 0
DMA: 1*4kB 1*8kB 3*16kB 2*32kB 3*64kB 2*128kB 3*256kB 2*512kB 3*1024kB 
3*2048kB 1*4096kB = 15676kB
DMA32: 730*4kB 328*8kB 223*16kB 123*32kB 182*64kB 96*128kB 172*256kB 56*512kB 
12*1024kB 1*2048kB 1*4096kB = 128120kB
Normal: 600*4kB 384*8kB 164*16kB 122*32kB 40*64kB 7*128kB 1*256kB 1*512kB 
1*1024kB 1*2048kB 0*4096kB = 19296kB

317367 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
1032176 pages 

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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

 vmscan: reclaim at order 0 when compaction is enabled
...

This is plausible since the issue seems to be in the kswapd + compaction
realm.  I've yet to figure out exactly what about this commit results in
kswapd spinning.

I would be interested if someone can confirm this finding.

--
Seth




On my system 3.7-rc4 the problem seems to be effectively solved by
revert patch: https://lkml.org/lkml/2012/11/5/308



Ok, while there is still a question on whether it's enough I think it's
sensible to at least start with the obvious one.




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  Firefox or TB  (memory hungry 
apps) so kswapd0 stops soon - and restart those apps again.

(And I still have like 1GB of cached memory)

kswapd0 R  running task030  2 0x
 8801331efae8 0082 0018 0246
 880135b9a340 8801331effd8 8801331effd8 8801331effd8
 880055dfa340 880135b9a340 331efad8 8801331ee000
Call Trace:
 [81555bf2] preempt_schedule+0x42/0x60
 [81557a95] _raw_spin_unlock+0x55/0x60
 [81192971] put_super+0x31/0x40
 [81192a42] drop_super+0x22/0x30
 [81193b89] prune_super+0x149/0x1b0
 [81141e2a] shrink_slab+0xba/0x510
 [81185b4a] ? mem_cgroup_iter+0x17a/0x2e0
 [81185a9a] ? mem_cgroup_iter+0xca/0x2e0
 [81145099] balance_pgdat+0x629/0x7f0
 [811453d4] kswapd+0x174/0x620
 [8106fd20] ? __init_waitqueue_head+0x60/0x60
 [81145260] ? balance_pgdat+0x7f0/0x7f0
 [8106f50b] kthread+0xdb/0xe0
 [8106f430] ? kthread_create_on_node+0x140/0x140
 [8155fa1c] ret_from_fork+0x7c/0xb0
 [8106f430] ? kthread_create_on_node+0x140/0x140


runnable tasks:
task   PID tree-key  switches  prio exec-runtime 
sum-execsum-sleep

--
 kswapd030   8689943.729790 36266   120   8689943.729790 
201495.640629  56609485.489414 /
 kworker/0:1 14790   8689937.729790 16969   120   8689937.729790 
  374.385996150405.181652 /
R   bash 14855   821.74926850   120   821.749268 
  24.027535  5252.291128 /autogroup-304





Mem-Info:
DMA per-cpu:
CPU0: hi:0, btch:   1 usd:   0
CPU1: hi:0, btch:   1 usd:   0
DMA32 per-cpu:
CPU0: hi:  186, btch:  31 usd: 146
CPU1: hi:  186, btch:  31 usd: 135
Normal per-cpu:
CPU0: hi:  186, btch:  31 usd: 131
CPU1: hi:  186, btch:  31 usd: 132
active_anon:726521 inactive_anon:26442 isolated_anon:0
 active_file:77765 inactive_file:76890 isolated_file:0
 unevictable:12 dirty:4 writeback:0 unstable:0
 free:40261 slab_reclaimable:12414 slab_unreclaimable:9694
 mapped:26382 shmem:162712 pagetables:6618 bounce:0
 free_cma:0
DMA free:15676kB min:272kB low:340kB high:408kB active_anon:208kB 
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15900kB mlocked:0kB dirty:0kB 
writeback:0kB mapped:0kB shmem:208kB slab_reclaimable:8kB 
slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB 
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes

lowmem_reserve[]: 0 2951 3836 3836
DMA32 free:126072kB min:51776kB low:64720kB high:77664kB active_anon:2175104kB 
inactive_anon:98976kB active_file:296252kB inactive_file:297648kB 
unevictable:48kB isolated(anon):0kB isolated(file):0kB present:3021960kB 
mlocked:48kB dirty:12kB writeback:0kB mapped:77664kB shmem:620388kB 
slab_reclaimable:19128kB slab_unreclaimable:6292kB kernel_stack:624kB 
pagetables:8900kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 885 885
Normal free:19296kB min:15532kB low:19412kB high:23296kB active_anon:730772kB 
inactive_anon:6792kB active_file:14808kB inactive_file:9912kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:906664kB mlocked:0kB dirty:4kB 
writeback:0kB mapped:27864kB shmem:30252kB slab_reclaimable:30520kB 
slab_unreclaimable:32476kB kernel_stack:2496kB pagetables:17572kB unstable:0kB 
bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0 0 0
DMA: 1*4kB 1*8kB 3*16kB 2*32kB 3*64kB 2*128kB 3*256kB 2*512kB 3*1024kB 
3*2048kB 1*4096kB = 15676kB
DMA32: 730*4kB 328*8kB 223*16kB 123*32kB 182*64kB 96*128kB 172*256kB 56*512kB 
12*1024kB 1*2048kB 1*4096kB

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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 - and I still see excessive
CPU usage - mainly  after  suspend/resume

Here is just simple  kswapd backtrace from running kernel:


Yup, this is what we were seeing with the former patch only too. Try to
apply the other one too:
https://patchwork.kernel.org/patch/1673231/

For me I would say, it is fixed by the two patches now. I won't be able
to report later, since I'm leaving to a conference tomorrow.


Damn it. It recurred right now, with both patches applied. After I
started a java program which consumed some more memory. Though there are
still 2 gigs free, kswap is spinning:
[] __cond_resched+0x2a/0x40
[] shrink_slab+0x1c0/0x2d0
[] kswapd+0x66d/0xb60
[] kthread+0xc0/0xd0
[] ret_from_fork+0x7c/0xb0
[] 0x


I'm also hitting this issue in v3.7-rc4.  It appears that the last
release not effected by this issue was v3.3.  Bisecting the changes
included for v3.4-rc1 showed that this commit introduced the issue:

fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit
commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c
Author: Rik van Riel 
Date:   Wed Mar 21 16:33:51 2012 -0700

 vmscan: reclaim at order 0 when compaction is enabled
...

This is plausible since the issue seems to be in the kswapd + compaction
realm.  I've yet to figure out exactly what about this commit results in
kswapd spinning.

I would be interested if someone can confirm this finding.

--
Seth




On my system 3.7-rc4 the problem seems to be effectively solved by revert 
patch: https://lkml.org/lkml/2012/11/5/308


i.e. in 2 days uptime kswapd0 eats 6 seconds which is IMHO ok - I'm not 
observing any busy loops on CPU with kswapd0.



Zdenek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd0: excessive CPU usage

[Zdenek Kabelac]

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 - and I still see excessive
CPU usage - mainly  after  suspend/resume

Here is just simple  kswapd backtrace from running kernel:


Yup, this is what we were seeing with the former patch only too. Try to
apply the other one too:
https://patchwork.kernel.org/patch/1673231/

For me I would say, it is fixed by the two patches now. I won't be able
to report later, since I'm leaving to a conference tomorrow.


Damn it. It recurred right now, with both patches applied. After I
started a java program which consumed some more memory. Though there are
still 2 gigs free, kswap is spinning:
[810b00da] __cond_resched+0x2a/0x40
[811318a0] shrink_slab+0x1c0/0x2d0
[8113478d] kswapd+0x66d/0xb60
[810a25d0] kthread+0xc0/0xd0
[816aa29c] ret_from_fork+0x7c/0xb0
[] 0x


I'm also hitting this issue in v3.7-rc4.  It appears that the last
release not effected by this issue was v3.3.  Bisecting the changes
included for v3.4-rc1 showed that this commit introduced the issue:

fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit
commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c
Author: Rik van Riel r...@redhat.com
Date:   Wed Mar 21 16:33:51 2012 -0700

 vmscan: reclaim at order 0 when compaction is enabled
...

This is plausible since the issue seems to be in the kswapd + compaction
realm.  I've yet to figure out exactly what about this commit results in
kswapd spinning.

I would be interested if someone can confirm this finding.

--
Seth




On my system 3.7-rc4 the problem seems to be effectively solved by revert 
patch: https://lkml.org/lkml/2012/11/5/308


i.e. in 2 days uptime kswapd0 eats 6 seconds which is IMHO ok - I'm not 
observing any busy loops on CPU with kswapd0.



Zdenek

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/