Bug 1048442 - [abrt] BUG: Bad page state in process swapper pfn:3be36
Summary: [abrt] BUG: Bad page state in process swapper pfn:3be36
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:9b09b0e55a9c3cbc34e755df4e3...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-04 09:20 UTC by Benjamin
Modified: 2014-02-25 15:19 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-02-25 15:19:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: dmesg (70.90 KB, text/plain)
2014-01-04 09:20 UTC, Benjamin
no flags Details
journal dump incl. kernel messages from yesterday's boot (184.86 KB, text/plain)
2014-01-08 09:17 UTC, Benjamin
no flags Details

Description Benjamin 2014-01-04 09:20:39 UTC
Additional info:
reporter:       libreport-2.1.10
BUG: Bad page state in process swapper  pfn:3be36
page:ffffea0000ef8d80 count:0 mapcount:-8 mapping:          (null) index:0x0
page flags: 0x3ff00000000000()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.6-300.fc20.x86_64 #1
Hardware name: MSI MS-7640/990FXA-GD65 (MS-7640), BIOS V19.9 10/08/2012
 00000000fffffff8 ffffffff81c01e00 ffffffff816630c1 ffffea0000ef8d80
 ffffffff81c01e18 ffffffff81660208 0000000000000000 ffffffff81c01e60
 ffffffff81149645 ffffea0000ef9000 0000000000000002 ffffea0000ef8000
Call Trace:
 [<ffffffff816630c1>] dump_stack+0x45/0x56
 [<ffffffff81660208>] bad_page.part.67+0xcf/0xe8
 [<ffffffff81149645>] free_pages_prepare+0x165/0x170
 [<ffffffff8114a1dd>] __free_pages+0x2d/0x70
 [<ffffffff81d432c5>] __free_pages_bootmem+0xba/0xc6
 [<ffffffff81d46340>] __free_memory_core+0xee/0x130
 [<ffffffff81d46558>] free_all_bootmem+0x45/0x92
 [<ffffffff81d34724>] mem_init+0x5c/0x8d
 [<ffffffff81d1cccb>] start_kernel+0x1de/0x415
 [<ffffffff81d1c8f6>] ? repair_env_string+0x5c/0x5c
 [<ffffffff81d1c120>] ? early_idt_handlers+0x120/0x120
 [<ffffffff81d1c5de>] x86_64_start_reservations+0x2a/0x2c
 [<ffffffff81d1c6e8>] x86_64_start_kernel+0x108/0x117

Comment 1 Benjamin 2014-01-04 09:20:46 UTC
Created attachment 845294 [details]
File: dmesg

Comment 2 Josh Boyer 2014-01-06 14:55:43 UTC
Is this recreateable?  If so, can you attach the full dmesg output from a fresh boot?

Comment 3 Benjamin 2014-01-08 09:17:02 UTC
Created attachment 847033 [details]
journal dump incl. kernel messages from yesterday's boot

Hi,
I still don't know what to do to reproduce this, but it happened again yesterday, when I just switched on the machine to ssh into it.

complete journal (incl. kernel messages) from yesterday included.

Comment 4 Srikkanth 2014-02-17 17:54:45 UTC
I have been facing the similar issue. I could reproduce this when running "rsync" with large number of files (between USB drive and local filesystem). Kernel version 3.12.9-301.fc20.x86_64.

vendor_id	: AuthenticAMD
cpu family	: 21
model		: 1
model name	: AMD FX(tm)-8120 Eight-Core Processor
stepping	: 2
microcode	: 0x600063d
cpu MHz		: 1400.000
cache size	: 2048 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 16
initial apicid	: 0
fpu		: yes

Backtrace:

BUG: Bad page state in process swapper  pfn:2f3cd
page:ffffea0000bcf340 count:0 mapcount:-33554432 mapping:          (null) index:0x0
page flags: 0x3ff00000000000()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.9-301.fc20.x86_64 #1
Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 1903 07/11/2013
 00000000fe000000 ffffffff81c01e00 ffffffff81667af7 ffffea0000bcf340
 ffffffff81c01e18 ffffffff81664c44 0000000000000000 ffffffff81c01e60
 ffffffff81149715 ffffea0000bd0000 0000000000000002 ffffea0000bcf000
Call Trace:
 [<ffffffff81667af7>] dump_stack+0x45/0x56
 [<ffffffff81664c44>] bad_page.part.67+0xcf/0xe8
 [<ffffffff81149715>] free_pages_prepare+0x165/0x170
 [<ffffffff8114a2ad>] __free_pages+0x2d/0x70
 [<ffffffff81d4423f>] __free_pages_bootmem+0xba/0xc6
 [<ffffffff81d472ba>] __free_memory_core+0xee/0x130
 [<ffffffff81d474d2>] free_all_bootmem+0x45/0x92
 [<ffffffff81d3569e>] mem_init+0x5c/0x8d
 [<ffffffff81d1dccb>] start_kernel+0x1de/0x415
 [<ffffffff81d1d8f6>] ? repair_env_string+0x5c/0x5c
 [<ffffffff81d1d120>] ? early_idt_handlers+0x120/0x120
 [<ffffffff81d1d5de>] x86_64_start_reservations+0x2a/0x2c
 [<ffffffff81d1d6e8>] x86_64_start_kernel+0x108/0x117

# cat os_info 
NAME=Fedora
VERSION="20 (Heisenbug)"
ID=fedora
VERSION_ID=20
PRETTY_NAME="Fedora 20 (Heisenbug)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:20"
HOME_URL="https://fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=20
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=20

Comment 5 Justin M. Forbes 2014-02-24 13:57:31 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 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

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

Comment 6 Srikkanth 2014-02-25 05:29:37 UTC
Installed the memory test in grub using memtest-setup and upon running it showed many memory errors. Had to replace the memory with compatible to that of the motherboard. Running rsync after that went find without any issues. It turns out to be incompatible memory module.


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