[Qemu-devel] [PATCH 0/3] Attempting to run Microport UNIX (ca 1987)

[Qemu-devel] [PATCH 0/3] Attempting to run Microport UNIX (ca 1987)

[Matthew Ogilvie]

I've recently been trying to get an ancient version of UNIX
I used to use working in qemu:

    Micoport UNIX System V/386, v 2.1 (ca 1987).

I used this from about 1987 until about 1996, when I first
got Linux.

With a couple of small patches, I can get qemu to boot and run UNIX
from the first install floppy, although I still have some sporadic
issues accessing the hard drive.

I don't know of any reason the first two patches of this series
shouldn't be applied now.

But the last patch (VGA) is a temporary hack just to make UNIX
usuable, and is currently not appropriate for general use.  The
commit comment discusses some possible strategies for improving
it; does anyone want to weigh in?

I've also noticed some other problems that I have not yet
tracked down:

-------
Hard Drive Issues:
-------

I also encounter a couple of hard drive issues, which I haven't
investigated as carefully, nor attempted to work around:

  1. It doesn't seem to recognize the hard drive geometry, even
     if I use "-hdachs" and keep it carefully inside ancient
     limitations.  Note that at the time, hard drives did not support
     self-identification commands for the geometry; you had to
     configure it in BIOS.   I also have some old notes from when my
     dad was asking Microport about compatibility; apparently
     they wanted to know the specific BIOS version in order to
     decide about compatibility.  Maybe UNIX is bypassing later
     standards for looking up geometry, and trying to get it in
     some non-standard way (straight from CMOS or something?)

  2. Although it can access the hard drive for a short time, when
     accessing the hard disk, the kernel will sporadially panic
     with a message about a logic error in a splint() method,
     which dissasembly shows is called from interrupt
     handlers.  (See also
     http://www.linuxmisc.com/29-unix-internals/4e6c1f6fa2e41670.htm
     for some general background information I found about UNIX
     kernel spl*() functions.)

I haven't spent much time investigating either of these yet, but
in my limited investigation so far, it hasn't yet run long enough
to complete the first phase of installation to the hard drive (when
it is running from floppy).

-------
KVM Issue:
-------

Finally, if KVM is enabled, I get different results.  It (somehow)
seems to make it past the control register instructions even with or
without my patch 2, but the UNIX kernel very quickly panics with
a logic error in an splx() method [apparently for restoring
interrupt controller bitmasks; see link above], before it runs
any userspace code.

I haven't investigated this, either.

-------

If anyone is interested in examining this system for themselves,
contact me and I can send you at least the first (bootable)
installation floppy image.

--

Matthew Ogilvie (3):
  fix debug printf 64bit format strings
  target-i386/translate.c: mov to/from crN/drN: ignore mod bits
  HACKS to make vga text mode work with old Microport UNIX (ca 1987)

 hw/cirrus_vga.c         |  4 ++--
 hw/ide/cmd646.c         |  5 +++--
 hw/ide/via.c            |  5 +++--
 hw/vga.c                |  5 +++--
 target-i386/translate.c | 16 ++++++++++++----
 5 files changed, 23 insertions(+), 12 deletions(-)

-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH 1/3] fix some debug printf 64bit format strings

[Matthew Ogilvie]

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---
 hw/cirrus_vga.c | 4 ++--
 hw/ide/cmd646.c | 5 +++--
 hw/ide/via.c    | 5 +++--
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 623dd68..24ddea6 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2055,8 +2055,8 @@ static void cirrus_vga_mem_write(void *opaque,
 	}
     } else {
 #ifdef DEBUG_CIRRUS
-        printf("cirrus: mem_writeb " TARGET_FMT_plx " value %02x\n", addr,
-               mem_value);
+        printf("cirrus: mem_writeb " TARGET_FMT_plx " value %" PRIx64 "\n",
+               addr, mem_value);
 #endif
     }
 }
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index bf8ece4..5ae9e25 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -154,7 +154,7 @@ static uint64_t bmdma_read(void *opaque, target_phys_addr_t addr,
         break;
     }
 #ifdef DEBUG_IDE
-    printf("bmdma: readb 0x%02x : 0x%02x\n", addr, val);
+    printf("bmdma: readb 0x%02" TARGET_PRIxPHYS " : 0x%02x\n", addr, val);
 #endif
     return val;
 }
