Fail to boot smp kernel

[Antonio Ricardo Soares da Silva Correia]

Since Hoary through last version of Breezy smp kernels fail to boot on my
Pentium IV with hyperthreading. Every other versions of Linux (ie. Mandrake,
Debian, Knopix,etc) boot smp kernels without problem. The system freezes in X
grey screen before the KDE login and a hard reboot is needed.

[Matt Zimmerman (mdz)]

You have confirmed that the problem does not occur if you boot a uniprocessor
kernel without any other changes?

See also https://wiki.ubuntu.com/DebuggingSystemCrash, though this could in fact
be an X server issue rather than a kernel issue

[Antonio Ricardo Soares da Silva Correia (correia)]

I confirm I have no problems if I boot a single processor Kernel. It just happens with
the smp kernels. I've just tried it again and if there is a problem with X it seems to
come from the smp kernel. When I boot the single processor kernel it goes through the
blue kubuntu's screen with boot messages and I can see "Setting up X server socket
directory...ok".
When I boot with the smp kernel I have the same message but without the "ok". The problem
probably comes from that. I looked at the wiki you mentioned and everything is ok at bios
level, I've even put AGP in 1x mode but it always freezes. I'm willing to try anything
else like boot params or whatever you think of. Thanks for your time.

[Antonio Ricardo Soares da Silva Correia (correia)]

I have tried the new development version (Dapper Drake) and installed the smp
kernel. It did run without problems on the first reboot but frozed after a
terminal session on the following reboot. I think the kernel version stays the
same, the only difference being I had GDM instead of KDM as the session manager
because for the moment I was unable to install kubuntu-desktop.
So, Dapper Drake appart, the smp kernel does not work flawlessly as in other
distributions.

[Daniel Robitaille (robitaille)]

Antonio, Have you tried this with a more recent Dapper kernel?

[Antonio Ricardo Soares da Silva Correia (correia)]

Since Hoary till Breezy that I'm still using I've tried with every single
kernel up to the last one. I have Dapper installed on another partition for
some time but I couldn't find in the repositories the smp version of the
kernel.
My system is up to date and every time a new kernel pops up I try the new smp
version to see if it works but it still doesn't.
The machine still freezes in X (the gray screen before KDE's login screen
appears).
I don't remember if I mentioned I have a Pentium with hyperthreading.
Anyhow, it boots fine in smp mode both with Mandriva and a Knopix live CD so I
figure the problem is not the machine...
If you need me to try again and if there is a log file I can send you back to
help track the problem I'll do it willingly.

Best regards,
Antonio

Le Vendredi 14 Avril 2006 10:24, Daniel Robitaille a écrit :
> Antonio, Have you tried this with a more recent Dapper kernel?
>
>
> ** Changed in: Ubuntu
> Sourcepackagename: None => linux-source-2.6.15

[Barry deFreese (bddebian)]

I hate to ask this but are you sure this isn't a hardware issue? Have you tried kernels from any other distros or maybe even run another OS that you know detects it as smp? I know some of the early HT Pentiums have issues. Thanks for your report.

[Antonio Ricardo Soares da Silva Correia (correia)]

Yes, I tried several distros. It works fine with Mandriva, Knopix (live CD)
and even with a Debian. I only have this problem with Ubuntu/Kubuntu so I
think it's not a hardware issue.

Best regards,
Antonio

> I hate to ask this but are you sure this isn't a hardware issue? Have
> you tried kernels from any other distros or maybe even run another OS
> that you know detects it as smp? I know some of the early HT Pentiums
> have issues. Thanks for your report.
>
> ** Changed in: linux-source-2.6.15 (Ubuntu)
> Status: Unconfirmed => Needs Info

[Richard Green (rtg-aapsc)]

Just encountered this same condition.
System is a dual-Pentium system:
rtg@jot:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 548.752
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 1097.70

I installed Breezy, then used Adept to install the 686 SMP kernel package. System hung upon reboot at the grey X screen before the KDM login window appeared. System was completely unresponsive - I could not switch to a text console, could not kill the X server, could not force reboot with ctrl-alt-del. Powered down.

