MESH problems in 2.2.x

MESH problems in 2.2.x

[Geert Uytterhoeven]

	Hi,

During boot up I now see the message:

    scsi1: device driver called scsi_done() for a syncronous reset

during SCSI probe, followed by nothing (Caps Lock still toggles the LED, so the
machine is alive).

scsi0 is sym53c875, scsi1 is mesh. Kernel is either 2.2.4 or 2.2.7.


What happens to my box: I had following devices on my SCSI chains:

  - scsi0 (sym53c875) wide chain:
      o id 0: QUANTUM VIKING II 4.5WLS (FAST-20 WIDE)
  - scsi0 (sym53c875) narrow chain:
      o id 3: PLEXTOR CD-ROM PX-12TS (FAST-10)
      o id 4: HP HP35480A (FAST-5)
      o id 5: QUANTUM FIREBALL_TM3200S (FAST-20)

  - scsi1 (mesh) narrow chain:
      o id 0: CONNER CP3040A-40mb-3.5

This worked fine with all kernels I tested (up to 2.2.7, 2.2.8 and beyond don't
boot on CHRP LongTrail, which is was investigating when the disaster mentioned
below happens). I used the Conner to boot from using Open Firmware (no OF
driver for the sym53c875).

Then the Conner died :-( To be able to boot (I can no longer boot from floppy
due to media errors, aarghl...), I moved the narrow chain from the sym875 to
the mesh, and I was able to boot an old kernel (2.1.130):

  - scsi0 (sym53c875) wide chain:
      o id 0: QUANTUM VIKING II 4.5WLS (FAST-20 WIDE)

  - scsi1 (mesh) narrow chain:
      o id 3: PLEXTOR CD-ROM PX-12TS (FAST-10)
      o id 4: HP HP35480A (FAST-5)
      o id 5: QUANTUM FIREBALL_TM3200S (FAST-20 capable running at FAST-10)

The weird thing is that 2.2.x kernels no longer boot. They hang during SCSI
probe with the message mentioned above. Then I moved most narrow devices to the
sym875 again (mesh sometimes looses arbitration when having multiple devices),
so I have my boot disk only at the mesh chain:

  - scsi0 (sym53c875) wide chain:
      o id 0: QUANTUM VIKING II 4.5WLS (FAST-20 WIDE)
  - scsi0 (sym53c875) narrow chain:
      o id 3: PLEXTOR CD-ROM PX-12TS (FAST-10)
      o id 4: HP HP35480A (FAST-5)

  - scsi1 (mesh) narrow chain:
      o id 5: QUANTUM FIREBALL_TM3200S (FAST-20 capable running at FAST-10)

Same happens: 2.1.130 works, 2.2.4 and 2.2.7 don't.

Since the message mentions `syncronous reset' and since the old Conner doesn't
seem to do synchronous mode, this makes me think the mesh driver fails with
synchronous devices in 2.2.x. Is this correct? Does anyone else see this
problem?

Well, now I have two problems to debug with 2.2.8 and above (or vger since a
few months) on my CHRP LongTrail:

  - it hangs after `instantiating rtas... done'
  - MESH hangs during probe

Happy hacking! ;-)

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ 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.   ]]

Re: MESH problems in 2.2.x

[Paul Mackerras]

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

> During boot up I now see the message:
> 
>     scsi1: device driver called scsi_done() for a syncronous reset

The reset and abort handling in the mesh driver needs to be updated;
the way the scsi mid-layer expects them to work changed during the 2.1
series but I haven't updated the mesh driver to the new way yet,
partly because I don't know exactly what the new way is. :-)

> Since the message mentions `syncronous reset' and since the old Conner doesn't
> seem to do synchronous mode, this makes me think the mesh driver fails with
> synchronous devices in 2.2.x. Is this correct? Does anyone else see this
> problem?

It's working OK for me now with a 2.3.4 kernel, having fixed ioremap
(the fix is now in vger for both the 2.2 and 2.3 branches).

If you want to disable sync mode, you could change the initializer for
mesh_sync_targets in drivers/scsi/mesh.c from 0xff to 0.

Regards,
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.   ]]

Re: MESH problems in 2.2.x

[Geert Uytterhoeven]

On Thu, 3 Jun 1999, Paul Mackerras wrote:
> Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:
> > During boot up I now see the message:
> > 
> >     scsi1: device driver called scsi_done() for a syncronous reset
> 
> The reset and abort handling in the mesh driver needs to be updated;
> the way the scsi mid-layer expects them to work changed during the 2.1
> series but I haven't updated the mesh driver to the new way yet,
> partly because I don't know exactly what the new way is. :-)
> 
> > Since the message mentions `syncronous reset' and since the old Conner doesn't
> > seem to do synchronous mode, this makes me think the mesh driver fails with
> > synchronous devices in 2.2.x. Is this correct? Does anyone else see this
> > problem?
> 
> It's working OK for me now with a 2.3.4 kernel, having fixed ioremap
> (the fix is now in vger for both the 2.2 and 2.3 branches).
> 
> If you want to disable sync mode, you could change the initializer for
> mesh_sync_targets in drivers/scsi/mesh.c from 0xff to 0.

