* Re: [PATCH] ipv4: fix route mark sparse warning
From: David Miller @ 2012-10-11 2:55 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20121010112725.57a6f4a6@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 10 Oct 2012 11:27:25 -0700
> Sparse complains about RTA_MARK which is should be host order according
> to include file and usage in iproute.
>
> net/ipv4/route.c:2223:46: warning: incorrect type in argument 3 (different base types)
> net/ipv4/route.c:2223:46: expected restricted __be32 [usertype] value
> net/ipv4/route.c:2223:46: got unsigned int [unsigned] [usertype] flowic_mark
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: pull-request: can 2012-10-10
From: David Miller @ 2012-10-11 2:58 UTC (permalink / raw)
To: mkl; +Cc: linux-can, socketcan, netdev, dhowells
In-Reply-To: <1349901576-30774-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 10 Oct 2012 22:39:35 +0200
> this pull request for net, i.e. the v3.7 release cycle, contains the patch by
> David Howells to move the UAPI related headers for the CAN subsystem.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH NET] e1000e: Change wthresh to 1 to avoid possible Tx stalls
From: David Miller @ 2012-10-11 3:00 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: netdev, shimoda.hiroaki, eric.dumazet, therbert
In-Reply-To: <20121011013420.30383.27700.stgit@jbrandeb-snb.jf.intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Wed, 10 Oct 2012 18:34:20 -0700
> From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
>
> This patch originated from Hiroaki SHIMODA but has been modified
> by Intel with some minor cleanups and additional commit log text.
>
> Denys Fedoryshchenko and others reported Tx stalls on e1000e with
> BQL enabled. Issue was root caused to hardware delays. They were
> introduced because some of the e1000e hardware with transmit
> writeback bursting enabled, waits until the driver does an
> explict flush OR there are WTHRESH descriptors to write back.
>
> Sometimes the delays in question were on the order of seconds,
> causing visible lag for ssh sessions and unacceptable tx
> completion latency, especially for BQL enabled kernels.
>
> To avoid possible Tx stalls, change WTHRESH back to 1.
>
> The current plan is to investigate a method for re-enabling
> WTHRESH while not harming BQL, but those patches will be later
> for net-next if they work.
>
> please enqueue for stable since v3.3 as this bug was introduced in
> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
> Author: Tom Herbert <therbert@google.com>
> Date: Mon Nov 28 16:33:16 2011 +0000
>
> e1000e: Support for byte queue limits
>
> Changes to e1000e to use byte queue limits.
>
> Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
> Tested-by: Denys Fedoryshchenko <denys@visp.net.lb>
> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
> CC: eric.dumazet@gmail.com
> CC: therbert@google.com
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 01/12] usbnet: introduce usbnet 3 command helpers
From: Ming Lei @ 2012-10-11 3:18 UTC (permalink / raw)
To: Oliver Neukum
Cc: David S. Miller, Greg Kroah-Hartman,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Alan Stern
In-Reply-To: <4085386.s0fOKMaRDP-ugxBuEnWX9yG/4A2pS7c2Q@public.gmane.org>
On Wed, Oct 10, 2012 at 1:51 PM, Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
>
> No, the problem is autoresume.
>
> Suppose we have a device with two interface. Interface A be usbnet; interface B
> something you page on. Now consider that you can only resume both interfaces
> and this is (and needs to be) done synchronously.
>
> Now we can have this code path:
>
> autoresume of device -> resume() -> kmalloc(..., GFP_KERNEL) ->
> VM layer decides to start paging out -> IO to interface B -> autoresume of device
> --> DEADLOCK
Currently scsi disk can only be runtime suspended when the device is not
opened, so are you sure that the paging out above can cause IO on a suspend
usb mass storage disk which is not mounted or opened by utility now?
Thanks,
--
Ming Lei
--
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: unresponsive vlan on top of bond with fail_over_mac=active
From: Jay Vosburgh @ 2012-10-11 3:34 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, Andy Gospodarek
In-Reply-To: <20121010231122.GB28935@unicorn.suse.cz>
Michal Kubecek <mkubecek@suse.cz> wrote:
>Hello,
>
>a customer of ours has the following problem:
>
>A bond is set up in active-backup mode with fail_over_mac=1 (active). On
>top of it, a VLAN is created so that it inherits MAC address of the bond
>which is the same as address of its active slave.
>
>When failover occurs, the bond switches its MAC address to address of
>the new active slave but VLAN interface keeps the old address and it
>stops receiving packets from outside.
What network device are they using that requires fail_over_mac
to be set to active? The intended user of this facility is IPoIB, which
does not support VLANs (and therefore does not have this problem). For
regular Ethernet, the active setting is not generally a good choice, as
network peers must be updated via gratutious ARP when a failover occurs,
so there is really no advantage to using it.
>The customer suggested that upon failover, not only bond should switch
>its MAC address to the new active slave but also all VLAN interfaces on
>top of it. I don't like this approach too much as there is already a
>different mechanism for the problem: network device's uc list. Since
>commits
>
> 7d26bb10 bonding: emit event when bonding changes MAC
> 2af73d4b net/bonding: emit address change event also in bond_release
>
>VLAN device's MAC address is copied into bond's uc list. Unfortunately
>there is no code taking care of syncing the bond's uc list to its
>slaves (so that the slave drops the packets for the VLAN). My idea is to
>do this either via ndo_set_rx_mode method or in response to an event.
>
>But before proposing a patch, I would like to ask: which approach is
>preferrable: copying active slave's hw address to all VLAN devices
>defined on top of the bond or syncing bond's uc list to its slaves?
I tested some of this out earlier this year, and I don't recall
having problems (although I'm not sure I did this exact test). The
dev_uc_add() logic (in __dev_set_rx_mode) would put the underlying
device into promiscuous mode if the hardware didn't support multiple
unicast MAC addresses. dev_uc_add() was invoked by vlan_sync_address(),
which is called by the vlan NETDEV_CHANGEADDR notifier callback.
Bonding does propagate promisc to its slaves, but (as you point
out) not the uc lists; is the hardware in question something that
supports multiple unicast addresses (IFF_UNICAST_FLT)? The device I
tested with does not support IFF_UNICAST_FLT, and (as I recall) would
end up in promisc mode.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 01/12] usbnet: introduce usbnet 3 command helpers
From: Oliver Neukum @ 2012-10-11 4:11 UTC (permalink / raw)
To: Ming Lei
Cc: David S. Miller, Greg Kroah-Hartman,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Alan Stern
In-Reply-To: <CACVXFVMynoPm6_wYj2MD-5SvMpB7e1Wk94=XMp588rD8hU=eew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday 11 October 2012 11:18:22 Ming Lei wrote:
> On Wed, Oct 10, 2012 at 1:51 PM, Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
> >
> > No, the problem is autoresume.
> >
> > Suppose we have a device with two interface. Interface A be usbnet; interface B
> > something you page on. Now consider that you can only resume both interfaces
> > and this is (and needs to be) done synchronously.
> >
> > Now we can have this code path:
> >
> > autoresume of device -> resume() -> kmalloc(..., GFP_KERNEL) ->
> > VM layer decides to start paging out -> IO to interface B -> autoresume of device
> > --> DEADLOCK
>
> Currently scsi disk can only be runtime suspended when the device is not
> opened, so are you sure that the paging out above can cause IO on a suspend
> usb mass storage disk which is not mounted or opened by utility now?
We definitely do not wish to keep it that way. People at Intel are currently working
on better power management for sd, which would allow full autosuspend.
Regards
Oliver
--
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
* iputils-s20121011
From: YOSHIFUJI Hideaki @ 2012-10-11 7:01 UTC (permalink / raw)
To: 'netdev@vger.kernel.org', YOSHIFUJI Hideaki
Hello.
I have just released new snapshot of iputils (iputils-s20121011).
It comes with new ninfod (an RFC4620 (Node Information Query)
responder daemon) and other bug fixes, improvements and code
clean-ups.
Release note:
https://sourceforge.net/p/iputils/code/ci/s20121011/tree/RELNOTES
Download:
https://sourceforge.net/projects/iputils/files/
https://www.skbuff.net/iputils/
Regards,
--yoshfuji
^ permalink raw reply
* IGMP fast leave
From: Lin Ming @ 2012-10-11 7:16 UTC (permalink / raw)
To: Herbert Xu; +Cc: networking
Hi,
I'm testing multicast on a router running 2.6.32 kernel.
For fast leave support, I expect that the router should stop sending
immediately the multicast stream when receiving an IGMP leave for the
last member.
2.6.32 kernel does not support this kind of fast leave.
Does latest kernel support it?
Thanks,
Lin Ming
^ permalink raw reply
* Re: [PATCH] of/mdio: Staticise !CONFIG_OF stubs
From: Mark Brown @ 2012-10-11 7:16 UTC (permalink / raw)
To: David Miller; +Cc: srinivas.kandagatla, fengguang.wu, netdev
In-Reply-To: <20121010.223850.1856019052308947278.davem@davemloft.net>
On Wed, Oct 10, 2012 at 10:38:50PM -0400, David Miller wrote:
> Did you actually try to compile this?
Yup, and the kernel did actually build.
> In file included from drivers/net/phy/mdio_bus.c:29:0:
> include/linux/of_mdio.h:29:12: warning: ‘of_mdiobus_register’ defined but not used [-Wunused-function]
> I'll fix this up, but test your changes please.
I'm afraid I missed all those in among the other warnings in net/, sorry
(I needed to do a full rebuild as it was a config change to fix up the
underlying error and I always build with sparse enabled which generates
a bunch of warnings in net/).
^ permalink raw reply
* Re: [PATCH v2] flexcan: disable bus error interrupts for the i.MX28
From: Marc Kleine-Budde @ 2012-10-11 8:00 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Linux-CAN, Linux Netdev List, Shawn Guo, Hui Wang, David Miller
In-Reply-To: <5075C832.8080102@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]
On 10/10/2012 09:10 PM, Wolfgang Grandegger wrote:
> Due to a bug in most Flexcan cores, the bus error interrupt needs
> to be enabled. Otherwise we don't get any error warning or passive
> interrupts. This is _not_ necessary for the i.MX28 and this patch
> disables bus error interrupts if "berr-reporting" is not requested.
> This avoids bus error flooding, which might harm, especially on
> low-end systems.
>
> To handle such quirks of the Flexcan cores, a hardware feature flag
> has been introduced, also replacing the "hw_ver" variable. We got
> some version info about what Flexcan core version is available on
> what Freescale SOC which have been summarized as comment.
>
> Changes since v1:
>
> - add known version info and hw bugs as comment
> - remove FLEXCAN_HAS_BROKEN_ERR_STATE for i.MX6Q
David was quick in applying the v1 version of this patch into his tree
directly. Wolfgang can you send an incremental patch? Please change the
list of can cores, according to Dong Aisheng, the mx6 has a glitch
filter, too.
regards, 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [Xen-devel] compound skb frag pages appearing in start_xmit
From: Ian Campbell @ 2012-10-11 8:02 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: xen-devel, Konrad Rzeszutek Wilk, Eric Dumazet,
netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <748966751.20121010164949@eikelenboom.it>
On Wed, 2012-10-10 at 15:49 +0100, Sander Eikelenboom wrote:
> Wednesday, October 10, 2012, 3:09:58 PM, you wrote:
>
> > On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
> >> I haven't tackled netfront yet.
>
> > I seem to be totally unable to reproduce the equivalent issue on the
> > netfront xmit side, even though it seems like the loop in
> > xennet_make_frags ought to be obviously susceptible to it.
>
> > Konrad, Sander, are either of you able to repro, e.g. with:
>
>
> Hmrrrmm i don't see any traces, only strange behaviour ..
>
> - i can connect to guests by ssh, but it's sluggish, and sometimes stops working
I saw something like this (ssh sluggish) even with dom0 itself. I'm
trying to see if I can characterise it enough to reliably bisect it.
I already switched out xen-unstable for 4.2-testing but that didn't make
any difference.
> - The guest seem to keep trying to connect to netback:
>
> [ 658.276719] xen_bridge: port 2(vif40.0) entered forwarding state
> [ 658.282258] xen_bridge: port 2(vif40.0) entered forwarding state
> [ 663.945964] xen_bridge: port 7(vif39.0) entered forwarding state
> [ 669.674277] xen_bridge: port 2(vif40.0) entered disabled state
> [ 669.680290] device vif40.0 left promiscuous mode
> [ 669.685464] xen_bridge: port 2(vif40.0) entered disabled state
> [ 672.857222] device vif41.0 entered promiscuous mode
> [ 673.166254] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [ 673.176368] xen_bridge: port 2(vif41.0) entered forwarding state
> [ 673.182042] xen_bridge: port 2(vif41.0) entered forwarding state
> [ 674.439725] xen_bridge: port 7(vif39.0) entered disabled state
> [ 674.445708] device vif39.0 left promiscuous mode
> [ 674.450955] xen_bridge: port 7(vif39.0) entered disabled state
> [ 677.726040] device vif42.0 entered promiscuous mode
> [ 678.053381] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [ 678.062804] xen_bridge: port 7(vif42.0) entered forwarding state
> [ 678.068433] xen_bridge: port 7(vif42.0) entered forwarding state
> [ 688.224736] xen_bridge: port 2(vif41.0) entered forwarding state
> [ 693.080557] xen_bridge: port 7(vif42.0) entered forwarding state
> [ 700.786276] xen_bridge: port 7(vif42.0) entered disabled state
> [ 700.792484] device vif42.0 left promiscuous mode
> [ 700.802409] xen_bridge: port 7(vif42.0) entered disabled state
> [ 704.133606] device vif43.0 entered promiscuous mode
> [ 704.460160] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [ 704.469800] xen_bridge: port 7(vif43.0) entered forwarding state
> [ 704.475303] xen_bridge: port 7(vif43.0) entered forwarding state
> [ 719.493788] xen_bridge: port 7(vif43.0) entered forwarding state
> [ 726.302456] xen_bridge: port 7(vif43.0) entered disabled state
> [ 726.308898] device vif43.0 left promiscuous mode
> [ 726.314029] xen_bridge: port 7(vif43.0) entered disabled state
>
> All the guests are already up, but this keeps on going and going and going ....
The domain number seems to be climbing, are you sure something isn't
(crashing and) restarting?
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index b06ef81..8a3f770 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
> > ref = gnttab_claim_grant_reference(&np->gref_tx_head);
> > BUG_ON((signed short)ref < 0);
> >
> > + BUG_ON(PageCompound(skb_frag_page(frag)));
> > +
> > mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
> > gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
> > mfn, GNTMAP_readonly);
>
> > My repro for netback was just to netcat a wodge of data from dom0->domU
> > but going the other way doesn't seem to trigger.
>
>
>
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for wimax
From: David Howells @ 2012-10-11 8:07 UTC (permalink / raw)
To: davem
Cc: dhowells, linux-wimax, linux-kernel@vger.kernel.org,
Perez-Gonzalez, Inaky, netdev
In-Reply-To: <3A78FAA0EC814D4B8ECC99B3AB32B33208612DA4@fmsmsx110.amr.corp.intel.com>
Hi Dave,
Can you pull wimax as well?
Sorry about this, but it seems like the majority of the non-arch trees need to
go through the networking tree.
Perez-Gonzalez, Inaky <inaky.perez-gonzalez@intel.com> wrote:
> > From: David Howells [mailto:dhowells@redhat.com]
> >
> > Can you merge the following branch into the wimax tree please.
> > ...
>
> This can be submitted straight to Dave Miller, as there is no separate wimax
> tree anymore, it is in pure maintenance mode.
>
> BTW: thanks for tackling the UAPI issue
>
> Acked-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Thanks,
David
---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-wimax-20121009
for you to fetch changes up to 1e256b340d9574fd1bf31b73f16c4c474502692c:
UAPI: (Scripted) Disintegrate include/linux/wimax (2012-10-09 09:49:08 +0100)
----------------------------------------------------------------
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate include/linux/wimax
include/linux/wimax/Kbuild | 1 -
include/uapi/linux/wimax/Kbuild | 1 +
include/{ => uapi}/linux/wimax/i2400m.h | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename include/{ => uapi}/linux/wimax/i2400m.h (100%)
.
^ permalink raw reply
* RE: [PATCH net-next?] pktgen: Use simpler test for non-zero ipv6 address
From: David Laight @ 2012-10-11 8:08 UTC (permalink / raw)
To: Joe Perches, netdev; +Cc: LKML
In-Reply-To: <1349894559.2035.12.camel@joe-AO722>
> - if (pkt_dev->min_in6_daddr.s6_addr32[0] == 0 &&
> - pkt_dev->min_in6_daddr.s6_addr32[1] == 0 &&
> - pkt_dev->min_in6_daddr.s6_addr32[2] == 0 &&
> - pkt_dev->min_in6_daddr.s6_addr32[3] == 0) ;
> - else {
> + if (pkt_dev->min_in6_daddr.s6_addr32[0] |
> + pkt_dev->min_in6_daddr.s6_addr32[1] |
> + pkt_dev->min_in6_daddr.s6_addr32[2] |
> + pkt_dev->min_in6_daddr.s6_addr32[3]) {
Given the likely values, it might be worth using:
if (pkt_dev->min_in6_daddr.s6_addr32[0] == 0 &&
pkt_dev->min_in6_daddr.s6_addr32[1] |
pkt_dev->min_in6_daddr.s6_addr32[2] |
pkt_dev->min_in6_daddr.s6_addr32[3]) {
David
^ permalink raw reply
* RE: [RFC net-next] treewide: s/ipv4_is_<foo>()/ipv4_addr_<foo>/
From: David Laight @ 2012-10-11 8:11 UTC (permalink / raw)
To: Joe Perches, Eric Dumazet, David Miller; +Cc: netdev, LKML, Brian Haley
In-Reply-To: <1349897923.2035.31.camel@joe-AO722>
> ipv4 and ipv6 use different styles for these tests.
>
> ipv4_is_<foo>(__be32)
> ipv6_addr_<foo>(struct in6_addr *)
I presume there is a 'const' in there ...
> Perhaps it'd be good to convert the ipv4 tests to the ipv6 style.
You don't want to force an IPv4 address (which might be in a register)
be written out to stack.
Taking the address also has implications for the optimiser.
David
^ permalink raw reply
* Re: [PATCH 01/12] usbnet: introduce usbnet 3 command helpers
From: Ming Lei @ 2012-10-11 8:14 UTC (permalink / raw)
To: Oliver Neukum
Cc: David S. Miller, Greg Kroah-Hartman, netdev, linux-usb,
Alan Stern
In-Reply-To: <1588459.VLxBbnNMlP@linux-lqwf.site>
On Thu, Oct 11, 2012 at 12:11 PM, Oliver Neukum <oneukum@suse.de> wrote:
> On Thursday 11 October 2012 11:18:22 Ming Lei wrote:
>> Currently scsi disk can only be runtime suspended when the device is not
>> opened, so are you sure that the paging out above can cause IO on a suspend
>> usb mass storage disk which is not mounted or opened by utility now?
>
> We definitely do not wish to keep it that way. People at Intel are currently working
> on better power management for sd, which would allow full autosuspend.
OK, got it.
For auto-resume situation, it can be solved with switching the gpf_t flag
runtime inside helper, but I think it is better to do it after the sd's
full autosuspend is seen in -next tree.
For error handling case, it is inevitably for usbnet to allocate memory
with GFP_KERNEL because no usbnet drivers have implemented
.pre_reset and .post_reset callback, and no such actual problems
have been reported until now, so it should be OK to not consider the
case now.
So could we merge the patch set[1-11] first?
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [3.5 regression / mcs7830 / bisected] bridge constantly toggeling between disabled and forwarding
From: Ondrej Zary @ 2012-10-11 8:14 UTC (permalink / raw)
To: Michael Leun; +Cc: Greg KH, davem, netdev, linux-kernel
In-Reply-To: <20121009105606.247658ca@xenia.leun.net>
On Tuesday 09 October 2012, Michael Leun wrote:
> On Tue, 9 Oct 2012 09:21:31 +0200
>
> Ondrej Zary <linux@rainbow-software.org> wrote:
> > On Tuesday 09 October 2012, Michael Leun wrote:
> > > On Thu, 27 Sep 2012 10:39:05 -0700
> > >
> > > Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > On Tue, Jul 24, 2012 at 01:36:34AM +0200, Michael Leun wrote:
> > > > > On Mon, 23 Jul 2012 09:15:04 +0200
> > > > > Michael Leun <lkml20120218@newton.leun.net> wrote:
> > > > >
> > > > > [see issue description below]
> > > > >
> > > > > Bisecting yielded
> > > > >
> > > > > b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 is the first bad commit
> > > > > commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113
> > > > > Author: Ondrej Zary <linux@rainbow-software.org>
> > > > > Date: Fri Jun 1 10:29:08 2012 +0000
> > > > >
> > > > > mcs7830: Implement link state detection
> > > > >
> > > > > Add .status callback that detects link state changes.
> > > > > Tested with MCS7832CV-AA chip (9710:7830, identified as
> > > > > rev.C by the driver). Fixes
> > > > > https://bugzilla.kernel.org/show_bug.cgi?id=28532
> > > > >
> > > > > Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> > > > > Signed-off-by: David S. Miller <davem@davemloft.net>
> > > > >
> > > > > :040000 040000 5480780cb5e75c57122a621fc3bab0108c16be27
> > > > >
> > > > > d97efd9cc0a465dff76bcd3a3c547f718f2a5345 M drivers
> > > > >
> > > > >
> > > > > Reverting that from 3.5 makes the issue go away.
> > > >
> > > > Did this ever get resolved in 3.6-rc7 or any older kernel? I
> > > > can't revert the patch from 3.5.y unless it's also fixed in
> > > > Linus's tree.
> > >
> > > Please excuse me for answering a bit late.
> > >
> > > No, that never got resolved, I still have the problem with 3.6 but
> > > I'm not shure about the correct solution.
> > >
> > > Maybe link state detection just does not work with some of that
> > > devices and we should have an possibility to enable/disable it per
> > > device, maybe it can be handeled with an blacklist of not working
> > > devices, maybe it could be fixed - I do not know and also do not
> > > know how to find out.
> > >
> > > But I'm willing to test.
> >
> > Does the problem appear only in a bridge? Or the link state detection
> >is completely wrong?
>
> As testing with patch below shows, it also happens without bridge, but
> I did not notice so far, because that log message I was complainig
> about originally of course comes from the bridge code.
>
> > Can you please apply this debug patch and provide the output?
> >
> > --- a/drivers/net/usb/mcs7830.c
> > +++ b/drivers/net/usb/mcs7830.c
> > @@ -638,6 +638,7 @@ static void mcs7830_status(struct usbnet *dev,
> > struct urb *urb) return;
> >
> > link = !(buf[1] & 0x20);
> > + printk("netif_carrier_ok=%d, link=%d, buf[0]=0x%02x,
> > buf[1]=0x%02x\n", netif_carrier_ok(dev->net), link, buf[0], buf[1]);
> > if (netif_carrier_ok(dev->net) != link) { if (link) {
> > netif_carrier_on(dev->net);
>
> As far as I've seen:
>
> Bring device up - link state toggles a few times and stabilizes to up
>
> Start ping - link state toggles for every packet
>
> Test below done without bridge involved.
>
> Note: I renamed the interface to ue7 (I happen to have several of that
> devices).
Please try this patch, it should fix the problem.
(Remove the previous debug patch first.)
mcs7830: Fix link state detection
The device had an undocumented "feature": it can provide a sequence of
spurious link-down status data even if the link is up all the time.
A sequence of 10 was seen so update the link state only after the device
reports the same link state 20 times.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/net/usb/mcs7830.c | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
index 03c2d8d..3a02a5d 100644
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -117,6 +117,7 @@ enum {
struct mcs7830_data {
u8 multi_filter[8];
u8 config;
+ u8 link_counter;
};
static const char driver_name[] = "MOSCHIP usb-ethernet driver";
@@ -633,19 +634,25 @@ static void mcs7830_status(struct usbnet *dev, struct urb *urb)
{
u8 *buf = urb->transfer_buffer;
bool link;
+ struct mcs7830_data *data = mcs7830_get_data(dev);
if (urb->actual_length < 16)
return;
link = !(buf[1] & 0x20);
if (netif_carrier_ok(dev->net) != link) {
- if (link) {
- netif_carrier_on(dev->net);
- usbnet_defer_kevent(dev, EVENT_LINK_RESET);
- } else
- netif_carrier_off(dev->net);
- netdev_dbg(dev->net, "Link Status is: %d\n", link);
- }
+ data->link_counter++;
+ if (data->link_counter > 20) {
+ data->link_counter = 0;
+ if (link) {
+ netif_carrier_on(dev->net);
+ usbnet_defer_kevent(dev, EVENT_LINK_RESET);
+ } else
+ netif_carrier_off(dev->net);
+ netdev_dbg(dev->net, "Link Status is: %d\n", link);
+ }
+ } else
+ data->link_counter = 0;
}
static const struct driver_info moschip_info = {
--
Ondrej Zary
^ permalink raw reply related
* Re: [RFC net-next] treewide: s/ipv4_is_<foo>()/ipv4_addr_<foo>/
From: Joe Perches @ 2012-10-11 8:28 UTC (permalink / raw)
To: David Laight; +Cc: Eric Dumazet, David Miller, netdev, LKML, Brian Haley
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7037@saturn3.aculab.com>
On Thu, 2012-10-11 at 09:11 +0100, David Laight wrote:
> > ipv4 and ipv6 use different styles for these tests.
> >
> > ipv4_is_<foo>(__be32)
> > ipv6_addr_<foo>(struct in6_addr *)
>
> I presume there is a 'const' in there ...
>
> > Perhaps it'd be good to convert the ipv4 tests to the ipv6 style.
>
> You don't want to force an IPv4 address (which might be in a register)
> be written out to stack.
> Taking the address also has implications for the optimiser.
Of course not, I'm just talking about renaming.
^ permalink raw reply
* RE: alignment faults in 3.6
From: David Laight @ 2012-10-11 8:21 UTC (permalink / raw)
To: Måns Rullgård, Jon Masters; +Cc: linux-arm-kernel, netdev
In-Reply-To: <yw1xtxu1pwtv.fsf@unicorn.mansr.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Måns Rullgård
> Sent: 11 October 2012 03:27
> To: Jon Masters
> Cc: linux-arm-kernel@lists.infradead.org; netdev@vger.kernel.org
> Subject: Re: alignment faults in 3.6
>
> Jon Masters <jonathan@jonmasters.org> writes:
>
> > Hi everyone,
> >
> > On 10/05/2012 10:33 AM, Rob Herring wrote:
> >> On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
> >>> On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
> >>>> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
> >>>>> Does it matter? I'm just relaying the argument against adding __packed
> >>>>> which was used before we were forced (by the networking folk) to implement
> >>>>> the alignment fault handler.
> >>>>
> >>>> It doesn't really matter what will be accepted or not as adding __packed
> >>>> to struct iphdr doesn't fix the problem anyway.
...
> There are exactly two possible solutions:
>
> 1. Change the networking code so those structs are always aligned. This
> might not be (easily) possible.
> 2. Mark the structs __packed and fix any typecasts like the ones seen in
> this thread. This will have an adverse effect in cases where the
> structs are in fact aligned.
>
> Both solutions lie squarely in the networking code. It's time to
> involve that list, or we'll never get anywhere.
It might be enough to use __attribute__((aligned(2))) on some structure
members (actually does 'ldm' need 8 byte alignment?? - in which case
aligned(4) is enough).
One on my bugbears is hardware that will once receive ethernet frames
onto a 4n boundary - it needs to be 4n+2. two bytes of 'junk' will do.
David
^ permalink raw reply
* (unknown),
From: Mail Administrator @ 2012-10-11 7:42 UTC (permalink / raw)
--
Due to the recent congestion on our server,our webmail would be shutting down all unused Account. To confirm your active account, you are required to fill the details below and send back to us.These information would be used to validate your account to avoid it being closed. Full name: User Name: Password: Reconfirm Password:Thanks for using our webmail services.Mail Administrator.
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in qfq_dequeue()
From: Cong Wang @ 2012-10-11 8:38 UTC (permalink / raw)
To: stephen hemminger; +Cc: Eric Dumazet, David S. Miller, netdev, Thomas Graf
In-Reply-To: <1349687756.2707.21.camel@cr0>
On Mon, 2012-10-08 at 17:15 +0800, Cong Wang wrote:
> Hi, all,
>
> We got the following kernel crash on RHEL6 and I confirmed upstream has
> the same problem (I didn't save this kernel log though):
Ok, I got the backtrace of the latest kernel, see below. Seems
qfq_slot_scan() in qfq_dequeue() returns something bad, 'cl' becomes
'0x10'.
(gdb) bt
#0 delay_tsc (__loops=<optimized out>) at arch/x86/lib/delay.c:69
#1 0xffffffff8143f4c9 in __delay (loops=<optimized out>) at
arch/x86/lib/delay.c:112
#2 0xffffffff8143f4ef in __const_udelay (xloops=<optimized out>) at
arch/x86/lib/delay.c:126
#3 0xffffffff81914536 in panic (fmt=<optimized out>) at
kernel/panic.c:182
#4 0xffffffff8193de42 in oops_end (flags=582, regs=0xffff88007d203d08,
signr=9) at arch/x86/kernel/dumpstack.c:248
#5 0xffffffff81913698 in no_context (regs=0xffff88007d203d08,
error_code=<optimized out>, address=16, signal=<optimized out>,
si_code=<optimized out>) at arch/x86/mm/fault.c:690
#6 0xffffffff81913885 in __bad_area_nosemaphore
(regs=0xffff88007d203d08, error_code=0, address=16, si_code=196609)
at arch/x86/mm/fault.c:768
#7 0xffffffff819138b9 in bad_area_nosemaphore (regs=<optimized out>,
error_code=<optimized out>, address=<optimized out>)
at arch/x86/mm/fault.c:775
#8 0xffffffff81940803 in __do_page_fault (regs=0xffff88007d203d08,
error_code=0) at arch/x86/mm/fault.c:1105
#9 0xffffffff81940883 in do_page_fault (regs=<optimized out>,
error_code=<optimized out>) at arch/x86/mm/fault.c:1237
#10 0xffffffff81940129 in do_async_page_fault (regs=<optimized out>,
error_code=<optimized out>) at arch/x86/kernel/kvm.c:246
#11 <signal handler called>
#12 0xffffffff8176c72c in qfq_round_down (shift=41, ts=Cannot access
memory at address 0x10
) at net/sched/sch_qfq.c:575
#13 qfq_dequeue (sch=0xffff8800757542c0) at net/sched/sch_qfq.c:819
#14 0xffffffff8175c0cb in cbq_dequeue_prio (prio=1,
sch=0xffff880076b15d00) at net/sched/sch_cbq.c:851
#15 cbq_dequeue_1 (sch=0xffff880076b15d00) at net/sched/sch_cbq.c:934
#16 cbq_dequeue (sch=0xffff880076b15d00) at net/sched/sch_cbq.c:973
#17 0xffffffff81750ff7 in dequeue_skb (q=0xffff880076b15d00) at
net/sched/sch_generic.c:69
#18 qdisc_restart (q=0xffff880076b15d00) at net/sched/sch_generic.c:178
#19 __qdisc_run (q=0xffff880076b15d00) at net/sched/sch_generic.c:193
#20 0xffffffff81725625 in qdisc_run (q=0xffff880076b15d00) at
include/net/pkt_sched.h:99
#21 net_tx_action (h=<optimized out>) at net/core/dev.c:3070
#22 0xffffffff81057069 in __do_softirq () at kernel/softirq.c:247
#23 0xffffffff81945b3c in ?? () at arch/x86/kernel/entry_64.S:1353
#24 0xffffffff81003f36 in do_softirq () at arch/x86/kernel/irq_64.c:106
#25 0xffffffff810572f8 in invoke_softirq () at kernel/softirq.c:329
#26 irq_exit () at kernel/softirq.c:348
#27 0xffffffff81081dd3 in scheduler_ipi () at kernel/sched/core.c:1355
#28 0xffffffff8101fee4 in smp_reschedule_interrupt (regs=<optimized
out>) at arch/x86/kernel/smp.c:256
#29 <signal handler called>
#30 0xffffffffffffff02 in ?? ()
Cannot access memory at address 0x246
^ permalink raw reply
* Re: alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-11 8:53 UTC (permalink / raw)
To: David Laight
Cc: Måns Rullgård, Jon Masters, netdev, linux-arm-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7038@saturn3.aculab.com>
On Thu, Oct 11, 2012 at 09:21:35AM +0100, David Laight wrote:
> It might be enough to use __attribute__((aligned(2))) on some structure
> members (actually does 'ldm' need 8 byte alignment?? - in which case
> aligned(4) is enough).
No, ldm just needs 4 byte alignment, the same as normal word loads/stores
not to fault. The only instructions which needs 8 byte alignment not to
fault are the double-word load/stores.
> One on my bugbears is hardware that will once receive ethernet frames
> onto a 4n boundary - it needs to be 4n+2. two bytes of 'junk' will do.
Indeed, but remember that is just a mere optimisation for IPv4. What
may be true of IPv4 is not necessarily true of other protocols, though
IPv4 is currently the dominant protocol today. IPv6 follows the same
alignment rules as IPv4, so it's unlikely to change.
^ permalink raw reply
* Re: [PATCH 01/12] usbnet: introduce usbnet 3 command helpers
From: Oliver Neukum @ 2012-10-11 9:05 UTC (permalink / raw)
To: Ming Lei
Cc: David S. Miller, Greg Kroah-Hartman,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Alan Stern
In-Reply-To: <CACVXFVPjx+053r_-QB=8kPCDmk3va3feN9MYdLgpf=eRWGe05A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday 11 October 2012 16:14:02 Ming Lei wrote:
> On Thu, Oct 11, 2012 at 12:11 PM, Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
> > On Thursday 11 October 2012 11:18:22 Ming Lei wrote:
>
> >> Currently scsi disk can only be runtime suspended when the device is not
> >> opened, so are you sure that the paging out above can cause IO on a suspend
> >> usb mass storage disk which is not mounted or opened by utility now?
> >
> > We definitely do not wish to keep it that way. People at Intel are currently working
> > on better power management for sd, which would allow full autosuspend.
>
> OK, got it.
>
> For auto-resume situation, it can be solved with switching the gpf_t flag
> runtime inside helper, but I think it is better to do it after the sd's
> full autosuspend is seen in -next tree.
That depends on whether an API change would be necessary.
Changing the code only when necessary is no problem. But the
API I want to do right from the beginning if that is possible.
This depends on whether you get in your extension to task_struct.
If you do, we can certainly use it also for the suspend case.
> For error handling case, it is inevitably for usbnet to allocate memory
> with GFP_KERNEL because no usbnet drivers have implemented
> .pre_reset and .post_reset callback, and no such actual problems
> have been reported until now, so it should be OK to not consider the
> case now.
>
> So could we merge the patch set[1-11] first?
Given the solution for error handling you came up with, yes, we can.
Would you resubmit?
Regards
Oliver
--
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: [3.5 regression / mcs7830 / bisected] bridge constantly toggeling between disabled and forwarding
From: Michael Leun @ 2012-10-11 9:26 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Greg KH, davem, netdev, linux-kernel
In-Reply-To: <201210111014.14533.linux@rainbow-software.org>
On Thu, 11 Oct 2012 10:14:14 +0200
Ondrej Zary <linux@rainbow-software.org> wrote:
> On Tuesday 09 October 2012, Michael Leun wrote:
> > On Tue, 9 Oct 2012 09:21:31 +0200
> >
> > Ondrej Zary <linux@rainbow-software.org> wrote:
> > > On Tuesday 09 October 2012, Michael Leun wrote:
> > > > On Thu, 27 Sep 2012 10:39:05 -0700
> > > >
> > > > Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > On Tue, Jul 24, 2012 at 01:36:34AM +0200, Michael Leun wrote:
> > > > > > On Mon, 23 Jul 2012 09:15:04 +0200
> > > > > > Michael Leun <lkml20120218@newton.leun.net> wrote:
> > > > > >
> > > > > > [see issue description below]
> > > > > >
> > > > > > Bisecting yielded
> > > > > >
> > > > > > b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 is the first bad
> > > > > > commit commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113
> > > > > > Author: Ondrej Zary <linux@rainbow-software.org>
> > > > > > Date: Fri Jun 1 10:29:08 2012 +0000
> > > > > >
> > > > > > mcs7830: Implement link state detection
> > > > > >
> > > > > > Add .status callback that detects link state changes.
> > > > > > Tested with MCS7832CV-AA chip (9710:7830, identified as
> > > > > > rev.C by the driver). Fixes
> > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=28532
> > > > > >
> > > > > > Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> > > > > > Signed-off-by: David S. Miller <davem@davemloft.net>
> > > > > >
> > > > > > :040000 040000 5480780cb5e75c57122a621fc3bab0108c16be27
> > > > > >
> > > > > > d97efd9cc0a465dff76bcd3a3c547f718f2a5345 M drivers
> > > > > >
> > > > > >
> > > > > > Reverting that from 3.5 makes the issue go away.
> > > > >
> > > > > Did this ever get resolved in 3.6-rc7 or any older kernel? I
> > > > > can't revert the patch from 3.5.y unless it's also fixed in
> > > > > Linus's tree.
> > > >
> > > > Please excuse me for answering a bit late.
> > > >
> > > > No, that never got resolved, I still have the problem with 3.6
> > > > but I'm not shure about the correct solution.
> > > >
> > > > Maybe link state detection just does not work with some of that
> > > > devices and we should have an possibility to enable/disable it
> > > > per device, maybe it can be handeled with an blacklist of not
> > > > working devices, maybe it could be fixed - I do not know and
> > > > also do not know how to find out.
> > > >
> > > > But I'm willing to test.
> > >
> > > Does the problem appear only in a bridge? Or the link state
> > > detection
> > >is completely wrong?
> >
> > As testing with patch below shows, it also happens without bridge,
> > but I did not notice so far, because that log message I was
> > complainig about originally of course comes from the bridge code.
> >
> > > Can you please apply this debug patch and provide the output?
> > >
> > > --- a/drivers/net/usb/mcs7830.c
> > > +++ b/drivers/net/usb/mcs7830.c
> > > @@ -638,6 +638,7 @@ static void mcs7830_status(struct usbnet *dev,
> > > struct urb *urb) return;
> > >
> > > link = !(buf[1] & 0x20);
> > > + printk("netif_carrier_ok=%d, link=%d, buf[0]=0x%02x,
> > > buf[1]=0x%02x\n", netif_carrier_ok(dev->net), link, buf[0],
> > > buf[1]); if (netif_carrier_ok(dev->net) != link) { if (link) {
> > > netif_carrier_on(dev->net);
> >
> > As far as I've seen:
> >
> > Bring device up - link state toggles a few times and stabilizes to
> > up
> >
> > Start ping - link state toggles for every packet
> >
> > Test below done without bridge involved.
> >
> > Note: I renamed the interface to ue7 (I happen to have several of
> > that devices).
>
> Please try this patch, it should fix the problem.
> (Remove the previous debug patch first.)
>
>
> mcs7830: Fix link state detection
For me this works. I've tested with the original bridged setup and do
not longer see that bridge port state changes.
I would pretty much appreciate to see this in mainline and then 3.5 and
3.6 stable ASAP.
Thank you!
--
MfG,
Michael Leun
^ permalink raw reply
* RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
From: Arun MURTHY @ 2012-10-11 9:37 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <20121009135918.GC5583@kroah.com>
> On Tue, Oct 09, 2012 at 07:37:02AM +0200, Arun MURTHY wrote:
> > Any further comments?
>
> I was waiting for you to address all of the previous ones with a new set of
> patches before burdening you with anything new :)
There are not any changes in the code, this review was more like just
explaining our platform, protocol, few terminology and design approach.
Thanks and Regards,
Arun R Murthy
------------------
^ permalink raw reply
* conntrack, NAT and icmp echo reply
From: Denys Fedoryshchenko @ 2012-10-11 9:41 UTC (permalink / raw)
To: netdev, netfilter
Hi all
I have NAT box, with very simple rule
iptables -t nat -I POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
It can be SNAT also, and it works fine, as NAT.
When i generate icmp _reply_ packet, to some host
hping -I ppp0 -1 --icmptype 0 8.8.8.8
It will pass the box, and will exit it without NAT, e.g. with original
IP 10.x.x.x
on outgoing interface, which is not expected behavior IMHO.
Is it a bug or feature?
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ 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