[rescue] Rescued SS2 crashes booting SunOS4 install CDs

Sat Sep 7 13:34:02 EDT 2024

Would you be willing to share the model more broadly?  I have an SS5 and
SS20 that I'm in the process of putting the ZuluSCSI in the computers.  It
would make my like much easier to be able to just print a mount or two.

Thanks,
~Daniel

On Thu, Sep 5, 2024, 17:48 Todd Vernon via rescue <rescue at sunhelp.org>
wrote:

> I have a model for your drive sled if you like.  Happy to send.
>
> What are you looking for for 1+ and do you have photos?
>
> -t
>
>
> Todd Vernon
> Entrepreneur | Investor
> Email: todd at toddvernon.com
> LinkedIn: toddvernon <https://www.linkedin.com/in/toddvernon/>
>
>
> On Sep 5, 2024 at 2:34:28 AM, Alan Perry <alanp at snowmoose.com> wrote:
>
>> Yes.
>>
>> The kernel read fault is always at the same address for each kernel, even
>> if I swap the memory sticks around. I moved the memory to a SS1+ that I am
>> also restoring and it works fine with that memory.
>>
>> The last message displayed before the panic is that it was starting init.
>> I have looked at the code for bringing up user mode in Solaris/SunOS 5 but
>> not SunOS 4. It is pretty fun trying to work out exactly is happening.
>>
>> Meanwhile if someone is looking for a SS1+ … Specs are  64M, ZuluSCSI
>> with a 32G SD card to configure to taste, SunOS 4.1.4 installed now, new
>> style MK48T02 IDPROM (that fails self-test), Boeing asset tag on case). It
>> will be available in a couple weeks. I am working on a 3D model to print a
>> drive sled to mount the ZuluSCSI in the floppy drive bay with the SD card
>> removable through the floppy disk slot.
>>
>> alan
>>
>>
>> On Sep 2, 2024, at 10:20, Todd Vernon <todd at toddvernon.com> wrote:
>>
>> 
>> I assume you programmed the clock nvram?
>>
>> T
>>
>> ---
>> Todd Vernon
>> Entrepreneur | Investor
>> Email: todd at toddvernon.com
>> LinkedIn: toddvernon <https://www.linkedin.com/in/toddvernon/>
>> On Sep 2, 2024 at 10:41 AM -0600, Alan Perry via rescue <
>> rescue at sunhelp.org>, wrote:
>>
>>
>> Hi again,
>>
>> Yesterday I posted about getting a ZuluSCSI working in a SS2. As I
>> noted, I have since found that it fails the same way booting with a
>> physical CDROM drive and HDD. I had the same problem booting 4.1.2 and
>> 4.1.4 CDs.
>>
>> The system passes all of the self-tests, including the full memory
>> tests, except for "TOD Registers Test FAILURE: TOD (f20007fa) Bit
>> Failure, Exp = 000000ff, Obs = 0000007f". It had a new MK48T02, so I
>> expect this.
>>
>> I have tried swapping memory sticks around and 4.1.4 continues to fail
>> on the same address.
>>
>> The output is below. Has anyone here seen a failure like this before?
>>
>> alan
>>
>>
>> SunOS 4.1.2:
>> Boot: vmunix
>> Size: 737280+2232656+40752 bytes
>> Kernel: libprom.a: Romvec Version 2
>> SunOS Release 4.1.2 (MUNIX) #2: Wed Oct 23 10:51:44 PDT 1991
>> Copyright (c) 1983-1991, Sun Microsystems, Inc.
>> mem = 32768K (0x2000000)
>> avail mem = 5066752
>> Ethernet address = 8:0:20:53:9a:8a
>> cpu = SUNW,Sun 4/75
>> BAD TRAP
>> (unknown): Data fault
>> kernel read fault at addr=0xf8303f0f, pme=0x63000303
>> Sync Error Reg 80<INVALID>
>> pc=0xf809d104, sp=0xf80c0bc8, psr=0x11400cc6, context=0x0
>> g1-g7: 80000000, 0, 1000, f8005000, f80c1c00, 330400, ffe8eb18
>> Begin traceback... sp = f80c0bc8
>> Called from f8097e7c, fp=f80c0c38, args=f82dc980 ff001000 0 f80c0c98 c00
>> f82e3080
>> Called from f80a0530, fp=f80c0ca8, args=0 ff001000 1000 ec00ffff 0 1
>> Called from f80b3130, fp=f80c0d08, args=1 11000ce1 ff001000 0 40f1000
>> ff001000
>> Called from f80a0348, fp=f80c0d70, args=fd801158 fd801110 ef0 38 fd801588
>> 0
>> Called from f80a01e4, fp=f80c0dd0, args=fd801000 fd801038 fd801048
>> ffeb6e40 fd8011b0 fd801158
>> Called from f80a0188, fp=f80c0e30, args=f80d4800 fff01000 0 0 10 f80c0e20
>> Called from f80a4630, fp=f80c0e90, args=0 fff02000 0 ec00ffff 0 1
>> Called from f80149a4, fp=f80c0ef8, args=f831f3c0 4eb 317400 fff 32d a8
>> Called from f8005258, fp=f80c0f58, args=f80c0fb4 ffffffff 18 0 f808e528 0
>> Called from 304ec4, fp=0, args=4000 2ffc50 1 221150 4000 0
>> End traceback...
>>
>> SunOS 4.1.4:
>> Boot: vmunix
>> Size: 770048+2247512+54024 bytes
>> SunOS Release 4.1.4 (MUNIX) #2: Fri Oct 14 11:07:06 PDT 1994
>> Copyright (c) 1983-1993, Sun Microsystems, Inc.
>> mem = 32768K (0x2000000)
>> avail mem = 5001216
>> Ethernet address = 8:0:20:53:9a:8a
>> cpu = SUNW,Sun 4/75
>> zs0 at obio 0xf1000000 pri 12
>> zs1 at obio 0xf0000000 pri 12
>> sbus0 at SBus slot 0 0x0
>> dma0 at SBus slot 0 0x400000
>> esp0 at SBus slot 0 0x800000 pri 3
>> sd0 at esp0 target 3 lun 0
>> sd0: Vendor 'SEAGATE', product 'ST11200N', (unknown capacity)
>> sr0 at esp0 target 6 lun 0
>> le0 at SBus slot 0 0xc00000 pri 5
>> fd0 at obio 0xf7200000 pri 11
>> rd0: using preloaded munixfs
>> WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
>> root on rd0a fstype 4.2
>> swap on ns0b fstype spec size 4788K
>> dump on ns0b fstype spec size 4776K
>> BAD TRAP
>> pid 3, `init': Data fault
>> kernel read fault at addr=0xf82c00b8, pme=0x630002c0
>> Sync Error Reg 80<INVALID>
>> pc=0xf809396c, sp=0xf834a548, psr=0x110000c3, context=0x3
>> g1-g7: f80c3000, 8000000, ffffffff, 1, f834b000, 0, 0
>> Begin traceback... sp = f834a548
>> Called from f80b5f58, fp=f834a5a8, args=f82bffc0 ff010500 1b00 100 2
>> ff010000
>> Called from f8063284, fp=f834a608, args=ff00e484 1 fce045f4 1dc000
>> f82bfac0 2000
>> Called from f8072de8, fp=f834a6a0, args=ff00c634 0 f833b3a8 f834a860 1
>> ff008020
>> Called from f8063824, fp=f834a708, args=f834a860 ff00c634 0 1000
>> f834a86c f834a860
>> Called from f8066438, fp=f834a778, args=ff00c634 0 2000 f834a86c
>> f834a860 2000
>> Called from f8068f58, fp=f834a7f0, args=ff00c634 0 2000 f834a86c
>> f834a860 2000
>> Called from f806f624, fp=f834a870, args=ff008020 ff94c000 2000 2 0
>> ff00c634
>> Called from f805c0c4, fp=f834a8d0, args=ff94c000 ff008020 2000 2 0
>> ff94c000
>> Called from f8052fdc, fp=f834a930, args=ff94c000 ff94c000 2000 0 f834a994
>> 0
>> Called from f80516a8, fp=f834a998, args=ff00c62c 0 0 f834a9fc 2000
>> fde03000
>> Called from f8060718, fp=f834aa00, args=ff00c62c f834ab40 f834aa64 0 200 0
>> Called from f806604c, fp=f834aa68, args=ff00c62c f834ab40 f834ab3c
>> ff008300 f834aca4 0
>> Called from f803fda8, fp=f834aad0, args=ff00c634 f834ab40 f834ab3c
>> ff008300 f834aca4 0
>> Called from f803fa30, fp=f834ac40, args=f834aca4 1 0 f834adb4 0 ff00c634
>> Called from f803f9f0, fp=f834acb0, args=0 0 1 0 f834adb4 0
>> Called from f8042188, fp=f834ad10, args=10080 0 1 0 f834adb4 f832501c
>> Called from f80408cc, fp=f834adf8, args=10080 0 3 914 f834ae5c 180
>> Called from f804083c, fp=f834ae60, args=10080 3 914 fce04d90 0 f8325000
>> Called from f80b0300, fp=f834aec0, args=f834afe0 28 f80d12b0 f80d12d8
>> f834b000 f80d12d8
>> Called from f8005a1c, fp=f834af58, args=f834b000 f834afb4 f834afe0
>> f834b000 f834b000 f834afb4
>> Called from 3944, fp=f7fffe38, args=10080 2 3914 80 3 c400
>> End traceback..
>>
>>
>> _______________________________________________
>> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org
>>
>> _______________________________________________
> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sunhelp.org/pipermail/rescue_sunhelp.org/attachments/20240907/f323dd07/attachment.html>