moose

Members
  • Posts

    226
  • Joined

  • Last visited

Everything posted by moose

  1. Excellent! These notes allowed me to flash a M1015 with my X9SCM-F after getting the "Failed to initialize PAL" message. Thanks to you and others in this forum!
  2. I assumed the latter, yeah, I guess I'll have to buy a couple more cat6 cables off ebay. Thanks. Or try monoprice.com for the CAT6 cables....might be cheaper.
  3. Thank you BetaQuasi and PCRx for the understanding and VMDK sample file! I now have an unRAID VM booting properly in ESXi 5.0u2. (Side note: shame the AOC-SAS2LP-MV8 doesn't have a ESXi hack (yet) to passthrough...fortunately I have a AOC-SASLP-MV8 card.)
  4. I'm attempting to virtualize unRAID in ESXi 5.0u2 with the hybrid boot method (Option #2 at this link). In essence, I've: 1. Created a VDMK file (virtual hard drive) on a Win7 guest. 2. VDMK was created as 8GB, IDE interface, formatted as FAT32 with volume named "UNRAID". 3. Unzipped "unRAID Server 5.0-rc11a AIO.zip" to the VDMK. 4. Edit "make_bootable.bat" in two lines near the end from "syslinux -ma" to "syslinux -maf". 5. Run "make_bootable.bat" from command prompt. 6. Rename VDMK volume name from "UNRAID" to "unraidboot". 7. Copy preclear script, unmenu script to "boot" and "unmenu" folders respectively. 8. Quit Win7 guest. 9. Remove VDMK file from Win7 guest. 10. Create unRAID VM as outlined in reply #2 of this thread with the previous VDMK (unraidboot) assigned as the virtual hard drive. 11. Included a USB controller and USB device in unRAID VM (step #10). 12. USB device in unRAID VM is external USB flash named "UNRAID", on this external USB flash I only have a folder named "config" and the only file is "pro2.key". No other files are on the external UNRAID flash other than \config\pro2.key The unRAID VM appears to boot and have a local IP assigned (192.168.0.123). The problem is that I cannot access the unRAID VM via http (web interface) and the VM console is pointing to the external USB "UNRAID" (with /config/pro2.key) rather than the "unraidboot" VDMK. I was under the impression that you place all unRAID files (including config folder, unmenu folder, etc.) on the VDMK (unraidboot) and only have the /config/*.key file on the external "UNRAID" USB flash. I'm sure I'm missing a step or made wrong step(s). I've searched the forum but not been able to find anything conclusive to help. Any ideas, suggestions or other forum links to point me? Thank you.
  5. See this thread. Try placing the "sysctl vm.highmem_is_dirtyable=1" command in your go file.
  6. Just installed this same CPU last night with two new unbuffered 8GB sticks of RAM. I'm now having the slow write issue. Previously had a Sandy Bridge i3-2120 with two registered 4GB sticks of RAM with no issues at all. I first noticed the issue when sabnzbd downloads and extractions were super slow. Ran "sysctl vm.highmem_is_dirtyable=1" and it sped them up. Will have to try transferring a large file over the network later tonight to see if it's sustained. Interesting observation. I have a Sandy Bridge Xeon CPU. I'm running un-buffered (ECC) memory too (and as mentioned previously have the slow write issue, minus the workaround). The X9SCM-F MB specs "technically" call for un-buffered ECC RAM per SuperMicro website. X9SCM-F specs
  7. I can validate a subset of the cases listed. (I only have one data disk and no cache disk.) Via network: a) writing to a disk share, - yes b) writing to a non-cache user share, - yes c) writing to the cache disk share, d) writing to a cache-enabled user share. Via command line: a) writing to cache disk, b) writing to array disk.
  8. I have 4x8GB sticks (32GB RAM) installed. I plan to run ESXi, but wanted to get unRAID fully working before virtualizing. I have ESXi and a Win7 VM setup, but haven't completed the unRAID VM steps yet. With 1GB test file and "append mem=4095M initrd=bzroot" in the syslinux.cfg file and sysctl vm.highmem_is_dirtyable=0, I get an initial 5sec burst of 45 MB/s then decays to 8 MB/s write speed within ~ 35sec. With 1GB test file and "append mem=8190M initrd=bzroot" in the syslinux.cfg file and sysctl vm.highmem_is_dirtyable=0, I get an initial 5sec burst of 45 MB/s then decays to 8 MB/s write speed within ~ 35sec. I seem to be the only one in which the "mem=4095M" change is not working. I wonder if that is due to the 4x8GB sticks installed. If everyone else is having better success with "mem=4095M" and I'm the outlier, I wonder if the cause is the high amount of RAM installed or the fact that the memory modules are 8GB sticks. Unfortunately I don't have any smaller sized memory sticks for this motherboard. I'll try to fit in another quick test before leaving for work this morning and remove 16GB and 24GB and retest with the "mem=4095" change. I understand the 32-bit/4GB RAM barrier. The question I have is why 5.0-rc5 and earlier releases don't have any issue. One answer is that 5.0-rc5 had kernel 3.0.33. I know (and agree) we aren't going backward with kernel releases but I wish we knew the underlying cause of the change in behavior once we went from kernel 3.0.33 to kernel 3.4.x (5.0-rc5 to 5.0-rc6 and beyond). Edit: With 16GB RAM installed (2x8GB), a 4+GB test file and "append mem=4095M initrd=bzroot" in the syslinux.cfg file and sysctl vm.highmem_is_dirtyable=0, I get ~ 21 MB/s write speed which is not great but acceptable. I'm guessing that running an unRAID VM in ESXi and the eventual 64-bit version of unRAID would improve the write speed in my setup. I just wish we knew the underlying cause and if it is a kernel change, what changed beyond 3.0.33 with respect to this problem. (I appreciate the great efforts of Tom and the unRAID community! )
  9. With 5.0-rc-10-test and no "sysctl vm.highmem_is_dirtyable=1" command, I am getting ~ 1 MB/s write speed. verified that kernel is 3.4.25 and output of "netstat -nope" command (during slow write) below. No emhttp with a TCP session in CLOSE_WAIT. Moose login: root Password: Linux 3.4.25-unRAID. root@Moose:~# uname -a Linux Moose 3.4.25-unRAID #1 SMP Sat Jan 12 16:14:59 PST 2013 i686 Intel(R) Xeon(R) CPU E31270 @ 3.40GHz GenuineIntel GNU/Linux root@Moose:~# netstat -nope Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name Timer tcp 2426412 0 192.168.0.31:445 192.168.0.100:50374 ESTABLISHED 0 9464 2174/smbd keepalive (6692.89/0/0) tcp 0 172 192.168.0.31:23 192.168.0.100:50424 ESTABLISHED 0 9468 2214/in.telnetd: 19 on (0.47/0/0) Active UNIX domain sockets (w/o servers) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 9 [ ] DGRAM 6207 1043/syslogd /dev/log unix 2 [ ] DGRAM 4124 788/udevd @/org/kernel/udev/udevd unix 2 [ ] DGRAM 10450 1200/emhttp unix 2 [ ] DGRAM 9313 1192/crond unix 3 [ ] STREAM CONNECTED 7278 1187/dbus-daemon unix 3 [ ] STREAM CONNECTED 7277 1187/dbus-daemon unix 2 [ ] DGRAM 10418 1177/acpid unix 2 [ ] DGRAM 175 1170/ntpd unix 2 [ ] DGRAM 7257 1153/rpc.statd unix 2 [ ] DGRAM 6213 1149/rpc.portmap unix 2 [ ] DGRAM 7244 1047/klogd unix 3 [ ] DGRAM 4129 788/udevd unix 3 [ ] DGRAM 4128 788/udevd root@Moose:~# Tom, please see this link for all X9SCM-F (v2.0b) BIOS settings: I don't see any option for "disk write cache" or "write caching" in the BIOS
  10. Thanks Tom! Enjoy the games and we'll test whenever it's ready.
  11. I'm having a problem when writing files to a share. The error messages include: Network Error There is a problem accessing \\server\share Make sure you are connected to the network and try again. It appears the network connection fails to the 5.0-rc10 server in the middle of a file transfer, however if I try again the file transfer again it will complete. Also, clicking "Try Again" doesn't allow the file write operation to complete/continue, but if I click "Cancel" and try the same file again it works. I've also noticed that this issue keeps randomly occurring. This issue was also present in 5.0-rc8a after the "sysctl vm.highmem_is_dirtyable=1" command workaround was found for the slow write speed, I just didn't have time to post. I'm still using the "sysctl vm.highmem_is_dirtyable=1" command in my go script to maintain a decent write speed to the array. I've attached a screenshot of the error messages received as well as the syslog. Edit: I'm wondering if this problem is related: http://lime-technology.com/forum/index.php?topic=24281.0 syslog-2013-01-12.txt
  12. That is without the "sysctl vm.highmem_is_dirtyable=1" command, correct? I'm fairly certain the parity "check" wasn't affected, it was only a "write" to the array that exhibited the slow write speed. tspotorno, can you try a "write" to the array with 5.0-rc9a? Edit: With 5.0-rc9a, my parity "sync" for a 3TB parity disk was 59217 sec => 50.7 MB/s if I am calculating this correctly. However when I write to the array, the slow ~ 1 MB/s speed is present unless I issue the "sysctl vm.highmem_is_dirtyable=1" command, then the write speed is great ~ 45 MB/s. Edit #2: Attached are "meminfo", "inconfig" and "ethtool" command outputs. I am running with "sysctl vm.highmem_is_dirtyable=1" in Go script. meminfo_inconfig_ethtool.txt
  13. I believe it should due to a bug that is fixed with kernel 3.4.24 but haven't been able to test/verify since my 5.0-rc9a server is performing a parity sync check at the moment. I should be able to test/verify this evening, but perhaps others can test/verify beforehand.
  14. Try the command at this post from telnet or console and see if it makes a difference. http://lime-technology.com/forum/index.php?topic=22675.msg213845#msg213845
  15. Hi Christoph, I understand your question now. Yes, generally speaking 30 MB/s is a good write speed with parity. If you use a cache drive, you would likely increase your write speed. See this post for everything cache drive related: http://lime-technology.com/forum/index.php?topic=5754.0 moose
  16. Yes indeed the command above changed the write speed from ~ 1 MB/s to ~40 MB/s with 32 MB RAM. My concern with the command was this comment in this post (http://thread.gmane.org/gmane.linux.kernel/1311355) that lists this command as a workaround: In subsequent searching, I found this post and I believe it might indicate a fix to properly allocate dirtyable memory. (https://patchwork.kernel.org/patch/1767451/) I just don't know enough to be certain if this fix is directly tied with the earlier post. If it is a proper fix for this problem, how does this get updated to the kernel? Any knowledgeable kernel work-flow folks that can comment? In the interim, I'm going to place the "sysctl vm.highmem_is_dirtyable=1" command in my GO script and use the 5.0-rc8a release...I just don't know if there might be other consequences...guess I'll find out.
  17. Just a random thought, but could this memory issue be caused by the same memory issue that is referenced in this thread? (See reply #70 and link provided) http://lime-technology.com/forum/index.php?topic=22675.0
  18. I don't know how comfortable I am with calling this one fixed. I'm not a kernel guru, but if you read the comments at the link that Tom provided in post #70, there seems to be a concern with "other impacts" with this command/parameter setting. Like I said, I'm not knowledgeable enough to know if this has any other side effects or not. Edit: I tried this command last night with 16GB RAM and it did appear to increase write speed. I need to do some further testing but have been working ~ 15 hours days this week...will likely have time to test further this weekend.
  19. I'm planning to use ESXi on this computer (X9SCM-F & E3-1270), just wanted to get unRAID successfully working first. If I use the full 32GB RAM in the motherboard and ESXi but limit unRAID to less RAM (4-8 GB total), theoretically should this work? I know...the answer is probably "test it and find out".
  20. I'm only getting good array (data+parity) write speeds with 16GB RAM. 24GB or 32GB RAM results in slow writes. Also 32GB RAM with preclear resulted in slow write speed with my setup. Maybe this is the the kernel/memory issue that Tom referenced in reply #70 and maybe the difference in our processors causes different limits of RAM to behave differently...just a guess.
  21. Yes this is my understanding of how to correctly upgrade/downgrade between releases (just replace bzimage and bzroot files).
  22. I can also confirm that with 16GB RAM (2x 8GB sticks in slots 2A and 2B) results in a 35-40 MB/s write speed (with Parity disk) for a 1 GB test file. When I re-tested with the 3rd 8GB stick in slot 1A (24GB RAM total), the slow write speed returned. I'm running 5.0-rc8a, BIOS 2.0b and no ESXi/pass through. Edit: just saw that Tom asked me to re-test with 16MB RAM on 12/3/12 and I didn't follow through...sorry Tom. I still think there might be a kernel/memory conflict that might be able to be improved.
  23. Good news. I believe Tom knows the probable cause to the slow write problem. See the other thread (referenced in the opening paragraph of this thread) for details.
  24. What/how did you do your flash drive to make it easier to switch between versions? I'd like to continue trying to help and experiment with Bios settings, etc, but now that I have my Pro.Key and more than 3 drives in the system, I do not want to be changing flash drives. I also wonder if Limetech may consider upgrading the kernel again. I believe the big change in rc5 to rc8a was going from kernel 3.0 to 3.4 But I believe there is a new 3.6 kernel released back in September. EDIT.. I actually just had another thought. Does anyone know of another simple linux distro with kernel 3.4 on it to test write speeds on? It may help to determine if its Kernel related or not. I had the same thought today...about some other 3.4.11 distro to test. I understand Tom not wanting to go back to an earlier kernel especially since 3.4.11 fixed other outstanding issues. I'm just wondering why some X9SCM-F users have problems and others (more) don't, especially since the X9SCM-F seems like a fairly popular MB...could be a couple of reasons: X9SCM-F users haven't upgraded to 5.0-rc8a yet. X9SCM-F users have upgraded to 5.0-rc8a but haven't written large files and noticed a problem. certain X9SCM-F users (like me) have a certain un-agreeable configuration with the MB certain X9SCM-F users (like me) have a hw/sw defect with the MB The X9SCM-F does seem to have various bugs relative to the BIOS. Other users in the links that Tom pointed out indicate these issues....the [H]ard|Forum site indicates these problems too, but neither indicates anything specific to me that would explain the slow write problem. I'm going to keep troubleshooting and trying some more of the additional suggested resolutions. I do like the work-around of using 5.0-rc5 (or earlier) files to write and then switch back to 5.0-rc8a. Helmonder, is there a easy way to keep additional (bzimage and bzroot) files on the flash and rename/move via telnet (to swap between 5.0-rc versions and reboot)? downloadski, just a random guess but since you aren't having any write speed problems, are you using the X9SCM-F IPMI (feature or the IPMI Ethernet port) Also what MB LAN port or add-on Ethernet adapter are you using? Does this MB have hardware revisions? I'll see if I can find anything on that. I know there is a newer version of this board called the X9SCM-IIF, but I'm asking strictly about the X9SCM-F variety. I would also think (hope) this is a temporary problem, otherwise I would need to consider selling this MB and look for a replacement MB. My gut instinct tells me its a config issue related to the kernel...I like ptmuldoon's idea of finding a stripped down 3.4.11 distro to test.