@@ -170,7 +170,8 @@ static void bmdma_write(void *opaque, target_phys_addr_t addr,
     }
 
 #ifdef DEBUG_IDE
-    printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
+    printf("bmdma: writeb 0x%02" TARGET_PRIxPHYS " : 0x%02" PRIx64 "\n",
+           addr, val);
 #endif
     switch(addr & 3) {
     case 0:
diff --git a/hw/ide/via.c b/hw/ide/via.c
index eec5136..96c6273 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -55,7 +55,7 @@ static uint64_t bmdma_read(void *opaque, target_phys_addr_t addr,
         break;
     }
 #ifdef DEBUG_IDE
-    printf("bmdma: readb 0x%02x : 0x%02x\n", addr, val);
+    printf("bmdma: readb 0x%02" TARGET_PRIxPHYS " : 0x%02x\n", addr, val);
 #endif
     return val;
 }
@@ -70,7 +70,8 @@ static void bmdma_write(void *opaque, target_phys_addr_t addr,
     }
 
 #ifdef DEBUG_IDE
-    printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
+    printf("bmdma: writeb 0x%02" TARGET_PRIxPHYS " : 0x%02" PRIx64 "\n",
+           addr, val);
 #endif
     switch (addr & 3) {
     case 0:
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH 2/3] target-i386/translate.c: mov to/from crN/drN: ignore mod bits

[Matthew Ogilvie]

Microport UNIX System V/386 v 2.1 (ca 1987) uses mod R/M bytes for
the control register mov instructions where the mod bits are 0,
even though the 80386 spec claims they are "always" 1's.  The fact
that it ran at all clearly indicates the real chips (at least 386
and 486) just ignores the bits and assumes they are 1's, rather
than trigger an illegal instruction if they aren't.

Also fixed: The dissassembled kernel also accesses debug
registers in a similar way, although other problems prevent
me verifiing that those instructions are reachable in UNIX.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

Alternatives?:

Potentially someone might want to make this dependent on some kind
of configuration option (what specific CPU it is emulating, or some
kind of quirks flag).

Or somehow log if it encounters unspecified instructions
like this, as a kind of warning mechanism for someone debugging
an OS.  (Although I'm not sure exactly what the qemu way to
log such a thing would be.)

But my initial thought is that neither of these are worth the effort.

------
Matthew Ogilvie   [mmogilvi_qemu@miniinfo.net]
------

 target-i386/translate.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/target-i386/translate.c b/target-i386/translate.c
index 1988dae..d056842 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -7465,8 +7465,12 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
             gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
         } else {
             modrm = ldub_code(s->pc++);
-            if ((modrm & 0xc0) != 0xc0)
-                goto illegal_op;
+            /* Ignore the mod bits (assume (modrm&0xc0)==0xc0).
+             * The 80386 reference manual says the bits are
+             * always 1, and doesn't say what happens if they aren't.
+             * But testing shows that the bits are just assumed to be
+             * 1s.
+             */
             rm = (modrm & 7) | REX_B(s);
             reg = ((modrm >> 3) & 7) | rex_r;
             if (CODE64(s))
@@ -7507,8 +7511,12 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
             gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
         } else {
             modrm = ldub_code(s->pc++);
-            if ((modrm & 0xc0) != 0xc0)
-                goto illegal_op;
+            /* Ignore the mod bits (assume (modrm&0xc0)==0xc0).
+             * The 80386 reference manual says the bits are
+             * always 1, and doesn't say what happens if they aren't.
+             * But testing shows that the bits are just assumed to be
+             * 1s.
+             */
             rm = (modrm & 7) | REX_B(s);
             reg = ((modrm >> 3) & 7) | rex_r;
             if (CODE64(s))
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH 3/3] HACKS for vga text mode with Microport UNIX (ca 1987)

[Matthew Ogilvie]

========
Background:
========

I don't really think it is appropriate to include this patch in it's
current form, but I'm posting it to illustrate some of the obscure
things that Microport UNIX System V/386 v 2.1 (ca 1987) is trying
to do to the video card.

On real hardware, this version of UNIX could drive an MDA graphics
card (actually an HGC [hurcules graphics card] in text mode only)
just fine.  BUT, the VGA card and monitor would always
display snow (timings were out of sync, and/or other problems).
In 1987, I initially had an HGC-only system, and added a VGA
to it later as a second graphics card and monitor.  DOS could switch
between them (the "mode" command), but UNIX was only usable on the HGC.