Rebooted with Dapper beta 2 CD. Installed. (two glitches with install - I'll file them separately) Used Adept to install 686 SMP kernel package, Reboot. (hung on shutdown, had to use hardware reset). On reboot w/686 kernel, system hung as X starting (blue screen this time) just before KDM window appears. System also totally unresponsive. Hard reset, selected 386 kernel in grub menu, system starts normally.

[Richard Green (rtg-aapsc)]

Just reconfirmed this with linux-image-2.6.15-22-686, right after running a dist-upgrade.

The system totally freezes as kdm is starting. This time, the screen background was black, with just an unmovable arrow cursor in the middle.
  I tried rebooting in recovery mode, and it gave me a root console. /proc/cpuinfo tells me that both CPUs were detected. When I exited the root shell, it proceeded with the runlevel 2 init, and the last message I saw flashing by the screen was 'starting kdm...' just before the screen went blank and the system became unresponsive.

  I rebooted with linux-image-2.6.15-22-386, and all is well, but running on one processor only.

[Ben Collins (ben-collins)]

We're going to need some sort of trace or crash message in order to debug this.

I'm not sure how to can get X to start while staying in the console to see any kernel messages. Have you checked /var/log/kern.log to see if anything is captured there?

Have you tried booting the SMP kernel with nosmp boot option?

[Richard Green (rtg-aapsc)]

> I'm not sure how to can get X to start while staying in the console to
> see any kernel messages.
   I don't know either. On my previous system (SuSE), I had available a
runlevel 3with a text console, and I could start X explicitly after I had
logged in. I haven't found a similar config in Kubuntu. I was wondering
about uninstalling kdm. Would that let me boot to a tty login prompt, so
that I could login, then start X? That might help determine if it's kdm
or X itself that's tripping up the kernel... ...or would that just break
the system?

> Have you checked /var/log/kern.log to see if
> anything is captured there?
   I checked that. The last 20 messages or so were exactly the same, both
when pooting the 686 kernel and crashing, and the 386 kernel successfully.
>
> Have you tried booting the SMP kernel with nosmp boot option?
   I did try that as well. Very strange results! WHen I add the 'nosmp'
option and boot, the boot seems to take forever, I get a plethora of
spurious 'lost interrupt' messages, finally culminating with a message to
the effect of 'hda1 does not exist' and it drops me into a busybox shell.
My hard disk isn't mounted, but I was able to `cat /proc/cpuinfo' and
verify that it was indeed running in uniprocessor mode. Since I couldn't
mount the root pertition, I made no attempt to start X (startx isn't one
of busybox's builtin commands!)

[Richard Green (rtg-aapsc)]

OK, I managed to create a text-login runlevel. It really wasn't that difficult, just edited /etc/inittab to change the default runlevel to 3, and then using kde's system settings/system services tool, I disabled kdm in runlevel 3.
  So the 686 kernel boots on my system to a text console just fine.
  I executed the 'startx' comand, and for a while, I thought it just might work. Kde started up, and I actually got as far as setting up the desktop, and it began to launch applications to restore my session.
  The first clue came when my Konsole window opened with just one tab, not the four I had when I logged out. Sure enough, the system was locked up solid. keyboard, mouse were unresponsive. System didn't respond to ping or ssh login attempt from a neighbor system.

What can I do to enable more verbose kernel logging, and make sure it gets written right up to the point of failure?

[Richard Green (rtg-aapsc)]

I did another full update, which picked up kernel 2.6.15-23-686, so I tried it again.
  Got a bit further. I booted initially to a console prompt, where I only ran 'cat /proc/cpuinfo' to verify that I was indeed running an SMP kernel (output attached). Then I issued the 'startx' command.
This time, I got all the way thru the KDE initialization. I saw the 'KDE is up and running' message just before the central info window disappeared. Konqueror had even loaded this web page, as evidenced by the button-label on the toolbar, but when I went to move the cursor to select that desktop, I found that the system was indeed frozen solid.
  Is there a way I can turn on some kind of strace or kernel debugging just before I issue the startx command, with its output directed to a serial port where I can capture it on a more stable system?

[Richard Green (rtg-aapsc)]

Output of 'cat /proc/cpuinfo' on the system which fails to run X with the 686 SMP kernel.

[Richard Green (rtg-aapsc)]

Verified again with kernel 2.6.15-25-686

[Richard Green (rtg-aapsc)]

I stumbled on a few blog posts, writing about a fix for Ubuntu Bug #36596 and #38802, (note: the fixes here may also apply to bug #16873, #38181 and #47775).
  My system also is equipped with a Radeon 7000/VE, so I'm curious that this bug, too, may be another manifestation of this same problem. When the patches have been incorporated into the Ubuntu sources, I would be happy to upgrade and test, in the hopes of squashing this one, too!
  (Source patch is from cipherfunk.org, where there are also patches for xorg driver and others as well, but the author is threatening to take the site down soon.)

[Richard Green (rtg-aapsc)]

Verified - The problem still occurs with kernel 2.6.15-26-686.

I booted into a text console, then issued the startx command. the system froze up as it got to the 'restoring session' phase of KDE initialization.

[Richard Green (rtg-aapsc)]

I found an old Matrox Millenium PCI video card, and swapped it into this machine.

lspci reports it as:
VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 01)

With it, I've been able to boot the 686SMP kernel, and startx with KDE. It's been running all of ten minutes now, but that's ten minutes more than I ever got with the ATI card(AGP).
  ...so it's looking more and more like this is really a manifestation of the 686/ATI 'random lockup' problem that the fellow at cipherfunk claims to have fixed. I posted his kernel patch here earlier. Here is his patch for the xorg driver.

[Richard Green (rtg-aapsc)]

Another data point: The system seems to be stable with the 686SMP kernel with an ATI rage pro PCI video card installed:
VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c)

