* Re: Bug: mv643xxx fails with highmem
From: Russell King - ARM Linux @ 2014-12-21 16:51 UTC (permalink / raw)
To: Ezequiel Garcia, David Miller
Cc: Nimrod Andy, Fabio Estevam, netdev, fugang.duan
In-Reply-To: <5492D2EF.6050807@free-electrons.com>
On Thu, Dec 18, 2014 at 10:13:19AM -0300, Ezequiel Garcia wrote:
> On 12/17/2014 09:03 PM, Russell King - ARM Linux wrote:
> > However, exactly how it occurs, I don't know. My understanding from
> > reading the various feature flags was that NETIF_F_HIGHDMA was required
> > for highmem (see illegal_highdma()) so as this isn't set, we shouldn't
> > be seeing highmem fragments - which is why I asked the question in my
> > original email.
> >
> > If you want me to revert my fix above, and reproduce again, I can
> > certainly try that - or put a WARN_ON_ONCE(PageHighMem(this_frag->page.p))
> > in there, but I seem to remember that it wasn't particularly useful as
> > the backtrace didn't show where the memory actually came from.
> >
>
> No, that's OK. Thanks a lot for all the details. I'll try to come up with a
> fix soon.
Well, I decided to add the WARN_ON_ONCE() and re-test. This I provoked
by touching etna_viv/src/etnaviv/etna_bo.c, and re-running make (etnaviv
is on a shared NFS mount.)
WARNING: CPU: 0 PID: 0 at /home/rmk/git/linux-cubox/drivers/net/ethernet/marvell/mv643xx_eth.c:884 mv643xx_eth_xmit+0x850/0x8dc()
Modules linked in: bnep rfcomm bluetooth nfsd exportfs ext3 jbd ext2 etnaviv(C)
snd_soc_spdif_tx orion_wdt snd_soc_kirkwood dove vmeta bmm_dmabuf hwmon snd_soc_kirkwood_spdif
CPU: 0 PID: 0 Comm: swapper Tainted: G C 3.18.0+ #1056
Backtrace:
[<c0011f54>] (dump_backtrace) from [<c0012228>] (show_stack+0x18/0x1c)
r6:00000374 r5:00000009 r4:00000000 r3:00000000
[<c0012210>] (show_stack) from [<c04992d8>] (dump_stack+0x20/0x28)
[<c04992b8>] (dump_stack) from [<c0050be4>] (warn_slowpath_common+0x6c/0x8c)
[<c0050b78>] (warn_slowpath_common) from [<c0050c28>] (warn_slowpath_null+0x24/0x2c)
r8:c064ea80 r7:e8a5d880 r6:d00d0d70 r5:e614877c r4:00000001
[<c0050c04>] (warn_slowpath_null) from [<c02fee9c>] (mv643xx_eth_xmit+0x850/0x8dc)
[<c02fe64c>] (mv643xx_eth_xmit) from [<c03b94fc>] (dev_hard_start_xmit+0x19c/0x328)
r10:c0648054 r9:d0261f60 r8:e6148000 r7:d00ec1c0 r6:c0648040 r5:e623ec00
r4:d013c580
[<c03b9360>] (dev_hard_start_xmit) from [<c03d2728>] (sch_direct_xmit+0x148/0x24c)
r10:e623ec00 r9:e63a4580 r8:e6148000 r7:e61f4e00 r6:c063e000 r5:00000000
r4:00000000
[<c03d25e0>] (sch_direct_xmit) from [<c03b985c>] (__dev_queue_xmit+0x1d4/0x590)
r10:e623ec00 r9:00000000 r8:00000000 r7:e6148000 r6:c063e000 r5:e61f4e00
r4:d0163e70
[<c03b9688>] (__dev_queue_xmit) from [<c03b9c40>] (dev_queue_xmit+0x14/0x18)
r10:c063e000 r9:00000000 r8:00000000 r7:d0163e70 r6:0000000e r5:d00caa00
r4:d00caa94
[<c03b9c2c>] (dev_queue_xmit) from [<c043c58c>] (ip6_finish_output2+0x1a0/0x524)[<c043c3ec>] (ip6_finish_output2) from [<c043e008>] (ip6_output+0xb4/0x174)
r10:d0163e70 r9:c063e000 r8:c066f678 r7:00000000 r6:d0163e70 r5:00000000
r4:000021c0
[<c043df54>] (ip6_output) from [<c043c114>] (ip6_xmit+0x278/0x550)
r7:00000000 r6:00000001 r5:00000000 r4:001463b6
[<c043be9c>] (ip6_xmit) from [<c0466fbc>] (inet6_csk_xmit+0x74/0xa8)
r10:d0163e70 r9:00000020 r8:d00d2080 r7:d00d25a0 r6:d0163e70 r5:00000000
r4:d00d2080
[<c0466f48>] (inet6_csk_xmit) from [<c03f87ac>] (tcp_transmit_skb+0x494/0x990)
r7:e6094100 r6:c0658910 r5:00000020 r4:ffff5165
[<c03f8318>] (tcp_transmit_skb) from [<c03f9970>] (tcp_write_xmit+0x138/0xc1c)
r10:00002178 r9:00000000 r8:00002ca0 r7:00000006 r6:00000594 r5:d0163dc0
r4:d00d2080
[<c03f9838>] (tcp_write_xmit) from [<c03fa4d4>] (__tcp_push_pending_frames+0x38/0x98)
r10:00000002 r9:00000078 r8:d03d7600 r7:d00d25a0 r6:d02841c0 r5:e448f778
r4:d00d2080
[<c03fa49c>] (__tcp_push_pending_frames) from [<c03f567c>] (tcp_rcv_established+0x15c/0x600)
r4:d00d2080
[<c03f5520>] (tcp_rcv_established) from [<c0461918>] (tcp_v6_do_rcv+0x2bc/0x46c) r10:00000002 r9:00000078 r8:d03d7600 r7:d00d25a0 r6:00000000 r5:d00d2080
r4:d02841c0
[<c046165c>] (tcp_v6_do_rcv) from [<c0462828>] (tcp_v6_rcv+0x7f8/0x810)
r8:00000000 r7:d00d2080 r6:c063e000 r5:c066f678 r4:d02841c0
[<c0462030>] (tcp_v6_rcv) from [<c043e750>] (ip6_input+0xec/0x424)
r10:c066f678 r9:c052a75c r8:d02841c0 r7:c0649720 r6:00000006 r5:e6168400
r4:00000006
[<c043e664>] (ip6_input) from [<c043e100>] (ip6_rcv_finish+0x38/0xa4)
r10:e6168400 r9:e6148000 r8:d02841c0 r7:00000001 r6:c066f678 r5:00000000
r4:d02841c0 r3:c043e664
[<c043e0c8>] (ip6_rcv_finish) from [<c043e494>] (ipv6_rcv+0x328/0x4f8)
r4:e448f750 r3:00000000
[<c043e16c>] (ipv6_rcv) from [<c03b43c0>] (__netif_receive_skb_core+0x2fc/0x5d0) r10:d02841c0 r9:c0649050 r8:c06480c4 r7:e6148000 r6:00000000 r5:0000dd86
r4:c043e16c
[<c03b40c4>] (__netif_receive_skb_core) from [<c03b6bac>] (__netif_receive_skb+0x2c/0x88)
r10:00000001 r9:d02841c0 r8:e61484e0 r7:e8a5b310 r6:2cc7fffe r5:00000003
r4:d02841c0
[<c03b6b80>] (__netif_receive_skb) from [<c03b6d30>] (netif_receive_skb_internal+0x2c/0x68)
r5:00000003 r4:d02841c0
[<c03b6d04>] (netif_receive_skb_internal) from [<c03b7690>] (napi_gro_receive+0x7c/0xa8)
r4:d02841c0
[<c03b7614>] (napi_gro_receive) from [<c0300738>] (mv643xx_eth_poll+0x58c/0x6ac) r5:e6148000 r4:e614864c
[<c03001ac>] (mv643xx_eth_poll) from [<c03b7370>] (net_rx_action+0xa4/0x1a8)
r10:c0658910 r9:c0675940 r8:c0675940 r7:0000012c r6:00000040 r5:e61485c0
r4:c03001ac
[<c03b72cc>] (net_rx_action) from [<c00533c0>] (__do_softirq+0xf0/0x214)
r10:00000003 r9:00000101 r8:c063e000 r7:00000003 r6:c0677480 r5:c067748c
r4:00000000
[<c00532d0>] (__do_softirq) from [<c005377c>] (irq_exit+0xac/0xfc)
r10:e6ffcd40 r9:560f5815 r8:00000000 r7:0000001e r6:00000000 r5:00000000
r4:c063e000
[<c00536d0>] (irq_exit) from [<c0085330>] (__handle_domain_irq+0x7c/0xc0)
r4:c065ef68 r3:00010001
[<c00852b4>] (__handle_domain_irq) from [<c000fb0c>] (handle_IRQ+0x24/0x28)
r8:00000001 r7:c063ff74 r6:ffffffff r5:600f0013 r4:c0077408 r3:c063ff40
[<c000fae8>] (handle_IRQ) from [<c0008600>] (dove_legacy_handle_irq+0x34/0x5c)
[<c00085cc>] (dove_legacy_handle_irq) from [<c0012ce0>] (__irq_svc+0x40/0x74)
Exception stack(0xc063ff40 to 0xc063ff88)
ff40: 00000000 0001114c c0658324 c001d940 c063e000 c06470c8 c06759fe c06759fe
ff60: 00000001 560f5815 e6ffcd40 c063ff9c c063ff88 c063ff88 c000fc38 c0077408
ff80: 600f0013 ffffffff
[<c0077354>] (cpu_startup_entry) from [<c04952c4>] (rest_init+0x78/0x90)
r7:ffffffff r3:c04b0554
[<c049524c>] (rest_init) from [<c0609ca8>] (start_kernel+0x34c/0x3b0)
r4:c06479b0 r3:00000001
[<c060995c>] (start_kernel) from [<00008070>] (0x8070)
Obviously, the useful bit is only down to just above
__tcp_push_pending_frames(), since that's traces back to the TCP socket's
send queue.
If I had to guess where the highmem pages were coming from, I'd suggest
that it was via the page cache and NFS - maybe something like GCC opens
a new NFS file, writes to it. Pages are allocated to it, which happen
to be allocated from highmem. NFS eventually sends these pages to the
NFS server via TCP, which fragments the page and leaves pointers to the
highmem page in the TCP skbuff. My NFS mounts are IPv6.
For Freescale iMX6 FEC, I haven't yet been able to reproduce this there.
The FEC has tx-checksum-ipv6 and rx-vlan-offload enabled, which the
mv643xxx driver doesn't have. The FEC platform has twice the memory of
the Dove platform (so has much more highmem) so I would've thought it
would have been easier to reproduce there. Slightly different kernels
too - Dove runs 3.18 plus additions, iMX6 is running Linus' tip from
two days ago plus very similar additions (but same GPU and X server
code.)
Other stuff... Dove memory is 0 - 0x3fffffff. mv643xxx DMA mask
uninitialised (coherent DMA mask set to 0xffffffff).
iMX6 is 0x10000000 - 0x8fffffff, with the DMA mask defaulting to
point at the coherent mask (due to being DT based) which is
0xffffffff.
Here's the diff of the ethtool -k output:
--- eth0.dove 2014-12-21 16:38:39.000000000 +0000
+++ eth0.imx6 2014-12-21 16:38:50.792453703 +0000
@@ -3,7 +3,7 @@
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
- tx-checksum-ipv6: off [fixed]
+ tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
@@ -17,7 +17,7 @@
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
-rx-vlan-offload: off [fixed]
+rx-vlan-offload: on
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
@@ -32,7 +32,6 @@
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
-tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
Hmm. I'm now wondering about this:
static netdev_features_t harmonize_features(struct sk_buff *skb,
netdev_features_t features)
{
...
if (skb->ip_summed != CHECKSUM_NONE &&
!can_checksum_protocol(features, type)) {
features &= ~NETIF_F_ALL_CSUM;
} else if (illegal_highdma(skb->dev, skb)) {
features &= ~NETIF_F_SG;
}
For Dove, can_checksum_protocol() would return false for IPv6, which
would allow the first "if" statement to succeed, hence clearing
NETIF_F_ALL_CSUM.
This would prevent the second if() being evaluated - which seems to
remove the check for any fragments in highmem. David - shouldn't these
two checks be independent?
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: SRIOV as bridge Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Shrijeet Mukherjee @ 2014-12-21 16:33 UTC (permalink / raw)
To: jhs; +Cc: John Fastabend, Hubert Sokolowski, roopa, netdev, Vlad Yasevich
In-Reply-To: <443500166.23675449.1419179623398.JavaMail.zimbra@cumulusnetworks.com>
----- Original Message -----
> From: "jhs" <jhs@mojatatu.com>
> To: "John Fastabend" <john.fastabend@gmail.com>
> Cc: "Hubert Sokolowski" <h.sokolowski@wit.edu.pl>, "roopa" <roopa@cumulusnetworks.com>, netdev@vger.kernel.org, "Vlad
> Yasevich" <vyasevic@redhat.com>, "Shrijeet Mukherjee" <shm@cumulusnetworks.com>
> Sent: Sunday, December 21, 2014 6:27:46 AM
> Subject: SRIOV as bridge Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
> Sorry for the latency, Ive been down with a bad flu (its bad when i cant
> type on my keyboard sitting infront of me;->), recovering and the
> thread seems to have caught on - should be able to catchup in the
> next few days.
> I am beginning to reach a conclusion that the current switchdev approach
> is *not* going to work for SRIOV. I also worry it may be too late
> to change that.
> Shrijeet wanted to set up a BOF for netdev to have hopefully final
> consensus. Shrijeet, are you going to make an official request for the BOF?
Yes, will write something up tonite. The point you make about the PF being the TheClassThingy is what make the merging of models possible IMO.
>
> Sorry John, I dont have enough energy to address all your points but i
> will try to just focus on SRIOV and will save a few bytes while at it.
>
>
> On 12/16/14 11:35, John Fastabend wrote:
>
>> But in the SR-IOV case you have multiple "Cpu ports" and you want
>> to send packets to each of them depending on the configuration.
>>
>>
>> port0 port1 port2 port3
>> | | | | uplinks
>> +------------------------------+
>> | |
>> | SRIOV edge relay |
>> | |
>> +------------------------------+
>> | downlink
>>
>>
>
> Two points above:
> 1) Did you flip uplink vs down link above?
> (I Thought URP was the wire link)
> 2) What you are not showing above which is *very important* is that
> infact there is an underlying embedded fdb.
>
> point #2 brings out a lot of the weird things in some of the bridge
> code. IOW, you have an *offloaded* bridge with _bridge ports_
> visible in the kernel but not the bridge that is controlled
> by standard Linux bridge tools. I am not saying that the model is
> wrong; on the contrary what Ben had exposed may fall under the
> same category i.e you have E_BRIDGE flag on the netdev to say it sits
> on top of an offloaded bridge and you dont need a br0 to run
> bridge command on. But then we need some proxy (TheClassThingy) to act
> as intemediary to the offloaded hardware.
> If you do that then the vf becomes simply a bridge port - which
> means bridge port ops apply.
>
> SRIOV it seems to have morphed its own toolkit.
> The PF port, when acting as the control interface, is actually
> TheClassThingy we discuss on/off.
> To add an fdb entry to point to vf 1, where TheClassThingy is eth1:
> ip link set eth1 vf 1 mac aa:bb:cc:dd:ee:ff vlan 10
>
> IMO, SRIOV should expose these ports with names and ifindices
> (probably does already) and pre-populated master or something
> which points to its parent, then i can do the following:
> bridge fdb add aa:bb:cc:dd:ee:ff vlan 10 dev vf1 master
>
> master in such a case will go to TheClassThingy which would pass
> such control to the underlying hardware.
> The PF still stays but not as the management interface.
>
> Ok, promised to keep this short ;-> I should respond to the other points
> in a separate email.
>
> cheers,
> jamal
^ permalink raw reply
* [PATCH v2] e1000: Add netif_napi_del in the normal path and error path to match netif_napi_add
From: Jia-Ju Bai @ 2014-12-21 15:15 UTC (permalink / raw)
To: sergei.shtylyov, davem, netdev; +Cc: todd.fujinaka, linux.nics, Jia-Ju Bai
The driver lacks netif_napi_del in the normal path and error path to match the call of netif_napi_add in e1000_probe.
This patch fixes this problem, and it has been tested in runtime.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 24f3986..f6def7b 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1004,7 +1004,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
/* make ready for any if (hw->...) below */
err = e1000_init_hw_struct(adapter, hw);
if (err)
- goto err_sw_init;
+ goto err_dma;
/* there is a workaround being applied below that limits
* 64-bit DMA addresses to 64-bit hardware. There are some
@@ -1239,8 +1239,9 @@ err_eeprom:
iounmap(hw->flash_address);
kfree(adapter->tx_ring);
kfree(adapter->rx_ring);
-err_dma:
err_sw_init:
+ netif_napi_del(&adapter->napi);
+err_dma:
err_mdio_ioremap:
iounmap(hw->ce4100_gbe_mdio_base_virt);
iounmap(hw->hw_addr);
@@ -1271,6 +1272,7 @@ static void e1000_remove(struct pci_dev *pdev)
e1000_down_and_stop(adapter);
e1000_release_manageability(adapter);
+ netif_napi_del(&adapter->napi);
unregister_netdev(netdev);
e1000_phy_hw_reset(hw);
--
1.7.9.5
^ permalink raw reply related
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-12-21 15:03 UTC (permalink / raw)
To: Maximilian Engelhardt
Cc: Michael Tokarev, Rafał Miłecki, Seth Forshee,
brcm80211 development, linux-wireless@vger.kernel.org,
Network Development
In-Reply-To: <9234001.YBqfvtcJFx@fuchs>
On 12/21/14 15:24, Maximilian Engelhardt wrote:
> On Sunday 21 December 2014 15:13:50 Arend van Spriel wrote:
>> On 12/21/14 15:08, Maximilian Engelhardt wrote:
>>> On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote:
>>>> On 12/21/14 10:58, Michael Tokarev wrote:
>>>>> 16.12.2014 19:51, Arend van Spriel wrote:
>>>>>> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please
>>>>>> remove that call as it causes endless recursion and eventually reboot.>
>>>>>
>>>>> Ok, that was easy. Now it loads, but wifi link still
>>>>> does not work, stalling as before. What we're looking
>>>>> at now?
>>>>
>>>> The patch is just to provide me with extra bt-coex related information
>>>> in the kernel log. So if you can provide that to me I have to info
>>>> needed to look in the proprietary code base to determine what is missing.
>>>>
>>>> Regards,
>>>> Arend
>>>
>>> Hi Arend,
>>
>>> here is the output from my card:
>> Thanks. It shows you have have the same bt-coex version as Michael. I am
>> not familiar with bluetooth side of things. Are you both using bluetooth
>> on 4313?
>>
>> Regards,
>> Arend
>
> I don't know. I think I have Bluetooth somehow enabled but I'm not really
> using it. I definitely don't have any Bluetooth devices connected. I could try
> to unload/disable Bluetooth it to see if it makes any difference.
That would be useful to know.
Thanks,
Arend
> Greetings,
> Maxi
>
^ permalink raw reply
* SRIOV fdb and modes WAS(Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Jamal Hadi Salim @ 2014-12-21 14:46 UTC (permalink / raw)
To: John Fastabend
Cc: Hubert Sokolowski, Roopa Prabhu, netdev@vger.kernel.org,
Vlad Yasevich
In-Reply-To: <54905F67.2090509@gmail.com>
John,
On CPU port: Yes, a VF with PCIE params is considered a "CPU port".
This is fine for SRIOV because it ties VF to a "CPU port". Other
ASIC models have an explicit single "CPU port" (I would say the tiny
openwrt types or larger broadcom switches). In such a case you program
separately the cpu MAC addresses and then you teach some table to
send to the CPU port. It doesnt matter whether it is L2 or L3. As
an example you can point a L3 NH to cpu port with a CPU port MAC address
so things dont show up as skb HOST tagged on the stack.
On Linux infact without the concept of an fdb - this is also true.
i.e not all NICs have an fdb. Macvlan was initially introduced (Patrick
McHardy iirc) to expose the multiple MAC address a standard NIC has.
Conflating this with having an fdb is where the water got mudied in my
opinion. I should be able to dump these MAC addresses without expecting
that i need to talk to an underlying hardware dumper (hence the default
dumper). Unless it is true today that _all_ NICs with multiple MACs have
an embedded fdb.
To summarize: I dont think we disagree much - i just wanted to emphasize
the concept of "cpu port" being important.
Other thing you brought up was the concept of uplink/downlink relay
ports. The more i think about it, the more i am reaching a conclusion
that they are *not* anything speacial.
Essentially, in one case you have the port column pointing to the VF
after you populate the underlying fdb. By default it doesnt seem these
SRIOV switches cant learn. We have knobs for that and capability is
exposable to point to the fact
And it seems to me that VEPA is just a mode where flooding control
points out one port connected externally.
We already have knobs per port flood and learning controls.
cheers,
jamal
^ permalink raw reply
* SRIOV as bridge Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Jamal Hadi Salim @ 2014-12-21 14:27 UTC (permalink / raw)
To: John Fastabend
Cc: Hubert Sokolowski, Roopa Prabhu, netdev@vger.kernel.org,
Vlad Yasevich, Shrijeet Mukherjee
In-Reply-To: <54905F67.2090509@gmail.com>
Sorry for the latency, Ive been down with a bad flu (its bad when i cant
type on my keyboard sitting infront of me;->), recovering and the
thread seems to have caught on - should be able to catchup in the
next few days.
I am beginning to reach a conclusion that the current switchdev approach
is *not* going to work for SRIOV. I also worry it may be too late
to change that.
Shrijeet wanted to set up a BOF for netdev to have hopefully final
consensus. Shrijeet, are you going to make an official request for the BOF?
Sorry John, I dont have enough energy to address all your points but i
will try to just focus on SRIOV and will save a few bytes while at it.
On 12/16/14 11:35, John Fastabend wrote:
> But in the SR-IOV case you have multiple "Cpu ports" and you want
> to send packets to each of them depending on the configuration.
>
>
> port0 port1 port2 port3
> | | | | uplinks
> +------------------------------+
> | |
> | SRIOV edge relay |
> | |
> +------------------------------+
> | downlink
>
>
Two points above:
1) Did you flip uplink vs down link above?
(I Thought URP was the wire link)
2) What you are not showing above which is *very important* is that
infact there is an underlying embedded fdb.
point #2 brings out a lot of the weird things in some of the bridge
code. IOW, you have an *offloaded* bridge with _bridge ports_
visible in the kernel but not the bridge that is controlled
by standard Linux bridge tools. I am not saying that the model is
wrong; on the contrary what Ben had exposed may fall under the
same category i.e you have E_BRIDGE flag on the netdev to say it sits
on top of an offloaded bridge and you dont need a br0 to run
bridge command on. But then we need some proxy (TheClassThingy) to act
as intemediary to the offloaded hardware.
If you do that then the vf becomes simply a bridge port - which
means bridge port ops apply.
SRIOV it seems to have morphed its own toolkit.
The PF port, when acting as the control interface, is actually
TheClassThingy we discuss on/off.
To add an fdb entry to point to vf 1, where TheClassThingy is eth1:
ip link set eth1 vf 1 mac aa:bb:cc:dd:ee:ff vlan 10
IMO, SRIOV should expose these ports with names and ifindices
(probably does already) and pre-populated master or something
which points to its parent, then i can do the following:
bridge fdb add aa:bb:cc:dd:ee:ff vlan 10 dev vf1 master
master in such a case will go to TheClassThingy which would pass
such control to the underlying hardware.
The PF still stays but not as the management interface.
Ok, promised to keep this short ;-> I should respond to the other points
in a separate email.
cheers,
jamal
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Maximilian Engelhardt @ 2014-12-21 14:24 UTC (permalink / raw)
To: Arend van Spriel
Cc: Michael Tokarev, Rafał Miłecki, Seth Forshee,
brcm80211 development, linux-wireless@vger.kernel.org,
Network Development
In-Reply-To: <5496D59E.5030601@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]
On Sunday 21 December 2014 15:13:50 Arend van Spriel wrote:
> On 12/21/14 15:08, Maximilian Engelhardt wrote:
> > On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote:
> >> On 12/21/14 10:58, Michael Tokarev wrote:
> >>> 16.12.2014 19:51, Arend van Spriel wrote:
> >>>> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please
> >>>> remove that call as it causes endless recursion and eventually reboot.>
> >>>
> >>> Ok, that was easy. Now it loads, but wifi link still
> >>> does not work, stalling as before. What we're looking
> >>> at now?
> >>
> >> The patch is just to provide me with extra bt-coex related information
> >> in the kernel log. So if you can provide that to me I have to info
> >> needed to look in the proprietary code base to determine what is missing.
> >>
> >> Regards,
> >> Arend
> >
> > Hi Arend,
>
> > here is the output from my card:
> Thanks. It shows you have have the same bt-coex version as Michael. I am
> not familiar with bluetooth side of things. Are you both using bluetooth
> on 4313?
>
> Regards,
> Arend
I don't know. I think I have Bluetooth somehow enabled but I'm not really
using it. I definitely don't have any Bluetooth devices connected. I could try
to unload/disable Bluetooth it to see if it makes any difference.
Greetings,
Maxi
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-12-21 14:13 UTC (permalink / raw)
To: Maximilian Engelhardt
Cc: Michael Tokarev, Rafał Miłecki, Seth Forshee,
brcm80211 development, linux-wireless@vger.kernel.org,
Network Development
In-Reply-To: <141935691.MGh8oJCUVD@fuchs>
On 12/21/14 15:08, Maximilian Engelhardt wrote:
> On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote:
>> On 12/21/14 10:58, Michael Tokarev wrote:
>>> 16.12.2014 19:51, Arend van Spriel wrote:
>>>> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please
>>>> remove that call as it causes endless recursion and eventually reboot.>
>>> Ok, that was easy. Now it loads, but wifi link still
>>> does not work, stalling as before. What we're looking
>>> at now?
>>
>> The patch is just to provide me with extra bt-coex related information
>> in the kernel log. So if you can provide that to me I have to info
>> needed to look in the proprietary code base to determine what is missing.
>>
>> Regards,
>> Arend
>
> Hi Arend,
>
> here is the output from my card:
Thanks. It shows you have have the same bt-coex version as Michael. I am
not familiar with bluetooth side of things. Are you both using bluetooth
on 4313?
Regards,
Arend
> [ 5167.720041] cfg80211: Calling CRDA to update world regulatory domain
> [ 5167.737243] bcma: bus0: Found chip with id 0x4313, rev 0x01 and package 0x08
> [ 5167.737271] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x24, class 0x0)
> [ 5167.737290] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x18, class 0x0)
> [ 5167.737324] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x11, class 0x0)
> [ 5167.737407] bcma: bus0: Found rev 8 PMU (capabilities 0x084C3008)
> [ 5167.737417] bcma: bus0: SPROM offset 0x830
> [ 5167.739392] bcma: bcmasprom:
> [ 5167.739396] bcma:
>
> [ 5167.739400] bcma: 2801
> [ 5167.739402] bcma: 0000
> [ 5167.739404] bcma: 0608
> [ 5167.739405] bcma: 14E4
> [ 5167.739408] bcma: 0070
> [ 5167.739409] bcma: EDBE
> [ 5167.739411] bcma: 0000
> [ 5167.739412] bcma: 2BC4
> [ 5167.739414] bcma: 2A64
> [ 5167.739416] bcma: 2964
> [ 5167.739417] bcma:
>
> [ 5167.739419] bcma: 2C64
> [ 5167.739421] bcma: 3CE7
> [ 5167.739422] bcma: 46FF
> [ 5167.739424] bcma: 47FF
> [ 5167.739425] bcma: 0C00
> [ 5167.739427] bcma: 0820
> [ 5167.739429] bcma: 0030
> [ 5167.739430] bcma: 1002
> [ 5167.739432] bcma: 9F28
> [ 5167.739434] bcma: 5D44
> [ 5167.739435] bcma:
>
> [ 5167.739438] bcma: 8080
> [ 5167.739439] bcma: 1D8F
> [ 5167.739441] bcma: 0032
> [ 5167.739442] bcma: 0100
> [ 5167.739444] bcma: DF00
> [ 5167.739445] bcma: 71F5
> [ 5167.739447] bcma: 8400
> [ 5167.739448] bcma: 0083
> [ 5167.739450] bcma: 8500
> [ 5167.739452] bcma: 2010
> [ 5167.739453] bcma:
>
> [ 5167.739455] bcma: 0001
> [ 5167.739457] bcma: 0000
> [ 5167.739458] bcma: 0000
> [ 5167.739460] bcma: 0000
> [ 5167.739461] bcma: 0000
> [ 5167.739463] bcma: 0000
> [ 5167.739464] bcma: 0000
> [ 5167.739466] bcma: 0000
> [ 5167.739467] bcma: 0000
> [ 5167.739469] bcma: 0000
> [ 5167.739470] bcma:
>
> [ 5167.739473] bcma: 0000
> [ 5167.739474] bcma: 0000
> [ 5167.739476] bcma: 1008
> [ 5167.739477] bcma: 0305
> [ 5167.739479] bcma: 0000
> [ 5167.739480] bcma: 0000
> [ 5167.739482] bcma: 0000
> [ 5167.739484] bcma: 0000
> [ 5167.739485] bcma: 4727
> [ 5167.739487] bcma: 8000
> [ 5167.739488] bcma:
>
> [ 5167.739490] bcma: 0002
> [ 5167.739492] bcma: 0000
> [ 5167.739493] bcma: 1F30
> [ 5167.739495] bcma: 1800
> [ 5167.739496] bcma: 0000
> [ 5167.739498] bcma: 0000
> [ 5167.739499] bcma: 0000
> [ 5167.739501] bcma: 0000
> [ 5167.739502] bcma: 0000
> [ 5167.739504] bcma: 0000
> [ 5167.739505] bcma:
>
> [ 5167.739508] bcma: 0000
> [ 5167.739509] bcma: 0000
> [ 5167.739511] bcma: 0000
> [ 5167.739512] bcma: 0000
> [ 5167.739514] bcma: 5372
> [ 5167.739515] bcma: 1109
> [ 5167.739517] bcma: 2201
> [ 5167.739519] bcma: 0040
> [ 5167.739520] bcma: 0884
> [ 5167.739522] bcma: 0000
> [ 5167.739523] bcma:
>
> [ 5167.739525] bcma: C014
> [ 5167.739526] bcma: 3DC1
> [ 5167.739528] bcma: 809D
> [ 5167.739530] bcma: 5856
> [ 5167.739531] bcma: 0001
> [ 5167.739533] bcma: FFFF
> [ 5167.739534] bcma: 83FF
> [ 5167.739536] bcma: FFFF
> [ 5167.739537] bcma: 0003
> [ 5167.739539] bcma: 0202
> [ 5167.739540] bcma:
>
> [ 5167.739543] bcma: FFFF
> [ 5167.739544] bcma: 0011
> [ 5167.739546] bcma: 017A
> [ 5167.739547] bcma: 0000
> [ 5167.739549] bcma: 0000
> [ 5167.739550] bcma: 0000
> [ 5167.739552] bcma: 0000
> [ 5167.739553] bcma: 0201
> [ 5167.739555] bcma: 0000
> [ 5167.739556] bcma: 7800
> [ 5167.739558] bcma:
>
> [ 5167.739559] bcma: 01FF
> [ 5167.739561] bcma: E398
> [ 5167.739563] bcma: 0008
> [ 5167.739564] bcma: 0000
> [ 5167.739566] bcma: 0000
> [ 5167.739568] bcma: 0000
> [ 5167.739569] bcma: 0044
> [ 5167.739571] bcma: 2400
> [ 5167.739572] bcma: FCF7
> [ 5167.739574] bcma: 0089
> [ 5167.739575] bcma:
>
> [ 5167.739578] bcma: 0000
> [ 5167.739579] bcma: 0000
> [ 5167.739581] bcma: 0000
> [ 5167.739582] bcma: 0000
> [ 5167.739584] bcma: 0000
> [ 5167.739585] bcma: 0000
> [ 5167.739587] bcma: 0000
> [ 5167.739588] bcma: 0000
> [ 5167.739590] bcma: 0000
> [ 5167.739591] bcma: 0000
> [ 5167.739593] bcma:
>
> [ 5167.739594] bcma: 0000
> [ 5167.739596] bcma: 0000
> [ 5167.739597] bcma: 0048
> [ 5167.739599] bcma: FED2
> [ 5167.739600] bcma: 15D9
> [ 5167.739602] bcma: FAC6
> [ 5167.739604] bcma: 0000
> [ 5167.739605] bcma: 0000
> [ 5167.739607] bcma: 0000
> [ 5167.739608] bcma: 0000
> [ 5167.739610] bcma:
>
> [ 5167.739612] bcma: 0000
> [ 5167.739614] bcma: 0000
> [ 5167.739615] bcma: 0000
> [ 5167.739617] bcma: 0000
> [ 5167.739618] bcma: 0000
> [ 5167.739620] bcma: 0000
> [ 5167.739622] bcma: 0000
> [ 5167.739623] bcma: 0000
> [ 5167.739625] bcma: 0000
> [ 5167.739626] bcma: 0000
> [ 5167.739627] bcma:
>
> [ 5167.739629] bcma: 0000
> [ 5167.739631] bcma: 0000
> [ 5167.739632] bcma: 0000
> [ 5167.739634] bcma: 0000
> [ 5167.739635] bcma: 0000
> [ 5167.739637] bcma: 0000
> [ 5167.739638] bcma: 0000
> [ 5167.739640] bcma: 0000
> [ 5167.739641] bcma: 0000
> [ 5167.739643] bcma: 0000
> [ 5167.739644] bcma:
>
> [ 5167.739647] bcma: 0000
> [ 5167.739648] bcma: 0000
> [ 5167.739650] bcma: 0000
> [ 5167.739651] bcma: 0000
> [ 5167.739653] bcma: 0000
> [ 5167.739654] bcma: 0000
> [ 5167.739656] bcma: 0000
> [ 5167.739657] bcma: 0000
> [ 5167.739659] bcma: 0000
> [ 5167.739660] bcma: 0000
> [ 5167.739662] bcma:
>
> [ 5167.739663] bcma: 0000
> [ 5167.739665] bcma: 0000
> [ 5167.739666] bcma: 0000
> [ 5167.739668] bcma: 0000
> [ 5167.739669] bcma: 0000
> [ 5167.739671] bcma: 0000
> [ 5167.739672] bcma: 0000
> [ 5167.739674] bcma: 0000
> [ 5167.739676] bcma: 0000
> [ 5167.739677] bcma: 0000
> [ 5167.739679] bcma:
>
> [ 5167.739681] bcma: 0000
> [ 5167.739682] bcma: 1111
> [ 5167.739684] bcma: 1111
> [ 5167.739686] bcma: 0000
> [ 5167.739687] bcma: 0000
> [ 5167.739689] bcma: 0000
> [ 5167.739690] bcma: 0000
> [ 5167.739692] bcma: 0000
> [ 5167.739693] bcma: 0000
> [ 5167.739695] bcma: 2222
> [ 5167.739696] bcma:
>
> [ 5167.739698] bcma: 3222
> [ 5167.739700] bcma: 0000
> [ 5167.739701] bcma: 0000
> [ 5167.739703] bcma: 0000
> [ 5167.739704] bcma: 0000
> [ 5167.739706] bcma: 0000
> [ 5167.739707] bcma: 0000
> [ 5167.739709] bcma: 0000
> [ 5167.739710] bcma: 0000
> [ 5167.739712] bcma: 0000
> [ 5167.739713] bcma:
>
> [ 5167.739716] bcma: 0000
> [ 5167.739717] bcma: 0000
> [ 5167.739719] bcma: 0000
> [ 5167.739720] bcma: 0000
> [ 5167.739722] bcma: 0000
> [ 5167.739723] bcma: 0000
> [ 5167.739725] bcma: 0000
> [ 5167.739726] bcma: 0000
> [ 5167.739728] bcma: 0000
> [ 5167.739729] bcma: 0000
> [ 5167.739731] bcma:
>
> [ 5167.739732] bcma: 0000
> [ 5167.739734] bcma: 0000
> [ 5167.739735] bcma: 0000
> [ 5167.739737] bcma: 0000
> [ 5167.739738] bcma: 0000
> [ 5167.739740] bcma: 0000
> [ 5167.739741] bcma: 0000
> [ 5167.739743] bcma: 0000
> [ 5167.739744] bcma: 0000
> [ 5167.739746] bcma: 0000
> [ 5167.739748] bcma:
>
> [ 5167.739750] bcma: 0000
> [ 5167.739751] bcma: 0000
> [ 5167.739753] bcma: 0000
> [ 5167.739755] bcma: 0000
> [ 5167.739756] bcma: 0000
> [ 5167.739758] bcma: 0000
> [ 5167.739759] bcma: 0000
> [ 5167.739761] bcma: 0000
> [ 5167.739762] bcma: 0000
> [ 5167.739764] bcma: 0000
> [ 5167.739765] bcma:
>
> [ 5167.739767] bcma: 0000
> [ 5167.739768] bcma: 0000
> [ 5167.739770] bcma: 0000
> [ 5167.739772] bcma: 0000
> [ 5167.739773] bcma: 0000
> [ 5167.739775] bcma: 0000
> [ 5167.739776] bcma: 0000
> [ 5167.739778] bcma: 0000
> [ 5167.739779] bcma: 0000
> [ 5167.739782] bcma: bus0: Found SPROM revision 8
> [ 5167.752730] bcma: bus0: GPIO driver not activated
> [ 5167.752738] bcma: bus0: Bus registered
> [ 5167.765209] brcmsmac bcma0:0: mfg 4bf core 812 rev 24 class 0 irq 17
> [ 5167.765319] bcma: bus0: Switched to core: 0x812
> [ 5167.766135] brcmsmac bcma0:0: hardware: SECI
> [ 5167.766559] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [ 5167.786115] cfg80211: World regulatory domain updated:
> [ 5167.786128] cfg80211: DFS Master region: unset
> [ 5167.786131] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
> [ 5167.786137] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> [ 5167.786141] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> [ 5167.786144] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
> [ 5167.786148] cfg80211: (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
> [ 5167.786152] cfg80211: (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
> [ 5167.786155] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
> [ 5167.786159] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
> [ 5167.786162] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
> [ 5167.794806] cfg80211: Calling CRDA for country: DE
> [ 5167.810110] cfg80211: Regulatory domain changed to country: DE
> [ 5167.810122] cfg80211: DFS Master region: ETSI
> [ 5167.810125] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
> [ 5167.810131] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> [ 5167.810134] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
> [ 5167.810139] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz), (N/A, 2000 mBm), (0 s)
> [ 5167.810142] cfg80211: (5470000 KHz - 5725000 KHz @ 80000 KHz), (N/A, 2698 mBm), (0 s)
> [ 5167.810146] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
>
>
> Greetings,
> Maxi
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Maximilian Engelhardt @ 2014-12-21 14:08 UTC (permalink / raw)
To: Arend van Spriel
Cc: Michael Tokarev, Rafał Miłecki, Seth Forshee,
brcm80211 development,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development
In-Reply-To: <54969D18.3060000-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 9845 bytes --]
On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote:
> On 12/21/14 10:58, Michael Tokarev wrote:
> > 16.12.2014 19:51, Arend van Spriel wrote:
> >> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please
> >> remove that call as it causes endless recursion and eventually reboot.>
> > Ok, that was easy. Now it loads, but wifi link still
> > does not work, stalling as before. What we're looking
> > at now?
>
> The patch is just to provide me with extra bt-coex related information
> in the kernel log. So if you can provide that to me I have to info
> needed to look in the proprietary code base to determine what is missing.
>
> Regards,
> Arend
Hi Arend,
here is the output from my card:
[ 5167.720041] cfg80211: Calling CRDA to update world regulatory domain
[ 5167.737243] bcma: bus0: Found chip with id 0x4313, rev 0x01 and package 0x08
[ 5167.737271] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x24, class 0x0)
[ 5167.737290] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x18, class 0x0)
[ 5167.737324] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x11, class 0x0)
[ 5167.737407] bcma: bus0: Found rev 8 PMU (capabilities 0x084C3008)
[ 5167.737417] bcma: bus0: SPROM offset 0x830
[ 5167.739392] bcma: bcmasprom:
[ 5167.739396] bcma:
[ 5167.739400] bcma: 2801
[ 5167.739402] bcma: 0000
[ 5167.739404] bcma: 0608
[ 5167.739405] bcma: 14E4
[ 5167.739408] bcma: 0070
[ 5167.739409] bcma: EDBE
[ 5167.739411] bcma: 0000
[ 5167.739412] bcma: 2BC4
[ 5167.739414] bcma: 2A64
[ 5167.739416] bcma: 2964
[ 5167.739417] bcma:
[ 5167.739419] bcma: 2C64
[ 5167.739421] bcma: 3CE7
[ 5167.739422] bcma: 46FF
[ 5167.739424] bcma: 47FF
[ 5167.739425] bcma: 0C00
[ 5167.739427] bcma: 0820
[ 5167.739429] bcma: 0030
[ 5167.739430] bcma: 1002
[ 5167.739432] bcma: 9F28
[ 5167.739434] bcma: 5D44
[ 5167.739435] bcma:
[ 5167.739438] bcma: 8080
[ 5167.739439] bcma: 1D8F
[ 5167.739441] bcma: 0032
[ 5167.739442] bcma: 0100
[ 5167.739444] bcma: DF00
[ 5167.739445] bcma: 71F5
[ 5167.739447] bcma: 8400
[ 5167.739448] bcma: 0083
[ 5167.739450] bcma: 8500
[ 5167.739452] bcma: 2010
[ 5167.739453] bcma:
[ 5167.739455] bcma: 0001
[ 5167.739457] bcma: 0000
[ 5167.739458] bcma: 0000
[ 5167.739460] bcma: 0000
[ 5167.739461] bcma: 0000
[ 5167.739463] bcma: 0000
[ 5167.739464] bcma: 0000
[ 5167.739466] bcma: 0000
[ 5167.739467] bcma: 0000
[ 5167.739469] bcma: 0000
[ 5167.739470] bcma:
[ 5167.739473] bcma: 0000
[ 5167.739474] bcma: 0000
[ 5167.739476] bcma: 1008
[ 5167.739477] bcma: 0305
[ 5167.739479] bcma: 0000
[ 5167.739480] bcma: 0000
[ 5167.739482] bcma: 0000
[ 5167.739484] bcma: 0000
[ 5167.739485] bcma: 4727
[ 5167.739487] bcma: 8000
[ 5167.739488] bcma:
[ 5167.739490] bcma: 0002
[ 5167.739492] bcma: 0000
[ 5167.739493] bcma: 1F30
[ 5167.739495] bcma: 1800
[ 5167.739496] bcma: 0000
[ 5167.739498] bcma: 0000
[ 5167.739499] bcma: 0000
[ 5167.739501] bcma: 0000
[ 5167.739502] bcma: 0000
[ 5167.739504] bcma: 0000
[ 5167.739505] bcma:
[ 5167.739508] bcma: 0000
[ 5167.739509] bcma: 0000
[ 5167.739511] bcma: 0000
[ 5167.739512] bcma: 0000
[ 5167.739514] bcma: 5372
[ 5167.739515] bcma: 1109
[ 5167.739517] bcma: 2201
[ 5167.739519] bcma: 0040
[ 5167.739520] bcma: 0884
[ 5167.739522] bcma: 0000
[ 5167.739523] bcma:
[ 5167.739525] bcma: C014
[ 5167.739526] bcma: 3DC1
[ 5167.739528] bcma: 809D
[ 5167.739530] bcma: 5856
[ 5167.739531] bcma: 0001
[ 5167.739533] bcma: FFFF
[ 5167.739534] bcma: 83FF
[ 5167.739536] bcma: FFFF
[ 5167.739537] bcma: 0003
[ 5167.739539] bcma: 0202
[ 5167.739540] bcma:
[ 5167.739543] bcma: FFFF
[ 5167.739544] bcma: 0011
[ 5167.739546] bcma: 017A
[ 5167.739547] bcma: 0000
[ 5167.739549] bcma: 0000
[ 5167.739550] bcma: 0000
[ 5167.739552] bcma: 0000
[ 5167.739553] bcma: 0201
[ 5167.739555] bcma: 0000
[ 5167.739556] bcma: 7800
[ 5167.739558] bcma:
[ 5167.739559] bcma: 01FF
[ 5167.739561] bcma: E398
[ 5167.739563] bcma: 0008
[ 5167.739564] bcma: 0000
[ 5167.739566] bcma: 0000
[ 5167.739568] bcma: 0000
[ 5167.739569] bcma: 0044
[ 5167.739571] bcma: 2400
[ 5167.739572] bcma: FCF7
[ 5167.739574] bcma: 0089
[ 5167.739575] bcma:
[ 5167.739578] bcma: 0000
[ 5167.739579] bcma: 0000
[ 5167.739581] bcma: 0000
[ 5167.739582] bcma: 0000
[ 5167.739584] bcma: 0000
[ 5167.739585] bcma: 0000
[ 5167.739587] bcma: 0000
[ 5167.739588] bcma: 0000
[ 5167.739590] bcma: 0000
[ 5167.739591] bcma: 0000
[ 5167.739593] bcma:
[ 5167.739594] bcma: 0000
[ 5167.739596] bcma: 0000
[ 5167.739597] bcma: 0048
[ 5167.739599] bcma: FED2
[ 5167.739600] bcma: 15D9
[ 5167.739602] bcma: FAC6
[ 5167.739604] bcma: 0000
[ 5167.739605] bcma: 0000
[ 5167.739607] bcma: 0000
[ 5167.739608] bcma: 0000
[ 5167.739610] bcma:
[ 5167.739612] bcma: 0000
[ 5167.739614] bcma: 0000
[ 5167.739615] bcma: 0000
[ 5167.739617] bcma: 0000
[ 5167.739618] bcma: 0000
[ 5167.739620] bcma: 0000
[ 5167.739622] bcma: 0000
[ 5167.739623] bcma: 0000
[ 5167.739625] bcma: 0000
[ 5167.739626] bcma: 0000
[ 5167.739627] bcma:
[ 5167.739629] bcma: 0000
[ 5167.739631] bcma: 0000
[ 5167.739632] bcma: 0000
[ 5167.739634] bcma: 0000
[ 5167.739635] bcma: 0000
[ 5167.739637] bcma: 0000
[ 5167.739638] bcma: 0000
[ 5167.739640] bcma: 0000
[ 5167.739641] bcma: 0000
[ 5167.739643] bcma: 0000
[ 5167.739644] bcma:
[ 5167.739647] bcma: 0000
[ 5167.739648] bcma: 0000
[ 5167.739650] bcma: 0000
[ 5167.739651] bcma: 0000
[ 5167.739653] bcma: 0000
[ 5167.739654] bcma: 0000
[ 5167.739656] bcma: 0000
[ 5167.739657] bcma: 0000
[ 5167.739659] bcma: 0000
[ 5167.739660] bcma: 0000
[ 5167.739662] bcma:
[ 5167.739663] bcma: 0000
[ 5167.739665] bcma: 0000
[ 5167.739666] bcma: 0000
[ 5167.739668] bcma: 0000
[ 5167.739669] bcma: 0000
[ 5167.739671] bcma: 0000
[ 5167.739672] bcma: 0000
[ 5167.739674] bcma: 0000
[ 5167.739676] bcma: 0000
[ 5167.739677] bcma: 0000
[ 5167.739679] bcma:
[ 5167.739681] bcma: 0000
[ 5167.739682] bcma: 1111
[ 5167.739684] bcma: 1111
[ 5167.739686] bcma: 0000
[ 5167.739687] bcma: 0000
[ 5167.739689] bcma: 0000
[ 5167.739690] bcma: 0000
[ 5167.739692] bcma: 0000
[ 5167.739693] bcma: 0000
[ 5167.739695] bcma: 2222
[ 5167.739696] bcma:
[ 5167.739698] bcma: 3222
[ 5167.739700] bcma: 0000
[ 5167.739701] bcma: 0000
[ 5167.739703] bcma: 0000
[ 5167.739704] bcma: 0000
[ 5167.739706] bcma: 0000
[ 5167.739707] bcma: 0000
[ 5167.739709] bcma: 0000
[ 5167.739710] bcma: 0000
[ 5167.739712] bcma: 0000
[ 5167.739713] bcma:
[ 5167.739716] bcma: 0000
[ 5167.739717] bcma: 0000
[ 5167.739719] bcma: 0000
[ 5167.739720] bcma: 0000
[ 5167.739722] bcma: 0000
[ 5167.739723] bcma: 0000
[ 5167.739725] bcma: 0000
[ 5167.739726] bcma: 0000
[ 5167.739728] bcma: 0000
[ 5167.739729] bcma: 0000
[ 5167.739731] bcma:
[ 5167.739732] bcma: 0000
[ 5167.739734] bcma: 0000
[ 5167.739735] bcma: 0000
[ 5167.739737] bcma: 0000
[ 5167.739738] bcma: 0000
[ 5167.739740] bcma: 0000
[ 5167.739741] bcma: 0000
[ 5167.739743] bcma: 0000
[ 5167.739744] bcma: 0000
[ 5167.739746] bcma: 0000
[ 5167.739748] bcma:
[ 5167.739750] bcma: 0000
[ 5167.739751] bcma: 0000
[ 5167.739753] bcma: 0000
[ 5167.739755] bcma: 0000
[ 5167.739756] bcma: 0000
[ 5167.739758] bcma: 0000
[ 5167.739759] bcma: 0000
[ 5167.739761] bcma: 0000
[ 5167.739762] bcma: 0000
[ 5167.739764] bcma: 0000
[ 5167.739765] bcma:
[ 5167.739767] bcma: 0000
[ 5167.739768] bcma: 0000
[ 5167.739770] bcma: 0000
[ 5167.739772] bcma: 0000
[ 5167.739773] bcma: 0000
[ 5167.739775] bcma: 0000
[ 5167.739776] bcma: 0000
[ 5167.739778] bcma: 0000
[ 5167.739779] bcma: 0000
[ 5167.739782] bcma: bus0: Found SPROM revision 8
[ 5167.752730] bcma: bus0: GPIO driver not activated
[ 5167.752738] bcma: bus0: Bus registered
[ 5167.765209] brcmsmac bcma0:0: mfg 4bf core 812 rev 24 class 0 irq 17
[ 5167.765319] bcma: bus0: Switched to core: 0x812
[ 5167.766135] brcmsmac bcma0:0: hardware: SECI
[ 5167.766559] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 5167.786115] cfg80211: World regulatory domain updated:
[ 5167.786128] cfg80211: DFS Master region: unset
[ 5167.786131] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 5167.786137] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 5167.786141] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 5167.786144] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 5167.786148] cfg80211: (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
[ 5167.786152] cfg80211: (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 5167.786155] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 5167.786159] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 5167.786162] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 5167.794806] cfg80211: Calling CRDA for country: DE
[ 5167.810110] cfg80211: Regulatory domain changed to country: DE
[ 5167.810122] cfg80211: DFS Master region: ETSI
[ 5167.810125] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 5167.810131] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 5167.810134] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 5167.810139] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz), (N/A, 2000 mBm), (0 s)
[ 5167.810142] cfg80211: (5470000 KHz - 5725000 KHz @ 80000 KHz), (N/A, 2698 mBm), (0 s)
[ 5167.810146] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
Greetings,
Maxi
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V2 1/2] e100 in linux-3.18.0: Fix null pointer deference in e100_probe
From: Sergei Shtylyov @ 2014-12-21 14:02 UTC (permalink / raw)
To: Jia-Ju Bai, David Miller, netdev
Cc: todd.fujinaka, Linux-nics, linux.nics, e1000-devel
In-Reply-To: <5496203F.9000000@163.com>
On 12/21/2014 4:19 AM, Jia-Ju Bai wrote:
Please don't send HTML to this mailing list -- your mail may be ignored by
the list server.
> The driver lacks the check of nic->cbs_pool after pci_pool_create in e100_probe. So when this function is failed, the null pointer dereference occurs when pci_pool_alloc uses nic->cbs_pool in e100_alloc_cbs.
Same comment as for the previous patch about wrapping at 80 columns.
> This patch fix this problem, and it has been tested in runtime.
> Signed-off-by: Jia-Ju Bai<baijiaju1990@163.com>
> ---
> drivers/net/ethernet/intel/e100.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
> index 781065e..ba1813f 100644
> --- a/drivers/net/ethernet/intel/e100.c
> +++ b/drivers/net/ethernet/intel/e100.c
> @@ -2969,6 +2969,10 @@ static int e100_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> nic->params.cbs.max * sizeof(struct cb),
> sizeof(u32),
> 0);
> + if (!nic->cbs_pool) {
> + err = -ENOMEM;
> + goto err_out_pool;
> + }
Looks like tabs got converted to spaces by your mailer, thus the patch
can't be applied. Consider using 'git send-email' instead.
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH V2] e1000: Add netif_napi_del in the normal path and error path to match netif_napi_add
From: Sergei Shtylyov @ 2014-12-21 13:57 UTC (permalink / raw)
To: Jia-Ju Bai, David Miller, netdev
Cc: todd.fujinaka, Linux-nics, linux.nics, e1000-devel
In-Reply-To: <549619E6.8070503@163.com>
Hello.
On 12/21/2014 3:52 AM, Jia-Ju Bai wrote:
> Th driver lacks netif_napi_del in the normal path and error path to match the
> call of netif_napi_add in e1000_probe.
Please wrap your change log lines at 80 columns (or less).
> This patch fixes this problem, and it has been tested in runtime.
> Signed-off-by: Jia-Ju Bai<baijiaju1990@163.com>
> ---
> drivers/net/ethernet/intel/e1000/e1000_main.c | 6 +-
> 1 file changed, 4 insertions(+), 2 deletions(-)
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
> b/drivers/net/ethernet/intel/e1000/e1000_main.c
>
> index 24f3986..f6def7b 100644
>
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
>
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
>
> @@ -1004,7 +1004,7 @@ static int e1000_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
>
> /* make ready for any if (hw->...) below */
>
> err = e1000_init_hw_struct(adapter, hw);
>
> if (err)
>
> - goto err_sw_init;
>
> + goto err_dma;
>
> /* there is a workaround being applied below that limits
>
> * 64-bit DMA addresses to 64-bit hardware. There are some
Somehow your mailer inserted empty lines after each actual line of the
patch. :-(
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net] in6: fix conflict with glibc
From: Hannes Frederic Sowa @ 2014-12-21 13:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Florent Fourcot, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141220121549.7c1b8aad@urahara>
On Sa, 2014-12-20 at 12:15 -0800, Stephen Hemminger wrote:
> Resolve conflicts between glibc definition of IPV6 socket options
> and those defined in Linux headers. Looks like earlier efforts to
> solve this did not cover all the definitions.
>
> It resolves warnings during iproute2 build.
> Please consider for stable as well.
>
> Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Acked-by: Hannes Frederic Sowa <hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] net: ceph: ceph_strings.c: Remove unused function
From: Ilya Dryomov @ 2014-12-21 11:24 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Sage Weil, David S. Miller, Ceph Development, netdev,
Linux Kernel Mailing List
In-Reply-To: <1419078894-31656-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On Sat, Dec 20, 2014 at 3:34 PM, Rickard Strandqvist
<rickard_strandqvist@spectrumdigital.se> wrote:
> Remove the function ceph_pool_op_name() that is not used anywhere.
>
> This was partially found by using a static code analysis program called cppcheck.
It's part of pool op infrastructure and I'd rather we use it in
monc_show() than remove it. I'll make a patch.
Thanks,
Ilya
^ permalink raw reply
* Re: [PATCH] net: ceph: armor.c: Remove unused function
From: Ilya Dryomov @ 2014-12-21 11:19 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Sage Weil, David S. Miller, Ceph Development, netdev,
Linux Kernel Mailing List
In-Reply-To: <1419115000-12178-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On Sun, Dec 21, 2014 at 1:36 AM, Rickard Strandqvist
<rickard_strandqvist@spectrumdigital.se> wrote:
> Remove the function ceph_armor() that is not used anywhere.
>
> This was partially found by using a static code analysis program called cppcheck.
It's ceph_unarmor()'s counterpart - so same as for "[PATCH] net: ceph:
crypto.c: Remove some unused functions".
Thanks,
Ilya
^ permalink raw reply
* Re: [PATCH] net: ceph: crypto.c: Remove some unused functions
From: Ilya Dryomov @ 2014-12-21 11:16 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Sage Weil, David S. Miller, Ceph Development, netdev,
Linux Kernel Mailing List
In-Reply-To: <1419094326-9218-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On Sat, Dec 20, 2014 at 7:52 PM, Rickard Strandqvist
<rickard_strandqvist@spectrumdigital.se> wrote:
> Removes some functions that are not used anywhere:
> ceph_encrypt() ceph_decrypt() ceph_crypto_key_encode()
>
> This was partially found by using a static code analysis program called cppcheck.
I'd like to keep this stuff even if it's unused, unless Sage/others
want it gone. ceph_crypto_key_encode() is ceph_crypto_key_decode()'s
counterpart and ceph_{en,de}crypt() are useful for reference purposes.
Thanks,
Ilya
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-12-21 10:12 UTC (permalink / raw)
To: Michael Tokarev
Cc: Maximilian Engelhardt, Rafał Miłecki, Seth Forshee,
brcm80211 development,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development
In-Reply-To: <549699D9.2060106-Gdu+ltImwkhes2APU0mLOQ@public.gmane.org>
On 12/21/14 10:58, Michael Tokarev wrote:
> 16.12.2014 19:51, Arend van Spriel wrote:
>
>> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please remove that call as it causes endless recursion and eventually reboot.
>
> Ok, that was easy. Now it loads, but wifi link still
> does not work, stalling as before. What we're looking
> at now?
The patch is just to provide me with extra bt-coex related information
in the kernel log. So if you can provide that to me I have to info
needed to look in the proprietary code base to determine what is missing.
Regards,
Arend
> (To have a common base, I applied this bt-coex patch to
> 3.18.0 kernel. I can also apply the previously mentioned
> debugging/stats patch too).
>
> Thanks,
>
> /mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-12-21 9:58 UTC (permalink / raw)
To: Arend van Spriel
Cc: Maximilian Engelhardt, Rafał Miłecki, Seth Forshee,
brcm80211 development,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development
In-Reply-To: <549062FE.2000808-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
16.12.2014 19:51, Arend van Spriel wrote:
> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please remove that call as it causes endless recursion and eventually reboot.
Ok, that was easy. Now it loads, but wifi link still
does not work, stalling as before. What we're looking
at now?
(To have a common base, I applied this bt-coex patch to
3.18.0 kernel. I can also apply the previously mentioned
debugging/stats patch too).
Thanks,
/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [RFC iproute2 v2] tc: Show classes in tree view
From: Vadim Kochan @ 2014-12-21 9:47 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Added new '-t[ree]' which shows classes dependency
in the tree view. Meanwhile only generic stats info
is supported.
e.g.:
$ tc/tc -t class show dev tap0
+---(1:2) htb rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| +---(1:40) htb prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| +---(1:50) htb rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | +---(1:51) htb prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| |
| +---(1:60) htb prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
|
+---(1:1) htb rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
+---(1:10) htb prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
+---(1:20) htb prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
+---(1:30) htb prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
$ tc/tc -t -s class show dev tap0
+---(1:2) htb rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
| | rate 0bit 0pps backlog 0b 0p requeues 0
| |
| +---(1:40) htb prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
| | rate 0bit 0pps backlog 0b 0p requeues 0
| |
| +---(1:50) htb rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| | | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
| | | rate 0bit 0pps backlog 0b 0p requeues 0
| | |
| | +---(1:51) htb prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
| | rate 0bit 0pps backlog 0b 0p requeues 0
| |
| +---(1:60) htb prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
| Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
| rate 0bit 0pps backlog 0b 0p requeues 0
|
+---(1:1) htb rate 6Mbit ceil 6Mbit burst 15Kb cburst 1599b
| Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
| rate 0bit 0pps backlog 0b 0p requeues 0
|
+---(1:10) htb prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 1600b
| Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
| rate 0bit 0pps backlog 0b 0p requeues 0
|
+---(1:20) htb prio 0 rate 3Mbit ceil 6Mbit burst 15Kb cburst 1599b
| Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
| rate 0bit 0pps backlog 0b 0p requeues 0
|
+---(1:30) htb prio 0 rate 1Kbit ceil 6Mbit burst 15Kb cburst 1599b
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
include/hlist.h | 6 ++
tc/tc.c | 5 +-
tc/tc_class.c | 166 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
tc/tc_common.h | 2 +
4 files changed, 176 insertions(+), 3 deletions(-)
diff --git a/include/hlist.h b/include/hlist.h
index 4e8de9e..dd3e606 100644
--- a/include/hlist.h
+++ b/include/hlist.h
@@ -53,4 +53,10 @@ static inline void hlist_add_head(struct hlist_node *n, struct hlist_head *h)
pos; \
pos = hlist_entry_safe((pos)->member.next, typeof(*(pos)), member))
+static inline void INIT_HLIST_NODE(struct hlist_node *h)
+{
+ h->next = NULL;
+ h->pprev = NULL;
+}
+
#endif /* __HLIST_H__ */
diff --git a/tc/tc.c b/tc/tc.c
index 9b50e74..30950a6 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -34,8 +34,9 @@ int show_stats = 0;
int show_details = 0;
int show_raw = 0;
int show_pretty = 0;
-int batch_mode = 0;
+int show_tree = 0;
+int batch_mode = 0;
int resolve_hosts = 0;
int use_iec = 0;
int force = 0;
@@ -278,6 +279,8 @@ int main(int argc, char **argv)
++show_raw;
} else if (matches(argv[1], "-pretty") == 0) {
++show_pretty;
+ } else if (matches(argv[1], "-tree") == 0) {
+ show_tree = 1;
} else if (matches(argv[1], "-Version") == 0) {
printf("tc utility, iproute2-ss%s\n", SNAPSHOT);
return 0;
diff --git a/tc/tc_class.c b/tc/tc_class.c
index e56bf07..1c21260 100644
--- a/tc/tc_class.c
+++ b/tc/tc_class.c
@@ -24,6 +24,22 @@
#include "utils.h"
#include "tc_util.h"
#include "tc_common.h"
+#include "hlist.h"
+
+struct cls_node {
+ struct hlist_node hlist;
+ __u32 handle;
+ __u32 parent;
+ int level;
+ struct cls_node *cls_parent;
+ struct cls_node *cls_right;
+ struct rtattr *attr;
+ int attr_len;
+ int childs_count;
+};
+
+static struct hlist_head cls_list = {};
+static struct hlist_head root_cls_list = {};
static void usage(void);
@@ -148,13 +164,150 @@ int filter_ifindex;
__u32 filter_qdisc;
__u32 filter_classid;
+static void tree_cls_add(__u32 parent, __u32 handle, struct rtattr *attr, int len)
+{
+ struct cls_node *cls = malloc(sizeof(struct cls_node));
+
+ memset(cls, 0, sizeof(*cls));
+ cls->handle = handle;
+ cls->parent = parent;
+ cls->attr = malloc(len);
+ cls->attr_len = len;
+
+ memcpy(cls->attr, attr, len);
+
+ if (parent == TC_H_ROOT)
+ hlist_add_head(&cls->hlist, &root_cls_list);
+ else
+ hlist_add_head(&cls->hlist, &cls_list);
+}
+
+static void tree_cls_indent(char *buf, struct cls_node *cls, int is_newline,
+ int add_spaces)
+{
+ char spaces[100] = {0};
+
+ while (cls && cls->cls_parent) {
+ cls->cls_parent->cls_right = cls;
+ cls = cls->cls_parent;
+ }
+ while (cls && cls->cls_right)
+ {
+ if (cls->hlist.next)
+ strcat(buf, "| ");
+ else
+ strcat(buf, " ");
+
+ cls = cls->cls_right;
+ }
+
+ if (is_newline) {
+ if (cls->hlist.next && cls->childs_count)
+ strcat(buf, "| |");
+ else if (cls->hlist.next)
+ strcat(buf, "| ");
+ else if (cls->childs_count)
+ strcat(buf, " |");
+ else if (!cls->hlist.next)
+ strcat(buf, " ");
+ }
+ if (add_spaces > 0)
+ {
+ sprintf(spaces, "%-*s", add_spaces, "");
+ strcat(buf, spaces);
+ }
+}
+
+static void tree_cls_show(FILE *fp, char *buf, struct hlist_head *root_list, int level)
+{
+ struct hlist_node *n, *tmp_cls;
+ char cls_id_str[256] = {};
+ struct rtattr * tb[TCA_MAX+1] = {};
+ struct qdisc_util *q;
+ char str[100] = {};
+
+ hlist_for_each_safe(n, tmp_cls, root_list) {
+ struct hlist_node *c, *tmp_chld;
+ struct hlist_head childs = {};
+ struct cls_node *cls = container_of(n, struct cls_node, hlist);
+
+ hlist_for_each_safe(c, tmp_chld, &cls_list) {
+ struct cls_node *child = container_of(c, struct cls_node, hlist);
+
+ if (cls->handle == child->parent) {
+ hlist_del(c);
+ INIT_HLIST_NODE(c);
+ hlist_add_head(c, &childs);
+ cls->childs_count++;
+ child->cls_parent = cls;
+ }
+ }
+
+ tree_cls_indent(buf, cls, 0, 0);
+
+ print_tc_classid(cls_id_str, sizeof(cls_id_str), cls->handle);
+ sprintf(str, "+---(%s)", cls_id_str);
+ strcat(buf, str);
+
+ parse_rtattr(tb, TCA_MAX, cls->attr, cls->attr_len);
+
+ if (tb[TCA_KIND] == NULL) {
+ strcat(buf, " unknown tc kind ");
+ } else {
+ const char *kind = rta_getattr_str(tb[TCA_KIND]);
+
+ sprintf(str, " %s ", kind);
+ strcat(buf, str);
+ fprintf(fp, "%s", buf);
+ buf[0] = '\0';
+
+ q = get_qdisc_kind(kind);
+ if (q && q->print_copt) {
+ q->print_copt(q, fp, tb[TCA_OPTIONS]);
+ }
+ if (q && show_stats)
+ {
+ int cls_indent = strlen(q->id) - 2 +
+ strlen(cls_id_str);
+ struct rtattr *xstats = NULL;
+
+ tree_cls_indent(buf, cls, 1, cls_indent);
+
+ if (tb[TCA_STATS] || tb[TCA_STATS2]) {
+ fprintf(fp, "\n");
+ print_tcstats_attr(fp, tb, buf, &xstats);
+ buf[0] = '\0';
+ }
+ if (cls->hlist.next || cls->childs_count)
+ {
+ strcat(buf, "\n");
+ tree_cls_indent(buf, cls, 1, 0);
+ }
+ }
+ }
+ free(cls->attr);
+ fprintf(fp, "%s\n", buf);
+ buf[0] = '\0';
+
+ tree_cls_show(fp, buf, &childs, level + 1);
+ if (!cls->hlist.next) {
+ tree_cls_indent(buf, cls, 0, 0);
+ strcat(buf, "\n");
+ }
+
+ fprintf(fp, "%s", buf);
+ buf[0] = '\0';
+ free(cls);
+ }
+}
+
int print_class(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg)
{
FILE *fp = (FILE*)arg;
struct tcmsg *t = NLMSG_DATA(n);
int len = n->nlmsg_len;
- struct rtattr * tb[TCA_MAX+1];
+ struct rtattr * tb[TCA_MAX+1] = {};
struct qdisc_util *q;
char abuf[256];
@@ -167,13 +320,18 @@ int print_class(const struct sockaddr_nl *who,
fprintf(stderr, "Wrong len %d\n", len);
return -1;
}
+
+ if (show_tree) {
+ tree_cls_add(t->tcm_parent, t->tcm_handle, TCA_RTA(t), len);
+ return 0;
+ }
+
if (filter_qdisc && TC_H_MAJ(t->tcm_handle^filter_qdisc))
return 0;
if (filter_classid && t->tcm_handle != filter_classid)
return 0;
- memset(tb, 0, sizeof(tb));
parse_rtattr(tb, TCA_MAX, TCA_RTA(t), len);
if (tb[TCA_KIND] == NULL) {
@@ -236,6 +394,7 @@ static int tc_class_list(int argc, char **argv)
{
struct tcmsg t;
char d[16];
+ char buf[1024] = {0};
memset(&t, 0, sizeof(t));
t.tcm_family = AF_UNSPEC;
@@ -306,6 +465,9 @@ static int tc_class_list(int argc, char **argv)
return 1;
}
+ if (show_tree)
+ tree_cls_show(stdout, &buf[0], &root_cls_list, 0);
+
return 0;
}
diff --git a/tc/tc_common.h b/tc/tc_common.h
index 4f88856..0ee009b 100644
--- a/tc/tc_common.h
+++ b/tc/tc_common.h
@@ -19,3 +19,5 @@ extern int parse_estimator(int *p_argc, char ***p_argv, struct tc_estimator *est
struct tc_sizespec;
extern int parse_size_table(int *p_argc, char ***p_argv, struct tc_sizespec *s);
extern int check_size_table_opts(struct tc_sizespec *s);
+
+extern int show_tree;
--
2.1.3
^ permalink raw reply related
* Re: Stable fixes for batman-adv
From: Antonio Quartulli @ 2014-12-21 9:39 UTC (permalink / raw)
To: Sven Eckelmann, davem; +Cc: netdev
In-Reply-To: <1419079737-31107-1-git-send-email-sven@narfation.org>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
Hi Sven,
On 20/12/14 13:48, Sven Eckelmann wrote:
> Hi,
>
> it seems that patches aren't forwarded anymore (since August?) from batman-adv
> to the netdev mailing list. Please correct me if I am wrong.
>
Thank you very much for sending these patches to stable. Unfortunately
in the last months I've been really busy with work and my focus has been
shifted a bit away ... I should be able to get back in sync after these
Christmas and New Year holidays.
David, please merge these fixes and queue them for stable even if this
is not the standard pull request we usually do.
Thank you all again for your work.
Regards,
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2 1/2] 8139too in linux-3.18.0: Fix the lack of pci_disable_device
From: Jia-Ju Bai @ 2014-12-21 7:36 UTC (permalink / raw)
To: Sergei Shtylyov, netdev; +Cc: jgarzik, shangh, bjj13
In-Reply-To: <54958534.7070202@cogentembedded.com>
When pci_request_regions is failed in rtl8139_init_board,
pci_disable_device is not called to disable the device which are enabled
by pci_enable_device, because disable_dev_on_err is not assigned 1.
This patch fix this problem.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/net/ethernet/realtek/8139too.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/8139too.c
b/drivers/net/ethernet/realtek/8139too.c
index 007b38c..49bbcf3 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -783,10 +783,10 @@ static struct net_device
*rtl8139_init_board(struct pci_dev *pdev)
if (rc)
goto err_out;
+ disable_dev_on_err = 1;
rc = pci_request_regions (pdev, DRV_NAME);
if (rc)
goto err_out;
- disable_dev_on_err = 1;
pci_set_master (pdev);
^ permalink raw reply related
* good day
From: christain147 @ 2014-12-19 22:46 UTC (permalink / raw)
To: Recipients
Good day,This email is sequel to an ealier sent message of which you have
not responded.I have a personal charity project which I will want you to
execute on my behalf.Please kindly get back to me with this code
MHR/3910/2014 .You can reach me on mrsalimqadri@gmail.com .
Thank you
Salim Qadri
^ permalink raw reply
* Re: [PATCH] bonding: avoid re-entry of bond_release
From: Ding Tianhong @ 2014-12-21 2:01 UTC (permalink / raw)
To: Andy Gospodarek, Wengang Wang; +Cc: netdev
In-Reply-To: <20141219151157.GD22253@gospo>
On 2014/12/19 23:11, Andy Gospodarek wrote:
> On Fri, Dec 19, 2014 at 04:56:57PM +0800, Wengang Wang wrote:
>> If bond_release is run against an interface which is already detached from
>> it's master, then there is an error message shown like
>> "<master name> cannot release <slave name>".
>>
>> The call path is:
>> bond_do_ioctl()
>> bond_release()
>> __bond_release_one()
>>
>> Though it does not really harm, the message the message is misleading.
>> This patch tries to avoid the message.
>>
>> Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
>> ---
>> drivers/net/bonding/bond_main.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 184c434..4a71bbd 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -3256,7 +3256,10 @@ static int bond_do_ioctl(struct net_device *bond_dev, struct ifreq *ifr, int cmd
>> break;
>> case BOND_RELEASE_OLD:
>> case SIOCBONDRELEASE:
>> - res = bond_release(bond_dev, slave_dev);
>> + if (slave_dev->flags & IFF_SLAVE)
>> + res = bond_release(bond_dev, slave_dev);
>> + else
>> + res = 0;
>
> Functionally this patch is fine, but I would prefer that you simply
> change the check in __bond_release_one to not be so noisy. There is a
> check[1] in bond_enslave to see if a slave is already in a bond and that
> just prints a message of netdev_dbg (rather than netdev_err) and it
> seems that would be appropriate for this type of message.
>
> [1] from bond_enslave():
>
> /* already enslaved */
> if (slave_dev->flags & IFF_SLAVE) {
> netdev_dbg(bond_dev, "Error: Device was already enslaved\n");
> return -EBUSY;
> }
>
>
>> break;
>> case BOND_SETHWADDR_OLD:
>> case SIOCBONDSETHWADDR:
>> --
agree ,use netdev_dbg looks more better and enough.
Ding
>> 1.8.3.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH V2 2/2] e100 in linux-3.18.0: Add netif_napi_del in the normal path and error path to match netif_napi_add
From: Jia-Ju Bai @ 2014-12-21 1:51 UTC (permalink / raw)
To: David Miller, netdev
Cc: bjj13, linux.nics, sergei.shtylyov, e1000-devel, Linux-nics
In-Reply-To: <20141220.143005.1130435723139487537.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 901 bytes --]
The driver lacks netif_napi_del in the normal path and error path to
match the call of netif_napi_add in e100_probe.
This patch fixes this problem, and it has been tested in runtime.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/net/ethernet/intel/e100.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e100.c
b/drivers/net/ethernet/intel/e100.c
index 781065e..21c4d0f 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -2985,6 +2985,7 @@ err_out_free_res:
err_out_disable_pdev:
pci_disable_device(pdev);
err_out_free_dev:
+ netif_napi_del(&nic->napi);
free_netdev(netdev);
return err;
}
@@ -2995,6 +2996,7 @@ static void e100_remove(struct pci_dev *pdev)
if (netdev) {
struct nic *nic = netdev_priv(netdev);
+ netif_napi_del(&nic->napi);
unregister_netdev(netdev);
e100_free(nic);
pci_iounmap(pdev, nic->csr);
[-- Attachment #2: Type: text/plain, Size: 441 bytes --]
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
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 related
* [PATCH V2 1/2] e100 in linux-3.18.0: Fix null pointer deference in e100_probe
From: Jia-Ju Bai @ 2014-12-21 1:19 UTC (permalink / raw)
To: David Miller, netdev; +Cc: e1000-devel, linux.nics, sergei.shtylyov, Linux-nics
In-Reply-To: <20141220.143005.1130435723139487537.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 1280 bytes --]
The driver lacks the check of nic->cbs_pool after pci_pool_create in e100_probe. So when this function is failed, the null pointer dereference occurs when pci_pool_alloc uses nic->cbs_pool in e100_alloc_cbs.
This patch fix this problem, and it has been tested in runtime.
Signed-off-by: Jia-Ju Bai<baijiaju1990@163.com>
---
drivers/net/ethernet/intel/e100.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
index 781065e..ba1813f 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -2969,6 +2969,10 @@ static int e100_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
nic->params.cbs.max * sizeof(struct cb),
sizeof(u32),
0);
+ if (!nic->cbs_pool) {
+ err = -ENOMEM;
+ goto err_out_pool;
+ }
netif_info(nic, probe, nic->netdev,
"addr 0x%llx, irq %d, MAC addr %pM\n",
(unsigned long long)pci_resource_start(pdev, use_io ? 1 : 0),
@@ -2976,6 +2980,8 @@ static int e100_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
return 0;
+err_out_pool:
+ unregister_netdev(netdev);
err_out_free:
e100_free(nic);
err_out_iounmap:
[-- Attachment #2: Type: text/plain, Size: 441 bytes --]
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
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 related
* [PATCH V2] e1000: Add netif_napi_del in the normal path and error path to match netif_napi_add
From: Jia-Ju Bai @ 2014-12-21 0:52 UTC (permalink / raw)
To: David Miller, netdev; +Cc: e1000-devel, linux.nics, sergei.shtylyov, Linux-nics
In-Reply-To: <20141220.143005.1130435723139487537.davem@davemloft.net>
Th driver lacks netif_napi_del in the normal path and error path to match the call of netif_napi_add in e1000_probe.
This patch fixes this problem, and it has been tested in runtime.
Signed-off-by: Jia-Ju Bai<baijiaju1990@163.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 6 +-
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 24f3986..f6def7b 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1004,7 +1004,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
/* make ready for any if (hw->...) below */
err = e1000_init_hw_struct(adapter, hw);
if (err)
- goto err_sw_init;
+ goto err_dma;
/* there is a workaround being applied below that limits
* 64-bit DMA addresses to 64-bit hardware. There are some
@@ -1239,8 +1239,9 @@ err_eeprom:
iounmap(hw->flash_address);
kfree(adapter->tx_ring);
kfree(adapter->rx_ring);
-err_dma:
err_sw_init:
+ netif_napi_del(&adapter->napi);
+err_dma:
err_mdio_ioremap:
iounmap(hw->ce4100_gbe_mdio_base_virt);
iounmap(hw->hw_addr);
@@ -1271,6 +1272,7 @@ static void e1000_remove(struct pci_dev *pdev)
e1000_down_and_stop(adapter);
e1000_release_manageability(adapter);
+ netif_napi_del(&adapter->napi);
unregister_netdev(netdev);
e1000_phy_hw_reset(hw);
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
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
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