* Re: SYSFS "errors"
From: Felipe Balbi @ 2013-02-19 10:12 UTC (permalink / raw)
To: Alexander Stein; +Cc: Greg KH, Felipe Balbi, Linux Kernel Mailing List, netdev
In-Reply-To: <2721602.qxhJKWaVil@ws-stein>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
+netdev
On Tue, Feb 19, 2013 at 08:41:47AM +0100, Alexander Stein wrote:
> On Monday 18 February 2013 09:49:16, Greg KH wrote:
> > > Invalid argument - /sys/devices/virtual/net/lo/speed
> > > Invalid argument - /sys/devices/virtual/net/lo/duplex
>
> This is even true for ethernet devices which do not have a link currently or non-ethernet devices (e.g. CAN).
> > LANG=C cat /sys/class/net/enp1s8/speed
> > cat: /sys/class/net/enp1s8/speed: Invalid argument
> > ethtool enp1s8 | grep -A1 Speed
> > Speed: Unknown!
> > Duplex: Unknown! (255)
> > LANG=C cat /sys/class/net/can0/speed
> > cat: /sys/class/net/can0/speed: Invalid argument
>
> Regards,
> Alexander
>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: SYSFS "errors"
From: Felipe Balbi @ 2013-02-19 10:11 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Borislav Petkov, Greg KH, balbi, Linux Kernel Mailing List,
Steven Rostedt, Frederic Weisbecker, Ingo Molnar, JBottomley,
linux-scsi, davem, netdev, Doug Thompson, linux-edac, rjw,
linux-pm
In-Reply-To: <20130219070310.2cadad7a@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
Hi,
On Tue, Feb 19, 2013 at 07:03:10AM -0300, Mauro Carvalho Chehab wrote:
> > But my gut feeling says to stay concervative and not touch this code -
> > we don't know what uses it and how much we would break by "fixing" it.
> > The current situation is not that big of a deal IMVHO and I'd be willing
> > to accept the small inconcistency versus possibly breaking userspace.
>
> I remember I saw some discussions about it in the past at bluesmoke ML,
> saying that -ENODEV is the expected behavior when this is not supported.
>
> Changing from -ENODEV to "N/A" will break anything that would be relying
> on the previous behavior. So, I think that such change will for sure break
> userspace.
>
> If we're willing to change it, not creating the "sdram_scrub_rate" sysfs
> node is less likely to affect userspace.
yeah, I agree with this. Guess we shouldn't be creating files which
aren't supported by the underlying HW and having a read() return -ENODEV
is quite weird IMO since that's actually 'breaking' read() interface
although that's up to interpretations.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 1/1] net: rfkill: Fix sparse warning in rfkill-regulator.c
From: Sachin Kamat @ 2013-02-19 9:57 UTC (permalink / raw)
To: netdev, linux-wireless; +Cc: davem, linville, johannes, sachin.kamat
'rfkill_regulator_ops' is used only in this file. Hence make it static.
Silences the following warning:
net/rfkill/rfkill-regulator.c:54:19: warning:
symbol 'rfkill_regulator_ops' was not declared. Should it be static?
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
net/rfkill/rfkill-regulator.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
index 4b5ab21..d11ac79 100644
--- a/net/rfkill/rfkill-regulator.c
+++ b/net/rfkill/rfkill-regulator.c
@@ -51,7 +51,7 @@ static int rfkill_regulator_set_block(void *data, bool blocked)
return 0;
}
-struct rfkill_ops rfkill_regulator_ops = {
+static struct rfkill_ops rfkill_regulator_ops = {
.set_block = rfkill_regulator_set_block,
};
--
1.7.4.1
^ permalink raw reply related
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Johannes Berg @ 2013-02-19 10:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Marc MERLIN, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1361251033.19353.120.camel@edumazet-glaptop>
On Mon, 2013-02-18 at 21:17 -0800, Eric Dumazet wrote:
> > chrome: page allocation failure: order:1, mode:0x4020
> > Pid: 8730, comm: chrome Tainted: G O 3.7.8-amd64-preempt-20121226-fixwd #1
> > Call Trace:
> > <IRQ> [<ffffffff810d5f38>] warn_alloc_failed+0x117/0x12c
> You could try to load iwlwifi with amsdu_size_8K set to 0 (disable)
>
> It should hopefully use order-0 pages
It will, do that then, unfortunately it can't switch at runtime because
it advertised this support to the access point or clients.
johannes
^ permalink raw reply
* Re: SYSFS "errors"
From: Mauro Carvalho Chehab @ 2013-02-19 10:03 UTC (permalink / raw)
To: Borislav Petkov
Cc: Greg KH, balbi, Linux Kernel Mailing List, Steven Rostedt,
Frederic Weisbecker, Ingo Molnar, JBottomley, linux-scsi, davem,
netdev, Doug Thompson, linux-edac, rjw, linux-pm
In-Reply-To: <20130218224405.GB21493@pd.tnic>
Em Mon, 18 Feb 2013 23:44:05 +0100
Borislav Petkov <bp@alien8.de> escreveu:
> On Mon, Feb 18, 2013 at 02:26:18PM -0800, Greg KH wrote:
> > I don't know, it depends on if userspace can handle this properly or
> > not. What tools rely on this sysfs file? WHat happens when they get a
> > non-number in the file?
The thing with "sdram_scrub_rate" is that this is not supported by any
userspace application I know. I suspect that this is used by userspace
scripts. So, we'll never know in advance what behavior those scripts would
expect.
>
> I'm not aware of any, frankly speaking.
>
> If there are any, those tools should be able to handle the -ENODEV
> they get. Now, if this gets changed this way, the read would succeed
> but they'll have to parse the returned value and see that it is not an
> integer.
>
> So I don't know either.
>
> But my gut feeling says to stay concervative and not touch this code -
> we don't know what uses it and how much we would break by "fixing" it.
> The current situation is not that big of a deal IMVHO and I'd be willing
> to accept the small inconcistency versus possibly breaking userspace.
I remember I saw some discussions about it in the past at bluesmoke ML,
saying that -ENODEV is the expected behavior when this is not supported.
Changing from -ENODEV to "N/A" will break anything that would be relying
on the previous behavior. So, I think that such change will for sure break
userspace.
If we're willing to change it, not creating the "sdram_scrub_rate" sysfs
node is less likely to affect userspace.
Regards,
Mauro
^ permalink raw reply
* Re: [PATCH] b43: Increase number of RX DMA slots
From: Rafał Miłecki @ 2013-02-19 9:57 UTC (permalink / raw)
To: David Laight
Cc: David Miller, Larry.Finger, linville, linux-wireless, netdev,
bittorf, stable
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7152@saturn3.aculab.com>
2013/2/19 David Laight <David.Laight@aculab.com>:
>> > Bastian Bittorf reported that some of the silent freezes on a Linksys WRT54G
>> > were due to overflow of the RX DMA ring buffer, which was created with 64
>> > slots. That finding reminded me that I was seeing similar crashed on a netbook,
>> > which also has a relatively slow processor. After increasing the number of
>> > slots to 128, runs on the netbook that previously failed now worked; however,
>> > I found that 109 slots had been used in one test. For that reason, the number
>> > of slots is being increased to 256.
>
> Surely the driver should work even if all the RX buffers get filled?
> Increasing the number of buffers is just hiding the issue.
> A burst of 300 back to back small packets probably fills the 256 slots.
>
> I realise that dropping frames isn't ideal, and that small numbers
> of buffers can make it impossible to receive long fragmented IP
> messages. but increasing the number of buffers doesn't seem to
> be the best fix for a 'silent freeze'.
>
> It might be that the driver would be more robust if it only ever
> put rx buffers into all but one of the ring slots.
That's what I said ;) I have this on my TODO, but I need to resolve my
issues with ethernet first.
--
Rafał
^ permalink raw reply
* Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Srivatsa S. Bhat @ 2013-02-19 9:55 UTC (permalink / raw)
To: Michel Lespinasse
Cc: tglx, peterz, tj, oleg, paulmck, rusty, mingo, akpm, namhyung,
rostedt, wangyun, xiaoguangrong, rjw, sbw, fweisbec, linux,
nikunj, linux-pm, linux-arch, linux-arm-kernel, linuxppc-dev,
netdev, linux-doc, linux-kernel, vincent.guittot
In-Reply-To: <CANN689E-98zK69pGeojbm30n3sswQYVBvhk3i3OzqvbeqSrSrg@mail.gmail.com>
On 02/19/2013 03:10 PM, Michel Lespinasse wrote:
> On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat
> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> But, the whole intention behind removing the parts depending on the
>> recursive property of rwlocks would be to make it easier to make rwlocks
>> fair (going forward) right? Then, that won't work for CPU hotplug, because,
>> just like we have a legitimate reason to have recursive
>> get_online_cpus_atomic(), we also have a legitimate reason to have
>> unfairness in locking (i.e., for deadlock-safety). So we simply can't
>> afford to make the locking fair - we'll end up in too many deadlock
>> possibilities, as hinted in the changelog of patch 1.
>
> Grumpf - I hadn't realized that making the underlying rwlock fair
> would break your hotplug use case. But you are right, it would. Oh
> well :/
>
Yeah :-/
>> So the only long-term solution I can think of is to decouple
>> percpu-rwlocks and rwlock_t (like what Tejun suggested) by implementing
>> our own unfair locking scheme inside. What do you think?
>
> I have no idea how hard would it be to change get_online_cpus_atomic()
> call sites so that the hotplug rwlock read side has a defined order vs
> other locks (thus making sure the situation you describe in patch 1
> doesn't happen). I agree we shouldn't base our short term plans around
> that, but maybe that's doable in the long term ???
>
I think it should be possible in the longer term. I'm expecting it to be
*much much* harder to audit and convert (requiring a lot of subsystem
knowledge of each subsystem that we are touching), than the simpler
tree-wide conversion that I did in this patchset... but I don't think it
is impossible.
> Otherwise, I think we should add some big-fat-warning that percpu
> rwlocks don't have reader/writer fairness, that the hotplug use case
> actually depends on the unfairness / would break if the rwlock was
> made fair, and that any new uses of percpu rwlocks should be very
> carefully considered because of the reader/writer fairness issues.
In fact, when I started out, I actually contained all the new locking code
inside CPU hotplug itself, and didn't even expose it as a generic percpu
rwlock in some of the previous versions of this patchset... :-)
But now that we already have a generic locking scheme exposed, we could
add a warning against using it without due consideration.
> Maybe even give percpu rwlocks a less generic sounding name, given how
> constrained they are by the hotplug use case.
I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
IMHO, the warning/documentation should suffice for anybody wanting to
try out this locking scheme for other use-cases.
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* [PATCH] NET/PHY: Eliminate the forced speed reduction algorithm.
From: Kirill Kapranov @ 2013-02-19 9:53 UTC (permalink / raw)
To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Francois Romieu, David Miller
NET/PHY: Eliminate the forced speed reduction algorithm.
The purpose of the introduced patch is deletion of the forced speed
reduction algorithm realisation from the driver module "phy".
The above mentioned algorithm works in the following way: if the phy
detected unlink line state (connector plugged off), NIC speed is
decreased step-by-step in the sequence:
100 full duplex
100 half duplex
10 full duplex
10 half duplex
with the latency circa 10 s per step, and stops at 10-HD value.
I have looked up RFC-802.3, and found, that the mentioned algorithm is
neither quoted nor described. AFAIK, no one RFC describe the mentioned
algorithm, so it may be a witty invention of the developer(s).
In the case of the fixed speed and duplex set, with the autonegotiation
off, for a NIC (e.g. # ethtool -s eth0 autoneg off speed 100 duplex
full) with ethernet cable plugged off, mentioned algorithm slows down
NIC speed, so when ethernet connector is plugged in, connection will be
inoperative: an ethernet switch will try to connect with 100/full
(e.g.), a NIC will stay at 10/half.
Thus, this algorithm is destructive for the fixed speed/duplex mode
(with autonegotiation off).
In the AUTO mode, the mentioned algorithm is inessential. The
autonegotiation procedure works fine regardless an speed/duplex settings
at the moment of connector hooking up.
Thus, there is no point in using of this algorithm in driver.
Thanks a lot Francois Romieu and David Miller for very constructive
advises.
Tested at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov <kkk@nita.ru>,<kapranoff@inbox.ru>
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.000000000 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.000000000 +0400
@@ -457,34 +457,6 @@ void phy_stop_machine(struct phy_device
}
/**
- * phy_force_reduction - reduce PHY speed/duplex settings by one step
- * @phydev: target phy_device struct
- *
- * Description: Reduces the speed/duplex settings by one notch,
- * in this order--
- * 1000/FULL, 1000/HALF, 100/FULL, 100/HALF, 10/FULL, 10/HALF.
- * The function bottoms out at 10/HALF.
- */
-static void phy_force_reduction(struct phy_device *phydev)
-{
- int idx;
-
- idx = phy_find_setting(phydev->speed, phydev->duplex);
-
- idx++;
-
- idx = phy_find_valid(idx, phydev->supported);
-
- phydev->speed = settings[idx].speed;
- phydev->duplex = settings[idx].duplex;
-
- pr_info("Trying %d/%s\n", phydev->speed,
- DUPLEX_FULL == phydev->duplex ?
- "FULL" : "HALF");
-}
-
-
-/**
* phy_error - enter HALTED state for this PHY device
* @phydev: target phy_device struct
*
@@ -814,30 +786,12 @@ void phy_state_machine(struct work_struc
phydev->adjust_link(phydev->attached_dev);
} else if (0 == phydev->link_timeout--) {
- int idx;
needs_aneg = 1;
/* If we have the magic_aneg bit,
* we try again */
if (phydev->drv->flags & PHY_HAS_MAGICANEG)
break;
-
- /* The timer expired, and we still
- * don't have a setting, so we try
- * forcing it until we find one that
- * works, starting from the fastest speed,
- * and working our way down */
- idx = phy_find_valid(0, phydev->supported);
-
- phydev->speed = settings[idx].speed;
- phydev->duplex = settings[idx].duplex;
-
- phydev->autoneg = AUTONEG_DISABLE;
-
- pr_info("Trying %d/%s\n", phydev->speed,
- DUPLEX_FULL ==
- phydev->duplex ?
- "FULL" : "HALF");
}
break;
case PHY_NOLINK:
@@ -863,7 +817,6 @@ void phy_state_machine(struct work_struc
netif_carrier_on(phydev->attached_dev);
} else {
if (0 == phydev->link_timeout--) {
- phy_force_reduction(phydev);
needs_aneg = 1;
}
}
^ permalink raw reply
* RE: [PATCH] b43: Increase number of RX DMA slots
From: David Laight @ 2013-02-19 9:42 UTC (permalink / raw)
To: David Miller, Larry.Finger
Cc: linville, linux-wireless, netdev, bittorf, stable
In-Reply-To: <20130219.005206.397289032011003833.davem@davemloft.net>
> > Bastian Bittorf reported that some of the silent freezes on a Linksys WRT54G
> > were due to overflow of the RX DMA ring buffer, which was created with 64
> > slots. That finding reminded me that I was seeing similar crashed on a netbook,
> > which also has a relatively slow processor. After increasing the number of
> > slots to 128, runs on the netbook that previously failed now worked; however,
> > I found that 109 slots had been used in one test. For that reason, the number
> > of slots is being increased to 256.
Surely the driver should work even if all the RX buffers get filled?
Increasing the number of buffers is just hiding the issue.
A burst of 300 back to back small packets probably fills the 256 slots.
I realise that dropping frames isn't ideal, and that small numbers
of buffers can make it impossible to receive long fragmented IP
messages. but increasing the number of buffers doesn't seem to
be the best fix for a 'silent freeze'.
It might be that the driver would be more robust if it only ever
put rx buffers into all but one of the ring slots.
David
^ permalink raw reply
* Re: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
From: Michel Lespinasse @ 2013-02-19 9:40 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: tglx, peterz, tj, oleg, paulmck, rusty, mingo, akpm, namhyung,
rostedt, wangyun, xiaoguangrong, rjw, sbw, fweisbec, linux,
nikunj, linux-pm, linux-arch, linux-arm-kernel, linuxppc-dev,
netdev, linux-doc, linux-kernel, vincent.guittot
In-Reply-To: <51227810.6090009@linux.vnet.ibm.com>
On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat
<srivatsa.bhat@linux.vnet.ibm.com> wrote:
> But, the whole intention behind removing the parts depending on the
> recursive property of rwlocks would be to make it easier to make rwlocks
> fair (going forward) right? Then, that won't work for CPU hotplug, because,
> just like we have a legitimate reason to have recursive
> get_online_cpus_atomic(), we also have a legitimate reason to have
> unfairness in locking (i.e., for deadlock-safety). So we simply can't
> afford to make the locking fair - we'll end up in too many deadlock
> possibilities, as hinted in the changelog of patch 1.
Grumpf - I hadn't realized that making the underlying rwlock fair
would break your hotplug use case. But you are right, it would. Oh
well :/
> So the only long-term solution I can think of is to decouple
> percpu-rwlocks and rwlock_t (like what Tejun suggested) by implementing
> our own unfair locking scheme inside. What do you think?
I have no idea how hard would it be to change get_online_cpus_atomic()
call sites so that the hotplug rwlock read side has a defined order vs
other locks (thus making sure the situation you describe in patch 1
doesn't happen). I agree we shouldn't base our short term plans around
that, but maybe that's doable in the long term ???
Otherwise, I think we should add some big-fat-warning that percpu
rwlocks don't have reader/writer fairness, that the hotplug use case
actually depends on the unfairness / would break if the rwlock was
made fair, and that any new uses of percpu rwlocks should be very
carefully considered because of the reader/writer fairness issues.
Maybe even give percpu rwlocks a less generic sounding name, given how
constrained they are by the hotplug use case.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
From: Ian Campbell @ 2013-02-19 8:58 UTC (permalink / raw)
To: Jan Beulich
Cc: David Miller, drjones@redhat.com, xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> > From: Andrew Jones <drjones@redhat.com>
> > Date: Mon, 18 Feb 2013 21:29:20 +0100
> >
> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> >> have one reference to the vif at this time, then the xenvif_put
> >> in netbk_fatal_tx_err is one too many.
> >>
> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
> >
> > Applied.
>
> But this is wrong from all we can tell,
Yes, please can this be reverted.
> we discussed this before
> (Wei pointed to the discussion in an earlier reply). The core of
> it is that the put here parallels the one in netbk_tx_err(), and
> the one in xenvif_carrier_off() matches the get from
> xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()).
Perhaps Andrew was looking at the tree before "xen-netback: correctly
return errors from netbk_count_requests()" which fixed a different case
of a double put which may have appeared to be fixed by this change too.
Ian.
> And anyway - shouldn't changes to netback require an ack from
> Ian?
>
> Jan
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
From: Andrew Jones @ 2013-02-19 8:58 UTC (permalink / raw)
To: Jan Beulich
Cc: David Miller, ian.campbell, xen-devel, linux-kernel, netdev, liuw
In-Reply-To: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
On Tue, 19 Feb 2013 08:03:49 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:
> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> > From: Andrew Jones <drjones@redhat.com>
> > Date: Mon, 18 Feb 2013 21:29:20 +0100
> >
> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> >> have one reference to the vif at this time, then the xenvif_put
> >> in netbk_fatal_tx_err is one too many.
> >>
> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
> >
> > Applied.
>
> But this is wrong from all we can tell, we discussed this before
> (Wei pointed to the discussion in an earlier reply). The core of
> it is that the put here parallels the one in netbk_tx_err(), and
> the one in xenvif_carrier_off() matches the get from
> xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()).
I see the balance described by Ian in [1] now. Sorry that I missed
that previous discussion and generated this noise.
[1] http://marc.info/?l=xen-devel&m=136084174026977&w=2
drew
>
> And anyway - shouldn't changes to netback require an ack from
> Ian?
>
> Jan
>
^ permalink raw reply
* Re: [PATCH 1/1] VSOCK: Introduce VM Sockets
From: Gerd Hoffmann @ 2013-02-19 8:45 UTC (permalink / raw)
To: Andy King; +Cc: pv-drivers, netdev, linux-kernel, virtualization, gregkh, davem
In-Reply-To: <1398469748.2079082.1361207251021.JavaMail.root@vmware.com>
On 02/18/13 18:07, Andy King wrote:
> Hi Gerd,
>
>>> + written = transport->stream_enqueue(
>>> + vsk, msg->msg_iov,
>>> + len - total_written);
>>
>> Hmm, shouldn't we pass total_written to stream_enqueue here?
>>
>> In case a blocking send(big-buffer) call gets splitted into multiple
>> stream_enqueue calls the second (and further) stream_enqueue calls need
>> to know at which msg offset they should continue sending the data, no?
>
> On the client side, the iov tracks it internally; see memcpy_fromiovec().
Ah, memcpy_fromiovec patches the iovec to keep track of the offset.
Wasn't aware it does this. Yes, we don't need to pass the offset then.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH net-next 2/3] tipc: byte-based overload control on socket receive queue
From: Jon Maloy @ 2013-02-19 8:07 UTC (permalink / raw)
To: Neil Horman; +Cc: Paul Gortmaker, David Miller, netdev, Ying Xue
In-Reply-To: <20130218144757.GA26199@hmsreliant.think-freely.org>
On 02/18/2013 09:47 AM, Neil Horman wrote:
> On Fri, Feb 15, 2013 at 05:57:46PM -0500, Paul Gortmaker wrote:
>> From: Ying Xue <ying.xue@windriver.com>
>>
>> Change overload control to be purely byte-based, using
>> sk->sk_rmem_alloc as byte counter, and compare it to a calculated
>> upper limit for the socket receive queue.
[...]
>> + *
>> + * For all connectionless messages, by default new queue limits are
>> + * as belows:
>> + *
>> + * TIPC_LOW_IMPORTANCE (5MB)
>> + * TIPC_MEDIUM_IMPORTANCE (10MB)
>> + * TIPC_HIGH_IMPORTANCE (20MB)
>> + * TIPC_CRITICAL_IMPORTANCE (40MB)
>> + *
>> + * Returns overload limit according to corresponding message importance
>> + */
>> +static unsigned int rcvbuf_limit(struct sock *sk, struct sk_buff *buf)
>> +{
>> + struct tipc_msg *msg = buf_msg(buf);
>> + unsigned int limit;
>> +
>> + if (msg_connected(msg))
>> + limit = CONN_OVERLOAD_LIMIT;
> This still strikes me as a bit wierd. If you really can't tolerate the default
> rmem settings in proc, have you considered separating the rmem and wmem values
> out into their own sysctls?
Initially we tried to set this value as default for sk_rcvbuf, and then use
fractions of it as limits, as you suggest below. The problem we found was that
if we want to change this via setsockopt(SOL_SOCKET, SO_RCVBUF) the value range
we can use is very limited, and doesn't fit our purposes.
We did consider to introduce a separate setsockopt at TIPC level for this,
but thought it had a value in itself to use the mechanism that is already there.
Hence the "re-interpretation" of sk_rcvbuf as we do below.
Considering the weird doubling of this parameter that is done elsewhere in the
code we thought that having our own interpretation might be acceptable.
We did of course see the potential issue with this, that is why we cc-ed
you for comments.
Now I see that David already pulled the series, so I am a little uncertain
about how to proceed.
Any comments from David on this?
///jon
Decnet is an example of a protocol that does this
> IIRC. If you did that, then you wouldn't be mysteriously violating the
> sk_rcvbuf value that gets set on all new sockets (and you could make this
> legitimately tunable).
>
>> + else
>> + limit = sk->sk_rcvbuf << (msg_importance(msg) + 5);
> Same here. You're using sk_rcvbuf as a base value, rather than a maximum value.
> It seems to me, sk_rcvbuf should be the maximum backlog at which you will store
> incomming messages. You can discard lower importance messages at fractions of
> sk_rcvbuf if you need to. If you create separate rmem and wmem sysctls you can
> still make the queue limits you document above work, and you won't violate the
> receive buffer value set in the socket.
>
> You might also consider looking into adding support for memory accounting, so
> that you can play a little more fast and loose with memory limits on an
> individual socket when the system as a whole isn't under pressure (tcp and sctp
> aer good examples of this).
>
> Neil
>
^ permalink raw reply
* Re: [PATCH v2 2/5] usb: phy: omap-usb2: use the new generic PHY framework
From: Felipe Balbi @ 2013-02-19 8:11 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: rob, tony, linux, eballetbo, javier, balbi, gregkh, akpm, mchehab,
cesarb, davem, arnd, santosh.shilimkar, broonie, swarren,
linux-doc, linux-kernel, linux-arm-kernel, linux-omap, linux-usb,
netdev
In-Reply-To: <1361253198-7401-3-git-send-email-kishon@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]
Hi,
On Tue, Feb 19, 2013 at 11:23:15AM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. omap_usb2_suspend
> is split into omap_usb_suspend and omap_usb_resume in order to align
> with the new framework.
>
> However using the old USB PHY library cannot be completely removed
> because OTG is intertwined with PHY and moving to the new framework
> will break OTG. Once we have a separate OTG state machine, we
> can get rid of the USB PHY library.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/phy/omap-usb2.c | 49 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/usb/omap_usb.h | 3 +++
> 2 files changed, 52 insertions(+)
>
> diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
> index 844ab68..924ae59 100644
> --- a/drivers/usb/phy/omap-usb2.c
> +++ b/drivers/usb/phy/omap-usb2.c
> @@ -119,9 +119,48 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
> return 0;
> }
>
> +static int omap_usb_suspend(struct phy_descriptor *desc)
> +{
> + struct omap_usb *phy = desc_to_omapusb(desc);
> +
> + if (!phy->is_suspended) {
I wonder if it wouldn't be better to have some refcounting done by phy
framework itself so that this only gets called when phy->refcount == 0
> + omap_control_usb_phy_power(phy->control_dev, 0);
coudln't you move this to ->runtime_suspend() ?
> + pm_runtime_put_sync(phy->dev);
> + phy->is_suspended = 1;
> + }
> +
> + return 0;
> +}
> +
> +static int omap_usb_resume(struct phy_descriptor *desc)
> +{
> + u32 ret;
> + struct omap_usb *phy = desc_to_omapusb(desc);
> +
> + if (phy->is_suspended) {
> + ret = pm_runtime_get_sync(phy->dev);
> + if (ret < 0) {
> + dev_err(phy->dev, "get_sync failed with err %d\n",
> + ret);
> + return ret;
> + }
> + omap_control_usb_phy_power(phy->control_dev, 1);
likewise, this could go to ->runtime_resume().
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
From: Jan Beulich @ 2013-02-19 8:03 UTC (permalink / raw)
To: David Miller, drjones; +Cc: ian.campbell, xen-devel, linux-kernel, netdev
In-Reply-To: <20130219.005356.2288460992654639558.davem@davemloft.net>
>>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> From: Andrew Jones <drjones@redhat.com>
> Date: Mon, 18 Feb 2013 21:29:20 +0100
>
>> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
>> a xenvif_put(). As callers of netbk_fatal_tx_err should only
>> have one reference to the vif at this time, then the xenvif_put
>> in netbk_fatal_tx_err is one too many.
>>
>> Signed-off-by: Andrew Jones <drjones@redhat.com>
>
> Applied.
But this is wrong from all we can tell, we discussed this before
(Wei pointed to the discussion in an earlier reply). The core of
it is that the put here parallels the one in netbk_tx_err(), and
the one in xenvif_carrier_off() matches the get from
xenvif_connect() (which normally would be done on the path
coming through xenvif_disconnect()).
And anyway - shouldn't changes to netback require an ack from
Ian?
Jan
^ permalink raw reply
* Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
From: Felipe Balbi @ 2013-02-19 8:01 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: rob, tony, linux, eballetbo, javier, balbi, gregkh, akpm, mchehab,
cesarb, davem, arnd, santosh.shilimkar, broonie, swarren,
linux-doc, linux-kernel, linux-arm-kernel, linux-omap, linux-usb,
netdev
In-Reply-To: <1361253198-7401-2-git-send-email-kishon@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4270 bytes --]
Hi,
On Tue, Feb 19, 2013 at 11:23:14AM +0530, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using phandle, the platform specfic intialization code (say from board file)
> should have already called phy_bind with the binding information. The binding
> information consists of phy's device name, phy user device name and an index.
> The index is used when the same phy user binds to mulitple phys.
>
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
s/has describes/describes
> poweron, shutdown.
>
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy.
you forgot to mention here that one case of re-use is OMAP5 where the
same PHY IP (different instances of it) is used for SATA and USB3
functionality, which means that we would have to maintain 2 drivers for
the same thing.
> diff --git a/Documentation/ABI/testing/sysfs-class-phy b/Documentation/ABI/testing/sysfs-class-phy
> new file mode 100644
> index 0000000..ffd9930
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-phy
> @@ -0,0 +1,15 @@
> +What: /sys/class/phy/<phy>/label
> +Date: Feb 2013
> +KernelVersion: 3.10
> +Contact: Kishon Vijay Abraham I <kishon@ti.com>
> +Description:
> + This is a read-only file for getting the label of the phy.
> +
> +What: /sys/class/phy/<phy>/bind
this will cause problems with the generic bind/unbind sysfs files which
are write-only. You should probably rename it to something else.
> +4. Getting a reference to the PHY
> +
> +Before the controller can make use of the PHY, it has to get a reference to
> +the PHY. The PHY framework provides 4 APIs to get a reference to the PHY.
'it has to get a reference to it. This framework', decreases the
duplication of 'PHY'.
> +struct phy *phy_get(struct device *dev, u8 index);
> +struct phy *devm_phy_get(struct device *dev, u8 index);
> +struct phy *of_phy_get(struct device *dev, const char *phandle, u8 index);
> +struct phy *devm_of_phy_get(struct device *dev, const char *phandle, u8 index);
> +
> +phy_get and devm_phy_get can be used to get the PHY in non-dt boot. This API
> +uses the binding information added using the phy_bind API to find and return
> +the appropriate PHY. The only difference between the two APIs is that
> +devm_phy_get associates the device with the PHY using devres on successful PHY
> +get. On driver detach, release function is invoked on the the devres data and
s/the the/the/
> +devres data is freed.
s/devres data/it/
> +7. Current Status
> +
> +Currently only USB in OMAP is made to use this framework. However using the
> +USB PHY library cannot be completely removed because it is intertwined with
> +OTG. Once we move OTG out of PHY completely, using the old PHY library can be
> +completely removed. SATA in OMAP will also more likely use this new framework
> +and we should have a patch for it soon.
not sure if this should be in the documentation, but fair enough.
> +static DEFINE_MUTEX(phy_list_mutex);
not sure if a mutex is enough to protect list traversal...
> +struct phy_ops {
> + int (*init)(struct phy_descriptor *desc);
> + int (*exit)(struct phy_descriptor *desc);
> + int (*suspend)(struct phy_descriptor *desc);
> + int (*resume)(struct phy_descriptor *desc);
should you really have these two pointers ? I wonder if it wouldn't be
better to force runtime_pm down on the users and have phy_suspend() and
phy_resume() just be wrappers to pm_runtime_get() and pm_runtime_put().
Up to discussion, I guess.
> +#if defined(CONFIG_GENERIC_PHY) || defined(CONFIG_GENERIC_PHY_MODULE)
#if IS_ENABLED(CONFIG_GENERIC_PHY)
> +static inline struct phy *devm_phy_get(struct device *dev, u8 index)
> +{
> + return ERR_PTR(-EINVAL);
would -EOPNOTSUPP fit better here (and all others)
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] netfilter: nf_ct_helper: Fix logging for dropped packets
From: Joe Perches @ 2013-02-19 7:51 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netdev, davem, netfilter-devel
In-Reply-To: <20130219015015.GA11869@localhost>
On Tue, 2013-02-19 at 02:50 +0100, Pablo Neira Ayuso wrote:
> On Mon, Feb 18, 2013 at 05:33:14PM -0800, Joe Perches wrote:
> > On Tue, 2013-02-19 at 02:11 +0100, Pablo Neira Ayuso wrote:
> > > On Mon, Feb 18, 2013 at 04:22:02PM -0800, Joe Perches wrote:
> > > > On Tue, 2013-02-19 at 01:10 +0100, pablo@netfilter.org wrote:
> > > > > This patch modifies the existing code to provide more specific
> > > > > error message in the scope of each helper to help users to debug
> > > > > the reason why the packet has been dropped, ie:
> > > > []
> > > > > diff --git a/include/net/netfilter/nf_conntrack_helper.h b/include/net/netfilter/nf_conntrack_helper.h
> > > > []
> > > > > @@ -100,6 +100,9 @@ struct nf_ct_helper_expectfn {
> > > > > void (*expectfn)(struct nf_conn *ct, struct nf_conntrack_expect *exp);
> > > > > };
> > > > >
> > > > > +extern void nf_ct_helper_log(struct sk_buff *skb, const struct nf_conn *,
> > > > > + const char *fmt, ...);
Hi again Pablo.
Sorry, I didn't look at the function implementation.
It doesn't use the var args that follow fmt.
Two current uses have format and args aren't emitted correctly.
This is needed:
From: Joe Perches <joe@perches.com>
Update nf_ct_helper_log to emit args along with the format.
Signed-off-by: Joe Perches <joe@perches.com>
---
net/netfilter/nf_conntrack_helper.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c
index 013cdf6..3ebc2ae 100644
--- a/net/netfilter/nf_conntrack_helper.c
+++ b/net/netfilter/nf_conntrack_helper.c
@@ -341,6 +341,13 @@ void nf_ct_helper_log(struct sk_buff *skb, const struct nf_conn *ct,
{
const struct nf_conn_help *help;
const struct nf_conntrack_helper *helper;
+ struct va_format vaf;
+ va_list args;
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
/* Called from the helper function, this call never fails */
help = nfct_help(ct);
@@ -349,7 +356,9 @@ void nf_ct_helper_log(struct sk_buff *skb, const struct nf_conn *ct,
helper = rcu_dereference(help->helper);
nf_log_packet(nf_ct_l3num(ct), 0, skb, NULL, NULL, NULL,
- "nf_ct_%s: dropping packet: %s ", helper->name, fmt);
+ "nf_ct_%s: dropping packet: %pV", helper->name, &vaf);
+
+ va_end(args);
}
EXPORT_SYMBOL_GPL(nf_ct_helper_log);
^ permalink raw reply related
* SOCK_STREAM TCP: send() returns success even when other side responded with RST packet
From: Tomas Hozza @ 2013-02-19 7:02 UTC (permalink / raw)
To: netdev
In-Reply-To: <79866921.1777178.1361257053436.JavaMail.root@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]
Hi.
I was advised to forward my networking Kernel related Bug here
so it can get fixed much faster. Here is the Bug description
copied from Red Hat Bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=912382):
Description of problem:
I'm using SOCK_STREAM TCP sockets. Imagine server-client application.
- Server will accept connection from client.
- Client sends some data to server -> server receives data.
- Client then half-closes the TCP connection using shutdown(fd, SHUT_WR).
- Client waits for some data from the server.
- Server sends some data to client -> client receives data.
- Client exits and closes the socket.
- After some time server tries to send some data to the client.
- The first send() call returns success even the Client's response is RST.
Version-Release number of selected component (if applicable):
3.7.7-201.fc18.x86_64
3.7.8-202.fc18.x86_64
How reproducible:
always
Steps to Reproduce:
1. download attached client/server sources.
2. compile server: # gcc tcp_server.c -o server
3. compile client: # gcc tcp_client.c -o client
4. run the server: # ./server
5. run the client: # ./client
Actual results:
Server started...
Created SOCK_STREAM socket
Bound to localhost:6666
waiting for connection...
Client connected!
Waiting for some data from client
Received: "MSG from client"
Received EOF
Sending msg to client: "MSG from server"
sleep(5)
Sending 1 msg to client: "MSG from server"
try #1 send() result: (0) Success
Sending 2 msg to client: "MSG from server"
try #2 send() result: (32) Broken pipe
Server exiting...
Expected results:
Server should fail to send() data right after sleep().
Server started...
Created SOCK_STREAM socket
Bound to localhost:6666
waiting for connection...
Client connected!
Waiting for some data from client
Received: "MSG from client"
Received EOF
Sending msg to client: "MSG from server"
sleep(5)
Sending 1 msg to client: "MSG from server"
try #1 send() result: (32) Broken pipe
Server exiting...
Additional info:
RST answer means that data were NOT delivered. Therefore the very
first send() call after server sleep() should fail!
Regards,
Tomas Hozza
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tcp_server.c --]
[-- Type: text/x-csrc; name=tcp_server.c, Size: 2474 bytes --]
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <signal.h>
int main(int argc, char **argv)
{
int ssock, csock, i;
static char buff[256];
ssize_t nbytes;
struct sockaddr_in saddr;
memset(&saddr, 0, sizeof(saddr));
saddr.sin_family = AF_INET;
saddr.sin_port = htons(6666);
signal(SIGPIPE, SIG_IGN);
printf("Server started...\n");
if ((ssock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
printf("socket() error. (%d) %s\n", errno, strerror(errno));
exit(1);
}
printf("Created SOCK_STREAM socket\n");
if (bind(ssock, (struct sockaddr*)&saddr, sizeof(saddr)) == -1) {
printf("bind() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
exit(1);
}
printf("Bound to localhost:6666\n");
if (listen(ssock, 1) == -1) {
printf("listen() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
exit(1);
}
printf("waiting for connection...\n");
csock = accept(ssock, NULL, NULL);
if (csock == -1) {
printf("accept() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
exit(1);
}
printf("Client connected!\n");
printf("Waiting for some data from client\n");
while ((nbytes = recv(csock, buff, sizeof(buff), 0)) > 0) {
printf("Received: \"%s\"\n", buff);
}
if (nbytes < 0) {
printf("recv() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
close(csock);
exit(1);
} else if (nbytes == 0) {
printf("Received EOF\n");
printf("Sending msg to client: \"MSG from server\"\n");
if ((nbytes = send(csock, "MSG from server", sizeof("MSG from server"), 0)) <= 0) {
printf("send() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
close(csock);
exit(1);
}
}
printf("sleep(5)\n");
sleep(5);
i = 1;
while (1) {
printf("Sending %d msg to client: \"MSG from server\"\n", i);
nbytes = send(csock, "MSG from server", sizeof("MSG from server"), 0);
printf("try #%d send() result: (%d) %s\n",i ,errno, strerror(errno));
if (nbytes <= 0)
break;
++i;
}
printf("Server exiting...\n");
close(ssock);
close(csock);
return 0;
}
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: tcp_client.c --]
[-- Type: text/x-csrc; name=tcp_client.c, Size: 1694 bytes --]
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
int main(int argc, char **argv)
{
int ssock, i;
static char buff[256];
ssize_t nbytes;
struct sockaddr_in saddr;
memset(&saddr, 0, sizeof(saddr));
saddr.sin_family = AF_INET;
saddr.sin_port = htons(6666);
printf("Client started...\n");
if ((ssock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
printf("socket() error. (%d) %s\n", errno, strerror(errno));
exit(1);
}
printf("Created SOCK_STREAM socket\n");
if (connect(ssock, (struct sockaddr *)&saddr, sizeof(saddr)) == -1) {
printf("connect() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
exit(1);
}
printf("Connected to the server!\n");
printf("Sending some data to server\n");
if ((nbytes = send(ssock, "MSG from client", sizeof("MSG from client"), 0)) <= 0) {
printf("send() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
exit(1);
}
printf("Half-closing connection with shutdown(ssock, SHUT_WR)\n");
if (shutdown(ssock, SHUT_WR) == -1) {
printf("shutdown() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
exit(1);
}
printf("Receiving data from server\n");
if ((nbytes = recv(ssock, buff, sizeof(buff), 0)) > 0) {
printf("Received: \"%s\"\n", buff);
} else {
printf("recv() error. (%d) %s\n", errno, strerror(errno));
close(ssock);
exit(1);
}
printf("Client exiting...\n");
close(ssock);
return 0;
}
^ permalink raw reply
* [PATCH] b44: use helper function for aligning IP header
From: Rafał Miłecki @ 2013-02-19 6:33 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Rafał Miłecki
Don't duplicate netdev_alloc_skb_ip_align which by the way uses
NET_IP_ALIGN instead of hardcoded "2".
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
I don't have hardware to check this, so please review if it's OK.
It's quite trivial so I hope I couldn't do anything wrong.
---
drivers/net/ethernet/broadcom/b44.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/b44.c b/drivers/net/ethernet/broadcom/b44.c
index 330b090..041aea6 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -809,11 +809,10 @@ static int b44_rx(struct b44 *bp, int budget)
struct sk_buff *copy_skb;
b44_recycle_rx(bp, cons, bp->rx_prod);
- copy_skb = netdev_alloc_skb(bp->dev, len + 2);
+ copy_skb = netdev_alloc_skb_ip_align(bp->dev, len);
if (copy_skb == NULL)
goto drop_it_no_recycle;
- skb_reserve(copy_skb, 2);
skb_put(copy_skb, len);
/* DMA sync done above, copy just the actual packet */
skb_copy_from_linear_data_offset(skb, RX_PKT_OFFSET,
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next 5/6] qlcnic: fix ping resumption to a VM after a live migration
From: Jitendra Kalsaria @ 2013-02-17 4:53 UTC (permalink / raw)
To: davem; +Cc: netdev, sony.chacko, Dept_NX_Linux_NIC_Driver, Shahed Shaikh
In-Reply-To: <1361076831-31746-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
Delete the MAC address of a VM, from the adapter's embedded switch,
after the VM had been migrated out of this adapter/server.
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 5 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 18 +++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 145 ++++++++++++++++++++--
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 21 +++
4 files changed, 177 insertions(+), 12 deletions(-)
XXXX --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
XXXXX 61b594c..01e9ea1 100644
XXX a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
XXX b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
XX -1008,9 +1008,12 @@ struct qlcnic_adapter {
XXXXXX delayed_work idc_aen_work;
XXXXXX qlcnic_filter_hash fhash;
X struct qlcnic_filter_hash rx_fhash;
XXXXXXXXXX tx_clean_lock;
XXXXXXXXXX mac_learn_lock;
X /* spinlock for catching rcv filters for eswitch traffic */
X spinlock_t rx_mac_learn_lock;
XXX file_prd_off; /*File fw product offset*/
XXX fw_version;
XXXXX struct firmware *fw;
XX -1506,6 +1509,8 @@ int qlcnic_init_pci_info(struct qlcnic_adapter *);
XXX qlcnic_set_default_offload_settings(struct qlcnic_adapter *);
XXX qlcnic_reset_npar_config(struct qlcnic_adapter *);
XXX qlcnic_set_eswitch_port_config(struct qlcnic_adapter *);
XXXXX qlcnic_add_lb_filter(struct qlcnic_adapter *, struct sk_buff *, int,
X __le16);
XX
X QLOGIC Board information
XX
XXXX --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
XXXXX 51716ab..325e11e 100644
XXX a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
XXX b/drivers/net/ethernet/qlogicXXXXXXXXXXXXXXXXXXX
XX -578,7 +578,8 @@ void qlcnic_prune_lb_filters(struct qlcnic_adapter *adapter)
XXXXXX qlcnic_filter *tmp_fil;
XXXXXX hlist_node *tmp_hnode, *n;
XXXXXX hlist_head *head;
X int i, time;
X int i;
X unsigned long time;
XX cmd;
XXX (i = 0; i < adapter->fhash.fbucket_size; i++) {
XX -600,6 +601,21 @@ void qlcnic_prune_lb_filters(struct qlcnic_adapter *adapter)
X
X
X
X for (i = 0; i < adapter->rx_fhash.fbucket_size; i++) {
X head = &(adapter->rx_fhash.fhead[i]);
X
X hlist_for_each_entry_safe(tmp_fil, tmp_hnode, n, head, fnode)
X {
X time = tmp_fil->ftime;
X if (jiffies > (QLCNIC_FILTER_AGE * HZ + time)) {
X spin_lock_bh(&adapter->rx_mac_learn_lock);
X adapter->rx_fhash.fnum--;
X hlist_del(&tmp_fil->fnode);
X spin_unlock_bh(&adapter->rx_mac_learn_lock);
X kfree(tmp_fil);
X }
X }
X }
X
XXXX qlcnic_delete_lb_filters(struct qlcnic_adapter *adapter)
XXXX --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
XXXXX 2990f45..6387e0c 100644
XXX a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
XXX b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
XX -152,6 +152,89 @@ static inline u32 qlcnic_get_ref_handle(struct qlcnic_adapter *adapter,
XXXXXX handle;
X
XXXXXXX inline int qlcniXXXXXXXXXXXXXXXXXXXX sts_data)
XX
X return (qlcnic_get_sts_status(sts_data) == STATUS_CKSUM_LOOP) ? 1 : 0;
XX
X
XXXXX qlcnic_add_lb_filter(struct qlcnic_adapter *adapter, struct sk_buff *skb,
X int loopback_pkt, __le16 vlan_id)
XX
X struct ethhdr *phdr = (struct ethhdr *)(skb->data);
X struct qlcnic_filter *fil, *tmp_fil;
X struct hlist_node *tmp_hnode, *n;
X struct hlist_head *head;
X unsigned long time;
X u64 src_addr = 0;
X u8 hindex, found = 0, op;
X int ret;
X
X memcpy(&src_addr, phdr->h_source, ETH_ALEN);
X
X if (loopback_pkt) {
X if (adapter->rx_fhash.fnum >= adapter->rx_fhash.fmax)
X return;
X
X hindex = qlcnic_mac_hash(src_addr) &
X (adapter->fhash.fbucket_size - 1);
X head = &(adapter->rx_fhash.fhead[hindex]);
X
X hlist_for_each_entry_safe(tmp_fil, tmp_hnode, n, head, fnode) {
X if (!memcmp(tmp_fil->faddr, &src_addr, ETH_ALEN) &&
X tmp_fil->vlan_id == vlan_id) {
X time = tmp_fil->ftime;
X if (jiffies > (QLCNIC_READD_AGE * HZ + time))
X tmp_fil->ftime = jiffies;
X return;
X }
X }
X
X fil = kzalloc(sizeof(struct qlcnic_filter), GFP_ATOMIC);
X if (!fil)
X return;
X
X fil->ftime = jiffies;
X memcpy(fil->faddr, &src_addr, ETH_ALEN);
X fil->vlan_id = vlan_id;
X spin_lock(&adapter->rx_mac_learn_lock);
X hlist_add_head(&(fil->fnode), hXXXXX
X adapter->rx_fhash.fnum++;
X spin_unlock(&adapter->rx_mac_learn_lock);
X } else {
X hindex = qlcnic_mac_hash(src_addr) &
X (adapter->fhash.fbucket_size - 1);
X head = &(adapter->rx_fhash.fhead[hindex]);
X spin_lock(&adapter->rx_mac_learn_lock);
X hlist_for_each_entry_safe(tmp_fil, tmp_hnode, n, head, fnode) {
X if (!memcmp(tmp_fil->faddr, &src_addr, ETH_ALEN) &&
X tmp_fil->vlan_id == vlan_id) {
X found = 1;
X break;
X }
X }
X
X if (!found) {
X spin_unlock(&adapter->rx_mac_learn_lock);
X return;
X }
X
X op = vlan_id ? QLCNIC_MAC_VLAN_ADD : QLCNIC_MAC_ADD;
X ret = qlcnic_sre_macaddr_change(adapter, (u8 *)&src_addr,
X vlan_id, op);
X if (!ret) {
X op = vlan_id ? QLCNIC_MAC_VLAN_DEL : QLCNIC_MAC_DEL;
X ret = qlcnic_sre_macaddr_change(adapter,
X (u8 *)&src_addr,
X vlan_id, op);
X if (!ret) {
X hlist_del(&(tmp_fil->fnode));
X adapter->rx_fhash.fnum--;
X }
X }
X spin_unlock(&adapter->rx_mac_learn_lock);
X }
XX
X
XXXX qlcnic_82xx_change_filter(struct qlcnic_adapter *adapter, u64 *uaddr,
XXXXXX vlan_id)
X
XX -207,9 +290,6 @@ static void qlcnic_send_filter(struct qlcnic_adapter *adapter,
XXXXXXX
X
X /* Only NPAR capable devices support vlan based learning */
X if (adapter->flags & QLCNIC_ESWITCH_ENXXXXXX
X vlan_id = first_desc->vlan_TCI;
XXXXXXXXXXXXXXXXX phdr->h_source, ETH_ALEN);
XXXXXX = qlcnic_mac_hash(src_addr) & (adapter->fhash.fbucket_size - 1);
XXXX = &(adapter->fhash.fhead[hindex]);
XX -920,8 +1000,8 @@ qlcnic_process_rcv(struct qlcnic_adapter *adapter,
XXXXXX qlcnic_rx_buffer *buffer;
XXXXXX sk_buff *skb;
XXXXXX qlcnic_host_rds_ring *rds_ring;
X int index, length, cksum, pkt_offset;
X u16 vid = 0xffff;
X int index, length, cksum, pkt_offset, is_lb_pkt;
X u16 vid = 0xffff, t_vid;
XX (unlikely(ring >= adapter->max_rds_rings))
XXXXXX NULL;
XX -941,6 +1021,14 @@ qlcnic_process_rcv(struct qlcnic_adapter *adapter,
XX (!skb)
XXXXXX buffer;
X if (adapter->drv_mac_learn &&
X (adapter->flags & QLCNIC_ESWITCH_ENABLED)) {
X t_vid = 0;
X is_lb_pkt = qlcnic_82xx_is_lb_pkt(sts_data0);
X qlcnic_add_lb_filter(adapter, skb, is_lb_pkt,
X cpu_to_le16(t_vid));
X }
X
XX (length > rds_ring->skb_size)
XXXXXXXXXXXX rds_ring->skb_size);
XXXX
XX -985,8 +1073,8 @@ qlcnic_process_lro(struct qlcnic_adapter *adapter,
XXXXXX ipv6hdr *ipv6h;
XXXXXX tcphdr *th;
XXXX push, timestamp;
X int index, l2_hdr_offset, l4_hdr_offset;
X u16 lro_length, length, data_offset, vid = 0xffff;
X int index, l2_hdr_offset, l4_hdr_offset, is_lb_pkt;
X u16 lro_length, lengXXX data_offset, t_vid, vid = 0xffff;
XXX seq_number;
XX (unlikely(ring > adapter->max_rds_rings))
XX -1011,6 +1099,14 @@ qlcnic_process_lro(struct qlcnic_adapter *adapter,
XX (!skb)
XXXXXX buffer;
X if (adapter->drv_mac_learn &&
X (adapter->flags & QLCNIC_ESWITCH_ENABLED)) {
X t_vid = 0;
X is_lb_pkt = qlcnic_82xx_is_lb_pkt(sts_data0);
X qlcnic_add_lb_filter(adapter, skb, is_lb_pkt,
X cpu_to_le16(t_vid));
X }
X
XX (timestamp)
XXXXXXXXXXX = l4_hdr_offset + QLC_TCP_TS_HDR_SIZE;
XXXX
XX -1357,6 +1453,17 @@ void qlcnic_82xx_napi_disable(struct qlcnic_adapter *adapter)
X
X
XXXXXXXX QLC_83XX_NORMAL_LB_PKT (1ULL << 36)
XXXXXXXX QLC_83XX_LRO_LB_PKT (1ULL << 46)
X
XXXXXXX inline int qlcnic_83xx_is_lb_pkt(u64 sts_data, int lro_pkt)
XX
X if (lro_pkt)
X return (sts_data & QLC_83XX_LRO_LB_PKT) ? 1 : 0;
X else
X return (sts_data & QLC_83XX_NORMAL_LB_PKT) ? 1 : 0;
XX
X
XXXXXX struct qlcnic_rx_buffer *
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX qlcnic_adapter *adapter,
XXXXXX qlcnic_host_sds_ring *sds_ring,
XX -1367,8 +1474,8 @@ qlcnic_83xx_process_rcv(struct qlcnic_adapter *adapter,
XXXXXX qlcnic_rx_buffer *buffer;
XXXXXX sk_buff *skb;
XXXXXX qlcnic_host_rds_ring *rds_ring;
X int index, length, cksum;
X u16 vid = 0xffff;
X int index, length, cksum, is_lb_pktX
X u16 vid = 0xffff, t_vid;
XX (unlikely(ring >= adapter->max_rds_rings))
XXXXXX NULL;
XX -1386,6 +1493,14 @@ qlcnic_83xx_process_rcv(struct qlcnic_adapter *adapter,
XX (!skb)
XXXXXX buffer;
X if (adapter->drv_mac_learn &&
X (adapter->flags & QLCNIC_ESWITCH_ENABLED)) {
X t_vid = 0;
X is_lb_pkt = qlcnic_83xx_is_lb_pkt(sts_data[1], 0);
X qlcnic_add_lb_filter(adapter, skb, is_lb_pkt,
X cpu_to_le16(t_vid));
X }
X
XX (length > rds_ring->skb_size)
XXXXXXXXXXXX rds_ring->skb_size);
XXXX
XX -1424,9 +1539,9 @@ qlcnic_83xx_process_lro(struct qlcnic_adapter *adapter,
XXXXXX tcphdr *th;
XXXX push;
XXX l2_hdr_offset, l4_hdr_offset;
X int index;
X int index, is_lb_pkt;
XXX lro_length, length, data_offset, gso_size;
X u16 vid = 0xffff;
X u16 vid = 0xffff, t_vid;
XX (unlikely(ring > adapter->max_rds_rings))
XXXXXX NULL;
XX -1447,6 +1562,14 @@ qlcnic_83xx_process_lro(struct qlcnic_adapter *adapter,
XXX = qlcnic_process_rxbuf(adapter, rds_ring, index, STATUS_CKSUM_OK);
XX (!skb)
XXXXXX buffer;
X
X if (adapter->drv_mac_learn &&
X (adapter->flags & QLCNIC_ESWITCH_ENABLED)) {
X t_vid = 0;
X is_lb_pkt = qlcnic_83xx_is_lb_pkt(sts_data[1], 1);
X qlcnic_add_lb_filter(adapter, skb, is_lb_pkt,
X cpu_to_le16(t_vid));
X }
XX (qlcnic_83xxXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXX = l4_hdr_offset + QLCNIC_TCP_TS_HDR_SIZE;
XXXX
XXXX --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
XXXXX e03017a..5d5fd06 100644
XXX a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
XXX b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
XX -2208,6 +2208,7 @@ void qlcnic_alloc_lb_filters_mem(struct qlcnic_adapter *adapter)
XXXXXXXXXXXX = adapter->ahw->act_pci_func;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X spin_lock_init(&adapter->rx_mac_learn_lock);
XX (qlcnic_82xx_check(adapter)) {
XXXXXXXXXXX = QLCNIC_LB_MAX_FILTERS;
XX -2231,6 +2232,20 @@ void qlcnic_alloc_lb_filters_mem(struct qlcnic_adapter *adapter)
XXX (i = 0; i < adapter->fhash.fbucket_size; i++)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X
X adapter->rx_fhash.fbucket_size = adapter->fhash.fbucket_size;
X
X head = kcalloc(adapter->rx_fhash.fbucket_size,
X sizeof(struct hlist_head), GFP_ATOMIC);
X
X if (!head)
X return;
X
X adapter->rx_fhash.fmax = (filter_size / act_pci_func);
X adapter->rx_fhash.fhead = head;
X
X for (i = 0; i < adapter->rx_fhash.fbucket_size; i++)
X INIT_HLIST_HEAD(&adapter->rx_fhash.fhead[i]);
X
XXXXXX void qlcnic_free_lb_filters_mem(struct qlcnic_adapter *adapter)
XX -2240,6 XXXXXXXX @@ static void qlcnic_free_lb_filters_mem(struct qlcnic_adapter *adapter)
XXXXXXXXXXXXXXXXXXXX = NULL;
XXXXXXXXXXXXXXXXXXX = 0;
X
X if (adapter->rx_fhash.fmax && adapter->rx_fhash.fhead)
X kfree(adapter->rx_fhash.fhead);
X
X adapter->rx_fhash.fmax = 0;
X adapter->rx_fhash.fhead = NULL;
X
XXX qlcnic_check_temp(struct qlcnic_adapter *adapter)
XX
XXXXX
^ permalink raw reply
* Fw: [Bug 54021] New: No internet with kernel 3.7 or 3.8 with LAN
From: Stephen Hemminger @ 2013-02-19 6:05 UTC (permalink / raw)
To: Jay Cliburn, Chris Snook; +Cc: netdev
Also, in link it references the devices
$ lspci -nnk | grep -i net -A2
01:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR8152 v1.1 Fast Ethernet [1969:2060] (rev c1)
Subsystem: Acer Incorporated [ALI] Device [1025:0349]
Kernel driver in use: atl1c
--
02:00.0 Network controller [0280]: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
Subsystem: Lite-On Communications Inc Device [11ad:6631]
Kernel driver in use: ath9k
Begin forwarded message:
Date: Sun, 17 Feb 2013 05:38:37 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 54021] New: No internet with kernel 3.7 or 3.8 with LAN
https://bugzilla.kernel.org/show_bug.cgi?id=54021
Summary: No internet with kernel 3.7 or 3.8 with LAN
Product: Networking
Version: 2.5
Kernel Version: since 3.7
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: david.erbs@gmail.com
Regression: No
Hello since kernel update 3.7 or 3.8 I have no internet connection with LAN,
wlan is working very well, with lan my internet connection is working for 5
minutes, then internet is not working anymore. I have to unplug the cable and
the i have to plug it again - so it will work 5 minutes.....
I have a netbook (acer aspire one d255)
With kernel 3.5x everything is working fine.
Problem is reported here (German)
http://forum.ubuntuusers.de/topic/internet-verbindung-bricht-ab/
If you need more information, feel free to ask
kind regards
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* net-next is CLOSED
From: David Miller @ 2013-02-19 5:56 UTC (permalink / raw)
To: netdev
The merge window has openned up and I have just emptied the backlog
of patches in patchwork.
This means only bug fixes from this point forward until I indicate
that net-next is open again.
Any patches submitted for net-next beforehand will be tossed from
patchwork, and must be resubmitted at the proper time when net-next is
open again.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: move procfs code to net/core/net-procfs.c
From: David Miller @ 2013-02-19 5:54 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev
In-Reply-To: <1361251233-25914-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 19 Feb 2013 13:20:33 +0800
> From: Cong Wang <xiyou.wangcong@gmail.com>
>
> Similar to net/core/net-sysfs.c, group procfs code to
> a single unit.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] qmi_wwan, cdc-ether: add ADU960S
From: David Miller @ 2013-02-19 5:54 UTC (permalink / raw)
To: dcbw-H+wXaHxf7aLQT0dZR+AlfA
Cc: bjorn-yOkvZcmFvRU, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1361244309.29695.12.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
From: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Mon, 18 Feb 2013 21:25:09 -0600
> It advertises a standard CDC-ETHER interface, which actually should be
> driven by qmi_wwan.
>
> Signed-off-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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