Is this your memory?

 

http://www.newegg.com/Product/Product.aspx?Item=N82E16820146565

 

If so, according to the specs, it needs 2.2 volts!  The default is 1.8v.  You need a 0.4v memory voltage boost for it to run reliably at its rated 4-4-4-12 speeds.

 

I have never seen a motherboard automatically boost memory voltage, so unless you did it yourself you are likely undervolted.

 

This all support's Joe's suspicion.

 

BTW, some motherboards do not have RAM voltage adjustment, especially the more budget oriented boards.  I did not see where you posted your motherboard so could not check for you.  If yours does not have this adjustment, you'll need to either to experiment with loosening your memory timings (5-5-5-15 may or may not work) or get different memory.

 

Yes, the memory you linked to on Newegg is the memory I have.  I also have the Abit AB9 Pro motherboard. Everything is still at the default settings.

 

I'm looking at the User's Manual now, and in the BIOS setup section, it shows there is a uGuru Utility that includes Voltage Control. It was set to 'Auto Detect' and the settings are

 

CPU Core Voltage = 1.325 V (this is for an Intel Pentium Dual E2160 @ 1.8GHz)

DDR2 Voltage = 2.00 V

MCH 1.25V Voltage = 1.25 V

ICHIO 1.5V Voltage = 1.5 V

 

I'll bump the DDR2 Voltage to 2.2V and see if that helps.

 

Thanks for pointing this out.

-Gregg

The ACPI errors I mentioned in this earlier post (http://lime-technology.com/forum/index.php?topic=1968.msg14244#msg14244), were also found in WeeboTech's pae syslogs (http://lime-technology.com/forum/index.php?topic=1969.msg14283#msg14283, didn't want to mention it in his thread, off-topic).  He also has an Abit AB9 Pro motherboard.  I also found it in another user's syslog, with the same Abit board, in http://lime-technology.com/forum/index.php?topic=1034.

 

Well, I thought everything was fine after changing the DDR2 voltage to 2.2V, because everything has been running fine in the last couple days.

 

Then today, I starting having some more problems. This time I was able to capture the syslog, and I've attached it to this message.

 

I could no longer read or write to drives on the unRAID server, so I tried to use the web interface to Stop and Start the array. It just hung there when I tried stopping the array, so I went to the console. i was able to capture the syslog and copy it to the flash drive. After issuing a 'samba stop' and mdcmd stop', I tried a poweroff, but it would not shut down the system. So after a hard boot, I had trouble getting it to startup. A message on the screen about invalid floppy appeared on the screen and the system started beeping. So I restarted and went into the BIOS settings. I noticed that the previous setting had changed, so I pressed F7 to go back to the failsafe settings. Then I made the changes so that the memory voltage was at 2.2V and the other changes to get the machine to boot from the USB flash drive. Now when I start the computer and start unRAID, I seem to be getting some other errors that I haven't seen before. These might have something to do with the SATA controller, but I'm not sure. The text scrolls pretty quickly, so I didn't have a chance to write down what was displayed, except I did see a line that said:

 

ata6: failed to recover some devices, retrying in 5 secs.

 

Now when I run the web interface from another machine (typing "\\media" in the browser address) the Main screen now says

 

Stopped. No devices

 

and none of the drives are listed in the 'Disk status' area.

 

If I pick the devices tab, there are drop downs for the first 4 devices (parity device, disk1 device, disk2 device, disk3 device), but all of them show:

 

pci-0000:00:1f-scsi-0:0:0:0 (no device)

 

So it looks like unRAID can no longer find the SATA drives. I will try to reboot and go back into the BIOS setup to see if the SATA settings are messed up.

 

Please let me know if you have any other suggestions.

 

Thanks

OK, now after another hard boot, I went back into the BIOS settings and changed the SATA mode from IDE to AHCI. This is the way I originally had it set when it was working and forgot to change it back after loading the fail-safe defaults.

 

Now it was able to boot into unRAID. However, it looks like I lost parity. The little status dot for the parity disk in the 'Disk status' area is now red. When I started the array, it now forced it to do a parity-sync, which is currently underway. It looks like this may take about 5 hours to complete.

 

Please let me know if there is anything else I should or should not be doing.

Thanks!

Since it did not cleanly shut down, it is re-building parity.  No need to do anything now but wait till it is finished.

 

Joe L.

I don't see any real problems with this syslog.  The drives are using the ahci driver, and appear to be setup correctly, finishing a parity check with an average speed of almost 58MB/sec, which is quite fast.  The fact that you reset the CMOS settings changed the drive settings, so different drivers were used, which setup different Device slots.  The kernel thought that the drives had moved to different slots, not the ones configured in config/disk.cfg, and then when reset to ahci, the kernel thought they had been moved again.

 

Everything appears to be working well, with no indication that I could see as to the problems that occurred earlier.  If you can, always capture a syslog before rebooting if problems are occurring.

 

You might check that the CMOS battery is OK, although that is a pretty rare failure.

 

Well, I'm not having a great amount of luck. While my server was re-building parity, I occasionally checked the console to see if anything unusual was happening. Having no expertise in Linux, I'm not sure what to even look for, but I suppose anything other than the standard prompts might be worth noting.

 

The parity-sync seemed to be doing fine until it was about 55% finished. Then a lot of text started scrolling on the screen. The basic prompts no longer appeared on the screen, so I couldn't issue any commands to capture the syslog. I could Shift-Page-Up/Down to view the text, but I couldn't do anything else. I noticed this text was written several times:

 

BUG: unable to handle kernel paging request at virtual address ffc61604

 

It also reported the same "bug" with addresses ffdfcb24 and ffc6f694, which probably don't mean much to anyone.

 

While this was showing up on the server's console, the actual parity-sync continued. I knew this because every time I pressed the 'Refresh' button on the main screen of the web interface, it would update current position, %, etc. After waiting about 1/2 hour I tried refreshing again. This time it didn't respond. Then I tried refreshing the web page and it couldn't find the server. So I went back to the server's console and discovered this message on the screen:

 

Kernal panic - not syncing: Fatal exception in interrupt

 

I performed another hard boot and got the same beeps and errors about not finding floppy drive. So I knew my BIOS setting were messed up again. Hmmm, I wonder if the CMOS battery is faulty. Shouldn't it retain the BIOS settings during this sort of thing, or is there something that could be causing it to reset. Anyhow, I went back into the BIOS setup to make sure it would boot, etc., etc. Then I ran Memtest. Memtest immediately starting bleeding lots of red text. I removed the memory stick that was causing problems before I increased the DRAM voltage, and restarted the machine. I ran Memtest to see if it would show any errors and it appeared to be ok (I didn't do a lengthy test, just watched it for a few minutes). I've since restarted unRAID and it is now running the parity-sync again. I'll let it run over night and check it again in the morning.

 

