Általános védelmi hiba, Mandriva 2006 + SunFire 1200 + 64 bit + SMP

Sziasztok!

Egy ideje nem tudtam írni, mert nagyon el voltam foglalva a Pestre költözéssel és az új munkahelyemmel. De mostanában van egy probléma az egyik Linuxos szerveremmel, amiről szerettem volna kikérni a véleményeteket.

A szóbanforgó cucc egy Sun Fire 1200, amire anno Mandriva Linux 2006-ot raktam. Na, most ez a szerver hetente vagy max. másfél hetente csontra fagy (uptime változó, de <2 hét). Eddig nem nagyon volt időm utánajárni a problémának, csak be-beszaladgáltam a Victor Hugo utcára újraindítani (ott lakok gyak. a szomszédban). Most, hogy lecsillapodtak egy kissé a dolgok, a végére szeretnék járni.

Úgy mellesleg: Ismerősök erőteljesen bíztatnak arra, hogy Sun hardvereken felejtsem el a Linuxot. Azt mondják, hogy Sun cuccra csak Solarist "szabad" pakolni. Megint mások arra esküsznek, hogy a különböző BSD-k (nevezetesen: Open- vagy max. FreeBSD) közül kellene választanom. (Valaki amúgy tréfából [vagy nem...] azt is benyögte, hogy rakjak fel Má$t mer' az biztos jó...) Amiben a két oldal megegyezik az az, hogy a Linux, pontosabban a kernel eleve "instabil" 64 biten, és ezt állítólag csak "súlyosbítja", hogy SMP módban használom. Van ebben valami szerintetek? Hogy egyszerűen és primitíven fogalmazzam meg a kérdést: "Akkor most rakjak fel Solarist vagy OpenBSD-t Linux helyett és minden bajom semmivé lesz?" Hm? :)

Visszatérve a problémára... Alább látható a releváns logbejegyzés az /etc/messages-ből:

Jul 10 08:08:00 sansz kernel: general protection fault: 0000 [1] SMP
Jul 10 08:08:00 sansz kernel: CPU 0
Jul 10 08:08:00 sansz kernel: Modules linked in: md5 ipv6 ipt_REJECT ipt_LOG ipt_state ipt_pkttype ipt_set ipt_CONNMARK ipt_MARK ipt_ROUTE ipt_connmark ipt_owner ipt_recent ipt_iprange ipt_physdev ipt_multiport ipt_conntrack iptable_mangle ip_set_portmap ip_set_macipmap ip_set_ipmap ip_set_iphash ip_set ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables tg3 forcedeth af_packet ide_cd loop tsdev usbmouse usbhid usbkbd ehci_hcd ohci_hcd usbcore evdev reiserfs sd_mod sata_nv libata scsi_mod
Jul 10 08:08:00 sansz kernel: Pid: 155, comm: pdflush Not tainted 2.6.12-12mdksmp
Jul 10 08:08:00 sansz kernel: RIP: 0010:[__wake_up_bit+8/48] <ffffffff801a7a58>{__wake_up_bit+8}
Jul 10 08:08:00 sansz kernel: RIP: 0010:[<ffffffff801a7a58>] <ffffffff801a7a58>{__wake_up_bit+8}
Jul 10 08:08:00 sansz kernel: RSP: 0018:ffff81007fd21ca8  EFLAGS: 00010292
Jul 10 08:08:00 sansz kernel: RAX: 3df330a000d80e48 RBX: ffff810002690098 RCX: 0000000000000040
Jul 10 08:08:00 sansz kernel: RDX: 0000000000000000 RSI: ffff810002690098 RDI: 3df330a000d80e40
Jul 10 08:08:00 sansz kernel: RBP: 0000000000001000 R08: ffff81005f160ea0 R09: 0000000000000004
Jul 10 08:08:00 sansz kernel: R10: 00000000ffffffff R11: 0000000000000000 R12: ffff81005f160ea0
Jul 10 08:08:00 sansz kernel: R13: ffff81007fe82380 R14: ffff81007fe82440 R15: 00000000000019f5
Jul 10 08:08:00 sansz kernel: FS:  00002aaaac195e80(0000) GS:ffffffff804d5d00(0000) knlGS:00000000556b86c0
Jul 10 08:08:00 sansz kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Jul 10 08:08:00 sansz kernel: CR2: 00002aaaabcf6000 CR3: 0000000021a34000 CR4: 00000000000006e0
Jul 10 08:08:00 sansz kernel: Process pdflush (pid: 155, threadinfo ffff81007fd20000, task ffff81007fd1ce70)
Jul 10 08:08:00 sansz kernel: Stack: ffff81007fe82380 ffffffff801b9e13 ffff810002690098 ffffffff801e436d
Jul 10 08:08:00 sansz kernel:        00000000000019f5 0000000000002000 0000000000000000 ffff81007faca400
Jul 10 08:08:00 sansz kernel:        ffffc20000024000 0000000000000002
Jul 10 08:08:00 sansz kernel: Call Trace:<ffffffff801b9e13>{unlock_page+35} <ffffffff801e436d>{__getblk+621}
Jul 10 08:08:00 sansz kernel:        <ffffffff801a7450>{keventd_create_kthread+0} <ffffffff8805f619>{:reiserfs:do_journal_end+1241}
Jul 10 08:08:00 sansz kernel:        <ffffffff8805fe24>{:reiserfs:do_journal_begin_r+52}
Jul 10 08:08:00 sansz kernel:        <ffffffff801a7a98>{wake_up_bit+24} <ffffffff801bfe40>{pdflush+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff801bfe40>{pdflush+0} <ffffffff801a7450>{keventd_create_kthread+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff8804d830>{:reiserfs:reiserfs_sync_fs+64} <ffffffff801e62dd>{sync_supers+125}
Jul 10 08:08:00 sansz kernel:        <ffffffff801bf3da>{wb_kupdate+42} <ffffffff801bfe40>{pdflush+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff801bff7c>{pdflush+316} <ffffffff801bf3b0>{wb_kupdate+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff801a76c9>{kthread+217} <ffffffff8018ba10>{schedule_tail+64}
Jul 10 08:08:00 sansz kernel:        <ffffffff8010f6d3>{child_rip+8} <ffffffff801a7450>{keventd_create_kthread+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff801a75f0>{kthread+0} <ffffffff8010f6cb>{child_rip+0}
Jul 10 08:08:00 sansz kernel:
Jul 10 08:08:00 sansz kernel:
Jul 10 08:08:00 sansz kernel: Code: 48 3b 47 08 48 89 34 24 89 54 24 08 74 12 48 89 e1 ba 01 00
Jul 10 08:08:00 sansz kernel: RIP <ffffffff801a7a58>{__wake_up_bit+8} RSP <ffff81007fd21ca8>

Nem tudom miért, de nekem így elsőre gyanús a sata_nv modul (NVidia cuccokkal már volt ezelőtt bajom). De nem akarok befolyásolni senkit a tévelygéseimmel... Ötletek? :)

Előre is hálásan köszönök minden hozzászólást!!