| Message ID | CANUX_P1j9QNGQ2n02KpXsuMQcZo9uOsSN-zZ8yNS1e5+Y9bJOA@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| 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-wireless" 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-wireless" 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-wireless" 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.
Hi, I am sorry but here is bad news. During previous debugging process, I have a modconf file /etc/modprobe.d/iwlwifi.conf, containing "options iwlmvm power_scheme=1". I removed it just now (Emmanuel says I can remove it now) and encountered (maybe) new bugs. Here is what I did just now: 0. Current kernel: patched with https://bugzilla.kernel.org/attachment.cgi?id=121671&action=diff ; setpci trick: none ; NIC status: works nice after ~16 hours heavy usage. 1. Delete that modconf file, reboot. 2. Network connection becomes painfully laggy and lossy. 3. Re-create that modconf file, reboot. 4. Network connection works fine. 5. Comment out that line, reboot. 6. Network connection becomes painfully laggy and lossy. 7. Uncomment that line, reboot. 8. Network connection works fine. What I mean "painfully laggy and lossy" is that, to whomever I "ping" (Google, 8.8.8.8, local DNS server...), the RTT is rather high than normal, and packet loss rate is above 90% (some addresses 100% loss). While at the same time, other network device in the same LAN works fine. I've attached dmesg and lspci output at step 6 and 8.
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-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2014/1/13 Grumbach, Emmanuel <emmanuel.grumbach@intel.com>: > Are you sure about step 1 and 5? > It seems completely weird that an existing file with a line commented out have any impact. > Can you please send the output of: > cat /sys/module/iwlmvm/parameters/power_scheme > in both cases. > Hi, the point is: * With "options iwlmvm power_scheme=1" -> everything's fine * Without "options iwlmvm power_scheme=1" -> network is bad Absense of the modconf file and a modconf with only one comment line have the *same* effect - network is bad. cat /sys/module/iwlmvm/parameters/power_scheme now returns 1, and the network is good. > Also - what code base are you using? What is "code base"...? > Since this is surely not related to PCI, please remove them in your reply. > (I keep them here to have them see my mail :)) Done. :-) English is not my native language so I checked if I misuse the phrase "comment out": http://english.stackexchange.com/questions/33483/when-i-say-comment-out-does-it-mean-to-uncomment-something-or-comment-it Seems not...
PiANCj4gSGksIHRoZSBwb2ludCBpczoNCj4gDQo+ICogV2l0aCAib3B0aW9ucyBpd2xtdm0gcG93 ZXJfc2NoZW1lPTEiIC0+IGV2ZXJ5dGhpbmcncyBmaW5lDQo+ICogV2l0aG91dCAib3B0aW9ucyBp d2xtdm0gcG93ZXJfc2NoZW1lPTEiIC0+IG5ldHdvcmsgaXMgYmFkDQo+IA0KPiBBYnNlbnNlIG9m IHRoZSBtb2Rjb25mIGZpbGUgYW5kIGEgbW9kY29uZiB3aXRoIG9ubHkgb25lIGNvbW1lbnQgbGlu ZQ0KPiBoYXZlIHRoZSAqc2FtZSogZWZmZWN0IC0gbmV0d29yayBpcyBiYWQuDQo+IA0KPiBjYXQg L3N5cy9tb2R1bGUvaXdsbXZtL3BhcmFtZXRlcnMvcG93ZXJfc2NoZW1lIG5vdyByZXR1cm5zIDEs IGFuZA0KPiB0aGUgbmV0d29yayBpcyBnb29kLg0KPiANCj4gPiBBbHNvIC0gd2hhdCBjb2RlIGJh c2UgYXJlIHlvdSB1c2luZz8NCj4gDQo+IFdoYXQgaXMgImNvZGUgYmFzZSIuLi4/DQoNCldoYXQg a2VybmVsIHZlcnNpb24gOikNCklmIHlvdSB1c2UgMy4xMywgeW91IGNhbiB0cnkgYSBuZXdlciBm aXJtd2FyZS4NCg0KPiANCj4gRW5nbGlzaCBpcyBub3QgbXkgbmF0aXZlIGxhbmd1YWdlIHNvIEkg Y2hlY2tlZCBpZiBJIG1pc3VzZSB0aGUgcGhyYXNlDQo+ICJjb21tZW50IG91dCI6IGh0dHA6Ly9l bmdsaXNoLnN0YWNrZXhjaGFuZ2UuY29tL3F1ZXN0aW9ucy8zMzQ4My93aGVuLQ0KPiBpLXNheS1j b21tZW50LW91dC1kb2VzLWl0LW1lYW4tdG8tdW5jb21tZW50LXNvbWV0aGluZy1vci1jb21tZW50 LWl0DQo+IA0KPiBTZWVtcyBub3QuLi4NCg0KRW5nbGlzaCBpc24ndCBteSBtb3RoZXIgdG9uZ3Vl IGVpdGhlcjopDQoNCj4gDQo+IC0tDQo+IHd6eWJveQ0K -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2014/1/13 Grumbach, Emmanuel <emmanuel.grumbach@intel.com>: > What kernel version :) > If you use 3.13, you can try a newer firmware. > I applied your patch against Arch Linux's stock kernel 3.12.7, using this PKGBUILD: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux&id=5e2f3b10dc4be40da8f1fe355bc871d7936ec2d8 wzyboy@xenien:~$ uname -a Linux xenien.wzyboy.im 3.12.7-1-ARCH #1 SMP PREEMPT Sun Jan 12 20:38:55 CST 2014 x86_64 GNU/Linux wzyboy@xenien:~$ cat /proc/version Linux version 3.12.7-1-ARCH (wzyboy@xenien.wzyboy.im) (gcc version 4.8.2 20131219 (prerelease) (GCC) ) #1 SMP PREEMPT Sun Jan 12 20:38:55 CST 2014
> > 2014/1/13 Grumbach, Emmanuel <emmanuel.grumbach@intel.com>: > > What kernel version :) > > If you use 3.13, you can try a newer firmware. > > > > I applied your patch against Arch Linux's stock kernel 3.12.7, using this > PKGBUILD: > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD? > h=packages/linux&id=5e2f3b10dc4be40da8f1fe355bc871d7936ec2d8 > > wzyboy@xenien:~$ uname -a > Linux xenien.wzyboy.im 3.12.7-1-ARCH #1 SMP PREEMPT Sun Jan 12 > 20:38:55 CST 2014 x86_64 GNU/Linux > wzyboy@xenien:~$ cat /proc/version > Linux version 3.12.7-1-ARCH (wzyboy@xenien.wzyboy.im) (gcc version > 4.8.2 20131219 (prerelease) (GCC) ) #1 SMP PREEMPT Sun Jan 12 20:38:55 CST > 2014 > > Are you using Bluetooth at the same time? Also - it might be worth to try wireless-testing and the latest firmware. While you seem to be the first to report issues about power save on this firmware, we know that a lot of issues have been fixed in the latest firmware (-8.ucode) which is supported in 3.13 only. But if you change kernel, go for wireless-testing. Thanks. > > -- > wzyboy
2014/1/13 Grumbach, Emmanuel <emmanuel.grumbach@intel.com>: > Are you using Bluetooth at the same time? No, I disabled bluetooth in BIOS since Nov 2013. Never have used it. > Also - it might be worth to try wireless-testing and the latest firmware. > While you seem to be the first to report issues about power save on this firmware, we know that a lot of issues have been fixed in the latest firmware (-8.ucode) which is supported in 3.13 only. But if you change kernel, go for wireless-testing. > Thanks. Okay, I'll put this down and follow up when Linux 3.13 goes stable. Thanks.
[-cc linux-pci] On Mon, Jan 13, 2014 at 1:26 AM, Grumbach, Emmanuel <emmanuel.grumbach@intel.com> wrote: >> Hi, >> >> I am sorry but here is bad news. >> >> During previous debugging process, I have a modconf file >> /etc/modprobe.d/iwlwifi.conf, containing "options iwlmvm >> power_scheme=1". I removed it just now (Emmanuel says I can remove it >> now) and encountered (maybe) new bugs. Here is what I did just now: >> >> 0. Current kernel: patched with >> https://bugzilla.kernel.org/attachment.cgi?id=121671&action=diff ; >> setpci trick: none ; NIC status: works nice after ~16 hours heavy >> usage. >> 1. Delete that modconf file, reboot. >> 2. Network connection becomes painfully laggy and lossy. >> 3. Re-create that modconf file, reboot. >> 4. Network connection works fine. >> 5. Comment out that line, reboot. >> 6. Network connection becomes painfully laggy and lossy. >> 7. Uncomment that line, reboot. >> 8. Network connection works fine. >> >> What I mean "painfully laggy and lossy" is that, to whomever I "ping" >> (Google, 8.8.8.8, local DNS server...), the RTT is rather high than >> normal, and packet loss rate is above 90% (some addresses 100% loss). >> While at the same time, other network device in the same LAN works >> fine. >> >> I've attached dmesg and lspci output at step 6 and 8. >> > > Are you sure about step 1 and 5? > It seems completely weird that an existing file with a line commented out have any impact. It doesn't seem strange to me; maybe we're interpreting wzyboy's data differently. The way I read it, if /etc/modprobe.d/iwlwifi.conf contains "options iwlmvm power_scheme=1", everything works fine (cases 0, 4, 8). If iwlwifi.conf does not exist or contains only a commented-out line, he sees problems (cases 2, 6). > Can you please send the output of: > cat /sys/module/iwlmvm/parameters/power_scheme > in both cases. > > Also - what code base are you using? > Since this is surely not related to PCI, please remove them in your reply. > (I keep them here to have them see my mail :)) Agreed, this doesn't sound PCI-related, so I removed linux-pci. Feel free to keep me or add me back if you do see anything PCI-related. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2014/1/14 Bjorn Helgaas <bhelgaas@google.com>: > It doesn't seem strange to me; maybe we're interpreting wzyboy's data > differently. The way I read it, if /etc/modprobe.d/iwlwifi.conf > contains "options iwlmvm power_scheme=1", everything works fine (cases > 0, 4, 8). If iwlwifi.conf does not exist or contains only a > commented-out line, he sees problems (cases 2, 6). > Yes, Bjorn got my point :-) With "options iwlmvm power_scheme=1" -> network is good Without "options iwlmvm power_scheme=1" -> network is bad Currently I am using Linux 3.12.7 with Emmanuel's patch, and without any setpci tricks. Emmanuel says a new firmware is available in 3.13 so I will follow up when 3.13 is released in my distro's repo.
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,