Doug Ledford wrote:
>
> Josef Moellers wrote:
> >
> > Hi,
> >
> > Since noone really seems to be maintaining the aic7xxx code (Doug
> > Ledford seems too busy), I'll try here.
>
> First, changing the sequencer code does no good unless you also recompile it.
> The sequencer compiler is not included in the source code distribution in the
I know that. I took the FBSD sequencer compiler and ported it to Linux.
That way I was able to incorporate the fix into a locally built aic7xxx
module and it worked.
> linux kernel. As far as me being too busy to do this, it's already done
> (correctly I might add, the section below is insufficient for proper
> operation) in the 5.1.29 driver. What you are really complaining about is
> that I haven't forward ported the 5.1.29 driver to 2.3 kernels yet. Tough,
> I'll do it as fast as I can, but forward porting the driver is secondary to
> making the driver work properly in all the cases I can test/get reports on.
If I can assist in any testing, I'd be happy to do so.
> > There is a bug in the aic7xxx sequencer code that has been confirmed by
> > Justin Gibbs, the FBSD developer of the sequencer code, who also sent me
> > the fix included. The bug prevents proper operation of Ultra160 devices
> > on an AIC7899 based HA.
>
> That should read "some Ultra160 devices" and in actuality it effects more old
> SCSI-I devices than it does Ultra160 devices.
Fact is, it was an Ultra160 LVD device that was causing problems (a GEM
chip). When we replaced the card with a single-ended purely asynchronous
card, the fault disappeared. First we thought it was a problem of the
GEM chip, but further analysis showed that there was no event whatsoever
that would cause the protocol violation and also the protocol was
violated by the initiator (AIC7899) rather than the target (GEM).
Tha main reason for my complaint is that when we joined the Linux crowd,
we found that there were some incompatibilities between our (large)
Int*l based machines and the various components of the Linux
distributions: we had to re-design LILO, because the Phoenix BIOS used
the upper end of base memory for storing the SMP config table (ask Zach
Brown), we had to work on the memory management initialization because
of the same problem, another bug in the mm initialization prevented the
system from using base memory (beats me why this hasn't surfaced
earlier). We had to build custom installation floppy images, kernel
patches, pre-compiled modules etc to get our customers to be able to
install Linux on our machines.
This time, I thought, I'd get the bug fixed _before_ a stable production
kernel was built by mailing the maintainer in person and, later, mailing
to a mailing list.
Sorry if I let the pressure that was put onto me influence my language.
I didn't want to be rude, perhaps provocative, but not rude. I'm having
a hard time keeping management from cutting down our Linux engagement.
Again, I'm sorry if I offended you.
--
Josef M�llers
Fujitsu Siemens Computers
SHV Server DS 1
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
