Bug 438860 - All kernels after oopses
All kernels after oopses
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
high Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-25 13:22 EDT by Vaclav "sHINOBI" Misek
Modified: 2008-04-08 06:17 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-08 05:58:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output from lspci -v (13.09 KB, text/plain)
2008-03-25 13:27 EDT, Vaclav "sHINOBI" Misek
no flags Details
dmesg (33.06 KB, text/plain)
2008-03-29 19:21 EDT, Vaclav "sHINOBI" Misek
no flags Details

  None (edit)
Description Vaclav "sHINOBI" Misek 2008-03-25 13:22:41 EDT
Description of problem:
The kernel is the latest working (from F8 line) on my hw.

Version-Release number of selected component (if applicable):

How reproducible:
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
Actual results:
Mar 25 16:28:34 kernel: Unable to handle kernel paging request at
ffff81003ce6c000 RIP: 
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 [1] 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 #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:

Expected results:

Additional info:
Comment 1 Vaclav "sHINOBI" Misek 2008-03-25 13:27:16 EDT
Created attachment 299051 [details]
output from lspci -v
Comment 2 Dave Jones 2008-03-25 14:06:00 EDT
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 ?

Comment 3 Vaclav "sHINOBI" Misek 2008-03-29 19:21:44 EDT
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.
Comment 4 Dave Jones 2008-03-29 19:39:05 EDT
could you try and reproduce it with the 'kernel-debug' kernel ?
That may give us some extra info to work with.
Comment 5 Vaclav "sHINOBI" Misek 2008-04-08 05:58:50 EDT
I'm unable to reproduce the problem anymore with so I'm
closing it. This version seems to be working without problems for 24 hours.
Comment 6 James 2008-04-08 06:17:53 EDT
Probably a good idea to still keep an eye on it, I came back to my workstation
once with 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).

Note You need to log in before you can comment on or make changes to this bug.