JackBauer Posted September 14, 2011 Share Posted September 14, 2011 Tom, Care to give us any updates on your plans for 12b or 13? TY Quote Link to comment
Nezil Posted September 14, 2011 Share Posted September 14, 2011 Much as I would love to see an official 5.0 release, I personally still don't think it's quite ready. Tom mentioned in the release notes for 12a that he's tried to tweak something to resolve the BLK_EH_NOT_HANDLED errors that several of us are seeing. In my experience, this issue still isn't fixed, and causes the server to become unresponsive (at least from the UI point of view) and all of the MV8 connected drives to be in-accessible from the terminal / ssh when it happens. As far as I can see, the only solution is a hard reset, which isn't a nice thing to have to do. Again, in my experience, it takes about 2 days for this issue to manifest. As before, I'm attaching a few complete sys logs that show the problem; some from beta11, some from beta12, and some from beta12a. Extracting all of the BLK_EH_NOT_HANDLED lines from the logs, there doesn't seem to be any pattern, and using Google I wasn't able to find any information on what the (presumably) Hex codes for 'command' and 'task' relate to. Beta 11 Aug 16 09:14:21 unRAID kernel: sas: command 0xd9fa9e40, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED Aug 16 10:27:13 unRAID kernel: sas: command 0xf77af6c0, task 0xdf71c140, timed out: BLK_EH_NOT_HANDLED Aug 16 13:30:37 unRAID kernel: sas: command 0xf7661240, task 0xdf71db80, timed out: BLK_EH_NOT_HANDLED Aug 16 13:53:49 unRAID kernel: sas: command 0xf6ded6c0, task 0xdf71ca00, timed out: BLK_EH_NOT_HANDLED Aug 16 15:42:56 unRAID kernel: sas: command 0xf75efcc0, task 0xdf4dd2c0, timed out: BLK_EH_NOT_HANDLED Aug 16 23:14:38 unRAID kernel: sas: command 0xf6fc6a80, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED Aug 17 02:32:09 unRAID kernel: sas: command 0xf6fc6480, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED Aug 17 05:35:40 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED Aug 17 06:05:34 unRAID kernel: sas: command 0xcdf13f00, task 0xdf71cf00, timed out: BLK_EH_NOT_HANDLED Aug 17 18:11:49 unRAID kernel: sas: command 0xd9f8f9c0, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 17 19:11:08 unRAID kernel: sas: command 0xd9f8fd80, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 17 20:47:38 unRAID kernel: sas: command 0xcdf13b40, task 0xdf71d680, timed out: BLK_EH_NOT_HANDLED Aug 18 00:40:51 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71cdc0, timed out: BLK_EH_NOT_HANDLED Aug 18 05:07:55 unRAID kernel: sas: command 0xcdf13d80, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED Aug 18 18:16:28 unRAID kernel: sas: command 0xf75ef780, task 0xdf4dd7c0, timed out: BLK_EH_NOT_HANDLED Aug 19 10:30:41 unRAID kernel: sas: command 0xf75ef600, task 0xdf4dc280, timed out: BLK_EH_NOT_HANDLED Aug 19 17:48:24 unRAID kernel: sas: command 0xcdf133c0, task 0xdf71c3c0, timed out: BLK_EH_NOT_HANDLED Aug 20 05:07:11 unRAID kernel: sas: command 0xf6fc6300, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 20 08:17:25 unRAID kernel: sas: command 0xcdf13f00, task 0xdf71d2c0, timed out: BLK_EH_NOT_HANDLED Aug 20 20:13:56 unRAID kernel: sas: command 0xcdf13e40, task 0xdf71d400, timed out: BLK_EH_NOT_HANDLED Aug 20 20:42:10 unRAID kernel: sas: command 0xf754f000, task 0xdf4ce000, timed out: BLK_EH_NOT_HANDLED Aug 20 23:10:46 unRAID kernel: sas: command 0xcdf13000, task 0xdf71d900, timed out: BLK_EH_NOT_HANDLED Aug 21 02:18:10 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71cc80, timed out: BLK_EH_NOT_HANDLED Aug 21 05:37:45 unRAID kernel: sas: command 0xcdc47540, task 0xdf71e500, timed out: BLK_EH_NOT_HANDLED Aug 21 07:10:02 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4ddb80, timed out: BLK_EH_NOT_HANDLED Aug 21 18:08:19 unRAID kernel: sas: command 0xf75eff00, task 0xdf4dd900, timed out: BLK_EH_NOT_HANDLED Aug 21 23:32:21 unRAID kernel: sas: command 0xf75ef480, task 0xdf4dcf00, timed out: BLK_EH_NOT_HANDLED Aug 22 13:19:01 unRAID kernel: sas: command 0xd0c2bb40, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED Aug 22 15:08:13 unRAID kernel: sas: command 0xcdf36d80, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 23 00:08:40 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71c000, timed out: BLK_EH_NOT_HANDLED Aug 23 04:12:11 unRAID kernel: sas: command 0xf75efc00, task 0xdf4dd7c0, timed out: BLK_EH_NOT_HANDLED Aug 23 10:26:29 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4dc280, timed out: BLK_EH_NOT_HANDLED Aug 23 15:32:48 unRAID kernel: sas: command 0xf75eff00, task 0xdf4dc3c0, timed out: BLK_EH_NOT_HANDLED Aug 23 16:45:50 unRAID kernel: sas: command 0xf75ef180, task 0xdf4dcc80, timed out: BLK_EH_NOT_HANDLED Aug 24 04:40:28 unRAID kernel: sas: command 0xcdf13180, task 0xdf71cc80, timed out: BLK_EH_NOT_HANDLED Aug 24 07:31:50 unRAID kernel: sas: command 0xcdc47480, task 0xdf71ea00, timed out: BLK_EH_NOT_HANDLED Aug 24 14:04:09 unRAID kernel: sas: command 0xf6f70b40, task 0xdf4ce140, timed out: BLK_EH_NOT_HANDLED Aug 24 17:13:11 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71c280, timed out: BLK_EH_NOT_HANDLED Aug 25 00:19:54 unRAID kernel: sas: command 0xcdf13b40, task 0xdf71cf00, timed out: BLK_EH_NOT_HANDLED Aug 25 08:20:32 unRAID kernel: sas: command 0xcdc479c0, task 0xdf71f180, timed out: BLK_EH_NOT_HANDLED Aug 25 09:52:37 unRAID kernel: sas: command 0xcdc470c0, task 0xdf71e280, timed out: BLK_EH_NOT_HANDLED Aug 25 12:22:13 unRAID kernel: sas: command 0xcdf13240, task 0xdf71d180, timed out: BLK_EH_NOT_HANDLED Aug 25 16:00:00 unRAID kernel: sas: command 0xf6f70b40, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 25 20:01:00 unRAID kernel: sas: command 0xcdf13cc0, task 0xdf71db80, timed out: BLK_EH_NOT_HANDLED Aug 27 05:08:45 unRAID kernel: sas: command 0xf75ef840, task 0xdf4dcf00, timed out: BLK_EH_NOT_HANDLED Aug 27 07:02:40 unRAID kernel: sas: command 0xf6f459c0, task 0xdf4ce3c0, timed out: BLK_EH_NOT_HANDLED Aug 27 16:11:21 unRAID kernel: sas: command 0xf75ef3c0, task 0xdf4dd400, timed out: BLK_EH_NOT_HANDLED Aug 27 16:11:51 unRAID kernel: sas: command 0xf75ef000, task 0xdf4dd680, timed out: BLK_EH_NOT_HANDLED Aug 27 21:02:06 unRAID kernel: sas: command 0xcdf139c0, task 0xdf71d2c0, timed out: BLK_EH_NOT_HANDLED Aug 28 04:38:11 unRAID kernel: sas: command 0xcdf36f00, task 0xdf4ce640, timed out: BLK_EH_NOT_HANDLED Aug 28 07:06:22 unRAID kernel: sas: command 0xf75ef840, task 0xdf4dc8c0, timed out: BLK_EH_NOT_HANDLED Beta 12 Sep 1 03:11:26 unRAID kernel: sas: command 0xdf8c1180, task 0xf47d8780, timed out: BLK_EH_NOT_HANDLED Sep 1 06:03:19 unRAID kernel: sas: command 0xdf95f0c0, task 0xf467f2c0, timed out: BLK_EH_NOT_HANDLED Sep 10 18:42:59 unRAID kernel: sas: command 0xeface180, task 0xdf86fcc0, timed out: BLK_EH_NOT_HANDLED Sep 11 23:00:34 unRAID kernel: sas: command 0xf4752600, task 0xdf826500, timed out: BLK_EH_NOT_HANDLED Beta 12a Sep 13 23:29:33 unRAID kernel: sas: command 0xdf872cc0, task 0xdfb04280, timed out: BLK_EH_NOT_HANDLED Sep 14 12:56:14 unRAID kernel: sas: command 0xda60d240, task 0xdf87c780, timed out: BLK_EH_NOT_HANDLED [email protected] [email protected] [email protected] [email protected] Quote Link to comment
thica Posted September 16, 2011 Share Posted September 16, 2011 Hello, just updated fro, 5.10 to 5.12b. Reason: 5.10 did not recognice my new AOC-SAS2LP-MV8. (5.12d does) Feedback after on day: did a parity check (with 115MB/sec) but emhttp died after fisnish the check. Telnet worked, but "powerdown" did not work. Overall: array works. Just for info... Quote Link to comment
dgaschk Posted September 16, 2011 Share Posted September 16, 2011 Can somone please help me with my upgrade from 5b6a to 5b12a. I replaced the correct files on the flash and the webgui loaded. The problem is that unraid sees all my WD 2tb drives as unknown formats. I have included the first part of my vary large syslog, at the end of the first part it looks like command keep on reapeating and continus throw most of the last part of the sys log. Any help would be wonderful. Any Ideas? Additional Info: Supermicro MBD-X8SIL-F-O with an i3 and 4gb of Kingston memory Supermicro AOC-SASLP-MV8 SAS card Corsair Professional Series HX750 Post the entire syslog. Zip it. Quote Link to comment
madburg Posted September 16, 2011 Share Posted September 16, 2011 Hello, just updated fro, 5.10 to 5.12b. Reason: 5.10 did not recognice my new AOC-SAS2LP-MV8. (5.12d does) Feedback after on day: did a parity check (with 115MB/sec) but emhttp died after fisnish the check. Telnet worked, but "powerdown" did not work. Overall: array works. Just for info... WHAT INFO? INFO IS AN ENTIRE SYSLOG ATTACHED! Please help Tom out by posting the entire syslog. If some have not noticed, Tom's tone/stance on not posting a complete syslog with your post will fall on deaf ears. Its hard enought to do what he is doing in 5beta, without a syslog what could he possible do to improve/fix anything. PLEASE if you run into an issue, POST your entire SYSLOG. There are many experienced forum members that read through them as well and help. Quote Link to comment
cjthiel Posted September 17, 2011 Share Posted September 17, 2011 I'm also getting the BLK_NOT_HANDLED errors. Have tried running b10-b12a but these errors persist. My setup: X9SCM-F-O i3-2100 Norco 4224 2 x SASLP-MV8 8gb RAM Corsair TX750 My problem is basically the same as everyone else reporting this error. I have tried preclearing a new 3tb Hitachi 5400 and the BLK error rears it's head within a couple minutes. That drive might be DOA though so maybe not related. I've also tried preclearing a 2tb Hitachi 7200 that I've used in my test runs of Unraid with no problems and with this drive the system will run for a few hours before the BLK errors happen. Obviously this only happens with drives connected to either of the SASLP. I've swapped cards and pci slots but to no prevail. I've also checked all power connections and ran with only power to the drives connected to the SASLP and still have same errors. Attached is my syslog from last night with the errors. syslog.zip Quote Link to comment
jinjorge Posted September 18, 2011 Share Posted September 18, 2011 just noticed the following error in my system log Sep 17 22:22:29 storage2 kernel: handle_stripe read error: 844899128/0, count: 1 Sep 17 22:22:29 storage2 kernel: md: disk0 read error Sep 17 22:22:29 storage2 kernel: handle_stripe read error: 844899136/0, count: 1 Sep 17 22:22:29 storage2 kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Sep 17 22:22:29 storage2 kernel: ata3.00: BMDMA stat 0x66 Sep 17 22:22:29 storage2 kernel: ata3.00: failed command: READ DMA EXT Sep 17 22:22:29 storage2 kernel: ata3.00: cmd 25/00:00:87:23:5c/00:04:32:00:00/e0 tag 0 dma 524288 in Sep 17 22:22:29 storage2 kernel: res 51/84:87:00:00:00/84:27:00:00:00/e0 Emask 0x30 (host bus error) Sep 17 22:22:29 storage2 kernel: ata3.00: status: { DRDY ERR } Sep 17 22:22:29 storage2 kernel: ata3.00: error: { ICRC ABRT } Sep 17 22:22:29 storage2 kernel: ata3: soft resetting link Sep 17 22:22:29 storage2 kernel: ata3.00: configured for UDMA/33 Sep 17 22:22:29 storage2 kernel: ata3.01: configured for UDMA/133 Sep 17 22:22:29 storage2 kernel: ata3: EH complete here is the syslog. Is this something to be concerned about? It's a plus system with a Parity, Cache, disk1 & disk 2. I can provide the HDD info if needed Thanks Edit - checked my sata cabling and rebooted the server and all is well. no errors in the syslog after the re-cabling. Quote Link to comment
dwarfer Posted September 19, 2011 Share Posted September 19, 2011 Has anyone else had this issue with 12a not even booting, bzroot just hangs with about 12-13 rows of dots. All previous beta's have worked fine for me. Syslog for beta 12 attached Thanks Stephen 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 syslog.txt Quote Link to comment
dgaschk Posted September 19, 2011 Share Posted September 19, 2011 Has anyone else had this issue with 12a not even booting, bzroot just hangs with about 12-13 rows of dots. All previous beta's have worked fine for me. Syslog for beta 12 attached Thanks Stephen 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 Save you config directory and reformat the flash. Follow insturctions for install to a new flash drive. After it boots successfully, replace the config directory and reboot. Quote Link to comment
dwarfer Posted September 19, 2011 Share Posted September 19, 2011 Many thanks I will give that a go and if any problems will report back Stephen Quote Link to comment
Shigo_Naito Posted September 20, 2011 Share Posted September 20, 2011 Can somone please help me with my upgrade from 5b6a to 5b12a. I replaced the correct files on the flash and the webgui loaded. The problem is that unraid sees all my WD 2tb drives as unknown formats. I have included the first part of my vary large syslog, at the end of the first part it looks like command keep on reapeating and continus throw most of the last part of the sys log. Any help would be wonderful. Any Ideas? Additional Info: Supermicro MBD-X8SIL-F-O with an i3 and 4gb of Kingston memory Supermicro AOC-SASLP-MV8 SAS card Corsair Professional Series HX750 Post the entire syslog. Zip it. I did, here it is again System_Log.zip Quote Link to comment
bigdave Posted September 21, 2011 Share Posted September 21, 2011 On 12a, I added two WD EARS and now my array won't start, it just sits in Starting .... , unmenu says its started but I know that's not really ready for 5.0 yet. The EARS have not even been added to the array. I have rebooted stopping what I can via cmd line before. I've attached a syslog nothing really stands out. Thanks for the help - -Dave EDIT: Got it to start by removing all the plugins - (couchpotato, sickbeard, sab, dyndns) rebooted via cmd line, then reboot via the GUI, array started. syslog.txt Quote Link to comment
mav3r1ck Posted September 21, 2011 Share Posted September 21, 2011 We have seen quite some cases with the "BLK_NOT_HANDLED" situation. A VERY annoying one. I still have this issue and for me the whole unRAID setup is worthless at the moment (Pro license, B12A) We have also seen users providing their FULL syslogs. Where's the support on this? I hope it's being looked at in the 'back office'. I work with developers everyday and I understand that at some point you will make rules in order to give quality feedback. Just now I am performing a Preclear run for all my brand new disks (13x2.0TB, Hitachi -HDS723020BLA642) and will try again when this finishes (takes forever ) What's the status? Thanks Quote Link to comment
larson Posted September 21, 2011 Share Posted September 21, 2011 We have seen quite some cases with the "BLK_NOT_HANDLED" situation. A VERY annoying one. I still have this issue and for me the whole unRAID setup is worthless at the moment (Pro license, B12A) I am sure you know that the b in 5.0b12a indicates it is a beta. If you want a stable release that is not worthless, there is 4.7 for you. If you insist on running a beta you will have to accept the development pace. I am a bit perplexed by many users here treating the 5 beta as a software for their production rigs, and demanding instant solutions for problems that is clearly a part of the beta process. I am sure Tom will update with a new beta as soon as he have a probable solution to these problems. Sorry for the rant, but just couldn't help myself. I am also eagerly awaiting the finished 5.0 and running the beta on my server. But it is a beta, not the final. /Lars Olof Quote Link to comment
PeterB Posted September 21, 2011 Share Posted September 21, 2011 We have seen quite some cases with the "BLK_NOT_HANDLED" situation. A VERY annoying one. Indeed .. and I'm hoping that the underlying cause is the same one which is causing me problems with the mpt2sas driver, which produces "attempting task abort" messages in the syslog. Certainly, some of the circumstances appear to be similar (ie heavy read activity such as during a preclear). Quote Link to comment
jayhawk Posted September 21, 2011 Share Posted September 21, 2011 Not that anything is 'owed' to anyone that is running beta--but an update or eta for next revision 12b, 13, whatever it may be, would be nice. As the last poster(s) indicated, it is beta--so, whatever changes have been made in an attempt to stabilize the BLK issue, network driver issues, I'm sure everyone would be willing to continue to test and report whatever progress has been made in the last couple weeks. For me, I reduced my server to 1 supermicro sas card, added 2 adaptec cards, moved to a different case (avoiding the norco 4224 backplane) and tried again. With two supermicro sas cards in, I still saw the issues. When I removed it, and added the adaptec card(s) and used onboard--I've yet to see that lockup issue. I don't know if it's an issue with the supermicro board (motherboard/pcie) or the sas cards, or the drivers/unraid... but seems it likes one card a lot better than multiple. For now it's stable for me. I've decided to try building it into a full release of slack again--I really need a full linux box and without the ability to do the CPIO/zcat mod to permanently add packages, kindof a must for me. Quote Link to comment
jinjorge Posted September 21, 2011 Share Posted September 21, 2011 We have seen quite some cases with the "BLK_NOT_HANDLED" situation. A VERY annoying one. I still have this issue and for me the whole unRAID setup is worthless at the moment (Pro license, B12A) . . . What's the status? Thanks The first line on the release notes page reads as follows.... Latest beta is: 5.0-beta12a These release notes refer to installation and upgrade instructions for a major unRAID Server version change. Please be aware that all measures have been taken to ensure data integrity, but this is beta software - use at your own risk. What's worthless is providing feedback the does not further development of the product, touting credentials, oh and the best of all what you have paid for..... It's BETA, for someone that works with developers, you surely understand what beta software means and that providing feedback by noting something to be "worthless" is not something they would smile upon. As stated in posts above, the stable release is 4.7. J Quote Link to comment
mav3r1ck Posted September 21, 2011 Share Posted September 21, 2011 @Lars Olof, don't be sorry for the 'rant' .. I can take it ;-) I didn't start with 4.7 as I wanted to start with 3TB drives, but along the road I came to the conclusion that my "Supermicro 8-Port SAS/SATA Cards (3xAOC-SASLP-MV8) don't support >2TB. I am fully aware of the BETA stages and I respect them, but let's say 4.7 works without the "BLK_NOT_HANDLED" issue, why would this be an issue in the new beta serie (5bxx)? We perform regression tests to keep the current functional design operational not sure how that works for Lime. We will wait and see. Quote Link to comment
mvdzwaan Posted September 21, 2011 Share Posted September 21, 2011 @Lars Olof, don't be sorry for the 'rant' .. I can take it ;-) I didn't start with 4.7 as I wanted to start with 3TB drives, but along the road I came to the conclusion that my "Supermicro 8-Port SAS/SATA Cards (3xAOC-SASLP-MV8) don't support >2TB. See other threads on this forum, it is confirmed that the AOC-SASLP-MV8 works fine with 3Tb disks. edit: It seem the test was done using only one 3tb on the aoc-saslp-mv8 http://lime-technology.com/forum/index.php?topic=11183.msg109527#msg109527 on avsforums I found a couple of people who had no problems with 1 drive but did with multiple 3tb drives. I will do some more research as my production unraid has a SASLP but I'm currently testing the beta on another server with 2 WD 3Tb drives. Quote Link to comment
mav3r1ck Posted September 21, 2011 Share Posted September 21, 2011 It does work, but I was told that it only takes 2TB instead of the total 3TB.. my supplier confirmed this after talking to Supermicro. Quote Link to comment
mvdzwaan Posted September 21, 2011 Share Posted September 21, 2011 It does work, but I was told that it only takes 2TB instead of the total 3TB.. my supplier confirmed this after talking to Supermicro. Finally found the thread which I was looking for : http://lime-technology.com/forum/index.php?topic=14021.0 As you can see from the screenshot multiple 3tb drives (although on beta9) Which saslp firmware are you running ? .21 ? Quote Link to comment
mav3r1ck Posted September 21, 2011 Share Posted September 21, 2011 Not sure, but .21 --> http://bit.ly/rphlMp also ain't your friend when it comes to the "BLK_NOT_HANDLED" How can I easily CLI the firmware version of my SASLP? Quote Link to comment
cyrnel Posted September 21, 2011 Share Posted September 21, 2011 Here's another "BLK_NOT_HANDLED" case on a Supermicro AOC-SASLP-MV8 card. Syslog attached (DHCP activity filtered). No client file activity was involved other than looking at \\tower\flash when copying syslogs. Network activity was limited to telnet sessions. Working up to the failure, I'd successfully precleared two Hitachis. I then started the WD EARS. The EARS is one that's shown errors after reaching a high LCC. When I left it, it had progressed beyond 50% of the pre-read dd. When I returned this morning the telnet window was dead. You can see the error at Sep 21 03:33:24. I'm guessing this was yet another drive response that exceeded mv_sas timing. System load is stuck at about 6. Nothing interesting from top. /proc/interrupts shows mild continued activity for eth0 and maybe 5/sec for RES: CPU0 CPU1 0: 24 0 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 9: 0 0 IO-APIC-fasteoi acpi 12: 0 3 IO-APIC-edge i8042 16: 1935052 151592570 IO-APIC-fasteoi mvsas 17: 1 1 IO-APIC-fasteoi ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3 18: 36 412 IO-APIC-fasteoi ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 2179 87455 IO-APIC-fasteoi ahci 40: 56 3210 PCI-MSI-edge xhci_hcd 41: 0 0 PCI-MSI-edge xhci_hcd 42: 0 0 PCI-MSI-edge xhci_hcd 43: 4528 120995 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 25901602 25901554 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts IWI: 0 0 IRQ work interrupts RES: 521564869 1075787243 Rescheduling interrupts CAL: 10852373 10120174 Function call interrupts TLB: 51680 47495 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 864 864 Machine check polls ERR: 0 MIS: 0 There's plenty of discussion/activity out there regarding this card and BLK_NOT_HANDLED problems, and on systems completely unrelated to unRAID other than being linux or FBSD. Rubbish driver? Edit 9/23/2011 2:40pm: Moved the borderline EARS drive to a MB SATA position. Precleared EARS drive successfully and then rebuilt parity while simultaneously transferring about 1TB to the empty EARS via rsync. Worked fine, if slow due to parallel operations. rsync speed on its own isn't bad at 20-40MB/s. This is using the on-board Realtek 8111E nic. So, I've hammered on it pretty well and things seem good so long as all drives on the AOC-SASLP-MV8 behave. syslog_precleardie_2011-09-21.zip Quote Link to comment
JackBauer Posted September 21, 2011 Share Posted September 21, 2011 It is Tom's prerogative to remain silent until he's ready to share. I do not fault him for it. I will say that in my opinion if task X takes 3 months to do, but you're regularly keeping stakeholders informed, they generally will be a lot happier than if task X takes 1.5 months, and there's nothing but silence during that time. It's in our nature to want everything "now" true - the general availability of information can fill that "need" in the absence of the final product. That's just my uneducated assessment. This isn't exactly Tom's full time job - so there's only so much we can expect. I'm sure he's pulling his hair out over some of these more difficult issues to resolve. I wish him godspeed in doing so. Quote Link to comment
Kilack Posted September 21, 2011 Share Posted September 21, 2011 With regards to the AOC-SASLP-MV8 problems. As I am new to Unraid, I started on the beta because the stable version didn't support my network card. I have one of these sas cards in my system and got these blk errors so obviously you don't need two cards to get the errors. I am curious though, this card is the one that is recommened by limetech, did these errors not exist in the 4.7 builds? Quote Link to comment
Recommended Posts
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.