Interesting. I emerged this new love sources, and when I boot, it locks up on some messages that says BOOTING 2/15 processors. I only have 2 procs and SMP is enabled in the config file. Im using a .config from my Love 4 build that works great.

well looks like you enabled too much stuff
as a general rule, dont enable anything under reiser4 except "large key support".

about the renicing tip, I suppose it works to an extent, but the key thing now is dont try to "over" stress it (compiling stuff while watch movies is ok, while compiling 4 things while playing ut2k4 and running sati is not ok )
but atleast i can upgrade my glibc now
peace

I have /portage as r4 and have just compiled xorg-x11 with no trouble on 2.6.6-love4 , would this be the kind of use likely to cause a lockup?

If so the comparison may be helpful / enlightening.

It's nice to have the "nice -15" work-around but does seem to indicate a serious flaw somewhere in the coding if the disk I/O has to be massages like that to prevent it locking up. A bit worrying.

heavy usage here = high cpu load + high reiser4 fs usage (mainly /var/tmp/portage)
also the lock up under heavy load is rather a new bug so I'm looking into it with Zam.
so if you have /var/tmp/portage on a sperate not-reiser4 partition you're safe.

@Jowilly try ivman please, *mount will be removed very soon., ivman pretty good. if you need help with it, join us on irc.

well looks like you enabled too much stuff
as a general rule, dont enable anything under reiser4 except "large key support".

about the renicing tip, I suppose it works to an extent, but the key thing now is dont try to "over" stress it (compiling stuff while watch movies is ok, while compiling 4 things while playing ut2k4 and running sati is not ok )
but atleast i can upgrade my glibc now
peace

Yep! That is what is was. Thanks. _________________The strong must protect the Sweet.

I have /portage as r4 and have just compiled xorg-x11 with no trouble on 2.6.6-love4 , would this be the kind of use likely to cause a lockup?

If so the comparison may be helpful / enlightening.

It's nice to have the "nice -15" work-around but does seem to indicate a serious flaw somewhere in the coding if the disk I/O has to be massages like that to prevent it locking up. A bit worrying.

heavy usage here = high cpu load + high reiser4 fs usage (mainly /var/tmp/portage)
also the lock up under heavy load is rather a new bug so I'm looking into it with Zam.
so if you have /var/tmp/portage on a sperate not-reiser4 partition you're safe.

peace

Sorry, I should have been more accurate. What I meant was /usr/portage and my $PORTAGE_TMPDIR is under this structure so all emerge and tmpdir is on r4 and fine under 2.6.6-love4.

I have problems with the latest love-sources (the ones from 2.6.7), they compile fine, booting from cold start ok, but when I do a simple reboot,my system hangs at "starting cupsd", ok but that's a minor problem.
with the 2.6.7 sources I can compile the nvidia kernel (without errors) but when I try modprobe nvidia, I get an error of nvidia module.
I just copied the .config file of my lover sources 2.6.6-love4 to the directory of 2.6.7 and did oldconfig.
I'm using nvidia-kernel 4496-r3, it worked fine with anterior love-sources (last was 2.6.6-love4)
For the moment I reverted using 2.6.6-love4, but I ould like to use the 2.6.7 kernel as well, what I'm doing wrong?

I had those problems with nvidia-kernel as well in the past and with this kernel. It seems that nvidia's drivers are getting nasty with the newer kernels and gcc releases. Recompiling both the kernel and nvidia-kernel with gcc-3.3.3 fixed my seg faults when loading the nvidia module. You might give that a try.

Symptoms: kernel builds fine, nvidia driver builds fine, modprobe nvidia is successful and returns no error, but startx switches to a black screen and locks up keyboard and mouse, required Alt+SysRq+K to be able to switch back to a console and then kill -9 X -- modprobe -r nvidia and then switching to nv driver worked okay

If this workaround applies to you: 1) You are using the hotplug scripts at boot runlevel (as mentioned in gentoo's udev guide) -- these are in the package sys-apps/hotplug and applies to version 20040401, and -- 2) during the boot scripts (* Starting xxx [ ok ]), you see the phrase Disabling IRQ #X, and 3) cat /proc/driver/nvidia/cards/0 shows your AGP slot using the same IRQ

The workaround: Currently it looks like PCI Hotplugging is the culprit and for some reason determines that the AGP IRQ is spurious and therefore disables it -- since udev only requires sys-apps/hotplug-base, not sys-apps/hotplug, it is safe to rc-update del hotplug -- if you rely on hotplug to load any modules (USB drivers especially) then add those to autoload for now

Anyone else noticed strange swap behavior with this kernel? According to top I have 256MB of ram free but yet I've got 86mb of crap in swap. Have the kernel developers gone insane and started trying to copy Microsoft's memory mismanagement or something?

As I'm very happy with mm-sources, I think about trying love-sources, but me keyboard doesn't works, and the keyboard-ps2 patch doesn't work to me patch says line 11 is wrong... may be because I do it wrong :