[ On Monday, December 6, 2004 at 00:28:13 (+0100), Manuel Bouyer wrote: ]
> Subject: Re: port-i386/17900: panic/system hang with Adaptec aic7889 SCSI controller
>
> Not really, the FreeBSD and NetBSD kernel are so different in this area that
> this can't be done mechanically. It really has to be done by someone who
> knows what he his doing.

The driver's pretty well split into OS specific and OS independent parts
as far as I can see and though the APIs between the two are the problem,
it might be a smaller problem than you might think.  That's just
speculation on my part of course since I've not done the port and only
looked at the diffs from a very high level.  :-)

But anyway perhaps if someone who knew what they were doing worked more
closely with Justin then the FreeBSD sources could be even better
architected into OS-spec. and OS-ind. parts with more stable interfaces
between to make such porting even easier in the future.  ;-)


> I won't request pullup for this. It's not clear that there has been no
> regression between the old and new driver (there are still open PRs about
> this),

You should actually check with the authors of those other PRs to confirm
that their problems were in fact real and due specifically to the new
driver -- most of those very few complaints were quite vaugue IIRC,
though I've lost track of my list of the relevant PRs.

You might also find if the latest FreeBSD code were re-ported that any
of the real device specific bugs have already been fixed there.


> and I don't have the hardware to test anyway.

Many people do have the hardware to test the pullups on though, and if
the pullups were done then it would be very easy for many more of those
people to do the tests themselves.  It seems that many of those who
follow the netbsd-1-6 branch regularly are still reluctant to make as
"radical" a change to their local source tree as I've done with my own
private pullup -- and their fears seem not to be that they'll break
something but rather only that their workload will go up.  If the
pullups are done in the official branch then they'll be able to test
them safely as part of their normal testing procedures and with no
additional effort required on their part.

Presumably there's lots of time before the 1.6.3 freeze to work out the
necessary fixes should any regression problems crop up.

I think this is a chicken & egg thing -- if the pullups are not done
then nobody who hasn't been eager enough to have already used my
instructions will bother to do any further testing.  That's been
apparent in the reaction I've seen any time I suggest anyone follow my
instructions to do their own private pullup.

As far as I have seen from the lack of ongoing PRs about it, this driver
has been running much better for everyone in -current than the previous
version did, and it has also worked very well in 1.6.x systems for
myself and all those few who've followed my instructions, and for a very
long time now.

On the other hand the driver still in 1.6 is totally useless on a very
large number of more recent systems -- often making NetBSD-1.6 totally
useless many of on those same systems since the cost of supplanting the
integrated hardware is prohibitive.  As I'm sure you know lots of people
don't run -current and I suspsect quite a few would also really prefer
to stick with the 1.6 branch until 2.0.1, if not until 2.1.  If 1.6.3
had this new driver I think a lot of people would be much happier with
how NetBSD is supported for production use.

Note the only thing that I think is missing from my instructions is the
associated AHD driver, but it should be the same simple copy and paste
effort as it was for the main AHC driver.


> Get the vendor to release docs for this hardware, and we'll be able to
> do something clean.

I think the vendor already does publish everything needed in the form of
an open-source, well documented, and excellently and professionally
supported driver; one that we already make "clean" use of as far as I
can see.  If you want to reinvent the wheel for yourself then be my
guest, but in the mean time it would be really helpful if NetBSD made
better use of the available driver resources for these incredibly widely
used and useful devices.  Blaming a vendor that's already provided
excellent support to the Open Source comminity isn't necessarily a good
thing to do.

Besides I'm sure you can talk to Justin as easily, if not more easily,
than I can.  He's friendly and helpful.  :-)

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>