RE: Inclusion of x86_64 memorize ioapic at bootup patch

RE: Inclusion of x86_64 memorize ioapic at bootup patch

[Lu, Yinghai]

I tried to comment the checksum check, then it can boot well..., 
So it must be someone modify the range (add entries...) and do not
update the mptable correctly...

YH

-----Original Message-----
From: ebiederm@xmission.com [mailto:ebiederm@xmission.com] 
Sent: Friday, January 06, 2006 4:30 PM
To: Lu, Yinghai
Cc: Andi Kleen; Vivek Goyal; Fastboot mailing list; linux kernel mailing
list; Morton Andrew Morton
Subject: Re: Inclusion of x86_64 memorize ioapic at bootup patch

Yinghai Lu <yinghai.lu@amd.com> writes:

> Eric,
>
> Do you try kexec with Nvidia ck804 based MB? it seems some one modify
> the mptable but not update the checksum ...

We've got a cluster using 2.6.14 booting over infiniband that
way.

Eric

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[yhlu]

some code clear 3 byte in mptable from 0x468

00000460: 41 01 09 12 03 00 0f 00 41 02 09 13 03 00 0f 00
00000470: 41 03 09 10 03 03 05 00 43 00 ff 00 03 01 05 00
00000480: 43 00 ff 01

00000460: 41 01 09 12 03 00 0f 00 00 00 00 13 03 00 0f 00
00000470: 41 03 09 10 03 03 05 00 43 00 ff 00 03 01 05 00
00000480: 43 00 ff 01

it is third irq entry for pcie slot....

//Slot  PCIE x4
        for(i=0;i<4;i++) {
                smp_write_intsrc(mc, mp_INT,
MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_ck804b_4, (0x00<<2)|i,
apicid_ck804b, 0x10 + (1+i+4-sbdnb%4)%4);
        }


/*Local Ints:   Type    Polarity    Trigger     Bus ID   IRQ    APIC ID PIN#*/
        smp_write_intsrc(mc, mp_ExtINT,
MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, MP_APIC_ALL,
0x0);
        smp_write_intsrc(mc, mp_NMI,
MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, MP_APIC_ALL,
0x1);

the range already in e820 reserved area...

Bootdata ok (command line is apic=debug pci=routeirq
ramdisk_size=65536 root=/dev/ram0 rw console=tty0
console=ttyS0,115200n8 )
Linux version 2.6.15-gdb9edfd7 (root@yhlunb) (gcc version 4.0.2
20050901 (prerelease) (SUSE Linux)) #13 SMP Fri Jan 6 17:58:25 PST
2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000e7c (reserved)
 BIOS-e820: 0000000000000e7c - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000240000000 (usable)

YH

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[yhlu]

andi,

in the smpboot.c, why you need to use 0x467, and 0x469 ....

        Dprintk("1.\n");
        *((volatile unsigned short *) phys_to_virt(0x469)) = start_rip >> 4;
        Dprintk("2.\n");
        *((volatile unsigned short *) phys_to_virt(0x467)) = start_rip & 0xf;
        Dprintk("3.\n");

YH

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[yhlu]

It seems the i386 is the same.

also why the addr (0x467) is not word align....?

YH

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[yhlu]

andi,

In LinuxBIOS, we don't set the MPS 0x467 and the AP still can be started by BSP.

are these really needed for x86_64?

        Dprintk("Setting warm reset code and vector.\n");

        CMOS_WRITE(0xa, 0xf);
        local_flush_tlb();
        Dprintk("1.\n");
        *((volatile unsigned short *) phys_to_virt(0x469)) = start_rip >> 4;
        Dprintk("2.\n");
        *((volatile unsigned short *) phys_to_virt(0x467)) = start_rip & 0xf;
        Dprintk("3.\n");

the STARTUP IPI should work well with MPS v1.4

YH

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Eric W. Biederman]

yhlu <yhlu.kernel@gmail.com> writes:

> andi,
>
> In LinuxBIOS, we don't set the MPS 0x467 and the AP still can be started by BSP.
>
> are these really needed for x86_64?
>
>         Dprintk("Setting warm reset code and vector.\n");
>
>         CMOS_WRITE(0xa, 0xf);
>         local_flush_tlb();
>         Dprintk("1.\n");
>         *((volatile unsigned short *) phys_to_virt(0x469)) = start_rip >> 4;
>         Dprintk("2.\n");
>         *((volatile unsigned short *) phys_to_virt(0x467)) = start_rip & 0xf;
>         Dprintk("3.\n");
>
> the STARTUP IPI should work well with MPS v1.4

