Jumping on an old train ...
On Wed, 2007-09-12 at 05:50 -0700, David Miller wrote:
This would mean we have a problem on all SMP machines right now.
This is not a correct statement.
Only on your platform do network device interrupts get moved
around, no other platform does this.
On Tue, 2007-10-16 at 14:06 +0800, Herbert Xu wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Note: I use msleep_interruptible(1); just like napi_disable(). However
I'm not too happy that the hot loop that results of a pending signal
here will spin without even a cpu_relax
So the powerpc platform just honors the affinity mask, and depending on
the PIC does things that range from nothing to spreading interrupts to
CPUs in the affinity mask.
All interrupts by defaults are spread to all CPUs (full balancing).
At this stage, it's afaik userland business to
On Tue, 2007-10-16 at 00:44 -0700, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 16 Oct 2007 17:29:47 +1000
Do you have any pointer to how that is done on x86 or sparc64 ?
Sparc64 does it statically in the kernel.
For x86, see http://irqbalance.org
On Tue, 2007-10-16 at 01:31 -0700, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 16 Oct 2007 18:28:56 +1000
Allright, so that's an out of tree userland thingy... (which may well
work on ppc too I suppose). Definitely not installed by default by my
distro
So this is really just like synchronize_irq()? Using msleep is bogus
because you want to spin, you are only waiting for a softirq on the other
cpu to finish. If you wait for a whole millisecond and sleep that
is far longer than the napi routine should take.
You could even optimize it like
On Tue, 2007-10-16 at 15:16 -0700, David Miller wrote:
And it's unfortunately buggy.
For example, the sky2_suspend() code iterates over the ports
and calls sky2_down() on each one that is up.
That will call napi_disable() on the same NAPI instance if
multiple ports are up, and thus hang
On Tue, 2007-10-16 at 21:16 -0400, Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
net: Fix new EMAC driver for NAPI changes
This fixes the new EMAC driver for the NAPI updates. The previous patch
by Roland Dreier (already applied) to do that doesn't actually work. This
applies
napi: use non-interruptible sleep in napi_disable
The current napi_disable() uses msleep_interruptible() but doesn't
(and can't) exit in case there's a signal, thus ending up doing a
hot spin without a cpu_relax. Use uninterruptible sleep instead.
Signed-off-by: Benjamin Herrenschmidt [EMAIL
\
Note: unfortunately, Jeff already picked up the EMAC patch without
waiting for this to be sorted out (oops...). So if you agree with
this patch, it would be nice to have it go in quickly or maybe via
Jeff's tree to avoid breakage ? Not terribly important tho.
Sorry, I thought that
On Fri, 2007-10-12 at 17:04 +0400, Valentine Barshak wrote:
Fix build RGMII error: use of_device_is_compatible()
insteadof now deprecated device_is_compatible() function.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers
On Mon, 2007-10-15 at 14:53 -0400, Jeff Garzik wrote:
Roland Dreier (2):
ibm_new_emac: Nuke SET_MODULE_OWNER() use
ibm_emac: Convert to use napi_struct independent of struct
net_device
Wow, I'd have loved to be CCed at least on the last one since I was
about to do just that
On Mon, 2007-10-15 at 15:04 -0400, Jeff Garzik wrote:
I would ideally like a single active patch generator (even if they
are
merely reviewed others work sometimes).
Outside of that, I'm hoping you and the other people listed making
changes will self-organize without my help :)
Josh, do
:-)
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
If the approach is accepted, I would like to have this merged now
so the EMAC patch to make it work again can follow :-)
Note: I use msleep_interruptible(1); just like napi_disable(). However
I'm not too happy that the hot loop
__napi_sycnhronize() to sync with napi poll
posted previously.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
The old EMAC driver does things a bit differently (doesn't do useful
locking :-) and seems to work with Roland patch. So I'm not going to
touch it unless somebody reports me that it has
Hi Stehphen !
The new netif_napi_add() function takes a netdev argument. In the EMAC
case, there is one NAPI instance working on behalf of multiple netdev's,
so that isn't very useful. For my EMAC patch (just posted to you the
list), I'm not passing NULL, but I'm wondering what would be a good
:-)
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
(Use correct address for Stephen this time)
If the approach is accepted, I would like to have this merged now
so the EMAC patch to make it work again can follow :-)
Note: I use msleep_interruptible(1); just like napi_disable
On Sun, 2007-10-14 at 09:15 +0200, Manfred Spraul wrote:
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
On Sun, 2007-10-14 at 16:15 -0700, Yinghai Lu wrote:
On 10/14/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Sun, 2007-10-14 at 09:15 +0200, Manfred Spraul wrote:
Yinghai Lu wrote:
On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote:
Someone around with a MSI capable
On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
A key problem I was hoping would be solved with your work here was
the
elimination of that post dma_map_sg() split.
If I understood James and Ben correctly, one of the key problems was
always in communicating libata's segment boundary
On Thu, 2007-09-27 at 03:49 -0400, Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
A key problem I was hoping would be solved with your work here was
the
elimination of that post dma_map_sg() split.
If I understood James and Ben
On Wed, 2007-07-25 at 02:14 -0500, Kumar Gala wrote:
I'm seeing the following warning:
WARNING: vmlinux.o(.init.text+0x1acdc): Section mismatch: reference to
.exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init')
I don't understand why its not ok to access .exit.text from
Here's a delusional reply: I didn't see any point to it.
1) a wmb would add overhead
2) the hardware is supposed to be looking at the status flag,
anyway, and not misbehaving.
3) there is a wmb when the descr is actually refilled in such
a way as to actually mean something to the
I do not know why sk_buff-head would be null, or
would be set in a racy kind of way, or why the rt patches
would cause this. But the evidence implicates that.
Would it be possible that a locking bug in spidernet would cause it
under some circumstances to get a stale skb pointer ?
Ben.
-
To
Geoff, I suspect gelic_net might have the same problem...
Cheers,
Ben.
On Fri, 2007-03-02 at 18:39 +0100, Norbert Eicker wrote:
On Fri 2.3.2007 00:34, Linas Vepstas wrote:
On Thu, Mar 01, 2007 at 04:52:54PM -0600, Chris Engel wrote:
I tried to apply this patch to 2.6.21-rc2 and CHECKSUM_HW
On Sat, 2007-03-03 at 04:06 +0100, Andi Kleen wrote:
Jan-Bernd Themann [EMAIL PROTECTED] writes:
Are there any concerns about this approach?
Yes. You should fix the NAPI code instead of trying to work
around it.
NAPI is being fixed but the fix will take time to get in. In the
meantime,
+static int bcm5461_enable_fiber(struct mii_phy* phy, int autoneg)
+{
+ /* select fiber mode, enable 1000 base-X registers */
+ phy_write(phy, MII_NCONFIG, 0xfc0b);
+
+ if (autoneg) {
+ /* enable fiber with no autonegotiation */
+ phy_write(phy,
reasonable. Thus
Acked-by: Linas Vepstas [EMAIL PROTECTED]
I'm somewhat unclear as to whethr I should be doing
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
If the patch wasn't actually handled and passed-on by you or modified by
you, then no. Acked-by is the way to go.
Acked-by: Benjamin
On Wed, 2007-02-07 at 17:15 -0500, Jeff Garzik wrote:
Ishizaki Kou wrote:
This is a revised spidernet patch set based on
netdev-2.6.git#upstream.
This patch set is merged Jens-san's spidernet patch and works on
Toshiba Cell reference set (aka Celleb).
It requires Jens-san's phy
On Thu, 2007-02-01 at 12:04 +0100, Jens Osterkamp wrote:
Ishizaki-san,
This patch partially works on celleb but remains
following several problems.
1. It doesn't recover once an ethernet cable which is
connected to a spider_net card is unpluged.
My understanding is that you are
We use bcm5461. There is a possibility that we don't know the appropriate
setting which is applicable for both type of switches.
Have you tested the existing 54xx code in sungem_phy.c ? We use that
with 5462 at least in K2 and all sorts of 54xx chips and it works
fine... Just setup the right
We need to use different auto-neg initial settings between
for 10/100Mbps ethernet switches and for Gbps ethernet switches.
That is strange ! What PHY chip are you using ? Are you sure it's not
just you not properly configuring the PHY ? Is the datasheet for the PHY
available somewhere ?
On Fri, 2007-01-26 at 14:09 +0100, Jens Osterkamp wrote:
This patch modifies the patch submitted by Kou Ishizaki to make it work on the
blade (http://marc.theaimsgroup.com/?l=linux-netdevm=116593424505539w=2).
Unfortunately I dont have access to a Celleb so I cannot test it there.
The basic
On Fri, 2007-01-26 at 14:07 +0100, Jens Osterkamp wrote:
This patch adds improved version of enable_fiber for both the 5421 and
the 5461 phy. It is now possible to specify with these wether you want
autonegotiation or not. This is needed for bladecenter switches where
some expect
On Wed, 2007-01-17 at 19:00 +0900, Ishizaki Kou wrote:
Dear everyone,
This is a revised version of the patch set for spider_net driver
that works on Toshiba Cell Refererence Set (aka Celleb).
This patch set is based on netdev-2.6.git#upstream.
Jens, can you give that a go on our blades
On Tue, 2007-01-16 at 09:39 -0700, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
With unique sysctl binary numbers setting insert_at_head is pointless.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED
On Tue, 2007-01-16 at 09:39 -0700, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
And make the mode of the kernel directory 0555 no one is allowed
to write to sysctl directories.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Acked-by: Benjamin
On Tue, 2007-01-16 at 09:39 -0700, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This was partially done already and there was no ABI breakage what
a relief.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL
On Thu, 2007-01-04 at 21:57 +0100, Eric Lemoine wrote:
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
From: Eric Lemoine [EMAIL PROTECTED]
Date: Thu, 4 Jan 2007 21:06:48 +0100
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
I've applied that patch, thanks.
David, I suppose
, it shouldn't be very hard to add in a subsequent patch.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
(Applies on top of Eric's locking patch)
Index: linux-work/drivers/net/sungem_phy.c
===
--- linux-work.orig/drivers/net
Thanks for finding these bugs, although that's really strange pause
behavior you are seeing on your switches.
By default, we advertise PAUSE but not ASYM PAUSE in the tg3 driver,
and I get flow control on every switch I have here.
Yeah, that's strange. I still have the debug values at
there, I suppose I should read a bit more
802.3 references, and I don't now what sungem is capable of, but I
noticed the PCS code (originated from you) does the same.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
(Applies on top of Eric's locking patch)
This version advertise pause
The one with only asym. support is a big Cisco Catalyst 3350 (well.. big
but not that many ports :-)
Ok, I got in the config of the switch with somebody who knows how to
speak ciscong, and it seems that it defaults to flow control desired
for send and off for receive on all ports, which means
On Thu, 2006-12-28 at 21:05 -0800, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Wed, 13 Dec 2006 15:07:24 +1100
tg3 says
tg3: eth0: Link is up at 1000 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
but sungem says
eth0
Great! At last glance, only gianfar, fs_enet, and au1000_eth. There
are one or two others that haven't gone in, yet. My hope is that
your changes will not require any changes to the drivers, but I'll
leave that to your discretion.
Unfortunately, it will probably have an impact on
On Thu, 2006-12-28 at 21:09 -0800, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Wed, 20 Dec 2006 14:44:12 +1100
I stumbled accross what might be a bug on out of order architecture:
netif_poll_enable() only does a clear_bit(). However,
netif_poll_disable
On Fri, 2006-12-22 at 10:24 -0500, David Hollis wrote:
On Fri, 2006-12-22 at 15:07 +1100, Benjamin Herrenschmidt wrote:
Hi Andy !
I've been looking at porting various drivers (EMAC, sungem,
spider_net, ...) to the generic PHY stuff. However, I have one
significant problem here
Hi Andy !
I've been looking at porting various drivers (EMAC, sungem,
spider_net, ...) to the generic PHY stuff. However, I have one
significant problem here.
One of the things I've been trying to do lately with EMAC and that I
plan to do with others, is to have the PHY polling entirely operate
Hi !
I stumbled accross what might be a bug on out of order architecture:
netif_poll_enable() only does a clear_bit(). However,
netif_poll_disable/enable pairs are often used as simili-spinlocks.
(netif_poll_enable() has pretty much spin_lock semantics except that it
schedules instead of
Thanks for testing this stuff.
I'll take a look at the pause-enabling issue in the sungem
drive then work on integrating Eric's patch.
Ok, thanks.
Probably we'll need to put this in post-2.6.20 as the merge
window is closed.
Yup, no hurry there.
Ben.
-
To unsubscribe from this list:
On Tue, 2006-12-12 at 06:49 +0100, Eric Lemoine wrote:
On 12/12/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Tue, 2006-12-12 at 06:33 +0100, Eric Lemoine wrote:
On 12/12/06, David Miller [EMAIL PROTECTED] wrote:
[...]
Anyways, Eric your changes look fine as far as I can
On Wed, 2006-12-13 at 15:46 -0800, Stephen Hemminger wrote:
Split off NAPI part from network device, this patch is build tested
only! It breaks kernel API for network devices, and only three examples
are fixed (skge, sky2, and tg3).
1. Decomposition allows different NAPI - network device
On Wed, 2006-12-13 at 11:35 -0800, Stephen Hemminger wrote:
Could we split off the NAPI context part of network_device instead?
I'll work up something for 2.6.21.
That would do the trick too... though I prefer not putting my hands in
network_device too much myself :-)
Ben
-
To unsubscribe
On Wed, 2006-12-13 at 14:12 +1100, Benjamin Herrenschmidt wrote:
Been hitting a raw throughput in both directions plus a few other things
on a dual G5 and the driver didn't crash :-)
I'm seeing a problem though but I'm not sure it's related to your patch,
I'll have to test without
On Tue, 2006-12-12 at 19:14 -0600, Linas Vepstas wrote:
On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote:
Following are the changes.
-This patch enables auto-negotiation.
-Loading firmware is done when spidernet_open() is called.
-And this patch adds other several small
Been hitting a raw throughput in both directions plus a few other things
on a dual G5 and the driver didn't crash :-)
I'm seeing a problem though but I'm not sure it's related to your patch,
I'll have to test without it.
Basically, if I use a slightly modified versio of tridge's socklib (raw
On Tue, 2006-12-12 at 20:03 -0800, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Wed, 13 Dec 2006 14:12:13 +1100
David, could that be the pause stuff not working properly ?
It could be, but if the tg3 says flow control is up in the kernel logs
things ought
(if we want them at all).
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
I'm shit at inventing function names so feel free to come up with
something nicer !
Index: linux-cell/drivers/net/ibm_emac/ibm_emac_mal.c
===
--- linux
On Tue, 2006-12-12 at 06:33 +0100, Eric Lemoine wrote:
On 12/12/06, David Miller [EMAIL PROTECTED] wrote:
[...]
Anyways, Eric your changes look fine as far as I can tell, can you
give them a really good testing on some SMP boxes?
Unfortunately I can't, I don't have the hardware (only an
A spinlock is expensive in the fast path, which is why Jeff says it's
invasive.
spider_net_decode_one_descr() is called from
spider_net_poll() (which is the netdev-poll callback)
and also from spider_net_handle_rxram_full().
The rxramfull routine is called from a tasklet that
is fired off
On Thu, 2006-12-07 at 02:22 -0800, Eugene Surovegin wrote:
On Thu, Dec 07, 2006 at 02:20:10AM -0800, David Miller wrote:
It also just occured to me that even if you use the dummy device
approach, it's the dummy device's quota that will be used by the
generic -poll() downcall into the
Hi Dave !
I'd like your advice on something we need to deal with in the EMAC
ethernet driver (an IBM part). The driver is maintainedby Eugene (CC'd),
I'm mostly adding support for some new hardware at this point, which
involves making it SMP safe among other things ;-)
So the problem this driver
What Eugene does currently, which seems to me like it's actually the
only proper solution, is to create a separate net_device structure for
the DMA engine and thus have a single NAPI poll weighting for all the
EMACs sharing a given MAL (MAL is the name of that DMA engine). This
means that
On Fri, 2006-09-15 at 16:15 -0400, Amy Fong wrote:
[PATCH] Add Broadcom PHY support
This patch adds a driver to support the bcm5421s and bcm5461s PHY
Kernel version: linux-2.6.18-rc6
Signed-off-by: Amy Fong
Some 5421's need special initialisation (see drivers/net/sungem_phy.c),
might
I believe that this fiber enabling can be done by defining config_init in the
phy_driver struct.
struct phy_driver {
snip
/* Called to initialize the PHY,
* including after a reset */
int (*config_init)(struct phy_device *phydev);
snip
};
Well... I don't know for
On Tue, 2006-11-28 at 15:43 -0800, David Miller wrote:
At least in theory the atomic + any necessary memory barriers
would be cheaper than the extra PIO read we need otherwise.
Yes, IO reads are generally the worst case scenarios even on machines
with fairly slow locks.
Ben.
-
To
On Fri, 2006-11-17 at 08:53 +0100, Johannes Berg wrote:
On Fri, 2006-11-17 at 18:46 +1100, Benjamin Herrenschmidt wrote:
So what is the solution for Apple machines owner who only get a v3
firmware from Apple ? I remember you telling me the answer on irc but I
wanted to make it public
On Thu, 2006-11-16 at 15:07 +0100, Michael Buesch wrote:
This fixes various bcm43xx-d80211 hwcrypto issues,
which mainly prevented mcast frames from being decrypted properly.
This is mostly a rewrite of the key managing code.
Note that after this patch v3 firmware is no longer supported.
So
Yes, the bit 4 isn't used, but I assumed clearing it shouldn't be prolem.
Always leave reserved bits alone ... I agree it's very unlikely in this
case that it could cause a problem but I've seen stranger things
Ben.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
That's ugly too imho but I suppose I can do it :-)
I generally think it's a bug in the kernel-wide API, if use of said API
requires arch-specific ifdefs.
Yes. I agree. In that specific case, I
This is why I said good enough for drivers. This is _key_.
I have run into several [PCI] devices with 64-bit registers, and
__none__ of them had requirements such that the Linux platform code
-must- provide an atomic readq/writeq. Probably because everybody wants
to support 32-bit
On Mon, 2006-11-06 at 01:37 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Jeff Garzik wrote:
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
Heartily agreed. MUCH better than adding unrelated #if defined() stuff,
whether arch-related
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My arch guy side screams at the idea, but if,
indeed, drivers generally cope fine
On Mon, 2006-11-06 at 04:55 -0500, Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My
Generally the kernel code should write the two 32-bit chunks to the
memory-mapped region in order (low dword first), and let things take
care of themselves from there.
That's pretty much the implementation that -every- driver copies, when
they need readq/writeq to work on a 32-bit
On Sun, 2006-11-05 at 14:00 +0100, Eric Lemoine wrote:
Hi!
Some (long) time ago benh wrote a blaming comment in sungem.c about
that driver's locking strategy. That comment basically says that we
probably don't need two spinlocks.
Yeah :) Note that I mostly blamed myself there ... Just never
accessors which will break that test. This fixes it. I
don't have anything less ugly at hand unfortunately.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
The patch changing ppc64 own definition is scheduled to go in 2.6.20 when
the merge window opens, so it would be nice if this patch
On Thu, 2006-10-19 at 17:29 +0200, Michael Buesch wrote:
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus
On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
From: Jesse Huang [EMAIL PROTECTED]
Change Logs:
For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent
is cut-through patent. If use this function, Tx will start to transmit after
few data be move in to Tx FIFO.
On Tue, 2006-10-10 at 18:20 -0500, jschopp wrote:
Linas Vepstas wrote:
The current driver code performs 512 DMA mappns of a bunch of
32-byte structures. This is silly, as they are all in contiguous
memory. Ths patch changes the code to DMA map the entie area
with just one call.
I started writingthe patch thinking it will have some huge effect on
performance, based on a false assumption on how i/o was done on this
machine
*If* this were another pSeries system, then each call to
pci_map_single() chews up an actual hardware translation
control entry (TCE) that
On Wed, 2006-09-27 at 17:26 +0200, Michael Buesch wrote:
This fixes some race conditions in the WirelessExtension
handling and association handling code.
Unlike the previous patch, this one doesn't apply on top of 2.6.18
(which I'm using as a basis for testing, along with Larry big bcm43xx
On Wed, 2006-09-27 at 19:50 +0200, Michael Buesch wrote:
On Wednesday 27 September 2006 18:18, Larry Finger wrote:
Michael Buesch wrote:
This fixes some race conditions in the WirelessExtension
handling and association handling code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
On Wed, 2006-09-27 at 19:43 -0500, Larry Finger wrote:
Benjamin Herrenschmidt wrote:
I won't try some random other git tree to test things, it's simply not
feasible for me and we need something we can give to distros to backport
so they have something remotely stable (I'm thinking
yes. Many locking issues in d80211 to still sort out. Basically, there
are next to no useful locks in it and most data structures are not
protected at all.
Doh ! Scary... locking is hard ... if the stuff was written without
locking in mind in the first place, it might end up being a
On Mon, 2006-09-25 at 20:07 -0400, Jeff Garzik wrote:
patch does not apply.
also, it would seem like varargs would be appropriate here.
Not really... these are hypervisor calls, their calling convention is
not varargs, thus we would need some conversion layer if using them,
with possible
prism54 fullmac, right?
Yes.
Try using -Dwext; the prism54 wpa_supplicant driver is a dead-end and I
added WE-19 commands to it a bit ago anyway. Oddly enough, I couldn't
seem to get the driver to work reliably for me using straight WEP
either, let alone WPA. It's pretty unmaintained at
On Sat, 2006-09-23 at 23:45 -0400, Daniel Drake wrote:
Benjamin Herrenschmidt wrote:
Oh and I don't care about it works in dscape stack sort of crap I
regulary get. I want something that
works with upstream kernels. That isn't that much to ask... or is it ?
wpa_supplicant triggers races
So what are the chances of getting this dscape stack merged, let's
say... for 2.6.19 ? Or we'll get yet another full release with barely
working wireless ?
I don't think it's possible to happen for 2.6.19.
Ealiest 2.6.20 but likely one or two releases later (me thinks).
Which means
On Sun, 2006-09-24 at 10:43 +0200, Michael Buesch wrote:
On Sunday 24 September 2006 10:12, Benjamin Herrenschmidt wrote:
So what are the chances of getting this dscape stack merged, let's
say... for 2.6.19 ? Or we'll get yet another full release with barely
working wireless
Hi folks !
So this is 2.6.18 + Larry fix (though I've seen this problem before,
it seems using WPA just make it happen more often).
This is also a 4318, so the link is pretty weak due to the Tx Power
problem and I suspects it makes the driver problems more visible...
So basically, I lose the
However, I presume someone added the __powerpc__ define here
because they picked up a 3c509 at a garage sale, stuck it in
a powerpc, found out it didn't work due to a byte-swapping bug,
and then patched it as above. I'm disturbed that somehow
outsl_ns() became identical to outsl() at some
On Tue, 2006-09-19 at 20:52 +0200, Matt Sealey wrote:
Some northbridges and PCI bridges have clever byteswapping in
hardware, maybe this is just an effect of that. In theory depending on
the host bridge, you should pass in big endian data and have it swap or
not swap, not pick that way in
On Wed, 2006-09-20 at 02:21 +0200, Segher Boessenkool wrote:
Nah. We have the basic rule that readl/writel are little endian.
PowerPC
additionally provides arch specific low level in_{be,le}32 type
accessors with explicit endianness. Or you can also use
cpu_to_le32/le32_to_cpu kind of
Ok, it seems like we might have more than just the missing barrier in
TG3. Possibly some IOMMU problems on some machines as well.
Unfortunately, I don't have a tg3 on a PCI-X or PCI-E card to test on a
pSeries or some other machine.
[Olof: I've disabled the new U4 DART invalidate code (reverted
On Sun, 2006-09-10 at 22:33 -0700, Michael Chan wrote:
Benjamin Herrenschmidt wrote:
I've done:
#define tw32_rx_mbox(reg, val) do { wmb();
tp-write32_rx_mbox(tp, reg, val); } while(0)
#define tw32_tx_mbox(reg, val) do { wmb();
tp-write32_tx_mbox(tp, reg, val); } while(0
But funky cascading using chained flow handlers doesn't work if the cascade
must share an IRQ with some other device, right?
Indeed. Best way there is then to have a normal action handler like you
do and have it call generic_handle_irq() on the cascaded interrupts.
Ben.
-
To unsubscribe
Oh, we know about this. The powerpc writel() used to have memory
barriers in 2.4 kernels but not any more in 2.6 kernels. Red Hat's
version of tg3 has extra wmb()'s to fix this problem. David doesn't
think that the upstream version of tg3 should have these wmb()'s, and
the problem should
On Sun, 2006-09-10 at 22:18 -0700, Michael Chan wrote:
Benjamin Herrenschmidt wrote:
I've added a wmb() in tw32_rx_mbox() and tw32_tx_mbox() and can still
reproduce the problem. I've also done a 2 days run without TSO enabled
without a failure (my test program normally fails after
On Sat, 2006-09-09 at 02:22 -0700, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Sat, 09 Sep 2006 07:46:02 +1000
I don't think that in general, you have ordering guarantees between
cacheable and non-cacheable stores unless you use explicit barriers.
In fact
301 - 400 of 443 matches
Mail list logo
