Bug 182963 - Kernal panic with dereference of virtual address 0000019c
Summary: Kernal panic with dereference of virtual address 0000019c
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-24 19:11 UTC by Ryan Schwarz
Modified: 2015-01-04 22:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-04 23:45:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ryan Schwarz 2006-02-24 19:11:02 UTC
Description of problem: Random kernel panic, locks up machine and requires and
hard reboot.


Version-Release number of selected component (if applicable):
2.6.14-1.1656_FC4smp and previous versions


How reproducible: random, once every 2-3 weeks


Steps to Reproduce: none
1.
2.
3.
  
Actual results:
Here is a dump of the log when it happens:
Jan 10 03:00:01 production crond(pam_unix)[23557]: session opened for user root
by (uid=0)
Jan 10 03:00:01 production crond(pam_unix)[23561]: session opened for user root
by (uid=0)
Jan 10 03:00:01 production crond(pam_unix)[23563]: session opened for user root
by (uid=0)
Jan 10 03:00:01 production crond(pam_unix)[23559]: session opened for user root
by (uid=0)
Jan 10 03:00:02 production crond(pam_unix)[23556]: session closed for user root
Jan 10 03:00:02 production crond(pam_unix)[23563]: session closed for user root
Jan 10 03:00:02 production kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000019c
Jan 10 03:00:02 production kernel: printing eip:
Jan 10 03:00:02 production kernel: c0195425
Jan 10 03:00:02 production kernel: *pde = 0255d001
Jan 10 03:00:02 production kernel: Oops: 0000 [#1]
Jan 10 03:00:02 production kernel: SMP
Jan 10 03:00:02 production kernel: Modules linked in: smbfs iptable_filter
ip_tables radeon drm nfsd exportfs lockd nfs_acl autofs4 i2c_dev i2c_core sunrpc
dm_mod video button battery ac ipv6 ohci_hcd ehci_hcd snd_atiixp snd_ac97_codec
snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc 8139too
mii floppy ext3 jbd raid1
Jan 10 03:00:02 production kernel: CPU: 1
Jan 10 03:00:02 production kernel: EIP: 0060:[<c0195425>] Not tainted VLI
Jan 10 03:00:02 production kernel: EFLAGS: 00010246 (2.6.14-1.1656_FC4smp)
Jan 10 03:00:02 production kernel: EIP is at show_map_internal+0x1f0/0x2df
Jan 10 03:00:02 production kernel: eax: 00000000 ebx: 00000070 ecx: 00000000
edx: 0061d000
Jan 10 03:00:02 production kernel: esi: 00100073 edi: db9f1e80 ebp: 00002000
esp: c3166edc
Jan 10 03:00:02 production kernel: ds: 007b es: 007b ss: 0068
Jan 10 03:00:02 production kernel: Process lsof (pid: 23591, threadinfo=c3166000
task=db7b3550)
Jan 10 03:00:02 production kernel: Stack: c034b153 c033acdc 0061a000 0061d000
00000072 0000002d 00000078 00000070
Jan 10 03:00:02 production kernel: 00000000 00000009 00000002 0061b938 c3166f38
0061d000 00000000 cb0548ac
Jan 10 03:00:02 production kernel: 00000078 dbcbb000 c16aa080 db01e080 0061b938
00000002 00000009 c01958ca
Jan 10 03:00:02 production crond(pam_unix)[23557]: session closed for user root
Jan 10 03:00:02 production kernel: Call Trace:
Jan 10 03:00:02 production kernel: [<c01958ca>] m_next+0x12/0x49
Jan 10 03:00:02 production kernel: [<c0181c8a>] seq_read+0x25f/0x2b8
Jan 10 03:00:02 production kernel: [<c0181a2b>] seq_read+0x0/0x2b8
Jan 10 03:00:02 production kernel: [<c0163036>] vfs_read+0xa0/0x158
Jan 10 03:00:02 production kernel: [<c01633a3>] sys_read+0x41/0x6a
Jan 10 03:00:02 production kernel: [<c0103995>] syscall_call+0x7/0xb
Jan 10 03:00:02 production kernel: Code: 3c 24 e8 a4 cc fe ff 8b 47 04 39 47 0c
72 2d 31 c0 83 c4 60 5b 5e 5f 5d c3 8b 54 24 44 8b 42 78 8b 54 24 3c 8b 52 04 89
54 24 34 <3b> 90 9c 01 00 00 0f 83 a1 fe ff ff e9 b1 fe ff ff 8b 44 24 44
Jan 10 03:00:02 production kernel: <0>Fatal exception: panic in 5 seconds
Jan 10 07:53:03 production syslogd 1.4.1: restart.
Jan 10 07:53:03 production kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jan 10 07:53:03 production kernel: Linux version 2.6.14-1.1656_FC4smp
(bhcompile.redhat.com) (gcc version 4.0.2 20051125 (Red Hat
4.0.2-8)) #1 SMP Thu Jan 5 22:24:06 EST 2006
Jan 10 07:53:03 production kernel: BIOS-provided physical RAM map:
Jan 10 07:53:03 production kernel: BIOS-e820: 0000000000000000 -
000000000009fc00 (usable)
Jan 10 07:53:03 production kernel: BIOS-e820: 000000000009fc00 -
00000000000a0000 (reserved)
Jan 10 07:53:03 production kernel: BIOS-e820: 00000000000f0000 -
0000000000100000 (reserved)
Jan 10 07:53:03 production kernel: BIOS-e820: 0000000000100000 -
000000001bff0000 (usable)
Jan 10 07:53:03 production kernel: BIOS-e820: 000000001bff0000 -
000000001bff3000 (ACPI NVS)


Expected results: no kernel panics.


Additional info:
We have no idea why it is happening.  We have this problem on 2 different
machines, both have the problem with the same virtual address location of
0000019c.  Both machines are Core 4 and have EVERYTHING installed during the
installation.  Both machines are Up to date using Yum.  Thanks.

Comment 1 Dave Jones 2006-02-27 05:19:35 UTC
Is this reproducable with the 2.6.15 based kernels at
http://people.redhat.com/davej/kernels/Fedora/FC-4/  ?


Comment 2 Ryan Schwarz 2006-02-27 20:12:05 UTC
(In reply to comment #1)
> Is this reproducable with the 2.6.15 based kernels at
> http://people.redhat.com/davej/kernels/Fedora/FC-4/  ?
> 

On the newest box we are running 2.6.15-1.1831_FC4smp

[root@accidents ~]# uname -a
Linux accidents 2.6.15-1.1831_FC4smp #1 SMP Tue Feb 7 13:48:31 EST 2006 i686
i686 i386 GNU/Linux


I assume the date, Feb 7, means the last time it was booted?  Its made it 20
days so its doing pretty good.  It seems like the lock-ups are random 2-3 weeks.
 We set the auto-reboot on panics so we don't really notice when it does it
anymore.  I posted this problem in a fedora forum and the only reply I recieved
was to create bug report on it so I did.  My linux knowledge is not great, so
its possible this problem is user error.  It does seems strange that it would
happen on 2 different boxes with different hardware at the same virtual address
location.  Thanks for any help!

Comment 3 Dave Jones 2006-03-04 23:45:41 UTC
Ok, reopen if it ever reoccurs.
There's a newer errata kernel available now also, which fixes a bunch of
additional bugs.



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