* RE: [E1000-devel] [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HD
From: David Laight @ 2013-02-21 9:42 UTC (permalink / raw)
To: Eric Dumazet, Alexander Duyck
Cc: Allan, Bruce W, e1000-devel, netdev, Brandeburg, Jesse,
Daniel Santos, Andrew Morton, Wu, Fengguang
In-Reply-To: <1361388156.19353.216.camel@edumazet-glaptop>
> > The problem is the 256 byte alignment for L1_CACHE_BYTES is increasing
> > the size of the data and shared info significantly pushing us past the
> > 2K limit.
> >
> > I'll look into this since it likely affects ixgbe as well.
Doesn't a 256 byte cache line cause issues almost everywhere
anything is marked as 'cache_aligned' ?
Some other structures have members part way down marked that way
so that the 2nd cache line (with smaller lines) contains a
known set of fields (either to get them together, or out of the
cache line containing the first part of the data).
With 256 byte cache lines the entire structure would probably be
a single cache line - except that it gets extended to two lines.
I know that some people have a habit of allocating mutex in their
own cache line (with nothing else), that also doesn't make sense
to me - especially with large cache lines (I don't know if there
any of those in Linux).
David
^ permalink raw reply
* Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings)
From: Rusty Russell @ 2013-02-21 6:37 UTC (permalink / raw)
To: Ohad Ben-Cohen, Sjur Brændeland
Cc: Dmitry Tarnyagin, Sjur Brændeland, Linus Walleij, Ido Yariv,
linux-kernel@vger.kernel.org, Erwan Yvin, virtualization, netdev,
David S. Miller
In-Reply-To: <CAK=Wgbb0EeiCh504jsoX+izzi+ZogfEDttz2cHRd4pVXvQunQw@mail.gmail.com>
Ohad Ben-Cohen <ohad@wizery.com> writes:
> Hi Sjur,
>
> On Tue, Feb 12, 2013 at 1:49 PM, <sjur.brandeland@stericsson.com> wrote:
>> From: Sjur Brændeland <sjur.brandeland@stericsson.com>
>>
>> Add functions for creating, deleting and kicking host-side virtio rings.
>>
>> The host ring is not integrated with virtiqueues and cannot be managed
>> through virtio-config.
>
> Is that an inherent design/issue of vringh or just a description of
> the current vringh code ?
It's by design. The producer (virtqueue) and consumer (vringh) are two
sides of the same coin, but they do different things.
virtqueue is a slightly higher level abstraction which assumes a
virtio_device, because every user so far has had one. vringh doesn't,
because it's also aimed to underlie vhost.c which doesn't really have
one.
> This is possible of course thanks to the abstraction provided by
> virtio: remoteproc only implements a set of callbacks which virtio
> invokes when needed.
>
> Do we not want to follow a similar design scheme with vringh ?
Hmm... I clearly jumped the gun, assuming consensus was already reached.
I have put these patches *back* into pending-rebases, and they will not
be merged this merge window.
Cheers,
Rusty.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* BCM5709 hang and state dump...
From: Daniel J Blueman @ 2013-02-21 5:26 UTC (permalink / raw)
To: Eilon Greenstein, Michael Chan; +Cc: Steffen Persvold, netdev
Hi Michael/Eilon,
On a large system with 552 cores, 1.5TB memory and linux 3.7, under some
particular workloads, we've seem the Broadcom 5709 network controller
hang [1]. It's running boot code 6.2.0 and NCSI code 2.0.11.
We suspect completion timeouts may be occurring due to possible starvation.
Is there anything significant/indicative from the state dumped?
Many thanks,
Daniel
--- [1]
bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.2.3 (June
27, 2012)
bnx2 0000:01:00.0 eth0: Broadcom NetXtreme II BCM5709 1000Base-T (C0)
PCI Express found at mem fc000000, IRQ 44, node addr e4:1f:13:80:70:03
bnx2 0000:01:00.1: enabling device (0140 -> 0142)
bnx2 0000:01:00.0: irq 72 for MSI/MSI-X
bnx2 0000:01:00.0: irq 73 for MSI/MSI-X
bnx2 0000:01:00.0: irq 74 for MSI/MSI-X
bnx2 0000:01:00.0: irq 75 for MSI/MSI-X
bnx2 0000:01:00.0: irq 76 for MSI/MSI-X
bnx2 0000:01:00.0: irq 77 for MSI/MSI-X
bnx2 0000:01:00.0: irq 78 for MSI/MSI-X
bnx2 0000:01:00.0: irq 79 for MSI/MSI-X
bnx2 0000:01:00.0 eth0: using MSIX
bnx2 0000:01:00.0 eth0: NIC Copper Link is Up, 1000 Mbps full duplex
<an hour later>
bnx2 0000:01:00.0 eth0: <--- start FTQ dump --->
bnx2 0000:01:00.0 eth0: RV2P_PFTQ_CTL 00010000
bnx2 0000:01:00.0 eth0: RV2P_TFTQ_CTL 00020000
bnx2 0000:01:00.0 eth0: RV2P_MFTQ_CTL 00004000
bnx2 0000:01:00.0 eth0: TBDR_FTQ_CTL 00004000
bnx2 0000:01:00.0 eth0: TDMA_FTQ_CTL 00010000
bnx2 0000:01:00.0 eth0: TXP_FTQ_CTL 00010000
bnx2 0000:01:00.0 eth0: TXP_FTQ_CTL 00010000
bnx2 0000:01:00.0 eth0: TPAT_FTQ_CTL 00010000
bnx2 0000:01:00.0 eth0: RXP_CFTQ_CTL 00008000
bnx2 0000:01:00.0 eth0: RXP_FTQ_CTL 00100000
bnx2 0000:01:00.0 eth0: COM_COMXQ_FTQ_CTL 00010000
bnx2 0000:01:00.0 eth0: COM_COMTQ_FTQ_CTL 00020000
bnx2 0000:01:00.0 eth0: COM_COMQ_FTQ_CTL 00010000
bnx2 0000:01:00.0 eth0: CP_CPQ_FTQ_CTL 00004000
bnx2 0000:01:00.0 eth0: CPU states:
bnx2 0000:01:00.0 eth0: 045000 mode b84c state 80001000 evt_mask 500 pc
8001284 pc 8001284 instr 8e260000
bnx2 0000:01:00.0 eth0: 085000 mode b84c state 80005000 evt_mask 500 pc
8000a4c pc 8000a5c instr 38420001
bnx2 0000:01:00.0 eth0: 0c5000 mode b84c state 80001000 evt_mask 500 pc
8004c20 pc 8004c10 instr 32050003
bnx2 0000:01:00.0 eth0: 105000 mode b8cc state 80008000 evt_mask 500 pc
8000aa0 pc 8000aa0 instr 8c420020
bnx2 0000:01:00.0 eth0: 145000 mode b880 state 80000000 evt_mask 500 pc
800d978 pc 8009c18 instr afbf001c
bnx2 0000:01:00.0 eth0: 185000 mode b8cc state 80000000 evt_mask 500 pc
8000cb0 pc 8000c58 instr 8ce800e8
bnx2 0000:01:00.0 eth0: <--- end FTQ dump --->
bnx2 0000:01:00.0 eth0: <--- start TBDC dump --->
bnx2 0000:01:00.0 eth0: TBDC free cnt: 32
bnx2 0000:01:00.0 eth0: LINE CID BIDX CMD VALIDS
bnx2 0000:01:00.0 eth0: 00 001180 0f40 00 [0]
bnx2 0000:01:00.0 eth0: 01 001180 0f48 00 [0]
bnx2 0000:01:00.0 eth0: 02 1db680 af58 f6 [0]
bnx2 0000:01:00.0 eth0: 03 0ddd00 fb58 fd [0]
bnx2 0000:01:00.0 eth0: 04 1fff80 ffc8 ef [0]
bnx2 0000:01:00.0 eth0: 05 1e9f80 9fa8 cf [0]
bnx2 0000:01:00.0 eth0: 06 1d7380 77e8 ff [0]
bnx2 0000:01:00.0 eth0: 07 1ddf00 7bb0 fb [0]
bnx2 0000:01:00.0 eth0: 08 1edb80 ff78 6f [0]
bnx2 0000:01:00.0 eth0: 09 1e9e80 ee58 9e [0]
bnx2 0000:01:00.0 eth0: 0a 17f780 fff8 74 [0]
bnx2 0000:01:00.0 eth0: 0b 1d7e00 6db8 fd [0]
bnx2 0000:01:00.0 eth0: 0c 1f7780 bff0 cf [0]
bnx2 0000:01:00.0 eth0: 0d 1bff80 bff8 ff [0]
bnx2 0000:01:00.0 eth0: 0e 17ff80 3de0 fe [0]
bnx2 0000:01:00.0 eth0: 0f 1ff780 98f0 ff [0]
bnx2 0000:01:00.0 eth0: 10 1f7f80 ffd8 ee [0]
bnx2 0000:01:00.0 eth0: 11 0e7780 eaa8 7f [0]
bnx2 0000:01:00.0 eth0: 12 1f9980 fde8 f7 [0]
bnx2 0000:01:00.0 eth0: 13 07ef80 ffc8 77 [0]
bnx2 0000:01:00.0 eth0: 14 1fbf80 57e8 bf [0]
bnx2 0000:01:00.0 eth0: 15 0fae80 df68 5b [0]
bnx2 0000:01:00.0 eth0: 16 0fff80 7ff8 be [0]
bnx2 0000:01:00.0 eth0: 17 1f7680 fed8 c6 [0]
bnx2 0000:01:00.0 eth0: 18 03e380 fe70 7b [0]
bnx2 0000:01:00.0 eth0: 19 0bcd80 7db8 7f [0]
bnx2 0000:01:00.0 eth0: 1a 0cb580 bbf0 ef [0]
bnx2 0000:01:00.0 eth0: 1b 0dfd80 dbf8 fb [0]
bnx2 0000:01:00.0 eth0: 1c 0bff80 7ff8 f3 [0]
bnx2 0000:01:00.0 eth0: 1d 0dfb80 f9f8 ec [0]
bnx2 0000:01:00.0 eth0: 1e 1e6e80 9be8 f7 [0]
bnx2 0000:01:00.0 eth0: 1f 1faf80 db78 52 [0]
bnx2 0000:01:00.0 eth0: <--- end TBDC dump --->
bnx2 0000:01:00.0 eth0: DEBUG: intr_sem[0] PCI_CMD[00100546]
bnx2 0000:01:00.0 eth0: DEBUG: PCI_PM[19002008] PCI_MISC_CFG[92000088]
bnx2 0000:01:00.0 eth0: DEBUG: EMAC_TX_STATUS[00000008]
EMAC_RX_STATUS[00000000]
bnx2 0000:01:00.0 eth0: DEBUG: RPM_MGMT_PKT_CTRL[40000088]
bnx2 0000:01:00.0 eth0: DEBUG: HC_STATS_INTERRUPT_STATUS[010600f9]
bnx2 0000:01:00.0 eth0: DEBUG: PBA[00000000]
bnx2 0000:01:00.0 eth0: <--- start MCP states dump --->
bnx2 0000:01:00.0 eth0: DEBUG: MCP_STATE_P0[0003610e] MCP_STATE_P1[0003610e]
bnx2 0000:01:00.0 eth0: DEBUG: MCP mode[0000b880] state[80000000]
evt_mask[00000500]
bnx2 0000:01:00.0 eth0: DEBUG: pc[0800d31c] pc[0800b46c] instr[a023f35c]
bnx2 0000:01:00.0 eth0: DEBUG: shmem states:
bnx2 0000:01:00.0 eth0: DEBUG: drv_mb[01030003] fw_mb[00000003]
link_status[8000006f]
bnx2 0000:01:00.0 eth0: DEBUG: dev_info_signature[44564903]
reset_type[01005254]
bnx2 0000:01:00.0 eth0: DEBUG: 000001c0: 01005254 42530083 0003610e 00000000
bnx2 0000:01:00.0 eth0: DEBUG: 000003cc: 44444444 44444444 44444444 00000a14
bnx2 0000:01:00.0 eth0: DEBUG: 000003dc: 0004ffff 00000000 00000000 00000000
bnx2 0000:01:00.0 eth0: DEBUG: 000003ec: 00000000 00000000 00000000 00000000
bnx2 0000:01:00.0 eth0: DEBUG: 0x3fc[0000ffff]
bnx2 0000:01:00.0 eth0: <--- end MCP states dump --->
bnx2 0000:01:00.0 eth0: NIC Copper Link is Down
--
Daniel J Blueman
Principal Software Engineer, Numascale Asia
^ permalink raw reply
* Re: [GIT] Networking
From: Paul Gortmaker @ 2013-02-21 3:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, Andrew Morton, Network Development,
Linux Kernel Mailing List
In-Reply-To: <CA+55aFz=tzf9a-SY1CqCAxsqRDz=ebE69YoZ30at6kHeKKhsaA@mail.gmail.com>
On Wed, Feb 20, 2013 at 10:05 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Feb 20, 2013 at 2:09 PM, David Miller <davem@davemloft.net> wrote:
>>
>> 15) Orphan and delete a bunch of pre-historic networking drivers from
>> Paul Gortmaker.
>
> Nooo.... You killed the 3c501 and 3c503 drivers! Snif.
Not true! They were dead long ago, and here we were just providing
the service of a coroner, by removing the bodies vs. having them left to
decompose on the side of the street.
Paul.
--
>
> I wonder if they still worked..
>
> Linus
> --
> 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/
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2013-02-21 3:40 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <CA+55aFzuNa9N313pYn+_qS+F7E9mTeWDDjOJhdm0zTZDoZ6XTg@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 20 Feb 2013 19:12:37 -0800
> On Wed, Feb 20, 2013 at 7:05 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Nooo.... You killed the 3c501 and 3c503 drivers! Snif.
>
> .. but thank gods, the 3c509 still exists in the tree. I was worried
> for a minute.
Don't worry, the 3c509 will have it's day of reckoning too at
some point. :-)
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2013-02-21 3:12 UTC (permalink / raw)
To: David Miller
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <CA+55aFz=tzf9a-SY1CqCAxsqRDz=ebE69YoZ30at6kHeKKhsaA@mail.gmail.com>
On Wed, Feb 20, 2013 at 7:05 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Nooo.... You killed the 3c501 and 3c503 drivers! Snif.
.. but thank gods, the 3c509 still exists in the tree. I was worried
for a minute.
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2013-02-21 3:05 UTC (permalink / raw)
To: David Miller
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <20130220.170901.343210063003534302.davem@davemloft.net>
On Wed, Feb 20, 2013 at 2:09 PM, David Miller <davem@davemloft.net> wrote:
>
> 15) Orphan and delete a bunch of pre-historic networking drivers from
> Paul Gortmaker.
Nooo.... You killed the 3c501 and 3c503 drivers! Snif.
I wonder if they still worked..
Linus
^ permalink raw reply
* Re: [PATCH 1/1] net: fec: fix crash at mx53 qsb board
From: Fabio Estevam @ 2013-02-21 2:19 UTC (permalink / raw)
To: Frank Li
Cc: lznuaa, davem, linux-arm-kernel, netdev, shawn.guo, B38611,
s.hauer
In-Reply-To: <1361408848-14118-1-git-send-email-Frank.Li@freescale.com>
On Wed, Feb 20, 2013 at 10:07 PM, Frank Li <Frank.Li@freescale.com> wrote:
> Unable to handle kernel NULL pointer dereference at virtual address 00000002
> pgd = 80004000
> [00000002] *pgd=00000000
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 Not tainted (3.8.0-rc7-next-20130215+ #346)
> PC is at fec_enet_interrupt+0xd0/0x348
> LR is at fec_enet_interrupt+0xb8/0x348
> pc : [<80372b7c>] lr : [<80372b64>] psr: 60000193
> sp : df855c20 ip : df855c20 fp : df855c74
> r10: 00000516 r9 : 1c000000 r8 : 00000000
> r7 : 00000000 r6 : 00000000 r5 : 00000000 r4 : df9b7800
> r3 : df9b7df4 r2 : 00000000 r1 : 00000000 r0 : df9b7d34
>
> It is possible that issue a irq between request_irq and fec_enet_init.
> Irq handle will be called but driver data structure is not ready yet.
>
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
^ permalink raw reply
* [PATCH 1/1] net: fec: fix crash at mx53 qsb board
From: Frank Li @ 2013-02-21 1:07 UTC (permalink / raw)
To: lznuaa, davem, linux-arm-kernel, netdev
Cc: shawn.guo, B38611, s.hauer, festevam, Frank Li
Unable to handle kernel NULL pointer dereference at virtual address 00000002
pgd = 80004000
[00000002] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 Not tainted (3.8.0-rc7-next-20130215+ #346)
PC is at fec_enet_interrupt+0xd0/0x348
LR is at fec_enet_interrupt+0xb8/0x348
pc : [<80372b7c>] lr : [<80372b64>] psr: 60000193
sp : df855c20 ip : df855c20 fp : df855c74
r10: 00000516 r9 : 1c000000 r8 : 00000000
r7 : 00000000 r6 : 00000000 r5 : 00000000 r4 : df9b7800
r3 : df9b7df4 r2 : 00000000 r1 : 00000000 r0 : df9b7d34
It is possible that issue a irq between request_irq and fec_enet_init.
Irq handle will be called but driver data structure is not ready yet.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/net/ethernet/freescale/fec.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 7c6e890..a860486 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -1676,7 +1676,6 @@ static int fec_enet_init(struct net_device *ndev)
ndev->netdev_ops = &fec_netdev_ops;
ndev->ethtool_ops = &fec_enet_ethtool_ops;
- writel(FEC_RX_DISABLED_IMASK, fep->hwp + FEC_IMASK);
netif_napi_add(ndev, &fep->napi, fec_enet_rx_napi, FEC_NAPI_WEIGHT);
/* Init enet descriptors */
@@ -1786,6 +1785,13 @@ fec_probe(struct platform_device *pdev)
fep->pdev = pdev;
fep->dev_id = dev_id++;
+ /*
+ * disable and clean all irq to avoid unexpected irq happen
+ * between init driver data structure and request_irq
+ */
+ writel(0, fep->hwp + FEC_IMASK);
+ writel(0xFFFFFFFF, fep->hwp + FEC_IEVENT);
+
fep->bufdesc_ex = 0;
if (!fep->hwp) {
--
1.7.1
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the mips tree
From: Stephen Rothwell @ 2013-02-21 2:01 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Hauke Mehrtens, John Crispin,
Ralf Baechle
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
include/linux/ssb/ssb_driver_gige.h between commit 111bd981e221 ("MIPS:
BCM47XX: add bcm47xx prefix in front of nvram function names") from the
mips tree and commit 180996c30517 ("ssb: get mac address from sprom
struct for gige driver") from the net-next tree.
I fixed it up (the latter seems to supercede the former, so I used that)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
From: Bing Zhao @ 2013-02-21 1:59 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Harro Haan, Dan Williams, libertas-dev@lists.infradead.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
John W. Linville, linux-kernel@vger.kernel.org
In-Reply-To: <1361249203.14137.27.camel@unicorn.kokotovo>
Hi Lubomir,
> > > @@ -825,20 +825,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card *card)
> > >
> > > sdio_release_host(func);
> > >
> > > - /*
> > > - * FUNC_INIT is required for SD8688 WLAN/BT multiple functions
> > > - */
> > > - if (card->model == MODEL_8688) {
> > > - struct cmd_header cmd;
> > > -
> > > - memset(&cmd, 0, sizeof(cmd));
> > > -
> > > - lbs_deb_sdio("send function INIT command\n");
> > > - if (__lbs_cmd(priv, CMD_FUNC_INIT, &cmd, sizeof(cmd),
> > > - lbs_cmd_copyback, (unsigned long) &cmd))
> > > - netdev_alert(priv->dev, "CMD_FUNC_INIT cmd failed\n");
> > > - }
> > > -
> >
> > Removing FUNC_INIT could break things in some scenarios.
> > Could you please test the following case?
> >
> > 1. insmod liberates -> download firmware, send FUNC_INIT, ...
> > 2. rmmod libertas -> send FUNC_SHUTDOWN command to firmware; BT is still working.
> > 3. insmod libertas -> skip firmware downloading, send FUNC_INIT, ...
> >
> > If FUNC_INIT is removed, I don't expect step 3 to work.
>
> In case btmrvl_sdio is loaded, the driver always locks up in FUNC_INIT
> upon probe time, thus I'm not able to proceed to further steps.
>
> [ 209.338953] [<c0502248>] (__schedule+0x610/0x764) from [<bf20ae24>] (__lbs_cmd+0xb8/0x130
> [libertas])
> [ 209.348340] [<bf20ae24>] (__lbs_cmd+0xb8/0x130 [libertas]) from [<bf222474>]
> (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
> [ 209.360136] [<bf222474>] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio]) from [<bf2226c4>]
> (if_sdio_power_on+0x18c/0x20c [libertas_sdio])
> [ 209.373052] [<bf2226c4>] (if_sdio_power_on+0x18c/0x20c [libertas_sdio]) from [<bf222944>]
> (if_sdio_probe+0x200/0x31c [libertas_sdio])
> [ 209.385316] [<bf222944>] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from [<bf01d820>]
> (sdio_bus_probe+0x94/0xfc [mmc_core])
> [ 209.396748] [<bf01d820>] (sdio_bus_probe+0x94/0xfc [mmc_core]) from [<c02e729c>]
> (driver_probe_device+0x12c/0x348)
> [ 209.407214] [<c02e729c>] (driver_probe_device+0x12c/0x348) from [<c02e7530>]
> (__driver_attach+0x78/0x9c)
> [ 209.416798] [<c02e7530>] (__driver_attach+0x78/0x9c) from [<c02e5658>] (bus_for_each_dev+0x50/0x88)
> [ 209.425946] [<c02e5658>] (bus_for_each_dev+0x50/0x88) from [<c02e6810>]
> (bus_add_driver+0x108/0x268)
> [ 209.435180] [<c02e6810>] (bus_add_driver+0x108/0x268) from [<c02e782c>]
> (driver_register+0xa4/0x134)
> [ 209.444426] [<c02e782c>] (driver_register+0xa4/0x134) from [<bf22601c>]
> (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
> [ 209.455339] [<bf22601c>] (if_sdio_init_module+0x1c/0x3c [libertas_sdio]) from [<c00085b8>]
> (do_one_initcall+0x98/0x174)
> [ 209.466236] [<c00085b8>] (do_one_initcall+0x98/0x174) from [<c0076504>] (load_module+0x1c5c/0x1f80)
> [ 209.475390] [<c0076504>] (load_module+0x1c5c/0x1f80) from [<c007692c>]
> (sys_init_module+0x104/0x128)
> [ 209.484632] [<c007692c>] (sys_init_module+0x104/0x128) from [<c0008c40>]
> (ret_fast_syscall+0x0/0x38)
>
> In case btmrvl_sdio is _not_ loaded, insmod returns, but driver locks up
> waiting for FUNC_INIT to finish:
>
> [ 300.538859] [<c0502248>] (__schedule+0x610/0x764) from [<bf1fae24>] (__lbs_cmd+0xb8/0x130
> [libertas])
> [ 300.548600] [<bf1fae24>] (__lbs_cmd+0xb8/0x130 [libertas]) from [<bf212474>]
> (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
> [ 300.560398] [<bf212474>] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio]) from [<bf213230>]
> (if_sdio_do_prog_firmware+0x414/0x454 [libertas_sdio])
> [ 300.574052] [<bf213230>] (if_sdio_do_prog_firmware+0x414/0x454 [libertas_sdio]) from [<bf1fffbc>]
> (lbs_fw_loaded+0x24/0x58 [libertas])
> [ 300.586907] [<bf1fffbc>] (lbs_fw_loaded+0x24/0x58 [libertas]) from [<c02f02c0>]
> (request_firmware_work_func+0xb0/0xf4)
> [ 300.597746] [<c02f02c0>] (request_firmware_work_func+0xb0/0xf4) from [<c003ae0c>]
> (process_one_work+0x348/0x6a8)
> [ 300.608288] [<c003ae0c>] (process_one_work+0x348/0x6a8) from [<c003b408>]
> (worker_thread+0x268/0x390)
> [ 300.617630] [<c003b408>] (worker_thread+0x268/0x390) from [<c00414b0>] (kthread+0xc0/0xd4)
> [ 300.625947] [<c00414b0>] (kthread+0xc0/0xd4) from [<c0008ce8>] (ret_from_fork+0x14/0x20)
> [ 300.634135] 2 locks held by kworker/0:1/19:
> [ 300.638383] #0: (events){.+.+.+}, at: [<c003accc>] process_one_work+0x208/0x6a8
> [ 300.646512] #1: ((&fw_work->work)){+.+.+.}, at: [<c003accc>] process_one_work+0x208/0x6a8
There seems to be a race condition in lbs_thread().
At line 582:
582 if (!priv->fw_ready)
583 continue;
The fw_ready is 0, so you never get the chance to execute the FUNC_INIT command.
617 /* Execute the next command */
618 if (!priv->dnld_sent && !priv->cur_cmd)
619 lbs_execute_next_command(priv);
Could you try the following change?
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libe
index 739309e..8f5d977 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,6 +825,8 @@ static void if_sdio_finish_power_on(struct if_sdio_card *car
sdio_release_host(func);
+ priv->fw_ready = 1;
+
/*
* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
*/
@@ -839,7 +841,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card *car
netdev_alert(priv->dev, "CMD_FUNC_INIT cmd failed\n");
}
- priv->fw_ready = 1;
wake_up(&card->pwron_waitq);
if (!card->started) {
Thanks,
Bing
>
> If I remove the FUNC_INIT call, wifi works fine, but bluetooth stops
> working after a network scan:
>
> [root@megalodon lkundrak]# iwlist scan >/dev/null 2>&1
> [root@megalodon lkundrak]# hcitool scan --flush
> Device is not available: No such device
> [root@megalodon lkundrak]#
^ permalink raw reply related
* Hello dear,
From: Grace Efuna @ 2013-02-21 1:54 UTC (permalink / raw)
--
Hello dear,
I am miss Grace Efuna 24years and single, hope am not offending you by
expressing my feelings of having a friendship or relationship with you, can you
please write to me back with my email below for more communication and exchange
of pictures to know more about each other for a better unions-hip.
Thanks,
Yours Grace.
--
^ permalink raw reply
* Re: why is it not allowed to add a new socket protocol family as an external module?
From: Eric Dumazet @ 2013-02-21 1:39 UTC (permalink / raw)
To: Chris Friesen; +Cc: Stephen Hemminger, netdev
In-Reply-To: <51256E02.4080509@genband.com>
On Wed, 2013-02-20 at 18:44 -0600, Chris Friesen wrote:
> Yes, there are a number of tables sized by NPROTO/AF_MAX/PF_MAX (and the
> fact that we use all three within the kernel is kind of sad) but there
> is no technical reason why we couldn't extend those dynamically if
> desired (with a linked list of additional protocols, perhaps).
>
> Hence my question--is the restriction for an ideological reason or
> simply because nobody thought it was worth the effort?
>
I guess nobody did the preliminary work.
lockdep might be the tricky part.
net/core/sock.c:197:static const char *const af_family_key_strings[AF_MAX+1] = {
net/core/sock.c:211: "sk_lock-AF_NFC" , "sk_lock-AF_MAX"
net/core/sock.c:213:static const char *const af_family_slock_key_strings[AF_MAX+1] = {
net/core/sock.c:227: "slock-AF_NFC" , "slock-AF_MAX"
net/core/sock.c:229:static const char *const af_family_clock_key_strings[AF_MAX+1] = {
net/core/sock.c:243: "clock-AF_NFC" , "clock-AF_MAX"
net/core/sock.c:250:static struct lock_class_key af_callback_keys[AF_MAX];
^ permalink raw reply
* Re: why is it not allowed to add a new socket protocol family as an external module?
From: David Miller @ 2013-02-21 1:05 UTC (permalink / raw)
To: chris.friesen; +Cc: stephen, netdev
In-Reply-To: <51256E02.4080509@genband.com>
From: Chris Friesen <chris.friesen@genband.com>
Date: Wed, 20 Feb 2013 18:44:50 -0600
> On 02/20/2013 05:23 PM, Stephen Hemminger wrote:
>> On Wed, 20 Feb 2013 10:56:13 -0600
>> Chris Friesen<chris.friesen@genband.com> wrote:
>>
>>> Hi,
>>>
>>> I was just wondering why the kernel doesn't allow a new network
>>> protocol
>>> family to be loaded as as a kernel module built outside the kernel
>>> source tree.
>
>> If you want an answer, to the question, use a tool like cscope and
>> learn to read the kernel code. There are several tables of pointers
>> sized by NPROTO.
>
> That's a bit insulting, don't you think?
Absolutely not insulting at all.
The list is _NOT_ a place to go when you're just too damn lazy to take
the 10 seconds it would have taken to answer your question with a
quick NPROTO grep on the kernel sources.
Stephen's response to you was therefore %100 appropriate, and I would
have told you likewise if I had been the first to respond.
^ permalink raw reply
* Re: Problem with Reaktek 8168
From: Ralf Friedl @ 2013-02-21 0:48 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20130220231122.GA22163@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Ralf Friedl <Ralf.Friedl@online.de> :
> [...]
>
>> If it helps I can also run a custom driver with additional debug code.
>>
> Can you send the XID line that your stock kernel r8169 driver displays ?
> It will help identifying your chipset revision as a start.
>
Thank you for your reply.
These are the messages when the driver loads.
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0: irq 90 for MSI/MSI-X
r8169 0000:02:00.0: eth0: RTL8168f/8111f at 0xffffc90010122000,
50:46:5d:a7:30:7a, XID 08000880 IRQ 90
r8169 0000:02:00.0: eth0: jumbo features [frames: 9200 bytes, tx
checksumming: ko]
Ralf Friedl
^ permalink raw reply
* Re: why is it not allowed to add a new socket protocol family as an external module?
From: Chris Friesen @ 2013-02-21 0:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20130220152325.64c57d55@samsung-9>
On 02/20/2013 05:23 PM, Stephen Hemminger wrote:
> On Wed, 20 Feb 2013 10:56:13 -0600
> Chris Friesen<chris.friesen@genband.com> wrote:
>
>> Hi,
>>
>> I was just wondering why the kernel doesn't allow a new network protocol
>> family to be loaded as as a kernel module built outside the kernel
>> source tree.
> If you want an answer, to the question, use a tool like cscope and
> learn to read the kernel code. There are several tables of pointers sized by NPROTO.
That's a bit insulting, don't you think?
Yes, there are a number of tables sized by NPROTO/AF_MAX/PF_MAX (and the
fact that we use all three within the kernel is kind of sad) but there
is no technical reason why we couldn't extend those dynamically if
desired (with a linked list of additional protocols, perhaps).
Hence my question--is the restriction for an ideological reason or
simply because nobody thought it was worth the effort?
Chris
^ permalink raw reply
* Re: Problem with Reaktek 8168
From: Francois Romieu @ 2013-02-20 23:11 UTC (permalink / raw)
To: Ralf Friedl; +Cc: netdev
In-Reply-To: <5124B909.4080907@online.de>
Ralf Friedl <Ralf.Friedl@online.de> :
[...]
> If it helps I can also run a custom driver with additional debug code.
Can you send the XID line that your stock kernel r8169 driver displays ?
It will help identifying your chipset revision as a start.
Thanks.
--
Ueimor
^ permalink raw reply
* Re: netlink, RTM_NEWTCLASS, nested attributes
From: Denys Fedoryshchenko @ 2013-02-20 23:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, pablo, jhs, davem, linux-kernel
In-Reply-To: <20130220152130.72df1258@samsung-9>
On 2013-02-21 01:21, Stephen Hemminger wrote:
> On Tue, 19 Feb 2013 23:45:25 +0200
> Denys Fedoryshchenko <denys@visp.net.lb> wrote:
>
>> Hi
>>
>> I tried recently to write my own tool based on amazing libmnl (which
>> makes understanding of netlink - easy), written
>> by Pablo Neira Ayuso, to manage QoS in Linux and faced problem,
>> which i
>> think probably
>> a bug in handling netlink messages in kernel.
>>
>> For example if i send message, RTM_NEWTCLASS, after attribute
>> TCA_OPTIONS i have nested attributes,
>> for example in HTB: TCA_HTB_PARMS, TCA_HTB_RTAB, TCA_HTB_CTAB.
>> libmnl, if i use nested attribute, adding a bit to it, by OR -
>> NLA_F_NESTED(1 << 15).
>> If i remove this flag - everything works fine. And here is the case,
>> iproute2 tools
>> just update length of TCA_OPTIONS, without setting flag, and it
>> works
>> because of that fine too.
>>
>> So there is basically 3 solutions:
>> 1)New function in libmnl to do nested attributes without setting by
>> OR
>> flag
>> 2)AND-ing attribute type in kernel to ignore nested flag
>> 3)Keeping as is, who cares?
>>
>
> Several legacy netlink interfaces don't use NESTED flag. These are by
> now enshrined in ABI and can't change. In code, that uses libmnl, I
> just
> manually clear the flag as needed and document why. This could
> be added to libmnl.
Thank you for clarification!
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* Re: why is it not allowed to add a new socket protocol family as an external module?
From: Stephen Hemminger @ 2013-02-20 23:23 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev
In-Reply-To: <5125002D.9080008@genband.com>
On Wed, 20 Feb 2013 10:56:13 -0600
Chris Friesen <chris.friesen@genband.com> wrote:
> Hi,
>
> I was just wondering why the kernel doesn't allow a new network protocol
> family to be loaded as as a kernel module built outside the kernel
> source tree.
>
> Most of the networking code would seem to allow this, but the check for
> "if (ops->family >= NPROTO)" in sock_register() means that only protocol
> families defined in socket.h can be registered.
>
> Was this intentional for ideological reasons, or has nobody wanted to be
> able to add arbitrary network protocols without patching the kernel and
> rebuilding?
>
If you want an answer, to the question, use a tool like cscope and
learn to read the kernel code. There are several tables of pointers sized by NPROTO.
^ permalink raw reply
* Re: netlink, RTM_NEWTCLASS, nested attributes
From: Stephen Hemminger @ 2013-02-20 23:21 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev, pablo, jhs, davem, linux-kernel
In-Reply-To: <3a8fd12d117d2281ac90cce96c0d68f3@visp.net.lb>
On Tue, 19 Feb 2013 23:45:25 +0200
Denys Fedoryshchenko <denys@visp.net.lb> wrote:
> Hi
>
> I tried recently to write my own tool based on amazing libmnl (which
> makes understanding of netlink - easy), written
> by Pablo Neira Ayuso, to manage QoS in Linux and faced problem, which i
> think probably
> a bug in handling netlink messages in kernel.
>
> For example if i send message, RTM_NEWTCLASS, after attribute
> TCA_OPTIONS i have nested attributes,
> for example in HTB: TCA_HTB_PARMS, TCA_HTB_RTAB, TCA_HTB_CTAB.
> libmnl, if i use nested attribute, adding a bit to it, by OR -
> NLA_F_NESTED(1 << 15).
> If i remove this flag - everything works fine. And here is the case,
> iproute2 tools
> just update length of TCA_OPTIONS, without setting flag, and it works
> because of that fine too.
>
> So there is basically 3 solutions:
> 1)New function in libmnl to do nested attributes without setting by OR
> flag
> 2)AND-ing attribute type in kernel to ignore nested flag
> 3)Keeping as is, who cares?
>
Several legacy netlink interfaces don't use NESTED flag. These are by
now enshrined in ABI and can't change. In code, that uses libmnl, I just
manually clear the flag as needed and document why. This could
be added to libmnl.
^ permalink raw reply
* Re: [PATCH 01/10] netfilter: make /proc/net/netfilter pernet
From: Pablo Neira Ayuso @ 2013-02-20 23:13 UTC (permalink / raw)
To: Gao feng; +Cc: netfilter-devel, containers, ebiederm, netdev, lve
In-Reply-To: <51246EEA.5020301@cn.fujitsu.com>
On Wed, Feb 20, 2013 at 02:36:26PM +0800, Gao feng wrote:
> > This doesn't belong here to x_tables, it should be place in
> > include/net/net_namespace.h.
>
> Get it,will fix it in next version.
Thanks Gao.
> Should I wait for the nf-next being open again?
Yes.
^ permalink raw reply
* Re: [E1000-devel] [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH...
From: Eric Dumazet @ 2013-02-20 23:02 UTC (permalink / raw)
To: Alexander Duyck
Cc: Allan, Bruce W, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, Brandeburg, Jesse, Daniel Santos,
Andrew Morton, Wu, Fengguang
In-Reply-To: <51255277.2020005@intel.com>
On Wed, 2013-02-20 at 14:47 -0800, Alexander Duyck wrote:
> Huh? I'm not seeing what you are saying. The NET_SKB_PAD is the value
> that is in the last set of parenthesis since it was:
> (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH_FRAME_LEN + ETH_FCS_LEN)
> that is the bit that became:
> (32 + 2 + 16 + 1514 + 4)
>
> The problem is the skb_shared_info bit rounds up to 512 reducing the
> available space to 1536. If you add up all of the other bits ignoring
> the NET_SKB_PAD value you end up with exactly 1536 meaning the only
> value for NET_SKB_PAD that would work is 0.
Oh well, for one moment I thought the SKB_DATA_ALIGN() was also using
NET_SKB_PAD, but its using SMP_CACHE_BYTES.
^ permalink raw reply
* Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings)
From: Sjur Brændeland @ 2013-02-20 23:01 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Dmitry Tarnyagin, netdev, Linus Walleij,
linux-kernel@vger.kernel.org, Erwan Yvin, virtualization,
David S. Miller, Ido Yariv
In-Reply-To: <CAK=Wgbb0EeiCh504jsoX+izzi+ZogfEDttz2cHRd4pVXvQunQw@mail.gmail.com>
On Wed, Feb 20, 2013 at 5:05 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Hi Sjur,
>
> On Tue, Feb 12, 2013 at 1:49 PM, <sjur.brandeland@stericsson.com> wrote:
>> From: Sjur Brændeland <sjur.brandeland@stericsson.com>
>>
>> Add functions for creating, deleting and kicking host-side virtio rings.
>>
>> The host ring is not integrated with virtiqueues and cannot be managed
>> through virtio-config.
>
> Is that an inherent design/issue of vringh or just a description of
> the current vringh code ?
>
>> Remoteproc must export functions for handling the host-side virtio rings.
>
> Have you considered exporting this via virtio instead ?
Rusty should comment on this...
I asked Rusty the same question a while a go, see
http://lkml.org/lkml/2013/1/11/559
AFAIK, using the vringh API directly is a deliberate design choice.
[Sjur:]
>> How do you see the in-kernel API for this? I would like to see
>> something similar to my previous patches, where we extend
>> the virtqueue API. E.g. something like this:
>> struct virtqueue *vring_new_virtqueueh(...)...
[Rusty:]
>I was just going to create _kernel variants of all the _user helpers,
>and let you drive it directly like that.
>
>If we get a second in-kernel user, we create wrappers (I'd prefer not to
>overload struct virtqueue though).
>> The functions rproc_virtio_get_vringh(), rproc_virtio_del_vringh(),
>> rproc_virtio_kick_vringh() are added to remoteproc_virtio.c.
>
> I wonder if this is the way we want things to work.
>
> Following this design, virtio drivers that use these rproc_* functions
> will be coupled with the remoteproc framework.
>
> One issue with this is what happens if, e.g., a VIRTIO_ID_CAIF vdev is
> added by other than remoteproc (e.g. by virtio_pci or virtio_mmio).
> Not sure how probable this really is, and whether there's anything
> that prevents this, but things will go awry if this happens.
Yes, if you insert a "malicious device" like that you can make it crash,
but wouldn't most drivers do if you try to register a malicious device...?
If we really want to protect from this, we could perhaps validate the vdev
pointer in function rproc_virtio_new_vringh() by looking through the vdevs
of the registered rprocs.
> But maybe the important aspect to consider is whether we really want
> to couple virtio drivers (such as the upcoming caif one) with the
> remoteproc framework.
I'm not sure this is an issue for the CAIF driver. It would be very nice
if someone else could make use of it, but right now cannot see the CAIF
driver being used outside the remoteproc framework. This driver is
designed specifically to work with the STE-modem using the CAIF
protocol over a shared memory interface.
> If you'll take a look at the rpmsg virtio driver, there's nothing
> there which couples it with remoteproc. It's just a standard virtio
> driver, that can be easily used with traditional virtio hosts as well.
>
> This is possible of course thanks to the abstraction provided by
> virtio: remoteproc only implements a set of callbacks which virtio
> invokes when needed.
Yes, and generalizing the use of virtio devices in remoteproc
has been useful. It has enabled me to let remoteproc manage both
virtio_serial and virtio_caif devices :-)
>
> Do we not want to follow a similar design scheme with vringh ?
I know some of my colleagues has been working on symmetric vring
for rpmsg. Last I heard from them they were going to use the same
approach I've done for CAIF, by "reversing" the direction of the rings.
AFAIK this means that the current API I have proposed will work for
them as well.
If some other driver is showing up using the vringh kernel API where
the current API don't fit, I guess it's time to create some abstractions
and wrappers... But I hope the current approach will do for now?
> I have some other questions as well but maybe it's better to discuss
> first the bigger picture.
OK, but please don't hesitate to address this. I'm still aiming for this
to go into 3.9.
Regards,
Sjur
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [E1000-devel] [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH...
From: Alexander Duyck @ 2013-02-20 22:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: Allan, Bruce W, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, Brandeburg, Jesse, Daniel Santos,
Andrew Morton, Wu, Fengguang
In-Reply-To: <1361396560.19353.226.camel@edumazet-glaptop>
On 02/20/2013 01:42 PM, Eric Dumazet wrote:
> On Wed, 2013-02-20 at 13:23 -0800, Alexander Duyck wrote:
>
>> NET_SKB_PAD is defined for the s390. It is already 32. If you look it
>> up we only have 2 definitions for NET_SKB_PAD, one specific to the s390
>> architecture and the other one in skbuff.h.
>>
> Andrew traces disagree, as they were :
>
>>>> s390 allmodconfig:
>>>>
>>>> bool __cond = !(!(((2048) - (((sizeof(struct skb_shared_info)) + (256 - 1)) &
>>>> ~(256 - 1))) < (32 + 2 + 16 + 1514 + 4)));
>>>>
> So it might be only a cross-compile environment issue, I dont know.
Huh? I'm not seeing what you are saying. The NET_SKB_PAD is the value
that is in the last set of parenthesis since it was:
(NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH_FRAME_LEN + ETH_FCS_LEN)
that is the bit that became:
(32 + 2 + 16 + 1514 + 4)
The problem is the skb_shared_info bit rounds up to 512 reducing the
available space to 1536. If you add up all of the other bits ignoring
the NET_SKB_PAD value you end up with exactly 1536 meaning the only
value for NET_SKB_PAD that would work is 0.
>> From what I can tell we would have to drop the NET_SKB_PAD to 0 in order
>> to not trigger this error with igb since we still have to add 22 bytes
>> for igb's per packet timestamp header, IP alignment, and CRC.
>>
>> The simple fix is for us just to drop the BUILD_BUG_ON check for igb
>> since we already had a check for size check in igb_set_rx_buffer_len.
>> It just means that build_skb won't be available for standard MTU sizes
>> on s390.
> Yeah, probably nobody will notice ;)
Yeah, it is only a few percentage points difference and only really
impacts small packets anyway. :-)
Thanks,
Alex
^ permalink raw reply
* Re: Problems with VSOCK?
From: Paul Moore @ 2013-02-20 22:28 UTC (permalink / raw)
To: Andy King; +Cc: netdev
In-Reply-To: <1906719446.2930546.1361398782879.JavaMail.root@vmware.com>
On Wednesday, February 20, 2013 02:19:42 PM Andy King wrote:
> Hi Paul,
>
> > I'm currently looking at the VSOCK implementation in netdev-next to
> > determine what we need in the way of LSM hooks and I ran into a few
> > things which look rather odd:
> >
> > * net/vmw_sock/Kconfig
> >
> > VMWARE_VMCI_SOCKETS depends on VMWARE_VMCI which doesn't look to be
> > defined
> > anywhere, help? For what it is worth, removing the VMWARE_VMCI dependency
>
> Ah, I think this is the same problem someone else had a few days ago. VMCI
> came in via Greg's char-misc-next tree, and it hasn't merged into Dave's
> tree yet. But the top-level linux-next tree now has all required modules:
>
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary
>
> Sorry about them coming in from different trees :/
Okay, thanks, I'll grab a copy of the next tree and take a look. That makes
much more sense, I was finding it hard to believe that so much was missing :)
--
paul moore
security and virtualization @ redhat
^ 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