Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Continuous disconnects: need mboard advice

Featured Replies

  • Author

and my syslog.. I see a lot of errors reporting temperature...

Maybe some setting on my motherboard that I need to switch on?

 

Mboard Manual is here

http://europe.giga-byte.com/FileList/Manual/motherboard_manual_ga-g33-ds3r_e.pdf

 

At page 39 of the manual you can see:

HDD S.M.A.R.T. Capability

Enables or disables the S.M.A.R.T. (Self Monitoring and Reporting Technology) capability of your

hard drive. This feature allows your system to report read/write errors of the hard drive and to

issue warnings when a third party hardware monitor utility is installed. (Default: Disabled)

 

Should this be enabled?

  • Author

Either drive 2 has failed, or the cable to it is loose... or far less likely, the SATA controller port failed.

 

The "reboot" when going to the management console has been reported before... So far, it is thought to be as a result of the browser caching the "reboot" command from a prior shutdown.

 

Joe L.

 

If drive 2 has failed, shouldn't it be offline? I think it is online right now, but the red icon is still there...

One reason you purchased unRaid is to be able to have it be able to serve up your data when a drive fails.

 

Yes, the "red" indicator tells me the drive has failed.  Yes, you can still read and write to it...

 

When reading, the parity drive, in combination with all the other drives in the array reconstruct what would be on the failed drive.

When writing, the parity drive is updated as if the write to the actual drive succeeded.

 

The array is not protected against a second drive failing at the same time.  It is very important to get drive2 working, either by replacing it, or, if a loose cable, by powering down and re-seating it.

 

Joe L.

and my syslog.. I see a lot of errors reporting temperature...

Maybe some setting on my motherboard that I need to switch on?

 

Mboard Manual is here

http://europe.giga-byte.com/FileList/Manual/motherboard_manual_ga-g33-ds3r_e.pdf

 

At page 39 of the manual you can see:

HDD S.M.A.R.T. Capability

Enables or disables the S.M.A.R.T. (Self Monitoring and Reporting Technology) capability of your

hard drive. This feature allows your system to report read/write errors of the hard drive and to

issue warnings when a third party hardware monitor utility is installed. (Default: Disabled)

 

Should this be enabled?

you probably want to enable "SMART" reporting in your bios.
  • Author

One reason you purchased unRaid is to be able to have it be able to serve up your data when a drive fails.

 

Yes, the "red" indicator tells me the drive has failed.  Yes, you can still read and write to it...

 

When reading, the parity drive, in combination with all the other drives in the array reconstruct what would be on the failed drive.

When writing, the parity drive is updated as if the write to the actual drive succeeded.

 

The array is not protected against a second drive failing at the same time.  It is very important to get drive2 working, either by replacing it, or, if a loose cable, by powering down and re-seating it.

 

Joe L.

 

Are you sure?

I have had two disks failing so far in my unraid.

Both of them Seagate, both within warranty.

When they failed (months from each other thankfully) unraid disabled the drive, and did not mount the array.

Unraid was unusable until I replaced the drive, rebuilding the data on it, and then starting the array.

I rebooted (remotely) the server, and the red dot is still there.... I guess next thing is when I get home to enable SMART and to try a different sata port on the motherboard/PCI card.

  • Author

You were right (of course)

 

From the FAQ:

 

How do hard drives become disabled?

When a write operation fails on a disk in a protected array, the system will disable the disk. A disabled disk will no longer be used in any way by the system. The disk still appears as a share, and you may still read and write it; however, the array will be running unprotected and another disk failure will cause data loss.

 

When a read operation fails the system will return the reconstructed data of the failed block. The system then tries to write the reconstructed data back to the failing disk. If this write operation fails then the hard disk will be disabled.

 

Once a disk is disabled it’s contents must be considered invalid (because there have been uncompleted writes). All further read requests to that disk will be serviced by reading Parity and all the other Data disks in order to reconstruct the requested data on-the-fly. All further write requests result in first reading all the other Data disks, and then updating the Parity disk.

 

Normally, you would replace the hard drive of a disabled disk; however, you can try to re-enable a disabled disk as follows:

 

Stop the array.

Power down the unit.

Physically remove the failed disk, leaving the slot empty.

Power up the unit.

Start the array.

Stop the array.

Power down the unit.

Re-install your failed disk.

Power up the unit.

Start the array.

When you start the array in step 5, the system will notice the failed disk’s slot is empty, and it will clear the identification data for that slot. Thus when you start the array in step 10, the system will treat the disk simply as a new disk.

 

The system records the presence of a disabled disk in the config/super.dat file.

 

 

You were right (of course)

 

From the FAQ:

 

How do hard drives become disabled?

When a write operation fails on a disk in a protected array, the system will disable the disk. A disabled disk will no longer be used in any way by the system. The disk still appears as a share, and you may still read and write it; however, the array will be running unprotected and another disk failure will cause data loss.

 

