Re: [PATCH 5/5 2.6.21] L2TP: Add PPPoL2TP in-kernel documentation
On Mon, 30 Apr 2007, James Chapman wrote: Signed-off-by: James Chapman [EMAIL PROTECTED] Index: linux-2.6.21/Documentation/networking/l2tp.txt === --- /dev/null +++ linux-2.6.21/Documentation/networking/l2tp.txt @@ -0,0 +1,167 @@ +This brief document describes how to use the kernel's PPPoL2TP driver +to provide L2TP functionality. L2TP is a protocol that tunnels one or +more PPP sessions over a UDP tunnel. It is commonly used for VPNs +(L2TP/IPSec) and by ISPs to tunnel subscriber PPP sessions over an IP +network infrastructure. + +Design +== + +The PPPoL2TP driver, drivers/net/pppol2tp.c, provides a mechanism by +which PPP frames carried through an L2TP session are passed through +the kernel's PPP subsystem. The standard PPP daemon, pppd, handles all +PPP interaction with the peer. PPP network interfaces are created for +each local PPP endpoint. ... +There are a number of requirements on the userspace L2TP daemon in +order to use the pppol2tp driver. + +1. Use a UDP socket per tunnel. + +2. Create a single PPPoL2TP socket per tunnel. This is used only for + for communicating with the driver but must remain open while the for for above. + tunnel is active. The driver marks the tunnel socket as an L2TP UDP + encapsulation socket, which hooks up the UDP receive path via + usp_encap_rcv() in net/ipv4/udp.c. PPP data frames are never passed Typo. usp_encap_rcv() - udp_encap_rcv(). + in this special PPPoX socket. + +3. Create a PPPoL2TP socket per L2TP session. This is typically done + by starting pppd with the pppol2tp plugin and appropriate + arguments. A PPPoL2TP tunnel management socket (Step 2) must be + created before the first PPPoL2TP session socket is created. -Bill - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8405] New: pppd does stops compresion with Lost compression sync
From the commend line: `dmesg -n 8'.
The really big fix is to boot with the ignore_loglevel boot option. This
will turn on all messages and will defeat any userspace attempt to turn the
loglevel down.
Thanks. With this command I see also the KERN_DEBUG printks now.
Here is the full diff
Thanks for persisting with this. The problem is rather serious.
If you have instructions how to proceed I'm looking forward to help solving
it. I guess reverting the zlib modification in the Linux main line is no
option. What I'm wondering is that this issue hasn't been detected earlier.
Looks as nobody is using analogue modems and nullmodem cables any more.
--- ppp_deflate.c.orig 2007-04-23 20:47:08.0 +0200
+++ ppp_deflate.c 2007-04-30 19:38:19.0 +0200
@@ -174,7 +174,7 @@ static int z_comp_init(void *arg, unsign
state-seqno = 0;
state-unit = unit;
- state-debug = debug;
+ state-debug = 1;
zlib_deflateReset(state-strm);
@@ -393,7 +393,7 @@ static int z_decomp_init(void *arg, unsi
state-seqno = 0;
state-unit = unit;
- state-debug = debug;
+ state-debug = 1;
state-mru = mru;
zlib_inflateReset(state-strm);
@@ -487,12 +487,18 @@ int z_decompress(void *arg, unsigned cha
*/
for (;;) {
r = zlib_inflate(state-strm, Z_PACKET_FLUSH);
- if (r != Z_OK) {
+// if (r != Z_OK) {
+if ((r != Z_OK) (r != Z_BUF_ERROR)) {
if (state-debug)
- printk(KERN_DEBUG z_decompress%d:
inflate returned %d (%s)\n,
+ printk(KERN_ERR z_decompress%d: inflate
returned %d (%s)\n,
state-unit, r, (state-strm.msg?
state-strm.msg: ));
return DECOMP_FATALERROR;
}
+if (r == Z_BUF_ERROR) {
+ printk(KERN_ERR z_decompress%d: Would have
triggered an error as inflate returned %d (%s)\n,
+ state-unit, r, (state-strm.msg?
state-strm.msg: ));
+}
(that was wordwrapped).
Sorry. I should have made an attachment.
What does it do?
It was just for debugging. Forget it. Now I have changed these modifications
back, and I do not see more debug information except those below:
z_decompress0: Would have triggered an error as inflate returned -5 ()
z_decompress0: Would have triggered an error as inflate returned -5 ()
z_decompress0: Would have triggered an error as inflate returned -5 ()
..
As there are no debug logs in inflate.c I can't provide more information by
now.
-
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: Natsemi DP83815 driver spaming
On Tue, 01 May 2007 10:23:38 +0200 Rafał Bilski [EMAIL PROTECTED] wrote: Hello again, I have downloaded DP83815 datasheet and I see that eth0: Wake-up event 0x20a means broadcast received and wakup on broadcast and unicast enabled. eth0: Wake-up event 0x8a Above means unicast received and wakup on broadcast and unicast enabled. I will try to check if disabling wakeup makes any difference. Thanks. You've removed all the cc's I added. I put them back. Please always do reply-to-all. - 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: Natsemi DP83815 driver spaming
On Mon, Apr 30, 2007 at 08:55:22PM -0700, Andrew Morton wrote: On Mon, 30 Apr 2007 22:58:47 +0200 Rafał Bilski [EMAIL PROTECTED] wrote: ezri user.info kernel: eth0: DSPCFG accepted after 0 usec. ezri user.notice kernel: eth0: Wake-up event 0x8a ezri user.info kernel: eth0: Setting full-duplex based on negotiated link capability. Could you please run ethtool -s eth0 msglvl 0x to turn logging from the driver right up and send a log? This will spam the log if there is any traffic but should say why the driver is doing this. It seems to be repeatedly setting the same duplex setting. The closest thing I can see in there in recent times is 68c90166e4aaa15ddcdd4778ad30bfb8b32534be, Add support for using MII port with no PHY. It's not just setting the same duplex setting, the WoL message indicates that it's doing that as part of init_registers() which should only be happening in error handling paths and during resume or open. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: [PATCH] zd1211rw-mac80211: limit URB buffering in tx path
On Tue, 1 May 2007 04:01:00 +0100 (BST), Daniel Drake wrote: The old code allowed unlimited buffing of tx frames in URBs submitted for transfer to the device. This patch stops the ieee80211_hw queue(s) if to many URBs are ready for submit to the device. Actually the ZD1211 device supports currently only one queue. This doesn't look correct to me. The limits should be per queue and you should always stop queues selectively. The ieee80211_stop_queues/ieee80211_wake_queues are for another purposes and should be used only rarely - one example is Michael Buesch's comment about a need to stop sending frames while tuning to a new channel in a workqueue. +/** + * wake_queues - wakes all queues + * @hw: a struct ieee80211_hw pointer + * + * Such a function is not provided by mac80211, so we have to provide them on + * our own. + */ +static void wake_queues(struct ieee80211_hw *hw) It is :-) Look for ieee80211_wake_queues. But as I said, you shouldn't need that. Thanks, Jiri -- Jiri Benc SUSE Labs - 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: Natsemi DP83815 driver spaming
[...] Could you please run ethtool -s eth0 msglvl 0x to turn logging from the driver right up and send a log? This will spam the log if there is any traffic but should say why the driver is doing this. OK. Here it is. It is from 2.6.21.1 with Andrew patch applied. I had to disable /var/log/messages because I have root fs on 1GB SD card. It is output from dmesg command. Btw. I've tried kexec, but it isn't working. I will have to flash kernel each time. Thank You Rafał eth0: Poll, status 0x09, mask 0xf1cd65. netdev_rx() entry 6 status was 0x98800076. eth0: Transmit frame #4 queued in slot 3. eth0: Interrupt, status 0x000249, mask 0xf1cd65. eth0: Poll, status 0x000249, mask 0xf1cd65. netdev_rx() entry 7 status was 0x98800046. eth0: tx frame #3 finished, status 0x872. eth0: Interrupt, status 0x09, mask 0xf1cd65. eth0: Poll, status 0x09, mask 0xf1cd65. netdev_rx() entry 8 status was 0x98800076. eth0: Transmit frame #5 queued in slot 4. eth0: Interrupt, status 0x000249, mask 0xf1cd65. eth0: Poll, status 0x000249, mask 0xf1cd65. netdev_rx() entry 9 status was 0x98800046. eth0: tx frame #4 finished, status 0x872. eth0: Interrupt, status 0x09, mask 0xf1cd65. eth0: Poll, status 0x09, mask 0xf1cd65. netdev_rx() entry 10 status was 0x98800076. eth0: Transmit frame #6 queued in slot 5. eth0: Interrupt, status 0x000249, mask 0xf1cd65. eth0: Poll, status 0x000249, mask 0xf1cd65. netdev_rx() entry 11 status was 0x98800046. eth0: tx frame #5 finished, status 0x872. eth0: Interrupt, status 0x09, mask 0xf1cd65. eth0: Poll, status 0x09, mask 0xf1cd65. netdev_rx() entry 12 status was 0x98800076. eth0: Transmit frame #7 queued in slot 6. eth0: Interrupt, status 0x000249, mask 0xf1cd65. eth0: Poll, status 0x000249, mask 0xf1cd65. netdev_rx() entry 13 status was 0x98800046. eth0: tx frame #6 finished, status 0x872. eth0: Transmit frame #8 queued in slot 7. eth0: Interrupt, status 0x000249, mask 0xf1cd65. eth0: Poll, status 0x000249, mask 0xf1cd65. netdev_rx() entry 14 status was 0x98800046. eth0: tx frame #7 finished, status 0x8000242. eth0: Transmit frame #9 queued in slot 8. eth0: Interrupt, status 0x000249, mask 0xf1cd65. eth0: Poll, status 0x000249, mask 0xf1cd65. netdev_rx() entry 15 status was 0x98800046. eth0: tx frame #8 finished, status 0x872. eth0: Media selection timer tick. eth0: possible phy reset: re-initializing eth0: Tx/Rx process stopped in 0 usec. Tx ring at c1189200: #0 desc. 0x1189210 0x872 0x13c405e. #1 desc. 0x1189220 0x872 0x134885e. #2 desc. 0x1189230 0x872 0x13d185e. #3 desc. 0x1189240 0x872 0x13be05e. #4 desc. 0x1189250 0x872 0x3bb05e. #5 desc. 0x1189260 0x872 0x139885e. #6 desc. 0x1189270 0x872 0x13ac05e. #7 desc. 0x1189280 0x8000242 0x139805e. #8 desc. 0x1189290 0x872 0xc6305e. #9 desc. 0x11892a0 0x00 0x13b305e. #10 desc. 0x11892b0 0x00 0x107965e. #11 desc. 0x11892c0 0x00 0x13ed05e. #12 desc. 0x11892d0 0x00 0x1b0585e. #13 desc. 0x11892e0 0x00 0x13be05e. #14 desc. 0x11892f0 0x00 0xc6785e. #15 desc. 0x1189200 0x00 0x138a05e. Rx ring c1189000: #0 desc. 0x1189010 0x0005f2 0xc67810. #1 desc. 0x1189020 0x0005f2 0x13a0010. #2 desc. 0x1189030 0x0005f2 0x11d0010. #3 desc. 0x1189040 0x0005f2 0x13c4010. #4 desc. 0x1189050 0x0005f2 0x13b3010. #5 desc. 0x1189060 0x0005f2 0x13c4810. #6 desc. 0x1189070 0x0005f2 0x1377010. #7 desc. 0x1189080 0x0005f2 0x13d1810. #8 desc. 0x1189090 0x0005f2 0x1371010. #9 desc. 0x11890a0 0x0005f2 0x13be010. #10 desc. 0x11890b0 0x0005f2 0x1348010. #11 desc. 0x11890c0 0x0005f2 0x3bb010. #12 desc. 0x11890d0 0x0005f2 0x1b05810. #13 desc. 0x11890e0 0x0005f2 0x1398810. #14 desc. 0x11890f0 0x0005f2 0x13ac010. #15 desc. 0x1189100 0x0005f2 0x1398010. #16 desc. 0x1189110 0x0005f2 0x1442810. #17 desc. 0x1189120 0x0005f2 0x1371810. #18 desc. 0x1189130 0x0005f2 0x1351010. #19 desc. 0x1189140 0x0005f2 0x13ed810. #20 desc. 0x1189150 0x0005f2 0x1351810. #21 desc. 0x1189160 0x0005f2 0x1b05010. #22 desc. 0x1189170 0x0005f2 0x11d0810. #23 desc. 0x1189180 0x0005f2 0x1377810. #24 desc. 0x1189190 0x0005f2 0x13d9810. #25 desc. 0x11891a0 0x0005f2 0x13a0810. #26 desc. 0x11891b0 0x0005f2 0x1361810. #27 desc. 0x11891c0 0x0005f2 0x138a810. #28 desc. 0x11891d0 0x0005f2 0x1361010. #29 desc. 0x11891e0 0x0005f2 0x13f8810. #30 desc. 0x11891f0 0x0005f2 0x13f8010. #31 desc. 0x1189000 0x0005f2 0x136b810. eth0: DSPCFG accepted after 0 usec. eth0: Wake-up event 0x8a eth0: Setting full-duplex based on negotiated link capability. eth0: Interrupt, status 0x002209, mask 0xf1cd65. eth0: Poll, status 0x002209, mask 0xf1cd65. netdev_rx() entry 0 status was 0x98800076. eth0: Transmit frame #1 queued in slot 0. eth0: Interrupt, status 0x000249, mask 0xf1cd65. eth0: Poll, status 0x000249, mask 0xf1cd65. netdev_rx() entry 1 status was 0x98800046. eth0: tx frame #0 finished, status 0x882. eth0: Interrupt, status 0x09, mask
BUG with ipv6 jumbo frames over loopback
Hi, with the double skb_free() issue fixed, I ran some more ip6sic tests, after a while i hit the following: [ 346.941000] Oops: [#1] [ 346.941000] PREEMPT [ 346.941000] Modules linked in: [ 346.941000] CPU:0 [ 346.941000] EIP:0060:[c05ce396]Not tainted VLI [ 346.941000] EFLAGS: 00010246 (2.6.21-g40caf5ea #3) [ 346.941000] EIP is at ipv6_hop_jumbo+0x26/0x180 [ 346.941000] eax: ebx: c93ce978 ecx: 0001 edx: 0103 [ 346.941000] esi: c8ca2126 edi: 008c ebp: c0816f14 esp: c0816f04 [ 346.941000] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 346.941000] Process ip6sic (pid: 4959, ti=c0816000 task=c9ea4aa0 task.ti=c8c2e000) [ 346.941000] Stack: c945a400 c0816f34 c07bf33c 002a c0816f3c c05cdb9f c0816f6c c07bf334 [ 346.941000]c93ce978 c8ca20fc 0496 c93ce978 c0816f6c c93ce9b4 c0816f4c c05ce6f1 [ 346.941000] cf8cfd84 c0816f7c c05ada2e 0001 0514 c07a3be0 0506 [ 346.941000] Call Trace: [ 346.941000] [c010490a] show_trace_log_lvl+0x1a/0x30 [ 346.941000] [c01049c9] show_stack_log_lvl+0xa9/0xd0 [ 346.941000] [c0104c0c] show_registers+0x21c/0x3a0 [ 346.941000] [c0104e94] die+0x104/0x260 [ 346.941000] [c0116087] do_page_fault+0x277/0x610 [ 346.941000] [c062a75c] error_code+0x74/0x7c [ 346.941000] [c05cdb9f] ip6_parse_tlv+0xef/0x130 [ 346.941000] [c05ce6f1] ipv6_parse_hopopts+0x41/0xb0 [ 346.941000] [c05ada2e] ipv6_rcv+0x1be/0x370 [ 346.941000] [c053978b] netif_receive_skb+0x21b/0x2b0 [ 346.941000] [c053b6e2] process_backlog+0x82/0xf0 [ 346.941000] [c053b97b] net_rx_action+0xab/0x1c0 [ 346.941000] [c01209a2] __do_softirq+0x62/0xc0 [ 346.941000] [c010632a] do_softirq+0x8a/0xf0 [ 346.941000] [c0120c96] local_bh_enable+0xa6/0x160 [ 346.941000] [c053bb28] dev_queue_xmit+0x98/0x330 [ 346.941000] [c05dfe38] packet_sendmsg+0x208/0x260 [ 346.941000] [c052eb05] sock_sendmsg+0xc5/0xf0 [ 346.941000] [c052ee0f] sys_sendto+0xbf/0xe0 [ 346.941000] [c052fd37] sys_socketcall+0x187/0x260 [ 346.941000] [c0104194] sysenter_past_esp+0x5d/0x99 [ 346.941000] === [ 346.941000] Code: 90 8d 74 26 00 55 89 e5 56 53 83 ec 08 8b 18 8b 4b 78 8d 34 11 80 7e 01 04 74 3b a1 30 7c 7c c0 85 c0 0f 85 7d 00 00 00 8b 43 1c 8b 80 8c 00 00 00 85 c0 74 09 8b 80 38 01 00 00 ff 40 08 a1 04 [ 346.941000] EIP: [c05ce396] ipv6_hop_jumbo+0x26/0x180 SS:ESP 0068:c0816f04 [ 346.953000] Kernel panic - not syncing: Fatal exception in interrupt It looks like packets coming via the loopback interface dont have skb-dst set, therefore we crash in ipv6_hop_jumbo() in exthdrs.c doing: IP6_INC_STATS_BH(ip6_dst_idev(skb-dst), IPSTATS_MIB_INHDRERRORS); the ip6_dst_idev() call dereferences skb-dst which is not set, causing the oops and hardlocking the box. The obvious fix would be to make ip6_dst_idev() return NULL if the parameter is NULL, since IP6_INC_STATS_BH() can handle a NULL argument, but not sure if this would be correct. To reproduce use: ip6sic -i lo -d ::1 -p 10 -r 4959 it should crash at 92.4%, i was unable to capture the stuff, since the box locks up hard, if i find a faster testcase I'll let you know. Greetings, Eric -- www.cobra-basket.de -- just my stuff - 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] e100 rx: or s and el bits
In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description
talks about emulating another driver by setting addtional bits and
the being unable to test when submitted. Seeing the operator to
set more bits made me suspicious, and indeed the bits are defined
in positive logic:
cb_s = 0x4000,
cb_el = 0x8000,
So anding those together would be 0. I'm guessing they should
be or'd, but don't have hardware here to test, much like the
committed patch. In fact, I'll let someone else do the compile
test too. I'll update the comment.
(It looks like the end of list and s bits would not be set
in the template nor cleared when linking in recieve skbs, so
as long as the kernel can keep up with the 100Mb card we
wouldn't see the adapter go off the linked list, possibly
explaining any successful use of this patch written against
2.6.14).
Signed-off-by: Milton Miller [EMAIL PROTECTED]
--- linux-2.6/drivers/net/e100.c.orig 2007-05-01 05:19:17.0 -0500
+++ linux-2.6/drivers/net/e100.c2007-05-01 05:22:14.0 -0500
@@ -947,7 +947,7 @@ static void e100_get_defaults(struct nic
((nic-mac = mac_82558_D101_A4) ? cb_cid : cb_i));
/* Template for a freshly allocated RFD */
- nic-blank_rfd.command = cpu_to_le16(cb_el cb_s);
+ nic-blank_rfd.command = cpu_to_le16(cb_el | cb_s);
nic-blank_rfd.rbd = 0x;
nic-blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
@@ -1769,13 +1769,13 @@ static int e100_rx_alloc_skb(struct nic
}
/* Link the RFD to end of RFA by linking previous RFD to
-* this one, and clearing EL bit of previous. */
+* this one, and clearing EL and S bit of previous. */
if(rx-prev-skb) {
struct rfd *prev_rfd = (struct rfd *)rx-prev-skb-data;
put_unaligned(cpu_to_le32(rx-dma_addr),
(u32 *)prev_rfd-link);
wmb();
- prev_rfd-command = ~cpu_to_le16(cb_el cb_s);
+ prev_rfd-command = ~cpu_to_le16(cb_el | cb_s);
pci_dma_sync_single_for_device(nic-pdev, rx-prev-dma_addr,
sizeof(struct rfd), PCI_DMA_TODEVICE);
}
-
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] libertas: fix for wireless Kconfig changes
On Sat, 2007-04-28 at 20:28 -0400, John W. Linville wrote: Need to change the libertas Kconfig entry to match changes made for other wireless drivers. Signed-off-by: John W. Linville [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index c4b3dc2..cb09e6b 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -267,7 +267,7 @@ config IPW2200_DEBUG config LIBERTAS_USB tristate Marvell Libertas 8388 802.11a/b/g cards - depends on NET_RADIO USB + depends on USB WLAN_80211 select FW_LOADER ---help--- A driver for Marvell Libertas 8388 USB devices. Will apply, we need to pull in wireless-dev first to get the NET_RADIO name change. Dan - 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 4/5] ne: MIPS: Use platform_driver for ne on RBTX49XX
On Tue, May 01, 2007 at 12:27:58AM +0900, Atsushi Nemoto wrote: This patch lets RBTX49XX boards use generic platform_driver interface for the ne driver. * Use platform_device to pass ioaddr and irq to the ne driver. * Remove unnecessary ifdefs for RBTX49XX from the ne driver. * Make the ne driver selectable on these boards regardless of CONFIG_ISA Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED] Acked-by: Ralf Baechle [EMAIL PROTECTED] Ralf - 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: IEEE1588 Precision Time Protocol (PTP) driver for AMCC 405EZ
On Mon, Apr 30, 2007 at 04:41:32PM +0200, Stefan Roese wrote: I'm in the stage of integrating an IEEE1588 PTP driver for the AMCC 405EZ PPC and looking for the correct location to place this driver in the Linux source tree. The driver is a character-driver that enables the user space applications to configure the time stamping unit and to read/write the timestamps. Could you elaborate your overall concept for this class of drivers? I assume it makes no sense to write an IEEE1588 driver especially for the AMCC chip, because there will probably be a need to support it on any capable hardware; for example the netX has 1588 support for precise timestamping as well and so do others. I'd prefer to discuss the needed functionality first, then find a common set of lowlevel APIs and move most of the IEEE1588 related stuff into userspace. It might also be a good idea to involve the RTnet in this discusson. Is drivers/net/ptp or drivers/net/ieee1588 a good solution? Or should it go to drivers/char/ptp because of the chrdev nature of the driver? Please start with discussing the concept, not the names. It might end being a part of the network drivers, without any special directory. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 - 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] libertas: fix for wireless Kconfig changes
On Tue, May 01, 2007 at 07:53:38AM -0400, Dan Williams wrote: On Sat, 2007-04-28 at 20:28 -0400, John W. Linville wrote: Need to change the libertas Kconfig entry to match changes made for other wireless drivers. Signed-off-by: John W. Linville [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index c4b3dc2..cb09e6b 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -267,7 +267,7 @@ config IPW2200_DEBUG config LIBERTAS_USB tristate Marvell Libertas 8388 802.11a/b/g cards - depends on NET_RADIO USB + depends on USB WLAN_80211 select FW_LOADER ---help--- A driver for Marvell Libertas 8388 USB devices. Will apply, we need to pull in wireless-dev first to get the NET_RADIO name change. No, that is already in Linus' tree via Jeff's tree. Jeff, I figured you would just apply the patch. If you'd prefer I can send a pull request, but I don't have anything else pending ATM. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sky2: re-enable 88E8056 for most motherboards
Hi Stephen,
Stephen Hemminger wrote:
This fixes the regression in 2.6.21 for users with 88e8056 on motherboard.
Allow all but the Gigabyte motherboard has some unresolved bus problems.
+ /* Some Gigabyte motherboards have 88e8056 but cause problems
+* There is some unresolved hardware related problem that causes
+* descriptor errors and receive data corruption.
+*/
+ if (pdev-vendor == PCI_VENDOR_ID_MARVELL
+ pdev-device == 0x4364 pdev-subsystem_vendor == 0x1458) {
+ dev_err(pdev-dev,
+ 88E8056 on Gigabyte motherboards not supported\n);
Gentoo have reports of sky2 working fine on Gigabyte boards which have
88E8056 devices:
https://bugs.gentoo.org/show_bug.cgi?id=176219
Can the patch be refined further?
Specifically:
Gigabyte DQ6
03:00.0 0200: 11ab:4364 (rev 12)
Subsystem: 1458:e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort-
MAbort- SERR- PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 219
Region 0: Memory at f700 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at 7000 [size=256]
[virtual] Expansion ROM at 4000 [disabled] [size=128K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable+
Address: fee0300c Data: 413a
Capabilities: [e0] Express Legacy Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0,
ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1,
Port 0
Link: Latency L0s 256ns, L1 unlimited
Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [100] Advanced Error Reporting
00: ab 11 64 43 07 04 10 00 12 00 00 02 08 00 00 00
10: 04 00 00 f7 00 00 00 00 01 70 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 00 e0
30: 00 00 00 00 48 00 00 00 00 00 00 00 0a 01 00 00
Gigabyte S3: sorry, no lspci dump available yet
Gigabyte DS3:
04:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. Unknown
device [11ab:4364] (rev 12)
Subsystem: Giga-byte Technology Unknown device [1458:e000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort-
MAbort- SERR- PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f800 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at 8000 [size=256]
[virtual] Expansion ROM at 4000 [disabled] [size=128K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0
Enable-
Address: Data:
Capabilities: [e0] Express Legacy Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0,
ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1,
Port 0
Link: Latency L0s 256ns, L1 unlimited
Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [100] Advanced Error Reporting
00: ab 11 64 43 07 00 10 00 12 00 00 02 08 00 00 00
10: 04 00 00 f8 00 00 00 00 01 80 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 00 e0
30: 00 00 00 00 48 00 00 00 00 00 00 00 0b 01 00 00
-
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] e100 rx: or s and el bits
Milton Miller wrote: In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description talks about emulating another driver by setting addtional bits and the being unable to test when submitted. Seeing the operator to set more bits made me suspicious, and indeed the bits are defined in positive logic: cb_s = 0x4000, cb_el = 0x8000, So anding those together would be 0. I'm guessing they should be or'd, but don't have hardware here to test, much like the committed patch. In fact, I'll let someone else do the compile test too. I'll update the comment. I wonder if this worked for me because the hardware also spun on the link field being NULL? Since the RU base is also set to 0, the calculated physical address would be 0 as well. I would imagine if the hardware tried to read/write to very low addresses across PCI, there would be issues. I will retest with a small receive pool to try to hit the problem. It seems to apply to a pretty recent git pull from linus's tree. I manually merged this into the 2.6.18.4 kernel we are using. With the original in kernel driver (just EL bit, no S bit), I had two tests that would always end in horrible memory corruption on a PXA255 based system. One is a 12 hour bidirectional TCP test using iperf with the ethernet port sending packets to a wireless card and vice versa. The other is a similar configuration running a 12 hour UDP test sending 20 megabits/second in each direction. Even through the original S-bit patch seems broken, we have had days of continuous traffic through it without issue where previously we could never go more than 6 hours. I will let folks know how it goes. In the UDP test, the ethernet side often gets ahead of the available buffers due to CPU and PCI usage by the wireless card and its driver. I will also run these tests with the new patch and with a smaller receive pool (default is 256) to make the pool run out more often. -Ack - 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] TCP FIN gets dropped prematurely, results in ack storm
Hello,
While testing a failover scenario, I managed to trigger an ack storm
between a Linux box and another system. Although the cause of this particular
ACK storm was due to the other box forgetting that it sent out a FIN (the
second node was unaware of the FIN the first sent in its dying gasp, which
is what I'm trying to fix, but it's a tricky race), the resulting Linux
behaviour wasn't very robust. Is there any particularly good reason that
FIN flag gets cleared on a connection which is being shut down? The trace
that motivates this can be seen at
http://www.kvack.org/~bcrl/ack-storm.log . As near as I can tell, a
similar effect can occur between two Linux boxes if the right packets get
reordered/dropped during connection teardown.
-ben
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 0faacf9..1e54291 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -635,9 +635,9 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32
len, unsigned int mss
TCP_SKB_CB(buff)-end_seq = TCP_SKB_CB(skb)-end_seq;
TCP_SKB_CB(skb)-end_seq = TCP_SKB_CB(buff)-seq;
- /* PSH and FIN should only be set in the second packet. */
+ /* PSH should only be set in the second packet. */
flags = TCP_SKB_CB(skb)-flags;
- TCP_SKB_CB(skb)-flags = flags ~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH);
+ TCP_SKB_CB(skb)-flags = flags ~(TCPCB_FLAG_PSH);
TCP_SKB_CB(buff)-flags = flags;
TCP_SKB_CB(buff)-sacked = TCP_SKB_CB(skb)-sacked;
TCP_SKB_CB(skb)-sacked = ~TCPCB_AT_TAIL;
@@ -1124,9 +1124,9 @@ static int tso_fragment(struct sock *sk, struct sk_buff
*skb, unsigned int len,
TCP_SKB_CB(buff)-end_seq = TCP_SKB_CB(skb)-end_seq;
TCP_SKB_CB(skb)-end_seq = TCP_SKB_CB(buff)-seq;
- /* PSH and FIN should only be set in the second packet. */
+ /* PSH should only be set in the second packet. */
flags = TCP_SKB_CB(skb)-flags;
- TCP_SKB_CB(skb)-flags = flags ~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH);
+ TCP_SKB_CB(skb)-flags = flags ~(TCPCB_FLAG_PSH);
TCP_SKB_CB(buff)-flags = flags;
/* This packet was never sent out yet, so no SACK bits. */
@@ -1308,7 +1308,7 @@ static int tcp_mtu_probe(struct sock *sk)
sk_stream_free_skb(sk, skb);
} else {
TCP_SKB_CB(nskb)-flags |= TCP_SKB_CB(skb)-flags
-
~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH);
+ ~(TCPCB_FLAG_PSH);
if (!skb_shinfo(skb)-nr_frags) {
skb_pull(skb, copy);
if (skb-ip_summed != CHECKSUM_PARTIAL)
-
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] e100 rx: or s and el bits
Milton Miller wrote:
In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description
talks about emulating another driver by setting addtional bits and
the being unable to test when submitted. Seeing the operator to
set more bits made me suspicious, and indeed the bits are defined
in positive logic:
cb_s = 0x4000,
cb_el = 0x8000,
So anding those together would be 0. I'm guessing they should
be or'd, but don't have hardware here to test, much like the
committed patch. In fact, I'll let someone else do the compile
test too. I'll update the comment.
(It looks like the end of list and s bits would not be set
in the template nor cleared when linking in recieve skbs, so
as long as the kernel can keep up with the 100Mb card we
wouldn't see the adapter go off the linked list, possibly
explaining any successful use of this patch written against
2.6.14).
yes, that definately doesn't seem right. I'll try to run this and watch out for
David Ackers report as well.
Thanks,
Auke
Signed-off-by: Milton Miller [EMAIL PROTECTED]
--- linux-2.6/drivers/net/e100.c.orig 2007-05-01 05:19:17.0 -0500
+++ linux-2.6/drivers/net/e100.c2007-05-01 05:22:14.0 -0500
@@ -947,7 +947,7 @@ static void e100_get_defaults(struct nic
((nic-mac = mac_82558_D101_A4) ? cb_cid : cb_i));
/* Template for a freshly allocated RFD */
- nic-blank_rfd.command = cpu_to_le16(cb_el cb_s);
+ nic-blank_rfd.command = cpu_to_le16(cb_el | cb_s);
nic-blank_rfd.rbd = 0x;
nic-blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
@@ -1769,13 +1769,13 @@ static int e100_rx_alloc_skb(struct nic
}
/* Link the RFD to end of RFA by linking previous RFD to
-* this one, and clearing EL bit of previous. */
+* this one, and clearing EL and S bit of previous. */
if(rx-prev-skb) {
struct rfd *prev_rfd = (struct rfd *)rx-prev-skb-data;
put_unaligned(cpu_to_le32(rx-dma_addr),
(u32 *)prev_rfd-link);
wmb();
- prev_rfd-command = ~cpu_to_le16(cb_el cb_s);
+ prev_rfd-command = ~cpu_to_le16(cb_el | cb_s);
pci_dma_sync_single_for_device(nic-pdev, rx-prev-dma_addr,
sizeof(struct rfd), PCI_DMA_TODEVICE);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] atl1: minor cleanup
Jay Cliburn wrote: Please accept the following trivial patches to the atl1 driver. - use dev_printk macros - fix whitespace damage Acked-By: Chris Snook [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] zd1211rw: Added new USB id for Planex GW-US54ZGL
From: Ulrich Kunitz [EMAIL PROTECTED]
Alan Tam Tam at SiuLung dot com asked for inclusion of this
device into the tree.
zd1211b chip 0053:5301 v4810 high 00-90-cc AL2230_RF pa0 ---N
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index: linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
===
--- linux-2.6.orig/drivers/net/wireless/zd1211rw/zd_usb.c
+++ linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -67,6 +67,7 @@ static struct usb_device_id usb_ids[] =
{ USB_DEVICE(0x0586, 0x3410), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0baf, 0x0121), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0586, 0x3412), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x0053, 0x5301), .driver_info = DEVICE_ZD1211B },
/* Driverless devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
{}
-
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] zd1211rw: Add ID for Sitecom WL-117
From: Matthew Davidson [EMAIL PROTECTED]
This is another driverless device which first presents itself as a USB
CDROM drive. A separate patch has been submitted to make usb-storage
ignore that device, so that zd1211rw can eject it.
zd1211 chip 0df6:9075 v4916 full 00-0c-f6 AL2230_RF pa0
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Index: linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
===
--- linux-2.6.orig/drivers/net/wireless/zd1211rw/zd_usb.c
+++ linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -40,6 +40,7 @@ static struct usb_device_id usb_ids[] =
{ USB_DEVICE(0x126f, 0xa006), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x6891, 0xa727), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x0df6, 0x9071), .driver_info = DEVICE_ZD1211 },
+ { USB_DEVICE(0x0df6, 0x9075), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x157e, 0x300b), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x079b, 0x004a), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x1740, 0x2000), .driver_info = DEVICE_ZD1211 },
@@ -70,6 +71,7 @@ static struct usb_device_id usb_ids[] =
{ USB_DEVICE(0x0053, 0x5301), .driver_info = DEVICE_ZD1211B },
/* Driverless devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
+ { USB_DEVICE(0x0ace, 0x20ff), .driver_info = DEVICE_INSTALLER },
{}
};
-
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] zd1211rw: Add ID for ZyXEL AG-225H v2
Tested by davo on IRC
zd1211b chip 0586:3413 v4810 full 00-13-49 AL7230B_RF pa0 -
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index: linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
===
--- linux-2.6.orig/drivers/net/wireless/zd1211rw/zd_usb.c
+++ linux-2.6/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -68,6 +68,7 @@ static struct usb_device_id usb_ids[] =
{ USB_DEVICE(0x0586, 0x3410), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0baf, 0x0121), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0586, 0x3412), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x0586, 0x3413), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0053, 0x5301), .driver_info = DEVICE_ZD1211B },
/* Driverless devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
-
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] drivers/net/3c505: Convert to generic boolean
Convert to generic boolean
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Compile-tested with all(yes|mod|no)config on x86(|_64) sparc(|64)
Diffed against Linus' git-tree.
diff --git a/drivers/net/3c505.c b/drivers/net/3c505.c
index e985a85..acede30 100644
--- a/drivers/net/3c505.c
+++ b/drivers/net/3c505.c
@@ -169,21 +169,6 @@ static int elp_debug;
/*
*
- * useful macros
- *
- */
-
-#ifndefTRUE
-#defineTRUE1
-#endif
-
-#ifndefFALSE
-#defineFALSE 0
-#endif
-
-
-/*
- *
* List of I/O-addresses we try to auto-sense
* Last element MUST BE 0!
*/
@@ -270,7 +255,7 @@ static inline void set_hsf(struct net_device *dev, int hsf)
spin_unlock_irqrestore(adapter-lock, flags);
}
-static int start_receive(struct net_device *, pcb_struct *);
+static bool start_receive(struct net_device *, pcb_struct *);
static inline void adapter_reset(struct net_device *dev)
{
@@ -328,28 +313,28 @@ static inline void check_3c505_dma(struct net_device *dev)
}
/* Primitive functions used by send_pcb() */
-static inline unsigned int send_pcb_slow(unsigned int base_addr, unsigned char
byte)
+static inline bool send_pcb_slow(unsigned int base_addr, unsigned char byte)
{
unsigned long timeout;
outb_command(byte, base_addr);
for (timeout = jiffies + 5*HZ/100; time_before(jiffies, timeout);) {
if (inb_status(base_addr) HCRE)
- return FALSE;
+ return false;
}
printk(KERN_WARNING 3c505: send_pcb_slow timed out\n);
- return TRUE;
+ return true;
}
-static inline unsigned int send_pcb_fast(unsigned int base_addr, unsigned char
byte)
+static inline bool send_pcb_fast(unsigned int base_addr, unsigned char byte)
{
unsigned int timeout;
outb_command(byte, base_addr);
for (timeout = 0; timeout 4; timeout++) {
if (inb_status(base_addr) HCRE)
- return FALSE;
+ return false;
}
printk(KERN_WARNING 3c505: send_pcb_fast timed out\n);
- return TRUE;
+ return true;
}
/* Check to see if the receiver needs restarting, and kick it if so */
@@ -386,7 +371,7 @@ static inline void prime_rx(struct net_device *dev)
* timeout is reduced to 500us).
*/
-static int send_pcb(struct net_device *dev, pcb_struct * pcb)
+static bool send_pcb(struct net_device *dev, pcb_struct * pcb)
{
int i;
unsigned long timeout;
@@ -396,14 +381,14 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
check_3c505_dma(dev);
if (adapter-dmaing adapter-current_dma.direction == 0)
- return FALSE;
+ return false;
/* Avoid contention */
if (test_and_set_bit(1, adapter-send_pcb_semaphore)) {
if (elp_debug = 3) {
printk(KERN_DEBUG %s: send_pcb entered while
threaded\n, dev-name);
}
- return FALSE;
+ return false;
}
/*
* load each byte into the command register and
@@ -435,7 +420,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
switch (GET_ASF(dev-base_addr)) {
case ASF_PCB_ACK:
adapter-send_pcb_semaphore = 0;
- return TRUE;
+ return true;
case ASF_PCB_NAK:
#ifdef ELP_DEBUG
@@ -453,7 +438,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
spin_unlock_irqrestore(adapter-lock, flags);
abort:
adapter-send_pcb_semaphore = 0;
- return FALSE;
+ return false;
}
@@ -470,7 +455,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
*
*/
-static int receive_pcb(struct net_device *dev, pcb_struct * pcb)
+static bool receive_pcb(struct net_device *dev, pcb_struct * pcb)
{
int i, j;
int total_length;
@@ -487,7 +472,7 @@ static int receive_pcb(struct net_device *dev, pcb_struct *
pcb)
while (((stat = get_status(dev-base_addr)) ACRF) == 0
time_before(jiffies, timeout));
if (time_after_eq(jiffies, timeout)) {
TIMEOUT_MSG(__LINE__);
- return FALSE;
+ return false;
}
pcb-command = inb_command(dev-base_addr);
@@ -497,14 +482,14 @@ static int receive_pcb(struct net_device *dev, pcb_struct
* pcb)
if (time_after_eq(jiffies, timeout)) {
TIMEOUT_MSG(__LINE__);
printk(KERN_INFO %s: status %02x\n, dev-name, stat);
- return FALSE;
+
Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 11:13:54AM -0400, Benjamin LaHaise ([EMAIL PROTECTED]) wrote: Hello, Hi Benjamin. While testing a failover scenario, I managed to trigger an ack storm between a Linux box and another system. Although the cause of this particular ACK storm was due to the other box forgetting that it sent out a FIN (the second node was unaware of the FIN the first sent in its dying gasp, which is what I'm trying to fix, but it's a tricky race), the resulting Linux behaviour wasn't very robust. Is there any particularly good reason that FIN flag gets cleared on a connection which is being shut down? The trace that motivates this can be seen at http://www.kvack.org/~bcrl/ack-storm.log . As near as I can tell, a similar effect can occur between two Linux boxes if the right packets get reordered/dropped during connection teardown. Could you archive 24Mb file or cut more precise bits out of it? +++ b/net/ipv4/tcp_output.c - TCP_SKB_CB(skb)-flags = flags ~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH); + TCP_SKB_CB(skb)-flags = flags ~(TCPCB_FLAG_PSH); Will it break 793 RFC: while the FIN is considered to occur after the last actual data octet in a segment in which it occurs. ... In this case, a FIN segment can be constructed and placed on the outgoing segment queue. No further SENDs from the user will be accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs are allowed in this state. All segments preceding and including FIN will be retransmitted until acknowledged. When the other TCP has both acknowledged the FIN and sent a FIN of its own, the first TCP can ACK this FIN. Note that a TCP receiving a FIN will ACK but not send its own FIN until its user has CLOSED the connection also. According to your patch, several packets with fin bit might be sent, including one with data. If another host does not receive fin retransmit, then that logic is broken, and it can not be fixed by duplicating fins, I would even say, that remote box should drop second packet with fin, while it can carry data, which will break higher connection logic. -- 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
[PATCH] drivers/net/tokenring: Convert to generic boolean
Convert to generic boolean Signed-off-by: Richard Knutsson [EMAIL PROTECTED] --- Compile-tested with all(yes|mod|no)config on x86(|_64) sparc(|64) Diffed against Linus' git-tree. diff --git a/drivers/net/tokenring/ibmtr.c b/drivers/net/tokenring/ibmtr.c index 1e8958e..0c69eaa 100644 --- a/drivers/net/tokenring/ibmtr.c +++ b/drivers/net/tokenring/ibmtr.c @@ -116,9 +116,6 @@ in the event that chatty debug messages are desired - jjs 12/30/98 */ #define ENABLE_PAGING 1 #endif -#define FALSE 0 -#define TRUE (!FALSE) - /* changes the output format of driver initialization */ #define TR_VERBOSE 0 @@ -1542,7 +1539,7 @@ static void initial_tok_int(struct net_device *dev) ti-ring_speed = init_status 0x01 ? 16 : 4; DPRINTK(Initial interrupt : %d Mbps, shared RAM base %08x.\n, ti-ring_speed, (unsigned int)dev-mem_start); - ti-auto_speedsave=readb(ti-init_srb+INIT_STATUS_2_OFST)4?TRUE:FALSE; + ti-auto_speedsave = (readb(ti-init_srb+INIT_STATUS_2_OFST) 4) != 0; if (ti-open_mode == MANUAL) wake_up(ti-wait_for_reset); elsetok_open_adapter((unsigned long)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: [ofa-general] Re: IPoIB forwarding
On 5/1/2007 1:57 AM, Bill Fink wrote: On Mon, 30 Apr 2007, Rick Jones wrote: Ethtool -i on the interface reports 1.2.0 as the driver version. Perhaps it would be useful to have different version strings for the in-kernel Linux version and the Myricom externally provided version. Just a thought. Indeed, and it is the case as of March-21 git (or any myri10ge version = 1.3.0). The in-kernel version will show something like: 1.3.0-1.226, the external version will only show1.3.0. Loic - 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] drivers/net/dm9000: Convert to generic boolean
Convert to generic boolean.
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Compile-tested with all(yes|mod|no)config on x86(|_64) sparc(|64)
Diffed against Linus' git-tree.
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 8cc1174..6fb3815 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -77,9 +77,6 @@
#define DM9000_PHY 0x40/* PHY address 0x01 */
-#define TRUE 1
-#define FALSE 0
-
#define CARDNAME dm9000
#define PFX CARDNAME :
@@ -896,7 +893,7 @@ dm9000_rx(struct net_device *dev)
struct dm9000_rxhdr rxhdr;
struct sk_buff *skb;
u8 rxbyte, *rdptr;
- int GoodPacket;
+ bool GoodPacket;
int RxLen;
/* Check packet ready or not */
@@ -918,7 +915,7 @@ dm9000_rx(struct net_device *dev)
return;
/* A packet ready now Get status/length */
- GoodPacket = TRUE;
+ GoodPacket = true;
writeb(DM9000_MRCMD, db-io_addr);
(db-inblk)(db-io_data, rxhdr, sizeof(rxhdr));
@@ -927,7 +924,7 @@ dm9000_rx(struct net_device *dev)
/* Packet Status check */
if (RxLen 0x40) {
- GoodPacket = FALSE;
+ GoodPacket = false;
PRINTK1(Bad Packet received (runt)\n);
}
@@ -936,7 +933,7 @@ dm9000_rx(struct net_device *dev)
}
if (rxhdr.RxStatus 0xbf00) {
- GoodPacket = FALSE;
+ GoodPacket = false;
if (rxhdr.RxStatus 0x100) {
PRINTK1(fifo error\n);
db-stats.rx_fifo_errors++;
-
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] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 08:20:50PM +0400, Evgeniy Polyakov wrote: http://www.kvack.org/~bcrl/ack-storm.log . As near as I can tell, a similar effect can occur between two Linux boxes if the right packets get reordered/dropped during connection teardown. Could you archive 24Mb file or cut more precise bits out of it? The interesting bits are the first 10 lines. According to your patch, several packets with fin bit might be sent, including one with data. If another host does not receive fin retransmit, then that logic is broken, and it can not be fixed by duplicating fins, I would even say, that remote box should drop second packet with fin, while it can carry data, which will break higher connection logic. The FIN hasn't been ack'd by the other side, though and yet Linux is no longer transmitting packets with it sent. Read the beginning of the trace. -ben -- Time is of no importance, Mr. President, only life is important. Don't Email: [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] gianfar: Add I/O barriers when touching buffer descriptor ownership.
The hardware must not see that is given ownership of a buffer until it is
completely written, and when the driver receives ownership of a buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are added where required.
Without this patch, I have observed GCC reordering the setting of
bdp-length and bdp-status in gfar_new_skb.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
drivers/net/gianfar.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index b666a0c..f187dc3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1025,6 +1025,7 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
net_device *dev)
dev-trans_start = jiffies;
+ iobarrier_w();
txbdp-status = status;
/* If this was the last BD in the ring, the next one */
@@ -1301,6 +1302,7 @@ struct sk_buff * gfar_new_skb(struct net_device *dev,
struct rxbd8 *bdp)
bdp-length = 0;
/* Mark the buffer empty */
+ iobarrier_w();
bdp-status |= (RXBD_EMPTY | RXBD_INTERRUPT);
return skb;
@@ -1484,6 +1486,7 @@ int gfar_clean_rx_ring(struct net_device *dev, int
rx_work_limit)
bdp = priv-cur_rx;
while (!((bdp-status RXBD_EMPTY) || (--rx_work_limit 0))) {
+ iobarrier_r();
skb = priv-rx_skbuff[priv-skb_currx];
if (!(bdp-status
--
1.5.0.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: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 12:49:35PM -0400, Benjamin LaHaise ([EMAIL PROTECTED]) wrote: On Tue, May 01, 2007 at 08:20:50PM +0400, Evgeniy Polyakov wrote: http://www.kvack.org/~bcrl/ack-storm.log . As near as I can tell, a similar effect can occur between two Linux boxes if the right packets get reordered/dropped during connection teardown. Could you archive 24Mb file or cut more precise bits out of it? The interesting bits are the first 10 lines. According to your patch, several packets with fin bit might be sent, including one with data. If another host does not receive fin retransmit, then that logic is broken, and it can not be fixed by duplicating fins, I would even say, that remote box should drop second packet with fin, while it can carry data, which will break higher connection logic. The FIN hasn't been ack'd by the other side, though and yet Linux is no longer transmitting packets with it sent. Read the beginning of the trace. Hmm, 2.2 machine in your test seems to behave incorrectly: 2211: 2624175182:2624175182(0) ack 1562038077 ack 2211: 2624175182:2624175182(0) ack 1562038077 fin 1122: 1562038077:1562038077(0) ack 2624175183 fin 1122: 1562038077:1562038077(0) ack 2624175183 fin // retransmit after 0.3 seconds, since there was no ack, it was either dropped, or first fin was dropped in the wire In former case 22 is in closing, in latter case - fin-wait1 2211: 2624175182:2624175182(0) ack 1562038077 ack //what is this ack for? It should have sequence number +1, since fin was sent. 1122: 1562038078:1562038078(0) ack 2624175183 ack 11 answers that this ack is bogus and it wants 2624175183 2211: 2624175182:2624175182(0) ack 1562038077 ack 1122: 1562038078:1562038078(0) ack 2624175183 ack and so on... I think if you will storm any system with acks lower than expected unacknowledged number, result will be the same - ack, that it was bogus message, if sending system sends wrong ack again, it will again receive that it was bogus... -- 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
[PATCH 1/2] AFS: Make the match_*() functions take const options
Make the match_*() functions take a const pointer to the options table and
make strings pointers in the options table const too.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
include/linux/parser.h |8
lib/parser.c | 10 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/parser.h b/include/linux/parser.h
index fa33328..86676f6 100644
--- a/include/linux/parser.h
+++ b/include/linux/parser.h
@@ -11,10 +11,10 @@
/* associates an integer enumerator with a pattern string. */
struct match_token {
int token;
- char *pattern;
+ const char *pattern;
};
-typedef struct match_token match_table_t[];
+typedef const struct match_token match_table_t[];
/* Maximum number of arguments that match_token will find in a pattern */
enum {MAX_OPT_ARGS = 3};
@@ -29,5 +29,5 @@ int match_token(char *, match_table_t table, substring_t
args[]);
int match_int(substring_t *, int *result);
int match_octal(substring_t *, int *result);
int match_hex(substring_t *, int *result);
-void match_strcpy(char *, substring_t *);
-char *match_strdup(substring_t *);
+void match_strcpy(char *, const substring_t *);
+char *match_strdup(const substring_t *);
diff --git a/lib/parser.c b/lib/parser.c
index 7ad2a48..703c8c1 100644
--- a/lib/parser.c
+++ b/lib/parser.c
@@ -22,7 +22,7 @@
* match extremely simple token=arg style patterns. If the pattern is found,
* the location(s) of the arguments will be returned in the @args array.
*/
-static int match_one(char *s, char *p, substring_t args[])
+static int match_one(char *s, const char *p, substring_t args[])
{
char *meta;
int argc = 0;
@@ -43,7 +43,7 @@ static int match_one(char *s, char *p, substring_t args[])
p = meta + 1;
if (isdigit(*p))
- len = simple_strtoul(p, p, 10);
+ len = simple_strtoul(p, (char **) p, 10);
else if (*p == '%') {
if (*s++ != '%')
return 0;
@@ -102,7 +102,7 @@ static int match_one(char *s, char *p, substring_t args[])
*/
int match_token(char *s, match_table_t table, substring_t args[])
{
- struct match_token *p;
+ const struct match_token *p;
for (p = table; !match_one(s, p-pattern, args) ; p++)
;
@@ -190,7 +190,7 @@ int match_hex(substring_t *s, int *result)
* substring_t @s to the c-style string @to. Caller guarantees that @to is
* large enough to hold the characters of @s.
*/
-void match_strcpy(char *to, substring_t *s)
+void match_strcpy(char *to, const substring_t *s)
{
memcpy(to, s-from, s-to - s-from);
to[s-to - s-from] = '\0';
@@ -204,7 +204,7 @@ void match_strcpy(char *to, substring_t *s)
* the substring_t @s. The caller is responsible for freeing the returned
* string with kfree().
*/
-char *match_strdup(substring_t *s)
+char *match_strdup(const substring_t *s)
{
char *p = kmalloc(s-to - s-from + 1, GFP_KERNEL);
if (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
[PATCH 2/2] AFS/AF_RXRPC: Miscellaneous fixes
Make miscellaneous fixes to AFS and AF_RXRPC:
(*) Make AF_RXRPC select KEYS rather than RXKAD or AFS_FS in Kconfig.
(*) Don't use FS_BINARY_MOUNTDATA.
(*) Remove a done 'TODO' item in a comemnt on afs_get_sb().
(*) Don't pass a void * as the page pointer argument of kmap_atomic() as this
breaks on m68k. Patch from Geert Uytterhoeven [EMAIL PROTECTED].
(*) Use match_*() functions rather than doing my own parsing.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
fs/Kconfig|1 -
fs/afs/fsclient.c |3 +-
fs/afs/super.c| 100 +++--
net/rxrpc/Kconfig |3 +-
4 files changed, 47 insertions(+), 60 deletions(-)
diff --git a/fs/Kconfig b/fs/Kconfig
index a42f767..e33c089 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -2020,7 +2020,6 @@ config AFS_FS
tristate Andrew File System support (AFS) (EXPERIMENTAL)
depends on INET EXPERIMENTAL
select AF_RXRPC
- select KEYS
help
If you say Y here, you will get an experimental Andrew File System
driver. It currently only supports unsecured read-only AFS access.
diff --git a/fs/afs/fsclient.c b/fs/afs/fsclient.c
index 2393d2a..e54e6c2 100644
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -266,7 +266,8 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call,
call-unmarshall++;
if (call-count PAGE_SIZE) {
- buffer = kmap_atomic(call-reply3, KM_USER0);
+ page = call-reply3;
+ buffer = kmap_atomic(page, KM_USER0);
memset(buffer + PAGE_SIZE - call-count, 0,
call-count);
kunmap_atomic(buffer, KM_USER0);
diff --git a/fs/afs/super.c b/fs/afs/super.c
index cebd03c..41173f8 100644
--- a/fs/afs/super.c
+++ b/fs/afs/super.c
@@ -20,6 +20,7 @@
#include linux/slab.h
#include linux/fs.h
#include linux/pagemap.h
+#include linux/parser.h
#include internal.h
#define AFS_FS_MAGIC 0x6B414653 /* 'kAFS' */
@@ -42,7 +43,7 @@ struct file_system_type afs_fs_type = {
.name = afs,
.get_sb = afs_get_sb,
.kill_sb= kill_anon_super,
- .fs_flags = FS_BINARY_MOUNTDATA,
+ .fs_flags = 0,
};
static const struct super_operations afs_super_ops = {
@@ -58,6 +59,20 @@ static const struct super_operations afs_super_ops = {
static struct kmem_cache *afs_inode_cachep;
static atomic_t afs_count_active_inodes;
+enum {
+ afs_no_opt,
+ afs_opt_cell,
+ afs_opt_rwpath,
+ afs_opt_vol,
+};
+
+static const match_table_t afs_options_list = {
+ { afs_opt_cell, cell=%s },
+ { afs_opt_rwpath, rwpath},
+ { afs_opt_vol, vol=%s},
+ { afs_no_opt, NULL},
+};
+
/*
* initialise the filesystem
*/
@@ -115,31 +130,6 @@ void __exit afs_fs_exit(void)
}
/*
- * check that an argument has a value
- */
-static int want_arg(char **_value, const char *option)
-{
- if (!_value || !*_value || !**_value) {
- printk(KERN_NOTICE kAFS: %s: argument missing\n, option);
- return 0;
- }
- return 1;
-}
-
-/*
- * check that there's no subsequent value
- */
-static int want_no_value(char *const *_value, const char *option)
-{
- if (*_value **_value) {
- printk(KERN_NOTICE kAFS: %s: Invalid argument: %s\n,
- option, *_value);
- return 0;
- }
- return 1;
-}
-
-/*
* parse the mount options
* - this function has been shamelessly adapted from the ext3 fs which
* shamelessly adapted it from the msdos fs
@@ -148,48 +138,46 @@ static int afs_parse_options(struct afs_mount_params
*params,
char *options, const char **devname)
{
struct afs_cell *cell;
- char *key, *value;
- int ret;
+ substring_t args[MAX_OPT_ARGS];
+ char *p;
+ int token;
_enter(%s, options);
options[PAGE_SIZE - 1] = 0;
- ret = 0;
- while ((key = strsep(options, ,))) {
- value = strchr(key, '=');
- if (value)
- *value++ = 0;
-
- _debug(kAFS: KEY: %s, VAL:%s, key, value ?: -);
+ while ((p = strsep(options, ,))) {
+ if (!*p)
+ continue;
- if (strcmp(key, rwpath) == 0) {
- if (!want_no_value(value, rwpath))
- return -EINVAL;
- params-rwpath = 1;
- } else if (strcmp(key, vol) == 0) {
- if (!want_arg(value, vol))
- return -EINVAL;
- *devname = value;
- } else if (strcmp(key, cell) == 0) {
- if (!want_arg(value, cell))
-
Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 09:41:28PM +0400, Evgeniy Polyakov wrote: Hmm, 2.2 machine in your test seems to behave incorrectly: I am aware of that. However, I think that the loss of certain packets and reordering can result in the same behaviour. What's more, is that this behaviour can occur in real deployed systems. Be strict in what you send and liberal in what you accept. Both systems should be fixed, which is what I'm trying to do. -ben -- Time is of no importance, Mr. President, only life is important. Don't Email: [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] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 09:41:28PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
On Tue, May 01, 2007 at 12:49:35PM -0400, Benjamin LaHaise ([EMAIL
PROTECTED]) wrote:
On Tue, May 01, 2007 at 08:20:50PM +0400, Evgeniy Polyakov wrote:
http://www.kvack.org/~bcrl/ack-storm.log . As near as I can tell, a
similar effect can occur between two Linux boxes if the right packets
get
reordered/dropped during connection teardown.
Could you archive 24Mb file or cut more precise bits out of it?
The interesting bits are the first 10 lines.
According to your patch, several packets with fin bit might be sent,
including one with data. If another host does not receive fin
retransmit, then that logic is broken, and it can not be fixed by
duplicating fins, I would even say, that remote box should drop second
packet with fin, while it can carry data, which will break higher
connection logic.
The FIN hasn't been ack'd by the other side, though and yet Linux is no
longer transmitting packets with it sent. Read the beginning of the trace.
Hmm, 2.2 machine in your test seems to behave incorrectly:
2211: 2624175182:2624175182(0) ack 1562038077 ack
2211: 2624175182:2624175182(0) ack 1562038077 fin
1122: 1562038077:1562038077(0) ack 2624175183 fin
1122: 1562038077:1562038077(0) ack 2624175183 fin // retransmit after
0.3 seconds, since there was no ack, it was either dropped, or first fin
was dropped in the wire
In former case 22 is in closing, in latter case - fin-wait1
2211: 2624175182:2624175182(0) ack 1562038077 ack //what is this ack
for? It should have sequence number +1, since fin was sent.
1122: 1562038078:1562038078(0) ack 2624175183 ack
11 answers that this ack is bogus and it wants 2624175183
2211: 2624175182:2624175182(0) ack 1562038077 ack
1122: 1562038078:1562038078(0) ack 2624175183 ack
and so on...
I think if you will storm any system with acks lower than expected
unacknowledged number, result will be the same - ack, that it was bogus
message, if sending system sends wrong ack again, it will again receive
that it was bogus...
Wrong syn number of course.
I described not exactly correct case - likely broken side does not know
that its messages were lost (or specially crafts such packets), so it
retransmit the same bogus packet with wrong syn, which already was acked.
As far as I can see, this is it:
/* step 1: check sequence number */
if (!tcp_sequence(tp, TCP_SKB_CB(skb)-seq, TCP_SKB_CB(skb)-end_seq)) {
if (!th-rst)
tcp_send_dupack(sk, skb);
goto discard;
}
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
Benjamin LaHaise wrote: According to your patch, several packets with fin bit might be sent, including one with data. If another host does not receive fin retransmit, then that logic is broken, and it can not be fixed by duplicating fins, I would even say, that remote box should drop second packet with fin, while it can carry data, which will break higher connection logic. The FIN hasn't been ack'd by the other side, though and yet Linux is no longer transmitting packets with it sent. Read the beginning of the trace. I agree completely with Evgeniy. The patch you sent would cause bad breakage by sending the FIN bit on segments with different sequence numbers. Looking at your trace, it seems like the behavior of the test system 192.168.2.2 is broken in two ways. First, like you said it has broken state in that it has forgotten that it sent the FIN. Once you do that, the connection state is corrupt and all bets are off. It's sending an out-of-window segment that's getting tossed by Linux, and Linux generates an ack in response. This is in direct RFC compliance. The second problem is that the other system is generating these broken acks in response to the legitimate acks Linux is sending, causing the ack war. I can't really guess why it's doing that... You might be able to change Linux to prevent this ack war, but doing so would break RFC compliance, and given the buggy nature of the other end, it sounds to me like a bad idea. -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
Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 09:57:18PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
I think if you will storm any system with acks lower than expected
unacknowledged number, result will be the same - ack, that it was bogus
message, if sending system sends wrong ack again, it will again receive
that it was bogus...
Wrong syn number of course.
I described not exactly correct case - likely broken side does not know
that its messages were lost (or specially crafts such packets), so it
retransmit the same bogus packet with wrong syn, which already was acked.
As far as I can see, this is it:
/* step 1: check sequence number */
if (!tcp_sequence(tp, TCP_SKB_CB(skb)-seq, TCP_SKB_CB(skb)-end_seq)) {
if (!th-rst)
tcp_send_dupack(sk, skb);
goto discard;
}
And this is part of the RFC Linux follows:
There are four cases for the acceptability test for an incoming
segment:
Segment Receive Test
Length Window
--- --- ---
0 0 SEG.SEQ = RCV.NXT
0 0 RCV.NXT = SEG.SEQ RCV.NXT+RCV.WND
0 0 not acceptable
0 0 RCV.NXT = SEG.SEQ RCV.NXT+RCV.WND
or RCV.NXT = SEG.SEQ+SEG.LEN-1 RCV.NXT+RCV.WND
If the RCV.WND is zero, no segments will be acceptable, but
special allowance should be made to accept valid ACKs, URGs and
RSTs.
If an incoming segment is not acceptable, an acknowledgment
should be sent in reply (unless the RST bit is set, if so drop
the segment and return):
SEQ=SND.NXTACK=RCV.NXTCTL=ACK
After sending the acknowledgment, drop the unacceptable segment
and return.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 01:54:03PM -0400, John Heffner wrote: Looking at your trace, it seems like the behavior of the test system 192.168.2.2 is broken in two ways. First, like you said it has broken state in that it has forgotten that it sent the FIN. Once you do that, the connection state is corrupt and all bets are off. It's sending an out-of-window segment that's getting tossed by Linux, and Linux generates an ack in response. This is in direct RFC compliance. The second problem is that the other system is generating these broken acks in response to the legitimate acks Linux is sending, causing the ack war. I can't really guess why it's doing that... I know it's a bug, and I'm trying to fix it, but that doesn't change the fact that A) the system is already deployed and B) Linux is not retransmitting the FIN, which (from Linux's point of view) remains unacknowledged by the other side. The patch might be wrong, but the goal of fixing the behaviour isn't. -ben -- Time is of no importance, Mr. President, only life is important. Don't Email: [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] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 02:04:05PM -0400, Benjamin LaHaise ([EMAIL PROTECTED]) wrote: I know it's a bug, and I'm trying to fix it, but that doesn't change the fact that A) the system is already deployed and B) Linux is not retransmitting the FIN, which (from Linux's point of view) remains unacknowledged by the other side. The patch might be wrong, but the goal of fixing the behaviour isn't. It does retransmit fin: 10:23:32.298477 IP (tos 0x0, ttl 255, id 39972, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.59192 192.168.2.2.bgp: F, cksum 0x5558 (correct), 1562038077:1562038077(0) ack 2624175183 win 183 nop,nop,timestamp 1549356119 781231 10:23:32.599809 IP (tos 0x0, ttl 255, id 39973, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.59192 192.168.2.2.bgp: F, cksum 0x542b (correct), 1562038077:1562038077(0) ack 2624175183 win 183 nop,nop,timestamp 1549356420 781231 10:23:33.201722 IP (tos 0x0, ttl 255, id 40802, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.59192 192.168.2.2.bgp: F, cksum 0x51d1 (correct), 1562038077:1562038077(0) ack 2624175183 win 183 nop,nop,timestamp 1549357022 781231 10:23:34.405537 IP (tos 0x0, ttl 255, id 40914, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.59192 192.168.2.2.bgp: F, cksum 0x4d1d (correct), 1562038077:1562038077(0) ack 2624175183 win 183 nop,nop,timestamp 1549358226 781231 -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
Benjamin LaHaise wrote: On Tue, May 01, 2007 at 09:41:28PM +0400, Evgeniy Polyakov wrote: Hmm, 2.2 machine in your test seems to behave incorrectly: I am aware of that. However, I think that the loss of certain packets and reordering can result in the same behaviour. What's more, is that this behaviour can occur in real deployed systems. Be strict in what you send and liberal in what you accept. Both systems should be fixed, which is what I'm trying to do. Actually, you cannot get in this situation by loss or reordering of packets, only be corruption of state on one side. It sends the FIN, which effectively increases the sequence number by one. However, all later segments it sends have an old lower sequence number, which are now out of window. Being liberal in what you accept is good to a point, but sometimes you have to draw the line. -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
Re: [PATCH 2/2] AFS/AF_RXRPC: Miscellaneous fixes
Hi David,
I've just noticed another issue: if CONFIG_AFS_FS=y, the kernel build fails
with
| `afs_callback_update_kill' referenced in section `.init.text' of
fs/built-in.o: defined in discarded section `.exit.text' of fs/built-in.o
| `afs_vlocation_purge' referenced in section `.init.text' of fs/built-in.o:
defined in discarded section `.exit.text' of fs/built-in.o
and indeed, afs_init() calls both afs_callback_update_kill() and
afs_vlocation_purge() in the failure path.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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: Natsemi DP83815 driver spaming
On Tue, May 01, 2007 at 12:25:20PM +0200, Rafał Bilski wrote: eth0: Media selection timer tick. eth0: possible phy reset: re-initializing This is why the reset is being triggered - it's a workaround for a hardware bug which checks to make sure the hardware is in the state that the kernel thinks it is is going off. The code has this explanatory comment: * 2) check for sudden death of the NIC: *It seems that a reference set for this chip went out with incorrect info, *and there exist boards that aren't quite right. An unexpected voltage *drop can cause the PHY to get itself in a weird state (basically reset). *NOTE: this only seems to affect revC chips. I'd suggest checking your power supply as a first step. [BTW, as Andrew said please don't drop people from the CC.] -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: [PATCH 2/2] AFS/AF_RXRPC: Miscellaneous fixes
Geert Uytterhoeven [EMAIL PROTECTED] wrote: I've just noticed another issue: if CONFIG_AFS_FS=y, the kernel build fails with Can you send me the config you're using please? David - 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] AFS: Fix use of __exit functions from __init path
Fix use of __exit functions from __init path.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
fs/afs/callback.c |2 +-
fs/afs/internal.h |4 ++--
fs/afs/vlocation.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/afs/callback.c b/fs/afs/callback.c
index 639399f..9bdbf36 100644
--- a/fs/afs/callback.c
+++ b/fs/afs/callback.c
@@ -468,7 +468,7 @@ int __init afs_callback_update_init(void)
/*
* shut down the callback update process
*/
-void __exit afs_callback_update_kill(void)
+void afs_callback_update_kill(void)
{
destroy_workqueue(afs_callback_update_worker);
}
diff --git a/fs/afs/internal.h b/fs/afs/internal.h
index c0404b4..f1bd47e 100644
--- a/fs/afs/internal.h
+++ b/fs/afs/internal.h
@@ -401,7 +401,7 @@ extern void afs_give_up_callback(struct afs_vnode *);
extern void afs_dispatch_give_up_callbacks(struct work_struct *);
extern void afs_flush_callback_breaks(struct afs_server *);
extern int __init afs_callback_update_init(void);
-extern void __exit afs_callback_update_kill(void);
+extern void afs_callback_update_kill(void);
/*
* cell.c
@@ -605,7 +605,7 @@ extern struct afs_vlocation *afs_vlocation_lookup(struct
afs_cell *,
struct key *,
const char *, size_t);
extern void afs_put_vlocation(struct afs_vlocation *);
-extern void __exit afs_vlocation_purge(void);
+extern void afs_vlocation_purge(void);
/*
* vnode.c
diff --git a/fs/afs/vlocation.c b/fs/afs/vlocation.c
index 6c8e95a..3370cdb 100644
--- a/fs/afs/vlocation.c
+++ b/fs/afs/vlocation.c
@@ -602,7 +602,7 @@ int __init afs_vlocation_update_init(void)
/*
* discard all the volume location records for rmmod
*/
-void __exit afs_vlocation_purge(void)
+void afs_vlocation_purge(void)
{
afs_vlocation_timeout = 0;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 11:13:54AM -0400, Benjamin LaHaise ([EMAIL PROTECTED]) wrote: Hello, While testing a failover scenario, I managed to trigger an ack storm between a Linux box and another system. Although the cause of this particular ACK storm was due to the other box forgetting that it sent out a FIN (the second node was unaware of the FIN the first sent in its dying gasp, which is what I'm trying to fix, but it's a tricky race), the resulting Linux behaviour wasn't very robust. Is there any particularly good reason that One of the packets sent by broken 1.1 host has incorrect checksum, so it will be dropped by 2.2 system in theory, could that packet somehow break 2.2 stack's state machine? -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 10:20:07PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: On Tue, May 01, 2007 at 11:13:54AM -0400, Benjamin LaHaise ([EMAIL PROTECTED]) wrote: Hello, While testing a failover scenario, I managed to trigger an ack storm between a Linux box and another system. Although the cause of this particular ACK storm was due to the other box forgetting that it sent out a FIN (the second node was unaware of the FIN the first sent in its dying gasp, which is what I'm trying to fix, but it's a tricky race), the resulting Linux behaviour wasn't very robust. Is there any particularly good reason that One of the packets sent by broken 1.1 host has incorrect checksum, so it will be dropped by 2.2 system in theory, could that packet somehow break 2.2 stack's state machine? It seems so, 2.2 stack expects i-1 sequence number, so when you add fin into both (i-1)'th and i'th packets, 2.2 system correctly completes session thinking that i-1 is the real last message, which is not. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
On Fri, 2007-27-04 at 08:45 -0700, Waskiewicz Jr, Peter P wrote: On Thu, 2007-26-04 at 09:30 -0700, Waskiewicz Jr, Peter P wrote: I agree, that to be fair for discussing the code that you should look at the patches before drawing conclusions. I appreciate the fact you have a different idea for your approach for multiqueue, but without having specific things to discuss in terms of implementation, I'm at a loss for what you want to see done. These patches have been released in the community for a few months now, and the general approach has been accepted for the most part. Sorry, I (was too busy with real work and) wasnt keeping up with netdev. And stop whining please if you want me to comment; that is such an important part of the network subsystem - so your patches need more scrutiny because their impact is huge. And i know that subsystem enough that i dont need to look at your patches to know you are going to be hit by a big truck (by just observing you are crossing a busy highway on foot). I don't know how you think I'm whining here. I'm just expecting people that make comments on patches submitted to actually look at them if they wish to make comments. Otherwise, I have no idea what to fix if you don't give context. The basis of your criticism and comments should be based on the code, and not be influenced that my approach is different than your approach. If you have a better approach, then please post it so the community can decide. My patches have been under discussion for a few months, and the general approach has been fairly well-accepted. The comments that David, Patrick, and Thomas have given were more on implementation, which have been fixed and are what you see today. So if you don't like my approach, then please provide an alternative. That being said, my approach was to provide an API for drivers to implement multiqueue support. We originally went with an idea to do the multiqueue support in the driver. That is certainly one (brute) approach. This way you meet the requirement of not changing anything on the qdisc level (user or kernel level). But i am not sure you need an API perse. Please explain why this is a brute force approach. Today, netdev gives drivers an API to manage the device queue (dev-queue_lock). I extended this to provide a management API to manage each queue on a device. This to me makes complete sense; why hide the fact a device has multiple queues from the kernel? I don't understand your comments here. However, many questions came up that were answered by pulling things into the qdisc / netdev layer. Specifically, if all the multiqueue code is in the driver, how would you ensure one flow of traffic (say on queue 0) doesn't interfere with another flow (say on queue 1)? If queue 1 on your NIC ran out of descriptors, the driver will set dev-queue_lock to __LINK_STATE_XOFF, which will cause all entry points into the scheduler to stop (i.e. - no more packets going to the NIC). That will also shut down queue 0. As soon as that happens, that is not multiqueue network support. The other question was how to classify traffic. We're proposing to use tc filters to do it, since the user has control over that; having flexibility to meet different network needs is a plus. We had tried doing queue selection in the driver, and it killed performance. Hence why we pulled it into the qdisc layer. at some point when my thinking was evolving, I had similar thoughts crossing my mind, but came to the conclusion i was thinking too hard when i started (until i started to look/think about the OLPC mesh network challenge). Lets take baby steps so we can make this a meaningful discussion. Ignore wireless for a second and talk just about simple wired interfaces; we can then come back to wireless in a later discussion. For the first baby steps, lets look at strict prio which if i am not mistaken is what you e1000 NICs support; but even that were not the case, strict prio covers a huge amount of multi-queue capability. For simplicity, lets pick something with just 2 hardware queues; PH and PL (PH stands for High Prio and PL low prio). With me so far? E1000 is not strict prio scheduling, rather, it is round-robin. This question was posed by Patrick McHardy on netdev and I answered it 2 weeks ago. I am making the assumptions that: a) you understand the basics of strict prio scheduling b) You have configured strict prio in the qdisc level and the hardware levels to be synced i.e if your hardware is capable of only strict prio, then you better use a matching strict prio qdisc (and not another qdisc like HTB etc). If your hardware is capable 2 queues, you better have your qdisc with only two bands. I disagree. If you read Patrick's comments, using strict PRIO in software and in hardware will probably give
Re: [PATCH] AFS: Fix use of __exit functions from __init path
On Tue, 1 May 2007, David Howells wrote:
Fix use of __exit functions from __init path.
Signed-off-by: David Howells [EMAIL PROTECTED]
Acked-by: Geert Uytterhoeven [EMAIL PROTECTED]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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
IFF_PROMISC again
Hi, for the nth time I send this email, hoping that majordomo won't eat it again. I know this has been extensibly discussed circa 2001, but I found that there's still problems: in debian (at least) neither ifconfig nor ip can tell that the interface is in promiscuous mode. I know about the deprecation of IFF_PROMISC, but I couldn't find out which is the current way of knowing the real state of the interface. I want to fix ifconfig, so this is not an issue of PACKET_(ADD|REMOVE)_MEMBERSHIP, I need to query the real device state. Also, it's unclear to me what happens when you set/reset IFF_PROMISC and then libpcap fiddles with membership. Is this documented somewhere? It has been said many times that ip should give this information. I cannot see this: $ sudo tcpdump -ni eth2 port $ dmesg |tail -2 device eth2 entered promiscuous mode audit(1175904782.767:40): dev=eth2 prom=256 old_prom=0 auid=4294967295 $ ip link show eth2 4: eth2: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:18:de:81:24:a2 brd ff:ff:ff:ff:ff:ff $ ip -V ip utility, iproute2-ss060323 I think that is a problem for user tools to not know about this, and I want to fix them. I don't know how. Can anyone give me a pointer? Thanks, Martín. -- Martín Ferrari [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
Bonding two 802.1q interfaces triggers sleeping function called from invalid context
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238307 This is kernel 2.6.20.3. From the bugzilla comment: === I need to use a bonding through two 802.1q tag VLAN virtual interface in the same physical network interface. When I bond interface with command : ifenslave bond0 eth1.10 eth1.20 Console and dmesg will continues report BUG: --Output1 begin kernel 2.6.20-1.2933.fc6 BUG: sleeping function called from invalid context at include/asm/uaccess.h:500 in_atomic():1, irqs_disabled():0 [c04ecadb] copy_from_user+0x35/0x66 [c05c2e78] dev_ethtool+0x51/0xa0d [c05ee503] tcp_current_mss+0x71/0xdf [c05ee169] tcp_rcv_established+0x74f/0x7de [c04cf48f] selinux_netlbl_sock_rcv_skb+0x1d/0x5b [c05f3a78] tcp_v4_do_rcv+0x1bf/0x49c [c05f5f1b] tcp_v4_rcv+0x564/0x8b1 [d8a3ac03] vlan_dev_ioctl+0x7b/0xa7 [8021q] [d8a3ab88] vlan_dev_ioctl+0x0/0xa7 [8021q] [d8a53102] bond_update_speed_duplex+0x88/0xd7 [bonding] [d8a5688e] bond_mii_monitor+0x0/0x403 [bonding] [d8a56c01] bond_mii_monitor+0x373/0x403 [bonding] [c061ff9d] _spin_unlock_irq+0x5/0x7 [c0439e73] hrtimer_run_queues+0x127/0x141 [d8a5688e] bond_mii_monitor+0x0/0x403 [bonding] [c042e673] run_timer_softirq+0x101/0x164 [c042b908] __do_softirq+0x5d/0xba [c04061b1] do_softirq+0x59/0xb1 [c0419df6] smp_apic_timer_interrupt+0x76/0x80 [c04049b0] apic_timer_interrupt+0x28/0x30 [c0402d52] default_idle+0x0/0x3e [c0402d7e] default_idle+0x2c/0x3e [c04023d0] cpu_idle+0x9e/0xb7 [c074a812] start_kernel+0x3b6/0x3be [c074a25a] unknown_bootoption+0x0/0x202 - 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: Natsemi DP83815 driver spaming
eth0: Media selection timer tick. eth0: possible phy reset: re-initializing This is why the reset is being triggered - it's a workaround for a hardware bug which checks to make sure the hardware is in the state that the kernel thinks it is is going off. The code has this explanatory comment: * 2) check for sudden death of the NIC: *It seems that a reference set for this chip went out with incorrect info, *and there exist boards that aren't quite right. An unexpected voltage *drop can cause the PHY to get itself in a weird state (basically reset). *NOTE: this only seems to affect revC chips. Yes. I have revision C chip. I'd suggest checking your power supply as a first step. 5,25V when not connected. 5,04V when connected to Wyse. I don't have access to osciloscope. I will check if this code is nedded. If it is then I will try to get new power supply. [BTW, as Andrew said please don't drop people from the CC.] OK. Will not happen again. Rafał -- Kasia Cichopek eksponuje biust http://link.interia.pl/f1a6f - 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] TCP FIN gets dropped prematurely, results in ack storm
On Tue, May 01, 2007 at 02:03:04PM -0400, John Heffner wrote: Actually, you cannot get in this situation by loss or reordering of packets, only be corruption of state on one side. It sends the FIN, which effectively increases the sequence number by one. However, all later segments it sends have an old lower sequence number, which are now out of window. Okay, I missed the other packets with a FIN later on in the storm. What is different about them is that they get sent with different timestamps than the acks being thrown about. Perhaps narrowly looking at the lack of FIN is wrong -- I'll try instrumenting what the PAWS code is doing on both sides as that is probably what short circuits an ACK into being sent. Being liberal in what you accept is good to a point, but sometimes you have to draw the line. True. Still, both sides are doing completely the wrong thing in this case, and I'd like to get an idea of the best way to prevent the ACK storm from happenning. -ben -- Time is of no importance, Mr. President, only life is important. Don't Email: [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: r8169 2.2LK: Low link speed after suspend
Hi Francois! Sorry, returning to this issue took me longer than anticipated before I could return to the issue. Hardly: the r8169 driver has been modified by ~40 patches from 2.6.18 to now. There is an ugly hack^W^W quick backport for 2.6.18 at: http://www.fr.zoreil.com/people/francois/backport/r8169/20070418-00 It compiles but I do not know if it works and I strongly suggest to use a more recent kernel package anyway. Unfortunately the driver that comes with 2.6.18 doesn't appear to support mii-tool. I get this message: Mars:~ # mii-tool -w eth2 SIOCGMIIPHY on 'eth2' failed: Operation not supported Next I'll be looking at the provided backport. Also, I'll be confronted with SuSE 10.2 and the RTL8111B at work next week. I'll keep you updated. Peter - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bonding two 802.1q interfaces triggers sleeping function called from invalid context
On Tue, May 01, 2007 at 02:47:59PM -0400, Chuck Ebbert wrote: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238307 This is kernel 2.6.20.3. From the bugzilla comment: === I need to use a bonding through two 802.1q tag VLAN virtual interface in the same physical network interface. When I bond interface with command : ifenslave bond0 eth1.10 eth1.20 Console and dmesg will continues report BUG: --Output1 begin kernel 2.6.20-1.2933.fc6 BUG: sleeping function called from invalid context at include/asm/uaccess.h:500 in_atomic():1, irqs_disabled():0 [c04ecadb] copy_from_user+0x35/0x66 [c05c2e78] dev_ethtool+0x51/0xa0d [c05ee503] tcp_current_mss+0x71/0xdf [c05ee169] tcp_rcv_established+0x74f/0x7de [c04cf48f] selinux_netlbl_sock_rcv_skb+0x1d/0x5b [c05f3a78] tcp_v4_do_rcv+0x1bf/0x49c [c05f5f1b] tcp_v4_rcv+0x564/0x8b1 [d8a3ac03] vlan_dev_ioctl+0x7b/0xa7 [8021q] [d8a3ab88] vlan_dev_ioctl+0x0/0xa7 [8021q] [d8a53102] bond_update_speed_duplex+0x88/0xd7 [bonding] [d8a5688e] bond_mii_monitor+0x0/0x403 [bonding] [d8a56c01] bond_mii_monitor+0x373/0x403 [bonding] Jay Vosburgh and I have been working on something to address this and other issues related to possible sleeping activities that might come from the monitoring functions. I feel like we are getting close to something so I hope we can post something soon. Care to add anything, Jay? - 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: Natsemi DP83815 driver spaming
eth0: Media selection timer tick. eth0: possible phy reset: re-initializing This is why the reset is being triggered - it's a workaround for a hardware bug which checks to make sure the hardware is in the state that the kernel thinks it is is going off. The code has this explanatory comment: * 2) check for sudden death of the NIC: *It seems that a reference set for this chip went out with incorrect info, *and there exist boards that aren't quite right. An unexpected voltage *drop can cause the PHY to get itself in a weird state (basically reset). *NOTE: this only seems to affect revC chips. Code commented out and NIC is working OK. Strange. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. dspcfg = 0x np-dspcfg = 0x5060 dspcfg = 0x np-dspcfg = 0x5060 dspcfg = 0x np-dspcfg = 0x5060 dspcfg = 0x np-dspcfg = 0x5060 dspcfg = 0x np-dspcfg = 0x5060 dspcfg = 0x np-dspcfg = 0x5060 dspcfg = 0x np-dspcfg = 0x5060 One problem solved in mean time :-) PCI: CS5530 video turned off. [BTW, as Andrew said please don't drop people from the CC.] I didn't. It is Thunderbird. I'm included instead of You. Fixed manually this time. Regards Rafał --- Linda jako gospodyni domowa - zobacz!!! http://link.interia.pl/f1a79 - 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 23/36] Use menuconfig objects II - netdev/wan
Jan Engelhardt [EMAIL PROTECTED] writes: Change Kconfig objects from menu, config into menuconfig so that the user can disable the whole feature without having to enter the menu first. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] --- drivers/net/wan/Kconfig | 34 +++--- Looks good. -- Krzysztof Halasa - 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: [SCTP] Initialization collision problem
Vlad, I finally got test results for the changes you suggested. The original issue is fixed and I have not detected any side effects. Thanks, Oscar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vlad Yasevich Sent: Wednesday, April 11, 2007 9:45 AM To: Isaula Oscar-QOI000 Cc: netdev@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [SCTP] Initialization collision problem Hi Oscar Isaula Oscar-QOI000 wrote: I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication to the User application but is giving back a value of zero for the assoc_id. Attached are the SCTP debugs for the period in question. A couple of things that I would like to note about my setup. One is that I'm running Kernel version 2.6.10 (I know is old but I can't move to a newer version due to custom drivers). The second thing is that the link between the two SCTP node is a very noisy and some messages are getting lost (i.e. the INIT_ACK from the peer in this particular case). Can you give this patch a try and let me know if this fixes your issue? Thanks -vlad - 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: r8169 2.2LK: Low link speed after suspend
Peter Missel [EMAIL PROTECTED] : [...] Sorry, returning to this issue took me longer than anticipated before I could return to the issue. No problem, it is in my bugs store. [...] Unfortunately the driver that comes with 2.6.18 doesn't appear to support mii-tool. I get this message: Mars:~ # mii-tool -w eth2 SIOCGMIIPHY on 'eth2' failed: Operation not supported Are you sure that your system is kept up-to-date ? If I read correctly, Suse's 10.2's kernel 2.6.18.8-0.1 includes a 2.6.19-rc5 version of the r8169 driver. It should support the relevant ioctl (please add '-v -v' to the mii-tool command btw). However... Next I'll be looking at the provided backport. Also, I'll be confronted with SuSE 10.2 and the RTL8111B at work next week. ... for the 8168/8111B, it is strongly suggested to use 2.6.21 + http://www.fr.zoreil.com/people/francois/misc/20070430-2.6.21-r8169-test.patch -- Ueimor Anybody got a battery for my Ultra 10 ? - 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: r8169 ethernet bonding problems
A tcpdump trace 1) before promiscuous mode 2) after promiscuous mode 3) after link failure (i.e. failover does not work) would be welcome. Okay, after fixing STP forwarding delays on the switch, bonding failover now works, as long as member links are forced to promisc mode. Still Have a problem with links randomly failing to achieve link on boot. This then requires a modprobe -r r8169; modprobe r8169 cycle to get link. Side effect is the mac address corruption I have described previously. Tim: - 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: [SCTP] Initialization collision problem
Isaula Oscar-QOI000 wrote: Vlad, I finally got test results for the changes you suggested. The original issue is fixed and I have not detected any side effects. Thanks. -vlad Thanks, Oscar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vlad Yasevich Sent: Wednesday, April 11, 2007 9:45 AM To: Isaula Oscar-QOI000 Cc: netdev@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [SCTP] Initialization collision problem Hi Oscar Isaula Oscar-QOI000 wrote: I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication to the User application but is giving back a value of zero for the assoc_id. Attached are the SCTP debugs for the period in question. A couple of things that I would like to note about my setup. One is that I'm running Kernel version 2.6.10 (I know is old but I can't move to a newer version due to custom drivers). The second thing is that the link between the two SCTP node is a very noisy and some messages are getting lost (i.e. the INIT_ACK from the peer in this particular case). Can you give this patch a try and let me know if this fixes your issue? Thanks -vlad - 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] zd1211rw-mac80211: limit URB buffering in tx path
On 07-05-01 12:34 Jiri Benc wrote: On Tue, 1 May 2007 04:01:00 +0100 (BST), Daniel Drake wrote: The old code allowed unlimited buffing of tx frames in URBs submitted for transfer to the device. This patch stops the ieee80211_hw queue(s) if to many URBs are ready for submit to the device. Actually the ZD1211 device supports currently only one queue. This doesn't look correct to me. The limits should be per queue and you should always stop queues selectively. The old ZD1211 chip doesn't support queuing and the new ZD1211B chip has support, but it is unclear how to put packets in the different queues. However the error condition here is, that packets can't be transmitted over the USB, which will affect all queues. Sure one could manage different high level marks for the different queues, but this is all theoretical currently. I could have coded with the explicit knowledge that we support only one queue, but it is really work the hassle. +/** + * wake_queues - wakes all queues + * @hw: a struct ieee80211_hw pointer + * + * Such a function is not provided by mac80211, so we have to provide them on + * our own. + */ +static void wake_queues(struct ieee80211_hw *hw) It is :-) Look for ieee80211_wake_queues. But as I said, you shouldn't need that. I provided the patch to add ieee80211_wake_queues(). Sorry for missing the moment, when it has been integrated. I will update the patch. -- Uli Kunitz - 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] TCP FIN gets dropped prematurely, results in ack storm
From: Benjamin LaHaise [EMAIL PROTECTED] Date: Tue, 1 May 2007 15:19:31 -0400 On Tue, May 01, 2007 at 02:03:04PM -0400, John Heffner wrote: Being liberal in what you accept is good to a point, but sometimes you have to draw the line. True. Still, both sides are doing completely the wrong thing in this case, and I'd like to get an idea of the best way to prevent the ACK storm from happenning. You do it by fixing the broken 2.2.x system, you don't do it by breaking 2.6.x to spit out FINs with different sequence numbers which is absolutely wrong and will cause more problems than it will solve. Please drop even the thought of this patch, kthx. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bonding two 802.1q interfaces triggers sleeping function called from invalid context
Andy Gospodarek [EMAIL PROTECTED] wrote: I need to use a bonding through two 802.1q tag VLAN virtual interface in the same physical network interface. When I bond interface with command : ifenslave bond0 eth1.10 eth1.20 Console and dmesg will continues report BUG: --Output1 begin kernel 2.6.20-1.2933.fc6 BUG: sleeping function called from invalid context at include/asm/uaccess.h:500 in_atomic():1, irqs_disabled():0 [c04ecadb] copy_from_user+0x35/0x66 [c05c2e78] dev_ethtool+0x51/0xa0d [c05ee503] tcp_current_mss+0x71/0xdf [c05ee169] tcp_rcv_established+0x74f/0x7de [c04cf48f] selinux_netlbl_sock_rcv_skb+0x1d/0x5b [c05f3a78] tcp_v4_do_rcv+0x1bf/0x49c [c05f5f1b] tcp_v4_rcv+0x564/0x8b1 [d8a3ac03] vlan_dev_ioctl+0x7b/0xa7 [8021q] [d8a3ab88] vlan_dev_ioctl+0x0/0xa7 [8021q] [d8a53102] bond_update_speed_duplex+0x88/0xd7 [bonding] [d8a5688e] bond_mii_monitor+0x0/0x403 [bonding] [d8a56c01] bond_mii_monitor+0x373/0x403 [bonding] Jay Vosburgh and I have been working on something to address this and other issues related to possible sleeping activities that might come from the monitoring functions. I feel like we are getting close to something so I hope we can post something soon. Care to add anything, Jay? I was thinking about this one a couple of days ago; it's a little tricky to get out of, since we nominally need to do the ethtool calls holding only rtnl, but don't want to cycle rtnl for each monitor pass. The warning only shows up with VLANs because VLAN get_settings() calls dev_ethtool() directly, and the copy_from_user() in dev_ethtool() is the complaining party here. Calling an end device driver's get_settings() directly doesn't trigger the warning. I think that's safe without rtnl (at least insofar as the slave won't vanish), since the slave cannot vanish without bonding being notified via the NETDEV_UNREGISTER notifier. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 31/33] m68k: kill skb_copy_from_linear_data compiler warnings
The recent conversion from `memcpy' to `skb_copy_from_linear_data' removed a
few casts, which were needed to silence compiler warnings. Re-add them.
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/net/7990.c |6 +++---
drivers/net/a2065.c |4 ++--
drivers/net/sun3_82586.c |5 +++--
3 files changed, 8 insertions(+), 7 deletions(-)
--- linux-m68k-2.6.21.orig/drivers/net/7990.c
+++ linux-m68k-2.6.21/drivers/net/7990.c
@@ -565,9 +565,9 @@ int lance_start_xmit (struct sk_buff *sk
ib-btx_ring [entry].length = (-len) | 0xf000;
ib-btx_ring [entry].misc = 0;
- if (skb-len ETH_ZLEN)
- memset((char *)ib-tx_buf[entry][0], 0, ETH_ZLEN);
-skb_copy_from_linear_data(skb, ib-tx_buf[entry][0], skblen);
+ if (skb-len ETH_ZLEN)
+ memset((void *)ib-tx_buf[entry][0], 0, ETH_ZLEN);
+skb_copy_from_linear_data(skb, (void *)ib-tx_buf[entry][0], skblen);
/* Now, give the packet to the lance */
ib-btx_ring [entry].tmd1_bits = (LE_T1_POK|LE_T1_OWN);
--- linux-m68k-2.6.21.orig/drivers/net/a2065.c
+++ linux-m68k-2.6.21/drivers/net/a2065.c
@@ -597,11 +597,11 @@ static int lance_start_xmit (struct sk_b
ib-btx_ring [entry].length = (-len) | 0xf000;
ib-btx_ring [entry].misc = 0;
- skb_copy_from_linear_data(skb, ib-tx_buf [entry][0], skblen);
+ skb_copy_from_linear_data(skb, (void *)ib-tx_buf [entry][0], skblen);
/* Clear the slack of the packet, do I need this? */
if (len != skblen)
- memset ((char *) ib-tx_buf [entry][skblen], 0, len - skblen);
+ memset ((void *) ib-tx_buf [entry][skblen], 0, len - skblen);
/* Now, give the packet to the lance */
ib-btx_ring [entry].tmd1_bits = (LE_T1_POK|LE_T1_OWN);
--- linux-m68k-2.6.21.orig/drivers/net/sun3_82586.c
+++ linux-m68k-2.6.21/drivers/net/sun3_82586.c
@@ -1023,10 +1023,11 @@ static int sun3_82586_send_packet(struct
{
len = skb-len;
if (len ETH_ZLEN) {
- memset((char *)p-xmit_cbuffs[p-xmit_count], 0,
ETH_ZLEN);
+ memset((void *)p-xmit_cbuffs[p-xmit_count], 0,
+ ETH_ZLEN);
len = ETH_ZLEN;
}
- skb_copy_from_linear_data(skb, p-xmit_cbuffs[p-xmit_count],
skb-len);
+ skb_copy_from_linear_data(skb, (void
*)p-xmit_cbuffs[p-xmit_count], skb-len);
#if (NUM_XMIT_BUFFS == 1)
# ifdef NO_NOPCOMMANDS
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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 27/33] m68k: macmace fixes
From: Finn Thain [EMAIL PROTECTED]
Fix a race condition in the transmit code, where the dma interrupt could update
the free tx buffer count concurrently and wedge the tx queue.
Fix the misuse of the rx frame status and rx frame length registers: no more
fifo overrun errors caused by the OFLOW bit being tested in the frame length
register (instead of the status register), and no more missed packets due to
incorrect length taken from status register (instead of the frame length
register).
Fix a panic (skb_over_panic BUG) caused by allocating and then copying an
incoming packet while the packet length register was changing.
Cut-and-paste the reset code from the powermac mace driver (mace.c), so the NIC
functions when MacOS does not initialise it (important for anyone wanting to
use the Emile boot loader).
Cut-and-paste the error counting and timeout recovery code from mace.c.
Fix over allocation of rx buffer memory (it's page order, not page count).
Converted to driver model.
Converted to DMA API.
Since I've run out of ways to make it fail, and since it performs well now,
promote the driver from EXPERIMENTAL status. Tested on both quadra 840av and
660av.
Signed-off-by: Finn Thain [EMAIL PROTECTED]
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/net/Kconfig |4
drivers/net/Space.c |4
drivers/net/macmace.c | 589 ++
3 files changed, 363 insertions(+), 234 deletions(-)
--- linux-m68k-2.6.21.orig/drivers/net/Kconfig
+++ linux-m68k-2.6.21/drivers/net/Kconfig
@@ -337,8 +337,8 @@ config MACSONIC
be called macsonic.
config MACMACE
- bool Macintosh (AV) onboard MACE ethernet (EXPERIMENTAL)
- depends on NET_ETHERNET MAC EXPERIMENTAL
+ bool Macintosh (AV) onboard MACE ethernet
+ depends on NET_ETHERNET MAC
select CRC32
help
Support for the onboard AMD 79C940 MACE Ethernet controller used in
--- linux-m68k-2.6.21.orig/drivers/net/Space.c
+++ linux-m68k-2.6.21/drivers/net/Space.c
@@ -83,7 +83,6 @@ extern struct net_device *bagetlance_pro
extern struct net_device *mvme147lance_probe(int unit);
extern struct net_device *tc515_probe(int unit);
extern struct net_device *lance_probe(int unit);
-extern struct net_device *mace_probe(int unit);
extern struct net_device *mac8390_probe(int unit);
extern struct net_device *mac89x0_probe(int unit);
extern struct net_device *mc32_probe(int unit);
@@ -274,9 +273,6 @@ static struct devprobe2 m68k_probes[] __
#ifdef CONFIG_MVME147_NET /* MVME147 internal Ethernet */
{mvme147lance_probe, 0},
#endif
-#ifdef CONFIG_MACMACE /* Mac 68k Quadra AV builtin Ethernet */
- {mace_probe, 0},
-#endif
#ifdef CONFIG_MAC8390 /* NuBus NS8390-based cards */
{mac8390_probe, 0},
#endif
--- linux-m68k-2.6.21.orig/drivers/net/macmace.c
+++ linux-m68k-2.6.21/drivers/net/macmace.c
@@ -12,6 +12,11 @@
* Copyright (C) 1998 Alan Cox [EMAIL PROTECTED]
*
* Modified heavily by Joshua M. Thompson based on Dave Huang's NetBSD
driver
+ *
+ * Copyright (C) 2007 Finn Thain
+ *
+ * Converted to DMA API, converted to unified driver model,
+ * sync'd some routines with mace.c and fixed various bugs.
*/
@@ -23,8 +28,9 @@
#include linux/string.h
#include linux/crc32.h
#include linux/bitrev.h
+#include linux/dma-mapping.h
+#include linux/platform_device.h
#include asm/io.h
-#include asm/pgtable.h
#include asm/irq.h
#include asm/macintosh.h
#include asm/macints.h
@@ -32,13 +38,20 @@
#include asm/page.h
#include mace.h
-#define N_TX_RING 1
-#define N_RX_RING 8
-#define N_RX_PAGES ((N_RX_RING * 0x0800 + PAGE_SIZE - 1) / PAGE_SIZE)
+static char mac_mace_string[] = macmace;
+static struct platform_device *mac_mace_device;
+
+#define N_TX_BUFF_ORDER0
+#define N_TX_RING (1 N_TX_BUFF_ORDER)
+#define N_RX_BUFF_ORDER3
+#define N_RX_RING (1 N_RX_BUFF_ORDER)
+
#define TX_TIMEOUT HZ
-/* Bits in transmit DMA status */
-#define TX_DMA_ERR 0x80
+#define MACE_BUFF_SIZE 0x800
+
+/* Chip rev needs workaround on HW multicast addr change */
+#define BROKEN_ADDRCHG_REV 0x0941
/* The MACE is simply wired down on a Mac68K box */
@@ -47,40 +60,46 @@
struct mace_data {
volatile struct mace *mace;
- volatile unsigned char *tx_ring;
- volatile unsigned char *tx_ring_phys;
- volatile unsigned char *rx_ring;
- volatile unsigned char *rx_ring_phys;
+ unsigned char *tx_ring;
+ dma_addr_t tx_ring_phys;
+ unsigned char *rx_ring;
+ dma_addr_t rx_ring_phys;
int dma_intr;
struct net_device_stats stats;
int rx_slot, rx_tail;
int tx_slot, tx_sloti, tx_count;
+ int chipid;
+ struct device *device;
};
struct mace_frame {
- u16 len;
- u16 status;
- u16 rntpc;
- u16 rcvcc;
- u32 pad1;
- u32
[patch 20/33] m68k: Mac DP8390 update
From: Finn Thain [EMAIL PROTECTED]
Fix the support for C/NET nubus ethernet cards etc. Sync up the DP8390 driver
with the latest code in the mac68k repo.
Signed-off-by: Finn Thain [EMAIL PROTECTED]
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/net/mac8390.c | 245 +++---
1 file changed, 175 insertions(+), 70 deletions(-)
--- linux-m68k-2.6.21.orig/drivers/net/mac8390.c
+++ linux-m68k-2.6.21/drivers/net/mac8390.c
@@ -14,6 +14,8 @@
/* 2001-05-15: support for Cabletron ported from old daynaport driver
* and fixed access to Sonic Sys card which masquerades as a Farallon
* by [EMAIL PROTECTED] */
+/* 2002-12-30: Try to support more cards, some clues from NetBSD driver */
+/* 2003-12-26: Make sure Asante cards always work. */
#include linux/module.h
#include linux/kernel.h
@@ -61,25 +63,21 @@ static char version[] =
#define DAYNA_8390_BASE0x8
#define DAYNA_8390_MEM 0x0
-#define KINETICS_8390_BASE 0x8
-#define KINETICS_8390_MEM 0x0
-
#define CABLETRON_8390_BASE0x9
#define CABLETRON_8390_MEM 0x0
+#define INTERLAN_8390_BASE 0xE
+#define INTERLAN_8390_MEM 0xD
+
enum mac8390_type {
MAC8390_NONE = -1,
MAC8390_APPLE,
MAC8390_ASANTE,
- MAC8390_FARALLON, /* Apple, Asante, and Farallon are all compatible */
+ MAC8390_FARALLON,
MAC8390_CABLETRON,
MAC8390_DAYNA,
MAC8390_INTERLAN,
MAC8390_KINETICS,
- MAC8390_FOCUS,
- MAC8390_SONICSYS,
- MAC8390_DAYNA2,
- MAC8390_DAYNA3,
};
static const char * cardname[] = {
@@ -90,10 +88,6 @@ static const char * cardname[] = {
dayna,
interlan,
kinetics,
- focus,
- sonic systems,
- dayna2,
- dayna_lc,
};
static int word16[] = {
@@ -104,10 +98,6 @@ static int word16[] = {
0, /* dayna */
1, /* interlan */
0, /* kinetics */
- 1, /* focus (??) */
- 1, /* sonic systems */
- 1, /* dayna2 */
- 1, /* dayna-lc */
};
/* on which cards do we use NuBus resources? */
@@ -119,10 +109,12 @@ static int useresources[] = {
0, /* dayna */
0, /* interlan */
0, /* kinetics */
- 0, /* focus (??) */
- 1, /* sonic systems */
- 1, /* dayna2 */
- 1, /* dayna-lc */
+};
+
+enum mac8390_access {
+ ACCESS_UNKNOWN = 0,
+ ACCESS_32,
+ ACCESS_16,
};
extern enum mac8390_type mac8390_ident(struct nubus_dev * dev);
@@ -134,8 +126,9 @@ static int mac8390_initdev(struct net_de
static int mac8390_open(struct net_device * dev);
static int mac8390_close(struct net_device * dev);
static void mac8390_no_reset(struct net_device *dev);
+static void interlan_reset(struct net_device *dev);
-/* Sane (32-bit chunk memory read/write) - Apple/Asante/Farallon do this*/
+/* Sane (32-bit chunk memory read/write) - Some Farallon and Apple do this*/
static void sane_get_8390_hdr(struct net_device *dev,
struct e8390_pkt_hdr *hdr, int ring_page);
static void sane_block_input(struct net_device * dev, int count,
@@ -172,23 +165,93 @@ static void word_memcpy_fromcard(void *t
enum mac8390_type __init mac8390_ident(struct nubus_dev * dev)
{
- if (dev-dr_sw == NUBUS_DRSW_ASANTE)
- return MAC8390_ASANTE;
- if (dev-dr_sw == NUBUS_DRSW_FARALLON)
- return MAC8390_FARALLON;
- if (dev-dr_sw == NUBUS_DRSW_KINETICS)
- return MAC8390_KINETICS;
- if (dev-dr_sw == NUBUS_DRSW_DAYNA)
- return MAC8390_DAYNA;
- if (dev-dr_sw == NUBUS_DRSW_DAYNA2)
- return MAC8390_DAYNA2;
- if (dev-dr_sw == NUBUS_DRSW_DAYNA_LC)
- return MAC8390_DAYNA3;
- if (dev-dr_hw == NUBUS_DRHW_CABLETRON)
- return MAC8390_CABLETRON;
+ switch (dev-dr_sw) {
+ case NUBUS_DRSW_3COM:
+ switch (dev-dr_hw) {
+ case NUBUS_DRHW_APPLE_SONIC_NB:
+ case NUBUS_DRHW_APPLE_SONIC_LC:
+ case NUBUS_DRHW_SONNET:
+ return MAC8390_NONE;
+ break;
+ default:
+ return MAC8390_APPLE;
+ break;
+ }
+ break;
+
+ case NUBUS_DRSW_APPLE:
+ switch (dev-dr_hw) {
+ case NUBUS_DRHW_ASANTE_LC:
+ return MAC8390_NONE;
+ break;
+ case NUBUS_DRHW_CABLETRON:
+ return MAC8390_CABLETRON;
+ break;
+ default:
+
[patch 16/33] m68k: Amiga A2065 and Ariadne TX statistics
Add missing code to the Amiga A2065 and Ariadne drivers to update
net_device_stats.tx_bytes.
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/net/a2065.c |4 +---
drivers/net/ariadne.c |1 +
2 files changed, 2 insertions(+), 3 deletions(-)
--- linux-m68k-2.6.21.orig/drivers/net/a2065.c
+++ linux-m68k-2.6.21/drivers/net/a2065.c
@@ -562,7 +562,6 @@ static int lance_start_xmit (struct sk_b
volatile struct lance_init_block *ib = lp-init_block;
int entry, skblen, len;
int status = 0;
- static int outs;
unsigned long flags;
skblen = skb-len;
@@ -607,8 +606,7 @@ static int lance_start_xmit (struct sk_b
/* Now, give the packet to the lance */
ib-btx_ring [entry].tmd1_bits = (LE_T1_POK|LE_T1_OWN);
lp-tx_new = (lp-tx_new+1) lp-tx_ring_mod_mask;
-
- outs++;
+ lp-stats.tx_bytes += skblen;
if (TX_BUFFS_AVAIL = 0)
netif_stop_queue(dev);
--- linux-m68k-2.6.21.orig/drivers/net/ariadne.c
+++ linux-m68k-2.6.21/drivers/net/ariadne.c
@@ -677,6 +677,7 @@ static int ariadne_start_xmit(struct sk_
priv-cur_tx -= TX_RING_SIZE;
priv-dirty_tx -= TX_RING_SIZE;
}
+priv-stats.tx_bytes += len;
/* Trigger an immediate send poll. */
lance-RAP = CSR0; /* PCnet-ISA Controller Status */
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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 07/33] m68k: Mac89x0 Ethernet netif updates
From: Matthias Urlichs [EMAIL PROTECTED]
Macintosh CS89x0 Ethernet: Netif updates
Addition of netif_stop_queue() before transmission by Michael Schmitz
skb_copy_{from,to}_linear_data() conversion by Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/net/Kconfig |2 -
drivers/net/mac89x0.c | 92 ++
2 files changed, 35 insertions(+), 59 deletions(-)
--- linux-m68k-2.6.21.orig/drivers/net/Kconfig
+++ linux-m68k-2.6.21/drivers/net/Kconfig
@@ -311,7 +311,7 @@ config MAC8390
config MAC89x0
tristate Macintosh CS89x0 based ethernet cards
- depends on NET_ETHERNET MAC BROKEN
+ depends on NET_ETHERNET MAC
---help---
Support for CS89x0 chipset based Ethernet cards. If you have a
Nubus or LC-PDS network (Ethernet) card of this type, say Y and
--- linux-m68k-2.6.21.orig/drivers/net/mac89x0.c
+++ linux-m68k-2.6.21/drivers/net/mac89x0.c
@@ -128,7 +128,7 @@ struct net_local {
extern void reset_chip(struct net_device *dev);
#endif
static int net_open(struct net_device *dev);
-static int net_send_packet(struct sk_buff *skb, struct net_device *dev);
+static int net_send_packet(struct sk_buff *skb, struct net_device *dev);
static irqreturn_t net_interrupt(int irq, void *dev_id);
static void set_multicast_list(struct net_device *dev);
static void net_rx(struct net_device *dev);
@@ -374,56 +374,39 @@ net_open(struct net_device *dev)
static int
net_send_packet(struct sk_buff *skb, struct net_device *dev)
{
- if (dev-tbusy) {
- /* If we get here, some higher level has decided we are broken.
- There should really be a kick me function call instead. */
- int tickssofar = jiffies - dev-trans_start;
- if (tickssofar 5)
- return 1;
- if (net_debug 0) printk(%s: transmit timed out, %s?\n,
dev-name,
- tx_done(dev) ? IRQ conflict : network cable
problem);
- /* Try to restart the adaptor. */
- dev-tbusy=0;
- dev-trans_start = jiffies;
- }
-
- /* Block a timer-based transmit from overlapping. This could better be
- done with atomic_swap(1, dev-tbusy), but set_bit() works as well. */
- if (test_and_set_bit(0, (void*)dev-tbusy) != 0)
- printk(%s: Transmitter access conflict.\n, dev-name);
- else {
- struct net_local *lp = netdev_priv(dev);
- unsigned long flags;
-
- if (net_debug 3)
- printk(%s: sent %d byte packet of type %x\n,
- dev-name, skb-len,
- (skb-data[ETH_ALEN+ETH_ALEN] 8)
- | skb-data[ETH_ALEN+ETH_ALEN+1]);
-
- /* keep the upload from being interrupted, since we
- ask the chip to start transmitting before the
- whole packet has been completely uploaded. */
- local_irq_save(flags);
-
- /* initiate a transmit sequence */
- writereg(dev, PP_TxCMD, lp-send_cmd);
- writereg(dev, PP_TxLength, skb-len);
-
- /* Test to see if the chip has allocated memory for the packet
*/
- if ((readreg(dev, PP_BusST) READY_FOR_TX_NOW) == 0) {
- /* Gasp! It hasn't. But that shouldn't happen since
- we're waiting for TxOk, so return 1 and requeue this
packet. */
- local_irq_restore(flags);
- return 1;
- }
+ struct net_local *lp = netdev_priv(dev);
+ unsigned long flags;
- /* Write the contents of the packet */
- memcpy_toio(dev-mem_start + PP_TxFrame, skb-data, skb-len+1);
+ if (net_debug 3)
+ printk(%s: sent %d byte packet of type %x\n,
+ dev-name, skb-len,
+ (skb-data[ETH_ALEN+ETH_ALEN] 8)
+ | skb-data[ETH_ALEN+ETH_ALEN+1]);
+
+ /* keep the upload from being interrupted, since we
+ ask the chip to start transmitting before the
+ whole packet has been completely uploaded. */
+ local_irq_save(flags);
+ netif_stop_queue(dev);
+ /* initiate a transmit sequence */
+ writereg(dev, PP_TxCMD, lp-send_cmd);
+ writereg(dev, PP_TxLength, skb-len);
+
+ /* Test to see if the chip has allocated memory for the packet */
+ if ((readreg(dev, PP_BusST) READY_FOR_TX_NOW) == 0) {
+ /* Gasp! It hasn't. But that shouldn't happen since
+ we're waiting for TxOk, so return 1 and requeue this packet.
*/
local_irq_restore(flags);
- dev-trans_start = jiffies;
+ return 1;
}
+
+ /* Write the contents of the packet */
+
Re: r8169 ethernet bonding problems
Tim Durack [EMAIL PROTECTED] : [...] Still Have a problem with links randomly failing to achieve link on boot. This then requires a modprobe -r r8169; modprobe r8169 cycle to get link. Side effect is the mac address corruption I have described previously. Can you try to set the MAC address by hand with the completely patched kernel (i.e. including the mac-address-change patch) ? Given the last report in http://bugzilla.kernel.org/show_bug.cgi?id=6032, it should be straightforward with your Debian system. No clear idea why your three cards are not handled the same though. -- Ueimor Anybody got a battery for my Ultra 10 ? - 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
Telnet closing delay
Since 2.6.21 I often got a 2 seconds delay when closing a telnet session to such a machine (even to localhost). I was at least not aware of this with older versions, but maybe I'm wrong?!? Client with delay: 0.62 select(4, [0 3], [], [3], NULL) = 1 (in [3]) 1.803057 recvfrom(3, , 8192, 0, NULL, NULL) = 0 without delay: 0.61 select(4, [0 3], [], [3], NULL) = 1 (in [3]) 0.001491 recvfrom(3, , 8192, 0, NULL, NULL) = 0 Server with delay: 0.95 select(4, [0 3], [], [0], NULL) = 1 (in [3]) 0.001779 read(3, 0x8059de0, 8192) = -1 EIO (Input/output error) 0.000103 select(4, [0 3], [], [0], NULL) = 1 (in [3]) 0.000171 read(3, 0x8059de0, 8192) = -1 EIO (Input/output error) and 1 lines more of this select/read 0.000103 select(4, [0 3], [], [0], NULL) = 1 (in [3]) 0.000343 --- SIGCHLD (Child exited) @ 0 (0) --- without delay: 0.000100 select(4, [0 3], [], [0], NULL) = 1 (in [3]) 0.001757 --- SIGCHLD (Child exited) @ 0 (0) --- Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 07/33] m68k: Mac89x0 Ethernet netif updates
Geert Uytterhoeven wrote:
From: Matthias Urlichs [EMAIL PROTECTED]
Macintosh CS89x0 Ethernet: Netif updates
Addition of netif_stop_queue() before transmission by Michael Schmitz
skb_copy_{from,to}_linear_data() conversion by Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/net/Kconfig |2 -
drivers/net/mac89x0.c | 92 ++
2 files changed, 35 insertions(+), 59 deletions(-)
The ethernet patches I've seen so far look sane to me... ACK.
Since they were addressed to Linus and Andrew, I will presume that one
of those two penguins will apply your drivers/net/* patches.
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: r8169 ethernet bonding problems
Can you try to set the MAC address by hand with the completely patched kernel (i.e. including the mac-address-change patch) ? Yup. Works fine. The randomly changing interface order is proving to be a challenge! Given the last report in http://bugzilla.kernel.org/show_bug.cgi?id=6032, it should be straightforward with your Debian system. No clear idea why your three cards are not handled the same though. - 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] zd1211rw-mac80211: limit URB buffering in tx path
On Tue, 1 May 2007 21:50:08 +0200, Ulrich Kunitz wrote: On 07-05-01 12:34 Jiri Benc wrote: On Tue, 1 May 2007 04:01:00 +0100 (BST), Daniel Drake wrote: The old code allowed unlimited buffing of tx frames in URBs submitted for transfer to the device. This patch stops the ieee80211_hw queue(s) if to many URBs are ready for submit to the device. Actually the ZD1211 device supports currently only one queue. This doesn't look correct to me. The limits should be per queue and you should always stop queues selectively. The old ZD1211 chip doesn't support queuing and the new ZD1211B chip has support, but it is unclear how to put packets in the different queues. However the error condition here is, that packets can't be transmitted over the USB, which will affect all queues. Really? From what you wrote (if too many URBs are ready for submit) it seems that the code is triggered when the queue is just full. That's not necessarily an error condition and the only thing needed to do is to stop the queue. Unless zd1211 is really special here (and then I'd like to know how is it special). Sure one could manage different high level marks for the different queues, but this is all theoretical currently. I could have coded with the explicit knowledge that we support only one queue, but it is really work the hassle. If you support one queue only, call ieee80211_stop_queue(hw, 0). Calling ieee80211_stop_queues if you have just a full queue is wrong. Thanks, Jiri -- Jiri Benc SUSE Labs - 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: r8169 ethernet bonding problems
Tim Durack [EMAIL PROTECTED] : Can you try to set the MAC address by hand with the completely patched kernel (i.e. including the mac-address-change patch) ? Yup. Works fine. The randomly changing interface order is proving to be a challenge! udev should be your friend to do a BUS/ID based rename. -- Ueimor Anybody got a battery for my Ultra 10 ? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8405] New: pppd does stops compresion with Lost compression sync
On Tue, 2007-05-01 at 09:27 +0200, Stefan Wenk wrote:
Now I have changed these modifications
back, and I do not see more debug information except those below:
z_decompress0: Would have triggered an error as inflate returned -5 ()
z_decompress0: Would have triggered an error as inflate returned -5 ()
z_decompress0: Would have triggered an error as inflate returned -5 ()
..
As there are no debug logs in inflate.c I can't provide more information by
now.
I had a look at that trace you sent, the echo and replys were normal but
obviously something is going wrong and it tries to negotiate turning off
the compression...
Having looked at the code a bit further, I have a theory that it was
impossible to reach the zlib_inflateSyncPacket call ppp deflate needs.
The patch below fixes that and also adds some debugging so if that isn't
the problem, we might get some further clues as to what the problem
is...
Thanks for the patience :)
Richard
Index: linux/drivers/net/ppp_deflate.c
===
--- linux.orig/drivers/net/ppp_deflate.c2007-01-18 00:52:50.0
+
+++ linux/drivers/net/ppp_deflate.c 2007-05-01 22:21:27.0 +0100
@@ -488,6 +488,13 @@ int z_decompress(void *arg, unsigned cha
for (;;) {
r = zlib_inflate(state-strm, Z_PACKET_FLUSH);
if (r != Z_OK) {
+ printk(KERN_ERR z_decompress%d: inflate returned %d
(%s)
+ ,av in %d, av out %d, t in %ld, t out %ld, dp
%d,
+of %d, is %d, os %d\n,
+ state-unit, r, (state-strm.msg?
state-strm.msg: ),
+ state-strm.avail_in, state-strm.avail_out,
+ state-strm.total_in, state-strm.total_out,
+ decode_proto, overflow, isize, osize);
if (state-debug)
printk(KERN_DEBUG z_decompress%d: inflate
returned %d (%s)\n,
state-unit, r, (state-strm.msg?
state-strm.msg: ));
Index: linux/lib/zlib_inflate/inflate.c
===
--- linux.orig/lib/zlib_inflate/inflate.c 2007-01-18 00:53:08.0
+
+++ linux/lib/zlib_inflate/inflate.c2007-05-01 22:03:53.0 +0100
@@ -743,12 +743,14 @@ int zlib_inflate(z_streamp strm, int flu
strm-data_type = state-bits + (state-last ? 64 : 0) +
(state-mode == TYPE ? 128 : 0);
-if (((in == 0 out == 0) || flush == Z_FINISH) ret == Z_OK)
-ret = Z_BUF_ERROR;
if (flush == Z_PACKET_FLUSH ret == Z_OK
(strm-avail_out != 0 || strm-avail_in == 0))
return zlib_inflateSyncPacket(strm);
+
+if (((in == 0 out == 0) || flush == Z_FINISH) ret == Z_OK)
+ret = Z_BUF_ERROR;
+
return ret;
}
-
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: Natsemi DP83815 driver spaming
On Tue, May 01, 2007 at 09:52:30PM +0200, Rafał Bilski wrote: * 2) check for sudden death of the NIC: *It seems that a reference set for this chip went out with incorrect info, *and there exist boards that aren't quite right. An unexpected voltage *drop can cause the PHY to get itself in a weird state (basically reset). *NOTE: this only seems to affect revC chips. Code commented out and NIC is working OK. Strange. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. dspcfg = 0x np-dspcfg = 0x5060 Oh, that's entertaining. I have to confess that I've never seen an that triggered the workaround before - adding the maintainer, Tim Hockin, who may be able to shed some light on the expected behaviour here? -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: [ofa-general] Re: IPoIB forwarding
On 4/30/2007 2:12 PM, Rick Jones wrote: Speaking of defaults, it would seem that the external 1.2.0 driver comes with 9000 bytes as the default MTU? At least I think that is what I am seeing now that I've started looking more closely. rick jones That's the same for the in-kernel-tree code (9K MTU by default). Assuming this is not wanted, I will submit a patch for that. Loic - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bonding two 802.1q interfaces triggers sleeping function called from invalid context
On Tue, May 01, 2007 at 01:33:26PM -0700, Jay Vosburgh wrote: Andy Gospodarek [EMAIL PROTECTED] wrote: I need to use a bonding through two 802.1q tag VLAN virtual interface in the same physical network interface. When I bond interface with command : ifenslave bond0 eth1.10 eth1.20 Console and dmesg will continues report BUG: --Output1 begin kernel 2.6.20-1.2933.fc6 BUG: sleeping function called from invalid context at include/asm/uaccess.h:500 in_atomic():1, irqs_disabled():0 [c04ecadb] copy_from_user+0x35/0x66 [c05c2e78] dev_ethtool+0x51/0xa0d [c05ee503] tcp_current_mss+0x71/0xdf [c05ee169] tcp_rcv_established+0x74f/0x7de [c04cf48f] selinux_netlbl_sock_rcv_skb+0x1d/0x5b [c05f3a78] tcp_v4_do_rcv+0x1bf/0x49c [c05f5f1b] tcp_v4_rcv+0x564/0x8b1 [d8a3ac03] vlan_dev_ioctl+0x7b/0xa7 [8021q] [d8a3ab88] vlan_dev_ioctl+0x0/0xa7 [8021q] [d8a53102] bond_update_speed_duplex+0x88/0xd7 [bonding] [d8a5688e] bond_mii_monitor+0x0/0x403 [bonding] [d8a56c01] bond_mii_monitor+0x373/0x403 [bonding] Jay Vosburgh and I have been working on something to address this and other issues related to possible sleeping activities that might come from the monitoring functions. I feel like we are getting close to something so I hope we can post something soon. Care to add anything, Jay? I was thinking about this one a couple of days ago; it's a little tricky to get out of, since we nominally need to do the ethtool calls holding only rtnl, but don't want to cycle rtnl for each monitor pass. The warning only shows up with VLANs because VLAN get_settings() calls dev_ethtool() directly, and the copy_from_user() in dev_ethtool() is the complaining party here. Agreed. All locks held when calling bond_update_speed_duplex for a vlan interface and need to be non bh-locks and the call needs to be done as a user-process. This might be hard to avoid with bond_enslave but could be avoided with some code restructing. Calling an end device driver's get_settings() directly doesn't trigger the warning. I think that's safe without rtnl (at least insofar as the slave won't vanish), since the slave cannot vanish without bonding being notified via the NETDEV_UNREGISTER notifier. This does look to be something specific to vlan interfaces being enslaved. Which makes me wonder: Why are we supporting that anyway? I *guess* there might be some crazy network admin that might like this, but it doesn't seem right... -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 - 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] IPROUTE: Modify tc for new PRIO multiqueue behavior
On Tue, 2007-01-05 at 11:27 -0700, Waskiewicz Jr, Peter P wrote: My patches have been under discussion for a few months, and the general approach has been fairly well-accepted. The comments that David, Patrick, and Thomas have given were more on implementation, which have been fixed and are what you see today. So if you don't like my approach, then please provide an alternative. I have provided you an alternative - maybe it is unclear and in which case i will be willing to explain again. It really doesnt matter if i look at the patch. Unless you are challenging my knowledge of that subsystem, I am not gonna comment on the semantics of you missing a comma or space somewhere because my disagreements are on your conceptual approach; it is therefore irrelvant to me that 10 other people have given you comments on your code. I am not questioning your (probably) great coding skills. I have provided you an alternative if you try to listen. An alternative that doesnt require big changes that you are making or break the assumed layering we have. Please explain why this is a brute force approach. Today, netdev gives drivers an API to manage the device queue (dev-queue_lock). I extended this to provide a management API to manage each queue on a device. This to me makes complete sense; why hide the fact a device has multiple queues from the kernel? I don't understand your comments here. What i meant by brute force was you could move all the management into the driver. For example, you could put additional software queues in the driver that hold things that dont fit into rings. I said this was better because nothing is touched in the core code. An API to me is a function call; the device queue managemnt is the tx state transition. If this is still not clear, just ignore it because it is a distraction. The real core is further below. E1000 is not strict prio scheduling, rather, it is round-robin. This question was posed by Patrick McHardy on netdev and I answered it 2 weeks ago. RR would fit just fine as well in what i described. I gave prio qdisc as an example because you were modifying it and because it covers the majority of the devices i have seen out there that implement multi-queueing. As i said further, what i described can be extended to any scheduling algorithm: strict prio, WRR etc. I just want you to understand what i am describing; and if you want i can show you how it would work for a scheduler of your choice. I am making the assumptions that: a) you understand the basics of strict prio scheduling b) You have configured strict prio in the qdisc level and the hardware levels to be synced i.e if your hardware is capable of only strict prio, then you better use a matching strict prio qdisc (and not another qdisc like HTB etc). If your hardware is capable 2 queues, you better have your qdisc with only two bands. I disagree. If you read Patrick's comments, using strict PRIO in software and in hardware will probably give you results you don't want. That was based on how your patches work. It is also why you would need to say multiqueue in the tc config. Why do 2 layers of QoS? Look at it this way: Linux already has the necessary qdiscs; if there is one or two missing, writing it will solve your problem. This way both single-hw-queue and multi-hw-queue hardware benefit from any new qdisc. I dont need a speacilized qdisc just because i have multiqueue hardware. More importantly, you dont need to make core code changes. You may need to add a new qdisc if it doesnt exist; but you can do that without mucking with the core code. It is clean. If your hardware has a hardware-based QoS, then you should have a generic round-robin (unassuming) qdisc above it. If your hardware has RR scheduling, then you better be fair in feeding that scheduler packets in a RR fashion otherwise bad things would happen. Thats the basis of #b. I probably misunderstood your wording, you seem to be saying the opposite. I don't understand why you would ever want to do 2 layers of prioritization; this is just unnecessary work for the CPU to be doing. And if you see how my patches to PRIO are working, you'd see that it allows a user to choose as many bands as he/she wants, and they will be assigned to the underlying hardware queues. This is very similar to the mapping that the 802.1p spec calls out for how to map many priorities to fewer queues. No big deal: It is what the prio qdisc has been doing since the dinosaur days; c) If you programmed a TOS, DSCP , IEEE 802.1p to go to qdisc queue PH via some classifier, then you will make sure that packets from qdisc PH end up in hardware queue PH. Not following #b and #c means it is a misconfiguration; i hope we can agree on that. i.e you need to have both the exact qdisc that maps to your hardware qdisc as well as synced configuration between the two layers. Please see my comments above.
Re: [ofa-general] Re: IPoIB forwarding
Loic Prylli wrote: On 4/30/2007 2:12 PM, Rick Jones wrote: Speaking of defaults, it would seem that the external 1.2.0 driver comes with 9000 bytes as the default MTU? At least I think that is what I am seeing now that I've started looking more closely. rick jones That's the same for the in-kernel-tree code (9K MTU by default). Assuming this is not wanted, I will submit a patch for that. While I like what that does for perrformance, and at the risk of putting words into the mouths of netdev, I suspect that 1500 bytes is indeed the desired default. It matches the IEEE specs, I've yet to see a switch which enabled Jumbo Frames by default, not everything out there even believes that Jubmo Frames means 9000 byte MTU etc etc etc. I think that 1500 bytes for an Ethernet device remains in line with the principle of least surprise. rick jones - 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] zd1211rw-mac80211: limit URB buffering in tx path
On 07-05-01 23:10 Jiri Benc wrote: Really? From what you wrote (if too many URBs are ready for submit) it seems that the code is triggered when the queue is just full. That's not necessarily an error condition and the only thing needed to do is to stop the queue. Unless zd1211 is really special here (and then I'd like to know how is it special). Jiri, even if ZD1211B supports multiple queues, there is only one USB endpoint receiving packets for transmission. I suppose that the queue for the packet can be set in the control data for the packet. However if the device doesn't read USB blocks anymore, all queues will be affected. At this point in time I have to stop all queues. Sure I could care for the different priorities of the queues by stopping low-priority queues earlier, but if the user is overloading the device, I have to stop all queues. If you support one queue only, call ieee80211_stop_queue(hw, 0). Calling ieee80211_stop_queues if you have just a full queue is wrong. Again I don't just have a full queue, I cannot send any packets to the device anymore. Under this condition I simply stop all queues, not caring whether there are 1 or 1024. Sure with the explicit knowledge that I have only one queue, I could stop it explicitly, but this would require a change of the code as soon as a second queue comes into play. -- Uli Kunitz - 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] make myri10ge use default MTU of 1500 bytes
Change default MTU from jumbo (9000) to standard (1500) for myri10ge Signed-off-by: Loic Prylli [EMAIL PROTECTED] --- drivers/net/myri10ge/myri10ge.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c index 16e3c43..0e9cc17 100644 --- a/drivers/net/myri10ge/myri10ge.c +++ b/drivers/net/myri10ge/myri10ge.c @@ -252,7 +252,7 @@ module_param(myri10ge_force_firmware, int, S_IRUGO); MODULE_PARM_DESC(myri10ge_force_firmware, Force firmware to assume aligned completions\n); -static int myri10ge_initial_mtu = MYRI10GE_MAX_ETHER_MTU - ETH_HLEN; +static int myri10ge_initial_mtu = 1500; module_param(myri10ge_initial_mtu, int, S_IRUGO); MODULE_PARM_DESC(myri10ge_initial_mtu, Initial MTU\n); -- 1.5.0.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
RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
If that queue is stopped, the qdisc will never get called to run and -dequeue(), and hard_start_xmit() will never be called. yes, that is true (and the desired intent) That intent is not what we want with our approach. The desired intent is to have independent network flows from the kernel, through the qdisc layer, into the NIC, and onto the wire. No flow should have the ability to interfere with another flow's operation unless the device itself shuts down, or a link-based flow control event occurs. I see little to no benefit of enabling multiqueue in a driver when all you'll get is essentially one pipe of traffic, since the granularity of the management of those queues is rough to the kernel. I guess this is the source of our differing views. The kernel is already multiqueue capable. Thats what qdiscs do. The kernel is multiqueue capable to enqueue in software. It is not multiqueue capable when dequeuing to a NIC with multiple queues. They dequeue based on dev-state, which is single-threaded. These patches are the glue to make the multiple queues in software hook to the multiple queues in the driver directly. Heres what i see the differences to be: 1) You want to change the core code; i dont see a need for that. The packet is received by the driver and netif stop works as before, with zero changes; the driver shuts down on the first ring full. The only work is mostly driver specific. To me, this doesn't buy you anything to do multiqueue only in the driver. I agree the driver needs work to manage the queues in the hardware, but if a single feeder from the kernel is handing it packets, you gain nothing in my opinion without granularity of stopping/starting each queue in the kernel. 2) You want to change qdiscs to make them multi-queue specific. I only see a need for adding missing schedulers (if they are missing) and not having some that work with multiqueues and other that dont. The assumption is that you have mappings between qdisc and hw-rings. The changes to PRIO are an initial example of getting my multiqueue approach working. This is the only qdisc I see being a logical change for multiqueue; other qdiscs can certainly be added in the future, which I plan on once multiqueue device support is in the kernel in some form. 3) For me: It is a driver change mostly. A new qdisc may be needed - but thats about it. I guess this is a fundamental difference in our thinking. I think of multiqueue as the multiple paths out of the kernel, being managed by per-queue states. If that is the case, the core code has to be changed at some level, specifically in dev_queue_xmit(), so it can check the state of the subqueue your skb has been associated with (skb-queue_mapping in my patchset). The qdisc needs to comprehend how to classify the skb (using TOS or TC) and assign the queue on the NIC to transmit on. My question to you is this: can you explain the benefit of not allowing the kernel to know of and be able to manage the queues on the NIC? This seems to be the heart of our disagreement; I view the ability to manage these queues from the kernel as being true multiqueue, and view doing the queue management solely in the driver as something that doesn't give any benefit. 4) You counter-argue that theres no need for QoS at the qdisc if the hardware does it; i am counter-counter-arguing if you need to write a new scheduler, it will benefit the other single-hwqueue devices. Not sure I completely understand this, but this an external argument to the core discussion; let's leave this until we can agree on the actual multiqueue network device support implementation. These emails are getting too long - typically people loose interest sooner. In your response, can you perhaps restrict it to just that last part and add anything you deem important? Yes, long emails are bad. I appreciate your efforts to come up to speed on what we've done here, and offering your viewpoints. Hopefully we can come to an agreement of some sort soon, since this work has been going on for some time to be halted after quite a bit of engineering and community feedback. Thanks Jamal, -PJ Waskiewicz - 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] zd1211rw-mac80211: limit URB buffering in tx path
On Wed, 2 May 2007 00:40:45 +0200, Ulrich Kunitz wrote: Jiri, even if ZD1211B supports multiple queues, there is only one USB endpoint receiving packets for transmission. I suppose that the queue for the packet can be set in the control data for the packet. However if the device doesn't read USB blocks anymore, all queues will be affected. Ah, that's stupid. I hope nobody is advertising these devices have a decent QoS support. At this point in time I have to stop all queues. Sure I could care for the different priorities of the queues by stopping low-priority queues earlier, but if the user is overloading the device, I have to stop all queues. Or you can split the available buffer space in the device, i.e. reserve some fixed part for the first queue, some part for the second queue, etc. Otherwise, the QoS is not so useful (you will still profit from the shorter backoff, of course, so it's not completely useless). But I don't know how many urbs the device can accept, it may not be feasible to do that. (But if it can accept reasonable amount of urbs, I'd suggest to implement that. It will need some testing to see whether it really improves something or not, though.) If you support one queue only, call ieee80211_stop_queue(hw, 0). Calling ieee80211_stop_queues if you have just a full queue is wrong. Again I don't just have a full queue, I cannot send any packets to the device anymore. Under this condition I simply stop all queues, not caring whether there are 1 or 1024. Okay, ACK then. Thanks for the clarification, Jiri -- Jiri Benc SUSE Labs - 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/20][BNX2]: Bug fixes and more 5709 suppot.
David, please review and apply the following patches that will follow. The firmware patches 6-11 will be sent to you off-list due to large size. [PATCH 1/20][BNX2]: Block MII access when ifdown. [PATCH 2/20][BNX2]: Fix register and memory test on 5709. [PATCH 3/20][BNX2]: Add 40-bit DMA workaround for 5708. [PATCH 4/20][BNX2]: Fix race conditions when calling register_netdev(). [PATCH 5/20][BNX2]: Save PCI state during suspend. [PATCH 6/20][BNX2]: Update 5708 firmware. [PATCH 7/20][BNX2]: Update 5709 firmware part 1. [PATCH 8/20][BNX2]: Update 5709 firmware part 2. [PATCH 9/20][BNX2]: Update 5709 firmware part 3. [PATCH 10/20][BNX2]: Update 5709 firmware part 4. [PATCH 11/20][BNX2]: Update 5709 firmware part 5. [PATCH 12/20][BNX2]: Add ipv6 TSO and checksum for 5709. [PATCH 13/20][BNX2]: Put MII register offsets in the bnx2 struct. [PATCH 14/20][BNX2]: Re-structure the 2.5G Serdes code. [PATCH 15/20][BNX2]: Add support for 5709 Serdes. [PATCH 16/20][BNX2]: Add indirect spinlock. [PATCH 17/20][BNX2]: Enhance the heartbeat. [PATCH 18/20][BNX2]: Add 1-shot MSI handler for 5709. [PATCH 19/20][BNX2]: Print bus information for PCIE devices. [PATCH 20/20][BNX2]: Update version and reldate. - 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/20][BNX2]: Block MII access when ifdown.
[BNX2]: Block MII access when ifdown.
The device may be in D3hot state and should not allow MII register
access.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index f98a220..9f0a067 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -5562,6 +5562,9 @@ bnx2_ioctl(struct net_device *dev, struct ifreq *ifr, int
cmd)
case SIOCGMIIREG: {
u32 mii_regval;
+ if (!netif_running(dev))
+ return -EAGAIN;
+
spin_lock_bh(bp-phy_lock);
err = bnx2_read_phy(bp, data-reg_num 0x1f, mii_regval);
spin_unlock_bh(bp-phy_lock);
@@ -5575,6 +5578,9 @@ bnx2_ioctl(struct net_device *dev, struct ifreq *ifr, int
cmd)
if (!capable(CAP_NET_ADMIN))
return -EPERM;
+ if (!netif_running(dev))
+ return -EAGAIN;
+
spin_lock_bh(bp-phy_lock);
err = bnx2_write_phy(bp, data-reg_num 0x1f, data-val_in);
spin_unlock_bh(bp-phy_lock);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/20][BNX2]: Fix register and memory test on 5709.
[BNX2]: Fix register and memory test on 5709.
Tweak registers and memory test range for 5709.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 9f0a067..6d05397 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -3763,10 +3763,11 @@ static int
bnx2_test_registers(struct bnx2 *bp)
{
int ret;
- int i;
+ int i, is_5709;
static const struct {
u16 offset;
u16 flags;
+#define BNX2_FL_NOT_5709 1
u32 rw_mask;
u32 ro_mask;
} reg_tbl[] = {
@@ -3774,26 +3775,26 @@ bnx2_test_registers(struct bnx2 *bp)
{ 0x0090, 0, 0x, 0x },
{ 0x0094, 0, 0x, 0x },
- { 0x0404, 0, 0x3f00, 0x },
- { 0x0418, 0, 0x, 0x },
- { 0x041c, 0, 0x, 0x },
- { 0x0420, 0, 0x, 0x80ff },
- { 0x0424, 0, 0x, 0x },
- { 0x0428, 0, 0x, 0x0001 },
- { 0x0450, 0, 0x, 0x },
- { 0x0454, 0, 0x, 0x },
- { 0x0458, 0, 0x, 0x },
-
- { 0x0808, 0, 0x, 0x },
- { 0x0854, 0, 0x, 0x },
- { 0x0868, 0, 0x, 0x },
- { 0x086c, 0, 0x, 0x },
- { 0x0870, 0, 0x, 0x },
- { 0x0874, 0, 0x, 0x },
-
- { 0x0c00, 0, 0x, 0x0001 },
- { 0x0c04, 0, 0x, 0x03ff0001 },
- { 0x0c08, 0, 0x0f0ff073, 0x },
+ { 0x0404, BNX2_FL_NOT_5709, 0x3f00, 0x },
+ { 0x0418, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x041c, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x0420, BNX2_FL_NOT_5709, 0x, 0x80ff },
+ { 0x0424, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x0428, BNX2_FL_NOT_5709, 0x, 0x0001 },
+ { 0x0450, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x0454, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x0458, BNX2_FL_NOT_5709, 0x, 0x },
+
+ { 0x0808, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x0854, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x0868, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x086c, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x0870, BNX2_FL_NOT_5709, 0x, 0x },
+ { 0x0874, BNX2_FL_NOT_5709, 0x, 0x },
+
+ { 0x0c00, BNX2_FL_NOT_5709, 0x, 0x0001 },
+ { 0x0c04, BNX2_FL_NOT_5709, 0x, 0x03ff0001 },
+ { 0x0c08, BNX2_FL_NOT_5709, 0x0f0ff073, 0x },
{ 0x1000, 0, 0x, 0x0001 },
{ 0x1004, 0, 0x, 0x000f0001 },
@@ -3840,7 +3841,6 @@ bnx2_test_registers(struct bnx2 *bp)
{ 0x5004, 0, 0x, 0x007f },
{ 0x5008, 0, 0x0f0007ff, 0x },
- { 0x500c, 0, 0xf800f800, 0x07ff07ff },
{ 0x5c00, 0, 0x, 0x0001 },
{ 0x5c04, 0, 0x, 0x0003000f },
@@ -3880,8 +3880,16 @@ bnx2_test_registers(struct bnx2 *bp)
};
ret = 0;
+ is_5709 = 0;
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ is_5709 = 1;
+
for (i = 0; reg_tbl[i].offset != 0x; i++) {
u32 offset, rw_mask, ro_mask, save_val, val;
+ u16 flags = reg_tbl[i].flags;
+
+ if (is_5709 (flags BNX2_FL_NOT_5709))
+ continue;
offset = (u32) reg_tbl[i].offset;
rw_mask = reg_tbl[i].rw_mask;
@@ -3950,10 +3958,10 @@ bnx2_test_memory(struct bnx2 *bp)
{
int ret = 0;
int i;
- static const struct {
+ static struct mem_entry {
u32 offset;
u32 len;
- } mem_tbl[] = {
+ } mem_tbl_5706[] = {
{ 0x6, 0x4000 },
{ 0xa, 0x3000 },
{ 0xe, 0x4000 },
@@ -3961,7 +3969,21 @@ bnx2_test_memory(struct bnx2 *bp)
{ 0x1a, 0x4000 },
{ 0x16, 0x4000 },
{ 0x, 0},
+ },
+ mem_tbl_5709[] = {
+ { 0x6, 0x4000 },
+ { 0xa, 0x3000 },
+ { 0xe, 0x4000 },
+ { 0x12, 0x4000 },
+ { 0x1a, 0x4000 },
+ { 0x, 0},
};
+ struct mem_entry *mem_tbl;
+
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ mem_tbl = mem_tbl_5709;
+
[PATCH 3/20][BNX2]: Add 40-bit DMA workaround for 5708.
[BNX2]: Add 40-bit DMA workaround for 5708.
The internal PCIE-to-PCIX bridge of the 5708 has the same 40-bit DMA
limitation as some of the tg3 chips. Use the same workaround used in
tg3. On 64-bit systems without IOMMU, linearize the SKB if any
address is 40-bit.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 6d05397..dba4088 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -4495,6 +4495,93 @@ bnx2_vlan_rx_kill_vid(struct net_device *dev, uint16_t
vid)
}
#endif
+/* Test for DMA addresses 40-bit.
+ * Only 64-bit systems without IOMMU require DMA address checking.
+ */
+static inline int bnx2_40bit_overflow_test(struct bnx2 *bp, dma_addr_t mapping,
+ int len)
+{
+#if defined(CONFIG_HIGHMEM) (BITS_PER_LONG == 64)
+ if (CHIP_NUM(bp) == CHIP_NUM_5708)
+ return (((u64) mapping + len) DMA_40BIT_MASK);
+ return 0;
+#else
+ return 0;
+#endif
+}
+
+#if defined(CONFIG_HIGHMEM) (BITS_PER_LONG == 64)
+/* Workaround 40-bit hardware DMA bugs. */
+static int bnx2_dma_hwbug_workaround(struct bnx2 *bp, struct sk_buff **skb,
+u16 *last_plus_one, u32 base_flags,
+u32 mss)
+{
+ struct sk_buff *new_skb = skb_copy(*skb, GFP_ATOMIC);
+ dma_addr_t new_addr = 0;
+ int i, ret = 0;
+ u16 hw_prod = *last_plus_one;
+ u16 start, hw_start, prod;
+
+ prod = TX_RING_IDX(hw_prod);
+ start = prod - 1 - skb_shinfo(*skb)-nr_frags;
+ hw_start = hw_prod - 1 - skb_shinfo(*skb)-nr_frags;
+ start = MAX_TX_DESC_CNT;
+ if (start prod) {
+ start--;
+ hw_start--;
+ }
+
+ if (!new_skb) {
+ ret = -1;
+ } else {
+ struct tx_bd *txbd;
+
+ /* New SKB is guaranteed to be linear. */
+ new_addr = pci_map_single(bp-pdev, new_skb-data, new_skb-len,
+ PCI_DMA_TODEVICE);
+ txbd = bp-tx_desc_ring[start];
+
+ txbd-tx_bd_haddr_hi = (u64) new_addr 32;
+ txbd-tx_bd_haddr_lo = (u64) new_addr 0x;
+ txbd-tx_bd_mss_nbytes = new_skb-len | (mss 16);
+ txbd-tx_bd_vlan_tag_flags = base_flags | TX_BD_FLAGS_START |
+TX_BD_FLAGS_END;
+
+ *last_plus_one = NEXT_TX_BD(hw_start);
+ }
+
+ /* Now clean up the sw ring entries. */
+ i = 0;
+ while (start != prod) {
+ int len;
+
+ if (i == 0)
+ len = skb_headlen(*skb);
+ else
+ len = skb_shinfo(*skb)-frags[i-1].size;
+
+ pci_unmap_single(bp-pdev,
+pci_unmap_addr(tp-tx_buf_ring[start],
+ mapping),
+len, PCI_DMA_TODEVICE);
+ if (i == 0) {
+ bp-tx_buf_ring[start].skb = new_skb;
+ pci_unmap_addr_set(bp-tx_buf_ring[start], mapping,
+ new_addr);
+ }
+ hw_start = NEXT_TX_BD(hw_start);
+ start = TX_RING_IDX(hw_start);
+ i++;
+ }
+
+ dev_kfree_skb(*skb);
+
+ *skb = new_skb;
+
+ return ret;
+}
+#endif
+
/* Called with netif_tx_lock.
* bnx2_tx_int() runs without netif_tx_lock unless it needs to call
* netif_wake_queue().
@@ -4508,7 +4595,7 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device
*dev)
struct sw_bd *tx_buf;
u32 len, vlan_tag_flags, last_frag, mss;
u16 prod, ring_prod;
- int i;
+ int i, would_hit_hwbug = 0;
if (unlikely(bnx2_tx_avail(bp) (skb_shinfo(skb)-nr_frags + 1))) {
netif_stop_queue(dev);
@@ -4598,10 +4685,25 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device
*dev)
txbd-tx_bd_mss_nbytes = len | (mss 16);
txbd-tx_bd_vlan_tag_flags = vlan_tag_flags;
+ if (bnx2_40bit_overflow_test(bp, mapping, len))
+ would_hit_hwbug = 1;
}
txbd-tx_bd_vlan_tag_flags |= TX_BD_FLAGS_END;
prod = NEXT_TX_BD(prod);
+
+#if defined(CONFIG_HIGHMEM) (BITS_PER_LONG == 64)
+ if (unlikely(would_hit_hwbug)) {
+ /* If the workaround fails due to memory/mapping
+* failure, silently drop this packet.
+*/
+ if (bnx2_dma_hwbug_workaround(bp, skb, prod,
+ vlan_tag_flags, mss))
+ return NETDEV_TX_OK;
+
+ }
+#endif
+
bp-tx_prod_bseq += skb-len;
REG_WR16(bp, bp-tx_bidx_addr, prod);
@@ -5711,6 +5813,7 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device
*dev)
[PATCH 4/20][BNX2]: Fix race conditions when calling register_netdev().
[BNX2]: Fix race conditions when calling register_netdev().
Hot-plug scripts can call bnx2_open() as soon as register_netdev() is
called in bnx2_init_one(). We need to call pci_set_drvdata() and
setup everything before calling register_netdev(). netif_carrier_off()
also needs to be moved to bnx2_open() to avoid race conditions with
the irq.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index dba4088..971607c 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -4350,6 +4350,8 @@ bnx2_open(struct net_device *dev)
struct bnx2 *bp = netdev_priv(dev);
int rc;
+ netif_carrier_off(dev);
+
bnx2_set_power_state(bp, PCI_D0);
bnx2_disable_int(bp);
@@ -6195,6 +6197,18 @@ bnx2_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
dev-poll_controller = poll_bnx2;
#endif
+ pci_set_drvdata(pdev, dev);
+
+ memcpy(dev-dev_addr, bp-mac_addr, 6);
+ memcpy(dev-perm_addr, bp-mac_addr, 6);
+ bp-name = board_info[ent-driver_data].name;
+
+ dev-features |= NETIF_F_IP_CSUM | NETIF_F_SG;
+#ifdef BCM_VLAN
+ dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+#endif
+ dev-features |= NETIF_F_TSO | NETIF_F_TSO_ECN;
+
if ((rc = register_netdev(dev))) {
dev_err(pdev-dev, Cannot register net device\n);
if (bp-regview)
@@ -6206,11 +6220,6 @@ bnx2_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
return rc;
}
- pci_set_drvdata(pdev, dev);
-
- memcpy(dev-dev_addr, bp-mac_addr, 6);
- memcpy(dev-perm_addr, bp-mac_addr, 6);
- bp-name = board_info[ent-driver_data].name,
printk(KERN_INFO %s: %s (%c%d) PCI%s %s %dMHz found at mem %lx,
IRQ %d, ,
dev-name,
@@ -6228,15 +6237,6 @@ bnx2_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
printk(%2.2x, dev-dev_addr[i]);
printk(\n);
- dev-features |= NETIF_F_SG;
- dev-features |= NETIF_F_IP_CSUM;
-#ifdef BCM_VLAN
- dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
-#endif
- dev-features |= NETIF_F_TSO | NETIF_F_TSO_ECN;
-
- netif_carrier_off(bp-dev);
-
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/20][BNX2]: Save PCI state during suspend.
[BNX2]: Save PCI state during suspend. This is needed to save the MSI state which will be lost during suspend. Signed-off-by: Michael Chan [EMAIL PROTECTED] diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c index 971607c..8520967 100644 --- a/drivers/net/bnx2.c +++ b/drivers/net/bnx2.c @@ -6281,6 +6281,7 @@ bnx2_suspend(struct pci_dev *pdev, pm_message_t state) reset_code = BNX2_DRV_MSG_CODE_SUSPEND_NO_WOL; bnx2_reset_chip(bp, reset_code); bnx2_free_skbs(bp); + pci_save_state(pdev); bnx2_set_power_state(bp, pci_choose_state(pdev, state)); return 0; } @@ -6294,6 +6295,7 @@ bnx2_resume(struct pci_dev *pdev) if (!netif_running(dev)) return 0; + pci_restore_state(pdev); bnx2_set_power_state(bp, PCI_D0); netif_device_attach(dev); bnx2_init_nic(bp); - 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 13/20][BNX2]: Put MII register offsets in the bnx2 struct.
[BNX2]: Put MII register offsets in the bnx2 struct.
The 5709 Serdes device uses non-standard MII register offsets. This
re-structuring will make it easier to support 5709 Serdes.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 8610f7f..c265068 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -572,8 +572,8 @@ bnx2_report_fw_link(struct bnx2 *bp)
if (bp-autoneg) {
fw_link_status |= BNX2_LINK_STATUS_AN_ENABLED;
- bnx2_read_phy(bp, MII_BMSR, bmsr);
- bnx2_read_phy(bp, MII_BMSR, bmsr);
+ bnx2_read_phy(bp, bp-mii_bmsr, bmsr);
+ bnx2_read_phy(bp, bp-mii_bmsr, bmsr);
if (!(bmsr BMSR_ANEGCOMPLETE) ||
bp-phy_flags PHY_PARALLEL_DETECT_FLAG)
@@ -654,8 +654,8 @@ bnx2_resolve_flow_ctrl(struct bnx2 *bp)
return;
}
- bnx2_read_phy(bp, MII_ADVERTISE, local_adv);
- bnx2_read_phy(bp, MII_LPA, remote_adv);
+ bnx2_read_phy(bp, bp-mii_adv, local_adv);
+ bnx2_read_phy(bp, bp-mii_lpa, remote_adv);
if (bp-phy_flags PHY_SERDES_FLAG) {
u32 new_local_adv = 0;
@@ -736,7 +736,7 @@ bnx2_5706s_linkup(struct bnx2 *bp)
bp-link_up = 1;
bp-line_speed = SPEED_1000;
- bnx2_read_phy(bp, MII_BMCR, bmcr);
+ bnx2_read_phy(bp, bp-mii_bmcr, bmcr);
if (bmcr BMCR_FULLDPLX) {
bp-duplex = DUPLEX_FULL;
}
@@ -748,8 +748,8 @@ bnx2_5706s_linkup(struct bnx2 *bp)
return 0;
}
- bnx2_read_phy(bp, MII_ADVERTISE, local_adv);
- bnx2_read_phy(bp, MII_LPA, remote_adv);
+ bnx2_read_phy(bp, bp-mii_adv, local_adv);
+ bnx2_read_phy(bp, bp-mii_lpa, remote_adv);
common = local_adv remote_adv;
if (common (ADVERTISE_1000XHALF | ADVERTISE_1000XFULL)) {
@@ -770,7 +770,7 @@ bnx2_copper_linkup(struct bnx2 *bp)
{
u32 bmcr;
- bnx2_read_phy(bp, MII_BMCR, bmcr);
+ bnx2_read_phy(bp, bp-mii_bmcr, bmcr);
if (bmcr BMCR_ANENABLE) {
u32 local_adv, remote_adv, common;
@@ -787,8 +787,8 @@ bnx2_copper_linkup(struct bnx2 *bp)
bp-duplex = DUPLEX_HALF;
}
else {
- bnx2_read_phy(bp, MII_ADVERTISE, local_adv);
- bnx2_read_phy(bp, MII_LPA, remote_adv);
+ bnx2_read_phy(bp, bp-mii_adv, local_adv);
+ bnx2_read_phy(bp, bp-mii_lpa, remote_adv);
common = local_adv remote_adv;
if (common ADVERTISE_100FULL) {
@@ -911,8 +911,8 @@ bnx2_set_link(struct bnx2 *bp)
link_up = bp-link_up;
- bnx2_read_phy(bp, MII_BMSR, bmsr);
- bnx2_read_phy(bp, MII_BMSR, bmsr);
+ bnx2_read_phy(bp, bp-mii_bmsr, bmsr);
+ bnx2_read_phy(bp, bp-mii_bmsr, bmsr);
if ((bp-phy_flags PHY_SERDES_FLAG)
(CHIP_NUM(bp) == CHIP_NUM_5706)) {
@@ -971,13 +971,13 @@ bnx2_reset_phy(struct bnx2 *bp)
int i;
u32 reg;
-bnx2_write_phy(bp, MII_BMCR, BMCR_RESET);
+bnx2_write_phy(bp, bp-mii_bmcr, BMCR_RESET);
#define PHY_RESET_MAX_WAIT 100
for (i = 0; i PHY_RESET_MAX_WAIT; i++) {
udelay(10);
- bnx2_read_phy(bp, MII_BMCR, reg);
+ bnx2_read_phy(bp, bp-mii_bmcr, reg);
if (!(reg BMCR_RESET)) {
udelay(20);
break;
@@ -1033,10 +1033,10 @@ bnx2_setup_serdes_phy(struct bnx2 *bp)
u32 new_bmcr;
int force_link_down = 0;
- bnx2_read_phy(bp, MII_ADVERTISE, adv);
+ bnx2_read_phy(bp, bp-mii_adv, adv);
adv = ~(ADVERTISE_1000XFULL | ADVERTISE_1000XHALF);
- bnx2_read_phy(bp, MII_BMCR, bmcr);
+ bnx2_read_phy(bp, bp-mii_bmcr, bmcr);
new_bmcr = bmcr ~(BMCR_ANENABLE | BCM5708S_BMCR_FORCE_2500);
new_bmcr |= BMCR_SPEED1000;
if (bp-req_line_speed == SPEED_2500) {
@@ -1067,19 +1067,19 @@ bnx2_setup_serdes_phy(struct bnx2 *bp)
if ((new_bmcr != bmcr) || (force_link_down)) {
/* Force a link down visible on the other side */
if (bp-link_up) {
- bnx2_write_phy(bp, MII_ADVERTISE, adv
+ bnx2_write_phy(bp, bp-mii_adv, adv
~(ADVERTISE_1000XFULL |
ADVERTISE_1000XHALF));
- bnx2_write_phy(bp, MII_BMCR, bmcr |
+ bnx2_write_phy(bp, bp-mii_bmcr, bmcr |
BMCR_ANRESTART | BMCR_ANENABLE);
[PATCH 12/20][BNX2]: Add ipv6 TSO and checksum for 5709.
[BNX2]: Add ipv6 TSO and checksum for 5709.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 8520967..8610f7f 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -4624,35 +4624,49 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device
*dev)
u32 tcp_opt_len, ip_tcp_len;
struct iphdr *iph;
- if (skb_header_cloned(skb)
- pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
- dev_kfree_skb(skb);
- return NETDEV_TX_OK;
- }
-
vlan_tag_flags |= TX_BD_FLAGS_SW_LSO;
- tcp_opt_len = 0;
- if (tcp_hdr(skb)-doff 5)
- tcp_opt_len = tcp_optlen(skb);
+ tcp_opt_len = tcp_optlen(skb);
- ip_tcp_len = ip_hdrlen(skb) + sizeof(struct tcphdr);
+ if (skb_shinfo(skb)-gso_type SKB_GSO_TCPV6) {
+ u32 tcp_off = skb_transport_offset(skb) -
+ sizeof(struct ipv6hdr) - ETH_HLEN;
- iph = ip_hdr(skb);
- iph-check = 0;
- iph-tot_len = htons(mss + ip_tcp_len + tcp_opt_len);
- tcp_hdr(skb)-check = ~csum_tcpudp_magic(iph-saddr,
-iph-daddr, 0,
-IPPROTO_TCP, 0);
- if (tcp_opt_len || (iph-ihl 5)) {
- vlan_tag_flags |= ((iph-ihl - 5) +
- (tcp_opt_len 2)) 8;
+ vlan_tag_flags |= ((tcp_opt_len 2) 8) |
+ TX_BD_FLAGS_SW_FLAGS;
+ if (likely(tcp_off == 0))
+ vlan_tag_flags = ~TX_BD_FLAGS_TCP6_OFF0_MSK;
+ else {
+ tcp_off = 3;
+ vlan_tag_flags |= ((tcp_off 0x3)
+ TX_BD_FLAGS_TCP6_OFF0_SHL) |
+ ((tcp_off 0x10)
+ TX_BD_FLAGS_TCP6_OFF4_SHL);
+ mss |= (tcp_off 0xc) TX_BD_TCP6_OFF2_SHL;
+ }
+ } else {
+ if (skb_header_cloned(skb)
+ pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+
+ ip_tcp_len = ip_hdrlen(skb) + sizeof(struct tcphdr);
+
+ iph = ip_hdr(skb);
+ iph-check = 0;
+ iph-tot_len = htons(mss + ip_tcp_len + tcp_opt_len);
+ tcp_hdr(skb)-check = ~csum_tcpudp_magic(iph-saddr,
+iph-daddr, 0,
+IPPROTO_TCP,
+0);
+ if (tcp_opt_len || (iph-ihl 5)) {
+ vlan_tag_flags |= ((iph-ihl - 5) +
+ (tcp_opt_len 2)) 8;
+ }
}
- }
- else
- {
+ } else
mss = 0;
- }
mapping = pci_map_single(bp-pdev, skb-data, len, PCI_DMA_TODEVICE);
@@ -5335,10 +5349,15 @@ bnx2_set_rx_csum(struct net_device *dev, u32 data)
static int
bnx2_set_tso(struct net_device *dev, u32 data)
{
- if (data)
+ struct bnx2 *bp = netdev_priv(dev);
+
+ if (data) {
dev-features |= NETIF_F_TSO | NETIF_F_TSO_ECN;
- else
- dev-features = ~(NETIF_F_TSO | NETIF_F_TSO_ECN);
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ dev-features |= NETIF_F_TSO6;
+ } else
+ dev-features = ~(NETIF_F_TSO | NETIF_F_TSO6 |
+ NETIF_F_TSO_ECN);
return 0;
}
@@ -5636,6 +5655,17 @@ bnx2_phys_id(struct net_device *dev, u32 data)
return 0;
}
+static int
+bnx2_set_tx_csum(struct net_device *dev, u32 data)
+{
+ struct bnx2 *bp = netdev_priv(dev);
+
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ return (ethtool_op_set_tx_hw_csum(dev, data));
+ else
+ return (ethtool_op_set_tx_csum(dev, data));
+}
+
static const struct ethtool_ops bnx2_ethtool_ops = {
.get_settings = bnx2_get_settings,
.set_settings = bnx2_set_settings,
@@ -5658,7 +5688,7 @@ static const struct ethtool_ops bnx2_ethtool_ops = {
.get_rx_csum= bnx2_get_rx_csum,
.set_rx_csum= bnx2_set_rx_csum,
.get_tx_csum=
[PATCH 14/20][BNX2]: Re-structure the 2.5G Serdes code.
[BNX2]: Re-structure the 2.5G Serdes code.
Add some common procedures to handle enabling and disabling 2.5G.
Add some missing code to resolve flow control.
Add SUPPORTED_2500baseX_Full and ADVERTISED_2500baseX_Full in
ethtool.h.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index c265068..eac52a1 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -899,6 +899,86 @@ bnx2_set_mac_link(struct bnx2 *bp)
}
static int
+bnx2_test_and_enable_2g5(struct bnx2 *bp)
+{
+ u32 up1;
+ int ret = 1;
+
+ if (!(bp-phy_flags PHY_2_5G_CAPABLE_FLAG))
+ return 0;
+
+ if (bp-autoneg AUTONEG_SPEED)
+ bp-advertising |= ADVERTISED_2500baseX_Full;
+
+ bnx2_read_phy(bp, bp-mii_up1, up1);
+ if (!(up1 BCM5708S_UP1_2G5)) {
+ up1 |= BCM5708S_UP1_2G5;
+ bnx2_write_phy(bp, bp-mii_up1, up1);
+ ret = 0;
+ }
+
+ return ret;
+}
+
+static int
+bnx2_test_and_disable_2g5(struct bnx2 *bp)
+{
+ u32 up1;
+ int ret = 0;
+
+ if (!(bp-phy_flags PHY_2_5G_CAPABLE_FLAG))
+ return 0;
+
+ bnx2_read_phy(bp, bp-mii_up1, up1);
+ if (up1 BCM5708S_UP1_2G5) {
+ up1 = ~BCM5708S_UP1_2G5;
+ bnx2_write_phy(bp, bp-mii_up1, up1);
+ ret = 1;
+ }
+
+ return ret;
+}
+
+static void
+bnx2_enable_forced_2g5(struct bnx2 *bp)
+{
+ u32 bmcr;
+
+ if (!(bp-phy_flags PHY_2_5G_CAPABLE_FLAG))
+ return;
+
+ if (CHIP_NUM(bp) == CHIP_NUM_5708) {
+ bnx2_read_phy(bp, bp-mii_bmcr, bmcr);
+ bmcr |= BCM5708S_BMCR_FORCE_2500;
+ }
+
+ if (bp-autoneg AUTONEG_SPEED) {
+ bmcr = ~BMCR_ANENABLE;
+ if (bp-req_duplex == DUPLEX_FULL)
+ bmcr |= BMCR_FULLDPLX;
+ }
+ bnx2_write_phy(bp, bp-mii_bmcr, bmcr);
+}
+
+static void
+bnx2_disable_forced_2g5(struct bnx2 *bp)
+{
+ u32 bmcr;
+
+ if (!(bp-phy_flags PHY_2_5G_CAPABLE_FLAG))
+ return;
+
+ if (CHIP_NUM(bp) == CHIP_NUM_5708) {
+ bnx2_read_phy(bp, bp-mii_bmcr, bmcr);
+ bmcr = ~BCM5708S_BMCR_FORCE_2500;
+ }
+
+ if (bp-autoneg AUTONEG_SPEED)
+ bmcr |= BMCR_SPEED1000 | BMCR_ANENABLE | BMCR_ANRESTART;
+ bnx2_write_phy(bp, bp-mii_bmcr, bmcr);
+}
+
+static int
bnx2_set_link(struct bnx2 *bp)
{
u32 bmsr;
@@ -941,17 +1021,9 @@ bnx2_set_link(struct bnx2 *bp)
}
else {
if ((bp-phy_flags PHY_SERDES_FLAG)
- (bp-autoneg AUTONEG_SPEED)) {
+ (bp-autoneg AUTONEG_SPEED))
+ bnx2_disable_forced_2g5(bp);
- u32 bmcr;
-
- bnx2_read_phy(bp, MII_BMCR, bmcr);
- bmcr = ~BCM5708S_BMCR_FORCE_2500;
- if (!(bmcr BMCR_ANENABLE)) {
- bnx2_write_phy(bp, MII_BMCR, bmcr |
- BMCR_ANENABLE);
- }
- }
bp-phy_flags = ~PHY_PARALLEL_DETECT_FLAG;
bp-link_up = 0;
}
@@ -1026,34 +1098,32 @@ bnx2_phy_get_pause_adv(struct bnx2 *bp)
static int
bnx2_setup_serdes_phy(struct bnx2 *bp)
{
- u32 adv, bmcr, up1;
+ u32 adv, bmcr;
u32 new_adv = 0;
if (!(bp-autoneg AUTONEG_SPEED)) {
u32 new_bmcr;
int force_link_down = 0;
+ if (bp-req_line_speed == SPEED_2500) {
+ if (!bnx2_test_and_enable_2g5(bp))
+ force_link_down = 1;
+ } else if (bp-req_line_speed == SPEED_1000) {
+ if (bnx2_test_and_disable_2g5(bp))
+ force_link_down = 1;
+ }
bnx2_read_phy(bp, bp-mii_adv, adv);
adv = ~(ADVERTISE_1000XFULL | ADVERTISE_1000XHALF);
bnx2_read_phy(bp, bp-mii_bmcr, bmcr);
- new_bmcr = bmcr ~(BMCR_ANENABLE | BCM5708S_BMCR_FORCE_2500);
+ new_bmcr = bmcr ~BMCR_ANENABLE;
new_bmcr |= BMCR_SPEED1000;
- if (bp-req_line_speed == SPEED_2500) {
- new_bmcr |= BCM5708S_BMCR_FORCE_2500;
- bnx2_read_phy(bp, BCM5708S_UP1, up1);
- if (!(up1 BCM5708S_UP1_2G5)) {
- up1 |= BCM5708S_UP1_2G5;
- bnx2_write_phy(bp, BCM5708S_UP1, up1);
- force_link_down = 1;
- }
- } else if (CHIP_NUM(bp) == CHIP_NUM_5708) {
- bnx2_read_phy(bp, BCM5708S_UP1, up1);
- if (up1 BCM5708S_UP1_2G5) {
- up1 = ~BCM5708S_UP1_2G5;
-
[PATCH 15/20][BNX2]: Add support for 5709 Serdes.
[BNX2]: Add support for 5709 Serdes.
Add PCI ID and code to support the 5709 Serdes PHY.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index eac52a1..ffd6976 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -84,6 +84,7 @@ typedef enum {
BCM5708,
BCM5708S,
BCM5709,
+ BCM5709S,
} board_t;
/* indexed by board_t, above */
@@ -98,6 +99,7 @@ static const struct {
{ Broadcom NetXtreme II BCM5708 1000Base-T },
{ Broadcom NetXtreme II BCM5708 1000Base-SX },
{ Broadcom NetXtreme II BCM5709 1000Base-T },
+ { Broadcom NetXtreme II BCM5709 1000Base-SX },
};
static struct pci_device_id bnx2_pci_tbl[] = {
@@ -117,6 +119,8 @@ static struct pci_device_id bnx2_pci_tbl[] = {
PCI_ANY_ID, PCI_ANY_ID, 0, 0, BCM5708S },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_NX2_5709,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, BCM5709 },
+ { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_NX2_5709S,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, BCM5709S },
{ 0, }
};
@@ -700,6 +704,45 @@ bnx2_resolve_flow_ctrl(struct bnx2 *bp)
}
static int
+bnx2_5709s_linkup(struct bnx2 *bp)
+{
+ u32 val, speed;
+
+ bp-link_up = 1;
+
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR, MII_BNX2_BLK_ADDR_GP_STATUS);
+ bnx2_read_phy(bp, MII_BNX2_GP_TOP_AN_STATUS1, val);
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR, MII_BNX2_BLK_ADDR_COMBO_IEEEB0);
+
+ if ((bp-autoneg AUTONEG_SPEED) == 0) {
+ bp-line_speed = bp-req_line_speed;
+ bp-duplex = bp-req_duplex;
+ return 0;
+ }
+ speed = val MII_BNX2_GP_TOP_AN_SPEED_MSK;
+ switch (speed) {
+ case MII_BNX2_GP_TOP_AN_SPEED_10:
+ bp-line_speed = SPEED_10;
+ break;
+ case MII_BNX2_GP_TOP_AN_SPEED_100:
+ bp-line_speed = SPEED_100;
+ break;
+ case MII_BNX2_GP_TOP_AN_SPEED_1G:
+ case MII_BNX2_GP_TOP_AN_SPEED_1GKV:
+ bp-line_speed = SPEED_1000;
+ break;
+ case MII_BNX2_GP_TOP_AN_SPEED_2_5G:
+ bp-line_speed = SPEED_2500;
+ break;
+ }
+ if (val MII_BNX2_GP_TOP_AN_FD)
+ bp-duplex = DUPLEX_FULL;
+ else
+ bp-duplex = DUPLEX_HALF;
+ return 0;
+}
+
+static int
bnx2_5708s_linkup(struct bnx2 *bp)
{
u32 val;
@@ -898,6 +941,24 @@ bnx2_set_mac_link(struct bnx2 *bp)
return 0;
}
+static void
+bnx2_enable_bmsr1(struct bnx2 *bp)
+{
+ if ((bp-phy_flags PHY_SERDES_FLAG)
+ (CHIP_NUM(bp) == CHIP_NUM_5709))
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR,
+ MII_BNX2_BLK_ADDR_GP_STATUS);
+}
+
+static void
+bnx2_disable_bmsr1(struct bnx2 *bp)
+{
+ if ((bp-phy_flags PHY_SERDES_FLAG)
+ (CHIP_NUM(bp) == CHIP_NUM_5709))
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR,
+ MII_BNX2_BLK_ADDR_COMBO_IEEEB0);
+}
+
static int
bnx2_test_and_enable_2g5(struct bnx2 *bp)
{
@@ -910,6 +971,9 @@ bnx2_test_and_enable_2g5(struct bnx2 *bp)
if (bp-autoneg AUTONEG_SPEED)
bp-advertising |= ADVERTISED_2500baseX_Full;
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR, MII_BNX2_BLK_ADDR_OVER1G);
+
bnx2_read_phy(bp, bp-mii_up1, up1);
if (!(up1 BCM5708S_UP1_2G5)) {
up1 |= BCM5708S_UP1_2G5;
@@ -917,6 +981,10 @@ bnx2_test_and_enable_2g5(struct bnx2 *bp)
ret = 0;
}
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR,
+ MII_BNX2_BLK_ADDR_COMBO_IEEEB0);
+
return ret;
}
@@ -929,6 +997,9 @@ bnx2_test_and_disable_2g5(struct bnx2 *bp)
if (!(bp-phy_flags PHY_2_5G_CAPABLE_FLAG))
return 0;
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR, MII_BNX2_BLK_ADDR_OVER1G);
+
bnx2_read_phy(bp, bp-mii_up1, up1);
if (up1 BCM5708S_UP1_2G5) {
up1 = ~BCM5708S_UP1_2G5;
@@ -936,6 +1007,10 @@ bnx2_test_and_disable_2g5(struct bnx2 *bp)
ret = 1;
}
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR,
+ MII_BNX2_BLK_ADDR_COMBO_IEEEB0);
+
return ret;
}
@@ -947,7 +1022,21 @@ bnx2_enable_forced_2g5(struct bnx2 *bp)
if (!(bp-phy_flags PHY_2_5G_CAPABLE_FLAG))
return;
- if (CHIP_NUM(bp) == CHIP_NUM_5708) {
+ if (CHIP_NUM(bp) == CHIP_NUM_5709) {
+ u32 val;
+
+ bnx2_write_phy(bp, MII_BNX2_BLK_ADDR,
+ MII_BNX2_BLK_ADDR_SERDES_DIG);
+
[PATCH 16/20][BNX2]: Add indirect spinlock.
[BNX2]: Add indirect spinlock.
The indirect register access method will be used by more than one
caller in BH context (NAPI poll and timer), so a spinlock is required.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index ffd6976..34ae3e9 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -234,21 +234,29 @@ static inline u32 bnx2_tx_avail(struct bnx2 *bp)
static u32
bnx2_reg_rd_ind(struct bnx2 *bp, u32 offset)
{
+ u32 val;
+
+ spin_lock_bh(bp-indirect_lock);
REG_WR(bp, BNX2_PCICFG_REG_WINDOW_ADDRESS, offset);
- return (REG_RD(bp, BNX2_PCICFG_REG_WINDOW));
+ val = REG_RD(bp, BNX2_PCICFG_REG_WINDOW);
+ spin_unlock_bh(bp-indirect_lock);
+ return val;
}
static void
bnx2_reg_wr_ind(struct bnx2 *bp, u32 offset, u32 val)
{
+ spin_lock_bh(bp-indirect_lock);
REG_WR(bp, BNX2_PCICFG_REG_WINDOW_ADDRESS, offset);
REG_WR(bp, BNX2_PCICFG_REG_WINDOW, val);
+ spin_unlock_bh(bp-indirect_lock);
}
static void
bnx2_ctx_wr(struct bnx2 *bp, u32 cid_addr, u32 offset, u32 val)
{
offset += cid_addr;
+ spin_lock_bh(bp-indirect_lock);
if (CHIP_NUM(bp) == CHIP_NUM_5709) {
int i;
@@ -266,6 +274,7 @@ bnx2_ctx_wr(struct bnx2 *bp, u32 cid_addr, u32 offset, u32
val)
REG_WR(bp, BNX2_CTX_DATA_ADR, offset);
REG_WR(bp, BNX2_CTX_DATA, val);
}
+ spin_unlock_bh(bp-indirect_lock);
}
static int
@@ -6138,6 +6147,7 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device
*dev)
bp-pdev = pdev;
spin_lock_init(bp-phy_lock);
+ spin_lock_init(bp-indirect_lock);
INIT_WORK(bp-reset_task, bnx2_reset_task);
dev-base_addr = dev-mem_start = pci_resource_start(pdev, 0);
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index 124bd03..ba175a8 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6522,6 +6522,7 @@ struct bnx2 {
/* Used to synchronize phy accesses. */
spinlock_t phy_lock;
+ spinlock_t indirect_lock;
u32 phy_flags;
#define PHY_SERDES_FLAG1
-
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 17/20][BNX2]: Enhance the heartbeat.
[BNX2]: Enhance the heartbeat.
In addition to the periodic heartbeat, we're adding a heartbeat
request interrupt when the heartbeat is late. This is useful
especially in -rt kernels where the timer frequently runs late.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 34ae3e9..3d41357 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1152,6 +1152,17 @@ bnx2_set_link(struct bnx2 *bp)
return 0;
}
+static void
+bnx2_send_heart_beat(struct bnx2 *bp)
+{
+ u32 msg;
+
+ spin_lock_bh(bp-phy_lock);
+ msg = (u32) ++bp-fw_drv_pulse_wr_seq;
+ spin_unlock_bh(bp-phy_lock);
+ REG_WR_IND(bp, bp-shmem_base + BNX2_DRV_PULSE_MB, msg);
+}
+
static int
bnx2_reset_phy(struct bnx2 *bp)
{
@@ -1939,26 +1950,37 @@ bnx2_alloc_rx_skb(struct bnx2 *bp, u16 index)
return 0;
}
-static void
-bnx2_phy_int(struct bnx2 *bp)
+static int
+bnx2_phy_event_is_set(struct bnx2 *bp, u32 event)
{
+ struct status_block *sblk = bp-status_blk;
u32 new_link_state, old_link_state;
+ int is_set = 1;
- new_link_state = bp-status_blk-status_attn_bits
- STATUS_ATTN_BITS_LINK_STATE;
- old_link_state = bp-status_blk-status_attn_bits_ack
- STATUS_ATTN_BITS_LINK_STATE;
+ new_link_state = sblk-status_attn_bits event;
+ old_link_state = sblk-status_attn_bits_ack event;
if (new_link_state != old_link_state) {
- if (new_link_state) {
- REG_WR(bp, BNX2_PCICFG_STATUS_BIT_SET_CMD,
- STATUS_ATTN_BITS_LINK_STATE);
- }
- else {
- REG_WR(bp, BNX2_PCICFG_STATUS_BIT_CLEAR_CMD,
- STATUS_ATTN_BITS_LINK_STATE);
- }
+ if (new_link_state)
+ REG_WR(bp, BNX2_PCICFG_STATUS_BIT_SET_CMD, event);
+ else
+ REG_WR(bp, BNX2_PCICFG_STATUS_BIT_CLEAR_CMD, event);
+ } else
+ is_set = 0;
+
+ return is_set;
+}
+
+static void
+bnx2_phy_int(struct bnx2 *bp)
+{
+ if (bnx2_phy_event_is_set(bp, STATUS_ATTN_BITS_LINK_STATE)) {
+ spin_lock(bp-phy_lock);
bnx2_set_link(bp);
+ spin_unlock(bp-phy_lock);
}
+ if (bnx2_phy_event_is_set(bp, STATUS_ATTN_BITS_TIMER_ABORT))
+ bnx2_send_heart_beat(bp);
+
}
static void
@@ -2280,6 +2302,8 @@ bnx2_interrupt(int irq, void *dev_instance)
return IRQ_HANDLED;
}
+#define STATUS_ATTN_EVENTS (STATUS_ATTN_BITS_LINK_STATE | \
+STATUS_ATTN_BITS_TIMER_ABORT)
static inline int
bnx2_has_work(struct bnx2 *bp)
{
@@ -2289,8 +2313,8 @@ bnx2_has_work(struct bnx2 *bp)
(sblk-status_tx_quick_consumer_index0 != bp-hw_tx_cons))
return 1;
- if ((sblk-status_attn_bits STATUS_ATTN_BITS_LINK_STATE) !=
- (sblk-status_attn_bits_ack STATUS_ATTN_BITS_LINK_STATE))
+ if ((sblk-status_attn_bits STATUS_ATTN_EVENTS) !=
+ (sblk-status_attn_bits_ack STATUS_ATTN_EVENTS))
return 1;
return 0;
@@ -2300,15 +2324,14 @@ static int
bnx2_poll(struct net_device *dev, int *budget)
{
struct bnx2 *bp = netdev_priv(dev);
+ struct status_block *sblk = bp-status_blk;
+ u32 status_attn_bits = sblk-status_attn_bits;
+ u32 status_attn_bits_ack = sblk-status_attn_bits_ack;
- if ((bp-status_blk-status_attn_bits
- STATUS_ATTN_BITS_LINK_STATE) !=
- (bp-status_blk-status_attn_bits_ack
- STATUS_ATTN_BITS_LINK_STATE)) {
+ if ((status_attn_bits STATUS_ATTN_EVENTS) !=
+ (status_attn_bits_ack STATUS_ATTN_EVENTS)) {
- spin_lock(bp-phy_lock);
bnx2_phy_int(bp);
- spin_unlock(bp-phy_lock);
/* This is needed to take care of transient status
* during link changes.
@@ -3757,7 +3780,7 @@ bnx2_init_chip(struct bnx2 *bp)
/* Clear internal stats counters. */
REG_WR(bp, BNX2_HC_COMMAND, BNX2_HC_COMMAND_CLR_STAT_NOW);
- REG_WR(bp, BNX2_HC_ATTN_BITS_ENABLE, STATUS_ATTN_BITS_LINK_STATE);
+ REG_WR(bp, BNX2_HC_ATTN_BITS_ENABLE, STATUS_ATTN_EVENTS);
if (REG_RD_IND(bp, bp-shmem_base + BNX2_PORT_FEATURE)
BNX2_PORT_FEATURE_ASF_ENABLED)
@@ -3769,7 +3792,7 @@ bnx2_init_chip(struct bnx2 *bp)
rc = bnx2_fw_sync(bp, BNX2_DRV_MSG_DATA_WAIT2 | BNX2_DRV_MSG_CODE_RESET,
0);
- REG_WR(bp, BNX2_MISC_ENABLE_SET_BITS, 0x5ff);
+ REG_WR(bp, BNX2_MISC_ENABLE_SET_BITS, 0x7ff);
REG_RD(bp, BNX2_MISC_ENABLE_SET_BITS);
udelay(20);
@@ -4574,7 +4597,6 @@ static void
bnx2_timer(unsigned long data)
{
struct bnx2 *bp = (struct bnx2 *) data;
- u32 msg;
if
[PATCH 18/20][BNX2]: Add 1-shot MSI handler for 5709.
[BNX2]: Add 1-shot MSI handler for 5709.
The 5709 supports the one-shot MSI handler similar to some of the tg3
chips. In this mode, the MSI disables itself automatically until it
is re-enabled at the end of NAPI poll.
Put the request_irq/free_irq logic in common procedures.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 3d41357..5869e2b 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -2273,6 +2273,23 @@ bnx2_msi(int irq, void *dev_instance)
}
static irqreturn_t
+bnx2_msi_1shot(int irq, void *dev_instance)
+{
+ struct net_device *dev = dev_instance;
+ struct bnx2 *bp = netdev_priv(dev);
+
+ prefetch(bp-status_blk);
+
+ /* Return here if interrupt is disabled. */
+ if (unlikely(atomic_read(bp-intr_sem) != 0))
+ return IRQ_HANDLED;
+
+ netif_rx_schedule(dev);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t
bnx2_interrupt(int irq, void *dev_instance)
{
struct net_device *dev = dev_instance;
@@ -3770,13 +3787,17 @@ bnx2_init_chip(struct bnx2 *bp)
REG_WR(bp, BNX2_HC_STAT_COLLECT_TICKS, 0xbb8); /* 3ms */
if (CHIP_ID(bp) == CHIP_ID_5706_A1)
- REG_WR(bp, BNX2_HC_CONFIG, BNX2_HC_CONFIG_COLLECT_STATS);
+ val = BNX2_HC_CONFIG_COLLECT_STATS;
else {
- REG_WR(bp, BNX2_HC_CONFIG, BNX2_HC_CONFIG_RX_TMR_MODE |
- BNX2_HC_CONFIG_TX_TMR_MODE |
- BNX2_HC_CONFIG_COLLECT_STATS);
+ val = BNX2_HC_CONFIG_RX_TMR_MODE | BNX2_HC_CONFIG_TX_TMR_MODE |
+ BNX2_HC_CONFIG_COLLECT_STATS;
}
+ if (bp-flags ONE_SHOT_MSI_FLAG)
+ val |= BNX2_HC_CONFIG_ONE_SHOT;
+
+ REG_WR(bp, BNX2_HC_CONFIG, val);
+
/* Clear internal stats counters. */
REG_WR(bp, BNX2_HC_COMMAND, BNX2_HC_COMMAND_CLR_STAT_NOW);
@@ -4619,6 +4640,38 @@ bnx2_restart_timer:
mod_timer(bp-timer, jiffies + bp-current_interval);
}
+static int
+bnx2_request_irq(struct bnx2 *bp)
+{
+ struct net_device *dev = bp-dev;
+ int rc = 0;
+
+ if (bp-flags USING_MSI_FLAG) {
+ irq_handler_t fn = bnx2_msi;
+
+ if (bp-flags ONE_SHOT_MSI_FLAG)
+ fn = bnx2_msi_1shot;
+
+ rc = request_irq(bp-pdev-irq, fn, 0, dev-name, dev);
+ } else
+ rc = request_irq(bp-pdev-irq, bnx2_interrupt,
+IRQF_SHARED, dev-name, dev);
+ return rc;
+}
+
+static void
+bnx2_free_irq(struct bnx2 *bp)
+{
+ struct net_device *dev = bp-dev;
+
+ if (bp-flags USING_MSI_FLAG) {
+ free_irq(bp-pdev-irq, dev);
+ pci_disable_msi(bp-pdev);
+ bp-flags = ~(USING_MSI_FLAG | ONE_SHOT_MSI_FLAG);
+ } else
+ free_irq(bp-pdev-irq, dev);
+}
+
/* Called with rtnl_lock */
static int
bnx2_open(struct net_device *dev)
@@ -4635,24 +4688,15 @@ bnx2_open(struct net_device *dev)
if (rc)
return rc;
- if ((CHIP_ID(bp) != CHIP_ID_5706_A0)
- (CHIP_ID(bp) != CHIP_ID_5706_A1)
- !disable_msi) {
-
+ if ((bp-flags MSI_CAP_FLAG) !disable_msi) {
if (pci_enable_msi(bp-pdev) == 0) {
bp-flags |= USING_MSI_FLAG;
- rc = request_irq(bp-pdev-irq, bnx2_msi, 0, dev-name,
- dev);
+ if (CHIP_NUM(bp) == CHIP_NUM_5709)
+ bp-flags |= ONE_SHOT_MSI_FLAG;
}
- else {
- rc = request_irq(bp-pdev-irq, bnx2_interrupt,
- IRQF_SHARED, dev-name, dev);
- }
- }
- else {
- rc = request_irq(bp-pdev-irq, bnx2_interrupt, IRQF_SHARED,
- dev-name, dev);
}
+ rc = bnx2_request_irq(bp);
+
if (rc) {
bnx2_free_mem(bp);
return rc;
@@ -4661,11 +4705,7 @@ bnx2_open(struct net_device *dev)
rc = bnx2_init_nic(bp);
if (rc) {
- free_irq(bp-pdev-irq, dev);
- if (bp-flags USING_MSI_FLAG) {
- pci_disable_msi(bp-pdev);
- bp-flags = ~USING_MSI_FLAG;
- }
+ bnx2_free_irq(bp);
bnx2_free_skbs(bp);
bnx2_free_mem(bp);
return rc;
@@ -4689,16 +4729,13 @@ bnx2_open(struct net_device *dev)
bp-dev-name);
bnx2_disable_int(bp);
- free_irq(bp-pdev-irq, dev);
- pci_disable_msi(bp-pdev);
- bp-flags = ~USING_MSI_FLAG;
+ bnx2_free_irq(bp);
rc = bnx2_init_nic(bp);
- if (!rc) {
-
[PATCH 19/20][BNX2]: Print bus information for PCIE devices.
[BNX2]: Print bus information for PCIE devices.
Fix the code to print PCI or PCIE bus information for all devices.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 5869e2b..fc25d2c 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -6151,6 +6151,58 @@ bnx2_get_5709_media(struct bnx2 *bp)
}
}
+static void __devinit
+bnx2_get_pci_speed(struct bnx2 *bp)
+{
+ u32 reg;
+
+ reg = REG_RD(bp, BNX2_PCICFG_MISC_STATUS);
+ if (reg BNX2_PCICFG_MISC_STATUS_PCIX_DET) {
+ u32 clkreg;
+
+ bp-flags |= PCIX_FLAG;
+
+ clkreg = REG_RD(bp, BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS);
+
+ clkreg = BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET;
+ switch (clkreg) {
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_133MHZ:
+ bp-bus_speed_mhz = 133;
+ break;
+
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_95MHZ:
+ bp-bus_speed_mhz = 100;
+ break;
+
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_66MHZ:
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_80MHZ:
+ bp-bus_speed_mhz = 66;
+ break;
+
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_48MHZ:
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_55MHZ:
+ bp-bus_speed_mhz = 50;
+ break;
+
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_LOW:
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_32MHZ:
+ case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_38MHZ:
+ bp-bus_speed_mhz = 33;
+ break;
+ }
+ }
+ else {
+ if (reg BNX2_PCICFG_MISC_STATUS_M66EN)
+ bp-bus_speed_mhz = 66;
+ else
+ bp-bus_speed_mhz = 33;
+ }
+
+ if (reg BNX2_PCICFG_MISC_STATUS_32BIT_DET)
+ bp-flags |= PCI_32BIT_FLAG;
+
+}
+
static int __devinit
bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
{
@@ -6229,7 +6281,15 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device
*dev)
bp-chip_id = REG_RD(bp, BNX2_MISC_ID);
- if (CHIP_NUM(bp) != CHIP_NUM_5709) {
+ if (CHIP_NUM(bp) == CHIP_NUM_5709) {
+ if (pci_find_capability(pdev, PCI_CAP_ID_EXP) == 0) {
+ dev_err(pdev-dev,
+ Cannot find PCIE capability, aborting.\n);
+ rc = -EIO;
+ goto err_out_unmap;
+ }
+ bp-flags |= PCIE_FLAG;
+ } else {
bp-pcix_cap = pci_find_capability(pdev, PCI_CAP_ID_PCIX);
if (bp-pcix_cap == 0) {
dev_err(pdev-dev,
@@ -6271,51 +6331,8 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device
*dev)
goto err_out_unmap;
}
- /* Get bus information. */
- reg = REG_RD(bp, BNX2_PCICFG_MISC_STATUS);
- if (reg BNX2_PCICFG_MISC_STATUS_PCIX_DET) {
- u32 clkreg;
-
- bp-flags |= PCIX_FLAG;
-
- clkreg = REG_RD(bp, BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS);
-
- clkreg = BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET;
- switch (clkreg) {
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_133MHZ:
- bp-bus_speed_mhz = 133;
- break;
-
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_95MHZ:
- bp-bus_speed_mhz = 100;
- break;
-
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_66MHZ:
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_80MHZ:
- bp-bus_speed_mhz = 66;
- break;
-
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_48MHZ:
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_55MHZ:
- bp-bus_speed_mhz = 50;
- break;
-
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_LOW:
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_32MHZ:
- case BNX2_PCICFG_PCI_CLOCK_CONTROL_BITS_PCI_CLK_SPD_DET_38MHZ:
- bp-bus_speed_mhz = 33;
- break;
- }
- }
- else {
- if (reg BNX2_PCICFG_MISC_STATUS_M66EN)
- bp-bus_speed_mhz = 66;
- else
- bp-bus_speed_mhz = 33;
- }
-
- if (reg BNX2_PCICFG_MISC_STATUS_32BIT_DET)
-
[PATCH 20/20][BNX2]: Update version and reldate.
[BNX2]: Update version and reldate. Update version to 1.5.10. Signed-off-by: Michael Chan [EMAIL PROTECTED] diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c index fc25d2c..7da6340 100644 --- a/drivers/net/bnx2.c +++ b/drivers/net/bnx2.c @@ -1,6 +1,6 @@ /* bnx2.c: Broadcom NX2 network driver. * - * Copyright (c) 2004, 2005, 2006 Broadcom Corporation + * Copyright (c) 2004-2007 Broadcom Corporation * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -54,8 +54,8 @@ #define DRV_MODULE_NAMEbnx2 #define PFX DRV_MODULE_NAME: -#define DRV_MODULE_VERSION 1.5.8 -#define DRV_MODULE_RELDATE April 24, 2007 +#define DRV_MODULE_VERSION 1.5.10 +#define DRV_MODULE_RELDATE May 1, 2007 #define RUN_AT(x) (jiffies + (x)) diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h index 322153c..bd6288d 100644 --- a/drivers/net/bnx2.h +++ b/drivers/net/bnx2.h @@ -1,6 +1,6 @@ /* bnx2.h: Broadcom NX2 network driver. * - * Copyright (c) 2004, 2005, 2006 Broadcom Corporation + * Copyright (c) 2004-2007 Broadcom Corporation * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by - 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] gianfar: Add I/O barriers when touching buffer descriptor ownership.
The hardware must not see that is given ownership of a buffer until it
is
completely written, and when the driver receives ownership of a buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are added where required.
Without this patch, I have observed GCC reordering the setting of
bdp-length and bdp-status in gfar_new_skb.
The :::memory in the barriers you used prevent GCC
from reordering accesses around the barriers.
AFAICS you need stronger barriers though; {w,r,}mb(),
to prevent _any_ reordering of those memory accesses,
not just the compiler-generated ones.
Segher
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp
On Mon, 30 Apr 2007 00:50:14 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Mitsuru Chinen [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 16:46:30 +0900
On Tue, 17 Apr 2007 20:14:36 +0900
Mitsuru Chinen [EMAIL PROTECTED] wrote:
This displays the statistics specified in the updated IP-MIB RFC
(RFC4293) at /proc/net/snmp. As new statistics are placed as the
last elements, this change wouldn't affect netstat, net-snmp, etc.
I'm sorry. I found adding new entries to /proc/net/snmp affects
net-snmp. I'm ashamed of my inadequate investigation.
However the other patches to support new statistics will be useful.
Could you pick up 1st to 5th patches?
You could display them on a new line of /proc/net/netstat, which
we currently use to display extensions to the TCP snmp variables.
It is just one idea.
Thanks for your proposal! I created a patch based on your idea.
How about this?
[IPV4] SNMP: Display new statistics at /proc/net/netstat
This displays the statistics specified in the updated IP-MIB RFC
(RFC4293) in /proc/net/netstat. The reason why these are not added
to /proc/net/snmp is that some existing utilities are developed under
the assumption that ipstat items in /proc/net/snmp is unchanged.
Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
net/ipv4/proc.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
7d86d2fc56dee38e18b4c8b3d2dc15d7d27f8a09
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 37ab580..38f24f9 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -88,6 +88,7 @@ static const struct file_operations sock
};
/* snmp items */
+#define IPSTATS_RFC4293_START 17
static const struct snmp_mib snmp4_ipstats_list[] = {
SNMP_MIB_ITEM(InReceives, IPSTATS_MIB_INRECEIVES),
SNMP_MIB_ITEM(InHdrErrors, IPSTATS_MIB_INHDRERRORS),
@@ -106,6 +107,13 @@ static const struct snmp_mib snmp4_ipsta
SNMP_MIB_ITEM(FragOKs, IPSTATS_MIB_FRAGOKS),
SNMP_MIB_ITEM(FragFails, IPSTATS_MIB_FRAGFAILS),
SNMP_MIB_ITEM(FragCreates, IPSTATS_MIB_FRAGCREATES),
+ /* Following RFC4293 items are displayed in /proc/net/netstat */
+ SNMP_MIB_ITEM(InNoRoutes, IPSTATS_MIB_INNOROUTES),
+ SNMP_MIB_ITEM(InTruncatedPkts, IPSTATS_MIB_INTRUNCATEDPKTS),
+ SNMP_MIB_ITEM(InMcastPkts, IPSTATS_MIB_INMCASTPKTS),
+ SNMP_MIB_ITEM(OutMcastPkts, IPSTATS_MIB_OUTMCASTPKTS),
+ SNMP_MIB_ITEM(InBcastPkts, IPSTATS_MIB_INBCASTPKTS),
+ SNMP_MIB_ITEM(OutBcastPkts, IPSTATS_MIB_OUTBCASTPKTS),
SNMP_MIB_SENTINEL
};
@@ -245,13 +253,13 @@ static int snmp_seq_show(struct seq_file
seq_puts(seq, Ip: Forwarding DefaultTTL);
- for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
+ for (i = 0; i IPSTATS_RFC4293_START; i++)
seq_printf(seq, %s, snmp4_ipstats_list[i].name);
seq_printf(seq, \nIp: %d %d,
ipv4_devconf.forwarding ? 1 : 2, sysctl_ip_default_ttl);
- for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
+ for (i = 0; i IPSTATS_RFC4293_START; i++)
seq_printf(seq, %lu,
snmp_fold_field((void **)ip_statistics,
snmp4_ipstats_list[i].entry));
@@ -338,6 +346,16 @@ static int netstat_seq_show(struct seq_f
snmp_fold_field((void **)net_statistics,
snmp4_net_list[i].entry));
+ seq_puts(seq, \nIpExt:);
+ for (i = IPSTATS_RFC4293_START; snmp4_ipstats_list[i].name != NULL; i++)
+ seq_printf(seq, %s, snmp4_ipstats_list[i].name);
+
+ seq_puts(seq, \nIpExt:);
+ for (i = IPSTATS_RFC4293_START; snmp4_ipstats_list[i].name != NULL; i++)
+ seq_printf(seq, %lu,
+ snmp_fold_field((void **)ip_statistics,
+ snmp4_ipstats_list[i].entry));
+
seq_putc(seq, '\n');
return 0;
}
--
1.3.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
[PATCH] skbuff: fix kernel-doc
From: Randy Dunlap [EMAIL PROTECTED] Fix skbuff.h kernel-doc: linux-2.6.21-git4//include/linux/skbuff.h:316): No description found for parameter 'transport_header' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- include/linux/skbuff.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.21-git4.orig/include/linux/skbuff.h +++ linux-2.6.21-git4/include/linux/skbuff.h @@ -197,7 +197,7 @@ typedef unsigned char *sk_buff_data_t; * @tstamp: Time we arrived * @dev: Device we arrived on/are leaving by * @iif: ifindex of device we arrived on - * @h: Transport layer header + * @transport_header: Transport layer header * @network_header: Network layer header * @mac_header: Link layer header * @dst: destination entry - 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] zd1211rw-mac80211: limit URB buffering in tx path
On Tue, May 01, 2007 at 09:50:08PM +0200, Ulrich Kunitz wrote: On 07-05-01 12:34 Jiri Benc wrote: It is :-) Look for ieee80211_wake_queues. But as I said, you shouldn't need that. I provided the patch to add ieee80211_wake_queues(). Sorry for missing the moment, when it has been integrated. I will update the patch. No need, I have adjusted the patch accordingly. Thanks, John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
