* [PATCH NEXT 0/2]qlcnic: bug fixes
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi
Sending series of 2 minor fixes.
Apply them on net-next.
-Amit
^ permalink raw reply
* [PATCH NEXT 1/2] qlcnic: fix bandwidth check
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Rajesh Borundia, Amit Kumar Salecha
In-Reply-To: <1279956266-23445-1-git-send-email-amit.salecha@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
Fix maximum and minmum bandwith value.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index e189477..fad8e9a 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1074,8 +1074,8 @@ struct qlcnic_eswitch {
/* Return codes for Error handling */
#define QL_STATUS_INVALID_PARAM -1
-#define MAX_BW 10000
-#define MIN_BW 100
+#define MAX_BW 100
+#define MIN_BW 1
#define MAX_VLAN_ID 4095
#define MIN_VLAN_ID 2
#define MAX_TX_QUEUES 1
@@ -1083,8 +1083,7 @@ struct qlcnic_eswitch {
#define DEFAULT_MAC_LEARN 1
#define IS_VALID_VLAN(vlan) (vlan >= MIN_VLAN_ID && vlan <= MAX_VLAN_ID)
-#define IS_VALID_BW(bw) (bw >= MIN_BW && bw <= MAX_BW \
- && (bw % 100) == 0)
+#define IS_VALID_BW(bw) (bw >= MIN_BW && bw <= MAX_BW)
#define IS_VALID_TX_QUEUES(que) (que > 0 && que <= MAX_TX_QUEUES)
#define IS_VALID_RX_QUEUES(que) (que > 0 && que <= MAX_RX_QUEUES)
#define IS_VALID_MODE(mode) (mode == 0 || mode == 1)
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 2/2] qlcnic: diag fixes
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Amit Kumar Salecha
In-Reply-To: <1279956266-23445-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
o Loopback not supported for virtual function.
o netif_device_attach was missing in error path from
qlcnic_diag_alloc_res
Acked-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 2 --
drivers/net/qlcnic/qlcnic_ethtool.c | 10 ++++++++--
drivers/net/qlcnic/qlcnic_main.c | 19 +------------------
3 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index fad8e9a..9703893 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1301,8 +1301,6 @@ struct qlcnic_nic_template {
int (*get_mac_addr) (struct qlcnic_adapter *, u8*);
int (*config_bridged_mode) (struct qlcnic_adapter *, u32);
int (*config_led) (struct qlcnic_adapter *, u32, u32);
- int (*set_ilb_mode) (struct qlcnic_adapter *);
- void (*clear_ilb_mode) (struct qlcnic_adapter *);
int (*start_firmware) (struct qlcnic_adapter *);
};
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 7d6558e..ecce364 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -678,6 +678,12 @@ static int qlcnic_loopback_test(struct net_device *netdev)
int max_sds_rings = adapter->max_sds_rings;
int ret;
+ if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC) {
+ dev_warn(&adapter->pdev->dev, "Loopback test is not supported"
+ "for non privilege function\n");
+ return 0;
+ }
+
if (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
return -EIO;
@@ -685,13 +691,13 @@ static int qlcnic_loopback_test(struct net_device *netdev)
if (ret)
goto clear_it;
- ret = adapter->nic_ops->set_ilb_mode(adapter);
+ ret = qlcnic_set_ilb_mode(adapter);
if (ret)
goto done;
ret = qlcnic_do_ilb_test(adapter);
- adapter->nic_ops->clear_ilb_mode(adapter);
+ qlcnic_clear_ilb_mode(adapter);
done:
qlcnic_diag_free_res(netdev, max_sds_rings);
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f1f7acf..3002a7f 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -107,8 +107,6 @@ static void qlcnic_config_indev_addr(struct net_device *dev, unsigned long);
static int qlcnic_start_firmware(struct qlcnic_adapter *);
static void qlcnic_dev_set_npar_ready(struct qlcnic_adapter *);
-static void qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *);
-static int qlcnicvf_set_ilb_mode(struct qlcnic_adapter *);
static int qlcnicvf_config_led(struct qlcnic_adapter *, u32, u32);
static int qlcnicvf_config_bridged_mode(struct qlcnic_adapter *, u32);
static int qlcnicvf_start_firmware(struct qlcnic_adapter *);
@@ -381,8 +379,6 @@ static struct qlcnic_nic_template qlcnic_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnic_config_bridged_mode,
.config_led = qlcnic_config_led,
- .set_ilb_mode = qlcnic_set_ilb_mode,
- .clear_ilb_mode = qlcnic_clear_ilb_mode,
.start_firmware = qlcnic_start_firmware
};
@@ -390,8 +386,6 @@ static struct qlcnic_nic_template qlcnic_vf_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnicvf_config_bridged_mode,
.config_led = qlcnicvf_config_led,
- .set_ilb_mode = qlcnicvf_set_ilb_mode,
- .clear_ilb_mode = qlcnicvf_clear_ilb_mode,
.start_firmware = qlcnicvf_start_firmware
};
@@ -1181,6 +1175,7 @@ int qlcnic_diag_alloc_res(struct net_device *netdev, int test)
ret = qlcnic_fw_create_ctx(adapter);
if (ret) {
+ netif_device_attach(netdev);
qlcnic_detach(adapter);
return ret;
}
@@ -2841,18 +2836,6 @@ qlcnicvf_config_led(struct qlcnic_adapter *adapter, u32 state, u32 rate)
return -EOPNOTSUPP;
}
-static int
-qlcnicvf_set_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return -EOPNOTSUPP;
-}
-
-static void
-qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return;
-}
-
static ssize_t
qlcnic_store_bridged_mode(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
--
1.6.0.2
^ permalink raw reply related
* Re: Linux 2.6.35-rc6
From: Jiri Slaby @ 2010-07-24 8:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linus Torvalds, Linux Kernel Mailing List, Russell King,
James Bottomley, David Miller, netdev, John W. Linville,
Michal Marek, Greg KH
In-Reply-To: <20100723112142.f698394e.sfr@canb.auug.org.au>
On 07/23/2010 03:21 AM, Stephen Rothwell wrote:
> On Thu, 22 Jul 2010 12:26:13 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
> I actually hope/think that this is going to be the last -rc. Things
>> have been pretty quiet, and while this -rc has more commits than -rc5
>> had, it's not by a large amount, nor does it look scary to me. So
>> there doesn't seem to be any point in dragging out the release any
>> more, unless we find something new that calls for it.
>
> I have no idea how important this stuff is, but I still have the
> following in linux-next that are (in theory) destined for v2.6.35:
Hi, and probably this one as well (introduced in rc1):
http://lkml.org/lkml/2010/7/9/287
Tim Gardner
i915: Use the correct mask to detect i830 aperture size.
--
js
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: walter harms @ 2010-07-24 8:59 UTC (permalink / raw)
To: Dan Carpenter
Cc: Joe Perches, Lennert Buytenhek, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <20100723221514.GJ26313@bicker>
Dan Carpenter schrieb:
> On Fri, Jul 23, 2010 at 06:30:22PM +0200, walter harms wrote:
>> this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
>> with this version:
>>
>> if (!pd ) {
>> msp->t_clk = 133000000;
>> msp->tx_csum_limit = 9 * 1024;
>> }
>> else
>> {
>> msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
>> msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
>> }
>>
>
> But then instead of 2 magic numbers we would have 4. :/
>
Yes it can be shorten,
msp->t_clk = 133000000;
msp->tx_csum_limit = 9 * 1024;
if (pd) {
if (pd->t_clk) msp->t_clk = pd->t_clk ;
if (pd->tx_csum_limit) sp->tx_csum_limit = pd->tx_csum_limit;
}
pd->t_clk
i was thinking about that in my first posting but i have the feeling that ppl
tend to overlook the "if (pd)" but in this case it is important since the
behavier is different.
IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit have usefull
values than adding a check but this is up to the maintainer.
re,
wh
^ permalink raw reply
* e1000e crashes with 2.6.34.x and ThinkPad T60
From: Marc Haber @ 2010-07-24 9:26 UTC (permalink / raw)
To: Linux Kernel Developers, Linux Kernel Network Developers
Hi,
I have a new notebook, a Thinkpad T60, which is freezing in random
intervals (like 30 minutes to two days) as long as I am using the
on-board wired ethernet interface, which is an e1000e, [8086:109a]. As
long as I keep using the WLAN, the system runs for weeks despite
frequent suspend/resume cycles etc. The crashes seem really to be tied
to using the wired ethernet. This is a hard freeze, with nothing
happening on the system, only a long push on the power button helps.
Additionally, sometimes, probably after suspend/resume, the wired
ethernet does not come up properly again, ip addr claims "NO CARRIER"
even if the LEDs on the interface and on the switch claim that there
was a link. No packets are received by the interface when it's at this
stage.
Both issues appear with 2.6.34 and 2.6.34.1. I didn't try any of these
issues with an older kernel, 2.6.34 was already out when I started
using the T60.
To rule out defective hardware, I have tried with a second T60, with
the same results.
Full dmesg and lspci-nn attached, please say if you need more.
Greetings
Marc
P.S.: Please Cc: me on replies, both linux-kernel and netdev are too
big for me to timely follow. I am subscribed to both lists, but a Cc
helps in getting a faster reply.
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* Winning Notification!!!
From: A .Baloteli @ 2010-07-24 10:26 UTC (permalink / raw)
To: tel.inters.p.a
Dear Client
You have been sent a payment order, here is your payment information:
PAYMENT N°: 965412070
PAYMENT APPROVAL DATE: 04/06/2010
PAYMENT REF: VD06/EUSA/2010
PAYMENT VALUE: EUR 225.500.00 (Euro)
In order to receive you payment please confirm you identification in our
verification office below:
Voda Telecom Inc.
Betolini 14 - Point 7002
Villa Ugo Ojetti 32, 00137
e-mail: voda.com2010@gmail.it
Payment Logistic Officer: Andrea M. Baloteli (Mr)
Copy the Payment Verification Information's above and submit to the above
office and officer. After we receive your email confirmation, your payment
would be processed we will send you the payment paying bank for cashing
your funds.
REASON OF PAYMENT: This e-mail draw is to promote the official
communication network for the 2010 World Cup and our network's
Anniversary.
On behalf of the Board kindly, accept our warmest congratulations.
Regards.
MANAGEMENT.
All information is strictly confidential and will only be used for the
purpose to which it is been requested.. Finally, all funds should be
claimed by their respective beneficiaries, not later than 12 days after
notification. Failure to do so will result to outright cancellation.
Copyright © 2008 telecom.it;Privacy & P.IVA...
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Ben Greear @ 2010-07-24 13:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, NetDev
In-Reply-To: <1279949024.2451.43.camel@edumazet-laptop>
On 07/23/2010 10:23 PM, Eric Dumazet wrote:
> Le vendredi 23 juillet 2010 à 16:14 -0700, Ben Greear a écrit :
>> Some time back, someone added some memset() calls to pktgen to
>> keep from leaking memory contents to the network.
>>
>
> Well, someone might be me ;)
>
>> At least in our modified version of pktgen, this caused about 25%
>> performance degradation when sending 1514 byte pkts (multi-pkt == 0)
>> on a pair of 10G ports. It was easy enough to comment these memset
>> calls out of course.
>>
>> I don't mind if this patch stays in,
>> but thought I'd post my findings in case anyone else wonders why
>> their pktgen slowed down...
>>
>
> Thanks Ben
>
> Here is a patch adding a new pktgen flag, so that admins can choose
> speed if they want to, if they dont use clone_skb to reduce skb setup
> costs.
It looks fine to me, though I have not actually tested it.
> +Very fast mode
> +==============
> +One knob to get very fast pktgen is the UNSAFE flag :
> +
> +flag UNSAFE
> +
> +This ask to pktgen to not clear content of packets before sending them.
> +Note this is a security problem, and should be used only if really needed.
> +If packets are cloned (clone_skb 1000), clearing data cost is amortized so
> +this UNSAFE mode is less interesting.
I think most users of pktgen wouldn't be too concerned about leaking
memory content to the network. It's a root-only test tool that can easily
saturate most networks and do horrible things like overflow switch CAM tables
by randomizing source/dest macs etc. So, this warning might could be a bit
more descriptive of how it is a security problem "arbitrary contents of memory can be
sent across the network and may be sniffed by devices on the network, potentially
revealing private information such as passwords and application data for applications
running on the machine running pktgen" instead of telling folks not to use it unless it's
really needed.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Eric Dumazet @ 2010-07-24 14:13 UTC (permalink / raw)
To: Ben Greear; +Cc: David Miller, NetDev
In-Reply-To: <4C4AE80F.1040406@candelatech.com>
Le samedi 24 juillet 2010 à 06:18 -0700, Ben Greear a écrit :
> I think most users of pktgen wouldn't be too concerned about leaking
> memory content to the network. It's a root-only test tool that can easily
> saturate most networks and do horrible things like overflow switch CAM tables
> by randomizing source/dest macs etc. So, this warning might could be a bit
> more descriptive of how it is a security problem "arbitrary contents of memory can be
> sent across the network and may be sniffed by devices on the network, potentially
> revealing private information such as passwords and application data for applications
> running on the machine running pktgen" instead of telling folks not to use it unless it's
> really needed.
Most of the horrible things you mention are not related to the memset()
thing, arent they ?
Being root means : "I am a trusted user on this machine, and as such,
must know a bit what security means".
It doesnt mean : "I am allowed to steal passwords, credit card numbers,
from gentle users. I am allowed to blow up the LAN with billions of evil
frames". Still, pktgen is there and might be used by a fool.
The "UNSAFE" label should be more than enough to warn the fool admin ;)
Note this "UNSAFE" thing is really bad. Nowhere in the kernel we are
allowed to make this sort of thing : No special mmap() flag asking
kernel to give non cleared memory pages, even to root user.
I am not sure David will accept the patch !
Anyway, as I said, if you want to saturate a 10Gb+ network with pktgen,
you probably need clone_skb ?
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Ben Greear @ 2010-07-24 15:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, NetDev
In-Reply-To: <1279980795.2451.157.camel@edumazet-laptop>
On 07/24/2010 07:13 AM, Eric Dumazet wrote:
> Le samedi 24 juillet 2010 à 06:18 -0700, Ben Greear a écrit :
>
>> I think most users of pktgen wouldn't be too concerned about leaking
>> memory content to the network. It's a root-only test tool that can easily
>> saturate most networks and do horrible things like overflow switch CAM tables
>> by randomizing source/dest macs etc. So, this warning might could be a bit
>> more descriptive of how it is a security problem "arbitrary contents of memory can be
>> sent across the network and may be sniffed by devices on the network, potentially
>> revealing private information such as passwords and application data for applications
>> running on the machine running pktgen" instead of telling folks not to use it unless it's
>> really needed.
>
> Most of the horrible things you mention are not related to the memset()
> thing, arent they ?
>
>
> Being root means : "I am a trusted user on this machine, and as such,
> must know a bit what security means".
>
> It doesnt mean : "I am allowed to steal passwords, credit card numbers,
> from gentle users. I am allowed to blow up the LAN with billions of evil
> frames". Still, pktgen is there and might be used by a fool.
Out of curiosity, couldn't root just use gdb, strace or similar means to
get access to user's programs? Or add a simple module to the kernel to
dump memory pages for that matter?
It would seem to me that this UNSAFE flag is only to protect root users from
accidentally sharing their own private memory accidentally.
> The "UNSAFE" label should be more than enough to warn the fool admin ;)
>
> Note this "UNSAFE" thing is really bad. Nowhere in the kernel we are
> allowed to make this sort of thing : No special mmap() flag asking
> kernel to give non cleared memory pages, even to root user.
Ok, I don't mind either way. I have a bunch of hacks to pktgen in
my tree already, so one more isn't a big deal.
> Anyway, as I said, if you want to saturate a 10Gb+ network with pktgen,
> you probably need clone_skb ?
I can get bi-directional 9.6Gbps or so using 1514 byte pkts and clone-skb == 0
on two ports using Intel 82599 10G NIC on core-i7 3.33Ghz (6GT/s pci-e bus).
(with memsets commented out). This is around 40Gbps total data across the network
interfaces.
Some day I'll get a quad or 6-port 10G and see what it can do :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH NEXT 2/2] qlcnic: diag fixes
From: Gustavo F. Padovan @ 2010-07-24 16:53 UTC (permalink / raw)
To: amit.salecha; +Cc: davem, netdev, ameen.rahman
In-Reply-To: <1279956266-23445-3-git-send-email-amit.salecha@qlogic.com>
Hi Amit,
* amit.salecha@qlogic.com <amit.salecha@qlogic.com> [2010-07-24 00:24:26 -0700]:
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> o Loopback not supported for virtual function.
> o netif_device_attach was missing in error path from
> qlcnic_diag_alloc_res
This second part should be a new commit actually. It fixes a different
thing.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: Lennert Buytenhek @ 2010-07-24 19:00 UTC (permalink / raw)
To: walter harms
Cc: Dan Carpenter, Joe Perches, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <4C4AAB5B.2050901@bfs.de>
On Sat, Jul 24, 2010 at 10:59:07AM +0200, walter harms wrote:
> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
> have usefull values than adding a check but this is up to the maintainer.
I don't see the point of that at all. We check against zero to see
whether the caller bothered to fill in the field at all, but if the
caller wants to pass in bogus values, that's up to the caller.
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Michael S. Tsirkin @ 2010-07-24 19:14 UTC (permalink / raw)
To: Tejun Heo
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <4C48B664.9000109@kernel.org>
On Thu, Jul 22, 2010 at 11:21:40PM +0200, Tejun Heo wrote:
> Hello,
>
> On 07/22/2010 05:58 PM, Michael S. Tsirkin wrote:
> > All the tricky barrier pairing made me uncomfortable. So I came up with
> > this on top (untested): if we do all operations under the spinlock, we
> > can get by without barriers and atomics. And since we need the lock for
> > list operations anyway, this should have no paerformance impact.
> >
> > What do you think?
>
> I've created kthread_worker in wq#for-next tree and already converted
> ivtv to use it. Once this lands in mainline, I think converting vhost
> to use it would be better choice. kthread worker code uses basically
> the same logic used in the vhost_workqueue code but is better
> organized and documented. So, I think it would be better to stick
> with the original implementation, as otherwise we're likely to just
> decrease test coverage without much gain.
>
> http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
Sure, if we keep using workqueue. But I'd like to investigate this
direction a bit more because there's discussion to switching from kthread to
regular threads altogether.
> > @@ -151,37 +161,37 @@ static void vhost_vq_reset(struct vhost_dev *dev,
> > static int vhost_worker(void *data)
> > {
> > struct vhost_dev *dev = data;
> > - struct vhost_work *work;
> > + struct vhost_work *work = NULL;
> >
> > -repeat:
> > - set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/ kthread_stop */
> > + for (;;) {
> > + set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/ kthread_stop */
> >
> > - if (kthread_should_stop()) {
> > - __set_current_state(TASK_RUNNING);
> > - return 0;
> > - }
> > + if (kthread_should_stop()) {
> > + __set_current_state(TASK_RUNNING);
> > + return 0;
> > + }
> >
> > - work = NULL;
> > - spin_lock_irq(&dev->work_lock);
> > - if (!list_empty(&dev->work_list)) {
> > - work = list_first_entry(&dev->work_list,
> > - struct vhost_work, node);
> > - list_del_init(&work->node);
> > - }
> > - spin_unlock_irq(&dev->work_lock);
> > + spin_lock_irq(&dev->work_lock);
> > + if (work) {
> > + work->done_seq = work->queue_seq;
> > + if (work->flushing)
> > + wake_up_all(&work->done);
>
> I don't think doing this before executing the function is correct,
Well, before I execute the function work is NULL, so this is skipped.
Correct?
> so
> you'll have to release the lock, execute the function, regrab the lock
> and then do the flush processing.
>
> Thanks.
It's done in the loop, so I thought we can reuse the locking
done for the sake of processing the next work item.
Makes sense?
> --
> tejun
^ permalink raw reply
* [PATCH 0/2] ks8842: Support for passing flags via platform data and 100 Mbps support
From: Richard Röjfors @ 2010-07-24 20:25 UTC (permalink / raw)
To: netdev; +Cc: davem
To follow are two patches
* Introduce a flags field in the platform data.
* removes flow control and advertise 100Mbps
^ permalink raw reply
* [PATCH 1/2] ks8842: Add flags in the platform data
From: Richard Röjfors @ 2010-07-24 20:25 UTC (permalink / raw)
To: netdev; +Cc: davem
Previously the driver did a write to a timberdale specific register.
Timberdale is a FPGA used in some hardware setup which communicates
to the ks8842 via VLB.
A flag field is introduced where it is possible to pass a flag if
the ks8842 is connected via timberdale. Otherwise the driver won't
try to access timberdale registers.
If the timberdale flag is passed the driver also acks interrupts
in the FPGA, this is a bit more polite to the FPGA state machine.
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
---
diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
index 0be9261..48e4582 100644
--- a/drivers/net/ks8842.c
+++ b/drivers/net/ks8842.c
@@ -33,7 +33,13 @@
#define DRV_NAME "ks8842"
/* Timberdale specific Registers */
-#define REG_TIMB_RST 0x1c
+#define REG_TIMB_RST 0x1c
+#define REG_TIMB_FIFO 0x20
+#define REG_TIMB_ISR 0x24
+#define REG_TIMB_IER 0x28
+#define REG_TIMB_IAR 0x2C
+#define REQ_TIMB_DMA_RESUME 0x30
+
/* KS8842 registers */
@@ -121,6 +127,7 @@ struct ks8842_adapter {
spinlock_t lock; /* spinlock to be interrupt safe */
struct work_struct timeout_work;
struct net_device *netdev;
+ u8 flags;
};
static inline void ks8842_select_bank(struct ks8842_adapter *adapter, u16 bank)
@@ -195,12 +202,15 @@ static void ks8842_reset(struct ks8842_adapter *adapter)
/* The KS8842 goes haywire when doing softare reset
* a work around in the timberdale IP is implemented to
* do a hardware reset instead
- ks8842_write16(adapter, 3, 1, REG_GRR);
- msleep(10);
- iowrite16(0, adapter->hw_addr + REG_GRR);
- */
- iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
- msleep(20);
+ */
+ if (adapter->flags & KS8842_FLAGS_TIMB) {
+ iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
+ msleep(20);
+ } else {
+ ks8842_write16(adapter, 3, 1, REG_GRR);
+ msleep(10);
+ iowrite16(0, adapter->hw_addr + REG_GRR);
+ }
}
static void ks8842_update_link_status(struct net_device *netdev,
@@ -463,6 +473,10 @@ void ks8842_tasklet(unsigned long arg)
/* Ack */
ks8842_write16(adapter, 18, isr, REG_ISR);
+ /* Ack in the timberdale IP as well */
+ if (adapter->flags & KS8842_FLAGS_TIMB)
+ iowrite32(0x1, adapter->hw_addr + REG_TIMB_IAR);
+
if (!netif_running(netdev))
return;
@@ -687,6 +701,8 @@ static int __devinit ks8842_probe(struct platform_device *pdev)
/* Check if a mac address was given */
i = netdev->addr_len;
if (pdata) {
+ adapter->flags = pdata->flags;
+
for (i = 0; i < netdev->addr_len; i++)
if (pdata->macaddr[i] != 0)
break;
diff --git a/include/linux/ks8842.h b/include/linux/ks8842.h
index da0341b..12b4bda 100644
--- a/include/linux/ks8842.h
+++ b/include/linux/ks8842.h
@@ -21,14 +21,18 @@
#include <linux/if_ether.h>
+#define KS8842_FLAGS_TIMB 0x01
+
/**
* struct ks8842_platform_data - Platform data of the KS8842 network driver
* @macaddr: The MAC address of the device, set to all 0:s to use the on in
* the chip.
+ * @flags: Flags to the drivers which configures the hardware setup
*
*/
struct ks8842_platform_data {
u8 macaddr[ETH_ALEN];
+ u8 flags;
};
#endif
^ permalink raw reply related
* [PATCH 2/2] ks8842: Advertise 100Mbps
From: Richard Röjfors @ 2010-07-24 20:25 UTC (permalink / raw)
To: netdev; +Cc: davem
This patch makes sure that the ks8842 also advertises 100Mbps
during autonegotiation.
If the ks8842 is connected via VLB, the bus is slower
than 100Mbps ethernet. It turned out using flow control
in the chip was not optimal, so that non default setting
is removed.
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
---
diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
index 48e4582..ea22f29 100644
--- a/drivers/net/ks8842.c
+++ b/drivers/net/ks8842.c
@@ -254,10 +254,8 @@ static void ks8842_reset_hw(struct ks8842_adapter *adapter)
/* Enable QMU Transmit flow control / transmit padding / Transmit CRC */
ks8842_write16(adapter, 16, 0x000E, REG_TXCR);
- /* enable the receiver, uni + multi + broadcast + flow ctrl
- + crc strip */
- ks8842_write16(adapter, 16, 0x8 | 0x20 | 0x40 | 0x80 | 0x400,
- REG_RXCR);
+ /* enable the receiver, uni + multi + broadcast + crc strip */
+ ks8842_write16(adapter, 16, 0x8 | 0x20 | 0x40 | 0x80, REG_RXCR);
/* TX frame pointer autoincrement */
ks8842_write16(adapter, 17, 0x4000, REG_TXFDPR);
@@ -274,13 +272,11 @@ static void ks8842_reset_hw(struct ks8842_adapter *adapter)
/* enable no excessive collison drop */
ks8842_enable_bits(adapter, 32, 1 << 3, REG_SGCR2);
- /* Enable port 1 force flow control / back pressure / transmit / recv */
- ks8842_write16(adapter, 48, 0x1E07, REG_P1CR2);
+ /* Enable port 1 / back pressure / transmit / recv */
+ ks8842_write16(adapter, 48, 0xE07, REG_P1CR2);
/* restart port auto-negotiation */
ks8842_enable_bits(adapter, 49, 1 << 13, REG_P1CR4);
- /* only advertise 10Mbps */
- ks8842_clear_bits(adapter, 49, 3 << 2, REG_P1CR4);
/* Enable the transmitter */
ks8842_enable_tx(adapter);
^ permalink raw reply related
* [PATCH 2.6.35-rc1] net-next: Fix an overflow bug in vmxnet3 Tx descriptor
From: Bhavesh Davda @ 2010-07-25 0:43 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
---
Fix an overflow bug in vmxnet3 Tx descriptor
This patch fixes a bug where a 16K buffer on a Tx descriptor was overflowing
into the 'gen' bit in the descriptor thereby corrupting the descriptor and
stalling the transmit ring.
Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
Signed-off-by: Matthew Delco <delcoM@vmware.com>
Signed-off-by: Ronghua Zhang <ronghua@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 9d64186..abe0ff5 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -664,8 +664,13 @@ vmxnet3_map_pkt(struct sk_buff *skb, struct vmxnet3_tx_ctx *ctx,
while (len) {
u32 buf_size;
- buf_size = len > VMXNET3_MAX_TX_BUF_SIZE ?
- VMXNET3_MAX_TX_BUF_SIZE : len;
+ if (len < VMXNET3_MAX_TX_BUF_SIZE) {
+ buf_size = len;
+ dw2 |= len;
+ } else {
+ buf_size = VMXNET3_MAX_TX_BUF_SIZE;
+ /* spec says that for TxDesc.len, 0 == 2^14 */
+ }
tbi = tq->buf_info + tq->tx_ring.next2fill;
tbi->map_type = VMXNET3_MAP_SINGLE;
@@ -673,13 +678,13 @@ vmxnet3_map_pkt(struct sk_buff *skb, struct vmxnet3_tx_ctx *ctx,
skb->data + buf_offset, buf_size,
PCI_DMA_TODEVICE);
- tbi->len = buf_size; /* this automatically convert 2^14 to 0 */
+ tbi->len = buf_size;
gdesc = tq->tx_ring.base + tq->tx_ring.next2fill;
BUG_ON(gdesc->txd.gen == tq->tx_ring.gen);
gdesc->txd.addr = cpu_to_le64(tbi->dma_addr);
- gdesc->dword[2] = cpu_to_le32(dw2 | buf_size);
+ gdesc->dword[2] = cpu_to_le32(dw2);
gdesc->dword[3] = 0;
dev_dbg(&adapter->netdev->dev,
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 762a6a7..2121c73 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -68,10 +68,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.13.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.14.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000B00
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000E00
/*
^ permalink raw reply related
* [PATCH] 3c59x: Add ethtool WOL support
From: Andrew O. Shadoura @ 2010-07-25 2:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Netdev mailing list, Linux kernel mailing list
This patch adds wrappers for ethtool to get or set wake-on-LAN
setting without re-inserting the kernel module.
Signed-off-by: Andrew O. Shadoura <andrew@beldisplaytech.com>
---
Hello.
I've actually tested this patch on a machine with a network
card that's idenfied by lsusb as "3c905C-TX/TX-M", and it seems
to work.
---
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index d75803e..a452dfe 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -2909,6 +2909,36 @@ static void vortex_get_drvinfo(struct net_device *dev,
}
}
+static void vortex_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct vortex_private *vp = netdev_priv(dev);
+
+ spin_lock_irq(&vp->lock);
+ wol->supported = WAKE_MAGIC;
+
+ wol->wolopts = 0;
+ if (vp->enable_wol)
+ wol->wolopts |= WAKE_MAGIC;
+ spin_unlock_irq(&vp->lock);
+}
+
+static int vortex_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct vortex_private *vp = netdev_priv(dev);
+ if (wol->wolopts & ~WAKE_MAGIC)
+ return -EINVAL;
+
+ spin_lock_irq(&vp->lock);
+ if (wol->wolopts & WAKE_MAGIC)
+ vp->enable_wol = 1;
+ else
+ vp->enable_wol = 0;
+ acpi_set_WOL(dev);
+ spin_unlock_irq(&vp->lock);
+
+ return 0;
+}
+
static const struct ethtool_ops vortex_ethtool_ops = {
.get_drvinfo = vortex_get_drvinfo,
.get_strings = vortex_get_strings,
@@ -2920,6 +2950,8 @@ static const struct ethtool_ops vortex_ethtool_ops = {
.set_settings = vortex_set_settings,
.get_link = ethtool_op_get_link,
.nway_reset = vortex_nway_reset,
+ .get_wol = vortex_get_wol,
+ .set_wol = vortex_set_wol,
};
#ifdef CONFIG_PCI
--
WBR, Andrew
^ permalink raw reply related
* Re: [PATCH net-next-2.6] bonding: set device in RLB ARP packet handler
From: David Miller @ 2010-07-25 3:38 UTC (permalink / raw)
To: andy; +Cc: fubar, greg.edwards, netdev, bonding-devel, linux-kernel
In-Reply-To: <20100723202648.GU7497@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Fri, 23 Jul 2010 16:26:48 -0400
> On Fri, Jul 23, 2010 at 01:02:04PM -0700, Jay Vosburgh wrote:
>>
>> From: Greg Edwards <greg.edwards@hp.com>
>>
>> After:
>>
>> commit 6146b1a4da98377e4abddc91ba5856bef8f23f1e
>> Author: Jay Vosburgh <fubar@us.ibm.com>
>> Date: Tue Nov 4 17:51:15 2008 -0800
>>
>> bonding: Fix ALB mode to balance traffic on VLANs
>>
>> the dev field in the RLB ARP packet handler was set to NULL to wildcard
>> and accommodate balancing VLANs on top of bonds.
>>
>> This has the side-effect of the packet handler being called against
>> other, non RLB-enabled bonds, and a kernel oops results when it tries to
>> dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be
>> set for those bonds, e.g. active-backup.
>>
>> With the __netif_receive_skb() changes from:
>>
>> commit 1f3c8804acba841b5573b953f5560d2683d2db0d
>> Author: Andy Gospodarek <andy@greyhouse.net>
>> Date: Mon Dec 14 10:48:58 2009 +0000
>>
>> bonding: allow arp_ip_targets on separate vlans to use arp validation
>>
>> frames received on VLANs correctly make their way to the bond's handler,
>> so we no longer need to wildcard the device.
>>
>> The oops can be reproduced by:
>>
>> modprobe bonding
>>
>> echo active-backup > /sys/class/net/bond0/bonding/mode
>> echo 100 > /sys/class/net/bond0/bonding/miimon
>> ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
>> echo +eth0 > /sys/class/net/bond0/bonding/slaves
>> echo +eth1 > /sys/class/net/bond0/bonding/slaves
>>
>> echo +bond1 > /sys/class/net/bonding_masters
>> echo balance-alb > /sys/class/net/bond1/bonding/mode
>> echo 100 > /sys/class/net/bond1/bonding/miimon
>> ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
>> echo +eth2 > /sys/class/net/bond1/bonding/slaves
>> echo +eth3 > /sys/class/net/bond1/bonding/slaves
>>
>> Pass some traffic on bond0. Boom.
>>
>> [ Tested, behaves as advertised. I do not believe a test of the bonding
>> mode is necessary, as there is no race between the packet handler and
>> the bonding mode changing (the mode can only change when the device is
>> closed). Also updated the log message to include the reproduction and
>> full commit ids. -J ]
>>
>> Signed-off-by: Greg Edwards <greg.edwards@hp.com>
>> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>
> Acked-by: Andy Gospodarek <andy@greyhouse.net>
This seems serious enough to put into net-2.6, so that's where I applied
it.
Thanks!
^ permalink raw reply
* Re: [PATCH NEXT 1/2] qlcnic: fix bandwidth check
From: David Miller @ 2010-07-25 3:42 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, rajesh.borundia
In-Reply-To: <1279956266-23445-2-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Sat, 24 Jul 2010 00:24:25 -0700
> From: Rajesh Borundia <rajesh.borundia@qlogic.com>
>
> Fix maximum and minmum bandwith value.
>
> Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] qlcnic: diag fixes
From: David Miller @ 2010-07-25 3:42 UTC (permalink / raw)
To: gustavo; +Cc: amit.salecha, netdev, ameen.rahman
In-Reply-To: <20100724165343.GC9787@vigoh>
From: "Gustavo F. Padovan" <gustavo@padovan.org>
Date: Sat, 24 Jul 2010 13:53:43 -0300
> Hi Amit,
>
> * amit.salecha@qlogic.com <amit.salecha@qlogic.com> [2010-07-24 00:24:26 -0700]:
>
>> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>>
>> o Loopback not supported for virtual function.
>> o netif_device_attach was missing in error path from
>> qlcnic_diag_alloc_res
>
> This second part should be a new commit actually. It fixes a different
> thing.
Agreed.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: fix ethtool stats
From: David Miller @ 2010-07-25 3:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, eric.dumazet
In-Reply-To: <20100723234252.18203.56378.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Jul 2010 16:44:21 -0700
> From: Eric Dumazet <eric.dumazet@gmail.com>
>
> In latest changes about 64bit stats on 32bit arches,
> [commit 28172739f0a276eb8 (net: fix 64 bit counters on 32 bit arches)],
> I missed ixgbe uses a bit of magic in its ixgbe_gstrings_stats
> definition.
>
> IXGBE_NETDEV_STAT() must now assume offsets relative to
> rtnl_link_stats64, not relative do dev->stats.
>
> As a bonus, we also get 64bit stats on ethtool -S
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Stephen Ko <stephen.s.ko@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH for-2.6.35] tun: avoid BUG, dump packet on GSO errors
From: David Miller @ 2010-07-25 3:47 UTC (permalink / raw)
To: herbert; +Cc: mst, netdev
In-Reply-To: <20100722130512.GA29088@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Jul 2010 21:05:12 +0800
> Michael S. Tsirkin <mst@redhat.com> wrote:
>> There are still some LRO cards that cause GSO errors in tun,
>> and BUG on this is an unfriendly way to tell the admin
>> to disable LRO.
>>
>> Further, experience shows we might have more GSO bugs lurking.
>> See https://bugzilla.kernel.org/show_bug.cgi?id=16413
>> as a recent example.
>> dumping a packet will make it easier to figure it out.
>>
>> Replace BUG with warning+dump+drop the packet to make
>> GSO errors in tun less critical and easier to debug.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Tested-by: Alex Unigovsky <unik@compot.ru>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add attribute to indicate hw address assignment type
From: David Miller @ 2010-07-25 3:50 UTC (permalink / raw)
To: sassmann
Cc: bhutchings, abadea, netdev, linux-kernel, gospo, gregory.v.rose,
alexander.h.duyck, leedom, harald
In-Reply-To: <4C485A0C.7020500@redhat.com>
From: Stefan Assmann <sassmann@redhat.com>
Date: Thu, 22 Jul 2010 16:47:40 +0200
> On 22.07.2010 16:07, Ben Hutchings wrote:
>> On Thu, 2010-07-22 at 14:50 +0200, Stefan Assmann wrote:
>>> On 21.07.2010 15:54, Ben Hutchings wrote:
>>>> On Wed, 2010-07-21 at 10:10 +0200, Stefan Assmann wrote:
>>>>> I put Alex' idea into code for further discussion, keeping the names
>>>>> mentioned here until we agree on the scope of this attribute. When we
>>>>> have settled I'll post a patch with proper patch description.
>>>> [...]
>>>>
>>>> Just a little nitpick: I think it would be clearer to use a more
>>>> specific term like 'address source' or 'address assignment type' rather
>>>> than 'address type'.
>>>
>>> Here's a proposal for the final patch.
>>
>> Looks good, but...
...
>> ...why '|=' and not '='?
>
> The intention is to use addr_assign_type as a bit field.
>
> Okay it it might not make too much sense to 'steal' a random MAC
> address but in case we add more types later it might get useful.
I think the patch is good enough to go into net-next-2.6 as-is, anything
remaining is a refinement or one sort or another.
So applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [patch 2.6.35] WiMAX pull request
From: David Miller @ 2010-07-25 3:52 UTC (permalink / raw)
To: inaky; +Cc: netdev, wimax, inaky.perez-gonzalez
In-Reply-To: <cover.1279843906.git.inaky.perez-gonzalez@intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Thu, 22 Jul 2010 17:15:13 -0700
> The following changes since commit a385a53e659b35ebee604889e21c40e5c336941f:
> Inaky Perez-Gonzalez (1):
> wimax/i2400m: fix missing endian correction read in fw loader
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git wimax-2.6.35.y
>
> Patches follow for reviewing convenience.
>
> Alexey Shvetsov (1):
> wimax/i2400m: Add PID & VID for Intel WiMAX 6250
Pulled, thanks.
^ 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