I compile MudOS on...

[Atomic]

Just to get a clear view on what systems you guys are using and what development tools/libraries/compilers
are needed to do so, I'd like to know on what OS you're running your version of MudOS.

I've tried on RedHat about 5 years ago, presently I've tried:

Debian Linux 3.0
Debian Linux 3.1
Debian Linux 4.0 (where it runs on now)

I'm feeling that I could compile my MudOS driver probably a lot better if only I knew how.
Perhaps I'm still missing something.

[cratylus]

I've compiled MudOS (the version shipping with DS) on:

IRIX (I don't remember the version)
SuSE Linux 8, 9, and 10
Sun Solaris 8, 9, and 10 (both SPARC and x86)
Windows (both Cygwin and MinGW)
Various Linux Distros Whose Versions I Forgot (Ubuntu, Centos, WolfOS)


With various version of GCC ranging from 3.x to 4.x. I don't
remember the last time I compiled on GCC 2.x, but I
suspect that works just fine as well.

I'm feeling that I could compile my MudOS driver probably a lot better if only I knew how.

I thought you fixed your problem. Has something new come up?

-Crat

[vlad]

I have used:

fedora 4
Debian
Mac OSX 10.4

[Nulvect]

Slackware 10.1 and 11.0 both compiled MudOS just fine.

[Atomic]

I thought you fixed your problem. Has something new come up?

-Crat

Well, apart from all the warnings compiling MudOS the last time, I'm still
having this thing that's spamming my console screen:

Code:

setitimer: driver (pid = 5354) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000
setitimer: driver (pid = 5354) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000
setitimer: driver (pid = 5354) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000

In other words: some proces (read: the driver (pid 5354)) is still doing something to the OS that it
didn't do that before (behaved on other OS's/versions)

You guys compiling MudOS with no warning whatsoever or you're just ignoring 'm?

Vlad wrote:

I have used:

fedora 4
Debian
Mac OSX 10.4

Vlad, what version of Debian is that?

[cratylus]

You guys compiling MudOS with no warning whatsoever or you're just ignoring 'm?

http://dead-souls.net/ds-inst-faq.html#10

I'm still having this thing that's spamming my console screen:

That thing is weird and I have no idea what it is. I have never seen it before.

Anyone else have a clue?

Is it actually interfering with running the mud?

-Crat

[cratylus]

Interesting. The man page for setitimer has this in it:

       POSIX.1  says that setitimer() should fail if a tv_usec value is speci-
       fied that is outside of the range 0 to 999999.  However, Linux does not
       give  an  error, but instead silently adjusts the corresponding seconds
       value for the timer.

And a casual google search suggests that some versions of Linux  distros
(perhaps even the kernel itself) plan to be compliant with this spec starting in 2007.

I'd be interested to know if this is causing problems for your mud.

A possible fix might be to change the driver source to have 999999 as the
largest tv_usec value.

Of course, I haven't the foggiest notion how that would affect your mud.

-Crat

[Tricky]

Well, apart from all the warnings compiling MudOS the last time, I'm still
having this thing that's spamming my console screen:

Code:

setitimer: driver (pid = 5354) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000
setitimer: driver (pid = 5354) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000
setitimer: driver (pid = 5354) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000

In other words: some proces (read: the driver (pid 5354)) is still doing something to the OS that it didn't do that before (behaved on other OS's/versions)

That is really weird as the code in the source that calls setitimer(), ualarm.c, shouldn't even... well... set it to that.

Code:

/* Berkeley copyright removed for briefness */

#if defined(LIBC_SCCS) && !defined(lint)
static char sccsid[] = "@(#)ualarm.c    5.5 (Berkeley) 2/23/91";
#endif                          /* LIBC_SCCS and not lint */

#define USPS    1000000         /* # of microseconds in a second */

unsigned ualarm PROT((register unsigned, register unsigned));

/*
 * Generate a SIGALRM signal in ``usecs'' microseconds.
 * If ``reload'' is non-zero, keep generating SIGALRM
 * every ``reload'' microseconds after the first signal.
 */
unsigned ualarm P2(register unsigned, usecs, register unsigned, reload) {
    struct itimerval new, old;

    new.it_interval.tv_usec = reload % USPS;
    new.it_interval.tv_sec = reload / USPS;

    new.it_value.tv_usec = usecs % USPS;
    new.it_value.tv_sec = usecs / USPS;

    if (setitimer(ITIMER_REAL, &new, &old) == 0)
        return old.it_value.tv_sec * USPS + old.it_value.tv_usec;
    /* else */
    return -1;
}

Tricky

[wodan]

discworld spits that out a few times when it boots as well, as far as I can tell it's impossible to actually use the wrong values, and it stops doing that soonish after a boot too, it's pretty weird but doesn't seem to harm anything.

[Atomic]

I must say that the current Debian distro is giving that to my console screen say about 5-8 times at tops, so it
seems to stop at some time.
Weird thing in this is that I didn't have that when using Debian 3.0 or even 3.1.

I don't think it does anything effectly to the mud, but who knows

[Tricky]

Sounds like the Debian 4 implementation of ualarm in it's kernal is flawed.

The code I posted is only compiled into MudOS if ualarm is not available in your system.

Tricky

[Nulvect]

It looks like the P2 function is being called with a usecs value of 0. This fits the error output of secs = 0 and usecs = 1000000. Not sure what that means, though.

[Tricky]

It looks like the P2 function is being called with a usecs value of 0. This fits the error output of secs = 0 and usecs = 1000000. Not sure what that means, though.

P2 is a #define wrapper to say that this function, ualarm, has 2 arguments.

The code I posted is only included if the system kernal does not have ualarm.

Tricky