The fact that it couldn't run a real VGA properly suggests that
hacking the emulated VGA isn't really the best solution.  A better
approach might be to add specific support for graphics cards
(MDA, HGC, and/or maybe plain-CGA) that UNIX works properly on.

If anyone is interested in examining this UNIX system
directly (for these VGA issues or other issues), let me know and
I can email you at least the first (bootable) installation
floppy image.

========
Visible Problems in Qemu:
========

Running and debugging UNIX in qemu, I see two main VGA-related
problems, and a few associated nits (not counting non-VGA issues
written up separately):

1. (Blank screen): UNIX weirdly writes exactly
   one byte to 0x3c0 (VGA_ATT_W).  After reading
   from 0x3da (which resets 0x3c0 to index mode),
   it writes a 0 to 0x3c0, and then doesn't touch the register again.
   It doesn't actually modify the contents of the data behind any index.
   Writing zero also clears the 0x20 "palette access bit", which forces
   qemu vga_update_display() to treat the screen as "GMODE_BLANK".
    - My hackish workaround will not blank the screen if the index
      register is still 0.  Perhaps this hack could be (slightly)
      improved to look at the index/data flip-flop as well, under
      the theory that until the OS actually starts modifying things,
      it is OK for the card to keep using the old palette?

2. (Characters cut in half): UNIX appears to be trying
   to program the CRTC under the assumption that the text
   mode is using a font that is only 8 pixels high, instead
   of 16.  I would guess it is trying to treat it like a CGA card.
    - (main problem): It changes CRTC register 9 (0x3d4[9]/0x3d5)
      from 0x4f to 0x07.  The 0xf vs 7 halves the height of
      the character, cutting off the bottom halves.  The 0x40
      bit doesn't seem to hurt, but documentation explains how
      it has something to do with split screen scrolling.
    - My hackish workaround is to ignore attempts to modify
      register 9 if the lock bit in register 0x11 is locked.
    - UNIX is also changing the cursor-height-within-a-character
      values from (0xe through 0xf) to (6 through 7), effectively
      moving the cursor to the middle of the character.
      (I haven't tried to work around this, but it would be
      trivial to disable these registers under some conditions TBD.
      Or perhaps translate the supplied values with scaling logic.)
    - UNIX changes register 8 (0x3d4[8]/0x3d5) from 0 to 2, but
      this doesn't seem to hurt.  (Documentation says it has to
      do with smooth text mode scrolling, but UNIX only sets it
      once...)
    - UNIX also attempts to change registers 0-7 (0x3d4[0-7]/0x3d5), but
      these attempts are ignored by qemu because of the lock bit
      in register 0x11 (0x3d4[0x11]/0x3d5).  (UNIX doesn't seem to
      know anything about registers greater than 0xf.)

3. I haven't looked to see if it programming other VGA subsystems
   strangely, but it wouldn't surprise me.

========
Possible "Real" Solutions:
========

1. The ideal solution would probably be to implement an emulated plain MDA
   adapter, and a way to select it on the command line.  (It could also be
   extended to optionally be HGC-capable and/or to support a
   dual monitor with a CGA/VGA [with two windows for the two
   monitors], as well.)
      Superficially, emulating an MDA or HGC card itself probably
   wouldn't be too hard (mostly just copy, strip down [simplify], and
   tweak the VGA support), but I'm still a little vague on the best
   way to get it all hooked into the overall system cleanly,
   and appropriate configurations options (perhaps options
   like "-vga mda", "-vga mda+std", "-vgs cirrus+hgc", etc?).
      This seems like a moderate amount of work, but it has the highest
   likelyhood of being useful for running other ancient software,
   rather than a hackish workaround for one rare OS.

2. Perhaps add some special command line option to enable hacks similar
   to what I do in this patch (normally disabled).  This is probably
   the easiest.  Any suggestions for command-line options, etc?

3. I wonder if maybe an alternative approach to these problems would be
   to somehow identify that the target is trying to use the VGA like
   a CGA, and have the fixups/hacks move it towards CGA functionality
   instead of leaving things in VGA mode and disabling the bad
   parts?  (e.g. use a 8 pixel high font, etc)
    - Identify if this is the case, and make a narrow exception
      for better CGA support?
    - Perhaps add a command line option to have the graphics card be
      limited to just CGA functionality?

(Intentionally not signed off; this version of this patch isn't appropriate
for general use.)
---
 hw/vga.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/vga.c b/hw/vga.c
index f82ced8..c57d8e2 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -548,7 +548,8 @@ void vga_ioport_write(void *opaque, uint32_t addr, uint32_t val)
 #endif
         /* handle CR0-7 protection */
         if ((s->cr[VGA_CRTC_V_SYNC_END] & VGA_CR11_LOCK_CR0_CR7) &&
-            s->cr_index <= VGA_CRTC_OVERFLOW) {
+            (s->cr_index <= VGA_CRTC_OVERFLOW ||
+             s->cr_index == VGA_CRTC_MAX_SCAN)) {
             /* can always write bit 4 of CR7 */
             if (s->cr_index == VGA_CRTC_OVERFLOW) {
                 s->cr[VGA_CRTC_OVERFLOW] = (s->cr[VGA_CRTC_OVERFLOW] & ~0x10) |
@@ -1886,7 +1887,7 @@ static void vga_update_display(void *opaque)
         /* nothing to do */
     } else {
         full_update = 0;
-        if (!(s->ar_index & 0x20)) {
+        if (!(s->ar_index & 0x20) && s->ar_index != 0) {
             graphic_mode = GMODE_BLANK;
         } else {
             graphic_mode = s->gr[VGA_GFX_MISC] & VGA_GR06_GRAPHICS_MODE;
-- 
1.7.10.2.484.gcd07cc5

Re: [Qemu-devel] [PATCH 2/3] target-i386/translate.c: mov to/from crN/drN: ignore mod bits

[malc]

On Fri, 27 Jul 2012, Matthew Ogilvie wrote:

> Microport UNIX System V/386 v 2.1 (ca 1987) uses mod R/M bytes for
> the control register mov instructions where the mod bits are 0,
> even though the 80386 spec claims they are "always" 1's.  The fact
> that it ran at all clearly indicates the real chips (at least 386
> and 486) just ignores the bits and assumes they are 1's, rather
> than trigger an illegal instruction if they aren't.
> 

AMD's document is explicit about it:

This instruction is always treated as a register-to-register (MOD = 11)
instruction, regardless of the encoding of the MOD field in the MODR/M
byte.

24594.pdf page 316

So i belive this patch should just be applied, thanks.

[..snip..]

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH 0/3] Attempting to run Microport UNIX (ca 1987)

[Markus Armbruster]

Matthew Ogilvie <mmogilvi_qemu@miniinfo.net> writes:

> I've recently been trying to get an ancient version of UNIX
> I used to use working in qemu:
>
>     Micoport UNIX System V/386, v 2.1 (ca 1987).
>
> I used this from about 1987 until about 1996, when I first
> got Linux.
[...]
> I've also noticed some other problems that I have not yet
> tracked down:
>
> -------
> Hard Drive Issues:
> -------
>
> I also encounter a couple of hard drive issues, which I haven't
> investigated as carefully, nor attempted to work around:
>
>   1. It doesn't seem to recognize the hard drive geometry, even
>      if I use "-hdachs" and keep it carefully inside ancient
>      limitations.  Note that at the time, hard drives did not support
>      self-identification commands for the geometry; you had to
>      configure it in BIOS.   I also have some old notes from when my
>      dad was asking Microport about compatibility; apparently
>      they wanted to know the specific BIOS version in order to
>      decide about compatibility.  Maybe UNIX is bypassing later
>      standards for looking up geometry, and trying to get it in
>      some non-standard way (straight from CMOS or something?)

Please run QEMU with -trace events=trace-events, where trace-events is a
file containing the line "hd_geometry_*".  Post results, along with your
full command line.

[...]

Re: [Qemu-devel] [PATCH 0/3] Attempting to run Microport UNIX (ca 1987)

[Matthew Ogilvie]

On Sat, Jul 28, 2012 at 08:33:54AM +0200, Markus Armbruster wrote:
> Matthew Ogilvie <mmogilvi_qemu@miniinfo.net> writes:
[...]
> >   1. It doesn't seem to recognize the hard drive geometry, even
> >      if I use "-hdachs" and keep it carefully inside ancient
> >      limitations.  Note that at the time, hard drives did not support
> >      self-identification commands for the geometry; you had to
> >      configure it in BIOS.   I also have some old notes from when my
> >      dad was asking Microport about compatibility; apparently
> >      they wanted to know the specific BIOS version in order to
> >      decide about compatibility.  Maybe UNIX is bypassing later
> >      standards for looking up geometry, and trying to get it in
> >      some non-standard way (straight from CMOS or something?)
> 
> Please run QEMU with -trace events=trace-events, where trace-events is a
> file containing the line "hd_geometry_*".  Post results, along with your
> full command line.
> 
> [...]

Thanks for the suggestion.  I've narrowed down a couple of problems
based on it:

First, the -hdachs command line option is silently ignored depending
on its relative order compared to other command line options.  I've
attached a patch below.

----

Second, this UNIX kernel and/or bootloader always seems to think
it has 17 sectors per track, no matter what I tell qemu (using a blank
image; no partition table).  But UNIX does recognize the number
of cylinders and heads correctly, and I've verified that
the number of sectors per track is also correct in the fixed disk
parameter table, by using the monitor's "x" (examine) command. 

Potentially guess_chs_for_size() could be enhanced to return 17
for small drive images when appropriate, to be consistent with most
legacy drives having 17.  Or maybe there is some more
obscure way to get UNIX to recognize non-17 sectors.
Or either document a third party way to put a basic partition table
on a new image, or add that ability to qemu-img, so that code
like that in guess_disk_lchs() or similar code that might exist
in some operating systems would have something to work with.
I also found a 1988 posting that suggests some leads for
further investigation:
http://www.megalextoria.com/usenet-archive/news076f1/b96/comp/unix/microport/00000798.html

But I'm not really inclined to worry much more about this
right now, because I have a usable workaround: Always define
my disk image size to be consistent with 17 sectors per
track, and tell qemu to use 17.

----

(Now if I can just figure out what's up with the sporadic panic
in UNIX's interrupt handlers...)

----

From: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
Date: Sat, 28 Jul 2012 17:01:14 -0600
Subject: [PATCH] vl.c: fix -hdachs/-hda argument order parsing issues

Without this patch, the -hdachs argument had to occur either
BEFORE the corresponding "-hda" option, or AFTER the plain
disk image name (if neither -hda nor -drive is used).  Otherwise
it would effectively be ignored.

Option -hdachs still has no effect on -drive, but that seems
reasonable.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---
 vl.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index c18bb80..e0611eb 100644
--- a/vl.c
+++ b/vl.c
@@ -2374,7 +2374,18 @@ int main(int argc, char **argv, char **envp)
         if (optind >= argc)
             break;
         if (argv[optind][0] != '-') {
-	    hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], HD_OPTS);
+            char buf[256];
+            if (cyls == 0)
+                snprintf(buf, sizeof(buf), "%s", HD_OPTS);
+            else
+                snprintf(buf, sizeof(buf),
+                         "%s,cyls=%d,heads=%d,secs=%d%s",
+                         HD_OPTS , cyls, heads, secs,
+                         translation == BIOS_ATA_TRANSLATION_LBA ?
+                         ",trans=lba" :
+                         translation == BIOS_ATA_TRANSLATION_NONE ?
+                         ",trans=none" : "");
+            hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], buf);
         } else {
             const QEMUOption *popt;
 
@@ -2404,7 +2415,7 @@ int main(int argc, char **argv, char **envp)
                                  ",trans=lba" :
                                  translation == BIOS_ATA_TRANSLATION_NONE ?
                                  ",trans=none" : "");
