Kernel Panic using any AMD64 SMP kernel /w Athlon64 X2

Created an attachment (id=3165)
SMP kernel panic

I have this problem with Ubuntu 5.10. I am using a DFI nf4-dagf with a Athlon 64
X2 3800+ and Maxtor MaXLine III 300GB SATA drive (seems relevent since it won't
sync). Everything works fine with the default AMD64 kernel. When I apt-get
install kernel-amd64-k8-smp, it will not boot. It gives me the same errors as
mentioned above.

I have the same problem

K8T Master2-FAR
2 x Opteron 242

I am experiencing the same problem in a dual Opteron 240 (64) machine with
Ubuntu Breezy 5.10.
The SMP kernel just don't work and begins an eternal error messages loop when
loading.
I am stuck with only one processor now, in the generic kernel... please someone
fix SMP.

I am seeing similar behavior, though I can avoid it by moving aside my
/etc/modules prior to boot. Can anyone else reproduce this?

I'm now unable to reproduce the "fix" I mentioned.

While the -k8-smp kernel is problematic, the -k8 kernel works just fine.

Ben, is it possible the amd64 smp patches in linux-patch-ubuntu-2.6.12 are doing
this? I could remove those bits of the patch myself, but I don't know how this
will affect long term stability.

I'm also experiencing the same problem on a dual processor Sun v20z.
For me, disabling the bootup splash screen solved the problems. (I've removed
'splash' from 'nonaltoptions' in /boot/grub/menu.lst and ran update-grub.)

So IMHO vga16fb is the problem, or at least that's what seems to trigger the
problem.

Created an attachment (id=4962)
Oops backtrace excerpts

Caught on a Sun v20z with 2.6.12-9-amd64-k8-smp 2.6.12-9.23.

I can reproduce these anytime. The oops messages seem to loop forever on the
console, and each of them seems to be slightly different. These are just two
examples.

I tried the /etc/modules fix but it didn't work very well in my dual opteron.
Today I tried modifying bios option MultiProcessor Specification Revision Level
from 1.4 downto 1.1. I think it's solved to me. I am still testing here, can
anyone reproduce this?

Sorry, It happened to break again when rebooting... So probably this is not the
problem.
But worked again when I rebooted another time! :|
I don't understand what is going on. It's just casual...?

Still not working well...

(In reply to comment #9)
> I tried the /etc/modules fix but it didn't work very well in my dual opteron.
> Today I tried modifying bios option MultiProcessor Specification Revision Level
> from 1.4 downto 1.1. I think it's solved to me. I am still testing here, can
> anyone reproduce this?

I removed the SMP/AMD64 bits from Ubuntu's patch-2.6.12-9.23 (in
linux-patches/amd64/2.6.12/debian/patch-2.6.12-9.23.bz2 provided by
linux-patch-ubuntu-2.6.12), built my own kernel package from this, and all is
well. I've rebooted the machine several times now.

Felix, I experienced the same behavior with the /etc/modules modification where
it worked at first, then no longer.

Ben, can you please consider removing your AMD64 SMP modifications to the kernel?

Created an attachment (id=5108)
Patch to Ubuntu's patch.

I know its a bit lame, patching a patch, but it gives you the basic idea.

I tried the patch, but it did not work and the kernel gave the identical error message as before.

I tried two different configurations :
- the kernel configuration from 2.6.12-9-amd64-k8 configuration with the options, Symmetric multi-processing support and
K8 NUMA support enabled
- the configuration from the 2.6.12-9-amd64-k8-smp package

Both were compiled with gcc-3.4

I also tried a similar patch and configuration for the 2.6.12-10 kernel. It also did not work.

System :
MSI K8T Master-2 FAR
2 x Opteron 242

If possible, please upgrade to Dapper's 2.6.15-7 kernel. If you do not want to
upgrade to Dapper, then you can also wait for the Dapper Flight 2 CD's, which
are due out within the next few days.

Let me know if this bug still exists with this kernel.

