Re: Troubles getting MOL running on 9500


Subject: Re: Troubles getting MOL running on 9500
From: Tovar (tvr@usermail.com)
Date: Sat Apr 28 2001 - 15:22:28 MDT


    On Wed, Apr 25, 2001 at 07:46:54AM -0700, Tovar wrote:
> This is compiled from the mol-0.9.57 source (with minor
> 'Makefile'-type changes previous described).

    I strongly recommend running the 0.9.58 version instead (just
    uploaded to the web site). The 0.9.57 version contained a bug that
    might severely affect stability. On most 604-machines, MOL would
    not event boot.

Indeed, that produced a big improvement.

> (1) 'mol' fails to start up at all. It does so by getting into a loop
> printing 'Unimplemented load instruction'.

    This error usually occurs when MacOS has crashed (thus, the error
    message is slightly misleading).

This still happens, but once it does come up, it's much more stable.
Having problems with 'molrc' seem to produce these crashs, as do
mismatches between the 'ofonly' video mode, what the MacOS expects,
and/or what MOL is setup for. I'm sorry about the vagueness of this,
it happens in an apparently random way, and it's not clear where the
causalities are. Today, it seems much better under X than with a
virtual terminal.

One of the very annoying aspects of this failure and that MOL would
get into a seemingly infinite loop writing to the console. In an X
window, that made it almost unkillable, without closing either the
terminal or the MOL window (sometimes both). Stopping that behavior
really helped! The change to /usr/src/mol-0.9.58/emulation/molcpu.c
first involved adding a sleep() and then later, i made it shut itself
down.

        33a34,35
> #include <signal.h>
>
        567a570,571
> static int uli_failures = 0;
>
        700c704,709
        < stop_emulation();
        ---
> sleep(1);
> if (uli_failures++ > 0) {
> kill(0,SIGINT);
> } else {
> stop_emulation();
> }

(The 'uli_failures' hack was an attempt to allow this error to stop in
the debugger if it was enabled.) This fix meant i could conveniently
retry starting it up many times until it worked, if it was having these
kinds of problem. You will probably have a better fix.

At the moment, MOL is starting up fine from X, but it sure is helpful
trying to boot into a virtual terminal, especially if i've recently
booted into MacOS directly and it had gratuitously changed my screen
parameters...

> (2) MOL start up succesfully, runs for at least a few minutes with user
> interactions, and then locks up. When it does, the log shows:
>
> scsi-bus: MESSAGE_REJECTED
> scsi-bus: Going busfree instead of sending a reject message!

    This (completely harmless) error message is always present in
    the oldworld setting. Actually, the SCSI bus MacOS sees is empty
    and only present since the oldworld ROM expects one. Real block
    device access is obtained through a different mechanism.

I was still seeing MacOS lock up yesterday in a seemingly disk-related
manner, but you're right, i don't now see much of a correlation between
that message and things freezing. I'll report back if i see it again
and/or if i have any better information to provide about this.

> (3) MacOS tries to boot, but discovers that it has not been shut down
> cleanly. It normally goes to check its disk, displaying a dialog
> explaining what's happening and asking for a confirmation when it
> finishes. Under MOL, it comes up with a blank rectangle, without
> any significant disk activity.

    What happens is that MacOS tries to play a beep (writing directly
    to the hardware, without using the MOL-audio module which has not
    been loaded yet). This should only happen with old versions
    of MacOS (I think the sound hardware check was introduced in 8.5
    or 8.6). Muting the sound for built-in sound output should prevent
    this from happening.

Yup, this still happens with 'mol-0.9.58'. I still haven't gotten audio
working under MOL, but that's a matter for a separate posting.

The other fix which made my life a lot easier involved having 'molvconfig'
not ask lots of irrelevant questions when LINUX is not running the display
card in native mode ('video=ofonly'). This is more of a hack than a clean
fix, but being able to say 'molvconfig --ofonly' really makes a difference
for me. The changes to 'mol-0.9.58/vconfig/main.c' are attached below.

                        With many thanks,

                                -- Tovar

-------------------------------------------------------------------------------
diff -w -c main.c{.orig,}
*** main.c.orig Wed Apr 25 11:23:38 2001
--- main.c Sat Apr 28 14:06:43 2001
***************
*** 72,77 ****
--- 72,78 ----
  static console_vmode_t *new_root = NULL;
  static console_vmode_t *old_root = NULL;
  int in_security_mode = 1;
+ int ofonly = 0;
  
  static struct fb_var_screeninfo startup_var;
  
***************
*** 703,709 ****
--- 704,715 ----
  
                  /* Does the user accept this mode? */
                  test_pattern( &var, &fix, depths[i] );
+ if(!ofonly) {
                          ret = accept_mode();
+ } else {
+ sleep(1);
+ ret = 1;
+ }
                  if( ret > 0 ) {
                          di[ndepths].depth = depths[i];
                          di[ndepths].page_offs = (int)fix.smem_start & 0xfff;
***************
*** 840,845 ****
--- 846,856 ----
                  exit(1);
          }
  
+ if(argc>1 && strcmp(argv[1],"--ofonly")==0) {
+ ++ofonly;
+ ++argv; -- argc;
+ }
+
          res_manager_init(0, argc, argv );
          atexit( res_manager_cleanup );
          getcwd( libdir, sizeof(libdir) );
***************
*** 874,880 ****
                  "To return to this screen, three key presses are necessary since all depths are\n"
                  "tested consecutively. Press '"C_YELLOW"Q"C_NORMAL"' at any time to abort.\n\n" );
          if( !read_def_modes( config_file ) ){
! if( yn_question_nl(C_YELLOW "Remove previously configured modes?", 0 ) ){
                          console_vmode_t *next;
                          while( old_root ){
                                  next = old_root->next;
--- 885,891 ----
                  "To return to this screen, three key presses are necessary since all depths are\n"
                  "tested consecutively. Press '"C_YELLOW"Q"C_NORMAL"' at any time to abort.\n\n" );
          if( !read_def_modes( config_file ) ){
! if( ofonly || yn_question_nl(C_YELLOW "Remove previously configured modes?", 0 ) ){
                          console_vmode_t *next;
                          while( old_root ){
                                  next = old_root->next;
***************
*** 883,889 ****
                          }
                  }
          }
!
          if( !(dir=opendir( mode_dir )) ) {
                  fprintf(stderr, "opendir '%s': %s\n", mode_dir, strerror(errno) );
                  cprintf(C_RED "opendir '%s': %s\n", mode_dir, strerror(errno) );
--- 894,900 ----
                          }
                  }
          }
! if (!ofonly) {
                  if( !(dir=opendir( mode_dir )) ) {
                          fprintf(stderr, "opendir '%s': %s\n", mode_dir, strerror(errno) );
                          cprintf(C_RED "opendir '%s': %s\n", mode_dir, strerror(errno) );
***************
*** 932,941 ****
                  new_root = old_root;
                  old_root = NULL;
          }
  
          /* As a last fallback, probe the startup resolution */
          if( !new_root ){
! if( yn_question(C_GREEN "No modes configured, probe current mode?", 1) ) {
                          probe_mode( &startup_var, 0 );
                          crefresh();
                  }
--- 943,953 ----
                          new_root = old_root;
                          old_root = NULL;
                  }
+ }
  
          /* As a last fallback, probe the startup resolution */
          if( !new_root ){
! if( ofonly || yn_question(C_GREEN "No modes configured, probe current mode?", 1) ) {
                          probe_mode( &startup_var, 0 );
                          crefresh();
                  }
===============================================================================



This archive was generated by hypermail 2a24 : Sat Apr 28 2001 - 15:24:37 MDT