headers
Lady Martha Stirling | 2 Nov 2007 03:58

Respond Asap!!!!!!!!!!

Am  Lady Martha Stirling, suffering from cancerous ailment.
I am a widow my  husband Sir Dennis Stirling an Englishman
who is dead. My  husband was into private practice all his life
before his death. My husband and I made a vow to uplift the
down-trodden and the less-privileged  individuals as he had
passion for people who can not help  themselves due to physical
disability or financial predicament. I can adduce this to the fact
that he needed a Child from this relationship, which never came.
When my late husband was alive he deposited the sum of 20 Million
(twenty Million Great Britain Pounds Sterling ) which were derived
from his vast estates and investment in capital market  with his
bank here in UK. Presently, this money is still with the  Bank.
Recently, my Doctor told me that I have limited days to live
due to the cancerous problems I am suffering from. I have decided
to donate this fund to you and   I took this decision because I do
not have any child that will inherit this  money. please assure me
that  you will act just as I have stated herein. Hope to hear from
you thanks. contact my private

email address:thestirling_nastydy01@...
Permalink | Reply | 0 comments |
headers
Lady Martha Stirling | 2 Nov 2007 02:58

Respond Asap!!!!!!!!!!

Am  Lady Martha Stirling, suffering from cancerous ailment.
I am a widow my  husband Sir Dennis Stirling an Englishman
who is dead. My  husband was into private practice all his life
before his death. My husband and I made a vow to uplift the
down-trodden and the less-privileged  individuals as he had
passion for people who can not help  themselves due to physical
disability or financial predicament. I can adduce this to the fact
that he needed a Child from this relationship, which never came.
When my late husband was alive he deposited the sum of 20 Million
(twenty Million Great Britain Pounds Sterling ) which were derived
from his vast estates and investment in capital market  with his
bank here in UK. Presently, this money is still with the  Bank.
Recently, my Doctor told me that I have limited days to live
due to the cancerous problems I am suffering from. I have decided
to donate this fund to you and   I took this decision because I do
not have any child that will inherit this  money. please assure me
that  you will act just as I have stated herein. Hope to hear from
you thanks. contact my private

email address:thestirling_nastydy01@...
Permalink | Reply | 0 comments |
headers
Ken'ichi Ohmichi | 2 Nov 2007 11:35
Picon
Picon

makedumpfile-1.2.2: Fix the problem that vmcoreinfo cannot be extracted from ELF32 /proc/vmcore


Hi,

makedumpfile version 1.2.2 is released.
Please test it. Your opinions/comments are welcome.

Explanation of makedumpfile:
  To shorten the size of the dumpfile and the time of creating the
  dumpfile, makedumpfile copies only the necessary pages for analysis
  to the dumpfile from /proc/vmcore. You can specify the kind of
  unnecessary pages with dump_level. If you want to shorten the size
  further, enable the compression of the page data.

Changelog:
o Fix the problem that vmcoreinfo cannot be extracted from ELF32 /proc/vmcore.
  There was a problem that makedumpfile cannot extract vmcoreinfo from
  an ELF32 /proc/vmcore:
    # makedumpfile -cd31 /proc/vmcore dumpfile
    get_pt_note_info: Can't find PT_NOTE Phdr.

    makedumpfile Failed.
    #
  The cause was that makedumpfile checked the address of flag_elf64 instead of
  the value.

Download:
  You can download the latest makedumpfile(ver. 1.2.2) from the following URL.
  Details of the change are written on the CVS page of the following site.
  https://sourceforge.net/projects/makedumpfile/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Horman | 7 Nov 2007 15:00
Picon
Favicon

Timer interrupt lost on some x86_64 systems

Hey all-
	I've been getting reports of some x86_64 systems that, on kdump kernel
