Did you try the latest code from CVS ? We no longer call smp_send_stop() as
part of dump now ...
But we've faced other problems with dumping from interrupt context, which
could be encountered Alt-SysRq-c trigger, depending on the dump device
type, or rather the driver involved. What device are you dumping to ?
I did hack things a little to work around some of the problems to get
Alt+SysRq+c dumping working in our test setup, but its probably not quite
the right way to do this. In the long run - a dump device interface or
second kernel soft boot approach in its absence for panic style dumps and
maybe the deferred dump option for non-disruptive dumps are possibilities
being looked at.
But then you do seem to be able to dump after making the changes you
mention)(After all you do seem to be able to dump after making the changes
IBM Software Lab, India
E-mail : bsuparna@xxxxxxxxxx
Phone : 91-80-5267117, Extn : 3961
"Tony Dziedzic" <Tony.Dziedzic@xxxxxxxxxxxx> on 10/10/2001 06:20:44 PM
Please respond to "Tony Dziedzic" <Tony.Dziedzic@xxxxxxxxxxxx>
cc: (bcc: Suparna Bhattacharya/India/IBM)
Subject: LKCD problems on SMP configurations?
I've integrated the latest LKCD code from SourceForge into our 2.4.4
kernel sources and have noticed that dumping on SMP systems isn't very
reliable. The test that I've been using is the Alt-SysRq-C magic key
sequence to generate a "sysrq" panic. The symptom that I see is that
the system hangs after printing the "Writing dump header ..." message.
Is anyone aware of pending issues on SMP systems?
I've found that if I comment out the __cli(); disable_local_APIC();
__sti(); sequence in smp_send_stop the hangs do not occur and I can
reproducibly generate a crash dump. Does this ring any bells?
FWIW, the system that I'm testing on uses a Tyan S2510 motherboard (dual
Storigen Systems, Inc.