Bug 979255 - Possible recursive locking lowmen_reserve
Summary: Possible recursive locking lowmen_reserve
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-28 05:19 UTC by David Highley
Modified: 2013-10-21 13:15 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-21 13:15:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Highley 2013-06-28 05:19:10 UTC
Description of problem:
Logout hangs

Version-Release number of selected component (if applicable):


How reproducible:
Possible memory leak as it takes several days for issue to occur

Steps to Reproduce:
1.
2.
3.

Actual results:
On logout hangs before getting back to Gnome user login selection screen

Expected results:


Additional info:
To clear the issue need to log into another system, ssh to system that has issue. Then do an init 3 followed by an init 5. Will not clear if done from the console on the system with the issue. Do not know if it is pertinate but the system with this issue has an Nvidia graphics card using nouveau driver.

Running a ps -efl command returns this infomation:
0 S root       647     1  0  80   0 - 35311 inotif Jun19 ?        00:00:01 /usr/bin/abrt-watch-log -F BUG: WARNING: at INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow (cur: eneral protection fault nable to handle kernel ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed : nobody cared IRQ handler type mismatch Machine Check Exception divide error: bounds: coprocessor segment overrun: invalid TSS: segment not present: invalid opcode: alignment check: stack segment: fpu exception: simd exception: iret exception: /var/log/messages -- /usr/bin/abrt-dump-oops -xD
0 S root       650     1  0  80   0 - 35311 inotif Jun19 ?        00:00:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD

The dmesg log has this information:
[595540.204307] active_anon:70719 inactive_anon:121254 isolated_anon:0
 active_file:1156919 inactive_file:1156566 isolated_file:0
 unevictable:875 dirty:158 writeback:0 unstable:0
 free:52517 slab_reclaimable:232420 slab_unreclaimable:69011
 mapped:28091 shmem:68269 pagetables:11651 bounce:0
 free_cma:0
[595540.204310] Node 0 DMA free:15892kB min:84kB low:104kB high:124kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB 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
[595540.204313] lowmem_reserve[]: 0 2948 11969 11969
[595540.204315] Node 0 DMA32 free:72624kB min:16624kB low:20780kB high:24936kB active_anon:12316kB inactive_anon:18764kB active_file:1131000kB inactive_file:1130112kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3120640kB managed:3018860kB mlocked:0kB dirty:0kB writeback:0kB mapped:8844kB shmem:2384kB slab_reclaimable:406112kB slab_unreclaimable:94972kB kernel_stack:96kB pagetables:4580kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:10
4 all_unreclaimable? no
[595540.204319] lowmem_reserve[]: 0 0 9021 9021
[595540.204320] Node 0 Normal free:121552kB min:50872kB low:63588kB high:76308kB active_anon:270560kB inactive_anon:466252kB active_file:3496336kB inactive_file:3496152kB unevictable:3500kB isolated(anon):0kB isolated(file):0kB present:9437184kB managed:9238028kB mlocked:3500kB dirty:632kB writeback:0kB mapped:103520kB shmem:270692kB slab_reclaimable:523568kB slab_unreclaimable:181056kB kernel_stack:4272kB pagetables:42024kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:138 all_unreclaimable? no
[595540.204324] lowmem_reserve[]: 0 0 0 0
[595540.204325] Node 0 DMA: 1*4kB (U) 0*8kB 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15892kB
[595540.204333] Node 0 DMA32: 5916*4kB (UEMR) 2714*8kB (UEMR) 1598*16kB (UEMR) 64*32kB (UEMR) 2*64kB (MR) 1*128kB (R) 1*256kB (R) 0*512kB 1*1024kB (R) 0*2048kB 0*4096kB = 74528kB
[595540.204340] Node 0 Normal: 20811*4kB (UEM) 2453*8kB (UEM) 802*16kB (UEM) 142*32kB (UEM) 31*64kB (M) 1*128kB (M) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 122356kB
[595540.204346] 2383350 total pagecache pages
[595540.204347] 1504 pages in swap cache
[595540.204349] Swap cache stats: add 11340, delete 9836, find 229880/230134
[595540.204349] Free swap  = 14349604kB
[595540.204350] Total swap = 14385148kB
[595540.237820] 3145727 pages RAM
[595540.237823] 71441 pages reserved
[595540.237824] 2288451 pages shared
[595540.237825] 1351239 pages non-shared

Comment 1 Josh Boyer 2013-07-01 15:34:22 UTC
Please attach the full dmesg output.  It looks like you're getting an OOM, which might be consistent with a memory leak.

Comment 2 Josh Boyer 2013-07-24 18:55:20 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Comment 3 David Highley 2013-08-15 05:05:28 UTC
The issue has happened again and this is after upgrading to Fedora 19.
The kernel version is 3.10.5-201.fc19.x86_64. I'm not seeing anything in the dmesg log other than this warning:

[    8.369990] ACPI Warning: 0x0000000000000828-0x000000000000082f SystemIO conflicts with Region \PMRG 1 (20130328/utaddress-251)
[    8.369996] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    8.370000] ACPI Warning: 0x0000000000000530-0x000000000000053f SystemIO conflicts with Region \GPS0 1 (20130328/utaddress-251)
[    8.370003] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    8.370005] ACPI Warning: 0x0000000000000500-0x000000000000052f SystemIO conflicts with Region \GPS0 1 (20130328/utaddress-251)
[    8.370008] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

