> > We had configured a kernel with a very large MAXPHYS (1024k). The old
> > isa_wdc.c driver minphys's based upon a define called MAX_SIZE,  which was
> > derived from MAXPHYS. Umm.. bad problem here because transfers larger than
> > 64K just seemed to plain fail without warning- at least that was the
> > symptom. It was, btw, the funniest darn way I found out- savecore(8) was
> > failing because it tries to read the dump area in 1024K chunks, and it was
> > just failing with an EINVAL.. and in finally examing isadma I saw where
> > this was coming from:
> > 
> >         if (chan & 4) 
> >                 maxsize = (1 << 17);
> >         else
> >                 maxsize = (1 << 16);
> 
> Hum, if I understand what you said properly, the problem only arize if we are
> using ISA DMA, isn't it ?

yes.

> 
> > 
> > So- upon looking what's in -current, the same problem sort of applies- in
> > dev/scsipi/atapi_wdc.c- or possibly isa/wdc_isa.c (the whole glue of how
> > this fits together I really have never pursued ...)
> > 
> > Now, here's the meat of the question- how should this be fixed? There
> > doesn't appear to be enough information available to atapi_wdc.c to decide
> > whether or not MAX_SIZD should be 64k, 128k, or an arbitrary size, since
> > that information is hidden from it. Would it simply be safe to limit it to
> > 64k? But what about PIO xfers then? I'm a little reluctant to just leap in
> > and 'fix' this because of this. This end of I/O isn't really quite my area
> > of expertise (if I have any at all)...
> > 
> 
> This is a problem for both ata_wdc.c and atapi_wdc.c. This limitation could
> be passed from the bus front-end, it is the only one who knows about it
> (this really depends on the bus, pciide shoul'nt have it, for example).
> The real problem here is to get this information from isadma to
> wdc_isa.c (or wdc_isapnp.c).
> 


Exactly so.