Bug 149172

Summary:	oops->panic: Unable to handle kernel paging request at virtual address 4ce82f9a
Product:	[Fedora] Fedora	Reporter:	Ellen Shull <ellenshull>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	pfrields, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-09-28 09:33:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ellen Shull 2005-02-20 00:07:56 UTC

Description of problem:  
Was watching a video in mplayer when system locked up.  Upon reboot, 
inspection of /var/log/messages revealed an oops/panic: 
 
kernel: Unable to handle kernel paging request at virtual address 4ce82f9a 
kernel:  printing eip: 
kernel: 4ce82f9a 
kernel: *pde = 00000000 
kernel: Oops: 0000 [#1] 
kernel: DEBUG_PAGEALLOC 
kernel: Modules linked in: nls_utf8 cls_u32 sch_sfq sch_cbq radeon deflate 
zlib_deflate twofish serpent aes_i586 blowfish des sha256 crypto_null 
xfrm4_tunnel ipcomp esp4 ah4 af_key autofs4 sunrpc ipt_REJECT ipt_state 
ip_conntrack iptable_filter ip_tables dm_mod video button battery ac md5 ipv6 
uhci_hcd i2c_viapro i2c_core snd_cmipci snd_pcm_oss snd_mixer_oss snd_pcm 
snd_page_alloc snd_opl3_lib snd_timer snd_hwdep gameport snd_mpu401_uart 
snd_rawmidi snd_seq_device snd soundcore tulip via_rhine mii floppy ext3 jbd 
raid5 xor aic7xxx sd_mod scsi_mod 
kernel: CPU:    0 
kernel: EIP:    0060:[<4ce82f9a>]    Not tainted VLI 
kernel: EFLAGS: 00213006   (2.6.10-1.1146_FC4) 
kernel: EIP is at 0x4ce82f9a 
kernel: eax: c1ee6024   ebx: c1ee6024   ecx: 00000000   edx: 00000001 
kernel: esi: 00000001   edi: c1ee3e18   ebp: cf495de4   esp: cf495dc4 
kernel: ds: 007b   es: 007b   ss: 0068 
kernel: Process X (pid: 3251, threadinfo=cf495000 task=c0ac0a80) 
kernel: Stack: c01178cb 00000000 e8cb07de 3c18d057 00000001 c1ee3e18 00203206 
c8ce7f48 
kernel:        cf495dfc c0117954 00000000 00000000 c1ee3e18 c4c97dc8 00000fd4 
c02fe4a9 
kernel:        00000000 c4c97dc8 c441edc8 c02a840a 00000000 c02a960c c8ce7f48 
0000002c 
kernel: Call Trace: 
kernel:  [<c01178cb>] __wake_up_common+0x36/0x51 
kernel:  [<c0117954>] __wake_up+0x6e/0xca 
kernel:  [<c02fe4a9>] unix_write_space+0x37/0x5c 
kernel:  [<c02a840a>] sock_wfree+0x1e/0x32 
kernel:  [<c02a960c>] __kfree_skb+0xa3/0xf3 
kernel:  [<c030038a>] unix_stream_recvmsg+0x2aa/0x374 
kernel:  [<c02a601d>] sock_aio_read+0x10d/0x11b 
kernel:  [<c01bee40>] inode_has_perm+0x4c/0x54 
kernel:  [<c015fec5>] do_sync_read+0x97/0xc9 
kernel:  [<c01c0c73>] selinux_file_permission+0x114/0x11d 
kernel:  [<c0132942>] autoremove_wake_function+0x0/0x2d 
kernel:  [<c0173e90>] sys_select+0x494/0x49e 
kernel:  [<c015ffa6>] vfs_read+0xaf/0xfb 
kernel:  [<c01601f5>] sys_read+0x3c/0x62 
kernel:  [<c0103383>] syscall_call+0x7/0xb 
kernel: Code:  Bad EIP value. 
kernel:  <0>Fatal exception: panic in 5 seconds 
  
Version-Release number of selected component (if applicable):  
All current rawhide as of 2005-02-19, including: 
kernel-2.6.10-1.1146_FC4.i686 (running on an Athlon XP) 
xorg-x11-6.8.2-1.i386 
  
How reproducible:  
First occurrence with this particular hw/sw combination.  I believe I've seen 
a very similar crash a while back (probably FC3-test era), but I can't seem to 
find where I filed it in bugzilla, and it was with a very different video card 
(PCI Millenium II IIRC).  Now (as of last weekend) I've got an AGP Radeon 7000 
in the machine, using the Xorg 'radeon' driver. 
 
Note I've been watching lots of videos over the last week in mplayer, and this 
is the first time I've seen a crash with the new card, so I don't think it's 
the hardware (the radeon replaced yet another card, a borrowed Permedia 2V, 
which I'm pretty sure *was* causing hardware crashes). 
 
I've been through the memtest86 drill and that passes fine. 
 
I will add comments to this bug if I see it again.

Comment 1 Dave Jones 2005-09-28 09:33:09 UTC

Given the lack of followup, I guess it never appeared again ?
There's been a lot of code changed since back then, so it's possible it got
fixed in an errata if you've updated at all.

I'll close this out, feel free to reopen if it reoccurs with the current errata
kernel.

thanks.