I have just started to set up my box. I have noticed that the kernel for the 686 is SMP enabled.
SMP causes my wireless card(rt2500 driver) to die instantly. I have noticed a few other things that do not work well with SMP enabled.

From my point of view 99.99% of knoppmyth installs are uniprocessor, and some low spec systems at that.

Is there a large user base that runs dual proc mythTV boxes?

noting the above low spec(I have a P3 933mhz coppermine) it take about forever to recompile the kernel.

For the developers, maybe consider having the default not be an SMP kernel. Having the option is for an SMP kernel is OK, but those who have SMP will know it and be on the look out for it.

thank you for your time and have a good day

actually newer PIV's are very common for newer hdtv systems, and hyperthreading uses smp support. Until very recently when someone else had problems with the rt2500 we haven't heard of anything that didn't work with smp. This really should be fixed in the kernel as smp is the future, there's already hyperthreading, and dual cores will be very common.

_________________
Have a question search the forum and have a look at the KnoppMythWiki.

Xsecrets

then why is the default a 586 kernel?

that's easy epia a very common box for frontends because of the low noise.

_________________
Have a question search the forum and have a look at the KnoppMythWiki.

Xsecrets

I am not sure I understand, I thought PIV hyperthreading cores were common and that is why SMP is default

The epia is not a hyper threading core.

I feel that the non-hyper threading cores are the lion share of the home built PVR's and that was my point. SMP isn't helping at all. For the majority it can only be a hinderance, some raid controllers have problems with SMP as well.

I think it would be helpful for the autoinstall script to have 3 choices, 586 - 686 - 686 SMP

Well here's the deal patching building and testing kernels takes time. to include three options would take three times longer, and most of us don't just have gobs of time to waste on stuff that is generally not important. Like I said until people started trying to use the ralink wireless drivers we never heard any problems from using an smp kernel. I still really see this as a problem the ralink developers need to fix as most desktop operating systems in the next couple of years will be smp and ralink is obviously not an htpc only driver.

_________________
Have a question search the forum and have a look at the KnoppMythWiki.

Xsecrets

First off, there is only one kernel and that is for 586 plus SMP and a few other goodies. I think you are only the second person to have issues with an SMP kernel. Guess what, I'm not going to recompile the kernel X number of times and include those kernels in order to solve everyone's little problems. The source is there and the config is there. Recompile or like Xsecret stated, ask the Ralink folks to produce a driver that is SMP safe. A script that asks what processor do you have isn't helpful either because guess what, some folks don't have a clue is there PIV is a 5 or 686. Does this PIV have HTT? Is so is it SMP? AAAHHHHH! Quick let me post on the forum instead of searching. Don't have a cow, simply stating the facts.

_________________
cesman

When the source is open, the possibilities are endless!

Not sure what the deal is, but I get
BUG: using smp_processor_id() in preemptible [00000001] code: lircd/
when trying to use IRsend...

Any suggestions? I am kinda a old newbie and recompiling the kernel sounds like a large task, I will give it a try if I have to.

Any other methods of shutting off the SMP stuff without recompiling?

-Joe