* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Bjørn Mork @ 2012-06-23 15:32 UTC (permalink / raw)
To: Ming Lei; +Cc: netdev, linux-usb, Marius Bjørnstad Kotsbak
In-Reply-To: <CACVXFVOZUvyNDzEoWT5o7JQRKjuw1pUgkipxV7dxT1w2Dd0H+A@mail.gmail.com>
Ming Lei <tom.leiming@gmail.com> writes:
> On Sat, Jun 23, 2012 at 4:45 PM, Bjørn Mork <bjorn@mork.no> wrote:
>
>> 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.
>
> Thanks for your explanation.
>
> I see, and your patch is correct, but it might not be generic enough.
>
> So driver_info->unbind will sync with .open/.close of the subdriver,
> just like unregister_netdev will sync with .open/.close of usbnet interface.
>
> IMO, the general solution is to keep intfdata's lifetime after ->unbind,
> which can guarantee that intfdata can be accessed safely in .open/.close
> of usbnet interface and the other subdrivers' device.
>
> Suppose there will be another usbnet driver which has its own subdriver
> too, the same trick of checking need to be added again if not taking the
> general way of simply removing 'usb_set_intfdata(intf, NULL);' in
> usbnet_disconnect.
Yes, I guess so.
I am just worrying (maybe too much) about the unknown consequences of
removing that code in usbnet, not fully understanding why it was there
in the first place. And I do not want to take the blame and cleanup
work if anything goes wrong :-) Fixing it in qmi_wwan feels much safer.
But if you want to remove the 'usb_set_intfdata(intf, NULL)', and the
other USB gurus agree, then I'm of course not going to object to that
alternative solution to this bug.
I still think it's unlikely this will ever hit another driver though.
Bjørn
^ permalink raw reply
* Re: [PATCH 0/2 net] Bug fixes for batman-adv 2012-06-23
From: Antonio Quartulli @ 2012-06-23 15:45 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1340465459-2949-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
On Sat, Jun 23, 2012 at 05:30:57 +0200, Antonio Quartulli wrote:
> Hello David,
>
> here are two fixes intended for net/linux-3.5.
>
> Patch 1 is a fix for the AP-Isolation feature. A wrong check made all the
> broadcast packets coming from any client be dropped before delivery to the
> interface.
> Patch 2 instead fixes a "real" race condition in the TranslationTable code.
>
> Please, tell me if there is any problem.
> Thank you,
> Antonio
>
>
>
> The following changes since commit a18e08bdcf845efb7344cea146e683df746bbfb4:
>
> net: sh_eth: fix the condition to fix the cur_tx/dirty_rx (2012-06-22 21:50:37 -0700)
>
> are available in the git repository at:
>
> git://git.open-mesh.org/linux-merge.git batman-adv/maint
>
> for you to fetch changes up to 8b8e4bc0391f8abbcdb9e1c54415bcc0f4f5a2a0:
>
> batman-adv: fix race condition in TT full-table replacement (2012-06-23 17:21:35 +0200)
>
Hello David,
after pulling these patchset in net, you should hit a conflict while trying to
merge net into net-next. The conflict is caused by the renaming patches that you
already have in the next tree.
Here are our instructions about how to solve it. Hope they will help.
Thank you.
Conflict 1:
<<<<<<<
orig_entry = container_of(rcu, struct batadv_tt_orig_list_entry, rcu);
atomic_dec(&orig_entry->orig_node->tt_size);
batadv_orig_node_free_ref(orig_entry->orig_node);
=======
orig_entry = container_of(rcu, struct tt_orig_list_entry, rcu);
orig_node_free_ref(orig_entry->orig_node);
>>>>>>>
Resolves to:
=======
orig_entry = container_of(rcu, struct batadv_tt_orig_list_entry, rcu);
batadv_orig_node_free_ref(orig_entry->orig_node);
=======
Conflict 2:
<<<<<<<
call_rcu(&orig_entry->rcu, batadv_tt_orig_list_entry_free_rcu);
=======
/* to avoid race conditions, immediately decrease the tt counter */
atomic_dec(&orig_entry->orig_node->tt_size);
call_rcu(&orig_entry->rcu, batadv_tt_orig_list_entry_free_rcu);
>>>>>>>
Resolves to:
=======
/* to avoid race conditions, immediately decrease the tt counter */
atomic_dec(&orig_entry->orig_node->tt_size);
call_rcu(&orig_entry->rcu, batadv_tt_orig_list_entry_free_rcu);
=======
Conflict 3:
<<<<<<<
struct batadv_tt_local_entry *tt_local_entry = NULL;
struct batadv_tt_global_entry *tt_global_entry = NULL;
bool ret = true;
=======
struct tt_local_entry *tt_local_entry = NULL;
struct tt_global_entry *tt_global_entry = NULL;
bool ret = false;
>>>>>>>
Resolves to:
=======
struct batadv_tt_local_entry *tt_local_entry = NULL;
struct batadv_tt_global_entry *tt_global_entry = NULL;
bool ret = false;
=======
Conflict 4:
<<<<<<<
if (_batadv_is_ap_isolated(tt_local_entry, tt_global_entry))
=======
if (!_is_ap_isolated(tt_local_entry, tt_global_entry))
>>>>>>>
Resolves to:
=======
if (!_batadv_is_ap_isolated(tt_local_entry, tt_global_entry))
=======
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 0/2 net] Bug fixes for batman-adv 2012-06-23
From: Antonio Quartulli @ 2012-06-23 15:30 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
here are two fixes intended for net/linux-3.5.
Patch 1 is a fix for the AP-Isolation feature. A wrong check made all the
broadcast packets coming from any client be dropped before delivery to the
interface.
Patch 2 instead fixes a "real" race condition in the TranslationTable code.
Please, tell me if there is any problem.
Thank you,
Antonio
The following changes since commit a18e08bdcf845efb7344cea146e683df746bbfb4:
net: sh_eth: fix the condition to fix the cur_tx/dirty_rx (2012-06-22 21:50:37 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git batman-adv/maint
for you to fetch changes up to 8b8e4bc0391f8abbcdb9e1c54415bcc0f4f5a2a0:
batman-adv: fix race condition in TT full-table replacement (2012-06-23 17:21:35 +0200)
----------------------------------------------------------------
Included changes:
- fix for the AP-isolation feature
- fix for a race condition in the TranslationTable code
----------------------------------------------------------------
Antonio Quartulli (1):
batman-adv: fix race condition in TT full-table replacement
Marek Lindner (1):
batman-adv: only drop packets of known wifi clients
net/batman-adv/translation-table.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 1/2 net] batman-adv: only drop packets of known wifi clients
From: Antonio Quartulli @ 2012-06-23 15:30 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Marek Lindner, Antonio Quartulli
In-Reply-To: <1340465459-2949-1-git-send-email-ordex@autistici.org>
From: Marek Lindner <lindner_marek@yahoo.de>
bug introduced with 59b699cdee039d75915c354da06937102d1f9a84
If the source or destination mac address of an ethernet packet
could not be found in the translation table the packet was
dropped if AP isolation was turned on. This behavior would
make it impossible to send broadcast packets over the mesh as
the broadcast address will never enter the translation table.
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---
net/batman-adv/translation-table.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index a66c2dc..660c40f 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -2031,10 +2031,10 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
{
struct tt_local_entry *tt_local_entry = NULL;
struct tt_global_entry *tt_global_entry = NULL;
- bool ret = true;
+ bool ret = false;
if (!atomic_read(&bat_priv->ap_isolation))
- return false;
+ goto out;
tt_local_entry = tt_local_hash_find(bat_priv, dst);
if (!tt_local_entry)
@@ -2044,10 +2044,10 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
if (!tt_global_entry)
goto out;
- if (_is_ap_isolated(tt_local_entry, tt_global_entry))
+ if (!_is_ap_isolated(tt_local_entry, tt_global_entry))
goto out;
- ret = false;
+ ret = true;
out:
if (tt_global_entry)
--
1.7.9.4
^ permalink raw reply related
* [PATCH 2/2 net] batman-adv: fix race condition in TT full-table replacement
From: Antonio Quartulli @ 2012-06-23 15:30 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1340465459-2949-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
bug introduced with cea194d90b11aff7fc289149e4c7f305fad3535a
In the current TT code, when a TT_Response containing a full table is received
from an originator, first the node purges all the clients for that originator in
the global translation-table and then merges the newly received table.
During the purging phase each client deletion is done by means of a call_rcu()
invocation and at the end of this phase the global entry counter for that
originator is set to 0. However the invoked rcu function decreases the global
entry counter for that originator by one too and since the rcu invocation is
likely to be postponed, the node will end up in first setting the counter to 0
and then decreasing it one by one for each deleted client.
This bug leads to having a wrong global entry counter for the related node, say
X. Then when the node with the broken counter will answer to a TT_REQUEST on
behalf of node X, it will create faulty TT_RESPONSE that will generate an
unrecoverable situation on the node that asked for the full table recover.
The non-recoverability is given by the fact that the node with the broken
counter will keep answering on behalf of X because its knowledge about X's state
(ttvn + tt_crc) is correct.
To solve this problem the counter is not explicitly set to 0 anymore and the
counter decrement is performed right before the invocation of call_rcu().
Signed-off-by: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
---
net/batman-adv/translation-table.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 660c40f..2ab83d7 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -141,13 +141,14 @@ static void tt_orig_list_entry_free_rcu(struct rcu_head *rcu)
struct tt_orig_list_entry *orig_entry;
orig_entry = container_of(rcu, struct tt_orig_list_entry, rcu);
- atomic_dec(&orig_entry->orig_node->tt_size);
orig_node_free_ref(orig_entry->orig_node);
kfree(orig_entry);
}
static void tt_orig_list_entry_free_ref(struct tt_orig_list_entry *orig_entry)
{
+ /* to avoid race conditions, immediately decrease the tt counter */
+ atomic_dec(&orig_entry->orig_node->tt_size);
call_rcu(&orig_entry->rcu, tt_orig_list_entry_free_rcu);
}
@@ -910,7 +911,6 @@ void tt_global_del_orig(struct bat_priv *bat_priv,
}
spin_unlock_bh(list_lock);
}
- atomic_set(&orig_node->tt_size, 0);
orig_node->tt_initialised = false;
}
--
1.7.9.4
^ permalink raw reply related
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Ben Hutchings @ 2012-06-23 15:02 UTC (permalink / raw)
To: Michael Chan; +Cc: David Miller, netdev, nsujir, mcarlson
In-Reply-To: <1340413453.4344.16.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
On Fri, 2012-06-22 at 18:04 -0700, Michael Chan wrote:
> 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?
Temperature and voltage can be exposed through an hwmon device (which
practically means you use multiple attributes with conventional names).
Other diagnostics might possible be suitable for ethtool stats,
depending on what they are.
If the driver can't easily parse the information (e.g. it varies greatly
between the different chips and firmware versions) then a binary
attribute or private ioctl might be appropriate. But generic interfaces
really should be considered first.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Ming Lei @ 2012-06-23 14:55 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb, Marius Bjørnstad Kotsbak
In-Reply-To: <8762aiju27.fsf@nemi.mork.no>
On Sat, Jun 23, 2012 at 4:45 PM, Bjørn Mork <bjorn@mork.no> wrote:
> 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.
Thanks for your explanation.
I see, and your patch is correct, but it might not be generic enough.
So driver_info->unbind will sync with .open/.close of the subdriver,
just like unregister_netdev will sync with .open/.close of usbnet interface.
IMO, the general solution is to keep intfdata's lifetime after ->unbind,
which can guarantee that intfdata can be accessed safely in .open/.close
of usbnet interface and the other subdrivers' device.
Suppose there will be another usbnet driver which has its own subdriver
too, the same trick of checking need to be added again if not taking the
general way of simply removing 'usb_set_intfdata(intf, NULL);' in
usbnet_disconnect.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: pull request: wireless 2012-06-22
From: Mohammed Shafi @ 2012-06-23 10:45 UTC (permalink / raw)
To: David Miller; +Cc: c_manoha, linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20120622.165611.2220193371527786713.davem@davemloft.net>
On Sat, Jun 23, 2012 at 5:26 AM, David Miller <davem@davemloft.net> 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.
apologies for the confusion, i haven't got a better timeout from very
few of the folks
queried, I should have updated that. As the patch is being already
pushed in, if we get
a proper timeout, we would fix it later with a proper timeout.
--
thanks,
shafi
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: Bjørn Mork @ 2012-06-23 10:44 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <20120623.033546.563917179592608418.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: 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.
OK. I just sent a forward ported version for net-next. Feel free to
use it instead of the conflicting one, or drop it if not necessary.
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
* [PATCH net-next] net: qmi_wwan: fix Gobi device probing
From: Bjørn Mork @ 2012-06-23 10:42 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, H.Siebmanns, Bjørn Mork
(forward port of commit b9f90eb27)
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:
[ 15.562552] qmi_wwan 4-1.6:1.0: cdc-wdm0: USB WDM device
[ 15.562691] qmi_wwan 4-1.6:1.0: wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
[ 15.563383] qmi_wwan: probe of 4-1.6:1.1 failed with error -22
[ 15.564189] qmi_wwan 4-1.6:1.2: cdc-wdm1: USB WDM device
[ 15.564302] qmi_wwan 4-1.6:1.2: wwan1: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
[ 15.564328] qmi_wwan: probe of 4-1.6:1.3 failed with error -22
[ 15.569376] qcserial 4-1.6:1.1: Qualcomm USB modem converter detected
[ 15.569440] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB0
[ 15.570372] qcserial 4-1.6:1.3: Qualcomm USB modem converter detected
[ 15.570430] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB1
Use static interface numbers taken from the interface map in
qcserial for all Gobi devices instead:
Gobi 1K USB layout:
0: serial port (doesn't respond)
1: serial port (doesn't respond)
2: AT-capable modem port
3: QMI/net
Gobi 2K+ USB layout:
0: QMI/net
1: DM/DIAG (use libqcdm from ModemManager for communication)
2: AT-capable modem port
3: NMEA
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@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 83 +++++++++++++++++++++-----------------------
1 file changed, 40 insertions(+), 43 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index f1e7791..68ca676 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -269,29 +269,6 @@ err:
return rv;
}
-/* Gobi devices uses identical class/protocol codes for all interfaces regardless
- * of function. Some of these are CDC ACM like and have the exact same endpoints
- * we are looking for. This leaves two possible strategies for identifying the
- * correct interface:
- * a) hardcoding interface number, or
- * b) use the fact that the wwan interface is the only one lacking additional
- * (CDC functional) descriptors
- *
- * Let's see if we can get away with the generic b) solution.
- */
-static int qmi_wwan_bind_gobi(struct usbnet *dev, struct usb_interface *intf)
-{
- int rv = -EINVAL;
-
- /* ignore any interface with additional descriptors */
- if (intf->cur_altsetting->extralen)
- goto err;
-
- rv = qmi_wwan_bind_shared(dev, intf);
-err:
- return rv;
-}
-
static void qmi_wwan_unbind(struct usbnet *dev, struct usb_interface *intf)
{
struct qmi_wwan_state *info = (void *)&dev->data;
@@ -375,15 +352,15 @@ static const struct driver_info qmi_wwan_shared = {
.manage_power = qmi_wwan_manage_power,
};
-static const struct driver_info qmi_wwan_gobi = {
- .description = "Qualcomm Gobi wwan/QMI device",
+static const struct driver_info qmi_wwan_force_int0 = {
+ .description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_gobi,
+ .bind = qmi_wwan_bind_shared,
.unbind = qmi_wwan_unbind,
.manage_power = qmi_wwan_manage_power,
+ .data = BIT(0), /* interface whitelist bitmap */
};
-/* ZTE suck at making USB descriptors */
static const struct driver_info qmi_wwan_force_int1 = {
.description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
@@ -393,6 +370,15 @@ static const struct driver_info qmi_wwan_force_int1 = {
.data = BIT(1), /* interface whitelist bitmap */
};
+static const struct driver_info qmi_wwan_force_int3 = {
+ .description = "Qualcomm WWAN/QMI device",
+ .flags = FLAG_WWAN,
+ .bind = qmi_wwan_bind_shared,
+ .unbind = qmi_wwan_unbind,
+ .manage_power = qmi_wwan_manage_power,
+ .data = BIT(3), /* interface whitelist bitmap */
+};
+
static const struct driver_info qmi_wwan_force_int4 = {
.description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
@@ -418,16 +404,23 @@ static const struct driver_info qmi_wwan_force_int4 = {
static const struct driver_info qmi_wwan_sierra = {
.description = "Sierra Wireless wwan/QMI device",
.flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_gobi,
+ .bind = qmi_wwan_bind_shared,
.unbind = qmi_wwan_unbind,
.manage_power = qmi_wwan_manage_power,
.data = BIT(8) | BIT(19), /* interface whitelist bitmap */
};
#define HUAWEI_VENDOR_ID 0x12D1
+
+/* Gobi 1000 QMI/wwan interface number is 3 according to qcserial */
+#define QMI_GOBI1K_DEVICE(vend, prod) \
+ USB_DEVICE(vend, prod), \
+ .driver_info = (unsigned long)&qmi_wwan_force_int3
+
+/* Gobi 2000 and Gobi 3000 QMI/wwan interface number is 0 according to qcserial */
#define QMI_GOBI_DEVICE(vend, prod) \
USB_DEVICE(vend, prod), \
- .driver_info = (unsigned long)&qmi_wwan_gobi
+ .driver_info = (unsigned long)&qmi_wwan_force_int0
static const struct usb_device_id products[] = {
{ /* Huawei E392, E398 and possibly others sharing both device id and more... */
@@ -538,20 +531,24 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 0xff,
.driver_info = (unsigned long)&qmi_wwan_sierra,
},
- {QMI_GOBI_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
- {QMI_GOBI_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
- {QMI_GOBI_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
- {QMI_GOBI_DEVICE(0x04da, 0x250d)}, /* Panasonic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x413c, 0x8172)}, /* Dell Gobi Modem device */
- {QMI_GOBI_DEVICE(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
- {QMI_GOBI_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
- {QMI_GOBI_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9001)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9002)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9202)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9203)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9222)}, /* Generic Gobi Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x9009)}, /* Generic Gobi Modem device */
+
+ /* Gobi 1000 devices */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
+ {QMI_GOBI1K_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
+ {QMI_GOBI1K_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
+ {QMI_GOBI1K_DEVICE(0x04da, 0x250d)}, /* Panasonic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x413c, 0x8172)}, /* Dell Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9001)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9002)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9202)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9203)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9222)}, /* Generic Gobi Modem device */
+ {QMI_GOBI1K_DEVICE(0x05c6, 0x9009)}, /* Generic Gobi Modem device */
+
+ /* Gobi 2000 and 3000 devices */
{QMI_GOBI_DEVICE(0x413c, 0x8186)}, /* Dell Gobi 2000 Modem device (N0218, VU936) */
{QMI_GOBI_DEVICE(0x05c6, 0x920b)}, /* Generic Gobi 2000 Modem device */
{QMI_GOBI_DEVICE(0x05c6, 0x9225)}, /* Sony Gobi 2000 Modem device (N0279, VU730) */
--
1.7.10
^ permalink raw reply related
* 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
* 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 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 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 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
* [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
* 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
* 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
* 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] 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: [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: 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: 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] 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: [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
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