This one seems to work.

Greetings,

				    Geert (nailing down other problems)

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ 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.   ]]

Re: MESH problems in 2.2.x

[Geert Uytterhoeven]

On Mon, 7 Jun 1999, Geert Uytterhoeven wrote:
> On Thu, 3 Jun 1999, Paul Mackerras wrote:
> > Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:
> > > During boot up I now see the message:
> > > 
> > >     scsi1: device driver called scsi_done() for a syncronous reset
> > 
> > The reset and abort handling in the mesh driver needs to be updated;
> > the way the scsi mid-layer expects them to work changed during the 2.1
> > series but I haven't updated the mesh driver to the new way yet,
> > partly because I don't know exactly what the new way is. :-)
> > 
> > > Since the message mentions `syncronous reset' and since the old Conner doesn't
> > > seem to do synchronous mode, this makes me think the mesh driver fails with
> > > synchronous devices in 2.2.x. Is this correct? Does anyone else see this
> > > problem?
> > 
> > It's working OK for me now with a 2.3.4 kernel, having fixed ioremap
> > (the fix is now in vger for both the 2.2 and 2.3 branches).
> > 
> > If you want to disable sync mode, you could change the initializer for
> > mesh_sync_targets in drivers/scsi/mesh.c from 0xff to 0.
> 
> This one seems to work.

But not perfect :-(

Since /me was stupid and told OF `boot scsi/disk@5:' (i.e. I forgot the file
part of the path), my OF kept on enjoying autoreboot cycles with `rebooting in
the correct mode for this client program' messages. The only thing that stopped
this was to remove the power from the scsi/disk@5 device. This was the first
time the power was removed since my previous mail about this.

And then I got

    scsi1: device driver called scsi_done() for a syncronous reset

again, booting 2.3.6 from vger-june15.

Fortunately I still had the working 2.1.130 kernel around. After I booted that
first, I was able to boot my 2.3.6 kernel.

So to boot recent kernels when you have sync-capable devices on the MESH, two
conditions have to be met:

  - boot 2.1.130 first
  - mesh_sync_targets = 0 (setting CONFIG_SCSI_MESH_SYNC_RATE=0 doesn't work)

Anyone else seeing this?

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ 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.   ]]

Re: MESH problems in 2.2.x

[Michel Lanners]

On  22 Jun, this message from Geert Uytterhoeven echoed through cyberspace:
> So to boot recent kernels when you have sync-capable devices on the MESH, two
> conditions have to be met:
> 
>   - boot 2.1.130 first
>   - mesh_sync_targets = 0 (setting CONFIG_SCSI_MESH_SYNC_RATE=0 doesn't work)
> 
> Anyone else seeing this?

No:

scsi0 : MESH
scsi1 : 53C94
scsi : 2 hosts.
mesh: target 1 synchronous at 10.0 MB/s
  Vendor: IBM       Model: DFHSS1F       !c  Rev: 1717
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 1, lun 0
mesh: target 2 synchronous at 10.0 MB/s
  Vendor: IBM       Model: DCAS-34330        Rev: S65A
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sdb at scsi0, channel 0, id 2, lun 0
mesh: target 3 synchronous at 5.0 MB/s
  Vendor: MATSHITA  Model: CD-ROM CR-8008    Rev: 8.0e
  Type:   CD-ROM                             ANSI SCSI revision: 02

Works perfectly well with kernel 2.2.8.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


[[ 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.   ]]

Re: MESH problems in 2.2.x

[Geert Uytterhoeven]

On Wed, 23 Jun 1999, Michel Lanners wrote:
> On  22 Jun, this message from Geert Uytterhoeven echoed through cyberspace:
> > So to boot recent kernels when you have sync-capable devices on the MESH, two
> > conditions have to be met:
> > 
> >   - boot 2.1.130 first
> >   - mesh_sync_targets = 0 (setting CONFIG_SCSI_MESH_SYNC_RATE=0 doesn't work)
> > 
> > Anyone else seeing this?
> 
> No:
> 
> scsi0 : MESH
> scsi1 : 53C94
> scsi : 2 hosts.
> mesh: target 1 synchronous at 10.0 MB/s
>   Vendor: IBM       Model: DFHSS1F       !c  Rev: 1717
>   Type:   Direct-Access                      ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 1, lun 0
> mesh: target 2 synchronous at 10.0 MB/s
>   Vendor: IBM       Model: DCAS-34330        Rev: S65A
>   Type:   Direct-Access                      ANSI SCSI revision: 02
> Detected scsi disk sdb at scsi0, channel 0, id 2, lun 0
> mesh: target 3 synchronous at 5.0 MB/s
>   Vendor: MATSHITA  Model: CD-ROM CR-8008    Rev: 8.0e
>   Type:   CD-ROM                             ANSI SCSI revision: 02

Then it's my QUANTUM FIREBALL_TM3200S 300X :-(

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ 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.   ]]

Re: MESH problems in 2.2.x

[Michel Lanners]

On  24 Jun, this message from Geert Uytterhoeven echoed through cyberspace:
>> > So to boot recent kernels when you have sync-capable devices on the MESH, two
>> > conditions have to be met:
>> > 
>> >   - boot 2.1.130 first
>> >   - mesh_sync_targets = 0 (setting CONFIG_SCSI_MESH_SYNC_RATE=0 doesn't work)
>> > 
>> > Anyone else seeing this?
>> 
>> No:
>> 
>> scsi0 : MESH
>> scsi1 : 53C94
>> scsi : 2 hosts.
>> mesh: target 1 synchronous at 10.0 MB/s
>>   Vendor: IBM       Model: DFHSS1F       !c  Rev: 1717
>>   Type:   Direct-Access                      ANSI SCSI revision: 02
>> Detected scsi disk sda at scsi0, channel 0, id 1, lun 0
[other drives deleted]

I might add that this is on a PowerMac 7600.

> Then it's my QUANTUM FIREBALL_TM3200S 300X :-(

Hmmm... I remember that in the early (and glorious ;-) days of MkLinux
DR2.1, there were lots of problems with the 7600's original internal
drives, being mostly Quantum Fireball TM1280S drives. I don't remeber
the problems clearly, but one of the solutions was to move the Quantum
drive to an ID different from 0. David Gatwood might remember what the
issue was....

On the other hand, I'm not sure the MESH in my 7600 is the same as the
one on your motherboard (except the name and the registers, maybe); so
that might be an explanation for your problems as well. For the record,
the MESH on the 7600 is integrated inside GrandCentral, an Apple ASIC
on the PCI bus, that handles the rst of the IO as well.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


[[ 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.   ]]

Re: MESH problems in 2.2.x

[Geert Uytterhoeven]

On Tue, 22 Jun 1999, Geert Uytterhoeven wrote:
> Since /me was stupid and told OF `boot scsi/disk@5:' (i.e. I forgot the file
> part of the path), my OF kept on enjoying autoreboot cycles with `rebooting in
> the correct mode for this client program' messages. The only thing that stopped
> this was to remove the power from the scsi/disk@5 device. This was the first
> time the power was removed since my previous mail about this.
> 
> And then I got
> 
>     scsi1: device driver called scsi_done() for a syncronous reset
> 
> again, booting 2.3.6 from vger-june15.
> 
> Fortunately I still had the working 2.1.130 kernel around. After I booted that
> first, I was able to boot my 2.3.6 kernel.
> 
> So to boot recent kernels when you have sync-capable devices on the MESH, two
> conditions have to be met:
> 
>   - boot 2.1.130 first
>   - mesh_sync_targets = 0 (setting CONFIG_SCSI_MESH_SYNC_RATE=0 doesn't work)

And subsequent reboots don't cause problems anymore. Next time the machine is
turned off, I need 2.1.130 again first before I can boot 2.3.6.

> Anyone else seeing this?

Thus not everyone is seeing this...

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?

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

I'll try to find out which one of the two guys causes my problems...

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 :-(

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium

[[ 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.   ]]

Re: MESH problems in 2.2.x

[Paul Mackerras]

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

Re: MESH problems in 2.2.x

[Geert Uytterhoeven]

On Wed, 14 Jul 1999, Paul Mackerras wrote:
> 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... :-)

I already have a feeling in my little toe who's gonna be the victim...

    push_on_job_queue("fix MESH driver");
    push_on_job_queue("study Linux SCSI subsystem");

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ 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.   ]]

Re: MESH problems in 2.2.x

[Geert Uytterhoeven]

On Wed, 14 Jul 1999, Paul Mackerras wrote:
> 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.

But on my UP box, changing the `#if 0' to `#if 1' fixed all my MESH
problems...

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ 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.   ]]

Re: MESH problems in 2.2.x

[Geert Uytterhoeven]

On Thu, 15 Jul 1999, Geert Uytterhoeven wrote:
> On Wed, 14 Jul 1999, Paul Mackerras wrote:
> > 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.
> 
> But on my UP box, changing the `#if 0' to `#if 1' fixed all my MESH
> problems...

Well, I've been too early...

After a power down of my Quantum Fireball TMS3200 I still have to boot a
2.1.130 first to avoid getting the `scsi_done()' messages under 2.3.x.
Intermittent soft reboots don't require this. Apart from that, the drive works
fine with FAST-10 under 2.3.{6,10}.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ 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.   ]]