I've cc'd current-users, since this might be a generic problem with the 
new wd driver.

> 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.......

The symptoms are similar, but I don't think it's the same problem.

> 
>      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

I'm not sure, but I think the new driver only attaches an atapibus if 
there is an atapi device attached to the wdc.  You seem to have two wd 
disks.

> 
> 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)
        ^^^^^^^^^^^^
 This is the jump through address zero (the reset handler)

>      _wdc_ata_bio_start(_wdc_ata_bio_start+0x10)
       ^^^^^^^^^^^^^^^^^^^
This is what called it.

>      _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
> 
...
> 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.
> 

Looking at the source for wdc_ata_bio_start, there only seem to be two 
"pointer-to-function" calls, both of which will (should) only occur if DMA 
is being used (which it shouldn't be on an RPC -- unfortunately :-( ).

You might be able to get more info if you rebuild ata_wdc.c and wdc.c with 
debugging flags on -- be warned this will really generate a lot of text.

Richard.