[PATCH] ppc64: 64K pages support

[PATCH] ppc64: 64K pages support

[Benjamin Herrenschmidt]

On Wed, 2005-11-02 at 18:07 +1100, Benjamin Herrenschmidt wrote:
> It took a while, but finally, here is the 64K pages support patch for
> ppc64. This patch adds a new CONFIG_PPC_64K_PAGES which, when enabled,
> changes the kernel base page size to 64K. The resulting kernel still
> boots on any hardware. On current machines with 4K pages support only,
> the kernel will maintain 16 "subpages" for each 64K page
> transparently.
> 
> Note that while real 64K capable HW has been tested, the current patch
> will not enable it yet as such hardware is not released yet, and I'm
> still verifying with the firmware architects the proper to get the
> information from the newer hypervisors.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Oh, and since the mailing lists are probably filtering this out due to
the patch size, here's an URL where you can find it too:

http://gate.crashing.org/~benh/ppc64-64k-pages.diff

Ben.

Re: [PATCH] ppc64: 64K pages support

[Paul Mackerras]

Benjamin Herrenschmidt writes:

> It took a while, but finally, here is the 64K pages support patch for
> ppc64. This patch adds a new CONFIG_PPC_64K_PAGES which, when enabled,
> changes the kernel base page size to 64K. The resulting kernel still
> boots on any hardware. On current machines with 4K pages support only,
> the kernel will maintain 16 "subpages" for each 64K page
> transparently.
> 
> Note that while real 64K capable HW has been tested, the current patch
> will not enable it yet as such hardware is not released yet, and I'm
> still verifying with the firmware architects the proper to get the
> information from the newer hypervisors.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Acked-by: Paul Mackerras <paulus@samba.org>

ppc64: Fix bug in SLB miss handler for hugepages

[David Gibson]

On Thu, Nov 03, 2005 at 02:16:29PM +1100, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
> 
> > It took a while, but finally, here is the 64K pages support patch for
> > ppc64. This patch adds a new CONFIG_PPC_64K_PAGES which, when enabled,
> > changes the kernel base page size to 64K. The resulting kernel still
> > boots on any hardware. On current machines with 4K pages support only,
> > the kernel will maintain 16 "subpages" for each 64K page
> > transparently.
> > 
> > Note that while real 64K capable HW has been tested, the current patch
> > will not enable it yet as such hardware is not released yet, and I'm
> > still verifying with the firmware architects the proper to get the
> > information from the newer hypervisors.
> > 
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 
> Acked-by: Paul Mackerras <paulus@samba.org>

This patch, however, should be applied on top to fix some problems
with hugepage (some pre-existing, another introduced by this patch).

The patch fixes a bug in the SLB miss handler for hugepages on ppc64
introduced by the dynamic hugepage patch (commit id
c594adad5653491813959277fb87a2fef54c4e05) due to a misunderstanding of
the srd instruction's behaviour (mea culpa).  The problem arises when
a 64-bit process maps some hugepages in the low 4GB of the address
space (unusual).  In this case, as well as the 256M segment in
question being marked for hugepages, other segments at 32G intervals
will be incorrectly marked for hugepages.

In the process, this patch tweaks the semantics of the hugepage
bitmaps to be more sensible.  Previously, an address below 4G was
marked for hugepages if the appropriate segment bit in the "low areas"
bitmask was set *or* if the low bit in the "high areas" bitmap was set
(which would mark all addresses below 1TB for hugepage).  With this
patch, any given address is governed by a single bitmap.  Addresses
below 4GB are marked for hugepage if and only if their bit is set in
the "low areas" bitmap (256M granularity).  Addresses between 4GB and
1TB are marked for hugepage iff the low bit in the "high areas" bitmap
is set.  Higher addresses are marked for hugepage iff their bit in the
"high areas" bitmap is set (1TB granularity).