Now, the question seems to be whether the bug is specific to the Radeon 7000 chipset, or possibly something with the AGP implementation? I'll see if I can dig up some other AGP video cards...

[Richard Green (rtg-aapsc)]

System booted and appears stable with X and KDE running. Current video card is:
 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15)
 So it isn't the AGP bus per se. Unfortunatly, I don't have a PCI version of the Radeon 7000 card available, to see if the bug is in the chipset code, or the bus logic...

[Richard Green (rtg-aapsc)]

OK, here's the last video card in my drawer:
 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)
It's an AGP card, and the system appears stable running X and KDE.

So here's the bottom line: kernel 2.6.15-26-686, and at least four earlier 686 kernels, lock up solid during KDE initialization on my dual-pIII system, Only when equipped with a Radeon 7000/VE AGP video card.

Next, I may try running this combination on a single-processor system, but I'll leave that for another day.

[Antonio Ricardo Soares da Silva Correia (correia)]

Richard, perhaps you are right in what concerns the ATI 7000 but that doesn't explain why my system works flawlessly with the other distributions and only fails with (K)Ubuntu. Oddly enough, now, even the plain 686 kernels don´t work in my machine. I´ve tried all since I installed Dapper and they freeze in X like the SMP ones. I wonder if they have merged 686 and 686_SMP kernels because I had one running for about 2 minutes before freezing and gkrellm indicated 2 processors what it only does with the SMP version of the kernel.
 So as you might guess, since Dapper was released I'm forced to use the 386 kernels and keep wondering why this just happens with (K)Ubuntu and not with the other dists. What are they doing wrong?

[Richard Green (rtg-aapsc)]

On Wed, 20 Sep 2006, Antonio Ricardo Soares da Silva Correia wrote:

> Richard, perhaps you are right in what concerns the ATI 7000 but that
> doesn't explain why my system works flawlessly with the other
> distributions and only fails with (K)Ubuntu. Oddly enough, now, even the
> plain 686 kernels don´t work in my machine. I´ve tried all since I
> installed Dapper and they freeze in X like the SMP ones. I wonder if
> they have merged 686 and 686_SMP kernels because I had one running for
> about 2 minutes before freezing and gkrellm indicated 2 processors what
> it only does with the SMP version of the kernel. So as you might guess,
> since Dapper was released I'm forced to use the 386 kernels and keep
> wondering why this just happens with (K)Ubuntu and not with the other
> dists. What are they doing wrong?
>
>
Yes, I, too, am able to run the SMP kernels from other distros. But as I
demonstrated, it's clearly an interaction between the X server,
specifically the ATI driver, and the kernel. Possibly those other distros
are still using XFree86, and haven't made the switch to xorg?
   Would you do a little testing? Perform the checks that I described
earlier:

1) run `lspci`, and post the result line that describes your video card.
2) Reboot the system with the 686 kernel, to a console prompt, as I
described earlier:
a) go to 'system settings/system services', and turn off kdm in runlevel 3.
b) edit /etc/inittab and change the initital default runlevel from 5 to 3
c) reboot, selecting the 686 kernel from the grub menu
d) Login, and play around enough to satisfy yourself that the kernel alone
is stable.
e) Issue the command `startx` and report the results.

