Richard Earnshaw wrote:

> > On 25th Oct, Todd Whitesel wrote:
> > >       root file system type: ffs
> > >       panic: Prefetch abort in non-USR mode (frame=0xf35a8d44)
> > >
> > >       Stopped in init at      _Debugger+0x10: ldmdb   r11, {r11, r13, r15}
> > >       db>
> > >
> > > if I type "trace" I get
> > >
> > >       db>trace
> > >       _Debugger(_Debugger+0x10)
> > >       _panic(_panic+0x14)
> > >       _prefetch_abort_handler(_prefetch_abort_handler+0x10)
> > >       _cnopen(_cnopen+0x10)
> > >       _spec_open(_spec_open+0x10)
> > >       _vn_open(_vn_open+0x10)
> > >       _sys_open(_sys_open+0x10)
> > >       _syscall(_syscall+0x10)
> > >       db>
> >
> > I get a very similar output with a fresh -current (and Richard
> > Earnshaws wdc patch). The wdc patch made the machine recognise the
> > discs, but then I got a panic. However, I've got _resethandler instead
> > of _prefetch_abort_handler in the above list.
> >
> > Also, I've got:
> >
> > panic: Branch to never-never land (zero)..... were (sic) dead
> > prior to the above.

I have the same problem as above on my riscpc(with the patch applied).I also
notice that there is a VERY long delay after the following two lines in the boot
sequence.......

     pioc0 at mainbus0 base 0xf6210000 - 0xf6212fff
     pioc0: SMC FDC37C665GT peripheral controller rev 2

.......before the wdc0 is found/identified and there is a similarly long delay
before wd0 is found/identified. They are, however correctly found and identified.
I also notice that atapibus0 doesn't seem to be found

Once wd0 has been found, the sequence continues normally(even identifying both
drives on the ICS IDE interface) until it reaches:

     root file system type: ffs

     doing automatic file system check (or something)

     /dev/rwd0a: file system is clean not checking
     /dev/rwd0e: file system is clean not checking
     Trapframe at 0xf3673bf0
     panic: branch to never-never land (zero)...... were dead
     stopped in fsck at _Debugger+0x10: ldmb r11, {r11, r13, r15}
     db> trace
     _Debugger(_Debugger+0x10)
     _panic(_panic+0x14)
     _resethandler(_resethandler+0x10)
     _wdc_ata_bio_start(_wdc_ata_bio_start+0x10)
     _wdc_ata_ctrl_intr(_wdc_ata_ctrl_intr+0x10)
     _wdcintr(_wdcintr+0x10)
     _icside_intr(_icside_intr+0x10)
     _malloc(_malloc+0x10)
     _pmap_create(_pmap_create+0x10)
     _uvmspace_init(_uvmspace_init+0x10)
     _uvmspace_alloc(_uvmspace_alloc+0x10)
     _uvmspace_exec(_uvmspace_exec+0x10)
     _sysexecve(_sysexecve+0x10)
     _syscall(_syscall+0x10)
     db>

