unRAID Server Release 5.0-beta12a Available


limetech

Recommended Posts

  • Replies 383
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Precleared drives, added them to the array--then when it was idle, apparently the BLK issue came in.  It had been up nearly 3 days while it was "busy" preclearing.  The first 10 hours it was idle, it dies with the BLK error.

 

Sep  6 08:26:43 HBO in.telnetd[30231]: connect from 10.0.1.1 (10.0.1.1)
Sep  6 08:26:48 HBO login[30232]: ROOT LOGIN  on '/dev/pts/1' from 'awesome.dog'
Sep  6 11:25:01 HBO kernel: sas: command 0xc51f8600, task 0xc307bcc0, timed out: BLK_EH_NOT_HANDLED
Sep  6 11:25:01 HBO kernel: sas: Enter sas_scsi_recover_host
Sep  6 11:25:01 HBO kernel: sas: trying to find task 0xc307bcc0
Sep  6 11:25:01 HBO kernel: sas: sas_scsi_find_task: aborting task 0xc307bcc0
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 1818:<7>mv_abort_task() mvi=f76a0000 task=c307bcc0 slot=f76b1640 slot_idx=x2
Sep  6 11:25:01 HBO kernel: sas: sas_scsi_find_task: querying task 0xc307bcc0
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 1747:mvs_query_task:rc= 5
Sep  6 11:25:01 HBO kernel: sas: sas_scsi_find_task: task 0xc307bcc0 failed to abort
Sep  6 11:25:01 HBO kernel: sas: task 0xc307bcc0 is not at LU: I_T recover
Sep  6 11:25:01 HBO kernel: sas: I_T nexus reset for dev 0600000000000000
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x89800.
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x1001
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2226:phy6 Unplug Notice
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x199800.
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x11081
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2253:notify plug in on phy[6]
Sep  6 11:25:01 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2278:plugin interrupt but phy6 is gone
Sep  6 11:25:03 HBO kernel: mvsas 0000:03:00.0: Phy6 : No sig fis
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2139:phy6 Attached Device
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x89800.
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x1001
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2226:phy6 Unplug Notice
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x199800.
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x81
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x199800.
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x10000
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2253:notify plug in on phy[6]
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 1338:port 6 attach dev info is 20000
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 1340:port 6 attach sas addr is 6
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 379:phy 6 byte dmaded.
Sep  6 11:25:03 HBO kernel: sas: sas_form_port: phy6 belongs to port6 already(1)!
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 1701:mvs_I_T_nexus_reset for device[6]:rc= 0
Sep  6 11:25:03 HBO kernel: sas: I_T 0600000000000000 recovered
Sep  6 11:25:03 HBO kernel: sas: sas_ata_task_done: SAS error 8d
Sep  6 11:25:03 HBO kernel: ata10: sas eh calling libata port error handler
Sep  6 11:25:03 HBO kernel: ata11: sas eh calling libata port error handler
Sep  6 11:25:03 HBO kernel: ata12: sas eh calling libata port error handler
Sep  6 11:25:03 HBO kernel: ata13: sas eh calling libata port error handler
Sep  6 11:25:03 HBO kernel: ata14: sas eh calling libata port error handler
Sep  6 11:25:03 HBO kernel: ata15: sas eh calling libata port error handler
Sep  6 11:25:03 HBO kernel: ata16: sas eh calling libata port error handler
Sep  6 11:25:03 HBO kernel: ata16.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 t0
Sep  6 11:25:03 HBO kernel: ata16.00: failed command: CHECK POWER MODE
Sep  6 11:25:03 HBO kernel: ata16.00: cmd e5/00:00:00:00:00/00:00:00:00:00/40 tag 0
Sep  6 11:25:03 HBO kernel:          res 01/04:ff:00:00:00/00:00:00:00:00/40 Emask 0x3 (HSM violation)
Sep  6 11:25:03 HBO kernel: ata16.00: status: { ERR }
Sep  6 11:25:03 HBO kernel: ata16.00: error: { ABRT }
Sep  6 11:25:03 HBO kernel: ata16: hard resetting link
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x89800.
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x1001
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2226:phy6 Unplug Notice
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x199800.
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x11081
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2253:notify plug in on phy[6]
Sep  6 11:25:03 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2278:plugin interrupt but phy6 is gone
Sep  6 11:25:05 HBO kernel: mvsas 0000:03:00.0: Phy6 : No sig fis
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2139:phy6 Attached Device
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x99800.
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x1081
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2226:phy6 Unplug Notice
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 6 ctrl sts=0x199800.
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 6 irq sts = 0x10000
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 2253:notify plug in on phy[6]
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 1338:port 6 attach dev info is 20000
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 1340:port 6 attach sas addr is 6
Sep  6 11:25:05 HBO kernel: drivers/scsi/mvsas/mv_sas.c 379:phy 6 byte dmaded.
Sep  6 11:25:05 HBO kernel: sas: sas_form_port: phy6 belongs to port6 already(1)!
Sep  6 11:25:06 HBO kernel: drivers/scsi/mvsas/mv_sas.c 1701:mvs_I_T_nexus_reset for device[6]:rc= 0
Sep  6 11:25:06 HBO kernel: sas: sas_ata_hard_reset: Found ATA device.
Sep  6 11:25:06 HBO kernel: ata16.00: configured for UDMA/133
Sep  6 11:25:06 HBO kernel: ata16: EH complete
Sep  6 11:25:06 HBO kernel: ata17: sas eh calling libata port error handler
Sep  6 11:25:06 HBO kernel: sas: --- Exit sas_scsi_recover_host
Sep  6 14:49:22 HBO kernel: sas: command 0xe233a9c0, task 0xd5443a40, timed out: BLK_EH_NOT_HANDLED
Sep  6 17:48:02 HBO in.telnetd[23171]: connect from 10.0.1.77 (10.0.1.77)

 

