[gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560710200721v2aa321fak9a7bbf3b0eb3b145@××××××××××.com, 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

-- 
gentoo-amd64@g.o mailing list