home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sun / admin / 5531 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  2.1 KB
  1. Path: sparky!uunet!mcsun!uknet!cf-cm!news
  2. From: spxpmf@thor.cf.ac.uk (Phillip Fayers)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Large Disk problem on Sun4
  5. Message-ID: <17963.9208141108@thor.cf.ac.uk>
  6. Date: 14 Aug 92 11:08:14 GMT
  7. Sender: news@cm.cf.ac.uk (Network News System)
  8. Organization: Physics Dept. University of Wales, Cardiff
  9. Lines: 37
  10. X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway
  11.  
  12. Hi all,
  13.     I've had a problem with a system recently and I have an idea
  14. that I've worked out what is wrong - I need to find out whether I'm
  15. right or not. The problem is this:
  16.  
  17.     Machine: Sun 4/360 (sun4/sun4 arch)
  18.     OS:      SunOs 4.1.1
  19.  
  20.     The system crashed a few times with a memory error, telling me
  21. which SIMM has the error, this isn't the main problem, we only thought
  22. it was. The SIMM is definately dud and is going to be replaced. The
  23. Prolem occured when the machine reboots after crashing, it failed to
  24. `fsck' our main user disk (a 1.4 GByte Seagate). This disk was in two
  25. partitions, one of 1200 MB (the user data) and one of ~200 MB (swap
  26. space), the swap space was `at the back' of the disk.
  27.     When crashing the machine claims to do a memory dump but when
  28. rebooting `savecore' fails to find it. This disk worked happily on the
  29. machine previously as a single 1400 MB partition which was filled (at
  30. times) to more than 1200 MB. Reformatting the drive on this machine
  31. failed twice - with no error messages, it just died part way through -
  32. reformatting on an IPC (4.1.1 patched for large disks) worked.
  33.  
  34.     It appears that the machine can handle filesystems > 1GB BUT
  35. when it attempts to write a memory dump to the swap partition it writes
  36. to the wrong place! Instead of starting to write at the end of the disk
  37. (the 1400th MB) and working back it appears to be doing the dump in the
  38. middle of our data disk, wiping out information as it does so. So the
  39. kernel has been fixed to understand >1GB filesystems but the code which
  40. does a memory dump has not.
  41.  
  42.     Am I on the right track ?
  43.     Can anyone confirm on deny my suspicions ?
  44.  
  45. -- 
  46.  
  47. Phillip Fayers                      email: fayers@cardiff.ac.uk
  48. Sun admin/support/programming       phone: 0222 874000 x 5282 (UK)
  49.