mesh in 2.4.0-test1

mesh in 2.4.0-test1

[Geert Uytterhoeven]

Is there anyone who is succesfully using SCSI devices connected to MESH SCSI
with 2.4.0-test1 (or late 2.3.99-preX, e.g. pre9)?

On my CHRP box (with sym53c875 and MESH), no devices at all are detected on the
MESH chain. I haven't tried to remove the sym53c8xx driver (which is scsi0)
from my kernel yet to see whether this is perhaps a more generic problem with
multiple SCSI adapters.

It worked fine in 2.3.99-pre3 from March 21. Anyone with a clue, before I start
diving into the (big) diff between 2.3.99-pre3 and -pre9?

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: mesh in 2.4.0-test1

[Martin Costabel]

Geert Uytterhoeven wrote:
>
> Is there anyone who is succesfully using SCSI devices connected to MESH SCSI
> with 2.4.0-test1 (or late 2.3.99-preX, e.g. pre9)?

Yes. I have only the one SCSI bus, though. From dmesg:

scsi0 : MESH
scsi : 1 host.
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
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
mesh: target 4 synchronous at 5.0 MB/s
  Vendor: QUANTUM   Model: XP34550S          Rev: LXY4
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 4, lun 0
  Vendor: IOMEGA    Model: ZIP 100           Rev: E.08
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi removable disk sdb at scsi0, channel 0, id 5, lun 0
scsi : detected 1 SCSI cdrom 2 SCSI disks total.
Uniform CD-ROM driver Revision: 3.08
SCSI device sda: hdwr sector= 512 bytes. Sectors= 8890760 [4341 MB] [4.3
GB]
 /dev/scsi/host0/bus0/target4/lun0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 196608 [96 MB] [0.1
GB]
sdb: Write Protect is off
 /dev/scsi/host0/bus0/target5/lun0: p1 p2 p3 p4

Kernel is current rsync from bitkeeper (2.4.0-test1, no ac):

root[5]#cat /proc/version
Linux version 2.4.0-test1 (root@chezmoi) (gcc version 2.95.3 19991030
(prerelease/franzo)) #61 Mon May 29 09:36:00 CEST 2000

The only problem I have with these devices is that I can't mount a HFS
CD, but whose fault this is is unknown, probably hfs or mount.

--
Martin

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

Re: mesh in 2.4.0-test1

[Geert Uytterhoeven]

On Wed, 31 May 2000, Geert Uytterhoeven wrote:
> Is there anyone who is succesfully using SCSI devices connected to MESH SCSI
> with 2.4.0-test1 (or late 2.3.99-preX, e.g. pre9)?

After 3 days of hacking, I found it. The new Core99 interrupt tree code doesn't
take into account that on CHRP boxes with both ISA and OpenPIC, the interrupt
numbers have to be fixed up. Below is the patch that made it work for me.

Before I check it in into bitkeeper: should I replace the test

    _machine == _MACH_chrp

by

    !strncmp(model, "IBM,LongTrail", 13)

or are there other CHRP models bitten by this as well?

