Opened 5 years ago

Closed 3 years ago

#15865 closed bug (invalid)

Kernel panic during boot from usb drive

Reported by: illiakailli Owned by: waddlesplash
Priority: normal Milestone: Unscheduled
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by diver)

First time running haiku. Boot sequence interrupts with the following message:
PANIC: get_boot_partitions failed!

Stack trace screens attached.
Safe mode doesn't help. No luck with generic video drivers or single-core mode.

Error message changes when trying out latest nightly hrev54033:
PANIC: page fault, but interrupts were disabled.

Tried and reproduced this issue on the following versions:

  • 32bit R1/beta1
  • 64bit R1/beta1
  • 64bit nightly hrev54033

Processor: Intel© Core™2 Quad CPU Q8300 @ 2.50GHz × 4 RAM: 5.8 GiB
Mobo: Gateway model: EG43M

nightly rev 54033  screen

Attachments (2)

20200412_183304.jpg (4.4 MB ) - added by illiakailli 5 years ago.
R1/beta trace screen
20200412_190000.jpg (4.4 MB ) - added by illiakailli 5 years ago.
nightly rev 54033 screen

Change History (9)

by illiakailli, 5 years ago

Attachment: 20200412_183304.jpg added

R1/beta trace screen

by illiakailli, 5 years ago

Attachment: 20200412_190000.jpg added

nightly rev 54033 screen

comment:1 by illiakailli, 5 years ago

Description: modified (diff)

comment:2 by X512, 5 years ago

What is version of USB port and USB drive (USB 2 or USB 3)?

Crash in object_cache_alloc can be caused by memory corruption in kernel space.

comment:3 by diver, 5 years ago

Description: modified (diff)
Platform: x86-64All
Version: R1/beta1R1/Development

There were a lot of fixes since beta1 so current nightly just boots further on yoгr hardware. Try booting from USB2 instead of USB3 or vice versa.

comment:4 by waddlesplash, 5 years ago

Owner: changed from nobody to waddlesplash
Status: newassigned

Crash in object_cache_alloc can be caused by memory corruption in kernel space.

No, look at the fault address: it's a NULL dereference. It looks like this is trying to do an object_cache_alloc before the object cache has been created. And indeed, this is occurring inside arch_int_init_io, which I guess occurs before vfs_init.

I'm not sure how get_module is supposed to work before vfs_init? Or maybe I'm getting things backwards here. I'll try to investigate this later.

comment:5 by waddlesplash, 5 years ago

hrev54077 adds an assert panic here, so please retest under that revision.

comment:6 by waddlesplash, 3 years ago

Component: - GeneralSystem/Kernel

Did you have a chance to retest this?

comment:7 by waddlesplash, 3 years ago

Resolution: invalid
Status: assignedclosed

No reply.

Note: See TracTickets for help on using tickets.