Re: [GIT] Networking

2017-09-06 Thread Linus Torvalds 
On Wed, Sep 6, 2017 at 10:40 PM, Luca Coelho  wrote:
>
> This patch is not very important (unless you really like blinking lights
> -- maybe I'll change my mind when the holidays approach :P). so it is
> fine if you just want to revert it for now.
>
> In any case, I'll send a patch fixing this problem soon.

No need to revert if we can get this fixed quickly enough.

I'll leave the fw-31 on my laptop, so that I can continue to use it for now.

Thanks,

   Linus

Re: [GIT] Networking

2017-09-06 Thread Luca Coelho 
On Thu, 2017-09-07 at 05:04 +, Coelho, Luciano wrote:
> On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote:
> > On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
> >  wrote:
> > > 
> > > This seems to be a problem with backwards-compatibility with FW version
> > > 27.  We are now in version 31[1] and upgrading will probably fix that.
> > 
> > I can confirm that fw version 31 works.
> 
> Great, so I know for sure that this is a backwards-compatibility issue
> with the FW API.
> 
> 
> > > But obviously the driver should not fail miserably like this with
> > > version 27, because it claims to support it still.
> > 
> > Not just "claims to support it", but if it's what is shipped with a
> > fairly recent distro like an up-to-date version of F26, I would really
> > hope that the driver can still work with it.
> 
> I totally agree, we support a bunch of older versions for that exact
> reason.  We just don't really test all the supported versions very
> often.  We should probably change that.
> 
> I'll make sure it still works with version 27.

Okay, I found the offending patch:

commit 7089ae634c50544b29b31faf1a751e8765c8de3b
Author: Johannes Berg 
AuthorDate: Wed Jun 28 16:19:49 2017 +0200
Commit: Luca Coelho 
CommitDate: Wed Aug 9 09:15:32 2017 +0300

iwlwifi: mvm: use firmware LED command where applicable

On devices starting from 8000 series, the host can no longer toggle
the LED through the CSR_LED_REG register, but must do it via the
firmware instead. Add support for this. Note that this means that
the LED cannot be turned on while the firmware is off, so using an
arbitrary LED trigger may not work as expected.

Fixes: 503ab8c56ca0 ("iwlwifi: Add 8000 HW family support")
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 

Reverting it solves the problem.  We introduced a new command to control
the LED lights and assumed it was available in older FW versions as
well, which turned out not to be the case.

This patch is not very important (unless you really like blinking lights
-- maybe I'll change my mind when the holidays approach :P). so it is
fine if you just want to revert it for now.

In any case, I'll send a patch fixing this problem soon.


--
Cheers,
Luca.

Re: [GIT] Networking

2017-09-06 Thread Coelho, Luciano 
On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote:
> On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
>  wrote:
> > 
> > This seems to be a problem with backwards-compatibility with FW version
> > 27.  We are now in version 31[1] and upgrading will probably fix that.
> 
> I can confirm that fw version 31 works.

Great, so I know for sure that this is a backwards-compatibility issue
with the FW API.


> > But obviously the driver should not fail miserably like this with
> > version 27, because it claims to support it still.
> 
> Not just "claims to support it", but if it's what is shipped with a
> fairly recent distro like an up-to-date version of F26, I would really
> hope that the driver can still work with it.

I totally agree, we support a bunch of older versions for that exact
reason.  We just don't really test all the supported versions very
often.  We should probably change that.

I'll make sure it still works with version 27.

--
Cheers,
Luca.

Re: [GIT] Networking

2017-09-06 Thread Linus Torvalds 
On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
 wrote:
>
> This seems to be a problem with backwards-compatibility with FW version
> 27.  We are now in version 31[1] and upgrading will probably fix that.

I can confirm that fw version 31 works.

> But obviously the driver should not fail miserably like this with
> version 27, because it claims to support it still.

Not just "claims to support it", but if it's what is shipped with a
fairly recent distro like an up-to-date version of F26, I would really
hope that the driver can still work with it.

> I'm looking into this now and will provide a fix asap.

Thanks,

  Linus

Re: [GIT] Networking

2017-09-06 Thread Coelho, Luciano 
On Wed, 2017-09-06 at 16:27 -0700, Linus Torvalds wrote:
> This pull request completely breaks Intel wireless for me.
> 
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
> 
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
> 
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
> 
>   iwlwifi :3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm
> 
> the thing starts acting badly with this:
> 
>   iwlwifi :3a:00.0: FW Error notification: type 0x cmd_id 0x04
>   iwlwifi :3a:00.0: FW Error notification: seq 0x service 0x0004
>   iwlwifi :3a:00.0: FW Error notification: timestamp 0x5D84
>   iwlwifi :3a:00.0: Microcode SW error detected.  Restarting 0x200.
>   iwlwifi :3a:00.0: Start IWL Error Log Dump:
>   iwlwifi :3a:00.0: Status: 0x0100, count: 6
>   iwlwifi :3a:00.0: Loaded firmware version: 27.455470.0
>   iwlwifi :3a:00.0: 0x0038 | BAD_COMMAND
>   iwlwifi :3a:00.0: 0x00A002F0 | trm_hw_status0
>   ...
>   iwlwifi :3a:00.0: 0x | isr status reg
>   ieee80211 phy0: Hardware restart was requested
>   iwlwifi :3a:00.0: FW error in SYNC CMD MAC_CONTEXT_CMD

This seems to be a problem with backwards-compatibility with FW version
27.  We are now in version 31[1] and upgrading will probably fix that.

But obviously the driver should not fail miserably like this with
version 27, because it claims to support it still.

I'm looking into this now and will provide a fix asap.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/iwlwifi-8000C-31.ucode


--
Cheers,
Luca.

Re: [GIT] Networking

2017-09-06 Thread Linus Torvalds 
On Wed, Sep 6, 2017 at 4:27 PM, Linus Torvalds
 wrote:
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
>
>   iwlwifi :3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm

And when I said "iwlwifi-8000C-28.ucode" I obviously meant
"iwlwifi-8000C-27.ucode".

At least it was _hopefully_ obvious from that "27" in the actual
version number it reports.

Linus

Re: [GIT] Networking

2017-09-06 Thread David Miller 
From: Linus Torvalds 
Date: Wed, 6 Sep 2017 16:27:15 -0700

> This pull request completely breaks Intel wireless for me.
> 
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
> 
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
> 
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
 ...

Johannes and other Intel folks please look into this.

Re: [GIT] Networking

2017-09-06 Thread Linus Torvalds 
This pull request completely breaks Intel wireless for me.

This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).

That remains a very standard Intel machine with absolutely zero odd
things going on.

The firmware is iwlwifi-8000C-28.ucode from
iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports

  iwlwifi :3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm

the thing starts acting badly with this:

  iwlwifi :3a:00.0: FW Error notification: type 0x cmd_id 0x04
  iwlwifi :3a:00.0: FW Error notification: seq 0x service 0x0004
  iwlwifi :3a:00.0: FW Error notification: timestamp 0x5D84
  iwlwifi :3a:00.0: Microcode SW error detected.  Restarting 0x200.
  iwlwifi :3a:00.0: Start IWL Error Log Dump:
  iwlwifi :3a:00.0: Status: 0x0100, count: 6
  iwlwifi :3a:00.0: Loaded firmware version: 27.455470.0
  iwlwifi :3a:00.0: 0x0038 | BAD_COMMAND
  iwlwifi :3a:00.0: 0x00A002F0 | trm_hw_status0
  ...
  iwlwifi :3a:00.0: 0x | isr status reg
  ieee80211 phy0: Hardware restart was requested
  iwlwifi :3a:00.0: FW error in SYNC CMD MAC_CONTEXT_CMD
  CPU: 2 PID: 993 Comm: NetworkManager Not tainted 4.13.0-06466-g80cee03bf1d6 #4
  Hardware name: Dell Inc. XPS 13 9350/09JHRY, BIOS 1.4.17 05/10/2017
  Call Trace:
   dump_stack+0x4d/0x70
   iwl_trans_pcie_send_hcmd+0x4e7/0x530 [iwlwifi]
   ? wait_woken+0x80/0x80
   iwl_trans_send_cmd+0x5c/0xc0 [iwlwifi]
   iwl_mvm_send_cmd+0x32/0x90 [iwlmvm]
   iwl_mvm_send_cmd_pdu+0x58/0x80 [iwlmvm]
   iwl_mvm_mac_ctxt_send_cmd+0x2a/0x60 [iwlmvm]
   ? iwl_mvm_mac_ctxt_send_cmd+0x2a/0x60 [iwlmvm]
   iwl_mvm_mac_ctxt_cmd_sta+0x140/0x1e0 [iwlmvm]
   iwl_mvm_mac_ctx_send+0x2d/0x60 [iwlmvm]
   iwl_mvm_mac_ctxt_add+0x43/0xc0 [iwlmvm]
   iwl_mvm_mac_add_interface+0x139/0x2b0 [iwlmvm]
   ? iwl_led_brightness_set+0x1f/0x30 [iwlmvm]
   drv_add_interface+0x4a/0x120 [mac80211]
   ieee80211_do_open+0x33d/0x820 [mac80211]
   ieee80211_open+0x52/0x60 [mac80211]
   __dev_open+0xae/0x120
   __dev_change_flags+0x17b/0x1c0
   dev_change_flags+0x29/0x60
   do_setlink+0x2f7/0xe60
   ? __nla_put+0x20/0x30
   ? _raw_read_unlock_bh+0x20/0x30
   ? inet6_fill_ifla6_attrs+0x4be/0x4e0
   ? __kmalloc_node_track_caller+0x35/0x2b0
   ? nla_parse+0x35/0x100
   rtnl_newlink+0x5d2/0x8f0
   ? __netlink_sendskb+0x3b/0x60
   ? security_capset+0x40/0x80
   ? ns_capable_common+0x68/0x80
   ? ns_capable+0x13/0x20
   rtnetlink_rcv_msg+0x1f9/0x280
   ? rtnl_calcit.isra.26+0x110/0x110
   netlink_rcv_skb+0x8e/0x130
   rtnetlink_rcv+0x15/0x20
   netlink_unicast+0x18b/0x220
   netlink_sendmsg+0x2ad/0x3a0
   sock_sendmsg+0x38/0x50
   ___sys_sendmsg+0x269/0x2c0
   ? addrconf_sysctl_forward+0x114/0x280
   ? dev_forward_change+0x140/0x140
   ? sysctl_head_finish.part.22+0x32/0x40
   ? lockref_put_or_lock+0x5e/0x80
   ? dput.part.22+0x13e/0x1c0
   ? mntput+0x24/0x40
   __sys_sendmsg+0x54/0x90
   ? __sys_sendmsg+0x54/0x90
   SyS_sendmsg+0x12/0x20
   entry_SYSCALL_64_fastpath+0x13/0x94
  RIP: 0033:0x7ff1f9933134
  RSP: 002b:7ffe7419b460 EFLAGS: 0293 ORIG_RAX: 002e
  RAX: ffda RBX: 55604b6d82b9 RCX: 7ff1f9933134
  RDX:  RSI: 7ffe7419b4b0 RDI: 0007
  RBP: 7ffe7419b940 R08:  R09: 55604d16b400
  R10: 7ff1f7cf8b38 R11: 0293 R12: 0001
  R13: 0001 R14: 7ffe7419b670 R15: 55604b9515a0
  iwlwifi :3a:00.0: Failed to send MAC context (action:1): -5

and it doesn't get any better from there. The next error seems to be

  Timeout waiting for hardware access (CSR_GP_CNTRL 0x0808)
  [ cut here ]
  WARNING: CPU: 3 PID: 1075 at
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1874
iwl_trans_pcie_grab_nic_access+0xdf/0xf0 [iwlwifi]

and it will continue with those microcode failure errors and various
other warnigns about how nothing is working.

And no, nothing works.  A lot of log output, no actual network access..

  Linus

Re: [GIT] Networking

2017-08-31 Thread Kalle Valo 
(Adding linux-wireless)

Pavel Machek  writes:

> On Thu 2017-08-31 07:44:58, Kalle Valo wrote:
>> David Miller  writes:
>> 
>> > From: Kalle Valo 
>> > Date: Wed, 30 Aug 2017 20:31:31 +0300
>> >
>> >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug
>> >> has been there for 7 years so waiting for a few more weeks should not
>> >> hurt.
>> >
>> > As a maintainer you have a right to handle bug fixing in that way, but
>> > certainly that is not how I would handle this.
>> >
>> > It's easy to validate this fix, it's extremely unlikely to cause
>> > a regression, and fixes a problem someone actually was able to
>> > trigger.
>> >
>> > Deferring to -next only has the side effect of making people wait
>> > longer for the fix.
>> 
>> Yeah, you are right there. I did actually ponder which I tree should
>> commit it back in July but due to various reasons decided differently.
>
> Can we still get the fix to v4.13-final? :-).