There are very large x86 machines that a reset is sent to the remote
cpu and thus 0x40:0x67 and 0x40:0x67 becomes relevant.

YH you didn't do something foolish and put a linuxbios table below
0x500 did you?

Eric

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[yhlu]

MPTABLE in LinuxBIOS is put from 0x20, if the system has too many cpu
and devices (slots)  the mptable will get bigger than 0x464, so it
will use 0x40:67....

We need to put mptable to [0xf0000:0x100000] together with acpi tables.

and if it is bigger than 64k, then we have to put it on special
postion ...from 1K, and pass the posstion of mptable to the kernel via
command line.

I will update the code in LinuxBIOS.

Thanks

YH

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Eric W. Biederman]

yhlu <yhlu.kernel@gmail.com> writes:

> MPTABLE in LinuxBIOS is put from 0x20, if the system has too many cpu
> and devices (slots)  the mptable will get bigger than 0x464, so it
> will use 0x40:67....

Then you or someone moved it.  The base in low memory was originally
at 0x500, to avoid just these kinds of problems.

> We need to put mptable to [0xf0000:0x100000] together with acpi
> tables.

Or move it up a few bytes.

> and if it is bigger than 64k, then we have to put it on special
> postion ...from 1K, and pass the posstion of mptable to the kernel via
> command line.
>
> I will update the code in LinuxBIOS.

Thanks.  It is always a good idea not to assign legacy regions of the
address space new meanings.

Eric

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[yhlu]

good, I will let it start from 0x500, and linuxbios table after it.
that is most easy, and don't need  to use command line to pass the
info, because it the signature is before 1K.

YH

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Eric W. Biederman]

"Lu, Yinghai" <yinghai.lu@amd.com> writes:

> Thanks. You don't need Etherboot with IB later....
>
> How about the size of your first kernel and initrd? Are they in IDE
> Flash?

Yes.  It is a bproc system for LANL.  2 kernel monte finally broke 
so we did a quick switch kexec to get things moving.

Small initrd are a separate issue entirely.

Eric

RE: Inclusion of x86_64 memorize ioapic at bootup patch

[Lu, Yinghai]

Thanks. You don't need Etherboot with IB later....

How about the size of your first kernel and initrd? Are they in IDE
Flash?

YH

-----Original Message-----
From: ebiederm@xmission.com [mailto:ebiederm@xmission.com] 
Sent: Friday, January 06, 2006 4:30 PM
To: Lu, Yinghai
Cc: Andi Kleen; Vivek Goyal; Fastboot mailing list; linux kernel mailing
list; Morton Andrew Morton
Subject: Re: Inclusion of x86_64 memorize ioapic at bootup patch

Yinghai Lu <yinghai.lu@amd.com> writes:

> Eric,
>
> Do you try kexec with Nvidia ck804 based MB? it seems some one modify
> the mptable but not update the checksum ...

We've got a cluster using 2.6.14 booting over infiniband that
way.

Eric

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Eric W. Biederman]

Yinghai Lu <yinghai.lu@amd.com> writes:

> Eric,
>
> Do you try kexec with Nvidia ck804 based MB? it seems some one modify
> the mptable but not update the checksum ...

We've got a cluster using 2.6.14 booting over infiniband that
way.

Eric

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Yinghai Lu]

Eric,

Do you try kexec with Nvidia ck804 based MB? it seems some one modify
the mptable but not update the checksum ...

YH

The first kernel said:

..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 0) ...works.
testing the IO APIC.......................


.................................... done.
Using local APIC timer interrupts.
Detected 12.564 MHz APIC timer.



LBsuse91AMD64:/x/xx/xx/elf # ../kexec -l ram0_2.5_2.6.15_k8.1_mydisk8_x86_64.elf
LBsuse91AMD64:/x/xx/xx/elf # ../kexec -e
Starting new kernel
Firmware type: LinuxBIOS
old bootloader convention, maybe loadlin?
Bootdata ok (command line is apic=debug pci=routeirq
ramdisk_size=65536 root=/dev/ram0 rw console=tty0
console=ttyS0,115200n8 )
Linux version 2.6.15-gdb9edfd7 (root@yhlunb) (gcc version 4.0.2
20050901 (prerelease) (SUSE Linux)) #7 SMP Fri Jan 6 15:18:18 PST 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000e7c (reserved)
 BIOS-e820: 0000000000000e7c - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000240000000 (usable)