if you need a whole syslog I can provide it, but you can see nothing happening prior to the error.

Link to comment

All good here!

 

Parity check completed on b12a last night with no issues at max HD speed (I.e. starting at 110MB/sec down to ~60ish).

 

Performance between it and b10:

 

5b12a_perf.jpg

 

So a small improvement apart from SMB to a disk root that is protected by parity, no idea why, but SMB via OS X isn't really that important anyway...

 

My cache drive performance is really bad tho :/

Link to comment

Beta12a won't boot... "Loading bzroot" begins to load...bunch of periods (probably 12-13 rows of em), and it just hangs for as long as I let it sit there... re-downloaded and re-copied 12A to USB Stick with no change.

 

Attempted upgrading from Beta 11 which had been running with no issue.

 

Reverting back to 11 allows normal boot...Syslog for Beta11 Boot attached.

 

You did notice :

 

ata4.00: exception Emask 0x10 SAct 0x3ff SErr 0x1180000 action 0x6 frozen

Sep  5 22:32:22 Media kernel: ata4.00: edma_err_cause=020400a0 pp_flags=00000003, EDMA self-disable, SError=01180000

Sep  5 22:32:22 Media kernel: ata4: SError: { 10B8B Dispar TrStaTrns }

Sep  5 22:32:22 Media kernel: ata4.00: failed command: READ FPDMA QUEUED

 

Nope...nor do I have a clue what that means.

 

Drive or interface issues with ata4 (see your own syslog which drive this is). This needs to be fixed before trying betas (or any other activity for that matter). TrStaTrns is not known to me. Please check your cabling to this drive.

 

This issue should be moved to another thread than this b12a discussion

 

I disagree.  He clearly states that he didn't have the problem in the previous beta.  And advising him to "check the cabling" ???

 

Link to comment

I have just upgraded from beta10 to beta12a and can't access any shares via SMB.  Not even the flash, but I can access the web interface.

 

Syslog attached.

 

I have fixed the above.  After looking in the samba logs I saw a lot of errors relating to the secrets.tdb file.  Deleting this and restarting samba fixed it.  Case closed.

Link to comment

 

I disagree.  He clearly states that he didn't have the problem in the previous beta.  And advising him to "check the cabling" ???

 

 

If you're having these sata errors related to bad cabling (do a google search on TrStaTrns) you should fix these before even trying beta's or anything else.

 

It is of note that b10 reacts differently to these sata errors than b12a but that might be pure coincidence.

 

My warning was purely directed at the user (and his data).

 

Link to comment

Hi,

 

I am having exactly the same problem with beta 12a. Loading bzroot just hangs with about 12-13 rows of dots.

Beta 12 works fine and all previous betas have also.

Syslog for beta 12 attached

 

Many thanks

 

Glad I wasn't the only one... I can load b11 and b12 just fine, but not b12a....  My Reply and B11 Syslog on Reply 61 of this thread

Link to comment

New (to me) stuff under load. This is my first AOC-SASLP-MV8, and first experience with BLK_EH_NOT_HANDLED errors. In the interest of time and seeing other similar errors I'm posting without trying to understand most of it.

 

Painful diary:

Board is Asus Biostar A880GU3. Built the system with 5b10 and copied 7+TB without problem. Initial parity and multiple rebuilds worked well. Ran lots of incremental rsync TBs over the LAN. Posted L1 pass. Loaded b11, nothing remarkable with many additional TBs via rsyncs and multiple parity checks. Weeks passed. Loaded b12. A few days later, during the first rsync since the upgrade, the system was dying. SMB wouldn't respond, web interface barely responded. This was bad timing as we were leaving on vacation. Telnet, powerdown -h, pack for trip. Thinking it had shut down I switched off the power and only then noticed it had been running. Crap, but couldn't think about it. Upon return I loaded b12a, rebooted, and let it rebuild parity. Ugly syslog attached:

 

14:04 replaying transactions.

14:05 cache_dirs starts

20:43 parity incorrect storm

20:44 BLK_EH_NOT_HANDLED

 

The array is available but sluggish. The web interface is impossibly slow. Telnet works fine. I've disabled everything non-stock for the next boot but will leave system running in case anything useful can be extracted.

 

Edit for System description:

MB Biostar A880GU3, BIOS 080016  01/25/2011

RAM 4GB Gskill

PS Corsair Builder CX430V2

SAS Card Supermicro AOC-SASLP-MV8

NIC Intel Pro 1000 MT PCI

 

Drives:

Hitachi_HDS723020BLA642(sda) 1953514584 (parity)

Hitachi_HDS721010CLA332(sdd) 976762584

Hitachi_HDS5C3020ALA632(sdc) 1953514584

Hitachi_HDS723020BLA642(sdb) 1953514584

ST2000DL003-9VT166_(sdf) 1953514584 (not assigned to array)

SAMSUNG_HD204UI(sdg) 1953514584

ST2000DL003-9VT166(sdh) 1953514584

Hitachi_HDS5C3020ALA632(sdi) 1953514584

 

Edit: Saturday morning

Loaded b11 last night & successfully completed parity rebuild. Differences were no cache_dirs or unmenu. Reloaded with b12a and rebuilding parity now. Should complete by 5-6pm.

 

Edit: Saturday 5pm

Parity rebuilt successfully with b12a. Known differences from initial failure were no cache_dirs and no unmenu. Stay tuned for more totally pointless tests.  ???

syslog-20110908-sasprobs.txt

Link to comment

New (to me) stuff under load. This is my first AOC-SASLP-MV8, and first experience with BLK_EH_NOT_HANDLED errors. In the interest of time and seeing other similar errors I'm posting without trying to understand most of it.

 

This is the third report of problems with an AOC-SASLP-MV8, and the second with this exact behavior.  I have one of those myself and was planning to upgrade to b12a this weekend, but the amount of people having problems has me concerned.

Link to comment

I have 3 AOC-SASLP-MV8s running in a nearly fully populated Norco RPC-4224 with no problems.  I even upgraded my Parity to a 3TB disk the other day and all is good.  As I mentioned to others before I use to see these BLK_EH_NOT_HANDLED errors intermittently due to power issues.  I was apparently under powering my drives and under heavy load e.g. big data transfers or parity checks, I'd eventually get these errors.  I upgraded my power supply to a SeaSonic X750 Gold 750W and made sure I fixed two faulty power splitter connectors.  This also happened in another smaller build I did with these cards...  For what it's worth, these errors were ALWAYS connected to power issues.  YMMV...

Link to comment

