On Fri, 2006-08-18 at 17:41 +0200, Thomas Klein wrote:
Hi Alexey,
first of all thanks a lot for the extensive review.
Alexey Dobriyan wrote:
+ u64 hret = H_HARDWARE;
Useless assignment here and everywhere.
Initializing returncodes to errorstate is a cheap way to prevent
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.
You *should* look at the code :)
So should we be reporting these as
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
affect
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.
You
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 ++---
1
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
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,
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; }
...
int
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
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
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:
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
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
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 function?
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
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)
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 changes
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.34-pre.
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
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
20 matches
Mail list logo
