[GH-ISSUE #50] drvPCFloppy: rebuilt driver fails to reserve IRQ 6, FloppyController never configures #45

New issue

Closed

opened 2026-11-03 22:03:09 -07:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-11-03 22:03:09 -07:00

Owner

Originally created by @raynorpat on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/50

The in-tree src/drivers-i386/ide/drvPCFloppy driver builds, but at boot its controller fails to configure:

ISASerialPort0: Base=0x03f8, IRQ=4, Type=16550AF/C/CF, FIFO=16
IRQ Levels: Couldn't reserve 6
configureDriver: could not allocate resources for class FloppyController
Registering: PS2Controller

Apple's 1998 binary (PROGRAM:Floppy PROJECT:drvPCFloppy-5, built Sat Mar 28 1998), which ships on rhap-i386-bootstrapped-v2.img, registers the controller (Registering: fc0) at the same point in the same boot.

The kernel is not the cause. The failing boot used master's kernel (pre-clamp 952b547de) with v2's own boot2 and sarld; the only change was swapping in the rebuilt Floppy.config (Floppy_reloc and Default.table). v2's Instance0.table was kept, apart from one added "Kernel ABI" key that this kernel does not read. The same failure also appears with the flat kernel from branch i386-flat.

Where it fails. The message comes from -[KernDeviceDescription _parseItemResourceByKey:value:] (src/kernel-7/driverkit/KernDeviceDescription.m:631), when reserveItem: for IRQ 6 returns nil. Something holds IRQ 6 before the controller's table resources are reserved, and that happens only with the rebuilt driver loaded.

One difference worth checking. The rebuilt Default.table has a key with no value, "Boot Driver";, where Apple's table has "Boot Driver" = "Boot Driver";. The boot used v2's Instance0.table, though, so this may be unrelated.

To reproduce:

QEMU -M pc -cpu pentium -m 768, on a throwaway copy of vm/work/rhap-i386-bootstrapped-v2.img (-snapshot), with Kernel Flags -v -s.
Build the driver with rbuild buildpackage --toolchain gcc-darwin-i386.conf --arch i386, and replace /private/Drivers/i386/Floppy.config/Floppy_reloc and Default.table on the copy with the rebuilt ones.
Read the COM2 serial log.

Found 2026-10-14 while boot-testing the i386 flat kernel. It also blocks that plan's ISA DMA check, which reads from the floppy.

Originally created by @raynorpat on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/50 The in-tree `src/drivers-i386/ide/drvPCFloppy` driver builds, but at boot its controller fails to configure: ``` ISASerialPort0: Base=0x03f8, IRQ=4, Type=16550AF/C/CF, FIFO=16 IRQ Levels: Couldn't reserve 6 configureDriver: could not allocate resources for class FloppyController Registering: PS2Controller ``` Apple's 1998 binary (`PROGRAM:Floppy PROJECT:drvPCFloppy-5`, built Sat Mar 28 1998), which ships on `rhap-i386-bootstrapped-v2.img`, registers the controller (`Registering: fc0`) at the same point in the same boot. **The kernel is not the cause.** The failing boot used master's kernel (pre-clamp `952b547de`) with v2's own boot2 and sarld; the only change was swapping in the rebuilt `Floppy.config` (`Floppy_reloc` and `Default.table`). v2's `Instance0.table` was kept, apart from one added `"Kernel ABI"` key that this kernel does not read. The same failure also appears with the flat kernel from branch `i386-flat`. **Where it fails.** The message comes from `-[KernDeviceDescription _parseItemResourceByKey:value:]` (`src/kernel-7/driverkit/KernDeviceDescription.m:631`), when `reserveItem:` for IRQ 6 returns nil. Something holds IRQ 6 before the controller's table resources are reserved, and that happens only with the rebuilt driver loaded. **One difference worth checking.** The rebuilt `Default.table` has a key with no value, `"Boot Driver";`, where Apple's table has `"Boot Driver" = "Boot Driver";`. The boot used v2's `Instance0.table`, though, so this may be unrelated. **To reproduce:** - QEMU `-M pc -cpu pentium -m 768`, on a throwaway copy of `vm/work/rhap-i386-bootstrapped-v2.img` (`-snapshot`), with Kernel Flags `-v -s`. - Build the driver with `rbuild buildpackage --toolchain gcc-darwin-i386.conf --arch i386`, and replace `/private/Drivers/i386/Floppy.config/Floppy_reloc` and `Default.table` on the copy with the rebuilt ones. - Read the COM2 serial log. Found 2026-10-14 while boot-testing the i386 flat kernel. It also blocks that plan's ISA DMA check, which reads from the floppy.

gitea-mirror closed this issue

2026-11-03 22:03:10 -07:00

gitea-mirror commented

2026-11-03 22:03:10 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 14, 2026):

Fixed. The IRQ 6 failure was the first of several bugs, found by booting the rebuilt driver for the first time and comparing it with Apple's 1998 binary on the same guest.