To avoid conflicts, this patch must be applied on top of BenH's
pending patch for 64k base page size [0].  As such, this patch also
addresses a hugepage problem introduced by that patch.  That patch
allows hugepages of 1MB in size on hardware which supports it,
however, that won't work when using 4k pages (4 level pagetable),
because in that case hugepage PTEs are stored at the PMD level, and
each PMD entry maps 2MB.  This patch simply disallows hugepages in
that case (we can do something cleverer to re-enable them some other
day).

Built, booted, and a handful of hugepage related tests passed on
POWER5 LPAR (both ARCH=powerpc and ARCH=ppc64).

[0] http://gate.crashing.org/~benh/ppc64-64k-pages.diff

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Index: working-2.6/arch/powerpc/mm/slb_low.S
===================================================================
--- working-2.6.orig/arch/powerpc/mm/slb_low.S	2005-11-03 14:52:16.000000000 +1100
+++ working-2.6/arch/powerpc/mm/slb_low.S	2005-11-03 14:55:56.000000000 +1100
@@ -80,12 +80,17 @@
 BEGIN_FTR_SECTION
 	b	1f
 END_FTR_SECTION_IFCLR(CPU_FTR_16M_PAGE)
+	cmpldi	r10,16
+
+	lhz	r9,PACALOWHTLBAREAS(r13)
+	mr	r11,r10
+	blt	5f
+
 	lhz	r9,PACAHIGHHTLBAREAS(r13)
 	srdi	r11,r10,(HTLB_AREA_SHIFT-SID_SHIFT)
-	srd	r9,r9,r11
-	lhz	r11,PACALOWHTLBAREAS(r13)
-	srd	r11,r11,r10
-	or.	r9,r9,r11
+
+5:	srd	r9,r9,r11
+	andi.	r9,r9,1
 	beq	1f
 _GLOBAL(slb_miss_user_load_huge)
 	li	r11,0
Index: working-2.6/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/hash_utils_64.c	2005-11-03 14:52:16.000000000 +1100
+++ working-2.6/arch/powerpc/mm/hash_utils_64.c	2005-11-03 15:40:56.000000000 +1100
@@ -329,12 +329,14 @@
 	 */
 	if (mmu_psize_defs[MMU_PAGE_16M].shift)
 		mmu_huge_psize = MMU_PAGE_16M;
+	/* With 4k/4level pagetables, we can't (for now) cope with a
+	 * huge page size < PMD_SIZE */
 	else if (mmu_psize_defs[MMU_PAGE_1M].shift)
 		mmu_huge_psize = MMU_PAGE_1M;
 
 	/* Calculate HPAGE_SHIFT and sanity check it */
-	if (mmu_psize_defs[mmu_huge_psize].shift > 16 &&
-	    mmu_psize_defs[mmu_huge_psize].shift < 28)
+	if (mmu_psize_defs[mmu_huge_psize].shift > MIN_HUGEPTE_SHIFT &&
+	    mmu_psize_defs[mmu_huge_psize].shift < SID_SHIFT)
 		HPAGE_SHIFT = mmu_psize_defs[mmu_huge_psize].shift;
 	else
 		HPAGE_SHIFT = 0; /* No huge pages dude ! */
Index: working-2.6/include/asm-ppc64/pgtable-4k.h
===================================================================
--- working-2.6.orig/include/asm-ppc64/pgtable-4k.h	2005-11-03 14:52:16.000000000 +1100
+++ working-2.6/include/asm-ppc64/pgtable-4k.h	2005-11-03 15:38:40.000000000 +1100
@@ -23,6 +23,9 @@
 #define PMD_SIZE	(1UL << PMD_SHIFT)
 #define PMD_MASK	(~(PMD_SIZE-1))
 
+/* With 4k base page size, hugepage PTEs go at the PMD level */
+#define MIN_HUGEPTE_SHIFT	PMD_SHIFT
+
 /* PUD_SHIFT determines what a third-level page table entry can map */
 #define PUD_SHIFT	(PMD_SHIFT + PMD_INDEX_SIZE)
 #define PUD_SIZE	(1UL << PUD_SHIFT)
