Re: Zero size vmcore on ia64

2008-08-27 Thread Bernhard Walle
Hi Jidong,

* jidong xiao [2008-08-27 17:01]:
 
 I encountered the zero-size-vmcore issue on IA64. I remember last year
 Nanhai submitted a patch which was intended to fix this issue, and I
 noticed that patch is merged into mainline kernel. I am using
 2.6.27-rc2, which means that patch is included in my kernel.And after
 the system
 completed rebooting, there is nothing generated in KDUMP_SAVEDIR. Let
 me know if I need to provide more information.Thanks.

Which version of kexec-tools do you use?

Please always include the kexec list (kexec@lists.infradead.org) on
kdump and kexec issues. I Cc'd it now.


Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: Zero size vmcore on ia64

2008-08-27 Thread jidong xiao
On Wed, Aug 27, 2008 at 5:27 PM, Bernhard Walle [EMAIL PROTECTED] wrote:
 Hi Jidong,

 * jidong xiao [2008-08-27 17:01]:

 I encountered the zero-size-vmcore issue on IA64. I remember last year
 Nanhai submitted a patch which was intended to fix this issue, and I
 noticed that patch is merged into mainline kernel. I am using
 2.6.27-rc2, which means that patch is included in my kernel.And after
 the system
 completed rebooting, there is nothing generated in KDUMP_SAVEDIR. Let
 me know if I need to provide more information.Thanks.

 Which version of kexec-tools do you use?

Well I am using SLES10SP2,(I tried the experiments on SLES10SP2
default kernel and also 2.6.27-rc2 mainline kernel, result is the
same.)
lfg-ia64:/var/log # rpm -qa | grep kexec
kexec-tools-1.101-32.48
lfg-ia64:/var/log # rpm -qa | grep kdump
kdump-0.3.0-8.9
yast2-kdump-2.13.11-0.3

 Please always include the kexec list (kexec@lists.infradead.org) on
 kdump and kexec issues. I Cc'd it now.
Okay, I see. Thanks.

Regards
Jason Xiao

 Bernhard
 --
 Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: Zero size vmcore on ia64

2008-08-27 Thread Bernhard Walle
* jidong xiao [2008-08-27 17:51]:

 On Wed, Aug 27, 2008 at 5:27 PM, Bernhard Walle [EMAIL PROTECTED] wrote:
  Hi Jidong,
 
  * jidong xiao [2008-08-27 17:01]:
 
  I encountered the zero-size-vmcore issue on IA64. I remember last year
  Nanhai submitted a patch which was intended to fix this issue, and I
  noticed that patch is merged into mainline kernel. I am using
  2.6.27-rc2, which means that patch is included in my kernel.And after
  the system
  completed rebooting, there is nothing generated in KDUMP_SAVEDIR. Let
  me know if I need to provide more information.Thanks.
 
  Which version of kexec-tools do you use?
 
 Well I am using SLES10SP2,(I tried the experiments on SLES10SP2
 default kernel and also 2.6.27-rc2 mainline kernel, result is the
 same.)

With the SP2 default kernel, it should work. At lest /proc/vmcore
should have a normal size. Can you set KDUMP_IMMEDIATE_REBOOT to no,
then log in in the serial console and execute

# ls -l /proc/vmcore

For 2.6.27 kernel on IA64, you have to update kexec-tools. I don't know
the exact version when the change was included, but 2.0.0 is safe. :)


Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: Zero size vmcore on ia64

2008-08-27 Thread jidong xiao
On Wed, Aug 27, 2008 at 6:14 PM, Bernhard Walle [EMAIL PROTECTED] wrote:
 * jidong xiao [2008-08-27 17:51]:

 On Wed, Aug 27, 2008 at 5:27 PM, Bernhard Walle [EMAIL PROTECTED] wrote:
  Hi Jidong,
 
  * jidong xiao [2008-08-27 17:01]:
 
  I encountered the zero-size-vmcore issue on IA64. I remember last year
  Nanhai submitted a patch which was intended to fix this issue, and I
  noticed that patch is merged into mainline kernel. I am using
  2.6.27-rc2, which means that patch is included in my kernel.And after
  the system
  completed rebooting, there is nothing generated in KDUMP_SAVEDIR. Let
  me know if I need to provide more information.Thanks.
 
  Which version of kexec-tools do you use?
 
 Well I am using SLES10SP2,(I tried the experiments on SLES10SP2
 default kernel and also 2.6.27-rc2 mainline kernel, result is the
 same.)

 With the SP2 default kernel, it should work. At lest /proc/vmcore
 should have a normal size. Can you set KDUMP_IMMEDIATE_REBOOT to no,
 then log in in the serial console and execute

