qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] SS20 running SunOS 4.1.4 - Data Access Exception on b


From: jim
Subject: Re: [Qemu-discuss] SS20 running SunOS 4.1.4 - Data Access Exception on boot
Date: Wed, 9 Dec 2015 20:06:17 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

Hi,

My experience is that it gets pretty hard to transfer an image because
there are subtle hardware differences between physical and the emulation.

I did an article on what I found worked reasonably for me : See
http://kb.networksystemssolutions.info/index.php/Sparc_Virtualization

It is based on having the original hardware to pre-prepare the
filesystem before virtualizing.  If you just have a dump image, you
probably need to get it online somehow to edit some files.

Key thing I'd try would be

touch /reconfigure

To force a hardware reconfig (should re-link the various kernel modules
to match the detected hardware).

or it may not.  I've had more failures than successes, though SunOS
4.1.4 was generally more successful than other SunOS/Solaris versions.

If you get it working, please post details - the list archives are
unfortunately lacking on good Sparc/SunOS/Solaris info to overcome
problems.  Many of the CPU variations work only in specific combinations
(and crash in others) and the OpenBoot ROM is fairly poor in my
experience when it's SunOS or Solaris (but seems to be good for Sparc
Linux as far as I can see).

Jim


On 09/12/2015 18:33, Tandy, Bob (UK) wrote:
> Hi,
>
> A lot of people seem to be having success with the SS20 running SunOS 4.1.4 
> so perhaps someone may have a solution to my situation.
> I'm using QEMU 2.4.1 for all the experiments, and have tried on both Windows 
> 7 and Oracle Linux hosts.
>
> I have successfully booted from an ISO image and used that to restore a dump 
> backup using a SS5 ROM image. But this gives me the wrong hostid for what I 
> need to do. Having built from source the Linux executables I tweaked the code 
> to try and force a "72" in first field of the hostid but this fails to start. 
> So thought it might be better to run with a SS20 ROM image and I found some 
> at http://home.earthlink.net/~reif/
>
> However with either ss20_v.2.25_rom or ross225r.bin I get a "Data Access 
> Exception" error,  using either the image created using SS5 or by returning 
> to the ISO image to create a new, vanilla install. 
>
> I get the following cksum output from ss20_v.2.25_rom:
>       4159205650 524288 ss20_v.2.25_rom
> If this is wrong then probably the problem. But where can I get a correct ROM 
> image from?
>
>
> Using the following to boot from "CD":
>       /usr/local/bin/qemu-system-sparc -nographic -monitor 
> telnet:127.0.0.1:4444,server,nowait -bios ss20_v.2.25_rom -M SS-20 -smp 
> 2,cores=4 -cpu "TI SuperSparc 60" -hda ss20.img -hdb solaris1.1.2.iso 
>
> I get the following output:
>
>            SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)
>
> CPU_#0       TI, TMS390Z50(3.x)       0Mb External cache
>
> CPU_#1       ******* NOT installed *******
> CPU_#2       ******* NOT installed *******
> CPU_#3       ******* NOT installed *******
>
>     <<< CPU_00000000 on MBus Slot_00000000 >>> IS RUNNING (MID = 00000008) 
>
>
> $$$$$   WARNING : No Keyboard Detected! $$$$$
> MMU Context Table Reg Test   
> MMU Context Register Test    
> MMU TLB Bit Pattern Tests    
>
>     <<< CPU_00000000 on MBus Slot_00000000 >>>
>      ERROR : Address = 00000000, 
>      exp = aaaaa000, obs = 00000000, xor = aaaaa000
>      U-NUMBER : Suspect Viking Module
> Available Memory 0x08000000
> Allocating SRMMU Context Table 
> Context Table allocated, Available Memory 0x07fc0000
> Setting SRMMU Context Register
> Context Table allocated, Available Memory 0x07fc0000
> Setting SRMMU Context Table Pointer Register
> RAMsize allocated, Available Memory 0x07fb0000
> Allocating SRMMU Level 1 Table
> Level 1 Table allocated, Available Memory 0x07fafc00
> Mapping RAM @ 0xffef0000
> RAM mapped, Available Memory 0x07fafa00
> Mapping ROM @ 0xffd00000
> ROM mapped, Available Memory 0x07faf800
> Mapping ROM @ 0x00000000
> ROM mapped, Available Memory 0x07faf000
> ttya initialized
> Cpu #0 TI,TMS390Z50 
> Cpu #1 Nothing there 
> Cpu #2 Nothing there 
> Cpu #3 Nothing there 
> Probing Memory Bank #0 64 Megabytes of DRAM
> Probing Memory Bank #1 64 Megabytes of DRAM
> Probing Memory Bank #2 Nothing there
> Probing Memory Bank #3 Nothing there
> Probing Memory Bank #4 Nothing there
> Probing Memory Bank #5 Nothing there
> Probing Memory Bank #6 Nothing there
> Probing Memory Bank #7 Nothing there
> Incorrect configuration checksum; 
> Setting NVRAM parameters to default values.
> Setting diag-switch? NVRAM parameter to true
> Probing /address@hidden,e0000000/address@hidden,e0001000 at f,0  espdma esp 
> sd st ledma le SUNW,bpp 
> Probing /address@hidden,e0000000/address@hidden,e0001000 at e,0  
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 0,0  Nothing there
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 1,0  Nothing there
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 2,0  SUNW,tcx 
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 3,0  Nothing there
> Cpu #0 TI,TMS390Z50 
> Cpu #1 Nothing there 
> Cpu #2 Nothing there 
> Cpu #3 Nothing there 
> Probing Memory Bank #0 64 Megabytes of DRAM
> Probing Memory Bank #1 64 Megabytes of DRAM
> Probing Memory Bank #2 Nothing there
> Probing Memory Bank #3 Nothing there
> Probing Memory Bank #4 Nothing there
> Probing Memory Bank #5 Nothing there
> Probing Memory Bank #6 Nothing there
> Probing Memory Bank #7 Nothing there
> Incorrect configuration checksum; 
> Setting NVRAM parameters to default values.
> Setting diag-switch? NVRAM parameter to true
> Probing /address@hidden,e0000000/address@hidden,e0001000 at f,0  espdma esp 
> sd st ledma le SUNW,bpp 
> Probing /address@hidden,e0000000/address@hidden,e0001000 at e,0  
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 0,0  Nothing there
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 1,0  Nothing there
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 2,0  SUNW,tcx 
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 3,0  Nothing there
>
> SPARCstation 20 (1 X 390Z50), No Keyboard
> ROM Rev. 2.25, 128 MB memory installed, Serial #9900323.
> Ethernet address 72:7:2:97:11:23, Host ID: 72971121.
>
>
> Boot device: /iommu/sbus/address@hidden,400010/address@hidden,c00000  File 
> and args:   
> Internal loopback test -- Wrong packet length; expected 36, observed 64 
>
> Can't open boot device
>
> Type  help  for more information
> ok boot disk1:d
> Boot device: 
> /iommu/sbus/address@hidden,400000/address@hidden,800000/address@hidden,0:d  
> File and args: 
> root on 
> /address@hidden,e0000000/address@hidden,e0001000/address@hidden,400000/address@hidden,800000/address@hidden,0:d
>  fstype 4.2
> Boot: vmunix
> Size: 868352+2319136+75288 bytes
> SuperSPARC: PAC ENABLED
> SunOS Release 4.1.4 (MUNIX) #2: Fri Oct 14 11:09:07 PDT 1994
> Copyright (c) 1983-1993, Sun Microsystems, Inc.
> cpu = SUNW,SPARCstation-20
> mod0 = TI,TMS390Z50 (mid = 8)
> mem = 130616K (0x7f8e000)
> avail mem = 124592128
> Ethernet address = 72:7:2:97:11:23
> BAD TRAP: cpu=0 type=9 rp=f00e0af4 addr=0 mmu_fsr=126 rw=1
> MMU sfsr=126: Invalid Address on supv data fetch at level 1
> regs at f00e0af4:
>       psr=40800cc5 pc=f002d1bc npc=f002d1c0
>       y: 1c00000 g1: ffd3e3d8 g2: f0314400 g3: fb005ff0
>       g4: f0005000 g5: f00e1000 g6: 0 g7: 30000000
>       o0: 8000000 o1: fb005ff0 o2: f0005000 o3: f00e1000
>       o4: 0 o5: 30000000 sp: f00e0b40 ra: 0
> (unknown): Data access exception
> kernel read fault at addr=0x0, pme=0x0
> MMU sfsr=126: Invalid Address on supv data fetch at level 1
> rp=0xf00e0af4, pc=0xf002d1bc, sp=0xf00e0b40, psr=0x40800cc5, context=0x0
> g1-g7: ffd3e3d8, f0314400, fb005ff0, f0005000, f00e1000, 0, 30000000
> Begin traceback... sp = f00e0b40
> Called from f00a66dc, fp=f00e0ba0, args=fb0015e0 fb0015e0 fb0014e0 0 0 
> ffd763f0
> Called from f00a6430, fp=f00e0c00, args=fb001418 f00ffbd8 6 fb0014e0 ffd763f0 
> fb0015e0
> Called from f00a6788, fp=f00e0c60, args=fb001418 76 73 0 f00ffbd8 76
> Called from f00a63f0, fp=f00e0cc0, args=fb001160 0 0 fb001418 0 fb001418
> Called from f00a6788, fp=f00e0d20, args=fb001160 76 54 0 f00ffba4 76
> Called from f00a6370, fp=f00e0d80, args=fb001000 f00ff800 fb001000 fb001050 
> fb0011b0 fb001160
> Called from f00a6320, fp=f00e0de0, args=f0102400 fefe0014 0 0 10 f00e0dd0
> Called from f00ad8b0, fp=f00e0e40, args=7fff00 f033fc04 1 800000 86 72
> Called from f001630c, fp=f00e0ef8, args=800000 100000 f0788bb4 2000 7ffe 2
> Called from f000539c, fp=f00e0f58, args=f00e0fb4 f0007810 293ff553 a8052044 
> 200 f00d1d18
> Called from 403f0c, fp=0, args=4000 3ffd60 1 236320 4000 0
> End traceback...
> panic: Data access exception
> rebooting...
> Resetting ...
>
>
> If I change the -cpu argument to match what is shown for CPU #0, I get 
>       qemu: Unable to find SPARC CPU definition
>
> Any pointers to where to investigate next gratefully appreciated.
>
> I'm not in interested in getting the graphics going. What I am hoping to do 
> is replicate the 21 year old original machine before the power goes off for 
> several days for maintenance, I fear it may not come back online. It has been 
> running for 965 consecutive days. The last reboot was last time power was 
> removed was due to aircon going down. It is a good machine and deserves to 
> retired gracefully after such sterling service.
>  
> TIA
> Bobbity
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
>


----------------------------------------------------------------------
All e-mail and telephone communications are subject to Suresafe Terms
And Conditions and may be monitored, recorded and processed for the
purposes contained therein and adherence to regulatory and legal
requirements.

Your further communication or reply to this e-mail indicates your
acceptance of this.

Any views or opinions expressed are the responsibility of the author
and may not reflect those of Suresafe Protection Limited.

Suresafe Protection Limited is registered in Scotland, number SC132827
The registered office is at 8 Kelvin Road, Cumbernauld, G67 2BA.
Telephone: 01236 727792    Fax: 01236 723301   VAT Number: 556 6950 02




reply via email to

[Prev in Thread] Current Thread [Next in Thread]