In addition to this I found this very interesting note on the gentoo amd64 project page... explaining a bit more about raid controllers on amd64 platforms: --- Difference Between Hardware And Software RAID A Hardware raid controller is always an add-on card, it never comes distributed on a motherboard. It has a bios which you can enter before booting into any OS and usually supports 0,1,1+0,and 5 at a minimum. It has a full CPU onboard that does all raid calculations and I/O, and displays itself to the OS as configured by the raid controller (i.e. if you configure a single raid 5, from 3 drives, it will show up by the OS as one big drive). A Hardware RAID will always be faster than a software raid, and consumes MUCH less CPU time. A hardware RAID controller can come optionally with DIMM slots for caching, and possibly a battery backup for that cache. Hardware raid also limits the possible complexity of a OS driver because the raid functionality is performed exclusively in hardware. A Software raid controller can be found in both add-on cards, and is distributed on many motherboards. A software controller may or may not have a BIOS, but the actual raid functionality is actually implemented by the driver in the OS. For this reason, you will NEVER find a software raid controller that can support a bootable RAID5. The OS will be able to see each drive as a standard hard drive, as it is not masked/transformed by the controller in any way. On 2.4 kernels, there was a module that could read many of the SATA controller's BIOSes, set up a linux software raid as specified by that bios, and create a psuedo device was accessible just like a hardware raid would be presented. This 'ataraid' module has not been ported to 2.6, and the 2.4 version does not support SATA controllers, only old PATA software raid controllers. To put it bluntly, a Software RAID controller is nothing more than a standard SATA/PATA controller with possibly a bios to store configuration information, this makes them extremely cheap to manufacture and is why you see them included on many motherboards. --- THis is the table of chips and if software or hardware raid Manufacturer Model Raid Type Status VIA 8237 Software WORKING Promise PDC202xx/PDC203xx Software WORKING Silicon Image 3112[a],3512,3114 Software MOSTLY WORKING (see note below) Promise SX4000 (PDC20621) Hardware WORKING 3Ware Escalade 7xxx and 8xxx Hardware WORKING For everyone else using the vt8237 what this means is you need to just setup the raid bios as no array. Then create a linux software raid array... Done. Aslong as you can access the sata controller portion linux does the raid part... (Benchmarks better than the actuall via provider raid drivers tooo I get over 90mb/ps in linux raid in windows I got around 88mb/ps using via's driver. Hope this helps some people. On Tue, 2004-05-18 at 15:54, Joel Wiramu Pauling wrote:
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