The raid on the MSI Master2far is just the Via vt8237, If you using a different manufacturer it's possible they are using the promise controller for hardware raid and the vt8237 just as the sata controller... I'm not sure I would have to look at the manufacturers specs. The Kernel crash appears to be just the same as yours with a slightly different message. This is the output from /var/log/messages during a crash the xconsole shows the same message as yours... May 16 06:45:27 rincewind kernel: Unable to handle kernel NULL pointer dereference at 000000000000002a RIP: May 16 06:45:27 rincewind kernel: <ffffffff8027ac72>{ide_multwrite+194}PML4 1102a067 PGD 2b62f067 PMD 0 May 16 06:45:27 rincewind kernel: Oops: 0000 [1] May 16 06:45:27 rincewind kernel: CPU 0 May 16 06:45:27 rincewind kernel: Pid: 7717, comm: y2base Tainted: P 2.6.4-54.5-default May 16 06:45:27 rincewind kernel: RIP: 0010:[ide_multwrite+194/320] <ffffffff8027ac72>{ide_multwrite+194} May 16 06:45:27 rincewind kernel: RIP: 0010:[<ffffffff8027ac72>] <ffffffff8027ac72>{ide_multwrite+194} May 16 06:45:27 rincewind kernel: RSP: 0018:000001004feb79c8 EFLAGS: 00010246 May 16 06:45:27 rincewind kernel: RAX: 0000000000000008 RBX: 000001007fae2a78 RCX: 0000000000000000 May 16 06:45:27 rincewind kernel: RDX: ffffffff8043e300 RSI: 0000000000000000 RDI: 0000000000000000 May 16 06:45:27 rincewind kernel: RBP: 0000000000000008 R08: 0000000000000008 R09: 0000000000000000 May 16 06:45:27 rincewind kernel: R10: 0000000000000000 R11: 0000000000000175 R12: ffffffff80495ad8 May 16 06:45:27 rincewind kernel: R13: 000001007fae0008 R14: 000001001c593680 R15: 0000010073481b00 May 16 06:45:27 rincewind kernel: FS: 0000002a98315c00(0000) GS:ffffffff804bd300(0000) knlGS:0000000055999080 May 16 06:45:27 rincewind kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b May 16 06:45:27 rincewind kernel: CR2: 000000000000002a CR3: 0000000000101000 CR4: 00000000000006e0 May 16 06:45:27 rincewind kernel: Process y2base (pid: 7717, stackpage=1001bb65240) May 16 06:45:27 rincewind kernel: Stack: 0000000000000000 ffffffff80495ad8 ffffffff80495990 ffffffff8027b694 May 16 06:45:27 rincewind kernel: 0000000000000000 ffffffff8026fbe1 ffffffff80134320 000001004feb7a00 May 16 06:45:27 rincewind kernel: 000001004feb7a00 ffffffff80495ad8 May 16 06:45:27 rincewind kernel: Call Trace:<ffffffff8027b694>{__ide_do_rw_disk+1396} <ffffffff8026fbe1>{ide_wait_stat+257} May 16 06:45:27 rincewind kernel: <ffffffff80134320>{autoremove_wake_function+0} <ffffffff8026e53f>{start_request+543} May 16 06:45:27 rincewind kernel: <ffffffff8026e8a2>{ide_do_request+818} <ffffffff8025058e>{generic_unplug_device+46} May 16 06:45:27 rincewind kernel: <ffffffff80250651>{blk_execute_rq+177} <ffffffff80253389>{scsi_cmd_ioctl+2169} May 16 06:45:27 rincewind kernel: <ffffffff80134320>{autoremove_wake_function+0} <ffffffff80134320>{autoremove_wake_function+0} May 16 06:45:27 rincewind kernel: <ffffffffa005c064>{:reiserfs:do_journal_end+3444} <ffffffffa004a835>{:reiserfs:reiserfs_dirty_inode+101} May 16 06:45:27 rincewind kernel: <ffffffff8026d121>{generic_ide_ioctl+1585} <ffffffff801ec44a>{avc_has_perm+90} May 16 06:45:27 rincewind kernel: <ffffffff801ed952>{inode_has_perm+98} <ffffffff80251bd4>{blkdev_ioctl+1716} May 16 06:45:27 rincewind kernel: <ffffffff801ee886>{selinux_file_ioctl+742} <ffffffff8017760f>{blkdev_open+47} May 16 06:45:27 rincewind kernel: <ffffffff8016dc9a>{dentry_open+234} <ffffffff801811f1>{sys_ioctl+897} May 16 06:45:27 rincewind kernel: <ffffffff8016de41>{sys_open+113} <ffffffff801103a4>{system_call+124} May 16 06:45:27 rincewind kernel: May 16 06:45:27 rincewind kernel: May 16 06:45:27 rincewind kernel: Code: 0f b7 47 2a 0f b7 57 28 48 89 f9 ff c0 66 39 d0 66 89 47 2a May 16 06:45:27 rincewind kernel: RIP <ffffffff8027ac72>{ide_multwrite+194} RSP <000001004feb79c8> May 16 06:45:27 rincewind kernel: CR2: 000000000000002a --- Kernel panic sorry this was the wrong terminology, should have been oops =-).
From this it looks like the yast2base package is bad... but even when I reinstall yast I get this error...(there is no yast2-base package so I reinstalled by hand the yast rpms)
This is how I reproduce. Go into yast2 (X or Console dosn't matter) Go to install and remove software Change some package selections... Wait... 10 secs... message in xconsole/logs appears... Then I have 10 secs or so before system reboots. Just for the record, how did you obtain the release... The version I'm using I torrented off the net, because suse/novell havn't shipped to NZ yet. I've noticed some inconsitencys in some of the packages... and have built up the system by hand from base install to make sure yast isn't install corrupt packages. Also what ram are you using i'm using OCZ ecc reged dual ddr dimms (ddr400) with my 248, and my system fails mprime stress test... and I can't turn on the ecc chipkill function on my board and still get it boot anything (will post, but won't run memtest even when ECC Chipkill is turned on) I have emailed msi about this. But i'm thinking my ram could be the problem. (Even tho it's specifically built for this type of platform, and it's gross price... ($1500 NZ) Dunno about your board but try 2cpu's forums, I learnt alot about my board from there. http://forums.2cpu.com/showthread.php?s=a0b9da91be0e34f9b417970121ac65ea&threadid=43961 As an Aside... has anyone managed to get the flash plugin working??? If so how I've tried and it keeps on saying cannot find shared librarys.... And is there a 64bit compiled version of openoffice binarys somewhere?... I'm using the 2.0 codebase, and compiling looks like a bit of mission. Kind regards Joel On Tue, 2004-05-18 at 04:23, Jan Meyer wrote:
Hi Joel,
Joel Wiramu Pauling wrote:
I can confirm the same errors... I.e Yast2 kernel panic with scr0000002 whenever I confirm additional package updates.
Mmmh, interesting, I don't get a kernel panic but only a message in xterm: "Import 'SCR' failed." and then the yast2 module does not start. [None of the modules works]
What do you mean by "confirm"? Start an online update?
Also I have various weird crashes with the machine. Am Using a vt based sata solution in a msi master2-far dual proc board with an opteron...
Appears to be a known bug as reported by ak@suse.de in another mail to suse-amd64.
Have you managed to get to raid to work at all.. I eventually disabled raid on the chip and set up softraid in linux...
I only intend to have one hdd - hence no RAID.
Do you also have a Promise controller? On my mainboard it appears to be the choice for SATA hw RAID. I don't fully understand why there are two different SATA/PATA controllers on my board in the first place.
- Jan
Kind regards
Joel
On Mon, 2004-05-17 at 22:09, Jan Meyer wrote:
Hi,
recently I tried to install Suse v9.1-AMD64 on my Athlon64 machine with an MSI K8T Neo-FIS2R (MS-6702) board. [Kernel was updated to 2.6.4-54.5]
To make the story short: During various stages (after finishing the installation and trying to fix issues like an incorrectly formatted swap partition), I had my only SATA drive connected to either of the two SATA controllers (and always the other one disabled). Still I encountered many complete system freezes and recently mainly kernel oopses, which - as far as I can tell - were related to either access to the SATA HDD or a PATA device on the VT8237 controller.
Even though I can finally boot the system, strangely yast2 is broken in a way that I get "import 'SCR' failed" errors. [I was only fiddling with modules.dep and initrd.]
Unless you have a better idea, I have now made up my mind that I should take the windows approach and format-and-reinstall Suse9.1. But before I start with that and run into the same problems:
Can you recommend to me which of the IDE controllers I should use? Which one has the most stable amd64 kernel modules?
Or should I consider patching the kernel (for a recent sata_via patch see also: http://lwn.net/Articles/76129/ ) - or possibly using a kraxel kernel?
Would system stability increase if I switched to a 32-bit kernel? Maybe the SATA controllers are not the problem?
Any hints would be greatly appreciated.
best regards,
Jan
P.S.: On the Via VT8237 my SATA hdd is now recognized as /dev/hda. Should it not be /dev/sda as on the Promise?
PPS: When I got the system to run after switching the SATA drive from Promise to VT8237, the hardware autorecognition feature offered me to add the sata_via module to initrd. I said 'yes' and my initrd got screwed in a way that I could not boot anymore. It took me quite a while to recreate a workable initrd - and still I got error messages that mkinitrd could not check the dependencies in modules.dep for sata_via. Maybe something is wrong with the mkinitrd script?
PPPPS. I also have a recent NVidia based graphic card, which takes an AGP aperture of 128MB. Running the suse install CD in rescue mode, I noticed that a module called nvram was loaded - what is that for?
-- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info