Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 20 Oct 2007 16:21:39 +0200:
>> With mainline kernel suspend-to-disk working > > it doesn't work well with xpress200m chipset and tends to break the > system stability. or at least the last time i tried it (2.6.22). it > works for me the suspend to ram, but that consumes the battery and on > shutdown it releases everything stored into ram. That's interesting... most docs I've read, including most of the docs in the kernel Documentation dir (mostly in Documentation/power) indicate that suspend-to-RAM is considerably more iffy than suspend-to-disk (aka hibernate). I've not tried suspend-to-RAM in ages, mainly because it doesn't shut all the fans and etc. off on my system, so it's hardly worth the hassle, particularly when support is iffy anyway, tho I did have it sort of working at one point... Hibernate, however, I'm very glad I have, and that it works... most of the time anyway. I will note that it breaks from time to time with -rc kernels and etc, and I've had problems when I was trying to use an image larger than the swap partition I was putting it on (I tried 4 gig at one point, but with headers and etc, the actual available size is slightly under that... that one was hard to diagnose because it takes awhile to get a 4 gig memory set, so it would work for several suspends, then break...) or when I (experimentally) forced it to suspend to RAID, which apparently isn't up when the resume attempt is made. I'd try with 2.6.23. They did do some major changes re hibernate with .23, which broke it until rc-7 or so. Maybe whatever they did fixed it for your system. Do note that in many cases, the video drivers don't properly restore into X after a hibernate. If you CTRL-ALT-Fn out of X to a text console, you may have better results. Additionally, if you are running a framebuffer console, consider trying text mode vgacon. Resuming from it may work better. Also, my (self-developed) hibernate script stops the ntp and ntp-client services and restarts them after resume. You probably don't have those on a laptop, but it's possible other services you have interfere. It's often recommended that you build your NIC drivers as modules, for instance, and shut down your network and remove the modules before hibernate. That tends to work better on some systems. You may wish to consider dropping to single-user mode (telinit 1) for initial testing. If that works reliably, you know it's possible. From there, you can create a new runlevel that's almost empty, and add services one or two at a time, until you find what's causing the problem. To reduce the chance of filesystem issues due to a bad shutdown when it doesn't resume correctly, always sync the disk at least three times in a row before you hibernate. You can either make this part of your hibernate script or, if you have the emergency SYSRQ keys configured into your kernel, use that (Alt-SysRq-S) to sync. That has saved me corrupted filesystem hassles a number of times, when I was testing -rcs or for some other reason ended up not being able to suspend properly. Finally, I don't know a lot about it, but a lot of people who can't get the mainline kernel hibernate to work swear by swsusp2. It's worth trying a kernel patched with that and the related userspace tools and config, if you haven't. Anyway, if you are truly shutting all the way down multiple times per day as it looks like, yes, I can certainly understand the irritation you'd have with portage, because it indeed takes a quite a bit of time to do its thing from a cold cache. > my notebook does only > support a 80gb (i'm planning an upgrade to 160 when it runs out of > waranty - on february) so i don't have neither the space needed for a > great swap neither a raid array on it. i'm also meditating to acquire a > new notebook the next year so i really wonder how much would it repay a > disk upgrade to the old one. Well, you haven't mentioned what size swap you /are/ running, or what size memory, for that matter. I originally referenced 4 gig since that's what each of my four swap partitions are, but anything larger than the default half gig hibernate image_size is going to be dramatically better. If you have a single 1-gig swap partition, checking the exact size in KB (as found in /proc/swaps) and setting that in /sys/power/ image_size will double it from the default, and that alone will be quite noticeable. A gig of swap is the normally recommended size for a half- gig of memory. If you happen to have a gig of memory and two gigs of swap, so much the better. (I honestly don't know if two gigs swap/ suspend-image with only a half gig memory is worth it or not.) Beyond that, I'd not worry about unless you really do have the resources to spare. > for what i've learned portage is not thread safe. thus, i've myself been > using 2 or three paludis threads at the same time after verifying that > the packages compile in one terminal don't relate to other ones. but > having something that actually does this without me needing to worry for > that would be better. It didn't used to be, but portage has been relatively parallel-build safe for quite some time now, altho there are very occasional bugs at least in ~arch portage related to it, but occasional bugs are expected in ~arch, and even then, I've not read of any corruption for quite some time. At the worst, one has to manually stop one of the parallel merges to let the other proceed, if they get deadlocked. There's a single bug open on that ATM, but it's pretty rare to hit it. (I've never hit it myself and only noticed it browsing thru bugs out of curiosity.) > by the way, i've seen a thread of you speaking of a tyan > with opteron and i'd like to think what you think of opteron vs athlon. > i'm planning a desktop middle ranged home server with some db, mail, > rsync, mythtv, compilation server and occasionally running some games > and i'd like to know if it worths buying an opteron dualcore or it's > better an athlonx2. The differences aren't that great, really, if you are staying with a single socket, and I'd actually recommend going with the desktop rather than the server version, not so much for performance, but simply due to cost, unless you do need a dual (or more) socket system -- which with dual-cores and now quad-cores you probably don't. The main reason I went Opteron originally was to get dual socket support and the close cooperation of the Opteron Hyper-transport CPU interlink between them, back before the dual-cores came out. I had never run a dual CPU system before, but after having been very happy with the upgrade to my original Athlon 500 MHz way back when, I had been disappointed with my single-CPU upgrades since then. It just didn't seem they did all that much better than the half-gigahertz Athlon of several generations earlier. I realized that what I really wanted/needed for my workload was a real dual CPU system, and took the chance when the Opterons came out with their close cooperation over the Hyper-transport link, to upgrade to 64-bit and dual CPU both at the same time. I wasn't disappointed. Both the AMD64 architecture and the dual Opterons in SMP way more than met my expectations. The press was and to a degree still is complaining about how folks don't /need/ dual-core or dual-CPU, and much of the time one sits there idle. That's true to some extent, yes, but OTOH, it /really/ makes a difference on responsiveness, especially when one CPU/core is going flat-out, perhaps because it got stuck in a runaway loop or whatever. I'd honestly have a very hard time going back to a single core single CPU system (and in fact, find myself frustrated sometimes, working on other systems... that seem so /slow/). However, dual socket mobos are relatively expensive, generally more than twice what a comparative single-socket mobo would cost, because they simply aren't mainstream enough. With the introduction of dual-cores, and now quad-cores, there's really little reason to go dual-socket at the mainboard. If one's not doing that, there's little reason to go Opteron. Add to that the fact that AFAIK, Opterons still require registered memory, while Athlon-X2s use standard memory at a MUCH lower cost, and the balance clearly tips toward the consumer/desktop chip. As a practical matter of cost, I'd tend to recommend a quad-core Barton or whatever they call the desktop targeted version now, over a quad or dual dual-core Opteron. I'd certainly go at least dual-core, but that's almost a given, these days. The other thing is memory. While registered memory is expensive overkill, one of the reasons I do NOT recommend an Opteron now, it can be worth getting a mobo and memory that support ECC. ECC is arguably worth the extra money, while registered memory is not. Of course, it's up to you, and many don't wish to spend that money, but I've had enough memory issues to appreciate solid memory and the stability it brings, and ECC does bring a bit of additional assurance in that regard. I'm not positive that the AthlonX2s and X4s or whatever they call them support ECC now, but if they do, I'd certainly consider that. If they don't, the balance tips back toward Opterons a bit, but I still don't think the registered memory is worth it, and believe Opterons require it, so I'd still say AthlonX2 or quad-core, and if ECC isn't available, just buy good memory and possibly run it slightly underclocked, if you want that extra stability. MHO, FWIW. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
