Re: ia64 2.4.17-mckinley-smp vm crash (SOLVED)

[rwp@hprwp.fc.hp.com (Bob Proulx)]

Hello Bdale!

Bdale Garbee <bdale@gag.com> [2003-01-05 22:18:45 -0700]:
> You really, really, want to move to the 2.4.19 kernels in Debian unstable. 
> They are exactly what I'm using for HP's installation and recovery media now,

I had tried an upgrade to testing but the problems with dash prevented
that being installable.

> My personal recommendation for a recipe is 3.0r1 plus 2.4.19 kernel from 
> unstable plus security updates.

Roger wilco.

I determined that the dependency on dash was actually 'dash | ash',
therefore while still with 'stable' I installed ash, cramfsprogs and
initrd-tools.  I already had modutils.  That covered all of the
dependencies for the new kernel so that I would need nothing else and
would not pull any other packages from unstable and therefore would
not pull a new glibc either and I can stick with the 'stable' bits as
much as possible.

I changed my sources.list to unstable for the install and then
returned back to stable immediately after that.  I installed the new
kernel, currently kernel-image-2.4.19-mckinley.  It installed pretty
well but had this one strange thing.

  [... lots of these Unresolved symbols ...]
  depmod: *** Unresolved symbols in /lib/modules/2.4.19-mckinley/kernel/net/netlink/netlink_dev.o
  There was a problem running depmod.  This may be benign, 
  (You may have versioned symbol names, for instance).
  Or this could be an error.
          depmod exited with return value 1
  In any case, since depmod is run at install time, 
  we could just defer running depmod
  Would you like to abort now? [Yes] no
  [...]
  Install a boot block using the existing /etc/elilo.conf? [Yes] 

I told it 'no', do not abort and continued the install.  Except for
that issue it installed fine.  I rebooted and everything came up fine
running the new kernel with no trouble.

The crashme-vm program I posted initially now runs without crashing
the machine.  I think this solves the problem.  An excellent result.

> and I'm hoping that for 3.0r2 they'll replace 2.4.17 as our default install
> kernel but that's still not certain to be accomplished.

Because a non-root process can crash the 2.4.17 kernel I strongly
second that.  Currently 'stable' is not stable with respect to this.
The appearance is of a flakey machine.  Initially we thought it was a
hardware problem.  Glad the problem is already solved in unstable.

Thanks!
Bob