* HELLO !!!
From: William Lee Cheng @ 2012-11-08 15:53 UTC (permalink / raw)
Dear Friend,
Greetings to you, I have a business proposal for you that will be
beneficial to the both of us.This proposal has to do with funds transfer.
In confirmation of your acceptance,I would need you to provide me with
your full names, current house and mailing address,date of birth telephone
and fax numbers so as to be very confident that I am dealing with the
right person.(This is very important).
Once I have received confirmation from you with the required information,
I shall then send you further details about this transaction and how it
will be executed. I look forward to hearing from you soonest and hope that
this marks the beginning of a successful and long lasting business
relationship with you. My profound greetings to you and your family.
Best regards,
William Lee Cheng.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH net-next] netconsole: add oops_only module option
From: Randy Dunlap @ 2012-11-08 19:49 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David Miller
In-Reply-To: <1352382158-3928-1-git-send-email-amwang@redhat.com>
On 11/08/2012 05:42 AM, Cong Wang wrote:
> Some people wants to log only oops messages via netconsole,
> (this is also why netoops was invented)
> so add a module option for netconsole. This can be tuned
> via /sys/module/netconsole/parameters/oops_only at run time
> as well.
>
Hi,
What does this do with panics?
Do they set oops_in_progress?
thanks.
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
>
> ---
> diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> index b332112..6989ebe 100644
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -56,6 +56,10 @@ static char config[MAX_PARAM_LENGTH];
> module_param_string(netconsole, config, MAX_PARAM_LENGTH, 0);
> MODULE_PARM_DESC(netconsole, " netconsole=[src-port]@[src-ip]/[dev],[tgt-port]@<tgt-ip>/[tgt-macaddr]");
>
> +static bool oops_only = false;
> +module_param(oops_only, bool, 0600);
> +MODULE_PARM_DESC(oops_only, "Only log oops messages");
> +
> #ifndef MODULE
> static int __init option_setup(char *opt)
> {
> @@ -683,6 +687,8 @@ static void write_msg(struct console *con, const char *msg, unsigned int len)
> struct netconsole_target *nt;
> const char *tmp;
>
> + if (oops_only && !oops_in_progress)
> + return;
> /* Avoid taking lock and disabling interrupts unnecessarily */
> if (list_empty(&target_list))
> return;
> --
--
~Randy
^ permalink raw reply
* [PATCH] qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
From: Dan Williams @ 2012-11-08 18:14 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, netdev, linux-usb
The Dell Wireless 5800 appears to be a Novatel E362 rebrand.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
---
Greg: CC-ed to linux-usb@ for visibility but should go through davem
drivers/net/usb/cdc_ether.c | 15 +++++++++++++++
drivers/net/usb/qmi_wwan.c | 14 ++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index d095b39..a74f35f 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -487,6 +487,7 @@ static const struct driver_info wwan_info = {
#define HUAWEI_VENDOR_ID 0x12D1
#define NOVATEL_VENDOR_ID 0x1410
#define ZTE_VENDOR_ID 0x19D2
+#define DELL_VENDOR_ID 0x413C
static const struct usb_device_id products [] = {
/*
@@ -606,6 +607,20 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
+/* Dell Wireless 5800 (Novatel E362) - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8195, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
+/* Dell Wireless 5800 V2 (Novatel E362) - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8196, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
/*
* WHITELIST!!!
*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3b566fa..28a76b2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -383,6 +383,20 @@ static const struct usb_device_id products[] = {
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&qmi_wwan_info,
},
+ { /* Dell Wireless 5800 (Novatel E362) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8195,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
+ { /* Dell Wireless 5800 V2 (Novatel E362) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8196,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
--
1.7.11.7
^ permalink raw reply related
* [PATCH] cdc_ether: use USB_DEVICE_AND_INTERFACE_INFO for Novatel 551L/E362
From: Dan Williams @ 2012-11-08 18:09 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, netdev
Small cleanup.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/net/usb/cdc_ether.c | 20 ++++----------------
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index d012982..d095b39 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -594,27 +594,15 @@ static const struct usb_device_id products [] = {
/* Novatel USB551L and MC551 - handled by qmi_wwan */
{
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0xB001,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0xB001, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
},
/* Novatel E362 - handled by qmi_wwan */
{
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0x9010,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0x9010, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
},
^ permalink raw reply related
* explaining the math behind the buffering done in USB network drivers
From: Oliver Neukum @ 2012-11-08 17:35 UTC (permalink / raw)
To: Robert Bradley, Dave Taht, Jim Gettys, netdev
Hi,
it is probably necessary to state the limitations of USB to understand
why we buffer as much data as we buffer. Basically the schedule on
the USB bus is set in stone for a period of 1ms(full speed). This means that a driver
has to have submitted to USB core enough data to fill _2_ such periods
at all times. Thus the schedule for the current period is filled up and the
host controller can seamlessly switch to the next period.
In addition the driver has to be ready to provide the data for the next period
as soon as one period is done.
Thus conceptually for USB we do tripple-buffering.
Few drivers actually express this logic internally. One usually calculates
a rough approximation, but this is the logic behind the thing.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-08 17:18 UTC (permalink / raw)
To: Shan Wei
Cc: dev-yBygre7rU0TnMu66kgdUjQ, NetDev, Kernel-Maillist, David Miller
In-Reply-To: <509BC026.4040209-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 8 Nov 2012, Shan Wei wrote:
> Christoph Lameter said, at 2012/11/3 1:46:
> >> u64_stats_update_begin(&stats->sync);
> >> stats->tx_packets++;
> >
> > Use this_cpu_inc(vport->percpu_stats->packets) here?
>
> Lots of network drivers use u64_stats_sync infrastructure for statistics
So they would all have an advantage from the patch.
^ permalink raw reply
* Re: [net-next:master 232/235] drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:7053:6: sparse: symbol 'bnx2x_init_searcher' was not declared. Should it be static?
From: Ben Hutchings @ 2012-11-08 17:15 UTC (permalink / raw)
To: Merav Sicron; +Cc: Fengguang Wu, Dmitry Kravkov, Eilon Greenstein, netdev
In-Reply-To: <1352390951.5555.5.camel@lb-tlvb-meravs.il.broadcom.com>
On Thu, 2012-11-08 at 18:09 +0200, Merav Sicron wrote:
> On Thu, 2012-11-08 at 17:38 +0800, Fengguang Wu wrote:
> > Hi Merav,
> >
> > FYI, there are new sparse warnings show up in
>
> Thanks. Before submitting I run sparse and it didn't catch these issues,
> but apparently it didn't function well. I will submit a patch soon.
> Merav
The kernel doesn't enable byte-order type checks by default; you have to
add CHECKFLAGS=-D__CHECK_ENDIAN__ to the make command line.
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: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: Rose, Gregory V @ 2012-11-08 16:53 UTC (permalink / raw)
To: Kirsher, Jeffrey T, pkill.2012
Cc: e1000-devel@lists.sourceforge.net, netdev, linux-kernel, kvm
In-Reply-To: <509B962C.6070002@gmail.com>
> -----Original Message-----
> From: Jeff Kirsher [mailto:tarbal@gmail.com]
> Sent: Thursday, November 08, 2012 3:23 AM
> To: pkill.2012
> Cc: linux-kernel; netdev; kvm; e1000-devel@lists.sourceforge.net; Rose,
> Gregory V
> Subject: Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources
> for SR-IOV)
>
> On 11/08/2012 03:15 AM, pkill.2012 wrote:
> > Hello,
> >
> > I installed kvm and tried to use SR-IOV virtualizaton for
> > 82599EB(Intel XT-520 T2) dual port card with latest ixgbe
> > driver(version:3.11.33) ,
> > kernel2.6.32-279.14.1(OS:Centos6.3) ,after configuration and reboot It
> > seems that only first port of the card's VFs works,second port of the
> > card's VFs didn't work I found some errors in /var/log messages:
> >
> > Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: not enough MMIO
> > resources for SR-IOV Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1:
> > (unregistered net_device): Failed to enable PCI sriov: -12
> >
> > How to fix it,any help would be greatly appreciated.
The BIOS in your machine doesn't support SR-IOV. You'll need to ask the manufacturer for a BIOS upgrade, if in fact one is available. Sometimes they're not.
- Greg
> >
> > below is the related information:
> > Server: R710
> > OS: centos6.3
> > NIC: X520-T2(dual port)
> > kernel: 2.6.32-279.14.1.el6.x86_64
> > BIOSVersion: 6.3.0(latest)
> > BIOS:Inter VT/VT-d or SR-IOV(enabled)
> > ixgbe:3.11.33(latest)
> > ixgbevf:2.7.12(latest)
> > grub config:intel_iommu=on appended
> >
> > /var/log/messages:
> > Nov 8 14:56:54 12 kernel: Intel(R) 10 Gigabit PCI Express Network
> > Driver - version 3.11.33 Nov 8 14:56:54 12 kernel: Copyright (c) 1999-
> 2012 Intel Corporation.
> > Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.0: PCI INT B -> GSI 50
> > (level, low) -> IRQ 50 Nov 8 14:56:54 12 kernel: ixgbe: I/O
> > Virtualization (IOV) set to 2 Nov 8 14:56:54 12 kernel: ixgbe:
> > 0000:07:00.0: ixgbe_check_options: FCoE Offload feature enabled Nov 8
> > 14:56:54 12 kernel: ixgbe 0000:07:00.0: (unregistered net_device):
> > SR-IOV enabled with 2 VFs Nov 8 14:56:54 12 kernel: ixgbe
> > 0000:07:00.0: FCoE offload feature is not available. Disabling FCoE
> > offload feature Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.0: (PCI
> > Express:5.0GT/s:Width x8) 68:05:ca:0c:7a:e2 Nov 8 14:56:54 12 kernel:
> > ixgbe 0000:07:00.0: eth4: MAC: 2, PHY: 2, PBA No: G21371-003 Nov 8
> > 14:56:54 12 kernel: ixgbe 0000:07:00.0: eth4: Enabled Features: RxQ: 1
> > TxQ: 1 LRO Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.0: eth4: IOV:
> > VF 0 is enabled mac 0E:15:B9:26:B3:7D Nov 8 14:56:54 12 kernel: ixgbe
> > 0000:07:00.0: eth4: IOV: VF 1 is enabled mac 32:69:2D:16:B9:40 Nov 8
> > 14:56:54 12 kernel: ixgbe 0000:07:00.0: eth4: Intel(R) 10 Gigabit
> > Network Connection Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: PCI
> > INT A -> GSI 40 (level, low) -> IRQ 40 Nov 8 14:56:54 12 kernel:
> > ixgbe: I/O Virtualization (IOV) set to 2 Nov 8 14:56:54 12 kernel:
> > ixgbe: 0000:07:00.1: ixgbe_check_options: FCoE Offload feature enabled
> > Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: not enough MMIO resources
> for SR-IOV Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: (unregistered
> net_device): Failed to enable PCI sriov: -12 Nov 8 14:56:54 12 kernel:
> ixgbe 0000:07:00.1: FCoE offload feature is not available. Disabling FCoE
> offload feature Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: (PCI
> Express:5.0GT/s:Width x8) 68:05:ca:0c:7a:e3 Nov 8 14:56:54 12 kernel:
> ixgbe 0000:07:00.1: eth5: MAC: 2, PHY: 2, PBA No: G21371-003 Nov 8
> 14:56:54 12 kernel: ixgbe 0000:07:00.1: eth5: Enabled Features:
> > RxQ: 16 TxQ: 16 FdirHash RSC
> > Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: eth5: Intel(R) 10
> > Gigabit Network Connection
> >
> > # dmesg |grep -E 'DMA|IOMMU'
> > ACPI: DMAR 00000000bf3b3668 001C0 (v01 DELL PE_SC3 00000001 DELL
> 00000001)
> > DMA 0x00000001 -> 0x00001000
> > DMA32 0x00001000 -> 0x00100000
> > DMA zone: 56 pages used for memmap
> > DMA zone: 102 pages reserved
> > DMA zone: 3839 pages, LIFO batch:0
> > DMA32 zone: 14280 pages used for memmap
> > DMA32 zone: 764849 pages, LIFO batch:31
> > Intel-IOMMU: enabled
> > DMAR: Host address width 40
> > DMAR: DRHD base: 0x000000fed90000 flags: 0x1 IOMMU fed90000: ver 1:0
> > cap c90780106f0462 ecap f020fe
> > DMAR: RMRR base: 0x000000bf4c8000 end: 0x000000bf4dffff
> > DMAR: RMRR base: 0x000000bf4b1000 end: 0x000000bf4bffff
> > DMAR: RMRR base: 0x000000bf4a1000 end: 0x000000bf4a1fff
> > DMAR: RMRR base: 0x000000bf4a3000 end: 0x000000bf4a3fff
> > DMAR: RMRR base: 0x000000bf4a5000 end: 0x000000bf4a5fff
> > DMAR: RMRR base: 0x000000bf4a7000 end: 0x000000bf4a7fff
> > DMAR: RMRR base: 0x000000bf4c0000 end: 0x000000bf4c0fff
> > DMAR: RMRR base: 0x000000bf4c2000 end: 0x000000bf4c2fff
> > DMAR: ATSR flags: 0x0
> > DMAR: Device scope device [0000:00:1a.02] not found
> > DMAR: Device scope device [0000:00:1a.02] not found
> > DMAR: Device scope device [0000:00:1d.02] not found
> > DMAR: Device scope device [0000:00:1d.02] not found IOMMU 0xfed90000:
> > using Queued invalidation
> > IOMMU: Setting RMRR:
> > IOMMU: Setting identity map for device 0000:00:1d.7 [0xbf4c2000 -
> > 0xbf4c3000]
> > IOMMU: Setting identity map for device 0000:00:1a.7 [0xbf4c0000 -
> > 0xbf4c1000]
> > IOMMU: Setting identity map for device 0000:00:1d.1 [0xbf4a7000 -
> > 0xbf4a8000]
> > IOMMU: Setting identity map for device 0000:00:1d.0 [0xbf4a5000 -
> > 0xbf4a6000]
> > IOMMU: Setting identity map for device 0000:00:1a.1 [0xbf4a3000 -
> > 0xbf4a4000]
> > IOMMU: Setting identity map for device 0000:00:1a.0 [0xbf4a1000 -
> > 0xbf4a2000]
> > IOMMU: Setting identity map for device 0000:00:1a.0 [0xbf4b1000 -
> > 0xbf4c0000]
> > IOMMU: Setting identity map for device 0000:00:1a.1 [0xbf4b1000 -
> > 0xbf4c0000]
> > IOMMU: Setting identity map for device 0000:00:1d.0 [0xbf4b1000 -
> > 0xbf4c0000]
> > IOMMU: Setting identity map for device 0000:00:1d.1 [0xbf4b1000 -
> > 0xbf4c0000]
> > IOMMU: Setting identity map for device 0000:00:1a.7 [0xbf4c8000 -
> > 0xbf4e0000]
> > IOMMU: Setting identity map for device 0000:00:1d.7 [0xbf4c8000 -
> > 0xbf4e0000]
> > IOMMU: Prepare 0-16MiB unity mapping for LPC
> > IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]
> > PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> > ata1: SATA max UDMA/133 cmd 0xdc10 ctl 0xdc08 bmdma 0xdc20 irq 23
> > ata2: SATA max UDMA/133 cmd 0xdc18 ctl 0xdc0c bmdma 0xdc28 irq 23
> > ata1.00: ATAPI: TSSTcorp DVD-ROM SN-108BB, D150, max UDMA/100
> > ata1.00: configured for UDMA/100
> >
> > # lspci|grep Virtual
> > 07:10.0 Ethernet controller: Intel Corporation 82599 Virtual Function
> > (rev 01)
> > 07:10.2 Ethernet controller: Intel Corporation 82599 Virtual Function
> > (rev 01)
> >
> > #lspci|grep '82599EB'
> > 07:00.0 Ethernet controller: Intel Corporation 82599EB 10 Gigabit TN
> > Network Connection (rev 01)
> > 07:00.1 Ethernet controller: Intel Corporation 82599EB 10 Gigabit TN
> > Network Connection (rev 01)
> >
> > # lspci -n|grep 07:00
> > 07:00.0 0200: 8086:151c (rev 01)
> > 07:00.1 0200: 8086:151c (rev 01)
> >
> > # lspci -n -d 8086:151c -vvv|grep -i width
> > LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1
> > <8us
> > LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> > BWMgmt- ABWMgmt-
> > LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1
> > <8us
> > LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> > BWMgmt- ABWMgmt-
> >
> > #lspci -vvv -s 07:00
> > 07:00.0 Ethernet controller: Intel Corporation 82599EB 10 Gigabit TN
> > Network Connection (rev 01)
> > Subsystem: Intel Corporation Ethernet Server Adapter X520-T2
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B- DisINTx+
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0, Cache Line Size: 64 bytes
> > Interrupt: pin B routed to IRQ 50
> > Region 0: Memory at de400000 (64-bit, non-prefetchable) [size=2M]
> > Region 2: I/O ports at ecc0 [size=32] Region 4: Memory at de3f8000
> > (64-bit, non-prefetchable) [size=16K] Expansion ROM at de200000
> > [disabled] [size=1M]
> > Capabilities: [40] Power Management version 3
> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> > PME(D0+,D1-,D2-,D3hot+,D3cold+)
> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> > Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > Address: 0000000000000000 Data: 0000
> > Masking: 00000000 Pending: 00000000
> > Capabilities: [70] MSI-X: Enable+ Count=64 Masked- Vector table: BAR=4
> > offset=00000000
> > PBA: BAR=4 offset=00002000
> > Capabilities: [a0] Express (v2) Endpoint, MSI 00
> > DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1
> > <64us
> > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
> > DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
> > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
> > MaxPayload 256 bytes, MaxReadReq 512 bytes
> > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
> > LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1
> > <8us
> > ClockPM- Surprise- LLActRep- BwNot-
> > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> > BWMgmt- ABWMgmt-
> > DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
> > DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis-
> > LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-,
> > Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range,
> > EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB
> > LnkSta2: Current De-emphasis Level: -6dB
> > Capabilities: [e0] Vital Product Data
> > Unknown small resource type 06, will not decode more.
> > Capabilities: [100] Advanced Error Reporting
> > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> > MalfTLP- ECRC- UnsupReq- ACSViol-
> > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt+ RxOF-
> > MalfTLP- ECRC- UnsupReq- ACSViol-
> > UESvrt: DLP+ SDES- TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+
> > MalfTLP+ ECRC+ UnsupReq- ACSViol-
> > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> > CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+
> > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> > Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-0c-7a-e2
> > Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> > ARICap: MFVC- ACS-, Next Function: 1
> > ARICtl: MFVC- ACS-, Function Group: 0
> > Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
> > IOVCap: Migration-, Interrupt Message Number: 000
> > IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy+
> > IOVSta: Migration-
> > Initial VFs: 64, Total VFs: 64, Number of VFs: 2, Function Dependency
> > Link: 00 VF offset: 128, stride: 2, Device ID: 10ed Supported Page
> > Size: 00000553, System Page Size: 00000001 Region 0: Memory at
> > 00000000d5900000 (64-bit, prefetchable) Region 3: Memory at
> > 00000000d5a00000 (64-bit, prefetchable) VF Migration: offset:
> > 00000000, BIR: 0 Kernel driver in use: ixgbe Kernel modules: ixgbe
> > 07:00.1 Ethernet controller: Intel Corporation 82599EB 10 Gigabit TN
> > Network Connection (rev 01)
> > Subsystem: Intel Corporation Ethernet Server Adapter X520-T2
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B- DisINTx+
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0, Cache Line Size: 64 bytes
> > Interrupt: pin A routed to IRQ 40
> > Region 0: Memory at de600000 (64-bit, non-prefetchable) [size=2M]
> > Region 2: I/O ports at ece0 [size=32] Region 4: Memory at de3fc000
> > (64-bit, non-prefetchable) [size=16K] Expansion ROM at d5800000
> > [disabled] [size=1M]
> > Capabilities: [40] Power Management version 3
> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> > PME(D0+,D1-,D2-,D3hot+,D3cold+)
> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> > Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > Address: 0000000000000000 Data: 0000
> > Masking: 00000000 Pending: 00000000
> > Capabilities: [70] MSI-X: Enable+ Count=64 Masked- Vector table: BAR=4
> > offset=00000000
> > PBA: BAR=4 offset=00002000
> > Capabilities: [a0] Express (v2) Endpoint, MSI 00
> > DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1
> > <64us
> > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
> > DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
> > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
> > MaxPayload 256 bytes, MaxReadReq 512 bytes
> > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
> > LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1
> > <8us
> > ClockPM- Surprise- LLActRep- BwNot-
> > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> > BWMgmt- ABWMgmt-
> > DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
> > DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis-
> > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
> > Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range,
> > EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB
> > LnkSta2: Current De-emphasis Level: -6dB
> > Capabilities: [e0] Vital Product Data
> > Unknown small resource type 06, will not decode more.
> > Capabilities: [100] Advanced Error Reporting
> > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> > MalfTLP- ECRC- UnsupReq- ACSViol-
> > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt+ RxOF-
> > MalfTLP- ECRC- UnsupReq- ACSViol-
> > UESvrt: DLP+ SDES- TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+
> > MalfTLP+ ECRC+ UnsupReq- ACSViol-
> > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> > CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+
> > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> > Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-0c-7a-e2
> > Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> > ARICap: MFVC- ACS-, Next Function: 0
> > ARICtl: MFVC- ACS-, Function Group: 0
> > Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
> > IOVCap: Migration-, Interrupt Message Number: 000
> > IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
> > IOVSta: Migration-
> > Initial VFs: 64, Total VFs: 64, Number of VFs: 2, Function Dependency
> > Link: 01 VF offset: 128, stride: 2, Device ID: 10ed Supported Page
> > Size: 00000553, System Page Size: 00000001 Region 0: Memory at
> > 00000000d5b00000 (64-bit, prefetchable) Region 3: Memory at
> > 00000000d5b00000 (64-bit, prefetchable) VF Migration: offset:
> > 00000000, BIR: 0 Kernel driver in use: ixgbe Kernel modules: ixgbe
> >
> > #modinfo ixgbe
> > filename: /lib/modules/2.6.32-
> 279.14.1.el6.x86_64/kernel/drivers/net/ixgbe/ixgbe.ko
> > version: 3.11.33
> > license: GPL
> > description: Intel(R) 10 Gigabit PCI Express Network Driver
> > author: Intel Corporation, <linux.nics@intel.com>
> > srcversion: ADDCBFA6FAFE8A0299074F8
> > alias: pci:v00008086d0000154Asv*sd*bc*sc*i*
> > alias: pci:v00008086d00001557sv*sd*bc*sc*i*
> > alias: pci:v00008086d0000154Fsv*sd*bc*sc*i*
> > alias: pci:v00008086d0000154Dsv*sd*bc*sc*i*
> > alias: pci:v00008086d00001528sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F8sv*sd*bc*sc*i*
> > alias: pci:v00008086d0000151Csv*sd*bc*sc*i*
> > alias: pci:v00008086d00001529sv*sd*bc*sc*i*
> > alias: pci:v00008086d0000152Asv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F9sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001514sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001507sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010FBsv*sd*bc*sc*i*
> > alias: pci:v00008086d00001517sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010FCsv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F7sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001508sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010DBsv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F4sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010E1sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F1sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010ECsv*sd*bc*sc*i*
> > alias: pci:v00008086d000010DDsv*sd*bc*sc*i*
> > alias: pci:v00008086d0000150Bsv*sd*bc*sc*i*
> > alias: pci:v00008086d000010C8sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010C7sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010C6sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010B6sv*sd*bc*sc*i*
> > depends: dca
> > vermagic: 2.6.32-279.14.1.el6.x86_64 SMP mod_unload modversions
> > parm: InterruptType:Change Interrupt Mode (0=Legacy, 1=MSI,
> 2=MSI-X), default IntMode (deprecated) (array of int)
> > parm: IntMode:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-
> X), default 2 (array of int)
> > parm: MQ:Disable or enable Multiple Queues, default 1 (array
> of int)
> > parm: DCA:Disable or enable Direct Cache Access, 0=disabled,
> 1=descriptor only, 2=descriptor and data (array of int)
> > parm: RSS:Number of Receive-Side Scaling Descriptor Queues,
> default 0=number of cpus (array of int)
> > parm: VMDQ:Number of Virtual Machine Device Queues: 0/1 =
> disable, 2-16 enable (default=8) (array of int)
> > parm: max_vfs:Number of Virtual Functions: 0 = disable
> (default), 1-63 = enable this many VFs (array of int)
> > parm: L2LBen:L2 Loopback Enable: 0 = disable, 1 = enable
> (default) (array of int)
> > parm: InterruptThrottleRate:Maximum interrupts per second, per
> vector, (0,1,956-488281), default 1 (array of int)
> > parm: LLIPort:Low Latency Interrupt TCP Port (0-65535) (array
> of int)
> > parm: LLIPush:Low Latency Interrupt on TCP Push flag (0,1)
> (array of int)
> > parm: LLISize:Low Latency Interrupt on Packet Size (0-1500)
> (array of int)
> > parm: LLIEType:Low Latency Interrupt Ethernet Protocol Type
> (array of int)
> > parm: LLIVLANP:Low Latency Interrupt on VLAN priority
> threshold (array of int)
> > parm: FdirPballoc:Flow Director packet buffer allocation
> level:
> > 1 = 8k hash filters or 2k perfect filters
> > 2 = 16k hash filters or 4k perfect filters
> > 3 = 32k hash filters or 8k perfect filters (array of int)
> > parm: AtrSampleRate:Software ATR Tx packet sample rate (array
> of int)
> > parm: FCoE:Disable or enable FCoE Offload, default 1 (array of
> int)
> > parm: LRO:Large Receive Offload (0,1), default 1 = on (array
> of int)
> > parm: allow_unsupported_sfp:Allow unsupported and untested
> SFP+ modules on 82599 based adapters, default 0 = Disable (array of int)
> >
> > # modinfo ixgbevf
> > filename: /lib/modules/2.6.32-
> 279.14.1.el6.x86_64/kernel/drivers/net/ixgbevf/ixgbevf.ko
> > version: 2.7.12
> > license: GPL
> > description: Intel(R) 10 Gigabit PCI Express Virtual Function Network
> Driver
> > author: Intel Corporation, <linux.nics@intel.com>
> > srcversion: 4D00B4A5B811D6D07D8BD15
> > alias: pci:v00008086d00001515sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010EDsv*sd*bc*sc*i*
> > depends:
> > vermagic: 2.6.32-279.14.1.el6.x86_64 SMP mod_unload modversions
> > parm: InterruptThrottleRate:Maximum interrupts per second, per
> vector, (956-488281), default 8000, use 1 for dynamic (array of int)
> >
> >
> > # dmidecode -t bios
> > # dmidecode 2.11
> > SMBIOS 2.6 present.
> > Handle 0x0000, DMI type 0, 24 bytes
> > BIOS Information
> > Vendor: Dell Inc.
> > Version: 6.3.0
> > Release Date: 07/24/2012
> > Address: 0xF0000
> > Runtime Size: 64 kB
> > ROM Size: 4096 kB
> > Characteristics:
> > ISA is supported
> > PCI is supported
> > PNP is supported
> > BIOS is upgradeable
> > BIOS shadowing is allowed
> > Boot from CD is supported
> > Selectable boot is supported
> > EDD is supported
> > Japanese floppy for Toshiba 1.2 MB is supported (int
> 13h)
> > 5.25"/360 kB floppy services are supported (int 13h)
> > 5.25"/1.2 MB floppy services are supported (int 13h)
> > 3.5"/720 kB floppy services are supported (int 13h)
> > 8042 keyboard services are supported (int 9h)
> > Serial services are supported (int 14h)
> > CGA/mono video services are supported (int 10h)
> > ACPI is supported
> > USB legacy is supported
> > BIOS boot specification is supported
> > Function key-initiated network boot is supported
> > Targeted content distribution is supported
> > BIOS Revision: 6.3
> > Handle 0x0D00, DMI type 13, 22 bytes
> > BIOS Language Information
> > Language Description Format: Long
> > Installable Languages: 1
> > en|US|iso8859-1
> > Currently Installed Language: en|US|iso8859-1
> >
> > Jason Gao
> > --
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> Adding e100-devel mailing list
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_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] allow pkg-config to be customized
From: Mike Frysinger @ 2012-11-08 16:41 UTC (permalink / raw)
To: stephen.hemminger, netdev
Rather than hard coding `pkg-config`, use ${PKG_CONFIG} so people can
override it to their specific version (like when cross-compiling).
This is the same way the upstream pkg-config code works.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
configure | 6 ++++--
tc/Makefile | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 2c2d1c4..0bfedf9 100755
--- a/configure
+++ b/configure
@@ -2,6 +2,8 @@
# This is not an autconf generated configure
#
INCLUDE=${1:-"$PWD/include"}
+: ${PKG_CONFIG:=pkg-config}
+echo "PKG_CONFIG:=${PKG_CONFIG}" >>Config
# Make a temp directory in build tree.
TMPDIR=$(mktemp -d config.XXXXXX)
@@ -51,7 +53,7 @@ int main(int argc, char **argv)
EOF
-if gcc -I$INCLUDE $IPTC -o $TMPDIR/ipttest $TMPDIR/ipttest.c $IPTL $(pkg-config xtables --cflags --libs) -ldl >/dev/null 2>&1
+if gcc -I$INCLUDE $IPTC -o $TMPDIR/ipttest $TMPDIR/ipttest.c $IPTL $(${PKG_CONFIG} xtables --cflags --libs) -ldl >/dev/null 2>&1
then
echo "TC_CONFIG_XT:=y" >>Config
echo "using xtables"
@@ -148,7 +150,7 @@ check_ipt()
check_ipt_lib_dir()
{
- IPT_LIB_DIR=$(pkg-config --variable=xtlibdir xtables)
+ IPT_LIB_DIR=$(${PKG_CONFIG} --variable=xtlibdir xtables)
if [ -n "$IPT_LIB_DIR" ]; then
echo $IPT_LIB_DIR
echo "IPT_LIB_DIR:=$IPT_LIB_DIR" >> Config
diff --git a/tc/Makefile b/tc/Makefile
index 389029d..696f891 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -135,10 +135,10 @@ q_atm.so: q_atm.c
$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o q_atm.so q_atm.c -latm
m_xt.so: m_xt.c
- $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt.so m_xt.c $$(pkg-config xtables --cflags --libs)
+ $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt.so m_xt.c $$($(PKG_CONFIG) xtables --cflags --libs)
m_xt_old.so: m_xt_old.c
- $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt_old.so m_xt_old.c $$(pkg-config xtables --cflags --libs)
+ $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt_old.so m_xt_old.c $$($(PKG_CONFIG) xtables --cflags --libs)
%.yacc.c: %.y
$(YACC) $(YACCFLAGS) -o $@ $<
--
1.7.12.4
^ permalink raw reply related
* [PATCH] usbnet: ratelimit kevent may have been dropped warnings
From: Steve Glendinning @ 2012-11-08 16:26 UTC (permalink / raw)
To: oneukum; +Cc: netdev, Steve Glendinning
when something goes wrong, a flood of these messages can be
generated by usbnet (thousands per second). This doesn't
generally *help* the condition so this patch ratelimits the
rate of their generation.
There's an underlying problem in usbnet's kevent deferral
mechanism which needs fixing, specifically that events *can*
get dropped and not handled. This patch doesn't address this,
but just mitigates fallout caused by the current implemention.
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
---
drivers/net/usb/usbnet.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 5bf7717..3565e6d 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -359,10 +359,12 @@ static enum skb_state defer_bh(struct usbnet *dev, struct sk_buff *skb,
void usbnet_defer_kevent (struct usbnet *dev, int work)
{
set_bit (work, &dev->flags);
- if (!schedule_work (&dev->kevent))
- netdev_err(dev->net, "kevent %d may have been dropped\n", work);
- else
+ if (!schedule_work (&dev->kevent)) {
+ if (net_ratelimit())
+ netdev_err(dev->net, "kevent %d may have been dropped\n", work);
+ } else {
netdev_dbg(dev->net, "kevent %d scheduled\n", work);
+ }
}
EXPORT_SYMBOL_GPL(usbnet_defer_kevent);
--
1.7.10.4
^ permalink raw reply related
* [PATCH][net-next v1] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: Claudiu Manoil @ 2012-11-08 15:59 UTC (permalink / raw)
To: netdev; +Cc: Paul Gortmaker, David S. Miller, Claudiu Manoil
Should gfar_init_bds() return with -ENOMEM inside gfar_alloc_skb_resources(),
free_skb_resources() will be called twice in a row on the "cleanup" path,
leading to duplicate kfree() calls for rx_|tx_queue->rx_|tx_skbuff resulting
in segmentation fault.
This patch prevents the segmentation fault to happen in the future
(rx_|tx_sbkbuff set to NULL), and corrects the error path handling
for gfar_init_bds().
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
v1: do free_skb_resources() on the cleanup path of gfar_init_bds()'s parent
drivers/net/ethernet/freescale/gianfar.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 1d03dcd..ce2007f 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -210,7 +210,7 @@ static int gfar_init_bds(struct net_device *ndev)
skb = gfar_new_skb(ndev);
if (!skb) {
netdev_err(ndev, "Can't allocate RX buffers\n");
- goto err_rxalloc_fail;
+ return -ENOMEM;
}
rx_queue->rx_skbuff[j] = skb;
@@ -223,10 +223,6 @@ static int gfar_init_bds(struct net_device *ndev)
}
return 0;
-
-err_rxalloc_fail:
- free_skb_resources(priv);
- return -ENOMEM;
}
static int gfar_alloc_skb_resources(struct net_device *ndev)
@@ -1356,7 +1352,9 @@ static int gfar_restore(struct device *dev)
if (!netif_running(ndev))
return 0;
- gfar_init_bds(ndev);
+ if (gfar_init_bds(ndev))
+ goto cleanup;
+
init_registers(ndev);
gfar_set_mac_address(ndev);
gfar_init_mac(ndev);
@@ -1373,6 +1371,10 @@ static int gfar_restore(struct device *dev)
enable_napi(priv);
return 0;
+
+cleanup:
+ free_skb_resources(priv);
+ return -ENOMEM;
}
static struct dev_pm_ops gfar_pm_ops = {
@@ -1709,6 +1711,7 @@ static void free_skb_tx_queue(struct gfar_priv_tx_q *tx_queue)
tx_queue->tx_skbuff[i] = NULL;
}
kfree(tx_queue->tx_skbuff);
+ tx_queue->tx_skbuff = NULL;
}
static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
@@ -1732,6 +1735,7 @@ static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
rxbdp++;
}
kfree(rx_queue->rx_skbuff);
+ rx_queue->rx_skbuff = NULL;
}
/* If there are any tx skbs or rx skbs still around, free them.
--
1.6.6
^ permalink raw reply related
* Re: [PATCH][net-next v1] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: Paul Gortmaker @ 2012-11-08 16:08 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller
In-Reply-To: <1352390396-10053-1-git-send-email-claudiu.manoil@freescale.com>
On 12-11-08 10:59 AM, Claudiu Manoil wrote:
> Should gfar_init_bds() return with -ENOMEM inside gfar_alloc_skb_resources(),
> free_skb_resources() will be called twice in a row on the "cleanup" path,
> leading to duplicate kfree() calls for rx_|tx_queue->rx_|tx_skbuff resulting
> in segmentation fault.
> This patch prevents the segmentation fault to happen in the future
> (rx_|tx_sbkbuff set to NULL), and corrects the error path handling
> for gfar_init_bds().
>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> Cc: "David S. Miller" <davem@davemloft.net>
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
> v1: do free_skb_resources() on the cleanup path of gfar_init_bds()'s parent
>
> drivers/net/ethernet/freescale/gianfar.c | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index 1d03dcd..ce2007f 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -210,7 +210,7 @@ static int gfar_init_bds(struct net_device *ndev)
> skb = gfar_new_skb(ndev);
> if (!skb) {
> netdev_err(ndev, "Can't allocate RX buffers\n");
> - goto err_rxalloc_fail;
> + return -ENOMEM;
> }
> rx_queue->rx_skbuff[j] = skb;
>
> @@ -223,10 +223,6 @@ static int gfar_init_bds(struct net_device *ndev)
> }
>
> return 0;
> -
> -err_rxalloc_fail:
> - free_skb_resources(priv);
> - return -ENOMEM;
> }
>
> static int gfar_alloc_skb_resources(struct net_device *ndev)
> @@ -1356,7 +1352,9 @@ static int gfar_restore(struct device *dev)
> if (!netif_running(ndev))
> return 0;
>
> - gfar_init_bds(ndev);
> + if (gfar_init_bds(ndev))
> + goto cleanup;
> +
Since this is the only exit point, just put the free and
return right here, and avoid the goto and the separate
unwind block entirely?
P.
--
> init_registers(ndev);
> gfar_set_mac_address(ndev);
> gfar_init_mac(ndev);
> @@ -1373,6 +1371,10 @@ static int gfar_restore(struct device *dev)
> enable_napi(priv);
>
> return 0;
> +
> +cleanup:
> + free_skb_resources(priv);
> + return -ENOMEM;
> }
>
> static struct dev_pm_ops gfar_pm_ops = {
> @@ -1709,6 +1711,7 @@ static void free_skb_tx_queue(struct gfar_priv_tx_q *tx_queue)
> tx_queue->tx_skbuff[i] = NULL;
> }
> kfree(tx_queue->tx_skbuff);
> + tx_queue->tx_skbuff = NULL;
> }
>
> static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
> @@ -1732,6 +1735,7 @@ static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
> rxbdp++;
> }
> kfree(rx_queue->rx_skbuff);
> + rx_queue->rx_skbuff = NULL;
> }
>
> /* If there are any tx skbs or rx skbs still around, free them.
>
^ permalink raw reply
* [PATCH] socket.7: Correctly describe SO_SNDTIMEO for connect
From: Andi Kleen @ 2012-11-08 15:55 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Andi Kleen
From: Andi Kleen <ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
When SO_SNDTIMEO is set before connect() connect may return EWOULDBLOCK
when the timeout fires. Describe this correctly.
Signed-off-by: Andi Kleen <ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
man7/socket.7 | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/man7/socket.7 b/man7/socket.7
index cd75746..9e05f48 100644
--- a/man7/socket.7
+++ b/man7/socket.7
@@ -434,6 +434,9 @@ set to
.B EAGAIN
or
.B EWOULDBLOCK
+or
+.B EINPROGRESS
+(for connect)
.\" in fact to EAGAIN
just as if the socket was specified to be nonblocking.
If the timeout is set to zero (the default)
@@ -442,6 +445,7 @@ Timeouts only have effect for system calls that perform socket I/O (e.g.,
.BR read (2),
.BR recvmsg (2),
.BR send (2),
+.BR connect (2),
.BR sendmsg (2));
timeouts have no effect for
.BR select (2),
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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 related
* [PATCH] ipv4: Handle very small SO_SNDTIMEOs
From: Andi Kleen @ 2012-11-08 15:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Andi Kleen
From: Andi Kleen <ak@linux.intel.com>
When the SO_SNDTIMEO timeout is short enough it may round down to zero
jiffies. This causes unexpected behaviour because the socket
essentially becomes always non blocking.
Round up the timeout to at least two jiffies, so that
we guarantee waiting for at least some time. With one jiffie
we could potentially still wait zero time because we might
be just at the edge of the jiffie, and if it flips over
in the middle of the check it could be still zero.
This has been observed in a real application.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
net/core/sock.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index a6000fb..93c0060 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -362,8 +362,15 @@ static int sock_set_timeout(long *timeo_p, char __user *optval, int optlen)
*timeo_p = MAX_SCHEDULE_TIMEOUT;
if (tv.tv_sec == 0 && tv.tv_usec == 0)
return 0;
- if (tv.tv_sec < (MAX_SCHEDULE_TIMEOUT/HZ - 1))
+ if (tv.tv_sec < (MAX_SCHEDULE_TIMEOUT/HZ - 1)) {
*timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(1000000/HZ-1))/(1000000/HZ);
+ /* Do at least two jiffies to ensure we wait at all.
+ * Otherwise we may be on the edge of the next jiffie already,
+ * and then essentially non block.
+ */
+ if ((unsigned long)*timeo_p < 2)
+ *timeo_p = 2;
+ }
return 0;
}
--
1.7.7.6
^ permalink raw reply related
* Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
From: Andy King @ 2012-11-08 15:47 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: pv-drivers, netdev, linux-kernel, virtualization, gregkh,
David Miller, georgezhang
In-Reply-To: <509A06AB.2020700@redhat.com>
Hi Gerd,
>> Also, there was some interest from RedHat into using vSockets as
>> a unified interface, routed over a hypervisor-specific transport
>> (virtio or otherwise, although for now VMCI is the only one
>> implemented).
>
> Can you outline how this can be done? From a quick look over the
> code it seems like vsock has a hard dependency on vmci, is that
> correct?
That's correct, VMCI is wired into vSockets and we don't currently
provide any way to insert another transport.
> When making vsock a generic, reusable kernel service it should be
> the other way around: vsock should provide the core implementation
> and an interface where hypervisor-specific transports (vmci,
> virtio, xenbus, ...) can register themself.
Sorry, that was a bad explanation on my part. You're absolutely
correct as to how it _should_ work. But it's up to Red Hat or others
to get the ball rolling and motivate the necessary work on vSockets
to make this happen. As Greg says, "everyone is lazy and just wants
their code accepted" ;)
Thanks!
- Andy
^ permalink raw reply
* [RFC PATCH] Bug on AT91 macb driver rx with high network traffic
From: matteo.fortini @ 2012-11-08 15:17 UTC (permalink / raw)
To: netdev; +Cc: Roberto Battani, nicolas.ferre
We are testing the robustness of the driver with UDP packets of
increasing length, up to the maximum allowed.
We have an UDP echo server listening on an port on the AT91 board, and
we send to it increasing length UDP packets, waiting for the echo reply
before sending the next one.
When packets get larghish, in the >40000 bytes range, we see that the
server is not receiving packets anymore, so the client does not receive
the reply and the test stops. Pinging the interface once resumes the
test, meaning that the packet has been actually received, but the driver
is waiting for an interrupt that is not coming.
We traced this down to slow/missing IRQ response, and we fixed it as in
the following patch, which calls napi_reschedule() before leaving the
polling loop if the loop condition is still valid at the end of the
polling loop, as other net drivers appear to do.
We don't know if this is the perfectly right way to do it, and we'd like
your opinion on this before submitting a proper patch.
I added the udp_server.c and udp_client.c softwares which may be useful.
Thank you in advance,
Matteo Fortini
===================================================================
From 2d8895022a0668f6a3c1112f15ebe471db1a471e Mon Sep 17 00:00:00 2001
From: Matteo Fortini <matteo.fortini@sadel.it>
Date: Thu, 8 Nov 2012 16:12:10 +0100
Subject: [PATCH] AT91 macb: Fix lost rx packets on high rx traffic
---
drivers/net/ethernet/cadence/macb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 033064b..348a20f 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -522,8 +522,16 @@ static int macb_poll(struct napi_struct *napi, int
budget)
work_done = macb_rx(bp, budget);
if (work_done < budget) {
+ u32 addr;
+
napi_complete(napi);
+ addr = bp->rx_ring[bp->rx_tail].addr;
+
+ if ((addr & MACB_BIT(RX_USED))) {
+ netdev_warn(bp->dev, "poll: reschedule");
+ napi_reschedule(napi);
+ }
/*
* We've done what we can to clean the buffers. Make
sure we
* get notified when new packets arrive.
--
1.7.10.4
====================================================
TEST PROGRAMS:
/*
* UDP client
* Copyright 2012 SADEL SpA
* Castel Maggiore
* Bologna
* Italy
*/
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#define BUFFER_LEN 70000 ///< Lenght of buffer
#define LISTEN_PORT 32000 ///< Listen port
#define MIN_PACKET_LEN 8 ///< Min lenght of a packet
#define MAX_PACKET_LEN 65499 ///< Min lenght of a packet
#define TIMEOUT 0 ///< Default wait_time between each
packet send
static int port = LISTEN_PORT;
static int minPacketLen = MIN_PACKET_LEN;
static int maxPacketLen = MAX_PACKET_LEN;
static int packetLen = 0;
static int wait_time = TIMEOUT;
static char *server = NULL;
static void usage(const char *program)
{
fprintf(stderr,"usage: %s [options]\n",program);
fprintf(stderr," -c <ipaddr> Server IP address\n");
fprintf(stderr," -p <port> Specify port number
(default: %d)\n", LISTEN_PORT);
fprintf(stderr," -t <waittime> wait time between each send
actions in usec\n");
fprintf(stderr," -m <min_len> Min packet length (default:
%d)\n",MIN_PACKET_LEN);
fprintf(stderr," -M <max_len> Mam packet length (default:
%d)\n",MAX_PACKET_LEN);
fprintf(stderr," -l <lenght> Lengh of packet [%d <
<length> < %d). If no specified, variable packet is sent\n");
fprintf(stderr," -h Show this help and exit\n");
}
static void check_parameter(int argc, char **argv)
{
int opt;
while ((opt = getopt(argc, argv, "c:l:t:p:m:M:h")) != -1) {
switch (opt) {
case 'c':
server = optarg;
break;
case 'p':
port = atoi(optarg);
if( port <= 0 ) {
fprintf(stderr, "Wrong parameter -p");
usage(argv[0]);
exit(EXIT_FAILURE);
}
break;
case 't':
wait_time = atoi(optarg);
break;
case 'm':
minPacketLen = atoi(optarg);
if( minPacketLen < MIN_PACKET_LEN ) {
fprintf(stderr, "Min packet length too low. Set to:
%d\n", MIN_PACKET_LEN);
minPacketLen = MIN_PACKET_LEN;
}
break;
case 'M':
maxPacketLen = atoi(optarg);
if( maxPacketLen > MAX_PACKET_LEN ) {
fprintf(stderr, "Max packet length too high. Set
to: %d\n", MAX_PACKET_LEN);
maxPacketLen = MAX_PACKET_LEN;
}
break;
case 'l':
packetLen = atoi(optarg);
break;
case 'h':
usage(argv[0]);
exit(0);
default: /* '?' */
fprintf(stderr, "Unrecognized parameter '%c'\n", opt);
usage(argv[0]);
exit(EXIT_FAILURE);
}
}
if( server == NULL ) {
fprintf(stderr, "Wrong or missing -c parameter\n");
usage(argv[0]);
exit(EXIT_FAILURE);
}
if( minPacketLen > maxPacketLen ) {
fprintf(stderr, "minPacketLen could not be greather than
maxPacketLen: %d, %d\n", minPacketLen, maxPacketLen);
usage(argv[0]);
exit(EXIT_FAILURE);
}
fprintf(stderr, "UDP Client - server: %s, port: %d, wait_time: %d",
server, port, wait_time);
if( packetLen > 0 ) {
fprintf(stderr, " - fixed packet len: %d bytes\n", packetLen);
} else {
fprintf(stderr, " - variable packet len from %d to %d bytes\n",
minPacketLen, maxPacketLen);
}
}
static int sendAndCheck(int sockfd, struct sockaddr_in *servaddr, const
char *msg_tx, size_t msg_len) {
int t, n, iRetVal = 0;
char msg_rx[BUFFER_LEN];
socklen_t len = sizeof(*servaddr);
t = sendto(sockfd, msg_tx, msg_len, 0, (struct sockaddr *)servaddr,
len);
fprintf(stderr, "TX [%d] bytes, ", msg_len, t);
n = recvfrom(sockfd,msg_rx,BUFFER_LEN,0,(struct sockaddr
*)servaddr,&len);
fprintf(stderr, "RX [%d] bytes - ",n);
if( t != n ) {
fprintf(stderr, "size differs!!!\n");
iRetVal = 0;
}
if( memcmp(msg_tx, msg_rx, msg_len) != 0 ) {
fprintf(stderr, "data = ko\n");
iRetVal = -1;
} else {
fprintf(stderr, "data = ok\n");
}
return iRetVal;
}
static int fixed_send(int sockfd, struct sockaddr_in *servaddr)
{
int i = 0, iRetVal = 0;
char msg_tx[BUFFER_LEN];
memset(msg_tx,sizeof(msg_tx),'a');
while(1) {
fprintf(stderr, "[%d] - ",i);
if( sendAndCheck(sockfd, servaddr, msg_tx, packetLen) != 0 ) {
break;
}
usleep(wait_time);
i++;
}
return iRetVal;
}
static int variable_send(int sockfd, struct sockaddr_in *servaddr)
{
int i, iRetVal = 0;
char msg_tx[BUFFER_LEN];
memset(msg_tx,sizeof(msg_tx),'a');
for ( i = 0; i <= maxPacketLen - minPacketLen; i++) {
fprintf(stderr, "[%d] - ",i);
if( sendAndCheck(sockfd, servaddr, msg_tx, minPacketLen+i) != 0 ) {
break;
}
usleep(wait_time);
}
return iRetVal;
}
int main(int argc, char**argv)
{
int sockfd;
struct sockaddr_in servaddr;
check_parameter(argc,argv);
bzero(&servaddr,sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr=inet_addr(server);
servaddr.sin_port=htons(port);
sockfd = socket(AF_INET,SOCK_DGRAM,0);
//Opzionale
if( connect(sockfd,(struct sockaddr *)&servaddr,sizeof(servaddr))
!= 0 ) {
fprintf(stderr, "Failed to connect\n");
exit(1);
}
if ( packetLen > 0 ) {
fixed_send(sockfd,&servaddr);
} else {
variable_send(sockfd,&servaddr);
}
return 0;
}
=================================================================
/*
* UDP server
* Copyright 2012 SADEL SpA
* Castel Maggiore
* Bologna
* Italy
*/
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#define BUFFER_LEN 70000 ///< Lenght of buffer
#define LISTEN_PORT 32000 ///< Listen port
#define TIMEOUT 0 ///< Default wait_time between each
packet send
static int port = LISTEN_PORT;
static int wait_time = TIMEOUT;
static void usage(const char *program)
{
fprintf(stderr,"usage: %s [options]\n",program);
fprintf(stderr," -p <port> Specify port number
(default: %d)\n", LISTEN_PORT);
fprintf(stderr," -t <waittime> wait time between each send
actions in usec\n");
fprintf(stderr," -h Show this help and exit\n");
}
static void check_parameter(int argc, char **argv)
{
int opt;
while ((opt = getopt(argc, argv, "t:p:h")) != -1) {
switch (opt) {
case 'p':
port = atoi(optarg);
if( port <= 0 ) {
fprintf(stderr, "Wrong parameter -p");
usage(argv[0]);
exit(EXIT_FAILURE);
}
break;
case 't':
wait_time = atoi(optarg);
break;
case 'h':
usage(argv[0]);
exit(0);
default: /* '?' */
fprintf(stderr, "Unrecognized parameter '%c'\n", opt);
usage(argv[0]);
exit(EXIT_FAILURE);
}
}
fprintf(stderr, "UDP Server - port: %d, wait_time: %d\n", port,
wait_time);
}
int main(int argc, char**argv)
{
int sockfd,n;
struct sockaddr_in servaddr,cliaddr;
socklen_t len;
char mesg[BUFFER_LEN];
int i = 1;
int t;
check_parameter(argc, argv);
sockfd=socket(AF_INET,SOCK_DGRAM,0);
bzero(&servaddr,sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr=htonl(INADDR_ANY);
servaddr.sin_port=htons(port);
bind(sockfd,(struct sockaddr *)&servaddr,sizeof(servaddr));
for (;;)
{
len = sizeof(cliaddr);
n = recvfrom(sockfd,mesg,BUFFER_LEN,0,(struct sockaddr
*)&cliaddr,&len);
fprintf(stderr, "[%d] - RX [%d] bytes ",i, n);
usleep(wait_time);
t = sendto(sockfd,mesg,n,0,(struct sockaddr
*)&cliaddr,sizeof(cliaddr));
fprintf(stderr, "- TX [%d] bytes\n",t);
mesg[n] = 0;
i++;
}
}
^ permalink raw reply related
* Re: [PATCH][net-next] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: Claudiu Manoil @ 2012-11-08 15:37 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev, David S. Miller
In-Reply-To: <509BBFCF.20109@windriver.com>
On 11/8/2012 4:21 PM, Paul Gortmaker wrote:
> On 12-11-08 08:40 AM, Claudiu Manoil wrote:
>> Should gfar_init_bds() return with -ENOMEM inside gfar_alloc_skb_resources(),
>> free_skb_resources() will be called twice in a row on the "cleanup" path,
>> leading to duplicate kfree() calls for rx_|tx_queue->rx_|tx_skbuff resulting
>> in segmentation fault.
>> This patch prevents the segmentation fault to happen in the future
>> (rx_|tx_sbkbuff set to NULL), and corrects the error path handling
>> for gfar_init_bds().
>
> Since gfar_init_bds is more like a slave routine to gfar_alloc_skb_resources,
> I think the dup free_skb_resources should remain in the parent, and be removed
> from gfar_init_bds. Otherwise the gfar_alloc_skb_resources will appear
> confusing -- one will think it it allocates some resources, hits a failure
> and then returns without bothering to do any cleanup of the parts it
> did manage to allocate. (Then gfar_restore will have to call the free
> itself _if_ gfar_init_bds fails too.)
>
> Paul.
You're right. I'll send the v1 patch shortly.
Thanks.
Claudiu
^ permalink raw reply
* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Brian Haley @ 2012-11-08 15:36 UTC (permalink / raw)
To: David Miller
Cc: Ben Hutchings, Pavel Emelyanov, Eric Dumazet,
netdev@vger.kernel.org
In-Reply-To: <50988BAE.6020602@hp.com>
On 11/05/2012 09:01 PM, Brian Haley wrote:
>>>>> + rcu_read_lock();
>>>>> + dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
>>>>> + if (dev)
>>>>> + strcpy(devname, dev->name);
>>>>
>>>> This still races with the device name change, potentially providing
>>>> a name which never existed in the system, doesn't it?
>>>
>>> My only argument here is that SIOCGIFNAME has had this same code
>>> forever, and
>>> noone has ever complained about that returning a garbled name. Even
>>> dev_get_by_name() only holds an rcu lock when doing a strncmp().
>>>
>>> We'd need to audit the whole kernel to catch all the places where we
>>> potentially
>>> look at dev->name while it could change. Is it really worth it?
>>
>> A net device name can't be changed while the device is up, or while
>> another task holds the RTNL lock. I think that covers almost all uses.
>> I don't know whether it's worth going out to look for exceptions, but we
>> might as well fix the cases we know about.
>
> So do you think we can fix these corner cases later and get the API
> right first?
Hi Dave,
I noticed this isn't in patchwork anymore. Is it possible to get this
in and then work on the other issue in a separate patch since it's not
just this code that has this problem?
Of course I'm still not convinced that extra check is necessary (but
I'll do it to make others happy) because if you do a setsockopt("eth0"),
all you care is that a getsockopt() returns "eth0" - if it returns
anything else, eth0_renamed, eth0_foo, etc you'll notice it's not the
same and take action. And the fact that the name can't change when UP
means the odds are small it can happen anyways.
Thanks,
-Brian
^ permalink raw reply
* Re: iproute2 (2012-11-08) and tunnel mode vti problems
From: Stephen Hemminger @ 2012-11-08 15:33 UTC (permalink / raw)
To: Ruben Herold; +Cc: Saurabh Mohan, netdev
In-Reply-To: <20121108131305.GD2838@puettmann.net>
> I have here some problems with the newest iproute2 taken from git today.
> I will play around with the new vti mode.
>
> First problem ist after loading the ip_vti module I got an ioctl error
> on ip tunnel show:
>
> ---------------------------------------------------------------------
> root@ipsec0:[~] > ip -V
> ip utility, iproute2-ss121108
> root@ipsec0:[~] > uname -a
> Linux ipsec0 3.6.6 #1 SMP Tue Nov 6 16:21:05 CET 2012 i686 GNU/Linux
> root@ipsec0:[~] > modprobe ip_vti
> root@ipsec0:[~] > ip tunnel show
> ip_vti0: ioctl 89f4 failed: Invalid argument
> ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0
> root@ipsec0:[~] >
> --------------------------------------------------------------------
Found the cause of the problem. It is a kernel issue.
The kernel implementation of VTI uses same flag bit as SIT tunnel,
and 'ip tunnel show' is using SIT flag to decide whether to look
up sit tunnel parameters, which fails on VTI.
It is a bug introduced in ioctl definition for VTI. Not sure
what the best way to fix it is? Add more kludge code in ip command,
or change definition of flag bit, and risk userspace ABI incompatibility.
Also, there is the issue that i_flags is a confusing mix of
network byte order bits or'd with host byte order bits. The initial
definition of SIT was broken long, long ago.
Copying netdev list.
^ permalink raw reply
* Re: [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Shan Wei @ 2012-11-08 14:22 UTC (permalink / raw)
To: Christoph Lameter
Cc: dev-yBygre7rU0TnMu66kgdUjQ, NetDev, Kernel-Maillist, David Miller
In-Reply-To: <0000013ac23ac528-19a0dd1b-3144-45df-9d6e-471999d6ae31-000000-p/GC64/jrecnJqMo6gzdpkEOCMrvLtNR@public.gmane.org>
Christoph Lameter said, at 2012/11/3 1:46:
>> u64_stats_update_begin(&stats->sync);
>> stats->tx_packets++;
>
> Use this_cpu_inc(vport->percpu_stats->packets) here?
Lots of network drivers use u64_stats_sync infrastructure for statistics
on 32bit or 64bit hosts no matter how many members in per-cpu variable.
keep them be consistent, so no plan to change them.
Thanks
^ permalink raw reply
* Re: [PATCH][net-next] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: Paul Gortmaker @ 2012-11-08 14:21 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller
In-Reply-To: <1352382008-7039-1-git-send-email-claudiu.manoil@freescale.com>
On 12-11-08 08:40 AM, Claudiu Manoil wrote:
> Should gfar_init_bds() return with -ENOMEM inside gfar_alloc_skb_resources(),
> free_skb_resources() will be called twice in a row on the "cleanup" path,
> leading to duplicate kfree() calls for rx_|tx_queue->rx_|tx_skbuff resulting
> in segmentation fault.
> This patch prevents the segmentation fault to happen in the future
> (rx_|tx_sbkbuff set to NULL), and corrects the error path handling
> for gfar_init_bds().
Since gfar_init_bds is more like a slave routine to gfar_alloc_skb_resources,
I think the dup free_skb_resources should remain in the parent, and be removed
from gfar_init_bds. Otherwise the gfar_alloc_skb_resources will appear
confusing -- one will think it it allocates some resources, hits a failure
and then returns without bothering to do any cleanup of the parts it
did manage to allocate. (Then gfar_restore will have to call the free
itself _if_ gfar_init_bds fails too.)
Paul.
--
>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> Cc: "David S. Miller" <davem@davemloft.net>
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
> drivers/net/ethernet/freescale/gianfar.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index 1d03dcd..c5c82ad 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -311,7 +311,7 @@ static int gfar_alloc_skb_resources(struct net_device *ndev)
> }
>
> if (gfar_init_bds(ndev))
> - goto cleanup;
> + return -ENOMEM;
>
> return 0;
>
> @@ -1356,7 +1356,9 @@ static int gfar_restore(struct device *dev)
> if (!netif_running(ndev))
> return 0;
>
> - gfar_init_bds(ndev);
> + if (gfar_init_bds(ndev))
> + return -ENOMEM;
> +
> init_registers(ndev);
> gfar_set_mac_address(ndev);
> gfar_init_mac(ndev);
> @@ -1709,6 +1711,7 @@ static void free_skb_tx_queue(struct gfar_priv_tx_q *tx_queue)
> tx_queue->tx_skbuff[i] = NULL;
> }
> kfree(tx_queue->tx_skbuff);
> + tx_queue->tx_skbuff = NULL;
> }
>
> static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
> @@ -1732,6 +1735,7 @@ static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
> rxbdp++;
> }
> kfree(rx_queue->rx_skbuff);
> + rx_queue->rx_skbuff = NULL;
> }
>
> /* If there are any tx skbs or rx skbs still around, free them.
>
^ permalink raw reply
* Re: [PATCH] ipv6: fix two typos in a comment in xfrm6_init()
From: Steffen Klassert @ 2012-11-08 14:19 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev, davem
In-Reply-To: <1352363888-14068-1-git-send-email-roy.qing.li@gmail.com>
On Thu, Nov 08, 2012 at 04:38:08PM +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ---
> net/ipv6/xfrm6_policy.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
> index f3ed8ca..93832e8 100644
> --- a/net/ipv6/xfrm6_policy.c
> +++ b/net/ipv6/xfrm6_policy.c
> @@ -332,10 +332,10 @@ int __init xfrm6_init(void)
> /*
> * We need a good default value for the xfrm6 gc threshold.
> * In ipv4 we set it to the route hash table size * 8, which
> - * is half the size of the maximaum route cache for ipv4. It
> + * is half the size of the maximum route cache for ipv4.
The routing cache is removed, so this comment is obsolete. But it reminds
me that we set the gc threshold to ip_rt_max_size/2 in ipv4. With the
routing cache removal patch, ip_rt_max_size was set to INT_MAX. So the gc
starts to remove entries when a threshold of INT_MAX/2 is reached.
cat /proc/sys/net/ipv4/xfrm4_gc_thresh
1073741823
I guess this was not intentional.
^ permalink raw reply
* Re: [PATCH v2 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
From: Felipe Balbi @ 2012-11-08 13:37 UTC (permalink / raw)
To: David Miller; +Cc: iancoolidge, gregkh, balbi, linux-usb, netdev
In-Reply-To: <20121107.212752.1709967292920700431.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
Hi,
On Wed, Nov 07, 2012 at 09:27:52PM -0500, David Miller wrote:
> From: Ian Coolidge <iancoolidge@gmail.com>
> Date: Wed, 7 Nov 2012 16:39:17 -0800
>
> > cdc_eem USB host driver and gadget driver both are broken in 1500 MTU
> > case while using 802.1Q VLANs. In both cases, this is due to the
> > assumption of standard Ethernet frame length.
> >
> > v2: rebase against Dave Miller's 'net/master' tree
> >
> > Ian Coolidge (2):
> > usb: gadget: g_ether: fix frame size check for 802.1Q
> > net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
>
> Applied, thanks.
did you take both ? I'd rather you waited for my Ack for anything under
drivers/usb/gadget/ so we avoid conflicts later.
cheers
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH net-next] netconsole: add oops_only module option
From: Cong Wang @ 2012-11-08 13:42 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Cong Wang
Some people wants to log only oops messages via netconsole,
(this is also why netoops was invented)
so add a module option for netconsole. This can be tuned
via /sys/module/netconsole/parameters/oops_only at run time
as well.
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index b332112..6989ebe 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -56,6 +56,10 @@ static char config[MAX_PARAM_LENGTH];
module_param_string(netconsole, config, MAX_PARAM_LENGTH, 0);
MODULE_PARM_DESC(netconsole, " netconsole=[src-port]@[src-ip]/[dev],[tgt-port]@<tgt-ip>/[tgt-macaddr]");
+static bool oops_only = false;
+module_param(oops_only, bool, 0600);
+MODULE_PARM_DESC(oops_only, "Only log oops messages");
+
#ifndef MODULE
static int __init option_setup(char *opt)
{
@@ -683,6 +687,8 @@ static void write_msg(struct console *con, const char *msg, unsigned int len)
struct netconsole_target *nt;
const char *tmp;
+ if (oops_only && !oops_in_progress)
+ return;
/* Avoid taking lock and disabling interrupts unnecessarily */
if (list_empty(&target_list))
return;
^ permalink raw reply related
* [PATCH][net-next] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: Claudiu Manoil @ 2012-11-08 13:40 UTC (permalink / raw)
To: netdev; +Cc: Paul Gortmaker, David S. Miller, Claudiu Manoil
Should gfar_init_bds() return with -ENOMEM inside gfar_alloc_skb_resources(),
free_skb_resources() will be called twice in a row on the "cleanup" path,
leading to duplicate kfree() calls for rx_|tx_queue->rx_|tx_skbuff resulting
in segmentation fault.
This patch prevents the segmentation fault to happen in the future
(rx_|tx_sbkbuff set to NULL), and corrects the error path handling
for gfar_init_bds().
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 1d03dcd..c5c82ad 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -311,7 +311,7 @@ static int gfar_alloc_skb_resources(struct net_device *ndev)
}
if (gfar_init_bds(ndev))
- goto cleanup;
+ return -ENOMEM;
return 0;
@@ -1356,7 +1356,9 @@ static int gfar_restore(struct device *dev)
if (!netif_running(ndev))
return 0;
- gfar_init_bds(ndev);
+ if (gfar_init_bds(ndev))
+ return -ENOMEM;
+
init_registers(ndev);
gfar_set_mac_address(ndev);
gfar_init_mac(ndev);
@@ -1709,6 +1711,7 @@ static void free_skb_tx_queue(struct gfar_priv_tx_q *tx_queue)
tx_queue->tx_skbuff[i] = NULL;
}
kfree(tx_queue->tx_skbuff);
+ tx_queue->tx_skbuff = NULL;
}
static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
@@ -1732,6 +1735,7 @@ static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
rxbdp++;
}
kfree(rx_queue->rx_skbuff);
+ rx_queue->rx_skbuff = NULL;
}
/* If there are any tx skbs or rx skbs still around, free them.
--
1.6.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox