Re: net/ipv4/fib_trie.c - compile error (Re: 2.6.23-rc3-mm1)
On 22-08-2007 19:03, Paul E. McKenney wrote: > On Wed, Aug 22, 2007 at 05:41:11PM +0200, Adrian Bunk wrote: >> On Wed, Aug 22, 2007 at 05:30:13PM +0200, Gabriel C wrote: >>> Got it with a randconfig ( >>> http://194.231.229.228/kernel/mm/2.6.23-rc3-mm1/r/randconfig-8 ) >>> >>> ... >>> >>> net/ipv4/fib_trie.c: In function 'trie_rebalance': >>> net/ipv4/fib_trie.c:969: error: lvalue required as unary '&' operand >>> net/ipv4/fib_trie.c:971: error: lvalue required as unary '&' operand >>> net/ipv4/fib_trie.c:977: error: lvalue required as unary '&' operand >>> net/ipv4/fib_trie.c:980: error: lvalue required as unary '&' operand >>> ... >> Side effect of the git-net removal, temporarily removing >> immunize-rcu_dereference-against-crazy-compiler-writers.patch should >> work around it. > > Alternatively, the following one-line patch to net/ipv4/fib_trie.c could > be used. > > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]> > --- > > fib_trie.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff -urpNa -X dontdiff linux-2.6.23-rc3-mm1/net/ipv4/fib_trie.c > linux-2.6.23-rc3-mm1.compile/net/ipv4/fib_trie.c > --- linux-2.6.23-rc3-mm1/net/ipv4/fib_trie.c 2007-08-22 09:20:33.0 > -0700 > +++ linux-2.6.23-rc3-mm1.compile/net/ipv4/fib_trie.c 2007-08-22 > 09:47:33.0 -0700 > @@ -94,7 +94,7 @@ typedef unsigned int t_key; > #define T_LEAF 1 > #define NODE_TYPE_MASK 0x1UL > #define NODE_PARENT(node) \ > - ((struct tnode *)rcu_dereference(((node)->parent & ~NODE_TYPE_MASK))) > + ((struct tnode *)(rcu_dereference((node)->parent) & ~NODE_TYPE_MASK)) ... After first reading of this thread I've had an impression it's about compiler's behavior, but now it seems to me this patch is not an alternative, but a 'must be' and only proper way of calling rcu_dereference (with a variable instead of an expression)? Am I right? Regards, Jarek P. - 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.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state
On Sat, Aug 25, 2007 at 11:43:08AM +0200, Mariusz Kozlowski wrote:
> > > =
> > > [ INFO: inconsistent lock state ]
> > > 2.6.23-rc2-mm1 #7
> > > -
> > > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> > > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > > (&tp->lock){+...}, at: [] rtl8139_interrupt+0x27/0x46b
> > > [8139too]
...
> I tested your patch and it still happens. Dmesg info from patched kernel
> attached.
> I coulnd't reproduce that on 2.6.23-rc3-mm1 - but on 2.6.23-rc2-mm2 it is
> easily
> reproducible.
>
> If you need more info, test some patches, etc. - just mail me.
>
...
> =
> [ INFO: possible irq lock inversion dependency detected ]
> 2.6.23-rc2-mm2 #2
> -
> runscript.sh/5065 just changed the state of lock:
> (_xmit_ETHER){-+..}, at: [] dev_watchdog+0x17/0xcc
> but this lock took another, soft-irq-unsafe lock in the past:
> (&tp->lock){--..}
>
> and interrupts could create inverse lock ordering between them.
It's OK! These're 2 different warnings. As a matter of fact, my patch
wasn't supposed to fix any of them, but something similar to the first
one, which was possible, but for some reason wasn't reported by
lockdep.
The first warning was fixed by Andrew Morton's patch to free_irq(),
so it shouldn't happen in -rc3-mm. The second warning could have been
fixed too, I don't know, but since it's quite long, I would prefer to
think about it only if it still happens in current -mm's.
Thanks,
Jarek P.
-
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: ps3 gelic network driver doesn't restart properly
Sorry for late reply. I was on holiday last week. On Thu, 23 Aug 2007 02:12:47 +0100 "Michael Lothian" <[EMAIL PROTECTED]> wrote: > I can confirm this behaviour > > It could also be worth mentioning I'm using gcc 4.2.1 > > Cheers I also reproduced the symptom now. I'll investigate. Thanks, Stefan and Mike. -- Masakazu MOKUNO - 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] pcnet32: add suspend and resume capability
Add suspend and resume capability to the driver.
Tested both to ram and to disk on x86_64 platform.
Signed-off-by: Don Fry <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc3/drivers/net/pcnet32.c.orig 2007-08-14 13:52:24.0
-0700
+++ linux-2.6.23-rc3/drivers/net/pcnet32.c 2007-08-14 14:16:55.0
-0700
@@ -23,11 +23,11 @@
#define DRV_NAME "pcnet32"
#ifdef CONFIG_PCNET32_NAPI
-#define DRV_VERSION"1.33-NAPI"
+#define DRV_VERSION"1.34-NAPI"
#else
-#define DRV_VERSION"1.33"
+#define DRV_VERSION"1.34"
#endif
-#define DRV_RELDATE"27.Jun.2006"
+#define DRV_RELDATE"14.Aug.2007"
#define PFXDRV_NAME ": "
static const char *const version =
@@ -2943,6 +2943,33 @@ static void pcnet32_watchdog(struct net_
mod_timer(&(lp->watchdog_timer), PCNET32_WATCHDOG_TIMEOUT);
}
+static int pcnet32_pm_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ if (netif_running(dev)) {
+ netif_device_detach(dev);
+ pcnet32_close(dev);
+ }
+ pci_save_state(pdev);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ return 0;
+}
+
+static int pcnet32_pm_resume(struct pci_dev *pdev)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+
+ if (netif_running(dev)) {
+ pcnet32_open(dev);
+ netif_device_attach(dev);
+ }
+ return 0;
+}
+
static void __devexit pcnet32_remove_one(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
@@ -2966,6 +2993,8 @@ static struct pci_driver pcnet32_driver
.probe = pcnet32_probe_pci,
.remove = __devexit_p(pcnet32_remove_one),
.id_table = pcnet32_pci_tbl,
+ .suspend = pcnet32_pm_suspend,
+ .resume = pcnet32_pm_resume,
};
/* An additional parameter that may be passed in... */
-
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/9 Rev3] Implement batching skb API and support in IPoIB
From: John Heffner <[EMAIL PROTECTED]> Date: Sun, 26 Aug 2007 21:32:26 -0400 > There are a few interesting things here. For one, the bursts caused by > TSO seem to be causing the receiver to do stretch acks. This may have a > negative impact on flow performance, but it's hard to say for sure how > much. Interestingly, it will even further reduce the CPU load on the > sender, since it has to process fewer acks. > > As I suspected, in the non-TSO case the receiver gets lots of packets > directly queued to user. This should result in somewhat lower CPU > utilization on the receiver. I don't know if it can account for all the > difference you see. I had completely forgotten these stretch ACK and ucopy issues. When the receiver gets inundated with a backlog of receive queue packets, it just spins there copying into userspace _every_ _single_ packet in that queue, then spits out one ACK. Meanwhile the sender has to pause long enough for the pipe to empty slightly. The transfer is much better behaved if we ACK every two full sized frames we copy into the receiver, and therefore don't stretch ACK, but at the cost of cpu utilization. These effects are particularly pronounced on systems where the bus bandwidth is also one of the limiting factors. - 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: issues concerning the next NAPI interface
From: James Chapman <[EMAIL PROTECTED]> Date: Sun, 26 Aug 2007 20:36:20 +0100 > David Miller wrote: > > From: James Chapman <[EMAIL PROTECTED]> > > Date: Fri, 24 Aug 2007 18:16:45 +0100 > > > >> Does hardware interrupt mitigation really interact well with NAPI? > > > > It interacts quite excellently. > > If NAPI disables interrupts and keeps them disabled while there are more > packets arriving or more transmits being completed, why do hardware > interrupt mitigation / coalescing features of the network silicon help? Because if your packet rate is low enough such that the cpu can process the interrupt fast enough and thus only one packet gets processed per NAPI poll, the cost of going into and out of NAPI mode dominates the packet processing costs. - 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/9 Rev3] Implement batching skb API and support in IPoIB
Bill Fink wrote: Here's the beforeafter delta of the receiver's "netstat -s" statistics for the TSO enabled case: Ip: 3659898 total packets received 3659898 incoming packets delivered 80050 requests sent out Tcp: 2 passive connection openings 3659897 segments received 80050 segments send out TcpExt: 33 packets directly queued to recvmsg prequeue. 104956 packets directly received from backlog 705528 packets directly received from prequeue 3654842 packets header predicted 193 packets header predicted and directly queued to user 4 acknowledgments not containing data received 6 predicted acknowledgments And here it is for the TSO disabled case (GSO also disabled): Ip: 4107083 total packets received 4107083 incoming packets delivered 1401376 requests sent out Tcp: 2 passive connection openings 4107083 segments received 1401376 segments send out TcpExt: 2 TCP sockets finished time wait in fast timer 48486 packets directly queued to recvmsg prequeue. 1056111048 packets directly received from backlog 2273357712 packets directly received from prequeue 1819317 packets header predicted 2287497 packets header predicted and directly queued to user 4 acknowledgments not containing data received 10 predicted acknowledgments For the TSO disabled case, there are a huge amount more TCP segments sent out (1401376 versus 80050), which I assume are ACKs, and which could possibly contribute to the higher throughput for the TSO disabled case due to faster feedback, but not explain the lower CPU utilization. There are many more packets directly queued to recvmsg prequeue (48486 versus 33). The numbers for packets directly received from backlog and prequeue in the TCP disabled case seem bogus to me so I don't know how to interpret that. There are only about half as many packets header predicted (1819317 versus 3654842), but there are many more packets header predicted and directly queued to user (2287497 versus 193). I'll leave the analysis of all this to those who might actually know what it all means. There are a few interesting things here. For one, the bursts caused by TSO seem to be causing the receiver to do stretch acks. This may have a negative impact on flow performance, but it's hard to say for sure how much. Interestingly, it will even further reduce the CPU load on the sender, since it has to process fewer acks. As I suspected, in the non-TSO case the receiver gets lots of packets directly queued to user. This should result in somewhat lower CPU utilization on the receiver. I don't know if it can account for all the difference you see. The backlog and prequeue values are probably correct, but netstat's description is wrong. A quick look at the code reveals these values are in units of bytes, not packets. -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
SCTP: Fix dead loop while received unexpected chunk with length set to zero
A ootb chunk such as data in close state or init-ack in estab state will
cause SCTP to enter dead loop. Look like this:
(1)
Endpoint A Endpoint B
(Closed)(Closed)
DATA -> Kernel dead loop
(With Length set to zero)
(2)
Endpoint A Endpoint B
(Established) (Established)
INIT-ACK -> Kernel dead loop
(With Length set to zero)
This is beacuse when process chunks, chunk->chunk_end is set to the
chunk->chunk_hdr plus chunk length, if chunk length is set to zero,
chunk->chunk_end will be never changed and process enter dead loop.
Following is the patch.
Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]>
--- a/net/sctp/inqueue.c2007-08-25 10:53:45.0 -0400
+++ b/net/sctp/inqueue.c2007-08-26 05:45:57.0 -0400
@@ -165,10 +165,8 @@ struct sctp_chunk *sctp_inq_pop(struct s
skb_pull(chunk->skb, sizeof(sctp_chunkhdr_t));
chunk->subh.v = NULL; /* Subheader is no longer valid. */
- if (chunk->chunk_end < skb_tail_pointer(chunk->skb)) {
- /* This is not a singleton */
- chunk->singleton = 0;
- } else if (chunk->chunk_end > skb_tail_pointer(chunk->skb)) {
+ if (chunk->chunk_end > skb_tail_pointer(chunk->skb) ||
+ chunk->chunk_end == chunk->chunk_hdr) {
/* RFC 2960, Section 6.10 Bundling
*
* Partial chunks MUST NOT be placed in an SCTP packet.
@@ -183,6 +181,9 @@ struct sctp_chunk *sctp_inq_pop(struct s
chunk = queue->in_progress = NULL;
return NULL;
+ } else if (chunk->chunk_end < skb_tail_pointer(chunk->skb)) {
+ /* This is not a singleton */
+ chunk->singleton = 0;
} else {
/* We are at the end of the packet, so mark the chunk
* in case we need to send a SACK.
-
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 0/3] [IrDA] IrDA updates for net-2.6.24
Hi Dave, Here go 3 IrDA patches for net-2.6.24 inclusion. Cheers, Samuel. - 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 3/3] [IrDA] Kingsun KS-959 IrDA USB driver
This dongle does not follow the usb-irda specification, so it needs its own special driver. First, it uses control URBs for data transfer, instead of bulk or interrupt transfers; the only interrupt endpoint exposed seems to be a dummy to prevent the interface from being rejected. Second, it uses obfuscation and padding at the USB traffic level, for no apparent reason other than to make reverse engineering harder (full details on obfuscation in comments at beginning of source). Although it is advertised as a "4 Mbps FIR dongle", it apparently loses packets at speeds greater than 57600 bps. On plugin, this dongle reports vendor and device IDs: 0x07d0:0x4959 . The Windows driver that is used normally to control this dongle has a filename of KS-959.SYS . Signed-off-by: Alex VillacÃs Lasso <[EMAIL PROTECTED]> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> --- drivers/net/irda/Kconfig | 14 drivers/net/irda/Makefile|1 drivers/net/irda/ks959-sir.c | 939 +++ 3 files changed, 954 insertions(+) Index: net-2.6.24-quilt/drivers/net/irda/Kconfig === --- net-2.6.24-quilt.orig/drivers/net/irda/Kconfig 2007-08-25 02:43:16.0 +0300 +++ net-2.6.24-quilt/drivers/net/irda/Kconfig 2007-08-25 03:05:15.0 +0300 @@ -176,6 +176,20 @@ To compile it as a module, choose M here: the module will be called ksdazzle-sir. +config KS959_DONGLE + tristate "KingSun KS-959 IrDA-USB dongle (EXPERIMENTAL)" + depends on IRDA && USB && EXPERIMENTAL + help + Say Y or M here if you want to build support for the KingSun KS-959 + IrDA-USB bridge device driver. + + This USB bridge does not conform to the IrDA-USB device class + specification, and therefore needs its own specific driver. This + dongle supports SIR speeds only (9600 through 57600 bps). + + To compile it as a module, choose M here: the module will be called + ks959-sir. + comment "Old SIR device drivers" config IRPORT_SIR Index: net-2.6.24-quilt/drivers/net/irda/ks959-sir.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24-quilt/drivers/net/irda/ks959-sir.c 2007-08-25 03:04:30.0 +0300 @@ -0,0 +1,939 @@ +/* +* +* Filename: ks959-sir.c +* Version: 0.1.2 +* Description: Irda KingSun KS-959 USB Dongle +* Status:Experimental +* Author:Alex VillacÃs Lasso <[EMAIL PROTECTED]> +* with help from Domen Puncer <[EMAIL PROTECTED]> +* +*Based on stir4200, mcs7780, kingsun-sir drivers. +* +*This program is free software; you can redistribute it and/or modify +*it under the terms of the GNU General Public License as published by +*the Free Software Foundation; either version 2 of the License. +* +*This program is distributed in the hope that it will be useful, +*but WITHOUT ANY WARRANTY; without even the implied warranty of +*MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +*GNU General Public License for more details. +* +*You should have received a copy of the GNU General Public License +*along with this program; if not, write to the Free Software +*Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +* +*/ + +/* + * Following is my most current (2007-07-17) understanding of how the Kingsun + * KS-959 dongle is supposed to work. This information was deduced by + * reverse-engineering and examining the USB traffic captured with USBSnoopy + * from the WinXP driver. Feel free to update here as more of the dongle is + * known. + * + * My most sincere thanks must go to Domen Puncer <[EMAIL PROTECTED]> for + * invaluable help in cracking the obfuscation and padding required for this + * dongle. + * + * General: This dongle exposes one interface with one interrupt IN endpoint. + * However, the interrupt endpoint is NOT used at all for this dongle. Instead, + * this dongle uses control transfers for everything, including sending and + * receiving the IrDA frame data. Apparently the interrupt endpoint is just a + * dummy to ensure the dongle has a valid interface to present to the PC.And I + * thought the DonShine dongle was weird... In addition, this dongle uses + * obfuscation (?!?!), applied at the USB level, to hide the traffic, both sent + * and received, from the dongle. I call it obfuscation because the XOR keying + * and padding required to produce an USB traffic acceptable for the dongle can + * not be explained by any other technical requirement. + * + * Transmission: To transmit an IrDA frame, the driver must prepare a control + * URB with the following as a setup packet: + *bRequestTypeUSB_DIR
[PATCH 2/3] [IrDA] Kingsun Dazzle IrDA USB driver
This dongle does not follow the usb-irda specification, so it needs its own special driver. Just like the Kingsun/Donshine dongle, it exposes two interrupt endpoints. Reception is performed through direct reads from the input endpoint. Transmission requires splitting the IrDA frames into 8-byte segments, in which the first byte encodes how many of the remaining 7 bytes are used as data. Speed change is made with a control URB just like the one in cypress_m8, and it seems to support up to 115200 bps. On plugin, this dongle reports vendor and device IDs: 0x07d0:0x4100 Signed-off-by: Alex VillacÃs Lasso <[EMAIL PROTECTED]> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> --- drivers/net/irda/Kconfig| 12 drivers/net/irda/Makefile |1 drivers/net/irda/ksdazzle-sir.c | 823 3 files changed, 836 insertions(+) Index: net-2.6.24-quilt/drivers/net/irda/Kconfig === --- net-2.6.24-quilt.orig/drivers/net/irda/Kconfig 2007-08-24 14:55:19.0 +0300 +++ net-2.6.24-quilt/drivers/net/irda/Kconfig 2007-08-25 02:43:16.0 +0300 @@ -162,7 +162,19 @@ Say Y here if you want to build support for the Cirrus logic EP7211 chipset's infrared module. +config KSDAZZLE_DONGLE + tristate "KingSun Dazzle IrDA-USB dongle (EXPERIMENTAL)" + depends on IRDA && USB && EXPERIMENTAL + help + Say Y or M here if you want to build support for the KingSun Dazzle + IrDA-USB bridge device driver. + This USB bridge does not conform to the IrDA-USB device class + specification, and therefore needs its own specific driver. This + dongle supports SIR speeds only (9600 through 115200 bps). + + To compile it as a module, choose M here: the module will be called + ksdazzle-sir. comment "Old SIR device drivers" Index: net-2.6.24-quilt/drivers/net/irda/ksdazzle-sir.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24-quilt/drivers/net/irda/ksdazzle-sir.c2007-08-25 02:42:20.0 +0300 @@ -0,0 +1,823 @@ +/* +* +* Filename: ksdazzle.c +* Version: 0.1.1 +* Description: Irda KingSun Dazzle USB Dongle +* Status:Experimental +* Author:Alex VillacÃs Lasso <[EMAIL PROTECTED]> +* +*Based on stir4200, mcs7780, kingsun-sir drivers. +* +*This program is free software; you can redistribute it and/or modify +*it under the terms of the GNU General Public License as published by +*the Free Software Foundation; either version 2 of the License. +* +*This program is distributed in the hope that it will be useful, +*but WITHOUT ANY WARRANTY; without even the implied warranty of +*MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +*GNU General Public License for more details. +* +*You should have received a copy of the GNU General Public License +*along with this program; if not, write to the Free Software +*Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +* +*/ + +/* + * Following is my most current (2007-07-26) understanding of how the Kingsun + * 07D0:4100 dongle (sometimes known as the MA-660) is supposed to work. This + * information was deduced by examining the USB traffic captured with USBSnoopy + * from the WinXP driver. Feel free to update here as more of the dongle is + * known. + * + * General: This dongle exposes one interface with two interrupt endpoints, one + * IN and one OUT. In this regard, it is similar to what the Kingsun/Donshine + * dongle (07c0:4200) exposes. Traffic is raw and needs to be wrapped and + * unwrapped manually as in stir4200, kingsun-sir, and ks959-sir. + * + * Transmission: To transmit an IrDA frame, it is necessary to wrap it, then + * split it into multiple segments of up to 7 bytes each, and transmit each in + * sequence. It seems that sending a single big block (like kingsun-sir does) + * won't work with this dongle. Each segment needs to be prefixed with a value + * equal to (unsigned char)0xF8 + , inside a payload + * of exactly 8 bytes. For example, a segment of 1 byte gets prefixed by 0xF9, + * and one of 7 bytes gets prefixed by 0xFF. The bytes at the end of the + * payload, not considered by the prefix, are ignored (set to 0 by this + * implementation). + * + * Reception: To receive data, the driver must poll the dongle regularly (like + * kingsun-sir.c) with interrupt URBs. If data is available, it will be returned + * in payloads from 0 to 8 bytes long. When concatenated, these payloads form + * a raw IrDA stream that needs to be unwrapped as in stir4200 and kingsun-sir + * + * Speed change: To change the speed of the dongle, the driver prepar
[PATCH 1/3] [IrDA] MSG_NOSIGNAL support for IrDA sockets
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
net/irda/af_irda.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
Index: net-2.6.24-quilt/net/irda/af_irda.c
===
--- net-2.6.24-quilt.orig/net/irda/af_irda.c2007-08-25 02:41:39.0
+0300
+++ net-2.6.24-quilt/net/irda/af_irda.c 2007-08-25 02:41:41.0 +0300
@@ -1245,18 +1245,17 @@
struct sock *sk = sock->sk;
struct irda_sock *self;
struct sk_buff *skb;
- int err;
+ int err = -EPIPE;
IRDA_DEBUG(4, "%s(), len=%zd\n", __FUNCTION__, len);
/* Note : socket.c set MSG_EOR on SEQPACKET sockets */
- if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_CMSG_COMPAT))
+ if (msg->msg_flags & ~(MSG_DONTWAIT | MSG_EOR | MSG_CMSG_COMPAT |
+ MSG_NOSIGNAL))
return -EINVAL;
- if (sk->sk_shutdown & SEND_SHUTDOWN) {
- send_sig(SIGPIPE, current, 0);
- return -EPIPE;
- }
+ if (sk->sk_shutdown & SEND_SHUTDOWN)
+ goto out_err;
if (sk->sk_state != TCP_ESTABLISHED)
return -ENOTCONN;
@@ -1283,7 +1282,7 @@
skb = sock_alloc_send_skb(sk, len + self->max_header_size + 16,
msg->msg_flags & MSG_DONTWAIT, &err);
if (!skb)
- return -ENOBUFS;
+ goto out_err;
skb_reserve(skb, self->max_header_size + 16);
skb_reset_transport_header(skb);
@@ -1291,7 +1290,7 @@
err = memcpy_fromiovec(skb_transport_header(skb), msg->msg_iov, len);
if (err) {
kfree_skb(skb);
- return err;
+ goto out_err;
}
/*
@@ -1301,10 +1300,14 @@
err = irttp_data_request(self->tsap, skb);
if (err) {
IRDA_DEBUG(0, "%s(), err=%d\n", __FUNCTION__, err);
- return err;
+ goto out_err;
}
/* Tell client how much data we actually sent */
return len;
+
+ out_err:
+ return sk_stream_error(sk, msg->msg_flags, err);
+
}
/*
--
-
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: issues concerning the next NAPI interface
David Miller wrote: From: James Chapman <[EMAIL PROTECTED]> Date: Fri, 24 Aug 2007 18:16:45 +0100 Does hardware interrupt mitigation really interact well with NAPI? It interacts quite excellently. If NAPI disables interrupts and keeps them disabled while there are more packets arriving or more transmits being completed, why do hardware interrupt mitigation / coalescing features of the network silicon help? There was a long saga about this with tg3 and huge SGI numa systems with large costs for interrupt processing, and the fix was to do a minimal amount of interrupt mitigation and this basically cleared up all the problems. Someone should reference that thread _now_ before this discussion goes too far and we repeat a lot of information and people like myself have to stay up all night correcting the misinformation and misunderstandings that are basically guarenteed for this topic :) I hope I'm not spreading misinformation. :) The original poster was observing NAPI going in/out of polled mode because the CPU is fast enough to process all work per poll. I've seen the same and I'm suggesting that the NAPI driver keeps itself in polled mode for N polls or M jiffies after it sees workdone=0. This has always worked for me in packet forwarding scenarios to maximize packets/sec and minimize latency. I'm considering putting a patch together to add this as another tuning knob, hence I'm keen to understand what I'm missing. :) -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development - 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] Prefix each line of multiline printk(KERN_ "foo\nbar") with KERN_
On Sun, 2007-08-26 at 10:30 +0200, Geert Uytterhoeven wrote:
> On Fri, 24 Aug 2007, Joe Perches wrote:
> > Corrected printk calls with multiple output lines which
> > did not correctly preface each line with KERN_
> > Fixed uses of some single lines with too many KERN_
> > --- a/arch/arm/kernel/ecard.c
> > +++ b/arch/arm/kernel/ecard.c
> > @@ -547,7 +547,8 @@ static void ecard_check_lockup(struct irq_desc *desc)
> > if (last == jiffies) {
> > lockup += 1;
> > if (lockup > 100) {
> > - printk(KERN_ERR "\nInterrupt lockup detected - "
> > + printk(KERN_ERR "\n"
> > + KERN_ERR "Interrupt lockup detected - "
> >"disabling all expansion card interrupts\n");
> >
> > desc->chip->mask(IRQ_EXPANSIONCARD);
>
> What's the purpose of having lines printed with e.g. `KERN_ERR "\n"' only?
> Shouldn't these just be removed?
My preference too. There could be a separate effort for that.
egrep -r --include=*.[ch] "KERN_[A-Z]*[[:space:]]+\"\\\n" * | wc -l
104
These are either errors or a desire to prettify logs with
vertical whitespace. I think vertical whitespace doesn't help.
> Usually lines starting with `\n' are continuations, but given some other
> module may call printk() in between, there's no guarantee continuations
> appear on the same line.
printk KERN_s were sometimes bolted on after code was written.
etherfoo_card_init()
{
printk(KERN_INFO "etherfoo card");
slot = foo_getslot();
if (slot < 0) {
printk("\n" KERN_ERR "etherfoo card slot not found\n");
return -1;
}
printk(" found in slot %d", slot);
irq = foo_getirq();
if (irq < 0) {
printk("\n" KERN_ERR "etherfoo card irq not found\n");
return -1;
}
printk(" with irq %d\n", irq);
}
Sometimes, a KERN_ERR is misplaced, or the "\n" is missing.
printk(KERN_ERR "\n" msg);
or
printk(KERN_ERR msg);
To me, the card announcement printk should move to the
end of the card_init routine and just be a single printk.
etherfoo_card_init()
{
slot = foo_getslot();
if (slot < 0) {
printk(KERN_ERR "etherfoo card slot not found\n");
return -1;
}
irq = foo_getirq();
if (irq < 0) {
printk(KERN_ERR "etherfoo card irq not found\n");
return -1;
}
printk(KERN_INFO "etherfoo card in slot %d with irq %d\n",
slot, irq);
}
-
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] Prefix each line of multiline printk(KERN_ "foo\nbar") with KERN_
On Sun, 26 Aug 2007, Mike Frysinger wrote:
> On 8/26/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > On Fri, 24 Aug 2007, Joe Perches wrote:
> > > Corrected printk calls with multiple output lines which
> > > did not correctly preface each line with KERN_
> > >
> > > Fixed uses of some single lines with too many KERN_
> >
> > > --- a/arch/arm/kernel/ecard.c
> > > +++ b/arch/arm/kernel/ecard.c
> > > @@ -547,7 +547,8 @@ static void ecard_check_lockup(struct irq_desc *desc)
> > > if (last == jiffies) {
> > > lockup += 1;
> > > if (lockup > 100) {
> > > - printk(KERN_ERR "\nInterrupt lockup detected - "
> > > + printk(KERN_ERR "\n"
> > > +KERN_ERR "Interrupt lockup detected - "
> > > "disabling all expansion card interrupts\n");
> > >
> > > desc->chip->mask(IRQ_EXPANSIONCARD);
> >
> > What's the purpose of having lines printed with e.g. `KERN_ERR "\n"' only?
> > Shouldn't these just be removed?
> >
> > Usually lines starting with `\n' are continuations, but given some other
> > module may call printk() in between, there's no guarantee continuations
> > appear on the same line.
>
> erm, i thought the prink lock was grabbed per-buffer, not per-line ...
> so yes, if the function calls were like printk(KERN_ERR "\n");
> printk(KERN_ERR "..."); things could be broken up, but this is on
> function call, so it shouldnt ...
Yes it is.
What I mean is that probably there used to be a printk() call starting with
`\n'. Then someone added a `KERN_ERR' in front of it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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] Prefix each line of multiline printk(KERN_ "foo\nbar") with KERN_
On 8/26/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> On Fri, 24 Aug 2007, Joe Perches wrote:
> > Corrected printk calls with multiple output lines which
> > did not correctly preface each line with KERN_
> >
> > Fixed uses of some single lines with too many KERN_
>
> > --- a/arch/arm/kernel/ecard.c
> > +++ b/arch/arm/kernel/ecard.c
> > @@ -547,7 +547,8 @@ static void ecard_check_lockup(struct irq_desc *desc)
> > if (last == jiffies) {
> > lockup += 1;
> > if (lockup > 100) {
> > - printk(KERN_ERR "\nInterrupt lockup detected - "
> > + printk(KERN_ERR "\n"
> > +KERN_ERR "Interrupt lockup detected - "
> > "disabling all expansion card interrupts\n");
> >
> > desc->chip->mask(IRQ_EXPANSIONCARD);
>
> What's the purpose of having lines printed with e.g. `KERN_ERR "\n"' only?
> Shouldn't these just be removed?
>
> Usually lines starting with `\n' are continuations, but given some other
> module may call printk() in between, there's no guarantee continuations
> appear on the same line.
erm, i thought the prink lock was grabbed per-buffer, not per-line ...
so yes, if the function calls were like printk(KERN_ERR "\n");
printk(KERN_ERR "..."); things could be broken up, but this is on
function call, so it shouldnt ...
-mike
-
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/9 Rev3] Implement batching skb API and support in IPoIB
On Fri, 24 Aug 2007, John Heffner wrote: > Bill Fink wrote: > > Here you can see there is a major difference in the TX CPU utilization > > (99 % with TSO disabled versus only 39 % with TSO enabled), although > > the TSO disabled case was able to squeeze out a little extra performance > > from its extra CPU utilization. Interestingly, with TSO enabled, the > > receiver actually consumed more CPU than with TSO disabled, so I guess > > the receiver CPU saturation in that case (99 %) was what restricted > > its performance somewhat (this was consistent across a few test runs). > > One possibility is that I think the receive-side processing tends to do > better when receiving into an empty queue. When the (non-TSO) sender is > the flow's bottleneck, this is going to be the case. But when you > switch to TSO, the receiver becomes the bottleneck and you're always > going to have to put the packets at the back of the receive queue. This > might help account for the reason why you have both lower throughput and > higher CPU utilization -- there's a point of instability right where the > receiver becomes the bottleneck and you end up pushing it over to the > bad side. :) > > Just a theory. I'm honestly surprised this effect would be so > significant. What do the numbers from netstat -s look like in the two > cases? Well, I was going to check this out, but I happened to reboot the system and now I get somewhat different results. Here are the new results, which should hopefully be more accurate since they are on a freshly booted system. TSO enabled and GSO disabled: [EMAIL PROTECTED] ~]# nuttcp -w10m 192.168.88.16 11610.6875 MB / 10.00 sec = 9735.9526 Mbps 100 %TX 75 %RX [EMAIL PROTECTED] ~]# nuttcp -M1460 -w10m 192.168.88.16 5029.6875 MB / 10.06 sec = 4194.6931 Mbps 36 %TX 100 %RX TSO disabled and GSO disabled: [EMAIL PROTECTED] ~]# nuttcp -w10m 192.168.88.16 11817.9375 MB / 10.00 sec = 9909.7773 Mbps 99 %TX 77 %RX [EMAIL PROTECTED] ~]# nuttcp -M1460 -w10m 192.168.88.16 5823.3125 MB / 10.00 sec = 4883.2429 Mbps 100 %TX 82 %RX The TSO disabled case got a little better performance even for 9000 byte jumbo frames. For the "-M1460" case eumalating a standard 1500 byte Ethernet MTU, the performance was significantly better and used less CPU on the receiver (82 % versus 100 %) although it did use significantly more CPU on the transmitter (100 % versus 36 %). TSO disabled and GSO enabled: [EMAIL PROTECTED] ~]# nuttcp -w10m 192.168.88.16 11609.5625 MB / 10.00 sec = 9734.9859 Mbps 99 %TX 75 %RX [EMAIL PROTECTED] ~]# nuttcp -M1460 -w10m 192.168.88.16 5001.4375 MB / 10.06 sec = 4170.6739 Mbps 52 %TX 100 %RX The GSO enabled case is very similar to the TSO enabled case, except that for the "-M1460" test the transmitter used more CPU (52 % versus 36 %), which is to be expected since TSO has hardware assist. Here's the beforeafter delta of the receiver's "netstat -s" statistics for the TSO enabled case: Ip: 3659898 total packets received 3659898 incoming packets delivered 80050 requests sent out Tcp: 2 passive connection openings 3659897 segments received 80050 segments send out TcpExt: 33 packets directly queued to recvmsg prequeue. 104956 packets directly received from backlog 705528 packets directly received from prequeue 3654842 packets header predicted 193 packets header predicted and directly queued to user 4 acknowledgments not containing data received 6 predicted acknowledgments And here it is for the TSO disabled case (GSO also disabled): Ip: 4107083 total packets received 4107083 incoming packets delivered 1401376 requests sent out Tcp: 2 passive connection openings 4107083 segments received 1401376 segments send out TcpExt: 2 TCP sockets finished time wait in fast timer 48486 packets directly queued to recvmsg prequeue. 1056111048 packets directly received from backlog 2273357712 packets directly received from prequeue 1819317 packets header predicted 2287497 packets header predicted and directly queued to user 4 acknowledgments not containing data received 10 predicted acknowledgments For the TSO disabled case, there are a huge amount more TCP segments sent out (1401376 versus 80050), which I assume are ACKs, and which could possibly contribute to the higher throughput for the TSO disabled case due to faster feedback, but not explain the lower CPU utilization. There are many more packets directly queued to recvmsg prequeue (48486 versus 33). The numbers for packets directly received from backlog and prequeue in the TCP disabled case seem bogus to me so I don't know how to interpret that. There are only about half as many packets header predicted (1819317 versus 3654842), but there are many more packets header predicted and directly queued to user (2287497 versus 193). I'll leave the analysis of all this to those who might actually know what it all means. I also ra
Re: [PATCH] Prefix each line of multiline printk(KERN_ "foo\nbar") with KERN_
On Fri, 24 Aug 2007, Joe Perches wrote:
> Corrected printk calls with multiple output lines which
> did not correctly preface each line with KERN_
>
> Fixed uses of some single lines with too many KERN_
> --- a/arch/arm/kernel/ecard.c
> +++ b/arch/arm/kernel/ecard.c
> @@ -547,7 +547,8 @@ static void ecard_check_lockup(struct irq_desc *desc)
> if (last == jiffies) {
> lockup += 1;
> if (lockup > 100) {
> - printk(KERN_ERR "\nInterrupt lockup detected - "
> + printk(KERN_ERR "\n"
> +KERN_ERR "Interrupt lockup detected - "
> "disabling all expansion card interrupts\n");
>
> desc->chip->mask(IRQ_EXPANSIONCARD);
What's the purpose of having lines printed with e.g. `KERN_ERR "\n"' only?
Shouldn't these just be removed?
Usually lines starting with `\n' are continuations, but given some other
module may call printk() in between, there's no guarantee continuations
appear on the same line.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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
