Re: systemd-rfkill regression on 5.11 and later kernels
Hi, On Thu, Mar 18, 2021 at 10:31 AM Takashi Iwai wrote: > > Hi, > > we've received a bug report about rfkill change that was introduced in > 5.11. While the systemd-rfkill expects the same size of both read and > write, the kernel rfkill write cuts off to the old 8 bytes while read > gives 9 bytes, hence it leads the error: > https://github.com/systemd/systemd/issues/18677 > https://bugzilla.opensuse.org/show_bug.cgi?id=1183147 If you use an old kernel that expects only 8 bytes and you write 9, then yes, the kernel will read only 8. If you use a new kernel (5.11) and you send 9 bytes, the kernel will read all the 9 bytes, so I am not sure I understand the problem here. If you have a new header file that makes you send 9 bytes, then, in order to run against an old kernel (which seems to have been the case with the report in github), then you must be ready to have the kernel read less than 9 bytes. What am I missing? > > As far as I understand from the log in the commit 14486c82612a, this > sounds like the intended behavior. But if this was implemented in > that way just for the compatibility reason, it actually is worse, > introducing a regression. > > Although this can be addressed easily in the systemd side, the current > kernel behavior needs reconsideration, IMO. > > > thanks, > > Takashi
Re: [BUG] iwlwifi: card unusable after firmware crash
Hi, > Hi, again, > > I haven't tested any patch or bisected, but I have another data point. > I built and tested Linux 5.8.18, with the same firmware, and it is > working correctly. I reduced the test case to just rfkilling the > connection, which showed the register dump immediately (before that I > was using the airplane toggle on the keyboard, which isn't working > correctly, it disables and immediately reenables the radio, for some > unfathomable reason). > So, now I'm inclined to believe this is some sort of race condition > between rfkill and pending transactions. Which also means it's not a regression. You can add a dump_stack() in the function that dumps the registers to get a clue.
Re: [BUG] iwlwifi: card unusable after firmware crash
On Wed, Dec 9, 2020 at 10:47 PM Emmanuel Grumbach wrote:
>
> On Wed, Dec 9, 2020 at 10:40 PM Rui Salvaterra wrote:
> >
> > Hi, Emmanuel,
> >
> > On Wed, 9 Dec 2020 at 20:32, Emmanuel Grumbach wrote:
> > >
> > > Rui, I looked at the register dump and looks like you're using AMT on
> > > your system?
> > > Can you confirm?
> >
> > AMT? You mean Intel Active Management? Heavens, no, not that I know
> > of! This is a personal laptop (Lenovo B51-80). (And I'd personally
> > kill the ME with fire, if I could.)
>
> Yes, I mean that thing. No VPRO sticker on the laptop?
> Weird... So apparently I was wrong about the register value.
Indeed, the bit is reverse logic. So we can put that aside.
Frankly, I have no clue. You can try our backport tree to bisect,
should be easier..
What I see here is that your GP_CTRL value is 080003d8
#define CSR_GP_CNTRL_REG_FLAG_HW_RF_KILL_SW (0x0800)
which means sense since apparently, HW RF-Kill was asserted.
#define CSR_GP_CNTRL_REG_FLAG_GOING_TO_SLEEP (0x0010)
Which means that the device is going to sleep... And that's the problem:
iwl_trans_pcie_grab_nic_access:
ret = iwl_poll_bit(trans, CSR_GP_CNTRL,
CSR_GP_CNTRL_REG_VAL_MAC_ACCESS_EN,
(CSR_GP_CNTRL_REG_FLAG_MAC_CLOCK_READY |
CSR_GP_CNTRL_REG_FLAG_GOING_TO_SLEEP), 15000);
if (unlikely(ret < 0)) {
u32 cntrl = iwl_read32(trans, CSR_GP_CNTRL);
WARN_ONCE(1,
"Timeout waiting for hardware access
(CSR_GP_CNTRL 0x%08x)\n",
cntrl);
but I'd expect the splat in your log...
Or maybe you can't load the firmware?
Can you try this:
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 2fffbbc8462f..748300752630 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -2121,6 +2121,7 @@ static bool
iwl_trans_pcie_grab_nic_access(struct iwl_trans *trans,
* track nic_access anyway.
*/
__release(&trans_pcie->reg_lock);
+ mdelay(1);
return true;
}
If that helps, then... I'd have no clue why it helps, but this
specific device caused us trouble like bad timing after
grab_nic_access..
>
> >
> > Thanks,
> > Rui
Re: [BUG] iwlwifi: card unusable after firmware crash
On Wed, Dec 9, 2020 at 10:40 PM Rui Salvaterra wrote: > > Hi, Emmanuel, > > On Wed, 9 Dec 2020 at 20:32, Emmanuel Grumbach wrote: > > > > Rui, I looked at the register dump and looks like you're using AMT on > > your system? > > Can you confirm? > > AMT? You mean Intel Active Management? Heavens, no, not that I know > of! This is a personal laptop (Lenovo B51-80). (And I'd personally > kill the ME with fire, if I could.) Yes, I mean that thing. No VPRO sticker on the laptop? Weird... So apparently I was wrong about the register value. > > Thanks, > Rui
Re: [BUG] iwlwifi: card unusable after firmware crash
On Wed, Dec 9, 2020 at 10:32 PM Emmanuel Grumbach wrote: > > On Wed, Dec 9, 2020 at 7:19 PM Jakub Kicinski wrote: > > > > On Tue, 8 Dec 2020 23:17:48 + Rui Salvaterra wrote: > > > Hi, Luca, > > > > > > On Tue, 8 Dec 2020 at 16:27, Coelho, Luciano > > > wrote: > > > > On Tue, 2020-12-08 at 11:27 +, Rui Salvaterra wrote: > > > > > > > > > > [ 3174.003910] iwlwifi :02:00.0: RF_KILL bit toggled to disable > > > > > radio. > > > > > [ 3174.003913] iwlwifi :02:00.0: reporting RF_KILL (radio > > > > > disabled) > > > > > > > > It looks like your machine is reporting RF-Kill to the WiFi device. > > > > > > Yes, that's an artifact of how I tested: I rebooted the router, the > > > Wi-Fi interface disassociated and the dmesg was clean. However, after > > > the router came up, the laptop didn't reconnect (and the connection > > > had completely disappeared from nmtui). Afterwards, I did the rfkill > > > cycle you see, and only then I got the register dump. > > > > > > > There seems to be some sort of race there that is causing us to still > > > > try to communicate with the device (and thus you see the transaction > > > > failed dump), but that will obviously fail when RF-Kill is enabled. > > > > > > I'm not sure about that, the card was already dead before the rfkill > > > cycle. > > > > Any luck figuring this out, Luca? If this is a 5.10 regression we need > > to let Linus know tomorrow, so the time is ticking :( > > Rui, I looked at the register dump and looks like you're using AMT on > your system? > Can you confirm? Besides, don't you get a stack dump in the vicinity of this register dump? That's be helpful to see.
Re: [BUG] iwlwifi: card unusable after firmware crash
On Wed, Dec 9, 2020 at 7:19 PM Jakub Kicinski wrote: > > On Tue, 8 Dec 2020 23:17:48 + Rui Salvaterra wrote: > > Hi, Luca, > > > > On Tue, 8 Dec 2020 at 16:27, Coelho, Luciano > > wrote: > > > On Tue, 2020-12-08 at 11:27 +, Rui Salvaterra wrote: > > > > > > > > [ 3174.003910] iwlwifi :02:00.0: RF_KILL bit toggled to disable > > > > radio. > > > > [ 3174.003913] iwlwifi :02:00.0: reporting RF_KILL (radio disabled) > > > > > > It looks like your machine is reporting RF-Kill to the WiFi device. > > > > Yes, that's an artifact of how I tested: I rebooted the router, the > > Wi-Fi interface disassociated and the dmesg was clean. However, after > > the router came up, the laptop didn't reconnect (and the connection > > had completely disappeared from nmtui). Afterwards, I did the rfkill > > cycle you see, and only then I got the register dump. > > > > > There seems to be some sort of race there that is causing us to still > > > try to communicate with the device (and thus you see the transaction > > > failed dump), but that will obviously fail when RF-Kill is enabled. > > > > I'm not sure about that, the card was already dead before the rfkill cycle. > > Any luck figuring this out, Luca? If this is a 5.10 regression we need > to let Linus know tomorrow, so the time is ticking :( Rui, I looked at the register dump and looks like you're using AMT on your system? Can you confirm?
Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed()
>
> On Tue, May 19, 2020 at 10:37 PM Emmanuel Grumbach
> wrote:
> > So I believe we already have this uevent, it is the devcoredump. All
> > we need is to add the unique id.
>
> I think there are a few reasons that devcoredump doesn't satisfy what
> either Luis or I want.
>
> 1) it can be disabled entirely [1], for good reasons (e.g., think of
> non-${CHIP_VENDOR} folks, who can't (and don't want to) do anything
> with the opaque dumps provided by closed-source firmware)
Ok, if all you're interested into is the information that this event
happen (as opposed to report a bug and providing the data), then I
agree. True, not everybody want or can enable devcoredump. I am just a
bit concerned that we may end up with two interface that notify the
same event basically. The ideal maybe would be to be able to
optionally reduce the content of the devoredump to nothing more that
is already in the dmesg output. But then, it is not what it is meant
to be: namely, a core dump..
> 2) not all drivers necessarily have a useful dump to provide when
> there's a crash; look at the rest of Luis's series to see the kinds of
> drivers-with-firmware that are crashing, some of which aren't dumping
> anything
Fair enouh.
> 3) for those that do support devcoredump, it may be used for purposes
> that are not "crashes" -- e.g., some provide debugfs or other knobs to
> initiate dumps, for diagnostic or debugging purposes
Not sure I really think we need to care about those cases, but you
already have 2 good arguments :)
>
> Brian
>
> [1] devcd_disabled
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/devcoredump.c?h=v5.6#n22
Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed()
Hi all, Since I have been involved quite a bit in the firmware debugging features in iwlwifi, I think I can give a few insights here. But before this, we need to understand that there are several sources of issues: 1) the firmware may crash but the bus is still alive, you can still use the bus to get the crash data 2) the bus is dead, when that happens, the firmware might even be in a good condition, but since the bus is dead, you stop getting any information about the firmware, and then, at some point, you get to the conclusion that the firmware is dead. You can't get the crash data that resides on the other side of the bus (you may have gathered data in the DRAM directly, but that's a different thing), and you don't have much recovery to do besides re-starting the PCI enumeration. At Intel, we have seen both unfortunately. The bus issues are the ones that are trickier obviously. Trickier to detect (because you just get garbage from any request you issue on the bus), and trickier to handle. One can argue that the kernel should *not* handle those and let this in userspace hands. I guess it all depends on what component you ship to your customer and what you customer asks from you :). > > Hi Luis, > > On Tue, May 19, 2020 at 7:02 AM Luis Chamberlain wrote: > > On Mon, May 18, 2020 at 06:23:33PM -0700, Brian Norris wrote: > > > On Sat, May 16, 2020 at 6:51 AM Johannes Berg > > > wrote: > > > > In addition, look what we have in iwl_trans_pcie_removal_wk(). If we > > > > detect that the device is really wedged enough that the only way we can > > > > still try to recover is by completely unbinding the driver from it, then > > > > we give userspace a uevent for that. I don't remember exactly how and > > > > where that gets used (ChromeOS) though, but it'd be nice to have that > > > > sort of thing as part of the infrastructure, in a sort of two-level > > > > notification? > > > > > > > > > We use this on certain devices where we know the underlying hardware > > > has design issues that may lead to device failure > > > > Ah, after reading below I see you meant for iwlwifi. > > Sorry, I was replying to Johannes, who I believe had his "we"="Intel" > hat (as iwlwifi maintainer) on, and was pointing at > iwl_trans_pcie_removal_wk(). > This pcie_removal thing is for the bus dead thing. My 2) above. > > If userspace can indeed grow to support this, that would be fantastic. > > Well, Chrome OS tailors its user space a bit more to the hardware (and > kernel/drivers in use) than the average distro might. We already do > this (for some values of "this") today. Is that "fantastic" to you? :D I guess it can be fantastic if other vendors also suffer from this. Or maybe that could be done as part of the PCI bus driver inside the kernel? > > > > -- then when we see > > > this sort of unrecoverable "firmware-death", we remove the > > > device[*]+driver, force-reset the PCI device (SBR), and try to > > > reload/reattach the driver. This all happens by way of a udev rule. > > > > So you've sprikled your own udev event here as part of your kernel delta? > > No kernel delta -- the event is there already: > iwl_trans_pcie_removal_wk() > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/intel/iwlwifi/pcie/trans.c?h=v5.6#n2027 > > And you can see our udev rules and scripts, in all their ugly details > here, if you really care: > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/net-wireless/iwlwifi_rescan/files/ > > > > We > > > also log this sort of stuff (and metrics around it) for bug reports > > > and health statistics, since we really hope to not see this happen > > > often. > > > > Assuming perfection is ideal but silly. So, what infrastructure do you > > use for this sort of issue? > > We don't yet log firmware crashes generally, but for all our current > crash reports (including WARN()), they go through this: > https://chromium.googlesource.com/chromiumos/platform2/+/master/crash-reporter/README.md > > For example, look for "cut here" in: > https://chromium.googlesource.com/chromiumos/platform2/+/master/crash-reporter/anomaly_detector.cc > > For other specific metrics (like counting "EVENT=INACCESSIBLE"), we > use the Chrome UMA system: > https://chromium.googlesource.com/chromiumos/platform2/+/master/metrics/README.md > > I don't imagine the "infrastructure" side of any of that would be > useful to you, but maybe the client-side gathering can at least show > you what we do. > > > > [*] "We" (user space) don't actually do this...it happens via the > > > 'remove_when_gone' module parameter abomination found in iwlwifi. > > > > BTW is this likely a place on iwlwifi where the firmware likely crashed? > > iwl_trans_pcie_removal_wk() is triggered because HW accesses timed out > in a way that is likely due to a dead PCIe endpoint. It's not directly > a firmware crash, although there may be firmware crashes reported > around the same time. iwl
Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
Hello, > > > > > > > > our hardware teams from the Bluetooth and WiFi side really need to look > > > > at this. > > > > Were you able to get attention from the hardware teams with the logs > > I've provided? Are there any news or an idea of when / if we can > > expect this to be fixed in firmware? If not, do you have suggestions > > for an alternative solution? > > > > Sorry to bother you again with this, but I'd really like to figure out > some way forward here. Did you get any feedback from the hardware > teams? Otherwise, I understand having an inter-dependency between the > wifi and bt kernel modules is not desirable, so do you have any > suggestion on how to solve this without adding this dependency? > Have you tried the update the BT firmware with what is now available in mainline linux-firmware.git? I heard that this problem has now been resolved. After you update the BT firmware, you need a full power cycle.
Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important
On Mon, Jun 12, 2017 at 12:30 AM, Emil Lenngren wrote: > 2017-06-11 22:48 GMT+02:00 Emmanuel Grumbach : >> On Sun, Jun 11, 2017 at 4:36 PM, Kees Cook wrote: >>> >>> On Sun, Jun 11, 2017 at 1:13 AM, Kalle Valo wrote: >>> > "Jason A. Donenfeld" writes: >>> > >>> >> Whenever you're comparing two MACs, it's important to do this using >>> >> crypto_memneq instead of memcmp. With memcmp, you leak timing >>> >> information, >>> >> which could then be used to iteratively forge a MAC. >>> > >>> > Do you have any pointers where I could learn more about this? >>> >>> While not using C specifically, this talks about the problem generally: >>> https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html >>> >> >> Sorry for the stupid question, but the MAC address is in plaintext in >> the air anyway or easily accessible via user space tools. I fail to >> see what it is so secret about a MAC address in that code where that >> same MAC address is accessible via myriads of ways. > > I think you're mixing up Media Access Control (MAC) addresses with > Message Authentication Code (MAC). The second one is a cryptographic > signature of a message. Obviously... Sorry for the noise.
Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important
On Sun, Jun 11, 2017 at 4:36 PM, Kees Cook wrote: > > On Sun, Jun 11, 2017 at 1:13 AM, Kalle Valo wrote: > > "Jason A. Donenfeld" writes: > > > >> Whenever you're comparing two MACs, it's important to do this using > >> crypto_memneq instead of memcmp. With memcmp, you leak timing information, > >> which could then be used to iteratively forge a MAC. > > > > Do you have any pointers where I could learn more about this? > > While not using C specifically, this talks about the problem generally: > https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html > Sorry for the stupid question, but the MAC address is in plaintext in the air anyway or easily accessible via user space tools. I fail to see what it is so secret about a MAC address in that code where that same MAC address is accessible via myriads of ways.
Re: Intel Wireless 7260 failed to work
On Wed, Dec 28, 2016 at 10:10 AM, Peter Xu wrote: > On Wed, Dec 28, 2016 at 09:27:15AM +0200, Luca Coelho wrote: > > [...] > >> > > > Is this a known issue? Please let me know if anyone wants more info or >> > > > logs, since this error triggers easily (everytime I boot). >> > > >> > > The error message isn't really telling much to the user (hint hint) but >> > > I suspect this is by design: >> > > >> > > "iwlwifi: remove support for fw older than -17 and -22 >> >> Right, we only maintain support for a certain number of firmware >> versions. The FW APIs change with time and we don't want to keep all >> legacy code supporting old firmwares in the driver forever. >> >> I agree that "no suitable firmware found!" is a bit scarce. I'll see >> if we can improve that with something: "no suitable firmware found! You >> need iwlwifi-7260-17.ucode ()". > > That'll be great if we can have this info in the log. Maybe no need > for a full URL, the firmware name would suffice at least for me. In this case, I think we should also print the range that is supported when we fail to find any suitable firmware. > > [...] > >> I don't think we are very aggressive, we have been supporting -17 since >> v4.3: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5865f3658ba37c54e346b0fdee08a1c7a152681b >> >> And we have published the firmware about half a year ago: >> >> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/iwlwifi-7260-17.ucode?id=f2cf4d67e8eced29c8a473d3a27057aa2df57c42 >> >> I understand your concern, but if you want to be on the bleeding-edge >> kernel, you should be on the bleeding-edge linux-firmware as well. ;) > > Fair enough. :-) > >> >> But as I said, I'll try to improve the error message, as that should >> make it easier to figure out. > > Thank you! > > -- peterx
Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava wrote:
>
> Didn't get any feedback or review comments on this patch. Resending ...
>
> P.
This change is obviously completely broken. It simply disables the
registration to thermal zone core.
>
> ---8<---
>
> The iwlwifi driver implements a thermal zone and hwmon device, but
> returns -EIO on temperature reads if the firmware isn't loaded. This
> results in the error
>
> iwlwifi-virtual-0
> Adapter: Virtual device
> ERROR: Can't get value of subfeature temp1_input: I/O error
> temp1:N/A
>
> being output when using sensors from the lm-sensors package. Since
> the temperature cannot be read unless the ucode is loaded there is no
> reason to add the interface only to have it return an error 100% of
> the time.
>
> This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
> stops the thermal zone from being created if the ucode hasn't been loaded.
>
> Signed-off-by: Prarit Bhargava
> Cc: Johannes Berg
> Cc: Emmanuel Grumbach
> Cc: Luca Coelho
> Cc: Intel Linux Wireless
> Cc: Kalle Valo
> Cc: Chaya Rachel Ivgi
> Cc: Sara Sharon
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> index 58fc7b3c711c..64802659711f 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> @@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct
> thermal_zone_device *device,
>
> mutex_lock(&mvm->mutex);
>
> - if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
> - ret = -EIO;
> - goto out;
> - }
> -
> ret = iwl_mvm_get_temp(mvm, &temp);
> if (ret)
> goto out;
> @@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct
> thermal_zone_device *device,
>
> mutex_lock(&mvm->mutex);
>
> - if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
> - ret = -EIO;
> - goto out;
> - }
> -
> if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
> ret = -EINVAL;
> goto out;
> @@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm
> *mvm)
> return;
> }
>
> + if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
> + return;
> +
> BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
>
> mvm->tz_device.tzone = thermal_zone_device_register(name,
> --
> 1.7.9.3
>
> --
> 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
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
Re: [PATCH] wlcore: spi: add wl18xx support
On Wed, Mar 30, 2016 at 3:58 PM, Eyal Reizer wrote:
>
> From: Eyal
Are you trying to hide or something? :)
>
> Add support for using with both wl12xx and wl18xx.
>
> - all wilink family needs special init command for entering wspi mode.
> extra clock cycles should be sent after the spi init command while the
> cs pin is high.
> - switch to controling the cs pin from the spi driver for achieveing the
> above.
> - the selected cs gpio is read from the spi device-tree node using the
> cs-gpios field and setup as a gpio.
> - See the example below for specifying the cs gpio using the cs-gpios entry
>
> &spi0 {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&spi0_pins>;
> cs-gpios = <&gpio0 5 0>;
> #address-cells = <1>;
> #size-cells = <0>;
> wlcore: wlcore@0 {
> compatible = "ti,wl1835";
> vwlan-supply = <&wlan_en_reg>;
> spi-max-frequency = <4800>;
> reg = <0>; /* chip select 0 on spi0, ie spi0.0 */
> interrupt-parent = <&gpio0>;
> interrupts = <27 IRQ_TYPE_EDGE_RISING>;
> };
> };
>
> Signed-off-by: Eyal Reizer
> ---
> drivers/net/wireless/ti/wlcore/spi.c | 176
> ++
> 1 file changed, 157 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/spi.c
> b/drivers/net/wireless/ti/wlcore/spi.c
> index 96d9c9d..6c5a369 100644
> --- a/drivers/net/wireless/ti/wlcore/spi.c
> +++ b/drivers/net/wireless/ti/wlcore/spi.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include "wlcore.h"
> #include "wl12xx_80211.h"
> @@ -70,16 +71,30 @@
> #define WSPI_MAX_CHUNK_SIZE4092
>
> /*
> - * only support SPI for 12xx - this code should be reworked when 18xx
> - * support is introduced
> + * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
> + * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
> */
> -#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
> +#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
>
> /* Maximum number of SPI write chunks */
> #define WSPI_MAX_NUM_OF_CHUNKS \
> ((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
>
>
> +struct wilink_familiy_data {
> + char name[8];
> +};
> +
> +const struct wilink_familiy_data *wilink_data;
> +
> +static const struct wilink_familiy_data wl18xx_data = {
> + .name = "wl18xx",
> +};
> +
> +static const struct wilink_familiy_data wl12xx_data = {
> + .name = "wl12xx",
> +};
> +
> struct wl12xx_spi_glue {
> struct device *dev;
> struct platform_device *core;
> @@ -120,6 +135,8 @@ static void wl12xx_spi_init(struct device *child)
> struct spi_transfer t;
> struct spi_message m;
> u8 *cmd = kzalloc(WSPI_INIT_CMD_LEN, GFP_KERNEL);
> + struct spi_device *spi = (struct spi_device *)glue->dev;
> + struct spi_master *master = spi->master;
>
> if (!cmd) {
> dev_err(child->parent,
> @@ -127,6 +144,15 @@ static void wl12xx_spi_init(struct device *child)
> return;
> }
>
> + if (!master->cs_gpios) {
> + dev_err(child->parent,
> + "spi chip select pin missing in platform data!\n");
> + return;
> + }
> +
> + /* Drive CS line low */
> + gpio_direction_output(master->cs_gpios[0], 0);
> +
> memset(&t, 0, sizeof(t));
> spi_message_init(&m);
>
> @@ -163,6 +189,26 @@ static void wl12xx_spi_init(struct device *child)
> spi_message_add_tail(&t, &m);
>
> spi_sync(to_spi_device(glue->dev), &m);
> +
> + /* Send extra clocks with CS high. this is required by the wilink
> +* family in order for successfully enter WSPI mode
> +*/
> + gpio_direction_output(master->cs_gpios[0], 1);
> +
> + memset(&m, 0, sizeof(m));
> + spi_message_init(&m);
> +
> + cmd[0] = 0xff;
> + cmd[1] = 0xff;
> + cmd[2] = 0xff;
> + cmd[3] = 0xff;
> + swab32s((u32 *)cmd);
> +
> + t.tx_buf = cmd;
> + t.len = 4;
> + spi_message_add_tail(&t, &m);
> + spi_sync(to_spi_device(glue->dev), &m);
> +
> kfree(cmd);
> }
>
> @@ -213,6 +259,16 @@ static int __must_check wl12xx_spi_raw_read(struct
> device *child, int addr,
> u32 *busy_buf;
> u32 *cmd;
> u32 chunk_len;
> + struct spi_device *spi = (struct spi_device *)glue->dev;
> + struct spi_master *master = spi->master;
> +
> + if (!master->cs_gpios) {
> + dev_err(child->parent,
> + "spi chip select pin missing in platform data!\n");
> + return -EINVAL;
> + }
> + /* Drive CS line low */
> + gpio_direction_output(master->cs_gpios[0], 0);
>
> while (len > 0) {
> chunk_len = min_t(size_t, WSPI_MAX_CHUNK_SIZE, len);
>
Re: iwlwifi A-MSDU tx
On Fri, Dec 4, 2015 at 9:35 AM, Emmanuel Grumbach wrote: > Hi, > > On Fri, Dec 4, 2015 at 12:05 AM, Stefan Sperling wrote: >> Hi Emmanuel, >> >> As part of implementing 802.11n support in OpenBSD I'm looking for >> an AP which sends A-MSDUs. Preferrably under software control rather >> than firmware. >> >> I found your iwlwifi A-MSDU patches at >> http://marc.info/?l=linux-wireless&m=144553311122495&w=2 >> and http://marc.info/?l=linux-wireless&m=144553311822496&w=2 >> >> Would these patches make it possible to run an AP with an 5300 or 7260 >> card and send A-MSDUs? That would be great as I have the necessary hardware. > > 7260 will go. Not 5300. > Note that this code simulates Tx TCP Csum offload. I did that to write > the code while we still don't have the hardware that has this > capability. But for testing purposes, it should do the work. The > testing teams have reported that AP mode didn't work quite well with > this and I haven't taken the time to look into yet, but if you see > issues, please report them or even better: fix them :) > >> >> Which Linux tree do these patches apply to? I've tried the following >> but had no luck in getting these patches applied without rejects: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git >> > > Right. These patches had a long internal review cycle. They are now > merge in our internal tree. > You can find them in our internal tree [1] (backport based). I will > push them soon in iwlwifi-next.git. I forgot to mention that you need to change the define of IWL_MVM_SW_TX_CSUM_OFFLOAD to 1. > > [1] - > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/ > Please read > https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release#how_to_install_the_driver. > >> Thanks, >> Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi A-MSDU tx
Hi, On Fri, Dec 4, 2015 at 12:05 AM, Stefan Sperling wrote: > Hi Emmanuel, > > As part of implementing 802.11n support in OpenBSD I'm looking for > an AP which sends A-MSDUs. Preferrably under software control rather > than firmware. > > I found your iwlwifi A-MSDU patches at > http://marc.info/?l=linux-wireless&m=144553311122495&w=2 > and http://marc.info/?l=linux-wireless&m=144553311822496&w=2 > > Would these patches make it possible to run an AP with an 5300 or 7260 > card and send A-MSDUs? That would be great as I have the necessary hardware. 7260 will go. Not 5300. Note that this code simulates Tx TCP Csum offload. I did that to write the code while we still don't have the hardware that has this capability. But for testing purposes, it should do the work. The testing teams have reported that AP mode didn't work quite well with this and I haven't taken the time to look into yet, but if you see issues, please report them or even better: fix them :) > > Which Linux tree do these patches apply to? I've tried the following > but had no luck in getting these patches applied without rejects: > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > Right. These patches had a long internal review cycle. They are now merge in our internal tree. You can find them in our internal tree [1] (backport based). I will push them soon in iwlwifi-next.git. [1] - https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/ Please read https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release#how_to_install_the_driver. > Thanks, > Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 10/27] iwlwifi: move under intel vendor directory
Hi Kalle, On Wed, Nov 18, 2015 at 4:45 PM, Kalle Valo wrote: > > Part of reorganising wireless drivers directory and Kconfig. > I am sorry but I'd prefer to wait with this. We have a big machinery of scripts / builds and alike that will break. I did give a heads up a while ago to the people in charge of these scripts that this change is on the way, but they are not done yet. I will get back to them and ask them when we can be ready for such a change and then it'll come from my tree. I promise to try to make it happen ASAP. The above is relevant for iwlwifi only. As far as I am concerned, you can move the iwlwifi and ipw. Thank you. > Signed-off-by: Kalle Valo > --- > MAINTAINERS|2 +- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: Deinline iwl_{read,write}{8,32}
> > > > I'll try to come up with a patch that is easier for me to read, but I > > am really busy right now. Ping me in a week if you have heard from me > > earlier. > > So how it is going with this patch? > > In hindsight, I would use a different name for the macro parameter here: > > #define IWL_READ_WRITE(static_inline) \ > +static_inline void iwl_write8(...) > > "static_inline" proved to be confusing. > Maybe perform s/static_inline/func_qualifier/ on the patch... > In the end, I un-inlined these functions unconditionally. It won't make it for 4.3 though. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously
On Thu, Jul 30, 2015 at 8:18 AM, Fu, Zhonghui wrote: > Enable wiphy device to suspend/resume asynchronously. This can improve > system suspend/resume speed. > How will that impact the timing with respect to the suspend call coming from the bus? I think that a few drivers rely on the suspend call of the wiphy device happening before the suspend call to the bus device. Not sure though. > Signed-off-by: Zhonghui Fu > --- > net/wireless/core.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/net/wireless/core.c b/net/wireless/core.c > index 2a0bbd2..bc5e68f 100644 > --- a/net/wireless/core.c > +++ b/net/wireless/core.c > @@ -416,6 +416,7 @@ use_default_name: > device_initialize(&rdev->wiphy.dev); > rdev->wiphy.dev.class = &ieee80211_class; > rdev->wiphy.dev.platform_data = rdev; > + device_enable_async_suspend(&rdev->wiphy.dev); > > INIT_LIST_HEAD(&rdev->destroy_list); > spin_lock_init(&rdev->destroy_list_lock); > -- 1.7.1 > > -- > 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi: Microcode SW error detected. Restarting 0x2000000.
Emmanuel Grumbach egrumb...@gmail.com On Fri, Jul 17, 2015 at 5:06 PM, Toralf Förster wrote: > On 07/14/2015 08:43 AM, Emmanuel Grumbach wrote: >> You are not using the latest firmware. Please upgrade to 25.17.12.0. > > At least with this firmware the issue is self-healing after a short while - I > do not need to restart the interface. > Thanks for the feedback. > FWIW it worked flawlessly since Dec last year so far - no software upgrade at > the fritz box nor any hardware change. > So the current kernel uncovered then an (existing hidden ?) issue, right ? The current kernel might just be loading a newer firmware that has a regression. It may very well be a regression in iwlwifi (kernel or firmware). What you can try is to use an older firmware. kernel 4.0 can still load -9.ucode and up. So you can just try to downgrade the firmware. Please use: ethtool -i wlan0 to check the version of the firmware. Don't rely on the information in modinfo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi: Microcode SW error detected. Restarting 0x2000000.
On Wed, Jul 15, 2015 at 10:20 PM, Toralf Förster wrote: > On 07/15/2015 07:48 PM, Emmanuel Grumbach wrote: >> Can you reproduce easily? >> > Unfortunately not, it happens sometimes gtwice a day, and then I do have 5 or > more daays in a row w/o any problems. > >> What bandwidth are you using? 20Mhz or 40Mhz? > 20 MHz accordingly to my Fritz!Box 7360 display. > Fritz!Box - oh well. We've had lots of issues with this kind of APs. There is already an open bug: https://bugzilla.kernel.org/show_bug.cgi?id=97291 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: Deinline iwl_{read,write}{8,32}
On Tue, Jul 14, 2015 at 3:41 PM, Denys Vlasenko
wrote:
> On Tue, Jul 14, 2015 at 2:38 PM, Sergei Shtylyov
> wrote:
>>> +#define IWL_READ_WRITE(static_inline) \
>>> +static_inline void iwl_write8(struct iwl_trans *trans, u32 ofs, u8 val) \
>>> +{ \
>>> + trace_iwlwifi_dev_iowrite8(trans->dev, ofs, val); \
>>> + iwl_trans_write8(trans, ofs, val); \
>>> +} \
>> [...]
>>>
>>> +#if !defined(CONFIG_IWLWIFI_DEVICE_TRACING)
>>> +IWL_READ_WRITE(static inline)
>>
>>Not static_inline?
>
> Yes. Here we are putting two words, "static inline", in front of every
> function definition.
> --
I'll try to come up with a patch that is easier for me to read, but I
am really busy right now. Ping me in a week if you have heard from me
earlier.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi: Microcode SW error detected. Restarting 0x2000000.
>> >> On Tue, Jul 14, 2015 at 12:53 AM, Toralf Förster >> wrote: >>> At a Gentoo (hardened) I experienced - starting with hardened kernel >>> 4.0.6-r1 - the (attached) hickup of the "03:00.0 Network controller: Intel >>> Corporation Wireless 7260 (rev 83)" at a ThinkPad T440s. The network stucks >>> till I do restart the network device using /etc/init.d/net.wlp3s0. >> >> You are not using the latest firmware. Please upgrade to 25.17.12.0. >> You'll be able to find the firmware here: >> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-7260-12.ucode >> > > With the mentioned firmware and 4.0.8 I get now repaetingly (restart of the > servcie helped): > Ouch. The stack doesn't make much sense, but it seems that you are still suffering from the stuck queue. The WARNING itself (Timeout waiting for hardware access) is interesting. Can you reproduce easily? What bandwidth are you using? 20Mhz or 40Mhz? > > > Jul 15 15:21:32 t44 kernel: ieee80211 phy0: Hardware restart was requested > Jul 15 15:21:34 t44 kernel: [ cut here ] > Jul 15 15:21:34 t44 kernel: WARNING: CPU: 0 PID: 0 at > drivers/net/wireless/iwlwifi/pcie/trans.c:1385 > iwl_trans_pcie_grab_nic_access+0x14b/0x160 [iwlwifi]() > Jul 15 15:21:34 t44 kernel: Timeout waiting for hardware access (CSR_GP_CNTRL > 0x080003d8) > Jul 15 15:21:34 t44 kernel: Modules linked in: nf_conntrack_ipv6 > nf_defrag_ipv6 ip6table_filter ip6_tables ipt_MASQUERADE > nf_nat_masquerade_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit ipt_REJECT > nf_reject_ipv4 xt_recent xt_tcpudp xt_conntrack iptable_raw iptable_nat > nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack > iptable_filter ip_tables x_tables nfsd auth_rpcgss oid_registry lockd grace > ctr ccm sunrpc af_packet bridge stp llc tun rc_dib0700_rc5 hid_cherry > dib7000p hid_generic usbhid hid dvb_usb_dib0700 dib3000mc dvb_usb dvb_core > dib0070 dib7000m dibx000_common dib0090 rc_core usblp snd_hda_codec_generic > arc4 rtsx_pci_sdmmc mmc_core evdev x86_pkg_temp_thermal coretemp kvm_intel > kvm iwlmvm aesni_intel aes_x86_64 glue_helper mac80211 lrw gf128mul > ablk_helper cryptd psmouse iwlwifi pcspkr atkbd > Jul 15 15:21:34 t44 kernel: i2c_i801 i915 cfg80211 cfbfillrect rtsx_pci > cfbimgblt fbcon bitblit thermal i2c_algo_bit softcursor font cfbcopyarea wmi > drm_kms_helper snd_hda_intel snd_hda_controller snd_hda_codec drm snd_pcm > i2c_core thinkpad_acpi intel_gtt snd_timer nvram battery agpgart rfkill ac > tpm_tis tpm xhci_pci ehci_pci xhci_hcd ehci_hcd video lpc_ich mfd_core fb > button fbdev usbcore snd processor e1000e thermal_sys usb_common soundcore > hwmon [last unloaded: microcode] > Jul 15 15:21:34 t44 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 4.0.8-hardened #1 > Jul 15 15:21:34 t44 kernel: Hardware name: LENOVO 20AQCTO1WW/20AQCTO1WW, BIOS > GJET83WW (2.33 ) 03/09/2015 > Jul 15 15:21:34 t44 kernel: 810dc4c6 > c05ca3a8 88033e203c58 > Jul 15 15:21:34 t44 kernel: 8159675c > 88033e203ca8 88033e203c98 > Jul 15 15:21:34 t44 kernel: 81059fea c05c8c18 > c05ca3a8 0569 > Jul 15 15:21:34 t44 kernel: Call Trace: > Jul 15 15:21:34 t44 kernel:[] ? > print_modules+0x76/0xe0 > Jul 15 15:21:34 t44 kernel: [] ? > iwl8000_base_params+0x1c68/0x299b [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] dump_stack+0x45/0x5d > Jul 15 15:21:34 t44 kernel: [] > warn_slowpath_common+0x8a/0xd0 > Jul 15 15:21:34 t44 kernel: [] ? > iwl8000_base_params+0x4d8/0x299b [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] ? > iwl8000_base_params+0x1c68/0x299b [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] ? > iwl8000_base_params+0x1eb8/0x299b [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] ? > iwl_trans_pcie_write32+0x40/0x40 [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] warn_slowpath_fmt+0x5a/0x70 > Jul 15 15:21:34 t44 kernel: [] ? > iwl8000_base_params+0x1eb8/0x299b [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] ? iwl_poll_bit+0x45/0x90 > [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] > iwl_trans_pcie_grab_nic_access+0x14b/0x160 [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] iwl_read_direct32+0x37/0x80 > [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] > iwl_pcie_txq_stuck_timer+0x138/0x3e0 [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] ? > iwl_pcie_alloc_dma_ptr.isra.23+0x110/0x110 [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] call_timer_fn+0x47/0x140 > Jul 15 15:21:34 t44 kernel: [] > run_timer_softirq+0x291/0x450 > Jul 15 15:21:34 t44 kernel: [] ? > iwl_pcie_alloc_dma_ptr.isra.23+0x110/0x110 [iwlwifi] > Jul 15 15:21:34 t44 kernel: [] __do_softirq+0xf8/0x290 > Jul 15 15:21:34 t44 kernel: [] irq_exit+0xa5/0xb0 > Jul 15 15:21:34 t44 kernel: [] > smp_apic_timer_interrupt+0x55/0x70 > Jul 15 15:21:34 t44 kernel: [] > apic_timer_interrupt+0x83/0x90 > Jul 15 15:21:34 t44 kernel:[] ? > __hrtimer_start_range_ns+0x1a5/0x3d0 > Jul 15 15:21:34 t44
Re: iwlwifi: Microcode SW error detected. Restarting 0x2000000.
Hi, On Tue, Jul 14, 2015 at 12:53 AM, Toralf Förster wrote: > At a Gentoo (hardened) I experienced - starting with hardened kernel 4.0.6-r1 > - the (attached) hickup of the "03:00.0 Network controller: Intel Corporation > Wireless 7260 (rev 83)" at a ThinkPad T440s. The network stucks till I do > restart the network device using /etc/init.d/net.wlp3s0. You are not using the latest firmware. Please upgrade to 25.17.12.0. You'll be able to find the firmware here: https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-7260-12.ucode Note that users reported an improvement with -13.ucode, but you'll need 4.1 to use that firmware. The issue you are facing can be caused by a lot of factor and hence it is hard to know if the newer versions will fix your problem, but it is worth trying. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mac80211: Use kstrdup to simplify code
The subject is wrong. You are not patch mac80211, but bcrmsmac. On Wed, Jul 8, 2015 at 10:32 PM, Christophe JAILLET wrote: > Replace a kmalloc+strcpy by an equivalent kstrdup in order to improve > readability. > > Signed-off-by: Christophe JAILLET > --- > drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c > b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c > index 4813506..8a6c077 100644 > --- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c > +++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c > @@ -1476,9 +1476,7 @@ struct brcms_timer *brcms_init_timer(struct brcms_info > *wl, > wl->timers = t; > > #ifdef DEBUG > - t->name = kmalloc(strlen(name) + 1, GFP_ATOMIC); > - if (t->name) > - strcpy(t->name, name); > + t->name = kstrdup(name, GFP_ATOMIC); > #endif > > return t; > -- > 2.1.4 > > -- > 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: Move each system tracepoints to their own header
it's me again. On Mon, Apr 13, 2015 at 9:22 AM, Emmanuel Grumbach wrote: > On Sun, Apr 12, 2015 at 8:37 PM, Emmanuel Grumbach > wrote: >> On Wed, Apr 8, 2015 at 10:44 AM, Johannes Berg >> wrote: >>> On Tue, 2015-04-07 at 12:13 -0400, Steven Rostedt wrote: >>>> Every tracing file must have its own TRACE_SYSTEM defined. >>>> The iwlwifi tracepoint header broke this and added in the middle >>>> of the file: >>> [...] >>>> Unfortunately, this broke new code in the ftrace infrastructure. >>>> Moving each of these TRACE_SYSTEMs into their own trace file with >>>> just one TRACE_SYSTEM per file fixes the issue. >>>> >>>> Cc: Johannes Berg >>>> Signed-off-by: Steven Rostedt >>> >>> >>>> drivers/net/wireless/iwlwifi/iwl-devtrace-data.h | 79 >>>> drivers/net/wireless/iwlwifi/iwl-devtrace-io.h | 155 >>>> .../net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h| 200 ++ >>>> drivers/net/wireless/iwlwifi/iwl-devtrace-msg.h| 97 + >>>> drivers/net/wireless/iwlwifi/iwl-devtrace-ucode.h | 81 >>>> drivers/net/wireless/iwlwifi/iwl-devtrace.h| 438 >>>> + >>>> 6 files changed, 618 insertions(+), 432 deletions(-) >>>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-data.h >>>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-io.h >>>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h >>>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-msg.h >>>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-ucode.h >>> >>> Looks good to me. >>> >>> Reviewed-by: Johannes Berg >>> >> >> I had to make quite a few modifications since this patch was not based >> on iwlwifi-next, but I picked it up in our internal tree. > > Wait - you seemed to want to apply that on your tree because of > dependencies (which I can understand). So how do you suggest to > proceed? > You can apply your original version of the patch on your tree, but > then it'll collapse when it'll meet iwlwifi-next.git. > I can try to have the modified version of the patch into 4.1 but I > doubt I'll make it. If I do make it, it'd allow you to work on top of > 4.1 whenever that'll be ready? What is your timeline? > I overthought it. Stephen fixed the conflict correctly. > Or maybe you can pull iwlwifi-next (which would be odd I have to say)? > What do you suggest? > FWIW - I am talking about: > > commit 7e1223b50089ab5901215d2fd8c61b42c7cfe034 > Author: Emmanuel Grumbach > Date: Tue Feb 3 20:11:48 2015 +0200 > > iwlwifi: mvm: new Alive / error table API > > The new API slightly changes the layout of the version of > the firmware - prepare for that. > > Signed-off-by: Emmanuel Grumbach -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: Move each system tracepoints to their own header
On Sun, Apr 12, 2015 at 8:37 PM, Emmanuel Grumbach wrote: > On Wed, Apr 8, 2015 at 10:44 AM, Johannes Berg > wrote: >> On Tue, 2015-04-07 at 12:13 -0400, Steven Rostedt wrote: >>> Every tracing file must have its own TRACE_SYSTEM defined. >>> The iwlwifi tracepoint header broke this and added in the middle >>> of the file: >> [...] >>> Unfortunately, this broke new code in the ftrace infrastructure. >>> Moving each of these TRACE_SYSTEMs into their own trace file with >>> just one TRACE_SYSTEM per file fixes the issue. >>> >>> Cc: Johannes Berg >>> Signed-off-by: Steven Rostedt >> >> >>> drivers/net/wireless/iwlwifi/iwl-devtrace-data.h | 79 >>> drivers/net/wireless/iwlwifi/iwl-devtrace-io.h | 155 >>> .../net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h| 200 ++ >>> drivers/net/wireless/iwlwifi/iwl-devtrace-msg.h| 97 + >>> drivers/net/wireless/iwlwifi/iwl-devtrace-ucode.h | 81 >>> drivers/net/wireless/iwlwifi/iwl-devtrace.h| 438 >>> + >>> 6 files changed, 618 insertions(+), 432 deletions(-) >>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-data.h >>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-io.h >>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h >>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-msg.h >>> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-ucode.h >> >> Looks good to me. >> >> Reviewed-by: Johannes Berg >> > > I had to make quite a few modifications since this patch was not based > on iwlwifi-next, but I picked it up in our internal tree. Wait - you seemed to want to apply that on your tree because of dependencies (which I can understand). So how do you suggest to proceed? You can apply your original version of the patch on your tree, but then it'll collapse when it'll meet iwlwifi-next.git. I can try to have the modified version of the patch into 4.1 but I doubt I'll make it. If I do make it, it'd allow you to work on top of 4.1 whenever that'll be ready? What is your timeline? Or maybe you can pull iwlwifi-next (which would be odd I have to say)? What do you suggest? FWIW - I am talking about: commit 7e1223b50089ab5901215d2fd8c61b42c7cfe034 Author: Emmanuel Grumbach Date: Tue Feb 3 20:11:48 2015 +0200 iwlwifi: mvm: new Alive / error table API The new API slightly changes the layout of the version of the firmware - prepare for that. Signed-off-by: Emmanuel Grumbach -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: Move each system tracepoints to their own header
On Wed, Apr 8, 2015 at 10:44 AM, Johannes Berg wrote: > On Tue, 2015-04-07 at 12:13 -0400, Steven Rostedt wrote: >> Every tracing file must have its own TRACE_SYSTEM defined. >> The iwlwifi tracepoint header broke this and added in the middle >> of the file: > [...] >> Unfortunately, this broke new code in the ftrace infrastructure. >> Moving each of these TRACE_SYSTEMs into their own trace file with >> just one TRACE_SYSTEM per file fixes the issue. >> >> Cc: Johannes Berg >> Signed-off-by: Steven Rostedt > > >> drivers/net/wireless/iwlwifi/iwl-devtrace-data.h | 79 >> drivers/net/wireless/iwlwifi/iwl-devtrace-io.h | 155 >> .../net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h| 200 ++ >> drivers/net/wireless/iwlwifi/iwl-devtrace-msg.h| 97 + >> drivers/net/wireless/iwlwifi/iwl-devtrace-ucode.h | 81 >> drivers/net/wireless/iwlwifi/iwl-devtrace.h| 438 >> + >> 6 files changed, 618 insertions(+), 432 deletions(-) >> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-data.h >> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-io.h >> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h >> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-msg.h >> create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-ucode.h > > Looks good to me. > > Reviewed-by: Johannes Berg > I had to make quite a few modifications since this patch was not based on iwlwifi-next, but I picked it up in our internal tree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Mar 5 (iwlwifi/mvm)
On Fri, Mar 6, 2015 at 1:41 AM, Randy Dunlap wrote: > On 03/04/15 19:34, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20150304: >> > > on i386, when IWLWIFI_DEBUGFS is not enabled: > > > ../drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c:179:38: error: 'struct > iwl_mvm' has no member named 'dbgfs_rx_phyinfo' > ../drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c:1378:30: error: 'struct > iwl_mvm_vif' has no member named 'mvm' > > Yes - I am sorry about that. I'll fix it on Sunday. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: mvm: check time event is over before disconnecting
On Sat, Feb 28, 2015 at 1:10 AM, Filip Ayazi wrote:
> On the 7260 time event was often ended before end_time and connections failed
> with "No association and the time event is over already...".
> This checks that the time event is actually over before disconnecting.
>
> Signed-off-by: Filip Ayazi
While this patch is wrong I'd like to know if it helps.
The patch is wrong because even if the driver thinks the time event
should still be running, if the firmware indicates it has already
ended, we should still disconnect. The reason for the disconnection is
that we can't be sure that the firmware will have the proper timing
for the beacon and hence for the DTIM. Both are critical to get a
decent behavior while saving power.
In any case, I doubt this patch does actually something because the
firmware and the driver should really be close in their timings. If
they aren't, it is fundamental bug in the firmware. While the firmware
does have bugs just like any piece of software, I doubt it has such
big ones :)
> ---
> drivers/net/wireless/iwlwifi/mvm/time-event.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/mvm/time-event.c
> b/drivers/net/wireless/iwlwifi/mvm/time-event.c
> index 54fafbf..b0aa892 100644
> --- a/drivers/net/wireless/iwlwifi/mvm/time-event.c
> +++ b/drivers/net/wireless/iwlwifi/mvm/time-event.c
> @@ -256,7 +256,8 @@ static void iwl_mvm_te_handle_notif(struct iwl_mvm *mvm,
> }
> }
>
> - if (le32_to_cpu(notif->action) & TE_V2_NOTIF_HOST_EVENT_END) {
> + if (le32_to_cpu(notif->action) & TE_V2_NOTIF_HOST_EVENT_END &&
> + time_after(jiffies, te_data->end_jiffies)) {
> IWL_DEBUG_TE(mvm,
> "TE ended - current time %lu, estimated end
> %lu\n",
> jiffies, te_data->end_jiffies);
> --
> 1.9.1
>
> --
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iwlwifi-driver card doesn't work with 3.19-rc2+
On Tue, Dec 30, 2014 at 3:33 PM, Jiri Kosina wrote: > > Hi, > > I just booted current Linus' tree (5faa0154fe33) on my x200s thinkpad, and > wifi doesn't work. iwconfig is telling me that wlan0 interface has no > wireless extensions. > So why do you used them? They have been deprecated for a couple of years now. You should be using nl80211 based tools such as iw. > Previous kernel that is known to work on this machine is 3.18-rc5. I can > do a bisect if needed, but wanted to ask in case this is a known problem. > 3.19 is the first kernel that actually removed the wireless extensions. > Please find the relevant part of dmesg below. The card in question is > this: > > 03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 5100 AGN > [Shiloh] Network Connection [8086:4237] > Subsystem: Intel Corporation WiFi Link 5100 AGN [8086:1211] > Flags: bus master, fast devsel, latency 0, IRQ 29 > Memory at f250 (64-bit, non-prefetchable) [size=8K] > Capabilities: [c8] Power Management version 3 > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [e0] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Device Serial Number 00-22-fa-ff-ff-34-b0-4c > Kernel driver in use: iwlwifi > Kernel modules: iwlwifi > > > > === snip === > [6.357092] Intel(R) Wireless WiFi driver for Linux, in-tree:d > [6.358637] Copyright(c) 2003- 2014 Intel Corporation > [6.387473] iwlwifi :03:00.0: loaded firmware version 8.83.5.1 build > 33692 op_mode iwldvm > [6.399552] e1000e :00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) > 00:1f:16:15:7a:65 > [6.401162] e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection > [6.402751] e1000e :00:19.0 eth0: MAC: 7, PHY: 8, PBA No: 1008FF-0FF > [6.404838] i801_smbus :00:1f.3: SMBus using PCI interrupt > [6.407182] ACPI Warning: SystemIO range > 0x1028-0x102f conflicts with OpRegion > 0x1000-0x107f (\_SB_.PCI0.LPC_.PMIO) > (20141107/utaddress-258) > [6.410662] ACPI: If an ACPI driver is available for this device, you > should use it instead of the native driver > [6.412580] ACPI Warning: SystemIO range > 0x11b0-0x11bf conflicts with OpRegion > 0x1180-0x11ff (\_SB_.PCI0.LPC_.LPIO) > (20141107/utaddress-258) > [6.416296] ACPI: If an ACPI driver is available for this device, you > should use it instead of the native driver > [6.418145] ACPI Warning: SystemIO range > 0x1180-0x11af conflicts with OpRegion > 0x1180-0x11ff (\_SB_.PCI0.LPC_.LPIO) > (20141107/utaddress-258) > [6.422111] ACPI: If an ACPI driver is available for this device, you > should use it instead of the native driver > [6.424214] lpc_ich: Resource conflict(s) found affecting gpio_ich > [6.432054] microcode: CPU0 sig=0x10676, pf=0x80, revision=0x60c > [6.440414] microcode: CPU0 sig=0x10676, pf=0x80, revision=0x60c > [6.444012] microcode: CPU0 updated to revision 0x60f, date = 2010-09-29 > [6.451926] microcode: CPU1 sig=0x10676, pf=0x80, revision=0x60c > [6.479540] thinkpad_acpi: ThinkPad ACPI Extras v0.25 > [6.481632] thinkpad_acpi: http://ibm-acpi.sf.net/ > [6.483636] thinkpad_acpi: ThinkPad BIOS 6DET38WW (2.02 ), EC 7XHT21WW-1.03 > [6.485724] thinkpad_acpi: Lenovo ThinkPad X200s, model 7470BN2 > [6.513239] microcode: CPU1 sig=0x10676, pf=0x80, revision=0x60c > [6.516007] microcode: CPU1 updated to revision 0x60f, date = 2010-09-29 > [6.525254] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > [6.557365] thinkpad_acpi: detected a 16-level brightness capable ThinkPad > [6.561203] thinkpad_acpi: radio switch found; radios are enabled > [6.563537] thinkpad_acpi: This ThinkPad has standard ACPI backlight > brightness control, supported by the ACPI video driver > [6.565722] thinkpad_acpi: Disabling thinkpad-acpi brightness events by > default... > [6.582468] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is > blocked > [6.613516] thinkpad_acpi: Standard ACPI backlight interface available, > not loading native one > [6.628357] input: ThinkPad Extra Buttons as > /devices/platform/thinkpad_acpi/input/input8 > [6.830228] sound hdaudioC0D0: CX20561 (Hermosa): BIOS auto-probing. > [6.835254] sound hdaudioC0D0: autoconfig: line_outs=1 > (0x1a/0x0/0x0/0x0/0x0) type:speaker > [6.837530] sound hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) > [6.839860] sound hdaudioC0D0:hp_outs=2 (0x19/0x16/0x0/0x0/0x0) > [6.842102] sound hdaudioC0D0:mono: mono_out=0x0 > [6.844365] sound hdaudioC0D0:dig-out=0x1c/0x0 > [6.846498] sound hdaudioC0D0:inputs: > [6.848629] sound hdaudioC0D0: Mic=0x18 > [6.850637] sound hdaudioC0D0:
Re: [patch] iwlwifi: cleanup a mask shift in iwlagn_bt_traffic_is_sco()
On Wed, Oct 29, 2014 at 6:08 PM, Dan Carpenter wrote: > The shift operation is higher precedence so the code is wrong and it > sets of a static checker warning. But it doesn't affect real life > because BT_UART_MSG_FRAME3SCOESCO_POS is zero so the shift is a no-op. > > I have re-written it in normal style and with parenthesis as a cleanup > and to silence the static checker warning. > > Signed-off-by: Dan Carpenter > In my tree already - I got it from Joe. https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-next.git/commit/?id=50f6635afe565a0e1c5ab78f040294fe1dc41de0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: iwlwifi 2014-03-19
Hi John, This fixes the build failure faced by Stephen: drivers/net/wireless/iwlwifi/mvm/debugfs.c: In function 'iwl_dbgfs_fw_error_dump_release': drivers/net/wireless/iwlwifi/mvm/debugfs.c:161:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] vfree(file->private_data); ^ Please pull. The following changes since commit a82dda6cd492b8c88952be6f6527f3656f7ac585: iwlwifi: mvm: disable uAPSD due to bugs in the firmware (2014-03-18 21:15:42 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git for-john for you to fetch changes up to 192c80a2499cf2571924081c646262036d841484: iwlwifi: mvm: add missing include (2014-03-19 08:25:05 +0200) ---- Emmanuel Grumbach (1): iwlwifi: mvm: add missing include drivers/net/wireless/iwlwifi/mvm/debugfs.c | 2 ++ 1 file changed, 2 insertions(+) signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/11] use ether_addr_equal_64bits
On Tue, Dec 31, 2013 at 1:13 AM, Johannes Berg
wrote:
>
> On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
> > On Mon, 30 Dec 2013, Johannes Berg wrote:
> > > On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > > > > Is there any way we could catch (sparse, or some other script?) that
> > > > > struct reorganising won't break the condition needed ("within a
> > > > > structure that contains at least two more bytes")?
> > > >
> > > > What kind of reorganizing could happen? Do you mean that the programmer
> > > > might do at some time in the future, or something the compiler might do?
> > >
> > > I'm just thinking of a programmer, e.g. changing a struct like this:
> > >
> > > struct foo {
> > >u8 addr[ETH_ALEN];
> > > - u16 dummy;
> > > };
> > >
> > > for example.
> >
> > That is easily resolved by:
> >
> > struct foo {
> > u8 addr[ETH_ALEN];
> > u16 required_padding; /* do not remove upon pain of death */
> > };
>
> That'd be a stupid waste of struct space. If anything, there should be
> *only* a comment saying that at least two bytes are needed - I'd still
> prefer an automated check.
>
Frankly I am not sure I like the patch. This flow is not a fast path
at all. While I don't really care for the waste in iwlwifi (because
there isn't), I don't see the real point is make the code more
sensitive to changes to earn basically nothing.
This flow happens only upon association which means a few times an hour maybe...
The only advantage I see here is that people like me who don't always
have a chance to read / write much code outside their little tiny
boring driver get to know about this kind of things. So, from an
educational point of view - this is cool.
But education is one thing, and the code is another.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2.1] net: wireless: iwlwifi: remove minor dead code
On 11/12/2013 02:01 AM, Michal Nazarewicz wrote: > inta is checked to be zero in a IRQ_NONE branch so afterwards it > cannot be zero as it is never modified. > > Signed-off-by: Michal Nazarewicz > --- > drivers/net/wireless/iwlwifi/pcie/rx.c | 24 +--- > 1 file changed, 9 insertions(+), 15 deletions(-) > > On Mon, Nov 11 2013, Johannes Berg wrote: >> no signed-off-by > > Sorry, fixed. Interestingly, I did not forget about it in my first patch. > no worries - I picked it up in our internal tree. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3.9.x stable regression, bisected] iwlwifi/iwldvm has a 30s delay in EAP authentication
>> >> Thanks for the bisection. Can you please try the patch in >> https://bugzilla.kernel.org/show_bug.cgi?id=58341 and report? >> Thanks >> > > I can confirm that the patch in this bugzilla entry does indeed get > rid of the delay in EAP authentication. > Thanks for the testing - patch on the way to upstream / stable -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3.9.x stable regression, bisected] iwlwifi/iwldvm has a 30s delay in EAP authentication
On Tue, May 21, 2013 at 5:09 PM, Kshitij Kulshreshtha wrote: > Hello, > > I am currently running the openSUSE Tumbleweed distribution and have a > problem starting with the kernel v3.9.1 and also with kernel v3.9.2. > > The iwldvm driver has an artificial delay of 30s when authenticating > with a radius server using EAP-TLS. This was not the case using kernel > v3.9. > > I bisected the problem using local builds of the tumbleweed desktop > configuration. This is the result: > > c30f37f8f1f8d06c142d67ba74955fd48b5cf5a4 is the first bad commit > commit c30f37f8f1f8d06c142d67ba74955fd48b5cf5a4 > Author: Emmanuel Grumbach > Date: Wed Apr 17 09:47:00 2013 +0300 > > iwlwifi: dvm: don't send zeroed LQ cmd > > commit 63b77bf489881747c5118476918cc8c29378ee63 upstream. > > When the stations are being restored because of unassoc > RXON, the LQ cmd may not have been initialized because it > is initialized only after association. > Sending zeroed LQ_CMD makes the fw unhappy: it raises > SYSASSERT_2078. > > Signed-off-by: Emmanuel Grumbach > Reviewed-by: Johannes Berg > [move zero_lq and make static const] > Signed-off-by: Johannes Berg > Signed-off-by: Greg Kroah-Hartman > Thanks for the bisection. Can you please try the patch in https://bugzilla.kernel.org/show_bug.cgi?id=58341 and report? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is L1 really disabled in iwlwifi
> > I couldn't imagine that silently ignoring the request to disable ASPM > would be the right thing, but I spent a long time experimenting with > Windows on qemu, and I think you're right. Windows 7 also seems to > ignore the "PciASPMOptOut" directive when we don't have permission > to manage ASPM. All the gory details are at > https://bugzilla.kernel.org/show_bug.cgi?id=57331 > > The current behavior is definitely confusing. I hate to rename or change > pci_disable_link_state() because it's exported and we'd have to maintain > the old interface for a while anyway. And I don't really want to return > failure to drivers, because I think that would encourage people to fiddle > with the Link Control register directly in the driver, which doesn't seem > like a good idea. > > And you're also right that (as far as I know) there's not an actual > problem with the current behavior other than the confusion it causes. > > So, how about something like the following patch, which just prints a > warning when we can't do what the driver requested? I suppose this may > also be a nuisance, because users will be worried, but they can't actually > *do* anything about it. Maybe it should be dev_info() instead. > Good for me - now I would be notified that something wrong happened. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bisected 3.9 regression for iwl4965 connection problem to 1672c0e3
>> > > But if so, I would also see >> > > the breakage on my setup, but I don't - it works quite well here. >> > >> > Are you testing on a passive channel? Try with a large beacon interval. >> >> I think most likely what happens is that it's on a passive channel, and >> the firmware drops the TX packet with a bad status. Before the patch, >> we'd just wait sitting on the channel for HZ/5 (200ms) before trying >> again, with the patch we immediately retransmit the packet, which will >> fail again and again until the firmware received a beacon. >> >> If you look at iwlwifi/dvm/, it has some passive_no_rx workaround for >> this, which I don't see in iwlegacy. > > Can you explain why it is named passive_no_rx instead passive_no_tx ? Well, it is basically - passive channel with no rx :-) This means we can't tx. >> I think the best way to solve this would be to do such a thing in >> iwlegacy as well, but until then and for stable maybe we should >> introduce another HW flag to restore the previous mac80211 behaviour? > > I'm not sure if I like to add passive_no_rx to iwlegacy. Stopping queues > and waiting for beacon looks sticky, what happen if beacon will not be > received? > > Perhaps I will just remove IEEE80211_HW_REPORTS_TX_ACK_STATUS from 4965, > it's simpler workaround ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
