Bug 846128 - [abrt]: BUG: Bad page state in process awn-applet pfn:3cac0
[abrt]: BUG: Bad page state in process awn-applet pfn:3cac0
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-08-06 18:07 EDT by collura
Modified: 2012-11-13 10:15 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-13 10:15:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description collura 2012-08-06 18:07:54 EDT
libreport version: 2.0.10
cmdline:        BOOT_IMAGE=/vmlinuz-3.3.8-1.fc16.x86_64 root=UUID=76d6aa89-d03b-4c61-b99c-dd6a53695430 ro

:BUG: Bad page state in process awn-applet  pfn:3cac0
:page:ffffea0000f2b000 count:0 mapcount:1 mapping:          (null) index:0x0
:page flags: 0x0()
:Modules linked in: fuse be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp fcoe libiscsi libfcoe libfc scsi_transport_fc scsi_tgt scsi_transport_iscsi 8021q garp stp llc rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter it87 hwmon_vid ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack uvcvideo videobuf2_core videodev media videobuf2_vmalloc videobuf2_memops joydev edac_core r592 memstick r852 sm_common nand nand_ids r8169 mii mtd k8temp nand_ecc serio_raw btusb edac_mce_amd sp5100_tco bluetooth i2c_piix4 snd_hda_codec_hdmi snd_hda_codec_si3054 snd_hda_codec_realtek arc4 snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device ath9k snd_pcm mac80211 ath9k_common ath9k_hw ath snd_timer asus_laptop cfg80211 sparse_keymap snd input_polldev soundcore rfkill snd_page_alloc sky2 uinput firewire_ohci ata_generic pata_acpi sdh
:ci_pci firewire_core sdhci mmc_core crc_itu_t pata_atiixp video radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
:Pid: 1844, comm: awn-applet Not tainted 3.3.8-1.fc16.x86_64 #1
:Call Trace:
: [<ffffffff81127a0f>] bad_page+0xbf/0x110
: [<ffffffff81129130>] get_page_from_freelist+0x6e0/0x8b0
: [<ffffffff811295c5>] __alloc_pages_nodemask+0x125/0x8f0
: [<ffffffff8112d57a>] ? pagevec_lru_move_fn+0xda/0xf0
: [<ffffffff8112d5ac>] ? __pagevec_lru_add+0x1c/0x20
: [<ffffffff8112d7a5>] ? __lru_cache_add+0x65/0x90
: [<ffffffff81150845>] ? page_add_new_anon_rmap+0xb5/0xd0
: [<ffffffff81162e6a>] alloc_pages_vma+0x9a/0x150
: [<ffffffff81175096>] do_huge_pmd_anonymous_page+0x146/0x380
: [<ffffffff81146f21>] handle_mm_fault+0x161/0x350
: [<ffffffff815f7fa2>] do_page_fault+0x142/0x4f0
: [<ffffffff81127b9a>] ? free_one_page+0x13a/0x340
: [<ffffffff8117c235>] ? mem_cgroup_bad_page_check+0x25/0x30
: [<ffffffff81128457>] ? free_pages_prepare+0x87/0x130
: [<ffffffff815ece77>] ? __slab_free+0xf3/0x1de
: [<ffffffff814da000>] ? skb_release_data+0x110/0x120
: [<ffffffff815f4b75>] page_fault+0x25/0x30
: [<ffffffff812ccc1d>] ? copy_user_generic_string+0x2d/0x40
: [<ffffffff814dd03f>] ? memcpy_toiovec+0x5f/0xb0
: [<ffffffff815837a9>] unix_stream_recvmsg+0x279/0x780
: [<ffffffff814cf732>] sock_aio_read.part.7+0x142/0x150
: [<ffffffff814cf76d>] sock_aio_read+0x2d/0x40
: [<ffffffff811809c2>] do_sync_read+0xd2/0x110
: [<ffffffff81269573>] ? security_file_permission+0x93/0xb0
: [<ffffffff81180e31>] ? rw_verify_area+0x61/0xf0
: [<ffffffff811813c5>] vfs_read+0x165/0x180
: [<ffffffff8118142a>] sys_read+0x4a/0x90
: [<ffffffff8119515b>] ? sys_poll+0x6b/0x100
: [<ffffffff815fc5e9>] system_call_fastpath+0x16/0x1b
Comment 1 Dave Jones 2012-08-07 12:13:13 EDT
These sorts of bugs are a really obscure, and a lot of the time when we see them they are indicative of some kind of hardware fault (like memory going bad).

That said, they can also occur from memory corruption caused by actual bugs.
Can you update to 3.4 and see if you can reproduce it ?

(If you have time, an overnight run of memtest86 might be a good thing too, just to rule out bad memory)
Comment 2 collura 2012-08-15 03:04:45 EDT
0) from comment#1, 
its certainly possible there is a hardware failure in progress 
but not sure where.  machine seems to behave if boot to another 
operating system that will remain nameless.

did run memtest86 off of fc17 live cd. :') 
ran in standard mode for 17 passes with zero errors 
during about 14hours of crunching.

might still be some hardware issue but didnt seem to be memory.
expect some sort of buss issue but cpu has to talk to bus to get to memory 
so should have shown in memory test, shrug.

1) seemed to come on all of a sudden along with a kernel update several weeks ago but was random enough that didnt figure out if so. :'\
nothing helpful ever seemed to get logged.

2) if no one else has this then will probably have to close this 
as insufficient info as i caved and upgraded the fc16 to fc17 
and deleted the active awn instances (though package still installed) 
to see if it was not awn related. :./

the upgrade also had the effect of morphing the 

 'kernel bug at mm/page_alloc.c: 777!
  invalid opcode: 0000 [#1] SMP
  CPU 1'

intermitant crash that had been getting in fc16 with


into something like

  mm/page_alloc.c: 796 error

that now intermitantly getting in fc17 with


and now i have no fc17 avant/awn in fc17 doh. ;.)

3) fyi: www.smolts.org/client/show/pub_4a40f7fb-5838-42ef-a3ca-0991630c175e
Comment 3 collura 2012-08-17 14:30:51 EDT
hmm not sure this should have helped the page_alloc crash from comment#2 i had but i think a yum downgrade to yum- fixed my issue thus clearing the kernel from questions?

i am wondering if the crash was related to me running yum.  i think the issue was running yum seemed to crash system with 'memory manager error page_alloc.c: 796' (before preupgrded from fc16 to fc17 was 'page_alloc.c: 777')?

wasnt able to update running yum or with updater gui without page_alloc crash so eventually tried to downgrade yum just in case.

probably unrelated but seemed to improve when i was able to 

  yum clean all
  yum downgrade yum-*

which downgraded me 
from yum- 
to   yum-

will have to run a while longer but wondering if that was the issue instead of a random memory crash.

if things stay stable will have to try upgrade back to yum- and see if the crash returns
in which case this bug would be closed. :.)
Comment 4 collura 2012-08-21 10:51:41 EDT

'warning: at mm/page_alloc.c:1488 get_page_from_freelist+0x86f/0x940()'

'process failed. nothing more can be done. thank you!'

show log:

--- Running report_uReport ---
(exited with 1)
Comment 5 Dave Jones 2012-10-23 11:27:15 EDT
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Comment 6 Justin M. Forbes 2012-11-13 10:15:13 EST
With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report.

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