AW: AW: AW: AW: AW: [realtek] RTL8101L/BL Support

[Markus Wössner]

Donald,

Thank you for your kind assistance.
Looks like I stole your time :-(

For the information of you and the other members of this list, I will
describe the solution of the problem:

On a mainboard with a onboard RLT8101L the NIC refused to work.
The solution was simple - for some reason the NIC did not like getting
IRQ12.
Obviously this chip IS supported.

Switching ON legacy mouse support in BIOS made IRQ 12 unavailable for
the NIC and fixed the problem.

What I do not know, is, if this is a BIOS bug or a kernel bug in
2.4.20...

With best regards,
Markus Woessner


> -----Ursprüngliche Nachricht-----
> Von: Donald Becker [mailto:becker@scyld.com] 
> Gesendet: Dienstag, 28. Januar 2003 20:42
> An: Markus Wössner
> Betreff: Re: AW: AW: AW: AW: [realtek] RTL8101L/BL Support
> 
> 
> On Tue, 28 Jan 2003, Markus Wössner wrote:
> > > On Tue, 28 Jan 2003, Markus Wössner wrote:
> > > 
> > > > > If so, check the interrupt count in /proc/interrupts.  If the 
> > > > > eth0 count is zero, you have an interrupt routing problem.
> > > > 
> > > > /proc/interrupts shows only interrupts: 0, 1, 2, NMI, ERR
> > > > 
> > > > Looks like I have that problem.
> > > 
> > > Make certain that the interface is activated before checking.
> > > There should be an entry for "eth0", but the interrupt count 
> > > will be zero if the interrupt controller (APIC) is not working.
> > 
> > I use dhcpcd -H -D eth0 - is this enough to activate?
> > The NIC definitely sends at least 1 DHCP discover package to the 
> > server before I check /proc/interrupts.
> 
> Explicitly bring up the interface with 'ifconfig eth0 ...' 
> and try sending packets.
> 
> > > > I already tried disabling ACPI, but this makes no difference to 
> > > > the
> > > > above described behaviour. What can I do to get this 
> system running?
> > > 
> > > There is likely a clue in the system boot-up messages.
> > 
> > You mean in the linux boot messages or in BIOS boot messages?
> 
> The Linux boot messages.
> 
> Keep in mind that this is a problem with the distribution 
> that you are using, *not* the driver.  You should ask the 
> distribution supplier for support.
> 
> -- 
> Donald Becker				becker@scyld.com
> Scyld Computing Corporation		http://www.scyld.com
> 410 Severn Ave. Suite 210		Scyld Beowulf cluster system
> Annapolis MD 21403			410-990-9993
>