linuxconsole-dev

FC3 and ruby woes

[James v. Z. <ja...@dv...>]

Just not stable. (for me)

Applying the same process that I've applied to rh9, fc1 and fc2, I have
not yet succeeded in producing a stable fc3 replica of an fc2 ruby
configuration.

I have applied the ruby-2.6.9-20041021.diff to the latest fc3 kernel
tree. It applied and compiled cleanly.

I have patched Xorg-6.8.1 most recent for fc3 with the mandrake
isolate_device patch.

I have compiled the kernel and X both with cpu-specific (athlon)
optomizations, something I have done with every other ruby config that
is working here.

I use nVidia cards exclusively, no TNT2 in service, all MX440, MX4000,
and FX5200. For this machine 1x FX5200, 2x MX440.

Symptoms are as follows, under 6111 or 6629 nV drivers, the system will
boot but experience a kernel oops/panic not long after X has started. It
is not consistent. I might crash while starting an Xinimera session with
rhgb graphical boot, or it might complete boot, give me three login
prompts, and crash soon after. I can login on any console if it doesn't
crash first.

If I don't start X, everything is stable. If I boot runlevel3 and start
X as Xinimera session, seems stable. I haven't done a long test of this,
but it doesn't lockup within seconds as it sometimes does with rhgb and
almost always does at runlevel 5 as gdm starts the consoles.

I also applied the following correction hunk to ruby, just in case,
although discussion suggested x86-64 problem that doesn't impact 32-bit
units. Doesn't solve any problems for me.

------------------------------------------------------------------
diff -Nurp --exclude-from=exclude linux-2.6.9/fs/compat_ioctl.c 
r269/fs/compat_ioctl.c
--- linux-2.6.9/fs/compat_ioctl.c       2004-10-19 00:55:27.000000000
+0300
+++ r269/fs/compat_ioctl.c      2004-10-20 19:31:58.000000000 +0300
@@ -1609,8 +1611,10 @@ static int do_fontx_ioctl(unsigned int f
                     get_user(data, &user_cfd->chardata))
                         return -EFAULT;
                 op.data = compat_ptr(data);
-               return con_font_op(fg_console, &op);
+               return con_font_op(vc, &op);
         case GIO_FONTX:
+               if (!user_cfd->chardata)
+                       return 0;
                 op.op = KD_FONT_OP_GET;
                 op.flags = 0;
                 op.width = 8;
------------------------------------------------------------------

I am currently suspecting Xorg to be unstable in this configuration, I
am wondering what success others have had with similar 32 bit FC3
configurations.

This same configuration was 100% stable under FC2 on the same machine.

Should I double check my kernel config ?-- it has changed from fc2 to
fc3, now having less built in and more modular and based on the fc3
kernel distribution. Should I avoid athlon optimizations?

Are there any known issues that I might not be aware of that would
produce such behaviour?

J

http://members.westnet.com.au/vanzeeland

FC3 kernel problem Re: FC3 and ruby woes

[James v. Z. <ja...@dv...>]

Confirmed FC3 kernel issue.

Compiling 32bit Athlon fc3 kernel with ruby patch results in an unstable
kernel that crashes inconsistently on launch of X.

This is duplicated using another standalone box without configuring
multiple consoles, just installing ruby kernel only.

What can I do to provide some debugging info?

I shall test further to confirm ruby patch against fc3 kernel as source
of issue. 

Anyone aware of FC3 quirks that might impact ruby?
such as gcc3.4.2-6.fc3? 

recalling the inlining issue : One can't just patch vanilla 2.6.9 with
ruby and expect it to compile under FC3, it will fail with inlining
errors, as do a small handful of other modules. However, patch the FC3
kernel and it compiles, but does it compile correctly?

Perhaps I should just wait for 2.6.10-ruby.

J

On Mon, 2004-12-20 at 12:00, James van Zeeland wrote:
> Just not stable. (for me)
> 
> Applying the same process that I've applied to rh9, fc1 and fc2, I have
> not yet succeeded in producing a stable fc3 replica of an fc2 ruby
> configuration.
> 
> I have applied the ruby-2.6.9-20041021.diff to the latest fc3 kernel
> tree. It applied and compiled cleanly.
> 
> I have patched Xorg-6.8.1 most recent for fc3 with the mandrake
> isolate_device patch.
> 
> I have compiled the kernel and X both with cpu-specific (athlon)
> optomizations, something I have done with every other ruby config that
> is working here.
> 
> I use nVidia cards exclusively, no TNT2 in service, all MX440, MX4000,
> and FX5200. For this machine 1x FX5200, 2x MX440.
> 
> Symptoms are as follows, under 6111 or 6629 nV drivers, the system will
> boot but experience a kernel oops/panic not long after X has started. It
> is not consistent. I might crash while starting an Xinimera session with
> rhgb graphical boot, or it might complete boot, give me three login
> prompts, and crash soon after. I can login on any console if it doesn't
> crash first.
> 
> If I don't start X, everything is stable. If I boot runlevel3 and start
> X as Xinimera session, seems stable. I haven't done a long test of this,
> but it doesn't lockup within seconds as it sometimes does with rhgb and
> almost always does at runlevel 5 as gdm starts the consoles.
> 
> I also applied the following correction hunk to ruby, just in case,
> although discussion suggested x86-64 problem that doesn't impact 32-bit
> units. Doesn't solve any problems for me.
> 
> ------------------------------------------------------------------
> diff -Nurp --exclude-from=exclude linux-2.6.9/fs/compat_ioctl.c 
> r269/fs/compat_ioctl.c
> --- linux-2.6.9/fs/compat_ioctl.c       2004-10-19 00:55:27.000000000
> +0300
> +++ r269/fs/compat_ioctl.c      2004-10-20 19:31:58.000000000 +0300
> @@ -1609,8 +1611,10 @@ static int do_fontx_ioctl(unsigned int f
>                      get_user(data, &user_cfd->chardata))
>                          return -EFAULT;
>                  op.data = compat_ptr(data);
> -               return con_font_op(fg_console, &op);
> +               return con_font_op(vc, &op);
>          case GIO_FONTX:
> +               if (!user_cfd->chardata)
> +                       return 0;
>                  op.op = KD_FONT_OP_GET;
>                  op.flags = 0;
>                  op.width = 8;
> ------------------------------------------------------------------
> 
> I am currently suspecting Xorg to be unstable in this configuration, I
> am wondering what success others have had with similar 32 bit FC3
> configurations.
> 
> This same configuration was 100% stable under FC2 on the same machine.
> 
> Should I double check my kernel config ?-- it has changed from fc2 to
> fc3, now having less built in and more modular and based on the fc3
> kernel distribution. Should I avoid athlon optimizations?
> 
> Are there any known issues that I might not be aware of that would
> produce such behaviour?
> 
> J
> 
> http://members.westnet.com.au/vanzeeland
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

