Opened 15 years ago

Closed 7 years ago

#5692 closed bug (fixed)

vm-pagefault: unhandled pagefault in kernel space

Reported by: HAL Owned by: axeld
Priority: high Milestone: R1
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (6)

vm_pagefault​ (467.5 KB ) - added by HAL 15 years ago.
vm_pagefault.jpg​ (467.5 KB ) - added by HAL 15 years ago.
vm_pagefaultl.JPG​ (440.2 KB ) - added by HAL 15 years ago.
Better quality picture
vm_pagefault_bactrace.jpg​ (446.6 KB ) - added by HAL 15 years ago.
Better quality picture
minicom-37908.log​ (7.5 KB ) - added by mmadia 14 years ago.
serial debug log of similar (or exact KDL) on hrev37908+checkfs.
checkfscrash.jpg​ (323.6 KB ) - added by idefix 14 years ago.
Screenshot of KDL and showing two clean checkfs runs and after that a checkfs run with error

Change History (24)

by HAL, 15 years ago

Attachment: vm_pagefault​ added

by HAL, 15 years ago

Attachment: vm_pagefault.jpg​ added

comment:1 by HAL, 15 years ago

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

by HAL, 15 years ago

Attachment: vm_pagefaultl.JPG​ added

Better quality picture

by HAL, 15 years ago

Attachment: vm_pagefault_bactrace.jpg​ added

Better quality picture

in reply to:  1 comment:2 by HAL, 15 years ago

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.

comment:3 by bonefish, 15 years ago

Component: - General → File Systems/BFS
Owner: changed from nobody to axeld
Status: new → assigned
Version: R1/alpha1 → R1/Development

comment:4 by HAL, 15 years ago

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

comment:5 by HAL, 15 years ago

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.

comment:6 by HAL, 15 years ago

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.

comment:7 by HAL, 15 years ago

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.

comment:8 by HAL, 14 years ago

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?

comment:9 by HAL, 14 years ago

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.

by mmadia, 14 years ago

Attachment: minicom-37908.log​ added

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

comment:10 by mmadia, 14 years ago

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.

Hmm... checkfs works fine in hrev37942.

Last edited 14 years ago by mmadia (previous) (diff)

comment:11 by anevilyak, 14 years ago

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?

comment:12 by mmadia, 14 years ago

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)

comment:13 by idefix, 14 years ago

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).

by idefix, 14 years ago

Attachment: checkfscrash.jpg​ added

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

comment:14 by X512, 14 years ago

Still present in 39156.

comment:15 by RahulAN, 7 years ago

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

comment:16 by HAL, 7 years ago

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

in reply to:  16 comment:17 by RahulAN, 7 years ago

@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.

comment:18 by waddlesplash, 7 years ago

Resolution: → fixed
Status: assigned → closed
Note: See TracTickets for help on using tickets.