Index: working-2.6/include/asm-ppc64/pgtable-64k.h
===================================================================
--- working-2.6.orig/include/asm-ppc64/pgtable-64k.h	2005-11-03 14:52:16.000000000 +1100
+++ working-2.6/include/asm-ppc64/pgtable-64k.h	2005-11-03 15:39:07.000000000 +1100
@@ -14,6 +14,9 @@
 #define PTRS_PER_PMD	(1 << PMD_INDEX_SIZE)
 #define PTRS_PER_PGD	(1 << PGD_INDEX_SIZE)
 
+/* With 4k base page size, hugepage PTEs go at the PMD level */
+#define MIN_HUGEPTE_SHIFT	PAGE_SHIFT
+
 /* PMD_SHIFT determines what a second-level page table entry can map */
 #define PMD_SHIFT	(PAGE_SHIFT + PTE_INDEX_SIZE)
 #define PMD_SIZE	(1UL << PMD_SHIFT)
Index: working-2.6/arch/powerpc/mm/hugetlbpage.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/hugetlbpage.c	2005-11-03 14:52:16.000000000 +1100
+++ working-2.6/arch/powerpc/mm/hugetlbpage.c	2005-11-03 15:56:34.000000000 +1100
@@ -212,6 +212,12 @@
 
 	BUG_ON(area >= NUM_HIGH_AREAS);
 
+	/* Hack, so that each addresses is controlled by exactly one
+	 * of the high or low area bitmaps, the first high area starts
+	 * at 4GB, not 0 */
+	if (start == 0)
+		start = 0x100000000UL;
+
 	/* Check no VMAs are in the region */
 	vma = find_vma(mm, start);
 	if (vma && (vma->vm_start < end))


-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/people/dgibson

Re: [PATCH] ppc64: 64K pages support

[Christoph Hellwig]

So how does the 64k on 4k hardware emulation work?  When Hugh did
bigger softpagesize for x86 based on 2.4.x he had to fix drivers all
over to deal with that.

Re: [PATCH] ppc64: 64K pages support

[Benjamin Herrenschmidt]

On Sat, 2005-11-05 at 01:38 +0100, Christoph Hellwig wrote:
> So how does the 64k on 4k hardware emulation work?  When Hugh did
> bigger softpagesize for x86 based on 2.4.x he had to fix drivers all
> over to deal with that.

What was the problem with drivers ? On ppc64, it's all hidden in the
arch code. All the kernel sees is a 64k page size. I extended the PTE to
contain tracking informations for the 16 sub pages (HPTE bits & hash
slot index). Sub pages are faulted on demand and flushed all at once,
but it's all transparent to the generic code.

Ben.

Re: [PATCH] ppc64: 64K pages support

[Dave Airlie]

> What was the problem with drivers ? On ppc64, it's all hidden in the
> arch code. All the kernel sees is a 64k page size. I extended the PTE to
> contain tracking informations for the 16 sub pages (HPTE bits & hash
> slot index). Sub pages are faulted on demand and flushed all at once,
> but it's all transparent to the generic code.
>

We did that with the VAX port about 5 years ago :-), granted for
different reasons..

The VAX has 512 byte hw pages, we had to make a 4K pagesize for the
kernel by grouping 8 hw pages together and hiding it all in the arch
dir..

granted I don't know if it broke any drivers, we didn't have any...

Dave.

Re: [PATCH] ppc64: 64K pages support

[Christoph Hellwig]

Booting current mainline with 64K pagesize enabled gives me a purple (!)
screen early during boot.

Re: [PATCH] ppc64: 64K pages support

[Mike Kravetz]

