linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@cs.anu.edu.au>
To: Geert.Uytterhoeven@cs.kuleuven.ac.be
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: MESH problems in 2.2.x
Date: Wed, 14 Jul 1999 15:09:21 +1000	[thread overview]
Message-ID: <199907140509.PAA21467@tango.anu.edu.au> (raw)
In-Reply-To: <Pine.LNX.4.10.9907131538530.6336-100000@mercator.cs.kuleuven.ac.be> (message from Geert Uytterhoeven on Tue, 13 Jul 1999 15:45:54 +0200 (CEST))


Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

> Just made some diff between 2.1.130 and the `broken' kernels. The following
> two things make me suspicious:
> 
> Index: drivers/scsi/mesh.c
> @@ -1643,6 +1643,7 @@
>  static void
>  mesh_completed(struct mesh_state *ms, Scsi_Cmnd *cmd)
>  {
> +#if 0
>  	if (ms->completed_q == NULL)
>  		ms->completed_q = cmd;
>  	else
> @@ -1651,6 +1652,9 @@
>  	cmd->host_scribble = NULL;
>  	queue_task(&ms->tqueue, &tq_immediate);
>  	mark_bh(IMMEDIATE_BH);
> +#else
> +	(*cmd->scsi_done)(cmd);
> +#endif
>  }
>  
>  /*
> 
> Why did Dave (mesh.c 1.20, according to the vger CVS logs, which don't help me
> much) do this?

I made that change, I think maybe I sent it straight to Linus and it
got into vger via the official releases or something.

The point was that I realized, looking at the scsi code (which has
changed quite a bit since I wrote the original mesh driver) that the
scsi done routine was going to schedule a BH handler anyway so there
was no point in mesh.c having complexity to arrange for that.  I was
cleaning up the SMP locking in mesh.c at the time and making that
change was an alternative to getting the locking right for the
completed_q stuff.

> Index: drivers/scsi/scsi_obsolete.c
> @@ -354,6 +357,18 @@
>      printk("In scsi_done(host = %d, result = %06x)\n", host->host_no, result);
>  #endif
>  
> +    if(SCpnt->flags & SYNC_RESET)
> +    {
> +        /*
> +        * The behaviou of scsi_reset(SYNC) was changed in 2.1.? .
> +        * The scsi mid-layer does a REDO after every sync reset, the driver
> +        * must not do that any more. In order to prevent old drivers from
> +        * crashing, all scsi_done() calls during sync resets are ignored.
> +        */
> +        printk("scsi%d: device driver called scsi_done() "
> +	       "for a syncronous reset.\n", SCpnt->host->host_no);
> +        return;
> +    }
>      if(SCpnt->flags & WAS_SENSE)
>      {
>  	SCpnt->use_sg = SCpnt->old_use_sg;
> 
> And after the `return', my machine no longer does anything...

The mesh driver really needs someone to go through and update the
abort and reset handling to the new way.  The first problem is of
course to work out exactly how the scsi mid-layer expects host adaptor
drivers to behave... :-)

> Things are a bit difficult now, because I no longer have Internet connectivity
> on my boxes. DDS 2 GB packets with high latency form my sole link now :-(

The latency sucks, but the bandwidth is phenomenal, right? :-) :-)

Paul.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

  reply	other threads:[~1999-07-14  5:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-02  8:47 MESH problems in 2.2.x Geert Uytterhoeven
1999-06-03  5:46 ` Paul Mackerras
1999-06-07 11:10   ` Geert Uytterhoeven
1999-06-22 13:00     ` Geert Uytterhoeven
1999-06-23 12:13       ` Michel Lanners
1999-06-24  7:53         ` Geert Uytterhoeven
1999-06-24 21:44           ` Michel Lanners
1999-07-13 13:45       ` Geert Uytterhoeven
1999-07-14  5:09         ` Paul Mackerras [this message]
1999-07-14  8:03           ` Geert Uytterhoeven
1999-07-15  8:45           ` Geert Uytterhoeven
1999-08-02 11:14             ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199907140509.PAA21467@tango.anu.edu.au \
    --to=paulus@cs.anu.edu.au \
    --cc=Geert.Uytterhoeven@cs.kuleuven.ac.be \
    --cc=Paul.Mackerras@cs.anu.edu.au \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).