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);
On Sat, Sep 09, 2006 at 09:10:35AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> >> - one point of critique which applied to many proposals over the years:
> >> multiplexer syscalls a bad, really bad. [...]
> >
> >Can you convince Christoph?
> >I do not care about interfaces, but until seve
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)
>
That should do it.
I think we need those tcpdump af
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
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 a couple of
> minutes).
>
Hi Ben,
The code is a bit tricky. I
> 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 sho
> 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 fr
Jesse, testing without NAPI, will see how it behaves.
Paul Aviles
- Original Message -
From: "Jesse Brandeburg" <[EMAIL PROTECTED]>
To: "Paul Aviles" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, September 05, 2006 12:09 PM
Subject: Re: e1000 Detected Tx Unit Hang
On 9/3/06, Paul Aviles <
John,
Please apply this patch to wireless-2.6. It arises due to an updating
of the PHY initialization routines.
Michael - the same changes will be needed for bcm43xx-d80211.
Thanks,
Larry
===
This patch updates the PHY initialization code for b
Stephen,
After some serious testing, this patch seems to fix the lockup issue
completely. I manually applied these changes against the 2.6.17.13 release.
- Original Message -
From: "Stephen Hemminger" <[EMAIL PROTECTED]>
To: "Jeff Garzik" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, Sept
Hello.
In article <[EMAIL PROTECTED]> (at Sun, 10 Sep 2006 20:10:06 +0300), Diego
Beltrami <[EMAIL PROTECTED]> says:
> as part of this email you can find a patch which introduces the BEET mode
> (Bound
> End-to-End Tunnel) as specified by the ietf draft at the following link:
:
> Signed-off-by
This patch replaces the bunch of arbitrary 64 and 128 bytes alloc_skb() calls
with more accurate allocation sizes.
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
include/net/irda/irlan_common.h | 10 ++-
include/net/irda/irlap_frame.h | 31 +++-
include/net/irda/irlm
With the inclusion of the stir421x code, we now need to select FW_LOADER
whenever we try to build the irda-usb code.
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/irda/Kconfig b/dri
Hi Dave,
We lock the socket when both releasing and getting a disconnected
notification. In the latter case, we also ste the socket as orphan.
This fixes a potential kernel bug that can be triggered when we get the
disconnection notification before closing the socket.
Signed-off-by: Samuel Ortiz
Arnd Bergmann <[EMAIL PROTECTED]> :
[...]
> A few comments on coding style:
Add:
- use netdev_priv()
- use DMA_{32/64}_BIT_MASK in place of private #define
- turn some define into enum ?
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EM
Paolo <[EMAIL PROTECTED]> :
[...]
> Realtek offers the GPL'd driver r1000, v1.04 at present, but seems it's not
> compatible with current 2.6.x kernel at the module param interface.
It is probably not compatible with the kernel developpers at the code
review interface either. :o)
> I've pushed Re
Huh. I assumed crc32_le gave us the result in little endian, but I guess
that's wrong.
I've attached another patch which basically does the same thing but adds some
sparse bitwise annotations to make things clear. Also, it has a signed-off-by
line. :)
d80211: fix WEP on big endian cpus
This p
Corentin CHARY <[EMAIL PROTECTED]> :
[no need to quote the original part in french]
> I have a Asus Laptop A6JC, and a r8168 network card. r1000 driver from
> realtek
> works, but I want to use r8169.c.
> I first tried with
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.17-rc6/r8169/ patchs,
Am Friday 15 September 2006 02:15 schrieb Misha Tomushev:
> VIOC Device Driver provides a standard device interface to the internal
> fabric interconnected network used on servers designed and built by
> Fabric 7 Systems.
>
> The patch can be found at ftp.fabric7.com/VIOC.
We recently had a discus
Jeff Garzik <[EMAIL PROTECTED]> :
> Francois Romieu wrote:
> >The ring_info.len field is not used at all. cp_private.rx_skb is
> >turned into an array of sk_buff *.
> >
> >Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
>
> Need to remove the now-dead struct ring_info.
I should have written "i
On Sun, 10 Sep 2006, Venkat Yekkirala wrote:
> > Is there any way you can send patches without "format=flowed" in the
> > content-type? On two mailers I've tried, the patches get mangled.
>
> Yes. I will send them to you in a few minutes with format=flowed disabled.
> As soon as you let me know
On Sun, Sep 10, 2006 at 11:45:35AM +0400, Dmitry Mishin wrote:
> On Sunday 10 September 2006 06:47, Herbert Poetzl wrote:
> > well, I think it would be best to have both, as
> > they are complementary to some degree, and IMHO
> > both, the full virtualization _and_ the isolation
> > will require a
On Sat, Sep 09, 2006 at 09:41:35PM -0600, Eric W. Biederman wrote:
> Herbert Poetzl <[EMAIL PROTECTED]> writes:
>
> > On Sat, Sep 09, 2006 at 11:57:24AM +0400, Dmitry Mishin wrote:
> >> On Friday 08 September 2006 22:11, Herbert Poetzl wrote:
> >> > actually the light-weight ip isolation runs perf
On Sunday 10 September 2006 19:36, David Kimdon wrote:
> The ICV is transmitted on the network as a 4 byte little endian
> quantity. WEP encryption needs to swap the bytes before transmission
> and decryption needs to swap bytes before ICV verification.
Holy shit, this fixes the bug I am hunting
The ICV is transmitted on the network as a 4 byte little endian
quantity. WEP encryption needs to swap the bytes before transmission
and decryption needs to swap bytes before ICV verification.
Index: wireless-dev/net/d80211/wep.c
==
Hi,
as part of this email you can find a patch which introduces the BEET mode (Bound
End-to-End Tunnel) as specified by the ietf draft at the following link:
http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-06.txt
A BEET mode Security Associations records two pairs of IP addresse
> Is there any way you can send patches without "format=flowed" in the
> content-type? On two mailers I've tried, the patches get mangled.
Yes. I will send them to you in a few minutes with format=flowed disabled.
As soon as you let me know you see them fine, I will resend them to the
lists.
Tha
hi, everybody
my name is Mariusz, I am newbie to linux kernel,
For several weeks I have been writing kernel driver for network card based on
rtl8139c chip. I am writing this driver for micrococontrollers technology
course in my university
I have some problems with DMA, i suppose.
there is a bi
Dmitry Mishin <[EMAIL PROTECTED]> writes:
> On Sunday 10 September 2006 07:41, Eric W. Biederman wrote:
>> I certainly agree that we are not at a point where a final decision
>> can be made. A major piece of that is that a layer 2 approach has
>> not shown to be without a performance penalty.
> B
Hi,
i have a little problem with dlink dwl650+ pcmcia.
After I downloaded wireless-2.6.git with cogito, compiled, rebooted my
laptop and loaded the acx_pci module. But my pcmcia don't work.
If i give this command line:
# iwlist scanning
eth1 Interface doesn't support scanning : Resource tempora
I'm not really an expert, and I didn't understand all your remarks
but I can tell you this:
The driver supplied with 2.6.15 looks like dlink's driver version 1.17.
I had a dlink NIC that got stuck once in a while running that driver.
dlink's version 1.19 is written for 2.4 kernels, so all I did w
On Thu, 2006-09-14 17:15:21 -0700, Misha Tomushev <[EMAIL PROTECTED]> wrote:
> VIOC Device Driver provides a standard device interface to the internal
> fabric interconnected network used on servers designed and built by
> Fabric 7 Systems.
>
> The patch can be found at ftp.fabric7.com/VIOC.
To g
Le samedi 9 septembre 2006 13:24, vous avez écrit :
> Corentin CHARY <[EMAIL PROTECTED]> :
> [...]
>
> > J'ai vu après qu'il y'avais des patchs plus à jour ici
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc5/r8169/ , mais pour
> > 2.6.18.
> >
> > Je me demande donc si il y'a un moyen de
VIOC Device Driver provides a standard device interface to the internal
fabric interconnected network used on servers designed and built by
Fabric 7 Systems.
The patch can be found at ftp.fabric7.com/VIOC.
Misha Tomushev
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
Nick Orlov wrote:
> On Fri, Sep 08, 2006 at 11:29:39PM -0400, Nick Orlov wrote:
>
>>I would like to confirm that issue with netdevice name corruption
>>is still present in 2.6.18-rc6-mm1 and extremely easy to reproduce
>>(at least on my system) with 100% hit rate.
>>
>>All I have to do is 'sudo /e
On Sunday 10 September 2006 07:41, Eric W. Biederman wrote:
> I certainly agree that we are not at a point where a final decision
> can be made. A major piece of that is that a layer 2 approach has
> not shown to be without a performance penalty.
But it is required. Why to limit possible usages?
On Sunday 10 September 2006 06:47, Herbert Poetzl wrote:
> well, I think it would be best to have both, as
> they are complementary to some degree, and IMHO
> both, the full virtualization _and_ the isolation
> will require a separate namespace to work,
[snip]
> I do not think that folks would w
37 matches
Mail list logo