-                    drive_add(IF_DEFAULT, 0, optarg, buf);
+                    hda_opts = drive_add(IF_DEFAULT, 0, optarg, buf);
                     break;
                 }
             case QEMU_OPTION_hdb:
-- 
1.7.10.2.484.gcd07cc5

Re: [Qemu-devel] [PATCH 0/3] Attempting to run Microport UNIX (ca 1987)

[Markus Armbruster]

Matthew Ogilvie <mmogilvi_qemu@miniinfo.net> writes:

> On Sat, Jul 28, 2012 at 08:33:54AM +0200, Markus Armbruster wrote:
>> Matthew Ogilvie <mmogilvi_qemu@miniinfo.net> writes:
> [...]
>> >   1. It doesn't seem to recognize the hard drive geometry, even
>> >      if I use "-hdachs" and keep it carefully inside ancient
>> >      limitations.  Note that at the time, hard drives did not support
>> >      self-identification commands for the geometry; you had to
>> >      configure it in BIOS.   I also have some old notes from when my
>> >      dad was asking Microport about compatibility; apparently
>> >      they wanted to know the specific BIOS version in order to
>> >      decide about compatibility.  Maybe UNIX is bypassing later
>> >      standards for looking up geometry, and trying to get it in
>> >      some non-standard way (straight from CMOS or something?)
>> 
>> Please run QEMU with -trace events=trace-events, where trace-events is a
>> file containing the line "hd_geometry_*".  Post results, along with your
>> full command line.
>> 
>> [...]
>
> Thanks for the suggestion.  I've narrowed down a couple of problems
> based on it:
>
> First, the -hdachs command line option is silently ignored depending
> on its relative order compared to other command line options.  I've
> attached a patch below.