Any other ideas??

 

Thanks again.

 

BTW, it looks like this is a hardware related problem. Is it possible to have this thread moved over to the 'Hardware' or 'Motherboards' section?

it is normal after all these, that parity needs rebuild (in fact it needed rebuild at least from the point where you hard boot the system).

 

 

All the problems that you experience ideally match hardware problem scenario. What I strongly recommend is to do in-depth analyse. Most likely the problem is with your RAM memory. Download the newest memtest86+ v2.01 and use it instead of the 'normal' memtest 3.2. Do not replace your ram sticks, neither change anything else. Just let it run and watch if there are any errors. Remember to set everything to 'default' in the bios. Also check the voltage level on 12v (yellow), 5v (red), and 3.3v (orange) rails.

Although the best way to test it would be to disconnect all the disks, connect one empty and install windows on. Then perform various tests, under the windows, such as orthos, spi, test transfering files through network etc. etc.

After letting it run the parity-sync with only 1 DRAM stick last night, this morning it shows "Parity is valid" and every thing seems back to normal. Short of disconnecting everything and installing a drive with Windows and running all the tests Koperfild recommends, is there a simple way to tell whether the memory stick, the DIMM socket or the motherboard are the malfunctioning culprit?

 

 

I'm not sure, but isn't the memtest version that is bundled with the latest unRAID memtest86? I'm not sure of the version, so I'll have to check on that. Can I simply copy the latest version binary, which is v3.4, to the root of my USB flash drive?

After letting it run the parity-sync with only 1 DRAM stick last night, this morning it shows "Parity is valid" and every thing seems back to normal.

Good.

Short of disconnecting everything and installing a drive with Windows and running all the tests Koperfild recommends, is there a simple way to tell whether the memory stick, the DIMM socket or the motherboard are the malfunctioning culprit?

No test will tell you if it is the memory stick, the socket, the motherboard, the wrong memory timing set in the bios, the wrong memory voltage, etc.  The test will only tell you if the memory can be written with various bit patterns and read back correctly.  If the test fails, it could still be any of the above issues.  If it passes, it could still be a different path on the motherboard from disk to memory through a DMA channel, or a power supply issue that is the cause of intermittent errors.

I'm not sure, but isn't the memtest version that is bundled with the latest unRAID memtest86? I'm not sure of the version, so I'll have to check on that. Can I simply copy the latest version binary, which is v3.4, to the root of my USB flash drive?

I just checked my flash drive, and ran "strings" on my memtest.  It is "Memtest86  v1.70"    The same version has apparently been in all the unRAID releases since it was initially added to the boot menu.

 

Joe L.