On Tue, Jun 26, 2012 at 8:54 PM, Dieter BSD <dieter...@engineer.com> wrote: > Robert writes: >> 3) the box is responsive to hitting enter at the console (it produces >> another login: prompt) > > Getty is in memory and can run. > >> 5) if I try to login to the console, it lets me enter a username then >> locks up totally, it does not present me with a password: prompt. > > Login(1) is not in memory, and the kernel cannot read it from disk > for some reason. > > I can get this symptom by writing a large file to a disk on a > controller that FreeBSD doesn't support NCQ on. I assume there > is a logjam in the buffer cache. Something trivial like reading > login in from disk that would normally happen in well under a > second can take many minutes. > > Perhaps geli is causing a similar logjam? Does it hang forever or > is it just obscenely slow? If it truely hangs forever it is > probably something else. Is there disk activity after it hangs? > Can you try it without geli? systat -vmstat might provide a clue.
I've done some more testing with forkbomb and if I bump the memory up to 512M I just get an error message on the console about the user exceeding maxproc and approaching the limit on PV entries. At that point I'm able to Ctrl-C and stop forkbomb: no freeze. I have a number of these instances, and I will reinstall one geli-free and see what happens. I will also reproduce the initial conditions and leave it for the night to see if it comes out of it. After a certain point there is no disk activity, and the uptime counter in the corner of top eventially freezes too, so I don't think it will come out of this, but we'll see. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"