Re: [gentoo-amd64] Re: Weird and unpredictable problem: emerge grinds system to a halt

[Petter Haggholm]

Duncan wrote:
> Daniel Iliev <danny@××××××××.com> posted 451B6C1E.8020503@××××××××.com,
> excerpted below, on  Thu, 28 Sep 2006 09:30:54 +0300:
>
>
>> Petter Haggholm wrote:
>>
>>> The subject is fairly descriptive. Often -- but not always -- an
>>> emerge will render my system unusable. At a PORTAGE_NICENESS of 3, and
>>> fairly standard MAKEOPTS of "-j2" (on a single-core system), I'm ...
>>> well, rather surprised, confused, and very frustrated. [] The system
>>> becomes unresponsive, the mouse will move but with enough of a lag that
>>> physically moving it may not cause a cursor movement for the next 30
>>> seconds or so, clicking a taskbar window may not have an effect at all;
>>> sometimes I can't even ssh into the system from my other computer (to
>>> kill the emerge) because it's slow enough that the ssh daemon times out
>>> my login attempt. This never used to happen[.]
>>>
>>>
>> 2) What happens if you put PORTAGE_NICENESS=19, MAKEOPTS of "-j2 -l1" ?
>> l5 (small "L", not the number "one"), means "loadavg=<1" If loadavg goes
>> up to 1 make waits this level to drop before continuing its job
>> 3) Is DMA enabled for your HDD(s)? (hdparm -d1 /dev/xxx)?
>>
>
> I second those two suggestions.
>
> It never used to happen?  I'll just /bet/ you somehow disabled hard drive
> DMA access.  In addition to checking hdparm, ensure that you have the
> correct drivers for your hard drive chipset being compiled with the kernel
> and verify from your log (or dmesg) that they are loaded and active -- the
> kernel isn't loading generic drivers that grab the hardware first so the
> chipset specific drivers can't grab the hardware themselves.
>
> It's almost certainly I/O access in any case, so portage niceness probably
> won't do a lot of good, tho reducing to -j1 or -j2 -l1 or -j1 -l1 might
> help some.  You can also try different I/O and task schedulers, and tweak
> your kernel preemption settings.
>
> [snip the stuff about systems with lots of RAM; mine doesn't]
I figured I'd give your suggestion a shot. I certainly never *disabled* 
hdparm, and I haven't altered my kernel options for IDE drivers in ... 
well, heaven knows how long. However, upon checking my menuconfig, I 
find that I unnecessarily have generic IDE chipset support in addition 
to the appropriate driver; I just disabled that, recompiled the kernel, 
and rebooted (for the first time in 19 days, which made the pre-reboot 
dmesg output a little intractable).

I/O schedulers ... well, I've already played around with those, as well 
as playing with the kernel pre-emption and timer settings, and no 
permutation helped before, so I left that as it was.

So far, it looks promising -- I just built a package that caused me 
problems earlier, followed by an `emerge -DuN world` (only four 
packages, though); no problems yet. Unfortunately, the problem has 
appeared nondeterministic, so I don't yet know whether it'll magically 
reappear to terrorise me later. Hopefully, the IDE driver thing fixed 
it; if not, I'll be back to complain more when the problem reappears. 
Thank you for the help, and wish me luck ...

-- 
Petter Häggholm
-- 
gentoo-amd64@g.o mailing list