ACPI: Unable to locate RSDP
Scanning NUMA topology in Northbridge 24
Number of nodes 4
Node 0 MemBase 0000000000000000 Limit 0000000080000000
Node 1 MemBase 0000000080000000 Limit 0000000140000000
Node 2 MemBase 0000000140000000 Limit 00000001c0000000
Node 3 MemBase 00000001c0000000 Limit 0000000240000000
Using node hash shift of 30
Bootmem setup node 0 0000000000000000-0000000080000000
Bootmem setup node 1 0000000080000000-0000000140000000
Bootmem setup node 2 0000000140000000-00000001c0000000
Bootmem setup node 3 00000001c0000000-0000000240000000
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
SMP mptable: checksum error!
BIOS bug, MP table errors detected!...
... disabling SMP support. (tell your hw vendor)
Allocating PCI resources starting at c4000000 (gap: c0000000:40000000)
Checking aperture...
CPU 0: aperture @ f8000000 size 64 MB
CPU 1: aperture @ f8000000 size 64 MB
CPU 2: aperture @ f8000000 size 64 MB
CPU 3: aperture @ f8000000 size 64 MB
Built 4 zonelists
Kernel command line: apic=debug pci=routeirq ramdisk_size=65536
root=/dev/ram0 rw console=tty0 console=ttyS0,115200n8
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1809.308 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Memory: 8223632k/9437184k available (2958k kernel code, 164588k
reserved, 1183k data, 228k init)
Calibrating delay using timer specific routine.. 3623.87 BogoMIPS (lpj=7247741)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(2) -> Node 0 -> Core 0
mtrr: v2.0 (20020519)
weird, boot CPU (#16) not listed by the BIOS.
SMP motherboard not detected.
Getting VERSION: 40010
Getting VERSION: 40010
Getting ID: 10000000
Getting ID: ef000000
Getting LVT0: 700
Getting LVT1: 400
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at arch/x86_64/kernel/apic.c:333
invalid operand: 0000 [1] SMP
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.15-gdb9edfd7 #7
RIP: 0010:[<ffffffff8056cd64>] <ffffffff8056cd64>{setup_local_APIC+23}
RSP: 0000:ffff810141c49eb8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000010 RCX: 0000000000000000
RDX: 00000000ffffff01 RSI: ffff810141c49f08 RDI: ffffffff80518fc0
RBP: 0000000000000000 R08: 0000000000000720 R09: 00000000ffffffff
R10: 00000000ffffffff R11: ffffffff8023dfa5 R12: 0000000000000010
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff80557800(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00000000005adf18 CR3: 0000000000101000 CR4: 00000000000006e0
Process swapper (pid: 1, threadinfo ffff810141c48000, task ffff810003619480)
Stack: 00000000ffffffff ffffffff8056d089 0000000000010000 0000000000000000
       0000000000000000 0000000000000000 0000000000010000 0000000000000000
       0000000000000000 0000000000000000
Call Trace:<ffffffff8056d089>{APIC_init_uniprocessor+151}
<ffffffff8056beb1>{smp_prepare_cpus+637}
       <ffffffff8010b07a>{init+54} <ffffffff8010b044>{init+0}
       <ffffffff8010e662>{child_rip+8} <ffffffff8010b044>{init+0}
       <ffffffff8010e65a>{child_rip+0}

Code: 0f 0b 68 15 63 40 80 c2 4d 01 48 8b 05 bb 6d f0 ff ff 50 28
RIP <ffffffff8056cd64>{setup_local_APIC+23} RSP <ffff810141c49eb8>
 <0>Kernel panic - not syncing: Attempted to kill init!

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Andi Kleen]

I queued it now.
-Andi

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Andi Kleen]

On Fri, Jan 06, 2006 at 01:02:16AM -0700, Eric W. Biederman wrote:
> Andrew Morton <akpm@osdl.org> writes:
> >
> > Please don't top-post.
> >
> >> 
> >> On 1/2/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> >> > Hi Andi,
> >> >
> >> > Can you please include the following patch. This patch has already been
> > pushed
> >> > by Andrew.
> >> >
> >> >
> > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
> >
> > IIRC, I dropped this patch because of discouraging noises from Andi and
> > because underlying x86_64 changes broke it in ugly ways.
> 
> Ok.  I just as extensively as I could and I can't find the under laying
> x86_64 changes that Andi mentioned he was working on.  I have looked
> in current -mm and in Andi merge and experimental quilt trees.  It
> could be that I'm  blind but I looked and I did not see them.
> 
> Even in the discussion where this was mentioned there never was a 
> semantic conflict.  But rather two patches passing so close they
> touched the same or neighboring lines of code.
> 
> > It needs to be
> > redone and Andi's objections (whatever they were) need to be addressed or
> > argued about.
> 
> The difference was one of approach.  Andi wanted us to treat the apics
> as black boxes and save and restore register values with no regard as
> to what the registers did.  This is theoretically more future proof,
> but it looses flexibility.