When a read operation fails the system will return the reconstructed data of the failed block. The system then tries to write the reconstructed data back to the failing disk. If this write operation fails then the hard disk will be disabled.

 

Once a disk is disabled it’s contents must be considered invalid (because there have been uncompleted writes). All further read requests to that disk will be serviced by reading Parity and all the other Data disks in order to reconstruct the requested data on-the-fly. All further write requests result in first reading all the other Data disks, and then updating the Parity disk.

 

Normally, you would replace the hard drive of a disabled disk; however, you can try to re-enable a disabled disk as follows:

 

Stop the array.

Power down the unit.

Physically remove the failed disk, leaving the slot empty.

Power up the unit.

Start the array.

Stop the array.

Power down the unit.

Re-install your failed disk.

Power up the unit.

Start the array.

When you start the array in step 5, the system will notice the failed disk’s slot is empty, and it will clear the identification data for that slot. Thus when you start the array in step 10, the system will treat the disk simply as a new disk.

 

The system records the presence of a disabled disk in the config/super.dat file.

 

 

You might be able to simply stop the array, un-assign the failed drive on the drive assignment page, start the array, it will show as "missing" and its contents still supplied by the remainder of the array, then stop the array once more and re-assign it and start the array a final time  That will probably also clear the failed disk's slot in the array.  (The FAQ probably pre-dates the ability to assign drives logically... in early versions of unRaid, the drive assignment page did not exist)

 

However, logically un-assigning and re-assigning a drive will do nothing if it is a loose connector, whereby physically disconnecting it probably will help if it is a loose connector.

 

