Re: [PATCH 1/1] r8169: Removed unused macros from r8169.c

Dayanidhi Sreenivasan : [...] I have fixed the conflict with the driver in net-next due to removal of the SafeMtu #define and pushed the result in branch davem-next.r8169 at git://violet.fr.zoreil.com/romieu/linux Next time you send a patch, please specify the branch it should apply to and

Re: [PATCH 1/1] r8169: Removed unused macros from r8169.c

Dayanidhi Sreenivasan dayanidhi.sreeniva...@gmail.com : [...] I have fixed the conflict with the driver in net-next due to removal of the SafeMtu #define and pushed the result in branch davem-next.r8169 at git://violet.fr.zoreil.com/romieu/linux Next time you send a patch, please specify the

Re: [PATCH v2 net-next] r8169: enable internal ASPM and clock request settings

David Miller : [...] > Francois? Please apply. Thanks. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at

Re: [PATCH v2 net-next] r8169: enable internal ASPM and clock request settings

David Miller da...@davemloft.net : [...] Francois? Please apply. Thanks. -- Ueimor -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the

Re: [PATCH v2] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois : > This regression was spotted between Debian squeeze and Debian wheezy > kernels (respectively based on 2.6.32 and 3.2). More info about > Wake-on-LAN issues with Realtek's 816x chipsets can be found in the > following thread: http://marc.info/?t=13207921944 David, please

Re: [PATCH net-next] r8169: enable internal ASPM and clock request settings

Hayes Wang : > The following chips need to enable internal settings to let ASPM > and clock request work. No objection, you know better than me. [...] > @@ -5145,7 +5146,10 @@ static void rtl_hw_start_8168g_1(struct > rtl8169_private *tp) > > RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); >

Re: [PATCH net-next] r8169: enable internal ASPM and clock request settings

