Subject: problem in atapi_wdc.c(?)... thoughts?
To: None <tech-kern@netbsd.org>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 03/24/1999 17:37:10
I ran into this problem with a spun-off variant of NetBSD-1.3, but the
same problem may exist in -current, and I thought I'd ask some folks'
opinions about it rather than just 'fixing' it....

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);

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)...

-matt