I'm not planning to submit pull requests to 4.13 anymore. If you think
this is so important that it needs to be applied in the last minute (I
don't) you could always try to convince Dave to take it directly.

Or better yet, push it to the stable tree. If the merge window opens on
Sunday I suspect that the commit will be in Linus' tree sometime next
week. Then you can submit the request to the stable team to take it.

-- 
Kalle Valo

Re: [GIT] Networking

2017-01-09 Thread Kalle Valo 
Linus Torvalds  writes:

> On Sun, Jan 8, 2017 at 7:38 PM, David Miller  wrote:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>
> Hmm. This still doesn't contain the rtlwifi oops fix that was posted
> back before christmas.
>
> Kalle said it was applied to the wireless-drivers tree as commit
> 60f59ce02785 in his tree, but it's never gotten to me.
>
> What's up? It's three weeks later, and people are hitting the bug.

You mean this one:

60f59ce02785 rtlwifi: rtl_usb: Fix missing entry in USB driver's private data

I accidentally missed the patch during my holiday pull request,
committed the patch late, and I haven't sent a new pull request since.
Also the commit log didn't mention anything about an oops, only about
"missing an entry", so I didn't realise it was a critical fix.

Sorry about that, I'll send a new pull request to Dave first thing
tomorrow. It's too late now for me.

-- 
Kalle Valo

Re: [GIT] Networking

2016-05-19 Thread Reinoud Koornstra 
On Thu, May 19, 2016 at 2:20 AM, Reinoud Koornstra
 wrote:
> On Wed, May 18, 2016 at 12:51 PM, Linus Torvalds
>  wrote:
>> On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
>>  wrote:
>>>
>>> From what I can tell, there's a merge bug in commit 909b27f70643,
>>> where David seems to have lost some of the changes to
>>> iwl_mvm_set_tx_cmd().
>>>
>>> I do not know if that's the reason for the problem I see. But I will test.
>>
>> Yes. The attached patch that fixes the incorrect merge seems to fix
>> things for me.
>>
>> That should mean that the assumption that this problem existed in v4.6
>> too was wrong, because the incorrect merge came in later. I think
>> Luciano mis-understood "v4.6+" to mean plain v4.6.
>>
>> Reinoud Koornstra, does this patch fix things for you too?
>
> Indeed, I meant 4.6+, not 4.6.
> The patch you attached doesn't change existing code for me in 4.6+ as
> these two lines are already in there.
> Thanks,
>
> Reinoud.
>

In the 4.6+ code from today I reverted commit 5c08b0f5026f.
Now iwlwifi works fine for me again.
So it's as the Intel guys suspected.
I'll attached my revert compared to the current 4.6+ development code.
Thanks,

Reinoud.



>>
>>Linus
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index c53aa0f..00c9298 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,7 +211,6 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff 
*skb,
struct iwl_tx_cmd *tx_cmd,
struct ieee80211_tx_info *info, u8 sta_id)
 {
-   struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -295,7 +294,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff 
*skb,
tx_cmd->tx_flags = cpu_to_le32(tx_flags);
/* Total # bytes to be transmitted */
tx_cmd->len = cpu_to_le16((u16)skb->len +
-   (uintptr_t)skb_info->driver_data[0]);
+   (uintptr_t)info->driver_data[0]);
tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
tx_cmd->sta_id = sta_id;
 
