Re: L2 network namespace benchmarking
Eric W. Biederman wrote: Daniel Lezcano [EMAIL PROTECTED] writes: [...] * When do you expect to have the network namespace into mainline ? My current goal is to finish my rebase against 2.6.linus_lastest in the next couple of days after having figured out how to deal with sysfs. Great news! I also have some questions about this updated version: - Have you integrated the bug fixes and cleanups(*) Daniel wrote for your previous netns patchset (and the few glitches I reported too)? (*) available in LXC8 patchset - Do you already have a public git repository set up for the rebase? - If it is private, any plan to make it public soon? (That would be great) I have been doing reviewing in more code then I know what to do with, and fighting some very strange bugs during the stabilization window. Which has kept me from doing additional development. Plus I have had a cold. I hope you're getting better... and you'll be able to provide us the updated patchset very soon :) [...] If I read the results right it took a 32bit machine from AMD with a gigabit interface before you could measure a throughput difference. That isn't shabby for a non-optimized code path. Indeed the throughput difference is not significant. This is very good to see that it stays constant when using the container. What I'm more worried about is the CPU load increase. But it seems we've identified some of the culprits. This afternoon I had a look at why the bridge setup isn't better than the route setup (section 2.3 and 2.4 of Daniel's report). In the bridge case, we encounter the same problems as the routes case. The oprofile profile is the same: the most demanding routines are pskb_expand_head and csum_partial_copy_generic. pskb_expand_head() is also called by skb_cow(), but this time skb_cow() is called by netfilter's nf_bridge_copy_header(). We can avoid this copy by removing option CONFIG_BRIDGE_NETFILTER. This copy is made even if netfilter is not used on the host. Maybe some optimizations can be made in netfilter's code to prevent this. Regards, Benjamin -- B e n j a m i n T h e r y - BULL/DT/Open Software RD http://www.bull.com - 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: RFC: Established connections hash function
On Wed, Mar 28, 2007 at 04:52:55PM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote: 3) We dont want to be 'totally secure'. We only want to raise the level, and eventually see if we have to spend more time on this next year(s). AFAIK we had two different reports from people being hit by the flaw of previous hash. Not really a critical issue. Yes, but you probably want a complexity of at least 10^5-10^6 to be any useful. I don't think you will get that early in boot from random unless you use hardware support. What we have (had) right now is broken situation, and it must be fixed no matter what solution is used. Using more secure hash (and breaking Jenkins hash is a bit harder than XOR one, I say it not only from theoretical point of view looking into its operations) is a fix. It is possible that there is even better fix - there is always something better than one has right now, but right now problem must be fixed. And David (and Eric, and Nikolaos) fixed that problem in place. It can be solved (this time it will be called 'improved') further. 4) We could add a hard limit on the length of one chain. Even if the bad guys discover a flaw, it wont hurt too much. Hard limit should not be used, since it is exactly what attacker wants - attacker can get all slots in th hash table and server will not respond to other clients at all, although it could, but much slower. Or just use the trie? It has other advantages too :) As an interested party I should not comment, but I can not resist - yes, it is cool and can be done better :) -Andi -- Evgeniy Polyakov - 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: [RESEND] [NET] fib_rules: Flush route cache after rule modifications
On Wed, Mar 28, 2007 at 09:34:36PM +0200, Thomas Graf wrote: * David Miller [EMAIL PROTECTED] 2007-03-28 11:24 Another idea Thomas and I tossed around was to have some kind of way for the rule insertion to indicate that the flush should be deferred and I kind of prefer that explicitness. Right, although I believe the flag should not only defer it but not flush at all. This would be the optimal solution for scripts which can do a ip ro flush cache as they know what they're doing. By default it's better the flush immediately, because the old behavior is totally unexpected. I insert a rule and it dosn't show up?, nobody expects that. It's a tough call, I'd favour immediate flush as well but I can see the point in delaying by ip_rt_min_delay which can be configured by the user. So people can choose to immediately flush by setting it to 0. It would also be consistent to the flush after route changes, the same delay is used there. Of course you both are right - but (...I've some doubts): - there is a difference between tools: route or ip route (as a successor) and ip rule; the latter is intended for advanced things, so users have to expect... (or RTFM!). - of course immediate flush seems to be more natural, but it isn't like that and rules (other rules) are changed, so maybe some transitory way is needed; these 2s look like a good compromise, but after looking into rt_cache_flush - it's not for all (I know - we don't like multipath - but untill it's here...) and these locks and timers aren't for free, too; so, IMHO, something like -n[oflush] option is a mustbe. - for consistency probably all ip objects should be verified: to flush or not to flush by default. Cheers, Jarek P. - 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: [RESEND] [NET] fib_rules: Flush route cache after rule modifications
On Thu, Mar 29, 2007 at 12:03:26PM +0200, Jarek Poplawski wrote: ... rt_cache_flush - it's not for all (I know - we don't like multipath - but untill it's here...)[...] Sorry, I forgot it's already not there... Jarek P. - 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: [PATCH] add Attansic L2 PCI ID
Chris Snook wrote: From: Chris Snook [EMAIL PROTECTED] Add PCI ID for the Attansic L2 100 Mb ethernet adapter. Signed-off-by: Chris Snook [EMAIL PROTECTED] --- linux-2.6.21-rc5.orig/include/linux/pci_ids.h 2007-03-27 23:26:50.0 -0400 +++ linux-2.6.21-rc5/include/linux/pci_ids.h2007-03-28 15:11:03.0 -0400 @@ -2090,6 +2090,7 @@ #define PCI_VENDOR_ID_ATTANSIC 0x1969 #define PCI_DEVICE_ID_ATTANSIC_L1 0x1048 +#define PCI_DEVICE_ID_ATTANSIC_L2 0x2048 Actually you should be doing the reverse: Remove PCI_DEVICE_ID_ATTANSIC_L1, and replace the one place that uses it with the hexadecimal constant. 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: [PATCH] atl1: save mac address on remove
Chris Snook wrote: From: Chris Snook [EMAIL PROTECTED] Some atl1 boards get their MAC address written directly to the register by the BIOS during POST, rather than storing it in EEPROM that's accessible to the driver. If the MAC register on one of these boards is changed and then the module is unloaded, the permanent MAC address will be forgotten until the box is rebooted. We should save the permanent address during removal if we've been messing with it. Signed-off-by: Chris Snook [EMAIL PROTECTED] applied, even though its a hack - 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: [PATCH] sis190: new PHY support
Francois Romieu wrote:
Reported to work on the WinFast 761GXK8MB-RS motherboard.
Plain 10/100 Mbps.
Signed-off-by: Paul Gibbons [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/sis190.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index b08508b..34463ce 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -324,6 +324,7 @@ static struct mii_chip_info {
u32 feature;
} mii_chip_table[] = {
{ Broadcom PHY BCM5461, { 0x0020, 0x60c0 }, LAN, F_PHY_BCM5461 },
+ { Broadcom PHY AC131, { 0x0143, 0xbc70 }, LAN, 0 },
{ Agere PHY ET1101B,{ 0x0282, 0xf010 }, LAN, 0 },
{ Marvell PHY 88E, { 0x0141, 0x0cc0 }, LAN, F_PHY_88E },
{ Realtek PHY RTL8201, { 0x, 0x8200 }, LAN, 0 },
applied
-
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: [PATCH 7/7] qla3xxx: Bumping driver version number to v2.03.00-k4
Ron Mercer wrote: The zeroeth patch was visable on my browser, but the seven patches didn't show up. I thought there was a problem with sendmail so turned debug on and retried. Forget the second set as they are identical patches. On Mon, Mar 26, 2007 at 01:47:30PM -0700, Andrew Vasquez wrote: BTW: this patchset was sent twice to netdev. That's what I saw here: patch #0 appear in my inbox, but patches #1-7 only appeared in my netdev box. 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: [PATCH 6/7] qla3xxx: Adding support for the Agere PHY (ET1011C)
Ron Mercer wrote: This PHY support patch was written by Benjamin Li. Signed-off-by: Benjamin Li [EMAIL PROTECTED] Signed-off-by: Ron Mercer [EMAIL PROTECTED] --- drivers/net/qla3xxx.c | 347 +++-- drivers/net/qla3xxx.h | 33 +- 2 files changed, 335 insertions(+), 45 deletions(-) applied 5-7 to #upstream - 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: [PATCH 2/2] mv643xx_eth: make eth_port_uc_addr_{get,set}() calls symmetric
Dale Farnsworth wrote: From: Gabriel Paubert [EMAIL PROTECTED] There is no good reason for the asymmetry in the parameters of eth_port_uc_addr_get() and eth_port_uc_addr_set(). Make them symmetric. Remove some gratuitous block comments while we're here. Signed-off-by: Gabriel Paubert [EMAIL PROTECTED] Signed-off-by: Dale Farnsworth [EMAIL PROTECTED] --- This is a clean-up patch that needn't be rushed upstream. -Dale drivers/net/mv643xx_eth.c | 59 +++- drivers/net/mv643xx_eth.h |4 -- 2 files changed, 13 insertions(+), 50 deletions(-) applied to #upstream - 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: Patch:replace with time_after in drivers/net/eexpress.c
Shani wrote: Hi, Replacing with time_after in drivers/net/eexpress.c Applies and compiles clean on latest tree.Not tested. thanks. Signed-off-by: Shani Moideen [EMAIL PROTECTED] applied to #upstream - 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: L2 network namespace benchmarking
Benjamin Thery [EMAIL PROTECTED] writes: Eric W. Biederman wrote: Daniel Lezcano [EMAIL PROTECTED] writes: [...] * When do you expect to have the network namespace into mainline ? My current goal is to finish my rebase against 2.6.linus_lastest in the next couple of days after having figured out how to deal with sysfs. Great news! I also have some questions about this updated version: - Have you integrated the bug fixes and cleanups(*) Daniel wrote for your previous netns patchset (and the few glitches I reported too)? About half of them so far. It is my intention to incorporate all of them. They weren't all trivial to include. A couple of Daniel's patches address a real issue in the wrong way so I have to give them some more thought. (*) available in LXC8 patchset - Do you already have a public git repository set up for the rebase? - If it is private, any plan to make it public soon? (That would be great) Yes. Where the current one is now. I have been doing reviewing in more code then I know what to do with, and fighting some very strange bugs during the stabilization window. Which has kept me from doing additional development. Plus I have had a cold. I hope you're getting better... and you'll be able to provide us the updated patchset very soon :) Hopefully. I think I have fixed my last non network regression I know about for 2.6.21-rcX. Which means I can begin to focus again. [...] If I read the results right it took a 32bit machine from AMD with a gigabit interface before you could measure a throughput difference. That isn't shabby for a non-optimized code path. Indeed the throughput difference is not significant. This is very good to see that it stays constant when using the container. What I'm more worried about is the CPU load increase. But it seems we've identified some of the culprits. Yes, and the good news is that they all seem to be in getting the packets to the network namespace. This afternoon I had a look at why the bridge setup isn't better than the route setup (section 2.3 and 2.4 of Daniel's report). In the bridge case, we encounter the same problems as the routes case. The oprofile profile is the same: the most demanding routines are pskb_expand_head and csum_partial_copy_generic. pskb_expand_head() is also called by skb_cow(), but this time skb_cow() is called by netfilter's nf_bridge_copy_header(). We can avoid this copy by removing option CONFIG_BRIDGE_NETFILTER. This copy is made even if netfilter is not used on the host. Maybe some optimizations can be made in netfilter's code to prevent this. Sounds reasonable. I guess the next step is to get some numbers with CONFIG_BRIDGE_NETFILTER disabled. (So we don't hit that case and just in case there are more). I suspect the bridging code has a small enough user base right now it just hasn't been optimized much. Eric - 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: [PATCH] atl1: save mac address on remove
Jeff Garzik wrote: Chris Snook wrote: From: Chris Snook [EMAIL PROTECTED] Some atl1 boards get their MAC address written directly to the register by the BIOS during POST, rather than storing it in EEPROM that's accessible to the driver. If the MAC register on one of these boards is changed and then the module is unloaded, the permanent MAC address will be forgotten until the box is rebooted. We should save the permanent address during removal if we've been messing with it. Signed-off-by: Chris Snook [EMAIL PROTECTED] applied, even though its a hack Oh, it's definitely a hack, but the hardware it's supporting is a hack, so we have to work with it. Thanks. -- Chris - 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: [PATCH] add Attansic L2 PCI ID
Jeff Garzik wrote: Chris Snook wrote: From: Chris Snook [EMAIL PROTECTED] Add PCI ID for the Attansic L2 100 Mb ethernet adapter. Signed-off-by: Chris Snook [EMAIL PROTECTED] --- linux-2.6.21-rc5.orig/include/linux/pci_ids.h2007-03-27 23:26:50.0 -0400 +++ linux-2.6.21-rc5/include/linux/pci_ids.h2007-03-28 15:11:03.0 -0400 @@ -2090,6 +2090,7 @@ #define PCI_VENDOR_ID_ATTANSIC0x1969 #define PCI_DEVICE_ID_ATTANSIC_L10x1048 +#define PCI_DEVICE_ID_ATTANSIC_L20x2048 Actually you should be doing the reverse: Remove PCI_DEVICE_ID_ATTANSIC_L1, and replace the one place that uses it with the hexadecimal constant. Jeff We're working on integrating the driver for the L2 chip, so it will be useful to symbolically distinguish between them. For now, adding the ID serves to document the distinction between the L1 and L2 chips, as they're alike enough that an atl1 driver hacked with the new PCI ID will detect link status on the L2, even though it won't really work. By getting the ID in now, we can distribute patches that don't touch core code and won't need to be tweaked for submission. If pci_ids.h bloat is really a big deal, we can hold off until the L2 patches are ready, but I don't see the harm in getting this out there now. -- Chris - 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: [2.6 patch] the scheduled eepro100 removal
Sounds sane to me. My overall opinion on eepro100 removal is that we're not there yet. Rare problem cases remain where e100 fails but eepro100 works, and it's older drivers so its low priority for everybody. Needs to happen, though... It seems that several Tyan Opteron base system that were using IPMI add on card. the IPMI card share intel 100Mhz nic onboard. you need to use eepro100 instead of e100 otherwise the e100 will shutdown OOB (out of Band) connection for IPMI when shut down the OS. I find it hard to believe that something as common as IPMI in conjunction with the IPMI technology wasn't tested in Intel's lab. From my experience with Intel Server boards, onboard IPMI (all offered versions) and e100/e1000 NICs, I've never ever experienced any problems operating the BMC over the NIC. Also, I don't quite understand you point about the IPMI card sharing the 100Mbit/s NIC onboard? What exactly is shared? Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | 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: [git patches] net driver fixes
Guennadi Liakhovetski wrote: Jeff, might be worth getting the sk_buff leak fix in ppp from http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too? Don't know how important it is for stable. It was present in 2.6.18 too. Can you resend the patch to me, please? Easier for the system to apply than the URL... 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: [PATCH] ehea: removing unused functionality
Jan-Bernd Themann wrote: This patch includes: - removal of unused fields in structs - ethtool statistics cleanup - removes unsed functionality from send path Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED] --- This patch applies on top of the netdev upstream branch for 2.6.22 drivers/net/ehea/ehea.h | 25 ++--- drivers/net/ehea/ehea_ethtool.c | 111 ++-- drivers/net/ehea/ehea_main.c| 55 +++ drivers/net/ehea/ehea_qmr.h |2 4 files changed, 69 insertions(+), 124 deletions(-) applied to #upstream - 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] e100 driver on ARM
On Thu, Mar 29, 2007 at 01:17:38AM -0400, David Acker wrote: I have a pxa255 based system with PCI added to it. The e100 would have memory corruption in its receive buffers detected by slab debugging unless I put in the patch to use the S-bit. Here is a link to the patch posting: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/broken-out/git-netdev-all.patch Search for e100.c. http://www-gatago.com/linux/kernel/15457063.html - This discussion seems to hit the issue. There appears to be a race on the cache line where the EL bit and the next packet info live. In my case the hardware appeared to write to a free packet. The S-bit seems to make the hardware stop and spin on the bit, while the EL bit seems to let the hardware try to use that packet. This race would occur less often when the receive buffer chain is always refilled before the hardware can use them up. On our 400 Mhz Xscale, we can use up all 256 buffers if the PCI bus has another busy device on it. In our case it is an 802.11g miniPCI card and our software was routing all ethernet packets to the wireless interface and vice versa while TCP streams were running accross these connections. Which PCI host controller are you using with the PXA255? We tried using a PXA255 based system with a PCI controller a couple of years ago and have to change to a different cpu in the end due to the PCI controller simply not being valid PCI. The PXA255 wasn't designed for PCI, and I get the impression that non of the PCI companion chips for it do a good enough job to actually add it correctly. -- Len Sorensen - 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
quick help with bonding?
Im doing some experimenting with a new network driver that receives jumbo frames into multiple separate pages that are then joined together in a single sk_buff using skb_fill_page_desc(). It behaved fairly well with standard networking, but its behaving strangely with bonding added to the mix. Could someone either point me to the bonding high level design document (couldn't find one at the sourceforge project page) or else give me a quick overview of the code path followed by an incoming packet when bonding is involved? Thanks, Chris Friesen - 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
DECnet routing rule resolution
Hi, One of the effects of the recent tidy up of the DECnet routing rules code is that we are no longer able to see the difference between reading a rule of type FR_ACT_UNREACHABLE returning -ENETUNREACH and simply running out of rules to look at, which also returns the same thing. The DECnet code used to return -ESRCH if it ran out of rules in which case the test in dn_route.c (which resulted in DECnet falling back to endnode routing in the -ESRCH case) no longer works. So there seems to be several options to try and solve this: one is to change the error return for running out of rules in fib_rules.c:fib_rules_lookup() to something else (but then that has a knock on effect in the ipv4 code). Another is to add the not found error return as a parameter in the struct fib_rules_ops so that both protocols can have their preferred error return. Both solutions seem a bit messy, so I thought I'd ask for some guidance on this before writing a patch, Steve. - 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
[IFB]: Fix crash on input device removal
Fix the crash reported in the another critical bug ? thread,
which turned out to be caused by a stale input_dev pointer.
The patch applies to current -git and latest -stable.
[IFB]: Fix crash on input device removal
The input_device pointer is not refcounted, which means the device may
disappear while packets are queued, causing a crash when ifb passes packets
with a stale skb-dev pointer to netif_rx().
Fix by storing the interface index instead and do a lookup where neccessary.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit a08b2ee8faa15fc9dcb71f52219db60852909ccf
tree 1e99ccb62cdcd0ba6b672ccd654bf57287ca217b
parent 190a4408ecb577391ea5fbd1f90148a6992a5756
author Patrick McHardy [EMAIL PROTECTED] Thu, 29 Mar 2007 18:20:38 +0200
committer Patrick McHardy [EMAIL PROTECTED] Thu, 29 Mar 2007 18:20:38 +0200
drivers/net/ifb.c | 35 +--
include/linux/skbuff.h |5 +++--
include/net/pkt_cls.h |7 +--
net/core/dev.c |8
net/core/skbuff.c |2 +-
net/sched/act_mirred.c |2 +-
6 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index ca2b21f..07b4c0d 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -96,17 +96,24 @@ static void ri_tasklet(unsigned long dev)
skb-tc_verd = SET_TC_NCLS(skb-tc_verd);
stats-tx_packets++;
stats-tx_bytes +=skb-len;
+
+ skb-dev = __dev_get_by_index(skb-iif);
+ if (!skb-dev) {
+ dev_kfree_skb(skb);
+ stats-tx_dropped++;
+ break;
+ }
+ skb-iif = _dev-ifindex;
+
if (from AT_EGRESS) {
dp-st_rx_frm_egr++;
dev_queue_xmit(skb);
} else if (from AT_INGRESS) {
-
dp-st_rx_frm_ing++;
+ skb_pull(skb, skb-dev-hard_header_len);
netif_rx(skb);
- } else {
- dev_kfree_skb(skb);
- stats-tx_dropped++;
- }
+ } else
+ BUG();
}
if (netif_tx_trylock(_dev)) {
@@ -157,26 +164,10 @@ static int ifb_xmit(struct sk_buff *skb, struct
net_device *dev)
stats-rx_packets++;
stats-rx_bytes+=skb-len;
- if (!from || !skb-input_dev) {
-dropped:
+ if (!(from (AT_INGRESS|AT_EGRESS)) || !skb-iif) {
dev_kfree_skb(skb);
stats-rx_dropped++;
return ret;
- } else {
- /*
-* note we could be going
-* ingress - egress or
-* egress - ingress
- */
- skb-dev = skb-input_dev;
- skb-input_dev = dev;
- if (from AT_INGRESS) {
- skb_pull(skb, skb-dev-hard_header_len);
- } else {
- if (!(from AT_EGRESS)) {
- goto dropped;
- }
- }
}
if (skb_queue_len(dp-rq) = dev-tx_queue_len) {
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 4ff3940..82f43ad 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -188,7 +188,7 @@ enum {
* @sk: Socket we are owned by
* @tstamp: Time we arrived
* @dev: Device we arrived on/are leaving by
- * @input_dev: Device we arrived on
+ * @iif: ifindex of device we arrived on
* @h: Transport layer header
* @nh: Network layer header
* @mac: Link layer header
@@ -235,7 +235,8 @@ struct sk_buff {
struct sock *sk;
struct skb_timeval tstamp;
struct net_device *dev;
- struct net_device *input_dev;
+ int iif;
+ /* 4 byte hole on 64 bit*/
union {
struct tcphdr *th;
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index b902d24..02647fe 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -352,10 +352,13 @@ tcf_change_indev(struct tcf_proto *tp, char *indev,
struct rtattr *indev_tlv)
static inline int
tcf_match_indev(struct sk_buff *skb, char *indev)
{
+ struct net_device *dev;
+
if (indev[0]) {
- if (!skb-input_dev)
+ if (!skb-iif)
return 0;
- if (strcmp(indev, skb-input_dev-name))
+ dev = __dev_get_by_index(skb-iif);
+ if (!dev || strcmp(indev, dev-name))
return 0;
}
diff --git a/net/core/dev.c b/net/core/dev.c
index 5984b55..d44b8f1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1741,8 +1741,8 @@ static int ing_filter(struct sk_buff *skb)
if (dev-qdisc_ingress) {
__u32 ttl = (__u32)
Re: [Bonding-devel] quick help with bonding?
Chris Friesen [EMAIL PROTECTED] wrote: Could someone either point me to the bonding high level design document (couldn't find one at the sourceforge project page) or else give me a quick overview of the code path followed by an incoming packet when bonding is involved? There really isn't a high level design document. The input path goes from the driver, which (probably) calls netif_receive_skb. That function does its processing whatnot, the only special step for bonding is the processing done by skb_bond() which assigns the packet to the bonding device. In the current mainline, skb_bond() also does some stuff to drop traffic on inactive slaves as the like. After that, the packet follows the regular input path in netif_skb_receive. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - 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
[PATCH 00/19] e1000: hardware init layer update, new internal API
Hi, This single patch split out over several e-mails creates an e1000 hardware- independent API for accessing MAC, PHY, NVM and manageability. The API adds function pointers for common entry points into the code and relieves the driver from doing lots of mac_type switch statements, allowing us to minimize the risk of introducing regressions when adding new hardware support to e1000. Code path separation also will allow us in the future to specifically enable only support for chipsets that the user needs in the case of embedded systems. The e1000 family of adapters currently consists of 7 distinctly different adapters. The family-specific code has been split out into one file per family. PHY, NVM and manageability infrastructure code has also been split out in a separate file per component. This change forces us to rewrite some of the register sets, particularly since the e1000 chipsets currently operate with two completely different register mappings. All the generic register defines are extracted into a separate container, while maintaining compatibility with the 82542 register set. This patch is dependent on both the upstream and e1000-fixes branch of jgarzik/netdev-2.6. The entire set of changes is available as a single git-commit to allow regression testing and bisecting to work as expected, but for convencience split up into several e-mails. Patch #7 will be missing from the netdev ML since it exceeds 100k, but it contains the removal of e1000_hw.c, and as such should not be missed too much. For convenience, all the patches can be viewed together with other patches in my queue here: http://foo-projects.org/~sofar/patches-20070327/ --- Jeff, Please consider pulling from: git://lost.foo-projects.org/~ahkok/git/netdev-2.6 e1000 Which is a tree based on both the e1000-fixes (prerequisite to this patch) and your upstream tree. --- Signed-off-by: Bruce Allan [EMAIL PROTECTED] Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Jeb Cramer [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/Makefile| 18 +- drivers/net/e1000/e1000.h |7 + drivers/net/e1000/e1000_80003es2lan.c | 1377 + drivers/net/e1000/e1000_80003es2lan.h | 89 + drivers/net/e1000/e1000_82540.c | 670 +++ drivers/net/e1000/e1000_82541.c | 1305 + drivers/net/e1000/e1000_82541.h | 86 + drivers/net/e1000/e1000_82542.c | 551 ++ drivers/net/e1000/e1000_82543.c | 1643 ++ drivers/net/e1000/e1000_82543.h | 45 + drivers/net/e1000/e1000_82571.c | 1333 + drivers/net/e1000/e1000_82571.h | 42 + drivers/net/e1000/e1000_api.c | 1174 + drivers/net/e1000/e1000_api.h | 160 + drivers/net/e1000/e1000_defines.h | 1303 + drivers/net/e1000/e1000_ethtool.c | 503 ++- drivers/net/e1000/e1000_hw.c | 9038 - drivers/net/e1000/e1000_hw.h | 3857 +++ drivers/net/e1000/e1000_ich8lan.c | 2443 + drivers/net/e1000/e1000_ich8lan.h | 110 + drivers/net/e1000/e1000_mac.c | 1939 +++ drivers/net/e1000/e1000_mac.h | 84 + drivers/net/e1000/e1000_main.c| 1034 ++-- drivers/net/e1000/e1000_manage.c | 384 ++ drivers/net/e1000/e1000_manage.h | 83 + drivers/net/e1000/e1000_nvm.c | 859 drivers/net/e1000/e1000_nvm.h | 60 + drivers/net/e1000/e1000_osdep.h | 52 +- drivers/net/e1000/e1000_param.c | 98 +- drivers/net/e1000/e1000_phy.c | 1933 +++ drivers/net/e1000/e1000_phy.h | 159 + drivers/net/e1000/e1000_regs.h| 261 + 32 files changed, 19582 insertions(+), 13118 deletions(-) create mode 100644 drivers/net/e1000/e1000_80003es2lan.c create mode 100644 drivers/net/e1000/e1000_80003es2lan.h create mode 100644 drivers/net/e1000/e1000_82540.c create mode 100644 drivers/net/e1000/e1000_82541.c create mode 100644 drivers/net/e1000/e1000_82541.h create mode 100644 drivers/net/e1000/e1000_82542.c create mode 100644 drivers/net/e1000/e1000_82543.c create mode 100644 drivers/net/e1000/e1000_82543.h create mode 100644 drivers/net/e1000/e1000_82571.c create mode 100644 drivers/net/e1000/e1000_82571.h create mode 100644 drivers/net/e1000/e1000_api.c create mode 100644 drivers/net/e1000/e1000_api.h create mode 100644 drivers/net/e1000/e1000_defines.h delete mode 100644 drivers/net/e1000/e1000_hw.c create mode 100644 drivers/net/e1000/e1000_ich8lan.c create mode 100644 drivers/net/e1000/e1000_ich8lan.h create mode 100644 drivers/net/e1000/e1000_mac.c create mode 100644 drivers/net/e1000/e1000_mac.h create mode 100644 drivers/net/e1000/e1000_manage.c create mode 100644 drivers/net/e1000/e1000_manage.h create mode 100644 drivers/net/e1000/e1000_nvm.c create mode 100644
[PATCH 01/19] e1000: introduce new driver internal hardware API
From: Jeb Cramer [EMAIL PROTECTED]
This introduces the new internal API for hardware-specific code. The
code is split up per chipset and allows future chipset support to be
added without touching the run-time codepatch of old hardware, greatly
reducing the risk of introducing regressions, and making debugging far
easier due to greater codepath separation.
The API code sets up function pointers for the main hardware specific
routines for each family and initializes the MAC type at load time. From
there on the driver initializes each subcomponent (PHY, NVM, etc.) through
it's function pointer call.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_api.c | 1174 +
drivers/net/e1000/e1000_api.h | 160 ++
2 files changed, 1334 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_api.c b/drivers/net/e1000/e1000_api.c
new file mode 100644
index 000..ea4dd64
--- /dev/null
+++ b/drivers/net/e1000/e1000_api.c
@@ -0,0 +1,1174 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+#include e1000_mac.h
+#include e1000_nvm.h
+#include e1000_phy.h
+
+static s32 e1000_set_mac_type(struct e1000_hw *hw);
+
+#ifndef NO_82542_SUPPORT
+extern voide1000_init_function_pointers_82542(struct e1000_hw *hw);
+#endif
+#ifndef NO_82543_SUPPORT
+extern voide1000_init_function_pointers_82543(struct e1000_hw *hw);
+#endif
+#ifndef NO_82540_SUPPORT
+extern voide1000_init_function_pointers_82540(struct e1000_hw *hw);
+#endif
+#ifndef NO_82571_SUPPORT
+extern voide1000_init_function_pointers_82571(struct e1000_hw *hw);
+#endif
+#ifndef NO_82541_SUPPORT
+extern voide1000_init_function_pointers_82541(struct e1000_hw *hw);
+#endif
+#ifndef NO_80003ES2LAN_SUPPORT
+extern voide1000_init_function_pointers_80003es2lan(struct e1000_hw *hw);
+#endif
+#ifndef NO_ICH8LAN_SUPPORT
+extern voide1000_init_function_pointers_ich8lan(struct e1000_hw *hw);
+#endif
+
+/**
+ * e1000_init_mac_params - Initialize MAC function pointers
+ * @hw: pointer to the HW structure
+ *
+ * This function initializes the function pointers for the MAC
+ * set of functions. Called by drivers or by e1000_setup_init_funcs.
+ **/
+s32
+e1000_init_mac_params(struct e1000_hw *hw)
+{
+ s32 ret_val = E1000_SUCCESS;
+
+ if (hw-func.init_mac_params != NULL) {
+ ret_val = hw-func.init_mac_params(hw);
+ if (ret_val) {
+ DEBUGOUT(MAC Initialization Error\n);
+ goto out;
+ }
+ } else {
+ DEBUGOUT(mac.init_mac_params was NULL\n);
+ ret_val = -E1000_ERR_CONFIG;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
+ * e1000_init_nvm_params - Initialize NVM function pointers
+ * @hw: pointer to the HW structure
+ *
+ * This function initializes the function pointers for the NVM
+ * set of functions. Called by drivers or by e1000_setup_init_funcs.
+ **/
+s32
+e1000_init_nvm_params(struct e1000_hw *hw)
+{
+ s32 ret_val = E1000_SUCCESS;
+
+ if (hw-func.init_nvm_params != NULL) {
+ ret_val = hw-func.init_nvm_params(hw);
+ if (ret_val) {
+ DEBUGOUT(NVM Initialization Error\n);
+ goto out;
+ }
+ } else {
+ DEBUGOUT(nvm.init_nvm_params was NULL\n);
+ ret_val = -E1000_ERR_CONFIG;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
+ * e1000_init_phy_params - Initialize PHY function pointers
+ * @hw: pointer to the HW structure
+ *
+ * This function initializes the function pointers for the PHY
+ * set of functions. Called by drivers or by e1000_setup_init_funcs.
+ **/
+s32
+e1000_init_phy_params(struct e1000_hw *hw)
+{
+ s32 ret_val =
[PATCH 05/19] e1000: Add manageability specific hardware initialization code
From: Jeb Cramer [EMAIL PROTECTED]
This adds a device-generic layer for intializing manageability parts
of e1000 hardware, such as packet filtering, dhcp setup, enable passthru
mode.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_manage.c | 384 ++
drivers/net/e1000/e1000_manage.h | 83
2 files changed, 467 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_manage.c b/drivers/net/e1000/e1000_manage.c
new file mode 100644
index 000..36bc082
--- /dev/null
+++ b/drivers/net/e1000/e1000_manage.c
@@ -0,0 +1,384 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+#include e1000_manage.h
+
+static u8 e1000_calculate_checksum(u8 *buffer, u32 length);
+
+/**
+ * e1000_calculate_checksum - Calculate checksum for buffer
+ * @buffer: pointer to EEPROM
+ * @length: size of EEPROM to calculate a checksum for
+ *
+ * Calculates the checksum for some buffer on a specified length. The
+ * checksum calculated is returned.
+ **/
+static u8
+e1000_calculate_checksum(u8 *buffer, u32 length)
+{
+ u32 i;
+ u8 sum = 0;
+
+ DEBUGFUNC(e1000_calculate_checksum);
+
+ if (!buffer)
+ return 0;
+
+ for (i = 0; i length; i++)
+ sum += buffer[i];
+
+ return (u8) (0 - sum);
+}
+
+/**
+ * e1000_mng_enable_host_if_generic - Checks host interface is enabled
+ * @hw: pointer to the HW structure
+ *
+ * Returns E1000_success upon success, else E1000_ERR_HOST_INTERFACE_COMMAND
+ *
+ * This function checks whether the HOST IF is enabled for command operaton
+ * and also checks whether the previous command is completed. It busy waits
+ * in case of previous command is not completed.
+ **/
+s32
+e1000_mng_enable_host_if_generic(struct e1000_hw * hw)
+{
+ u32 hicr;
+ s32 ret_val = E1000_SUCCESS;
+ u8 i;
+
+ DEBUGFUNC(e1000_mng_enable_host_if_generic);
+
+ /* Check that the host interface is enabled. */
+ hicr = E1000_READ_REG(hw, E1000_HICR);
+ if ((hicr E1000_HICR_EN) == 0) {
+ DEBUGOUT(E1000_HOST_EN bit disabled.\n);
+ ret_val = -E1000_ERR_HOST_INTERFACE_COMMAND;
+ goto out;
+ }
+ /* check the previous command is completed */
+ for (i = 0; i E1000_MNG_DHCP_COMMAND_TIMEOUT; i++) {
+ hicr = E1000_READ_REG(hw, E1000_HICR);
+ if (!(hicr E1000_HICR_C))
+ break;
+ mdelay(1);
+ }
+
+ if (i == E1000_MNG_DHCP_COMMAND_TIMEOUT) {
+ DEBUGOUT(Previous command timeout failed .\n);
+ ret_val = -E1000_ERR_HOST_INTERFACE_COMMAND;
+ goto out;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
+ * e1000_check_mng_mode_generic - Generic check managament mode
+ * @hw: pointer to the HW structure
+ *
+ * Reads the firmware semaphore register and returns true (0) if
+ * manageability is enabled, else false (0).
+ **/
+boolean_t
+e1000_check_mng_mode_generic(struct e1000_hw *hw)
+{
+ u32 fwsm;
+
+ DEBUGFUNC(e1000_check_mng_mode_generic);
+
+ fwsm = E1000_READ_REG(hw, E1000_FWSM);
+
+ return ((fwsm E1000_FWSM_MODE_MASK) ==
+ (E1000_MNG_IAMT_MODE E1000_FWSM_MODE_SHIFT));
+}
+
+/**
+ * e1000_enable_tx_pkt_filtering_generic - Enable packet filtering on TX
+ * @hw: pointer to the HW structure
+ *
+ * Enables packet filtering on transmit packets if manageability is enabled
+ * and host interface is enabled.
+ **/
+boolean_t
+e1000_enable_tx_pkt_filtering_generic(struct e1000_hw *hw)
+{
+ struct e1000_host_mng_dhcp_cookie *hdr = hw-mng_cookie;
+ u32 *buffer = (u32 *)hw-mng_cookie;
+ u32 offset;
+ s32 ret_val, hdr_csum, csum;
+ u8 i, len;
+
[PATCH 06/19] e1000: Add new register set code
From: Jeb Cramer [EMAIL PROTECTED] Add e1000_registers.h which contains all supported register sets by e1000 devices in a single file. Signed-off-by: Jeb Cramer [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/e1000_regs.h | 261 1 files changed, 261 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000/e1000_regs.h b/drivers/net/e1000/e1000_regs.h new file mode 100644 index 000..ce6175b --- /dev/null +++ b/drivers/net/e1000/e1000_regs.h @@ -0,0 +1,261 @@ +/*** + + Intel PRO/1000 Linux driver + Copyright(c) 1999 - 2007 Intel Corporation. + + This program is free software; you can redistribute it and/or modify it + under the terms and conditions of the GNU General Public License, + version 2, as published by the Free Software Foundation. + + This program is distributed in the hope it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., + 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. + + The full GNU General Public License is included in this distribution in + the file called COPYING. + + Contact Information: + Linux NICS [EMAIL PROTECTED] + e1000-devel Mailing List [EMAIL PROTECTED] + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +***/ + +#ifndef _E1000_REGS_H_ +#define _E1000_REGS_H_ + +#define E1000_CTRL 0x0 /* Device Control - RW */ +#define E1000_CTRL_DUP 0x4 /* Device Control Duplicate (Shadow) - RW */ +#define E1000_STATUS 0x8 /* Device Status - RO */ +#define E1000_EECD 0x00010 /* EEPROM/Flash Control - RW */ +#define E1000_EERD 0x00014 /* EEPROM Read - RW */ +#define E1000_CTRL_EXT 0x00018 /* Extended Device Control - RW */ +#define E1000_FLA 0x0001C /* Flash Access - RW */ +#define E1000_MDIC 0x00020 /* MDI Control - RW */ +#define E1000_SCTL 0x00024 /* SerDes Control - RW */ +#define E1000_FCAL 0x00028 /* Flow Control Address Low - RW */ +#define E1000_FCAH 0x0002C /* Flow Control Address High -RW */ +#define E1000_FEXTNVM 0x00028 /* Future Extended NVM - RW */ +#define E1000_FCT 0x00030 /* Flow Control Type - RW */ +#define E1000_VET 0x00038 /* VLAN Ether Type - RW */ +#define E1000_ICR 0x000C0 /* Interrupt Cause Read - R/clr */ +#define E1000_ITR 0x000C4 /* Interrupt Throttling Rate - RW */ +#define E1000_ICS 0x000C8 /* Interrupt Cause Set - WO */ +#define E1000_IMS 0x000D0 /* Interrupt Mask Set - RW */ +#define E1000_IMC 0x000D8 /* Interrupt Mask Clear - WO */ +#define E1000_IAM 0x000E0 /* Interrupt Acknowledge Auto Mask */ +#define E1000_RCTL 0x00100 /* RX Control - RW */ +#define E1000_RDTR10x02820 /* RX Delay Timer (1) - RW */ +#define E1000_RDBAL1 0x02900 /* RX Descriptor Base Address Low (1) - RW */ +#define E1000_RDBAH1 0x02904 /* RX Descriptor Base Address High (1) - RW */ +#define E1000_RDLEN1 0x02908 /* RX Descriptor Length (1) - RW */ +#define E1000_RDH1 0x02910 /* RX Descriptor Head (1) - RW */ +#define E1000_RDT1 0x02918 /* RX Descriptor Tail (1) - RW */ +#define E1000_FCTTV0x00170 /* Flow Control Transmit Timer Value - RW */ +#define E1000_TXCW 0x00178 /* TX Configuration Word - RW */ +#define E1000_RXCW 0x00180 /* RX Configuration Word - RO */ +#define E1000_TCTL 0x00400 /* TX Control - RW */ +#define E1000_TCTL_EXT 0x00404 /* Extended TX Control - RW */ +#define E1000_TIPG 0x00410 /* TX Inter-packet gap -RW */ +#define E1000_TBT 0x00448 /* TX Burst Timer - RW */ +#define E1000_AIT 0x00458 /* Adaptive Interframe Spacing Throttle - RW */ +#define E1000_LEDCTL 0x00E00 /* LED Control - RW */ +#define E1000_EXTCNF_CTRL 0x00F00 /* Extended Configuration Control */ +#define E1000_EXTCNF_SIZE 0x00F08 /* Extended Configuration Size */ +#define E1000_PHY_CTRL 0x00F10 /* PHY Control Register in CSR */ +#define E1000_PBA 0x01000 /* Packet Buffer Allocation - RW */ +#define E1000_PBS 0x01008 /* Packet Buffer Size */ +#define E1000_EEMNGCTL 0x01010 /* MNG EEprom Control */ +#define E1000_EEARBC 0x01024 /* EEPROM Auto Read Bus Control */ +#define E1000_FLASHT 0x01028 /* FLASH Timer Register */ +#define E1000_EEWR 0x0102C /* EEPROM Write Register - RW */ +#define E1000_FLSWCTL 0x01030 /* FLASH control register */ +#define E1000_FLSWDATA 0x01034 /* FLASH data register */ +#define E1000_FLSWCNT 0x01038 /* FLASH Access Counter */ +#define E1000_FLOP 0x0103C /* FLASH Opcode Register */ +#define
[PATCH 04/19] e1000: NVM specific hardware initialization code
From: Jeb Cramer [EMAIL PROTECTED]
This adds NVM-generic layer code to the e1000 driver, allowing generic
access to the EEPROM/NVM and abstracts much of the driver interaction
with the NVM data.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_nvm.c | 859 +
drivers/net/e1000/e1000_nvm.h | 60 +++
2 files changed, 919 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_nvm.c b/drivers/net/e1000/e1000_nvm.c
new file mode 100644
index 000..46544df
--- /dev/null
+++ b/drivers/net/e1000/e1000_nvm.c
@@ -0,0 +1,859 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+#include e1000_nvm.h
+
+/**
+ * e1000_raise_eec_clk - Raise EEPROM clock
+ * @hw: pointer to the HW structure
+ * @eecd: pointer to the EEPROM
+ *
+ * Enable/Raise the EEPROM clock bit.
+ **/
+static void
+e1000_raise_eec_clk(struct e1000_hw *hw, u32 *eecd)
+{
+ *eecd = *eecd | E1000_EECD_SK;
+ E1000_WRITE_REG(hw, E1000_EECD, *eecd);
+ E1000_WRITE_FLUSH(hw);
+ udelay(hw-nvm.delay_usec);
+}
+
+/**
+ * e1000_lower_eec_clk - Lower EEPROM clock
+ * @hw: pointer to the HW structure
+ * @eecd: pointer to the EEPROM
+ *
+ * Clear/Lower the EEPROM clock bit.
+ **/
+static void
+e1000_lower_eec_clk(struct e1000_hw *hw, u32 *eecd)
+{
+ *eecd = *eecd ~E1000_EECD_SK;
+ E1000_WRITE_REG(hw, E1000_EECD, *eecd);
+ E1000_WRITE_FLUSH(hw);
+ udelay(hw-nvm.delay_usec);
+}
+
+/**
+ * e1000_shift_out_eec_bits - Shift data bits our to the EEPROM
+ * @hw: pointer to the HW structure
+ * @data: data to send to the EEPROM
+ * @count: number of bits to shift out
+ *
+ * We need to shift 'count' bits out to the EEPROM. So, the value in the
+ * data parameter will be shifted out to the EEPROM one bit at a time.
+ * In order to do this, data must be broken down into bits.
+ **/
+static void
+e1000_shift_out_eec_bits(struct e1000_hw *hw, u16 data, u16 count)
+{
+ struct e1000_nvm_info *nvm = hw-nvm;
+ u32 eecd = E1000_READ_REG(hw, E1000_EECD);
+ u32 mask;
+
+ DEBUGFUNC(e1000_shift_out_eec_bits);
+
+ mask = 0x01 (count - 1);
+ if (nvm-type == e1000_nvm_eeprom_microwire)
+ eecd = ~E1000_EECD_DO;
+ else if (nvm-type == e1000_nvm_eeprom_spi)
+ eecd |= E1000_EECD_DO;
+
+ do {
+ eecd = ~E1000_EECD_DI;
+
+ if (data mask)
+ eecd |= E1000_EECD_DI;
+
+ E1000_WRITE_REG(hw, E1000_EECD, eecd);
+ E1000_WRITE_FLUSH(hw);
+
+ udelay(nvm-delay_usec);
+
+ e1000_raise_eec_clk(hw, eecd);
+ e1000_lower_eec_clk(hw, eecd);
+
+ mask = 1;
+ } while (mask);
+
+ eecd = ~E1000_EECD_DI;
+ E1000_WRITE_REG(hw, E1000_EECD, eecd);
+}
+
+/**
+ * e1000_shift_in_eec_bits - Shift data bits in from the EEPROM
+ * @hw: pointer to the HW structure
+ * @count: number of bits to shift in
+ *
+ * In order to read a register from the EEPROM, we need to shift 'count' bits
+ * in from the EEPROM. Bits are shifted in by raising the clock input to
+ * the EEPROM (setting the SK bit), and then reading the value of the data out
+ * DO bit. During this shifting in process the data in DI bit should
+ * always be clear.
+ **/
+static u16
+e1000_shift_in_eec_bits(struct e1000_hw *hw, u16 count)
+{
+ u32 eecd;
+ u32 i;
+ u16 data;
+
+ DEBUGFUNC(e1000_shift_in_eec_bits);
+
+ eecd = E1000_READ_REG(hw, E1000_EECD);
+
+ eecd = ~(E1000_EECD_DO | E1000_EECD_DI);
+ data = 0;
+
+ for (i = 0; i count; i++) {
+ data = 1;
+ e1000_raise_eec_clk(hw, eecd);
+
+ eecd = E1000_READ_REG(hw, E1000_EECD);
+
+
[PATCH 09/19] e1000: Add 82542 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82542.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82542.c | 551 +++
1 files changed, 551 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82542.c b/drivers/net/e1000/e1000_82542.c
new file mode 100644
index 000..adca182
--- /dev/null
+++ b/drivers/net/e1000/e1000_82542.c
@@ -0,0 +1,551 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82542 (rev 1 2)
+ */
+
+#include e1000_api.h
+
+void e1000_init_function_pointers_82542(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82542(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82542(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82542(struct e1000_hw *hw);
+static s32 e1000_get_bus_info_82542(struct e1000_hw *hw);
+static s32 e1000_reset_hw_82542(struct e1000_hw *hw);
+static s32 e1000_init_hw_82542(struct e1000_hw *hw);
+static s32 e1000_setup_link_82542(struct e1000_hw *hw);
+static s32 e1000_led_on_82542(struct e1000_hw *hw);
+static s32 e1000_led_off_82542(struct e1000_hw *hw);
+static void e1000_clear_hw_cntrs_82542(struct e1000_hw *hw);
+
+struct e1000_dev_spec_82542 {
+ boolean_t dma_fairness;
+};
+
+/**
+ * e1000_init_phy_params_82542 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82542(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_phy_params_82542);
+
+ phy-type = e1000_phy_none;
+
+ return ret_val;
+}
+
+/**
+ * e1000_init_nvm_params_82542 - Init NVM func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_nvm_params_82542(struct e1000_hw *hw)
+{
+ struct e1000_nvm_info *nvm = hw-nvm;
+ struct e1000_functions *func = hw-func;
+
+ DEBUGFUNC(e1000_init_nvm_params_82542);
+
+ nvm-address_bits = 6;
+ nvm-delay_usec = 50;
+ nvm-opcode_bits= 3;
+ nvm-type = e1000_nvm_eeprom_microwire;
+ nvm-word_size = 64;
+
+ /* Function Pointers */
+ func-read_nvm = e1000_read_nvm_microwire;
+ func-release_nvm = e1000_stop_nvm;
+ func-write_nvm = e1000_write_nvm_microwire;
+ func-update_nvm= e1000_update_nvm_checksum_generic;
+ func-validate_nvm = e1000_validate_nvm_checksum_generic;
+
+ return E1000_SUCCESS;
+}
+
+/**
+ * e1000_init_mac_params_82542 - Init MAC func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_mac_params_82542(struct e1000_hw *hw)
+{
+ struct e1000_mac_info *mac = hw-mac;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_mac_params_82542);
+
+ /* Set media type */
+ hw-media_type = e1000_media_type_fiber;
+
+ /* Set mta register count */
+ mac-mta_reg_count = 128;
+ /* Set rar entry count */
+ mac-rar_entry_count = E1000_RAR_ENTRIES;
+
+ /* Function pointers */
+
+ /* bus type/speed/width */
+ func-get_bus_info = e1000_get_bus_info_82542;
+ /* reset */
+ func-reset_hw = e1000_reset_hw_82542;
+ /* hw initialization */
+ func-init_hw = e1000_init_hw_82542;
+ /* link setup */
+ func-setup_link = e1000_setup_link_82542;
+ /* phy/fiber/serdes setup */
+ func-setup_physical_interface =
[PATCH 10/19] e1000: Add 82543 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82543.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82543.c | 1643 +++
drivers/net/e1000/e1000_82543.h | 45 +
2 files changed, 1688 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82543.c b/drivers/net/e1000/e1000_82543.c
new file mode 100644
index 000..e61e34a
--- /dev/null
+++ b/drivers/net/e1000/e1000_82543.c
@@ -0,0 +1,1643 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82543
+ * e1000_82544
+ */
+
+#include e1000_82543.h
+
+void e1000_init_function_pointers_82543(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82543(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82543(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82543(struct e1000_hw *hw);
+static s32 e1000_read_phy_reg_82543(struct e1000_hw *hw, u32 offset,
+ u16 *data);
+static s32 e1000_write_phy_reg_82543(struct e1000_hw *hw, u32 offset,
+ u16 data);
+static s32 e1000_phy_force_speed_duplex_82543(struct e1000_hw *hw);
+static s32 e1000_phy_hw_reset_82543(struct e1000_hw *hw);
+static s32 e1000_reset_hw_82543(struct e1000_hw *hw);
+static s32 e1000_init_hw_82543(struct e1000_hw *hw);
+static s32 e1000_setup_link_82543(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_82543(struct e1000_hw *hw);
+static s32 e1000_setup_fiber_link_82543(struct e1000_hw *hw);
+static s32 e1000_check_for_copper_link_82543(struct e1000_hw *hw);
+static s32 e1000_check_for_fiber_link_82543(struct e1000_hw *hw);
+static s32 e1000_led_on_82543(struct e1000_hw *hw);
+static s32 e1000_led_off_82543(struct e1000_hw *hw);
+static void e1000_write_vfta_82543(struct e1000_hw *hw, u32 offset,
+u32 value);
+static void e1000_mta_set_82543(struct e1000_hw *hw, u32 hash_value);
+static void e1000_clear_hw_cntrs_82543(struct e1000_hw *hw);
+static s32 e1000_config_mac_to_phy_82543(struct e1000_hw *hw);
+static boolean_t e1000_init_phy_disabled_82543(struct e1000_hw *hw);
+static void e1000_lower_mdi_clk_82543(struct e1000_hw *hw, u32 *ctrl);
+static s32 e1000_polarity_reversal_workaround_82543(struct e1000_hw *hw);
+static void e1000_raise_mdi_clk_82543(struct e1000_hw *hw, u32 *ctrl);
+static u16 e1000_shift_in_mdi_bits_82543(struct e1000_hw *hw);
+static void e1000_shift_out_mdi_bits_82543(struct e1000_hw *hw, u32 data,
+u16 count);
+static boolean_t e1000_tbi_compatibility_enabled_82543(struct e1000_hw *hw);
+static void e1000_set_tbi_sbp_82543(struct e1000_hw *hw, boolean_t state);
+
+struct e1000_dev_spec_82543 {
+ u32 tbi_compatibility;
+ boolean_t dma_fairness;
+ boolean_t init_phy_disabled;
+};
+
+/**
+ * e1000_init_phy_params_82543 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82543(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_phy_params_82543);
+
+ if (hw-media_type != e1000_media_type_copper) {
+ phy-type = e1000_phy_none;
+ goto out;
+ }
+
+ phy-addr = 1;
+ phy-autoneg_mask = AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ phy-reset_delay_us = 1;
+ phy-type =
[PATCH 14/19] e1000: Add 80003es2lan (ESB2) specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 80003es2lan (ESB2).
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_80003es2lan.c | 1377 +
drivers/net/e1000/e1000_80003es2lan.h | 89 ++
2 files changed, 1466 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_80003es2lan.c
b/drivers/net/e1000/e1000_80003es2lan.c
new file mode 100644
index 000..ab9631c
--- /dev/null
+++ b/drivers/net/e1000/e1000_80003es2lan.c
@@ -0,0 +1,1377 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_80003es2lan
+ */
+
+#include e1000_80003es2lan.h
+
+void e1000_init_function_pointers_80003es2lan(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_acquire_phy_80003es2lan(struct e1000_hw *hw);
+static void e1000_release_phy_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_acquire_nvm_80003es2lan(struct e1000_hw *hw);
+static void e1000_release_nvm_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_read_phy_reg_gg82563_80003es2lan(struct e1000_hw *hw,
+ u32 offset,
+ u16 *data);
+static s32 e1000_write_phy_reg_gg82563_80003es2lan(struct e1000_hw *hw,
+u32 offset,
+u16 data);
+static s32 e1000_write_nvm_80003es2lan(struct e1000_hw *hw, u16 offset,
+u16 words, u16 *data);
+static s32 e1000_get_cfg_done_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_phy_force_speed_duplex_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_get_cable_length_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_get_link_up_info_80003es2lan(struct e1000_hw *hw, u16 *speed,
+ u16 *duplex);
+static s32 e1000_reset_hw_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_init_hw_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_80003es2lan(struct e1000_hw *hw);
+static void e1000_clear_hw_cntrs_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_acquire_swfw_sync_80003es2lan(struct e1000_hw *hw, u16 mask);
+static s32 e1000_cfg_kmrn_10_100_80003es2lan(struct e1000_hw *hw, u16 duplex);
+static s32 e1000_cfg_kmrn_1000_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_copper_link_setup_gg82563_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_get_hw_semaphore_80003es2lan(struct e1000_hw *hw);
+static void e1000_initialize_hw_bits_80003es2lan(struct e1000_hw *hw);
+static void e1000_put_hw_semaphore_80003es2lan(struct e1000_hw *hw);
+static void e1000_release_swfw_sync_80003es2lan(struct e1000_hw *hw, u16 mask);
+
+/* A table for the GG82563 cable length where the range is defined
+ * with a lower bound at index and the upper bound at
+ * index + 5.
+ */
+static const
+u16 e1000_gg82563_cable_length_table[] =
+ { 0, 60, 115, 150, 150, 60, 115, 150, 180, 180, 0xFF };
+#define GG82563_CABLE_LENGTH_TABLE_SIZE \
+(sizeof(e1000_gg82563_cable_length_table) / \
+ sizeof(e1000_gg82563_cable_length_table[0]))
+
+/**
+ * e1000_init_phy_params_80003es2lan - Init ESB2 PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_80003es2lan(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+
[PATCH 16/19] e1000: add new chipset-specific files and api files to the Makefile
From: Jeb Cramer [EMAIL PROTECTED] Signed-off-by: Jeb Cramer [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/Makefile | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/net/e1000/Makefile b/drivers/net/e1000/Makefile index 4a6ab15..1086807 100644 --- a/drivers/net/e1000/Makefile +++ b/drivers/net/e1000/Makefile @@ -1,7 +1,7 @@ # # Intel PRO/1000 Linux driver -# Copyright(c) 1999 - 2006 Intel Corporation. +# Copyright(c) 1999 - 2007 Intel Corporation. # # This program is free software; you can redistribute it and/or modify it # under the terms and conditions of the GNU General Public License, @@ -32,4 +32,18 @@ obj-$(CONFIG_E1000) += e1000.o -e1000-objs := e1000_main.o e1000_hw.o e1000_ethtool.o e1000_param.o +e1000-objs := e1000_api.o \ + e1000_82540.o \ + e1000_82541.o \ + e1000_82543.o \ + e1000_82542.o \ + e1000_82571.o \ + e1000_ich8lan.o \ + e1000_80003es2lan.o \ + e1000_mac.o \ + e1000_phy.o \ + e1000_nvm.o \ + e1000_manage.o \ + e1000_param.o \ + e1000_ethtool.o \ + e1000_main.o - 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
[PATCH 11/19] e1000: Add 82540 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82540.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82540.c | 670 +++
1 files changed, 670 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82540.c b/drivers/net/e1000/e1000_82540.c
new file mode 100644
index 000..41549b8
--- /dev/null
+++ b/drivers/net/e1000/e1000_82540.c
@@ -0,0 +1,670 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82540
+ * e1000_82545
+ * e1000_82546
+ * e1000_82545_rev_3
+ * e1000_82546_rev_3
+ */
+
+#include e1000_api.h
+
+void e1000_init_function_pointers_82540(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82540(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82540(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82540(struct e1000_hw *hw);
+static s32 e1000_adjust_serdes_amplitude_82540(struct e1000_hw *hw);
+static void e1000_clear_hw_cntrs_82540(struct e1000_hw *hw);
+static s32 e1000_init_hw_82540(struct e1000_hw *hw);
+static s32 e1000_reset_hw_82540(struct e1000_hw *hw);
+static s32 e1000_set_phy_mode_82540(struct e1000_hw *hw);
+static s32 e1000_set_vco_speed_82540(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_82540(struct e1000_hw *hw);
+static s32 e1000_setup_fiber_serdes_link_82540(struct e1000_hw *hw);
+
+/**
+ * e1000_init_phy_params_82540 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82540(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ phy-addr = 1;
+ phy-autoneg_mask = AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ phy-reset_delay_us = 1;
+ phy-type = e1000_phy_m88;
+
+ /* Function Pointers */
+ func-check_polarity= e1000_check_polarity_m88;
+ func-commit_phy= e1000_phy_sw_reset_generic;
+ func-force_speed_duplex= e1000_phy_force_speed_duplex_m88;
+ func-get_cable_length = e1000_get_cable_length_m88;
+ func-get_cfg_done = e1000_get_cfg_done_generic;
+ func-read_phy_reg = e1000_read_phy_reg_m88;
+ func-reset_phy = e1000_phy_hw_reset_generic;
+ func-write_phy_reg = e1000_write_phy_reg_m88;
+ func-get_phy_info = e1000_get_phy_info_m88;
+
+ ret_val = e1000_get_phy_id(hw);
+ if (ret_val)
+ goto out;
+
+ /* Verify phy id */
+ switch (hw-mac.type) {
+ case e1000_82540:
+ case e1000_82545:
+ case e1000_82545_rev_3:
+ case e1000_82546:
+ case e1000_82546_rev_3:
+ if (phy-id == M88E1011_I_PHY_ID)
+ break;
+ /* Fall Through */
+ default:
+ ret_val = -E1000_ERR_PHY;
+ goto out;
+ break;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
+ * e1000_init_nvm_params_82540 - Init NVM func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_nvm_params_82540(struct e1000_hw *hw)
+{
+ struct e1000_nvm_info *nvm = hw-nvm;
+ struct e1000_functions *func = hw-func;
+ u32 eecd = E1000_READ_REG(hw, E1000_EECD);
+
+ DEBUGFUNC(e1000_init_nvm_params_82540);
+
+ nvm-type = e1000_nvm_eeprom_microwire;
+ nvm-delay_usec = 50;
+ nvm-opcode_bits= 3;
+ switch (nvm-override) {
+ case
[PATCH 13/19] e1000: Add 82571 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82571.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82571.c | 1333 +++
drivers/net/e1000/e1000_82571.h | 42 +
2 files changed, 1375 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82571.c b/drivers/net/e1000/e1000_82571.c
new file mode 100644
index 000..32e11a5
--- /dev/null
+++ b/drivers/net/e1000/e1000_82571.c
@@ -0,0 +1,1333 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82571
+ * e1000_82572
+ * e1000_82573
+ */
+
+#include e1000_82571.h
+
+void e1000_init_function_pointers_82571(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82571(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82571(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82571(struct e1000_hw *hw);
+static s32 e1000_acquire_nvm_82571(struct e1000_hw *hw);
+static void e1000_release_nvm_82571(struct e1000_hw *hw);
+static s32 e1000_write_nvm_82571(struct e1000_hw *hw, u16 offset,
+ u16 words, u16 *data);
+static s32 e1000_update_nvm_checksum_82571(struct e1000_hw *hw);
+static s32 e1000_validate_nvm_checksum_82571(struct e1000_hw *hw);
+static s32 e1000_get_cfg_done_82571(struct e1000_hw *hw);
+static s32 e1000_set_d0_lplu_state_82571(struct e1000_hw *hw,
+ boolean_t active);
+static s32 e1000_reset_hw_82571(struct e1000_hw *hw);
+static s32 e1000_init_hw_82571(struct e1000_hw *hw);
+static void e1000_clear_vfta_82571(struct e1000_hw *hw);
+static void e1000_mc_addr_list_update_82571(struct e1000_hw *hw,
+u8 *mc_addr_list, u32
mc_addr_count,
+u32 rar_used_count, u32 rar_count);
+static s32 e1000_setup_link_82571(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_82571(struct e1000_hw *hw);
+static s32 e1000_setup_fiber_serdes_link_82571(struct e1000_hw *hw);
+static s32 e1000_valid_led_default_82571(struct e1000_hw *hw, u16 *data);
+static void e1000_clear_hw_cntrs_82571(struct e1000_hw *hw);
+static s32 e1000_fix_nvm_checksum_82571(struct e1000_hw *hw);
+static s32 e1000_get_phy_id_82571(struct e1000_hw *hw);
+static void e1000_initialize_hw_bits_82571(struct e1000_hw *hw);
+static s32 e1000_write_nvm_eewr_82571(struct e1000_hw *hw, u16 offset,
+ u16 words, u16 *data);
+
+struct e1000_dev_spec_82571 {
+ boolean_t laa_is_present;
+};
+
+/**
+ * e1000_init_phy_params_82571 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82571(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_phy_params_82571);
+
+ if (hw-media_type != e1000_media_type_copper) {
+ phy-type= e1000_phy_none;
+ goto out;
+ }
+
+ phy-addr= 1;
+ phy-autoneg_mask= AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ phy-reset_delay_us = 100;
+
+ func-acquire_phy= e1000_get_hw_semaphore_generic;
+ func-check_polarity = e1000_check_polarity_igp;
+ func-check_reset_block = e1000_check_reset_block_generic;
+ func-release_phy= e1000_put_hw_semaphore_generic;
+ func-reset_phy = e1000_phy_hw_reset_generic;
+ func-set_d0_lplu_state = e1000_set_d0_lplu_state_82571;
+ func-set_d3_lplu_state =
[PATCH 12/19] e1000: Add 82541 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82541.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82541.c | 1305 +++
drivers/net/e1000/e1000_82541.h | 86 +++
2 files changed, 1391 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82541.c b/drivers/net/e1000/e1000_82541.c
new file mode 100644
index 000..c1e74a3
--- /dev/null
+++ b/drivers/net/e1000/e1000_82541.c
@@ -0,0 +1,1305 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82541
+ * e1000_82547
+ * e1000_82541_rev_2
+ * e1000_82547_rev_2
+ */
+
+#include e1000_82541.h
+
+void e1000_init_function_pointers_82541(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82541(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82541(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82541(struct e1000_hw *hw);
+static s32 e1000_reset_hw_82541(struct e1000_hw *hw);
+static s32 e1000_init_hw_82541(struct e1000_hw *hw);
+static s32 e1000_get_link_up_info_82541(struct e1000_hw *hw, u16 *speed,
+ u16 *duplex);
+static s32 e1000_phy_hw_reset_82541(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_82541(struct e1000_hw *hw);
+static s32 e1000_check_for_link_82541(struct e1000_hw *hw);
+static s32 e1000_get_cable_length_igp_82541(struct e1000_hw *hw);
+static s32 e1000_set_d3_lplu_state_82541(struct e1000_hw *hw,
+ boolean_t active);
+static s32 e1000_setup_led_82541(struct e1000_hw *hw);
+static s32 e1000_cleanup_led_82541(struct e1000_hw *hw);
+static void e1000_clear_hw_cntrs_82541(struct e1000_hw *hw);
+static s32 e1000_config_dsp_after_link_change_82541(struct e1000_hw *hw,
+ boolean_t link_up);
+static s32 e1000_phy_init_script_82541(struct e1000_hw *hw);
+
+static const
+u16 e1000_igp_cable_length_table[] =
+{ 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
+ 5, 10, 10, 10, 10, 10, 10, 10, 20, 20, 20, 20, 20, 25, 25, 25,
+ 25, 25, 25, 25, 30, 30, 30, 30, 40, 40, 40, 40, 40, 40, 40, 40,
+ 40, 50, 50, 50, 50, 50, 50, 50, 60, 60, 60, 60, 60, 60, 60, 60,
+ 60, 70, 70, 70, 70, 70, 70, 80, 80, 80, 80, 80, 80, 90, 90, 90,
+ 90, 90, 90, 90, 90, 90, 100, 100, 100, 100, 100, 100, 100, 100, 100, 100,
+ 100, 100, 100, 100, 110, 110, 110, 110, 110, 110, 110, 110, 110, 110,
110, 110,
+ 110, 110, 110, 110, 110, 110, 120, 120, 120, 120, 120, 120, 120, 120,
120, 120};
+#define IGP01E1000_AGC_LENGTH_TABLE_SIZE \
+(sizeof(e1000_igp_cable_length_table) / \
+ sizeof(e1000_igp_cable_length_table[0]))
+
+struct e1000_dev_spec_82541 {
+ e1000_dsp_config dsp_config;
+ e1000_ffe_config ffe_config;
+ u16 spd_default;
+ boolean_t phy_init_script;
+};
+
+/**
+ * e1000_init_phy_params_82541 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82541(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_phy_params_82541);
+
+ phy-addr = 1;
+ phy-autoneg_mask = AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ phy-reset_delay_us = 1;
+ phy-type = e1000_phy_igp;
+
+ /* Function Pointers */
+ func-check_polarity= e1000_check_polarity_igp;
+ func-force_speed_duplex= e1000_phy_force_speed_duplex_igp;
+ func-get_cable_length = e1000_get_cable_length_igp_82541;
+
[PATCH 19/19] e1000: major part of the new API changes
From: Jeb Cramer [EMAIL PROTECTED]
The new hardware initialization code requires us to follow a slightly
different approach to setup the device. First the function pointers
have to be initialized for the proper hardware type, after which the
general initialization calls those in turn to do per-device specific
initialization.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_ethtool.c | 97 ++-
drivers/net/e1000/e1000_main.c| 155 -
2 files changed, 160 insertions(+), 92 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 033cdb6..c26fdac 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -29,6 +29,7 @@
/* ethtool support for e1000 */
#include e1000.h
+#include e1000_82541.h
#include asm/uaccess.h
@@ -1334,6 +1335,43 @@ e1000_integrated_phy_loopback(struct e1000_adapter
*adapter)
}
static int
+e1000_set_82571_fiber_loopback(struct e1000_adapter *adapter)
+{
+ struct e1000_hw *hw = adapter-hw;
+ u32 ctrl = E1000_READ_REG(hw, E1000_CTRL);
+ int link = 0;
+
+ /* special requirements for 82571/82572 fiber adapters */
+
+ /* jump through hoops to make sure link is up because serdes
+* link is hardwired up */
+ ctrl |= E1000_CTRL_SLU;
+ E1000_WRITE_REG(hw, E1000_CTRL, ctrl);
+
+ /* disable autoneg */
+ ctrl = E1000_READ_REG(hw, E1000_TXCW);
+ ctrl = ~(1 31);
+ E1000_WRITE_REG(hw, E1000_TXCW, ctrl);
+
+ link = (E1000_READ_REG(hw, E1000_STATUS) E1000_STATUS_LU);
+
+ if (!link) {
+ /* set invert loss of signal */
+ ctrl = E1000_READ_REG(hw, E1000_CTRL);
+ ctrl |= E1000_CTRL_ILOS;
+ E1000_WRITE_REG(hw, E1000_CTRL, ctrl);
+ }
+
+ /* special write to serdes control register to enable SerDes analog
+* loopback */
+#define E1000_SERDES_LB_ON 0x410
+ E1000_WRITE_REG(hw, E1000_SCTL, E1000_SERDES_LB_ON);
+ msleep(10);
+
+ return 0;
+}
+
+static int
e1000_set_phy_loopback(struct e1000_adapter *adapter)
{
uint16_t phy_reg = 0;
@@ -1385,6 +1423,42 @@ e1000_set_phy_loopback(struct e1000_adapter *adapter)
return 8;
}
+/* only call this for fiber/serdes connections to es2lan */
+static int
+e1000_set_es2lan_mac_loopback(struct e1000_adapter *adapter)
+{
+ struct e1000_hw *hw = adapter-hw;
+ u32 ctrlext = E1000_READ_REG(hw, E1000_CTRL_EXT);
+ u32 ctrl = E1000_READ_REG(hw, E1000_CTRL);
+
+ /* save CTRL_EXT to restore later, reuse an empty variable (unused
+ on mac_type 80003es2lan) */
+ adapter-tx_fifo_head = ctrlext;
+
+ /* clear the serdes mode bits, putting the device into mac loopback */
+ ctrlext = ~E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES;
+ E1000_WRITE_REG(hw, E1000_CTRL_EXT, ctrlext);
+
+ /* force speed to 1000/FD, link up */
+ ctrl = ~(E1000_CTRL_SPD_1000 | E1000_CTRL_SPD_100);
+ ctrl |= (E1000_CTRL_SLU | E1000_CTRL_FRCSPD | E1000_CTRL_FRCDPX |
+E1000_CTRL_SPD_1000 | E1000_CTRL_FD);
+ E1000_WRITE_REG(hw, E1000_CTRL, ctrl);
+
+ /* set mac loopback */
+ ctrl = E1000_READ_REG(hw, E1000_RCTL);
+ ctrl |= E1000_RCTL_LBM_MAC;
+ E1000_WRITE_REG(hw, E1000_RCTL, ctrl);
+
+ /* set testing mode parameters (no need to reset later) */
+#define KMRNCTRLSTA_OPMODE (0x1F 16)
+#define KMRNCTRLSTA_OPMODE_1GB_FD_GMII 0x0582
+ E1000_WRITE_REG(hw, E1000_KMRNCTRLSTA,
+ (KMRNCTRLSTA_OPMODE | KMRNCTRLSTA_OPMODE_1GB_FD_GMII));
+
+ return 0;
+}
+
static int
e1000_setup_loopback_test(struct e1000_adapter *adapter)
{
@@ -1394,6 +1468,9 @@ e1000_setup_loopback_test(struct e1000_adapter *adapter)
if (hw-media_type == e1000_media_type_fiber ||
hw-media_type == e1000_media_type_internal_serdes) {
switch (hw-mac.type) {
+ case e1000_80003es2lan:
+ return e1000_set_es2lan_mac_loopback(adapter);
+ break;
case e1000_82545:
case e1000_82546:
case e1000_82545_rev_3:
@@ -1402,11 +1479,7 @@ e1000_setup_loopback_test(struct e1000_adapter *adapter)
break;
case e1000_82571:
case e1000_82572:
-#define E1000_SERDES_LB_ON 0x410
- e1000_set_phy_loopback(adapter);
- E1000_WRITE_REG(hw, E1000_SCTL, E1000_SERDES_LB_ON);
- msleep(10);
- return 0;
+ return e1000_set_82571_fiber_loopback(adapter);
break;
default:
rctl = E1000_READ_REG(hw, E1000_RCTL);
@@ -1432,6 +1505,14 @@ e1000_loopback_cleanup(struct e1000_adapter *adapter)
Re: [IFB]: Fix crash on input device removal
On Thu, 2007-29-03 at 18:30 +0200, Patrick McHardy wrote: Fix the crash reported in the another critical bug ? thread, which turned out to be caused by a stale input_dev pointer. The patch applies to current -git and latest -stable. Mucho Gracias Patrick. Dont know if the ack is needed, but here it is. Acked-by: Jamal Hadi Salim [EMAIL PROTECTED] cheers, jamal - 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
traffic shaping with NAT: IFB as IMQ replacement?
Hello, Sorry for the many Ccs, but I hope to reach all parties involved. I want to do traffic shaping with NAT and I wanted to do it with IFB instead of IMQ [1]. I tried a lot of things but now I am stuck (and maybe confused). The setup: eth0 eth1 WAN/(Internet) - Linux Router - LAN Linux router: - does NAT for the LANs - runs local processes communicating with the WAN/Internet Incoming and outgoing traffic on eth0 should be subject to traffic shaping. I put quotes here, because it seems the term policing would be used for the incoming traffic directed at the router itself. It is not an ideal solution to drop incoming packets, but assuming TCP, intelligent dropping (shaping) is still much better than plain rate limiting or no action at all. (see also parts of [2]). If there is a better solution than ingress shaping available or being worked on, please tell me. First of all: Why is it difficult? Because you can't use the advanced qdics (htb, cbq, ...) on ingres directly (only the ingress qdisc). Using IMQ it is quite straightforward to work around this limitation. It seems IFB is intented as IMQ replacement [3] I managed to use IFB as IMQ replacement in a setup without NAT. But when NAT is involved I am in trouble because when I want to classify the packets they still have the translated addresses. I could live with the translated addresses if I could use netfilter connection tracking information to classify the packets [4]. This was also discussed in the thread [3]: Jamal Hadi Salim writes: [...] Instead the plan is to have a contrack related action. This action will selectively either query/create contrack state on incoming packets. Packets could then be redirected to dummy based on what happens - eg on incoming packets; if we find they are of known state we could send to a different queue than one which didnt have existing state. This all however is dependent on whatever rules the admin enters. [...] I tried something like: tc filter add dev ... match all ... \ action ipt -j CONNMARK --restore-mark \ action ipt -j LOG --log-prefix ... \ action continue tc filter add dev ... handle some-mark \ action ipt -j LOG --log-prefix ... to no avail. I couldn't find any information whether this is possible now or what steps it would take to implement this? Greetings Jens PS: similar threads on the LARTC mailing list: http://thread.gmane.org/gmane.linux.network.routing/25922 http://www.spinics.net/lists/lartc/msg19965.html (many more) [1] IMQ: http://www.linuximq.net/ [2] shaping: http://mailman.ds9a.nl/pipermail/lartc/2004q3/013093.html [3] IFB: netdev mailing list thread dummy as IMQ replacement Message-Id: [EMAIL PROTECTED] http://marc.info/?l=linux-netdevm=110712327422706w=2 [4] Note: I think using the old policer [Symbol: NET_CLS_POLICE [=n] Prompt: Traffic Policing (obsolete)] this maybe works? It seems ingress policing happens after netfilter PREROUTING if you use NET_CLS_POLICE but using NET_CLS_ACT it happens before netfilter PREROUTING? (see also: sch_ingress.c and http://mailman.ds9a.nl/pipermail/lartc/2005q4/017782.html) But then again it is marked as obsolete and I need NET_CLS_ACT to redirect to the IFB?! - 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: [Bonding-devel] quick help with bonding?
On Thu, Mar 29, 2007 at 10:14:40AM -0600, Chris Friesen wrote: Im doing some experimenting with a new network driver that receives jumbo frames into multiple separate pages that are then joined together in a single sk_buff using skb_fill_page_desc(). It behaved fairly well with standard networking, but its behaving strangely with bonding added to the mix. Can you elaborate on what isn't going well with this driver/hardware? - 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: [KJ] Patch:replace with time_after in drivers/net/eexpress.c
2007/3/28, Shani [EMAIL PROTECTED]: @@ -1650,7 +1651,7 @@ eexp_set_multicast(struct net_device *dev) #endif oj = jiffies; while ((SCB_CUstat(scb_status(dev)) == 2) - ((jiffies-oj) 2000)); + (time_after(jiffies, oj + 2000))); if (SCB_CUstat(scb_status(dev)) == 2) printk(%s: warning, CU didn't stop\n, dev-name); lp-started = ~(STARTED_CU); it should be time_before, not time_after... - 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: [PATCH] NET: Add TCP connection abort IOCTL
From: Predrag Hodoba [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 16:56:22 +0200 Need for such an API is to a degree indicated in the Carrier Grade Linux requirements by The Linux Foundation (former OSDL). Something being in the CGL specification is to me exactly a great reason NOT to add it. That specification is so full of garbage it's unbelievable. Thanks, you've given me one more reason not to even remotely consider adding this feature. - 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: DECnet routing rule resolution
From: Steven Whitehouse [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 17:24:10 +0100 One of the effects of the recent tidy up of the DECnet routing rules code is that we are no longer able to see the difference between reading a rule of type FR_ACT_UNREACHABLE returning -ENETUNREACH and simply running out of rules to look at, which also returns the same thing. The DECnet code used to return -ESRCH if it ran out of rules in which case the test in dn_route.c (which resulted in DECnet falling back to endnode routing in the -ESRCH case) no longer works. So there seems to be several options to try and solve this: one is to change the error return for running out of rules in fib_rules.c:fib_rules_lookup() to something else (but then that has a knock on effect in the ipv4 code). Another is to add the not found error return as a parameter in the struct fib_rules_ops so that both protocols can have their preferred error return. Both solutions seem a bit messy, so I thought I'd ask for some guidance on this before writing a patch, I think we should be able to return -ESRCH (a more sensible error value if you ask me) across the board. Thomas what do you think? - 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: [IFB]: Fix crash on input device removal
From: jamal [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 12:52:15 -0400 On Thu, 2007-29-03 at 18:30 +0200, Patrick McHardy wrote: Fix the crash reported in the another critical bug ? thread, which turned out to be caused by a stale input_dev pointer. The patch applies to current -git and latest -stable. Mucho Gracias Patrick. Dont know if the ack is needed, but here it is. Acked-by: Jamal Hadi Salim [EMAIL PROTECTED] It's clear that going to an ifindex for input_dev was inevitably, thanks for taking care of this Patrick! Patch applied, and I'll push to -stable too. - 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: [PATCH] add Attansic L2 PCI ID
Chris Snook wrote: Jeff Garzik wrote: Chris Snook wrote: From: Chris Snook [EMAIL PROTECTED] Add PCI ID for the Attansic L2 100 Mb ethernet adapter. Signed-off-by: Chris Snook [EMAIL PROTECTED] --- linux-2.6.21-rc5.orig/include/linux/pci_ids.h2007-03-27 23:26:50.0 -0400 +++ linux-2.6.21-rc5/include/linux/pci_ids.h2007-03-28 15:11:03.0 -0400 @@ -2090,6 +2090,7 @@ #define PCI_VENDOR_ID_ATTANSIC0x1969 #define PCI_DEVICE_ID_ATTANSIC_L10x1048 +#define PCI_DEVICE_ID_ATTANSIC_L20x2048 Actually you should be doing the reverse: Remove PCI_DEVICE_ID_ATTANSIC_L1, and replace the one place that uses it with the hexadecimal constant. Jeff We're working on integrating the driver for the L2 chip, so it will be useful to symbolically distinguish between them. For now, adding the ID serves to document the distinction between the L1 and L2 chips, as they're alike enough that an atl1 driver hacked with the new PCI ID will detect link status on the L2, even though it won't really work. By getting the ID in now, we can distribute patches that don't touch core code and won't need to be tweaked for submission. If pci_ids.h bloat is really a big deal, we can hold off until the L2 patches are ready, but I don't see the harm in getting this out there now. It is current policy that we do not add PCI ID symbols that are only used in one place. It is pointless to add this. 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
Issue with connector/netlink
Hi Evgenjy,
Again we run into an issue in the connector/netlink code
path. This time we were not able to create a fix. But
please allow me to describe everything:
Kernel: 2.6.20.3
The OOPS:
general protection fault: [1] SMP
CPU 0
Modules linked in: tun nfs lockd nfs_acl sunrpc ipv6 bridge kvm_intel kvm drbd
cn tsde
v i2c_i801 psmouse i2c_core floppy pcspkr serio_raw parport_pc parport evdev
shpchp pc
i_hotplug ext3 jbd mbcache dm_mirror dm_snapshot dm_mod raid1 raid0 md_mod
ide_generic
sd_mod ata_piix libata scsi_mod generic ide_core ehci_hcd uhci_hcd e1000
thermal proc
essor fan
Pid: 1948, comm: cqueue/0 Not tainted 2.6.20.3 #2
RIP: 0010:[8024f904] [8024f904]
netlink_broadcast+0x123/0x2de
RSP: 0018:8100379bddc0 EFLAGS: 00010297
RAX: 656b736968772d31 RBX: 810079d7f800 RCX: 0004
RDX: 81007e113000 RSI: 810079d68280 RDI: 804c6a80
RBP: 810079d68280 R08: 00d0 R09: 810079d68280
R10: 0002 R11: 81007fd6fac0 R12: 0020
R13: R14: 810079d7f818 R15: 0003
FS: () GS:804d6000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2b2acc1ecb40 CR3: 79ac1000 CR4: 26e0
Process cqueue/0 (pid: 1948, threadinfo 8100379bc000, task 810037fd8040)
Stack: 810079d7f400 00d0 81007e113000 7e069a24
0100 810079d7f400 81007e069a10
81007e069a24 881e9d00 81007cf07800 881d5c23
Call Trace:
[881d5c23] :drbd:drbd_connector_callback+0x14f/0x19c
[881b70c3] :cn:cn_queue_wrapper+0x0/0x33
[881b70d8] :cn:cn_queue_wrapper+0x15/0x33
[881b70c3] :cn:cn_queue_wrapper+0x0/0x33
[80247176] run_workqueue+0x8f/0x137
[80243ddc] worker_thread+0x0/0x14a
[8028e63b] keventd_create_kthread+0x0/0x65
[80243ef0] worker_thread+0x114/0x14a
[8027c586] default_wake_function+0x0/0xe
[8022ef0a] kthread+0xd1/0x100
[80256ec8] child_rip+0xa/0x12
[8028e63b] keventd_create_kthread+0x0/0x65
[8022ee39] kthread+0x0/0x100
[80256ebe] child_rip+0x0/0x12
Code: 44 0f a3 38 19 c0 85 c0 0f 84 17 01 00 00 83 7c 24 24 00 74
Decoded:
RIP; 8024f904 netlink_broadcast+123/2de =
RAX; 656b736968772d31 phys_startup_64+656b736968572c31/7f00
RBX; 810079d7f800 phys_startup_64+810079b7f700/7f00
RDX; 81007e113000 phys_startup_64+81007df12f00/7f00
RSI; 810079d68280 phys_startup_64+810079b68180/7f00
RDI; 804c6a80 nl_table_lock+0/10
RBP; 810079d68280 phys_startup_64+810079b68180/7f00
R09; 810079d68280 phys_startup_64+810079b68180/7f00
R11; 81007fd6fac0 phys_startup_64+81007fb6f9c0/7f00
R14; 810079d7f818 phys_startup_64+810079b7f718/7f00
Trace; 881d5c23 _end+7c0ffb3/7f03a390
Trace; 881b70c3 _end+7bf1453/7f03a390
Trace; 881b70d8 _end+7bf1468/7f03a390
Trace; 881b70c3 _end+7bf1453/7f03a390
Trace; 80247176 run_workqueue+8f/137
Trace; 80243ddc worker_thread+0/14a
Trace; 8028e63b keventd_create_kthread+0/65
Trace; 80243ef0 worker_thread+114/14a
Trace; 8027c586 default_wake_function+0/e
Trace; 8022ef0a kthread+d1/100
Trace; 80256ec8 child_rip+a/12
Trace; 8028e63b keventd_create_kthread+0/65
Trace; 8022ee39 kthread+0/100
Trace; 80256ebe child_rip+0/12
Code; 8024f904 netlink_broadcast+123/2de
_RIP:
Code; 8024f904 netlink_broadcast+123/2de =
0: 44 0f a3 38 bt %r15d,(%rax) =
Code; 8024f908 netlink_broadcast+127/2de
4: 19 c0 sbb%eax,%eax
Code; 8024f90a netlink_broadcast+129/2de
6: 85 c0 test %eax,%eax
Code; 8024f90c netlink_broadcast+12b/2de
8: 0f 84 17 01 00 00 je 125 _RIP+0x125
Code; 8024f912 netlink_broadcast+131/2de
e: 83 7c 24 24 00cmpl $0x0,0x24(%rsp)
Code; 8024f917 netlink_broadcast+136/2de
13: 74 00 je 15 _RIP+0x15
It happens in netlink_broadcast() which seems to get called
from drbd_connector_callback(). Drbd_connector_callback()
calls cn_netlink_send(), which in turn calls netlink_broadcast().
I guess this little detail is missing from the trace since
the call to netlink_broadcast() happens with the return
statement in cn_netlink_send().
netlink_broadcast() in turn calls the inlined function
do_one_broadcast(), in which the OOPS happens. It is the test_bit()
call!
static inline int do_one_broadcast(struct sock *sk,
struct netlink_broadcast_data *p)
{
struct netlink_sock *nlk =
Re: many sockets, slow sendto
Hi, Thanks for the patch. I almost dare not confess that I don't know which version to apply to. I tried 3 different ones (2.6.19-r5-gentoo, 2.6.20.1 and 2.6.21-rc4), but in the best case at least two hunks failed. Nevertheless, I applied the patches manually. In each case, UDP stopped working. I guess, you checked the patch and worked. I don't think I made a mistake in the manual copy, and it seems unlikely that your patch interfered with other parallel changes in the kernel - but, I'm just guessing ... I think, I'd better send you the spec and code, as you suggested that first we have a common understanding of the issue. I must have failed in passing the point. I'm removing irrelevant stuff, and I send it to you as soon as I can (sorry for my long delays). thx a lot, Zacco Eric Dumazet wrote: Eric Dumazet a écrit : Currently, udp_hash[UDP_HTABLE_SIZE] is using a hash function based on dport number only. In your case, as you use a single port value, all sockets are in a single slot of this hash table : To find the good socket, __udp4_lib_lookup() has to search in a list with thousands of elements. Not that good, isnt it ? :( In case you want to try, here is a patch that could help you :) [PATCH] INET : IPV4 UDP lookups converted to a 2 pass algo Some people want to have many UDP sockets, binded to a single port but many different addresses. We currently hash all those sockets into a single chain. Processing of incoming packets is very expensive, because the whole chain must be examined to find the best match. I chose in this patch to hash UDP sockets with a hash function that take into account both their port number and address : This has a drawback because we need two lookups : one with a given address, one with a wildcard (null) address. Signed-off-by: Eric Dumazet [EMAIL PROTECTED] - 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: DECnet routing rule resolution
* David Miller [EMAIL PROTECTED] 2007-03-29 11:43 From: Steven Whitehouse [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 17:24:10 +0100 One of the effects of the recent tidy up of the DECnet routing rules code is that we are no longer able to see the difference between reading a rule of type FR_ACT_UNREACHABLE returning -ENETUNREACH and simply running out of rules to look at, which also returns the same thing. The DECnet code used to return -ESRCH if it ran out of rules in which case the test in dn_route.c (which resulted in DECnet falling back to endnode routing in the -ESRCH case) no longer works. So there seems to be several options to try and solve this: one is to change the error return for running out of rules in fib_rules.c:fib_rules_lookup() to something else (but then that has a knock on effect in the ipv4 code). Another is to add the not found error return as a parameter in the struct fib_rules_ops so that both protocols can have their preferred error return. Both solutions seem a bit messy, so I thought I'd ask for some guidance on this before writing a patch, I think we should be able to return -ESRCH (a more sensible error value if you ask me) across the board. Thomas what do you think? I agree. - 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
[PATCH] add NAPI support to sb1250-mac.c (take 2)
Patch to add NAPI support to sb1250-mac.c (rev 2). This patch differs from
the last in that the NAPI support isn't marked as experimental, nor is it
configurable (ie. once applied - NAPI is enabled all the time). This was
based on feedback from Ralf and others.
Signed-off-by: Mark Mason [EMAIL PROTECTED]
---
drivers/net/sb1250-mac.c | 278 ++
1 files changed, 182 insertions(+), 96 deletions(-)
diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c
index 103c317..f8df1ec 100644
--- a/drivers/net/sb1250-mac.c
+++ b/drivers/net/sb1250-mac.c
@@ -95,19 +95,28 @@ MODULE_PARM_DESC(full_duplex, 1-
__MODULE_STRING(MAX_UNITS));
#endif
#ifdef CONFIG_SBMAC_COALESCE
-static int int_pktcnt = 0;
-module_param(int_pktcnt, int, S_IRUGO);
-MODULE_PARM_DESC(int_pktcnt, Packet count);
+static int int_pktcnt_tx = 255;
+module_param(int_pktcnt_tx, int, S_IRUGO);
+MODULE_PARM_DESC(int_pktcnt_tx, TX packet count);
-static int int_timeout = 0;
-module_param(int_timeout, int, S_IRUGO);
-MODULE_PARM_DESC(int_timeout, Timeout value);
+static int int_timeout_tx = 255;
+module_param(int_timeout_tx, int, S_IRUGO);
+MODULE_PARM_DESC(int_timeout_tx, TX timeout value);
+
+static int int_pktcnt_rx = 64;
+module_param(int_pktcnt_rx, int, S_IRUGO);
+MODULE_PARM_DESC(int_pktcnt_rx, RX packet count);
+
+static int int_timeout_rx = 64;
+module_param(int_timeout_rx, int, S_IRUGO);
+MODULE_PARM_DESC(int_timeout_rx, RX timeout value);
#endif
#include asm/sibyte/sb1250.h
#if defined(CONFIG_SIBYTE_BCM1x55) || defined(CONFIG_SIBYTE_BCM1x80)
#include asm/sibyte/bcm1480_regs.h
#include asm/sibyte/bcm1480_int.h
+#define R_MAC_DMA_OODPKTLOST_RXR_MAC_DMA_OODPKTLOST
#elif defined(CONFIG_SIBYTE_SB1250) || defined(CONFIG_SIBYTE_BCM112X)
#include asm/sibyte/sb1250_regs.h
#include asm/sibyte/sb1250_int.h
@@ -155,8 +164,8 @@ typedef enum { sbmac_state_uninit, sbmac_state_off,
sbmac_state_on,
#define NUMCACHEBLKS(x) (((x)+SMP_CACHE_BYTES-1)/SMP_CACHE_BYTES)
-#define SBMAC_MAX_TXDESCR 32
-#define SBMAC_MAX_RXDESCR 32
+#define SBMAC_MAX_TXDESCR 256
+#define SBMAC_MAX_RXDESCR 256
#define ETHER_ALIGN2
#define ETHER_ADDR_LEN 6
@@ -185,10 +194,10 @@ typedef struct sbmacdma_s {
* associated with it.
*/
- struct sbmac_softc *sbdma_eth; /* back pointer to associated
MAC */
- int sbdma_channel; /* channel number */
+ struct sbmac_softc *sbdma_eth; /* back pointer to associated MAC */
+ int sbdma_channel; /* channel number */
int sbdma_txdir; /* direction (1=transmit) */
- int sbdma_maxdescr;/* total # of descriptors in
ring */
+ int sbdma_maxdescr;/* total # of descriptors in ring */
#ifdef CONFIG_SBMAC_COALESCE
int sbdma_int_pktcnt; /* # descriptors rx/tx before
interrupt*/
int sbdma_int_timeout; /* # usec rx/tx interrupt */
@@ -197,13 +206,16 @@ typedef struct sbmacdma_s {
volatile void __iomem *sbdma_config0; /* DMA config register 0 */
volatile void __iomem *sbdma_config1; /* DMA config register 1 */
volatile void __iomem *sbdma_dscrbase; /* Descriptor base address */
- volatile void __iomem *sbdma_dscrcnt; /* Descriptor count register
*/
+ volatile void __iomem *sbdma_dscrcnt; /* Descriptor count register */
volatile void __iomem *sbdma_curdscr; /* current descriptor address */
+ volatile void __iomem *sbdma_oodpktlost;/* pkt drop (rx only) */
+
/*
* This stuff is for maintenance of the ring
*/
+ sbdmadscr_t *sbdma_dscrtable_unaligned;
sbdmadscr_t *sbdma_dscrtable; /* base of descriptor table */
sbdmadscr_t *sbdma_dscrtable_end; /* end of descriptor table */
@@ -286,8 +298,8 @@ static int sbdma_add_rcvbuffer(sbmacdma_t *d,struct sk_buff
*m);
static int sbdma_add_txbuffer(sbmacdma_t *d,struct sk_buff *m);
static void sbdma_emptyring(sbmacdma_t *d);
static void sbdma_fillring(sbmacdma_t *d);
-static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d);
-static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d);
+static int sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d, int
work_to_do, int poll);
+static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll);
static int sbmac_initctx(struct sbmac_softc *s);
static void sbmac_channel_start(struct sbmac_softc *s);
static void sbmac_channel_stop(struct sbmac_softc *s);
@@ -308,6 +320,8 @@ static struct net_device_stats *sbmac_get_stats(struct
net_device *dev);
static void sbmac_set_rx_mode(struct net_device *dev);
static int sbmac_mii_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static int sbmac_close(struct net_device *dev);
+static int sbmac_poll(struct net_device *poll_dev, int *budget);
+
static
[PATCH][IPv6]: Fix incorrect length check in rawv6_sendmsg()
The check for length in rawv6_sendmsg() is incorrect. As len is an unsigned int, (len 0) will never be TRUE. I think checking for IPV6_MAXPLEN(65535) is better. Is it possible to send ipv6 jumbo packets using raw sockets? If so, we can remove this check. Thanks Sridhar Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c index 306d5d8..dc11ec3 100644 --- a/net/ipv6/raw.c +++ b/net/ipv6/raw.c @@ -686,10 +686,7 @@ static int rawv6_sendmsg(struct kiocb *i u16 proto; int err; - /* Rough check on arithmetic overflow, - better check is made in ip6_build_xmit -*/ - if (len 0) + if (len IPV6_MAXPLEN) return -EMSGSIZE; /* Mirror BSD error message compatibility */ - 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: [PATCH][IPv6]: Fix incorrect length check in rawv6_sendmsg()
From: Sridhar Samudrala [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 14:17:28 -0700 The check for length in rawv6_sendmsg() is incorrect. As len is an unsigned int, (len 0) will never be TRUE. I think checking for IPV6_MAXPLEN(65535) is better. Is it possible to send ipv6 jumbo packets using raw sockets? If so, we can remove this check. I don't see why such a limitation against jumbo would exist, does anyone else? Thanks for catching this Sridhar. A good compiler should simply fail to compile if (x 0) when 'x' is an unsigned type, don't you think :-) - 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: [Bonding-devel] quick help with bonding?
Andy Gospodarek wrote: Can you elaborate on what isn't going well with this driver/hardware? I have a ppc64 blade running a customized 2.6.10. At init time, two of our gigE links (eth4 and eth5) are bonded together to form bond0. This link has an MTU of 9000, and uses arp monitoring. We're using an ethernet driver with a modified RX path for jumbo frames[1]. With the stock driver, it seems to work fine. The problem is that eth5 seems to be bouncing up and down every 15 sec or so (see the attached log excerpt). Also, ifconfig shows that only 3 packets totalling 250 bytes have gone out eth5, when I know that the arp monitoring code from the bond layer is sending 10 arps/sec out the link. eth5 Link encap:Ethernet HWaddr 00:03:CC:51:01:3E inet6 addr: fe80::203:ccff:fe51:13e/64 Scope:Link UP BROADCAST RUNNING SLAVE MULTICAST MTU:9000 Metric:1 RX packets:119325 errors:90283 dropped:90283 overruns:90283 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8978310 (8.5 MiB) TX bytes:250 (250.0 b) Base address:0x3840 Memory:9222-9224 I had initially suspected that it might be due to the u32 jiffies stuff in bonding.h, but changing that doesn't seem to fix the issue. If I boot the system and then log in and manually create the bond link (rather than it happening at init time) then I don't see the problem. If it matters at all, normally the system boots from eth4. I'm going to try booting from eth6 and see if the problem still occurs. Chris [1] I'm not sure if I'm supposed to mention the specific driver, as it hasn't been officially released yet, so I'll keep this high-level. Normally for jumbo frames you need to allocate a large physically contiguous buffer. With the modified driver, rather than receiving into a contiguous buffer the incoming packet is split across multiple pages which are then reassembled into an sk_buff and passed up the link. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: ARP monitoring set to 100 ms with 2 target(s): 172.24.136.0 172.24.137.0 Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: ARP monitoring set to 100 ms with 2 target(s): 172.25.136.0 172.25.137.0 Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: Warning: failed to get speed/duplex from eth4, speed forced to 100Mbps, duplex forced to Full. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: enslaving eth4 as an active interface with an up link. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: Warning: failed to get speed/duplex from eth5, speed forced to 100Mbps, duplex forced to Full. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: enslaving eth5 as an active interface with an up link. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: scheduling interface eth5 to be reset in 3 msec. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth5 is now down. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: scheduling interface eth4 to be reset in 3 msec. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth4 is now down. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: now running without any active interface ! Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: cancelled scheduled reset of interface eth5 Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: link status definitely up for interface eth5 Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: cancelled scheduled reset of interface eth4 Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth4 is now up Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: scheduling interface eth5 to be reset in 3 msec. Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth5 is now down. Mar 29 20:54:09 base0-0-0-5-0-11-1 kernel: bonding: interface eth4 reset delay set to 600 msec. Mar 29 20:54:59 base0-0-0-5-0-11-1 kernel: bonding: bond0: cancelled scheduled reset of interface eth5 Mar 29 20:54:59 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth5 is now up Mar 29 20:54:59 base0-0-0-5-0-11-1 kernel: bonding: bond0: scheduling interface eth5 to be reset in 3 msec. Mar 29 20:54:59 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth5 is now down. Mar 29 20:55:15 base0-0-0-5-0-11-1 kernel: bonding: bond0: cancelled scheduled reset of interface eth5 Mar 29 20:55:15 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth5 is now up Mar 29 20:55:15 base0-0-0-5-0-11-1 kernel: bonding: bond0: scheduling interface eth5 to be reset in 3 msec. Mar 29 20:55:15 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth5 is now down. Mar 29 20:55:30 base0-0-0-5-0-11-1 kernel: bonding: bond0: cancelled scheduled reset of interface eth5 Mar 29 20:55:30 base0-0-0-5-0-11-1 kernel: bonding: bond0: interface eth5 is now up
Re: [Bonding-devel] quick help with bonding?
Chris Friesen [EMAIL PROTECTED] wrote: [...] I have a ppc64 blade running a customized 2.6.10. At init time, two of our gigE links (eth4 and eth5) are bonded together to form bond0. This link has an MTU of 9000, and uses arp monitoring. We're using an ethernet driver with a modified RX path for jumbo frames[1]. With the stock driver, it seems to work fine. 2.6.10 is pretty old, and there have been a number of fixes to the bonding ARP monitor since then, so it may be that it is simply misbehaving (presuming that you're running the 2.6.10 bonding driver). Are you in a position to test against a more recent kernel (and/or bonding driver)? Does the miimon misbehave in a similar fashion? The problem is that eth5 seems to be bouncing up and down every 15 sec or so (see the attached log excerpt). Also, ifconfig shows that only 3 packets totalling 250 bytes have gone out eth5, when I know that the arp monitoring code from the bond layer is sending 10 arps/sec out the link. [...] Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: scheduling interface eth4 to be reset in 3 msec. [...] Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: cancelled scheduled reset of interface eth5 These two messages (which appear a number of times in your log excerpt) are not from the standard mainline bonding driver, even in 2.6.10. I don't know what this is all about. If I boot the system and then log in and manually create the bond link (rather than it happening at init time) then I don't see the problem. I would hazard to guess that it's an ARP monitor problem; older versions of the ARP monitor had less than intelligent means to figure out what the bond's IP address is (to use for the probes). This, along with some logic problems in the monitor code itself, led to various problems with the ARP probes and the sort of up / down cycle of behavior you seem to be seeing. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - 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
[-MM GIT PULL] e1000: fixes, API rewrite, cleanups
Andrew, Please consider pulling from my git tree: git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 mm To get a copy of my current e1000 queue. This tree consists of a recent 'master' branch from linus, and the following patches: 1) 3 patches from jgarzik's e1000-fixes tree 2) 3 patches from jgarzik's upstream branch 3) the hardware initialization API rewrite (as a single commit) patch posted on netdev yesterday 4) 15 other fixes and cleanups currently in my e1000 queue All patches from 3) onwards are also available to view over here: http://foo-projects.org/~sofar/patches-20070327/ Cheers, Auke --- commit a6f63e313c5a26340f52884c52492668a555c38b Author: Auke Kok [EMAIL PROTECTED] Date: Thu Mar 29 14:59:38 2007 -0700 e1000: Update version, typo fixes, date Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 18a6e4b... 3fc332a... M drivers/net/e1000/e1000.h :100644 100644 8a412c5... 05a0573... M drivers/net/e1000/e1000_ethtool.c :100644 100644 4d8443a... b157359... M drivers/net/e1000/e1000_main.c :100644 100644 3dc17ed... bd2d28a... M drivers/net/e1000/e1000_osdep.h :100644 100644 8bcb377... 95a39c0... M drivers/net/e1000/e1000_param.c commit 67de893160519308ca33248fb4b8e30f7cc1cf8f Author: Bruce Allan [EMAIL PROTECTED] Date: Thu Mar 29 14:59:26 2007 -0700 e1000: insufficient use of DRV_LOAD bit causing firmware to take control The CTRL_EXT.DRV_LOAD bit was being cleared in the driver on every MAC reset (e.g. when the interface was down'ed) and not being properly set again (e.g. when the interface was re-up'ed). This caused AMT to think it was the sole owner of the h/w which consequently forced the PHY to 100Mbps since the f/w folks chose not to support 1000Mbps in order to not have to implement the Nineveh PHY powerdown workaround. Signed-off-by: Bruce Allan [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 e3b2e52... 4d8443a... M drivers/net/e1000/e1000_main.c commit 8d4d8333b64c6251ccb6eae56ea49efc6fc49f95 Author: Auke Kok [EMAIL PROTECTED] Date: Thu Mar 29 14:59:18 2007 -0700 e1000: Free interrupts symmetrically with resume Free interrupts symmetrically with resume allocation to prevent pci save/restore state from possibly failing or warning. Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 07f7e98... e3b2e52... M drivers/net/e1000/e1000_main.c commit 91f0e3ed1deef5183fc7a5ce9a424b01f79d4810 Author: Jesse Brandeburg [EMAIL PROTECTED] Date: Thu Mar 29 14:59:06 2007 -0700 e1000: fix empty frame only containing a crc from being dumped A cornercase fragment could contain only the CRC but considered empty after crc stripping. Make sure we account for that. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 69a204b... 07f7e98... M drivers/net/e1000/e1000_main.c commit 4d4b5ac4ab84de1f693c976764eb33b6aa1585c3 Author: Bruce Allan [EMAIL PROTECTED] Date: Thu Mar 29 14:58:57 2007 -0700 e1000: Fix some stats being collected on adapters that don't have them Several stats were being collected on ich8 that don't exist there. Signed-off-by: Bruce Allan [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 6037e78... 69a204b... M drivers/net/e1000/e1000_main.c commit 39db87a668ed8aac1dd75befd5f6f48dda0e3db7 Author: Bruce Allan [EMAIL PROTECTED] Date: Thu Mar 29 14:58:38 2007 -0700 e1000: fix two ich8 errata: tx timeouot factor and cable unplug issue for 10/100 modes, a simple incoming ping-flood could cause TX to delay long enough to scream 'TX hung' which was false. Extend the timeout factor for 10/100 speed. On a rare occasion, an ich8 device may lose link after a cable unplug event with the PHY. Downshifting the link prevents us from reading garbage from the PHY and makes sure that the PHY is accessible. Signed-off-by: Bruce Allan [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 90cffc4... 6037e78... M drivers/net/e1000/e1000_main.c commit 38fe2f8adb14761600d571f3ec269c55060e0da3 Author: Auke Kok [EMAIL PROTECTED] Date: Thu Mar 29 14:58:30 2007 -0700 e1000: skip unneeded PHY reads in watchdog when link is OK Several PHY reads that are costly can be omitted if the link is up and netdev as well. Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 4a322ae... 90cffc4... M drivers/net/e1000/e1000_main.c commit 95a01c8a78bc2e51dad8c0e667141023cb323e51 Author: Jesse Brandeburg [EMAIL PROTECTED] Date: Thu Mar 29 14:58:23 2007 -0700 e1000: set timestamps before dma unmapping on the off chance that the check of buffer_info-dma returns true when buffer_info-time_stamp hasn't been filled in yet, reverse the order of
Re: [Bonding-devel] quick help with bonding?
Jay Vosburgh wrote: Chris Friesen [EMAIL PROTECTED] wrote: [...] I have a ppc64 blade running a customized 2.6.10. At init time, two of our gigE links (eth4 and eth5) are bonded together to form bond0. This link has an MTU of 9000, and uses arp monitoring. We're using an ethernet driver with a modified RX path for jumbo frames[1]. With the stock driver, it seems to work fine. 2.6.10 is pretty old, and there have been a number of fixes to the bonding ARP monitor since then, so it may be that it is simply misbehaving (presuming that you're running the 2.6.10 bonding driver). Are you in a position to test against a more recent kernel (and/or bonding driver)? Does the miimon misbehave in a similar fashion? The problem is that eth5 seems to be bouncing up and down every 15 sec or so (see the attached log excerpt). Also, ifconfig shows that only 3 packets totalling 250 bytes have gone out eth5, when I know that the arp monitoring code from the bond layer is sending 10 arps/sec out the link. [...] Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: scheduling interface eth4 to be reset in 3 msec. [...] Mar 29 20:54:08 base0-0-0-5-0-11-1 kernel: bonding: bond0: cancelled scheduled reset of interface eth5 These two messages (which appear a number of times in your log excerpt) are not from the standard mainline bonding driver, even in 2.6.10. I don't know what this is all about. If I boot the system and then log in and manually create the bond link (rather than it happening at init time) then I don't see the problem. I would hazard to guess that it's an ARP monitor problem; older versions of the ARP monitor had less than intelligent means to figure out what the bond's IP address is (to use for the probes). This, along with some logic problems in the monitor code itself, led to various problems with the ARP probes and the sort of up / down cycle of behavior you seem to be seeing. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - I'll second what Jay said. I support a version of the 2.6.10 kernel with bonding, and I needed to upgrade the bonding that was native to 2.6.10 to get reasonable behavior. You may also need a newer ifenslave. It also looks like the mii interface is not well-behaved, because of the initialization messages related to link speed. - 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
[PATCH 2.6.21-rc5] bnx2: fix buffer overrun in bnx2_nvram_write
A buffer overrun issue exists in the bnx2_nvram_write function. This
issue
is exposed by calling ethtool to write to the eeprom as shown below.
ethtool -E eth4 magic 0x669955AA offset 0x137 value 0xC4
The problem happens when align_buf is allocated only 2 bytes in the
kmalloc
call and later 4 bytes written to it. The len32 variable is calculated
in the
below code segment at around line 3102.
if ((align_start = (offset32 3))) {
offset32 = ~3;
len32 += (4 - align_start);
:
The next if conditional in the code that could alter these values is
not
entered, so we end up with:
len32=2
align_start=3
offset32=308
This results in align_buf being allocated 2 bytes, and overwritten with
4 bytes in the if (align_start) segment just below the allocation.
I made a change adjust the len32 to the next 4 byte boundary.
I also made changes so the call to erase the eeprom page is not called
unless
the page will be written. To achieve this I just moved the code inside
the
conditional that writes the page. After doing this I realized the page
erase
functions were no-ops since the same conditional checked for before the
page
is written in this function is checked in the erase function. I left the
changes in because it makes it more logical and removes unneeded calls.
Also note that if len32 is not on a 4 byte boundary the, data_end
variable
(offset32 + len32 in this case) will never equal data_start plus a
multiple of 4 to cause the BNX2_NVM_COMMAND_LAST to be issued to the
board
at around line 3220.
Signed-Off-By: Tony Cureington ([EMAIL PROTECTED])
--- linux-2.6.21-rc5.orig/drivers/net/bnx2.c2007-03-29
12:49:33.0 -0500
+++ linux/drivers/net/bnx2.c2007-03-29 17:06:36.0 -0500
@@ -3116,6 +3116,10 @@
}
if (align_start || align_end) {
+ if (len323) {
+ // adjust to 4 byte boundary
+ len32 += 4-(len323);
+ }
align_buf = kmalloc(len32, GFP_KERNEL);
if (align_buf == NULL)
return -ENOMEM;
@@ -3187,17 +3191,17 @@
if ((rc = bnx2_enable_nvram_write(bp)) != 0)
goto nvram_write_end;
- /* Erase the page */
- if ((rc = bnx2_nvram_erase_page(bp, page_start)) != 0)
- goto nvram_write_end;
-
- /* Re-enable the write again for the actual write */
- bnx2_enable_nvram_write(bp);
-
/* Loop to write back the buffer data from page_start to
* data_start */
i = 0;
if (bp-flash_info-buffered == 0) {
+ /* Erase the page */
+ if ((rc = bnx2_nvram_erase_page(bp, page_start))
!= 0)
+ goto nvram_write_end;
+
+ /* Re-enable the write again for the actual
write */
+ bnx2_enable_nvram_write(bp);
+
for (addr = page_start; addr data_start;
addr += 4, i += 4) {
-
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: traffic shaping with NAT: IFB as IMQ replacement?
Hi, Linux router: - does NAT for the LANs - runs local processes communicating with the WAN/Internet I understand this requirement; unfortunately when i polled for features majority of people who emailed back were asking for the other things. I have changed my opinion a little since last time because the netfilter/contracking code now does netlink. I believe this could all be achieved in user space. Infact i have started writting some code - the I'm also interested in shaping NAT. Would you mind telling us what you have in mind with your userspace code? Do you plan something like tun - your userspace code - tun ^ | (netlink) v conntrack Kind regards, Gerd - 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: [PATCH][IPv6]: Fix incorrect length check in rawv6_sendmsg()
On Thu, Mar 29, 2007 at 14:26:44 -0700, David Miller wrote: From: Sridhar Samudrala [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 14:17:28 -0700 The check for length in rawv6_sendmsg() is incorrect. As len is an unsigned int, (len 0) will never be TRUE. I think checking for IPV6_MAXPLEN(65535) is better. Is it possible to send ipv6 jumbo packets using raw sockets? If so, we can remove this check. I don't see why such a limitation against jumbo would exist, does anyone else? Thanks for catching this Sridhar. A good compiler should simply fail to compile if (x 0) when 'x' is an unsigned type, don't you think :-) gcc warns if you use -W or -Wextra (but not if only -Wall is used): * An unsigned value is compared against zero with '' or '='. -- Do what you love because life is too short for anything else. - 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: [-MM GIT PULL] e1000: fixes, API rewrite, cleanups
On Thu Mar 29 15:50:55 PDT 2007
Auke Kok [EMAIL PROTECTED] wrote:
Please consider pulling from my git tree:
git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 mm
To get a copy of my current e1000 queue. This tree consists of a recent
'master' branch from linus, and the following patches:
1) 3 patches from jgarzik's e1000-fixes tree
2) 3 patches from jgarzik's upstream branch
3) the hardware initialization API rewrite (as a single commit) patch
posted on netdev yesterday
4) 15 other fixes and cleanups currently in my e1000 queue
OK. I got quite a lot of git carnage when generating the git-netdev-all
versus git-e1000 diff. But as long as things don't change too much we
should be OK.
What I do when this happens is to manually create a remove-the-git-rejects
patch. Hope I got it right..
Davem's tree diddles e1000_main.c as well, so whoever merges second has
a little bit of rework to do.
The current davem diff is 2.2MB, touching 852 files. Nobody breathe...
drivers/net/e1000/e1000_ethtool.c |5 -
drivers/net/e1000/e1000_main.c| 91
2 files changed, 96 deletions(-)
diff -puN drivers/net/e1000/e1000_ethtool.c~git-e1000-fixup
drivers/net/e1000/e1000_ethtool.c
--- a/drivers/net/e1000/e1000_ethtool.c~git-e1000-fixup
+++ a/drivers/net/e1000/e1000_ethtool.c
@@ -1046,13 +1046,8 @@ e1000_setup_desc_rings(struct e1000_adap
struct e1000_tx_ring *txdr = adapter-test_tx_ring;
struct e1000_rx_ring *rxdr = adapter-test_rx_ring;
struct pci_dev *pdev = adapter-pdev;
- HEAD/drivers/net/e1000/e1000_ethtool.c
- uint32_t rctl;
- int i, ret_val;
-===
u32 rctl;
int i, ret_val;
- /drivers/net/e1000/e1000_ethtool.c
/* Setup Tx descriptor ring and Tx buffers */
diff -puN drivers/net/e1000/e1000_main.c~git-e1000-fixup
drivers/net/e1000/e1000_main.c
--- a/drivers/net/e1000/e1000_main.c~git-e1000-fixup
+++ a/drivers/net/e1000/e1000_main.c
@@ -425,42 +425,22 @@ e1000_update_mng_vlan(struct e1000_adapt
static void
e1000_release_hw_control(struct e1000_adapter *adapter)
{
- HEAD/drivers/net/e1000/e1000_main.c
- uint32_t ctrl_ext;
- uint32_t swsm;
-===
u32 ctrl_ext;
u32 swsm;
- /drivers/net/e1000/e1000_main.c
/* Let firmware taken over control of h/w */
- HEAD/drivers/net/e1000/e1000_main.c
- switch (adapter-hw.mac_type) {
- case e1000_82573:
- swsm = E1000_READ_REG(adapter-hw, SWSM);
- E1000_WRITE_REG(adapter-hw, SWSM,
- swsm ~E1000_SWSM_DRV_LOAD);
- break;
-===
switch (adapter-hw.mac.type) {
case e1000_82573:
swsm = E1000_READ_REG(adapter-hw, E1000_SWSM);
E1000_WRITE_REG(adapter-hw, E1000_SWSM,
swsm ~E1000_SWSM_DRV_LOAD);
break;
- /drivers/net/e1000/e1000_main.c
case e1000_82571:
case e1000_82572:
case e1000_80003es2lan:
- HEAD/drivers/net/e1000/e1000_main.c
- case e1000_ich8lan:
- ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
- E1000_WRITE_REG(adapter-hw, CTRL_EXT,
-===
case e1000_ich8lan:
ctrl_ext = E1000_READ_REG(adapter-hw, E1000_CTRL_EXT);
E1000_WRITE_REG(adapter-hw, E1000_CTRL_EXT,
- /drivers/net/e1000/e1000_main.c
ctrl_ext ~E1000_CTRL_EXT_DRV_LOAD);
break;
default:
@@ -482,42 +462,22 @@ e1000_release_hw_control(struct e1000_ad
static void
e1000_get_hw_control(struct e1000_adapter *adapter)
{
- HEAD/drivers/net/e1000/e1000_main.c
- uint32_t ctrl_ext;
- uint32_t swsm;
-===
u32 ctrl_ext;
u32 swsm;
- /drivers/net/e1000/e1000_main.c
/* Let firmware know the driver has taken over */
- HEAD/drivers/net/e1000/e1000_main.c
- switch (adapter-hw.mac_type) {
- case e1000_82573:
- swsm = E1000_READ_REG(adapter-hw, SWSM);
- E1000_WRITE_REG(adapter-hw, SWSM,
- swsm | E1000_SWSM_DRV_LOAD);
- break;
-===
switch (adapter-hw.mac.type) {
case e1000_82573:
swsm = E1000_READ_REG(adapter-hw, E1000_SWSM);
E1000_WRITE_REG(adapter-hw, E1000_SWSM,
swsm | E1000_SWSM_DRV_LOAD);
break;
- /drivers/net/e1000/e1000_main.c
case e1000_82571:
case e1000_82572:
case e1000_80003es2lan:
- HEAD/drivers/net/e1000/e1000_main.c
- case e1000_ich8lan:
- ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
- E1000_WRITE_REG(adapter-hw, CTRL_EXT,
-===
case e1000_ich8lan:
ctrl_ext = E1000_READ_REG(adapter-hw, E1000_CTRL_EXT);
E1000_WRITE_REG(adapter-hw, E1000_CTRL_EXT,
- /drivers/net/e1000/e1000_main.c
Re: [-MM GIT PULL] e1000: fixes, API rewrite, cleanups
Andrew Morton wrote:
On Thu Mar 29 15:50:55 PDT 2007
Auke Kok [EMAIL PROTECTED] wrote:
Please consider pulling from my git tree:
git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 mm
To get a copy of my current e1000 queue. This tree consists of a recent
'master' branch from linus, and the following patches:
1) 3 patches from jgarzik's e1000-fixes tree
2) 3 patches from jgarzik's upstream branch
3) the hardware initialization API rewrite (as a single commit) patch
posted on netdev yesterday
4) 15 other fixes and cleanups currently in my e1000 queue
OK. I got quite a lot of git carnage when generating the git-netdev-all
versus git-e1000 diff. But as long as things don't change too much we
should be OK.
What I do when this happens is to manually create a remove-the-git-rejects
patch. Hope I got it right..
Davem's tree diddles e1000_main.c as well, so whoever merges second has
a little bit of rework to do.
The current davem diff is 2.2MB, touching 852 files. Nobody breathe...
it looks about right. I'll try to verify tomorrow that it is OK.
Thanks,
Auke
drivers/net/e1000/e1000_ethtool.c |5 -
drivers/net/e1000/e1000_main.c| 91
2 files changed, 96 deletions(-)
diff -puN drivers/net/e1000/e1000_ethtool.c~git-e1000-fixup
drivers/net/e1000/e1000_ethtool.c
--- a/drivers/net/e1000/e1000_ethtool.c~git-e1000-fixup
+++ a/drivers/net/e1000/e1000_ethtool.c
@@ -1046,13 +1046,8 @@ e1000_setup_desc_rings(struct e1000_adap
struct e1000_tx_ring *txdr = adapter-test_tx_ring;
struct e1000_rx_ring *rxdr = adapter-test_rx_ring;
struct pci_dev *pdev = adapter-pdev;
- HEAD/drivers/net/e1000/e1000_ethtool.c
- uint32_t rctl;
- int i, ret_val;
-===
u32 rctl;
int i, ret_val;
- /drivers/net/e1000/e1000_ethtool.c
/* Setup Tx descriptor ring and Tx buffers */
diff -puN drivers/net/e1000/e1000_main.c~git-e1000-fixup drivers/net/e1000/e1000_main.c
--- a/drivers/net/e1000/e1000_main.c~git-e1000-fixup
+++ a/drivers/net/e1000/e1000_main.c
@@ -425,42 +425,22 @@ e1000_update_mng_vlan(struct e1000_adapt
static void
e1000_release_hw_control(struct e1000_adapter *adapter)
{
- HEAD/drivers/net/e1000/e1000_main.c
- uint32_t ctrl_ext;
- uint32_t swsm;
-===
u32 ctrl_ext;
u32 swsm;
- /drivers/net/e1000/e1000_main.c
/* Let firmware taken over control of h/w */
- HEAD/drivers/net/e1000/e1000_main.c
- switch (adapter-hw.mac_type) {
- case e1000_82573:
- swsm = E1000_READ_REG(adapter-hw, SWSM);
- E1000_WRITE_REG(adapter-hw, SWSM,
- swsm ~E1000_SWSM_DRV_LOAD);
- break;
-===
switch (adapter-hw.mac.type) {
case e1000_82573:
swsm = E1000_READ_REG(adapter-hw, E1000_SWSM);
E1000_WRITE_REG(adapter-hw, E1000_SWSM,
swsm ~E1000_SWSM_DRV_LOAD);
break;
- /drivers/net/e1000/e1000_main.c
case e1000_82571:
case e1000_82572:
case e1000_80003es2lan:
- HEAD/drivers/net/e1000/e1000_main.c
- case e1000_ich8lan:
- ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
- E1000_WRITE_REG(adapter-hw, CTRL_EXT,
-===
case e1000_ich8lan:
ctrl_ext = E1000_READ_REG(adapter-hw, E1000_CTRL_EXT);
E1000_WRITE_REG(adapter-hw, E1000_CTRL_EXT,
- /drivers/net/e1000/e1000_main.c
ctrl_ext ~E1000_CTRL_EXT_DRV_LOAD);
break;
default:
@@ -482,42 +462,22 @@ e1000_release_hw_control(struct e1000_ad
static void
e1000_get_hw_control(struct e1000_adapter *adapter)
{
- HEAD/drivers/net/e1000/e1000_main.c
- uint32_t ctrl_ext;
- uint32_t swsm;
-===
u32 ctrl_ext;
u32 swsm;
- /drivers/net/e1000/e1000_main.c
/* Let firmware know the driver has taken over */
- HEAD/drivers/net/e1000/e1000_main.c
- switch (adapter-hw.mac_type) {
- case e1000_82573:
- swsm = E1000_READ_REG(adapter-hw, SWSM);
- E1000_WRITE_REG(adapter-hw, SWSM,
- swsm | E1000_SWSM_DRV_LOAD);
- break;
-===
switch (adapter-hw.mac.type) {
case e1000_82573:
swsm = E1000_READ_REG(adapter-hw, E1000_SWSM);
E1000_WRITE_REG(adapter-hw, E1000_SWSM,
swsm | E1000_SWSM_DRV_LOAD);
break;
- /drivers/net/e1000/e1000_main.c
case e1000_82571:
case e1000_82572:
case e1000_80003es2lan:
- HEAD/drivers/net/e1000/e1000_main.c
- case e1000_ich8lan:
- ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
- E1000_WRITE_REG(adapter-hw, CTRL_EXT,
-===
case e1000_ich8lan:
ctrl_ext = E1000_READ_REG(adapter-hw, E1000_CTRL_EXT);
Re: [Bonding-devel] quick help with bonding?
Jay Vosburgh wrote: 2.6.10 is pretty old, and there have been a number of fixes to the bonding ARP monitor since then, so it may be that it is simply misbehaving (presuming that you're running the 2.6.10 bonding driver). Are you in a position to test against a more recent kernel (and/or bonding driver)? Does the miimon misbehave in a similar fashion? Testing a more recent kernel is problematic. A new bonding driver could be possible, assuming the code hasn't changed too much. I just did another experiment. Normally we boot via eth4 (which then becomes part of the bond with eth5 at init time). If I boot via eth6 instead, it appears as though the problem doesn't show up. Chris - 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: [PATCH][IPv6]: Fix incorrect length check in rawv6_sendmsg()
In article [EMAIL PROTECTED] (at Thu, 29 Mar 2007 14:26:44 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: From: Sridhar Samudrala [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 14:17:28 -0700 The check for length in rawv6_sendmsg() is incorrect. As len is an unsigned int, (len 0) will never be TRUE. I think checking for IPV6_MAXPLEN(65535) is better. Is it possible to send ipv6 jumbo packets using raw sockets? If so, we can remove this check. I don't see why such a limitation against jumbo would exist, does anyone else? Thanks for catching this Sridhar. A good compiler should simply fail to compile if (x 0) when 'x' is an unsigned type, don't you think :-) Dave, we use int for returning value, so we should fix this anyway, IMHO; we should not allow len INT_MAX. Don't you think so? Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c index 306d5d8..203e069 100644 --- a/net/ipv6/raw.c +++ b/net/ipv6/raw.c @@ -687,9 +687,9 @@ static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk, int err; /* Rough check on arithmetic overflow, - better check is made in ip6_build_xmit + better check is made in ip6_append_data(). */ - if (len 0) + if (len INT_MAX) return -EMSGSIZE; /* Mirror BSD error message compatibility */ diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index 0ad4719..f590db5 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -615,7 +615,7 @@ do_udp_sendmsg: return udp_sendmsg(iocb, sk, msg, len); /* Rough check on arithmetic overflow, - better check is made in ip6_build_xmit + better check is made in ip6_append_data(). */ if (len INT_MAX - sizeof(struct udphdr)) return -EMSGSIZE; --yoshfuji - 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: [-MM GIT PULL] e1000: fixes, API rewrite, cleanups
On Thu, 29 Mar 2007 17:03:24 -0700 Kok, Auke [EMAIL PROTECTED] wrote: The current davem diff is 2.2MB, touching 852 files. Nobody breathe... Just for giggles: git-net: 852 files changed, 10326 insertions(+), 27095 deletions(-) git-netdev-all: 146 files changed, 39390 insertions(+), 3099 deletions(-) git-wireless: 201 files changed, 85602 insertions(+), 620 deletions(-) git-e1000: 32 files changed, 20117 insertions(+), 13478 deletions(-) git-ipwireless_cs: 11 files changed, 3619 insertions(+) for a total of nearly 8MB of networking diff. They flower in the Spring, obviously. it looks about right. I'll try to verify tomorrow that it is OK. I'll get what I have now compiling and booting and then I'll shove another -mm out the door. Hopefully this evening.. - 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: [Bonding-devel] quick help with bonding?
Chris Friesen [EMAIL PROTECTED] wrote: Jay Vosburgh wrote: 2.6.10 is pretty old, and there have been a number of fixes to the bonding ARP monitor since then, so it may be that it is simply misbehaving (presuming that you're running the 2.6.10 bonding driver). Are you in a position to test against a more recent kernel (and/or bonding driver)? Does the miimon misbehave in a similar fashion? Testing a more recent kernel is problematic. A new bonding driver could be possible, assuming the code hasn't changed too much. I just did another experiment. Normally we boot via eth4 (which then becomes part of the bond with eth5 at init time). If I boot via eth6 instead, it appears as though the problem doesn't show up. Well, if you're still inclined to investigate, you may want to inspect the ARP probes generated by bonding in the bad situation. I don't really have any evidence to back it up, but one guess is that the IP detection stuff in the ARP monitor is getting messed up. I'd check to see if the ARP probes have the correct source IP address (which, in the 2.6.10 era bonding, is determined only once by inspection of outbound ARP traffic, and never updated). If you're not using active-backup mode (you didn't say, and I can't tell from your log excerpt), then the ARP monitor may not work at all (since it will send ARP probes with an IP source of all zeros). If bad ARP probe source addresses are your problem, then that is fixed in a later version of bonding, although the changes would require some rework to backport to 2.6.10 (if they can be backported). -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - 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: [Bonding-devel] quick help with bonding?
On Thu, Mar 29, 2007 at 05:42:54PM -0600, Chris Friesen wrote: Jay Vosburgh wrote: 2.6.10 is pretty old, and there have been a number of fixes to the bonding ARP monitor since then, so it may be that it is simply misbehaving (presuming that you're running the 2.6.10 bonding driver). Are you in a position to test against a more recent kernel (and/or bonding driver)? Does the miimon misbehave in a similar fashion? Testing a more recent kernel is problematic. A new bonding driver could be possible, assuming the code hasn't changed too much. If you are looking for a decent source for patches you could consider downloading the latest source-rpm from RHEL4/CentOS4. The bonding driver in those releases have been updated to much later code and I can tell you from personal experience they work pretty well. You may need to do some backporting to get the latest arp-monitoring features, but let me know if you need a hand with that, I might have some laying around. ;) I just did another experiment. Normally we boot via eth4 (which then becomes part of the bond with eth5 at init time). If I boot via eth6 instead, it appears as though the problem doesn't show up. Does eth6 use the same hardware/driver as eth4/5? (Sorry if I missed that in the thread, but didn't see if you indicated that it did.) - 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: [PATCH 2.6.21-rc5] bnx2: fix buffer overrun in bnx2_nvram_write
On Thu, 2007-03-29 at 22:47 +, Cureington, Tony wrote:
A buffer overrun issue exists in the bnx2_nvram_write function.
Tony, thanks for the patch. The alignment logic is indeed still broken
despite trying to fix it before. I think the following patch is better
in fixing the alignment logic. I agree with you about moving the code
to erase the page, and that part of your patch is preserved.
[BNX2]: Fix nvram write logic.
The nvram dword alignment logic was broken when writing less than 4
bytes on a non-aligned offset. It was missing logic to round the
length to 4 bytes.
The page erase code is also moved so that it is only called when
using non-buffered flash for better code clarity.
Update version to 1.5.7.
Based on initial patch from Tony Cureington [EMAIL PROTECTED].
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index d43fe28..0b7aded 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -54,8 +54,8 @@
#define DRV_MODULE_NAMEbnx2
#define PFX DRV_MODULE_NAME:
-#define DRV_MODULE_VERSION 1.5.6
-#define DRV_MODULE_RELDATE March 28, 2007
+#define DRV_MODULE_VERSION 1.5.7
+#define DRV_MODULE_RELDATE March 29, 2007
#define RUN_AT(x) (jiffies + (x))
@@ -3099,20 +3099,18 @@ bnx2_nvram_write(struct bnx2 *bp, u32 offset, u8
*data_buf,
if ((align_start = (offset32 3))) {
offset32 = ~3;
- len32 += (4 - align_start);
+ len32 += align_start;
+ if (len32 4)
+ len32 = 4;
if ((rc = bnx2_nvram_read(bp, offset32, start, 4)))
return rc;
}
if (len32 3) {
- if ((len32 4) || !align_start) {
- align_end = 4 - (len32 3);
- len32 += align_end;
- if ((rc = bnx2_nvram_read(bp, offset32 + len32 - 4,
- end, 4))) {
- return rc;
- }
- }
+ align_end = 4 - (len32 3);
+ len32 += align_end;
+ if ((rc = bnx2_nvram_read(bp, offset32 + len32 - 4, end, 4)))
+ return rc;
}
if (align_start || align_end) {
@@ -3187,17 +3185,17 @@ bnx2_nvram_write(struct bnx2 *bp, u32 offset, u8
*data_buf,
if ((rc = bnx2_enable_nvram_write(bp)) != 0)
goto nvram_write_end;
- /* Erase the page */
- if ((rc = bnx2_nvram_erase_page(bp, page_start)) != 0)
- goto nvram_write_end;
-
- /* Re-enable the write again for the actual write */
- bnx2_enable_nvram_write(bp);
-
/* Loop to write back the buffer data from page_start to
* data_start */
i = 0;
if (bp-flash_info-buffered == 0) {
+ /* Erase the page */
+ if ((rc = bnx2_nvram_erase_page(bp, page_start)) != 0)
+ goto nvram_write_end;
+
+ /* Re-enable the write again for the actual write */
+ bnx2_enable_nvram_write(bp);
+
for (addr = page_start; addr data_start;
addr += 4, i += 4) {
-
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
list of 100,000 chiropractors in the USA
Just completed - 100,000 American Chiropractor's Offices FIELDS: Office Name, Full Address, Phone, Fax, Email and Website Special Promotional Price: $199 (valid until March 30)--LAST CHANCE! contact [EMAIL PROTECTED] or call (206) 600-5313 for more info. For exclusion from future emails please send an email with exclude in the subject - 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: [PATCH] NET: Add TCP connection abort IOCTL
David Miller wrote: From: Predrag Hodoba [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 16:56:22 +0200 Need for such an API is to a degree indicated in the Carrier Grade Linux requirements by The Linux Foundation (former OSDL). Something being in the CGL specification is to me exactly a great reason NOT to add it. That specification is so full of garbage it's unbelievable. Thanks, you've given me one more reason not to even remotely consider adding this feature. Agreed, CGL is a vendor driven group that has always wanted to replicate proprietary misfeatures onto Linux. There is a real requirement to provide high availability but there should be no requirement to implement the solution in the same crap way as legacy Unix. - 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: [Bonding-devel] quick help with bonding?
Andy Gospodarek wrote: If you are looking for a decent source for patches you could consider downloading the latest source-rpm from RHEL4/CentOS4. The bonding driver in those releases have been updated to much later code and I can tell you from personal experience they work pretty well. You may need to do some backporting to get the latest arp-monitoring features, but let me know if you need a hand with that, I might have some laying around. ;) I'm just about to load a kernel with a backport of bonding from 2.6.14. I'll try it out and if it doesn't help I'll try the RHEL4 one. Does eth6 use the same hardware/driver as eth4/5? (Sorry if I missed that in the thread, but didn't see if you indicated that it did.) No, eth6 is an AMD-8111. Chris - 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: [Bonding-devel] quick help with bonding?
Chris Friesen wrote: Andy Gospodarek wrote: If you are looking for a decent source for patches you could consider downloading the latest source-rpm from RHEL4/CentOS4. The bonding driver in those releases have been updated to much later code and I can tell you from personal experience they work pretty well. I'm just about to load a kernel with a backport of bonding from 2.6.14. I'll try it out and if it doesn't help I'll try the RHEL4 one. No joy on the 2.6.14 backport, so I guess I'll try the RHEL4 route. Chris - 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: net nasties in davem's tree
From: Andrew Morton [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 18:37:30 -0700 drivers/net/3c523.c: In function 'elmc_send_packet': drivers/net/3c523.c:1148: warning: passing argument 2 of 'skb_copy_from_linear_data' discards qualifiers from pointer target type drivers/net/ni52.c: In function 'ni52_send_packet': drivers/net/ni52.c:1185: warning: passing argument 2 of 'skb_copy_from_linear_data' discards qualifiers from pointer target type We should probably mark the to argument to skb_copy_from_linear_data() as const, I'll take care of that. Thanks for the report. - 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: net nasties in davem's tree
From: David Miller [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 19:03:17 -0700 (PDT) From: Andrew Morton [EMAIL PROTECTED] Date: Thu, 29 Mar 2007 18:37:30 -0700 drivers/net/3c523.c: In function 'elmc_send_packet': drivers/net/3c523.c:1148: warning: passing argument 2 of 'skb_copy_from_linear_data' discards qualifiers from pointer target type drivers/net/ni52.c: In function 'ni52_send_packet': drivers/net/ni52.c:1185: warning: passing argument 2 of 'skb_copy_from_linear_data' discards qualifiers from pointer target type We should probably mark the to argument to skb_copy_from_linear_data() as const, I'll take care of that. Thanks for the report. My bad, what's going on in the first case is the driver has volatile disease. I'll add back the (char *) cast that was in the original memcpy(). - 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: [Bonding-devel] quick help with bonding?
On Thu, Mar 29, 2007 at 07:26:07PM -0600, Chris Friesen wrote: Chris Friesen wrote: Andy Gospodarek wrote: If you are looking for a decent source for patches you could consider downloading the latest source-rpm from RHEL4/CentOS4. The bonding driver in those releases have been updated to much later code and I can tell you from personal experience they work pretty well. I'm just about to load a kernel with a backport of bonding from 2.6.14. I'll try it out and if it doesn't help I'll try the RHEL4 one. No joy on the 2.6.14 backport, so I guess I'll try the RHEL4 route. Ah, ok. I'm not too sure how different the 2.6.9 and 2.6.10 bonding code was, so it might take a little tweaking but I'm guessing there won't be significant differences. - 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: [Bonding-devel] quick help with bonding?
Chris Friesen wrote: No joy on the 2.6.14 backport, so I guess I'll try the RHEL4 route. Bonding driver from 2.6.9-42.0.8.EL doesn't help at all, at least with the module parms I was using before. Switching to miimon doesn't help either. Chris - 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: [2.6 patch] the scheduled eepro100 removal
Roberto Nibali wrote: Sounds sane to me. My overall opinion on eepro100 removal is that we're not there yet. Rare problem cases remain where e100 fails but eepro100 works, and it's older drivers so its low priority for everybody. Needs to happen, though... It seems that several Tyan Opteron base system that were using IPMI add on card. the IPMI card share intel 100Mhz nic onboard. you need to use eepro100 instead of e100 otherwise the e100 will shutdown OOB (out of Band) connection for IPMI when shut down the OS. I find it hard to believe that something as common as IPMI in conjunction with the IPMI technology wasn't tested in Intel's lab. From my experience with Intel Server boards, onboard IPMI (all offered versions) and e100/e1000 NICs, I've never ever experienced any problems operating the BMC over the NIC. Also, I don't quite understand you point about the IPMI card sharing the 100Mbit/s NIC onboard? What exactly is shared? It's a legit problem, but only with this *one* system. - 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: [PATCH] net: tun/tap: fixed hw address handling
Brian Braunstein wrote:
From: Brian Braunstein [EMAIL PROTECTED]
Fixed tun/tap driver's handling of hw addresses.
Okay, the attached patch applies. Can someone comment on whether
it makes sense? (pasted inline for comments)
From: Brian Braunstein [EMAIL PROTECTED]
Fixed tun/tap driver's handling of hw addresses. The hw address is stored in
both the net_device.dev_addr and tun.dev_addr fields. These fields were not
kept synchronized, and in fact weren't even initialized to the same value.
Now during both init and when performing SIOCSIFHWADDR on the tun device
these values are both updated. However, if SIOCSIFHWADDR is performed on the
net device directly (for instance, setting the hw address using ifconfig),
the tun device does not get updated. Perhaps the tun.dev_addr field should
be removed completely at some point, as it is redundant and
net_device.dev_addr can be used anywhere it is used.
Signed-off-by: Brian Braunstein [EMAIL PROTECTED]
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -196,7 +196,10 @@ static void tun_net_init(struct net_devi
dev-set_multicast_list = tun_net_mclist;
ether_setup(dev);
- random_ether_addr(dev-dev_addr);
+
+ /* random address already created for us by tun_set_iff, use it
*/
+ memcpy(dev-dev_addr, tun-dev_addr, min(sizeof(tun-dev_addr),
sizeof(dev-dev_addr)) );
+
dev-tx_queue_len = TUN_READQ_SIZE; /* We prefer our own queue
length */
break;
}
@@ -636,6 +639,7 @@ static int tun_chr_ioctl(struct inode *i
return 0;
case SIOCGIFHWADDR:
+ /* Note: the actual net device's address may be different */
memcpy(ifr.ifr_hwaddr.sa_data, tun-dev_addr,
min(sizeof ifr.ifr_hwaddr.sa_data, sizeof
tun-dev_addr));
if (copy_to_user( argp, ifr, sizeof ifr))
@@ -643,16 +647,22 @@ static int tun_chr_ioctl(struct inode *i
return 0;
case SIOCSIFHWADDR:
- /** Set the character device's hardware address. This is used
when
-* filtering packets being sent from the network device to the
character
-* device. */
- memcpy(tun-dev_addr, ifr.ifr_hwaddr.sa_data,
- min(sizeof ifr.ifr_hwaddr.sa_data, sizeof
tun-dev_addr));
- DBG(KERN_DEBUG %s: set hardware address: %x:%x:%x:%x:%x:%x\n,
- tun-dev-name,
- tun-dev_addr[0], tun-dev_addr[1],
tun-dev_addr[2],
- tun-dev_addr[3], tun-dev_addr[4],
tun-dev_addr[5]);
- return 0;
+ /* try to set the actual net device's hw address */
+ int ret = dev_set_mac_address(tun-dev, ifr.ifr_hwaddr);
+
+ if (ret == 0) {
+ /** Set the character device's hardware address. This
is used when
+* filtering packets being sent from the network device
to the character
+* device. */
+ memcpy(tun-dev_addr, ifr.ifr_hwaddr.sa_data,
+ min(sizeof ifr.ifr_hwaddr.sa_data,
sizeof tun-dev_addr));
+ DBG(KERN_DEBUG %s: set hardware address:
%x:%x:%x:%x:%x:%x\n,
+ tun-dev-name,
+ tun-dev_addr[0], tun-dev_addr[1],
tun-dev_addr[2],
+ tun-dev_addr[3], tun-dev_addr[4],
tun-dev_addr[5]);
+ }
+
+ return ret;
case SIOCADDMULTI:
/** Add the specified group to the character device's multicast
filter
From: Brian Braunstein [EMAIL PROTECTED]
Fixed tun/tap driver's handling of hw addresses. The hw address is stored in
both the net_device.dev_addr and tun.dev_addr fields. These fields were not
kept synchronized, and in fact weren't even initialized to the same value.
Now during both init and when performing SIOCSIFHWADDR on the tun device
these values are both updated. However, if SIOCSIFHWADDR is performed on the
net device directly (for instance, setting the hw address using ifconfig),
the tun device does not get updated. Perhaps the tun.dev_addr field should
be removed completely at some point, as it is redundant and
net_device.dev_addr can be used anywhere it is used.
Signed-off-by: Brian Braunstein [EMAIL PROTECTED]
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -196,7 +196,10 @@ static void tun_net_init(struct net_devi
dev-set_multicast_list = tun_net_mclist;
ether_setup(dev);
- random_ether_addr(dev-dev_addr);
+
+ /* random address already created for us by tun_set_iff, use it
*/
+ memcpy(dev-dev_addr, tun-dev_addr, min(sizeof(tun-dev_addr),
sizeof(dev-dev_addr)) );
+
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/atl1/atl1_main.c | 10 ++
drivers/net/netxen/netxen_nic_init.c |3 ++-
drivers/net/sis190.c |1 +
3 files changed, 13 insertions(+), 1 deletions(-)
Chris Snook (1):
atl1: save mac address on remove
Francois Romieu (1):
sis190: new PHY support
Linsys Contractor Adhiraj Joshi (1):
NetXen: Fix hardware access for ppc architecture.
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index dee3638..8606eac 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2320,6 +2320,16 @@ static void __devexit atl1_remove(struct pci_dev *pdev)
return;
adapter = netdev_priv(netdev);
+
+ /* Some atl1 boards lack persistent storage for their MAC, and get it
+* from the BIOS during POST. If we've been messing with the MAC
+* address, we need to save the permanent one.
+*/
+ if (memcmp(adapter-hw.mac_addr, adapter-hw.perm_mac_addr, ETH_ALEN)) {
+ memcpy(adapter-hw.mac_addr, adapter-hw.perm_mac_addr,
ETH_ALEN);
+ atl1_set_mac_addr(adapter-hw);
+ }
+
iowrite16(0, adapter-hw.hw_addr + REG_GPHY_ENABLE);
unregister_netdev(netdev);
pci_iounmap(pdev, adapter-hw.hw_addr);
diff --git a/drivers/net/netxen/netxen_nic_init.c
b/drivers/net/netxen/netxen_nic_init.c
index 229aa1c..eff965d 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -438,6 +438,7 @@ do_rom_fast_read_words(struct netxen_adapter *adapter, int
addr,
for (addridx = addr; addridx (addr + size); addridx += 4) {
ret = do_rom_fast_read(adapter, addridx, (int *)bytes);
+ *(int *)bytes = cpu_to_le32(*(int *)bytes);
if (ret != 0)
break;
bytes += 4;
@@ -497,7 +498,7 @@ static inline int do_rom_fast_write_words(struct
netxen_adapter *adapter,
int timeout = 0;
int data;
- data = *(u32*)bytes;
+ data = le32_to_cpu((*(u32*)bytes));
ret = do_rom_fast_write(adapter, addridx, data);
if (ret 0)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index b08508b..34463ce 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -324,6 +324,7 @@ static struct mii_chip_info {
u32 feature;
} mii_chip_table[] = {
{ Broadcom PHY BCM5461, { 0x0020, 0x60c0 }, LAN, F_PHY_BCM5461 },
+ { Broadcom PHY AC131, { 0x0143, 0xbc70 }, LAN, 0 },
{ Agere PHY ET1101B,{ 0x0282, 0xf010 }, LAN, 0 },
{ Marvell PHY 88E, { 0x0141, 0x0cc0 }, LAN, F_PHY_88E },
{ Realtek PHY RTL8201, { 0x, 0x8200 }, LAN, 0 },
-
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: IP1000A: About IC Plus IP1000A Linux driver current status
Francois Romieu [EMAIL PROTECTED] : [...] BUG: spinlock already unlocked on CPU#0, swapper/0 Almost perfect... --- 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: [BUG] ethX misnumbered and one missing in mii-tool
added netdev. On 3/29/07, Andrei Popa [EMAIL PROTECTED] wrote: In a dual core 2 server with an intel motherboard and 5 network cards(two onboard) and 1 pci express card with two slots and one pci-x pci64 card the kernel sees all of them in dmesg but in mii-tool are misnumbered and one card is missing. (please CC as I am not subscribed to lkml) please don't use mii-tool, ethtool is a much better option and actually works with gigabit cards. from dmesg: Intel(R) PRO/1000 Network Driver - version 7.0.33-k2-NAPI Copyright (c) 1999-2005 Intel Corporation. ACPI: PCI Interrupt :03:00.0[A] - GSI 16 (level, low) - IRQ 16 PCI: Setting latency timer of device :03:00.0 to 64 e1000: :03:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4) 00:15:17:21:0c:08 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth0... ACPI: PCI Interrupt :03:00.1[B] - GSI 17 (level, low) - IRQ 17 PCI: Setting latency timer of device :03:00.1 to 64 e1000: :03:00.1: e1000_probe: (PCI Express:2.5Gb/s:Width x4) 00:15:17:21:0c:09 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth0... ACPI: PCI Interrupt :05:00.0[A] - GSI 18 (level, low) - IRQ 18 PCI: Setting latency timer of device :05:00.0 to 64 e1000: :05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4) 00:15:17:17:b7:68 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth0... GSI 20 sharing vector 0xC9 and IRQ 20 ACPI: PCI Interrupt :05:00.1[B] - GSI 19 (level, low) - IRQ 20 PCI: Setting latency timer of device :05:00.1 to 64 e1000: :05:00.1: e1000_probe: (PCI Express:2.5Gb/s:Width x4) 00:15:17:17:b7:69 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth0... GSI 21 sharing vector 0xD1 and IRQ 21 ACPI: PCI Interrupt :06:02.0[A] - GSI 27 (level, low) - IRQ 21 e1000: :06:02.0: e1000_probe: (PCI-X:100MHz:64-bit) 00:0e:0c:ba:a8:50 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth0... um, I'm a little confused why every interface was named eth0 when it tried to come up. you didn't mention what kernel you're using. you can enable MSI and not share interrupts on this platform, it will at least help your PCIe adapters. zeus ~ # mii-tool eth2: no link eth5: negotiated 100baseTx-FD, link ok eth6: no link eth7: no link zeus ~ # it sees only 4 cards that are misnumbered and one is missing. what does 'ip link' or 'ifconfig -a' show? Jesse - 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: [RFC] rfkill - Add support for input key to control wireless radio
Input: polled device skeleton
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile|1
drivers/input/misc/input-polldev.c | 149 +
include/linux/input-polldev.h | 46 +++
4 files changed, 207 insertions(+)
Index: linux/drivers/input/misc/Kconfig
===
--- linux.orig/drivers/input/misc/Kconfig
+++ linux/drivers/input/misc/Kconfig
@@ -81,6 +81,17 @@ config INPUT_UINPUT
To compile this driver as a module, choose M here: the
module will be called uinput.
+config INPUT_POLLDEV
+ tristate Polled input device skeleton
+ help
+ Say Y here if you are using a driver for an input
+ device that periodically polls hardware state. This
+ option is only useful for out-of-tree drivers since
+ in-tree drivers select it automatically.
+
+ To compile this driver as a module, choose M here: the
+ module will be called input-polldev.
+
config HP_SDC_RTC
tristate HP SDC Real Time Clock
depends on GSC || HP300
Index: linux/drivers/input/misc/Makefile
===
--- linux.orig/drivers/input/misc/Makefile
+++ linux/drivers/input/misc/Makefile
@@ -4,6 +4,7 @@
# Each configuration option enables a list of files.
+obj-$(CONFIG_INPUT_POLLDEV)+= input-polldev.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
Index: linux/drivers/input/misc/input-polldev.c
===
--- /dev/null
+++ linux/drivers/input/misc/input-polldev.c
@@ -0,0 +1,149 @@
+/*
+ * Generic implementation of a polled input device
+
+ * Copyright (c) 2007 Dmitry Torokhov
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/jiffies.h
+#include linux/input-polldev.h
+
+static DEFINE_MUTEX(polldev_mutex);
+static int polldev_users;
+static struct workqueue_struct *polldev_wq;
+
+static void input_polled_device_work(struct work_struct *work)
+{
+ struct input_polled_dev *dev =
+ container_of(work, struct input_polled_dev, work.work);
+
+ dev-poll(dev);
+ queue_delayed_work(polldev_wq, dev-work,
+ msecs_to_jiffies(dev-poll_interval));
+}
+
+static int input_open_polled_device(struct input_dev *input)
+{
+ struct input_polled_dev *dev = input-private;
+ int retval;
+
+ retval = mutex_lock_interruptible(polldev_mutex);
+ if (retval)
+ return retval;
+
+ if (!polldev_users++) {
+ polldev_wq = create_singlethread_workqueue(ipolldevd);
+ if (!polldev_wq) {
+ printk(KERN_ERR input-polldev: failed to create
+ ipolldevd workqueue\n);
+ goto out;
+ }
+ }
+
+ if (dev-flush)
+ dev-flush(dev);
+ queue_delayed_work(polldev_wq, dev-work,
+ msecs_to_jiffies(dev-poll_interval));
+
+ out:
+ mutex_unlock(polldev_mutex);
+ return retval;
+}
+
+static void input_close_polled_device(struct input_dev *input)
+{
+ struct input_polled_dev *dev = input-private;
+
+ cancel_rearming_delayed_workqueue(polldev_wq, dev-work);
+
+ mutex_lock(polldev_mutex);
+ if (!--polldev_users)
+ destroy_workqueue(polldev_wq);
+ mutex_unlock(polldev_mutex);
+}
+
+/**
+ * input_allocate_polled_device - allocated memory polled device
+ *
+ * The function allocates memory for a polled device and also
+ * for an input device associated with this polled device.
+ */
+struct input_polled_dev *input_allocate_polled_device(void)
+{
+ struct input_polled_dev *dev;
+
+ dev = kzalloc(sizeof(struct input_polled_dev), GFP_KERNEL);
+ if (!dev)
+ return NULL;
+
+ dev-input = input_allocate_device();
+ if (!dev-input) {
+ kfree(dev);
+ return NULL;
+ }
+
+ return dev;
+}
+EXPORT_SYMBOL(input_allocate_polled_device);
+
+/**
+ * input_free_polled_device - free memory allocated for polled device
+ * @dev: device to free
+ *
+ * The function frees memory allocated for pollign device and drops
+ * reference to the associated input device (if present).
+ */
+void input_free_polled_device(struct input_polled_dev *dev)
+{
+ if (dev) {
+ input_free_device(dev-input);
+ kfree(dev);
+ }
+}
+EXPORT_SYMBOL(input_free_polled_device);
+
+/**
+ * input_register_polled_device - register polled device
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wednesday 31 January 2007 06:20, Ivo van Doorn wrote: Hope you will be resubmitting this. And here is the new version, I didn't make the name const as requested that field is being passed to the class_device_create method which requires a char* argument. But I have made the flag field. And now this time the patch actually includes the changes I promised in last mail. (mutex, workqueue api, etc) Hi Ivo, I am very sorry for taking so much time to respond but finally I went through the patch and I still have the same objection as before - it mixes two logically (and often physically) separated objects into a single entity. I think that RF switch and button should be separate entities, created and destroyed independently of each other. This way everything handled uniformly by the kernel. I attempted to rework the rfkill core supprt and simplify it and came up with the patch below. Network card drivers that are able to control state of their RF transmitters allocate and register rfkill structures. Every rfkill structure belongs to one of RF classes (WLAN, Bluetooth or IRDA) and exports its name, type, state and user_claim through sysfs. There is also an input handler that catces KEY_WLAN and KEY_BLUETOOTH events passing through input system and toggles state of all RF switches of appropriate type registered with rfkill system (unless a switch was claimed by userspace in which case it is left alone). I think this provides basic functionality that most of the users need and any advanced control will have to be done from userspace. In a followup patch there is a skeleton code for creating polled input devices. For cards that have button physically connected their drivers will have to register a separate input device and let either input handler or userspace application take care of switching RF state appropriately. My only concern is where rfkill code should live. Since it is no longer dependent on input core (embedded systems might disable rfkill-input and use bare rfkill and control state from userspace) it does not need to live in drivers/input. Please let me know what you think. -- Dmitry From: Ivo van Doorn [EMAIL PROTECTED] Input: rfkill - Add support for input key to control wireless radio Signed-off-by Ivo van Doorn [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] --- drivers/input/misc/Kconfig| 26 ++ drivers/input/misc/Makefile |2 drivers/input/misc/rfkill-input.c | 169 drivers/input/misc/rfkill.c | 400 ++ include/linux/rfkill.h| 85 5 files changed, 682 insertions(+) Index: work/drivers/input/misc/Kconfig === --- work.orig/drivers/input/misc/Kconfig +++ work/drivers/input/misc/Kconfig @@ -98,4 +98,30 @@ config HP_SDC_RTC Say Y here if you want to support the built-in real time clock of the HP SDC controller. +config RFKILL + tristate RF switch support + help + Say Y here if you want to have control over RF switches + found on many WiFi, Bluetooth and IRDA cards. + + To compile this driver as a module, choose M here: the + module will be called rfkill. + +if RFKILL + +config RFKILL_INPUT + tristate Input layer to RF switch bridge + depends on INPUT + help + Say Y here if you want kernel automatically toggle state + of RF switches on and off when user presses appropriate + button an a key on the keyboard. Without this module + you need a some kind of userspace application to control + state of the switches. + + To compile this driver as a module, choose M here: the + module will be called rfkill-input. + +endif + endif Index: work/drivers/input/misc/Makefile === --- work.orig/drivers/input/misc/Makefile +++ work/drivers/input/misc/Makefile @@ -13,3 +13,5 @@ obj-$(CONFIG_INPUT_WISTRON_BTNS) += wist obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o +obj-$(CONFIG_RFKILL) += rfkill.o +obj-$(CONFIG_RFKILL_INPUT) += rfkill-input.o Index: work/drivers/input/misc/rfkill.c === --- /dev/null +++ work/drivers/input/misc/rfkill.c @@ -0,0 +1,400 @@ +/* + * Copyright (C) 2006 Ivo van Doorn + * Copyright (C) 2007 Dmitry Torokhov + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY;
tcp crash in net-2.6 tree
Full -mm lineup. The x86_64 box was acting as a distcc server at the time.
Nothing hit the logs, I'm afraid. But almost all the info is in
http://userweb.kernel.org/~akpm/s5000494.jpg
pokes around in gdb a bit
It died in tcp_update_scoreboard_fack() here:
if ((!IsFack(tp) || !tcp_skb_timedout(sk, skb))
after(TCP_SKB_CB(skb)-seq, tp-high_seq)) {
/* RFC: should we have find_below? */
skb = tcp_write_queue_find(sk, tp-high_seq);
not_marked_skb = skb;
skb = tcp_write_queue_prev(sk, skb);
/* Timedout top is again uncertain? */
if (tcp_skb_timedout(sk, skb))
timedout_continue = 1;
}
(gdb) l *0x8048ded8
0x8048ded8 is in tcp_update_scoreboard_fack (include/net/tcp.h:1197).
1192return skb-next;
1193}
1194
1195static inline struct sk_buff *tcp_write_queue_prev(struct sock *sk,
struct sk_buff *skb)
1196{
1197return skb-prev;
1198}
1199
1200#define tcp_for_write_queue(skb, sk) \
(gdb) x/10i 0x8048ded8
0x8048ded8 tcp_update_scoreboard_fack+528:mov0x8(%rdx),%r12
So if that CR2: 0008 is the access address then it appears that
`skb' is NULL. tcp_write_queue_find() didn't find nuthin.
-
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