===== arch/ppc/kernel/prom.c 1.18 vs edited =====
--- 1.18/arch/ppc/kernel/prom.c	Fri May  5 00:15:36 2000
+++ edited/arch/ppc/kernel/prom.c	Sun Jun  4 12:59:07 2000
@@ -1125,17 +1125,36 @@
 	     */
 	    if (get_property(node, "interrupt-controller", &l)) {
 	    	int i,j;
 	    	np->intrs = (struct interrupt_info *) mem_start;
 		np->n_intrs = ipsize / isize;
 		mem_start += np->n_intrs * sizeof(struct interrupt_info);
 		for (i = 0; i < np->n_intrs; ++i) {
 		    np->intrs[i].line = *interrupts++;
 		    np->intrs[i].sense = 0;
 		    if (isize > 1)
 		        np->intrs[i].sense = *interrupts++;
 		    for (j=2; j<isize; j++)
 		    	interrupts++;
 		}
+		/*
+		 *  On the CHRP LongTrail, ISA interrupts are cascaded through
+		 *  the OpenPIC. For compatibility reasons, ISA interrupts are
+		 *  numbered 0-15 and OpenPIC interrupts start at 16.
+		 *  Hence we have to fixup the interrupt numbers for sources
+		 *  that are attached to the OpenPIC and thus have an
+		 *  interrupt-controller named `open-pic'.
+		 *
+		 *  FIXME: The name of the interrupt-controller node for the
+		 *         `ide' node has no name, although its parent is
+		 *         correctly specified in interrupt-map, so we check
+		 *         for a NULL name as well.
+		 */
+		if (_machine == _MACH_chrp &&
+		    ((node->name && !strcmp(node->name, "open-pic")) ||
+		     !node->name)) {
+		    for (i = 0; i < np->n_intrs; ++i)
+			np->intrs[i].line = openpic_to_irq(np->intrs[i].line);
+		}
 		return mem_start;
 	    }
 	    /* We lookup for an interrupt-map. This code can only handle one interrupt

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: mesh in 2.4.0-test1

[Benjamin Herrenschmidt]

On Sun, Jun 4, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

>take into account that on CHRP boxes with both ISA and OpenPIC, the interrupt
>numbers have to be fixed up. Below is the patch that made it work for me.
>
>Before I check it in into bitkeeper: should I replace the test
>
>    _machine == _MACH_chrp
>
>by
>
>    !strncmp(model, "IBM,LongTrail", 13)
>
>or are there other CHRP models bitten by this as well?

Hum, that's a side effect of enabling the new interrupt tree parsing on
all machines. Well, that's more or less my fault: the pmac_newworld
variable gets set to 1 on CHRP, thus enabling the new interrupt tree
parsing on them.

A better fix would be to only enable pmac_newworld on pmacs. (But still
keep the interrupt tree parsing for chrp since it's basically a chrp
thing that Apple implemented in newworld machines).

Note that this problem may be present in recent 2.2.x kernels too.
However, a subtle difference in 2.2.x is that _machine may not be
initialized yet when finish_device_tree() is called.

I'll look into those today and push fixed to both bk trees.

Ben.

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

Re: mesh in 2.4.0-test1

[Benjamin Herrenschmidt]

On Sun, Jun 4, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

>After 3 days of hacking, I found it. The new Core99 interrupt tree code
>doesn't
>take into account that on CHRP boxes with both ISA and OpenPIC, the interrupt
>numbers have to be fixed up. Below is the patch that made it work for me.
>
>Before I check it in into bitkeeper: should I replace the test
>
>    _machine == _MACH_chrp
>
>by
>
>    !strncmp(model, "IBM,LongTrail", 13)
>
>or are there other CHRP models bitten by this as well?

After reading the code more closely, it appear that I spoke to quickly:
_machine is initialized before finish_device_tree() in all cases. I
beleive this problem will happen with all CHRPs since all of them have an
ISA legacy controller. So I'll keep the test
as it is, and I'll merge the fix into bk today for both 2.2 and 2.4 along
with some other prom.c changes I have here.

Ben.


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

Re: mesh in 2.4.0-test1

[Benjamin Herrenschmidt]

On Sun, Jun 4, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

>After 3 days of hacking, I found it. The new Core99 interrupt tree code
>doesn't
>take into account that on CHRP boxes with both ISA and OpenPIC, the interrupt
>numbers have to be fixed up. Below is the patch that made it work for me.
>
>Before I check it in into bitkeeper: should I replace the test
>
>    _machine == _MACH_chrp
>
>by
>
>    !strncmp(model, "IBM,LongTrail", 13)
>
>or are there other CHRP models bitten by this as well?

After reading the code more closely, it appear that I spoke to quickly:
_machine is initialized before finish_device_tree() in all cases. I
beleive this problem will happen with all CHRPs since all of them have an
ISA legacy controller. So I'll keep the test
as it is, and I'll merge the fix into bk today for both 2.2 and 2.4 along
with some other prom.c changes I have here.

Ben.


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