Opened 15 years ago
Closed 13 years ago
#5936 closed bug (invalid)
PANIC: vm_page_fault: unhandled page fault in kernel space at 0x0, ip 0x82dcfbe3
| Reported by: | tonestone57 | Owned by: | mmlr |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | System/Kernel | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | x86 |
Description
Haiku hrev36666, gcc2 hybrid, trunk build.
I would say that recent changes caused this new crash. I was able to boot Alpha2-rc on this machine without Haiku crashing (when I disabled ACPI).
Screenshot of stack trace attached. Let me know what else you need.
Attachments (4)
Change History (15)
by , 15 years ago
| Attachment: | vm_page_fault.jpg added |
|---|
comment:1 by , 15 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
follow-up: 4 comment:2 by , 15 years ago
comment:4 by , 15 years ago
Replying to mmlr:
Curios one really. From the output it looks like the gPCI pointer is NULL, but the PCI::FindDevice() call really is already the second use of gPCI in this function. It is already used to call PCI::ResolveVirtualBus(), so it should've crashed there already if not available.
The call itself doesn't dereference the object pointer (non-virtual method) and the method implementation doesn't dereference the this pointer either.
comment:5 by , 15 years ago
by , 15 years ago
| Attachment: | r36747-bt.jpg added |
|---|
comment:6 by , 15 years ago
Tested with Alpha2 hrev36737 which works without any issues and very well in Live-CD mode. System only crashes with this error when using Haiku's trunk build.
I would say that crashing started with Ingo's vm changes which somehow affected my laptop.
comment:7 by , 15 years ago
I looked and saw Ingo's vm changes were all fully merged into Alpha2 before hrev36737 release. So, must be other code committed to trunk causing the crash. Sorry for the mistake.
comment:8 by , 15 years ago
Please hold off on fixing this ticket! I believe my haiku source files have become corrupted somehow (were not updated for 10 months) and I would like to test with nightly from haiku files when they become available again for download.
I will update this ticket when I can test with nightly from haiku files too. I will rebuild haiku from clean and if that does not work then I will check out clean copy of source too. Very sorry about that guys!
by , 14 years ago
| Attachment: | shutdown-error.png added |
|---|
Another picture about r1alpha2 shutdown crash in WMware player.
by , 14 years ago
| Attachment: | shutdown-error2.png added |
|---|
The end of picture about r1alpha2 shutdown crash (AMD Turion X2)
comment:10 by , 14 years ago
This ticket can be closed for now and I may reopen at later date.
Images from haiku-files seem to work without crashing on my laptop. Images I build crash on my laptop ever since the MSI changeset happened.
I will look into how my images differ from those off haiku-files later on when i have more time. Might be awhile before I check into this.
comment:11 by , 13 years ago
| Resolution: | → invalid |
|---|---|
| Status: | assigned → closed |
Closing as it looks like the issue was stale object files. "Official" images didn't experience this issue.
Curios one really. From the output it looks like the gPCI pointer is NULL, but the PCI::FindDevice() call really is already the second use of gPCI in this function. It is already used to call PCI::ResolveVirtualBus(), so it should've crashed there already if not available.