Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
On Mon, Feb 25, 2008 at 02:30:00AM -0500, Jeff Garzik wrote: > Grant Grundler wrote: >> On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote: >>> I think that de2104x driver should be removed (or at least its >>> MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 >>> PCI IDs added to de4x5. >>> >>> I can send a patch if this is acceptable. >> It's acceptable to me. Jeff? (jgarzik) > > NAK, sorry, for two reasons: > > 1) we don't delete otherwise clean, working drivers Just to be clear - he's not trying to remove the driver. He's just interested in making de4x5 the "default" for this set of boards by doctoring with the pci device ids each driver will claim. > simply because of a bug triggered by unplugging a cable. Ondrej would be happy to test any patches sent. Tracking this sort of bug down usually isn't trivial as the statement above implies. > 2) de4x5 needs to go away. Ok. I'd prefer to wait until someone demonstrates de2104x driver is a fully functional alternative for all the PCI Ids it claims. thanks, grant -- 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] Don't limit the number of tunnels with generic name explicitly.
David Miller wrote: > From: Pavel Emelyanov <[EMAIL PROTECTED]> > Date: Thu, 21 Feb 2008 15:38:16 +0300 > >> Changelog: >> >> Use the added dev_alloc_name() call to create tunnel device name, >> rather than iterate in a hand-made loop with an artificial limit. >> >> Thanks Patrick for noticing this. >> >> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> > > Applied, but I had to rework this in two places that didn't > apply cleanly. That's because you skipped the first patch titled "Don't create tunnels with '%' in name.", which adds the dev_alloc_name() call and tosses the error paths a bit. Without this first patch, these four drivers become broken :( When user doesn't specify the name, the device's name will be e.g. "tunl%d", but not "tunl0" like he expects. > The ip_gre.c and ipip.c changes remove a "failed" label but > that can't be done in the current tree as there are other > existing references. > Yup :( this code was removed in that first patch... -- 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] Can not send icmp netunreach packet
On 26-02-2008 07:34, Li Yewang wrote: > Hi All > >There is a bug about icmp netunreach. >If the kernel does not find a route for a packet, >it must send a icmp netunreach packet to the source host, >and discard the packet. But the kernel does not send >a icmp netunreach packet because of the fib_lookup >return value of -ESRCH when a route is not found. ...or because some function doesn't handle -ESRCH return from fib_lookup? It seems changing this to -ESRCH was needed in some cases. And you don't explain enough why it can't be handled later (like in ipv4/route.c: ip_route_input_slow)? Regards, Jarek P. > > Signed-off-by: Li Yewang <[EMAIL PROTECTED]> > > diff -Nurp net/core_back/fib_rules.c net/core/fib_rules.c > --- net/core_back/fib_rules.c 2008-02-25 13:15:37.0 +0800 > +++ net/core/fib_rules.c2008-02-25 13:16:01.0 +0800 > @@ -188,7 +188,7 @@ jumped: > } > } > > - err = -ESRCH; > + err = -ENETUNREACH; > out: > rcu_read_unlock(); > -- 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] llc: dont trust payload size on test cmd
On Mon, Feb 25, 2008 at 08:14:39AM -0800, Jim Westfall wrote:
> Hi
>
> In testing its not safe to trust the payload length we are given in a
> received llc test command header. Instead we should calculate this
> ourselves or run the risk of an skb_over_panic() if the received length in
> the header is > then the actual payload size.
Shouldn't it be discarded?
>
> Signed-off-by: Jim Westfall <[EMAIL PROTECTED]>
>
> diff -urp linux-2.6.24.2.org/include/net/llc_pdu.h
> linux-2.6.24.2/include/net/llc_pdu.h
> --- linux-2.6.24.2.org/include/net/llc_pdu.h 2008-02-10 21:51:11.0
> -0800
> +++ linux-2.6.24.2/include/net/llc_pdu.h 2008-02-24 10:23:02.0
> -0800
> @@ -348,7 +348,7 @@ static inline void llc_pdu_init_as_test_
> struct llc_pdu_un *ev_pdu = llc_pdu_un_hdr(ev_skb);
> int dsize;
>
> - dsize = ntohs(eth_hdr(ev_skb)->h_proto) - 3;
> + dsize = (ev_skb->tail - (u8 *)ev_pdu) - 3;
In addition, dsize can be a minus. (with & without your patch)
> memcpy(((u8 *)pdu) + 3, ((u8 *)ev_pdu) + 3, dsize);
> skb_put(skb, dsize);
> }
>
> - End forwarded message -
[PATCH] LLC: discard malfromed llc packet
Discard llc packet which has invalid data size.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
net/llc/llc_input.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/llc/llc_input.c b/net/llc/llc_input.c
index c40c9b2..6ef80fe 100644
--- a/net/llc/llc_input.c
+++ b/net/llc/llc_input.c
@@ -117,9 +117,12 @@ static inline int llc_fixup_skb(struct sk_buff *skb)
skb_pull(skb, llc_len);
if (skb->protocol == htons(ETH_P_802_2)) {
__be16 pdulen = eth_hdr(skb)->h_proto;
- u16 data_size = ntohs(pdulen) - llc_len;
+ s32 data_size = ntohs(pdulen) - llc_len;
- if (unlikely(pskb_trim_rcsum(skb, data_size)))
+ if (data_size < 0
+ || ((skb->tail - (u8 *)pdu) - llc_len) < data_size)
+ return 0;
+ if (unlikely(pskb_trim_rcsum(skb, (unsigned int)data_size)))
return 0;
}
return 1;
--
1.5.4
> --
> 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
--
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] llc: fix skb size for test responses
On Sun, Feb 24, 2008 at 11:07:58AM -0800, Jim Westfall wrote:
> Hi
>
> The llc test command is used for a layer2 ping and contains a variable
> length payload that we must include in the response. Use the size of the
> received skb as the size of the skb we must allocate to hold the payload.
>
> This resolved an skb_over_panic(), when trying to copy the payload into
> what was a hard coded skb of size 128.
>
> Signed-off-by: Jim Westfall <[EMAIL PROTECTED]>
>
> diff -urp linux-2.6.24.2.org/net/llc/llc_s_ac.c
> linux-2.6.24.2/net/llc/llc_s_ac.c
> --- linux-2.6.24.2.org/net/llc/llc_s_ac.c 2008-02-10 21:51:11.0
> -0800
> +++ linux-2.6.24.2/net/llc/llc_s_ac.c 2008-02-24 10:15:02.0 -0800
> @@ -148,9 +148,18 @@ int llc_sap_action_send_test_r(struct ll
> llc_pdu_decode_sa(skb, mac_da);
> llc_pdu_decode_da(skb, mac_sa);
> llc_pdu_decode_ssap(skb, &dsap);
> - nskb = llc_alloc_frame(NULL, skb->dev);
> + nskb = alloc_skb(skb->end - skb->head, GFP_ATOMIC);
Jim,
Not enough.
Because of 'skb_reserve(nskb, 50)', we need additional 50bytes.
> +
> if (!nskb)
> goto out;
> +
> + skb_reset_mac_header(nskb);
> + skb_reserve(nskb, 50);
> + skb_reset_network_header(nskb);
> + skb_reset_transport_header(nskb);
> + nskb->protocol = htons(ETH_P_802_2);
> + nskb->dev = skb->dev;
> +
> llc_pdu_header_init(nskb, LLC_PDU_TYPE_U, sap->laddr.lsap, dsap,
> LLC_PDU_RSP);
> llc_pdu_init_as_test_rsp(nskb, skb);
> diff -urp linux-2.6.24.2.org/net/llc/llc_station.c
> linux-2.6.24.2/net/llc/llc_station.c
> --- linux-2.6.24.2.org/net/llc/llc_station.c 2008-02-10 21:51:11.0
> -0800
> +++ linux-2.6.24.2/net/llc/llc_station.c 2008-02-24 10:10:01.0
> -0800
> @@ -298,10 +298,18 @@ static int llc_station_ac_send_test_r(st
> {
> u8 mac_da[ETH_ALEN], dsap;
> int rc = 1;
> - struct sk_buff *nskb = llc_alloc_frame(NULL, skb->dev);
> + struct sk_buff *nskb = alloc_skb(skb->end - skb->head, GFP_ATOMIC);
Also here.
>
> if (!nskb)
> goto out;
> +
> + skb_reset_mac_header(nskb);
> + skb_reserve(nskb, 50);
> + skb_reset_network_header(nskb);
> + skb_reset_transport_header(nskb);
> + nskb->protocol = htons(ETH_P_802_2);
> + nskb->dev = skb->dev;
> +
> rc = 0;
> llc_pdu_decode_sa(skb, mac_da);
> llc_pdu_decode_ssap(skb, &dsap);
>
Thanks,
Joonwoo
> --
> 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
--
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.25-rc2-git] rndis_host: fix transfer size negotiation
On Mon, 2008-02-25 at 13:29 -0500, John W. Linville wrote: > On Fri, Feb 22, 2008 at 05:31:16PM -0800, David Brownell wrote: > > From: Jean-Christophe Dubois <[EMAIL PROTECTED]> > > > > This patch should resolve a problem that's troubled support for > > some RNDIS peripherals. It seems to have boiled down to using a > > variable to establish transfer size limits before it was assigned, > > which caused those devices to fallback to a default "jumbogram" > > mode we don't support. Fix by assigning it earlier for RNDIS. > > Any chance that something like this is appropriate for rndis_wlan? > This fix is automatically reflected to rndis_wlan since rndis_wlan reuses that functions of that rndis_host module. - Jussi -- 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] Can not send icmp netunreach packet
Hi All There is a bug about icmp netunreach. If the kernel does not find a route for a packet, it must send a icmp netunreach packet to the source host, and discard the packet. But the kernel does not send a icmp netunreach packet because of the fib_lookup return value of -ESRCH when a route is not found. Signed-off-by: Li Yewang <[EMAIL PROTECTED]> diff -Nurp net/core_back/fib_rules.c net/core/fib_rules.c --- net/core_back/fib_rules.c 2008-02-25 13:15:37.0 +0800 +++ net/core/fib_rules.c2008-02-25 13:16:01.0 +0800 @@ -188,7 +188,7 @@ jumped: } } - err = -ESRCH; + err = -ENETUNREACH; out: rcu_read_unlock(); -- 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 00/28] Swap over NFS -v16
On Saturday February 23, [EMAIL PROTECTED] wrote: > On Wed, 20 Feb 2008 15:46:10 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > Another posting of the full swap over NFS series. > > Well I looked. There's rather a lot of it and I wouldn't pretend to > understand it. But pretending is fun :-) > > What is the NFS and net people's take on all of this? Well I'm only vaguely an NFS person, barely a net person, sporadically an mm person, but I've had a look and it seems to mostly make sense. We introduce a new "emergency" concept for page allocation. The size of the emergency pool is set by various reservations by different potential users. If the number of free pages is below the "emergency" size, then only users with a "MEMALLOC" flag get to allocate pages. Further, those pages get a "reserve" flag set which propagates into slab/slub so kmalloc/kmemalloc only return memory from those pages to MEMALLOC users. MEMALLOC users are those that set PF_MEMALLOC. A socket can get SOCK_MEMALLOC set which will cause certain pieces of code to temporarily set PF_MEMALLOC while working on that socket. The upshot is that providing any MEMALLOC user reserves an appropriate amount of emergency space, returns the emergency memory promptly, and sets PF_MEMALLOC whenever allocating memory, it's memory allocations should never fail. As memory is requested is small units, but allocated as pages, there needs to be a conversion from small-units to pages. One of the patches does this and appears to err on the side of be over-generous, which is the right thing to do. Memory reservations are organised in a tree. I really don't understand the tree. Is it just to make /proc/reserve_info look more helpful? Certainly all the individual reservations need to be recorded, and the cumulative reservation needs also to be recorded (currently in the root of the tree) but what are all the other levels used for? Reservations are used for all the transient memory that might be used by the network stack. This particularly includes the route cache and skbs for incoming messages. I have no idea if there is anything else that needs to be allowed for. Filesystems can advertise (via address_space_operations) that files may be used as swap file. They then provide swapout/swapin methods which are like writepage/readpage but may behave differently and have a different way to get credentials from a 'struct file'. So in general, the patch set looks to have the right sort of shape. I cannot be very authoritative on the details as there are a lot of them, and they touch code that I'm not very familiar with. Some specific comments on patches: reserve-slub.patch Please avoid irrelevant reformatting in patches. It makes them harder to read. e.g.: -static void setup_object(struct kmem_cache *s, struct page *page, - void *object) +static void setup_object(struct kmem_cache *s, struct page *page, void *object) mm-kmem_estimate_pages.patch This introduces kestimate kestimate_single kmem_estimate_pages The last obviously returns a number of pages. The contrast seems to suggest the others don't. But they do... I don't think the names are very good, but I concede that it is hard to choose good names here. Maybe: kmalloc_estimate_variable kmalloc_estimate_fixed kmem_alloc_estimate ??? mm-reserve.patch I'm confused by __mem_reserve_add. + reserve = mem_reserve_root.pages; + __calc_reserve(res, pages, 0); + reserve = mem_reserve_root.pages - reserve; __calc_reserve will always add 'pages' to mem_reserve_root.pages. So this is a complex way of doing reserve = pages; __calc_reserve(res, pages, 0); And as you can calculate reserve before calling __calc_reserve (which seems odd when stated that way), the whole function looks like it could become: ret = adjust_memalloc_reserve(pages); if (!ret) __calc_reserve(res, pages, limit); return ret; What am I missing? Also, mem_reserve_disconnect really should be a "void" function. Just put a BUG_ON(ret) and don't return anything. Finally, I'll just repeat that the purpose of the tree structure eludes me. net-sk_allocation.patch Why are the "GFP_KERNEL" call sites just changed to "sk->sk_allocation" rather than "sk_allocation(sk, GFP_KERNEL)" ?? I assume there is a good reason, and seeing it in the change log would educate me and make the patch more obviously correct. netvm-reserve.patch Function names again: sk_adjust_memalloc sk_set_memalloc sound similar. Purpose is completely different. mm-page_file_methods.patch This makes page_offset and others more expensive by adding a conditional jump to a function call that is not usually made. Why do swap pages have a different index to everyon
Re: [Bluez-devel] forcing SCO connection patch
Hi Marcel
>> --- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25
>> 17:17:11.0 +0900
>> +++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25
>> 17:30:23.0 +0900
>> @@ -1313,8 +1313,17 @@
>> hci_dev_lock(hdev);
>>
>> conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
>> - if (!conn)
>> - goto unlock;
>> + if (!conn) {
>> + if (ev->link_type != ACL_LINK) {
>> + __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK : ESCO_LINK;
>> +
>> + conn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
>> + if (conn)
>> + conn->type = ev->link_type;
>> + }
>> + if (!conn)
>> + goto unlock;
>> + }
>
> NAK. There is no need to check for ACL_LINK. The sync_complete will
> only be called for SCO or eSCO connections.
I see. I removed this check line in the patch.
Thanks.
Louis JANG
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-26 12:46:36.0
+0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-26 12:47:23.0
+0900
@@ -1313,8 +1313,15 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK :
ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ else
+ goto unlock;
+ }
if (!ev->status) {
conn->handle = __le16_to_cpu(ev->handle);
Re: [Bluez-devel] forcing SCO connection patch
Hi Louis,
I fixed all of errors except 80 characters warning.
Thanks
Louis JANG
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25
17:17:11.0 +0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25
17:30:23.0 +0900
@@ -1313,8 +1313,17 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ if (ev->link_type != ACL_LINK) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK :
ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type,
&ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ }
+ if (!conn)
+ goto unlock;
+ }
NAK. There is no need to check for ACL_LINK. The sync_complete will
only be called for SCO or eSCO connections.
diff -uNr linux-2.6.23/include/net/bluetooth-orig/sco.h linux-2.6.23/
include/net/bluetooth/sco.h
--- linux-2.6.23/include/net/bluetooth-orig/sco.h 2007-10-10
05:31:38.0 +0900
+++ linux-2.6.23/include/net/bluetooth/sco.h 2008-02-25
18:04:20.0 +0900
@@ -51,6 +51,8 @@
__u8 dev_class[3];
};
+#define SCO_FORCESCO 0x03
+
NAK. We don't need this. And even if we really would want this, we
would do it via extra parameters inside sockaddr_sco. In that case we
would do it right and exposing eSCO settings and not some boolean
parameter.
Regards
Marcel
--
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
Get loan from xaio loan company........Apply now!!!
You can quickly qualify for a personal loan. We have come up with the resources that offer flexible plans to meet ones life goal. We offer some of the most flexible finance programs on the Internet. The procedure to apply for this type of financing is safe and simple, documentation is minimal and loan approval is quick. There is no collateral required! Contact email:[EMAIL PROTECTED] APPLICATION FORM Name of applicant :. Address of applicant: .. ... Nation : ... Country :.. State :... City: ... Zip Code :.. Telephone :.. . Fax: ... Birthday :.. Gender :.. Marital status :... Profession :.. Amount required :($). In Words The purpose of the loan :.. ... Loan amount . Term Loan / duration :. ... I (Mr / Ms ) Hereby declare that the information Above-mentioned conditions are met. Date : 2008 Best Regards, Dr.Xiao Ettek -- 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: [Netem] Fixed delay patch for netem
On Sun, 24 Feb 2008 12:11:16 -0200 "Julio Kriger" <[EMAIL PROTECTED]> wrote: > Hi! > I have created this patch to add a fixed delay on packet filtered by > netem. Soon I will send the patch to iproute2. > This patch comes from a need I have to delay all packets 50ms, beside > the actual delay setting, like 30ms +- 15 ms. Why is 50ms + 30m +/- 15ms any different than 80ms +/- 15ms > This strike, IMMHO, a > missing point on gap reordering. If I set "gap 5 delay 10ms" every 5th > (10th, 15th, ...) packet to go to be sent immediately and every other > packet to be delayed by 10ms. This is ok, but I also need a "fixed" > delay of 50ms to be applied to all packets. Since netem can't be > nested with himself (so I can do a fixed delay), I needed this new > feature on netem. The gap stuff is an awkward interface that should/could have been done better. > This patch was create with linux kernel version 2.6.24.2. > I hope you like it, and it would be great if it goes shiped with the > next version of the kernel :-)) > Regards, > Julio Kriger Maybe, but it is getting confusing with all the growth of parameters. Probably time for a rethink. -- 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: [Bugme-new] [Bug 10073] New: Just-small-enough packets in tunnels are silently eaten
On Sat, 23 Feb 2008 09:17:14 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10073 > >Summary: Just-small-enough packets in tunnels are silently eaten >Product: Networking >Version: 2.5 > KernelVersion: 2.6.23 (mainline), 2.6.25-rc2 (mainline), 2.6.18-6-amd64 > (Debian > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV6 > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Hi, > > This has been broken for quite a while, but I haven't gotten around to debug > it > until now. > > I have an IPv6-in-IPv4 tunnel between two points, both with MTU 1500 on the > regular v4 network. (I've verified that I can indeed send 1500-byte packets > and > fragments over IPv4 from the two points.) By default, Linux assigns MTU 1480 > to > this tunnel. > > However, if I try to ping -s 5000 from one side of the tunnel to the other, I > get > first "Packet too big, mtu=1480" and then on the next packet (when the machine > tries to send 1480-byte fragments) "Packet too big, mtu=1472". After that, the > packet goes through. > > However, in some cases it seems I do not seem to get the "Packet too big" ICMP > at all. In particular, if I change to a GRE tunnel (where the default MTU is > 1476), and send in 1476-byte packets, they are just eaten. They clearly go > into > the GRE tunnel (according to tcpdump), but no IPv4 packets ever go out on the > other side, and no ICMPs are sent back. (There's no iptables rules on the > router in question, nor any relevant sysctl settings except that IPv6 > forwarding is of course turned on.) If I lower MTU on the interfaces to 1468, > everything seems to work just fine. (I cannot change the MTU of a regular ipip > tunnel, so it's impossible for me to check whether a lower MTU would have > fixed > the issues for those as well, but it seems reasonable.) > > Any idea where the extra eight bytes go? Is there some inner layer of > encapsulation in the kernel (adding eight bytes internally) that I've missed? > -- 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: [git patches] net driver updates
Divy Le Ray wrote: So, it sounds like Krishna's patch is ok, because the race does not exist anymore in this driver? The first part is right indeed, but the second part is breaking the current usage of txq_stopped and the logic that stops and restarts the Tx queue. I can submit a patch fixing it. Plese let me know what's more convenient for you. At this point, yes a fix (with a good patch description) would be preferred... Thanks, Jeff -- 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: [git patches] net driver updates
So, it sounds like Krishna's patch is ok, because the race does not exist anymore in this driver? The first part is right indeed, but the second part is breaking the current usage of txq_stopped and the logic that stops and restarts the Tx queue. I can submit a patch fixing it. Plese let me know what's more convenient for you. Cheers, Divy -- 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: printk_ratelimit and net_ratelimit conflict and tunable behavior
On Mon, 25 Feb 2008 14:36:40 -0600 Steven Hawkes <[EMAIL PROTECTED]> wrote:
> From: Steve Hawkes <[EMAIL PROTECTED]>
>
> The printk_ratelimit() and net_ratelimit() functions each have their own
> tunable parameters to control their respective rate limiting feature, but
> they share common state variables, preventing independent tuning of the
> parameters from working correctly. Also, changes to rate limiting tunable
> parameters do not always take effect properly since state is not recomputed
> when changes occur. For example, if ratelimit_burst is increased while rate
> limiting is occurring, the change won't take full effect until at least
> enough time between messages occurs so that the toks value reaches
> ratelimit_burst * ratelimit_jiffies. This can result in messages being
> suppressed when they should be allowed.
>
> Implement independent state for printk_ratelimit() and net_ratelimit(), and
> update state when tunables are changed.
>
This patch causes a large and nasty reject.
> ---
> --- linux-2.6.24/include/linux/kernel.h 2008-01-24 16:58:37.0
> -0600
> +++ linux-2.6.24-printk_ratelimit/include/linux/kernel.h 2008-02-21
> 11:20:41.751197312 -0600
Probably because you patched 2.6.24. We're developing 2.6.25 now, and the
difference between the two is very large inded. Please raise patches
against Linus's latest tree?
There are other patches pending against printk.c (in -mm and in git-sched)
but afacit they won't collide.
> @@ -196,8 +196,19 @@ static inline int log_buf_copy(char *des
>
> unsigned long int_sqrt(unsigned long);
>
> +struct printk_ratelimit_state
> +{
Please do
struct printk_ratelimit_state {
> + unsigned long toks;
> + unsigned long last_jiffies;
> + int missed;
> + int limit_jiffies;
> + int limit_burst;
> + char const *facility;
> +};
I find that the best-value comments one can add to kernel code are to the
members of structures. If the reader understands what all the fields do, the
code becomes simple to follow.
> --- linux-2.6.24/net/core/utils.c 2008-01-24 16:58:37.0 -0600
> +++ linux-2.6.24-printk_ratelimit/net/core/utils.c2008-02-21
> 11:03:44.644337698 -0600
> @@ -41,7 +41,16 @@ EXPORT_SYMBOL(net_msg_warn);
> */
> int net_ratelimit(void)
> {
> - return __printk_ratelimit(net_msg_cost, net_msg_burst);
> + static struct printk_ratelimit_state limit_state = {
> + .toks = 10 * 5 * HZ,
> + .last_jiffies = 0,
> + .missed= 0,
> + .limit_jiffies = 5 * HZ,
> + .limit_burst = 10,
> + .facility = "net"
> + };
> +
> + return __printk_ratelimit(net_msg_cost, net_msg_burst, &limit_state);
I don't get it. There's one instance of limit_state, kernel-wide, and
__printk_ratelimit() modifies it. What prevents one CPU's activities from
interfering with a second CPU's activities?
--
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: [git patches] net driver updates
Marin Mitov wrote: On Tuesday 26 February 2008 12:59:04 am you wrote: Divy Le Ray wrote: From: "Divy Le Ray" <[EMAIL PROTECTED]> Date: Wed, 20 Feb 2008 21:57:08 -0800 The driver is cxgb3 here, it uses LLTX. That's extremely unfortunate, hopefully you can update it to use a model like tg3 and others use. LLTX is a lost cause for hardware device drivers, and in fact we'd like to remove it tree wide eventually. Just for info: loopback.c uses it too :-) Yes, we're all aware of this. Google for "david miller loopback lltx" for a few examples... Also, please do not strip CC's, that's quite annoying. Jeff -- 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: [git patches] net driver updates
Divy Le Ray wrote: From: "Divy Le Ray" <[EMAIL PROTECTED]> Date: Wed, 20 Feb 2008 21:57:08 -0800 The driver is cxgb3 here, it uses LLTX. That's extremely unfortunate, hopefully you can update it to use a model like tg3 and others use. LLTX is a lost cause for hardware device drivers, and in fact we'd like to remove it tree wide eventually. It sounds like I messed up. cxgb3 does not use LLTX - The Chelsio driver does, thus should be converted. So, it sounds like Krishna's patch is ok, because the race does not exist anymore in this driver? Jeff -- 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: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Shift calculation wrong for single sge entries.
Thanks, applied, although I assume based on the Signed-off-by line that you left out a From: Bryan Rosenburg <[EMAIL PROTECTED]> at the top (to get the authorship in git correctly). > RDMA/cxgb3: Shift calculation wrong for single sge entries. BTW, there's no need to duplicate the subject line in the message body, but if you are going to do it, please put a "Subject:" before it. Otherwise I just have to edit it out by hand to avoid git putting the subject in twice. - R. -- 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
r8169 driver compatibility with rtl8168 [need confirm]
Hi, Many users who have onboard Realtek 8168 network controllers in combination with nVidia hardware (mostly nVidia graphic card and/or nForce motherboard (MCP5x) ) experience still-not-very-explained hangup triggered by heavy network usage which fills a tx buffer, and (speculation) causes race condition on irq sharing, resulting in absolute freeze (not oops/panic). On all affected machines I've seen this fix solved the problem: --- a/drivers/net/r8169.c 2008-02-25 22:53:01.0 +0100 +++ b/drivers/net/r8169.c 2008-02-25 22:54:32.0 +0100 @@ -86,8 +86,8 @@ #define R8169_REGS_SIZE256 #define R8169_NAPI_WEIGHT 64 -#define NUM_TX_DESC64 /* Number of Tx descriptor registers */ -#define NUM_RX_DESC256 /* Number of Rx descriptor registers */ +#define NUM_TX_DESC1024/* Number of Tx descriptor registers */ +#define NUM_RX_DESC1024/* Number of Rx descriptor registers */ #define RX_BUF_SIZE1536/* Rx Buffer size */ #define R8169_TX_RING_BYTES(NUM_TX_DESC * sizeof(struct TxDesc)) #define R8169_RX_RING_BYTES(NUM_RX_DESC * sizeof(struct RxDesc)) It's not really a fix, we do not address the real race cond. (or whatever) problem, but it removes the hangup and causes no negative side effects. I need someone else who can confirm that it works. cheers, [exa] PS. There might already be some fixes, but I didn't manage to find them. -- 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: [Bugme-new] [Bug 10071] New: kernel hang in inet_init
On Sat, 23 Feb 2008 00:34:06 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10071 > >Summary: kernel hang in inet_init >Product: Networking >Version: 2.5 > KernelVersion: 2.6.25 rc2 latest git > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV4 > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Distribution:ubuntu hardy > Hardware Environment:dell dimension 5150 > Problem Description: > kernel hang mostly but boot slowly sometimes > > Steps to reproduce: > boot > > when the computer manage to boot, inet_init last some time: > [1.725306] NET: Registered protocol family 2 > [6.825384] IP route cache hash table entries: 32768 (order: 5, 131072 > bytes) > [6.825803] TCP established hash table entries: 131072 (order: 8, 1048576 > bytes) > [6.826691] TCP bind hash table entries: 65536 (order: 9, 2359296 bytes) > [6.836160] TCP: Hash tables configured (established 131072 bind 65536) > [6.836255] TCP reno registered > [7.081569] initcall 0xc03b8920: inet_init+0x0/0x3aa() returned 0. > [7.081569] initcall 0xc03b8920 ran for 5106 msecs: inet_init+0x0/0x3aa() > > When booting with acpi=ht it works: > [0.124668] Calling initcall 0xc03b8920: inet_init+0x0/0x3aa() > [0.124867] NET: Registered protocol family 2 > [0.288067] IP route cache hash table entries: 32768 (order: 5, 131072 > bytes) > [0.288856] TCP established hash table entries: 131072 (order: 8, 1048576 > bytes) > [0.289739] TCP bind hash table entries: 65536 (order: 9, 2359296 bytes) > [0.299156] TCP: Hash tables configured (established 131072 bind 65536) > [0.299250] TCP reno registered > Feb 23 09:10:28 tiyann kernel: [0.162267] initcall 0xc03b8920: > inet_init+0x0/0x3aa() returned 0. > [0.162383] initcall 0xc03b8920 ran for 33 msecs: inet_init+0x0/0x3aa() > > there seem to be a weird interaction between acpi and inet_init > > any hint on how to provide better information > thanks > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
Jarek Poplawski wrote, On 02/25/2008 02:39 PM: ... > Hmm... Wait a minute! But on the other hand David has written about > his cons here, and it looks reasonable: this place would be fixed, > but some others can start reports like this. Maybe, it's better to > analyze yet if it's really so hard to eliminate taking this lock > on the xmit path? James, I wonder if you could try to test this patch below? ip_queue_xmit() seems to do proper things with __sk_dst_check(), and if some other functions don't behave similarly lockdep should tell. I think, you could test it with your "locks to _bh" patch (without pppol2tp_xmit() part), and maybe with my sock.c lockdep patch (it should help lockdep to see these locks a bit more distinctly). Jarek P. PS: Since ppp_generic isn't endangered for now I removed Paul from CC. --- diff --git a/drivers/net/pppol2tp.c b/drivers/net/pppol2tp.c index e0b072d..b94659a 100644 --- a/drivers/net/pppol2tp.c +++ b/drivers/net/pppol2tp.c @@ -1058,7 +1058,7 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb) /* Get routing info from the tunnel socket */ dst_release(skb->dst); - skb->dst = sk_dst_get(sk_tun); + skb->dst = NULL; skb_orphan(skb); skb->sk = sk_tun; -- 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: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
On Monday 25 February 2008 08:28:14 Jeff Garzik wrote: > Grant Grundler wrote: > > ISTR there was a time when tulip would compete with de4x5 for devices. > > tulip is the preferred driver. That's clearly no longer the case > > and perhaps both distro's need to revisit this. > > The only reason why de4x5 still exists is that the /tulip/ driver fails > to work on a few chips like the 21142 (43?) shipped in various alpha boxen. > > de4x5 needs to go away, it's been unmaintained for ages, doesn't support > any of the new hotplug APIs. But has extensive port auto-detection which seems to work great (at least on my card). I don't feel like porting that code to de2104x - the code looks complex. > > > de2104x is a "work in progress". > > That's why it's marked "EXPERIMENTAL" in the Kconfig file. > > It's not a work in progress, it works just fine for most people (the few > that are left). > > Last I heard, there was a problem with non-twisted-pair stuff, but > that's about it. > > 'experimental' is generally a poorly maintained marker. So we have two unmaintained drivers - one that works fine (and is production quality - or at least seems to be) but does not support hotplug APIs and one that was never finished (the TP-unplug problem is present at least since 2003). Perhaps de4x5 could be ported to new API(s)? I think that it's much easier than fixing obscure hardware-related problems like cable auto-detection. -- Ondrej Zary -- 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.25-rc2-git] rndis_host: fix transfer size negotiation
> > This patch should resolve a problem that's troubled support for > > some RNDIS peripherals. It seems to have boiled down to using a > > variable to establish transfer size limits before it was assigned, > > which caused those devices to fallback to a default "jumbogram" > > mode we don't support. Fix by assigning it earlier for RNDIS. > > Any chance that something like this is appropriate for rndis_wlan? I'd expect so; but, isn't it already getting that benefit? - Dave -- 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
printk_ratelimit and net_ratelimit conflict and tunable behavior
From: Steve Hawkes <[EMAIL PROTECTED]>
The printk_ratelimit() and net_ratelimit() functions each have their own
tunable parameters to control their respective rate limiting feature, but
they share common state variables, preventing independent tuning of the
parameters from working correctly. Also, changes to rate limiting tunable
parameters do not always take effect properly since state is not recomputed
when changes occur. For example, if ratelimit_burst is increased while rate
limiting is occurring, the change won't take full effect until at least
enough time between messages occurs so that the toks value reaches
ratelimit_burst * ratelimit_jiffies. This can result in messages being
suppressed when they should be allowed.
Implement independent state for printk_ratelimit() and net_ratelimit(), and
update state when tunables are changed.
Signed-off-by: Steve Hawkes <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.24/include/linux/kernel.h
linux-2.6.24-printk_ratelimit/include/linux/kernel.h
--- linux-2.6.24/include/linux/kernel.h 2008-01-24 16:58:37.0 -0600
+++ linux-2.6.24-printk_ratelimit/include/linux/kernel.h2008-02-21
11:20:41.751197312 -0600
@@ -196,8 +196,19 @@ static inline int log_buf_copy(char *des
unsigned long int_sqrt(unsigned long);
+struct printk_ratelimit_state
+{
+ unsigned long toks;
+ unsigned long last_jiffies;
+ int missed;
+ int limit_jiffies;
+ int limit_burst;
+ char const *facility;
+};
+
extern int printk_ratelimit(void);
-extern int __printk_ratelimit(int ratelimit_jiffies, int ratelimit_burst);
+extern int __printk_ratelimit(int ratelimit_jiffies, int ratelimit_burst,
+ struct printk_ratelimit_state *state);
extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
unsigned int interval_msec);
diff -uprN linux-2.6.24/kernel/printk.c
linux-2.6.24-printk_ratelimit/kernel/printk.c
--- linux-2.6.24/kernel/printk.c2008-01-24 16:58:37.0 -0600
+++ linux-2.6.24-printk_ratelimit/kernel/printk.c 2008-02-21
11:22:27.442319625 -0600
@@ -1238,35 +1238,41 @@ void tty_write_message(struct tty_struct
/*
* printk rate limiting, lifted from the networking subsystem.
*
- * This enforces a rate limit: not more than one kernel message
- * every printk_ratelimit_jiffies to make a denial-of-service
- * attack impossible.
+ * This enforces a rate limit to mitigate denial-of-service attacks:
+ * not more than ratelimit_burst messages every ratelimit_jiffies.
*/
-int __printk_ratelimit(int ratelimit_jiffies, int ratelimit_burst)
+int __printk_ratelimit(int ratelimit_jiffies,
+ int ratelimit_burst,
+ struct printk_ratelimit_state *state)
{
static DEFINE_SPINLOCK(ratelimit_lock);
- static unsigned long toks = 10 * 5 * HZ;
- static unsigned long last_msg;
- static int missed;
unsigned long flags;
unsigned long now = jiffies;
spin_lock_irqsave(&ratelimit_lock, flags);
- toks += now - last_msg;
- last_msg = now;
- if (toks > (ratelimit_burst * ratelimit_jiffies))
- toks = ratelimit_burst * ratelimit_jiffies;
- if (toks >= ratelimit_jiffies) {
- int lost = missed;
-
- missed = 0;
- toks -= ratelimit_jiffies;
+ state->toks += now - state->last_jiffies;
+ /* Reset limiting if tunables changed */
+ if ((state->limit_jiffies != ratelimit_jiffies) ||
+ (state->limit_burst != ratelimit_burst)) {
+ state->toks = ratelimit_burst * ratelimit_jiffies;
+ state->limit_jiffies = ratelimit_jiffies;
+ state->limit_burst = ratelimit_burst;
+ }
+ state->last_jiffies = now;
+ if (state->toks > (ratelimit_burst * ratelimit_jiffies))
+ state->toks = ratelimit_burst * ratelimit_jiffies;
+ if (state->toks >= ratelimit_jiffies) {
+ int lost = state->missed;
+ state->missed = 0;
+ state->toks -= ratelimit_jiffies;
spin_unlock_irqrestore(&ratelimit_lock, flags);
- if (lost)
- printk(KERN_WARNING "printk: %d messages
suppressed.\n", lost);
+ if (lost) {
+ pr_warning("%s ratelimit suppressed message count:
%d\n",
+ state->facility, lost);
+ }
return 1;
}
- missed++;
+ state->missed++;
spin_unlock_irqrestore(&ratelimit_lock, flags);
return 0;
}
@@ -1280,8 +1286,17 @@ int printk_ratelimit_burst = 10;
int printk_ratelimit(void)
{
+ static struct printk_ratelimit_state limit_state = {
+ .toks = 10 * 5 * HZ,
+ .last_jiffies = 0,
+ .missed= 0,
+ .limit_jiffies = 5 * HZ,
+ .limit_bur
Re: [PATCH] [XFRM] Beet: Fix output for ipv6
Hi Herbert,
Have you had a chance to look this, or are you working on something else for
it?
On Friday 08 February 2008 18:12, Joakim Koskela wrote:
> Hi,
>
> This patch fixes the ipv6 mode of ipsec beet. It has been using logic
> similar to tunnel mode, making it crash during esp packaging.
>
> Signed-off-by: Joakim Koskela <[EMAIL PROTECTED]>
> ---
> net/ipv6/xfrm6_mode_beet.c |9 ++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/xfrm6_mode_beet.c b/net/ipv6/xfrm6_mode_beet.c
> index 0527d11..0395800 100644
> --- a/net/ipv6/xfrm6_mode_beet.c
> +++ b/net/ipv6/xfrm6_mode_beet.c
> @@ -40,11 +40,14 @@ static void xfrm6_beet_make_header(struct sk_buff *skb)
> static int xfrm6_beet_output(struct xfrm_state *x, struct sk_buff *skb)
> {
> struct ipv6hdr *top_iph;
> + u8 *prevhdr;
> + int hdr_len;
>
> + hdr_len = x->type->hdr_offset(x, skb, &prevhdr);
> + skb_set_mac_header(skb, (prevhdr - x->props.header_len) - skb->data);
> skb_set_network_header(skb, -x->props.header_len);
> - skb->mac_header = skb->network_header +
> - offsetof(struct ipv6hdr, nexthdr);
> - skb->transport_header = skb->network_header + sizeof(*top_iph);
> + skb->transport_header = skb->network_header + hdr_len;
> + __skb_pull(skb, hdr_len);
>
> xfrm6_beet_make_header(skb);
>
--
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: New sparse warning in net/mac80211/debugfs_sta.c
From: Johannes Berg <[EMAIL PROTECTED]> Date: Mon, 25 Feb 2008 21:05:42 +0100 > > On Mon, 2008-02-25 at 20:56 +0100, Johannes Berg wrote: > > On Mon, 2008-02-25 at 11:52 -0800, David Miller wrote: > > > From: Johannes Berg <[EMAIL PROTECTED]> > > > Date: Mon, 25 Feb 2008 10:53:48 +0100 > > > > > > > Maybe we should just add a new printf modifier like %M for MAC > > > > addresses? Then we could use sprintf, snprintf, printk and whatever we > > > > please without any of the macro stuff... > > > > > > But GCC has no idea what the heck it is and will warn. > > > > No, I actually wondered about that too and finally just tried, it simply > > ignores it when doing the printf warnings. > > Wait, no, you're right, I had the wrong warning flags enabled :( Oh well :-/ I really think it's not worth dorking around with this print_mac() stuff so much like this, let's just take care of the cases that Patrick mentioned (which need to go back to MAC_FMT because they are in fast paths) and then leave this alone for a while. We've already wasted too much time on this. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: printk_ratelimit and net_ratelimit conflict and tunable behavior
On Mon, 2008-02-25 at 09:47 -0600, Hawkes Steve-FSH016 wrote: > How about this? line wrapped, but seems better. > Signed-off-by: Steve Hawkes <[EMAIL PROTECTED]> > > diff -uprN linux-2.6.24/include/linux/kernel.h > linux-2.6.24-printk_ratelimit/include/linux/kernel.h > --- linux-2.6.24/include/linux/kernel.h 2008-01-24 16:58:37.0 > + * This enforces a rate limit to mitigate denial-of-service attacks: > + * not more than ratelimit_burst messages every ratelimit_jiffies. > */ > -int __printk_ratelimit(int ratelimit_jiffies, int ratelimit_burst) > +int __printk_ratelimit(int ratelimit_jiffies, > + int ratelimit_burst, > + struct printk_ratelimit_state *state) I think the value of in-place tunables is low. I'd remove that bit and use the struct printk_ratelimit_state. David Miller points out that struct initializations to 0 or NULL are not necessary. -- 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.25-rc3] smc91x section fix
On Sun, Feb 24, 2008 at 10:33:12PM -0800, David Brownell wrote: > On Sunday 24 February 2008, Sam Ravnborg wrote: > > > From a quick look this is wrong. > > smc_drv_probe is assined the .probe member so it is used during > > hotplug and thus should be __devinit. > > Likewise smc_probe is used by smc_drv_probe and thus smc_probe > > should be __devinit too. > > Thing is, with only rare exceptions, devices on the platform > bus are *NOT* hotpluggable. So using __devinit/__devexit and > friends adds up to no more than a waste of I-space. It was a quick look - thanks for the explanation. Sam -- 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: New sparse warning in net/mac80211/debugfs_sta.c
From: Johannes Berg <[EMAIL PROTECTED]> Date: Mon, 25 Feb 2008 20:56:43 +0100 > > On Mon, 2008-02-25 at 11:52 -0800, David Miller wrote: > > From: Johannes Berg <[EMAIL PROTECTED]> > > Date: Mon, 25 Feb 2008 10:53:48 +0100 > > > > > Maybe we should just add a new printf modifier like %M for MAC > > > addresses? Then we could use sprintf, snprintf, printk and whatever we > > > please without any of the macro stuff... > > > > But GCC has no idea what the heck it is and will warn. > > No, I actually wondered about that too and finally just tried, it simply > ignores it when doing the printf warnings. Ok, so it simply can't validate the thing. -- 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: New sparse warning in net/mac80211/debugfs_sta.c
On Mon, 2008-02-25 at 20:56 +0100, Johannes Berg wrote: > On Mon, 2008-02-25 at 11:52 -0800, David Miller wrote: > > From: Johannes Berg <[EMAIL PROTECTED]> > > Date: Mon, 25 Feb 2008 10:53:48 +0100 > > > > > Maybe we should just add a new printf modifier like %M for MAC > > > addresses? Then we could use sprintf, snprintf, printk and whatever we > > > please without any of the macro stuff... > > > > But GCC has no idea what the heck it is and will warn. > > No, I actually wondered about that too and finally just tried, it simply > ignores it when doing the printf warnings. Wait, no, you're right, I had the wrong warning flags enabled :( johannes signature.asc Description: This is a digitally signed message part
Re: printk_ratelimit and net_ratelimit conflict and tunable behavior
From: "Hawkes Steve-FSH016" <[EMAIL PROTECTED]> Date: Mon, 25 Feb 2008 09:47:11 -0600 > > .facility = NULL > > How about this? Actually, for compile time initializations, setting anything to zero is superfluous and by convention is not therefore explicitly done in the sources. -- 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: New sparse warning in net/mac80211/debugfs_sta.c
On Mon, 2008-02-25 at 12:47 +0100, Patrick McHardy wrote:
> It would be good if Joe could go through the remaining print_mac users
> and convert the remaining unintended function calls in fastpaths back
> to MAC_FMT. Grepping for "start_xmit" in commit 0795af5729b shows that
> at least 10 hard_start_xmit functions are affected and I expect that
> some of the changes in the wireless code affect fastpaths as well.
I don't mind doing that, as calling print_mac in these fastpaths in
unintentional and undesirable. But wouldn't it be better to find a
solution that removes all debug printk function calls that should
be optimized away?
I have not seen any response to a suggestion to convert debug printk
macros (dprintk, pr_debug, dev_dbg, etc) to:
#define pr_debug(fmt, arg...) \
do { if (0) printk(KERN_DEBUG fmt, ##arg); } while (0)
This preserves argument verification and gives the compiler the
capability to optimize out the printk and any functions the printk
might call.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 2df44e7..cd24112 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -293,10 +293,8 @@ extern void print_hex_dump_bytes(const char *prefix_str,
int prefix_type,
#define pr_debug(fmt, arg...) \
printk(KERN_DEBUG fmt, ##arg)
#else
-static inline int __attribute__ ((format (printf, 1, 2))) pr_debug(const char
* fmt, ...)
-{
- return 0;
-}
+#define pr_debug(fmt, arg...) \
+ do { if (0) printk(KERN_DEBUG fmt, ##arg); } while (0)
#endif
/*
diff --git a/include/linux/device.h b/include/linux/device.h
index 2258d89..79601b1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -608,21 +608,15 @@ extern const char *dev_driver_string(struct device *dev);
#define dev_dbg(dev, format, arg...) \
dev_printk(KERN_DEBUG , dev , format , ## arg)
#else
-static inline int __attribute__ ((format (printf, 2, 3)))
-dev_dbg(struct device *dev, const char *fmt, ...)
-{
- return 0;
-}
+#define dev_dbg(dev, format, arg...) \
+ do { if (0) dev_printk(KERN_DEBUG , dev , format, ## arg); } while (0)
#endif
#ifdef VERBOSE_DEBUG
#define dev_vdbg dev_dbg
#else
-static inline int __attribute__ ((format (printf, 2, 3)))
-dev_vdbg(struct device *dev, const char *fmt, ...)
-{
- return 0;
-}
+#define dev_vdbg(dev, format, arg...) \
+ do { if (0) dev_printk(KERN_DEBUG , dev , format, ## arg); } while (0)
#endif
/* Create alias, so I can be autoloaded. */
--
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: New sparse warning in net/mac80211/debugfs_sta.c
On Mon, 2008-02-25 at 11:52 -0800, David Miller wrote: > From: Johannes Berg <[EMAIL PROTECTED]> > Date: Mon, 25 Feb 2008 10:53:48 +0100 > > > Maybe we should just add a new printf modifier like %M for MAC > > addresses? Then we could use sprintf, snprintf, printk and whatever we > > please without any of the macro stuff... > > But GCC has no idea what the heck it is and will warn. No, I actually wondered about that too and finally just tried, it simply ignores it when doing the printf warnings. johannes signature.asc Description: This is a digitally signed message part
Re: New sparse warning in net/mac80211/debugfs_sta.c
From: Johannes Berg <[EMAIL PROTECTED]> Date: Mon, 25 Feb 2008 10:53:48 +0100 > Maybe we should just add a new printf modifier like %M for MAC > addresses? Then we could use sprintf, snprintf, printk and whatever we > please without any of the macro stuff... But GCC has no idea what the heck it is and will warn. -- 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] llc: fix skb size for test responses
From: Jim Westfall <[EMAIL PROTECTED]> Date: Sun, 24 Feb 2008 21:04:21 -0800 > I sent it a few minutes after this one, but seems like it never made it > to the list. My local smtp shows it was delivered sucussfully to > vger.kernel.org. Usually this means some string in the email triggered our Majordomo level regexp filters, they are listed at: http://vger.kernel.org/majordomo-info.html#taboo -- 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
problems with e1000 and flow control
Hello, it seems that e1000 enables flow-control (rx pause frames) even if the switch does not advertise flow control. This seems to get a problem as (at least some) switches then forward pause frames directed to the card from other hosts. We think there are hosts which indeed do this in the lans of our student halls. I think flow control should be completely disabled by default if the switch does not advertise it. It still can be forced with ethtool. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- 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 RESEND] libertas: Remove unused exports
On Sat, 2008-02-23 at 20:10 -0800, Roland Dreier wrote:
> Any chance of getting this applied? It seems the build is still
> broken on ia64 at least due to the export of static functions.
> ---
Normal route is to [EMAIL PROTECTED]
However; if the symbols aren't used anywhere in
drivers/net/wireless/libertas/*, it makes no sense to keep them around &
exported.
Acked-by: Dan Williams <[EMAIL PROTECTED]>
>
> The libertas driver exports a number of symbols with no in-tree
> users; remove these unused exports. lbs_reset_device() is completely
> unused, with no callers at all, so remove the function completely.
>
> A couple of these unused exported symbols are static, which causes the
> following build error on ia64 with gcc 4.2.3:
>
> drivers/net/wireless/libertas/main.c:1375: error:
> __ksymtab_lbs_remove_mesh causes a section type conflict
> drivers/net/wireless/libertas/main.c:1354: error: __ksymtab_lbs_add_mesh
> causes a section type conflict
>
> This patch fixes this problem. I don't have hardware, so this is not
> run-tested, but I tested the build with
>
> CONFIG_LIBERTAS=y
> CONFIG_LIBERTAS_USB=m
> CONFIG_LIBERTAS_CS=m
> CONFIG_LIBERTAS_SDIO=m
>
> and there were no problems with undefined symbols.
>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/net/wireless/libertas/cmd.c
> b/drivers/net/wireless/libertas/cmd.c
> index eab0203..b3c1acb 100644
> --- a/drivers/net/wireless/libertas/cmd.c
> +++ b/drivers/net/wireless/libertas/cmd.c
> @@ -1040,7 +1040,6 @@ int lbs_mesh_access(struct lbs_private *priv, uint16_t
> cmd_action,
> lbs_deb_leave(LBS_DEB_CMD);
> return ret;
> }
> -EXPORT_SYMBOL_GPL(lbs_mesh_access);
>
> int lbs_mesh_config(struct lbs_private *priv, uint16_t enable, uint16_t chan)
> {
> @@ -1576,7 +1575,6 @@ done:
> lbs_deb_leave_args(LBS_DEB_HOST, "ret %d", ret);
> return ret;
> }
> -EXPORT_SYMBOL_GPL(lbs_prepare_and_send_command);
>
> /**
> * @brief This function allocates the command buffer and link
> diff --git a/drivers/net/wireless/libertas/decl.h
> b/drivers/net/wireless/libertas/decl.h
> index aaacd9b..4e22341 100644
> --- a/drivers/net/wireless/libertas/decl.h
> +++ b/drivers/net/wireless/libertas/decl.h
> @@ -69,7 +69,6 @@ struct lbs_private *lbs_add_card(void *card, struct device
> *dmdev);
> int lbs_remove_card(struct lbs_private *priv);
> int lbs_start_card(struct lbs_private *priv);
> int lbs_stop_card(struct lbs_private *priv);
> -int lbs_reset_device(struct lbs_private *priv);
> void lbs_host_to_card_done(struct lbs_private *priv);
>
> int lbs_update_channel(struct lbs_private *priv);
> diff --git a/drivers/net/wireless/libertas/main.c
> b/drivers/net/wireless/libertas/main.c
> index 84fb49c..1eaf6af 100644
> --- a/drivers/net/wireless/libertas/main.c
> +++ b/drivers/net/wireless/libertas/main.c
> @@ -1351,8 +1350,6 @@ done:
> lbs_deb_leave_args(LBS_DEB_MESH, "ret %d", ret);
> return ret;
> }
> -EXPORT_SYMBOL_GPL(lbs_add_mesh);
> -
>
> static void lbs_remove_mesh(struct lbs_private *priv)
> {
> @@ -1372,7 +1369,6 @@ static void lbs_remove_mesh(struct lbs_private *priv)
> free_netdev(mesh_dev);
> lbs_deb_leave(LBS_DEB_MESH);
> }
> -EXPORT_SYMBOL_GPL(lbs_remove_mesh);
>
> /**
> * @brief This function finds the CFP in
> @@ -1458,20 +1454,6 @@ void lbs_interrupt(struct lbs_private *priv)
> }
> EXPORT_SYMBOL_GPL(lbs_interrupt);
>
> -int lbs_reset_device(struct lbs_private *priv)
> -{
> - int ret;
> -
> - lbs_deb_enter(LBS_DEB_MAIN);
> - ret = lbs_prepare_and_send_command(priv, CMD_802_11_RESET,
> - CMD_ACT_HALT, 0, 0, NULL);
> - msleep_interruptible(10);
> -
> - lbs_deb_leave_args(LBS_DEB_MAIN, "ret %d", ret);
> - return ret;
> -}
> -EXPORT_SYMBOL_GPL(lbs_reset_device);
> -
> static int __init lbs_init_module(void)
> {
> lbs_deb_enter(LBS_DEB_MAIN);
--
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: [Bugme-new] [Bug 10097] New: SMP BUG in __nf_conntrack_find
On Mon, 25 Feb 2008 10:44:08 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10097 > >Summary: SMP BUG in __nf_conntrack_find >Product: Networking >Version: 2.5 > KernelVersion: 2.6.25-rc3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Netfilter/Iptables > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Latest working kernel version: 2.6.24.2 > Earliest failing kernel version: 2.6.24-rc3 (not checked before) > Distribution: Bluewhite64 > Hardware Environment: Athlon X2 4200 > > Software Environment: > samba 3.0, 2.6.25-rc3 kernel + HR + tickless + kernel SMP debugging > > Problem Description: > The Samba smbd daemon triggers regularly the following BUG with 2.6.25-rc3: > > BUG: using smp_processor_id() in preemptible [] code: nmbd/3167 > caller is __nf_conntrack_find+0x119/0x150 > Pid: 3167, comm: nmbd Not tainted 2.6.25-rc3 #1 > > Call Trace: > [] debug_smp_processor_id+0xc4/0xd0 > [] __nf_conntrack_find+0x119/0x150 > [] nf_conntrack_find_get+0x19/0x80 > [] nf_conntrack_in+0x1a4/0x5a0 > [] ? restore_args+0x0/0x30 > [] ipv4_conntrack_local+0x66/0x70 > [] nf_iterate+0x62/0xa0 > [] ? dst_output+0x0/0x10 > [] nf_hook_slow+0x66/0xe0 > [] ? dst_output+0x0/0x10 > [] __ip_local_out+0xa5/0xb0 > [] ip_local_out+0x11/0x30 > [] ip_push_pending_frames+0x261/0x3e0 > [] udp_push_pending_frames+0x233/0x3d0 > [] udp_sendmsg+0x30f/0x710 > [] ? default_wake_function+0x0/0x10 > [] inet_sendmsg+0x45/0x80 > [] sock_sendmsg+0xdf/0x110 > [] ? autoremove_wake_function+0x0/0x40 > [] ? hrtick_resched+0x77/0x90 > [] ? trace_hardirqs_on+0xd5/0x160 > [] ? sockfd_lookup_light+0x45/0x80 > [] sys_sendto+0xea/0x120 > [] ? _spin_unlock_irq+0x2b/0x60 > [] ? trace_hardirqs_on+0xd5/0x160 > [] ? _spin_unlock_irq+0x36/0x60 > [] system_call_after_swapgs+0x7b/0x80 > > Steps to reproduce: > Start smbd with the forementionned kernel instrumented for SMP and kernel > debugging and hr + tickless enabled. > Presumably this is in NF_CT_STAT_INC(). I wonder what caused it to start happening. Guys, this probably means that the developers who tested this change aren't enabling the debug options which all kernel developers _should_ be enabling when "testing" their code! Documentation/SubmitChecklist has a handy list. Should NF_CT_STAT_INC() be using local_inc()? -- 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.25-rc2-git] rndis_host: fix transfer size negotiation
On Mon, 2008-02-25 at 13:29 -0500, John W. Linville wrote: > On Fri, Feb 22, 2008 at 05:31:16PM -0800, David Brownell wrote: > > From: Jean-Christophe Dubois <[EMAIL PROTECTED]> > > > > This patch should resolve a problem that's troubled support for > > some RNDIS peripherals. It seems to have boiled down to using a > > variable to establish transfer size limits before it was assigned, > > which caused those devices to fallback to a default "jumbogram" > > mode we don't support. Fix by assigning it earlier for RNDIS. > > Any chance that something like this is appropriate for rndis_wlan? rndis_wlan uses this code so it already "got" this change. johannes signature.asc Description: This is a digitally signed message part
Re: [patch 2.6.25-rc2-git] rndis_host: fix transfer size negotiation
On Fri, Feb 22, 2008 at 05:31:16PM -0800, David Brownell wrote: > From: Jean-Christophe Dubois <[EMAIL PROTECTED]> > > This patch should resolve a problem that's troubled support for > some RNDIS peripherals. It seems to have boiled down to using a > variable to establish transfer size limits before it was assigned, > which caused those devices to fallback to a default "jumbogram" > mode we don't support. Fix by assigning it earlier for RNDIS. Any chance that something like this is appropriate for rndis_wlan? John -- John W. Linville [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ethtool netlink interface
* Jeff Garzik <[EMAIL PROTECTED]> 2008-02-25 12:30 > However, I would think it inconsistent to only do SSET/GSET. If others > are OK with this patch, are you open to implementing the full set of > ethtool operations? Of course, I would also provide a documented userspace api within libnl. -- 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] de2104x: remove BUG_ON() when changing media type
Ondrej Zary wrote: When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning. Signed-off-by: Ondrej Zary <[EMAIL PROTECTED]> --- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25 18:27:34.0 +0100 +++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c2008-02-25 18:34:56.0 +0100 @@ -910,7 +910,8 @@ unsigned media = de->media_type; u32 macmode = dr32(MacMode); - BUG_ON(de_is_running(de)); + if (de_is_running(de)) + printk(KERN_WARNING "%s: chip is running while changing media!\n", de->dev->name); Certainly a sane improvement... -- 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] de2104x: remove BUG_ON() when changing media type
When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning. Signed-off-by: Ondrej Zary <[EMAIL PROTECTED]> --- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25 18:27:34.0 +0100 +++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c2008-02-25 18:34:56.0 +0100 @@ -910,7 +910,8 @@ unsigned media = de->media_type; u32 macmode = dr32(MacMode); - BUG_ON(de_is_running(de)); + if (de_is_running(de)) + printk(KERN_WARNING "%s: chip is running while changing media!\n", de->dev->name); if (de->de21040) dw32(CSR11, FULL_DUPLEX_MAGIC); -- Ondrej Zary -- 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] ethtool netlink interface
Thomas Graf wrote: Hello, Before I continue to finish this work I'd like to get a few comments on my implementation attempt. The following patch implements the ETHTOOL_SSET and ETHTOOL_GSET command via netlink. The individual commands are implemented as separate functions and hooked into a table holding a validate, set and fill function for each command. Additionaly an entry must be made in the attribute policy to validate attributes when received. Each ethtool command bundle is stored as a nested attribute in the regular link netlink message, therefore, unlike the ioctl interface, multiple ethtool commands can be issued in the same message allowing for links to be fully configured with a single message. There is one big disadvantage: Due to the nature of ioctl it is basically not possible to share any code between the ioctl and neltink implementation therefore it implies duplicating code unless we want to do the same hack as fib fronted by constructing netlink messages inside the kernel. No objections, and it certainly makes sense that you would need a separate "thunking" layer to unwrap ethtool-nl msgs rather than handling an ioctl. However, I would think it inconsistent to only do SSET/GSET. If others are OK with this patch, are you open to implementing the full set of ethtool operations? Jeff -- 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: New sparse warning in net/mac80211/debugfs_sta.c
> > Maybe we should just add a new printf modifier like %M for MAC > > addresses? Then we could use sprintf, snprintf, printk and whatever we > > please without any of the macro stuff... > > Could gcc validate the printf %M arguments? No, but it won't barf on it either, it silently ignores unknown stuff. > Another possibility without changing printf argument validation > is to use a MAC_FMT macro in place of "%s" > > #ifdef CONFIG_INLINE_MAC Yes, but the argument was that in some debugging cases these things are in the fast path even when debugging is turned off, so to not have them there would force you to always turn this config ON which defeats the point. johannes signature.asc Description: This is a digitally signed message part
Re: New sparse warning in net/mac80211/debugfs_sta.c
On Mon, 2008-02-25 at 10:53 +0100, Johannes Berg wrote:
> On Sat, 2008-02-23 at 20:02 -0800, David Miller wrote:
> > From: Patrick McHardy <[EMAIL PROTECTED]>
> > Date: Thu, 21 Feb 2008 19:00:03 +0100
> >
> > > And adds back the overhead of two completely unnecessary
> > > function calls to the VLAN fastpath. How about just
> > > stopping this idiocy and reverting the appropriate patches
> > > to bring back MAC_FMT and use it where appropriate?
> >
> > Agreed, I'll do that.
>
> Maybe we should just add a new printf modifier like %M for MAC
> addresses? Then we could use sprintf, snprintf, printk and whatever we
> please without any of the macro stuff...
I have something like this in mind. Might even be faster than using the
MAC_FMT/MAC_ARG stuff because it's done in a single loop rather than
invoking the hex digit printing 6 times.
From: Johannes Berg <[EMAIL PROTECTED]>
Subject: MAC printing with %M/%m
We've been through two ways to print MAC addresses to the kernel
logs/buffers/whatever.
Until recently, we had
#define MAC_FMT "%.2x:%.2x:%.2x:..."
#define MAC_ARG(m) (m)[0], (m)[1], (m)[2], ...
printk("bla bla " MAC_FMT "\n", MAC_ARG(mac));
This is fairly ugly and was found to lead to quite long strings
embedded in the kernel, all the %.2x stuff.
Recently, we changed to using print_mac():
DECLARE_MAC_BUF(mbuf);
printk("bla bla %s\n", print_mac(mbuf, mac));
This was, however, found to force the compiler to emit print_mac()
function calls in fast paths even when debugging was turned off.
Here's my take on it, putting it right into the vsnprintf code.
It allows you to write
printk("bla bla %m\n", mac);
without any further function calls or local variables.
The only problem I see with using 'm' and 'M' is that 'm' is already
defined by glibc to print strerror(errno).
This patch doesn't contain any conversion yet but that could happen
gradually, starting with the fast paths.
I've tested this code in userspace with a number of MAC addresses
and various output buffer limits.
Field length specifiers are allowed and treated as if the already
printed MAC address was given to a %s specifier, ie.
%-20m is like %-20s
etc.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
lib/vsprintf.c | 47 ++-
1 file changed, 42 insertions(+), 5 deletions(-)
--- everything.orig/lib/vsprintf.c 2008-02-25 17:31:56.0 +0100
+++ everything/lib/vsprintf.c 2008-02-25 17:57:34.0 +0100
@@ -366,11 +366,11 @@ static noinline char* put_dec(char *buf,
#define SMALL 32 /* Must be 32 == 0x20 */
#define SPECIAL64 /* 0x */
+/* we are called with base 8, 10 or 16, only, thus don't need "G..." */
+static const char hexdigits[16] = "0123456789ABCDEF"; /*
"GHIJKLMNOPQRSTUVWXYZ"; */
+
static char *number(char *buf, char *end, unsigned long long num, int base,
int size, int precision, int type)
{
- /* we are called with base 8, 10 or 16, only, thus don't need "G..." */
- static const char digits[16] = "0123456789ABCDEF"; /*
"GHIJKLMNOPQRSTUVWXYZ"; */
-
char tmp[66];
char sign;
char locase;
@@ -408,7 +408,7 @@ static char *number(char *buf, char *end
tmp[i++] = '0';
/* Generic code, for any base:
else do {
- tmp[i++] = (digits[do_div(num,base)] | locase);
+ tmp[i++] = (hexdigits[do_div(num,base)] | locase);
} while (num != 0);
*/
else if (base != 10) { /* 8 or 16 */
@@ -416,7 +416,7 @@ static char *number(char *buf, char *end
int shift = 3;
if (base == 16) shift = 4;
do {
- tmp[i++] = (digits[((unsigned char)num) & mask] |
locase);
+ tmp[i++] = (hexdigits[((unsigned char)num) & mask] |
locase);
num >>= shift;
} while (num);
} else { /* base 10 */
@@ -621,6 +621,43 @@ int vsnprintf(char *buf, size_t size, co
}
continue;
+
+ case 'm':
+ flags |= SMALL;
+ case 'M':
+ s = va_arg(args, unsigned char *);
+ len = 17;
+
+ if (!(flags & LEFT)) {
+ while (len < field_width--) {
+ if (str < end)
+ *str = ' ';
+ ++str;
+ }
+ }
+ for (i = 0; i < len; i++) {
+ if (str < end) {
+ if ((i % 3) == 0)
+ *str =
hexdi
Re: New sparse warning in net/mac80211/debugfs_sta.c
On Mon, 2008-02-25 at 10:53 +0100, Johannes Berg wrote: > Maybe we should just add a new printf modifier like %M for MAC > addresses? Then we could use sprintf, snprintf, printk and whatever we > please without any of the macro stuff... Could gcc validate the printf %M arguments? Another possibility without changing printf argument validation is to use a MAC_FMT macro in place of "%s" #ifdef CONFIG_INLINE_MAC #define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x" #define DECLARE_MAC_BUF(var) #define print_mac(buf, addr) (addr)[0], (addr)[1], (addr)[2], (addr)[3], (addr)[4], (addr)[5] #else #define MAC_FMT "%s" #define DECLARE_MAC_BUF(var) char var[18]; extern char *print_mac(char *buf, const unsigned char *addr); #endif use: DECLARE_MAC_BUF(mac); printk(KERN_INFO "Mac address is: " MAC_FMT "\n", print_mac(mac, addr)); -- 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] llc: dont trust payload size on test cmd
Hi In testing its not safe to trust the payload length we are given in a received llc test command header. Instead we should calculate this ourselves or run the risk of an skb_over_panic() if the received length in the header is > then the actual payload size. Signed-off-by: Jim Westfall <[EMAIL PROTECTED]> diff -urp linux-2.6.24.2.org/include/net/llc_pdu.h linux-2.6.24.2/include/net/llc_pdu.h --- linux-2.6.24.2.org/include/net/llc_pdu.h2008-02-10 21:51:11.0 -0800 +++ linux-2.6.24.2/include/net/llc_pdu.h2008-02-24 10:23:02.0 -0800 @@ -348,7 +348,7 @@ static inline void llc_pdu_init_as_test_ struct llc_pdu_un *ev_pdu = llc_pdu_un_hdr(ev_skb); int dsize; - dsize = ntohs(eth_hdr(ev_skb)->h_proto) - 3; + dsize = (ev_skb->tail - (u8 *)ev_pdu) - 3; memcpy(((u8 *)pdu) + 3, ((u8 *)ev_pdu) + 3, dsize); skb_put(skb, dsize); } - End forwarded message - -- 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] tg3: ethtool phys_id default (rev2)
> > Doesn't this mean that ethtool -p will hold the RTNL lock forever? > > Is this a good idea? > > > > For example on the Red Hat machine I have here if you do: > > > > ethtool -p eth2 10 & > > reboot > > > > Various things the shutdown scripts try to do will fail because of the > > held RTNL lock. in the end the script dies and the machine does not > > reboot. > > 1. ethtool -p is only used by root to identify interfaces, so in practice >this is not a real problem. > > 2. ethtool -p is interruptible, and the reboot process sends a SIGTERM to >all processes. The simple use-case of running ethtool -p eth0 1 on an ssh console and them going to the rack and pressing the power button fails. It seems like the shutdown script dies a long way before it usually kills all the processes. Bringing down NFS, SNMP and several other services fails. Then things die for being blocked more then 120 seconds and the system is stuck. -- 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] tg3: ethtool phys_id default (rev2)
On Sun, 24 Feb 2008 07:42:06 +0200 "Eliezer Tamir" <[EMAIL PROTECTED]> wrote: > > On Sat, 2008-02-23 at 19:52 -0800, David Miller wrote: > > From: "Michael Chan" <[EMAIL PROTECTED]> > > Date: Fri, 22 Feb 2008 11:16:42 -0800 > > > > > On Fri, 2008-02-22 at 10:24 -0800, Stephen Hemminger wrote: > > > > When asked to blink LEDs the tg3 driver behaves when using: > > > > ethtool -p ethX > > > > The default value for data is zero, and other drivers interpret this > > > > as blink forever (or at least a really long time). The tg3 driver > > > > interprets this as blink once. All drivers should have the same > > > > behaviour. > ... > > > We should do this across the board for bnx2, bnx2x, and niu as well. > > > > Agreed. > > Doesn't this mean that ethtool -p will hold the RTNL lock forever? > Is this a good idea? > > For example on the Red Hat machine I have here if you do: > > ethtool -p eth2 10 & > reboot > > Various things the shutdown scripts try to do will fail because of the > held RTNL lock. in the end the script dies and the machine does not > reboot. 1. ethtool -p is only used by root to identify interfaces, so in practice this is not a real problem. 2. ethtool -p is interruptible, and the reboot process sends a SIGTERM to all processes. -- 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: printk_ratelimit and net_ratelimit conflict and tunable behavior
Joe Perches wrote:
>
> On Wed, 2008-02-20 at 22:32 -0800, David Miller wrote:
> > > + if (lost) {
> > > + printk(KERN_WARNING
> > > +"printk: %d %s%smessage%s suppressed.\n",
> > > +lost,
> > > +(state->facility == 0 ? "" :
> > > state->facility),
> > > +(state->facility == 0 ? "" : " "),
> > > +(lost > 1 ? "s" : ""));
> > > + }
> > > return 1;
> > > }
>
> This compares a pointer to 0.
>
> How about something like:
>
> if (lost)
> pr_warn("printk: %s suppressed message count: %d\n",
> state->facility ? : "ratelimit", lost);
>
> > > - missed++;
> > > + state->missed++;
> > > spin_unlock_irqrestore(&ratelimit_lock, flags);
> > > return 0;
> > > }
> > > @@ -1280,8 +1290,18 @@ int printk_ratelimit_burst = 10;
> > >
> > > int printk_ratelimit(void)
> > > {
> > > + static struct printk_ratelimit_state limit_state = {
> > > + .toks = 10 * 5 * HZ,
> > > + .last_jiffies = 0,
> > > + .missed= 0,
> > > + .limit_jiffies = 5 * HZ,
> > > + .limit_burst = 10,
> > > + .facility = 0
> > > + };
> > > +
>
> .facility = NULL
How about this?
Signed-off-by: Steve Hawkes <[EMAIL PROTECTED]>
diff -uprN linux-2.6.24/include/linux/kernel.h
linux-2.6.24-printk_ratelimit/include/linux/kernel.h
--- linux-2.6.24/include/linux/kernel.h 2008-01-24 16:58:37.0
-0600
+++ linux-2.6.24-printk_ratelimit/include/linux/kernel.h
2008-02-21 11:20:41.751197312 -0600
@@ -196,8 +196,19 @@ static inline int log_buf_copy(char *des
unsigned long int_sqrt(unsigned long);
+struct printk_ratelimit_state
+{
+ unsigned long toks;
+ unsigned long last_jiffies;
+ int missed;
+ int limit_jiffies;
+ int limit_burst;
+ char const *facility;
+};
+
extern int printk_ratelimit(void);
-extern int __printk_ratelimit(int ratelimit_jiffies, int
ratelimit_burst);
+extern int __printk_ratelimit(int ratelimit_jiffies, int
ratelimit_burst,
+ struct printk_ratelimit_state *state);
extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
unsigned int interval_msec);
diff -uprN linux-2.6.24/kernel/printk.c
linux-2.6.24-printk_ratelimit/kernel/printk.c
--- linux-2.6.24/kernel/printk.c2008-01-24 16:58:37.0
-0600
+++ linux-2.6.24-printk_ratelimit/kernel/printk.c 2008-02-21
11:22:27.442319625 -0600
@@ -1238,35 +1238,41 @@ void tty_write_message(struct tty_struct
/*
* printk rate limiting, lifted from the networking subsystem.
*
- * This enforces a rate limit: not more than one kernel message
- * every printk_ratelimit_jiffies to make a denial-of-service
- * attack impossible.
+ * This enforces a rate limit to mitigate denial-of-service attacks:
+ * not more than ratelimit_burst messages every ratelimit_jiffies.
*/
-int __printk_ratelimit(int ratelimit_jiffies, int ratelimit_burst)
+int __printk_ratelimit(int ratelimit_jiffies,
+ int ratelimit_burst,
+ struct printk_ratelimit_state *state)
{
static DEFINE_SPINLOCK(ratelimit_lock);
- static unsigned long toks = 10 * 5 * HZ;
- static unsigned long last_msg;
- static int missed;
unsigned long flags;
unsigned long now = jiffies;
spin_lock_irqsave(&ratelimit_lock, flags);
- toks += now - last_msg;
- last_msg = now;
- if (toks > (ratelimit_burst * ratelimit_jiffies))
- toks = ratelimit_burst * ratelimit_jiffies;
- if (toks >= ratelimit_jiffies) {
- int lost = missed;
-
- missed = 0;
- toks -= ratelimit_jiffies;
+ state->toks += now - state->last_jiffies;
+ /* Reset limiting if tunables changed */
+ if ((state->limit_jiffies != ratelimit_jiffies) ||
+ (state->limit_burst != ratelimit_burst)) {
+ state->toks = ratelimit_burst * ratelimit_jiffies;
+ state->limit_jiffies = ratelimit_jiffies;
+ state->limit_burst = ratelimit_burst;
+ }
+ state->last_jiffies = now;
+ if (state->toks > (ratelimit_burst * ratelimit_jiffies))
+ state->toks = ratelimit_burst * ratelimit_jiffies;
+ if (state->toks >= ratelimit_jiffies) {
+ int lost = state->missed;
+ state->missed = 0;
+ state->toks -= ratelimit_jiffies;
spin_unlock_irqrestore(&ratelimit_lock, flags);
- if (lost)
- printk(KERN_WARNING "printk: %d messages
suppressed.\n", lost);
+ if (lost) {
+ pr_warning("%s ratelimit suppressed message
count: %d\n",
+ state->facility, lost);
+ }
return 1;
[MACVLAN]: Update Kconfig to refer to iproute
[MACVLAN]: Update Kconfig to refer to iproute Since the macvlan release I had at least 5 users asking how to configure it since the old userspace tool doesn't work with the version in the kernel. Add a pointer to the Kconfig help. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f337800..f333c11 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -90,6 +90,11 @@ config MACVLAN This allows one to create virtual interfaces that map packets to or from specific MAC addresses to a particular interface. + Macvlan devices can be added using the "ip" command from the + iproute2 package starting with the iproute2-2.6.23 release: + + "ip link add link [ address MAC ] [ NAME ] type macvlan" + To compile this driver as a module, choose M here: the module will be called macvlan.
Re: [PATCH] llc: fix skb size for test responses
Em Sun, Feb 24, 2008 at 09:04:21PM -0800, Jim Westfall escreveu: > David Miller <[EMAIL PROTECTED]> wrote [02.24.08]: > > From: Jim Westfall <[EMAIL PROTECTED]> > > Date: Sun, 24 Feb 2008 11:07:58 -0800 > > > > > Hi > > > > > > The llc test command is used for a layer2 ping and contains a variable > > > length payload that we must include in the response. Use the size of the > > > received skb as the size of the skb we must allocate to hold the payload. > > > > > > This resolved an skb_over_panic(), when trying to copy the payload into > > > what was a hard coded skb of size 128. > > > > > > Signed-off-by: Jim Westfall <[EMAIL PROTECTED]> > > > > Arnaldo, please review Jim's patch, thanks! > > Our of curiosity did you all get my 2nd patch? > > Subject: [PATCH] llc: dont trust payload size on test cmd > > I sent it a few minutes after this one, but seems like it never made it > to the list. My local smtp shows it was delivered sucussfully to > vger.kernel.org. I got it, but you made a mistake on the To: address: From: Jim Westfall <[EMAIL PROTECTED]> Subject: [PATCH] llc: dont trust payload size on test cmd To: "To:netdev"@vger.kernel.org, [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
On Mon, Feb 25, 2008 at 01:39:48PM +, Jarek Poplawski wrote: ... > Maybe, it's better to > analyze yet if it's really so hard to eliminate taking this lock > on the xmit path? BTW, I'm not sure if it helps, but this matters only for the sockets which could be used (and locked) outside of pppol2tp code (so before pppol2tp code is called). 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][PPPOL2TP]: Fix SMP oops in pppol2tp driver
On Mon, Feb 25, 2008 at 01:05:08PM +, Jarek Poplawski wrote: ... > On Mon, Feb 25, 2008 at 12:19:50PM +, James Chapman wrote: > > Is this an acceptable solution? If so, I'll prepare and send official > > patches. > > IMHO this should be acceptable because I can't see any reason for > changing properly working code if there is so simple and not costly > solution. But maybe David or somebody else finds some cons? [...] Hmm... Wait a minute! But on the other hand David has written about his cons here, and it looks reasonable: this place would be fixed, but some others can start reports like this. Maybe, it's better to analyze yet if it's really so hard to eliminate taking this lock on the xmit path? 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] nf_conntrack: less hairy ifdefs around proc and sysctl
Alexey Dobriyan wrote: Patch splits creation of /proc/net/nf_conntrack, /proc/net/stat/nf_conntrack and net.netfilter hierarchy into their own functions with dummy ones if PROC_FS or SYSCTL is not set. Also, remove dead "ret = 0" write while I'm at it. Queued for 2.6.26, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] ethtool netlink interface
Hello,
Before I continue to finish this work I'd like to get a few comments
on my implementation attempt.
The following patch implements the ETHTOOL_SSET and ETHTOOL_GSET
command via netlink. The individual commands are implemented as
separate functions and hooked into a table holding a validate,
set and fill function for each command. Additionaly an entry must
be made in the attribute policy to validate attributes when received.
Each ethtool command bundle is stored as a nested attribute in
the regular link netlink message, therefore, unlike the ioctl
interface, multiple ethtool commands can be issued in the same
message allowing for links to be fully configured with a single
message.
There is one big disadvantage: Due to the nature of ioctl it is
basically not possible to share any code between the ioctl and
neltink implementation therefore it implies duplicating code
unless we want to do the same hack as fib fronted by constructing
netlink messages inside the kernel.
Index: net-2.6.26/include/linux/if_link.h
===
--- net-2.6.26.orig/include/linux/if_link.h 2008-02-22 14:13:22.0
+0100
+++ net-2.6.26/include/linux/if_link.h 2008-02-22 14:40:24.0 +0100
@@ -79,6 +79,7 @@
IFLA_LINKINFO,
#define IFLA_LINKINFO IFLA_LINKINFO
IFLA_NET_NS_PID,
+ IFLA_ETHTOOL,
__IFLA_MAX
};
Index: net-2.6.26/net/core/ethtool.c
===
--- net-2.6.26.orig/net/core/ethtool.c 2008-02-22 14:13:22.0 +0100
+++ net-2.6.26/net/core/ethtool.c 2008-02-25 13:51:23.0 +0100
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
/*
* Some useful ethtool_ops methods that're device independent.
@@ -977,6 +978,136 @@
return rc;
}
+static int validate_settings(struct net_device *dev, struct nlattr *attr)
+{
+ if (!dev->ethtool_ops->get_settings)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
+static int set_settings(struct net_device *dev, struct nlattr *attr)
+{
+ return dev->ethtool_ops->set_settings(dev, nla_data(attr));
+}
+
+static int fill_settings(struct sk_buff *skb, struct net_device *dev)
+{
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+ struct ethtool_cmd cmd = { ETHTOOL_GSET };
+ int err;
+
+ if (!ops->get_settings)
+ return 0;
+
+ if ((err = ops->get_settings(dev, &cmd)) < 0)
+ return err;
+
+ return nla_put(skb, IFLA_ET_SETTINGS, sizeof(cmd), &cmd);
+}
+
+static struct {
+ int (*validate)(struct net_device *, struct nlattr *);
+ int (*exec)(struct net_device *, struct nlattr *);
+ int (*fill)(struct sk_buff *, struct net_device *);
+} nlops[IFLA_ET_MAX+1] = {
+ [IFLA_ET_SETTINGS] = { .validate = validate_settings,
+ .exec = set_settings,
+ .fill = fill_settings, },
+};
+
+static const struct nla_policy ethtool_policy[IFLA_ET_MAX+1] = {
+ [IFLA_ET_SETTINGS] = { .len = sizeof(struct ethtool_cmd) },
+};
+
+int ethtool_validate_nlattr(struct net_device *dev, struct nlattr *cfg)
+{
+ const struct ethtool_ops *ops;
+ struct nlattr *attr;
+ int err, remaining = 0;
+
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ if (!netif_device_present(dev))
+ return -ENODEV;
+
+ if (!(ops = dev->ethtool_ops))
+ return -EOPNOTSUPP;
+
+ if ((err = nla_validate_nested(cfg, IFLA_ET_MAX, ethtool_policy)) < 0)
+ goto errout;
+
+ nla_for_each_nested(attr, cfg, remaining) {
+ if (nlops[attr->nla_type].validate) {
+ err = nlops[attr->nla_type].validate(dev, attr);
+ if (err < 0)
+ goto errout;
+ }
+ }
+
+errout:
+ return err;
+}
+
+int ethtool_execute_nlattr(struct net_device *dev, struct nlattr *et_attr)
+{
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+ struct nlattr *attr;
+ unsigned long old_features;
+ int err, remaining = 0;
+
+ if (ops->begin && (err = ops->begin(dev)) < 0)
+ return err;
+
+ old_features = dev->features;
+
+ nla_for_each_nested(attr, et_attr, remaining) {
+ if (nlops[attr->nla_type].exec) {
+ if ((err = nlops[attr->nla_type].exec(dev, attr)) < 0)
+ goto errout;
+ }
+ }
+
+ err = 0;
+errout:
+ if (ops->complete)
+ ops->complete(dev);
+
+ if (old_features != dev->features)
+ netdev_features_change(dev);
+
+ return err;
+}
+
+int ethtool_fill_nlattr(struct sk_buff *skb, struct net_device *dev)
+{
+ struct nlattr *attr;
+ int nfilled = 0, i, err = -EMSGSIZE;
+
+ if (!(attr = nla_nest_start(sk
Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
On Mon, Feb 25, 2008 at 12:19:50PM +, James Chapman wrote:
> Jarek Poplawski wrote:
>> Jarek Poplawski wrote, On 02/21/2008 01:08 PM:
>> ...
>>
>>> Another, probably simpler way would be to move almost all pppol2tp_xmit
>> ...
>>
>> Actually, the simplest off all seems to be now this old idea to maybe make
>> sk_dst_lock globally softirq immune. At least I think it's worth of testing,
>> to check for these other possible lockdep warnings. It should only need to
>> change all write_ and read_lock(&sk->sk_dst_lock) in very few places:
>> include/net/sock.h, include/net/ip6_route.h, and net/ipv6/ipv6_sockglue.c.
>> This could be tested together with you full _bh locking patch (maybe except
>> these other changes in pppol2tp_xmit).
>
> I did this and all lockdep errors have now gone. Tests ran all weekend.
> See attached patch.
>
> Is this an acceptable solution? If so, I'll prepare and send official
> patches.
IMHO this should be acceptable because I can't see any reason for
changing properly working code if there is so simple and not costly
solution. But maybe David or somebody else finds some cons? Since
this patch isn't very big I think you could try to send this
officially and we will simply see...
Regards,
Jarek P.
>
>
> --
> James Chapman
> Katalix Systems Ltd
> http://www.katalix.com
> Catalysts for your Embedded Linux software development
>
> Index: linux-2.6.24.2/include/net/ip6_route.h
> ===
> --- linux-2.6.24.2.orig/include/net/ip6_route.h
> +++ linux-2.6.24.2/include/net/ip6_route.h
> @@ -150,9 +150,9 @@ static inline void __ip6_dst_store(struc
> static inline void ip6_dst_store(struct sock *sk, struct dst_entry *dst,
>struct in6_addr *daddr, struct in6_addr *saddr)
> {
> - write_lock(&sk->sk_dst_lock);
> + write_lock_bh(&sk->sk_dst_lock);
> __ip6_dst_store(sk, dst, daddr, saddr);
> - write_unlock(&sk->sk_dst_lock);
> + write_unlock_bh(&sk->sk_dst_lock);
> }
>
> static inline int ipv6_unicast_destination(struct sk_buff *skb)
> Index: linux-2.6.24.2/include/net/sock.h
> ===
> --- linux-2.6.24.2.orig/include/net/sock.h
> +++ linux-2.6.24.2/include/net/sock.h
> @@ -1058,11 +1058,11 @@ sk_dst_get(struct sock *sk)
> {
> struct dst_entry *dst;
>
> - read_lock(&sk->sk_dst_lock);
> + read_lock_bh(&sk->sk_dst_lock);
> dst = sk->sk_dst_cache;
> if (dst)
> dst_hold(dst);
> - read_unlock(&sk->sk_dst_lock);
> + read_unlock_bh(&sk->sk_dst_lock);
> return dst;
> }
>
> @@ -1079,9 +1079,9 @@ __sk_dst_set(struct sock *sk, struct dst
> static inline void
> sk_dst_set(struct sock *sk, struct dst_entry *dst)
> {
> - write_lock(&sk->sk_dst_lock);
> + write_lock_bh(&sk->sk_dst_lock);
> __sk_dst_set(sk, dst);
> - write_unlock(&sk->sk_dst_lock);
> + write_unlock_bh(&sk->sk_dst_lock);
> }
>
> static inline void
> @@ -1097,9 +1097,9 @@ __sk_dst_reset(struct sock *sk)
> static inline void
> sk_dst_reset(struct sock *sk)
> {
> - write_lock(&sk->sk_dst_lock);
> + write_lock_bh(&sk->sk_dst_lock);
> __sk_dst_reset(sk);
> - write_unlock(&sk->sk_dst_lock);
> + write_unlock_bh(&sk->sk_dst_lock);
> }
>
> extern struct dst_entry *__sk_dst_check(struct sock *sk, u32 cookie);
> Index: linux-2.6.24.2/net/ipv6/ipv6_sockglue.c
> ===
> --- linux-2.6.24.2.orig/net/ipv6/ipv6_sockglue.c
> +++ linux-2.6.24.2/net/ipv6/ipv6_sockglue.c
> @@ -440,9 +440,9 @@ static int do_ipv6_setsockopt(struct soc
> opt = xchg(&np->opt, opt);
> sk_dst_reset(sk);
> } else {
> - write_lock(&sk->sk_dst_lock);
> + write_lock_bh(&sk->sk_dst_lock);
> opt = xchg(&np->opt, opt);
> - write_unlock(&sk->sk_dst_lock);
> + write_unlock_bh(&sk->sk_dst_lock);
> sk_dst_reset(sk);
> }
> sticky_done:
> @@ -504,9 +504,9 @@ update:
> opt = xchg(&np->opt, opt);
> sk_dst_reset(sk);
> } else {
> - write_lock(&sk->sk_dst_lock);
> + write_lock_bh(&sk->sk_dst_lock);
> opt = xchg(&np->opt, opt);
> - write_unlock(&sk->sk_dst_lock);
> + write_unlock_bh(&sk->sk_dst_lock);
> sk_dst_reset(sk);
> }
>
--
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: [NETFILTER]: Introduce nf_inet_address
On Mon, 2008-02-25 at 13:23 +0100, Patrick McHardy wrote: > David Woodhouse wrote: > > On Mon, 2008-02-25 at 13:20 +0100, Patrick McHardy wrote: > >> Right, I missed that. In that case the current headers should match > >> the kernel headers (with the compiler.h part removed). > > > > They don't. When you run 'make headers_install' there are some missing. > > > We don't need all of them, but I'll do a proper resync. Thanks. I think we need some of them -- when I just dropped the results of 'make headers_install' into the iptables build directory, it complained of a number of them being missing (which I showed a few days ago). Ideally, the contents of the include/linux/ directory in the iptables tree would be identical to what you get in usr/include/linux/netfilter* after running 'make headers_install'. -- dwmw2 -- 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: [NETFILTER]: Introduce nf_inet_address
David Woodhouse wrote: On Mon, 2008-02-25 at 13:20 +0100, Patrick McHardy wrote: Right, I missed that. In that case the current headers should match the kernel headers (with the compiler.h part removed). They don't. When you run 'make headers_install' there are some missing. We don't need all of them, but I'll do a proper resync. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETFILTER]: Introduce nf_inet_address
David Woodhouse wrote: On Mon, 2008-02-25 at 13:12 +0100, Patrick McHardy wrote: Yes, the kernel headers need to be fixed as well to not include linux/compiler.h outside of #ifdef __KERNEL__. I'll take care of that. No. When you run 'make headers_install' that's already taken care of. Right, I missed that. In that case the current headers should match the kernel headers (with the compiler.h part removed). -- 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: [NETFILTER]: Introduce nf_inet_address
On Mon, 2008-02-25 at 13:20 +0100, Patrick McHardy wrote: > > Right, I missed that. In that case the current headers should match > the kernel headers (with the compiler.h part removed). They don't. When you run 'make headers_install' there are some missing. -- dwmw2 -- 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][PPPOL2TP]: Fix SMP oops in pppol2tp driver
Jarek Poplawski wrote:
Jarek Poplawski wrote, On 02/21/2008 01:08 PM:
...
Another, probably simpler way would be to move almost all pppol2tp_xmit
...
Actually, the simplest off all seems to be now this old idea to maybe make
sk_dst_lock globally softirq immune. At least I think it's worth of testing,
to check for these other possible lockdep warnings. It should only need to
change all write_ and read_lock(&sk->sk_dst_lock) in very few places:
include/net/sock.h, include/net/ip6_route.h, and net/ipv6/ipv6_sockglue.c.
This could be tested together with you full _bh locking patch (maybe except
these other changes in pppol2tp_xmit).
I did this and all lockdep errors have now gone. Tests ran all weekend.
See attached patch.
Is this an acceptable solution? If so, I'll prepare and send official
patches.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
Index: linux-2.6.24.2/include/net/ip6_route.h
===
--- linux-2.6.24.2.orig/include/net/ip6_route.h
+++ linux-2.6.24.2/include/net/ip6_route.h
@@ -150,9 +150,9 @@ static inline void __ip6_dst_store(struc
static inline void ip6_dst_store(struct sock *sk, struct dst_entry *dst,
struct in6_addr *daddr, struct in6_addr *saddr)
{
- write_lock(&sk->sk_dst_lock);
+ write_lock_bh(&sk->sk_dst_lock);
__ip6_dst_store(sk, dst, daddr, saddr);
- write_unlock(&sk->sk_dst_lock);
+ write_unlock_bh(&sk->sk_dst_lock);
}
static inline int ipv6_unicast_destination(struct sk_buff *skb)
Index: linux-2.6.24.2/include/net/sock.h
===
--- linux-2.6.24.2.orig/include/net/sock.h
+++ linux-2.6.24.2/include/net/sock.h
@@ -1058,11 +1058,11 @@ sk_dst_get(struct sock *sk)
{
struct dst_entry *dst;
- read_lock(&sk->sk_dst_lock);
+ read_lock_bh(&sk->sk_dst_lock);
dst = sk->sk_dst_cache;
if (dst)
dst_hold(dst);
- read_unlock(&sk->sk_dst_lock);
+ read_unlock_bh(&sk->sk_dst_lock);
return dst;
}
@@ -1079,9 +1079,9 @@ __sk_dst_set(struct sock *sk, struct dst
static inline void
sk_dst_set(struct sock *sk, struct dst_entry *dst)
{
- write_lock(&sk->sk_dst_lock);
+ write_lock_bh(&sk->sk_dst_lock);
__sk_dst_set(sk, dst);
- write_unlock(&sk->sk_dst_lock);
+ write_unlock_bh(&sk->sk_dst_lock);
}
static inline void
@@ -1097,9 +1097,9 @@ __sk_dst_reset(struct sock *sk)
static inline void
sk_dst_reset(struct sock *sk)
{
- write_lock(&sk->sk_dst_lock);
+ write_lock_bh(&sk->sk_dst_lock);
__sk_dst_reset(sk);
- write_unlock(&sk->sk_dst_lock);
+ write_unlock_bh(&sk->sk_dst_lock);
}
extern struct dst_entry *__sk_dst_check(struct sock *sk, u32 cookie);
Index: linux-2.6.24.2/net/ipv6/ipv6_sockglue.c
===
--- linux-2.6.24.2.orig/net/ipv6/ipv6_sockglue.c
+++ linux-2.6.24.2/net/ipv6/ipv6_sockglue.c
@@ -440,9 +440,9 @@ static int do_ipv6_setsockopt(struct soc
opt = xchg(&np->opt, opt);
sk_dst_reset(sk);
} else {
- write_lock(&sk->sk_dst_lock);
+ write_lock_bh(&sk->sk_dst_lock);
opt = xchg(&np->opt, opt);
- write_unlock(&sk->sk_dst_lock);
+ write_unlock_bh(&sk->sk_dst_lock);
sk_dst_reset(sk);
}
sticky_done:
@@ -504,9 +504,9 @@ update:
opt = xchg(&np->opt, opt);
sk_dst_reset(sk);
} else {
- write_lock(&sk->sk_dst_lock);
+ write_lock_bh(&sk->sk_dst_lock);
opt = xchg(&np->opt, opt);
- write_unlock(&sk->sk_dst_lock);
+ write_unlock_bh(&sk->sk_dst_lock);
sk_dst_reset(sk);
}
Re: [NETFILTER]: Introduce nf_inet_address
On Mon, 2008-02-25 at 13:12 +0100, Patrick McHardy wrote: > > Yes, the kernel headers need to be fixed as well to not include > linux/compiler.h outside of #ifdef __KERNEL__. I'll take care > of that. No. When you run 'make headers_install' that's already taken care of. -- dwmw2 -- 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: [NETFILTER]: Introduce nf_inet_address
David Woodhouse wrote: On Fri, 2008-02-22 at 16:44 +0100, Patrick McHardy wrote: Pablo Neira Ayuso wrote: Patrick McHardy wrote: Yes, that was a bug in the lastest release. We need to release a 1.4.1 version or something like that, but I'm not too familiar with the release process, so I haven't done this so far. I can schedule one for this weekend, just send me an ACK. That would be great. I think we had another issue in 1.4.0 with some header files, but I can't remeber the details. If you are going to include header files in the release (which makes a certain amount of sense), it would be best if those are simply the result of the kernel's 'make headers_install', without any manual changes. Yes, the kernel headers need to be fixed as well to not include linux/compiler.h outside of #ifdef __KERNEL__. I'll take care of that. -- 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: [Bluez-devel] forcing SCO connection patch
Dave Young 쓴 글:
> On Mon, Feb 25, 2008 at 5:28 PM, Louis JANG <[EMAIL PROTECTED]> wrote:
>
>> > I ever asked marcel about the coding style. please see following thread:
>> > http://lkml.org/lkml/2008/1/22/91
>> >
>> > I think the style problem marcel said is
>> > 1. using kernel codeing style
>> > 2. marcel's style
>> > container_of or get_user_data calls at the top of the variable declaration
>> > using the empty lines to seperate code blocks
>> >
>> > Please rework your patch and resend if you fixed them.
>> >
>> > BTW, please use the new bluetooth mailing list for kerne issue.
>> > [EMAIL PROTECTED]
>> >
>> > (Thanks for andrew and davem)
>> >
>> > Regards
>> > dave
>> >
>> > Regards
>> > dave
>> >
>> >
>>
>> Hi all,
>>
>> I adjusted indentation of the patches
>>
>
> Not enough.
>
> Please first read Documentation/CodingStyle, fix them, and
> then use scripts/checkpatch.pl to check your patch.
>
I fixed all of errors except 80 characters warning.
Thanks
Louis JANG
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25 17:17:11.0
+0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25 17:30:23.0
+0900
@@ -1313,8 +1313,17 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ if (ev->link_type != ACL_LINK) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ?
SCO_LINK : ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type,
&ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ }
+ if (!conn)
+ goto unlock;
+ }
if (!ev->status) {
conn->handle = __le16_to_cpu(ev->handle);
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
diff -uNr linux-2.6.23/include/net/bluetooth-orig/sco.h
linux-2.6.23/include/net/bluetooth/sco.h
--- linux-2.6.23/include/net/bluetooth-orig/sco.h 2007-10-10
05:31:38.0 +0900
+++ linux-2.6.23/include/net/bluetooth/sco.h2008-02-25 18:04:20.0
+0900
@@ -51,6 +51,8 @@
__u8 dev_class[3];
};
+#define SCO_FORCESCO 0x03
+
/* SCO connections */
struct sco_conn {
struct hci_conn *hcon;
@@ -74,6 +76,7 @@
struct bt_sock bt;
__u32 flags;
struct sco_conn *conn;
+ unsigned intforce_sco :1;
};
#endif /* __SCO_H */
diff -uNr linux-2.6.23/net/bluetooth-orig/hci_conn.c
linux-2.6.23/net/bluetooth/hci_conn.c
--- linux-2.6.23/net/bluetooth-orig/hci_conn.c 2008-02-25 17:58:27.0
+0900
+++ linux-2.6.23/net/bluetooth/hci_conn.c 2008-02-25 18:02:04.0
+0900
@@ -354,7 +354,7 @@
if (acl->state == BT_CONNECTED &&
(sco->state == BT_OPEN || sco->state == BT_CLOSED)) {
- if (lmp_esco_capable(hdev))
+ if (type == ESCO_LINK)
hci_setup_sync(sco, acl->handle);
else
hci_add_sco(sco, acl->handle);
diff -uNr linux-2.6.23/net/bluetooth-orig/sco.c linux-2.6.23/net/bluetooth/sco.c
--- linux-2.6.23/net/bluetooth-orig/sco.c 2008-02-25 17:58:27.0
+0900
+++ linux-2.6.23/net/bluetooth/sco.c2008-02-25 18:08:51.0 +0900
@@ -200,7 +200,10 @@
err = -ENOMEM;
- type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
+ if (sco_pi(sk)->force_sco)
+ type = SCO_LINK;
+ else
+ type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
hcon = hci_connect(hdev, type, dst);
if (!hcon)
@@ -660,12 +663,21 @@
{
struct sock *sk = sock->sk;
int err = 0;
+ int force_sco;
BT_DBG("sk %p", sk);
lock_sock(sk);
switch (optname) {
+ case SCO_FORCESCO:
+ if (copy_from_user(&force_sco, optval, sizeof(int))) {
+ err = -EFAULT;
+ break;
+ }
+ sco_pi(sk)->force_sco = (force_sco != 0);
+ break;
+
default:
err = -ENOPROTOOPT;
break;
@@ -681,6 +693,7 @@
struct sco_options opts;
struct sco_conninfo cinfo;
int len, err = 0;
+ int force_sco;
BT_DBG("sk %p", sk);
@@ -721,6 +734,13 @@
break;
+ case SCO_FORCESCO:
+ force_sco = sco_pi(sock)->force_sco;
+ if (copy_to_user(optval, &force_sco, sizeof(int)))
+ err = -EFAULT;
+
+ break;
+
default:
err = -ENOPROTOOPT;
break;
Re: New sparse warning in net/mac80211/debugfs_sta.c
David Miller wrote: From: Patrick McHardy <[EMAIL PROTECTED]> Date: Thu, 21 Feb 2008 19:00:03 +0100 And adds back the overhead of two completely unnecessary function calls to the VLAN fastpath. How about just stopping this idiocy and reverting the appropriate patches to bring back MAC_FMT and use it where appropriate? Agreed, I'll do that. It would be good if Joe could go through the remaining print_mac users and convert the remaining unintended function calls in fastpaths back to MAC_FMT. Grepping for "start_xmit" in commit 0795af5729b shows that at least 10 hard_start_xmit functions are affected and I expect that some of the changes in the wireless code affect fastpaths as well. -- 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: [BUG][AX25] spinlock lockup
Applied. Thanks!
Regards,
Jann
> -Ursprüngliche Nachricht-
> Von: Jarek Poplawski [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 24. Februar 2008 20:51
> An: Jann Traschewski
> Cc: netdev@vger.kernel.org; 'Ralf Baechle'
> Betreff: Re: [BUG][AX25] spinlock lockup
>
> On Sun, Feb 24, 2008 at 04:10:29AM +0100, Jann Traschewski wrote:
> > Hello,
>
> Hi!
>
> > I got a "spinlock lockup" using the latest Kernel 2.6.24.2
> with recent
> > patches from Jarek Poplawski applied.
> ...
> > ppp_deflate nf_nat zlib_deflateBUG: unable to handle kernel NULL
> > pointer dereference zlib_inflate nf_conntrack_ipv4 bsd_comp slhc
> > ppp_async xt_state
> ...
> > EIP is at skb_append+0x1b/0x30
> ...
> > 0010 BUG: spinlock lockup on CPU#1, bcm/12213, f40846b8
>
> Looks like 2 in 1: NULL pointer dereference and (later?) lockup.
>
> There is only one function in AX25 calling skb_append(), and
> it really looks suspicious: appends skb after previously
> enqueued one, but in the meantime this previous skb could be
> removed from the queue.
>
> Here is a patch for testing: it fixes this simple way, so
> this is not fully compatible with the current method, but
> let's check if this could be a problem?
>
> Regards,
> Jarek P.
>
> (testing patch #1)
>
> ---
>
> net/ax25/ax25_subr.c | 11 +++
> 1 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/net/ax25/ax25_subr.c b/net/ax25/ax25_subr.c
> index d8f2157..034aa10 100644
> --- a/net/ax25/ax25_subr.c
> +++ b/net/ax25/ax25_subr.c
> @@ -64,20 +64,15 @@ void ax25_frames_acked(ax25_cb *ax25,
> unsigned short nr)
>
> void ax25_requeue_frames(ax25_cb *ax25) {
> - struct sk_buff *skb, *skb_prev = NULL;
> + struct sk_buff *skb;
>
> /*
>* Requeue all the un-ack-ed frames on the output queue
> to be picked
>* up by ax25_kick called from the timer. This
> arrangement handles the
>* possibility of an empty output queue.
>*/
> - while ((skb = skb_dequeue(&ax25->ack_queue)) != NULL) {
> - if (skb_prev == NULL)
> - skb_queue_head(&ax25->write_queue, skb);
> - else
> - skb_append(skb_prev, skb, &ax25->write_queue);
> - skb_prev = skb;
> - }
> + while ((skb = skb_dequeue_tail(&ax25->ack_queue)) != NULL)
> + skb_queue_head(&ax25->write_queue, skb);
> }
>
> /*
--
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] [PS3] gelic wireless driver needs MAC80211 support
On Mon, 2008-02-25 at 12:16 +0100, Sebastian Siewior wrote: > * Johannes Berg | 2008-02-25 11:13:56 [+0100]: > > >That seems completely wrong since it's a full-mac "chip" (implemented in > >the HV or so maybe). What exactly does it need from mac80211? > Nothing, please drop. I've sent another patch which enables WEXT what is > the correct thing to do. Sorry for the noise. No problem. I saw it later on netdev but had read linux-wireless first :) johannes signature.asc Description: This is a digitally signed message part
Re: circular locking, mirred, 2.6.24.2
On Mon, Feb 25, 2008 at 12:48:38PM +0200, Denys Fedoryshchenko wrote: > What does it mean early? > I have custom boot scripts, it is also custom system based on busybox. There > is a chance that i forgot to bring ifb0 up, but thats it. > I think such warning must not appear on any actions in userspace. It's not about ifb0: this report shows loopback_init after some action on eth, so eth was probably up before lo. And of course you are right: this warning shouldn't be there. But, since this report looks very strange, I wonder if there could be something else that mislead lockdep. Could you try to reproduce this with 2.6.24.2 without these additional patches? 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] [PS3] gelic wireless driver needs MAC80211 support
* Johannes Berg | 2008-02-25 11:13:56 [+0100]: >That seems completely wrong since it's a full-mac "chip" (implemented in >the HV or so maybe). What exactly does it need from mac80211? Nothing, please drop. I've sent another patch which enables WEXT what is the correct thing to do. Sorry for the noise. >johannes Sebastian -- 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: circular locking, mirred, 2.6.24.2
What does it mean early?
I have custom boot scripts, it is also custom system based on busybox. There
is a chance that i forgot to bring ifb0 up, but thats it.
I think such warning must not appear on any actions in userspace.
On Mon, 25 Feb 2008 09:56:46 +, Jarek Poplawski wrote
> On 24-02-2008 23:20, Denys Fedoryshchenko wrote:
> > 2.6.24.2 with applied patches for printk,softlockup, and patch for htb
(as i
> > understand, they are in 2.6.25 git and it is fixes).
> >
> > I will send also to private mails QoS rules i am using.
> >
> > [ 118.840072] ===
> > [ 118.840158] [ INFO: possible circular locking dependency detected ]
> > [ 118.840203] 2.6.24.2-build-0022 #7
> > [ 118.840243] ---
> > [ 118.840288] swapper/0 is trying to acquire lock:
> > [ 118.840329] (&dev->queue_lock){-+..}, at: [] dev_queue_xmit
> > +0x177/0x302
> > [ 118.840490]
> > [ 118.840490] but task is already holding lock:
> > [ 118.840567] (&p->tcfc_lock){-+..}, at: [] tcf_mirred
+0x20/0x180
> > [act_mirred]
> > [ 118.840727]
> > [ 118.840727] which lock already depends on the new lock.
> > [ 118.840728]
> > [ 118.840842]
> > [ 118.840842] the existing dependency chain (in reverse order) is:
> > [ 118.840921]
> > [ 118.840921] -> #2 (&p->tcfc_lock){-+..}:
> > [ 118.841075][] __lock_acquire+0xa30/0xc19
> > [ 118.841324][] lock_acquire+0x7a/0x94
> > [ 118.841572][] _spin_lock+0x2e/0x58
> > [ 118.841820][] tcf_mirred+0x20/0x180 [act_mirred]
> > [ 118.842068][] tcf_action_exec+0x44/0x77
> > [ 118.842344][] u32_classify+0x119/0x24a [cls_u32]
> > [ 118.842595][] tc_classify_compat+0x2f/0x5e
> > [ 118.842845][] tc_classify+0x1a/0x80
> > [ 118.843092][] ingress_enqueue+0x1a/0x53 [sch_ingress]
> > [ 118.843343][] netif_receive_skb+0x296/0x44c
> > [ 118.843592][] e100_poll+0x14b/0x26a [e100]
> > [ 118.843843][] net_rx_action+0xbf/0x201
> > [ 118.844091][] __do_softirq+0x6f/0xe9
> > [ 118.844343][] do_softirq+0x61/0xc8
> > [ 118.844591][] 0x
> > [ 118.844840]
> > [ 118.844840] -> #1 (&dev->ingress_lock){-+..}:
> > [ 118.844993][] __lock_acquire+0xa30/0xc19
> > [ 118.845242][] lock_acquire+0x7a/0x94
> > [ 118.845489][] _spin_lock+0x2e/0x58
> > [ 118.845737][] qdisc_lock_tree+0x1e/0x21
> > [ 118.845984][] dev_init_scheduler+0xb/0x53
> > [ 118.846235][] register_netdevice+0x2a3/0x2fd
> > [ 118.846483][] register_netdev+0x32/0x3f
> > [ 118.846730][] loopback_net_init+0x39/0x6c
> > [ 118.846980][] register_pernet_operations+0x13/0x15
> > [ 118.847230][] register_pernet_device+0x1f/0x4c
> > [ 118.847478][] loopback_init+0xd/0xf
> > [ 118.847725][] kernel_init+0x155/0x2c6
>
> This looks strange: are you sure your tc scripts aren't started too
> early? (Or maybe there are some problems during booting?)
>
> Regards,
> Jarek P.
>
> > [ 118.847973][] kernel_thread_helper+0x7/0x10
> > [ 118.848225][] 0x
> > [ 118.848472]
> > [ 118.848472] -> #0 (&dev->queue_lock){-+..}:
> > [ 118.848626][] __lock_acquire+0x920/0xc19
> > [ 118.848874][] lock_acquire+0x7a/0x94
> > [ 118.849122][] _spin_lock+0x2e/0x58
> > [ 118.849370][] dev_queue_xmit+0x177/0x302
> > [ 118.849617][] tcf_mirred+0x15f/0x180 [act_mirred]
> > [ 118.849866][] tcf_action_exec+0x44/0x77
> > [ 118.850114][] u32_classify+0x119/0x24a [cls_u32]
> > [ 118.850366][] tc_classify_compat+0x2f/0x5e
> > [ 118.850614][] tc_classify+0x1a/0x80
> > [ 118.850861][] ingress_enqueue+0x1a/0x53 [sch_ingress]
> > [ 118.85][] netif_receive_skb+0x296/0x44c
> > [ 118.851360][] e100_poll+0x14b/0x26a [e100]
> > [ 118.851612][] net_rx_action+0xbf/0x201
> > [ 118.851859][] __do_softirq+0x6f/0xe9
> > [ 118.852106][] do_softirq+0x61/0xc8
> > [ 118.852355][] 0x
>
> --
> 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
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
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: lockdep trace from rc2.
On Sun, 2008-02-24 at 21:22 -0500, Dave Jones wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=431038 has some more info,
> but the trace is below...
> I'll get an rc3 kernel built and ask the user to retest, but in case this
> isn't a known problem, I'm forwarding this here.
I can't fix it but I can explain it.
> Feb 24 17:53:21 cirithungol kernel: ip/10650 is trying to acquire lock:
> Feb 24 17:53:21 cirithungol kernel: (events){--..}, at: []
> flush_workqueue+0x0/0x85
> Feb 24 17:53:21 cirithungol kernel:
> Feb 24 17:53:21 cirithungol kernel: but task is already holding lock:
> Feb 24 17:53:21 cirithungol kernel: (rtnl_mutex){--..}, at: []
> rtnetlink_rcv+0x12/0x26
> Feb 24 17:53:21 cirithungol kernel:
> Feb 24 17:53:21 cirithungol kernel: which lock already depends on the new
> lock.
What's happening here is that the linkwatch_work runs on the generic
schedule_work() workqueue.
> Feb 24 17:53:21 cirithungol kernel: -> #1 ((linkwatch_work).work){--..}:
The function that is called is linkwatch_event(), which acquires the
RTNL as you can see here:
> Feb 24 17:53:21 cirithungol kernel: -> #2 (rtnl_mutex){--..}:
> Feb 24 17:53:21 cirithungol kernel:[]
> __lock_acquire+0xa7c/0xbf4
> Feb 24 17:53:21 cirithungol kernel:[] rtnl_lock+0xf/0x11
> Feb 24 17:53:21 cirithungol kernel:[]
> tick_program_event+0x31/0x55
> Feb 24 17:53:21 cirithungol kernel:[] lock_acquire+0x6a/0x90
> Feb 24 17:53:21 cirithungol kernel:[] rtnl_lock+0xf/0x11
> Feb 24 17:53:21 cirithungol kernel:[]
> mutex_lock_nested+0xdb/0x271
> Feb 24 17:53:21 cirithungol kernel:[] rtnl_lock+0xf/0x11
> Feb 24 17:53:21 cirithungol kernel:last message repeated 2 times
> Feb 24 17:53:21 cirithungol kernel:[]
> linkwatch_event+0x8/0x22
The problem with that is that tulip_down() calls flush_scheduled_work()
while holding the RTNL:
> Feb 24 17:53:21 cirithungol kernel:[]
> flush_workqueue+0x0/0x85
> Feb 24 17:53:21 cirithungol kernel:[]
> flush_scheduled_work+0xd/0xf
> Feb 24 17:53:21 cirithungol kernel:[] tulip_down+0x20/0x1a3
> [tulip]
[...]
> Feb 24 17:53:21 cirithungol kernel:[]
> rtnetlink_rcv+0x1e/0x26
(rtnetlink_rcv will acquire the RTNL)
The deadlock that can now happen is that linkwatch_work is scheduled on
the workqueue but not running yet. During tulip_down(),
flush_scheduled_work() is called which will wait for everything that is
scheduled to complete. Among those things could be linkwatch_event()
which will start running and try to acquire the RTNL. Because that is
already locked it will wait for the RTNL, but on the other hand we're
waiting for linkwatch_event() to finish while holding the RTNL.
The fix here would most likely be to not use flush_scheduled_work() but
rather cancel_work_sync().
This should be a correct change afaict, unless tulip has more work
structs than the media work.
@@ tulip_down
- flush_scheduled_work();
+ cancel_work_sync(&tp->media_work);
johannes
signature.asc
Description: This is a digitally signed message part
[PATCH resend 2.6.25 11/12][BNX2X]: update version
[BNX2X]: update version Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]> --- drivers/net/bnx2x.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c index 2db0427..6db4805 100644 --- a/drivers/net/bnx2x.c +++ b/drivers/net/bnx2x.c @@ -63,8 +63,8 @@ #include "bnx2x.h" #include "bnx2x_init.h" -#define DRV_MODULE_VERSION "0.40.15" -#define DRV_MODULE_RELDATE "$DateTime: 2007/11/15 07:28:37 $" +#define DRV_MODULE_VERSION "1.40.22" +#define DRV_MODULE_RELDATE "$DateTime: 2008/02/23 20:21:47 $" #define BNX2X_BC_VER 0x040200 /* Time in jiffies before concluding the transmitter is hung. */ -- 1.5.3.2 -- 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 resend 2.6.25 7/12][BNX2X]: HW attention and error handling
[BNX2X]: HW attention and error handling - many fixes, sometimes improperly
acked HW attentions could cause lockup.
Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/bnx2x.c | 229 +--
1 files changed, 150 insertions(+), 79 deletions(-)
diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c
index 6f987fa..b99e3b7 100644
--- a/drivers/net/bnx2x.c
+++ b/drivers/net/bnx2x.c
@@ -4089,8 +4089,8 @@ static void bnx2x_attn_int_asserted(struct bnx2x *bp, u32
asserted)
u32 igu_addr = (IGU_ADDR_ATTN_BITS_SET + IGU_PORT_BASE * port) * 8;
u32 aeu_addr = port ? MISC_REG_AEU_MASK_ATTN_FUNC_1 :
MISC_REG_AEU_MASK_ATTN_FUNC_0;
- u32 nig_mask_addr = port ? NIG_REG_MASK_INTERRUPT_PORT1 :
- NIG_REG_MASK_INTERRUPT_PORT0;
+ u32 nig_int_mask_addr = port ? NIG_REG_MASK_INTERRUPT_PORT1 :
+ NIG_REG_MASK_INTERRUPT_PORT0;
if (~bp->aeu_mask & (asserted & 0xff))
BNX2X_ERR("IGU ERROR\n");
@@ -4108,15 +4108,11 @@ static void bnx2x_attn_int_asserted(struct bnx2x *bp,
u32 asserted)
if (asserted & ATTN_HARD_WIRED_MASK) {
if (asserted & ATTN_NIG_FOR_FUNC) {
- u32 nig_status_port;
- u32 nig_int_addr = port ?
- NIG_REG_STATUS_INTERRUPT_PORT1 :
- NIG_REG_STATUS_INTERRUPT_PORT0;
- bp->nig_mask = REG_RD(bp, nig_mask_addr);
- REG_WR(bp, nig_mask_addr, 0);
+ /* save nig interrupt mask */
+ bp->nig_mask = REG_RD(bp, nig_int_mask_addr);
+ REG_WR(bp, nig_int_mask_addr, 0);
- nig_status_port = REG_RD(bp, nig_int_addr);
bnx2x_link_update(bp);
/* handle unicore attn? */
@@ -4169,15 +4165,132 @@ static void bnx2x_attn_int_asserted(struct bnx2x *bp,
u32 asserted)
/* now set back the mask */
if (asserted & ATTN_NIG_FOR_FUNC)
- REG_WR(bp, nig_mask_addr, bp->nig_mask);
+ REG_WR(bp, nig_int_mask_addr, bp->nig_mask);
}
-static void bnx2x_attn_int_deasserted(struct bnx2x *bp, u32 deasserted)
+static inline void bnx2x_attn_int_deasserted0(struct bnx2x *bp, u32 attn)
{
int port = bp->port;
- int index;
+ int reg_offset;
+ u32 val;
+
+ if (attn & AEU_INPUTS_ATTN_BITS_SPIO5) {
+
+ reg_offset = (port ? MISC_REG_AEU_ENABLE1_FUNC_1_OUT_0 :
+MISC_REG_AEU_ENABLE1_FUNC_0_OUT_0);
+
+ val = REG_RD(bp, reg_offset);
+ val &= ~AEU_INPUTS_ATTN_BITS_SPIO5;
+ REG_WR(bp, reg_offset, val);
+
+ BNX2X_ERR("SPIO5 hw attention\n");
+
+ switch (bp->board & SHARED_HW_CFG_BOARD_TYPE_MASK) {
+ case SHARED_HW_CFG_BOARD_TYPE_BCM957710A1022G:
+ /* Fan failure attention */
+
+ /* The PHY reset is controled by GPIO 1 */
+ bnx2x_set_gpio(bp, MISC_REGISTERS_GPIO_1,
+ MISC_REGISTERS_GPIO_OUTPUT_LOW);
+ /* Low power mode is controled by GPIO 2 */
+ bnx2x_set_gpio(bp, MISC_REGISTERS_GPIO_2,
+ MISC_REGISTERS_GPIO_OUTPUT_LOW);
+ /* mark the failure */
+ bp->ext_phy_config &=
+ ~PORT_HW_CFG_XGXS_EXT_PHY_TYPE_MASK;
+ bp->ext_phy_config |=
+ PORT_HW_CFG_XGXS_EXT_PHY_TYPE_FAILURE;
+ SHMEM_WR(bp,
+dev_info.port_hw_config[port].
+ external_phy_config,
+bp->ext_phy_config);
+ /* log the failure */
+ printk(KERN_ERR PFX "Fan Failure on Network"
+ " Controller %s has caused the driver to"
+ " shutdown the card to prevent permanent"
+ " damage. Please contact Dell Support for"
+ " assistance\n", bp->dev->name);
+ break;
+
+ default:
+ break;
+ }
+ }
+}
+
+static inline void bnx2x_attn_int_deasserted1(struct bnx2x *bp, u32 attn)
+{
+ u32 val;
+
+ if (attn & BNX2X_DOORQ_ASSERT) {
+
+ val = REG_RD(bp, DORQ_REG_DORQ_INT_STS_CLR);
+ BNX2X_ERR("DB hw attention 0x%x\n", val);
+ /* DORQ discard attention */
+ if (val & 0x2)
+ BNX2X_ERR("FATAL error from DORQ\n");
+ }
+}
+
+sta
[PATCH resend 2.6.25 5/12][BNX2X]: fix stats
[BNX2X]: fix stats - rx errors were summed improperly, some were missing
Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/bnx2x.c | 164 +--
drivers/net/bnx2x.h |4 +-
2 files changed, 83 insertions(+), 85 deletions(-)
diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c
index 103d3e0..a35feee 100644
--- a/drivers/net/bnx2x.c
+++ b/drivers/net/bnx2x.c
@@ -4972,39 +4972,37 @@ static void bnx2x_update_net_stats(struct bnx2x *bp)
nstats->rx_bytes = bnx2x_hilo(&estats->total_bytes_received_hi);
- nstats->tx_bytes =
- bnx2x_hilo(&estats->total_bytes_transmitted_hi);
+ nstats->tx_bytes = bnx2x_hilo(&estats->total_bytes_transmitted_hi);
- nstats->rx_dropped = estats->checksum_discard +
- estats->mac_discard;
+ nstats->rx_dropped = estats->checksum_discard + estats->mac_discard;
nstats->tx_dropped = 0;
nstats->multicast =
bnx2x_hilo(&estats->total_multicast_packets_transmitted_hi);
- nstats->collisions =
- estats->single_collision_transmit_frames +
- estats->multiple_collision_transmit_frames +
- estats->late_collision_frames +
- estats->excessive_collision_frames;
+ nstats->collisions = estats->single_collision_transmit_frames +
+estats->multiple_collision_transmit_frames +
+estats->late_collision_frames +
+estats->excessive_collision_frames;
nstats->rx_length_errors = estats->runt_packets_received +
estats->jabber_packets_received;
- nstats->rx_over_errors = estats->no_buff_discard;
+ nstats->rx_over_errors = estats->brb_discard +
+estats->brb_truncate_discard;
nstats->rx_crc_errors = estats->crc_receive_errors;
nstats->rx_frame_errors = estats->alignment_errors;
- nstats->rx_fifo_errors = estats->brb_discard +
- estats->brb_truncate_discard;
+ nstats->rx_fifo_errors = estats->no_buff_discard;
nstats->rx_missed_errors = estats->xxoverflow_discard;
nstats->rx_errors = nstats->rx_length_errors +
nstats->rx_over_errors +
nstats->rx_crc_errors +
nstats->rx_frame_errors +
- nstats->rx_fifo_errors;
+ nstats->rx_fifo_errors +
+ nstats->rx_missed_errors;
nstats->tx_aborted_errors = estats->late_collision_frames +
- estats->excessive_collision_frames;
+ estats->excessive_collision_frames;
nstats->tx_carrier_errors = estats->false_carrier_detections;
nstats->tx_fifo_errors = 0;
nstats->tx_heartbeat_errors = 0;
@@ -8755,81 +8753,87 @@ static void bnx2x_self_test(struct net_device *dev,
static struct {
char string[ETH_GSTRING_LEN];
} bnx2x_stats_str_arr[BNX2X_NUM_STATS] = {
- { "rx_bytes"}, /* 0 */
- { "rx_error_bytes"}, /* 1 */
- { "tx_bytes"}, /* 2 */
- { "tx_error_bytes"}, /* 3 */
- { "rx_ucast_packets"}, /* 4 */
- { "rx_mcast_packets"}, /* 5 */
- { "rx_bcast_packets"}, /* 6 */
- { "tx_ucast_packets"}, /* 7 */
- { "tx_mcast_packets"}, /* 8 */
- { "tx_bcast_packets"}, /* 9 */
- { "tx_mac_errors"}, /* 10 */
- { "tx_carrier_errors"}, /* 11 */
- { "rx_crc_errors"}, /* 12 */
- { "rx_align_errors"},/* 13 */
- { "tx_single_collisions"}, /* 14 */
- { "tx_multi_collisions"},/* 15 */
- { "tx_deferred"},/* 16 */
- { "tx_excess_collisions"}, /* 17 */
- { "tx_late_collisions"}, /* 18 */
- { "tx_total_collisions"},/* 19 */
- { "rx_fragments"}, /* 20 */
- { "rx_jabbers"}, /* 21 */
- { "rx_undersize_packets"}, /* 22 */
- { "rx_oversize_packets"},/* 23 */
- { "rx_xon_frames"}, /* 24 */
- { "rx_xoff_frames"}, /* 25 */
- { "tx_xon_frames"}, /* 26 */
- { "tx_xoff_frames"}, /* 27 */
- { "rx_mac_ctrl_frames"}, /* 28 */
- { "rx_filtered_packets"},/* 29 */
- { "rx_discards"},/* 30 */
+
[PATCH resend 2.6.25 4/12][BNX2X]: correct rx filtering (client-config)
[BNX2X]: correct rx filtering (client-config)
Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/bnx2x.c | 165 ---
drivers/net/bnx2x.h |5 +-
2 files changed, 92 insertions(+), 78 deletions(-)
diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c
index 5cd7850..103d3e0 100644
--- a/drivers/net/bnx2x.c
+++ b/drivers/net/bnx2x.c
@@ -298,8 +298,7 @@ static void bnx2x_read_dmae(struct bnx2x *bp, u32 src_addr,
u32 len32)
static int bnx2x_mc_assert(struct bnx2x *bp)
{
- int i, j;
- int rc = 0;
+ int i, j, rc = 0;
char last_idx;
const char storm[] = {"XTCU"};
const u32 intmem_base[] = {
@@ -313,8 +312,9 @@ static int bnx2x_mc_assert(struct bnx2x *bp)
for (i = 0; i < 4; i++) {
last_idx = REG_RD8(bp, XSTORM_ASSERT_LIST_INDEX_OFFSET +
intmem_base[i]);
- BNX2X_ERR("DATA %cSTORM_ASSERT_LIST_INDEX 0x%x\n",
- storm[i], last_idx);
+ if (last_idx)
+ BNX2X_LOG("DATA %cSTORM_ASSERT_LIST_INDEX 0x%x\n",
+ storm[i], last_idx);
/* print the asserts */
for (j = 0; j < STROM_ASSERT_ARRAY_SIZE; j++) {
@@ -330,7 +330,7 @@ static int bnx2x_mc_assert(struct bnx2x *bp)
intmem_base[i]);
if (row0 != COMMON_ASM_INVALID_ASSERT_OPCODE) {
- BNX2X_ERR("DATA %cSTORM_ASSERT_INDEX 0x%x ="
+ BNX2X_LOG("DATA %cSTORM_ASSERT_INDEX 0x%x ="
" 0x%08x 0x%08x 0x%08x 0x%08x\n",
storm[i], j, row3, row2, row1, row0);
rc++;
@@ -349,21 +349,22 @@ static void bnx2x_fw_dump(struct bnx2x *bp)
int word;
mark = REG_RD(bp, MCP_REG_MCPR_SCRATCH + 0xf104);
- printk(KERN_ERR PFX "begin fw dump (mark 0x%x)\n", mark);
+ mark = ((mark + 0x3) & ~0x3);
+ printk(KERN_ERR PFX "begin fw dump (mark 0x%x)\n" KERN_ERR, mark);
for (offset = mark - 0x0800; offset <= 0xF900; offset += 0x8*4) {
for (word = 0; word < 8; word++)
data[word] = htonl(REG_RD(bp, MCP_REG_MCPR_SCRATCH +
offset + 4*word));
data[8] = 0x0;
- printk(KERN_ERR PFX "%s", (char *)data);
+ printk(KERN_CONT "%s", (char *)data);
}
for (offset = 0xF108; offset <= mark - 0x0800; offset += 0x8*4) {
for (word = 0; word < 8; word++)
data[word] = htonl(REG_RD(bp, MCP_REG_MCPR_SCRATCH +
offset + 4*word));
data[8] = 0x0;
- printk(KERN_ERR PFX "%s", (char *)data);
+ printk(KERN_CONT "%s", (char *)data);
}
printk("\n" KERN_ERR PFX "end of fw dump\n");
}
@@ -428,10 +429,10 @@ static void bnx2x_panic_dump(struct bnx2x *bp)
}
}
- BNX2X_ERR("def_c_idx(%u) def_u_idx(%u) def_t_idx(%u)"
- " def_x_idx(%u) def_att_idx(%u) attn_state(%u)"
+ BNX2X_ERR("def_c_idx(%u) def_u_idx(%u) def_x_idx(%u)"
+ " def_t_idx(%u) def_att_idx(%u) attn_state(%u)"
" spq_prod_idx(%u)\n",
- bp->def_c_idx, bp->def_u_idx, bp->def_t_idx, bp->def_x_idx,
+ bp->def_c_idx, bp->def_u_idx, bp->def_x_idx, bp->def_t_idx,
bp->def_att_idx, bp->attn_state, bp->spq_prod_idx);
@@ -789,20 +790,20 @@ static void bnx2x_sp_event(struct bnx2x_fastpath *fp,
fp->state = BNX2X_FP_STATE_HALTED;
break;
- case (RAMROD_CMD_ID_ETH_PORT_DEL | BNX2X_STATE_CLOSING_WAIT4_DELETE):
- DP(NETIF_MSG_IFDOWN, "got delete ramrod\n");
- bp->state = BNX2X_STATE_CLOSING_WAIT4_UNLOAD;
- break;
-
case (RAMROD_CMD_ID_ETH_CFC_DEL | BNX2X_STATE_CLOSING_WAIT4_HALT):
- DP(NETIF_MSG_IFDOWN, "got delete ramrod for MULTI[%d]\n", cid);
- bnx2x_fp(bp, cid, state) = BNX2X_FP_STATE_DELETED;
+ DP(NETIF_MSG_IFDOWN, "got delete ramrod for MULTI[%d]\n",
+ cid);
+ bnx2x_fp(bp, cid, state) = BNX2X_FP_STATE_CLOSED;
break;
case (RAMROD_CMD_ID_ETH_SET_MAC | BNX2X_STATE_OPEN):
DP(NETIF_MSG_IFUP, "got set mac ramrod\n");
break;
+ case (RAMROD_CMD_ID_ETH_SET_MAC | BNX2X_STATE_CLOSING_WAIT4_HALT):
+ DP(NETIF_MSG_IFUP, "got (un)set mac ramrod\n");
+ break;
+
default:
BNX2X_ERR("unexpected ramrod (%d) state is %x\n",
command, bp->state);
@@ -5236,6 +5237,9 @@ static void bnx2x_init_de
[PATCH resend 2.6.25 0/12][BNX2X] bugfixes
Dave, Here are just the bug fixes out of the previous update. Please apply to 2.6.25 1 Spelling fixes 2 Fix bnx2x_init_one() - was printing wrong PCI-E info, failed to release netdev in one case. 3 Link mgmt and BC bugs - many link cfg fixes The move to boot code 4.2.0 is mandatory since it fixes many bugs in the old ones. All old devices are being upgraded, all the devices that have been manufactured for a while have the new bootcode. (by the time 2.6.25 is out, there should no longer be any devices with pre-4.2.0 bootcode) 4 Correct rx filtering (AKA client-config) 5 Fix stats - rx errors were summed improperly, some were missing. 6 MSI-X / INT#A errata - loading with INT#A after using MSI-X did not work due to a HW bug. 7 HW attention and error handling - many fixes, sometimes improperly acked HW attentions could cause lockup. 8 Fixed slowpath races - fixed up/down racing with timer and fastpath. 9 Tx fixes - fix several bugs in start_xmit (the shiny new rewrite will wait for 2.6.26) 10 Update version 11 Add bnx2x to MAINTAINERS Thanks Eliezer -- 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 resend 2.6.25 2/12][BNX2X]: fix bnx2x_init_one()
[BNX2X]: fix bnx2x_init_one() - was printing wrong PCI-E info, failed to
release netdev in one case.
Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/bnx2x.c | 41 ++---
drivers/net/bnx2x.h |5 +
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c
index 7b2d789..7786716 100644
--- a/drivers/net/bnx2x.c
+++ b/drivers/net/bnx2x.c
@@ -8873,14 +8873,32 @@ err_out:
return rc;
}
+static int __devinit bnx2x_get_pcie_width(struct bnx2x *bp)
+{
+ u32 val = REG_RD(bp, PCICFG_OFFSET + PCICFG_LINK_CONTROL);
+
+ val = (val & PCICFG_LINK_WIDTH) >> PCICFG_LINK_WIDTH_SHIFT;
+ return val;
+}
+
+/* return value of 1=2.5GHz 2=5GHz */
+static int __devinit bnx2x_get_pcie_speed(struct bnx2x *bp)
+{
+ u32 val = REG_RD(bp, PCICFG_OFFSET + PCICFG_LINK_CONTROL);
+
+ val = (val & PCICFG_LINK_SPEED) >> PCICFG_LINK_SPEED_SHIFT;
+ return val;
+}
+
static int __devinit bnx2x_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
static int version_printed;
struct net_device *dev = NULL;
struct bnx2x *bp;
- int rc, i;
+ int rc;
int port = PCI_FUNC(pdev->devfn);
+ DECLARE_MAC_BUF(mac);
if (version_printed++ == 0)
printk(KERN_INFO "%s", version);
@@ -8897,6 +8915,7 @@ static int __devinit bnx2x_init_one(struct pci_dev *pdev,
if (port && onefunc) {
printk(KERN_ERR PFX "second function disabled. exiting\n");
+ free_netdev(dev);
return 0;
}
@@ -8950,22 +8969,14 @@ static int __devinit bnx2x_init_one(struct pci_dev
*pdev,
pci_set_drvdata(pdev, dev);
bp->name = board_info[ent->driver_data].name;
- printk(KERN_INFO "%s: %s (%c%d) PCI%s %s %dMHz "
- "found at mem %lx, IRQ %d, ",
- dev->name, bp->name,
+ printk(KERN_INFO "%s: %s (%c%d) PCI-E x%d %s found at mem %lx,"
+ " IRQ %d, ", dev->name, bp->name,
((CHIP_ID(bp) & 0xf000) >> 12) + 'A',
((CHIP_ID(bp) & 0x0ff0) >> 4),
- ((bp->flags & PCIX_FLAG) ? "-X" : ""),
- ((bp->flags & PCI_32BIT_FLAG) ? "32-bit" : "64-bit"),
- bp->bus_speed_mhz,
- dev->base_addr,
- bp->pdev->irq);
-
- printk("node addr ");
- for (i = 0; i < 6; i++)
- printk("%2.2x", dev->dev_addr[i]);
- printk("\n");
-
+ bnx2x_get_pcie_width(bp),
+ (bnx2x_get_pcie_speed(bp) == 2) ? "5GHz (Gen2)" : "2.5GHz",
+ dev->base_addr, bp->pdev->irq);
+ printk(KERN_CONT "node addr %s\n", print_mac(mac, dev->dev_addr));
return 0;
}
diff --git a/drivers/net/bnx2x.h b/drivers/net/bnx2x.h
index 7a01668..ea91008 100644
--- a/drivers/net/bnx2x.h
+++ b/drivers/net/bnx2x.h
@@ -867,6 +867,11 @@ struct bnx2x {
DPM_TRIGER_TYPE); \
} while (0)
+/* PCIE link and speed */
+#define PCICFG_LINK_WIDTH 0x1f0
+#define PCICFG_LINK_WIDTH_SHIFT20
+#define PCICFG_LINK_SPEED 0xf
+#define PCICFG_LINK_SPEED_SHIFT16
/* stuff added to make the code fit 80Col */
--
1.5.3.2
--
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 resend 2.6.25 12/12][BNX2X]: add bnx2x to MAINTAINERS
[BNX2X]: add bnx2x to MAINTAINERS Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]> --- MAINTAINERS |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 36c7bc6..38f5744 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -982,6 +982,12 @@ M: [EMAIL PROTECTED] L: netdev@vger.kernel.org S: Supported +BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER +P: Eliezer Tamir +M: [EMAIL PROTECTED] +L: netdev@vger.kernel.org +S: Supported + BROADCOM TG3 GIGABIT ETHERNET DRIVER P: Michael Chan M: [EMAIL PROTECTED] -- 1.5.3.2 -- 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 resend 2.6.25 8/12][BNX2X]: fixed slowpath races
[BNX2X]: fixed slowpath races - fixed up/down racing with timer and fastpath.
Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/bnx2x.c | 213 ---
drivers/net/bnx2x.h |3 -
2 files changed, 116 insertions(+), 100 deletions(-)
diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c
index b99e3b7..d21599c 100644
--- a/drivers/net/bnx2x.c
+++ b/drivers/net/bnx2x.c
@@ -6881,14 +6881,11 @@ static void bnx2x_free_msix_irqs(struct bnx2x *bp)
"state(%x)\n", i, bp->msix_table[i + 1].vector,
bnx2x_fp(bp, i, state));
- if (bnx2x_fp(bp, i, state) != BNX2X_FP_STATE_CLOSED) {
-
- free_irq(bp->msix_table[i + 1].vector, &bp->fp[i]);
- bnx2x_fp(bp, i, state) = BNX2X_FP_STATE_CLOSED;
-
- } else
- DP(NETIF_MSG_IFDOWN, "irq not freed\n");
+ if (bnx2x_fp(bp, i, state) != BNX2X_FP_STATE_CLOSED)
+ BNX2X_ERR("IRQ of fp #%d being freed while "
+ "state != closed\n", i);
+ free_irq(bp->msix_table[i + 1].vector, &bp->fp[i]);
}
}
@@ -6918,7 +6915,7 @@ static int bnx2x_enable_msix(struct bnx2x *bp)
if (pci_enable_msix(bp->pdev, &bp->msix_table[0],
bp->num_queues + 1)){
- BNX2X_ERR("failed to enable msix\n");
+ BNX2X_LOG("failed to enable MSI-X\n");
return -1;
}
@@ -6935,8 +6932,6 @@ static int bnx2x_req_msix_irqs(struct bnx2x *bp)
int i, rc;
- DP(NETIF_MSG_IFUP, "about to request sp irq\n");
-
rc = request_irq(bp->msix_table[0].vector, bnx2x_msix_sp_int, 0,
bp->dev->name, bp->dev);
@@ -6951,7 +6946,8 @@ static int bnx2x_req_msix_irqs(struct bnx2x *bp)
bp->dev->name, &bp->fp[i]);
if (rc) {
- BNX2X_ERR("request fp #%d irq failed\n", i);
+ BNX2X_ERR("request fp #%d irq failed "
+ "rc %d\n", i, rc);
bnx2x_free_msix_irqs(bp);
return -EBUSY;
}
@@ -7084,12 +7080,13 @@ static int bnx2x_setup_multi(struct bnx2x *bp, int
index)
/* reset IGU state */
bnx2x_ack_sb(bp, index, CSTORM_ID, 0, IGU_INT_ENABLE, 0);
+ /* SETUP ramrod */
bp->fp[index].state = BNX2X_FP_STATE_OPENING;
bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_CLIENT_SETUP, index, 0, index, 0);
/* Wait for completion */
return bnx2x_wait_ramrod(bp, BNX2X_FP_STATE_OPEN, index,
-&(bp->fp[index].state), 1);
+&(bp->fp[index].state), 0);
}
@@ -7099,8 +7096,8 @@ static void bnx2x_set_rx_mode(struct net_device *dev);
static int bnx2x_nic_load(struct bnx2x *bp, int req_irq)
{
- int rc;
- int i = 0;
+ u32 load_code;
+ int i;
bp->state = BNX2X_STATE_OPENING_WAIT4_LOAD;
@@ -7110,12 +7107,17 @@ static int bnx2x_nic_load(struct bnx2x *bp, int req_irq)
initialized, otherwise - not.
*/
if (!nomcp) {
- rc = bnx2x_fw_command(bp, DRV_MSG_CODE_LOAD_REQ);
- if (rc == FW_MSG_CODE_DRV_LOAD_REFUSED) {
+ load_code = bnx2x_fw_command(bp, DRV_MSG_CODE_LOAD_REQ);
+ if (!load_code) {
+ BNX2X_ERR("MCP response failure, unloading\n");
+ return -EBUSY;
+ }
+ if (load_code == FW_MSG_CODE_DRV_LOAD_REFUSED) {
+ BNX2X_ERR("MCP refused load request, unloading\n");
return -EBUSY; /* other port in diagnostic mode */
}
} else {
- rc = FW_MSG_CODE_DRV_LOAD_COMMON;
+ load_code = FW_MSG_CODE_DRV_LOAD_COMMON;
}
/* if we can't use msix we only need one fp,
@@ -7153,13 +7155,13 @@ static int bnx2x_nic_load(struct bnx2x *bp, int req_irq)
if (bp->flags & USING_MSIX_FLAG) {
if (bnx2x_req_msix_irqs(bp)) {
pci_disable_msix(bp->pdev);
- goto out_error;
+ goto load_error;
}
} else {
if (bnx2x_req_irq(bp)) {
BNX2X_ERR("IRQ request failed, aborting\n");
- goto out_error;
+ goto load_error;
}
}
}
@@ -7170,9 +7172,10 @@ static int bnx2x_nic_load(struct bnx2x *bp, int req_irq)
/* Initialize HW */
- if (bnx2x_function_init(bp, (rc == FW_MSG_CODE_DRV_LOAD_COMMON))) {
+ if (bnx2x_function_init(bp,
+ (load_cod
[PATCH resend 2.6.25 10/12][BNX2X]: Tx fixes
[BNX2X]: Tx fixes - fix several bugs in start_xmit
Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/bnx2x.c | 12 +++-
drivers/net/bnx2x.h |3 +++
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c
index d21599c..2db0427 100644
--- a/drivers/net/bnx2x.c
+++ b/drivers/net/bnx2x.c
@@ -9269,7 +9269,7 @@ static int bnx2x_start_xmit(struct sk_buff *skb, struct
net_device *dev)
/* for now NS flag is not used in Linux */
pbd->global_data = (len |
- ((skb->protocol == ETH_P_8021Q) <<
+ ((skb->protocol == ntohs(ETH_P_8021Q)) <<
ETH_TX_PARSE_BD_LLC_SNAP_EN_SHIFT));
pbd->ip_hlen = ip_hdrlen(skb) / 2;
pbd->total_hlen = cpu_to_le16(len + pbd->ip_hlen);
@@ -9278,7 +9278,7 @@ static int bnx2x_start_xmit(struct sk_buff *skb, struct
net_device *dev)
tx_bd->bd_flags.as_bitfield |=
ETH_TX_BD_FLAGS_TCP_CSUM;
- pbd->tcp_flags = htonl(tcp_flag_word(skb)) & 0x;
+ pbd->tcp_flags = pbd_tcp_flags(skb);
pbd->total_hlen += cpu_to_le16(tcp_hdrlen(skb) / 2);
pbd->tcp_pseudo_csum = swab16(th->check);
@@ -9322,7 +9322,7 @@ static int bnx2x_start_xmit(struct sk_buff *skb, struct
net_device *dev)
if (skb_shinfo(skb)->gso_size &&
(skb->len > (bp->dev->mtu + ETH_HLEN))) {
- int hlen = 2 * le32_to_cpu(pbd->total_hlen);
+ int hlen = 2 * le16_to_cpu(pbd->total_hlen);
DP(NETIF_MSG_TX_QUEUED,
"TSO packet len %d hlen %d total len %d tso size %d\n",
@@ -9439,9 +9439,11 @@ static int bnx2x_start_xmit(struct sk_buff *skb, struct
net_device *dev)
DP(NETIF_MSG_TX_QUEUED, "doorbell: nbd %u bd %d\n", nbd, bd_prod);
- fp->hw_tx_prods->bds_prod += cpu_to_le16(nbd);
+ fp->hw_tx_prods->bds_prod =
+ cpu_to_le16(le16_to_cpu(fp->hw_tx_prods->bds_prod) + nbd);
mb(); /* FW restriction: must not reorder writing nbd and packets */
- fp->hw_tx_prods->packets_prod += cpu_to_le32(1);
+ fp->hw_tx_prods->packets_prod =
+ cpu_to_le32(le32_to_cpu(fp->hw_tx_prods->packets_prod) + 1);
DOORBELL(bp, fp_index, 0);
mmiowb();
diff --git a/drivers/net/bnx2x.h b/drivers/net/bnx2x.h
index 6a86afb..4f0c0d3 100644
--- a/drivers/net/bnx2x.h
+++ b/drivers/net/bnx2x.h
@@ -869,6 +869,9 @@ struct bnx2x {
#define PCICFG_LINK_SPEED_SHIFT16
#define BMAC_CONTROL_RX_ENABLE 2
+
+#define pbd_tcp_flags(skb) (ntohl(tcp_flag_word(tcp_hdr(skb)))>>16 & 0xff)
+
/* stuff added to make the code fit 80Col */
#define TPA_TYPE_START ETH_FAST_PATH_RX_CQE_START_FLG
--
1.5.3.2
--
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 resend 2.6.25 9/12][BNX2X]: workaround PCI queue overflow
[BNX2X]: workaround PCI queue overflow - limit traffic through an internal queue to prevent overflow. Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]> --- drivers/net/bnx2x_init.h | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/net/bnx2x_init.h b/drivers/net/bnx2x_init.h index 04f93bf..dcaecc5 100644 --- a/drivers/net/bnx2x_init.h +++ b/drivers/net/bnx2x_init.h @@ -1,6 +1,6 @@ /* bnx2x_init.h: Broadcom Everest network driver. * - * Copyright (c) 2007 Broadcom Corporation + * Copyright (c) 2007-2008 Broadcom Corporation * * 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 @@ -409,7 +409,7 @@ static void bnx2x_init_pxp(struct bnx2x *bp) pci_read_config_word(bp->pdev, bp->pcie_cap + PCI_EXP_DEVCTL, (u16 *)&val); - DP(NETIF_MSG_HW, "read 0x%x from devctl\n", val); + DP(NETIF_MSG_HW, "read 0x%x from devctl\n", (u16)val); w_order = ((val & PCI_EXP_DEVCTL_PAYLOAD) >> 5); r_order = ((val & PCI_EXP_DEVCTL_READRQ) >> 12); @@ -472,10 +472,14 @@ static void bnx2x_init_pxp(struct bnx2x *bp) REG_WR(bp, PXP2_REG_PSWRQ_BW_WR, val); REG_WR(bp, PXP2_REG_RQ_WR_MBS0, w_order); - REG_WR(bp, PXP2_REG_RQ_WR_MBS0 + 8, w_order); + REG_WR(bp, PXP2_REG_RQ_WR_MBS1, w_order); REG_WR(bp, PXP2_REG_RQ_RD_MBS0, r_order); - REG_WR(bp, PXP2_REG_RQ_RD_MBS0 + 8, r_order); + REG_WR(bp, PXP2_REG_RQ_RD_MBS1, r_order); + if (r_order == MAX_RD_ORD) + REG_WR(bp, PXP2_REG_RQ_PDR_LIMIT, 0xe00); + + REG_WR(bp, PXP2_REG_WR_USDMDP_TH, (0x18 << w_order)); REG_WR(bp, PXP2_REG_WR_DMAE_TH, (128 << w_order)/16); } -- 1.5.3.2 -- 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 resend 2.6.25 6/12][BNX2X]: MSI-X / INT#A errata
[BNX2X]: MSI-X / INT#A errata - workaround for a HW bug when moving from MSI-X
to INT#A without a reboot
Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/bnx2x.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c
index a35feee..6f987fa 100644
--- a/drivers/net/bnx2x.c
+++ b/drivers/net/bnx2x.c
@@ -443,7 +443,7 @@ static void bnx2x_panic_dump(struct bnx2x *bp)
DP(BNX2X_MSG_STATS, "stats_state - DISABLE\n");
}
-static void bnx2x_enable_int(struct bnx2x *bp)
+static void bnx2x_int_enable(struct bnx2x *bp)
{
int port = bp->port;
u32 addr = port ? HC_REG_CONFIG_1 : HC_REG_CONFIG_0;
@@ -456,18 +456,26 @@ static void bnx2x_enable_int(struct bnx2x *bp)
HC_CONFIG_0_REG_ATTN_BIT_EN_0);
} else {
val |= (HC_CONFIG_0_REG_SINGLE_ISR_EN_0 |
+ HC_CONFIG_0_REG_MSI_MSIX_INT_EN_0 |
HC_CONFIG_0_REG_INT_LINE_EN_0 |
HC_CONFIG_0_REG_ATTN_BIT_EN_0);
+
+ /* Errata A0.158 workaround */
+ DP(NETIF_MSG_INTR, "write %x to HC %d (addr 0x%x) MSI-X %d\n",
+ val, port, addr, msix);
+
+ REG_WR(bp, addr, val);
+
val &= ~HC_CONFIG_0_REG_MSI_MSIX_INT_EN_0;
}
- DP(NETIF_MSG_INTR, "write %x to HC %d (addr 0x%x) msi %d\n",
+ DP(NETIF_MSG_INTR, "write %x to HC %d (addr 0x%x) MSI-X %d\n",
val, port, addr, msix);
REG_WR(bp, addr, val);
}
-static void bnx2x_disable_int(struct bnx2x *bp)
+static void bnx2x_int_disable(struct bnx2x *bp)
{
int port = bp->port;
u32 addr = port ? HC_REG_CONFIG_1 : HC_REG_CONFIG_0;
@@ -486,7 +494,7 @@ static void bnx2x_disable_int(struct bnx2x *bp)
BNX2X_ERR("BUG! proper val not read from IGU!\n");
}
-static void bnx2x_disable_int_sync(struct bnx2x *bp)
+static void bnx2x_int_disable_sync(struct bnx2x *bp)
{
int msix = (bp->flags & USING_MSIX_FLAG) ? 1 : 0;
@@ -494,7 +502,7 @@ static void bnx2x_disable_int_sync(struct bnx2x *bp)
atomic_inc(&bp->intr_sem);
/* prevent the HW from sending interrupts */
- bnx2x_disable_int(bp);
+ bnx2x_int_disable(bp);
/* make sure all ISRs are done */
if (msix) {
@@ -5710,7 +5718,7 @@ static void bnx2x_nic_init(struct bnx2x *bp)
bnx2x_init_internal(bp);
bnx2x_init_stats(bp);
bnx2x_init_ind_table(bp);
- bnx2x_enable_int(bp);
+ bnx2x_int_enable(bp);
}
@@ -7154,7 +7162,7 @@ stop_netif:
napi_disable(&bnx2x_fp(bp, i, napi));
int_disable:
- bnx2x_disable_int_sync(bp);
+ bnx2x_int_disable_sync(bp);
bnx2x_free_skbs(bp);
bnx2x_free_irq(bp);
@@ -7174,7 +7182,7 @@ static void bnx2x_netif_stop(struct bnx2x *bp)
bp->rx_mode = BNX2X_RX_MODE_NONE;
bnx2x_set_storm_rx_mode(bp);
- bnx2x_disable_int_sync(bp);
+ bnx2x_int_disable_sync(bp);
bnx2x_link_reset(bp);
for_each_queue(bp, i)
--
1.5.3.2
--
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 resend 2.6.25 1/12][BNX2X]: Spelling fixes
[BNX2X]: Spelling fixes
Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/bnx2x.c | 119 +++---
drivers/net/bnx2x.h |2 +-
2 files changed, 56 insertions(+), 65 deletions(-)
diff --git a/drivers/net/bnx2x.c b/drivers/net/bnx2x.c
index afc7f34..7b2d789 100644
--- a/drivers/net/bnx2x.c
+++ b/drivers/net/bnx2x.c
@@ -10,13 +10,13 @@
* Based on code from Michael Chan's bnx2 driver
* UDP CSUM errata workaround by Arik Gendelman
* Slowpath rework by Vladislav Zolotarov
- * Statistics and Link managment by Yitchak Gertner
+ * Statistics and Link management by Yitchak Gertner
*
*/
/* define this to make the driver freeze on error
* to allow getting debug info
- * (you will need to reboot afterwords)
+ * (you will need to reboot afterwards)
*/
/*#define BNX2X_STOP_ON_ERROR*/
@@ -71,7 +71,7 @@
#define TX_TIMEOUT (5*HZ)
static char version[] __devinitdata =
- "Broadcom NetXtreme II 577xx 10Gigabit Ethernet Driver "
+ "Broadcom NetXtreme II 5771X 10Gigabit Ethernet Driver "
DRV_MODULE_NAME " " DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
MODULE_AUTHOR("Eliezer Tamir <[EMAIL PROTECTED]>");
@@ -94,8 +94,8 @@ module_param(debug, int, 0);
MODULE_PARM_DESC(use_inta, "use INT#A instead of MSI-X");
MODULE_PARM_DESC(poll, "use polling (for debug)");
MODULE_PARM_DESC(onefunc, "enable only first function");
-MODULE_PARM_DESC(nomcp, "ignore managment CPU (Implies onefunc)");
-MODULE_PARM_DESC(debug, "defualt debug msglevel");
+MODULE_PARM_DESC(nomcp, "ignore management CPU (Implies onefunc)");
+MODULE_PARM_DESC(debug, "default debug msglevel");
#ifdef BNX2X_MULTI
module_param(use_multi, int, 0);
@@ -341,6 +341,7 @@ static int bnx2x_mc_assert(struct bnx2x *bp)
}
return rc;
}
+
static void bnx2x_fw_dump(struct bnx2x *bp)
{
u32 mark, offset;
@@ -491,7 +492,7 @@ static void bnx2x_disable_int_sync(struct bnx2x *bp)
int i;
atomic_inc(&bp->intr_sem);
- /* prevent the HW from sending interrupts*/
+ /* prevent the HW from sending interrupts */
bnx2x_disable_int(bp);
/* make sure all ISRs are done */
@@ -775,6 +776,7 @@ static void bnx2x_sp_event(struct bnx2x_fastpath *fp,
mb(); /* force bnx2x_wait_ramrod to see the change */
return;
}
+
switch (command | bp->state) {
case (RAMROD_CMD_ID_ETH_PORT_SETUP | BNX2X_STATE_OPENING_WAIT4_PORT):
DP(NETIF_MSG_IFUP, "got setup ramrod\n");
@@ -1471,7 +1473,7 @@ static int bnx2x_mdio45_vwrite(struct bnx2x *bp, u32 reg,
u32 addr, u32 val)
}
/*
- * link managment
+ * link management
*/
static void bnx2x_flow_ctrl_resolve(struct bnx2x *bp, u32 gp_status)
@@ -1482,7 +1484,7 @@ static void bnx2x_flow_ctrl_resolve(struct bnx2x *bp, u32
gp_status)
bp->flow_ctrl = 0;
- /* reolve from gp_status in case of AN complete and not sgmii */
+ /* resolve from gp_status in case of AN complete and not sgmii */
if ((bp->req_autoneg & AUTONEG_FLOW_CTRL) &&
(gp_status & MDIO_AN_CL73_OR_37_COMPLETE) &&
(!(bp->phy_flags & PHY_SGMII_FLAG)) &&
@@ -1680,7 +1682,7 @@ static void bnx2x_link_int_ack(struct bnx2x *bp, int
is_10g)
int port = bp->port;
/* first reset all status
-* we asume only one line will be change at a time */
+* we assume only one line will be change at a time */
bnx2x_bits_dis(bp, NIG_REG_STATUS_INTERRUPT_PORT0 + port*4,
(NIG_XGXS0_LINK_STATUS |
NIG_SERDES0_LINK_STATUS |
@@ -1819,7 +1821,7 @@ static void bnx2x_bmac_enable(struct bnx2x *bp, int is_lb)
u32 wb_write[2];
u32 val;
- DP(NETIF_MSG_LINK, "enableing BigMAC\n");
+ DP(NETIF_MSG_LINK, "enabling BigMAC\n");
/* reset and unreset the BigMac */
REG_WR(bp, GRCBASE_MISC + MISC_REGISTERS_RESET_REG_2_CLEAR,
(MISC_REGISTERS_RESET_REG_2_RST_BMAC0 << port));
@@ -1940,7 +1942,7 @@ static void bnx2x_emac_enable(struct bnx2x *bp)
u32 val;
int timeout;
- DP(NETIF_MSG_LINK, "enableing EMAC\n");
+ DP(NETIF_MSG_LINK, "enabling EMAC\n");
/* reset and unreset the emac core */
REG_WR(bp, GRCBASE_MISC + MISC_REGISTERS_RESET_REG_2_CLEAR,
(MISC_REGISTERS_RESET_REG_2_RST_EMAC0_HARD_CORE << port));
@@ -2033,7 +2035,7 @@ static void bnx2x_emac_enable(struct bnx2x *bp)
EMAC_TX_MODE_EXT_PAUSE_EN);
}
- /* KEEP_VLAN_TAG, promiscous */
+ /* KEEP_VLAN_TAG, promiscuous */
val = REG_RD(bp, emac_base + EMAC_REG_EMAC_RX_MODE);
val |= EMAC_RX_MODE_KEEP_VLAN_TAG | EMAC_RX_MODE_PROMISCUOUS;
EMAC_WR(EMAC_REG_EMAC_RX_MODE, val);
@@ -2161,7 +2163,6 @@ static void bnx2x_pbf_update(struct bnx2x *bp)
u32 count = 1000;
u32 pause = 0;
-
/* dis
[PATCH] IPv6 - Add missing initializations of the new nl_info.nl_net field
Here is an updated version of the patch without the initializations to "zero". Add some more missing initializations of the new nl_info.nl_net field in IPv6 stack. This field will be used when network namespaces are fully supported. Signed-off-by: Benjamin Thery <[EMAIL PROTECTED]> --- net/ipv6/addrconf.c |3 +++ net/ipv6/route.c|2 ++ 2 files changed, 5 insertions(+) Index: net-2.6.26/net/ipv6/addrconf.c === --- net-2.6.26.orig/net/ipv6/addrconf.c +++ net-2.6.26/net/ipv6/addrconf.c @@ -1557,6 +1557,7 @@ addrconf_prefix_route(struct in6_addr *p .fc_expires = expires, .fc_dst_len = plen, .fc_flags = RTF_UP | flags, + .fc_nlinfo.nl_net = &init_net, }; ipv6_addr_copy(&cfg.fc_dst, pfx); @@ -1583,6 +1584,7 @@ static void addrconf_add_mroute(struct n .fc_ifindex = dev->ifindex, .fc_dst_len = 8, .fc_flags = RTF_UP, + .fc_nlinfo.nl_net = &init_net, }; ipv6_addr_set(&cfg.fc_dst, htonl(0xFF00), 0, 0, 0); @@ -1599,6 +1601,7 @@ static void sit_route_add(struct net_dev .fc_ifindex = dev->ifindex, .fc_dst_len = 96, .fc_flags = RTF_UP | RTF_NONEXTHOP, + .fc_nlinfo.nl_net = &init_net, }; /* prefix length - 96 bits "::d.d.d.d" */ Index: net-2.6.26/net/ipv6/route.c === --- net-2.6.26.orig/net/ipv6/route.c +++ net-2.6.26/net/ipv6/route.c @@ -1719,6 +1719,8 @@ static void rtmsg_to_fib6_config(struct cfg->fc_src_len = rtmsg->rtmsg_src_len; cfg->fc_flags = rtmsg->rtmsg_flags; + cfg->fc_nlinfo.nl_net = &init_net; + ipv6_addr_copy(&cfg->fc_dst, &rtmsg->rtmsg_dst); ipv6_addr_copy(&cfg->fc_src, &rtmsg->rtmsg_src); ipv6_addr_copy(&cfg->fc_gateway, &rtmsg->rtmsg_gateway); -- -- 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] [PS3] gelic wireless driver needs MAC80211 support
On Sat, 2008-02-23 at 15:26 -0500, Jeff Garzik wrote: > Sebastian Siewior wrote: > > so select it. > > Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]> > > --- > > drivers/net/Kconfig |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > > index f337800..a116056 100644 > > --- a/drivers/net/Kconfig > > +++ b/drivers/net/Kconfig > > @@ -2363,6 +2363,7 @@ config GELIC_NET > > config GELIC_WIRELESS > > bool "PS3 Wireless support" > > depends on GELIC_NET > > + select MAC80211 That seems completely wrong since it's a full-mac "chip" (implemented in the HV or so maybe). What exactly does it need from mac80211? johannes signature.asc Description: This is a digitally signed message part
Re: New sparse warning in net/mac80211/debugfs_sta.c
On Sat, 2008-02-23 at 20:02 -0800, David Miller wrote: > From: Patrick McHardy <[EMAIL PROTECTED]> > Date: Thu, 21 Feb 2008 19:00:03 +0100 > > > And adds back the overhead of two completely unnecessary > > function calls to the VLAN fastpath. How about just > > stopping this idiocy and reverting the appropriate patches > > to bring back MAC_FMT and use it where appropriate? > > Agreed, I'll do that. Maybe we should just add a new printf modifier like %M for MAC addresses? Then we could use sprintf, snprintf, printk and whatever we please without any of the macro stuff... johannes signature.asc Description: This is a digitally signed message part
Re: [Bluez-devel] forcing SCO connection patch
On Mon, Feb 25, 2008 at 5:28 PM, Louis JANG <[EMAIL PROTECTED]> wrote:
>
> > I ever asked marcel about the coding style. please see following thread:
> > http://lkml.org/lkml/2008/1/22/91
> >
> > I think the style problem marcel said is
> > 1. using kernel codeing style
> > 2. marcel's style
> > container_of or get_user_data calls at the top of the variable declaration
> > using the empty lines to seperate code blocks
> >
> > Please rework your patch and resend if you fixed them.
> >
> > BTW, please use the new bluetooth mailing list for kerne issue.
> > [EMAIL PROTECTED]
> >
> > (Thanks for andrew and davem)
> >
> > Regards
> > dave
> >
> > Regards
> > dave
> >
> >
>
> Hi all,
>
> I adjusted indentation of the patches
Not enough.
Please first read Documentation/CodingStyle, fix them, and
then use scripts/checkpatch.pl to check your patch.
>but I'm not sure what's wrong
> about second comment of Marcel. please let me know if there are another
> problems in this patch.
>
> Thanks in advance,
> Louis JANG
>
>
> --- net/bluetooth/hci_event.c.orig 2008-02-25 17:17:11.0 +0900
> +++ net/bluetooth/hci_event.c 2008-02-25 17:30:23.0 +0900
> @@ -1313,8 +1313,17 @@
> hci_dev_lock(hdev);
>
> conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
> - if (!conn)
> - goto unlock;
> + if (!conn) {
> + if (ev->link_type != ACL_LINK) {
> + __u8 link_type = (ev->link_type == ESCO_LINK) ?
> SCO_LINK : ESCO_LINK;
> +
> + conn = hci_conn_hash_lookup_ba(hdev, link_type,
> &ev->bdaddr);
> + if (conn)
> + conn->type = ev->link_type;
> + }
> + if (!conn)
> + goto unlock;
> + }
>
> if (!ev->status) {
> conn->handle = __le16_to_cpu(ev->handle);
>
> diff -uNr include/net/bluetooth-orig/sco.h include/net/bluetooth/sco.h
> --- include/net/bluetooth-orig/sco.h2007-10-10 05:31:38.0 +0900
> +++ include/net/bluetooth/sco.h 2008-02-25 18:04:20.0 +0900
> @@ -51,6 +51,8 @@
> __u8 dev_class[3];
> };
>
> +#define SCO_FORCESCO 0x03
> +
> /* SCO connections */
> struct sco_conn {
> struct hci_conn *hcon;
> @@ -74,6 +76,7 @@
> struct bt_sock bt;
> __u32 flags;
> struct sco_conn *conn;
> + unsigned intforce_sco :1;
> };
>
> #endif /* __SCO_H */
> diff -uNr net/bluetooth-orig/hci_conn.c net/bluetooth/hci_conn.c
> --- net/bluetooth-orig/hci_conn.c 2008-02-25 17:58:27.0 +0900
> +++ net/bluetooth/hci_conn.c2008-02-25 18:02:04.0 +0900
> @@ -354,7 +354,7 @@
>
> if (acl->state == BT_CONNECTED &&
> (sco->state == BT_OPEN || sco->state == BT_CLOSED)) {
> - if (lmp_esco_capable(hdev))
> + if (type == ESCO_LINK)
> hci_setup_sync(sco, acl->handle);
> else
> hci_add_sco(sco, acl->handle);
> diff -uNr net/bluetooth-orig/sco.c net/bluetooth/sco.c
> --- net/bluetooth-orig/sco.c2008-02-25 17:58:27.0 +0900
> +++ net/bluetooth/sco.c 2008-02-25 18:08:51.0 +0900
> @@ -200,7 +200,10 @@
>
> err = -ENOMEM;
>
> - type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
> + if (sco_pi(sk)->force_sco)
> + type = SCO_LINK;
> + else
> + type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
>
> hcon = hci_connect(hdev, type, dst);
> if (!hcon)
> @@ -660,12 +663,21 @@
> {
> struct sock *sk = sock->sk;
> int err = 0;
> + unsigned int force_sco;
>
> BT_DBG("sk %p", sk);
>
> lock_sock(sk);
>
> switch (optname) {
> + case SCO_FORCESCO:
> + if (copy_from_user((char *)&force_sco, optval,
> sizeof(unsigned int))) {
> + err = -EFAULT;
> + break;
> + }
> + sco_pi(sk)->force_sco = (force_sco != 0);
> + break;
> +
> default:
> err = -ENOPROTOOPT;
> break;
> @@ -681,6 +693,7 @@
> struct sco_options opts;
> struct sco_conninfo cinfo;
> int len, err = 0;
> + unsigned int force_sco;
>
> BT_DBG("sk %p", sk);
>
> @@ -721,6 +734,13 @@
>
> break;
>
> + case SCO_FORCESCO:
> + force_sco = sco_pi(sock)->force_sco;
> + if (copy_to_user(optval, (char *)&force_sco, sizeof(unsigned
> int)))
> + err = -EFAULT;
> +
> + break;
> +
> default:
> err = -ENOPROTOOPT;
> break;
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
Re: circular locking, mirred, 2.6.24.2
On 24-02-2008 23:20, Denys Fedoryshchenko wrote:
> 2.6.24.2 with applied patches for printk,softlockup, and patch for htb (as i
> understand, they are in 2.6.25 git and it is fixes).
>
> I will send also to private mails QoS rules i am using.
>
> [ 118.840072] ===
> [ 118.840158] [ INFO: possible circular locking dependency detected ]
> [ 118.840203] 2.6.24.2-build-0022 #7
> [ 118.840243] ---
> [ 118.840288] swapper/0 is trying to acquire lock:
> [ 118.840329] (&dev->queue_lock){-+..}, at: [] dev_queue_xmit
> +0x177/0x302
> [ 118.840490]
> [ 118.840490] but task is already holding lock:
> [ 118.840567] (&p->tcfc_lock){-+..}, at: [] tcf_mirred+0x20/0x180
> [act_mirred]
> [ 118.840727]
> [ 118.840727] which lock already depends on the new lock.
> [ 118.840728]
> [ 118.840842]
> [ 118.840842] the existing dependency chain (in reverse order) is:
> [ 118.840921]
> [ 118.840921] -> #2 (&p->tcfc_lock){-+..}:
> [ 118.841075][] __lock_acquire+0xa30/0xc19
> [ 118.841324][] lock_acquire+0x7a/0x94
> [ 118.841572][] _spin_lock+0x2e/0x58
> [ 118.841820][] tcf_mirred+0x20/0x180 [act_mirred]
> [ 118.842068][] tcf_action_exec+0x44/0x77
> [ 118.842344][] u32_classify+0x119/0x24a [cls_u32]
> [ 118.842595][] tc_classify_compat+0x2f/0x5e
> [ 118.842845][] tc_classify+0x1a/0x80
> [ 118.843092][] ingress_enqueue+0x1a/0x53 [sch_ingress]
> [ 118.843343][] netif_receive_skb+0x296/0x44c
> [ 118.843592][] e100_poll+0x14b/0x26a [e100]
> [ 118.843843][] net_rx_action+0xbf/0x201
> [ 118.844091][] __do_softirq+0x6f/0xe9
> [ 118.844343][] do_softirq+0x61/0xc8
> [ 118.844591][] 0x
> [ 118.844840]
> [ 118.844840] -> #1 (&dev->ingress_lock){-+..}:
> [ 118.844993][] __lock_acquire+0xa30/0xc19
> [ 118.845242][] lock_acquire+0x7a/0x94
> [ 118.845489][] _spin_lock+0x2e/0x58
> [ 118.845737][] qdisc_lock_tree+0x1e/0x21
> [ 118.845984][] dev_init_scheduler+0xb/0x53
> [ 118.846235][] register_netdevice+0x2a3/0x2fd
> [ 118.846483][] register_netdev+0x32/0x3f
> [ 118.846730][] loopback_net_init+0x39/0x6c
> [ 118.846980][] register_pernet_operations+0x13/0x15
> [ 118.847230][] register_pernet_device+0x1f/0x4c
> [ 118.847478][] loopback_init+0xd/0xf
> [ 118.847725][] kernel_init+0x155/0x2c6
This looks strange: are you sure your tc scripts aren't started too
early? (Or maybe there are some problems during booting?)
Regards,
Jarek P.
> [ 118.847973][] kernel_thread_helper+0x7/0x10
> [ 118.848225][] 0x
> [ 118.848472]
> [ 118.848472] -> #0 (&dev->queue_lock){-+..}:
> [ 118.848626][] __lock_acquire+0x920/0xc19
> [ 118.848874][] lock_acquire+0x7a/0x94
> [ 118.849122][] _spin_lock+0x2e/0x58
> [ 118.849370][] dev_queue_xmit+0x177/0x302
> [ 118.849617][] tcf_mirred+0x15f/0x180 [act_mirred]
> [ 118.849866][] tcf_action_exec+0x44/0x77
> [ 118.850114][] u32_classify+0x119/0x24a [cls_u32]
> [ 118.850366][] tc_classify_compat+0x2f/0x5e
> [ 118.850614][] tc_classify+0x1a/0x80
> [ 118.850861][] ingress_enqueue+0x1a/0x53 [sch_ingress]
> [ 118.85][] netif_receive_skb+0x296/0x44c
> [ 118.851360][] e100_poll+0x14b/0x26a [e100]
> [ 118.851612][] net_rx_action+0xbf/0x201
> [ 118.851859][] __do_softirq+0x6f/0xe9
> [ 118.852106][] do_softirq+0x61/0xc8
> [ 118.852355][] 0x
...
--
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] nf_conntrack: less hairy ifdefs around proc and sysctl
Patch splits creation of /proc/net/nf_conntrack, /proc/net/stat/nf_conntrack
and net.netfilter hierarchy into their own functions with dummy ones
if PROC_FS or SYSCTL is not set. Also, remove dead "ret = 0" write
while I'm at it.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
net/netfilter/nf_conntrack_standalone.c | 119
1 file changed, 76 insertions(+), 43 deletions(-)
--- a/net/netfilter/nf_conntrack_standalone.c
+++ b/net/netfilter/nf_conntrack_standalone.c
@@ -295,6 +295,41 @@ static const struct file_operations ct_cpu_seq_fops = {
.llseek = seq_lseek,
.release = seq_release_private,
};
+
+static int nf_conntrack_standalone_init_proc(void)
+{
+ struct proc_dir_entry *pde;
+
+ pde = proc_net_fops_create(&init_net, "nf_conntrack", 0440,
&ct_file_ops);
+ if (!pde)
+ goto out_nf_conntrack;
+ pde = create_proc_entry("nf_conntrack", S_IRUGO,
init_net.proc_net_stat);
+ if (!pde)
+ goto out_stat_nf_conntrack;
+ pde->proc_fops = &ct_cpu_seq_fops;
+ pde->owner = THIS_MODULE;
+ return 0;
+
+out_stat_nf_conntrack:
+ proc_net_remove(&init_net, "nf_conntrack");
+out_nf_conntrack:
+ return -ENOMEM;
+}
+
+static void nf_conntrack_standalone_fini_proc(void)
+{
+ remove_proc_entry("nf_conntrack", init_net.proc_net_stat);
+ proc_net_remove(&init_net, "nf_conntrack");
+}
+#else
+static int nf_conntrack_standalone_init_proc(void)
+{
+ return 0;
+}
+
+static void nf_conntrack_standalone_fini_proc(void)
+{
+}
#endif /* CONFIG_PROC_FS */
/* Sysctl support */
@@ -390,63 +425,61 @@ static struct ctl_path nf_ct_path[] = {
};
EXPORT_SYMBOL_GPL(nf_ct_log_invalid);
+
+static int nf_conntrack_standalone_init_sysctl(void)
+{
+ nf_ct_sysctl_header =
+ register_sysctl_paths(nf_ct_path, nf_ct_netfilter_table);
+ if (nf_ct_sysctl_header == NULL) {
+ printk("nf_conntrack: can't register to sysctl.\n");
+ return -ENOMEM;
+ }
+ return 0;
+
+}
+
+static void nf_conntrack_standalone_fini_sysctl(void)
+{
+ unregister_sysctl_table(nf_ct_sysctl_header);
+}
+#else
+static int nf_conntrack_standalone_init_sysctl(void)
+{
+ return 0;
+}
+
+static void nf_conntrack_standalone_fini_sysctl(void)
+{
+}
#endif /* CONFIG_SYSCTL */
static int __init nf_conntrack_standalone_init(void)
{
-#ifdef CONFIG_PROC_FS
- struct proc_dir_entry *proc, *proc_stat;
-#endif
- int ret = 0;
+ int ret;
ret = nf_conntrack_init();
if (ret < 0)
- return ret;
-
-#ifdef CONFIG_PROC_FS
- proc = proc_net_fops_create(&init_net, "nf_conntrack", 0440,
&ct_file_ops);
- if (!proc) goto cleanup_init;
-
- proc_stat = create_proc_entry("nf_conntrack", S_IRUGO,
init_net.proc_net_stat);
- if (!proc_stat)
- goto cleanup_proc;
-
- proc_stat->proc_fops = &ct_cpu_seq_fops;
- proc_stat->owner = THIS_MODULE;
-#endif
-#ifdef CONFIG_SYSCTL
- nf_ct_sysctl_header = register_sysctl_paths(nf_ct_path,
- nf_ct_netfilter_table);
- if (nf_ct_sysctl_header == NULL) {
- printk("nf_conntrack: can't register to sysctl.\n");
- ret = -ENOMEM;
- goto cleanup_proc_stat;
- }
-#endif
- return ret;
+ goto out;
+ ret = nf_conntrack_standalone_init_proc();
+ if (ret < 0)
+ goto out_proc;
+ ret = nf_conntrack_standalone_init_sysctl();
+ if (ret < 0)
+ goto out_sysctl;
+ return 0;
-#ifdef CONFIG_SYSCTL
- cleanup_proc_stat:
-#endif
-#ifdef CONFIG_PROC_FS
- remove_proc_entry("nf_conntrack", init_net. proc_net_stat);
- cleanup_proc:
- proc_net_remove(&init_net, "nf_conntrack");
- cleanup_init:
-#endif /* CNFIG_PROC_FS */
+out_sysctl:
+ nf_conntrack_standalone_fini_proc();
+out_proc:
nf_conntrack_cleanup();
+out:
return ret;
}
static void __exit nf_conntrack_standalone_fini(void)
{
-#ifdef CONFIG_SYSCTL
- unregister_sysctl_table(nf_ct_sysctl_header);
-#endif
-#ifdef CONFIG_PROC_FS
- remove_proc_entry("nf_conntrack", init_net.proc_net_stat);
- proc_net_remove(&init_net, "nf_conntrack");
-#endif /* CNFIG_PROC_FS */
+ nf_conntrack_standalone_fini_sysctl();
+ nf_conntrack_standalone_fini_proc();
nf_conntrack_cleanup();
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [ACKVEC]: Schedule Sync as out-of-band mechanism
The problem with Ack Vectors is that
i) their length is variable and can in principle grow quite large,
ii) it is hard to predict exactly how large they will be.
Due to the second point it seems not a good idea to reduce the MPS; in
particular when on average there is enough room for the Ack Vector and an
increase in length is momentarily due to some burst loss, after which the
Ack Vector returns to its normal/average length.
The solution taken by this patch is to subtract a minimum-expected Ack Vector
length from the MPS (previous patch), and to defer any larger Ack Vectors onto
a separate Sync - but only if indeed there is no space left on the skb.
This patch provides the infrastructure to schedule Sync-packets for transporting
(urgent) out-of-band data. Its signalling is quicker than scheduling an Ack,
since
it does not need to wait for new application data.
It can thus serve other parts of the DCCP code as well.
Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
---
include/linux/dccp.h |2 ++
net/dccp/options.c | 24
net/dccp/output.c|8
3 files changed, 30 insertions(+), 4 deletions(-)
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -475,6 +475,7 @@ struct dccp_ackvec;
* @dccps_hc_rx_insert_options - receiver wants to add options when acking
* @dccps_hc_tx_insert_options - sender wants to add options when sending
* @dccps_server_timewait - server holds timewait state on close (RFC 4340,
8.3)
+ * @dccps_sync_scheduled - flag which signals "send out-of-band message soon"
* @dccps_xmit_timer - timer for when CCID is not ready to send
* @dccps_syn_rtt - RTT sample from Request/Response exchange (in usecs)
*/
@@ -515,6 +516,7 @@ struct dccp_sock {
__u8dccps_hc_rx_insert_options:1;
__u8dccps_hc_tx_insert_options:1;
__u8dccps_server_timewait:1;
+ __u8dccps_sync_scheduled:1;
struct timer_list dccps_xmit_timer;
};
--- a/net/dccp/options.c
+++ b/net/dccp/options.c
@@ -428,6 +428,7 @@ int dccp_insert_option_ackvec(struct soc
{
struct dccp_sock *dp = dccp_sk(sk);
struct dccp_ackvec *av = dp->dccps_hc_rx_ackvec;
+ struct dccp_skb_cb *dcb = DCCP_SKB_CB(skb);
const u16 buflen = dccp_ackvec_buflen(av);
/* Figure out how many options do we need to represent the ackvec */
const u16 nr_opts = DIV_ROUND_UP(buflen, DCCP_SINGLE_OPT_MAXLEN);
@@ -436,10 +437,25 @@ int dccp_insert_option_ackvec(struct soc
const unsigned char *tail, *from;
unsigned char *to;
- if (DCCP_SKB_CB(skb)->dccpd_opt_len + len > DCCP_MAX_OPT_LEN)
+ if (dcb->dccpd_opt_len + len > DCCP_MAX_OPT_LEN) {
+ DCCP_WARN("Lacking space for %u bytes on %s packet\n", len,
+ dccp_packet_name(dcb->dccpd_type));
return -1;
-
- DCCP_SKB_CB(skb)->dccpd_opt_len += len;
+ }
+ /*
+* Since Ack Vectors are variable-length, we can not always predict
+* their size. To catch exception cases where the space is running out
+* on the skb, a separate Sync is scheduled to carry the Ack Vector.
+*/
+ if (len > DCCPAV_MIN_OPTLEN &&
+ len + dcb->dccpd_opt_len + skb->len > dp->dccps_mss_cache) {
+ DCCP_WARN("No space left for Ack Vector (%u) on skb (%u+%u), "
+ "MPS=%u ==> reduce payload size?\n", len, skb->len,
+ dcb->dccpd_opt_len, dp->dccps_mss_cache);
+ dp->dccps_sync_scheduled = 1;
+ return 0;
+ }
+ dcb->dccpd_opt_len += len;
to = skb_push(skb, len);
len = buflen;
@@ -480,7 +496,7 @@ int dccp_insert_option_ackvec(struct soc
/*
* Each sent Ack Vector is recorded in the list, as per A.2 of RFC 4340.
*/
- if (dccp_ackvec_update_records(av, DCCP_SKB_CB(skb)->dccpd_seq, nonce))
+ if (dccp_ackvec_update_records(av, dcb->dccpd_seq, nonce))
return -ENOBUFS;
return 0;
}
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -292,6 +292,8 @@ void dccp_write_xmit(struct sock *sk, in
if (err)
DCCP_BUG("err=%d after ccid_hc_tx_packet_sent",
err);
+ if (dp->dccps_sync_scheduled)
+ dccp_send_sync(sk, dp->dccps_gsr,
DCCP_PKT_SYNC);
} else {
dccp_pr_debug("packet discarded due to err=%d\n", err);
kfree_skb(skb);
@@ -564,6 +566,12 @@ void dccp_send_sync(struct sock *sk, con
DCCP_SKB_CB(skb)->dccpd_type = pkt_type;
DCCP_SKB_CB(skb)->dccpd_ack_seq = ackno;
+ /*
+* Clear the flag in case the Sync was scheduled for out-of-band data,
+*
[PATCH 1/2] [DCCP]: Leave headroom for options when calculating the MPS
The Maximum Packet Size (MPS) is of interest for applications which want to transfer data, so it is only relevant to the data transfer phase of a connection (unless one wants to send data on the DCCP-Request, but that is not considered here). The strategy chosen to deal with this requirement is to leave room for only such options that may appear on data packets. A special consideration applies to Ack Vectors: this is purely guesswork, since these can have any length between 3 and 1020 bytes. The strategy chosen here is to subtract a configurable minimum, the value of 16 bytes (2 bytes for type/length plus 14 Ack Vector cells) has been found by experimentatation. If people experience this as too much or too little, this could later be turned into a Kconfig option. There are currently no CCID-specific header options which may appear on data packets, hence it is not necessary to define a corresponding CCID field. Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]> Acked-by: Ian McDonald <[EMAIL PROTECTED]> --- net/dccp/ackvec.h |3 +++ net/dccp/output.c | 22 ++ 2 files changed, 17 insertions(+), 8 deletions(-) --- a/net/dccp/ackvec.h +++ b/net/dccp/ackvec.h @@ -21,6 +21,9 @@ /* We can spread an ack vector across multiple options */ #define DCCP_MAX_ACKVEC_LEN (DCCP_SINGLE_OPT_MAXLEN * 2) +/* Estimated minimum average Ack Vector length - used for updating MPS */ +#define DCCPAV_MIN_OPTLEN 16 + #define DCCP_ACKVEC_STATE_RECEIVED 0 #define DCCP_ACKVEC_STATE_ECN_MARKED (1 << 6) #define DCCP_ACKVEC_STATE_NOT_RECEIVED (3 << 6) --- a/net/dccp/output.c +++ b/net/dccp/output.c @@ -153,21 +153,27 @@ unsigned int dccp_sync_mss(struct sock * struct inet_connection_sock *icsk = inet_csk(sk); struct dccp_sock *dp = dccp_sk(sk); u32 ccmps = dccp_determine_ccmps(dp); - int cur_mps = ccmps ? min(pmtu, ccmps) : pmtu; + u32 cur_mps = ccmps ? min(pmtu, ccmps) : pmtu; /* Account for header lengths and IPv4/v6 option overhead */ cur_mps -= (icsk->icsk_af_ops->net_header_len + icsk->icsk_ext_hdr_len + sizeof(struct dccp_hdr) + sizeof(struct dccp_hdr_ext)); /* -* FIXME: this should come from the CCID infrastructure, where, say, -* TFRC will say it wants TIMESTAMPS, ELAPSED time, etc, for now lets -* put a rough estimate for NDP + TIMESTAMP + TIMESTAMP_ECHO + ELAPSED -* TIME + TFRC_OPT_LOSS_EVENT_RATE + TFRC_OPT_RECEIVE_RATE + padding to -* make it a multiple of 4 +* Leave enough headroom for common DCCP header options. +* This only considers options which may appear on DCCP-Data packets, as +* per table 3 in RFC 4340, 5.8. When running out of space for other +* options (eg. Ack Vector which can take up to 255 bytes), it is better +* to schedule a separate Ack. Thus we leave headroom for the following: +* - 1 byte for Slow Receiver (11.6) +* - 6 bytes for Timestamp (13.1) +* - 10 bytes for Timestamp Echo (13.3) +* - 8 bytes for NDP count (7.7, when activated) +* - 6 bytes for Data Checksum (9.3) +* - %DCCPAV_MIN_OPTLEN bytes for Ack Vector size (11.4, when enabled) */ - - cur_mps -= ((5 + 6 + 10 + 6 + 6 + 6 + 3) / 4) * 4; + cur_mps -= roundup(1 + 6 + 10 + dp->dccps_send_ndp_count * 8 + 6 + + (dp->dccps_hc_rx_ackvec ? DCCPAV_MIN_OPTLEN : 0), 4); /* And store cached results */ icsk->icsk_pmtu_cookie = pmtu; -- 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
[DCCP] [Patch v2 0/2] [Revision]: Fix Ack Vector MPS Minimum Value
This is a resubmission to fix a problem with accounting for Ack Vector length in the MPS. The present solution did not work well: the MPS did not account for Ack Vectors, so that applications which relied on the MPS value via getopt were disadvantaged by having all their Ack Vectors put onto Syncs -- sorely degrading performance. Found out by testing with gstreamer DCCP plugin. Hence the revision of these two patches implements a new strategy -- it now * subtracts an estimated minimum from the MPS - currently set to 16 bytes (found via experimentation) and * schedules a Sync only if the actual length is greater than this minimum _and_ there is no space left on the skb. Patch #1: Is the revised version of the account-for-option-sizes-in-MPS patch. Patch #2: Is the revised "exception handler" for overly large Ack Vectors. Both patches have been uploaded to the test tree on git://eden-feed.erg.abnd.ac.uk/dccp_exp [dccp] -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.25-rc2-mm1 - several bugs and a crash
Paul E. McKenney schrieb: On Fri, Feb 22, 2008 at 01:52:53AM +0100, Tilman Schmidt wrote: So the nf_conntrack BUG is fixed, but the crash (and of course the swapper "spinlock bad magic" BUG) persists. Do you have CONFIG_DEBUG_PREEMPT set? That would help find any other bugs similar to nf_conntrack. CONFIG_DEBUG_PREEMPT=y was set but didn't produce anything. Or perhaps it did and the message just didn't make it to the disk. Time to set up a test with netconsole, I guess. -- Tilman SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [PATCH] llc: fix skb size for test responses
2008/2/25, Jim Westfall <[EMAIL PROTECTED]>: > David Miller <[EMAIL PROTECTED]> wrote [02.24.08]: > > From: Jim Westfall <[EMAIL PROTECTED]> > > Date: Sun, 24 Feb 2008 11:07:58 -0800 > > > > > Hi > > > > > > The llc test command is used for a layer2 ping and contains a variable > > > length payload that we must include in the response. Use the size of the > > > received skb as the size of the skb we must allocate to hold the payload. > > > > > > This resolved an skb_over_panic(), when trying to copy the payload into > > > what was a hard coded skb of size 128. > > > > > > Signed-off-by: Jim Westfall <[EMAIL PROTECTED]> > > > > Arnaldo, please review Jim's patch, thanks! > > Our of curiosity did you all get my 2nd patch? > > Subject: [PATCH] llc: dont trust payload size on test cmd > > I sent it a few minutes after this one, but seems like it never made it > to the list. My local smtp shows it was delivered sucussfully to > vger.kernel.org. > Jim, Could you please send it again? I cannot find your second patch on the list. I have a pending patch for LLC as well, so I want to avoid conflict with yours. Thanks, Joonwoo -- 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
[NET] Can not send icmp netunreach packet
Hi Steven There is a bug about icmp netunreach. If the kernel does not find a route for a packet, it must send a icmp netunreach packet to the source host, and discard the packet. But the latest kernel does not send a icmp netunreach packet because of the fib_lookup return value of -ESRCH when a route is not found. I found a your patch about why changes the "not found" error return for the lookup function to -ESRCH. But I think this is not correct. Your patch is as following: http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=83886b6b636173b206f475929e58fac75c6f2446 -- 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: [Bluez-devel] forcing SCO connection patch
Sorry, [EMAIL PROTECTED] was missed in cc On Mon, Feb 25, 2008 at 3:34 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > On Mon, Feb 25, 2008 at 3:30 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > Quote mail from [EMAIL PROTECTED] : > > > > 2007/12/17 Louis JANG <[EMAIL PROTECTED]>: > > > > > > > Hello everybody, > > > > > > I attached two patches. the first one(bluez-kernel-forcesco.patch) is > to > > > force using HCI_OP_ADD_SCO instead of HCI_OP_SETUP_SYNC_CONN, and the > > > second one is to handle SCO connection complete event but its request > > > was ESCO. > > > > > > 1. > > > I'm developing bluetooth functions in my linux phone project, and I'm > > > using bluez for my job. I've tested lots of headsets, and found that I > > > coudn't connect SCO channel with HCI_OP_SETUP_SYNC_CONN in some old > > > headsets. I could connect SCO channel with HCI_OP_ADD_SCO in this case. > > > however, there is no api to force using SCO instead of ESCO in bluez. > so > > > I added SCO_FORCESCO to handle this old headsets > > > > > > 2. > > > When I tried to connect SCO channel with > > > HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets > responds > > > with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't > > > handle this situation, and patch_hci_event.c is for this. > > > > > > > > > BRs > > > Louis JANG > > > > > > > > > > Reply from [EMAIL PROTECTED]: > > > > On Mon, Feb 25, 2008 at 2:43 PM, Brad Midgley <[EMAIL PROTECTED]> wrote: > > > Louis > > > > > > > > > > > > When I tried to connect SCO channel with > > > > HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets > responds > > > > with LINK_TYPE_SCO because it did not support ESCO. But bluez > couldn't > > > > handle this situation, and patch_hci_event.c is for this. > > > > > > > > Marcel looked at this patch and came back with the comments below. Can > > > you revisit it? I think some other people are seeing the same issues. > > > The patch won't go upstream until Marcel likes it. > > > > > > the patch you sent me is fully broken. First of all the coding style > > > is wrong. Does nobody have learned this by now? I always look for that > > > first before even reading the patch. Second the case where an > > > ESCO_LINK returns NULL is broken and will fall over and crash. > > > > > > -- > > > Brad > > > > > > > > > I ever asked marcel about the coding style. please see following thread: > > http://lkml.org/lkml/2008/1/22/91 > > > > I think the style problem marcel said is > > 1. using kernel codeing style > > 2. marcel's style > > container_of or get_user_data calls at the top of the variable declaration > > using the empty lines to seperate code blocks > > > > Please rework your patch and resend if you fixed them. > > > > BTW, please use the new bluetooth mailing list for kerne issue. > > [EMAIL PROTECTED] > > > > (Thanks for andrew and davem) > > On bugzilla, bug 9871 are same problem as yours. > > add davem and netdev in cc-list > > > > > Regards > > dave > > > > Regards > > dave > > > -- 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
