bblue

I too can get around in vi if I have to, but would rather not. My personal favorite for years has been 'jove' (Jonathan's Own Version of Emacs). It's not a full implementation of Emacs but has more than enough for everyday use and programming, plus it's small and fast and can be built for most any unix-like os. Works well over putty or even telnet in a windows cmd window. Of course, the command set is all emacs, which some would also say is an acquired taste... Look for jove-4.16.0.61-i386-1.tgz or newer. --Bill

It used to be the case (several years ago) that you'd get a pretty decent working BIOS in most boards. With newer chipsets, features, overclocking capabilities and onboard devices, and the frantic rush to ship product, we're far more prone to receive an older, immature BIOS than ever before. If you don't notice problems, good for you. But that doesn't mean they don't exist or that they aren't affecting you in some way. MSI, for example, encourages you to be sure and install the latest BIOS as one of the first things you do upon installing a new motherboard. And, as it turns out, they seem to be among the worst with old buggy BIOS's shipped on a brand new product. Gigabyte prints the usual warning/caution about BIOS updating as a formality, but elsewhere they provide details of fixes and encourage the update. ASUS is pretty much the same with the warning. But they ALL are several BIOS revisions behind on new boards, with a variety of different issues. I always perform an initial BIOS update, and after that, check periodically for newer updates that might have effect on some issue I've noticed (when fixes are disclosed). I generally don't update further unless there's been a significant list of fixes, or improved handling of on-board devices. By far the easiest way to do this for BIOS updates (motherboard or cards) is to make up a DOS bootable USB stick. Put each update, driver set, or what-have-you in its own directory ready to run with a supplied program. Then all you have to do is either boot the stick and go to the correct directory to run the appropriate program, or boot normally into the BIOS and flash the new image from there. It's quick and painless. --Bill

Regardless of which motherboard you choose to use or evaluate, be sure to update its BIOS to the most recent available on the manufacturer's web site. Even brand new boards will often have BIOS's that are several revisions behind -- and buggy to various degrees. My last two MSI P45 Neo2 boards had BIOS's that were three revisions old, and misbehaved badly under some scenarios. My last two Gigabyte EP43 series boards were four revisions behind. Updating them cured several inconsistencies. Likewise with Asus P5's and P6's. I'm not singling out these brands -- they all are like this apparently due to time spent in stock at the manufacturer or in distribution. If you don't know how to load (flash) a new BIOS, learn how! It's easy and likely to save you lots of frustration in the future. --Bill

Your Norco looks like it has a lot of commonality with my Chenbro RM41416b 4U case. How many active drives are you running in there now? I ask because I'm wondering how effective your cooling solution actually is. I used 5 80mm Noctual fans across that center divider because there was already hardware and plug-in shells for each fan. The fans it came with were much higher RPM and quite noisy. With 13 drives (1.5T and 2T) installed, 11 in the canisters and two (cache and parity) in the top positions, I'm finding that during a parity calc (any event that keeps all drives running for extended periods of time) the temperature of some of the drives gets into the low 50's C. Normally they run in the high 30's. It seems that three 120mm fans may marginally produce more air flow than five 80mm, depeding on their ratings So I'm wondering how many active drives you are running and how the drive temperatures maintain under an all-running scenario? --Bill

Ok, I could try that. This one is a new Corsair 650TX and seems completely stable when the unit is on for days at a time when no suspend is in play. I do have an extra 550TX here, but am not sure it will be sufficient to power up 13 drives. Will give it a shot. Thanks. I put the 550TX in last night, and it did power up with all the drives, no problem. Just took it out of suspend at 21 hours and it came right up as it should. Next will be a longer suspend time to verify. Odd too, the 650TX drew .04 watts during suspend. The smaller 550TX draws .06 watts during suspend. It's been several days now, and after trying a wakeup with as much as 35 hours of suspend, there have been no problems at all. Thanks for that tip, Bubba. Interestingly, I moved the original 650TX supply into a Windows 7 system and it has absolutely no problems resuming after any period of time. Different motherboard (MSI instead of Gigabyte) and different OS, but still... --Bill

No, it's still there, and I'll keep it there for quite a while. Everything looks ok from here, give it another shot. --Bill

Just pick up libx86-1.1-i486-1.tgz from http://packages.slackware.it in the 12.2 distribution, and install it with installpkg. --Bill

err... try again. http://nada.netoldies.com/s2ram ... HTTP Error 404 - File or directory not found. Cripes. Ok, I had to name it s2ram.bin to keep the server happy. Download and then rename it. Sorry about that. --Bill

Geez. Message corrected, sorry.

Ok, I have placed the Slackware binary for s2ram on my server at http://nada.netoldies.com/s2ram.bin . After downloading rename it to just s2ram. Lot's of info about how to use it can be found at http://en.opensuse.org/S2ram mostly on the #1 option. --Bill

Ok, I could try that. This one is a new Corsair 650TX and seems completely stable when the unit is on for days at a time when no suspend is in play. I do have an extra 550TX here, but am not sure it will be sufficient to power up 13 drives. Will give it a shot. Thanks. I put the 550TX in last night, and it did power up with all the drives, no problem. Just took it out of suspend at 21 hours and it came right up as it should. Next will be a longer suspend time to verify. Odd too, the 650TX drew .04 watts during suspend. The smaller 550TX draws .06 watts during suspend. --Bill

Ok, I could try that. This one is a new Corsair 650TX and seems completely stable when the unit is on for days at a time when no suspend is in play. I do have an extra 550TX here, but am not sure it will be sufficient to power up 13 drives. Will give it a shot. Thanks. --Bill

Nope. Just install the dev kit and gcc... compile it... copy the necessary files to a persistent location, and reboot to get rid of the dev kit. Ok, thanks. I'm currently installing the complete Slackware 13 distribution on an external e-SATA drive which I can use either on the dedicated unRaid server as an alternate boot, or on a dedicated machine. So one way or the other... I've compiled s2ram, and with the -f (force) and -p (post video) options the monitor comes back up when operation is resumed with a WOL packet. I noticed once before before video was working on resume (just suspending with the "echo 3 > /proc/acpi/sleep"), and again now with s2ram, that as long as the time between suspend and resume is low, something below 16 hours or so everything works as it should. But if the suspended time is more in the 24+ hour range the OS no longer appears to be operational on resume. The WOL packet wakes the system up with all drives spinning, but there is no video or network connectivity, and the system does not respond to a console keyboard ctrl-alt-delete to reboot. After a hardware reset everything reboots and comes back just fine. AFAIK, as long as RAM is powered and there's been no AC interruptions there shouldn't be any time limit involved. Does anyone have any ideas or suggestions on this? --Bill

Newegg has this card: http://www.newegg.com/Product/Product.aspx?Item=N82E16816124027 I think there has been a couple people try it in the unRAID server without success. Hopefully someone will get it to work. I got mine yesterday. It had an older RAID bios in it, so I flashed it to the newest standard bios. However, it does not work in unRAID. It initializes ok and sees drives in the bios, but when unRaid starts detecting and initializing the devices it stops and locks up at this card with IRQ errors, FF. I don't recall the entire sequence and I haven't done further testing on it yet. Since this is the first time a sil3124 has been built utilizing a PCI-e X1 slot, it could be a driver issue, but that's just a guess. --Bill Can you go into the bios of the card and disable the raid bios? I have to do this with my Adaptec 1430SA cards. Please continue the discussion of this board and it's use in unRAID here. Will do. When I reflashed the bios, I used the standard (not RAID) version. So yes, I disabled it. :-) I just finished setting up a full development machine w/Slackware 13 and the huge kernel The boot drive is e-SATA which can be moved from that machine and booted on my unRaid box for comparative motherboard vs cards tests. I'll test this card later tonight on the dev machine to a) see if the behavior is any different in 2.6.29.1 vs .6, and b) note what the exact errors are. I'll post here and see if anyone recognizes them. --Bill

Newegg has this card: http://www.newegg.com/Product/Product.aspx?Item=N82E16816124027 I think there has been a couple people try it in the unRAID server without success. Hopefully someone will get it to work. I got mine yesterday. It had an older RAID bios in it, so I flashed it to the newest standard bios. However, it does not work in unRAID. It initializes ok and sees drives in the bios, but when unRaid starts detecting and initializing the devices it stops and locks up at this card with IRQ errors, FF. I don't recall the entire sequence and I haven't done further testing on it yet. Since this is the first time a sil3124 has been built utilizing a PCI-e X1 slot, it could be a driver issue, but that's just a guess. --Bill

Nope. Just install the dev kit and gcc... compile it... copy the necessary files to a persistent location, and reboot to get rid of the dev kit. Ok, thanks. I'm currently installing the complete Slackware 13 distribution on an external e-SATA drive which I can use either on the dedicated unRaid server as an alternate boot, or on a dedicated machine. So one way or the other... --Bill

Do you have a link to somewhere with a compiled-for-Slackware version of it? I didn't find much besides the Suspend project source code on SourceForge which contains s2ram. I don't have the GCC compiler suite installed here presently. --Bill

This turns out to be caused by using a port multiplier on the motherboard AHCI SATA ports (ICH10 chipset). It only shows up when a local drive is really pushing fast transfers to the cache drive. Even if the cache drive is NOT on a PM or motherboard SATA port, it still happens. Move all PM's from MB to sil3132 PCI-e controllers and the behavior stops. So either there are still Intel bugs in this implementation of AHCI, or (more likely) the drivers in our unRaid kernel is not correctly handling the ICH10 chipset when PM's are involved. Shot down again. --Bill

I picked up a supposedly 16550 compatible AT Native dual serial board today, but it turned out not to be an exact emulation. Linux saw it as COM 1 and recognized the UART but was unable to initialize it. Then in small print on the package, a statement about all Windows drivers included. Well, a truly compatible board wouldn't need its own drivers. This motherboard has a 16550 compatible UART as well, but apparently not quite compatible enough for the Slackware drivers. I'm not really sure what else to try at this point. --Bill

I picked up a Diamond (ATI Radeon HD 4350) video card today and tried it instead of the EVA NVidia chipset card I had installed. NO difference. At all. It makes no attempt to come back up after the WOL. So, that and other similar reports with a variety of devices, leads me to believe that this is really a kernel/driver problem. There is a vga_reset program and a couple of others which may cause a driver reset in some of the kernel module packages, but there are no packages for the unRaid version of the kernel. There's a kernel-modules-smp-2.6.27.31_smp-i686-2.tgz for 12.2 Slackware and a kernel-modules-smp-2.6.29.6_smp-i686-2.txz for 13.0, but both of those packages have .ko kernel files that are of an incompatible format to ours. Is there someone with a full sized smp kernel they compiled that would have (or could have) compatible modules who could make up a full driver package for me to try? It looks like at least one vga related module might fix/patch the no video issue, and two others (usbserials.ko and ftdi-serial.ko) might get the serial port over USB working. Any info appreciated. --Bill

I meant to, sorry. Yes, very interesting. It was distressing to learn how much storage you *actually* had... :-) What was your basis for calculating the cache size? --Bill

