home *** CD-ROM | disk | FTP | other *** search
/ Amiga GigaPD 3 / Amiga_GigaPD_v3_3of3.iso / netbsd / docs / mailinglist-archive / 1993-11 / text0256.txt < prev    next >
Encoding:
Text File  |  1993-06-25  |  8.2 KB  |  176 lines
  1. On Nov 23,  8:57pm, Patrick Vervoorn wrote:
  2. > I have tried the brand-new vmunix-040.713 kernel, but it, much to my
  3. > regret, doesn't do much on my Amiga 4000/040, though comparably a lot more
  4. > than previous kernels... :)
  5.  
  6.   Ah - someone finally willing to try it out on the A4000.
  7.  
  8. > The first problem is (probably) the AGA chipset; if I boot with it enabled,
  9. > the console screen that appears is a bunch of garbage. Selecting the ECS
  10. > setting in the 3.0 bootmenu fixes this. Typing
  11.  
  12.   That would make sense - the current kernel wouldn't know anything about
  13. the AGA stuff.
  14.  
  15. > 1> RunShit loadbsd.713 vmunix-040.713
  16. > 
  17. > also fixes this problem. RunShit is a rather useful "getting euro-demos to
  18. > work"-utility. Too bad I have to use it with NetBSD :)
  19.  
  20.   Is the source to RunShit available?  If it's easy to select the ECS mode
  21. from software, loadbsd could be modified to do this.  This would be
  22. a workaround until the kernel can initialize things properly.
  23.  
  24. > The second problem happens during booting; since I know of no way to
  25. > redirect the console output to a file (and I don't even have a NetBSD
  26. > partition yet (my HD died sunday :()), I have written it on a piece of
  27. > paper and will type it from this piece of paper; I might have missed
  28. > something or used the wrong character case (upper/lower), so there might be
  29. > some errors. All goes well upto and including the first line I quote, after
  30. > that the sh*t hits the fan...
  31. > 
  32. > ---------------------------------------------------------------------------
  33. > 
  34. > using 102 buffers blabla....
  35. > unexpected trap (vector offset 30) from 10009
  36.  
  37.   This is rather strange, as that trap is defined as "reserved, undefined"
  38. according to my 68040 manual.  I'll have to look at what's at that pc
  39. location.
  40.  
  41. > pid 0: kernel format exception
  42.  
  43.   Looks like a stack frame got clobbered, or maybe the 040 doesn't accept
  44. the stack frame from the previous exception.
  45.  
  46. > trap: bad kernel access at 10
  47. > trap type 8, code = 485, v = c0
  48. > pid = 0, pc = 00059F68, ps = 2018, sfc = 0001, dfc = 0001
  49. > registers:
  50. >         0        1        2        3        4        5        6        7
  51. > preg FFFFFFF7 FFFFFFFF 00000001 00000000 0000008A 0000000C 0000000D 00000000
  52. > areg 00000000 01C0F850 000A5E50 00000000 0009A068 00000000 FFFFFEAE 0EFFFFFC
  53.  
  54.   This looks like a fault in the kernel trying to access location 0x10
  55. (or 0xc0 - the "at 10" and "v= c0" should be printing out the same value).
  56. Again, I'll have to check the pc location and see what was going on.
  57.  
  58. > kernel stack (FFFFFD8C)
  59. > 
  60. > <kernel stack dump *NOT* hand-copied :)>
  61.  
  62.   I don't blame you :-)
  63.  
  64. > panic: MMU fault
  65. > hit any key to boot/dump
  66. > 
  67. > <this repeats indefinately when hitting a key>
  68.  
  69.   It's probably not a good idea to hit a key at this point until the 
  70. kernel gets far enough to be able to write a dump file.  Since there's
  71. nothing to analyze a dump file yet anyway, it's probably best to just
  72. reboot at this point.
  73.  
  74. > All this on an Amiga 4000/040, 8MB FAST, 2MB CHIP, the plain SeaCrate
  75. > 120meg HD and nothing else in it. It is of course possible it crashes
  76. > because it finds no supported host-adapter; after my HD crash I removed my
  77. > GVP HC8+ (it slowed down the booting by about half a minute every time I
  78. > reset due to no devices on the SCSI bus)... If this is so, it might prove
  79. > useful to give some more meaningfull messages during bootup, indicating
  80. > this problem...
  81.  
  82.   I'm not sure, but you might be able to disable the autoboot on the GVP
  83. HC8+ card which would allow you to leave the card in the machine without
  84. a hard disk connected.  I ran mine that way for a while.  If I wanted to
  85. use the controller, I could just run binddrivers (I don't normally run it
  86. on bootup since I have nothing that needs it at the moment).  Then again,
  87. I don't think this would work on the next kernel - I modified the autoconfig
  88. of the GVP devices to try to distinguish the Series II controller and
  89. the I/O extender card.  I think the Series II controller with the autoboot
  90. disabled would look exactly like the I/O extender.  [I'm going to disable
  91. the autoboot on my GVP this weekend since I want to try out a new ADOS
  92. driver for it, so I'll find out if it will work.]
  93.  
  94.   If the fast memory on the A4000 starts at 0x07000000 or higher, the current
  95. kernel will think it's running on an A3000 and attempt to configure the
  96. hardware as such.  Specifically, it will try to access the real time clock
  97. [does anybody know if the RTC on the A4000 is the same or different than
  98. the RTC on the A3000?], and it will also attempt to access the built-in
  99. SCSI on the A3000.  The next kernel will have a patchable location
  100. (_a3000_flag) that can be patched to 0 to disable the A3000 configuration
  101. setup.  I suspect that the A4000 may need a special configuation setup.
  102.  
  103. > I hope this means something to all you kernel hackers; I'm not one of them,
  104. > though I've tried to compile the kernel under AmigaDOS. To no avail, which
  105. > brings me to my third problem;
  106.  
  107.   Since I've been doing the 040 support, it does mean something to me and
  108. I will do what I can to help get it running on the A4000.  Since I don't
  109. have any access to an A4000, it's not too easy to do.
  110.  
  111. > - Until my new HD arrives (hopefully at or before the end of this week), I
  112. > can't even try to write the rootfs to my HD. Does the current rootfs still
  113. > work with the '040 patches (or a '040 kernel)? Or is it hopelessly
  114. > out-of-date?
  115.  
  116.   I've booted my '040 kernel using the original rootfs and it works well
  117. enough to boot up to the root prompt and allow access to the root file
  118. system.  Unfortunately, the 713 and later kernels have changed some
  119. data structures so that the old newfs will not run.  It should be easy
  120. enough to transfer the new newfs to the root partition.
  121.  
  122. > - Could the author of the rather handy (or so the message claimed) "raw
  123. > partition write"- util (I forgot its AND the author's name: sorry about
  124. > that) please upload it to ftp.eunet.ch? I don't have a spare HD and will
  125. > add NetBSD to my new HD and would like to, when possible, keep the other
  126. > partitions intact.. ;-)
  127.  
  128.   If you are talking about the dcp program by Chris Hooper, it should be
  129. available at ftp.mtu.edu in the directory /pub/cdh.  It's much easier to
  130. use dcp than filetodev [I never bothered trying to use filetodev.]
  131.  
  132. > - Is there a way to check where you write the rootfs? I know the method to
  133. > calculate the blocknumber where you should write it is in the FAQ (and I
  134. > understand it fully), but I suppose you could also use the calculated
  135. > numbers with the 'devtofile' command to read the blocks you intend to
  136. > overwrite into a file. Can this file be examined to check if you are indeed
  137. > 'poking' at the right spot? What should I look for in this file?
  138.  
  139.   If you have the RDB information correct, then dcp will access the correct
  140. location.
  141.  
  142. > - A question about the current GVP SCSI driver. Does it take advantage of
  143. > possible 16-bit RAM which I could put on the HC8+? This would be the
  144. > fastest possible temporary buffer (of minimally 2MB) for the HC8+ to DMA
  145. > the data to and the fastest possible buffer to CPU-copy it out of. (Besides
  146. > having 32-bit RAM within the ZORRO-II range, something which is, AFAIK,
  147. > impossible on the A4000/040).
  148.  
  149.   No, the current GVP SCSI driver does not take advantage of the Zorro II
  150. memory.  You need to patch _scsi_no_dma if your fast memory is outside
  151. the Zorro II address space.  I've had some thoughts on doing some things
  152. dynamically for both the GVP and A2091 drivers so that it will use DMA
  153. if the buffer is withing the Zorro II address space and use PIO if the
  154. buffer isn't.  I'd also like to try setting up a chip memory buffer that
  155. could be used to do DMA if the buffer is outside the Zorro II address
  156. space (there isn't any convenient way at the moment to have it use 16
  157. bit memory, which would be better - but DMA using chip memory should
  158. be better than PIO).
  159.  
  160. > And, to ease my decision, when will there be a NetBSD driver for either the
  161. > A4091 or the Z3 Fastlane? :) (or any other Fast-SCSI-2 adapter that might
  162. > emerge.)
  163.  
  164.   I've got the 53C710 [got that number correct this time!] drive reorganized
  165. to allow supporting different cards, so the A4091 support should be easy
  166. to add once all the required hardware details are known.
  167.  
  168. Michael
  169.  
  170. -- 
  171. Michael L. Hitch            INTERNET:  osymh@montana.edu
  172. Computer Consultant            BITNET:  OSYMH@MTSUNIX1.BITNET
  173. Office of Systems and Computing Services
  174. Montana State University    Bozeman, MT    USA
  175.  
  176.