wrote:
* Manfred Spraul <manf...@colorfullife.com> wrote:
Hi Ingo,
On 07/07/2017 10:31 AM, Ingo Molnar wrote:
There's another, probably just as significant advantage:
queued_spin_unlock_wait()
is 'read-only', while spin_lock()+spin_unlock() dirties the lock cache line. On
any b
Hi Ingo,
On 07/07/2017 10:31 AM, Ingo Molnar wrote:
There's another, probably just as significant advantage:
queued_spin_unlock_wait()
is 'read-only', while spin_lock()+spin_unlock() dirties the lock cache line. On
any bigger system this should make a very measurable difference - if
Hi Paul,
On 07/06/2017 01:31 AM, Paul E. McKenney wrote:
From: Manfred Spraul <manf...@colorfullife.com>
As we want to remove spin_unlock_wait() and replace it with explicit
spin_lock()/spin_unlock() calls, we can use this to simplify the
locking.
In addition:
- Reading nf_conntrack_loc
slow path should not hurt:
Due to the hysteresis code, the slow path is at least factor 10
rarer than it was before.
Especially: Who is able to test it?
Signed-off-by: Manfred Spraul <manf...@colorfullife.com>
Cc: Alan Stern <st...@rowland.harvard.edu>
On 07/03/2017 07:14 PM, Paul E. McKenney wrote:
On Mon, Jul 03, 2017 at 10:39:49AM -0400, Alan Stern wrote:
On Sat, 1 Jul 2017, Manfred Spraul wrote:
As we want to remove spin_unlock_wait() and replace it with explicit
spin_lock()/spin_unlock() calls, we can use this to simplify the
locking
immediately by spin_unlock().
This should be safe from a performance perspective because exit_sem()
is rarely invoked in production.
Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Davidlohr Bueso <d...@stgolabs.net>
Yinghai Lu wrote:
Correct, but the overall point was that MSI-X conceptually conflicts
with the existing lockless disable_irq() schedule, which was written
when there was a one-one relationship between irq, PCI device, and work
to be done.
at this point, nic in mcp55 is using msi or
Yinghai Lu wrote:
On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote:
Someone around with a MSI capable board? The forcedeth driver does
dev-irq = pci_dev-irq
in nv_probe(), especially before pci_enable_msi().
Does pci_enable_msi() change pci_dev-irq? Then we would disable the
wrong
Jeff Garzik wrote:
I think the scenario you outline is an illustration of the approach's
fragility: disable_irq() is a heavy hammer that originated with INTx,
and it relies on a chip-specific disable method (kernel/irq/manage.c)
that practically guarantees behavior will vary across
Jeff Garzik wrote:
Interested parties should try the forcedeth patches I just posted :)
The patches look good, but I would still prefer to understand why the
current implementation causes crashes before rewriting everything.
I've just noticed that netpoll_send_skb() calls -hard_start_xmit()
Ayaz Abdulla wrote:
I am trying to track down a forcedeth driver issue described by bug
9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy
load). I added a patch to synchronize the timer handlers so that one
handler doesn't accidently enable the IRQ while another timer
Marcelo Tosatti wrote:
Since v2.4.33 should be out RSN, my opinion is that applying the one-liner
to fix the bringup problem for now is more prudent..
It's attached. Untested, but it should work. Just the relevant hunk from
the 0.42 patch.
But I would disagree with waiting for 2.3.34
Hi Willy,
Willy Tarreau wrote:
I started from the latest backport you sent in september (0.42) and
incrementally applied 2.6 updates. I stopped at 0.50 which provides
VLAN support, because after this one, there are some 2.4-incompatible
changes (64bit consistent memory allocation for rings,
Andi Kleen wrote:
My NF4Pro machine now reliably does
Disconnecting: Bad packet length 3742984839.
when I display a lot of data through ssh. Apparently it generates some
corruption that's not caught by the TCP checksum.
The nic does hw checksumming - thus the tcp checksum won't catch
Ingo Oeser wrote:
Hi there,
here are some suggested cleanups, which compiled without problems using
allyesconfig on the latest net-2.6 git tree from David S. Miller.
Please review and apply, if convienient.
I think the patch should wait until 0.57 is merged: There are 4 patches
on their
Hi Ayaz,
looks good, except:
Ayaz Abdulla wrote:
+
+ NvRegPowerState2 = 0x600,
You access a register at offset 0x600
/* Miscelaneous hardware related defines: */
-#define NV_PCI_REGSZ 0x270
+#define NV_PCI_REGSZ_VER1 0x270
+#define NV_PCI_REGSZ_VER2
Ayaz Abdulla wrote:
Manfred Spraul wrote:
Ayaz Abdulla wrote:
if (nv_alloc_rx(dev)) {
-spin_lock(np-lock);
+spin_lock_irqsave(np-lock, flags);
Tiny point:
there is not need for irqsave(): we are in timer context, that
guarantees:
- bottom half disabled
PROTECTED]
Signed-Off-By: Manfred Spraul [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
Ayaz Abdulla wrote:
Ayaz Abdulla wrote:
Manfred Spraul wrote:
Ayaz Abdulla wrote:
This patch adds support for configuration of various parameters. This
includes module parameters and ethtool commands.
+
+if (netif_running(dev)) {
+nv_start_rx(dev);
+nv_start_tx
Ayaz Abdulla wrote:
This patch adds flow control support for tx and rx pause frames in
forcedeth.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
Signed-Off-By: Manfred Spraul [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
Ayaz Abdulla wrote:
This patch adds support for configuration of various parameters. This
includes module parameters and ethtool commands.
+
+ if (netif_running(dev)) {
+ nv_start_rx(dev);
+ nv_start_tx(dev);
+ nv_enable_irq(dev);
+ }
+
Ayaz Abdulla wrote:
+
+ NvRegPowerState2 = 0x600,
+#define NVREG_POWERSTATE2_POWERUP_MASK 0x0F11
+#define NVREG_POWERSTATE2_POWERUP_REV_A3 0x0001
};
If the nic has a register 0x600, then we should
- ioremap enough memory. Right now, the code only remaps 0x270
- report
Ayaz Abdulla wrote:
if (nv_alloc_rx(dev)) {
- spin_lock(np-lock);
+ spin_lock_irqsave(np-lock, flags);
Tiny point:
there is not need for irqsave(): we are in timer context, that guarantees:
- bottom half disabled
- interrupts enabled
Just use
Eric W. Biederman wrote:
There are also things to cause doubt. It looks like Manfred Spraul
has contributed about as many patches as Ayaz Abdulla.
That's misleading: I did most of the initial work, in the last months
Ayaz wrote virtually all improvements.
--
Manfred
-
To unsubscribe
Hi Ayaz,
I know, I'm late, but:
Ayaz Abdulla wrote:
- disable_irq(dev-irq);
+
+ if (!(np-msi_flags NV_MSI_X_ENABLED) ||
+ ((np-msi_flags NV_MSI_X_ENABLED)
+ ((np-msi_flags NV_MSI_X_VECTORS_MASK) == 0x1))) {
+ disable_irq(dev-irq);
+ } else {
+
Hi Ayaz,
sorry for the slow reply:
Ayaz Abdulla wrote:
This forcedeth patch adds high dma support for tx/rx rings.
@@ -2529,7 +2548,14 @@
printk(KERN_INFO forcedeth: 64-bit DMA failed, using 32-bit
addressing for device %s.\n,
Ayaz Abdulla wrote:
If you look at the code, I do not set the NV_TX2_VALID bit (stored in
np-tx_flags) in the first tx descriptor
You are right: tx_flags starts as 0 and is only set to np-tx_flags
after the first tx descriptor was set up.
I overlooked that point, sorry.
Jeff: Could you add
.
Signed-off-by: Ayaz Abdulla [EMAIL PROTECTED]
Rediffed against forcedeth 0.48
Signed-Off-By: Manfred Spraul [EMAIL PROTECTED]
--- 2.6/drivers/net/forcedeth.c 2005-12-24 14:22:04.0 +0100
+++ x64/drivers/net/forcedeth.c 2005-12-24 14:21:35.0 +0100
@@ -101,6 +101,7 @@
* 0.46
Hi,
Andi Kleen wrote:
It shouldn't make any difference on !SLAB_DEBUG kernels because kmalloc
will pad typical mtus (1.5k, 9k) to 2k or 16k. But at least the
network driver is usable now again with slab debugging enabled.
Very odd. slab debugging doesn't affect the padding. Even with
Andi Kleen wrote:
It's more than 82 bytes but less than 86. I didn't run the binary
search further.
My guess: with 86 byte additional padding, you end up doing
kmalloc(2049), and thus with a 4 kB allocation.
On my setup, padding 64 results in a 1984 byte kmalloc call:
dev_kfree_skb for
Andi Kleen wrote:
On Fri, Dec 23, 2005 at 03:15:24PM +0100, Manfred Spraul wrote:
Andi Kleen wrote:
It's more than 82 bytes but less than 86. I didn't run the binary
search further.
My guess: with 86 byte additional padding, you end up doing
kmalloc(2049), and thus
John W. Linville wrote:
I am now... :-) But, I still don't seem to see any problem. Are there
specific tests I should run?
It crashes for me, too:
- nForce 3-250 Gb, in 100 mbit mode
- slab debugging on
- iommu debug and iommu leak enabled
- x86-64
- tx works.
- rx crashes.
Test case:
Hi,
forcedeth called pci_map_single() with size==0 in the rx codepath. This
might explain the crashes on x86-64.
The attached patch fixes that. Who saw data corruptions? Are they fixed
by the attached patch?
--
Manfred
--- 2.6/drivers/net/forcedeth.c 2005-12-19 01:36:54.0 +0100
John W. Linville wrote:
I am now... :-) But, I still don't seem to see any problem. Are there
specific tests I should run?
There are multiple nforce versions - which one do you use?
For example only the most recent one supports 64-bit dma, perhaps
something with the 64-bit code is
34 matches
Mail list logo
