Re: [PATCH 1/1] LSM-IPsec SELinux Authorize (with minor fix)
From: David Miller <[EMAIL PROTECTED]> Date: Thu, 08 Jun 2006 23:40:03 -0700 (PDT) > From: Xiaolan Zhang <[EMAIL PROTECTED]> > Date: Tue, 6 Jun 2006 10:55:58 -0400 > > > Singned-off-by: Catherine Zhang <[EMAIL PROTECTED]> > > > > James, is this enough or do I need to modify the original patch to add the > > above line? The code was taken from various pieces of patches originally > > from Trent and merged/modified by me. Let me know what else I need to do. > > That's good enough for me, patch applied, thanks a lot. BTW, can I ask you SELINUX folks to at least attempt to do a build with SELINUX disabled when you submit networking changes to me? It would save me a lot of time, this one failed with: net/xfrm/xfrm_user.c: In function $,1rx(Bxfrm_del_sa$,1ry(B: net/xfrm/xfrm_user.c:430: warning: passing argument 1 of $,1rx(Bsecurity_xfrm_state_delete$,1ry(B from incompatible pointer type net/xfrm/xfrm_user.c:430: warning: suggest parentheses around assignment used as truth value net/xfrm/xfrm_user.c: In function $,1rx(Bxfrm_get_policy$,1ry(B: net/xfrm/xfrm_user.c:1060: warning: suggest parentheses around assignment used as truth value because the nop implementation of security_xfrm_state_delete() was declared to take an xfrm_policy instead of an xfrm_state. I've fixed all of this up, but please test this stuff out next time around. Thanks a lot. - 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 1/1] LSM-IPsec SELinux Authorize (with minor fix)
From: Xiaolan Zhang <[EMAIL PROTECTED]> Date: Tue, 6 Jun 2006 10:55:58 -0400 > Singned-off-by: Catherine Zhang <[EMAIL PROTECTED]> > > James, is this enough or do I need to modify the original patch to add the > above line? The code was taken from various pieces of patches originally > from Trent and merged/modified by me. Let me know what else I need to do. That's good enough for me, patch applied, thanks a lot. - 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: Using netconsole for debugging suspend/resume
On Friday 09 June 2006 07:23, David Miller wrote: > From: Auke Kok <[EMAIL PROTECTED]> > Date: Thu, 08 Jun 2006 22:13:48 -0700 > > > netconsole should retry. There is no timeout programmed here since that > > might > > lose important information, and you rather want netconsole to survive an odd > > unplugged cable then to lose vital debugging information when the system is > > busy for instance. (losing link will cause the interface to be down and thus > > the queue to be stopped) > > I completely disagree that netpoll should loop when the ethernet > cable is plugged out. Currently it is a bit dumb and doesn't distingush the various cases well. I submitted a patch to loop to be a bit more clever at some point. It can be still found in the netdev archives. -Andi - 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]: Add netif_tx_lock
On Thu, Jun 01, 2006 at 09:15:03PM +1000, herbert wrote:
>
> OK, here is a patch which does this.
>
> [NET]: Add netif_tx_lock
Just noticed that I showed dyslexia in winbond.c :) Here is the corrected
version.
[NET]: Add netif_tx_lock
Various drivers use xmit_lock internally to synchronise with their
transmission routines. They do so without setting xmit_lock_owner.
This is fine as long as netpoll is not in use.
With netpoll it is possible for deadlocks to occur if xmit_lock_owner
isn't set. This is because if a printk occurs while xmit_lock is held
and xmit_lock_owner is not set can cause netpoll to attempt to take
xmit_lock recursively.
While it is possible to resolve this by getting netpoll to use trylock,
it is suboptimal because netpoll's sole objective is to maximise the
chance of getting the printk out on the wire. So delaying or dropping
the message is to be avoided as much as possible.
So the only alternative is to always set xmit_lock_owner. The following
patch does this by introducing the netif_tx_lock family of functions that
take care of setting/unsetting xmit_lock_owner.
I renamed xmit_lock to _xmit_lock to indicate that it should not be used
directly. I didn't provide irq versions of the netif_tx_lock functions
since xmit_lock is meant to be a BH-disabling lock.
This is pretty much a straight text substitution except for a small bug
fix in winbond. It currently uses netif_stop_queue/spin_unlock_wait to
stop transmission. This is unsafe as an IRQ can potentially wake up the
queue. So it is safer to use netif_tx_disable.
The hamradio bits used spin_lock_irq but it is unnecessary as xmit_lock
must never be taken in an IRQ handler.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/Documentation/networking/netdevices.txt
b/Documentation/networking/netdevices.txt
index 3c0a5ba..847cedb 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -42,9 +42,9 @@ dev->get_stats:
Context: nominally process, but don't sleep inside an rwlock
dev->hard_start_xmit:
- Synchronization: dev->xmit_lock spinlock.
+ Synchronization: netif_tx_lock spinlock.
When the driver sets NETIF_F_LLTX in dev->features this will be
- called without holding xmit_lock. In this case the driver
+ called without holding netif_tx_lock. In this case the driver
has to lock by itself when needed. It is recommended to use a try lock
for this and return -1 when the spin lock fails.
The locking there should also properly protect against
@@ -62,12 +62,12 @@ dev->hard_start_xmit:
Only valid when NETIF_F_LLTX is set.
dev->tx_timeout:
- Synchronization: dev->xmit_lock spinlock.
+ Synchronization: netif_tx_lock spinlock.
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed true
dev->set_multicast_list:
- Synchronization: dev->xmit_lock spinlock.
+ Synchronization: netif_tx_lock spinlock.
Context: BHs disabled
dev->poll:
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 1dae4b2..1d917ed 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -821,7 +821,8 @@ void ipoib_mcast_restart_task(void *dev_
ipoib_mcast_stop_thread(dev, 0);
- spin_lock_irqsave(&dev->xmit_lock, flags);
+ local_irq_save(flags);
+ netif_tx_lock(dev);
spin_lock(&priv->lock);
/*
@@ -896,7 +897,8 @@ void ipoib_mcast_restart_task(void *dev_
}
spin_unlock(&priv->lock);
- spin_unlock_irqrestore(&dev->xmit_lock, flags);
+ netif_tx_unlock(dev);
+ local_irq_restore(flags);
/* We have to cancel outside of the spinlock */
list_for_each_entry_safe(mcast, tmcast, &remove_list, list) {
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 2f0f358..9fd8752 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -1052,7 +1052,7 @@ static void wq_set_multicast_list (void
dvb_net_feed_stop(dev);
priv->rx_mode = RX_MODE_UNI;
- spin_lock_bh(&dev->xmit_lock);
+ netif_tx_lock_bh(dev);
if (dev->flags & IFF_PROMISC) {
dprintk("%s: promiscuous mode\n", dev->name);
@@ -1077,7 +1077,7 @@ static void wq_set_multicast_list (void
}
}
- spin_unlock_bh(&dev->xmit_lock);
+ netif_tx_unlock_bh(dev);
dvb_net_feed_start(dev);
}
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 54161ae..9c5a884 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -2009,7 +2009,7
Re: Using netconsole for debugging suspend/resume
Auke Kok wrote: netconsole should retry. There is no timeout programmed here since that might lose important information, and you rather want netconsole to survive an odd unplugged cable then to lose vital debugging information when the system is busy for instance. (losing link will cause the interface to be down and thus the queue to be stopped) Well, the trouble is that it ends up spinning forever in the suspend case. The driver's suspend routine has XOFFed the queue, and its never going to come back if netconsole clogs everything up over it. Perhaps the correct fix isn't at the netpoll level, but at the netconsole level, but the behaviour of "suspend ethernet, netconsole drops bits into the bucket until the ether comes back" seems to be the best we can hope for. The present behaviour is definitely bad, since it will prevent any system from suspending while using netconsole, so you'd need to make it modular and rmmod/modprobe it around the suspend event - definitely losing more information. Also it means that if you kick a cable, the machine will eventually lock up, which doesn't seem like the best behaviour... Even so, it will wait for 1 second per skb sent (2 x 50uS) to wait for the queue to be started, so it will be pretty slow, and will recover from little hiccups without losing much. polling is for receives. We're basically telling the stack not to poll our interface anymore. OK, I see. e1000_suspend saves the entire configuration of the device and puts it in Wake-on-Lan mode, allowing it to be waken up by your 'zap' in the proper way. Not sure that's terribly useful. It would be nice to be able to zap the ethernet to get a console dump from early stages, but talking to the device depends on all the intermediate PCI stuff being set up first, so netconsole could cause even more of a mess. Then the e1000 would resume normally, including restarting the xmit queue so that netconsole can start again immediately; any netconsole output before the e1000 resume would be lost, of course (I guess it could be buffered). That would suit me for now. after coming out of suspend, e1000_resume is called which basically reinitializes the entire device. In the entire sequence it is unlikely that you'll actually be able to maintain netconsole in the first boot stage - the network device will not be initialized by the kernel yet, and obviously will be useless until e1000_resume is called! Yes, but I think that's OK for what I'm looking at. The problems I'm seeing happen later, and as I said in the first mail, I'm willing to accept a bletcherous hack if necessary (though obviously something clean and mergable would be preferable). At the netpoll level, assuming that netpoll_send_skb doesn't busywait forever while the queue is XOFFed, it will toss things until the moment the ethernet device queue is up, and then it will resume as normal. I'm not sure that tweaking e1000 to survive longer is the answer here, and you might be better off trying to have netconsole graciously wait (msleep_interruptable instead of udelay?) Pretty sure netpoll can't sleep there... In any case, I see the biggest problem in the early boot stage when all nics are basically uninitialized until resume starts. You just can't assign it an IP address for instance that easy, and even resume causes the device to reset and thus link renegotiation, adding crucial seconds to the time that the link is down, in which time you're stacking up netconsole messages, or worse, fail to initialize netconsole netconsole has already been initialized. It doesn't need reinit on resume. I hope this helps - I can't help but thinking that netconsole definately wasn't designed with this in mind. Perhaps not, but it isn't far from being a useful tool in this case. Its much better than the alternative of having no information at all about the whole process. J - 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 4/8] e1000: prevent statistics from getting garbled during reset
From: Linas Vepstas <[EMAIL PROTECTED]>
If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
ethernet packet count statistics from the hardware will fail, returning
garbage data upstream. This patch skips statistics data collection if the
PCI device is not on the bus.
This patch presumes that an earlier patch,
[PATCH] PCI Error Recovery: e1000 network device driver
has already been applied.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: John Ronciak <[EMAIL PROTECTED]>
Cc: Jesse Brandeburg <[EMAIL PROTECTED]>
Cc: Jeff Kirsher <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |8 +++-
1 files changed, 7 insertions(+), 1 deletion(-)
diff -puN
drivers/net/e1000/e1000_main.c~e1000-prevent-statistics-from-getting-garbled-during-reset
drivers/net/e1000/e1000_main.c
---
devel/drivers/net/e1000/e1000_main.c~e1000-prevent-statistics-from-getting-garbled-during-reset
2006-04-14 23:41:34.0 -0700
+++ devel-akpm/drivers/net/e1000/e1000_main.c 2006-04-14 23:41:34.0
-0700
@@ -3082,14 +3082,20 @@ void
e1000_update_stats(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
+ struct pci_dev *pdev = adapter->pdev;
unsigned long flags;
uint16_t phy_tmp;
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
- /* Prevent stats update while adapter is being reset */
+ /*
+* Prevent stats update while adapter is being reset, or if the pci
+* connection is down.
+*/
if (adapter->link_speed == 0)
return;
+ if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
+ return;
spin_lock_irqsave(&adapter->stats_lock, flags);
_
-
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: Using netconsole for debugging suspend/resume
From: Auke Kok <[EMAIL PROTECTED]> Date: Thu, 08 Jun 2006 22:13:48 -0700 > netconsole should retry. There is no timeout programmed here since that might > lose important information, and you rather want netconsole to survive an odd > unplugged cable then to lose vital debugging information when the system is > busy for instance. (losing link will cause the interface to be down and thus > the queue to be stopped) I completely disagree that netpoll should loop when the ethernet cable is plugged out. This stops the entire system. What if this is one of my main web servers and I have other links on the machine for redundancy and load balancing? Just because some careless sysop knocks one of the cables out, my system just freezes up and stops? What if I'm on a remote serial console, how long should I scratch my head wondering why the whole machine is frozen up before I "figure out" that the ethernet cable being out has made my system unusable because netpoll is just looping on the thing forever? That's an extremely poor quality of implementation if you ask me. Netpoll is _BEST_ _EFFORT_, end of story. It by definition can only offer that level of service because it does locking in circumstances where such locking might be illegal or even impossible. So it has to try, but if it can't get the resources it needs, it must stop trying and abort the logging. - 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 6/8] drivers/char/hw_random.c: remove assert()'s
From: Adrian Bunk <[EMAIL PROTECTED]>
Remove the assert()'s from drivers/char/hw_random.c since you both needed
to enable a manual option in the driver source to make them effective and
they only covered some obviously impossible cases.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/char/hw_random.c | 21 -
1 files changed, 21 deletions(-)
diff -puN drivers/char/hw_random.c~drivers-char-hw_randomc-remove-asserts
drivers/char/hw_random.c
--- 25/drivers/char/hw_random.c~drivers-char-hw_randomc-remove-asserts Mon May
8 12:03:00 2006
+++ 25-akpm/drivers/char/hw_random.cMon May 8 12:03:00 2006
@@ -66,17 +66,6 @@
#define DPRINTK(fmt, args...) pr_debug(PFX "%s: " fmt, __FUNCTION__ , ## args)
-#undef RNG_NDEBUG/* define to enable lightweight runtime checks */
-#ifdef RNG_NDEBUG
-#define assert(expr) \
- if(!(expr)) { \
- printk(KERN_DEBUG PFX "Assertion failed! %s,%s,%s," \
- "line=%d\n", #expr, __FILE__, __FUNCTION__, __LINE__); \
- }
-#else
-#define assert(expr)
-#endif
-
#define RNG_MISCDEV_MINOR 183 /* official */
static int rng_dev_open (struct inode *inode, struct file *filp);
@@ -211,29 +200,23 @@ static void __iomem *rng_mem;
static inline u8 intel_hwstatus (void)
{
- assert (rng_mem != NULL);
return readb (rng_mem + INTEL_RNG_HW_STATUS);
}
static inline u8 intel_hwstatus_set (u8 hw_status)
{
- assert (rng_mem != NULL);
writeb (hw_status, rng_mem + INTEL_RNG_HW_STATUS);
return intel_hwstatus ();
}
static unsigned int intel_data_present(void)
{
- assert (rng_mem != NULL);
-
return (readb (rng_mem + INTEL_RNG_STATUS) & INTEL_RNG_DATA_PRESENT) ?
1 : 0;
}
static u32 intel_data_read(void)
{
- assert (rng_mem != NULL);
-
return readb (rng_mem + INTEL_RNG_DATA);
}
@@ -495,7 +478,6 @@ static u32 geode_data_read(void)
{
u32 val;
- assert(geode_rng_base != NULL);
val = readl(geode_rng_base + GEODE_RNG_DATA_REG);
return val;
}
@@ -504,7 +486,6 @@ static unsigned int geode_data_present(v
{
u32 val;
- assert(geode_rng_base != NULL);
val = readl(geode_rng_base + GEODE_RNG_STATUS_REG);
return val;
}
@@ -605,8 +586,6 @@ static int __init rng_init_one (struct p
DPRINTK ("ENTER\n");
- assert(rng_ops != NULL);
-
rc = rng_ops->init(dev);
if (rc)
goto err_out;
_
-
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 7/9] secmark: Add secmark support to conntrack
From: James Morris <[EMAIL PROTECTED]>
Add a secmark field to IP and NF conntracks, so that security markings on
packets can be copied to their associated connections, and also copied back to
packets as required. This is similar to the network mark field currently used
with conntrack, although it is intended for enforcement of security policy
rather than network policy.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/linux/netfilter_ipv4/ip_conntrack.h |4 ++
include/net/netfilter/nf_conntrack.h |4 ++
include/net/netfilter/nf_conntrack_compat.h | 26 +
net/ipv4/netfilter/Kconfig | 12 +++
net/ipv4/netfilter/ip_conntrack_core.c |3 +
net/ipv4/netfilter/ip_conntrack_standalone.c |5 +++
net/netfilter/Kconfig| 12 +++
net/netfilter/nf_conntrack_core.c|3 +
net/netfilter/nf_conntrack_standalone.c |5 +++
9 files changed, 74 insertions(+)
diff -puN
include/linux/netfilter_ipv4/ip_conntrack.h~secmark-add-secmark-support-to-conntrack
include/linux/netfilter_ipv4/ip_conntrack.h
---
devel/include/linux/netfilter_ipv4/ip_conntrack.h~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/include/linux/netfilter_ipv4/ip_conntrack.h 2006-06-01
20:31:50.0 -0700
@@ -120,6 +120,10 @@ struct ip_conntrack
u_int32_t mark;
#endif
+#ifdef CONFIG_IP_NF_CONNTRACK_SECMARK
+ u_int32_t secmark;
+#endif
+
/* Traversed often, so hopefully in different cacheline to top */
/* These are my tuples; original and reply */
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
diff -puN
include/net/netfilter/nf_conntrack_compat.h~secmark-add-secmark-support-to-conntrack
include/net/netfilter/nf_conntrack_compat.h
---
devel/include/net/netfilter/nf_conntrack_compat.h~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/include/net/netfilter/nf_conntrack_compat.h 2006-06-01
20:31:50.0 -0700
@@ -20,6 +20,19 @@ static inline u_int32_t *nf_ct_get_mark(
}
#endif /* CONFIG_IP_NF_CONNTRACK_MARK */
+#ifdef CONFIG_IP_NF_CONNTRACK_SECMARK
+static inline u_int32_t *nf_ct_get_secmark(const struct sk_buff *skb,
+ u_int32_t *ctinfo)
+{
+ struct ip_conntrack *ct = ip_conntrack_get(skb, ctinfo);
+
+ if (ct)
+ return &ct->secmark;
+ else
+ return NULL;
+}
+#endif /* CONFIG_IP_NF_CONNTRACK_SECMARK */
+
#ifdef CONFIG_IP_NF_CT_ACCT
static inline struct ip_conntrack_counter *
nf_ct_get_counters(const struct sk_buff *skb)
@@ -70,6 +83,19 @@ static inline u_int32_t *nf_ct_get_mark(
}
#endif /* CONFIG_NF_CONNTRACK_MARK */
+#ifdef CONFIG_NF_CONNTRACK_SECMARK
+static inline u_int32_t *nf_ct_get_secmark(const struct sk_buff *skb,
+ u_int32_t *ctinfo)
+{
+ struct nf_conn *ct = nf_ct_get(skb, ctinfo);
+
+ if (ct)
+ return &ct->secmark;
+ else
+ return NULL;
+}
+#endif /* CONFIG_NF_CONNTRACK_MARK */
+
#ifdef CONFIG_NF_CT_ACCT
static inline struct ip_conntrack_counter *
nf_ct_get_counters(const struct sk_buff *skb)
diff -puN
include/net/netfilter/nf_conntrack.h~secmark-add-secmark-support-to-conntrack
include/net/netfilter/nf_conntrack.h
---
devel/include/net/netfilter/nf_conntrack.h~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/include/net/netfilter/nf_conntrack.h 2006-06-01
20:31:50.0 -0700
@@ -113,6 +113,10 @@ struct nf_conn
u_int32_t mark;
#endif
+#ifdef CONFIG_NF_CONNTRACK_SECMARK
+ u_int32_t secmark;
+#endif
+
/* Storage reserved for other modules: */
union nf_conntrack_proto proto;
diff -puN
net/ipv4/netfilter/ip_conntrack_core.c~secmark-add-secmark-support-to-conntrack
net/ipv4/netfilter/ip_conntrack_core.c
---
devel/net/ipv4/netfilter/ip_conntrack_core.c~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/ipv4/netfilter/ip_conntrack_core.c 2006-06-01
20:31:50.0 -0700
@@ -724,6 +724,9 @@ init_conntrack(struct ip_conntrack_tuple
/* this is ugly, but there is no other place where to put it */
conntrack->nat.masq_index = exp->master->nat.masq_index;
#endif
+#ifdef CONFIG_IP_NF_CONNTRACK_SECMARK
+ conntrack->secmark = exp->master->secmark;
+#endif
nf_conntrack_get(&conntrack->master->ct_general);
CONNTRACK_STAT_INC(expect_new);
} else {
diff -puN
net/ipv4/netfilter/ip_conntrack_standalone.c~secmark-add-secmark-support-to-conntrack
net/ipv4/netfilter/ip_conntrack_standalone.c
---
devel/net/ipv4/netfilter/ip_conntrack_standalone.c~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:
[patch 2/9] selinux: add security class for appletalk sockets
From: Christopher J. PeBenito <[EMAIL PROTECTED]>
Add a security class for appletalk sockets so that they can be
distinguished in SELinux policy. Please apply.
Signed-off-by: Stephen Smalley <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
security/selinux/hooks.c |2 +
security/selinux/include/av_inherit.h |1
security/selinux/include/av_permissions.h | 23 +++
security/selinux/include/class_to_string.h |1
security/selinux/include/flask.h |1
5 files changed, 28 insertions(+)
diff -puN
security/selinux/hooks.c~selinux-add-security-class-for-appletalk-sockets
security/selinux/hooks.c
---
devel/security/selinux/hooks.c~selinux-add-security-class-for-appletalk-sockets
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/security/selinux/hooks.c 2006-06-01 20:31:49.0 -0700
@@ -696,6 +696,8 @@ static inline u16 socket_type_to_securit
return SECCLASS_PACKET_SOCKET;
case PF_KEY:
return SECCLASS_KEY_SOCKET;
+ case PF_APPLETALK:
+ return SECCLASS_APPLETALK_SOCKET;
}
return SECCLASS_SOCKET;
diff -puN
security/selinux/include/av_inherit.h~selinux-add-security-class-for-appletalk-sockets
security/selinux/include/av_inherit.h
---
devel/security/selinux/include/av_inherit.h~selinux-add-security-class-for-appletalk-sockets
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/security/selinux/include/av_inherit.h2006-06-01
20:31:49.0 -0700
@@ -29,3 +29,4 @@
S_(SECCLASS_NETLINK_IP6FW_SOCKET, socket, 0x0040UL)
S_(SECCLASS_NETLINK_DNRT_SOCKET, socket, 0x0040UL)
S_(SECCLASS_NETLINK_KOBJECT_UEVENT_SOCKET, socket, 0x0040UL)
+ S_(SECCLASS_APPLETALK_SOCKET, socket, 0x0040UL)
diff -puN
security/selinux/include/av_permissions.h~selinux-add-security-class-for-appletalk-sockets
security/selinux/include/av_permissions.h
---
devel/security/selinux/include/av_permissions.h~selinux-add-security-class-for-appletalk-sockets
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/security/selinux/include/av_permissions.h2006-06-01
20:31:49.0 -0700
@@ -933,3 +933,26 @@
#define NETLINK_KOBJECT_UEVENT_SOCKET__SEND_MSG 0x0010UL
#define NETLINK_KOBJECT_UEVENT_SOCKET__NAME_BIND 0x0020UL
+#define APPLETALK_SOCKET__IOCTL 0x0001UL
+#define APPLETALK_SOCKET__READ0x0002UL
+#define APPLETALK_SOCKET__WRITE 0x0004UL
+#define APPLETALK_SOCKET__CREATE 0x0008UL
+#define APPLETALK_SOCKET__GETATTR 0x0010UL
+#define APPLETALK_SOCKET__SETATTR 0x0020UL
+#define APPLETALK_SOCKET__LOCK0x0040UL
+#define APPLETALK_SOCKET__RELABELFROM 0x0080UL
+#define APPLETALK_SOCKET__RELABELTO 0x0100UL
+#define APPLETALK_SOCKET__APPEND 0x0200UL
+#define APPLETALK_SOCKET__BIND0x0400UL
+#define APPLETALK_SOCKET__CONNECT 0x0800UL
+#define APPLETALK_SOCKET__LISTEN 0x1000UL
+#define APPLETALK_SOCKET__ACCEPT 0x2000UL
+#define APPLETALK_SOCKET__GETOPT 0x4000UL
+#define APPLETALK_SOCKET__SETOPT 0x8000UL
+#define APPLETALK_SOCKET__SHUTDOWN0x0001UL
+#define APPLETALK_SOCKET__RECVFROM0x0002UL
+#define APPLETALK_SOCKET__SENDTO 0x0004UL
+#define APPLETALK_SOCKET__RECV_MSG0x0008UL
+#define APPLETALK_SOCKET__SEND_MSG0x0010UL
+#define APPLETALK_SOCKET__NAME_BIND 0x0020UL
+
diff -puN
security/selinux/include/class_to_string.h~selinux-add-security-class-for-appletalk-sockets
security/selinux/include/class_to_string.h
---
devel/security/selinux/include/class_to_string.h~selinux-add-security-class-for-appletalk-sockets
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/security/selinux/include/class_to_string.h 2006-06-01
20:31:49.0 -0700
@@ -58,3 +58,4 @@
S_("nscd")
S_("association")
S_("netlink_kobject_uevent_socket")
+S_("appletalk_socket")
diff -puN
security/selinux/include/flask.h~selinux-add-security-class-for-appletalk-sockets
security/selinux/include/flask.h
---
devel/security/selinux/include/flask.h~selinux-add-security-class-for-appletalk-sockets
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/security/selinux/include/flask.h 2006-06-01 20:31:49.0
-0700
@@ -60,6 +60,7 @@
#define SECCLASS_NSCD53
#define SECCLASS_ASSOCIATION 54
#define SECCLASS_NETLINK_KOBJECT_UEVENT_SOCKET 55
+#define SECCLASS_APPLETALK_SOCKET56
/*
* Secur
[patch 6/9] secmark: Add xtables SECMARK target
From: James Morris <[EMAIL PROTECTED]>
Add a SECMARK target to xtables, allowing the admin to apply security marks to
packets via both iptables and ip6tables.
The target currently handles SELinux security marking, but can be extended
for other purposes as needed.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/linux/netfilter/xt_SECMARK.h | 26
net/netfilter/Kconfig|9 +
net/netfilter/Makefile |1
net/netfilter/xt_SECMARK.c | 156 +
4 files changed, 192 insertions(+)
diff -puN /dev/null include/linux/netfilter/xt_SECMARK.h
--- /dev/null 2006-06-01 17:04:03.273681250 -0700
+++ devel-akpm/include/linux/netfilter/xt_SECMARK.h 2006-06-01
20:31:50.0 -0700
@@ -0,0 +1,26 @@
+#ifndef _XT_SECMARK_H_target
+#define _XT_SECMARK_H_target
+
+/*
+ * This is intended for use by various security subsystems (but not
+ * at the same time).
+ *
+ * 'mode' refers to the specific security subsystem which the
+ * packets are being marked for.
+ */
+#define SECMARK_MODE_SEL 0x01/* SELinux */
+#define SECMARK_SELCTX_MAX 256
+
+struct xt_secmark_target_selinux_info {
+ u_int32_t selsid;
+ char selctx[SECMARK_SELCTX_MAX];
+};
+
+struct xt_secmark_target_info {
+ u_int8_t mode;
+ union {
+ struct xt_secmark_target_selinux_info sel;
+ } u;
+};
+
+#endif /*_XT_SECMARK_H_target */
diff -puN net/netfilter/Kconfig~secmark-add-xtables-secmark-target
net/netfilter/Kconfig
--- devel/net/netfilter/Kconfig~secmark-add-xtables-secmark-target
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/netfilter/Kconfig2006-06-01 20:31:50.0 -0700
@@ -174,6 +174,15 @@ config NETFILTER_XT_TARGET_NOTRACK
If you want to compile it as a module, say M here and read
. If unsure, say `N'.
+config NETFILTER_XT_TARGET_SECMARK
+ tristate '"SECMARK" target support'
+ depends on NETFILTER_XTABLES && NETWORK_SECMARK
+ help
+ The SECMARK target allows security marking of network
+ packets, for use with security subsystems.
+
+ To compile it as a module, choose M here. If unsure, say N.
+
config NETFILTER_XT_MATCH_COMMENT
tristate '"comment" match support'
depends on NETFILTER_XTABLES
diff -puN net/netfilter/Makefile~secmark-add-xtables-secmark-target
net/netfilter/Makefile
--- devel/net/netfilter/Makefile~secmark-add-xtables-secmark-target
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/netfilter/Makefile 2006-06-01 20:31:50.0 -0700
@@ -28,6 +28,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_CONNMAR
obj-$(CONFIG_NETFILTER_XT_TARGET_MARK) += xt_MARK.o
obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
obj-$(CONFIG_NETFILTER_XT_TARGET_NOTRACK) += xt_NOTRACK.o
+obj-$(CONFIG_NETFILTER_XT_TARGET_SECMARK) += xt_SECMARK.o
# matches
obj-$(CONFIG_NETFILTER_XT_MATCH_COMMENT) += xt_comment.o
diff -puN /dev/null net/netfilter/xt_SECMARK.c
--- /dev/null 2006-06-01 17:04:03.273681250 -0700
+++ devel-akpm/net/netfilter/xt_SECMARK.c 2006-06-01 20:31:50.0
-0700
@@ -0,0 +1,156 @@
+/*
+ * Module for modifying the secmark field of the skb, for use by
+ * security subsystems.
+ *
+ * Based on the nfmark match by:
+ * (C) 1999-2001 Marc Boucher <[EMAIL PROTECTED]>
+ *
+ * (C) 2006 Red Hat, Inc., James Morris <[EMAIL PROTECTED]>
+ *
+ * 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
+#include
+#include
+#include
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("James Morris <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("ip[6]tables SECMARK modification module");
+MODULE_ALIAS("ipt_SECMARK");
+MODULE_ALIAS("ip6t_SECMARK");
+
+#define PFX "SECMARK: "
+
+static u8 mode;
+
+static unsigned int target(struct sk_buff **pskb, const struct net_device *in,
+ const struct net_device *out, unsigned int hooknum,
+ const struct xt_target *target,
+ const void *targinfo, void *userinfo)
+{
+ u32 secmark = 0;
+ const struct xt_secmark_target_info *info = targinfo;
+
+ BUG_ON(info->mode != mode);
+
+ switch (mode) {
+ case SECMARK_MODE_SEL:
+ secmark = info->u.sel.selsid;
+ break;
+
+ default:
+ BUG();
+ }
+
+ if ((*pskb)->secmark != secmark)
+ (*pskb)->secmark = secmark;
+
+ return XT_CONTINUE;
+}
+
+static int checkentry_selinux(struct xt_secmark_target_info *info)
+{
+ int err;
+ struct xt_secmark_target_selinux_info *sel = &info->u.sel;
+
+ err = selinux_string_to_sid(sel->selctx, &sel->selsid);
+ if (err) {
+ if (err == -EINVAL)
+
[patch 8/9] secmark: Add CONNSECMARK xtables target
From: James Morris <[EMAIL PROTECTED]>
Add a new xtables target, CONNSECMARK, which is used to specify rules for
copying security marks from packets to connections, and for copyying security
marks back from connections to packets. This is similar to the CONNMARK
target, but is more limited in scope in that it only allows copying of
security marks to and from packets, as this is all it needs to do.
A typical scenario would be to apply a security mark to a 'new' packet with
SECMARK, then copy that to its conntrack via CONNMARK, and then restore the
security mark from the connection to established and related packets on that
connection.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/linux/netfilter/xt_CONNSECMARK.h | 13 +
net/netfilter/Kconfig| 11 +
net/netfilter/Makefile |1
net/netfilter/xt_CONNSECMARK.c | 155 +
4 files changed, 180 insertions(+)
diff -puN /dev/null include/linux/netfilter/xt_CONNSECMARK.h
--- /dev/null 2006-06-01 17:04:03.273681250 -0700
+++ devel-akpm/include/linux/netfilter/xt_CONNSECMARK.h 2006-06-01
20:31:50.0 -0700
@@ -0,0 +1,13 @@
+#ifndef _XT_CONNSECMARK_H_target
+#define _XT_CONNSECMARK_H_target
+
+enum {
+ CONNSECMARK_SAVE = 1,
+ CONNSECMARK_RESTORE,
+};
+
+struct xt_connsecmark_target_info {
+ u_int8_t mode;
+};
+
+#endif /*_XT_CONNSECMARK_H_target */
diff -puN net/netfilter/Kconfig~secmark-add-connsecmark-xtables-target
net/netfilter/Kconfig
--- devel/net/netfilter/Kconfig~secmark-add-connsecmark-xtables-target
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/netfilter/Kconfig2006-06-01 20:31:50.0 -0700
@@ -195,6 +195,17 @@ config NETFILTER_XT_TARGET_SECMARK
To compile it as a module, choose M here. If unsure, say N.
+config NETFILTER_XT_TARGET_CONNSECMARK
+ tristate '"CONNSECMARK" target support'
+ depends on NETFILTER_XTABLES && (NF_CONNTRACK_SECMARK ||
IP_NF_CONNTRACK_SECMARK)
+ help
+ The CONNSECMARK target copies security markings from packets
+ to connections, and restores security markings from connections
+ to packets (if the packets are not already marked). This would
+ normally be used in conjunction with the SECMARK target.
+
+ To compile it as a module, choose M here. If unsure, say N.
+
config NETFILTER_XT_MATCH_COMMENT
tristate '"comment" match support'
depends on NETFILTER_XTABLES
diff -puN net/netfilter/Makefile~secmark-add-connsecmark-xtables-target
net/netfilter/Makefile
--- devel/net/netfilter/Makefile~secmark-add-connsecmark-xtables-target
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/netfilter/Makefile 2006-06-01 20:31:50.0 -0700
@@ -29,6 +29,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_MARK) +
obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
obj-$(CONFIG_NETFILTER_XT_TARGET_NOTRACK) += xt_NOTRACK.o
obj-$(CONFIG_NETFILTER_XT_TARGET_SECMARK) += xt_SECMARK.o
+obj-$(CONFIG_NETFILTER_XT_TARGET_CONNSECMARK) += xt_CONNSECMARK.o
# matches
obj-$(CONFIG_NETFILTER_XT_MATCH_COMMENT) += xt_comment.o
diff -puN /dev/null net/netfilter/xt_CONNSECMARK.c
--- /dev/null 2006-06-01 17:04:03.273681250 -0700
+++ devel-akpm/net/netfilter/xt_CONNSECMARK.c 2006-06-01 20:31:50.0
-0700
@@ -0,0 +1,155 @@
+/*
+ * This module is used to copy security markings from packets
+ * to connections, and restore security markings from connections
+ * back to packets. This would normally be performed in conjunction
+ * with the SECMARK target and state match.
+ *
+ * Based somewhat on CONNMARK:
+ * Copyright (C) 2002,2004 MARA Systems AB
+ *by Henrik Nordstrom <[EMAIL PROTECTED]>
+ *
+ * (C) 2006 Red Hat, Inc., James Morris <[EMAIL PROTECTED]>
+ *
+ * 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
+#include
+#include
+#include
+#include
+
+#define PFX "CONNSECMARK: "
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("James Morris <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("ip[6]tables CONNSECMARK module");
+MODULE_ALIAS("ipt_CONNSECMARK");
+MODULE_ALIAS("ip6t_CONNSECMARK");
+
+/*
+ * If the packet has a security mark and the connection does not, copy
+ * the security mark from the packet to the connection.
+ */
+static void secmark_save(struct sk_buff *skb)
+{
+ if (skb->secmark) {
+ u32 *connsecmark;
+ enum ip_conntrack_info ctinfo;
+
+ connsecmark = nf_ct_get_secmark(skb, &ctinfo);
+ if (connsecmark && !*connsecmark)
+ if (*connsecmark != skb->secmark)
+ *connsecmark = skb->secmark;
+ }
+}
+
+/*
+ * If packet has no security mark, and the connection does, rest
[patch 5/9] secmark: Add secmark support to core networking.
From: James Morris <[EMAIL PROTECTED]>
Add a secmark field to the skbuff structure, to allow security subsystems to
place security markings on network packets. This is similar to the nfmark
field, except is intended for implementing security policy, rather than than
networking policy.
This patch was already acked in principle by Dave Miller.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 22 ++
net/Kconfig |7 +++
net/core/skbuff.c |3 ++-
net/ipv4/ip_output.c|1 +
net/ipv4/netfilter/ipt_REJECT.c |1 +
net/ipv6/ip6_output.c |1 +
6 files changed, 34 insertions(+), 1 deletion(-)
diff -puN include/linux/skbuff.h~secmark-add-secmark-support-to-core-networking
include/linux/skbuff.h
--- devel/include/linux/skbuff.h~secmark-add-secmark-support-to-core-networking
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/include/linux/skbuff.h 2006-06-01 20:31:50.0 -0700
@@ -209,6 +209,7 @@ enum {
* @nf_bridge: Saved data about a bridged frame - see br_netfilter.c
* @tc_index: Traffic control index
* @tc_verd: traffic control verdict
+ * @secmark: security marking
*/
struct sk_buff {
@@ -288,6 +289,9 @@ struct sk_buff {
#ifdef CONFIG_NET_DMA
dma_cookie_tdma_cookie;
#endif
+#ifdef CONFIG_NETWORK_SECMARK
+ __u32 secmark;
+#endif
/* These elements must be at the end, see alloc_skb() for details. */
@@ -1399,5 +1403,23 @@ static inline void nf_reset(struct sk_bu
static inline void nf_reset(struct sk_buff *skb) {}
#endif /* CONFIG_NETFILTER */
+#ifdef CONFIG_NETWORK_SECMARK
+static inline void skb_copy_secmark(struct sk_buff *to, const struct sk_buff
*from)
+{
+ to->secmark = from->secmark;
+}
+
+static inline void skb_init_secmark(struct sk_buff *skb)
+{
+ skb->secmark = 0;
+}
+#else
+static inline void skb_copy_secmark(struct sk_buff *to, const struct sk_buff
*from)
+{ }
+
+static inline void skb_init_secmark(struct sk_buff *skb)
+{ }
+#endif
+
#endif /* __KERNEL__ */
#endif /* _LINUX_SKBUFF_H */
diff -puN net/core/skbuff.c~secmark-add-secmark-support-to-core-networking
net/core/skbuff.c
--- devel/net/core/skbuff.c~secmark-add-secmark-support-to-core-networking
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/core/skbuff.c2006-06-01 20:31:50.0 -0700
@@ -464,7 +464,7 @@ struct sk_buff *skb_clone(struct sk_buff
n->tc_verd = CLR_TC_MUNGED(n->tc_verd);
C(input_dev);
#endif
-
+ skb_copy_secmark(n, skb);
#endif
C(truesize);
atomic_set(&n->users, 1);
@@ -526,6 +526,7 @@ static void copy_skb_header(struct sk_bu
#endif
new->tc_index = old->tc_index;
#endif
+ skb_copy_secmark(new, old);
atomic_set(&new->users, 1);
skb_shinfo(new)->tso_size = skb_shinfo(old)->tso_size;
skb_shinfo(new)->tso_segs = skb_shinfo(old)->tso_segs;
diff -puN net/ipv4/ip_output.c~secmark-add-secmark-support-to-core-networking
net/ipv4/ip_output.c
--- devel/net/ipv4/ip_output.c~secmark-add-secmark-support-to-core-networking
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/ipv4/ip_output.c 2006-06-01 20:31:50.0 -0700
@@ -410,6 +410,7 @@ static void ip_copy_metadata(struct sk_b
nf_bridge_get(to->nf_bridge);
#endif
#endif
+ skb_copy_secmark(to, from);
}
/*
diff -puN
net/ipv4/netfilter/ipt_REJECT.c~secmark-add-secmark-support-to-core-networking
net/ipv4/netfilter/ipt_REJECT.c
---
devel/net/ipv4/netfilter/ipt_REJECT.c~secmark-add-secmark-support-to-core-networking
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/ipv4/netfilter/ipt_REJECT.c 2006-06-01 20:31:50.0
-0700
@@ -147,6 +147,7 @@ static void send_reset(struct sk_buff *o
/* This packet will not be the same as the other: clear nf fields */
nf_reset(nskb);
nskb->nfmark = 0;
+ skb_init_secmark(nskb);
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
diff -puN net/ipv6/ip6_output.c~secmark-add-secmark-support-to-core-networking
net/ipv6/ip6_output.c
--- devel/net/ipv6/ip6_output.c~secmark-add-secmark-support-to-core-networking
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/ipv6/ip6_output.c2006-06-01 20:31:50.0 -0700
@@ -459,6 +459,7 @@ static void ip6_copy_metadata(struct sk_
nf_bridge_get(to->nf_bridge);
#endif
#endif
+ skb_copy_secmark(to, from);
}
int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
diff -puN net/Kconfig~secmark-add-secmark-support-to-core-networking net/Kconfig
--- devel/net/Kconfig~secmark-add-secmark-support-to-core-networking
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/Kconfig 2006-06-01 20:31:50.0 -0700
@@ -66,6 +66,13 @@ source "net/ipv6/Kconfig"
endif # if IN
[patch 4/9] secmark: Add SELinux exports
From: James Morris <[EMAIL PROTECTED]>
Add and export new functions to the in-kernel SELinux API in support of the
new secmark-based packet controls.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/linux/selinux.h| 32
security/selinux/exports.c | 22 ++
2 files changed, 54 insertions(+)
diff -puN include/linux/selinux.h~secmark-add-selinux-exports
include/linux/selinux.h
--- devel/include/linux/selinux.h~secmark-add-selinux-exports 2006-06-01
20:31:50.0 -0700
+++ devel-akpm/include/linux/selinux.h 2006-06-01 20:31:50.0 -0700
@@ -118,6 +118,27 @@ void selinux_get_ipc_sid(const struct ke
*/
void selinux_get_task_sid(struct task_struct *tsk, u32 *sid);
+/**
+ * selinux_string_to_sid - map a security context string to a security ID
+ * @str: the security context string to be mapped
+ * @sid: ID value returned via this.
+ *
+ * Returns 0 if successful, with the SID stored in sid. A value
+ * of zero for sid indicates no SID could be determined (but no error
+ * occurred).
+ */
+int selinux_string_to_sid(char *str, u32 *sid);
+
+/**
+ * selinux_relabel_packet_permission - check permission to relabel a packet
+ * @sid: ID value to be applied to network packet (via SECMARK, most
likely)
+ *
+ * Returns 0 if the current task is allowed to label packets with the
+ * supplied security ID. Note that it is implicit that the packet is
always
+ * being relabeled from the default unlabled value, and that the access
+ * control decision is made in the AVC.
+ */
+int selinux_relabel_packet_permission(u32 sid);
#else
@@ -172,6 +193,17 @@ static inline void selinux_get_task_sid(
*sid = 0;
}
+static inline int selinux_string_to_sid(const char *str, u32 *sid)
+{
+ *sid = 0;
+ return 0;
+}
+
+static inline int selinux_relabel_packet_permission(u32 sid)
+{
+ return 0;
+}
+
#endif /* CONFIG_SECURITY_SELINUX */
#endif /* _LINUX_SELINUX_H */
diff -puN security/selinux/exports.c~secmark-add-selinux-exports
security/selinux/exports.c
--- devel/security/selinux/exports.c~secmark-add-selinux-exports
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/exports.c 2006-06-01 20:31:50.0
-0700
@@ -72,3 +72,25 @@ void selinux_get_task_sid(struct task_st
*sid = 0;
}
+int selinux_string_to_sid(char *str, u32 *sid)
+{
+ if (selinux_enabled)
+ return security_context_to_sid(str, strlen(str), sid);
+ else {
+ *sid = 0;
+ return 0;
+ }
+}
+EXPORT_SYMBOL_GPL(selinux_string_to_sid);
+
+int selinux_relabel_packet_permission(u32 sid)
+{
+ if (selinux_enabled) {
+ struct task_security_struct *tsec = current->security;
+
+ return avc_has_perm(tsec->sid, sid, SECCLASS_PACKET,
+ PACKET__RELABELTO, NULL);
+ }
+ return 0;
+}
+EXPORT_SYMBOL_GPL(selinux_relabel_packet_permission);
_
-
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 3/9] secmark: Add new flask definitions to SELinux
From: James Morris <[EMAIL PROTECTED]>
Secmark implements a new scheme for adding security markings to packets via
iptables, as well as changes to SELinux to use these markings for security
policy enforcement. The rationale for this scheme is explained and discussed
in detail in the original threads:
http://thread.gmane.org/gmane.linux.network/34927/
http://thread.gmane.org/gmane.linux.network/35244/
Examples of policy and rulesets, as well as a full archive of patches for
iptables and SELinux userland, may be found at:
http://people.redhat.com/jmorris/selinux/secmark/
The code has been tested with various compilation options and in several
scenarios, including with 'complicated' protocols such as FTP and also with
the new generic conntrack code with IPv6 connection tracking.
This patch:
Add support for a new object class ('packet'), and associated permissions
('send', 'recv', 'relabelto'). These are used to enforce security policy for
network packets labeled with SECMARK, and for adding labeling rules.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
security/selinux/include/av_perm_to_string.h |3 +++
security/selinux/include/av_permissions.h|3 +++
security/selinux/include/class_to_string.h |1 +
security/selinux/include/flask.h |1 +
4 files changed, 8 insertions(+)
diff -puN
security/selinux/include/av_permissions.h~secmark-add-new-flask-definitions-to-selinux
security/selinux/include/av_permissions.h
---
devel/security/selinux/include/av_permissions.h~secmark-add-new-flask-definitions-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/include/av_permissions.h2006-06-01
20:31:50.0 -0700
@@ -956,3 +956,6 @@
#define APPLETALK_SOCKET__SEND_MSG0x0010UL
#define APPLETALK_SOCKET__NAME_BIND 0x0020UL
+#define PACKET__SEND 0x0001UL
+#define PACKET__RECV 0x0002UL
+#define PACKET__RELABELTO 0x0004UL
diff -puN
security/selinux/include/av_perm_to_string.h~secmark-add-new-flask-definitions-to-selinux
security/selinux/include/av_perm_to_string.h
---
devel/security/selinux/include/av_perm_to_string.h~secmark-add-new-flask-definitions-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/include/av_perm_to_string.h 2006-06-01
20:31:50.0 -0700
@@ -239,3 +239,6 @@
S_(SECCLASS_ASSOCIATION, ASSOCIATION__SENDTO, "sendto")
S_(SECCLASS_ASSOCIATION, ASSOCIATION__RECVFROM, "recvfrom")
S_(SECCLASS_ASSOCIATION, ASSOCIATION__SETCONTEXT, "setcontext")
+ S_(SECCLASS_PACKET, PACKET__SEND, "send")
+ S_(SECCLASS_PACKET, PACKET__RECV, "recv")
+ S_(SECCLASS_PACKET, PACKET__RELABELTO, "relabelto")
diff -puN
security/selinux/include/class_to_string.h~secmark-add-new-flask-definitions-to-selinux
security/selinux/include/class_to_string.h
---
devel/security/selinux/include/class_to_string.h~secmark-add-new-flask-definitions-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/include/class_to_string.h 2006-06-01
20:31:50.0 -0700
@@ -59,3 +59,4 @@
S_("association")
S_("netlink_kobject_uevent_socket")
S_("appletalk_socket")
+S_("packet")
diff -puN
security/selinux/include/flask.h~secmark-add-new-flask-definitions-to-selinux
security/selinux/include/flask.h
---
devel/security/selinux/include/flask.h~secmark-add-new-flask-definitions-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/include/flask.h 2006-06-01 20:31:50.0
-0700
@@ -61,6 +61,7 @@
#define SECCLASS_ASSOCIATION 54
#define SECCLASS_NETLINK_KOBJECT_UEVENT_SOCKET 55
#define SECCLASS_APPLETALK_SOCKET56
+#define SECCLASS_PACKET 57
/*
* Security identifier indices for initial entities
_
-
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 9/9] secmark: Add new packet controls to SELinux
From: James Morris <[EMAIL PROTECTED]>
Add new per-packet access controls to SELinux, replacing the old packet
controls.
Packets are labeled with the iptables SECMARK and CONNSECMARK targets, then
security policy for the packets is enforced with these controls.
To allow for a smooth transition to the new controls, the old code is still
present, but not active by default. To restore previous behavior, the old
controls may be activated at runtime by writing a '1' to /selinux/compat_net,
and also via the kernel boot parameter selinux_compat_net. Switching between
the network control models requires the security load_policy permission. The
old controls will probably eventually be removed and any continued use is
discouraged.
With this patch, the new secmark controls for SElinux are disabled by default,
so existing behavior is entirely preserved, and the user is not affected at
all.
It also provides a config option to enable the secmark controls by default
(which can always be overridden at boot and runtime). It is also noted in the
kconfig help that the user will need updated userspace if enabling secmark
controls for SELinux and that they'll probably need the SECMARK and CONNMARK
targets, and conntrack protocol helpers, although such decisions are beyond
the scope of kernel configuration.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Cc: Stephen Smalley <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |9
security/selinux/Kconfig| 29 +++
security/selinux/hooks.c| 242 ++
security/selinux/include/xfrm.h |2
security/selinux/selinuxfs.c| 66 +++
security/selinux/xfrm.c | 12 -
6 files changed, 241 insertions(+), 119 deletions(-)
diff -puN
Documentation/kernel-parameters.txt~secmark-add-new-packet-controls-to-selinux
Documentation/kernel-parameters.txt
---
devel/Documentation/kernel-parameters.txt~secmark-add-new-packet-controls-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/Documentation/kernel-parameters.txt 2006-06-01
20:31:50.0 -0700
@@ -1405,6 +1405,15 @@ running once the system is up.
If enabled at boot time, /selinux/disable can be used
later to disable prior to initial policy load.
+ selinux_compat_net =
+ [SELINUX] Set initial selinux_compat_net flag value.
+Format: { "0" | "1" }
+0 -- use new secmark-based packet controls
+1 -- use legacy packet controls
+Default value is 0 (preferred).
+Value can be changed at runtime via
+/selinux/compat_net.
+
serialnumber[BUGS=IA-32]
sg_def_reserved_size= [SCSI]
diff -puN security/selinux/hooks.c~secmark-add-new-packet-controls-to-selinux
security/selinux/hooks.c
--- devel/security/selinux/hooks.c~secmark-add-new-packet-controls-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/hooks.c 2006-06-01 20:31:50.0 -0700
@@ -80,6 +80,7 @@
extern unsigned int policydb_loaded_version;
extern int selinux_nlmsg_lookup(u16 sclass, u16 nlmsg_type, u32 *perm);
+extern int selinux_compat_net;
#ifdef CONFIG_SECURITY_SELINUX_DEVELOP
int selinux_enforcing = 0;
@@ -3216,47 +3217,17 @@ static int selinux_socket_unix_may_send(
return 0;
}
-static int selinux_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
+static int selinux_sock_rcv_skb_compat(struct sock *sk, struct sk_buff *skb,
+ struct avc_audit_data *ad, u32 sock_sid, u16 sock_class,
+ u16 family, char *addrp, int len)
{
- u16 family;
- char *addrp;
- int len, err = 0;
+ int err = 0;
u32 netif_perm, node_perm, node_sid, if_sid, recv_perm = 0;
- u32 sock_sid = 0;
- u16 sock_class = 0;
- struct socket *sock;
- struct net_device *dev;
- struct avc_audit_data ad;
-
- family = sk->sk_family;
- if (family != PF_INET && family != PF_INET6)
- goto out;
-
- /* Handle mapped IPv4 packets arriving via IPv6 sockets */
- if (family == PF_INET6 && skb->protocol == htons(ETH_P_IP))
- family = PF_INET;
-
- read_lock_bh(&sk->sk_callback_lock);
- sock = sk->sk_socket;
- if (sock) {
- struct inode *inode;
- inode = SOCK_INODE(sock);
- if (inode) {
- struct inode_security_struct *isec;
- isec = inode->i_security;
- sock_sid = isec->sid;
- sock_class = isec->sclass;
- }
- }
- read_unlock_bh(&sk->sk_callback_lock);
- if (!sock_sid)
- goto out;
- dev = skb->dev;
- if (!dev)
+ if (!skb->d
[patch 3/8] natsemi: Add support for using MII port with no PHY
From: Mark Brown <[EMAIL PROTECTED]>
Provide a module option which configures the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool. Any PHYs that are present can be accessed via the MII
ioctl()s.
This is useful for systems where the device is connected without a PHY or
where either information or actions outside the scope of the driver are
required in order to use the PHYs.
Signed-off-by: Mark Brown <[EMAIL PROTECTED]>
Cc: Tim Hockin <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/natsemi.c | 105 +---
1 files changed, 67 insertions(+), 38 deletions(-)
diff -puN
drivers/net/natsemi.c~natsemi-add-support-for-using-mii-port-with-no-phy
drivers/net/natsemi.c
---
devel/drivers/net/natsemi.c~natsemi-add-support-for-using-mii-port-with-no-phy
2006-04-10 23:21:19.0 -0700
+++ devel-akpm/drivers/net/natsemi.c2006-04-10 23:21:19.0 -0700
@@ -259,7 +259,7 @@ MODULE_PARM_DESC(debug, "DP8381x default
MODULE_PARM_DESC(rx_copybreak,
"DP8381x copy breakpoint for copy-only-tiny-frames");
MODULE_PARM_DESC(options,
- "DP8381x: Bits 0-3: media type, bit 17: full duplex");
+ "DP8381x: Bits 0-3: media type, bit 17: full duplex, bit 18: ignore
PHY");
MODULE_PARM_DESC(full_duplex, "DP8381x full duplex setting(s) (1)");
/*
@@ -690,6 +690,8 @@ struct netdev_private {
u32 intr_status;
/* Do not touch the nic registers */
int hands_off;
+ /* Don't pay attention to the reported link state. */
+ int ignore_phy;
/* external phy that is used: only valid if dev->if_port != PORT_TP */
int mii;
int phy_addr_external;
@@ -894,7 +896,19 @@ static int __devinit natsemi_probe1 (str
np->intr_status = 0;
np->eeprom_size = NATSEMI_DEF_EEPROM_SIZE;
+ option = find_cnt < MAX_UNITS ? options[find_cnt] : 0;
+ if (dev->mem_start)
+ option = dev->mem_start;
+
+ /* Ignore the PHY status? */
+ if (option & 0x400) {
+ np->ignore_phy = 1;
+ } else {
+ np->ignore_phy = 0;
+ }
+
/* Initial port:
+* - If configured to ignore the PHY set up for external.
* - If the nic was configured to use an external phy and if find_mii
* finds a phy: use external port, first phy that replies.
* - Otherwise: internal port.
@@ -902,7 +916,7 @@ static int __devinit natsemi_probe1 (str
* The address would be used to access a phy over the mii bus, but
* the internal phy is accessed through mapped registers.
*/
- if (readl(ioaddr + ChipConfig) & CfgExtPhy)
+ if (np->ignore_phy || readl(ioaddr + ChipConfig) & CfgExtPhy)
dev->if_port = PORT_MII;
else
dev->if_port = PORT_TP;
@@ -912,7 +926,9 @@ static int __devinit natsemi_probe1 (str
if (dev->if_port != PORT_TP) {
np->phy_addr_external = find_mii(dev);
- if (np->phy_addr_external == PHY_ADDR_NONE) {
+ /* If we're ignoring the PHY it doesn't matter if we can't
+* find one. */
+ if (!np->ignore_phy && np->phy_addr_external == PHY_ADDR_NONE) {
dev->if_port = PORT_TP;
np->phy_addr_external = PHY_ADDR_INTERNAL;
}
@@ -920,10 +936,6 @@ static int __devinit natsemi_probe1 (str
np->phy_addr_external = PHY_ADDR_INTERNAL;
}
- option = find_cnt < MAX_UNITS ? options[find_cnt] : 0;
- if (dev->mem_start)
- option = dev->mem_start;
-
/* The lower four bits are the media type. */
if (option) {
if (option & 0x200)
@@ -957,7 +969,10 @@ static int __devinit natsemi_probe1 (str
if (mtu)
dev->mtu = mtu;
- netif_carrier_off(dev);
+ if (np->ignore_phy)
+ netif_carrier_on(dev);
+ else
+ netif_carrier_off(dev);
/* get the initial settings from hardware */
tmp= mdio_read(dev, MII_BMCR);
@@ -1005,6 +1020,8 @@ static int __devinit natsemi_probe1 (str
printk("%02x, IRQ %d", dev->dev_addr[i], irq);
if (dev->if_port == PORT_TP)
printk(", port TP.\n");
+ else if (np->ignore_phy)
+ printk(", port MII, ignoring PHY\n");
else
printk(", port MII, phy ad %d.\n",
np->phy_addr_external);
}
@@ -1685,42 +1702,44 @@ static void check_link(struct net_device
{
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
- int duplex;
+ int duplex = np->full_dupl
[patch 1/9] git-net: NET_TCPPROBE Kconfig fix
From: Dave Jones <[EMAIL PROTECTED]> Just spotted this typo in a new option. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> Cc: "David S. Miller" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- net/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN net/Kconfig~git-net-net_tcpprobe-kconfig-fix net/Kconfig --- devel/net/Kconfig~git-net-net_tcpprobe-kconfig-fix 2006-06-07 23:58:31.0 -0700 +++ devel-akpm/net/Kconfig 2006-06-07 23:58:31.0 -0700 @@ -227,7 +227,7 @@ config NET_TCPPROBE depends on INET && EXPERIMENTAL && PROC_FS && KPROBES ---help--- This module allows for capturing the changes to TCP connection - state in response to incoming patckets. It is used for debugging + state in response to incoming packets. It is used for debugging TCP congestion avoidance modules. If you don't understand what was just said, you don't need it: say N. _ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 5/8] e100: disable interrupts at boot
From: Bjorn Helgaas <[EMAIL PROTECTED]>
Apparently the Intel PRO/100 device enables interrupts on reset. Unless
firmware explicitly disables PRO/100 interrupts, we can get a flood of
interrupts when a driver attaches to an unrelated device that happens to
share the PRO/100 IRQ.
This should resolve this "irq 11: nobody cared" bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=5918
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Cc: Jesse Brandeburg <[EMAIL PROTECTED]>
Cc: Jeff Kirsher <[EMAIL PROTECTED]>
Cc: John Ronciak <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c | 57 +
1 file changed, 57 insertions(+)
diff -puN drivers/pci/quirks.c~e100-disable-interrupts-at-boot
drivers/pci/quirks.c
--- devel/drivers/pci/quirks.c~e100-disable-interrupts-at-boot 2006-06-06
17:25:42.0 -0700
+++ devel-akpm/drivers/pci/quirks.c 2006-06-06 17:25:42.0 -0700
@@ -1390,6 +1390,63 @@ static void __devinit quirk_netmos(struc
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NETMOS, PCI_ANY_ID, quirk_netmos);
+static void __devinit quirk_e100_interrupt(struct pci_dev *dev)
+{
+ u16 command;
+ u32 bar;
+ u8 __iomem *csr;
+ u8 cmd_hi;
+
+ switch (dev->device) {
+ /* PCI IDs taken from drivers/net/e100.c */
+ case 0x1029:
+ case 0x1030 ... 0x1034:
+ case 0x1038 ... 0x103E:
+ case 0x1050 ... 0x1057:
+ case 0x1059:
+ case 0x1064 ... 0x106B:
+ case 0x1091 ... 0x1095:
+ case 0x1209:
+ case 0x1229:
+ case 0x2449:
+ case 0x2459:
+ case 0x245D:
+ case 0x27DC:
+ break;
+ default:
+ return;
+ }
+
+ /*
+* Some firmware hands off the e100 with interrupts enabled,
+* which can cause a flood of interrupts if packets are
+* received before the driver attaches to the device. So
+* disable all e100 interrupts here. The driver will
+* re-enable them when it's ready.
+*/
+ pci_read_config_word(dev, PCI_COMMAND, &command);
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &bar);
+
+ if (!(command & PCI_COMMAND_MEMORY) || !bar)
+ return;
+
+ csr = ioremap(bar, 8);
+ if (!csr) {
+ printk(KERN_WARNING "PCI: Can't map %s e100 registers\n",
+ pci_name(dev));
+ return;
+ }
+
+ cmd_hi = readb(csr + 3);
+ if (cmd_hi == 0) {
+ printk(KERN_WARNING "PCI: Firmware left %s e100 interrupts "
+ "enabled, disabling\n", pci_name(dev));
+ writeb(1, csr + 3);
+ }
+
+ iounmap(csr);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, quirk_e100_interrupt);
static void __devinit fixup_rev1_53c810(struct pci_dev* dev)
{
_
-
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 8/8] ipw2200 locking fix
From: Zhu Yi <[EMAIL PROTECTED]>
Well, this is not 100% if when the card fires two consecutive
interrupts. Though unlikely, it's better to protect early than seeing
some "weird" bugs one day. I proposed attached patch. If you can help to
test, that will be appreciated (I cannot see the lockdep warning on my
box somehow).
Cc: Frederik Deweerdt <[EMAIL PROTECTED]>
Cc: Arjan van de Ven <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/wireless/ipw2200.c | 41 ---
drivers/net/wireless/ipw2200.h |1
2 files changed, 33 insertions(+), 9 deletions(-)
diff -puN drivers/net/wireless/ipw2200.c~ipw2200-locking-fix
drivers/net/wireless/ipw2200.c
--- devel/drivers/net/wireless/ipw2200.c~ipw2200-locking-fix2006-06-04
23:58:05.0 -0700
+++ devel-akpm/drivers/net/wireless/ipw2200.c 2006-06-04 23:58:05.0
-0700
@@ -533,7 +533,7 @@ static inline void ipw_clear_bit(struct
ipw_write32(priv, reg, ipw_read32(priv, reg) & ~mask);
}
-static inline void ipw_enable_interrupts(struct ipw_priv *priv)
+static inline void __ipw_enable_interrupts(struct ipw_priv *priv)
{
if (priv->status & STATUS_INT_ENABLED)
return;
@@ -541,7 +541,7 @@ static inline void ipw_enable_interrupts
ipw_write32(priv, IPW_INTA_MASK_R, IPW_INTA_MASK_ALL);
}
-static inline void ipw_disable_interrupts(struct ipw_priv *priv)
+static inline void __ipw_disable_interrupts(struct ipw_priv *priv)
{
if (!(priv->status & STATUS_INT_ENABLED))
return;
@@ -549,6 +549,24 @@ static inline void ipw_disable_interrupt
ipw_write32(priv, IPW_INTA_MASK_R, ~IPW_INTA_MASK_ALL);
}
+static inline void ipw_enable_interrupts(struct ipw_priv *priv)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->irq_lock, flags);
+ __ipw_enable_interrupts(priv);
+ spin_unlock_irqrestore(&priv->irq_lock, flags);
+}
+
+static inline void ipw_disable_interrupts(struct ipw_priv *priv)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->irq_lock, flags);
+ __ipw_disable_interrupts(priv);
+ spin_unlock_irqrestore(&priv->irq_lock, flags);
+}
+
#ifdef CONFIG_IPW2200_DEBUG
static char *ipw_error_desc(u32 val)
{
@@ -1856,7 +1874,7 @@ static void ipw_irq_tasklet(struct ipw_p
unsigned long flags;
int rc = 0;
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock_irqsave(&priv->irq_lock, flags);
inta = ipw_read32(priv, IPW_INTA_RW);
inta_mask = ipw_read32(priv, IPW_INTA_MASK_R);
@@ -1865,6 +1883,10 @@ static void ipw_irq_tasklet(struct ipw_p
/* Add any cached INTA values that need to be handled */
inta |= priv->isr_inta;
+ spin_unlock_irqrestore(&priv->irq_lock, flags);
+
+ spin_lock_irqsave(&priv->lock, flags);
+
/* handle all the justifications for the interrupt */
if (inta & IPW_INTA_BIT_RX_TRANSFER) {
ipw_rx(priv);
@@ -1993,10 +2015,10 @@ static void ipw_irq_tasklet(struct ipw_p
IPW_ERROR("Unhandled INTA bits 0x%08x\n", inta & ~handled);
}
+ spin_unlock_irqrestore(&priv->lock, flags);
+
/* enable all interrupts */
ipw_enable_interrupts(priv);
-
- spin_unlock_irqrestore(&priv->lock, flags);
}
#define IPW_CMD(x) case IPW_CMD_ ## x : return #x
@@ -10460,7 +10482,7 @@ static irqreturn_t ipw_isr(int irq, void
if (!priv)
return IRQ_NONE;
- spin_lock(&priv->lock);
+ spin_lock(&priv->irq_lock);
if (!(priv->status & STATUS_INT_ENABLED)) {
/* Shared IRQ */
@@ -10482,7 +10504,7 @@ static irqreturn_t ipw_isr(int irq, void
}
/* tell the device to stop sending interrupts */
- ipw_disable_interrupts(priv);
+ __ipw_disable_interrupts(priv);
/* ack current interrupts */
inta &= (IPW_INTA_MASK_ALL & inta_mask);
@@ -10493,11 +10515,11 @@ static irqreturn_t ipw_isr(int irq, void
tasklet_schedule(&priv->irq_tasklet);
- spin_unlock(&priv->lock);
+ spin_unlock(&priv->irq_lock);
return IRQ_HANDLED;
none:
- spin_unlock(&priv->lock);
+ spin_unlock(&priv->irq_lock);
return IRQ_NONE;
}
@@ -11477,6 +11499,7 @@ static int ipw_pci_probe(struct pci_dev
#ifdef CONFIG_IPW2200_DEBUG
ipw_debug_level = debug;
#endif
+ spin_lock_init(&priv->irq_lock);
spin_lock_init(&priv->lock);
for (i = 0; i < IPW_IBSS_MAC_HASH_SIZE; i++)
INIT_LIST_HEAD(&priv->ibss_mac_hash[i]);
diff -puN drivers/net/wireless/ipw2200.h~ipw2200-locking-fix
drivers/net/wireless/ipw2200.h
--- devel/drivers/net/wireless/ipw2200.h~ipw2200-locking-fix2006-06-04
23:58:05.0 -0700
+++ devel-akpm/drivers/net/wireless/ipw2200.h 2006-06-04 23:58:05.0
-0700
@@ -1173,6 +1173,7 @@ struct ipw_priv {
struct i
[patch 1/8] myri10ge: alpha build fix
From: Andrew Morton <[EMAIL PROTECTED]> drivers/net/myri10ge/myri10ge.c: In function 'myri10ge_submit_8rx': drivers/net/myri10ge/myri10ge.c:772: error: 'DMA_32BIT_MASK' undeclared (first use in this function) drivers/net/myri10ge/myri10ge.c:772: error: (Each undeclared identifier is reported only once drivers/net/myri10ge/myri10ge.c:772: error: for each function it appears in.) drivers/net/myri10ge/myri10ge.c: In function 'myri10ge_probe': drivers/net/myri10ge/myri10ge.c:2607: error: 'DMA_64BIT_MASK' undeclared (first use in this function) drivers/net/myri10ge/myri10ge.c:2612: error: 'DMA_32BIT_MASK' undeclared (first use in this function) Cc: Brice Goglin <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/myri10ge/myri10ge.c |2 ++ 1 file changed, 2 insertions(+) diff -puN drivers/net/myri10ge/myri10ge.c~myri10ge-alpha-build-fix drivers/net/myri10ge/myri10ge.c --- devel/drivers/net/myri10ge/myri10ge.c~myri10ge-alpha-build-fix 2006-06-03 21:13:30.0 -0700 +++ devel-akpm/drivers/net/myri10ge/myri10ge.c 2006-06-03 21:13:43.0 -0700 @@ -59,6 +59,8 @@ #include #include #include +#include + #include #include #include _ - 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/8] smc911x Kconfig fix
From: Andrew Morton <[EMAIL PROTECTED]> In file included from drivers/net/smc911x.c:84: drivers/net/smc911x.h:46:9: warning: "SMC_USE_16BIT" is not defined drivers/net/smc911x.h:60:9: warning: "SMC_USE_32BIT" is not defined drivers/net/smc911x.h:73:10: warning: "SMC_USE_PXA_DMA" is not defined drivers/net/smc911x.c: In function `smc911x_reset': drivers/net/smc911x.c:247: warning: implicit declaration of function `SMC_inl' drivers/net/smc911x.c:249: warning: implicit declaration of function `SMC_outl' Cc: Dustin McIntire <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/Kconfig~smc911x-Kconfig-fix drivers/net/Kconfig --- devel/drivers/net/Kconfig~smc911x-Kconfig-fix 2006-04-26 20:42:30.0 -0700 +++ devel-akpm/drivers/net/Kconfig 2006-04-26 20:42:56.0 -0700 @@ -869,7 +869,7 @@ config SMC911X tristate "SMSC LAN911[5678] support" select CRC32 select MII - depends on NET_ETHERNET + depends on NET_ETHERNET && ARCH_PXA help This is a driver for SMSC's LAN911x series of Ethernet chipsets including the new LAN9115, LAN9116, LAN9117, and LAN9118. _ - 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: Using netconsole for debugging suspend/resume
Jeremy Fitzhardinge wrote:
Matt Mackall wrote:
That's odd. Netpoll holds a reference to the device, of course, but so
does a normal "up" interface. So that shouldn't be the problem.
Another possibility is that outgoing packets from printks in the
driver are causing difficulty. Not sure what can be done about that.
I only tried once; maybe I misunderstood what was going on. I'll try
again tonight.
Oh, I think I see what's happening. The e1000 suspend routine does this:
if (netif_running(netdev))
e1000_down(adapter);
This leaves the interface up, but it stops the queue. Then
netpoll_send_skb() has this loop:
do {
npinfo->tries--;
spin_lock(&np->dev->xmit_lock);
np->dev->xmit_lock_owner = smp_processor_id();
/*
* network drivers do not expect to be called if the queue is
* stopped.
*/
if (netif_queue_stopped(np->dev)) {
np->dev->xmit_lock_owner = -1;
spin_unlock(&np->dev->xmit_lock);
netpoll_poll(np);
udelay(50);
continue;
}
/* ... */
again: /* proposed */
} while (npinfo->tries > 0);
so this will end up in an infinite loop, since netif_queue_stopped()
will always return true, and it never looks at npinfo->tries. Should
the "continue" be "goto again"?
netconsole should retry. There is no timeout programmed here since that might
lose important information, and you rather want netconsole to survive an odd
unplugged cable then to lose vital debugging information when the system is
busy for instance. (losing link will cause the interface to be down and thus
the queue to be stopped)
Also, e1000_down does a netif_poll_disable(), but I'm not sure what that
actually does... Should it prevent netpoll from even trying to send?
polling is for receives. We're basically telling the stack not to poll our
interface anymore.
It's generally going to suck, because unlike a polled serial port, the
device needs to be put to sleep. But if you're doing suspend to RAM,
I'm interested in suspend-to-ram. I presume that with suspend-to-disk,
booting with built-in netconsole will tell me useful stuff; that'll be
the next experiment.
you might be able to do something like this:
- unhook net device from suspend machinery (possibly just return success)
- bounce out of suspend before the final call to ACPI is made
Net effect is you do OS-level suspend and resume of everything but the
NIC without actually powering down the core. Which should let you
debug just about everything.
Well, the machine has to really suspend so that I can see (and debug) a
mostly normal resume. In particular, I need the hardware to be zapped
so I can see if it is being restarted properly.
What might work is to change the e1000 suspend routine to save enough
state for resume to work, but keep the interface up so that netconsole
can keep transmitting all the way up to the point that the final acpi
call powers off the machine.
e1000_suspend saves the entire configuration of the device and puts it in
Wake-on-Lan mode, allowing it to be waken up by your 'zap' in the proper way.
Then the e1000 would resume normally, including restarting the xmit
queue so that netconsole can start again immediately; any netconsole
output before the e1000 resume would be lost, of course (I guess it
could be buffered). That would suit me for now.
after coming out of suspend, e1000_resume is called which basically
reinitializes the entire device. In the entire sequence it is unlikely that
you'll actually be able to maintain netconsole in the first boot stage - the
network device will not be initialized by the kernel yet, and obviously will
be useless until e1000_resume is called!
I'm not sure that tweaking e1000 to survive longer is the answer here, and you
might be better off trying to have netconsole graciously wait
(msleep_interruptable instead of udelay?) In any case, I see the biggest
problem in the early boot stage when all nics are basically uninitialized
until resume starts. You just can't assign it an IP address for instance that
easy, and even resume causes the device to reset and thus link renegotiation,
adding crucial seconds to the time that the link is down, in which time you're
stacking up netconsole messages, or worse, fail to initialize netconsole
I hope this helps - I can't help but thinking that netconsole definately
wasn't designed with this in mind.
Cheers,
Auke
-
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: Netchannels: netchannel vs. socket. 2:0.
On Fri, Jun 09, 2006 at 01:00:24AM +0200, Hans Henrik Happe ([EMAIL PROTECTED]) wrote: > On Thursday 08 June 2006 19:15, you wrote: > > After some enhancements made for netchannel subsystem I'm pleased to > > announce, that netchannel subsystem outperforms existing layered design > > both in CPU usage and network speed. > > > > Well, after such pretentious introduction I want to cool things down. > > CPU usage is about 1-2% less for netchannels and network performance is > > about 1-2 MB higher and sometimes exceeds 84 MB/sec which, I think, > > is maximum for given network setup (e1000 receive, r8169 send, 1500 MTU). > > I have followed your work closely and have wondered how it affects latency? > I have somewhat limited knowledge about TCP and how the kernel handles it, > but > I guess the path from NIC to userspace hasn't increased. What about syscall > overhead caused by userspace TCP processing? Path from NIC to userspace was decreased in that way that there are less number of context switches, much smaller amount of work being done in softirq (I have not modified driver and still use NAPI), less cache thrashing due to work ping-ponging and less number of locks. Number of syscalls is still the same - either one recv() or one netchannel_control() to read the same block of data. But since existing socket code is used, gain is not that big, since sockets are locked, although they should not, skbs are requeued, ACKs are scheduled, although all that could be changed. At least receiving part of the netchannel TCP processing could be different. And my thoughts move in that direction. > H³ -- 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: [patch 06/17] neighbour.c, pneigh_get_next() skips published entry
Jari Takkala <[EMAIL PROTECTED]> wrote:
>
> I have not checked neigh seqfile iterators, the problem may exist in
> there as well. My patch solves this issue for us, however a more elegant
> solution would be most welcome. Could the root of the problem be that
> *pos is off by one when pneigh_get_idx() is called?
Could you post an exact sequence of commands that reproduces the bug?
That would help us in verifying your fix.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Fw: [Bugme-new] [Bug 6666] New: invalid tcp socket connection to windows stacks
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> If it's buggy you get :
>
> 11:24:15.021572 d59.x-mailer.de.59959 >
> cust.static.212-90-215-40.cybernet.ch.smtp: S 2028538653:2028538653(0) win
> 5840
> (DF)
> 11:24:15.076329 cust.static.212-90-215-40.cybernet.ch.smtp >
> d59.x-mailer.de.59959: S 2328498080:2328498080(0) ack 2028538654 win 16384
> 1400,nop,wscale 0,nop,nop,timestamp 0
> 0,nop,nop,sackOK>
> 11:24:15.076352 d59.x-mailer.de.59959 >
> cust.static.212-90-215-40.cybernet.ch.smtp: . ack 1 win 46 243108503 0> (DF)
...
> ### you should get kind of this:
>
> 13:56:37.203297 d59.x-mailer.de.43286 >
> cust.static.212-90-215-40.cybernet.ch.smtp: S 1489507409:1489507409(0) win
> 5840
> (DF)
> 13:56:37.250827 cust.static.212-90-215-40.cybernet.ch.smtp >
> d59.x-mailer.de.43286: S 783498912:783498912(0) ack 1489507410 win 16384 1400,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK>
> 13:56:37.250888 d59.x-mailer.de.43286 >
> cust.static.212-90-215-40.cybernet.ch.smtp: . ack 1 win 1460
> 16627473 0> (DF)
Looks like the problem is window scaling.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: netif_tx_disable vs netif_stop_queue (possible races?)
Daniel Drake <[EMAIL PROTECTED]> wrote:
>
> More specifically, we're talking about drivers/usb/net/usbnet.c and the
> usbnet_disconnect() function. The race I am highlighting is that
> usbnet's hard_start_xmit handler (usbnet_start_xmit) may be running when
> the disconnect happens.
>
> Is this a possible scenario?
It should be safe, if only because of the synchronize_net that occurs
before a netdev can be freed.
However, there is definitely room for clean-ups. In particular, LLTX
drivers have changed the meaning of xmit_lock so things like dev_deactivate
no longer carries the same power they used to.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 RFC] netpoll: don't spin forever sending to stopped queues
Matt Mackall wrote:
That's odd. Netpoll holds a reference to the device, of course, but so
does a normal "up" interface. So that shouldn't be the problem.
Another possibility is that outgoing packets from printks in the
driver are causing difficulty. Not sure what can be done about that.
Here's a patch. I haven't tested it beyond compiling it, and I don't
know if it is actually correct. In this case, it seems pointless to
spin waiting for an even which will never happen. Should
netif_poll_disable() cause netpoll_send_skb() (or something) to not even
bother trying to send? netif_poll_disable seems mysteriously simple to me.
J
--
Subject: netpoll: don't spin forever sending to stopped queues
When transmitting a skb in netpoll_send_skb(), only retry a limited
number of times if the device queue is stopped.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
diff -r aac813f54617 net/core/netpoll.c
--- a/net/core/netpoll.cWed Jun 07 14:53:40 2006 -0700
+++ b/net/core/netpoll.cThu Jun 08 19:00:29 2006 -0700
@@ -280,15 +280,10 @@ static void netpoll_send_skb(struct netp
* network drivers do not expect to be called if the queue is
* stopped.
*/
- if (netif_queue_stopped(np->dev)) {
- np->dev->xmit_lock_owner = -1;
- spin_unlock(&np->dev->xmit_lock);
- netpoll_poll(np);
- udelay(50);
- continue;
- }
-
- status = np->dev->hard_start_xmit(skb, np->dev);
+ status = NETDEV_TX_BUSY;
+ if (!netif_queue_stopped(np->dev))
+ status = np->dev->hard_start_xmit(skb, np->dev);
+
np->dev->xmit_lock_owner = -1;
spin_unlock(&np->dev->xmit_lock);
-
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: Using netconsole for debugging suspend/resume
Rafael J. Wysocki wrote: Please try doing "echo 8 > /proc/sys/kernel/printk" before suspend. Um, why? That would increase the amount of log output, but I don't see how it would help with netconsole preventing suspend, or not being able to see console messages on a blank screen after resume. J - 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: Using netconsole for debugging suspend/resume
Matt Mackall wrote:
That's odd. Netpoll holds a reference to the device, of course, but so
does a normal "up" interface. So that shouldn't be the problem.
Another possibility is that outgoing packets from printks in the
driver are causing difficulty. Not sure what can be done about that.
I only tried once; maybe I misunderstood what was going on. I'll try
again tonight.
Oh, I think I see what's happening. The e1000 suspend routine does this:
if (netif_running(netdev))
e1000_down(adapter);
This leaves the interface up, but it stops the queue. Then
netpoll_send_skb() has this loop:
do {
npinfo->tries--;
spin_lock(&np->dev->xmit_lock);
np->dev->xmit_lock_owner = smp_processor_id();
/*
* network drivers do not expect to be called if the queue is
* stopped.
*/
if (netif_queue_stopped(np->dev)) {
np->dev->xmit_lock_owner = -1;
spin_unlock(&np->dev->xmit_lock);
netpoll_poll(np);
udelay(50);
continue;
}
/* ... */
again: /* proposed */
} while (npinfo->tries > 0);
so this will end up in an infinite loop, since netif_queue_stopped()
will always return true, and it never looks at npinfo->tries. Should
the "continue" be "goto again"?
Also, e1000_down does a netif_poll_disable(), but I'm not sure what that
actually does... Should it prevent netpoll from even trying to send?
It's generally going to suck, because unlike a polled serial port, the
device needs to be put to sleep. But if you're doing suspend to RAM,
I'm interested in suspend-to-ram. I presume that with suspend-to-disk,
booting with built-in netconsole will tell me useful stuff; that'll be
the next experiment.
you might be able to do something like this:
- unhook net device from suspend machinery (possibly just return success)
- bounce out of suspend before the final call to ACPI is made
Net effect is you do OS-level suspend and resume of everything but the
NIC without actually powering down the core. Which should let you
debug just about everything.
Well, the machine has to really suspend so that I can see (and debug) a
mostly normal resume. In particular, I need the hardware to be zapped
so I can see if it is being restarted properly.
What might work is to change the e1000 suspend routine to save enough
state for resume to work, but keep the interface up so that netconsole
can keep transmitting all the way up to the point that the final acpi
call powers off the machine.
Then the e1000 would resume normally, including restarting the xmit
queue so that netconsole can start again immediately; any netconsole
output before the e1000 resume would be lost, of course (I guess it
could be buffered). That would suit me for now.
J
-
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] wan/sdla section fixes
From: Randy Dunlap <[EMAIL PROTECTED]>
Priority: tossup.
netdev->set_config can be called at any time, so these references
to __initdata would be a real problem.
However, problem has not been observed AFAIK.
Fix section mismatch warnings:
WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to .init.data:
from .text between 'sdla_set_config' (at offset 0x1b8e) and 'sdla_stats'
WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to .init.data:
from .text between 'sdla_set_config' (at offset 0x1e76) and 'sdla_stats'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/net/wan/sdla.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2617-rc6.orig/drivers/net/wan/sdla.c
+++ linux-2617-rc6/drivers/net/wan/sdla.c
@@ -60,9 +60,9 @@
static const char* version = "SDLA driver v0.30, 12 Sep 1996, [EMAIL
PROTECTED]";
-static unsigned int valid_port[] __initdata = { 0x250, 0x270, 0x280, 0x300,
0x350, 0x360, 0x380, 0x390};
+static unsigned int valid_port[] = { 0x250, 0x270, 0x280, 0x300, 0x350, 0x360,
0x380, 0x390};
-static unsigned int valid_mem[] __initdata = {
+static unsigned int valid_mem[] = {
0xA, 0xA2000, 0xA4000, 0xA6000,
0xA8000, 0xAA000, 0xAC000, 0xAE000,
0xB, 0xB2000, 0xB4000, 0xB6000,
0xB8000, 0xBA000, 0xBC000, 0xBE000,
0xC, 0xC2000, 0xC4000, 0xC6000,
0xC8000, 0xCA000, 0xCC000, 0xCE000,
---
-
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: Using netconsole for debugging suspend/resume
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote: > I've been trying to get suspend/resume working well on my new laptop. > In general, netconsole has been pretty useful for extracting oopses and > other messages, but it is of more limited help in debugging the actual > suspend/resume cycle. The problem looks like the e1000 driver won't > suspend while netconsole is using it, so I have to rmmod/modprobe > netconsole around the actual suspend/resume. If your laptop has firewire you can also use firescope. (ftp://ftp.suse.com/pub/people/ak/firescope/) > This is a big problem during resume because the screen is also blank, so > I get no useful clue as to what went wrong when things go wrong. I'm > wondering if there's some way to keep netconsole alive to the last > possible moment during suspend, and re-woken as soon as possible during > resume. It would be nice to have a clean solution, but I'm willing to > use a bletcherous hack if that's what it takes. FW keeps running as long as nobody resets the ieee1394 chip. Networking is much more complex and will likely never work well for such low level debug situations. Netconsole is mostly useful to catch the odd oops during runtime. -Andi - 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: Firewall question
> Well the DSL modem only transfers whatever data the ISP end sends to it, > which in your case is just PPP packets (LCC or LCP I think). No one out > on the internet No one out on the internet, but it would be trivial for someone outside his house. All his traffic will be on a long unsecured cable. That is why I would never bridge home ethernet traffic onto a DSL line. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
On Thu, 08 Jun 2006 22:40:05 -0400 Jeff Garzik wrote: > Randy.Dunlap wrote: > > Conversely, any reason to use the RealTek r1000 driver? > > FWIW, RealTek emailed me about merging r1000. I suggested that, if the > register sets were similar, that r8169 should be updated instead, to > preserve compatibility with existing users (and not lose existing work). Sounds good to me. I'm not terribly interested in seeing multiple drivers for the same hardware in the kernel tree. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Randy.Dunlap wrote: Conversely, any reason to use the RealTek r1000 driver? FWIW, RealTek emailed me about merging r1000. I suggested that, if the register sets were similar, that r8169 should be updated instead, to preserve compatibility with existing users (and not lose existing work). Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
Hello.
In article <[EMAIL PROTECTED]> (at Fri, 09 Jun 2006 00:56:46 +0200), Patrick
McHardy <[EMAIL PROTECTED]> says:
Okay, thanks.
I think it is better to eliminate these magic numbers.
How about this?
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 445006e..b5267c6 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2860,6 +2860,11 @@ inet6_rtm_newaddr(struct sk_buff *skb, s
return inet6_addr_add(ifm->ifa_index, pfx, ifm->ifa_prefixlen);
}
+/* Maximum length of ifa_cacheinfo attributes */
+#define INET6_IFADDR_RTA_SPACE \
+ RTA_SPACE(16) /* IFA_ADDRESS */ + \
+ RTA_SPACE(sizeof(struct ifa_cacheinfo)) /* CACHEINFO */
+
static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa,
u32 pid, u32 seq, int event, unsigned int flags)
{
@@ -3092,7 +3097,7 @@ static int inet6_dump_ifacaddr(struct sk
static void inet6_ifa_notify(int event, struct inet6_ifaddr *ifa)
{
struct sk_buff *skb;
- int size = NLMSG_SPACE(sizeof(struct ifaddrmsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifaddrmsg) +
INET6_IFADDR_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
@@ -3142,6 +3147,16 @@ static void inline ipv6_store_devconf(st
#endif
}
+/* Maximum length of ifinfomsg attributes */
+#define INET6_IFINFO_RTA_SPACE \
+ RTA_SPACE(IFNAMSIZ) /* IFNAME */ + \
+ RTA_SPACE(MAX_ADDR_LEN) /* ADDRESS */ + \
+ RTA_SPACE(sizeof(u32)) /* MTU */ + \
+ RTA_SPACE(0) /* PROTINFO */ + \
+ RTA_SPACE(sizeof(u32)) /* FLAGS */ + \
+ RTA_SPACE(sizeof(struct ifla_cacheinfo)) /* CACHEINFO */ + \
+ RTA_SPACE(sizeof(__s32[DEVCONF_MAX])) /* CONF */
+
static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev,
u32 pid, u32 seq, int event, unsigned int flags)
{
@@ -3235,8 +3250,7 @@ static int inet6_dump_ifinfo(struct sk_b
void inet6_ifinfo_notify(int event, struct inet6_dev *idev)
{
struct sk_buff *skb;
- /* 128 bytes ?? */
- int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifinfomsg) +
INET6_IFINFO_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
@@ -3252,6 +3266,11 @@ void inet6_ifinfo_notify(int event, stru
netlink_broadcast(rtnl, skb, 0, RTNLGRP_IPV6_IFINFO, GFP_ATOMIC);
}
+/* Maximum length of prefix_cacheinfo attributes */
+#define INET6_PREFIX_RTA_SPACE \
+ RTA_SPACE(sizeof(((struct prefix_info *)NULL)->prefix)) /*
ADDRESS */ + \
+ RTA_SPACE(sizeof(struct prefix_cacheinfo)) /* CACHEINFO */
+
static int inet6_fill_prefix(struct sk_buff *skb, struct inet6_dev *idev,
struct prefix_info *pinfo, u32 pid, u32 seq,
int event, unsigned int flags)
@@ -3296,7 +3315,7 @@ static void inet6_prefix_notify(int even
struct prefix_info *pinfo)
{
struct sk_buff *skb;
- int size = NLMSG_SPACE(sizeof(struct prefixmsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct prefixmsg) +
INET6_PREFIX_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
--
YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Randy.Dunlap <[EMAIL PROTECTED]> :
[...]
> static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
> { 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> {0,}
> };
>
> Any reason not to include all of those?
Nothing worrying:
- 0x8167 and 0x8168 use a different PCI region;
- some phy differences. They appear when the r1000 driver is
compared to the previous r8169 driver from realtek.
I'll pack it with other changes.
> Conversely, any reason to use the RealTek r1000 driver?
Feel free to read it and make your own mind.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
netif_tx_disable vs netif_stop_queue (possible races?)
Hi, In order to avoid disconnect races in ZD1211, I'm trying to convince myself that other USB network drivers are race-free (and why). I brought up a possible issue in usbnet with David Brownell, but it appears neither of us are 100% clear on the details, so it would be good to get some extra clarification. USB devices can be yanked out by the user at *any* time, and typically free_netdev is called in the disconnect handler, which frees all device-specific structures. The issue I brought up is that code using these structures may be running concurrently on another CPU when the disconnect handler is invoked, resulting in access to freed data. More specifically, we're talking about drivers/usb/net/usbnet.c and the usbnet_disconnect() function. The race I am highlighting is that usbnet's hard_start_xmit handler (usbnet_start_xmit) may be running when the disconnect happens. Is this a possible scenario? My thoughts on avoiding this are to ensure that the TX queue is stopped and all current transmissions in usbnet_stop (the netdev->stop hook). I understand that the stop function is called during disconnect, because usbnet_disconnect() calls unregister_netdev(). The stop function already has a call to netif_stop_queue but (based on my knowledge from LDD3) this is not enough. My understanding is that netif_stop_queue() should be used only inside a hard_start_xmit function, when it wants to make sure that no more transmissions are started until the queue is reopened. I suggested that we use netif_tx_disable here, which is effectively the same but because it takes the lock, it guarantees that no hard_start_xmit transmissions are running on any CPU when it returns. David pointed out that netif_tx_disable is rarely used, and a large number of drivers call netif_stop_queue in their stop function, so if what I suggest is true, there may be many such potential races elsewhere. Am I missing something simple? Thanks, Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netchannels: netchannel vs. socket. 2:0.
On Thursday 08 June 2006 19:15, you wrote: > After some enhancements made for netchannel subsystem I'm pleased to > announce, that netchannel subsystem outperforms existing layered design > both in CPU usage and network speed. > > Well, after such pretentious introduction I want to cool things down. > CPU usage is about 1-2% less for netchannels and network performance is > about 1-2 MB higher and sometimes exceeds 84 MB/sec which, I think, > is maximum for given network setup (e1000 receive, r8169 send, 1500 MTU). I have followed your work closely and have wondered how it affects latency? I have somewhat limited knowledge about TCP and how the kernel handles it, but I guess the path from NIC to userspace hasn't increased. What about syscall overhead caused by userspace TCP processing? H³ - 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
[IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
[IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
The allocated skb is too small for the message, which results in an EINVAL
getting reported to the (innocent) multicast listeners.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit f71bc8ace692302ad3a80d84b8cbccbb14e88fe5
tree 21ccfa89e911ff8e6bda04ab817367f2ac4e3173
parent 1def630a6a49dda5bc89dfbd86656293640456f0
author Patrick McHardy <[EMAIL PROTECTED]> Wed, 07 Jun 2006 09:25:26 +0200
committer Patrick McHardy <[EMAIL PROTECTED]> Wed, 07 Jun 2006 09:25:26 +0200
net/ipv6/addrconf.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 445006e..cc81cab 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3235,8 +3235,7 @@ static int inet6_dump_ifinfo(struct sk_b
void inet6_ifinfo_notify(int event, struct inet6_dev *idev)
{
struct sk_buff *skb;
- /* 128 bytes ?? */
- int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+172);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: Gerrit Renker <[EMAIL PROTECTED]> Date: Thu, 8 Jun 2006 21:09:33 +0100 > That is why I held back regarding the IPv6 port: I can ensure that > this (IPv4) code is up to standard and to date, but am lacking the > required additional time to implement the same for IPv6. I am > trying to contact people to help with the port, but for the moment I > will take responsibility only for the IPv4 version. It's not like an ipv6 port is such a big pile of work. I'd say it would take you an afternoon, max. You don't have to test it to the point where it is ISO9000 compliant, that's not what is being asked of you. - 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 8/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
Signed-off-by: Kriston Carson <[EMAIL PROTECTED]>
Signed-off-by: Xianghua Xiao <[EMAIL PROTECTED]>
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |6 +-
drivers/net/phy/Kconfig |5 ++
drivers/net/phy/Makefile |1
drivers/net/phy/vitesse.c | 112 +
4 files changed, 121 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index bdaaad8..c1c2758 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2179,11 +2179,11 @@ config SPIDER_NET
config GIANFAR
tristate "Gianfar Ethernet"
- depends on 85xx || 83xx
+ depends on 85xx || 83xx || PPC_86xx
select PHYLIB
help
- This driver supports the Gigabit TSEC on the MPC85xx
- family of chips, and the FEC on the 8540
+ This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
+ and MPC86xx family of chips, and the FEC on the 8540.
config GFAR_NAPI
bool "NAPI Support"
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index fa39b94..76e51b1 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -44,6 +44,11 @@ config CICADA_PHY
depends on PHYLIB
---help---
Currently supports the cis8204
+config VITESSE_PHY
+tristate "Drivers for the Vitesse PHYs"
+depends on PHYLIB
+---help---
+ Currently supports the vsc8244
endmenu
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e4116a5..a8d066e 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_DAVICOM_PHY) += davicom.o
obj-$(CONFIG_CICADA_PHY) += cicada.o
obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_QSEMI_PHY)+= qsemi.o
+obj-$(CONFIG_VITESSE_PHY) += vitesse.o
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
new file mode 100644
index 000..ffd215d
--- /dev/null
+++ b/drivers/net/phy/vitesse.c
@@ -0,0 +1,112 @@
+/*
+ * Driver for Vitesse PHYs
+ *
+ * Author: Kriston Carson
+ *
+ * Copyright (c) 2005 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Vitesse Extended Control Register 1 */
+#define MII_VSC8244_EXT_CON1 0x17
+#define MII_VSC8244_EXTCON1_INIT 0x
+
+/* Vitesse Interrupt Mask Register */
+#define MII_VSC8244_IMASK 0x19
+#define MII_VSC8244_IMASK_IEN 0x8000
+#define MII_VSC8244_IMASK_SPEED0x4000
+#define MII_VSC8244_IMASK_LINK 0x2000
+#define MII_VSC8244_IMASK_DUPLEX 0x1000
+#define MII_VSC8244_IMASK_MASK 0xf000
+
+/* Vitesse Interrupt Status Register */
+#define MII_VSC8244_ISTAT 0x1a
+#define MII_VSC8244_ISTAT_STATUS 0x8000
+#define MII_VSC8244_ISTAT_SPEED0x4000
+#define MII_VSC8244_ISTAT_LINK 0x2000
+#define MII_VSC8244_ISTAT_DUPLEX 0x1000
+
+/* Vitesse Auxiliary Control/Status Register */
+#define MII_VSC8244_AUX_CONSTAT0x1c
+#define MII_VSC8244_AUXCONSTAT_INIT0x0004
+#define MII_VSC8244_AUXCONSTAT_DUPLEX 0x0020
+#define MII_VSC8244_AUXCONSTAT_SPEED 0x0018
+#define MII_VSC8244_AUXCONSTAT_GBIT0x0010
+#define MII_VSC8244_AUXCONSTAT_100 0x0008
+
+MODULE_DESCRIPTION("Vitesse PHY driver");
+MODULE_AUTHOR("Kriston Carson");
+MODULE_LICENSE("GPL");
+
+static int vsc824x_config_init(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_write(phydev, MII_VSC8244_AUX_CONSTAT,
+ MII_VSC8244_AUXCONSTAT_INIT);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, MII_VSC8244_EXT_CON1,
+ MII_VSC8244_EXTCON1_INIT);
+ return err;
+}
+
+static int vsc824x_ack_interrupt(struct phy_device *phydev)
+{
+ int err = phy_read(phydev, MII_VSC8244_ISTAT);
+
+ return (err < 0) ? err : 0;
+}
+
+static int vsc824x_config_intr(struct phy_device *phydev)
+{
+ int err;
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ err = phy_write(phydev, MII_VSC8244_IMASK,
+ MII_VSC8244_IMASK_MASK);
+ else
+ err = phy_write(phydev, MII_VSC8244_IMASK, 0);
+ return err;
+}
+
+/* Vitesse 824x */
+static struct phy_driver vsc8244_driver = {
+ .phy_id = 0x000fc6c2,
+ .name = "Vitesse VSC8244",
+ .phy_id_mask= 0x000fffc0,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init= &vsc82
[git patches] net driver fixes
Just got back from travelling, and am catching up. Thanks to Andrew for
working with me via email while I was on the road, he pushed a couple
patches already for me.
Here are the netdev fixes that were in my 'Pending' folder. I've got a
couple libata fixes to push as well, those may not come until tomorrow.
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/e1000/e1000_ethtool.c |5 +++-
drivers/net/e1000/e1000_main.c |8 +--
drivers/net/wireless/bcm43xx/bcm43xx_dma.c | 31 -
3 files changed, 28 insertions(+), 16 deletions(-)
Auke Kok:
e1000: fix ethtool test irq alloc as "probe"
e1000: remove risky prefetch on next_skb->data
Michael Buesch:
bcm43xx: add DMA rx poll workaround to DMA4
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index ea3..d1c705b 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -870,13 +870,16 @@ e1000_intr_test(struct e1000_adapter *ad
*data = 0;
/* Hook up test interrupt handler just for this test */
- if (!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) {
+ if (!request_irq(irq, &e1000_test_intr, SA_PROBEIRQ, netdev->name,
+netdev)) {
shared_int = FALSE;
} else if (request_irq(irq, &e1000_test_intr, SA_SHIRQ,
netdev->name, netdev)){
*data = 1;
return -1;
}
+ DPRINTK(PROBE,INFO, "testing %s interrupt\n",
+ (shared_int ? "shared" : "unshared"));
/* Disable all the interrupts */
E1000_WRITE_REG(&adapter->hw, IMC, 0x);
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index ed15fca..97e71a4 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3519,7 +3519,7 @@ #endif
buffer_info = &rx_ring->buffer_info[i];
while (rx_desc->status & E1000_RXD_STAT_DD) {
- struct sk_buff *skb, *next_skb;
+ struct sk_buff *skb;
u8 status;
#ifdef CONFIG_E1000_NAPI
if (*work_done >= work_to_do)
@@ -3537,8 +3537,6 @@ #endif
prefetch(next_rxd);
next_buffer = &rx_ring->buffer_info[i];
- next_skb = next_buffer->skb;
- prefetch(next_skb->data - NET_IP_ALIGN);
cleaned = TRUE;
cleaned_count++;
@@ -3668,7 +3666,7 @@ #endif
struct e1000_buffer *buffer_info, *next_buffer;
struct e1000_ps_page *ps_page;
struct e1000_ps_page_dma *ps_page_dma;
- struct sk_buff *skb, *next_skb;
+ struct sk_buff *skb;
unsigned int i, j;
uint32_t length, staterr;
int cleaned_count = 0;
@@ -3697,8 +3695,6 @@ #endif
prefetch(next_rxd);
next_buffer = &rx_ring->buffer_info[i];
- next_skb = next_buffer->skb;
- prefetch(next_skb->data - NET_IP_ALIGN);
cleaned = TRUE;
cleaned_count++;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
index bbecba0..d0318e5 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -624,25 +624,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
-* in the lower 12 bits
+* in the lower 12 bits.
+* Note that the cookie must never be 0, as this
+* is a special value used in RX path.
*/
switch (ring->mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot & 0xF000) == 0x);
@@ -660,16 +663,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x:
+ case 0xA000:
ring = dma->tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma->tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dm
Re: [RFT] Realtek 8168 ethernet support
On Thu, 1 Jun 2006 21:02:00 +0100 (BST) Daniel Drake wrote:
> I've produced this patch which should allow the r8169 driver to work with the
> new Realtek 8168 chips. These are found in PCI-Express form and onboard some
> newer motherboards.
>
> Does anyone own this hardware? I'm looking for someone to test it before I
> send it on.
>
> Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
>
> Index: linux/drivers/net/r8169.c
> ===
> --- linux.orig/drivers/net/r8169.c
> +++ linux/drivers/net/r8169.c
> @@ -184,6 +184,7 @@ static const struct {
>
> static struct pci_device_id rtl8169_pci_tbl[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
> + { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), },
> { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
> { PCI_DEVICE(0x16ec,0x0116), },
> { PCI_VENDOR_ID_LINKSYS,0x1032, PCI_ANY_ID, 0x0024, },
The (GPL) RealTek driver (from
http://www.realtek.com.tw/downloads/downloads1-3.aspx?lineid=1&famid=4&series=2003072&Software=True)
contains this PCI device table:
static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
{ 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{0,}
};
Any reason not to include all of those?
Conversely, any reason to use the RealTek r1000 driver?
> @@ -1398,6 +1399,7 @@ rtl8169_init_board(struct pci_dev *pdev,
> struct net_device *dev;
> struct rtl8169_private *tp;
> int rc = -ENOMEM, i, acpi_idle_state = 0, pm_cap;
> + u32 mmio_base = 0;
>
> assert(ioaddr_out != NULL);
>
> @@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
> }
> }
>
> - /* make sure PCI base addr 1 is MMIO */
> - if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
> - if (netif_msg_probe(tp)) {
> - printk(KERN_ERR PFX
> -"region #1 not an MMIO resource, aborting\n");
> - }
> - rc = -ENODEV;
> - goto err_out_mwi;
> + /* find MMIO resource: this varies between 8168 and 8169 */
> + for (i = 0; i < 5; i++) {
> + /* check resource type */
> + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> + continue;
> +
> + /* check for weird/broken PCI region reporting */
> + if (pci_resource_len(pdev, i) < R8169_REGS_SIZE)
> + continue;
> +
> + mmio_base = pci_resource_start(pdev, i);
> + break;
> }
> - /* check for weird/broken PCI region reporting */
> - if (pci_resource_len(pdev, 1) < R8169_REGS_SIZE) {
> +
> + if (mmio_base == 0) {
> if (netif_msg_probe(tp)) {
> printk(KERN_ERR PFX
> -"Invalid PCI region size(s), aborting\n");
> +"couldn't find valid MMIO resource, aborting\n");
> }
> rc = -ENODEV;
> goto err_out_mwi;
> @@ -1490,7 +1496,7 @@ rtl8169_init_board(struct pci_dev *pdev,
> pci_set_master(pdev);
>
> /* ioremap MMIO region */
> - ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE);
> + ioaddr = ioremap(mmio_base, R8169_REGS_SIZE);
> if (ioaddr == NULL) {
> if (netif_msg_probe(tp))
> printk(KERN_ERR PFX "cannot remap MMIO, aborting\n");
> -
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New tulip maintainer...
On 6/8/06, Grant Grundler <[EMAIL PROTECTED]> wrote: On Thu, Jun 08, 2006 at 11:41:28AM -0400, Jeff Garzik wrote: > Now that we have a new tulip maintainer, perhaps a resend of the > long-outstanding tulip phy patches could be resent? All the tulip patches I have are archived here: ftp://ftp.parisc-linux.org/patches/ Anything else tulip I've been involved with is available via CVS from cvs.parisc-linux.org/linux-2.6/ Thibaut Varene has also committed his changes to that CVS. Hey folks, Just a quick note to say that, yes, in a moment of weak-willed delusion, I did let Jeff pressure me into becoming the tulip maintainer. I will accept tokens of condolence in the form of beer, money, and old tulip cards (email me for my shipping address). I'm going to be a tiny bit busy the next couple of weeks - minor things like running the file systems workshop and moving house - but I am paying attention and will start testing and shipping patches as soon as possible. One quick note: please use my spiffy [EMAIL PROTECTED] address (see From: address) for Linux stuff. Besides giving props to my employer, it's much easier to send/receive patches from that account. -VAL - 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: Using netconsole for debugging suspend/resume
On Thu, Jun 08, 2006 at 10:50:57AM -0700, Jeremy Fitzhardinge wrote: > I've been trying to get suspend/resume working well on my new laptop. > In general, netconsole has been pretty useful for extracting oopses and > other messages, but it is of more limited help in debugging the actual > suspend/resume cycle. The problem looks like the e1000 driver won't > suspend while netconsole is using it, so I have to rmmod/modprobe > netconsole around the actual suspend/resume. That's odd. Netpoll holds a reference to the device, of course, but so does a normal "up" interface. So that shouldn't be the problem. Another possibility is that outgoing packets from printks in the driver are causing difficulty. Not sure what can be done about that. > This is a big problem during resume because the screen is also blank, so > I get no useful clue as to what went wrong when things go wrong. I'm > wondering if there's some way to keep netconsole alive to the last > possible moment during suspend, and re-woken as soon as possible during > resume. It would be nice to have a clean solution, but I'm willing to > use a bletcherous hack if that's what it takes. It's generally going to suck, because unlike a polled serial port, the device needs to be put to sleep. But if you're doing suspend to RAM, you might be able to do something like this: - unhook net device from suspend machinery (possibly just return success) - bounce out of suspend before the final call to ACPI is made Net effect is you do OS-level suspend and resume of everything but the NIC without actually powering down the core. Which should let you debug just about everything. -- Mathematics is the supreme nostalgia of our time. - 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 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
Jon Loeliger wrote: On Thu, 2006-06-08 at 15:46, Jeff Garzik wrote: I leave it up to you and Paul to coordinate, then :) I'm fine with the patch, and if its better to merge via linuxppc.git, that's OK with me. If you would prefer to send it via my tree, to go ahead and get it in, that's fine too. OK, thanks. I need to re-submit 5 of 10 parts for other cleanup issues anyway, so I think I will: - Resubmit the entire patch set, - Resubmit netdev parts to Paul, and netdev with an added ACK: by you line (OK?), OK with me. Since we use a specific header to indicate such, that would be: Acked-by: Jeff Garzik <[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: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
On Thu, 2006-06-08 at 15:46, Jeff Garzik wrote: > I leave it up to you and Paul to coordinate, then :) > > I'm fine with the patch, and if its better to merge via linuxppc.git, > that's OK with me. If you would prefer to send it via my tree, to go > ahead and get it in, that's fine too. OK, thanks. I need to re-submit 5 of 10 parts for other cleanup issues anyway, so I think I will: - Resubmit the entire patch set, - Resubmit netdev parts to Paul, and netdev with an added ACK: by you line (OK?), - Throw myself on the mercy of "Help us Obi-wan Mackerras" and see what he says when he wakes up! Thanks! jdl - 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 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
Jon Loeliger wrote: On Thu, 2006-06-08 at 15:36, Jeff Garzik wrote: Is it dependent on other stuff in Paul's tree? Yes, very much so. Most of this patch set is an entirely new PPC board port against his arch/powerpc basis. The new PHY is incidentally on that board, but the patches for its introduction could be introduced through the netdev tree if needed. It would just need to be coordinated some. I am, of course, willing to work it either way as needed. I leave it up to you and Paul to coordinate, then :) I'm fine with the patch, and if its better to merge via linuxppc.git, that's OK with me. If you would prefer to send it via my tree, to go ahead and get it in, that's fine too. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
On Thu, 2006-06-08 at 15:36, Jeff Garzik wrote: > Is it dependent on other stuff in Paul's tree? Yes, very much so. Most of this patch set is an entirely new PPC board port against his arch/powerpc basis. The new PHY is incidentally on that board, but the patches for its introduction could be introduced through the netdev tree if needed. It would just need to be coordinated some. I am, of course, willing to work it either way as needed. jdl - 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: Using netconsole for debugging suspend/resume
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote: > I've been trying to get suspend/resume working well on my new laptop. > In general, netconsole has been pretty useful for extracting oopses and > other messages, but it is of more limited help in debugging the actual > suspend/resume cycle. The problem looks like the e1000 driver won't > suspend while netconsole is using it, so I have to rmmod/modprobe > netconsole around the actual suspend/resume. > > This is a big problem during resume because the screen is also blank, so > I get no useful clue as to what went wrong when things go wrong. I'm > wondering if there's some way to keep netconsole alive to the last > possible moment during suspend, and re-woken as soon as possible during > resume. It would be nice to have a clean solution, but I'm willing to > use a bletcherous hack if that's what it takes. > > Any ideas? Please try doing "echo 8 > /proc/sys/kernel/printk" before suspend. Greetings, Rafael - 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: Using netconsole for debugging suspend/resume
Jeremy Fitzhardinge wrote: I've been trying to get suspend/resume working well on my new laptop. In general, netconsole has been pretty useful for extracting oopses and other messages, but it is of more limited help in debugging the actual suspend/resume cycle. The problem looks like the e1000 driver won't suspend while netconsole is using it, so I have to rmmod/modprobe netconsole around the actual suspend/resume. This is a big problem during resume because the screen is also blank, so I get no useful clue as to what went wrong when things go wrong. I'm wondering if there's some way to keep netconsole alive to the last possible moment during suspend, and re-woken as soon as possible during resume. It would be nice to have a clean solution, but I'm willing to use a bletcherous hack if that's what it takes. Any ideas? Have you tried using different cards/drivers? This might or might not be either a netconsole problem (generic) or driver related (which could impact other drivers too). From the top of my head I don't see any reason why the e1000 shouldn't handle the suspend event - but mind you that a fix for e1000/WoL impacting shutdown handlers was only recently added. Which kernels does this impact? Auke - 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 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
Jon Loeliger wrote: On Thu, 2006-06-08 at 14:34, Jeff Garzik wrote: Jon Loeliger wrote: Signed-off-by: Kriston Carson <[EMAIL PROTECTED]> Signed-off-by: Xianghua Xiao <[EMAIL PROTECTED]> Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]> ACK, but patch does not apply to netdev-2.6.git#upstream. Jeff Thanks, Jeff. Are you willing to take the netdev parts as-is, then? Or would you like me to reformat the netdev parts to apply against the netdev-2.6.git#upstream branch? The patch is currently for the Paul Mackerras powerpc.git tree as it stands now. Should we apply it through that path now as you have ACK'ed it? Is it dependent on other stuff in Paul's tree? Normally this should come through netdev-2.6.git#upstream... 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 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
On Thu, 2006-06-08 at 14:34, Jeff Garzik wrote: > Jon Loeliger wrote: > > Signed-off-by: Kriston Carson <[EMAIL PROTECTED]> > > Signed-off-by: Xianghua Xiao <[EMAIL PROTECTED]> > > Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]> > > ACK, but patch does not apply to netdev-2.6.git#upstream. > > Jeff Thanks, Jeff. Are you willing to take the netdev parts as-is, then? Or would you like me to reformat the netdev parts to apply against the netdev-2.6.git#upstream branch? The patch is currently for the Paul Mackerras powerpc.git tree as it stands now. Should we apply it through that path now as you have ACK'ed it? Thanks, jdl - 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.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
Quoting James Morris: | On Thu, 8 Jun 2006, David Miller wrote: | | > > Understood. Please, anyone, disregard or un-apply the previous | > > UDP-Lite patch. A revised patch will be prepared and posted as soon | > > as testing permits. | > | > Nobody is going to integrate your patch anywhere, don't worry. | > You make it clear that once you toss this piece of code over | > the wall, you'll disappear. | | Having dealt with more than enough code thrown over the wall in recent | times, I agree. I understand the points of both of you well enough. But how come this is interpreted as saying I'd "toss this piece of code over the wall"? I can understand getting tired of cowboy coding jobs, but there is a misunderstanding here. Of course do and will I maintain that code and every issue related it. I have been maintaining, improving, testing this code for 9 months. The protocol spec (RFC 3828) was developed at University of Aberdeen, and there is continuing research into UDP-Lite here, i.e. it is not a `dead' project. That is why I held back regarding the IPv6 port: I can ensure that this (IPv4) code is up to standard and to date, but am lacking the required additional time to implement the same for IPv6. I am trying to contact people to help with the port, but for the moment I will take responsibility only for the IPv4 version. And if there is someone `well-known and respected' who is interested in taking this code over, I would only be happy for him/her to do this. But I won't simply `disappear' :-) - 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.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
On Thu, 8 Jun 2006, David Miller wrote: > > Understood. Please, anyone, disregard or un-apply the previous > > UDP-Lite patch. A revised patch will be prepared and posted as soon > > as testing permits. > > Nobody is going to integrate your patch anywhere, don't worry. > You make it clear that once you toss this piece of code over > the wall, you'll disappear. Having dealt with more than enough code thrown over the wall in recent times, I agree. But, if someone well known & trusted wants to claim responsibility for the code once it's upstream, that might be a way forward (I think the Apache project has or had a policy like this). - James -- James Morris <[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: Please pull 'upstream-fixes' branch of wireless-2.6
John W. Linville wrote: This pull is intended for 2.6.17 if at all possible. Thanks, John --- The following changes since commit 672c6108a51bf559d19595d9f8193dfd81f0f752: Linus Torvalds: Merge master.kernel.org:/.../jejb/scsi-rc-fixes-2.6 are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes pulled - 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: Please pull 'upstream' branch of wireless-2.6
John W. Linville wrote: This pull is intended for 2.6.18. Thanks, John --- The following changes since commit f6882a0688ea83db5fc2f3491ac9fcdce0834cc7: John W. Linville: Merge branch 'upstream-fixes' into upstream are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream 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 1/5] skge: use workq for PHY handling
applied 1-5 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 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
Jon Loeliger wrote: Signed-off-by: Kriston Carson <[EMAIL PROTECTED]> Signed-off-by: Xianghua Xiao <[EMAIL PROTECTED]> Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]> ACK, but patch does not apply to netdev-2.6.git#upstream. 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
Using netconsole for debugging suspend/resume
I've been trying to get suspend/resume working well on my new laptop. In general, netconsole has been pretty useful for extracting oopses and other messages, but it is of more limited help in debugging the actual suspend/resume cycle. The problem looks like the e1000 driver won't suspend while netconsole is using it, so I have to rmmod/modprobe netconsole around the actual suspend/resume. This is a big problem during resume because the screen is also blank, so I get no useful clue as to what went wrong when things go wrong. I'm wondering if there's some way to keep netconsole alive to the last possible moment during suspend, and re-woken as soon as possible during resume. It would be nice to have a clean solution, but I'm willing to use a bletcherous hack if that's what it takes. Any ideas? Thanks, J - 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: Firewall question
On Thu, Jun 08, 2006 at 11:57:12AM -0700, Alex Davis wrote: > The scenario: > I have a DSL modem in pass through (bridge) mode. The linux firewall/router > has a single ethernet card. It is running pppoe. This gives two interfaces: > eth0 and ppp0. The firewall is running iptables. There are several machines > behind the firewall. > > Problem: > I've been told that if someone whose public IP address is on the same > network subnet as mine were to get my mac address, (s)he could bypass > the firewall and talk directly to the machines behind it. > > Is this true? Well the DSL modem only transfers whatever data the ISP end sends to it, which in your case is just PPP packets (LCC or LCP I think). No one out on the internet would be able to send ethernet data over the DSL link, so the only way to send data to another machine on your network (that the DSL modem is connected to physically) is if you have other machines on your local network which are also running PPPoE and listening for that traffic. So the worst thing I can see happening is that someone on your local network could potentially take over your PPPoE session, but that's about it. I just can't see anything else that could happen. I used to run exactly the setup you describe before I had to drop the DSL connection (I moved). 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
Re: [Bugme-new] [Bug 6666] New: invalid tcp socket connection to windows stacks
FIN only gets output when the connection is actually closed for sending, and that is controlled by the application not by the kernel. - 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
Firewall question
The scenario: I have a DSL modem in pass through (bridge) mode. The linux firewall/router has a single ethernet card. It is running pppoe. This gives two interfaces: eth0 and ppp0. The firewall is running iptables. There are several machines behind the firewall. Problem: I've been told that if someone whose public IP address is on the same network subnet as mine were to get my mac address, (s)he could bypass the firewall and talk directly to the machines behind it. Is this true? Thanks. I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: Gerrit Renker <[EMAIL PROTECTED]> Date: Thu, 8 Jun 2006 17:03:54 +0100 > Understood. Please, anyone, disregard or un-apply the previous > UDP-Lite patch. A revised patch will be prepared and posted as soon > as testing permits. Nobody is going to integrate your patch anywhere, don't worry. You make it clear that once you toss this piece of code over the wall, you'll disappear. - 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.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: Gerrit Renker <[EMAIL PROTECTED]> Date: Thu, 8 Jun 2006 12:22:54 +0100 > I am sorry, I don't at the moment have the time to port to v6 with the > same degree of rigour. You give the impression that you would just disappear from the face of the planet should your work actually be integrated into the kernel tree. So I can only assume that you are posting this for people to play around with, and not for serious consideration of inclusion into the kernel tree. We're trying to avoid this serious problem we have where a group or individual submits on a piece of code, works just hard enough to get it integrated into the tree, then disappears and does not stick around to support the inevitable ensuing bugs and problem reports. Such behavior is totally irresponsible, yet it happens quite a bit. So if you can't be bothered to cook up IPV6 support, chances are you won't stick around to support your code if it went into the tree either. - 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 1/2] e1000: fix netpoll with NAPI
On Thu, Jun 08, 2006 at 10:23:56AM -0700, Mitch Williams wrote:
> On Wed, 2006-06-07 at 11:54 -0700, John W. Linville wrote:
>
> > Pedantic objection, but I think this would read easier w/o the extra
> > newline before disable_irq.
>
> Heh. I prefer to have a newline between declarations and code. The
Normally I would agree. But in this case, I find the distraction of
the random newline after the #else to be more compelling.
> real problem is the position of the #ifdef -- that's what makes it
> difficult to read. The other solution would be
> {
> struct e1000_adapter *adapter = netdev_priv(netdev);
> #ifdef CONFIG_E1000_NAPI
> int budget = 0;
> #endif
>
> disable_irq(adapter->pdev->irq);
>
> #ifdef CONFIG_E1000_NAPI
> < all that stuff >
> #else
>
> #endif
> }
>
> Which I think is worse to read.
I presume it is the double #ifdef that you find objectionable?
I don't really like it, but at least that idiom is quite common.
Given that the disable_irq appears in both code paths (almost by
necessity), there is a certain appeal to having it outside of the
#ifdef block. That seems more maintainable.
To me, the idiomatic #ifdef placement seems more readable, if for no
other reason than familiarity. I suppose we can agree to disagree.
John
--
John W. Linville
[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: [patch 06/17] neighbour.c, pneigh_get_next() skips published entry
On Mon, 5 Jun 2006, David Miller wrote: > This patch doesn't make any sense, I've been over it a few times. > > The seqfile layer should take care of that user buffering issue transparently as > long as we implement the interface callbacks properly. > > Even if something needs to be fixed in the pneigh dumper, special casing *pos==1 > doesn't look right. Also, if pneigh has this problem, how come the neigh seqfile > iterators don't have the same problem or do they? >From my analysis, the problem is that pneigh_get_next() ends up assigning pn to one entry ahead of what it should be pointing too. This only occurs when the user's read buffer fills up, where pneigh_get_idx() is called, which calls pneigh_get_next() until *pos is not true. I have not checked neigh seqfile iterators, the problem may exist in there as well. My patch solves this issue for us, however a more elegant solution would be most welcome. Could the root of the problem be that *pos is off by one when pneigh_get_idx() is called? Jari - 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
[DOC] update bonding documentation with sysfs
Jeff, Attached patch is pushed on top of #upstream on our git server also containing the resent patches earlier today. Please pull: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream Cheers, Auke --- [DOC] Update bonding documentation with sysfs info Bonding documentation needed an update to include sysfs specific information. This patch adds information on how to change bonding parameters at runtime using the sysfs interface. Signed-off-by: Mitch Williams <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- bonding.txt | 323 ++-- 1 file changed, 229 insertions(+), 94 deletions(-) --- [DOC] Update bonding documentation with sysfs info Bonding documentation needed an update to include sysfs specific information. This patch adds information on how to change bonding parameters at runtime using the sysfs interface. Signed-off-by: Mitch Williams <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- bonding.txt | 323 ++-- 1 file changed, 229 insertions(+), 94 deletions(-) --- diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 8d8b4e5..afac780 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -1,7 +1,7 @@ Linux Ethernet Bonding Driver HOWTO - Latest update: 21 June 2005 + Latest update: 24 April 2006 Initial release : Thomas Davis Corrections, HA extensions : 2000/10/03-15 : @@ -12,6 +12,8 @@ Corrections, HA extensions : 2000/10/03- - Jay Vosburgh Reorganized and updated Feb 2005 by Jay Vosburgh +Added Sysfs information: 2006/04/24 + - Mitch Williams Introduction @@ -38,61 +40,62 @@ Table of Contents 2. Bonding Driver Options 3. Configuring Bonding Devices -3.1 Configuration with sysconfig support -3.1.1 Using DHCP with sysconfig -3.1.2 Configuring Multiple Bonds with sysconfig -3.2 Configuration with initscripts support -3.2.1 Using DHCP with initscripts -3.2.2 Configuring Multiple Bonds with initscripts -3.3 Configuring Bonding Manually +3.1 Configuration with Sysconfig Support +3.1.1 Using DHCP with Sysconfig +3.1.2 Configuring Multiple Bonds with Sysconfig +3.2 Configuration with Initscripts Support +3.2.1 Using DHCP with Initscripts +3.2.2 Configuring Multiple Bonds with Initscripts +3.3 Configuring Bonding Manually with Ifenslave 3.3.1 Configuring Multiple Bonds Manually +3.4 Configuring Bonding Manually via Sysfs -5. Querying Bonding Configuration -5.1 Bonding Configuration -5.2 Network Configuration +4. Querying Bonding Configuration +4.1 Bonding Configuration +4.2 Network Configuration -6. Switch Configuration +5. Switch Configuration -7. 802.1q VLAN Support +6. 802.1q VLAN Support -8. Link Monitoring -8.1 ARP Monitor Operation -8.2 Configuring Multiple ARP Targets -8.3 MII Monitor Operation +7. Link Monitoring +7.1 ARP Monitor Operation +7.2 Configuring Multiple ARP Targets +7.3 MII Monitor Operation -9. Potential Trouble Sources -9.1 Adventures in Routing -9.2 Ethernet Device Renaming -9.3 Painfully Slow Or No Failed Link Detection By Miimon +8. Potential Trouble Sources +8.1 Adventures in Routing +8.2 Ethernet Device Renaming +8.3 Painfully Slow Or No Failed Link Detection By Miimon -10. SNMP agents +9. SNMP agents -11. Promiscuous mode +10. Promiscuous mode -12. Configuring Bonding for High Availability -12.1 High Availability in a Single Switch Topology -12.2 High Availability in a Multiple Switch Topology -12.2.1 HA Bonding Mode Selection for Multiple Switch Topology -12.2.2 HA Link Monitoring for Multiple Switch Topology +11. Configuring Bonding for High Availability +11.1 High Availability in a Single Switch Topology +11.2 High Availability in a Multiple Switch Topology +11.2.1 HA Bonding Mode Selection for Multiple Switch Topology +11.2.2 HA Link Monitoring for Multiple Switch Topology -13. Configuring Bonding for Maximum Throughput -13.1 Maximum Throughput in a Single Switch Topology -13.1.1 MT Bonding Mode Selection for Single Switch Topology -13.1.2 MT Link Monitoring for Single Switch Topology -13.2 Maximum Throughput in a Multiple Switch Topology -13.2.1 MT Bonding Mode Selection for Multiple Switch Topology -13.2.2 MT Link Monitoring for Multiple Switch Topology +12. Configuring Bonding for Maximum Throughput +12.1 Maximum Throughput in a Single Switch Topology +12.1.1 MT Bonding Mode Selection for Single Switch Topology +12.1.2 MT Link Monitoring for Single Switch Topology +12.2 Maximum Throughput in a Multiple Switch Topology +12.2.1 MT Bonding Mode Selection for Multiple Switch Topology +12.2.2 MT Link Monitoring for Multiple Switch Topology -14. Switch Behavior Issues -14.1 Link Establishment and Failover Delays -14.2 Duplicated Incoming Packets +13. Switch Behavior Issues +13.1 Link Establishment and Failover Delays +13.2 Duplicat
Re: Netchannels: netchannel vs. socket. 2:0.
On Thu, Jun 08, 2006 at 09:15:55PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > After some enhancements made for netchannel subsystem I'm pleased to > announce, that netchannel subsystem outperforms existing layered design > both in CPU usage and network speed. > > Well, after such pretentious introduction I want to cool things down. > CPU usage is about 1-2% less for netchannels and network performance is > about 1-2 MB higher and sometimes exceeds 84 MB/sec which, I think, > is maximum for given network setup (e1000 receive, r8169 send, 1500 MTU). > > It is stable and 100% reproductible result. > > Performance graph and patch are attached. Hmm, graph has been attached now. -- Evgeniy Polyakov netchannel_speed.png Description: PNG image
Fw: [Bugme-new] [Bug 6666] New: invalid tcp socket connection to windows stacks
Begin forwarded message: Date: Thu, 8 Jun 2006 05:23:04 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug ] New: invalid tcp socket connection to windows stacks http://bugzilla.kernel.org/show_bug.cgi?id= Summary: invalid tcp socket connection to windows stacks Kernel Version: 2.6.17.rc3-rc6 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.6.16 stable Distribution: none. static kernel compiled directly out of the box. Hardware Environment: dual Xeon 2.66 512kB 1024MB networks e1000 e1000 e100 dual Xeon 3.20 2048kB 2048MB networks e1000 sky2 Software Environment: problem occurs in kernel version 2.6.17rc3, 2.6.17rc6 problem does NOT occur in kernel version 2.6.16 Problem Description: The kernel sends an ack to the windows stack after sync has been replied, but theres no answere to this ack(1) and the kernel sends a FIN packet after connection timeout. Now the windowsstack sends an ack(2) and a FIN and the connections ends. It takes a while for the linux kernel to send the fin, we have shorten this in our tcpdump a bit. connections to other windowssystems i.e. throu a dsl router or other linux based computers are working as expected. It is a very! special bug which you are maybe not able to reproduce. that's why i added the ip adress to test with. As far as i know, the ip belongs to an exchange server in a home network somewhere in switzerland. You can use it freely as it acts as a public mailserver for the domain. Problem occurs independently of "Rx Polling"/"NAPI" and "Packet Split" settings. Steps to reproduce: You need TCPDUMP and NETCAT ( nc ). 1) tcpdump -w /tmp/log -s 2000 host 212.90.215.40 & 2) nc 212.90.215.40 25 If it's buggy you get : 11:24:15.021572 d59.x-mailer.de.59959 > cust.static.212-90-215-40.cybernet.ch.smtp: S 2028538653:2028538653(0) win 5840 (DF) 11:24:15.076329 cust.static.212-90-215-40.cybernet.ch.smtp > d59.x-mailer.de.59959: S 2328498080:2328498080(0) ack 2028538654 win 16384 11:24:15.076352 d59.x-mailer.de.59959 > cust.static.212-90-215-40.cybernet.ch.smtp: . ack 1 win 46 (DF) 11:24:21.926186 d59.x-mailer.de.59959 > cust.static.212-90-215-40.cybernet.ch.smtp: F 1:1(0) ack 1 win 46 (DF) 11:24:21.972106 cust.static.212-90-215-40.cybernet.ch.smtp > d59.x-mailer.de.59959: . ack 2 win 65535 (DF) 11:24:21.973980 cust.static.212-90-215-40.cybernet.ch.smtp > d59.x-mailer.de.59959: F 116:116(0) ack 2 win 65535 (DF) 11:24:21.973999 d59.x-mailer.de.59959 > cust.static.212-90-215-40.cybernet.ch.smtp: R 2028538655:2028538655(0) win 0 (DF) ### you should get kind of this: 13:56:37.203297 d59.x-mailer.de.43286 > cust.static.212-90-215-40.cybernet.ch.smtp: S 1489507409:1489507409(0) win 5840 (DF) 13:56:37.250827 cust.static.212-90-215-40.cybernet.ch.smtp > d59.x-mailer.de.43286: S 783498912:783498912(0) ack 1489507410 win 16384 13:56:37.250888 d59.x-mailer.de.43286 > cust.static.212-90-215-40.cybernet.ch.smtp: . ack 1 win 1460 (DF) 13:56:37.292170 cust.static.212-90-215-40.cybernet.ch.smtp > d59.x-mailer.de.43286: P 1:116(115) ack 1 win 65535 (DF) 13:56:37.292207 d59.x-mailer.de.43286 > cust.static.212-90-215-40.cybernet.ch.smtp: . ack 116 win 1460 (DF) 13:56:39.373383 d59.x-mailer.de.43286 > cust.static.212-90-215-40.cybernet.ch.smtp: F 1:1(0) ack 116 win 1460 (DF) 13:56:39.413075 cust.static.212-90-215-40.cybernet.ch.smtp > d59.x-mailer.de.43286: . ack 2 win 65535 (DF) 13:56:39.414449 cust.static.212-90-215-40.cybernet.ch.smtp > d59.x-mailer.de.43286: F 116:116(0) ack 2 win 65535 (DF) 13:56:39.414464 d59.x-mailer.de.43286 > cust.static.212-90-215-40.cybernet.ch.smtp: . ack 117 win 1460 (DF) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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 1/2] e1000: fix netpoll with NAPI
On Wed, 2006-06-07 at 11:54 -0700, John W. Linville wrote:
> Pedantic objection, but I think this would read easier w/o the extra
> newline before disable_irq.
Heh. I prefer to have a newline between declarations and code. The
real problem is the position of the #ifdef -- that's what makes it
difficult to read. The other solution would be
{
struct e1000_adapter *adapter = netdev_priv(netdev);
#ifdef CONFIG_E1000_NAPI
int budget = 0;
#endif
disable_irq(adapter->pdev->irq);
#ifdef CONFIG_E1000_NAPI
< all that stuff >
#else
#endif
}
Which I think is worse to read.
-Mitch
-
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 1/2] e1000: fix netpoll with NAPI
==> Regarding Re: [PATCH 1/2] e1000: fix netpoll with NAPI; Mitch Williams <[EMAIL PROTECTED]> adds: mitch.a.williams> On Wed, 2006-06-07 at 11:44 -0700, Jeff Moyer wrote: >> That patch locks around the tx clean routine. As such, it doesn't >> prevent the problem. mitch.a.williams> The call to netif_rx_schedule_prep provides locking mitch.a.williams> because it sets the __LINK_STATE_RX_SCHED bit atomically. mitch.a.williams> The spinlock around e1000_clean_tx_irq is to protect it mitch.a.williams> from other calls to the transmit routine, not NAPI. Yes, but what prevents recursion in the poll routine? Consider that the poll routine could end up triggerring a printk (think iptables, here). In that case, you end up calling into netpoll, and if the tx ring is full, we call the poll_controller routine. We've now recursed. The poll lock was originally introduced to prevent recursion, not concurrent access. -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 1/2] e1000: fix netpoll with NAPI
On Wed, 2006-06-07 at 11:44 -0700, Jeff Moyer wrote:
> That patch locks around the tx clean routine. As such, it doesn't
> prevent
> the problem.
The call to netif_rx_schedule_prep provides locking because it sets the
__LINK_STATE_RX_SCHED bit atomically. The spinlock around
e1000_clean_tx_irq is to protect it from other calls to the transmit
routine, not NAPI.
-Mitch
> > + disable_irq(adapter->pdev->irq);
> > + if
> (likely(netif_rx_schedule_prep(&adapter->polling_netdev[0]))) {
> > + if (spin_trylock(&adapter->tx_queue_lock)) {
> > + e1000_clean_tx_irq(adapter,
> &adapter->tx_ring[0]);
> > + spin_unlock(&adapter->tx_queue_lock);
> > + }
> > + adapter->clean_rx(adapter, adapter->rx_ring,
> > + &budget, netdev->weight);
> > + clear_bit(__LINK_STATE_RX_SCHED,
> > + &adapter->polling_netdev[0].state);
>
> -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
Netchannels: netchannel vs. socket. 2:0.
After some enhancements made for netchannel subsystem I'm pleased to
announce, that netchannel subsystem outperforms existing layered design
both in CPU usage and network speed.
Well, after such pretentious introduction I want to cool things down.
CPU usage is about 1-2% less for netchannels and network performance is
about 1-2 MB higher and sometimes exceeds 84 MB/sec which, I think,
is maximum for given network setup (e1000 receive, r8169 send, 1500 MTU).
It is stable and 100% reproductible result.
Performance graph and patch are attached.
Interesting note, that netchannel copy_to_user() setup slightly
outperforms memcpy() setup.
I have some doubts that stock socket TCP code was used in Van Jacobson
netchannel implementation, especially in the final benchmarks, because
of his words about userspace TCP processing, which sometimes pushes to read
RFC 793 and do some coding...
Previous patches, userspace utility, design and implementatin details
can be found at project's homepage [1].
1. Netchannel homepage.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index f48bef1..7a4a758 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -315,3 +315,5 @@ ENTRY(sys_call_table)
.long sys_splice
.long sys_sync_file_range
.long sys_tee /* 315 */
+ .long sys_vmsplice
+ .long sys_netchannel_control
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S
index 5a92fed..fdfb997 100644
--- a/arch/x86_64/ia32/ia32entry.S
+++ b/arch/x86_64/ia32/ia32entry.S
@@ -696,4 +696,5 @@ ia32_sys_call_table:
.quad sys_sync_file_range
.quad sys_tee
.quad compat_sys_vmsplice
+ .quad sys_netchannel_control
ia32_syscall_end:
diff --git a/include/asm-i386/unistd.h b/include/asm-i386/unistd.h
index eb4b152..777cd85 100644
--- a/include/asm-i386/unistd.h
+++ b/include/asm-i386/unistd.h
@@ -322,8 +322,9 @@
#define __NR_sync_file_range 314
#define __NR_tee 315
#define __NR_vmsplice 316
+#define __NR_netchannel_control317
-#define NR_syscalls 317
+#define NR_syscalls 318
/*
* user-visible error numbers are in the range -1 - -128: see
diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h
index feb77cb..08c230e 100644
--- a/include/asm-x86_64/unistd.h
+++ b/include/asm-x86_64/unistd.h
@@ -617,8 +617,10 @@ __SYSCALL(__NR_tee, sys_tee)
__SYSCALL(__NR_sync_file_range, sys_sync_file_range)
#define __NR_vmsplice 278
__SYSCALL(__NR_vmsplice, sys_vmsplice)
+#define __NR_netchannel_control279
+__SYSCALL(__NR_vmsplice, sys_netchannel_control)
-#define __NR_syscall_max __NR_vmsplice
+#define __NR_syscall_max __NR_netchannel_control
#ifndef __NO_STUBS
diff --git a/include/linux/netchannel.h b/include/linux/netchannel.h
new file mode 100644
index 000..ed426e6
--- /dev/null
+++ b/include/linux/netchannel.h
@@ -0,0 +1,118 @@
+/*
+ * netchannel.h
+ *
+ * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * 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; 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __NETCHANNEL_H
+#define __NETCHANNEL_H
+
+#include
+
+enum netchannel_commands {
+ NETCHANNEL_CREATE = 0,
+ NETCHANNEL_REMOVE,
+ NETCHANNEL_BIND,
+ NETCHANNEL_READ,
+ NETCHANNEL_DUMP,
+};
+
+enum netchannel_type {
+ NETCHANNEL_COPY_USER = 0,
+ NETCHANNEL_MMAP,
+ NETCHANEL_VM_HACK,
+};
+
+struct unetchannel
+{
+ __u32 src, dst; /* source/destination
hashes */
+ __u16 sport, dport; /* source/destination
ports */
+ __u8proto; /* IP protocol number */
+ __u8type; /* Netchannel type */
+ __u8memory_limit_order; /* Memor limit order */
+ __u8init_stat_work; /* Start statistic
dumping */
+};
+
+struct unetchannel_control
+{
+ struct unetchannel unc;
+ __u32 cmd;
+ __u32 len;
Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
On Thu, Jun 08, 2006 at 10:43:04AM -0400, Jeff Garzik wrote:
...
> Perhaps cp_close() in 8139cp.c could be an example of a good ordering?
> It stops the chip, syncs irqs, frees irq, then frees [thus unmapping]
> the rings.
Here is a new patch that moves free_irq() into tulip_down().
The resulting code is structured the same as cp_close().
While I believe the code is correct, I'm not real happy
that tulip_up() and tulip_down() don't both deal with IRQs.
(ie not symetrical). Oh well, I can submit another patch
for that if Val doesn't want to wrangle that herself.
This is compile tested only.
I'll drop it on ia64/parisc servers later and retest.
thanks,
grant
Index: drivers/net/tulip/tulip_core.c
===
RCS file: /var/cvs/linux-2.6/drivers/net/tulip/tulip_core.c,v
retrieving revision 1.35
diff -u -p -r1.35 tulip_core.c
--- drivers/net/tulip/tulip_core.c 23 Apr 2006 15:18:28 - 1.35
+++ drivers/net/tulip/tulip_core.c 8 Jun 2006 16:25:43 -
@@ -18,11 +18,11 @@
#define DRV_NAME "tulip"
#ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION"1.1.13-NAPI" /* Keep at least for test */
+#define DRV_VERSION"1.1.14-NAPI" /* Keep at least for test */
#else
-#define DRV_VERSION"1.1.13"
+#define DRV_VERSION"1.1.14"
#endif
-#define DRV_RELDATE"December 15, 2004"
+#define DRV_RELDATE"May 6, 2006"
#include
@@ -743,6 +745,11 @@ static void tulip_down (struct net_devic
/* Stop the Tx and Rx processes. */
tulip_stop_rxtx(tp);
+ spin_unlock_irqrestore (&tp->lock, flags);
+
+ synchronize_irq(dev->irq);
+ free_irq (dev->irq, dev);
+
/* prepare receive buffers */
tulip_refill_rx(dev);
@@ -752,7 +759,6 @@ static void tulip_down (struct net_devic
if (ioread32 (ioaddr + CSR6) != 0x)
tp->stats.rx_missed_errors += ioread32 (ioaddr + CSR8) & 0x;
- spin_unlock_irqrestore (&tp->lock, flags);
init_timer(&tp->timer);
tp->timer.data = (unsigned long)dev;
@@ -774,14 +780,13 @@ static int tulip_close (struct net_devic
int i;
netif_stop_queue (dev);
tulip_down (dev);
if (tulip_debug > 1)
printk (KERN_DEBUG "%s: Shutting down ethercard, status was
%2.2x.\n",
dev->name, ioread32 (ioaddr + CSR5));
- free_irq (dev->irq, dev);
/* Free all the skbuffs in the Rx queue. */
for (i = 0; i < RX_RING_SIZE; i++) {
@@ -1750,7 +1757,6 @@ static int tulip_suspend (struct pci_dev
tulip_down(dev);
netif_device_detach(dev);
- free_irq(dev->irq, dev);
pci_save_state(pdev);
pci_disable_device(pdev);
-
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 RESEND] e100/e1000: fixes and pci error recovery
Jeff, This is a resend of several earlier sent (and Acked) patches for e100 and e1000. They are available on our git server and contain: in branch upstream-fixes: [1] e1000: fix irq sharing when running ethtool test [2] e1000: remove risky prefetch on next_skb->data against netdev-2.6#upstream-fixes e82b0f2cc21be905e504573483fa9542b15df96f [ please note that patch 2 will need manual merging into #upstream ] in branch upstream: [3] e100: add PCI Error Recovery [4] e1000: add PCI Error Recovery against netdev-2.6#upstream 983f27d37d4fc72c252835cb2ee3103b360735a6 Please pull: into #upstream-fixes: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes into #upstream: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream Cheers, Auke Refs [1] http://marc.theaimsgroup.com/?l=linux-netdev&m=114928689932374&w=2 [2] http://marc.theaimsgroup.com/?l=linux-netdev&m=114954878609885&w=2 [3] http://marc.theaimsgroup.com/?l=linux-netdev&m=114436228823926&w=2 [4] http://marc.theaimsgroup.com/?l=linux-pci&m=114325705604534&w=2 - 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] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
This patch makes the gianfar ethtool code use phy_ethtool_get_link()
instead of ethtool_op_get_link().
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
--- a/drivers/net/gianfar_ethtool.c 2006-06-05 11:27:19.0 -0500
+++ b/drivers/net/gianfar_ethtool.c 2006-06-04 19:31:01.0 -0500
@@ -228,6 +228,18 @@
buf[i] = gfar_read(&theregs[i]);
}
+static u32 gfar_get_link(struct net_device *dev)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+
+ if (NULL == phydev)
+ return 0;
+
+ return phy_ethtool_get_link(phydev);
+}
+
+
/* Convert microseconds to ethernet clock ticks, which changes
* depending on what speed the controller is running at */
static unsigned int gfar_usecs2ticks(struct gfar_private *priv, unsigned int
usecs)
@@ -574,7 +578,7 @@
.get_drvinfo = gfar_gdrvinfo,
.get_regs_len = gfar_reglen,
.get_regs = gfar_get_regs,
- .get_link = ethtool_op_get_link,
+ .get_link = gfar_get_link,
.get_coalesce = gfar_gcoalesce,
.set_coalesce = gfar_scoalesce,
.get_ringparam = gfar_gringparam,
-
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 5/5] ehea: makefile and Kconfig
On Thu, 08 Jun 2006 11:56:05 +0200 Jan-Bernd Themann wrote: > Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> > > > drivers/net/ehea/Kconfig |6 ++ > drivers/net/ehea/Makefile |7 +++ > 2 files changed, 13 insertions(+) > > > > --- linux-2.6.16-rc5-orig/drivers/net/ehea/Makefile 1969-12-31 > 16:00:00.0 -0800 > +++ kernel/drivers/net/ehea/Makefile 2006-06-08 01:58:28.839212488 -0700 > @@ -0,0 +1,7 @@ > +# > +# Makefile for the eHEA ethernet device driver for IBM eServer System p > +# > + > +ehea_mod-objs = ehea_main.o ehea_phyp.o ehea_qmr.o ehea_ethtool.o ehea_phyp.o > +obj-$(CONFIG_EHEA) += ehea_mod.o > + > --- linux-2.6.16-rc5-orig/drivers/net/ehea/Kconfig1969-12-31 > 16:00:00.0 -0800 > +++ kernel/drivers/net/ehea/Kconfig 2006-06-08 01:58:28.842212032 -0700 > @@ -0,0 +1,6 @@ > +config EHEA > + tristate "eHEA Ethernet support" > + depends on IBMEBUS > + ---help--- > + This driver supports the IBM pSeries ethernet adapter > + Hi, Will you be modifying drivers/net/Makefile and drivers/net/Kconfig to use these files? And "help" text is normally indented (convention is 2 spaces) since (from Documentation/kbuild/kconfig-language.txt): The end of the help text is determined by the indentation level, this means it ends at the first line which has a smaller indentation than the first line of the help text. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New tulip maintainer...
On Thu, Jun 08, 2006 at 11:41:28AM -0400, Jeff Garzik wrote: > Now that we have a new tulip maintainer, perhaps a resend of the > long-outstanding tulip phy patches could be resent? All the tulip patches I have are archived here: ftp://ftp.parisc-linux.org/patches/ Anything else tulip I've been involved with is available via CVS from cvs.parisc-linux.org/linux-2.6/ Thibaut Varene has also committed his changes to that CVS. thanks, grant - 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.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
Quoting Alan Cox: | Ar Iau, 2006-06-08 am 11:50 +0100, ysgrifennodd Gerrit Renker: | > + UDP-Lite introduces a new socket type, the SOCK_LDGRAM (note the L) for | > + lightweight, connection-less services. These are the socket options: | | This is not the intended use of the socket API when distinguishing | between services. The socket() call has a protocol field that is usually | unused and it exists precisely to disambiguate multiple protocols with | the same generic behaviour but different properties. | | s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE); | | is probably the right way to do this, keeping 0 "default" as before | meaning IPPROTO_UDP Understood. Please, anyone, disregard or un-apply the previous UDP-Lite patch. A revised patch will be prepared and posted as soon as testing permits. - 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] s2io: netpoll support
This adds netpoll support for things like netconsole/kgdboe to the s2io
10GbE driver.
This duplicates some code from s2io_poll() as I wanted to be
least-invasive, someone from Neterion might have other thoughts?
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 79208f4..c2c5f46 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -2575,6 +2575,53 @@ no_rx:
#endif
/**
+ * s2io_netpoll - Rx interrupt service handler for netpoll support
+ * @dev : pointer to the device structure.
+ * Description:
+ * Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void s2io_netpoll(struct net_device *dev)
+{
+ nic_t *nic = dev->priv;
+ mac_info_t *mac_control;
+ struct config_param *config;
+ XENA_dev_config_t __iomem *bar0 = nic->bar0;
+ u64 val64;
+ int i;
+
+ atomic_inc(&nic->isr_cnt);
+
+ /* Disable all interrupts */
+ en_dis_able_nic_intrs(nic, ENA_ALL_INTRS, DISABLE_INTRS);
+
+ mac_control = &nic->mac_control;
+ config = &nic->config;
+
+ val64 = readq(&bar0->rx_traffic_int);
+ writeq(val64, &bar0->rx_traffic_int);
+
+ for (i = 0; i < config->rx_ring_num; i++)
+ rx_intr_handler(&mac_control->rings[i]);
+
+ for (i = 0; i < config->rx_ring_num; i++) {
+ if (fill_rx_buffers(nic, i) == -ENOMEM) {
+ DBG_PRINT(ERR_DBG, "%s:Out of memory", dev->name);
+ DBG_PRINT(ERR_DBG, " in Rx Netpoll!!\n");
+ break;
+ }
+ }
+ /* Re-enable all interrupts */
+ en_dis_able_nic_intrs(nic, ENA_ALL_INTRS, ENABLE_INTRS);
+ atomic_dec(&nic->isr_cnt);
+ return;
+}
+#endif
+
+/**
* rx_intr_handler - Rx interrupt handler
* @nic: device private variable.
* Description:
@@ -6210,6 +6257,10 @@ Defaulting to INTA\n");
dev->weight = 32;
#endif
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ dev->poll_controller = s2io_netpoll;
+#endif
+
dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM;
if (sp->high_dma_flag == TRUE)
dev->features |= NETIF_F_HIGHDMA;
Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
On Thu, Jun 08, 2006 at 11:38:52AM -0400, Jeff Garzik wrote: > >Can we call free_irq() from tulip_down()? > > I'm sure you can answer that yourself. If it doesn't cause problems > elsewhere, yes. Otherwise, no. :) Yeah, well, I was hoping you would "Just Know" (tm). :) Research takes time. > Did you read the example I cited, cp_close() ? Yes - after I sent the mail. It looks good to me too. thanks, grant - 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
New tulip maintainer...
Now that we have a new tulip maintainer, perhaps a resend of the long-outstanding tulip phy patches could be resent? With an active tulip maintainer, the "too-long mdelay" would hopefully only exist temporarily -- with the proper fix being to move that code into a kernel thread (workqueue?) long term. 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] pcnet32 driver NAPI support
On Wed, Jun 07, 2006 at 03:32:45PM -0700, Don Fry wrote: > One other problem I ran into. I applied the patch but it will not > compile because rl_active is never defined. I have worked around it but Doh! I thought I cleaned up all my "weird code" from my own version. Because of the platform I work with having 4 pcnet32 ports, and a slow poke 266MHz geode, we can't handle full traffic load, so to keep the system responsive to pause processing receives when we pass a certain number of packets per second. rl_active is part of that. I meant to remove all of it, apparently I didn't read every line of my patch carefully enough. :( Well at least this ought to clean up my work a bit. 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
Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
Grant Grundler wrote: Ok...I think I understand what you are driving at here. The case is when CPU vector is enabled and shared but one device _without_ an interrupt handler is registered is still yanking on the interrupt line. It will cause linux to disable the line since the IRQ isn't being handled. Correct. Can we call free_irq() from tulip_down()? I'm sure you can answer that yourself. If it doesn't cause problems elsewhere, yes. Otherwise, no. :) Did you read the example I cited, cp_close() ? 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 2.6.17-rc5 tulip free_irq() called too late
On Thu, Jun 08, 2006 at 11:32:39AM -0400, Jeff Garzik wrote: > >The chip IRQ gets turned off in tulip_down(). > >It won't be screaming for very long. > > Then you admit that you add a race. Yes - I realized that after I hit :( ... > >In the shared IRQ case, I expect free_irq() to unlink this instance > >of the tulip interrupt handler from the CPU vector list. If that > > Irrelevant -- that doesn't stop the tulip hardware from raising the irq, > nor stop the system from attempting to deliver it [in all cases]. In > the shared interrupt case, that means that another driver's irq handler > will be called for an event tulip hardware raised. *nod* thanks, grant - 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.17-rc5 tulip free_irq() called too late
On Thu, Jun 08, 2006 at 09:22:21AM -0600, Grant Grundler wrote: > > Perhaps cp_close() in 8139cp.c could be an example of a good ordering? > > It stops the chip, syncs irqs, frees irq, then frees [thus unmapping] > > the rings. > > Sorry, I don't see how it matters if we disable chip IRQ first > or unlink from CPU IRQ list first. Does it? Ok...I think I understand what you are driving at here. The case is when CPU vector is enabled and shared but one device _without_ an interrupt handler is registered is still yanking on the interrupt line. It will cause linux to disable the line since the IRQ isn't being handled. This is only possible in the shared IRQ case. Can we call free_irq() from tulip_down()? I have the feeling this is going to cause alot more code movement. thanks, grant - 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] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
Nathaniel Case wrote:
On Thu, 2006-06-08 at 10:58 -0400, Jeff Garzik wrote:
+static u32 gfar_get_link(struct net_device *dev)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+
+ if (NULL == phydev)
+ return -ENODEV;
NAK, return code obviously wrong
Thanks. I think we can just return 0 for that case. Updated patch
follows.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
Sigh. See rule #6: http://linux.yyz.us/patch-format.html
You excised the patch description, which means your patch can no longer
be applied correctly by scripts.
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 2.6.17-rc5 tulip free_irq() called too late
Grant Grundler wrote: On Thu, Jun 08, 2006 at 10:43:04AM -0400, Jeff Garzik wrote: (CC'ing our newly minted tulip maintainer, Val) Excellent! Has MAINTAINERS file been updated? :) It should be updated, yes. Calling free_irq() while the chip is still active is just a bad idea, because the chip could raise an interrupt, creating a screaming-interrupts situation. Consider especially the case of shared interrupts here, as a concrete example of how this won't work. The chip IRQ gets turned off in tulip_down(). It won't be screaming for very long. Then you admit that you add a race. No one will hear it screaming and no one will care. False. Easy counter-example already provided: Shared interrupts. For some IRQ architectures, even without shared interrupts, this could easily trigger the kernel's screaming-irq detection code. Secondly, if tulip has a problem with shared IRQs, it's already there. We would have called free_irq() anyway - just a bit later. Yes... AFTER we told the chip to stop DMA'ing, and delivering interrupts. I'm frankly surprised you don't see the obvious, natural ordering. You stop the hardware from wanting to deliver interrupts, before unregistering the irq handler. IOW you turn out the lights, before leaving the room. In the shared IRQ case, I expect free_irq() to unlink this instance of the tulip interrupt handler from the CPU vector list. If that Irrelevant -- that doesn't stop the tulip hardware from raising the irq, nor stop the system from attempting to deliver it [in all cases]. In the shared interrupt case, that means that another driver's irq handler will be called for an event tulip hardware raised. 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 2.6.17-rc5 tulip free_irq() called too late
On Thu, Jun 08, 2006 at 10:43:04AM -0400, Jeff Garzik wrote: > (CC'ing our newly minted tulip maintainer, Val) Excellent! Has MAINTAINERS file been updated? :) ... > NAK. This is a band-aid, and one that creates new problems even as it > attempts to solve problems. You failed to demonstrate that below. Any other objections? > Calling free_irq() while the chip is still active is just a bad idea, > because the chip could raise an interrupt, creating a > screaming-interrupts situation. Consider especially the case of shared > interrupts here, as a concrete example of how this won't work. The chip IRQ gets turned off in tulip_down(). It won't be screaming for very long. No one will hear it screaming and no one will care. The decision to bring down the NIC was already made. Secondly, if tulip has a problem with shared IRQs, it's already there. We would have called free_irq() anyway - just a bit later. In the shared IRQ case, I expect free_irq() to unlink this instance of the tulip interrupt handler from the CPU vector list. If that doesn't happen, I could consider that an arch specific bug, not a tulip driver bug. > Perhaps cp_close() in 8139cp.c could be an example of a good ordering? > It stops the chip, syncs irqs, frees irq, then frees [thus unmapping] > the rings. Sorry, I don't see how it matters if we disable chip IRQ first or unlink from CPU IRQ list first. Does it? thanks, grant - 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] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
On Thu, 2006-06-08 at 10:58 -0400, Jeff Garzik wrote:
> > +static u32 gfar_get_link(struct net_device *dev)
> > +{
> > + struct gfar_private *priv = netdev_priv(dev);
> > + struct phy_device *phydev = priv->phydev;
> > +
> > + if (NULL == phydev)
> > + return -ENODEV;
>
> NAK, return code obviously wrong
Thanks. I think we can just return 0 for that case. Updated patch
follows.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
--- a/drivers/net/gianfar_ethtool.c 2006-06-05 11:27:19.0 -0500
+++ b/drivers/net/gianfar_ethtool.c 2006-06-04 19:31:01.0 -0500
@@ -228,6 +228,18 @@
buf[i] = gfar_read(&theregs[i]);
}
+static u32 gfar_get_link(struct net_device *dev)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+
+ if (NULL == phydev)
+ return 0;
+
+ return phy_ethtool_get_link(phydev);
+}
+
+
/* Convert microseconds to ethernet clock ticks, which changes
* depending on what speed the controller is running at */
static unsigned int gfar_usecs2ticks(struct gfar_private *priv, unsigned int
usecs)
@@ -574,7 +578,7 @@
.get_drvinfo = gfar_gdrvinfo,
.get_regs_len = gfar_reglen,
.get_regs = gfar_get_regs,
- .get_link = ethtool_op_get_link,
+ .get_link = gfar_get_link,
.get_coalesce = gfar_gcoalesce,
.set_coalesce = gfar_scoalesce,
.get_ringparam = gfar_gringparam,
-
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 1/9] NetXen 1G/10G ethernet driver patch with corrections
diff -u linux-2.6.16.20/drivers/net/netxen/netxen_nic_ethtool.c
linux-2.6.16.20/drivers/net/netxen/netxen_nic_ethtool.c
--- linux-2.6.16.20/drivers/net/netxen/netxen_nic_ethtool.c 2006-06-06
06:58:11.0 -0700
+++ linux-2.6.16.20/drivers/net/netxen/netxen_nic_ethtool.c 2006-06-08
06:52:09.0 -0700
@@ -240,6 +240,95 @@
return NETXEN_NIC_REGS_LEN;
}
+struct netxen_niu_regs {
+ netxen_crbword_treg[NETXEN_NIC_REGS_COUNT];
+};
+
+static struct netxen_niu_regs niu_registers[] = {
+ {
+/* GB Mode */
+{
+ NETXEN_NIU_GB_SERDES_RESET,
+ NETXEN_NIU_GB0_MII_MODE,
+ NETXEN_NIU_GB1_MII_MODE,
+ NETXEN_NIU_GB2_MII_MODE,
+ NETXEN_NIU_GB3_MII_MODE,
+ NETXEN_NIU_GB0_GMII_MODE,
+ NETXEN_NIU_GB1_GMII_MODE,
+ NETXEN_NIU_GB2_GMII_MODE,
+ NETXEN_NIU_GB3_GMII_MODE,
+ NETXEN_NIU_REMOTE_LOOPBACK,
+ NETXEN_NIU_GB0_HALF_DUPLEX,
+ NETXEN_NIU_GB1_HALF_DUPLEX,
+ NETXEN_NIU_RESET_SYS_FIFOS,
+ NETXEN_NIU_GB_CRC_DROP,
+ NETXEN_NIU_GB_DROP_WRONGADDR,
+ NETXEN_NIU_TEST_MUX_CTL,
+
+ NETXEN_NIU_GB_MAC_CONFIG_0(0),
+ NETXEN_NIU_GB_MAC_CONFIG_1(0),
+ NETXEN_NIU_GB_HALF_DUPLEX_CTRL(0),
+ NETXEN_NIU_GB_MAX_FRAME_SIZE(0),
+ NETXEN_NIU_GB_TEST_REG(0),
+ NETXEN_NIU_GB_MII_MGMT_CONFIG(0),
+ NETXEN_NIU_GB_MII_MGMT_COMMAND(0),
+ NETXEN_NIU_GB_MII_MGMT_ADDR(0),
+ NETXEN_NIU_GB_MII_MGMT_CTRL(0),
+ NETXEN_NIU_GB_MII_MGMT_STATUS(0),
+ NETXEN_NIU_GB_MII_MGMT_INDICATE(0),
+ NETXEN_NIU_GB_INTERFACE_CTRL(0),
+ NETXEN_NIU_GB_INTERFACE_STATUS(0),
+ NETXEN_NIU_GB_STATION_ADDR_0(0),
+ NETXEN_NIU_GB_STATION_ADDR_1(0),
+ -1,
+}
+ },
+ {
+/* XG Mode */
+{
+ NETXEN_NIU_XG_SINGLE_TERM,
+ NETXEN_NIU_XG_DRIVE_HI,
+ NETXEN_NIU_XG_DRIVE_LO,
+ NETXEN_NIU_XG_DTX,
+ NETXEN_NIU_XG_DEQ,
+ NETXEN_NIU_XG_WORD_ALIGN,
+ NETXEN_NIU_XG_RESET,
+ NETXEN_NIU_XG_POWER_DOWN,
+ NETXEN_NIU_XG_RESET_PLL,
+ NETXEN_NIU_XG_SERDES_LOOPBACK,
+ NETXEN_NIU_XG_DO_BYTE_ALIGN,
+ NETXEN_NIU_XG_TX_ENABLE,
+ NETXEN_NIU_XG_RX_ENABLE,
+ NETXEN_NIU_XG_STATUS,
+ NETXEN_NIU_XG_PAUSE_THRESHOLD,
+ NETXEN_NIU_XGE_CONFIG_0,
+ NETXEN_NIU_XGE_CONFIG_1,
+ NETXEN_NIU_XGE_IPG,
+ NETXEN_NIU_XGE_STATION_ADDR_0_HI,
+ NETXEN_NIU_XGE_STATION_ADDR_0_1,
+ NETXEN_NIU_XGE_STATION_ADDR_1_LO,
+ NETXEN_NIU_XGE_STATUS,
+ NETXEN_NIU_XGE_MAX_FRAME_SIZE,
+ NETXEN_NIU_XGE_PAUSE_FRAME_VALUE,
+ NETXEN_NIU_XGE_TX_BYTE_CNT,
+ NETXEN_NIU_XGE_TX_FRAME_CNT,
+ NETXEN_NIU_XGE_RX_BYTE_CNT,
+ NETXEN_NIU_XGE_RX_FRAME_CNT,
+ NETXEN_NIU_XGE_AGGR_ERROR_CNT,
+ NETXEN_NIU_XGE_MULTICAST_FRAME_CNT,
+ NETXEN_NIU_XGE_UNICAST_FRAME_CNT,
+ NETXEN_NIU_XGE_CRC_ERROR_CNT,
+ NETXEN_NIU_XGE_OVERSIZE_FRAME_ERR,
+ NETXEN_NIU_XGE_UNDERSIZE_FRAME_ERR,
+ NETXEN_NIU_XGE_LOCAL_ERROR_CNT,
+ NETXEN_NIU_XGE_REMOTE_ERROR_CNT,
+ NETXEN_NIU_XGE_CONTROL_CHAR_CNT,
+ NETXEN_NIU_XGE_PAUSE_FRAME_CNT,
+ -1,
+}
+ }
+};
+
static void
netxen_nic_get_regs(struct net_device *dev, struct ethtool_regs *regs,
void *p)
{
@@ -248,6 +337,7 @@
netxen_crbword_t mode, *regs_buff = p;
unsigned long flags;
void *addr;
+ int i, window;
memset(p, 0, NETXEN_NIC_REGS_LEN);
regs->version = (1 << 24) | (adapter->ahw.revision_id << 16) |
@@ -260,176 +350,18 @@
/* Common registers to all the modes */
NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_STRAP_VALUE_SAVE_HIGHER,
®s_buff[2]);
- switch (mode) {
- case 4:{/* XGB Mode */
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_SINGLE_TERM,
- ®s_buff[3]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DRIVE_HI,
- ®s_buff[4]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DRIVE_LO,
- ®s_buff[5]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DTX,
- ®s_buff[6]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DEQ,
- ®s_buff[7]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_WORD_ALIGN,
- ®s_buff[8]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_RESET,
- ®s_buff[9]);
- NETXEN_NIC_
Re: [PATCH 2/2] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
Nathaniel Case wrote:
This patch makes the gianfar ethtool code use phy_ethtool_get_link() instead of
ethtool_op_get_link().
Patch depends on previous one (1/2).
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
--- a/drivers/net/gianfar_ethtool.c 2006-06-05 11:27:19.0 -0500
+++ b/drivers/net/gianfar_ethtool.c 2006-06-04 19:31:01.0 -0500
@@ -228,6 +228,18 @@
buf[i] = gfar_read(&theregs[i]);
}
+static u32 gfar_get_link(struct net_device *dev)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+
+ if (NULL == phydev)
+ return -ENODEV;
NAK, return code obviously wrong
-
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 to correct dump of WPA IE
In net/ieee80211/softmac/ieee80211softmac_wx.c, there is a bug that prints extended sign information
whenever the byte value exceeds 0x7f. The following patch changes the printk to use a u8 cast to
limit the output to 2 digits. This bug was first noticed by Dan Williams <[EMAIL PROTECTED]>. This
patch applies to the current master branch of the Linville tree.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c
b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 27edb2b..55c5c26 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -388,7 +388,7 @@ ieee80211softmac_wx_set_genie(struct net
memcpy(mac->wpa.IE, extra, wrqu->data.length);
dprintk(KERN_INFO PFX "generic IE set to ");
for (i=0;idata.length;i++)
- dprintk("%.2x", mac->wpa.IE[i]);
+ dprintk("%.2x", (u8)mac->wpa.IE[i]);
dprintk("\n");
mac->wpa.IElen = wrqu->data.length;
} 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: EHEA: Is there a size limit below 80K for patches?
Christoph Raisch wrote: well, now I'm confused... 2 People, two opinions Here's a URL for a complete tarball, "sharing" the download location with our other driver. http://prdownloads.sourceforge.net/ibmehcad/ehea_EHEA_0002.tgz We're waiting for a sourceforge project now since 9 days to put out a tgz, and it looks like many other people get upset right now by their response time. So what's the "right"/preferred way to proceed? Patches and new drivers should always go to the mailing list.. except for the case where they are too big to be posted to the mailing list. For that special case, a URL to a patch should be posted. 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 2.6.17-rc5 tulip free_irq() called too late
(CC'ing our newly minted tulip maintainer, Val) Grant Grundler wrote: Jeff, SLES10 testing exposed an MCA that was confirmed to be a DMA IO TLB miss. This means tulip device was attempting to DMA to memory that was already unmapped. The test was crashing in the "ifconfig down" step when a 4-port tulip card was under this work load: while : do ifconfig eth24 up ifconfig eth25 up ifconfig eth26 up ifconfig eth27 up # Pound both interfaces with ethtool for i in `seq 1000` do ethtool eth24 &>/dev/null ethtool eth25 &>/dev/null ethtool eth26 &>/dev/null ethtool eth27 &>/dev/null done # Bring interfaces down echo ifconfig $nic1 down ifconfig eth24 down ifconfig eth25 down ifconfig eth26 down ifconfig eth27 down sleep 5 done [ And yes, I know tulip doesn't support ethtool. Don't ask. It's still a sore point at the moment. Just consider it a delay loop or use "sleep 5" instead. ] The real "network load" comes from another box(en) running 4 instances of "ping -f -s 1450 192.168.x.y" where "x.y" is the subnet/IP of eth24-27. The parisc and ia64 machines will crash in minutes. I believe the problem is a race condition between an interrupt coming in and the tulip_down() code path. Moving the "free_irq()" to before tulip_down() call fixes the problem. I've been able to run the above test for several hours now. NAK. This is a band-aid, and one that creates new problems even as it attempts to solve problems. Calling free_irq() while the chip is still active is just a bad idea, because the chip could raise an interrupt, creating a screaming-interrupts situation. Consider especially the case of shared interrupts here, as a concrete example of how this won't work. Perhaps cp_close() in 8139cp.c could be an example of a good ordering? It stops the chip, syncs irqs, frees irq, then frees [thus unmapping] the rings. 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 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
In article <[EMAIL PROTECTED]> (at Thu, 08 Jun 2006 15:47:52 +0100), Alan Cox <[EMAIL PROTECTED]> says: > Ar Iau, 2006-06-08 am 11:50 +0100, ysgrifennodd Gerrit Renker: > > + UDP-Lite introduces a new socket type, the SOCK_LDGRAM (note the L) for > > + lightweight, connection-less services. These are the socket options: : > s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE); > > is probably the right way to do this, keeping 0 "default" as before > meaning IPPROTO_UDP I do think so, too. --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: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
Ar Iau, 2006-06-08 am 11:50 +0100, ysgrifennodd Gerrit Renker: > + UDP-Lite introduces a new socket type, the SOCK_LDGRAM (note the L) for > + lightweight, connection-less services. These are the socket options: This is not the intended use of the socket API when distinguishing between services. The socket() call has a protocol field that is usually unused and it exists precisely to disambiguate multiple protocols with the same generic behaviour but different properties. s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE); is probably the right way to do this, keeping 0 "default" as before meaning IPPROTO_UDP - 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] myri10ge update
The following patch updates the myri10ge to 1.0.0, with the following changes:
* Switch to dma_alloc_coherent API.
* Avoid PCI burst when writing the firmware on chipset with unaligned
completions.
* Use ethtool_op_set_tx_hw_csum instead of ethtool_op_set_tx_csum.
* Include linux/dma-mapping.h to bring DMA_32/64BIT_MASK on all architectures
(was missing at least on alpha).
* Some typo and warning fixes.
Please apply.
Note that Andrew's myri10ge-alpha-build-fix.patch would conflict,
but it does not seem to have been merged in netdev-2.6 anyway.
Thanks.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
Signed-off-by: Andrew J. Gallatin <[EMAIL PROTECTED]>
drivers/net/myri10ge/myri10ge.c | 57 +++---
1 file changed, 37 insertions(+), 20 deletions(-)
diff -urNp linux-mm.old/drivers/net/myri10ge/myri10ge.c
linux-mm/drivers/net/myri10ge/myri10ge.c
--- linux-mm.old/drivers/net/myri10ge/myri10ge.c2006-06-04
08:51:00.0 -0400
+++ linux-mm/drivers/net/myri10ge/myri10ge.c2006-06-07 11:28:20.0
-0400
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -62,7 +63,6 @@
#include
#include
#include
-#include
#include
#ifdef CONFIG_MTRR
#include
@@ -71,7 +71,7 @@
#include "myri10ge_mcp.h"
#include "myri10ge_mcp_gen_header.h"
-#define MYRI10GE_VERSION_STR "0.9.0"
+#define MYRI10GE_VERSION_STR "1.0.0"
MODULE_DESCRIPTION("Myricom 10G driver (10GbE)");
MODULE_AUTHOR("Maintainer: [EMAIL PROTECTED]");
@@ -480,7 +478,19 @@ static int myri10ge_load_hotplug_firmwar
goto abort_with_fw;
crc = crc32(~0, fw->data, fw->size);
- memcpy_toio(mgp->sram + MYRI10GE_FW_OFFSET, fw->data, fw->size);
+ if (mgp->tx.boundary == 2048) {
+ /* Avoid PCI burst on chipset with unaligned completions. */
+ int i;
+ __iomem u32 *ptr = (__iomem u32 *) (mgp->sram +
+ MYRI10GE_FW_OFFSET);
+ for (i = 0; i < fw->size / 4; i++) {
+ __raw_writel(((u32 *) fw->data)[i], ptr + i);
+ wmb();
+ }
+ } else {
+ myri10ge_pio_copy(mgp->sram + MYRI10GE_FW_OFFSET, fw->data,
+ fw->size);
+ }
/* corruption checking is good for parity recovery and buggy chipset */
memcpy_fromio(fw->data, mgp->sram + MYRI10GE_FW_OFFSET, fw->size);
reread_crc = crc32(~0, fw->data, fw->size);
@@ -536,6 +548,7 @@ static int myri10ge_load_firmware(struct
u32 dma_low, dma_high, size;
int status, i;
+ size = 0;
status = myri10ge_load_hotplug_firmware(mgp, &size);
if (status) {
dev_warn(&mgp->pdev->dev, "hotplug firmware loading failed\n");
@@ -778,7 +791,7 @@ myri10ge_submit_8rx(struct mcp_kreq_ethe
}
/*
- * Set of routunes to get a new receive buffer. Any buffer which
+ * Set of routines to get a new receive buffer. Any buffer which
* crosses a 4KB boundary must start on a 4KB boundary due to PCIe
* wdma restrictions. We also try to align any smaller allocation to
* at least a 16 byte boundary for efficiency. We assume the linux
@@ -1349,7 +1362,7 @@ static struct ethtool_ops myri10ge_ethto
.get_rx_csum = myri10ge_get_rx_csum,
.set_rx_csum = myri10ge_set_rx_csum,
.get_tx_csum = ethtool_op_get_tx_csum,
- .set_tx_csum = ethtool_op_set_tx_csum,
+ .set_tx_csum = ethtool_op_set_tx_hw_csum,
.get_sg = ethtool_op_get_sg,
.set_sg = ethtool_op_set_sg,
#ifdef NETIF_F_TSO
@@ -2615,12 +2628,13 @@ static int myri10ge_probe(struct pci_dev
dev_err(&pdev->dev, "Error %d setting DMA mask\n", status);
goto abort_with_netdev;
}
- mgp->cmd = pci_alloc_consistent(pdev, sizeof(*mgp->cmd), &mgp->cmd_bus);
+ mgp->cmd = dma_alloc_coherent(&pdev->dev, sizeof(*mgp->cmd),
+ &mgp->cmd_bus, GFP_KERNEL);
if (mgp->cmd == NULL)
goto abort_with_netdev;
- mgp->fw_stats = pci_alloc_consistent(pdev, sizeof(*mgp->fw_stats),
-&mgp->fw_stats_bus);
+ mgp->fw_stats = dma_alloc_coherent(&pdev->dev, sizeof(*mgp->fw_stats),
+ &mgp->fw_stats_bus, GFP_KERNEL);
if (mgp->fw_stats == NULL)
goto abort_with_cmd;
@@ -2659,8 +2673,8 @@ static int myri10ge_probe(struct pci_dev
/* allocate rx done ring */
bytes = myri10ge_max_intr_slots * sizeof(*mgp->rx_done.entry);
- mgp->rx_done.entry =
- pci_alloc_consistent(pdev, bytes, &mgp->rx_done.bus);
+ mgp->rx_done.entry = dma_alloc_coherent(&pdev->dev, bytes,
+ &mgp->rx_done.bus, GFP_KERNEL);
if (mgp->rx_done.entry == NULL)
goto abort_with_ioremap
