Bug 1056304 - general protection fault: 0000 [#1] SMP [NEEDINFO]
Summary: general protection fault: 0000 [#1] SMP
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: fs-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-21 23:07 UTC by H.J. Lu
Modified: 2014-03-17 18:45 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-03-17 18:45:10 UTC
Type: Bug
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)
Another ext4 crash on the same machine (3.59 MB, image/jpeg)
2014-01-21 23:20 UTC, H.J. Lu
no flags Details
Another crash (3.57 MB, image/jpeg)
2014-01-22 20:45 UTC, H.J. Lu
no flags Details

Description H.J. Lu 2014-01-21 23:07:26 UTC
When I was copying a directory with many many files from
one HD to another, I got

[ 1961.747832] general protection fault: 0000 [#1] SMP 
[ 1961.747842] Modules linked in: fuse ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack xt_CHECKSUM iptable_mangle tun bridge stp llc ip6table_filter ip6_tables ebtable_nat ebtables bnep bluetooth cfg80211 rfkill ses enclosure x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul iTCO_wdt crc32c_intel iTCO_vendor_support snd_hda_codec_realtek usb_storage ghash_clmulni_intel ppdev snd_hda_intel microcode snd_hda_codec serio_raw snd_hwdep i2c_i801 snd_seq lpc_ich snd_seq_device mfd_core snd_pcm r8169 mii snd_page_alloc snd_timer snd mei_me mei soundcore shpchp parport_pc parport nfsd auth_rpcgss nfs_acl lockd sunrpc nouveau mxm_wmi wmi i2c_algo_bit drm_kms_helper ttm drm i2c_core video
[ 1961.747908] CPU: 2 PID: 80 Comm: kswapd0 Tainted: G          I  3.12.8-300.0.fc20.x86_64 #1
[ 1961.747911] Hardware name: Gigabyte Technology Co., Ltd. H87M-D3H/H87M-D3H, BIOS F6 08/03/2013
[ 1961.747914] task: ffff88080f058000 ti: ffff88080f054000 task.ti: ffff88080f054000
[ 1961.747916] RIP: 0010:[<ffffffff811512b9>]  [<ffffffff811512b9>] truncate_inode_pages_range+0x29/0x5c0
[ 1961.747923] RSP: 0018:ffff88080f055ad0  EFLAGS: 00010282
[ 1961.747925] RAX: fdff8807dea826d1 RBX: ffffffffffffffff RCX: 0000000000008000
[ 1961.747928] RDX: ffffffffffffffff RSI: 0000000000000000 RDI: ffff8807dea82820
[ 1961.747930] RBP: ffff88080f055b90 R08: e038000000000000 R09: 07dea827701c0000
[ 1961.747932] R10: f80359d039eddc07 R11: 00000000000003ed R12: 0000000000000000
[ 1961.747934] R13: ffffffff8182ccc0 R14: 0000000000000229 R15: 0000000000000000
[ 1961.747937] FS:  0000000000000000(0000) GS:ffff88083dc80000(0000) knlGS:0000000000000000
[ 1961.747939] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1961.747941] CR2: 00007fa2f8139000 CR3: 0000000001c0e000 CR4: 00000000001407e0
[ 1961.747943] Stack:
[ 1961.747945]  ffff88083dfe8d80 ffff88080f055b58 ffff8807dea82820 ffff8807dea82250
[ 1961.747950]  ffffffff812675f8 ffff8807dea82568 0000000000000000 ffff88080ecad800
[ 1961.747957]  ffff8807dea82550 ffff88080f055b18 ffff88080f055b18 ffff880781d64de8
[ 1961.747961] Call Trace:
[ 1961.747966]  [<ffffffff812675f8>] ? ext4_discard_preallocations+0x78/0x410
[ 1961.747971]  [<ffffffff811d6172>] ? __inode_wait_for_writeback+0x72/0xc0
[ 1961.747974]  [<ffffffff81151865>] truncate_inode_pages+0x15/0x20
[ 1961.747977]  [<ffffffff81237f82>] ext4_evict_inode+0x72/0x4f0
[ 1961.747980]  [<ffffffff811c8c6f>] evict+0x9f/0x190
[ 1961.747983]  [<ffffffff811c8d9e>] dispose_list+0x3e/0x50
[ 1961.747985]  [<ffffffff811c9bf7>] prune_icache_sb+0x47/0x60
[ 1961.747989]  [<ffffffff811b2819>] super_cache_scan+0xf9/0x160
[ 1961.747992]  [<ffffffff81153ecf>] shrink_slab+0x1cf/0x380
[ 1961.747995]  [<ffffffff811568f7>] kswapd_shrink_zone+0x117/0x1b0
[ 1961.747998]  [<ffffffff81157c3c>] kswapd+0x45c/0x840
[ 1961.748073]  [<ffffffff811577e0>] ? mem_cgroup_shrink_node_zone+0x120/0x120
[ 1961.748078]  [<ffffffff8108b1b0>] kthread+0xc0/0xd0
[ 1961.748081]  [<ffffffff8108b0f0>] ? insert_kthread_work+0x40/0x40
[ 1961.748086]  [<ffffffff81676ebc>] ret_from_fork+0x7c/0xb0
[ 1961.748088]  [<ffffffff8108b0f0>] ? insert_kthread_work+0x40/0x40
[ 1961.748090] Code: 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 f4 53 48 89 d3 48 81 ec 98 00 00 00 48 8b 07 48 89 bd 50 ff ff ff <48> 8b 40 28 44 8b 98 58 03 00 00 45 85 db 78 05 e8 f2 a7 05 00 
[ 1961.748158] RIP  [<ffffffff811512b9>] truncate_inode_pages_range+0x29/0x5c0
[ 1961.748167]  RSP <ffff88080f055ad0>
[ 1961.751252] ---[ end trace 7f79e7d8fdecb369 ]---

Comment 1 H.J. Lu 2014-01-21 23:20:54 UTC
Created attachment 853505 [details]
Another ext4 crash on the same machine

Comment 2 H.J. Lu 2014-01-22 00:15:24 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1043729

is also a general protection fault on the same platform:

Gigabyte Technology Co., Ltd. H87M-D3H/H87M-D3H, BIOS F6 08/03/2013

I don't know if they are related. My machine has Intel Core i7-4770K
CPU, 32GB RAM, 800GB Intel SSD DC S3500 and Seagate Constellation
ES ST31000524NS 1TB HD. Kernel crash happened when I was copying
100GB data from Seagate HD to SSD and I was also running chrome
browser.

Comment 3 Eric Sandeen 2014-01-22 00:17:23 UTC
You might try running kernel-debug and see if any extra information turns up if you hit the crash again...

Comment 4 H.J. Lu 2014-01-22 00:22:48 UTC
(In reply to Eric Sandeen from comment #3)
> You might try running kernel-debug and see if any extra information turns up
> if you hit the crash again...

I will.  But it may not happen to me again since copying
100GB stuff from HD to SSD was a one-time thing on this
machine.

Comment 5 H.J. Lu 2014-01-22 20:45:21 UTC
Created attachment 854030 [details]
Another crash

Comment 6 Eric Sandeen 2014-01-22 20:54:31 UTC
Comment on attachment 854030 [details]
Another crash

Not enough there to go on, you've got the actual oops trimeed off.

Random snippets of backtrace don't help a whole lot...

Comment 7 Justin M. Forbes 2014-02-24 13:55:59 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 8 Justin M. Forbes 2014-03-17 18:45:10 UTC
*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.


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