2364 2012-04-23 15:05:21 +0000 crownbay: bad_page_state with BLDK2 boot 2014-05-12 21:58:51 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-configuration unspecified Other Multiple RESOLVED FIXED Medium normal 1.6 1 tom.zanussi tom.zanussi dvhart jessica.zhang richard.purdie scott.a.garman yp.bsp.watcher yp.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 20819 0 tom.zanussi 2012-04-23 15:05:21 +0000 While bringing up a demo using crownbay, several BUG warnings were noted, which however didn't seem to affect system operation. The affected pages always had 'uncached' page flags as the cause of the BUG, and on all the systems, there were always 14 pages affected, a group of 10 and another group of 4. The kernel was 3.2, but the same problem existed with 3.0. The problem was the same with or without emgd. The problem 'goes away' if you boot with the 'nopat' Filing this as a low priority bug, mainly to keep track of the info until such time as we officially support bldk2. BUG: Bad page state in process pango-querymodu pfn:38960 page:f6ebfc00 count:0 mapcount:0 mapping: (null) index:0x0 page flags: 0x80400000(uncached) Modules linked in: ipv6 minix Pid: 1512, comm: pango-querymodu Tainted: G W 3.2.11-yocto-standard #1 Call Trace: [<c10bbf0f>] bad_page+0x8f/0xe0 [<c10bc4ce>] get_page_from_freelist+0x3ee/0x480 [<c10bc64b>] __alloc_pages_nodemask+0xeb/0x660 [<c11f5d02>] ? blk_finish_plug+0x12/0x40 [<c10bfaa3>] __do_page_cache_readahead+0xe3/0x1f0 [<c10ebe0f>] ? memcg_check_events+0x3f/0x1c0 [<c10bfe37>] ra_submit+0x27/0x30 [<c10b8811>] filemap_fault+0x361/0x3d0 [<c10c0ce3>] ? __lru_cache_add+0x63/0xb0 [<c10eaf7f>] ? mem_cgroup_update_page_stat+0x6f/0x120 [<c10d2e50>] __do_fault+0x60/0x460 [<c10d5551>] handle_pte_fault+0xe1/0x6b0 [<c10d77c3>] ? __vma_link_file+0x43/0x70 [<c10d5bc6>] handle_mm_fault+0xa6/0x120 [<c14f6bc0>] ? spurious_fault+0xcd/0xcd [<c14f6cb9>] do_page_fault+0xf9/0x490 [<c10f0375>] ? filp_close+0x55/0x80 [<c14f70c3>] ? sub_preempt_count+0x73/0xb0 [<c10f0413>] ? sys_close+0x73/0xc0 [<c14f6bc0>] ? spurious_fault+0xcd/0xcd [<c14f4c0a>] error_code+0x5a/0x60 [<c14f6bc0>] ? spurious_fault+0xcd/0xcd 21148 1 tom.zanussi 2012-05-07 20:31:05 +0000 BLDK support not planned for 1.3, so this is a no-op for 1.3. 21393 2 dvhart 2012-05-16 23:01:17 +0000 Scott G. is seeing something similar on FRI2. Scott, does the "nopat" kernel parameter resolve issues for you on the FRI2? 21396 3 scott.a.garman 2012-05-17 00:22:15 +0000 No, I can still reproduce the panic with the nopat option if I hammer on the disk a bit, e.g, dd a 5 MB file and then sync. I've tried with a few different USB thumbdrives to rule out a bad drive. 21400 4 tom.zanussi 2012-05-17 01:53:06 +0000 Scott, it would be good for you to add your stack trace, since it may be the same thing or something different. Also, is this an EFI boot? I'm also wondering what about it suggested that it was related to the USB thumbdrive. 21402 5 scott.a.garman 2012-05-17 03:34:50 +0000 I'm booting the FRI2 using the .hddimage on a USB thumbdrive, so I'm not using internal flash. That's why at first I was suspicous it might be due to the thumbdrive. I'll get a ton of these in dmesg when the problem occurs. It generally happens when doing disk I/O, and it's clear when it occurs because the system hangs for 15 seconds or so. BUG: Bad page state in process loop0 pfn:38c3a page:f6d57740 count:0 mapcount:0 mapping: (null) index:0x0 page flags: 0x80400000(uncached) Modules linked in: Pid: 474, comm: loop0 Tainted: G B W 3.2.11-yocto-standard #1 Call Trace: [<c10bcaef>] bad_page+0x8f/0xe0 [<c10bd0ab>] get_page_from_freelist+0x40b/0x4b0 [<c10bd23b>] __alloc_pages_nodemask+0xeb/0x640 [<c1001b2b>] ? __switch_to+0x1b/0x210 [<c1513295>] ? _raw_spin_unlock_irq+0x15/0x40 [<c103264b>] ? get_parent_ip+0xb/0x40 [<c10c0694>] __do_page_cache_readahead+0xe4/0x210 [<c1063794>] ? ktime_get_ts+0xc4/0xf0 [<c10c0a47>] ra_submit+0x27/0x30 [<c10c0b87>] ondemand_readahead+0x137/0x230 [<c10c0cfe>] page_cache_async_readahead+0x7e/0xa0 [<c111ac20>] __generic_file_splice_read+0x370/0x5c0 [<c1119500>] ? page_cache_pipe_buf_release+0x20/0x20 [<c10338e6>] ? load_balance+0x76/0x6d0 [<c103264b>] ? get_parent_ip+0xb/0x40 [<c103264b>] ? get_parent_ip+0xb/0x40 [<c1516373>] ? sub_preempt_count+0x43/0xb0 [<c1021efe>] ? __kunmap_atomic+0x3e/0x90 [<c12c0d90>] ? loop_make_request+0xf0/0xf0 [<c12c0462>] ? lo_splice_actor+0x92/0xd0 [<c11e4764>] ? security_file_permission+0x94/0xb0 [<c111aee4>] generic_file_splice_read+0x74/0xe0 [<c12c03d0>] ? unregister_transfer_cb+0x60/0x60 [<c111ae70>] ? __generic_file_splice_read+0x5c0/0x5c0 [<c1119871>] vfs_splice_to+0x61/0x80 [<c111993a>] splice_direct_to_actor+0xaa/0x1d0 [<c12c0c80>] ? loop_thread+0x530/0x530 [<c12c09ed>] loop_thread+0x29d/0x530 [<c12c0700>] ? do_lo_send_write+0x90/0xe0 [<c12c0750>] ? do_lo_send_write+0xe0/0xe0 [<c1059daf>] kthread+0x6f/0x80 [<c1059d40>] ? kthread_worker_fn+0x150/0x150 [<c1519b36>] kernel_thread_helper+0x6/0x10 root@fri2-noemgd:~# uname -a Linux fri2-noemgd 3.2.11-yocto-standard #1 SMP PREEMPT Mon May 14 11:13:17 PDT 2012 i686 GNU/Linux The kernel was built using meta-intel 96df30005bbc8095713d03956e7f9058a2e97561 22225 6 dvhart 2012-06-14 20:45:03 +0000 Is this the one we determined was fixed with http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/commit/?h=tzanussi/ioremap-fix&id=a789b047d9ca2a850282d7a49c4d386895f9bd4e ? Seems easy enough to pull in for 1.3 M2. Do you recall why we set this to 1.4? 22227 7 tom.zanussi 2012-06-14 20:57:28 +0000 (In reply to comment #6) > Is this the one we determined was fixed with > http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/commit/ > ?h=tzanussi/ioremap-fix&id=a789b047d9ca2a850282d7a49c4d386895f9bd4e ? Seems > easy enough to pull in for 1.3 M2. Do you recall why we set this to 1.4? IIRC it was because we didn't have bldk2 in the 1.3 plans. 32223 8 richard.purdie 2013-04-16 11:15:59 +0000 Could someone update this bug please? Is this fixed for 1.4? 32247 9 tom.zanussi 2013-04-16 14:46:22 +0000 This isn't a problem in 1.4 - the following patch in the linux-yocto kernels gets rid of the problem for the platforms that support efi i.e. fri2, but we need to revisit it in 1.5 - we shouldn't need a patch that special-cases 64-bit (to remove the offending code from 32-bit in this case). Author: Tom Zanussi <tom.zanussi@intel.com> Date: Thu Oct 25 01:26:54 2012 -0700 efi: Add patch to fix 32bit EFI service mapping (rhbz 726701) From fedora kernel: commit 6f3e186bc7721c5b24ad90d4a751cccfccd445e6 Author: Josh Boyer <jwboyer@redhat.com> Date: Fri Aug 5 08:47:23 2011 -0400 Add patch to fix 32bit EFI service mapping (rhbz 726701) 43268 10 tom.zanussi 2014-05-12 21:58:51 +0000 This is now upstream as: commit 700870119f49084da004ab588ea2b799689efaf7 Author: Josh Boyer <jwboyer@redhat.com> Date: Thu Apr 18 07:51:34 2013 -0700 x86, efi: Don't map Boot Services on i386