It might also be informative if a Gnome user with a 686SMP/Radeon7000
system would chime in with their experiences...

[Antonio Ricardo Soares da Silva Correia (correia)]

Hi Richard,

I did the tests you asked and here are the results:

correia@kubox:~$ lspci
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]

I did the modifications you suggested and the 686 kernel runs ok in console mode (it already did before without modifying anything).

Starting X it went ok through the login screen to my normal kdm session, gkrellm displayed 2 processors confirming my suspiction that under the label 686 kernel it´s the SMP one that´s being installed and then the system froze as usual...

I can confirm that the system also freezes with GDM (I have both installed and can choose at login time what kind of session I want, Gnome or KDE).

I wish they would put back the 686 kernel without SMP extensions until they solve the problem because at least I would be able to run a 686 kernel as I did before with Breezy.

In what regards the other distros I´m pretty sure both Debian and Mandrake (or Mandriva) are using Xorg, I´m not sure about Knopix.

[Ben Collins (ben-collins)]

If you just want to run a non-SMP kernel, "sudo apt-get install linux-386" will do the trick for you.

[Richard Green (rtg-aapsc)]

That's not the issue. the 386 kernel is the default, and is what I've been
running. The desire for a 686 non-SMP kernel is to determine if the
problem is with the 686 optimizations or the SMP code.
   WHat I really want is for someone with knowledge of the kernel internals
to look at Paul's patches and see if they're appropriate to apply to the
current 686smp kernel source. I'm not a C programmer, and I haven't even
configured and compiled a kernel since it went modular, so I don't trust
my own opinion on the subject...

--
Rick Green

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
                                   -Benjamin Franklin

[Ben Collins (ben-collins)]

On Wed, 2006-09-20 at 23:13 +0000, Richard Green wrote:
> That's not the issue. the 386 kernel is the default, and is what I've been
> running. The desire for a 686 non-SMP kernel is to determine if the
> problem is with the 686 optimizations or the SMP code.
> WHat I really want is for someone with knowledge of the kernel internals
> to look at Paul's patches and see if they're appropriate to apply to the
> current 686smp kernel source. I'm not a C programmer, and I haven't even
> configured and compiled a kernel since it went modular, so I don't trust
> my own opinion on the subject...

How about booting the 686 kernel with the nosmp on the boot command
line?

As for the patch, it's _way_ too invasive to even consider for dapper.

If you want, you can try the Edgy Knot-3 LiveCD to see if it fixes your
problem.

[Richard Green (rtg-aapsc)]

On Thu, 21 Sep 2006, Ben Collins wrote:

> How about booting the 686 kernel with the nosmp on the boot command
> line?
   That was suggested earlier, and I reported that it threw all kind of
wierd missing interrupt errors, finally giving up on mounting the disk,
and dropped me into busybox.
>
> As for the patch, it's _way_ too invasive to even consider for dapper.
  What do you mean by 'invasive'? Affects too many areas of the kernel?
Too much of a bear to test?
>
> If you want, you can try the Edgy Knot-3 LiveCD to see if it fixes your
> problem.
  DOes that include an SMP kernel? All the *buntu distros I've used before
do no CPU hardware detection, and just install the default 386 kernel.
How would a 'live' CD anyway detect the PIII and switch to the 686SMP
kernel mid-boot?

--
Rick Green

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
                                   -Benjamin Franklin

[Richard Green (rtg-aapsc)]

I was also looking at the discussion on bug # 16873, which appears to be the same problem, but they are looking at the radeon driver side rather than the kernel, and they appear to have a patch that's looking promising, but it's edgy only at this point. But a 'stable release' (does that mean dapper?) will probably be made soon.
  Now this brings up a more basic question: Does the Radeon driver run as a kernel module, so when it crashes, it takes the kernel with it, or does it run in userspace? I ask the question because if it is the latter, then fixing the driver would only be a circumvention, not a fix for the kernel lockups, right? In that case, we should keep the broken radeon driver around, and make sure the appropriate hardware gets to a kernel developer who can use it to discover the underlying kernel bug.

[Ben Collins (ben-collins)]

