ppc64: 64K pages support
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): 1130915220.20136.14.camel@gaston
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_PAGESwhich, 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.
Signed-off-by Benjamin Herrenschmidt <[email protected]>
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.
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_PAGESwhich, 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.
Signed-off-by Benjamin Herrenschmidt <[email protected]>
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_PAGESwhich, 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.
Signed-off-by Benjamin Herrenschmidt <[email protected]>Acked-by Paul Mackerras <[email protected]>
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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.
--
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>
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>
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>
Booting current mainline with 64K pagesize enabled gives me a purple (!) screen early during boot.
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
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.
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 00000000firmware_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 = 0x80htab_address = 0x0000000000000000htab_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 MHztime_init: processor frequency = 1655.992000 MHz
Page orders: linear mapping = 24, others = 12
Bogus initrd 00000000 00000000firmware_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 = 0x80htab_address = 0x0000000000000000htab_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 MHztime_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 disabledblk_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:piohde: 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.
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.
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
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
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
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
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]
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
Quoted 2 lines · Christoph Hellwig
Booting current mainline with 64K pagesize enabled gives me a purple (!) screen early during boot.
On the G5 ? Weird... I'll test.
Ben.
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.
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.