* 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b
@ 2006-09-28 20:42 Jeremy Fitzhardinge
2006-09-28 20:48 ` James Morris
2006-09-28 21:23 ` Andrew Morton
0 siblings, 2 replies; 10+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-28 20:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailing List
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
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
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
[<c040537f>] show_stack_log_lvl+0x8a/0x95
[<c04054b7>] show_registers+0x12d/0x19a
[<c04056b4>] die+0x190/0x293
[<c0614c91>] do_page_fault+0x4e8/0x5ba
[<c0404be9>] error_code+0x39/0x40
[<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
Code: 0f 94 c0 84 c0 74 07 89 d0 e8 c4 0e ae c7 c7 83 90 00 00 00 ff ff ff ff 8b 93 94 00 00 00 85 d2 74 24 83 fa ff 74 1f 85 d2 74 11 <f0> ff 0a 0f 94 c0 84 c0 74 07 89 d0 e8 96 0e ae c7 c7 83 94 00
EIP: [<f898bf73>] ext3_clear_inode+0x52/0x8b [ext3] SS:ESP 0068:f3f0cd94
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b
2006-09-28 20:42 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b Jeremy Fitzhardinge
@ 2006-09-28 20:48 ` James Morris
2006-09-28 21:00 ` Jeremy Fitzhardinge
2006-09-28 21:23 ` Andrew Morton
1 sibling, 1 reply; 10+ messages in thread
From: James Morris @ 2006-09-28 20:48 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Andrew Morton, Linux Kernel Mailing List
On Thu, 28 Sep 2006, Jeremy Fitzhardinge wrote:
> BUG: unable to handle kernel paging request at virtual address 756e6547
> 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
Seems that one of the modules tainted the kernel. Any idea which?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b
2006-09-28 20:42 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b Jeremy Fitzhardinge
2006-09-28 20:48 ` James Morris
@ 2006-09-28 21:23 ` Andrew Morton
2006-09-28 21:26 ` Jeremy Fitzhardinge
2006-10-03 5:32 ` Eric Sandeen
1 sibling, 2 replies; 10+ messages in thread
From: Andrew Morton @ 2006-09-28 21:23 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Linux Kernel Mailing List
On Thu, 28 Sep 2006 13:42:26 -0700
Jeremy Fitzhardinge <jeremy@goop.org> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b
2006-09-28 21:23 ` Andrew Morton
@ 2006-09-28 21:26 ` Jeremy Fitzhardinge
2006-10-03 5:32 ` Eric Sandeen
1 sibling, 0 replies; 10+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-28 21:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailing List
Andrew Morton wrote:
> 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.
>
I was compiling a kernel at the time, so it could have come from the
kernel source.
> 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.
>
Yep, that was as far as I got...
J
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b
2006-09-28 21:23 ` Andrew Morton
2006-09-28 21:26 ` Jeremy Fitzhardinge
@ 2006-10-03 5:32 ` Eric Sandeen
2006-10-03 5:42 ` Adrian Bunk
1 sibling, 1 reply; 10+ messages in thread
From: Eric Sandeen @ 2006-10-03 5:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jeremy Fitzhardinge, Linux Kernel Mailing List
Andrew Morton wrote:
> On Thu, 28 Sep 2006 13:42:26 -0700
> Jeremy Fitzhardinge <jeremy@goop.org> 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.
But strangely enough, it's the second report we've seen with this exact
backtrace, and the same "Genu" ascii string where the i_default_acl should be.
Both boxes had been through a suspend-to-ram recently, just in case that might
matter.
Seems like something more than random chance...
-Eric
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b
2006-10-03 5:32 ` Eric Sandeen
@ 2006-10-03 5:42 ` Adrian Bunk
2006-10-03 14:06 ` Eric Sandeen
0 siblings, 1 reply; 10+ messages in thread
From: Adrian Bunk @ 2006-10-03 5:42 UTC (permalink / raw)
To: Eric Sandeen
Cc: Andrew Morton, Jeremy Fitzhardinge, Linux Kernel Mailing List
On Tue, Oct 03, 2006 at 12:32:14AM -0500, Eric Sandeen wrote:
> Andrew Morton wrote:
> >On Thu, 28 Sep 2006 13:42:26 -0700
> >Jeremy Fitzhardinge <jeremy@goop.org> 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.
>
> But strangely enough, it's the second report we've seen with this exact
> backtrace, and the same "Genu" ascii string where the i_default_acl should
> be.
>
> Both boxes had been through a suspend-to-ram recently, just in case that
> might matter.
>
> Seems like something more than random chance...
Can you give a pointer to the other report?
> -Eric
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b
2006-10-03 5:42 ` Adrian Bunk
@ 2006-10-03 14:06 ` Eric Sandeen
2006-10-03 16:23 ` Adrian Bunk
0 siblings, 1 reply; 10+ messages in thread
From: Eric Sandeen @ 2006-10-03 14:06 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Jeremy Fitzhardinge, Linux Kernel Mailing List
Adrian Bunk wrote:
> On Tue, Oct 03, 2006 at 12:32:14AM -0500, Eric Sandeen wrote:
>> Andrew Morton wrote:
>>>> 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.
>> But strangely enough, it's the second report we've seen with this exact
>> backtrace, and the same "Genu" ascii string where the i_default_acl should
>> be.
>>
>> Both boxes had been through a suspend-to-ram recently, just in case that
>> might matter.
>>
>> Seems like something more than random chance...
>
> Can you give a pointer to the other report?
Sure, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207658
-Eric
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b
2006-10-03 14:06 ` Eric Sandeen
@ 2006-10-03 16:23 ` Adrian Bunk
2006-10-03 16:27 ` Eric Sandeen
0 siblings, 1 reply; 10+ messages in thread
From: Adrian Bunk @ 2006-10-03 16:23 UTC (permalink / raw)
To: Eric Sandeen
Cc: Andrew Morton, Jeremy Fitzhardinge, Linux Kernel Mailing List
On Tue, Oct 03, 2006 at 09:06:05AM -0500, Eric Sandeen wrote:
> Adrian Bunk wrote:
> >On Tue, Oct 03, 2006 at 12:32:14AM -0500, Eric Sandeen wrote:
> >>Andrew Morton wrote:
>
> >>>>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.
> >>But strangely enough, it's the second report we've seen with this exact
> >>backtrace, and the same "Genu" ascii string where the i_default_acl
> >>should be.
> >>
> >>Both boxes had been through a suspend-to-ram recently, just in case that
> >>might matter.
> >>
> >>Seems like something more than random chance...
> >
> >Can you give a pointer to the other report?
>
> Sure, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207658
Another tainted kernel...
> -Eric
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-10-03 16:28 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-28 20:42 2.6.18-1.2689.fc6PAE: oops in ext3_clear_inode+0x52/0x8b Jeremy Fitzhardinge
2006-09-28 20:48 ` James Morris
2006-09-28 21:00 ` Jeremy Fitzhardinge
2006-09-28 21:23 ` Andrew Morton
2006-09-28 21:26 ` Jeremy Fitzhardinge
2006-10-03 5:32 ` Eric Sandeen
2006-10-03 5:42 ` Adrian Bunk
2006-10-03 14:06 ` Eric Sandeen
2006-10-03 16:23 ` Adrian Bunk
2006-10-03 16:27 ` Eric Sandeen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox