home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text4661.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  3.5 KB
  1. Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id IAA08422 for <executor@nacm.com>; Fri, 8 Sep 1995 08:11:07 -0700
  2. Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id JAA08417; Fri, 8 Sep 1995 09:11:01 -0600
  3. Received: from gwar.ardi.com by mailhost  with smtp
  4.     (nextstep Smail3.1.29.0 #11) id m0sr4yu-000YbDC; Fri, 8 Sep 95 09:04 MDT
  5. Received: by gwar.ardi.com (linux Smail3.1.28.1 #5)
  6.     id m0sr4yu-000GOkC; Fri, 8 Sep 95 09:04 MDT
  7. Message-Id: <m0sr4yu-000GOkC@gwar.ardi.com>
  8. Date: Fri, 8 Sep 95 09:04 MDT
  9. From: mat@ardi.com (Mat Hostetter)
  10. To: jowaters@NMSU.Edu
  11. Cc: executor@nacm.com
  12. Subject: Re: Svga & Linux
  13. In-Reply-To: <199509072132.PAA14123@NMSU.Edu>
  14. References: <Pine.3.89.9509071353.A15878-0100000@gold.tc.umn.edu>
  15.     <199509072132.PAA14123@NMSU.Edu>
  16. Sender: owner-paper@nacm.com
  17. Precedence: bulk
  18.  
  19. >>>>> "jowaters" == jowaters  <jowaters@NMSU.Edu> writes:
  20.  
  21.     jowaters> Oh, for the record ARDI folks, executor 1.2.7 doesn't
  22.     jowaters> work on my machine either (I'm running a 2-meg VL-bus S3
  23.     jowaters> 805 board, like others who have already posted bug
  24.     jowaters> reports...  I guess it's a chipset problem right now...)
  25.  
  26.     jowaters> But the X version is amazing.  I'm totally impressed
  27.     jowaters> with the work you folks have done so far.  If there's
  28.     jowaters> anything I can do to help debug the svgalib version (my
  29.     jowaters> screen goes black, but I still retain control of the
  30.     jowaters> machine) I'd love to help...  I don't know how to get
  31.     jowaters> any debug output from it right now though.
  32.  
  33. Here's a message from the linux-svgalib mailing list yesterday, from
  34. one of the main svgalib maintainers.  It explains what we believe to
  35. be the problem (cottons@ardi.com figured it out).  Basically,
  36. `vga_safety_fork' (an svgalib routine Executor calls) is broken
  37. because it throws away important I/O port permissions.  We should have
  38. a workaround in the next BleedingEdge release.
  39.  
  40. Thanks for your patience.
  41.  
  42. -Mat
  43.  
  44. ----------------------------------------------------------------------
  45. From: Michael Weller <eowmob@exp-math.uni-essen.de>
  46. Sender: vger.rutgers.edu!owner-linux-svgalib
  47. Sender: owner-linux-svgalib@vger.rutgers.edu
  48. To: linux-svgalib@vger.rutgers.edu
  49. Subject: vga_safety_fork()
  50. Date: Thu, 7 Sep 1995 17:36:28 +0200 (MSZ)
  51.  
  52. I was pointed to a problem with vga_safety_fork().
  53. iopermissions are not inherited through forks which causes a segfault
  54. when the ports are accessed. The segfault handler tries to restore textmode
  55. which again segfaults when accessing the ports -> endless loop.
  56.  
  57. One could change get_vga_perm to get the required access permissions, but 
  58. this doesn't help coz it does not care for the access permissions of all
  59. card specific registers. Calling the cards initialization routines
  60. a second time might not work well for all drivers. I don't see an easy fix
  61. for this problem. A new card specific driver func might be needed to 
  62. clone the permissions.
  63.  
  64. I'll investigate further, but if I don't find a simple solution I'll make
  65. vga_safety_fork a noop until a working solution is found.
  66.  
  67. One could, however, just call iopl(3) in the forked off proc as we
  68. really trust it (do we?).
  69.  
  70. Comments/Suggestions?
  71. Michael.
  72.  
  73. (eowmob@exp-math.uni-essen.de or  eowmob@pollux.exp-math.uni-essen.de
  74. Please do not use my vm or de0hrz1a accounts anymore. In case of real
  75. problems reaching me try mat42b@aixrs1.hrz.uni-essen.de instead.)
  76. ----------------------------------------------------------------------
  77.  
  78.