Opened 9 months ago

Closed 7 months ago

Last modified 7 months ago

#15094 closed bug (fixed)

KDL when booting anyboot image hrev53173

Reported by: MelanieFox Owned by: korli
Priority: blocker Milestone: R1/beta2
Component: System/Kernel Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86-64


I've tried booting the x86-64 anyboot iso in VirtualBox as usual. Unfortunately i get an "did not find any boot partitions!" KDL.

Screenshot attached.

Attachments (2)

VirtualBox_Haiku_31_05_2019_15_08_01.png (41.3 KB ) - added by MelanieFox 9 months ago.
com1.txt (30.6 KB ) - added by MelanieFox 9 months ago.

Download all attachments as: .zip

Change History (14)

comment:1 by waddlesplash, 9 months ago

Please use VirtualBox's serial port emulation to get a syslog.

by MelanieFox, 9 months ago

Attachment: com1.txt added

in reply to:  1 comment:2 by MelanieFox, 9 months ago

Replying to waddlesplash:

Please use VirtualBox's serial port emulation to get a syslog.


comment:3 by waddlesplash, 9 months ago

There does not appear to be a CD drive in the PCI device list, only a SATA controller with an empty hard drive attached...

How precisely did you connect the anyboot?

comment:4 by MelanieFox, 9 months ago

The VBox CD-Rom drive is attached to the sata controller.

Using an IDE Controller with a CDROM Drive gave the same KDL.

comment:5 by MelanieFox, 9 months ago

Some more testing turned out that the last working hrev is hrev53167. After that every hrev fails to boot.

comment:6 by waddlesplash, 9 months ago

Milestone: UnscheduledR1/beta2
Owner: changed from nobody to korli
Status: newassigned

That would mean korli's SCSI changes are to blame here.

comment:7 by korli, 8 months ago

I can't reproduce with VirtualBox 5.2.18 (both IDE and SATA). Is there anything to check in the settings?

comment:8 by MelanieFox, 8 months ago

I use 6.0.8 for the tests, worked since hrev53167. Oddly i can reproduce the problem on recently enough baremetal.

Currently don't have a clue where the problem could be.

Very strange thing.

comment:9 by simonsouth, 7 months ago

I've added a proposed fix for review here:

The issue turned to be a pair of calls to ioctl() that passed in a buffer but omitted the optional parameter specifying its length, causing a garbage value from va_arg() to be passed to _kern_ioctl() in its place.

With korli's changes in hrev53168 scsi_periph's periph_ioctl() actually does check this length value, meaning these calls would normally fail whenever they were directed at a SCSI device---like a CD-ROM drive. As a result, when Haiku was booted from CD KDiskDeviceManager would find the CD-ROM drive but later drop it from its list, removing it from consideration as a boot device and eventually leading to the kernel panic.

Once booted, the same issue in partitioning_system's Disc.cpp caused the desktop to hang with no Tracker.

For completeness my commit updates all the relevant ioctl calls in the affected modules (file_systems/cdda, partitioning_systems and disk_device_manager).

comment:10 by waddlesplash, 7 months ago

Blocked By: 15075 added

Hey simonsouth, good to see you around again! :)

Very nice find! IMO we should make the kernel ioctl() always take 4 arguments. That would be the systemic solution ... but of course out of scope of this ticket.

Likely that patch will also fix #15075 then, so I'm adding it as a blocking bug.

comment:11 by waddlesplash, 7 months ago

Blocked By: 15075 removed
Blocking: 15075 added
Resolution: fixed
Status: assignedclosed

Merged in hrev53243.

comment:12 by waddlesplash, 7 months ago

Blocking: 15075 removed
Note: See TracTickets for help on using tickets.