Re: Flooded by do_IRQ: 0.91 No irq handler for vector

[Luis Fernando Planella Gonzalez <lfpg.dev@gmail.com>]

Answers below...

Em Quarta-feira 19 Agosto 2009, às 23:48:59, Eric W. Biederman escreveu:
> Luis Fernando Planella Gonzalez <lfpg.dev@gmail.com> writes:
> 
> > I have changed my distro to sidux, so it won't be an easy task to
> > return to 2.6.24....
> > Anyway, I do use the 64bit kernel.
> 
> > But I've downloaded the 32 bit version (sidux 2009.02 with the
> > 2.6.30.1 kernel), and the very same error occurs. I've just used the
> > live cd, and it does happen.
> 
> Sure.  I inferred this by how early this message starting showing
> up.   This code did not get added into the 32bit kernels until
> recently.
> 
> > Something that changed from 2.6.28 to 2.6.30 is that it no longer
> > happens the 0.99 message. All complaints are about 0.91...
> 
> Interesting.
> 
> > One more thing: Deleting /usr/sbin/irqbalance changed nothing, which
> > is no surprise, as I had already tested the noirqbalance kernel
> > option....
> 
> Even after a reboot?
Yes, even after a reboot.

> 
> Are you running any kind of vitalization on your box?
No.

> 
> > I'm pasting here something I had previously replied personally to
> > Robert Hancock, and may be useful:
> >
> > Well, as I've installed sidux, it has upgraded the kernel to 2.6.30.5,
> > but the error is the same.
> > I've also tried:
> > * noapic: the message changes to do_IRQ: 0.55 No irq handler for
> > vector (irq -1), but then the X server fails to start
> 
> Interesting... 
> 
> > * noacpi: have no effect on the error message.
> 
> There is something very strange about your box.  Possibly it is
> just VIA interrupt controller madness.  VIA has been known
> to interrupt interrupt related fields in creative ways, and
> we may be on the edge of another of these.
Probably. My mother board is an Asus P5VD2-X, which is based on VIA PT890:
http://br.asus.com/products.aspx?l1=3&l2=11&l3=346&l4=0&model=1362&modelmenu=1 (sorry, link in portuguese)

> 
> I expect it is going to come down to writing a patch to dump out
> all of the interrupt routing state on the system and to see what
> is generating the totally unexpected interrupt and then to work our
> way backwards from there.
> 
> The fact that the vector number is changing indicates that it is
> a programmable something that is causing the problem.
> 
> I'm drawing a blank on which patch to write up.
> 
> Eric
> 
Thanks again.

--
Luis Fernando Planella Gonzalez