general protection fault: 0000 [1] SMP

general protection fault: 0000 [1] SMP

[Martin Klier]

[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]

Dear list,

has somebody seen something like that before?

------------------snip----------------------
Jan 28 00:27:54 svdbslx002 kernel: general protection fault: 0000 [1] SMP
Jan 28 00:27:54 svdbslx002 kernel: CPU 1
Jan 28 00:27:54 svdbslx002 kernel: Pid: 14706, comm: ps Tainted: P   U   
(2.6.5-7.201-smp SLES9_SP2_BRANCH-20050825
0620450000)
Jan 28 00:27:54 svdbslx002 kernel: RIP: 0010:[<ffffffff80177f4b>] 
<ffffffff80177f4b>{get_user_pages+267}
Jan 28 00:27:54 svdbslx002 kernel: RSP: 0018:00000101d2e8dd58  EFLAGS: 
00010202
Jan 28 00:27:54 svdbslx002 kernel: RAX: 00009cd0f0009ff8 RBX: 00000000ffffe000 
RCX: 0000010000000000
Jan 28 00:27:54 svdbslx002 kernel: RDX: 00009bd0f0009ff8 RSI: 000ffffffffff000 
RDI: ffffffff803d4f80
Jan 28 00:27:54 svdbslx002 kernel: RBP: 00000101d8d6cc00 R08: 0000000000000000 
R09: 0000000000000001
Jan 28 00:27:54 svdbslx002 kernel: R10: 0000000000000001 R11: 0000000000000246 
R12: 0000000000000000
Jan 28 00:27:54 svdbslx002 kernel: R13: 0000000000000000 R14: 000001017b9163e0 
R15: 0000000000000001
Jan 28 00:27:54 svdbslx002 kernel: FS:  00000000417ff960(0000) 
GS:ffffffff80562f00(0000) knlGS:00000000557d56a0
Jan 28 00:27:54 svdbslx002 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 
000000008005003b
Jan 28 00:27:54 svdbslx002 kernel: CR2: 0000007fbfffbc90 CR3: 000000017ff54000 
CR4: 00000000000006e0
Jan 28 00:27:54 svdbslx002 kernel: Process ps (pid: 14706, threadinfo 
00000101d2e8c000, task 000001015fecf330)
Jan 28 00:27:54 svdbslx002 kernel: Stack: 00000101e9e263a0 ffffffff8019c54b 
00000101d2e8de98 0000000000000000
Jan 28 00:27:54 svdbslx002 kernel:        000fffffeff80106 0000000000000106 
00000010d2e8dde8 00000000ffffe000
Jan 28 00:27:54 svdbslx002 kernel:        0000000000000001 00000101d2e8de18
Jan 28 00:27:54 svdbslx002 kernel: Call 
Trace:<ffffffff8019c54b>{real_lookup+123} <ffffffff80145493>{access_process
_vm+179}
Jan 28 00:27:54 svdbslx002 kernel:        
<ffffffff801c4d02>{proc_pid_cmdline+146} <ffffffff801c418f>{proc_info_rea
d+111}
Jan 28 00:27:54 svdbslx002 kernel:        <ffffffff8018d234>{vfs_read+244} 
<ffffffff8018d48d>{sys_read+157}
Jan 28 00:27:54 svdbslx002 kernel:        <ffffffff80189e87>{sys_open+231} 
<ffffffff801107d4>{system_call+124}
Jan 28 00:27:54 svdbslx002 kernel:
Jan 28 00:27:54 svdbslx002 kernel:
Jan 28 00:27:54 svdbslx002 kernel: Code: 48 8b 00 48 c1 eb 09 81 e3 f8 0f 00 
00 48 21 f0 48 01 d8 48
Jan 28 00:27:54 svdbslx002 kernel: RIP <ffffffff80177f4b>{get_user_pages+267} 
RSP <00000101d2e8dd58>
------------------snip----------------------

In the web, I found several *shrug*s and vague hints on a nmi watchdog issue. 
But I have not seen a real solution anywhere. Can YOU tell me more?
-- 
Mit freundlichen Grüßen

i.A. Martin Klier
PC-Benutzerunterstützung / Linux-Server
IT Asset Management

A.T.U - Auto-Teile-Unger
Dr.-Kilian-Straße 11
92637 Weiden

Telefon:  (0961) 306-5663
Telefax:  (0961) 306-5982

Internet: www.atu.de

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: general protection fault: 0000 [1] SMP

[Martin Klier]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

Hi there,

> Jan 28 00:27:54 svdbslx002 kernel: general protection fault: 0000 [1] SMP
> Jan 28 00:27:54 svdbslx002 kernel: CPU 1
> Jan 28 00:27:54 svdbslx002 kernel: Pid: 14706, comm: ps Tainted: P   U
> (2.6.5-7.201-smp SLES9_SP2_BRANCH-20050825
> 0620450000)

I have found the culprit (Novell support helped a lot):
The 2.6.5-7.201 kernel for x86_64 suffered from a racing condition via which
32-bit systemcalls could cause Oopses. As far as I understood occured the 
problem in memory allocation for 32bit code.

Maybe you want to read 
http://www.x86-64.org/lists/discuss/msg05795.html
or
http://groups.google.de/group/fa.linux.kernel/browse_thread/thread/d3d72f301833e6e2/948440747db94d2b?lnk=st&q=kernel%3A+general+protection+fault%3A+0000+%5B1%5D+SMP&rnum=1&hl=de#948440747db94d2b

It will help to upgrade to the 2.6.5-7.244 kernel, available as part of SP3 or 
as
the separate patch-10731, "Recommended update for Linux kernel",     
http://support.novell.com/cgi-bin/search/searchtid.cgi?/psdb/309c95cc337c1c860f8b7fd1ef14067a.html

Have care, maybe you will have to re-think your raw device rights management 
after patching to -7.244. Dunno why, but it's fact that since the upgrade the 
raw binary messes up the given file permissions/ownership/group each time you 
(re)map a raw device.

Regards,
-- 
Mit freundlichen Grüßen

i.A. Martin Klier
Serveradministration / Datenbanken

A.T.U - Auto-Teile-Unger
Dr.-Kilian-Straße 11
92637 Weiden

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]