Need testers with MESH SCSI

Need testers with MESH SCSI

[Benjamin Herrenschmidt]

I need some feedback about the following change to the MESH driver. Does
it fix previously non-working configurations ? Does it break currently
working configurations ?

in drivers/scsi/mesh.c, replace the mesh_init function with:

static void mesh_init(struct mesh_state *ms)
{
    volatile struct mesh_regs *mr = ms->mesh;
    volatile struct dbdma_regs *md = ms->dma;

    udelay(100);

    /* Reset DBDMA & mask interrupts */
    out_le32(&md->control, (RUN|PAUSE|FLUSH|WAKE) << 16);
    out_8(&mr->intr_mask, 0);

    /* Pre-reset mesh to make sure it's in an approx. sane state */
    out_8(&mr->exception, 0xff);	/* clear all exception bits */
    out_8(&mr->error, 0xff);	/* clear all error bits */
    out_8(&mr->sequence, SEQ_RESETMESH);
    (void)in_8(&mr->sequence);
    udelay(10);

    /* Reset bus */
    out_8(&mr->bus_status1, BS1_RST);
    (void)in_8(&mr->bus_status1);
    udelay(30);
    out_8(&mr->bus_status1, 0);
    (void)in_8(&mr->bus_status1);

    /* Let bus and some devices settle down (Apple) */
    mdelay(250);

    /* Reset MESH again (for real), clear any error occured during
     * bus reset
     */
    out_8(&mr->exception, 0xff);	/* clear all exception bits */
    out_8(&mr->error, 0xff);	/* clear all error bits */
    out_8(&mr->sequence, SEQ_RESETMESH);
    (void)in_8(&mr->sequence);
    udelay(10);
    out_8(&mr->sequence, SEQ_FLUSHFIFO);
    (void)in_8(&mr->sequence);
    udelay(1);

    /* Initialize the chip */
    out_8(&mr->error, 0xff);	/* clear all error bits */
    out_8(&mr->interrupt, 0xff);	/* clear all interrupt bits */
    out_8(&mr->intr_mask, INT_ERROR | INT_EXCEPTION | INT_CMDDONE);
    out_8(&mr->source_id, ms->host->this_id);
    out_8(&mr->sel_timeout, 25);	/* 250ms */
    out_8(&mr->sync_params, ASYNC_PARAMS);	 /* asynchronous initially */
}


Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Geert Uytterhoeven]

On Thu, 21 Dec 2000, Benjamin Herrenschmidt wrote:
> I need some feedback about the following change to the MESH driver. Does
> it fix previously non-working configurations ? Does it break currently
> working configurations ?

Doesn't make a difference for me. This is on a CHRP LongTrail with Apple Hydra
Mac I/O and one disk on the MESH chain:

    Host: scsi1 Channel: 00 Id: 05 Lun: 00
      Vendor: QUANTUM  Model: FIREBALL_TM3200S Rev: 300X
      Type:   Direct-Access                    ANSI SCSI revision: 02

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Michael Schmitz]

> On Thu, 21 Dec 2000, Benjamin Herrenschmidt wrote:
> > I need some feedback about the following change to the MESH driver. Does
> > it fix previously non-working configurations ? Does it break currently
> > working configurations ?
>
> Doesn't make a difference for me. This is on a CHRP LongTrail with Apple Hydra
> Mac I/O and one disk on the MESH chain:

Neither does it change anything for me (Lombard, SCSI Zip and Quantum
VP32210). I've not tried to force any bus resets or something weird
though.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Benjamin Herrenschmidt]

>Neither does it change anything for me (Lombard, SCSI Zip and Quantum
>VP32210). I've not tried to force any bus resets or something weird
>though.

Well, I didn't change mesh_reset(), only mesh_init(). Since it seem that
it doesn't break working configs but actually fix some non working ones,
I'll push it one of these days.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Michael Schmitz]

> >Neither does it change anything for me (Lombard, SCSI Zip and Quantum
> >VP32210). I've not tried to force any bus resets or something weird
> >though.
>
> Well, I didn't change mesh_reset(), only mesh_init(). Since it seem that

I saw mesh_init called in more than one spot on a quick glance over the
source and must have incorrectly assumed it's also used on bus or host
reset.

> it doesn't break working configs but actually fix some non working ones,
> I'll push it one of these days.

In case it wasn't obvious: my setup was working perfectly fine even before
the patch :-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Wolfgang Haeuptli]

Well, would have been a nice christmas present... BUT STILL:
(after applying the new mesh_init() to scsi/mesh.c)

mesh: target 6 aborted

which means that my UMAX Astra 1200S Scanner still does not work under
linuxppc...

My System: Performa 6400, Kernel 2.2.15pre19

(a couple of months ago I found a message on the list how to enable
scsi-debugging/logging, which magically made the scanner work -- slow and lots
of debugs in log/messages. There must be a better way...)

Greetings

Wolfgang Haeuptli

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Benjamin Herrenschmidt]

>
>Well, would have been a nice christmas present... BUT STILL:
>(after applying the new mesh_init() to scsi/mesh.c)
>
>mesh: target 6 aborted
>
>which means that my UMAX Astra 1200S Scanner still does not work under
>linuxppc...

Can you try increasing the udelay() calls in mesh_init() to see if it
helps ? There maybe something else going on, but it's worth trying.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Geert Uytterhoeven]

On Fri, 22 Dec 2000, Benjamin Herrenschmidt wrote:
> >Well, would have been a nice christmas present... BUT STILL:
> >(after applying the new mesh_init() to scsi/mesh.c)
> >
> >mesh: target 6 aborted
> >
> >which means that my UMAX Astra 1200S Scanner still does not work under
> >linuxppc...
>
> Can you try increasing the udelay() calls in mesh_init() to see if it
> helps ? There maybe something else going on, but it's worth trying.

Note that there can be other problems with the mesh as well: I remember I once
had some early 2.3.x kernels that could not init the mesh when cold-booted,
only when warm-booted. So I had to boot an older kernel first each time I had
powered down my box :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Benjamin Herrenschmidt]

>Note that there can be other problems with the mesh as well: I remember
I once
>had some early 2.3.x kernels that could not init the mesh when cold-booted,
>only when warm-booted. So I had to boot an older kernel first each time I had
>powered down my box :-)

There were issues with powering up the MESH on some powerbooks that were
fixed some time ago, but maybe your issue is unrelated.

Looking at Darwin's MESH driver, they have a whole bunch of workarounds
for known issues (either with common device protocol errors, or MESH
internal races).

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Need testers with MESH SCSI

[Geert Uytterhoeven]

On Tue, 26 Dec 2000, Benjamin Herrenschmidt wrote:
> >Note that there can be other problems with the mesh as well: I remember
> I once
> >had some early 2.3.x kernels that could not init the mesh when cold-booted,
> >only when warm-booted. So I had to boot an older kernel first each time I had
> >powered down my box :-)
>
> There were issues with powering up the MESH on some powerbooks that were
> fixed some time ago, but maybe your issue is unrelated.

Yes, since I don't have a Powerbook, but a LongTrail.

> Looking at Darwin's MESH driver, they have a whole bunch of workarounds
> for known issues (either with common device protocol errors, or MESH
> internal races).

I still see the

    mesh: halt_dma: data_ptr=-256 (nb=20736, ms=c06ff278)

(i.e. the DMA ptr shows it did 256 bytes too much), but I never noticed any
file corruption during the 3.5 years I've been using this machine. Let's call
it a harmless hardware bug.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/