Re: Final pre-2.0.31.. Expect this to be same as real 2.0.31

Doug Ledford (
Wed, 10 Sep 1997 13:03:01 -0500


> > The other thing that is unusual is the Sending SDTR!! messages. Do you
> > happen to have Synchronous negotiation disabled on that device in your
> > Adaptec setup? If so, you should enable it, as our negotiation routines are
> > much more reliable when we start the negotiation instead of the device
> > starting the negotiation (this is a limitation of the amount of code space
> > we have in the sequencer).

> On both disks (WDE 4360) there is a jumper "disable target initiated
> synchronous/wide negotiation" which I left open (default). That means the
> disks may initiate synchronous negotiations and probably do it before the
> controller.

Ugghh....disable that "feature". For other SCSI controllers that would be
fine, with the limited sequencer space we have on the aic7xxx chipsets, we
don't have the instruction room to be truly deterministic about negotiation
that is initiated by the target. We need to initiate negotiation.

> first no problems for a long time
> then known already SCSI timeouts
> then SCSI bus reset
> followed immediately by lots of "can not allocate skb of size 64" (or 1066)
> after 2-3 seconds Aiee: scheduling in interrupt 0012b118 (or 0012b8d5)
> scrolling very fast (end of story, hard reset)
> using "v-20" (value of 50) and ping -s -f 1024 from otherhost I got again
> SCSI reset, then "could not allocate skbuf of size 1066" scrolling, then
> kernel panic: aicxxxx : unable to proceed with device negotiation.
> and then after 20 seconds:
> Aiee: scheduling in interrupt 0012b118
> (hard reset)
> This "unable to proceed with device negotiation" is called in aicxxxx.c in
> two places, always because atomic memory allocation fails.

Yep, we shouldn't be letting ourselves get so low on RAM that we fail the
occasional atomic memory allocation. Especially when they aren't very large
in size.

> And now the best part of the story. I have applied the patch I got from
> Werner on top of "v-20" and got "v-21". I have made two standard tests
> without external ping (once without any warnings, once with only one SCSI
> reset)
> I have made also three tests with external ping -f -s 1024 myhost. All of
> tests completed without any problems (no SCSI timeuts). The bonnies output
> has shown that output transfer rate was even slightly faster. Block
> inputs are slightly slower, but "getc" input is faster.

Sounds like Werner's latest patch helps to avoid the failure to allocate
atomic memory problem.

* Doug Ledford                      *   Unix, Novell, Dos, Windows 3.x,     *
*    873-DIAL  *     WfW, Windows 95 & NT Technician   *
*   PPP access $14.95/month         *****************************************
*   Springfield, MO and surrounding * Usenet news, e-mail and shell account.*
*   communities.  Sign-up online at * Web page creation and hosting, other  *
*   873-9000 V.34                   * services available, call for info.    *