* [PATCH net 2/2] openvswitch: Store flow key len if ARP opcode is not request or reply.
From: Jesse Gross @ 2012-11-27 18:37 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
Mehak Mahajan
In-Reply-To: <1354041423-3050-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Mehak Mahajan <mmahajan-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
We currently only extract the ARP payload if the opcode indicates
that it is a request or reply. However, we also only set the
key length in these situations even though it should still be
possible to match on the opcode. There's no real reason to
restrict the ARP opcode since all have the same format so this
simply removes the check.
Signed-off-by: Mehak Mahajan <mmahajan-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/flow.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 98c7063..733cbf4 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -702,15 +702,11 @@ int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct sw_flow_key *key,
/* We only match on the lower 8 bits of the opcode. */
if (ntohs(arp->ar_op) <= 0xff)
key->ip.proto = ntohs(arp->ar_op);
-
- if (key->ip.proto == ARPOP_REQUEST
- || key->ip.proto == ARPOP_REPLY) {
- memcpy(&key->ipv4.addr.src, arp->ar_sip, sizeof(key->ipv4.addr.src));
- memcpy(&key->ipv4.addr.dst, arp->ar_tip, sizeof(key->ipv4.addr.dst));
- memcpy(key->ipv4.arp.sha, arp->ar_sha, ETH_ALEN);
- memcpy(key->ipv4.arp.tha, arp->ar_tha, ETH_ALEN);
- key_len = SW_FLOW_KEY_OFFSET(ipv4.arp);
- }
+ memcpy(&key->ipv4.addr.src, arp->ar_sip, sizeof(key->ipv4.addr.src));
+ memcpy(&key->ipv4.addr.dst, arp->ar_tip, sizeof(key->ipv4.addr.dst));
+ memcpy(key->ipv4.arp.sha, arp->ar_sha, ETH_ALEN);
+ memcpy(key->ipv4.arp.tha, arp->ar_tha, ETH_ALEN);
+ key_len = SW_FLOW_KEY_OFFSET(ipv4.arp);
}
} else if (key->eth.type == htons(ETH_P_IPV6)) {
int nh_len; /* IPv6 Header + Extensions */
--
1.7.9.5
^ permalink raw reply related
* [PATCH net 1/2] openvswitch: Print device when warning about over MTU packets.
From: Jesse Gross @ 2012-11-27 18:37 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1354041423-3050-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
If an attempt is made to transmit a packet that is over the device's
MTU then we log it using the datapath's name. However, it is much
more helpful to use the device name instead.
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/vport-netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
index 3c1e58b..a903348 100644
--- a/net/openvswitch/vport-netdev.c
+++ b/net/openvswitch/vport-netdev.c
@@ -158,7 +158,7 @@ static int netdev_send(struct vport *vport, struct sk_buff *skb)
if (unlikely(packet_length(skb) > mtu && !skb_is_gso(skb))) {
net_warn_ratelimited("%s: dropped over-mtu packet: %d > %d\n",
- ovs_dp_name(vport->dp),
+ netdev_vport->dev->name,
packet_length(skb), mtu);
goto error;
}
--
1.7.9.5
^ permalink raw reply related
* [GIT net] Open vSwitch
From: Jesse Gross @ 2012-11-27 18:37 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
These two small bug fixes are intended for 3.7/net if there is still time.
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git fixes
for you to fetch changes up to d04d382980c86bdee9960c3eb157a73f8ed230cc:
openvswitch: Store flow key len if ARP opcode is not request or reply. (2012-10-30 17:17:09 -0700)
----------------------------------------------------------------
Jesse Gross (1):
openvswitch: Print device when warning about over MTU packets.
Mehak Mahajan (1):
openvswitch: Store flow key len if ARP opcode is not request or reply.
net/openvswitch/flow.c | 14 +++++---------
net/openvswitch/vport-netdev.c | 2 +-
2 files changed, 6 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/1] net: ethernet: cpsw: fix build warnings for CPSW when CPTS not selected
From: Richard Cochran @ 2012-11-27 18:31 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem, linux-arm-kernel, linux-omap
In-Reply-To: <1354038820-11095-1-git-send-email-mugunthanvnm@ti.com>
On Tue, Nov 27, 2012 at 11:23:40PM +0530, Mugunthan V N wrote:
> CC drivers/net/ethernet/ti/cpsw.o
> drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_ndo_ioctl':
> drivers/net/ethernet/ti/cpsw.c:881:20: warning: unused variable 'priv'
>
> The build warning is generated when CPTS is not selected in Kernel Build.
> Fixing by passing the net_device pointer to cpts IOCTL instead of passing priv
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Thanks for this fix.
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc
From: Krzysztof Mazur @ 2012-11-27 18:28 UTC (permalink / raw)
To: David Woodhouse; +Cc: davem, netdev, linux-kernel, nathan
In-Reply-To: <1354039349.2534.11.camel@shinybook.infradead.org>
On Tue, Nov 27, 2012 at 06:02:29PM +0000, David Woodhouse wrote:
> On Tue, 2012-11-27 at 18:39 +0100, Krzysztof Mazur wrote:
> > Yes, I missed that one - it's even worse, I introduced that bug
> > in "[PATCH 1/7] atm: detach protocol before closing vcc". Before that
> > patch that scenario shouldn't happen because vcc was closed before
> > calling pppoatm_send(vcc, NULL) - the driver should provide appropriate
> > synchronization.
> >
> > I think that we should just drop that patch. With later changes it's not
> > necessary - the pppoatm_send() can be safely called while closing vcc.
>
> I'm not running with that patch. This bug exists for br2684 even before
> it, and I think also for pppoatm.
>
> In solos-pci at least, the ops->close() function doesn't flush all
> pending skbs for this vcc before returning. So can be a tasklet
> somewhere which has loaded the address of the vcc->pop function from one
> of them, and is going to call it in some unspecified amount of time.
>
> Should we make the device's ->close function wait for all TX and RX skbs
> for this vcc to complete?
Yes, the ->close() can sleep and after vcc is closed the ->pop() shouldn't be
called.
While reviewing your br2684 patch I also found that some ATM drivers does
not call ->pop() when ->send() fails, they should do:
if (vcc->pop)
vcc->pop(vcc, skb);
else
dev_kfree_skb(skb);
but some drivers just call dev_kfree_skb(skb).
I think that we should add atm_pop() function that does that and fix all
drivers.
Krzysiek
^ permalink raw reply
* RE: [E1000-devel] 82571EB: Detected Hardware Unit Hang
From: Fujinaka, Todd @ 2012-11-27 18:24 UTC (permalink / raw)
To: Ben Hutchings, Mary Mcgrath
Cc: Joe Jin, netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org, linux-pci
In-Reply-To: <1354039840.2701.14.camel@bwh-desktop.uk.solarflarecom.com>
Thanks for the clarification. I was just going by the PCIe spec, which says the lowest value of both ends is used, and I figured SOMETHING had to be looking at that and doing some sort of negotiation. I'm no BIOS guy, so I'm not sure what's actually going on, whether something walks the PCIe tree or if the BIOS just sets all the values to the minimum.
Todd Fujinaka
Technical Marketing Engineer
LAN Access Division (LAD)
Intel Corporation
todd.fujinaka@intel.com
(503) 712-4565
-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Tuesday, November 27, 2012 10:11 AM
To: Fujinaka, Todd; Mary Mcgrath
Cc: Joe Jin; netdev@vger.kernel.org; e1000-devel@lists.sf.net; linux-kernel@vger.kernel.org; linux-pci
Subject: RE: [E1000-devel] 82571EB: Detected Hardware Unit Hang
On Tue, 2012-11-27 at 17:32 +0000, Fujinaka, Todd wrote:
> Forgive me if I'm being too repetitious as I think some of this has
> been mentioned in the past.
>
> We (and by we I mean the Ethernet part and driver) can only change the
> advertised availability of a larger MaxPayloadSize. The size is
> negotiated by both sides of the link when the link is established. The
> driver should not change the size of the link as it would be poking at
> registers outside of its scope and is controlled by the upstream
> bridge (not us).
[...]
MaxPayloadSize (MPS) is not negotiated between devices but is programmed by the system firmware (at least for devices present at boot - the kernel may be responsible in case of hotplug). You can use the kernel parameter 'pci=pcie_bus_perf' (or one of several others) to set a policy that overrides this, but no policy will allow setting MPS above the device's MaxPayloadSizeSupported (MPSS).
(These parameters are not documented in
Documentation/kernel-parameters.txt! Someone ought to fix that.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes
From: Bjørn Mork @ 2012-11-27 18:12 UTC (permalink / raw)
To: Steve Glendinning; +Cc: netdev, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKh2mn7f94a7La_EQ9L_qwr7FZEXfawUiAajPMDO8ScS2fJupg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Steve Glendinning <steve-nksJyM/082jR7s880joybQ@public.gmane.org> writes:
> Hi Bjorn,
>
> On 27 November 2012 17:21, Steve Glendinning <steve-nksJyM/082jR7s880joybQ@public.gmane.org> wrote:
>> Hi Bjorn,
>>
>>>> + smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
>>>
>>> As mentioned in another comment to the smsc95xx driver: This is weird.
>>> Do you really need to do that?
>>>
>>> This is an USB interface driver. The USB device is handled by the
>>> generic "usb" driver, which will do the right thing. See
>>> drivers/usb/generic.c and drivers/usb/core/hub.c
>>
>> Thanks, I've tested removing all these calls from the driver and
>> wakeup functionality seems to still work.
>>
>> I'll resubmit my smsc75xx enhancement patchset with this change once
>> I've done some more testing.
>
> Further testing shows that removing these calls stop wakeup from
> system suspend working (although don't appear to impact runtime
> autosuspend). Have I missed a flag or somewhere that causes
> udev->do_remote_wakeup to be set in the code you posted?
udev->do_remote_wakeup is set in choose_wakeup() in
drivers/usb/core/driver.c. AFAICS it is always set as long as
device_may_wakeup(&udev->dev) is true.
But I am just trying to get a grasp of this code. Others on the
linux-usb list will know these things much better than me...
Just a thought: Did you remember to remove the clear_feature you have in
resume?
Bjørn
--
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
* RE: [E1000-devel] 82571EB: Detected Hardware Unit Hang
From: Ben Hutchings @ 2012-11-27 18:10 UTC (permalink / raw)
To: Fujinaka, Todd, Mary Mcgrath
Cc: Joe Jin, netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org, linux-pci
In-Reply-To: <9B4A1B1917080E46B64F07F2989DADD62F2D8070@ORSMSX102.amr.corp.intel.com>
On Tue, 2012-11-27 at 17:32 +0000, Fujinaka, Todd wrote:
> Forgive me if I'm being too repetitious as I think some of this has
> been mentioned in the past.
>
> We (and by we I mean the Ethernet part and driver) can only change the
> advertised availability of a larger MaxPayloadSize. The size is
> negotiated by both sides of the link when the link is established. The
> driver should not change the size of the link as it would be poking at
> registers outside of its scope and is controlled by the upstream
> bridge (not us).
[...]
MaxPayloadSize (MPS) is not negotiated between devices but is programmed
by the system firmware (at least for devices present at boot - the
kernel may be responsible in case of hotplug). You can use the kernel
parameter 'pci=pcie_bus_perf' (or one of several others) to set a policy
that overrides this, but no policy will allow setting MPS above the
device's MaxPayloadSizeSupported (MPSS).
(These parameters are not documented in
Documentation/kernel-parameters.txt! Someone ought to fix that.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc
From: David Woodhouse @ 2012-11-27 18:02 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: davem, netdev, linux-kernel, nathan
In-Reply-To: <20121127173906.GA11390@shrek.podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
On Tue, 2012-11-27 at 18:39 +0100, Krzysztof Mazur wrote:
> Yes, I missed that one - it's even worse, I introduced that bug
> in "[PATCH 1/7] atm: detach protocol before closing vcc". Before that
> patch that scenario shouldn't happen because vcc was closed before
> calling pppoatm_send(vcc, NULL) - the driver should provide appropriate
> synchronization.
>
> I think that we should just drop that patch. With later changes it's not
> necessary - the pppoatm_send() can be safely called while closing vcc.
I'm not running with that patch. This bug exists for br2684 even before
it, and I think also for pppoatm.
In solos-pci at least, the ops->close() function doesn't flush all
pending skbs for this vcc before returning. So can be a tasklet
somewhere which has loaded the address of the vcc->pop function from one
of them, and is going to call it in some unspecified amount of time.
Should we make the device's ->close function wait for all TX and RX skbs
for this vcc to complete?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: TCP and reordering
From: Rick Jones @ 2012-11-27 18:00 UTC (permalink / raw)
To: Saku Ytti; +Cc: netdev
In-Reply-To: <CAAeewD9MtEx4uF6ezbBj7Ci5OzX8VK7p=WQ2TB3PfjmznA4X0w@mail.gmail.com>
On 11/27/2012 09:15 AM, Saku Ytti wrote:
> On 27 November 2012 19:05, Rick Jones <rick.jones2@hp.com> wrote:
>
>> Packet reordering is supposed to be the exception, not the rule.
>> Links which habitually/constantly introduce reordering are, in my
>> opinion, broken. Optimizing for them would be optimizing an error
>> case.
>
> TCP used to be friendly to reordering before fast retransmit
> optimization was implemented.
It remained "friendly" to reordering even after fast retransmit was
implemented - just not to particularly bad reordering.
And friendly is somewhat relative. Even before fast retransmit came to
be, TCP would immediately ACK each out-of-order segment.
> It seems like minimal complexity in TCP algorithm and would
> dynamically work correctly depending on situation. It is rather slim
> comfort that network should work, when it does not, and you cannot
> affect it.
It is probably considered an "ancient" text these days, but one of the
chapter intros for The Mythical Man Month includes a quote from Ovid:
adde parvum parvo magnus acervus erit
which if recollection serves the book translated as:
add little to little and soon there will be a big pile.
> But if the complexity is higher than I expect, then I fully agree,
> makes no sense to add it. Reason why reordering can happen in modern
> MPLS network is that you have to essentially duck type your traffic,
> and sometimes you duck type them wrong and you are then calculating
> ECMP on incorrect values, causing packets inside flow to take
> different ports.
I appreciate that one may not always have "access" and there can be
layer 8 and layer 9 issues involved, but if incorrect typing is the root
cause of the reordering, treating root cause rather than the symptom is
what should happen. How many kludges, no matter how angelic, can fit in
a TCP implementation?
For other reasons (CPU utilization) various stacks (HP-UX, Solaris, some
versions of MacOS) have had explicit ACK-avoidance heuristics. They
would back-off from ack-every-other to back-every-N, N >> 2. The
heuristics worked quite well in LAN environments and on bulk flows (eg
FTP, ttcp, netperf TCP_STREAM), not necessarily as well in other
environments. One (very necessary) part of the heuristic in those is
to go back to ack-every-other when necessary. That keyed off the
standalone ACK timer - if that ever fired the current avoidance count
would go back to 2, and the max allowed would be half what it was
before. However, that took a non-trivial performance hit when there was
"tail-drop" and something that wasn't a continuous stream of traffic -
the tail got dropped, nothing to cause out-of-order to force immediate
ACKs. (*) Standalone ACK timer is then the only thing getting us back
out which means idleness. I worked a number of "WAN performance
problems" involving one of those stacks where part of the solution was
turning down the limits on the ack avoidance heuristic by a considerable
quantity. (And I say this as someone with a fondness for the schemes)
I cannot say with certainty your idea would have the same problems but
as you look to work-out a solution to propose as a patch, you will have
to keep that in mind.
rick
* yes, the same holds true for a non-ack-avoiding setup, the heuristic
simply made it worse - especially if the sender wanted to send but had
gotten limited by cwnd - the ACK(s) of the head of that chunk of data
were "avoided" and so wouldn't open the cwnd which might then allow
futher segments to enable detection of the dropped segments. Even
without losses it also tended to interact poorly with sending TCPs which
wantend to increase the congestion window by one MSS for each ACK rather
than based on the quantity of bytes covered by the ACK.
^ permalink raw reply
* Re: [PATCH for 3.8] iproute2: Add "ip netns pids" and "ip netns identify"
From: Ben Hutchings @ 2012-11-27 18:00 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Stephen Hemminger, netdev, Serge E. Hallyn
In-Reply-To: <87a9u4q7k9.fsf@xmission.com>
On Mon, 2012-11-26 at 17:16 -0600, Eric W. Biederman wrote:
> Add command that go between network namespace names and process
> identifiers. The code builds and runs agains older kernels but
> only works on Linux 3.8+ kernels where I have fixed stat to work
> properly.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
>
> I don't know if this is too soon to send this patch to iproute as the
> kernel code that fixes stat is currently sitting in my for-next branch
> of:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
>
> and has not hit Linus's tree yet. Still the code runs and is harmless
> on older kernels so it should be harmless whatever happens with it.
>
> ip/ipnetns.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++++++
> man/man8/ip-netns.8 | 5 ++-
> 2 files changed, 145 insertions(+), 1 deletions(-)
>
> diff --git a/ip/ipnetns.c b/ip/ipnetns.c
> index e41a598..c55fe3a 100644
> --- a/ip/ipnetns.c
> +++ b/ip/ipnetns.c
> @@ -13,6 +13,7 @@
> #include <dirent.h>
> #include <errno.h>
> #include <unistd.h>
> +#include <ctype.h>
>
> #include "utils.h"
> #include "ip_common.h"
> @@ -48,6 +49,8 @@ static void usage(void)
> fprintf(stderr, "Usage: ip netns list\n");
> fprintf(stderr, " ip netns add NAME\n");
> fprintf(stderr, " ip netns delete NAME\n");
> + fprintf(stderr, " ip netns identify PID\n");
> + fprintf(stderr, " ip netns pids NAME\n");
> fprintf(stderr, " ip netns exec NAME cmd ...\n");
> fprintf(stderr, " ip netns monitor\n");
> exit(-1);
> @@ -171,6 +174,138 @@ static int netns_exec(int argc, char **argv)
> exit(-1);
> }
>
> +static int is_pid(const char *str)
> +{
> + int ch;
> + for (; (ch = *str); str++) {
> + if (!isdigit(ch))
ch must be cast to unsigned char before passing to isdigit().
> + return 0;
> + }
> + return 1;
> +}
> +
> +static int netns_pids(int argc, char **argv)
> +{
> + const char *name;
> + char net_path[MAXPATHLEN];
> + int netns;
> + struct stat netst;
> + DIR *dir;
> + struct dirent *entry;
> +
> + if (argc < 1) {
> + fprintf(stderr, "No netns name specified\n");
> + return -1;
> + }
> + if (argc > 1) {
> + fprintf(stderr, "extra arguments specified\n");
> + return -1;
> + }
These, and many other return statements in this file which set the
process exit code, should return 1 (general failure) or 2 (user error)
rather than -1 (likely to be interpreted as command not found).
> + name = argv[0];
> + snprintf(net_path, sizeof(net_path), "%s/%s", NETNS_RUN_DIR, name);
No check for truncation?
> + netns = open(net_path, O_RDONLY);
This file descriptor is leaked, though that probably doesn't really
matter.
[...]
> +static int netns_identify(int argc, char **argv)
> +{
> + const char *pidstr;
> + char net_path[MAXPATHLEN];
> + int netns;
> + struct stat netst;
> + DIR *dir;
> + struct dirent *entry;
> +
> + if (argc < 1) {
> + fprintf(stderr, "No pid specified\n");
> + return -1;
> + }
> + if (argc > 1) {
> + fprintf(stderr, "extra arguments specified\n");
> + return -1;
> + }
> + pidstr = argv[0];
> +
> + if (!is_pid(pidstr)) {
> + fprintf(stderr, "Specified string '%s' is not a pid\n",
> + pidstr);
> + return -1;
> + }
> +
> + snprintf(net_path, sizeof(net_path), "/proc/%s/ns/net", pidstr);
> + netns = open(net_path, O_RDONLY);
> + if (netns < 0) {
> + fprintf(stderr, "Cannot open network namespace: %s\n",
> + strerror(errno));
> + return -1;
> + }
> + if (fstat(netns, &netst) < 0) {
> + fprintf(stderr, "Stat of netns failed: %s\n",
> + strerror(errno));
> + return -1;
> + }
> + dir = opendir(NETNS_RUN_DIR);
> + if (!dir)
> + return 0;
Shouldn't this be treated as an error? Or, if you want it to succeed
when the kernel does not have netns functionality, then treat it as an
error if !dir && errno != ENOENT.
> + while((entry = readdir(dir))) {
> + char name_path[MAXPATHLEN];
> + struct stat st;
> +
> + if (strcmp(entry->d_name, ".") == 0)
> + continue;
> + if (strcmp(entry->d_name, "..") == 0)
> + continue;
> +
> + snprintf(name_path, sizeof(name_path), "%s/%s", NETNS_RUN_DIR,
> + entry->d_name);
> +
> + if (stat(name_path, &st) != 0)
> + continue;
> +
> + if ((st.st_dev == netst.st_dev) &&
> + (st.st_ino == netst.st_ino)) {
> + printf("%s\n", entry->d_name);
> + }
> + }
> + closedir(dir);
> + return 0;
> +
> +}
[...]
It's a shame there isn't a more efficient way to do these lookups.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes
From: Steve Glendinning @ 2012-11-27 17:55 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKh2mn4OiN7ZAX_0SJ_XHwRNPoyKUk=+4ha5esBMAajGD4BX=w@mail.gmail.com>
Hi Bjorn,
On 27 November 2012 17:21, Steve Glendinning <steve-nksJyM/082jR7s880joybQ@public.gmane.org> wrote:
> Hi Bjorn,
>
>>> + smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
>>
>> As mentioned in another comment to the smsc95xx driver: This is weird.
>> Do you really need to do that?
>>
>> This is an USB interface driver. The USB device is handled by the
>> generic "usb" driver, which will do the right thing. See
>> drivers/usb/generic.c and drivers/usb/core/hub.c
>
> Thanks, I've tested removing all these calls from the driver and
> wakeup functionality seems to still work.
>
> I'll resubmit my smsc75xx enhancement patchset with this change once
> I've done some more testing.
Further testing shows that removing these calls stop wakeup from
system suspend working (although don't appear to impact runtime
autosuspend). Have I missed a flag or somewhere that causes
udev->do_remote_wakeup to be set in the code you posted?
--
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
* [PATCH 1/1] net: ethernet: cpsw: fix build warnings for CPSW when CPTS not selected
From: Mugunthan V N @ 2012-11-27 17:53 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-arm-kernel, linux-omap, richardcochran,
Mugunthan V N
CC drivers/net/ethernet/ti/cpsw.o
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_ndo_ioctl':
drivers/net/ethernet/ti/cpsw.c:881:20: warning: unused variable 'priv'
The build warning is generated when CPTS is not selected in Kernel Build.
Fixing by passing the net_device pointer to cpts IOCTL instead of passing priv
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 02c2477..c9714e1 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -812,8 +812,9 @@ static void cpsw_hwtstamp_v2(struct cpsw_priv *priv)
__raw_writel(ETH_P_1588, &priv->regs->ts_ltype);
}
-static int cpsw_hwtstamp_ioctl(struct cpsw_priv *priv, struct ifreq *ifr)
+static int cpsw_hwtstamp_ioctl(struct net_device *dev, struct ifreq *ifr)
{
+ struct cpsw_priv *priv = netdev_priv(dev);
struct cpts *cpts = &priv->cpts;
struct hwtstamp_config cfg;
@@ -878,14 +879,12 @@ static int cpsw_hwtstamp_ioctl(struct cpsw_priv *priv, struct ifreq *ifr)
static int cpsw_ndo_ioctl(struct net_device *dev, struct ifreq *req, int cmd)
{
- struct cpsw_priv *priv = netdev_priv(dev);
-
if (!netif_running(dev))
return -EINVAL;
#ifdef CONFIG_TI_CPTS
if (cmd == SIOCSHWTSTAMP)
- return cpsw_hwtstamp_ioctl(priv, req);
+ return cpsw_hwtstamp_ioctl(dev, req);
#endif
return -ENOTSUPP;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] smsc95xx: fix suspend buffer overflow
From: Joe Perches @ 2012-11-27 17:42 UTC (permalink / raw)
To: Steve Glendinning; +Cc: netdev, dan.carpenter
In-Reply-To: <1354022623-7317-1-git-send-email-steve.glendinning@shawell.net>
On Tue, 2012-11-27 at 13:23 +0000, Steve Glendinning wrote:
> This patch fixes a buffer overflow introduced by bbd9f9e, where
> the filter_mask array is accessed beyond its bounds.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
> ---
> drivers/net/usb/smsc95xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index 79d495d..6cdc504 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -1281,7 +1281,7 @@ static int smsc95xx_suspend(struct usb_interface *intf, pm_message_t message)
> }
>
> if (pdata->wolopts & (WAKE_BCAST | WAKE_MCAST | WAKE_ARP | WAKE_UCAST)) {
> - u32 *filter_mask = kzalloc(32, GFP_KERNEL);
> + u32 *filter_mask = kzalloc(sizeof(u32) * 32, GFP_KERNEL);
It's also unchecked for alloc failure.
> u32 command[2];
> u32 offset[2];
> u32 crc[4];
^ permalink raw reply
* Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc
From: Krzysztof Mazur @ 2012-11-27 17:39 UTC (permalink / raw)
To: David Woodhouse; +Cc: davem, netdev, linux-kernel, nathan
In-Reply-To: <1354036592.2534.6.camel@shinybook.infradead.org>
On Tue, Nov 27, 2012 at 05:16:32PM +0000, David Woodhouse wrote:
> Krzysztof, you've fixed a bunch of races... but I think there's one
> still left.
>
> An ATM driver will often have code like this, which gets called from
> arbitrary contexts:
> if (vcc->pop)
> vcc->pop(vcc, skb);
>
> Now, what happens if pppoatm_send(vcc, NULL) happens after the address
> of vcc->pop (currently pppoatm_pop) has been loaded, but before the
> function is actually called?
>
> You tear down all the setup and set vcc->user_back to NULL. And then
> pppoatm_pop() gets called. And promptly crashes because pvcc is NULL.
>
> A lot of these problems exist for br2684 too, and in prodding at it a
> little I can consistently crash the system by sending a flood of
> outbound packets while I kill the br2684ctl program. I end up in
> br2684_pop() with vcc->user_back == NULL. In looking to see how you'd
> fixed that in pppoatm, I realised that you haven't... :)
>
Yes, I missed that one - it's even worse, I introduced that bug
in "[PATCH 1/7] atm: detach protocol before closing vcc". Before that
patch that scenario shouldn't happen because vcc was closed before
calling pppoatm_send(vcc, NULL) - the driver should provide appropriate
synchronization.
I think that we should just drop that patch. With later changes it's not
necessary - the pppoatm_send() can be safely called while closing vcc.
Krzysiek
^ permalink raw reply
* RE: [E1000-devel] 82571EB: Detected Hardware Unit Hang
From: Fujinaka, Todd @ 2012-11-27 17:32 UTC (permalink / raw)
To: Mary Mcgrath, Joe Jin
Cc: netdev@vger.kernel.org, e1000-devel@lists.sf.net,
linux-kernel@vger.kernel.org
In-Reply-To: <b46b84cf-3688-4fd7-b741-4e96f2663517@default>
Forgive me if I'm being too repetitious as I think some of this has been mentioned in the past.
We (and by we I mean the Ethernet part and driver) can only change the advertised availability of a larger MaxPayloadSize. The size is negotiated by both sides of the link when the link is established. The driver should not change the size of the link as it would be poking at registers outside of its scope and is controlled by the upstream bridge (not us).
You also need to check all the PCIe links to get to the device. There can be several to get from the root complex, through bridges, to the endpoint Ethernet controller. The Ethernet part and driver has no control over any other links. You'll have to talk to the motherboard manufacturer about those links.
Your original problem appears to be hangs and Tushar asked you to the entire path of PCIe connections from the root complex to the endpoint. Any mismatches in payload can cause hangs and I believe you have had the problem in the past. I'm sure you remember all the lspci commands to list the tree view and to dump all the details from each of the links and I would suggest you do that to check to see that the payload sizes match. What I do is "lspci -tvvv" to see what's connected, then "lspci -s xx:xx.x -vvv" to check the devices on the link.
Thanks.
Todd Fujinaka
Technical Marketing Engineer
LAN Access Division (LAD)
Intel Corporation
todd.fujinaka@intel.com
(503) 712-4565
-----Original Message-----
From: Mary Mcgrath [mailto:mary.mcgrath@oracle.com]
Sent: Monday, November 26, 2012 6:07 PM
To: Joe Jin
Cc: netdev@vger.kernel.org; e1000-devel@lists.sf.net; linux-kernel@vger.kernel.org
Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
Joe
Thank you for working this.
I would love to find out how they expect a customer to make the modification To "word 0x1A, and see if the 8th bit is 0 or 1, and to change to 0."
I have in turn asked the ct for the lspci command on eth3, maybe the incorrect setting is upstream.
Again, thank you.
Regards
Mary
-----Original Message-----
From: Joe Jin
Sent: Monday, November 26, 2012 8:00 PM
To: Fujinaka, Todd
Cc: Dave, Tushar N; netdev@vger.kernel.org; e1000-devel@lists.sf.net; linux-kernel@vger.kernel.org; Mary Mcgrath
Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
On 11/27/12 00:23, Fujinaka, Todd wrote:
> If you look at the previous section, DevCap, you'll see that it's
> correctly advertising 256 bytes but the system is negotiating 128 for
> the link to the Ethernet controller. Things on the "other" side of the
> link are controlled outside of the e1000 driver.
>
> Tushar's first suggestion was to check the PCIe payload settings in
> the entire chain. Have you done that? Mismatches will cause hangs.
Hi Todd,
So far I had to know how to modify the maxpayload size, since BIOS have not entry to change this, so I had to use ethtool, now I need to get the offset of MaxPayload size in eeprom, I ever tried to find from Intel online document but failed, any idea?
Thanks in advance,
Joe
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [patch] atm: forever loop loading ambassador firmware
From: Dan Carpenter @ 2012-11-27 17:29 UTC (permalink / raw)
To: Chas Williams, David Woodhouse; +Cc: linux-atm-general, netdev, kernel-janitors
There was a forever loop introduced here when we converted this to
request_firmware() back in 2008.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Spotted in code reading. Untested.
diff --git a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c
index 89b30f3..ff7bb8a 100644
--- a/drivers/atm/ambassador.c
+++ b/drivers/atm/ambassador.c
@@ -1961,6 +1961,7 @@ static int __devinit ucode_init (loader_block * lb, amb_dev * dev) {
res = loader_verify(lb, dev, rec);
if (res)
break;
+ rec = ihex_next_binrec(rec);
}
release_firmware(fw);
if (!res)
^ permalink raw reply related
* Re: [PATCH 2/2] smsc75xx: support PHY wakeup source
From: Steve Glendinning @ 2012-11-27 17:23 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, David Miller
In-Reply-To: <1354031804.2116.8.camel@joe-AO722>
Hi Joe,
On 27 November 2012 15:56, Joe Perches <joe@perches.com> wrote:
> On Tue, 2012-11-27 at 14:28 +0000, Steve Glendinning wrote:
>> + ret = smsc75xx_read_reg_nopm(dev, PMT_CTL, &val);
>> + check_warn_return(ret, "Error reading PMT_CTL");
>
> Hi Steve, can you please add newlines to these new
> check_warn_<foo> messages and the netdev_<level> ones too?
> It helps avoid message interleaving.
Sorry about that, I did see your earlier patch to fix existing instances.
David: please discard this patch too, I'll resubmit.
^ permalink raw reply
* Re: [PATCH net-next] net: move inet_dport/inet_num in sock_common
From: Joe Perches @ 2012-11-27 17:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Ling Ma
In-Reply-To: <1354028815.14302.35.camel@edumazet-glaptop>
On Tue, 2012-11-27 at 07:06 -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> commit 68835aba4d9b (net: optimize INET input path further)
> moved some fields used for tcp/udp sockets lookup in the first cache
> line of struct sock_common.
[]
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index 5e11905..196ede4 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -365,19 +365,21 @@ static inline struct raw6_sock *raw6_sk(const struct sock *sk)
> #endif /* IS_ENABLED(CONFIG_IPV6) */
>
> #define INET6_MATCH(__sk, __net, __hash, __saddr, __daddr, __ports, __dif)\
> + (((__sk)->sk_hash == (__hash)) && \
> + ((*((__portpair *)&(inet_sk(__sk)->inet_dport))) == (__ports)) && \
> + ((__sk)->sk_family == AF_INET6) && \
Perhaps these could be |'d together to avoid the test/jump
after each comparison by using some bit operations instead.
> + ipv6_addr_equal(&inet6_sk(__sk)->daddr, (__saddr)) && \
> + ipv6_addr_equal(&inet6_sk(__sk)->rcv_saddr, (__daddr)) && \
> + (!((__sk)->sk_bound_dev_if) || ((__sk)->sk_bound_dev_if == (__dif))) && \
> + net_eq(sock_net(__sk), (__net)))
^ permalink raw reply
* Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes
From: Steve Glendinning @ 2012-11-27 17:21 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <87624r9k1f.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
Hi Bjorn,
>> + smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
>
> As mentioned in another comment to the smsc95xx driver: This is weird.
> Do you really need to do that?
>
> This is an USB interface driver. The USB device is handled by the
> generic "usb" driver, which will do the right thing. See
> drivers/usb/generic.c and drivers/usb/core/hub.c
Thanks, I've tested removing all these calls from the driver and
wakeup functionality seems to still work.
I'll resubmit my smsc75xx enhancement patchset with this change once
I've done some more testing.
David: please discard this patch.
--
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
* Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc
From: David Woodhouse @ 2012-11-27 17:16 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: davem, netdev, linux-kernel, nathan
In-Reply-To: <1350926091-12642-3-git-send-email-krzysiek@podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
Krzysztof, you've fixed a bunch of races... but I think there's one
still left.
An ATM driver will often have code like this, which gets called from
arbitrary contexts:
if (vcc->pop)
vcc->pop(vcc, skb);
Now, what happens if pppoatm_send(vcc, NULL) happens after the address
of vcc->pop (currently pppoatm_pop) has been loaded, but before the
function is actually called?
You tear down all the setup and set vcc->user_back to NULL. And then
pppoatm_pop() gets called. And promptly crashes because pvcc is NULL.
A lot of these problems exist for br2684 too, and in prodding at it a
little I can consistently crash the system by sending a flood of
outbound packets while I kill the br2684ctl program. I end up in
br2684_pop() with vcc->user_back == NULL. In looking to see how you'd
fixed that in pppoatm, I realised that you haven't... :)
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: TCP and reordering
From: Saku Ytti @ 2012-11-27 17:15 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <50B4F2DA.8020206@hp.com>
On 27 November 2012 19:05, Rick Jones <rick.jones2@hp.com> wrote:
> Packet reordering is supposed to be the exception, not the rule. Links
> which habitually/constantly introduce reordering are, in my opinion, broken.
> Optimizing for them would be optimizing an error case.
TCP used to be friendly to reordering before fast retransmit
optimization was implemented.
It seems like minimal complexity in TCP algorithm and would
dynamically work correctly depending on situation. It is rather slim
comfort that network should work, when it does not, and you cannot
affect it.
But if the complexity is higher than I expect, then I fully agree,
makes no sense to add it. Reason why reordering can happen in modern
MPLS network is that you have to essentially duck type your traffic,
and sometimes you duck type them wrong and you are then calculating
ECMP on incorrect values, causing packets inside flow to take
different ports.
--
++ytti
^ permalink raw reply
* Re: TCP and reordering
From: Rick Jones @ 2012-11-27 17:05 UTC (permalink / raw)
To: Saku Ytti; +Cc: netdev
In-Reply-To: <CAAeewD8zsfb6QPFecvPab_oK3D3T7eG_M53MVvfJ2QrxUFxWSQ@mail.gmail.com>
On 11/27/2012 01:32 AM, Saku Ytti wrote:
> Today due to fast retransmit performance on links which cause
> reordering is appalling.
>
> Is it too esoteric situation to handle gracefully? Couldn't we
> maintain 'reorder' counter in socket, which is increment when we get
> two copies of same packet after duplicate ack, if this counter is
> sufficiently high in relation to packet loss, we could start delaying
> duplicate acks as we'd expect to receive the sequence very soon.
Packet reordering is supposed to be the exception, not the rule. Links
which habitually/constantly introduce reordering are, in my opinion,
broken. Optimizing for them would be optimizing an error case.
That said, there is net.ipv4.tcp_reordering which you can increase from
the default of three to desensitize TCP to such broken links. That will
though be on the sending rather than receiving side.
rick jones
^ permalink raw reply
* Re: [net-next RFC] pktgen: don't wait for the device who doesn't free skb immediately after sent
From: Stephen Hemminger @ 2012-11-27 16:49 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, netdev, linux-kernel, virtualization, davem
In-Reply-To: <50B46179.4040809@redhat.com>
On Tue, 27 Nov 2012 14:45:13 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 11/27/2012 01:37 AM, Stephen Hemminger wrote:
> > On Mon, 26 Nov 2012 15:56:52 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >
> >> Some deivces do not free the old tx skbs immediately after it has been sent
> >> (usually in tx interrupt). One such example is virtio-net which optimizes for
> >> virt and only free the possible old tx skbs during the next packet sending. This
> >> would lead the pktgen to wait forever in the refcount of the skb if no other
> >> pakcet will be sent afterwards.
> >>
> >> Solving this issue by introducing a new flag IFF_TX_SKB_FREE_DELAY which could
> >> notify the pktgen that the device does not free skb immediately after it has
> >> been sent and let it not to wait for the refcount to be one.
> >>
> >> Signed-off-by: Jason Wang <jasowang@redhat.com>
> > Another alternative would be using skb_orphan() and skb->destructor.
> > There are other cases where skb's are not freed right away.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> Hi Stephen:
>
> Do you mean registering a skb->destructor for pktgen then set and check
> bits in skb->tx_flag?
Yes. Register a destructor that does something like update a counter (number of packets pending),
then just spin while number of packets pending is over threshold.
^ permalink raw reply
* Arp problems after upgrade to 3.6
From: Phil Oester @ 2012-11-27 16:29 UTC (permalink / raw)
To: netdev
Upgraded a box to 3.6.7 yesterday, and started noticing it becoming
unreachable occasionally. Watching arp traffic, it appears it is
sometimes arping for the gateway using the wrong source IP in the requests.
Sample trace from bond1:
11:10:13.489388 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:10:14.489372 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:10:15.489358 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:10:16.489517 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:10:16.489518 ARP, Request who-has 10.253.128.13 tell 10.253.128.14, length 28
11:10:16.490025 ARP, Reply 10.253.128.13 is-at 00:d0:04:b1:d4:00, length 46
11:11:43.618851 ARP, Request who-has 10.253.128.13 tell 10.253.128.14, length 28
11:11:43.619406 ARP, Reply 10.253.128.13 is-at 00:d0:04:b1:d4:00, length 46
11:15:05.792656 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:15:06.789369 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:15:07.789338 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:15:08.789939 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
Seems to be getting bond0 and bond1 IPs confused here:
12: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether xx:xx:xx:xx:xx:20 brd ff:ff:ff:ff:ff:ff
inet 10.253.128.6/30 brd 10.253.128.7 scope global bond0
17: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether xx:xx:xx:xx:xx:22 brd ff:ff:ff:ff:ff:ff
inet 10.253.128.14/30 brd 10.253.128.15 scope global bond1
This box is still up, so if there is any additional information I can provide
before rebooting it, please let me know.
Phil Oester
^ 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