[from the nitpick department..]
Hi Jeff, hi Scott,
Adrian wrote:
The Coverity checker spotted the following two array overflows in
drivers/net/chelsio/sge.c (in both cases, the arrays contain 3
elements):
Am Freitag, 17. März 2006 01:21 schrieb Jeff Garzik:
Scott Bardone wrote:
Adrian,
Hi,
in smctr.c request_region() return value is not always checked.
Here is a simple patch to fix it.
Patch is against 2.6.16-rc6-git8.
Please CC me on replies,
Regards.
Signed-off-by: Laurent Wandrebeck [EMAIL PROTECTED]
--- linux-2.6.16-rc6/drivers/net/tokenring/smctr.c.ori 2006-03-11
subcribe netdev
-
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
On Fri, 2006-17-03 at 09:24 +1000, Russell Stuart wrote:
On Thu, 2006-03-16 at 08:51 -0500, jamal wrote:
BTW, in this example, the new hash I suggested would be as good
as the 2.6 case.
Yes, if you used 256 buckets per hash table ;-
No - you haven't understood what the new
[1.] One line summary of the problem:
System freezes when changing MAC address
[2.] Full description of the problem/report:
When I try to change the MAC address of my Broadcom BCM4401-B0
ethernet card without having activated the network interface
first, my system
Stephen Hemminger wrote:
On Wed, 15 Mar 2006 20:13:01 -0800
Skunk Worx [EMAIL PROTECTED] wrote:
Hello,
I've taken a performance hit over localhost between kernels 2.6.14 and
2.6.15 in my client/server application.
This came up with java debugging already. The problem is when the sender
Don Fry wrote:
I get the same results in my testing. Good catch on the coding error
for ecmd.transciever. Without adding some more specific code to support
the Allied Telesyn cards I don`t know how to get things to work without
using ethtool.
Maybe someone else has a better idea.
Here is
This project is stopped due to impossibility to compete with synchronous
buffered reading. Analysis below.
The maximum achieved results are 2100 Mb/s for buffered reading vs.
2000 Mb/s for AIO with the same CPU usage on 2.4 Ghz Xeon with 1Gb RAM
and ext3 filesystem.
Actually both cases are
This is second part of kevent based AIO reading implementation.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/include/linux/kevent.h b/include/linux/kevent.h
index 376fedc..521119e 100644
--- a/include/linux/kevent.h
+++ b/include/linux/kevent.h
@@ -27,12 +27,14 @@
*/
Skunk Worx wrote:
Rick Jones wrote:
From strace :
15:27:04.568800 recv(3, ?xml version=\1.0\ encoding=\UT...,
555, ) = 555 0.000121
vs.
15:18:24.515891 recv(3, ?xml version=\1.0\ encoding=\UT...,
566, ) = 566 0.038414
Will watch replies and post more when I know more. Kinda new at
I am curious about why this is seen only on loopback. Over ether, with
client and server on two machines, there is no 40ms. ack penalty. If
anything, I would expect to see things the other way around--penalty on
ether, no penalty on loopback.
What is the MTU of the loopback interface? The
On Fri, 2006-03-17 at 16:41 +0100, Philipp Kohlbecher wrote:
[1.] One line summary of the problem:
System freezes when changing MAC address
I think the MAC core cannot be accessed until it is powered up on some
of the 4401 chips. Register reads will never complete. I'll ask someone
to
Thanks Pete,
This is correct, the array should contain 3 elements. The bug was we were
accessing a 4th element ([3]) which did not exist. We should be modifying the
last element ([2]) instead.
-Scott
Hans-Peter Jansen wrote:
[from the nitpick department..]
Hi Jeff, hi Scott,
Adrian
On Sun, Mar 05, 2006 at 01:46:26AM +0100, Andreas Happe wrote:
Add the following config entries for the ipw2200 driver to
drivers/net/wireless/Kconfig
* IPW2200_MONITOR
enables Monitor mode, as this seems to generate lots of firmware errors
it depends upon BROKEN
*
On Wed, Mar 08, 2006 at 12:59:14PM +, Christoph Hellwig wrote:
+ if (unlikely(status-frame_size skb_tailroom(packet-skb) -
sizeof(struct ipw_rt_hdr))) {
please don't spill over 80 characters.
#include net/ieee80211.h
+#ifdef CONFIG_IPW2100_MONITOR
+#include
On Fri, Mar 17, 2006 at 05:13:24PM +0100, Seewer Philippe wrote:
OK. applied it to 2.6.16-rc6. applies and works flawless. The new
check_media function is subjectively slower than the older code without
it but thats all I found.
Tested with AT 2700FTX and 2701FTX. Both work and can be
Overall, if this were a class assignment I would give it a C- if I was
feeling generous. It tries to follow the linux driver style, but it
really needs more work and is incomplete at this time.
* The most troublesome design flaw seems to be that the hardware knows
about the ip_address. Well, if
Don Fry wrote:
On Fri, Mar 17, 2006 at 05:13:24PM +0100, Seewer Philippe wrote:
OK. applied it to 2.6.16-rc6. applies and works flawless. The new
check_media function is subjectively slower than the older code without
it but thats all I found.
Tested with AT 2700FTX and 2701FTX. Both
The following changes since commit dd288e7d75b9041f79fecae77d61cfa345da7266:
John W. Linville:
Merge branch 'upstream-fixes'
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
Adrian Bunk:
On Tue, Feb 28, 2006 at 09:48:28AM -0600, Larry Finger wrote:
As stated in a comment, the ipw2200 driver uses several routines that were
borrowed from ieee80211_geo.c. As ipw2200 requires ieee80211, these
routines are duplicated. The attached patch, which is sent as an attachment
to
On Wed, Mar 08, 2006 at 12:23:14PM +0800, Zhu Yi wrote:
[PATCH 1/6] ipw2x00: expend Copyright to 2006
[PATCH 2/6] ipw2100: add radiotap headers to packtes captured in monitor mode
[PATCH 3/6] ipw2100: Fix radiotap code gcc warning
[PATCH 4/6] ipw2100: semaphore to mutexes conversion
[PATCH
On Wed, Mar 08, 2006 at 01:14:45PM -0600, James Ketrenos wrote:
ieee80211: Don't update network statistics from off-channel packets.
Merged to upstream branch of wireless-2.6...thanks!
John
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev
5700 and 5701 will not return correct SRAM data when the chip is in
D3hot power state. tg3_get_eeprom_hw_cfg() must first put the device
in D0 before reading SRAM.
Thanks to Thomas Chenault at Dell for noticing this problem.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git
Some PHYs should not be powered down in tg3_set_power_state() because
of bugs or other hardware limitations.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 1fc4380..fbd8e46 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1148,6
Rick Jones wrote:
Skunk Worx wrote:
Rick Jones wrote:
From strace :
15:27:04.568800 recv(3, ?xml version=\1.0\ encoding=\UT...,
555, ) = 555 0.000121
vs.
15:18:24.515891 recv(3, ?xml version=\1.0\ encoding=\UT...,
566, ) = 566 0.038414
Will watch replies and post more when I know
On Fri, 2006-03-17 at 09:34 -0500, jamal wrote:
- the 2.4 algorithm performs very poorly for 8 bits if you use a
standard mask for ALL cases except when you use a lot of memory, most of
which is _wasted_, in which case it performs equally. There are only 8
masks in an 8 bit ranging from
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Sat, 18 Mar 2006 06:16:31 +
That workaround should be in the pci code as it affects any pci
device behind that bridge, not just tg3 ones.
We don't have any infrastructure to do that, even if it
was practical.
-
To unsubscribe from this list:
27 matches
Mail list logo
