| Message ID | CANUX_P1j9QNGQ2n02KpXsuMQcZo9uOsSN-zZ8yNS1e5+Y9bJOA@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
2013/12/25 Emmanuel Grumbach <egrumbach@gmail.com>: > Back to you. > Can you please try not to do the setpci and add this: Glad to see you again :-) I've compiled Linux 3.12.5 with your patch, removed "setpci" trick and rebooted. During the boot of new kernel, I can see additional (error) messages among "systemd-fsck" lines but I was not fast enough to take photos for them before they disappeared (flushed away) by tty login interface. After logging in, I find that netcfg did not connect to dormitory's Wi-Fi as before. I run "lspci -vvxxx" and find that the interface is filled with "ff". I've attached the output of "lspci -vvxxx" and "dmesg". (And here is something "fun": I reverted my kernel to Arch's official 3.12.5 and rebooted, and the interface is totally missing! I mean, it disappeared from the output of "ip link". I cannot even see it in "lspci -vvxxx", not even "ff". The strange effect vanished after one more reboot and a cold boot.)
PiANCj4gDQo+IEdsYWQgdG8gc2VlIHlvdSBhZ2FpbiA6LSkNCj4gDQo+IEkndmUgY29tcGlsZWQg TGludXggMy4xMi41IHdpdGggeW91ciBwYXRjaCwgcmVtb3ZlZCAic2V0cGNpIiB0cmljayBhbmQN Cj4gcmVib290ZWQuDQo+IA0KPiBEdXJpbmcgdGhlIGJvb3Qgb2YgbmV3IGtlcm5lbCwgSSBjYW4g c2VlIGFkZGl0aW9uYWwgKGVycm9yKSBtZXNzYWdlcyBhbW9uZw0KPiAic3lzdGVtZC1mc2NrIiBs aW5lcyBidXQgSSB3YXMgbm90IGZhc3QgZW5vdWdoIHRvIHRha2UgcGhvdG9zIGZvciB0aGVtDQo+ IGJlZm9yZSB0aGV5IGRpc2FwcGVhcmVkIChmbHVzaGVkIGF3YXkpIGJ5IHR0eSBsb2dpbiBpbnRl cmZhY2UuDQo+IA0KPiBBZnRlciBsb2dnaW5nIGluLCBJIGZpbmQgdGhhdCBuZXRjZmcgZGlkIG5v dCBjb25uZWN0IHRvIGRvcm1pdG9yeSdzIFdpLUZpIGFzDQo+IGJlZm9yZS4gSSBydW4gImxzcGNp IC12dnh4eCIgYW5kIGZpbmQgdGhhdCB0aGUgaW50ZXJmYWNlIGlzIGZpbGxlZCB3aXRoICJmZiIu IEkndmUNCj4gYXR0YWNoZWQgdGhlIG91dHB1dCBvZiAibHNwY2kgLXZ2eHh4IiBhbmQgImRtZXNn Ii4NCj4gDQoNClNvIGl0IGRpZG4ndCB3b3JrIC0gb2suIEkgYW0gbm90IHN1cnByaXNlZCwgYnV0 IEkgc3RpbGwgd2FudGVkIHRvIGtub3cuDQpUaGlzIHBhdGNoIGlzIHN1cHBvc2VkIHRvIGZpeCBz b21lIHRpbWluZyBpc3N1ZSBpbiB0aGUgd2FrZSB1cCBmcm9tIEwxLg0KVGhhbmtzIGZvciB0ZXN0 aW5nLg0KDQo+IA0KPiAoQW5kIGhlcmUgaXMgc29tZXRoaW5nICJmdW4iOiBJIHJldmVydGVkIG15 IGtlcm5lbCB0byBBcmNoJ3Mgb2ZmaWNpYWwNCj4gMy4xMi41IGFuZCByZWJvb3RlZCwgYW5kIHRo ZSBpbnRlcmZhY2UgaXMgdG90YWxseSBtaXNzaW5nISBJIG1lYW4sIGl0DQo+IGRpc2FwcGVhcmVk IGZyb20gdGhlIG91dHB1dCBvZiAiaXAgbGluayIuIEkgY2Fubm90IGV2ZW4gc2VlIGl0IGluICJs c3BjaSAtDQo+IHZ2eHh4Iiwgbm90IGV2ZW4gImZmIi4gVGhlIHN0cmFuZ2UgZWZmZWN0IHZhbmlz aGVkIGFmdGVyIG9uZSBtb3JlIHJlYm9vdA0KPiBhbmQgYSBjb2xkIGJvb3QuKQ0KDQpHcmVhdCAt IHRoYXQgY2FuIGhhcHBlbiBzb21ldGltZXMgd2hlbiBzb21ldGhpbmcgZ29lcyB3cm9uZy4uLg0K -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, yesterday a friend of mine told me that one can now install Windows 8/8.1 on a USB device natively. So I tried this so-called "Windows To Go" technology. Now I have successfully deployed a Windows 8.1 installation on my external USB HDD and booted my laptop up with it. That is to say, I can now observe how Intel 7260 acts under Windows.
(Sorry for sending this mail multiple times...) Hi, yesterday a friend of mine told me that one can now install Windows 8/8.1 on a USB device natively. So I tried this so-called "Windows To Go" technology. Now I have successfully deployed a Windows 8.1 installation on my external USB HDD and booted my laptop up with it. That is to say, I can now observe how Intel 7260 acts under Windows. Could you tell me what should I do to gather debugging information such as L1 mode etc in Windows? I will send them to you then. Maybe this could help, to figure out what the bug of iwlwifi is.
> Hi, > > yesterday a friend of mine told me that one can now install Windows > 8/8.1 on a USB device natively. So I tried this so-called "Windows To Go" > technology. > > Now I have successfully deployed a Windows 8.1 installation on my external > USB HDD and booted my laptop up with it. That is to say, I can now observe > how Intel 7260 acts under Windows. > > Could you tell me what should I do to gather debugging information such as > L1 mode etc in Windows? I will send them to you then. Maybe this could > help, to figure out what the bug of iwlwifi is. http://rweverything.com/
2013/12/29 Grumbach, Emmanuel <emmanuel.grumbach@intel.com>:
> http://rweverything.com/
Here are the output of "PCI" and "PCI Index" of Intel Wireless.
> > > Here are the output of "PCI" and "PCI Index" of Intel Wireless. > > looks like all the power features are enabled... including the ones I told you to disable. I am lost now... -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2013/12/29 Emmanuel Grumbach <egrumbach@gmail.com>: > looks like all the power features are enabled... including the ones I > told you to disable. > I am lost now... Oh... That sounds bad. But I thought both Windows and Linux driver for this NIC is written by Intel?
On Sun, Dec 29, 2013 at 2:23 AM, wzyboy <wzyboy@wzyboy.org> wrote: > 2013/12/29 Grumbach, Emmanuel <emmanuel.grumbach@intel.com>: >> http://rweverything.com/ > > > Here are the output of "PCI" and "PCI Index" of Intel Wireless. ASPM must be configured on both ends of the link, so for completeness, can you also collect the "PCI" output for the bridge leading to the 7260 device? Based on the Linux lspci output, this should be 0000:00:1c.1. And I assume the device works well with the Windows driver? Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2014/1/3 Bjorn Helgaas <bhelgaas@google.com>: > ASPM must be configured on both ends of the link, so for completeness, > can you also collect the "PCI" output for the bridge leading to the > 7260 device? Based on the Linux lspci output, this should be > 0000:00:1c.1. > > And I assume the device works well with the Windows driver? Here are the "PCI" and "PCI Index" data for 0000:00:1c:1. And yes the NIC works nice in Windows.
> > ASPM must be configured on both ends of the link, so for completeness, > > can you also collect the "PCI" output for the bridge leading to the > > 7260 device? Based on the Linux lspci output, this should be > > 0000:00:1c.1. > > > > And I assume the device works well with the Windows driver? > > > Here are the "PCI" and "PCI Index" data for 0000:00:1c:1. > > And yes the NIC works nice in Windows. > Small update from the bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=64541). The bug is solved... There seem to be a hardware bug with the L1 OFF exit timer. To solve this bug we need *not* to rely on the internal clock and need to keep using the external clock. The internal clock isn't reliable enough and can lead to loss of synchronization between the bridge and the device upon L1 OFF transition. This issue has been seen in simulation and not on real hardware... until now... The windows driver has a workaround for this hardware bug, this is why the issue wasn't seen on Windows. I am porting the work around to the Linux driver. Thank you wzyboy for your patience... Then end.
2014/1/13 Grumbach, Emmanuel <emmanuel.grumbach@intel.com>: > Small update from the bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=64541). > The bug is solved... There seem to be a hardware bug with the L1 OFF exit timer. To solve this bug we need *not* to rely on the internal clock and need to keep using the external clock. The internal clock isn't reliable enough and can lead to loss of synchronization between the bridge and the device upon L1 OFF transition. > This issue has been seen in simulation and not on real hardware... until now... The windows driver has a workaround for this hardware bug, this is why the issue wasn't seen on Windows. I am porting the work around to the Linux driver. > > Thank you wzyboy for your patience... > > Then end. So this is a hardware bug instead of a driver bug? Oh... I'm glad this is finally solved since 2013-11-03. Thanks to all, providing me with wordarounds, without which I could only use wired network. :-) Cheers.
PiBIaSwNCj4gDQo+IEkgYW0gc29ycnkgYnV0IGhlcmUgaXMgYmFkIG5ld3MuDQo+IA0KPiBEdXJp bmcgcHJldmlvdXMgZGVidWdnaW5nIHByb2Nlc3MsIEkgaGF2ZSBhIG1vZGNvbmYgZmlsZQ0KPiAv ZXRjL21vZHByb2JlLmQvaXdsd2lmaS5jb25mLCBjb250YWluaW5nICJvcHRpb25zIGl3bG12bQ0K PiBwb3dlcl9zY2hlbWU9MSIuIEkgcmVtb3ZlZCBpdCBqdXN0IG5vdyAoRW1tYW51ZWwgc2F5cyBJ IGNhbiByZW1vdmUgaXQNCj4gbm93KSBhbmQgZW5jb3VudGVyZWQgKG1heWJlKSBuZXcgYnVncy4g SGVyZSBpcyB3aGF0IEkgZGlkIGp1c3Qgbm93Og0KPiANCj4gMC4gQ3VycmVudCBrZXJuZWw6IHBh dGNoZWQgd2l0aA0KPiBodHRwczovL2J1Z3ppbGxhLmtlcm5lbC5vcmcvYXR0YWNobWVudC5jZ2k/ aWQ9MTIxNjcxJmFjdGlvbj1kaWZmIDsNCj4gc2V0cGNpIHRyaWNrOiBub25lIDsgTklDIHN0YXR1 czogd29ya3MgbmljZSBhZnRlciB+MTYgaG91cnMgaGVhdnkNCj4gdXNhZ2UuDQo+IDEuIERlbGV0 ZSB0aGF0IG1vZGNvbmYgZmlsZSwgcmVib290Lg0KPiAyLiBOZXR3b3JrIGNvbm5lY3Rpb24gYmVj b21lcyBwYWluZnVsbHkgbGFnZ3kgYW5kIGxvc3N5Lg0KPiAzLiBSZS1jcmVhdGUgdGhhdCBtb2Rj b25mIGZpbGUsIHJlYm9vdC4NCj4gNC4gTmV0d29yayBjb25uZWN0aW9uIHdvcmtzIGZpbmUuDQo+ IDUuIENvbW1lbnQgb3V0IHRoYXQgbGluZSwgcmVib290Lg0KPiA2LiBOZXR3b3JrIGNvbm5lY3Rp b24gYmVjb21lcyBwYWluZnVsbHkgbGFnZ3kgYW5kIGxvc3N5Lg0KPiA3LiBVbmNvbW1lbnQgdGhh dCBsaW5lLCByZWJvb3QuDQo+IDguIE5ldHdvcmsgY29ubmVjdGlvbiB3b3JrcyBmaW5lLg0KPiAN Cj4gV2hhdCBJIG1lYW4gInBhaW5mdWxseSBsYWdneSBhbmQgbG9zc3kiIGlzIHRoYXQsIHRvIHdo b21ldmVyIEkgInBpbmciDQo+IChHb29nbGUsIDguOC44LjgsIGxvY2FsIEROUyBzZXJ2ZXIuLi4p LCB0aGUgUlRUIGlzIHJhdGhlciBoaWdoIHRoYW4NCj4gbm9ybWFsLCBhbmQgcGFja2V0IGxvc3Mg cmF0ZSBpcyBhYm92ZSA5MCUgKHNvbWUgYWRkcmVzc2VzIDEwMCUgbG9zcykuDQo+IFdoaWxlIGF0 IHRoZSBzYW1lIHRpbWUsIG90aGVyIG5ldHdvcmsgZGV2aWNlIGluIHRoZSBzYW1lIExBTiB3b3Jr cw0KPiBmaW5lLg0KPiANCj4gSSd2ZSBhdHRhY2hlZCBkbWVzZyBhbmQgbHNwY2kgb3V0cHV0IGF0 IHN0ZXAgNiBhbmQgOC4NCj4gDQoNCkFyZSB5b3Ugc3VyZSBhYm91dCBzdGVwIDEgYW5kIDU/DQpJ dCBzZWVtcyBjb21wbGV0ZWx5IHdlaXJkIHRoYXQgYW4gZXhpc3RpbmcgZmlsZSB3aXRoIGEgbGlu ZSBjb21tZW50ZWQgb3V0IGhhdmUgYW55IGltcGFjdC4NCkNhbiB5b3UgcGxlYXNlIHNlbmQgdGhl IG91dHB1dCBvZjoNCgljYXQgL3N5cy9tb2R1bGUvaXdsbXZtL3BhcmFtZXRlcnMvcG93ZXJfc2No ZW1lDQppbiBib3RoIGNhc2VzLg0KDQpBbHNvIC0gd2hhdCBjb2RlIGJhc2UgYXJlIHlvdSB1c2lu Zz8NClNpbmNlICB0aGlzIGlzIHN1cmVseSBub3QgcmVsYXRlZCB0byBQQ0ksIHBsZWFzZSByZW1v dmUgdGhlbSBpbiB5b3VyIHJlcGx5Lg0KKEkga2VlcCB0aGVtIGhlcmUgdG8gaGF2ZSB0aGVtIHNl ZSBteSBtYWlsIDopKQ0K -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c index 079a511..e8a52f3 100644 --- a/drivers/net/wireless/iwlwifi/pcie/tx.c +++ b/drivers/net/wireless/iwlwifi/pcie/tx.c @@ -707,6 +707,8 @@ void iwl_pcie_tx_start(struct iwl_trans *trans, u32 scd_base_addr) iwl_write_direct32(trans, FH_TX_CHICKEN_BITS_REG, reg_val | FH_TX_CHICKEN_BITS_SCD_AUTO_RETRY_EN); + iwl_set_bits_prph(trans, 0xa04068, 0x8); + /* Enable L1-Active */ iwl_clear_bits_prph(trans, APMG_PCIDEV_STT_REG,