Well I still think it would be better to do it in the generic way,
but i'm not feeling very strongly about it anymore.

> to change the destination cpu, in the kexec on panic case.  This
> is something that cannot be done if we simply saved off the registers.
>      
> > Right now the patch is rather dead.
> 
> Current the referred to patch applies just fine, to 2.6.15,
> and except for a conflict with the above mentioned patch which
> applies fine to 2.6.15-mm1 as well.


It conflicts with the x86-64 timer routing rewrite I did, but that's currently
on hold because it has some other issues.  I can merge them later, no problem.

-Andi

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Eric W. Biederman]

Yinghai Lu <yinghai.lu@amd.com> writes:

> the patch is good.
>
> I tried LinuxBIOS with kexec.
>
> without this patch: I need to disable acpi in kernel. otherwise the
> kernel with acpi support can boot the second kernel, but the second
> kernel will hang after
>
> time.c: Using 14.318180 MHz HPET timer.
> time.c: Detected 2197.663 MHz processor.
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )

Yes. This is the reason the patch was written.  Every bios that
implements acpi has this problem.

Eric

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Eric W. Biederman]

Andrew Morton <akpm@osdl.org> writes:
>
> Please don't top-post.
>
>> 
>> On 1/2/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
>> > Hi Andi,
>> >
>> > Can you please include the following patch. This patch has already been
> pushed
>> > by Andrew.
>> >
>> >
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
>
> IIRC, I dropped this patch because of discouraging noises from Andi and
> because underlying x86_64 changes broke it in ugly ways.

Ok.  I just as extensively as I could and I can't find the under laying
x86_64 changes that Andi mentioned he was working on.  I have looked
in current -mm and in Andi merge and experimental quilt trees.  It
could be that I'm  blind but I looked and I did not see them.

Even in the discussion where this was mentioned there never was a 
semantic conflict.  But rather two patches passing so close they
touched the same or neighboring lines of code.

> It needs to be
> redone and Andi's objections (whatever they were) need to be addressed or
> argued about.

The difference was one of approach.  Andi wanted us to treat the apics
as black boxes and save and restore register values with no regard as
to what the registers did.  This is theoretically more future proof,
but it looses flexibility.

My approach is to treat the apics as something we understand, and
simply save off the one small piece of information from the boot
time state that we can't discover any other way.

The x86_64-ioapic-virtual-wire-mode-fix.patch in 2.6.15-mm1 actually
takes advantage of the fact we understand what the apics are doing
to change the destination cpu, in the kexec on panic case.  This
is something that cannot be done if we simply saved off the registers.
     
> Right now the patch is rather dead.

Current the referred to patch applies just fine, to 2.6.15,
and except for a conflict with the above mentioned patch which
applies fine to 2.6.15-mm1 as well.

Putting the apics in a state where we can use them if fundamental
so to booting a kernel so this is something we need to resolve
if we want kexec to be usable.

A revived version of the patch that applies without patch
follows.


Eric

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Vivek Goyal]

On Thu, Jan 05, 2006 at 04:38:48PM -0800, Andrew Morton wrote:
> Yinghai Lu <yinghai.lu@amd.com> wrote:
> >
> > the patch is good.
> > 
> > I tried LinuxBIOS with kexec.
> > 
> > without this patch: I need to disable acpi in kernel. otherwise the
> > kernel with acpi support can boot the second kernel, but the second
> > kernel will hang after
> > 
> > time.c: Using 14.318180 MHz HPET timer.
> > time.c: Detected 2197.663 MHz processor.
> > Console: colour VGA+ 80x25
> > Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> > Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> > Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )
> > 
> > 
> 
> Please don't top-post.
> 
> > 
> > On 1/2/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > > Hi Andi,
> > >
> > > Can you please include the following patch. This patch has already been pushed
> > > by Andrew.
> > >
> > > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
> 
> IIRC, I dropped this patch because of discouraging noises from Andi and
> because underlying x86_64 changes broke it in ugly ways.  It needs to be
> redone and Andi's objections (whatever they were) need to be addressed or
> argued about.
> 