@@ -443,11 +442,10 @@ static void iwl_mvm_set_tx_cmd_crypto(struct iwl_mvm *mvm,
  */
 static struct iwl_device_cmd *
 iwl_mvm_set_tx_params(struct iwl_mvm *mvm, struct sk_buff *skb,
- struct ieee80211_tx_info *info, int hdrlen,
- struct ieee80211_sta *sta, u8 sta_id)
+ int hdrlen, struct ieee80211_sta *sta, u8 sta_id)
 {
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
-   struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
+   struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct iwl_device_cmd *dev_cmd;
struct iwl_tx_cmd *tx_cmd;
 
@@ -467,10 +465,10 @@ iwl_mvm_set_tx_params(struct iwl_mvm *mvm, struct sk_buff 
*skb,
 
iwl_mvm_set_tx_cmd_rate(mvm, tx_cmd, info, sta, hdr->frame_control);
 
-   memset(_info->status, 0, sizeof(skb_info->status));
-   memset(skb_info->driver_data, 0, sizeof(skb_info->driver_data));
+   memset(>status, 0, sizeof(info->status));
+   memset(info->driver_data, 0, sizeof(info->driver_data));
 
-   skb_info->driver_data[1] = dev_cmd;
+   info->driver_data[1] = dev_cmd;
 
return dev_cmd;
 }
@@ -478,25 +476,22 @@ iwl_mvm_set_tx_params(struct iwl_mvm *mvm, struct sk_buff 
*skb,
 int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct sk_buff *skb)
 {
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
-   struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
-   struct ieee80211_tx_info info;
+   struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct iwl_device_cmd *dev_cmd;
struct iwl_tx_cmd *tx_cmd;
u8 sta_id;
int hdrlen = ieee80211_hdrlen(hdr->frame_control);
 
-   memcpy(, skb->cb, sizeof(info));
-
-   if (WARN_ON_ONCE(info.flags & IEEE80211_TX_CTL_AMPDU))
+   if (WARN_ON_ONCE(info->flags & IEEE80211_TX_CTL_AMPDU))
return -1;
 
-   if (WARN_ON_ONCE(info.flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM &&
-(!info.control.vif ||
- info.hw_queue != info.control.vif->cab_queue)))
+   if (WARN_ON_ONCE(info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM &&
+(!info->control.vif ||
+ info->hw_queue != info->control.vif->cab_queue)))
return -1;
 
/* This holds the amsdu headers length */
-   skb_info->driver_data[0] = (void *)(uintptr_t)0;
+   info->driver_data[0] = (void *)(uintptr_t)0;
 
/*
 * IWL_MVM_OFFCHANNEL_QUEUE is used for

Re: [GIT] Networking

2016-05-19 Thread Reinoud Koornstra 
On Wed, May 18, 2016 at 12:51 PM, Linus Torvalds
 wrote:
> On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
>  wrote:
>>
>> From what I can tell, there's a merge bug in commit 909b27f70643,
>> where David seems to have lost some of the changes to
>> iwl_mvm_set_tx_cmd().
>>
>> I do not know if that's the reason for the problem I see. But I will test.
>
> Yes. The attached patch that fixes the incorrect merge seems to fix
> things for me.
>
> That should mean that the assumption that this problem existed in v4.6
> too was wrong, because the incorrect merge came in later. I think
> Luciano mis-understood "v4.6+" to mean plain v4.6.
>
> Reinoud Koornstra, does this patch fix things for you too?

Indeed, I meant 4.6+, not 4.6.
The patch you attached doesn't change existing code for me in 4.6+ as
these two lines are already in there.
Thanks,

Reinoud.

>
>Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

2016-05-18 Thread David Miller 
From: Linus Torvalds 
Date: Wed, 18 May 2016 11:45:06 -0700

> David, do you happen to recall that merge conflict? I think you must
> have removed that "skb_info" variable declaration and initialization
> manually (due to the "unused variable" warning, which in turn was due
> to the incorrect merge of the actual conflict), because I think git
> would have merged that line into the result.

Yes, I know I buggered this merge conflict and Kalle said he'd have
a fix coming my way ASAP.

Sorry, I was travelling today, so I'll catch up with this tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

2016-05-18 Thread Kalle Valo 
Linus Torvalds  writes:

> On Wed, May 18, 2016 at 11:58 AM, Kalle Valo  wrote:
>>
>> It would be best if you could send a patch either directly to Dave or
>> Linus to resolve this quickly.
>
> I'm committing my patch myself right now, since this bug makes my
> laptop useless, and I will take credit for finding and testing it on
> my own

Kiitti :)

> even if it was apparently also discussed independently on the
> networking list ;)

Yeah, sorry about taking this too long.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

2016-05-18 Thread Coelho, Luciano 
On Wed, 2016-05-18 at 12:00 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 11:58 AM, Kalle Valo 
> wrote:
> > 
> > 
> > It would be best if you could send a patch either directly to Dave
> > or
> > Linus to resolve this quickly.
> I'm committing my patch myself right now, since this bug makes my
> laptop useless, and I will take credit for finding and testing it on
> my own even if it was apparently also discussed independently on the
> networking list ;)

Great! :)

You beat me by a few minutes, even though I had the whole day to play
with it. :\

--
Cheers,
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [GIT] Networking

2016-05-18 Thread Linus Torvalds 
On Wed, May 18, 2016 at 11:58 AM, Kalle Valo  wrote:
>
> It would be best if you could send a patch either directly to Dave or
> Linus to resolve this quickly.

I'm committing my patch myself right now, since this bug makes my
laptop useless, and I will take credit for finding and testing it on
my own even if it was apparently also discussed independently on the
networking list ;)

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

2016-05-18 Thread Kalle Valo 
"Coelho, Luciano"  writes:

> Kalle, David, what is the status with the fix that is on the way via
> your trees?

It would be best if you could send a patch either directly to Dave or
Linus to resolve this quickly.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

2016-05-18 Thread Linus Torvalds 
On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
 wrote:
>
> From what I can tell, there's a merge bug in commit 909b27f70643,
> where David seems to have lost some of the changes to
> iwl_mvm_set_tx_cmd().
>
> I do not know if that's the reason for the problem I see. But I will test.

Yes. The attached patch that fixes the incorrect merge seems to fix
things for me.

That should mean that the assumption that this problem existed in v4.6
too was wrong, because the incorrect merge came in later. I think
Luciano mis-understood "v4.6+" to mean plain v4.6.

Reinoud Koornstra, does this patch fix things for you too?

   Linus
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 880210917a6f..c53aa0f220e0 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,6 +211,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff 
*skb,
struct iwl_tx_cmd *tx_cmd,
struct ieee80211_tx_info *info, u8 sta_id)
 {
+   struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -294,7 +295,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff 
*skb,
tx_cmd->tx_flags = cpu_to_le32(tx_flags);
/* Total # bytes to be transmitted */
tx_cmd->len = cpu_to_le16((u16)skb->len +
-   (uintptr_t)info->driver_data[0]);
+   (uintptr_t)skb_info->driver_data[0]);
tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
tx_cmd->sta_id = sta_id;

Re: [GIT] Networking

2016-05-18 Thread Coelho, Luciano 
On Wed, 2016-05-18 at 11:45 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
>  wrote:
> > 
> > 
> > I can confirm that 4.6 contains the same bug.  And reverting the
> > patch
> > I mentioned does solve the problem...
> > 
> > The same patch works fine in our internal tree.  I'll have to
> > figure
> > out together with Emmanuel what the problem actually is.
> Hmm.
> 
> From what I can tell, there's a merge bug in commit 909b27f70643,
> where David seems to have lost some of the changes to
> iwl_mvm_set_tx_cmd().
> 
> The reason seems to be a conflict with d8fe484470dd, where David
> missed the fact that "info->driver_data[0]" had become
> "skb_info->driver_data[0]", and then he removed the skb_info because
> it was unused.
> 
> I do not know if that's the reason for the problem I see. But I will
> test.
> 
> David, do you happen to recall that merge conflict? I think you must
> have removed that "skb_info" variable declaration and initialization
> manually (due to the "unused variable" warning, which in turn was due
> to the incorrect merge of the actual conflict), because I think git
> would have merged that line into the result.

Actually I just tested it and indeed it seems to be the merge damage
(which we discussed extensively in the linux-wireless mailing list)
that causes this problem.  The "4.6 doesn't work either" thing was a
false alarm.

If the merge damage is fixed this way, the problem is gone:

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index b5f7c36..ae2ecf6 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,6 +211,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct
sk_buff *skb,
struct iwl_tx_cmd *tx_cmd,
struct ieee80211_tx_info *info, u8 sta_id)
 {
+   struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -294,7 +295,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct
sk_buff *skb,
tx_cmd->tx_flags = cpu_to_le32(tx_flags);
/* Total # bytes to be transmitted */
tx_cmd->len = cpu_to_le16((u16)skb->len +
-   (uintptr_t)info->driver_data[0]);
+   (uintptr_t)skb_info->driver_data[0]);
tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
tx_cmd->sta_id = sta_id;


