rtl8139
Mij
My D-Link rt8139C card isn't recognized correctly,
and produces the following output when booting:
(copied manually, may contain typos)
# eth_check_drivers: got notification from 14 <- or from 16, 28
# eth_check_drivers: got name: rtl8139
# eth_restart: restarting eth0, task 14, port 0
# rtl8139#0: Realtek TRL8139 (10ec/8139) at 0.10.0
# rtl8139#0: using I/O address 0x9800, IRQ 255
here already, that IRQ made me turn up the nose; then,
most interesting:
# RTL8139: error, couldn't set IRQ policy: -22
# Panic in rtl8139: reset failed to complete
# eth_restart: sendrec to ethernet task 14 failed: -108
i'm have no expertise in kernel programming, so debugging
is hostile to me, but I began by
- 1-ing debug
- 1-ing VERBOSE
then I took a look into rtl8139.c , here:
# rep->re_hook_id = rep->re_irq;
# if ((s=sys_irqsetpolicy(rep->re_irq, 0, &rep->re_hook_id)) != OK)
# printf("RTL8139: error, couldn't set IRQ policy: %d\n", s);
walking up to the where I've been able to, the IRQ appears to
be set in rl_pci_conf by pci_attr_r8():
# bar= pci_attr_r32(devind, PCI_BAR) & 0xffffffe0;
# if ((bar & 0x3ff) >= 0x100-32 || bar < 0x400)
# panic("rtl_probe",
# "base address is not properly configured", NO_NUM);
# rep->re_base_port= bar;
#
# ilr= pci_attr_r8(devind, PCI_ILR);
# rep->re_irq= ilr;
so ahead to pci.{h, c} I found:
# _PROTOTYPE( u8_t pci_attr_r8, (int devind, int port));
and
# return pcibus[busind].pb_rreg8(busind, devind, port);
which by prior assignments means calling pcii_rreg8():
# PRIVATE u8_t pcii_rreg8(busind, devind, port)
It is my heuristic that in pci.c "#if 0" occurrences comment
debug stuff, so I made vi replace them to "if 1", recompiled,
restarted:
# #if 0
# printf("pcii_rreg8(%d, %d, 0x%X): %d.%d.%d= 0x%X\n",
# busind, devind, port,
# pcibus[busind].pb_bus, pcidev[devind].pd_dev,
# pcidev[devind].pd_func, v);
# #endif
produces on boot:
pcii_rreg8(1, 9, 0xE): x.y.0 = 0xFF
where x is in {0,1} and, for what I can see on the fast
scroll, in [16..31].
I can only guess it tries from the base address 0.10.0 up
to 1.31.1 . I also guess about those params 1,9,0xE being
fixed (I'm too lazy to dump on a file)
the core of the pcii_rreg8() is PCII_RREG8_() which
appears to always return 255/0xFF . I could resolve
PCII_RREG8_ until sys_out(), then I lose its track.
suggestions for further investigations?
I append one note. The code is well written, but you have
to lower the assumptions if you look for more contributions.
Some parts of the code are still dummy, and mostly dominate
by functional, not explanatory comments.
I look forward for some clues from you. thanks
ryadav
Philip Homburg
>hello
>
>My D-Link rt8139C card isn't recognized correctly,
>and produces the following output when booting:
>
>(copied manually, may contain typos)
>
># eth_check_drivers: got notification from 14 <- or from 16, 28
># eth_check_drivers: got name: rtl8139
># eth_restart: restarting eth0, task 14, port 0
># rtl8139#0: Realtek TRL8139 (10ec/8139) at 0.10.0
># rtl8139#0: using I/O address 0x9800, IRQ 255
I've not seen this before. Usually the BIOS assigns a usable IRQ. Debug
output is supposed to end up in /usr/log/messages. Can you set 'pci_debug=1'
in the boot monitor and post the resulting list of PCI devices. Maybe
that provides a clue for further debugging.
--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency
Martijn van Buul
> I've not seen this before. Usually the BIOS assigns a usable IRQ. Debug
> output is supposed to end up in /usr/log/messages. Can you set 'pci_debug=1'
> in the boot monitor and post the resulting list of PCI devices. Maybe
> that provides a clue for further debugging.
Other OSes (like NetBSD, for example) have PCI fixup routines because of
this - some BIOSes only assign resources to devices they're familiar with.
--
Martijn van Buul - pi...@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac Asimov
Mij
> I've not seen this before. Usually the BIOS assigns a usable IRQ.
I dug on the irq setting routine indeed as I supposed minix to adapt
it in these cases
> Debug output is supposed to end up in /usr/log/messages. Can you set 'pci_debug=1'
> in the boot monitor and post the resulting list of PCI devices. Maybe
> that provides a clue for further debugging.
this is an excerpt from /usr/log/messages:
(again copied manually)
# pci_intel_init: VIA VT...
# 0.0.0: VIA VT8363/8365 [KT133/KM133] (...)
# class Host bridge (6/0/0)
# 0.1.0: VIA VT8635 [KM133 AGP] (...)
# class PCI-to-PCI bridge (6/4/0)
# 0.4.0: VIA VT82C686 (Apollo South Bridge) (...)
# class ISA bridge (6/1/0)
# 0.4.1: VIA IDE controller (...)
# class IDE controller (...)
# 0.9.0: Unknown device, vendor 1102 ...
# class Audio device
# 0.9.1: similar with class "input device"
# 0.10.0: Realtek RTL8139 (10EC/8139)
# class Ethernet controller
# 0.12.0: D-Link RTL8139 (1186/1300)
# eth ctrl
#...
the videocard is on 1.0.0; INTA & INTB "disabled",
INTC=5 INTD=11
the bios is an AWARD. IRQ settings were all to Auto; I
recall I tried to set them explicitly (to random guessed
values, what else?), resulting in the IDE controller no
longer be seen as well as several other devices.
You see 2 NICs up there; I get the same behavior no
matter what combination of them I leave plugged.
bye
Philip Homburg
>Philip Homburg wrote:
>this is an excerpt from /usr/log/messages:
>
>(again copied manually)
># pci_intel_init: VIA VT...
># 0.0.0: VIA VT8363/8365 [KT133/KM133] (...)
># class Host bridge (6/0/0)
># 0.1.0: VIA VT8635 [KM133 AGP] (...)
># class PCI-to-PCI bridge (6/4/0)
># 0.4.0: VIA VT82C686 (Apollo South Bridge) (...)
># class ISA bridge (6/1/0)
># 0.4.1: VIA IDE controller (...)
># class IDE controller (...)
># 0.9.0: Unknown device, vendor 1102 ...
># class Audio device
># 0.9.1: similar with class "input device"
># 0.10.0: Realtek RTL8139 (10EC/8139)
># class Ethernet controller
># 0.12.0: D-Link RTL8139 (1186/1300)
># eth ctrl
>#...
>
>the videocard is on 1.0.0; INTA & INTB "disabled",
>INTC=5 INTD=11
What may be worth trying is to hack the source code to assign IRQ 5 (or
11 if 5 doesn't work) to the RTL8139.
It is possible that 5 and 11 were assigned to the sound card and that
the ethernet cards are on INTA and INTB. In that case you would have to
add code to enable additional IRQs in the ISA bridge.
Álvaro Jurado Cuevas
patch and look at solutions for Mij. Nothing at all.
My chipset is Realtek 81398 (not C), but the kernel message it's the same:
eth_check_drivers: got name: rtl8139
eth_restart: restarting eth0, task 26, port 0
panic in rtl8139: reset failed to complete
eth_restart: sendrec to ethernet task 26 failed: -108
eth_check_drivers: got a notification from 14
I've thought that was DHCPD (my cable is in that mode), kernel says that can
get an IP address. But DHCPD boot ok.
My mobo is an Intel 440BX with latest BIOS, year 1999, with PIII an 256 RAM.
MINIX 3 is in Secondary IDE. All right except ethernet.
The primery OS in this machine is FreeBSD, no problems with anything. Is it
IRQ as I've read? should I change this BIOS parameters?
We want mount a MINIX server FTP to centralize downloads of krownix.sytes
comunity. It would be nice.
Any idea?
Thanks.
--
Álvaro Jurado Cuevas
http://krownix.sytes.net
Cadalso Computer
Cadalso de los Vidrios
Madrid - España
"Everybody goes to NIX"
Philip Homburg
=?UTF-8?B?w4FsdmFybw==?= Jurado Cuevas <ajur...@terra.es> wrote:
>eth_check_drivers: got name: rtl8139
>eth_restart: restarting eth0, task 26, port 0
>panic in rtl8139: reset failed to complete
>eth_restart: sendrec to ethernet task 26 failed: -108
>eth_check_drivers: got a notification from 14
Please try the following patch and report what happens.
*** /tmp/rtl8139.c Mon Nov 21 15:30:34 2005
--- /usr/src/drivers/rtl8139/rtl8139.c Mon Nov 21 15:25:20 2005
***************
*** 81,87 ****
#define printW() ((void)0)
#define vm_1phys2bus(p) (p)
! #define VERBOSE 0 /* display message during init */
#include "../libpci/pci.h"
#include "rtl8139.h"
--- 81,87 ----
#define printW() ((void)0)
#define vm_1phys2bus(p) (p)
! #define VERBOSE 1 /* display message during init */
#include "../libpci/pci.h"
#include "rtl8139.h"
***************
*** 182,195 ****
FORWARD _PROTOTYPE( unsigned my_inw, (U16_t port) );
FORWARD _PROTOTYPE( unsigned my_inl, (U16_t port) );
static unsigned my_inb(U16_t port) {
! U8_t value;
int s;
if ((s=sys_inb(port, &value)) !=OK)
printf("RTL8139: warning, sys_inb failed: %d\n", s);
return value;
}
static unsigned my_inw(U16_t port) {
! U16_t value;
int s;
if ((s=sys_inw(port, &value)) !=OK)
printf("RTL8139: warning, sys_inw failed: %d\n", s);
--- 182,195 ----
FORWARD _PROTOTYPE( unsigned my_inw, (U16_t port) );
FORWARD _PROTOTYPE( unsigned my_inl, (U16_t port) );
static unsigned my_inb(U16_t port) {
! u32_t value;
int s;
if ((s=sys_inb(port, &value)) !=OK)
printf("RTL8139: warning, sys_inb failed: %d\n", s);
return value;
}
static unsigned my_inw(U16_t port) {
! u32_t value;
int s;
if ((s=sys_inw(port, &value)) !=OK)
printf("RTL8139: warning, sys_inw failed: %d\n", s);
***************
*** 648,656 ****
pci_reserve(devind);
/* printf("cr = 0x%x\n", pci_attr_r16(devind, PCI_CR)); */
bar= pci_attr_r32(devind, PCI_BAR) & 0xffffffe0;
! if ((bar & 0x3ff) >= 0x100-32 || bar < 0x400)
! panic("rtl_probe",
! "base address is not properly configured", NO_NUM);
rep->re_base_port= bar;
ilr= pci_attr_r8(devind, PCI_ILR);
--- 648,658 ----
pci_reserve(devind);
/* printf("cr = 0x%x\n", pci_attr_r16(devind, PCI_CR)); */
bar= pci_attr_r32(devind, PCI_BAR) & 0xffffffe0;
! if (bar < 0x400)
! {
! panic("rtl_probe",
! "base address is not properly configured", NO_NUM);
! }
rep->re_base_port= bar;
ilr= pci_attr_r8(devind, PCI_ILR);
***************
*** 773,779 ****
printf("RTL8139: error, couldn't enable interrupts: %d\n", s);
#if VERBOSE /* stay silent during startup, can always get status later */
! if (rep->re_mode) {
printf("%s: model %s\n", rep->re_name, rep->re_model);
} else
{
--- 775,781 ----
printf("RTL8139: error, couldn't enable interrupts: %d\n", s);
#if VERBOSE /* stay silent during startup, can always get status later */
! if (rep->re_model) {
printf("%s: model %s\n", rep->re_name, rep->re_model);
} else
{
***************
*** 823,836 ****
#endif
/* Reset the device */
rl_outb(port, RL_CR, RL_CR_RST);
getuptime(&t0);
do {
if (!(rl_inb(port, RL_CR) & RL_CR_RST))
break;
! } while (getuptime(&t1)==OK && (t1-t0) < HZ);
! if (rl_inb(port, RL_CR) & RL_CR_RST)
! panic("rtl8139","reset failed to complete", NO_NUM);
t= rl_inl(port, RL_TCR);
switch(t & (RL_TCR_HWVER_AM | RL_TCR_HWVER_BM))
--- 825,842 ----
#endif
/* Reset the device */
+ printf("rl_reset_hw: (before reset) port = 0x%x, RL_CR = 0x%x\n",
+ port, rl_inb(port, RL_CR));
rl_outb(port, RL_CR, RL_CR_RST);
getuptime(&t0);
do {
if (!(rl_inb(port, RL_CR) & RL_CR_RST))
break;
! } while (getuptime(&t1)==OK && (t1-t0) < 10*HZ);
! printf("rl_reset_hw: (after reset) port = 0x%x, RL_CR = 0x%x\n",
! port, rl_inb(port, RL_CR));
! if (rl_inb(port, RL_CR) & RL_CR_RST)
! printf("rtl8139: reset failed to complete");
t= rl_inl(port, RL_TCR);
switch(t & (RL_TCR_HWVER_AM | RL_TCR_HWVER_BM))
Álvaro Jurado Cuevas
> #*/
> ! if (rep->re_mode) {
> printf("%s: model %s\n", rep->re_name, rep->re_model);
> } else
> {
> --- 775,781 ----
> printf("RTL8139: error, couldn't enable interrupts: %d\n", s);
>
> #if VERBOSE /* stay silent during startup, can always get status later
> #*/
Ok nice patch. Says diffrent things that Steinhoff's patch, look at:
sendrec to ethernet task 14 failed: -108 same
eth_check_drivers: got a notification from 14 same
eth_check_drivers: got name: rtl8139 same
eth_restart: restarting eth0, task 14, port 0 same
rtl8139#0: Realtek RTL8139 (10ec/8139) at 0.13.0 patch 823,836
rl_reset_hw: (before reset) port = 0x1400, RL_CR = 0xff patch 823,836
rl_reset_hw: (after reset) port = 0x1400, RL_CR = 0xff patch 823,836
Panic in rtl8139: reset failed to complete same
Same signal and unable obtain IP address... of course no IP device. Do you
see the way?
Thank you very much.
Philip Homburg
Something went wrong in patching the driver. I replaced the panic
with a printf.
I don't think it is going to work though. The value 0xff suggests that there
is no hardware at the address where the driver expects the ethernet card.
Can you get another OS to print where it thinks that the I/O ports of the
Realtek are located?
Álvaro Jurado Cuevas
> In article <kJMgf.59981$yg1....@twister.auna.com>,
> =?UTF-8?B?w4FsdmFybw==?= Jurado Cuevas <ajur...@terra.es> wrote:
>>Ok nice patch. Says diffrent things that Steinhoff's patch, look at:
>>
>>sendrec to ethernet task 14 failed: -108 same
>>eth_check_drivers: got a notification from 14 same
>>eth_check_drivers: got name: rtl8139 same
>>eth_restart: restarting eth0, task 14, port 0 same
>>rtl8139#0: Realtek RTL8139 (10ec/8139) at 0.13.0 patch
>>823,836
>>rl_reset_hw: (before reset) port = 0x1400, RL_CR = 0xff patch
>>823,836
>>rl_reset_hw: (after reset) port = 0x1400, RL_CR = 0xff patch
>>823,836
>>Panic in rtl8139: reset failed to complete same
>
> Something went wrong in patching the driver. I replaced the panic
> with a printf.
Yes I forgot the last line. Sorry.
>
> I don't think it is going to work though. The value 0xff suggests that
> there is no hardware at the address where the driver expects the ethernet
> card.
Ahm.. he he. Well my eyes are so wrong reciently.. the chipset is 8139B
(with "B" of "Boston"), not 81398... (you can kill me if you want ;)) I've
probed with 8139D. Same result (shit!)
>
> Can you get another OS to print where it thinks that the I/O ports of the
> Realtek are located?
Well, in that machine the principal OS is FreeBSD 5.4. In boot the rl0
device says that 0x1400 and 0x14ff. In krownix comunity server, FreeBSD
6.0, chipset 8139B, 0x1400 and 0x14ff too. I don't know if it's what you
mean. Tomorrow I'll look at in Windows machine (in my job) if it help you
more.
>
>
Thanks again Philip.
Álvaro Jurado Cuevas
> In article <kJMgf.59981$yg1....@twister.auna.com>,
> =?UTF-8?B?w4FsdmFybw==?= Jurado Cuevas <ajur...@terra.es> wrote:
>>Ok nice patch. Says diffrent things that Steinhoff's patch, look at:
>>
>>sendrec to ethernet task 14 failed: -108 same
>>eth_check_drivers: got a notification from 14 same
>>eth_check_drivers: got name: rtl8139 same
>>eth_restart: restarting eth0, task 14, port 0 same
>>rtl8139#0: Realtek RTL8139 (10ec/8139) at 0.13.0 patch
>>823,836
>>rl_reset_hw: (before reset) port = 0x1400, RL_CR = 0xff patch
>>823,836
>>rl_reset_hw: (after reset) port = 0x1400, RL_CR = 0xff patch
>>823,836
>>Panic in rtl8139: reset failed to complete same
>
> Something went wrong in patching the driver. I replaced the panic
> with a printf.
>
> I don't think it is going to work though. The value 0xff suggests that
> there is no hardware at the address where the driver expects the ethernet
> card.
>
> Can you get another OS to print where it thinks that the I/O ports of the
> Realtek are located?
>
>
Ahm... maybe important.
Complete kernel information about ethernet FreeBSD 5.4:
rl0 <Realtek 8139 10/100BaseTX> port 0x1400-0x14ff mem
0xf4000000-0xf40000ff irq 11 at device 13.0 on pci 0
As you seeing: exactly as MINIX except two bytes 0x14ff (irq in MINIX I
don't know).
that's all.
Philip Homburg
=?UTF-8?B?w4FsdmFybw==?= Jurado Cuevas <ajur...@terra.es> wrote:
>Complete kernel information about ethernet FreeBSD 5.4:
>
> rl0 <Realtek 8139 10/100BaseTX> port 0x1400-0x14ff mem
>0xf4000000-0xf40000ff irq 11 at device 13.0 on pci 0
I think I have run out of ideas of what might be wrong and ways to solve
the problem. Sorry.
Álvaro Jurado Cuevas
> In article <kJMgf.59981$yg1....@twister.auna.com>,
> =?UTF-8?B?w4FsdmFybw==?= Jurado Cuevas <ajur...@terra.es> wrote:
>>Ok nice patch. Says diffrent things that Steinhoff's patch, look at:
>>
>>sendrec to ethernet task 14 failed: -108 same
>>eth_check_drivers: got a notification from 14 same
>>eth_check_drivers: got name: rtl8139 same
>>eth_restart: restarting eth0, task 14, port 0 same
>>rtl8139#0: Realtek RTL8139 (10ec/8139) at 0.13.0 patch
>>823,836
>>rl_reset_hw: (before reset) port = 0x1400, RL_CR = 0xff patch
>>823,836
>>rl_reset_hw: (after reset) port = 0x1400, RL_CR = 0xff patch
>>823,836
>>Panic in rtl8139: reset failed to complete same
>
> Something went wrong in patching the driver. I replaced the panic
> with a printf.
>
> I don't think it is going to work though. The value 0xff suggests that
> there is no hardware at the address where the driver expects the ethernet
> card.
>
> Can you get another OS to print where it thinks that the I/O ports of the
> Realtek are located?
>
>
Philip, all works fine!!! my BIOS had enabled OS Plug and Play. That's all.
rl_reset_hw: (before reset) port = 0x1000, RL_CR = 0x1
Thank you very much for all.