boot get stuck in calibrate_delay(),  in both RHEL kernels and upstream kernels.
The current thinking is that the lapic timer interrupt is no longer getting
delivered, likely because we handle a crash condition on a cpu that isn't the
boot cpu.  One known offender is this motherboard:
http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QM8-2.cfm
My current thought is that the TIMER_LVT entry is masked on all but the boot cpu
on this system (which is strange, as I was under the impression that the timer
interrupt was supposed to be enabled on all CPU's nominally.  At any rate, I was
going to try to read/write the TIMER_LVT on the crashing processor before we
jump to purgatory, or in purgatory itself, to see if that fixes the problem, but
I wanted to report the issue here to see if anyone had any alternate thoughts.
I know that intel ioapics had a timer related problem recently that caused the
same issue, but the fix doesn't seem to help in this case.

Thanks & Regards
Neil

--

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman@...
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/
Permalink | Reply | 9 comments |
headers
Online coordinator | 8 Nov 2007 07:27
Picon

Congratulations! Your E-mail Address Won In Our Sweepstakes.


We happily announce to you the Draw (#679) of the UK NATIONAL LOTTERY 
held on the 7th November,2007.Your E-mail Address  attached to Ticket
No.:03,10,21,25,29,49 Bonus No.20, Agent ID Number:110 won you a total 
sum of £1,750,000.00 POUNDS STERLING.
Contact Mr. Anthony Flowers
Claims and Release Order Department,
Email:Email:claimsgntt1 <at> yahoo.co.uk
LONDON, UNITED KINGDOM
Tel: +447024078607
For claims validation.
Yours Truly,
Angelina Ashton.
------------------
The Lucky Dip facility uses special software to generate numbers at 
random and the programs are tested to make sure they are. As each line 
is generated independently, thus on some occasions one, two, or even 
more numbers may be repeated on the same ticket.

_______________________________________________
kexec mailing list
kexec <at> lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Permalink | Reply | 0 comments |
headers
Akio Takebe | 9 Nov 2007 10:34
Favicon

[Patch] Fix PA() in purgatory-ia64.c

Hi,

I met the issue that kdump didn't work on Xen/HVM guest.
I investigated the cause, found that PA() in purgatory-ia64.c
is used in Physical mode.

The PA() currently use PAGE_OFFSET fixed size(0xe000000000000000UL).
So the PA() don't work properly if it is called in Physcal mode.

 inline unsigned long PA(unsigned long addr)
 {
        return addr - PAGE_OFFSET;
 }

I make the patch to fix this issue.
How about this?

Signed-off-by: Akio Takebe <takebe_akio@...>

Best Regards,

Akio Takebe

---
--- kexec-tools-testing-20071030.orig/purgatory/arch/ia64/purgatory-ia64.c	2007-10-17
12:16:16.000000000 +0900
+++ kexec-tools-testing-20071030/purgatory/arch/ia64/purgatory-ia64.c	2007-11-09
18:20:27.000000000 +0900
 <at>  <at>  -21,7 +21,7  <at>  <at> 
 #include <string.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vivek Goyal | 12 Nov 2007 05:49
Picon

Re: Timer interrupt lost on some x86_64 systems

On Wed, Nov 07, 2007 at 09:00:06AM -0500, Neil Horman wrote:
> Hey all-
> 	I've been getting reports of some x86_64 systems that, on kdump kernel
> boot get stuck in calibrate_delay(),  in both RHEL kernels and upstream kernels.
> The current thinking is that the lapic timer interrupt is no longer getting
> delivered, likely because we handle a crash condition on a cpu that isn't the
> boot cpu.  One known offender is this motherboard:
> http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QM8-2.cfm
> My current thought is that the TIMER_LVT entry is masked on all but the boot cpu
> on this system (which is strange, as I was under the impression that the timer
> interrupt was supposed to be enabled on all CPU's nominally.

I also thought that LAPIC timer interrupts are enabled on all cpus.

>  At any rate, I was
> going to try to read/write the TIMER_LVT on the crashing processor before we
> jump to purgatory, or in purgatory itself, to see if that fixes the problem, but

I think calibrate_dealy() depends on external timer interrupt coming and
not the local APIC timer interrupt. Generally it is 8254 timer chip. Now a
days motherboards seems to be having HPET and I know somebody has reported
problems with HPET where HPET interrupts are not coming in second kernel and
system hangs in second kernel. I suspect  that same might be the issue here.

Thanks
Vivek
Permalink | Reply | 8 comments |
headers
Simon Horman | 12 Nov 2007 05:55
Picon
Gravatar

[patch] ia64: Guard elfcorehdr_addr with #if CONFIG_PROC_FS

Access to elfcorehdr_addr needs to be guarded by #if CONFIG_PROC_FS
as well as the existing #if guards.

Fixes the following build problem:

arch/ia64/hp/common/built-in.o: In function
`sba_init':arch/ia64/hp/common/sba_iommu.c:2043: undefined reference to `elfcorehdr_addr'
:arch/ia64/hp/common/sba_iommu.c:2043: undefined reference to `elfcorehdr_addr'

Signed-off-by: Simon Horman <horms <at> verge.net.au>

Index: net-2.6/arch/ia64/hp/common/sba_iommu.c
===================================================================
--- net-2.6.orig/arch/ia64/hp/common/sba_iommu.c	2007-11-12 12:49:23.000000000 +0900
+++ net-2.6/arch/ia64/hp/common/sba_iommu.c	2007-11-12 13:29:07.000000000 +0900
 <at>  <at>  -2034,7 +2034,8  <at>  <at>  sba_init(void)
 	if (!ia64_platform_is("hpzx1") && !ia64_platform_is("hpzx1_swiotlb"))
 		return 0;

-#if defined(CONFIG_IA64_GENERIC) && defined(CONFIG_CRASH_DUMP)
+#if defined(CONFIG_IA64_GENERIC) && defined(CONFIG_CRASH_DUMP) && \
+        defined(CONFIG_PROC_FS)
 	/* If we are booting a kdump kernel, the sba_iommu will
 	 * cause devices that were not shutdown properly to MCA
 	 * as soon as they are turned back on.  Our only option for
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Horman | 12 Nov 2007 16:17
Picon
Favicon

Re: Timer interrupt lost on some x86_64 systems

On Mon, Nov 12, 2007 at 10:19:03AM +0530, Vivek Goyal wrote:
> On Wed, Nov 07, 2007 at 09:00:06AM -0500, Neil Horman wrote:
> > Hey all-
> > 	I've been getting reports of some x86_64 systems that, on kdump kernel
> > boot get stuck in calibrate_delay(),  in both RHEL kernels and upstream kernels.
> > The current thinking is that the lapic timer interrupt is no longer getting
> > delivered, likely because we handle a crash condition on a cpu that isn't the
> > boot cpu.  One known offender is this motherboard:
> > http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QM8-2.cfm
> > My current thought is that the TIMER_LVT entry is masked on all but the boot cpu
> > on this system (which is strange, as I was under the impression that the timer
> > interrupt was supposed to be enabled on all CPU's nominally.
> 
> I also thought that LAPIC timer interrupts are enabled on all cpus.
> 
That doesn't appear to be the case.  The configuration I've seen is that only
one lapic has timer interrupts enabled, and the interrupt handler for the timer
interrupt broadcasts the interrupt to all the other processors via IPI

> >  At any rate, I was
> > going to try to read/write the TIMER_LVT on the crashing processor before we
> > jump to purgatory, or in purgatory itself, to see if that fixes the problem, but
> 
> I think calibrate_dealy() depends on external timer interrupt coming and
> not the local APIC timer interrupt. Generally it is 8254 timer chip. Now a
> days motherboards seems to be having HPET and I know somebody has reported
> problems with HPET where HPET interrupts are not coming in second kernel and
> system hangs in second kernel. I suspect  that same might be the issue here.
> 
Perhaps, do you have a pointer to any list discussions on the subject?  I've not
(Continue reading)

Permalink | Reply | 7 comments |
headers
Neil Horman | 12 Nov 2007 16:41
Picon
Favicon

Re: Timer interrupt lost on some x86_64 systems

On Mon, Nov 12, 2007 at 10:17:21AM -0500, Neil Horman wrote:
> On Mon, Nov 12, 2007 at 10:19:03AM +0530, Vivek Goyal wrote:
> > On Wed, Nov 07, 2007 at 09:00:06AM -0500, Neil Horman wrote:
> > > Hey all-
> > > 	I've been getting reports of some x86_64 systems that, on kdump kernel
> > > boot get stuck in calibrate_delay(),  in both RHEL kernels and upstream kernels.
> > > The current thinking is that the lapic timer interrupt is no longer getting
> > > delivered, likely because we handle a crash condition on a cpu that isn't the
> > > boot cpu.  One known offender is this motherboard:
> > > http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QM8-2.cfm
> > > My current thought is that the TIMER_LVT entry is masked on all but the boot cpu
> > > on this system (which is strange, as I was under the impression that the timer
> > > interrupt was supposed to be enabled on all CPU's nominally.
> > 
> > I also thought that LAPIC timer interrupts are enabled on all cpus.
> > 
> That doesn't appear to be the case.  The configuration I've seen is that only
> one lapic has timer interrupts enabled, and the interrupt handler for the timer
> interrupt broadcasts the interrupt to all the other processors via IPI
> 
> > >  At any rate, I was
> > > going to try to read/write the TIMER_LVT on the crashing processor before we
> > > jump to purgatory, or in purgatory itself, to see if that fixes the problem, but
> > 
> > I think calibrate_dealy() depends on external timer interrupt coming and
> > not the local APIC timer interrupt. Generally it is 8254 timer chip. Now a
> > days motherboards seems to be having HPET and I know somebody has reported
> > problems with HPET where HPET interrupts are not coming in second kernel and
> > system hangs in second kernel. I suspect  that same might be the issue here.
> >
(Continue reading)

Permalink | Reply | 5 comments |

Gmane