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.