Messages in this thread | | | From | Luis Fernando Planella Gonzalez <> | Subject | Re: Flooded by do_IRQ: 0.91 No irq handler for vector | Date | Thu, 20 Aug 2009 10:31:00 -0300 |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |