Re: [BUG] RTNL and flush_scheduled_work deadlocks
On Thu, Feb 15, 2007 at 11:40:32PM -0800, Ben Greear wrote: ... Maybe there should be something like an ASSERT_NOT_RTNL() in the flush_scheduled_work() method? If it's performance criticial, #ifdef it out if we're not debugging locks? Yes! I thought about the same (at first). But in my opinion it was not enough, so I thought about doing this in flush_workqueue. But in my next opinion it was not enough too. Now I think something like this should be done in rtnl_lock (under some debugging #if of course). Cheers, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] RTNL and flush_scheduled_work deadlocks
Jarek Poplawski wrote: On Thu, Feb 15, 2007 at 11:40:32PM -0800, Ben Greear wrote: ... Maybe there should be something like an ASSERT_NOT_RTNL() in the flush_scheduled_work() method? If it's performance criticial, #ifdef it out if we're not debugging locks? Yes! I thought about the same (at first). But in my opinion it was not enough, so I thought about doing this in flush_workqueue. But in my next opinion it was not enough too. Now I think something like this should be done in rtnl_lock (under some debugging #if of course). The reason these bugs have been hidden is that most of the time, there is nothing on the pending work queue that will try to grab RTNL. But, the flush_work_queue is still called with RTNL held, so an assert would find this much earlier than waiting for someone to get lucky and actually catch (and debug and report) a deadlock... I don't see how asserting it in the rtnl_lock would help anything, because at that point we are about to deadlock anyway... (and this is probably very rare, as mentioned above.) Thanks, Ben Cheers, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.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: [BUG] RTNL and flush_scheduled_work deadlocks
On Fri, Feb 16, 2007 at 12:23:05AM -0800, Ben Greear wrote: Jarek Poplawski wrote: On Thu, Feb 15, 2007 at 11:40:32PM -0800, Ben Greear wrote: ... Maybe there should be something like an ASSERT_NOT_RTNL() in the flush_scheduled_work() method? If it's performance criticial, #ifdef it out if we're not debugging locks? Yes! I thought about the same (at first). But in my opinion it was not enough, so I thought about doing this in flush_workqueue. But in my next opinion it was not enough too. Now I think something like this should be done in rtnl_lock (under some debugging #if of course). The reason these bugs have been hidden is that most of the time, there is nothing on the pending work queue that will try to grab RTNL. But, the flush_work_queue is still called with RTNL held, so an assert would find this much earlier than waiting for someone to get lucky and actually catch (and debug and report) a deadlock... Yes. Regarding this, you are right - it should be better. But, anyway cancel_rearming... is equally dangerous, so there is a question where: in all places where used, in workqueue.c or maybe make it semi obligatory in networking and add some net wrappers e.g.: net_flush_work_queue and net_cancel_rearmnig with this ASSERT_NO_RTNL? I don't see how asserting it in the rtnl_lock would help anything, because at that point we are about to deadlock anyway... (and this is probably very rare, as mentioned above.) But it's happening now. Probably lockdep is not enough and rtnl_lock is probably used in too many places, so I meant some additional checks would be possible. I wrote something like this and mean some check if we have this lock already before trying to get it again. But maybe it's really too much and your proposal is sufficient for this. Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2 bonding problem, 802.3ad
Jay Vosburgh [EMAIL PROTECTED] writes: The log you included (with debug turned on) indicates that bonding is at least attempting to send LACPDUs, but there are no log entries for having received any LACPDUs. Yes, the log clearly shows that the LACPDUs are sent, at least bonding thinks so. I just checked for received mcast packages on the switch: yes, they come in frequently on all four ports. Though I can't check or Slow_Protocols_Multicast address specifically. If the switch is configured, you may want to also check to see if it has counters for LACPDUs sent and received. If the switch is not sending and receiving LACPDUs on the appropriate ports, then it's more likely to be a communications problem somewhere (vs. an 802.3ad negotiation problem). I did not find a dedicated stat for received LACPDUs. I tried some settings on the switch webinterface. Interesting: if I toggle the 'Admin Flow Control' from either 'enabled' to 'autonegotiation' I immediately receive the switch LACPCUs, see: bonding: ad_tx_machine() 1210: Sent LACPDU on port 1 bonding: bond_3ad_rx_indication() 2175: Received LACPDU on port 1 bonding: ad_rx_machine() 1123: Rx Machine: Port=1, Last State=6, Curr State=6 If I then disable the bond (rmmod inclusive) and then enable the bond again there are no received LACPDUs from the switch. Mmmpff... For the version of bonding in your dmesg log, the IFF_NOARP is expected; 802.3ad will select one aggregator as the active one, the other aggregators will be marked inactive, and that sets IFF_NOARP. Since no LACPDUs have been exchanged, bonding is leaving each interface as a separate aggregator. Versions of bonding later than February 2006 (your proc-bond0-ok for example) don't set the IFF_NOARP on inactive slaves (a new mechanism is used that doesn't mess with the flags). Yes, I already saw in the code that IFF_NOARP was expected. Any ideas? /holger - 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: [Sk-drivers] sky2 bonding problem, 802.3ad
Holger Eitzenberger [EMAIL PROTECTED] writes: bonding: ad_tx_machine() 1210: Sent LACPDU on port 1 bonding: bond_3ad_rx_indication() 2175: Received LACPDU on port 1 bonding: ad_rx_machine() 1123: Rx Machine: Port=1, Last State=6, Curr State=6 One important point I forgot about in my previous post: the host receives LACPDUs, but still the bond does not work. Also note that the other e1000 bond works happily: it is in fact the link which I use to configure it currently (via telnet). /holger - 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 1/2] atm: Use ARRAY_SIZE macro when appropriate
From: Ahmed S. Darwish [EMAIL PROTECTED]
Use ARRAY_SIZE macro already defined in kernel.h for ATM
drivers.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: chas williams [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/atm/he.c |2 +-
drivers/atm/idt77252.c |8
drivers/atm/nicstarmac.c |4 +++-
3 files changed, 8 insertions(+), 6 deletions(-)
diff -puN drivers/atm/he.c~atm-use-array_size-macro-when-appropriate
drivers/atm/he.c
--- a/drivers/atm/he.c~atm-use-array_size-macro-when-appropriate
+++ a/drivers/atm/he.c
@@ -3017,7 +3017,7 @@ read_prom_byte(struct he_dev *he_dev, in
he_writel(he_dev, val, HOST_CNTL);
/* Send READ instruction */
- for (i = 0; i sizeof(readtab)/sizeof(readtab[0]); i++) {
+ for (i = 0; i ARRAY_SIZE(readtab); i++) {
he_writel(he_dev, val | readtab[i], HOST_CNTL);
udelay(EEPROM_DELAY);
}
diff -puN drivers/atm/idt77252.c~atm-use-array_size-macro-when-appropriate
drivers/atm/idt77252.c
--- a/drivers/atm/idt77252.c~atm-use-array_size-macro-when-appropriate
+++ a/drivers/atm/idt77252.c
@@ -388,7 +388,7 @@ idt77252_eeprom_read_status(struct idt77
gp = idt77252_read_gp(card) ~(SAR_GP_EESCLK|SAR_GP_EECS|SAR_GP_EEDO);
- for (i = 0; i sizeof(rdsrtab)/sizeof(rdsrtab[0]); i++) {
+ for (i = 0; i ARRAY_SIZE(rdsrtab); i++) {
idt77252_write_gp(card, gp | rdsrtab[i]);
udelay(5);
}
@@ -422,7 +422,7 @@ idt77252_eeprom_read_byte(struct idt7725
gp = idt77252_read_gp(card) ~(SAR_GP_EESCLK|SAR_GP_EECS|SAR_GP_EEDO);
- for (i = 0; i sizeof(rdtab)/sizeof(rdtab[0]); i++) {
+ for (i = 0; i ARRAY_SIZE(rdtab); i++) {
idt77252_write_gp(card, gp | rdtab[i]);
udelay(5);
}
@@ -469,14 +469,14 @@ idt77252_eeprom_write_byte(struct idt772
gp = idt77252_read_gp(card) ~(SAR_GP_EESCLK|SAR_GP_EECS|SAR_GP_EEDO);
- for (i = 0; i sizeof(wrentab)/sizeof(wrentab[0]); i++) {
+ for (i = 0; i ARRAY_SIZE(wrentab); i++) {
idt77252_write_gp(card, gp | wrentab[i]);
udelay(5);
}
idt77252_write_gp(card, gp | SAR_GP_EECS);
udelay(5);
- for (i = 0; i sizeof(wrtab)/sizeof(wrtab[0]); i++) {
+ for (i = 0; i ARRAY_SIZE(wrtab); i++) {
idt77252_write_gp(card, gp | wrtab[i]);
udelay(5);
}
diff -puN drivers/atm/nicstarmac.c~atm-use-array_size-macro-when-appropriate
drivers/atm/nicstarmac.c
--- a/drivers/atm/nicstarmac.c~atm-use-array_size-macro-when-appropriate
+++ a/drivers/atm/nicstarmac.c
@@ -7,6 +7,8 @@
* Read this ForeRunner's MAC address from eprom/eeprom
*/
+#include linux/kernel.h
+
typedef void __iomem *virt_addr_t;
#define CYCLE_DELAY 5
@@ -176,7 +178,7 @@ read_eprom_byte(virt_addr_t base, u_int8
val = NICSTAR_REG_READ( base, NICSTAR_REG_GENERAL_PURPOSE ) 0xFFF0;
/* Send READ instruction */
- for (i=0; isizeof readtab/sizeof readtab[0]; i++)
+ for (i=0; iARRAY_SIZE(readtab); i++)
{
NICSTAR_REG_WRITE( base, NICSTAR_REG_GENERAL_PURPOSE,
(val | readtab[i]) );
_
-
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/2] bugfixes and new hardware support for arcnet driver
From: Jeff Morrow [EMAIL PROTECTED]
The modifications and bug fixes noted below were done by Realtime Control
Works and Contemporary Control Systems, Inc, Jan 2005. They were
incorporated into the 2.6 kernel by Jeff Morrow of Sierra Analytics, Feb
2007. [EMAIL PROTECTED]
The changes have been tested on a Contemporary Controls PCI20U-4000.
Summary of changes:
Arc-rawmode.c:
rx():
- Fixed error in received packet lengths; 256 byte packets were
being received as 257 bytes packets.
prepare_tx():
- Fixed error in transmit length calcs; 257 byte packets were being
transmitted as 260 byte packets.
com20020.c:
com20020_check():
- We now load the SETUP2 register if the 'clockm' parameter is
non-zero, instead of checking for ARC_CAN_10MBIT. The user is
now responsible for whether or not SETUP2 is loaded. If the
clock multiplier is non-zero, this means that the user wants a
baud rate greater than 2.5Mbps. This is not possible unless the
SETUP2 register is present (COM20020D, or COM20022). So, we're
relying on the user to be smart about what kind of chip he's
dealing with...
com20020-pci.c
- Added several entries to com20020pci_id_table[].
Signed-off-by: Jeff Morrow [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/arcnet/arc-rawmode.c |4 ++--
drivers/net/arcnet/arcnet.c |2 +-
drivers/net/arcnet/com20020-pci.c |3 +++
drivers/net/arcnet/com20020.c |2 +-
4 files changed, 7 insertions(+), 4 deletions(-)
diff -puN
drivers/net/arcnet/arcnet.c~bugfixes-and-new-hardware-support-for-arcnet-driver
drivers/net/arcnet/arcnet.c
---
a/drivers/net/arcnet/arcnet.c~bugfixes-and-new-hardware-support-for-arcnet-driver
+++ a/drivers/net/arcnet/arcnet.c
@@ -41,7 +41,7 @@
* [EMAIL PROTECTED]
*/
-#define VERSION arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.\n
+#define VERSION arcnet: v3.94 BETA 2007/02/08 - by Avery Pennarun et al.\n
#include linux/module.h
#include linux/types.h
diff -puN
drivers/net/arcnet/arc-rawmode.c~bugfixes-and-new-hardware-support-for-arcnet-driver
drivers/net/arcnet/arc-rawmode.c
---
a/drivers/net/arcnet/arc-rawmode.c~bugfixes-and-new-hardware-support-for-arcnet-driver
+++ a/drivers/net/arcnet/arc-rawmode.c
@@ -94,7 +94,7 @@ static void rx(struct net_device *dev, i
BUGMSG(D_DURING, it's a raw packet (length=%d)\n, length);
- if (length = MinTU)
+ if (length MTU)
ofs = 512 - length;
else
ofs = 256 - length;
@@ -183,7 +183,7 @@ static int prepare_tx(struct net_device
length, XMTU);
length = XMTU;
}
- if (length MinTU) {
+ if (length = MinTU) {
hard-offset[0] = 0;
hard-offset[1] = ofs = 512 - length;
} else if (length MTU) {
diff -puN
drivers/net/arcnet/com20020.c~bugfixes-and-new-hardware-support-for-arcnet-driver
drivers/net/arcnet/com20020.c
---
a/drivers/net/arcnet/com20020.c~bugfixes-and-new-hardware-support-for-arcnet-driver
+++ a/drivers/net/arcnet/com20020.c
@@ -104,7 +104,7 @@ int com20020_check(struct net_device *de
SET_SUBADR(SUB_SETUP1);
outb(lp-setup, _XREG);
- if (lp-card_flags ARC_CAN_10MBIT)
+ if (lp-clockm != 0)
{
SET_SUBADR(SUB_SETUP2);
outb(lp-setup2, _XREG);
diff -puN
drivers/net/arcnet/com20020-pci.c~bugfixes-and-new-hardware-support-for-arcnet-driver
drivers/net/arcnet/com20020-pci.c
---
a/drivers/net/arcnet/com20020-pci.c~bugfixes-and-new-hardware-support-for-arcnet-driver
+++ a/drivers/net/arcnet/com20020-pci.c
@@ -155,6 +155,7 @@ static struct pci_device_id com20020pci_
{ 0x1571, 0xa00b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_IS_5MBIT },
{ 0x1571, 0xa00c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_IS_5MBIT },
{ 0x1571, 0xa00d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_IS_5MBIT },
+ { 0x1571, 0xa00e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_IS_5MBIT },
{ 0x1571, 0xa201, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x1571, 0xa202, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x1571, 0xa203, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
@@ -163,6 +164,8 @@ static struct pci_device_id com20020pci_
{ 0x1571, 0xa206, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x10B5, 0x9030, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{ 0x10B5, 0x9050, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
+ { 0x14BA, 0x6000, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
+ { 0x10B5, 0x2200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ARC_CAN_10MBIT },
{0,}
};
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH] dm9000: do not kfree() netdevice
On Mon, Feb 12, 2007 at 12:05:39PM +, Ben Dooks wrote: The DM9000 network driver is calling kfree() on an netdev causing the system to oops if the probe fails. The right thing to do is call free_netdev(). Thanks to Russell King for spotting this. Signed-off-by: Ben Dooks [EMAIL PROTECTED] diff -urpN -X ../dontdiff linux-2.6.20/drivers/net/dm9000.c linux-2.6.20-dmfix/drivers/net/dm9000.c --- linux-2.6.20/drivers/net/dm9000.c 2007-02-04 18:44:54.0 + +++ linux-2.6.20-dmfix/drivers/net/dm9000.c 2007-02-12 12:01:22.0 + @@ -601,7 +601,7 @@ dm9000_probe(struct platform_device *pde printk(%s: not found (%d).\n, CARDNAME, ret); dm9000_release_board(pdev, db); - kfree(ndev); + free_netdev(ndev); return ret; } @@ -1194,7 +1194,7 @@ dm9000_drv_remove(struct platform_device unregister_netdev(ndev); dm9000_release_board(pdev, (board_info_t *) ndev-priv); - kfree(ndev);/* free device structure */ + free_netdev(ndev); /* free device structure */ PRINTK1(clean_module() exit\n); Do I need to send this patch to a particual person to ensure that it gets included into the kernel? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - 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
acenic swallowing 802.1q tag when kernel compiled with VLAN support
Hi, i discovered that once the kernel is compiled 802.1Q VLAN Support the acenic driver swallows the 802.1q header in promiscous mode. I am tracing an gigabit ethernet with 802.1q in 802.1q so i would usually see 2 802.1q VLAN header. When compiling with VLAN aka 802.1q support the first or outer vlan header disappears from the traces even though the vlan support kernel module is not loaded nor vlans activated on the link. Card i am using: :06:02.0 Ethernet controller: 3Com Corporation 3c985 1000BaseSX (SX/TX) (rev 01) Subsystem: Unknown device 9850:0001 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (16000ns min), Cache Line Size: 0x10 (64 bytes) Interrupt: pin A routed to IRQ 225 Region 0: Memory at fdff (32-bit, non-prefetchable) [size=16K] dmesg output: acenic.c: v0.92 08/05/2002 Jes Sorensen, [EMAIL PROTECTED] http://home.cern.ch/~jes/gige/acenic.html ACPI: PCI Interrupt :06:02.0[A] - GSI 78 (level, low) - IRQ 225 :06:02.0: 3Com 3C985 Gigabit Ethernet at 0xfdff, irq 225 Tigon II (Rev. 6), Firmware: 12.4.11, MAC: 00:60:08:f6:f5:4e PCI cache line size set incorrectly (64 bytes) by BIOS/FW, expecting 32 PCI bus width: 64 bits, speed: 66MHz, latency: 64 clks Disabling PCI memory write and invalidate :06:02.0: Firmware up and running Kernel: lnxp-1115:~# uname -a Linux lnxp-1115 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux lnxp-1115:~# egrep CONFIG_ACENIC|CONFIG_VLAN /boot/config-2.6.18-3-686 CONFIG_VLAN_8021Q=m CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set Thats the default Debian Etch kernel. I have seen this behaviour in a couple kernel releases since i started tracing stuff so its not a new bug. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Re: [BUG] RTNL and flush_scheduled_work deadlocks
On Fri, Feb 16, 2007 at 10:04:25AM +0100, Jarek Poplawski wrote: On Fri, Feb 16, 2007 at 12:23:05AM -0800, Ben Greear wrote: ... I don't see how asserting it in the rtnl_lock would help anything, because at that point we are about to deadlock anyway... (and this is probably very rare, as mentioned above.) But it's happening now. Probably lockdep is not enough and rtnl_lock is probably used in too many places, so I meant some additional checks would be possible. And of course it already could be done by DEBUG_MUTEXES or DEBUG_SPINLOCK, so I gone too far and it's really bad idea. Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - drivers/net/hamradio remove local random function, use random32()
On Thu, 2007-02-15 at 19:36 -0800, Joe Perches wrote: remove local random function, use random32() instead Signed-off-by: Joe Perches [EMAIL PROTECTED] Acked-By: Thomas Sailer [EMAIL PROTECTED] There are a bunch of other drivers with their homegrown random number function, namely 6pack.c dmascc.c hdlcdrv.c yam.c. Can you do a patch for those too? Thanks a lot, Tom - 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
[HAMRADIO] Replace local random function with random32()
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
index 153b6dc..84aa211 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -52,6 +52,7 @@
#include linux/hdlcdrv.h
#include linux/baycom.h
#include linux/jiffies.h
+#include linux/random.h
#include net/ax25.h
#include asm/uaccess.h
@@ -433,16 +434,6 @@ static void encode_hdlc(struct baycom_state *bc)
/* -- */
-static unsigned short random_seed;
-
-static inline unsigned short random_num(void)
-{
- random_seed = 28629 * random_seed + 157;
- return random_seed;
-}
-
-/* -- */
-
static int transmit(struct baycom_state *bc, int cnt, unsigned char stat)
{
struct parport *pp = bc-pdev-port;
@@ -464,7 +455,7 @@ static int transmit(struct baycom_state *bc, int cnt,
unsigned char stat)
if ((--bc-hdlctx.slotcnt) 0)
return 0;
bc-hdlctx.slotcnt = bc-ch_params.slottime;
- if ((random_num() % 256) bc-ch_params.ppersist)
+ if ((random32() % 256) bc-ch_params.ppersist)
return 0;
}
}
diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
index 452873e..f5a17ad 100644
--- a/drivers/net/hamradio/hdlcdrv.c
+++ b/drivers/net/hamradio/hdlcdrv.c
@@ -56,6 +56,7 @@
#include linux/if_arp.h
#include linux/skbuff.h
#include linux/hdlcdrv.h
+#include linux/random.h
#include net/ax25.h
#include asm/uaccess.h
@@ -371,16 +372,6 @@ static void start_tx(struct net_device *dev, struct
hdlcdrv_state *s)
/* -- */
-static unsigned short random_seed;
-
-static inline unsigned short random_num(void)
-{
- random_seed = 28629 * random_seed + 157;
- return random_seed;
-}
-
-/* -- */
-
void hdlcdrv_arbitrate(struct net_device *dev, struct hdlcdrv_state *s)
{
if (!s || s-magic != HDLCDRV_MAGIC || s-hdlctx.ptt || !s-skb)
@@ -396,7 +387,7 @@ void hdlcdrv_arbitrate(struct net_device *dev, struct
hdlcdrv_state *s)
if ((--s-hdlctx.slotcnt) 0)
return;
s-hdlctx.slotcnt = s-ch_params.slottime;
- if ((random_num() % 256) s-ch_params.ppersist)
+ if ((random32() % 256) s-ch_params.ppersist)
return;
start_tx(dev, s);
}
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index 6d74f08..efc0bcd 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -50,6 +50,7 @@
#include linux/slab.h
#include linux/errno.h
#include linux/bitops.h
+#include linux/random.h
#include asm/io.h
#include asm/system.h
#include linux/interrupt.h
@@ -566,14 +567,6 @@ static void yam_start_tx(struct net_device *dev, struct
yam_port *yp)
ptt_on(dev);
}
-static unsigned short random_seed;
-
-static inline unsigned short random_num(void)
-{
- random_seed = 28629 * random_seed + 157;
- return random_seed;
-}
-
static void yam_arbitrate(struct net_device *dev)
{
struct yam_port *yp = netdev_priv(dev);
@@ -600,7 +593,7 @@ static void yam_arbitrate(struct net_device *dev)
yp-slotcnt = yp-slot / 10;
/* is random persist ? */
- if ((random_num() % 256) yp-pers)
+ if ((random32() % 256) yp-pers)
return;
yam_start_tx(dev, yp);
-
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: [HAMRADIO] Replace local random function with random32()
On Fri, 2007-02-16 at 11:55 +, Ralf Baechle wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Acked-by: Thomas Sailer [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
[KJ][PATCH] is_power_of_2 in Chelsio
Replacing (n (n-1)) in the context of power of 2 checks with is_power_of_2 diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c index c67f7d3..26ac0bb 100644 --- a/drivers/net/cxgb3/cxgb3_main.c +++ b/drivers/net/cxgb3/cxgb3_main.c @@ -42,6 +42,7 @@ #include linux/workqueue.h #include linux/proc_fs.h #include linux/rtnetlink.h +#include linux/log2.h #include asm/uaccess.h #include common.h @@ -1792,8 +1793,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr) return -EBUSY; if (copy_from_user(m, useraddr, sizeof(m))) return -EFAULT; - if (!m.rx_pg_sz || (m.rx_pg_sz (m.rx_pg_sz - 1)) || - !m.tx_pg_sz || (m.tx_pg_sz (m.tx_pg_sz - 1))) + if (!is_power_of_2(m.rx_pg_sz) || + !is_power_of_2(m.tx_pg_sz)) return -EINVAL; /* not power of 2 */ if (!(m.rx_pg_sz 0x14000)) return -EINVAL; /* not 16KB or 64KB */ -- Regards, Vignesh Babu BM _ Why is it that every time I'm with you, makes me believe in magic? - 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] Convert meth to netdev_priv
And while at it loose plenty of useless casts.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/drivers/net/meth.c b/drivers/net/meth.c
index d38b7c7..7e69ca6 100644
--- a/drivers/net/meth.c
+++ b/drivers/net/meth.c
@@ -170,7 +170,7 @@ static int mdio_probe(struct meth_private *priv)
static void meth_check_link(struct net_device *dev)
{
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
unsigned long mii_advertising = mdio_read(priv, 4);
unsigned long mii_partner = mdio_read(priv, 5);
unsigned long negotiated = mii_advertising mii_partner;
@@ -268,7 +268,7 @@ static void meth_free_rx_ring(struct meth_private *priv)
int meth_reset(struct net_device *dev)
{
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
/* Reset card */
mace-eth.mac_ctrl = SGI_MAC_RESET;
@@ -310,7 +310,7 @@ int meth_reset(struct net_device *dev)
*/
static int meth_open(struct net_device *dev)
{
- struct meth_private *priv = dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
int ret;
priv-phy_addr = -1;/* No PHY is known yet... */
@@ -354,7 +354,7 @@ out_free_tx_ring:
static int meth_release(struct net_device *dev)
{
- struct meth_private *priv = dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
DPRINTK(Stopping queue\n);
netif_stop_queue(dev); /* can't transmit any more */
@@ -376,7 +376,7 @@ static void meth_rx(struct net_device* dev, unsigned long
int_status)
{
struct sk_buff *skb;
unsigned long status;
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
unsigned long fifo_rptr = (int_status METH_INT_RX_RPTR_MASK) 8;
spin_lock(priv-meth_lock);
@@ -466,14 +466,14 @@ static void meth_rx(struct net_device* dev, unsigned long
int_status)
static int meth_tx_full(struct net_device *dev)
{
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
return (priv-tx_count = TX_RING_ENTRIES - 1);
}
static void meth_tx_cleanup(struct net_device* dev, unsigned long int_status)
{
- struct meth_private *priv = dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
unsigned long status;
struct sk_buff *skb;
unsigned long rptr = (int_statusTX_INFO_RPTR) 16;
@@ -536,7 +536,7 @@ static void meth_tx_cleanup(struct net_device* dev,
unsigned long int_status)
static void meth_error(struct net_device* dev, unsigned status)
{
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
printk(KERN_WARNING meth: error status: 0x%08x\n,status);
/* check for errors too... */
@@ -570,7 +570,7 @@ static void meth_error(struct net_device* dev, unsigned
status)
static irqreturn_t meth_interrupt(int irq, void *dev_id)
{
struct net_device *dev = (struct net_device *)dev_id;
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
unsigned long status;
status = mace-eth.int_stat;
@@ -695,7 +695,7 @@ static void meth_add_to_tx_ring(struct meth_private *priv,
struct sk_buff *skb)
*/
static int meth_tx(struct sk_buff *skb, struct net_device *dev)
{
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
unsigned long flags;
spin_lock_irqsave(priv-meth_lock, flags);
@@ -726,7 +726,7 @@ static int meth_tx(struct sk_buff *skb, struct net_device
*dev)
*/
static void meth_tx_timeout(struct net_device *dev)
{
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
unsigned long flags;
printk(KERN_WARNING %s: transmit timed out\n, dev-name);
@@ -778,7 +778,7 @@ static int meth_ioctl(struct net_device *dev, struct ifreq
*rq, int cmd)
*/
static struct net_device_stats *meth_stats(struct net_device *dev)
{
- struct meth_private *priv = (struct meth_private *) dev-priv;
+ struct meth_private *priv = netdev_priv(dev);
return priv-stats;
}
@@ -807,7 +807,7 @@ static struct net_device *meth_init(void)
dev-irq = MACE_ETHERNET_IRQ;
dev-base_addr = (unsigned long)mace-eth;
- priv = (struct meth_private *) dev-priv;
+ priv = netdev_priv(dev);
spin_lock_init(priv-meth_lock);
ret = register_netdev(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
Re: Strange connection slowdown on pcnet32
On Thu, Feb 15, 2007 at 05:50:30PM -0500, Lennart Sorensen wrote: I have encountered a strange behaviour with the pcnet32. I am transfering data from a server to a client routing it through my router. The router has 2 ethernet ports, both of which are amd 972 chips (pcnet32). The transfer has so far been either http or ftp (both see the same problem). I transfer lots of data, and after a while (I have seen anywhere from 200 to 700MB or so) the speed suddenly drops to less than 1KB/s. If I ping from the router to the server, the ping requests go out normally (seen by tcpdump on the server) every second, but on the router the replies are not seen by the kernel for multiple seconds. Sometimes I will see 3 ping replies together, sometimes 5 or even 10. The turn around times will show 10500, 9500, 8500, ..., 500ms for the packets received in a batch. ifconfig on the router shows the packet receive counts showing up in lumps, just as ping does, and tcpdump on the interface on the router. Doing ifconfig down and up on the port connecting to the server makes the problem clear and it can handle another pile of data before the problem reappears. The CPU on the router is not fast enough to ensure there won't ever be dropped packets at 100Mbps. When I force the port to the server to 10Mbps I have no problems at all. Replacing the port to the server with an rtl8139 doesn't show any problems at 100Mbps, although the transfer rate drops from 6500KBps to 4000KBps compared to using the pcnet32. Kernel used so far is 2.6.16 and 2.6.18. I have a tulip card I intend to try with as well just to see if it affects anything other than the pcnet32. Does anyone have any hints as to what part of the code to look at for changes made by doing ifconfig eth1 down; ifconfig eth1 up? Any ideas as to what could make the reception of packets suddenly get very very slow? On one pass where I was running tcpdump on the router, I saw a wrap of the sequence number right before the problem occoured, but that has not been the case every time as far as I can tell, so I am not sure if that is related to the problem at all. I have run some tests using 2.6.8 now, and so far it hasn't failed. Still investigating... -- 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: Strange connection slowdown on pcnet32
On Fri, Feb 16, 2007 at 09:35:54AM -0500, Lennart Sorensen wrote: I have run some tests using 2.6.8 now, and so far it hasn't failed. Still investigating... And 5 minutes later 2.6.8 failed the same way too. Maybe I will go back to 2.4 and check. -- 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
[PATCH] macb: Remove inappropriate spinlocks around mii calls
Remove spin_lock_irqsave() around mii_ethtool_gset, mii_ethtool_sset
and generic_mii_ioctl. These are unnecessary and harmful because
the mii calls may call back into the mdio functions, which may sleep.
Pointed out by David Brownell.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
drivers/net/macb.c | 24 +++-
1 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index a41418b..2e9571b 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -881,27 +881,15 @@ static struct net_device_stats *macb_get_stats(struct
net_device *dev)
static int macb_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct macb *bp = netdev_priv(dev);
- int ret;
- unsigned long flags;
-
- spin_lock_irqsave(bp-lock, flags);
- ret = mii_ethtool_gset(bp-mii, cmd);
- spin_unlock_irqrestore(bp-lock, flags);
- return ret;
+ return mii_ethtool_gset(bp-mii, cmd);
}
static int macb_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct macb *bp = netdev_priv(dev);
- int ret;
- unsigned long flags;
-
- spin_lock_irqsave(bp-lock, flags);
- ret = mii_ethtool_sset(bp-mii, cmd);
- spin_unlock_irqrestore(bp-lock, flags);
- return ret;
+ return mii_ethtool_sset(bp-mii, cmd);
}
static void macb_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo
*info)
@@ -930,17 +918,11 @@ static struct ethtool_ops macb_ethtool_ops = {
static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct macb *bp = netdev_priv(dev);
- int ret;
- unsigned long flags;
if (!netif_running(dev))
return -EINVAL;
- spin_lock_irqsave(bp-lock, flags);
- ret = generic_mii_ioctl(bp-mii, if_mii(rq), cmd, NULL);
- spin_unlock_irqrestore(bp-lock, flags);
-
- return ret;
+ return generic_mii_ioctl(bp-mii, if_mii(rq), cmd, NULL);
}
static ssize_t macb_mii_show(const struct device *_dev, char *buf,
--
1.4.4.4
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [Bug 8013] New: select for write hangs on a socket after write returned ECONNRESET
On Thu, Feb 15, 2007 at 04:04:05PM -0800, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
Someone want to take a stab at fixing this??
Works for me with attached application - select on connreset socket
immediately returns one ready descriptor.
$ ./a.out 192.168.0.48 22
select: err: 1, errno: 0.
write: err: 128, errno: 0.
select: err: 1, errno: 0.
write: err: 128, errno: 0.
select: err: 1, errno: 0.
write: err: -1, errno: 104.
on exit: select: err: 1, errno: 104.
--
Evgeniy Polyakov
#include sys/types.h
#include sys/socket.h
#include sys/resource.h
#include sys/wait.h
#include sys/stat.h
#include sys/time.h
#include sys/poll.h
#include sys/sendfile.h
#include netinet/in.h
#include netinet/tcp.h
#include arpa/inet.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include errno.h
#include string.h
#include fcntl.h
#include time.h
#include ctype.h
#include netdb.h
#define ulog(f, a...) fprintf(stderr, f, ##a)
#define ulog_err(f, a...) ulog(f : %s [%d].\n, ##a, strerror(errno), errno)
int main(int argc, char *argv[])
{
struct hostent *h;
int s, err;
char buf[128];
struct sockaddr_in sa;
fd_set rfds;
struct timeval tv;
if (argc != 3) {
ulog(Usage: %s addr port\n, argv[0]);
return -1;
}
h = gethostbyname(argv[1]);
if (!h) {
ulog_err(%s: Failed to get address of %s.\n, __func__,
argv[1]);
return -1;
}
s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (s == -1) {
ulog_err(%s: Failed to create server socket, __func__);
return -1;
}
memcpy((sa.sin_addr.s_addr), h-h_addr_list[0], 4);
sa.sin_port = htons(atoi(argv[2]));
sa.sin_family = AF_INET;
if (connect(s, (struct sockaddr *)sa, sizeof(sa))) {
ulog_err(%s: Failed to connect to %s:%s, __func__, argv[1],
argv[2]);
return -1;
}
do {
FD_ZERO(rfds);
FD_SET(s, rfds);
tv.tv_sec = 500;
tv.tv_usec = 0;
err = select(s+1, rfds, NULL, NULL, tv);
ulog(select: err: %d, errno: %d.\n, err, errno);
err = write(s, buf, sizeof(buf));
ulog(write: err: %d, errno: %d.\n, err, errno);
} while (err 0);
FD_ZERO(rfds);
FD_SET(s, rfds);
tv.tv_sec = 500;
tv.tv_usec = 0;
err = select(s+1, rfds, NULL, NULL, tv);
ulog(on exit: select: err: %d, errno: %d.\n, err, errno);
}
Re: Fw: [Bug 8013] New: select for write hangs on a socket after write returned ECONNRESET
On Fri, Feb 16, 2007 at 06:25:57PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Thu, Feb 15, 2007 at 04:04:05PM -0800, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Someone want to take a stab at fixing this?? Works for me with attached application - select on connreset socket immediately returns one ready descriptor. $ ./a.out 192.168.0.48 22 select: err: 1, errno: 0. write: err: 128, errno: 0. select: err: 1, errno: 0. write: err: 128, errno: 0. select: err: 1, errno: 0. write: err: -1, errno: 104. on exit: select: err: 1, errno: 104. Nope, fails if file descriptor is checked for write. -- 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: Fw: [Bug 8013] New: select for write hangs on a socket after write returned ECONNRESET
On Fri, Feb 16, 2007 at 06:28:58PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Fri, Feb 16, 2007 at 06:25:57PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Thu, Feb 15, 2007 at 04:04:05PM -0800, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Someone want to take a stab at fixing this?? Ok, I've fund a reason - select() only checks if valid output condition is #define POLLOUT_SET (POLLWRBAND | POLLWRNORM | POLLOUT | POLLERR) Linux never sets POLLERR on shutdown - only on socket error, on shutdown POLLHUP is setup instead, so reading always shows that: #define POLLIN_SET (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP | POLLERR) A 'fix' can be to add POLLHUP into POLLOUT_SET or workaround that in application to check both input and output events in select() or use poll and explicitly check returned mask. -- 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: Fw: [Bug 8013] New: select for write hangs on a socket after write returned ECONNRESET
On Fri, Feb 16, 2007 at 06:39:58PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Fri, Feb 16, 2007 at 06:28:58PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Fri, Feb 16, 2007 at 06:25:57PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Thu, Feb 15, 2007 at 04:04:05PM -0800, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Someone want to take a stab at fixing this?? Ok, I've fund a reason - select() only checks if valid output condition is #define POLLOUT_SET (POLLWRBAND | POLLWRNORM | POLLOUT | POLLERR) Linux never sets POLLERR on shutdown - only on socket error, on shutdown POLLHUP is setup instead, so reading always shows that: #define POLLIN_SET (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP | POLLERR) A 'fix' can be to add POLLHUP into POLLOUT_SET or workaround that in application to check both input and output events in select() or use poll and explicitly check returned mask. Here is mask returned from poll() in the described case: pollin [ 2000.564000] do_select: 2076: mask: 104, i: 3/4, j: 3/32, ret: 0, in: pollin/pollout [ 2000.572000] do_select: 2076: mask: 145, i: 3/4, j: 3/32, ret: 1, in: [ 2000.572000] do_select: 2076: mask: 145, i: 3/4, j: 3/32, ret: 1, in: error is set! but only once since sock_error() replaces sk-sk_err with zero. Also pollhup is set. [ 2000.572000] do_select: 2076: mask: 2059, i: 3/4, j: 3/32, ret: 1, in: Only pollhup is set without pollerr. [ 2000.572000] do_select: 2076: mask: 2051, i: 3/4, j: 3/32, ret: 0, in: [ 2014.40] do_select: 2076: mask: 2051, i: 3/4, j: 3/32, ret: 0, in: Above sock_error() is called through the following codepath: write() - tcp_sendmsg() - disconnect detected - sk_stream_error() - sock_error() == ends up with zero sk-sk_err. select() - tcp_poll() == check for sk-sk_err fails and thus poller is not set and tcp_poll() does not return that bit, so select() fails to say that file descriptor is ready for output. -- 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: [BUG] RTNL and flush_scheduled_work deadlocks
Jarek Poplawski wrote: On Fri, Feb 16, 2007 at 10:04:25AM +0100, Jarek Poplawski wrote: On Fri, Feb 16, 2007 at 12:23:05AM -0800, Ben Greear wrote: ... I don't see how asserting it in the rtnl_lock would help anything, because at that point we are about to deadlock anyway... (and this is probably very rare, as mentioned above.) But it's happening now. Probably lockdep is not enough and rtnl_lock is probably used in too many places, so I meant some additional checks would be possible. And of course it already could be done by DEBUG_MUTEXES or DEBUG_SPINLOCK, so I gone too far and it's really bad idea. Well, I had lockdep and all of the locking debugging I could find enabled, but it did not catch this problem..I had to use sysctl -t and manually dig through the backtraces to find the deadlock It may be that lockdep could be enhanced to catch this sort of thing Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.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
[PATCH] MAINTAINER
After being the defacto maintainer for a couple of years, I can now become the official maintainer. Signed-off-by: Don Fry [EMAIL PROTECTED] --- linux-2.6.20-git8/MAINTAINERS.orig 2007-02-13 09:55:34.0 -0800 +++ linux-2.6.20-git8/MAINTAINERS 2007-02-13 09:59:50.0 -0800 @@ -2612,8 +2612,8 @@ T:git kernel.org:/pub/scm/linux/kernel/ S: Maintained PCNET32 NETWORK DRIVER -P: Thomas Bogendörfer -M: [EMAIL PROTECTED] +P: Don Fry +M: [EMAIL PROTECTED] L: netdev@vger.kernel.org S: Maintained - 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] pcnet32 NAPI no longer experimental
Remove the experimental tag for the pcnet32 NAPI implementation. Signed-off-by: Don Fry [EMAIL PROTECTED] --- linux-2.6.20-git8/drivers/net/Kconfig.orig 2007-02-13 09:55:36.0 -0800 +++ linux-2.6.20-git8/drivers/net/Kconfig 2007-02-13 10:00:54.0 -0800 @@ -1284,8 +1284,8 @@ config PCNET32 will be called pcnet32. config PCNET32_NAPI - bool Use RX polling (NAPI) (EXPERIMENTAL) - depends on PCNET32 EXPERIMENTAL + bool Use RX polling (NAPI) + depends on PCNET32 help NAPI is a new driver API designed to reduce CPU and interrupt load when the driver is receiving lots of packets from the card. It 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: Fw: [Bug 8013] New: select for write hangs on a socket after write returned ECONNRESET
one of the possible fixes for select() after write() after ECONNRESET. Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED] diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index b67e0dd..661ca0c 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -365,7 +365,7 @@ unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait) * blocking on fresh not-connected or disconnected socket. --ANK */ if (sk-sk_shutdown == SHUTDOWN_MASK || sk-sk_state == TCP_CLOSE) - mask |= POLLHUP; + mask |= POLLHUP | POLLERR; if (sk-sk_shutdown RCV_SHUTDOWN) mask |= POLLIN | POLLRDNORM | POLLRDHUP; -- 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: Re: Strange connection slowdown on pcnet32
Are there any messages in the log about timeouts, or anything else from the driver? When it gets in this state, can you communicate with another system, and does it have the same slow behavior? Looks like my mailer is munging white spaces. On Fri, Feb 16, 2007 at 09:35:54AM -0500, Lennart Sorensen wrote: I have run some tests using 2.6.8 now, and so far it hasn't failed. Still investigating... And 5 minutes later 2.6.8 failed the same way too. Maybe I will go back to 2.4 and check. -- 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 - 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: Re: Strange connection slowdown on pcnet32
On Fri, Feb 16, 2007 at 10:21:24AM -0600, [EMAIL PROTECTED] wrote: Are there any messages in the log about timeouts, or anything else from the driver? When it gets in this state, can you communicate with another system, and does it have the same slow behavior? Nope no timeouts or messages. As far as the system looks, cpu and ram and logs show nothing unusual. Just very slow reception on the ethernet port going towards the server providing the data for the transfer. Messages do get through eventually, but very very late (when a ping reply arives at the port and takes 5 to 10 seconds to make it to the network stack, then something isn't right, at least when there is no other traffic waiting). I did have NAPI in the driver even in 2.6.8 (I was adding that at the time). I am now testing with 2.6.8 without NAPI (so no mask/unmask of receive interrupts taking place), and so far it has run for over an hour without failing, although that doens't prove it won't, just that it has lasted longer. I think I will try compiling 2.6.18 again with NAPI disabled on the pcnet32 and see what that does. There is a chance that something in the NAPI implementation is breaking the chip's receive somehow although I can't currently imagine what it could be or how. -- 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: Are you responsible for Fedora's ifenslave utility?
Eric S. Raymond wrote: Are you responsible for the ifenslave utility that ships with Fedora Core? You are emailing a mailing list, so there are multiple yous here. I suggest trying the bonding driver maintainers, which are listed in the MAINTAINERS file in the kernel source tree: BONDING DRIVER P: Chad Tindel M: [EMAIL PROTECTED] P: Jay Vosburgh M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://sourceforge.net/projects/bonding/ S: Supported Regards, 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: degradation in bridging performance of 5% in 2.6.20 when compared to 2.6.19
kalyan tejaswi wrote: Hi all, I have been comparing bridging performance for 2.6.20 and 2.6.19 kernels. The kenel configurations are identical for both the kernels. I use D-Link cards (8139too driver) for the Malta 4Kc board. The setup is: netperf client --- malta 4Kc - netperf server. The throughput statistics (in 10^6 bits/second) are: 2.6.19 2.6.20 routing30.2 30.16 bridging 32.35 30.81 I observe that there has been a degradation in bridging performance of 5% in 2.6.20 when compared to 2.6.19. Has anyone observed similar behaviour? Any inputs or suggestions are welcome. In each case is the malta CPU bound? If not, some idea of the change in CPU util might be helpful. rick jones btw, netperf 2.4.3 just released: ftp://ftp.netperf.org/netperf http://www.netperf.org/svn/netperf2/tags/netperf-2.4.3 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] RTNL and flush_scheduled_work deadlocks
On Thu, 15 Feb 2007 23:40:32 -0800 Ben Greear [EMAIL PROTECTED] wrote: Jarek Poplawski wrote: On 14-02-2007 22:27, Stephen Hemminger wrote: Ben found this but the problem seems pretty widespread. The following places are subject to deadlock between flush_scheduled_work and the RTNL mutex. What can happen is that a work queue routine (like bridge port_carrier_check) is waiting forever for RTNL, and the driver routine has called flush_scheduled_work with RTNL held and is waiting for the work queue to clear. Several other places have comments like: can't call flush_scheduled_work here or it will deadlock. Most of the problem places are in device close routine. My recommendation would be to add a check for device netif_running in what ever work routine is used, and move the flush_scheduled_work to the remove routine. 8139too.c: rtl8139_close -- rtl8139_stop_thread r8169.c: rtl8169_down cassini.c: cas_change_mtu iseries_veth.c: veth_stop_connection s2io.c: s2io_close sis190.c: sis190_down There is probably more than this... Maybe there should be something like an ASSERT_NOT_RTNL() in the flush_scheduled_work() method? If it's performance criticial, #ifdef it out if we're not debugging locks? You can't safely add a check like that. What if another cpu had acquired RTNL and was unrelated. -- Stephen Hemminger [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: degradation in bridging performance of 5% in 2.6.20 when compared to 2.6.19
On Fri, 16 Feb 2007 09:43:20 -0800 Rick Jones [EMAIL PROTECTED] wrote: kalyan tejaswi wrote: Hi all, I have been comparing bridging performance for 2.6.20 and 2.6.19 kernels. The kenel configurations are identical for both the kernels. I use D-Link cards (8139too driver) for the Malta 4Kc board. The setup is: netperf client --- malta 4Kc - netperf server. The throughput statistics (in 10^6 bits/second) are: 2.6.19 2.6.20 routing30.2 30.16 bridging 32.35 30.81 I observe that there has been a degradation in bridging performance of 5% in 2.6.20 when compared to 2.6.19. Has anyone observed similar behaviour? Any inputs or suggestions are welcome. In each case is the malta CPU bound? If not, some idea of the change in CPU util might be helpful. rick jones btw, netperf 2.4.3 just released: ftp://ftp.netperf.org/netperf http://www.netperf.org/svn/netperf2/tags/netperf-2.4.3 - 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 I couldn't think of a worse NIC for bridging than the 8139too because that card has no direct DMA and does a data copy for each receive. -- Stephen Hemminger [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: [Bug 8013] New: select for write hangs on a socket after write returned ECONNRESET
On Fri, Feb 16, 2007 at 10:29:14AM -0800, Stephen Hemminger ([EMAIL PROTECTED]) wrote: On Fri, 16 Feb 2007 19:10:45 +0300 Evgeniy Polyakov [EMAIL PROTECTED] wrote: one of the possible fixes for select() after write() after ECONNRESET. Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED] diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index b67e0dd..661ca0c 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -365,7 +365,7 @@ unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait) * blocking on fresh not-connected or disconnected socket. --ANK */ if (sk-sk_shutdown == SHUTDOWN_MASK || sk-sk_state == TCP_CLOSE) - mask |= POLLHUP; + mask |= POLLHUP | POLLERR; if (sk-sk_shutdown RCV_SHUTDOWN) mask |= POLLIN | POLLRDNORM | POLLRDHUP; No, that would end up setting error bit on normal shutdown. This is incorrect behaviour and might even be described in SUSE standard. There might even be LSB tests on this? Maybe - I do not have it handy. Otherwise we can extend select output mask to include hungup too (getting into account that hungup is actually output event). -- Stephen Hemminger [EMAIL PROTECTED] -- 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: [BUG] RTNL and flush_scheduled_work deadlocks
Stephen Hemminger wrote: On Thu, 15 Feb 2007 23:40:32 -0800 Ben Greear [EMAIL PROTECTED] wrote: Maybe there should be something like an ASSERT_NOT_RTNL() in the flush_scheduled_work() method? If it's performance criticial, #ifdef it out if we're not debugging locks? You can't safely add a check like that. What if another cpu had acquired RTNL and was unrelated. I guess there isn't a way to see if *this* thread is the owner of the RTNL currently? I think lockdep knows the owner...maybe could query it somehow, or just save the owner in the mutex object when debugging is enabled... Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.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: Are you responsible for Fedora's ifenslave utility?
On Fri, Feb 16, 2007 at 11:35:05AM -0500, Eric S. Raymond wrote: Are you responsible for the ifenslave utility that ships with Fedora Core? Eric, asking on an upstream list about distribution maintainers is totally inappropriate, so please stop it. Fedora has enough mailing lists of their own. - 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: Are you responsible for Fedora's ifenslave utility?
Christoph Hellwig [EMAIL PROTECTED]: On Fri, Feb 16, 2007 at 11:35:05AM -0500, Eric S. Raymond wrote: Are you responsible for the ifenslave utility that ships with Fedora Core? Eric, asking on an upstream list about distribution maintainers is totally inappropriate, so please stop it. Fedora has enough mailing lists of their own. Don't make so many presumptions. I had to try to locate the upstream maintainers precisely because it wasn't clear whether I'm looking at a Fedora packaging problem or something further upstream. Jay Vosburgh and I are trying to detemine that now. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a - 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] - drivers/net/hamradio remove local random function, use random32()
On Fri, 2007-02-16 at 11:50 +0100, Thomas Sailer wrote:
On Thu, 2007-02-15 at 19:36 -0800, Joe Perches wrote:
remove local random function, use random32() instead
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Acked-By: Thomas Sailer [EMAIL PROTECTED]
There are a bunch of other drivers with their homegrown random number
function, namely 6pack.c dmascc.c hdlcdrv.c yam.c.
Can you do a patch for those too?
hamradio files with random functions converted to random32()
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 760d04a..01c5e1d 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -24,6 +24,7 @@
#include linux/errno.h
#include linux/netdevice.h
#include linux/timer.h
+#include linux/random.h
#include net/ax25.h
#include linux/etherdevice.h
#include linux/skbuff.h
@@ -142,11 +143,9 @@ static void sp_xmit_on_air(unsigned long channel)
{
struct sixpack *sp = (struct sixpack *) channel;
int actual, when = sp-slottime;
- static unsigned char random;
- random = random * 17 + 41;
-
- if (((sp-status1 SIXP_DCD_MASK) == 0) (random sp-persistence))
{
+ if (((sp-status1 SIXP_DCD_MASK) == 0)
+((unsigned char)random32() sp-persistence)) {
sp-led_state = 0x70;
sp-tty-driver-write(sp-tty, sp-led_state, 1);
sp-tx_enable = 1;
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
index 153b6dc..84aa211 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -52,6 +52,7 @@
#include linux/hdlcdrv.h
#include linux/baycom.h
#include linux/jiffies.h
+#include linux/random.h
#include net/ax25.h
#include asm/uaccess.h
@@ -433,16 +434,6 @@ static void encode_hdlc(struct baycom_state *bc)
/* -- */
-static unsigned short random_seed;
-
-static inline unsigned short random_num(void)
-{
- random_seed = 28629 * random_seed + 157;
- return random_seed;
-}
-
-/* -- */
-
static int transmit(struct baycom_state *bc, int cnt, unsigned char stat)
{
struct parport *pp = bc-pdev-port;
@@ -464,7 +455,7 @@ static int transmit(struct baycom_state *bc, int cnt,
unsigned char stat)
if ((--bc-hdlctx.slotcnt) 0)
return 0;
bc-hdlctx.slotcnt = bc-ch_params.slottime;
- if ((random_num() % 256) bc-ch_params.ppersist)
+ if ((random32() % 256) bc-ch_params.ppersist)
return 0;
}
}
diff --git a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c
index 0fbb414..0526a22 100644
--- a/drivers/net/hamradio/dmascc.c
+++ b/drivers/net/hamradio/dmascc.c
@@ -34,6 +34,7 @@
#include linux/rtnetlink.h
#include linux/sockios.h
#include linux/workqueue.h
+#include linux/random.h
#include asm/atomic.h
#include asm/bitops.h
#include asm/dma.h
@@ -246,7 +247,6 @@ static inline void tx_on(struct scc_priv *priv);
static inline void rx_on(struct scc_priv *priv);
static inline void rx_off(struct scc_priv *priv);
static void start_timer(struct scc_priv *priv, int t, int r15);
-static inline unsigned char random(void);
static inline void z8530_isr(struct scc_info *info);
static irqreturn_t scc_isr(int irq, void *dev_id);
@@ -269,7 +269,6 @@ static struct scc_hardware hw[NUM_TYPES]
__initdata_or_module = HARDWARE;
/* Global variables */
static struct scc_info *first;
-static unsigned long rand;
MODULE_AUTHOR(Klaus Kudielka);
@@ -314,8 +313,6 @@ static int __init dmascc_init(void)
unsigned long time, start[MAX_NUM_DEVS], delay[MAX_NUM_DEVS],
counting[MAX_NUM_DEVS];
- /* Initialize random number generator */
- rand = jiffies;
/* Cards found = 0 */
n = 0;
/* Warning message */
@@ -1099,13 +1096,6 @@ static void start_timer(struct scc_priv *priv, int t,
int r15)
}
-static inline unsigned char random(void)
-{
- /* See Numerical Recipes in C, second edition, p. 284 */
- rand = rand * 1664525L + 1013904223L;
- return (unsigned char) (rand 24);
-}
-
static inline void z8530_isr(struct scc_info *info)
{
int is, i = 100;
@@ -1466,7 +1456,8 @@ static void tm_isr(struct scc_priv *priv)
} else {
priv-state = WAIT;
start_timer(priv,
- random() / priv-param.persist *
+ (unsigned char)random32() /
+ priv-param.persist *
priv-param.slottime, DCDIE);
}
break;
diff --git a/drivers/net/hamradio/hdlcdrv.c
Re: Re: Strange connection slowdown on pcnet32
On Fri, Feb 16, 2007 at 12:21:10PM -0500, Lennart Sorensen wrote:
On Fri, Feb 16, 2007 at 10:21:24AM -0600, [EMAIL PROTECTED] wrote:
Are there any messages in the log about timeouts, or anything else from the
driver? When it gets in this state, can you communicate with another
system, and does it have the same slow behavior?
Nope no timeouts or messages. As far as the system looks, cpu and ram and
logs show nothing unusual. Just very slow reception on the ethernet port
going towards the server providing the data for the transfer. Messages do
get through eventually, but very very late (when a ping reply arives at
the port and takes 5 to 10 seconds to make it to the network stack, then
something isn't right, at least when there is no other traffic waiting).
I did have NAPI in the driver even in 2.6.8 (I was adding that at the
time). I am now testing with 2.6.8 without NAPI (so no mask/unmask of
receive interrupts taking place), and so far it has run for over an hour
without failing, although that doens't prove it won't, just that it has
lasted longer.
I think I will try compiling 2.6.18 again with NAPI disabled on the
pcnet32 and see what that does. There is a chance that something in the
NAPI implementation is breaking the chip's receive somehow although I
can't currently imagine what it could be or how.
So I have determined that when the port gets stuck/slow it is hitting
this problem:
(in pcnet32_rx):
while (quota npackets (short)le16_to_cpu(rxp-status) = 0) {
if (netif_msg_intr(lp)) printk(KERN_DEBUG %s: pcnet32_rx
npackets %d\n, dev-name, npackets);
pcnet32_rx_entry(dev, lp, rxp, entry);
npackets += 1;
/*
* The docs say that the buffer length isn't touched, but Andrew
* Boyd of QNX reports that some revs of the 79C965 clear it.
*/
rxp-buf_length = le16_to_cpu(2 - PKT_BUF_SZ);
wmb(); /* Make sure owner changes after others are visible */
rxp-status = le16_to_cpu(0x8000);
entry = (++lp-cur_rx) lp-rx_mod_mask;
rxp = lp-rx_ring[entry];
}
Unfortunately rxp-status reads as 0x8000 for a long time, and then
eventually changes to 0x0310 at which point the receive happens. Until
that happens, the poll is called about once per second and each time
returns that 0 packets were received but that more packets are waiting.
I can't figure out why it would get a status of 0x8000 which means that
the MAC hasn't changed the ownership flag on the packet yet, even though
it generated a receive interrupt multiple seconds ago. Could it be some
caching issue that makes the cpu not realize that the memory has in fact
been changed by DMA? Any way to force a cache update for a memory
location?
The CPU is a Geode SC1200 (Geode GX1 + Companion in one). So far I have
seen __memcpy from system ram to device memory get data out of order, so
I have no reason to believe the cpu doesn't have more stupid bugs
related to doing I/O.
--
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
ip_append_page and the socket send buffer
I wrote a function that is equivalent to udp_sendmsg, but uses ip_append_page to attach data to an skb. The function is implemented as follows: 1. Allocate a page and copy the given data to that page 2. Set up routing and cork the socket 3. Call ip_append_data to create an initial skb (with data length set to 0) 4. Call ip_append_page with the allocated page 5. Call udp_push_pending_frames to send the packet The function works correctly. Packets are generated and sent as expected: this was verified by looking at the packet contents on the receiving machine. However, under load, there is a significant difference in the behaviour of udp_sendmsg, compared with my function. The problem is that the socket send buffer (wmem_alloc) quickly grows beyond its upper limit (which is 131071 by default). This results in numerous failures of ip_append_data with EAGAIN, degrading performance considerably. udp_sendmsg, on the other hand, keeps wmem_alloc in a much smaller range under the same load. Two notes: 1. Modifying the upper limit to 524287 solved the problem completely (regardless of the load) 2. The same thing happens with multiple calls to ip_append_data (e.g., if I want to copy the data in two sections), so it is not a problem with ip_append_page. This leads me o believe that the problem lies with Scatter/Gather I/O. Any thoughts? Elad - 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 3/4] 8139too: RTNL and flush_scheduled_work deadlock
Jarek Poplawski [EMAIL PROTECTED] : [...] diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c index 35ad5cf..99304b2 100644 --- a/drivers/net/8139too.c +++ b/drivers/net/8139too.c @@ -1109,6 +1109,8 @@ static void __devexit rtl8139_remove_one (struct pci_dev *pdev) assert (dev != NULL); + flush_scheduled_work(); + IMHO there should be rather cancel_rearming_delayed_work instead of this. The delayed_work is initialized even if tp-have_thread is false, so cancel_rearming_delayed_work() will work, yes. Feel free to send a patch. [...] @@ -1603,18 +1605,21 @@ static void rtl8139_thread (struct work_struct *work) struct net_device *dev = tp-mii.dev; unsigned long thr_delay = next_tick; + rtnl_lock(); + + if (!netif_running(dev)) + goto out_unlock; I wonder, why you don't do netif_running before rtnl_lock ? It's an atomic operation. And I'm not sure if increasing rtnl_lock range is really needed here. threadA: netif_running() user task B: rtnl_lock() user task B: dev-close() user task B: rtnl_unlock() threadA: rtnl_lock() threadA: mess with closed device Btw, the thread runs every 3*HZ at most. -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Sk-drivers] sky2 bonding problem, 802.3ad
Holger Eitzenberger [EMAIL PROTECTED] wrote: Holger Eitzenberger [EMAIL PROTECTED] writes: bonding: ad_tx_machine() 1210: Sent LACPDU on port 1 bonding: bond_3ad_rx_indication() 2175: Received LACPDU on port 1 bonding: ad_rx_machine() 1123: Rx Machine: Port=1, Last State=6, Curr State=6 One important point I forgot about in my previous post: the host receives LACPDUs, but still the bond does not work. Also note that the other e1000 bond works happily: it is in fact the link which I use to configure it currently (via telnet). Can you send me (off list, I'm thinking) the full bonding debug dmesg log as well as a tcpdump trace of the LACP exchange (i.e., the case that LACPDUs are both sent and received)? The raw tcpdump (tcpdump -w somefile) is better than the formatted text output. I don't have either of the pieces of hardware you're using (the switch or the sky2 card), so I'm hoping there will be some gleaming nuggets of evidence in the logs. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] 8139too: RTNL and flush_scheduled_work deadlock
On Fri, 16 Feb 2007 21:20:34 +0100 Francois Romieu [EMAIL PROTECTED] wrote: Jarek Poplawski [EMAIL PROTECTED] : [...] diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c index 35ad5cf..99304b2 100644 --- a/drivers/net/8139too.c +++ b/drivers/net/8139too.c @@ -1109,6 +1109,8 @@ static void __devexit rtl8139_remove_one (struct pci_dev *pdev) assert (dev != NULL); + flush_scheduled_work(); + IMHO there should be rather cancel_rearming_delayed_work instead of this. The delayed_work is initialized even if tp-have_thread is false, so cancel_rearming_delayed_work() will work, yes. Feel free to send a patch. [...] @@ -1603,18 +1605,21 @@ static void rtl8139_thread (struct work_struct *work) struct net_device *dev = tp-mii.dev; unsigned long thr_delay = next_tick; + rtnl_lock(); + + if (!netif_running(dev)) + goto out_unlock; I wonder, why you don't do netif_running before rtnl_lock ? It's an atomic operation. And I'm not sure if increasing rtnl_lock range is really needed here. threadA: netif_running() user task B: rtnl_lock() user task B: dev-close() user task B: rtnl_unlock() threadA: rtnl_lock() threadA: mess with closed device Btw, the thread runs every 3*HZ at most. You need to hold a dev reference (dev_hold) as well. to keep the device from disappearing. or do a flush_scheduled_work in the remove routine. -- Stephen Hemminger [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: Re: Strange connection slowdown on pcnet32
On Fri, Feb 16, 2007 at 03:23:00PM -0500, Lennart Sorensen wrote:
So I have determined that when the port gets stuck/slow it is hitting
this problem:
(in pcnet32_rx):
while (quota npackets (short)le16_to_cpu(rxp-status) = 0) {
if (netif_msg_intr(lp)) printk(KERN_DEBUG %s: pcnet32_rx
npackets %d\n, dev-name, npackets);
pcnet32_rx_entry(dev, lp, rxp, entry);
npackets += 1;
/*
* The docs say that the buffer length isn't touched, but
Andrew
* Boyd of QNX reports that some revs of the 79C965 clear it.
*/
rxp-buf_length = le16_to_cpu(2 - PKT_BUF_SZ);
wmb(); /* Make sure owner changes after others are visible */
rxp-status = le16_to_cpu(0x8000);
entry = (++lp-cur_rx) lp-rx_mod_mask;
rxp = lp-rx_ring[entry];
}
Unfortunately rxp-status reads as 0x8000 for a long time, and then
eventually changes to 0x0310 at which point the receive happens. Until
that happens, the poll is called about once per second and each time
returns that 0 packets were received but that more packets are waiting.
I can't figure out why it would get a status of 0x8000 which means that
the MAC hasn't changed the ownership flag on the packet yet, even though
it generated a receive interrupt multiple seconds ago. Could it be some
caching issue that makes the cpu not realize that the memory has in fact
been changed by DMA? Any way to force a cache update for a memory
location?
The CPU is a Geode SC1200 (Geode GX1 + Companion in one). So far I have
seen __memcpy from system ram to device memory get data out of order, so
I have no reason to believe the cpu doesn't have more stupid bugs
related to doing I/O.
It seems whenever it gets stuck, it is always the same descripter it is
stuck on. Here is my current log:
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00.
eth1: base: 0x04c51812 status: 8000 next-status: 0340
eth1: pcnet32_poll: pcnet32_rx() got 0 packets
eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x.
eth1: exiting interrupt,
Re: ip_append_page and the socket send buffer
On Fri, 16 Feb 2007, Elad Lahav wrote: I wrote a function that is equivalent to udp_sendmsg, but uses ip_append_page to attach data to an skb. The function is implemented as follows: Why? Where is the code? -- 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
[PATCH 1/2] b44: replace define
Replaced B44_DMA_MASK with DMA_30BIT_MASK.
Signed-off by: Gary Zambrano [EMAIL PROTECTED]
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 5ff7882..9332f4c 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -59,7 +59,6 @@
#define B44_DEF_TX_RING_PENDING(B44_TX_RING_SIZE - 1)
#define B44_TX_RING_BYTES (sizeof(struct dma_desc) * \
B44_TX_RING_SIZE)
-#define B44_DMA_MASK 0x3fff
#define TX_RING_GAP(BP)\
(B44_TX_RING_SIZE - (BP)-tx_pending)
@@ -665,7 +664,7 @@ static int b44_alloc_rx_skb(struct b44 *
/* Hardware bug work-around, the chip is unable to do PCI DMA
to/from anything above 1GB :-( */
if (dma_mapping_error(mapping) ||
- mapping + RX_PKT_BUF_SZ B44_DMA_MASK) {
+ mapping + RX_PKT_BUF_SZ DMA_30BIT_MASK) {
/* Sigh... */
if (!dma_mapping_error(mapping))
pci_unmap_single(bp-pdev, mapping,
RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
@@ -677,7 +676,7 @@ static int b44_alloc_rx_skb(struct b44 *
RX_PKT_BUF_SZ,
PCI_DMA_FROMDEVICE);
if (dma_mapping_error(mapping) ||
- mapping + RX_PKT_BUF_SZ B44_DMA_MASK) {
+ mapping + RX_PKT_BUF_SZ DMA_30BIT_MASK) {
if (!dma_mapping_error(mapping))
pci_unmap_single(bp-pdev, mapping,
RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
dev_kfree_skb_any(skb);
@@ -988,7 +987,7 @@ static int b44_start_xmit(struct sk_buff
}
mapping = pci_map_single(bp-pdev, skb-data, len, PCI_DMA_TODEVICE);
- if (dma_mapping_error(mapping) || mapping + len B44_DMA_MASK) {
+ if (dma_mapping_error(mapping) || mapping + len DMA_30BIT_MASK) {
/* Chip can't handle DMA to/from 1GB, use bounce buffer */
if (!dma_mapping_error(mapping))
pci_unmap_single(bp-pdev, mapping, len,
PCI_DMA_TODEVICE);
@@ -1000,7 +999,7 @@ static int b44_start_xmit(struct sk_buff
mapping = pci_map_single(bp-pdev, bounce_skb-data,
len, PCI_DMA_TODEVICE);
- if (dma_mapping_error(mapping) || mapping + len B44_DMA_MASK)
{
+ if (dma_mapping_error(mapping) || mapping + len
DMA_30BIT_MASK) {
if (!dma_mapping_error(mapping))
pci_unmap_single(bp-pdev, mapping,
len, PCI_DMA_TODEVICE);
@@ -1227,7 +1226,7 @@ static int b44_alloc_consistent(struct b
DMA_BIDIRECTIONAL);
if (dma_mapping_error(rx_ring_dma) ||
- rx_ring_dma + size B44_DMA_MASK) {
+ rx_ring_dma + size DMA_30BIT_MASK) {
kfree(rx_ring);
goto out_err;
}
@@ -1254,7 +1253,7 @@ static int b44_alloc_consistent(struct b
DMA_TO_DEVICE);
if (dma_mapping_error(tx_ring_dma) ||
- tx_ring_dma + size B44_DMA_MASK) {
+ tx_ring_dma + size DMA_30BIT_MASK) {
kfree(tx_ring);
goto out_err;
}
@@ -2151,13 +2150,13 @@ static int __devinit b44_init_one(struct
pci_set_master(pdev);
- err = pci_set_dma_mask(pdev, (u64) B44_DMA_MASK);
+ err = pci_set_dma_mask(pdev, (u64) DMA_30BIT_MASK);
if (err) {
dev_err(pdev-dev, No usable DMA configuration, aborting.\n);
goto err_out_free_res;
}
- err = pci_set_consistent_dma_mask(pdev, (u64) B44_DMA_MASK);
+ err = pci_set_consistent_dma_mask(pdev, (u64) DMA_30BIT_MASK);
if (err) {
dev_err(pdev-dev, No usable DMA configuration, aborting.\n);
goto err_out_free_res;
-
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/2] B44: increase wait loop
The b44 Enet control disable bit may take longer to clear on some
systems, so the loop count is increased with this patch. Functionality
is not compromised, but a debug message can be seen when the bit is not
cleared within the count value.
Thanks to Vasileios Lourdas who reported the problem.
Signed-off by: Gary Zambrano [EMAIL PROTECTED]
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 9332f4c..aaada57 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -1288,7 +1288,7 @@ static void b44_chip_reset(struct b44 *b
if (ssb_is_core_up(bp)) {
bw32(bp, B44_RCV_LAZY, 0);
bw32(bp, B44_ENET_CTRL, ENET_CTRL_DISABLE);
- b44_wait_bit(bp, B44_ENET_CTRL, ENET_CTRL_DISABLE, 100, 1);
+ b44_wait_bit(bp, B44_ENET_CTRL, ENET_CTRL_DISABLE, 200, 1);
bw32(bp, B44_DMATX_CTRL, 0);
bp-tx_prod = bp-tx_cons = 0;
if (br32(bp, B44_DMARX_STAT) DMARX_STAT_EMASK) {
-
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: ip_append_page and the socket send buffer
James Morris wrote: On Fri, 16 Feb 2007, Elad Lahav wrote: I wrote a function that is equivalent to udp_sendmsg, but uses ip_append_page to attach data to an skb. The function is implemented as follows: Why? This scheme allows you to send the same data to multiple recipients. The user's data is copied only once into a set of pages, which are then shared among multiple skbuff objects. Where is the code? The code is probably too long to be attached to a mailing list message. It pretty much follows the steps I specified in my original e-mail. I can provide more details, if required. Elad - 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 0/3] e1000: fix, two minor updates
Jeff, Please pull: git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 e1000 to receive one fix (patch 1) and 2 updates to the e1000 driver. Cheers, Auke --- Summary: Jesse Brandeburg [EMAIL PROTECTED]: (1) e1000: fix shared interrupt warning message Auke Kok [EMAIL PROTECTED]: (2) e1000: allow ethtool to see link status when down e1000: remove obsolete custom pci_save_state code --- drivers/net/e1000/e1000.h |1 drivers/net/e1000/e1000_ethtool.c |2 - drivers/net/e1000/e1000_main.c| 70 -- 3 files changed, 9 insertions(+), 64 deletions(-) --- These patches appply against torvalds/linux-2.6 #master as of commit 0187f221e96e3436d552c0c7143f183eb82fb658 ( Ben Dooks -- [PATCH] s3c2410fb: fix un-initialised dev field) - 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 1/3] e1000: fix shared interrupt warning message
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 619c892..f293690 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -1417,10 +1417,6 @@ e1000_open(struct net_device *netdev) if ((err = e1000_setup_all_rx_resources(adapter))) goto err_setup_rx; - err = e1000_request_irq(adapter); - if (err) - goto err_req_irq; - e1000_power_up_phy(adapter); if ((err = e1000_up(adapter))) @@ -1431,6 +1427,10 @@ e1000_open(struct net_device *netdev) e1000_update_mng_vlan(adapter); } + err = e1000_request_irq(adapter); + if (err) + goto err_req_irq; + /* If AMT is enabled, let the firmware know that the network * interface is now open */ if (adapter-hw.mac_type == e1000_82573 @@ -1439,10 +1439,10 @@ e1000_open(struct net_device *netdev) return E1000_SUCCESS; +err_req_irq: + e1000_down(adapter); err_up: e1000_power_down_phy(adapter); - e1000_free_irq(adapter); -err_req_irq: e1000_free_all_rx_resources(adapter); err_setup_rx: e1000_free_all_tx_resources(adapter); --- Auke Kok [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] e1000: remove obsolete custom pci_save_state code
Now that 2.6.19 provides a proper implementation that saves MSI, PCI-E
config space, we can have the e1000 driver use those instead of it's
custom implementation.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000.h |1 -
drivers/net/e1000/e1000_main.c | 58 +---
2 files changed, 2 insertions(+), 57 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 689f158..dd4b728 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -337,7 +337,6 @@ struct e1000_adapter {
struct e1000_rx_ring test_rx_ring;
- uint32_t *config_space;
int msg_enable;
#ifdef CONFIG_PCI_MSI
boolean_t have_msi;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index f293690..a710237 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -5071,58 +5071,6 @@ e1000_set_spd_dplx(struct e1000_adapter *adapter,
uint16_t spddplx)
return 0;
}
-#ifdef CONFIG_PM
-/* Save/restore 16 or 64 dwords of PCI config space depending on which
- * bus we're on (PCI(X) vs. PCI-E)
- */
-#define PCIE_CONFIG_SPACE_LEN 256
-#define PCI_CONFIG_SPACE_LEN 64
-static int
-e1000_pci_save_state(struct e1000_adapter *adapter)
-{
- struct pci_dev *dev = adapter-pdev;
- int size;
- int i;
-
- if (adapter-hw.mac_type = e1000_82571)
- size = PCIE_CONFIG_SPACE_LEN;
- else
- size = PCI_CONFIG_SPACE_LEN;
-
- WARN_ON(adapter-config_space != NULL);
-
- adapter-config_space = kmalloc(size, GFP_KERNEL);
- if (!adapter-config_space) {
- DPRINTK(PROBE, ERR, unable to allocate %d bytes\n, size);
- return -ENOMEM;
- }
- for (i = 0; i (size / 4); i++)
- pci_read_config_dword(dev, i * 4, adapter-config_space[i]);
- return 0;
-}
-
-static void
-e1000_pci_restore_state(struct e1000_adapter *adapter)
-{
- struct pci_dev *dev = adapter-pdev;
- int size;
- int i;
-
- if (adapter-config_space == NULL)
- return;
-
- if (adapter-hw.mac_type = e1000_82571)
- size = PCIE_CONFIG_SPACE_LEN;
- else
- size = PCI_CONFIG_SPACE_LEN;
- for (i = 0; i (size / 4); i++)
- pci_write_config_dword(dev, i * 4, adapter-config_space[i]);
- kfree(adapter-config_space);
- adapter-config_space = NULL;
- return;
-}
-#endif /* CONFIG_PM */
-
static int
e1000_suspend(struct pci_dev *pdev, pm_message_t state)
{
@@ -5142,9 +5090,7 @@ e1000_suspend(struct pci_dev *pdev, pm_message_t state)
}
#ifdef CONFIG_PM
- /* Implement our own version of pci_save_state(pdev) because pci-
-* express adapters have 256-byte config spaces. */
- retval = e1000_pci_save_state(adapter);
+ retval = pci_save_state(pdev);
if (retval)
return retval;
#endif
@@ -5231,7 +5177,7 @@ e1000_resume(struct pci_dev *pdev)
uint32_t err;
pci_set_power_state(pdev, PCI_D0);
- e1000_pci_restore_state(adapter);
+ pci_restore_state(pdev);
if ((err = pci_enable_device(pdev))) {
printk(KERN_ERR e1000: Cannot enable PCI device from
suspend\n);
return err;
---
Auke Kok [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] e1000: allow ethtool to see link status when down
By reading the MAC status register we can detect whether the MAC has
seen the PHY see link. This allows us to show the link properties before
the device is up in ethtool.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_ethtool.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 44ebc72..6777887 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -166,7 +166,7 @@ e1000_get_settings(struct net_device *netdev, struct
ethtool_cmd *ecmd)
ecmd-transceiver = XCVR_EXTERNAL;
}
- if (netif_carrier_ok(adapter-netdev)) {
+ if (E1000_READ_REG(adapter-hw, STATUS) E1000_STATUS_LU) {
e1000_get_speed_and_duplex(hw, adapter-link_speed,
adapter-link_duplex);
---
Auke Kok [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: Re: Strange connection slowdown on pcnet32
On Fri, Feb 16, 2007 at 04:01:57PM -0500, Lennart Sorensen wrote: It seems whenever it gets stuck, it is always the same descripter it is stuck on. Here is my current log: eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt,
Re: [PATCH] sk98lin: planned removal
Nag message about planned sk98lin removal.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge.orig/drivers/net/sk98lin/skge.c
+++ skge/drivers/net/sk98lin/skge.c
@@ -5188,6 +5188,9 @@ static struct pci_driver skge_driver = {
static int __init skge_init(void)
{
+ printk(KERN_NOTICE sk98lin: driver has been replaced by the skge
driver
+ and is scheduled for removal\n);
+
return pci_register_driver(skge_driver);
}
-
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] skge: race with workq and RTNL
If a workqueue function that needs RTNL is running when skge_down is called then a deadlock is possible. Fix by only clearing the timer, and handling the flush_scheduled_work on removal. This work queue is only ever used for the old fiber based boards. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- skge.orig/drivers/net/skge.c +++ skge/drivers/net/skge.c @@ -1419,7 +1419,8 @@ static void xm_link_timer(struct work_st mutex_unlock(hw-phy_mutex); nochange: - schedule_delayed_work(skge-link_thread, LINK_HZ); + if (netif_running(dev)) + schedule_delayed_work(skge-link_thread, LINK_HZ); } static void genesis_mac_init(struct skge_hw *hw, int port) @@ -2530,7 +2531,7 @@ static int skge_down(struct net_device * netif_stop_queue(dev); if (hw-chip_id == CHIP_ID_GENESIS hw-phy_type == SK_PHY_XMAC) - cancel_rearming_delayed_work(skge-link_thread); + cancel_delayed_work(skge-link_thread); skge_write8(skge-hw, SK_REG(skge-port, LNK_LED_REG), LED_OFF); if (hw-chip_id == CHIP_ID_GENESIS) @@ -3690,6 +3691,8 @@ static void __devexit skge_remove(struct if (!hw) return; + flush_scheduled_work(); + if ((dev1 = hw-dev[1])) unregister_netdev(dev1); dev0 = hw-dev[0]; @@ -3704,8 +3707,6 @@ static void __devexit skge_remove(struct skge_write16(hw, B0_LED, LED_STAT_OFF); skge_write8(hw, B0_CTST, CS_RST_SET); - flush_scheduled_work(); - free_irq(pdev-irq, hw); pci_release_regions(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: Update mailing list info for 802.1q vlans
Dave, could you apply this please? The old mailing list is dead and gone. diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c index 18fcb9f..c4209c8 100644 --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -3,7 +3,8 @@ * Ethernet-type device handling. * * Authors:Ben Greear [EMAIL PROTECTED] - * Please send support related email to: [EMAIL PROTECTED] + * Please send support related email to: [EMAIL PROTECTED] + *after subscribing using the link below. * VLAN Home Page: http://www.candelatech.com/~greear/vlan.html * * Fixes: diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c index e49e252..203cd54 100644 --- a/net/8021q/vlan_dev.c +++ b/net/8021q/vlan_dev.c @@ -3,7 +3,8 @@ * Ethernet-type device handling. * * Authors:Ben Greear [EMAIL PROTECTED] - * Please send support related email to: [EMAIL PROTECTED] + * Please send support related email to: [EMAIL PROTECTED] + *after subscribing using the web page below. * VLAN Home Page: http://www.candelatech.com/~greear/vlan.html * * Fixes: Mar 22 2001: Martin Bokaemper [EMAIL PROTECTED] Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.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: forcedeth problems on 2.6.20-rc6-mm3
Tobias Diedrich wrote: Jeff Garzik wrote: Tobias Diedrich wrote: Tobias Diedrich wrote: Ayaz Abdulla wrote: For all those who are having issues, please try out the attached patch. Will try. Does not apply cleanly against 2.6.20, is this one fixed up right? It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3. IOW, the forcedeth changes in question are not in 2.6.20, and you need to apply the patch on top of the latest batch of forcedeth changes. Well, it hasn't blown up on me despite being applied to 2.6.20... The problem I was seeing might even be fixed in 2.6.20 vanilla, since the last version I saw it in was 2.6.20-rc6 and then I reverted to 2.6.19 to make sure that one is ok (see [EMAIL PROTECTED]). And having run vanilla 2.6.20 since my last mail, I haven't seen the problem on that one either. So I _guess_ the particular problem I was seeing was fixed somewhere between 2.6.20-rc6 and 2.6.20. But since I can't reliably trigger it, I can't say that for sure. -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.21-rc1] ehea: dynamic add / remove port
Hi,
I agree with most points. Here the new design proposal:
On Wednesday 14 February 2007 23:25, John Rose wrote:
Hi-
A few high level comments, then some really insignificant ones.
First, is there a reason why we shouldn't have a sysfs entry/kobject for
each logical port? How is it possible to determine, from the adapter
sysfs directory, the current number of ports for that adapter? A port
sysfs directory could include attributes like the OF path to the port,
the state of the port, etc etc.
I think it is not necessary to have a special entry/kobject for each logical
port. I suggest we use SET_NETDEV_DEV to create links to all ethernet devices
that represent each a logical port. This should be in sync with all other
ethernet drivers. Port attributes like the logical port id that might be
need by the userspace application can be added to the net:ethX entry
(link created with SET_NETDEV_DEV) as additional attributes.
Thus we have a simple and consistent way to determine
all currently available network interfaces (logical ports) and its
corresponding IDs.
Second, the probe and remove functions do not communicate whether an add
or remove was successful. Combine this with the lack of port
information in the adapter sysfs directory, and the userspace tool has
no way of verifying a dynamic add/remove.
True. I suggest we return error codes (-EIO / -EINVAL) in case the adding
or removing of ports fails. This is possible as we know instantly if the
operation failed or not. It is a synchronus operation.
+ ehea_info(%s - logial port id #%d,
Spelling :)
true, fixed
if (port_setup_ok)
- ret = 0;/* At least some ports are setup correctly */
+ return 0; /* At least some ports are setup correctly */
else
- ret = -EINVAL;
+ return -EINVAL;
The else is unnecessary.
agreed, fixed
static int __devexit ehea_remove(struct ibmebus_dev *dev)
{
struct ehea_adapter *adapter = dev-ofdev.dev.driver_data;
u64 hret;
int i;
- for (i = 0; i adapter-num_ports; i++)
+ for (i = 0; i EHEA_MAX_PORTS; i++)
if (adapter-port[i]) {
ehea_shutdown_single_port(adapter-port[i]);
adapter-port[i] = NULL;
}
Else break?
no break wanted here as remove_port might cause situations where
not all currently available ports are in a row
Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.21-rc1] ehea: dynamic add / remove port
Hi- Sounds good. A couple of questions/comments: I think it is not necessary to have a special entry/kobject for each logical port. I suggest we use SET_NETDEV_DEV to create links to all ethernet devices that represent each a logical port. This should be in sync with all other ethernet drivers. Port attributes like the logical port id that might be need by the userspace application can be added to the net:ethX entry (link created with SET_NETDEV_DEV) as additional attributes. As we develop the userspace tool, we are finding a need to know the following for each logical port: 1) the linux interface/device (a symlink would do this) 2) the logical port number - were you suggesting communicating this through the name of the symlink, or in the directory of the symlink target? 3) the open firmware path for the logical port. This is typically communicated through a sysfs attribute file devspec, but we can't do this without a new kobject for the port. Second, the probe and remove functions do not communicate whether an add or remove was successful. Combine this with the lack of port information in the adapter sysfs directory, and the userspace tool has no way of verifying a dynamic add/remove. True. I suggest we return error codes (-EIO / -EINVAL) in case the adding or removing of ports fails. This is possible as we know instantly if the operation failed or not. It is a synchronus operation. Sounds good. Thanks! John - 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] dma-mapping.h
Added dma_sync_single_range_for_cpu/device to dma-mapping.h in asm-arm
asm-avr32 to call dma_sync_single_for_cpu/device. This patch enables b44
to compile on systems with these cpus.
This patch was created with the assumption that another method of
dma_sync_single_range_for_cpu/device does not exist on these
architectures.
Signed-off by: Gary Zambrano [EMAIL PROTECTED]
diff --git a/include/asm-arm/dma-mapping.h b/include/asm-arm/dma-mapping.h
index 9bc46b4..7d01450 100644
--- a/include/asm-arm/dma-mapping.h
+++ b/include/asm-arm/dma-mapping.h
@@ -294,6 +294,24 @@ dma_unmap_sg(struct device *dev, struct
extern void dma_unmap_sg(struct device *, struct scatterlist *, int, enum
dma_data_direction);
#endif
+#ifndef CONFIG_DMABOUNCE
+static inline void
+dma_sync_single_range_for_cpu(struct device *dev, dma_addr_t dma_handle,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+{
+ /* just sync everything, that's all the pci API can do */
+ dma_sync_single_for_cpu(dev, dma_handle, offset+size, direction);
+}
+
+static inline void
+dma_sync_single_range_for_device(struct device *dev, dma_addr_t dma_handle,
+unsigned long offset, size_t size,
+enum dma_data_direction direction)
+{
+ /* just sync everything, that's all the pci API can do */
+ dma_sync_single_for_device(dev, dma_handle, offset+size, direction);
+}
/**
* dma_sync_single_for_cpu
@@ -312,7 +330,6 @@ extern void dma_unmap_sg(struct device *
* must first the perform a dma_sync_for_device, and then the
* device again owns the buffer.
*/
-#ifndef CONFIG_DMABOUNCE
static inline void
dma_sync_single_for_cpu(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir)
@@ -329,6 +346,8 @@ dma_sync_single_for_device(struct device
consistent_sync((void *)dma_to_virt(dev, handle), size, dir);
}
#else
+extern void dma_sync_single_range_for_cpu(struct device*, dma_addr_t, unsigned
long, size_t, enum dma_data_direction);
+extern void dma_sync_single_range_for_device(struct device*, dma_addr_t,
unsigned long, size_t, enum dma_data_direction);
extern void dma_sync_single_for_cpu(struct device*, dma_addr_t, size_t, enum
dma_data_direction);
extern void dma_sync_single_for_device(struct device*, dma_addr_t, size_t,
enum dma_data_direction);
#endif
diff --git a/include/asm-avr32/dma-mapping.h b/include/asm-avr32/dma-mapping.h
index 115813e..dfd1fb3 100644
--- a/include/asm-avr32/dma-mapping.h
+++ b/include/asm-avr32/dma-mapping.h
@@ -242,6 +242,24 @@ dma_unmap_sg(struct device *dev, struct
{
}
+static inline void
+dma_sync_single_range_for_cpu(struct device *dev, dma_addr_t dma_handle,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+{
+ /* just sync everything, that's all the pci API can do */
+ dma_sync_single_for_cpu(dev, dma_handle, offset+size, direction);
+}
+
+static inline void
+dma_sync_single_range_for_device(struct device *dev, dma_addr_t dma_handle,
+unsigned long offset, size_t size,
+enum dma_data_direction direction)
+{
+ /* just sync everything, that's all the pci API can do */
+ dma_sync_single_for_device(dev, dma_handle, offset+size, direction);
+}
+
/**
* dma_sync_single_for_cpu
-
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
MediaGX/GeodeGX1 requires X86_OOSTORE. (Was: Re: Strange connection slowdown on pcnet32)
On Fri, Feb 16, 2007 at 05:27:28PM -0500, Lennart Sorensen wrote: On Fri, Feb 16, 2007 at 04:01:57PM -0500, Lennart Sorensen wrote: It seems whenever it gets stuck, it is always the same descripter it is stuck on. Here is my current log: eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0433, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000 next-status: 0340 eth1: pcnet32_poll: pcnet32_rx() got 0 packets eth1: interrupt csr0=0x4f3 new csr=0x33, csr3=0x. eth1: exiting interrupt, csr0=0x0033, csr3=0x5f00. eth1: base: 0x04c51812 status: 8000
Re: MediaGX/GeodeGX1 requires X86_OOSTORE. (Was: Re: Strange connection slowdown on pcnet32)
On Fri, Feb 16, 2007 at 05:48:24PM -0500, Lennart Sorensen wrote: Well so far it really looks like enabling OOSTORE on the Geode SC1200/GX1 really does make a difference. A bit of searching seems to indicate the person that originally submitted the patch that enabled load/store reordering on the MediaGX/Geode though it might need OOSTORE, but was convinced by others it didn't. Looks like it really does need it. The failure that occoured before within a few seconds of starting a large transfer, no longer fails and all I did was enable CONFIG_X86_OOSTORE, and recompile pcnet32.ko and load the new module on the running system. Moving back to the pcnet32.ko built without OOSTORE enabled hits the failure again within seconds, until ifconfig eth1 down/up reinitialized it's descriptor ring, after which it survices another bit of transfer and then fails again. Well forcing load/store serialize on the CPU doesn't help, disalbing memory bypass doesn't help. Enabling the X86_OOSTORE does help. What a stupid CPU design. So far nothing has managed to fix the __memcpy_toio in the jsm driver getting data out of order when sending on an exar pci uart chip. Only calling memcpy with one byte at a time seems to work there. Works fine on every other cpu of course. What else am I going to discover is wrong with this CPU. -- 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
[PATCH 1/5][SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.
[SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.
This option was introduced in draft-ietf-tsvwg-sctpsocket-13. It
prevents head-of-line blocking in the case of one-to-many endpoint.
Applications enabling this option really must enable SCTP_SNDRCV event
so that they would know where the data belongs. Based on an
earlier patch by Ivan Skytte Jørgensen.
Additionally, this functionality now permits multiple associations
on the same endpoint to enter Partial Delivery. Applications should
be extra careful, when using this functionality, to track EOR indicators.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED]
---
include/net/sctp/structs.h |3 +
include/net/sctp/ulpqueue.h |2 -
include/net/sctp/user.h |4 +-
net/sctp/socket.c | 84 ++---
net/sctp/ulpqueue.c | 88 +--
5 files changed, 150 insertions(+), 31 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 31a8e88..6883c7d 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -304,10 +304,11 @@ struct sctp_sock {
__u32 autoclose;
__u8 nodelay;
__u8 disable_fragments;
- __u8 pd_mode;
__u8 v4mapped;
+ __u8 frag_interleave;
__u32 adaptation_ind;
+ atomic_t pd_mode;
/* Receive to here while partial delivery is in effect. */
struct sk_buff_head pd_lobby;
};
diff --git a/include/net/sctp/ulpqueue.h b/include/net/sctp/ulpqueue.h
index a43c878..3421b19 100644
--- a/include/net/sctp/ulpqueue.h
+++ b/include/net/sctp/ulpqueue.h
@@ -77,7 +77,7 @@ void sctp_ulpq_partial_delivery(struct s
void sctp_ulpq_abort_pd(struct sctp_ulpq *, gfp_t);
/* Clear the partial data delivery condition on this socket. */
-int sctp_clear_pd(struct sock *sk);
+int sctp_clear_pd(struct sock *sk, struct sctp_association *asoc);
/* Skip over an SSN. */
void sctp_ulpq_skip(struct sctp_ulpq *ulpq, __u16 sid, __u16 ssn);
diff --git a/include/net/sctp/user.h b/include/net/sctp/user.h
index 67a30eb..e773160 100644
--- a/include/net/sctp/user.h
+++ b/include/net/sctp/user.h
@@ -97,6 +97,8 @@ #define SCTP_GET_PEER_ADDR_INFO SCTP_GET
#define SCTP_DELAYED_ACK_TIME SCTP_DELAYED_ACK_TIME
SCTP_CONTEXT, /* Receive Context */
#define SCTP_CONTEXT SCTP_CONTEXT
+ SCTP_FRAGMENT_INTERLEAVE,
+#define SCTP_FRAGMENT_INTERLEAVE SCTP_FRAGMENT_INTERLEAVE
/* Internal Socket Options. Some of the sctp library functions are
* implemented using these socket options.
@@ -530,7 +532,7 @@ struct sctp_paddrparams {
__u32 spp_flags;
} __attribute__((packed, aligned(4)));
-/* 7.1.24. Delayed Ack Timer (SCTP_DELAYED_ACK_TIME)
+/* 7.1.23. Delayed Ack Timer (SCTP_DELAYED_ACK_TIME)
*
* This options will get or set the delayed ack timer. The time is set
* in milliseconds. If the assoc_id is 0, then this sets or gets the
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 536298c..912073d 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2249,7 +2249,7 @@ static int sctp_setsockopt_peer_addr_par
return 0;
}
-/* 7.1.24. Delayed Ack Timer (SCTP_DELAYED_ACK_TIME)
+/* 7.1.23. Delayed Ack Timer (SCTP_DELAYED_ACK_TIME)
*
* This options will get or set the delayed ack timer. The time is set
* in milliseconds. If the assoc_id is 0, then this sets or gets the
@@ -2786,6 +2786,46 @@ static int sctp_setsockopt_context(struc
return 0;
}
+/*
+ * 7.1.24. Get or set fragmented interleave (SCTP_FRAGMENT_INTERLEAVE)
+ *
+ * This options will at a minimum specify if the implementation is doing
+ * fragmented interleave. Fragmented interleave, for a one to many
+ * socket, is when subsequent calls to receive a message may return
+ * parts of messages from different associations. Some implementations
+ * may allow you to turn this value on or off. If so, when turned off,
+ * no fragment interleave will occur (which will cause a head of line
+ * blocking amongst multiple associations sharing the same one to many
+ * socket). When this option is turned on, then each receive call may
+ * come from a different association (thus the user must receive data
+ * with the extended calls (e.g. sctp_recvmsg) to keep track of which
+ * association each receive belongs to.
+ *
+ * This option takes a boolean value. A non-zero value indicates that
+ * fragmented interleave is on. A value of zero indicates that
+ * fragmented interleave is off.
+ *
+ * Note that it is important that an implementation that allows this
+ * option to be turned on, have it off by default. Otherwise an unaware
+ * application using the one to many model may become confused and act
+ * incorrectly.
+ */
+static int sctp_setsockopt_fragment_interleave(struct sock *sk,
+ char __user *optval,
+
[PATCH 3/5][SCTP]: Implement SCTP_MAX_BURST socket option.
[SCTP]: Implement SCTP_MAX_BURST socket option.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED]
---
include/net/sctp/constants.h |2 +
include/net/sctp/structs.h |1 +
include/net/sctp/user.h |4 ++-
net/sctp/associola.c |2 +
net/sctp/protocol.c |2 +
net/sctp/socket.c| 61 ++
6 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
index 5ddb855..bb37724 100644
--- a/include/net/sctp/constants.h
+++ b/include/net/sctp/constants.h
@@ -283,7 +283,7 @@ #define SCTP_RTO_ALPHA 3 /* 1
#define SCTP_RTO_BETA 2 /* 1/4 when converted to right shifts. */
/* Maximum number of new data packets that can be sent in a burst. */
-#define SCTP_MAX_BURST 4
+#define SCTP_DEFAULT_MAX_BURST 4
#define SCTP_CLOCK_GRANULARITY 1 /* 1 jiffy */
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 6883c7d..e3bcc6c 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -276,6 +276,7 @@ struct sctp_sock {
__u32 default_context;
__u32 default_timetolive;
__u32 default_rcv_context;
+ int max_burst;
/* Heartbeat interval: The endpoint sends out a Heartbeat chunk to
* the destination address every heartbeat interval. This value
diff --git a/include/net/sctp/user.h b/include/net/sctp/user.h
index 36a319e..81d85bc 100644
--- a/include/net/sctp/user.h
+++ b/include/net/sctp/user.h
@@ -99,8 +99,10 @@ #define SCTP_DELAYED_ACK_TIME SCTP_DELAY
#define SCTP_CONTEXT SCTP_CONTEXT
SCTP_FRAGMENT_INTERLEAVE,
#define SCTP_FRAGMENT_INTERLEAVE SCTP_FRAGMENT_INTERLEAVE
+ SCTP_MAX_BURST,
+#define SCTP_MAX_BURST SCTP_MAX_BURST
- /* Internal Socket Options. Some of the sctp library functions are
+ /* Internal Socket Options. Some of the sctp library functions are
* implemented using these socket options.
*/
SCTP_SOCKOPT_BINDX_ADD = 100,/* BINDX requests for adding addresses. */
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 294be94..2f61d58 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -143,7 +143,7 @@ static struct sctp_association *sctp_ass
/* Initialize the maximum mumber of new data packets that can be sent
* in a burst.
*/
- asoc-max_burst = sctp_max_burst;
+ asoc-max_burst = sp-max_burst;
/* initialize association timers */
asoc-timeouts[SCTP_EVENT_TIMEOUT_NONE] = 0;
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index e17a823..b9e6fb2 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1044,7 +1044,7 @@ SCTP_STATIC __init int sctp_init(void)
sctp_cookie_preserve_enable = 1;
/* Max.Burst- 4 */
- sctp_max_burst = SCTP_MAX_BURST;
+ sctp_max_burst = SCTP_DEFAULT_MAX_BURST;
/* Association.Max.Retrans - 10 attempts
* Path.Max.Retrans - 5 attempts (per destination address)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 912073d..ed9872a 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2826,6 +2826,36 @@ static int sctp_setsockopt_fragment_inte
return 0;
}
+/*
+ * 7.1.28. Set or Get the maximum burst (SCTP_MAX_BURST)
+ *
+ * This option will allow a user to change the maximum burst of packets
+ * that can be emitted by this association. Note that the default value
+ * is 4, and some implementations may restrict this setting so that it
+ * can only be lowered.
+ *
+ * NOTE: This text doesn't seem right. Do this on a socket basis with
+ * future associations inheriting the socket value.
+ */
+static int sctp_setsockopt_maxburst(struct sock *sk,
+ char __user *optval,
+ int optlen)
+{
+ int val;
+
+ if (optlen != sizeof(int))
+ return -EINVAL;
+ if (get_user(val, (int __user *)optval))
+ return -EFAULT;
+
+ if (val 0)
+ return -EINVAL;
+
+ sctp_sk(sk)-max_burst = val;
+
+ return 0;
+}
+
/* API 6.2 setsockopt(), getsockopt()
*
* Applications use setsockopt() and getsockopt() to set or retrieve
@@ -2943,6 +2973,9 @@ SCTP_STATIC int sctp_setsockopt(struct s
case SCTP_FRAGMENT_INTERLEAVE:
retval = sctp_setsockopt_fragment_interleave(sk, optval,
optlen);
break;
+ case SCTP_MAX_BURST:
+ retval = sctp_setsockopt_maxburst(sk, optval, optlen);
+ break;
default:
retval = -ENOPROTOOPT;
break;
@@ -3102,6 +3135,7 @@ SCTP_STATIC int sctp_init_sock(struct so
sp-default_timetolive = 0;
sp-default_rcv_context = 0;
+ sp-max_burst
[PATCH 4/5][SCTP]: Fix connection hang/slowdown with PR-SCTP
[SCTP]: Fix connection hang/slowdown with PR-SCTP
The problem that this patch corrects happens when all of the following
conditions are satisfisfied:
1. PR-SCTP is used and the timeout on the chunks is set below RTO.Max.
2. One of the paths on a multihomed associations is brought down.
In this scenario, data will expire within the rto of the initial
transmission and will never be retransmitted. However this data still
fills the send buffer and is counted against the association as outstanding
data. This causes any new data not to be sent and retransmission to not
happen.
The fix is to discount the abandoned data from the outstanding count and
peers rwnd estimation. This allows new data to be sent and a retransmission
timer restarted. Even though this new data will most likely expire within
the rto, the timer still counts as a strike against the transport and forces
the FORWARD-TSN chunk to be retransmitted as well.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED]
---
net/sctp/outqueue.c | 27 ++-
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 5c2ddd1..41abfd1 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -396,6 +396,19 @@ void sctp_retransmit_mark(struct sctp_ou
if (sctp_chunk_abandoned(chunk)) {
list_del_init(lchunk);
sctp_insert_list(q-abandoned, lchunk);
+
+ /* If this chunk has not been previousely acked,
+* stop considering it 'outstanding'. Our peer
+* will most likely never see it since it will
+* not be retransmitted
+*/
+ if (!chunk-tsn_gap_acked) {
+ chunk-transport-flight_size -=
+ sctp_data_size(chunk);
+ q-outstanding_bytes -= sctp_data_size(chunk);
+ q-asoc-peer.rwnd += (sctp_data_size(chunk) +
+ sizeof(struct sk_buff));
+ }
continue;
}
@@ -1244,6 +1257,15 @@ #endif /* SCTP_DEBUG */
if (sctp_chunk_abandoned(tchunk)) {
/* Move the chunk to abandoned list. */
sctp_insert_list(q-abandoned, lchunk);
+
+ /* If this chunk has not been acked, stop
+* considering it as 'outstanding'.
+*/
+ if (!tchunk-tsn_gap_acked) {
+ tchunk-transport-flight_size -=
+ sctp_data_size(tchunk);
+ q-outstanding_bytes -= sctp_data_size(tchunk);
+ }
continue;
}
@@ -1695,11 +1717,6 @@ static void sctp_generate_fwdtsn(struct
*/
if (TSN_lte(tsn, ctsn)) {
list_del_init(lchunk);
- if (!chunk-tsn_gap_acked) {
- chunk-transport-flight_size -=
- sctp_data_size(chunk);
- q-outstanding_bytes -= sctp_data_size(chunk);
- }
sctp_chunk_free(chunk);
} else {
if (TSN_lte(tsn, asoc-adv_peer_ack_point+1)) {
-
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/5][SCTP]: Strike the transport before updating rto.
[SCTP]: Strike the transport before updating rto. Once we reach a point where we exceed the max.path.retrans, strike the transport before updating the rto. This will force transport switch at the right time, instead of 1 retransmit too late. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] --- net/sctp/sm_statefuns.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c index b3cad8a..70c39ea 100644 --- a/net/sctp/sm_statefuns.c +++ b/net/sctp/sm_statefuns.c @@ -4605,12 +4605,12 @@ sctp_disposition_t sctp_sf_do_6_3_3_rtx( * sent as soon as cwnd allows (normally when a SACK arrives). */ - /* NB: Rules E4 and F1 are implicit in R1. */ - sctp_add_cmd_sf(commands, SCTP_CMD_RETRAN, SCTP_TRANSPORT(transport)); - /* Do some failure management (Section 8.2). */ sctp_add_cmd_sf(commands, SCTP_CMD_STRIKE, SCTP_TRANSPORT(transport)); + /* NB: Rules E4 and F1 are implicit in R1. */ + sctp_add_cmd_sf(commands, SCTP_CMD_RETRAN, SCTP_TRANSPORT(transport)); + return SCTP_DISPOSITION_CONSUME; } - 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
