Description of problem: - I was running MATLAB, and MATLAB was accessing files on a HFS+ file system (*not* journaled) on a USB drive, via a bind filesystem to translate UID - The Fedora ABRT said the kernel crashed with "Bad page state in process MATLAB" - A look at /var/log/messages reveals many thousands of errors like this: May 4 20:54:08 magrathea kernel: [1402718.724883] hfsplus: recoff 26047 too large May 4 20:54:08 magrathea kernel: [1402718.724889] hfsplus: recoff 26047 too large May 4 20:54:08 magrathea kernel: hfsplus: recoff 26047 too large May 4 20:54:08 magrathea kernel: hfsplus: recoff 26047 too large <snip> - A quick count of the errors: [root@magrathea log]# fgrep hfsplus /var/log/messages |wc -l 39124 - Another count, 5 mins later, after typing this in: [root@magrathea log]# fgrep hfsplus /var/log/messages |wc -l 75770 Hope this is helpful. Not sure if I can reproduce. Additional info: reporter: libreport-2.2.1 BUG: Bad page state in process MATLAB pfn:1641fc page:ffffea0005907f00 count:0 mapcount:0 mapping: (null) index:0x2 page flags: 0x5ffff800000004(referenced) Modules linked in: vfat fat loop binfmt_misc nls_utf8 hfsplus usb_storage bnep bluetooth cfg80211 bridge stp llc fuse eeepc_wmi asus_wmi sparse_keymap iTCO_wdt rfkill iTCO_vendor_support mxm_wmi x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel raid1 snd_hda_codec_realtek ghash_clmulni_intel snd_hda_codec_hdmi joydev microcode serio_raw snd_hda_intel snd_hda_codec lpc_ich i2c_i801 mfd_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer mei_me snd mei soundcore shpchp wmi nfsd auth_rpcgss nfs_acl lockd sunrpc i915 i2c_algo_bit drm_kms_helper e1000e drm ptp pps_core i2c_core video [last unloaded: iptable_raw] CPU: 1 PID: 15665 Comm: MATLAB Not tainted 3.13.9-200.fc20.x86_64 #1 Hardware name: ASUS All Series/SABERTOOTH Z87, BIOS 1007 05/17/2013 0000000000000000 ffff8803c258bac8 ffffffff81687dac ffffea0005907f00 ffff8803c258bae0 ffffffff81685079 0000000000000000 ffff8803c258bbc8 ffffffff81153682 ffffffff811534eb 0000000000000002 ffff88041fde8b08 Call Trace: [<ffffffff81687dac>] dump_stack+0x45/0x56 [<ffffffff81685079>] bad_page.part.67+0xcf/0xe8 [<ffffffff81153682>] get_page_from_freelist+0x832/0x980 [<ffffffff811534eb>] ? get_page_from_freelist+0x69b/0x980 [<ffffffff81153d4f>] __alloc_pages_nodemask+0x57f/0xa80 [<ffffffff8119572a>] alloc_pages_vma+0x9a/0x140 [<ffffffff811a87dc>] do_huge_pmd_anonymous_page+0xfc/0x410 [<ffffffff81174b6b>] handle_mm_fault+0x19b/0xeb0 [<ffffffff81692434>] __do_page_fault+0x174/0x530 [<ffffffff810a65dc>] ? update_curr+0xcc/0x160 [<ffffffff810a2676>] ? __dequeue_entity+0x26/0x40 [<ffffffff810125f9>] ? __switch_to+0x169/0x4c0 [<ffffffff816927fe>] do_page_fault+0xe/0x10 [<ffffffff8168ef88>] page_fault+0x28/0x30
Created attachment 892341 [details] File: dmesg
For what it's worth, after rebooting from this I ran fsck.hfs on the filesystem, and it came back clean. So it does not appear to be a broken filesystem. /dev/sdi2: fsck_hfs run at Sun May 4 21:42:46 2014 /dev/sdi2: ** /dev/sdi2 /dev/sdi2: Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. ** Detected a case-sensitive volume. The volume name is WDBACKUP ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume WDBACKUP appears to be OK.
*********** 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.14.4-200.fc20. 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 experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 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.