Kalle, David, what is the status with the fix that is on the way via
your trees?

--
Cheers,
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [GIT] Networking

2016-05-18 Thread Linus Torvalds 
On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
 wrote:
>
> I can confirm that 4.6 contains the same bug.  And reverting the patch
> I mentioned does solve the problem...
>
> The same patch works fine in our internal tree.  I'll have to figure
> out together with Emmanuel what the problem actually is.

Hmm.

>From what I can tell, there's a merge bug in commit 909b27f70643,
where David seems to have lost some of the changes to
iwl_mvm_set_tx_cmd().

The reason seems to be a conflict with d8fe484470dd, where David
missed the fact that "info->driver_data[0]" had become
"skb_info->driver_data[0]", and then he removed the skb_info because
it was unused.

I do not know if that's the reason for the problem I see. But I will test.

David, do you happen to recall that merge conflict? I think you must
have removed that "skb_info" variable declaration and initialization
manually (due to the "unused variable" warning, which in turn was due
to the incorrect merge of the actual conflict), because I think git
would have merged that line into the result.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

2016-05-18 Thread Coelho, Luciano 
On Wed, 2016-05-18 at 06:51 -0600, Reinoud Koornstra wrote:
> On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano
>  wrote:
> > 
> > On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
> > > 
> > > On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
> > >  wrote:
> > > > 
> > > > 
> > > > Hi Emmanuel, Linus,
> > > > 
> > > > 
> > > > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
> > > > > 
> > > > > 
> > > > > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
> > > > >  wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Tue, May 17, 2016 at 12:11 PM, David Miller  > > > > > loft
> > > > > > .net
> > > > > > > 
> > > > > > > 
> > > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > Highlights:
> > > > > > Lowlights:
> > > > > > 
> > > > > >  1) the iwlwifi driver seems to be broken
> > > > > > 
> > > > > > My laptop that uses the intel 7680 iwlwifi module no longer
> > > > > > connects
> > > > > > to the network. It fails with a "Microcode SW error
> > > > > > detected."
> > > > > > and
> > > > > > spews out register state over and over again.
> > > > > Can we have the register state and the ASSERT / NMI /
> > > > > whatever
> > > > > that
> > > > > goes along with it?
> > > > > This clearly means that the firmware is crashing, but I don't
> > > > > know
> > > > > why,
> > > > > I copied here the lines that I need from another bug with
> > > > > another
> > > > > device with another firmware,
> > > > > but the log that we will still explain what I need:
> > > > I managed to reproduce this bug locally with Linus'
> > > > master.  I'm
> > > > investigating the cause and I'll let you how it goes.
> > > I did run the latest git code as well 4.6+
> > > iwlwifi went pearshape in my case as well.
> > > I just updated the microcode as well, it didn't matter.
> > > 4.6-rc7 works fine and no errors are reported with iwlwifi.
> > > 
> > > Here's output that might come in handy
> > Thanks! That is helpful.
> > 
> > Since you say that 4.6-rc7 works but 4.6 doesn't, the prime suspect
> > is
> > commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with
> > the
> > AMSDU len"), which is the only iwlwifi patch between those two
> > releases.
> > 
> > Could you try to revert that and see if the error is gone?
> Will do, since git revert failed I'll revert manually and report
> back.

