[PATCH] virtio_net: Fix open <-> interrupt race
Jeff,
Rusty is (supposed to be) on vacation. Can you send this fix against
virtio_net with your next network driver fixes for 2.6.25?
Thank you
-
I got the following oops during interface ifup. Unfortunately its not
easily reproducable so I cant say for sure that my fix fixes this
problem, but I am confident and I think its correct anyway:
<2>kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:234!
<4>illegal operation: 0001 [#1] PREEMPT SMP
<4>Modules linked in:
<4>CPU: 0 Not tainted 2.6.24zlive-guest-07293-gf1ca151-dirty #91
<4>Process swapper (pid: 0, task: 00800938, ksp: 0084ddb8)
<4>Krnl PSW : 040430018000 00466374 (vring_disable_cb+0x30/0x34)
<4> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
<4>Krnl GPRS: 0001 0001 10003800
00466344
<4> 0e980900 008848b0 0084e748
<4> 0087b300 1237 1237
0f85bdd8
<4> 0e980920 001137c0 00464754
0f85bdd8
<4>Krnl Code: 00466368: e3b0b074lg %r11,112(%r11)
<4> 0046636e: 07febcr 15,%r14
<4> 00466370: a7f40001brc 15,466372
<4> >00466374: a7f4fff6brc 15,466360
<4> 00466378: eb7ff0500024stmg
%r7,%r15,80(%r15)
<4> 0046637e: a7f13e00tmll%r15,15872
<4> 00466382: b90400eflgr %r14,%r15
<4> 00466386: a7840001brc 8,466388
<4>Call Trace:
<4>([<000201500f85c000>] 0x201500f85c000)
<4> [<00466556>] vring_interrupt+0x72/0x88
<4> [<004801a0>] kvm_extint_handler+0x34/0x44
<4> [<0010d22c>] do_extint+0xbc/0xf8
<4> [<00113f98>] ext_no_vtime+0x16/0x1a
<4> [<0010a182>] cpu_idle+0x216/0x238
<4>([<0010a162>] cpu_idle+0x1f6/0x238)
<4> [<00568656>] rest_init+0xaa/0xb8
<4> [<0084ee2c>] start_kernel+0x3fc/0x490
<4> [<00100020>] _stext+0x20/0x80
<4>
<4> <0>Kernel panic - not syncing: Fatal exception in interrupt
<4>
After looking at the code and the dump I think the following scenario
happened: Ifup was running on cpu2 and the interrupt arrived on cpu0.
Now virtnet_open on cpu 2 managed to execute napi_enable and disable_cb
but did not execute rx_schedule. Meanwhile on cpu 0 skb_recv_done was
called by vring_interrupt, executed netif_rx_schedule_prep, which
succeeded and therefore called disable_cb. This triggered the BUG_ON,
as interrupts were already disabled by cpu 2.
I think the proper solution is to make the call to disable_cb depend on
the atomic update of NAPI_STATE_SCHED by using netif_rx_schedule_prep
in the same way as skb_recv_done.
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
Acked-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/virtio_net.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
Index: kvm/drivers/net/virtio_net.c
===
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -321,10 +321,12 @@ static int virtnet_open(struct net_devic
/* If all buffers were filled by other side before we napi_enabled, we
* won't get another interrupt, so process any outstanding packets
-* now. virtnet_poll wants re-enable the queue, so we disable here. */
- vi->rvq->vq_ops->disable_cb(vi->rvq);
- netif_rx_schedule(vi->dev, &vi->napi);
-
+* now. virtnet_poll wants re-enable the queue, so we disable here.
+* We synchronize against interrupts via NAPI_STATE_SCHED */
+ if (netif_rx_schedule_prep(dev, &vi->napi)) {
+ vi->rvq->vq_ops->disable_cb(vi->rvq);
+ __netif_rx_schedule(dev, &vi->napi);
+ }
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [e1000][net-2.6 tree] Regression: driver doesn't detect card on my node.
Yinghai Lu wrote: > On Tuesday 05 February 2008 09:24:17 am Kok, Auke wrote: >> [Added Ingo, Thomas, Justin who signed off on the patch/tested it] >> >> Pavel Emelyanov wrote: >>> The commit >>> >>> 093af8d7f0ba3c6be1485973508584ef081e9f93 >>> x86_32: trim memory by updating e820 >>> >>> broke my e1000 card: on loading driver says that >>> >>> e1000: probe of :04:03.0 failed with error -5 >>> >>> and the interface doesn't appear. >>> >>> With this commit reset everything is OK. >>> >>> lspci output: >>> 04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet >>> Controller (rev 05) >>> lspci -n output: >>> 04:03.0 Class 0200: 8086:1076 (rev 05) >>> >>> My colleague Denis Lunev has e1000 adapter too, but doesn't >>> experience such problems. >>> >>> What other info from me is required? Upd: booting with disable_mtrr_trim option helps. > > boot log please. with the patch and reverting the patch. > > Thanks > > YH > -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
> +static __init int init_syncookies(void)
> +{
> + get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
> + return 0;
> +}
> +module_init(init_syncookies);
I didn't think a module could have multiple module_inits. Are you
sure that works?
-Andi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [e1000][net-2.6 tree] Regression: driver doesn't detect card on my node.
[snip] >>> What other info from me is required? > > boot log please. with the patch and reverting the patch. Here they are (attached). BTW, I found, that the sky2 adapter is broken by this patch as well. To simplify the analysis, here's their diff: --- bad-log 2008-02-06 10:06:40.0 +0300 +++ good-log2008-02-06 10:06:40.0 +0300 @@ -1,4 +1,4 @@ -Linux version 2.6.24 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070724 (prerelease) (SUSE Linux)) #22 SMP Tue Feb 5 20:09:11 MSK 2008 +Linux version 2.6.24 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070724 (prerelease) (SUSE Linux)) #23 SMP Wed Feb 6 10:03:53 MSK 2008 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) @@ -19,29 +19,6 @@ Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at [c00ff780] 000ff780 -*** - WARNING: likely BIOS bug - MTRRs don't cover all of memory, trimmed 786432 pages -*** -update e820 for mtrr -modified physical RAM map: - modified: - 0009f800 (usable) - modified: 0009f800 - 000a (reserved) - modified: 000e - 0010 (reserved) - modified: 0010 - 4000 (usable) - modified: 4000 - bfff (reserved) - modified: bfff - b000 (ACPI data) - modified: b000 - c000 (ACPI NVS) - modified: c000 - 0001 (reserved) - modified: 0001 - 00014000 (usable) -Warning only 4GB will be used. -Use a HIGHMEM64G enabled kernel. -3200MB HIGHMEM available. -896MB LOWMEM available. -Scan SMP from c000 for 1024 bytes. -Scan SMP from c009fc00 for 1024 bytes. -Scan SMP from c00f for 65536 bytes. -found SMP MP-table at [c00ff780] 000ff780 Entering add_active_range(0, 0, 1048576) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 @@ -69,7 +46,7 @@ I/O APIC #7 Version 32 at 0xFEC0. I/O APIC #8 Version 32 at 0xFEC1. Enabling APIC mode: Flat. Using 2 I/O APICs Processors: 2 -Allocating PCI resources starting at 1010 (gap: 1000:0040) +Allocating PCI resources starting at c400 (gap: c000:3ec0) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1040384 Kernel command line: ro root=08:02 ignore_loglevel debug: ignoring loglevel setting. @@ -80,22 +57,22 @@ Enabling fast FPU save and restore... do Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) -Detected 3192.350 MHz processor. +Detected 3192.343 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) -Memory: 1011264k/4194304k available (1357k kernel code, 36260k reserved, 594k data, 168k init, 131072k highmem) +Memory: 3108104k/4194304k available (1357k kernel code, 36260k reserved, 594k data, 168k init, 2228024k highmem) virtual kernel memory layout: fixmap : 0xfffa - 0xf000 ( 380 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc05f - 0xc061a000 ( 168 kB) - .data : 0xc055375e - 0xc05e8088 ( 594 kB) - .text : 0xc040 - 0xc055375e (1357 kB) + .data : 0xc0553754 - 0xc05e8088 ( 594 kB) + .text : 0xc040 - 0xc0553754 (1357 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. -Calibrating delay using timer specific routine.. 6387.02 BogoMIPS (lpj=3193513) +Calibrating delay using timer specific routine.. 6387.05 BogoMIPS (lpj=3193528) Mount-cache hash table entries: 512 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K @@ -119,7 +96,7 @@ Intel machine check reporting enabled on CPU1: Intel P4/Xeon Extended MCE MSRs (24) available CPU1: Thermal monitoring enabled CPU1: Intel(R) Xeon(TM) CPU 3.20GHz stepping 01 -Total of 2 processors activated (12770.19 BogoMIPS). +Total of 2 processors activated (12770.22 BogoMIPS). ExtINT not setup in hardware but reported by MP table ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 @@ -153,41 +130,22 @@ PCI->APIC IRQ transform: :00:1f.3[B] PCI->APIC IRQ transform: :02:00.0[A] -> IRQ 16 PCI->APIC IRQ transform: :04:02.0[A] -> IRQ 17 PCI->APIC IRQ transform: :04:03.0[A] -> IRQ 16 -PCI: Cannot allocate resource region 8 of bridge :00:03.0 -PCI: Cannot allocate resource region 8 of bridge :00:1e.0 -PCI: Cannot allocate resource region 0 of device :00:1d.4 -PCI: Cannot allocate resource region 0 of device :00:1d.7 -PCI: Cannot allocate resource region 0 of device 0
Re: [PATCH][RFC] race in generic address resolution
From: Blaschka <[EMAIL PROTECTED]>
Date: Mon, 4 Feb 2008 15:27:17 +0100
> I'm running a SMP maschine (2 CPUs) configured as a router. During heavy
> traffic kernel dies with following message:
>
> <2>kernel BUG at
> /home/autobuild/BUILD/linux-2.6.23-20080125/net/core/skbuff.c:648!
...
> Following patch fixes the problem but I do not know if it is a good sollution.
>
> From: Frank Blaschka <[EMAIL PROTECTED]>
>
> neigh_update sends skb from neigh->arp_queue while
> neigh_timer_handler has increased skbs refcount and calls
> solicit with the skb. Do not send neighbour skbs
> marked for solicit (skb_shared).
>
> Signed-off-by: Frank Blaschka <[EMAIL PROTECTED]>
Thanks for finding this bug.
I'm fine with your approach as a temporary fix, but there is a slight
problem with your patch. If the skb is shared we have to free it if
we don't pass it on to ->output(), otherwise this creates a leak.
In the longer term, this is an unfortunate limitation. The
->solicit() code just wants to look at a few header fields to
determine how to construct the solicitation request.
What's funny is that we added these skb_get() calls for
the solications exactly to deal with this race condition.
I considered various ways to fix this. The simplest is probably just
to skb_copy() in the ->solicit() case. Solicitation is a rare event
so it's not big deal to copy the packet until the neighbour is
resolved.
The other option is holding the write lock on neigh->lock during the
->solicit() call. I looked at all of the ndisc_ops implementations
and this seems workable. The only case that needs special care is the
IPV4 ARP implementation of arp_solicit(). It wants to take
neigh->lock as a reader to protect the header entry in neigh->ha
during the emission of the soliciation. We can simply remove the read
lock calls to take care of that since holding the lock as a writer at
the caller providers a superset of the protection afforded by the
existing read locking.
The rest of the ->solicit() implementations don't care whether
the neigh is locked or not.
Can you see if this version of the patch fixes your problem?
Thanks!
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index a16cf1e..7bb6a9a 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -834,18 +834,12 @@ static void neigh_timer_handler(unsigned long arg)
}
if (neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) {
struct sk_buff *skb = skb_peek(&neigh->arp_queue);
- /* keep skb alive even if arp_queue overflows */
- if (skb)
- skb_get(skb);
- write_unlock(&neigh->lock);
+
neigh->ops->solicit(neigh, skb);
atomic_inc(&neigh->probes);
- if (skb)
- kfree_skb(skb);
- } else {
-out:
- write_unlock(&neigh->lock);
}
+out:
+ write_unlock(&neigh->lock);
if (notify)
neigh_update_notify(neigh);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 8e17f65..c663fa5 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -368,7 +368,6 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
if (!(neigh->nud_state&NUD_VALID))
printk(KERN_DEBUG "trying to ucast probe in
NUD_INVALID\n");
dst_ha = neigh->ha;
- read_lock_bh(&neigh->lock);
} else if ((probes -= neigh->parms->app_probes) < 0) {
#ifdef CONFIG_ARPD
neigh_app_ns(neigh);
@@ -378,8 +377,6 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
arp_send(ARPOP_REQUEST, ETH_P_ARP, target, dev, saddr,
dst_ha, dev->dev_addr, NULL);
- if (dst_ha)
- read_unlock_bh(&neigh->lock);
}
static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
--
To unsubscribe from this list: send 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] virtio_net: Fix open <-> interrupt race
On Wednesday 06 February 2008 00:36:10 Christian Borntraeger wrote: > I got the following oops during interface ifup. Unfortunately its not > easily reproducable so I cant say for sure that my fix fixes this > problem, but I am confident and I think its correct anyway: Looks fine, and certainly shouldn't hurt. Please push this out. Acked-by: Rusty Russell <[EMAIL PROTECTED]> Thanks, Rusty. -- To unsubscribe from this list: send 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] ipvs: Make wrr "no available servers" error message rate-limited
From: Simon Horman <[EMAIL PROTECTED]> Date: Wed, 6 Feb 2008 11:19:09 +0900 > On Tue, Feb 05, 2008 at 09:30:21PM +0100, Sven Wegener wrote: > > No available servers is more an error message than something informational. > > It > > should also be rate-limited, else we're going to flood our logs on a busy > > director, if all real servers are out of order with a weight of zero. > > > > Signed-off-by: Sven Wegener <[EMAIL PROTECTED]> > > Hi Sven, > > this looks good to me. > > Acked-by: Simon Horman <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: wireless-2.6 'fixes' 2008-02-05
From: "John W. Linville" <[EMAIL PROTECTED]> Date: Tue, 5 Feb 2008 21:59:02 -0500 > Some fixes intended for 2.6.25, especially some ports to b43legacy of > some b43 fixes that are already merged. Please let me know if there are > problems. Pulled, thanks a lot 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
pull request: wireless-2.6 'fixes' 2008-02-05
Dave,
Some fixes intended for 2.6.25, especially some ports to b43legacy of
some b43 fixes that are already merged. Please let me know if there are
problems.
Thanks!
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes
---
The following changes since commit 9ef9dc69d4167276c04590d67ee55de8380bc1ad:
Linus Torvalds (1):
Merge branch 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes
Adrian Bunk (1):
iwl3945-base.c: fix off-by-one errors
Andrew Morton (1):
b43: fix build with CONFIG_SSB_PCIHOST=n
Michael Buesch (2):
mac80211: Is not EXPERIMENTAL anymore
b43: Fix DMA for 30/32-bit DMA engines
Stefano Brivio (4):
b43legacy: fix PIO crash
b43legacy: fix suspend/resume
b43legacy: drop packets we are not able to encrypt
b43legacy: fix DMA slot resource leakage
drivers/net/wireless/b43/dma.c | 137 ++-
drivers/net/wireless/b43/dma.h | 20 ++--
drivers/net/wireless/b43legacy/dma.c| 23 -
drivers/net/wireless/b43legacy/main.c |9 ++-
drivers/net/wireless/b43legacy/pio.c| 21 -
drivers/net/wireless/b43legacy/xmit.c | 15 +++-
drivers/net/wireless/b43legacy/xmit.h |2 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c |8 +-
include/linux/ssb/ssb.h |9 ++
net/mac80211/Kconfig|1 -
10 files changed, 171 insertions(+), 74 deletions(-)
diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index 8a708b7..3dfb28a 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -337,7 +337,7 @@ static inline int txring_to_priority(struct b43_dmaring
*ring)
return idx_to_prio[index];
}
-u16 b43_dmacontroller_base(int dma64bit, int controller_idx)
+static u16 b43_dmacontroller_base(enum b43_dmatype type, int controller_idx)
{
static const u16 map64[] = {
B43_MMIO_DMA64_BASE0,
@@ -356,7 +356,7 @@ u16 b43_dmacontroller_base(int dma64bit, int controller_idx)
B43_MMIO_DMA32_BASE5,
};
- if (dma64bit) {
+ if (type == B43_DMA_64BIT) {
B43_WARN_ON(!(controller_idx >= 0 &&
controller_idx < ARRAY_SIZE(map64)));
return map64[controller_idx];
@@ -437,7 +437,7 @@ static int alloc_ringmemory(struct b43_dmaring *ring)
* 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
* which accounts for the GFP_DMA flag below.
*/
- if (ring->dma64)
+ if (ring->type == B43_DMA_64BIT)
flags |= GFP_DMA;
ring->descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
&(ring->dmabase), flags);
@@ -459,7 +459,8 @@ static void free_ringmemory(struct b43_dmaring *ring)
}
/* Reset the RX DMA channel */
-int b43_dmacontroller_rx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
+static int b43_dmacontroller_rx_reset(struct b43_wldev *dev, u16 mmio_base,
+ enum b43_dmatype type)
{
int i;
u32 value;
@@ -467,12 +468,13 @@ int b43_dmacontroller_rx_reset(struct b43_wldev *dev, u16
mmio_base, int dma64)
might_sleep();
- offset = dma64 ? B43_DMA64_RXCTL : B43_DMA32_RXCTL;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_RXCTL : B43_DMA32_RXCTL;
b43_write32(dev, mmio_base + offset, 0);
for (i = 0; i < 10; i++) {
- offset = dma64 ? B43_DMA64_RXSTATUS : B43_DMA32_RXSTATUS;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_RXSTATUS :
+ B43_DMA32_RXSTATUS;
value = b43_read32(dev, mmio_base + offset);
- if (dma64) {
+ if (type == B43_DMA_64BIT) {
value &= B43_DMA64_RXSTAT;
if (value == B43_DMA64_RXSTAT_DISABLED) {
i = -1;
@@ -496,7 +498,8 @@ int b43_dmacontroller_rx_reset(struct b43_wldev *dev, u16
mmio_base, int dma64)
}
/* Reset the TX DMA channel */
-int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
+static int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base,
+ enum b43_dmatype type)
{
int i;
u32 value;
@@ -505,9 +508,10 @@ int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16
mmio_base, int dma64)
might_sleep();
for (i = 0; i < 10; i++) {
- offset = dma64 ? B43_DMA64_TXSTATUS : B43_DMA32_TXSTATUS;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_TXSTATUS :
+
Re: [PATCH] ipvs: Make wrr "no available servers" error message rate-limited
On Tue, Feb 05, 2008 at 09:30:21PM +0100, Sven Wegener wrote: > No available servers is more an error message than something informational. It > should also be rate-limited, else we're going to flood our logs on a busy > director, if all real servers are out of order with a weight of zero. > > Signed-off-by: Sven Wegener <[EMAIL PROTECTED]> Hi Sven, this looks good to me. Acked-by: Simon Horman <[EMAIL PROTECTED]> > --- > > Actually, do we need this message at all? The wrr scheduler is the only one > printing an error message in such a case. I was wondering about that too. Though I'd err on the side of adding it to the other schedulers as neccessary rather than removing it here. But if you'd rather just get rid of it, I have no strong objections. -- Horms -- To unsubscribe from this list: send 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/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
On Monday 04 February 2008, Ayaz Abdulla wrote: > Jeff Garzik wrote: > > Ayaz Abdulla wrote: > >> I believe Michael determined that a newer BIOS fixes this issue. > > > > That's a solution that makes vendors happy... but we still have to deal > > with it in Linux. There are plenty of the old broken BIOS still out in > > the field... > > > > Jeff > > Michael, can you provide which BIOS version had this issue and which > version fixed the issue? Ayaz, One of my earlier messages to the list was from BIOS revision F3 from what I can tell (which matches pretty well with what I remember having). I am currently on F8. I may go back to F3 if I can get booting from USB to work just to verify because I could have sworn it was still broken after going to F8. But since unpatched Linux 2.6.23.12 apparently works fine and I'm not sure when exactly that happened (I use Ketchup to maintain the sources and somewhere it unpatched my forcedeth.c :) I want to double-check that a simple BIOS upgrade will solve it. But I also don't have a lot of time before I go underway for a few months. :-/ Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/2] Remove unnecessary locks from rtnetlink
From: Laszlo Attila Toth <[EMAIL PROTECTED]> Date: Fri, 1 Feb 2008 17:07:33 +0100 > The do_setlink() function is protected by rtnl, additional locks are > unnecessary. > and the set_operstate() function is called from protected parts. Locks removed > from both functions. > > The set_operstate() is also called from rtnl_create_link() and from no other > places. > In rtnl_create_link() none of the changes is protected by set_lock_bh() except > inside set_operstate(), different locking scheme is not necessary > for the operstate. > > Signed-off-by: Laszlo Attila Toth <[EMAIL PROTECTED]> The protection using dev_base_lock() is needed. When analyzing cases like this you need to also look at other code paths outside of rtnetlink that access ->operstate and ->link_mode, you obviously didn't do this. For example, net/core/net-sysfs.c takes a read lock on dev_base_lock in order to fetch a stable copy of both netif_running() and dev->operstate at the same time. Similar write locking to protect dev->operstate is made by net/core/link_watch.c:rfc2863_policy(), for the same reason rtnetlink has to make this locking. You therefore cannot remove it. This invalidates your second patch so I'm dropping that as well. -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
I realized an earlier email I sent had an incorrect timestamp and wasn't
associated with the thread, so I thought it would be better to resend.
I apologize if this is duplicated for anyone.
Here is a reworked patch that moves the IPv6 syncookie support out of
the ipv4/syncookies.c file and into it's own ipv6/syncookies.c. The
same CONFIG options and sysctl variables as ipv4, but this way the code
is isolated to the ipv6 module.
Signed-off-by: Glenn Griffin <[EMAIL PROTECTED]>
---
include/net/tcp.h |6 +
net/ipv6/Makefile |1 +
net/ipv6/syncookies.c | 273 +
net/ipv6/tcp_ipv6.c | 77 ++
4 files changed, 335 insertions(+), 22 deletions(-)
create mode 100644 net/ipv6/syncookies.c
diff --git a/include/net/tcp.h b/include/net/tcp.h
index cb5b033..d7f620c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -436,6 +436,11 @@ extern struct sock *cookie_v4_check(struct sock *sk,
struct sk_buff *skb,
extern __u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb,
__u16 *mss);
+/* From net/ipv6/syncookies.c */
+extern struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb);
+extern __u32 cookie_v6_init_sequence(struct sock *sk, struct sk_buff *skb,
+__u16 *mss);
+
/* tcp_output.c */
extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss,
@@ -1337,6 +1342,7 @@ extern int tcp_proc_register(struct tcp_seq_afinfo
*afinfo);
extern void tcp_proc_unregister(struct tcp_seq_afinfo *afinfo);
extern struct request_sock_ops tcp_request_sock_ops;
+extern struct request_sock_ops tcp6_request_sock_ops;
extern int tcp_v4_destroy_sock(struct sock *sk);
diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile
index 87c23a7..d1a1056 100644
--- a/net/ipv6/Makefile
+++ b/net/ipv6/Makefile
@@ -15,6 +15,7 @@ ipv6-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o
xfrm6_input.o \
ipv6-$(CONFIG_NETFILTER) += netfilter.o
ipv6-$(CONFIG_IPV6_MULTIPLE_TABLES) += fib6_rules.o
ipv6-$(CONFIG_PROC_FS) += proc.o
+ipv6-$(CONFIG_SYN_COOKIES) += syncookies.o
ipv6-objs += $(ipv6-y)
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
new file mode 100644
index 000..521c9da
--- /dev/null
+++ b/net/ipv6/syncookies.c
@@ -0,0 +1,273 @@
+/*
+ * IPv6 Syncookies implementation for the Linux kernel
+ *
+ * Authors:
+ * Glenn Griffin <[EMAIL PROTECTED]>
+ *
+ * Based on IPv4 implementation by Andi Kleen
+ * linux/net/ipv4/syncookies.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+extern int sysctl_tcp_syncookies;
+
+static __u32 syncookie_secret[2][16-10+SHA_DIGEST_WORDS];
+
+static __init int init_syncookies(void)
+{
+ get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
+ return 0;
+}
+module_init(init_syncookies);
+
+#define COOKIEBITS 24 /* Upper bits store count */
+#define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
+
+/*
+ * This table has to be sorted and terminated with (__u16)-1.
+ * XXX generate a better table.
+ * Unresolved Issues: HIPPI with a 64k MSS is not well supported.
+ *
+ * Taken directly from ipv4 implementation.
+ * Should this list be modified for ipv6 use or is it close enough?
+ * rfc 2460 8.3 suggests mss values 20 bytes less than ipv4 counterpart
+ */
+static __u16 const msstab[] = {
+ 64 - 1,
+ 256 - 1,
+ 512 - 1,
+ 536 - 1,
+ 1024 - 1,
+ 1440 - 1,
+ 1460 - 1,
+ 4312 - 1,
+ (__u16)-1
+};
+/* The number doesn't include the -1 terminator */
+#define NUM_MSS (ARRAY_SIZE(msstab) - 1)
+
+/*
+ * This (misnamed) value is the age of syncookie which is permitted.
+ * Its ideal value should be dependent on TCP_TIMEOUT_INIT and
+ * sysctl_tcp_retries1. It's a rather complicated formula (exponential
+ * backoff) to compute at runtime so it's currently hardcoded here.
+ */
+#define COUNTER_TRIES 4
+
+static inline struct sock *get_cookie_sock(struct sock *sk, struct sk_buff
*skb,
+ struct request_sock *req,
+ struct dst_entry *dst)
+{
+ struct inet_connection_sock *icsk = inet_csk(sk);
+ struct sock *child;
+
+ child = icsk->icsk_af_ops->syn_recv_sock(sk, skb, req, dst);
+ if (child)
+ inet_csk_reqsk_queue_add(sk, req, child);
+ else
+ reqsk_free(req);
+
+ return child;
+}
+
+static u32 cookie_hash(struct in6_addr *saddr, struct in6_addr *daddr,
+ __be16 sport, __be16 dport, u32 count, int c)
+{
+ __u32 tmp[16 + 5 + SHA_WORKSPACE_WORDS];
+
+ /*
Re: [PATCH] [IPV4]: Fix compiler error with CONFIG_PROC_FS=n
From: Johann Felix Soden <[EMAIL PROTECTED]> Date: Tue, 05 Feb 2008 19:43:54 +0100 > From: Johann Felix Soden <[EMAIL PROTECTED]> > > Handle CONFIG_PROC_FS=n in net/ipv4/fib_frontend.c because: > > net/ipv4/fib_frontend.c: In function 'fib_net_init': > net/ipv4/fib_frontend.c:1032: error: implicit declaration of function > 'fib_proc_init' > net/ipv4/fib_frontend.c: In function 'fib_net_exit': > net/ipv4/fib_frontend.c:1047: error: implicit declaration of function > 'fib_proc_exit' > > Signed-off-by: Johann Felix Soden <[EMAIL PROTECTED]> I'm pretty sure I merged in a change this morning which fixes this. BTW, in general we do not put ifdefs into *.c code to fix stuff like this, instead we add empty implementations into a header file which is a better place for ifdef tests. And that's how the patch which was merged handles this problem. -- To unsubscribe from this list: send 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] [PPPOL2TP] Label unused warning when CONFIG_PROC_FS is not set.
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Tue, 05 Feb 2008 13:22:19 -0500 > David or Paul, wanna pick this up? I took it, no worries. -- To unsubscribe from this list: send 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] [PPPOL2TP] Label unused warning when CONFIG_PROC_FS is not set.
From: James Chapman <[EMAIL PROTECTED]> Date: Tue, 05 Feb 2008 17:38:10 + > Acked-by: James Chapman <[EMAIL PROTECTED]> Applied, thanks everyone. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET_SCHED 04/04]: cls_flow: support classification based on VLAN tag
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Tue, 5 Feb 2008 15:29:44 +0100 (MET) > [NET_SCHED]: cls_flow: support classification based on VLAN tag > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Also applied, thanks a lot. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [VLAN 03/04]: Constify skb argument to vlan_get_tag()
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Tue, 5 Feb 2008 15:29:43 +0100 (MET) > [VLAN]: Constify skb argument to vlan_get_tag() > > Required by next patch to use it from the flow classifier. > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET_SCHED 01/04]: em_meta: fix compile warning
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Tue, 5 Feb 2008 15:29:40 +0100 (MET) > [NET_SCHED]: em_meta: fix compile warning > > net/sched/em_meta.c: In function 'meta_int_vlan_tag': > net/sched/em_meta.c:179: warning: 'tag' may be used uninitialized in this > function > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET_SCHED 02/04]: cls_flow: fix key mask validity check
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Tue, 5 Feb 2008 15:29:41 +0100 (MET) > [NET_SCHED]: cls_flow: fix key mask validity check > > Since we're using fls(), we need to check whether the value is non-zero first. > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add IPv6 support to TCP SYN cookies
Here is a reworked implementation that restricts the code to the ipv6 module as
Andi suggested. Uses the same CONFIG and sysctl variables as the ipv4
implementation.
Signed-off-by: Glenn Griffin <[EMAIL PROTECTED]>
---
include/net/tcp.h |6 +
net/ipv6/Makefile |1 +
net/ipv6/syncookies.c | 273 +
net/ipv6/tcp_ipv6.c | 77 ++
4 files changed, 335 insertions(+), 22 deletions(-)
create mode 100644 net/ipv6/syncookies.c
diff --git a/include/net/tcp.h b/include/net/tcp.h
index cb5b033..d7f620c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -436,6 +436,11 @@ extern struct sock *cookie_v4_check(struct sock *sk,
struct sk_buff *skb,
extern __u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb,
__u16 *mss);
+/* From net/ipv6/syncookies.c */
+extern struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb);
+extern __u32 cookie_v6_init_sequence(struct sock *sk, struct sk_buff *skb,
+__u16 *mss);
+
/* tcp_output.c */
extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss,
@@ -1337,6 +1342,7 @@ extern int tcp_proc_register(struct tcp_seq_afinfo
*afinfo);
extern void tcp_proc_unregister(struct tcp_seq_afinfo *afinfo);
extern struct request_sock_ops tcp_request_sock_ops;
+extern struct request_sock_ops tcp6_request_sock_ops;
extern int tcp_v4_destroy_sock(struct sock *sk);
diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile
index 87c23a7..d1a1056 100644
--- a/net/ipv6/Makefile
+++ b/net/ipv6/Makefile
@@ -15,6 +15,7 @@ ipv6-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o
xfrm6_input.o \
ipv6-$(CONFIG_NETFILTER) += netfilter.o
ipv6-$(CONFIG_IPV6_MULTIPLE_TABLES) += fib6_rules.o
ipv6-$(CONFIG_PROC_FS) += proc.o
+ipv6-$(CONFIG_SYN_COOKIES) += syncookies.o
ipv6-objs += $(ipv6-y)
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
new file mode 100644
index 000..521c9da
--- /dev/null
+++ b/net/ipv6/syncookies.c
@@ -0,0 +1,273 @@
+/*
+ * IPv6 Syncookies implementation for the Linux kernel
+ *
+ * Authors:
+ * Glenn Griffin <[EMAIL PROTECTED]>
+ *
+ * Based on IPv4 implementation by Andi Kleen
+ * linux/net/ipv4/syncookies.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+extern int sysctl_tcp_syncookies;
+
+static __u32 syncookie_secret[2][16-10+SHA_DIGEST_WORDS];
+
+static __init int init_syncookies(void)
+{
+ get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
+ return 0;
+}
+module_init(init_syncookies);
+
+#define COOKIEBITS 24 /* Upper bits store count */
+#define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
+
+/*
+ * This table has to be sorted and terminated with (__u16)-1.
+ * XXX generate a better table.
+ * Unresolved Issues: HIPPI with a 64k MSS is not well supported.
+ *
+ * Taken directly from ipv4 implementation.
+ * Should this list be modified for ipv6 use or is it close enough?
+ * rfc 2460 8.3 suggests mss values 20 bytes less than ipv4 counterpart
+ */
+static __u16 const msstab[] = {
+ 64 - 1,
+ 256 - 1,
+ 512 - 1,
+ 536 - 1,
+ 1024 - 1,
+ 1440 - 1,
+ 1460 - 1,
+ 4312 - 1,
+ (__u16)-1
+};
+/* The number doesn't include the -1 terminator */
+#define NUM_MSS (ARRAY_SIZE(msstab) - 1)
+
+/*
+ * This (misnamed) value is the age of syncookie which is permitted.
+ * Its ideal value should be dependent on TCP_TIMEOUT_INIT and
+ * sysctl_tcp_retries1. It's a rather complicated formula (exponential
+ * backoff) to compute at runtime so it's currently hardcoded here.
+ */
+#define COUNTER_TRIES 4
+
+static inline struct sock *get_cookie_sock(struct sock *sk, struct sk_buff
*skb,
+ struct request_sock *req,
+ struct dst_entry *dst)
+{
+ struct inet_connection_sock *icsk = inet_csk(sk);
+ struct sock *child;
+
+ child = icsk->icsk_af_ops->syn_recv_sock(sk, skb, req, dst);
+ if (child)
+ inet_csk_reqsk_queue_add(sk, req, child);
+ else
+ reqsk_free(req);
+
+ return child;
+}
+
+static u32 cookie_hash(struct in6_addr *saddr, struct in6_addr *daddr,
+ __be16 sport, __be16 dport, u32 count, int c)
+{
+ __u32 tmp[16 + 5 + SHA_WORKSPACE_WORDS];
+
+ /*
+* we have 320 bits of information to hash, copy in the remaining
+* 192 bits required for sha_transform, from the syncookie_secret
+* and overwrite the digest with the secret
+*/
+ memcpy(tmp + 10, syncookie_secret[c], sizeof(syn
Re: [PATCH 01/24 for-2.6.25] DM9000: Fix endian-ness of data accesses. Patch from: Laurent Pinchart
Ben Dooks <[EMAIL PROTECTED]> :
> This patch splits the receive status in 8bit wide fields and convert the
> packet length from little endian to CPU byte order.
>
> Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
> Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
>
> Index: linux-2.6.24-git5-dm9k/drivers/net/dm9000.c
> ===
> --- linux-2.6.24-git5-dm9k.orig/drivers/net/dm9000.c
> +++ linux-2.6.24-git5-dm9k/drivers/net/dm9000.c
> @@ -867,7 +867,8 @@ dm9000_timer(unsigned long data)
> }
>
> struct dm9000_rxhdr {
> - u16 RxStatus;
> + u8 RxPktReady;
> + u8 RxStatus;
> u16 RxLen;
Given the description of the patch, you could s/u16/__le16/
Al regularly pushes endianness fixes. You can save him some work.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/24 for-2.6.25] DM9000: Add initial ethtool support
Ben Dooks <[EMAIL PROTECTED]> :
> Add support for ethtool operations for the DM9000.
>
> Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
>
> Index: linux-2.6.24-quilt3/drivers/net/dm9000.c
> ===
> --- linux-2.6.24-quilt3.orig/drivers/net/dm9000.c
> +++ linux-2.6.24-quilt3/drivers/net/dm9000.c
[...]
> +static int dm9000_get_settings(struct net_device *dev, struct ethtool_cmd
> *cmd)
> +{
> + board_info_t *dm = to_dm9000_board(dev);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dm->lock, flags);
> + mii_ethtool_gset(&dm->mii, cmd);
drivers/net/mii.c::mii_ethtool_gset
[...]
advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE);
drivers/net/dm9000.c::dm9000_probe
[...]
db->mii.mdio_read= dm9000_phy_read;
drivers/net/dm9000.c::dm9000_phy_read
[...]
board_info_t *db = (board_info_t *) dev->priv;
unsigned long flags;
unsigned int reg_save;
int ret;
spin_lock_irqsave(&db->lock,flags);
-> deadlock
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pull request for 'r6040' branch
Please pull from branch 'r6040' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r6040
to get the changes below.
I have simply rebased the r6040 branch from december on top of
Linus's latest head and given each patch a compile test.
The content is identical to Florian's initial work (minus the
removal of the unused TIMER_WUT and a duplicate update of an
error counter).
Distance from 'master' (21511abd0a248a3f225d3b611cfabb93124605a7)
-
ec6d2d453a932fd50c5fd95d5aac633b4e5f241d
106adf3c84d081776a1d1fbb8a047cad12af2bb9
b4f1255d6839bd970d5ff20a9c3d73f73c9adaa3
d248fd77902fcf33b0bc49ab521930877d94890f
Diffstat
drivers/net/r6040.c | 233 +-
1 files changed, 135 insertions(+), 98 deletions(-)
Shortlog
Florian Fainelli (4):
r6040: do not use a private stats structure to store statistics
r6040: add helpers to allocate and free the Tx/Rx buffers
r6040: recover from transmit timeout
r6040: cleanups
Patch
-
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 2334f4e..19184e4 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -61,7 +61,6 @@
/* Time in jiffies before concluding the transmitter is hung. */
#define TX_TIMEOUT (6000 * HZ / 1000)
-#define TIMER_WUT (jiffies + HZ * 1)/* timer wakeup time : 1 second */
/* RDC MAC I/O Size */
#define R6040_IO_SIZE 256
@@ -174,8 +173,6 @@ struct r6040_private {
struct net_device *dev;
struct mii_if_info mii_if;
struct napi_struct napi;
- struct net_device_stats stats;
- u16 napi_rx_running;
void __iomem *base;
};
@@ -235,17 +232,53 @@ static void mdio_write(struct net_device *dev, int
mii_id, int reg, int val)
phy_write(ioaddr, lp->phy_addr, reg, val);
}
-static void r6040_tx_timeout(struct net_device *dev)
+static void r6040_free_txbufs(struct net_device *dev)
{
- struct r6040_private *priv = netdev_priv(dev);
+ struct r6040_private *lp = netdev_priv(dev);
+ int i;
- disable_irq(dev->irq);
- napi_disable(&priv->napi);
- spin_lock(&priv->lock);
- dev->stats.tx_errors++;
- spin_unlock(&priv->lock);
+ for (i = 0; i < TX_DCNT; i++) {
+ if (lp->tx_insert_ptr->skb_ptr) {
+ pci_unmap_single(lp->pdev, lp->tx_insert_ptr->buf,
+ MAX_BUF_SIZE, PCI_DMA_TODEVICE);
+ dev_kfree_skb(lp->tx_insert_ptr->skb_ptr);
+ lp->rx_insert_ptr->skb_ptr = NULL;
+ }
+ lp->tx_insert_ptr = lp->tx_insert_ptr->vndescp;
+ }
+}
- netif_stop_queue(dev);
+static void r6040_free_rxbufs(struct net_device *dev)
+{
+ struct r6040_private *lp = netdev_priv(dev);
+ int i;
+
+ for (i = 0; i < RX_DCNT; i++) {
+ if (lp->rx_insert_ptr->skb_ptr) {
+ pci_unmap_single(lp->pdev, lp->rx_insert_ptr->buf,
+ MAX_BUF_SIZE, PCI_DMA_FROMDEVICE);
+ dev_kfree_skb(lp->rx_insert_ptr->skb_ptr);
+ lp->rx_insert_ptr->skb_ptr = NULL;
+ }
+ lp->rx_insert_ptr = lp->rx_insert_ptr->vndescp;
+ }
+}
+
+static void r6040_init_ring_desc(struct r6040_descriptor *desc_ring,
+dma_addr_t desc_dma, int size)
+{
+ struct r6040_descriptor *desc = desc_ring;
+ dma_addr_t mapping = desc_dma;
+
+ while (size-- > 0) {
+ mapping += sizeof(sizeof(*desc));
+ desc->ndesc = cpu_to_le32(mapping);
+ desc->vndescp = desc + 1;
+ desc++;
+ }
+ desc--;
+ desc->ndesc = cpu_to_le32(desc_dma);
+ desc->vndescp = desc_ring;
}
/* Allocate skb buffer for rx descriptor */
@@ -256,7 +289,7 @@ static void rx_buf_alloc(struct r6040_private *lp, struct
net_device *dev)
descptr = lp->rx_insert_ptr;
while (lp->rx_free_desc < RX_DCNT) {
- descptr->skb_ptr = dev_alloc_skb(MAX_BUF_SIZE);
+ descptr->skb_ptr = netdev_alloc_skb(dev, MAX_BUF_SIZE);
if (!descptr->skb_ptr)
break;
@@ -272,6 +305,63 @@ static void rx_buf_alloc(struct r6040_private *lp, struct
net_device *dev)
lp->rx_insert_ptr = descptr;
}
+static void r6040_alloc_txbufs(struct net_device *dev)
+{
+ struct r6040_private *lp = netdev_priv(dev);
+ void __iomem *ioaddr = lp->base;
+
+ lp->tx_free_desc = TX_DCNT;
+
+ lp->tx_remove_ptr = lp->tx_insert_ptr = lp->tx_ring;
+ r6040_init_ring_desc(lp->tx_ring, lp->tx_ring_dma, TX_DCNT);
+
+ iowrite16(lp->tx_ring_dma, ioaddr + MTD_SA0);
+ iowrite16(lp->tx_ring_dma >> 16, ioaddr + MTD_SA1);
+}
+
+static void r6040_alloc_rxbufs(struct net_device *dev)
+{
+
[PATCH] Fix PHY Lib support for gianfar and ucc_geth
The PHY Lib now uses mutexes instead of spin_locks. ucc_geth
and gianfar both grab the locks in their mdio_reset functions,
so they need to use mutex_(un)lock instead. This was not caught
until someone tested it on an SMP system.
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
drivers/net/gianfar_mii.c |4 ++--
drivers/net/ucc_geth_mii.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index 100bf41..6a647d9 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -127,7 +127,7 @@ int gfar_mdio_reset(struct mii_bus *bus)
struct gfar_mii __iomem *regs = (void __iomem *)bus->priv;
unsigned int timeout = PHY_INIT_TIMEOUT;
- spin_lock_bh(&bus->mdio_lock);
+ mutex_lock(&bus->mdio_lock);
/* Reset the management interface */
gfar_write(®s->miimcfg, MIIMCFG_RESET);
@@ -140,7 +140,7 @@ int gfar_mdio_reset(struct mii_bus *bus)
timeout--)
cpu_relax();
- spin_unlock_bh(&bus->mdio_lock);
+ mutex_unlock(&bus->mdio_lock);
if(timeout <= 0) {
printk(KERN_ERR "%s: The MII Bus is stuck!\n",
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index e3ba14a..c69e654 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -109,7 +109,7 @@ int uec_mdio_reset(struct mii_bus *bus)
struct ucc_mii_mng __iomem *regs = (void __iomem *)bus->priv;
unsigned int timeout = PHY_INIT_TIMEOUT;
- spin_lock_bh(&bus->mdio_lock);
+ mutex_lock(&bus->mdio_lock);
/* Reset the management interface */
out_be32(®s->miimcfg, MIIMCFG_RESET_MANAGEMENT);
@@ -121,7 +121,7 @@ int uec_mdio_reset(struct mii_bus *bus)
while ((in_be32(®s->miimind) & MIIMIND_BUSY) && timeout--)
cpu_relax();
- spin_unlock_bh(&bus->mdio_lock);
+ mutex_unlock(&bus->mdio_lock);
if (timeout <= 0) {
printk(KERN_ERR "%s: The MII Bus is stuck!\n", bus->name);
--
1.5.0.2.230.gfbe3d-dirty
--
To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
> SACK is actually a good idea for mobile devices, so preventing > syncookies from not getting into account some options (btw, does it work > with timestamps and PAWS?) is not a solution. Syncookies only get used at the point where the alternative is failure. No SACK beats a DoS situation most days -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Wed, Feb 06, 2008 at 12:52:17AM +0300, Evgeniy Polyakov wrote: > Hi Alan. > > On Tue, Feb 05, 2008 at 09:20:17PM +, Alan Cox ([EMAIL PROTECTED]) wrote: > > > Most (if not all) distributions have them enabled and window growing > > > works just fine. Actually I do not see any reason why connection > > > establishment handshake should prevent any run-time operations at all, > > > even if it was setup during handshake. > > > > Syncookies are only triggered if the system is under a load where it > > would begin to lose connections otherwise. So they merely turn a DoS into > > a working if slightly slower setup (and > 64K windows don't matter for > > most normal users, especially on mobile devices). > > SACK is actually a good idea for mobile devices, so preventing > syncookies from not getting into account some options (btw, does it work > with timestamps and PAWS?) is not a solution. All TCP options negociated during session setup are lost. In fact, some bits (3) are still reserved for the best known value of the MSS, but that's all. The principle of SYN cookies is that the server does not create any session upon the SYN, but builds a sequence number constitued from a hash and the values it absolutely needs to know when the client validates the session with an ACK. I've seen some firewalls acting as SYN gateways which send the options from the server to the client in the first ACK packet from the server. This is normally not allowed, but it seems to work with some TCP stacks (at least for the MSS). One solution would be to extend TCP to officially support this behaviour and to optionally use it along with SYN cookies, but there will always be old clients not compatible with the extension. Regards, Willy -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
Hi Alan. On Tue, Feb 05, 2008 at 09:20:17PM +, Alan Cox ([EMAIL PROTECTED]) wrote: > > Most (if not all) distributions have them enabled and window growing > > works just fine. Actually I do not see any reason why connection > > establishment handshake should prevent any run-time operations at all, > > even if it was setup during handshake. > > Syncookies are only triggered if the system is under a load where it > would begin to lose connections otherwise. So they merely turn a DoS into > a working if slightly slower setup (and > 64K windows don't matter for > most normal users, especially on mobile devices). SACK is actually a good idea for mobile devices, so preventing syncookies from not getting into account some options (btw, does it work with timestamps and PAWS?) is not a solution. -- 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] Add IPv6 support to TCP SYN cookies
On Tue, Feb 05, 2008 at 09:53:45PM +0100, Andi Kleen ([EMAIL PROTECTED]) wrote: > > How does syncookies prevent windows from growing? > > Syncookies do not allow window scaling so you can't have any windows >64k Then you meant not windows change, but the fact, that option is ignored as long as sack enable one? > > Most (if not all) distributions have them enabled and window growing > > works just fine. Actually I do not see any reason why connection > > establishment handshake should prevent any run-time operations at all, > > even if it was setup during handshake. > > TCP only uses options negotiated during the hand shake and syncookies > is incapable to do this. What about fixing the implementation, so that it could get into account different options too? > -Andi -- 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 5/5] forcedeth: preserve registers
Various registers need to be preserved before resetting the device.
Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>
--- old/drivers/net/forcedeth.c 2008-01-17 16:51:40.0 -0500
+++ new/drivers/net/forcedeth.c 2008-01-20 11:56:45.0 -0500
@@ -1443,16 +1443,30 @@
{
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
+ u32 temp1, temp2, temp3;
dprintk(KERN_DEBUG "%s: nv_mac_reset\n", dev->name);
+
writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET | np->txrxctl_bits,
base + NvRegTxRxControl);
pci_push(base);
+
+ /* save registers since they will be cleared on reset */
+ temp1 = readl(base + NvRegMacAddrA);
+ temp2 = readl(base + NvRegMacAddrB);
+ temp3 = readl(base + NvRegTransmitPoll);
+
writel(NVREG_MAC_RESET_ASSERT, base + NvRegMacReset);
pci_push(base);
udelay(NV_MAC_RESET_DELAY);
writel(0, base + NvRegMacReset);
pci_push(base);
udelay(NV_MAC_RESET_DELAY);
+
+ /* restore saved registers */
+ writel(temp1, base + NvRegMacAddrA);
+ writel(temp2, base + NvRegMacAddrB);
+ writel(temp3, base + NvRegTransmitPoll);
+
writel(NVREG_TXRXCTL_BIT2 | np->txrxctl_bits, base + NvRegTxRxControl);
pci_push(base);
}
[PATCH 4/5] forcedeth: tx pause watermarks
New chipsets introduced variant Rx FIFO sizes that need to be taken into
account when setting up the tx pause watermarks. This patch introduces
the new device feature flags based on a version and implements the new
watermarks.
Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>
--- old/drivers/net/forcedeth.c 2008-01-17 16:50:29.0 -0500
+++ new/drivers/net/forcedeth.c 2008-01-17 16:51:02.0 -0500
@@ -166,22 +166,24 @@
* Hardware access:
*/
-#define DEV_NEED_TIMERIRQ 0x0001 /* set the timer irq flag in the irq
mask */
-#define DEV_NEED_LINKTIMER 0x0002 /* poll link settings. Relies on the
timer irq */
-#define DEV_HAS_LARGEDESC 0x0004 /* device supports jumbo frames and
needs packet format 2 */
-#define DEV_HAS_HIGH_DMA0x0008 /* device supports 64bit dma */
-#define DEV_HAS_CHECKSUM0x0010 /* device supports tx and rx checksum
offloads */
-#define DEV_HAS_VLAN0x0020 /* device supports vlan tagging and
striping */
-#define DEV_HAS_MSI 0x0040 /* device supports MSI */
-#define DEV_HAS_MSI_X 0x0080 /* device supports MSI-X */
-#define DEV_HAS_POWER_CNTRL 0x0100 /* device supports power savings */
-#define DEV_HAS_PAUSEFRAME_TX 0x0200 /* device supports tx pause frames */
-#define DEV_HAS_STATISTICS_V1 0x0400 /* device supports hw statistics
version 1 */
-#define DEV_HAS_STATISTICS_V2 0x0800 /* device supports hw statistics
version 2 */
-#define DEV_HAS_TEST_EXTENDED 0x1000 /* device supports extended diagnostic
test */
-#define DEV_HAS_MGMT_UNIT 0x2000 /* device supports management unit */
-#define DEV_HAS_CORRECT_MACADDR 0x4000 /* device supports correct mac address
order */
-#define DEV_HAS_COLLISION_FIX 0x8000 /* device supports tx collision fix */
+#define DEV_NEED_TIMERIRQ 0x1 /* set the timer irq flag in the
irq mask */
+#define DEV_NEED_LINKTIMER 0x2 /* poll link settings. Relies on
the timer irq */
+#define DEV_HAS_LARGEDESC 0x4 /* device supports jumbo frames
and needs packet format 2 */
+#define DEV_HAS_HIGH_DMA 0x8 /* device supports 64bit dma */
+#define DEV_HAS_CHECKSUM 0x00010 /* device supports tx and rx
checksum offloads */
+#define DEV_HAS_VLAN 0x00020 /* device supports vlan tagging
and striping */
+#define DEV_HAS_MSI0x00040 /* device supports MSI */
+#define DEV_HAS_MSI_X 0x00080 /* device supports MSI-X */
+#define DEV_HAS_POWER_CNTRL0x00100 /* device supports power savings */
+#define DEV_HAS_STATISTICS_V1 0x00200 /* device supports hw statistics
version 1 */
+#define DEV_HAS_STATISTICS_V2 0x00400 /* device supports hw statistics
version 2 */
+#define DEV_HAS_TEST_EXTENDED 0x00800 /* device supports extended
diagnostic test */
+#define DEV_HAS_MGMT_UNIT 0x01000 /* device supports management unit
*/
+#define DEV_HAS_CORRECT_MACADDR0x02000 /* device supports correct mac
address order */
+#define DEV_HAS_COLLISION_FIX 0x04000 /* device supports tx collision
fix */
+#define DEV_HAS_PAUSEFRAME_TX_V1 0x08000 /* device supports tx pause frames
version 1 */
+#define DEV_HAS_PAUSEFRAME_TX_V2 0x1 /* device supports tx pause frames
version 2 */
+#define DEV_HAS_PAUSEFRAME_TX_V3 0x2 /* device supports tx pause frames
version 3 */
enum {
NvRegIrqStatus = 0x000,
@@ -322,8 +324,10 @@
NvRegTxRingPhysAddrHigh = 0x148,
NvRegRxRingPhysAddrHigh = 0x14C,
NvRegTxPauseFrame = 0x170,
-#define NVREG_TX_PAUSEFRAME_DISABLE0x01ff0080
-#define NVREG_TX_PAUSEFRAME_ENABLE 0x01800010
+#define NVREG_TX_PAUSEFRAME_DISABLE0x0fff0080
+#define NVREG_TX_PAUSEFRAME_ENABLE_V1 0x01800010
+#define NVREG_TX_PAUSEFRAME_ENABLE_V2 0x056003f0
+#define NVREG_TX_PAUSEFRAME_ENABLE_V3 0x09f00880
NvRegMIIStatus = 0x180,
#define NVREG_MIISTAT_ERROR0x0001
#define NVREG_MIISTAT_LINKCHANGE 0x0008
@@ -2741,7 +2745,12 @@
if (np->pause_flags & NV_PAUSEFRAME_TX_CAPABLE) {
u32 regmisc = readl(base + NvRegMisc1) & ~NVREG_MISC1_PAUSE_TX;
if (pause_flags & NV_PAUSEFRAME_TX_ENABLE) {
- writel(NVREG_TX_PAUSEFRAME_ENABLE, base +
NvRegTxPauseFrame);
+ u32 pause_enable = NVREG_TX_PAUSEFRAME_ENABLE_V1;
+ if (np->driver_data & DEV_HAS_PAUSEFRAME_TX_V2)
+ pause_enable = NVREG_TX_PAUSEFRAME_ENABLE_V2;
+ if (np->driver_data & DEV_HAS_PAUSEFRAME_TX_V3)
+ pause_enable = NVREG_TX_PAUSEFRAME_ENABLE_V3;
+ writel(pause_enable, base + NvRegTxPauseFrame);
writel(regmisc|NVREG_MISC1_PAUSE_TX, base + NvRegMisc1);
np->pause_flags |= NV_PAUSEFRAME_TX_ENABLE;
} else {
@@ -5158,7 +5167,9 @@
}
[PATCH 2/5] forcedeth: tx collision fix
This patch supports a new fix in hardware regarding tx collisions. In
the cases where we are in autoneg mode and the link partner is in forced
mode, we need to setup the tx deferral register differently in order to
reduce collisions on the wire.
Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>
--- old/drivers/net/forcedeth.c 2008-01-15 17:44:38.0 -0500
+++ new/drivers/net/forcedeth.c 2008-01-15 18:28:08.0 -0500
@@ -181,6 +181,7 @@
#define DEV_HAS_TEST_EXTENDED 0x1000 /* device supports extended diagnostic
test */
#define DEV_HAS_MGMT_UNIT 0x2000 /* device supports management unit */
#define DEV_HAS_CORRECT_MACADDR 0x4000 /* device supports correct mac address
order */
+#define DEV_HAS_COLLISION_FIX 0x8000 /* device supports tx collision fix */
enum {
NvRegIrqStatus = 0x000,
@@ -266,9 +267,12 @@
#define NVREG_RNDSEED_FORCE3 0x7400
NvRegTxDeferral = 0xA0,
-#define NVREG_TX_DEFERRAL_DEFAULT 0x15050f
-#define NVREG_TX_DEFERRAL_RGMII_10_100 0x16070f
-#define NVREG_TX_DEFERRAL_RGMII_1000 0x14050f
+#define NVREG_TX_DEFERRAL_DEFAULT 0x15050f
+#define NVREG_TX_DEFERRAL_RGMII_10_100 0x16070f
+#define NVREG_TX_DEFERRAL_RGMII_1000 0x14050f
+#define NVREG_TX_DEFERRAL_RGMII_STRETCH_10 0x16190f
+#define NVREG_TX_DEFERRAL_RGMII_STRETCH_1000x16300f
+#define NVREG_TX_DEFERRAL_MII_STRETCH 0x152000
NvRegRxDeferral = 0xA4,
#define NVREG_RX_DEFERRAL_DEFAULT 0x16
NvRegMacAddrA = 0xA8,
@@ -2771,6 +2775,7 @@
int retval = 0;
u32 control_1000, status_1000, phyreg, pause_flags, txreg;
u32 txrxFlags = 0;
+ u32 phy_exp;
/* BMSR_LSTATUS is latched, read it twice:
* we want the current value.
@@ -2898,13 +2903,25 @@
phyreg |= PHY_1000;
writel(phyreg, base + NvRegPhyInterface);
+ phy_exp = mii_rw(dev, np->phyaddr, MII_EXPANSION, MII_READ) &
EXPANSION_NWAY; /* autoneg capable */
if (phyreg & PHY_RGMII) {
- if ((np->linkspeed & NVREG_LINKSPEED_MASK) ==
NVREG_LINKSPEED_1000)
+ if ((np->linkspeed & NVREG_LINKSPEED_MASK) ==
NVREG_LINKSPEED_1000) {
txreg = NVREG_TX_DEFERRAL_RGMII_1000;
- else
- txreg = NVREG_TX_DEFERRAL_RGMII_10_100;
+ } else {
+ if (!phy_exp && !np->duplex && (np->driver_data &
DEV_HAS_COLLISION_FIX)) {
+ if ((np->linkspeed & NVREG_LINKSPEED_MASK) ==
NVREG_LINKSPEED_10)
+ txreg =
NVREG_TX_DEFERRAL_RGMII_STRETCH_10;
+ else
+ txreg =
NVREG_TX_DEFERRAL_RGMII_STRETCH_100;
+ } else {
+ txreg = NVREG_TX_DEFERRAL_RGMII_10_100;
+ }
+ }
} else {
- txreg = NVREG_TX_DEFERRAL_DEFAULT;
+ if (!phy_exp && !np->duplex && (np->driver_data &
DEV_HAS_COLLISION_FIX))
+ txreg = NVREG_TX_DEFERRAL_MII_STRETCH;
+ else
+ txreg = NVREG_TX_DEFERRAL_DEFAULT;
}
writel(txreg, base + NvRegTxDeferral);
@@ -5603,51 +5620,51 @@
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_28),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR|DEV_HAS_COLLISION_FIX,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_29),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR|DEV_HAS_COLLISION_FIX,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_30),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HA
[PATCH 3/5] forcedeth: phy status fix
The driver needs to ack only the phy status bits that it is currently
handling and preserve the other bits for the other handlers. For
example, when reading/writing from the phy, it should not clear the link
change interrupt bit. This will cause a missing link change interrupt.
Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>
--- old/drivers/net/forcedeth.c 2008-01-15 18:38:52.0 -0500
+++ new/drivers/net/forcedeth.c 2008-01-15 19:27:55.0 -0500
@@ -327,8 +327,8 @@
NvRegMIIStatus = 0x180,
#define NVREG_MIISTAT_ERROR0x0001
#define NVREG_MIISTAT_LINKCHANGE 0x0008
-#define NVREG_MIISTAT_MASK 0x000f
-#define NVREG_MIISTAT_MASK20x000f
+#define NVREG_MIISTAT_MASK_RW 0x0007
+#define NVREG_MIISTAT_MASK_ALL 0x000f
NvRegMIIMask = 0x184,
#define NVREG_MII_LINKCHANGE 0x0008
@@ -1068,7 +1068,7 @@
u32 reg;
int retval;
- writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus);
+ writel(NVREG_MIISTAT_MASK_RW, base + NvRegMIIStatus);
reg = readl(base + NvRegMIIControl);
if (reg & NVREG_MIICTL_INUSE) {
@@ -3012,7 +3012,7 @@
u32 miistat;
miistat = readl(base + NvRegMIIStatus);
- writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus);
+ writel(NVREG_MIISTAT_LINKCHANGE, base + NvRegMIIStatus);
dprintk(KERN_INFO "%s: link change irq, status 0x%x.\n", dev->name,
miistat);
if (miistat & (NVREG_MIISTAT_LINKCHANGE))
@@ -4887,7 +4887,7 @@
writel(0, base + NvRegMIIMask);
writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus);
- writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus);
+ writel(NVREG_MIISTAT_MASK_ALL, base + NvRegMIIStatus);
writel(NVREG_MISC1_FORCE | NVREG_MISC1_HD, base + NvRegMisc1);
writel(readl(base + NvRegTransmitterStatus), base +
NvRegTransmitterStatus);
@@ -4925,7 +4925,7 @@
nv_disable_hw_interrupts(dev, np->irqmask);
pci_push(base);
- writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus);
+ writel(NVREG_MIISTAT_MASK_ALL, base + NvRegMIIStatus);
writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus);
pci_push(base);
@@ -4948,7 +4948,7 @@
{
u32 miistat;
miistat = readl(base + NvRegMIIStatus);
- writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus);
+ writel(NVREG_MIISTAT_MASK_ALL, base + NvRegMIIStatus);
dprintk(KERN_INFO "startup: got 0x%08x.\n", miistat);
}
/* set linkspeed to invalid value, thus force nv_update_linkspeed
@@ -5320,7 +5320,7 @@
phystate &= ~NVREG_ADAPTCTL_RUNNING;
writel(phystate, base + NvRegAdapterControl);
}
- writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus);
+ writel(NVREG_MIISTAT_MASK_ALL, base + NvRegMIIStatus);
if (id->driver_data & DEV_HAS_MGMT_UNIT) {
/* management unit running on the mac? */
[PATCH 1/5] forcedeth: restart tx/rx
This patch fixes the issue where the transmitter and receiver must be
restarted when applying new changes to certain registers.
Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>
--- old/drivers/net/forcedeth.c 2008-01-15 17:41:00.0 -0500
+++ new/drivers/net/forcedeth.c 2008-01-15 17:41:02.0 -0500
@@ -624,6 +624,9 @@
#define NV_MSI_X_VECTOR_TX0x1
#define NV_MSI_X_VECTOR_OTHER 0x2
+#define NV_RESTART_TX 0x1
+#define NV_RESTART_RX 0x2
+
/* statistics */
struct nv_ethtool_str {
char name[ETH_GSTRING_LEN];
@@ -2767,6 +2770,7 @@
int mii_status;
int retval = 0;
u32 control_1000, status_1000, phyreg, pause_flags, txreg;
+ u32 txrxFlags = 0;
/* BMSR_LSTATUS is latched, read it twice:
* we want the current value.
@@ -2862,6 +2866,16 @@
np->duplex = newdup;
np->linkspeed = newls;
+ /* The transmitter and receiver must be restarted for safe update */
+ if (readl(base + NvRegTransmitterControl) & NVREG_XMITCTL_START) {
+ txrxFlags |= NV_RESTART_TX;
+ nv_stop_tx(dev);
+ }
+ if (readl(base + NvRegReceiverControl) & NVREG_RCVCTL_START) {
+ txrxFlags |= NV_RESTART_RX;
+ nv_stop_rx(dev);
+ }
+
if (np->gigabit == PHY_GIGABIT) {
phyreg = readl(base + NvRegRandomSeed);
phyreg &= ~(0x3FF00);
@@ -2950,6 +2964,11 @@
}
nv_update_pause(dev, pause_flags);
+ if (txrxFlags & NV_RESTART_TX)
+ nv_start_tx(dev);
+ if (txrxFlags & NV_RESTART_RX)
+ nv_start_rx(dev);
+
return retval;
}
Re: [PATCH] Add IPv6 support to TCP SYN cookies
Hi Andi, Alan, I've run extensive tests with/without syn cookies recently. On Tue, Feb 05, 2008 at 05:39:12PM +0100, Andi Kleen wrote: > On Tue, Feb 05, 2008 at 03:42:13PM +, Alan Cox wrote: > > > Syncookies are discouraged these days. They disable too many > > > valuable TCP features (window scaling, SACK) and even without them > > > the kernel is usually strong enough to defend against syn floods > > > and systems have much more memory than they used to be. > > > > Somewhat untrue. Network speeds have risen dramatically, the number of > > With strong I meant Linux has much better algorithms to handle the standard > syn queue (syncookies was originally added when it had only dumb head drop) > and there are minisocks which also require significantly less overhead > to manage than full sockets (less memory etc.) That's true, but not enough, see below. > When I wrote syncookies originally that all was not true. > > > appliances running Linux that are not PC class means memory has fallen > > not risen and CPU has been pretty level. > > > > > So I don't think it makes much sense to add more code to it, sorry. > > > > I think it makes a lot of sense > > I have my doubts. It would be probably better to recheck everything > and then remove syncookies. > > Also your sub PC class appliances rarely run LISTEN servers anyways > that are open to the world. In my tests, I discovered that in fact SYN cookies more benefit high end machines than low-end ones. Let me explain. I noticed that computing the cookie consumes a lot of CPU, which is a real problem on low-end machines. But on the other end, it helps the system continue to respond when otherwise it would not. My tests on an AMD LX800 with max_syn_backlog at 63000 on an HTTP reverse proxy consisted in injecting 250 hits/s of legitimate traffic with 8000 SYN/s of noise. Without SYN cookies, the average response time was about 1.5 second and unstable (due to retransmits), and the CPU was set to 60%. With SYN cookies enabled, the response time dropped to 12-15ms only, but CPU usage jumped to 70%. The difference appears at a higher legitimate traffic rate. At 500 hits/s + 7800 SYN/s, the CPU is just saturated with correct response time (SYN backlog almost full but never full), and the performance slightly goes down with SYN cookies enabled, inducing a drop of the hit rate due to the increased CPU consumption. Till there, one would conclude that SYN cookies are bad. BUT! this was with tcp_synack_retries = 1, which is the optimal situation without SYN cookies under an attack and which is pretty bad for normal usage. The real problem without SYN cookies is that you are forced to support a huge SYN backlog (eg: 2 million entries to sustain 100 Mbps of SYN). And what happens with a large backlog ? You send a lot of retries for each SYN. 5 by default, meaning 6 SYN-ACKs for 1 SYN. Thus, you become a SYN amplifier and the guy in front of you just has to send you 20 Mbps of traffic for you to saturate your 100 Mbps uplink. Also, sending all those SYN-ACKs takes a huge amount of CPU time. With tcp_synack_retries at 0, my machine received 26600 SYN/s, and returned 26600 SYN-ACK/s at 100% CPU. With tcp_synack_retries set to 4, it could only accept 12900 SYN/s, replying with 51200 SYN-ACK/s. So the input load was halfed and the output was doubled. I did not bother going higher. The only solution against this is then to reduce tcp_synack_retries to very low values (0 ideally, to match SYN cookies behaviour), but in this case, you degrade normal traffic 100% of the time, while SYN cookies would only trigger while you're already under attack. My conclusions after those tests was to set tcp_synack_retries to a reasonable value (1 to 3), and set the backlog to the number of half-open sessions your machine can accumulate under a SYN attack without collapsing. You then enable SYN cookies, and they will only trigger when you know that your machine will not be able to sustain the increased load. This solution permits you to accept normal connections when not under attack, with an acceptable number of retransmits and with TCP options working well. Under a moderate attack, the large backlog will still help you accept legitimate connections with all comfort (sack, wscale, ...). Under a massive attack, you will not send more than tcp_synack_retries*backlog packets per tcp_synack_retries period, thus limiting the outbound traffic, plus 1 SYN-ACK per incoming SYN, legitimate or not. At this stage, if your users have a castrated TCP stack in front of them, that's not a problem because you know that otherwise they would not even have been able to connect. So in this regard, SYN cookies are really needed. Last, I've read on DJB's page that SYN cookies do not break TCP beahaviour. Yes they do. If the client waits for the server to talk first, you'd better not lose the first ACK from the client because it will not get retransmitted, and the client will see an ESTABLISHED
Re: [PATCH] Add IPv6 support to TCP SYN cookies
> >So I don't think it makes much sense to add more code to it, sorry. > > Distributions should then probably deactivate it by default. > SUSE 10.3 for example still has it enabled on default installs. Even though I work the loyal opposition to SuSE I'd say SuSE 10.3 is correct in having it enabled in the build. Alan -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
> How does syncookies prevent windows from growing? Enabling them doesn't. > Most (if not all) distributions have them enabled and window growing > works just fine. Actually I do not see any reason why connection > establishment handshake should prevent any run-time operations at all, > even if it was setup during handshake. Syncookies are only triggered if the system is under a load where it would begin to lose connections otherwise. So they merely turn a DoS into a working if slightly slower setup (and > 64K windows don't matter for most normal users, especially on mobile devices). -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Tue, Feb 05, 2008 at 09:11:06PM +0100, Andi Kleen wrote: > > The problem is that any reasonably recent PC can generate enough > > forged SYN packets to overwhelm reasonable SYN queues on a much more > > powerful server. > > Have you actually seen this with a recent kernel in the wild or are > you just talking theoretically? > > Linux uses some heuristics to manage the syn queue that should > still ensure reasonable service even without cookies under attack. > Also SYN-RECV sockets are stored in a special data structure optimized > to use minimal resources. > > It is far from the classical head drop method that was so vunerable > to syn flooding. I work at a hosting company and we see these kinds of issues in the real world fairly frequently. I would guess maybe a monthly basis. The servers where we have seen this are typically running RHEL 4 or 5 kernels, so I can't really speak to how recent the kernel is in this specific term. If I can find a box that we could temporary get a kernel.org kernel on, I'll see if I can get a real comparison together. We have collected a few of the more effective attack tools that have been left on compromised systems, so it wouldn't be too difficult to get some numbers. -- Ross Vandegrift [EMAIL PROTECTED] "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
> Jeff, any chance this can get into .25 soon? I have another patch > queued up behind this one that requires it, and I don't see it in any > of your trees or branches. > > Or, if you aren't opposed, I can take it through Paul's tree with your > Ack. In case my "it's fine" wasn't enough, here's an: Acked-by: Benjamin Herrenschmidt <[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] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
On Thu, 31 Jan 2008 10:14:58 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-01-30 at 07:16 +0100, Stefan Roese wrote: > > On Wednesday 16 January 2008, Josh Boyer wrote: > > > On Wed, 16 Jan 2008 20:53:59 +1100 > > > > > > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > > On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote: > > > > > With the removal the the "rgmii-interface" device_type property from > > > > > the dts files, the newemac driver needs an update to only rely on > > > > > compatible property. > > > > > > > > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > > > > > > > I need to test if it works on CAB, can't change the DT on those. I'll > > > > let you know tomorrow. > > > > > > This should be fine on CAB. The rgmii node has: > > > > > > compatible = "ibm,rgmii-axon", "ibm,rgmii" > > > > > > so the match should still catch on the latter. > > > > How about this patch? Ben, if you think this is ok then we should make sure > > that it goes in in this merge-window, since the other dts patch relies on > > it. > > It's fine. Jeff, any chance this can get into .25 soon? I have another patch queued up behind this one that requires it, and I don't see it in any of your trees or branches. Or, if you aren't opposed, I can take it through Paul's tree with your Ack. josh -- To unsubscribe from this list: send 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] ipvs: Make wrr "no available servers" error message rate-limited
No available servers is more an error message than something informational. It
should also be rate-limited, else we're going to flood our logs on a busy
director, if all real servers are out of order with a weight of zero.
Signed-off-by: Sven Wegener <[EMAIL PROTECTED]>
---
Actually, do we need this message at all? The wrr scheduler is the only one
printing an error message in such a case.
net/ipv4/ipvs/ip_vs_wrr.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ipvs/ip_vs_wrr.c b/net/ipv4/ipvs/ip_vs_wrr.c
index 749fa04..85c680a 100644
--- a/net/ipv4/ipvs/ip_vs_wrr.c
+++ b/net/ipv4/ipvs/ip_vs_wrr.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
@@ -169,7 +170,7 @@ ip_vs_wrr_schedule(struct ip_vs_service *svc, const struct
sk_buff *skb)
*/
if (mark->cw == 0) {
mark->cl = &svc->destinations;
- IP_VS_INFO("ip_vs_wrr_schedule(): "
+ IP_VS_ERR_RL("ip_vs_wrr_schedule(): "
"no available servers\n");
dest = NULL;
goto out;
--
1.5.3.7
--
To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Tue, Feb 05, 2008 at 11:39:11PM +0300, Evgeniy Polyakov wrote: > On Tue, Feb 05, 2008 at 09:02:11PM +0100, Andi Kleen ([EMAIL PROTECTED]) > wrote: > > On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote: > > > > Syncookies are discouraged these days. They disable too many > > > > valuable TCP features (window scaling, SACK) and even without them > > > > the kernel is usually strong enough to defend against syn floods > > > > and systems have much more memory than they used to be. > > > > > > > > So I don't think it makes much sense to add more code to it, sorry. > > How does syncookies prevent windows from growing? Syncookies do not allow window scaling so you can't have any windows >64k > Most (if not all) distributions have them enabled and window growing > works just fine. Actually I do not see any reason why connection > establishment handshake should prevent any run-time operations at all, > even if it was setup during handshake. TCP only uses options negotiated during the hand shake and syncookies is incapable to do this. -Andi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add IPv6 support to TCP SYN cookies
On Tue, Feb 05, 2008 at 09:02:11PM +0100, Andi Kleen ([EMAIL PROTECTED]) wrote: > On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote: > > > Syncookies are discouraged these days. They disable too many > > > valuable TCP features (window scaling, SACK) and even without them > > > the kernel is usually strong enough to defend against syn floods > > > and systems have much more memory than they used to be. > > > > > > So I don't think it makes much sense to add more code to it, sorry. How does syncookies prevent windows from growing? Most (if not all) distributions have them enabled and window growing works just fine. Actually I do not see any reason why connection establishment handshake should prevent any run-time operations at all, even if it was setup during handshake. -- 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] [IPV4]: Fix compiler error with CONFIG_PROC_FS=n
Johann Felix Soden wrote: > From: Johann Felix Soden <[EMAIL PROTECTED]> > > Handle CONFIG_PROC_FS=n in net/ipv4/fib_frontend.c because: > > net/ipv4/fib_frontend.c: In function 'fib_net_init': > net/ipv4/fib_frontend.c:1032: error: implicit declaration of function > 'fib_proc_init' > net/ipv4/fib_frontend.c: In function 'fib_net_exit': > net/ipv4/fib_frontend.c:1047: error: implicit declaration of function > 'fib_proc_exit' > > Signed-off-by: Johann Felix Soden <[EMAIL PROTECTED]> Fix from Li Zefan is already commited. (cc8274f50f2ad9a97a837451f63a0a3e65f7f490) -- To unsubscribe from this list: send 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/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
Jeff Garzik wrote: Indeed, that would work too... though we would need to put out a call for Gigabyte testers during 2.6.25-rc. It is an entirely reasonable scenario for NVIDIA to deploy a fix to Gigabyte, which would then return us to the same scenario we have today: some work and some don't. That's my main reason for leaning more conservative here. If they deploy a fix, then the Gigabyte prefix will show up as a prefix, rather than a suffix - no problem. That's actually the reason to deploy that solution rather than relying on DMI. -hpa -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Feb 5 2008 16:55, Andi Kleen wrote: >On Mon, Feb 04, 2008 at 03:01:01PM -0800, Glenn Griffin wrote: >> Add IPv6 support to TCP SYN cookies. This is written and tested against >> 2.6.24, and applies cleanly to linus' current HEAD (d2fc0b). Unfortunately >> linus' HEAD breaks my sky2 card at the moment, so I'm unable to test against >> that. I see no reason why it would be affected though. Comments/suggestions >> are welcome. > >Syncookies are discouraged these days. They disable too many >valuable TCP features (window scaling, SACK) and even without them >the kernel is usually strong enough to defend against syn floods >and systems have much more memory than they used to be. > >So I don't think it makes much sense to add more code to it, sorry. Distributions should then probably deactivate it by default. SUSE 10.3 for example still has it enabled on default installs. -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote: > > Syncookies are discouraged these days. They disable too many > > valuable TCP features (window scaling, SACK) and even without them > > the kernel is usually strong enough to defend against syn floods > > and systems have much more memory than they used to be. > > > > So I don't think it makes much sense to add more code to it, sorry. > > As you say the kernel is usually strong enough to defend against syn flood > attacks, but what about the situations where it isn't? As valuable as the TCP > features are I would give them up if it means I'm able to connect to my sshd > port when I otherwise would be unable to. While increased synq sizes, better > dropping algorithms, and minisocks are a great way to mitigate the attacks and > in most cases are enough, there are situations where syncookies are nice. > > Regardless, I would say as long as ipv4 has syncookie support it will > accurately be viewed as a deficiency of ipv6 if it lacks support. So perhaps > the discussion should be we whether all the other defenses are enough to > warrant the removal of syncookie support from ipv4. That topic may bring in > more opinions. Yes, syncookies, while presenting some tradeoffs, are a necessary tool to have. The problem is that any reasonably recent PC can generate enough forged SYN packets to overwhelm reasonable SYN queues on a much more powerful server. Imagine a server with a few hundres Apache virtual hosts. One website pisses off the wrong person and it impacts service for everyone. While syncookies isn't always enough, enabling it often helps make the server more resiliant during attacks. And for web service, most of the connections are short-lived connections for small pieces of data - so I'm not really convinced that window scaling and selective ACK are all that important. -- Ross Vandegrift [EMAIL PROTECTED] "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
> The problem is that any reasonably recent PC can generate enough > forged SYN packets to overwhelm reasonable SYN queues on a much more > powerful server. Have you actually seen this with a recent kernel in the wild or are you just talking theoretically? Linux uses some heuristics to manage the syn queue that should still ensure reasonable service even without cookies under attack. Also SYN-RECV sockets are stored in a special data structure optimized to use minimal resources. It is far from the classical head drop method that was so vunerable to syn flooding. -Andi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
Jeff Garzik wrote: Ayaz Abdulla wrote: Andrew Morton wrote: On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> NAK - this fixes one set of users, and breaks a working set of users. Need to add DMI check for the specific motherboard (dmi_check_system), and flip flag according to success/failure of that check. OK :) I added the above to the changelog for next time. You guys can hide, but this patch isn't going away! I believe Michael determined that a newer BIOS fixes this issue. That's a solution that makes vendors happy... but we still have to deal with it in Linux. There are plenty of the old broken BIOS still out in the field... Jeff Michael, can you provide which BIOS version had this issue and which version fixed the issue? --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote: > > Syncookies are discouraged these days. They disable too many > > valuable TCP features (window scaling, SACK) and even without them > > the kernel is usually strong enough to defend against syn floods > > and systems have much more memory than they used to be. > > > > So I don't think it makes much sense to add more code to it, sorry. > > As you say the kernel is usually strong enough to defend against syn flood > attacks, but what about the situations where it isn't? As valuable as the TCP > features are I would give them up if it means I'm able to connect to my sshd > port when I otherwise would be unable to. While increased synq sizes, better > dropping algorithms, and minisocks are a great way to mitigate the attacks and > in most cases are enough, there are situations where syncookies are nice. Have you seen such a case in practice with a modern kernel? They also cause problems unfortunately; e.g. there is no real flow control for connections anymore in the non DOS case. > Regardless, I would say as long as ipv4 has syncookie support it will > accurately be viewed as a deficiency of ipv6 if it lacks support. So perhaps > the discussion should be we whether all the other defenses are enough to > warrant the removal of syncookie support from ipv4. That topic may bring in > more opinions. That is essentially what I and Alan were discussing. > > > Besides you should really move it to the ipv6 module, right now the code > > would be always compiled in even for ipv4 only kernels. > > That is correct. I will gladly move it into it's own section within > net/ipv6/. > Do you have any problem using the same CONFIG and sysctl variables as the ipv4 > implementation? No. -Andi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
Ayaz Abdulla wrote: Andrew Morton wrote: On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> NAK - this fixes one set of users, and breaks a working set of users. Need to add DMI check for the specific motherboard (dmi_check_system), and flip flag according to success/failure of that check. OK :) I added the above to the changelog for next time. You guys can hide, but this patch isn't going away! I believe Michael determined that a newer BIOS fixes this issue. That's a solution that makes vendors happy... but we still have to deal with it in Linux. There are plenty of the old broken BIOS still out in the field... Jeff -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
Andrew Morton wrote: On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> NAK - this fixes one set of users, and breaks a working set of users. Need to add DMI check for the specific motherboard (dmi_check_system), and flip flag according to success/failure of that check. OK :) I added the above to the changelog for next time. You guys can hide, but this patch isn't going away! I believe Michael determined that a newer BIOS fixes this issue. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- To unsubscribe from this list: send 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/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
Andrew Morton wrote:
On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote:
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
NAK - this fixes one set of users, and breaks a working set of users.
Need to add DMI check for the specific motherboard (dmi_check_system),
and flip flag according to success/failure of that check.
OK :) I added the above to the changelog for next time.
You guys can hide, but this patch isn't going away!
In the original thread, I even posted a
fill-in-the-blanks-with-the-motherboard-name patch. I'll attach it again...
Jeff
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 3634223..eab85fa 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -147,6 +147,7 @@
#include
#include
#include
+#include
#include
#include
@@ -4992,6 +4993,26 @@ static int nv_close(struct net_device *dev)
return 0;
}
+static int nv_reversed_macaddr(void)
+{
+ static const struct dmi_system_id sysids[] = {
+ {
+ .ident = "",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ""),
+ DMI_MATCH(DMI_PRODUCT_NAME, ""),
+ },
+ },
+
+ { } /* terminate list */
+ };
+
+ if (dmi_check_system(sysids))
+ return 1;
+
+ return 0;
+}
+
static int __devinit nv_probe(struct pci_dev *pci_dev, const struct
pci_device_id *id)
{
struct net_device *dev;
@@ -5187,8 +5208,9 @@ static int __devinit nv_probe(struct pci_dev *pci_dev,
const struct pci_device_i
/* check the workaround bit for correct mac address order */
txreg = readl(base + NvRegTransmitPoll);
- if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
- (id->driver_data & DEV_HAS_CORRECT_MACADDR)) {
+ if (((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id->driver_data & DEV_HAS_CORRECT_MACADDR))) &&
+ (!nv_reversed_macaddr())) {
/* mac address is already in correct order */
dev->dev_addr[0] = (np->orig_mac[0] >> 0) & 0xff;
dev->dev_addr[1] = (np->orig_mac[0] >> 8) & 0xff;
[patch 2.6.24-git] net/enc28j60: oops fix, low power mode
From: David Brownell <[EMAIL PROTECTED]>
Prevent unaligned packet oops on enc28j60 packet RX.
Keep enc28j60 chips in low-power mode when they're not in use.
At typically 120 mA, these chips run hot even when idle. Low
power mode cuts that power usage by a factor of around 100.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/net/enc28j60.c | 54 +
1 files changed, 50 insertions(+), 4 deletions(-)
--- avr.orig/drivers/net/enc28j60.c 2008-02-05 10:04:22.0 -0800
+++ avr/drivers/net/enc28j60.c 2008-02-05 10:50:50.0 -0800
@@ -594,6 +594,43 @@ static void nolock_txfifo_init(struct en
nolock_regw_write(priv, ETXNDL, end);
}
+/*
+ * Low power mode shrinks power consumption about 100x, so we'd like
+ * the chip to be in that mode whenever it's inactive.
+ */
+static void enc28j60_lowpower(struct enc28j60_net *priv, bool is_low)
+{
+ int tmp;
+
+ dev_dbg(&priv->spi->dev, "%s power...\n", is_low ? "low" : "high");
+
+ mutex_lock(&priv->lock);
+ if (is_low) {
+ nolock_reg_bfclr(priv, ECON1, ECON1_RXEN);
+ for (;;) {
+ tmp = nolock_regb_read(priv, ESTAT);
+ if (!(tmp & ESTAT_RXBUSY))
+ break;
+ }
+ for (;;) {
+ tmp = nolock_regb_read(priv, ECON1);
+ if (!(tmp & ECON1_TXRTS))
+ break;
+ }
+ /* ECON2_VRPS was set during initialization */
+ nolock_reg_bfset(priv, ECON2, ECON2_PWRSV);
+ } else {
+ nolock_reg_bfclr(priv, ECON2, ECON2_PWRSV);
+ for (;;) {
+ tmp = nolock_regb_read(priv, ESTAT);
+ if (tmp & ESTAT_CLKRDY)
+ break;
+ }
+ /* caller sets ECON1_RXEN */
+ }
+ mutex_unlock(&priv->lock);
+}
+
static int enc28j60_hw_init(struct enc28j60_net *priv)
{
u8 reg;
@@ -612,8 +649,8 @@ static int enc28j60_hw_init(struct enc28
priv->tx_retry_count = 0;
priv->max_pk_counter = 0;
priv->rxfilter = RXFILTER_NORMAL;
- /* enable address auto increment */
- nolock_regb_write(priv, ECON2, ECON2_AUTOINC);
+ /* enable address auto increment and voltage regulator powersave */
+ nolock_regb_write(priv, ECON2, ECON2_AUTOINC | ECON2_VRPS);
nolock_rxfifo_init(priv, RXSTART_INIT, RXEND_INIT);
nolock_txfifo_init(priv, TXSTART_INIT, TXEND_INIT);
@@ -690,7 +727,9 @@ static int enc28j60_hw_init(struct enc28
static void enc28j60_hw_enable(struct enc28j60_net *priv)
{
- /* enable interrutps */
+ enc28j60_lowpower(priv, false);
+
+ /* enable interrupts */
if (netif_msg_hw(priv))
printk(KERN_DEBUG DRV_NAME ": %s() enabling interrupts.\n",
__FUNCTION__);
@@ -717,6 +756,8 @@ static void enc28j60_hw_disable(struct e
nolock_reg_bfclr(priv, ECON1, ECON1_RXEN);
priv->hw_enable = false;
mutex_unlock(&priv->lock);
+
+ enc28j60_lowpower(priv, true);
}
static int
@@ -734,6 +775,8 @@ enc28j60_setlink(struct net_device *ndev
"hw_reset() failed\n");
ret = -EINVAL;
}
+ enc28j60_lowpower(priv, true);
+
} else {
if (netif_msg_link(priv))
dev_warn(&ndev->dev,
@@ -900,7 +943,7 @@ static void enc28j60_hw_rx(struct net_de
if (RSV_GETBIT(rxstat, RSV_LENCHECKERR))
ndev->stats.rx_frame_errors++;
} else {
- skb = dev_alloc_skb(len);
+ skb = dev_alloc_skb(len + NET_IP_ALIGN);
if (!skb) {
if (netif_msg_rx_err(priv))
dev_err(&ndev->dev,
@@ -908,6 +951,7 @@ static void enc28j60_hw_rx(struct net_de
ndev->stats.rx_dropped++;
} else {
skb->dev = ndev;
+ skb_reserve(skb, NET_IP_ALIGN);
/* copy the packet from the receive buffer */
enc28j60_mem_read(priv, priv->next_pk_ptr + sizeof(rsv),
len, skb_put(skb, len));
@@ -1536,6 +1580,8 @@ static int __devinit enc28j60_probe(stru
dev->watchdog_timeo = TX_TIMEOUT;
SET_ETHTOOL_OPS(dev, &enc28j60_ethtool_ops);
+ enc28j60_lowpower(priv, true);
+
ret = register_netdev(dev);
if (ret) {
if (netif_msg_probe(priv))
--
To unsubscribe from this list: send 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/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > NAK - this fixes one set of users, and breaks a working set of users. > > Need to add DMI check for the specific motherboard (dmi_check_system), > and flip flag according to success/failure of that check. OK :) I added the above to the changelog for next time. You guys can hide, but this patch isn't going away! -- To unsubscribe from this list: send 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] [IPV4]: Fix compiler error with CONFIG_PROC_FS=n
From: Johann Felix Soden <[EMAIL PROTECTED]>
Handle CONFIG_PROC_FS=n in net/ipv4/fib_frontend.c because:
net/ipv4/fib_frontend.c: In function 'fib_net_init':
net/ipv4/fib_frontend.c:1032: error: implicit declaration of function
'fib_proc_init'
net/ipv4/fib_frontend.c: In function 'fib_net_exit':
net/ipv4/fib_frontend.c:1047: error: implicit declaration of function
'fib_proc_exit'
Signed-off-by: Johann Felix Soden <[EMAIL PROTECTED]>
---
net/ipv4/fib_frontend.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 86ff271..581d588 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1029,9 +1029,12 @@ static int __net_init fib_net_init(struct net *net)
error = nl_fib_lookup_init(net);
if (error < 0)
goto out_nlfl;
+#ifdef CONFIG_PROC_FS
error = fib_proc_init(net);
if (error < 0)
goto out_proc;
+#endif
+
out:
return error;
@@ -1044,7 +1047,9 @@ out_nlfl:
static void __net_exit fib_net_exit(struct net *net)
{
+#ifdef CONFIG_PROC_FS
fib_proc_exit(net);
+#endif
nl_fib_lookup_exit(net);
ip_fib_net_exit(net);
}
--
1.5.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
H. Peter Anvin wrote: Jeff Garzik wrote: Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> NAK - this fixes one set of users, and breaks a working set of users. Need to add DMI check for the specific motherboard (dmi_check_system), and flip flag according to success/failure of that check. Either that, or detect the Gigabyte prefix used as a suffix, since they seem to be the source of this particular f*ckup. Indeed, that would work too... though we would need to put out a call for Gigabyte testers during 2.6.25-rc. It is an entirely reasonable scenario for NVIDIA to deploy a fix to Gigabyte, which would then return us to the same scenario we have today: some work and some don't. That's my main reason for leaning more conservative here. Jeff -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
Jeff Garzik wrote: Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> NAK - this fixes one set of users, and breaks a working set of users. Need to add DMI check for the specific motherboard (dmi_check_system), and flip flag according to success/failure of that check. Either that, or detect the Gigabyte prefix used as a suffix, since they seem to be the source of this particular f*ckup. -hpa -- To unsubscribe from this list: send 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] xircom_cb should return NETDEV_TX_BUSY when there are no descriptors available
Erik Mouw wrote: Hi, Changes in other networking paths uncovered a bug in the xircom_cb driver which made the kernel spew lots of the following error messages: BUG eth1 code -5 qlen 0 It turned out that the driver returned -EIO when there was no descriptor available for sending packets. It should return NETDEV_TX_BUSY instead. This was discussed on the netdev list before, see http://thread.gmane.org/gmane.linux.network/84603 . Signed-off-by: Erik Mouw <[EMAIL PROTECTED]> diff --git a/drivers/net/tulip/xircom_cb.c b/drivers/net/tulip/xircom_cb.c index 8fc7274..6b93d01 100644 --- a/drivers/net/tulip/xircom_cb.c +++ b/drivers/net/tulip/xircom_cb.c @@ -441,7 +441,7 @@ static int xircom_start_xmit(struct sk_buff *skb, struct net_device *dev) spin_unlock_irqrestore(&card->lock,flags); trigger_transmit(card); - return -EIO; + return NETDEV_TX_BUSY; } applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] ixgbe: add real-time traffic counters
Auke Kok wrote: From: Ayyappan Veeraiyan <[EMAIL PROTECTED]> Just like our other drivers before we can switch ixgbe to provide real-time packet/byte counters to the stack easily. Signed-off-by: Ayyappan Veeraiyan <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/ixgbe/ixgbe_main.c | 15 +++ 1 files changed, 11 insertions(+), 4 deletions(-) applied 1-8 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Generic HDLC - fix kernel panic
Krzysztof Halasa wrote: Fixes kernel panic in Frame Relay mode Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> applied 1-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] [POWERPC] iSeries: fix section mismatch in iseries_veth
Stephen Rothwell wrote:
WARNING: vmlinux.o(.text+0x25dca0): Section mismatch in reference from the
function .veth_probe() to the function .init.text:.veth_probe_one()
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/net/iseries_veth.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Jeff, can this go in through the powerpc tree?
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index 419861c..58d3bb6 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -1020,7 +1020,7 @@ static const struct ethtool_ops ops = {
.get_link = veth_get_link,
};
-static struct net_device * __init veth_probe_one(int vlan,
+static struct net_device *veth_probe_one(int vlan,
struct vio_dev *vio_dev)
{
it's trivial enough to not matter, and faster to just... applied
(if you'll pardon the bad grammar)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/4] mv643xx_eth: fix byte order when checksum offload is enabled
[EMAIL PROTECTED] wrote: From: Byron Bradley <[EMAIL PROTECTED]> The Marvell Orion system on chips have an integrated mv643xx MAC. On these little endian ARM devices mv643xx will oops when checksum offload is enabled. Swapping the byte order of the protocol and checksum solves this problem. Signed-off-by: Byron Bradley <[EMAIL PROTECTED]> Cc: Dale Farnsworth <[EMAIL PROTECTED]> Cc: Manish Lachwani <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Cc: Al Viro <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/mv643xx_eth.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) applied 3-4 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sky2: fix for Yukon FE (regression in 2.6.25)
Stephen Hemminger wrote: The Yukon FE chip has a ram buffer therefore it needs the alignment restriction and hang check workarounds. Therefore: * Autodetect the prescence/absence of ram buffer * Rename the flag value to reflect this * Use it consistently (ie don't reread register) Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add IPv6 support to TCP SYN cookies
> Syncookies are discouraged these days. They disable too many > valuable TCP features (window scaling, SACK) and even without them > the kernel is usually strong enough to defend against syn floods > and systems have much more memory than they used to be. > > So I don't think it makes much sense to add more code to it, sorry. As you say the kernel is usually strong enough to defend against syn flood attacks, but what about the situations where it isn't? As valuable as the TCP features are I would give them up if it means I'm able to connect to my sshd port when I otherwise would be unable to. While increased synq sizes, better dropping algorithms, and minisocks are a great way to mitigate the attacks and in most cases are enough, there are situations where syncookies are nice. Regardless, I would say as long as ipv4 has syncookie support it will accurately be viewed as a deficiency of ipv6 if it lacks support. So perhaps the discussion should be we whether all the other defenses are enough to warrant the removal of syncookie support from ipv4. That topic may bring in more opinions. > Besides you should really move it to the ipv6 module, right now the code > would be always compiled in even for ipv4 only kernels. That is correct. I will gladly move it into it's own section within net/ipv6/. Do you have any problem using the same CONFIG and sysctl variables as the ipv4 implementation? Thanks --Glenn -- To unsubscribe from this list: send 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] [PPPOL2TP] Label unused warning when CONFIG_PROC_FS is not set.
Rami Rosen wrote: Hi, When CONFIG_PROC_FS is not set and CONFIG_PPPOL2TP is set, we have the following warning in build: drivers/net/pppol2tp.c: In function 'pppol2tp_init': drivers/net/pppol2tp.c:2472: warning: label 'out_unregister_pppox_proto' defined but not used This patches fixes this warning by adding appropriate #ifdef. Regards, Rami Rosen Signed-off-by: Rami Rosen <[EMAIL PROTECTED]> David or Paul, wanna pick this up? -- To unsubscribe from this list: send 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/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
[EMAIL PROTECTED] wrote: From: Michael Pyne <[EMAIL PROTECTED]> Partially revert a change to mac address detection introduced to the forcedeth driver. The change was intended to correct mac address detection for newer nVidia chipsets where the mac address was stored in reverse order. One of those chipsets appears to still have the mac address in reverse order (or at least, it does on my system). The change that broke mac address detection for my card was commit ef756b3e56c68a4d76d9d7b9a73fa8f4f739180f "forcedeth: mac address correct" My network card is an nVidia built-in Ethernet card, output from lspci as follows (with text and numeric ids): $ lspci | grep Ethernet 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) $ lspci -n | grep 07.0 00:07.0 0680: 10de:03ef (rev a2) The vendor id is, of course, nVidia. The device id corresponds to the NVIDIA_NVENET_19 entry. The included patch fixes the MAC address detection on my system. Interestingly, the MAC address appears to be in the range reserved for my motherboard manufacturer (Gigabyte) and not nVidia. Signed-off-by: Michael J. Pyne <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Cc: Ayaz Abdulla <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> On Wed, 21 Nov 2007 15:34:52 -0800 "Ayaz Abdulla" <[EMAIL PROTECTED]> wrote: The solution is to get the OEM to update their BIOS (instead of integrating this patch) since the MCP61 specs indicate that the MAC Address should be in correct order from BIOS. By changing the feature DEV_HAS_CORRECT_MACADDR to all MCP61 boards, it could cause it to break on other OEM systems who have implemented it correctly. Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> NAK - this fixes one set of users, and breaks a working set of users. Need to add DMI check for the specific motherboard (dmi_check_system), and flip flag according to success/failure of that check. 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: [e1000][net-2.6 tree] Regression: driver doesn't detect card on my node.
On Tuesday 05 February 2008 09:24:17 am Kok, Auke wrote: > > [Added Ingo, Thomas, Justin who signed off on the patch/tested it] > > Pavel Emelyanov wrote: > > The commit > > > > 093af8d7f0ba3c6be1485973508584ef081e9f93 > > x86_32: trim memory by updating e820 > > > > broke my e1000 card: on loading driver says that > > > > e1000: probe of :04:03.0 failed with error -5 > > > > and the interface doesn't appear. > > > > With this commit reset everything is OK. > > > > lspci output: > > 04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet > > Controller (rev 05) > > lspci -n output: > > 04:03.0 Class 0200: 8086:1076 (rev 05) > > > > My colleague Denis Lunev has e1000 adapter too, but doesn't > > experience such problems. > > > > What other info from me is required? boot log please. with the patch and reverting the patch. Thanks YH -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
status inquiry #3 (RE: [PATCH 01/03] ISATAP V2 (header file changes))
Would appreciate a status update on this submission, posted 1/15/08.
Thanks - Fred
[EMAIL PROTECTED]
> -Original Message-
> From: Templin, Fred L
> Sent: Tuesday, January 15, 2008 11:57 AM
> To: netdev@vger.kernel.org
> Cc: YOSHIFUJI Hideaki / 吉藤英明
> Subject: [PATCH 01/03] ISATAP V2 (header file changes)
>
> This patch updates the Linux the Intra-Site Automatic Tunnel
> Addressing
> Protocol (ISATAP) implementation. It places the ISATAP
> potential router
> list (PRL) in the kernel and adds three new private ioctls for PRL
> management. The diffs are specific to the netdev net-2.6.25
> development
> tree taken by "git pull" on 1/14/08.
>
> Signed-off-by: Fred L. Templin <[EMAIL PROTECTED]>
>
> --- net-2.6.25/include/linux/skbuff.h.orig2008-01-14
> 15:33:36.0 -0800
> +++ net-2.6.25/include/linux/skbuff.h 2008-01-14
> 15:43:06.0 -0800
> @@ -311,7 +311,8 @@ struct sk_buff {
> __u16 tc_verd;/* traffic
> control verdict */
> #endif
> #endif
> - /* 2 byte hole */
> + __u8rtr_type;
> + /* 1 byte hole */
>
> #ifdef CONFIG_NET_DMA
> dma_cookie_tdma_cookie;
> --- net-2.6.25/include/linux/if_tunnel.h.orig 2008-01-14
> 15:33:36.0 -0800
> +++ net-2.6.25/include/linux/if_tunnel.h 2008-01-14
> 15:42:14.0 -0800
> @@ -7,6 +7,9 @@
> #define SIOCADDTUNNEL (SIOCDEVPRIVATE + 1)
> #define SIOCDELTUNNEL (SIOCDEVPRIVATE + 2)
> #define SIOCCHGTUNNEL (SIOCDEVPRIVATE + 3)
> +#define SIOCADDPRL (SIOCDEVPRIVATE + 4)
> +#define SIOCDELPRL (SIOCDEVPRIVATE + 5)
> +#define SIOCCHGPRL (SIOCDEVPRIVATE + 6)
>
> #define GRE_CSUM __constant_htons(0x8000)
> #define GRE_ROUTING __constant_htons(0x4000)
> @@ -17,9 +20,6 @@
> #define GRE_FLAGS__constant_htons(0x00F8)
> #define GRE_VERSION __constant_htons(0x0007)
>
> -/* i_flags values for SIT mode */
> -#define SIT_ISATAP 0x0001
> -
> struct ip_tunnel_parm
> {
> charname[IFNAMSIZ];
> @@ -30,5 +30,15 @@ struct ip_tunnel_parm
> __be32 o_key;
> struct iphdriph;
> };
> +/* SIT-mode i_flags */
> +#define SIT_ISATAP 0x0001
> +
> +struct ip_tunnel_prladdr {
> + __be32 addr;
> + __be16 flags;
> + __be16 rsvd;
> +};
> +/* PRL flags */
> +#define PRL_BORDER 0x0001
>
> #endif /* _IF_TUNNEL_H_ */
> --- net-2.6.25/include/net/ipip.h.orig2008-01-14
> 15:33:36.0 -0800
> +++ net-2.6.25/include/net/ipip.h 2008-01-14
> 15:41:21.0 -0800
> @@ -24,6 +24,13 @@ struct ip_tunnel
> int mlink;
>
> struct ip_tunnel_parm parms;
> + struct ip_tunnel_prlent *prl; /* potential
> router list */
> +};
> +
> +struct ip_tunnel_prlent
> +{
> + struct ip_tunnel_prlent *next;
> + struct ip_tunnel_prladdr ent;
> };
>
> #define IPTUNNEL_XMIT() do {
> \
> --- net-2.6.25/include/net/ndisc.h.orig 2008-01-14
> 15:40:28.0 -0800
> +++ net-2.6.25/include/net/ndisc.h2008-01-15
> 08:43:21.0 -0800
> @@ -12,6 +12,16 @@
> #define NDISC_REDIRECT 137
>
> /*
> + * Router type: cross-layer information from link-layer to
> + * IPv6 layer reported by certain link types (e.g., RFC4214).
> + */
> +
> +#define RTRTYPE_UNSPEC 0 /*
> unspecified (default) */
> +#define RTRTYPE_HOST 1 /* host or
> unauthorized router */
> +#define RTRTYPE_INTERIOR 2 /* site-interior router */
> +#define RTRTYPE_BORDER 3 /* site
> border router */
> +
> +/*
> * ndisc options
> */
> --
> To unsubscribe from this list: send 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] [PPPOL2TP] Label unused warning when CONFIG_PROC_FS is not set.
Acked-by: James Chapman <[EMAIL PROTECTED]> Rami Rosen wrote: Hi, When CONFIG_PROC_FS is not set and CONFIG_PPPOL2TP is set, we have the following warning in build: drivers/net/pppol2tp.c: In function 'pppol2tp_init': drivers/net/pppol2tp.c:2472: warning: label 'out_unregister_pppox_proto' defined but not used This patches fixes this warning by adding appropriate #ifdef. Regards, Rami Rosen Signed-off-by: Rami Rosen <[EMAIL PROTECTED]> -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development -- To unsubscribe from this list: send 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: [e1000][net-2.6 tree] Regression: driver doesn't detect card on my node.
[Added Ingo, Thomas, Justin who signed off on the patch/tested it] Pavel Emelyanov wrote: > The commit > > 093af8d7f0ba3c6be1485973508584ef081e9f93 > x86_32: trim memory by updating e820 > > broke my e1000 card: on loading driver says that > > e1000: probe of :04:03.0 failed with error -5 > > and the interface doesn't appear. > > With this commit reset everything is OK. > > lspci output: > 04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet > Controller (rev 05) > lspci -n output: > 04:03.0 Class 0200: 8086:1076 (rev 05) > > My colleague Denis Lunev has e1000 adapter too, but doesn't > experience such problems. > > What other info from me is required? > > Config: > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.24 > # Tue Feb 5 19:56:28 2008 > # > # CONFIG_64BIT is not set > CONFIG_X86_32=y > # CONFIG_X86_64 is not set > CONFIG_X86=y > # CONFIG_GENERIC_LOCKBREAK is not set > CONFIG_GENERIC_TIME=y > CONFIG_GENERIC_CMOS_UPDATE=y > CONFIG_CLOCKSOURCE_WATCHDOG=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_SEMAPHORE_SLEEPERS=y > CONFIG_MMU=y > CONFIG_ZONE_DMA=y > CONFIG_QUICKLIST=y > CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_IOMAP=y > CONFIG_GENERIC_BUG=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_DMI=y > # CONFIG_RWSEM_GENERIC_SPINLOCK is not set > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > # CONFIG_ARCH_HAS_ILOG2_U32 is not set > # CONFIG_ARCH_HAS_ILOG2_U64 is not set > CONFIG_GENERIC_CALIBRATE_DELAY=y > # CONFIG_GENERIC_TIME_VSYSCALL is not set > # CONFIG_ARCH_SETS_UP_PER_CPU_AREA is not set > CONFIG_ARCH_SUPPORTS_OPROFILE=y > # CONFIG_ZONE_DMA32 is not set > CONFIG_ARCH_POPULATES_NODE_MAP=y > # CONFIG_AUDIT_ARCH is not set > CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_GENERIC_PENDING_IRQ=y > CONFIG_X86_SMP=y > CONFIG_X86_32_SMP=y > CONFIG_X86_HT=y > CONFIG_X86_BIOS_REBOOT=y > CONFIG_X86_TRAMPOLINE=y > CONFIG_KTIME_SCALAR=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > > # > # General setup > # > CONFIG_EXPERIMENTAL=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_LOCALVERSION="" > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > CONFIG_SYSVIPC_SYSCTL=y > # CONFIG_POSIX_MQUEUE is not set > # CONFIG_BSD_PROCESS_ACCT is not set > # CONFIG_TASKSTATS is not set > # CONFIG_USER_NS is not set > # CONFIG_PID_NS is not set > # CONFIG_AUDIT is not set > CONFIG_IKCONFIG=y > CONFIG_IKCONFIG_PROC=y > CONFIG_LOG_BUF_SHIFT=17 > # CONFIG_CGROUPS is not set > # CONFIG_FAIR_GROUP_SCHED is not set > # CONFIG_RELAY is not set > CONFIG_BLK_DEV_INITRD=y > CONFIG_INITRAMFS_SOURCE="" > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_SYSCTL=y > CONFIG_EMBEDDED=y > CONFIG_UID16=y > CONFIG_SYSCTL_SYSCALL=y > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_ALL is not set > CONFIG_KALLSYMS_EXTRA_PASS=y > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_ANON_INODES=y > CONFIG_EPOLL=y > # CONFIG_SIGNALFD is not set > # CONFIG_EVENTFD is not set > CONFIG_SHMEM=y > CONFIG_VM_EVENT_COUNTERS=y > CONFIG_SLAB=y > # CONFIG_SLUB is not set > # CONFIG_SLOB is not set > CONFIG_SLABINFO=y > CONFIG_RT_MUTEXES=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > # CONFIG_MODULE_FORCE_UNLOAD is not set > CONFIG_MODVERSIONS=y > CONFIG_MODULE_SRCVERSION_ALL=y > CONFIG_KMOD=y > CONFIG_STOP_MACHINE=y > CONFIG_BLOCK=y > CONFIG_LBD=y > CONFIG_LSF=y > # CONFIG_BLK_DEV_BSG is not set > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_AS=y > # CONFIG_IOSCHED_DEADLINE is not set > # CONFIG_IOSCHED_CFQ is not set > CONFIG_DEFAULT_AS=y > # CONFIG_DEFAULT_DEADLINE is not set > # CONFIG_DEFAULT_CFQ is not set > # CONFIG_DEFAULT_NOOP is not set > CONFIG_DEFAULT_IOSCHED="anticipatory" > CONFIG_CLASSIC_RCU=y > # CONFIG_PREEMPT_RCU is not set > > # > # Processor type and features > # > CONFIG_TICK_ONESHOT=y > CONFIG_NO_HZ=y > CONFIG_HIGH_RES_TIMERS=y > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > CONFIG_SMP=y > CONFIG_X86_PC=y > # CONFIG_X86_ELAN is not set > # CONFIG_X86_VOYAGER is not set > # CONFIG_X86_NUMAQ is not set > # CONFIG_X86_SUMMIT is not set > # CONFIG_X86_BIGSMP is not set > # CONFIG_X86_VISWS is not set > # CONFIG_X86_GENERICARCH is not set > # CONFIG_X86_ES7000 is not set > # CONFIG_X86_VSMP is not set > # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set > # CONFIG_PARAVIRT_GUEST is not set > # CONFIG_M386 is not set > # CONFIG_M486 is not set > # CONFIG_M586 is not set > # CONFIG_M586TSC is not set > # CONFIG_M586MMX is not set > CONFIG_M686=y > # CONFIG_MPENTIUMII is not set > # CONFIG_MPENTIUMIII is not set > # CONFIG_MPENTIUMM is not set > # CONFIG_MPENTIUM4 is not set > # CONFIG_MK6 is not set > # CONFIG_MK7 is not set > # CONFIG_MK8 is not set > # CONFIG_MCRUS
[e1000][net-2.6 tree] Regression: driver doesn't detect card on my node.
The commit 093af8d7f0ba3c6be1485973508584ef081e9f93 x86_32: trim memory by updating e820 broke my e1000 card: on loading driver says that e1000: probe of :04:03.0 failed with error -5 and the interface doesn't appear. With this commit reset everything is OK. lspci output: 04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05) lspci -n output: 04:03.0 Class 0200: 8086:1076 (rev 05) My colleague Denis Lunev has e1000 adapter too, but doesn't experience such problems. What other info from me is required? Config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24 # Tue Feb 5 19:56:28 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ARCH_SETS_UP_PER_CPU_AREA is not set CONFIG_ARCH_SUPPORTS_OPROFILE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y # CONFIG_SIGNALFD is not set # CONFIG_EVENTFD is not set CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_VSMP is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG
Re: [patch 5/7] bluetooth: blacklist another Broadcom BCM2035 device
Hi David, > > From: Andy Shevchenko <[EMAIL PROTECTED]> > > > > This device is recognized as bluetooth, but still not works. > > > > Signed-off-by: Andy Shevchenko <[EMAIL PROTECTED]> > > Cc: Marcel Holtmann <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > Applied. > > But, what driver should drive this device? the hci_usb will driver this device, but since it is Broadcom based it needs some extra quirks to work accordingly. Regards Marcel -- To unsubscribe from this list: send 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/7] hci_ldisc: fix null pointer deref
Hi David, > > akpm: > > > > No idea. trollmerge. > > > > Cc: Arjan van de Ven <[EMAIL PROTECTED]> > > Cc: Alan Cox <[EMAIL PROTECTED]> > > Cc: Marcel Holtmann <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > I'll let Marcel and/or Alan take a look at this one. we might have to re-work the whole hci_uart driver at some point, but for now I think this fix is feasible. Alan, if you think it is wrong please step up. I am not an expert when it comes to TTY line disciplines. Regards Marcel -- To unsubscribe from this list: send 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: Still oopsing in nf_nat_move_storage()
Patrick McHardy wrote: Chuck Ebbert wrote: On 01/31/2008 01:03 PM, Chuck Ebbert wrote: On 01/29/2008 12:18 PM, Patrick McHardy wrote: Chuck Ebbert wrote: nf_nat_move_storage(): /usr/src/debug/kernel-2.6.23/linux-2.6.23.i686/net/ipv4/netfilter/nf_nat_core.c:612 87: f7 47 64 80 01 00 00testl $0x180,0x64(%edi) 8e: 74 39 je c9 line 612: if (!(ct->status & IPS_NAT_DONE_MASK)) return; ct is NULL The current kernel (and 2.6.23-stable) have: if (!ct || !(ct->status & IPS_NAT_DONE_MASK)) return; so it seems you're using an old version. So, it is now oopsing after the test for NULL and only x86_64 is catching the invalid address because it is non-canonical. Checking for NULL is obviously not enough... Could you try whether this patch fixes it please? Hallo Patrick, I have tested the patch and the problem seems to be fixed. Thanks, Thomas -- Thomas Woerner Software EngineerPhone: +49-711-96437-0 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner <[EMAIL PROTECTED]> D-70178 StuttgartWeb : http://www.redhat.de/ -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vlan tag match
On Tue, 05 Feb 2008 15:26:07 +0100 Patrick McHardy <[EMAIL PROTECTED]> wrote: > David Miller wrote: > > From: Stephen Hemminger <[EMAIL PROTECTED]> > > Date: Thu, 31 Jan 2008 21:50:25 -0800 > > > >> On Fri, 01 Feb 2008 06:34:34 +0100 > >> Patrick McHardy <[EMAIL PROTECTED]> wrote: > >> > >>> Stephen Hemminger wrote: > Provide a way to use tc filters on vlan tag even if tag is buried in > skb due to hardware acceleration. > >>> Looks reasonable. Would you like to add the same feature to the > >>> flow classifier? > >> Yes, that would be good. > > > > Did that patch get posted? I didn't see it. > > > No, but I already added it myself. I'll post it in a new thread. > > BTW, Stephen, I noticed your ematch patch doesn't mask out the > VLAN priority which is also included in the return value of > vlan_get_tag(), is that intentional? > It seemed easier than adding two different tag related matches, since meta match can do expressions. -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add IPv6 support to TCP SYN cookies
> What kind of LISTEN ports? And does it matter if they're DoS'ed? I guess that depends on the opinion of the owner - Push based mobile services - Email delivery - VoIP - Management ports - Peer to peer data transfer - Instant messaging direct user/user connections Some of that can also be hardened using IP filter rules > > Is the other stuff enough - good question, and can be measured easily > > enough on a little dlink router or similar. > > My guess would be that it is. Alan -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Tue, Feb 05, 2008 at 04:03:01PM +, Alan Cox wrote: > > Also your sub PC class appliances rarely run LISTEN servers anyways > > that are open to the world. > > Really. The ones that first come to mind often have exposed ports > including PDA devices and phones. (Ditto low end PC boxes - portscan an > EEPC some day ;)) What kind of LISTEN ports? And does it matter if they're DoS'ed? The only one I can think of right now would be ident and frankly nobody will really care if that one works or not. If it's just the management interface etc. (which should really be firewalled) then likely not. > Is the other stuff enough - good question, and can be measured easily > enough on a little dlink router or similar. My guess would be that it is. If it's not it would be probably better to look at improving the standard queue management again; e.g.readd RED. -Andi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add IPv6 support to TCP SYN cookies
> Also your sub PC class appliances rarely run LISTEN servers anyways > that are open to the world. Really. The ones that first come to mind often have exposed ports including PDA devices and phones. (Ditto low end PC boxes - portscan an EEPC some day ;)) Is the other stuff enough - good question, and can be measured easily enough on a little dlink router or similar. Alan -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Tue, Feb 05, 2008 at 03:42:13PM +, Alan Cox wrote: > > Syncookies are discouraged these days. They disable too many > > valuable TCP features (window scaling, SACK) and even without them > > the kernel is usually strong enough to defend against syn floods > > and systems have much more memory than they used to be. > > Somewhat untrue. Network speeds have risen dramatically, the number of With strong I meant Linux has much better algorithms to handle the standard syn queue (syncookies was originally added when it had only dumb head drop) and there are minisocks which also require significantly less overhead to manage than full sockets (less memory etc.) When I wrote syncookies originally that all was not true. > appliances running Linux that are not PC class means memory has fallen > not risen and CPU has been pretty level. > > > So I don't think it makes much sense to add more code to it, sorry. > > I think it makes a lot of sense I have my doubts. It would be probably better to recheck everything and then remove syncookies. Also your sub PC class appliances rarely run LISTEN servers anyways that are open to the world. -Andi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netatalk slow after system upgrade (possibly kernel problem?)
(I let full quote here for reference, my text is on the bottom) On Sonntag, 27. Januar 2008 Andrew Morton wrote: > (cc netdev) > > > On Fri, 25 Jan 2008 12:55:42 +0100 Michael Monnerie > > <[EMAIL PROTECTED]> wrote: Dear lists, > > > > I've been spending a LOT of time trying to find out where's the > > problem, but can't find it and therefore seek urgent help now. We > > have the following system: > > > > Server with VMware server > > -> VM running a webserver and netatalk > > -> 2 other VMs not related > > > > The VM with netatalk was SUSE 10.0 with kernel 2.6.13-15.15-smp > > (from SUSE), and things were pretty fun and quick. Then we upgraded > > to SUSE 10.2 and now 10.3, where everything EXCEPT netatalk runs > > perfect. Since this upgrade, Apple clients (MacOS X) now do READ > > very very slowly (about 512KB/s over the gigabit LAN), while > > writing to the server still is normal (>20MB/s). I've even retried > > with the newest kernel 2.6.23.13, tried different > > /proc/sys/net/ipv4/tcp_congestion_control (cubic, reno, bic, etc.) > > and nothing helps. I've then tried to install Samba and found that > > we have similar problems reading with it from MacOS clients. Now > > I'm pretty sure it should be something with the linux kernel, but I > > don't understand what. > > > > Here are the wireshark dumps in pcap format: > > http://zmi.at/x/atalk-write-fast.pcap > > -> you can see writing to the server (192.168.120.9) is normal and > > fast > > > > http://zmi.at/x/atalk-read-slow.pcap > > -> reading is horribly slow. Lots of "unknown", because of netatalk > > or what? > > > > http://zmi.at/x/unknown-atalk.pcap > > -> another dump while reading, you see "unknown" reads. I'm not > > sure if it's just wireshark not understanding the packets or > > netatalk. > > > > And trying with samba: > > http://zmi.at/x/smb-read-slow.pcap > > http://zmi.at/x/smb-write-quick.pcap > > you can see that it's also slow. > > > > Now why did it work with the old 2.6.13 kernel? I still have that > > old VM, and when I start it, it is always perfectly fast. Only > > newer versions are slow. Can somebody give me a hint please? > > It would be interesting if this could be repeated on bare hardware, > so we can eliminate the possibility that it is some weird interaction > with vmware. I tested now on the same machine, outside of VMware: It is blazing fast, just as it should be - kernel release 2.6.18.8-0.5-ZMI, where -ZMI means I compiled the kernel myself. Still, it runs quick within the VM with kernel 2.6.13-15.15-smp from SUSE 10.0, but slow with more recent kernels (I couldn't test every combination of course). I tried but cannot compile 2.6.13 within SUSE 10.3, it gives lots of errors because libs changed. It would be very nice to find the source of the problem. I uploaded the kernel config options files onto my server for reference, HTH: VMware with SUSE 10.0 and fast netatalk/samba: http://zmi.at/x/config2.6.13-15.15.txt VMware host, outside of VMware, also fast: http://zmi.at/x/config2.6.18.8-host.txt VMware with SUSE 10.2 and kernel 2.6.22-9-ZMI, slow: http://zmi.at/x/config2.6.22.9-slow.txt VMware with SUSE 10.3 and kernel 2.6.23.13-ZMI, slow: http://zmi.at/x/config2.6.23.13-slow.txt The problem seems to be somewhere between the kernel and VMware, but I do not know what to do. mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0676/846 914 666 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: www.keyserver.net Key-ID: 1C1209B4 signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Add IPv6 support to TCP SYN cookies
> Syncookies are discouraged these days. They disable too many > valuable TCP features (window scaling, SACK) and even without them > the kernel is usually strong enough to defend against syn floods > and systems have much more memory than they used to be. Somewhat untrue. Network speeds have risen dramatically, the number of appliances running Linux that are not PC class means memory has fallen not risen and CPU has been pretty level. > So I don't think it makes much sense to add more code to it, sorry. I think it makes a lot of sense - providing it defaults off for the PC world where as you say its use is limited. Alan -- To unsubscribe from this list: send 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] Add IPv6 support to TCP SYN cookies
On Mon, Feb 04, 2008 at 03:01:01PM -0800, Glenn Griffin wrote: > Add IPv6 support to TCP SYN cookies. This is written and tested against > 2.6.24, and applies cleanly to linus' current HEAD (d2fc0b). Unfortunately > linus' HEAD breaks my sky2 card at the moment, so I'm unable to test against > that. I see no reason why it would be affected though. Comments/suggestions > are welcome. Syncookies are discouraged these days. They disable too many valuable TCP features (window scaling, SACK) and even without them the kernel is usually strong enough to defend against syn floods and systems have much more memory than they used to be. So I don't think it makes much sense to add more code to it, sorry. Besides you should really move it to the ipv6 module, right now the code would be always compiled in even for ipv4 only kernels. -Andi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SCTP: Fix kernel panic while received ASCONF chunk with bad serial number
Wei Yongjun wrote:
While recevied ASCONF chunk with serial number less then needed, kernel
will treat this chunk as a retransmitted ASCONF chunk and find cached
ASCONF-ACK chunk used sctp_assoc_lookup_asconf_ack(). But this function
will always return NO-NULL. So response with cached ASCONF-ACKs chunk
will cause kernel panic.
In function sctp_assoc_lookup_asconf_ack(), if the cached ASCONF-ACKs
list asconf_ack_list is empty, or if the serial being requested does not
exists, the function as it currectly stands returns the actuall
list_head asoc->asconf_ack_list, this is not a cache ASCONF-ACK chunk
but a bogus pointer.
Thanks, applied.
-vlad
Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]>
--- a/net/sctp/associola.c2008-01-28 20:31:39.0 -0500
+++ b/net/sctp/associola.c2008-01-28 23:45:20.0 -0500
@@ -1525,7 +1525,7 @@ struct sctp_chunk *sctp_assoc_lookup_asc
const struct sctp_association *asoc,
__be32 serial)
{
-struct sctp_chunk *ack = NULL;
+struct sctp_chunk *ack;
/* Walk through the list of cached ASCONF-ACKs and find the
* ack chunk whose serial number matches that of the request.
@@ -1533,9 +1533,9 @@ struct sctp_chunk *sctp_assoc_lookup_asc
list_for_each_entry(ack, &asoc->asconf_ack_list, transmitted_list) {
if (ack->subh.addip_hdr->serial == serial) {
sctp_chunk_hold(ack);
-break;
+return ack;
}
}
-return ack;
+return NULL;
}
--
To unsubscribe from this list: send 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] SCTP: Fix kernel panic while received ASCONF chunk with bad serial number
While recevied ASCONF chunk with serial number less then needed, kernel
will treat this chunk as a retransmitted ASCONF chunk and find cached
ASCONF-ACK chunk used sctp_assoc_lookup_asconf_ack(). But this function
will always return NO-NULL. So response with cached ASCONF-ACKs chunk
will cause kernel panic.
In function sctp_assoc_lookup_asconf_ack(), if the cached ASCONF-ACKs
list asconf_ack_list is empty, or if the serial being requested does not
exists, the function as it currectly stands returns the actuall
list_head asoc->asconf_ack_list, this is not a cache ASCONF-ACK chunk
but a bogus pointer.
Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]>
--- a/net/sctp/associola.c 2008-01-28 20:31:39.0 -0500
+++ b/net/sctp/associola.c 2008-01-28 23:45:20.0 -0500
@@ -1525,7 +1525,7 @@ struct sctp_chunk *sctp_assoc_lookup_asc
const struct sctp_association *asoc,
__be32 serial)
{
- struct sctp_chunk *ack = NULL;
+ struct sctp_chunk *ack;
/* Walk through the list of cached ASCONF-ACKs and find the
* ack chunk whose serial number matches that of the request.
@@ -1533,9 +1533,9 @@ struct sctp_chunk *sctp_assoc_lookup_asc
list_for_each_entry(ack, &asoc->asconf_ack_list, transmitted_list) {
if (ack->subh.addip_hdr->serial == serial) {
sctp_chunk_hold(ack);
- break;
+ return ack;
}
}
- return ack;
+ return NULL;
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[IPROUTE]: cls_flow: add vlan-tag support
commit 94e9cba778cb97d77d9146dc3bd38ff195bc2c8a
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sat Feb 2 18:22:16 2008 +0100
[IPROUTE]: cls_flow: add vlan-tag support
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index 16869c2..e3e9e25 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -348,6 +348,7 @@ enum
FLOW_KEY_RTCLASSID,
FLOW_KEY_SKUID,
FLOW_KEY_SKGID,
+ FLOW_KEY_VLAN_TAG,
__FLOW_KEY_MAX,
};
diff --git a/tc/f_flow.c b/tc/f_flow.c
index eca05cd..1537ade 100644
--- a/tc/f_flow.c
+++ b/tc/f_flow.c
@@ -32,7 +32,8 @@ static void explain(void)
"KEY-LIST := [ KEY-LIST , ] KEY\n"
"KEY := [ src | dst | proto | proto-src | proto-dst | iif | priority | \n"
" mark | nfct | nfct-src | nfct-dst | nfct-proto-src | \n"
-" nfct-proto-dst | rt-classid | sk-uid | sk-gid ]\n"
+" nfct-proto-dst | rt-classid | sk-uid | sk-gid |\n"
+" vlan-tag ]\n"
"OPS := [ or NUM | and NUM | xor NUM | rshift NUM | addend NUM ]\n"
"ID := X:Y\n"
);
@@ -55,6 +56,7 @@ static const char *flow_keys[FLOW_KEY_MAX+1] = {
[FLOW_KEY_RTCLASSID]= "rt-classid",
[FLOW_KEY_SKUID]= "sk-uid",
[FLOW_KEY_SKGID]= "sk-gid",
+ [FLOW_KEY_VLAN_TAG] = "vlan-tag",
};
static int flow_parse_keys(__u32 *keys, __u32 *nkeys, char *argv)
[NET_SCHED 04/04]: cls_flow: support classification based on VLAN tag
[NET_SCHED]: cls_flow: support classification based on VLAN tag
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 104092e6d90cba5fa00902a3154155872d693f42
tree 0e3fd5871a861fa022bbc2f34d314bb8672b556a
parent 03faf81b8195be455c3c7592d76d712ea9d80b13
author Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Feb 2008 15:22:23 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Feb 2008 15:22:23 +0100
include/linux/pkt_cls.h |1 +
net/sched/cls_flow.c| 12
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index 40fac8c..28dfc61 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -348,6 +348,7 @@ enum
FLOW_KEY_RTCLASSID,
FLOW_KEY_SKUID,
FLOW_KEY_SKGID,
+ FLOW_KEY_VLAN_TAG,
__FLOW_KEY_MAX,
};
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index eeb223c..971b867 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -270,6 +271,15 @@ static u32 flow_get_skgid(const struct sk_buff *skb)
return 0;
}
+static u32 flow_get_vlan_tag(const struct sk_buff *skb)
+{
+ u16 uninitialized_var(tag);
+
+ if (vlan_get_tag(skb, &tag) < 0)
+ return 0;
+ return tag & VLAN_VID_MASK;
+}
+
static u32 flow_key_get(const struct sk_buff *skb, int key)
{
switch (key) {
@@ -305,6 +315,8 @@ static u32 flow_key_get(const struct sk_buff *skb, int key)
return flow_get_skuid(skb);
case FLOW_KEY_SKGID:
return flow_get_skgid(skb);
+ case FLOW_KEY_VLAN_TAG:
+ return flow_get_vlan_tag(skb);
default:
WARN_ON(1);
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
[VLAN 03/04]: Constify skb argument to vlan_get_tag()
[VLAN]: Constify skb argument to vlan_get_tag()
Required by next patch to use it from the flow classifier.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 03faf81b8195be455c3c7592d76d712ea9d80b13
tree 9da377d2bd44421494a4c4d7cf6c705d199c26ce
parent 2e5915ef51e55135522e59e041bb176432857d82
author Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Feb 2008 15:22:23 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Feb 2008 15:22:23 +0100
include/linux/if_vlan.h |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 34f40ef..79504b2 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -327,7 +327,7 @@ static inline struct sk_buff *vlan_put_tag(struct sk_buff
*skb, unsigned short t
*
* Returns error if the skb is not of VLAN type
*/
-static inline int __vlan_get_tag(struct sk_buff *skb, unsigned short *tag)
+static inline int __vlan_get_tag(const struct sk_buff *skb, unsigned short
*tag)
{
struct vlan_ethhdr *veth = (struct vlan_ethhdr *)skb->data;
@@ -347,7 +347,8 @@ static inline int __vlan_get_tag(struct sk_buff *skb,
unsigned short *tag)
*
* Returns error if @skb->cb[] is not set correctly
*/
-static inline int __vlan_hwaccel_get_tag(struct sk_buff *skb, unsigned short
*tag)
+static inline int __vlan_hwaccel_get_tag(const struct sk_buff *skb,
+unsigned short *tag)
{
struct vlan_skb_tx_cookie *cookie;
@@ -370,7 +371,7 @@ static inline int __vlan_hwaccel_get_tag(struct sk_buff
*skb, unsigned short *ta
*
* Returns error if the skb is not VLAN tagged
*/
-static inline int vlan_get_tag(struct sk_buff *skb, unsigned short *tag)
+static inline int vlan_get_tag(const struct sk_buff *skb, unsigned short *tag)
{
if (skb->dev->features & NETIF_F_HW_VLAN_TX) {
return __vlan_hwaccel_get_tag(skb, tag);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET_SCHED 01/04]: em_meta: fix compile warning
[NET_SCHED]: em_meta: fix compile warning
net/sched/em_meta.c: In function 'meta_int_vlan_tag':
net/sched/em_meta.c:179: warning: 'tag' may be used uninitialized in this
function
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit adfab462c5e0a32274927bba4eec3afc6e35
tree bfac456798152d7ea6bedcca4a03b4f045605d3d
parent fb1c15ba9ebcab6478a409051ad26d7d180fe286
author Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Feb 2008 15:22:21 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Feb 2008 15:22:21 +0100
net/sched/em_meta.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sched/em_meta.c b/net/sched/em_meta.c
index 9c2ec19..2a7e648 100644
--- a/net/sched/em_meta.c
+++ b/net/sched/em_meta.c
@@ -176,7 +176,7 @@ META_COLLECTOR(var_dev)
META_COLLECTOR(int_vlan_tag)
{
- unsigned short tag;
+ unsigned short uninitialized_var(tag);
if (vlan_get_tag(skb, &tag) < 0)
*err = -1;
else
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET_SCHED 02/04]: cls_flow: fix key mask validity check
[NET_SCHED]: cls_flow: fix key mask validity check
Since we're using fls(), we need to check whether the value is non-zero first.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 2e5915ef51e55135522e59e041bb176432857d82
tree 9a42fac3d1646a378acdc91b55642b68c9d97dde
parent adfab462c5e0a32274927bba4eec3afc6e35
author Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Feb 2008 15:22:23 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Feb 2008 15:22:23 +0100
net/sched/cls_flow.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index 8d76986..eeb223c 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -402,12 +402,13 @@ static int flow_change(struct tcf_proto *tp, unsigned
long base,
if (tb[TCA_FLOW_KEYS]) {
keymask = nla_get_u32(tb[TCA_FLOW_KEYS]);
- if (fls(keymask) - 1 > FLOW_KEY_MAX)
- return -EOPNOTSUPP;
nkeys = hweight32(keymask);
if (nkeys == 0)
return -EINVAL;
+
+ if (fls(keymask) - 1 > FLOW_KEY_MAX)
+ return -EOPNOTSUPP;
}
err = tcf_exts_validate(tp, tb, tca[TCA_RATE], &e, &flow_ext_map);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET_SCHED 00/04]: Two fixes + cls_flow VLAN tag based classification
These patches fix a compile warning in em_meta, an invalid check in the flow classifier and add VLAN tag based classification to cls_flow. Please apply, thanks. include/linux/if_vlan.h |7 --- include/linux/pkt_cls.h |1 + net/sched/cls_flow.c| 17 +++-- net/sched/em_meta.c |2 +- 4 files changed, 21 insertions(+), 6 deletions(-) Patrick McHardy (4): [NET_SCHED]: em_meta: fix compile warning [NET_SCHED]: cls_flow: fix key mask validity check [VLAN]: Constify skb argument to vlan_get_tag() [NET_SCHED]: cls_flow: support classification based on VLAN tag -- To unsubscribe from this list: send 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] vlan tag match
David Miller wrote: From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 31 Jan 2008 21:50:25 -0800 On Fri, 01 Feb 2008 06:34:34 +0100 Patrick McHardy <[EMAIL PROTECTED]> wrote: Stephen Hemminger wrote: Provide a way to use tc filters on vlan tag even if tag is buried in skb due to hardware acceleration. Looks reasonable. Would you like to add the same feature to the flow classifier? Yes, that would be good. Did that patch get posted? I didn't see it. No, but I already added it myself. I'll post it in a new thread. BTW, Stephen, I noticed your ematch patch doesn't mask out the VLAN priority which is also included in the return value of vlan_get_tag(), is that intentional? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
etcnet Wi-Fi tuning
Hello,
Can you help me? What can I read to solve the task:
The is Altlinux installed on the computer with Ethernet card connected
with the local network/Internet (DHCP) + WiFi USB stick.
There is notebook with Windows XP + Wi-FI PCMCIA card.
I want to connect with notebook AD-HOC: Samba, printer (on my PC
(CUPS)). I also want to retransmit local network/Internet to the notebook.
Altlinux has etcnet.
I made some tuning in ifaces/wlan0, but notebook cannot connect
with wi-fi net "Ivp" (there are two, and it cannot connect with each of
then).
Folder wlan0:
ipv4address:
192.168.0.2/24
ipv4route:
default via 192.168.0.1
iwconfig:
essid Ivp
mode 1
ap 00-50-22-E2-B6-OF
channel 3
rate 54M
options:
TYPE=eth
MODULE=ndiswrapper
NEVER_RMMOD=YES
USE_HOTPLUG=no
ONBOOT=yes
wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
update_config=1
network={
ssid="Ivp"
bssid=00-15-E9-B3-2A-20
key_mgmt=NONE
}
What is wrong?
I.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] virtio_net: Fix open <-> interrupt race
I got the following oops during interface ifup. Unfortunately its not
easily reproducable so I cant say for sure that my fix fixes this
problem, but I am confident and I think its correct anyway:
<2>kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:234!
<4>illegal operation: 0001 [#1] PREEMPT SMP
<4>Modules linked in:
<4>CPU: 0 Not tainted 2.6.24zlive-guest-07293-gf1ca151-dirty #91
<4>Process swapper (pid: 0, task: 00800938, ksp: 0084ddb8)
<4>Krnl PSW : 040430018000 00466374 (vring_disable_cb+0x30/0x34)
<4> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
<4>Krnl GPRS: 0001 0001 10003800
00466344
<4> 0e980900 008848b0 0084e748
<4> 0087b300 1237 1237
0f85bdd8
<4> 0e980920 001137c0 00464754
0f85bdd8
<4>Krnl Code: 00466368: e3b0b074lg %r11,112(%r11)
<4> 0046636e: 07febcr 15,%r14
<4> 00466370: a7f40001brc 15,466372
<4> >00466374: a7f4fff6brc 15,466360
<4> 00466378: eb7ff0500024stmg
%r7,%r15,80(%r15)
<4> 0046637e: a7f13e00tmll%r15,15872
<4> 00466382: b90400eflgr %r14,%r15
<4> 00466386: a7840001brc 8,466388
<4>Call Trace:
<4>([<000201500f85c000>] 0x201500f85c000)
<4> [<00466556>] vring_interrupt+0x72/0x88
<4> [<004801a0>] kvm_extint_handler+0x34/0x44
<4> [<0010d22c>] do_extint+0xbc/0xf8
<4> [<00113f98>] ext_no_vtime+0x16/0x1a
<4> [<0010a182>] cpu_idle+0x216/0x238
<4>([<0010a162>] cpu_idle+0x1f6/0x238)
<4> [<00568656>] rest_init+0xaa/0xb8
<4> [<0084ee2c>] start_kernel+0x3fc/0x490
<4> [<00100020>] _stext+0x20/0x80
<4>
<4> <0>Kernel panic - not syncing: Fatal exception in interrupt
<4>
After looking at the code and the dump I think the following scenario
happened: Ifup was running on cpu2 and the interrupt arrived on cpu0.
Now virtnet_open on cpu 2 managed to execute napi_enable and disable_cb
but did not execute rx_schedule. Meanwhile on cpu 0 skb_recv_done was
called by vring_interrupt, executed netif_rx_schedule_prep, which
succeeded and therefore called disable_cb. This triggered the BUG_ON,
as interrupts were already disabled by cpu 2.
I think the proper solution is to make the call to disable_cb depend on
the atomic update of NAPI_STATE_SCHED by using netif_rx_schedule_prep
in the same way as skb_recv_done.
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
drivers/net/virtio_net.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
Index: kvm/drivers/net/virtio_net.c
===
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -321,10 +321,12 @@ static int virtnet_open(struct net_devic
/* If all buffers were filled by other side before we napi_enabled, we
* won't get another interrupt, so process any outstanding packets
-* now. virtnet_poll wants re-enable the queue, so we disable here. */
- vi->rvq->vq_ops->disable_cb(vi->rvq);
- netif_rx_schedule(vi->dev, &vi->napi);
-
+* now. virtnet_poll wants re-enable the queue, so we disable here.
+* We synchronize against interrupts via NAPI_STATE_SCHED */
+ if (netif_rx_schedule_prep(dev, &vi->napi)) {
+ vi->rvq->vq_ops->disable_cb(vi->rvq);
+ __netif_rx_schedule(dev, &vi->napi);
+ }
return 0;
}
--
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
To unsubscribe from this list: send 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: locking api self-test hanging
* Andrew Morton <[EMAIL PROTECTED]> [2008-02-04 14:04]: > > but that code really needs help. Using spin_lock_irqsave() is what rtc_get_rtc_time() does which was used before I changed to get_rtc_time() does. So it should be ok. I missed that difference. However, I agree with you the whole RTC "emulation" per HPET is a bit unclean. However, I have too little experience in this code area to come up with a proper redesign. I just ported it from the old RTC to the new RTC module interface. > Bernhard, I believe the checklist items in Documentation/SubmitChecklist > would have prevented this at the source. Yes. I must admit that I didn't know that document. I used checkpatch.pl, but that's of course only for coding style. I'll try to follow the points in SubmitChecklist in future. Bernhard -- To unsubscribe from this list: send 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] [PPPOL2TP] Label unused warning when CONFIG_PROC_FS is not set.
Hi, When CONFIG_PROC_FS is not set and CONFIG_PPPOL2TP is set, we have the following warning in build: drivers/net/pppol2tp.c: In function 'pppol2tp_init': drivers/net/pppol2tp.c:2472: warning: label 'out_unregister_pppox_proto' defined but not used This patches fixes this warning by adding appropriate #ifdef. Regards, Rami Rosen Signed-off-by: Rami Rosen <[EMAIL PROTECTED]> diff --git a/drivers/net/pppol2tp.c b/drivers/net/pppol2tp.c index 1b51bb6..5aa0a80 100644 --- a/drivers/net/pppol2tp.c +++ b/drivers/net/pppol2tp.c @@ -2468,9 +2468,10 @@ static int __init pppol2tp_init(void) out: return err; - +#ifdef CONFIG_PROC_FS out_unregister_pppox_proto: unregister_pppox_proto(PX_PROTO_OL2TP); +#endif out_unregister_pppol2tp_proto: proto_unregister(&pppol2tp_sk_proto); goto out;
Re: [PATCH] vlan tag match
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 31 Jan 2008 21:50:25 -0800 > On Fri, 01 Feb 2008 06:34:34 +0100 > Patrick McHardy <[EMAIL PROTECTED]> wrote: > > > Stephen Hemminger wrote: > > > Provide a way to use tc filters on vlan tag even if tag is buried in > > > skb due to hardware acceleration. > > > > Looks reasonable. Would you like to add the same feature to the > > flow classifier? > > Yes, that would be good. Did that patch get posted? I didn't see it. -- To unsubscribe from this list: send 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] vlan tag match
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 31 Jan 2008 21:07:32 -0800 > Provide a way to use tc filters on vlan tag even if tag is buried in > skb due to hardware acceleration. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add if_addrlabel.h to sanitized headers
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 31 Jan 2008 22:37:31 -0800 > if_addrlabel.h is needed for iproute2 usage. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] rtnetlink.c: remove no longer used functions
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Fri, 1 Feb 2008 18:19:04 +0200 > On Wed, Jan 30, 2008 at 09:04:33PM +0100, Patrick McHardy wrote: > > Adrian Bunk wrote: > >> This patch #if 0's the following no longer used functions: > >> - rtattr_parse() > >> - rtattr_strlcpy() > >> - __rtattr_parse_nested_compat() > >> > > > > Please remove them instead. > > Updated patch below. Applied, thanks Adrian. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
