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
BLDK support not planned for 1.3, so this is a no-op for 1.3.
Scott G. is seeing something similar on FRI2. Scott, does the "nopat" kernel parameter resolve issues for you on the FRI2?
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.
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.
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
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?
(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.
Could someone update this bug please? Is this fixed for 1.4?
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)
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