Hi Alan,
On 07/08/2017 06:21 PM, Alan Stern wrote:
Pardon me for barging in, but I found this whole interchange extremely
confusing...
On Sat, 8 Jul 2017, Ingo Molnar wrote:
* Paul E. McKenney wrote:
On Sat, Jul 08, 2017 at 10:35:43AM +0200, Ingo Molnar wrote:
* Manfred Spraul 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 bigger system this should make a very measurable difference - if
spin_unloc
Hi Paul,
On 07/06/2017 01:31 AM, Paul E. McKenney wrote:
From: Manfred Spraul
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_locks_all needs ACQUIRE memory
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
Cc: Alan Stern
---
ipc/sem.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/ipc/sem.
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
lowed 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
Cc: Andrew Morton
Cc: Davidlohr Bueso
Cc: Manfred Spraul
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Alan Stern
Cc: Andrea
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 INT
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 wo
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 MSI/INTx/
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 handle
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 for
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, and
Andreas Kleen wrote:
No idea, but unlikely. The fix removes a duplicate request_irq call.
Is
it possible that the both instances run concurrently?
The system has two Forcedeth ports, but only one has a cable connected.
I don't think there is any parallelism. Just one connection with a lot
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 drive
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 w
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
AIL 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:
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
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:
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 spin_loc
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 all
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:
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
th
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);
+ } e
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 unsubs
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 ad
.
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
@@ -
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 t
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 162
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 sla
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?
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: "p
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 broken
35 matches
Mail list logo
