Red Hat Bugzilla – Bug 438860
All kernels after 188.8.131.52-137.fc8 oopses
Last modified: 2008-04-08 06:17:53 EDT
Description of problem:
The kernel 184.108.40.206-137.fc8 is the latest working (from F8 line) on my hw.
Version-Release number of selected component (if applicable):
after several minutes of heavier io (including network)
Steps to Reproduce:
1. reboot machine with this kernel
2. after several minutes of heavier io (including network) oops
Mar 25 16:28:34 kernel: Unable to handle kernel paging request at
Mar 25 16:28:34 kernel: [<ffffffff810bf99c>] page_zero_new_buffers+0xcd/0x10b
Mar 25 16:28:34 kernel: PGD 8063 PUD 9063 PMD c1bc00003ce001e3
Mar 25 16:28:34 kernel: Oops: 000b  SMP
Mar 25 16:28:34 kernel: CPU 1
Mar 25 16:28:34 kernel: Modules linked in: xt_multiport autofs4 it87 hwmon_vid
hwmon ipt_REJECT nf_conntrack_ipv4 iptable_filter ip_tables nf_conntrack_ipv6
xt_state nf_conntrack xt_tcpudp ip6t_ipv6header ip6t_REJECT ip6table_filter
ip6_tables x_tables ipv6 cpufreq_ondemand dm_multipath snd_hda_intel
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss firewire_ohci snd_pcm firewire_core snd_timer snd_page_alloc
snd_hwdep pcspkr parport_pc snd parport crc_itu_t soundcore r8169 button sg
sr_mod cdrom pata_atiixp pata_jmicron dm_snapshot dm_zero dm_mirror dm_mod ahci
libata sd_mod scsi_mod raid456 async_xor async_memcpy async_tx xor raid1 ext3
jbd mbcache uhci_hcd ohci_hcd ehci_hcd
Mar 25 16:28:34 kernel: Pid: 2996, comm: cleanup Not tainted 220.127.116.11-50.fc8 #1
Mar 25 16:28:34 kernel: RIP: 0010:[<ffffffff810bf99c>] [<ffffffff810bf99c>]
Mar 25 16:28:34 kernel: RSP: 0018:ffff8100cf09dac8 EFLAGS: 00010246
Mar 25 16:28:34 kernel: RAX: 0000000000000000 RBX: ffff810044d4dd68 RCX:
Mar 25 16:28:34 kernel: RDX: 0000000000001000 RSI: 0000000000000000 RDI:
Mar 25 16:28:34 kernel: RBP: 0000000000001000 R08: 0000000000000000 R09:
Mar 25 16:28:34 kernel: R10: ffffffff88037b2c R11: 4e776678467a4157 R12:
Created attachment 299051 [details]
output from lspci -v
is that all that made it into the logs? the oops is missing the call backtrace.
If there's no more info in the logs, you may get lucky by switching to a tty,
and trying to reproduce there.
Could you also attach the dmesg output ?
Created attachment 299597 [details]
No, there are no other messages in log. The machine seems to be working after
oops, but with really slow disc access. I was unable to catch if there were
some errors on console, I'll try to catch it later.
could you try and reproduce it with the 'kernel-debug' kernel ?
That may give us some extra info to work with.
I'm unable to reproduce the problem anymore with 18.104.22.168-64.fc8debug so I'm
closing it. This version seems to be working without problems for 24 hours.
Probably a good idea to still keep an eye on it, I came back to my workstation
once with 22.214.171.124-64.fc8 and a whole bunch of processes had segfaulted. dmesg
also segfaulted, so I couldn't find what'd happened and I didn't think to sync
before trying to reboot (and then it locked up).