I can confirm that 4.6 contains the same bug.  And reverting the patch
I mentioned does solve the problem...

The same patch works fine in our internal tree.  I'll have to figure
out together with Emmanuel what the problem actually is.

--
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [GIT] Networking

2016-05-18 Thread Reinoud Koornstra 
On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano
 wrote:
> On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
>> On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
>>  wrote:
>> >
>> > Hi Emmanuel, Linus,
>> >
>> >
>> > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
>> > >
>> > > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
>> > >  wrote:
>> > > >
>> > > >
>> > > > On Tue, May 17, 2016 at 12:11 PM, David Miller > > > > .net
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > >
>> > > > > Highlights:
>> > > > Lowlights:
>> > > >
>> > > >  1) the iwlwifi driver seems to be broken
>> > > >
>> > > > My laptop that uses the intel 7680 iwlwifi module no longer
>> > > > connects
>> > > > to the network. It fails with a "Microcode SW error detected."
>> > > > and
>> > > > spews out register state over and over again.
>> > > Can we have the register state and the ASSERT / NMI / whatever
>> > > that
>> > > goes along with it?
>> > > This clearly means that the firmware is crashing, but I don't
>> > > know
>> > > why,
>> > > I copied here the lines that I need from another bug with another
>> > > device with another firmware,
>> > > but the log that we will still explain what I need:
>> > I managed to reproduce this bug locally with Linus' master.  I'm
>> > investigating the cause and I'll let you how it goes.
>> I did run the latest git code as well 4.6+
>> iwlwifi went pearshape in my case as well.
>> I just updated the microcode as well, it didn't matter.
>> 4.6-rc7 works fine and no errors are reported with iwlwifi.
>>
>> Here's output that might come in handy
>
> Thanks! That is helpful.
>
> Since you say that 4.6-rc7 works but 4.6 doesn't, the prime suspect is
> commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the
> AMSDU len"), which is the only iwlwifi patch between those two
> releases.
>
> Could you try to revert that and see if the error is gone?

Will do, since git revert failed I'll revert manually and report back.

>
> --
> Cheers,
> Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

2016-05-18 Thread Coelho, Luciano 
On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
> On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
>  wrote:
> > 
> > Hi Emmanuel, Linus,
> > 
> > 
> > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
> > > 
> > > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
> > >  wrote:
> > > > 
> > > > 
> > > > On Tue, May 17, 2016 at 12:11 PM, David Miller  > > > .net
> > > > > 
> > > > > wrote:
> > > > > 
> > > > > 
> > > > > Highlights:
> > > > Lowlights:
> > > > 
> > > >  1) the iwlwifi driver seems to be broken
> > > > 
> > > > My laptop that uses the intel 7680 iwlwifi module no longer
> > > > connects
> > > > to the network. It fails with a "Microcode SW error detected."
> > > > and
> > > > spews out register state over and over again.
> > > Can we have the register state and the ASSERT / NMI / whatever
> > > that
> > > goes along with it?
> > > This clearly means that the firmware is crashing, but I don't
> > > know
> > > why,
> > > I copied here the lines that I need from another bug with another
> > > device with another firmware,
> > > but the log that we will still explain what I need:
> > I managed to reproduce this bug locally with Linus' master.  I'm
> > investigating the cause and I'll let you how it goes.
> I did run the latest git code as well 4.6+
> iwlwifi went pearshape in my case as well.
> I just updated the microcode as well, it didn't matter.
> 4.6-rc7 works fine and no errors are reported with iwlwifi.
> 
> Here's output that might come in handy

Thanks! That is helpful.

Since you say that 4.6-rc7 works but 4.6 doesn't, the prime suspect is
commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the
AMSDU len"), which is the only iwlwifi patch between those two
releases.

Could you try to revert that and see if the error is gone?

--
Cheers,
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [GIT] Networking

2016-05-18 Thread Reinoud Koornstra 
On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
 wrote:
> Hi Emmanuel, Linus,
>
>
> On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
>> On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
>>  wrote:
>> >
>> > On Tue, May 17, 2016 at 12:11 PM, David Miller > > > wrote:
>> > >
>> > >
>> > > Highlights:
>> > Lowlights:
>> >
>> >  1) the iwlwifi driver seems to be broken
>> >
>> > My laptop that uses the intel 7680 iwlwifi module no longer
>> > connects
>> > to the network. It fails with a "Microcode SW error detected." and
>> > spews out register state over and over again.
>> Can we have the register state and the ASSERT / NMI / whatever that
>> goes along with it?
>> This clearly means that the firmware is crashing, but I don't know
>> why,
>> I copied here the lines that I need from another bug with another
>> device with another firmware,
>> but the log that we will still explain what I need:
>
> I managed to reproduce this bug locally with Linus' master.  I'm
> investigating the cause and I'll let you how it goes.

I did run the latest git code as well 4.6+
iwlwifi went pearshape in my case as well.
I just updated the microcode as well, it didn't matter.
4.6-rc7 works fine and no errors are reported with iwlwifi.