On Wed, Nov 09, 2005 at 06:21:25PM +0100, Christoph Hellwig wrote:
> Booting current mainline with 64K pagesize enabled gives me a purple (!)
> screen early during boot.

I seem to also be having problems with this patch.  My OpenPOWER 720
stopped booting with 2.6.14-git10(and later).  Just using defconfig.
64k page size NOT enabled.  If I back out the 64k page size patch,
2.6.14-git10 boots.  I'm trying to get more info but it is painful.
It dies before xmon is initialized.

I could have sworn that I booted 2.6.14-git7 with the 64k page size
patch applied.  But, I can't do that now either.

Some co-workers have successfully booted other POWER systems with these
kernels.  So, it must be specific to my hardware/LPAR configuration.

-- 
Mike

Re: [PATCH] ppc64: 64K pages support

[Benjamin Herrenschmidt]

On Wed, 2005-11-09 at 12:17 -0800, Mike Kravetz wrote:
> On Wed, Nov 09, 2005 at 06:21:25PM +0100, Christoph Hellwig wrote:
> > Booting current mainline with 64K pagesize enabled gives me a purple (!)
> > screen early during boot.
> 
> I seem to also be having problems with this patch.  My OpenPOWER 720
> stopped booting with 2.6.14-git10(and later).  Just using defconfig.
> 64k page size NOT enabled.  If I back out the 64k page size patch,
> 2.6.14-git10 boots.  I'm trying to get more info but it is painful.
> It dies before xmon is initialized.

There  have been a couple of fixes, try the very latest git. Also, try
enabling early debug in arch/ppc64/kernel/setup.c

> I could have sworn that I booted 2.6.14-git7 with the 64k page size
> patch applied.  But, I can't do that now either.
> 
> Some co-workers have successfully booted other POWER systems with these
> kernels.  So, it must be specific to my hardware/LPAR configuration.

Ok, i'll do more tests here too.

Ben.

Re: [PATCH] ppc64: 64K pages support

[Benjamin Herrenschmidt]

On Wed, 2005-11-09 at 18:21 +0100, Christoph Hellwig wrote:
> Booting current mainline with 64K pagesize enabled gives me a purple (!)
> screen early during boot.

On the G5 ? Weird... I'll test.

Ben.

Re: [PATCH] ppc64: 64K pages support

[Badari Pulavarty]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

On Thu, 2005-11-10 at 07:32 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-11-09 at 12:17 -0800, Mike Kravetz wrote:
> > On Wed, Nov 09, 2005 at 06:21:25PM +0100, Christoph Hellwig wrote:
> > > Booting current mainline with 64K pagesize enabled gives me a purple (!)
> > > screen early during boot.
> > 
> > I seem to also be having problems with this patch.  My OpenPOWER 720
> > stopped booting with 2.6.14-git10(and later).  Just using defconfig.
> > 64k page size NOT enabled.  If I back out the 64k page size patch,
> > 2.6.14-git10 boots.  I'm trying to get more info but it is painful.
> > It dies before xmon is initialized.
> 
> There  have been a couple of fixes, try the very latest git. Also, try
> enabling early debug in arch/ppc64/kernel/setup.c
> 
> > I could have sworn that I booted 2.6.14-git7 with the 64k page size
> > patch applied.  But, I can't do that now either.
> > 
> > Some co-workers have successfully booted other POWER systems with these
> > kernels.  So, it must be specific to my hardware/LPAR configuration.
> 
> Ok, i'll do more tests here too.

I didn't have any luck on 2.6.14-git12 either.
I tried 64k page support on my P570. 

Here are the console messages:

Thanks,
Badari

[-- Attachment #2: 64kpage.out --]
[-- Type: text/plain, Size: 10119 bytes --]

boot: 2614git12
Please wait, loading kernel...
   Elf32 kernel loaded...

zImage starting: loaded at 0x00401a04 (sp: 0x019ffbe0)
Allocating 0x845378 bytes for kernel ...
gunzipping (0x1c00000 <- 0x407a04:0x63e99d)...done 0x6963d8 bytes
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: root=/dev/sda3 selinux=0 elevator=cfq
memory layout at init:
  memory_limit : 0000000000000000 (16 MB aligned)
  alloc_bottom : 0000000002460000
  alloc_top    : 0000000008000000
  alloc_top_hi : 00000000ed000000
  rmo_top      : 0000000008000000
  ram_top      : 00000000ed000000
Looking for displays
instantiating rtas at 0x00000000077c0000 ... done
0000000000000000 : boot cpu     0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000002470000 -> 0x00000000024711de
Device tree struct  0x0000000002480000 -> 0x00000000024a0000
Calling quiesce ...
returning from prom_init
Page orders: linear mapping = 24, others = 12
Bogus initrd 00000000 00000000
firmware_features = 0x1ffd5f
Partition configured for 4 cpus.
Starting Linux PPC64 #1 SMP Wed Nov 9 10:51:26 PST 2005
-----------------------------------------------------
ppc64_pft_size                = 0x1a
ppc64_interrupt_controller    = 0x2
systemcfg                     = 0xc000000000618a00
systemcfg->platform           = 0x101
systemcfg->processorCount     = 0x4
systemcfg->physicalMemorySize = 0xed000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address                  = 0x0000000000000000
htab_hash_mask                = 0x7ffff
-----------------------------------------------------
[boot]0100 MM Init
[boot]0100 MM Init Done
Linux version 2.6.14-git12 (root@elm3b157) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Wed Nov 9 10:51:26 PST 2005
[boot]0012 Setup Arch
Node 0 Memory: 0x0-0xed000000
Syscall map setup, 240 32-bit and 219 64-bit syscalls
No ramdisk, default root is /dev/sda2
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Using dedicated idle loop
[boot]0015 Setup Done
Built 1 zonelists
Kernel command line: root=/dev/sda3 selinux=0 elevator=cfq
[boot]0020 XICS Init
xics: no ISA interrupt controller
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 131072 bytes)
time_init: decrementer frequency = 206.999000 MHz
time_init: processor frequency   = 1655.992000 MHz
Page orders: linear mapping = 24, others = 12
Bogus initrd 00000000 00000000
firmware_features = 0x1ffd5f
Partition configured for 4 cpus.
Starting Linux PPC64 #1 SMP Wed Nov 9 10:51:26 PST 2005
-----------------------------------------------------
ppc64_pft_size                = 0x1a
ppc64_interrupt_controller    = 0x2
systemcfg                     = 0xc000000000618a00
systemcfg->platform           = 0x101
systemcfg->processorCount     = 0x4
systemcfg->physicalMemorySize = 0xed000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address                  = 0x0000000000000000
htab_hash_mask                = 0x7ffff
-----------------------------------------------------
[boot]0100 MM Init
[boot]0100 MM Init Done
Linux version 2.6.14-git12 (root@elm3b157) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Wed Nov 9 10:51:26 PST 2005
[boot]0012 Setup Arch
Node 0 Memory: 0x0-0xed000000
Syscall map setup, 240 32-bit and 219 64-bit syscalls
No ramdisk, default root is /dev/sda2
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Using dedicated idle loop
[boot]0015 Setup Done
Built 1 zonelists
Kernel command line: root=/dev/sda3 selinux=0 elevator=cfq
[boot]0020 XICS Init
xics: no ISA interrupt controller
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 131072 bytes)
time_init: decrementer frequency = 206.999000 MHz
time_init: processor frequency   = 1655.992000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
freeing bootmem node 0
Memory: 3851648k/3883008k available (4928k kernel code, 31360k reserved, 1728k data, 1748k bss, 320k init)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Mount-cache hash table entries: 4096
softlockup thread 0 started up.
Processor 1 found.
softlockup thread 1 started up.
Processor 2 found.
softlockup thread 2 started up.
Processor 3 found.
Brought up 4 CPUs
softlockup thread 3 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging disabled
mapping IO 3fe00200000 -> d000080000000000, size: 100000
mapping IO 3fe00700000 -> d000080000100000, size: 100000
PCI: Probing PCI hardware done
SCSI subsystem initialized
i/pSeries Real Time Clock Driver v1.1
RTAS daemon started
audit: initializing netlink socket (disabled)
audit(1131572634.103:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
rpaphp: Slot [0001:00:02.4](PCI location=U787E.001.AAA1978-P2-C1) registered
rpaphp: Slot [0001:00:02.2](PCI location=U787E.001.AAA1978-P2-C2) registered
rpaphp: Slot [0001:00:02.6](PCI location=U787E.001.AAA1978-P2-C3) registered
HVSI: registered 0 devices
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
blk_queue_max_sectors: set to minimum 128
Floppy drive(s): fd0 is 2.88M
RAMDISK driver initialized: 16 RAM disks of 123456K size 1024 blocksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 6.1.16-k2-NAPI
Copyright (c) 1999-2005 Intel Corporation.
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20275: IDE controller at PCI slot 0000:cc:01.0
PDC20275: chipset revision 1
PDC20275: 100% native mode on irq 134
    ide2: BM-DMA at 0xdec00-0xdec07, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0xdec08-0xdec0f, BIOS settings: hdg:pio, hdh:pio
hde: IBM DROM00205J1 H0, ATAPI CD/DVD-ROM drive
ide2 at 0xde400-0xde407,0xddc02 on irq 134
hde: ATAPI 24X DVD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.20
ipr: IBM Power RAID SCSI Device Driver version: 2.0.14 (May 2, 2005)
ipr 0000:d0:01.0: Found IOA with IRQ: 135
ipr 0000:d0:01.0: Starting IOA initialization sequence.
ipr 0000:d0:01.0: Adapter firmware version: 020A005E
ipr 0000:d0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
  Vendor: IBM   H0  Model: HUS103014FL3800   Rev: RPQF
  Type:   Direct-Access                      ANSI SCSI revision: 04
  Vendor: IBM   H0  Model: HUS103014FL3800   Rev: RPQF
  Type:   Direct-Access                      ANSI SCSI revision: 04
  Vendor: IBM       Model: VSBPD4E2  U4SCSI  Rev: 7134
  Type:   Enclosure                          ANSI SCSI revision: 02
scsi: unknown device type 31
  Vendor: IBM       Model: 570B001           Rev: 0150
  Type:   Unknown                            ANSI SCSI revision: 00
SCSI device sda: 286748000 512-byte hdwr sectors (146815 MB)
SCSI device sda: drive cache: write through
SCSI device sda: 286748000 512-byte hdwr sectors (146815 MB)
SCSI device sda: drive cache: write through
 sda: sda1 sda2 sda3
sd 0:0:5:0: Attached scsi disk sda
SCSI device sdb: 286748000 512-byte hdwr sectors (146815 MB)
SCSI device sdb: drive cache: write through
SCSI device sdb: 286748000 512-byte hdwr sectors (146815 MB)
SCSI device sdb: drive cache: write through
 sdb: unknown partition table
sd 0:0:8:0: Attached scsi disk sdb
sd 0:0:5:0: Attached scsi generic sg0 type 0
sd 0:0:8:0: Attached scsi generic sg1 type 0
 0:0:15:0: Attached scsi generic sg2 type 13
 0:255:255:255: Attached scsi generic sg3 type 31
mice: PS/2 mouse device common for all mice
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.39
oprofile: using ppc64/power5 performance monitoring.
NET: Registered protocol family 2
IP route cache hash table entries: 524288 (order: 6, 4194304 bytes)
TCP established hash table entries: 1048576 (order: 8, 16777216 bytes)
TCP bind hash table entries: 65536 (order: 4, 1048576 bytes)
TCP: Hash tables configured (established 1048576 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
ReiserFS: sda3: found reiserfs format "3.6" with standard journal
ReiserFS: sda3: using ordered data mode
ReiserFS: sda3: journal params: device sda3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda3: checking transaction log (sda3)
ReiserFS: sda3: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 320k freed
INIT: version 2.85 booting
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.

Re: [PATCH] ppc64: 64K pages support

[Benjamin Herrenschmidt]

> I didn't have any luck on 2.6.14-git12 either.
> I tried 64k page support on my P570. 
> 
> Here are the console messages:

What distro do you use in userland ? Some older glibc versions have a
bug that cause issues with 64k pages, though it generally happens with
login blowing up, not init ...

Ben.

Re: [PATCH] ppc64: 64K pages support

[Badari Pulavarty]

On Thu, 2005-11-10 at 09:01 +1100, Benjamin Herrenschmidt wrote:
> > I didn't have any luck on 2.6.14-git12 either.
> > I tried 64k page support on my P570. 
> > 
> > Here are the console messages:
> 
> What distro do you use in userland ? Some older glibc versions have a
> bug that cause issues with 64k pages, though it generally happens with
> login blowing up, not init ...

SLES9 (could be SLES9 SP1).

Thanks,
Badari

Re: [PATCH] ppc64: 64K pages support

[Paul Mackerras]

Christoph Hellwig writes:

> Booting current mainline with 64K pagesize enabled gives me a purple (!)
> screen early during boot.

Cool!

Is this on a G5, or what sort of machine?  What .config are you using?

Paul.

Re: [PATCH] ppc64: 64K pages support

[Benjamin Herrenschmidt]

On Wed, 2005-11-09 at 18:21 +0100, Christoph Hellwig wrote:
> Booting current mainline with 64K pagesize enabled gives me a purple (!)
> screen early during boot.

Do you use one of the nvidia fbdev's ? What if you disable it ?

(Also, rivafb has some funky bugs on my iMac G5, though nvidiafb works
fine with the latest fixes that are now in -git, but I haven't tried
with 64K pages enabled in the .config yet).

Ben.

Re: [PATCH] ppc64: 64K pages support

[Olaf Hering]

 On Wed, Nov 09, Badari Pulavarty wrote:

> On Thu, 2005-11-10 at 09:01 +1100, Benjamin Herrenschmidt wrote:
> > > I didn't have any luck on 2.6.14-git12 either.
> > > I tried 64k page support on my P570. 
> > > 
> > > Here are the console messages:
> > 
> > What distro do you use in userland ? Some older glibc versions have a
> > bug that cause issues with 64k pages, though it generally happens with
> > login blowing up, not init ...
> 
> SLES9 (could be SLES9 SP1).

Can you double check? rpm -qi glibc | head should be enough.
Would be bad if SP2 or SP3 does not work with 64k.

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

Re: [PATCH] ppc64: 64K pages support

[Badari Pulavarty]

On Thu, 2005-11-17 at 00:08 +0100, Olaf Hering wrote:
>  On Wed, Nov 09, Badari Pulavarty wrote:
> 
> > On Thu, 2005-11-10 at 09:01 +1100, Benjamin Herrenschmidt wrote:
> > > > I didn't have any luck on 2.6.14-git12 either.
> > > > I tried 64k page support on my P570. 
> > > > 
> > > > Here are the console messages:
> > > 
> > > What distro do you use in userland ? Some older glibc versions have a
> > > bug that cause issues with 64k pages, though it generally happens with
> > > login blowing up, not init ...
> > 
> > SLES9 (could be SLES9 SP1).
> 
> Can you double check? rpm -qi glibc | head should be enough.
> Would be bad if SP2 or SP3 does not work with 64k.
> 

I think I am using SLES9. Planning to update to SP3.

# rpm -qi glibc | head
Name        : glibc                        Relocations: (not
relocatable)
Version     : 2.3.3                             Vendor: SuSE Linux AG,
Nuernberg, Germany
Release     : 98.28                         Build Date: Wed Jun 30
15:55:45 2004
Install date: Wed Jul  6 17:24:44 2005      Build Host:
gooseberry.suse.de
Group       : System/Libraries              Source RPM:
glibc-2.3.3-98.28.src.rpm
Size        : 6161800                          License: GPL, LGPL
Signature   : DSA/SHA1, Wed Jun 30 16:00:21 2004, Key ID
a84edae89c800aca
Packager    : http://www.suse.de/feedback
URL         : http://www.gnu.org/software/libc/libc.html
Summary     : The standard shared libraries (from the GNU C Library)

Thanks,
Badari

Re: [PATCH] ppc64: 64K pages support

[Olaf Hering]

 On Wed, Nov 16, Badari Pulavarty wrote:

> I think I am using SLES9. Planning to update to SP3.
> 
> # rpm -qi glibc | head
> Name        : glibc                        Relocations: (not
> relocatable)
> Version     : 2.3.3                             Vendor: SuSE Linux AG,
> Nuernberg, Germany
> Release     : 98.28                         Build Date: Wed Jun 30
> 15:55:45 2004

The release number indicates the GA glibc.spec was used, but the
build date indicates its slightly older than SLES9 GA.

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

Re: [PATCH] ppc64: 64K pages support

[Badari Pulavarty]

On Wed, 2005-11-16 at 17:57 -0600, Sonny Rao wrote:
> On 11/16/05, Badari Pulavarty <pbadari@us.ibm.com> wrote:
>         On Thu, 2005-11-17 at 00:08 +0100, Olaf Hering wrote:
>         >  On Wed, Nov 09, Badari Pulavarty wrote:
>         >
>         > > On Thu, 2005-11-10 at 09:01 +1100, Benjamin Herrenschmidt
>         wrote:
>         > > > > I didn't have any luck on 2.6.14-git12 either.
>         > > > > I tried 64k page support on my P570.
>         > > > >
>         > > > > Here are the console messages:
>         > > >
>         > > > What distro do you use in userland ? Some older glibc
>         versions have a 
>         > > > bug that cause issues with 64k pages, though it
>         generally happens with
>         > > > login blowing up, not init ...
>         > >
>         > > SLES9 (could be SLES9 SP1).
>         >
>         > Can you double check? rpm -qi glibc | head should be
>         enough. 
>         > Would be bad if SP2 or SP3 does not work with 64k.
>         >
>         
>         I think I am using SLES9. Planning to update to SP3.
> 
>  
> Badari, the problem is with your toolchain.. 
> the binutils in SLES9 is too old (even in SP3)
> 
> The issue is that it cannot align something (the zero page I think) to
> 64kb .
> 
> SLES9 SP3 has "GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux)"
> 
> But I have to use binutils 2.15.94 to make a 64kb kernel boot
> properly 
> (I can give you the package offline if you need)

Thank you Sonny. I updated my binutils package and 64k pagesize
kernel works fine for me (atleast booted fine).

Thanks,
Badari

Re: [PATCH] ppc64: 64K pages support

[Andreas Schwab]

Olaf Hering <olh@suse.de> writes:

>  On Wed, Nov 16, Badari Pulavarty wrote:
>
>> I think I am using SLES9. Planning to update to SP3.
>> 
>> # rpm -qi glibc | head
>> Name        : glibc                        Relocations: (not
>> relocatable)
>> Version     : 2.3.3                             Vendor: SuSE Linux AG,
>> Nuernberg, Germany
>> Release     : 98.28                         Build Date: Wed Jun 30
>> 15:55:45 2004
>
> The release number indicates the GA glibc.spec was used, but the
> build date indicates its slightly older than SLES9 GA.

Build date is local time (timezone has been chopped off here).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."