Could you try the following (you'll need to revert the previous patch). Is it legitimate to have holes in the list of MSCP devices on a controller - eg, unit 0, then unit 2 but no unit 1? btw - Tom, do you tend to use IRC or any other IM channel? :) On 27 June 2012 15:52, David Brownlee <abs%netbsd.org@localhost> wrote: > On 27 June 2012 15:44, Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost> > wrote: >> David Brownlee <abs%netbsd.org@localhost> writes: >> >>> Tom - could you try the following patch on your system? >> >> Of course. :) >> >> mtc0 at uba0 csr 174500 vec 774 ipl 17 >> mscpbus0 at mtc0: version 4 model 14 >> mscpbus0: DMA burst size set to 4 >> DBGX: 0 wait for slavereply >> DBGX: 0 stash slavereply >> DBGX: 0 use slavereply >> DBGX: 1 wait for slavereply >> DBGX: 0 stash slavereply >> DBGX: 0 use slavereply >> uda0 at uba0 csr 172150 vec 770 ipl 17 >> mscpbus1 at uda0: version 6 model 13 >> mscpbus1: DMA burst size set to 4 >> DBGX: 0 wait for slavereply >> DBGX: 0 stash slavereply >> DBGX: 0 use slavereply >> DBGX: 1 wait for slavereply >> DBGX: 0 stash slavereply >> DBGX: 0 use slavereply >> mt0 at mscpbus0 drive 0: TK70 >> mt1 at mscpbus0 drive 0: TK70 >> ra0 at mscpbus1 drive 0: RA90 >> ra1 at mscpbus1 drive 0: RA90 >> boot device: ra1 >> root on ra1a dumps on ra1b >> root on ra1a dumps on ra1b >> root file system type: ffs >> >> There's a long wait between "ra1 at ..." and "boot device: ra1". > > I wonder.... if we ask for a drive that doesn't exist do we always end > up with 0 in the mscp_unit slave reply... > > (one moment)
Attachment:
diffs2
Description: Binary data