[linrad] Re: Linrad 02.05 part II, svgalib version.
I do not undertand why this happens, because I chose "N" to the question:
"use mlockall to prevent swapping ? (Y/N) " -> "N"
This is a trivial bug. There should have been a test if(ui.memloc==0)
Ok. The xz() function has been a very efective way of finding where the
crash occured. Thanks for the tip!
In 02.06 and later renamed to if(ui.no_memlock == FALSE)
I have started to use TRUE/FALSE for variables used as boolean variables
and sometimes the variable name has to change to reflect whether
a 0 or a 1 matches what the name suggests. (I do not want to change
parameter values)
Understood.
Early like this the mlocall call seldomly fails, that is why I never
detected it. As a temporary solution, just remove the line lir_lock_mem();
Yes, mlockall fails with consistence here within linrad, but if I do
this simple program never fails here.
#include
#include
void main(void){
int i;
i=mlockall(MCL_CURRENT);
printf("returned value is %d \n",i);
}
It always return a 0 value and never crashes
Who knows!! :-)
73, Ramiro.
There will be a greatly improved Lir-02.06 tomorrow:-)
We will wait for the new version
Thank you very much!!!
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad 02.05 part II, svgalib version.
Hi Ramiro, > After some "compilation and xz iterations", I have found that the > funcion that completly crashes my computer is mlockall(), called from > function lir_lock_mem() in lsys.c. > > lir_lock_mem() is called from main() in lmain.c > > > The call to mlockall() never returns and crashes the computer. > > > > I do not undertand why this happens, because I chose "N" to the question: > "use mlockall to prevent swapping ? (Y/N) " -> "N" This is a trivial bug. There should have been a test if(ui.memloc==0) In 02.06 and later renamed to if(ui.no_memlock == FALSE) I have started to use TRUE/FALSE for variables used as boolean variables and sometimes the variable name has to change to reflect whether a 0 or a 1 matches what the name suggests. (I do not want to change parameter values) Early like this the mlocall call seldomly fails, that is why I never detected it. As a temporary solution, just remove the line lir_lock_mem(); There will be a greatly improved Lir-02.06 tomorrow:-) 73 Leif # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad 02.05 part II, svgalib version.
Hi Leif,
Forgot to post the debugging "xz":
int lir_lock_mem(void)
{
int i,k;
xz("lir_lock_mem_1");
i= mlockall(MCL_CURRENT);
xz("lir_lock_mem_2");
if(i==0)return 0;
k=errno;
munlockall();
errno=k;
return i;
}
More information about the mlockall issue.
This "dirty" code modification removes the first crash and linrad
screen appears and works well during some time, until it crashes again
when I press "X".
The crash blocks all pure text consoles, but I can get GNOME with
ctrl-alt-F7. I run "ps ax" and can not locate any linrad process running
in order to kill them.
int lir_lock_mem(void)
{
int i,k;
//i= mlockall(MCL_CURRENT);
i=0;
if(i==0)return 0;
k=errno;
munlockall();
errno=k;
return i;
}
I do not understand anything... :-(
Regards.
Ramiro.
EA1ABZ
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad 02.05 part II, svgalib version.
Ramiro Aceves wrote:
[EMAIL PROTECTED] wrote:
Hi Ramiro,
The way I locate this kind of errors is th change "DUMPFILE",
now in vernr.h, to 1.
Hello Leif,
I have done the debugging you suggested.
After some "compilation and xz iterations", I have found that the
funcion that completly crashes my computer is mlockall(), called from
function lir_lock_mem() in lsys.c.
lir_lock_mem() is called from main() in lmain.c
The call to mlockall() never returns and crashes the computer.
I do not undertand why this happens, because I chose "N" to the question:
"use mlockall to prevent swapping ? (Y/N) " -> "N"
Hi Leif,
Forgot to post the debugging "xz":
int lir_lock_mem(void)
{
int i,k;
xz("lir_lock_mem_1");
i= mlockall(MCL_CURRENT);
xz("lir_lock_mem_2");
if(i==0)return 0;
k=errno;
munlockall();
errno=k;
return i;
}
I only saw "lir_lock_mem_1" in "dmp" file.
"lir_lock_mem_2" never appeard.
Hope this helps.
Ramiro.
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad 02.05 part II, svgalib version.
[EMAIL PROTECTED] wrote: Hi Ramiro, The way I locate this kind of errors is th change "DUMPFILE", now in vernr.h, to 1. Hello Leif, I have done the debugging you suggested. After some "compilation and xz iterations", I have found that the funcion that completly crashes my computer is mlockall(), called from function lir_lock_mem() in lsys.c. lir_lock_mem() is called from main() in lmain.c The call to mlockall() never returns and crashes the computer. I do not undertand why this happens, because I chose "N" to the question: "use mlockall to prevent swapping ? (Y/N) " -> "N" Svgalib mouse settings are ok cause "mousetest" works fine. Tell me if you want me to do more tests. Ramiro. EA1ABZ. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad 02.05 part II, svgalib version.
[EMAIL PROTECTED] wrote:
Hi Ramiro,
The way I locate this kind of errors is th change "DUMPFILE",
now in vernr.h, to 1.
Then add statements xz("comment");
between code statement statements.
xz={fprintf(dmp,"%s\n",agr);fflush(dmp);sync();}
When the computer has rebooted, the last line in the file
dmp is the last xz statement encountered.
Then I would remove all xz before the last one
and insert more of them between the last one and
the next one that was not executed. Pretty soon
I know what statement that does not return.
My Debian Sarge 2.6.8 installation will be complete (perhaps)
in about 12 hours. I will try to reproduce the error you report,
but I do not think the chances are so good I can get this
error.
Maybe you could place some xz statements in your lmain.c
like this:
if(global_uiparms()==0)
{
lir_errcod=1197;
xz("goto exitmain");
goto exitmain;
}
xz("glob_uip OK");
.
.
}
vga_setmousesupport(1);
xz("mouse OK");
Verify that the mouse driver is specified correctly in libvga.config.
(You can check by trying mousetest)
Linrad-01.35 uses
mouse_init("/dev/mouse",vga_getmousetype(),MOUSE_DEFAULTSAMPLERATE);
mouse_setdefaulteventhandler();
while linrad-02.05 uses
vga_setmousesupport(1);
I do not know what the best way would be to find out where
the correct mouse driver is located. The 2.05 way is intended
to force users to get into the libvga.config file. I added
tools to allow some editing of libvga.config because that
seemed to be something needed to make the live CD easy to
use. Now with a Windows version I think it is time to
delete the 'libvga.config editor' and replace it with
some on-screen instructions about the need to use a
text editor on /etc/vga/libvga.config before proceeding.
Hello Leif,
I appreciate all your efforts and dedication in Linrad programming. I
imagine that you spend several hours a day into Linrad development. I
can not program more than a hundred of C code lines without a tremendous
headache!
I want to thank you for the very detailed answers you write to our
emails. I am going to try to introduce the debugging sentences between
the code, even when I do not well understand how such a complex program
work. You always say that you are not a programmer, but I believe you
are a great one!
Have patience with your Debian Sarge network install ;-) . In such cases
it is a good thing to have the CDROMs or DVDs at hand. I use to buy them
on cheap Internet vendors when a new Debian version is released. As you
will now, there are also CDROM and DVD images for the Etch distribution,
but they get outdated quickly. For etch I prefer the network install.
Anyway, I will experiment what you have teached to me.
We will keep in touch.
Ramiro.
EA1ABZ.
73
Leif / SM5BSZ
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad 02.05 part II, svgalib version.
Hi Ramiro,
The way I locate this kind of errors is th change "DUMPFILE",
now in vernr.h, to 1.
Then add statements xz("comment");
between code statement statements.
xz={fprintf(dmp,"%s\n",agr);fflush(dmp);sync();}
When the computer has rebooted, the last line in the file
dmp is the last xz statement encountered.
Then I would remove all xz before the last one
and insert more of them between the last one and
the next one that was not executed. Pretty soon
I know what statement that does not return.
My Debian Sarge 2.6.8 installation will be complete (perhaps)
in about 12 hours. I will try to reproduce the error you report,
but I do not think the chances are so good I can get this
error.
Maybe you could place some xz statements in your lmain.c
like this:
if(global_uiparms()==0)
{
lir_errcod=1197;
xz("goto exitmain");
goto exitmain;
}
xz("glob_uip OK");
.
.
}
vga_setmousesupport(1);
xz("mouse OK");
Verify that the mouse driver is specified correctly in libvga.config.
(You can check by trying mousetest)
Linrad-01.35 uses
mouse_init("/dev/mouse",vga_getmousetype(),MOUSE_DEFAULTSAMPLERATE);
mouse_setdefaulteventhandler();
while linrad-02.05 uses
vga_setmousesupport(1);
I do not know what the best way would be to find out where
the correct mouse driver is located. The 2.05 way is intended
to force users to get into the libvga.config file. I added
tools to allow some editing of libvga.config because that
seemed to be something needed to make the live CD easy to
use. Now with a Windows version I think it is time to
delete the 'libvga.config editor' and replace it with
some on-screen instructions about the need to use a
text editor on /etc/vga/libvga.config before proceeding.
73
Leif / SM5BSZ
> I also can not get working svgalib version of Linrad 02.05 on my two
> computers. Linrad 01.37 _works_ just fine, so I discard a svgalig issue.
>
> Computers are a 1.86 GHz 1GB RAM Pentium Centrino laptop and a 1.2 GHz
> AMD Athlon 256 MB desktop.
>
> * svgalib linrad 02.05
> * both computers, same result*
>
> # ./linrad
> I press "S"
> I choose video mode 12: 1024x768
> I choose font scale "1".
> I choose "N"
> I choose "N"
> I choose "20" mouse reduction factor
>
> The system hangs hard!
>
> Switching to alternate console does not work.
> CTRL-ALT-DEL does not work.
>
> I pressed reset button to restart the machine.
>
> Thank you very much
> Ramiro, EA1ABZ.
>
> #
> This message is sent to you because you are subscribed to
> the mailing list .
> To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
> Send administrative queries to <[EMAIL PROTECTED]>
>
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
