I am running an application that works fine on openSuse 11.3 and on 11.4 with the 2.6.39 kernel. But on 11.4 with the stock 2.6.37 kernel, it gives me an error.
This application creates threads with different priorities. When running pthread_setschedparam( ) it returns 1, which is EPERM (not permitted). I am logged in as root when this happens.
I’ve tried setting some of the values in /etc/security/limits.conf file, but it still didn’t work. I also didn’t understand why root would have limits on it.
I looked at the kernel changes from 2.6.34 to .39, and there were some mentions on scheduling, but I didn’t see any smoking gun there.
I am running an application that works fine on openSuse 11.3 and on 11.4 with the 2.6.39 kernel. But on 11.4 with the stock 2.6.37 kernel, it gives me an error.
This application creates threads with different priorities. When running pthread_setschedparam( ) it returns 1, which is EPERM (not permitted). I am logged in as root when this happens.
I’ve tried setting some of the values in /etc/security/limits.conf file, but it still didn’t work. I also didn’t understand why root would have limits on it.
I looked at the kernel changes from 2.6.34 to .39, and there were some mentions on scheduling, but I didn’t see any smoking gun there.
Any help is appreciated. Thanks.
Hello rob_g and sorry to hear of your problem. I did search around on this issue where I see you have posted about this here in another thread. While I can find talk about this elsewhere, nothing that says it as a problem with kernel 2.6.37. None the less, it seems that you have already found the solution by upgrading your kernel. There is no reason to not run a newer kernel version with openSUSE. I am running kernel-3.1.0-rc9 right this minute. There are various ways to do a kernel upgrade. A couple of bash scripts I have can provide the very latest version if you like:
> pthread_setschedparam
Which policy do you pass and what is the content of the sched struct you
use, I would guess (without knowing your details) that there is possibly a
glitch with the parameters you pass, something which was ok with the old
kernel and not with the newer one.
Do you have a minimal example of what you do which you can post?
I still have a 11.3 system here so I can compare with a minimal program if
that maybe causes what you see.
Of course a return value of EPERM should not happen in such a case I
describe and EINVAL should be returned instead but you never know if that is
simply a bug in the return value.
–
PC: oS 11.4 64 bit | Intel Core i7-2600@3.40GHz | KDE 4.6.0 | GeForce GT 420
| 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.2 | nVidia
ION | 3GB Ram
Unfortunately, it’s not as easy as just going to the latest kernel (or to 11.3). I’m writing demo programs for our customers, and we try to support the latest opensuse (11.4) and the latest with the most recent 2.6 kernel. So that means it has to work with both of those. If I can determine that this is a bug in the 2.6.37 kernel, then that’d be ok and I can make an exception. But that’s mainly what I’m trying to figure out her, is if this is a bug or I’m just doing something wrong.
I’ll develop a short simple C program today that demonstrate the problem and then post that. It should be pretty short.
On 10/14/2011 02:26 PM, rob g wrote:
>
> we try to support the latest opensuse (11.4) and the latest with the most recent 2.6 kernel.
and, maybe consider running it against the v 3.x kernel soon to ship in 12.1
and question: do you have a lot of customers running on short life
openSUSE (11.4 dies 338 days)? or do more of those standing in line with
money in their hand user the longer life, enterprise (commercial)
offerings of suse.com ?
just wondering? (of course, as soon as 3.x is running swell here it will
morph into SLES…i guess)
–
DD
openSUSE®, the “German Automobiles” of operating systems
We officially support the latest openSuse and Redhat 9 (for 2.4 kernel stuff), so we’ll eventually go to 3.x when openSuse 12.x comes out. We support all other forms of Linux as well, but we develop and test specifically on openSuse and RH. All our code is open source, so if a customer wants to use a different distro or kernel, we let them figure it out, and if they can’t, then we’ll help as we can.
I maintain linux device drivers for a myriad of hardware products, so it is not uncommon for a customer to latch onto a distro/version and hang on forever. Right now I’m just bringing a set of drivers up to 11.4, since they were last released under 11.0. Basically what happens is someone buys our hardware and then asks if we have drivers for a more recent kernel, and so that prompts us to bring them up to date…hence what I’m doing now.
We maintain or develop drivers to support the latest openSuse and the latest 2.6 kernel, and we also support Redhat 9 and the latest 2.4 kernel. We’re more focused on kernels than distros. We don’t specifically support later versions of Redhat or Fedora. I do try to keep a supply of different distros handy for testing though, especially if a customer has an issue on that version.
Ok, here is a simple program. Forgive its crudeness. I just tested this, and when executed as root, on 11.3 and 11.4 with the 2.6.39 kernel, it works. When executed as root on 11.4 with 2.6.37, it doesn’t.
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
void *processFunc(void)
{
int val;
while (1) {
val++;
}
}
int main(int argc, char **argv)
{
pthread_t pid;
struct sched_param param;
char junk;
int retVal;
retVal = pthread_create(&pid, NULL, processFunc, NULL);
if (retVal != 0) {
printf("Error creating thread: %d
", retVal);
exit(1);
}
param.sched_priority = 99;
retVal = pthread_setschedparam(pid, SCHED_FIFO, ¶m);
if (retVal != 0) {
printf("Error setting thread priority: %d
", retVal);
}
else {
printf("Thread created and scheduled. Hit return to end.
");
scanf("%c", &junk);
}
pthread_cancel(pid);
return 0;
}
On 10/14/2011 03:56 PM, rob g wrote:
>
> Ok, here is a simple program. Forgive its crudeness. I just tested
> this, and when executed as root, on 11.3 and 11.4 with the 2.6.39
> kernel, it works. When executed as root on 11.4 with 2.6.37, it
> doesn’t.
if you don’t get meaningful input here within a reasonable time frame
(you decide what that is [one minute to one month?]) then i’d suggest
you talk directly to some openSUSE developers (via IRC or mail list,
findable here:
Ok, thanks. I replied to the original thread I found on here in hopes the original poster had come to some resolution on their own and just hadn’t posted it, but have gotten no response yet. This isn’t a time critical thing, but I would like a definitive answer one way or the other on if it’s me, or the kernel. I guess next would be to try a different distro with the same kernel…
>
> Ok, here is a simple program. Forgive its crudeness. I just tested
> this, and when executed as root, on 11.3 and 11.4 with the 2.6.39
> kernel, it works. When executed as root on 11.4 with 2.6.37, it
> doesn’t.
That works for me on 11.4 64 bit,
martinh@sirius:~/tmp> gcc test_thread.c -lpthread
test_thread.c: In function ‘main’:
test_thread.c:23:5: warning: passing argument 3 of ‘pthread_create’ from
incompatible pointer type
/usr/include/pthread.h:227:12: note: expected ‘void * (*)(void *)’ but
argument is of type ‘void * (*)(void)’
martinh@sirius:~/tmp> ./a.out
Error setting thread priority: 1
martinh@sirius:~/tmp> sudo ./a.out
root's password:
Thread created and scheduled. Hit return to end.
You see running a.out as normal user failed (of course) but with root rights
it works (it also works with “su - -c” as full root instead of sudo).
My system has uname -a
Linux sirius 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200
x86_64 x86_64 x86_64 GNU/Linux
–
PC: oS 11.4 64 bit | Intel Core i7-2600@3.40GHz | KDE 4.6.0 | GeForce GT 420
| 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.2 | nVidia
ION | 3GB Ram
That’s interesting, and VERY helpful. I actually had tried it on 11.4 64bit, and had the same problem (which is why I thought it was a kernel version issue).
My uname version on systems that don’t work is 2.6.37.1-1.2-desktop. I’m wondering if that’s the difference. I guess I can update…is that just a zypper update issue, or does that involve kernel patching (haven’t tried that yet).
>
> That’s interesting, and VERY helpful. I actually had tried it on 11.4
> 64bit, and had the same problem (which is why I thought it was a kernel
> version issue).
>
> My uname version on systems that don’t work is 2.6.37.1-1.2-desktop.
> I’m wondering if that’s the difference. I guess I can update…is that
> just a zypper update issue, or does that involve kernel patching
> (haven’t tried that yet).
>
My system where I tested is a plain 11.4 with security patches applied. So
if you just run the security updates you will be moved to the kernel version
I have. During its life time a openSUSE version never changes the kernel
version (in this case 2.6.37) but of course applies patches for known bugs
with the security updates (and I guess you somehow ran into that now).
If you run “zypper up” or more conservative only “zypper patch” your system
will have the same kernel I have.
–
PC: oS 11.4 64 bit | Intel Core i7-2600@3.40GHz | KDE 4.6.0 | GeForce GT 420
| 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.2 | nVidia
ION | 3GB Ram
>
> That was it! Works fine now. Thank you so much, this was quite
> annoying.
>
Ok so it somehow was obviously a known bug for 2.6.37 (or a bug which had
this as a side effect) which was already solved.
Glad to hear this works now.
I think you can tell your customers that a prerequisite for your software is
that they apply the standard security updates that it works (they should do
that of course also if they don’t use your software to have a safe and
bugfree system). And you should always test aginst the system which has this
updates because that is what runs in reality out there at your customers I
hope.
–
PC: oS 11.4 64 bit | Intel Core i7-2600@3.40GHz | KDE 4.6.0 | GeForce GT 420
| 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.2 | nVidia
ION | 3GB Ram
Heh…based on what I’ve run into so far, I don’t quite have the some confidence you do. :\ But you’re right, I should test against the security patched version. Our demos are mainly just so they can see through the code how to access the hardware, so they’ll be useful in that regard no matter what the distro or kernel…but even better if they actually worked!
