* Re: [PATCH resend] can: c_can: Fix tx_bytes accounting
From: Kurt Van Dijck @ 2011-03-24 10:49 UTC (permalink / raw)
To: Jan Altenberg
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Wolfgang Grandegger,
b.spranger-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org
In-Reply-To: <1300966010.3295.40.camel@localhost>
On Thu, Mar 24, 2011 at 12:26:50PM +0100, Jan Altenberg wrote:
> The current SocketCAN implementation for the Bosch c_can cell doesn't
> account the TX bytes correctly, because it calls
> c_can_inval_msg_object() (which clears the msg ctrl register) before
> reading the DLC value:
>
> The fix is quite easy: Just move c_can_inval_msg_object() to the end of
> the if() statement. So:
> * We only call c_can_inval_msg_object() if the message was
> actually transmitted
> * We read out the DLC value _before_ clearing the msg ctrl
> register
>
> Signed-off-by: Jan Altenberg <jan-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Acked-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
I cut the description a bit, to what I would have found sufficient.
^ permalink raw reply
* Re: RFC: [PATCH] can: c_can: disable one shot mode until driver is fixed
From: Kurt Van Dijck @ 2011-03-24 10:52 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D8B209E.5010907-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Thu, Mar 24, 2011 at 11:44:46AM +0100, Marc Kleine-Budde wrote:
> On 03/24/2011 11:28 AM, Kurt Van Dijck wrote:
> > On Thu, Mar 24, 2011 at 11:12:29AM +0100, Marc Kleine-Budde wrote:
> >> This patch disables the one shot mode, until the driver has been fixed and
> >> tested to support it.
> >>
> > isn't this part necessary now (temporarily) to avoid dead code?
>
> It's not necessary, the driver should still work.
Yep, I saw that.
> But it's dead code. If
> someone fixes the driver she/he can easily revert the patch.
>
> Can I fold your patch and add your S-o-b?
Yes.
>
Kurt
^ permalink raw reply
* [PATCH v2] can: c_can: disable one shot mode until driver is fixed
From: Marc Kleine-Budde @ 2011-03-24 11:00 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
jan-hfZtesqFncYOwBW4kG4KsQ
This patch disables the one shot mode, until the driver has been fixed and
tested to support it.
> I'm quite sure I've seen a situation where msg_obj 17 "seemed" to be
> pending, while msg_obj 18 and 19 already have been transmitted. But
> in that case, I enabled ONESHOT for the can interface, which enables
> the DA mode (automatic retransmission is disabled).
Reported-by: Jan Altenberg <jan-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Cc: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
---
Changes since v1:
* remove code to enable CAN_CTRLMODE_ONE_SHOT entirely
(thanks Kurt)
drivers/net/can/c_can/c_can.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 110eda0..d0bffb0 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -588,14 +588,9 @@ static void c_can_chip_config(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
- if (priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT)
- /* disable automatic retransmission */
- priv->write_reg(priv, &priv->regs->control,
- CONTROL_DISABLE_AR);
- else
- /* enable automatic retransmission */
- priv->write_reg(priv, &priv->regs->control,
- CONTROL_ENABLE_AR);
+ /* enable automatic retransmission */
+ priv->write_reg(priv, &priv->regs->control,
+ CONTROL_ENABLE_AR);
if (priv->can.ctrlmode & (CAN_CTRLMODE_LISTENONLY &
CAN_CTRLMODE_LOOPBACK)) {
@@ -1112,8 +1107,7 @@ struct net_device *alloc_c_can_dev(void)
priv->can.bittiming_const = &c_can_bittiming_const;
priv->can.do_set_mode = c_can_set_mode;
priv->can.do_get_berr_counter = c_can_get_berr_counter;
- priv->can.ctrlmode_supported = CAN_CTRLMODE_ONE_SHOT |
- CAN_CTRLMODE_LOOPBACK |
+ priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
CAN_CTRLMODE_LISTENONLY |
CAN_CTRLMODE_BERR_REPORTING;
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH resend] can: c_can: Fix tx_bytes accounting
From: Wolfgang Grandegger @ 2011-03-24 11:49 UTC (permalink / raw)
To: Jan Altenberg, Bhupesh SHARMA,
b.spranger-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "
In-Reply-To: <20110324104925.GB339-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
On 03/24/2011 11:49 AM, Kurt Van Dijck wrote:
> On Thu, Mar 24, 2011 at 12:26:50PM +0100, Jan Altenberg wrote:
>> The current SocketCAN implementation for the Bosch c_can cell doesn't
>> account the TX bytes correctly, because it calls
>> c_can_inval_msg_object() (which clears the msg ctrl register) before
>> reading the DLC value:
>>
>> The fix is quite easy: Just move c_can_inval_msg_object() to the end of
>> the if() statement. So:
>> * We only call c_can_inval_msg_object() if the message was
>> actually transmitted
>> * We read out the DLC value _before_ clearing the msg ctrl
>> register
>>
>> Signed-off-by: Jan Altenberg <jan-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> Acked-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v2] can: c_can: disable one shot mode until driver is fixed
From: Wolfgang Grandegger @ 2011-03-24 11:56 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, jan-hfZtesqFncYOwBW4kG4KsQ
In-Reply-To: <1300964453-2634-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 03/24/2011 12:00 PM, Marc Kleine-Budde wrote:
> This patch disables the one shot mode, until the driver has been fixed and
> tested to support it.
>
>> I'm quite sure I've seen a situation where msg_obj 17 "seemed" to be
>> pending, while msg_obj 18 and 19 already have been transmitted. But
>> in that case, I enabled ONESHOT for the can interface, which enables
>> the DA mode (automatic retransmission is disabled).
>
> Reported-by: Jan Altenberg <jan-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
> Cc: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
I agree, ONESHOT mode is tricky and needs more thoughts and testing. I
remember some ugly principle problems with the MCP251x.
Wolfgang.
^ permalink raw reply
* [PATCH 1/2 V3] can: c_can: disable one shot mode until driver is fixed
From: Marc Kleine-Budde @ 2011-03-24 12:34 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: jan-hfZtesqFncYOwBW4kG4KsQ, Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, David Miller
In-Reply-To: <1300970073-25522-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
This patch disables the one shot mode, until the driver has been fixed and
tested to support it.
> I'm quite sure I've seen a situation where msg_obj 17 "seemed" to be
> pending, while msg_obj 18 and 19 already have been transmitted. But
> in that case, I enabled ONESHOT for the can interface, which enables
> the DA mode (automatic retransmission is disabled).
Reported-by: Jan Altenberg <jan-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Cc: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
---
Changes since v2: add Wolfgang's Ack.
drivers/net/can/c_can/c_can.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 110eda0..d0bffb0 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -588,14 +588,9 @@ static void c_can_chip_config(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
- if (priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT)
- /* disable automatic retransmission */
- priv->write_reg(priv, &priv->regs->control,
- CONTROL_DISABLE_AR);
- else
- /* enable automatic retransmission */
- priv->write_reg(priv, &priv->regs->control,
- CONTROL_ENABLE_AR);
+ /* enable automatic retransmission */
+ priv->write_reg(priv, &priv->regs->control,
+ CONTROL_ENABLE_AR);
if (priv->can.ctrlmode & (CAN_CTRLMODE_LISTENONLY &
CAN_CTRLMODE_LOOPBACK)) {
@@ -1112,8 +1107,7 @@ struct net_device *alloc_c_can_dev(void)
priv->can.bittiming_const = &c_can_bittiming_const;
priv->can.do_set_mode = c_can_set_mode;
priv->can.do_get_berr_counter = c_can_get_berr_counter;
- priv->can.ctrlmode_supported = CAN_CTRLMODE_ONE_SHOT |
- CAN_CTRLMODE_LOOPBACK |
+ priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
CAN_CTRLMODE_LISTENONLY |
CAN_CTRLMODE_BERR_REPORTING;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] can: c_can_platform: fix irq check in probe
From: Marc Kleine-Budde @ 2011-03-24 12:34 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
jan-hfZtesqFncYOwBW4kG4KsQ, David Miller
In-Reply-To: <1300970073-25522-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
This patch fixes the check in the probe function whether a IRQ was supplied
to the driver. The original driver check the irq "struct resource *" against
<= 0. Use "platform_get_irq" instead.
Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
---
drivers/net/can/c_can/c_can_platform.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index e629b96..cc90824 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -73,7 +73,8 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
void __iomem *addr;
struct net_device *dev;
struct c_can_priv *priv;
- struct resource *mem, *irq;
+ struct resource *mem;
+ int irq;
#ifdef CONFIG_HAVE_CLK
struct clk *clk;
@@ -88,8 +89,8 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
/* get the platform data */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!mem || (irq <= 0)) {
+ irq = platform_get_irq(pdev, 0);
+ if (!mem || irq <= 0) {
ret = -ENODEV;
goto exit_free_clk;
}
@@ -117,7 +118,7 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
- dev->irq = irq->start;
+ dev->irq = irq;
priv->regs = addr;
#ifdef CONFIG_HAVE_CLK
priv->can.clock.freq = clk_get_rate(clk);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/2] can: c_can: disable one shot mode and fix irq check
From: Marc Kleine-Budde @ 2011-03-24 12:34 UTC (permalink / raw)
To: netdev; +Cc: Socketcan-core, jan, David Miller
Hello David,
can you please pick up these two bug fix patches for net-2.6/master.
I'd like to see them in 2.6.39. In the first patch we disables the one
shot mode which causes problems in the drivers tx logic. The second
patch fixes the check for a valid irq in the probe function.
regards, Marc
^ permalink raw reply
* Re: bnx2 vlan issue
From: Seblu @ 2011-03-24 12:58 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev
In-Reply-To: <AANLkTi=D9Qw+Tw7wHb2T7UG_o9zkZcr2meHE3fwcMwvF@mail.gmail.com>
On Wed, Mar 23, 2011 at 12:19 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Tue, Mar 22, 2011 at 3:59 AM, Seblu <seblu@seblu.net> wrote:
>> On Tue, Mar 22, 2011 at 3:05 AM, Jesse Gross <jesse@nicira.com> wrote:
>>> On Thu, Mar 17, 2011 at 4:22 PM, Seblu <seblu@seblu.net> wrote:
>>>> On Thu, Mar 17, 2011 at 8:16 PM, Jesse Gross <jesse@nicira.com> wrote:
>>>>> On Thu, Mar 17, 2011 at 11:02 AM, Seblu <seblu@seblu.net> wrote:
>>>>>> On Thu, Mar 17, 2011 at 3:51 PM, Seblu <seblu@seblu.net> wrote:
>>>> How can I create a bridge with the untagged vlan from an interface?
>>>>
>>>>> * bridge on interface, vlans on bridge device. This gives you a
>>>>> bridge with all packets and vlan devices can give you specific vlans.
>>>> I cannot use this schema, i used bridge to bring together vnet
>>>> interface and vlan interface.
>>>
>>> I'm not sure I understand why you say you can't use this. You can
>>> combine vlans and bridging pretty much arbitrarily, including stacking
>>> multiple layers.
>> I don't see _how I can bridge an interface with an untagged vlan from
>> another interface_.
>>
>> I little example is maybe more clear:
>> My dekstop have 2 NIC (eth0, eth1). I receive from network admin 2
>> vlans. 20 untag and 21 tagged. My laptop is plugged to eth1.
>> I want "export" untagged vlan 20 to eth1.
>> Before 2.6.37, i do something like br0 = (eth0 + eth1). I put an ip on
>> br0 and on eth0.21. And br0 just have untagged frame from eth0 which
>> was transmitted to eth1. eth0.21 have only tagged frame from vlan 21.
>> eth1 did not receive tagged vlan 21.
>> After 2.6.37, i can do a bridge like before (br0 = eth0 + eth1) but i
>> must use br0.21 to have access to vlan 21 network in my desktop. But,
>> my laptop can also access to tagged vlan 21, and i don't want this.
>>
>> A lot of old xen based setup use this behaviour.
>> About my kvm test, I'm looking to the pci passtrough and macvtap, but
>> this requires configuration that supports it.
>> Why cannot have a eth0.U with only untagged frames?
>>
>>>
>>>>
>>>>> * Use ebtables rules in the bridge to accept/reject certain packets as desired.
>>>> I don't see how use ebtables to push untagged frame to a dedicated
>>>> iface which can be added in a bridge.
>>>
>>> You could have a bridge on the raw interface and connect all of the
>>> VMs that need untagged traffic. If you add an ebtables rule to reject
>>> tagged traffic then vlan devices on the interface will continue to
>>> work as before.
>>>
>> If I ignores the fact that the name of the card is not fixed, i see.
>> But performance will follow? I don't believe this kind of config will
>> allow ~7/8Gbit/s of traffic.
>> Traversing ebtables rules is not free. And starting filtering traffic
>> is a really different job than just bridge cards together.
>
> I don't necessarily disagree that there should be a better way to do
> this, though as of the moment the above is probably your best bet.
>
> To me, the most important thing is to have consistent behavior across
> different cards.
Speaking of that, i've tryed 2.6.38 on my station (dell opitplex 980)
to use the new bridging schema and it doesn't work.
Exactly the case previously described: ip on br0 (eth0+eth1) and ip on
br0.42. eth0 driver is e1000e and eth1 is tg3. br0.42 don't receive
traffic.
I have to open a bug report?
> In 2.6.37 that behavior was standardized on the way
> non-accelerated NICs used to do but the other way is more common and
> perhaps better. Eric B. posted a patch yesterday that better unifies
> the code paths. This would be the first step to such a change because
> it would make it easier to move the handling logic for both at the
> same time.
Agree it's going in the right direction, but it's sad that breaks
basic network concept. Therefore hope in future versions.
Regards,
--
Sébastien Luttringer
www.seblu.net
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Arnd Bergmann @ 2011-03-24 13:13 UTC (permalink / raw)
To: Ben Hutchings
Cc: Steve Calfee, Michal Nazarewicz, Randy Dunlap, broonie, lkml,
Nicolas Pitre, Greg KH, David Brownell, Alan Cox, grant.likely,
Linux USB list, andy.green, netdev, Benjamin Herrenschmidt,
roger.quadros, Jaswinder Singh
In-Reply-To: <1300924878.2638.38.camel@bwh-desktop>
On Thursday 24 March 2011, Ben Hutchings wrote:
> On Wed, 2011-03-23 at 16:38 -0700, Steve Calfee wrote:
> > On 03/23/11 16:17, Michal Nazarewicz wrote:
> > >>> On Wednesday 23 March 2011 20:53:13 Michał Nazarewicz wrote:
> > >>>> I think P2P could be better.
> > >>
> > >> OTOH, I knew that PTP was point-to-point.
> > >
> > > It can be any of that, depending on context. For me PTP is more like
> > > Picture Transport Protocol, whereas "2" between two letters is usually
> > > "to".
> > >
> > Well, my 2 cents, picture transport protocol is so obviously different
> > than flags for network interfaces it does not cause a mental collision.
>
> PTP is also Precision Time Protocol, which *is* used on network
> interfaces (maybe not USB-connected interfaces though).
>
> How about FLAG_NON_IEEE, meaning that the physical layer is not based on
> an IEEE 802.3, 802.11 or other standard physical layer.
I think that doesn't really express the meaning, since FLAG_WWAN is
presumably also not IEEE, right?
Thanks for the bike shedding everyone, I'll just use my own color then
and call it FLAG_POINTTOPOINT.
Arnd
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Arnd Bergmann @ 2011-03-24 13:15 UTC (permalink / raw)
To: Ben Hutchings
Cc: Steve Calfee, Michal Nazarewicz, Randy Dunlap, broonie, lkml,
Nicolas Pitre, Greg KH, David Brownell, Alan Cox, grant.likely,
Linux USB list, andy.green, netdev, Benjamin Herrenschmidt,
roger.quadros, Jaswinder Singh, patches
In-Reply-To: <201103241413.54599.arnd@arndb.de>
The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.
Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().
Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.
The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_PTP setting in the usbnet
driver_info. A driver can set both FLAG_PTP and FLAG_ETHER if
it is not sure (e.g. cdc_ether), or just one of the two.
The usbnet framework only looks at the MAC address for device
naming if both flags are set, otherwise it trusts the flag.
Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Cc: Andy Green <andy.green@linaro.org>
Cc: patches@linaro.org
---
drivers/net/usb/cdc_eem.c | 2 +-
drivers/net/usb/cdc_ether.c | 2 +-
drivers/net/usb/cdc_ncm.c | 2 +-
drivers/net/usb/cdc_subset.c | 8 ++++++++
drivers/net/usb/gl620a.c | 2 +-
drivers/net/usb/net1080.c | 2 +-
drivers/net/usb/plusb.c | 2 +-
drivers/net/usb/rndis_host.c | 2 +-
drivers/net/usb/usbnet.c | 3 ++-
drivers/net/usb/zaurus.c | 8 ++++----
include/linux/usb/usbnet.h | 2 ++
11 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c
index 5f3b976..8f12854 100644
--- a/drivers/net/usb/cdc_eem.c
+++ b/drivers/net/usb/cdc_eem.c
@@ -340,7 +340,7 @@ next:
static const struct driver_info eem_info = {
.description = "CDC EEM Device",
- .flags = FLAG_ETHER,
+ .flags = FLAG_ETHER | FLAG_POINTTOPOINT,
.bind = eem_bind,
.rx_fixup = eem_rx_fixup,
.tx_fixup = eem_tx_fixup,
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 9a60e41..98b2bbd 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -450,7 +450,7 @@ static int cdc_manage_power(struct usbnet *dev, int on)
static const struct driver_info cdc_info = {
.description = "CDC Ethernet Device",
- .flags = FLAG_ETHER,
+ .flags = FLAG_ETHER | FLAG_POINTTOPOINT,
// .check_connect = cdc_check_connect,
.bind = cdc_bind,
.unbind = usbnet_cdc_unbind,
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 7113168..967371f 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1237,7 +1237,7 @@ static int cdc_ncm_manage_power(struct usbnet *dev, int status)
static const struct driver_info cdc_ncm_info = {
.description = "CDC NCM",
- .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET,
+ .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET,
.bind = cdc_ncm_bind,
.unbind = cdc_ncm_unbind,
.check_connect = cdc_ncm_check_connect,
diff --git a/drivers/net/usb/cdc_subset.c b/drivers/net/usb/cdc_subset.c
index ca39ace..fc5f13d 100644
--- a/drivers/net/usb/cdc_subset.c
+++ b/drivers/net/usb/cdc_subset.c
@@ -89,6 +89,7 @@ static int always_connected (struct usbnet *dev)
static const struct driver_info ali_m5632_info = {
.description = "ALi M5632",
+ .flags = FLAG_POINTTOPOINT,
};
#endif
@@ -110,6 +111,7 @@ static const struct driver_info ali_m5632_info = {
static const struct driver_info an2720_info = {
.description = "AnchorChips/Cypress 2720",
+ .flags = FLAG_POINTTOPOINT,
// no reset available!
// no check_connect available!
@@ -132,6 +134,7 @@ static const struct driver_info an2720_info = {
static const struct driver_info belkin_info = {
.description = "Belkin, eTEK, or compatible",
+ .flags = FLAG_POINTTOPOINT,
};
#endif /* CONFIG_USB_BELKIN */
@@ -157,6 +160,7 @@ static const struct driver_info belkin_info = {
static const struct driver_info epson2888_info = {
.description = "Epson USB Device",
.check_connect = always_connected,
+ .flags = FLAG_POINTTOPOINT,
.in = 4, .out = 3,
};
@@ -173,6 +177,7 @@ static const struct driver_info epson2888_info = {
#define HAVE_HARDWARE
static const struct driver_info kc2190_info = {
.description = "KC Technology KC-190",
+ .flags = FLAG_POINTTOPOINT,
};
#endif /* CONFIG_USB_KC2190 */
@@ -200,16 +205,19 @@ static const struct driver_info kc2190_info = {
static const struct driver_info linuxdev_info = {
.description = "Linux Device",
.check_connect = always_connected,
+ .flags = FLAG_POINTTOPOINT,
};
static const struct driver_info yopy_info = {
.description = "Yopy",
.check_connect = always_connected,
+ .flags = FLAG_POINTTOPOINT,
};
static const struct driver_info blob_info = {
.description = "Boot Loader OBject",
.check_connect = always_connected,
+ .flags = FLAG_POINTTOPOINT,
};
#endif /* CONFIG_USB_ARMLINUX */
diff --git a/drivers/net/usb/gl620a.c b/drivers/net/usb/gl620a.c
index dcd57c3..c4cfd1d 100644
--- a/drivers/net/usb/gl620a.c
+++ b/drivers/net/usb/gl620a.c
@@ -193,7 +193,7 @@ static int genelink_bind(struct usbnet *dev, struct usb_interface *intf)
static const struct driver_info genelink_info = {
.description = "Genesys GeneLink",
- .flags = FLAG_FRAMING_GL | FLAG_NO_SETINT,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_GL | FLAG_NO_SETINT,
.bind = genelink_bind,
.rx_fixup = genelink_rx_fixup,
.tx_fixup = genelink_tx_fixup,
diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index ba72a72..01db460 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -560,7 +560,7 @@ static int net1080_bind(struct usbnet *dev, struct usb_interface *intf)
static const struct driver_info net1080_info = {
.description = "NetChip TurboCONNECT",
- .flags = FLAG_FRAMING_NC,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_NC,
.bind = net1080_bind,
.reset = net1080_reset,
.check_connect = net1080_check_connect,
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 08ad269..823c537 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -96,7 +96,7 @@ static int pl_reset(struct usbnet *dev)
static const struct driver_info prolific_info = {
.description = "Prolific PL-2301/PL-2302",
- .flags = FLAG_NO_SETINT,
+ .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset = pl_reset,
};
diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index dd8a4ad..5994a25 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -573,7 +573,7 @@ EXPORT_SYMBOL_GPL(rndis_tx_fixup);
static const struct driver_info rndis_info = {
.description = "RNDIS device",
- .flags = FLAG_ETHER | FLAG_FRAMING_RN | FLAG_NO_SETINT,
+ .flags = FLAG_ETHER | FLAG_POINTTOPOINT | FLAG_FRAMING_RN | FLAG_NO_SETINT,
.bind = rndis_bind,
.unbind = rndis_unbind,
.status = rndis_status,
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 95c41d5..c5b6cfb 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1376,7 +1376,8 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
// else "eth%d" when there's reasonable doubt. userspace
// can rename the link if it knows better.
if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
- (net->dev_addr [0] & 0x02) == 0)
+ ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 ||
+ (net->dev_addr [0] & 0x02) == 0))
strcpy (net->name, "eth%d");
/* WLAN devices should always be named "wlan%d" */
if ((dev->driver_info->flags & FLAG_WLAN) != 0)
diff --git a/drivers/net/usb/zaurus.c b/drivers/net/usb/zaurus.c
index 3eb0b16..241756e 100644
--- a/drivers/net/usb/zaurus.c
+++ b/drivers/net/usb/zaurus.c
@@ -102,7 +102,7 @@ static int always_connected (struct usbnet *dev)
static const struct driver_info zaurus_sl5x00_info = {
.description = "Sharp Zaurus SL-5x00",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -112,7 +112,7 @@ static const struct driver_info zaurus_sl5x00_info = {
static const struct driver_info zaurus_pxa_info = {
.description = "Sharp Zaurus, PXA-2xx based",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -122,7 +122,7 @@ static const struct driver_info zaurus_pxa_info = {
static const struct driver_info olympus_mxl_info = {
.description = "Olympus R1000",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -258,7 +258,7 @@ bad_desc:
static const struct driver_info bogus_mdlm_info = {
.description = "pseudo-MDLM (BLAN) device",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
.check_connect = always_connected,
.tx_fixup = zaurus_tx_fixup,
.bind = blan_mdlm_bind,
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 44842c8..1ef9aa0 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -97,6 +97,8 @@ struct driver_info {
#define FLAG_LINK_INTR 0x0800 /* updates link (carrier) status */
+#define FLAG_POINTTOPOINT 0x1000 /* possibly use "usb%d" names */
+
/*
* Indicates to usbnet, that USB driver accumulates multiple IP packets.
* Affects statistic (counters) and short packet handling.
^ permalink raw reply related
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Andy Green @ 2011-03-24 13:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ben Hutchings, Steve Calfee, Michal Nazarewicz, Randy Dunlap,
broonie, lkml, Nicolas Pitre, Greg KH, David Brownell, Alan Cox,
grant.likely, Linux USB list, netdev, Benjamin Herrenschmidt,
roger.quadros, Jaswinder Singh, patches
In-Reply-To: <201103241415.45115.arnd@arndb.de>
On 03/24/2011 01:15 PM, Somebody in the thread at some point said:
> The documentation for the USB ethernet devices suggests that
> only some devices are supposed to use usb0 as the network interface
> name instead of eth0. The logic used there, and documented in
> Kconfig for CDC is that eth0 will be used when the mac address
> is a globally assigned one, but usb0 is used for the locally
> managed range that is typically used on point-to-point links.
>
> Unfortunately, this has caused a lot of pain on the smsc95xx
> device that is used on the popular pandaboard without an
> EEPROM to store the MAC address, which causes the driver to
> call random_ether_address().
>
> Obviously, there should be a proper MAC addressed assigned to
> the device, and discussions are ongoing about how to solve
> this, but this patch at least makes sure that the default
> interface naming gets a little saner and matches what the
> user can expect based on the documentation, including for
> new devices.
>
> The approach taken here is to flag whether a device might be a
> point-to-point link with the new FLAG_PTP setting in the usbnet
> driver_info. A driver can set both FLAG_PTP and FLAG_ETHER if
> it is not sure (e.g. cdc_ether), or just one of the two.
> The usbnet framework only looks at the MAC address for device
> naming if both flags are set, otherwise it trusts the flag.
>
> Signed-off-by: Arnd Bergmann<arnd.bergmann@linaro.org>
> Cc: Andy Green<andy.green@linaro.org>
> Cc: patches@linaro.org
For Panda case at least,
Tested-by: Andy Green <andy.green@linaro.org>
-Andy
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Alan Stern @ 2011-03-24 13:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ben Hutchings, Steve Calfee, Michal Nazarewicz, Randy Dunlap,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, lkml,
Nicolas Pitre, Greg KH, David Brownell, Alan Cox,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Linux USB list,
andy.green-QSEj5FYQhm4dnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
Benjamin Herrenschmidt, roger.quadros-xNZwKgViW5gAvxtiuMwx3w,
Jaswinder Singh, patches-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <201103241415.45115.arnd-r2nGTMty4D4@public.gmane.org>
On Thu, 24 Mar 2011, Arnd Bergmann wrote:
> The documentation for the USB ethernet devices suggests that
> only some devices are supposed to use usb0 as the network interface
> name instead of eth0. The logic used there, and documented in
> Kconfig for CDC is that eth0 will be used when the mac address
> is a globally assigned one, but usb0 is used for the locally
> managed range that is typically used on point-to-point links.
>
> Unfortunately, this has caused a lot of pain on the smsc95xx
> device that is used on the popular pandaboard without an
> EEPROM to store the MAC address, which causes the driver to
> call random_ether_address().
>
> Obviously, there should be a proper MAC addressed assigned to
> the device, and discussions are ongoing about how to solve
> this, but this patch at least makes sure that the default
> interface naming gets a little saner and matches what the
> user can expect based on the documentation, including for
> new devices.
>
> The approach taken here is to flag whether a device might be a
> point-to-point link with the new FLAG_PTP setting in the usbnet
> driver_info. A driver can set both FLAG_PTP and FLAG_ETHER if
You updated the flag name in the patch but not in the description.
> it is not sure (e.g. cdc_ether), or just one of the two.
> The usbnet framework only looks at the MAC address for device
> naming if both flags are set, otherwise it trusts the flag.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Michael S. Tsirkin @ 2011-03-24 14:28 UTC (permalink / raw)
To: Rusty Russell; +Cc: Shirley Ma, Herbert Xu, davem, kvm, netdev
In-Reply-To: <87r59xbbr6.fsf@rustcorp.com.au>
On Thu, Mar 24, 2011 at 11:00:53AM +1030, Rusty Russell wrote:
> > With simply removing the notify here, it does help the case when TX
> > overrun hits too often, for example for 1K message size, the single
> > TCP_STREAM performance improved from 2.xGb/s to 4.xGb/s.
>
> OK, we'll be getting rid of the "kick on full", so please delete that on
> all benchmarks.
>
> Now, does the capacity check before add_buf() still win anything? I
> can't see how unless we have some weird bug.
>
> Once we've sorted that out, we should look at the more radical change
> of publishing last_used and using that to intuit whether interrupts
> should be sent. If we're not careful with ordering and barriers that
> could introduce more bugs.
Right. I am working on this, and trying to be careful.
One thing I'm in doubt about: sometimes we just want to
disable interrupts. Should still use flags in that case?
I thought that if we make the published index 0 to vq->num - 1,
then a special value in the index field could disable
interrupts completely. We could even reuse the space
for the flags field to stick the index in. Too complex?
> Anything else on the optimization agenda I've missed?
>
> Thanks,
> Rusty.
Several other things I am looking at, wellcome cooperation:
1. It's probably a good idea to update avail index
immediately instead of upon kick: for RX
this might help parallelism with the host.
2. Adding an API to add a single buffer instead of s/g,
seems to help a bit.
3. For TX sometimes we free a single buffer, sometimes
a ton of them, which might make the transmit latency
vary. It's probably a good idea to limit this,
maybe free the minimal number possible to keep the device
going without stops, maybe free up to MAX_SKB_FRAGS.
4. If the ring is full, we now notify right after
the first entry is consumed. For TX this is suboptimal,
we should try delaying the interrupt on host.
More ideas, would be nice if someone can try them out:
1. We are allocating/freeing buffers for indirect descriptors.
Use some kind of pool instead?
And we could preformat part of the descriptor.
2. I didn't have time to work on virtio2 ideas presented
at the kvm forum yet, any takers?
--
MST
^ permalink raw reply
* Re: widely supported ZigBee USB hardware?
From: John W. Linville @ 2011-03-24 14:05 UTC (permalink / raw)
To: George Nychis
Cc: linux-wireless, netdev, Sergey Lapin, Dmitry Eremin-Solenikov
In-Reply-To: <AANLkTimi3OYP+MEJDxS+3GQMqVBZvt8hKzPK4T-XbRre@mail.gmail.com>
On Wed, Mar 23, 2011 at 07:49:13PM -0400, George Nychis wrote:
> I am trying to find a widely supported (and available) ZigBee USB
> device with Linux. I understand there are some GPL related issues with
> ZigBee, but there seems to be a couple related drivers available. In
> particular, this device:
> http://www.adaptivem2m.com/zigbee-technology/zigbee-usb-dongle.htm
>
> I could get this, but I wanted to get some general feedback first to
> see if there is something different that is more well updated. It
> seems like the last driver I could find for this was from 2007.
>
> Has anyone had any personal experience with ZigBee and Linux and have
> any advice?
I'm not sure anyone on this list has experience with ZigBee. I know
there is some ieee802.15.4 support in the kernel, but I'm not sure
where that is discussed (other than netdev). Hopefully someone on
the Cc list is aware?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* regression: ip r change mss doesn't work in 2.6.38-git14
From: Alessandro Suardi @ 2011-03-24 15:08 UTC (permalink / raw)
To: linux-kernel, netdev
After fixing the display issue thanks to Chris Wilson, I now have
another problem
(which didn't exist in 2.6.38-git2); most websites outside of my DSL link don't
work properly (connection packet goes through, but the page load times out
within Firefox) unless I do
ip r change default via 192.168.1.1 dev eth1 advmss 1400
This however doesn't change advmss anymore:
[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1 scope link metric 1004
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.8
[root@duff ~]# ip r change default via 192.168.1.1 dev eth1 advmss 1400
[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1 scope link metric 1004
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.8
strace of this operation doesn't appear to show errors in userspace,
which is btw:
[root@duff ~]# ip -V
ip utility, iproute2-ss100804
[root@duff ~]# rpm -qf /sbin/ip
iproute-2.6.35-6.fc14.x86_64
execve("/sbin/ip", ["ip", "r", "change", "default", "via",
"192.168.1.1", "dev", "eth1", "advmss", "1400"], [/* 23 vars */]) = 0
brk(0) = 0x2461000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f79c8d1c000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=101259, ...}) = 0
mmap(NULL, 101259, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f79c8d03000
close(3) = 0
open("/lib64/libresolv.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p8`12\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=113832, ...}) = 0
mmap(0x3231600000, 2202280, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3231600000
mprotect(0x3231617000, 2093056, PROT_NONE) = 0
mmap(0x3231816000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x3231816000
mmap(0x3231818000, 6824, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3231818000
close(3) = 0
open("/lib64/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r
/2\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=22536, ...}) = 0
mmap(0x322f200000, 2109720, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x322f200000
mprotect(0x322f202000, 2097152, PROT_NONE) = 0
mmap(0x322f402000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x322f402000
close(3) = 0
open("/lib64/libgcc_s.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360(
02\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=89760, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f79c8d02000
mmap(0x3230200000, 2183032, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3230200000
mprotect(0x3230215000, 2093056, PROT_NONE) = 0
mmap(0x3230414000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x3230414000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\357\241.2\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1956608, ...}) = 0
mmap(0x322ea00000, 3781816, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x322ea00000
mprotect(0x322eb91000, 2097152, PROT_NONE) = 0
mmap(0x322ed91000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x191000) = 0x322ed91000
mmap(0x322ed96000, 21688, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x322ed96000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f79c8d01000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f79c8cff000
arch_prctl(ARCH_SET_FS, 0x7f79c8cff720) = 0
mprotect(0x3231816000, 4096, PROT_READ) = 0
mprotect(0x322f402000, 4096, PROT_READ) = 0
mprotect(0x322ed91000, 16384, PROT_READ) = 0
mprotect(0x322e81e000, 4096, PROT_READ) = 0
munmap(0x7f79c8d03000, 101259) = 0
socket(PF_NETLINK, SOCK_RAW, 0) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=4336, groups=00000000}, [12]) = 0
sendto(3, "\24\0\0\0\22\0\1\3\330]\213M\0\0\0\0\0\0\0\0", 20, 0, NULL, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"\344\3\0\0\20\0\2\0\330]\213M\360\20\0\0\0\0\4\3\1\0\0\0I\0\1\0\0\0\0\0"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 3020
brk(0) = 0x2461000
brk(0x2482000) = 0x2482000
brk(0) = 0x2482000
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"\24\0\0\0\3\0\2\0\330]\213M\360\20\0\0\0\0\0\0\1\0\0\0I\0\1\0\0\0\0\0"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 20
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"8\0\0\0\30\0\5\1\331]\213M\0\0\0\0\2\0\0\0\376\3\0\1\0\0\0\0\10\0\5\0"...,
56}], msg_controllen=0, msg_flags=0}, 0) = 56
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"$\0\0\0\2\0\0\0\331]\213M\360\20\0\0\0\0\0\0008\0\0\0\30\0\5\1\331]\213M"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 36
exit_group(0) = ?
Thanks in advance,
--alessandro
"There's always a siren singing you to shipwreck"
(Radiohead, "There There")
^ permalink raw reply
* Re: [Bugme-new] [Bug 28282] New: forwarding turns autoconfiguration off
From: Hadmut Danisch @ 2011-03-24 15:07 UTC (permalink / raw)
To: Francois Romieu
Cc: Bill Fink, David Miller, akpm, netdev, bugzilla-daemon,
bugme-daemon
In-Reply-To: <20110209074221.GA9790@electric-eye.fr.zoreil.com>
Hi all,
since the discussion seems to have completely died, just allow me a
simple question:
How would I configure a Linux machine to accept ipv6 prefix ads (because
they are dynamically assigned and advertised by my router) and to work
as a VPN tunnel end?
Remember: Linux does not allow autoconfiguration and routing at the same
time, without any good reason. The only reason I've seen so far is that
the Terminology in an RFC vaguely distinguishes between router machines
and nodes.
If you believe that Linux is correct here the way it is, just tell me
how to solve that problem with Linux.
best regards
Hadmut
^ permalink raw reply
* Re: [RFC] myri10ge: small rx_done refactoring
From: Stephen Hemminger @ 2011-03-24 15:15 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: netdev, Andrew Gallatin, Brice Goglin
In-Reply-To: <20110324081621.GA5508@redhat.com>
On Thu, 24 Mar 2011 09:16:21 +0100
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Mar 23, 2011 at 08:33:57AM -0700, Stephen Hemminger wrote:
> > On Wed, 23 Mar 2011 13:52:04 +0100
> > Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >
> > > Add lro_enable variable to read NETIF_F_LRO flag only once per napi poll
> > > call. This should fix theoretical race condition with
> > > myri10ge_set_rx_csum() and myri10ge_set_flags() where flag NETIF_F_LRO
> > > can be changed.
> >
> > You may need a barrier or the race may still be there.
>
> I don't understand why barrier in that case is need.
>
> What I tried to avoid is.
>
> myri10ge_clean_rx_done():
>
> if (dev->features & NETIF_F_LRO)
> setup lro
> myri10ge_set_flags()
>
> if (dev->features & NETIF_F_LRO)
> flush lro
>
> Now we read dev->features & NETIF_F_LRO only once to local
> lro_enabled variable. So we can not flush without setup
> or setup without flush. No idea why memory barries is still
> needed.
>
> > The driver seems to use mb() where wmb() is intended, and never use rmb()?
>
> Yes, I think we can have some optimalization here.
>
Without barrier there is no guarantee that compiler read the flags
into a local variable. It is free to do the same thing as the original
code.
--
^ permalink raw reply
* Re: regression: ip r change mss doesn't work in 2.6.38-git14
From: Eric Dumazet @ 2011-03-24 15:21 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: linux-kernel, netdev
In-Reply-To: <AANLkTik6+TrjiC6ZF+KHhZ1iPzEe2jDayr363C0HgQN4@mail.gmail.com>
Le jeudi 24 mars 2011 à 16:08 +0100, Alessandro Suardi a écrit :
> After fixing the display issue thanks to Chris Wilson, I now have
> another problem
> (which didn't exist in 2.6.38-git2); most websites outside of my DSL link don't
> work properly (connection packet goes through, but the page load times out
> within Firefox) unless I do
>
> ip r change default via 192.168.1.1 dev eth1 advmss 1400
>
> This however doesn't change advmss anymore:
>
> [root@duff ~]# ip r
> default via 192.168.1.1 dev eth1
> 169.254.0.0/16 dev eth1 scope link metric 1004
> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.8
> [root@duff ~]# ip r change default via 192.168.1.1 dev eth1 advmss 1400
> [root@duff ~]# ip r
> default via 192.168.1.1 dev eth1
> 169.254.0.0/16 dev eth1 scope link metric 1004
> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.8
Indeed, we'll take a look, thanks for the report.
In the time being you can do :
ip ro change default via 192.168.1.1 dev eth1 advmss 1400 mtu 1500
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Serge E. Hallyn @ 2011-03-24 15:37 UTC (permalink / raw)
To: Eric Paris
Cc: Vasiliy Kulikov, linux-kernel, mjt, arnd, mirqus, netdev,
Ben Hutchings, David Miller, kuznet, pekkas, jmorris, yoshfuji,
kaber, eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm, Greg KH, Stephen Smalley, LSM List,
Daniel J Walsh, David Howells
In-Reply-To: <AANLkTikr=qfFeaXDkiBbK-4KvKS83LzURrUj4L2TP8_u@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8450 bytes --]
Quoting Eric Paris (eparis@parisplace.org):
> On Tue, Mar 1, 2011 at 4:33 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
...
> This patch is causing a bit of a problem in Fedora. The problem lies
Sorry, what exactly is the problem it is causing? I gather it's
spitting out printks? What exactly do the printks say? The patch
included at bottom checks for CAP_NET_ADMIN before checking for
CAP_SYS_MODULE, so these must be cases which historically always
quietly failed, and are now hitting the 'pr_err' which this patch
adds?
If it really is the capable(CAP_SYS_ADMIN) call itself, then there
must be a bug in the no_module logic in the patch. Every
case where it's currently checking for capable(CAP_SYS_ADMIN)
(and potentially auditing a failure) should be one where in the past
it would have (and currently it still would) spit out an audit msg
for the capable(CAP_NET_ADMIN) failure anyway.
If it's just the pr_err that's causing problems, then perhaps we
can turn it into a warn_once?
> mostly in the fact that we, by means of using SELinux, grant very very
> few domains CAP_SYS_MODULE (and we record when domains attempt to use
> this permission). Unlike most other distros in which uid==0 is for
> all intensive purposes == CAP_FULL_SET and there is no logging of
> failures to use capabilities. What happened is that as soon as we
> instituted this change we started getting SELinux denials because lots
> of domains (libvirt, udev, iw, NetworkManager) all the sudden started
> trying to use CAP_SYS_MODULE. It took me a minute to make sure this
> patch was the problem because I wasn't seeing any printk messages. I
> had to make some changes to the patch to print every time a task got
> into the CAP_SYS_MODULE case in order to get an idea what was causing
> the problem. I found on my machine I hit the problem 3 times trying
> to load "reg", "wifi0", and "virbr0" None of these are actual
> modules in userspace so the upcall failed.
>
> I'm trying to figure out how I should be dealing with this.
>
> My first idea is changing the capable(CAP_SYS_MODULE) into a
> has_capability_noaudit(). Which will not audit the access attempt.
> I'm not sure I like that since it uses the read cred, it doesn't set
> PF_SUPERPRIV, and it means we could likely miss recording a problem if
> a task is doing this intentionally...
>
> The next idea is I guess figuring out what's causing these and fix
> them there, but I'm not certain a good way to debug it. I know from
> our audit logs that wpa_supplicant is calling SIOCGIFINDEX which is
> causing one of these, libvirt is calling SIOCGIFFLAGS. I'm not sure
> what udev->iw is doing to trigger it's problem.....
>
> If the name in question is not coming from direct userspace request I
> guess I need help figuring out what is causing them....
>
> So while this patch might not necessarily be breaking things it
> certainly is not regression free and could potentially be breaking
> systems with fine grained capabilities controls....
>
> -Eric
>
> > root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) --
> > root@albatros:~# grep Cap /proc/$$/status
> > CapInh: 0000000000000000
> > CapPrm: fffffff800001000
> > CapEff: fffffff800001000
> > CapBnd: fffffff800001000
> > root@albatros:~# modprobe xfs
> > FATAL: Error inserting xfs
> > (/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted
> > root@albatros:~# lsmod | grep xfs
> > root@albatros:~# ifconfig xfs
> > xfs: error fetching interface information: Device not found
> > root@albatros:~# lsmod | grep xfs
> > root@albatros:~# lsmod | grep sit
> > root@albatros:~# ifconfig sit
> > sit: error fetching interface information: Device not found
> > root@albatros:~# lsmod | grep sit
> > root@albatros:~# ifconfig sit0
> > sit0 Link encap:IPv6-in-IPv4
> > NOARP MTU:1480 Metric:1
> >
> > root@albatros:~# lsmod | grep sit
> > sit 10457 0
> > tunnel4 2957 1 sit
> >
> > For CAP_SYS_MODULE module loading is still relaxed:
> >
> > root@albatros:~# grep Cap /proc/$$/status
> > CapInh: 0000000000000000
> > CapPrm: ffffffffffffffff
> > CapEff: ffffffffffffffff
> > CapBnd: ffffffffffffffff
> > root@albatros:~# ifconfig xfs
> > xfs: error fetching interface information: Device not found
> > root@albatros:~# lsmod | grep xfs
> > xfs 745319 0
> >
> > Reference: https://lkml.org/lkml/2011/2/24/203
> >
> > Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
> > ---
> > v2 - use pr_err()
> > - don't try to load $name if netdev-$name is loaded
> >
> > include/linux/netdevice.h | 3 +++
> > net/core/dev.c | 12 ++++++++++--
> > net/ipv4/ip_gre.c | 2 +-
> > net/ipv4/ipip.c | 2 +-
> > net/ipv6/sit.c | 2 +-
> > 5 files changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index d971346..71caf7a 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -2392,6 +2392,9 @@ extern int netdev_notice(const struct net_device *dev, const char *format, ...)
> > extern int netdev_info(const struct net_device *dev, const char *format, ...)
> > __attribute__ ((format (printf, 2, 3)));
> >
> > +#define MODULE_ALIAS_NETDEV(device) \
> > + MODULE_ALIAS("netdev-" device)
> > +
> > #if defined(DEBUG)
> > #define netdev_dbg(__dev, format, args...) \
> > netdev_printk(KERN_DEBUG, __dev, format, ##args)
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 8ae6631..6561021 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1114,13 +1114,21 @@ EXPORT_SYMBOL(netdev_bonding_change);
> > void dev_load(struct net *net, const char *name)
> > {
> > struct net_device *dev;
> > + int no_module;
> >
> > rcu_read_lock();
> > dev = dev_get_by_name_rcu(net, name);
> > rcu_read_unlock();
> >
> > - if (!dev && capable(CAP_NET_ADMIN))
> > - request_module("%s", name);
> > + no_module = !dev;
> > + if (no_module && capable(CAP_NET_ADMIN))
> > + no_module = request_module("netdev-%s", name);
> > + if (no_module && capable(CAP_SYS_MODULE)) {
> > + if (!request_module("%s", name))
> > + pr_err("Loading kernel module for a network device "
> > +"with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s "
> > +"instead\n", name);
> > + }
> > }
> > EXPORT_SYMBOL(dev_load);
> >
> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> > index 6613edf..d1d0e2c 100644
> > --- a/net/ipv4/ip_gre.c
> > +++ b/net/ipv4/ip_gre.c
> > @@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
> > MODULE_LICENSE("GPL");
> > MODULE_ALIAS_RTNL_LINK("gre");
> > MODULE_ALIAS_RTNL_LINK("gretap");
> > -MODULE_ALIAS("gre0");
> > +MODULE_ALIAS_NETDEV("gre0");
> > diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
> > index 988f52f..a5f58e7 100644
> > --- a/net/ipv4/ipip.c
> > +++ b/net/ipv4/ipip.c
> > @@ -913,4 +913,4 @@ static void __exit ipip_fini(void)
> > module_init(ipip_init);
> > module_exit(ipip_fini);
> > MODULE_LICENSE("GPL");
> > -MODULE_ALIAS("tunl0");
> > +MODULE_ALIAS_NETDEV("tunl0");
> > diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> > index 8ce38f1..d2c16e1 100644
> > --- a/net/ipv6/sit.c
> > +++ b/net/ipv6/sit.c
> > @@ -1290,4 +1290,4 @@ static int __init sit_init(void)
> > module_init(sit_init);
> > module_exit(sit_cleanup);
> > MODULE_LICENSE("GPL");
> > -MODULE_ALIAS("sit0");
> > +MODULE_ALIAS_NETDEV("sit0");
> > --
> > 1.7.0.4
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: regression: ip r change mss doesn't work in 2.6.38-git14
From: Alessandro Suardi @ 2011-03-24 15:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1300980118.3747.42.camel@edumazet-laptop>
On Thu, Mar 24, 2011 at 4:21 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 24 mars 2011 à 16:08 +0100, Alessandro Suardi a écrit :
>> After fixing the display issue thanks to Chris Wilson, I now have
>> another problem
>> (which didn't exist in 2.6.38-git2); most websites outside of my DSL link don't
>> work properly (connection packet goes through, but the page load times out
>> within Firefox) unless I do
>>
>> ip r change default via 192.168.1.1 dev eth1 advmss 1400
>>
>> This however doesn't change advmss anymore:
>>
>> [root@duff ~]# ip r
>> default via 192.168.1.1 dev eth1
>> 169.254.0.0/16 dev eth1 scope link metric 1004
>> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.8
>> [root@duff ~]# ip r change default via 192.168.1.1 dev eth1 advmss 1400
>> [root@duff ~]# ip r
>> default via 192.168.1.1 dev eth1
>> 169.254.0.0/16 dev eth1 scope link metric 1004
>> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.8
>
> Indeed, we'll take a look, thanks for the report.
>
> In the time being you can do :
>
> ip ro change default via 192.168.1.1 dev eth1 advmss 1400 mtu 1500
Thanks - this one works for me.
I'm available to test patches if needed, though I have a feeling you
already have a handle on the issue and won't need that ;)
--alessandro
"There's always a siren singing you to shipwreck"
(Radiohead, "There There")
^ permalink raw reply
* Re: [RFC] myri10ge: small rx_done refactoring
From: Stanislaw Gruszka @ 2011-03-24 15:59 UTC (permalink / raw)
To: Stephen Hemminger, David Howells; +Cc: netdev, Andrew Gallatin, Brice Goglin
In-Reply-To: <20110324081539.47ad0972@nehalam>
On Thu, Mar 24, 2011 at 08:15:39AM -0700, Stephen Hemminger wrote:
> > On Wed, Mar 23, 2011 at 08:33:57AM -0700, Stephen Hemminger wrote:
> > > On Wed, 23 Mar 2011 13:52:04 +0100
> > > Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > >
> > > > Add lro_enable variable to read NETIF_F_LRO flag only once per napi poll
> > > > call. This should fix theoretical race condition with
> > > > myri10ge_set_rx_csum() and myri10ge_set_flags() where flag NETIF_F_LRO
> > > > can be changed.
> > >
> > > You may need a barrier or the race may still be there.
> >
> > I don't understand why barrier in that case is need.
> >
> > What I tried to avoid is.
> >
> > myri10ge_clean_rx_done():
> >
> > if (dev->features & NETIF_F_LRO)
> > setup lro
> > myri10ge_set_flags()
> >
> > if (dev->features & NETIF_F_LRO)
> > flush lro
> >
> > Now we read dev->features & NETIF_F_LRO only once to local
> > lro_enabled variable. So we can not flush without setup
> > or setup without flush. No idea why memory barries is still
> > needed.
> >
> > > The driver seems to use mb() where wmb() is intended, and never use rmb()?
> >
> > Yes, I think we can have some optimalization here.
> >
>
> Without barrier there is no guarantee that compiler read the flags
> into a local variable. It is free to do the same thing as the original
> code.
Ok, so C code like:
code1
if (dev->features & NETIF_F_LRO)
branch1
code2;
if (dev->features & NETIF_F_LRO)
branch2
and
bool lro_enabled = dev->features & NETIF_F_LRO;
code1
if (lro_enabled)
branch1
code2
if (lro_enabled)
branch2
can give the same assembly output.
It's really hard for me to understand that. I could
understand, if we would get global variable directly
like:
bool lro_enabled = dev->lro_enabled;
instead of:
bool lro_enabled = dev->features & NETIF_F_LRO;
David, can you confirm that Staphen is correct?
Also where this barrier() should go. Before
"bool lro_enabled = dev->features & NETIF_F_LRO;"
or after?
Stanislaw
^ permalink raw reply
* Re: regression: ip r change mss doesn't work in 2.6.38-git14
From: Eric Dumazet @ 2011-03-24 16:15 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: linux-kernel, netdev
In-Reply-To: <AANLkTikZhT5LaA-UEXniDvkneH8JScaVaCaCd4LT59cV@mail.gmail.com>
Le jeudi 24 mars 2011 à 16:52 +0100, Alessandro Suardi a écrit :
> On Thu, Mar 24, 2011 at 4:21 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le jeudi 24 mars 2011 à 16:08 +0100, Alessandro Suardi a écrit :
> >> After fixing the display issue thanks to Chris Wilson, I now have
> >> another problem
> >> (which didn't exist in 2.6.38-git2); most websites outside of my DSL link don't
> >> work properly (connection packet goes through, but the page load times out
> >> within Firefox) unless I do
> >>
> >> ip r change default via 192.168.1.1 dev eth1 advmss 1400
> >>
> >> This however doesn't change advmss anymore:
> >>
> >> [root@duff ~]# ip r
> >> default via 192.168.1.1 dev eth1
> >> 169.254.0.0/16 dev eth1 scope link metric 1004
> >> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.8
> >> [root@duff ~]# ip r change default via 192.168.1.1 dev eth1 advmss 1400
> >> [root@duff ~]# ip r
> >> default via 192.168.1.1 dev eth1
> >> 169.254.0.0/16 dev eth1 scope link metric 1004
> >> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.8
> >
> > Indeed, we'll take a look, thanks for the report.
> >
> > In the time being you can do :
> >
> > ip ro change default via 192.168.1.1 dev eth1 advmss 1400 mtu 1500
>
> Thanks - this one works for me.
>
> I'm available to test patches if needed, though I have a feeling you
> already have a handle on the issue and won't need that ;)
;)
I am testing following patch :
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 622ac4c..654ef5b 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -251,7 +251,7 @@ static struct fib_info *fib_find_info(const struct fib_info *nfi)
nfi->fib_prefsrc == fi->fib_prefsrc &&
nfi->fib_priority == fi->fib_priority &&
memcmp(nfi->fib_metrics, fi->fib_metrics,
- sizeof(fi->fib_metrics)) == 0 &&
+ sizeof(u32) * RTAX_MAX) == 0 &&
((nfi->fib_flags ^ fi->fib_flags) & ~RTNH_F_DEAD) == 0 &&
(nfi->fib_nhs == 0 || nh_comp(fi, nfi) == 0))
return fi;
^ permalink raw reply related
* Re: [PATCH 4/4] can: c_can: remove duplicated #include
From: Wolfgang Grandegger @ 2011-03-24 16:15 UTC (permalink / raw)
To: Huang Weiyi
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1300457247-2652-1-git-send-email-weiyi.huang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 03/18/2011 03:07 PM, Huang Weiyi wrote:
> Remove duplicated #include('s) in
> drivers/net/can/c_can/c_can.c
> drivers/net/can/c_can/c_can_platform.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/can/c_can/c_can.c | 1 -
> drivers/net/can/c_can/c_can_platform.c | 1 -
> 2 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> index 1405078..b343bcb 100644
> --- a/drivers/net/can/c_can/c_can.c
> +++ b/drivers/net/can/c_can/c_can.c
> @@ -34,7 +34,6 @@
> #include <linux/if_arp.h>
> #include <linux/if_ether.h>
> #include <linux/list.h>
> -#include <linux/delay.h>
> #include <linux/io.h>
>
> #include <linux/can.h>
> diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
> index e629b96..61c41ba 100644
> --- a/drivers/net/can/c_can/c_can_platform.c
> +++ b/drivers/net/can/c_can/c_can_platform.c
> @@ -28,7 +28,6 @@
> #include <linux/if_arp.h>
> #include <linux/if_ether.h>
> #include <linux/list.h>
> -#include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> #include <linux/clk.h>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
I added a CC to the netdev mailing list. Hope that's sufficient to get
the patch accepted.
Thanks,
Wolfgang.
^ permalink raw reply
* Need a special way tune TCP IPv6->IPv4 fallback timeout
From: Guillaume Leclanche @ 2011-03-24 16:23 UTC (permalink / raw)
To: netdev
Hi,
(this is a copy of text I've put in
https://bugzilla.kernel.org/show_bug.cgi?id=23242 for anyone who would
like to do something with bugzilla).
When applications call the connect() API, if AAAA record is returned
and correct routing is present, the system will start a TCP connection
over IPv6.
However, if the host is finally unreachable, the system waits until
the IPv6 TCP connection attempt fails, that is roughly 3 min (5
retries, backoff, well, you know that). Then it falls back to IPv4.
Afaik, the only way to tune this timeout of 3 mins in the kernel is
the tcp_syn_retries sysctl (RTO tuning not available in Linux TCP). By
setting the value to 2, you can reduce the delay to ~10s which is more
acceptable, and still 3 SYN are sent.
In order not to modify uselessly the TCP parameters for standard
IPv4-only connections at the same time, it would be necessary to have
a *separate* parameter-set to decrease the v6->v4 fallback delay.
No idea how feasible this is, nor if it has already been discussed
here in the past.
// Not subscribed, please CC me.
Best regards,
Guillaume
^ 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