> > If you want, you can try the Edgy Knot-3 LiveCD to see if it fixes your
> > problem.
> DOes that include an SMP kernel? All the *buntu distros I've used before
> do no CPU hardware detection, and just install the default 386 kernel.
> How would a 'live' CD anyway detect the PIII and switch to the 686SMP
> kernel mid-boot?

I think you are misunderstanding what our "SMP" kernel is. It's an
SMP-alt kernel, meaning when you boot it on a non-SMP system, it
switches it's internal code (at boot) to more UP like functions).

That's the reason we did away with the 686-smp/686 setup. It wasn't
needed anymore.

That said, we now have a -generic kernel in edgy which is SMP enabled,
and can be used on k7/686. This kernel is on our livecd for edgy, so
yes, it will be SMP from this CD.

[Antonio Ricardo Soares da Silva Correia (correia)]

Ben,

what I want is to be able to run the 686 SMP kernel like I manage to do in other dists and, while this issue is not solved, to be at least able to run the 686 non SMP kernel as I used to with Hoary and Breezy. Not only this hasn´t been solved since Hoary but now I even don´t have the possibility to run a 686 kernel because it was widrawn from the repositories and replaced with the SMP version (though not described as so) and that one never worked with my computer.
I´m using the 386 kernel because I have no other choice but I feel like having a Ferrari with a Fiat 500 engine...

[Antonio Ricardo Soares da Silva Correia (correia)]

Richard,

Though I have some knowledge of C it´s not that deep so I can´t comment on Paul´s patches.
I know 386 is the default kernel in many distributions but I´ve got used to using the 686 because my first dist, years ago, was Mandrake and on install it detected the kind of processor and installed by default 686/SMP as the default kernel for my machine.
Both the 686 and 686/SMP kernels provide better performance for a Pentium 4 (or better machine) otherwise it would make no sense having them.
The 386 kernel should work also with an Atlon 64 that is backwards compatible with Intel x86 code but it won´t take full profit of the processor and that´s why there is a kernel version for it (and other AMD processors as a matter of fact).
So my point is I want to be able to use my machine to the full extent of the speed and other possibilities of it´s hardware and not be limited to the bare bones 386 kernel that ignores the most of the microcode in my processor.
Appart from 3rd world countries I don´t suppose there are many of us around still using a 386 or even a 486 and that would need the that version of the kernel.

[Antonio Ricardo Soares da Silva Correia (correia)]

Ben,

I will try the nosmp option on boot to see if at least I can run the 686 kernel.
I´ll let you know if it works.

[Ben Collins (ben-collins)]

On Thu, 2006-09-21 at 11:25 +0000, Antonio Ricardo Soares da Silva
Correia wrote:
> Ben,
>
> what I want is to be able to run the 686 SMP kernel like I manage to do in other dists and, while this issue is not solved, to be at least able to run the 686 non SMP kernel as I used to with Hoary and Breezy. Not only this hasn´t been solved since Hoary but now I even don´t have the possibility to run a 686 kernel because it was widrawn from the repositories and replaced with the SMP version (though not described as so) and that one never worked with my computer.
> I´m using the 386 kernel because I have no other choice but I feel like having a Ferrari with a Fiat 500 engine...

Believe me when I tell you that the performance gain of using a -686
kernel (non-SMP) over the -386 kernel is less than 1%. There is not
enough to even worry about the benefit.

So continue use the -386 kernel, with the comfort that it isn't
degrading your performance as much as you think :)

The whole reason we went with -generic, -386 kernels in Edgy is because
the -686 and -k7 Alt-SMP kernels there didn't improve performance enough
over the -generic version to warrant them either.

[Antonio Ricardo Soares da Silva Correia (correia)]

Ben,

Thanks for your info on kernel performance. Still, it just behaves as a 386 running at 3Ghz. What about other issues like special instructions and the larger quantities of memory handling available in modern processors.
My old 386 system had a 80 Mb hard drive, my current system has a lot more than that as RAM...
Futhermore, I have seen several "experts" say that even with a single processor like the Pentium 4 with hyperthreading, enabling SMP can bring benefits at the performance level and optimization of process handling.
I can remember at least one application (I suppose it was something regarding SETI) that detected 2 processors under SMP and that gave me the option of using 1 or both and if I´m not wrong K3B can also take profit of that.

Don´t you think that, performance issues apart, the 686 kernel, SMP or not, should work fine like in other distributions?
After all, it´s not necessary to re-invent the wheel. If they manage to make it work why can´t we in our favorite distribution?

