Bug 130730 - Kernel Panic : Unable to handle kernel paging request
Summary: Kernel Panic : Unable to handle kernel paging request
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-08-23 23:38 UTC by Ian Turner
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-06-07 16:26:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ian Turner 2004-08-23 23:38:48 UTC
Description of problem:
Kernel panic within minutes of of starting load run.


Version-Release number of selected component (if applicable):
2.4.21-17.ELsmp on an x86_64

How reproducible:
Very, just about every run.


Steps to Reproduce:
1.Run heavy load of sequential read (512 bytes) requests to 30
Fiber channel disks (30 processes)
2.HBA is Qlogic ISP 2312 using default qla2300.o driver
3.Opteron based system with 8 Gig memory
  
Actual results:
Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
Kernel 2.4.21-17.ELsmp on an x86_64


Unable to handle kernel paging request at virtual
 address ffffffffffffffff
 printing rip:
ffffffffa000952c
PML4 103027 PGD 18344f067 PMD 0
Oops: 0002
CPU 2
Pid: 2296, comm: rawread Not tainted
RIP: 0010:[<ffffffffa000952c>]{:scsi_mod:scsi_request_fn+188}
RSP: 0018:000001017f597ce8  EFLAGS: 00010097
RAX: ffffffffffffffff RBX: 00000101ffa1d430 RCX: 00000101fe7ead98
RDX: 0000000000000018 RSI: 000001017f597d98 RDI: ffffffffa0010a2b
RBP: 000001017f597d68 R08: 0000000000000000 R09: 0000000000000003
R10: 0000000000000001 R11: 0000000000000001 R12: 00000101ffa1d400
R13: 00000101ffd78000 R14: 00000101ffa1d430 R15: 0000000000000001
FS:  000000004a9ff970(005b) GS:ffffffff805dd040(0000) 
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffffffffffff CR3: 00000000079c3000 CR4: 00000000000006e0

Call Trace: [<ffffffff801f7a05>]{submit_bh_linked+357}
       [<ffffffff801f6669>]{generic_unplug_device+89} 
[<ffffffff8012aec3>]{__run
_task_queue+115}
       [<ffffffff8017a786>]{kiobuf_wait_for_io+102} 
[<ffffffff80162936>]{brw_kio
vec+1174}
       [<ffffffff8013bc9a>]{__get_user_pages+314} [<ffffffff801e0635>]
{rw_raw_de
v+453}
       [<ffffffff8015de52>]{sys_read+178} [<ffffffff80110177>]
{system_call+119}

Process rawread (pid: 2296, stackpage=1017f597000)
Stack: 000001017f597ce8 0000000000000018 0000000000000000 
000001017f597cf8
       ffffffff801f7a05 0000000000000020 00000101ffa1d430 
000001017f597d68
       000001017f597d98 00000101fe7ead90 0000000000000200 
0000000000000001
       ffffffff801f6669 00000101ffd78100 0000000000000212 
000001017f597d68
       ffffffff8012aec3 0000000000000000 0000000000000212 
00000101ffa1d4d8
       00000101ffa1d4d8 0000000000000001 000001017f596000 
00000101fe7ead40
       ffffffff8017a786 0000000000000000 000001017f596000 
00000101fe7ead98
       00000101fe7ead98 0000000000000000 0000000000000000 
00000101fe8e9aa8
       00000101fe8e9aa8 00000101fe7ead40 0000000000000001 
0000000000000009
       ffffffff80162936 000001017f596000 0000000000000000 
0000000000000200
Call Trace: [<ffffffff801f7a05>]{submit_bh_linked+357}
       [<ffffffff801f6669>]{generic_unplug_device+89} 
[<ffffffff8012aec3>]{__run
_task_queue+115}
       [<ffffffff8017a786>]{kiobuf_wait_for_io+102} 
[<ffffffff80162936>]{brw_kio
vec+1174}
       [<ffffffff8013bc9a>]{__get_user_pages+314} [<ffffffff801e0635>]
{rw_raw_de
v+453}
       [<ffffffff8015de52>]{sys_read+178} [<ffffffff80110177>]
{system_call+119}


Code: f0 fe 08 0f 88 74 04 00 00 41 8b 95 b4 00 00 00 85 d2 7e 0c

Kernel panic: Fatal exception

Expected results:
no panic


Additional info:
We have NDA with RedHat that can be used for additional system 
configuration information.

Comment 1 Doug Ledford 2006-09-19 22:56:44 UTC
This looks like general highmem mapping issues on x86_64 that were solved some
time ago.  If this problem still persists, please let us know.

Comment 2 Doug Ledford 2007-06-07 16:26:21 UTC
This bug has been in NEEDINFO for an extended period of time.  I'm assuming that
indicates the issue was resolved.  Closing this bug out.


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