Re: HEADs up - gcc 4.1 reversion & MSCP CD changes in current

[Anders Magnusson <ragge%ludd.ltu.se@localhost>]

Hi,

sorry to jump in late; MSCP devices can be between 0-4095, with holes 
inbetween numbers.
There may be many places in the mscp code that assumes that things are 
done in sequence.
I may have a look at it this weekend.

-- Ragge

On 06/27/2012 05:17 PM, David Brownlee wrote:
> 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)