Cause of this issue: +[IODiskPartitionNEW deviceStyle] returned IO_DirectDevice (0). Apple's returns 1 (IO_IndirectDevice). IODiskPartitionNEW comes before FloppyController in Class Names, so configureDriver reserved the table's DMA, IRQ and ports for it first. The "Boot Driver"; key was unrelated: Apple's table has the same line.

Further defects fixed, in the order the guest hit them:

FloppyController ivar layout was off by 4 from 0x12c, and the six _dataRateChangeCount++ lines were outb()'s own lock incl, not driver code.
sendCmd: reported every result-less command as failed (so the controller never initialised); RECALIBRATE/SEEK read the wrong result bytes.
getDriveStatus: read write-protect from the wrong field, so every disk looked write-protected.
attachBsdDiskInterfaceToDrive: and fdRwCommon: sent selectors no class implements (kernel panic on first access).
constructRequest: treated the write flag as a pointer: writes ran as reads and stored to address 1.
_probeLabel: truncated the label pointer to a BOOL, so /dev/rfd0a (newfs/fsck) was unusable.
fdrToIo, the read/write entry points and updatePhysicalParametersInt returned the wrong codes.
IOFloppyDrive shadowed IODriveNEW's _diskId, so no disk inserted after an eject was ever probed.

Verified on a QEMU -M pc guest of rhap-i386-bootstrapped-v2.img, against Apple's driver:

boot-time FDC register trace identical; cold-start read traffic identical;
raw reads/writes at several sizes, disk -i, newfs, mount, copy, fsck, read-back after remount;
write-behind data reaches the medium (all 80 cylinders, byte for byte);
media change after disk -e, and write-protected media refused with Permission denied.

Not tested: fdform, a second drive, 720 KB / 2.88 MB media, real hardware.

Commits (on local master, not yet pushed): 88a9ee7e6, 36de697b4, 9582d6591, 6dc322263. The last one adds a section on this test to reconstruction/divergences.md.

@raynorpat commented on GitHub (Oct 14, 2026): Fixed. The IRQ 6 failure was the first of several bugs, found by booting the rebuilt driver for the first time and comparing it with Apple's 1998 binary on the same guest. **Cause of this issue:** `+[IODiskPartitionNEW deviceStyle]` returned `IO_DirectDevice` (0). Apple's returns 1 (`IO_IndirectDevice`). `IODiskPartitionNEW` comes before `FloppyController` in `Class Names`, so `configureDriver` reserved the table's DMA, IRQ and ports for it first. The `"Boot Driver";` key was unrelated: Apple's table has the same line. **Further defects fixed, in the order the guest hit them:** - `FloppyController` ivar layout was off by 4 from 0x12c, and the six `_dataRateChangeCount++` lines were `outb()`'s own `lock incl`, not driver code. - `sendCmd:` reported every result-less command as failed (so the controller never initialised); RECALIBRATE/SEEK read the wrong result bytes. - `getDriveStatus:` read write-protect from the wrong field, so every disk looked write-protected. - `attachBsdDiskInterfaceToDrive:` and `fdRwCommon:` sent selectors no class implements (kernel panic on first access). - `constructRequest:` treated the write flag as a pointer: writes ran as reads and stored to address 1. - `_probeLabel:` truncated the label pointer to a `BOOL`, so `/dev/rfd0a` (newfs/fsck) was unusable. - `fdrToIo`, the read/write entry points and `updatePhysicalParametersInt` returned the wrong codes. - `IOFloppyDrive` shadowed `IODriveNEW`'s `_diskId`, so no disk inserted after an eject was ever probed. **Verified on a QEMU `-M pc` guest of `rhap-i386-bootstrapped-v2.img`, against Apple's driver:** - boot-time FDC register trace identical; cold-start read traffic identical; - raw reads/writes at several sizes, `disk -i`, `newfs`, `mount`, copy, `fsck`, read-back after remount; - write-behind data reaches the medium (all 80 cylinders, byte for byte); - media change after `disk -e`, and write-protected media refused with `Permission denied`. Not tested: `fdform`, a second drive, 720 KB / 2.88 MB media, real hardware. Commits (on local master, not yet pushed): `88a9ee7e6`, `36de697b4`, `9582d6591`, `6dc322263`. The last one adds a section on this test to `reconstruction/divergences.md`.

gitea-mirror referenced this issue

2026-11-03 22:03:11 -07:00

[GH-ISSUE #55] msdosfs: mmap'd files lose their size on truncate and rewrite; no SIGBUS past EOF #46

gitea-mirror referenced this issue

2026-11-03 22:03:11 -07:00

[GH-ISSUE #54] msdosfs: concurrent rename deadlocks on denode locks; the hang spreads to the root fs #47

gitea-mirror referenced this issue

2026-11-03 22:03:11 -07:00

[GH-ISSUE #53] hfs: concurrent rename/mkdir/rmdir deadlocks two processes on hfsnode vnode locks, then hangs the system #48