Ben, thanks for your response. Do you mean 2.6.15.5 instead of 2.6.15-7?
http://archive.ubuntu.com/ubuntu/pool/main/l/linux-meta/linux-image-amd64-k8-smp_2.6.15.5_amd64.deb

Also, does this mean that there won't be a fix for Breezy?

Ronald, can you confirm that my patch really removed Ben's AMD64/SMP patch from
the final source? I'm questioning my ability to create a patch rather than your
ability to apply one. :) Basically, before you build your kernel, there should
be no smp_call_function_single in

  linux-source-2.6.12-2.6.12.orig/arch/x86_64/kernel/smp.c
  linux-source-2.6.12-2.6.12.orig/arch/x86_64/kernel/smpboot.c
  linux-source-2.6.12-2.6.12.orig/include/asm-x86_64/smp.h

Note that I'm no kernel hacker; I just tried removing these bits because the
problem only manifested itself on AMD64/SMP.

*** Bug 25560 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> Ben, thanks for your response. Do you mean 2.6.15.5 instead of 2.6.15-7?
>
http://archive.ubuntu.com/ubuntu/pool/main/l/linux-meta/linux-image-amd64-k8-smp_2.6.15.5_amd64.deb

That's the meta package. The actual package is linux-image-2.6.15-8-amd64-k8-smp

> Also, does this mean that there won't be a fix for Breezy?

Unfortunately, it probably will not be.

(In reply to comment #17)
> The actual package is linux-image-2.6.15-8-amd64-k8-smp

Okay, thanks.

> > Also, does this mean that there won't be a fix for Breezy?
>
> Unfortunately, it probably will not be.

Darn. If possible then, please test Dapper's final k8-smp kernel on SMP hardware
before release. (all of our local hardware is running stable releases so we
can't test the betas)

(In reply to comment #18)
> Darn. If possible then, please test Dapper's final k8-smp kernel on SMP hardware
> before release. (all of our local hardware is running stable releases so we
> can't test the betas)

Any chance I could get you to test the flight2 liveCD?

http://cdimage.ubuntulinux.org/releases/dapper/flight-2/

(In reply to comment #19)
> Any chance I could get you to test the flight2 liveCD?
>
> http://cdimage.ubuntulinux.org/releases/dapper/flight-2/

Does the liveCD have a generic or k8-smp kernel? If generic, I'd have to use the
install CD and not the live, right?

(In reply to comment #20)
> (In reply to comment #19)
> > Any chance I could get you to test the flight2 liveCD?
> >
> > http://cdimage.ubuntulinux.org/releases/dapper/flight-2/
>
> Does the liveCD have a generic or k8-smp kernel? If generic, I'd have to use the
> install CD and not the live, right?

Correct. Sorry about that.

(In reply to comment #17)
> Unfortunately, it probably will not be.

What types of systems are affected by the bug, and what risks would be involved
in backporting the fix?

(In reply to comment #22)
> (In reply to comment #17)
> > Unfortunately, it probably will not be.
>
> What types of systems are affected by the bug, and what risks would be involved
> in backporting the fix?

The risk would have to be assessed after it's confirmed that it is indeed fixed :)

Ryan, I checked the ubuntu patches after your patch and the smp_call_function_single references were removed.

I installed Dapper Duck Flight-2 and the linux-AMD64-k8-smp meta package works, both processors are recognised.

The kernal that is used is vmlinuz-2.6.15-12-amd-k8. Is smp going mainstream? :)

On Sun, Jan 15, 2006 at 02:02:53PM -0000, Ronald Jones wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/18997
>
> Comment:
> Ryan, I checked the ubuntu patches after your patch and the
> smp_call_function_single references were removed.
>
>
> I installed Dapper Duck Flight-2 and the linux-AMD64-k8-smp meta package works, both processors are recognised.
>
> The kernal that is used is vmlinuz-2.6.15-12-amd-k8. Is smp going
> mainstream? :)

Thanks very much Ronald. Very glad to hear it!

Ryan