# ls -l /proc/vmcore
I am sorry to say, I tried to follow your instruction but finally the
out put is zero.
lfg-ia64:~ # ls -l /proc/vmcore
-r 1 root root 0 2008-08-27 18:40 /proc/vmcore


 For 2.6.27 kernel on IA64, you have to update kexec-tools. I don't know
 the exact version when the change was included, but 2.0.0 is safe. :)

Okay I will try to update kexec-tools and do the experiment again then
report it.

In addition following I attached the dmesg info, among other things, I
saw one message: Cannot locate EFI vmcore descriptor, this probably
implies that something is wrong, though I have no idea.

lfg-ia64:~ # dmesg
Linux version 2.6.27-rc2-test ([EMAIL PROTECTED]) (gcc version 4.1.2
20070115 (SUSE Linux)) #8 SMP Wed Aug 27 13:54:51 CST 2008
Ignoring memory below 256MB
Ignoring memory above 512MB
EFI v1.10 by INTEL: SALsystab=0x7fe4c8c0 ACPI=0x7ff99000 ACPI
2.0=0x7ff98000 MPS=0x7ff97000 SMBIOS=0xf
booting generic kernel on platform dig
ACPI: RSDP 7FF98000, 0024 (r2 INTEL )
ACPI: XSDT 7FF98090, 003C (r1 INTEL  SR870BH2  1072002 MSFT10013)
ACPI: FACP 7FF98138, 00F4 (r3 INTEL  SR870BH2  1072002 MSFT10013)
ACPI: DSDT 7FF9A000, 292B (r1  Intel SR870BH20 MSFT  10D)
ACPI: FACS 7FF982E0, 0040
ACPI: APIC 7FF98230, 00AE (r1 INTEL  SR870BH2  1072002 MSFT10013)
ACPI: SPCR 7FF98328, 0050 (r1 INTEL  SR870BH2  1072002 MSFT10013)
Cannot locate EFI vmcore descriptor
Initial ramdisk at: 0xe0001f598000 (10617709 bytes)
SAL 3.1: Intel Corp   SR870BH2
version 3.0
SAL Platform features: BusLock
SAL: AP wakeup using external interrupt vector 0xf0
TR register number exceeds IA64_TR_ALLOC_MAX!IA64_TR_ALLOC_MAX should
be extended
ia64_native_iosapic_pcat_compat_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c000fee0
PLATFORM int CPEI (0x3): GSI 22 (level, low) - CPU 0 (0x) vector 30
register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level
2 CPUs available, 2 CPUs total
MCA related initialization done
Virtual mem_map starts at 0xa0007fc8
Zone PFN ranges:
  DMA  0x4000 - 0x0004
  Normal   0x0004 - 0x0004
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x4000 - 0x7ff8
0: 0x7ff9 - 0x8000
On node 0 totalpages: 16383
free_area_init_node: node 0, pgdat e0001140, node_mem_map
a0007fc8
  DMA zone: 16327 pages, LIFO batch:3
SMP: Allowing 2 CPUs, 0 hotplug CPUs
Built 1 zonelists in Node order, mobility grouping off.  Total pages: 16327
Policy zone: DMA
Kernel command line: CRASH=1  root=/dev/sda2  insmod=usbcore
insmod=uhci-hcd insmod=ohci-hcd insmod=ehci-hcd insmod=hid   ro
elevator=deadline sysrq=1 reset_devices irqpoll maxcpus=1  1
elfcorehdr=524160K max_addr=512M min_addr=256M
Misrouted IRQ fixup and polling support enabled
This may significantly impact system performance
PID hash table entries: 1024 (order: 10, 8192 bytes)
CPU 0: base freq=199.457MHz, ITC ratio=15/2, ITC freq=1495.930MHz
Console: colour VGA+ 80x25
console [tty0] enabled
Placing software IO TLB between 0x115d8000 - 0x155d8000
Memory: 163648k/233584k available (6640k code, 98480k reserved, 5825k
data, 2016k init)
Calibrating delay loop... 2211.84 BogoMIPS (lpj=4423680)
kdb version 4.4 by Keith Owens, Scott Lurndal. Copyright SGI, All
Rights Reserved
Security Framework initialized
Dentry cache hash table entries: 32768 (order: 4, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)
Mount-cache hash table entries: 1024
ACPI: Core revision 20080609
Boot processor id 0x0/0x0
Brought up 1 CPUs
Total of 1 processors activated (2211.84 BogoMIPS).
CPU0 attaching sched-domain:
 domain 0: span 0 level NODE
  groups: 0
net_namespace: 1456 bytes
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOSAPIC