October 18, 201114 yr LimeTech has a code escrow in place. In the case of LimeTech's dissolution, the code will become open source. Nothing to worry about. Uh... Did I just miss something? Why is there discussion about "keys in one place" and "LimeTech's dissolution"...?
October 18, 201114 yr LimeTech has a code escrow in place. In the case of LimeTech's dissolution, the code will become open source. Nothing to worry about. Uh... Did I just miss something? Why is there discussion about "keys in one place" and "LimeTech's dissolution"...? No you did not. It is an age old discussion that comes up whenever Limetech is silent on the forums for a period of time. People get nervous, they start asking questions, and answers are given. Nothing to see here, move along :-)
October 18, 201114 yr Quick question on 12a: is there a way to prevent the server from starting up with a parity check? It does soe EVERY time and this is annyoing as within a few minutes I have the dreaded BLK_Not_HANDLED_ error and the system freezes, then when I reboot, if I wait too long, it happens again. So no parity checks for me at the moment. It's really very annoying but I'm sure there is a fix on the way in the next beta, right?
October 18, 201114 yr Quick question on 12a: is there a way to prevent the server from starting up with a parity check? It does soe EVERY time and this is annyoing as within a few minutes I have the dreaded BLK_Not_HANDLED_ error and the system freezes, then when I reboot, if I wait too long, it happens again. So no parity checks for me at the moment. It's really very annoying but I'm sure there is a fix on the way in the next beta, right? To prevent a parity check on start up is easy. Stop the server cleanly. Then power down. A clean stop will record that fact in the config/super.dat file on the flash drive and no parity check will occur on start up. Joe L.
October 18, 201114 yr Quick question on 12a: is there a way to prevent the server from starting up with a parity check? It does soe EVERY time and this is annyoing as within a few minutes I have the dreaded BLK_Not_HANDLED_ error and the system freezes, then when I reboot, if I wait too long, it happens again. So no parity checks for me at the moment. It's really very annoying but I'm sure there is a fix on the way in the next beta, right? To prevent a parity check on start up is easy. Stop the server cleanly. Then power down. A clean stop will record that fact in the config/super.dat file on the flash drive and no parity check will occur on start up. Joe L. I think his problem is, he cant cleanly reboot because he got the BLK_Not_HANDLED_ error. On reboot the system starts the parity check and gives him yet another BLK_Not_HANDLED_ error..... loop death in a way. @Sunny. If you're pretty much fubar on 5B12a, why cant you roll back to 5B11? I don't know your build, so I don't know why you're on the cutting edge of "might or might not work". It sounds like you're going to end up corrupting something eventually if you keep crashing... just my 2cents. @others with the BLK_Not_HANDLED_ error. I think it would be helpful to start logging exact hardware with bios and firmware versions. This seems to be all over with who it works for and who it does not and I don't see a pattern. I have yet to get a BLK_Not_HANDLED_ error and i am running 2 5B12a production boxes with SASLP-MV8's...
October 19, 201114 yr I'll just chime in with the fact that I've also been running without any issues on 5b12a and x2 SASLP-MV8's. I'll make a note of the Firmware they are running and update this post next time I reboot.
October 19, 201114 yr I have been following this thread for a while now and i would like some clarification as to what is the problem as i see it it's just the realtek network cards and the SASLP-MV8 controllers is the BLK_EH_NOT_HANDLED issue just to these controllers.? thanks
October 19, 201114 yr I moved to an IBM M1015 SATA/RAID card (Rebranded LSI 9211-8i) and also bought a genuine LSI 9211-8i. Flashed the 2 cards to IT-mode and I am currently starting my unRAID b12-a performing the first parity build/check. A fresh system and hopefully a fresh and good start without that annoying "BLK_EH error" In other words. I returned the AOC-SASLP-MV8's I was thinking of doing the exact same thing.. Please let us know if the m1015 runs with no errors.. It looks very promising sofar, But then again the system has only been running for 1 day and 20 hrs. Tune back in tomorrow. Normally within or shortly after 2 days the BLK error arises. Running smoothly for 2+ days now. You can never be a 100% sure on this, but removing the AOC-SASLP-MV8's replacing them by LSI 9211 8i's or IBM 1015 cards resolves the BLK_Not_HANDLED_ errors for me. In my case I don't have so much time to wait for a solution. My system: unRAID Version: unRAID Server Pro, Version 5.0-beta12a Case: Norco 4224 Motherboard: Supermicro X8ST3 BIOS: American Megatrends Inc, Version: 2.0, Release Date: 07/29/10 Processor: Intel® CoreTM i7 CPU 950 @ 3.07GHz Memory: 8GB Kingston 1333 MHz (0.8ns) Network: 1000Mb/s Full Duplex Harddrives: 14x 2TB Hitachi_HDS723020BLA642 2x 1.5TB SAMSUNG_HD154U
October 19, 201114 yr Let me know if you can do a preclear on your M1015. I have 3 that run flawlessly until I try to preclear them, then they fail.
October 19, 201114 yr I think his problem is, he cant cleanly reboot because he got the BLK_Not_HANDLED_ error. On reboot the system starts the parity check and gives him yet another BLK_Not_HANDLED_ error..... loop death in a way. @Sunny. If you're pretty much fubar on 5B12a, why cant you roll back to 5B11? Yes, it is a dreaded loop. I guess I could roll back to 5b11. However will the BLK Issue go away? IF yes then I'll roll back. I can't go all the way back to 4.7 even though that worked a dream for a long long time, because I am now using a lot of 3TB drives.
October 19, 201114 yr seems like you guys were right. I made no changes to the hardware, simply shut down, rolled back to beta 11, now running a parity check, and even after 2 hours, it is still going without freezing. Before this would take between 2-5 Minutes before the server became unresponsive.
October 19, 201114 yr I just upgraded my tower. unRAID Version: unRAID Server Pro, Version 5.0-beta12a Motherboard: Supermicro - X8SIL Processor: Intel® CoreTM i3 CPU 540 @ 3.07GHz - 3.066 GHz Cache: L1 = 128 kB L2 = 512 kB L3 = 4096 kB Memory: 4 GB - DIMM0 = 1333 MHz DIMM1 = 1333 MHz I am getting these errors: Oct 16 18:29:12 unRAID kernel: ata5: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata5: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata6: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata5: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata6: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata7: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata5: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata6: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata7: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata8: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata5: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata6: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata7: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata8: sas eh calling libata port error handler (Errors) Oct 16 18:29:12 unRAID kernel: ata9: sas eh calling libata port error handler (Errors) I am also getting these minor issues. I had these errors before I upgraded. I get these hourly: unRAID crond[1293]: failed parsing crontab for user root: cron="" (Minor Issues) These also, I don't know if I had these before I upgraded or not: Oct 16 18:29:15 unRAID emhttp: shcmd (66): killall -HUP smbd (Minor Issues) Oct 17 17:32:43 unRAID emhttp: shcmd (70): killall -HUP smbd (Minor Issues) Oct 17 17:33:14 unRAID emhttp: shcmd (74): killall -HUP smbd (Minor Issues) Oct 17 17:33:47 unRAID emhttp: shcmd (78): killall -HUP smbd (Minor Issues) Oct 17 17:33:55 unRAID emhttp: shcmd (82): killall -HUP smbd (Minor Issues) Oct 17 23:32:18 unRAID emhttp: shcmd (86): killall -HUP smbd (Minor Issues) Oct 18 21:35:40 unRAID emhttp: shcmd (91): killall -HUP smbd (Minor Issues) Besides these errors/issues, everything is working great. I am going to run a parity check tonight. Are these errors anything to worry about? Thanks syslog-2011-10-19.txt
October 19, 201114 yr As far as I know, the error is from the new marvel driver (the mv8 uses this) in the kernel used in 12a. 11 should still be on the previous kernel? that being the case, this error is limited to the 12x series to my knowledge. you could read through the 11 thread to confirm.
October 19, 201114 yr As far as I know, the error is from the new marvel driver (the mv8 uses this) in the kernel used in 12a. 11 should still be on the previous kernel? that being the case, this error is limited to the 12x series to my knowledge. you could read through the 11 thread to confirm. Those are probably not errors, but just lines in the syslog with the word "error" in them. The killall of smbd would be normal every time you make a change in the array configuration of user-shares, or stop/start the arrray.
October 20, 201114 yr As far as I know, the error is from the new marvel driver (the mv8 uses this) in the kernel used in 12a. 11 should still be on the previous kernel? that being the case, this error is limited to the 12x series to my knowledge. you could read through the 11 thread to confirm. Those are probably not errors, but just lines in the syslog with the word "error" in them. The killall of smbd would be normal every time you make a change in the array configuration of user-shares, or stop/start the arrray. I am not experiencing them personally. those that are, are saying their servers are locking up on the second occurrence of the error?
October 20, 201114 yr Those are probably not errors, but just lines in the syslog with the word "error" in them. The killall of smbd would be normal every time you make a change in the array configuration of user-shares, or stop/start the arrray. I did change the user shares configuration to get the mover to go to the drives that I wanted it to. That explains that, thanks. What about? unRAID kernel: ata5: sas eh calling libata port error handler (Errors) And? unRAID crond[1293]: failed parsing crontab for user root: cron="" (Minor Issues) I know you said they may not be errors, but I am curious about what is causing the syslog to report it. Could you please explain what's going on?
October 20, 201114 yr Not to add fuel to the fire but I did purchase a few 3 TB drives since 2TB just doesn't seem the proper way to spend money on space. I would like to run those drives but not in a beta. My data is too important and my chassis is filling up so I am in the midst of a bit of a conundrum as to how to expand my server... I would like 5.0 to go final but be of final quality and not just stamped so. I monitor this forum in great hopes that finality will come sooner - or later. Patiently, Neil
October 20, 201114 yr It's tough to say if I would recommend the betas as I have experienced error reports that don't seem to be consistent and yet highlight the uncertainty of just how truly sound is my data integrity. The problems I've personally experienced only occur when I'm upgrading a drive. Otherwise, the server has been rock stable and running 24/7 for a month with no restarts. Since it's just a media server, the risks were acceptable enough for me as I had maxxed out the capacity and urgently needed to go to >2TB drives. I now have 4 3TB drives and already need at least another pair (I've got new videos on two external 2TB drives and those therefore are completely unprotected in any way). Although it seems I haven't lost any data yet despite all the errors reported by unRAID which simply redoing an upgrade or rebuilding parity appears to clear the errors, you must do your own risk assessment to determine if the need to go to larger drives is more important than potentially losing data. YMMV....
October 21, 201114 yr I've been running beta12a for about a month with no problems, this weekend I'm going to add to the server one Supermicro AOC-SASLP-MV8 controller. Since some people are having problems with this card and beta12a, I was planning on downgrading to beta11, my LAN card it's not realtek. Is this a good idea or should I use a earlier "stabler" beta? I'd like to keep release > 5.0. Thanks, Jorge
October 21, 201114 yr Let me know if you can do a preclear on your M1015. I have 3 that run flawlessly until I try to preclear them, then they fail. I have 2) M1015s that have been working great I just finished preclearing a 1.5TB WD & a 2TB Seagate... no problems or errors.
October 22, 201114 yr I was planning on downgrading to beta11, my LAN card it's not realtek. Is this a good idea or should I use a earlier "stabler" beta? I'd like to keep release > 5.0. I have reverted to beta11 because of NFS problems in 12. It's running fine.
October 22, 201114 yr Let me know if you can do a preclear on your M1015. I have 3 that run flawlessly until I try to preclear them, then they fail. I have 2) M1015s that have been working great I just finished preclearing a 1.5TB WD & a 2TB Seagate... no problems or errors. What firmware version are you running? I have 3 that won't. It makes think that's my issue.
October 22, 201114 yr 12b run great for more than 5 weeks, with two AOC-SASLP-MV8 cards running 8 - 3TB Hitachi cool spins, not a single problem, then bam! the scheduled Parity check started, and all heck broke loose, after about a week of trying all suggestions, I gave up and went back to 11b.
October 22, 201114 yr 12b run great for more than 5 weeks, with two AOC-SASLP-MV8 cards running 8 - 3TB Hitachi cool spins, not a single problem, then bam! the scheduled Parity check started, and all heck broke loose, after about a week of trying all suggestions, I gave up and went back to 11b. Correct me if I'm wrong. the best way, if i have a saslp-mv8, is to downgrade to 5b11, right? i
Archived
This topic is now archived and is closed to further replies.