* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: David Miller @ 2012-06-23 0:26 UTC (permalink / raw)
To: mchan; +Cc: netdev, nsujir, mcarlson
In-Reply-To: <1340237192-30052-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 20 Jun 2012 17:06:32 -0700
> Some tg3 devices have management firmware that can export data such as
> temperature and other real time diagnostics data. Export this data to
> sysfs so that userspace can access this information.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
I do not agree that sysfs is the appropriate place to export binary
data.
^ permalink raw reply
* Re: [PATCH -v1 0/3] usbnet: usbnet: PM related fixes
From: David Miller @ 2012-06-23 0:34 UTC (permalink / raw)
To: ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, oneukum-l3A5Bk7waGM,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1340176553-32225-1-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
From: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Date: Wed, 20 Jun 2012 15:15:50 +0800
> The 3 patches fix some PM related problems.
>
> v1:
> - one line fix in 3/3: GFP_ATOMIC -> flags in rx_alloc_submit
All applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Stephen Hemminger @ 2012-06-23 0:59 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev, nsujir, mcarlson
In-Reply-To: <1340237192-30052-3-git-send-email-mchan@broadcom.com>
On Wed, 20 Jun 2012 17:06:32 -0700
"Michael Chan" <mchan@broadcom.com> wrote:
> Some tg3 devices have management firmware that can export data such as
> temperature and other real time diagnostics data. Export this data to
> sysfs so that userspace can access this information.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Linux has existing sensor api's that can be used by existing
services like SNMP. Wouldn't you like the it to just work with
existing code API's?
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Michael Chan @ 2012-06-23 1:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nsujir, mcarlson
In-Reply-To: <20120622.172651.932738000786251092.davem@davemloft.net>
On Fri, 2012-06-22 at 17:26 -0700, David Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Wed, 20 Jun 2012 17:06:32 -0700
>
> > Some tg3 devices have management firmware that can export data such as
> > temperature and other real time diagnostics data. Export this data to
> > sysfs so that userspace can access this information.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> I do not agree that sysfs is the appropriate place to export binary
> data.
>
What's your suggestion? ethtool?
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Michael Chan @ 2012-06-23 1:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev, nsujir, mcarlson
In-Reply-To: <20120622175934.2cc253b7@nehalam.linuxnetplumber.net>
On Fri, 2012-06-22 at 17:59 -0700, Stephen Hemminger wrote:
> On Wed, 20 Jun 2012 17:06:32 -0700
> "Michael Chan" <mchan@broadcom.com> wrote:
>
> > Some tg3 devices have management firmware that can export data such as
> > temperature and other real time diagnostics data. Export this data to
> > sysfs so that userspace can access this information.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> Linux has existing sensor api's that can be used by existing
> services like SNMP. Wouldn't you like the it to just work with
> existing code API's?
>
Is it the lm-sensors API? The data that we are exporting is for the
Lights out management for the system OEMs. I need to check with the
OEM.
^ permalink raw reply
* Re: pull request: wireless 2012-06-22
From: Sujith Manoharan @ 2012-06-23 2:11 UTC (permalink / raw)
To: David Miller; +Cc: c_manoha, linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20120622.165611.2220193371527786713.davem@davemloft.net>
David Miller wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> Date: Sat, 23 Jun 2012 05:05:10 +0530
>
> > Sujith Manoharan wrote:
> >> John W. Linville wrote:
> >> > Mohammed Shafi Shajakhan (1):
> >> > ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
> >>
> >> Um, this commit doesn't really fix anything - the timeout is also
> >> arbitrary. Can you remove this from the 3.5 queue ? Thanks.
> >
> > A review of the patch later, I think it's good. At least there's a
> > WARN_ON_ONCE() to indicate the situation in which the measurement fails.
> > It might come in handy as a debugging aid.
>
> Thanks for wasting our time.
>
> Make these determinations when changes to into John's tree, not
> later when he asks me to pull them into mine.
The patch was under review:
http://marc.info/?l=linux-wireless&m=134001371002288&w=2
Sujith
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Ming Lei @ 2012-06-23 3:32 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Marius Bjørnstad Kotsbak
In-Reply-To: <1340356279-3124-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
On Fri, Jun 22, 2012 at 5:11 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>
> Reported-by: Marius Bjørnstad Kotsbak <marius.kotsbak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> ---
> drivers/net/usb/qmi_wwan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 3767a12..b01960f 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -197,6 +197,10 @@ err:
> static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
> {
> struct usbnet *dev = usb_get_intfdata(intf);
> +
> + /* can be called while disconnecting */
> + if (!dev)
> + return 0;
> return qmi_wwan_manage_power(dev, on);
> }
Considered there isn't any protection between usbnet_disconnet and
wdm_open/wdm_close, you patch still doesn't work on the race, see
below:
+ if (!dev)
+ return 0;
-> usbnet_disconnect() triggered and completed, so
return qmi_wwan_manage_power(dev, on);
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: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Ming Lei @ 2012-06-23 3:39 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb, Marius Bjørnstad Kotsbak
In-Reply-To: <CACVXFVNmquD6nhcJkumZsnXH7T+Ga3YNt9EAQ=-5HUkYwEdp7w@mail.gmail.com>
Sorry for mistaken triggered sending, :-(
On Sat, Jun 23, 2012 at 11:32 AM, Ming Lei <tom.leiming@gmail.com> wrote:
> On Fri, Jun 22, 2012 at 5:11 PM, Bjørn Mork <bjorn@mork.no> wrote:
>
>>
>> Reported-by: Marius Bjørnstad Kotsbak <marius.kotsbak@gmail.com>
>> Cc: <stable@vger.kernel.org> # v3.4
>> Signed-off-by: Bjørn Mork <bjorn@mork.no>
>> ---
>> drivers/net/usb/qmi_wwan.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
>> index 3767a12..b01960f 100644
>> --- a/drivers/net/usb/qmi_wwan.c
>> +++ b/drivers/net/usb/qmi_wwan.c
>> @@ -197,6 +197,10 @@ err:
>> static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
>> {
>> struct usbnet *dev = usb_get_intfdata(intf);
>> +
>> + /* can be called while disconnecting */
>> + if (!dev)
>> + return 0;
>> return qmi_wwan_manage_power(dev, on);
>> }
>
Considered there isn't any protection between usbnet_disconnet and
wdm_open/wdm_close, you patch still doesn't work on the race, see
below:
+ if (!dev)
+ return 0;
-> usbnet_disconnect() is triggered and completed here, so
dev may point to a freed usbnet instance.
return qmi_wwan_manage_power(dev, on);
One fix I can think of is to export wdm_mutex or its lock/unlock
functions, and introduce the function of qmi_wwan_disconnect, which
will call usbnet_disconnect with holding wdm_mutex.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: pull request: wireless 2012-06-22
From: John W. Linville @ 2012-06-23 4:11 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20453.9687.225096.194368@gargle.gargle.HOWL>
On Sat, Jun 23, 2012 at 07:41:35AM +0530, Sujith Manoharan wrote:
> David Miller wrote:
> > From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> > Date: Sat, 23 Jun 2012 05:05:10 +0530
> >
> > > Sujith Manoharan wrote:
> > >> John W. Linville wrote:
> > >> > Mohammed Shafi Shajakhan (1):
> > >> > ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
> > >>
> > >> Um, this commit doesn't really fix anything - the timeout is also
> > >> arbitrary. Can you remove this from the 3.5 queue ? Thanks.
> > >
> > > A review of the patch later, I think it's good. At least there's a
> > > WARN_ON_ONCE() to indicate the situation in which the measurement fails.
> > > It might come in handy as a debugging aid.
> >
> > Thanks for wasting our time.
> >
> > Make these determinations when changes to into John's tree, not
> > later when he asks me to pull them into mine.
>
> The patch was under review:
> http://marc.info/?l=linux-wireless&m=134001371002288&w=2
Quibbling over the exact number of iterations for a timeout didn't
seem is important as avoiding an endless loop...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: tcp: dont cache output dst for syncookies
From: David Miller @ 2012-06-23 4:47 UTC (permalink / raw)
To: brouer; +Cc: eric.dumazet, netdev, hans.schillstrom
In-Reply-To: <1340365654.4003.46.camel@localhost>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Fri, 22 Jun 2012 13:47:34 +0200
> On Wed, 2012-06-20 at 17:02 +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Don't cache output dst for syncookies, as this adds pressure on IP route
>> cache and rcu subsystem for no gain.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> Looks good to me.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] r8169: RxConfig hack for the 8168evl.
From: David Miller @ 2012-06-23 4:49 UTC (permalink / raw)
To: romieu; +Cc: hayeswang, netdev, thomas.pi
In-Reply-To: <20120620220918.GA2785@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 21 Jun 2012 00:09:18 +0200
> The 8168evl (RTL_GIGA_MAC_VER_34) based Gigabyte GA-990FXA motherboards
> are very prone to NETDEV watchdog problems without this change. See
> https://bugzilla.kernel.org/show_bug.cgi?id=42899 for instance.
>
> I don't know why it *works*. It's depressingly effective though.
>
> For the record:
> - the problem may go along IOMMU (AMD-Vi) errors but it really looks
> like a red herring.
> - the patch sets the RX_MULTI_EN bit. If the 8168c doc is any guide,
> the chipset now fetches several Rx descriptors at a time.
> - long ago the driver ignored the RX_MULTI_EN bit.
> e542a2269f232d61270ceddd42b73a4348dee2bb changed the RxConfig
> settings. Whatever the problem it's now labeled a regression.
> - Realtek's own driver can identify two different 8168evl devices
> (CFG_METHOD_16 and CFG_METHOD_17) where the r8169 driver only
> sees one. It sucks.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Applied, thanks Francois.
^ permalink raw reply
* Re: [PATCH] net: sh_eth: fix the rxdesc pointer when rx descriptor empty happens
From: David Miller @ 2012-06-23 4:51 UTC (permalink / raw)
To: g.liakhovetski; +Cc: yoshihiro.shimoda.uh, netdev, linux-sh
In-Reply-To: <Pine.LNX.4.64.1206221610350.17552@axis700.grange>
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Date: Fri, 22 Jun 2012 16:16:38 +0200 (CEST)
> Hi Shimoda-san
>
> On Thu, 21 Jun 2012, Shimoda, Yoshihiro wrote:
>
>> Hello Guennadi-san,
>>
>> 2012/06/20 22:10, Guennadi Liakhovetski wrote:
>> > Hello Shimoda-san
>> >
>> > On Tue, 29 May 2012, Shimoda, Yoshihiro wrote:
>> >
>> >> When Receive Descriptor Empty happens, rxdesc pointer of the driver
>> >> and actual next descriptor of the controller may be mismatch.
>> >> This patch fixes it.
>> >
>> > Unfortunately, this patch breaks networking on ecovec (sh7724). Booting
>> > with dhcp and NFS-root progresses very slowly with lots of "nfs: server
>> > not responding / Ok" messages and never completes. Reverting it in current
>> > Linus' tree fixes the problem.
>>
>> Thank you very much for the report.
>> The SH7724 doesn't set the RMCR register. So, the EDRRR will be clear after
>> the controller receives a freme every time.
>> So, the "fix the rxdesc pointer" had to check a condition.
>>
>> I wrote a patch for the issue as the following.
>> If possible, would you try the patch?
>
> Yes, it does seem to fix the problem.
>
> Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Applied, thanks.
^ permalink raw reply
* Re: Bug in net/ipv6/ip6_fib.c:fib6_dump_table()
From: Eric Dumazet @ 2012-06-23 5:37 UTC (permalink / raw)
To: David Miller
Cc: johunt, kaber, dbavatar, netdev, yoshfuji, jmorris, pekkas,
kuznet, linux-kernel, Ben Greear
In-Reply-To: <20120622.170237.1504103690155447356.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
> 1) Patrick McHardy has been inactive for a while, so do not expect
> any insight from him.
>
> 2) Ben Greear isn't even on the CC: list of this discussion yet he
> appears to be the person who reproduced the crash way back then
> and is listed in the Tested-by tag of the commit.
>
> As a result we aren't likely to get any insight from the one person
> who actually could hit the crash.
>
> I'm inclined to just revert simply because we have people active who
> can reproduce regressions introduced by this change and nobody can
> understand why the change is even necessary.
Well, except that :
I spent 3 hours trying to understand Alexey code and failed.
All other /proc/net files don't have a such sophisticated walkers aware
mechanism (easily DOSable by the way, if some guy opens 10.000 handles
and suspend in the middle the dumps).
cat /proc/net/tcp for example can display same socket twice or miss a
socket, because a 'suspend/restart' remembers offsets/counts in a hash
chain, not a pointer to 'next socket'
The fix I submitted is a real one, based on my analysis and tests.
Patrick patch was restarting the dump at the root of the tree, and
setting skip = count was doing nothing at all, since all entries were
dumped again.
This is more a stable candidate fix.
If someones smarter than me can find the real bug, then we certainly can
revert Patrick patch ?
[PATCH] ipv6: fib: fix fib dump restart
Commit 2bec5a369ee79576a3 (ipv6: fib: fix crash when changing large fib
while dumping it) introduced ability to restart the dump at tree root,
but failed to skip correctly a count of already dumped entries. Code
didn't match Patrick intent.
We must skip exactly the number of already dumped entries.
Note that like other /proc/net files or netlink producers, we could
still dump some duplicates entries.
Reported-by: Debabrata Banerjee <dbavatar@gmail.com>
Reported-by: Josh Hunt <johunt@akamai.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Ben Greear <greearb@candelatech.com>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
---
net/ipv6/ip6_fib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 74c21b9..6083276 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1349,8 +1349,8 @@ static int fib6_walk_continue(struct fib6_walker_t *w)
if (w->leaf && fn->fn_flags & RTN_RTINFO) {
int err;
- if (w->count < w->skip) {
- w->count++;
+ if (w->skip) {
+ w->skip--;
continue;
}
^ permalink raw reply related
* Re: [PATCH] ipv4: Add sysctl knob to control early socket demux
From: Eric Dumazet @ 2012-06-23 5:45 UTC (permalink / raw)
To: David Miller; +Cc: alexander.h.duyck, netdev, jeffrey.t.kirsher, edumazet
In-Reply-To: <20120622.171509.1112294083000632011.davem@davemloft.net>
On Fri, 2012-06-22 at 17:15 -0700, David Miller wrote:
> I applied this for now, making a minor change to move the local
> variables down into the new basic block you created.
>
Hmm, sorry to come late, but you left NET_IPV4_EARLY_DEMUX=126 sysctl,
while this is deprecated way...
> There has got to be a way to make this really cheap. At the very
> least we can have the GRO code store away the ports and therefore
> allow us to just do a direct call to try and demux the socket. Thus,
> we'd avoid all of pskb_may_pull() et al. packet validations, and
> packet header pointer calculations.
>
> Furthermore, we can reduce to overhead by making a special inet
> established hash demux that doesn't check for time-wait sockets,
> reducing the number of probes to 1 from 2.
The timewait hash chain is on the same cache line than established one.
And on a router, both chains are empty with a 99.999 % probability.
^ permalink raw reply
* Re: [PATCH] ipv4: Add sysctl knob to control early socket demux
From: David Miller @ 2012-06-23 6:00 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.h.duyck, netdev, jeffrey.t.kirsher, edumazet
In-Reply-To: <1340430326.4604.11946.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 23 Jun 2012 07:45:26 +0200
> On Fri, 2012-06-22 at 17:15 -0700, David Miller wrote:
>
>> Furthermore, we can reduce to overhead by making a special inet
>> established hash demux that doesn't check for time-wait sockets,
>> reducing the number of probes to 1 from 2.
>
> The timewait hash chain is on the same cache line than established one.
> And on a router, both chains are empty with a 99.999 % probability.
I understand this.
Probably a lot of the overhead has to do with the function calls
and, as I mentioned, the transport layer probing and validation.
^ permalink raw reply
* Re: [PATCH] ipv4: Add sysctl knob to control early socket demux
From: David Miller @ 2012-06-23 6:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.h.duyck, netdev, jeffrey.t.kirsher, edumazet
In-Reply-To: <1340430326.4604.11946.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 23 Jun 2012 07:45:26 +0200
> On Fri, 2012-06-22 at 17:15 -0700, David Miller wrote:
>
>> I applied this for now, making a minor change to move the local
>> variables down into the new basic block you created.
>>
>
> Hmm, sorry to come late, but you left NET_IPV4_EARLY_DEMUX=126 sysctl,
> while this is deprecated way...
Thanks for catching this:
--------------------
[PATCH] ipv4: Don't add deprecated new binary sysctl value.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/sysctl.h | 1 -
kernel/sysctl_binary.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 20825e5..c34b4c8 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -425,7 +425,6 @@ enum
NET_TCP_ALLOWED_CONG_CONTROL=123,
NET_TCP_MAX_SSTHRESH=124,
NET_TCP_FRTO_RESPONSE=125,
- NET_IPV4_EARLY_DEMUX=126,
};
enum {
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index 6a3cf82..a650694 100644
--- a/kernel/sysctl_binary.c
+++ b/kernel/sysctl_binary.c
@@ -415,8 +415,6 @@ static const struct bin_table bin_net_ipv4_table[] = {
{ CTL_INT, NET_IPV4_IPFRAG_SECRET_INTERVAL, "ipfrag_secret_interval" },
/* NET_IPV4_IPFRAG_MAX_DIST "ipfrag_max_dist" no longer used */
- { CTL_INT, NET_IPV4_EARLY_DEMUX, "ip_early_demux" },
-
{ CTL_INT, 2088 /* NET_IPQ_QMAX */, "ip_queue_maxlen" },
/* NET_TCP_DEFAULT_WIN_SCALE unused */
--
1.7.10.2
^ permalink raw reply related
* Re: pull request: wireless 2012-06-22
From: Sujith Manoharan @ 2012-06-23 6:10 UTC (permalink / raw)
To: John W. Linville
Cc: Sujith Manoharan, David Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20120623041103.GA29801@tuxdriver.com>
John W. Linville wrote:
> > The patch was under review:
> > http://marc.info/?l=linux-wireless&m=134001371002288&w=2
>
> Quibbling over the exact number of iterations for a timeout didn't
> seem is important as avoiding an endless loop...
Yes, which is why I okayed the patch. :)
Sujith
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid tx starvation by SYNACK packets
From: Vijay Subramanian @ 2012-06-23 7:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dave Taht, Hans Schillstrom, netdev, Neal Cardwell, Tom Herbert,
Jesper Dangaard Brouer
In-Reply-To: <1338615992.2760.1665.camel@edumazet-glaptop>
On 1 June 2012 22:46, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2012-06-01 at 18:28 -0700, Dave Taht wrote:
>> On Thu, May 31, 2012 at 2:56 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > pfifo_fast being the default Qdisc, its pretty easy to fill it with
>> > SYNACK (small) packets while host is under SYNFLOOD attack.
>> >
>> > Packets of established TCP sessions are dropped and host appears almost
>> > dead.
>> >
>> > Avoid this problem assigning TC_PRIO_FILLER priority to SYNACK
>> > generated in SYNCOOKIE mode, so that these packets are enqueued into
>> > pfifo_fast band 2.
>> >
>> > Other packets, queued to band 0 or 1 are dequeued before any SYNACK
>> > packets waiting in band 2.
>>
This patch ([PATCH net-next] tcp: avoid tx starvation by SYNACK
packets) is neither in net/net-next trees nor on patchwork. Maybe it
was missed since it was sent during the merge window. Is this not
needed anymore or is it being tested currently?
Thanks,
Vijay
^ permalink raw reply
* Linux 3.4.2 doesn't detect Intel 82579V on Supermicro X9SCL-F
From: Denys Fedoryshchenko @ 2012-06-23 8:05 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Peter P Waskiewicz Jr, Alex Duyck,
John Ronciak, e1000-devel, netdev, linux-kernel
I have motherboard X9SCL-F with two onboard network cards, one of them
are not detected.
First i notice that on Ubuntu, now i tried also vanilla 3.4.2, on same
motherboard model, but different server.
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 05)
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
Particular adapter that are not working:
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 05)
Subsystem: Intel Corporation Device 0000
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 20
Region 0: Memory at f7a00000 (32-bit, non-prefetchable)
[size=128K]
Region 1: Memory at f7a23000 (32-bit, non-prefetchable)
[size=4K]
Region 2: I/O ports at f020 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 00000000fee00378 Data: 0000
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel modules: e1000e
corresponding log entries:
[ 3.189176] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
[ 3.197950] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[ 3.206540] md: raid0 personality registered for level 0
[ 3.206693] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) ->
IRQ 20
[ 3.206723] e1000e 0000:00:19.0: setting latency timer to 64
[ 3.207412] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[ 3.224410] input: Winbond Electronics Corp Hermon USB hidmouse Device
as
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input2
[ 3.241969] md: raid1 personality registered for level 1
[ 3.242538] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID
v1.00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on
usb-0000:00:1a.0-1.2/input0
[ 3.243563] input: Winbond Electronics Corp Hermon USB hidmouse Device
as
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/input/input3
[ 3.243978] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID
v1.00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on
usb-0000:00:1a.0-1.2/input1
[ 3.243988] usbcore: registered new interface driver usbhid
[ 3.243989] usbhid: USB HID core driver
[ 3.271808] e1000e 0000:00:19.0: PCI INT A disabled
[ 3.271813] e1000e: probe of 0000:00:19.0 failed with error -3
[ 3.271821] e1000e 0000:02:00.0: Disabling ASPM L0s
[ 3.272000] e1000e 0000:02:00.0: PCI INT A -> GSI 16 (level, low) ->
IRQ 16
[ 3.272082] e1000e 0000:02:00.0: setting latency timer to 64
[ 3.381646] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X
[ 3.381652] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X
[ 3.381658] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X
[ 3.382503] async_tx: api initialized (async)
root@central:~# ethtool -i eth0
driver: e1000e
version: 1.5.1-k
firmware-version: 2.1-2
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
root@central:~# ethtool -i eth1
Cannot get driver information: No such device
---
AlsaDevices:
total 0
crw-rw---T 1 root audio 116, 1 Jun 17 13:22 seq
crw-rw---T 1 root audio 116, 33 Jun 17 13:22 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 12.04
HibernationDevice: RESUME=UUID=6bdcd41e-069d-48e1-831d-5789badf4aab
InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Release
amd64 (20120424.1)
Lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching
Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching
Hub
Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd
MachineType: Supermicro X9SCL/X9SCM
Package: linux (not installed)
PciMultimedia:
ProcEnviron:
TERM=xterm
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-25-generic
root=UUID=49e8b23b-7eb0-41ac-8343-d6586659c879 ro
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18
RelatedPackageVersions:
linux-restricted-modules-3.2.0-25-generic N/A
linux-backports-modules-3.2.0-25-generic N/A
linux-firmware 1.79
RfKill: Error: [Errno 2] No such file or directory
Tags: precise
Uname: Linux 3.2.0-25-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:
dmi.bios.date: 05/08/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2.00
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X9SCL/X9SCM
dmi.board.vendor: Supermicro
dmi.board.version: 0123456789
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Supermicro
dmi.chassis.version: 0123456789
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr2.00:bd05/08/2012:svnSupermicro:pnX9SCL/X9SCM:pvr0123456789:rvnSupermicro:rnX9SCL/X9SCM:rvr0123456789:cvnSupermicro:ct3:cvr0123456789:
dmi.product.name: X9SCL/X9SCM
dmi.product.version: 0123456789
dmi.sys.vendor: Supermicro
Detailed hardware information and ticket on ubuntu
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1014490
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Eric Dumazet @ 2012-06-23 8:42 UTC (permalink / raw)
To: Vijay Subramanian
Cc: Dave Taht, Hans Schillstrom, netdev, Neal Cardwell, Tom Herbert,
Jesper Dangaard Brouer
In-Reply-To: <CAGK4HS8Hae_4sNQeGXGc4ocK1-2DVtCUdBAPj7+DY_iF6-2zOA@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
On Sat, 2012-06-23 at 00:34 -0700, Vijay Subramanian wrote:
> This patch ([PATCH net-next] tcp: avoid tx starvation by SYNACK
> packets) is neither in net/net-next trees nor on patchwork. Maybe it
> was missed since it was sent during the merge window. Is this not
> needed anymore or is it being tested currently?
You're right, thanks for the reminder !
[PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
pfifo_fast being the default Qdisc, its pretty easy to fill it with
SYNACK (small) packets while host is under synflood attack.
Packets of established TCP sessions are dropped at Qdisc layer and
host appears almost dead.
Avoid this problem assigning TC_PRIO_FILLER priority to SYNACK
generated in SYNCOOKIE mode, so that these packets are enqueued into
pfifo_fast lowest priority (band 2).
Other packets, queued to band 0 or 1 are dequeued before any SYNACK
packets waiting in band 2.
If not under synflood, SYNACK priority is as requested by listener
sk_priority policy.
Reported-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Vijay Subramanian <subramanian.vijay@gmail.com>
---
net/dccp/ipv4.c | 2 ++
net/ipv4/ip_output.c | 2 +-
net/ipv4/tcp_ipv4.c | 7 ++++++-
net/ipv6/inet6_connection_sock.c | 1 +
net/ipv6/ip6_output.c | 2 +-
net/ipv6/tcp_ipv6.c | 11 ++++++++---
6 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 3eb76b5..045176f 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -515,6 +515,7 @@ static int dccp_v4_send_response(struct sock *sk, struct request_sock *req,
dh->dccph_checksum = dccp_v4_csum_finish(skb, ireq->loc_addr,
ireq->rmt_addr);
+ skb->priority = sk->sk_priority;
err = ip_build_and_send_pkt(skb, sk, ireq->loc_addr,
ireq->rmt_addr,
ireq->opt);
@@ -556,6 +557,7 @@ static void dccp_v4_ctl_send_reset(struct sock *sk, struct sk_buff *rxskb)
skb_dst_set(skb, dst_clone(dst));
bh_lock_sock(ctl_sk);
+ skb->priority = ctl_sk->sk_priority;
err = ip_build_and_send_pkt(skb, ctl_sk,
rxiph->daddr, rxiph->saddr, NULL);
bh_unlock_sock(ctl_sk);
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 0f3185a..71c6c20 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -155,7 +155,7 @@ int ip_build_and_send_pkt(struct sk_buff *skb, struct sock *sk,
ip_options_build(skb, &opt->opt, daddr, rt, 0);
}
- skb->priority = sk->sk_priority;
+ /* skb->priority is set by the caller */
skb->mark = sk->sk_mark;
/* Send it out. */
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index b52934f..5ef4131 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -81,7 +81,7 @@
#include <linux/stddef.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
-
+#include <linux/pkt_sched.h>
#include <linux/crypto.h>
#include <linux/scatterlist.h>
@@ -821,6 +821,7 @@ static void tcp_v4_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
* Send a SYN-ACK after having received a SYN.
* This still operates on a request_sock only, not on a big
* socket.
+ * nocache is set for SYN-ACK sent in SYNCOOKIE mode
*/
static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
struct request_sock *req,
@@ -843,6 +844,10 @@ static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
__tcp_v4_send_check(skb, ireq->loc_addr, ireq->rmt_addr);
skb_set_queue_mapping(skb, queue_mapping);
+
+ /* SYNACK sent in SYNCOOKIE mode have low priority */
+ skb->priority = nocache ? TC_PRIO_FILLER : sk->sk_priority;
+
err = ip_build_and_send_pkt(skb, sk, ireq->loc_addr,
ireq->rmt_addr,
ireq->opt);
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index e6cee52..5812a74 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -248,6 +248,7 @@ int inet6_csk_xmit(struct sk_buff *skb, struct flowi *fl_unused)
/* Restore final destination back after routing done */
fl6.daddr = np->daddr;
+ skb->priority = sk->sk_priority;
res = ip6_xmit(sk, skb, &fl6, np->opt, np->tclass);
rcu_read_unlock();
return res;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index a233a7c..a93378a 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -228,7 +228,7 @@ int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6,
hdr->saddr = fl6->saddr;
hdr->daddr = *first_hop;
- skb->priority = sk->sk_priority;
+ /* skb->priority is set by the caller */
skb->mark = sk->sk_mark;
mtu = dst_mtu(dst);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 26a8862..f664452 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -43,6 +43,7 @@
#include <linux/ipv6.h>
#include <linux/icmpv6.h>
#include <linux/random.h>
+#include <linux/pkt_sched.h>
#include <net/tcp.h>
#include <net/ndisc.h>
@@ -479,7 +480,8 @@ out:
static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req,
struct request_values *rvp,
- u16 queue_mapping)
+ u16 queue_mapping,
+ bool syncookie)
{
struct inet6_request_sock *treq = inet6_rsk(req);
struct ipv6_pinfo *np = inet6_sk(sk);
@@ -515,6 +517,7 @@ static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req,
if (skb) {
__tcp_v6_send_check(skb, &treq->loc_addr, &treq->rmt_addr);
+ skb->priority = syncookie ? TC_PRIO_FILLER : sk->sk_priority;
fl6.daddr = treq->rmt_addr;
skb_set_queue_mapping(skb, queue_mapping);
err = ip6_xmit(sk, skb, &fl6, opt, np->tclass);
@@ -531,7 +534,7 @@ static int tcp_v6_rtx_synack(struct sock *sk, struct request_sock *req,
struct request_values *rvp)
{
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_RETRANSSEGS);
- return tcp_v6_send_synack(sk, req, rvp, 0);
+ return tcp_v6_send_synack(sk, req, rvp, 0, false);
}
static void tcp_v6_reqsk_destructor(struct request_sock *req)
@@ -909,6 +912,7 @@ static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
dst = ip6_dst_lookup_flow(ctl_sk, &fl6, NULL, false);
if (!IS_ERR(dst)) {
skb_dst_set(buff, dst);
+ skb->priority = ctl_sk->sk_priority;
ip6_xmit(ctl_sk, buff, &fl6, NULL, tclass);
TCP_INC_STATS_BH(net, TCP_MIB_OUTSEGS);
if (rst)
@@ -1217,7 +1221,8 @@ have_isn:
if (tcp_v6_send_synack(sk, req,
(struct request_values *)&tmp_ext,
- skb_get_queue_mapping(skb)) ||
+ skb_get_queue_mapping(skb),
+ want_cookie) ||
want_cookie)
goto drop_and_free;
^ permalink raw reply related
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Bjørn Mork @ 2012-06-23 8:45 UTC (permalink / raw)
To: Ming Lei
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Marius Bjørnstad Kotsbak
In-Reply-To: <CACVXFVMJSrLjOyKUnZWr3CY2HJT6Wfm6AugZOhSCRUubV0hNMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Sat, Jun 23, 2012 at 11:32 AM, Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Jun 22, 2012 at 5:11 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>>
>>>
>>> Reported-by: Marius Bjørnstad Kotsbak <marius.kotsbak-Re5JQEeQqe8@public.gmane.orgm>
>>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4
>>> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>>> ---
>>> drivers/net/usb/qmi_wwan.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
>>> index 3767a12..b01960f 100644
>>> --- a/drivers/net/usb/qmi_wwan.c
>>> +++ b/drivers/net/usb/qmi_wwan.c
>>> @@ -197,6 +197,10 @@ err:
>>> static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
>>> {
>>> struct usbnet *dev = usb_get_intfdata(intf);
>>> +
>>> + /* can be called while disconnecting */
>>> + if (!dev)
>>> + return 0;
>>> return qmi_wwan_manage_power(dev, on);
>>> }
>>
>
> Considered there isn't any protection between usbnet_disconnet and
> wdm_open/wdm_close, you patch still doesn't work on the race, see
> below:
>
> + if (!dev)
> + return 0;
>
> -> usbnet_disconnect() is triggered and completed here, so
> dev may point to a freed usbnet instance.
> return qmi_wwan_manage_power(dev, on);
usbnet_disconnect() cannot continue to the point where it frees the
netdev before wdm_open/wdm_close has completed, because it waits for
qmi_wwan_unbind which waits for wdm_disconnect. And wdm_disconnect
takes the both read and write mutexes.
So I do not think there is any race there.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: Bjørn Mork @ 2012-06-23 9:26 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <20120622.171735.637204872051168180.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Date: Thu, 21 Jun 2012 14:45:58 +0200
>
>> Ignoring interfaces with additional descriptors is not a reliable
>> method for locating the correct interface on Gobi devices. There
>> is at least one device where this method fails:
>> https://bbs.archlinux.org/viewtopic.php?id=143506
>>
>> The result is that the AT command port (interface #2) is hidden
>> from qcserial, preventing traditional serial modem usage:
> ...
>> Use static interface numbers taken from the interface map in
>> qcserial for all Gobi devices instead:
> ...
>> This should be more reliable over all, and will also prevent the
>> noisy "probe failed" messages. The whitelisting logic is expected
>> to be replaced by direct interface number matching in 3.6.
>>
>> Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4: 0000188 USB: qmi_wwan: Make forced int 4 whitelist generic
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4: f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4
>> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>
> Applied.
Thanks.
Note that this patch will conflict with the qmi_wwan changes already in
net-next. I can prepare a minimal forward port if you like.
But I would really prefer to rewrite it completely for 3.6 instead,
taking advantage of the USB interface number matching in usb-next. That
will allow us to get rid of the ugly whitelisting logic and just match
directly on the USB interface number instead. Would that be OK? It
will depend on
81df2d5 USB: allow match on bInterfaceNumber
fec1868 USB: properly pad out usb_device_id.driver_info
from usb-next, so those must go into net-next before this is possible.
Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
an option?
I can of course also do the basic forward port now and then fix it up
later during the 3.6 cycle if you prefer that.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: David Miller @ 2012-06-23 9:37 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <87y5neidk1.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Sat, 23 Jun 2012 11:26:54 +0200
> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
> an option?
I'm extremely reluctant to have a dependency on another tree.
The USB tree, on the other hand, could pull the net-next tree
in so you can continue your dependent work there.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: Bjørn Mork @ 2012-06-23 10:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-usb, H.Siebmanns
In-Reply-To: <20120623.023749.1066357959466872561.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Bjørn Mork <bjorn@mork.no>
> Date: Sat, 23 Jun 2012 11:26:54 +0200
>
>> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
>> an option?
>
> I'm extremely reluctant to have a dependency on another tree.
fair enough
> The USB tree, on the other hand, could pull the net-next tree
> in so you can continue your dependent work there.
OK, that will be up to Greg then.
But failing that, would it be OK to let the 3.6 version of the fix wait
for -rc2? It's not a crash or any other kind of data loss bug, just a
usability regression with a workaround.
Bjørn
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: David Miller @ 2012-06-23 10:35 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <87txy2ibr8.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Sat, 23 Jun 2012 12:05:46 +0200
> But failing that, would it be OK to let the 3.6 version of the fix wait
> for -rc2? It's not a crash or any other kind of data loss bug, just a
> usability regression with a workaround.
I'm shortly going to merge net into net-next as I periodically do,
so I'm going to have to resolve the conflict regardless of how you
finally want to fix this Gobi device probing problem.
--
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
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