I have no idea why from this information that I would have a possibly incorrect driver. Logwatch pulled this information from log files the last couple of days.

--------------------- Kernel Begin ------------------------ 

 WARNING:  Segmentation Faults in these executables
    pool :  1 Time(s)
 
 WARNING:  General Protection Faults in these executables
    traps: polkitd :  1 Time(s)
 
 ---------------------- Kernel End ------------------------- 



I see this information in the process listing.

0 S root       619     1  0  80   0 - 34618 inotif Aug10 ?        00:00:00 /usr/bin/abrt-watch-log -F BUG: WARNING: at INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow (cur: eneral protection fault nable to handle kernel ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed : nobody cared IRQ handler type mismatch Machine Check Exception divide error: bounds: coprocessor segment overrun: invalid TSS: segment not present: invalid opcode: alignment check: stack segment: fpu exception: simd exception: iret exception: /var/log/messages -- /usr/bin/abrt-dump-oops -xD


4 S root      7426  7419  0  80   0 - 28798 wait   Aug10 ?        00:00:00 /bin/sh -c nice sosreport --tmp-dir "$DUMP_DIR" --batch \                 --only=anaconda --only=bootloader --only=devicemapper \                 --only=filesys --only=hardware --only=kernel --only=libraries \                 --only=memory --only=networking --only=nfsserver --only=pam \                 --only=process --only=rpm -k rpm.rpmva=off --only=ssh \                 --only=startup --only=yum --only=general --only=x11 \                 >sosreport.log 2>&1 \         && {                 rm sosreport.log                 rm sosreport*.md5                 mv sosreport*.tar.bz2 sosreport.tar.bz2                 mv sosreport*.tar.xz sosreport.tar.xz                 exit 0         } 2>/dev/null         # Error in sosreport run. Let user see the problem.         echo "sosreport run failed with exit code $?, log follows:"         # sosreport prints many useless empty lines, nuke them:         # it looks awful in syslog otherwise.         cat sosreport.log | sed 's/  *$//' | grep -v '^$'         rm sosreport.log         exit 1
4 S root      7427  7426  0  90  10 - 108581 read_g Aug10 ?       00:00:02 /usr/bin/python /usr/sbin/sosreport --tmp-dir /var/tmp/abrt/ccpp-2013-08-10-22:21:54-7221 --batch --only=anaconda --only=bootloader --only=devicemapper --only=filesys --only=hardware --only=kernel --only=libraries --only=memory --only=networking --only=nfsserver --only=pam --only=process --only=rpm -k rpm.rpmva=off --only=ssh --only=startup --only=yum --only=general --only=x11
1 S root      9950     2  0  80   0 -     0 worker 13:30 ?        00:00:01 [kworker/4:2]

Comment 4 Justin M. Forbes 2013-10-18 21:09:18 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs.

Fedora 18 has now been rebased to 3.11.4-101.fc18.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19.

If you experience different issues, please open a new bug report for those.

Comment 5 David Highley 2013-10-19 04:23:41 UTC
As documented above we saw the issue or something that appeared the same after updating to Fedora 19. We are no longer experiencing this issue.


Note You need to log in before you can comment on or make changes to this bug.