Freeze when running freebsd-update

Robert Simmons rsimmons0 at gmail.com
Wed Jun 27 17:51:22 UTC 2012


On Wed, Jun 27, 2012 at 2:33 AM, Dieter BSD <dieterbsd at 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.
>>
>> Well, it is geli. I'm unable to reproduce the freeze on the same
>> exact system with everything else the same except for no geli. I'm
>> going to move this thread over to geom, and continue it there. Thanks
>> for your help!
>
> It occurs to me that it will need twice as much memory for disk i/o.
> 1 buffer for encrypted and 1 for unencrypted. I know nothing about geli,
> so I don't know if it uses the buffer cache for both, or what.
> Could it be that the kernel isn't keeping enough memory free and
> manages to paint itself into a corner and not have space to store
> the unencrypted version of disk reads, and can't page/swap anything
> out to make space because it doesn't have space to store the encrypted
> version to write?

I think that's probably about what is happening.  I'm still waiting
for an answer on the geom mailing list, but I will do some testing
with increasing memory sizes and see where the problem stops
occurring.


More information about the freebsd-hackers mailing list