Re: drivers/net/chelsio/sge.c: two array overflows
[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, This is a bug. The array should contain 2 elements. Attached is a patch which fixes it. Thanks. Signed-off-by: Scott Bardone [EMAIL PROTECTED] applied. please avoid attachments and use a proper patch description in the future. I had to hand-edit and hand-apply your patch. where you wrote in kernel tree commit 347a444e687b5f8cf0f6485704db1c6024d3: This is a bug. The array should contain 2 elements. Here is the fix. If I'm not completely off the track, you both committed a description off by one error: since the patch doesn't change the array size, it's presumely¹ still 3 elements, where index 2 references the last one. Here's hopefully a better patch description: Fixed off by one thinko in stats accounting, spotted by Coverity checker, notified by Adrian The Cleanman Bunk. SCR, Pete ¹) otherwise, it's still off by one.. - 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
[patch 1/1] missing check for request_region() return value in smctr.c
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
23:12:55.0 +0100
+++ linux-2.6.16-rc6/drivers/net/tokenring/smctr.c 2006-03-17
13:33:11.0 +0100
@@ -509,7 +509,10 @@ static int __init smctr_chk_mca(struct n
r2 = mca_read_stored_pos(tp-slot_num, 2);
r2 = 0xF0;
dev-base_addr = ((__u16)r2 8) + (__u16)0x800;
- request_region(dev-base_addr, SMCTR_IO_EXTENT, smctr_name);
+ if (!request_region(dev-base_addr, SMCTR_IO_EXTENT, smctr_name)) {
+ printf(KERN_ERR smctr: unable to request region
%d\n,dev-base_addr);
+ return -EBUSY;
+ }
/* IRQ */
r5 = mca_read_stored_pos(tp-slot_num, 5);
-
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
[no subject]
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
Re: [PATCH] TC: bug fixes to the sample clause
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 algorithm does. Ok, so you were talking about the new hash which takes both by new. You keep confusing me because i am no longer sure if you are still defending the 2.4.x or not. At some point you seem to be and other not. I take it you are no longer saying that for any sets which are = 8 bits, correct? For the 8 bits all i am asking you is to show that on a wide range of parameters that the old one is better. It will get the same performance of the 2.6 version with the same memory. In fact for all cases where the number of bits used is = 8, ie is _identical_ to the 2.6 algorithm. Yes, thats a given but what is the point? You showed for one piece of data something was good for the old hash - does that justify a few more instructions? I dont even remember what it was that you showed worked better for the old algorithm. It is odd that you keep mention IPv6. The IPv6 header has no fields that are less that 8 bits, and there are none that are not aligned on a 8 bit boundary. In fact even within the IPv6 addresses, there are no sub-fields less that 8 bits. It would be a happy hunting ground for the 2.4 algorithm. I talked about two octets in an IPV6 address. One octet had good entropy in the first 6 bits the other had good entropy in the next 5 bits. It has nothing to do with bit alignment. Well, this is the crux of the matter, isn't it? You are apparently used to looking up well known patterns - probably ones you determine. As such, you can arrange these in nice logical ranges. It helps me to optimize for the common. But i didnt invent that technique - it is the rest of the world of people who put together classifiers. I explained why earlier and asked you to go and look at some of the classical papers. Guess what? The very thing that started this off was me looking up TCP UDP port numbers. I didn't determine those port numbers. They are all over the shop - for me they are effectively random data. And they are sparse too, as in they occupy 16 bits. And for that you are entitled to look at the whole 16 bit space. Observing that the data is random is not going to help you. Ensuring that the whole 16 bit range is evenly spread across the buckets is important. The whole point of the rant that followed was to explain to you why in a case like that the 2.6 hash runs substantially slower that the 2.4 one. Whats more, it can't be fixed by simply trading off more memory. But you seem to be burying you head in the sand and saying such data sets don't exist. Well they do. And I gave you a real life one. I never said it doesnt exist. I said in such cases you need to assume the full range will show up - and then just ensure the buckets are being effectively used. Here is another one: I have contemplated at times giving priority to Australian traffic. So I went and found myself a list of Australian IP addresses. Being allocated by some central authority, I expected some nice ordered data set. How naive. There are some 400 subnets, and after trying to find some pattern I gave up after an hour. Another random dataset. The 2.4 algorithm will handle that well. I have been asking for some data now for the last few emails and you keep coming back making bold claims like these without backing them. When you changed the hash algorithm, you optimised it for your particular world - at the expense of people who have data sets like mime. Note that users of 2.4 with your dataset have a way out - waste a bit of memory and it will run just as fast. With a large dataset and 2.6 there is no way out. You are probably doubting this as you are it - I explain why below. All i asked for was some data and i would be more than happy to support your scheme;- And all your emails are refusing to provide me said data. a) If i built a hash table with 256 buckets, i can guarantee that i will find any host using either scheme in 4 lookups. Except 75% of the buckets will not be used by either. You miss one point. While you can guarantee it will happen in 4 lookups, 2.4 averages slightly more than 1 lookup it if hashes the entire value in one hit. In 2.6, you are stuck with your 4 lookups, as you say. I dont know if i followed what you said. If a mask of the whole 8bit was used neither scheme would be any different. They will all result in 1 lookup precisely. But this is about not using the whole 8 bit. See the pattern? But this is not the worst part. The nasty part is if i built a newer level of hash tables so i can reduce the lookups, it totally reduces my effectiveness; i need to figure out which buckets are being hit etc. The
PROBLEM: System freezes when changing MAC address
[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 freezes. There is no kernel oops or panic. I am using a Samsung X20 XVM 1730 V laptop running Ubuntu 5.10, my kernel version is 2.6.12-10-686. When I activate the interface first (ifconfig eth0 up), deactivate if again (ifconfig eth0 down), and then change the MAC address, the problem does not occur, even if I remove and re-insert the b44 kernel module in between. [3.] Keywords (i.e., modules, networking, kernel): networking, b44 [4.] Kernel version (from /proc/version): Linux version 2.6.12-10-686 ([EMAIL PROTECTED]) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8.1)) #1 Sat Mar 11 16:22:51 UTC 2006 [5.] Output of Oops.. message (if applicable) n/a [6.] A small shell script or example program which triggers the problem (if possible) 1. Boot the system with boot parameters ro and init=/bin/sh (parameters are not necessary to reproduce the problem, as long as the interface is not automatically brought up during the boot sequence). 2. Issue the following command: ifconfig eth0 hw ether 00:11:22:33:44:55 [7.] Environment [7.1.] Software (add the output of the ver_linux script here) Linux (none) 2.6.12-10-686 #1 Sat Mar 11 16:22:51 UTC 2006 i686 GNU/Linux Gnu C 4.0.2 Gnu make 3.80 binutils 2.16.1 util-linux 2.12p mount 2.12p module-init-tools 3.2-pre7 e2fsprogs 1.38 jfsutils 1.1.8 reiserfsprogs 3.6.19 reiser4progs 1.0.4 xfsprogs 2.6.28 pcmcia-cs 3.2.5 PPP2.4.3 Linux C Library2.3.5 Dynamic linker (ldd) 2.3.5 Procps 3.2.5 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 udev 060 Modules Loaded ext3 jbd mbcache thermal processor fan b44 mii ehci_hcd uhci_hcd usbcore ide_cd cdrom ide_disk ide_generic piix ide_core unix fbcon tileblit font bitblit vesafb cfbcopyarea cfbimgblt cfbfillrect softcursor capability commoncap [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.73GHz stepping: 8 cpu MHz : 1728.967 cache size : 2048 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2 bogomips: 3424.25 [7.3.] Module information (from /proc/modules): ext3 136264 2 - Live 0xf910 jbd 54776 1 ext3, Live 0xf90c9000 mbcache 9252 1 ext3, Live 0xf9085000 thermal 13000 0 - Live 0xf909 processor 22812 1 thermal, Live 0xf9089000 fan 4484 0 - Live 0xf8871000 b44 20996 0 - Live 0xf8878000 mii 5696 1 b44, Live 0xf8866000 ehci_hcd 34248 0 - Live 0xf9076000 uhci_hcd 31184 0 - Live 0xf9048000 usbcore 118044 3 ehci_hcd,uhci_hcd, Live 0xf9099000 ide_cd 41572 0 - Live 0xf903c000 cdrom 39616 1 ide_cd, Live 0xf9031000 ide_disk 18464 3 - Live 0xf886b000 ide_generic 1376 0 - Live 0xf8841000 piix 10372 1 - Live 0xf884c000 ide_core 138772 4 ide_cd,ide_disk,ide_generic,piix, Live 0xf9053000 unix 26896 0 - Live 0xf885c000 fbcon 38496 67 - Live 0xf8851000 tileblit 2368 1 fbcon, Live 0xf883f000 font 8224 1 fbcon, Live 0xf8843000 bitblit 5632 1 fbcon, Live 0xf883c000 vesafb 7992 1 - Live 0xf8831000 cfbcopyarea 4608 1 vesafb, Live 0xf8836000 cfbimgblt 2944 1 vesafb, Live 0xf8834000 cfbfillrect 3872 1 vesafb, Live 0xf8827000 softcursor 2272 1 vesafb, Live 0xf8829000 capability 4712 0 - Live 0xf882e000 commoncap 6816 1 capability, Live 0xf882b000 [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) /proc/ioports: -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 03c0-03df : vesafb 03f6-03f6 : ide0 1000-107f : motherboard 1000-1003 : PM1a_EVT_BLK 1004-1005 : PM1a_CNT_BLK 1008-100b : PM_TMR 1010-1015 : ACPI CPU throttle 1020-1020 : PM2_CNT_BLK 1028-102f : GPE0_BLK 1180-11bf : motherboard 1640-164f : motherboard 1800-1807 : :00:02.0 1810-181f : :00:1f.1 1810-1817 : ide0 1820-183f : :00:1d.0 1820-183f : uhci_hcd 1840-185f : :00:1d.1 1840-185f : uhci_hcd 1860-187f : :00:1d.2 1860-187f : uhci_hcd 1880-189f : :00:1d.3
Re: 2.6.15 localhost performance hit
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 writes a message in separate write() system calls, each one becomes a separate packet. In 2.6.15 we do a new thing called Appropriate Byte Count and that penalizes stupid applications, but provides better fairness over the internet by accounting for packets better. 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. --- John - 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
Re: [PATCH 1/2] pcnet32: Introduce basic AT 2700/01 FTX support
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 my current patch for you to review. I would like to submit it
for 2.6.17.
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 reconfigured
with ethtool. Supplying default options like 100full work as well.
I fiddled with the code a bit and got AUTONEG running. With this
extension our AT FTX cards will work fine. All cards will be configured
by default to use fibre at 100full and the module will use autoneg.
Since the fibre phy ignores settings for autoneg, 100full is not
overridden and works. But copper the phy will do autoneg. Tested and
works (un-/plugging and switching too of course).
snip
+} else {
+ int first_phy = -1;
+ u16 bmcr;
+ u32 bcr9;
+ struct ethtool_cmd ecmd;
+
+ /*
+* There is really no good other way to handle multiple PHYs
+* other than turning off all automatics
+*/
ASEL in BCR2 should be turned off as well. I noticed that only because
ethtool clears it. And without clearing it autoneg doesn't work.
val = lp-a.read_bcr(ioaddr, 2);
lp-a.write_bcr(ioaddr, 2, val ~2);
+ val = lp-a.read_bcr(ioaddr, 32);
+ lp-a.write_bcr(ioaddr, 32, val ~(1 7)); /* stop MII manager */
+
Do the following only if not asel:
if (!(lp-options PCNET32_PORT_ASEL)) {
+ /* setup ecmd */
+ ecmd.port = PORT_MII;
+ ecmd.transceiver = XCVR_INTERNAL;
+ ecmd.autoneg = AUTONEG_DISABLE;
+ ecmd.speed = lp-options PCNET32_PORT_100 ? SPEED_100 : SPEED_10;
+ bcr9 = lp-a.read_bcr(ioaddr, 9);
+
+ if (lp-options PCNET32_PORT_FD) {
+ ecmd.duplex = DUPLEX_FULL;
+ bcr9 |= (1 0);
+ } else {
+ ecmd.duplex = DUPLEX_HALF;
+ bcr9 |= ~(1 0);
+ }
+ lp-a.write_bcr(ioaddr, 9, bcr9);
}
+
+ for (i=0; iPCNET32_MAX_PHYS; i++) {
+ if (lp-phymask (1 i)) {
+ /* isolate all but the first PHY */
+ bmcr = mdio_read(dev, i, MII_BMCR);
+ if (first_phy == -1) {
+ first_phy = i;
+ mdio_write(dev, i, MII_BMCR, bmcr ~BMCR_ISOLATE);
+ } else {
+ mdio_write(dev, i, MII_BMCR, bmcr | BMCR_ISOLATE);
+ }
+ /* use mii_ethtool_sset to setup PHY */
+ lp-mii_if.phy_id = i;
+ ecmd.phy_address = i;
AUTOSEL Support: use ethtool_gset to setup ecmd...
if (lp-options PCNET32_PORT_ASEL) {
mii_ethtool_gset(lp-mii_if, ecmd);
ecmd.autoneg = AUTONEG_ENABLE;
}
+ mii_ethtool_sset(lp-mii_if, ecmd);
+ }
+ }
+ lp-mii_if.phy_id = first_phy;
+ if (netif_msg_link(lp))
+ printk(KERN_INFO %s: Using PHY number %d.\n, dev-name,
first_phy);
}
-
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
[PATCH] Kevent based AIO reading.
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 synchronous nonblocking reading from VFS cache either
using
copy_to_user() or memcpy() into userspace pages.
Attached performance graph, which compares copy_to_user() for i386 with
(optimized) memcpy().
mempcy() transfer is splitted into chunks of 1, 4 or 32 pages per
memcpy() call.
Vertical axis is number of megabytes per second transferred using either
memcpy() with different number of pages per call or copy_to_user() which
transfers the whole buffer at once. Horizontal axis is number of pages
transferred each system call (in case of memcpy() this transfer is
splitted into 32, 4, or 1 pages).
As we can see on the graph, if we transfer data using memcpy() using
only one page per call, it is completely impossible to have the same
performance as copy_to_user() if it transfers the whole buffer at once.
Since pinned userspace pages can only be accessed one by one, it will be
the 'memcpy_1_page', i.e. purple graph.
If we add here kmap_atomic()/kunmap_atomic() overhead on highmem enabled
kernels, which halves performace picture becomes even worse.
For interested reader attached kevent based AIO patch for ext3 system.
It does not populate read pages into VFS cache.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/fs/bio.c b/fs/bio.c
index 460554b..2bbaf6a 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -118,7 +118,7 @@ void bio_free(struct bio *bio, struct bi
/*
* default destructor for a bio allocated with bio_alloc_bioset()
*/
-static void bio_fs_destructor(struct bio *bio)
+void bio_fs_destructor(struct bio *bio)
{
bio_free(bio, fs_bio_set);
}
diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
index 8824e84..02d04c9 100644
--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -787,7 +787,7 @@ out:
return err;
}
-static int ext3_get_block(struct inode *inode, sector_t iblock,
+int ext3_get_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh_result, int create)
{
handle_t *handle = NULL;
diff --git a/fs/file_table.c b/fs/file_table.c
index 7d73a2b..9be1420 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -90,7 +90,7 @@ struct file *get_empty_filp(void)
goto fail_sec;
#ifdef CONFIG_KEVENT_POLL
- kevent_storage_init(KEVENT_POLL, KEVENT_MASK_EMPTY, f, f-st);
+ kevent_storage_init(f, f-st);
#endif
eventpoll_init_file(f);
atomic_set(f-f_count, 1);
diff --git a/fs/inode.c b/fs/inode.c
index 185bd67..11bbca4 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -166,8 +166,8 @@ static struct inode *alloc_inode(struct
}
memset(inode-u, 0, sizeof(inode-u));
inode-i_mapping = mapping;
-#if defined CONFIG_KEVENT_INODE || defined CONFIG_KEVENT_SOCKET
- kevent_storage_init(KEVENT_INODE, KEVENT_MASK_EMPTY, inode,
inode-st);
+#if defined CONFIG_KEVENT
+ kevent_storage_init(inode, inode-st);
#endif
}
return inode;
diff --git a/include/linux/kevent.h b/include/linux/kevent.h
index 64926bc..376fedc 100644
--- a/include/linux/kevent.h
+++ b/include/linux/kevent.h
@@ -43,6 +43,7 @@ enum {
KEVENT_TIMER,
KEVENT_POLL,
KEVENT_NAIO,
+ KEVENT_AIO,
KEVENT_MAX,
};
@@ -95,6 +96,13 @@ enum {
KEVENT_POLL_POLLREMOVE = 0x1000,
};
+/*
+ * Asynchronous IO events.
+ */
+enum {
+ KEVENT_AIO_BIO = 0x1,
+};
+
#define KEVENT_MASK_ALL0x /* Mask of all possible
event values. */
#define KEVENT_MASK_EMPTY 0x0 /* Empty mask of ready events.
*/
@@ -198,6 +206,11 @@ struct kevent_user
wait_queue_head_t wait; /* Wait until some
events are ready. */
atomic_trefcnt; /* Reference counter,
increased for each new kevent. */
+#ifdef CONFIG_KEVENT_USER_STAT
+ unsigned long im_num;
+ unsigned long wait_num;
+ unsigned long total;
+#endif
};
#define KEVENT_MAX_REQUESTSPAGE_SIZE/sizeof(struct kevent)
@@ -208,8 +221,6 @@ int kevent_enqueue(struct kevent *k);
int kevent_dequeue(struct kevent *k);
int kevent_init(struct kevent *k);
void kevent_requeue(struct kevent *k);
-int kevent_storage_enqueue(struct kevent_storage *st, struct kevent *k);
-void kevent_storage_dequeue(struct kevent_storage *st, struct kevent *k);
#define list_for_each_entry_reverse_safe(pos, n, head, member)
\
for (pos = list_entry((head)-prev, typeof(*pos), member), \
@@ -225,10 +236,13 @@ int kevent_init_inode(struct kevent *k);
int kevent_init_timer(struct kevent *k);
int kevent_init_poll(struct kevent
Re: [PATCH] Kevent based AIO reading.
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 @@
*/
#define KEVENT_REQ_ONESHOT 0x1 /* Process this event only once
and then dequeue. */
+#define KEVENT_REQ_ENQUEUE 0x2 /* Always add that kevent, even
if it is ready immediately. */
/*
* Kevent return flags.
*/
#define KEVENT_RET_BROKEN 0x1 /* Kevent is broken. */
#define KEVENT_RET_DONE0x2 /* Kevent processing
was finished successfully. */
+#define KEVENT_RET_STACK 0x4 /* Kevent was allocated in
stack. Can only be used for immediate ready kevents. */
/*
* Kevent type set.
@@ -202,7 +204,6 @@ struct kevent_user
unsigned intmax_ready_num; /* Requested number of
kevents. */
struct semaphorectl_mutex; /* Protects against
simultaneous kevent_user control manipulations. */
- struct semaphorewait_mutex; /* Protects against
simultaneous kevent_user waits. */
wait_queue_head_t wait; /* Wait until some
events are ready. */
atomic_trefcnt; /* Reference counter,
increased for each new kevent. */
@@ -210,6 +211,7 @@ struct kevent_user
unsigned long im_num;
unsigned long wait_num;
unsigned long total;
+ unsigned long enfile;
#endif
};
@@ -220,7 +222,9 @@ void kevent_free(struct kevent *k);
int kevent_enqueue(struct kevent *k);
int kevent_dequeue(struct kevent *k);
int kevent_init(struct kevent *k);
-void kevent_requeue(struct kevent *k);
+int kevent_requeue(struct kevent *k);
+struct kevent *kevent_recreate(struct kevent *kevent, gfp_t mask);
+void kevent_finish_user(struct kevent *k, int lock, int deq);
#define list_for_each_entry_reverse_safe(pos, n, head, member)
\
for (pos = list_entry((head)-prev, typeof(*pos), member), \
@@ -241,7 +245,7 @@ int kevent_init_aio(struct kevent *k);
void kevent_storage_ready(struct kevent_storage *st, kevent_callback_t
ready_callback, u32 event);
int kevent_storage_init(void *origin, struct kevent_storage *st);
void kevent_storage_fini(struct kevent_storage *st);
-int kevent_storage_enqueue(struct kevent_storage *st, struct kevent *k);
+void kevent_storage_enqueue(struct kevent_storage *st, struct kevent *k);
void kevent_storage_dequeue(struct kevent_storage *st, struct kevent *k);
int kevent_user_add_ukevent(struct ukevent *uk, struct kevent_user *u);
diff --git a/kernel/kevent/kevent.c b/kernel/kevent/kevent.c
index 9bccc66..a055f40 100644
--- a/kernel/kevent/kevent.c
+++ b/kernel/kevent/kevent.c
@@ -116,7 +116,7 @@ int kevent_init(struct kevent *k)
* Called from -enqueue() callback when reference counter for given
* origin (socket, inode...) has been increased.
*/
-int kevent_storage_enqueue(struct kevent_storage *st, struct kevent *k)
+void kevent_storage_enqueue(struct kevent_storage *st, struct kevent *k)
{
unsigned long flags;
@@ -125,7 +125,6 @@ int kevent_storage_enqueue(struct kevent
list_add_tail(k-storage_entry, st-list);
st-qlen++;
spin_unlock_irqrestore(st-lock, flags);
- return 0;
}
/*
@@ -146,7 +145,7 @@ void kevent_storage_dequeue(struct keven
spin_unlock_irqrestore(st-lock, flags);
}
-static void __kevent_requeue(struct kevent *k, u32 event)
+static int kevent_callback(struct kevent *k)
{
int err, rem = 0;
unsigned long flags;
@@ -162,30 +161,45 @@ static void __kevent_requeue(struct keve
}
rem = (k-event.req_flags KEVENT_REQ_ONESHOT);
spin_unlock_irqrestore(k-lock, flags);
+
+ if (err rem) {
+ list_del(k-storage_entry);
+ k-st-qlen--;
+ }
- if (err) {
- if (rem) {
- list_del(k-storage_entry);
- k-st-qlen--;
- }
-
- spin_lock_irqsave(k-user-ready_lock, flags);
- if (k-ready_entry.next == LIST_POISON1) {
- list_add_tail(k-ready_entry, k-user-ready_list);
- k-user-ready_num++;
- }
- spin_unlock_irqrestore(k-user-ready_lock, flags);
- wake_up(k-user-wait);
+ return err;
+}
+
+static void __kevent_requeue(struct kevent *k, u32 event)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(k-user-ready_lock, flags);
+ if (k-ready_entry.next == LIST_POISON1) {
+ list_add_tail(k-ready_entry, k-user-ready_list);
+ k-user-ready_num++;
}
+ spin_unlock_irqrestore(k-user-ready_lock, flags);
+
Re: 2.6.15 localhost performance hit
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 this.
Do you have the strace from the sending side?
Yes...I hope I'm not posting too much info but here goes. It's worth
mentioning that this data is never on the internet, only isolated lan or
loopback. We are using an older version of the GSOAP toolkit (a
sourceforge project) and are in the process of porting to their latest
version.
In addition to the straces below, I have ethereal screencaps in jpeg
format if anyone wants to see those...2 x ~400k. ea.
Thanks everyone for pondering this. I tried to get the socket setup and
several full transactions from each side of loopback.
---
John
Server side:
15:15:11.267781 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 0.33
15:15:11.267885 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.15
15:15:11.267970 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
0.14
15:15:11.268051 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
0.14
15:15:11.268133 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 0.16
Sigh, still another application abusing TCP_NODELAY. Quelle surprise.
15:15:11.268216 bind(3, {sa_family=AF_INET, sin_port=htons(8080),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0 0.20
15:15:11.268318 listen(3, 100) = 0 0.43
15:15:11.268433 getsockname(3, {sa_family=AF_INET, sin_port=htons(8080),
sin_addr=inet_addr(0.0.0.0)}, [16]) = 0 0.15
snip
15:18:23.624649 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) 0.14
15:18:23.624724 fcntl64(3, F_SETFL, O_RDWR) = 0 0.13
15:18:23.624799 accept(3, {sa_family=AF_INET, sin_port=htons(57058),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 4 0.23
15:18:23.624939 setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
0.15
15:18:23.625021 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
0.14
15:18:23.625101 setsockopt(4, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
0.14
15:18:23.625180 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0 0.14
I wonder how many of those previous four setsockopts could have been
inherited from the listen socket?
15:18:23.625316 recv(4, POST / HTTP/1.1\r\nHost: localhost..., 32768,
0) = 593 0.18
15:18:23.625542 send(4, HTTP/1.1 200 OK\r\nServer: gSOAP/2..., 129, 0)
= 129 0.000114
15:18:23.625787 send(4, 236\r\n, 5, 0) = 5 0.76
15:18:23.625937 send(4, ?xml version=\1.0\ encoding=\UT..., 566,
0) = 566 0.000117
15:18:23.626133 send(4, \r\n0\r\n\r\n, 7, 0) = 7 0.000167
And there you have it - four separate sends for logically associated
data, when there should have been just the one sendmsg or writev call.
Given the sizes involved, that is roughly three to four times as much
CPU consumed to send that data is should have been - for small packets
you can handwave that the CPU cost is per-packet rather than
per-byte (OK, not _strictly_ true for say that 566 byte chunk, but for
the rest basically true)
Client side :
15:16:05.012862 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 0.29
15:16:05.012960 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
0.16
15:16:05.013045 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
0.15
15:16:05.013125 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 0.17
snip
15:16:05.019312 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) 0.14
15:16:05.019388 fcntl64(3, F_SETFL, O_RDWR) = 0 0.14
15:16:05.019463 connect(3, {sa_family=AF_INET, sin_port=htons(8080),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0 0.000815
snip
15:18:23.624100 send(3, POST / HTTP/1.1\r\nHost: localhost..., 593, 0)
= 593 0.87
At least the client is doing the right thing with its requests.
15:18:23.624313 recv(3, HTTP/1.1 200 OK\r\nServer: gSOAP/2..., 32768,
0) = 129 0.002025
15:18:23.626445 recv(3, 236\r\n?xml version=\1.0\ encodin...,
32768, 0) = 578 0.20
That would have been just the one recv() call had the sender been doing
things properly...
rick jones
-
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
Re: 2.6.15 localhost performance hit
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 way 2.6.15 maps the byte-based heuristics of the ABC RFC to the stack's packet-based cwnd it requires the exchange of an entire MSS worth of data before an additional packet is added to cwnd. IIRC the loopback MTU is 16384 bytes, and an Ethernet MTU is 1500, so it will take a _lot_ more small packets sent back and forth over loopback to increase the cwnd by one packet than it would over Ethernet. I suspect that were Gigabit Ethernet involved and the MTU set to 9000 bytes the Ethernet case might look more like the loopback case. rick jones - 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
Re: PROBLEM: System freezes when changing MAC address
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 look into this. Thanks. - 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
Re: drivers/net/chelsio/sge.c: two array overflows
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 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, This is a bug. The array should contain 2 elements. Attached is a patch which fixes it. Thanks. Signed-off-by: Scott Bardone [EMAIL PROTECTED] applied. please avoid attachments and use a proper patch description in the future. I had to hand-edit and hand-apply your patch. where you wrote in kernel tree commit 347a444e687b5f8cf0f6485704db1c6024d3: This is a bug. The array should contain 2 elements. Here is the fix. If I'm not completely off the track, you both committed a description off by one error: since the patch doesn't change the array size, it's presumely¹ still 3 elements, where index 2 references the last one. Here's hopefully a better patch description: Fixed off by one thinko in stats accounting, spotted by Coverity checker, notified by Adrian The Cleanman Bunk. SCR, Pete ¹) otherwise, it's still off by one.. - 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
Re: 2.6.16-rc5-mm2: IPW_QOS: two remarks
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 * IPW2200_QOS enables QoS feature - this is under development right now, so it depends upon EXPERIMENTAL. Your patch appears to be whitespace-damaged. Please configure your mailer appropriately. Also, please stick to the patch format described here: http://linux.yyz.us/patch-format.html In particular, don't put anything in the message that doesn't belong in the kernel's changelog, such as email-ish messages. On Tue, Mar 07, 2006 at 06:06:42PM +0100, Adrian Bunk wrote: On Sun, Mar 05, 2006 at 01:46:26AM +0100, Andreas Happe wrote: On Friday 03 March 2006 16:26, Adrian Bunk wrote: ... - please add a help text i could add some stuff about WMM to its help text, but I think someone more involved with the ipw2200-project should do that. Even a short help text is better than no help text. I agree w/ Adrian. Since you are touching it, please put something appropriate in the Kconfig file. Zhu Yi may be able to help if you aren't sure what the help text should say. Thanks! John -- John W. Linville [EMAIL PROTECTED] - 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
Re: [PATCH 2/6] ipw2100: add radiotap headers to packtes captured in monitor mode
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 net/ieee80211_radiotap.h
+#endif
please include the header unconditionally.
+
#include linux/workqueue.h
and for a followon patch please inlcude net/*.h after linux/*.h
On Wed, Mar 08, 2006 at 12:59:59PM +, Christoph Hellwig wrote:
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -194,6 +194,7 @@ static struct ipw2100_fw ipw2100_firmwar
#endif
#include linux/moduleparam.h
+#include linux/mutex.h
module_param(debug, int, 0444);
please keep a whitespace after the includes and before the module_param
statements.
In the interest of progress, I'm going to go ahead and merge these
patches. But, I would happily accept style patches to clean-up
these issues...anyone?
John
--
John W. Linville
[EMAIL PROTECTED]
-
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
Re: [PATCH 1/2] pcnet32: Introduce basic AT 2700/01 FTX support
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 reconfigured with ethtool. Supplying default options like 100full work as well. I fiddled with the code a bit and got AUTONEG running. With this extension our AT FTX cards will work fine. All cards will be configured by default to use fibre at 100full and the module will use autoneg. Is this selection of 100Full done with the AT diag routine? Since the fibre phy ignores settings for autoneg, 100full is not overridden and works. But copper the phy will do autoneg. Tested and works (un-/plugging and switching too of course). If I understand correctly, your suggestion is to always have Autoneg selected (options = 0) but the hardware is set by default to use 100Full Fiber. Is that a correct understanding? -- Don Fry [EMAIL PROTECTED] - 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
Re: [RFC] new qla3xxx NIC Driver v2.02.00b01
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 you are doing some offloading, your going to get screwed cause you don't handle address changes, and gob of other issues related to addreses, IPV6, ... * Don't use typedef's ql3xx_adapter, ... etc. * Don't define stuff in ql3_def.h that is already in other linux headers ETH_DATA_LEN ... * You have to allocate an skb and copy the data into the buffer on every receive in interrupt. Boy I bet that really sucks for performance. * Use netdev_priv() rather than dev-priv * You are making more work than necessary. The driver is keeping stuff in the adapter data structure that is available already in net_device mtu, eth_addr, multicast list, ... * Also lots of rx/tx block information is redundant and can be rederived. If you have the skb and map address that should be sufficient. * Any gigabit driver ought to be using NAPI, this isn't * Don't do ethtool via ioctl hook use ethtool_ops. * Do nvram via ethtool * Needs real ethtool support for speed setting/reporting * If you need a linked list, use list macros? * Use new module_param() not deprecated MODULE_PARM() * Use netif_msg_ rather than your current print_lvl / qDbgLevel * Remove wrapper macros like QLDPRT5 * Remove HARD_ETHER_ADDRESS! * Use existing MII code and interface * Use C90 style initializers rather than old GNU style * WTF is ql3xxx_driver_entry? * ql3xxx_open is unnecessary stupid wrapper to ql_open remove it * Don't use a dpc thread, use a work queue instead * qdev-stats should just be part of the netdev_priv() not malloc'd * enable/disable interrupts should probably be inline in .h file * ql_sem_spinlock and ql_sem_lock defined but not used? delete it * make functions used in one file static. * isr routine shouldn't save/restore flags it's an isr interrupts are disabled already * code is full of places where it looks like you are being paid by the LOC if (retval) return IRQ_HANDLED; else return IRQ_NONE; vs. return IRA_HANDLED(retval); * Minor - use const char for name/string/version - add MODULE_VERS(DRV_VERSION) - use PCI_DEVICE() macro in pci_device_id table - source lines 80 characters please indent - Splitting things up into separate files isn't helpful for a driver this size. * Different from common usage: - Most net drivers use pci_alloc_consistent rather than dma_alloc_coherent in network drivers - 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
Re: [PATCH 1/2] pcnet32: Introduce basic AT 2700/01 FTX support
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 work and can be reconfigured with ethtool. Supplying default options like 100full work as well. I fiddled with the code a bit and got AUTONEG running. With this extension our AT FTX cards will work fine. All cards will be configured by default to use fibre at 100full and the module will use autoneg. Is this selection of 100Full done with the AT diag routine? oh sorry. yes. Since the fibre phy ignores settings for autoneg, 100full is not overridden and works. But copper the phy will do autoneg. Tested and works (un-/plugging and switching too of course). If I understand correctly, your suggestion is to always have Autoneg selected (options = 0) but the hardware is set by default to use 100Full Fiber. Is that a correct understanding? yes and no. the site i work for: yes (we'll fix every card by with the at diag utility). for others: it just means that the pcnet32 multiphy code fully complies to module options including autonegotiation. That way multiphy-cards can be initialized with whatever sane settings the user wants and if necessary postconfigured with ethtool. The AT cards are just special cases because there is one element which does not understand autonegotiation, which i can take advantage of by correctly presetting that element. Whether 0 (autoneg) or something else is a good default value i don't know... - 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
Please pull 'upstream' branch of wireless-2.6
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: drivers/net/wireless/ipw2200.c: make ipw_qos_current_mode() static drivers/net/wireless/ipw2200.c: fix an array overun Bill Moss: ipw2200: Add signal level to iwlist scan output Cahill, Ben M: ipw2200: Set a meaningful silence threshold value ipw2200: Enables the slow diversity algorithm Henrik Brix Andersen: ipw2200: print geography code upon module load Ingo Molnar: ipw2100: semaphore to mutexes conversion James Ketrenos: ipw2200: stop netdev queue if h/w doesn't have space for new packets ipw2200: switch to the new ipw2200-fw-3.0 image format ieee80211: Don't update network statistics from off-channel packets. Larry Finger: Remove duplicated code from ipw2200.c Olivier Hochreutiner: ipw2200: wireless extension sensitivity threshold support Stefan Rompf: ipw2100: add radiotap headers to packtes captured in monitor mode Zhu Yi: ipw2200: fix a potential NULL pointer dereference ipw2200: use generic ieee80211_get_hdrlen() to get packet length ipw2200: remove the WPA card associates to non-WPA AP checking ipw2200: Fix rf_kill is activated after mode change with 'disable=1' ipw2200: Fix ipw_sw_reset() implementation inconsistent with comment ipw2200: Filter unsupported channels out in ad-hoc mode ipw2200: Change debug level for firmware error logging ipw2200: export `debug' module param only if CONFIG_IPW2200_DEBUG ipw2200: Update ipw2200 version stamp to 1.1.1 ipw2x00: expend Copyright to 2006 ipw2100: Fix radiotap code gcc warning ipw2100: move mutex.h include from ipw2100.c to ipw2100.h ipw2100: Update version ipw2100 stamp to 1.2.2 Documentation/networking/README.ipw2100 | 12 - Documentation/networking/README.ipw2200 | 44 +++ drivers/net/wireless/ipw2100.c | 220 ++- drivers/net/wireless/ipw2100.h | 11 + drivers/net/wireless/ipw2200.c | 450 +-- drivers/net/wireless/ipw2200.h | 39 +-- net/ieee80211/ieee80211_rx.c| 14 + 7 files changed, 415 insertions(+), 375 deletions(-) diff --git a/Documentation/networking/README.ipw2100 b/Documentation/networking/README.ipw2100 index 3ab4037..f3fcaa4 100644 --- a/Documentation/networking/README.ipw2100 +++ b/Documentation/networking/README.ipw2100 @@ -3,18 +3,18 @@ Intel(R) PRO/Wireless 2100 Driver for Li Intel(R) PRO/Wireless 2100 Network Connection -Copyright (C) 2003-2005, Intel Corporation +Copyright (C) 2003-2006, Intel Corporation README.ipw2100 -Version: 1.1.3 -Date : October 17, 2005 +Version: git-1.1.5 +Date : January 25, 2006 Index --- 0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER 1. Introduction -2. Release 1.1.3 Current Features +2. Release git-1.1.5 Current Features 3. Command Line Parameters 4. Sysfs Helper Files 5. Radio Kill Switch @@ -89,7 +89,7 @@ potential fixes and patches, as well as for the driver project. -2. Release 1.1.3 Current Supported Features +2. Release git-1.1.5 Current Supported Features --- - Managed (BSS) and Ad-Hoc (IBSS) - WEP (shared key and open) @@ -270,7 +270,7 @@ For installation support on the ipw2100 9. License --- - Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved. + Copyright(c) 2003 - 2006 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License (version 2) as diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200 index c6492d3..acb30c5 100644 --- a/Documentation/networking/README.ipw2200 +++ b/Documentation/networking/README.ipw2200 @@ -10,7 +10,7 @@ both hardware adapters listed above. In PRO/Wireless 2915ABG Driver for Linux will be used to reference the unified driver. -Copyright (C) 2004-2005, Intel Corporation +Copyright (C) 2004-2006, Intel Corporation README.ipw2200 @@ -26,9 +26,11 @@ Index 1.2. Module parameters 1.3. Wireless Extension Private Methods 1.4. Sysfs Helper Files +1.5. Supported channels 2. Ad-Hoc Networking 3. Interacting with Wireless Tools 3.1. iwconfig mode +3.2. iwconfig sens 4. About the Version Numbers 5. Firmware installation 6. Support @@ -314,6 +316,35 @@ For the device level files, see /sys/bus running ifconfig and is therefore disabled by default. +1.5. Supported channels +--- + +Upon loading the Intel(R) PRO/Wireless 2915ABG Driver
Re: [PATCH] Remove duplicated code from ipw2200.c
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 preserve whitespace, converts ipw2200.c to use the ieee80211 versions, thereby reducing bloat in both the source and binary. 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 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ipw2100 driver updates
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 5/6] ipw2100: move mutex.h include from ipw2100.c to ipw2100.h [PATCH 6/6] ipw2100: Update version ipw2100 stamp to 1.2.1 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 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ieee80211: Don't update network statistics from off-channel packets.
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 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.17 1/2] tg3: Fix SRAM access during tg3_init_one()
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 a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6bf8e04..1fc4380 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9436,12 +9436,18 @@ static inline struct subsys_tbl_ent *loo
return NULL;
}
-/* Since this function may be called in D3-hot power state during
- * tg3_init_one(), only config cycles are allowed.
- */
static void __devinit tg3_get_eeprom_hw_cfg(struct tg3 *tp)
{
u32 val;
+ u16 pmcsr;
+
+ /* On some early chips the SRAM cannot be accessed in D3hot state,
+* so need make sure we're in D0.
+*/
+ pci_read_config_word(tp-pdev, tp-pm_cap + PCI_PM_CTRL, pmcsr);
+ pmcsr = ~PCI_PM_CTRL_STATE_MASK;
+ pci_write_config_word(tp-pdev, tp-pm_cap + PCI_PM_CTRL, pmcsr);
+ msleep(1);
/* Make sure register accesses (indirect or otherwise)
* will function correctly.
-
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
[PATCH 2.6.17 2/2] tg3: Skip phy power down on some devices
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 +1148,19 @@ static int tg3_halt_cpu(struct tg3 *, u3
static int tg3_nvram_lock(struct tg3 *);
static void tg3_nvram_unlock(struct tg3 *);
+static void tg3_power_down_phy(struct tg3 *tp)
+{
+ /* The PHY should not be powered down on some chips because
+* of bugs.
+*/
+ if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5700 ||
+ GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5704 ||
+ (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5780
+(tp-tg3_flags2 TG3_FLG2_MII_SERDES)))
+ return;
+ tg3_writephy(tp, MII_BMCR, BMCR_PDOWN);
+}
+
static int tg3_set_power_state(struct tg3 *tp, pci_power_t state)
{
u32 misc_host_ctrl;
@@ -1327,8 +1340,7 @@ static int tg3_set_power_state(struct tg
tg3_writephy(tp, MII_TG3_EXT_CTRL,
MII_TG3_EXT_CTRL_FORCE_LED_OFF);
tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x01b2);
- if (GET_ASIC_REV(tp-pci_chip_rev_id) != ASIC_REV_5700)
- tg3_writephy(tp, MII_BMCR, BMCR_PDOWN);
+ tg3_power_down_phy(tp);
}
}
-
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
Re: 2.6.15 localhost performance hit
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 more. Kinda new at this. Do you have the strace from the sending side? 15:18:23.625316 recv(4, POST / HTTP/1.1\r\nHost: localhost..., 32768, 0) = 593 0.18 15:18:23.625542 send(4, HTTP/1.1 200 OK\r\nServer: gSOAP/2..., 129, 0) = 129 0.000114 15:18:23.625787 send(4, 236\r\n, 5, 0) = 5 0.76 15:18:23.625937 send(4, ?xml version=\1.0\ encoding=\UT..., 566, 0) = 566 0.000117 15:18:23.626133 send(4, \r\n0\r\n\r\n, 7, 0) = 7 0.000167 And there you have it - four separate sends for logically associated data, when there should have been just the one sendmsg or writev call. Given the sizes involved, that is roughly three to four times as much CPU consumed to send that data is should have been - for small packets you can handwave that the CPU cost is per-packet rather than per-byte (OK, not _strictly_ true for say that 566 byte chunk, but for the rest basically true) We're kind of stuck using gsoap. We like the toolkit and have a lot of code using it. Fortunately, none of our packets will be going on the internet. The same problem exists using the latest version of gsoap, so they are still utilizing small packets. I am planning on mentioning this to them occasionally on their list. We noticed an interesting dynamic in the way the TCP ACK delay is applied to our transactions. The gsoap toolkit has an internal keep_alive variable that regulates the number of transactions a client can make to the server on a given connection. We've always used the default of 100. In the tcpdump, we see that the first 40 ms. ACK delay is applied just after the TCP window ramps up on a new connection. We get additional ACK delays applied for the next 22 transactions, then it stops--no more delays are seen in the remaining 77 transactions. Then the keep_alive has counted to zero, and the client is forced to reconnect to the server, and the process repeats--23 ACK delays, then 77 unmolested transactions. Changing the keep_alive to 10,000 (we write all our clients, not worried about abuse) drops the ACK delay count to about 27/13,000 transactions, much better than the 3000 delays originally seen. Another option is to sysctl tcp_abc off, if we have to. I wonder if client applications are being charged for the initial SYN packets, or something else odd is happening in the ABC algorithm as the TCP window is growing? --- John - 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
Re: [PATCH] TC: bug fixes to the sample clause
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 length of 1 to 8. Should not be hard to prove or disprove. Should be very easy to see when you plot. Agreed. - You made the claim the 2.6 algorithm performs poorly if you had a 16 bit mask. You showed one sample of data. I dont even remember your sample anymore because you keep bombarding me with a lot of claims. I gave you the parameters which will help convince me. I showed you a sample using similar parameters why the old one was buggy in the case of 8 bits. There are only 16 possible masks for 16 bits (of length 1-16). Why cant you just give me similar results? Why do we have to go back and forth with a lot of hand waving when we can settle this easily? I guess there are a couple of points here I don't understand: - I don't see how 2.4 was buggy, but perhaps we have different definitions of buggy. I regard giving the wrong result as buggy. Neither algorithm does that. - I don't understand your point about there are only 16 possible masks for 16 bits. What do you want me to show? I will not respond to any further emails which do not contain data - instead I am going to produce mine. Put the 2.4 vs 2.6 argument aside. The best solution as is to adopt the new algorithm I proposed. Here is why: 1. It can emulate either the 2.4 or 2.6 algorithm by a suitable choice of mask. I can prove formally this if you need me to. 2. There is no dataset where the new algorithm is slower than either 2.4, or 2.6. This follows from (1). 3. There are datasets where it is faster than the 2.6, algorithm, and datasets where it is faster than the 2.4 algorithm. This follows from the fact that there are datasets where 2.6 is faster than 2.4, and there are datasets where 2.4 is faster than 2.6. I think you know this already, but if not I can give some simple examples to prove it - just ask. 4. Timing. If we are going to change the algorithm, this is the time to do it - while the algorithm in tc is wrong and must be changed anyway. For your convenience I have cut pasted from the previous email the comparison of the 2.4, 2.6 and new algorithm: 2.4 Algorithm: 2.6 algorithm: New Algorithm: -- -- -- hash = (hash16)^hash; hash = hashshift; hash = hashshift; hash = (hash8)^hash; return hash 0xff; hash = (hash16)^hash; return hash 0xff; hash = (hash8)^hash; return hash 0xff; - 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
Re: [PATCH 2.6.16] tg3: 40-bit DMA workaround part 2
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: 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
