Skip to contentSkip to conversation

ppc64: 64K pages support

PATCH In review Benjamin Herrenschmidt 9 participants 20 messages Nov 2, 2005 – Nov 17, 2005 2 messages not in the archive

Subsystems (2)
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 1130915220.20136.14.camel@gaston

#1 lore raw

PATCH 1/1 ppc64: 64K pages support

Quoted 7 lines · Benjamin Herrenschmidt

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.

Quoted 6 lines

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.

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.

Acked-by on v1 1/1
#2 lore raw
Quoted 7 lines · Benjamin Herrenschmidt

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.

Quoted 6 lines

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.

#3 lore raw

ppc64: Fix bug in SLB miss handler for hugepages

Quoted 9 lines · Paul Mackerras
Quoted 7 lines · Benjamin Herrenschmidt

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.

Quoted 8 lines
Quoted 6 lines

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.

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

arch/powerpc/mm/slb_low.S +9 -4
Index: working-2.6/arch/powerpc/mm/slb_low.S
===================================================================
@@ -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
arch/powerpc/mm/hash_utils_64.c +4 -2
Index: working-2.6/arch/powerpc/mm/hash_utils_64.c
===================================================================
@@ -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 ! */
include/asm-ppc64/pgtable-4k.h +3 -0
Index: working-2.6/include/asm-ppc64/pgtable-4k.h
===================================================================
@@ -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)
include/asm-ppc64/pgtable-64k.h +3 -0
Index: working-2.6/include/asm-ppc64/pgtable-64k.h
===================================================================
@@ -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)
arch/powerpc/mm/hugetlbpage.c +6 -0
Index: working-2.6/arch/powerpc/mm/hugetlbpage.c
===================================================================
@@ -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))
Signature · 4 lines
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
#5 lore raw
Quoted 3 lines · 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.

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#6 lore raw
Quoted 6 lines

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#8 lore raw
Quoted 2 lines · Christoph Hellwig

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.

Signature · 1 line
Mike
#9 lore raw
Quoted 9 lines · Mike Kravetz
Quoted 2 lines · Christoph Hellwig

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

Quoted 5 lines

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.

#10 lore raw
Quoted 14 lines · Benjamin Herrenschmidt
Quoted 9 lines · Mike Kravetz
Quoted 2 lines · Christoph Hellwig

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

Quoted 7 lines
Quoted 5 lines

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

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.

#11 lore raw
Quoted 5 lines

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.

#12 lore raw
Quoted 8 lines · Benjamin Herrenschmidt
Quoted 4 lines

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

#13 lore raw
Quoted 11 lines · Badari Pulavarty
Quoted 8 lines · Benjamin Herrenschmidt
Quoted 4 lines

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.

Signature · 2 lines
short story of a lazy sysadmin:
 alias appserv=wotan
#14 lore raw
Quoted 8 lines · Olaf Hering
Quoted 6 lines · Badari Pulavarty
Quoted 5 lines · Benjamin Herrenschmidt
Quoted 4 lines

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:

Quoted 9 lines
Quoted 5 lines
Quoted 3 lines

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

#15 lore raw
Quoted 9 lines · Badari Pulavarty

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.

Signature · 2 lines
short story of a lazy sysadmin:
 alias appserv=wotan
#16 lore raw
Quoted 12 lines · Olaf Hering
Quoted 9 lines · Badari Pulavarty

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
Quoted 2 lines

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.

Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected]
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."

A message that is not in the archive (sent off-list or not yet received): [email protected]

#18 lore raw
Quoted 30 lines · Sonny Rao

On 11/16/05, Badari Pulavarty <[email protected]> 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)

Quoted 8 lines

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

#20 lore raw
In reply to Christoph Hellwig
Quoted 2 lines · Christoph Hellwig

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.

#21 lore raw
In reply to Christoph Hellwig
Quoted 2 lines · Christoph Hellwig

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.