On Fri, Jan 26, 2018 at 11:55 PM, Dan Williams wrote:
>
> Here's another spin of the spectre-v1 mitigations for 4.16.
I see nothing really objectionable here.
And unlike Spectre-v2 and Meltdown, I expect Spectre-v1 to be with us
for a long time. It's not a "CPU did a
On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck wrote:
>
> Here there isn't any reason for speculation. The core has the
> value of 'x' in a register and the upper bound encoded into the
> "cmp" instruction. Both are right there, no waiting, no speculation.
So this is an
On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams wrote:
>
> This series incorporates Mark Rutland's latest ARM changes and adds
> the x86 specific implementation of 'ifence_array_ptr'. That ifence
> based approach is provided as an opt-in fallback, but the default
>
On Wed, Nov 8, 2017 at 9:19 PM, Fengguang Wu wrote:
>
> Yes it's accessing the list. Here is the faddr2line output.
Ok, so it's a corrupted timer list. Which is not a big surprise.
It's
next->pprev = pprev;
in __hlist_del(), and the trapping instruction
On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu wrote:
>
> Here are 3 dmesgs related to wireless and 1 from ethernet.
Fengguang, these would be lovelier still _if_ you have DEBUG_INFO
enabled on the kernel, and your script were to find things like
"symbol+0xhex/0xhex", and
On Fri, Sep 15, 2017 at 12:43 PM, Luca Coelho <l...@coelho.fi> wrote:
> On Fri, 2017-09-15 at 12:38 -0700, Linus Torvalds wrote:
>>
>> From some of the context it looks like commit 40f11adc7cd9 ("PCI:
>> Avoid race while enabling upstream bridges"), is
On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe wrote:
>>
>> In any case, your patch introduces a regression on systems. Please get
>> it reverted now, and then you can come up with a new approach to fix the
>> double enable of the upstream bridge.
>
> Who's sending in the revert? I
On Thu, Sep 7, 2017 at 5:39 AM, Kalle Valo wrote:
>
> Linus, do you want to apply this directly or should we take it via the
> normal route (wireless-drivers -> net)? If your prefer the latter when
> I'm planning to submit this to Dave in a day or two and expecting it to
>
On Wed, Sep 6, 2017 at 10:40 PM, Luca Coelho wrote:
>
> This patch is not very important (unless you really like blinking lights
> -- maybe I'll change my mind when the holidays approach :P). so it is
> fine if you just want to revert it for now.
>
> In any case, I'll send a patch
On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
wrote:
>
> This seems to be a problem with backwards-compatibility with FW version
> 27. We are now in version 31[1] and upgrading will probably fix that.
I can confirm that fw version 31 works.
> But obviously the
On Wed, Sep 6, 2017 at 4:27 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
>
> iwlwifi :3a:00.0: loaded firmware version 27.455470.0 op_mode iw
This pull request completely breaks Intel wireless for me.
This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
That remains a very standard Intel machine with absolutely zero odd
things going on.
The firmware is iwlwifi-8000C-28.ucode from
On Fri, Jul 7, 2017 at 1:09 PM, Arend van Spriel
<arend.vanspr...@broadcom.com> wrote:
> Now I signed off on the patch although formally I suppose Linus should
> sign it off.
You can certainly consider it
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
but I
On Fri, Jul 7, 2017 at 6:17 AM, Johannes Berg wrote:
>
> Linus, since you were involved already, will you apply this directly?
I don't think it's _that_ urgent, since it's specific to one
particular driver anyway. I'd suggest just going through the normal
channels, and
On Thu, Jul 6, 2017 at 10:11 AM, Arend van Spriel
wrote:
>
> Looks fine to me so ...
I really think that if we can't trust 'len', then we have to check
against the lower bound of DOT11_MGMT_HDR_LEN too, because otherwise
we'll just have a big 16-bit number instead.
On Thu, May 4, 2017 at 8:22 AM, David Miller wrote:
> From: Johannes Berg
>>
>> I figured I'd give Linus to a chance to try or even apply it, but I
>> have no objection to you applying it either. I don't have anything else
>> yet right now, and
So my Dell XPS 13 seems to have grown a new warning as of the
networking merge yesterday.
Things still work, but when it starts warning, it generates a *lot* of
noise (I got 36 of these within about ten minutes).
I have no idea what triggered it, because when I rebooted (not because
of this
On Tue, Feb 21, 2017 at 10:18 AM, David Miller wrote:
>
> Kalle I really wanted to send my net-next pull request to Linus later
> today. But I guess I have to wait for this ath10k first.
Feel free to send it to me - it sounds like the regression is
(a) easy to work around
On Thu, Aug 18, 2016 at 10:11 AM, Jakub Kicinski
wrote:
> Hi!
>
> This is what I came up with. Changes:
I can live with this, certainly. I'm not really sure how many drivers
(or perhaps core code, for that matter) will actually start using it,
but it at least
On Wed, Aug 17, 2016 at 10:11 AM, Jakub Kicinski
<jakub.kicin...@netronome.com> wrote:
> On Wed, 17 Aug 2016 09:33:26 -0700, Linus Torvalds wrote:
>>
>> I'm not a huge fan, since the interface fundamentally seems to be
>> oddly designed (why pass in the mask rather
On Wed, Aug 17, 2016 at 3:31 AM, Kalle Valo wrote:
>
> Are people ok with this? I think they are useful and I can take these
> through my tree, but I would prefer to get an ack from other maintainers
> first. Dave? Andrew?
I'm not a huge fan, since the interface
On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann wrote:
>
> This patch changes all users of IS_ERR_VALUE() that I could find
> on 32-bit ARM randconfig builds and x86 allmodconfig. For the
> moment, this doesn't change the definition of IS_ERR_VALUE()
> because there are probably
On Fri, May 27, 2016 at 2:46 PM, Andrew Morton
wrote:
>
> So you do plan to add some sort of typechecking into IS_ERR_VALUE()?
The easiest way to do it is to just turn the (x) into (unsigned
long)(void *)(x), which then complains about casting an integer to a
pointer
On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote:
>
> It would be best if you could send a patch either directly to Dave or
> Linus to resolve this quickly.
I'm committing my patch myself right now, since this bug makes my
laptop useless, and I will take credit for
On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
>
> From what I can tell, there's a merge bug in commit 909b27f70643,
> where David seems to have lost some of the changes to
> iwl_mvm_set_tx_cmd().
>
> I do not know if that's the reas
On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
wrote:
>
> I can confirm that 4.6 contains the same bug. And reverting the patch
> I mentioned does solve the problem...
>
> The same patch works fine in our internal tree. I'll have to figure
> out together with
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
So I upgraded the firmware on my Intel NUC (NUC6i3SYK), and that made
the wireless no longer work with a 4.5 kernel. I could get the
occasional packets through, but not many, and ti would hang for ten
seconds at a time, and then output errors like
iwlwifi :01:00.0: Queue 2 stuck for 1
On Wed, Mar 16, 2016 at 2:13 PM, Grumbach, Emmanuel
wrote:
>
> This ... typically means that the firmware got stuck while sending
> packets. Can you tell me on what band your router operates? 2.4GHz or
> 5.2GHz?
Both.
> Do you use 20Mhz or 40MHz?
HT20 on 2.4GHz,
On Fri, Jan 29, 2016 at 9:54 AM, Larry Finger wrote:
>
> The test patch that Johannes sent earlier was close. The section needed to
> add VHT rates is:
Hmm. This looks pretty much exactly like what I already tried (I had
fixed Johannes' patch to use "vht_cap" already,
On Thu, Jan 28, 2016 at 4:13 AM, Johannes Berg
<johan...@sipsolutions.net> wrote:
> On Wed, 2016-01-27 at 21:34 -0800, Linus Torvalds wrote:
>
>> .. except now I upgraded the nearest access point, and now wireless
>> on that machine no longer works.
>
> Can you d
On Thu, Jan 28, 2016 at 2:12 PM, Johannes Berg
wrote:
>
> Your best workaround may just be to ignore VHT for now - clearly it's
> broken so using "just" HT (which is likely not that much of a penalty
> anyway since you're apparently not using 80 MHz) will be much
On Thu, Jan 28, 2016 at 1:44 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
>
> I will try Johannes' suggestion on that machine to see if it makes a
> difference
Well, it "makes a difference" in the sense that the warning goes away.
But it doesn't make thing
that this is not a new issue. Or at least
I seem to find reports that look very much like this from over a year
ago.
Linus
On Thu, Jan 28, 2016 at 12:40 PM, Johannes Berg
<johan...@sipsolutions.net> wrote:
> On Thu, 2016-01-28 at 11:01 -0800, Linus Torvalds wrote:
>>
&g
On Thu, Jan 28, 2016 at 5:54 PM, Larry Finger wrote:
>
> I have been running an RTL8821AE since kernel 3.18 without hitting this
> problem using a TRENDnet AC1750 dual-band AP. The UniFi may be doing
> something that the driver is not expecting.
I've had issues with
Hmm. So my daughter has a little Gigabyte Brix that has rtl8821ae
wireless in it. Yeah, nasty, I know, but it has actually worked
reasonably well.
.. except now I upgraded the nearest access point, and now wireless on
that machine no longer works.
Or rather, it actually *does* work in the sense
Johannes,
On Thu, Feb 26, 2015 at 5:50 AM, Jouni Malinen jo...@qca.qualcomm.com wrote:
Reported-by: Linus Torvalds torva...@linux-foundation.org
Also Tested-by:, and I'd suggest marking it for stable too (although
I understand that David generally doesn't use stable tags, and just
sends them
On Wed, Feb 25, 2015 at 6:47 AM, Jouni Malinen j...@w1.fi wrote:
There may be something else wrong (say, some kind of interference), but
there is no way we can assume normal users to be able to fix such
issues. If we make EAPOL frames go through more robustly, the connection
can be
On Wed, Feb 25, 2015 at 10:14 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
I'm talking about the two from Jouni - the don't encrypt EAPOL
frames one, and the one-liner that makes all EAPOL frames go at the
lowest data rate.
So I just found out and confirmed that this is not Atheros
On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen j...@w1.fi wrote:
mac80211: Do not encrypt EAPOL frames before peer has used the key
Hmm. This patch does not seem to make a difference. I thought it did
at first, but then removed the wpa_supplicant debugging, and got the
same failures.
On Sun,
On Mon, Feb 23, 2015 at 12:06 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
This machine has a fairly minimal kernel config. Does that type
monitor interface perhaps need some debug infrastructure that I
haven't added?
Nope. Same behavior with a F21 kernel (which means
On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi wrote:
How far is the station from the AP? Would it be possible to see whether
the behavior changes if you were within, say, five meters or so?
Well, it was pretty much within five meters already, but there was a
thin wall in between
On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen j...@w1.fi wrote:
This did not get exactly supportive response when this was proposed last
time (Sep 2013). Anyway, for a quick test, this can be done with the
following one-liner:
fwiw, that one-liner seems to work fine for me.
Which I guess is
On Sat, Feb 21, 2015 at 10:50 PM, Sujith Manoharan suj...@msujith.org wrote:
Can you please post the output of 'iw dev wlp1s0 scan' ?
Attached.
It's the UniFi-home SSID that doesn't work. The 1gnoraNT one is the
old working one that I'm obviously associated with, and that has
multiple AP's.
On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd adr...@freebsd.org wrote:
Just a wild shot - try disabling fast authentication and see if that
makes a difference?
wpa_supplicant.conf:
fast_reauth=0
I recall having issues with fast_reauth once, but I never stuck around
that location long
On Sun, Feb 22, 2015 at 11:39 AM, Adrian Chadd adr...@freebsd.org wrote:
Hm, can you enable wpa debugging to log everything whilst it's
associating / reassociating?
Ugh. When I add -dd to the command line, it has now worked three
times in a row, when before it worked once out of ten tries.
So
On Sun, Feb 22, 2015 at 10:58 AM, Dave Taht dave.t...@gmail.com wrote:
Hint: Several unifi (and most ubnt) products are well supported by
openwrt directly,
I want Linux to just work. None of this oh, you can change
something else and it probably works. I want to fix the problem in
*linux*.
On Sun, Feb 22, 2015 at 1:50 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Ugh. When I add -dd to the command line, it has now worked three
times in a row, when before it worked once out of ten tries.
So my guess is that it's something timing-dependent.
So it stays working with -dd
On Sun, Feb 22, 2015 at 5:55 PM, Adrian Chadd adr...@freebsd.org wrote:
Do you have a 5GHz SSID setup on this access point? Is this kind of
messed up diassociation-to-steer-you-to-another-band thing?
Nope. That's the older single-band UniFi UAP - 2.4GHz only.
Linus
--
On Sun, Feb 22, 2015 at 4:54 PM, Adrian Chadd adr...@freebsd.org wrote:
I /think/ it's okay? The removed stuff is the pre-shared key pieces.
Ok. Attached is what seems to be the relevant part of the
wpa_supplicant.log file.
The datestamp has been changed so that it can be matched up with the
On Mon, Jan 19, 2015 at 5:48 AM, Arend van Spriel ar...@broadcom.com wrote:
So as you indicated you were in location where none of your configured
networks were available. Flipping the rfkill switch in that situation is the
way to trigger the issue.
So you certainly seem to be able to explain
On Sun, Jan 18, 2015 at 11:24 PM, Emmanuel Grumbach egrumb...@gmail.com wrote:
we have different scan flows based on the firmware version you have,
so it would help if you could tell me what firmware you have.
Sure. It's the larest one I could find
iwlwifi :01:00.0: loaded firmware
So there seems to be some issue with unlucky timing when turning off
wireless while the driver is busy scanning. I can't reproduce this, so
it's a one-off, but it's not just ugly warnings, the kernel woudln't
scan any wireless on that device afterwards and I had to reboot to get
networking back,
On Thu, Jan 1, 2015 at 11:44 AM, Lennart Sorensen
lsore...@csclub.uwaterloo.ca wrote:
ifconfig seems to just be broken for many cases of perfectly nice features
in the kernel.
So I'm not saying ifconfig is wonderful. It's not.
But I *am* saying that changing user interfaces and then expecting
On Wed, Dec 31, 2014 at 9:31 AM, Theodore Ts'o ty...@mit.edu wrote:
Most poeple are still using route and ifconfig instead of ip.
Deal with it.
Indeed. This whole let's throw out the old and broken stuff is a disease.
It would have been much better (and it's still an option, as Ted
points
On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o ty...@mit.edu wrote:
Yeah, the confusing part is that ip tends to use verb object
scheme, which is consistent with the Cisco IOS command set it was
trying to emulate.
Side note: does anybody think that was really a good idea to begin
with? I
56 matches
Mail list logo