limetech Posted November 16, 2010 Share Posted November 16, 2010 Download This is a maintenance release to fix a "kernel oops" (ie, crash). unRAID Server 4.5.7 Release Notes ================================= Changes from 4.5.6 to 4.5.7 --------------------------- Bug fixes: - Fix for kernel oops of the following type: "Tower kernel: EIP is at md_cmd_proc_read+0x41/0x54 [md_mod]" Changes from 4.5.5 to 4.5.6 --------------------------- Sorry, the 4.5.5 release package got built wrong which resulted in bugs listed below. Bug fixes: - Fixed problem with restoring timezone setting upon reboot. - Fixed missing reiserfsprogs. Changes from 4.5.4 to 4.5.5 --------------------------- Bug fixes: - Fixed 'Mover logging' control in webGui. Other: - Added better timezone support. - Increase supported array width from 20 to 21 drives. - Add 'Are you sure?' prompt to the 'initconfig' command. - Added IPMI support, I2C support, and Intel 82801 support. - During parity-check, the first 20 sync errors are output to the system log. - If directory named 'extra' exists in root of Flash, invoke 'installpkg' on all files found there before invoking the 'go' script. - Add 'removepkg' and 'explodepkg'. - Added 'bzip2'. - Upgrade reiserfsprogs to version 3.6.21 Changes from 4.5.3 to 4.5.4 --------------------------- Bug fixes: - Fix (another) problem where formatted data disks could appear 'unformatted' immediately following array start. This one was due to race condition where md devices could possibly not exist before management utility issues 'mount'. Other: - Generate additional logging information during 'mount'. - Added additional "safeguards" in the code handling 'format' operations. - Removed 'Restore' button from webGui, replacing with new shell command called 'initconfig'. - Updated mc (midnight-commander) utility to slackware's 2010-02-06 version. Changes from 4.5.2 to 4.5.3 --------------------------- Other: - Update linux kernel to 2.6.32.9 - Enable SMT (Hyperthreading) scheduler support in kernel. - Update linux udev subsystem to 1.41. - Fix problem reading USB Flash device model & serial number with some motherboads. - Added USB FTDI Single Port Serial Driver per user request. Changes from 4.5.1 to 4.5.2 --------------------------- Bug fixes: - Fix problem where device assignment via webGui could fail if device identifier is too long. Other: - Added SCST subsystem (see http://scst.sourceforge.net) in order to support Marvell 88SE63xx/64xx/68xx/94xx SAS controller-based cards. - Added 'COPYING' file in release that includes text of the GPL version 2. Changes from 4.5 to 4.5.1 ------------------------- Bug fixes: - Fix javascript bug checking valid settings on the Settings page. - Fix bug where a disk can appear 'Unformatted' immediately after array Start. - Change unmount polling rate from 1 second to 5 seconds when Stopping the array when external extensions still have a disk or use share mounted. Other: - Updated linux kernel to version 2.6.31.12 - Updated Samba to version 3.4.5 - Added Areca driver. - Added Marvell legacy PATA support. - Added USB printer support. Upgrade Instructions (Please Read Carefully) ============================================ If you are currently running unRAID Server 4.2-beta1 or higher (including 4.2.x 'final'), please copy the following files from the new release to the root of your Flash device: bzimage bzroot If you are currently running unRAID server 4.0 or 4.1, please copy the following files from the new release to the root of your Flash device: bzimage bzroot syslinux.cfg menu.c32 memtest This can be done either by plugging the Flash into your PC or, by copying the files to the 'flash' share on your running server. The server must then be rebooted. If you are currently running unRAID Server 3.0-beta1 or higher, please follow these steps to upgrade: 1. Referring to the System Management Utility 'Main' page, make a note of each disks's model/serial number; you will need this information later. 2. Shut down your server, remove the Flash and plug it into your PC. 3. Right-click your Flash device listed under My Computer and select Properties. Make sure the volume label is set to "UNRAID" (without the quotes) and click OK. You do NOT need to format the Flash. 4. Copy the files from the new release to the root of your Flash device. 5. Right-click your Flash device listed under My Computer and select Eject. Remove the Flash, install in your server and power-up. 6. After your server has booted up, the System Management Utility 'Main' page will probably show no devices; this is OK, navigate to the 'Devices' page. Using the model/serial number information gathered in step 1, assign each of your hard drives to the correct disk slot. 7. Go back to the 'Main' page and your devices should appear correctly. You may now Start the array. Link to comment
NAS Posted November 16, 2010 Share Posted November 16, 2010 Tom since this is such a specific release can you perhaps shed some light on scenarios where we should upgrade i.e if we haven't seen the oops should we just upgrade at a convenient moment or is this a priority must patch asap. Link to comment
Chris Pollard Posted November 16, 2010 Share Posted November 16, 2010 Tom since this is such a specific release can you perhaps shed some light on scenarios where we should upgrade i.e if we haven't seen the oops should we just upgrade at a convenient moment or is this a priority must patch asap. Agree, would also like to see more details of the bug if possible. Thanks. Link to comment
mbryanr Posted November 17, 2010 Share Posted November 17, 2010 copied the two files over to the flash with TerraCopy; upon reboot noticed this error - which keeps repeating... Nov 16 19:28:47 Tower unmenu[1377]: /root/mdcmd: line 3: echo: write error: Invalid argument Nov 16 19:28:47 Tower kernel: mdcmd (12): status Nov 16 19:28:54 Tower unmenu[1377]: /root/mdcmd: line 3: echo: write error: Invalid argument Nov 16 19:28:54 Tower kernel: mdcmd (13): status Edit: Reverted back to 4.5.6, just to verify there was no issue from my copy procedure. No more errors. Link to comment
Joe L. Posted November 17, 2010 Share Posted November 17, 2010 copied the two files over to the flash with TerraCopy; upon reboot noticed this error - which keeps repeating... Nov 16 19:28:47 Tower unmenu[1377]: /root/mdcmd: line 3: echo: write error: Invalid argument Nov 16 19:28:47 Tower kernel: mdcmd (12): status Nov 16 19:28:54 Tower unmenu[1377]: /root/mdcmd: line 3: echo: write error: Invalid argument Nov 16 19:28:54 Tower kernel: mdcmd (13): status Edit: Reverted back to 4.5.6, just to verify there was no issue from my copy procedure. No more errors. I've not loaded the new version here yet... So I have not yet seen the errors you are describing from unmenu. Apparently something changed in the output of mdcmd that unMENU uses to get the array status. I'm in the middle of something right now and won't be able to reboot the server until late tonight to see if I get the same messages. In the interim, either revert, or ignore the errors. What version of unMENU are you running? (look in the "About" link) Joe L. Link to comment
limetech Posted November 17, 2010 Author Share Posted November 17, 2010 This fix addresses the same crash symptom reported in various threads, e.g., http://lime-technology.com/forum/index.php?topic=8376.msg80937#msg80937 http://lime-technology.com/forum/index.php?topic=6969.0 http://lime-technology.com/forum/index.php?topic=8027.0 http://lime-technology.com/forum/index.php?topic=7981.0 and others. The problem is a race condition in the unRaid driver command/status interface via the /proc file system. Rather than using ioctl()'s to interact with the driver, the driver uses the pseudo-file "/proc/mdcmd". The idea is that you write the /proc/mdcmd file with a "command", and then read the /proc/mdcmd file to get the command result. The problem shows up in a case where two (or more) threads are trying to interact with the driver at the same time. Normally the driver "sees" write/read to mdcmd file, but with multiple threads with a fast multi-core cpu, it's possible for the driver to "see" write/write/read/read - well the 2nd read is messed up because of this sequence. This is solved by tweaking the semantics of the API somewhat. What happens now is the completion status of a command is given by the return code to the write. In addition, the 'status' command was removed completely and instead any read of mdcmd acts as if the 'status' command was previously issued. Anyway, mbryanr has found a slight issue. I tested this fix with a couple people who I worked with via email - apparently they are not using unmenu - because unmenu is issuing the old style "write status to /proc/mdcmd then read /proc/mdcmd" (or in fairness, probably using the 'mdcmd' script). So this leads to an interesting conundrum: I can either put back a "dummy" status command, or the author of unmenu can change their code to not issue "mdcmd status" (and just read the /proc/mdcmd file to get status). In this particular case, I will probably create a releaes 4.5.8 that puts in a dummy status command. But this kind of issue will become more prevalent in version 5.x - that is, to what extent should new code not break old code? Link to comment
limetech Posted November 17, 2010 Author Share Posted November 17, 2010 copied the two files over to the flash with TerraCopy; upon reboot noticed this error - which keeps repeating... Nov 16 19:28:47 Tower unmenu[1377]: /root/mdcmd: line 3: echo: write error: Invalid argument Nov 16 19:28:47 Tower kernel: mdcmd (12): status Nov 16 19:28:54 Tower unmenu[1377]: /root/mdcmd: line 3: echo: write error: Invalid argument Nov 16 19:28:54 Tower kernel: mdcmd (13): status Edit: Reverted back to 4.5.6, just to verify there was no issue from my copy procedure. No more errors. I've not loaded the new version here yet... So I have not yet seen the errors you are describing from unmenu. Apparently something changed in the output of mdcmd that unMENU uses to get the array status. I'm in the middle of something right now and won't be able to reboot the server until late tonight to see if I get the same messages. In the interim, either revert, or ignore the errors. What version of unMENU are you running? (look in the "About" link) Joe L. Joe, see my reply above - this is because I changed the API slightly. I can easily fix this but will require releasing 4.5.8, which I'll get to later tonight. Link to comment
Joe L. Posted November 17, 2010 Share Posted November 17, 2010 copied the two files over to the flash with TerraCopy; upon reboot noticed this error - which keeps repeating... Nov 16 19:28:47 Tower unmenu[1377]: /root/mdcmd: line 3: echo: write error: Invalid argument Nov 16 19:28:47 Tower kernel: mdcmd (12): status Nov 16 19:28:54 Tower unmenu[1377]: /root/mdcmd: line 3: echo: write error: Invalid argument Nov 16 19:28:54 Tower kernel: mdcmd (13): status Edit: Reverted back to 4.5.6, just to verify there was no issue from my copy procedure. No more errors. I've not loaded the new version here yet... So I have not yet seen the errors you are describing from unmenu. Apparently something changed in the output of mdcmd that unMENU uses to get the array status. I'm in the middle of something right now and won't be able to reboot the server until late tonight to see if I get the same messages. In the interim, either revert, or ignore the errors. What version of unMENU are you running? (look in the "About" link) Joe L. Joe, see my reply above - this is because I changed the API slightly. I can easily fix this but will require releasing 4.5.8, which I'll get to later tonight. I see. Yes, I do use the "status" command, and in fact, it is the /root/mdcmd shell script I invoke as "/root/mdcmd status|strings" (The output of the status command sometimes contains non-printable characters so I pass it through strings to get rid of them) As far as new code not breaking old code... Well... we'll deal with those issues as they occur. The big issue is communications, since the release announcement only described a kernel oops fix, and did not mention the API change. I can modify unMENU quickly enough, and it has a "Check for/Install Updates" feature, so once I code the change it will be easy for users to get the newer version. (two button clicks, one to check for the update, the second to download/install it from google.code) Let's both make our respective changes. I'll read /proc/mdcmd directly. You fix the race condition. I would not have had the error here as my older server is the original Intel MB, and not a multiple CPU server. There will be other scripts written by other people needing to be changed though, as I know I'm not the only one looking at the output of /root/mdcmd. They too will need to make corresponding changes. Joe L. Link to comment
Joe L. Posted November 17, 2010 Share Posted November 17, 2010 I can modify unMENU to read /proc/mdcmd directly, but if it is used on an older version of unRAID I think I still need to issue a prior command to get the status... or do I? Can I just use strings /proc/mdcmd and process the output? Even on older releases? Or, should I continue to echo "status" to /proc/mdcmd, even if it is being ignored/no longer valid? Link to comment
prostuff1 Posted November 17, 2010 Share Posted November 17, 2010 Since I come from apple land I tend to lean towards the side of make your changes Tom and we, the developers, will work around them and make things work. I know I have used the command JoeL mentions multiple times in my testing, messing with, and coding of my own scripts. Since we know it has changes we can make the adjustments, but if you can give a command that would do the same thing as /root/mdcmd status|strings Link to comment
Joe L. Posted November 17, 2010 Share Posted November 17, 2010 Since I come from apple land I tend to lean towards the side of make your changes Tom and we, the developers, will work around them and make things work. I know I have used the command JoeL mentions multiple times in my testing, messing with, and coding of my own scripts. Since we know it has changes we can make the adjustments, but if you can give a command that would do the same thing as /root/mdcmd status|strings from what he described, you'll be able to use strings /proc/mdcmd Link to comment
MortenSchmidt Posted November 17, 2010 Share Posted November 17, 2010 It sounds like this would cause issues with the unraid_notify 2.55 package as well (found at http://lime-technology.com/forum/index.php?topic=2470.0). If this change is really needed, so be it, but if a fix can be made with a 4.5.8 release I would appreciate it a lot. I have been having some strange crashes on two occasions after upgrading to 4.5.6, that have manifested after server has been up about 3 weeks. Symptoms included the shares being down, the webinterface and unmenu as well. First time I observed it, I was able to telnet in, but an attempt to copy the syslog to /boot would then hang it completely. The other time I was unable to telnet in. Therefore I didn't get any syslog. Link to comment
Joe L. Posted November 17, 2010 Share Posted November 17, 2010 It sounds like this would cause issues with the unraid_notify 2.55 package as well (found at http://lime-technology.com/forum/index.php?topic=2470.0). If this change is really needed, so be it, but if a fix can be made with a 4.5.8 release I would appreciate it a lot. I have been having some strange crashes on two occasions after upgrading to 4.5.6, that have manifested after server has been up about 3 weeks. Symptoms included the shares being down, the webinterface and unmenu as well. First time I observed it, I was able to telnet in, but an attempt to copy the syslog to /boot would then hang it completely. The other time I was unable to telnet in. Therefore I didn't get any syslog. By far the simplest is if Tom makes the /root/mdcmd status command functional, even if the "status" command is a dummy one ignored by /proc/mdcmd. Joe L. Link to comment
limetech Posted November 17, 2010 Author Share Posted November 17, 2010 Version 4.5.8 has been posted to restore backward compatibility with 3rd party add-ons. This thread is now closed. Link to comment
Recommended Posts