Opened 7 weeks ago

Closed 6 days 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: #15075
Has a Patch: no Platform: x86-64

Description

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 7 weeks ago.
com1.txt (30.6 KB) - added by MelanieFox 7 weeks ago.

Download all attachments as: .zip

Change History (13)

Changed 7 weeks ago by MelanieFox

comment:1 Changed 7 weeks ago by waddlesplash

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

Changed 7 weeks ago by MelanieFox

Attachment: com1.txt added

comment:2 in reply to:  1 Changed 7 weeks ago by MelanieFox

Replying to waddlesplash:

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

Done.

comment:3 Changed 7 weeks ago by waddlesplash

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 Changed 7 weeks ago by MelanieFox

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 Changed 6 weeks ago by MelanieFox

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

comment:6 Changed 6 weeks ago by waddlesplash

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

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

comment:7 Changed 4 weeks ago by korli

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

comment:8 Changed 4 weeks ago by MelanieFox

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 Changed 6 days ago by simonsouth

I've added a proposed fix for review here: https://review.haiku-os.org/c/haiku/+/1582

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 Changed 6 days ago by waddlesplash

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 Changed 6 days ago by waddlesplash

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

Merged in hrev53243.

Note: See TracTickets for help on using tickets.