Re: [RFT] Realtek 8168 ethernet support
Hi Francois, Francois Romieu wrote: Despite the fact that the newer 8168 has been reported to only work with an extra alignment (gross hack: s/NET_IP_ALIGN/8/), the serie seems otherwise fine. I'll submit an updated serie to correctly support the 8168. Any word on the updated 8168 patch? Would love to get that supported in Gentoo's upcoming release media, if the patch is ready. Thanks! Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Francois Romieu [EMAIL PROTECTED] :
The patch below agaisnt 2.6.17-rc6 includes the following changes:
commit 3072cc0aba3ac0c944e196a63c4154ca5746ec0b
r8169: sync with vendor's driver
- add several PCI ID for the PCI-E adapters ;
- new identification strings ;
- the RTL_GIGA_MAC_VER_ defines have been renamed to closely match the
out-of-tree driver. It makes the comparison less hairy ;
- various magic ;
- the PCI region for the device with PCI ID 0x8136 is guessed.
Explanation: the in-kernel Linux driver is written to allow MM register
accesses and avoid the IO tax. The relevant BAR register was found at
base address 1 for the plain-old PCI 8169. User reported lspci show that
it is found at base address 2 for the new Gigabit PCI-E 816{8/9}.
Despite the fact that the newer 8168 has been reported to only work with an
extra alignment (gross hack: s/NET_IP_ALIGN/8/), the serie seems otherwise
fine.
I'll submit an updated serie to correctly support the 8168.
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Hi, sorry for the delayed response... On 13/06/06 00:29, Francois Romieu wrote: wget goes faster, right ? Do you have some vmstat 1 output at hand for it ? It does indeed go faster, and it seems a little bit more reliable, but with big enough transfers it locks up too. See commandline-2.txt and vmstat-2.txt - it gets through around 600-700MB before locking up. I also noticed that at 3-4 points during the transfer it seemed to pause, and then continue. Ok but can you set correctly the link with the command which was told to fail in you first mail ? The patch could fix it. Yes, indeed: doing ethtool -s eth0 speed 10 autoneg off switches it to the slow speed, and keeps it there too (at 10Mb/s). ethtool eth0 still reports Advertised auto-negotiation: Yes and Auto-negotiation: on, which is probably not right. It also reports Advertised link modes: 10baseT/Full only, which is probably correct. It only actually restarts auto-negotiation when I issue the command ethtool -s eth0 autoneg on, at which point the speeds goes back up to 1000Mb/s - the expected behaviour. So it seems ethtool works better than before wrt auto-negotiation. Can you try something like: dd if=/dev/zero bs=1024k count=1000 | ssh -c blowfish hell dd of=/tmp/1000m.bin Well this transfer (from shuttle - hell) completed successfully. See commandline-3.txt and vmstat-3.txt; However I noticed the speed was only around 7 MB/s and wondered if the link speed was maybe set to 100Mb/s, so I immediately afterwards did a wget-test again, which locked up after only 5%. The wget test however did confirm the link speed to be 1000Mb/s. See commandline-4.txt and vmstat-4.txt for that last, short test. May I assume that the freeze locks everything (keyboard, mouse, led) beyond the scp command itself ? Yes indeed. My (usb) keyboard doesn't respond at all anymore, networking is completely out, (usb) mouse freezes too. SysRq doesn't seem to help much either. -- Mourad shuttle:~# wget http://hell/testfile.bin --18:39:21-- http://hell/testfile.bin = `testfile.bin' Resolving hell... 10.10.1.1 Connecting to hell|10.10.1.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,073,741,824 (1.0G) [application/octet-stream] 56% [ ] 602,018,040 27.70M/sETA 00:17 shuttle:~# dd if=/dev/zero bs=1024k count=1000 | ssh -c blowfish hell dd of=/tmp/1000m.bin Password: 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 155.971 seconds, 6.7 MB/s 2047951+99 records in 2048000+0 records out 1048576000 bytes (1.0 GB) copied, 140.689 seconds, 7.5 MB/s shuttle:~# shuttle:~# wget http://hell/testfile.bin --18:57:26-- http://hell/testfile.bin = `testfile.bin' Resolving hell... 10.10.1.1 Connecting to hell|10.10.1.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,073,741,824 (1.0G) [application/octet-stream] 5% [] 57,266,17630.30M/s shuttle:~# vmstat 1 procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 0 0 0 983108 4672 29140003311 45264 1 6 92 1 0 0 0 983108 4672 2914000 0 0 45818 0 2 98 0 0 0 0 982556 4688 2958800 464 0 49265 1 2 90 7 0 0 0 981316 4692 3072000 0 0 2029 162 0 2 98 0 0 0 0 951804 4724 5932400 0 0 38927 3128 1 42 57 0 0 1 0 911380 4764 9652800 4 66940 50360 10405 3 63 33 1 0 1 0 875916 4796 13171600 0 0 41138 4251 5 69 0 26 1 1 0 842684 4828 16480400 0 0 38724 4368 3 66 0 31 1 1 0 807468 4872 19929600 0 204 43170 4254 4 59 9 28 1 0 0 772748 4908 23277200 4 32516 39246 4071 3 67 22 8 0 2 0 737656 4940 26625600 0 97720 38868 4612 4 66 30 0 0 2 0 737532 4940 26625600 0 32768 66323 0 5 0 95 0 2 0 738772 4940 26625600 0 6724 55119 0 3 0 97 1 1 0 718436 4972 28860800 0 196 26291 2494 3 47 1 49 0 0 0 676276 5012 32910800 0 0 54791 4380 3 59 2 36 0 2 0 639944 5048 36237600 4 81856 44893 7185 2 54 9 35 0 2 0 640564 5048 36237600 0 14268 61819 0 2 0 98 0 2 0 641928 5048 36237600 024 55318 0 2 0 98 0 1 0 608944 5088 39601600 0 128 45004 9135 4 52 6 38 0 1 0 571868 5124 43154400 0 0 47833 9603 2 59 12 27 1 1 0 529212 5160 47110400 0 84548 52399 4222 2 61 5 32 1 3 0 493500 5200 50649200 4 16384 40790 4236 6 74 0 20 0 3 0 459276 5232 54068400
Re: [RFT] Realtek 8168 ethernet support
On 12/06/06 01:30, Francois Romieu wrote: The patch below agaisnt 2.6.17-rc6 includes the following changes: Just FYI: I just tried this patch set, but it doesn't do anything for the freeze at high speed I mentioned on 2006-06-09. It still locks up. (As an additional data point: I installed win2k on this machine, and it seems to have no problems transferring at high speeds. Just wanted to try to rule out faulty hardware.) Thanks, -- Mourad DC - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Mourad De Clerck [EMAIL PROTECTED] : [...] I just tried this patch set, but it doesn't do anything for the freeze at high speed I mentioned on 2006-06-09. It still locks up. (As an additional data point: I installed win2k on this machine, and it seems to have no problems transferring at high speeds. Just wanted to try to rule out faulty hardware.) Please send .config and complete dmesg (starting with 'Linux version ...'). The output of a 'vmstat 1' until it freezes could give some hint. So could trying a different PCI slot. How do you generate traffic ? 15Mo/s of usual traffic means roughly 1000pps. It is not really high speed. Unrelated: have you checked the link setting ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Mourad De Clerck [EMAIL PROTECTED] : [...] I do notice a pattern with more and less complicated/cpu intensive traffic: using http (wget) I manage to finish doing the transfer of the same reasonably big file. With scp I only manage to get to 90% of that file before it freezes - I should still test whether I can get a http transfer to lock up if I use a (much) bigger file. wget goes faster, right ? Do you have some vmstat 1 output at hand for it ? [...] Unrelated: have you checked the link setting ? ethtool reports Link detected: yes and so does my switch. Ok but can you set correctly the link with the command which was told to fail in you first mail ? The patch could fix it. [...] shuttle:~# scp hell:/srv/bigfile.bin . bigfile.bin 90% 155MB 17.5MB/s 00:00 ETA Can you try something like: dd if=/dev/zero bs=1024k count=1000 | ssh -c blowfish hell dd of=/tmp/1000m.bin May I assume that the freeze locks everything (keyboard, mouse, led) beyond the scp command itself ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
The patch below agaisnt 2.6.17-rc6 includes the following changes:
commit 3072cc0aba3ac0c944e196a63c4154ca5746ec0b
r8169: sync with vendor's driver
- add several PCI ID for the PCI-E adapters ;
- new identification strings ;
- the RTL_GIGA_MAC_VER_ defines have been renamed to closely match the
out-of-tree driver. It makes the comparison less hairy ;
- various magic ;
- the PCI region for the device with PCI ID 0x8136 is guessed.
Explanation: the in-kernel Linux driver is written to allow MM register
accesses and avoid the IO tax. The relevant BAR register was found at
base address 1 for the plain-old PCI 8169. User reported lspci show that
it is found at base address 2 for the new Gigabit PCI-E 816{8/9}.
Typically:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown
device 8168 (rev 01)
Subsystem: Unknown device 1631:e015
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0, cache line size 20
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at b800 [size=256]
Region 2: Memory at ff7ff000 (64-bit, non-prefetchable) [size=4K]
So far I have not received any lspci report for the 0x8136 and
Realtek's driver do not help: be it under BSD or Linux, their r1000 driver
include a USE_IO_SPACE #define but the bar address is always hardcoded
to 1 in the MM case. :o/
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
commit 33857396c4f7d171f4ccaca86356df5fe2fdd304
r8169: remove rtl8169_init_board
Rationale:
- its signature is not exactly pretty;
- it has no knowledge of pci_device_id;
- kiss 23 lines good bye.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
commit af50f4372644c3c18c2af697a933c90f2a96be77
r8169: hardware flow control
The datasheet suggests that the device handles the hardware flow
control almost automagically. User report a different story, so
let's try to twiddle the mii registers.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
commit d1e6ebbea2297df970e52823e1d8c9af62b0548d
r8169: RX fifo overflow recovery
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
commit 17fb3bf33149eb2cb1a37ff94ab236ab01f91a40
r8169: mac address change support
Fix for http://bugzilla.kernel.org/show_bug.cgi?id=6032.
Cc: Tim Mattox [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
The patch is for review only: mac address change apart, I need to
test it and it will surely conflict with jeff#netdev because of a
recently added PCI ID.
The patches are available at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.17-rc6/r8169
or:
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git r8169
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 0ad3310..53a33c5 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -150,11 +150,16 @@ #define RTL_R16(reg) readw (ioaddr + (r
#define RTL_R32(reg) ((unsigned long) readl (ioaddr + (reg)))
enum mac_version {
- RTL_GIGA_MAC_VER_B = 0x00,
- /* RTL_GIGA_MAC_VER_C = 0x03, */
- RTL_GIGA_MAC_VER_D = 0x01,
- RTL_GIGA_MAC_VER_E = 0x02,
- RTL_GIGA_MAC_VER_X = 0x04 /* Greater than RTL_GIGA_MAC_VER_E */
+ RTL_GIGA_MAC_VER_01 = 0x00,
+ RTL_GIGA_MAC_VER_02 = 0x01,
+ RTL_GIGA_MAC_VER_03 = 0x02,
+ RTL_GIGA_MAC_VER_04 = 0x03,
+ RTL_GIGA_MAC_VER_05 = 0x04,
+ RTL_GIGA_MAC_VER_11 = 0x0b,
+ RTL_GIGA_MAC_VER_12 = 0x0c,
+ RTL_GIGA_MAC_VER_13 = 0x0d,
+ RTL_GIGA_MAC_VER_14 = 0x0e,
+ RTL_GIGA_MAC_VER_15 = 0x0f
};
enum phy_version {
@@ -166,7 +171,6 @@ enum phy_version {
RTL_GIGA_PHY_VER_H = 0x08, /* PHY Reg 0x03 bit0-3 == 0x0003 */
};
-
#define _R(NAME,MAC,MASK) \
{ .name = NAME, .mac_version = MAC, .RxConfigMask = MASK }
@@ -175,18 +179,28 @@ static const struct {
u8 mac_version;
u32 RxConfigMask; /* Clears the bits supported by this chip */
} rtl_chip_info[] = {
- _R(RTL8169, RTL_GIGA_MAC_VER_B, 0xff7e1880),
- _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_D, 0xff7e1880),
- _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_E, 0xff7e1880),
- _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_X, 0xff7e1880),
+ _R(RTL8169, RTL_GIGA_MAC_VER_01, 0xff7e1880),
+ _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_02, 0xff7e1880),
+ _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_03, 0xff7e1880),
+ _R(RTL8169sb/8110sb, RTL_GIGA_MAC_VER_04, 0xff7e1880),
+ _R(RTL8169sc/8110sc, RTL_GIGA_MAC_VER_05, 0xff7e1880),
+ _R(RTL8168b/8111b,RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
+
Re: [RFT] Realtek 8168 ethernet support
Jeff Garzik [EMAIL PROTECTED] :
Francois Romieu wrote:
Jeff Garzik [EMAIL PROTECTED] :
Randy.Dunlap wrote:
Conversely, any reason to use the RealTek r1000 driver?
FWIW, RealTek emailed me about merging r1000. I suggested that, if the
Which one ?
r1000_n.c where #define RELEASE_DATE 2006/02/23
They didn't say. Just r1000
Can you ask your Realtek person if he is really sure about the following
snippet in r1000_n.c::r1000_init_one:
if((priv-mcfg!=MCFG_METHOD_13)(priv-mcfg!=MCFG_METHOD_14)(priv-mcfg!=MCFG_METHOD_15))
printk(This Realtek NIC doesn't support 1000Mbps\n);
else
Cap1000 = PHY_Cap_1000_Full|PHY_Cap_1000_Half;
- in forced 1000 mode, 1000_{Half/Full} would only be written to the
advertisement register for MCFG_METHOD_1{3/4/5}. It excludes all
the adapters that the in-kernel driver support (huh ?).
Later in the same function:
[...]
if(( priv-mcfg == MCFG_METHOD_11 )||( priv-mcfg == MCFG_METHOD_12 ))
printk(Realtek RTL8168/8111 Family PCI-E Gigabit Ethernet
Network Adapter\n);
else
if((priv-mcfg==MCFG_METHOD_13)||(priv-mcfg==MCFG_METHOD_14)||(priv-mcfg==MCFG_METHOD_15))
printk(Realtek RTL8139/810x Family Fast Ethernet Network
Adapter\n);
- the != ... ... != test above seems inverted.
Btw, it would be nice if he could confirm that the 0x10ec/0x8129 ID
sent by Yoichi Yuasa is really allowed (and not a random bitflip).
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Francois Romieu [EMAIL PROTECTED] : [...] - the != ... ... != test above seems inverted. Answering to myself: yes, it is. The 8100 and 8101 are PCI Express fast ethernet only (but they should do 802.1q, go figure). -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Jeff Garzik [EMAIL PROTECTED] : Randy.Dunlap wrote: Conversely, any reason to use the RealTek r1000 driver? FWIW, RealTek emailed me about merging r1000. I suggested that, if the Which one ? r1000_n.c where #define RELEASE_DATE 2006/02/23 -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Francois Romieu wrote: Jeff Garzik [EMAIL PROTECTED] : Randy.Dunlap wrote: Conversely, any reason to use the RealTek r1000 driver? FWIW, RealTek emailed me about merging r1000. I suggested that, if the Which one ? r1000_n.c where #define RELEASE_DATE 2006/02/23 They didn't say. Just r1000 Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
On Thu, 1 Jun 2006 21:02:00 +0100 (BST) Daniel Drake wrote:
I've produced this patch which should allow the r8169 driver to work with the
new Realtek 8168 chips. These are found in PCI-Express form and onboard some
newer motherboards.
Does anyone own this hardware? I'm looking for someone to test it before I
send it on.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux/drivers/net/r8169.c
===
--- linux.orig/drivers/net/r8169.c
+++ linux/drivers/net/r8169.c
@@ -184,6 +184,7 @@ static const struct {
static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
{ PCI_DEVICE(0x16ec,0x0116), },
{ PCI_VENDOR_ID_LINKSYS,0x1032, PCI_ANY_ID, 0x0024, },
The (GPL) RealTek driver (from
http://www.realtek.com.tw/downloads/downloads1-3.aspx?lineid=1famid=4series=2003072Software=True)
contains this PCI device table:
static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
{ 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{0,}
};
Any reason not to include all of those?
Conversely, any reason to use the RealTek r1000 driver?
@@ -1398,6 +1399,7 @@ rtl8169_init_board(struct pci_dev *pdev,
struct net_device *dev;
struct rtl8169_private *tp;
int rc = -ENOMEM, i, acpi_idle_state = 0, pm_cap;
+ u32 mmio_base = 0;
assert(ioaddr_out != NULL);
@@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
}
}
- /* make sure PCI base addr 1 is MMIO */
- if (!(pci_resource_flags(pdev, 1) IORESOURCE_MEM)) {
- if (netif_msg_probe(tp)) {
- printk(KERN_ERR PFX
-region #1 not an MMIO resource, aborting\n);
- }
- rc = -ENODEV;
- goto err_out_mwi;
+ /* find MMIO resource: this varies between 8168 and 8169 */
+ for (i = 0; i 5; i++) {
+ /* check resource type */
+ if (!(pci_resource_flags(pdev, i) IORESOURCE_MEM))
+ continue;
+
+ /* check for weird/broken PCI region reporting */
+ if (pci_resource_len(pdev, i) R8169_REGS_SIZE)
+ continue;
+
+ mmio_base = pci_resource_start(pdev, i);
+ break;
}
- /* check for weird/broken PCI region reporting */
- if (pci_resource_len(pdev, 1) R8169_REGS_SIZE) {
+
+ if (mmio_base == 0) {
if (netif_msg_probe(tp)) {
printk(KERN_ERR PFX
-Invalid PCI region size(s), aborting\n);
+couldn't find valid MMIO resource, aborting\n);
}
rc = -ENODEV;
goto err_out_mwi;
@@ -1490,7 +1496,7 @@ rtl8169_init_board(struct pci_dev *pdev,
pci_set_master(pdev);
/* ioremap MMIO region */
- ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE);
+ ioaddr = ioremap(mmio_base, R8169_REGS_SIZE);
if (ioaddr == NULL) {
if (netif_msg_probe(tp))
printk(KERN_ERR PFX cannot remap MMIO, aborting\n);
-
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Randy.Dunlap [EMAIL PROTECTED] :
[...]
static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
{ 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{0,}
};
Any reason not to include all of those?
Nothing worrying:
- 0x8167 and 0x8168 use a different PCI region;
- some phy differences. They appear when the r1000 driver is
compared to the previous r8169 driver from realtek.
I'll pack it with other changes.
Conversely, any reason to use the RealTek r1000 driver?
Feel free to read it and make your own mind.
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Randy.Dunlap wrote: Conversely, any reason to use the RealTek r1000 driver? FWIW, RealTek emailed me about merging r1000. I suggested that, if the register sets were similar, that r8169 should be updated instead, to preserve compatibility with existing users (and not lose existing work). Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
On Thu, 08 Jun 2006 22:40:05 -0400 Jeff Garzik wrote: Randy.Dunlap wrote: Conversely, any reason to use the RealTek r1000 driver? FWIW, RealTek emailed me about merging r1000. I suggested that, if the register sets were similar, that r8169 should be updated instead, to preserve compatibility with existing users (and not lose existing work). Sounds good to me. I'm not terribly interested in seeing multiple drivers for the same hardware in the kernel tree. --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT] Realtek 8168 ethernet support
I've produced this patch which should allow the r8169 driver to work with the
new Realtek 8168 chips. These are found in PCI-Express form and onboard some
newer motherboards.
Does anyone own this hardware? I'm looking for someone to test it before I
send it on.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux/drivers/net/r8169.c
===
--- linux.orig/drivers/net/r8169.c
+++ linux/drivers/net/r8169.c
@@ -184,6 +184,7 @@ static const struct {
static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
{ PCI_DEVICE(0x16ec,0x0116), },
{ PCI_VENDOR_ID_LINKSYS,0x1032, PCI_ANY_ID, 0x0024, },
@@ -1398,6 +1399,7 @@ rtl8169_init_board(struct pci_dev *pdev,
struct net_device *dev;
struct rtl8169_private *tp;
int rc = -ENOMEM, i, acpi_idle_state = 0, pm_cap;
+ u32 mmio_base = 0;
assert(ioaddr_out != NULL);
@@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
}
}
- /* make sure PCI base addr 1 is MMIO */
- if (!(pci_resource_flags(pdev, 1) IORESOURCE_MEM)) {
- if (netif_msg_probe(tp)) {
- printk(KERN_ERR PFX
- region #1 not an MMIO resource, aborting\n);
- }
- rc = -ENODEV;
- goto err_out_mwi;
+ /* find MMIO resource: this varies between 8168 and 8169 */
+ for (i = 0; i 5; i++) {
+ /* check resource type */
+ if (!(pci_resource_flags(pdev, i) IORESOURCE_MEM))
+ continue;
+
+ /* check for weird/broken PCI region reporting */
+ if (pci_resource_len(pdev, i) R8169_REGS_SIZE)
+ continue;
+
+ mmio_base = pci_resource_start(pdev, i);
+ break;
}
- /* check for weird/broken PCI region reporting */
- if (pci_resource_len(pdev, 1) R8169_REGS_SIZE) {
+
+ if (mmio_base == 0) {
if (netif_msg_probe(tp)) {
printk(KERN_ERR PFX
- Invalid PCI region size(s), aborting\n);
+ couldn't find valid MMIO resource, aborting\n);
}
rc = -ENODEV;
goto err_out_mwi;
@@ -1490,7 +1496,7 @@ rtl8169_init_board(struct pci_dev *pdev,
pci_set_master(pdev);
/* ioremap MMIO region */
- ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE);
+ ioaddr = ioremap(mmio_base, R8169_REGS_SIZE);
if (ioaddr == NULL) {
if (netif_msg_probe(tp))
printk(KERN_ERR PFX cannot remap MMIO, aborting\n);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Daniel Drake [EMAIL PROTECTED] :
[...]
@@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
}
}
- /* make sure PCI base addr 1 is MMIO */
- if (!(pci_resource_flags(pdev, 1) IORESOURCE_MEM)) {
- if (netif_msg_probe(tp)) {
- printk(KERN_ERR PFX
-region #1 not an MMIO resource, aborting\n);
- }
- rc = -ENODEV;
- goto err_out_mwi;
+ /* find MMIO resource: this varies between 8168 and 8169 */
+ for (i = 0; i 5; i++) {
I'd rather use pci_device_id-driver_data but it's an option.
Btw a 0x8167 may be encountered too.
A diff between latest versions of Realtek's code suggests that
rtl_chip_info and mac_info need an update as well.
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
On Fri, Jun 02, 2006 at 12:24:37AM +0200, Francois Romieu wrote: I'd rather use pci_device_id-driver_data but it's an option. I would prefer this, too. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
