Re: [PATCH 5/6] tg3: Skip timer code during full lock
David S. Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:10:10 -0800 Skip the main timer code if interrupts are disabled in the full lock state. Signed-off-by: Michael Chan [EMAIL PROTECTED] Could this wedge the driver while we're trying to quiesce the interrupt? If so, probably a 2.6.16.x stable candidate? I don't think it will. The timer gets the the tp-lock before doing anything so the worse that can happen is that it will spin for a long time waiting for the tp-lock. This can happen if one CPU has entered tg3_full_lock() and then do something lengthy such as self test while another CPU is entering tg3_timer() for example. - 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/6] tg3: Skip timer code during full lock
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 23:58:59 -0800 David S. Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:10:10 -0800 Skip the main timer code if interrupts are disabled in the full lock state. Signed-off-by: Michael Chan [EMAIL PROTECTED] Could this wedge the driver while we're trying to quiesce the interrupt? If so, probably a 2.6.16.x stable candidate? I don't think it will. The timer gets the the tp-lock before doing anything so the worse that can happen is that it will spin for a long time waiting for the tp-lock. This can happen if one CPU has entered tg3_full_lock() and then do something lengthy such as self test while another CPU is entering tg3_timer() for example. Ok. - 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: [INET]: Introduce tunnel4/tunnel6
From: Herbert Xu [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 21:17:59 +1100 Basically this patch moves the generic tunnel protocol stuff out of xfrm4_tunnel/xfrm6_tunnel and moves it into the new files of tunnel4.c and tunnel6 respectively. Ok, this seems reasonable, applied. BTW, can you sanity check your patches with something like: git apply --check --whitespace=error-all diff This patch here had a bunch of trailing whitespace I had to fixup for you. 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: [INET]: Introduce tunnel4/tunnel6
On Tue, Mar 28, 2006 at 01:13:11AM -0800, David S. Miller wrote:
Ok, this seems reasonable, applied.
Thanks.
BTW, can you sanity check your patches with something like:
git apply --check --whitespace=error-all diff
This patch here had a bunch of trailing whitespace I had
to fixup for you.
OK, will do.
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: Fix memory allocation in com90xx.c
On Monday 27 March 2006 17:41, Darren Jenkins\ wrote: - shmems = kzalloc(((0x1-0xa) / 0x800) * sizeof(unsigned long), + shmems = kcalloc(((0x1-0xa) / 0x800), sizeof(unsigned long), GFP_KERNEL); If it's too big for kzalloc then it's too big for kcalloc too. -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
[softmac] Re: internal functions send packets even when queue is full
Hi, It doesn't, but softmac tries to send 2 separate frames in quick succession when associating, the second of which is a probereq (haven't looked at the first), and the first one hasn't had quite enough time to complete at that point. Ah ok. The second one should only come in after a receive though, or maybe it is resending the packet.. doubt that though. Interesting idea. netif_stop_queue() is called at the start of the TX function, and netif_wake_queue() is called when the entire transmission has been completed. netif_queue_stopped() can be called at any point to determine whether the queue is running. Right. I was just wondering if there was a completion in the network layer for netif_wake_queue() :) Maybe we should lose the is_queue_running hook and simply just use the netif queue as detailed above. Then we could provide softmac wrappers around those functions. Probably. That way, when softmac_netif_queue_wake() is called, we can first transmit the internal softmac packets which were previously suspended, and when they are done, softmac_netif_queue_wake() can call the real netif_queue_wake(). Does that sound sensible? That way we won't need the completion in any case :) Will any softmac developers be at the summit? Yes, I'll be there. johannes signature.asc Description: This is a digitally signed message part
Re: Fix memory allocation in com90xx.c
On Tue, Mar 28, 2006 at 01:12:25PM +0200, Andi Kleen wrote: On Monday 27 March 2006 17:41, Darren Jenkins\ wrote: - shmems = kzalloc(((0x1-0xa) / 0x800) * sizeof(unsigned long), + shmems = kcalloc(((0x1-0xa) / 0x800), sizeof(unsigned long), GFP_KERNEL); Original problem is obvious, blatant typo: that 0x1 should've been 0x10. Fix is in -mm; I thought it got to mainline already... - 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: Fix memory allocation in com90xx.c
On Tue, 2006-03-28 at 13:12 +0200, Andi Kleen wrote: GFP_KERNEL); If it's too big for kzalloc then it's too big for kcalloc too. -Andi Thanks for that. I seem to have been rather confused about the difference between kzalloc, and kcalloc. Darren 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: [PATCH 1/6] tg3: Fix probe failure due to invalid MAC address
Michael Chan wrote: Some older bootcode in some devices may report 0 MAC address in SRAM when booting up from low power state. This patch fixes the problem by checking for a valid MAC address in SRAM and falling back to NVRAM if necessary. Seems to fix the problem, thanks. Thanks to walt [EMAIL PROTECTED] for reporting the problem and helping to debug it... My pleasure. And thanks to you for supporting open source. - 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] spidernet : reduce console spam
This patch reduces the message level of the RX ram full messages from err to debug to prevent spamming the console leaving it in the logfiles though. Please apply. From: Jens Osterkamp [EMAIL PROTECTED] Index: linux-2.6.16/drivers/net/spider_net.c === --- linux-2.6.16.orig/drivers/net/spider_net.c +++ linux-2.6.16/drivers/net/spider_net.c @@ -1442,7 +1442,7 @@ spider_net_handle_error_irq(struct spide case SPIDER_NET_GRFAFLLINT: /* fallthrough */ case SPIDER_NET_GRMFLLINT: if (netif_msg_intr(card) net_ratelimit()) - pr_err(Spider RX RAM full, incoming packets + pr_debug(Spider RX RAM full, incoming packets might be discarded!\n); spider_net_rx_irq_off(card); tasklet_schedule(card-rxram_full_tl); - 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
[RFC] [PATCH] spidernet : move BCM5421 and BCM 5461 init code for fiber mode
Hi,
the BCM5421 and (now) 5461 chips that we use on our boards contain a
serdes/fiber
interface in addition to the copper interface.
Up to now we were using the generic init code in drivers/net/sungem_phy.c and
some
additional code to set up the serdes/fiber mode in our driver
(drivers/net/spider_net.c).
In a first step I want to get rid of the BCM init code in spider_ net.c and
move this to
sungem_phy.c where it belongs in my opinion. For this I added a enable_fiber
function pointer and two separate enable_fiber functions for the 5421 and the
5461.
A second step would then be to move the sungem_phy code over to the generic
kernel
phy infrastructure code and use this in the affected drivers (sungem.c and
spidernet.c).
Questions / comments / suggestions ?
Jens
Index: linux-2.6.16/drivers/net/sungem_phy.c
===
--- linux-2.6.16.orig/drivers/net/sungem_phy.c
+++ linux-2.6.16/drivers/net/sungem_phy.c
@@ -329,6 +329,30 @@ static int bcm5421_init(struct mii_phy*
return 0;
}
+static int bcm5421_enable_fiber(struct mii_phy* phy)
+{
+ /* enable fiber mode */
+ phy_write(phy, MII_NCONFIG, 0x9020);
+ /* LEDs active in both modes, autosense prio = fiber */
+ phy_write(phy, MII_NCONFIG, 0x945f);
+
+ /* switch off fibre autoneg */
+ phy_write(phy, MII_NCONFIG, 0xfc01);
+ phy_write(phy, 0x0b, 0x0004);
+
+ return 0;
+}
+
+static int bcm5461_enable_fiber(struct mii_phy* phy)
+{
+phy_write(phy, MII_NCONFIG, 0xfc0c);
+phy_write(phy, MII_BMCR, 0x4140);
+phy_write(phy, MII_NCONFIG, 0xfc0b);
+ phy_write(phy, MII_BMCR, 0x0140);
+
+ return 0;
+}
+
static int bcm54xx_setup_aneg(struct mii_phy *phy, u32 advertise)
{
u16 ctl, adv;
@@ -762,6 +786,7 @@ static struct mii_phy_ops bcm5421_phy_op
.setup_forced = bcm54xx_setup_forced,
.poll_link = genmii_poll_link,
.read_link = bcm54xx_read_link,
+ .enable_fiber = bcm5421_enable_fiber,
};
static struct mii_phy_def bcm5421_phy_def = {
@@ -792,6 +817,25 @@ static struct mii_phy_def bcm5421k2_phy_
.ops= bcm5421k2_phy_ops
};
+static struct mii_phy_ops bcm5461_phy_ops = {
+ .init = bcm5421_init,
+ .suspend= bcm5411_suspend,
+ .setup_aneg = bcm54xx_setup_aneg,
+ .setup_forced = bcm54xx_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = bcm54xx_read_link,
+ .enable_fiber = bcm5461_enable_fiber,
+};
+
+static struct mii_phy_def bcm5461_phy_def = {
+ .phy_id = 0x002060c0,
+ .phy_id_mask= 0xfff0,
+ .name = BCM5461,
+ .features = MII_GBIT_FEATURES,
+ .magic_aneg = 1,
+ .ops= bcm5461_phy_ops
+};
+
/* Broadcom BCM 5462 built-in Vesta */
static struct mii_phy_ops bcm5462V_phy_ops = {
.init = bcm5421_init,
@@ -856,6 +900,7 @@ static struct mii_phy_def* mii_phy_table
bcm5411_phy_def,
bcm5421_phy_def,
bcm5421k2_phy_def,
+ bcm5461_phy_def,
bcm5462V_phy_def,
marvell_phy_def,
genmii_phy_def,
Index: linux-2.6.16/drivers/net/spider_net.c
===
--- linux-2.6.16.orig/drivers/net/spider_net.c
+++ linux-2.6.16/drivers/net/spider_net.c
@@ -1792,16 +1792,8 @@ spider_net_setup_phy(struct spider_net_c
if (phy-def-ops-setup_forced)
phy-def-ops-setup_forced(phy, SPEED_1000, DUPLEX_FULL);
- /* the following two writes could be moved to sungem_phy.c */
- /* enable fiber mode */
- spider_net_write_phy(card-netdev, 1, MII_NCONFIG, 0x9020);
- /* LEDs active in both modes, autosense prio = fiber */
- spider_net_write_phy(card-netdev, 1, MII_NCONFIG, 0x945f);
-
- /* switch off fibre autoneg */
- spider_net_write_phy(card-netdev, 1, MII_NCONFIG, 0xfc01);
- spider_net_write_phy(card-netdev, 1, 0x0b, 0x0004);
-
+ phy-def-ops-enable_fiber(phy);
+
phy-def-ops-read_link(phy);
pr_info(Found %s with %i Mbps, %s-duplex.\n, phy-def-name,
phy-speed, phy-duplex==1 ? Full : Half);
Index: linux-2.6.16/drivers/net/sungem_phy.h
===
--- linux-2.6.16.orig/drivers/net/sungem_phy.h
+++ linux-2.6.16/drivers/net/sungem_phy.h
@@ -12,6 +12,7 @@ struct mii_phy_ops
int (*setup_forced)(struct mii_phy *phy, int speed, int fd);
int (*poll_link)(struct mii_phy *phy);
int (*read_link)(struct mii_phy *phy);
+ int (*enable_fiber)(struct mii_phy *phy);
};
/* Structure used to statically define an mii/gii based PHY */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
hostap on linux2.6
Hi, I was compiling a new kernel to test some of the new IPW stuff in kernel, but looks like hostap is also, not compiling so far. I didn't wanted to bother people by addling LKML. CC [M] drivers/net/wireless/hostap/hostap_80211_rx.o drivers/net/wireless/hostap/hostap_80211_rx.c:2:33: error: net/ieee80211_crypt.h: No such file or directory In file included from drivers/net/wireless/hostap/hostap_80211_rx.c:4: drivers/net/wireless/hostap/hostap_80211.h:96: warning: struct ieee80211_crypt_data declared inside parameter list drivers/net/wireless/hostap/hostap_80211.h:96: warning: its scope is only this definition or declaration, which is probably not what you want In file included from drivers/net/wireless/hostap/hostap.h:7, from drivers/net/wireless/hostap/hostap_80211_rx.c:5: drivers/net/wireless/hostap/hostap_ap.h:238: warning: struct ieee80211_hdr_4addr declared inside parameter list drivers/net/wireless/hostap/hostap_ap.h:248: warning: struct ieee80211_hdr_4addr declared inside parameter list drivers/net/wireless/hostap/hostap_ap.h:253: warning: struct ieee80211_hdr_4addr declared inside parameter list drivers/net/wireless/hostap/hostap_80211_rx.c: In function hostap_dump_rx_80211: drivers/net/wireless/hostap/hostap_80211_rx.c:33: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:35: warning: implicit declaration of function WLAN_FC_GET_TYPE drivers/net/wireless/hostap/hostap_80211_rx.c:35: warning: implicit declaration of function WLAN_FC_GET_STYPE drivers/net/wireless/hostap/hostap_80211_rx.c:36: error: IEEE80211_FCTL_TODS undeclared (first use in this function) drivers/net/wireless/hostap/hostap_80211_rx.c:36: error: (Each undeclared identifier is reported only once drivers/net/wireless/hostap/hostap_80211_rx.c:36: error: for each function it appears in.) drivers/net/wireless/hostap/hostap_80211_rx.c:37: error: IEEE80211_FCTL_FROMDS undeclared (first use in this function) drivers/net/wireless/hostap/hostap_80211_rx.c:44: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:45: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete tdrivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:48: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:50: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:50: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:50: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:50: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:50: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:50: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c: In function prism2_rx_80211: drivers/net/wireless/hostap/hostap_80211_rx.c:71: error: ARPHRD_IEEE80211_PRISM undeclared (first use in this function) drivers/net/wireless/hostap/hostap_80211_rx.c:85: error: dereferencing pointer to incomplete type drivers/net/wireless/hostap/hostap_80211_rx.c:87: error: IEEE80211_FCTL_VERS undeclared (first use in this function) drivers/net/wireless/hostap/hostap_80211_rx.c: At top level: drivers/net/wireless/hostap/hostap_80211_rx.c:229: warning: struct
[PATCH] smc91x: add support for LogicPD PXA270 platform
This patch adds support for the smc91x on the LogicPD PXA270 to the smc91x driver. Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] Index: linux-2.6.16/drivers/net/smc91x.h === --- linux-2.6.16.orig/drivers/net/smc91x.h +++ linux-2.6.16/drivers/net/smc91x.h @@ -129,6 +129,24 @@ #define SMC_insb(a, r, p, l) readsb((a) + (r), p, (l)) #define SMC_outsb(a, r, p, l) writesb((a) + (r), p, (l)) +#elif defined(CONFIG_MACH_LOGICPD_PXA270) + +#define SMC_CAN_USE_8BIT 0 +#define SMC_CAN_USE_16BIT 1 +#define SMC_CAN_USE_32BIT 0 +#define SMC_IO_SHIFT 0 +#define SMC_NOWAIT 1 +#define SMC_USE_PXA_DMA1 + +#define SMC_inb(a, r) readb((a) + (r)) +#define SMC_inw(a, r) readw((a) + (r)) +#define SMC_inl(a, r) readl((a) + (r)) +#define SMC_outb(v, a, r) writeb(v, (a) + (r)) +#define SMC_outw(v, a, r) writew(v, (a) + (r)) +#define SMC_outl(v, a, r) writel(v, (a) + (r)) +#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) +#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l) + #elif defined(CONFIG_ARCH_INNOKOM) || \ defined(CONFIG_MACH_MAINSTONE) || \ defined(CONFIG_ARCH_PXA_IDP) || \ - 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] smc91x: add support for LogicPD PXA270 platform
On Tue, 28 Mar 2006, Lennert Buytenhek wrote: This patch adds support for the smc91x on the LogicPD PXA270 to the smc91x driver. Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] Signed-off-by: Nicolas Pitre [EMAIL PROTECTED] Index: linux-2.6.16/drivers/net/smc91x.h === --- linux-2.6.16.orig/drivers/net/smc91x.h +++ linux-2.6.16/drivers/net/smc91x.h @@ -129,6 +129,24 @@ #define SMC_insb(a, r, p, l) readsb((a) + (r), p, (l)) #define SMC_outsb(a, r, p, l)writesb((a) + (r), p, (l)) +#elifdefined(CONFIG_MACH_LOGICPD_PXA270) + +#define SMC_CAN_USE_8BIT 0 +#define SMC_CAN_USE_16BIT1 +#define SMC_CAN_USE_32BIT0 +#define SMC_IO_SHIFT 0 +#define SMC_NOWAIT 1 +#define SMC_USE_PXA_DMA 1 + +#define SMC_inb(a, r)readb((a) + (r)) +#define SMC_inw(a, r)readw((a) + (r)) +#define SMC_inl(a, r)readl((a) + (r)) +#define SMC_outb(v, a, r)writeb(v, (a) + (r)) +#define SMC_outw(v, a, r)writew(v, (a) + (r)) +#define SMC_outl(v, a, r)writel(v, (a) + (r)) +#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) +#define SMC_outsw(a, r, p, l)writesw((a) + (r), p, l) + #elifdefined(CONFIG_ARCH_INNOKOM) || \ defined(CONFIG_MACH_MAINSTONE) || \ defined(CONFIG_ARCH_PXA_IDP) || \ Nicolas - 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: hostap on linux2.6
On Tue, Mar 28, 2006 at 09:10:38AM -0600, Alejandro Bonilla wrote: Hi, I was compiling a new kernel to test some of the new IPW stuff in kernel, but looks like hostap is also, not compiling so far. I didn't wanted to bother people by addling LKML. CC [M] drivers/net/wireless/hostap/hostap_80211_rx.o drivers/net/wireless/hostap/hostap_80211_rx.c:2:33: error: net/ieee80211_crypt.h: No such file or directory I just pulled from Linus and built drivers/net/wireless/hostap/ -- It works for me! Perhaps you have a bad git clone? 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
Use pci_set_consistent_dma_mask in ixgb driver
The ixgb driver is using pci_alloc_consistent, thus is should also use
pci_set_consistent_dma_mask. This allows the driver to work on SGI
systems.
In case of an error during probing it should also disable the device again.
Signed-off-by: Andreas Schwab [EMAIL PROTECTED]
--- linux-2.6.16/drivers/net/ixgb/ixgb_main.c.~1~ 2006-03-20
06:53:29.0 +0100
+++ linux-2.6.16/drivers/net/ixgb/ixgb_main.c 2006-03-28 18:05:40.0
+0200
@@ -357,18 +357,20 @@ ixgb_probe(struct pci_dev *pdev,
if((err = pci_enable_device(pdev)))
return err;
- if(!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK))) {
+ if(!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK))
+ !(err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK))) {
pci_using_dac = 1;
} else {
- if((err = pci_set_dma_mask(pdev, DMA_32BIT_MASK))) {
+ if((err = pci_set_dma_mask(pdev, DMA_32BIT_MASK)) ||
+ (err = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK))) {
IXGB_ERR(No usable DMA configuration, aborting\n);
- return err;
+ goto err_dma_mask;
}
pci_using_dac = 0;
}
if((err = pci_request_regions(pdev, ixgb_driver_name)))
- return err;
+ goto err_request_regions;
pci_set_master(pdev);
@@ -502,6 +504,9 @@ err_ioremap:
free_netdev(netdev);
err_alloc_etherdev:
pci_release_regions(pdev);
+err_request_regions:
+err_dma_mask:
+ pci_disable_device(pdev);
return err;
}
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
-
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] acenic: fix section mismatches
On Tue, 28 Mar 2006 07:10:30 +0200 Sam Ravnborg wrote: On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote: Nope, only with HOTPLUG enabled. I can try without also (but disabling it is a pain :). ugh, FW_LOADER is the beast (not CONFIG_HOTPLUG itself). Sam, I am now seeing this error (not a WARNING like the previous ones were): Can you send me your .config. Tried but did not manage to get rid of FW_LOADER. OK - did not try hard though. I took a simple way out, disabling large sections of drivers, like all USB, all IEEE1394, etc. It's attached. --- ~Randy config-nothotplug Description: Binary data
kernel: BUG: soft lockup detected on CPU#0!
Greetings friends,
I have been experiencing a number of networking issues with three new
machines I have purchased. They are Dell SC1425 machines, each with two
64-bit processors. I have attached the dmesg log to this email for your
review.
The symptom is simply that every once and a while the machine appears to
go off line. I can ping it and it responds, but I cannot SSH into it or
generally get any other type of network access to it. This happened a
few times and so I turned kernel logging on in the hopes that I could
catch some debugging information. Here's what I found this morning
(after the machine went down). In order to restart the machine I had to
pull the plug. It would not respond to the three-fingered salute or to
the power button.
Mar 28 07:52:39 xenon kernel: SELinux: initialized (dev smbfs, type smbfs),
uses genfs_contexts
Mar 28 07:54:54 xenon kernel: SELinux: initialized (dev smbfs, type smbfs),
uses genfs_contexts
Mar 28 07:55:33 xenon kernel: smb_receive_header: long packet: 65648
Mar 28 07:56:03 xenon kernel: smb_add_request: request [81003c1e2380,
mid=1114] timed out!
Mar 28 07:56:03 xenon kernel: smb_lookup: find 625/b5aa7496-PICT0324_prv.jpg
failed, error=-5
Mar 28 07:56:04 xenon kernel: smb_add_request: request [81003c1e2200,
mid=1115] timed out!
Mar 28 07:56:08 xenon kernel: smb_add_request: request [81003c1e2080,
mid=1116] timed out!
Mar 28 07:56:33 xenon kernel: smb_add_request: request [81003c1e2380,
mid=1117] timed out!
Mar 28 07:56:33 xenon kernel: smb_add_request: request [81003c1e2500,
mid=1118] timed out!
Mar 28 07:56:33 xenon kernel: smb_lookup: find 625/6d537496-PICT0322
copy_prv.jpg failed, error=-5
Mar 28 07:56:38 xenon kernel: smb_add_request: request [81003c1e2080,
mid=1119] timed out!
Mar 28 07:57:03 xenon kernel: smb_add_request: request [81003c1e2380,
mid=1120] timed out!
Mar 28 07:57:03 xenon kernel: smb_add_request: request [81003c1e2200,
mid=1121] timed out!
Mar 28 07:57:03 xenon kernel: smb_lookup: find 625/6ec17396-PICT0306
copy_prv.jpg failed, error=-5
Mar 28 07:57:03 xenon kernel: smb_add_request: request [81003c1e2500,
mid=1122] timed out!
Mar 28 07:57:23 xenon kernel: smb_add_request: request [81003c1e2e00,
mid=1123] timed out!
Mar 28 07:57:33 xenon kernel: smb_add_request: request [81003c1e2380,
mid=1124] timed out!
Mar 28 07:57:33 xenon kernel: smb_add_request: request [81003c1e2b00,
mid=1125] timed out!
Mar 28 07:57:33 xenon kernel: smb_lookup: find 625/14537396-PICT0289
copy_prv.jpg failed, error=-5
Mar 28 07:57:33 xenon kernel: smb_add_request: request [81003c1e2200,
mid=1126] timed out!
Mar 28 07:57:53 xenon kernel: smb_add_request: request [81003c1e2e00,
mid=1127] timed out!
Mar 28 07:58:03 xenon kernel: smb_add_request: request [81003c1e2380,
mid=1128] timed out!
Mar 28 07:58:03 xenon kernel: smb_add_request: request [81003c1e2680,
mid=1129] timed out!
Mar 28 07:58:03 xenon kernel: smb_lookup: find 625/a6c37296-PICT0288
copy_prv.jpg failed, error=-5
Mar 28 08:10:07 xenon kernel: BUG: soft lockup detected on CPU#0!
Mar 28 08:10:07 xenon kernel:
Mar 28 08:10:07 xenon kernel: Modules linked in: smbfs md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core rfcomm l2cap bluetooth sunrpc pcmcia yenta_socket rsrc_nonstatic pcmcia_core video button battery ac uhci_hcd ehci_hcd shpchp e1000 dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata sd_mod scsi_mod
Mar 28 08:10:07 xenon kernel: Pid: 2601, comm: smbiod Not tainted
2.6.11-1.1369_FC4
Mar 28 08:10:07 xenon kernel: RIP: 0010:[80349754]
80349754{skb_copy_datagram_iovec+52}
Mar 28 08:10:07 xenon kernel: RSP: 0018:810073219b58 EFLAGS: 0206
Mar 28 08:10:07 xenon kernel: RAX: 810073219e08 RBX: 0003 RCX:
Mar 28 08:10:07 xenon kernel: RDX: 810073219e48 RSI: 00c5 RDI:
81005ddbb380
Mar 28 08:10:07 xenon kernel: RBP: 00c5 R08: R09:
4000
Mar 28 08:10:07 xenon kernel: R10: 804cc7e0 R11: 0048 R12:
00c8
Mar 28 08:18:10 xenon kernel: R13: 810064a72160 R14: 00c5 R15:
Mar 28 08:18:10 xenon kernel: FS: 2adfc6e0()
GS:80576c00() knlGS:
Mar 28 08:18:10 xenon kernel: CS: 0010 DS: ES: CR0: 8005003b
Mar 28 08:22:11 xenon kernel: CR2: 2aaac000 CR3: 3e11c000 CR4:
06e0
Mar 28 08:22:11 xenon kernel:
Mar 28 08:22:11 xenon kernel: Call Trace:8037a148{tcp_recvmsg+1320} 80343df3{sock_common_recvmsg+51}
Mar 28 08:22:11 xenon kernel:80343210{sock_recvmsg+304}
8015cad0{autoremove_wake_function+0}
Mar 28 08:22:11 xenon kernel:8034468f{lock_sock+783}
803439fb{kernel_recvmsg+59}
Mar 28 08:22:11 xenon kernel:8821face{:smbfs:smb_receive_drop+158}
Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
On 3/16/06, Kumar Gala [EMAIL PROTECTED] wrote: It would seem that when a client registers (or shortly there after when they call dma_async_client_chan_request()) they would expect to get the number of channels they need by some given time period. For example, lets say a client registers but no dma device exists. They will never get called to be aware of this condition. I would think most clients would either spin until they have all the channels they need or fall back to a non-async mechanism. Clients *are* expected to fall back to non-async if they are not given channels. The reason it was implemented with callbacks for added/removed was that the client may be initializing before the channels are enumerated. For example, the net subsystem will ask for channels and not get them for a while, until the ioatdma PCI device is found and its driver loads. In this scenario, we'd like the net subsystem to be given these channels, instead of them going unused. Also, what do you think about adding an operation type (MEMCPY, XOR, CRYPTO_AES, etc). We can than validate if the operation type expected is supported by the devices that exist. No objections, but this speculative support doesn't need to be in our initial patchset. Shouldn't we also have a dma_async_client_chan_free()? Well we could just define it to be chan_request(0) but it doesn't seem to be needed. Also, the allocation mechanism we have for channels is different from alloc/free's semantics, so it may be best to not muddy the water in this area. Regards -- Andy - 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/8] [I/OAT] DMA memcpy subsystem
On Mar 28, 2006, at 12:44 PM, Andrew Grover wrote: On 3/16/06, Kumar Gala [EMAIL PROTECTED] wrote: It would seem that when a client registers (or shortly there after when they call dma_async_client_chan_request()) they would expect to get the number of channels they need by some given time period. For example, lets say a client registers but no dma device exists. They will never get called to be aware of this condition. I would think most clients would either spin until they have all the channels they need or fall back to a non-async mechanism. Clients *are* expected to fall back to non-async if they are not given channels. The reason it was implemented with callbacks for added/removed was that the client may be initializing before the channels are enumerated. For example, the net subsystem will ask for channels and not get them for a while, until the ioatdma PCI device is found and its driver loads. In this scenario, we'd like the net subsystem to be given these channels, instead of them going unused. Fair, I need to think on that a little more. Also, what do you think about adding an operation type (MEMCPY, XOR, CRYPTO_AES, etc). We can than validate if the operation type expected is supported by the devices that exist. No objections, but this speculative support doesn't need to be in our initial patchset. I don't consider it speculative. The patch is for a generic DMA engine interface. That interface should encompass all users. I have a security/crypto DMA engine that I'd like to front with the generic DMA interface today. Also, I believe there is another Intel group with an XOR engine that had a similar concept called ADMA posted a while ago. http://marc.theaimsgroup.com/?t=11260312014r=1w=2 Shouldn't we also have a dma_async_client_chan_free()? Well we could just define it to be chan_request(0) but it doesn't seem to be needed. Also, the allocation mechanism we have for channels is different from alloc/free's semantics, so it may be best to not muddy the water in this area. Can you explain what the semantics are. It's been a little while since I posted so my thoughts on the subject are going to take a little while to come back to me :) - kumar - 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] minor typo fix on RFC3465 comment
signed off by speattle ~~~ tcp_cong_typo_patch Description: 3914340511-tcp_cong_typo_patch
Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
On 3/28/06, Kumar Gala [EMAIL PROTECTED] wrote: Also, what do you think about adding an operation type (MEMCPY, XOR, CRYPTO_AES, etc). We can than validate if the operation type expected is supported by the devices that exist. No objections, but this speculative support doesn't need to be in our initial patchset. I don't consider it speculative. The patch is for a generic DMA engine interface. That interface should encompass all users. I have a security/crypto DMA engine that I'd like to front with the generic DMA interface today. Also, I believe there is another Intel group with an XOR engine that had a similar concept called ADMA posted a while ago. Please submit patches then. We will be doing another rev of the I/OAT patch very soon, which you will be able to patch against. Or, once the patch gets in mainline then we can enhance it. Code in the Linux kernel is never done, and the burden of implementing additional functionality falls on those who want it. Can you explain what the semantics are. It's been a little while since I posted so my thoughts on the subject are going to take a little while to come back to me :) Yeah. Basically you register as a DMA client, and say how many DMA channels you want. Our net_dma patch for example uses multiple channels to help lock contention. Then when channels are available (i.e. a DMA device added or another client gives them up) then you get a callback. If the channel goes away (i.e. DMA device is removed (theoretically possible but practically never happens) or *you* are going away and change your request to 0 channels) then you get a remove callback. This gets around the problem of DMA clients registering (and therefore not getting) channels simply because they init before the DMA device is discovered. Regards -- Andy - 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] Janitor: drivers/net/pcnet32: fix incorrect comments
Please sign-off/ack/apply and/or forward upstream.
[PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
The comments concerning how the pcnet32 ethernet device driver selects
the MAC addr to use are incorrect. A recent patch (in the last 3 months)
changed how the code worked, but did not change the comments.
Side comment: the new behaviour is good; I've got a pcnet32 card which
powers up with garbage in the CSR's, and a good MAC addr in the PROM.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/pcnet32.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.16-git6/drivers/net/pcnet32.c
===
--- linux-2.6.16-git6.orig/drivers/net/pcnet32.c2006-03-23
12:21:41.0 -0600
+++ linux-2.6.16-git6/drivers/net/pcnet32.c 2006-03-28 16:08:23.398158717
-0600
@@ -1167,8 +1167,8 @@ pcnet32_probe1(unsigned long ioaddr, int
* station address PROM at the base address and programmed into the
* Physical Address Registers CSR12-14.
* As a precautionary measure, we read the PROM values and complain if
-* they disagree with the CSRs. Either way, we use the CSR values, and
-* double check that they are valid.
+* they disagree with the CSRs. If they miscompare, and the PROM addr
+* is valid, then the PROM addr is used.
*/
for (i = 0; i 3; i++) {
unsigned int 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: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
On Mar 28, 2006, at 4:01 PM, Andrew Grover wrote: On 3/28/06, Kumar Gala [EMAIL PROTECTED] wrote: Also, what do you think about adding an operation type (MEMCPY, XOR, CRYPTO_AES, etc). We can than validate if the operation type expected is supported by the devices that exist. No objections, but this speculative support doesn't need to be in our initial patchset. I don't consider it speculative. The patch is for a generic DMA engine interface. That interface should encompass all users. I have a security/crypto DMA engine that I'd like to front with the generic DMA interface today. Also, I believe there is another Intel group with an XOR engine that had a similar concept called ADMA posted a while ago. Please submit patches then. We will be doing another rev of the I/OAT patch very soon, which you will be able to patch against. Or, once the patch gets in mainline then we can enhance it. Code in the Linux kernel is never done, and the burden of implementing additional functionality falls on those who want it. I completely understand that. However, I think putting something into mainline that only works or solves the particular problem you have is a bad idea. I'll provide patches for the changes I'd like to see. However, I figured a little discussion on the subject before I went off an spent time on it was worth while. Can you explain what the semantics are. It's been a little while since I posted so my thoughts on the subject are going to take a little while to come back to me :) Yeah. Basically you register as a DMA client, and say how many DMA channels you want. Our net_dma patch for example uses multiple channels to help lock contention. Then when channels are available (i.e. a DMA device added or another client gives them up) then you get a callback. If the channel goes away (i.e. DMA device is removed (theoretically possible but practically never happens) or *you* are going away and change your request to 0 channels) then you get a remove callback. Do you only get callback when a channel is available? How do you decide to do to provide PIO to the client? A client should only request multiple channel to handle multiple concurrent operations. This gets around the problem of DMA clients registering (and therefore not getting) channels simply because they init before the DMA device is discovered. What do you expect to happen in a system in which the channels are over subscribed? Do you expect the DMA device driver to handle scheduling of channels between multiple clients? - kumar - 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] minor typo fix on RFC3465 comment
From: S P [EMAIL PROTECTED] Date: Tue, 28 Mar 2006 11:53:01 -0800 (PST) signed off by speattle ~~~ 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
[Fwd: [Bug 6295] New: unregister_netdevice loops indefinitely when bringing down an interface if static ARP entries are present]
---BeginMessage--- http://bugzilla.kernel.org/show_bug.cgi?id=6295 Summary: unregister_netdevice loops indefinitely when bringing down an interface if static ARP entries are present Kernel Version: 2.6.16 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.6.8 Distribution: Debian unstable, bug reproduced with vanilla kernel from kernel.org Problem Description: When using a VPN client, such as openvpn or gvpe, killing the client (which should result in bringing down of the VPN interface) deadlocks it in D+ state, if static ARP entries are present for the interface. Kernel periodically emits messages unregister_netdevice: waiting for interface to become free. Usage count = 1. The usage count number is equal to the number of the static ARP entries. Thanks a lot to Marc Lehmann for patient debugging of this problem and constructing the test case. Steps to reproduce (using openvpn, all mentioned addresses are non-existent): # modprobe tun # openvpn --remote 192.168.1.111 --dev tun1 --ifconfig 10.0.0.1 10.0.0.2 In another console: # ip neigh add to 10.0.0.3 dev tun1 nud permanent Return to the console in which openvpn is running and press Ctrl-C. The openvpn process hangs in D+ state (can't be killed), error messages mentioned above are periodically produced on the console. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ---End Message---
