problems with kernel 2.4.13

Franz Reinhardt fre at wenglor.de
Sun Nov 4 23:36:35 PST 2001


On Monday, 5. November 2001 04:19, Dieter Scholz wrote:
> Hi,
>
> > I have some problems with kernel 2.4.13. Perhaps you can help:
> >
> > 1.)
> >
> > After the ethnet startup script is executed, a message appears:
> >
> > 'task ifconfig exit_signal 17 in reparent to init'
> >
> > But eth0 is shown when executing 'ifconfig'.
> >
> > When I disable the ethnetscript and use exactly the same ifconfig command
> > in a bash shell, no error occurs at all.
> >
> > I do not have this problem, when booting this system with a 2.4.5 kernel
> > build on a pre3.0 LFS system.
> >
> > 2.)
> >
> > When working with the shell randomly a message appears:
> >
> > 'spurious 8259A interrupt: IRQ7'
> >
> > 8259A is an interrupt controller AFAIK.
> >
> > Again this problem does not appear, when booting this system the 2.4.5
> > kernel build on a pre3.0 LFS system.
>
> Ok ... should have asked Google before posting ...
>
> Problem 1 and 2 are caused by an error in the Realtek nic driver. If I use
> a
> 2.4.7 kernel everything works ok.
>
> > 3.)
> >
> > Both, the 2.4.5 and 2.4.13 kernels print out the following message, when
> > booting:
> >
> > 'IRQ routing conflict for 00.7.02: have IRQ 5 want IRQ 10'
> > 'IRQ routing conflict for 00.7.03: have IRQ 5 want IRQ 10'
> >
> > IRQ 10 is used by my Ethernet card.
> >
> > /proc/pci says, that 7.02/03 are my USB Controllers.
> >
> > Does these messages point to an error or can I ignore them?
>
> I'm still curious, is this just a warning or does this message say
> something
> is wrong with my system or to be more specific with my interrupt table?

This warning may be caused by unclean device driver coding (or hardware that 
doesn't support interrupt routing). Normally a linux device driver for a pci 
device should be able to route interrupts to any free interrupt. The 
interrupt may be even shared with another pci device. 
So, as long as there a free interrupts, the device will get the free one.
Exceptions are always possible :-)
To track this down, I would remove both modules from the kernel (rmmod) and 
insert them manually (insmod), to find out which sequence causes the 
interrupt conflict.

Franz 

>
> Dieter
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message



More information about the lfs-support mailing list