DragonFly users List (threaded) for 2009-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Realtek NIC issue
On Thu, 10 Sep 2009, Sepherosa Ziehau wrote:
> On Wed, Sep 9, 2009 at 1:23 AM, Saifi Khan <saifi.khan@datasynergy.org> wrote:
> > Hi all:
> >
> > Installed DragonFlyBSD 2.3.2.750.g517f2e-DEVELOPMENT (Sep 2
> > snapshot) on my Compaq 301TU laptop.
> >
> > The Realtek NIC card does not seem to be working,
> > although the following lines are seen in dmesg output
> >
> > rl0: <Realtek 8139 10/100BaseTX> port 0x2000-0x20ff mem
> > 0xd0100000-0xd01000ff irq 11 at device 8.0 at pci8
> > rl0: unknown device ID: fff
> > device_probe_and_attach: rl0 attach returned 6
>
> Does the attached patch work for you?
>
> Best Regards,
> sephe
>
Hi Sephe:
Thanks for sending in the patch. i applied the patch to 2.4.1
src/sys/dev/netif/if_rl.c .
After compiling the native kernel, the device is detected and
attached.
The dmesg log shows the following lines:
rl0.pci8.pcib3.pci0.pcib0.legacy0.nexus0.root0
rl0: <RealTek 8139 10/100BaseTX> [tentative] port 0x2000-0x20ff
mem 0xd0100000-0xd01000ff irq 11 at device 8.0 on pci8
rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000
miibus0.rl0.pci8.pcib3.pci0.pcib0.legacy0.nexus0.root0
miibus0: <MII bus> [tentative] on rl0
rlphy0.miibus0.rl0.pci8.pcib3.pci0.pcib0.legacy0.nexus0.root0
miibus0: <MII bus> [attached!] on rl0
rl0: bpf attached
rl0: MAC address: ff:ff:ff:ff:ff:ff
rl0: <RealTek 8139 10/100BaseTX> [attached!] port 0x2000-0x20ff
mem 0xd0100000-0xd01000ff irq 11 at device 8.0 on pci8
This looks promising and so i try to run a DHCP client.
# dhclient rl0
and an IP address 10.10.10.7 is assigned
bound to 10.10.10.7 -- renewal in 43200 seconds
#ifconfig rl0
shows the ether as ff:ff:ff:ff:ff:ff and inet as 10.10.10.7
Now, if i run the DHCP client again,
#dhclient rl0
another DHCP offer is received and a new IP address 10.10.10.8
is assigned
To summarize, everytime i run 'dhclient rl0' a new DHCP IP
address is assigned but no traffic is seen while pinging the
dateway..
This looks like a bug in the driver code.
Perhaps the fact that the ether MAC continues to be
ff:ff:ff:ff:ff:ff suggests that we may need to extract the
ethernet address as well.
i've a laptop with identical hardware, running FreeBSD
8-CURRENT-200906 (ie. this one, used to write this mail)
and the following lines are seen in the driver code
src/sys/pci/if_rl.c
. ..
if (sc->rl_type == 0) {
device_printf(dev, "unknown device ID: %x assuming 8139\n",
rl_did);
sc->rl_type = RL_8139;
/*
* Read RL_IDR register to get ethernet address as accessing
* EEPROM may not extract correct address.
*/
for (i = 0; i < ETHER_ADDR_LEN; i++)
eaddr[i] = CSR_READ_1(sc, RL_IDR0 + i);
}
. ..
What do you think ?
thanks
Saifi.
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]