home *** CD-ROM | disk | FTP | other *** search
/ Amiga GigaPD 3 / Amiga_GigaPD_v3_3of3.iso / netbsd / docs / mailinglist-archive / 1993-08 / text0078.txt < prev    next >
Encoding:
Text File  |  1993-06-25  |  2.1 KB  |  53 lines
  1.  
  2. billc laments:
  3.  
  4. > >From: ahh@netcom.com (Andy Heffernan)
  5. > > >binpatch -b -a 0x72be2 -r 1 vmunix.570
  6. > > 0x72be2: 0 (0x0)
  7. > 
  8. > >I don't have access to the sources right now, but if you >have
  9. > >some other controller, try setting 0x72bea and 0x72bf2 to 1 as well
  10. > >(just going down the column for device 6).  If you're really desperate
  11. > >you may want to try setting the whole 24-byte array to 1's.
  12. > 
  13. > I did, it didn't.  I tried changing ALL of the array to 1s, to no avail.
  14. > It _still_ gives me the sync negotiation messages and pukes with a 0x4a.
  15. > During the identify's I get a TIMEO with a 0x4e right before it displays
  16. > the Archive Viper Tape drive as ST0.  (I pulled the Cipher tape drive off
  17. > in favor of one that is known to work under the kernal).
  18. > 
  19. > >> I then copy it to tape, unload it on the BSD slave, then it still  
  20. > 
  21. > 
  22. > >    You did a loadbsd of the patched kernel, right?  Worry about
  23. > >updating /vmunix when you get booted succesfully!
  24. > 
  25. > Yeh, I don't have that problem, because I can't GET to a command prompt
  26. > under BSD ;-).
  27.  
  28.     Yeah, that's obvious to me now -- I got confused by your
  29. statement about copying the kernel to your BSD slave (at least that's
  30. the cover story I'm using!)
  31.  
  32. > I've noticed that when I do the binpatch, the returned value is always 0,
  33. > which according to the binpatch doc is wrong.. any ideas?  This would
  34. > explain why nothing is changing in the kernel.
  35.  
  36.     Do you mean that if you run the same "binpatch -r 1" command
  37. twice in a row, it still says something like:
  38.     0x72be2: 0 (0x0)
  39. It shouldn't, the line that's printed out shows what's there now, so it
  40. should change to:
  41.     0x72be2: 1 (0x1)
  42. A couple more things to try would be to try working with longs instead
  43. of bytes (this is what I did because I forgot about the -b switch), so
  44. you would do "binpatch -l -a 0x72be0 -r 512 vmunix.570"; or, as a test
  45. of binpatch, try setting scsi_debug (a long) to 1, and see if you
  46. notice any change in output while booting (maybe you're already doing
  47. this).
  48.  
  49. --
  50. ------------------------------------------------------------------------
  51. Andy Heffernan                                            ahh@netcom.com
  52.  
  53.