Andrew, as per my information this patch has not broken anything. It was
other patch which tried to initialize ioapics early which had broken some
sysmtems and that patch has already been dropped.

Andi's main concern with this patch is that it has got special case
knowledge of 8259 and legacy stuff. He would rather prefer, saving all the
APIC states early during boot and restore it back during reboot.

This shall work well for kexec but will not work for kdump as we might
crash on a non-boot cpu and second kernel will come up on a non-boot cpu.
Just restoring the APIC states shall ensure that kernel can boot well on
BIOS designated boot cpu but it does not hold good for other cpus. One
example is that other cpus will not receive timer interrupts during early
boot.

Hence there does not seem to be any escape route except relocate
to boot cpu after crash and second kernel comes up on BIOS designated
boot cpu. But after crash relocating to boot cpu might not be a very
reliable thing to do.

Thanks
Vivek

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Andrew Morton]

Yinghai Lu <yinghai.lu@amd.com> wrote:
>
> the patch is good.
> 
> I tried LinuxBIOS with kexec.
> 
> without this patch: I need to disable acpi in kernel. otherwise the
> kernel with acpi support can boot the second kernel, but the second
> kernel will hang after
> 
> time.c: Using 14.318180 MHz HPET timer.
> time.c: Detected 2197.663 MHz processor.
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )
> 
> 

Please don't top-post.

> 
> On 1/2/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > Hi Andi,
> >
> > Can you please include the following patch. This patch has already been pushed
> > by Andrew.
> >
> > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch

IIRC, I dropped this patch because of discouraging noises from Andi and
because underlying x86_64 changes broke it in ugly ways.  It needs to be
redone and Andi's objections (whatever they were) need to be addressed or
argued about.

Right now the patch is rather dead.

Re: Inclusion of x86_64 memorize ioapic at bootup patch

[Yinghai Lu]

the patch is good.

I tried LinuxBIOS with kexec.

without this patch: I need to disable acpi in kernel. otherwise the
kernel with acpi support can boot the second kernel, but the second
kernel will hang after

time.c: Using 14.318180 MHz HPET timer.
time.c: Detected 2197.663 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )


YH

On 1/2/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> Hi Andi,
>
> Can you please include the following patch. This patch has already been pushed
> by Andrew.
>
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
>
> This patch is regarding remembering at boot up time where i8259 is connected
> and restore the APIC settings back during kexec boot or kdump boot. This
> enables getting timer interrupts in new kernel in legacy mode.
>
> This patch is needed to make kexec and kdump work on some systems,
> especially opteron boxes. Otherwise the second kernel does not receive
> timer interrupts during early boot hence hangs.
>
> I understand, that you are inclined towards remembering all the APIC states
> and simply restore it back instead of putting hooks. This will work
> well for kexec but not for kdump because in kdump system can crash on
> non-boot cpu.
>
> Restoring BIOS APIC state can make sure that BIOS designated boot cpu will
> always be able to see timer interrupts in legacy mode but same does not
> hold good if new kernel boots on some other cpu as is the case with kdump.
>
> In case of kexec boot, we relocate to boot cpu but in case of kdump we
> don't because it was suggested that in some extreme cases of crash, boot cpu
> might not respond even to NMI and relocation to boot cpu will not be
> possible.
>
> Can you please re-consider this patch for inclusion.
>
> Thanks
> Vivek
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Inclusion of x86_64 memorize ioapic at bootup patch

[Vivek Goyal]

Hi Andi,

Can you please include the following patch. This patch has already been pushed
by Andrew.

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch

This patch is regarding remembering at boot up time where i8259 is connected
and restore the APIC settings back during kexec boot or kdump boot. This
enables getting timer interrupts in new kernel in legacy mode.

This patch is needed to make kexec and kdump work on some systems,
especially opteron boxes. Otherwise the second kernel does not receive
timer interrupts during early boot hence hangs.

I understand, that you are inclined towards remembering all the APIC states
and simply restore it back instead of putting hooks. This will work 
well for kexec but not for kdump because in kdump system can crash on 
non-boot cpu.

Restoring BIOS APIC state can make sure that BIOS designated boot cpu will 
always be able to see timer interrupts in legacy mode but same does not 
hold good if new kernel boots on some other cpu as is the case with kdump.

In case of kexec boot, we relocate to boot cpu but in case of kdump we
don't because it was suggested that in some extreme cases of crash, boot cpu
might not respond even to NMI and relocation to boot cpu will not be
possible.

Can you please re-consider this patch for inclusion.

Thanks
Vivek