* Re: [PATCH v8] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: xeb @ 2010-08-21 10:09 UTC (permalink / raw)
To: netdev, Eric Dumazet
> > What is the next step ?
>
> David S. Miller review the thing, and if no problem remains, adds it to
> its net-next-2.6 tree
>
> You can check netdev list of current patches right here :
>
> http://patchwork.ozlabs.org/project/netdev/list/
>
> Your patch is already there ;)
Ah ok, thanks!
I see my mail's subject contains some unexpected symbols, maybe i have to
resend patch with cleaned subject ?
^ permalink raw reply
* Re: About unix_autobind()
From: Changli Gao @ 2010-08-21 12:34 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: netdev
In-Reply-To: <201008212101.IJG87048.QMOHFtSOVOLFFJ@I-love.SAKURA.ne.jp>
On Sat, Aug 21, 2010 at 8:01 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> I was browsing unix_autobind() and wondered what happens if all names in
> Unix domain socket's abstract namespace were in use.
>
> Below part is unix_autobind() from linux-2.6.36-rc1/net/unix/af_unix.c
>
> 710 retry:
> 711 addr->len = sprintf(addr->name->sun_path+1, "%05x", ordernum) + 1 + sizeof(short);
> 712 addr->hash = unix_hash_fold(csum_partial(addr->name, addr->len, 0));
> 713
> 714 spin_lock(&unix_table_lock);
> 715 ordernum = (ordernum+1)&0xFFFFF;
> 716
> 717 if (__unix_find_socket_byname(net, addr->name, addr->len, sock->type,
> 718 addr->hash)) {
> 719 spin_unlock(&unix_table_lock);
> 720 /* Sanity yield. It is unusual case, but yet... */
> 721 if (!(ordernum&0xFF))
> 722 yield();
> 723 goto retry;
> 724 }
>
> We can see that unix_autobind() allows 1048576 names.
>
> A machine with 256MB RAM:
>
> # cat /proc/sys/fs/file-max
> 24109
> # cat /proc/sys/fs/file-nr
> 608 0 24109
>
> A machine with 1736MB RAM:
>
> # cat /proc/sys/fs/file-max
> 174347
> # cat /proc/sys/fs/file-nr
> 96 0 174347
>
> /proc/sys/fs/file-max seems to be proportional to the amount of RAM.
> I don't have access to a machine with 10GB RAM (where /proc/sys/fs/file-max
> becomes larger than 1048576 by default). So, I manually set
>
> # echo 1050000 > /proc/sys/fs/file-max
>
> and executed below program as non-root user.
>
> ---------- Test program start ----------
> #include <sys/socket.h>
> #include <sys/un.h>
> #include <unistd.h>
>
> int main(int argc, char *argv[])
> {
> int i;
> for (i = 0; i < 1030; i++) {
> switch (fork()) {
> case 0:
> sleep(5);
> close(0);
> close(1);
> close(2);
> for (i = 0; i < 1024; i++) {
> struct sockaddr_un addr;
> int fd = socket(PF_UNIX, SOCK_DGRAM, 0);
> addr.sun_family = AF_UNIX;
> bind(fd, (struct sockaddr *) &addr, sizeof(addr.sun_family));
> }
> while (1)
> sleep(1000);
> case -1:
> write(1, "fork() failed\n", 14);
> return 1;
> }
> }
> return 0;
> }
> ---------- Test program end ----------
>
> If there is not enough memory, OOM killer was invoked. OOM killer killed
> /usr/sbin/httpd process rather than above test program. (Oops. Non-root user
> was able to terminate other user's processes via OOM killer.)
>
> If there is enough memory (I can't test it), OOM killer will not be invoked.
> But if all names were occupied, I guess subsequent unix_autobind() by other
> users will loop forever because it loops until a name becomes available.
> (I had to type "killall a.out" before above program occupies all names, for
> the machine became very dull due to unix_autobind().)
>
> Maybe some safeguard is wanted.
You can add a counter of the names, and check it before allocating a new name.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH v8] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: Changli Gao @ 2010-08-21 12:42 UTC (permalink / raw)
To: Dmitry Kozlov; +Cc: Eric Dumazet, netdev
In-Reply-To: <E1OmmB6-0005es-00.xeb-mail-ru@f299.mail.ru>
On Sat, Aug 21, 2010 at 7:24 PM, Dmitry Kozlov <xeb@mail.ru> wrote:
>> > What is the next step ?
>>
>> David S. Miller review the thing, and if no problem remains, adds it to
>> its net-next-2.6 tree
>>
>> You can check netdev list of current patches right here :
>>
>> http://patchwork.ozlabs.org/project/netdev/list/
>>
>> Your patch is already there ;)
>
> Ah ok, thanks!
>
> I see some unexpected symbols in mail's subject, maybe i have to resend mail with subject cleaned ?
from Documentation/SubmittingPatches
The "---" marker line serves the essential purpose of marking for patch
handling tools where the changelog message ends.
I think the following lines from your patch are also useful, and you'd
better move them above the "---" marker.
This patch introduces then pptp support to the linux kernel which
dramatically speeds up pptp vpn connections and decreases cpu usage in
comparison of existing user-space implementation (poptop/pptpclient).
There is accel-pptp project
(https://sourceforge.net/projects/accel-pptp/) to utilize this module,
it contains plugin for pppd to use pptp in client-mode and modified
pptpd (poptop) to build high-performance pptp NAS.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH] net: rps: fix the wrong network header pointer
From: Changli Gao @ 2010-08-21 16:13 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Changli Gao
__skb_get_rxhash() was broken after the commit:
commit bfb564e7391340638afe4ad67744a8f3858e7566
Author: Krishna Kumar <krkumar2@in.ibm.com>
Date: Wed Aug 4 06:15:52 2010 +0000
core: Factor out flow calculation from get_rps_cpu
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/core/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index da584f5..4d74d26 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2283,7 +2283,7 @@ __u32 __skb_get_rxhash(struct sk_buff *skb)
if (!pskb_may_pull(skb, sizeof(*ip) + nhoff))
goto done;
- ip = (struct iphdr *) skb->data + nhoff;
+ ip = (struct iphdr *) (skb->data + nhoff);
if (ip->frag_off & htons(IP_MF | IP_OFFSET))
ip_proto = 0;
else
@@ -2296,7 +2296,7 @@ __u32 __skb_get_rxhash(struct sk_buff *skb)
if (!pskb_may_pull(skb, sizeof(*ip6) + nhoff))
goto done;
- ip6 = (struct ipv6hdr *) skb->data + nhoff;
+ ip6 = (struct ipv6hdr *) (skb->data + nhoff);
ip_proto = ip6->nexthdr;
addr1 = (__force u32) ip6->saddr.s6_addr32[3];
addr2 = (__force u32) ip6->daddr.s6_addr32[3];
^ permalink raw reply related
* [PATCH] net_sched: cls_flow: add key rxhash
From: Changli Gao @ 2010-08-21 16:23 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, Changli Gao
We can use rxhash to classify the traffic into flows. As rxhash maybe
supplied by NIC or RPS, it is cheaper.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
include/linux/pkt_cls.h | 1 +
net/sched/cls_flow.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index 7f6ba86..defbde2 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -332,6 +332,7 @@ enum {
FLOW_KEY_SKUID,
FLOW_KEY_SKGID,
FLOW_KEY_VLAN_TAG,
+ FLOW_KEY_RXHASH,
__FLOW_KEY_MAX,
};
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index cd709f1..5b271a1 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -306,6 +306,11 @@ static u32 flow_get_vlan_tag(const struct sk_buff *skb)
return tag & VLAN_VID_MASK;
}
+static u32 flow_get_rxhash(struct sk_buff *skb)
+{
+ return skb_get_rxhash(skb);
+}
+
static u32 flow_key_get(struct sk_buff *skb, int key)
{
switch (key) {
@@ -343,6 +348,8 @@ static u32 flow_key_get(struct sk_buff *skb, int key)
return flow_get_skgid(skb);
case FLOW_KEY_VLAN_TAG:
return flow_get_vlan_tag(skb);
+ case FLOW_KEY_RXHASH:
+ return flow_get_rxhash(skb);
default:
WARN_ON(1);
return 0;
^ permalink raw reply related
* [PATCH] iproute2: tc: f_flow: add key rxhash
From: Changli Gao @ 2010-08-21 16:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, netdev, Changli Gao
We can use rxhash to classify the traffic into flows. As rxhash maybe
supplied by NIC or RPS, it is cheaper.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
include/linux/pkt_cls.h | 1 +
tc/f_flow.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index 7f6ba86..defbde2 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -332,6 +332,7 @@ enum {
FLOW_KEY_SKUID,
FLOW_KEY_SKGID,
FLOW_KEY_VLAN_TAG,
+ FLOW_KEY_RXHASH,
__FLOW_KEY_MAX,
};
diff --git a/tc/f_flow.c b/tc/f_flow.c
index 84b45c9..574253d 100644
--- a/tc/f_flow.c
+++ b/tc/f_flow.c
@@ -33,7 +33,7 @@ static void explain(void)
"KEY := [ src | dst | proto | proto-src | proto-dst | iif | priority | \n"
" mark | nfct | nfct-src | nfct-dst | nfct-proto-src | \n"
" nfct-proto-dst | rt-classid | sk-uid | sk-gid |\n"
-" vlan-tag ]\n"
+" vlan-tag | rxhash ]\n"
"OPS := [ or NUM | and NUM | xor NUM | rshift NUM | addend NUM ]\n"
"ID := X:Y\n"
);
@@ -57,6 +57,7 @@ static const char *flow_keys[FLOW_KEY_MAX+1] = {
[FLOW_KEY_SKUID] = "sk-uid",
[FLOW_KEY_SKGID] = "sk-gid",
[FLOW_KEY_VLAN_TAG] = "vlan-tag",
+ [FLOW_KEY_RXHASH] = "rxhash",
};
static int flow_parse_keys(__u32 *keys, __u32 *nkeys, char *argv)
^ permalink raw reply related
* Re: Fwd: Re: Linux r8169 interrupt patch
From: Rafael J. Wysocki @ 2010-08-21 20:03 UTC (permalink / raw)
To: Alex; +Cc: eric.dumazet, romieu, davem, adobriyan, jpirko, netdev,
linux-kernel
In-Reply-To: <4C6FBF5D.2070409@gmx.de>
On Saturday, August 21, 2010, Alex wrote:
> Hello gyus,
>
> I am writing to you, on case of the linux r8169 interrupt bug. Sergey
> gave me your addresses. I assume you can read all the neccessary
> informations below. Please reopen the thread at the bugtracker.
> I have several servers running with this chipset and driver. In my case,
> the problem is very critical. Network brokes even every day down. I can
> provide some testing if you would give me some patches or solution tips.
>
> Thanks in advance for your reply.
https://bugzilla.kernel.org/show_bug.cgi?id=15704 reopened.
Thanks,
Rafael
> -------- Original-Nachricht --------
> Betreff: Re: Linux r8169 interrupt patch
> Datum: Sat, 21 Aug 2010 14:14:36 +0300
> Von: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> An: alex <alexbtk@gmx.de>
> CC: sergey.senozhatsky@gmail.com
>
>
>
> On (08/20/10 22:24), alex wrote:
> > Date: Fri, 20 Aug 2010 22:24:20 +0200
> > From: alex<alexbtk@gmx.de>
> > To: sergey.senozhatsky@gmail.com
> > Subject: Linux r8169 interrupt patch
> > User-Agent: Opera Mail/10.61 (Win32)
> >
> > Hello Sergey,
> >
>
> Hello Alex,
>
> > I write to you, because of your conversation in this tracker:
> > http://patchwork.ozlabs.org/patch/47889/
> >
> > I have the same problem on the 2.6.33.7 kernel. I even upgraded
> > yesterday from 2.6.33.6, hoping to solve this bug. My kernel-panic
> > occurs even every day. That's very disgustig.
> > Here the trace:
> >
> > Aug 20 02:41:48 het1 kernel: [49652.963863] ------------[ cut here
> > ]------------
> > Aug 20 02:41:48 het1 kernel: [49652.964033] WARNING: at
> > net/sched/sch_generic.c:259 dev_watchdog+0x14d/0x208()
> > Aug 20 02:41:48 het1 kernel: [49652.964346] Hardware name: MS-7522
> > Aug 20 02:41:48 het1 kernel: [49652.964504] NETDEV WATCHDOG: eth0
> > (r8169): transmit queue 0 timed out
> > Aug 20 02:41:48 het1 kernel: [49652.964670] Pid: 71, comm:
> > sirq-timer/5 Not tainted 2.6.33.7-rt29 #1
> > Aug 20 02:41:48 het1 kernel: [49652.964835] Call Trace:
> > Aug 20 02:41:48 het1 kernel: [49652.964997] [<ffffffff812fcf32>] ?
> > dev_watchdog+0x14d/0x208
> > Aug 20 02:41:48 het1 kernel: [49652.965001] [<ffffffff8103233c>] ?
> > warn_slowpath_common+0x72/0x9e
> > Aug 20 02:41:48 het1 kernel: [49652.965004] [<ffffffff810323c4>] ?
> > warn_slowpath_fmt+0x51/0x59
> > Aug 20 02:41:48 het1 kernel: [49652.965008] [<ffffffff8102e474>] ?
> > try_to_wake_up+0x351/0x37f
> > Aug 20 02:41:48 het1 kernel: [49652.965012] [<ffffffff8106dce4>] ?
> > cpupri_set+0x10f/0x138
> > Aug 20 02:41:48 het1 kernel: [49652.965016] [<ffffffff812ebb40>] ?
> > netdev_drivername+0x3b/0x40
> > Aug 20 02:41:48 het1 kernel: [49652.965019] [<ffffffff812fcf32>] ?
> > dev_watchdog+0x14d/0x208
> > Aug 20 02:41:48 het1 kernel: [49652.965022] [<ffffffff81027e68>] ?
> > update_curr_rt+0x114/0x18b
> > Aug 20 02:41:48 het1 kernel: [49652.965025] [<ffffffff8102c972>] ?
> > finish_task_switch+0x4a/0xa3
> > Aug 20 02:41:48 het1 kernel: [49652.965028] [<ffffffff812fcde5>] ?
> > dev_watchdog+0x0/0x208
> > Aug 20 02:41:48 het1 kernel: [49652.965031] [<ffffffff8103b688>] ?
> > run_timer_softirq+0x20b/0x2a9
> > Aug 20 02:41:48 het1 kernel: [49652.965035] [<ffffffff81036b50>] ?
> > run_ksoftirqd+0x182/0x2a6
> > Aug 20 02:41:48 het1 kernel: [49652.965038] [<ffffffff810369ce>] ?
> > run_ksoftirqd+0x0/0x2a6
> > Aug 20 02:41:48 het1 kernel: [49652.965041] [<ffffffff81044759>] ?
> > kthread+0x79/0x81
> > Aug 20 02:41:48 het1 kernel: [49652.965044] [<ffffffff8102c972>] ?
> > finish_task_switch+0x4a/0xa3
> > Aug 20 02:41:48 het1 kernel: [49652.965048] [<ffffffff81003714>] ?
> > kernel_thread_helper+0x4/0x10
> > Aug 20 02:41:48 het1 kernel: [49652.965051] [<ffffffff810446e0>] ?
> > kthread+0x0/0x81
> > Aug 20 02:41:48 het1 kernel: [49652.965053] [<ffffffff81003710>] ?
> > kernel_thread_helper+0x0/0x10
> > Aug 20 02:41:48 het1 kernel: [49652.965055] ---[ end trace
> > 1af3434dfa0224f2 ]---
> >
> > I read that the patch fix the rx_interrupt(), but as I can see in my
> > case, he fails while sending the packets "transmit queue 0 timed
> > out".
> > My question now: Have you solved the problem? If yes, by applying the
> > patch?
> >
>
> No, unfortunately no. The problem is that this laptop (with r8169) is no longer
> available.
>
> We had a later conversation with Eric, and he had proposed several patches
> (none of them, however didn't solve the problem).
>
> So, I'll recommend to contanct Eric Dumazet<eric.dumazet@gmail.com>
> and "Rafael J. Wysocki"<rjw@sisk.pl> to reopen bug entry:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15704
> > Subject : [r8169] WARNING: at net/sched/sch_generic.c
> > Submitter : Sergey Senozhatsky<sergey.senozhatsky@gmail.com>
> > Date : 2010-03-31 10:21 (124 days old)
> > Message-ID :<20100331102142.GA3294@swordfish.minsk.epam.com>
> > References : http://marc.info/?l=linux-kernel&m=127003090406108&w=2
> >
>
> as now we have hardware to reproduce this.
>
> Maintainers of r8169 are:
> Francois Romieu<romieu@fr.zoreil.com>
> "David S. Miller"<davem@davemloft.net>
> Alexey Dobriyan<adobriyan@gmail.com>
> Jiri Pirko<jpirko@redhat.com>
> netdev@vger.kernel.org
> linux-kernel@vger.kernel.org
>
> So, please Cc them too.
>
>
> > Thanks for your answer in advance, I hope to hear from you soon.
> >
> > Best regards
> > Alexey Batyuk
> >
>
> All the best,
>
>
> Sergey
>
>
>
^ permalink raw reply
* Re: [PATCH] net_sched: cls_flow: add key rxhash
From: jamal @ 2010-08-21 21:41 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1282407795-3449-1-git-send-email-xiaosuo@gmail.com>
On Sun, 2010-08-22 at 00:23 +0800, Changli Gao wrote:
> We can use rxhash to classify the traffic into flows. As rxhash maybe
> supplied by NIC or RPS, it is cheaper.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Nice idea.
Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] iproute2: tc: f_flow: add key rxhash
From: jamal @ 2010-08-21 21:42 UTC (permalink / raw)
To: Changli Gao; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1282408201-3522-1-git-send-email-xiaosuo@gmail.com>
On Sun, 2010-08-22 at 00:30 +0800, Changli Gao wrote:
> We can use rxhash to classify the traffic into flows. As rxhash maybe
> supplied by NIC or RPS, it is cheaper.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v8] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: David Miller @ 2010-08-22 2:56 UTC (permalink / raw)
To: xeb; +Cc: eric.dumazet, netdev
In-Reply-To: <E1OmmB6-0005es-00.xeb-mail-ru@f299.mail.ru>
From: Dmitry Kozlov <xeb@mail.ru>
Date: Sat, 21 Aug 2010 15:24:00 +0400
>> > What is the next step ?
>>
>> David S. Miller review the thing, and if no problem remains, adds it to
>> its net-next-2.6 tree
>>
>> You can check netdev list of current patches right here :
>>
>> http://patchwork.ozlabs.org/project/netdev/list/
>>
>> Your patch is already there ;)
>
> Ah ok, thanks!
>
> I see some unexpected symbols in mail's subject, maybe i have to resend mail with subject cleaned ?
No need. Although in the future if you could post your patches
without koi8 encoding in the subject (that's the part of the subject
that patchwork can't parse properly) I would appreciate it.
^ permalink raw reply
* Re: [PATCH] net: rps: fix the wrong network header pointer
From: David Miller @ 2010-08-22 5:55 UTC (permalink / raw)
To: xiaosuo; +Cc: netdev
In-Reply-To: <1282407208-3367-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Sun, 22 Aug 2010 00:13:28 +0800
> __skb_get_rxhash() was broken after the commit:
>
> commit bfb564e7391340638afe4ad67744a8f3858e7566
> Author: Krishna Kumar <krkumar2@in.ibm.com>
> Date: Wed Aug 4 06:15:52 2010 +0000
>
> core: Factor out flow calculation from get_rps_cpu
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v8] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: David Miller @ 2010-08-22 6:01 UTC (permalink / raw)
To: xiaosuo; +Cc: xeb, eric.dumazet, netdev
In-Reply-To: <AANLkTimQwja4qF0X5gzG7u14+aXF_zVVZcwN5bHzku6V@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Sat, 21 Aug 2010 20:42:09 +0800
> I think the following lines from your patch are also useful, and you'd
> better move them above the "---" marker.
I'll take care of this when applying his patch.
Also this patch was against net-2.6 or even something
earlier, so there were many patch rejects I had to fix
up against include/linux/if_pppox.h when applying this
to net-next-2.6
^ permalink raw reply
* Re: [PATCH v8] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: David Miller @ 2010-08-22 6:03 UTC (permalink / raw)
To: xiaosuo; +Cc: xeb, eric.dumazet, netdev
In-Reply-To: <20100821.230129.71103230.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 21 Aug 2010 23:01:29 -0700 (PDT)
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Sat, 21 Aug 2010 20:42:09 +0800
>
>> I think the following lines from your patch are also useful, and you'd
>> better move them above the "---" marker.
>
> I'll take care of this when applying his patch.
>
> Also this patch was against net-2.6 or even something
> earlier, so there were many patch rejects I had to fix
> up against include/linux/if_pppox.h when applying this
> to net-next-2.6
It also doesn't even build against anything even remotely
recent:
drivers/net/pptp.c: In function ‘pptp_xmit’:
drivers/net/pptp.c:204: error: ‘struct rtable’ has no member named ‘u’
drivers/net/pptp.c:271: error: ‘struct rtable’ has no member named ‘u’
drivers/net/pptp.c:279: error: ‘struct rtable’ has no member named ‘u’
drivers/net/pptp.c:283: error: ‘struct rtable’ has no member named ‘u’
drivers/net/pptp.c:288: error: ‘struct rtable’ has no member named ‘u’
drivers/net/pptp.c: In function ‘pptp_connect’:
drivers/net/pptp.c:483: error: ‘struct rtable’ has no member named ‘u’
drivers/net/pptp.c:485: error: ‘struct rtable’ has no member named ‘u’
drivers/net/pptp.c: In function ‘pptp_init_module’:
drivers/net/pptp.c:675: error: implicit declaration of function ‘__vmalloc’
drivers/net/pptp.c:676: warning: assignment makes pointer from integer without a cast
drivers/net/pptp.c:707: error: implicit declaration of function ‘vfree’
That means this patch is against a tree which is at least two
releases old. We got rid of the 'u' member of struct rtable
quite some time ago.
Ugh, I'll fix this up, but after _8_, yes _EIGHT_, iterations of this
patch set the amount of problems that remain is completely
unbelievable.
^ permalink raw reply
* WARN with 3c905 boomerang NIC
From: Doug Nazar @ 2010-08-22 6:35 UTC (permalink / raw)
To: linux-kernel, netdev
Since de85d99eb7b595f6751550184b94c1e2f74a828b (netpoll: Fix RCU
usage) I've been getting the follow warning:
Aug 20 22:33:26 dryad kernel: [ 64.263065] ------------[ cut here
]------------
Aug 20 22:33:26 dryad kernel: [ 64.263089] WARNING: at
/usr/src/linux/kernel/softirq.c:143 local_bh_enable+0x58/0x82()
Aug 20 22:33:26 dryad kernel: [ 64.263095] Hardware name: OptiPlex GX240
Aug 20 22:33:26 dryad kernel: [ 64.263099] Modules linked in:
rpcsec_gss_krb5 softdog snd_intel8x0 snd_ac97_codec 8250_pnp ac97_bu
Aug 20 22:33:26 dryad kernel: [ 64.263234] Pid: 5892, comm:
runscript.sh Not tainted 2.6.36-rc1-00133-g47ade1d #43
Aug 20 22:33:26 dryad kernel: [ 64.263238] Call Trace:
Aug 20 22:33:26 dryad kernel: [ 64.263251] [<c12a492e>] ?
printk+0x18/0x1a
Aug 20 22:33:26 dryad kernel: [ 64.263263] [<c102a015>]
warn_slowpath_common+0x67/0x8e
Aug 20 22:33:26 dryad kernel: [ 64.263271] [<c102ee76>] ?
local_bh_enable+0x58/0x82
Aug 20 22:33:26 dryad kernel: [ 64.263277] [<c102ee76>] ?
local_bh_enable+0x58/0x82
Aug 20 22:33:26 dryad kernel: [ 64.263285] [<c102a059>]
warn_slowpath_null+0x1d/0x1f
Aug 20 22:33:26 dryad kernel: [ 64.263292] [<c102ee76>]
local_bh_enable+0x58/0x82
Aug 20 22:33:26 dryad kernel: [ 64.263301] [<c12399e5>]
netif_rx+0x14f/0x172
Aug 20 22:33:26 dryad kernel: [ 64.263315] [<e20e8f0f>]
boomerang_rx+0x27a/0x42f [3c59x]
Aug 20 22:33:26 dryad kernel: [ 64.263328] [<c10a369b>] ?
path_put+0x20/0x23
Aug 20 22:33:26 dryad kernel: [ 64.263342] [<e20eadfb>]
boomerang_interrupt+0xd9/0x2b7 [3c59x]
Aug 20 22:33:26 dryad kernel: [ 64.263361] [<c105651c>]
handle_IRQ_event+0x3e/0x13e
Aug 20 22:33:26 dryad kernel: [ 64.263369] [<c1057c6e>]
handle_fasteoi_irq+0x3c/0x89
Aug 20 22:33:26 dryad kernel: [ 64.263378] [<c1004e58>]
handle_irq+0x18/0x30
Aug 20 22:33:26 dryad kernel: [ 64.263385] [<c10048cb>] do_IRQ+0x34/0x97
Aug 20 22:33:26 dryad kernel: [ 64.263392] [<c10037a9>]
common_interrupt+0x29/0x30
Aug 20 22:33:26 dryad kernel: [ 64.263398] ---[ end trace
511646352388ce9c ]---
The card is an:
02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 78)
Doug
^ permalink raw reply
* Re: [PATCH] net_sched: cls_flow: add key rxhash
From: David Miller @ 2010-08-22 6:41 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, netdev
In-Reply-To: <1282426892.3532.5.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Sat, 21 Aug 2010 17:41:32 -0400
> On Sun, 2010-08-22 at 00:23 +0800, Changli Gao wrote:
>> We can use rxhash to classify the traffic into flows. As rxhash maybe
>> supplied by NIC or RPS, it is cheaper.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Nice idea.
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
Sometimes the simplest patches are the best :-)
Applied, thanks Changli!
^ permalink raw reply
* Re: [PATCH] irda: fix a race in irlan_eth_xmit()
From: David Miller @ 2010-08-22 7:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: samuel, netdev
In-Reply-To: <1282297893.2484.14.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 20 Aug 2010 11:51:33 +0200
> [PATCH net-next-2.6] irda: use net_device_stats from struct net_device
>
> struct net_device has its own struct net_device_stats member, so use
> this one instead of a private copy in the irlan_cb struct.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] atl1c: use net_device_stats from struct net_device
From: David Miller @ 2010-08-22 7:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, Jie.Yang
In-Reply-To: <1282308916.2484.26.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 20 Aug 2010 14:55:16 +0200
> struct net_device has its own struct net_device_stats member, so use
> this one instead of a private copy in the atl1c_adapter struct.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] amd8111e: use net_device_stats from struct net_device
From: David Miller @ 2010-08-22 7:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1282309703.2484.30.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 20 Aug 2010 15:08:23 +0200
> struct net_device has its own struct net_device_stats member, so use
> this one instead of a private copy in the amd8111e_priv struct.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re[2]: [PATCH v8] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: Dmitry Kozlov @ 2010-08-22 7:17 UTC (permalink / raw)
To: David Miller; +Cc: xiaosuo, eric.dumazet, netdev
In-Reply-To: <20100821.230309.104050634.davem@davemloft.net>
> From: David Miller <davem@davemloft.net>
> Date: Sat, 21 Aug 2010 23:01:29 -0700 (PDT)
>
> > From: Changli Gao <xiaosuo@gmail.com>
> > Date: Sat, 21 Aug 2010 20:42:09 +0800
> >
> >> I think the following lines from your patch are also useful, and you'd
> >> better move them above the "---" marker.
> >
> > I'll take care of this when applying his patch.
> >
> > Also this patch was against net-2.6 or even something
> > earlier, so there were many patch rejects I had to fix
> > up against include/linux/if_pppox.h when applying this
> > to net-next-2.6
>
> It also doesn't even build against anything even remotely
> recent:
>
> drivers/net/pptp.c: In function ?pptp_xmit?:
> drivers/net/pptp.c:204: error: ?struct rtable? has no member named ?u?
> drivers/net/pptp.c:271: error: ?struct rtable? has no member named ?u?
> drivers/net/pptp.c:279: error: ?struct rtable? has no member named ?u?
> drivers/net/pptp.c:283: error: ?struct rtable? has no member named ?u?
> drivers/net/pptp.c:288: error: ?struct rtable? has no member named ?u?
> drivers/net/pptp.c: In function ?pptp_connect?:
> drivers/net/pptp.c:483: error: ?struct rtable? has no member named ?u?
> drivers/net/pptp.c:485: error: ?struct rtable? has no member named ?u?
> drivers/net/pptp.c: In function ?pptp_init_module?:
> drivers/net/pptp.c:675: error: implicit declaration of function ?__vmalloc?
> drivers/net/pptp.c:676: warning: assignment makes pointer from integer without a cast
> drivers/net/pptp.c:707: error: implicit declaration of function ?vfree?
>
> That means this patch is against a tree which is at least two
> releases old. We got rid of the 'u' member of struct rtable
> quite some time ago.
>
> Ugh, I'll fix this up, but after _8_, yes _EIGHT_, iterations of this
> patch set the amount of problems that remain is completely
> unbelievable.
Sorry, maybe it is wrong, but i did patch using repository git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git, HEAD at a63ecd835f075b21d7d5cef9580447f5fbb36263.
Have i update and resend it for net-next-2.6 ?
^ permalink raw reply
* Re: [PATCH v8] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: David Miller @ 2010-08-22 7:39 UTC (permalink / raw)
To: xeb; +Cc: xiaosuo, eric.dumazet, netdev
In-Reply-To: <E1On4oL-0008EI-00.xeb-mail-ru@f230.mail.ru>
From: Dmitry Kozlov <xeb@mail.ru>
Date: Sun, 22 Aug 2010 11:17:45 +0400
>> From: David Miller <davem@davemloft.net>
>> Date: Sat, 21 Aug 2010 23:01:29 -0700 (PDT)
>>
>> Ugh, I'll fix this up, but after _8_, yes _EIGHT_, iterations of this
>> patch set the amount of problems that remain is completely
>> unbelievable.
>
> Sorry, maybe it is wrong, but i did patch using repository git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git, HEAD at a63ecd835f075b21d7d5cef9580447f5fbb36263.
> Have i update and resend it for net-next-2.6 ?
I said "I'll fix this up" which means I'll take care of everything.
You should always make all patches against the tree that it will be
applied to.
^ permalink raw reply
* Re: WARN with 3c905 boomerang NIC
From: David Miller @ 2010-08-22 7:46 UTC (permalink / raw)
To: nazard.lkml; +Cc: linux-kernel, netdev, herbert
In-Reply-To: <4C70C516.5020404@gmail.com>
From: Doug Nazar <nazard.lkml@gmail.com>
Date: Sun, 22 Aug 2010 02:35:02 -0400
> Since de85d99eb7b595f6751550184b94c1e2f74a828b (netpoll: Fix RCU
> usage) I've been getting the follow warning:
> Aug 20 22:33:26 dryad kernel: [ 64.263065] ------------[ cut here
> ]------------
> Aug 20 22:33:26 dryad kernel: [ 64.263089] WARNING: at
> /usr/src/linux/kernel/softirq.c:143 local_bh_enable+0x58/0x82()
> Aug 20 22:33:26 dryad kernel: [ 64.263095] Hardware name: OptiPlex
> GX240
> Aug 20 22:33:26 dryad kernel: [ 64.263099] Modules linked in:
> rpcsec_gss_krb5 softdog snd_intel8x0 snd_ac97_codec 8250_pnp ac97_bu
> Aug 20 22:33:26 dryad kernel: [ 64.263234] Pid: 5892, comm:
> runscript.sh Not tainted 2.6.36-rc1-00133-g47ade1d #43
> Aug 20 22:33:26 dryad kernel: [ 64.263238] Call Trace:
> Aug 20 22:33:26 dryad kernel: [ 64.263251] [<c12a492e>] ?
> printk+0x18/0x1a
> Aug 20 22:33:26 dryad kernel: [ 64.263263] [<c102a015>]
> warn_slowpath_common+0x67/0x8e
> Aug 20 22:33:26 dryad kernel: [ 64.263271] [<c102ee76>] ?
> local_bh_enable+0x58/0x82
> Aug 20 22:33:26 dryad kernel: [ 64.263277] [<c102ee76>] ?
> local_bh_enable+0x58/0x82
> Aug 20 22:33:26 dryad kernel: [ 64.263285] [<c102a059>]
> warn_slowpath_null+0x1d/0x1f
> Aug 20 22:33:26 dryad kernel: [ 64.263292] [<c102ee76>]
> local_bh_enable+0x58/0x82
> Aug 20 22:33:26 dryad kernel: [ 64.263301] [<c12399e5>]
> netif_rx+0x14f/0x172
> Aug 20 22:33:26 dryad kernel: [ 64.263315] [<e20e8f0f>]
> boomerang_rx+0x27a/0x42f [3c59x]
...
Yes we know about this and are working on a solution.
^ permalink raw reply
* Re: IPsec: Why do pfkey_getspi and xfrm_alloc_userspi call xfrm_find_acq_byseq?
From: David Miller @ 2010-08-22 7:53 UTC (permalink / raw)
To: christophe.gouault; +Cc: netdev
In-Reply-To: <4C6D29B9.5070403@6wind.com>
From: Christophe Gouault <christophe.gouault@6wind.com>
Date: Thu, 19 Aug 2010 14:55:21 +0200
> The call to xfrm_find_acq_byseq() by the pfkey_getspi() and
> xfrm_alloc_userspi() functions is quite costly and proves to entail
> scalability issues when performing thousands of IKE negotiations with
> racoon (from ipsec-tools distribution) or charon (from strongswan
> distribution).
>
> Removing this call in the kernel drastically accelerates the
> processing and does not seem to entail functional problems.
>
> For now, I don't see the point of this call. I need to understand its
> purpose, because I'm highly tempted to simply remove it.
First of all, removing a function because you don't understand
why it's there is rarely a good idea :-)
I think the semantics require that we check for existing ACQUIRE
state entries before we allocate an SPI.
The likelyhood of breaking something if you remove the call is very
high.
^ permalink raw reply
* Re: [patch] tokenring: remove unneeded NULL checks
From: David Miller @ 2010-08-22 7:54 UTC (permalink / raw)
To: error27; +Cc: netdev, kernel-janitors
In-Reply-To: <20100819100438.GC6674@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Thu, 19 Aug 2010 12:04:38 +0200
> "fw_entry" is always non-NULL at this point and anyway
> release_firmware() handles NULL parameters.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied, thanks Dan.
^ permalink raw reply
* [PATCH net-2.6 1/6] be2net: fix net-snmp error because of wrong packet stats
From: Ajit Khaparde @ 2010-08-22 9:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Wrong packet statistics for multicast Rx was causing net-snmp error messages
every 15 seconds. Instead of picking the multicast stats from hardware,
maintaining it in the driver itself.
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
drivers/net/benet/be.h | 1 +
drivers/net/benet/be_ethtool.c | 1 +
drivers/net/benet/be_hw.h | 7 +++++--
drivers/net/benet/be_main.c | 15 +++++++++++----
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index 99197bd..53306bf 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -181,6 +181,7 @@ struct be_drvr_stats {
u64 be_rx_bytes_prev;
u64 be_rx_pkts;
u32 be_rx_rate;
+ u32 be_rx_mcast_pkt;
/* number of non ether type II frames dropped where
* frame len > length field of Mac Hdr */
u32 be_802_3_dropped_frames;
diff --git a/drivers/net/benet/be_ethtool.c b/drivers/net/benet/be_ethtool.c
index cd16243..13f0abb 100644
--- a/drivers/net/benet/be_ethtool.c
+++ b/drivers/net/benet/be_ethtool.c
@@ -60,6 +60,7 @@ static const struct be_ethtool_stat et_stats[] = {
{DRVSTAT_INFO(be_rx_events)},
{DRVSTAT_INFO(be_tx_compl)},
{DRVSTAT_INFO(be_rx_compl)},
+ {DRVSTAT_INFO(be_rx_mcast_pkt)},
{DRVSTAT_INFO(be_ethrx_post_fail)},
{DRVSTAT_INFO(be_802_3_dropped_frames)},
{DRVSTAT_INFO(be_802_3_malformed_frames)},
diff --git a/drivers/net/benet/be_hw.h b/drivers/net/benet/be_hw.h
index 5d38046..a2ec5df 100644
--- a/drivers/net/benet/be_hw.h
+++ b/drivers/net/benet/be_hw.h
@@ -167,8 +167,11 @@
#define FLASH_FCoE_BIOS_START_g3 (13631488)
#define FLASH_REDBOOT_START_g3 (262144)
-
-
+/************* Rx Packet Type Encoding **************/
+#define BE_UNICAST_PACKET 0
+#define BE_MULTICAST_PACKET 1
+#define BE_BROADCAST_PACKET 2
+#define BE_RSVD_PACKET 3
/*
* BE descriptors: host memory data structures whose formats
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 74e146f..a5a24e6 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -247,6 +247,7 @@ void netdev_stats_update(struct be_adapter *adapter)
dev_stats->tx_packets = drvr_stats(adapter)->be_tx_pkts;
dev_stats->rx_bytes = drvr_stats(adapter)->be_rx_bytes;
dev_stats->tx_bytes = drvr_stats(adapter)->be_tx_bytes;
+ dev_stats->multicast = drvr_stats(adapter)->be_rx_mcast_pkt;
/* bad pkts received */
dev_stats->rx_errors = port_stats->rx_crc_errors +
@@ -294,7 +295,6 @@ void netdev_stats_update(struct be_adapter *adapter)
/* no space available in linux */
dev_stats->tx_dropped = 0;
- dev_stats->multicast = port_stats->rx_multicast_frames;
dev_stats->collisions = 0;
/* detailed tx_errors */
@@ -848,7 +848,7 @@ static void be_rx_rate_update(struct be_adapter *adapter)
}
static void be_rx_stats_update(struct be_adapter *adapter,
- u32 pktsize, u16 numfrags)
+ u32 pktsize, u16 numfrags, u8 pkt_type)
{
struct be_drvr_stats *stats = drvr_stats(adapter);
@@ -856,6 +856,9 @@ static void be_rx_stats_update(struct be_adapter *adapter,
stats->be_rx_frags += numfrags;
stats->be_rx_bytes += pktsize;
stats->be_rx_pkts++;
+
+ if (pkt_type == BE_MULTICAST_PACKET)
+ stats->be_rx_mcast_pkt++;
}
static inline bool do_pkt_csum(struct be_eth_rx_compl *rxcp, bool cso)
@@ -925,9 +928,11 @@ static void skb_fill_rx_data(struct be_adapter *adapter,
u16 rxq_idx, i, j;
u32 pktsize, hdr_len, curr_frag_len, size;
u8 *start;
+ u8 pkt_type;
rxq_idx = AMAP_GET_BITS(struct amap_eth_rx_compl, fragndx, rxcp);
pktsize = AMAP_GET_BITS(struct amap_eth_rx_compl, pktsize, rxcp);
+ pkt_type = AMAP_GET_BITS(struct amap_eth_rx_compl, cast_enc, rxcp);
page_info = get_rx_page_info(adapter, rxq_idx);
@@ -993,7 +998,7 @@ static void skb_fill_rx_data(struct be_adapter *adapter,
BUG_ON(j > MAX_SKB_FRAGS);
done:
- be_rx_stats_update(adapter, pktsize, num_rcvd);
+ be_rx_stats_update(adapter, pktsize, num_rcvd, pkt_type);
}
/* Process the RX completion indicated by rxcp when GRO is disabled */
@@ -1060,6 +1065,7 @@ static void be_rx_compl_process_gro(struct be_adapter *adapter,
u32 num_rcvd, pkt_size, remaining, vlanf, curr_frag_len;
u16 i, rxq_idx = 0, vid, j;
u8 vtm;
+ u8 pkt_type;
num_rcvd = AMAP_GET_BITS(struct amap_eth_rx_compl, numfrags, rxcp);
/* Is it a flush compl that has no data */
@@ -1070,6 +1076,7 @@ static void be_rx_compl_process_gro(struct be_adapter *adapter,
vlanf = AMAP_GET_BITS(struct amap_eth_rx_compl, vtp, rxcp);
rxq_idx = AMAP_GET_BITS(struct amap_eth_rx_compl, fragndx, rxcp);
vtm = AMAP_GET_BITS(struct amap_eth_rx_compl, vtm, rxcp);
+ pkt_type = AMAP_GET_BITS(struct amap_eth_rx_compl, cast_enc, rxcp);
/* vlanf could be wrongly set in some cards.
* ignore if vtm is not set */
@@ -1125,7 +1132,7 @@ static void be_rx_compl_process_gro(struct be_adapter *adapter,
vlan_gro_frags(&eq_obj->napi, adapter->vlan_grp, vid);
}
- be_rx_stats_update(adapter, pkt_size, num_rcvd);
+ be_rx_stats_update(adapter, pkt_size, num_rcvd, pkt_type);
}
static struct be_eth_rx_compl *be_rx_compl_get(struct be_adapter *adapter)
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-2.6 2/6] be2net: fix a bug in UE detection logic
From: Ajit Khaparde @ 2010-08-22 9:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The ONLINE registers can return 0xFFFFFFFF on more than one
occassion. On systems that care, reading these registers could
lead to problems.
So the new code decides that the ASIC has encountered and error
by reading the UE_STATUS_LOW/HIGH registers. AND them with
the mask values and a non-zero result indicates an error.
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
drivers/net/benet/be_main.c | 32 ++++++++------------------------
1 files changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index a5a24e6..6eda7a0 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1750,26 +1750,7 @@ static int be_poll_tx_mcc(struct napi_struct *napi, int budget)
return 1;
}
-static inline bool be_detect_ue(struct be_adapter *adapter)
-{
- u32 online0 = 0, online1 = 0;
-
- pci_read_config_dword(adapter->pdev, PCICFG_ONLINE0, &online0);
-
- pci_read_config_dword(adapter->pdev, PCICFG_ONLINE1, &online1);
-
- if (!online0 || !online1) {
- adapter->ue_detected = true;
- dev_err(&adapter->pdev->dev,
- "UE Detected!! online0=%d online1=%d\n",
- online0, online1);
- return true;
- }
-
- return false;
-}
-
-void be_dump_ue(struct be_adapter *adapter)
+void be_detect_dump_ue(struct be_adapter *adapter)
{
u32 ue_status_lo, ue_status_hi, ue_status_lo_mask, ue_status_hi_mask;
u32 i;
@@ -1786,6 +1767,11 @@ void be_dump_ue(struct be_adapter *adapter)
ue_status_lo = (ue_status_lo & (~ue_status_lo_mask));
ue_status_hi = (ue_status_hi & (~ue_status_hi_mask));
+ if (ue_status_lo || ue_status_hi) {
+ adapter->ue_detected = true;
+ dev_err(&adapter->pdev->dev, "UE Detected!!\n");
+ }
+
if (ue_status_lo) {
for (i = 0; ue_status_lo; ue_status_lo >>= 1, i++) {
if (ue_status_lo & 1)
@@ -1821,10 +1807,8 @@ static void be_worker(struct work_struct *work)
adapter->rx_post_starved = false;
be_post_rx_frags(adapter);
}
- if (!adapter->ue_detected) {
- if (be_detect_ue(adapter))
- be_dump_ue(adapter);
- }
+ if (!adapter->ue_detected)
+ be_detect_dump_ue(adapter);
schedule_delayed_work(&adapter->work, msecs_to_jiffies(1000));
}
--
1.7.0.4
^ permalink raw reply related
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