In what regards your suggestion I´ve tried to boot the 686 kernel with the nosmp option. It doesn´t work, the system freezes right at the begining.

Mounting essential modules ok
Mounting root file system

and nothing...

The hard drive blinks for a few seconds and everything comes to a halt.

[Antonio Ricardo Soares da Silva Correia (correia)]

Em Quarta, 31 de Maio de 2006 04:00, o Richard Green escreveu:
> I did another full update, which picked up kernel 2.6.15-23-686, so I tried
> it again. Got a bit further. I booted initially to a console prompt, where
> I only ran 'cat /proc/cpuinfo' to verify that I was indeed running an SMP
> kernel (output attached). Then I issued the 'startx' command. This time, I
> got all the way thru the KDE initialization. I saw the 'KDE is up and
> running' message just before the central info window disappeared.
> Konqueror had even loaded this web page, as evidenced by the button-label
> on the toolbar, but when I went to move the cursor to select that desktop,
> I found that the system was indeed frozen solid. Is there a way I can turn
> on some kind of strace or kernel debugging just before I issue the startx
> command, with its output directed to a serial port where I can capture it
> on a more stable system?
>
> ** Attachment added: "CPUINFO"
> http://librarian.launchpad.net/3004227/cpuinfo.txt

Richard,

While looking around for improved Radeon 7000 performance increase I accidentaly found the solution for our problem.
Begin by visiting this forum and read the 1st message.

http://ubuntuforums.org/showthread.php?t=221672

Follow the instructions but pay attention for a little detail I've found out that is very important:

Install the 686 kernel including the restricted image but don't boot it yet.
When you follow the instructions and you must execute sudo ./install.sh do it twice, one for the 386 kernel (just press enter for every question) and the second time when you run it for the 686 kernel just provide the path /lib/your_686_kernel this turn.

You will have the DRI Radeon module installed for both kernels. This will be the 386 version of the module in both cases. Why? Because if you install the kernel headers and linux-headers-686 the resulting 686 version of the module will freeze the system as usual...
Weird but true.

In my case the speed problem didn't get fixed (see my message in the same forum if you wish) but at least the DRI Radeon driver doesn't freeze the system and I have CPU0 and CPU1 write where they should be in Gkrellm.
As for stability I'm writing this on kmail with 686smp running while I was never able to open any app under smp before.

Let me know if it worked for you. In fact if it works for everybody it's one of those things that should be in a knowledge database somewhere so this info doesn't get lost as time goes by.

Best regards,
Correia

[Kyle M Weller (kylew)]

I can reconfirm this issue with all latest kernels, here is my bug report:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/138440

[Henrik Nilsen Omma (henrik)]

At this point, we'll only fix this in Gutsy.

[Leann Ogasawara (leannogasawara)]

Antonio, can you confirm this issue in Gutsy? Also, the Hardy Alpha series is out as well so it would be good to know if the issue exists there as well. Thanks.

[arcorreia (kubadmin)]

Hi Leann,

I'm using Kubuntu 7.04 with the generic kernel and it correctly handles SMP so It's impossible for me to confirm if the problem still exists in Gutsy. Sorry.

[Leann Ogasawara (leannogasawara)]

Thanks for the feedback Antonio. I'm going to close this report for now due to your last comment. Also, just in case you're interested, the Hardy Heron Alpha series which was recently released contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ . Thanks.

[Richard Green (rtg-aapsc)]

I had also reported and confirmed this bug earlier. This weekend, I built
up a test system (Dual PIII-550 w/ Radeon 7000 video) I booted it with a
Hardy Alpha 4 server(already on HDD), then used aptitude to install
kubuntu-desktop. I was able to startx, and the KDE desktop came up fine.
I then launched adept, intending to install the 686 SMP kernel to test
whether the bug was still there or not, and discovered that hardy doesnt
have a 686 kernel! In fact, you've taken the 'generic' concept quite far,
and are using one kernel for x86 and x86_64, UP and SMP alike.
   I ran uname -a, and found 2.6.24-7-server, and ran lshw and found both
CPUs detected.
   So I guess the bottom line is this bug has been squashed in Hardy.

  Thank you!

[Leann Ogasawara (leannogasawara)]

Hi Richard,

Thanks for testing the Hardy Alpha release and providing an update. I'm marking this report as "Fix Released" against Hardy per you last comment. Thanks.