* Re: strange behaviour of MC7700 with sierra_net
From: Phil Sutter @ 2011-07-28 16:32 UTC (permalink / raw)
To: Dan Williams
Cc: Elina Pasheva, dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Rory Filer
In-Reply-To: <1311795643.17655.13.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
Dan,
Thanks for the quick reply!
On Wed, Jul 27, 2011 at 02:40:40PM -0500, Dan Williams wrote:
> I wonder if the firmware changed and Sierra hasn't updated the driver
> yet. I've got a usb306 which also uses sierra_net which doesn't have
> this problem. It looks like the driver tries to sync with the firmware
> right after binding to the net interface, so that means at least a
> couple of SYNC requests have already happened by the time you start
> getting errors. My first thought here is simply that the firmware on
> the MC7700 doesn't work like the rest of the devices that sierra_net
> expects, and for that you'd have to get Sierra to weigh in on the
> required changes :(
That's exactly the case. My printf-debugging shows that ~30 calls to
sierra_net_dosync() sycceed before it starts failing. Why the heck does
that work if I set the interface up? When doing so, the driver
immediately receives a whole bunch of restart-messages. Looks
like the number matches the number of successfully sent sync-messages.
This looks like the turned down interface is holding something back, but
looking with usbmon I see communication (this is the point when the
sync-messages start to fail):
| da9ebc40 74.842086 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 74.842971 C Co:1:035:0 0 4 >
| da9ebc40 76.848151 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 76.848835 C Co:1:035:0 -32 4 >
But maybe something should be done in the beginning that's done when the
interface comes up. The capture in that situation is this:
| da9ebc40 88.898257 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 88.898860 C Co:1:035:0 -32 4 >
| dbe29dc0 90.548212 S Ii:1:035:8 -:64 64 <
| da9ebc40 90.548619 S Bi:1:035:9 - 8192 <
| dbe29c40 90.548632 S Bi:1:035:9 - 8192 <
| daab45c0 90.548639 S Bi:1:035:9 - 8192 <
| daac3640 90.548645 S Bi:1:035:9 - 8192 <
| da9cce40 90.548651 S Bi:1:035:9 - 8192 <
| dbe6b7c0 90.548657 S Bi:1:035:9 - 8192 <
| dab0ae40 90.548663 S Bi:1:035:9 - 8192 <
| dbe29640 90.548669 S Bi:1:035:9 - 8192 <
| dbe29340 90.548675 S Bi:1:035:9 - 8192 <
| dbe6b540 90.548681 S Bi:1:035:9 - 8192 <
| dbe6b0c0 90.548688 S Bi:1:035:9 - 8192 <
| dbe29dc0 90.550814 C Ii:1:035:8 0:64 8 = a1010000 07000000
| dbe29dc0 90.550868 S Ii:1:035:8 -:64 64 <
| daac3540 90.550980 S Ci:1:035:0 s a1 01 0000 0007 0400 1024 <
| daac3540 90.551694 C Ci:1:035:0 0 68 = 00406200 53574939 32303058 5f30332e 30302e30 322e3030 41502052 32303332
| dbe29dc0 90.558801 C Ii:1:035:8 0:64 8 = a1010000 07000000
| dbe29dc0 90.558960 S Ii:1:035:8 -:64 64 <
| daac3540 90.559054 S Ci:1:035:0 s a1 01 0000 0007 0400 1024 <
| daac3540 90.559544 C Ci:1:035:0 0 68 = 00406200 53574939 32303058 5f30332e 30302e30 322e3030 41502052 32303332
| dbe29dc0 90.566798 C Ii:1:035:8 0:64 8 = a1010000 07000000
The kernel log output of the above timeframe:
| Jul 28 17:55:36 (none) user.debug kernel: [266833.170570] usb 1-1: sierra_net_send_sync
| Jul 28 17:55:36 (none) user.info kernel: [266833.170590] sierra_net_send_sync: netif is not running
| Jul 28 17:55:36 (none) user.err kernel: [266833.171515] sierra_net 1-1:1.7: wwan0: Submit SYNC failed -32
| Jul 28 17:55:36 (none) user.err kernel: [266833.174713] sierra_net 1-1:1.7: wwan0: Send SYNC failed, status -32
| Jul 28 17:55:38 (none) user.debug kernel: [266834.823421] usb 1-1: sierra_net_status
| Jul 28 17:55:38 (none) user.debug kernel: [266834.824316] usb 1-1: sierra_net_kevent: Received status message, 0044 bytes
| Jul 28 17:55:38 (none) user.debug kernel: [266834.824475] usb 1-1: Restart reported: 0, stopping sync timer
| Jul 28 17:55:38 (none) user.debug kernel: [266834.831400] usb 1-1: sierra_net_status
| Jul 28 17:55:38 (none) user.debug kernel: [266834.832268] usb 1-1: sierra_net_kevent: Received status message, 0044 bytes
| Jul 28 17:55:38 (none) user.debug kernel: [266834.832426] usb 1-1: Restart reported: 0, stopping sync timer
> Since the MC7700 is an LTE module it's 100% likely the firmware is
> different, or at least significantly rebased, from the existing Sierra
> HSPA/EVDO parts that use sierra_net and thus I wouldn't necessarily
> expect it to work out of the box.
Well, it's obviously not that bad. Setting wwan0 up as a workaround,
everything's quite fine. Also, if I'm fast enough initialising the modem
via AT-commands before the control-tty dies, I can dial in even with
wwan0 being down, set it up and receive an address via DHCP.
Since the MC7700 has the same USB product and vendor IDs as any other
direct-IP device (1199:68a3), Sierra may indeed have meant this device
to act identical to the other ones. Or their driver-developers are just
a little bit masochistic. ;)
Hopefully Elina Pasheva can provide some helpful insights here.
Greetings, Phil
--
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: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
From: Ian Campbell @ 2011-07-28 16:27 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Konrad Rzeszutek Wilk, netdev@vger.kernel.org,
davem@davemloft.net, bhutchings@solarflare.com,
Kirsher, Jeffrey T, Jesse Barnes, linux-pci@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019414D525@orsmsx508.amr.corp.intel.com>
On Thu, 2011-07-28 at 08:58 -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > Sent: Thursday, July 28, 2011 8:11 AM
> > To: Rose, Gregory V; Konrad Rzeszutek Wilk
> > Cc: netdev@vger.kernel.org; davem@davemloft.net;
> > bhutchings@solarflare.com; Kirsher, Jeffrey T; Jesse Barnes; linux-
> > pci@vger.kernel.org
> > Subject: Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device has
> > been assigned by KVM
> >
> > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > Device drivers that create and destroy SR-IOV virtual functions via
> > > calls to pci_enable_sriov() and pci_disable_sriov can cause catastrophic
> > > failures if they attempt to destroy VFs while they are assigned to
> > > guest virtual machines. By adding a flag for use by the KVM module
> > > to indicate that a device is assigned a device driver can check that
> > > flag and avoid destroying VFs while they are assigned and avoid system
> > > failures.
> > >
> > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > ---
> > >
> > > include/linux/pci.h | 2 ++
> >
> > I added Jesse and linux-pci to CC.
> >
> > > virt/kvm/assigned-dev.c | 2 ++
> > > virt/kvm/iommu.c | 4 ++++
> > > 3 files changed, 8 insertions(+), 0 deletions(-)
> >
> > I suppose this would also be useful in Xen's pciback or any other system
> > which does passthrough? (Konrad CC'd for pciback)
>
> Definitely yes. Xen experiences the same issues when the PF driver is
> removed while VFs are assigned to guests.
>
> >
> > Is there some common lower layer we could hook this in to? (does
> > iommu_attach/detach_device make sense?) Or shall we just add the flag
> > manipulations to pciback as well?
> [Greg Rose]
>
> I was unaware of any common lower layers, i.e I didn't know that Xen
> also uses the iommu_attach/detach_device calls.
my mistake -- under Xen the iommu is driver by the hypervisor and not
the domain 0 kernel so there is no iommu_* in pciback.
> It took me a week of digging around in the KVM module code just to
> find these hooks.
I'm not actually sure where in pciback the right place to put this would
be is, perhaps Konrad has an idea.
> Generally I stick to Ethernet device drivers and I'm not that
> familiar with device pass through code. I was just confronted with a
> problem and looking for some way to fix it.
>
> ;^)
>
> That sounds like a good idea, let me have a look at it.
>
> - Greg
>
--
Ian Campbell
Traffic signals in New York are just rough guidelines.
-- David Letterman
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 16:21 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
Kirsher, Jeffrey T
In-Reply-To: <20110728.091448.548423057039764289.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, July 28, 2011 9:15 AM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> From: "Rose, Gregory V" <gregory.v.rose@intel.com>
> Date: Thu, 28 Jul 2011 08:51:05 -0700
>
> >> -----Original Message-----
> >> From: David Miller [mailto:davem@davemloft.net]
> >> Sent: Wednesday, July 27, 2011 10:28 PM
> >> To: Rose, Gregory V
> >> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey
> T
> >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> >>
> >> From: Greg Rose <gregory.v.rose@intel.com>
> >> Date: Wed, 27 Jul 2011 15:17:59 -0700
> >>
> >> > Add new set commands to configure the number of SR-IOV VFs, the
> >> > number of VM queues and spoof checking on/off switch.
> >> >
> >> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> >> > ---
> >> >
> >> > include/linux/ethtool.h | 11 ++++++++++-
> >> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> >> > index c6e427a..c4972ba 100644
> >> > --- a/include/linux/ethtool.h
> >> > +++ b/include/linux/ethtool.h
> >> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> >> > __u8 mdio_support;
> >> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> >> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> >> > + __u32 num_vfs; /* Enable SR-IOV VFs */
> >> > + __u32 num_vmqs; /* Set number of queues for VMDq */
> >>
> >> You can't change the layout of this datastructure in this way without
> >> breaking every ethtool binary out there.
> >>
> >> You have to find another place to add these knobs.
> >
> > Perhaps at the end of the ethtool_cmd structure? Something like this:
>
> Either use the two reserved u32's we have there, or create a new
> ethtool command and control structure.
OK, I see what you're saying. The size of the structure can never be changed. I'm slow sometimes but I do eventually get there. I didn't want to use the reserved u32's because I didn't know what they were reserved for. The num_vfs and num_vmqs values will actually never exceed 8 bits. I'll stuff them into the space used by one of the u32's and then add padding to align and keep the same structure size.
Thanks for the feedback and help. I'll address this and the other feedback I've gotten and come back later with V2 of the RFC.
- Greg
^ permalink raw reply
* [PATCH] sis190: Rx filter init is needed for MAC address change.
From: Francois Romieu @ 2011-07-28 16:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Klement Fish
From: Klement Fish <klement2@azet.sk>
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=34552
Signed-off-by: Klement Fish <klement2@azet.sk>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/sis190.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index 8ad7bfb..3c0f131 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -1825,6 +1825,16 @@ static int sis190_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
generic_mii_ioctl(&tp->mii_if, if_mii(ifr), cmd, NULL);
}
+static int sis190_mac_addr(struct net_device *dev, void *p)
+{
+ int rc;
+
+ rc = eth_mac_addr(dev, p);
+ if (!rc)
+ sis190_init_rxfilter(dev);
+ return rc;
+}
+
static const struct net_device_ops sis190_netdev_ops = {
.ndo_open = sis190_open,
.ndo_stop = sis190_close,
@@ -1833,7 +1843,7 @@ static const struct net_device_ops sis190_netdev_ops = {
.ndo_tx_timeout = sis190_tx_timeout,
.ndo_set_multicast_list = sis190_set_rx_mode,
.ndo_change_mtu = eth_change_mtu,
- .ndo_set_mac_address = eth_mac_addr,
+ .ndo_set_mac_address = sis190_mac_addr,
.ndo_validate_addr = eth_validate_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = sis190_netpoll,
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 2/2] ASIX: Use only 11 bits of header for data size
From: Marek Vasut @ 2011-07-28 16:17 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-l3A5Bk7waGM
In-Reply-To: <20110728151806.GB22202-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Thursday, July 28, 2011 05:18:06 PM Greg KH wrote:
> On Thu, Jul 28, 2011 at 08:06:18AM +0200, Marek Vasut wrote:
> > On Thursday, July 28, 2011 07:40:29 AM David Miller wrote:
> > > From: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Date: Wed, 27 Jul 2011 04:44:47 +0200
> > >
> > > > The AX88772B uses only 11 bits of the header for the actual size. The
> > > > other bits
> > > >
> > > > are used for something else. This causes dmesg full of messages:
> > > > asix_rx_fixup() Bad Header Length
> > > >
> > > > This patch trims the check to only 11 bits. I believe on older chips,
> > > > the remaining 5 top bits are unused.
> > > >
> > > > Signed-off-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >
> > > Applied.
> >
> > Hi, did you test it ?
> >
> > I left NOTEs outside the commit message:
> >
> > NOTE: If possible, can someone test/verify this patch with other ASIX
> > chips ? NOTE2: If Ack-ed, Greg, can you get this into -stable?
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
Yea I know ... I'm just so very tired (read dead). Sorry
>
> </formletter>
--
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: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: David Miller @ 2011-07-28 16:14 UTC (permalink / raw)
To: gregory.v.rose; +Cc: netdev, bhutchings, jeffrey.t.kirsher
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019414D509@orsmsx508.amr.corp.intel.com>
From: "Rose, Gregory V" <gregory.v.rose@intel.com>
Date: Thu, 28 Jul 2011 08:51:05 -0700
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Wednesday, July 27, 2011 10:28 PM
>> To: Rose, Gregory V
>> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
>> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>>
>> From: Greg Rose <gregory.v.rose@intel.com>
>> Date: Wed, 27 Jul 2011 15:17:59 -0700
>>
>> > Add new set commands to configure the number of SR-IOV VFs, the
>> > number of VM queues and spoof checking on/off switch.
>> >
>> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>> > ---
>> >
>> > include/linux/ethtool.h | 11 ++++++++++-
>> > 1 files changed, 10 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> > index c6e427a..c4972ba 100644
>> > --- a/include/linux/ethtool.h
>> > +++ b/include/linux/ethtool.h
>> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
>> > __u8 mdio_support;
>> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
>> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
>> > + __u32 num_vfs; /* Enable SR-IOV VFs */
>> > + __u32 num_vmqs; /* Set number of queues for VMDq */
>>
>> You can't change the layout of this datastructure in this way without
>> breaking every ethtool binary out there.
>>
>> You have to find another place to add these knobs.
>
> Perhaps at the end of the ethtool_cmd structure? Something like this:
Either use the two reserved u32's we have there, or create a new
ethtool command and control structure.
^ permalink raw reply
* Re: [Bug 40132] New: kernel BUG at mm/slab.c:501, when in kfree from ipv4_frags_exit_net
From: David Miller @ 2011-07-28 16:13 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110728083526.6f55bee9@nehalam.ftrdhcpuser.net>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Thu, 28 Jul 2011 08:35:26 -0700
>
>
> Begin forwarded message:
I think the first OOPS in path_init() potentially corrupts his memory,
and then all bets are off.
There's a lot of SUNRPC failures in these traces too.
Close this and tell the reporter to reopen the bug if it persists after
getting rid of the initial crashes that happen first.
^ permalink raw reply
* RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-07-28 15:58 UTC (permalink / raw)
To: Ian Campbell, Konrad Rzeszutek Wilk
Cc: netdev@vger.kernel.org, davem@davemloft.net,
bhutchings@solarflare.com, Kirsher, Jeffrey T, Jesse Barnes,
linux-pci@vger.kernel.org
In-Reply-To: <1311865877.24408.144.camel@cthulhu.hellion.org.uk>
> -----Original Message-----
> From: Ian Campbell [mailto:ijc@hellion.org.uk]
> Sent: Thursday, July 28, 2011 8:11 AM
> To: Rose, Gregory V; Konrad Rzeszutek Wilk
> Cc: netdev@vger.kernel.org; davem@davemloft.net;
> bhutchings@solarflare.com; Kirsher, Jeffrey T; Jesse Barnes; linux-
> pci@vger.kernel.org
> Subject: Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device has
> been assigned by KVM
>
> On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > Device drivers that create and destroy SR-IOV virtual functions via
> > calls to pci_enable_sriov() and pci_disable_sriov can cause catastrophic
> > failures if they attempt to destroy VFs while they are assigned to
> > guest virtual machines. By adding a flag for use by the KVM module
> > to indicate that a device is assigned a device driver can check that
> > flag and avoid destroying VFs while they are assigned and avoid system
> > failures.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > ---
> >
> > include/linux/pci.h | 2 ++
>
> I added Jesse and linux-pci to CC.
>
> > virt/kvm/assigned-dev.c | 2 ++
> > virt/kvm/iommu.c | 4 ++++
> > 3 files changed, 8 insertions(+), 0 deletions(-)
>
> I suppose this would also be useful in Xen's pciback or any other system
> which does passthrough? (Konrad CC'd for pciback)
Definitely yes. Xen experiences the same issues when the PF driver is removed while VFs are assigned to guests.
>
> Is there some common lower layer we could hook this in to? (does
> iommu_attach/detach_device make sense?) Or shall we just add the flag
> manipulations to pciback as well?
[Greg Rose]
I was unaware of any common lower layers, i.e I didn't know that Xen also uses the iommu_attach/detach_device calls. It took me a week of digging around in the KVM module code just to find these hooks. Generally I stick to Ethernet device drivers and I'm not that familiar with device pass through code. I was just confronted with a problem and looking for some way to fix it.
;^)
That sounds like a good idea, let me have a look at it.
- Greg
^ permalink raw reply
* RE: [RFC net-next PATCH 4/4] ixgbe: Add support for new ethtool settings
From: Rose, Gregory V @ 2011-07-28 15:52 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev@vger.kernel.org, davem@davemloft.net,
bhutchings@solarflare.com, Kirsher, Jeffrey T
In-Reply-To: <CAHXqBFJ30LLV=dgWuSK73rhxYLt5xoVFVwHdU3cWFmr_Yxs5pg@mail.gmail.com>
> -----Original Message-----
> From: Michał Mirosław [mailto:mirqus@gmail.com]
> Sent: Thursday, July 28, 2011 4:54 AM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; davem@davemloft.net;
> bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 4/4] ixgbe: Add support for new ethtool
> settings
>
> 2011/7/28 Greg Rose <gregory.v.rose@intel.com>:
> > Adds ixgbe driver support for new ethtool settings for SR-IOV re-init,
> > number of VM queues and anti-spoofing ON/OFF switch.
> [...]
> > +static int ixgbe_reinit_sriov(struct net_device *netdev, int new_vfs)
> > +{
> [...]
> > + if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED) {
> > + adapter->flags &= ~(IXGBE_FLAG_RSS_ENABLED |
> > + IXGBE_FLAG_DCB_ENABLED);
> > + netdev->features &= ~NETIF_F_RXHASH;
> > + } else {
> > + adapter->flags |= IXGBE_FLAG_RSS_ENABLED;
> > + netdev->features |= NETIF_F_RXHASH;
> > + }
>
> Please use ndo_fix_features/ndo_set_features callbacks for this.
OK, sure. I'll add a separate patch to do that.
- Greg
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 15:51 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
Kirsher, Jeffrey T
In-Reply-To: <20110727.222749.1654973220321763098.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, July 27, 2011 10:28 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Wed, 27 Jul 2011 15:17:59 -0700
>
> > Add new set commands to configure the number of SR-IOV VFs, the
> > number of VM queues and spoof checking on/off switch.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > ---
> >
> > include/linux/ethtool.h | 11 ++++++++++-
> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > index c6e427a..c4972ba 100644
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > __u8 mdio_support;
> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > + __u32 num_vfs; /* Enable SR-IOV VFs */
> > + __u32 num_vmqs; /* Set number of queues for VMDq */
>
> You can't change the layout of this datastructure in this way without
> breaking every ethtool binary out there.
>
> You have to find another place to add these knobs.
Perhaps at the end of the ethtool_cmd structure? Something like this:
/* This should work for both 32 and 64 bit userland. */
struct ethtool_cmd {
__u32 cmd;
__u32 supported; /* Features this interface supports */
__u32 advertising; /* Features this interface advertises */
__u16 speed; /* The forced speed (lower bits) in
* Mbps. Please use
* ethtool_cmd_speed()/_set() to
* access it */
__u8 duplex; /* Duplex, half or full */
__u8 port; /* Which connector port */
__u8 phy_address;
__u8 transceiver; /* Which transceiver to use */
__u8 autoneg; /* Enable or disable autonegotiation */
__u8 mdio_support;
__u32 maxtxpkt; /* Tx pkts before generating tx int */
__u32 maxrxpkt; /* Rx pkts before generating rx int */
__u16 speed_hi; /* The forced speed (upper
* bits) in Mbps. Please use
* ethtool_cmd_speed()/_set() to
* access it */
__u8 eth_tp_mdix;
__u8 spoof_check; /* Enable/Disable anti-spoofing */
__u32 lp_advertising; /* Features the link partner advertises */
__u32 reserved[2];
__u32 num_vfs; /* Enable SR-IOV VFs */
__u32 num_vmqs; /* Set number of queues for VMDq */
};
- Greg
^ permalink raw reply
* RE: [RFC net-next PATCH 2/4] ixgbe: Reconfigure SR-IOV Init
From: Rose, Gregory V @ 2011-07-28 15:44 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
Kirsher, Jeffrey T
In-Reply-To: <20110727.222653.1937782529626247279.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, July 27, 2011 10:27 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 2/4] ixgbe: Reconfigure SR-IOV Init
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Wed, 27 Jul 2011 15:17:54 -0700
>
> > + int i;
> > + for (i = 0; i < adapter->num_vfs; i++) {
> > + if (adapter->vfinfo[i].vfdev->dev_flags &
> > + PCI_DEV_FLAGS_ASSIGNED) {
> > + return true;
> > + }
> > + }
>
> Bad formatting and indentation, please fix this.
Will do.
>
> > + pvfdev = pci_get_device(IXGBE_INTEL_VENDOR_ID, device_id,
> NULL);
> > + while (pvfdev) {
> > + if (pvfdev->devfn == thisvf_devfn)
> > + break;
> > + pvfdev = pci_get_device(IXGBE_INTEL_VENDOR_ID,
> > + device_id, pvfdev);
> > + }
> > + if (pvfdev)
> > + adapter->vfinfo[vfn].vfdev = pvfdev;
>
> pci_get_*() grabs a reference to any non-NULL pci device object
> returned, where does this reference get released? I scanned
> all uses of x.vfdev and x->vfdev and could not find the necessary
> release.
I was ignorant of this behavior. I'll fix it.
- Greg
^ permalink raw reply
* Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups
From: Stephen Hemminger @ 2011-07-28 15:41 UTC (permalink / raw)
To: David Lamparter; +Cc: Nick Carter, netdev, Michał Mirosław, davem
In-Reply-To: <20110727111714.GA2027462@jupiter.n2.diac24.net>
On Wed, 27 Jul 2011 13:17:15 +0200
David Lamparter <equinox@diac24.net> wrote:
> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > > > >> I am still undecided on this. Understand the need, but don't like idea
> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
> > > > >> has any input.
> > > > >
> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
> > > > > is 0, which just keeps the old behaviour.
> >
> > P.S.: I'd like to once more stress this. In my opinion the patch should
> > be merged because it provides desireable functionality at a small cost
> > (one test, one knob) and __does not change any default behaviour__.
>
> Stephen, anything new on this?
No.
Don't like adding yet another hack user visible API which will have
to be maintained for too long. But on the other hand I don't have
a better solution at my finger tips. If better idea doesn't come
along, then we can go with yours.
^ permalink raw reply
* Fw: [Bug 40132] New: kernel BUG at mm/slab.c:501, when in kfree from ipv4_frags_exit_net
From: Stephen Hemminger @ 2011-07-28 15:35 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 26 Jul 2011 13:49:14 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 40132] New: kernel BUG at mm/slab.c:501, when in kfree from ipv4_frags_exit_net
https://bugzilla.kernel.org/show_bug.cgi?id=40132
Summary: kernel BUG at mm/slab.c:501, when in kfree from
ipv4_frags_exit_net
Product: Networking
Version: 2.5
Kernel Version: 3.0.0-03370-gb6844e8
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: baryluk@smp.if.uj.edu.pl
Regression: No
Created an attachment (id=66702)
--> (https://bugzilla.kernel.org/attachment.cgi?id=66702)
Kernel config
Happens 16.3% of times. gcc 4.4.5. i386. Debian GNU/Linux stable (squeeze).
It is probably one of the most rearly tested cleanup routines in kernel. I
discovered it by incident because of the bug in kdevtmpfs initialization.
[ 9.802917] BUG: unable to handle kernel paging request at 61203a73
[ 9.803237] IP: [<c115ed37>] path_init+0xc7/0x3b0
[ 9.803584] *pdpt = 0000000000000000 *pde = 0000000000000000
[ 9.803940] Oops: 0000 [#1] PREEMPT SMP
[ 9.804223] Modules linked in:
[ 9.804434]
[ 9.804615] Pid: 13, comm: kdevtmpfs Not tainted 3.0.0-t43-03370-gb6844e8
#22 Bochs Bochs
[ 9.804980] EIP: 0060:[<c115ed37>] EFLAGS: 00000246 CPU: 0
[ 9.805223] EIP is at path_init+0xc7/0x3b0
[ 9.805402] EAX: ffffff9c EBX: c78e1e90 ECX: 00000050 EDX: 00001050
[ 9.805643] ESI: 61203a73 EDI: 61203a73 EBP: c78e1e20 ESP: c78e1df8
[ 9.805888] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 9.806119] Process kdevtmpfs (pid: 13, ti=c78e0000 task=c78de1a0
task.ti=c78e0000)
[ 9.806407] Stack:
[ 9.806528] c78e1e00 00000e44 00000000 c78e1e14 00000e44 c78e1e14 c109446d
c78e1e90
[ 9.806998] c78e1f44 61203a73 c78e1e68 c115ff21 c78e1e90 c78e1e58 c17a9da7
c78ba0e0
[ 9.807432] c78e1e48 00000006 00000050 c78de1a0 c78e1e58 c10985c1 c7d47d00
c1a787e0
[ 9.807882] Call Trace:
[ 9.808047] [<c109446d>] ? put_lock_stats+0xd/0x30
[ 9.808263] [<c115ff21>] path_lookupat+0x31/0x5d0
[ 9.808469] [<c17a9da7>] ? _raw_spin_unlock_irq+0x27/0x60
[ 9.808697] [<c10985c1>] ? trace_hardirqs_on_caller+0x61/0xa0
[ 9.808938] [<c11604ec>] do_path_lookup+0x2c/0xb0
[ 9.809150] [<c1160656>] kern_path_create+0x26/0xe0
[ 9.809360] [<c17a69aa>] ? schedule+0x3a/0x770
[ 9.809562] [<c1094482>] ? put_lock_stats+0x22/0x30
[ 9.809776] [<c1413531>] handle_create+0x31/0x100
[ 9.809985] [<c17a7462>] ? preempt_schedule+0x32/0x50
[ 9.810146] [<c17a9d74>] ? _raw_spin_unlock_irqrestore+0x74/0x80
[ 9.810146] [<c104749b>] ? complete+0x4b/0x60
[ 9.810146] [<c14139b5>] devtmpfsd+0xf5/0x150
[ 9.810146] [<c14138c0>] ? handle_remove+0x200/0x200
[ 9.810146] [<c107dac4>] kthread+0x74/0x80
[ 9.810146] [<c107da50>] ? __init_kthread_worker+0x60/0x60
[ 9.810146] [<c17b0e7a>] kernel_thread_helper+0x6/0x10
[ 9.810146] Code: f3 ff 8b 53 04 8b 42 04 a8 01 0f 85 b5 02 00 00 89 43 24
31 ff 89 f8 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3 c7 43 14 00 00 00 00
[ 9.810146] 3e 2f 0f 84 c8 00 00 00 83 f8 9c 74 5b 8d 55 f0 bf f7 ff ff
[ 9.810146] EIP: [<c115ed37>] path_init+0xc7/0x3b0 SS:ESP 0068:c78e1df8
[ 9.810146] CR2: 0000000061203a73
[ 9.815606] kobject: 'hpet' (c7b77220): kobject_add_internal: parent:
'drivers', set: 'drivers'
[ 9.816880] kobject: 'hpet' (c7b77220): kobject_uevent_env
[ 9.817122] kobject: 'hpet' (c7b77220): fill_kobj_path: path =
'/bus/acpi/drivers/hpet'
[ 9.818518] kobject: 'nvram' (c7b6dc08): kobject_add_internal: parent:
'misc', set: 'devices'
[ 9.819257] ---[ end trace b8a3675a10c16a9a ]---
[ 9.819558] kdevtmpfs used greatest stack depth: 6172 bytes left
[ 9.872251] kobject: 'rx-0' (c798c9a8): kobject_cleanup
[ 9.872471] kobject: 'rx-0' (c798c9a8): auto cleanup 'remove' event
[ 9.872705] kobject: 'rx-0' (c798c9a8): kobject_uevent_env
[ 9.872930] kobject: 'rx-0' (c798c9a8): fill_kobj_path: path =
'/devices/virtual/net/lo/queues/rx-0'
[ 9.874037] kobject: 'rx-0' (c798c9a8): auto cleanup kobject_del
[ 9.874359] kobject: 'rx-0' (c798c9a8): calling ktype release
[ 9.874608] kobject: 'rx-0': free name
[ 9.874795] kobject: 'tx-0' (c798b950): kobject_cleanup
[ 9.874996] kobject: 'tx-0' (c798b950): auto cleanup 'remove' event
[ 9.875227] kobject: 'tx-0' (c798b950): kobject_uevent_env
[ 9.875469] kobject: 'tx-0' (c798b950): fill_kobj_path: path =
'/devices/virtual/net/lo/queues/tx-0'
[ 9.876721] kobject: 'tx-0' (c798b950): auto cleanup kobject_del
[ 9.880057] kobject: 'tx-0' (c798b950): calling ktype release
[ 9.881695] kobject: 'tx-0': free name
[ 9.881878] kobject: 'queues' (c798b870): kobject_cleanup
[ 9.882082] kobject: 'queues' (c798b870): auto cleanup kobject_del
[ 9.882349] kobject: 'queues' (c798b870): calling ktype release
[ 9.882579] kobject: 'queues' (c798b870): kset_release
[ 9.882789] kobject: 'queues': free name
[ 9.884069] kobject: 'lo' (c7996acc): kobject_uevent_env
[ 9.884287] kobject: 'lo' (c7996acc): fill_kobj_path: path =
'/devices/virtual/net/lo'
[ 9.885368] kobject: 'net' (c798c960): kobject_cleanup
[ 9.885573] kobject: 'net' (c798c960): auto cleanup kobject_del
[ 9.885834] kobject: 'net' (c798c960): calling ktype release
[ 9.886061] kobject: 'net': free name
[ 9.892232] kobject: 'lo' (c7996acc): kobject_cleanup
[ 9.892552] kobject: 'lo' (c7996acc): calling ktype release
[ 9.892914] kobject: 'lo': free name
[ 9.893865] ------------[ cut here ]------------
[ 9.894234] WARNING: at fs/proc/generic.c:850
remove_proc_entry+0x26a/0x270()
[ 9.894548] Hardware name: Bochs
[ 9.894730] remove_proc_entry: removing non-empty directory 'net/rpc',
leaking at least 'nfs'
[ 9.895070] Modules linked in:
[ 9.895384] Pid: 14, comm: kworker/u:1 Tainted: G D
3.0.0-t43-03370-gb6844e8 #22
[ 9.895733] Call Trace:
[ 9.895943] [<c105bb52>] warn_slowpath_common+0x72/0xa0
[ 9.896205] [<c11ab88a>] ? remove_proc_entry+0x26a/0x270
[ 9.896450] [<c11ab88a>] ? remove_proc_entry+0x26a/0x270
[ 9.896705] [<c105bc23>] warn_slowpath_fmt+0x33/0x40
[ 9.896943] [<c11ab88a>] remove_proc_entry+0x26a/0x270
[ 9.897233] [<c1140265>] ? kfree+0xc5/0x280
[ 9.897457] [<c16fa2a7>] ? ip_map_cache_destroy+0x97/0xb0
[ 9.897708] [<c1098579>] ? trace_hardirqs_on_caller+0x19/0xa0
[ 9.897966] [<c109860b>] ? trace_hardirqs_on+0xb/0x10
[ 9.898206] [<c17a9cdc>] ? _raw_spin_unlock+0x2c/0x50
[ 9.898446] [<c17006cd>] ? sunrpc_destroy_cache_detail+0x6d/0xc0
[ 9.898719] [<c16fec48>] ? remove_cache_proc_entries+0x68/0xf0
[ 9.898993] [<c1704b54>] rpc_proc_exit+0x24/0x40
[ 9.899217] [<c16fe0a7>] sunrpc_exit_net+0x17/0x20
[ 9.899450] [<c159eaef>] ops_exit_list+0x2f/0x50
[ 9.899676] [<c159f369>] cleanup_net+0xd9/0x170
[ 9.899905] [<c10778d8>] process_one_work+0x1d8/0x4c0
[ 9.905162] [<c107785c>] ? process_one_work+0x15c/0x4c0
[ 9.905439] [<c159f290>] ? register_pernet_subsys+0x40/0x40
[ 9.905678] [<c1078b70>] worker_thread+0x140/0x3a0
[ 9.905886] [<c17a7462>] ? preempt_schedule+0x32/0x50
[ 9.906104] [<c1078a30>] ? manage_workers+0x110/0x110
[ 9.906317] [<c107dac4>] kthread+0x74/0x80
[ 9.906509] [<c107da50>] ? __init_kthread_worker+0x60/0x60
[ 9.906740] [<c17b0e7a>] kernel_thread_helper+0x6/0x10
[ 9.906981] ---[ end trace b8a3675a10c16a9b ]---
[ 9.907540] ------------[ cut here ]------------
[ 9.907738] kernel BUG at mm/slab.c:501!
[ 9.907909] invalid opcode: 0000 [#2] PREEMPT SMP
[ 9.908150] Modules linked in:
[ 9.908296]
[ 9.908385] Pid: 14, comm: kworker/u:1 Tainted: G D W
3.0.0-t43-03370-gb6844e8 #22 Bochs Bochs
[ 9.908755] EIP: 0060:[<c1140383>] EFLAGS: 00000046 CPU: 0
[ 9.908971] EIP is at kfree+0x1e3/0x280
[ 9.909136] EAX: 40000400 EBX: c7f31920 ECX: c11401df EDX: c87fd000
[ 9.909370] ESI: c1ac9b60 EDI: c15f5f39 EBP: c78edebc ESP: c78ede90
[ 9.909604] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 9.909813] Process kworker/u:1 (pid: 14, ti=c78ec000 task=c78ea1c0
task.ti=c78ec000)
[ 9.910117] Stack:
[ 9.910220] c7abdbc0 c7a234e0 c251b2c0 00000282 c780e800 00000286 c19fcd82
c1ac9b60
[ 9.910477] c251b2c0 c1ac9b60 c78edee8 c78edecc c15f5f39 c1ac9b40 c251b2c0
c78edee0
[ 9.910477] c159eaef c78edee8 c1ac9b40 c1ac3428 c78edf04 c159f369 c251b300
c251b300
[ 9.910477] Call Trace:
[ 9.910477] [<c15f5f39>] ipv4_frags_exit_net+0x29/0x50
[ 9.910477] [<c159eaef>] ops_exit_list+0x2f/0x50
[ 9.910477] [<c159f369>] cleanup_net+0xd9/0x170
[ 9.910477] [<c10778d8>] process_one_work+0x1d8/0x4c0
[ 9.910477] [<c107785c>] ? process_one_work+0x15c/0x4c0
[ 9.910477] [<c159f290>] ? register_pernet_subsys+0x40/0x40
[ 9.910477] [<c1078b70>] worker_thread+0x140/0x3a0
[ 9.910477] [<c17a7462>] ? preempt_schedule+0x32/0x50
[ 9.910477] [<c1078a30>] ? manage_workers+0x110/0x110
[ 9.910477] [<c107dac4>] kthread+0x74/0x80
[ 9.910477] [<c107da50>] ? __init_kthread_worker+0x60/0x60
[ 9.910477] [<c17b0e7a>] kernel_thread_helper+0x6/0x10
[ 9.910477] Code: e9 fa fe ff ff 8b 55 ec 89 f1 89 d8 83 c2 38 89 55 e4 c7
04 24 00 00 00 00 e8 da fc ff ff 89 f1 c1 e1 02 89 75 e0 89 4d dc eb 9f <0f> 0b
eb fe 8b 5b 0c e9 86 fe ff ff 8b 5b 0c e9 6e fe ff ff 89
[ 9.910477] EIP: [<c1140383>] kfree+0x1e3/0x280 SS:ESP 0068:c78ede90
[ 9.910477] ---[ end trace b8a3675a10c16a9c ]---
[ 9.918123] BUG: unable to handle kernel paging request at fffffffc
[ 9.918410] IP: [<c107d61f>] kthread_data+0xf/0x20
[ 9.918630] *pdpt = 0000000001ce7001 *pde = 0000000001cec067 *pte =
0000000000000000
[ 9.918990] Oops: 0000 [#3] PREEMPT SMP
[ 9.919197] Modules linked in:
[ 9.919339]
[ 9.919426] Pid: 14, comm: kworker/u:1 Tainted: G D W
3.0.0-t43-03370-gb6844e8 #22 Bochs Bochs
[ 9.919791] EIP: 0060:[<c107d61f>] EFLAGS: 00000002 CPU: 0
[ 9.920005] EIP is at kthread_data+0xf/0x20
[ 9.920206] EAX: 00000000 EBX: 00000000 ECX: c1cddd00 EDX: 00000000
[ 9.920468] ESI: 00000000 EDI: c1cddd00 EBP: c78edcac ESP: c78edca0
[ 9.920718] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 9.920942] Process kworker/u:1 (pid: 14, ti=c78ec000 task=c78ea1c0
task.ti=c78ec000)
[ 9.921247] Stack:
[ 9.921348] c10767b1 c78ea1c0 00000000 c78edd3c c17a6ef9 00000000 c1a6cb90
c2426f80
[ 9.921822] c10cc943 c78edcec 00000004 c1cddd00 c1cddd00 c1cddd00 c7d433a0
c78edce4
[ 9.922295] c7d47d00 c78ea1c0 00000202 00000001 00000202 c78ea1c0 c78ea1c0
00000001
[ 9.922878] Call Trace:
[ 9.923018] [<c10767b1>] ? wq_worker_sleeping+0x11/0x80
[ 9.923257] [<c17a6ef9>] schedule+0x589/0x770
[ 9.923466] [<c10cc943>] ? __call_rcu+0xd3/0x190
[ 9.923687] [<c10cca12>] ? call_rcu+0x12/0x20
[ 9.923894] [<c1085b35>] ? creds_are_invalid+0x25/0x60
[ 9.924127] [<c1085bdd>] ? __validate_process_creds+0x6d/0xd0
[ 9.924394] [<c10963be>] ? print_held_locks_bug+0xe/0x80
[ 9.924636] [<c105fb2d>] do_exit+0x20d/0x3e0
[ 9.924843] [<c17ab2e5>] oops_end+0x95/0xd0
[ 9.925056] [<c1015e04>] die+0x54/0x80
[ 9.925243] [<c17aa9f6>] do_trap+0x96/0xd0
[ 9.925443] [<c1013e30>] ? do_coprocessor_segment_overrun+0x90/0x90
[ 9.925716] [<c1013ebc>] do_invalid_op+0x8c/0xb0
[ 9.925935] [<c1140383>] ? kfree+0x1e3/0x280
[ 9.926141] [<c17a9d65>] ? _raw_spin_unlock_irqrestore+0x65/0x80
[ 9.926404] [<c1098579>] ? trace_hardirqs_on_caller+0x19/0xa0
[ 9.926661] [<c17a9d44>] ? _raw_spin_unlock_irqrestore+0x44/0x80
[ 9.926925] [<c134c0ae>] ? debug_object_active_state+0xde/0x120
[ 9.927187] [<c17aa7ab>] ? error_code+0x5b/0x64
[ 9.927398] [<c1013e30>] ? do_coprocessor_segment_overrun+0x90/0x90
[ 9.927467] [<c1094540>] ? trace_hardirqs_off_caller+0x20/0x130
[ 9.927467] [<c133904c>] ? trace_hardirqs_off_thunk+0xc/0x10
[ 9.927467] [<c17aa7af>] error_code+0x5f/0x64
[ 9.927467] [<c11401df>] ? kfree+0x3f/0x280
[ 9.927467] [<c15f5f39>] ? ipv4_frags_exit_net+0x29/0x50
[ 9.927467] [<c1013e30>] ? do_coprocessor_segment_overrun+0x90/0x90
[ 9.927467] [<c1140383>] ? kfree+0x1e3/0x280
[ 9.927467] [<c15f5f39>] ipv4_frags_exit_net+0x29/0x50
[ 9.927467] [<c159eaef>] ops_exit_list+0x2f/0x50
[ 9.927467] [<c159f369>] cleanup_net+0xd9/0x170
[ 9.927467] [<c10778d8>] process_one_work+0x1d8/0x4c0
[ 9.927467] [<c107785c>] ? process_one_work+0x15c/0x4c0
[ 9.927467] [<c159f290>] ? register_pernet_subsys+0x40/0x40
[ 9.927467] [<c1078b70>] worker_thread+0x140/0x3a0
[ 9.927467] [<c17a7462>] ? preempt_schedule+0x32/0x50
[ 9.927467] [<c1078a30>] ? manage_workers+0x110/0x110
[ 9.927467] [<c107dac4>] kthread+0x74/0x80
[ 9.927467] [<c107da50>] ? __init_kthread_worker+0x60/0x60
[ 9.927467] [<c17b0e7a>] kernel_thread_helper+0x6/0x10
[ 9.927467] Code: 8d 74 26 00 64 a1 ac 7d b9 c1 8b 80 6c 02 00 00 5d 8b 40
f8 c3 8d b4 26 00 00 00 00 55 89 e5 3e 8d 74 26 00 8b 80 6c 02 00 00 5d <8b> 40
fc c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 3e
[ 9.927467] EIP: [<c107d61f>] kthread_data+0xf/0x20 SS:ESP 0068:c78edca0
[ 9.927467] CR2: 00000000fffffffc
[ 9.927467] ---[ end trace b8a3675a10c16a9d ]---
[ 9.927467] Fixing recursive fault but reboot is needed!
No further messages. Kernel freezes.
On 100/1000 of cases, there is line:
[ 5.843059] remove_proc_entry: removing non-empty directory 'net/rpc',
leaking at least 'auth.unix.gid'
And on 63/1000 of cases, there is instead:
[ 9.972779] remove_proc_entry: removing non-empty directory 'net/rpc',
leaking at least 'nfs'
Full kernel message from serial line in qemu attached and config.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 2/2] ASIX: Use only 11 bits of header for data size
From: Greg KH @ 2011-07-28 15:18 UTC (permalink / raw)
To: Marek Vasut; +Cc: David Miller, linux-kernel, netdev, linux-usb, gregkh
In-Reply-To: <201107280806.18813.marek.vasut@gmail.com>
On Thu, Jul 28, 2011 at 08:06:18AM +0200, Marek Vasut wrote:
> On Thursday, July 28, 2011 07:40:29 AM David Miller wrote:
> > From: Marek Vasut <marek.vasut@gmail.com>
> > Date: Wed, 27 Jul 2011 04:44:47 +0200
> >
> > > The AX88772B uses only 11 bits of the header for the actual size. The
> > > other bits
> > >
> > > are used for something else. This causes dmesg full of messages:
> > > asix_rx_fixup() Bad Header Length
> > >
> > > This patch trims the check to only 11 bits. I believe on older chips, the
> > > remaining 5 top bits are unused.
> > >
> > > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> >
> > Applied.
>
> Hi, did you test it ?
>
> I left NOTEs outside the commit message:
>
> NOTE: If possible, can someone test/verify this patch with other ASIX chips ?
> NOTE2: If Ack-ed, Greg, can you get this into -stable?
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
From: Ian Campbell @ 2011-07-28 15:11 UTC (permalink / raw)
To: Greg Rose, Konrad Rzeszutek Wilk
Cc: netdev, davem, bhutchings, jeffrey.t.kirsher, Jesse Barnes,
linux-pci
In-Reply-To: <20110727221749.8435.19000.stgit@gitlad.jf.intel.com>
On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> Device drivers that create and destroy SR-IOV virtual functions via
> calls to pci_enable_sriov() and pci_disable_sriov can cause catastrophic
> failures if they attempt to destroy VFs while they are assigned to
> guest virtual machines. By adding a flag for use by the KVM module
> to indicate that a device is assigned a device driver can check that
> flag and avoid destroying VFs while they are assigned and avoid system
> failures.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> ---
>
> include/linux/pci.h | 2 ++
I added Jesse and linux-pci to CC.
> virt/kvm/assigned-dev.c | 2 ++
> virt/kvm/iommu.c | 4 ++++
> 3 files changed, 8 insertions(+), 0 deletions(-)
I suppose this would also be useful in Xen's pciback or any other system
which does passthrough? (Konrad CC'd for pciback)
Is there some common lower layer we could hook this in to? (does
iommu_attach/detach_device make sense?) Or shall we just add the flag
manipulations to pciback as well?
Ian.
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 2d29218..a297ca2 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -174,6 +174,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG = (__force pci_dev_flags_t) 1,
> /* Device configuration is irrevocably lost if disabled into D3 */
> PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> + /* Provide indication device is assigned by KVM */
> + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> };
>
> enum pci_irq_reroute_variant {
> diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
> index 6cc4b97..f401de1 100644
> --- a/virt/kvm/assigned-dev.c
> +++ b/virt/kvm/assigned-dev.c
> @@ -205,6 +205,8 @@ static void kvm_free_assigned_device(struct kvm *kvm,
> else
> pci_restore_state(assigned_dev->dev);
>
> + assigned_dev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +
> pci_release_regions(assigned_dev->dev);
> pci_disable_device(assigned_dev->dev);
> pci_dev_put(assigned_dev->dev);
> diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
> index 62a9caf..cffc530 100644
> --- a/virt/kvm/iommu.c
> +++ b/virt/kvm/iommu.c
> @@ -181,6 +181,8 @@ int kvm_assign_device(struct kvm *kvm,
> goto out_unmap;
> }
>
> + pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> +
> printk(KERN_DEBUG "assign device %x:%x:%x.%x\n",
> assigned_dev->host_segnr,
> assigned_dev->host_busnr,
> @@ -209,6 +211,8 @@ int kvm_deassign_device(struct kvm *kvm,
>
> iommu_detach_device(domain, &pdev->dev);
>
> + pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +
> printk(KERN_DEBUG "deassign device %x:%x:%x.%x\n",
> assigned_dev->host_segnr,
> assigned_dev->host_busnr,
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ian Campbell
All progress is based upon a universal innate desire of every organism
to live beyond its income.
-- Samuel Butler, "Notebooks"
^ permalink raw reply
* Re: r8169 driver crashes in 2.6.32.43
From: Francois Romieu @ 2011-07-28 14:47 UTC (permalink / raw)
To: Kasper Dupont; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110728125437.GA24876@colin.search.kasperd.net>
Kasper Dupont <kasperd@cpvhh.24.jul.2011.kasperd.net> :
> On 28/07/11 14.45, Kasper Dupont wrote:
> > On 28/07/11 14.23, Francois Romieu wrote:
> > > You can replace them with plain printk(KERN_{INFO/ERR} "S: ...).
> >
> > Then it compiles, will let you know shortly how it works out.
>
> The last 24 lines before network stopped working:
[...]
> S: 000000c0
> FEmp
> S: 000000c0
> FEmp
> S: 00000040
> S: 000000c4
> S: 00000044
> S: 00000040
Can you revert the last patch and apply the one below ?
Network traffic capture at the remote end of the link would be welcome,
especially ethernet MAC control frames.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7d9c650..b79fa86 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -287,6 +287,7 @@ enum rtl_registers {
/* Unlimited maximum PCI burst. */
#define RX_DMA_BURST (7 << RXCFG_DMA_SHIFT)
+ TimerCount = 0x48,
RxMissed = 0x4c,
Cfg9346 = 0x50,
Config0 = 0x51,
@@ -395,6 +396,7 @@ enum rtl_register_content {
/* InterruptStatusBits */
SYSErr = 0x8000,
PCSTimeout = 0x4000,
+ RxFIFOEmpty = 0x0200, /* 816x something only ? */
SWInt = 0x0100,
TxDescUnavail = 0x0080,
RxFIFOOver = 0x0040,
@@ -5110,8 +5112,9 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
tp->cur_tx += frags + 1;
- wmb();
+ mmiowb();
+ RTL_W32(TimerCount, 12500);
RTL_W8(TxPoll, NPQ);
if (TX_BUFFS_AVAIL(tp) < MAX_SKB_FRAGS) {
@@ -5222,15 +5225,6 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
(TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
}
- /*
- * 8168 hack: TxPoll requests are lost when the Tx packets are
- * too close. Let's kick an extra TxPoll request when a burst
- * of start_xmit activity is detected (if it is not detected,
- * it is slow enough). -- FR
- */
- smp_rmb();
- if (tp->cur_tx != dirty_tx)
- RTL_W8(TxPoll, NPQ);
}
}
@@ -5379,11 +5373,21 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
break;
}
+ if (unlikely(status & PCSTimeout)) {
+ printk(KERN_INFO "%08lx %08x %08x %08x %08x %08x\n",
+ jiffies, status, tp->cur_rx, tp->dirty_rx,
+ tp->cur_tx, tp->dirty_tx);
+ smp_rmb();
+ if (tp->cur_tx != tp->dirty_tx)
+ RTL_W8(TxPoll, NPQ);
+ }
+
if (unlikely(status & RxFIFOOver)) {
switch (tp->mac_version) {
+ int i;
+
/* Work around for rx fifo overflow */
case RTL_GIGA_MAC_VER_11:
- case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_26:
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
@@ -5399,6 +5403,21 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
case RTL_GIGA_MAC_VER_28:
case RTL_GIGA_MAC_VER_31:
/* Experimental science. Pktgen proof. */
+ case RTL_GIGA_MAC_VER_22:
+ printk(KERN_INFO "%08lx %08x %08x %08x %08x %08x\n",
+ jiffies, status,
+ tp->cur_rx, tp->dirty_rx,
+ tp->cur_tx, tp->dirty_tx);
+ for (i = 0; i < 4000000; i++) {
+ if (RTL_R16(IntrStatus) & RxFIFOEmpty) {
+ RTL_W16(IntrStatus, RxFIFOOver);
+ printk(KERN_INFO "FEmp %d\n", i);
+ break;
+ }
+ udelay(10);
+ }
+ if (i >= 4000000)
+ printk(KERN_ERR "no FEmp\n");
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_25:
if (status == RxFIFOOver)
^ permalink raw reply related
* Re: Oops when insmod rtl8192ce
From: Larry Finger @ 2011-07-28 14:56 UTC (permalink / raw)
To: hubert Liao
Cc: John W. Linville, wlanfae, Chaoming Li, linux-wireless, netdev,
linux-kernel
In-Reply-To: <CAMzZzFH8xBdiEN-rV1XE-1ZhFbzO_tcnA75Hpx_AyJ6LtWq01A@mail.gmail.com>
On 07/28/2011 02:06 AM, hubert Liao wrote:
> 2011/7/27 John W. Linville<linville@tuxdriver.com>:
>> On Wed, Jul 27, 2011 at 05:20:15PM +0800, hubert Liao wrote:
>>> Hi,
>>>
>>> We got an oops when insmod rtl8192ce module (the board is an ARM soc),
>>> accroding the oops message, find it's because in rtl_pci_probe() called
>>> _rtl_pci_find_adapter(),
>>> in this funcation, the pdev->bus->self is a NULL pointer .
>>>
>>> static boot _rtl_pci_find_adapter(strcut pci_dev *dev,
>>> struct ieee80211_hw *hw)
>>> {
>>>
>>> struct pci_dev *bridge_pdev = pdev->bus->self; //line 1601
>>> ...
>>>
>>> pcipriv->ndis_adapter.pcibridge_vendorid = bridge_pdev->vendor;<-- [oops
>>> here] line 1700
>>>
>>> ...
>>> }
>>>
>>> here, I just want to know why the bus->self is NULL?
>>
>> pdev is coming straight from what is passed to the PCI probe routine.
>> It seems like pdev->bus->self should already be set before that
>> happens.
>>
> Yes, I think it should be initialized when added the pci bus bridge,
> I have checked the mach-kirkwood(my board is arch/arm/mach-kirkwood)
> pcie related code, and I think when system initialized should call
> kirkwood_pcie_init() ->
> kirkwood_pcie_scan_bus() ->
> pci_scan_bus() ->
> pci_bus_add_devices()
> if the pci_bus->self was initialized in pci_bus_add_devices()?
> Maybe the code is too complex for me , I really can not find where
> set the “->self" member?
I added a request to the bugzilla entry to post the full dmesg output there.
Perhaps there is some clue in the bus setup.
Larry
^ permalink raw reply
* Re: invalid requirement from ethtool?
From: Eli Cohen @ 2011-07-28 14:55 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1311848553.2619.1.camel@deadeye>
On Thu, Jul 28, 2011 at 12:22:33PM +0200, Ben Hutchings wrote:
>
> The ethtool core doesn't check the values in struct ethtool_coalesce, so
> the rules are really driver-specific.
>
Exactly. That's why I think those comments are not in place.
^ permalink raw reply
* [PATCH] ip6tnl: avoid touching dst refcount in ip6_tnl_xmit2()
From: Eric Dumazet @ 2011-07-28 14:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Even using percpu stats, we still hit tunnel dst_entry refcount in
ip6_tnl_xmit2()
Since we are in RCU locked section, we can use skb_dst_set_noref() and
avoid these atomic operations, leaving dst shared on cpus.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv6/ip6_tunnel.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0bc9888..6fb1fb3 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -889,7 +889,7 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
struct net_device_stats *stats = &t->dev->stats;
struct ipv6hdr *ipv6h = ipv6_hdr(skb);
struct ipv6_tel_txoption opt;
- struct dst_entry *dst;
+ struct dst_entry *dst, *ndst = NULL;
struct net_device *tdev;
int mtu;
unsigned int max_headroom = sizeof(struct ipv6hdr);
@@ -897,19 +897,19 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
int err = -1;
int pkt_len;
- if ((dst = ip6_tnl_dst_check(t)) != NULL)
- dst_hold(dst);
- else {
- dst = ip6_route_output(net, NULL, fl6);
+ dst = ip6_tnl_dst_check(t);
+ if (!dst) {
+ ndst = ip6_route_output(net, NULL, fl6);
- if (dst->error)
+ if (ndst->error)
goto tx_err_link_failure;
- dst = xfrm_lookup(net, dst, flowi6_to_flowi(fl6), NULL, 0);
- if (IS_ERR(dst)) {
- err = PTR_ERR(dst);
- dst = NULL;
+ ndst = xfrm_lookup(net, ndst, flowi6_to_flowi(fl6), NULL, 0);
+ if (IS_ERR(ndst)) {
+ err = PTR_ERR(ndst);
+ ndst = NULL;
goto tx_err_link_failure;
}
+ dst = ndst;
}
tdev = dst->dev;
@@ -955,7 +955,7 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
skb = new_skb;
}
skb_dst_drop(skb);
- skb_dst_set(skb, dst_clone(dst));
+ skb_dst_set_noref(skb, dst);
skb->transport_header = skb->network_header;
@@ -987,13 +987,14 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
stats->tx_errors++;
stats->tx_aborted_errors++;
}
- ip6_tnl_dst_store(t, dst);
+ if (ndst)
+ ip6_tnl_dst_store(t, ndst);
return 0;
tx_err_link_failure:
stats->tx_carrier_errors++;
dst_link_failure(skb);
tx_err_dst_release:
- dst_release(dst);
+ dst_release(ndst);
return err;
}
^ permalink raw reply related
* [PATCH] ipv6: avoid a dst_entry refcount change in ipv6_destopt_rcv()
From: Eric Dumazet @ 2011-07-28 14:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
ipv6_destopt_rcv() runs with rcu_read_lock(), so there is no need to
take a temporay reference on dst_entry, even if skb is freed by
ip6_parse_tlv()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv6/exthdrs.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 79a485e..1318de4 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -273,12 +273,12 @@ static int ipv6_destopt_rcv(struct sk_buff *skb)
#if defined(CONFIG_IPV6_MIP6) || defined(CONFIG_IPV6_MIP6_MODULE)
__u16 dstbuf;
#endif
- struct dst_entry *dst;
+ struct dst_entry *dst = skb_dst(skb);
if (!pskb_may_pull(skb, skb_transport_offset(skb) + 8) ||
!pskb_may_pull(skb, (skb_transport_offset(skb) +
((skb_transport_header(skb)[1] + 1) << 3)))) {
- IP6_INC_STATS_BH(dev_net(skb_dst(skb)->dev), ip6_dst_idev(skb_dst(skb)),
+ IP6_INC_STATS_BH(dev_net(dst->dev), ip6_dst_idev(dst),
IPSTATS_MIB_INHDRERRORS);
kfree_skb(skb);
return -1;
@@ -289,9 +289,7 @@ static int ipv6_destopt_rcv(struct sk_buff *skb)
dstbuf = opt->dst1;
#endif
- dst = dst_clone(skb_dst(skb));
if (ip6_parse_tlv(tlvprocdestopt_lst, skb)) {
- dst_release(dst);
skb->transport_header += (skb_transport_header(skb)[1] + 1) << 3;
opt = IP6CB(skb);
#if defined(CONFIG_IPV6_MIP6) || defined(CONFIG_IPV6_MIP6_MODULE)
@@ -304,7 +302,6 @@ static int ipv6_destopt_rcv(struct sk_buff *skb)
IP6_INC_STATS_BH(dev_net(dst->dev),
ip6_dst_idev(dst), IPSTATS_MIB_INHDRERRORS);
- dst_release(dst);
return -1;
}
^ permalink raw reply related
* [PATCH] ipv6: use RCU in inet6_csk_xmit()
From: Eric Dumazet @ 2011-07-28 13:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Use RCU to avoid changing dst_entry refcount in fast path.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv6/inet6_connection_sock.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index 8a58e8c..2916200 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -211,6 +211,7 @@ int inet6_csk_xmit(struct sk_buff *skb, struct flowi *fl_unused)
struct flowi6 fl6;
struct dst_entry *dst;
struct in6_addr *final_p, final;
+ int res;
memset(&fl6, 0, sizeof(fl6));
fl6.flowi6_proto = sk->sk_protocol;
@@ -241,12 +242,14 @@ int inet6_csk_xmit(struct sk_buff *skb, struct flowi *fl_unused)
__inet6_csk_dst_store(sk, dst, NULL, NULL);
}
- skb_dst_set(skb, dst_clone(dst));
+ rcu_read_lock();
+ skb_dst_set_noref(skb, dst);
/* Restore final destination back after routing done */
ipv6_addr_copy(&fl6.daddr, &np->daddr);
- return ip6_xmit(sk, skb, &fl6, np->opt);
+ res = ip6_xmit(sk, skb, &fl6, np->opt);
+ rcu_read_unlock();
+ return res;
}
-
EXPORT_SYMBOL_GPL(inet6_csk_xmit);
^ permalink raw reply related
* Re: r8169 driver crashes in 2.6.32.43
From: Kasper Dupont @ 2011-07-28 12:54 UTC (permalink / raw)
To: Francois Romieu; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110728124548.GA24762@colin.search.kasperd.net>
On 28/07/11 14.45, Kasper Dupont wrote:
> On 28/07/11 14.23, Francois Romieu wrote:
> > You can replace them with plain printk(KERN_{INFO/ERR} "S: ...).
>
> Then it compiles, will let you know shortly how it works out.
The last 24 lines before network stopped working:
S: 00000044
FEmp
S: 000000c0
FEmp
S: 00000044
FEmp
S: 00000040
FEmp
S: 00000044
FEmp
S: 00000041
FEmp
S: 000000c0
FEmp
S: 00000040
FEmp
S: 000000c0
FEmp
S: 000000c0
FEmp
S: 00000040
S: 000000c4
S: 00000044
S: 00000040
--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);
^ permalink raw reply
* Re: 802.1ad on linux
From: David Lamparter @ 2011-07-28 12:48 UTC (permalink / raw)
To: Satendra...; +Cc: Jens Osterkamp, netdev
In-Reply-To: <201107281321.46294.jens@linux.vnet.ibm.com>
On Thu, Jul 28, 2011 at 01:21:46PM +0200, Jens Osterkamp wrote:
> On Thursday 28 July 2011, Satendra... wrote:
> > Hi,
> >
> > Does linux kernel has support for 802.1ad ? if yes could u plz mention
> > the version?
>
> No, but David Lamparter has just recently posted patches which implement this.
>
> http://marc.info/?l=linux-netdev&m=131093613717022&w=2
>
> They work fine for me on top of net-next. I had to add EXPORT_SYMBOL for
> vlan_untag and vlan_do_receive to be able to build as a module.
> You will need his patch for iproute2 as well to be able to create 802.1ad
> VLAN devices.
I will be rebasing them onto current net-next HEAD this weekend. With
the VLAN cleanup in, some bits changed; I'll also do some reordering to
fix those symbols.
-David
^ permalink raw reply
* [PATCH 3/6] drivers/net/niu.c: adjust array index
From: Julia Lawall @ 2011-07-28 12:46 UTC (permalink / raw)
To: Grant Likely
Cc: kernel-janitors, David S. Miller, Ben Hutchings,
Stephen Hemminger, Eric Dumazet, Michał Mirosław,
netdev, linux-kernel, devicetree-discuss
In-Reply-To: <1311857165-14780-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Convert array index from the loop bound to the loop index.
A simplified version of the semantic patch that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e1,e2,ar;
@@
for(e1 = 0; e1 < e2; e1++) { <...
ar[
- e2
+ e1
]
...> }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
Not tested.
drivers/net/niu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -u -p a/drivers/net/niu.c b/drivers/net/niu.c
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -9201,7 +9201,7 @@ static int __devinit niu_ldg_init(struct
first_chan = 0;
for (i = 0; i < port; i++)
- first_chan += parent->rxchan_per_port[port];
+ first_chan += parent->rxchan_per_port[i];
num_chan = parent->rxchan_per_port[port];
for (i = first_chan; i < (first_chan + num_chan); i++) {
@@ -9217,7 +9217,7 @@ static int __devinit niu_ldg_init(struct
first_chan = 0;
for (i = 0; i < port; i++)
- first_chan += parent->txchan_per_port[port];
+ first_chan += parent->txchan_per_port[i];
num_chan = parent->txchan_per_port[port];
for (i = first_chan; i < (first_chan + num_chan); i++) {
err = niu_ldg_assign_ldn(np, parent,
^ permalink raw reply
* [PATCH 1/6] net: adjust array index
From: Julia Lawall @ 2011-07-28 12:46 UTC (permalink / raw)
To: David S. Miller
Cc: kernel-janitors, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev,
linux-kernel
In-Reply-To: <1311857165-14780-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Convert array index from the loop bound to the loop index.
A simplified version of the semantic patch that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e1,e2,ar;
@@
for(e1 = 0; e1 < e2; e1++) { <...
ar[
- e2
+ e1
]
...> }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
Not tested.
net/ipv4/igmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -u -p a/net/ipv4/igmp.c b/net/ipv4/igmp.c
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1718,7 +1718,7 @@ static int ip_mc_add_src(struct in_devic
pmc->sfcount[sfmode]--;
for (j=0; j<i; j++)
- (void) ip_mc_del1_src(pmc, sfmode, &psfsrc[i]);
+ (void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
} else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
#ifdef CONFIG_IP_MULTICAST
struct ip_sf_list *psf;
^ 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