Hayes Wang hayesw...@realtek.com : The following chips need to enable internal settings to let ASPM and clock request work. No objection, you know better than me. [...] @@ -5145,7 +5146,10 @@ static void rtl_hw_start_8168g_1(struct rtl8169_private *tp) RTL_W8(ChipCmd, CmdTxEnb |

Re: [PATCH v2] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois k...@debian.org : This regression was spotted between Debian squeeze and Debian wheezy kernels (respectively based on 2.6.32 and 3.2). More info about Wake-on-LAN issues with Realtek's 816x chipsets can be found in the following thread: http://marc.info/?t=13207921944

Re: [PATCH] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois : [...] > Thanks. Should I re-send with that as reference, or will you amend the > patch once you're done with your testing? It would be nice to resend, directly to netdev and davem. Shutdown Wol behaved as expected with 3.7-rc3 for both cards: unicast WoL failed without the

Re: [PATCH] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois k...@debian.org : [...] Thanks. Should I re-send with that as reference, or will you amend the patch once you're done with your testing? It would be nice to resend, directly to netdev and davem. Shutdown Wol behaved as expected with 3.7-rc3 for both cards: unicast WoL failed

Re: [PATCH] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois : > This regression was spotted between Debian squeeze and Debian wheezy > kernels (respectively based on 2.6.32 and 3.2). The fix was inspired > by , using > RTL_GIGA_MAC_VER_{25,26} for the RTL8168d/8111d chipset. If someone

Re: [PATCH] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois k...@debian.org : This regression was spotted between Debian squeeze and Debian wheezy kernels (respectively based on 2.6.32 and 3.2). The fix was inspired by http://www.spinics.net/lists/netdev/msg178543.html, using RTL_GIGA_MAC_VER_{25,26} for the RTL8168d/8111d chipset. If

Re: [PATCH v3 net-next] r8169: enable ALDPS for power saving

the > RTL8168d/8111d. > > For 8136 series, make sure the ALDPS is disabled before loading the > firmware. For 8168 series, the ALDPS would be disabled automatically > when loading firmware. You must not disable it directly. > > Signed-off-by: Hayes Wang Acked-by: Francois Romi

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

hayeswang : > Francois Romieu [mailto:rom...@fr.zoreil.com] > [...] > > It would be nice to state these things in the commit message, namely: > > - ALDPS should never be enabled for the RTL8105e > > - none of the firmware-free chipsets support ALDPS > > -

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

hayeswang hayesw...@realtek.com : Francois Romieu [mailto:rom...@fr.zoreil.com] [...] It would be nice to state these things in the commit message, namely: - ALDPS should never be enabled for the RTL8105e - none of the firmware-free chipsets support ALDPS - neither do the RTL8168d

Re: [PATCH v3 net-next] r8169: enable ALDPS for power saving

the RTL8168d/8111d. For 8136 series, make sure the ALDPS is disabled before loading the firmware. For 8168 series, the ALDPS would be disabled automatically when loading firmware. You must not disable it directly. Signed-off-by: Hayes Wang hayesw...@realtek.com Acked-by: Francois Romieu rom

Re: [PATCH v2 net-next 2/2] r8169: update the settings for RTL8111G

Hayes Wang : > Update the parameters of RTL8111G I am Jack's Broken Heart. :o/ In a not too distant future somebody may try to figure if things should be fed into one of the numerous -stable trees. He will appreciate figuring from the comment if this commit is supposed to fix anything or if

Re: [PATCH v2 net-next 1/2] r8169: enable ALDPS for power saving

Hayes Wang : > Enable ALDPS function to save power when link down. Note that the > feature should be set after the other PHY settings. And the firmware > is necessary. Don't enable it without loading the firmware. > > Signed-off-by: Hayes Wang [...] Please see my just sent answer in

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

hayeswang : [...] > The flag is determined if the firmware is loaded. It doesn't mean to enable > ALDPS. Besides ALDPS, the firmware includes the other features about power > saving, performance, hw behavior, and so on. Thus, I think it is the extended > feature. Any suggestion?

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

hayeswang hayesw...@realtek.com : [...] The flag is determined if the firmware is loaded. It doesn't mean to enable ALDPS. Besides ALDPS, the firmware includes the other features about power saving, performance, hw behavior, and so on. Thus, I think it is the extended feature. Any suggestion?

Re: [PATCH v2 net-next 1/2] r8169: enable ALDPS for power saving

Hayes Wang hayesw...@realtek.com : Enable ALDPS function to save power when link down. Note that the feature should be set after the other PHY settings. And the firmware is necessary. Don't enable it without loading the firmware. Signed-off-by: Hayes Wang hayesw...@realtek.com [...] Please

Re: [PATCH v2 net-next 2/2] r8169: update the settings for RTL8111G

Hayes Wang hayesw...@realtek.com : Update the parameters of RTL8111G I am Jack's Broken Heart. :o/ In a not too distant future somebody may try to figure if things should be fed into one of the numerous -stable trees. He will appreciate figuring from the comment if this commit is supposed to

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

Hayes Wang : > Enable ALDPS function to save power when link down. Note that the > feature should be set after the other PHY settings. And the firmware > is necessary. Don't enable it without loading the firmware. > > Signed-off-by: Hayes Wang > --- > drivers/net/ethernet/realtek/r8169.c | 46

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

Hayes Wang hayesw...@realtek.com : Enable ALDPS function to save power when link down. Note that the feature should be set after the other PHY settings. And the firmware is necessary. Don't enable it without loading the firmware. Signed-off-by: Hayes Wang hayesw...@realtek.com ---

Re: [PATCH 2/20 V2] drivers/net/ethernet/natsemi/natsemi.c: fix error return code

but returns non negative value, > making it difficult for a caller function to notice the error. Ok. natsemi_probe1() forgets to return a negative status code in one of its failure paths. [...] > Signed-off-by: Peter Senna Tschudin Acked-by: Francois Romieu -- Ueimor -- To unsubscr

Re: [PATCH 2/20 V2] drivers/net/ethernet/natsemi/natsemi.c: fix error return code

path, but returns non negative value, making it difficult for a caller function to notice the error. Ok. natsemi_probe1() forgets to return a negative status code in one of its failure paths. [...] Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com Acked-by: Francois Romieu rom

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : [...] > Ping failed in the following step: > > HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its > rtl_hw_start callers. *spleen* It's a genuine code move without any real change. Imho it's more a matter of sleeping a few seconds for the link to settle after the device

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : [...] > I don't know what's wrong, but I am getting those errors. > Are you sure about the git tree? Yes. Replace 'git rev-list --all' with 'git rev-list --branches'. It should show something like: $ git rev-list --branches a65a9b5d9c4569228909e36bb6e20d33fe208950

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis thana...@asyr.hopto.org : [...] I don't know what's wrong, but I am getting those errors. Are you sure about the git tree? Yes. Replace 'git rev-list --all' with 'git rev-list --branches'. It should show something like: $ git rev-list --branches

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis thana...@asyr.hopto.org : [...] Ping failed in the following step: HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its rtl_hw_start callers. *spleen* It's a genuine code move without any real change. Imho it's more a matter of sleeping a few seconds for the link to settle

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : > Attached the whole log so far. > (the process looks stuck anyway for more than 30 min at the same point) You don't need to wait that long. I have updated git://violet.fr.zoreil.com/romieu/r8169 with a '3.2.r8169.backport' branch. You can remove your existing r8169 git tree, clone

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis thana...@asyr.hopto.org : Attached the whole log so far. (the process looks stuck anyway for more than 30 min at the same point) You don't need to wait that long. I have updated git://violet.fr.zoreil.com/romieu/r8169 with a '3.2.r8169.backport' branch. You can remove your existing

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : > on 09/21/2012 11:29 PM Francois Romieu wrote the following: [...] > What message? What do you mean "the usual netdev watchdog message"? No, this one (see your 3.5.4 kernel log): [ 23.712058] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x121/0x1a3(

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : > So far, ping has failed *only* at this iteration of the make loop: Ok. Without the usual netdev watchdog message I presume ? [...] > Now, after 74 iterations, it looks as if the loop is stuck at the following: > > HEAD is now at 1ce4b16 r8169: spinlock redux. > make -C

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : [...] > Hmm, think I got it ... Here is what I put there: > > ifconfig eth0 192.168.0.19 up ; ping -c 3 192.168.0.1 If it fails with the r8169 driver included in the 3.5 tree, that's what you can use, yes (you may add a second ping with -q -f -l and more packets to wrap the descriptor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : > on 09/21/2012 02:20 AM Francois Romieu wrote the following: [...] > > Thanasis, can you narrow down a bit the failing revision ? > > Sure, let me know how to do it please. A rough kernel estimate had been enough. Nevermind. You will find a hopefully not too quick

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis thana...@asyr.hopto.org : on 09/21/2012 02:20 AM Francois Romieu wrote the following: [...] Thanasis, can you narrow down a bit the failing revision ? Sure, let me know how to do it please. A rough kernel estimate had been enough. Nevermind. You will find a hopefully not too quick

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis thana...@asyr.hopto.org : [...] Hmm, think I got it ... Here is what I put there: ifconfig eth0 192.168.0.19 up ; ping -c 3 192.168.0.1 If it fails with the r8169 driver included in the 3.5 tree, that's what you can use, yes (you may add a second ping with -q -f -l and more packets to

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis thana...@asyr.hopto.org : So far, ping has failed *only* at this iteration of the make loop: Ok. Without the usual netdev watchdog message I presume ? [...] Now, after 74 iterations, it looks as if the loop is stuck at the following: HEAD is now at 1ce4b16 r8169: spinlock redux.

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis thana...@asyr.hopto.org : on 09/21/2012 11:29 PM Francois Romieu wrote the following: [...] What message? What do you mean the usual netdev watchdog message? No, this one (see your 3.5.4 kernel log): [ 23.712058] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x121/0x1a3

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Bjorn Helgaas : [...] > Thanks. I don't see anything wrong from the PCI core point of view. > But searching for "r8169 transmit queue timed out" found lots of > similar reports. It's a rather common symptom when things go wrong :o/ > +cc 8169 driver folks (thanks) Thanasis, can you narrow

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Bjorn Helgaas bhelg...@google.com : [...] Thanks. I don't see anything wrong from the PCI core point of view. But searching for r8169 transmit queue timed out found lots of similar reports. It's a rather common symptom when things go wrong :o/ +cc 8169 driver folks (thanks) Thanasis, can

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

Hugh Dickins : > [ Cc'ing original mail to netdev as the problem may be recognized there ] [...] > Francois is right that a GFP_ATOMIC allocation from pskb_expand_head() > is failing, which can easily happen, and cause your "failed to reallocate > TX buffer" errors; but it's well worth looking up

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

Hugh Dickins hu...@google.com : [ Cc'ing original mail to netdev as the problem may be recognized there ] [...] Francois is right that a GFP_ATOMIC allocation from pskb_expand_head() is failing, which can easily happen, and cause your failed to reallocate TX buffer errors; but it's well worth

Re: [PATCH v3] net: add new QCA alx ethernet driver

cj...@qca.qualcomm.com : [...] > diff --git a/drivers/net/ethernet/atheros/alx/alx.h > b/drivers/net/ethernet/atheros/alx/alx.h > new file mode 100644 > index 000..2b4ecc1 > --- /dev/null > +++ b/drivers/net/ethernet/atheros/alx/alx.h [...] > +#define ALX_VLAN_TO_TAG(_vlan, _tag) \ > +

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

David Madore : [...] > [ 268.976317] ieee80211 phy0: failed to reallocate TX buffer > [ 716.880515] ieee80211 phy0: failed to reallocate TX buffer > [ 1160.877677] ieee80211 phy0: failed to reallocate TX buffer > > Could they be related? Yes. This is a pskb_expand_head failure from

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

David Madore david...@madore.org : [...] [ 268.976317] ieee80211 phy0: failed to reallocate TX buffer [ 716.880515] ieee80211 phy0: failed to reallocate TX buffer [ 1160.877677] ieee80211 phy0: failed to reallocate TX buffer Could they be related? Yes. This is a pskb_expand_head failure

Re: [PATCH v3] net: add new QCA alx ethernet driver

cj...@qca.qualcomm.com cj...@qca.qualcomm.com : [...] diff --git a/drivers/net/ethernet/atheros/alx/alx.h b/drivers/net/ethernet/atheros/alx/alx.h new file mode 100644 index 000..2b4ecc1 --- /dev/null +++ b/drivers/net/ethernet/atheros/alx/alx.h [...] +#define ALX_VLAN_TO_TAG(_vlan,

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

David Madore : [...] > I imagine it being somehow related to the fact that it operates a > network bridge (I imagine this because I have another identical > machine with exactly the same kernel and a very similar config but not > running a bridge, and the warning never pops up). Could it not be

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

David Madore david...@madore.org : [...] I imagine it being somehow related to the fact that it operates a network bridge (I imagine this because I have another identical machine with exactly the same kernel and a very similar config but not running a bridge, and the warning never pops up).

Re: [2/3][PATCH][v2] TDM Framework

sand...@freescale.com : [...] > The main functions of this Framework are: > - provides interface to TDM clients to access TDM functionalities. > - provides standard interface for TDM drivers to hook with the framework. > - handles various data handling stuff and buffer management. > > In

Re: [2/3][PATCH][v2] TDM Framework

sand...@freescale.com sand...@freescale.com : [...] The main functions of this Framework are: - provides interface to TDM clients to access TDM functionalities. - provides standard interface for TDM drivers to hook with the framework. - handles various data handling stuff and buffer

Re: [RFC] firmware load: defer request_firmware during early boot and resume

Ming Lei : > On Sun, Jul 22, 2012 at 1:31 AM, Linus Torvalds > wrote: > > On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote: > >> The RFC patch is just for discussing if the idea of deferring > >> request_firmware is doable for addressing the issue of > >> request_firmware in resume path, which

Re: [RFC] firmware load: defer request_firmware during early boot and resume

Ming Lei tom.leim...@gmail.com : On Sun, Jul 22, 2012 at 1:31 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei tom.leim...@gmail.com wrote: The RFC patch is just for discussing if the idea of deferring request_firmware is doable for

Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond

hayeswang : [...] > rtt min/avg/max/mdev = 0.028/0.040/0.101/0.011 ms, pipe 4, ipg/ewma > 0.021/0.035 > rtt min/avg/max/mdev = 0.151/0.173/0.247/0.020 ms, pipe 4, ipg/ewma > 0.048/0.168 [...] > The attached file is my log. It seems fine. A few percents packet loss at this rate does not exactly

Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond

hayeswang hayesw...@realtek.com : [...] rtt min/avg/max/mdev = 0.028/0.040/0.101/0.011 ms, pipe 4, ipg/ewma 0.021/0.035 rtt min/avg/max/mdev = 0.151/0.173/0.247/0.020 ms, pipe 4, ipg/ewma 0.048/0.168 [...] The attached file is my log. It seems fine. A few percents packet loss at this rate

Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond

Francois Romieu : [...] > I'll try again tomorrow evening. W/o firmware does not seem to make a difference. # ping -qf -l 4 -s 81 -c 60 10.0.3.1 PING 10.0.3.1 (10.0.3.1) 81(109) bytes of data. --- 10.0.3.1 ping statistics --- 60 packets transmitted, 60 received, 0% packet loss, time 153ms

Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond

Francois Romieu rom...@fr.zoreil.com : [...] I'll try again tomorrow evening. W/o firmware does not seem to make a difference. # ping -qf -l 4 -s 81 -c 60 10.0.3.1 PING 10.0.3.1 (10.0.3.1) 81(109) bytes of data. --- 10.0.3.1 ping statistics --- 60 packets transmitted, 60 received, 0% packet

Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond

Hayes Wang : > No waiting is needed for mac_ocp_{write / read}. And the bit 31 of > OCPDR would not change, so rtl_udelay_loop_wait_high always return > false. That is, the r8168_mac_ocp_read always retuen ~0. (testing with davem's 48ee3569f31d91084dc694fef5517eb782428083) It seemed right at

Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond

Hayes Wang hayesw...@realtek.com : No waiting is needed for mac_ocp_{write / read}. And the bit 31 of OCPDR would not change, so rtl_udelay_loop_wait_high always return false. That is, the r8168_mac_ocp_read always retuen ~0. (testing with davem's 48ee3569f31d91084dc694fef5517eb782428083) It

Re: [PATCH net-next 6/6] r8169: support RTL8168G

(you should include a Signed-off-by) Hayes Wang : > 1. Remove rtl_ocpdr_cond. No waiting is needed for mac_ocp_{write / read}. Nit: it would not hurt to do a better job than me and save some commit noise getting these things right before they pollute the history. :o) > 2. Set ocp_base to

Re: [PATCH net-next 6/6] r8169: support RTL8168G

Hayes Wang : > fix incorrct argument in rtl_hw_init_8168g. > > Signed-off-by: Hayes Wang Thanks Hayes. It's available with proper attribution and subject at: git://violet.fr.zoreil.com/romieu/linux davem-next.r8169 -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH net-next 6/6] r8169: support RTL8168G

Hayes Wang hayesw...@realtek.com : fix incorrct argument in rtl_hw_init_8168g. Signed-off-by: Hayes Wang hayesw...@realtek.com Thanks Hayes. It's available with proper attribution and subject at: git://violet.fr.zoreil.com/romieu/linux davem-next.r8169 -- Ueimor -- To unsubscribe from

Re: [PATCH net-next 6/6] r8169: support RTL8168G

(you should include a Signed-off-by) Hayes Wang hayesw...@realtek.com : 1. Remove rtl_ocpdr_cond. No waiting is needed for mac_ocp_{write / read}. Nit: it would not hurt to do a better job than me and save some commit noise getting these things right before they pollute the history. :o) 2.

Re: 3.4.4 r8169 weirdness

Udo van den Heuvel : [...] > Is my hardware dying or is it the kernel? Try adding eb2dc35d99028b698cdedba4f5522bc43e576bd2 if you own a 8168evl. If you don't, try reverting 036dafa28da1e2565a8529de2ae663c37b7a0060. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH net-next 1/2] r8169: support RTL8106E

David Miller : > Francois, what would you like me to do with these two patches? I > haven't seen full ACKs from you yet. You have two options: - You can apply the first (8106) patch. I tested it. I'm ok with Hayes point. Consider it Acked. - You wait for a pull request with both patches + the

Re: [PATCH net-next 1/2] r8169: support RTL8106E

David Miller da...@davemloft.net : Francois, what would you like me to do with these two patches? I haven't seen full ACKs from you yet. You have two options: - You can apply the first (8106) patch. I tested it. I'm ok with Hayes point. Consider it Acked. - You wait for a pull request with

Re: 3.4.4 r8169 weirdness

Udo van den Heuvel udo...@xs4all.nl : [...] Is my hardware dying or is it the kernel? Try adding eb2dc35d99028b698cdedba4f5522bc43e576bd2 if you own a 8168evl. If you don't, try reverting 036dafa28da1e2565a8529de2ae663c37b7a0060. -- Ueimor -- To unsubscribe from this list: send the line

Re: [PATCH v2 net-next 2/2] r8169: support RTL8168G

igned-off-by: Francois Romieu --- drivers/net/ethernet/realtek/r8169.c | 460 +- 1 file changed, 225 insertions(+), 235 deletions(-) diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 0759c76..4f350fc 100644 --- a/dr

Re: [PATCH v2 net-next 2/2] r8169: support RTL8168G

hayeswang : > Francois Romieu [rom...@fr.zoreil.com] [...] > > - fix r8168g_mdio_write (if (reg_addr == 0x1f) { if (reg_addr == 0) snafu) > > -> Please check this one. > > That is fine. Thanks, I'll merge your patch and feed both drivers to davem. -- Ueimor -- To un

Re: [PATCH v2 net-next 2/2] r8169: support RTL8168G

hayeswang hayesw...@realtek.com : Francois Romieu [rom...@fr.zoreil.com] [...] - fix r8168g_mdio_write (if (reg_addr == 0x1f) { if (reg_addr == 0) snafu) - Please check this one. That is fine. Thanks, I'll merge your patch and feed both drivers to davem. -- Ueimor -- To unsubscribe

Re: [PATCH v2 net-next 2/2] r8169: support RTL8168G

. Signed-off-by: Francois Romieu rom...@fr.zoreil.com --- drivers/net/ethernet/realtek/r8169.c | 460 +- 1 file changed, 225 insertions(+), 235 deletions(-) diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 0759c76

Re: [git patches] net driver fixes

David Miller <[EMAIL PROTECTED]> : [...] > Because it forces me to pull Linus's upstream into net-2.6, > I don't have any choice in the matter. Jeff's choice is a bit surprizing. That being said, it would had been nice to fast-forward net-2.6 from a442585952f137bd4cdb1f2f3166e4157d383b82 to

Re: [git patches] net driver fixes

David Miller [EMAIL PROTECTED] : [...] Because it forces me to pull Linus's upstream into net-2.6, I don't have any choice in the matter. Jeff's choice is a bit surprizing. That being said, it would had been nice to fast-forward net-2.6 from a442585952f137bd4cdb1f2f3166e4157d383b82 to Linus's

Re: [git patches] net driver fixes

Sam Ravnborg <[EMAIL PROTECTED]> : [...] > > -static struct pci_device_id sis190_pci_tbl[] __devinitdata = { > > +static struct pci_device_id sis190_pci_tbl[] = { > > { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 }, > > { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 }, > > { 0, }, >

Re: [git patches] net driver fixes

Sam Ravnborg [EMAIL PROTECTED] : [...] -static struct pci_device_id sis190_pci_tbl[] __devinitdata = { +static struct pci_device_id sis190_pci_tbl[] = { { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 }, { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 }, { 0, }, The

Re: r8169 and out of space

Alistair John Strachan <[EMAIL PROTECTED]> : [..] > No, we have not diagnosed the cause of the problem, beyond the swiotlb usage. > I'm adding the r8169 maintainer, linux-net and linux-kernel to CC, to pass on > your information, I hope you don't mind. swiotlb fragmentation perhaps ? Switching

Re: r8169 and out of space

Alistair John Strachan [EMAIL PROTECTED] : [..] No, we have not diagnosed the cause of the problem, beyond the swiotlb usage. I'm adding the r8169 maintainer, linux-net and linux-kernel to CC, to pass on your information, I hope you don't mind. swiotlb fragmentation perhaps ? Switching the

Re: 2.6.24-rc6 oops in net_tx_action

[EMAIL PROTECTED] <[EMAIL PROTECTED]> : > Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial > port driver. > > 2.6.23 was known stable. I haven't tested earlier 2.6.24 releases. > I think it happened once before; I got a black-screen lockup with > keyboard LEDs blinking, but

Re: 2.6.24-rc6 oops in net_tx_action

[EMAIL PROTECTED] [EMAIL PROTECTED] : Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial port driver. 2.6.23 was known stable. I haven't tested earlier 2.6.24 releases. I think it happened once before; I got a black-screen lockup with keyboard LEDs blinking, but that was

Re: VIA Velocity and 802.1q VLAN support

Steve Davies <[EMAIL PROTECTED]> : [...] > I assume that the NIC is not allowing tagged packets into the driver > due to its built-in hardware acceleration/filtering :( > > Is it inappropriate to beg for help and suggestions? Try to disable the vlan related Rx filtering ? -- Ueimor -- To

Re: VIA Velocity and 802.1q VLAN support

Steve Davies [EMAIL PROTECTED] : [...] I assume that the NIC is not allowing tagged packets into the driver due to its built-in hardware acceleration/filtering :( Is it inappropriate to beg for help and suggestions? Try to disable the vlan related Rx filtering ? -- Ueimor -- To unsubscribe

Re: [2.6 patch] drivers/net/sis190.c section fix

Adrian Bunk <[EMAIL PROTECTED]> : > This patch fixes the following section mismatch with CONFIG_HOTPLUG=n: [...] > WARNING: vmlinux.o(.init.text.20+0x4cb25): Section mismatch: reference to > .exit.text:sis190_mii_remove (between 'sis190_init_one' and 'read_eeprom') Thanks. Applied at:

Re: [2.6 patch] drivers/net/sis190.c section fix

Adrian Bunk [EMAIL PROTECTED] : This patch fixes the following section mismatch with CONFIG_HOTPLUG=n: [...] WARNING: vmlinux.o(.init.text.20+0x4cb25): Section mismatch: reference to .exit.text:sis190_mii_remove (between 'sis190_init_one' and 'read_eeprom') Thanks. Applied at:

Re: [2.6 patch] drivers/net/ipg.c: add __devexit annotation

Adrian Bunk <[EMAIL PROTECTED]> : > ipg_remove() can become __devexit. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> I'll add it to the pending ipg queue. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]

Re: [2.6 patch] drivers/net/ipg.c: add __devexit annotation

Adrian Bunk [EMAIL PROTECTED] : ipg_remove() can become __devexit. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] I'll add it to the pending ipg queue. -- Ueimor -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More

Re: Reproducible data corruption with sendfile+vsftp - splice regression?

Holger Hoffstaette <[EMAIL PROTECTED]> : [...] > Maybe turning off sendfile or NAPI just lead to random success - so far it > really looks like tso on the r8169 is the common cause. TSO on the r8169 is the magic switch but the regression makes imvho more sense from a VM pov: - the corrupted file

Re: Reproducible data corruption with sendfile+vsftp - splice regression?

Holger Hoffstaette [EMAIL PROTECTED] : [...] Maybe turning off sendfile or NAPI just lead to random success - so far it really looks like tso on the r8169 is the common cause. TSO on the r8169 is the magic switch but the regression makes imvho more sense from a VM pov: - the corrupted file has

Re: Reproducible data corruption with sendfile+vsftp - splice regression?

Francois Romieu <[EMAIL PROTECTED]> : > Holger Hoffstaette <[EMAIL PROTECTED]> : > [...] > > Should I file this in bugzilla? > > Yes. 5326 5585327 5585328 5585329 5585330 5585331 5585332 5585333 5585334 5585335 558 5336 5585337 5585338 5585339 5585340 5585341 55853

Re: Reproducible data corruption with sendfile+vsftp - splice regression?

Holger Hoffstaette <[EMAIL PROTECTED]> : [...] > Should I file this in bugzilla? Yes. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: Reproducible data corruption with sendfile+vsftp - splice regression?

Holger Hoffstaette [EMAIL PROTECTED] : [...] Should I file this in bugzilla? Yes. -- Ueimor -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the

Re: Reproducible data corruption with sendfile+vsftp - splice regression?

Francois Romieu [EMAIL PROTECTED] : Holger Hoffstaette [EMAIL PROTECTED] : [...] Should I file this in bugzilla? Yes. 5326 5585327 5585328 5585329 5585330 5585331 5585332 5585333 5585334 5585335 558 5336 5585337 5585338 5585339 5585340 5585341 5585342 5585343 5589440 5589441 558

Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space

Francois Romieu <[EMAIL PROTECTED]> : > Alistair John Strachan <[EMAIL PROTECTED]> : > [...] > > The "choke" affects other devices on the system too, notably libata, which > > does not recover gracefully. In my logs, I see a stream of: > > > >

Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space

Alan Cox <[EMAIL PROTECTED]> : [...] > You seem to have a leak, which actually isn't suprising > > rtl8169_xmit_frags allocates a set of maps for a fragmented packet > > rtl8169_start_xmit allocates a buffer > > When we finish the transit we free the main buffer (always using

Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space

Alistair John Strachan <[EMAIL PROTECTED]> : [...] > The "choke" affects other devices on the system too, notably libata, which > does not recover gracefully. In my logs, I see a stream of: > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 > DMA: Out of SW-IOMMU space for 7222

Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space

Alistair John Strachan [EMAIL PROTECTED] : [...] The choke affects other devices on the system too, notably libata, which does not recover gracefully. In my logs, I see a stream of: DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 DMA: Out of SW-IOMMU space for 7222 bytes at

Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space

Alan Cox [EMAIL PROTECTED] : [...] You seem to have a leak, which actually isn't suprising rtl8169_xmit_frags allocates a set of maps for a fragmented packet rtl8169_start_xmit allocates a buffer When we finish the transit we free the main buffer (always using skb-len when

Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space

Francois Romieu [EMAIL PROTECTED] : Alistair John Strachan [EMAIL PROTECTED] : [...] The choke affects other devices on the system too, notably libata, which does not recover gracefully. In my logs, I see a stream of: DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0

Re: network driver usage count

Wagner Ferenc <[EMAIL PROTECTED]> : [...] > So why can I remove a driver serving live network traffic? Why not ? It is quite common to remove physically a network/storage device. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: network driver usage count

Wagner Ferenc [EMAIL PROTECTED] : [...] So why can I remove a driver serving live network traffic? Why not ? It is quite common to remove physically a network/storage device. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL

<    1   2   3   4   5   6   7   8   9   10   >