DragonFlyBSD

• Matthias Schmidt wrote:

Moin,

I installed a recent master (2.7.3.1095.g4cdde1) on my old IBM Thinkpad
T42 and I installed the system on an encrypted HAMMER root volume.
While installing packages and using X I made some observations:

- After a crash, the "loader" in the initial ramdisk is no longer able
to load the real init. It displays all HAMMER related messages about
an unclean file system and stops right after "recovery complete". I
can move the cursor and panic the system, but nothing else happens.
Rebooting the live CD and mounting the partition fixes the problem.

I can reproduce it. Every time I run "hammer cleanup" the system
freezes.

Cheers

Matthias

:
:* Matthias Schmidt wrote:
:> Moin,
:>
:> I installed a recent master (2.7.3.1095.g4cdde1) on my old IBM Thinkpad
:> T42 and I installed the system on an encrypted HAMMER root volume.
:> While installing packages and using X I made some observations:
:>
:> - After a crash, the "loader" in the initial ramdisk is no longer able
:> to load the real init. It displays all HAMMER related messages about
:> an unclean file system and stops right after "recovery complete". I
:> can move the cursor and panic the system, but nothing else happens.
:> Rebooting the live CD and mounting the partition fixes the problem.
:
:I can reproduce it. Every time I run "hammer cleanup" the system
:freezes.
:
:Cheers
:
: Matthias

How much memory does this system have?  The problem is almost
    certainly buffer cache / memory-exhaustion.  The crypto layer
    uses memory heavily.  We need a kernel panic / kernel core
    when it gets stuck to verify that is the issue.  Swap cannot
    be encrypted if you want the kernel core to have a chance of
    succeeding in this situation.

Both hammer cleanup and crypto are heavy kernel memory users.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Moin,

• Matthew Dillon wrote:

How much memory does this system have? The problem is almost
certainly buffer cache / memory-exhaustion. The crypto layer
uses memory heavily. We need a kernel panic / kernel core
when it gets stuck to verify that is the issue. Swap cannot
be encrypted if you want the kernel core to have a chance of
succeeding in this situation.

Both hammer cleanup and crypto are heavy kernel memory users.

1GB RAM. The swap partition is not encrypted, only the HAMMER root fs.
The machine froze various times in the last days, but I didn't get a
dump ... any ideas?

Do you have any idea why the system cannot load the real init process
when the HAMMER fs is unclean?

Cheers

Matthias

• Matthew Dillon wrote:

How much memory does this system have? The problem is almost
certainly buffer cache / memory-exhaustion. The crypto layer
uses memory heavily. We need a kernel panic / kernel core
when it gets stuck to verify that is the issue. Swap cannot
be encrypted if you want the kernel core to have a chance of
succeeding in this situation.

Both hammer cleanup and crypto are heavy kernel memory users.

I was able to crash the system but I didn't get a crash dump again. I
started dozens of applications in X (including FF and soffice) and ran
hammer reblock while on syscons. The last message I saw before the
system freezed was:

td 0xc04a24c0 (ithread 69) unexpectedly rescheduled

Cheers

Matthias

Maybe you could write a script that continuously (every 500ms?) refreshes a vmstat
-m output of dm and dm_crypt malloc tags and then run hammer reblock in the
background?

This sounds a lot like the problem I was having in issue1976. It was fixed in
c9f7645b973a801d99a9ae073ff8363caf483082. Can you verify it's fixed for you?