* [parisc-linux] Strange newest LAB msg? @ 2006-03-31 15:26 Joel Soete 2006-03-31 15:54 ` Matthew Wilcox 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2006-03-31 15:26 UTC (permalink / raw) To: Parisc List Hello all, Just noticed on n4k with recent kernel: [snip] Mar 31 11:45:39 patst006 kernel: Linux version 2.6.16-pa8-n4kmp (root@patst006) (gcc version 4.0.3 (Debian 4.0.3-1)) #212 SMP Tue Ma r 28 12:30:16 CEST 2006 [snip] Mar 31 11:45:39 patst006 kernel: CPU(s): 2 x PA8600 (PCX-W+) at 550.00000= 0 MHz Mar 31 11:45:39 patst006 kernel: Whole cache flush 199180 cycles, flushin= g 5369080 bytes 1536791 cycles Mar 31 11:45:39 patst006 kernel: Setting cache flush threshold to a9e80 (= 2 CPUs online) Mar 31 11:45:39 patst006 kernel: SBA found Ike rev 2 at 0xfffffffffed0000= 0 Mar 31 11:45:39 patst006 kernel: SBA found Ike rev 2 at 0xfffffffffed4000= 0 Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffe0000 Mar 31 11:45:39 patst006 kernel: iosapic: no IRTE for 0000:00:04.0 (IRQ n= ot connected?) Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffe2000 Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffe4000 Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffe8000 Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffea000 Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbfff0000 Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbfff4000 Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbfff8000 Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffece0000 Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffece4000 Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffece8000 Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffecf0000 Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffecf4000 Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space = - use vmalloc=3D<size> to increase size. Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffecf8000 Mar 31 11:45:39 patst006 kernel: SCSI subsystem initialized Mar 31 11:45:39 patst006 kernel: unwind_init: start =3D 0x10451cc0, end =3D= 0x10472e10, entries =3D 8469 Mar 31 11:45:39 patst006 kernel: Performance monitoring counters enabled = for Unknown machine Mar 31 11:45:39 patst006 kernel: Initializing Cryptographic API Mar 31 11:45:39 patst006 kernel: io scheduler noop registered Mar 31 11:45:39 patst006 kernel: io scheduler anticipatory registered (de= fault) [...] (with a previous kernel Feb 13 13:47:20 patst006 kernel: Linux version 2.6.16-rc3-pa0-n4kmp (root@patst006) (gcc version 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)) #14 SMP Mon Feb 13 13:05:14 CET 2006 Feb 13 13:47:20 patst006 kernel: CPU(s): 2 x PA8600 (PCX-W+) at 550.00000= 0 MHz Feb 13 13:47:20 patst006 kernel: Whole cache flush 217577 cycles, flushin= g 5352456 bytes 1498027 cycles Feb 13 13:47:20 patst006 kernel: Setting cache flush threshold to bdcc0 (= 2 CPUs online) Feb 13 13:47:20 patst006 kernel: SBA found Ike rev 2 at 0xfffffffffed0000= 0 Feb 13 13:47:20 patst006 kernel: SBA found Ike rev 2 at 0xfffffffffed4000= 0 Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffe0000 Feb 13 13:47:20 patst006 kernel: iosapic: no IRTE for 0000:00:04.0 (IRQ n= ot connected?) Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffe2000 Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffe4000 Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffe8000 Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbffea000 Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbfff0000 Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbfff4000 Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xffffffffbfff8000 Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffece0000 Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffece4000 Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffece8000 Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffecf0000 Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (c= learing) Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffecf4000 Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at 0xfffffffffecf8000 Feb 13 13:47:20 patst006 kernel: SCSI subsystem initialized Feb 13 13:47:20 patst006 kernel: unwind_init: start =3D 0x10452ce0, end =3D= 0x10473d50, entries =3D 8455 Feb 13 13:47:20 patst006 kernel: Performance monitoring counters enabled = for Unknown machine Feb 13 13:47:20 patst006 kernel: Initializing Cryptographic API [snip] ) Joel=0A=0A---------------------------------------------------------------= =0AA free anti-spam and anti-virus filter on all Scarlet mailboxes=0AMore= info on http://www.scarlet.be/ _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-03-31 15:26 [parisc-linux] Strange newest LAB msg? Joel Soete @ 2006-03-31 15:54 ` Matthew Wilcox 2006-04-01 7:02 ` Grant Grundler 0 siblings, 1 reply; 17+ messages in thread From: Matthew Wilcox @ 2006-03-31 15:54 UTC (permalink / raw) To: Joel Soete; +Cc: Parisc List Just so nobody else has to scratch their head looking at two almost-identical dumps, the message Joel means is > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. Either we're leaking vmalloc space, we allocate too much of it, or we need to drastically increase it the amount of it we have available. On Fri, Mar 31, 2006 at 04:26:38PM +0100, Joel Soete wrote: > Hello all, > > Just noticed on n4k with recent kernel: > [snip] > Mar 31 11:45:39 patst006 kernel: Linux version 2.6.16-pa8-n4kmp > (root@patst006) (gcc version 4.0.3 (Debian 4.0.3-1)) #212 SMP Tue Ma > r 28 12:30:16 CEST 2006 > [snip] > Mar 31 11:45:39 patst006 kernel: CPU(s): 2 x PA8600 (PCX-W+) at 550.000000 MHz > Mar 31 11:45:39 patst006 kernel: Whole cache flush 199180 cycles, flushing > 5369080 bytes 1536791 cycles > Mar 31 11:45:39 patst006 kernel: Setting cache flush threshold to a9e80 (2 > CPUs online) > Mar 31 11:45:39 patst006 kernel: SBA found Ike rev 2 at 0xfffffffffed00000 > Mar 31 11:45:39 patst006 kernel: SBA found Ike rev 2 at 0xfffffffffed40000 > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffe0000 > Mar 31 11:45:39 patst006 kernel: iosapic: no IRTE for 0000:00:04.0 (IRQ not > connected?) > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffe2000 > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffe4000 > Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffe8000 > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffea000 > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbfff0000 > Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbfff4000 > Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbfff8000 > Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffece0000 > Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffece4000 > Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffece8000 > Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffecf0000 > Mar 31 11:45:39 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Mar 31 11:45:39 patst006 kernel: NOTICE: Enabling PCI Arbitration > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffecf4000 > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > vmalloc=<size> to increase size. > Mar 31 11:45:39 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffecf8000 > Mar 31 11:45:39 patst006 kernel: SCSI subsystem initialized > Mar 31 11:45:39 patst006 kernel: unwind_init: start = 0x10451cc0, end = > 0x10472e10, entries = 8469 > Mar 31 11:45:39 patst006 kernel: Performance monitoring counters enabled for > Unknown machine > Mar 31 11:45:39 patst006 kernel: Initializing Cryptographic API > Mar 31 11:45:39 patst006 kernel: io scheduler noop registered > Mar 31 11:45:39 patst006 kernel: io scheduler anticipatory registered (default) > [...] > > (with a previous kernel > Feb 13 13:47:20 patst006 kernel: Linux version 2.6.16-rc3-pa0-n4kmp > (root@patst006) (gcc version 4.0.3 20060128 (prerelease) (Debian > 4.0.2-8)) #14 SMP Mon Feb 13 13:05:14 CET 2006 > Feb 13 13:47:20 patst006 kernel: CPU(s): 2 x PA8600 (PCX-W+) at 550.000000 MHz > Feb 13 13:47:20 patst006 kernel: Whole cache flush 217577 cycles, flushing > 5352456 bytes 1498027 cycles > Feb 13 13:47:20 patst006 kernel: Setting cache flush threshold to bdcc0 (2 > CPUs online) > Feb 13 13:47:20 patst006 kernel: SBA found Ike rev 2 at 0xfffffffffed00000 > Feb 13 13:47:20 patst006 kernel: SBA found Ike rev 2 at 0xfffffffffed40000 > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffe0000 > Feb 13 13:47:20 patst006 kernel: iosapic: no IRTE for 0000:00:04.0 (IRQ not > connected?) > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffe2000 > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffe4000 > Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffe8000 > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbffea000 > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbfff0000 > Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbfff4000 > Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xffffffffbfff8000 > Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffece0000 > Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffece4000 > Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffece8000 > Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffecf0000 > Feb 13 13:47:20 patst006 kernel: NOTICE: PCI bus reset still asserted! (clearing) > Feb 13 13:47:20 patst006 kernel: NOTICE: Enabling PCI Arbitration > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffecf4000 > Feb 13 13:47:20 patst006 kernel: LBA version TR4.0 (0x5) found at > 0xfffffffffecf8000 > Feb 13 13:47:20 patst006 kernel: SCSI subsystem initialized > Feb 13 13:47:20 patst006 kernel: unwind_init: start = 0x10452ce0, end = > 0x10473d50, entries = 8455 > Feb 13 13:47:20 patst006 kernel: Performance monitoring counters enabled for > Unknown machine > Feb 13 13:47:20 patst006 kernel: Initializing Cryptographic API > [snip] > ) > > Joel > > --------------------------------------------------------------- > A free anti-spam and anti-virus filter on all Scarlet mailboxes > More info on http://www.scarlet.be/ > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-03-31 15:54 ` Matthew Wilcox @ 2006-04-01 7:02 ` Grant Grundler 2006-04-01 7:35 ` Helge Deller 0 siblings, 1 reply; 17+ messages in thread From: Grant Grundler @ 2006-04-01 7:02 UTC (permalink / raw) To: Matthew Wilcox; +Cc: Parisc List On Fri, Mar 31, 2006 at 08:54:48AM -0700, Matthew Wilcox wrote: > > Just so nobody else has to scratch their head looking at two > almost-identical dumps, the message Joel means is > > > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > > vmalloc=<size> to increase size. Ah - thanks. I saw that but wasn't sure it was the cause of discussion. > Either we're leaking vmalloc space, we allocate too much of it, or we > need to drastically increase it the amount of it we have available. It's odd that vmalloc fails so early in the boot sequence. At least the last 10 (of 14) PCI busses fail with the "allocation failed" message. Could this somehow be related to the IOREMAP changes? grant _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-01 7:02 ` Grant Grundler @ 2006-04-01 7:35 ` Helge Deller 2006-04-01 14:30 ` James Bottomley 0 siblings, 1 reply; 17+ messages in thread From: Helge Deller @ 2006-04-01 7:35 UTC (permalink / raw) To: parisc-linux; +Cc: Matthew Wilcox On Saturday 01 April 2006 09:02, Grant Grundler wrote: > On Fri, Mar 31, 2006 at 08:54:48AM -0700, Matthew Wilcox wrote: > > > > Just so nobody else has to scratch their head looking at two > > almost-identical dumps, the message Joel means is > > > > > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use > > > vmalloc=<size> to increase size. > > Ah - thanks. I saw that but wasn't sure it was the cause of discussion. > > > Either we're leaking vmalloc space, we allocate too much of it, or we > > need to drastically increase it the amount of it we have available. > > It's odd that vmalloc fails so early in the boot sequence. > At least the last 10 (of 14) PCI busses fail with the > "allocation failed" message. > Could this somehow be related to the IOREMAP changes? I'm pretty sure. We never vmalloc'ed IOmem before. Helge _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-01 7:35 ` Helge Deller @ 2006-04-01 14:30 ` James Bottomley 2006-04-02 9:29 ` Helge Deller 0 siblings, 1 reply; 17+ messages in thread From: James Bottomley @ 2006-04-01 14:30 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux, Matthew Wilcox On Sat, 2006-04-01 at 09:35 +0200, Helge Deller wrote: > I'm pretty sure. > We never vmalloc'ed IOmem before. Where are you taking the ioremap virtual range from? If it's the vmalloc range, which is the only one I can think we have available for arbitrary kernel mappings, then that would explain the behaviour. James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-01 14:30 ` James Bottomley @ 2006-04-02 9:29 ` Helge Deller 2006-04-02 11:18 ` Joel Soete 0 siblings, 1 reply; 17+ messages in thread From: Helge Deller @ 2006-04-02 9:29 UTC (permalink / raw) To: James Bottomley, Joel Soete; +Cc: parisc-linux, Matthew Wilcox [-- Attachment #1: Type: text/plain, Size: 1514 bytes --] On Saturday 01 April 2006 16:30, James Bottomley wrote: > On Sat, 2006-04-01 at 09:35 +0200, Helge Deller wrote: > > I'm pretty sure. > > We never vmalloc'ed IOmem before. > > Where are you taking the ioremap virtual range from? If it's the > vmalloc range, which is the only one I can think we have available for > arbitrary kernel mappings, then that would explain the behaviour. Correct. ioremap() calls get_vm_area(), which in turn gets it from __get_vm_area(size, flags, VMALLOC_START, VMALLOC_END); VMALLOC_START seems to be at 32KB, while VMALLOC_END at around 240MB. This means we have ~240MB of IO-Space which seems to little for the N4k. Willy said in another mail: > Either we're leaking vmalloc space, we allocate too much of it, or we > need to drastically increase it the amount of it we have available. I think Willy is right. We probably don't leak in ioremap(), since we use the standard Linux kernel functions. I would propose to analyze how much the 14 PCI busses wants to allocate, and if they free it correctly and if they might leak. Might this be the culprit: (lba_pci.c:1216) case PAT_PIOP: /* ** Postable I/O port space is per PCI host adapter. ** base of 64MB PIOP region */ lba_dev->iop_base = ioremap_nocache(p->start, 64 * 1024 * 1024); It allocates 64MB in a loop. Joel, can you apply the attached patch and send us the bootlog of the N4k with it ? Helge [-- Attachment #2: t --] [-- Type: text/plain, Size: 709 bytes --] Index: ioremap.c =================================================================== RCS file: /var/cvs/linux-2.6/arch/parisc/mm/ioremap.c,v retrieving revision 1.16 diff -u -p -r1.16 ioremap.c --- ioremap.c 29 Mar 2006 22:18:32 -0000 1.16 +++ ioremap.c 2 Apr 2006 09:27:59 -0000 @@ -181,6 +181,9 @@ void __iomem * __ioremap(unsigned long p phys_addr &= PAGE_MASK; size = PAGE_ALIGN(last_addr) - phys_addr; + + printk("IOREMAP: phys=%lx, size=%lx\n", phys_addr, size); + /* * Ok, go for it.. */ @@ -193,6 +196,8 @@ void __iomem * __ioremap(unsigned long p vfree(addr); return NULL; } + + printk("IOREMAP: remapped to %p\n", addr); return (void __iomem *) (offset + (char *)addr); } [-- Attachment #3: Type: text/plain, Size: 169 bytes --] _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-02 9:29 ` Helge Deller @ 2006-04-02 11:18 ` Joel Soete 2006-04-02 13:15 ` Helge Deller 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2006-04-02 11:18 UTC (permalink / raw) To: Helge Deller; +Cc: James Bottomley, parisc-linux, Matthew Wilcox Hello Helge, Helge Deller wrote: > On Saturday 01 April 2006 16:30, James Bottomley wrote: > >>On Sat, 2006-04-01 at 09:35 +0200, Helge Deller wrote: >> >>>I'm pretty sure. >>>We never vmalloc'ed IOmem before. >> >>Where are you taking the ioremap virtual range from? If it's the >>vmalloc range, which is the only one I can think we have available for >>arbitrary kernel mappings, then that would explain the behaviour. > > > Correct. > ioremap() calls get_vm_area(), which in turn gets it from __get_vm_area(size, flags, VMALLOC_START, VMALLOC_END); > VMALLOC_START seems to be at 32KB, while VMALLOC_END at around 240MB. > This means we have ~240MB of IO-Space which seems to little for the N4k. > > Willy said in another mail: > >>Either we're leaking vmalloc space, we allocate too much of it, or we >>need to drastically increase it the amount of it we have available. > > > I think Willy is right. > We probably don't leak in ioremap(), since we use the standard Linux kernel functions. > I would propose to analyze how much the 14 PCI busses wants to allocate, and if they free it correctly and if they might leak. > > Might this be the culprit: > (lba_pci.c:1216) > case PAT_PIOP: > /* > ** Postable I/O port space is per PCI host adapter. > ** base of 64MB PIOP region > */ > lba_dev->iop_base = ioremap_nocache(p->start, 64 * 1024 * 1024); > It allocates 64MB in a loop. > > Joel, can you apply the attached patch and send us the bootlog of the N4k with it ? > > Helge Here there are: [snip] Interact with IPL (Y, N, or Cancel)?> n Booting... Boot IO Dependent Code (IODC) revision 1 HARD Booted. palo ipl 1.9 root@c3k Wed Jul 20 12:51:49 MDT 2005 Skipping extended partition 7 - beyond reach of IPL Partition Start(MB) End(MB) Id Type 1 1 61 f0 Palo 2 62 306 82 swap 3 307 367 83 ext2 5 368 1953 83 ext2 6 1954 2197 83 ext2 PALO(F0) partition contains: Information: No console specified on kernel command line. This is normal. PALO will choose the console currently used by firmware (serial). Command line for kernel: 'root=/dev/sda5 HOME=/ panic=30 profile=2 console=ttyS0 TERM=vt102 palo_kernel=3/vmlinux' Selected kernel: /vmlinux from partition 3 ELF64 executable Entry 00100000 first 00100000 n 3 Segment 0 load 00100000 size 4417856 mediaptr 0x1000 Segment 1 load 00538000 size 344208 mediaptr 0x438000 Segment 2 load 00590000 size 303760 mediaptr 0x48d000 Branching to kernel entry point 0x00100000. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org Linux version 2.6.16.1-pa10-n4kmp (root@patst006) (gcc version 4.0.3 (Debian 4.0.3-1)) #698 SMP Sun Apr 2 12:22:58 CEST 2006 FP[0] enabled: Rev 1 Model 16 The 64-bit Kernel has started... Initialized PDC Console for debugging. Determining PDC firmware type: 64 bit PAT. model 00005d30 00000491 00000000 00000002 27988e5d 100000f1 00000008 000000b2 000000b2 vers 00000301 CPUID vers 18 rev 11 (0x0000024b) capabilities 0x1 model 9000/800/N4000-55 Memory Ranges: 0) Start 0x0000000000000000 End 0x000000007fffffff Size 2048 MB 1) Start 0x0000000180000000 End 0x00000001ffffffff Size 2048 MB Total Memory: 4096 MB SMP: bootstrap CPU ID is 0 Built 2 zonelists Kernel command line: root=/dev/sda5 HOME=/ panic=30 profile=2 console=ttyS0 TERM=vt102 palo_kernel=3/vmlinux kernel profiling enabled (shift: 2) PID hash table entries: 4096 (order: 12, 131072 bytes) Console: colour dummy device 160x64 Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes) Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes) Memory: 4194304k available Mount-cache hash table entries: 256 Brought up 1 CPUs migration_cost=0 NET: Registered protocol family 16 Searching for devices... Found devices: 1. Unknown machine at 0xfffffffffed25000 [37] { 0, 0x0, 0x5d3, 0x00000 } 2. Unknown machine at 0xfffffffffed2d000 [45] { 0, 0x0, 0x5d3, 0x00000 } 3. DEW BC Runway Port at 0xfffffffffed24000 [36] { 7, 0x0, 0x584, 0x0000c } 4. DEW BC Runway Port at 0xfffffffffed2c000 [44] { 7, 0x0, 0x584, 0x0000c } 5. Memory at 0xfffffffffedc0000 [192] { 1, 0x0, 0x090, 0x00009 } 6. IKE I/O BC Merced Port at 0xfffffffffed00000 [0] { 7, 0x0, 0x803, 0x0000c } 7. Elroy PCI Bridge at 0xffffffffbffe0000 [0/0] { 13, 0x0, 0x782, 0x0000a } 8. Elroy PCI Bridge at 0xffffffffbffe2000 [0/1] { 13, 0x0, 0x782, 0x0000a } 9. Elroy PCI Bridge at 0xffffffffbffe4000 [0/2] { 13, 0x0, 0x782, 0x0000a } 10. Elroy PCI Bridge at 0xffffffffbffe8000 [0/4] { 13, 0x0, 0x782, 0x0000a } 11. Elroy PCI Bridge at 0xffffffffbffea000 [0/5] { 13, 0x0, 0x782, 0x0000a } 12. Elroy PCI Bridge at 0xffffffffbfff0000 [0/8] { 13, 0x0, 0x782, 0x0000a } 13. Elroy PCI Bridge at 0xffffffffbfff4000 [0/10] { 13, 0x0, 0x782, 0x0000a } 14. Elroy PCI Bridge at 0xffffffffbfff8000 [0/12] { 13, 0x0, 0x782, 0x0000a } 15. IKE I/O BC Merced Port at 0xfffffffffed40000 [1] { 7, 0x0, 0x803, 0x0000c } 16. Elroy PCI Bridge at 0xfffffffffece0000 [1/0] { 13, 0x0, 0x782, 0x0000a } 17. Elroy PCI Bridge at 0xfffffffffece4000 [1/2] { 13, 0x0, 0x782, 0x0000a } 18. Elroy PCI Bridge at 0xfffffffffece8000 [1/4] { 13, 0x0, 0x782, 0x0000a } 19. Elroy PCI Bridge at 0xfffffffffecf0000 [1/8] { 13, 0x0, 0x782, 0x0000a } 20. Elroy PCI Bridge at 0xfffffffffecf4000 [1/10] { 13, 0x0, 0x782, 0x0000a } 21. Elroy PCI Bridge at ********** VIRTUAL FRONT PANEL ********** System Boot detected ***************************************** LEDs: RUN ATTENTION FAULT REMOTE POWER ON OFF OFF ON ON LED State: System running normally. processor system initialization 1C00 ***************************************** ************ EARLY BOOT VFP ************* End of early boot detected ***************************************** Releasing cpu 1 now, hpa=fffffffffed2d000 FP[1] enabled: Rev 1 Model 16 migration_cost=1000 CPU(s): 2 x PA8600 (PCX-W+) at 550.000000 MHz Setting cache flush threshold to ad700 (2 CPUs online) IOREMAP: phys=fffffffffed00000, size=1000 IOREMAP: remapped to 0000000000008000 SBA found Ike rev 2 at 0xfffffffffed00000 IOREMAP: phys=fffffffffed02000, size=1000 IOREMAP: remapped to 000000000000a000 IOREMAP: phys=fffffffffed03000, size=1000 IOREMAP: remapped to 000000000000c000 IOREMAP: phys=ffffffffbffe0000, size=1000 IOREMAP: remapped to 000000000000e000 IOREMAP: phys=ffffffffbffe2000, size=1000 IOREMAP: remapped to 0000000000010000 IOREMAP: phys=ffffffffbffe4000, size=1000 IOREMAP: remapped to 0000000000012000 IOREMAP: phys=ffffffffbffe8000, size=1000 IOREMAP: remapped to 0000000000014000 IOREMAP: phys=ffffffffbffea000, size=1000 IOREMAP: remapped to 0000000000016000 IOREMAP: phys=ffffffffbfff0000, size=1000 IOREMAP: remapped to 0000000000018000 IOREMAP: phys=ffffffffbfff4000, size=1000 IOREMAP: remapped to 000000000001a000 IOREMAP: phys=ffffffffbfff8000, size=1000 IOREMAP: remapped to 000000000001c000 IOREMAP: phys=fffffffffed40000, size=1000 IOREMAP: remapped to 000000000001e000 SBA found Ike rev 2 at 0xfffffffffed40000 IOREMAP: phys=fffffffffed42000, size=1000 IOREMAP: remapped to 0000000000020000 IOREMAP: phys=fffffffffed43000, size=1000 IOREMAP: remapped to 0000000000022000 IOREMAP: phys=fffffffffece0000, size=1000 IOREMAP: remapped to 0000000000024000 IOREMAP: phys=fffffffffece4000, size=1000 IOREMAP: remapped to 0000000000026000 IOREMAP: phys=fffffffffece8000, size=1000 IOREMAP: remapped to 0000000000028000 IOREMAP: phys=fffffffffecf0000, size=1000 IOREMAP: remapped to 000000000002a000 IOREMAP: phys=fffffffffecf4000, size=1000 IOREMAP: remapped to 000000000002c000 IOREMAP: phys=fffffffffecf8000, size=1000 IOREMAP: remapped to 000000000002e000 IOREMAP: phys=ffffffffbffe0000, size=1000 IOREMAP: remapped to 0000000000030000 LBA version TR4.0 (0x5) found at 0xffffffffbffe0000 IOREMAP: phys=ffffffffbffe0000, size=2000 IOREMAP: remapped to 0000000000034000 IOREMAP: phys=fffffff000000000, size=4000000 IOREMAP: remapped to 0000000000080000 iosapic: no IRTE for 0000:00:04.0 (IRQ not connected?) IOREMAP: phys=ffffffffbffe2000, size=1000 IOREMAP: remapped to 0000000000032000 LBA version TR4.0 (0x5) found at 0xffffffffbffe2000 IOREMAP: phys=ffffffffbffe2000, size=2000 IOREMAP: remapped to 0000000000038000 IOREMAP: phys=fffffff080000000, size=4000000 IOREMAP: remapped to 0000000004100000 IOREMAP: phys=ffffffffbffe4000, size=1000 IOREMAP: remapped to 000000000003c000 LBA version TR4.0 (0x5) found at 0xffffffffbffe4000 IOREMAP: phys=ffffffffbffe4000, size=2000 IOREMAP: remapped to 0000000000040000 IOREMAP: phys=fffffff100000000, size=4000000 IOREMAP: remapped to 0000000008180000 IOREMAP: phys=ffffffffbffe8000, size=1000 IOREMAP: remapped to 000000000003e000 LBA version TR4.0 (0x5) found at 0xffffffffbffe8000 IOREMAP: phys=ffffffffbffe8000, size=2000 IOREMAP: remapped to 0000000000044000 IOREMAP: phys=fffffff200000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=ffffffffbffea000, size=1000 IOREMAP: remapped to 0000000000048000 LBA version TR4.0 (0x5) found at 0xffffffffbffea000 IOREMAP: phys=ffffffffbffea000, size=2000 IOREMAP: remapped to 000000000004c000 IOREMAP: phys=fffffff280000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=ffffffffbfff0000, size=1000 IOREMAP: remapped to 000000000004a000 LBA version TR4.0 (0x5) found at 0xffffffffbfff0000 IOREMAP: phys=ffffffffbfff0000, size=2000 IOREMAP: remapped to 0000000000050000 IOREMAP: phys=fffffff400000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=ffffffffbfff4000, size=1000 IOREMAP: remapped to 0000000000054000 LBA version TR4.0 (0x5) found at 0xffffffffbfff4000 IOREMAP: phys=ffffffffbfff4000, size=2000 IOREMAP: remapped to 0000000000058000 IOREMAP: phys=fffffff500000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=ffffffffbfff8000, size=1000 IOREMAP: remapped to 0000000000056000 LBA version TR4.0 (0x5) found at 0xffffffffbfff8000 IOREMAP: phys=ffffffffbfff8000, size=2000 IOREMAP: remapped to 000000000005c000 IOREMAP: phys=fffffff600000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=fffffffffece0000, size=1000 IOREMAP: remapped to 0000000000060000 LBA version TR4.0 (0x5) found at 0xfffffffffece0000 IOREMAP: phys=fffffffffece0000, size=2000 IOREMAP: remapped to 0000000000064000 IOREMAP: phys=fffffff800000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=fffffffffece4000, size=1000 IOREMAP: remapped to 0000000000062000 LBA version TR4.0 (0x5) found at 0xfffffffffece4000 IOREMAP: phys=fffffffffece4000, size=2000 IOREMAP: remapped to 0000000000068000 IOREMAP: phys=fffffff900000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=fffffffffece8000, size=1000 IOREMAP: remapped to 000000000006c000 LBA version TR4.0 (0x5) found at 0xfffffffffece8000 IOREMAP: phys=fffffffffece8000, size=2000 IOREMAP: remapped to 0000000000070000 IOREMAP: phys=fffffffa00000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=fffffffffecf0000, size=1000 IOREMAP: remapped to 000000000006e000 LBA version TR4.0 (0x5) found at 0xfffffffffecf0000 IOREMAP: phys=fffffffffecf0000, size=2000 IOREMAP: remapped to 0000000000074000 IOREMAP: phys=fffffffc00000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=fffffffffecf4000, size=1000 IOREMAP: remapped to 0000000000078000 LBA version TR4.0 (0x5) found at 0xfffffffffecf4000 IOREMAP: phys=fffffffffecf4000, size=2000 IOREMAP: remapped to 000000000007c000 IOREMAP: phys=fffffffd00000000, size=4000000 allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. IOREMAP: phys=fffffffffecf8000, size=1000 IOREMAP: remapped to 000000000007a000 LBA version TR4.0 (0x5) found at 0xfffffffffecf8000 IOREMAP: phys=fffffffffecf8000, size=2000 IOREMAP: remapped to 0000000004084000 IOREMAP: phys=fffffffe00000000, size=4000000 SCSI subsystem initialized unwind_init: start = 0x10451cc0, end = 0x10472e30, entries = 8471 Performance monitoring counters enabled for Unknown machine Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered PDC Stable Storage facility v0.22 Soft power switch support not available. Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled IOREMAP: phys=ffffffff80000000, size=1000 IOREMAP: remapped to 0000000004082000 0000:00:04.1: ttyS0 at MMIO 0xffffffff80000000 (irq = 22) is a 16550A 0000:00:04.1: ttyS1 at MMIO 0xffffffff80000008 (irq = 22) is a 16450 0000:00:04.1: ttyS2 at MMIO 0xffffffff80000010 (irq = 22) is a 16550A 0000:00:04.1: ttyS3 at MMIO 0xffffffff80000030 (irq = 22) is a 16550A Couldn't register serial port 0000:00:04.1: -28 RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize loop: loaded (max 8 devices) Linux Tulip driver version 1.1.13 (December 15, 2004) IOREMAP: phys=ffffffff80003000, size=1000 IOREMAP: remapped to 0000000004088000 tulip0: no phy info, aborting mtable build tulip0: MII transceiver #1 config 1000 status 782d advertising 01e1. eth0: Digital DS21142/DS21143 Tulip rev 65 at 0000000004088000, 00:30:6E:1C:B2:0B, IRQ 18. IOREMAP: phys=ffffffff8a040000, size=1000 IOREMAP: remapped to 000000000408a000 tulip1: EEPROM default media type Autosense. tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. tulip1: MII transceiver #1 config 3100 status 7849 advertising 0101. eth1: Digital DS21142/DS21143 Tulip rev 65 at 000000000408a000, 00:30:6E:21:14:B4, IRQ 24. IOREMAP: phys=ffffffff80080000, size=1000 IOREMAP: remapped to 000000000408c000 IOREMAP: phys=ffffffff80100000, size=1000 IOREMAP: remapped to 000000000408e000 sym0: <895> rev 0x1 at pci 0000:00:01.0 irq 19 sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking sym0: SCSI BUS has been reset. sym0: SCSI BUS mode change from SE to SE. scsi0 : sym-2.2.2 sym0: SCSI BUS has been reset. Vendor: HP Model: DVD-ROM 305 Rev: 1.01 Type: CD-ROM ANSI SCSI revision: 02 target0:0:1: Beginning Domain Validation target0:0:1: asynchronous target0:0:1: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16) target0:0:1: Domain Validation skipping write tests target0:0:1: Ending Domain Validation Vendor: HP Model: C1537A Rev: L105 Type: Sequential-Access ANSI SCSI revision: 02 target0:0:3: Beginning Domain Validation target0:0:3: asynchronous target0:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 31) target0:0:3: Domain Validation skipping write tests target0:0:3: Ending Domain Validation Vendor: SEAGATE Model: ST39103LW Rev: HP04 Type: Direct-Access ANSI SCSI revision: 02 target0:0:8: tagged command queuing enabled, command queue depth 16. target0:0:8: Beginning Domain Validation target0:0:8: asynchronous target0:0:8: wide asynchronous target0:0:8: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 15) target0:0:8: Domain Validation skipping write tests target0:0:8: Ending Domain Validation IOREMAP: phys=ffffffff80004000, size=1000 IOREMAP: remapped to 0000000004090000 IOREMAP: phys=ffffffff80001000, size=1000 IOREMAP: remapped to 0000000004092000 sym1: <875> rev 0x37 at pci 0000:00:02.0 irq 20 sym1: PA-RISC Firmware, ID 7, Fast-20, SE, parity checking sym1: SCSI BUS has been reset. scsi1 : sym-2.2.2 IOREMAP: phys=ffffffff80005000, size=1000 IOREMAP: remapped to 0000000004094000 IOREMAP: phys=ffffffff80002000, size=1000 IOREMAP: remapped to 0000000004096000 sym2: <875> rev 0x37 at pci 0000:00:02.1 irq 21 sym2: PA-RISC Firmware, ID 7, Fast-20, SE, parity checking sym2: SCSI BUS has been reset. scsi2 : sym-2.2.2 st: Version 20050830, fixed bufsize 32768, s/g segs 256 st 0:0:3:0: Attached scsi tape st0<4>st0: try direct i/o: yes (alignment 512 B) SCSI device sda: 17783112 512-byte hdwr sectors (9105 MB) sda: Write Protect is off SCSI device sda: drive cache: write back w/ FUA SCSI device sda: 17783112 512-byte hdwr sectors (9105 MB) sda: Write Protect is off SCSI device sda: drive cache: write back w/ FUA sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 > sd 0:0:8:0: Attached scsi disk sda sr0: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:1:0: Attached scsi generic sg0 type 5 st 0:0:3:0: Attached scsi generic sg1 type 1 sd 0:0:8:0: Attached scsi generic sg2 type 0 md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: bitmap version 4.39 NET: Registered protocol family 2 IP route cache hash table entries: 262144 (order: 9, 2097152 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: Badness in smp_call_function at /usr/src/linux-2.6.16.1-pa10/arch/parisc/kernel/smp.c:348 Backtrace: [<0000000010112900>] dump_stack+0x18/0x28 [<000000001011d9b4>] smp_call_function+0x37c/0x3c0 [<0000000010111c5c>] flush_data_cache+0x2c/0x48 [<00000000101109a8>] free_initmem+0x68/0x2f8 [<000000001010fb20>] init+0x858/0x8c8 [<000000001010347c>] ret_from_kernel_ ********** VIRTUAL FRONT PANEL ********** System Boot detected ***************************************** LEDs: RUN ATTENTION FAULT REMOTE POWER ON OFF OFF ON ON LED State: System running normally. processor system initialization 1C00 ***************************************** [snip] (this latest 'Badness in smp_call_function ...' was there but seems to be harmless and the boot continue without showing any more IOREMAP info ;-) ) Hth, Joel PS: btw, rm CONFIG_DETECT_SOFTLOCKUP in the config doesn't help on this system ;<(: still hanging (this time without Softlockup msg) after only: top - 09:04:58 up 1 day, 16:26, 3 users, load average: 2.40, 2.26, 2.20 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-02 11:18 ` Joel Soete @ 2006-04-02 13:15 ` Helge Deller 2006-04-02 14:29 ` Joel Soete 2006-04-03 1:28 ` Grant Grundler 0 siblings, 2 replies; 17+ messages in thread From: Helge Deller @ 2006-04-02 13:15 UTC (permalink / raw) To: parisc-linux On Sunday 02 April 2006 13:18, Joel Soete wrote: > > On Saturday 01 April 2006 16:30, James Bottomley wrote: > >>On Sat, 2006-04-01 at 09:35 +0200, Helge Deller wrote: > >>>I'm pretty sure. > >>>We never vmalloc'ed IOmem before. > >> > >>Where are you taking the ioremap virtual range from? If it's the > >>vmalloc range, which is the only one I can think we have available for > >>arbitrary kernel mappings, then that would explain the behaviour. > > > > > > Correct. > > ioremap() calls get_vm_area(), which in turn gets it from __get_vm_area(size, flags, VMALLOC_START, VMALLOC_END); > > VMALLOC_START seems to be at 32KB, while VMALLOC_END at around 240MB. > > This means we have ~240MB of IO-Space which seems to little for the N4k. > > > > Willy said in another mail: > > > >>Either we're leaking vmalloc space, we allocate too much of it, or we > >>need to drastically increase it the amount of it we have available. > > > > > > I think Willy is right. > > We probably don't leak in ioremap(), since we use the standard Linux kernel functions. > > I would propose to analyze how much the 14 PCI busses wants to allocate, and if they free it correctly and if they might leak. > > > > Might this be the culprit: > > (lba_pci.c:1216) > > case PAT_PIOP: > > /* > > ** Postable I/O port space is per PCI host adapter. > > ** base of 64MB PIOP region > > */ > > lba_dev->iop_base = ioremap_nocache(p->start, 64 * 1024 * 1024); > > It allocates 64MB in a loop. LOG ANALYSIS: > Setting cache flush threshold to ad700 (2 CPUs online) > IOREMAP: phys=fffffffffed00000, size=1000 > IOREMAP: remapped to 0000000000008000 STARTING HERE > SBA found Ike rev 2 at 0xfffffffffed00000 > IOREMAP: phys=fffffffffed02000, size=1000 > IOREMAP: remapped to 000000000000a000 OK, includes 4k filler > [...] > LBA version TR4.0 (0x5) found at 0xffffffffbffe0000 > IOREMAP: phys=ffffffffbffe0000, size=2000 > IOREMAP: remapped to 0000000000034000 > IOREMAP: phys=fffffff000000000, size=4000000 THIS IS THE 64MB ioremap() (see above) > IOREMAP: remapped to 0000000000080000 OK. > iosapic: no IRTE for 0000:00:04.0 (IRQ not connected?) > IOREMAP: phys=ffffffffbffe2000, size=1000 > IOREMAP: remapped to 0000000000032000 FILLS up in-between. > LBA version TR4.0 (0x5) found at 0xffffffffbffe2000 > IOREMAP: phys=ffffffffbffe2000, size=2000 > IOREMAP: remapped to 0000000000038000 > IOREMAP: phys=fffffff080000000, size=4000000 THE NEXT 64MB > IOREMAP: remapped to 0000000004100000 OK. > IOREMAP: phys=ffffffffbffe4000, size=1000 > IOREMAP: remapped to 000000000003c000 > LBA version TR4.0 (0x5) found at 0xffffffffbffe4000 > IOREMAP: phys=ffffffffbffe4000, size=2000 > IOREMAP: remapped to 0000000000040000 > IOREMAP: phys=fffffff100000000, size=4000000 ANOTHER 64MB > IOREMAP: remapped to 0000000008180000 WE ARE NOW at 008180000 > IOREMAP: phys=ffffffffbffe8000, size=1000 > IOREMAP: remapped to 000000000003e000 > LBA version TR4.0 (0x5) found at 0xffffffffbffe8000 > IOREMAP: phys=ffffffffbffe8000, size=2000 > IOREMAP: remapped to 0000000000044000 THIS SMALL ONE IS STILL OK. > IOREMAP: phys=fffffff200000000, size=4000000 BUT THIS BIG 64MB CHUNK FAILS. > allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. > IOREMAP: phys=ffffffffbffea000, size=1000 > IOREMAP: remapped to 0000000000048000 OTHER SMALLER ONES OK AGAIN.. > LBA version TR4.0 (0x5) found at 0xffffffffbffea000 So, the problem is really the 64MB ioremap() from lba_pci.c:1216. Grant, Willy, ... : Is it possible to reduce it or to iounmap() it again ? > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Mounted root (ext3 filesystem) readonly. > Freeing unused kernel memory: Badness in smp_call_function at /usr/src/linux-2.6.16.1-pa10/arch/parisc/kernel/smp.c:348 > Backtrace: > [<0000000010112900>] dump_stack+0x18/0x28 > [<000000001011d9b4>] smp_call_function+0x37c/0x3c0 > [<0000000010111c5c>] flush_data_cache+0x2c/0x48 > [<00000000101109a8>] free_initmem+0x68/0x2f8 > [<000000001010fb20>] init+0x858/0x8c8 > [<000000001010347c>] ret_from_kernel_ > (this latest 'Badness in smp_call_function ...' was there but seems to be harmless and the boot continue without showing any more > IOREMAP info ;-) ) WHAT'S THAT ? Do we have some __init too much ? I never tested SMP. > PS: btw, rm CONFIG_DETECT_SOFTLOCKUP in the config doesn't help on this system ;<(: > still hanging (this time without Softlockup msg) after only: > top - 09:04:58 up 1 day, 16:26, 3 users, load average: 2.40, 2.26, 2.20 I think the softlockups don't really matter. Does your box hangs without SMP as well ? Helge _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-02 13:15 ` Helge Deller @ 2006-04-02 14:29 ` Joel Soete 2006-04-03 1:28 ` Grant Grundler 1 sibling, 0 replies; 17+ messages in thread From: Joel Soete @ 2006-04-02 14:29 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux Helge Deller wrote: > On Sunday 02 April 2006 13:18, Joel Soete wrote: > [snip] > >>EXT3-fs: mounted filesystem with ordered data mode. >>VFS: Mounted root (ext3 filesystem) readonly. >>Freeing unused kernel memory: Badness in smp_call_function at /usr/src/linux-2.6.16.1-pa10/arch/parisc/kernel/smp.c:348 >>Backtrace: >> [<0000000010112900>] dump_stack+0x18/0x28 >> [<000000001011d9b4>] smp_call_function+0x37c/0x3c0 >> [<0000000010111c5c>] flush_data_cache+0x2c/0x48 >> [<00000000101109a8>] free_initmem+0x68/0x2f8 >> [<000000001010fb20>] init+0x858/0x8c8 >> [<000000001010347c>] ret_from_kernel_ >>(this latest 'Badness in smp_call_function ...' was there but seems to be harmless and the boot continue without showing any more >>IOREMAP info ;-) ) > > > WHAT'S THAT ? > Do we have some __init too much ? 337 smp_call_function (void (*func) (void *info), void *info, int retry, int wait) 338 { 339 struct smp_call_struct data; 340 unsigned long timeout; 341 static DEFINE_SPINLOCK(lock); 342 int retries = 0; 343 344 if (num_online_cpus() < 2) 345 return 0; 346 347 /* Can deadlock when called with interrupts disabled */ 348 WARN_ON(irqs_disabled()); 349 > I never tested SMP. > No pb ;-) > > >>PS: btw, rm CONFIG_DETECT_SOFTLOCKUP in the config doesn't help on this system ;<(: >>still hanging (this time without Softlockup msg) after only: >>top - 09:04:58 up 1 day, 16:26, 3 users, load average: 2.40, 2.26, 2.20 > > > I think the softlockups don't really matter. > Does your box hangs without SMP as well ? > well it did with b2k and n4k runing 64bit kernel with CONFIG_DETECT_SOFTLOCKUP=y && # CONFIG_SMP is not set but I need to verify now without CONFIG_DETECT_SOFTLOCKUP. (sorry I couldn't do it now but tomorrow morming; ok? Thanks, Joel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-02 13:15 ` Helge Deller 2006-04-02 14:29 ` Joel Soete @ 2006-04-03 1:28 ` Grant Grundler 2006-04-03 2:02 ` Matthew Wilcox 2006-04-04 12:05 ` James Bottomley 1 sibling, 2 replies; 17+ messages in thread From: Grant Grundler @ 2006-04-03 1:28 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux On Sun, Apr 02, 2006 at 03:15:04PM +0200, Helge Deller wrote: ... > > IOREMAP: phys=fffffff200000000, size=4000000 BUT THIS BIG 64MB CHUNK FAILS. > > allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. > > IOREMAP: phys=ffffffffbffea000, size=1000 > > IOREMAP: remapped to 0000000000048000 OTHER SMALLER ONES OK AGAIN.. > > LBA version TR4.0 (0x5) found at 0xffffffffbffea000 > > So, the problem is really the 64MB ioremap() from lba_pci.c:1216. > Grant, Willy, ... : Is it possible to reduce it or to iounmap() it again ? Unfortunately not. Not unless you want to disable IO Port space access. Each PCI bus controller routes 64MB of GMMIO space to 64KB of IO port space. The first 4 bytes of each page maps to a unique 4 byte in IO Port space. On Astro platforms, we can use 64KB in LMMIO space to access IO Port space for all busses. The difference is Astro only has one SBA and IOC. N-class has two. There's more to this and I'm not sure of all the details at the moment. 240MB is clearly not going to be enough on that machine. Even on a "normal" machine, a couple of graphics cards would exhaust the 240MB. A single infiniband card could exhaust the 240MB space we have now. hth, grant ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-03 1:28 ` Grant Grundler @ 2006-04-03 2:02 ` Matthew Wilcox 2006-04-04 12:05 ` James Bottomley 1 sibling, 0 replies; 17+ messages in thread From: Matthew Wilcox @ 2006-04-03 2:02 UTC (permalink / raw) To: Grant Grundler; +Cc: Helge Deller, parisc-linux On Sun, Apr 02, 2006 at 07:28:31PM -0600, Grant Grundler wrote: > > So, the problem is really the 64MB ioremap() from lba_pci.c:1216. > > Grant, Willy, ... : Is it possible to reduce it or to iounmap() it again ? > > Unfortunately not. Not unless you want to disable IO Port space access. > Each PCI bus controller routes 64MB of GMMIO space to 64KB of IO port space. > The first 4 bytes of each page maps to a unique 4 byte in IO Port space. > > On Astro platforms, we can use 64KB in LMMIO space to access > IO Port space for all busses. The difference is Astro only > has one SBA and IOC. N-class has two. There's more to this > and I'm not sure of all the details at the moment. > > 240MB is clearly not going to be enough on that machine. > Even on a "normal" machine, a couple of graphics cards > would exhaust the 240MB. A single infiniband card could > exhaust the 240MB space we have now. I think using page tables to map IO Port space isn't really necessary. We can use the (slightly inappropriately named) gsc_read/writeX to access that area. Also, there should be loads of virtual memory space available to us with a 64-bit kernel, and we should definitely look at increasing the amount of vmalloc space available with 64-bit. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-03 1:28 ` Grant Grundler 2006-04-03 2:02 ` Matthew Wilcox @ 2006-04-04 12:05 ` James Bottomley 2006-04-05 6:50 ` Helge Deller 1 sibling, 1 reply; 17+ messages in thread From: James Bottomley @ 2006-04-04 12:05 UTC (permalink / raw) To: Grant Grundler; +Cc: parisc-linux, Helge Deller On Sun, 2006-04-02 at 19:28 -0600, Grant Grundler wrote: > Unfortunately not. Not unless you want to disable IO Port space access. > Each PCI bus controller routes 64MB of GMMIO space to 64KB of IO port space. > The first 4 bytes of each page maps to a unique 4 byte in IO Port space. > > On Astro platforms, we can use 64KB in LMMIO space to access > IO Port space for all busses. The difference is Astro only > has one SBA and IOC. N-class has two. There's more to this > and I'm not sure of all the details at the moment. > > 240MB is clearly not going to be enough on that machine. > Even on a "normal" machine, a couple of graphics cards > would exhaust the 240MB. A single infiniband card could > exhaust the 240MB space we have now. OK, could someone explain what we're trying to do and why? The original PA implementation of ioremap actually had I/O space and memory space separated (this is almost essential on 32 bit machines with lots of memory). The new implementation is trying to map our I/O space directly into memory. Because of the way PA is implemented: no highmem, entire memory offset mapped at 0x1000000; that means the only space we have for kernel VM is 0-0x10000000 (On 32 bits, this offset mapping loses us the top 256k on 4GB machines, but that's f space anyway). However, our vmalloc space is very squeezed at 240k (remember, all modules have to be in vmalloc space), so trying to share it with I/O mappings looks to be a bit of a non-starter. I suggest that on 32 bits, we really shouldn't alter the current scheme (i.e. keep the separated I/O and memory mappings). On 64 bits, we could allocate a far different VM range to vmalloc (somewhere up beyond the maximum possible physical memory) and thus make it far bigger, which would allow us to keep a mapped ioremap implementation. Oh, and just before anyone suggests it, we'd have incredible difficulty moving __PAGE_OFFSET because of the absolute<->virtual equivalence requirements. James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-04 12:05 ` James Bottomley @ 2006-04-05 6:50 ` Helge Deller 2006-04-06 0:02 ` James Bottomley 0 siblings, 1 reply; 17+ messages in thread From: Helge Deller @ 2006-04-05 6:50 UTC (permalink / raw) To: James Bottomley; +Cc: parisc-linux On Tuesday 04 April 2006 14:05, James Bottomley wrote: > On Sun, 2006-04-02 at 19:28 -0600, Grant Grundler wrote: > > Unfortunately not. Not unless you want to disable IO Port space access. > > Each PCI bus controller routes 64MB of GMMIO space to 64KB of IO port space. > > The first 4 bytes of each page maps to a unique 4 byte in IO Port space. > > > > On Astro platforms, we can use 64KB in LMMIO space to access > > IO Port space for all busses. The difference is Astro only > > has one SBA and IOC. N-class has two. There's more to this > > and I'm not sure of all the details at the moment. > > > > 240MB is clearly not going to be enough on that machine. > > Even on a "normal" machine, a couple of graphics cards > > would exhaust the 240MB. A single infiniband card could > > exhaust the 240MB space we have now. > > OK, could someone explain what we're trying to do and why? > > The original PA implementation of ioremap actually had I/O space and > memory space separated (this is almost essential on 32 bit machines with > lots of memory). Yes. > The new implementation is trying to map our I/O space directly into > memory. Because of the way PA is implemented: no highmem, entire memory > offset mapped at 0x1000000; that means the only space we have for kernel > VM is 0-0x10000000 (On 32 bits, this offset mapping loses us the top > 256k on 4GB machines, but that's f space anyway). However, our vmalloc > space is very squeezed at 240k (remember, all modules have to be in > vmalloc space), so trying to share it with I/O mappings looks to be a > bit of a non-starter. Yes (240MB). > I suggest that on 32 bits, we really shouldn't alter the current scheme > (i.e. keep the separated I/O and memory mappings). On 64 bits, we > could allocate a far different VM range to vmalloc (somewhere up beyond > the maximum possible physical memory) and thus make it far bigger, which > would allow us to keep a mapped ioremap implementation. Might work, although it makes the sources pretty ugly again. The biggest problem with 64bit kernel and seperated I/O and memory mappings was, that you wasn't able to export I/O-memory via mmap() to 32bit userspace applications. Biggest affected application was X11, who tried to mmap() the 64bit f-space region of the graphics RAM into 32bit-userspace. This might maybe be maybe solveable with your proposal, since e.g. X11 on 32bit Kernel worked already somehow and 64bit could be solved with the mapping. Another proposal could be to keep the current implementation on 32bit and as such not make the sources ugly again. If a user then runs on a big iron like N4k he should use a 64bit kernel instead, which then would implement your 64bit-changes proposal. > Oh, and just before anyone suggests it, we'd have incredible difficulty > moving __PAGE_OFFSET because of the absolute<->virtual equivalence > requirements. Yes, that's the reason I never proposed that :-) Helge _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-05 6:50 ` Helge Deller @ 2006-04-06 0:02 ` James Bottomley 0 siblings, 0 replies; 17+ messages in thread From: James Bottomley @ 2006-04-06 0:02 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux, Grant Grundler On Wed, 2006-04-05 at 08:50 +0200, Helge Deller wrote: > > I suggest that on 32 bits, we really shouldn't alter the current scheme > > (i.e. keep the separated I/O and memory mappings). On 64 bits, we > > could allocate a far different VM range to vmalloc (somewhere up beyond > > the maximum possible physical memory) and thus make it far bigger, which > > would allow us to keep a mapped ioremap implementation. > > Might work, although it makes the sources pretty ugly again. > The biggest problem with 64bit kernel and seperated I/O and memory mappings was, that you wasn't able to export I/O-memory via mmap() to 32bit userspace applications. > Biggest affected application was X11, who tried to mmap() the 64bit f-space region of the graphics RAM into 32bit-userspace. > This might maybe be maybe solveable with your proposal, since e.g. X11 on 32bit Kernel worked already somehow and 64bit could be solved with the mapping. I suspected it might be something like this. Actually, ioremap looks to be the wrong interface to fix this. The problem seems to be that fb_mmap() in drivers/video/fb.c has a special fall through case if the driver doesn't implement fb_mmap() which tries to insert page mappings for the I/O memory region into the users space, this fall through doesn't seem to be correct for 64 bits (or at least for 32 bit processes running on a 64 bit kernel) ... I think if we fix this, we'll get graphics on 64 bit without the need to remap I/O memory. James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? @ 2006-04-03 13:20 Joel Soete 0 siblings, 0 replies; 17+ messages in thread From: Joel Soete @ 2006-04-03 13:20 UTC (permalink / raw) To: deller; +Cc: parisc-linux Hello Helge, > > > Helge Deller wrote: > > On Sunday 02 April 2006 13:18, Joel Soete wrote: > > [snip] > > > >>PS: btw, rm CONFIG_DETECT_SOFTLOCKUP in the config doesn't help on th= is system ;<(: > >>still hanging (this time without Softlockup msg) after only: > >>top - 09:04:58 up 1 day, 16:26, 3 users, load average: 2.40, 2.26, = 2.20 > > > > > > I think the softlockups don't really matter. > > Does your box hangs without SMP as well ? > > > well it did with b2k and n4k runing 64bit kernel with CONFIG_DETECT_SOFTLOCKUP=3Dy && # CONFIG_SMP is not set > > but I need to verify now without CONFIG_DETECT_SOFTLOCKUP. > (sorry I couldn't do it now but tomorrow morming; ok? > Unfortunately, this test (kernel 2.6.16-pa10 up and wiythout CONFIG_DETECT_SOFTLOCKUP) finished earlier then expected: i.e. the system= also hang up after just few hours of build loop ;<( Joel=0A=0A---------------------------------------------------------------= =0AA free anti-spam and anti-virus filter on all Scarlet mailboxes=0AMore= info on http://www.scarlet.be/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? @ 2006-04-05 16:43 Joel Soete 2006-04-05 17:02 ` Helge Deller 0 siblings, 1 reply; 17+ messages in thread From: Joel Soete @ 2006-04-05 16:43 UTC (permalink / raw) To: deller; +Cc: James.Bottomley, parisc-linux Hello Helge, [...] > If a user then runs on a big iron like N4k he should use a 64bit kernel= instead, which then would implement your 64bit-changes proposal. > Sorry but I misderstood: iirc only 64bit kernel runs on such system like = A, L, N class; we haven't the choice? Thanks, Joel PS: btw, I read a lot of your patch related to page size 16k and 64k (for= pa8000) but not sure we can try it now?=0A=0A----------------------------= -----------------------------------=0AA free anti-spam and anti-virus fil= ter on all Scarlet mailboxes=0AMore info on http://www.scarlet.be/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Strange newest LAB msg? 2006-04-05 16:43 Joel Soete @ 2006-04-05 17:02 ` Helge Deller 0 siblings, 0 replies; 17+ messages in thread From: Helge Deller @ 2006-04-05 17:02 UTC (permalink / raw) To: Joel Soete; +Cc: James.Bottomley, parisc-linux On Wednesday 05 April 2006 18:43, Joel Soete wrote: > > If a user then runs on a big iron like N4k he should use a 64bit kernel > instead, which then would implement your 64bit-changes proposal. > > > Sorry but I misderstood: iirc only 64bit kernel runs on such system like A, L, > N class; we haven't the choice? Yes, 64bit kernel, but with additional changes as James proposed. (the proposal is to implement an iomapping-region (in a very high memory region where you do not have physical memory), in which the ioremapping can happen.) > PS: btw, I read a lot of your patch related to page size 16k and 64k (for > pa8000) but not sure we can try it now? It does not makes sense to test it yet, since it will crash your box. I'm trying to read and understand the docs. Not sure when I have it (at least partly) workable.... I'll let you know when you can try. Helge _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2006-04-06 0:02 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-03-31 15:26 [parisc-linux] Strange newest LAB msg? Joel Soete 2006-03-31 15:54 ` Matthew Wilcox 2006-04-01 7:02 ` Grant Grundler 2006-04-01 7:35 ` Helge Deller 2006-04-01 14:30 ` James Bottomley 2006-04-02 9:29 ` Helge Deller 2006-04-02 11:18 ` Joel Soete 2006-04-02 13:15 ` Helge Deller 2006-04-02 14:29 ` Joel Soete 2006-04-03 1:28 ` Grant Grundler 2006-04-03 2:02 ` Matthew Wilcox 2006-04-04 12:05 ` James Bottomley 2006-04-05 6:50 ` Helge Deller 2006-04-06 0:02 ` James Bottomley -- strict thread matches above, loose matches on Subject: below -- 2006-04-03 13:20 Joel Soete 2006-04-05 16:43 Joel Soete 2006-04-05 17:02 ` Helge Deller
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.