The last working kernel that I was able to compile gives the following boot
messages

     Oct 28 18:54:36 oak syslogd: restart
     Oct 28 18:54:37 oak /netbsd: NetBSD 1.3H (OAK) #3: Mon Oct 12 09:30:11
     BST 1998
     Oct 28 18:54:37 oak /netbsd:
     root@oak.largesalad.co.uk:/home/src/sys/arch/arm32/compile/OAK
     Oct 28 18:54:37 oak /netbsd: real mem  = 33554432
     Oct 28 18:54:37 oak /netbsd: avail mem = 27209728
     Oct 28 18:54:37 oak /netbsd: using 307 buffers containing 1781760 bytes
     of memory
     Oct 28 18:54:37 oak /netbsd: mainbus0 (root)
     Oct 28 18:54:37 oak /netbsd: cpu0 at mainbus0: ARM610 rev 4 IDC enabled
     WB enabled EABT
     Oct 28 18:54:38 oak /netbsd: pioc0 at mainbus0 base
     0xf6210000-0xf6212fff
     Oct 28 18:54:38 oak /netbsd: pioc0: SMC FDC37C665GT peripheral
     controller rev 2
     Oct 28 18:54:38 oak /netbsd: wdc0 at pioc0 offset 0x1f0-0x1f7 irq 9
     Oct 28 18:54:38 oak /netbsd: atapibus0 at wdc0
     Oct 28 18:54:38 oak /netbsd: wd0 at wdc0 drive 0: <Conner Peripherals
     850MB - CFS850A>
     Oct 28 18:54:38 oak /netbsd: wd0: using 16-sector 16-bit pio transfers,
     lba mode
     Oct 28 18:54:38 oak /netbsd: wd0 812MB, 1651 cyl, 16 head, 63 sec, 512
     bytes/sect x 1664583 sectors
     Oct 28 18:54:38 oak /netbsd: fdc0 at pioc0 offset 0x3f0-0x3f7 irq 12 drq
     0x00002000
     Oct 28 18:54:38 oak /netbsd: fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head,
     18 sec
     Oct 28 18:54:38 oak /netbsd: com0 at pioc0 offset 0x3f8-0x3ff irq 10:
     ns16550a, working fifo
     Oct 28 18:54:38 oak /netbsd: lpt0 at pioc0 offset 0x278-0x27b irq 0
     Oct 28 18:54:38 oak /netbsd: iomd0 at mainbus0: RPC IOMD
     Oct 28 18:54:38 oak /netbsd: iomd0: DRAM refresh=16us
     Oct 28 18:54:38 oak /netbsd: clock0 at iomd0
     Oct 28 18:54:38 oak /netbsd: kbd0 at iomd0
     Oct 28 18:54:38 oak /netbsd: iic0 at iomd0
     Oct 28 18:54:38 oak /netbsd: rtc0 at iic0 addr 0xa0: PCF8583 clock base
     32.768KHz
     Oct 28 18:54:38 oak /netbsd: todclock0 at rtc0
     Oct 28 18:54:38 oak /netbsd: qms0 at iomd0
     Oct 28 18:54:38 oak /netbsd: vidc0 at mainbus0: vidc20
     Oct 28 18:54:38 oak /netbsd: beep0 at vidc0
     Oct 28 18:54:38 oak /netbsd: vidcaudio0 at vidc0
     Oct 28 18:54:38 oak /netbsd: audio0 at vidcaudio0
     Oct 28 18:54:38 oak /netbsd: vidcvideo0 at vidc0: refclk=24MHz 1024KB
     VRAM
     Oct 28 18:54:39 oak /netbsd: vt0 at vidc0: console driver [V203E] using
     vt100 VIDC
     Oct 28 18:54:39 oak /netbsd: vt1 at vidc0: console driver [V203E] using
     vt100 VIDC
     Oct 28 18:54:39 oak /netbsd: vt2 at vidc0: console driver [V203E] using
     vt100 VIDC
     Oct 28 18:54:39 oak /netbsd: vt3 at vidc0: console driver [V203E] using
     vt100 VIDC
     Oct 28 18:54:39 oak /netbsd: vt4 at vidc0: console driver [V203E] using
     vt100 VIDC
     Oct 28 18:54:39 oak /netbsd: vt5 at vidc0: console driver [V203E] using
     vt100 VIDC
     Oct 28 18:54:39 oak /netbsd: sysbeep0 at vidc0
     Oct 28 18:54:39 oak /netbsd: podulebus0 (root)
     Oct 28 18:54:39 oak /netbsd: podule0  at podulebus0 : ICS : IDE
     Interface : IDE Interface
     Oct 28 18:54:39 oak /netbsd: icside0 at podulebus0 [ podule 0 ]: ARCIN
     V5
     Oct 28 18:54:39 oak /netbsd: wdc1 at icside0: primary channel
     Oct 28 18:54:39 oak /netbsd: atapibus1 at wdc1
     Oct 28 18:54:39 oak /netbsd: wd1 at wdc1 drive 0: <WDC AC31600H>
     Oct 28 18:54:39 oak /netbsd: wd1: using 16-sector 16-bit pio transfers,
     lba mode
     Oct 28 18:54:39 oak /netbsd: wd1 1549MB, 3148 cyl, 16 head, 63 sec, 512
     bytes/sect x 3173184 sectors
     Oct 28 18:54:39 oak /netbsd: wd2 at wdc1 drive 1: <H3342-A4>
     Oct 28 18:54:39 oak /netbsd: wd2: using 1-sector 16-bit pio transfers,
     chs mode
     Oct 28 18:54:39 oak /netbsd: wd2 327MB, 872 cyl, 16 head, 48 sec, 512
     bytes/sect x 669696 sectors
     Oct 28 18:54:39 oak /netbsd: ipl_bio=00108409 ipl_net=00100400
     ipl_tty=00100400 ipl_imp=00100400
     Oct 28 18:54:39 oak /netbsd: ipl_audio=00000400 ipl_imp=00000400
     ipl_high=00000400 ipl_serial=00000000
     Oct 28 18:54:39 oak /netbsd: lpt0: out of paper
     Oct 28 18:54:40 oak /netbsd: clock: hz=100 stathz = 0 profhz = 0
     Oct 28 18:54:40 oak /netbsd: md0: allocated 0K (0 blocks)
     Oct 28 18:54:40 oak /netbsd: boot device: wd0
     Oct 28 18:54:40 oak /netbsd: root on wd0a dumps on wd0b
     Oct 28 18:54:40 oak /netbsd: inittodr: 18:54:19.9600 28/10/1998
     Oct 28 18:54:40 oak /netbsd: Clock has gained 0 days 0 hours 6 minutes
     24 secs
     Oct 28 18:54:40 oak /netbsd: root file system type: ffs
     Oct 28 18:54:40 oak /netbsd:
     Oct 28 18:56:22 oak savecore: no core dump

This kernel is compiled from sources supped overnight 11th October and even this
would not get past the secondary bootstrap without lots of printf statements in
the relevant sections of rpc_machdep.c - don't ask me why just putting printf
staements in should make a difference, but they do - and they are still required.

A kernel built from last night's sources with an unmodified rpc_machdep.c still
locks up at the secondary bootstrap phase, whereas putting my printf debugging
statements in give a kernel as described at the top.

If anyone needs any more info, let me know.

regards,
Dave
--
Make it idiot-proof and someone will make a better idiot!

e-mail: dmillen@largesalad.co.uk
net: http://www.largesalad.co.uk/DJMsoft/