I'll second that! Just wait. --Bill

Hmm, interesting. I've got to go to Fry's in a bit so I'll try something else. Maybe a low cost ATI or something. I have a bunch of extra cards but they're all PCI and this board uses PCI-e for video. Drat! None. New telnets, http's start right up, and telnet sessions that were in use continue right where they left off. Hard drives come up all on, though. --Bill

I have s3(STR) suspend working just fine, and the system wakes up no problem with a WOL magic packet, or a press of the power button. But there's no console video, and there doesn't appear to be any video related re-init options in the motherboard BIOS. The console keyboard (USB) works fine after WOL. I've seen this issue mentioned a few times here, but not with any specific resolution. Is there one? Or are there steps to try and isolate if it's hardware or software? The motherboard is Gigabyte EP43-U3DL, and video is an inexpensive EVA (NVidia 8800 chipset). It seems to work fine in all other aspects. I'm using the unRaid 4.5b6 build. Any suggestions would be helpful. --Bill

I run mover every hour on my machine, and more often than not it spins up all the drives each time. It's caused by the 'sync' command. There doesn't seem to be any reason to spin the drives up if there's nothing for mover to do, so I made a change in mover to test the cache drive before anything else. If cache is empty, skip over the finds and sync operations. If cache is non-empty, everything proceeds as usual. Here's just the code part of my mover which also leaves the top level share hierarchies instead of removing them (-mindepth 2 in the second find if you don't want that). Some might find this useful. # Only run script if cache disk enabled if [ ! -d /mnt/user0 ]; then exit 0 fi # If a previous invokation of this script is already running, exit if [ -f /var/run/mover.pid ]; then if ps h `cat /var/run/mover.pid` | grep mover ; then echo "mover already running" exit 0 fi fi echo $$ >/var/run/mover.pid # print without a newline echo -n mover started sz=$(du -s /mnt/cache | cut -f1) if [ $sz == 0 ] then echo ":no work" else echo (cd /mnt/cache ; \ find . \ \( -type d -regex '[.]/[^.].*' -exec mkdir -p /mnt/user0/{} \; \) , \ \( -type f -regex '[.]/[^.].*/.*' ! -exec fuser -s {} \; -exec echo moving {} \; -exec mv -v {} /mnt/user0/{} \; \) ; \ find . -mindepth 2 -type d -regex '[.]/[^.].*' ! -exec fuser -s {} \; -empty -delete \ ) sync fi echo "mover finished" rm /var/run/mover.pid --Bill