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