* [parisc-linux] Linux only see 2Gb of ram of N4k
@ 2004-02-20 18:04 Joel Soete
2004-02-20 18:21 ` Matthew Wilcox
0 siblings, 1 reply; 9+ messages in thread
From: Joel Soete @ 2004-02-20 18:04 UTC (permalink / raw)
To: parisc-linux
Hi all,
My collegue make me notice that the N4k on which I can test Linux was supplied
with 4Gb of ram (which if confirm at boot prompt) but Linux only see 2Gb.
It is a dual cpu machine, is that 1/2 ram dedicated to 1 cpu and the other
1/2 to the 2d cpu?
Thanks for advise,
Joel
----------------------------------------------------------------------------------------
Tiscali ADSL: 19,50 /mois, pendant 3 mois! L'Internet rapide, c'est pour
tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [parisc-linux] Linux only see 2Gb of ram of N4k
2004-02-20 18:04 [parisc-linux] Linux only see 2Gb of ram of N4k Joel Soete
@ 2004-02-20 18:21 ` Matthew Wilcox
2004-02-21 18:19 ` Joel Soete
2004-02-22 5:49 ` Grant Grundler
0 siblings, 2 replies; 9+ messages in thread
From: Matthew Wilcox @ 2004-02-20 18:21 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
On Fri, Feb 20, 2004 at 07:04:26PM +0100, Joel Soete wrote:
> Hi all,
>
> My collegue make me notice that the N4k on which I can test Linux was supplied
> with 4Gb of ram (which if confirm at boot prompt) but Linux only see 2Gb.
>
> It is a dual cpu machine, is that 1/2 ram dedicated to 1 cpu and the other
> 1/2 to the 2d cpu?
Unlikely. As I recall, the N4k diagram looks like this:
<-PCI-> Elroy <-Ropes\ PA <-+-> PA PA <-+-> PA /Ropes-> Elroy
<-PCI-> Elroy <-Ropes-\ DEW RAM DEW /-Ropes-> Elroy
<-PCI-> Elroy <-Ropes--> IKE <-Merced-> Stretch <-Merced-> IKE <--Ropes-> Elroy
<-PCI-> Elroy <-Ropes-/ DEW RAM DEW \-Ropes-> Elroy
<-PCI-> Elroy <-Ropes/ PA <-+-> PA PA <-+-> PA \Ropes-> Elroy
So the RAM is uniformly-accessible from all CPUs, but the IO is not.
If you look at pat_memconfig() in arch/parisc/kernel/inventory.c, you'll
see how we try to figure out what memory ranges are in the machine.
Want to try debugging that, see what's being reported by firmware?
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [parisc-linux] Linux only see 2Gb of ram of N4k
2004-02-20 18:21 ` Matthew Wilcox
@ 2004-02-21 18:19 ` Joel Soete
2004-02-22 5:49 ` Grant Grundler
1 sibling, 0 replies; 9+ messages in thread
From: Joel Soete @ 2004-02-21 18:19 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: parisc-linux
Matthew Wilcox wrote:
> On Fri, Feb 20, 2004 at 07:04:26PM +0100, Joel Soete wrote:
>
>>Hi all,
>>
>>My collegue make me notice that the N4k on which I can test Linux was supplied
>>with 4Gb of ram (which if confirm at boot prompt) but Linux only see 2Gb.
>>
>>It is a dual cpu machine, is that 1/2 ram dedicated to 1 cpu and the other
>>1/2 to the 2d cpu?
>
>
> Unlikely. As I recall, the N4k diagram looks like this:
>
> <-PCI-> Elroy <-Ropes\ PA <-+-> PA PA <-+-> PA /Ropes-> Elroy
> <-PCI-> Elroy <-Ropes-\ DEW RAM DEW /-Ropes-> Elroy
> <-PCI-> Elroy <-Ropes--> IKE <-Merced-> Stretch <-Merced-> IKE <--Ropes-> Elroy
> <-PCI-> Elroy <-Ropes-/ DEW RAM DEW \-Ropes-> Elroy
> <-PCI-> Elroy <-Ropes/ PA <-+-> PA PA <-+-> PA \Ropes-> Elroy
>
> So the RAM is uniformly-accessible from all CPUs, but the IO is not.
That is also what I believe to have understood from our previous talk about N Stretch mmu
(but I am never sure to well undertand, thanks to confirm)
>
> If you look at pat_memconfig() in arch/parisc/kernel/inventory.c, you'll
> see how we try to figure out what memory ranges are in the machine.
> Want to try debugging that, see what's being reported by firmware?
>
I will try.
Many thanks,
Joel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [parisc-linux] Linux only see 2Gb of ram of N4k
2004-02-20 18:21 ` Matthew Wilcox
2004-02-21 18:19 ` Joel Soete
@ 2004-02-22 5:49 ` Grant Grundler
2004-02-23 8:30 ` Joel Soete
1 sibling, 1 reply; 9+ messages in thread
From: Grant Grundler @ 2004-02-22 5:49 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: parisc-linux
On Fri, Feb 20, 2004 at 06:21:40PM +0000, Matthew Wilcox wrote:
> Unlikely. As I recall, the N4k diagram looks like this:
Beautiful diagram! (I'm saving that one)
And I confirmed it is correct in case anyone had doubts.
(I did)
> So the RAM is uniformly-accessible from all CPUs, but the IO is not.
I don't think there is much penalty for CPU's to access MMIO space
on "the other side". MMIO reads are so expensive anyway, I'd doubt
it would make that much difference.
> If you look at pat_memconfig() in arch/parisc/kernel/inventory.c, you'll
> see how we try to figure out what memory ranges are in the machine.
> Want to try debugging that, see what's being reported by firmware?
I'm pretty sure it will look like this:
RAM Phys Address
0-2GB -> 0-2GB
-> 2-4GB I/O Space (mostly PCI MMIO)
2-4GB -> 4-6GB (courtesy of the memory controller)
The N-class was the first box which has an I/O hole from 2-4GB
physical address range. I hope Joel will be able to confirm this.
If not, I likely have documentation to confirm this.
grant
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [parisc-linux] Linux only see 2Gb of ram of N4k
2004-02-22 5:49 ` Grant Grundler
@ 2004-02-23 8:30 ` Joel Soete
2004-03-23 15:07 ` Joel Soete
0 siblings, 1 reply; 9+ messages in thread
From: Joel Soete @ 2004-02-23 8:30 UTC (permalink / raw)
To: Grant Grundler, Matthew Wilcox; +Cc: parisc-linux
>Beautiful diagram! (I'm saving that one)
Yes, Nice
>And I confirmed it is correct in case anyone had doubts.
(I did)
>> So the RAM is uniformly-accessible from all CPUs, but the IO is not.
>
>I don't think there is much penalty for CPU's to access MMIO space
>on "the other side". MMIO reads are so expensive anyway, I'd doubt
>it would make that much difference.
>
>> If you look at pat_memconfig() in arch/parisc/kernel/inventory.c, you'll
>> see how we try to figure out what memory ranges are in the machine.
>> Want to try debugging that, see what's being reported by firmware?
>
>I'm pretty sure it will look like this:
>RAM Phys Address
>0-2GB -> 0-2GB
> -> 2-4GB I/O Space (mostly PCI MMIO)
>2-4GB -> 4-6GB (courtesy of the memory controller)
>
>The N-class was the first box which has an I/O hole from 2-4GB
>physical address range. I hope Joel will be able to confirm this.
>If not, I likely have documentation to confirm this.
>
Awaiting I have a more detail look into code, I already have a cat of /proc/iomem:
palx4000:/Sources/Debian4hppa# cat /proc/iomem
00000000-7fffffff : System RAM
00000000-000009ff : PDC data (Page Zero)
00100000-00451387 : Kernel code
00451388-00605567 : Kernel data
fffffff004000000-fffffff07fffffff : LBA GMMIO
fffffff084000000-fffffff0ffffffff : LBA GMMIO
fffffff104000000-fffffff17fffffff : LBA GMMIO
fffffff204000000-fffffff27fffffff : LBA GMMIO
fffffff284000000-fffffff2ffffffff : LBA GMMIO
fffffff404000000-fffffff47fffffff : LBA GMMIO
fffffff504000000-fffffff57fffffff : LBA GMMIO
fffffff604000000-fffffff67fffffff : LBA GMMIO
fffffff804000000-fffffff87fffffff : LBA GMMIO
fffffff904000000-fffffff97fffffff : LBA GMMIO
fffffffa04000000-fffffffa7fffffff : LBA GMMIO
fffffffc04000000-fffffffc7fffffff : LBA GMMIO
fffffffd04000000-fffffffd7fffffff : LBA GMMIO
fffffffe04000000-fffffffe7fffffff : LBA GMMIO
ffffffff80000000-ffffffff81ffffff : LBA LMMIO
ffffffff80000000-ffffffff80000fff : 0000:00:04.1
ffffffff80000000-ffffffff80000007 : serial
ffffffff80000008-ffffffff8000000f : serial
ffffffff80000010-ffffffff80000017 : serial
ffffffff80000038-ffffffff8000003f : serial
ffffffff80001000-ffffffff80001fff : 0000:00:02.0
ffffffff80001000-ffffffff80001fff : sym53c8xx
ffffffff80002000-ffffffff80002fff : 0000:00:02.1
ffffffff80002000-ffffffff80002fff : sym53c8xx
ffffffff80003000-ffffffff800033ff : 0000:00:00.0
ffffffff80003000-ffffffff800033ff : tulip
ffffffff80004000-ffffffff800040ff : 0000:00:02.0
ffffffff80004000-ffffffff800040ff : sym53c8xx
ffffffff80005000-ffffffff800050ff : 0000:00:02.1
ffffffff80005000-ffffffff800050ff : sym53c8xx
ffffffff80040000-ffffffff8007ffff : 0000:00:00.0
ffffffff80080000-ffffffff800800ff : 0000:00:01.0
ffffffff80080000-ffffffff800800ff : sym53c8xx
ffffffff80100000-ffffffff80100fff : 0000:00:01.0
ffffffff80100000-ffffffff80100fff : sym53c8xx
ffffffff82000000-ffffffff83ffffff : LBA LMMIO
ffffffff84000000-ffffffff85ffffff : LBA LMMIO
ffffffff88000000-ffffffff89ffffff : LBA LMMIO
ffffffff88000000-ffffffff8801ffff : 0000:20:00.0
ffffffff88020000-ffffffff8803ffff : 0000:20:00.0
ffffffff88040000-ffffffff880401ff : 0000:20:00.0
ffffffff8a000000-ffffffff8bffffff : LBA LMMIO
ffffffff8a000000-ffffffff8a0003ff : 0000:28:00.0
ffffffff8a000000-ffffffff8a0003ff : tulip
ffffffff90000000-ffffffff91ffffff : LBA LMMIO
ffffffff94000000-ffffffff95ffffff : LBA LMMIO
ffffffff98000000-ffffffff99ffffff : LBA LMMIO
ffffffffbffe0000-ffffffffbffe0fff : lba
ffffffffbffe2000-ffffffffbffe2fff : lba
ffffffffbffe4000-ffffffffbffe4fff : lba
ffffffffbffe8000-ffffffffbffe8fff : lba
ffffffffbffea000-ffffffffbffeafff : lba
ffffffffbfff0000-ffffffffbfff0fff : lba
ffffffffbfff4000-ffffffffbfff4fff : lba
ffffffffbfff8000-ffffffffbfff8fff : lba
ffffffffc0000000-ffffffffc1ffffff : LBA LMMIO
ffffffffc4000000-ffffffffc5ffffff : LBA LMMIO
ffffffffc8000000-ffffffffc9ffffff : LBA LMMIO
ffffffffd0000000-ffffffffd1ffffff : LBA LMMIO
ffffffffd4000000-ffffffffd5ffffff : LBA LMMIO
ffffffffd4000000-ffffffffd401ffff : 0000:d0:00.0
ffffffffd4020000-ffffffffd403ffff : 0000:d0:00.0
ffffffffd4040000-ffffffffd40401ff : 0000:d0:00.0
ffffffffd8000000-ffffffffd9ffffff : LBA LMMIO
ffffffffd8000000-ffffffffd801ffff : 0000:e0:00.0
ffffffffd8020000-ffffffffd803ffff : 0000:e0:00.0
ffffffffd8040000-ffffffffd80401ff : 0000:e0:00.0
fffffffffece0000-fffffffffece0fff : lba
fffffffffece4000-fffffffffece4fff : lba
fffffffffece8000-fffffffffece8fff : lba
fffffffffecf0000-fffffffffecf0fff : lba
fffffffffecf4000-fffffffffecf4fff : lba
fffffffffecf8000-fffffffffecf8fff : lba
fffffffffed00000-fffffffffed00fff : SBA
fffffffffed25000-fffffffffed25fff : CPU
fffffffffed40000-fffffffffed40fff : SBA
fffffffffff80000-fffffffffffaffff : Central Bus
fffffffffffb0000-fffffffffffdffff : Local Broadcast
fffffffffffe0000-ffffffffffffffff : Global Broadcast
Does it help?
Joel
----------------------------------------------------------------------------------------
Tiscali ADSL: 19,50 /mois, pendant 3 mois! L'Internet rapide, c'est pour
tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [parisc-linux] Linux only see 2Gb of ram of N4k
2004-02-23 8:30 ` Joel Soete
@ 2004-03-23 15:07 ` Joel Soete
2004-03-24 16:42 ` Joel Soete
0 siblings, 1 reply; 9+ messages in thread
From: Joel Soete @ 2004-03-23 15:07 UTC (permalink / raw)
To: Grant Grundler, Matthew Wilcox; +Cc: parisc-linux
Hi Grant,
I come back to you with more relevant info (I hope)
>I'm pretty sure it will look like this:
>RAM Phys Address
>0-2GB -> 0-2GB
> -> 2-4GB I/O Space (mostly PCI MMIO)
>2-4GB -> 4-6GB (courtesy of the memory controller)
>
>The N-class was the first box which has an I/O hole from 2-4GB
>physical address range. I hope Joel will be able to confirm this.
>If not, I likely have documentation to confirm this.
>
I added some more printk as follow:
in arch/parisc/kernel/inventory.c
static void __init pat_memconfig(void)
{
unsigned long actual_len;
struct pdc_pat_pd_addr_map_entry mem_table[PAT_MAX_RANGES+1];
struct pdc_pat_pd_addr_map_entry *mtbl_ptr;
physmem_range_t *pmem_ptr;
long status;
int entries;
unsigned long length;
int i;
length = (PAT_MAX_RANGES + 1) * sizeof(struct pdc_pat_pd_addr_map_entry);
status = pdc_pat_pd_get_addr_map(&actual_len, mem_table, length,
0L);
/* JSO S */
if ((status == PDC_OK)) {
printk("Status == PDC_OK.\n");
printk("Sizeof(struct pdc_pat_pd_addr_map_entry) = %d.\n",
sizeof(struct pdc_pat_pd_addr_map_entry));
printk("actual_len = %ld.\n", actual_len);
printk("length = %ld.\n", length);
}
/* JSO E */
if ((status != PDC_OK)
|| ((actual_len % sizeof(struct pdc_pat_pd_addr_map_entry)) !=
0)) {
/* The above pdc call shouldn't fail, but, just in
* case, just use the PAGE0 info.
*/
printk("\n\n\n");
printk(KERN_WARNING "WARNING! Could not get full memory configuration.
"
"All memory may not be used!\n\n\n");
pagezero_memconfig();
return;
}
entries = actual_len / sizeof(struct pdc_pat_pd_addr_map_entry);
printk("entries = %d.\n", entries);
if (entries > PAT_MAX_RANGES) {
printk(KERN_WARNING "This Machine has more memory ranges
than we support!\n");
printk(KERN_WARNING "Some memory may not be used!\n");
}
/* Copy information into the firmware independent pmem_ranges
* array, skipping types we don't care about. Notice we said
* "may" above. We'll use all the entries that were returned.
*/
npmem_ranges = 0;
mtbl_ptr = mem_table;
pmem_ptr = pmem_ranges; /* Global firmware independent table */
for (i = 0; i < entries; i++,mtbl_ptr++) {
if ( (mtbl_ptr->entry_type != PAT_MEMORY_DESCRIPTOR)
|| (mtbl_ptr->memory_type != PAT_MEMTYPE_MEMORY)
|| (mtbl_ptr->pages == 0)
|| ( (mtbl_ptr->memory_usage != PAT_MEMUSE_GENERAL)
&& (mtbl_ptr->memory_usage != PAT_MEMUSE_GI)
&& (mtbl_ptr->memory_usage != PAT_MEMUSE_GNI) ) )
{
continue;
}
if (npmem_ranges == MAX_PHYSMEM_RANGES) {
printk(KERN_WARNING "This Machine has more memory
ranges than we support!\n");
printk(KERN_WARNING "Some memory will not be used!\n");
break;
}
set_pmem_entry(pmem_ptr++,mtbl_ptr->paddr,mtbl_ptr->pages);
npmem_ranges++;
}
for (i = 0; i < entries; i++)
printk("pmem_ranges[%d].pages = %ld.\n", i, pmem_ranges[i].pages);
printk("npmem_ranges = %d.\n", npmem_ranges);
}
arch/parisc/mm/init.c
static void __init setup_bootmem(void)
{
[snip]
#ifndef CONFIG_DISCONTIGMEM
/*
* Sort the ranges. Since the number of ranges is typically
* small, and performance is not an issue here, just do
* a simple insertion sort.
*/
printk("npmem_ranges = %d.(line 143)\n", npmem_ranges);
for (i = 1; i < npmem_ranges; i++) {
int j;
for (j = i; j > 0; j--) {
unsigned long tmp;
if (pmem_ranges[j-1].start_pfn <
pmem_ranges[j].start_pfn) {
break;
}
tmp = pmem_ranges[j-1].start_pfn;
pmem_ranges[j-1].start_pfn = pmem_ranges[j].start_pfn;
pmem_ranges[j].start_pfn = tmp;
tmp = pmem_ranges[j-1].pages;
pmem_ranges[j-1].pages = pmem_ranges[j].pages;
pmem_ranges[j].pages = tmp;
}
}
/*
* Throw out ranges that are too far apart (controlled by
* MAX_GAP). If CONFIG_DISCONTIGMEM wasn't implemented so
* poorly, we would recommend enabling that option, but,
* until it is fixed, this is the best way to go.
*/
printk("npmem_ranges = %d.(line 171)\n", npmem_ranges);
for (i = 1; i < npmem_ranges; i++) {
printk("pmem_ranges[%d].start_pfn = %ld.\n", i-1, pmem_ranges[i-1].pages);
printk("pmem_ranges[%d].pages = %ld.\n", i-1, pmem_ranges[i-1].pages);
printk("pmem_ranges[%d].start_pfn = %ld.\n", i, pmem_ranges[i].pages);
printk("MAX_GAP = %ld.\n", MAX_GAP);
if (pmem_ranges[i].start_pfn -
(pmem_ranges[i-1].start_pfn +
pmem_ranges[i-1].pages) > MAX_GAP) {
npmem_ranges = i;<=====================[ref1.]
break;
}
}
#endif
printk("npmem_ranges = %d.(line 186)\n", npmem_ranges);
if (npmem_ranges > 1) {
[snip]
<==== return by pat_memconfig() ====>
Status == PDC_OK.
Sizeof(struct pdc_pat_pd_addr_map_entry) = 32.
actual_len = 64.
length = 1056.
entries = 2.
pmem_ranges[0].pages = 524288.
pmem_ranges[1].pages = 524288.
npmem_ranges = 2.
So pat_memconfig() returns well 2 entries of 2Gb Ok
<==== return by setup_bootmem() ====>
npmem_ranges = 2.(line 143)
npmem_ranges = 2.(line 171)
pmem_ranges[0].start_pfn = 524288.
pmem_ranges[0].pages = 524288.
pmem_ranges[1].start_pfn = 524288.
MAX_GAP = 262144.
npmem_ranges = 1.(line 186)
pmem_ranges[0].pages = 524288.
So here only one entry is scan because of condition ([ref1]) but I have no
clue of the actual meaning of this condition. Thanks in advance for info
:)
RSize = 2147483648.
Total Memory: 2048 Mb
On node 0 totalpages: 524288
Thanks,
Joel
----------------------------------------------------------------------------------------
Tiscali ADSL: 35 /mois, la meilleure offre du marché!
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [parisc-linux] Linux only see 2Gb of ram of N4k
2004-03-23 15:07 ` Joel Soete
@ 2004-03-24 16:42 ` Joel Soete
2004-03-24 17:39 ` Grant Grundler
0 siblings, 1 reply; 9+ messages in thread
From: Joel Soete @ 2004-03-24 16:42 UTC (permalink / raw)
To: Grant Grundler, Matthew Wilcox; +Cc: parisc-linux
Hi Grant,
Sorry but I make a typo in
arch/parisc/mm/init.c
static void __init setup_bootmem(void)
{
[snip]
/*
* Throw out ranges that are too far apart (controlled by
* MAX_GAP). If CONFIG_DISCONTIGMEM wasn't implemented so
* poorly, we would recommend enabling that option, but,
* until it is fixed, this is the best way to go.
*/
printk("npmem_ranges = %d.(line 171)\n", npmem_ranges);
for (i = 1; i < npmem_ranges; i++) {
printk("pmem_ranges[%d].start_pfn = %ld.\n", i-1,
pmem_ranges[i-1].pages); <=== should be start_pfn also
printk("pmem_ranges[%d].pages = %ld.\n", i-1,
pmem_ranges[i-1].pages);
printk("pmem_ranges[%d].start_pfn = %ld.\n", i,
pmem_ranges[i].pages); <==== here the same
printk("MAX_GAP = %ld.\n", MAX_GAP);
[snip]
And actual results would be:
<==== return by setup_bootmem() ====>
pmem_ranges[0].start_pfn = 0.
pmem_ranges[0].pages = 524288.
pmem_ranges[1].start_pfn = 1572864.
Is it much more in accordance to your knowledge?
Thanks for advise,
Joel
PS: May I risk to play with CONFIG_DISCONTIGMEM?
----------------------------------------------------------------------------------------
Tiscali ADSL: 35 /mois, la meilleure offre du marché!
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [parisc-linux] Linux only see 2Gb of ram of N4k
2004-03-24 16:42 ` Joel Soete
@ 2004-03-24 17:39 ` Grant Grundler
2004-03-24 18:23 ` Joel Soete
0 siblings, 1 reply; 9+ messages in thread
From: Grant Grundler @ 2004-03-24 17:39 UTC (permalink / raw)
To: Joel Soete; +Cc: Matthew Wilcox, parisc-linux
On Wed, Mar 24, 2004 at 05:42:06PM +0100, Joel Soete wrote:
...
> And actual results would be:
> <==== return by setup_bootmem() ====>
> pmem_ranges[0].start_pfn = 0.
> pmem_ranges[0].pages = 524288.
> pmem_ranges[1].start_pfn = 1572864.
>
> Is it much more in accordance to your knowledge?
It's more or less what I was expecting, yes.
> PS: May I risk to play with CONFIG_DISCONTIGMEM?
Isn't this open source? of course you can.
thanks,
grant
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [parisc-linux] Linux only see 2Gb of ram of N4k
2004-03-24 17:39 ` Grant Grundler
@ 2004-03-24 18:23 ` Joel Soete
0 siblings, 0 replies; 9+ messages in thread
From: Joel Soete @ 2004-03-24 18:23 UTC (permalink / raw)
To: Grant Grundler; +Cc: Matthew Wilcox, parisc-linux
> > PS: May I risk to play with CONFIG_DISCONTIGMEM?
>
> Isn't this open source? of course you can.
:))
I just didn't see any way to select it with 'make menuconfig' as there are
no Kconfig entry for parisc. I so conclude that anybody had never tested
this code (even in 2.4).
But ok when I will recover the availability of this server for my linux test,
I will try to build a kernel with this stuff.
Thanks a lot,
Joel
----------------------------------------------------------------------------------------
Tiscali ADSL: 35 /mois, la meilleure offre du marché!
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-03-24 18:24 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-20 18:04 [parisc-linux] Linux only see 2Gb of ram of N4k Joel Soete
2004-02-20 18:21 ` Matthew Wilcox
2004-02-21 18:19 ` Joel Soete
2004-02-22 5:49 ` Grant Grundler
2004-02-23 8:30 ` Joel Soete
2004-03-23 15:07 ` Joel Soete
2004-03-24 16:42 ` Joel Soete
2004-03-24 17:39 ` Grant Grundler
2004-03-24 18:23 ` Joel Soete
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox