linuxconsole-dev

Re: 2.6.5-ruby boot problem

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

Unfortunately I should use agressive methods to check out how
wide is ruby bug.

> ============================================
> kernel BUG at kernel/softirq.c:412!
> invalid operand: 000 [#1]
> 
-               BUG_ON(per_cpu(tasklet_vec, hotcpu).list);
-               BUG_ON(per_cpu(tasklet_hi_vec, hotcpu).list);
+               per_cpu(tasklet_vec, hotcpu).list = NULL;
+               per_cpu(tasklet_hi_vec, hotcpu).list = NULL;

I do not know how linux-ruby destroy static structures :(
Current i have only one thread - linux-ruby dies shortly
after VGA console init, because R.Russel place BUG into
line 412.

Aivils

Re: 2.6.5-ruby boot problem

[Zoltan B. <zb...@fr...>]

Arne Georg Gleditsch =EDrta:
> * Zoltan Boszormenyi
>=20
>>do your Num/Caps/Scroll Lock leds work? The keys themselves do
>>but the led states aren't changing. (2.6.6-rc2-mm1-ruby)
>=20
>=20
> Ah, no, they don't.  Not surprising, perhaps, since set_leds was
> calling tasklet_schedule before the tasklet lists were assigned to

I don't really get this. This is in linux-2.6.5/init/main.c :

-------------from line 477 -------------
         init_timers();
         softirq_init();
         time_init();
=20

         /*
          * HACK ALERT! This is early. We're enabling the console before
          * we've done PCI setups etc, and console_init() must be aware o=
f
          * this. But we do want output early, in case something goes wro=
ng.
          */
         console_init();
         if (panic_later)
                 panic(panic_later, panic_param);
----------------------------------------

So the softirq_init() is already run before console_init()
that goes this way (back trace):

Call Trace:
  [<c0120432>] __tasklet_schedule+0x92/0xb0
  [<c01e7af1>] vte_ris+0x181/0x190
  [<c01edbe5>] vc_init+0x45/0x60
  [<c021770c>] vgacon_init+0x8c/0xc0
  [<c01edd93>] vc_allocate+0x123/0x1f0
  [<c01ef195>] vt_map_display+0x145/0x1c0
  [<c036ef0a>] vga_console_init+0x3a/0xb0
  [<c01088ba>] setup_irq+0x8a/0xf0
  [<c036ab63>] console_init+0x23/0x30

 > NULL.  I just commented out the two lines that were originally BUG_ON,
 > now the leds work again.  I suppose there's an ordering problem here,
 > if the lists are not really allowed to be appended to before the
 > softirq-stuff runs.

But softirq_init() was already done.

Rusty, could it be the BUG_ON() calls are bogus?

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: 2.6.5-ruby boot problem

[Rusty R. <ru...@ru...>]

On Thu, 2004-04-29 at 14:51, Zoltan Boszormenyi wrote:
> Arne Georg Gleditsch =EDrta:
> > * Zoltan Boszormenyi
> >=20
> >>do your Num/Caps/Scroll Lock leds work? The keys themselves do
> >>but the led states aren't changing. (2.6.6-rc2-mm1-ruby)
> >=20
> >=20
> > Ah, no, they don't.  Not surprising, perhaps, since set_leds was
> > calling tasklet_schedule before the tasklet lists were assigned to
>=20
> I don't really get this. This is in linux-2.6.5/init/main.c :
>=20
> -------------from line 477 -------------
>          init_timers();
>          softirq_init();

But this needs spawn_ksoftirqd, which isn't called here.

Looks like the right fix is to remove the BUG_ON()s in cpu_callback,
or wrap them in "if (system_state =3D=3D SYSTEM_RUNNING)".

Rusty.
--=20
Anyone who quotes me in their signature is an idiot -- Rusty Russell

Re: 2.6.5-ruby boot problem

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

On Thursday 29 April 2004 08:37, Rusty Russell wrote:
> On Thu, 2004-04-29 at 14:51, Zoltan Boszormenyi wrote:
> > Arne Georg Gleditsch =EDrta:
> > > * Zoltan Boszormenyi
> > >=20
> > >>do your Num/Caps/Scroll Lock leds work? The keys themselves do
> > >>but the led states aren't changing. (2.6.6-rc2-mm1-ruby)
> > >=20
> > >=20
> > > Ah, no, they don't.  Not surprising, perhaps, since set_leds was
> > > calling tasklet_schedule before the tasklet lists were assigned to
> >=20
> > I don't really get this. This is in linux-2.6.5/init/main.c :
> >=20
> > -------------from line 477 -------------
> >          init_timers();
> >          softirq_init();
>=20
> But this needs spawn_ksoftirqd, which isn't called here.
>=20
> Looks like the right fix is to remove the BUG_ON()s in cpu_callback,
> or wrap them in "if (system_state =3D=3D SYSTEM_RUNNING)".

Thanks You very match for Your deep and wide support.
linuxconsole.sf.net project have his own terminal emulation code, which
seems right now is slightly outdated.
Our bug is calling set_leds() to early. I will try to find right place for
set_leds() and live alone linus-tree 2.6.5 ,because here set_leds() removed
from reset_terminal since APR-2002 :)
So BUG_ON() kernel/softirq.c line 412 notify us about early call of
tasklet_schedule() and You have the right.

Aivils Stoss

Re: 2.6.5-ruby boot problem

[Zoltan B. <zb...@fr...>]

Aivils =EDrta:
> linuxconsole.sf.net project have his own terminal emulation code, which
> seems right now is slightly outdated.
> Our bug is calling set_leds() to early. I will try to find right place =
for
> set_leds() and live alone linus-tree 2.6.5 ,because here set_leds() rem=
oved
> from reset_terminal since APR-2002 :)
> So BUG_ON() kernel/softirq.c line 412 notify us about early call of
> tasklet_schedule() and You have the right.

