On Dec 7, 2007 9:58 AM, Neil Horman <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
> > On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
> > > On Dec 7, 2007 12:50 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On Dec 6, 2007 4:33 PM,
On 10/16/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007 21:51:13 +0200 Thomas Meyer wrote:
>
> [adding kexec mailing list]
>
>
> > Hi.
> >
> > Look at this:
> >
> > $ file arch/x86/boot/bzImage (tree 821f3eff7cdb9d6c7076effabd46c96c322daed1)
> > arch/x86/boot/bzImage: Linux kerne
On 5/11/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Pavel Machek wrote:
>
> I do not think OLPC is using linuxBIOS these days. What they have
> certainly looks like Sun's ROM monitor.
>
That would be OpenFirmware, then.
current kernel for x86 support OFW boot patch?
YH
-
To unsubscribe from
On 5/9/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote:
Refine SCREEN_INFO sanity check for vgacon initialization.
Checking video mode field only to see whenever SCREEN_INFO is
initialized is not enougth, in some cases it is zero although
a vga card is present. Lets additionally check cols and line
On 5/9/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
We can look in /proc/ioports and see what has reserved
the video resources. That should give us a reasonable
estimate of the video adapter. We can do an ioctl to
the console and see how many lin
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
H. Peter Anvin wrote:
Of course, one could argue that since all of those were obsolete by the
time Linux was first created, that it probably doesn't matter and that
isVGA == 0 pretty much means the more obvious thing.
MDA/HGC stuck around for
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
need one good way to find if there is support vga console.
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
besides elf-x86_64, still need --args-linux to pass sth? but how to
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
I believe YH is asking how we setup real_mode_data in /sbin/kexec.
pxelinux:
SCREEN_INFO.orig_video_mode = 3
SCREEN_INFO.orig_x = 0
SCREEN_INFO.orig_y = 24
x86_boot_params[] :
: 00 18 ff
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Jeremy Fitzhardinge wrote:
Specifically boot_params.screen_info isn't being properly set up by the
caller.
will setup real_mode_data in kexec path?
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
You might try a git-bisect, or if it is just these patches
walking through them one-by-one.
f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
Author: Gerd Hoffmann <[EMAIL PROTECTE
the mkelfImage 2.7 patch is at
https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Eric,
i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments
So i use mkelfImage with my patch ( convert elf64 to elf32) to make
another elf32. and loaded with kexec and can not get vga console too.
---serial console works well.
the mkelfImage 2.7 patch is
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
setup.S is never executed while doing kexec (unless somebody chooses to
do a real mode entry) and these patches don't change this beahviour.
Tomorrow I will test VGA behaviour on my machine. Are you using some
special frame buffer mode etc?
I
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Yes. setup.S has always been skipped by bzImage via the kexec path
unless you explicitly tell /sbin/kexec to use the 16bit entry point.
Is not having a VGA console a new thing, or it something you just noticed?
Eric
before the changes,
On 5/2/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
>> Jeremy Fitzhardinge wrote:
>> >
>> > So the bzImage structure is currently:
>> >
>> >1. old-style boot sector
>> >2. old-st
On 12/2/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Please yank the direct out of the filename if you are making something
like this out of it. That was my note I was going direct to hardware
which is pretty much assumed if you are in LinuxBIOS.
Yes, I adapted the code to used in LinuxBIO
thanks
YH
On 8/17/05, Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> fyhlu wrote:
> > Me too. If use latest kernel mouse is dead.
> >
> > By the way, did you solve the battery problem in Linux. "Can not read
> > battery status"
>
> Yes. It's a prob
Me too. If use latest kernel mouse is dead.
By the way, did you solve the battery problem in Linux. "Can not read
battery status"
YH
On 8/16/05, Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Christoph Lameter wrote:
> > On Tue, 16 Aug 2005, jerome
last year some time, I have manually the patch from 2.4 to 2.6. my
patch result is the same as 2.4. It only works when bios doesn't do
the init. Then if the BIOS do the init, it will hang there. I assume
something only can be done once.
YH
On 8/15/05, James Simmons <[EMAIL PROTECTED]> wrote:
>
>
james,
I remember that xlinit in 2.6 kernel only works when BIOS option-rom
really init fb.
It can not work if the BIOS option rom is not executed.
For 2.4, it reversed, it can not work if BIOS opton-rom is executed.
Only work if BIOS don't excute the option rom.
YH
On 8/12/05, James Simmons <[
I played a while with atyfb in LinuxBIOS. move the xl_init.c into LinuxBIOS.
there is one patch call xlinit.c that can be used even ati fb is not
inited in BIOS to make kernel still can use atyfb.
I wonder if James put that in mainstream, he already sent one patch
for 2.6.5
please refer to
why matrin need to make apic id to be greater than 0x10 when system is
only 2way?
too much io-apic in system?
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 09:37:11AM -0700, yhlu wrote:
> > So MPTABLE do not have problem with it, only acpi relate
Oh.
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 09:18:07AM -0700, yhlu wrote:
> > good, I will produce one patch next week.
>
> I already did it in my tree.
>
> -Andi
>
-
To unsubscribe from this list: send the line "unsubsc
So MPTABLE do not have problem with it, only acpi related...?
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 04:55:40PM +0200, Martin Wilck wrote:
> > I wrote:
> >
> > >>How so? The XAPIC version check should work there.
> > >
> > >ACPI: LAPIC (acpi_id[0x11] lapic_
good, I will produce one patch next week.
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 11, 2005 at 11:59:21PM -0700, yhlu wrote:
> > andi,
> >
> > is it possible for
> > after the AP1 call_in is done and before AP1 get in tsc_sync_wait
&g
* Allow the master to continue.
*/
cpu_set(cpuid, cpu_callin_map);
On 8/11/05, yhlu <[EMAIL PROTECTED]> wrote:
> andi,
>
> is it possible for
> after the AP1 call_in is done and before AP1 get in tsc_sync_wait
> The AP2 call_in done. and then AP1 get
8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 10, 2005 at 05:43:23PM -0700, yhlu wrote:
> > Yes, I mean more aggressive
> >
> > static void __init smp_init(void)
> > {
> > unsigned int i;
> >
> >
So boot_cpu_id is apic id of BSP.
Anyway sync_tsc(...) there is master and MASTER..., but value are all 0.
YH
On 8/11/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ok being impatient not wanting this tiny bug to be forgotten for
> 2.6.13. Linus please apply this micro patch.
>
> > > stat
gt; On Wed, Aug 10, 2005 at 05:23:31PM -0700, yhlu wrote:
> > I wonder if you can make the bsp can start the APs callin in the same
> > time, and make it asynchronous, So you make spare 2s or more.
>
> The setting of cpu_callin_map in the AP could be moved earlier yes.
> But it&
I wonder if you can make the bsp can start the APs callin in the same
time, and make it asynchronous, So you make spare 2s or more.
YH
On 8/10/05, yhlu <[EMAIL PROTECTED]> wrote:
> In LinuxBIOS, we could init_ecc asynchronous and the time reduced from
> 8x to 2.1x for 8 ways system
In LinuxBIOS, we could init_ecc asynchronous and the time reduced from
8x to 2.1x for 8 ways system. 1x mean 5s for 4G in one cpu. If 16G
will take 20s.
for TSC_SYNC asynchronous maybe you can get back 0.1s...
YH
On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > So my patch still can be used
0, 2005 at 04:14:19PM -0700, Mike Waychison wrote:
> > YhLu wrote:
> > >andi,
> > >
> > >please refer the patch, it will move cpu_set(, cpu_callin_map) from
> > >smi_callin to start_secondary.
> >
> >
> > This patch fixes an apparent race
<[EMAIL PROTECTED]> wrote:
> On Tue, Aug 09, 2005 at 11:50:53AM -0700, yhlu wrote:
> > anyone is working on add driver for ati xpress 200m?
> >
> > without that My turion notebook, can not work read the battery status.
>
> Normally this should be done in ACPI batter
anyone is working on add driver for ati xpress 200m?
without that My turion notebook, can not work read the battery status.
I guess sbs-cm need that driver in kernel.
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
In LinuxBIOS internal structure for resource, We have index member in resource.
So the resource will be count from 0, 7 or etc, but index member
will point to real BAR position.
I would like to see Kernel has simmliar definintion.
in LinuxBIOS
typedef uint64_t resource_t;
struct resource {
I remember last year when I used IBGOLD 0.5 with PCI-X IB card, it
seems that it could support 64 bit pref mem.
I will try IBGOLD 1.7 .
YH
On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
>yhlu> Roland, what is the -16 mean?
>
>yhlu> is it /* Attempt to mo
Roland,
what is the -16 mean?
is it
/* Attempt to modify a QP/EE which is not in the presumed state: */
MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10,
YH
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> You are right. CONG_SPECIAL_QP
>
> ib_mthca: Mellanox InfiniBand HCA dri
In LinuxBIOS, We can allocate 64 bit region ( 0xfc000) to the
mellanox Infiniband card. Some range above 4G. So the mmio below 4G
is some smaller only 128M, Otherwise need 512M. If 4 IB cards are
used, the mmio will be 2G. For new opteron E stepping, We could use
hareware memhole support.
please check the patch for fix overwrite upper 32bit
YH
--- drivers/pci/setup-res.c.orig2005-08-05 10:08:45.0 -0700
+++ drivers/pci/setup-res.c 2005-08-05 13:25:06.0 -0700
@@ -33,6 +33,18 @@
u32 new, check, mask;
int reg;
+if (resno < 6) {
+
dating region "
"%s/%d (high %08x != %08x)\n",
pci_name(dev), resno, new, check);
}
}
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> pci_restore_bars cause that.
> it didn't restore that accor
*/
+ return;
+ }
+
+ for (i = 0; i < numres; i ++)
+ pci_update_resource(dev, &dev->resource[i], i);
+}
+
+/**
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> before I do the cg-update this morning, it didn't mask out the upper 8 bit.
>
> YH
>
> On 8/5/05, Roland
before I do the cg-update this morning, it didn't mask out the upper 8 bit.
YH
On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> yhlu> ps. some kernel pci code patch broke sth yesterday night.
> yhlu> it mask out bit [32-39]
>
> Is it possible that all
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> You are right. CONG_SPECIAL_QP
>
> ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
> ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex
> (Tavor compatibility mode) (:04:00.0)
> ib_mthca
You are right. CONG_SPECIAL_QP
ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex
(Tavor compatibility mode) (:04:00.0)
ib_mthca :04:00.0: FW version 000400060002, max commands 64
ib_mthca :04:00.0: FW s
400 for eqn 3
ib_mthca: probe of :04:00.0 failed with error -16
On 8/4/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> yhlu> i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y I didn't get any
> yhlu> more debug info, is that depend other setting?
>
> It shouldn&
Yes.
On 8/3/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting r. yhlu <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes
> >
> > Roland,
> >
> > In LinuxBIOS, If I enable the prefmem64 to use r
i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y
I didn't get any more debug info, is that depend other setting?
YH
On 8/4/05, yhlu <[EMAIL PROTECTED]> wrote:
> The mellanox can use prefmem64, but the BIOS could only allocate the
> some range below 4G, So 32 bit OS still can use th
YES.
I will send you the output message later about "CONFIG_INFINIBAND_MTHCA_DEBUG=y"
YH
On 8/3/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> yhlu> In LinuxBIOS, If I enable the prefmem64 to use real 64
> yhlu> range. the IB driver in Kernel can not be loade
back if Opteron don't have hardware memhole
support).
YH
On 8/4/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> >>>>> "yhlu" == yhlu <[EMAIL PROTECTED]> writes:
>
> yhlu> YES. I will send you the output message later about
> yhl
Roland,
In LinuxBIOS, If I enable the prefmem64 to use real 64 range. the IB
driver in Kernel can not be loaded.
YH
PCI: 00:18.0 1c1 <- [0x001000 - 0x003fff] io
PCI: 00:18.0 1b9 <- [0xfce000 - 0xfcf07f] prefmem
PCI: 00:18.0 1b1 <- [0x00fc00 - 0x00fd2f] mem
P
Eric,
Latest tree works.
YH
Booting processor 1/4 APIC 0x1
Initializing CPU#1
masked ExtINT on CPU#1
Calibrating delay using timer specific routine.. 4000.31 BogoMIPS (lpj=8000624)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(1) ->
I will use linus's latest tree to have a try.
YH
On 7/29/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> yhlu <[EMAIL PROTECTED]> writes:
>
> > if using you patch, the
> > "synchronized TSC with CPU" never come out.
> >
> > then wit
Can we put tsc_sync_wait() back to smp_callin?
So that it will be executed serially and we can get
"synchronized TSC with CPU"?
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Is that for Nvidia CK804 stuff?
Actually in LinuxBIOS I swap the irq 0 and 2 entries in mptable to
solve the problem. and it could work well with current code.
YH
On 7/29/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> Currently we attempt to restore virtual wire mode on reboot, which
> on
les, maxerr 1415 cycles)
On 7/28/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> yhlu <[EMAIL PROTECTED]> writes:
>
> > I have some problem with this patch.
> >
> > YH
> >
> > On 7/28/05, yhlu <[EMAIL PROTECTED]> wrote:
> >> Do
I have some problem with this patch.
YH
On 7/28/05, yhlu <[EMAIL PROTECTED]> wrote:
> Do you mean solve the timing problem for 2 way dual core or 4 way
> single core above?
>
> YH
>
> On 7/27/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> > s
Do you mean solve the timing problem for 2 way dual core or 4 way
single core above?
YH
On 7/27/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> sync_tsc was using smp_call_function to ask the boot processor
> to report it's tsc value. smp_call_function performs an IPI_send_allbutself
> whi
Andi,
I verify the timing problem could happen with any x86-64 system with
more than 2 cpus. ( 2 way dual core, or four way single core).
please refer the patch, it will move cpu_set(, cpu_callin_map) from
smi_callin to start_secondary.
--- /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel
EFI support in x86-64?
Is EFI only support IA64?
Is acpi in EFI?
YH
On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Jul 2005 20:52:58 -0700
> yhlu <[EMAIL PROTECTED]> wrote:
>
> > Andi,
> >
> > How do yo think about make x86-64 kernel
Andi,
How do yo think about make x86-64 kernel support openfirmware interface?
Can we borrow some code from ppc64 arch?
YH
On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 14, 2005 at 07:46:49PM -0700, yhlu wrote:
> > p.s. can you use powernow when acpi is disa
I didn't see any problem about NUMA with LinuxBIOS + 8way dual core system.
of couse the acpi support in Kernel is disabled.
p.s. can you use powernow when acpi is disabled?
p.s.s Is powerpc64 support ACPI? or ACPI is only can be used by x86?
YH
On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
FYI in Tyan S4881 (8 ways dual core 875 cpu ) with LinuxBIOS I got
also the 1G mem hole is enabled.
So the kernel should be OK with read NUMA directly from HW.
YH
Firmware type: LinuxBIOS
old bootloader convention, maybe loadlin?
Bootdata ok (command line is apic=debug ramdisk_size=65536
root=/d
wonder if suse kernel have some special code to show that. in
Kernel.org, I can not Node0Node 1...
YH
On 7/14/05, Li-Ta Lo <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-07-14 at 10:58 -0700, yhlu wrote:
> > Someone mentioned that NUMA support for dual core opteron need acpi
> >
Someone mentioned that NUMA support for dual core opteron need acpi
support in LinuxBIOS.
there may be some other solution for that.
1. PowerPC already support dual core and it should support NUMA, So
the Open Firmware must have some NUMA entry definition.
Can we make x86-64 kernel support OpenFir
Andi,
Can you look at the patch? It could solve the timing problem.
I also move your ext_apic_id patch into 2.6.13 manaully.
YH
> -Original Message-
> From: YhLu
> Sent: Wednesday, July 06, 2005 5:51 PM
> To: Andi Kleen
> Cc: 'Peter Buckingham'; lin
andi,
please refer the patch, it will move cpu_set(, cpu_callin_map) from
smi_callin to start_secondary.
--- /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel/smpboot.c.orig
2005-07-06 18:41:16.789767168 -0700
+++ /home/yhlu/xx1/linux-2.6.13-rc2/arch/x86_64/kernel/smpboot.c
2005-07-06 18:45
andi,
the core1/node0 take a long while to get TSC synchronized. Is it normal?
i guess
"CPU 1: synchronized TSC with CPU 0" should be just after "CPU 1: Syncing
TSC to CPU0"
YH
cpu 1: setting up apic clock
cpu 1: enabling apic timer
CPU 1: Syncing TSC to CPU 0.
CPU has booted.
waiting for cpu
Andi,
I tried 2.6.12-rc3 with dual way dual cpus.
It seems right mapping should be
CPU 0(2) -> Node 0 -> Core 0
CPU 1(2) -> Node 0 -> Core 1
CPU 2(2) -> Node 1 -> Core 0
CPU 3(2) -> Node 1 -> Core 1
instead of
CPU 0(2) -> Node 0 -> Core 0
CPU 1(2) -> Node 0 -> Core 0
CPU 2(2) -> Node 1 -> Core
Interrupts always go to CPU 11.
If dual core is diabled, it always go to CPU5. It is OK on 32bit mode.
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12
CPU13 CPU14 CPU15
0:
Yes. should not use prink(ERR
YH
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 16, 2005 10:22 PM
> To: YhLu
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: node_to_cpumask x86_64 broken
>
> On Wed, Feb 16,
forget about it. I found the reason: I only put node 0 has RAM installed.
YH
> -Original Message-
> From: YhLu
> Sent: Wednesday, February 16, 2005 9:40 PM
> To: Andi Kleen
> Cc: linux-kernel@vger.kernel.org
> Subject: node_to_cpumask x86_64 broken
>
> I add
I add some printk in k8_bus.c
node id = 0, node_to_cpumask = f
i= 0 ldtbus = 0
i= 1 ldtbus = 40100
i= 2 ldtbus = 0
node id = 1, node_to_cpumask = 0
i= 0 ldtbus = 0
i= 1 ldtbus = 0
i= 2 ldtbus = 70500
node id = 2, node_to_cpumask = 0
i= 0 ldtbus = 0
i= 1 ldtbus = 0
i= 2 ldtbus = 0
node id = 3, node
Thanks.
I will test 64G on node 4-7 only or 64G on node 0-3.
YH
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 15, 2005 2:55 PM
> To: YhLu
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: X86_64 kernel support MAX memory
It passed the memtest86+ 3.1a
No oops dump, it just restart the system.
YH
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 15, 2005 2:42 PM
> To: YhLu
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: X86_64 kernel
If only use 64G RAM, it works well.
YH
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 15, 2005 12:15 PM
> To: YhLu
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: X86_64 kernel support MAX memory.
>
> On Tue, Fe
I got a system with 8 way Opteron. Every CPU has 16G memory.
2.6 kernel x86_64, it will crash when it start the Fifth node.
YH
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 15, 2005 4:08 AM
> To: YhLu
> Cc: linux-kernel@
Andi,
How much is max RAM 2.6.11 x86_64 support on AMD64?
64G or 128G?
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.t
CC arch/x86_64/kernel/asm-offsets.s
arch/x86_64/kernel/asm-offsets.c: In function `main':
arch/x86_64/kernel/asm-offsets.c:65: error: invalid application of `sizeof'
to an incomplete type
arch/x86_64/kernel/asm-offsets.c:66: error: dereferencing pointer to
incomplete type
arch/x86_64/kernel/
79 matches
Mail list logo
