Re: general protection fault: 0000 [1] SMP

[Martin Klier <martin.klier@atu.de>]

[-- 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 --]