Hi, I found out that SYS does not need the "get default BPB" call,
it just uses it as optional data source to adjust the BPB of the
already existing boot sector. However, FORMAT does need the default
BPB when formatting a not-yet-formatted disk.

The FORMAT problem with my USB flash memory stick, using USBASPI4
and ASPIDISK drivers, turned out to be a kernel bug (evil grin)...

I got the error code "not same device", and here is why:
COUNT DosDevIOctl(lregs * r)
...
/* the & 0x1f is because NDN_HACK is on ... */
      CharReqHdr.r_unit = ((r->BL & 0x1f) == 0 ? default_drive :
                           (r->BL & 0x1f) - 1);
      dpbp = get_dpb(CharReqHdr.r_unit);
      if (dpbp)
        attr = dpbp->dpb_device->dh_attr;
...

Somebody forgot the CharReqHdr.r_unit = dpbp->dpb_subunit;
in the "if (dpbp)" branch, so the sub unit number is WRONG
for all block devices except kernel-driven ones (where A: is
the first sub unit).

Format of device driver request header:
Offset  Size    Description     (Table 02597)
 00h    BYTE    length of request header
 01h    BYTE    subunit within device driver
...

Note the WITHIN. In rqblockio and dskxfer the sub unit is properly
initalized, only DosDevIoctl gets it wrong. This breaks the functions:
- int 21.69 (get serno)
- int 21.4404 (read block dev ctrl channel)
- int 21.4405 (write block dev ctrl channel)
- int 21.4408 (check if block dev removable)
- int 21.4409 (check if block dev remote)
- int 21.440d (generic block dev ioctl, access to many ioctl functions)
- int 21.440e (get logical drive map - check if dev has several letters)
- int 21.440f (set logical drive map - inc drive letter for drive??)
- int 21.4411 (query genioctl capability for drive)

Suggested fix:
      dpbp = get_dpb(CharReqHdr.r_unit);
      if (dpbp)
+     {
        attr = dpbp->dpb_device->dh_attr;
+       CharReqHdr.r_unit = dpbp->dpb_subunit;
+     }
      else if (r->AL != 9)
        return DE_INVLDDRV;

Note that the "breaks the functions" only affects block devices for
which you have loaded a device driver. KERNEL block devices escape the bug.

I hope I figured this out correctly. Avoiding yet another FORMAT update :-).

Eric




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Freedos-kernel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Reply via email to