Hey! I have these same drives, and was experiencing the same error. Could it be drive related? (this was beta 10 however, but ... doesn't hurt to investigate any thoughts )

 

quick specs

 

Jayhawk - do you have any samsung hd154uis in your system? (I'll PM this post)

 

SuperMicro X7SPA -H-O (for some reason this is impossible for me to remember)

SUPERMICRO AOC-SASLP-MV8

7 x SAMSUNG EcoGreen F2 HD154UI

 

 

*due to lack of memory decided to put pertinent specs into .sig. Sorry for large sig

 

** due to lack of hardware I am *not* running latest betas, only have the one box, and am hesitant to test on it. Running 4.7 but ran 5.10beta and had issues, downgraded & resolved issues

 

 

Check out the URL for the ENTIRE syslog: http://bit.ly/nbM0DN

 

There are currently only 4 slots in my Norco 4224 seated with 1.5TB SAMSUNG_HD154UI's

 

More specs:

 

PSU: Seasonic 750 Watt

Mobo: Supermicro X8ST3

SATA controller: 3x AOC-SASLP-MV8 - 8 Port SATA II PCIe x4

Ram: Kingston 8GB

CPU: Intel Core i7 950

 

Link to comment

Just checked w/ Jayhawk, another BLK error, and he does not have the samsung drives. Was worth a shot I suppose.

 

Hey! I have these same drives, and was experiencing the same error. Could it be drive related? (this was beta 10 however, but ... doesn't hurt to investigate any thoughts )

 

quick specs

 

Jayhawk - do you have any samsung hd154uis in your system? (I'll PM this post)

 

SuperMicro X7SPA -H-O (for some reason this is impossible for me to remember)

SUPERMICRO AOC-SASLP-MV8

7 x SAMSUNG EcoGreen F2 HD154UI

 

 

*due to lack of memory decided to put pertinent specs into .sig. Sorry for large sig

 

** due to lack of hardware I am *not* running latest betas, only have the one box, and am hesitant to test on it. Running 4.7 but ran 5.10beta and had issues, downgraded & resolved issues

 

 

Check out the URL for the ENTIRE syslog: http://bit.ly/nbM0DN

 

There are currently only 4 slots in my Norco 4224 seated with 1.5TB SAMSUNG_HD154UI's

 

More specs:

 

PSU: Seasonic 750 Watt

Mobo: Supermicro X8ST3

SATA controller: 3x AOC-SASLP-MV8 - 8 Port SATA II PCIe x4

Ram: Kingston 8GB

CPU: Intel Core i7 950

 

Link to comment

I'm using Cache_Dirs just as I was in 4.7 where all my drives spun down fine, with 5b12a, only one of all my drives (always the same one Drive 20) ever spins down, the rest stay up no matter what I do...  In fact, I just greped the syslog and I don't even see spin down commands for any drive besides #20.  I have checked my  spindown settings, I even changed them manually for each drive (in case something was "stuck" from my  upgrade from 4.7).  Any ideas on what to try or where to look to find the problem?

Link to comment

 

There's a critical bug fix in this release having to do with data rebuild.  There is a corner case that comes up where, if during a data rebuild of a disabled disk (or disk replaced with a larger one), if a write-request occurs for another disk in the same stripe for the disk currently being rebuilt, it's possible the data for the disk being rebuilt is not actually written.  Later, this will cause a Parity Check 'sync error'.

 

If you are running any previous 5.0-beta release, please upgrade to this release.

 

In addition, [red]I will be updating the 4.7 series (to 4.7.1) with the same parity sync bug fix[/red].

How do we avoid this bug? Not write anything while the replacement drive is being rebuilt?

By updating to 5.0-beta8 or [red]4.7.1 (which isn't out yet)[/red].

 

Barring that, yes, with a data rebuild in progress, don't write.  With a "upgrade existing disk to larger one" operation, it's potentially unavoidable.

 

Something interesting about this bug: it has existed since day 1

 

Two months later, and still no 4.7.1.  Any idea how much longer for this fix?

 

"Unavoidable" data corruption, if using unRaid's "stable" release... that doesn't look good.

 

 

Link to comment

Recently I have added two new drives to the array. These new drives are connected to an Adaptec 1430SA PCI-E card, where my other drives connect directly to the sata ports of my motherboard.

 

It appears the automatic spin-down for these new drives doesn't work. It is possible to do a spin-down using the "spin down" button, but the drives keep 'active' after the spin-down timer expires (I have set it to 2 hours).

 

It only happens to these drives, the directly connected drives spin down as expected.

Link to comment

Sadly, Beta 12a not working for me…. Same problems as I had with beta10. Loose my eth0.

Flip back to Beta12 and all works fine

When in Beta12, ifconfig gets me:

 

eth0      Link encap:Ethernet  HWaddr 5c:d9:98:4a:14:7f 

          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:10081 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9716 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1828686 (1.7 MiB)  TX bytes:2006905 (1.9 MiB)

          Interrupt:19 Base address:0xec00

 

lo        Link encap:Local Loopback 

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:460 errors:0 dropped:0 overruns:0 frame:0

          TX packets:460 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:72585 (70.8 KiB)  TX bytes:72585 (70.8 KiB)

 

When in Beta12a , eth0 simply doesn’t show – and I can’t “see” unRaid from my Mac or PC workstation

Modprobe r8168 returns “FATAL: Module r8168 not found” in 12 and no response in 12a

(but eth0 remains lost)

logfile attached

Network card is Dlink DGE-528T (card was on recommended list when I built my server)

 

Any chance that network access will be fixed for Beta13?

syslog.zip

Link to comment

Sadly, Beta 12a not working for me…. Same problems as I had with beta10. Loose my eth0.

Flip back to Beta12 and all works fine

When in Beta12, ifconfig gets me:

 

eth0      Link encap:Ethernet  HWaddr 5c:d9:98:4a:14:7f 

          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:10081 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9716 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1828686 (1.7 MiB)  TX bytes:2006905 (1.9 MiB)

          Interrupt:19 Base address:0xec00

 

lo        Link encap:Local Loopback 

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:460 errors:0 dropped:0 overruns:0 frame:0

          TX packets:460 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:72585 (70.8 KiB)  TX bytes:72585 (70.8 KiB)

 

When in Beta12a , eth0 simply doesn’t show – and I can’t “see” unRaid from my Mac or PC workstation

Modprobe r8168 returns “FATAL: Module r8168 not found” in 12 and no response in 12a

(but eth0 remains lost)

logfile attached

Network card is Dlink DGE-528T (card was on recommended list when I built my server)

 

Any chance that network access will be fixed for Beta13?

 

Remove the card and try the onboard NIC if possible

Link to comment

Sadly, Beta 12a not working for me…. Same problems as I had with beta10. Loose my eth0.

Flip back to Beta12 and all works fine

When in Beta12, ifconfig gets me:

 

eth0      Link encap:Ethernet  HWaddr 5c:d9:98:4a:14:7f  

         inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0

         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

         RX packets:10081 errors:0 dropped:0 overruns:0 frame:0

         TX packets:9716 errors:0 dropped:0 overruns:0 carrier:0

         collisions:0 txqueuelen:1000

         RX bytes:1828686 (1.7 MiB)  TX bytes:2006905 (1.9 MiB)

         Interrupt:19 Base address:0xec00

 

lo        Link encap:Local Loopback  

         inet addr:127.0.0.1  Mask:255.0.0.0

         UP LOOPBACK RUNNING  MTU:16436  Metric:1

         RX packets:460 errors:0 dropped:0 overruns:0 frame:0

         TX packets:460 errors:0 dropped:0 overruns:0 carrier:0

         collisions:0 txqueuelen:0

         RX bytes:72585 (70.8 KiB)  TX bytes:72585 (70.8 KiB)

 

When in Beta12a , eth0 simply doesn’t show – and I can’t “see” unRaid from my Mac or PC workstation

Modprobe r8168 returns “FATAL: Module r8168 not found” in 12 and no response in 12a

(but eth0 remains lost)

logfile attached

Network card is Dlink DGE-528T (card was on recommended list when I built my server)

 

Any chance that network access will be fixed for Beta13?

 

Remove the card and try the onboard NIC if possible

 

Sorry - not really much of an option (unless you really need me to do this to help define a bug?)- my mobo is a tiny bit ancient and onboard NIC is slow. Plus my server is v. heavy and to remove a card and put it all back together is a l-o-n-g and tiring job... would rather just put another (recommended?) card in I think!

Thanks

Link to comment

Also in this version I keep getting the BLK_EH_NOT_HANDLED.

 

 

According to this url: http://lime-technology.com/wiki/index.php?title=Hardware_Compatibility#PCI_SATA_Controllers

the SuperMicro AOC-SASLP-MV8 - 8 Port SATA II PCIe x4 is fully supported.

 

Rebuilding and even starting a new array ends in the BLK_EH_NOT_HANDLED error. I am not the only one having this issue... what's going on?

 

Tested on Beta11 / 12 and 12a

 

 

I am getting this error also.  I have one AOC-SASLP-MV8 in my setup so far.

WD earx 2 tb drives.

SUPERMICRO MBD-X9SCL-F-O  8 gigs of ecc memory

650 watt corsair psu enthusiast v2

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.