Here's output that might come in handy

[   17.436340] iwlwifi :04:00.0: loaded firmware version
16.242414.0 op_mode iwlmvm
[   17.714920] iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144

SNIP
[  114.837923] wlp4s0: authenticate with 00:30:44:1d:cf:2b
[  114.841365] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
[  114.842073] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 2/3)
[  115.041992] iwlwifi :04:00.0: Microcode SW error detected.
Restarting 0x200.
[  115.041995] iwlwifi :04:00.0: CSR values:
[  115.041996] iwlwifi :04:00.0: (2nd byte of CSR_INT_COALESCING
is CSR_INT_PERIODIC_REG)
[  115.042000] iwlwifi :04:00.0:CSR_HW_IF_CONFIG_REG: 0X40489204
[  115.042003] iwlwifi :04:00.0:  CSR_INT_COALESCING: 0X8040
[  115.042006] iwlwifi :04:00.0: CSR_INT: 0X
[  115.042009] iwlwifi :04:00.0:CSR_INT_MASK: 0X
[  115.042013] iwlwifi :04:00.0:   CSR_FH_INT_STATUS: 0X
[  115.042016] iwlwifi :04:00.0: CSR_GPIO_IN: 0X
[  115.042019] iwlwifi :04:00.0:   CSR_RESET: 0X
[  115.042022] iwlwifi :04:00.0:CSR_GP_CNTRL: 0X080403c5
[  115.042026] iwlwifi :04:00.0:  CSR_HW_REV: 0X0144
[  115.042029] iwlwifi :04:00.0:  CSR_EEPROM_REG: 0X
[  115.042032] iwlwifi :04:00.0:   CSR_EEPROM_GP: 0X8000
[  115.042035] iwlwifi :04:00.0:  CSR_OTP_GP_REG: 0X803a
[  115.042038] iwlwifi :04:00.0: CSR_GIO_REG: 0X001f0044
[  115.042042] iwlwifi :04:00.0:CSR_GP_UCODE_REG: 0X
[  115.042045] iwlwifi :04:00.0:   CSR_GP_DRIVER_REG: 0X
[  115.042048] iwlwifi :04:00.0:   CSR_UCODE_DRV_GP1: 0X
[  115.042051] iwlwifi :04:00.0:   CSR_UCODE_DRV_GP2: 0X
[  115.042054] iwlwifi :04:00.0: CSR_LED_REG: 0X0060
[  115.042058] iwlwifi :04:00.0:CSR_DRAM_INT_TBL_REG: 0X88035a74
[  115.042061] iwlwifi :04:00.0:CSR_GIO_CHICKEN_BITS: 0X27800200
[  115.042064] iwlwifi :04:00.0: CSR_ANA_PLL_CFG: 0Xd5d5
[  115.042067] iwlwifi :04:00.0:  CSR_MONITOR_STATUS_REG: 0X3d0801bd
[  115.042070] iwlwifi :04:00.0:   CSR_HW_REV_WA_REG: 0X0001001a
[  115.042074] iwlwifi :04:00.0:CSR_DBG_HPET_MEM_REG: 0X
[  115.042075] iwlwifi :04:00.0: FH register values:
[  115.042086] iwlwifi :04:00.0:
FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X455fd200
[  115.042097] iwlwifi :04:00.0:
FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X04556370
[  115.042108] iwlwifi :04:00.0:
FH_RSCSR_CHNL0_WPTR: 0X0078
[  115.042119] iwlwifi :04:00.0:
FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X00801114
[  115.042129] iwlwifi :04:00.0:
FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc
[  115.042140] iwlwifi :04:00.0:
FH_MEM_RSSR_RX_STATUS_REG: 0X0303
[  115.042151] iwlwifi :04:00.0:
FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X
[  115.042162] iwlwifi :04:00.0:
FH_TSSR_TX_STATUS_REG: 0X07ff0001
[  115.042173] iwlwifi :04:00.0:
FH_TSSR_TX_ERROR_REG: 0X
[  115.042278] iwlwifi :04:00.0: Start IWL Error Log Dump:
[  115.042279] iwlwifi :04:00.0: Status: 0x, count: 6
[  115.042280] iwlwifi :04:00.0: Loaded firmware version: 16.242414.0
[  115.042281] iwlwifi :04:00.0: 0x0034 | NMI_INTERRUPT_WDG
[  115.042282] iwlwifi :04:00.0: 0x059002A0 | trm_hw_status0
[  115.042283] iwlwifi :04:00.0: 0x | trm_hw_status1
[  115.042284] iwlwifi :04:00.0:

Re: [GIT] Networking

2016-05-18 Thread Coelho, Luciano 
Hi Emmanuel, Linus,


On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
> On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
>  wrote:
> > 
> > On Tue, May 17, 2016 at 12:11 PM, David Miller  > > wrote:
> > > 
> > > 
> > > Highlights:
> > Lowlights:
> > 
> >  1) the iwlwifi driver seems to be broken
> > 
> > My laptop that uses the intel 7680 iwlwifi module no longer
> > connects
> > to the network. It fails with a "Microcode SW error detected." and
> > spews out register state over and over again.
> Can we have the register state and the ASSERT / NMI / whatever that
> goes along with it?
> This clearly means that the firmware is crashing, but I don't know
> why,
> I copied here the lines that I need from another bug with another
> device with another firmware,
> but the log that we will still explain what I need:

I managed to reproduce this bug locally with Linus' master.  I'm
investigating the cause and I'll let you how it goes.

--
Cheers,
Luca.

Re: [GIT] Networking