So when will we see the CVS updated? ;-)

Best regards
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: 2.6.5-ruby boot problem

[Arne G. G. <ar...@li...>]

* Aivils
> I do not know how linux-ruby destroy static structures :(
> Current i have only one thread - linux-ruby dies shortly
> after VGA console init, because R.Russel place BUG into
> line 412.

I don't think this is memory corruption.  I've made an attempt to
chase this down, and it seems the problem is the call to
tasklet_schedule in set_leds.  The call stack is like this:

  vt_console_init
  vga_console_init
  vt_map_display
  vc_allocate
  vc_init
  vte_ris
  set_leds
  tasklet_schedule

Not sure why this is a problem or what the correct fix is, though.


							Arne.

Re: 2.6.5-ruby boot problem

[Arne G. G. <ar...@li...>]

* Arne Georg Gleditsch
> Not sure why this is a problem or what the correct fix is, though.

As a datapoint, with the quick-and-dirty fix given, I'm running a
multiseat X configuration quite happily with 2.6.6rc3/ruby.  I'm
probably not exercising all of the Ruby codebase, but if anyone wants
my patches, I'll be happy to make them available.


							Arne.

Re: 2.6.5-ruby boot problem

[Zoltan B. <zb...@fr...>]

Hi,

Arne Georg Gleditsch =EDrta:
> * Arne Georg Gleditsch
>=20
>>Not sure why this is a problem or what the correct fix is, though.
>=20
>=20
> As a datapoint, with the quick-and-dirty fix given, I'm running a
> multiseat X configuration quite happily with 2.6.6rc3/ruby.  I'm
> probably not exercising all of the Ruby codebase, but if anyone wants
> my patches, I'll be happy to make them available.
>=20
>=20
> 							Arne.

do your Num/Caps/Scroll Lock leds work? The keys themselves do
but the led states aren't changing. (2.6.6-rc2-mm1-ruby)

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: 2.6.5-ruby boot problem

[Arne G. G. <ar...@li...>]

* Zoltan Boszormenyi
> do your Num/Caps/Scroll Lock leds work? The keys themselves do
> but the led states aren't changing. (2.6.6-rc2-mm1-ruby)

Ah, no, they don't.  Not surprising, perhaps, since set_leds was
calling tasklet_schedule before the tasklet lists were assigned to
NULL.  I just commented out the two lines that were originally BUG_ON,
now the leds work again.  I suppose there's an ordering problem here,
if the lists are not really allowed to be appended to before the
softirq-stuff runs.


							Arne.