vm-pagefault: unhandled pagefault in kernel space

[HAL]

I did a checkfs command in the Terminal. The system then went to KDL.

1. In Terminal type: checkfs /boot
2. Press Enter.

After a few seconds it goes to KDL. I was testing in hrev36043 gcc2 hybrid.

[HAL]

In the gcc4 hybrid hrev36056 version I cannot reproduce this bug.

[HAL]

Better quality picture

[HAL]

Better quality picture

[HAL]

Replying to HAL:

In the gcc4 hybrid hrev36056 version I cannot reproduce this bug.

I tried again to see if this was consistently so. It does not seem consistenly reproducible. The bug is still valid.

[HAL]

Have not been able to reproduce in hrev36476 GCC4 Hybrid so far. It might be fixed.

[HAL]

Well it seemed reproducible then in hrev36476 non reproducible after many tests but suddenly in the same version I can reprodue it consistently. I cannot pin down what seems to turn it of and on.

[HAL]

I have reinstalled the same version hrev36476 and now again it is not reproducible. The only changes I have not yet made to get it back to exactly all the applications and settings is: Gnash and Webositive have not been installed yet. I will try one at a time.

[HAL]

I tried to see if the bug was made reproducible after installing Webpositive but no. Tried again after Gnash and dependencies, the same. I cannot find what enables this bug unless when something in the file system needs to be rectified by checkfs, then makes it fail.

[HAL]

The bug is back to been reproducible in hrev36707. I was not able to reproduce it in R1/alpha2. Not certain if the bug is just coming and going or it only manifests in file system corruption. How can I tell if there is file system corruption other than trying to run checkfs?

[HAL]

I am quite certain the bug only manifests when a file system repair is needed. I deliberately did a hard reset with trcker window open and a Bepdf file open. After rebooting I tried checkfs in the Termonal and got the same KDL screen and backtrace.

[mmadia]

serial debug log of similar (or exact KDL) on hrev37908+checkfs.

[mmadia]

hrev37908, I can reproduce a similar (or exact) KDL by running checkfs on a spare data partition. A remote kdebug session over ssh can be setup, if desired.

[anevilyak]

Interestingly, I hit this one just now with hrev37948 by doing a checkfs -c followed by a full checkfs (because -c indicated 2 blocks could be freed). However, on reboot it's no longer reproducible + checkfs now indicates 0 blocks could be freed. Anything worth looking into in KDL next time if it occurs again?

[mmadia]

I managed to reproduce this. I'll keep the box in KDL at least until 19:00 utc sunday. Hopefully someone will want to do a ssh based serial debug session. (ssh in to a 2ndbox here and control KDL via serial_input)

[idefix]

I can also reliably reproduce this crash with checkfs on hrev38803.

The volume is initialised with a block-size of 1024 and no index. It contains a full checkout of Haiku.

When I repeatedly run checkfs on this volume, it will find no errors the first 2 or 3 times. After that, another checkfs suddenly can't open a random inode and, after it continues, it will KDL at the end. See attachment:checkfscrash.jpg​.

Some more info: running hrev38803 on real hardware (PII @ 400 MHz, 384 MiB, 2.04 GB swap).

[idefix]

Screenshot of KDL and showing two clean checkfs runs and after that a checkfs run with error

[X512]

Still present in 39156.

[RahulAN]

I am not able to reproduce on my machine with latest Haiku Image.

[HAL]

I cannot reproduce it now either. In latest versions. It is probably fixed.

[RahulAN]

@alexd, you could close this ticket, as it is fixed and confirmed by @HAL

Replying to HAL:

I cannot reproduce it now either. In latest versions. It is probably fixed.