Nevermind, I got everything working after applying ~9 patches from
2.6.16 back to 2.6.15.7

regards,
Mike

On 8/9/06, Mike Snitzer <[EMAIL PROTECTED]> wrote:
> Vivek,
>
> I'm trying to use 2.6.15.7's kexec on x86_64.  I'm experiencing the
> same hang that Badari detailed (quite some time ago now ;) with the
> last line being similar to Badari's:
>
> Memory: 59240k/81920k available (2979k kernel code, 6256k reserved,
> 1130k data, 204k init)
>
> Can you confirm that this timer interrupt issue was fixed with this 
> changeset?:
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=af5b98042452cc6f50de8afa9d079bda8556d74d
>
> I'll try it in the morning but figured I'd verify with you.
>
> thanks,
> Mike
>
> On 12/19/05, Vivek Goyal <[EMAIL PROTECTED]> wrote:
> > On Fri, Dec 16, 2005 at 09:58:19AM -0800, Badari Pulavarty wrote:
> > > On Fri, 2005-12-16 at 08:58 -0800, Mike Mason wrote:
> > > > An update... I got kexec working on Badari's machine. The second
> > > > kernel loads fine and boots when I force a panic with AltSysRq-C. I
> > > > don't know why it didn't load before. However, on this system the root
> > > > filesystem gets corrupted whenever I force a panic. Fsck runs during
> > > > the second kernel boot, then automatically reboots when fsck finishes,
> > > > so there's never an opportunity copy /proc/vmcore. I assume this is
> > > > the scenario that led to the mkinitrd patches on
> > > > http://lse.sourceforge.net/kdump/.
> > >
> > > Thanks Mike for the update & thrashing my machine :)
> > >
> > > I tried it on another AMD64 machine (with out initrd) -- I was
> > > able to kexec second kernel and force a dump using sysrq-c.
> > > Second kernel boots half way through and hangs (never gave
> > > me prompt to save core). Here are the messages:
> > >
> > > Any ideas on whats happening here ?
> > >
> >
> > Thanks Badri for testing it out. I think here timer interrupts are not
> > coming hence it is waiting inifinitely in calibrate_delay() loop. This
> > does not seem to be an issue with EM64T but we are seeing the same issue
> > with our AMD64 boxes.
> >
> > I am debugging this and working on a patch to save and restore APIC
> > states (As suggested by Andi).
> >
> > Which version of kdump patches (user space) are you using? Can you please
> > use the latest consolidated patch posted by maneesh.
> >
> > http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch
> >
> > This shall be able to initialize ACPI in second kernel (Though it might
> > not be directly related to this timer interrupt issue.)
> >
> > Thanks
> > Vivek
> >
> >
> > > Thanks,
> > > Badari
> > >
> > > SysRq : Trigger a crashdump
> > > Bootdata ok (command line is root=/dev/hda2 console=tty0
> > > console=ttyS0,38400 init 1  memmap=exactmap [EMAIL PROTECTED]
> > > [EMAIL PROTECTED] [EMAIL PROTECTED] elfcorehdr=22056K)
> > > Linux version 2.6.15-rc5-mm3 ([EMAIL PROTECTED]) (gcc version 3.3.3 (SuSE
> > > Linux)) #1 Fri Dec 16 09:09:46 PST 2005
> > > BIOS-provided physical RAM map:
> > >  BIOS-e820: 0000000000000100 - 000000000009f000 (usable)
> > >  BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
> > >  BIOS-e820: 0000000000100000 - 00000000dfef0000 (usable)
> > >  BIOS-e820: 00000000dfef0000 - 00000000dfeff000 (ACPI data)
> > >  BIOS-e820: 00000000dfeff000 - 00000000dff00000 (ACPI NVS)
> > >  BIOS-e820: 00000000dff00000 - 00000000e0000000 (usable)
> > >  BIOS-e820: 00000000fec00000 - 00000000fec00400 (reserved)
> > >  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> > >  BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
> > >  BIOS-e820: 0000000100000000 - 00000001e0000000 (usable)
> > > user-defined physical RAM map:
> > >  user: 0000000000000000 - 00000000000a0000 (usable)
> > >  user: 0000000001000000 - 00000000014ea000 (usable)
> > >  user: 000000000158a400 - 0000000005000000 (usable)
> > > ACPI: Unable to map XSDT header
> > > Intel MultiProcessor Specification v1.4
> > >     Virtual Wire compatibility mode.
> > > OEM ID: AMD      <6>Product ID: HAMMER       <6>APIC at: 0xFEE00000
> > > Processor #0 15:5 APIC version 16
> > > Processor #1 15:5 APIC version 16
> > > WARNING: NR_CPUS limit of 1 reached. Processor ignored.
> > > Processor #2 15:5 APIC version 16
> > > WARNING: NR_CPUS limit of 1 reached. Processor ignored.
> > > Processor #3 15:5 APIC version 16
> > > WARNING: NR_CPUS limit of 1 reached. Processor ignored.
> > > I/O APIC #4 Version 17 at 0xFEC00000.
> > > I/O APIC #5 Version 17 at 0xFA3E0000.
> > > I/O APIC #6 Version 17 at 0xFA3E1000.
> > > I/O APIC #7 Version 17 at 0xFA3E2000.
> > > I/O APIC #8 Version 17 at 0xFA3E4000.
> > > Setting APIC routing to flat
> > > Processors: 1
> > > Allocating PCI resources starting at 10000000 (gap: 5000000:fb000000)
> > > Checking aperture...
> > > CPU 0: aperture @ c000000 size 64 MB
> > > CPU 1: aperture @ c000000 size 64 MB
> > > CPU 2: aperture @ c000000 size 64 MB
> > > CPU 3: aperture @ c000000 size 64 MB
> > > Built 1 zonelists
> > > Initializing CPU#0
> > > Kernel command line: root=/dev/hda2 console=tty0 console=ttyS0,38400
> > > init 1  memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED]
> > > [EMAIL PROTECTED] elfcorehdr=22056K
> > > PID hash table entries: 256 (order: 8, 8192 bytes)
> > > time.c: Using 1.193182 MHz PIT timer.
> > > time.c: Detected 1398.203 MHz processor.
> > > time.c: Using PIT/TSC based timekeeping.
> > > Console: colour dummy device 80x25
> > > Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
> > > Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
> > > Memory: 59240k/81920k available (2979k kernel code, 6256k reserved,
> > > 1130k data, 204k init)
> > >
> > >
> > > Thanks,
> > > Badari
> > >
> >
> > > _______________________________________________
> > > fastboot mailing list
> > > [email protected]
> > > https://lists.osdl.org/mailman/listinfo/fastboot
> >
> >
> >
> > _______________________________________________
> > fastboot mailing list
> > [email protected]
> > https://lists.osdl.org/mailman/listinfo/fastboot
> >
> >
> >
>
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot

Reply via email to