Re: FC3 kernel problem Re: FC3 and ruby woes

[Aivils <ai...@un...>]

On Tuesday 21 December 2004 14:08, James van Zeeland wrote:
> Confirmed FC3 kernel issue.
> 
> Compiling 32bit Athlon fc3 kernel with ruby patch results in an unstable
> kernel that crashes inconsistently on launch of X.
> 
Are You capable determine where oops happens?

In my case oops oft (1 time per 24h) happens in the nvidia module.
As result specific head dies until full system restart. Oops may never
happen if GLX applications is not used :) Unfortunately in the my end
GLX applications will be run everyday. Next head runs as nothig
happened even if reman 1 head from 3.

Aivils

GLX + (Re: FC3 kernel problem -- not ruby either.)

[James v. Z. <ja...@dv...>]

> In my case oops oft (1 time per 24h) happens in the nvidia module.
> As result specific head dies until full system restart.

re: GLX -- I also had such GLX issues with older Xorg on FC2; newest
update with 6629 driver solved them all for me. Days/weeks uptime with
recent ruby.vz kernels, play games, any console, all works, all stable!
Have been going from one kernel update to the next with no reset or
crash inbetween.

>From my experiments I feel FC2 with most recent Xorg best for ruby 

FC3 is obviously another story :

This is not a ruby problem either, as I tried removing ruby and kernel
remains unstable. It's a mystery.

I have one stable FC3 kernel tree/build. I am going to look closely at
it and see if I can find out what makes it stable while five other FC3
based kernels are unstable all with the same symptoms.

I would need serial port debug output or crash dump patch to provide
debugging info, yes? I can't get to a console to see output.

J

http://members.westnet.com.au/vanzeeland


On Wed, 2004-12-22 at 00:22, Aivils wrote:
> On Tuesday 21 December 2004 14:08, James van Zeeland wrote:
> > Confirmed FC3 kernel issue.
> > 
> > Compiling 32bit Athlon fc3 kernel with ruby patch results in an unstable
> > kernel that crashes inconsistently on launch of X.
> > 
> Are You capable determine where oops happens?
> 
> In my case oops oft (1 time per 24h) happens in the nvidia module.
> As result specific head dies until full system restart. Oops may never
> happen if GLX applications is not used :) Unfortunately in the my end
> GLX applications will be run everyday. Next head runs as nothig
> happened even if reman 1 head from 3.
> 
> Aivils
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

Re: FC3 kernel problem -- not ruby either.

[James v. Z. <ja...@dv...>]

> I have one stable FC3 kernel tree/build. I am going to look closely at
> it and see if I can find out what makes it stable

because it's not an FC3 kernel tree, it was built from kernel.org 2.6.9




On Wed, 2004-12-22 at 13:50, James van Zeeland wrote:
> > In my case oops oft (1 time per 24h) happens in the nvidia module.
> > As result specific head dies until full system restart.
> 
> re: GLX -- I also had such GLX issues with older Xorg on FC2; newest
> update with 6629 driver solved them all for me. Days/weeks uptime with
> recent ruby.vz kernels, play games, any console, all works, all stable!
> Have been going from one kernel update to the next with no reset or
> crash inbetween.
> 
> >From my experiments I feel FC2 with most recent Xorg best for ruby 
> 
> FC3 is obviously another story :
> 
> This is not a ruby problem either, as I tried removing ruby and kernel
> remains unstable. It's a mystery.
> 
> I have one stable FC3 kernel tree/build. I am going to look closely at
> it and see if I can find out what makes it stable while five other FC3
> based kernels are unstable all with the same symptoms.
> 
> I would need serial port debug output or crash dump patch to provide
> debugging info, yes? I can't get to a console to see output.
> 
> J
> 
> http://members.westnet.com.au/vanzeeland
> 
> 
> On Wed, 2004-12-22 at 00:22, Aivils wrote:
> > On Tuesday 21 December 2004 14:08, James van Zeeland wrote:
> > > Confirmed FC3 kernel issue.
> > > 
> > > Compiling 32bit Athlon fc3 kernel with ruby patch results in an unstable
> > > kernel that crashes inconsistently on launch of X.
> > > 
> > Are You capable determine where oops happens?
> > 
> > In my case oops oft (1 time per 24h) happens in the nvidia module.
> > As result specific head dies until full system restart. Oops may never
> > happen if GLX applications is not used :) Unfortunately in the my end
> > GLX applications will be run everyday. Next head runs as nothig
> > happened even if reman 1 head from 3.
> > 
> > Aivils
> > 
> > 
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now. 
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > Linuxconsole-dev mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> > 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>