What's holding this up? I'm getting a pretty regular oops that this series would have fixed. I have a temporary workaround patch attached, but it would conflict with this, and I'd hate to muck up its merge. [127227.081586] IP: [<c011c5bb>] show_mem+0x8b/0x250 [127227.091751] Oops: 0000 [#1] SMP [127227.095152] Modules linked in: kqemu authenc esp4 aead xfrm4_mode_tunnel nls_iso8859_1 vfat fat rfcomm l2cap kvm_intel kvm tun ppdev acpi_cpufreq cpufreq_stats cpufreq_ondemand freq_table cpufreq_powersave cpufreq_userspace cpufreq_conservative sbs container sbshc iptable_filter ip_tables x_tables deflate zlib_deflate des_generic cbc aes_generic xcbc sha256_generic sha1_generic af_key dummy dm_crypt dm_mod lp joydev snd_hda_intel snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss af_packet snd_seq_midi_event snd_seq arc4 ecb usbhid snd_timer pcmcia crypto_blkcipher usb_storage snd_seq_device psmouse thinkpad_acpi iwl4965 iwlcore hid serio_raw libusual hci_usb sdhci mac80211 led_class snd parport_pc parport mmc_core ricoh_mmc yenta_socket rsrc_nonstatic pcmcia_core button soundcore cfg80211 nvram evdev snd_page_alloc ohci1394 ieee1394 ehci_hcd uhci_hcd usbcore e1000 thermal processor fan fuse [127227.095152] [127227.095152] Pid: 0, comm: swapper Not tainted (2.6.26-rc8-00089-ge1441b9 #24) [127227.095152] EIP: 0060:[<c011c5bb>] EFLAGS: 00010206 CPU: 0 [127227.095152] EIP is at show_mem+0x8b/0x250 [127227.095152] EAX: 01800000 EBX: 000c0000 ECX: 00000018 EDX: 01800000 [127227.095152] ESI: c04b5700 EDI: 0013c000 EBP: c0536e10 ESP: c0536de8 [127227.095152] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [127227.095152] Process swapper (pid: 0, ti=c0536000 task=c04afa40 task.ti=c04e8000) [127227.095152] Stack: c04574fa 00000000 00088000 0000000b 00060e45 00002f19 000c0001 c04b6b24 [127227.095152] c04afa40 00004020 c0536e5c c016b067 c045fddc c04afd41 00000002 00004020 [127227.095152] c04b6b04 00000000 00000032 00000000 00000001 00000000 c04b6b00 00000002 [127227.095152] Call Trace: [127227.095152] [<c016b067>] ? __alloc_pages_internal+0x3d7/0x420 [127227.095152] [<c016b0c2>] ? __alloc_pages+0x12/0x20 [127227.095152] [<c016b102>] ? __get_free_pages+0x12/0x30 [127227.095152] [<c018d262>] ? __kmalloc_track_caller+0xd2/0x100 [127227.095152] [<c031bb44>] ? skb_copy+0x34/0x90 [127227.095152] [<c031b43b>] ? __alloc_skb+0x4b/0x100 [127227.095152] [<c031bb44>] ? skb_copy+0x34/0x90 [127227.095152] [<f8ba234b>] ? __ieee80211_rx_handle_packet+0x13b/0x1f0 [mac80211] [127227.095152] [<f8ba2906>] ? __ieee80211_rx+0xb6/0xc0 [mac80211] [127227.095152] [<f8b91ad3>] ? ieee80211_tasklet_handler+0x103/0x110 [mac80211] [127227.095152] [<c013257b>] ? tasklet_action+0xcb/0xe0 [127227.095152] [<c0132161>] ? __do_softirq+0x81/0x110 [127227.095152] [<c0105f1e>] ? do_softirq+0x6e/0xd0 [127227.095152] [<c0160cd0>] ? handle_fasteoi_irq+0x0/0xd0 [127227.095152] [<c0132255>] ? irq_exit+0x45/0x50 [127227.095152] [<c0105da1>] ? do_IRQ+0x91/0xf0 [127227.095152] [<c010479b>] ? common_interrupt+0x23/0x28 [127227.095152] [<c014007b>] ? sys_timer_create+0xeb/0x2a0 [127227.095152] [<f8862079>] ? acpi_processor_idle+0x30f/0x47c [processor] [127227.095152] [<f8861d6a>] ? acpi_processor_idle+0x0/0x47c [processor] [127227.095152] [<c0102122>] ? cpu_idle+0x92/0xe0 [127227.095152] [<c038d6de>] ? rest_init+0x4e/0x50 [127227.095152] ======================= [127227.095152] Code: f7 c3 ff 03 00 00 0f 84 bc 01 00 00 8b 86 34 14 00 00 ff 45 f0 01 d8 89 c2 c1 ea 11 8b 14 d5 00 a3 59 c0 c1 e0 05 83 e2 fc 01 c2 <8b> 0a 89 c8 c1 e8 17 83 e0 03 8d 04 80 c1 e0 08 05 00 57 4b c0 [127227.095152] EIP: [<c011c5bb>] show_mem+0x8b/0x250 SS:ESP 0068:c0536de8 [127227.704832] Kernel panic - not syncing: Fatal exception in interrupt -- Dave >From 55b1d0caade20e9597e07759d923f6ce1350e522 Mon Sep 17 00:00:00 2001 From: Dave Hansen <dave@xxxxxxxx> Date: Tue, 15 Jul 2008 10:32:56 -0700 Subject: [PATCH] fix i386 show_mem() oops I've had the occasional kernel hang with 2.6.26 since I upgraded my laptop to 4G of RAM. But, I have a hole at 3-4GB, so I need PAE, and I'm running with SPARSEMEM=y. I figured it was something to do with PAE, but never got a clean oops until this morning. The oops was in show_mem()'s pgdat_page_nr(). It was passing a pfn of a page from the memory hole and oopsing. Dumping my sparsemem section table, you can clearly see the hole: 00000000 03 10 00 c1 00 02 00 c1 03 10 00 c1 80 02 00 c1 |................| 00000010 03 10 00 c1 00 03 00 c1 03 10 00 c1 80 03 00 c1 |................| 00000020 03 10 00 c1 00 04 00 c1 03 10 00 c1 80 04 00 c1 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 03 10 80 c0 00 05 00 c1 03 10 80 c0 80 05 00 c1 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 The sections are 512MB, and you can see 6 valid ones followed by two holes, and then two more valid ones. Anyway, I believe this patch will fix the oops. --- arch/x86/mm/pgtable_32.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/mm/pgtable_32.c b/arch/x86/mm/pgtable_32.c index 369cf06..eb2a480 100644 --- a/arch/x86/mm/pgtable_32.c +++ b/arch/x86/mm/pgtable_32.c @@ -37,6 +37,8 @@ void show_mem(void) for (i = 0; i < pgdat->node_spanned_pages; ++i) { if (unlikely(i % MAX_ORDER_NR_PAGES == 0)) touch_nmi_watchdog(); + if (!pfn_valid(pgdat->node_start_pfn + i)) + continue; page = pgdat_page_nr(pgdat, i); total++; if (PageHighMem(page)) -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html