Re: Fw: [Bugme-new] [Bug 7058] New: CONFIG_IP_ROUTE_FWMARK breaks rp_filter checks
Andrew Morton [EMAIL PROTECTED] wrote:
Using a fwmark as a key for selecting among multiple routing tables (via ip
rule command) breaks the rp_filter functionality since the fwmark field is
not
initialized in function fib_validate_source. Because of this there is no way
to
assure that outgoing and incoming packets use the same routing table.
Yes this is a problem. However, using the fwmark of the inbound packet
as the key to look up the inverse route isn't the best option since this
doesn't work if the mark generated by a real packet going in the inverse
direction is different.
This isn't the only problem that rp_filter has of course. For example,
it fails to take IPsec policies into account as well.
So perhaps it is time to look at solving this problem in a different way.
One possible approach is to have an rp_filter check in netfilter that
constructs the inverse flow of the packet in question and performs all
relevant lookups, including netfilter and IPsec, before deciding whether
the packet is acceptable or not. This would have the added benefit that
it can be turned on/off based on criteria other than the interface via
which a packet arrived on.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [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: IPSec kernel oops on ppc64
Joy Latten [EMAIL PROTECTED] wrote:
I installed 2.6.17 + patch-2.6.18-rc4 + 2.6.18-rc4-mm2
onto two pSeries power 5 (ppc64 lpars) machines. I configured
IPSec using the configuration listed below.
Could you try straight 2.6.17? If that crashes too, then at least we
can be sure that it isn't something new.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [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] ssb: Add support for new ChipCommon
Hi John,
Please apply this to wireless-dev.
--
This adds support for the new 0x900 ChipCommon core.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/misc/ssb.c
===
--- wireless-dev.orig/drivers/misc/ssb.c2006-08-24 22:33:44.0
+0200
+++ wireless-dev/drivers/misc/ssb.c 2006-08-26 12:28:31.0 +0200
@@ -648,7 +648,7 @@
ssb-chipcommon_capabilities = 0;
ssb-nr_cores = 0;
- if (cc == SSB_CC_CHIPCOMMON) {
+ if (cc == SSB_CC_CHIPCOMMON || cc == SSB_CC_CHIPCOMMON2) {
tmp = ssb_read32(ssb, SSB_CHIPCOMMON_CHIPID);
ssb-chip_id = (tmp SSB_CHIPCOMMON_IDMASK);
@@ -656,7 +656,7 @@
SSB_CHIPCOMMON_REVSHIFT;
ssb-chip_package = (tmp SSB_CHIPCOMMON_PACKMASK)
SSB_CHIPCOMMON_PACKSHIFT;
- if (rev = 4) {
+ if (rev = 4 || cc == SSB_CC_CHIPCOMMON2) {
ssb-nr_cores = (tmp SSB_CHIPCOMMON_NRCORESMASK)
SSB_CHIPCOMMON_NRCORESSHIFT;
}
Index: wireless-dev/include/linux/ssb.h
===
--- wireless-dev.orig/include/linux/ssb.h 2006-08-24 22:28:03.0
+0200
+++ wireless-dev/include/linux/ssb.h2006-08-26 12:26:11.0 +0200
@@ -251,6 +251,7 @@
#define SSB_CC_MINI_MACPHY 0x823
#define SSB_CC_ARM_11760x824
#define SSB_CC_ARM_7TDMI 0x825
+#define SSB_CC_CHIPCOMMON2 0x900
/* ChipCommon core registers. */
--
Greetings Michael.
-
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] bcm43xx-d80211: add support for 4312
Hi John,
Please apply this to wireless-dev.
Larry, theoretically it's possible to backport this
to wireless-2.6. But it depends on some other changes
that are (going to be) in the ssb module. That's support
for PCIE and CHIPCOMMON2, as far as I can see.
So if you want to backport this, you also have to backport
the PCIE and CHIPCOMMON2 stuff.
--
Add support for Broadcom 4312 a/b/g devices.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-08-24 22:49:45.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-08-26 12:39:24.0 +0200
@@ -129,6 +129,8 @@ static struct pci_device_id bcm43xx_pci_
{ PCI_VENDOR_ID_BROADCOM, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4307 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ /* Broadcom 4312 802.11a/b/g */
+ { PCI_VENDOR_ID_BROADCOM, 0x4312, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4319 802.11b/g */
@@ -2742,7 +2744,7 @@ static int bcm43xx_probe_cores(struct bc
switch (core-rev) {
case 2: case 4: case 5: case 6:
- case 7: case 9:
+ case 7: case 9: case 10:
break;
default:
printk(KERN_ERR PFX Error: Unsupported 80211
core revision %u\n,
@@ -3247,7 +3249,7 @@ static int bcm43xx_read_phyinfo(struct b
phy_rev_ok = 0;
break;
case BCM43xx_PHYTYPE_G:
- if (phy_rev 7)
+ if (phy_rev 8)
phy_rev_ok = 0;
break;
default:
--
Greetings Michael.
-
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 routing by fwmark
[IPV6]: Fix routing by fwmark Fix mark comparison, also dump the mask to userspace when the mask is zero, but the mark is not (in which case the mark is dumped, so the mask is needed to make sense of it). Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit 829b107d9e4ef2bbbf2ccf25a748235739e9231e tree 4ca98fb79f3e5e9cb0175ad9c074d9e4447735ac parent 6963696ada0c98c53c2d59ca66944adb4d13e3a5 author Patrick McHardy [EMAIL PROTECTED] Sat, 26 Aug 2006 13:12:32 +0200 committer Patrick McHardy [EMAIL PROTECTED] Sat, 26 Aug 2006 13:12:32 +0200 net/ipv6/fib6_rules.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c index ee4aa43..2fbc71d 100644 --- a/net/ipv6/fib6_rules.c +++ b/net/ipv6/fib6_rules.c @@ -129,7 +129,7 @@ static int fib6_rule_match(struct fib_ru return 0; #ifdef CONFIG_IPV6_ROUTE_FWMARK - if ((r-fwmark ^ fl-fl6_fwmark) / r-fwmask) + if ((r-fwmark ^ fl-fl6_fwmark) r-fwmask) return 0; #endif @@ -256,7 +256,7 @@ #ifdef CONFIG_IPV6_ROUTE_FWMARK if (rule6-fwmark) NLA_PUT_U32(skb, FRA_FWMARK, rule6-fwmark); - if (rule6-fwmask) + if (rule6-fwmask || rule6-fwmark) NLA_PUT_U32(skb, FRA_FWMASK, rule6-fwmask); #endif
Re: [NET_SCHED]: Add mask support to fwmark classifier
jamal wrote: Another approach could have been to add the mask as part of the hashing. and you add the new hash field not in the head rather in the filter. At runtime, you hash - walk the bucket and compare the mask as well as the index. That doesn't work. To what do you compare it? We have a mark from the packet .. but no mask. And we don't want to compare the mask but use it to mask the mark value. - 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 routing by fwmark
In article [EMAIL PROTECTED] (at Sat, 26 Aug 2006 13:11:26 +0200), Patrick McHardy [EMAIL PROTECTED] says: Fix mark comparison, also dump the mask to userspace when the mask is zero, but the mark is not (in which case the mark is dumped, so the mask is needed to make sense of it). Signed-off-by: Patrick McHardy [EMAIL PROTECTED] What a shame... Thank you for catching this. --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] ssb: Add support for new ChipCommon
Oops, sorry. Please drop this.
This patch is wrong and I will submit a correct one, soon.
a 0x900 core does not exist. Instead the meaning of the
revision bits changed slightly.
On Saturday 26 August 2006 12:33, Michael Buesch wrote:
Hi John,
Please apply this to wireless-dev.
--
This adds support for the new 0x900 ChipCommon core.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/misc/ssb.c
===
--- wireless-dev.orig/drivers/misc/ssb.c 2006-08-24 22:33:44.0
+0200
+++ wireless-dev/drivers/misc/ssb.c 2006-08-26 12:28:31.0 +0200
@@ -648,7 +648,7 @@
ssb-chipcommon_capabilities = 0;
ssb-nr_cores = 0;
- if (cc == SSB_CC_CHIPCOMMON) {
+ if (cc == SSB_CC_CHIPCOMMON || cc == SSB_CC_CHIPCOMMON2) {
tmp = ssb_read32(ssb, SSB_CHIPCOMMON_CHIPID);
ssb-chip_id = (tmp SSB_CHIPCOMMON_IDMASK);
@@ -656,7 +656,7 @@
SSB_CHIPCOMMON_REVSHIFT;
ssb-chip_package = (tmp SSB_CHIPCOMMON_PACKMASK)
SSB_CHIPCOMMON_PACKSHIFT;
- if (rev = 4) {
+ if (rev = 4 || cc == SSB_CC_CHIPCOMMON2) {
ssb-nr_cores = (tmp SSB_CHIPCOMMON_NRCORESMASK)
SSB_CHIPCOMMON_NRCORESSHIFT;
}
Index: wireless-dev/include/linux/ssb.h
===
--- wireless-dev.orig/include/linux/ssb.h 2006-08-24 22:28:03.0
+0200
+++ wireless-dev/include/linux/ssb.h 2006-08-26 12:26:11.0 +0200
@@ -251,6 +251,7 @@
#define SSB_CC_MINI_MACPHY 0x823
#define SSB_CC_ARM_1176 0x824
#define SSB_CC_ARM_7TDMI 0x825
+#define SSB_CC_CHIPCOMMON2 0x900
/* ChipCommon core registers. */
--
Greetings Michael.
-
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] ssb: fix core CC and REV reading
Hi John, Please apply this to wireless-dev. This is the correct fix for the ChipCommon issue. -- Fix CoreCode and CoreRev extraction from coreidhi. And yes, it's ugly. But that's how the device works. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-dev/drivers/misc/ssb.c === --- wireless-dev.orig/drivers/misc/ssb.c2006-08-26 13:34:03.0 +0200 +++ wireless-dev/drivers/misc/ssb.c 2006-08-26 13:43:11.0 +0200 @@ -643,8 +643,9 @@ int ssb_probe_cores(struct ssb *ssb, goto error; idhi = ssb_read32(ssb, SSB_IDHIGH); - cc = (idhi SSB_IDHIGH_CC_MASK) SSB_IDHIGH_CC_SHIFT; - rev = (idhi SSB_IDHIGH_RC_MASK); + cc = (idhi SSB_IDHIGH_CC) SSB_IDHIGH_CC_SHIFT; + rev = (idhi SSB_IDHIGH_RCLO); + rev |= (idhi SSB_IDHIGH_RCHI) SSB_IDHIGH_RCHI_SHIFT; ssb-chipcommon_capabilities = 0; ssb-nr_cores = 0; @@ -716,9 +717,10 @@ int ssb_probe_cores(struct ssb *ssb, core = (ssb-cores[i]); idhi = ssb_read32(ssb, SSB_IDHIGH); - core-cc = (idhi SSB_IDHIGH_CC_MASK) SSB_IDHIGH_CC_SHIFT; - core-rev = (idhi SSB_IDHIGH_RC_MASK); - core-vendor = (idhi SSB_IDHIGH_VC_MASK) SSB_IDHIGH_VC_SHIFT; + core-cc = (idhi SSB_IDHIGH_CC) SSB_IDHIGH_CC_SHIFT; + core-rev = (idhi SSB_IDHIGH_RCLO); + core-rev |= (idhi SSB_IDHIGH_RCHI) SSB_IDHIGH_RCHI_SHIFT; + core-vendor = (idhi SSB_IDHIGH_VC) SSB_IDHIGH_VC_SHIFT; core-index = i; dprintk(KERN_DEBUG PFX Core %d found: Index: wireless-dev/include/linux/ssb.h === --- wireless-dev.orig/include/linux/ssb.h 2006-08-26 13:34:03.0 +0200 +++ wireless-dev/include/linux/ssb.h2006-08-26 13:40:11.0 +0200 @@ -100,10 +100,12 @@ #define SSB_IDLOW_SSBREV_22 0x /* = 2.2 */ #define SSB_IDLOW_SSBREV_23 0x1000 /* 2.3 */ #define SSB_IDHIGH 0x0FFC /* SB Identification High */ -#define SSB_IDHIGH_RC_MASK0x000f /* Revision Code */ -#define SSB_IDHIGH_CC_MASK0xfff0 /* Core Code */ +#define SSB_IDHIGH_RCLO 0x000F /* Revision Code (low part) */ +#define SSB_IDHIGH_CC 0x8FF0 /* Core Code */ #define SSB_IDHIGH_CC_SHIFT 4 -#define SSB_IDHIGH_VC_MASK0x /* Vendor Code */ +#define SSB_IDHIGH_RCHI 0x7000 /* Revision Code (high part) */ +#define SSB_IDHIGH_RCHI_SHIFT 8 /* yes, shift 8 is right */ +#define SSB_IDHIGH_VC 0x /* Vendor Code */ #define SSB_IDHIGH_VC_SHIFT 16 /* SPROM shadow area. If not otherwise noted, fields are -- Greetings Michael. - 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
[NET]: Use BUILD_BUG_ON() for checking size of skb-cb.
[NET]: Use BUILD_BUG_ON() for checking size of skb-cb.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index c84a320..8f11a34 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1254,10 +1254,7 @@ static int __init inet_init(void)
struct list_head *r;
int rc = -EINVAL;
- if (sizeof(struct inet_skb_parm) sizeof(dummy_skb-cb)) {
- printk(KERN_CRIT %s: panic\n, __FUNCTION__);
- goto out;
- }
+ BUILD_BUG_ON(sizeof(struct inet_skb_parm) sizeof(dummy_skb-cb));
rc = proto_register(tcp_prot, 1);
if (rc)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index ac85e9c..b77726e 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -757,6 +757,8 @@ static int __init inet6_init(void)
struct list_head *r;
int err;
+ BUILD_BUG_ON(sizeof(struct inet6_skb_parm) sizeof(dummy_skb-cb));
+
#ifdef MODULE
#if 0 /* FIXME --RR */
if (!mod_member_present(__this_module, can_unload))
@@ -766,11 +768,6 @@ #if 0 /* FIXME --RR */
#endif
#endif
- if (sizeof(struct inet6_skb_parm) sizeof(dummy_skb-cb)) {
- printk(KERN_CRIT inet6_proto_init: size fault\n);
- return -EINVAL;
- }
-
err = proto_register(tcpv6_prot, 1);
if (err)
goto out;
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index b85c1f9..f3d63a5 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1728,8 +1728,6 @@ static struct net_proto_family netlink_f
.owner = THIS_MODULE, /* for consistency 8) */
};
-extern void netlink_skb_parms_too_large(void);
-
static int __init netlink_proto_init(void)
{
struct sk_buff *dummy_skb;
@@ -1741,8 +1739,7 @@ static int __init netlink_proto_init(voi
if (err != 0)
goto out;
- if (sizeof(struct netlink_skb_parms) sizeof(dummy_skb-cb))
- netlink_skb_parms_too_large();
+ BUILD_BUG_ON(sizeof(struct netlink_skb_parms) sizeof(dummy_skb-cb));
nl_table = kcalloc(MAX_LINKS, sizeof(*nl_table), GFP_KERNEL);
if (!nl_table) {
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index de6ec51..7c91c20 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2060,10 +2060,7 @@ static int __init af_unix_init(void)
int rc = -1;
struct sk_buff *dummy_skb;
- if (sizeof(struct unix_skb_parms) sizeof(dummy_skb-cb)) {
- printk(KERN_CRIT %s: panic\n, __FUNCTION__);
- goto out;
- }
+ BUILD_BUG_ON(sizeof(struct unix_skb_parms) sizeof(dummy_skb-cb));
rc = proto_register(unix_proto, 1);
if (rc != 0) {
--
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: RTL8136
I demand that Francois Romieu may or may not have written... Darren Salt [EMAIL PROTECTED] : In case you don't yet have an lspci dump for an RTL8136, here's one for a device which is working with the r1000 driver which is supplied with Ubuntu dapper (though the machine in question - a Toshiba Equium A110-233 - is actually running Debian testing.) Thanks. The MM region was correctly guessed. If the driver does not work, ... which it doesn't - the connection is lost, and the hardware continually tries and fails to re-establish it. I can at least get a 10baseT/full connection with help from ethtool, but trying to send anything over it fails; switching back to r1000 (and forcing the connection speed) gets things working again, though a reboot seems to be needed to get auto-negotiation of higher speeds working again (note that it's limited to 100baseT/full; I have nothing else capable of 1000baseT). you can try to s/RTL_CFG_1/RTL_CFG_2/ for the 0x8136 entry in the rtl8169_pci_tbl array. That appears to make no difference. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | Kill all extremists! The universe is a spheroid region 705m in diameter. - 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] bcm43xx-d80211: 4311 support
Hi John,
Please apply this to wireless-dev.
--
This adds support for the 4311 cards.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-08-26 13:34:45.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-08-26 14:06:11.0 +0200
@@ -129,6 +129,8 @@ static struct pci_device_id bcm43xx_pci_
{ PCI_VENDOR_ID_BROADCOM, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4307 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ /* Broadcom 4311 802.11a/b/g */
+ { PCI_VENDOR_ID_BROADCOM, 0x4311, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4312 802.11a/b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4312, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4318 802.11b/g */
@@ -2301,7 +2303,9 @@ static int bcm43xx_wireless_core_init(st
u32 sbimconfiglow;
u8 limit;
- if (bcm-ssb.chip_rev 5) {
+ assert(bcm-core_pci);
+ if (bcm-core_pci-cc == SSB_CC_PCI
+ bcm-core_pci-rev = 5) {
sbimconfiglow = bcm43xx_read32(bcm, SSB_IMCFGLO);
sbimconfiglow = ~SSB_IMCFGLO_REQTO;
sbimconfiglow = ~SSB_IMCFGLO_SERTO;
@@ -2712,6 +2716,7 @@ static int bcm43xx_probe_cores(struct bc
switch (core-cc) {
case SSB_CC_PCI:
+ case SSB_CC_PCIE:
if (bcm-core_pci) {
printk(KERN_WARNING PFX Multiple PCI cores
found.\n);
break;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
2006-08-24 22:18:03.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_power.c
2006-08-26 15:05:21.0 +0200
@@ -153,8 +153,6 @@ int bcm43xx_pctl_init(struct bcm43xx_pri
int err, maxfreq;
struct ssb_core *old_core;
- if (!(bcm-ssb.chipcommon_capabilities SSB_CHIPCOMMON_CAP_PCTL))
- return 0;
if (!bcm-core_chipcommon)
return 0;
@@ -163,11 +161,26 @@ int bcm43xx_pctl_init(struct bcm43xx_pri
if (err)
goto out;
- maxfreq = bcm43xx_pctl_clockfreqlimit(bcm, 1);
- bcm43xx_write32(bcm, SSB_CHIPCOMMON_PLLONDELAY,
- (maxfreq * 150 + 99) / 100);
- bcm43xx_write32(bcm, SSB_CHIPCOMMON_FREFSELDELAY,
- (maxfreq * 15 + 99) / 100);
+ if (bcm-ssb.chip_id == 0x4321) {
+ if (bcm-ssb.chip_rev == 0)
+ bcm43xx_write32(bcm, SSB_CHIPCOMMON_CHIPCTL, 0x03A4);
+ else if (bcm-ssb.chip_rev == 1)
+ bcm43xx_write32(bcm, SSB_CHIPCOMMON_CHIPCTL, 0x00A4);
+ }
+ if (bcm-ssb.chipcommon_capabilities SSB_CHIPCOMMON_CAP_PCTL) {
+ if (bcm-core_chipcommon-rev = 10) {
+ /* Set Idle Power clock rate to 1Mhz */
+ bcm43xx_write32(bcm, SSB_CHIPCOMMON_SYSCLKCTL,
+ (bcm43xx_read32(bcm,
SSB_CHIPCOMMON_SYSCLKCTL)
+0x) | 0x0004);
+ } else {
+ maxfreq = bcm43xx_pctl_clockfreqlimit(bcm, 1);
+ bcm43xx_write32(bcm, SSB_CHIPCOMMON_PLLONDELAY,
+ (maxfreq * 150 + 99) / 100);
+ bcm43xx_write32(bcm, SSB_CHIPCOMMON_FREFSELDELAY,
+ (maxfreq * 15 + 99) / 100);
+ }
+ }
err = ssb_switch_core(bcm-ssb, old_core);
assert(err == 0);
Index: wireless-dev/include/linux/ssb.h
===
--- wireless-dev.orig/include/linux/ssb.h 2006-08-26 13:40:11.0
+0200
+++ wireless-dev/include/linux/ssb.h2006-08-26 14:57:44.0 +0200
@@ -279,12 +279,40 @@ enum {
#define SSB_CHIPCOMMON_CAP_64BIT 0x0800 /* 64-bit Backplane */
#define SSB_CHIPCOMMON_CORECTL 0x0008
#define SSB_CHIPCOMMON_BIST0x000C
+#define SSB_CHIPCOMMON_OTPSTAT 0x0010
+#define SSB_CHIPCOMMON_OTPCTL 0x0014
+#define SSB_CHIPCOMMON_OTPPRG 0x0018
+#define SSB_CHIPCOMMON_IRQSTAT 0x0020
+#define SSB_CHIPCOMMON_IRQMASK 0x0024
+#define SSB_CHIPCOMMON_CHIPCTL 0x0028 /* Rev = 11 only */
+#define SSB_CHIPCOMMON_CHIPSTAT0x002C /* Rev = 11 only */
+#define SSB_CHIPCOMMON_JTAGCMD 0x0030 /* Rev = 10 only */
+#define
Re: [patch 08/10] [TULIP] Handle pci_enable_device() errors in resume
Ar Gwe, 2006-08-25 am 17:02 -0700, ysgrifennodd Valerie Henson:
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- pci_enable_device(pdev);
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR tulip: pci_enable_device failed in resume\n);
+ return retval;
+ }
Should you not stick it back in D3 if you are being neat about this ?
if ((retval = request_irq(dev-irq, tulip_interrupt, IRQF_SHARED,
dev-name, dev))) {
printk (KERN_ERR tulip: request_irq failed in resume\n);
--- linux-2.6.18-rc4-mm1.orig/drivers/net/tulip/winbond-840.c
+++ linux-2.6.18-rc4-mm1/drivers/net/tulip/winbond-840.c
@@ -1626,14 +1626,18 @@ static int w840_resume (struct pci_dev *
{
struct net_device *dev = pci_get_drvdata (pdev);
struct netdev_private *np = netdev_priv(dev);
+ int retval;
rtnl_lock();
if (netif_device_present(dev))
goto out; /* device not suspended */
if (netif_running(dev)) {
- pci_enable_device(pdev);
- /* pci_power_on(pdev); */
-
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR
+ %s: pci_enable_device failed in resume\n,
+ dev-name);
+ return retval;
NAK: What about rtnl_lock()
+ }
spin_lock_irq(np-lock);
iowrite32(1, np-base_addr+PCIBusCfg);
ioread32(np-base_addr+PCIBusCfg);
--- linux-2.6.18-rc4-mm1.orig/drivers/net/tulip/de2104x.c
+++ linux-2.6.18-rc4-mm1/drivers/net/tulip/de2104x.c
@@ -2138,17 +2138,21 @@ static int de_resume (struct pci_dev *pd
{
struct net_device *dev = pci_get_drvdata (pdev);
struct de_private *de = dev-priv;
+ int retval;
rtnl_lock();
if (netif_device_present(dev))
goto out;
- if (netif_running(dev)) {
- pci_enable_device(pdev);
- de_init_hw(de);
- netif_device_attach(dev);
- } else {
- netif_device_attach(dev);
+ if (!netif_running(dev))
+ goto out_attach;
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR %s: pci_enable_device failed in resume\n,
+ dev-name);
+ return retval;
NAK again - rtnl_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: [patch 05/10] [TULIP] Defer tulip_select_media() to process context
Ar Gwe, 2006-08-25 am 17:02 -0700, ysgrifennodd Valerie Henson:
+static inline void tulip_tx_timeout_complete(struct tulip_private *tp, void
__iomem *ioaddr)
+{
+ /* Stop and restart the chip's Tx processes. */
+ tulip_restart_rxtx(tp);
+ /* Trigger an immediate transmit demand. */
+ iowrite32(0, ioaddr + CSR1);
In mmio mode it will only be immediate if the caller is guaranteed to
read from the device and flush the iowrite
-
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] net/*: use SLAB_PANIC
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
Forgive me reformatting, in some cases making it fit in 80 columns was hard.
net/core/flow.c|6 +-
net/core/neighbour.c | 12
net/core/skbuff.c |9 ++---
net/decnet/dn_route.c | 11 +++
net/ipv4/inetpeer.c|5 +
net/ipv4/ipmr.c|5 +
net/ipv4/route.c | 10 +++---
net/ipv4/tcp.c |4 +---
net/ipv6/ip6_fib.c |4 +---
net/ipv6/route.c | 10 +++---
net/xfrm/xfrm_input.c |4 +---
net/xfrm/xfrm_policy.c |5 +
12 files changed, 22 insertions(+), 63 deletions(-)
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -346,12 +346,8 @@ static int __init flow_cache_init(void)
flow_cachep = kmem_cache_create(flow_cache,
sizeof(struct flow_cache_entry),
- 0, SLAB_HWCACHE_ALIGN,
+ 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC,
NULL, NULL);
-
- if (!flow_cachep)
- panic(NET: failed to allocate flow cache slab\n);
-
flow_hash_shift = 10;
flow_lwm = 2 * flow_hash_size;
flow_hwm = 4 * flow_hash_size;
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1338,14 +1338,10 @@ void neigh_table_init_no_netlink(struct
neigh_rand_reach_time(tbl-parms.base_reachable_time);
if (!tbl-kmem_cachep)
- tbl-kmem_cachep = kmem_cache_create(tbl-id,
-tbl-entry_size,
-0, SLAB_HWCACHE_ALIGN,
-NULL, NULL);
-
- if (!tbl-kmem_cachep)
- panic(cannot create neighbour cache);
-
+ tbl-kmem_cachep =
+ kmem_cache_create(tbl-id, tbl-entry_size, 0,
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC,
+ NULL, NULL);
tbl-stats = alloc_percpu(struct neigh_statistics);
if (!tbl-stats)
panic(cannot create neighbour cache statistics);
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2046,19 +2046,14 @@ void __init skb_init(void)
skbuff_head_cache = kmem_cache_create(skbuff_head_cache,
sizeof(struct sk_buff),
0,
- SLAB_HWCACHE_ALIGN,
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC,
NULL, NULL);
- if (!skbuff_head_cache)
- panic(cannot create skbuff cache);
-
skbuff_fclone_cache = kmem_cache_create(skbuff_fclone_cache,
(2*sizeof(struct sk_buff)) +
sizeof(atomic_t),
0,
- SLAB_HWCACHE_ALIGN,
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC,
NULL, NULL);
- if (!skbuff_fclone_cache)
- panic(cannot create skbuff cache);
}
EXPORT_SYMBOL(___pskb_trim);
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1781,14 +1781,9 @@ void __init dn_route_init(void)
{
int i, goal, order;
- dn_dst_ops.kmem_cachep = kmem_cache_create(dn_dst_cache,
- sizeof(struct dn_route),
- 0, SLAB_HWCACHE_ALIGN,
- NULL, NULL);
-
- if (!dn_dst_ops.kmem_cachep)
- panic(DECnet: Failed to allocate dn_dst_cache\n);
-
+ dn_dst_ops.kmem_cachep =
+ kmem_cache_create(dn_dst_cache, sizeof(struct dn_route), 0,
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
init_timer(dn_route_timer);
dn_route_timer.function = dn_dst_check_expire;
dn_route_timer.expires = jiffies + decnet_dst_gc_interval * HZ;
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -126,12 +126,9 @@ void __init inet_initpeers(void)
peer_cachep = kmem_cache_create(inet_peer_cache,
sizeof(struct inet_peer),
- 0, SLAB_HWCACHE_ALIGN,
+ 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC,
NULL, NULL);
- if (!peer_cachep)
- panic(cannot create inet_peer_cache);
-
/* All the timers, started at system startup tend
to synchronize. Perturb it a bit.
*/
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1899,11 +1899,8 @@ void __init ip_mr_init(void)
{
mrt_cachep =
Re: [PATCH 0/7] [DCCP]: Fixes and enhancements
From: Ian McDonald [EMAIL PROTECTED] Date: Thu, 24 Aug 2006 15:16:33 +1200 Please find following a series of patches for DCCP. These have been tested against torvalds/linux-2.6.git and davem/net-2.6.19.git My opinion is that 1 and 2 can go straight into 2.6.18 as documentation changes only - Dave - are you able to do as Arnaldo is very busy at present. I would love 3, 4, 5 to go into 2.6.18 as these resolve long standing CCID3 issues that have been in the DCCP tree since inception and have caught a number of people. Ok, I'll toss 1-5 into 2.6.18 One thing I don't understand is this description from patch 5: This gives a theoretical speed of 71.9 Kbits/s. I measured across three runs with this patch set and got 70.1 Kbits/s. Without this patchset the average was 232 Kbits/s which means Linux can't be used for CCID3 research properly. Decreasing the transfer rate is desirable? I read this as saying this fix drops the transfer rate down from 232Kb/sec to 70.1Kb/sec. What's going on here? - 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] remove third bogus argument from NLA_PUT_FLAG
From: Johannes Berg [EMAIL PROTECTED] Date: Fri, 25 Aug 2006 12:55:26 +0200 This patch removes the 'value' argument from NLA_PUT_FLAG which is unused anyway. The documentation comment was already correct so it doesn't need an update :) Signed-off-by: Johannes Berg [EMAIL PROTECTED] Applied, thanks Johannes. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/*: use SLAB_PANIC
From: Alexey Dobriyan [EMAIL PROTECTED] Date: Sun, 27 Aug 2006 03:08:41 +0400 Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] Applied, thanks. - 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
2.6.18-rc4-mm3: NF_CONNTRACK_FTP=y compile error
On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote: ... Changes since 2.6.18-rc4-mm2: ... git-net.patch ... git trees ... -- snip -- ... CC net/netfilter/nf_conntrack_ftp.o /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c: In function ‘get_ipv6_addr’: /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: warning: implicit declaration of function ‘in6_pton’ /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: ‘end’ undeclared (first use in this function) /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: (Each undeclared identifier is reported only once /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: for each function it appears in.) make[3]: *** [net/netfilter/nf_conntrack_ftp.o] Error 1 -- snip -- cu Adrian -- Gentoo kernels are 42 times more popular than SUSE kernels among KLive users (a service by SUSE contractor Andrea Arcangeli that gathers data about kernels from many users worldwide). There are three kinds of lies: Lies, Damn Lies, and Statistics. Benjamin Disraeli - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc4-mm3: NF_CONNTRACK_FTP=y compile error
From: Adrian Bunk [EMAIL PROTECTED]
Date: Sun, 27 Aug 2006 04:42:19 +0200
CC net/netfilter/nf_conntrack_ftp.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:
In function $,1rx(Bget_ipv6_addr$,1ry(B:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117:
warning: implicit declaration of function $,1rx(Bin6_pton$,1ry(B
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117:
error: $,1rx(Bend$,1ry(B undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117:
error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117:
error: for each function it appears in.)
make[3]: *** [net/netfilter/nf_conntrack_ftp.o] Error 1
So the one single place where we call this new in6_pton() thing,
it doesn't even compile.
Yoshifuji, what tree are you testing your builds against? This
is the second build failure introduced by this in6_pton()
changeset.
I'm going to butcher it like this so at least it builds.
commit 32677088bc145cf7d45466e39286f1a8c7bf2d67
Author: David S. Miller [EMAIL PROTECTED]
Date: Sat Aug 26 19:48:49 2006 -0700
[NETFILTER]: Fix nf_conntrack_ftp.c build.
Noticed by Adrian Bunk.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c
index 9dccb40..0c17a5b 100644
--- a/net/netfilter/nf_conntrack_ftp.c
+++ b/net/netfilter/nf_conntrack_ftp.c
@@ -21,6 +21,7 @@ #include linux/netfilter.h
#include linux/ip.h
#include linux/ipv6.h
#include linux/ctype.h
+#include linux/inet.h
#include net/checksum.h
#include net/tcp.h
@@ -114,7 +115,8 @@ static struct ftp_search {
static int
get_ipv6_addr(const char *src, size_t dlen, struct in6_addr *dst, u_int8_t
term)
{
- int ret = in6_pton(src, min_t(size_t, dlen, 0x), dst, term, end);
+ const char *end;
+ int ret = in6_pton(src, min_t(size_t, dlen, 0x), (u8 *)dst, term,
end);
if (ret 0)
return (int)(end - src);
return 0;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2.6.17] net/ipv6/udp.c: remove duplicate udp_get_port code
From: [EMAIL PROTECTED] Date: Thu, 17 Aug 2006 13:25:46 +0100 [NET]: UDPv4 and UDPv6 use an almost identical version of the get_port function, which is unnecessary since the (long) code differs in only one if-statement. This patch creates one common function which is called by udp_v4_get_port() and udp_v6_get_port(). As a result, * duplicated code is removed * udp_port_rover and local port lookup can now be removed from udp.h * further savings follow since the same function will be used by UDP-Litev4 and UDP-Litev6 In contrast to the patch sent in response to Yoshifujis comments (fixed by this variant), the code below also removes the EXPORT_SYMBOL(udp_port_rover), since udp_port_rover can now remain local to net/ipv4/udp.c. Signed-off-by: Gerrit Renker [EMAIL PROTECTED] Applied, and I marked udp_port_rover static for good measure. Thanks. - 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] [NETLINK]: Make use of NLA_STRING/NLA_NUL_STRING attribute validation
From: Thomas Graf [EMAIL PROTECTED] Date: Tue, 22 Aug 2006 14:53:56 +0200 Converts existing NLA_STRING attributes to use the new validation features, saving a couple of temporary buffers. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Applied, thanks Thomas. - 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 0/4] bridge-netfilter fixes
From: [EMAIL PROTECTED] Date: Tue, 22 Aug 2006 17:10:50 -0700 This set of patches fixes issues with bridge netfilter code. First patch is for 2.6.18 and fixes a crash. Later patches could be deferred, they just cleanup the style, usage, etc. What a nasty bug. I'll push the bug fix to Linus for 2.6.18 right now, and after he eats that I'll rebase net-2.6.19 then put your other 3 patches on top. Thanks. - 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 0/7] [DCCP]: Fixes and enhancements
On 8/27/06, David Miller [EMAIL PROTECTED] wrote: I would love 3, 4, 5 to go into 2.6.18 as these resolve long standing CCID3 issues that have been in the DCCP tree since inception and have caught a number of people. Ok, I'll toss 1-5 into 2.6.18 Thanks for that. Are 6 and 7 going into 2.6.19 or do you want Arnaldo to have a bit more of a look? 6 in particular is trivial. One thing I don't understand is this description from patch 5: This gives a theoretical speed of 71.9 Kbits/s. I measured across three runs with this patch set and got 70.1 Kbits/s. Without this patchset the average was 232 Kbits/s which means Linux can't be used for CCID3 research properly. Decreasing the transfer rate is desirable? I read this as saying this fix drops the transfer rate down from 232Kb/sec to 70.1Kb/sec. What's going on here? DCCP CCID3 (RFC 4342) uses TFRC (RFC 3448) to calculate the desired rate to send at based on feedback from the receiver. The reason for this is that TFRC is not ACK/Window based to control rate and TFRC calculates a rate so that the flow is fair when competing with TCP. TFRC is designed to be smoother than TCP at dealing with loss - more sine wave than saw tooth. The calculation is based on the work Padhye et al did in this paper - http://citeseer.ist.psu.edu/padhye98modeling.html As it turns out this is based on TCP Reno at that time and modern TCP variants are more efficient when dealing with loss as can be verified through iperf but we should implement what the RFC says. Basically the implementation in the DCCP code was buggy and was transmitting too fast so I have made it conform to the RFC much closer. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand - 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 08/10] [TULIP] Handle pci_enable_device() errors in resume
On Sat, Aug 26, 2006 at 05:41:58PM +0100, Alan Cox wrote:
Ar Gwe, 2006-08-25 am 17:02 -0700, ysgrifennodd Valerie Henson:
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- pci_enable_device(pdev);
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR tulip: pci_enable_device failed in resume\n);
+ return retval;
+ }
Should you not stick it back in D3 if you are being neat about this ?
I don't know. Any thoughts from the peanut gallery? I've spent some
time trolling both docs and other drivers, but I haven't yet found an
example of a driver that correctly handles all the resume error cases.
Also, at least one other driver does a pci_disable_device() if the
request_irq() fails - should tulip do this too?
NAK: What about rtnl_lock()
Gah. Thanks, how about the patch below instead?
-VAL
Subject: [TULIP] Handle pci_enable_device() errors in resume
Signed-off-by: Valerie Henson [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
---
drivers/net/tulip/de2104x.c | 16 ++--
drivers/net/tulip/tulip_core.c |5 -
drivers/net/tulip/winbond-840.c | 12
3 files changed, 22 insertions(+), 11 deletions(-)
--- linux-2.6.18-rc4-mm1-tulip.orig/drivers/net/tulip/tulip_core.c
+++ linux-2.6.18-rc4-mm1-tulip/drivers/net/tulip/tulip_core.c
@@ -1780,7 +1780,10 @@ static int tulip_resume(struct pci_dev *
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- pci_enable_device(pdev);
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR tulip: pci_enable_device failed in resume\n);
+ return retval;
+ }
if ((retval = request_irq(dev-irq, tulip_interrupt, IRQF_SHARED,
dev-name, dev))) {
printk (KERN_ERR tulip: request_irq failed in resume\n);
--- linux-2.6.18-rc4-mm1-tulip.orig/drivers/net/tulip/winbond-840.c
+++ linux-2.6.18-rc4-mm1-tulip/drivers/net/tulip/winbond-840.c
@@ -1626,14 +1626,18 @@ static int w840_resume (struct pci_dev *
{
struct net_device *dev = pci_get_drvdata (pdev);
struct netdev_private *np = netdev_priv(dev);
+ int retval = 0;
rtnl_lock();
if (netif_device_present(dev))
goto out; /* device not suspended */
if (netif_running(dev)) {
- pci_enable_device(pdev);
- /* pci_power_on(pdev); */
-
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR
+ %s: pci_enable_device failed in resume\n,
+ dev-name);
+ goto out;
+ }
spin_lock_irq(np-lock);
iowrite32(1, np-base_addr+PCIBusCfg);
ioread32(np-base_addr+PCIBusCfg);
@@ -1651,7 +1655,7 @@ static int w840_resume (struct pci_dev *
}
out:
rtnl_unlock();
- return 0;
+ return retval;
}
#endif
--- linux-2.6.18-rc4-mm1-tulip.orig/drivers/net/tulip/de2104x.c
+++ linux-2.6.18-rc4-mm1-tulip/drivers/net/tulip/de2104x.c
@@ -2138,17 +2138,21 @@ static int de_resume (struct pci_dev *pd
{
struct net_device *dev = pci_get_drvdata (pdev);
struct de_private *de = dev-priv;
+ int retval = 0;
rtnl_lock();
if (netif_device_present(dev))
goto out;
- if (netif_running(dev)) {
- pci_enable_device(pdev);
- de_init_hw(de);
- netif_device_attach(dev);
- } else {
- netif_device_attach(dev);
+ if (!netif_running(dev))
+ goto out_attach;
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR %s: pci_enable_device failed in resume\n,
+ dev-name);
+ goto out;
}
+ de_init_hw(de);
+out_attach:
+ netif_device_attach(dev);
out:
rtnl_unlock();
return 0;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] [DCCP]: Fixes and enhancements
From: Ian McDonald [EMAIL PROTECTED] Date: Sun, 27 Aug 2006 15:46:58 +1200 On 8/27/06, David Miller [EMAIL PROTECTED] wrote: I would love 3, 4, 5 to go into 2.6.18 as these resolve long standing CCID3 issues that have been in the DCCP tree since inception and have caught a number of people. Ok, I'll toss 1-5 into 2.6.18 Thanks for that. Are 6 and 7 going into 2.6.19 or do you want Arnaldo to have a bit more of a look? 6 in particular is trivial. Those patches are already in net-2.6.19 Basically the implementation in the DCCP code was buggy and was transmitting too fast so I have made it conform to the RFC much closer. Thanks for the explanation. - 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 0/7] [DCCP]: Fixes and enhancements
On 8/27/06, David Miller [EMAIL PROTECTED] wrote: I would love 3, 4, 5 to go into 2.6.18 as these resolve long standing CCID3 issues that have been in the DCCP tree since inception and have caught a number of people. Ok, I'll toss 1-5 into 2.6.18 Thanks for that. Are 6 and 7 going into 2.6.19 or do you want Arnaldo to have a bit more of a look? 6 in particular is trivial. Those patches are already in net-2.6.19 Yes I see that now. However I can't see #5 in net-2.6.git in your tree or Linus' where 1-4 made it in... Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand - 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: lockdep rt2500usb report
On Friday 11 August 2006 01:34, Johannes Berg wrote: This is running wireless-dev from yesterday. All I did was plug in a rt2500usb device into a usb port on a freshly booted system. I have a feeling that this is could be one of the problems reported earlier with the d80211 stack, but I haven't mastered the art of picking through these traces yet... What's swapper doing in there? Ok, so it looks like dev_activate (called by dev_open) grabs queue_lock, then calls another function (dev_watchdog_up) which grabs xmit_lock. However, at that point, the device is up enough that someone who wants to try transmitting, can transmit (I think). If they're unlucky enough to transmit after the queue_lock is grabbed but before xmit_lock, we get a deadlock. This seems avoidable either by setting carrier_off before calling dev_open, and turning it back on at a safe point (on association?), or simply refusing to transmit until it is reasonable to do so. (a similar thing was done in adm8211: call netif_stop_queue and return 1 if we're not ready to tx yet in order to hold skbs until association, where netif_wake_queue would be called.) -Michael Wu pgpcKsoDg6PyO.pgp Description: PGP signature
Re: [PATCH 0/7] [DCCP]: Fixes and enhancements
From: Ian McDonald [EMAIL PROTECTED] Date: Sun, 27 Aug 2006 16:57:17 +1200 Yes I see that now. However I can't see #5 in net-2.6.git in your tree or Linus' where 1-4 made it in... Resend it to me privately and I'll figure out what happened. - 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
