* [PATCH] remove useless code from fib6_del_route
From: Gui Jianfeng @ 2007-12-28 7:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Hi Dave,
There are useless codes in fib6_del_route(). The following patch
has been tested, every thing looks fine, as usual.
Signed-off-by: Gui Jianfeng<guijianfeng@cn.fujitsu.com>
---
net/ipv6/ip6_fib.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 946cf38..5f96eb1 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1122,9 +1122,6 @@ static void fib6_del_route(struct fib6_node *fn, struct rt6_info **rtp,
rt->u.dst.rt6_next = NULL;
- if (fn->leaf == NULL && fn->fn_flags&RTN_TL_ROOT)
- fn->leaf = &ip6_null_entry;
-
/* If it was last route, expunge its radix tree node */
if (fn->leaf == NULL) {
fn->fn_flags &= ~RTN_RTINFO;
--
Regards
Gui Jianfeng
^ permalink raw reply related
* Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Andreas Mohr @ 2007-12-28 7:21 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Andreas Mohr, Andrew Morton, David Woodhouse, Eric W. Biederman,
Linus Torvalds, Rafael J. Wysocki, Pavel Machek, kernel list,
netdev, Pavel Emelyanov, Denis V. Lunev
In-Reply-To: <20071228062201.GA2071@martell.zuzino.mipt.ru>
Hi,
On Fri, Dec 28, 2007 at 09:22:01AM +0300, Alexey Dobriyan wrote:
> On Thu, Dec 27, 2007 at 11:17:28PM +0100, Andreas Mohr wrote:
> > And this is the state that my 2.6.24-rc_six_-mm1 tree is in already.
>
> OK.
>
> > So either it didn't help here or it broke again by some later change or
> > there's some dumb PEBKAC error here.
>
> Do you by chance forgot CONFIG_USB_?HCI_HCD=y ? I see empty usbfs here if
> they are deselected.
Quite well-educated guess! In fact I had already discovered that
ohci-hcd fails to load, at all. Doh.
(however after going through all recent ohci.*hcd related LKML postings
it seems there's no report about such problems yet)
Sorry for barking up the entirely wrong tree!
For giggles, here's the output:
# modprobe ohci-hcd
FATAL: Error inserting ohci_hcd (/lib/modules/2.6.24-rc6-mm1-gate/kernel/drivers/usb/host/ohci-hcd.ko): No such device
dmesg:
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd: block sizes: ed 64 td 64
(yes, that's all there is, despite CONFIG_USB_DEBUG being set)
The LED of a usb stick isn't active either, for obvious reasons.
And keep in mind that this is a (relatively old) OHCI-only machine...
(which had the 2.6.19 lsmod showing ohci-hcd just fine and working fine
with WLAN USB)
Now pondering whether to try -rc6 proper or whether to revert specific
guilty-looking USB changes...
And wondering how to properly elevate this issue (prompt Greg about it,
new thread, bug #, ...?)
Thanks,
Andreas Mohr
^ permalink raw reply
* Re: fib6_del_route has redundant code
From: David Miller @ 2007-12-28 8:15 UTC (permalink / raw)
To: guijianfeng; +Cc: netdev, linux-kernel
In-Reply-To: <4774907D.5070806@cn.fujitsu.com>
From: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Date: Fri, 28 Dec 2007 13:58:21 +0800
> >> I think the following code in fib6_del_route in the latest kernel is useless.
> >> 1125 if (fn->leaf == NULL && fn->fn_flags&RTN_TL_ROOT)
> >> 1126 fn->leaf = &ip6_null_entry;
> >>
> >> ip6_null_entry will never be unlinked from fn->leaf now, that is,
> >> fn->leaf == NULL will never meet.
> >
> > I think you are right, but if it is true the next block of
> > code is dead too:
> >
> > /* If it was last route, expunge its radix tree node */
> > if (fn->leaf == NULL) {
> > fn->fn_flags &= ~RTN_RTINFO;
> > rt6_stats.fib_route_nodes--;
> > fn = fib6_repair_tree(fn);
> > }
> >
>
> I think this block of code can't be removed, because just the
> root(default route) fn->leaf always has ip6_null_entry on it. The
> normal fn->leaf becomes NULL when last route has been deleted, the
> radix tree should be expunged.
But you said (still quoted above) that fn->leaf == NULL will not
occur.
Do you mean this, only in the case that the RTN_TL_ROOT flag is set?
I thought you meant always when the function is called, fn->leaf
cannot ever be NULL.
^ permalink raw reply
* Re: fib6_del_route has redundant code
From: Gui Jianfeng @ 2007-12-28 8:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20071228.001510.239311334.davem@davemloft.net>
> From: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
> Date: Fri, 28 Dec 2007 13:58:21 +0800
>
>>>> I think the following code in fib6_del_route in the latest kernel is useless.
>>>> 1125 if (fn->leaf == NULL && fn->fn_flags&RTN_TL_ROOT)
>>>> 1126 fn->leaf = &ip6_null_entry;
>>>>
>>>> ip6_null_entry will never be unlinked from fn->leaf now, that is,
>>>> fn->leaf == NULL will never meet.
>>> I think you are right, but if it is true the next block of
>>> code is dead too:
>>>
>>> /* If it was last route, expunge its radix tree node */
>>> if (fn->leaf == NULL) {
>>> fn->fn_flags &= ~RTN_RTINFO;
>>> rt6_stats.fib_route_nodes--;
>>> fn = fib6_repair_tree(fn);
>>> }
>>>
>> I think this block of code can't be removed, because just the
>> root(default route) fn->leaf always has ip6_null_entry on it. The
>> normal fn->leaf becomes NULL when last route has been deleted, the
>> radix tree should be expunged.
>
> But you said (still quoted above) that fn->leaf == NULL will not
> occur.
>
> Do you mean this, only in the case that the RTN_TL_ROOT flag is set?
yes, I mean this :-)
>
> I thought you meant always when the function is called, fn->leaf
> cannot ever be NULL.
its my fault, sorry for the inconvenient.
>
>
>
^ permalink raw reply
* Re: [PATCH net-2.6.25] CAN: Fix plain integer definitions in userspace header & new CAN version 20071227
From: Oliver Hartkopp @ 2007-12-28 8:58 UTC (permalink / raw)
To: David Miller; +Cc: sam, urs, netdev
In-Reply-To: <20071227.165052.167438890.davem@davemloft.net>
David Miller wrote:
> From: Oliver Hartkopp <oliver@hartkopp.net>
> Date: Thu, 27 Dec 2007 21:14:57 +0100
>
>
>> diff -uprN -X net-2.6.25/Documentation/dontdiff net-2.6.25/include/linux/can/bcm.h export/net2625-2007-12-27/include/linux/can/bcm.h
>> --- net-2.6.25/include/linux/can/bcm.h 2007-12-15 19:33:20.000000000 +0100
>> +++ export/net2625-2007-12-27/include/linux/can/bcm.h 2007-12-27 20:35:54.000000000 +0100
>>
>
> Also, please properly root your patches in the future:
>
> davem@sunset:~/src/GIT/net-2.6.25$ git apply --check --whitespace=error-all diff
> error: net2625-2007-12-27/include/linux/can/bcm.h: No such file or directory
>
>
I was just testing the patch with 'patch -p1 < ... ' but after your
error message i recognized why my patch was faulty as the paths had a
different root depth. Tnx for the hint. Such a mistake will not happen
again.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH net-2.6.25] CAN: Fix plain integer definitions in userspace header & new CAN version 20071227
From: Oliver Hartkopp @ 2007-12-28 9:26 UTC (permalink / raw)
To: David Miller; +Cc: sam, urs, netdev
In-Reply-To: <20071227.164900.233018217.davem@davemloft.net>
David Miller wrote:
> From: Oliver Hartkopp <oliver@hartkopp.net>
> Date: Thu, 27 Dec 2007 21:14:57 +0100
>
>
>> This patch fixes the use of plain integers instead of __u32 in a struct
>> that is visible from kernel space and user space. As this change is user
>> visible this patch also updates the CAN version to 20071227.
>>
>> Thanks to Sam Ravnborg for pointing out the wrong plain int usage.
>>
>> It applies on the current net-2.6.25 tree.
>>
>
> The types are exactly the same size regardless of anything.
>
> There is no reason to make such a big fuss about this, changing the
> CAN version etc.
>
> Also, since CAN has never shown up in a released kernel, there is
> nothing to be incompatible with.
>
The CAN stuff is also available in the 'SocketCAN' SVN for older 2.6
Kernels and i backported the latest code to Kernel 2.4 two weeks ago as
some people still use it. As a change in bcm.h is user visable i just
wanted to freeze the latest version of the header files into a
consistent CAN version for Mainline, older 2.6 and 2.4 Kernels. That was
the reason for creating version 20071227 *before* it hits a released Kernel.
Thanks
Oliver
^ permalink raw reply
* Re: [PATCH net-2.6.25] CAN: Fix plain integer definitions in userspace header & new CAN version 20071227
From: Oliver Hartkopp @ 2007-12-28 10:10 UTC (permalink / raw)
To: David Miller; +Cc: sam, urs, netdev
In-Reply-To: <4774C14F.9010809@hartkopp.net>
Oliver Hartkopp wrote:
> David Miller wrote:
>> The types are exactly the same size regardless of anything.
>>
>> There is no reason to make such a big fuss about this, changing the
>> CAN version etc.
>>
Btw. you are perfectly right with your remark. I'll revert the CAN
version in the SocketCAN SVN back to 20071116 which is in net-2.6.25.
Sorry for the noise.
Oliver
^ permalink raw reply
* Re: testing crazy stuff with iproute2
From: Jarek Poplawski @ 2007-12-28 10:18 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <20071227233749.M11574@visp.net.lb>
On Fri, Dec 28, 2007 at 01:44:17AM +0200, Denys Fedoryshchenko wrote:
...
> For bandwidth sharing it is perfect, but i want just to make things, which i
> did with TBF - some time bursty speed, and then slow down to lower speed if
> customer is using too much. In theory it has to work like this, but in
> practice i am hitting wall. I tried it about 1 year ago, it was same thing,
> just with another conditions. Seems cburst/burst a bit different thing, just
> to make load on CPU by HTB less , at high speeds.
IMHO it's quite possible you're trying to use HTB to things it is
not intended to do. cburst/burst have to limit burstiness and not
change rates depending on load. But, maybe they could do the other
things too whith some tricks, I don't know. I think CBQ or maybe
HFSC could be better for you. But, if TBF works for you, and you
don't need sharing (lending) I don't understand why to 'fight'
with HTB at all. You could maybe use it only to get class hierarchy
with some high, not limiting rates, or even try e.g. prio + TBF
combination.
Regards,
Jarek P.
^ permalink raw reply
* [PATCH] Add Linksys WCF11 to hostap driver
From: Marcin Juszkiewicz @ 2007-12-28 13:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Jouni Malinen, Pavel Roskin, netdev
From: Marcin Juszkiewicz <openembedded@haerwu.biz>
Linksys WCF11 submitted by Ångström user.
"The Linksys Group, Inc.", "Wireless Network CF Card", "ISL37300P", "RevA",
0xa5f472c2, 0x9c05598d, 0xc9049a39, 0x57a66194
manfid: 0x0274, 0x3301
Signed-off-by: Marcin Juszkiewicz <openembedded@haerwu.biz>
---
drivers/net/wireless/hostap/hostap_cs.c | 4 ++++
1 file changed, 4 insertions(+)
--- linux-2.6.23.orig/drivers/net/wireless/hostap/hostap_cs.c
+++ linux-2.6.23/drivers/net/wireless/hostap/hostap_cs.c
@@ -887,10 +887,14 @@ static struct pcmcia_device_id hostap_cs
"Ver. 1.00",
0x5cd01705, 0x4271660f, 0x9d08ee12),
PCMCIA_DEVICE_PROD_ID123(
"corega", "WL PCCL-11", "ISL37300P",
0xa21501a, 0x59868926, 0xc9049a39),
+ PCMCIA_DEVICE_PROD_ID1234(
+ "The Linksys Group, Inc.", "Wireless Network CF Card", "ISL37300P",
+ "RevA",
+ 0xa5f472c2, 0x9c05598d, 0xc9049a39, 0x57a66194),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
OpenEmbedded developer/consultant
Resistance Is Useless! (If < 1 ohm)
^ permalink raw reply
* Re: testing crazy stuff with iproute2
From: Denys Fedoryshchenko @ 2007-12-28 13:20 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20071228101827.GE1618@ff.dom.local>
Prio is limited. I can have on PPPoE up to 500-600 customers, and i need to
create for each in ifb device class/qdisc. So prio will not fit.
On Fri, 28 Dec 2007 11:18:27 +0100, Jarek Poplawski wrote
> On Fri, Dec 28, 2007 at 01:44:17AM +0200, Denys Fedoryshchenko wrote:
> ....
> > For bandwidth sharing it is perfect, but i want just to make things,
which i
> > did with TBF - some time bursty speed, and then slow down to lower speed
if
> > customer is using too much. In theory it has to work like this, but in
> > practice i am hitting wall. I tried it about 1 year ago, it was same
thing,
> > just with another conditions. Seems cburst/burst a bit different thing,
just
> > to make load on CPU by HTB less , at high speeds.
>
> IMHO it's quite possible you're trying to use HTB to things it is
> not intended to do. cburst/burst have to limit burstiness and not
> change rates depending on load. But, maybe they could do the other
> things too whith some tricks, I don't know. I think CBQ or maybe
> HFSC could be better for you. But, if TBF works for you, and you
> don't need sharing (lending) I don't understand why to 'fight'
> with HTB at all. You could maybe use it only to get class hierarchy
> with some high, not limiting rates, or even try e.g. prio + TBF
> combination.
>
> Regards,
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* [PATCH net-2.6.25] [IPv4] Remove unused define in include/net/arp.h (HAVE_ARP_CREATE)
From: Rami Rosen @ 2007-12-28 15:20 UTC (permalink / raw)
To: davem; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
Hello,
It seems to me that the HAVE_ARP_CREATE (empty) definition, from
include/net/arp.h, can be removed,
since it is not used anywhere in the kernel.
Regards,
Rami Rosen
http://www.linux-foundation.org/en/Net:Network_Overview
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 267 bytes --]
diff --git a/include/net/arp.h b/include/net/arp.h
index 36482bf..752eb47 100644
--- a/include/net/arp.h
+++ b/include/net/arp.h
@@ -5,7 +5,6 @@
#include <linux/if_arp.h>
#include <net/neighbour.h>
-#define HAVE_ARP_CREATE
extern struct neigh_table arp_tbl;
^ permalink raw reply related
* Re: [PATCH] net/ipv4/netfilter/ip_tables.c: remove some inlines
From: Patrick McHardy @ 2007-12-28 15:30 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Harald Welte, netdev, linux-kernel,
Netfilter Development Mailinglist
In-Reply-To: <200712270401.35983.vda.linux@googlemail.com>
Denys Vlasenko wrote:
> On Monday 17 December 2007 14:47, Patrick McHardy wrote:
>
>> This clashes with my pending patches, which I'll push upstream
>> today. I also spent some time resyncing ip_tables and ip6_tables
>> so a diff of both (with some sed'ing) shows only the actual
>> differences, so please update ip6_tables as well.
>>
>
> I would be happy to rediff the patch.
>
> Which tree should I sync against in order to not collide
> with your changes?
>
The net-2.6.25.git tree contains all my changes.
^ permalink raw reply
* [PATCH net-2.6.25] [NEIGH] Remove unused method from include/net/neighbour.h
From: Rami Rosen @ 2007-12-28 15:56 UTC (permalink / raw)
To: davem; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
Hello,
It seems to me that neigh_is_valid() inline method from
include/net/neighbour.h can be removed since it is not used.
Though it can be considered as an API for future use, and
indeed we have neigh_is_connected() method in this same header (which is BTW
used only in one place, drivers/net/cxgb3/l2t.c), we can easily notice
that we don't have
any accessor method to check whether the neighbour is in NUD_IN_TIMER
(not to mention that we don't have methods to check the single neighbour states,
like NUD_REACHABLE or NUD_DELAY or the other ones). So for consistency
I suggest to
consider removing the neigh_is_valid() method.
Regards,
Rami Rosen
http://www.linux-foundation.org/en/Net:Network_Overview
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 471 bytes --]
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 11590f2..a9dda29 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -292,10 +292,6 @@ static inline int neigh_is_connected(struct neighbour *neigh)
return neigh->nud_state&NUD_CONNECTED;
}
-static inline int neigh_is_valid(struct neighbour *neigh)
-{
- return neigh->nud_state&NUD_VALID;
-}
static inline int neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
{
^ permalink raw reply related
* Re: [PATCH 0/2] netem: trace enhancement: kernel
From: Patrick McHardy @ 2007-12-28 16:08 UTC (permalink / raw)
To: Ariane Keller; +Cc: Ben Greear, Stephen Hemminger, netdev, Rainer Baumann
In-Reply-To: <476EBD00.2060905@ee.ethz.ch>
Ariane Keller wrote:
> +struct tc_netem_stats
> +{
> + int packetcount;
> + int packetok;
> + int normaldelay;
> + int drops;
> + int dupl;
> + int corrupt;
> + int novaliddata;
> + int reloadbuffer;
These should be unsigned int or __u32.
>
> diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
> linux-2.6.23.8/include/net/flowseed.h
> linux-2.6.23.8_mod/include/net/flowseed.h
> --- linux-2.6.23.8/include/net/flowseed.h 1970-01-01
> 01:00:00.000000000 +0100
> +++ linux-2.6.23.8_mod/include/net/flowseed.h 2007-12-21
> 19:43:24.000000000 +0100
> @@ -0,0 +1,34 @@
> +/* flowseed.h header file for the netem trace enhancement
> + */
> +
> +#ifndef _FLOWSEED_H
> +#define _FLOWSEED_H
> +#include <net/sch_generic.h>
> +
> +/* must be divisible by 4 (=#pkts)*/
> +#define DATA_PACKAGE 4000
Its not obvious that this refers to a size, please rename
to something more approriate. And why is it hardcoded
to 4000? Shouldn't it be related to NLMSG_GOODSIZE?
> +#define DATA_PACKAGE_ID 4008
Its even less obvious that this is the netlink attribute
size. Its obfuscation anyway, just open-code
RTA_SPACE(new name of DATA_PACKAGE).
> +
> +/* struct per flow - kernel */
> +struct tcn_control
> +{
> + struct list_head full_buffer_list;
> + struct list_head empty_buffer_list;
> + struct buflist * buffer_in_use;
> + int *offsetpos; /* pointer to actual pos in the buffer in
> use */
> + int flowid;
> +};
> +
> +struct tcn_statistic
> +{
> + int packetcount;
> + int packetok;
> + int normaldelay;
> + int drops;
> + int dupl;
> + int corrupt;
> + int novaliddata;
> + int reloadbuffer;
Also unsigned please.
>
> diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
> linux-2.6.23.8/net/sched/sch_api.c linux-2.6.23.8_mod/net/sched/sch_api.c
> --- linux-2.6.23.8/net/sched/sch_api.c 2007-11-16
> 19:14:27.000000000 +0100
> +++ linux-2.6.23.8_mod/net/sched/sch_api.c 2007-12-21
> 19:42:49.000000000 +0100
> @@ -28,6 +28,7 @@
> #include <linux/list.h>
> #include <linux/hrtimer.h>
>
> +#include <net/sock.h>
> #include <net/netlink.h>
> #include <net/pkt_sched.h>
>
> @@ -841,6 +842,62 @@ rtattr_failure:
> nlmsg_trim(skb, b);
> return -1;
> }
> +static int tc_fill(struct sk_buff *skb, struct Qdisc *q, u32 clid,
> + u32 pid, u32 seq, u16 flags, int event)
> +{
> + struct tcmsg *tcm;
> + struct nlmsghdr *nlh;
> + unsigned char *b = skb_tail_pointer(skb);
> +
> + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
> + tcm = NLMSG_DATA(nlh);
> + tcm->tcm_family = AF_UNSPEC;
> + tcm->tcm__pad1 = 0;
> + tcm->tcm__pad2 = 0;
> + tcm->tcm_ifindex = q->dev->ifindex;
> + tcm->tcm_parent = clid;
> + tcm->tcm_handle = q->handle;
> + tcm->tcm_info = atomic_read(&q->refcnt);
> + RTA_PUT(skb, TCA_KIND, IFNAMSIZ, q->ops->id);
> + if (q->ops->dump && q->ops->dump(q, skb) < 0)
> + goto rtattr_failure;
> +
> + nlh->nlmsg_len = skb_tail_pointer(skb) - b;
> +
> + return skb->len;
Why is this function not used by tc_fill_qdisc?
> +
> +nlmsg_failure:
> +rtattr_failure:
> + nlmsg_trim(skb, b);
> + return -1;
> +}
> +
> +int qdisc_notify_pid(int pid, struct nlmsghdr *n,
> + u32 clid, struct Qdisc *old, struct Qdisc *new)
> +{
> + struct sk_buff *skb;
> + skb = alloc_skb(NLMSG_GOODSIZE, gfp_any());
> + if (!skb)
> + return -ENOBUFS;
> +
> + if (old && old->handle) {
> + if (tc_fill(skb, old, clid, pid, n->nlmsg_seq,
> + 0, RTM_DELQDISC) < 0)
> + goto err_out;
> + }
> + if (new) {
> + if (tc_fill(skb, new, clid, pid, n->nlmsg_seq,
> + old ? NLM_F_REPLACE : 0, RTM_NEWQDISC) < 0)
> + goto err_out;
> + }
> + if (skb->len)
> + return rtnetlink_send(skb, pid, RTNLGRP_TC, n->nlmsg_flags);
And why do you need a new notification function? qdisc_notify
seems perfectly fine for this.
> +
> +err_out:
> + kfree_skb(skb);
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(qdisc_notify_pid);
>
> static int qdisc_notify(struct sk_buff *oskb, struct nlmsghdr *n,
> u32 clid, struct Qdisc *old, struct Qdisc *new)
> @@ -848,7 +905,7 @@ static int qdisc_notify(struct sk_buff *
> struct sk_buff *skb;
> u32 pid = oskb ? NETLINK_CB(oskb).pid : 0;
>
> - skb = alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
> + skb = alloc_skb(NLMSG_GOODSIZE, gfp_any());
You don't even use qdisc_notify anywhere in your patch, why
this change?
> if (!skb)
> return -ENOBUFS;
>
> diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
> linux-2.6.23.8/net/sched/sch_netem.c
> linux-2.6.23.8_mod/net/sched/sch_netem.c
> --- linux-2.6.23.8/net/sched/sch_netem.c 2007-11-16
> 19:14:27.000000000 +0100
> +++ linux-2.6.23.8_mod/net/sched/sch_netem.c 2007-12-21
> 19:42:49.000000000 +0100
> +/* don't call this function directly. It is called after
> + * a packet has been taken out of a buffer and it was the last.
> + */
> +static int reload_flowbuffer(struct netem_sched_data *q, struct Qdisc
> *sch)
> +{
> + struct tcn_control *flow = q->flowbuffer;
> + struct nlmsghdr n;
> + struct buflist *element = list_entry(flow->full_buffer_list.next,
> + struct buflist, list);
> + /* the current buffer is empty */
> + list_add_tail(&flow->buffer_in_use->list, &flow->empty_buffer_list);
> +
> + if (list_empty(&q->flowbuffer->full_buffer_list)) {
> + printk(KERN_ERR "netem: reload_flowbuffer, no full buffer\n");
> + return -EFAULT;
> + }
> +
> + list_del_init(&element->list);
> + flow->buffer_in_use = element;
> + flow->offsetpos = (int *)element->buf;
> + memset(&n, 0, sizeof(struct nlmsghdr));
> + n.nlmsg_seq = 1;
> + n.nlmsg_flags = NLM_F_REQUEST;
This netlink header faking is horrible, please just change qdisc_notify
to deal with absent netlink headers appropriately. The sequence number
used for kernel notifications not related to userspace requests is 0.
> + if (qdisc_notify_pid(q->flowid, &n, sch->parent, NULL, sch) < 0)
> + printk(KERN_ERR "netem: unable to request for more data\n");
netlink_set_err() causing userspace to request all current information
seems like better error handling. The remaining netem part also looks
like it could use a lot of improvement, you shouldn't need manual
notifications on destruction, change, etc., all this is already
handled by sch_api. There should be a single new notification in
netem_enqueue(), calling qdisc_notify(), which dumps the current
state to userspace.
^ permalink raw reply
* [PATCH][v2] phylib: add module owner to the mii_bus structure
From: Ionut Nicu @ 2007-12-28 17:31 UTC (permalink / raw)
To: netdev; +Cc: shemminger, Ionut Nicu
In-Reply-To: <785b16e8da057c6efb259494258bb30314ccac4c.1198861866.git.ionut.nicu@freescale.com>
Prevent unloading mii bus driver module when other modules have references to some
phydevs on that bus. Added a new member (module owner) to struct mii_bus and added
code to increment the mii bus owner module usage count on phy_connect and decrement
it on phy_disconnect
Set the module owner in the ucc_geth_mdio driver.
Signed-off-by: Ionut Nicu <ionut.nicu@freescale.com>
Tested-by: Emil Medve <Emilian.Medve@Freescale.com>
---
drivers/net/phy/phy_device.c | 9 ++++++++-
drivers/net/ucc_geth_mii.c | 3 +++
include/linux/phy.h | 4 ++++
3 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 5b9e175..ca617ec 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -171,6 +171,10 @@ struct phy_device * phy_connect(struct net_device *dev, const char *phy_id,
if (IS_ERR(phydev))
return phydev;
+ /* Increment the usage count of the mii bus owner */
+ if (!try_module_get(phydev->bus->owner))
+ return ERR_PTR(-EFAULT);
+
phy_prepare_link(phydev, handler);
phy_start_machine(phydev, NULL);
@@ -192,9 +196,12 @@ void phy_disconnect(struct phy_device *phydev)
phy_stop_interrupts(phydev);
phy_stop_machine(phydev);
-
+
phydev->adjust_link = NULL;
+ /* Decrement the reference count for the mii bus owner */
+ module_put(phydev->bus->owner);
+
phy_detach(phydev);
}
EXPORT_SYMBOL(phy_disconnect);
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index a3af4ea..84c7295 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -217,6 +217,9 @@ static int uec_mdio_probe(struct of_device *ofdev, const struct of_device_id *ma
}
}
+ /* register ourselves as the owner of this bus */
+ new_bus->owner = THIS_MODULE;
+
err = mdiobus_register(new_bus);
if (0 != err) {
printk(KERN_ERR "%s: Cannot register as MDIO bus\n",
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 554836e..04ff6a5 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -82,6 +82,10 @@ struct mii_bus {
const char *name;
int id;
void *priv;
+
+ /* The module that owns this bus */
+ struct module *owner;
+
int (*read)(struct mii_bus *bus, int phy_id, int regnum);
int (*write)(struct mii_bus *bus, int phy_id, int regnum, u16 val);
int (*reset)(struct mii_bus *bus);
--
1.5.4.rc1
^ permalink raw reply related
* Re: [PATCH] via-velocity big-endian support
From: Al Viro @ 2007-12-28 18:40 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, jgarzik
In-Reply-To: <20071225232135.GA22589@electric-eye.fr.zoreil.com>
On Wed, Dec 26, 2007 at 12:21:35AM +0100, Francois Romieu wrote:
> -> some descriptor bits are now declared with an explicit endianness
> while others are not (whence "u16 rsr" where "__le16 rsr" whould
> have fit). Both are fine but it would not hurt to stick with one
> convention in a given driver.
Point taken...
* kill multibyte bitfields
* annotate
* add missing conversions
* fix a couple of brainos in zerocopy stuff (fortunately, it's ifdef'ed out)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
drivers/net/via-velocity.c | 62 ++++++-------
drivers/net/via-velocity.h | 220 +++++++++++++++++++-------------------------
2 files changed, 125 insertions(+), 157 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 35cd65d..3842516 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -8,7 +8,6 @@
* for 64bit hardware platforms.
*
* TODO
- * Big-endian support
* rx_copybreak/alignment
* Scatter gather
* More testing
@@ -681,7 +680,7 @@ static void velocity_rx_reset(struct velocity_info *vptr)
* Init state, all RD entries belong to the NIC
*/
for (i = 0; i < vptr->options.numrx; ++i)
- vptr->rd_ring[i].rdesc0.owner = OWNED_BY_NIC;
+ vptr->rd_ring[i].rdesc0.len |= OWNED_BY_NIC;
writew(vptr->options.numrx, ®s->RBRDU);
writel(vptr->rd_pool_dma, ®s->RDBaseLo);
@@ -777,7 +776,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
vptr->int_mask = INT_MASK_DEF;
- writel(cpu_to_le32(vptr->rd_pool_dma), ®s->RDBaseLo);
+ writel(vptr->rd_pool_dma, ®s->RDBaseLo);
writew(vptr->options.numrx - 1, ®s->RDCSize);
mac_rx_queue_run(regs);
mac_rx_queue_wake(regs);
@@ -785,7 +784,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
writew(vptr->options.numtx - 1, ®s->TDCSize);
for (i = 0; i < vptr->num_txq; i++) {
- writel(cpu_to_le32(vptr->td_pool_dma[i]), &(regs->TDBaseLo[i]));
+ writel(vptr->td_pool_dma[i], ®s->TDBaseLo[i]);
mac_tx_queue_run(regs, i);
}
@@ -1195,7 +1194,7 @@ static inline void velocity_give_many_rx_descs(struct velocity_info *vptr)
dirty = vptr->rd_dirty - unusable;
for (avail = vptr->rd_filled & 0xfffc; avail; avail--) {
dirty = (dirty > 0) ? dirty - 1 : vptr->options.numrx - 1;
- vptr->rd_ring[dirty].rdesc0.owner = OWNED_BY_NIC;
+ vptr->rd_ring[dirty].rdesc0.len |= OWNED_BY_NIC;
}
writew(vptr->rd_filled & 0xfffc, ®s->RBRDU);
@@ -1210,7 +1209,7 @@ static int velocity_rx_refill(struct velocity_info *vptr)
struct rx_desc *rd = vptr->rd_ring + dirty;
/* Fine for an all zero Rx desc at init time as well */
- if (rd->rdesc0.owner == OWNED_BY_NIC)
+ if (rd->rdesc0.len & OWNED_BY_NIC)
break;
if (!vptr->rd_info[dirty].skb) {
@@ -1413,7 +1412,7 @@ static int velocity_rx_srv(struct velocity_info *vptr, int status)
if (!vptr->rd_info[rd_curr].skb)
break;
- if (rd->rdesc0.owner == OWNED_BY_NIC)
+ if (rd->rdesc0.len & OWNED_BY_NIC)
break;
rmb();
@@ -1421,7 +1420,7 @@ static int velocity_rx_srv(struct velocity_info *vptr, int status)
/*
* Don't drop CE or RL error frame although RXOK is off
*/
- if ((rd->rdesc0.RSR & RSR_RXOK) || (!(rd->rdesc0.RSR & RSR_RXOK) && (rd->rdesc0.RSR & (RSR_CE | RSR_RL)))) {
+ if (rd->rdesc0.RSR & (RSR_RXOK | RSR_CE | RSR_RL)) {
if (velocity_receive_frame(vptr, rd_curr) < 0)
stats->rx_dropped++;
} else {
@@ -1433,7 +1432,7 @@ static int velocity_rx_srv(struct velocity_info *vptr, int status)
stats->rx_dropped++;
}
- rd->inten = 1;
+ rd->size |= RX_INTEN;
vptr->dev->last_rx = jiffies;
@@ -1554,7 +1553,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
struct net_device_stats *stats = &vptr->stats;
struct velocity_rd_info *rd_info = &(vptr->rd_info[idx]);
struct rx_desc *rd = &(vptr->rd_ring[idx]);
- int pkt_len = rd->rdesc0.len;
+ int pkt_len = le16_to_cpu(rd->rdesc0.len) & 0x3fff;
struct sk_buff *skb;
if (rd->rdesc0.RSR & (RSR_STP | RSR_EDP)) {
@@ -1637,8 +1636,7 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
*/
*((u32 *) & (rd->rdesc0)) = 0;
- rd->len = cpu_to_le32(vptr->rx_buf_sz);
- rd->inten = 1;
+ rd->size = cpu_to_le16(vptr->rx_buf_sz) | RX_INTEN;
rd->pa_low = cpu_to_le32(rd_info->skb_dma);
rd->pa_high = 0;
return 0;
@@ -1674,7 +1672,7 @@ static int velocity_tx_srv(struct velocity_info *vptr, u32 status)
td = &(vptr->td_rings[qnum][idx]);
tdinfo = &(vptr->td_infos[qnum][idx]);
- if (td->tdesc0.owner == OWNED_BY_NIC)
+ if (td->tdesc0.len & OWNED_BY_NIC)
break;
if ((works++ > 15))
@@ -1874,7 +1872,7 @@ static void velocity_free_tx_buf(struct velocity_info *vptr, struct velocity_td_
for (i = 0; i < tdinfo->nskb_dma; i++) {
#ifdef VELOCITY_ZERO_COPY_SUPPORT
- pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i], td->tdesc1.len, PCI_DMA_TODEVICE);
+ pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i], le16_to_cpu(td->tdesc1.len), PCI_DMA_TODEVICE);
#else
pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i], skb->len, PCI_DMA_TODEVICE);
#endif
@@ -2067,8 +2065,8 @@ static int velocity_xmit(struct sk_buff *skb, struct net_device *dev)
struct velocity_td_info *tdinfo;
unsigned long flags;
int index;
-
int pktlen = skb->len;
+ __le16 len = cpu_to_le16(pktlen);
#ifdef VELOCITY_ZERO_COPY_SUPPORT
if (skb_shinfo(skb)->nr_frags > 6 && __skb_linearize(skb)) {
@@ -2085,7 +2083,7 @@ static int velocity_xmit(struct sk_buff *skb, struct net_device *dev)
td_ptr->tdesc1.TCPLS = TCPLS_NORMAL;
td_ptr->tdesc1.TCR = TCR0_TIC;
- td_ptr->td_buf[0].queue = 0;
+ td_ptr->td_buf[0].size &= ~TD_QUEUE;
/*
* Pad short frames.
@@ -2093,14 +2091,15 @@ static int velocity_xmit(struct sk_buff *skb, struct net_device *dev)
if (pktlen < ETH_ZLEN) {
/* Cannot occur until ZC support */
pktlen = ETH_ZLEN;
+ len = cpu_to_le16(ETH_ZLEN);
skb_copy_from_linear_data(skb, tdinfo->buf, skb->len);
memset(tdinfo->buf + skb->len, 0, ETH_ZLEN - skb->len);
tdinfo->skb = skb;
tdinfo->skb_dma[0] = tdinfo->buf_dma;
- td_ptr->tdesc0.pktsize = pktlen;
+ td_ptr->tdesc0.len = len;
td_ptr->td_buf[0].pa_low = cpu_to_le32(tdinfo->skb_dma[0]);
td_ptr->td_buf[0].pa_high = 0;
- td_ptr->td_buf[0].bufsize = td_ptr->tdesc0.pktsize;
+ td_ptr->td_buf[0].size = len; /* queue is 0 anyway */
tdinfo->nskb_dma = 1;
td_ptr->tdesc1.CMDZ = 2;
} else
@@ -2111,10 +2110,10 @@ static int velocity_xmit(struct sk_buff *skb, struct net_device *dev)
if (nfrags > 6) {
skb_copy_from_linear_data(skb, tdinfo->buf, skb->len);
tdinfo->skb_dma[0] = tdinfo->buf_dma;
- td_ptr->tdesc0.pktsize =
+ td_ptr->tdesc0.len = len;
td_ptr->td_buf[0].pa_low = cpu_to_le32(tdinfo->skb_dma[0]);
td_ptr->td_buf[0].pa_high = 0;
- td_ptr->td_buf[0].bufsize = td_ptr->tdesc0.pktsize;
+ td_ptr->td_buf[0].size = len; /* queue is 0 anyway */
tdinfo->nskb_dma = 1;
td_ptr->tdesc1.CMDZ = 2;
} else {
@@ -2122,22 +2121,23 @@ static int velocity_xmit(struct sk_buff *skb, struct net_device *dev)
tdinfo->nskb_dma = 0;
tdinfo->skb_dma[i] = pci_map_single(vptr->pdev, skb->data, skb->len - skb->data_len, PCI_DMA_TODEVICE);
- td_ptr->tdesc0.pktsize = pktlen;
+ td_ptr->tdesc0.len = len;
/* FIXME: support 48bit DMA later */
td_ptr->td_buf[i].pa_low = cpu_to_le32(tdinfo->skb_dma);
td_ptr->td_buf[i].pa_high = 0;
- td_ptr->td_buf[i].bufsize = skb->len->skb->data_len;
+ td_ptr->td_buf[i].size =
+ cpu_to_le16(skb->len->skb->data_len);
for (i = 0; i < nfrags; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- void *addr = ((void *) page_address(frag->page + frag->page_offset));
+ void *addr = (void *)page_address(frag->page) + frag->page_offset;
tdinfo->skb_dma[i + 1] = pci_map_single(vptr->pdev, addr, frag->size, PCI_DMA_TODEVICE);
td_ptr->td_buf[i + 1].pa_low = cpu_to_le32(tdinfo->skb_dma[i + 1]);
td_ptr->td_buf[i + 1].pa_high = 0;
- td_ptr->td_buf[i + 1].bufsize = frag->size;
+ td_ptr->td_buf[i + 1].size = cpu_to_le16(frag->size);
}
tdinfo->nskb_dma = i - 1;
td_ptr->tdesc1.CMDZ = i;
@@ -2152,18 +2152,16 @@ static int velocity_xmit(struct sk_buff *skb, struct net_device *dev)
*/
tdinfo->skb = skb;
tdinfo->skb_dma[0] = pci_map_single(vptr->pdev, skb->data, pktlen, PCI_DMA_TODEVICE);
- td_ptr->tdesc0.pktsize = pktlen;
+ td_ptr->tdesc0.len = len;
td_ptr->td_buf[0].pa_low = cpu_to_le32(tdinfo->skb_dma[0]);
td_ptr->td_buf[0].pa_high = 0;
- td_ptr->td_buf[0].bufsize = td_ptr->tdesc0.pktsize;
+ td_ptr->td_buf[0].size = len;
tdinfo->nskb_dma = 1;
td_ptr->tdesc1.CMDZ = 2;
}
if (vptr->vlgrp && vlan_tx_tag_present(skb)) {
- td_ptr->tdesc1.pqinf.VID = vlan_tx_tag_get(skb);
- td_ptr->tdesc1.pqinf.priority = 0;
- td_ptr->tdesc1.pqinf.CFI = 0;
+ td_ptr->tdesc1.vlan = cpu_to_le16(vlan_tx_tag_get(skb));
td_ptr->tdesc1.TCR |= TCR0_VETAG;
}
@@ -2185,7 +2183,7 @@ static int velocity_xmit(struct sk_buff *skb, struct net_device *dev)
if (prev < 0)
prev = vptr->options.numtx - 1;
- td_ptr->tdesc0.owner = OWNED_BY_NIC;
+ td_ptr->tdesc0.len |= OWNED_BY_NIC;
vptr->td_used[qnum]++;
vptr->td_curr[qnum] = (index + 1) % vptr->options.numtx;
@@ -2193,7 +2191,7 @@ static int velocity_xmit(struct sk_buff *skb, struct net_device *dev)
netif_stop_queue(dev);
td_ptr = &(vptr->td_rings[qnum][prev]);
- td_ptr->td_buf[0].queue = 1;
+ td_ptr->td_buf[0].size |= TD_QUEUE;
mac_tx_queue_wake(vptr->mac_regs, qnum);
}
dev->trans_start = jiffies;
@@ -3410,7 +3408,7 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
velocity_save_context(vptr, &vptr->context);
velocity_shutdown(vptr);
velocity_set_wol(vptr);
- pci_enable_wake(pdev, 3, 1);
+ pci_enable_wake(pdev, PCI_D3hot, 1);
pci_set_power_state(pdev, PCI_D3hot);
} else {
velocity_save_context(vptr, &vptr->context);
diff --git a/drivers/net/via-velocity.h b/drivers/net/via-velocity.h
index aa91796..ffb7ced 100644
--- a/drivers/net/via-velocity.h
+++ b/drivers/net/via-velocity.h
@@ -70,40 +70,27 @@
* Bits in the RSR0 register
*/
-#define RSR_DETAG 0x0080
-#define RSR_SNTAG 0x0040
-#define RSR_RXER 0x0020
-#define RSR_RL 0x0010
-#define RSR_CE 0x0008
-#define RSR_FAE 0x0004
-#define RSR_CRC 0x0002
-#define RSR_VIDM 0x0001
+#define RSR_DETAG cpu_to_le16(0x0080)
+#define RSR_SNTAG cpu_to_le16(0x0040)
+#define RSR_RXER cpu_to_le16(0x0020)
+#define RSR_RL cpu_to_le16(0x0010)
+#define RSR_CE cpu_to_le16(0x0008)
+#define RSR_FAE cpu_to_le16(0x0004)
+#define RSR_CRC cpu_to_le16(0x0002)
+#define RSR_VIDM cpu_to_le16(0x0001)
/*
* Bits in the RSR1 register
*/
-#define RSR_RXOK 0x8000 // rx OK
-#define RSR_PFT 0x4000 // Perfect filtering address match
-#define RSR_MAR 0x2000 // MAC accept multicast address packet
-#define RSR_BAR 0x1000 // MAC accept broadcast address packet
-#define RSR_PHY 0x0800 // MAC accept physical address packet
-#define RSR_VTAG 0x0400 // 802.1p/1q tagging packet indicator
-#define RSR_STP 0x0200 // start of packet
-#define RSR_EDP 0x0100 // end of packet
-
-/*
- * Bits in the RSR1 register
- */
-
-#define RSR1_RXOK 0x80 // rx OK
-#define RSR1_PFT 0x40 // Perfect filtering address match
-#define RSR1_MAR 0x20 // MAC accept multicast address packet
-#define RSR1_BAR 0x10 // MAC accept broadcast address packet
-#define RSR1_PHY 0x08 // MAC accept physical address packet
-#define RSR1_VTAG 0x04 // 802.1p/1q tagging packet indicator
-#define RSR1_STP 0x02 // start of packet
-#define RSR1_EDP 0x01 // end of packet
+#define RSR_RXOK cpu_to_le16(0x8000) // rx OK
+#define RSR_PFT cpu_to_le16(0x4000) // Perfect filtering address match
+#define RSR_MAR cpu_to_le16(0x2000) // MAC accept multicast address packet
+#define RSR_BAR cpu_to_le16(0x1000) // MAC accept broadcast address packet
+#define RSR_PHY cpu_to_le16(0x0800) // MAC accept physical address packet
+#define RSR_VTAG cpu_to_le16(0x0400) // 802.1p/1q tagging packet indicator
+#define RSR_STP cpu_to_le16(0x0200) // start of packet
+#define RSR_EDP cpu_to_le16(0x0100) // end of packet
/*
* Bits in the CSM register
@@ -120,33 +107,21 @@
* Bits in the TSR0 register
*/
-#define TSR0_ABT 0x0080 // Tx abort because of excessive collision
-#define TSR0_OWT 0x0040 // Jumbo frame Tx abort
-#define TSR0_OWC 0x0020 // Out of window collision
-#define TSR0_COLS 0x0010 // experience collision in this transmit event
-#define TSR0_NCR3 0x0008 // collision retry counter[3]
-#define TSR0_NCR2 0x0004 // collision retry counter[2]
-#define TSR0_NCR1 0x0002 // collision retry counter[1]
-#define TSR0_NCR0 0x0001 // collision retry counter[0]
-#define TSR0_TERR 0x8000 //
-#define TSR0_FDX 0x4000 // current transaction is serviced by full duplex mode
-#define TSR0_GMII 0x2000 // current transaction is serviced by GMII mode
-#define TSR0_LNKFL 0x1000 // packet serviced during link down
-#define TSR0_SHDN 0x0400 // shutdown case
-#define TSR0_CRS 0x0200 // carrier sense lost
-#define TSR0_CDH 0x0100 // AQE test fail (CD heartbeat)
-
-/*
- * Bits in the TSR1 register
- */
-
-#define TSR1_TERR 0x80 //
-#define TSR1_FDX 0x40 // current transaction is serviced by full duplex mode
-#define TSR1_GMII 0x20 // current transaction is serviced by GMII mode
-#define TSR1_LNKFL 0x10 // packet serviced during link down
-#define TSR1_SHDN 0x04 // shutdown case
-#define TSR1_CRS 0x02 // carrier sense lost
-#define TSR1_CDH 0x01 // AQE test fail (CD heartbeat)
+#define TSR0_ABT cpu_to_le16(0x0080) // Tx abort because of excessive collision
+#define TSR0_OWT cpu_to_le16(0x0040) // Jumbo frame Tx abort
+#define TSR0_OWC cpu_to_le16(0x0020) // Out of window collision
+#define TSR0_COLS cpu_to_le16(0x0010) // experience collision in this transmit event
+#define TSR0_NCR3 cpu_to_le16(0x0008) // collision retry counter[3]
+#define TSR0_NCR2 cpu_to_le16(0x0004) // collision retry counter[2]
+#define TSR0_NCR1 cpu_to_le16(0x0002) // collision retry counter[1]
+#define TSR0_NCR0 cpu_to_le16(0x0001) // collision retry counter[0]
+#define TSR0_TERR cpu_to_le16(0x8000) //
+#define TSR0_FDX cpu_to_le16(0x4000) // current transaction is serviced by full duplex mode
+#define TSR0_GMII cpu_to_le16(0x2000) // current transaction is serviced by GMII mode
+#define TSR0_LNKFL cpu_to_le16(0x1000) // packet serviced during link down
+#define TSR0_SHDN cpu_to_le16(0x0400) // shutdown case
+#define TSR0_CRS cpu_to_le16(0x0200) // carrier sense lost
+#define TSR0_CDH cpu_to_le16(0x0100) // AQE test fail (CD heartbeat)
//
// Bits in the TCR0 register
@@ -197,25 +172,26 @@
*/
struct rdesc0 {
- u16 RSR; /* Receive status */
- u16 len:14; /* Received packet length */
- u16 reserved:1;
- u16 owner:1; /* Who owns this buffer ? */
+ __le16 RSR; /* Receive status */
+ __le16 len; /* bits 0--13; bit 15 - owner */
};
struct rdesc1 {
- u16 PQTAG;
+ __le16 PQTAG;
u8 CSM;
u8 IPKT;
};
+enum {
+ RX_INTEN = __constant_cpu_to_le16(0x8000)
+};
+
struct rx_desc {
struct rdesc0 rdesc0;
struct rdesc1 rdesc1;
- u32 pa_low; /* Low 32 bit PCI address */
- u16 pa_high; /* Next 16 bit PCI address (48 total) */
- u16 len:15; /* Frame size */
- u16 inten:1; /* Enable interrupt */
+ __le32 pa_low; /* Low 32 bit PCI address */
+ __le16 pa_high; /* Next 16 bit PCI address (48 total) */
+ __le16 size; /* bits 0--14 - frame size, bit 15 - enable int. */
} __attribute__ ((__packed__));
/*
@@ -223,32 +199,26 @@ struct rx_desc {
*/
struct tdesc0 {
- u16 TSR; /* Transmit status register */
- u16 pktsize:14; /* Size of frame */
- u16 reserved:1;
- u16 owner:1; /* Who owns the buffer */
+ __le16 TSR; /* Transmit status register */
+ __le16 len; /* bits 0--13 - size of frame, bit 15 - owner */
};
-struct pqinf { /* Priority queue info */
- u16 VID:12;
- u16 CFI:1;
- u16 priority:3;
-} __attribute__ ((__packed__));
-
struct tdesc1 {
- struct pqinf pqinf;
+ __le16 vlan;
u8 TCR;
u8 TCPLS:2;
u8 reserved:2;
u8 CMDZ:4;
} __attribute__ ((__packed__));
+enum {
+ TD_QUEUE = __constant_cpu_to_le16(0x8000)
+};
+
struct td_buf {
- u32 pa_low;
- u16 pa_high;
- u16 bufsize:14;
- u16 reserved:1;
- u16 queue:1;
+ __le32 pa_low;
+ __le16 pa_high;
+ __le16 size; /* bits 0--13 - size, bit 15 - queue */
} __attribute__ ((__packed__));
struct tx_desc {
@@ -276,7 +246,7 @@ struct velocity_td_info {
enum velocity_owner {
OWNED_BY_HOST = 0,
- OWNED_BY_NIC = 1
+ OWNED_BY_NIC = __constant_cpu_to_le16(0x8000)
};
@@ -1012,45 +982,45 @@ struct mac_regs {
volatile u8 RCR;
volatile u8 TCR;
- volatile u32 CR0Set; /* 0x08 */
- volatile u32 CR0Clr; /* 0x0C */
+ volatile __le32 CR0Set; /* 0x08 */
+ volatile __le32 CR0Clr; /* 0x0C */
volatile u8 MARCAM[8]; /* 0x10 */
- volatile u32 DecBaseHi; /* 0x18 */
- volatile u16 DbfBaseHi; /* 0x1C */
- volatile u16 reserved_1E;
+ volatile __le32 DecBaseHi; /* 0x18 */
+ volatile __le16 DbfBaseHi; /* 0x1C */
+ volatile __le16 reserved_1E;
- volatile u16 ISRCTL; /* 0x20 */
+ volatile __le16 ISRCTL; /* 0x20 */
volatile u8 TXESR;
volatile u8 RXESR;
- volatile u32 ISR; /* 0x24 */
- volatile u32 IMR;
+ volatile __le32 ISR; /* 0x24 */
+ volatile __le32 IMR;
- volatile u32 TDStatusPort; /* 0x2C */
+ volatile __le32 TDStatusPort; /* 0x2C */
- volatile u16 TDCSRSet; /* 0x30 */
+ volatile __le16 TDCSRSet; /* 0x30 */
volatile u8 RDCSRSet;
volatile u8 reserved_33;
- volatile u16 TDCSRClr;
+ volatile __le16 TDCSRClr;
volatile u8 RDCSRClr;
volatile u8 reserved_37;
- volatile u32 RDBaseLo; /* 0x38 */
- volatile u16 RDIdx; /* 0x3C */
- volatile u16 reserved_3E;
+ volatile __le32 RDBaseLo; /* 0x38 */
+ volatile __le16 RDIdx; /* 0x3C */
+ volatile __le16 reserved_3E;
- volatile u32 TDBaseLo[4]; /* 0x40 */
+ volatile __le32 TDBaseLo[4]; /* 0x40 */
- volatile u16 RDCSize; /* 0x50 */
- volatile u16 TDCSize; /* 0x52 */
- volatile u16 TDIdx[4]; /* 0x54 */
- volatile u16 tx_pause_timer; /* 0x5C */
- volatile u16 RBRDU; /* 0x5E */
+ volatile __le16 RDCSize; /* 0x50 */
+ volatile __le16 TDCSize; /* 0x52 */
+ volatile __le16 TDIdx[4]; /* 0x54 */
+ volatile __le16 tx_pause_timer; /* 0x5C */
+ volatile __le16 RBRDU; /* 0x5E */
- volatile u32 FIFOTest0; /* 0x60 */
- volatile u32 FIFOTest1; /* 0x64 */
+ volatile __le32 FIFOTest0; /* 0x60 */
+ volatile __le32 FIFOTest1; /* 0x64 */
volatile u8 CAMADDR; /* 0x68 */
volatile u8 CAMCR; /* 0x69 */
@@ -1063,18 +1033,18 @@ struct mac_regs {
volatile u8 PHYSR1;
volatile u8 MIICR;
volatile u8 MIIADR;
- volatile u16 MIIDATA;
+ volatile __le16 MIIDATA;
- volatile u16 SoftTimer0; /* 0x74 */
- volatile u16 SoftTimer1;
+ volatile __le16 SoftTimer0; /* 0x74 */
+ volatile __le16 SoftTimer1;
volatile u8 CFGA; /* 0x78 */
volatile u8 CFGB;
volatile u8 CFGC;
volatile u8 CFGD;
- volatile u16 DCFG; /* 0x7C */
- volatile u16 MCFG;
+ volatile __le16 DCFG; /* 0x7C */
+ volatile __le16 MCFG;
volatile u8 TBIST; /* 0x80 */
volatile u8 RBIST;
@@ -1086,9 +1056,9 @@ struct mac_regs {
volatile u8 rev_id;
volatile u8 PORSTS;
- volatile u32 MIBData; /* 0x88 */
+ volatile __le32 MIBData; /* 0x88 */
- volatile u16 EEWrData;
+ volatile __le16 EEWrData;
volatile u8 reserved_8E;
volatile u8 BPMDWr;
@@ -1098,7 +1068,7 @@ struct mac_regs {
volatile u8 EECHKSUM; /* 0x92 */
volatile u8 EECSR;
- volatile u16 EERdData; /* 0x94 */
+ volatile __le16 EERdData; /* 0x94 */
volatile u8 EADDR;
volatile u8 EMBCMD;
@@ -1112,22 +1082,22 @@ struct mac_regs {
volatile u8 DEBUG;
volatile u8 CHIPGCR;
- volatile u16 WOLCRSet; /* 0xA0 */
+ volatile __le16 WOLCRSet; /* 0xA0 */
volatile u8 PWCFGSet;
volatile u8 WOLCFGSet;
- volatile u16 WOLCRClr; /* 0xA4 */
+ volatile __le16 WOLCRClr; /* 0xA4 */
volatile u8 PWCFGCLR;
volatile u8 WOLCFGClr;
- volatile u16 WOLSRSet; /* 0xA8 */
- volatile u16 reserved_AA;
+ volatile __le16 WOLSRSet; /* 0xA8 */
+ volatile __le16 reserved_AA;
- volatile u16 WOLSRClr; /* 0xAC */
- volatile u16 reserved_AE;
+ volatile __le16 WOLSRClr; /* 0xAC */
+ volatile __le16 reserved_AE;
- volatile u16 PatternCRC[8]; /* 0xB0 */
- volatile u32 ByteMask[4][4]; /* 0xC0 */
+ volatile __le16 PatternCRC[8]; /* 0xB0 */
+ volatile __le32 ByteMask[4][4]; /* 0xC0 */
} __attribute__ ((__packed__));
@@ -1238,12 +1208,12 @@ typedef u8 MCAM_ADDR[ETH_ALEN];
struct arp_packet {
u8 dest_mac[ETH_ALEN];
u8 src_mac[ETH_ALEN];
- u16 type;
- u16 ar_hrd;
- u16 ar_pro;
+ __be16 type;
+ __be16 ar_hrd;
+ __be16 ar_pro;
u8 ar_hln;
u8 ar_pln;
- u16 ar_op;
+ __be16 ar_op;
u8 ar_sha[ETH_ALEN];
u8 ar_sip[4];
u8 ar_tha[ETH_ALEN];
@@ -1253,7 +1223,7 @@ struct arp_packet {
struct _magic_packet {
u8 dest_mac[6];
u8 src_mac[6];
- u16 type;
+ __be16 type;
u8 MAC[16][6];
u8 password[6];
} __attribute__ ((__packed__));
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH 0/2] netem: trace enhancement: kernel
From: Ariane Keller @ 2007-12-28 21:02 UTC (permalink / raw)
To: Patrick McHardy
Cc: Ariane Keller, Ben Greear, Stephen Hemminger, netdev,
Rainer Baumann
In-Reply-To: <47751F86.1030205@trash.net>
Thanks for your comments!
Patrick McHardy wrote:
> Ariane Keller wrote:
>> +/* must be divisible by 4 (=#pkts)*/
>> +#define DATA_PACKAGE 4000
>
> Its not obvious that this refers to a size, please rename
> to something more approriate. And why is it hardcoded
> to 4000? Shouldn't it be related to NLMSG_GOODSIZE?
Ok, I can rename it to TRACE_DATA_PACKET_SIZE
>
>> +#define DATA_PACKAGE_ID 4008
>
> Its even less obvious that this is the netlink attribute
> size. Its obfuscation anyway, just open-code
> RTA_SPACE(new name of DATA_PACKAGE).
DATA_PACKAGE_ID corresponds to DATA_PACKAGE + 2 * sizeof(int).
The two ints are a small header in front of each packet.
I agree the name is really bad and I have to think
about the whole thing with this header.
>> +
>> +int qdisc_notify_pid(int pid, struct nlmsghdr *n,
>> + u32 clid, struct Qdisc *old, struct Qdisc *new)
>> +{
>> + struct sk_buff *skb;
>> + skb = alloc_skb(NLMSG_GOODSIZE, gfp_any());
>> + if (!skb)
>> + return -ENOBUFS;
>> +
>> + if (old && old->handle) {
>> + if (tc_fill(skb, old, clid, pid, n->nlmsg_seq,
>> + 0, RTM_DELQDISC) < 0)
>> + goto err_out;
>> + }
>> + if (new) {
>> + if (tc_fill(skb, new, clid, pid, n->nlmsg_seq,
>> + old ? NLM_F_REPLACE : 0, RTM_NEWQDISC) < 0)
>> + goto err_out;
>> + }
>> + if (skb->len)
>> + return rtnetlink_send(skb, pid, RTNLGRP_TC, n->nlmsg_flags);
>
> And why do you need a new notification function? qdisc_notify
> seems perfectly fine for this.
qdisc_notify results in acquiring a lock (q->stats_lock) which we
already hold in this situation
(qdisc_notify->tc_fill_qdisc->gnet_stats_start_copy_compat).
Writing a new notification function may be wrong,
but I do not know a better way.
>> diff -uprN -X linux-2.6.23.8/Documentation/dontdiff
>> linux-2.6.23.8/net/sched/sch_netem.c
>> linux-2.6.23.8_mod/net/sched/sch_netem.c
>> --- linux-2.6.23.8/net/sched/sch_netem.c 2007-11-16
>> 19:14:27.000000000 +0100
>> +++ linux-2.6.23.8_mod/net/sched/sch_netem.c 2007-12-21
>> 19:42:49.000000000 +0100
>
>> +/* don't call this function directly. It is called after
>> + * a packet has been taken out of a buffer and it was the last.
>> + */
>> +static int reload_flowbuffer(struct netem_sched_data *q, struct Qdisc
>> *sch)
>> +{
>> + struct tcn_control *flow = q->flowbuffer;
>> + struct nlmsghdr n;
>> + struct buflist *element = list_entry(flow->full_buffer_list.next,
>> + struct buflist, list);
>> + /* the current buffer is empty */
>> + list_add_tail(&flow->buffer_in_use->list, &flow->empty_buffer_list);
>> +
>> + if (list_empty(&q->flowbuffer->full_buffer_list)) {
>> + printk(KERN_ERR "netem: reload_flowbuffer, no full buffer\n");
>> + return -EFAULT;
>> + }
>> +
>> + list_del_init(&element->list);
>> + flow->buffer_in_use = element;
>> + flow->offsetpos = (int *)element->buf;
>> + memset(&n, 0, sizeof(struct nlmsghdr));
>> + n.nlmsg_seq = 1;
>> + n.nlmsg_flags = NLM_F_REQUEST;
>
> This netlink header faking is horrible, please just change qdisc_notify
> to deal with absent netlink headers appropriately. The sequence number
> used for kernel notifications not related to userspace requests is 0.
>
>> + if (qdisc_notify_pid(q->flowid, &n, sch->parent, NULL, sch) < 0)
>> + printk(KERN_ERR "netem: unable to request for more data\n");
>
> netlink_set_err() causing userspace to request all current information
> seems like better error handling. The remaining netem part also looks
> like it could use a lot of improvement, you shouldn't need manual
> notifications on destruction, change, etc., all this is already
> handled by sch_api. There should be a single new notification in
> netem_enqueue(), calling qdisc_notify(), which dumps the current
> state to userspace.
I can summarize the notifications which request for more data.
But I do not (yet) know how I get rid of those which deal
with the notification of the deletion of a qdisc.
"tc qdisc add/change ... trace ..." start a new process (flowseed)
which waits for kernel requests to send trace data packets
to the netem module.
If "tc qdisc change/del ..." is called the previously generated
flowseed process needs to be terminated. I did this by sending a
notification to the corresponding flowseed process.
Upon receiving this notification the flowseed process terminates itself.
Is there already an event generated by sch_api on which the flowseed
process could listen in order to be notified when a given qdisc is deleted?
Thanks a lot!
Ariane
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [ROSE] [AX25] possible circular locking
From: Pidoux @ 2007-12-28 21:30 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Alexey Dobriyan, Ralf Baechle DL5RB, Linux Netdev List
In-Reply-To: <20071218135202.GA2023@ff.dom.local>
Jarek Poplawski wrote :
> On Mon, Dec 17, 2007 at 11:06:04AM +0100, Bernard Pidoux F6BVP wrote:
>
>> Hi,
>>
>>
>> When I killall kissattach I can see the following message.
>>
>> This happens on kernel 2.6.24-rc5 already patched with the 6 previously
>> patches I sent recently.
>>
>>
>> =======================================================
>> [ INFO: possible circular locking dependency detected ]
>> 2.6.23.9 #1
>> -------------------------------------------------------
>> kissattach/2906 is trying to acquire lock:
>> (linkfail_lock){-+..}, at: [<d8bd4603>] ax25_link_failed+0x11/0x39 [ax25]
>>
>> but task is already holding lock:
>> (ax25_list_lock){-+..}, at: [<d8bd7c7c>] ax25_device_event+0x38/0x84
>> [ax25]
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
> ...
>
> It seems, lockdep is warried about the different order here:
>
> #1 (rose_neigh_list_lock){-+..}:
> #3 (ax25_list_lock){-+..}:
>
> #0 (linkfail_lock){-+..}:
> #1 (rose_neigh_list_lock){-+..}:
>
> #3 (ax25_list_lock){-+..}:
> #0 (linkfail_lock){-+..}:
>
> So, ax25_list_lock could be taken before and after linkfail_lock.
> I don't know if this three-thread clutch is very probable (or
> possible at all), but it seems this other bug nearby reported by
> Bernard ("[...] system impossible to reboot with linux-2.6.24-rc5")
> could have similar source - namely ax25_list_lock held by
> ax25_kill_by_device() during ax25_disconnect(). It looks like the
> only place which calls ax25_disconnect() this way, so I guess, it
> isn't necessary. But, since I don't know AX25 & ROSE at all, this
> should be necessarily verified by somebody who knows these things.
>
> I attach here my very experimental proposal with breaking the lock
> for ax25_disconnect(), with some failsafe and debugging because of
> this, but, if in this special case the lock is required for some
> other reasons, then this patch should be dumped, of course.
>
> Regards,
> Jarek P.
>
> WARNING:
> not tested, not even compiled, needs some ack before testing!
>
> ---
>
> diff -Nurp linux-2.6.24-rc5-/net/ax25/af_ax25.c linux-2.6.24-rc5+/net/ax25/af_ax25.c
> --- linux-2.6.24-rc5-/net/ax25/af_ax25.c 2007-12-17 13:29:19.000000000 +0100
> +++ linux-2.6.24-rc5+/net/ax25/af_ax25.c 2007-12-18 13:36:05.000000000 +0100
> @@ -87,10 +87,19 @@ static void ax25_kill_by_device(struct n
> return;
>
> spin_lock_bh(&ax25_list_lock);
> +again:
> ax25_for_each(s, node, &ax25_list) {
> if (s->ax25_dev == ax25_dev) {
> + struct hlist_node *nn = node->next;
> +
> s->ax25_dev = NULL;
> + spin_unlock_bh(&ax25_list_lock);
> ax25_disconnect(s, ENETUNREACH);
> + spin_lock_bh(&ax25_list_lock);
> + if (nn != node->next) {
> + WARN_ON_ONCE(1);
> + goto again;
> + }
> }
> }
> spin_unlock_bh(&ax25_list_lock);
>
>
>
After a few days of observation and a number of reboot for test purpose,
I confirm that your patch is doing very well.
I have no more problems rebooting and the AX25 applications are running
fine.
I hope this patch, with or without warning, could be applied in next
kernel release.
Thanks again Jarek.
Regards from Bernard P.
f6bvp
^ permalink raw reply
* [PATCH][ROSE][AX25] af_ax25: possible circular locking
From: Jarek Poplawski @ 2007-12-28 21:48 UTC (permalink / raw)
To: David Miller
Cc: Pidoux, Ralf Baechle DL5RB, Alexey Dobriyan, Linux Netdev List
In-Reply-To: <47755FDB.2070501@free.fr>
On Fri, Dec 28, 2007 at 09:43:07PM +0100, Pidoux wrote:
...
> After a few days of observation and a number of reboot for test purpose, I
> confirm that your patch is doing very well.
> I have no more problems rebooting and the AX25 applications are running
> fine.
>
> I hope this patch, with or without warning, could be applied in next kernel
> release.
>
> Thanks again Jarek.
>
> Regards from Bernard P.
> f6bvp
Thanks again Bernard.
Jarek P. too
---------------->
Subject: [ROSE][AX25] af_ax25: possible circular locking
Bernard Pidoux F6BVP reported:
> When I killall kissattach I can see the following message.
>
> This happens on kernel 2.6.24-rc5 already patched with the 6 previously
> patches I sent recently.
>
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.23.9 #1
> -------------------------------------------------------
> kissattach/2906 is trying to acquire lock:
> (linkfail_lock){-+..}, at: [<d8bd4603>] ax25_link_failed+0x11/0x39 [ax25]
>
> but task is already holding lock:
> (ax25_list_lock){-+..}, at: [<d8bd7c7c>] ax25_device_event+0x38/0x84
> [ax25]
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
...
lockdep is worried about the different order here:
#1 (rose_neigh_list_lock){-+..}:
#3 (ax25_list_lock){-+..}:
#0 (linkfail_lock){-+..}:
#1 (rose_neigh_list_lock){-+..}:
#3 (ax25_list_lock){-+..}:
#0 (linkfail_lock){-+..}:
So, ax25_list_lock could be taken before and after linkfail_lock.
I don't know if this three-thread clutch is very probable (or
possible at all), but it seems another bug reported by Bernard
("[...] system impossible to reboot with linux-2.6.24-rc5")
could have similar source - namely ax25_list_lock held by
ax25_kill_by_device() during ax25_disconnect(). It looks like the
only place which calls ax25_disconnect() this way, so I guess, it
isn't necessary.
This patch is breaking the lock for ax25_disconnect(), with some
failsafe and debugging added to detect unforeseen problems.
Reported-and-tested-by: Bernard Pidoux <f6bvp@free.fr>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
diff -Nurp linux-2.6.24-rc5-/net/ax25/af_ax25.c linux-2.6.24-rc5+/net/ax25/af_ax25.c
--- linux-2.6.24-rc5-/net/ax25/af_ax25.c 2007-12-17 13:29:19.000000000 +0100
+++ linux-2.6.24-rc5+/net/ax25/af_ax25.c 2007-12-18 13:36:05.000000000 +0100
@@ -87,10 +87,19 @@ static void ax25_kill_by_device(struct n
return;
spin_lock_bh(&ax25_list_lock);
+again:
ax25_for_each(s, node, &ax25_list) {
if (s->ax25_dev == ax25_dev) {
+ struct hlist_node *nn = node->next;
+
s->ax25_dev = NULL;
+ spin_unlock_bh(&ax25_list_lock);
ax25_disconnect(s, ENETUNREACH);
+ spin_lock_bh(&ax25_list_lock);
+ if (nn != node->next) {
+ WARN_ON_ONCE(1);
+ goto again;
+ }
}
}
spin_unlock_bh(&ax25_list_lock);
^ permalink raw reply
* Re: 2.6.24-rc6-mm1
From: Andrew Morton @ 2007-12-28 23:07 UTC (permalink / raw)
To: Torsten Kaiser; +Cc: linux-kernel, Neil Brown, J. Bruce Fields, netdev
In-Reply-To: <64bb37e0712281453y4aac82b7h7acc8ec314ca6e3e@mail.gmail.com>
On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <just.for.lkml@googlemail.com> wrote:
> On Dec 23, 2007 5:27 PM, Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> > On Dec 23, 2007 8:30 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
> > I have finally given up on using 2.6.24-rc3-mm2 with slub_debug=FZP to
> > get more information out of the random crashes I had seen with that
> > version. (Did not crash once with slub_debug, so no new information on
> > what the cause was)
>
> Murphy: Just after sending that mail the system crashed two times with
> slub_debug=FZP, but did not show any new informations.
> No debug output from slub, only this stacktrace: (Its the same I
> already reported in the 2.6.24-rc3-mm2 thread)
>
> [ 7620.673012] ------------[ cut here ]------------
> [ 7620.676291] kernel BUG at lib/list_debug.c:33!
> [ 7620.679440] invalid opcode: 0000 [1] SMP
> [ 7620.682319] last sysfs file:
> /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
> [ 7620.687845] CPU 0
> [ 7620.689300] Modules linked in: radeon drm nfsd exportfs w83792d
> ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
> tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
> videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common
> v4l1_compat hid i2c_nforce2 sg pata_amd
> [ 7620.708561] Pid: 5698, comm: nfsv4-svc Not tainted 2.6.24-rc3-mm2 #2
> [ 7620.713080] RIP: 0010:[<ffffffff803bae54>] [<ffffffff803bae54>]
> __list_add+0x54/0x60
> [ 7620.718667] RSP: 0018:ffff81011bca1dc0 EFLAGS: 00010282
> [ 7620.722439] RAX: 0000000000000088 RBX: ffff81011c862c48 RCX: 0000000000000002
> [ 7620.727504] RDX: ffff81011bc82ef0 RSI: 0000000000000001 RDI: ffffffff807590c0
> [ 7620.732581] RBP: ffff81011bca1dc0 R08: 0000000000000001 R09: 0000000000000000
> [ 7620.737658] R10: ffff810080058d48 R11: 0000000000000001 R12: ffff81011ed8d1c8
> [ 7620.742711] R13: ffff81011ed8d200 R14: ffff81011ed8d200 R15: ffff81011cc0e578
> [ 7620.747806] FS: 00007ffe400116f0(0000) GS:ffffffff807d4000(0000)
> knlGS:00000000f73558e0
> [ 7620.753535] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 7620.757607] CR2: 00000000017071dc CR3: 00000001188b5000 CR4: 00000000000006e0
> [ 7620.762677] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 7620.767748] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 7620.772808] Process nfsv4-svc (pid: 5698, threadinfo
> FFFF81011BCA0000, task FFFF81011BC82EF0)
> [ 7620.778872] Stack: ffff81011bca1e00 ffffffff805be26e
> ffff81011ed8d1d0 ffff81011cc0e578
> [ 7620.784626] ffff81011c862c48 ffff81011c8be000 ffff810054a8b060
> ffff81011cc0e588
> [ 7620.789913] ffff81011bca1e10 ffffffff805be367 ffff81011bca1ee0
> ffffffff805bf0ac
> [ 7620.795062] Call Trace:
> [ 7620.796941] [<ffffffff805be26e>] svc_xprt_enqueue+0x1ae/0x250
> [ 7620.801087] [<ffffffff805be367>] svc_xprt_received+0x17/0x20
> [ 7620.805199] [<ffffffff805bf0ac>] svc_recv+0x39c/0x840
> [ 7620.808851] [<ffffffff805bea3f>] svc_send+0xaf/0xd0
> [ 7620.812374] [<ffffffff8022f590>] default_wake_function+0x0/0x10
> [ 7620.816637] [<ffffffff803163ea>] nfs_callback_svc+0x7a/0x130
> [ 7620.820712] [<ffffffff805cfea2>] trace_hardirqs_on_thunk+0x35/0x3a
> [ 7620.825174] [<ffffffff80259f8f>] trace_hardirqs_on+0xbf/0x160
> [ 7620.829335] [<ffffffff8020cbc8>] child_rip+0xa/0x12
> [ 7620.832842] [<ffffffff8020c2df>] restore_args+0x0/0x30
> [ 7620.836554] [<ffffffff80316370>] nfs_callback_svc+0x0/0x130
> [ 7620.840564] [<ffffffff8020cbbe>] child_rip+0x0/0x12
> [ 7620.844102]
> [ 7620.845168] INFO: lockdep is turned off.
> [ 7620.847964]
> [ 7620.847965] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16
> 48 89 e5 e8
> [ 7620.854334] RIP [<ffffffff803bae54>] __list_add+0x54/0x60
> [ 7620.858255] RSP <ffff81011bca1dc0>
> [ 7620.860724] Kernel panic - not syncing: Aiee, killing interrupt handler!
>
That looks like a sunrpc bug. git-nfsd has bene mucking around in there a
bit.
>
> The cause, why I am resending this: I just got a crash with
> 2.6.24-rc6-mm1, again looking network related:
>
> [93436.933356] WARNING: at include/net/dst.h:165 dst_release()
> [93436.936685] Pid: 8079, comm: konqueror Not tainted 2.6.24-rc6-mm1 #11
> [93436.939292]
> [93436.939293] Call Trace:
> [93436.939304] [<ffffffff80531d2d>] skb_release_all+0xdd/0x110
> [93436.939307] [<ffffffff80531311>] __kfree_skb+0x11/0xa0
> [93436.939309] [<ffffffff805313b7>] kfree_skb+0x17/0x30
> [93436.939312] [<ffffffff805a0b48>] unix_release_sock+0x128/0x250
> [93436.939315] [<ffffffff805a0c91>] unix_release+0x21/0x30
> [93436.939318] [<ffffffff8052b144>] sock_release+0x24/0x90
> [93436.939320] [<ffffffff8052b656>] sock_close+0x26/0x50
> [93436.939324] [<ffffffff8029f921>] __fput+0xc1/0x230
> [93436.939327] [<ffffffff8029fe46>] fput+0x16/0x20
> [93436.939329] [<ffffffff8029c576>] filp_close+0x56/0x90
> [93436.939331] [<ffffffff8029de46>] sys_close+0xa6/0x110
> [93436.939335] [<ffffffff8020b57b>] system_call_after_swapgs+0x7b/0x80
> [93436.939337]
> [93436.947241] general protection fault: 0000 [1] SMP
> [93436.947243] last sysfs file:
> /sys/devices/pci0000:00/0000:00:0f.0/0000:01:00.1/irq
> [93436.947245] CPU 1
> [93436.947246] Modules linked in: radeon drm nfsd exportfs w83792d
> ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
> tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
> videobuf_core btcx_risc tveeprom usbhid videodev v4l2_common hid
> v4l1_compat pata_amd sg i2c_nforce2
> [93436.947257] Pid: 8079, comm: konqueror Not tainted 2.6.24-rc6-mm1 #11
> [93436.947259] RIP: 0010:[<ffffffff80531438>] [<ffffffff80531438>]
> skb_drop_list+0x18/0x30
> [93436.947262] RSP: 0018:ffff810005f4fda8 EFLAGS: 00010286
> [93436.947263] RAX: ab1ed5ca5b74e7de RBX: ab1ed5ca5b74e7de RCX: 000000000000d135
> [93436.947265] RDX: ffff81011d089a80 RSI: 0000000000000001 RDI: ffff81011d089a88
> [93436.947266] RBP: ffff810005f4fdb8 R08: 0000000000000001 R09: 0000000000000006
> [93436.947268] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100de02c500
> [93436.947269] R13: ffff81011c188a00 R14: 0000000000000001 R15: ffff81011c189198
> [93436.947271] FS: 00007fb5bde0d700(0000) GS:ffff81007ff22000(0000)
> knlGS:0000000000000000
> [93436.947273] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [93436.947274] CR2: 00007fb5bdd76000 CR3: 00000000664d5000 CR4: 00000000000006e0
> [93436.947276] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [93436.947277] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [93436.947279] Process konqueror (pid: 8079, threadinfo
> ffff810005f4e000, task ffff8100a1dec000)
> [93436.947281] Stack: ffff810005f4fdd8 ffff810116c86140
> ffff810005f4fdd8 ffffffff805314ae
> [93436.947284] ffff810116c86140 ffff8100de02c500 ffff810005f4fdf8
> ffffffff80531cf0
> [93436.947286] ffff8100de02c500 ffff81011c188b48 ffff810005f4fe18
> ffffffff80531311
> [93436.947288] Call Trace:
> [93436.947290] [<ffffffff805314ae>] skb_release_data+0x5e/0xa0
> [93436.947293] [<ffffffff80531cf0>] skb_release_all+0xa0/0x110
> [93436.947295] [<ffffffff80531311>] __kfree_skb+0x11/0xa0
> [93436.947297] [<ffffffff805313b7>] kfree_skb+0x17/0x30
> [93436.947299] [<ffffffff805a0b48>] unix_release_sock+0x128/0x250
> [93436.947302] [<ffffffff805a0c91>] unix_release+0x21/0x30
> [93436.947304] [<ffffffff8052b144>] sock_release+0x24/0x90
> [93436.947307] [<ffffffff8052b656>] sock_close+0x26/0x50
> [93436.947309] [<ffffffff8029f921>] __fput+0xc1/0x230
> [93436.947312] [<ffffffff8029fe46>] fput+0x16/0x20
> [93436.947314] [<ffffffff8029c576>] filp_close+0x56/0x90
> [93436.947316] [<ffffffff8029de46>] sys_close+0xa6/0x110
> [93436.947319] [<ffffffff8020b57b>] system_call_after_swapgs+0x7b/0x80
> [93436.947322]
> [93436.947322]
> [93436.947323] Code: 48 8b 18 48 89 c7 e8 5d ff ff ff 48 85 db 75 ed
> 48 83 c4 08
> [93436.947328] RIP [<ffffffff80531438>] skb_drop_list+0x18/0x30
> [93436.947330] RSP <ffff810005f4fda8>
> [93436.947332] ---[ end trace befb7cc3528ab3b1 ]---
Yes, that looks more networking-related.
> Don't know in what direction I should look.
> I also can't easily reproduce this, it happened after several hours of
> watching a wmv stream with mplayer...
>
> Torsten
^ permalink raw reply
* [PATCH] Make FC, FDDI, HIPPI and TR tristate
From: Jan Engelhardt @ 2007-12-28 23:45 UTC (permalink / raw)
To: jgarzik; +Cc: netdev
Turn CONFIG_FC, CONFIG_FDDI, CONFIG_HIPPI and CONFIG_TR into tristate
so they can be built as modules. This will allow CONFIG_LLC to be
built as a module too, overall reducing the core kernel image size.
$ size vmlinux.previous vmlinux
text data bss dec hex filename
2805040 266008 380928 3451976 34ac48 vmlinux.previous
2794603 265620 380928 3441151 3481ff vmlinux
$ l vmlinux.previous vmlinux
-rwxr-xr-x 1 jengelh users 5154214 Dec 29 00:02 vmlinux.previous
-rwxr-xr-x 1 jengelh users 5135974 Dec 29 00:39 vmlinux
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index d9107e5..934f678 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2638,7 +2638,7 @@ config RIONET_RX_SIZE
default "128"
config FDDI
- bool "FDDI driver support"
+ tristate "FDDI driver support"
depends on (PCI || EISA || TC)
help
Fiber Distributed Data Interface is a high speed local area network
@@ -2708,7 +2708,7 @@ config SKFP
will be called skfp. This is recommended.
config HIPPI
- bool "HIPPI driver support (EXPERIMENTAL)"
+ tristate "HIPPI driver support (EXPERIMENTAL)"
depends on EXPERIMENTAL && INET && PCI
help
HIgh Performance Parallel Interface (HIPPI) is a 800Mbit/sec and
@@ -3009,7 +3009,7 @@ config SLIP_MODE_SLIP6
over the async ports of a Camtec JNT Pad. If unsure, say N.
config NET_FC
- bool "Fibre Channel driver support"
+ tristate "Fibre Channel driver support"
depends on SCSI && PCI
help
Fibre Channel is a high speed serial protocol mainly used to connect
diff --git a/drivers/net/tokenring/Kconfig b/drivers/net/tokenring/Kconfig
index e6b2e06..c4137b0 100644
--- a/drivers/net/tokenring/Kconfig
+++ b/drivers/net/tokenring/Kconfig
@@ -4,7 +4,7 @@
# So far, we only have PCI, ISA, and MCA token ring devices
menuconfig TR
- bool "Token Ring driver support"
+ tristate "Token Ring driver support"
depends on NETDEVICES && !UML
depends on (PCI || ISA || MCA || CCW)
select LLC
^ permalink raw reply related
* [RFC/PATCH] e100 driver didn't support any MII-less PHYs...
From: Andreas Mohr @ 2007-12-28 23:51 UTC (permalink / raw)
To: e1000-devel; +Cc: auke-jan.h.kok, netdev, linux-kernel, bunk
Hi all,
I was mildly annoyed when rebooting my _headless_ internet gateway after a
hotplug -> udev migration and witnessing it not coming up again,
which turned out to be due to an eepro100 / e100 loading conflict
since eepro100 supported both of my Intel-based network cards,
whereas e100 only supported the "newer" one and entirely failed on ifup...
(udev had somehow managed to tweak loading sequence as compared to
a hotplug setup, which caused the drivers to probe differently)
After investigating this e100 failure for half an hour it was obvious
that it was failing in e100_hw_init() -> e100_phy_init() since the driver was
prepared to handle MII-capable PHYs only, not certain older(?) MII-less
PHYs such as 80c24 or i82503.
Investigating some FreeBSD etc. drivers it became terribly clear that there
are also some MII-less PHYs and that one would have to handle them properly.
Thus I decided to add support for those:
- after PHY init failure, try to detect whether the EEPROM lists one of
the MII-less PHYs
- if so, don't fatally fail PHY init function
- avoid touching MII in various utility functions in case of MII-less
PHY (FIXME: this may need review, it was a quick hack in some places)
- add some proper logging on init failure
Note that this is an initial, semi-rough patch only, would love to have
it corrected/improved by the e1000 team.
(I also added some spelling updates for good measure, these would have
to be committed separately obviously)
Frankly I'm quite uncertain as to why one would try to actively deprecate
a driver which works for many cards with a newer one which fails to work
for several card types and doesn't seem clearly superiour in hindsight
after going through it...
Oh, right, that's in order to brute-force people to report any
nagging problems with the new driver, which is... errm... very
understandable after all ;)
(I hope that me "reporting" this problem via a patch is ok ;)
For reference, I'm using a BNC/AUI/TP PCI combo card
Intel 82557 645477-004 FCC ID EJMNPDEPR10PCTPCI
This mail written using a reassuringly stable connection over the newly
adapted driver...
Thanks,
Andreas Mohr
Signed-off-by: Andreas Mohr <andi@lisas.de>
--- linux-2.6.24-rc6/drivers/net/e100.c.orig 2007-12-28 18:05:39.000000000 +0100
+++ linux-2.6.24-rc6/drivers/net/e100.c 2007-12-29 00:19:25.000000000 +0100
@@ -94,7 +94,7 @@
* enabled. 82557 pads with 7Eh, while the later controllers pad
* with 00h.
*
- * IV. Recieve
+ * IV. Receive
*
* The Receive Frame Area (RFA) comprises a ring of Receive Frame
* Descriptors (RFD) + data buffer, thus forming the simplified mode
@@ -113,7 +113,7 @@
* and Rx indication and re-allocation happen in the same context,
* therefore no locking is required. A software-generated interrupt
* is generated from the watchdog to recover from a failed allocation
- * senario where all Rx resources have been indicated and none re-
+ * scenario where all Rx resources have been indicated and none re-
* placed.
*
* V. Miscellaneous
@@ -251,6 +251,7 @@
mac_unknown = 0xFF,
};
+/* FIXME: these are unused: what the heck?? */
enum phy {
phy_100a = 0x000003E0,
phy_100c = 0x035002A8,
@@ -352,8 +353,12 @@
op_ewen = 0x13,
};
+enum phy_chips { NonSuchPhy=0, I82553AB, I82553C, I82503, DP83840, S80C240,
+ S80C24, I82555, DP83840A=10, };
+
enum eeprom_offsets {
eeprom_cnfg_mdix = 0x03,
+ eeprom_phy_iface = 0x06,
eeprom_id = 0x0A,
eeprom_config_asf = 0x0D,
eeprom_smbus_addr = 0x90,
@@ -553,6 +558,7 @@
multicast_all = (1 << 2),
wol_magic = (1 << 3),
ich_10h_workaround = (1 << 4),
+ phy_is_non_mii = (1 << 5),
} flags ____cacheline_aligned;
enum mac mac;
@@ -596,6 +602,11 @@
(void)ioread8(&nic->csr->scb.status);
}
+static inline int e100_phy_supports_mii(struct nic *nic)
+{
+ return ((nic->flags & phy_is_non_mii) == 0);
+}
+
static void e100_enable_irq(struct nic *nic)
{
unsigned long flags;
@@ -947,7 +958,7 @@
/* Quadwords to DMA into FIFO before starting frame transmit */
nic->tx_threshold = 0xE0;
- /* no interrupt for every tx completion, delay = 256us if not 557*/
+ /* no interrupt for every tx completion, delay = 256us if not 557 */
nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf |
((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
@@ -980,7 +991,8 @@
config->standard_stat_counter = 0x1; /* 1=standard, 0=extended */
config->rx_discard_short_frames = 0x1; /* 1=discard, 0=pass */
config->tx_underrun_retry = 0x3; /* # of underrun retries */
- config->mii_mode = 0x1; /* 1=MII mode, 0=503 mode */
+ if (e100_phy_supports_mii(nic))
+ config->mii_mode = 1; /* 1=MII mode, 0=i82503 mode */
config->pad10 = 0x6;
config->no_source_addr_insertion = 0x1; /* 1=no, 0=yes */
config->preamble_length = 0x2; /* 0=1, 1=3, 2=7, 3=15 bytes */
@@ -1350,6 +1362,42 @@
offsetof(struct mem, dump_buf));
}
+static int e100_phy_check_without_mii(struct nic *nic)
+{
+ u8 phy_type;
+ int without_mii;
+
+ phy_type = (nic->eeprom[eeprom_phy_iface] >> 8) & 0x0f;
+
+ switch (phy_type) {
+ case NonSuchPhy: /* Non-MII PHY; UNTESTED! */
+ case I82503: /* Non-MII PHY; UNTESTED! */
+ case S80C24: /* Non-MII PHY; tested and working */
+ {
+ /* paragraph from the FreeBSD driver, "FXP_PHY_80C24":
+ * The Seeq 80c24 AutoDUPLEX(tm) Ethernet Interface Adapter
+ * doesn't have a programming interface of any sort. The
+ * media is sensed automatically based on how the link partner
+ * is configured. This is, in essence, manual configuration.
+ */
+ DPRINTK(PROBE, INFO, "found MII-less i82503 or 80c24 or other PHY\n");
+ nic->mii.phy_id = 0; /* is this ok for an MII-less PHY? */
+
+ /* these might be needed for certain MII-less cards...
+ * nic->flags |= ich;
+ * nic->flags |= ich_10h_workaround; */
+
+ nic->flags |= phy_is_non_mii;
+ without_mii = 1;
+ }
+ break;
+ default:
+ without_mii = 0;
+ break;
+ }
+ return without_mii;
+}
+
#define NCONFIG_AUTO_SWITCH 0x0080
#define MII_NSC_CONG MII_RESV1
#define NSC_CONG_ENABLE 0x0100
@@ -1370,9 +1418,21 @@
if(!((bmcr == 0xFFFF) || ((stat == 0) && (bmcr == 0))))
break;
}
- DPRINTK(HW, DEBUG, "phy_addr = %d\n", nic->mii.phy_id);
- if(addr == 32)
- return -EAGAIN;
+ if(addr == 32) {
+ /* uhoh, no PHY detected: check whether we seem to be some
+ * weird, rare variant which is *known* to not have any MII.
+ * But do this AFTER MII checking only, since this does
+ * lookup of EEPROM values which may easily be unreliable. */
+ if (e100_phy_check_without_mii(nic))
+ return 0; /* simply return and hope for the best */
+ else {
+ /* for unknown cases log a fatal error */
+ DPRINTK(HW, ERR, "Failed to detect a PHY, aborting.\n");
+ return -EAGAIN;
+ }
+ }
+ else
+ DPRINTK(HW, DEBUG, "phy_addr = %d\n", nic->mii.phy_id);
/* Selected the phy and isolate the rest */
for(addr = 0; addr < 32; addr++) {
@@ -1490,7 +1550,7 @@
&s->complete;
/* Device's stats reporting may take several microseconds to
- * complete, so where always waiting for results of the
+ * complete, so we're always waiting for results of the
* previous command. */
if(*complete == le32_to_cpu(cuc_dump_reset_complete)) {
@@ -1568,19 +1628,25 @@
DPRINTK(TIMER, DEBUG, "right now = %ld\n", jiffies);
- /* mii library handles link maintenance tasks */
+ if (e100_phy_supports_mii(nic)) {
+ /* MII library handles link maintenance tasks */
- mii_ethtool_gset(&nic->mii, &cmd);
+ mii_ethtool_gset(&nic->mii, &cmd);
- if(mii_link_ok(&nic->mii) && !netif_carrier_ok(nic->netdev)) {
- DPRINTK(LINK, INFO, "link up, %sMbps, %s-duplex\n",
- cmd.speed == SPEED_100 ? "100" : "10",
- cmd.duplex == DUPLEX_FULL ? "full" : "half");
- } else if(!mii_link_ok(&nic->mii) && netif_carrier_ok(nic->netdev)) {
- DPRINTK(LINK, INFO, "link down\n");
- }
+ if(mii_link_ok(&nic->mii) && !netif_carrier_ok(nic->netdev)) {
+ DPRINTK(LINK, INFO, "link up, %sMbps, %s-duplex\n",
+ cmd.speed == SPEED_100 ? "100" : "10",
+ cmd.duplex == DUPLEX_FULL ? "full" : "half");
+ } else if(!mii_link_ok(&nic->mii) && netif_carrier_ok(nic->netdev)) {
+ DPRINTK(LINK, INFO, "link down\n");
+ }
- mii_check_link(&nic->mii);
+ mii_check_link(&nic->mii);
+ } else {
+ /* since MII API activates carrier internally,
+ * we have to do this manually for MII-less hardware */
+ netif_carrier_on(nic->netdev);
+ }
/* Software generated interrupt to recover from (rare) Rx
* allocation failure.
@@ -2180,6 +2246,9 @@
led_on_557 = 0x07,
};
+ if (!e100_phy_supports_mii(nic))
+ return;
+
nic->leds = (nic->leds & led_on) ? led_off :
(nic->mac < mac_82559_D101M) ? led_on_557 : led_on_559;
mdio_write(nic->netdev, nic->mii.phy_id, MII_LED_CONTROL, nic->leds);
@@ -2189,6 +2258,10 @@
static int e100_get_settings(struct net_device *netdev, struct ethtool_cmd *cmd)
{
struct nic *nic = netdev_priv(netdev);
+
+ if (!e100_phy_supports_mii(nic))
+ return -EINVAL;
+
return mii_ethtool_gset(&nic->mii, cmd);
}
@@ -2197,6 +2270,9 @@
struct nic *nic = netdev_priv(netdev);
int err;
+ if (!e100_phy_supports_mii(nic))
+ return -EINVAL;
+
mdio_write(netdev, nic->mii.phy_id, MII_BMCR, BMCR_RESET);
err = mii_ethtool_sset(&nic->mii, cmd);
e100_exec_cb(nic, NULL, e100_configure);
@@ -2281,12 +2357,20 @@
static int e100_nway_reset(struct net_device *netdev)
{
struct nic *nic = netdev_priv(netdev);
+
+ if (!e100_phy_supports_mii(nic))
+ return 0; /* "success" */
+
return mii_nway_restart(&nic->mii);
}
static u32 e100_get_link(struct net_device *netdev)
{
struct nic *nic = netdev_priv(netdev);
+
+ if (!e100_phy_supports_mii(nic))
+ return 1; /* "link ok" */
+
return mii_link_ok(&nic->mii);
}
@@ -2379,6 +2463,9 @@
struct nic *nic = netdev_priv(netdev);
int i, err;
+ if (!e100_phy_supports_mii(nic))
+ return;
+
memset(data, 0, E100_TEST_LEN * sizeof(u64));
data[0] = !mii_link_ok(&nic->mii);
data[1] = e100_eeprom_load(nic);
@@ -2409,6 +2496,9 @@
{
struct nic *nic = netdev_priv(netdev);
+ if (!e100_phy_supports_mii(nic))
+ return 0;
+
if(!data || data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ))
data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ);
mod_timer(&nic->blink_timer, jiffies);
@@ -2505,6 +2595,9 @@
{
struct nic *nic = netdev_priv(netdev);
+ if (!e100_phy_supports_mii(nic))
+ return -EINVAL;
+
return generic_mii_ioctl(&nic->mii, if_mii(ifr), cmd, NULL);
}
@@ -2791,17 +2884,17 @@
/**
* e100_io_error_detected - called when PCI error is detected.
* @pdev: Pointer to PCI device
- * @state: The current pci conneection state
+ * @state: The current pci connection state
*/
static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
- /* Similar to calling e100_down(), but avoids adpater I/O. */
+ /* Similar to calling e100_down(), but avoids adapter I/O. */
netdev->stop(netdev);
- /* Detach; put netif into state similar to hotplug unplug. */
+ /* Detach; put netif into a state similar to hotplug unplug. */
napi_enable(&nic->napi);
netif_device_detach(netdev);
pci_disable_device(pdev);
^ permalink raw reply
* Re: [PATCH] Make FC, FDDI, HIPPI and TR tristate
From: Adrian Bunk @ 2007-12-29 0:09 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: jgarzik, netdev
In-Reply-To: <Pine.LNX.4.64.0712282348280.29013@fbirervta.pbzchgretzou.qr>
On Sat, Dec 29, 2007 at 12:45:12AM +0100, Jan Engelhardt wrote:
> Turn CONFIG_FC, CONFIG_FDDI, CONFIG_HIPPI and CONFIG_TR into tristate
> so they can be built as modules. This will allow CONFIG_LLC to be
> built as a module too, overall reducing the core kernel image size.
>...
Just an example of code you have to fix if you do this:
$ grep -r "#ifdef CONFIG_TR" net/
net/802/sysctl_net_802.c:#ifdef CONFIG_TR
net/802/sysctl_net_802.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/atm/lec.c:#ifdef CONFIG_TR
net/ipv4/arp.c:#ifdef CONFIG_TR
net/llc/llc_output.c:#ifdef CONFIG_TR
net/sysctl_net.c:#ifdef CONFIG_TR
net/sysctl_net.c:#ifdef CONFIG_TR
$
For all variables you change to tristates you have to check every single
#ifdef in C code in the kernel using this variable whether it needs to
be fixed when it's modular.
You also have to check all usages of these variables in Kconfig files,
but my first impression is they are all OK.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] Make FC, FDDI, HIPPI and TR tristate
From: Jan Engelhardt @ 2007-12-29 0:41 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jgarzik, netdev
In-Reply-To: <20071229000930.GD9105@does.not.exist>
On Dec 29 2007 02:09, Adrian Bunk wrote:
>On Sat, Dec 29, 2007 at 12:45:12AM +0100, Jan Engelhardt wrote:
>> Turn CONFIG_FC, CONFIG_FDDI, CONFIG_HIPPI and CONFIG_TR into tristate
>> so they can be built as modules. This will allow CONFIG_LLC to be
>> built as a module too, overall reducing the core kernel image size.
>>...
>
>Just an example of code you have to fix if you do this:
>
>$ grep -r "#ifdef CONFIG_TR" net/
Ah, thank you for reminding me. For lec.c, would it be ok to do
#if defined(CONFIG_TR) || defined(CONFIG_TR_MODULE)
# define WITH_TR 1
#endif
at the top and then do a s/CONFIG_TR/WITH_TR/? Just so that the #ifdef
lines do not explode in redundance.
>net/802/sysctl_net_802.c:#ifdef CONFIG_TR
>net/802/sysctl_net_802.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/atm/lec.c:#ifdef CONFIG_TR
>net/ipv4/arp.c:#ifdef CONFIG_TR
>net/llc/llc_output.c:#ifdef CONFIG_TR
>net/sysctl_net.c:#ifdef CONFIG_TR
>net/sysctl_net.c:#ifdef CONFIG_TR
>$
^ permalink raw reply
* Re: [PATCH] Make FC, FDDI, HIPPI and TR tristate
From: Adrian Bunk @ 2007-12-29 0:52 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: jgarzik, netdev
In-Reply-To: <Pine.LNX.4.64.0712290140090.29013@fbirervta.pbzchgretzou.qr>
On Sat, Dec 29, 2007 at 01:41:23AM +0100, Jan Engelhardt wrote:
>
> On Dec 29 2007 02:09, Adrian Bunk wrote:
> >On Sat, Dec 29, 2007 at 12:45:12AM +0100, Jan Engelhardt wrote:
> >> Turn CONFIG_FC, CONFIG_FDDI, CONFIG_HIPPI and CONFIG_TR into tristate
> >> so they can be built as modules. This will allow CONFIG_LLC to be
> >> built as a module too, overall reducing the core kernel image size.
> >>...
> >
> >Just an example of code you have to fix if you do this:
> >
> >$ grep -r "#ifdef CONFIG_TR" net/
>
> Ah, thank you for reminding me. For lec.c, would it be ok to do
>
> #if defined(CONFIG_TR) || defined(CONFIG_TR_MODULE)
> # define WITH_TR 1
> #endif
>...
#if defined(CONFIG_TR) || (defined(CONFIG_TR_MODULE) && defined(MODULE))
Otherwise stuff like calling alloc_trdev() will cause build errors with
CONFIG_TR=m, CONFIG_ATM_LANE=y.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox