Patchwork [0/3] Attempting to run Microport UNIX (ca 1987)

login
register
mail settings
Submitter Matthew Ogilvie
Date July 29, 2012, 12:26 a.m.
Message ID <20120729002647.GA19206@comcast.net>
Download mbox | patch
Permalink /patch/173899/
State New
Headers show

Comments

Matthew Ogilvie - July 29, 2012, 12:26 a.m.
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(-)
Markus Armbruster - July 30, 2012, 12:29 p.m.
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.

Patch

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: