Re: mm->context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
Date: Fri, 15 Dec 2000 18:55:28 +0100 From: Andrea Arcangeli <[EMAIL PROTECTED]> I'm aware this way all ports actively using `mm->context' needs to be changed but the change is certainly a no-brainer... OK? My problem is that I don't want to typedef it to a structure, this will unnecessarily increase the required alignment of the structure member on some architectures. Well, if you're willing to do all the fixing up, then I won't argue it much more. :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm->context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
On Fri, Dec 15, 2000 at 09:11:31AM -0800, David S. Miller wrote: > Can you name the mm_struct member "context" [..] I got you was proposing that but once we change it I preferred to use a generic mm_arch structure (not just a context field) to have a more generic interface in the long run. (maybe some port wants to collect something else than a MM `context') > Then all the code changes will make the accesses look less > meaningful. Consider: > > if (CTX_VALID(mm->mm_arch)) > > whereas before the code said: > > if (CTX_VALID(mm->context)) > > which tells the reader lot more. [..] What I propose is to convert the current: if (CTX_VALID(mm->context)) to if (CTX_VALID(mm->mm_arch.context)) (that's the same I did in the alpha tree from mm->context[] to mm->mm_arch.context[]) I'm aware this way all ports actively using `mm->context' needs to be changed but the change is certainly a no-brainer... OK? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm->context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
Date: Fri, 15 Dec 2000 16:46:26 +0100 From: Andrea Arcangeli <[EMAIL PROTECTED]> This one breaks all archs but i386 and alpha. If some arch maintainer likes me to update its arch blindly implementing mm_arch structure as an `unsigned long context' and fixing up the miscompilation I will do. Can you name the mm_struct member "context" still instead of "mm_arch"? Because many ports will simply: typedef unsigned long mm_arch_t; Then all the code changes will make the accesses look less meaningful. Consider: if (CTX_VALID(mm->mm_arch)) whereas before the code said: if (CTX_VALID(mm->context)) which tells the reader lot more. In fact, retaining the "context" member name allows most ports to operate with only one change, creating the asm/mm_arch.h header. You can in fact do this for all ports which care about MMU tlb contexts (a simple grep such as egrep -e "m->context" `find . -type f -name "*.[ch]"` will show you which ports care). Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm->context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
On Fri, Dec 01, 2000 at 08:14:44PM +0100, Andrea Arcangeli wrote: > On Fri, Dec 01, 2000 at 10:19:44AM -0800, David S. Miller wrote: > > I would instead suggest to declare 'context' to be of an arch-specific > > defined type, much like "thread_struct" is. > > I agree, [..] Here it is: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test12/alpha-ASN-SMP-races-2.4.x-2 This one breaks all archs but i386 and alpha. If some arch maintainer likes me to update its arch blindly implementing mm_arch structure as an `unsigned long context' and fixing up the miscompilation I will do. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm-context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
On Fri, Dec 01, 2000 at 08:14:44PM +0100, Andrea Arcangeli wrote: On Fri, Dec 01, 2000 at 10:19:44AM -0800, David S. Miller wrote: I would instead suggest to declare 'context' to be of an arch-specific defined type, much like "thread_struct" is. I agree, [..] Here it is: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test12/alpha-ASN-SMP-races-2.4.x-2 This one breaks all archs but i386 and alpha. If some arch maintainer likes me to update its arch blindly implementing mm_arch structure as an `unsigned long context' and fixing up the miscompilation I will do. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm-context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
Date: Fri, 15 Dec 2000 16:46:26 +0100 From: Andrea Arcangeli [EMAIL PROTECTED] This one breaks all archs but i386 and alpha. If some arch maintainer likes me to update its arch blindly implementing mm_arch structure as an `unsigned long context' and fixing up the miscompilation I will do. Can you name the mm_struct member "context" still instead of "mm_arch"? Because many ports will simply: typedef unsigned long mm_arch_t; Then all the code changes will make the accesses look less meaningful. Consider: if (CTX_VALID(mm-mm_arch)) whereas before the code said: if (CTX_VALID(mm-context)) which tells the reader lot more. In fact, retaining the "context" member name allows most ports to operate with only one change, creating the asm/mm_arch.h header. You can in fact do this for all ports which care about MMU tlb contexts (a simple grep such as egrep -e "m-context" `find . -type f -name "*.[ch]"` will show you which ports care). Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm-context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
On Fri, Dec 15, 2000 at 09:11:31AM -0800, David S. Miller wrote: Can you name the mm_struct member "context" [..] I got you was proposing that but once we change it I preferred to use a generic mm_arch structure (not just a context field) to have a more generic interface in the long run. (maybe some port wants to collect something else than a MM `context') Then all the code changes will make the accesses look less meaningful. Consider: if (CTX_VALID(mm-mm_arch)) whereas before the code said: if (CTX_VALID(mm-context)) which tells the reader lot more. [..] What I propose is to convert the current: if (CTX_VALID(mm-context)) to if (CTX_VALID(mm-mm_arch.context)) (that's the same I did in the alpha tree from mm-context[] to mm-mm_arch.context[]) I'm aware this way all ports actively using `mm-context' needs to be changed but the change is certainly a no-brainer... OK? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm-context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
Date: Fri, 15 Dec 2000 18:55:28 +0100 From: Andrea Arcangeli [EMAIL PROTECTED] I'm aware this way all ports actively using `mm-context' needs to be changed but the change is certainly a no-brainer... OK? My problem is that I don't want to typedef it to a structure, this will unnecessarily increase the required alignment of the structure member on some architectures. Well, if you're willing to do all the fixing up, then I won't argue it much more. :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Mon, Dec 04, 2000 at 01:53:42PM -0500, Phillip Ezolt wrote:
>
> I've recompiled as you have suggested. Any ideas?
Compile again with the following patches (these are against 2.4.0-test12,
but those in arch/alpha/kernel/core_cia.c should work against test10/11
as well).
Something got lost between 2.2 and 2.4, but it's most likely that
MIATA (because it has 6 DIMM slots) is one of the few CIA and PYXIS
machines that could actually get over 1GB of memory; that's why we
haven't seen this before...
--Jay++
-
Jay A EstabrookAlpha Engineering - LINUX Project
Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080
200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED]
-
diff -urN old/arch/alpha/kernel/core_cia.c new/arch/alpha/kernel/core_cia.c
--- old/arch/alpha/kernel/core_cia.cTue Dec 5 10:09:01 2000
+++ new/arch/alpha/kernel/core_cia.cTue Dec 5 18:45:12 2000
@@ -700,11 +700,11 @@
*(vip)CIA_IOC_PCI_W1_BASE = 0x4000 | 1;
*(vip)CIA_IOC_PCI_W1_MASK = (0x4000 - 1) & 0xfff0;
- *(vip)CIA_IOC_PCI_T1_BASE = 0;
+ *(vip)CIA_IOC_PCI_T1_BASE = 0 >> 2;
*(vip)CIA_IOC_PCI_W2_BASE = 0x8000 | 1;
*(vip)CIA_IOC_PCI_W2_MASK = (0x4000 - 1) & 0xfff0;
- *(vip)CIA_IOC_PCI_T2_BASE = 0x4000;
+ *(vip)CIA_IOC_PCI_T2_BASE = 0x4000 >> 2;
*(vip)CIA_IOC_PCI_W3_BASE = 0;
}
diff -urN old/arch/alpha/kernel/pci.c new/arch/alpha/kernel/pci.c
--- old/arch/alpha/kernel/pci.c Tue Dec 5 10:09:01 2000
+++ new/arch/alpha/kernel/pci.c Tue Dec 5 10:20:01 2000
@@ -91,9 +91,15 @@
if (dev->class >> 8 != PCI_CLASS_STORAGE_IDE)
return;
dev->resource[1].start |= 2;
- dev->resource[1].end = dev->resource[1].start;
+ dev->resource[1].end = dev->resource[1].start + 1;
+#ifndef CONFIG_BLK_DEV_IDEPCI
+ /* already claimed by "standard" (ie junk) resources */
+ dev->resource[0].flags &= ~IORESOURCE_IO;
+ dev->resource[1].flags &= ~IORESOURCE_IO;
+#else
pci_claim_resource(dev, 0);
pci_claim_resource(dev, 1);
+#endif
}
static void __init
diff -urN old/drivers/pci/pci.c new/drivers/pci/pci.c
--- old/drivers/pci/pci.c Tue Dec 5 10:09:02 2000
+++ new/drivers/pci/pci.c Tue Dec 5 10:17:32 2000
@@ -540,7 +540,7 @@
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
- u32 l, sz;
+ u32 l, sz, tmp;
struct resource *res;
for(pos=0; poshttp://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Andrea, > Does the qlogic driver works well on an ES40 with more than 1G of ram? If > yes then qlogic driver should be ok. Yes. I have tried it on an ES40 with 16 Gig of ram, and it boots just fine. From what you say, this appears to be a Miata problem and NOT a qlogic problem. What next? --Phil Compaq: High Performance Server Division/Benchmark Performance Engineering Alpha, The Fastest Processor on Earth [EMAIL PROTECTED]|C|O|M|P|A|Q|[EMAIL PROTECTED] --- See the results at www.spec.org --- On Fri, 1 Dec 2000, Andrea Arcangeli wrote: > On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote: > > What data structure's would I look at? What should I investigate to > > verify this? > > The relevant code is in arch/alpha/kernel/core_cia.c > > > What would I have to do to test this? I have an ES40 & 3 miata's > > Does the qlogic driver works well on an ES40 with more than 1G of ram? If > yes then qlogic driver should be ok. > > Andrea > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Mon, Dec 04, 2000 at 01:53:42PM -0500, Phillip Ezolt wrote:
I've recompiled as you have suggested. Any ideas?
Compile again with the following patches (these are against 2.4.0-test12,
but those in arch/alpha/kernel/core_cia.c should work against test10/11
as well).
Something got lost between 2.2 and 2.4, but it's most likely that
MIATA (because it has 6 DIMM slots) is one of the few CIA and PYXIS
machines that could actually get over 1GB of memory; that's why we
haven't seen this before...
--Jay++
-
Jay A EstabrookAlpha Engineering - LINUX Project
Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080
200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED]
-
diff -urN old/arch/alpha/kernel/core_cia.c new/arch/alpha/kernel/core_cia.c
--- old/arch/alpha/kernel/core_cia.cTue Dec 5 10:09:01 2000
+++ new/arch/alpha/kernel/core_cia.cTue Dec 5 18:45:12 2000
@@ -700,11 +700,11 @@
*(vip)CIA_IOC_PCI_W1_BASE = 0x4000 | 1;
*(vip)CIA_IOC_PCI_W1_MASK = (0x4000 - 1) 0xfff0;
- *(vip)CIA_IOC_PCI_T1_BASE = 0;
+ *(vip)CIA_IOC_PCI_T1_BASE = 0 2;
*(vip)CIA_IOC_PCI_W2_BASE = 0x8000 | 1;
*(vip)CIA_IOC_PCI_W2_MASK = (0x4000 - 1) 0xfff0;
- *(vip)CIA_IOC_PCI_T2_BASE = 0x4000;
+ *(vip)CIA_IOC_PCI_T2_BASE = 0x4000 2;
*(vip)CIA_IOC_PCI_W3_BASE = 0;
}
diff -urN old/arch/alpha/kernel/pci.c new/arch/alpha/kernel/pci.c
--- old/arch/alpha/kernel/pci.c Tue Dec 5 10:09:01 2000
+++ new/arch/alpha/kernel/pci.c Tue Dec 5 10:20:01 2000
@@ -91,9 +91,15 @@
if (dev-class 8 != PCI_CLASS_STORAGE_IDE)
return;
dev-resource[1].start |= 2;
- dev-resource[1].end = dev-resource[1].start;
+ dev-resource[1].end = dev-resource[1].start + 1;
+#ifndef CONFIG_BLK_DEV_IDEPCI
+ /* already claimed by "standard" (ie junk) resources */
+ dev-resource[0].flags = ~IORESOURCE_IO;
+ dev-resource[1].flags = ~IORESOURCE_IO;
+#else
pci_claim_resource(dev, 0);
pci_claim_resource(dev, 1);
+#endif
}
static void __init
diff -urN old/drivers/pci/pci.c new/drivers/pci/pci.c
--- old/drivers/pci/pci.c Tue Dec 5 10:09:02 2000
+++ new/drivers/pci/pci.c Tue Dec 5 10:17:32 2000
@@ -540,7 +540,7 @@
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
- u32 l, sz;
+ u32 l, sz, tmp;
struct resource *res;
for(pos=0; poshowmany; pos = next) {
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Ivan, I've recompiled as you have suggested. Any ideas? Here is my dmesg output: Linux version 2.4.0-test12 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #3 Mon Dec 4 02:38:18 EST 2000 Booting GENERIC on Miata using machine vector Miata from SRM Command line: console=tty0 console=ttyS0,9600 root=/dev/fd0 memcluster 0, usage 1, start0, end 236 memcluster 1, usage 0, start 236, end 147455 memcluster 2, usage 1, start 147455, end 147456 freeing pages 236:384 freeing pages 754:147455 pci: cia revision 1 (pyxis) On node 0 totalpages: 147456 zone(0): 147456 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=tty0 console=ttyS0,9600 root=/dev/fd0 Using epoch = 1952 Console: colour VGA+ 80x25 Calibrating delay loop... 1191.18 BogoMIPS Memory: 1155136k/1179640k available (1602k kernel code, 22616k reserved, 515k data, 376k init) Dentry-cache hash table entries: 262144 (order: 9, 4194304 bytes) Buffer-cache hash table entries: 65536 (order: 6, 524288 bytes) Page-cache hash table entries: 262144 (order: 8, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 2097152 bytes) POSIX conformance testing by UNIFIX pci: passed tb register update test pci: passed sg loopback i/o read test pci: passed tbia test pci: passed pte write cache snoop test pci: failed valid tag invalid pte reload test (mcheck; workaround available) pci: passed pci machine check test got res[8000:807f] for resource 0 of Digital Equipment Corporation DECchip 21142/43 got res[8080:80ff] for resource 1 of Digital Equipment Corporation DEFPA got res[8400:840f] for resource 4 of Contaq Microsystems 82c693 (#2) got res[900:97f] for resource 1 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[980:983] for resource 6 of Digital Equipment Corporation DECchip 21142/43 got res[984:984] for resource 4 of Contaq Microsystems 82c693 (#3) got res[985:985] for resource 6 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[986:986] for resource 2 of Digital Equipment Corporation DEFPA got res[987:9873fff] for resource 0 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[9874000:9874fff] for resource 0 of Contaq Microsystems 82c693 (#4) got res[9875000:987507f] for resource 1 of Digital Equipment Corporation DECchip 21142/43 got res[9876000:987607f] for resource 0 of Digital Equipment Corporation DEFPA got res[9000:90ff] for resource 0 of Q Logic ISP1020 got res[9400:947f] for resource 0 of Digital Equipment Corporation DECchip 21040 [Tulip] got res[990:990] for resource 6 of Q Logic ISP1020 got res[991:9910fff] for resource 1 of Q Logic ISP1020 got res[9911000:991107f] for resource 1 of Digital Equipment Corporation DECchip 21040 [Tulip] PCI: Bus 1, bridge: Digital Equipment Corporation DECchip 21152 IO window: 9000-9fff MEM window: 0990-099f PCI enable device: (Digital Equipment Corporation DECchip 21142/43) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693 (#2)) cmd reg 0x45 PCI enable device: (Contaq Microsystems 82c693 (#3)) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693 (#4)) cmd reg 0x46 PCI enable device: (Matrox Graphics, Inc. MGA 2064W [Millennium]) cmd reg 0x87 PCI enable device: (Digital Equipment Corporation DEFPA) cmd reg 0x47 PCI enable device: (Digital Equipment Corporation DECchip 21152) cmd reg 0x107 PCI enable device: (Q Logic ISP1020) cmd reg 0x47 PCI enable device: (Digital Equipment Corporation DECchip 21040 [Tulip]) cmd reg 0x47 SMC37c669 Super I/O Controller found @ 0x370 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx CY82C693: IDE controller on PCI bus 00 dev 39 CY82C693: chipset revision 0 CY82C693: not 100% native mode: will probe irqs later CY82C693U driver v0.34 99-13-12 Andreas S. Krebs ([EMAIL PROTECTED]) ide0: BM-DMA at 0x8400-0x8407<7>pci_map_single: [fc000191,1000] -> direct 4191 from fc31afa8 , BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x8408-0x840f<7>pci_map_single: [fc1fa000,1000] -> direct 401fa000 from fc31afa8 , BIOS settings: hdc:pio, hdd:pio hda: TOSHIBA CD-ROM XM-5702B, ATAPI CDROM drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: ATAPI 12X CD-ROM drive, 256kB Cache Uniform CD-ROM driver Revision: 3.11 Floppy drive(s): fd0 is 2.88M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A rtc: Digital UNIX epoch (1952) detected
Re: Alpha SCSI error on 2.4.0-test11
Ivan, I've recompiled as you have suggested. Any ideas? Here is my dmesg output: Linux version 2.4.0-test12 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #3 Mon Dec 4 02:38:18 EST 2000 Booting GENERIC on Miata using machine vector Miata from SRM Command line: console=tty0 console=ttyS0,9600 root=/dev/fd0 memcluster 0, usage 1, start0, end 236 memcluster 1, usage 0, start 236, end 147455 memcluster 2, usage 1, start 147455, end 147456 freeing pages 236:384 freeing pages 754:147455 pci: cia revision 1 (pyxis) On node 0 totalpages: 147456 zone(0): 147456 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=tty0 console=ttyS0,9600 root=/dev/fd0 Using epoch = 1952 Console: colour VGA+ 80x25 Calibrating delay loop... 1191.18 BogoMIPS Memory: 1155136k/1179640k available (1602k kernel code, 22616k reserved, 515k data, 376k init) Dentry-cache hash table entries: 262144 (order: 9, 4194304 bytes) Buffer-cache hash table entries: 65536 (order: 6, 524288 bytes) Page-cache hash table entries: 262144 (order: 8, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 2097152 bytes) POSIX conformance testing by UNIFIX pci: passed tb register update test pci: passed sg loopback i/o read test pci: passed tbia test pci: passed pte write cache snoop test pci: failed valid tag invalid pte reload test (mcheck; workaround available) pci: passed pci machine check test got res[8000:807f] for resource 0 of Digital Equipment Corporation DECchip 21142/43 got res[8080:80ff] for resource 1 of Digital Equipment Corporation DEFPA got res[8400:840f] for resource 4 of Contaq Microsystems 82c693 (#2) got res[900:97f] for resource 1 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[980:983] for resource 6 of Digital Equipment Corporation DECchip 21142/43 got res[984:984] for resource 4 of Contaq Microsystems 82c693 (#3) got res[985:985] for resource 6 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[986:986] for resource 2 of Digital Equipment Corporation DEFPA got res[987:9873fff] for resource 0 of Matrox Graphics, Inc. MGA 2064W [Millennium] got res[9874000:9874fff] for resource 0 of Contaq Microsystems 82c693 (#4) got res[9875000:987507f] for resource 1 of Digital Equipment Corporation DECchip 21142/43 got res[9876000:987607f] for resource 0 of Digital Equipment Corporation DEFPA got res[9000:90ff] for resource 0 of Q Logic ISP1020 got res[9400:947f] for resource 0 of Digital Equipment Corporation DECchip 21040 [Tulip] got res[990:990] for resource 6 of Q Logic ISP1020 got res[991:9910fff] for resource 1 of Q Logic ISP1020 got res[9911000:991107f] for resource 1 of Digital Equipment Corporation DECchip 21040 [Tulip] PCI: Bus 1, bridge: Digital Equipment Corporation DECchip 21152 IO window: 9000-9fff MEM window: 0990-099f PCI enable device: (Digital Equipment Corporation DECchip 21142/43) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693 (#2)) cmd reg 0x45 PCI enable device: (Contaq Microsystems 82c693 (#3)) cmd reg 0x47 PCI enable device: (Contaq Microsystems 82c693 (#4)) cmd reg 0x46 PCI enable device: (Matrox Graphics, Inc. MGA 2064W [Millennium]) cmd reg 0x87 PCI enable device: (Digital Equipment Corporation DEFPA) cmd reg 0x47 PCI enable device: (Digital Equipment Corporation DECchip 21152) cmd reg 0x107 PCI enable device: (Q Logic ISP1020) cmd reg 0x47 PCI enable device: (Digital Equipment Corporation DECchip 21040 [Tulip]) cmd reg 0x47 SMC37c669 Super I/O Controller found @ 0x370 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx CY82C693: IDE controller on PCI bus 00 dev 39 CY82C693: chipset revision 0 CY82C693: not 100% native mode: will probe irqs later CY82C693U driver v0.34 99-13-12 Andreas S. Krebs ([EMAIL PROTECTED]) ide0: BM-DMA at 0x8400-0x84077pci_map_single: [fc000191,1000] - direct 4191 from fc31afa8 , BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x8408-0x840f7pci_map_single: [fc1fa000,1000] - direct 401fa000 from fc31afa8 , BIOS settings: hdc:pio, hdd:pio hda: TOSHIBA CD-ROM XM-5702B, ATAPI CDROM drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: ATAPI 12X CD-ROM drive, 256kB Cache Uniform CD-ROM driver Revision: 3.11 Floppy drive(s): fd0 is 2.88M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A rtc: Digital UNIX epoch (1952) detected Real
Re: Alpha SCSI error on 2.4.0-test11
On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote: > What data structure's would I look at? What should I investigate to > verify this? In the arch/alpha/kernel/pci_iommu.c change #define DEBUG_ALLOC 0 to #define DEBUG_ALLOC 2 Perhaps this will give us more info. At the first look window 1 is being set up properly. Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote: > What data structure's would I look at? What should I investigate to > verify this? The relevant code is in arch/alpha/kernel/core_cia.c > What would I have to do to test this? I have an ES40 & 3 miata's Does the qlogic driver works well on an ES40 with more than 1G of ram? If yes then qlogic driver should be ok. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Andrea, > large 2G. So it's maybe the second window between 1G and 2G that isn't set > correctly? What data structure's would I look at? What should I investigate to verify this? > Does the qlogic driver works on a tsunami southbridge? What would I have to do to test this? I have an ES40 & 3 miata's at my disposal. Thanks, --Phil Compaq: High Performance Server Division/Benchmark Performance Engineering Alpha, The Fastest Processor on Earth [EMAIL PROTECTED]|C|O|M|P|A|Q|[EMAIL PROTECTED] --- See the results at www.spec.org --- On Fri, 1 Dec 2000, Andrea Arcangeli wrote: > On Fri, Dec 01, 2000 at 01:30:10PM -0500, Phillip Ezolt wrote: > > Any ideas? (Or patches that I can test... ;-) ) > > miata seems to use cia southbridge so it should set an iommu direct mapping > large 2G. So it's maybe the second window between 1G and 2G that isn't set > correctly? Does the qlogic driver works on a tsunami southbridge? > > Andrea > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Fri, Dec 01, 2000 at 01:30:10PM -0500, Phillip Ezolt wrote: > Any ideas? (Or patches that I can test... ;-) ) miata seems to use cia southbridge so it should set an iommu direct mapping large 2G. So it's maybe the second window between 1G and 2G that isn't set correctly? Does the qlogic driver works on a tsunami southbridge? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm->context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
On Fri, Dec 01, 2000 at 10:19:44AM -0800, David S. Miller wrote: >I'm still left the #ifdef __alpha__ around the context[NR_CPUS] to >avoid breakage of other archs but that should be probably removed: >any CPU with per-CPU ASNs like alpha needs per-CPU per-MM context >information to avoid wasting ASNs when the task migrate CPU or with >threads. > > I would instead suggest to declare 'context' to be of an arch-specific > defined type, much like "thread_struct" is. I agree, really that should been the case since the first place because the 4 bytes of context are just a waste for x86* :). I mainly wanted to make sure other archs was doing the right thing too. > For example, I don't need NR_CPUS contexts in the mm_struct on > sparc64, my allocation just works differently, so I shouldn't eat > all the space. I think at least mips wants to use per-mm per-cpu context too btw. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm->context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
Date:Fri, 1 Dec 2000 15:18:42 +0100 From: Andrea Arcangeli <[EMAIL PROTECTED]> I'm still left the #ifdef __alpha__ around the context[NR_CPUS] to avoid breakage of other archs but that should be probably removed: any CPU with per-CPU ASNs like alpha needs per-CPU per-MM context information to avoid wasting ASNs when the task migrate CPU or with threads. I would instead suggest to declare 'context' to be of an arch-specific defined type, much like "thread_struct" is. For example, I don't need NR_CPUS contexts in the mm_struct on sparc64, my allocation just works differently, so I shouldn't eat all the space. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Ivan,
I have tried test12-pre3 with and without your patch, it fails in the same
way.
The Qlogic SCSI controller continues to fail if we have >1 gig in the machine.
(But works fine without it.)
Any ideas? (Or patches that I can test... ;-) )
Thanks,
--Phil
Compaq: High Performance Server Division/Benchmark Performance Engineering
Alpha, The Fastest Processor on Earth
[EMAIL PROTECTED]|C|O|M|P|A|Q|[EMAIL PROTECTED]
--- See the results at www.spec.org ---
On Fri, 1 Dec 2000, Ivan Kokshaysky wrote:
> On Thu, Nov 30, 2000 at 11:37:42PM +0100, Andrea Arcangeli wrote:
> > test12-pre2 crashes at boot on my DS20. This patch workaround the problem
> > but I would be _very_ surprised if this is the right fix :) It's obviously not
> > meant for inclusion.
> ...
> > - struct resource_list *ln = list->next;
> > + struct resource_list *ln;
> >
> > + if (!list)
> > + return;
> > + ln = list->next;
>
> Argh. I believe that crash could happen only if some broken device has
> empty I/O or memory range and IORESOURCE_[IO,MEM] bit set.
>
> Andrea, could you try this?
>
> Ivan.
>
> --- linux/drivers/pci/setup-res.c~Thu Nov 30 12:14:31 2000
> +++ linux/drivers/pci/setup-res.c Fri Dec 1 13:49:34 2000
> @@ -136,6 +136,7 @@ pdev_sort_resources(struct pci_dev *dev,
> for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> struct resource *r;
> struct resource_list *list, *tmp;
> + unsigned long r_size;
>
> /* PCI-PCI bridges may have I/O ports or
> memory on the primary bus */
> @@ -144,7 +145,9 @@ pdev_sort_resources(struct pci_dev *dev,
> continue;
>
> r = >resource[i];
> - if (!(r->flags & type_mask) || r->parent)
> + r_size = r->end - r->start;
> +
> + if (!(r->flags & type_mask) || !r_size || r->parent)
> continue;
> for (list = head; ; list = list->next) {
> unsigned long size = 0;
> @@ -152,7 +155,7 @@ pdev_sort_resources(struct pci_dev *dev,
>
> if (ln)
> size = ln->res->end - ln->res->start;
> - if (r->end - r->start > size) {
> + if (r_size > size) {
> tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
> tmp->next = ln;
> tmp->res = r;
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
mm->context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
On Fri, Dec 01, 2000 at 02:56:19PM +0300, Ivan Kokshaysky wrote: > Andrea, could you try this? that's the right fix thanks (please send to Linus). BTW, here is a preview of the asn SMP race fix for 2.4.x: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test12-pre2/alpha-ASN-SMP-races-2.4.x-1 I'm still left the #ifdef __alpha__ around the context[NR_CPUS] to avoid breakage of other archs but that should be probably removed: any CPU with per-CPU ASNs like alpha needs per-CPU per-MM context information to avoid wasting ASNs when the task migrate CPU or with threads. The ASN race fix for 2.4.x is implemented differently than the 2.2.x previous version, in 2.4.x I'm avoiding the __cli, so the whole context switch runs with irq _enabled_ as usual (unlike in the 2.2.x version). I'm also taking care not to waste any ASN than strictly necessary while doing the race-check after the context switch completed. And here a new version of the 2.2.x one (I was clearing all other cpu context from activate_context, and that wasn't necessary but it couldn't hurt so it's a minor update): ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre23/alpha-ASN-SMP-races-3 (the cli-less logic could be backported to 2.2.x but OTOH the cli way looks simpler so more appropriate for 2.2.x) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Thu, Nov 30, 2000 at 11:37:42PM +0100, Andrea Arcangeli wrote:
> test12-pre2 crashes at boot on my DS20. This patch workaround the problem
> but I would be _very_ surprised if this is the right fix :) It's obviously not
> meant for inclusion.
...
> - struct resource_list *ln = list->next;
> + struct resource_list *ln;
>
> + if (!list)
> + return;
> + ln = list->next;
Argh. I believe that crash could happen only if some broken device has
empty I/O or memory range and IORESOURCE_[IO,MEM] bit set.
Andrea, could you try this?
Ivan.
--- linux/drivers/pci/setup-res.c~ Thu Nov 30 12:14:31 2000
+++ linux/drivers/pci/setup-res.c Fri Dec 1 13:49:34 2000
@@ -136,6 +136,7 @@ pdev_sort_resources(struct pci_dev *dev,
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
struct resource *r;
struct resource_list *list, *tmp;
+ unsigned long r_size;
/* PCI-PCI bridges may have I/O ports or
memory on the primary bus */
@@ -144,7 +145,9 @@ pdev_sort_resources(struct pci_dev *dev,
continue;
r = >resource[i];
- if (!(r->flags & type_mask) || r->parent)
+ r_size = r->end - r->start;
+
+ if (!(r->flags & type_mask) || !r_size || r->parent)
continue;
for (list = head; ; list = list->next) {
unsigned long size = 0;
@@ -152,7 +155,7 @@ pdev_sort_resources(struct pci_dev *dev,
if (ln)
size = ln->res->end - ln->res->start;
- if (r->end - r->start > size) {
+ if (r_size > size) {
tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
tmp->next = ln;
tmp->res = r;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Thu, Nov 30, 2000 at 11:37:42PM +0100, Andrea Arcangeli wrote:
test12-pre2 crashes at boot on my DS20. This patch workaround the problem
but I would be _very_ surprised if this is the right fix :) It's obviously not
meant for inclusion.
...
- struct resource_list *ln = list-next;
+ struct resource_list *ln;
+ if (!list)
+ return;
+ ln = list-next;
Argh. I believe that crash could happen only if some broken device has
empty I/O or memory range and IORESOURCE_[IO,MEM] bit set.
Andrea, could you try this?
Ivan.
--- linux/drivers/pci/setup-res.c~ Thu Nov 30 12:14:31 2000
+++ linux/drivers/pci/setup-res.c Fri Dec 1 13:49:34 2000
@@ -136,6 +136,7 @@ pdev_sort_resources(struct pci_dev *dev,
for (i = 0; i PCI_NUM_RESOURCES; i++) {
struct resource *r;
struct resource_list *list, *tmp;
+ unsigned long r_size;
/* PCI-PCI bridges may have I/O ports or
memory on the primary bus */
@@ -144,7 +145,9 @@ pdev_sort_resources(struct pci_dev *dev,
continue;
r = dev-resource[i];
- if (!(r-flags type_mask) || r-parent)
+ r_size = r-end - r-start;
+
+ if (!(r-flags type_mask) || !r_size || r-parent)
continue;
for (list = head; ; list = list-next) {
unsigned long size = 0;
@@ -152,7 +155,7 @@ pdev_sort_resources(struct pci_dev *dev,
if (ln)
size = ln-res-end - ln-res-start;
- if (r-end - r-start size) {
+ if (r_size size) {
tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
tmp-next = ln;
tmp-res = r;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
mm-context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
On Fri, Dec 01, 2000 at 02:56:19PM +0300, Ivan Kokshaysky wrote: Andrea, could you try this? that's the right fix thanks (please send to Linus). BTW, here is a preview of the asn SMP race fix for 2.4.x: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test12-pre2/alpha-ASN-SMP-races-2.4.x-1 I'm still left the #ifdef __alpha__ around the context[NR_CPUS] to avoid breakage of other archs but that should be probably removed: any CPU with per-CPU ASNs like alpha needs per-CPU per-MM context information to avoid wasting ASNs when the task migrate CPU or with threads. The ASN race fix for 2.4.x is implemented differently than the 2.2.x previous version, in 2.4.x I'm avoiding the __cli, so the whole context switch runs with irq _enabled_ as usual (unlike in the 2.2.x version). I'm also taking care not to waste any ASN than strictly necessary while doing the race-check after the context switch completed. And here a new version of the 2.2.x one (I was clearing all other cpu context from activate_context, and that wasn't necessary but it couldn't hurt so it's a minor update): ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre23/alpha-ASN-SMP-races-3 (the cli-less logic could be backported to 2.2.x but OTOH the cli way looks simpler so more appropriate for 2.2.x) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Ivan,
I have tried test12-pre3 with and without your patch, it fails in the same
way.
The Qlogic SCSI controller continues to fail if we have 1 gig in the machine.
(But works fine without it.)
Any ideas? (Or patches that I can test... ;-) )
Thanks,
--Phil
Compaq: High Performance Server Division/Benchmark Performance Engineering
Alpha, The Fastest Processor on Earth
[EMAIL PROTECTED]|C|O|M|P|A|Q|[EMAIL PROTECTED]
--- See the results at www.spec.org ---
On Fri, 1 Dec 2000, Ivan Kokshaysky wrote:
On Thu, Nov 30, 2000 at 11:37:42PM +0100, Andrea Arcangeli wrote:
test12-pre2 crashes at boot on my DS20. This patch workaround the problem
but I would be _very_ surprised if this is the right fix :) It's obviously not
meant for inclusion.
...
- struct resource_list *ln = list-next;
+ struct resource_list *ln;
+ if (!list)
+ return;
+ ln = list-next;
Argh. I believe that crash could happen only if some broken device has
empty I/O or memory range and IORESOURCE_[IO,MEM] bit set.
Andrea, could you try this?
Ivan.
--- linux/drivers/pci/setup-res.c~Thu Nov 30 12:14:31 2000
+++ linux/drivers/pci/setup-res.c Fri Dec 1 13:49:34 2000
@@ -136,6 +136,7 @@ pdev_sort_resources(struct pci_dev *dev,
for (i = 0; i PCI_NUM_RESOURCES; i++) {
struct resource *r;
struct resource_list *list, *tmp;
+ unsigned long r_size;
/* PCI-PCI bridges may have I/O ports or
memory on the primary bus */
@@ -144,7 +145,9 @@ pdev_sort_resources(struct pci_dev *dev,
continue;
r = dev-resource[i];
- if (!(r-flags type_mask) || r-parent)
+ r_size = r-end - r-start;
+
+ if (!(r-flags type_mask) || !r_size || r-parent)
continue;
for (list = head; ; list = list-next) {
unsigned long size = 0;
@@ -152,7 +155,7 @@ pdev_sort_resources(struct pci_dev *dev,
if (ln)
size = ln-res-end - ln-res-start;
- if (r-end - r-start size) {
+ if (r_size size) {
tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
tmp-next = ln;
tmp-res = r;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Fri, Dec 01, 2000 at 01:30:10PM -0500, Phillip Ezolt wrote: Any ideas? (Or patches that I can test... ;-) ) miata seems to use cia southbridge so it should set an iommu direct mapping large 2G. So it's maybe the second window between 1G and 2G that isn't set correctly? Does the qlogic driver works on a tsunami southbridge? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Andrea, large 2G. So it's maybe the second window between 1G and 2G that isn't set correctly? What data structure's would I look at? What should I investigate to verify this? Does the qlogic driver works on a tsunami southbridge? What would I have to do to test this? I have an ES40 3 miata's at my disposal. Thanks, --Phil Compaq: High Performance Server Division/Benchmark Performance Engineering Alpha, The Fastest Processor on Earth [EMAIL PROTECTED]|C|O|M|P|A|Q|[EMAIL PROTECTED] --- See the results at www.spec.org --- On Fri, 1 Dec 2000, Andrea Arcangeli wrote: On Fri, Dec 01, 2000 at 01:30:10PM -0500, Phillip Ezolt wrote: Any ideas? (Or patches that I can test... ;-) ) miata seems to use cia southbridge so it should set an iommu direct mapping large 2G. So it's maybe the second window between 1G and 2G that isn't set correctly? Does the qlogic driver works on a tsunami southbridge? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote: What data structure's would I look at? What should I investigate to verify this? The relevant code is in arch/alpha/kernel/core_cia.c What would I have to do to test this? I have an ES40 3 miata's Does the qlogic driver works well on an ES40 with more than 1G of ram? If yes then qlogic driver should be ok. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote: What data structure's would I look at? What should I investigate to verify this? In the arch/alpha/kernel/pci_iommu.c change #define DEBUG_ALLOC 0 to #define DEBUG_ALLOC 2 Perhaps this will give us more info. At the first look window 1 is being set up properly. Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mm-context[NR_CPUS] and pci fix check [was Re: Alpha SCSI error on 2.4.0-test11]
Date:Fri, 1 Dec 2000 15:18:42 +0100 From: Andrea Arcangeli [EMAIL PROTECTED] I'm still left the #ifdef __alpha__ around the context[NR_CPUS] to avoid breakage of other archs but that should be probably removed: any CPU with per-CPU ASNs like alpha needs per-CPU per-MM context information to avoid wasting ASNs when the task migrate CPU or with threads. I would instead suggest to declare 'context' to be of an arch-specific defined type, much like "thread_struct" is. For example, I don't need NR_CPUS contexts in the mm_struct on sparc64, my allocation just works differently, so I shouldn't eat all the space. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Thu, Nov 30, 2000 at 05:26:58PM -0500, Phillip Ezolt wrote:
> I'll give test12-pre3 a try and see if it fixes things.
test12-pre2 crashes at boot on my DS20. This patch workaround the problem
but I would be _very_ surprised if this is the right fix :) It's obviously not
meant for inclusion.
--- 2.4.0-test12-pre2-alpha/drivers/pci/setup-res.c.~1~ Tue Nov 28 18:40:29 2000
+++ 2.4.0-test12-pre2-alpha/drivers/pci/setup-res.c Wed Nov 29 03:15:45 2000
@@ -148,8 +148,11 @@
continue;
for (list = head; ; list = list->next) {
unsigned long size = 0;
- struct resource_list *ln = list->next;
+ struct resource_list *ln;
+ if (!list)
+ return;
+ ln = list->next;
if (ln)
size = ln->res->end - ln->res->start;
if (r->end - r->start > size) {
I prefer to finish the ASN SMP rework before looking into this.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Ivan, We dug a little deeper, and think that we found the problem. The error occurs if we have over 1024 MB of memory in the machine. If we have less than 1024MB, the machine behaves correctly. (This is a 600Mhz Digital Personal Workstation) Once again, the 2.2 kernel in RH 7.0 behaves properly. I'll give test12-pre3 a try and see if it fixes things. Thanks, --Phil Compaq: High Performance Server Division/Benchmark Performance Engineering Alpha, The Fastest Processor on Earth [EMAIL PROTECTED]|C|O|M|P|A|Q|[EMAIL PROTECTED] --- See the results at www.spec.org --- On Fri, 1 Dec 2000, Ivan Kokshaysky wrote: > On Thu, Nov 30, 2000 at 03:02:42PM -0500, Phillip Ezolt wrote: > > Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal >WorkStation 600au). > > > > When starting up, we get a machine check after initialing the qlogic SCSI code. > > Try test12-pre3 - there is the new PCI init stuff. It works (to some degree) > on as1000a with the same qlogic scsi. > > Ivan. > > > > ___ > Axp-list mailing list > [EMAIL PROTECTED] > https://listman.redhat.com/mailman/listinfo/axp-list > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Thu, Nov 30, 2000 at 03:02:42PM -0500, Phillip Ezolt wrote: > Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal >WorkStation 600au). > > When starting up, we get a machine check after initialing the qlogic SCSI code. Try test12-pre3 - there is the new PCI init stuff. It works (to some degree) on as1000a with the same qlogic scsi. Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Alpha SCSI error on 2.4.0-test11
Its probaly due to the semaphore changes that went in to test11 by Richard Henderson. scsi_wait_req will grab one on entry. Did test10 work for you on Alpha? Regards, Torben Mathiasen > -Original Message- > From: Rival, Frank > Sent: 30. november 2000 21:37 > To: Ezolt, Phillip > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > Estabrook, Jay; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: Alpha SCSI error on 2.4.0-test11 > > > Hi Phil, > > Phillip Ezolt wrote: > > > Hi All, > > > > Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata > (Digital Personal WorkStation 600au). > > > > When starting up, we get a machine check after initialing > the qlogic SCSI code. > > > > Using the Alpha kgdb, we figured out that the code is dying > in scsi_wait_request(). > > Wow, I'm impressed! I didn't realize that kgdb worked on > Alpha...Were > you using the remote kgdb? (You can answer me offline to save > bandwidth.) This would be a _huge_ help in trying to figure > out why my > Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I > stole from > Jay and have been hacking on. > > Speaking of that system, it has two QLogic adapters in it > (both 1040Bs, > like the Miata), and they are working just fine under 2.4.0-test11 > (obviously, without my changes ;). It looks like it's probably the > platform code that's busted. I can't remember...are those Pyxis or > CIA? Anyway, could this have something to do with the PCI & > PCI bridge > work that Richard and Ivan just submitted? > > - Pete > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Hi Phil, Phillip Ezolt wrote: > Hi All, > > Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal >WorkStation 600au). > > When starting up, we get a machine check after initialing the qlogic SCSI code. > > Using the Alpha kgdb, we figured out that the code is dying in scsi_wait_request(). Wow, I'm impressed! I didn't realize that kgdb worked on Alpha...Were you using the remote kgdb? (You can answer me offline to save bandwidth.) This would be a _huge_ help in trying to figure out why my Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I stole from Jay and have been hacking on. Speaking of that system, it has two QLogic adapters in it (both 1040Bs, like the Miata), and they are working just fine under 2.4.0-test11 (obviously, without my changes ;). It looks like it's probably the platform code that's busted. I can't remember...are those Pyxis or CIA? Anyway, could this have something to do with the PCI & PCI bridge work that Richard and Ivan just submitted? - Pete > > Here's the backtrace: > > scsi_wait_req (SRpnt=0xfc0001f9b480, cmnd=0xfc89a078, > buffer=0x100, bufflen=2, timeout=17891584, retries=6144) > at /usr/src/linux/include/asm/atomic.h:85 > (gdb) where > #0 scsi_wait_req (SRpnt=0xfc0001f9b480, cmnd=0xfc89a078, > buffer=0x100, bufflen=2, timeout=17891584, retries=6144) > at /usr/src/linux/include/asm/atomic.h:85 > #1 0xfc4107f0 in scan_scsis_single (channel=0, dev=41080, lun=0, > max_dev_lun=0xfc1efa30, sparse_lun=0xfc1efa34, > SDpnt2=0xfc1efa38, shpnt=0xfc5ff800, > scsi_result=0xfc1ef930 "\001") at scsi_scan.c:516 > #2 0xfc410548 in scan_scsis (shpnt=0xfc5ff800, hardcoded=1, > hchannel=0, hid=0, hlun=0) at scsi_scan.c:403 > #3 0xfc404f58 in scsi_register_host (tpnt=0xfc58fb80) > at scsi.c:1904 > #4 0xfc4dac50 in init_this_scsi_driver () > #5 0xfc4c2bec in do_initcalls () > #6 0xfc4c2c6c in do_basic_setup () > #7 0xfc310078 in init (unused=0x0) at init/main.c:775 > > > Note: On the working kernels, the two controllers are 0x800 apart, but > on the broken kernels, they are only 0x400. Could the overlap > cause problems? > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Hi Phil, Phillip Ezolt wrote: Hi All, Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal WorkStation 600au). When starting up, we get a machine check after initialing the qlogic SCSI code. Using the Alpha kgdb, we figured out that the code is dying in scsi_wait_request(). Wow, I'm impressed! I didn't realize that kgdb worked on Alpha...Were you using the remote kgdb? (You can answer me offline to save bandwidth.) This would be a _huge_ help in trying to figure out why my Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I stole from Jay and have been hacking on. Speaking of that system, it has two QLogic adapters in it (both 1040Bs, like the Miata), and they are working just fine under 2.4.0-test11 (obviously, without my changes ;). It looks like it's probably the platform code that's busted. I can't remember...are those Pyxis or CIA? Anyway, could this have something to do with the PCI PCI bridge work that Richard and Ivan just submitted? - Pete Here's the backtrace: scsi_wait_req (SRpnt=0xfc0001f9b480, cmnd=0xfc89a078, buffer=0x100, bufflen=2, timeout=17891584, retries=6144) at /usr/src/linux/include/asm/atomic.h:85 (gdb) where #0 scsi_wait_req (SRpnt=0xfc0001f9b480, cmnd=0xfc89a078, buffer=0x100, bufflen=2, timeout=17891584, retries=6144) at /usr/src/linux/include/asm/atomic.h:85 #1 0xfc4107f0 in scan_scsis_single (channel=0, dev=41080, lun=0, max_dev_lun=0xfc1efa30, sparse_lun=0xfc1efa34, SDpnt2=0xfc1efa38, shpnt=0xfc5ff800, scsi_result=0xfc1ef930 "\001") at scsi_scan.c:516 #2 0xfc410548 in scan_scsis (shpnt=0xfc5ff800, hardcoded=1, hchannel=0, hid=0, hlun=0) at scsi_scan.c:403 #3 0xfc404f58 in scsi_register_host (tpnt=0xfc58fb80) at scsi.c:1904 #4 0xfc4dac50 in init_this_scsi_driver () #5 0xfc4c2bec in do_initcalls () #6 0xfc4c2c6c in do_basic_setup () #7 0xfc310078 in init (unused=0x0) at init/main.c:775 Note: On the working kernels, the two controllers are 0x800 apart, but on the broken kernels, they are only 0x400. Could the overlap cause problems? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Alpha SCSI error on 2.4.0-test11
Its probaly due to the semaphore changes that went in to test11 by Richard Henderson. scsi_wait_req will grab one on entry. Did test10 work for you on Alpha? Regards, Torben Mathiasen -Original Message- From: Rival, Frank Sent: 30. november 2000 21:37 To: Ezolt, Phillip Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Estabrook, Jay; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Alpha SCSI error on 2.4.0-test11 Hi Phil, Phillip Ezolt wrote: Hi All, Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal WorkStation 600au). When starting up, we get a machine check after initialing the qlogic SCSI code. Using the Alpha kgdb, we figured out that the code is dying in scsi_wait_request(). Wow, I'm impressed! I didn't realize that kgdb worked on Alpha...Were you using the remote kgdb? (You can answer me offline to save bandwidth.) This would be a _huge_ help in trying to figure out why my Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I stole from Jay and have been hacking on. Speaking of that system, it has two QLogic adapters in it (both 1040Bs, like the Miata), and they are working just fine under 2.4.0-test11 (obviously, without my changes ;). It looks like it's probably the platform code that's busted. I can't remember...are those Pyxis or CIA? Anyway, could this have something to do with the PCI PCI bridge work that Richard and Ivan just submitted? - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Thu, Nov 30, 2000 at 03:02:42PM -0500, Phillip Ezolt wrote: Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal WorkStation 600au). When starting up, we get a machine check after initialing the qlogic SCSI code. Try test12-pre3 - there is the new PCI init stuff. It works (to some degree) on as1000a with the same qlogic scsi. Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
Ivan, We dug a little deeper, and think that we found the problem. The error occurs if we have over 1024 MB of memory in the machine. If we have less than 1024MB, the machine behaves correctly. (This is a 600Mhz Digital Personal Workstation) Once again, the 2.2 kernel in RH 7.0 behaves properly. I'll give test12-pre3 a try and see if it fixes things. Thanks, --Phil Compaq: High Performance Server Division/Benchmark Performance Engineering Alpha, The Fastest Processor on Earth [EMAIL PROTECTED]|C|O|M|P|A|Q|[EMAIL PROTECTED] --- See the results at www.spec.org --- On Fri, 1 Dec 2000, Ivan Kokshaysky wrote: On Thu, Nov 30, 2000 at 03:02:42PM -0500, Phillip Ezolt wrote: Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal WorkStation 600au). When starting up, we get a machine check after initialing the qlogic SCSI code. Try test12-pre3 - there is the new PCI init stuff. It works (to some degree) on as1000a with the same qlogic scsi. Ivan. ___ Axp-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/axp-list - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Thu, Nov 30, 2000 at 05:26:58PM -0500, Phillip Ezolt wrote:
I'll give test12-pre3 a try and see if it fixes things.
test12-pre2 crashes at boot on my DS20. This patch workaround the problem
but I would be _very_ surprised if this is the right fix :) It's obviously not
meant for inclusion.
--- 2.4.0-test12-pre2-alpha/drivers/pci/setup-res.c.~1~ Tue Nov 28 18:40:29 2000
+++ 2.4.0-test12-pre2-alpha/drivers/pci/setup-res.c Wed Nov 29 03:15:45 2000
@@ -148,8 +148,11 @@
continue;
for (list = head; ; list = list-next) {
unsigned long size = 0;
- struct resource_list *ln = list-next;
+ struct resource_list *ln;
+ if (!list)
+ return;
+ ln = list-next;
if (ln)
size = ln-res-end - ln-res-start;
if (r-end - r-start size) {
I prefer to finish the ASN SMP rework before looking into this.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
