Subject: Re: problem in atapi_wdc.c(?)... thoughts?
To: Manuel Bouyer <firstname.lastname@example.org>
From: Matthew Jacob <email@example.com>
Date: 03/29/1999 08:40:56
> > 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 ?
> > 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).