* Re: [PATCH] Add pch ieee1588 driver for Intel EG20T PCH
From: Richard Cochran @ 2011-08-10 7:28 UTC (permalink / raw)
To: Toshiharu Okada
Cc: tomoya-linux, kok.howg.ewe, joel.clark, yong.y.wang, qi.wang,
linux-kernel, netdev, richard.cochran
In-Reply-To: <817E42EB77CC464D9F0BA9D4CB92C152@hacdom.okisemi.com>
On Wed, Aug 10, 2011 at 02:03:32PM +0900, Toshiharu Okada wrote:
> Hi Richard
>
> I added comment below.
> Please confirm them
Thanks, I have a few questions, below.
I will also comment on the patch itself.
> >Section 14.6.1.10 in the data sheet seems to imply that the input
> >clock is 50 MHz. In that case you could use a nominal frequency of
> >31.25 MHz (period 32 ns, SHIFT 5). However, you need to find out
> >the actual input clock frequency. If this can vary, then the driver
> >should allow changing these values.
>
> modify as follows.
>
> #define DEFAULT_ADDEND 0xA0000000
> #define TICKS_NS_SHIFT 5
Have you determined the input clock frequency?
If so, what is it?
> >> + u32 ch_control;
> >
> >You never program this register. But I think the "Mode" field should
> >be set to 2. The other settings really make no sense at all. Or do
> >you set this in the MAC driver?
> >
> >(I wonder why Intel retained the very limited PTP V1 modes from the
> >IXP time stamping unit.)
>
> ch_control register was set as 0x80020000 (Version:1, mode:2 )
It might make more sense to set this register in the MAC driver in
connection with enabling and disabling packet time stamps (see below).
> >This ISR code (and much of the rest of the driver) is copied from the
> >IXP driver. It would be nice to know if it actually works on the atom
> >hardware. Do have any hardware to try it on?
>
> We have a board of atom(E600) and EG20T.
> However there is no environment for confirming auxiliary snapshot.
Well, if you plan to test the auxiliary snapshot on real hardware,
then we can leave the code as it is.
Otherwise, I would prefer to move the auxiliary snapshot code into a
separate patch. Then, we can wait to merge that code until someone
tests it.
I did test the auxiliary snapshot code on the IXP465, and probably it
will work just fine, but I want to be sure that it works on the atom
before merging.
> >I would also like to see how the time stamps are done in the MAC
> >driver. Have you already posted that?
>
> Mac driver already upstreamed. ( drivers/net/pch_gbe)
> However the code relevant to IEEE1588 is not contained into Ethernet driver.
> I have question about rx/tx snapshot.
> Is it necessary to use a snapshot within an Ethernet driver driver?
> I was indicated that there must not be any dependence of a device when the
> Ethernet driver was upstreamed.
(I assume that you mean "time stamp" when you say, "snapshot")
You will need to also add time stamping support into that driver. That
means supporting the SIOCSHWTSTAMP ioctl. As an example, you can take
a look at drivers/net/arm/ixp4xx_eth.c.
It would be nice to have a series of two patches, one adding the PHC
driver, and one adding SIOCSHWTSTAMP to the MAC driver.
Thanks,
Richard
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Michael Guntsche @ 2011-08-10 7:40 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <20110810070722.GA2150@minipsycho>
On Wed, Aug 10, 2011 at 9:07 AM, Jiri Pirko <jpirko@redhat.com> wrote:
> Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>>Good evening/morning,
>>
>>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>>> testing. On a first look everything seemed to work fine, but when I
>>> tried to connect via openvpn to my internal network (tap0 being bridged
>>> with the internal network) I noticed that I was not able to access the
>>> server on my internal network. I could access the bridge (which is
>>> acting as the openvpn server as well) just fine though.
>>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>>> internal network. I could see the ARP requests being answered.....
>><snip>
>>
>>After much digging and testing I found the commit that causes the
>>problem for me here.
>>
>>87c288c6e gianfar: do vlan cleanup
>>
>>Before this commit my bridge works fine. I simplified the test case
>>and just tried to access the server from a local wireless device with
>>gets also bridged via
>>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>>device from the internal network afterwards it stops.
>>For testing purposes I reverted this commit (plus some others to make
>>the code compile) and it started working again.
>>The hardware is a routerboard with three onboard nics two of em gianfar.
>>The gianfar nics do not support any kind of offloading,
>
> Thanks for testing/report. I'm not sure I understand your simplified
> case :(
Sorry if my explanation was confusing but it was late night/morning
when I wrote it.
The setup is quite easy.
WLAN ----->|Bridge|<----- Wired Lan (gianfar nic)
Client (in WLAN): 192.168.42.55
Bridge: 192.168.42.1
Server (on Wired): 192.168.42.127
With your patch the Bridge can ping the client and the server, but the
client cannot reach the server and vice-versa.
>
> Anyway, gianfar supports rx/tx vlan accel. Would you please try to turn
> it on/off manually by ethtool to see if it works in some setup?
The gianfar chip in this routerboard does NOT support vlan accel it is
a TSEC model.
ethtool complains that this feature is not supported.
>
> I presume you have no vlans involved in your setup, right?
No, there are no vlans in my setup.
>>Is it possible that the new code is tripped up by the bridge offload
>>parameters somehow and thinks that the gianfar nic supports it as
>>well?
>
> I don't see how now. Outside the bridge all is working correctly?
Yes I can access the server from the bridge so the network is working.
For me it looks like that the packets are just dropped when they
should go through the bridge.
Kind regards,
Michael
^ permalink raw reply
* Re: [PATCH] slip: fix NOHZ local_softirq_pending 08 warning
From: Matvejchikov Ilya @ 2011-08-10 7:47 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: netdev, Alan Cox
In-Reply-To: <4E416951.4020207@hartkopp.net>
Oliver,
As I see it, there is the following call chain of the netif_rx_ni() in
the slip (or slcan) driver:
[flush_to_ldisc] -> [disc->ops->receive_buf] -> [slip_unesc] ->
[sl_bump] -> [netif_rx_ni]
So flush_to_ldisc() may be called:
1) From tty_flush_to_ldisc() with flush_work and as it mentioned
must not be called from IRQ context.
2) From input_available_p() which can be called from n_tty_read() or
n_tty_poll(), so it's the user's context.
2) From tty_flip_buffer_push() which schedules the flush_to_ldisc to
work or calls it directly if the tty->low_latency set.
So the only thing we must take into account that with tty->low_latency
set we can be in IRQ context when doing with netif_rx_ni(). But if we
are using netif_rx_ni() we can handle both IRQ and softirq contexts
well as if there are any softirq pending netif_rx_ni() calls
do_softirq() with preemtion disabled. Then do_softirq() checks if
there is an IRQ context and does nothing if so.
So, I think it's correct to change netif_rx() with the netif_rx_ni().
2011/8/9 Oliver Hartkopp <socketcan@hartkopp.net>:
> Hello Ilya,
>
> is the processing of characters in the tty input stream for line disciplines
> *always* done in softirq context???
>
> If so, i would send a patch for drivers/net/can/slcan.c too ...
>
> Thanks,
> Oliver
>
> On 05.08.2011 21:23, Matvejchikov Ilya wrote:
>> When using nanosleep() in an userspace application we get a ratelimit warning:
>>
>> NOHZ: local_softirq_pending 08
>>
>> According to 481a8199142c050b72bff8a1956a49fd0a75bbe0 the problem is caused by
>> netif_rx() function. This patch replaces netif_rx() with netif_rx_ni() which
>> has to be used from process/softirq context.
>>
>> Signed-off-by: Matvejchikov Ilya <matvejchikov@gmail.com>
>> ---
>> drivers/net/slip.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/slip.c b/drivers/net/slip.c
>> index f11b3f3..4c61753 100644
>> --- a/drivers/net/slip.c
>> +++ b/drivers/net/slip.c
>> @@ -367,7 +367,7 @@ static void sl_bump(struct slip *sl)
>> memcpy(skb_put(skb, count), sl->rbuff, count);
>> skb_reset_mac_header(skb);
>> skb->protocol = htons(ETH_P_IP);
>> - netif_rx(skb);
>> + netif_rx_ni(skb);
>> dev->stats.rx_packets++;
>> }
>>
>
>
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robert Schwebel @ 2011-08-10 8:15 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <1312945564-6626-6-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Robin,
On Tue, Aug 09, 2011 at 10:06:04PM -0500, Robin Holt wrote:
> In working with the socketcan developers, we have come to the conclusion
> the Documentation...fsl-flexcan.txt device tree documentation needs to
> be cleaned up. The driver does not depend upon any properties other
> than the required properties so we are removing the file. Additionally,
> the p1010*dts* files are not following the standard for node naming in
> that they have a trailing -v1.0.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
> arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> 3 files changed, 4 insertions(+), 73 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
I suggest that you set devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org and Grant
Likely on Cc: for this patch.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Jiri Pirko @ 2011-08-10 8:37 UTC (permalink / raw)
To: Michael Guntsche; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <CAMvAeqNA9Wcr3bO+Vya4gt2YC47oe=-A8Fxnswdj0ozD5tfZtQ@mail.gmail.com>
Wed, Aug 10, 2011 at 09:40:50AM CEST, mguntsche@gmail.com wrote:
>On Wed, Aug 10, 2011 at 9:07 AM, Jiri Pirko <jpirko@redhat.com> wrote:
>> Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>>>Good evening/morning,
>>>
>>>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>>>> testing. On a first look everything seemed to work fine, but when I
>>>> tried to connect via openvpn to my internal network (tap0 being bridged
>>>> with the internal network) I noticed that I was not able to access the
>>>> server on my internal network. I could access the bridge (which is
>>>> acting as the openvpn server as well) just fine though.
>>>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>>>> internal network. I could see the ARP requests being answered.....
>>><snip>
>>>
>>>After much digging and testing I found the commit that causes the
>>>problem for me here.
>>>
>>>87c288c6e gianfar: do vlan cleanup
>>>
>>>Before this commit my bridge works fine. I simplified the test case
>>>and just tried to access the server from a local wireless device with
>>>gets also bridged via
>>>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>>>device from the internal network afterwards it stops.
>>>For testing purposes I reverted this commit (plus some others to make
>>>the code compile) and it started working again.
>>>The hardware is a routerboard with three onboard nics two of em gianfar.
>>>The gianfar nics do not support any kind of offloading,
>>
>> Thanks for testing/report. I'm not sure I understand your simplified
>> case :(
>Sorry if my explanation was confusing but it was late night/morning
>when I wrote it.
>
>The setup is quite easy.
>
>WLAN ----->|Bridge|<----- Wired Lan (gianfar nic)
>
>Client (in WLAN): 192.168.42.55
>Bridge: 192.168.42.1
>Server (on Wired): 192.168.42.127
>
>With your patch the Bridge can ping the client and the server, but the
>client cannot reach the server and vice-versa.
This is very interesting. Can you please find out of packets get lost on
tx or rx of gianfar? Please try to watch the trafic by tcpdump on bridge
and on gianfar device.
>
>>
>> Anyway, gianfar supports rx/tx vlan accel. Would you please try to turn
>> it on/off manually by ethtool to see if it works in some setup?
>The gianfar chip in this routerboard does NOT support vlan accel it is
>a TSEC model.
>ethtool complains that this feature is not supported.
What routerboard is it? Maybe I can get one to see this myself. Thanks.
Can you please send me output of following command?
"cat /sys/class/net/[gianfar devname]/features"
Also, please try with following testing patch:
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 2659daa..2727bb7 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2711,8 +2711,8 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
skb->protocol = eth_type_trans(skb, dev);
/* Set vlan tag */
- if (fcb->flags & RXFCB_VLN)
- __vlan_hwaccel_put_tag(skb, fcb->vlctl);
+ //if (fcb->flags & RXFCB_VLN)
+ // __vlan_hwaccel_put_tag(skb, fcb->vlctl);
/* Send the packet up the stack */
ret = netif_receive_skb(skb);
>
>>
>> I presume you have no vlans involved in your setup, right?
>No, there are no vlans in my setup.
>
>
>>>Is it possible that the new code is tripped up by the bridge offload
>>>parameters somehow and thinks that the gianfar nic supports it as
>>>well?
>>
>> I don't see how now. Outside the bridge all is working correctly?
>Yes I can access the server from the bridge so the network is working.
>For me it looks like that the packets are just dropped when they
>should go through the bridge.
>
>Kind regards,
>Michael
^ permalink raw reply related
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Michael Guntsche @ 2011-08-10 8:46 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <20110810083732.GA1909@minipsycho.brq.redhat.com>
On Wed, Aug 10, 2011 at 10:37 AM, Jiri Pirko <jpirko@redhat.com> wrote:
> Wed, Aug 10, 2011 at 09:40:50AM CEST, mguntsche@gmail.com wrote:
>>On Wed, Aug 10, 2011 at 9:07 AM, Jiri Pirko <jpirko@redhat.com> wrote:
>>> Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>>>>Good evening/morning,
>>>>
>>>>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>>>>> testing. On a first look everything seemed to work fine, but when I
>>>>> tried to connect via openvpn to my internal network (tap0 being bridged
>>>>> with the internal network) I noticed that I was not able to access the
>>>>> server on my internal network. I could access the bridge (which is
>>>>> acting as the openvpn server as well) just fine though.
>>>>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>>>>> internal network. I could see the ARP requests being answered.....
>>>><snip>
>>>>
>>>>After much digging and testing I found the commit that causes the
>>>>problem for me here.
>>>>
>>>>87c288c6e gianfar: do vlan cleanup
>>>>
>>>>Before this commit my bridge works fine. I simplified the test case
>>>>and just tried to access the server from a local wireless device with
>>>>gets also bridged via
>>>>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>>>>device from the internal network afterwards it stops.
>>>>For testing purposes I reverted this commit (plus some others to make
>>>>the code compile) and it started working again.
>>>>The hardware is a routerboard with three onboard nics two of em gianfar.
>>>>The gianfar nics do not support any kind of offloading,
>>>
>>> Thanks for testing/report. I'm not sure I understand your simplified
>>> case :(
>>Sorry if my explanation was confusing but it was late night/morning
>>when I wrote it.
>>
>>The setup is quite easy.
>>
>>WLAN ----->|Bridge|<----- Wired Lan (gianfar nic)
>>
>>Client (in WLAN): 192.168.42.55
>>Bridge: 192.168.42.1
>>Server (on Wired): 192.168.42.127
>>
>>With your patch the Bridge can ping the client and the server, but the
>>client cannot reach the server and vice-versa.
>
> This is very interesting. Can you please find out of packets get lost on
> tx or rx of gianfar? Please try to watch the trafic by tcpdump on bridge
> and on gianfar device.
I can try to do that this afternoon.
>>> Anyway, gianfar supports rx/tx vlan accel. Would you please try to turn
>>> it on/off manually by ethtool to see if it works in some setup?
>>The gianfar chip in this routerboard does NOT support vlan accel it is
>>a TSEC model.
>>ethtool complains that this feature is not supported.
>
> What routerboard is it? Maybe I can get one to see this myself. Thanks.
The model is a Rb600a which is no longer available
> Can you please send me output of following command?
> "cat /sys/class/net/[gianfar devname]/features"
There is no file called features under the gianfar devname
>
> Also, please try with following testing patch:
>
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 2659daa..2727bb7 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2711,8 +2711,8 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
> skb->protocol = eth_type_trans(skb, dev);
>
> /* Set vlan tag */
> - if (fcb->flags & RXFCB_VLN)
> - __vlan_hwaccel_put_tag(skb, fcb->vlctl);
> + //if (fcb->flags & RXFCB_VLN)
> + // __vlan_hwaccel_put_tag(skb, fcb->vlctl);
>
> /* Send the packet up the stack */
> ret = netif_receive_skb(skb);
Will do.
Kind regards,
Michael
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Jiri Pirko @ 2011-08-10 9:00 UTC (permalink / raw)
To: Michael Guntsche; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <CAMvAeqOA0=FnjB2oPPCEYpkXdKrmqOs+MwAqszV5sTGys_a3mQ@mail.gmail.com>
Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>Good evening/morning,
>
>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>> testing. On a first look everything seemed to work fine, but when I
>> tried to connect via openvpn to my internal network (tap0 being bridged
>> with the internal network) I noticed that I was not able to access the
>> server on my internal network. I could access the bridge (which is
>> acting as the openvpn server as well) just fine though.
>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>> internal network. I could see the ARP requests being answered.....
><snip>
>
>After much digging and testing I found the commit that causes the
>problem for me here.
>
>87c288c6e gianfar: do vlan cleanup
>
>Before this commit my bridge works fine. I simplified the test case
>and just tried to access the server from a local wireless device with
>gets also bridged via
>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>device from the internal network afterwards it stops.
>For testing purposes I reverted this commit (plus some others to make
>the code compile) and it started working again.
>The hardware is a routerboard with three onboard nics two of em gianfar.
>The gianfar nics do not support any kind of offloading,
>
>Offload parameters for lan_wire:
>rx-checksumming: off
>tx-checksumming: off
>scatter-gather: off
>tcp-segmentation-offload: off
>udp-fragmentation-offload: off
>generic-segmentation-offload: off
>generic-receive-offload: on
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: off
>ntuple-filters: off
>receive-hashing: off
>
>The Bridge device on the other hand....
>
>Offload parameters for lan:
>rx-checksumming: on
>tx-checksumming: on
>scatter-gather: off
>tcp-segmentation-offload: off
>udp-fragmentation-offload: off
>generic-segmentation-offload: off
>generic-receive-offload: on
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: on
^^^^^^^^^^^^^^^^^^^ is this gfar?
>ntuple-filters: off
>receive-hashing: off
>
>Is it possible that the new code is tripped up by the bridge offload
>parameters somehow and thinks that the gianfar nic supports it as
>well?
>As I wrote in my initial mail, connecting to the Bridge itself works,
>I can also see ARP requests and Broadcasts, the rest just seems to
>disappear.
>
>As for the commits I reverted:
>a4aeb2662 vlan: kill __vlan_hwaccel_rx and vlan_hwaccel_rx
>6dacaddd4 vlan: kill vlan_hwaccel_receive_skb
>7890a5b9c vlan: kill ndo_vlan_rx_register
>b852b7208 gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
>
>87c288c6e gianfar: do vlan cleanup
>
>I really think that there is only some small change in the gianfar
>code needed, but I could not figure it out myself.
>Please tell me if you need any more information.
>
>Kind regards,
>Michael Guntsche
^ permalink raw reply
* Re: [PATCH] slip: fix NOHZ local_softirq_pending 08 warning
From: Alan Cox @ 2011-08-10 9:28 UTC (permalink / raw)
To: matvejchikov; +Cc: Oliver Hartkopp, netdev
In-Reply-To: <CAKh5naayzp3ANwnE2Y9U2LEaiWNoZAuT3aOQbRYdoB5uNdrOPw@mail.gmail.com>
> 2) From tty_flip_buffer_push() which schedules the flush_to_ldisc to
> work or calls it directly if the tty->low_latency set.
>
> So the only thing we must take into account that with tty->low_latency
> set we can be in IRQ context when doing with netif_rx_ni(). But if we
A driver is not permitted to directly call into flush_to_ldisc from an
interrupt so that case doesn't happen.
Alan
^ permalink raw reply
* Re: gianfar.c null pointer deref in gfar_start_xmit().
From: Robin Holt @ 2011-08-10 9:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Robin Holt, Sandeep Gopalpet, David S. Miller, netdev
In-Reply-To: <1312956061.2547.74.camel@edumazet-laptop>
On Wed, Aug 10, 2011 at 08:01:01AM +0200, Eric Dumazet wrote:
> Le mardi 09 août 2011 à 08:06 -0500, Robin Holt a écrit :
> > On Tue, Aug 09, 2011 at 09:10:13AM +0200, Eric Dumazet wrote:
> > > Le mardi 09 août 2011 à 01:54 -0500, Robin Holt a écrit :
> > > > On Tue, Aug 02, 2011 at 09:44:38PM -0500, Robin Holt wrote:
> > > > >
> > > > > While using the v3.0 kernel on a Freescale P1010RDB with 3 minor patches
> > > > > (None which affect gianfar.c), I get a NULL pointer deref at:
> > > > >
> > > > > static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > > > > {
> > > > > ...
> > > > > regs = tx_queue->grp->regs;
> > > > >
> > > > > I put a BUG_ON(tx_queue->grp) just before this line and it did trip.
> > > > > I have not looked at this any more than that.
> > > > >
> > > > > Any suggestions would be welcome. To reproduce, all I need to do is
> > > > > a few sequences of pings.
> > > >
> > > > I was able to reproduce this with the net-next-2.6 kernel as well.
> > > >
> > >
> > > This driver incorrectly assumes a non dense txqueue array is possible
> > > for a netdev, but its not true.
> > >
> > > In the meantime, you could force it to use one tx_queue only.
> > >
> > > tx_queues = (u32 *)of_get_property(np, "fsl,num_tx_queues", NULL);
> > > num_tx_qs = tx_queues ? *tx_queues : 1;
> >
> > I fixed up the .dts file and now it works. I have not tested the RGMII
> > interface yet so I do not know if that supports multiple queues. I assume
> > I could find it in the documentation. What might I be looking for?
> >
>
> What exact change did you in dts ?
I changed arch/powerpc/boot/dts/p1010si.dtsi and modified all lines that
had fsl,num_rx_queues and fsl,num_tx_queues then recompiled and rebuilt
my multi-image boot file.
It looks like my boot loader might be missing something. The p1010
reference manual has a section 15.7.2 Multigroup Mode Initialization.
I assume that sections initialize before using multigroup mode steps are
not getting done in the boot loader. Does that possibly sound like the
right section of the manual?
>
> Assuming your p1010rdb is single core powerpc, I fail to see why 8
> queues should be enabled on NIC. It only increases number of interrupts
> if multiple flows are in use, and memory footprint.
Thanks,
Robin
^ permalink raw reply
* Re: [linux-firmware 1/2] rtl_nic: update firmware for RTL8111E-VL
From: David Woodhouse @ 2011-08-10 9:35 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1312954862-32708-1-git-send-email-hayeswang@realtek.com>
On Wed, 2011-08-10 at 13:41 +0800, Hayes Wang wrote:
> From: Albert Kuo <albertk@realtek.com>
>
> Updated firmware with stability fixes.
> Version: rtl8168e-3_0.0.1.
>
> Signed-off-by: Albert Kuo <albertk@realtek.com>
Please could you put that version information into the WHENCE file so
that it isn't lost in the git log?
--
dwmw2
^ permalink raw reply
* Re: [PATCH v10 4/5] [powerpc] Add flexcan device support for p1010rdb.
From: Marc Kleine-Budde @ 2011-08-10 9:56 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <1312945564-6626-5-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 4921 bytes --]
On 08/10/2011 05:06 AM, Robin Holt wrote:
> I added a simple clock source for the p1010rdb so the flexcan driver
> could determine a clock frequency. The p1010 can device only has an
> oscillator of system bus frequency divided by 2.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 2 +
> arch/powerpc/platforms/85xx/Makefile | 2 +
> arch/powerpc/platforms/85xx/clock.c | 53 ++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/85xx/p1010rdb.c | 8 +++++
> 4 files changed, 65 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/clock.c
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..c4304ae 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -70,6 +70,8 @@ config MPC85xx_RDB
> config P1010_RDB
> bool "Freescale P1010RDB"
> select DEFAULT_UIMAGE
> + select HAVE_CAN_FLEXCAN if NET && CAN
> + select PPC_CLOCK if CAN_FLEXCAN
> help
> This option enables support for the MPC85xx RDB (P1010 RDB) board
>
> diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
> index a971b32..cc7f381 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -3,6 +3,8 @@
> #
> obj-$(CONFIG_SMP) += smp.o
>
> +obj-$(CONFIG_PPC_CLOCK) += clock.o
> +
> obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
> obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
> obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
> diff --git a/arch/powerpc/platforms/85xx/clock.c b/arch/powerpc/platforms/85xx/clock.c
> new file mode 100644
> index 0000000..16fae04
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/clock.c
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright 2011 SGI, inc.
> + *
> + * This code is licensed for use under the GPL V2 as published by
> + * the Free Software Foundation.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +
> +#include <asm/clk_interface.h>
> +
> +#include <sysdev/fsl_soc.h>
> +
> +/*
> + * p1010 needs to provide a clock source for the flexcan driver. The
> + * oscillator for the p1010 processor is only ever the system clock / 2.
> + */
> +
> +static struct clk *mpc85xx_clk_get(struct device *dev, const char *id)
> +{
> + if (!dev)
> + return ERR_PTR(-ENOENT);
> +
> + if (!dev->of_node ||
> + !of_device_is_compatible(dev->of_node, "fsl,flexcan"))
> + return ERR_PTR(-ENOENT);
> +
> + return NULL;
> +}
> +
> +static void mpc85xx_clk_put(struct clk *clk)
> +{
> + return;
> +}
> +
> +static unsigned long mpc85xx_clk_get_rate(struct clk *clk)
> +{
> + return fsl_get_sys_freq() / 2;
> +}
> +
> +static struct clk_interface mpc85xx_clk_functions = {
> + .clk_get = mpc85xx_clk_get,
> + .clk_get_rate = mpc85xx_clk_get_rate,
> + .clk_put = mpc85xx_clk_put,
> +};
> +
> +void __init mpc85xx_clk_init(void)
> +{
> + clk_functions = mpc85xx_clk_functions;
> +}
> +
git is even picker then me: "new blank line at EOF."
please fix
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
> index d7387fa..5e52122 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -81,6 +81,13 @@ static void __init p1010_rdb_setup_arch(void)
> printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
> }
>
> +extern void mpc85xx_clk_init(void);
> +
> +static void __init p1010_rdb_init(void)
> +{
> + mpc85xx_clk_init();
> +}
> +
> static struct of_device_id __initdata p1010rdb_ids[] = {
> { .type = "soc", },
> { .compatible = "soc", },
> @@ -111,6 +118,7 @@ define_machine(p1010_rdb) {
> .name = "P1010 RDB",
> .probe = p1010_rdb_probe,
> .setup_arch = p1010_rdb_setup_arch,
> + .init = p1010_rdb_init,
> .init_IRQ = p1010_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Michael Guntsche @ 2011-08-10 9:59 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <20110810090014.GB1909@minipsycho.brq.redhat.com>
On Wed, Aug 10, 2011 at 11:00 AM, Jiri Pirko <jpirko@redhat.com> wrote:
> Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>>Good evening/morning,
>>
>>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>>> testing. On a first look everything seemed to work fine, but when I
>>> tried to connect via openvpn to my internal network (tap0 being bridged
>>> with the internal network) I noticed that I was not able to access the
>>> server on my internal network. I could access the bridge (which is
>>> acting as the openvpn server as well) just fine though.
>>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>>> internal network. I could see the ARP requests being answered.....
>><snip>
>>
>>After much digging and testing I found the commit that causes the
>>problem for me here.
>>
>>87c288c6e gianfar: do vlan cleanup
>>
>>Before this commit my bridge works fine. I simplified the test case
>>and just tried to access the server from a local wireless device with
>>gets also bridged via
>>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>>device from the internal network afterwards it stops.
>>For testing purposes I reverted this commit (plus some others to make
>>the code compile) and it started working again.
>>The hardware is a routerboard with three onboard nics two of em gianfar.
>>The gianfar nics do not support any kind of offloading,
>>
>>Offload parameters for lan_wire:
>>rx-checksumming: off
>>tx-checksumming: off
>>scatter-gather: off
>>tcp-segmentation-offload: off
>>udp-fragmentation-offload: off
>>generic-segmentation-offload: off
>>generic-receive-offload: on
>>large-receive-offload: off
>>rx-vlan-offload: off
>>tx-vlan-offload: off
>>ntuple-filters: off
>>receive-hashing: off
>>
>>The Bridge device on the other hand....
>>
>>Offload parameters for lan:
>>rx-checksumming: on
>>tx-checksumming: on
>>scatter-gather: off
>>tcp-segmentation-offload: off
>>udp-fragmentation-offload: off
>>generic-segmentation-offload: off
>>generic-receive-offload: on
>>large-receive-offload: off
>>rx-vlan-offload: off
>>tx-vlan-offload: on
> ^^^^^^^^^^^^^^^^^^^ is this gfar?
No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
/Michael
^ permalink raw reply
* Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
From: Marc Kleine-Budde @ 2011-08-10 10:01 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <1312945564-6626-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1022 bytes --]
On 08/10/2011 05:05 AM, Robin Holt wrote:
> With all the patches applied, my p1010rdb works for communicating between
> its two can ports and also can communicate with an external PSOC. I have
> done no testing beyond compile testing on an arm system as I have no
> access to an arm based system.
>
> For the first three patches in the series, I believe they are all ready
> for forwarding to David S. Miller for the netdev tree. I think patch
> 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed
> from the previous post by adding a second compatible string for the
> fsl,p1010_flexcan.
One remark for the subjects. It seems no one is using "[$subsystem]"
anymore, but rather "$subsystem:".
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 10:09 UTC (permalink / raw)
To: Grant Likely, devicetree-discuss
Cc: socketcan-core, netdev, PPC list, Kumar Gala, Marc Kleine-Budde,
Wolfgang Grandegger, U Bhaskar-B22300, Scott Wood
In-Reply-To: <1312945564-6626-6-git-send-email-holt@sgi.com>
Grant,
Do you need this patch resent with you on the Cc: list or can you pick
up the discussion from here? I am just trying to minimize noise on
the mailing lists if it is not needed.
The essence of the discussion to this point is:
1) Freescale built a board support package for a new processor and eval
board (p1010) based upon some older boards.
2) As part of that effort, they made changes as they saw fit to get it
working without submitting those changes to the community.
3) In the case of the flexcan device, that included defining a device
tree node for the integrated Controller Area Network device and set
.compatible="fsl,flexcan-v1.0". Apparently this was copied from
another device, possibly mscan.
4) In an effort to get my p1010rdb eval board working with a community
kernel, I started submitting patches for flexcan which have evolved
to the point of nearly being accepted with the exception of we need
to settle on the node's .compatible= strings and whether it should
be documented.
5) To this point, I believe the concensus has settled on
"fsl,p1010-flexcan" and "fsl,flexcan" as the compatible strings.
This leaves the most flexibility for segragating future specific
revisions of the flexcan interface if needed.
6) I failed to Cc: you or the device tree list when I submitted version
10 of the patches. I have added both to the patch header so they
will be included in the next pass.
Thanks,
Robin Holt
On Tue, Aug 09, 2011 at 10:06:04PM -0500, Robin Holt wrote:
> In working with the socketcan developers, we have come to the conclusion
> the Documentation...fsl-flexcan.txt device tree documentation needs to
> be cleaned up. The driver does not depend upon any properties other
> than the required properties so we are removing the file. Additionally,
> the p1010*dts* files are not following the standard for node naming in
> that they have a trailing -v1.0.
>
> Signed-off-by: Robin Holt <holt@sgi.com>
> To: Marc Kleine-Budde <mkl@pengutronix.de>,
> To: Wolfgang Grandegger <wg@grandegger.com>,
> To: U Bhaskar-B22300 <B22300@freescale.com>
> To: Scott Wood <scottwood@freescale.com>
> Cc: socketcan-core@lists.berlios.de,
> Cc: netdev@vger.kernel.org,
> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
> arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> 3 files changed, 4 insertions(+), 73 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> deleted file mode 100644
> index 1a729f0..0000000
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -CAN Device Tree Bindings
> -------------------------
> -2011 Freescale Semiconductor, Inc.
> -
> -fsl,flexcan-v1.0 nodes
> ------------------------
> -In addition to the required compatible-, reg- and interrupt-properties, you can
> -also specify which clock source shall be used for the controller.
> -
> -CPI Clock- Can Protocol Interface Clock
> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> - The PRESDIV field of CTRL(control register) controls a prescaler that
> - generates the Serial Clock (Sclock), whose period defines the
> - time quantum used to compose the CAN waveform.
> -
> -Can Engine Clock Source
> - There are two sources for CAN clock
> - - Platform Clock It represents the bus clock
> - - Oscillator Clock
> -
> - Peripheral Clock (PLL)
> - --------------
> - |
> - --------- -------------
> - | |CPI Clock | Prescaler | Sclock
> - | |---------------->| (1.. 256) |------------>
> - --------- -------------
> - | |
> - -------------- ---------------------CLK_SRC
> - Oscillator Clock
> -
> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> - the peripheral clock. PLL clock is fed to the
> - prescaler to generate the Serial Clock (Sclock).
> - Valid values are "oscillator" and "platform"
> - "oscillator": CAN engine clock source is oscillator clock.
> - "platform" The CAN engine clock source is the bus clock
> - (platform clock).
> -
> -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> - clock divider can be specified.
> -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> -
> -Note:
> - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> - - P1010 does not have oscillator as the Clock Source.So the default
> - Clock Source is platform clock.
> -Examples:
> -
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> - reg = <0x1c000 0x1000>;
> - interrupts = <48 0x2>;
> - interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-source = "platform";
> - fsl,flexcan-clock-divider = <2>;
> - clock-frequency = <fixed by u-boot>;
> - };
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> index 6b33b73..d6a0bb2 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -169,14 +169,6 @@
> };
> };
>
> - can0@1c000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> - can1@1d000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> usb@22000 {
> phy_type = "utmi";
> };
> diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
> index 7f51104..20c396d 100644
> --- a/arch/powerpc/boot/dts/p1010si.dtsi
> +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> @@ -141,19 +141,19 @@
> };
>
> can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> + compatible = "fsl,p1010-flexcan",
> + "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> can1@1d000 {
> - compatible = "fsl,flexcan-v1.0";
> + compatible = "fsl,p1010-flexcan",
> + "fsl,flexcan";
> reg = <0x1d000 0x1000>;
> interrupts = <61 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> L2: l2-cache-controller@20000 {
> --
> 1.7.2.1
^ permalink raw reply
* Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
From: Robin Holt @ 2011-08-10 10:11 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <4E425716.4010104-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Wed, Aug 10, 2011 at 12:01:58PM +0200, Marc Kleine-Budde wrote:
> On 08/10/2011 05:05 AM, Robin Holt wrote:
> > With all the patches applied, my p1010rdb works for communicating between
> > its two can ports and also can communicate with an external PSOC. I have
> > done no testing beyond compile testing on an arm system as I have no
> > access to an arm based system.
> >
> > For the first three patches in the series, I believe they are all ready
> > for forwarding to David S. Miller for the netdev tree. I think patch
> > 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed
> > from the previous post by adding a second compatible string for the
> > fsl,p1010_flexcan.
>
> One remark for the subjects. It seems no one is using "[$subsystem]"
> anymore, but rather "$subsystem:".
I will, one day, get these patches subject lines correct ;)
Did you happen to get a chance to test the patches on arm?
Thanks,
Robin
^ permalink raw reply
* Re: [PATCH v10 4/5] [powerpc] Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-10 10:15 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <4E4255B1.6050001-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Wed, Aug 10, 2011 at 11:56:01AM +0200, Marc Kleine-Budde wrote:
> On 08/10/2011 05:06 AM, Robin Holt wrote:
> > diff --git a/arch/powerpc/platforms/85xx/clock.c b/arch/powerpc/platforms/85xx/clock.c
> > new file mode 100644
> > index 0000000..16fae04
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/85xx/clock.c
> > @@ -0,0 +1,53 @@
...
> > +void __init mpc85xx_clk_init(void)
> > +{
> > + clk_functions = mpc85xx_clk_functions;
> > +}
> > +
>
> git is even picker then me: "new blank line at EOF."
> please fix
That reminded me that I have slacked on using checkpatch.pl in a few
resends and it really does not like this patch at all so I will rework
the patch with its concerns. I am going to hold off on resending until
there are more substantial changes.
Thanks,
Robin
^ permalink raw reply
* RE: [PATCH net-next 0/6] be2net: fixes
From: Sathya.Perla @ 2011-08-10 10:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1312906987.2371.51.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
>From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>Sent: Tuesday, August 09, 2011 9:53 PM
>> >
>>
>> Not sure which recent be2net patch is problematic on 32bit arches :
>>
>> Kernel: arch/x86/boot/bzImage is ready (#280)
>> Building modules, stage 2.
>> MODPOST 1854 modules
>> ERROR: "__udivdi3" [drivers/net/benet/be2net.ko] undefined!
>> make[1]: *** [__modpost] Erreur 1
>> make: *** [modules] Erreur 2
>>
>> Please fix this, thanks.
>>
>>
>
>Comes from commit ac124ff973e27802797
>(be2net: cleanup and refactor stats code)
>
>be_rx_eqd_update() now performs u64 divides.
>
>Following patch should be enough, there is no way packet count can
>overwrap a long anyway between two samples...
>
>
>
>[PATCH] benet: fix build error on 32bit arch
>
Thanks for the quick patch.
-Sathya
^ permalink raw reply
* Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
From: Marc Kleine-Budde @ 2011-08-10 10:24 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <20110810101113.GN4926-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1317 bytes --]
On 08/10/2011 12:11 PM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 12:01:58PM +0200, Marc Kleine-Budde wrote:
>> On 08/10/2011 05:05 AM, Robin Holt wrote:
>>> With all the patches applied, my p1010rdb works for communicating between
>>> its two can ports and also can communicate with an external PSOC. I have
>>> done no testing beyond compile testing on an arm system as I have no
>>> access to an arm based system.
>>>
>>> For the first three patches in the series, I believe they are all ready
>>> for forwarding to David S. Miller for the netdev tree. I think patch
>>> 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed
>>> from the previous post by adding a second compatible string for the
>>> fsl,p1010_flexcan.
>>
>> One remark for the subjects. It seems no one is using "[$subsystem]"
>> anymore, but rather "$subsystem:".
>
> I will, one day, get these patches subject lines correct ;)
>
> Did you happen to get a chance to test the patches on arm?
It's still compiling...
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Michael Guntsche @ 2011-08-10 10:30 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <CAMvAeqO2bLaPwmdW+c+7hz-ec=-tF6Z0EFBv=FA7+rU_QZ_wDA@mail.gmail.com>
On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
<snip>
>>>Offload parameters for lan_wire:
>>>rx-checksumming: off
>>>tx-checksumming: off
>>>scatter-gather: off
>>>tcp-segmentation-offload: off
>>>udp-fragmentation-offload: off
>>>generic-segmentation-offload: off
>>>generic-receive-offload: on
>>>large-receive-offload: off
>>>rx-vlan-offload: off
>>>tx-vlan-offload: off
>>>ntuple-filters: off
>>>receive-hashing: off
>>>
>>>The Bridge device on the other hand....
>>>
>>>Offload parameters for lan:
>>>rx-checksumming: on
>>>tx-checksumming: on
>>>scatter-gather: off
>>>tcp-segmentation-offload: off
>>>udp-fragmentation-offload: off
>>>generic-segmentation-offload: off
>>>generic-receive-offload: on
>>>large-receive-offload: off
>>>rx-vlan-offload: off
>>>tx-vlan-offload: on
>> ^^^^^^^^^^^^^^^^^^^ is this gfar?
> No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
>
> /Michael
>
Ok I would have saved hours of bisecting if I had just used the -e
switch with tcpdump from the beginning.
Jiri first of all the patch makes the connection work again. I can
ping the client on the wlan from the server and vice-versa. Taking a
look at the tcpdump (WITH -e) makes it obvious why it fails with the
non patched version...
This is a capture from the gfar lan port on the bridge with no patch applied
12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
(oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
id 23567, seq 74, length 64
As you can see we get a VLAN package????
With the patched version:
12:16:33.756966 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
(oui Unknown), ethertype IPv4 (0x0800), length 98: gibson.comsick.at >
192.168.42.55: ICMP echo request, id 23669, seq 2, length 64
12:16:33.843289 b4:07:f9:70:b7:c1 (oui Unknown) > 00:13:d4:4f:a2:dc
(oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.42.55 >
gibson.comsick.at: ICMP echo reply, id 23669, seq 2, length 64
No VLAN and I get my replies.
All that is left to do now is to find out why the current driver
thinks that it is on a VLAN when it isn't.
Any ideas Jiri?
Kind regards,
Michael
^ permalink raw reply
* Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
From: Marc Kleine-Budde @ 2011-08-10 11:09 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <1312945564-6626-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1049 bytes --]
On 08/10/2011 05:05 AM, Robin Holt wrote:
> With all the patches applied, my p1010rdb works for communicating between
> its two can ports and also can communicate with an external PSOC. I have
> done no testing beyond compile testing on an arm system as I have no
> access to an arm based system.
>
> For the first three patches in the series, I believe they are all ready
> for forwarding to David S. Miller for the netdev tree. I think patch
> 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed
> from the previous post by adding a second compatible string for the
> fsl,p1010_flexcan.
This patch series is working on phytec's pcm043 (mx35) based on current
net-next. Feel free to add my Acked-by to all patches.
good work,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Jiri Pirko @ 2011-08-10 11:19 UTC (permalink / raw)
To: Michael Guntsche
Cc: shemminger, sebastian.belden, netdev, linux-kernel, davem
In-Reply-To: <CAMvAeqM-oH1UzxEp9PgO6ZP-AKtqosuMg5za25_X8DpPJMDX2w@mail.gmail.com>
Wed, Aug 10, 2011 at 12:30:16PM CEST, mguntsche@gmail.com wrote:
>On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
><snip>
>>>>Offload parameters for lan_wire:
>>>>rx-checksumming: off
>>>>tx-checksumming: off
>>>>scatter-gather: off
>>>>tcp-segmentation-offload: off
>>>>udp-fragmentation-offload: off
>>>>generic-segmentation-offload: off
>>>>generic-receive-offload: on
>>>>large-receive-offload: off
>>>>rx-vlan-offload: off
>>>>tx-vlan-offload: off
>>>>ntuple-filters: off
>>>>receive-hashing: off
>>>>
>>>>The Bridge device on the other hand....
>>>>
>>>>Offload parameters for lan:
>>>>rx-checksumming: on
>>>>tx-checksumming: on
>>>>scatter-gather: off
>>>>tcp-segmentation-offload: off
>>>>udp-fragmentation-offload: off
>>>>generic-segmentation-offload: off
>>>>generic-receive-offload: on
>>>>large-receive-offload: off
>>>>rx-vlan-offload: off
>>>>tx-vlan-offload: on
>>> ^^^^^^^^^^^^^^^^^^^ is this gfar?
>> No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
>>
>> /Michael
>>
>
>Ok I would have saved hours of bisecting if I had just used the -e
>switch with tcpdump from the beginning.
>Jiri first of all the patch makes the connection work again. I can
>ping the client on the wlan from the server and vice-versa. Taking a
>look at the tcpdump (WITH -e) makes it obvious why it fails with the
>non patched version...
>
>This is a capture from the gfar lan port on the bridge with no patch applied
>12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
>(oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
>ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
>id 23567, seq 74, length 64
>
>As you can see we get a VLAN package????
Ugh, this is what I expected. Patch to fix:
Subject: [patch net-2.6] gianfar: prevent buggy hw rx vlan tagging
On some buggy chips, "vlan tag present" flag is set which causes packet
loss. Fix this by checking if rx vlan accel is enabled in features.
Reported-by: Michael Guntsche <mguntsche@gmail.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/gianfar.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 2659daa..31d5c57 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2710,8 +2710,13 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
/* Tell the skb what kind of packet this is */
skb->protocol = eth_type_trans(skb, dev);
- /* Set vlan tag */
- if (fcb->flags & RXFCB_VLN)
+ /*
+ * There's need to check for NETIF_F_HW_VLAN_RX here.
+ * Even if vlan rx accel is disabled, on some chips
+ * RXFCB_VLN is pseudo randomly set.
+ */
+ if (dev->features & NETIF_F_HW_VLAN_RX &&
+ fcb->flags & RXFCB_VLN)
__vlan_hwaccel_put_tag(skb, fcb->vlctl);
/* Send the packet up the stack */
--
1.7.6
^ permalink raw reply related
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Michael Guntsche @ 2011-08-10 11:51 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel, davem
In-Reply-To: <20110810111947.GC1909@minipsycho.brq.redhat.com>
On Wed, Aug 10, 2011 at 1:19 PM, Jiri Pirko <jpirko@redhat.com> wrote:
> Wed, Aug 10, 2011 at 12:30:16PM CEST, mguntsche@gmail.com wrote:
>>On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
>><snip>
>>>>>Offload parameters for lan_wire:
>>>>>rx-checksumming: off
>>>>>tx-checksumming: off
>>>>>scatter-gather: off
>>>>>tcp-segmentation-offload: off
>>>>>udp-fragmentation-offload: off
>>>>>generic-segmentation-offload: off
>>>>>generic-receive-offload: on
>>>>>large-receive-offload: off
>>>>>rx-vlan-offload: off
>>>>>tx-vlan-offload: off
>>>>>ntuple-filters: off
>>>>>receive-hashing: off
>>>>>
>>>>>The Bridge device on the other hand....
>>>>>
>>>>>Offload parameters for lan:
>>>>>rx-checksumming: on
>>>>>tx-checksumming: on
>>>>>scatter-gather: off
>>>>>tcp-segmentation-offload: off
>>>>>udp-fragmentation-offload: off
>>>>>generic-segmentation-offload: off
>>>>>generic-receive-offload: on
>>>>>large-receive-offload: off
>>>>>rx-vlan-offload: off
>>>>>tx-vlan-offload: on
>>>> ^^^^^^^^^^^^^^^^^^^ is this gfar?
>>> No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
>>>
>>> /Michael
>>>
>>
>>Ok I would have saved hours of bisecting if I had just used the -e
>>switch with tcpdump from the beginning.
>>Jiri first of all the patch makes the connection work again. I can
>>ping the client on the wlan from the server and vice-versa. Taking a
>>look at the tcpdump (WITH -e) makes it obvious why it fails with the
>>non patched version...
>>
>>This is a capture from the gfar lan port on the bridge with no patch applied
>>12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
>>(oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
>>ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
>>id 23567, seq 74, length 64
>>
>>As you can see we get a VLAN package????
>
> Ugh, this is what I expected. Patch to fix:
>
> Subject: [patch net-2.6] gianfar: prevent buggy hw rx vlan tagging
>
> On some buggy chips, "vlan tag present" flag is set which causes packet
> loss. Fix this by checking if rx vlan accel is enabled in features.
>
> Reported-by: Michael Guntsche <mguntsche@gmail.com>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> ---
> drivers/net/gianfar.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 2659daa..31d5c57 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2710,8 +2710,13 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
> /* Tell the skb what kind of packet this is */
> skb->protocol = eth_type_trans(skb, dev);
>
> - /* Set vlan tag */
> - if (fcb->flags & RXFCB_VLN)
> + /*
> + * There's need to check for NETIF_F_HW_VLAN_RX here.
> + * Even if vlan rx accel is disabled, on some chips
> + * RXFCB_VLN is pseudo randomly set.
> + */
> + if (dev->features & NETIF_F_HW_VLAN_RX &&
> + fcb->flags & RXFCB_VLN)
> __vlan_hwaccel_put_tag(skb, fcb->vlctl);
>
> /* Send the packet up the stack */
> --
> 1.7.6
>
>
Jiri, there seems to be another bug lingering in the bridge code,
which might cause this problem in the first place but I am not really
sure. I looked at the ethtool output some more and I noticed that some
features were enabled on the Bridge which should be off.
With 3.1-rc1
Offload parameters for lan (This is the bridge interface itself):
rx-checksumming: on <---- ON
tx-checksumming: on <---- ON
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: on <---- ON
I booted an older kernel on the same hardware (2.6.39) and the output differs.
Offload parameters for lan:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off
receive-hashing: off
As you can see all the values are OFF which is correct, since no
attached interface supports these features.
Is it possible that this is tripping up the now changed gianfar code somehow?
What I am trying to say. Could it be that your patch is hiding a
problem that is now surfacing with a change in the bridge code?
I am thinking about this commit:
c4d27ef95: bridge: convert br_features_recompute() to ndo_fix_features
Of course this could also be a totally separate bug as well.
Any thoughts, Dave, Stephen?
Kind regards,
Michael Guntsche
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Jiri Pirko @ 2011-08-10 11:59 UTC (permalink / raw)
To: Michael Guntsche
Cc: shemminger, sebastian.belden, netdev, linux-kernel, davem
In-Reply-To: <CAMvAeqOZ9OoV5KxTbn0+sPxJ=AkSrb__31GShVshDkX6NUXgNw@mail.gmail.com>
Wed, Aug 10, 2011 at 01:51:54PM CEST, mguntsche@gmail.com wrote:
>On Wed, Aug 10, 2011 at 1:19 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>> Wed, Aug 10, 2011 at 12:30:16PM CEST, mguntsche@gmail.com wrote:
>>>On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
>>><snip>
>>>>>>Offload parameters for lan_wire:
>>>>>>rx-checksumming: off
>>>>>>tx-checksumming: off
>>>>>>scatter-gather: off
>>>>>>tcp-segmentation-offload: off
>>>>>>udp-fragmentation-offload: off
>>>>>>generic-segmentation-offload: off
>>>>>>generic-receive-offload: on
>>>>>>large-receive-offload: off
>>>>>>rx-vlan-offload: off
>>>>>>tx-vlan-offload: off
>>>>>>ntuple-filters: off
>>>>>>receive-hashing: off
>>>>>>
>>>>>>The Bridge device on the other hand....
>>>>>>
>>>>>>Offload parameters for lan:
>>>>>>rx-checksumming: on
>>>>>>tx-checksumming: on
>>>>>>scatter-gather: off
>>>>>>tcp-segmentation-offload: off
>>>>>>udp-fragmentation-offload: off
>>>>>>generic-segmentation-offload: off
>>>>>>generic-receive-offload: on
>>>>>>large-receive-offload: off
>>>>>>rx-vlan-offload: off
>>>>>>tx-vlan-offload: on
>>>>> ^^^^^^^^^^^^^^^^^^^ is this gfar?
>>>> No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
>>>>
>>>> /Michael
>>>>
>>>
>>>Ok I would have saved hours of bisecting if I had just used the -e
>>>switch with tcpdump from the beginning.
>>>Jiri first of all the patch makes the connection work again. I can
>>>ping the client on the wlan from the server and vice-versa. Taking a
>>>look at the tcpdump (WITH -e) makes it obvious why it fails with the
>>>non patched version...
>>>
>>>This is a capture from the gfar lan port on the bridge with no patch applied
>>>12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
>>>(oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
>>>ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
>>>id 23567, seq 74, length 64
>>>
>>>As you can see we get a VLAN package????
>>
>> Ugh, this is what I expected. Patch to fix:
>>
>> Subject: [patch net-2.6] gianfar: prevent buggy hw rx vlan tagging
>>
>> On some buggy chips, "vlan tag present" flag is set which causes packet
>> loss. Fix this by checking if rx vlan accel is enabled in features.
>>
>> Reported-by: Michael Guntsche <mguntsche@gmail.com>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>> ---
>> drivers/net/gianfar.c | 9 +++++++--
>> 1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
>> index 2659daa..31d5c57 100644
>> --- a/drivers/net/gianfar.c
>> +++ b/drivers/net/gianfar.c
>> @@ -2710,8 +2710,13 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
>> /* Tell the skb what kind of packet this is */
>> skb->protocol = eth_type_trans(skb, dev);
>>
>> - /* Set vlan tag */
>> - if (fcb->flags & RXFCB_VLN)
>> + /*
>> + * There's need to check for NETIF_F_HW_VLAN_RX here.
>> + * Even if vlan rx accel is disabled, on some chips
>> + * RXFCB_VLN is pseudo randomly set.
>> + */
>> + if (dev->features & NETIF_F_HW_VLAN_RX &&
>> + fcb->flags & RXFCB_VLN)
>> __vlan_hwaccel_put_tag(skb, fcb->vlctl);
>>
>> /* Send the packet up the stack */
>> --
>> 1.7.6
>>
>>
>
>Jiri, there seems to be another bug lingering in the bridge code,
>which might cause this problem in the first place but I am not really
>sure. I looked at the ethtool output some more and I noticed that some
>features were enabled on the Bridge which should be off.
>
>With 3.1-rc1
>Offload parameters for lan (This is the bridge interface itself):
>rx-checksumming: on <---- ON
>tx-checksumming: on <---- ON
>scatter-gather: off
>tcp-segmentation-offload: off
>udp-fragmentation-offload: off
>generic-segmentation-offload: off
>generic-receive-offload: on
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: on <---- ON
>
>I booted an older kernel on the same hardware (2.6.39) and the output differs.
>
>Offload parameters for lan:
>rx-checksumming: off
>tx-checksumming: off
>scatter-gather: off
>tcp-segmentation-offload: off
>udp-fragmentation-offload: off
>generic-segmentation-offload: off
>generic-receive-offload: off
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: off
>ntuple-filters: off
>receive-hashing: off
>
>As you can see all the values are OFF which is correct, since no
>attached interface supports these features.
>Is it possible that this is tripping up the now changed gianfar code somehow?
>What I am trying to say. Could it be that your patch is hiding a
>problem that is now surfacing with a change in the bridge code?
Well this seems unrelated. The problem is that gianfar hw is indicating
it received vlan tagged packet even in case it did not.
>
>I am thinking about this commit:
>c4d27ef95: bridge: convert br_features_recompute() to ndo_fix_features
>
>Of course this could also be a totally separate bug as well.
>
>Any thoughts, Dave, Stephen?
>
>Kind regards,
>Michael Guntsche
^ permalink raw reply
* [linux-firmware v2 2/2] rtl_nic: add new firmware for RTL8111F
From: Hayes Wang @ 2011-08-10 12:22 UTC (permalink / raw)
To: dwmw2; +Cc: romieu, netdev, Hayes Wang
In-Reply-To: <1312978979-1808-1-git-send-email-hayeswang@realtek.com>
Add new firmware:
1. rtl_nic/rtl8168f-1.fw
version: rtl8168f-1_0.0.1
2. rtl_nic/rtl8168f-2.fw
version: rtl8168f-2_0.0.1
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 2 ++
rtl_nic/rtl8168f-1.fw | Bin 0 -> 2928 bytes
rtl_nic/rtl8168f-2.fw | Bin 0 -> 256 bytes
3 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 rtl_nic/rtl8168f-1.fw
create mode 100644 rtl_nic/rtl8168f-2.fw
diff --git a/WHENCE b/WHENCE
index a463417..7290828 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1627,6 +1627,8 @@ File: rtl_nic/rtl8105e-1.fw
File: rtl_nic/rtl8168e-1.fw
File: rtl_nic/rtl8168e-2.fw
File: rtl_nic/rtl8168e-3.fw (Version: rtl8168e-3_0.0.1)
+File: rtl_nic/rtl8168f-1.fw (Version: rtl8168f-1_0.0.1)
+File: rtl_nic/rtl8168f-2.fw (Version: rtl8168f-2_0.0.1)
Licence:
* Copyright © 2011, Realtek Semiconductor Corporation
diff --git a/rtl_nic/rtl8168f-1.fw b/rtl_nic/rtl8168f-1.fw
new file mode 100644
index 0000000000000000000000000000000000000000..a0dd2e5dec0a73968b26e0d81b4542240dbc719d
GIT binary patch
literal 2928
zcmbuBdx+Fk6vyw(I>$BBd~Le9uCou{kDb|YUG1OMD2%K`h{z;^G!TTMj8rs^u8TUG
zB3VWRvKa)4vxEqRfxC)i`bYQ*l(c@U>w}V60^3#Fb^4sSzgfrdzXmS%ywCTXd+z;>
zbI!fHdR2Y0uKukV$z_R|iJ8fGqP`}Xs7WT#*>4f+c+|NKZt=pp+S<gtWsB#%u<Yr#
zm#<isOeSVMnTRKob8GA7CTF{y&W%?$#;J29F5Bhe?CoxW(}BoqTsd<0PQ<yuxiT|~
ztBbZQcjgyM<bBPy>H*s^4xhNgc2sB^!=^hMQ+1MyZT3?1xDI4}5-HIQ4W)!H$;lit
zi(TmB6yK<5&jQha7(H20Z4qrn7VQ=t6A_IVJwbG*hV*>VrO3@Mnif5Yyg3l<*ebfM
z8JlwW4$<-yGVGcQWgmIj_CnbX(H88EJJBCnMK_-l?W`017@Ov+qM2QyKM^ZaL@wLk
z5N)>|`y=6g*!F><ZMMHB`YC%G__h+m-4y+%6#UScJ3_y_uhn|`9(Kg}eY0pi_NO<%
zgXMC_4}cGDi>C06Q)_0Fr=$2h9|vbZJrhMIbwX!EtDrl<+&fA1_5k0P^mfrv*fyhg
z&?$V@ED_y9J<&m;H)5h2t(Px}uBsIs(Cc&V2y=FiBPRaF*O(nX-%b^sZuC&mL&O<i
z^cSLk%@A!g8r<*a^Y0KHTp?P)c{YPH3V*6mv<$o8b04>o+PaI$Q|b9xrhC)VRe4>N
z=aZ&;#naWM1Ak|==WPzs#E(r7oe<^=;0^o4d>ndY{0xgz=IKfKIP}eQMd*6f_b}kh
zHk$u_?4R&-h0&Zv6Y{vxLp@z(G<9r2UJY$?oS~;>)SaOp<Jd2=uLoyvg+-t0jqU*V
z9MQ2eMdyI!^bkJ>>ni<RSU<nsNFQ6_!?;lqy@G5LIr=91bL(JMZZUhgKA?+I>*SvM
ze5^vW68j!{5=;s4lP^jSzo(w5dD|v>NWVvz?JaDlg*An?A8z9Ou}xj2Pw4w+jhv30
z`TT>(XY;lno1(bSZ8himMy!BYGQ8H$Xpv|!7;?VkA4L9s-%8PuU<tTmx!xA|TF=e5
z5ll9_5AA`?0yxs(djw34(A_t=_nf!YJ|(XwZ!tJ6Z~6v0Y^N6Lz+`b+u(6!e^13bf
zReQgdqh2>1o%QESYA<&5<uvuTp<5@qq26OnWsqav-#_A%7sQF-XXo3xkDPyVCXtXo
z1V0!aT~2=t9z2d^J-EvptnBi-%&($H>2Vjn_jY@I2K@<S_Kpm1^fG&A?43(>h>kzO
z`+)s$X3T16g}3>&IK9XX?_KVN<!Jjy^ceEB(C!TD95qxT2U~T*&u<%No*n7wA&W#`
zeFi+^MK66uZ_bMD;$DroB)WIB=x@aC;%zjny?qbn%8<)2{6d}f%}LSEE^6;uOFm*g
zEMJ;@QO-HL#@9CXr070s=;E$jAiu+R+8(fM<n6cf;oR+fBAi#0njRg-dpBHk2z_m1
zzq;Aik$bDbkmobhXxQw|kEDj?uSCxtq%QS!r5{q4y)AYZCfGbL5Z#Tx^?$wLBK9nB
z<z|Fl<aXpXn;nP2Vz!rg1KRy}Xf}D%tH~Glwnd@OcjjYrhFxwy!nwAJUMun6vD9@i
zBg+&&_+9IB56)5?AH(#2RuF)l7!h`Ra|7PS2I`OZ(63HvY7k8zvu~lDTg7B-%qI@b
zZr{LQOz6|?eKPnwMT~%%NrnCEgm>5n%x>Y_-(kjozKe`?cO^KO)q^jSm+x>n-vZ0K
zpS**~TV}H`R&)`wFxlSR=dfGO8(m=c8g}j!b7OwTxQ`XwakGVQdy#tqh9=JH3|P-|
z{ufI5pTsJ?$YS2N4Ft<J(btKag<dg)d0z?^CwlQ&W)j;2taF#aiY$-G=5rk95!f7%
zx4Vh6;_j86XI;RTSmtZFZXEz4b=v=oJobCc>TYKHN9yil#d`TJ-4Xo*y!KsM@+Wgo
zjB@VTwRkAMjt+UR*)XGh+)YPK4bUAQh%RnmhD=9(w@`F`N6co${xc3^Z*TYypZ_oD
z!vCV#taCWT?Z0UL|K<Jvprc(h7iV<4`4zDq+dBwzPp4`l{j_tX?q1gZr<P(nETo4)
K^Pf1kock9M(ey3=
literal 0
HcmV?d00001
diff --git a/rtl_nic/rtl8168f-2.fw b/rtl_nic/rtl8168f-2.fw
new file mode 100644
index 0000000000000000000000000000000000000000..f8b48c3b5d4d4a040dc9703235bce4799c1fb106
GIT binary patch
literal 256
zcmY+7!3qIU6ox+}+gXsA61S`@n0u~FlO48{Y%OMkl_Gh7c?3&KkK$3hfj7XpBKhld
zPXGV?9e~4en@W;yx-PRl+Y@8cSZpk!nb%yWqqAf&O`NmiY%!W;lig~aiP)rXjmXd?
zLpR_At(=e?YCP{4-B-@!74>79>a#Dv4H_OYImOEg-z(d1*R$<EHbgrHWvd_d$J8l8
a0QIZym;8Ss9#79l>II)Wc<1jQ{PY6x_bUMa
literal 0
HcmV?d00001
--
1.7.3.2
^ permalink raw reply related
* [linux-firmware v2 1/2] rtl_nic: update firmware for RTL8111E-VL
From: Hayes Wang @ 2011-08-10 12:22 UTC (permalink / raw)
To: dwmw2; +Cc: romieu, netdev, Hayes Wang
Updated firmware with stability fixes.
Version: rtl8168e-3_0.0.1.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 2 +-
rtl_nic/rtl8168e-3.fw | Bin 2804 -> 3264 bytes
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/WHENCE b/WHENCE
index 4b88f1f..a463417 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1626,7 +1626,7 @@ File: rtl_nic/rtl8168d-2.fw
File: rtl_nic/rtl8105e-1.fw
File: rtl_nic/rtl8168e-1.fw
File: rtl_nic/rtl8168e-2.fw
-File: rtl_nic/rtl8168e-3.fw
+File: rtl_nic/rtl8168e-3.fw (Version: rtl8168e-3_0.0.1)
Licence:
* Copyright © 2011, Realtek Semiconductor Corporation
diff --git a/rtl_nic/rtl8168e-3.fw b/rtl_nic/rtl8168e-3.fw
index cb494071d0273c7b3102b97552f4bc7b756c0e17..43d1b8641fb09d2f8dd91998ed78c1deb7c71a7a 100644
GIT binary patch
literal 3264
zcmaKvYiyKd7RR4XJEv1F2Cx-|%P_rAM4+9iSgT*G$Qn#^V@Nhxb+hmRKA3FcMoAX$
zr$R?<l^E|avDV%FqB0d(q94pMd@!2qCYvonBD=bIr?%kknwf+^%cW)foq68TS3{iS
z&3T^loXh{*p7$N+oO^Kh@A|U6eY-YZzdh5H>B^=vz1=-M-PtT>_Pd*BdA)N<x9!f}
zo@{3G_HDP`wf(jScJA7q&1QPDnRIs3%{_fLXEW{v=T@s*=G3_sS1G$R^r+kFv=M%{
zOTl-)uX8SNZlwvO)x}14I@611YPu%d{v+9?4xO|^wmFoIBQsrzt2(LLHhHPPMjLtF
zcP+Z3KdA?yZckD_F#1GN4?zz;nAE@6{>h{sw*5m%t*dL%xJzn1v>qCV&SjD+(3v-r
z+6euWJ+V}MIDEt`&hXjMy0nU+9}Ep{nI3OirVjs;MiWUrYqXNohIyXfY;-|VJB-5L
zZFCyB<^H^31r)tzqjSg^#oi{P=xqu4FB?U#iX(!-fx&pu962RdG0~Z=q5(OZsfg;R
z=oq}%v}jA6Xq~OwL`OAT-y(VseAA2lRrFu*hXc{#GosH9Ba>oZ6ip4mLvA?Ad(QKo
zkMj0o8@bP%=*MHC1II-tkBPpB%<z=x_)DUNdeQbl(HrqO-p(G{8SYE$6FJcmGV_e?
z5M5*xdy7MQ1T3XS^o%|v`U=!+JcAGSt>`;R(HB^kE(rbObuAa;myyHH@~CgHt_t@J
z_zupC4xyXQqu1=$F?8NoO&kI7c8ac@WL+W#){|4Bvuj1qH~75epBHUTv*z5f9zti&
zy`m$;6KfLvcU<%-%k`t8*&fk`S?_ay=yQ4%Hqp2JfXV$v^zZ9MH`;og=wa+M*!mUG
zzjcZ3v-M}957hkc7oFcK+Dg5L!5L$}iL({R1>bnPZNxSWj>$H^w|eK1OAvp1L~ms_
zjES>&hiFH57O*#bYif4Z{KO7<>5SMpw=rUeT&<0qJ!0{YgA3%nd=ZTIi#{FZ;@B=<
zum5(7_JTi!UV+%oh5H5UQ;R+Ce3ZAu^DaesS9{)T)X{8Jb*Zn}OAkhP*MI@ubM#aU
z*|rgCc#8bc>&@gNL(FA-{u&!23*gg-iC*~BxZy44WgNXRY7gx$us%ahZxnsCEILR3
z)nfezv0A(riMNg!Is7ZIaK0hLa)8+8Un@FjHmLhFKCV5$EZ>3LPSJG{x%-fF|MY!z
zU<b7Vf1AmIvG7aLPpEJ1i0Com{eoUN$$T{OB){bOia95S^0T79#cqZ5u7&h7eV1~g
zU*0bI6|#qTj!%FUUJaAQwTf5+Y!^NuKRM!K){|fGoJ1E}rfa^=9s(nA+WZ-IoBhl5
zo8{$G;<ntx>4S+2qW=SL@U`f@|EEsaNYNvw(joseXYglDrik90pS=LR0s5wsxP#?>
z-D+!M9<+Y4^;Le|ZtH~avkumlr&5pT%1J2sSp}VdJ{IB#9vAHk{pD|Bmbyf5q7TN&
zQ=v}u1o^gjV#IUoDe6W}`a-)g5nZxZbT8*~)+5ANq}R{VU)8xAAns1;#re#i!9^`C
zj#li);@oA}TsITSlD9Z{Xg1mRki9O9CzL(CM09;k_Gx50yx*A*MW;4+pSAm@nk&;I
zw^QJ+VQFG*ch-TkqV@P{$5-%rm_y`)CU3`bYr2=1tEw*8n!x(KZX0o%E<JAZ+!4{W
z{G0B_d#{|21o_wthCIC#TSMP73pIT6z_*XH>3O_o)^bjc*456zkN~q`$bZ8bve!k=
zz-M+wkum@4YiHytL9TLk24*|kz}e80=-cEW;ru+e+AN;%^K5y{mEa@){oRk9RK!jk
zJ*)fJ1a{9+kGgPwhW&i@oZ0<7MqiHN)A5+yi}c6+%!Qqmh(E?$mC?QYsy{Dr-UQFy
zOZV;byhZe!Gn_y3*t^Z%t+}G;YU((G&Bel=ILFvq@0+h#_!iSeX3B6BF5v_I!>k=O
zu{ln)!3W>B-M;q=?V@Ms1-n}plDm6;0p``r|7-aCT=XSoatU|MAD4>$2ixU}k7qWV
z-<q!yz6`?&a-qbMBj;t4e;9w*ypq2>{$lh(Wsi?-1-<buF_gQw>+tW;T|WYr0s7c#
z*yC$hy{n07!6MOv-02I+eF54%82L5<Lv3&0CWg)Ki>tvj{3p@R4-=RAxbjzs%kCw+
zf9zcuY~{XV?uUxpErtu*H-Kx%`iR<ADSYeS;t{YQo0|~*8hrNcW4X;+9@Ad7KGgXL
zooX*4SEa<Tn0`3b;=i48r@;)b#GM!YmYTzV^*)0Bp<lEgTmd!eX%oGhb#XU2-NH9v
z0H1noJBkfkp9JrnqMM6xi^0Cz7eSBq|72hLK6T;$fl9?W6w>y8p!SV#{{uGL|A2P?
OJ^RD|0{iy%zwZF4*F!x3
literal 2804
zcmaKuS!|S56vyvuXDEwdX=z8WolZ+xrAP=!Vq#-Nc`(M9m<Srf13vJiQ4@-BIfa&`
zMS>d`6R?UeXp0DaGtxc~Ow<@#AOWSxH%JAQw21-A(sulv@B5~F;_~q2-gE9*{^x(s
zJu}W#sjG16T$w8jxh!jsTkSNBzTQ=$cQ3}A^PHP)Mp<?7_Vv!~b}qHVg}!E6^Ecaa
zhfmgFTN>J?u(?)9sXFmvo4q7vYMSp0SElP4GJ2TRHD>fnTi?j&5!S;mW%Q`YZ)UX1
z<d-uVi<N20Wi-K>U`?@(F3G5{4)4oon)L)SwfH$4IpT&j{MJ>M`xqL)kaQJVo32nd
zmeFOlj%KvBf^`JhR%G8V;^Xi!U9={r)D{;VUM=cT<8VP#+eHtdi(eBhi;2c;pA)Sw
z?jICg!`}SjJ4FwwXqzXR-!8hN4f{&uyl7=BI_%n_I_ypNR#dl3v>n|y<p1iBXwxat
z3;RXi!KQ6MwD(=n?u6*u&7v#F*;|9m`d%mxB1?<tAT|?NyVr?s$Jbp3TSjy@`@tK+
zJ+hL+YU~}uj{Wv%Ov4(=Nn(1}1Dx4T{7QqpakQ4Y5{;rIU`!bYKZ`!FS#&A;k^4li
zCyC>Uc2d{fS<x&!wq3vud0vy~Li71fbpE}>v3-~5`}i!j{kNhoMEoaJi&jVcmvJ@=
zJMWU{F6zpG?OF=Ha)DgTI|2MP5x?2sDxRfkMQg(|4@?$kPBG4$JL1%d)<xo61@m~E
zxuSC;XRpG4azyk7ybaw1;|9@f#5Vr=o)7r`tzL9F_$%@2rnal0JQ=xiTA;fg)lCm{
zx1zckfo^YA5X<-Fek|Uu=7?@47|`wHzT(*CxUbe<xfgn{6h4-KYlxgrgJ=I_^lAEM
zIr_EK@ezI8iy!^ySnIpl{|TonME4Adj?zEHT7RHctM?}L#^~Lyr@+Gbhar|uYI}5^
zXtTxG%YBh!UWe$9&mhxJ)tmW{JGe)CXOEN9!}i#5aBd|}pJ?U`-&xUfVC<)-(|kL2
zh^_}q`Z>`l1<_~W*uniHmDrx+>lZzL1Ra>VW1@S(WAEn>y>aXw(c|>!R`T@0-I=85
z*)VR=_XxR8UBMrWMeJ7p5Vei%;X6UUk8<DO_Rfp`^1J9C#7x6q0zR|g@ZkGmsP{O_
z(;uU(N%I4%^-@O@@1*YbzLY!j^(~@zWpD4Tr+xi4c&g>S!PA97V$BX$YVvWsCi*&Y
z{e1U}u4KQMyY8F?Pb-6at+u;39o*+;<AfR0F$o>^LR{0uPx98b1U1^5Zp{-DKAPz1
zI^xBt`_mkEIUL~Xq>dEWYw#UDi0ypQmazZL_H%e%P_(7C6!lCu+l$yP4Bkp@7<VIi
z7h&5vKz?$L&lGYb;Hnxwk2AwkjgMC%dWAmE(ns-x=m*3$t~$w60*9^aJBX72-wgA;
z6=180_~t_2o4h&S7oJPtdEA$nTksu$-+$x7n?Nst+n*(tgPtG9H&JwAb1*Mb?Ysdy
zkMLu@m%wke_-6|u_&Cc_XQJpA;mZ6RH5ShX76m-GkD2kD*^EC;&DQrL;2-23%|40V
z=DW=&<J_ZHP4CEIcXfa|uF?mwP(F%02{|6hUn3`wE$@g6_^=re-@u#UtYr{i^foI-
zcrV76=^SsW*|5;FzRu%K2ycemu_}6Rzvuun$>b#Qi*bsx#&X;uM+^NsM4Y}&<Redx
zFHQ~qoVpzJ^$hEAW|qyHRZ~Q()-VIWbF!cJ1~>im{8Vz-`~JVLoPJ1tB3k(VpR;cq
z549yM4sWVk$qW8X<XXk|Uzp~?dm}aE3&HPpjQ6?tvjF3!v&>}THF4M7;BBXOiog9s
zF>vEIZ8AI_W~DZNKJ5$Yws{?ujYFHW#^(WkJG!`Y<!z7G1&-)U&tto>L9`)HUyyrg
zPV@=(`B&iJVbPyF^k9Cnhkmj>Slwfy59L$Fqy2}R%G%R#hg|&c<--4_g@POZZ(97n
VdHX+Uxf?6kf6?+D|9>1#e*sYqwB!H)
--
1.7.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox