* netdev munching messages again?
From: Thomas Graf @ 2005-06-07 21:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <20050607140901.632982000@axs>
Is netdev not fed regularely so it started munching messages again?
I've not received the introduction message and patches 1-5 back
only 6-7 which have been sitting in the queue due to refused
connections for a while. Am I the only one having troubles?
^ permalink raw reply
* Re: netdev munching messages again?
From: David S. Miller @ 2005-06-07 21:42 UTC (permalink / raw)
To: tgraf; +Cc: netdev
In-Reply-To: <20050607213621.GG20969@postel.suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 7 Jun 2005 23:36:21 +0200
> Is netdev not fed regularely so it started munching messages again?
> I've not received the introduction message and patches 1-5 back
> only 6-7 which have been sitting in the queue due to refused
> connections for a while. Am I the only one having troubles?
This is exactly what I saw as well.
I did get all of your postings because you sent them
with me on the CC: list, but netdev only sent out
6 and 7 to me just as you observed.
This has become a regular occurance, it may be time to finally move
this thing over to vger.kernel.org. Thoughts?
^ permalink raw reply
* [ANNOUNCE] iproute2-ss050607
From: Stephen Hemminger @ 2005-06-07 22:43 UTC (permalink / raw)
To: linux-net, lartc, netdev
Small update to iproute2, I have been waiting to get a CVS conversion
completed and working on other things so changes are small.
http://developer.osdl.org/dev/iproute2/download/iproute2-ss050607.tar.gz
Stephen Hemminger
* Fix 'ip link' map to handle case where device gets autoloaded
by using if_nametoindex as fallback
* Device indices are unsigned not int.
Masahide NAKAMURA
* [ip] show timestamp when using '-t' option.
* [ip] remove duplicated code for expired message of xfrm.
* [ip] add "deleteall" command for xfrm;
"flush" uses kernel's flush interface and
"deleteall" uses legacy iproute2's flush feature like
getting-and-deleting-for-each.
This is the first export from the CVS repo, so let me know if there
are any quirks.
If you have something you want to see in the next release and it isn't
there please resend.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Rick Jones @ 2005-06-07 23:19 UTC (permalink / raw)
To: Robert Olsson, netdev
Cc: Martin Josefsson, jamal, Stephen Hemminger, Mitch Williams,
Ronciak, John, David S. Miller, mchan, buytenh, jdmason,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <17061.52365.336303.369135@robur.slu.se>
>
> BTW, Can netperf be used for tests like this? (Rick?)
Assuming I'm translating "test like this" to the right sort of stuff :)
If one wants to see the effect of different buffer replenishment strategies, I
suppose that some netperf tests could indeed be used. It would be desirable to
look at service demand moreso than throughput (assuming the throughput is
link-bound). TCP_STREAM and/or TCP_MAERTS. I'm not sure the extent to which it
would be visible to a TCP_RR test.
Differences in service demand could also be used to measure effects of irq
migration, pinning IRQs and/or processes to specific CPUs and the like. The
linux processor affinity stuff in netperf could use a little help though - it is
easily confused as to when to use a two argument vs three argument
sched_setaffinity call. I suspect one may also see differences in TCP_RR
transaction rates.
I suspect some high number of confidence interval iterations might be required.
rick jones
i'd trim individual names from the dist list, but am not 100% sure who is on
netdev...
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Jesse Brandeburg @ 2005-06-08 1:50 UTC (permalink / raw)
To: Ben Greear
Cc: Williams, Mitch A, Ronciak, John, David S. Miller, mchan, hadi,
buytenh, jdmason, shemminger, netdev, Robert.Olsson,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <42A4E599.2090604@candelatech.com>
On Mon, 6 Jun 2005, Ben Greear wrote:
> So is the Linux server reading/writing these large files to/from the
> disk?
no, the test runs completely from memory, and the clients are
reading/writing from/to the server
> Can you tell us how much performance went down when you increased the
> descriptors to 512?
sorry don't know the answer to that one.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Jesse Brandeburg @ 2005-06-08 2:20 UTC (permalink / raw)
To: David S. Miller
Cc: Ronciak, John, hadi, shemminger, Williams, Mitch A, mchan,
buytenh, jdmason, netdev, Robert.Olsson, Venkatesan, Ganesh,
Brandeburg, Jesse
In-Reply-To: <20050607.132159.35660612.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2928 bytes --]
On Tue, 7 Jun 2005, David S. Miller wrote:
> > There also seems to be some misconceptions about changing the weight
> > value. It actually improves the performance of other drivers as well.
> > Not as much as it improves the e1000 performance but it does seem to
> > help others as well.
>
> One reason it helps e1000 more, which Robert Olsson mentioned, could
> be the HW irq mitigation settings used by the e1000 driver. Lowering
> these would be a good test.
Well, first a little more data. The machine in question is a dual xeon
running 2.6.12-rc5 or 2.6.12-rc4-supertso
with the 2.6.12-rc5 kernel (the old) tso promptly shuts down after a SACK,
and after that point the machine is CPU bound at 100%. This is the point
that we start to drop packets at the hardware level.
I tried the experiment today where I replenish buffers to hardware every
16 packets or so. This appears to mitigate all drops at the hardware
level (no drops). We're still at 100% with the rc5 kernel, however.
even with this replenish fix, the addition of dropping the weight to 16
helped increase our throughput, although only about 1%.
On the other hand, taking our driver as is with no changes and running the
supertso (not the split out version, yet) kernel, we show no dropped
packets and 60% cpu use. This combines with a 6% increase in throughput,
and the data pattern on the wire is much more constant (i have tcpdumps,
do you want to see them Dave?)
I'm looking forward to trying the split out patches tomorrow.
here is my (compile tested) patch, for e1000
diff -rup e1000-6.0.60.orig/src/e1000_main.c e1000-6.0.60/src/e1000_main.c
--- e1000-6.0.60.orig/src/e1000_main.c 2005-06-07 19:07:37.000000000 -0700
+++ e1000-6.0.60/src/e1000_main.c 2005-06-07 19:15:05.000000000 -0700
@@ -3074,11 +3074,14 @@ e1000_clean_rx_irq(struct e1000_adapter
next_desc:
rx_desc->status = 0;
buffer_info->skb = NULL;
+ if(unlikely((i & ~(E1000_RX_BUFFER_WRITE - 1)) == i))
+ adapter->alloc_rx_buf(adapter);
if(unlikely(++i == rx_ring->count)) i = 0;
rx_desc = E1000_RX_DESC(*rx_ring, i);
}
rx_ring->next_to_clean = i;
+ /* not sure this is necessary any more, but its safe */
adapter->alloc_rx_buf(adapter);
return cleaned;
@@ -3209,12 +3212,15 @@ e1000_clean_rx_irq_ps(struct e1000_adapt
next_desc:
rx_desc->wb.middle.status_error &= ~0xFF;
buffer_info->skb = NULL;
+ if(unlikely((i & ~(E1000_RX_BUFFER_WRITE - 1)) == i))
+ adapter->alloc_rx_buf(adapter);
if(unlikely(++i == rx_ring->count)) i = 0;
rx_desc = E1000_RX_DESC_PS(*rx_ring, i);
staterr = le32_to_cpu(rx_desc->wb.middle.status_error);
}
rx_ring->next_to_clean = i;
+ /* not sure this is necessary any more, but its safe */
adapter->alloc_rx_buf(adapter);
return cleaned;
PS e1000-6.0.60 is posted on sf.net/projects/e1000 now.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: David S. Miller @ 2005-06-08 3:31 UTC (permalink / raw)
To: jesse.brandeburg
Cc: john.ronciak, hadi, shemminger, mitch.a.williams, mchan, buytenh,
jdmason, netdev, Robert.Olsson, ganesh.venkatesan
In-Reply-To: <Pine.LNX.4.62.0506071852290.31708@ladlxr>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Tue, 7 Jun 2005 19:20:37 -0700 (PDT)
> I'm looking forward to trying the split out patches tomorrow.
Don't get too excited, those are purely bug fixes and don't
actually do the actual "Super TSO" part yet. I'm trying to
test the cleanups leading up to the actual TSO segmenting change
to make sure any such regressions therein get weeded out.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: David S. Miller @ 2005-06-08 3:43 UTC (permalink / raw)
To: jesse.brandeburg
Cc: john.ronciak, hadi, shemminger, mitch.a.williams, mchan, buytenh,
jdmason, netdev, Robert.Olsson, ganesh.venkatesan
In-Reply-To: <Pine.LNX.4.62.0506071852290.31708@ladlxr>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Tue, 7 Jun 2005 19:20:37 -0700 (PDT)
> with the 2.6.12-rc5 kernel (the old) tso promptly shuts down after a SACK,
> and after that point the machine is CPU bound at 100%. This is the point
> that we start to drop packets at the hardware level.
You're getting packet loss on the local network where you're
running these tests? Or is it simple packet reordering?
> I tried the experiment today where I replenish buffers to hardware every
> 16 packets or so. This appears to mitigate all drops at the hardware
> level (no drops). We're still at 100% with the rc5 kernel, however.
>
> even with this replenish fix, the addition of dropping the weight to 16
> helped increase our throughput, although only about 1%.
Any minor timing difference of any kind can have up to a %3 or
%4 difference in TCP performance when the receiver is CPU
limited.
> On the other hand, taking our driver as is with no changes and running the
> supertso (not the split out version, yet) kernel, we show no dropped
> packets and 60% cpu use. This combines with a 6% increase in throughput,
> and the data pattern on the wire is much more constant (i have tcpdumps,
> do you want to see them Dave?)
Yes, indeed the tcpdumps tend to look much nicer with supertso.
The 10gbit guys see regressions though. They are helping me
test things gradually in order to track down what change causes
the problems. That's why I've started rewriting super TSO from
scratch in a series of very small patches.
I don't see how supertso can help the receiver, which is where
the RX drops should be occuring. That's a little weird.
I can't believe a 2.5 GHZ machine can't keep up with a simple 1 Gbit
TCP stream. Do you have some other computation going on in that
system? As stated yesterday my 1.5 GHZ crappy sparc64 box can receive
a 1 Gbit TCP stream with much cpu to spare, my 750 MHZ sparc64 box can
nearly do so as well.
Something is up, if a single gigabit TCP stream can fully CPU
load your machine. 10 gigabit, yeah, definitely all current
generation machines are cpu limited over that link speed, but
1 gigabit should be no problem.
^ permalink raw reply
* 痙攣する秘部
From: 溢れ出る蜜 @ 2005-06-08 6:03 UTC (permalink / raw)
To: netdev
右手で透き通った蜜を指に絡め
空いている方の手で柔らかな膨らみを確認し
壊さないようにゆっくりと揉んでゆく
http://handachi.com/?80620190458024927
一つになりたいと思った
少しづつ彼女の中へと己自身を進める
彼女の顔が歪んだ
http://handachi.com/?80620190458024927
^ permalink raw reply
* [-mm] ipw2100 cleanups: no X___ prefixes
From: Pavel Machek @ 2005-06-08 13:20 UTC (permalink / raw)
To: Netdev list, James P. Ketrenos, Andrew Morton
ipw2100 uses strange X__ prefixes even for symbols already prefixed
by ipw2100. Fixed.
Signed-off-by: Pavel Machek <pavel@suse.cz>
--- /data/l/clean-mm/drivers/net/wireless/ipw2100.c 2005-06-08 12:11:29.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2100.c 2005-06-08 15:09:26.000000000 +0200
@@ -106,7 +106,7 @@
tx_pend_list : Holds used Tx buffers waiting to go into the TBD ring
TAIL modified ipw2100_tx()
- HEAD modified by X__ipw2100_tx_send_data()
+ HEAD modified by ipw2100_tx_send_data()
msg_free_list : Holds pre-allocated Msg (Command) buffers
TAIL modified in __ipw2100_tx_process()
@@ -114,7 +114,7 @@
msg_pend_list : Holds used Msg buffers waiting to go into the TBD ring
TAIL modified in ipw2100_hw_send_command()
- HEAD modified in X__ipw2100_tx_send_commands()
+ HEAD modified in ipw2100_tx_send_commands()
The flow of data on the TX side is as follows:
@@ -287,8 +279,8 @@
/* Pre-decl until we get the code solid and then we can clean it up */
-static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv);
-static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv);
+static void ipw2100_tx_send_commands(struct ipw2100_priv *priv);
+static void ipw2100_tx_send_data(struct ipw2100_priv *priv);
static int ipw2100_adapter_setup(struct ipw2100_priv *priv);
static void ipw2100_queues_initialize(struct ipw2100_priv *priv);
@@ -2841,14 +2736,14 @@
while (__ipw2100_tx_process(priv) && i < 200) i++;
if (i == 200) {
- IPW_DEBUG_WARNING(
+ printk(KERN_WARNING DRV_NAME ": "
"%s: Driver is running slow (%d iters).\n",
priv->net_dev->name, i);
}
}
-static void X__ipw2100_tx_send_commands(struct ipw2100_priv *priv)
+static void ipw2100_tx_send_commands(struct ipw2100_priv *priv)
{
struct list_head *element;
struct ipw2100_tx_packet *packet;
@@ -2916,10 +2811,10 @@
/*
- * X__ipw2100_tx_send_data
+ * ipw2100_tx_send_data
*
*/
-static void X__ipw2100_tx_send_data(struct ipw2100_priv *priv)
+static void ipw2100_tx_send_data(struct ipw2100_priv *priv)
{
struct list_head *element;
struct ipw2100_tx_packet *packet;
@@ -3134,8 +3029,8 @@
IPW2100_INTA_TX_TRANSFER);
__ipw2100_tx_complete(priv);
- X__ipw2100_tx_send_commands(priv);
- X__ipw2100_tx_send_data(priv);
+ ipw2100_tx_send_commands(priv);
+ ipw2100_tx_send_data(priv);
}
if (inta & IPW2100_INTA_TX_COMPLETE) {
@@ -3286,7 +3179,7 @@
list_add_tail(element, &priv->tx_pend_list);
INC_STAT(&priv->tx_pend_stat);
- X__ipw2100_tx_send_data(priv);
+ ipw2100_tx_send_data(priv);
spin_unlock_irqrestore(&priv->low_lock, flags);
return 0;
^ permalink raw reply
* oops with hostap and 2.6.12-rc6-mm1: Kernel BUG at "net/ipv4/tcp_output.c":928
From: belyshev @ 2005-06-08 13:21 UTC (permalink / raw)
To: netdev
Seems that this oops happens only if using hostap.
$ cat /dev/zero | nc host.com discard
^C
Segmentation fault
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at "net/ipv4/tcp_output.c":928
invalid operand: 0000 [1]
CPU 0
Modules linked in: hostap_cs hostap
Pid: 3312, comm: nc Not tainted 2.6.12-rc6-mm1
RIP: 0010:[<ffffffff803ea297>] <ffffffff803ea297>{tcp_tso_should_defer+55}
RSP: 0018:ffff810015769c10 EFLAGS: 00010246
RAX: 0000000000000017 RBX: ffff81001e751340 RCX: 0000000005a80100
RDX: ffff81001e751340 RSI: ffff81001388aac0 RDI: 0000000000000002
RBP: ffff81001388aac0 R08: 0000000000000000 R09: ffff810015769d58
R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000
R13: 0000000000000000 R14: ffff81001388aac0 R15: 0000000000000018
FS: 00002aaaaae00c80(0000) GS:ffffffff8082e840(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000005c5008 CR3: 0000000013eb4000 CR4: 00000000000006e0
Process nc (pid: 3312, threadinfo ffff810015768000, task ffff81001ed2b750)
Stack: ffffffff803ecaa4 ffff8100016c7bd8 000005a800000001 0000000000000001
ffff81001388aac0 ffff81001388aac0 0000000000000000 0000000000000000
ffff810019e4e888 ffff81001559f828
Call Trace:<ffffffff803ecaa4>{tcp_write_xmit+196} <ffffffff803ece79>{__tcp_push_pending_frames+41}
<ffffffff803e1361>{tcp_close+593} <ffffffff803fd9ec>{inet_release+92}
<ffffffff80398b41>{sock_release+33} <ffffffff803993c5>{sock_close+53}
<ffffffff80175ee2>{__fput+194} <ffffffff801733d8>{filp_close+104}
<ffffffff80133fd4>{put_files_struct+116} <ffffffff80134f1a>{do_exit+522}
<ffffffff80135931>{do_group_exit+177} <ffffffff8013f657>{get_signal_to_deliver+1255}
<ffffffff8010e0fd>{do_signal+157} <ffffffff80146f90>{autoremove_wake_function+0}
<ffffffff8019ac79>{inotify_inode_queue_event+41} <ffffffff8017551f>{vfs_write+303}
<ffffffff8010ea33>{sysret_signal+28} <ffffffff8010ed1b>{ptregscall_common+103}
Code: 0f 0b de b7 4f 80 ff ff ff ff a0 03 44 8b 8e 14 03 00 00 44
RIP <ffffffff803ea297>{tcp_tso_should_defer+55} RSP <ffff810015769c10>
<1>Fixing recursive fault but reboot is needed!
^ permalink raw reply
* [-mm] ipw2100: cleanup debug prints
From: Pavel Machek @ 2005-06-08 13:28 UTC (permalink / raw)
To: Netdev list, James P. Ketrenos, Andrew Morton
ipw2100 uses custom debug prints that are sometimes longer and always
harder to read than normal printk. They also introduced some bugs where
prefix is printed twice.
Signed-off-by: Pavel Machek <pavel@suse.cz>
--- /data/l/clean-mm/drivers/net/wireless/ipw2100.c 2005-06-08 12:11:29.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2100.c 2005-06-08 15:09:26.000000000 +0200
@@ -484,7 +476,7 @@
u32 total_length;
if (ordinals->table1_addr == 0) {
- IPW_DEBUG_WARNING(DRV_NAME ": attempt to use fw ordinals "
+ printk(KERN_WARNING DRV_NAME ": attempt to use fw ordinals "
"before they have been loaded.\n");
return -EINVAL;
}
@@ -493,8 +485,7 @@
if (*len < IPW_ORD_TAB_1_ENTRY_SIZE) {
*len = IPW_ORD_TAB_1_ENTRY_SIZE;
- IPW_DEBUG_WARNING(DRV_NAME
- ": ordinal buffer length too small, need %d\n",
+ printk(KERN_WARNING DRV_NAME ": ordinal buffer length too small, need %d\n",
IPW_ORD_TAB_1_ENTRY_SIZE);
return -EINVAL;
@@ -546,7 +537,7 @@
return 0;
}
- IPW_DEBUG_WARNING(DRV_NAME ": ordinal %d neither in table 1 nor "
+ printk(KERN_WARNING DRV_NAME ": ordinal %d neither in table 1 nor "
"in table 2\n", ord);
return -EINVAL;
@@ -761,7 +752,7 @@
}
if (priv->fatal_error) {
- IPW_DEBUG_WARNING("%s: firmware fatal error\n",
+ printk(KERN_WARNING DRV_NAME ": %s: firmware fatal error\n",
priv->net_dev->name);
return -EIO;
}
@@ -1001,7 +975,7 @@
/* load microcode */
err = ipw2100_ucode_download(priv, &ipw2100_firmware);
if (err) {
- IPW_DEBUG_ERROR("%s: Error loading microcode: %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Error loading microcode: %d\n",
priv->net_dev->name, err);
goto fail;
}
@@ -1014,7 +988,7 @@
/* s/w reset and clock stabilization (again!!!) */
err = sw_reset_and_clock(priv);
if (err) {
- IPW_DEBUG_ERROR("%s: sw_reset_and_clock failed: %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: sw_reset_and_clock failed: %d\n",
priv->net_dev->name, err);
goto fail;
}
@@ -1210,7 +1163,7 @@
* fw & dino ucode
*/
if (ipw2100_download_firmware(priv)) {
- IPW_DEBUG_ERROR("%s: Failed to power on the adapter.\n",
+ printk(KERN_ERR DRV_NAME ": %s: Failed to power on the adapter.\n",
priv->net_dev->name);
return -EIO;
}
@@ -1270,7 +1223,7 @@
i ? "SUCCESS" : "FAILED");
if (!i) {
- IPW_DEBUG_WARNING("%s: Firmware did not initialize.\n",
+ printk(KERN_WARNING DRV_NAME ": %s: Firmware did not initialize.\n",
priv->net_dev->name);
return -EIO;
}
@@ -1466,7 +1416,7 @@
err = ipw2100_hw_phy_off(priv);
if (err)
- IPW_DEBUG_WARNING("Error disabling radio %d\n", err);
+ printk(KERN_WARNING DRV_NAME ": Error disabling radio %d\n", err);
/*
* If in D0-standby mode going directly to D3 may cause a
@@ -1492,7 +1442,7 @@
err = ipw2100_hw_send_command(priv, &cmd);
if (err)
- IPW_DEBUG_WARNING(
+ printk(KERN_WARNING DRV_NAME ": "
"%s: Power down command failed: Error %d\n",
priv->net_dev->name, err);
else {
@@ -1533,7 +1483,7 @@
}
if (i == 0)
- IPW_DEBUG_WARNING(DRV_NAME
+ printk(KERN_WARNING DRV_NAME
": %s: Could now power down adapter.\n",
priv->net_dev->name);
@@ -1573,13 +1523,13 @@
err = ipw2100_hw_send_command(priv, &cmd);
if (err) {
- IPW_DEBUG_WARNING("exit - failed to send CARD_DISABLE command\n");
+ printk(KERN_WARNING DRV_NAME ": exit - failed to send CARD_DISABLE command\n");
goto fail_up;
}
err = ipw2100_wait_for_card_state(priv, IPW_HW_STATE_DISABLED);
if (err) {
- IPW_DEBUG_WARNING("exit - card failed to change to DISABLED\n");
+ printk(KERN_WARNING DRV_NAME ": exit - card failed to change to DISABLED\n");
goto fail_up;
}
@@ -1689,7 +1633,7 @@
(priv->status & STATUS_RESET_PENDING)) {
/* Power cycle the card ... */
if (ipw2100_power_cycle_adapter(priv)) {
- IPW_DEBUG_WARNING("%s: Could not cycle adapter.\n",
+ printk(KERN_WARNING DRV_NAME ": %s: Could not cycle adapter.\n",
priv->net_dev->name);
rc = 1;
goto exit;
@@ -1699,7 +1643,7 @@
/* Load the firmeware, start the clocks, etc. */
if (ipw2100_start_adapter(priv)) {
- IPW_DEBUG_ERROR("%s: Failed to start the firmware.\n",
+ printk(KERN_ERR DRV_NAME ": %s: Failed to start the firmware.\n",
priv->net_dev->name);
rc = 1;
goto exit;
@@ -1709,7 +1653,7 @@
/* Determine capabilities of this particular HW configuration */
if (ipw2100_get_hw_features(priv)) {
- IPW_DEBUG_ERROR("%s: Failed to determine HW features.\n",
+ printk(KERN_ERR DRV_NAME ": %s: Failed to determine HW features.\n",
priv->net_dev->name);
rc = 1;
goto exit;
@@ -1717,7 +1661,7 @@
lock = LOCK_NONE;
if (ipw2100_set_ordinal(priv, IPW_ORD_PERS_DB_LOCK, &lock, &ord_len)) {
- IPW_DEBUG_ERROR("%s: Failed to clear ordinal lock.\n",
+ printk(KERN_ERR DRV_NAME ": %s: Failed to clear ordinal lock.\n",
priv->net_dev->name);
rc = 1;
goto exit;
@@ -1743,7 +1687,7 @@
/* Send all of the commands that must be sent prior to
* HOST_COMPLETE */
if (ipw2100_adapter_setup(priv)) {
- IPW_DEBUG_ERROR("%s: Failed to start the card.\n",
+ printk(KERN_ERR DRV_NAME ": %s: Failed to start the card.\n",
priv->net_dev->name);
rc = 1;
goto exit;
@@ -1752,7 +1696,7 @@
if (!deferred) {
/* Enable the adapter - sends HOST_COMPLETE */
if (ipw2100_enable_adapter(priv)) {
- IPW_DEBUG_ERROR(
+ printk(KERN_ERR DRV_NAME ": "
"%s: failed in call to enable adapter.\n",
priv->net_dev->name);
ipw2100_hw_stop_adapter(priv);
@@ -1810,7 +1754,7 @@
spin_unlock_irqrestore(&priv->low_lock, flags);
if (ipw2100_hw_stop_adapter(priv))
- IPW_DEBUG_ERROR("%s: Error stopping adapter.\n",
+ printk(KERN_ERR DRV_NAME ": %s: Error stopping adapter.\n",
priv->net_dev->name);
/* Do not disable the interrupt until _after_ we disable
@@ -2417,7 +2312,7 @@
/* We need to allocate a new SKB and attach it to the RDB. */
if (unlikely(ipw2100_alloc_skb(priv, packet))) {
- IPW_DEBUG_WARNING(
+ printk(KERN_WARNING DRV_NAME ": "
"%s: Unable to allocate SKB onto RBD ring - disabling "
"adapter.\n", priv->net_dev->name);
/* TODO: schedule adapter shutdown */
@@ -2679,7 +2574,7 @@
break;
default:
- IPW_DEBUG_WARNING("%s: Bad fw_pend_list entry!\n",
+ printk(KERN_WARNING DRV_NAME ": %s: Bad fw_pend_list entry!\n",
priv->net_dev->name);
return 0;
}
@@ -2693,7 +2588,7 @@
read_register(priv->net_dev, IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX,
&w);
if (w != txq->next)
- IPW_DEBUG_WARNING("%s: write index mismatch\n",
+ printk(KERN_WARNING DRV_NAME ": %s: write index mismatch\n",
priv->net_dev->name);
/*
@@ -2754,7 +2649,7 @@
switch (packet->type) {
case DATA:
if (txq->drv[txq->oldest].status.info.fields.txType != 0)
- IPW_DEBUG_WARNING("%s: Queue mismatch. "
+ printk(KERN_WARNING DRV_NAME ": %s: Queue mismatch. "
"Expecting DATA TBD but pulled "
"something else: ids %d=%d.\n",
priv->net_dev->name, txq->oldest, packet->index);
@@ -2801,7 +2696,7 @@
case COMMAND:
if (txq->drv[txq->oldest].status.info.fields.txType != 1)
- IPW_DEBUG_WARNING("%s: Queue mismatch. "
+ printk(KERN_WARNING DRV_NAME ": %s: Queue mismatch. "
"Expecting COMMAND TBD but pulled "
"something else: ids %d=%d.\n",
priv->net_dev->name, txq->oldest, packet->index);
@@ -3085,7 +2980,7 @@
(unsigned long)inta & IPW_INTERRUPT_MASK);
if (inta & IPW2100_INTA_FATAL_ERROR) {
- IPW_DEBUG_WARNING(DRV_NAME
+ printk(KERN_WARNING DRV_NAME
": Fatal interrupt. Scheduling firmware restart.\n");
priv->inta_other++;
write_register(
@@ -3105,7 +3000,7 @@
}
if (inta & IPW2100_INTA_PARITY_ERROR) {
- IPW_DEBUG_ERROR("***** PARITY ERROR INTERRUPT !!!! \n");
+ printk(KERN_ERR DRV_NAME ": ***** PARITY ERROR INTERRUPT !!!! \n");
priv->inta_other++;
write_register(
dev, IPW_REG_INTA,
@@ -3223,7 +3116,7 @@
if (inta == 0xFFFFFFFF) {
/* Hardware disappeared */
- IPW_DEBUG_WARNING("IRQ INTA == 0xFFFFFFFF\n");
+ printk(KERN_WARNING DRV_NAME ": IRQ INTA == 0xFFFFFFFF\n");
goto none;
}
@@ -3308,7 +3201,7 @@
IPW_COMMAND_POOL_SIZE * sizeof(struct ipw2100_tx_packet),
GFP_KERNEL);
if (!priv->msg_buffers) {
- IPW_DEBUG_ERROR("%s: PCI alloc failed for msg "
+ printk(KERN_ERR DRV_NAME ": %s: PCI alloc failed for msg "
"buffers.\n", priv->net_dev->name);
return -ENOMEM;
}
@@ -3319,7 +3212,7 @@
sizeof(struct ipw2100_cmd_header),
&p);
if (!v) {
- IPW_DEBUG_ERROR(
+ printk(KERN_ERR DRV_NAME ": "
"%s: PCI alloc failed for msg "
"buffers.\n",
priv->net_dev->name);
@@ -3826,7 +3289,7 @@
err = ipw2100_disable_adapter(priv);
if (err) {
- IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n",
priv->net_dev->name, err);
return err;
}
@@ -4272,7 +3557,7 @@
TX_PENDED_QUEUE_LENGTH * sizeof(struct ipw2100_tx_packet),
GFP_ATOMIC);
if (!priv->tx_buffers) {
- IPW_DEBUG_ERROR("%s: alloc failed form tx buffers.\n",
+ printk(KERN_ERR DRV_NAME ": %s: alloc failed form tx buffers.\n",
priv->net_dev->name);
bd_queue_free(priv, &priv->tx_queue);
return -ENOMEM;
@@ -4282,7 +3567,7 @@
v = pci_alloc_consistent(
priv->pci_dev, sizeof(struct ipw2100_data_header), &p);
if (!v) {
- IPW_DEBUG_ERROR("%s: PCI alloc failed for tx "
+ printk(KERN_ERR DRV_NAME ": %s: PCI alloc failed for tx "
"buffers.\n", priv->net_dev->name);
err = -ENOMEM;
break;
@@ -4593,7 +3852,7 @@
if (!batch_mode) {
err = ipw2100_disable_adapter(priv);
if (err) {
- IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n",
priv->net_dev->name, err);
return err;
}
@@ -5212,7 +4390,7 @@
if (!batch_mode) {
err = ipw2100_disable_adapter(priv);
if (err) {
- IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n",
priv->net_dev->name, err);
return err;
}
@@ -5300,7 +4478,7 @@
err = ipw2100_disable_adapter(priv);
/* FIXME: IPG: shouldn't this prink be in _disable_adapter()? */
if (err) {
- IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n",
priv->net_dev->name, err);
return err;
}
@@ -5336,7 +4514,7 @@
if (!batch_mode) {
err = ipw2100_disable_adapter(priv);
if (err) {
- IPW_DEBUG_ERROR("%s: Could not disable adapter %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Could not disable adapter %d\n",
priv->net_dev->name, err);
return err;
}
@@ -5884,7 +5049,7 @@
break;
default:
- IPW_DEBUG_ERROR("%s: Unknown WPA param: %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Unknown WPA param: %d\n",
dev->name, name);
ret = -EOPNOTSUPP;
}
@@ -5907,7 +5072,7 @@
break;
default:
- IPW_DEBUG_ERROR("%s: Unknown MLME request: %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Unknown MLME request: %d\n",
dev->name, command);
ret = -EOPNOTSUPP;
}
@@ -6157,7 +5322,7 @@
break;
default:
- IPW_DEBUG_ERROR("%s: Unknown WPA supplicant request: %d\n",
+ printk(KERN_ERR DRV_NAME ": %s: Unknown WPA supplicant request: %d\n",
dev->name, param->cmd);
ret = -EOPNOTSUPP;
@@ -8395,7 +7531,7 @@
(struct ipw2100_fw_header *)fw->fw_entry->data;
if (IPW2100_FW_MAJOR(h->version) != IPW2100_FW_MAJOR_VERSION) {
- IPW_DEBUG_WARNING("Firmware image not compatible "
+ printk(KERN_WARNING DRV_NAME ": Firmware image not compatible "
"(detected version id of %u). "
"See Documentation/networking/README.ipw2100\n",
h->version);
@@ -8438,7 +7574,7 @@
rc = request_firmware(&fw->fw_entry, fw_name, &priv->pci_dev->dev);
if (rc < 0) {
- IPW_DEBUG_ERROR(
+ printk(KERN_ERR DRV_NAME ": "
"%s: Firmware '%s' not available or load failed.\n",
priv->net_dev->name, fw_name);
return rc;
@@ -8520,7 +7656,7 @@
firmware_data_left -= 2;
if (len > 32) {
- IPW_DEBUG_ERROR(
+ printk(KERN_ERR DRV_NAME ": "
"Invalid firmware run-length of %d bytes\n",
len);
return -EINVAL;
@@ -8630,7 +7766,7 @@
}
if (i == 10) {
- IPW_DEBUG_ERROR("%s: Error initializing Symbol\n",
+ printk(KERN_ERR DRV_NAME ": %s: Error initializing Symbol\n",
dev->name);
return -EIO;
}
@@ -8651,7 +7787,7 @@
}
if (i == 30) {
- IPW_DEBUG_ERROR("%s: No response from Symbol - hw not alive\n",
+ printk(KERN_ERR DRV_NAME ": %s: No response from Symbol - hw not alive\n",
dev->name);
printk_buf(IPW_DL_ERROR, (u8*)&response, sizeof(response));
return -EIO;
^ permalink raw reply
* Re: netdev munching messages again?
From: Thomas Graf @ 2005-06-08 13:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050607.144237.93024273.davem@davemloft.net>
* David S. Miller <20050607.144237.93024273.davem@davemloft.net> 2005-06-07 14:42
> I did get all of your postings because you sent them
> with me on the CC: list, but netdev only sent out
> 6 and 7 to me just as you observed.
I tried to resend, the message were accepted by oss.sgi.com but
none of them came back. Maybe dropped due to duplicated message
ids though.
> This has become a regular occurance, it may be time to finally move
> this thing over to vger.kernel.org. Thoughts?
I have no personal objections, would be valuable to take over the
archives though.
^ permalink raw reply
* [-mm] ipw2100: assume recent kernel
From: Pavel Machek @ 2005-06-08 13:31 UTC (permalink / raw)
To: Netdev list, James P. Ketrenos, Andrew Morton
ipw2100 still has support for old kernels. Thats considered bad for
patch in mainline... this fixes few instances.
Signed-off-by: Pavel Machek <pavel@suse.cz>
--- /data/l/clean-mm/drivers/net/wireless/ipw2100.c 2005-06-08 12:11:29.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2100.c 2005-06-08 15:09:26.000000000 +0200
@@ -6719,17 +5873,9 @@
/* Remove the PRESENT state of the device */
netif_device_detach(dev);
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10)
- pci_save_state(pci_dev, priv->pm_state);
-#else
pci_save_state(pci_dev);
-#endif
pci_disable_device (pci_dev);
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11)
- pci_set_power_state(pci_dev, state);
-#else
pci_set_power_state(pci_dev, PCI_D3hot);
-#endif
up(&priv->action_sem);
@@ -6750,17 +5896,9 @@
IPW_DEBUG_INFO("%s: Coming out of suspend...\n",
dev->name);
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11)
- pci_set_power_state(pci_dev, 0);
-#else
pci_set_power_state(pci_dev, PCI_D0);
-#endif
pci_enable_device(pci_dev);
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10)
- pci_restore_state(pci_dev, priv->pm_state);
-#else
pci_restore_state(pci_dev);
-#endif
/*
* Suspend/Resume resets the PCI configuration space, so we have to
--- /data/l/clean-mm/drivers/net/wireless/ipw2100.h 2005-06-08 12:11:29.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2100.h 2005-06-08 15:07:31.000000000 +0200
@@ -44,30 +44,6 @@
#include <linux/workqueue.h>
-#ifndef IRQ_NONE
-typedef void irqreturn_t;
-#define IRQ_NONE
-#define IRQ_HANDLED
-#define IRQ_RETVAL(x)
-#endif
-
-#if WIRELESS_EXT < 17
-#define IW_QUAL_QUAL_INVALID 0x10
-#define IW_QUAL_LEVEL_INVALID 0x20
-#define IW_QUAL_NOISE_INVALID 0x40
-#endif
-
-#if ( LINUX_VERSION_CODE < KERNEL_VERSION(2,6,5) )
-#define pci_dma_sync_single_for_cpu pci_dma_sync_single
-#define pci_dma_sync_single_for_device pci_dma_sync_single
-#endif
-
-#ifndef HAVE_FREE_NETDEV
-#define free_netdev(x) kfree(x)
-#endif
-
-
-
struct ipw2100_priv;
struct ipw2100_tx_packet;
struct ipw2100_rx_packet;
^ permalink raw reply
* [-mm] ipw2100: kill dead macros
From: Pavel Machek @ 2005-06-08 13:35 UTC (permalink / raw)
To: Netdev list, James P. Ketrenos, Andrew Morton
There are several never used macros in ipw2100. This removes them.
Signed-off-by: Pavel Machek <pavel@suse.cz>
--- /data/l/clean-mm/drivers/net/wireless/ipw2100.c 2005-06-08 12:11:29.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2100.c 2005-06-08 15:09:26.000000000 +0200
@@ -1118,7 +1074,6 @@
{
#define MAX_RF_KILL_CHECKS 5
#define RF_KILL_CHECK_DELAY 40
-#define RF_KILL_CHECK_THRESHOLD 3
unsigned short value = 0;
u32 reg = 0;
--- /data/l/clean-mm/drivers/net/wireless/ipw2100.h 2005-06-08 12:11:29.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2100.h 2005-06-08 15:07:31.000000000 +0200
@@ -167,15 +141,6 @@
#define IPW_DEBUG_STATE(f, a...) IPW_DEBUG(IPW_DL_STATE | IPW_DL_ASSOC | IPW_DL_INFO, f, ## a)
#define IPW_DEBUG_ASSOC(f, a...) IPW_DEBUG(IPW_DL_ASSOC | IPW_DL_INFO, f, ## a)
-
-#define VERIFY(f) \
-{ \
- int status = 0; \
- status = f; \
- if(status) \
- return status; \
-}
-
enum {
IPW_HW_STATE_DISABLED = 1,
IPW_HW_STATE_ENABLED = 0
@@ -210,8 +175,6 @@
} info;
} __attribute__ ((packed));
-#define IPW_BUFDESC_LAST_FRAG 0
-
struct ipw2100_bd {
u32 host_addr;
u32 buf_length;
@@ -648,9 +606,6 @@
struct semaphore adapter_sem;
wait_queue_head_t wait_command_queue;
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10)
- u32 pm_state[PM_STATE_SIZE];
-#endif
};
@@ -761,41 +707,6 @@
#define IPW_MEM_HOST_SHARED_TX_QUEUE_WRITE_INDEX \
(IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND)
-
-#if 0
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x00)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x04)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x08)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0c)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x10)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x14)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_BD_BASE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x18)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_BD_SIZE (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x1c)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x80)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x84)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x88)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_READ_INDEX (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x8c)
-
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_BD_BASE(QueueNum) \
- (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + (QueueNum<<3))
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_BD_SIZE(QueueNum) \
- (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0004+(QueueNum<<3))
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_READ_INDEX(QueueNum) \
- (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x0080+(QueueNum<<2))
-
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_0_WRITE_INDEX \
- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x00)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_1_WRITE_INDEX \
- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x04)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_2_WRITE_INDEX \
- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x08)
-#define IPW_MEM_HOST_SHARED_TX_QUEUE_3_WRITE_INDEX \
- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x0c)
-#define IPW_MEM_HOST_SHARED_SLAVE_MODE_INT_REGISTER \
- (IPW_MEM_SRAM_HOST_INTERRUPT_AREA_LOWER_BOUND + 0x78)
-
-#endif
-
#define IPW_MEM_HOST_SHARED_ORDINALS_TABLE_1 (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x180)
#define IPW_MEM_HOST_SHARED_ORDINALS_TABLE_2 (IPW_MEM_SRAM_HOST_SHARED_LOWER_BOUND + 0x184)
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: jamal @ 2005-06-08 13:36 UTC (permalink / raw)
To: David S. Miller
Cc: jesse.brandeburg, john.ronciak, shemminger, mitch.a.williams,
mchan, buytenh, jdmason, netdev, Robert.Olsson, ganesh.venkatesan
In-Reply-To: <20050607.204339.21591152.davem@davemloft.net>
On Tue, 2005-07-06 at 20:43 -0700, David S. Miller wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Date: Tue, 7 Jun 2005 19:20:37 -0700 (PDT)
[..]
> > I tried the experiment today where I replenish buffers to hardware every
> > 16 packets or so. This appears to mitigate all drops at the hardware
> > level (no drops). We're still at 100% with the rc5 kernel, however.
> >
> > even with this replenish fix, the addition of dropping the weight to 16
> > helped increase our throughput, although only about 1%.
>
> Any minor timing difference of any kind can have up to a %3 or
> %4 difference in TCP performance when the receiver is CPU
> limited.
>
Agreed.
[..]
> I don't see how supertso can help the receiver, which is where
> the RX drops should be occuring. That's a little weird.
>
> I can't believe a 2.5 GHZ machine can't keep up with a simple 1 Gbit
> TCP stream. Do you have some other computation going on in that
> system? As stated yesterday my 1.5 GHZ crappy sparc64 box can receive
> a 1 Gbit TCP stream with much cpu to spare, my 750 MHZ sparc64 box can
> nearly do so as well.
>
> Something is up, if a single gigabit TCP stream can fully CPU
> load your machine. 10 gigabit, yeah, definitely all current
> generation machines are cpu limited over that link speed, but
> 1 gigabit should be no problem.
>
Yes, sir.
BTW, all along i thought the sender and receiver are hooked up directly
(there was some mention of chariot a while back).
Even if they did have some smart ass thing in the middle that reorders,
it is still suprising that such a fast CPU cant handle a mere one Gig of
what seems to be MTU=1500 bytes sized packets.
I suppose a netstat -s would help for visualization in addition to those
dumps.
Heres what i am deducing from their data, correct me if i am wrong:
->The evidence is that something is expensive in their code path (duh).
-> Whatever that expensive thing code is, it not helped by them
replenishing the descriptors after all the budget is exhausted since the
descriptor departure rate is much slower than packet arrival.
---> This is why they would be seeing that the reduction of weight
improves performance since the replenishing happens sooner with a
smaller weight.
------> Clearly the driver needs some fixing - if they could do what
their competitor's(who shall remain nameless) driver does or replenish
more often, then that would go some way to help (Jesse's result with
replenish after 16 is proof).
This still hasnt resolved what the problem is but we may be getting
close.
Even if they SACKed for every packet, this still would not make any
sense. So i think a profile of where the cycles are spent would also
help. I am suspecting the driver at this point but i could be wrong.
cheers,
jamal
^ permalink raw reply
* Intel, please fix your email system
From: Pavel Machek @ 2005-06-08 13:42 UTC (permalink / raw)
To: Netdev list, Jeff Garzik, kernel list
Hi!
I attempted to mail ipw2100 maintainer, and got back message about
"inappropriate subject". Subject was "Subject: [-mm] ipw2100: kill
dead macros". I do not think that's inappropriate.
Pavel
This is the Postfix program at host amd.ucw.cz.
I'm sorry to have to inform you that your message could not be
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The Postfix program
<ipw2100-admin@linux.intel.com>: host jf-in.intel.com[134.134.136.18]
said: 553
5.0.0 Inappropriate subject (in reply to end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Encoding: 7bit, Size: 0.4K --]
Reporting-MTA: dns; amd.ucw.cz
X-Postfix-Queue-ID: C9B8F8B8A7
X-Postfix-Sender: rfc822; pavel@ucw.cz
Arrival-Date: Wed, 8 Jun 2005 15:35:06 +0200 (CEST)
Final-Recipient: rfc822; ipw2100-admin@linux.intel.com
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host jf-in.intel.com[134.134.136.18] said:
553
5.0.0 Inappropriate subject (in reply to end of DATA command)
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Encoding: 7bit, Size: 4.3K --]
To: Netdev list <netdev@oss.sgi.com>,
"James P. Ketrenos" <ipw2100-admin@linux.intel.com>,
Andrew Morton <akpm@zip.com.au>
^ permalink raw reply
* Re: netdev munching messages again?
From: jamal @ 2005-06-08 13:44 UTC (permalink / raw)
To: Thomas Graf; +Cc: Ralf Baechle, David S. Miller, netdev
In-Reply-To: <20050608132953.GK20969@postel.suug.ch>
I thought netdev just picks on me ;-> My stoopid ISP as well
as oss.sgi.com have some "clever" (read: questionable) ways
of delivering email which violates end to end semantics of SMTP.
I too noticed some emails were swallowed in the last 1-2 days. I know
from past experience in fact they will never be seen again;->
Or someone, who doesnt look at the headers, will flame me for repeating
what has already been discussed and agreed on (has happened to me at
least 5 times on netdev ;->).
It's quiet ironic when packets delivered over TCP dont make it to the
remote end, even when the app tries to help in reliable delivery;->
CCing El-sido Bacchus.
cheers,
jamal
On Wed, 2005-08-06 at 15:29 +0200, Thomas Graf wrote:
> * David S. Miller <20050607.144237.93024273.davem@davemloft.net> 2005-06-07 14:42
> > I did get all of your postings because you sent them
> > with me on the CC: list, but netdev only sent out
> > 6 and 7 to me just as you observed.
>
> I tried to resend, the message were accepted by oss.sgi.com but
> none of them came back. Maybe dropped due to duplicated message
> ids though.
>
> > This has become a regular occurance, it may be time to finally move
> > this thing over to vger.kernel.org. Thoughts?
>
> I have no personal objections, would be valuable to take over the
> archives though.
>
>
^ permalink raw reply
* dl2k tx timeout problems
From: Jon Mason @ 2005-06-08 14:10 UTC (permalink / raw)
To: MOUNIER Emmanuel; +Cc: netdev
In-Reply-To: <883AD1ABBCC79842ACCEDB1BE3E5B78C03B2B5F6@srvexch01siege.Outremer.rfo.fr>
Bonjour,
Please see my comments below.
On 6/8/05, MOUNIER Emmanuel <Emmanuel.MOUNIER@rfo.fr> wrote:
> Hello!
> I'm not sure, but I think the EMT 64 is for the extended PCI Slot (64bits), right?
Actually no, EMT64 is Intel's version of 64bit extensions (similar to
AMD's athlon64/opteron). This enables you to run a 64bit kernel or a
32bit kernel. If you installed a standard x86 version of Linux, then
you are running in 32bit mode. if you installed something for x86_64
(sometimes called amd64), then you are running in 64bit mode. "uname
-a" will show you which one you are running.
> If it's true, yes, my card work in 64bits mode, and I think it's maybe the problem, because the DGE-550SX card work perfectly on some of our old server in standard PCI slot (32bits).
I think this is worth noting. I'll investigate this with my copper adapter.
> I've tried many kernel versions without success, but actually I'm running kernel 2.6.8.1-10smp on a Mandrake Linux 10.1.
What other kernels have you tried? Have you tried a vanilla kernel
from kernel.org?
> Now, I will try to explain my problem as clear as I can:
>
> I've plugged the card, and turned on my Linux box. The card was detected perfectly and the module was loaded at the boot.
>
> I can assign an IP address to the card, and I'm able to ping my network. After a short time, the network traffic completely hangs and it says: TX timeout, is buffer full?
how long (an estimate is fine) before the system experiences the tx
timeout? What kind of network traffic is the systeming doing during
this time? Are the systems idle? are they running NFS?
> When I restart the network service, I can see in my logs that Linux simply disable the IRQ of my NIC:
Can you send me the output of "lspci -v"? This will help confirm that
no other devices shares the same interrupt.
> /var/log/messages :
>
>
>
> FWRFO kernel: eth2: D-Link DGE-550SX Gigabit Ethernet Adapter, 00:0d:88:b5:f3:f5, IRQ 4
>
> FWRFO kernel: tx_coalesce:^I16 packets
>
> FWRFO kernel: rx_coalesce:^I10 packets
>
> FWRFO kernel: rx_timeout: ^I128000 ns
>
> FWRFO kernel: Uhhuh. NMI received. Dazed and confused, but trying to continue
>
> FWRFO kernel: You probably have a hardware problem with your RAM chips
The error above is a memory parity error. That is definately not
good. Are you seeing this error very often?
> FWRFO kernel: eth2: Link off
>
> FWRFO kernel: eth2: Link up
>
> FWRFO kernel: Auto 1000 Mbps, Full duplex
>
> FWRFO kernel: Enable Tx Flow Control
>
> FWRFO kernel: Enable Rx Flow Control
>
> FWRFO kernel: irq 4: nobody cared!
>
> FWRFO kernel: [dump_stack+30/32] dump_stack+0x1e/0x20
>
> FWRFO kernel: [<c0107e3e>] dump_stack+0x1e/0x20
>
> FWRFO kernel: [__report_bad_irq+43/144] __report_bad_irq+0x2b/0x90
>
> FWRFO kernel: [<c010945b>] __report_bad_irq+0x2b/0x90
>
> FWRFO kernel: [note_interrupt+144/176] note_interrupt+0x90/0xb0
>
> FWRFO kernel: [<c0109570>] note_interrupt+0x90/0xb0
>
> FWRFO kernel: [do_IRQ+272/304] do_IRQ+0x110/0x130
>
> FWRFO kernel: [<c0109850>] do_IRQ+0x110/0x130
>
> FWRFO kernel: [common_interrupt+24/32] common_interrupt+0x18/0x20
>
> FWRFO kernel: [<c0107960>] common_interrupt+0x18/0x20
>
> FWRFO kernel: [do_softirq+53/64] do_softirq+0x35/0x40
>
> FWRFO kernel: [<c01278f5>] do_softirq+0x35/0x40
>
> FWRFO kernel: [do_IRQ+279/304] do_IRQ+0x117/0x130
>
> FWRFO kernel: [<c0109857>] do_IRQ+0x117/0x130
>
> FWRFO kernel: [common_interrupt+24/32] common_interrupt+0x18/0x20
>
> FWRFO kernel: [<c0107960>] common_interrupt+0x18/0x20
>
> FWRFO kernel: [pg0+945814381/1069203456] rio_open+0x5d/0x210 [dl2k]
>
> FWRFO kernel: [<f8a51b6d>] rio_open+0x5d/0x210 [dl2k]
>
> FWRFO kernel: [dev_open+232/256] dev_open+0xe8/0x100
>
> FWRFO kernel: [<c0287bf8>] dev_open+0xe8/0x100
>
> FWRFO kernel: [dev_change_flags+88/304] dev_change_flags+0x58/0x130
>
> FWRFO kernel: [<c0289378>] dev_change_flags+0x58/0x130
>
> FWRFO kernel: [devinet_ioctl+1392/1584] devinet_ioctl+0x570/0x630
>
> FWRFO kernel: [<c02cda60>] devinet_ioctl+0x570/0x630
>
> FWRFO kernel: [inet_ioctl+192/208] inet_ioctl+0xc0/0xd0
>
> FWRFO kernel: [<c02cfd60>] inet_ioctl+0xc0/0xd0
>
> FWRFO kernel: [sock_ioctl+522/720] sock_ioctl+0x20a/0x2d0
>
> FWRFO kernel: [<c027ecca>] sock_ioctl+0x20a/0x2d0
>
> FWRFO kernel: [sys_ioctl+586/662] sys_ioctl+0x24a/0x296
>
> FWRFO kernel: [<c0174ffa>] sys_ioctl+0x24a/0x296
>
> FWRFO kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71
>
> FWRFO kernel: [<c0106fa1>] sysenter_past_esp+0x52/0x71
>
> FWRFO kernel: handlers:
>
> FWRFO kernel: [pg0+945816320/1069203456] (rio_interrupt+0x0/0xf0 [dl2k])
>
> FWRFO kernel: [<f8a52300>] (rio_interrupt+0x0/0xf0 [dl2k])
>
> FWRFO kernel: Disabling IRQ #4
The bad interrupt is most likely related to the restarting of the
network while the adapter is hung.
> I went to the BIOS setup, and I set the system to not share the IRQ for my NIC.
>
>
>
> I've tried with several DLINK NIC of the same series, and in 4 DL-360 HP servers, so I don't think it's a hardware malfunction.
>
>
>
> I also tried to build a new kernel without power management, and with the Dlink drivers include in the kernel (not in a module).
>
>
>
> I can try as many debug patch as you want =)
Great! I'm sure I'll have something for you to test. I can send you
the patch that I sent to Richard. It solves the problem under light
load, but the network will still hang under high load.
>
>
> And sure, you can forward our mails to the Linux kernel network mailing list.
I have CC'ed them on this e-mail, and changed the subject accordingly.
> I have some knowledge in Linux OS, but I'm very poor in software development, so maybe you must explain me in details what I must do for patching, etc...
>
I'll be happy to explain when the time comes.
> Thanks you very much, and sorry for my poor English...
Your English is very good (and loads better than my French).
> Emmanuel Mounier
>
> Chargé de projet direction Technique
>
> RFO ( www.rfo.fr )
>
> mail : emmanuel.mounier@rfo.fr
>
>
> ________________________________
>
> De: Jon Mason [mailto:jdmason@gmail.com]
> Date: mar. 07/06/2005 18:35
> À: MOUNIER Emmanuel
> Objet : Re: Help : Big Problem With DLINK Fiber NIC
>
>
>
> Bonjour!
>
> I am happy to help. My previous experience has been with the copper
> adapters (I have one at home), but the fiber ones should be fairly
> similar.
>
> From "http://h18004.www1.hp.com/products/servers/proliantdl360/", I
> see that your systems are EMT64. Are you running them in 64bit or
> 32bit? What kernel version are you running?
>
> When you refer to the same problem, I assume you mean tx timeouts.
> How are you causing the error?
>
> I never fully fixed Richards issue, but I was able to get it working
> under light traffic. I got side tracked, and have't looked at the
> problem in a little while. Are you willing to try some debug patches?
>
> With your approval, I would like to CC the netdev mailing list
> (netdev@oss.sgi.com) on these e-mails. netdev is the linux kernel
> network mailing list (incase you didn't already know).
>
> Thanks,
> Jon
>
> On 6/7/05, MOUNIER Emmanuel <Emmanuel.MOUNIER@rfo.fr> wrote:
> >
> >
> >
> > Hello.
> >
> > I'm a french network manager, and I have a big problem with some Dlink
> > Fiber Network cards (DGE-550SX).
> >
> > I've seen on a website that you helped Mr Richard EMS to try to find a
> > solution.
> > (http://www.ussg.iu.edu/hypermail/linux/kernel/0412.2/0371.html)
> >
> > I've contacted him, but he said he have bought another Fiber NIC card.
> >
> > My problem is that I have 13 DGE-550SX cards for 8 HP Server Proliant
> > DL-360 G4, and I have the same problem.
> >
> > Just want to know if you have any idea now, or maybe, if you can bring me
> > some help...
> >
> > Fiber NIC card is very expensive, and I hope I will find a way to solve the
> > problem but, either DLink or HP seem to be able to give me a solution.
> >
> > If I can do something to help you, just tell me what !
> >
> > Thanks per advance.
> >
> > Emmanuel Mounier
> > Chargé de projet direction Technique
> > RFO ( www.rfo.fr )
> > mail : emmanuel.mounier@rfo.fr
>
>
>
>
^ permalink raw reply
* [-mm] ipw2100: small cleanups
From: Pavel Machek @ 2005-06-08 14:20 UTC (permalink / raw)
To: Jeff Garzik, Netdev list, Andrew Morton
Fix few typos/thinkos in ipw, remove ugly macro (it is commented
around, anyway), and fix types passed to pci_set_power_state.
--- middle-mm//drivers/net/wireless/ipw2100.c 2005-06-08 16:15:23.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2100.c 2005-06-08 16:16:27.000000000 +0200
@@ -916,7 +916,7 @@
}
/*********************************************************************
- Procedure : ipw2100_ipw2100_download_firmware
+ Procedure : ipw2100_download_firmware
Purpose : Initiaze adapter after power on.
The sequence is:
1. assert s/w reset first!
@@ -1150,7 +1150,6 @@
*/
static int ipw2100_start_adapter(struct ipw2100_priv *priv)
{
-#define IPW_WAIT_FW_INIT_COMPLETE_DELAY (40 * HZ / 1000)
int i;
u32 inta, inta_mask, gpio;
@@ -1185,7 +1184,7 @@
i = 5000;
do {
set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(IPW_WAIT_FW_INIT_COMPLETE_DELAY);
+ schedule_timeout(40 * HZ / 1000);
/* Todo... wait for sync command ... */
read_register(priv->net_dev, IPW_REG_INTA, &inta);
@@ -1641,7 +1640,7 @@
} else
priv->status |= STATUS_POWERED;
- /* Load the firmeware, start the clocks, etc. */
+ /* Load the firmware, start the clocks, etc. */
if (ipw2100_start_adapter(priv)) {
printk(KERN_ERR DRV_NAME ": %s: Failed to start the firmware.\n",
priv->net_dev->name);
@@ -5679,7 +5678,7 @@
if ((val & 0x0000ff00) != 0)
pci_write_config_dword(pci_dev, 0x40, val & 0xffff00ff);
- pci_set_power_state(pci_dev, 0);
+ pci_set_power_state(pci_dev, PCI_D0);
if (!ipw2100_hw_is_adapter_in_system(dev)) {
printk(KERN_WARNING DRV_NAME
@@ -7206,7 +7205,7 @@
ipw2100_wx_set_wap, /* SIOCSIWAP */
ipw2100_wx_get_wap, /* SIOCGIWAP */
NULL, /* -- hole -- */
- NULL, /* SIOCGIWAPLIST -- depricated */
+ NULL, /* SIOCGIWAPLIST -- deprecated */
ipw2100_wx_set_scan, /* SIOCSIWSCAN */
ipw2100_wx_get_scan, /* SIOCGIWSCAN */
ipw2100_wx_set_essid, /* SIOCSIWESSID */
^ permalink raw reply
* ipw2100: firmware problem
From: Pavel Machek @ 2005-06-08 14:23 UTC (permalink / raw)
To: Jeff Garzik, Netdev list, kernel list, James P. Ketrenos
Hi!
I'm fighting with firmware problem: if ipw2100 is compiled into
kernel, it is loaded while kernel boots and firmware loader is not yet
available. That leads to uninitialized (=> useless) adapter.
What's the prefered way to solve this one? Only load firmware when
user does ifconfig eth1 up? [It is wifi, it looks like it would be
better to start firmware sooner so that it can associate to the
AP...].
Last initcall available in kernel is late_initcall; that's not late
enough for me. Is adding one more initcall that is started when
userland is available a solution?
Pavel
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-08 14:44 UTC (permalink / raw)
To: Pavel Machek, Jeff Garzik, Netdev list, kernel list,
James P. Ketrenos
In-Reply-To: <20050608142310.GA2339@elf.ucw.cz>
On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> Hi!
>
> I'm fighting with firmware problem: if ipw2100 is compiled into
> kernel, it is loaded while kernel boots and firmware loader is not yet
> available. That leads to uninitialized (=> useless) adapter.
>
> What's the prefered way to solve this one? Only load firmware when
> user does ifconfig eth1 up? [It is wifi, it looks like it would be
> better to start firmware sooner so that it can associate to the
> AP...].
Do you want to associate to an AP when your kernel boots,
_before_ any iwconfig had a chance to configure anything?
That's strange.
My position is that wifi drivers must start up in an "OFF" mode.
Do not send anything. Do not join APs or start IBSS.
Thus, no need to load fw in early boot.
Driver may load firmware and start actively doing something
only when iwconfig gets executed and thus driver is
instructed what to do.
Some drivers currently do not act this way, and thus
less advanced users may unknowingly run a wireless STA
(or worse, an AP!) on their notebook for years, interfering
with neighbors and/or violating local regulations (there are
countrles where 802.11 use needs licensing).
--
vda
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Jirka Bohac @ 2005-06-08 14:56 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: Pavel Machek, Jeff Garzik, Netdev list, kernel list
In-Reply-To: <200506081744.20687.vda@ilport.com.ua>
On Wed, Jun 08, 2005 at 05:44:20PM +0300, Denis Vlasenko wrote:
> On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > What's the prefered way to solve this one? Only load firmware when
> > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > better to start firmware sooner so that it can associate to the
> > AP...].
>
> Do you want to associate to an AP when your kernel boots,
> _before_ any iwconfig had a chance to configure anything?
> That's strange.
>
> My position is that wifi drivers must start up in an "OFF" mode.
> Do not send anything. Do not join APs or start IBSS.
Agreed.
> Thus, no need to load fw in early boot.
I don't think this is true. Loading the firmware on the first
"ifconfig up" is problematic. Often, people want to rename the
device from ethX/wlanX/... to something stable. This is usually
based on the adapter's MAC address, which is not visible until
the firmware is loaded.
Prism54 does it this way and it really sucks. You need to bring
the adapter up to load the firmware, then bring it back down,
rename it, and bring it up again.
Denis: any plans for this to be fixed?
I agree that drivers should initialize the adapter in the OFF
state, but the firmware needs to be loaded earlier than the
first ifconfig up.
How about loading the firmware when the first ioctl touches the
device? This way, it would get loaded just before the MAC address
is retrieved.
regards,
--
Jirka Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CR
^ permalink raw reply
* RE: ipw2100: firmware problem
From: Alejandro Bonilla @ 2005-06-08 15:05 UTC (permalink / raw)
To: 'Denis Vlasenko', 'Pavel Machek',
'Jeff Garzik', 'Netdev list',
'kernel list', 'James P. Ketrenos'
In-Reply-To: <200506081744.20687.vda@ilport.com.ua>
> On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > Hi!
> >
> > I'm fighting with firmware problem: if ipw2100 is compiled into
> > kernel, it is loaded while kernel boots and firmware loader
> is not yet
> > available. That leads to uninitialized (=> useless) adapter.
Pavel,
I might be lost here but... How is the firmware loaded when using the
ipw2100-1.0.0/patches Kernel patch?
That patch normally works fine. It might not be the way you kernel
developers would like it, but maybe that could work the same way?
> >
> > What's the prefered way to solve this one? Only load firmware when
> > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > better to start firmware sooner so that it can associate to the
> > AP...].
>
> Do you want to associate to an AP when your kernel boots,
> _before_ any iwconfig had a chance to configure anything?
> That's strange.
Currently, when we install the driver, it associates to any open network on
boot. This is good, cause we don't want to be typing the commands all the
time just to associate. It works this way now and is pretty nice.
>
> My position is that wifi drivers must start up in an "OFF" mode.
> Do not send anything. Do not join APs or start IBSS.
> Thus, no need to load fw in early boot.
>
So, to scan a network, I would have to do ifconfig eth1 up ; iwlist eth1
scan?
When moving from modes with the firmwares, would I have to do ifconfig eth1
up ; iwconfig eth1 mode monitor? or would the firmware be loaded with
iwconfig? Does it have that function?
I'm not sure, but I guess that you guys should use the same method that the
source/patches uses?
.Alejandro
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Jiri Benc @ 2005-06-08 15:23 UTC (permalink / raw)
To: abonilla
Cc: 'Denis Vlasenko', 'Pavel Machek',
'Jeff Garzik', 'Netdev list',
'kernel list', 'James P. Ketrenos'
In-Reply-To: <002901c56c3b$8216cdd0$600cc60a@amer.sykes.com>
On Wed, 8 Jun 2005 09:05:27 -0600, Alejandro Bonilla wrote:
> I might be lost here but... How is the firmware loaded when using the
> ipw2100-1.0.0/patches Kernel patch?
It is loaded by request_firmware() during initialization of the adapter.
That doesn't work, as at that time no hotplug binary can be executed (we
are talking about ipw2100 built in the kernel, not built as a module).
> Currently, when we install the driver, it associates to any open network on
> boot. This is good, cause we don't want to be typing the commands all the
> time just to associate. It works this way now and is pretty nice.
It sounds very dangerous to me.
> So, to scan a network, I would have to do ifconfig eth1 up ; iwlist eth1
> scan?
No. Driver should request the firmware when it is told to perform a scan.
> When moving from modes with the firmwares, would I have to do ifconfig eth1
> up ; iwconfig eth1 mode monitor? or would the firmware be loaded with
> iwconfig? Does it have that function?
Firmware can be loaded automatically by the driver when there is some
request from userspace and the firmware has not been loaded yet.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox