JFAT/IDE multi-sector writes to IDE disk deadlock after first sector(s) (cp, grub stage2 copy hang)

[LSantha]

Summary

Large (multi-sector) writes to a FAT32 partition on an IDE disk hang after the first sector(s): the write path stalls indefinitely, the shell becomes unresponsive, and only small single-sector writes succeed. This blocks cp, the GRUB stage2 install (grub hda0), and the installer CopyFilesAction.

Repro (QEMU)

Host: qemu-system-x86_64 -m 768 -cdrom all/build/cdroms/jnode-x86-lite.iso -drive file=fresh.img,format=raw (fresh.img = 256M, MBR + single FAT32 type-c partition starting at sector 2048, formatted with mkfs.fat).

1. Boot JNode full CD (menu entry 1). Serial log shows Mounted JFAT on /devices/hda0, Mounted ISO9660 on /devices/sg0.
2. cp /devices/sg0/shell.jgz /devices/hda0/shell.jgz (448 KB) → hangs after exactly 1 IDE sector write; a 0-byte shell.jgz entry appears in the FAT, data never flushed. Left >60s, no progress.
3. grub hda0 (alias of org.jnode.fs.jfat.command.JGrubInstallCommand) → stage1 + stage1.5 write OK (verified on the image: MBR 55aa + GRUB code, stage1.5 blocklist =14), then the stage2 copy hangs mid-write at ~197 of 393 sectors; IDE writes slow to ~1.3 s/sector before stalling completely.
4. Small write works: echo hello > /devices/hda0/tiny.txt creates a 6-byte file.

Serial log evidence

Unknown IDE IRQ 15 status 0x50

repeats during the stall (fs/src/driver/org/jnode/driver/bus/ide/IDEBus.java:171). IDE_DATA_XFER_TIMEOUT (10 s) is apparently never hit — the command never finishes, so no timeout exception is raised; the thread is stuck inside bus.executeAndWait.

Suspected regression

The write path was changed in two very recent commits:

• bc852d8f4 — "IDE write-through with configurable property. (IDE write-through with configurable property. #609)": writeThrough defaults to true (fs/src/driver/org/jnode/driver/bus/ide/disk/IDEDiskDriver.java:88, :104-105) and IDEDiskDriver.transfer() now issues a flush() after every write (IDEDiskDriver.java:278-280).
• 7baa16d65 — "feat(ide): defer FLUSH CACHE to filesystem sync": removed the inline flush from IDEWriteSectorsCommand.setup() (fs/src/driver/org/jnode/driver/bus/ide/command/IDEWriteSectorsCommand.java:57-77) and added IDEFlushCacheCommand.

Either the new per-write flush() / FLUSH CACHE path deadlocks (e.g. IRQ loss while the device is busy, mismatched status polling in IDEFlushCacheCommand), or the deferred-flush change leaves the write loop waiting on an IRQ that was already consumed. The stall after N sectors then full stop suggests an IRQ/status race in pollWait or the flush wait.

Suggested next steps

1. Bisect: temporarily set jnode.ide.writethrough=false (IDEDiskDriver.java:104-105) and retest — isolates the per-write FLUSH CACHE path.
2. Check IDEFlushCacheCommand post-command wait / ST_ERROR handling (added in 7baa16d65) against the ATA spec.
3. Reproduce the hang and capture a thread dump / KDB stack to confirm where the stuck thread waits (semaphore vs pollWait).
4. Add a multi-sector write regression test (JFAT write of >1 cluster to an IDE-backed image).

Reference

• fs/src/driver/org/jnode/driver/bus/ide/disk/IDEDiskDriver.java:227-281 (transfer), :88/:104-105 (writeThrough)
• fs/src/driver/org/jnode/driver/bus/ide/command/IDEWriteSectorsCommand.java:57-77 (setup, deferred flush)
• fs/src/driver/org/jnode/driver/bus/ide/IDEBus.java:171 ("Unknown IDE IRQ")
• Commits bc852d8f4, 7baa16d65