The array will start as long as only one drive has failed.  It is good your drive failures occured in separate months.  You must be getting better at the RMA process by now... :(

 

Joe L.

Either I'm confused or the syslog was captured too early, before the problem with Disk 2.  Unless I missed something there is absolutely no serious problems with any of the 11 drives according to the syslog.

 

Eight of the drives need to have SMART turned on.  I suspect the other 3 are on a Promise card that has SMART automatically turned on.

 

It appears that most or all of the Seagates either have their SATA150 jumper still installed, or are not using the optimal mode in the BIOS, as they are linking at 1.5 gbps, not 3.0 Gbps.  It does look like many of the drives are in an IDE mode.  If it is possible to select in the BIOS a native SATA or AHCI mode, that would be better.

 

It appears you have the disable_msi=1 parameter set in your syslinux.cfg.  Was this intentionally set for this motherboard, or was it copied from a previous setup?  It looks to me as if it should NOT be set for this board.

 

Since you have installed a new motherboard, I would use both sticks of RAM.

 

  • Author

Either I'm confused or the syslog was captured too early, before the problem with Disk 2.  Unless I missed something there is absolutely no serious problems with any of the 11 drives according to the syslog.

 

Syslog was taken after the drive was showing in red on the management page

 

Eight of the drives need to have SMART turned on.  I suspect the other 3 are on a Promise card that has SMART automatically turned on.

 

you are spot on

 

It appears that most or all of the Seagates either have their SATA150 jumper still installed, or are not using the optimal mode in the BIOS, as they are linking at 1.5 gbps, not 3.0 Gbps.  It does look like many of the drives are in an IDE mode.  If it is possible to select in the BIOS a native SATA or AHCI mode, that would be better.

 

I can force AHCI mode, will test it tonight. What are the  Sata150 jumpers? Are they on the drives itself or the motherboard? I have never touched any drives on unraid (master slave etc)

 

It appears you have the disable_msi=1 parameter set in your syslinux.cfg.  Was this intentionally set for this motherboard, or was it copied from a previous setup?  It looks to me as if it should NOT be set for this board.

 

You are spot on again, I inserted it as suggested by limetech, I will remove it when I get home

 

Since you have installed a new motherboard, I would use both sticks of RAM.

 

Only have one stick of DIMM2 at the moment, the other 2 sticks are DIMM and won't fit in the new motherboard

 

  • Author

I went in Devices, deselected the drive, started the array, stopped the array, reselected the drive in devices, and rebuilding the drive now.

Speed very slow though, 356 Kb/sec, 22823 min remaining.... shall I cancel it?

It sounds as if at least one of your drives is in PIO mode.  Eventually you will need to cancel the restore... unless you want to wait nearly 16 days for it to finish ...  ;D

 

What does the syslog look like now?  Still showing errors?

 

Joe L.

Syslog was taken after the drive was showing in red on the management page

That is really strange.  There are no log entries related to disk errors, or unRAID disabling a drive.

 

I can force AHCI mode, will test it tonight. What are the  Sata150 jumpers? Are they on the drives itself or the motherboard?

AHCI is what you want.  These jumpers are typically found on the cable end of new Seagate SATA drives, for backward compatibility with some early and faulty SATA controllers.  You don't need them, and they should be removed, for better performance.  Regrettably, they are small and pushed well in, requires a needle nose, so the drives usually have to be pulled out.

 

Speed very slow though, 356 Kb/sec, 22823 min remaining....

Ignore the very first reported speeds, I suspect they include setup and initialization time.  Keep refreshing the management screen, and if the time after a few percent is less than 4000 Kb/sec, then yes, you have a problem, probably PIO mode as Joe said.  Once everything is configured correctly, an array of all SATA II drives on modern controllers should be running a parity check somewhere above 50,000 Kb/sec, probably in the 60,000's.  Since 3 of yours are on a Promise PCI card, your times will be a little slower, I'm guessing in the 40,000's to 50,000's.  Parity performance is of course different from normal operational performance, and the drives on the PCI bus will not be noticeably slower than the others, for single drive access.

 

  • Author

Find attached the latest version of the syslog.

 

I can see a line about UDMA33 switched to PIO4 in there...

Joe is right, you have one drive slowing everything down.  This time you have disk errors, but I can't tell which Disk number they are associated with.  It has a serial number ending in 8G57, currently device sdl.  There were 2 attempts to change it to PIO4 mode, and then the exception handler would change it to UDMA/33, which would provide about a third or fourth of normal performance.  Check for bad cable, loose connectors, or try another port, or it could be the drive.

 

All of the drives initialized and mounted without problems.  The exception errors from the one drive occurred after successful mounting.

 

I am hoping that Tom will add the Disk numbers to the syslog, either to the Disk Inventory or a separate table.  It would make troubleshooting easier, being able to easily match the users Disk number with the physical drive.

 

  • Author

8G57 is the one that is disabled...

So it the bottleneck is the same drive that I am trying to rebuild, it appears. I will check the sata cable, and swap the connections around.

  • Author

Swapped sata ports around, extracted and re-insterted the sata cable, rebooted.

Swapped drive locations in the management utility.

Now rebuilding the drive at much higher speed 34,601 KB/sec (230 minutes left).

Forgot to enable AHCI, will do it later on...

Thanks for ALL your help guys, it is a pleasure to be on a forum with so many people willing to help a fellow unraider stuck in the middle of nowhere...

  • Author

The drive was rebuilt succesfully and the parity recalculated.

I enabled AHCI in the bios.

 

From the manual:

 

SATA RAID/AHCI Mode (Intel ICH9R Southbridge)

Enables or disables RAID for the SATA controllers integrated in the Intel ICH9R Southbridge

configures the SATA controllers to AHCI mode.

Disabled Disables RAID for the SATA controllers and configures the SATA controllers

PATA mode. (Default)

RAID Enables RAID for the SATA controller.

AHCI Configures the SATA controllers to AHCI mode. Advanced Host Controller

Interface (AHCI) is an interface specification that allows the storage driver

enable advanced Serial ATA features such as Native Command Queuing

hot plug.

 

I Enabled this

 

Also:

 

SATA Port0-3 Native Mode (Intel ICH9R Southbridge)

Specifies the operating mode of the integrated SATA controllers.

Disabled Allows the SATA controllers to operate in Legacy IDE mode.

In Legacy mode the SATA controllers use dedicated IRQs that cannot be shared

with other device. Set this option to Disabled if you wish to install operating

systems that do not support Native mode, e.g. Windows 9X/ME. (Default)

Enabled Allows the SATA controllers to operate in Native IDE mode.

Enable Native IDE mode if you wish to install operating systems that support

Native mode, e.g. Windows XP/2000.

 

I enabled this setting too.

 

After I did that, 4 drives where showing as missing under the management page.

Went to the drives tab, and reselected them in the drop down menu. all good so far.

 

Attached the syslog I run after all that.

 

Attached the syslog I run after all that.

 

And a very clean syslog it is!

 

Now that all of the SATA ports are in a true SATA mode, it is easy to see their speed.  All 11 of them are showing a SATA link up speed of 1.5 Gbps, so that's another project.  I'll be curious to see how much performance improvement you see after removing the jumpers.  It probably won't be much, but should be detectable.

 

I do appreciate your including some detail as to the settings you have changed.  It helps the next person who runs into similar issues, and it helps those of us who try to help, as we don't have access to every hardware config out there.

 

  • 2 weeks later...
  • Author

Just thought I let you know that my server is still up and running, no reboots and network connection is still up.

So far so good... makes a pleasant change...

  • 2 weeks later...
  • Author

I can confirm my issue seems truly resolved. There must have been a problem with the motherboard, because I now I don't get any disconnects, I have moved a couple of hundreds GB to the server, with no disconnects or problems.

Thanks to all of those who have helped. No reboots yet since I installed the new motherboard, very happy with it.

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.