> card->low_watermark->next->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
> mb();
> card->low_watermark->dmac_cmd_status &= ~SPIDER_NET_DESCR_TXDESFLG;
> card->low_watermark = card->low_watermark->next;
>
> when we queue another frame for TX.
I would have expected those to be racy vs. the hardw
Hello,
I'm trying to properly handle pci_enable_device() errors in the resume
routines of a couple of tulip drivers. I noticed that several drivers
pay attention to errors from pci_enable_device() in the init routine
but ignore it on resume; other drivers vary wildly. What's proper
behavior when
Rik van Riel wrote:
Andrew Morton wrote:
- We expect that the lots-of-dirty-anon-memory-over-swap-over-network
scenario might still cause deadlocks.
I assert that this can be solved by putting swap on local disks.
Peter
asserts that this isn't acceptable due to disk unreliability. I
On Sun, Aug 20, 2006 at 02:05:20AM +0200, Michael Buesch wrote:
> On Sunday 20 August 2006 01:48, Willy Tarreau wrote:
> > On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote:
> > > Willy,
> > >
> > > I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
> > > into 2.4.
On Sunday 20 August 2006 01:48, Willy Tarreau wrote:
> On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote:
> > Willy,
> >
> > I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
> > into 2.4.34-pre.
> >
> > (2.6 kernels could benefit from the same change, too, but a
On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote:
> Willy,
>
> I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
> into 2.4.34-pre.
>
> (2.6 kernels could benefit from the same change, too, but at the moment
> I am dealing with proper submission of generic chang
Willy,
I propose the attached patch (extracted from 2.4.33-ow1) for inclusion
into 2.4.34-pre.
(2.6 kernels could benefit from the same change, too, but at the moment
I am dealing with proper submission of generic changes like this that
are a part of 2.4.33-ow1.)
The patch makes getsockopt(2) sa
[EMAIL PROTECTED] wrote:
From: Andrew Morton <[EMAIL PROTECTED]>
WARNING: drivers/net/ni52.o - Section mismatch: reference to
.init.text:ni52_probe from .text between 'init_module' (at offset 0x997) and
'ni52_close'
WARNING: drivers/net/ni65.o - Section mismatch: reference to
.init.text:ni65_
patch updated: It seems for me e1000_power_down_phy() should be added to
rollbacke1000_power_up_phy().
I know, currently e1000_up() always return success. But this behaviour may be
changed in future...
Andrew,
could you please use attached patch instead previous version?
---
irq leak was found in
Hello Joe,
Joe Perches wrote:
> On Fri, 2006-08-18 at 19:02 +0400, Vasily Averin wrote:
>>Memory leak was found in 2.6.18-rc4 and e1000 7.2.7 from sourceforge:
>>We should free resources allocated for previous rings if following allocation
>>fails.
>
> Did you read the comment headers in the fun
d80211: Group EIDs by standard, add remaining 802.11d EIDs
This patch groups EIDs together by the 802.11 standard they were introduced in
and adds the remaining 802.11d EIDs. The spec where the QoS EID was
introduced still needs to be found. (does not appear to be 802.11e..) This
patch depends
Hi John,
Please apply this to wireless-dev.
--
hard_start_xmit should return a NETDEV_TX_FOO error code.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
On 8/18/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
I assert that this can be solved by putting swap on local disks. Peter
asserts that this isn't acceptable due to disk unreliability. I point
out that local disk reliability can be increased via MD, all goes quiet.
A good exposition w
John,
Please apply the following patch by Michael Buesch to wireless-2.6.
Larry
==
hard_start_xmit should return a NETIF_TX_FOO error code.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-2.6/driv
Andrew Morton wrote:
- We expect that the lots-of-dirty-anon-memory-over-swap-over-network
scenario might still cause deadlocks.
I assert that this can be solved by putting swap on local disks. Peter
asserts that this isn't acceptable due to disk unreliability. I point
out that loc
Andy Gay wrote:
fs/bio.c:169: warning: 'idx' may be used uninitialized in this function
fs/eventpoll.c:500: warning: 'fd' may be used uninitialized in this function
fs/isofs/namei.c:162: warning: 'offset' may be used uninitialized in this
function
fs/isofs/namei.c:162: warning: 'block' may be us
On Saturday 19 August 2006 10:41, Michael Ellerman wrote:
> A lot of these have started appearing recently, which I think is due to
> GCC becoming more vocal. Unfortunately many of them are false positives
> caused by GCC not seeming to grok that this is ok:
>
> void foo(int *x) { *x = 1; }
> ...
On Sunday 20 August 2006 03:31, Stephen Hemminger wrote:
>
> The reason reclaim via poll() is efficient is because it avoid causing a
> softirq that is
> necessary when skb_free_irq() is done. Instead it reuses the softirq
> from the poll() routine.
Ok, I completely missed this point so far, t
Hi,
I am currently wondering, if we should use NETDEV_TX_LOCKED
in the bcm43xx wireless net driver.
I currently don't have an SMP machine with a bcm43xx card
running, so I can't use benchmarks to find out.
There are various things to consider:
* The RX and TX-status paths, which also must take t
Jesse Huang <[EMAIL PROTECTED]> :
> From: Jesse Huang <[EMAIL PROTECTED]>
>
> This is only coding style modify for ipg_config_autoneg(). Thanks for the
> suggestion form Francois.
>
> Change Logs:
> Modify coding style of ipg_config_autoneg()
>
> ---
>
> drivers/net/ipg.c | 17 ++
On Sat, 2006-08-19 at 02:48 -0400, Andy Gay wrote:
> On Sat, 2006-08-19 at 16:18 +1000, Michael Ellerman wrote:
>
> >
> > If you try to return an uninitialized value the compiler will warn you,
> > you'll then look at the code and realise you missed a case, you might
> > save yourself a bug.
>
On Fri, 18 Aug 2006 21:14:09 -0700
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> So rather than just the word deadlock, let us add "or atomic 0 order
> alloc failure during TCP receive" to the challenge. Fair?
If it's significantly performance-affecting in any way which is at all likely
to
affe
22 matches
Mail list logo
