On Thu, 28 Sep 2006 13:42:26 -0700
Jeremy Fitzhardinge <[email protected]> wrote:
> I just filed this in the Redhat bugzilla, since its from the FC6 distro
> kernel. But since its fairly close to current kernel.org kernels, I
> thought it might be relevent.
>
> The bug is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208488
>
> Unfortunately this isn't a very useful report since it was a once-off,
> and there's a P-tainting module in there. But if anyone sees anything
> else like this, it's interesting.
>
> The oops is:
>
> BUG: unable to handle kernel paging request at virtual address 756e6547
756e6547 -> uneG. Matches "GenuineIntel".
That'll get written into a temporary page by the /proc/cpuinfo handler, so
it might just be a use-uninitialised.
> printing eip:
> f898bf73
> *pde = 0014c7c0
> Oops: 0002 [#1]
> SMP
> last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
> Modules linked in: ath_pci(U) usb_storage loop wlan_wep(U) snd_hda_codec nfsd exportfs lockd nfs_acl tun ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc airprime usbserial hci_usb cpufreq_powersave i915 drm cpufreq_conservative ipv6 autofs4 hidp rfcomm l2cap bluetooth sunrpc ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables vfat fat dm_mirror dm_mod video sbs ibm_acpi i2c_ec dock button battery asus_acpi ac parport_pc lp parport snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq wlan_scan_sta(U) snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm ath_rate_sample(U) mmc_block snd_timer snd sg ohci1394 i2c_i801 wlan(U) ieee1394 sdhci soundcore pcspkr i2c_core snd_page_alloc serio_raw e1000 mmc_core ath_hal(U) ahci libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
> CPU: 0
> EIP: 0060:[<f898bf73>] Tainted: P VLI
> EFLAGS: 00013206 (2.6.18-1.2689.fc6PAE #1)
> EIP is at ext3_clear_inode+0x52/0x8b [ext3]
> eax: c07dda80 ebx: c07dd994 ecx: 00000000 edx: 756e6547
> esi: c07dda80 edi: 00000000 ebp: f3f0cda0 esp: f3f0cd94
> ds: 007b es: 007b ss: 0068
> Process Xorg (pid: 2862, ti=f3f0c000 task=f3cf4030 task.ti=f3f0c000)
> Stack: c07dda80 c07ddc9c 0000001f f3f0cdb0 c04881e5 c07dda80 c07dda88 f3f0cdc8
> c04884ba f3f0cdd8 c0bf3db0 00000000 00000080 f3f0cdec c04886c6 00000080
> 00000080 c07dddb8 f32d1428 0000620c f7ff62fc 000000a9 f3f0ce1c c045ba2d
> Call Trace:
> [<c04881e5>] clear_inode+0xd8/0x129
> [<c04884ba>] dispose_list+0x3c/0xc1
> [<c04886c6>] shrink_icache_memory+0x187/0x1af
> [<c045ba2d>] shrink_slab+0xd0/0x137
> [<c045c285>] try_to_free_pages+0x159/0x218
> [<c045860d>] __alloc_pages+0x199/0x287
> [<c045f3b8>] __handle_mm_fault+0x1b2/0xb84
> [<c0614a5a>] do_page_fault+0x2b1/0x5ba
> [<c0404be9>] error_code+0x39/0x40
It's relatively common for that big inode LRU walk to wander off in the
wrong direction and to start operating on random memory.
IOW: don't know. Something scribbled on memory somewhere.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