Recommend to post patches with Subject: [PATCH] ..., so that maintainers
spot them.

> ----
>
> Second, this UNIX kernel and/or bootloader always seems to think
> it has 17 sectors per track, no matter what I tell qemu (using a blank
> image; no partition table).  But UNIX does recognize the number
> of cylinders and heads correctly, and I've verified that
> the number of sectors per track is also correct in the fixed disk
> parameter table, by using the monitor's "x" (examine) command. 
>
> Potentially guess_chs_for_size() could be enhanced to return 17
> for small drive images when appropriate, to be consistent with most
> legacy drives having 17.  Or maybe there is some more
> obscure way to get UNIX to recognize non-17 sectors.
> Or either document a third party way to put a basic partition table
> on a new image, or add that ability to qemu-img, so that code
> like that in guess_disk_lchs() or similar code that might exist
> in some operating systems would have something to work with.
> I also found a 1988 posting that suggests some leads for
> further investigation:
> http://www.megalextoria.com/usenet-archive/news076f1/b96/comp/unix/microport/00000798.html
>
> But I'm not really inclined to worry much more about this
> right now, because I have a usable workaround: Always define
> my disk image size to be consistent with 17 sectors per
> track, and tell qemu to use 17.

Yes, that's best.

> ----
>
> (Now if I can just figure out what's up with the sporadic panic
> in UNIX's interrupt handlers...)
>
> ----
>
> From: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
> Date: Sat, 28 Jul 2012 17:01:14 -0600
> Subject: [PATCH] vl.c: fix -hdachs/-hda argument order parsing issues
>
> Without this patch, the -hdachs argument had to occur either
> BEFORE the corresponding "-hda" option, or AFTER the plain
> disk image name (if neither -hda nor -drive is used).  Otherwise
> it would effectively be ignored.
>
> Option -hdachs still has no effect on -drive, but that seems
> reasonable.

Pretty sure it's intentional.

> Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
> ---
>  vl.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index c18bb80..e0611eb 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2374,7 +2374,18 @@ int main(int argc, char **argv, char **envp)
>          if (optind >= argc)
>              break;
>          if (argv[optind][0] != '-') {
> -	    hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], HD_OPTS);
> +            char buf[256];
> +            if (cyls == 0)
> +                snprintf(buf, sizeof(buf), "%s", HD_OPTS);
> +            else
> +                snprintf(buf, sizeof(buf),
> +                         "%s,cyls=%d,heads=%d,secs=%d%s",
> +                         HD_OPTS , cyls, heads, secs,
> +                         translation == BIOS_ATA_TRANSLATION_LBA ?
> +                         ",trans=lba" :
> +                         translation == BIOS_ATA_TRANSLATION_NONE ?
> +                         ",trans=none" : "");
> +            hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], buf);
>          } else {
>              const QEMUOption *popt;
>  

I suspect this was broken in commit e4bcb14c, Dec 2007.  Makes me doubt
-hdachs is used much.

Duplicates the code under case QEMU_OPTION_hda.  Should be factored out.

> @@ -2404,7 +2415,7 @@ int main(int argc, char **argv, char **envp)
>                                   ",trans=lba" :
>                                   translation == BIOS_ATA_TRANSLATION_NONE ?
>                                   ",trans=none" : "");
> -                    drive_add(IF_DEFAULT, 0, optarg, buf);
> +                    hda_opts = drive_add(IF_DEFAULT, 0, optarg, buf);
>                      break;
>                  }
>              case QEMU_OPTION_hdb:

This part fixes up commit 5645b0f4.