Heiner Kallweit :
> pci_set_drvdata() is called only after registering the net_device,
> therefore we could run into a NPE if one of the functions using
> driver_data is called before it's set.
>
> Fix this by calling pci_set_drvdata() before registering the
> net_device.
>
> This fix is a candi
Andrew Lunn :
[...]
> How about rtl8169_get_wol() and rtl8169_set_wol(). And
> rtl8169_get_ethtool_stats().
rtl8169_get_wol does not depend on dev->driver_data. Neither does
rtl8169_set_wol() nor rtl8169_get_ethtool_stats().
> Basically anything which makes use of run time power management
> cou
Daniel Drake :
[...]
> Also, is there a standard behaviour defined for ethernet drivers
> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
> if it believes the hardware is capable of it,
If so it isn't its designed behavior.
The r8169 driver does not enable specific WoL even
Heiner Kallweit :
[...]
> Last but not least it enables a feature which was (I presume accidently)
> disabled before. There are members of the RTL8169 family supporting MSI
> (e.g. RTL8169SB), however MSI never got enabled because RTL_CFG_0 was
> missing flag RTL_FEATURE_MSI.
> An indicator for "a
Amine Kherbouche :
[...]
> diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
> index 36ea2ad..060ed07 100644
> --- a/net/mpls/af_mpls.c
> +++ b/net/mpls/af_mpls.c
[...]
> @@ -39,6 +40,40 @@ static int one = 1;
> static int label_limit = (1 << 20) - 1;
> static int ttl_max = 255;
>
> +size_t
Holger Hoffstätte :
[...]
> I continued to use the BQL patch in my private tree after it was reverted
> and also had occasional timeouts, but *only* after I started playing
> with ethtool to change offload settings. Without offloads or the BQL patch
> everything has been rock-solid since then.
> T
Heiner Kallweit :
[...]
> This issue has been there more or less forever (at least it exists in
> 3.16 already), so I can't provide a "Fixes" tag.
Hardly forever. It fixes da78dbff2e05630921c551dbbc70a4b7981a8fff.
--
Ueimor
Eric Dumazet :
[...]
> One has to wonder why rtl8169_poll(), which might be called in a loop under
> DOS,
> has to call rtl_ack_events() ?
So as to cover a wider temporal range before any event can trigger an
extra irq. I was more worried about irq cost than about IO cost (and
I still am).
--
Eric Dumazet :
> On 10/18/2018 03:59 PM, Francois Romieu wrote:
> > Eric Dumazet :
> > [...]
> >> One has to wonder why rtl8169_poll(), which might be called in a loop
> >> under DOS,
> >> has to call rtl_ack_events() ?
> >
> > So as to cov
Heiner Kallweit :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 75dfac024..1eb4f625a 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7327,9 +7327,9 @@ static void __rtl8169_resume(s
David Miller :
> From: Heiner Kallweit
> Date: Mon, 21 May 2018 19:01:19 +0200
>
> > The driver uses pm_runtime_get_sync() in few places and relies on the
> > device being fully runtime-resumed after this call. So far however
> > the runtime resume callback triggers an asynchronous reset.
> > A
David Miller :
[...]
> The amount of coverage this change is going to get is very small as
> well, meaning an even greater chance of regressions.
Yes.
> Therefore the only acceptable way to handle this is to have
> a white-list, specific chips that have been explicitly tested
> and are known to
= pdev;" to dscc4_found1() but this driver has
> been broken since before we started using git and no one has complained
> so probably we should just remove it.
>
> Signed-off-by: Dan Carpenter
Acked-by: Francois Romieu
--
Ueimor
Aviad Krawczyk :
[...]
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
> b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
> new file mode 100644
> index 000..fbc9de4
> --- /dev/null
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
[...]
> +/**
> + * hinic_init_hwdev
Aviad Krawczyk :
[...]
> hinic_remove - If insmod failed and someone calls rmmod, we will get a
> crash because the resource are already free. Therefore we test if the
> device exists, please tell me if you meant to something different
The module won't even proceed through the pci_driver remove m
Aviad Krawczyk :
[...]
> module_pci_driver - is not used in other drivers in the same segments, it
> is necessary ?
/me checks... Ok, there seems to be some overenthusiastic copy'paste.
See drivers/net/ethernet/intel/ixgb/ixgb_main.c:
[...]
/**
* ixgb_init_module - Driver Registration Routine
Benoit Panizzon :
[...]
> It's not marked as fixed but:
>
> when I try to turn offloading off I get:
>
> # /sbin/ethtool -K eth0 rx-vlan-offload off
> ethtool: bad command line argument(s)
> For more information run ethtool -h
>
> Could anyone give me a hint how to further debug the problem or
Peter Zijlstra :
[...]
> There is only 1 variable afaict. Memory barriers need at least 2 in
> order to be able to do _anything_.
I don't get your point: why don't {cur_tx, dirty_tx} qualify as said
two variables ?
--
Ueimor
Jia-Ju Bai :
[...]
> The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
> if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
> netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
> goto err_stop_0;
> }
> But there is no
Peter Zijlstra :
> On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote:
> > Peter Zijlstra :
> > [...]
> > > There is only 1 variable afaict. Memory barriers need at least 2 in
> > > order to be able to do _anything_.
> >
> > I don&
Jia-Ju Bai :
>
> On 2018/1/19 9:11, Francois Romieu wrote:
> > Jia-Ju Bai :
> > [...]
> > > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
> > > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
>
Oliver Freyermuth :
[...]
Is it an AMD based system ?
--
Ueimor
Oliver Freyermuth :
> Am 21.01.2018 um 21:48 schrieb Francois Romieu:
> > Oliver Freyermuth :
[...]
> > Is it an AMD based system ?
> >
>
> No, all the systems on which I have observed this up to now are Intel-based.
> Two Haswell and one Sandy Bridge sy
Oliver Freyermuth :
[...]
> This looks like it could very well match the structure found in memory,
> so something would be broken related to rtl8169_do_counters, in the DMA
> transfer.
>
> Does this help - can I provide more info? I get the feeling this affects
> many tens of thousands of syste
Hardware statistics retrieval hurts in tight invocation loops.
Avoid extraneous write and enforce strict ordering of writes targeted to
the tally counters dump area address registers.
Signed-off-by: Francois Romieu
Tested-by: Oliver Freyermuth
---
drivers/net/ethernet/realtek/r8169.c | 9
Chunhao Lin :
[...]
> @@ -5878,6 +5881,20 @@ static void rtl_pcie_state_l2l3_enable(struct
> rtl8169_private *tp, bool enable)
> RTL_W8(Config3, data);
> }
>
> +static void rtl_hw_internal_aspm_clkreq_enable(struct rtl8169_private *tp,
> + bool enable)
> +{
>
net-next is closed anyway.
--
Ueimor
Alexey Khoroshilov :
> The driver does not check if mapping dma memory succeed.
> The patch adds the checks and failure handling.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
Please amend your subject line as:
Subject: [PATCH net-nex
Alexey Khoroshilov :
[...]
> diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
> index 799830f..6a9ffac 100644
> --- a/drivers/net/wan/dscc4.c
> +++ b/drivers/net/wan/dscc4.c
> @@ -518,23 +518,31 @@ static void dscc4_release_ring(struct dscc4_dev_priv
> *dpriv)
> static inline int t
Murali Karicheri :
[...]
> The internal memory or FIFO can store only up to 3 MTU sized packets. So that
> has to
> be processed before PRU gets another packets to send to CPU. So per above,
> it is not ideal to run NAPI for this scenario, right? Also for NetCP we use
> about 128 descriptors wit
Alexey Khoroshilov :
[...]
> diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
> index 8480dbf..a043fb1 100644
> --- a/drivers/net/wan/dscc4.c
> +++ b/drivers/net/wan/dscc4.c
[...]
> @@ -506,8 +506,9 @@ static void dscc4_release_ring(struct dscc4_dev_priv
> *dpriv)
> skbuff = d
David Miller :
[...]
> Oops, this will need to be sent as a relative fixup as I've applied these
> two patches to net-next, sorry Francois.
No problem. It works perfectly this way.
--
Ueimor
David Miller :
> From: Joshua Emele
> Date: Wed, 24 May 2017 15:43:18 -0700
[...]
> > The sky2_hw_down uses sky2_tx_complete to free pending frames stuck in
> > the HW queue. Because sky2_hw_down can be called from a process context,
> > the call to u64_stats_update_begin can result in deadlock.
Kirill Smelkov :
[...]
> I was keeping you in To and Cc all the time but got no reply at all since my
> first posting from ~ 1 month ago.
I thought it was longer than that. Sorry for the frustrating excess delay.
As Eric already said there is no problem and I am perfectly fine with
the current a
Stephen Hemminger <[EMAIL PROTECTED]> :
???...]
> Better to just get rid of using the lock as a transmit lock and
> use netif_tx_lock instead.
> --- a/drivers/net/b44.c 2007-05-29 09:51:43.0 -0700
> +++ b/drivers/net/b44.c 2007-05-29 14:26:03.0 -0700
> @@ -607,6 +607,7 @
Emmanuel Fusté <[EMAIL PROTECTED]> :
[..]
> Could this bug fix from Stephen Hemminger be another track to follow ?
> http://marc.info/?l=linux-netdev&m=118048588011069&w=2
> If you think so, I could give it a try whitout applying the
> "spin_lock_irqsave" patch.
You can apply it too but Stephen's
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Rolf Eike Beer <[EMAIL PROTECTED]>
---
realtek.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/realtek.c b/realtek.c
index 8daba69..c56b3f5 100644
--- a/realtek.c
+++ b/realtek.c
@@ -46,6 +46,7 @@ s
Francois Romieu <[EMAIL PROTECTED]> :
[...]
Andrew, have you had any time to do some testing with an uniform 7200
bytes MTU through your LAN ?
You will find a backport of the r8169 driver for the 2.6.18 kernel at
http://www.fr.zoreil.com/people/francois/backport/r8169/20070604-00
Could yo
Rolf Eike Beer <[EMAIL PROTECTED]> :
[...]
> I just had another freeze using your patches. After 512kB over smb it was
> dead.
In-kernel smb/cifs ?
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Kacper Bielecki <[EMAIL PROTECTED]> :
[...]
> The motherboadr is ASRock ConRoe945G-DVI
Same model as my current test machine.
It uses a boring el-cheapo PIV though.
> After installing kernel 2.6.22-rc4 with patches 0001..0013 (there wasn't
> patch) the problem is not solved. I still get th
Emmanuel Fusté <[EMAIL PROTECTED]> :
[...]
> Did you plan to submit the "spin_lock_irqsave" patch to mainline ?
No. I will not have enough time to figure why/if it fixes things.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTE
Rolf Eike Beer <[EMAIL PROTECTED]> :
[...]
> fine. Even the next try with this file didn't produce a crash. What was
> different on this tests was that I used the console instead of X (don't want
> to munch up too many file systems). Any ideas?
X and friends ?
Can you send the usual dmesg, lspc
Benjamin LaHaise <[EMAIL PROTECTED]> :
[...]
> I'm seeing something odd with r8169 on FC7: doing a ping -s 1600 alternates
> between a 1s latency and sub 1ms. Has anyone else seen anything like this?
> The system in question is an Asus M2A-VM with an onboard RTL8111 (I think).
> NAPI doesn't
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[...]
> Please review and provide comments.
o ixgbe_call_func and the ton of wrappers which go along with it
should go.
o boolean_t duplicates the existing 'bool'
o The options below {should be/are} handled through ethtool:
- TxDescriptors
- RxDescri
David Gundersen <[EMAIL PROTECTED]> :
[...]
> I've been doing a bit of investigation work into a problem that I've
> been experiencing with the latest available r8168 driver from realtek
> ('r8168-8.001.00') & linux kernel 2.6.21.1.
>
> I have been experiencing wierd problems with slow outbound
Ayyappan Veeraiyan <[EMAIL PROTECTED]> :
[...]
> netpoll_send_skb should not deadlock because ixgbe_xmit_frame should
> bail out because of this...
>
> if (!spin_trylock_irqsave(&tx_ring->tx_lock, flags))
> /* Collision - tell upper layer to requeue */
> return NET
David Gundersen <[EMAIL PROTECTED]> :
[...]
> I might do some more thorough testing on the weekend to find out what
> the minimal changes required are to get things working.
In your patch, the first chunk of data (which is handed back to the
nic outside of rtl8169_xmit_frags) will not have is Firs
Tim Durack <[EMAIL PROTECTED]> :
[snip]
Can you try 2.6.22-rc5 +
http://www.fr.zoreil.com/people/francois/misc/20070619-2.6.22-rc5-r8169-test.patch
It does not seem to work too bad here (tested with 2.6.22-rc5 + patch):
# grep bonding /etc/modprobe.conf
alias bond0 bonding
options bonding miimon
Francois Romieu <[EMAIL PROTECTED]> :
[...]
> A pesky fever apart, I should be able to come with a patch before
> the week end.
(oops, late again)
You can try the hack below as a temporary fix.
It makes things way better on top of 2.6.22-rc5 + current r8169 patchkit at
http://www.f
David Gundersen <[EMAIL PROTECTED]> :
[...]
> - Why are you checking dirty_tx against cur_rx (shouldn't it be cur_tx?)?
Usual "try something, send something else" bug.
> - Is there a possibility that the driver could be triggering the card to
> send invalid packets with that code?
[snip]
I do n
Thomas Bogendoerfer <[EMAIL PROTECTED]> :
[...]
> +static inline void init_rx_bufs(struct net_device *dev)
> +{
> + struct i596_private *lp = netdev_priv(dev);
> + struct i596_dma *dma = lp->dma;
> + int i;
> + struct i596_rfd *rfd;
> + struct i596_rbd *rbd;
> +
> + /* First
Thomas Bogendoerfer <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/net/sni_82596.c b/drivers/net/sni_82596.c
> new file mode 100644
> index 000..80e32ad
> --- /dev/null
> +++ b/drivers/net/sni_82596.c
[...]
> +static int __devinit sni_82596_probe(struct platform_device *dev)
> +{
[...]
> +
Thomas Bogendoerfer <[EMAIL PROTECTED]> :
> On Tue, Jun 26, 2007 at 11:47:55PM +0200, Francois Romieu wrote:
> > Thomas Bogendoerfer <[EMAIL PROTECTED]> :
> > [...]
> > > +static inline void init_rx_bufs(struct net_device *dev)
[...]
> > The driver c
(netdev Cced. People, please, please Cc: netdev)
Soren Hansen <[EMAIL PROTECTED]> :
[...]
> I have an Asrock ConRoe945G-DVI motherboard with a RTL8111/8168B in it.
> The stock r8159 driver locks up from time to time. I've described it
> here: https://launchpad.net/bugs/121815 . The patchset at
> h
Jens Stroebel <[EMAIL PROTECTED]> :
[...]
> Is there any possibility to get this fix working in 2.6.21.5? Would it
> be possible to apply the single patch to 2.6.21.5 and get a working
> driver? Or would it be possible to create the fixing patch for the
> driver in 2.6.21.5?
Mantra: mainline first
The latest serie of r8169 changes is available against 2.6.22-rc6 as:
http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch
or (tarball sits one level higher):
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/
or (rebase prone branch)
git://elec
Jens Stroebel <[EMAIL PROTECTED]> :
[...]
> It seems like the patch is able to change things in a way which makes
> the machine lock up hard. Pity that, looked so promising at first...
As a 8168 user, you should really apply the serie I sent yesterday before
anything else. Then you can try again t
993a6801e2b902362930
794e2548627e76fa5a4fc25ec6f26a01226b18eb
e7c39d0961889a4836091da87cb785d33fcc36e0
Diffstat
drivers/net/r8169.c | 944 ---
1 files changed, 528 insertions(+), 416 deletions(-)
Shortlog
David S. Miller (1):
r8169: kill eth_copy_and_sum()
Use netdev_alloc_skb and remove the useless sk_buff * argument of
rtl8169_alloc_rx_skb.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 27 ++
d try
to go over it.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 4586446..1f7fb54 100644
--- a
- pci_dma_sync_single_for_cpu is not needed for a single large packet
- remove the function pointer to help gcc optimizing the inline
pci_dma functions.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[
It hasn't "summed" anything in over 7 years, and it's
just a straight mempcy ala skb_copy_to_linear_data()
so just get rid of it.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL P
rtl_hw_start_8168 inherits the content of rtl_hw_start_8169 minus
the code which depends on RTL_GIGA_MAC_VER_XY (XY != {11/12}).
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 34 +++
ry in rtl_cfg_info was unused. I recycled it for the 0x8168.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 64 +++---
1 files changed, 45 insertions(+), 19 deletions(-)
diff --
They aim to limit the amount of moved code when the hw_start
handler gets more specialized.
No functional change.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 53 +--
work around for AMD platform.
Some registers definitions in Realtek's driver are let aside for later.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 90 +++
1 files
the driver, of course)
and the 8101/8168 go with a plain 8 bytes alignment.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/r8169
Extracted from version 1.001.00 of Realtek's r8101.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r816
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers
It has been documented as deprecated:
- in MODULE_PARM_DESC since may 2005 ;
- at the top of the source file and in printk since june 2004.
Good bye.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8
are
not changed for the 8169/8110 and the 8101
Includes ChipCmd fix from Bernhard Walle <[EMAIL PROTECTED]> (2007/02/24).
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 119 ++-
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5d9e754..d8862cd 100644
--- a/drivers/net/r
off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Philip Craig <[EMAIL PROTECTED]>
Cc: Mike Isely <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/dri
Same thing as the previous change for rtl_hw_start_8168.
The 8101 related code in rtl_hw_start_8169 (see RTL_GIGA_MAC_VER_13)
goes away.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8
...still a bit yucky though.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
i
: Francois Romieu <[EMAIL PROTECTED]>
Cc: Stephen Hemminger <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 347 +--
1 files changed, 145 insertions(+), 202 deletions(-)
diff --git a/drivers/net/r8169.c b
Merged from Realtek's r8169-6.001 driver.
I have added some locking to protect against the arp monitoring
timer in the bonding driver. Accessing the configuration registers
is otherwise performed under RTNL locking.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward
It does not cost much and it will ease the identification of (so far)
unknown devices.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/n
It does not really make sense to update the RX config register
before the mac filtering registers.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a
Jeff Garzik <[EMAIL PROTECTED]> :
> Arjan van de Ven wrote:
> >>+ pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
> >
> >can you create a pci_set_latency_timer() for this please?
[...]
> >>+ if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
> >>+ pci_write_config_byte(tp->pci_d
Peter Missel <[EMAIL PROTECTED]> :
[...]
> It is now on 2.6.21.5 as downloaded from www.kernel.org, built for AMD64.
> Unfortunately, the problem is not gone. After suspend-to-disk and resume,
> link speed is 100. Unplugging and replugging the cable does not help.
> Unloading and reloading the
Francois Romieu <[EMAIL PROTECTED]> :
[...]
> The patch will not apply directly against 2.6.21.5. Is it an option for
> you to try 2.6.22-rc6 or are you stuck with 2.6.21.5 ?
If you feel adventurous, you will find a compile-tested-only patchkit for
2.6.21.5 here:
http://www.fr.zore
Peter Missel <[EMAIL PROTECTED]> :
[...]
> The patch applies without failure; I'm getting a warning during build,
>
> CC [M] drivers/net/r8169.o
> drivers/net/r8169.c: In function ‘rtl8169_start_xmit’:
> drivers/net/r8169.c:2341: warning: ‘txd’ may be used uninitialized in this
> function
It'
Peter Missel <[EMAIL PROTECTED]> :
[...]
> Unfortunately I couldn't get NFS to work with the updated kernel, so I had to
> revert to the original from SuSE 10.2.
No NFS but networking or no networking at all ?
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
Kok, Auke <[EMAIL PROTECTED]> :
> Jeff Garzik wrote:
> >Kok, Auke wrote:
[...]
> This is not acceptable and hardly fair to expect from us.
>
> It also exposes users to endless delays and uncertainties as to a final
> resolution. Not to mention that writing a driver from scratch for (just)
> ich9
Philip Craig <[EMAIL PROTECTED]> :
[...]
> Try the patches at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/
> I think patches 0012 and/or 0017 will fix this.
They should but they will not apply directly against 2.6.18-something.
Florian, can you consider one of the option below:
- try c
Jonathan Larsen <[EMAIL PROTECTED]> :
> I've been looking for the r8169 driver that is for the 2.6.x kernel
> and also supports the device id 8167, 10ec. chipset is the 8110sc.
> im sure someone is familiar with this.
It is not the most used chipset in the 816x family but there are
some known use
Francois Romieu <[EMAIL PROTECTED]> :
[...]
> - try http://www.fr.zoreil.com/people/francois/backport/r8169/20070604-00
> It is a backport against 2.6.18 which should bring you quite close to
> 2.6.23-git wrt r8169.
Regarding the backport option, it was initially more a compi
Clemens Brunner <[EMAIL PROTECTED]> :
[...]
> I just found out that everything is working just fine with a 64-bit Linux
> kernel. I hope this helps you hunt down the error in the 32-bit version.
> https://bugzilla.novell.com/show_bug.cgi?id=288406
Does your setup exclude the "wake up" issue descr
Jonathan Larsen <[EMAIL PROTECTED]> :
> I got git installed on my dev box. i went to my linux source dir and ran,
> git init
> git add .
> git format-patch v2.6.18..v2.6.23-rc1 -- drivers/net/r8169.c
>
> and i got an error
> fatal: bad revision 'v2.6.18..v2.6.23-rc1'
>
> what did i do wrong? im
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[...]
> Can you test this one, this time it's made against the netdev-2.6 version.
> There indeed is a slight offset in the line numbers.
It still fails.
Fixed version follow.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" i
Signed-off-by: Mika Lansirinne <[EMAIL PROTECTED]>
---
drivers/net/8139cp.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index 807e699..e970e64 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/813
Veena Parat <[EMAIL PROTECTED]> :
> - Adding checks to check the return value of pci mapping function
>
> Signed-off-by: Veena Parat <[EMAIL PROTECTED]>
> ---
> diff -Nurp 2.0.23.1/drivers/net/s2io.c 2.0.23.1P1/drivers/net/s2io.c
> --- 2.0.23.1/drivers/net/s2io.c 2007-07-03 08:54:02.000
Veena Parat <[EMAIL PROTECTED]> :
> - Removed 3 buffer mode support from driver - unused feature
Please make it the first patch in the serie.
It will avoid modifying fill_rxd_3buf() needlessly in the previous patches.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev
Veena Parat <[EMAIL PROTECTED]> :
> Implementation of review comments
> - Incorporated Jeff Garzik's comments on coding standards
> - Incorporated Andreas Schwab's comments on redundant condition check
>
> Signed-off-by: Veena Parat <[EMAIL PROTECTED]>
[...]
> diff -Nurp 2.0.23.1P3/drivers/net/s
Jonathan Larsen <[EMAIL PROTECTED]> :
> >You should read the tutorial until you find the 'Using git for
> >collaboration'
> >part. You missed a:
> >
> >git clone
> >git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> Alright sweet, i got somewhere :). i was able to pull tha
Andrew Paprocki <[EMAIL PROTECTED]> :
[...]
> Just writing to let you know that I'm still not getting a link on
> either r8169 port with the stock 2.6.22 kernel. I haven't been able to
> get any other network interface working on this device yet, as it only
> has a mini-PCI slot and I haven't found
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[...]
> Anyone have any suggestions for solving this problem?
Try 2.6.23-rc1 when it is published or apply against 2.6.22 one of:
http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch
http://www.fr.zoreil.com/linux/kernel/2.6.x/2
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[...]
> Unfortunately, the 20070628 patch did not make any difference.
@!#$
[...]
> >http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/
>
> I tried various patches from that directory (aren't most or all of them
> included in the 200706
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 ;
&g
1 - 100 of 878 matches
Mail list logo