2016-05-17 Thread Emmanuel Grumbach 
On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
 wrote:
> On Tue, May 17, 2016 at 12:11 PM, David Miller  wrote:
>>
>> Highlights:
>
> Lowlights:
>
>  1) the iwlwifi driver seems to be broken
>
> My laptop that uses the intel 7680 iwlwifi module no longer connects
> to the network. It fails with a "Microcode SW error detected." and
> spews out register state over and over again.

Can we have the register state and the ASSERT / NMI / whatever that
goes along with it?
This clearly means that the firmware is crashing, but I don't know why,
I copied here the lines that I need from another bug with another
device with another firmware,
but the log that we will still explain what I need:

[  800.880402] iwlwifi :02:00.0: Start IWL Error Log Dump:
[  800.880406] iwlwifi :02:00.0: Status: 0x, count: 6
[  800.880409] iwlwifi :02:00.0: Loaded firmware version: 21.311951.0
[  800.880413] iwlwifi :02:00.0: 0x0394 | ADVANCED_SYSASSERT
[  800.880416] iwlwifi :02:00.0: 0x0220 | trm_hw_status0
[  800.880419] iwlwifi :02:00.0: 0x | trm_hw_status1
[  800.880422] iwlwifi :02:00.0: 0x0BD8 | branchlink2
[  800.880425] iwlwifi :02:00.0: 0x00026AC4 | interruptlink1
[  800.880428] iwlwifi :02:00.0: 0x | interruptlink2
[  800.880431] iwlwifi :02:00.0: 0x0001 | data1
[  800.880434] iwlwifi :02:00.0: 0x02039845 | data2
[  800.880437] iwlwifi :02:00.0: 0x0056 | data3
[  800.880440] iwlwifi :02:00.0: 0x8E4184A7 | beacon time
[  800.880443] iwlwifi :02:00.0: 0x30E2CB41 | tsf low
[  800.880446] iwlwifi :02:00.0: 0x0027 | tsf hi
[  800.880449] iwlwifi :02:00.0: 0x | time gp1
[  800.880451] iwlwifi :02:00.0: 0x2F842F8A | time gp2
[  800.880454] iwlwifi :02:00.0: 0x | uCode revision type
[  800.880457] iwlwifi :02:00.0: 0x0015 | uCode version major
[  800.880460] iwlwifi :02:00.0: 0x0004C28F | uCode version minor
[  800.880463] iwlwifi :02:00.0: 0x0201 | hw version
[  800.880466] iwlwifi :02:00.0: 0x00489008 | board version
[  800.880469] iwlwifi :02:00.0: 0x001C | hcmd
[  800.880472] iwlwifi :02:00.0: 0x24022000 | isr0
[  800.880475] iwlwifi :02:00.0: 0x0100 | isr1
[  800.880478] iwlwifi :02:00.0: 0x580A | isr2
[  800.880481] iwlwifi :02:00.0: 0x4041FCC1 | isr3
[  800.880483] iwlwifi :02:00.0: 0x | isr4
[  800.880486] iwlwifi :02:00.0: 0x00800110 | last cmd Id
[  800.880489] iwlwifi :02:00.0: 0x | wait_event
[  800.880492] iwlwifi :02:00.0: 0x02C8 | l2p_control
[  800.880495] iwlwifi :02:00.0: 0x00018030 | l2p_duration
[  800.880498] iwlwifi :02:00.0: 0x00BF | l2p_mhvalid
[  800.880501] iwlwifi :02:00.0: 0x00EF | l2p_addr_match
[  800.880503] iwlwifi :02:00.0: 0x000D | lmpm_pmg_sel
[  800.880506] iwlwifi :02:00.0: 0x30031805 | timestamp
[  800.880509] iwlwifi :02:00.0: 0xE0F0 | flow_handler




>
> The last thing it says before falling over is:
>
>   wlp1s0: authenticate with xx:xx:xx:xx:xx:xx
>   wlp1s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
>   wlp1s0: send auth to xx:xx:xx:xx:xx:xx (try 2/3)
>
> and then it goes all titsup.
>
> I thought that it might be because I had downloaded one of the daily
> firmware versions (it calls itself iwlwifi-7260-17.ucode, but isn't a
> real release afaik - but it has worked fien for me before), but the
> problem persists with the ver-16 ucode too, so that wasn't it.
>
> I haven't bisected it, but there is absolutely nothing odd in my hardware.
>
> I do have a 802.11ac network, which apparently not everybody does,
> judging by previous bug-reports of mine..
>
> Intel iwlwifi people: please check this out.
>
>Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

2016-05-17 Thread Linus Torvalds 
On Tue, May 17, 2016 at 12:11 PM, David Miller  wrote:
>
> Highlights:

Lowlights:

 1) the iwlwifi driver seems to be broken

My laptop that uses the intel 7680 iwlwifi module no longer connects
to the network. It fails with a "Microcode SW error detected." and
spews out register state over and over again.

The last thing it says before falling over is:

  wlp1s0: authenticate with xx:xx:xx:xx:xx:xx
  wlp1s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
  wlp1s0: send auth to xx:xx:xx:xx:xx:xx (try 2/3)

and then it goes all titsup.

I thought that it might be because I had downloaded one of the daily
firmware versions (it calls itself iwlwifi-7260-17.ucode, but isn't a
real release afaik - but it has worked fien for me before), but the
problem persists with the ver-16 ucode too, so that wasn't it.

I haven't bisected it, but there is absolutely nothing odd in my hardware.

I do have a 802.11ac network, which apparently not everybody does,
judging by previous bug-reports of mine..

Intel iwlwifi people: please check this out.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html