Hi Amit, Amit Kulkarni wrote on Tue, Sep 09, 2014 at 08:47:22PM -0500:
> A basic rule of thumb when building ports: raise your /etc/login.conf > limits...especially datasize-cur needs to be 2G and datasize-max needs to > be 3G. The reason being there are some ports where the linker blows up to > 2G or slightly over. The worst offenders are usually the www/webkit or > chrome or firefox. Though py-py also takes a lot of memory. Sure. When i see ld(1) dying from signals, i'll bump limits. But that's not what what i'm talking about. Memory allocation failure in ld(1) is hopefully not going to cause a hard kernel lockup. Besides, almost all the kernel lockups i saw today happened while trying to build either archivers/gtar or misc/fileutils. Those are not going to hit any limits. > There is also another well-known bug in the I/O path which espie@ > referred to a few months ago. But it is as yet undetected? It rears > its ugly head when your machine does a lot of I/O. Try running cvsync, > building ports, run a find/grep over ports tree, and try to browse > with firefox all at the same time. The system feels as if it goes > into a hang. But give it a few seconds and it comes back normally. > Is this what is happening with you? I did see temporary userland lockups caused by firefox in the past, though not lately, and i'm not sure it was the same you are referring to. Besides, those could always be interrupted with Ctrl-Alt-Backspace. What i'm seeing here locks up the kernel, not merely X, and for good. Anyway, i'm going to shut up now. As i can't even provide a backtrace, tech@ is clearly the wrong list. At least i should bisect when asking for help, but i can't afford the time right now. I'll continue to test floating patches that seem possibly related (to my naive understanding), and i'm sure kettenis@ will continue to fondly remind me that a patch for FOO is not going to magically fix BAR whenever my understanding turns out to be nothing but a mis- (thanks for that). Yours, Ingo
