* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-22 16:24 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <1469204186.15064.6.camel@redhat.com>
Hi Dan,
I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
For now though - the iwlist scan results for both a USB device and the
libertas device:
USB: http://termbin.com/hdwl
Libertas: http://termbin.com/jxh7
Will follow up shortly with WPA and Open network configs.
Christopher Williamson
On 22 July 2016 at 17:16:29, Dan Williams
(dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> Hi Dan,
>
> I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
>
> For now though - the iwlist scan results for both a USB device and the
> libertas device:
>
> USB: http://termbin.com/hdwl
> Libertas: http://termbin.com/jxh7
>
> Will follow up shortly with WPA and Open network configs.
>
> *Christopher Williamson*
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-22 16:39 UTC (permalink / raw)
To: Dan Williams, linux-wireless@vger.kernel.org, Arend Van Spriel
In-Reply-To: <CANXHH3nvu7TC=x5RTR_WcgGkd2=_0h4BZrc_Nv74023nrc3P5w@mail.gmail.com>
Ok so I created a guest wifi network without any encryption enabled at
all and the client still refuses to connect.
Again, the connection is made perfectly using the USB dongle I have
but not the built in libertas sd8686 chipset.
I do currently use pfSense as a firewall box behind my wireless router
(acting as an AP) and can see that no DHCP request is making it to the
pfSense box. I believe you are right in the point about the firmware
being the problem here.
I should also confirm - the firmware in use is the latest from the
linux-firmware Ubuntu 16.04 package. I did read around the net about
being having various issues with various firmware sources and not
others but despite trying firmware linked directly from Marvell I seem
to always get one of two issues:
1.) I am unable to connect and keep getting asked for passphrases, or:
2.) The system completely freezes up (with the v8 firmwares I tried)
I’m not really sure what else to try at this point.
Christopher Williamson
On 22 July 2016 at 17:24:52, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> Hi Dan,
>
> I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
>
> For now though - the iwlist scan results for both a USB device and the
> libertas device:
>
> USB: http://termbin.com/hdwl
> Libertas: http://termbin.com/jxh7
>
> Will follow up shortly with WPA and Open network configs.
>
> Christopher Williamson
>
>
>
> On 22 July 2016 at 17:16:29, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
>
> > Hi Dan,
> >
> > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> >
> > For now though - the iwlist scan results for both a USB device and the
> > libertas device:
> >
> > USB: http://termbin.com/hdwl
> > Libertas: http://termbin.com/jxh7
> >
> > Will follow up shortly with WPA and Open network configs.
> >
> > *Christopher Williamson*
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-22 16:54 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <CANXHH3kX-U_CRfBf+DVe7AMpU13fKGG5bRwgLhDqYuGOBF-HBw@mail.gmail.com>
Disregard - I have actually managed to get this to connect to a open network!
# iw reg set GB
# iw reg get
country GB: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A)
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
(5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
# iwconfig wlan0 essid "shaunthesheep-guest”
# dhclient wlan0
It’s good to have some progress - so it looks like the issue
preventing the previous connection was the iw reg not being set
properly (or possibly just wpa_supplicant borking the connection in
some way. I stopped that this time around. I’ll try wpa1 now and
report back.
Christopher Williamson
On 22 July 2016 at 17:39:50, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> Ok so I created a guest wifi network without any encryption enabled at all and the client still refuses to connect.
>
> Again, the connection is made perfectly using the USB dongle I have but not the built in libertas sd8686 chipset.
>
> I do currently use pfSense as a firewall box behind my wireless router (acting as an AP) and can see that no DHCP request is making it to the pfSense box. I believe you are right in the point about the firmware being the problem here.
>
> I should also confirm - the firmware in use is the latest from the linux-firmware Ubuntu 16.04 package. I did read around the net about being having various issues with various firmware sources and not others but despite trying firmware linked directly from Marvell I seem to always get one of two issues:
>
> 1.) I am unable to connect and keep getting asked for passphrases, or:
> 2.) The system completely freezes up (with the v8 firmwares I tried)
>
> I’m not really sure what else to try at this point.
> Christopher Williamson
>
>
>
> On 22 July 2016 at 17:24:52, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> >
> > Hi Dan,
> >
> > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> >
> > For now though - the iwlist scan results for both a USB device and the
> > libertas device:
> >
> > USB: http://termbin.com/hdwl
> > Libertas: http://termbin.com/jxh7
> >
> > Will follow up shortly with WPA and Open network configs.
> >
> > Christopher Williamson
> >
> >
> >
> > On 22 July 2016 at 17:16:29, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> >
> > > Hi Dan,
> > >
> > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > >
> > > For now though - the iwlist scan results for both a USB device and the
> > > libertas device:
> > >
> > > USB: http://termbin.com/hdwl
> > > Libertas: http://termbin.com/jxh7
> > >
> > > Will follow up shortly with WPA and Open network configs.
> > >
> > > *Christopher Williamson*
^ permalink raw reply
* Re: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
From: Jouni Malinen @ 2016-07-22 16:55 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam
In-Reply-To: <ab0bb1b790c74675a92b129916662545@SC-EXCH04.marvell.com>
On Fri, Jul 22, 2016 at 03:59:47PM +0000, Amitkumar Karwar wrote:
> I am trying to understand the problem you mentioned during IGTK rekeying. Today I ran tests with two stations connecting an AP. MFP is enabled on all of them.
>
> On hostapd side, my observation is add_key() is always called followed by set_default_mgmt_key(). set_default_mgmt_key() sets the key added by add_key() as default key.
>
> We are ignoring set_default_mgmt_key() and updating Tx key index during add_key() itself.
>
> Your concerns is we should not update Tx key index during add_key(). Reason is IGTK rekeying is not yet completed with all stations. Right?
Correct. set_default_mgmt_key() does not have much effect for the very
first IGTK configuration, but whenever doing IGTK rekeying, hostapd
behaves just like it does with GTK rekeying. In other words, a different
Key ID is selected (alternating between 4 and 5), a random new IGTK is
generated, the new IGTK is configured to the local driver (but the old
IGTK is still supposed to be used for TX), each associated STA is
notified of the new IGTK, the new IGTK is taken into use once the group
key handshake has completed with each associated STA. It is that last
operation that needs set_default_mgmt_key() to allow this rekeying to
work correctly. If you update the TX Key ID on add_key(), you'll risk
sending out frames that some of the associated STAs do not yet have a
key to validate.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-22 17:17 UTC (permalink / raw)
To: Dan Williams, linux-wireless@vger.kernel.org, Arend Van Spriel
In-Reply-To: <CANXHH3nB3BujorAuYRweE=w+n=ESoJod2LFphRrxwXrXUrf_zw@mail.gmail.com>
I haven’t managed to get connected to a WPA network either so it looks
like open only at the moment but I fear that may just have been a
fluke.
A big problem I’m facing is that editing /etc/default/crda to
REGDOMAIN=GB wasn’t enough to set the wifi regulation mode to GB and I
have to set it manually. This sometimes works and sometimes reports
the following:
country 98: DFS-UNSET
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(2457 - 2472 @ 15), (N/A, 20), (N/A), NO-IR
(5170 - 5250 @ 80), (N/A, 17), (N/A), NO-IR
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
(5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
(57240 - 63720 @ 2160), (N/A, 0), (N/A)
At best this is simply an annoyance but at worst I’m thinking this may
be responsible for the issues I’m seeing.
Is there anywhere else I can force this to be set to GB?
Christopher Williamson
On 22 July 2016 at 17:54:40, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> Disregard - I have actually managed to get this to connect to a open network!
>
> # iw reg set GB
> # iw reg get
> country GB: DFS-ETSI
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 20), (N/A)
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
> (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> # iwconfig wlan0 essid "shaunthesheep-guest”
> # dhclient wlan0
>
> It’s good to have some progress - so it looks like the issue preventing the previous connection was the iw reg not being set properly (or possibly just wpa_supplicant borking the connection in some way. I stopped that this time around. I’ll try wpa1 now and report back.
>
>
> Christopher Williamson
>
>
>
> On 22 July 2016 at 17:39:50, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> >
> > Ok so I created a guest wifi network without any encryption enabled at all and the client still refuses to connect.
> >
> > Again, the connection is made perfectly using the USB dongle I have but not the built in libertas sd8686 chipset.
> >
> > I do currently use pfSense as a firewall box behind my wireless router (acting as an AP) and can see that no DHCP request is making it to the pfSense box. I believe you are right in the point about the firmware being the problem here.
> >
> > I should also confirm - the firmware in use is the latest from the linux-firmware Ubuntu 16.04 package. I did read around the net about being having various issues with various firmware sources and not others but despite trying firmware linked directly from Marvell I seem to always get one of two issues:
> >
> > 1.) I am unable to connect and keep getting asked for passphrases, or:
> > 2.) The system completely freezes up (with the v8 firmwares I tried)
> >
> > I’m not really sure what else to try at this point.
> > Christopher Williamson
> >
> >
> >
> > On 22 July 2016 at 17:24:52, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> >
> > >
> > > Hi Dan,
> > >
> > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > >
> > > For now though - the iwlist scan results for both a USB device and the
> > > libertas device:
> > >
> > > USB: http://termbin.com/hdwl
> > > Libertas: http://termbin.com/jxh7
> > >
> > > Will follow up shortly with WPA and Open network configs.
> > >
> > > Christopher Williamson
> > >
> > >
> > >
> > > On 22 July 2016 at 17:16:29, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > >
> > > > Hi Dan,
> > > >
> > > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > > >
> > > > For now though - the iwlist scan results for both a USB device and the
> > > > libertas device:
> > > >
> > > > USB: http://termbin.com/hdwl
> > > > Libertas: http://termbin.com/jxh7
> > > >
> > > > Will follow up shortly with WPA and Open network configs.
> > > >
> > > > *Christopher Williamson*
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Arnd Bergmann @ 2016-07-22 19:47 UTC (permalink / raw)
To: Jes Sorensen
Cc: Stefan Lippers-Hollmann, linux-wireless, Kalle Valo, Larry Finger,
netdev, Greg Kroah-Hartman, Mateusz Kulikowski, devel,
linux-kernel, Andrea Merello
In-Reply-To: <wrfjoa5phop3.fsf@redhat.com>
On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote:
> Stefan Lippers-Hollmann <s.l-h@gmx.de> writes:
> > Hi
> >
> > On 2016-07-20, Arnd Bergmann wrote:
> >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> >> > Arnd Bergmann <arnd@arndb.de> writes:
> >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> >> > >> Arnd Bergmann <arnd@arndb.de> writes:
> > [...]
> >> Yes, I was just agreeing here that it's not worth doing that one.
> >> As far as I can see, the evolution of these devices is
> >>
> >> RTL81xxU (2008)
> >> RTL81xxSU (2009)
> >> RTL81xxCU (2010)
> >
> > There is also RTL81xxDU, apparently from 2011, a dualband device
> > coming in several variants (single MAC + single PHY, double MAC +
> > double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC).
Right. In my list above I tried to have just the ones that seem
to each be 100% supersets of previous generations replacing the
earlier ones, which isn't true for RTL81xxDU as RTL81xxEU
reverts to single PHY.
> > While probably not overly common, it was/ is (hardware-wise) a pretty
> > interesting device due to its support for 5 GHz[1] - actually I hoped
> > it to be a (supported-) RTL8192CU variant when I bought it.
> > Unfortunately no driver[2] made it to staging or the proper kernel.
>
> I actually have one of those in my USB dongle box, but as you say, not
> overly common so not sure if/when I'll get to it.
>
> Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too
> complicated.
My guess is that these devices have largely been replaced by
802.11ac devices on the market, and whoever has one of the old ones
probably bought it because of the 5GHz support, so adding 2.4GHz-only
support for it may not help all that much either.
Arnd
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Stefan Lippers-Hollmann @ 2016-07-22 20:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jes Sorensen, linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel,
Andrea Merello
In-Reply-To: <7894919.vMsHjmmMb1@wuerfel>
Hi
On 2016-07-22, Arnd Bergmann wrote:
> On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote:
> > Stefan Lippers-Hollmann <s.l-h@gmx.de> writes:
> > > On 2016-07-20, Arnd Bergmann wrote:
> > >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> > >> > Arnd Bergmann <arnd@arndb.de> writes:
> > >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> > >> > >> Arnd Bergmann <arnd@arndb.de> writes:
[...]
> > > While probably not overly common, it was/ is (hardware-wise) a pretty
> > > interesting device due to its support for 5 GHz[1] - actually I hoped
> > > it to be a (supported-) RTL8192CU variant when I bought it.
> > > Unfortunately no driver[2] made it to staging or the proper kernel.
> >
> > I actually have one of those in my USB dongle box, but as you say, not
> > overly common so not sure if/when I'll get to it.
> >
> > Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too
> > complicated.
>
> My guess is that these devices have largely been replaced by
> 802.11ac devices on the market, and whoever has one of the old ones
> probably bought it because of the 5GHz support, so adding 2.4GHz-only
> support for it may not help all that much either.
Talking purely for myself, I've certainly bought the rtl8192du device
because of its 5 GHz support, as I've made it a fairly hard policy for
me not to buy 2.4 GHz only devices anymore. But this doesn't mean that
a mainline driver only supporting 2.4 GHz for the time being would not be
appreciated dearly, given that the current state of the device is pretty
much being a doorstop[1] - especially considering that 5 GHz support
might even become a possibility at a later time, when 802.11ac devices
start demanding most of the functionality for potentially more common
newer chipset generations.
So even with my current personal policy of only buying 5 GHz capable
devices, in practice you probably won't find 5 GHz only AP installations
(aside from long range/ outdoor point-to-point connections), be it
because of the plethora of existing 2.4 GHz only devices or just because
of the longer indoor (walls) range of the 2.4 GHz band. In practice, by
far most of my existing wireless devices don't support 5 GHz (the router
does, of course) because of the reasons mentioned above, but replacing
older devices takes its time.
Regards
Stefan Lippers-Hollmann
[1] yes, I know about https://github.com/lwfinger/rtl8192du/ and
even have a couple of clean-up patches pending[2] for the
kernel-version branch, but those need some further testing.
[2] http://aptosid.com/slh/rtl8192du/kernel-version/
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-22 21:47 UTC (permalink / raw)
To: Dan Williams, linux-wireless@vger.kernel.org, Arend Van Spriel
In-Reply-To: <CANXHH3m2XEjkOfXGhtBUqCfu4Vix365fiRHzHL3DanoVzOsT3w@mail.gmail.com>
Hi all,
So I decided to have another fiddle with this and managed to get the
WiFi working perfectly first time on an ArchLinux LiveCD so it looks
like this issue is Ubuntu specific.
I’m going to copy the firmware files and check if they’re responsible
and work my way through the various differences but at least I know
this device can work properly on the Linux 4.6.3 (which the livecd is
based on.)
I’ll follow up if and when I find out what the cause of the problem was.
Christopher Williamson
On 22 July 2016 at 22:42:50, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> Hi all,
>
> So I decided to have another fiddle with this and managed to get the WiFi working perfectly first time on an ArchLinux LiveCD so it looks like this issue is Ubuntu specific.
>
> I’m going to copy the firmware files and check if they’re responsible and work my way through the various differences but at least I know this device can work properly on the Linux 4.6.3 (which the livecd is based on.)
>
> I’ll follow up if and when I find out what the cause of the problem was.
> Christopher Williamson
> www.chrisaw.com(http://www.chrisaw.com)
>
>
>
>
> On 22 July 2016 at 18:17:20, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> > I haven’t managed to get connected to a WPA network either so it looks like open only at the moment but I fear that may just have been a fluke.
> >
> > A big problem I’m facing is that editing /etc/default/crda to REGDOMAIN=GB wasn’t enough to set the wifi regulation mode to GB and I have to set it manually. This sometimes works and sometimes reports the following:
> >
> > country 98: DFS-UNSET
> > (2402 - 2472 @ 40), (N/A, 20), (N/A)
> > (2457 - 2472 @ 15), (N/A, 20), (N/A), NO-IR
> > (5170 - 5250 @ 80), (N/A, 17), (N/A), NO-IR
> > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
> > (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
> > (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
> > (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> >
> > At best this is simply an annoyance but at worst I’m thinking this may be responsible for the issues I’m seeing.
> >
> > Is there anywhere else I can force this to be set to GB?
> >
> > Christopher Williamson
> >
> >
> > On 22 July 2016 at 17:54:40, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> >
> > > Disregard - I have actually managed to get this to connect to a open network!
> > >
> > > # iw reg set GB
> > > # iw reg get
> > > country GB: DFS-ETSI
> > > (2402 - 2482 @ 40), (N/A, 20), (N/A)
> > > (5170 - 5250 @ 80), (N/A, 20), (N/A)
> > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
> > > (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> > > (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> > > # iwconfig wlan0 essid "shaunthesheep-guest”
> > > # dhclient wlan0
> > >
> > > It’s good to have some progress - so it looks like the issue preventing the previous connection was the iw reg not being set properly (or possibly just wpa_supplicant borking the connection in some way. I stopped that this time around. I’ll try wpa1 now and report back.
> > >
> > >
> > > Christopher Williamson
> > >
> > >
> > >
> > > On 22 July 2016 at 17:39:50, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > >
> > > >
> > > > Ok so I created a guest wifi network without any encryption enabled at all and the client still refuses to connect.
> > > >
> > > > Again, the connection is made perfectly using the USB dongle I have but not the built in libertas sd8686 chipset.
> > > >
> > > > I do currently use pfSense as a firewall box behind my wireless router (acting as an AP) and can see that no DHCP request is making it to the pfSense box. I believe you are right in the point about the firmware being the problem here.
> > > >
> > > > I should also confirm - the firmware in use is the latest from the linux-firmware Ubuntu 16.04 package. I did read around the net about being having various issues with various firmware sources and not others but despite trying firmware linked directly from Marvell I seem to always get one of two issues:
> > > >
> > > > 1.) I am unable to connect and keep getting asked for passphrases, or:
> > > > 2.) The system completely freezes up (with the v8 firmwares I tried)
> > > >
> > > > I’m not really sure what else to try at this point.
> > > > Christopher Williamson
> > > >
> > > >
> > > >
> > > > On 22 July 2016 at 17:24:52, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > >
> > > > >
> > > > > Hi Dan,
> > > > >
> > > > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > > > >
> > > > > For now though - the iwlist scan results for both a USB device and the
> > > > > libertas device:
> > > > >
> > > > > USB: http://termbin.com/hdwl
> > > > > Libertas: http://termbin.com/jxh7
> > > > >
> > > > > Will follow up shortly with WPA and Open network configs.
> > > > >
> > > > > Christopher Williamson
> > > > >
> > > > >
> > > > >
> > > > > On 22 July 2016 at 17:16:29, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > > > >
> > > > > > Hi Dan,
> > > > > >
> > > > > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > > > > >
> > > > > > For now though - the iwlist scan results for both a USB device and the
> > > > > > libertas device:
> > > > > >
> > > > > > USB: http://termbin.com/hdwl
> > > > > > Libertas: http://termbin.com/jxh7
> > > > > >
> > > > > > Will follow up shortly with WPA and Open network configs.
> > > > > >
> > > > > > *Christopher Williamson*
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Luis R. Rodriguez @ 2016-07-22 22:05 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Stanislaw Gruszka, Prarit Bhargava, Emmanuel Grumbach,
Michal Kazior, Kalle Valo, linux-wireless, ath10k,
Arend van Spriel, Greg Kroah-Hartman, Ming Lei, Luis R. Rodriguez,
mmarek
In-Reply-To: <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
> + Luis
>
> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> > (cc: firmware and brcmfmac maintainers)
> >
> > On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
> >>
> >>
> >> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> >>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> >>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> >>>>>> Firmware files are versioned to prevent older
> >>>>>> driver instances to load unsupported firmware
> >>>>>> blobs. This is reflected with a fallback logic
> >>>>>> which attempts to load several firmware files.
> >>>>>>
> >>>>>> This however produced a lot of unnecessary
> >>>>>> warnings sometimes confusing users and leading
> >>>>>> them to rename firmware files making things even
> >>>>>> more confusing.
> >>>>>
> >>>>> This happens on kernels configured with
> >>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> >>>>> but also 60 seconds delay before loading next firmware version.
> >>>>> For some reason RHEL kernel needs above config option, so this
> >>>>> patch is very welcome from my perspective.
> >>>>>
> >>>>
> >>>> Sorry for my ignorance but how does the firmware loading work if not
> >>>> with udev's help?
> >>>
> >>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
> >>> file data directly from mounted filesystem without user space helper.
> >>
> >> Here's the situation: request_firmware() waits 60 seconds for udev to do its
> >> loading magic via a "usermode helper". This delay is there to allow, for
> >> example, userspace to unpack or download a new firmware image or verify the
> >> firmware image *in userspace* before providing it to the driver to apply to the HW.
> >>
> >> Why 60 seconds? It is arbitrary and there is no way for udev & the kernel to
> >> handshake on completion.
> >>
> >>>
> >>>> As you can imagine, iwlwifi is suffering from the
> >>>> same problem and I would be interested in applying the same change,
> >>>> but I'd love to understand a bit more :)
> >>>
> >>> Yes, iwlwifi (and some other drivers) suffer from this. However this
> >>> happen when the newest firmware version is not installed on the system
> >>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> >>> it's not common.
> >>
> >> request_firmware_direct() was introduced at my request because (as you've
> >> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
> >> periods of time when starting. The bug that this introduced was a 60 second
> >> delay per logical cpu when starting a system. On a 64 cpu system that meant the
> >> boot would complete in a little over one hour.
> >>
> >>>
> >>> I started to see this currently, because that option was enabled on
> >>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> >>> happened because of that, i.e. thermal device was not functional
> >>> because f/w wasn't loaded due to big delay.
> >>>
> >>> I'm not sure if replacing to request_firmware_direct() is a good
> >>> fix though. For example I can see this problem also on brcmfmac, which
> >>> use request_firmware_nowait(). I think I would rather prefer special
> >>> helper for firmware drivers that needs user helper and have
> >>> request_firmware() be direct as default.
> >>>
> >>
> >> The difference between request_firmware_direct() and request_firmware() is that
> >> the _direct() version does not wait the 60 seconds for udev interaction. The
> >> only userspace check performed is to see if the file is there, and if the file
> >> does exist it is provided to the driver to be applied to the hardware.
> >>
> >> So the real question to ask here is whether or not the ath10k, brcmfmac, and
> >> iwlwifi require udev to do anything beyond checking for the existence and
> >> loading the firmware image. If they don't, then it is better to use
> >> request_firmware_direct().
> >
> > They don't need that, like 99% of the drivers I think, hence changing the
> > default seems to be more reasonable. However changing 3 drivers would work
> > for me as well, and that change do not introduce risk of broking drivers
> > that require udev fw download.
> >
> > iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> > use request_firmware_nowait(), so it first need to be converted to
> > ordinary request_firmware(), but this should be doable and I can do
> > that.
>
> I am going bonkers here. This is the Nth time a discussion pops up on
> firmware API usage. I stopped counting N :-( So the first issue was that
> the INIT was taking to long as we were requesting firmware during probe
> which was executed in the INIT context. So we added a worker and
> register the driver from there. There was probably a reason for
> switching to _no_wait() as well, but I do not recall the details. The
> things is I don't know if I need user-space or not. I just need firmware
> to get the device up and running. We have changed our driver a couple of
> times now to accommodate something that in my opinion should have been
> abstracted behind the firmware API in the first place and now here is
> another proposal to change the drivers. Come on!
Its a big mess, but a lot of it has to do with the fact that none of the
issues have been well documented. Its also not clear what distros, driver
developers or users should do. I've tried helping with by providing such
documentation and also providing grammar rules to avoid further issues [0],
hopefully this series will be merged soon.
[0] https://marc.info/?l=linux-kernel&m=146611775314567
Using grammar rules the hunt with coccinelle as of today's linux-next
reveals there are only 2 explicit users of the usermode helper, and
I've vetted for these as well in the above patch series.
Now, other than this users will experience the usermode helper if the
distribution messed up and build their kernel with the fallback
usermode helper. If this was done on some old kernel the only way
to fix that is to fix that kernel build or change drivers to avoid
the usermode helper explicitly, unfortunately some API calls cannot
avoid it .... I've documented all this in the above series.
> > However I wonder if changing that will not broke the case when
> > driver is build-in in the kernel and f/w is not yet available when
> > driver start to initialize.
Indeed, tons of races are in theory possible here ;) technically since we use a
common API to read files directly now, a race might also be possible for other
users of the API on init as well. I have some grammar rules to test for this in
development, that is to vet that not only the firmware API is checked and we
avoid on init but also other callers that use the same read API.
> > Or maybe nowadays this is not the case
> > any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
> > images are build-in in the kernel or copied to initramfs?
The firmware API is a mess and I've been trying to correct that
with a more flexible API.
> That is a nice idea, but I have not seen any change in that area. Could
> have missed it.
Extensions to the fw API are IMHO best done through a newer flexible
API, feel free to refer to this development tree if you'd like to
contribute:
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2
Luis
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Luis R. Rodriguez @ 2016-07-22 22:15 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Arend Van Spriel, Prarit Bhargava, Emmanuel Grumbach,
Michal Kazior, Kalle Valo, linux-wireless, ath10k,
Arend van Spriel, Greg Kroah-Hartman, Ming Lei, Luis R. Rodriguez,
mmarek
In-Reply-To: <20160722102559.GA2662@redhat.com>
On Fri, Jul 22, 2016 at 12:26:00PM +0200, Stanislaw Gruszka wrote:
> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
> > + Luis
> >
> > On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> > > (cc: firmware and brcmfmac maintainers)
> > >
> > > On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
> > >>
> > >>
> > >> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> > >>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> > >>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > >>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> > >>>>>> Firmware files are versioned to prevent older
> > >>>>>> driver instances to load unsupported firmware
> > >>>>>> blobs. This is reflected with a fallback logic
> > >>>>>> which attempts to load several firmware files.
> > >>>>>>
> > >>>>>> This however produced a lot of unnecessary
> > >>>>>> warnings sometimes confusing users and leading
> > >>>>>> them to rename firmware files making things even
> > >>>>>> more confusing.
> > >>>>>
> > >>>>> This happens on kernels configured with
> > >>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> > >>>>> but also 60 seconds delay before loading next firmware version.
> > >>>>> For some reason RHEL kernel needs above config option, so this
> > >>>>> patch is very welcome from my perspective.
> > >>>>>
> > >>>>
> > >>>> Sorry for my ignorance but how does the firmware loading work if not
> > >>>> with udev's help?
> > >>>
> > >>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
> > >>> file data directly from mounted filesystem without user space helper.
> > >>
> > >> Here's the situation: request_firmware() waits 60 seconds for udev to do its
> > >> loading magic via a "usermode helper". This delay is there to allow, for
> > >> example, userspace to unpack or download a new firmware image or verify the
> > >> firmware image *in userspace* before providing it to the driver to apply to the HW.
> > >>
> > >> Why 60 seconds? It is arbitrary and there is no way for udev & the kernel to
> > >> handshake on completion.
> > >>
> > >>>
> > >>>> As you can imagine, iwlwifi is suffering from the
> > >>>> same problem and I would be interested in applying the same change,
> > >>>> but I'd love to understand a bit more :)
> > >>>
> > >>> Yes, iwlwifi (and some other drivers) suffer from this. However this
> > >>> happen when the newest firmware version is not installed on the system
> > >>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> > >>> it's not common.
> > >>
> > >> request_firmware_direct() was introduced at my request because (as you've
> > >> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
> > >> periods of time when starting. The bug that this introduced was a 60 second
> > >> delay per logical cpu when starting a system. On a 64 cpu system that meant the
> > >> boot would complete in a little over one hour.
> > >>
> > >>>
> > >>> I started to see this currently, because that option was enabled on
> > >>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> > >>> happened because of that, i.e. thermal device was not functional
> > >>> because f/w wasn't loaded due to big delay.
> > >>>
> > >>> I'm not sure if replacing to request_firmware_direct() is a good
> > >>> fix though. For example I can see this problem also on brcmfmac, which
> > >>> use request_firmware_nowait(). I think I would rather prefer special
> > >>> helper for firmware drivers that needs user helper and have
> > >>> request_firmware() be direct as default.
> > >>>
> > >>
> > >> The difference between request_firmware_direct() and request_firmware() is that
> > >> the _direct() version does not wait the 60 seconds for udev interaction. The
> > >> only userspace check performed is to see if the file is there, and if the file
> > >> does exist it is provided to the driver to be applied to the hardware.
> > >>
> > >> So the real question to ask here is whether or not the ath10k, brcmfmac, and
> > >> iwlwifi require udev to do anything beyond checking for the existence and
> > >> loading the firmware image. If they don't, then it is better to use
> > >> request_firmware_direct().
> > >
> > > They don't need that, like 99% of the drivers I think, hence changing the
> > > default seems to be more reasonable. However changing 3 drivers would work
> > > for me as well, and that change do not introduce risk of broking drivers
> > > that require udev fw download.
> > >
> > > iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> > > use request_firmware_nowait(), so it first need to be converted to
> > > ordinary request_firmware(), but this should be doable and I can do
> > > that.
> >
> > I am going bonkers here. This is the Nth time a discussion pops up on
> > firmware API usage. I stopped counting N :-( So the first issue was that
> > the INIT was taking to long as we were requesting firmware during probe
> > which was executed in the INIT context. So we added a worker and
> > register the driver from there. There was probably a reason for
> > switching to _no_wait() as well, but I do not recall the details. The
> > things is I don't know if I need user-space or not. I just need firmware
> > to get the device up and running. We have changed our driver a couple of
> > times now to accommodate something that in my opinion should have been
> > abstracted behind the firmware API in the first place and now here is
> > another proposal to change the drivers. Come on!
>
> I understand you dislike that :-) Just to clarify the issue here:
>
> Some drivers (including brcmfmac) request new firmware images, which are
> not yet available (i.e. development F/W versions) and then fall-back
> to older firmware version and works perfectly fine.
The right way to address this of course is to extend the FW API
so that a batch of firmware files can be hunted for and one can
easily annotate as a driver developer which are optional and which are
not. The API then will do everything for you.
I was considering this as a future extension to the firmware API
through the new extensible firmware API, the sysdata API. I'd prefer
to add that as a secondary step, but if someone wants to add support
for it now feel free to send me some patches against my tree.
> However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
> of missing F/W image, request firmware involve user space helper and
> waits 60s (loading_timeout value from drivers/base/firmware_class.c),
> what delays creating network interface and confuse users.
Correct, this has been a holy mess. One way to fix this on userspace
is to upgrade systemd with an exception to the udev kmod helper,
and avoid the timeout completely for kmod helper which loads drivers.
CONFIG_FW_LOADER_USER_HELPER_FALLBACK should be avoided.
> For brcmfmac this looks like this:
>
> [ 15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
> [ 15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
> <snip>
> [ 75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
> [ 75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
>
> Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
> silently fail and then instantly next F/W image is loaded.
Yup.
> Another option to solve to problem would be stop requesting not
> available publicly firmware. However, I assume some drivers would
> like to preserve that option.
No, this seems counter productive given that the firmware is expected
to land eventually.
> > > However I wonder if changing that will not broke the case when
> > > driver is build-in in the kernel and f/w is not yet available when
> > > driver start to initialize. Or maybe nowadays this is not the case
> > > any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
> > > images are build-in in the kernel or copied to initramfs?
> >
> > That is a nice idea, but I have not seen any change in that area. Could
> > have missed it.
>
> I believe this is how the things are already done, IOW switching to
> request_firmware_direct() in the driver should be no harm.
We don't stuff firmware as built-in if the driver used MODULE_FIRMWARE()
and the driver is built-in. What commit did that?
The right thing to do is distros should avoid
CONFIG_FW_LOADER_USER_HELPER_FALLBACK and if they are stuck with it, a
systemd work around is possible. Upstream systemd already increased
the timeout to 180 seconds. Upstream also added a udevd --event-timeout
command line option, look into that. Other distros (OpenSUSE) avoids
the kmod timeout ;)
The timeout thing was simply a mistake, specially for kmod and it wasn't
well thought out. I've listed more serious implications for it here:
http://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html
Luis
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Luis R. Rodriguez @ 2016-07-22 22:19 UTC (permalink / raw)
To: Prarit Bhargava
Cc: Arend Van Spriel, Stanislaw Gruszka, Emmanuel Grumbach,
Michal Kazior, Kalle Valo, linux-wireless, ath10k,
Arend van Spriel, Greg Kroah-Hartman, Ming Lei, Luis R. Rodriguez
In-Reply-To: <579216D8.2010401@redhat.com>
On Fri, Jul 22, 2016 at 08:51:36AM -0400, Prarit Bhargava wrote:
> On 07/22/2016 08:21 AM, Arend Van Spriel wrote:
> >> Another option to solve to problem would be stop requesting not
> >> available publicly firmware. However, I assume some drivers would
> >> like to preserve that option.
> >
> > Actually, this is not the case with brcmfmac. We do need a firmware
> > file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file,
> > ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device
> > works fine without it.
> >
> > What is still unclear to me is when request_firmware_direct() would fail
> > and in what circumstances the udev helper is a valid callback. Can you
> > explain such a scenario. Another question I have is what the reasons are
> > behind the 60 seconds timeout.
>
> request_firmware_direct() will fail when the specified FW file is not present.
> This is different from request_firmware() which implements a usermode helper to
> potentially download firmware, or unpack a firmware image.
>
> Re: 60 second timeout ... The 60 second timeout with request_firmware() is
> completely arbitrary. There is no way for udev to signal back to the kernel
> that userspace helper has not completed its actions, so the kernel has a 60 dead
> man timer-ish delay.
Lets call it what it was: the 60 second timeout thing was simply a mistake.
Its no longer 60 seconds anyway, and in fact its accepted a dreaded issue.
What *we* should be doing is thinking about proper long term architecture now.
Async probe was one solution to some issues, a new flexible firmware API
that avoids the usermode helper 100% is another.
Distros stuck with the fallback option should review their strategies,
either disabling the fallback option, upgrade systemd, or use alternative
solutions (opensuse has a good one).
> >>>> However I wonder if changing that will not broke the case when
> >>>> driver is build-in in the kernel and f/w is not yet available when
> >>>> driver start to initialize. Or maybe nowadays this is not the case
> >>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
> >>>> images are build-in in the kernel or copied to initramfs?
> >>>
> >>> That is a nice idea, but I have not seen any change in that area. Could
> >>> have missed it.
> >>
> >> I believe this is how the things are already done, IOW switching to
> >> request_firmware_direct() in the driver should be no harm.
> >
> > Ok. What are the consequences when:
> > - driver is built-in.
> > - driver+firmware present on initramfs.
> > - driver on initramfs, firmware only present on rootfs.
> > - driver+firmware only on rootfs.
> >
> > I assume the third one would be considered a configuration issue.
>
> I think your question here can be answered by reading drivers/base/Kconfig:88,
> and reading about those 4 config options.
No, this documentation is terrible, I've posted some patches to help with this
mess.
> I could paraphrase it butI think the
> Kconfig notes are better than I could explain it. Note that this is how things
> currently work with request_firmware_nowait(). IIRC request_firmware_nowait()
> is just an asynchronous version of request_firmware().
... its a mess.
Luis
^ permalink raw reply
* Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
From: Ben Greear @ 2016-07-22 22:43 UTC (permalink / raw)
To: Rajkumar Manoharan, ath10k; +Cc: linux-wireless, rmanohar, Felix Fietkau
In-Reply-To: <20160614061728.570-1-rmanohar@qti.qualcomm.com>
On 06/13/2016 11:17 PM, Rajkumar Manoharan wrote:
> commit b057886524be ("ath10k: do not use coherent memory for allocated
> device memory chunks") replaced coherent memory allocation for memory
> chunks to fix low memory platforms. Unfortunately this is causing system
> freeze on x86 platform while bringing up qca99x0 device. The system
> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
> this by limiting maximum memory chunk size to 256 KiB per request.
>
> Cc: Felix Fietkau <nbd@nbd.name>
> Fixes: b057886524be ("ath10k: do not use coherent memory for allocated device memory chunks")
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
> drivers/net/wireless/ath/ath10k/wmi.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 6279ab4a760e..7c15f65fe5ed 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
> if (!pool_size)
> return -EINVAL;
>
> + if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
> + num_units = WMI_MAX_MEM_CHUNK_SIZE /
> + round_up(unit_len, 4);
> + pool_size = num_units * round_up(unit_len, 4);
> + }
I started testing my 9980 x86-64 system with VT/d enabled today.
With this patch in my tree, it crashes on bootup (with my firmware).
Works fine without this patch.
I don't see the exact place it is crashing in the firmware, though I could
probably narrow it down with some effort. It is in the early startup code,
at least, which makes debugging more difficult.
This patch works fine with a slightly newer firmware compiled for 9984. That
same firmware compiled for 9980 crashes, but I am not certain it is the same issue
as the older 9980. It appears similar, at least.
Looks to me like there are lots of variances in how firmware and chip revisions
deal with this particular code, so we are going to have to test on lots of chips
and platforms to know if a 'fix' is really a fix or not.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
From: Sebastian Gottschall @ 2016-07-23 9:11 UTC (permalink / raw)
To: Ben Greear, Rajkumar Manoharan, ath10k
Cc: linux-wireless, rmanohar, Felix Fietkau
In-Reply-To: <5792A189.5050807@candelatech.com>
from my point of view this patch is just shit. it trunkates the maximum
allocated memory to a certain value.
so firmware requests 800 kb memory but just gets 256kb. so out of bound
memory access is guaranteed at all.
Am 23.07.2016 um 00:43 schrieb Ben Greear:
> On 06/13/2016 11:17 PM, Rajkumar Manoharan wrote:
>> commit b057886524be ("ath10k: do not use coherent memory for allocated
>> device memory chunks") replaced coherent memory allocation for memory
>> chunks to fix low memory platforms. Unfortunately this is causing system
>> freeze on x86 platform while bringing up qca99x0 device. The system
>> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
>> this by limiting maximum memory chunk size to 256 KiB per request.
>>
>> Cc: Felix Fietkau <nbd@nbd.name>
>> Fixes: b057886524be ("ath10k: do not use coherent memory for
>> allocated device memory chunks")
>> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
>> ---
>> drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
>> drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
>> b/drivers/net/wireless/ath/ath10k/wmi.c
>> index 6279ab4a760e..7c15f65fe5ed 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct
>> ath10k *ar, u32 req_id,
>> if (!pool_size)
>> return -EINVAL;
>>
>> + if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
>> + num_units = WMI_MAX_MEM_CHUNK_SIZE /
>> + round_up(unit_len, 4);
>> + pool_size = num_units * round_up(unit_len, 4);
>> + }
>
> I started testing my 9980 x86-64 system with VT/d enabled today.
> With this patch in my tree, it crashes on bootup (with my firmware).
> Works fine without this patch.
>
> I don't see the exact place it is crashing in the firmware, though I
> could
> probably narrow it down with some effort. It is in the early startup
> code,
> at least, which makes debugging more difficult.
>
> This patch works fine with a slightly newer firmware compiled for
> 9984. That
> same firmware compiled for 9980 crashes, but I am not certain it is
> the same issue
> as the older 9980. It appears similar, at least.
>
> Looks to me like there are lots of variances in how firmware and chip
> revisions
> deal with this particular code, so we are going to have to test on
> lots of chips
> and platforms to know if a 'fix' is really a fix or not.
>
> Thanks,
> Ben
>
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
From: Manoharan, Rajkumar @ 2016-07-23 9:45 UTC (permalink / raw)
To: Sebastian Gottschall, Ben Greear, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org, rmanohar@codeaurora.org,
nbd@nbd.name
In-Reply-To: <6495e664-5da8-a11b-0bd5-15dc24c51edf@dd-wrt.com>
> from my point of view this patch is just shit. it trunkates the maximum
> allocated memory to a certain value.
> so firmware requests 800 kb memory but just gets 256kb. so out of bound
> memory access is guaranteed at all.
>
Even with current logic, If the memory chunk allocation fails for bigger size, then it tries
to allocate smaller chunks. So anyway it is guaranteed for oob access. no?
while (!vaddr && num_units) {
pool_size = num_units * round_up(unit_len, 4);
if (!pool_size)
return -EINVAL;
vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
if (!vaddr)
num_units /= 2;
}
Actually the commit "ath10k: do not use coherent memory for allocated device memory chunks"
is causing system hang on non VT/d x86 platform. Better to revert the commit until it is properly
root caused
-Rajkumar
Am 23.07.2016 um 00:43 schrieb Ben Greear:
> On 06/13/2016 11:17 PM, Rajkumar Manoharan wrote:
>> commit b057886524be ("ath10k: do not use coherent memory for allocated
>> device memory chunks") replaced coherent memory allocation for memory
>> chunks to fix low memory platforms. Unfortunately this is causing system
>> freeze on x86 platform while bringing up qca99x0 device. The system
>> hangs while DMA mapping bigger memory chunks (689816/865444 bytes). Fix
>> this by limiting maximum memory chunk size to 256 KiB per request.
>>
>> Cc: Felix Fietkau <nbd@nbd.name>
>> Fixes: b057886524be ("ath10k: do not use coherent memory for
>> allocated device memory chunks")
>> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
>> ---
>> drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
>> drivers/net/wireless/ath/ath10k/wmi.h | 1 +
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
>> b/drivers/net/wireless/ath/ath10k/wmi.c
>> index 6279ab4a760e..7c15f65fe5ed 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>> @@ -4411,6 +4411,12 @@ static int ath10k_wmi_alloc_chunk(struct
>> ath10k *ar, u32 req_id,
>> if (!pool_size)
>> return -EINVAL;
>>
>> + if (pool_size > WMI_MAX_MEM_CHUNK_SIZE) {
>> + num_units = WMI_MAX_MEM_CHUNK_SIZE /
>> + round_up(unit_len, 4);
>> + pool_size = num_units * round_up(unit_len, 4);
>> + }
>
> I started testing my 9980 x86-64 system with VT/d enabled today.
> With this patch in my tree, it crashes on bootup (with my firmware).
> Works fine without this patch.
>
> I don't see the exact place it is crashing in the firmware, though I
> could
> probably narrow it down with some effort. It is in the early startup
> code,
> at least, which makes debugging more difficult.
>
> This patch works fine with a slightly newer firmware compiled for
> 9984. That
> same firmware compiled for 9980 crashes, but I am not certain it is
> the same issue
> as the older 9980. It appears similar, at least.
>
> Looks to me like there are lots of variances in how firmware and chip
> revisions
> deal with this particular code, so we are going to have to test on
> lots of chips
> and platforms to know if a 'fix' is really a fix or not.
>
> Thanks,
> Ben
>
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-23 12:29 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <CANXHH3kDVSiLwpKcYwdr4gqOZkgu9Djf=2e8kFpgZT2mT0AmZw@mail.gmail.com>
Just to follow up on this - I performed a minimal ubuntu server
install (16.04.1), commented out the crda udev rule (since that was
setting the weird country: 98 issue) and tried again and it still
didn’t work.
I did confirm that the md5 sums for the firmware included with Arch is
the exact same as the firmware included for Ubuntu 16.04.1 so there
was no difference there.
At this point I’m thinking it’s either:
- Some Ubuntu-specific udev rule breaking things or:
- A difference in the kernel config between Arch and Ubuntu
I think I’m going to forfeit for now and switch over to Arch - spent
several days on this already. If anyone has any other ideas on what
could be causing this please do let me know and I’ll follow up if I
experiment this with again.
Christopher Williamson
On 22 July 2016 at 22:47:15, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> Hi all,
>
> So I decided to have another fiddle with this and managed to get the WiFi working perfectly first time on an ArchLinux LiveCD so it looks like this issue is Ubuntu specific.
>
> I’m going to copy the firmware files and check if they’re responsible and work my way through the various differences but at least I know this device can work properly on the Linux 4.6.3 (which the livecd is based on.)
>
> I’ll follow up if and when I find out what the cause of the problem was.
>
> Christopher Williamson
>
>
>
>
> On 22 July 2016 at 22:42:50, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> > Hi all,
> >
> > So I decided to have another fiddle with this and managed to get the WiFi working perfectly first time on an ArchLinux LiveCD so it looks like this issue is Ubuntu specific.
> >
> > I’m going to copy the firmware files and check if they’re responsible and work my way through the various differences but at least I know this device can work properly on the Linux 4.6.3 (which the livecd is based on.)
> >
> > I’ll follow up if and when I find out what the cause of the problem was.
> > Christopher Williamson
> > www.chrisaw.com(http://www.chrisaw.com)
> >
> >
> >
> >
> > On 22 July 2016 at 18:17:20, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> >
> > > I haven’t managed to get connected to a WPA network either so it looks like open only at the moment but I fear that may just have been a fluke.
> > >
> > > A big problem I’m facing is that editing /etc/default/crda to REGDOMAIN=GB wasn’t enough to set the wifi regulation mode to GB and I have to set it manually. This sometimes works and sometimes reports the following:
> > >
> > > country 98: DFS-UNSET
> > > (2402 - 2472 @ 40), (N/A, 20), (N/A)
> > > (2457 - 2472 @ 15), (N/A, 20), (N/A), NO-IR
> > > (5170 - 5250 @ 80), (N/A, 17), (N/A), NO-IR
> > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
> > > (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
> > > (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
> > > (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> > >
> > > At best this is simply an annoyance but at worst I’m thinking this may be responsible for the issues I’m seeing.
> > >
> > > Is there anywhere else I can force this to be set to GB?
> > >
> > > Christopher Williamson
> > >
> > >
> > > On 22 July 2016 at 17:54:40, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > >
> > > > Disregard - I have actually managed to get this to connect to a open network!
> > > >
> > > > # iw reg set GB
> > > > # iw reg get
> > > > country GB: DFS-ETSI
> > > > (2402 - 2482 @ 40), (N/A, 20), (N/A)
> > > > (5170 - 5250 @ 80), (N/A, 20), (N/A)
> > > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
> > > > (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> > > > (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> > > > # iwconfig wlan0 essid "shaunthesheep-guest”
> > > > # dhclient wlan0
> > > >
> > > > It’s good to have some progress - so it looks like the issue preventing the previous connection was the iw reg not being set properly (or possibly just wpa_supplicant borking the connection in some way. I stopped that this time around. I’ll try wpa1 now and report back.
> > > >
> > > >
> > > > Christopher Williamson
> > > >
> > > >
> > > >
> > > > On 22 July 2016 at 17:39:50, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > >
> > > > >
> > > > > Ok so I created a guest wifi network without any encryption enabled at all and the client still refuses to connect.
> > > > >
> > > > > Again, the connection is made perfectly using the USB dongle I have but not the built in libertas sd8686 chipset.
> > > > >
> > > > > I do currently use pfSense as a firewall box behind my wireless router (acting as an AP) and can see that no DHCP request is making it to the pfSense box. I believe you are right in the point about the firmware being the problem here.
> > > > >
> > > > > I should also confirm - the firmware in use is the latest from the linux-firmware Ubuntu 16.04 package. I did read around the net about being having various issues with various firmware sources and not others but despite trying firmware linked directly from Marvell I seem to always get one of two issues:
> > > > >
> > > > > 1.) I am unable to connect and keep getting asked for passphrases, or:
> > > > > 2.) The system completely freezes up (with the v8 firmwares I tried)
> > > > >
> > > > > I’m not really sure what else to try at this point.
> > > > > Christopher Williamson
> > > > >
> > > > >
> > > > >
> > > > > On 22 July 2016 at 17:24:52, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > > >
> > > > > >
> > > > > > Hi Dan,
> > > > > >
> > > > > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > > > > >
> > > > > > For now though - the iwlist scan results for both a USB device and the
> > > > > > libertas device:
> > > > > >
> > > > > > USB: http://termbin.com/hdwl
> > > > > > Libertas: http://termbin.com/jxh7
> > > > > >
> > > > > > Will follow up shortly with WPA and Open network configs.
> > > > > >
> > > > > > Christopher Williamson
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 22 July 2016 at 17:16:29, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > > > > >
> > > > > > > Hi Dan,
> > > > > > >
> > > > > > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > > > > > >
> > > > > > > For now though - the iwlist scan results for both a USB device and the
> > > > > > > libertas device:
> > > > > > >
> > > > > > > USB: http://termbin.com/hdwl
> > > > > > > Libertas: http://termbin.com/jxh7
> > > > > > >
> > > > > > > Will follow up shortly with WPA and Open network configs.
> > > > > > >
> > > > > > > *Christopher Williamson*
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-23 13:26 UTC (permalink / raw)
To: Dan Williams, linux-wireless@vger.kernel.org, Arend Van Spriel
In-Reply-To: <CANXHH3nXBg9C+45rswD1ge-piH4Jz_XCaMULOMDgtfoTgKirzw@mail.gmail.com>
Quick follow-up - I suspected the issue may be with wpa_supplicant
rather than udev / kernel config.
Since this does connect properly on open wireless networks the issue
is now only with WPA/WPA2.
It seems even the latest dev builds of Ubuntu are still stuck using
wpa_supplicant 2.4.x rather than hopping over to 2.5 which I believe
contains a fix needed for the libertas chipset to properly
authenticate with WPA/WPA2 networks.
I therefore decided to compile version 2.5 of wpa_supplicant myself
and install it on a Ubuntu 16.04.1 clean install - looks like that
actually fixed the problem.
So the end result is - the ubuntu 2.4 wpa_supplicant doesn’t work with
libertas+libertas_sdio but it *does* work properly with wpa_supplicant
2.5.
Christopher Williamson
On 23 July 2016 at 13:29:41, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> Just to follow up on this - I performed a minimal ubuntu server install (16.04.1), commented out the crda udev rule (since that was setting the weird country: 98 issue) and tried again and it still didn’t work.
>
> I did confirm that the md5 sums for the firmware included with Arch is the exact same as the firmware included for Ubuntu 16.04.1 so there was no difference there.
>
> At this point I’m thinking it’s either:
>
> - Some Ubuntu-specific udev rule breaking things or:
> - A difference in the kernel config between Arch and Ubuntu
>
> I think I’m going to forfeit for now and switch over to Arch - spent several days on this already. If anyone has any other ideas on what could be causing this please do let me know and I’ll follow up if I experiment this with again.
>
> Christopher Williamson
>
>
>
>
> On 22 July 2016 at 22:47:15, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> >
> > Hi all,
> >
> > So I decided to have another fiddle with this and managed to get the WiFi working perfectly first time on an ArchLinux LiveCD so it looks like this issue is Ubuntu specific.
> >
> > I’m going to copy the firmware files and check if they’re responsible and work my way through the various differences but at least I know this device can work properly on the Linux 4.6.3 (which the livecd is based on.)
> >
> > I’ll follow up if and when I find out what the cause of the problem was.
> >
> > Christopher Williamson
> >
> >
> >
> >
> > On 22 July 2016 at 22:42:50, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> >
> > > Hi all,
> > >
> > > So I decided to have another fiddle with this and managed to get the WiFi working perfectly first time on an ArchLinux LiveCD so it looks like this issue is Ubuntu specific.
> > >
> > > I’m going to copy the firmware files and check if they’re responsible and work my way through the various differences but at least I know this device can work properly on the Linux 4.6.3 (which the livecd is based on.)
> > >
> > > I’ll follow up if and when I find out what the cause of the problem was.
> > > Christopher Williamson
> > > www.chrisaw.com(http://www.chrisaw.com)
> > >
> > >
> > >
> > >
> > > On 22 July 2016 at 18:17:20, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > >
> > > > I haven’t managed to get connected to a WPA network either so it looks like open only at the moment but I fear that may just have been a fluke.
> > > >
> > > > A big problem I’m facing is that editing /etc/default/crda to REGDOMAIN=GB wasn’t enough to set the wifi regulation mode to GB and I have to set it manually. This sometimes works and sometimes reports the following:
> > > >
> > > > country 98: DFS-UNSET
> > > > (2402 - 2472 @ 40), (N/A, 20), (N/A)
> > > > (2457 - 2472 @ 15), (N/A, 20), (N/A), NO-IR
> > > > (5170 - 5250 @ 80), (N/A, 17), (N/A), NO-IR
> > > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
> > > > (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
> > > > (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
> > > > (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> > > >
> > > > At best this is simply an annoyance but at worst I’m thinking this may be responsible for the issues I’m seeing.
> > > >
> > > > Is there anywhere else I can force this to be set to GB?
> > > >
> > > > Christopher Williamson
> > > >
> > > >
> > > > On 22 July 2016 at 17:54:40, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > >
> > > > > Disregard - I have actually managed to get this to connect to a open network!
> > > > >
> > > > > # iw reg set GB
> > > > > # iw reg get
> > > > > country GB: DFS-ETSI
> > > > > (2402 - 2482 @ 40), (N/A, 20), (N/A)
> > > > > (5170 - 5250 @ 80), (N/A, 20), (N/A)
> > > > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
> > > > > (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> > > > > (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> > > > > # iwconfig wlan0 essid "shaunthesheep-guest”
> > > > > # dhclient wlan0
> > > > >
> > > > > It’s good to have some progress - so it looks like the issue preventing the previous connection was the iw reg not being set properly (or possibly just wpa_supplicant borking the connection in some way. I stopped that this time around. I’ll try wpa1 now and report back.
> > > > >
> > > > >
> > > > > Christopher Williamson
> > > > >
> > > > >
> > > > >
> > > > > On 22 July 2016 at 17:39:50, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > > >
> > > > > >
> > > > > > Ok so I created a guest wifi network without any encryption enabled at all and the client still refuses to connect.
> > > > > >
> > > > > > Again, the connection is made perfectly using the USB dongle I have but not the built in libertas sd8686 chipset.
> > > > > >
> > > > > > I do currently use pfSense as a firewall box behind my wireless router (acting as an AP) and can see that no DHCP request is making it to the pfSense box. I believe you are right in the point about the firmware being the problem here.
> > > > > >
> > > > > > I should also confirm - the firmware in use is the latest from the linux-firmware Ubuntu 16.04 package. I did read around the net about being having various issues with various firmware sources and not others but despite trying firmware linked directly from Marvell I seem to always get one of two issues:
> > > > > >
> > > > > > 1.) I am unable to connect and keep getting asked for passphrases, or:
> > > > > > 2.) The system completely freezes up (with the v8 firmwares I tried)
> > > > > >
> > > > > > I’m not really sure what else to try at this point.
> > > > > > Christopher Williamson
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 22 July 2016 at 17:24:52, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > > > >
> > > > > > >
> > > > > > > Hi Dan,
> > > > > > >
> > > > > > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > > > > > >
> > > > > > > For now though - the iwlist scan results for both a USB device and the
> > > > > > > libertas device:
> > > > > > >
> > > > > > > USB: http://termbin.com/hdwl
> > > > > > > Libertas: http://termbin.com/jxh7
> > > > > > >
> > > > > > > Will follow up shortly with WPA and Open network configs.
> > > > > > >
> > > > > > > Christopher Williamson
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 22 July 2016 at 17:16:29, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > > > > > >
> > > > > > > > Hi Dan,
> > > > > > > >
> > > > > > > > I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
> > > > > > > >
> > > > > > > > For now though - the iwlist scan results for both a USB device and the
> > > > > > > > libertas device:
> > > > > > > >
> > > > > > > > USB: http://termbin.com/hdwl
> > > > > > > > Libertas: http://termbin.com/jxh7
> > > > > > > >
> > > > > > > > Will follow up shortly with WPA and Open network configs.
> > > > > > > >
> > > > > > > > *Christopher Williamson*
^ permalink raw reply
* [v3] UCC_GETH/UCC_FAST: Use IS_ERR_VALUE_U32 API to avoid IS_ERR_VALUE abuses.
From: Arvind Yadav @ 2016-07-23 18:05 UTC (permalink / raw)
To: zajec5, leoli
Cc: qiang.zhao, scottwood, viresh.kumar, akpm, linux-wireless, netdev,
linuxppc-dev, linux, arnd, Arvind Yadav
IS_ERR_VALUE() assumes that its parameter is an unsigned long.
It can not be used to check if an 'unsigned int' reflects an error.
As they pass an 'unsigned int' into a function that takes an
'unsigned long' argument. This happens to work because the type
is sign-extended on 64-bit architectures before it gets converted
into an unsigned type.
However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.
It would be nice to any users that are not passing 'unsigned int'
arguments.
Passing value in IS_ERR_VALUE() is wrong, as they pass an
'unsigned int' into a function that takes an 'unsigned long'
argument.This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.
Passing an 'unsigned short' or 'unsigned int'argument into
IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers
and types that are wider than 'unsigned long'.
Any user will get compilation warning for that do not pass an
unsigned long' argument.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/bcma/scan.c | 2 --
drivers/net/ethernet/freescale/ucc_geth.c | 30 +++++++++++++++---------------
drivers/soc/fsl/qe/ucc_fast.c | 4 ++--
include/linux/err.h | 1 +
4 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
index 4a2d1b2..319d78e 100644
--- a/drivers/bcma/scan.c
+++ b/drivers/bcma/scan.c
@@ -272,8 +272,6 @@ static struct bcma_device *bcma_find_core_reverse(struct bcma_bus *bus, u16 core
return NULL;
}
-#define IS_ERR_VALUE_U32(x) ((x) >= (u32)-MAX_ERRNO)
-
static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
struct bcma_device_id *match, int core_num,
struct bcma_device *core)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 5bf1ade..d290dea 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -289,7 +289,7 @@ static int fill_init_enet_entries(struct ucc_geth_private *ugeth,
else {
init_enet_offset =
qe_muram_alloc(thread_size, thread_alignment);
- if (IS_ERR_VALUE(init_enet_offset)) {
+ if (IS_ERR_VALUE_U32(init_enet_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory\n");
qe_put_snum((u8) snum);
@@ -2234,7 +2234,7 @@ static int ucc_geth_alloc_tx(struct ucc_geth_private *ugeth)
ugeth->tx_bd_ring_offset[j] =
qe_muram_alloc(length,
UCC_GETH_TX_BD_RING_ALIGNMENT);
- if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
+ if (!IS_ERR_VALUE_U32(ugeth->tx_bd_ring_offset[j]))
ugeth->p_tx_bd_ring[j] =
(u8 __iomem *) qe_muram_addr(ugeth->
tx_bd_ring_offset[j]);
@@ -2311,7 +2311,7 @@ static int ucc_geth_alloc_rx(struct ucc_geth_private *ugeth)
ugeth->rx_bd_ring_offset[j] =
qe_muram_alloc(length,
UCC_GETH_RX_BD_RING_ALIGNMENT);
- if (!IS_ERR_VALUE(ugeth->rx_bd_ring_offset[j]))
+ if (!IS_ERR_VALUE_U32(ugeth->rx_bd_ring_offset[j]))
ugeth->p_rx_bd_ring[j] =
(u8 __iomem *) qe_muram_addr(ugeth->
rx_bd_ring_offset[j]);
@@ -2521,7 +2521,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
ugeth->tx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->tx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_tx_glbl_pram\n");
return -ENOMEM;
@@ -2541,7 +2541,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
sizeof(struct ucc_geth_thread_data_tx) +
32 * (numThreadsTxNumerical == 1),
UCC_GETH_THREAD_DATA_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->thread_dat_tx_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->thread_dat_tx_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_thread_data_tx\n");
return -ENOMEM;
@@ -2568,7 +2568,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
qe_muram_alloc(ug_info->numQueuesTx *
sizeof(struct ucc_geth_send_queue_qd),
UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->send_q_mem_reg_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->send_q_mem_reg_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_send_q_mem_reg\n");
return -ENOMEM;
@@ -2609,7 +2609,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
ugeth->scheduler_offset =
qe_muram_alloc(sizeof(struct ucc_geth_scheduler),
UCC_GETH_SCHEDULER_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->scheduler_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->scheduler_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_scheduler\n");
return -ENOMEM;
@@ -2656,7 +2656,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
qe_muram_alloc(sizeof
(struct ucc_geth_tx_firmware_statistics_pram),
UCC_GETH_TX_STATISTICS_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->tx_fw_statistics_pram_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->tx_fw_statistics_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_tx_fw_statistics_pram\n");
return -ENOMEM;
@@ -2693,7 +2693,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
ugeth->rx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
UCC_GETH_RX_GLOBAL_PRAM_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->rx_glbl_pram_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->rx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_rx_glbl_pram\n");
return -ENOMEM;
@@ -2712,7 +2712,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
qe_muram_alloc(numThreadsRxNumerical *
sizeof(struct ucc_geth_thread_data_rx),
UCC_GETH_THREAD_DATA_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->thread_dat_rx_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->thread_dat_rx_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_thread_data_rx\n");
return -ENOMEM;
@@ -2733,7 +2733,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
qe_muram_alloc(sizeof
(struct ucc_geth_rx_firmware_statistics_pram),
UCC_GETH_RX_STATISTICS_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->rx_fw_statistics_pram_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->rx_fw_statistics_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_rx_fw_statistics_pram\n");
return -ENOMEM;
@@ -2753,7 +2753,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
qe_muram_alloc(ug_info->numQueuesRx *
sizeof(struct ucc_geth_rx_interrupt_coalescing_entry)
+ 4, UCC_GETH_RX_INTERRUPT_COALESCING_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->rx_irq_coalescing_tbl_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->rx_irq_coalescing_tbl_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_rx_irq_coalescing_tbl\n");
return -ENOMEM;
@@ -2819,7 +2819,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
(sizeof(struct ucc_geth_rx_bd_queues_entry) +
sizeof(struct ucc_geth_rx_prefetched_bds)),
UCC_GETH_RX_BD_QUEUES_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->rx_bd_qs_tbl_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->rx_bd_qs_tbl_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_rx_bd_qs_tbl\n");
return -ENOMEM;
@@ -2905,7 +2905,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
ugeth->exf_glbl_param_offset =
qe_muram_alloc(sizeof(struct ucc_geth_exf_global_pram),
UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->exf_glbl_param_offset)) {
+ if (IS_ERR_VALUE_U32(ugeth->exf_glbl_param_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_exf_glbl_param\n");
return -ENOMEM;
@@ -3039,7 +3039,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* Allocate InitEnet command parameter structure */
init_enet_pram_offset = qe_muram_alloc(sizeof(struct ucc_geth_init_pram), 4);
- if (IS_ERR_VALUE(init_enet_pram_offset)) {
+ if (IS_ERR_VALUE_U32(init_enet_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_init_enet_pram\n");
return -ENOMEM;
diff --git a/drivers/soc/fsl/qe/ucc_fast.c b/drivers/soc/fsl/qe/ucc_fast.c
index a768931..f7fa59f 100644
--- a/drivers/soc/fsl/qe/ucc_fast.c
+++ b/drivers/soc/fsl/qe/ucc_fast.c
@@ -268,7 +268,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
/* Allocate memory for Tx Virtual Fifo */
uccf->ucc_fast_tx_virtual_fifo_base_offset =
qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
- if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
+ if (IS_ERR_VALUE_U32(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
@@ -281,7 +281,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
qe_muram_alloc(uf_info->urfs +
UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
- if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
+ if (IS_ERR_VALUE_U32(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
__func__);
uccf->ucc_fast_rx_virtual_fifo_base_offset = 0;
diff --git a/include/linux/err.h b/include/linux/err.h
index 1e35588..a42f942 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -19,6 +19,7 @@
#ifndef __ASSEMBLY__
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
+#define IS_ERR_VALUE_U32(x) unlikely((unsigned int)(x) >= (unsigned int)-MAX_ERRNO)
static inline void * __must_check ERR_PTR(long error)
{
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
From: Ben Greear @ 2016-07-23 21:55 UTC (permalink / raw)
To: Sebastian Gottschall, Rajkumar Manoharan, ath10k
Cc: linux-wireless, rmanohar, Felix Fietkau
In-Reply-To: <6495e664-5da8-a11b-0bd5-15dc24c51edf@dd-wrt.com>
On 07/23/2016 02:11 AM, Sebastian Gottschall wrote:
> from my point of view this patch is just shit. it trunkates the maximum allocated memory to a certain value.
> so firmware requests 800 kb memory but just gets 256kb. so out of bound memory access is guaranteed at all.
At least some of the firmware logic attempts to deal with this segmentation. 9984 firmware had bugs in one area that I fixed,
but probably there are other bugs and that is why it fails for 9980 firmware.
Even if I fix my firmware, that doesn't help everyone else with stock firmware.
At best, maybe enable this type of logic for only exact firmware with proper feature
flag showing that it is known to work with it.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* PROBLEM: network data corruption (bisected to e5a4b0bb803b)
From: Alan Curry @ 2016-07-24 3:35 UTC (permalink / raw)
To: chunkeey, linux-wireless, netdev, linux-kernel
[1.] One line summary of the problem:
network data corruption (bisected to e5a4b0bb803b)
[2.] Full description of the problem/report:
Note: although my bisect ended at a commit from before 3.19, I have the
same symptom in all newer kernels I've tried, up to 4.6.4.
The commit was:
>commit e5a4b0bb803b39a36478451eae53a880d2663d5b
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date: Mon Nov 24 18:17:55 2014 -0500
>
> switch memcpy_to_msg() and skb_copy{,_and_csum}_datagram_msg() to primitives
The symptom is that downloaded files (http, ftp, and probably other
protocols) have small corrupted segments (about 1-2 kilobytes long) in
random locations. Only downloads that sustain a high speed for at least a
few seconds are corrupted. Anything small enough to be received in less
than about 5 seconds is not affected.
If I download the same file twice in a row, the corruption is in different
places in each copy.
If I try to do a git clone, it fails a few seconds into the "Receiving
objects" stage with a deflate error.
[3.] Keywords: networking, carl9170
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
Multiple versions are known to be affected, from 3.19 to 4.6.4
[4.2.] Kernel .config file:
For testing I built with make x86_64_defconfig followed by enabling the
carl9170 driver, which adds these lines:
CONFIG_ATH_COMMON=m
CONFIG_ATH_CARDS=m
CONFIG_CARL9170=m
CONFIG_CARL9170_LEDS=y
CONFIG_CARL9170_WPC=y
[5.] Most recent kernel version which did not have the bug:
That would be the predecessor of e5a4b0bb803b39a36478451eae53a880d2663d5b
which is v3.18-rc6-1620-g17836394e578
[6.] no Oops
[7.] A small shell script or example program which triggers the
problem (if possible)
This command fails reliably for me when running an affected kernel:
git clone git://git.kernel.org/pub/scm/git/git.git
(I'm including all the standard format stuff suggested by REPORTING-BUGS,
but I think you can skip from here to section 8.7 without missing anything
relevant)
[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)
Mostly Debian 8.5 stable packages here.
GNU C 4.9.2
GNU Make 4.0
Binutils 2.25
Util-linux 2.25.2
Mount 2.25.2
Quota-tools 4.01
Linux C Library 2.19
Dynamic linker (ldd) 2.19
Procps 2.0.11
Kbd 1.15.5
Console-tools 1.15.5
Sh-utils 8.23
Modules Loaded <snipped since I'm not running the affected kernel now>
[8.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Pentium(R) CPU G620 @ 2.60GHz
stepping : 7
microcode : 0x14
cpu MHz : 1599.914
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm arat pln pts
bugs :
bogomips : 5188.45
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Pentium(R) CPU G620 @ 2.60GHz
stepping : 7
microcode : 0x14
cpu MHz : 2340.304
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm arat pln pts
bugs :
bogomips : 5189.38
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
[8.3.] Module information (from /proc/modules):
When I tested with the x86_64_defconfig + carl9170 kernel, there were
hardly any modules built, and I reproduced the problem after booting with
init=/bin/sh, so no unnecessary modules were loaded. Currently running a
normal 4.6.4 kernel which is showing the bug, there are many more modules:
ip6t_REJECT 1524 1 - Live 0xffffffffa0393000
nf_reject_ipv6 2744 1 ip6t_REJECT, Live 0xffffffffa038f000
ip6table_filter 1419 1 - Live 0xffffffffa038b000
ip6_tables 13135 1 ip6table_filter, Live 0xffffffffa0383000
nf_nat_tftp 1158 0 - Live 0xffffffffa037f000
nf_conntrack_tftp 4017 1 nf_nat_tftp, Live 0xffffffffa037b000
nf_nat_irc 1574 0 - Live 0xffffffffa0377000
nf_conntrack_irc 3787 1 nf_nat_irc, Live 0xffffffffa0373000
nf_nat_ftp 1836 0 - Live 0xffffffffa036f000
nf_conntrack_ftp 6335 1 nf_nat_ftp, Live 0xffffffffa036a000
ipt_REJECT 1457 2 - Live 0xffffffffa0366000
nf_reject_ipv4 2483 1 ipt_REJECT, Live 0xffffffffa0362000
xt_TCPMSS 3187 1 - Live 0xffffffffa035e000
iptable_mangle 1544 1 - Live 0xffffffffa035a000
nf_log_ipv4 3667 1 - Live 0xffffffffa0356000
nf_log_common 2837 1 nf_log_ipv4, Live 0xffffffffa0352000
xt_LOG 1487 1 - Live 0xffffffffa034e000
xt_tcpudp 2522 5 - Live 0xffffffffa034a000
iptable_filter 1480 1 - Live 0xffffffffa0346000
iptable_nat 1786 0 - Live 0xffffffffa0342000
nf_conntrack_ipv4 10891 1 - Live 0xffffffffa033b000
nf_defrag_ipv4 1475 1 nf_conntrack_ipv4, Live 0xffffffffa0337000
nf_nat_ipv4 4349 1 iptable_nat, Live 0xffffffffa0332000
nf_nat 10019 4 nf_nat_tftp,nf_nat_irc,nf_nat_ftp,nf_nat_ipv4, Live 0xffffffffa032a000
nf_conntrack 59739 9 nf_nat_tftp,nf_conntrack_tftp,nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat, Live 0xffffffffa030f000
ip_tables 12753 3 iptable_mangle,iptable_filter,iptable_nat, Live 0xffffffffa0307000
x_tables 14824 10 ip6t_REJECT,ip6table_filter,ip6_tables,ipt_REJECT,xt_TCPMSS,iptable_mangle,xt_LOG,xt_tcpudp,iptable_filter,ip_tables, Live 0xffffffffa02fd000
ide_generic 1377 0 [permanent], Live 0xffffffffa02f9000
ide_core 71087 1 ide_generic, Live 0xffffffffa02da000
snd_hda_codec_hdmi 28560 1 - Live 0xffffffffa02cd000
snd_hda_codec_realtek 50872 1 - Live 0xffffffffa02b7000
snd_hda_codec_generic 44234 1 snd_hda_codec_realtek, Live 0xffffffffa02a5000
snd_hda_intel 16223 1 - Live 0xffffffffa029b000
snd_hda_codec 66159 4 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel, Live 0xffffffffa027c000
snd_hda_core 37571 5 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec, Live 0xffffffffa0267000
snd_pcm_oss 29084 0 - Live 0xffffffffa025a000
snd_pcm 64191 5 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core,snd_pcm_oss, Live 0xffffffffa023e000
snd_timer 16920 1 snd_pcm, Live 0xffffffffa0234000
snd_mixer_oss 12283 2 snd_pcm_oss, Live 0xffffffffa022d000
snd 48509 8 snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss, Live 0xffffffffa0217000
soundcore 4527 2 snd, Live 0xffffffffa0211000
af_packet 26418 6 - Live 0xffffffffa0205000
arc4 2040 2 - Live 0xffffffffa0201000
carl9170 65428 0 - Live 0xffffffffa01ea000
ehci_pci 3783 0 - Live 0xffffffffa01e6000
ath 16832 1 carl9170, Live 0xffffffffa01dd000
led_class 3520 1 carl9170, Live 0xffffffffa01d8000
mac80211 319536 1 carl9170, Live 0xffffffffa0170000
cfg80211 178240 3 carl9170,ath,mac80211, Live 0xffffffffa0132000
rfkill 13258 1 cfg80211, Live 0xffffffffa0129000
xts 3015 2 - Live 0xffffffffa0125000
gf128mul 5879 1 xts, Live 0xffffffffa0120000
dm_crypt 15756 1 - Live 0xffffffffa0118000
dm_mod 75130 16 dm_crypt, Live 0xffffffffa00f9000
raid1 23138 1 - Live 0xffffffffa00ef000
md_mod 88740 2 raid1, Live 0xffffffffa00ce000
coretemp 4358 0 - Live 0xffffffffa00c9000
hwmon 2866 1 coretemp, Live 0xffffffffa00c4000
hid_generic 1321 0 - Live 0xffffffffa00c0000
usbhid 22332 1 - Live 0xffffffffa00b5000
hid 54261 2 hid_generic,usbhid, Live 0xffffffffa00a1000
xhci_pci 4024 0 - Live 0xffffffffa009d000
xhci_hcd 84050 1 xhci_pci, Live 0xffffffffa0082000
uhci_hcd 18422 0 - Live 0xffffffffa0079000
ohci_hcd 16591 0 - Live 0xffffffffa0070000
ehci_hcd 35022 1 ehci_pci, Live 0xffffffffa0062000
usbcore 142047 9 carl9170,ehci_pci,usbhid,xhci_pci,xhci_hcd,uhci_hcd,ohci_hcd,ehci_hcd, Live 0xffffffffa002b000
usb_common 2222 1 usbcore, Live 0xffffffffa0027000
loop 14910 0 - Live 0xffffffffa001e000
fuse 65423 0 - Live 0xffffffffa0005000
rtc 5294 0 - Live 0xffffffffa0000000
[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
0000-0000 : PCI Bus 0000:00
0000-0000 : dma1
0000-0000 : pic1
0000-0000 : timer0
0000-0000 : timer1
0000-0000 : keyboard
0000-0000 : PNP0800:00
0000-0000 : keyboard
0000-0000 : rtc
0000-0000 : dma page reg
0000-0000 : pic2
0000-0000 : dma2
0000-0000 : PNP0C04:00
0000-0000 : fpu
0000-0000 : ide_generic
0000-0000 : ide_generic
0000-0000 : ide_generic
0000-0000 : PCI Bus 0000:00
0000-0000 : vga+
0000-0000 : PCI Bus 0000:00
0000-0000 : ide_generic
0000-0000 : ACPI PM1a_EVT_BLK
0000-0000 : ACPI PM1a_CNT_BLK
0000-0000 : ACPI PM_TMR
0000-0000 : ACPI CPU throttle
0000-0000 : ACPI GPE0_BLK
0000-0000 : ACPI PM2_CNT_BLK
0000-0000 : pnp 00:06
0000-0000 : pnp 00:05
0000-0000 : pnp 00:04
0000-0000 : pnp 00:05
0000-0000 : pnp 00:01
0000-0000 : pnp 00:01
0000-0000 : pnp 00:01
0000-0000 : PCI conf1
0000-0000 : PCI Bus 0000:00
0000-0000 : pnp 00:05
0000-0000 : PCI Bus 0000:01
0000-0000 : 0000:01:00.0
0000-0000 : 0000:00:02.0
0000-0000 : 0000:00:1f.3
0000-0000 : 0000:00:1f.2
0000-0000 : ahci
0000-0000 : 0000:00:1f.2
0000-0000 : ahci
0000-0000 : 0000:00:1f.2
0000-0000 : ahci
0000-0000 : 0000:00:1f.2
0000-0000 : ahci
0000-0000 : 0000:00:1f.2
0000-0000 : ahci
00000000-00000000 : reserved
00000000-00000000 : System RAM
00000000-00000000 : reserved
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : Video ROM
00000000-00000000 : reserved
00000000-00000000 : System ROM
00000000-00000000 : System RAM
00000000-00000000 : Kernel code
00000000-00000000 : Kernel data
00000000-00000000 : Kernel bss
00000000-00000000 : reserved
00000000-00000000 : System RAM
00000000-00000000 : reserved
00000000-00000000 : System RAM
00000000-00000000 : ACPI Non-volatile Storage
00000000-00000000 : ACPI Tables
00000000-00000000 : ACPI Non-volatile Storage
00000000-00000000 : reserved
00000000-00000000 : System RAM
00000000-00000000 : reserved
00000000-00000000 : ACPI Non-volatile Storage
00000000-00000000 : reserved
00000000-00000000 : ACPI Non-volatile Storage
00000000-00000000 : reserved
00000000-00000000 : RAM buffer
00000000-00000000 : reserved
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : reserved
00000000-00000000 : 0000:00:02.0
00000000-00000000 : PCI Bus 0000:01
00000000-00000000 : 0000:01:00.0
00000000-00000000 : 0000:01:00.0
00000000-00000000 : PCI MMCONFIG 0000 [bus 00-ff]
00000000-00000000 : reserved
00000000-00000000 : pnp 00:00
00000000-00000000 : reserved
00000000-00000000 : 0000:00:02.0
00000000-00000000 : PCI Bus 0000:03
00000000-00000000 : 0000:03:00.0
00000000-00000000 : xhci-hcd
00000000-00000000 : PCI Bus 0000:02
00000000-00000000 : 0000:02:00.0
00000000-00000000 : xhci-hcd
00000000-00000000 : 0000:00:1b.0
00000000-00000000 : ICH HD audio
00000000-00000000 : 0000:00:1f.3
00000000-00000000 : 0000:00:1f.2
00000000-00000000 : ahci
00000000-00000000 : 0000:00:1d.0
00000000-00000000 : ehci_hcd
00000000-00000000 : 0000:00:1a.0
00000000-00000000 : ehci_hcd
00000000-00000000 : 0000:00:16.0
00000000-00000000 : reserved
00000000-00000000 : reserved
00000000-00000000 : IOAPIC 0
00000000-00000000 : HPET 0
00000000-00000000 : PNP0103:00
00000000-00000000 : reserved
00000000-00000000 : pnp 00:05
00000000-00000000 : reserved
00000000-00000000 : pnp 00:00
00000000-00000000 : reserved
00000000-00000000 : pnp 00:05
00000000-00000000 : pnp 00:00
00000000-00000000 : reserved
00000000-00000000 : pnp 00:00
00000000-00000000 : reserved
00000000-00000000 : pnp 00:00
00000000-00000000 : Local APIC
00000000-00000000 : reserved
00000000-00000000 : pnp 00:05
00000000-00000000 : System RAM
00000000-00000000 : RAM buffer
[8.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
Subsystem: Biostar Microtech Int'l Corp Device 3108
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: snb_uncore
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: Biostar Microtech Int'l Corp Device 110d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fe000000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
Subsystem: Biostar Microtech Int'l Corp Device 3108
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fe608000 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) (prog-if 20 [EHCI])
Subsystem: Biostar Microtech Int'l Corp Device 3108
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe607000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
Subsystem: Biostar Microtech Int'l Corp Device 8229
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 33
Region 0: Memory at fe600000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41a2
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=22
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000d0000000-00000000d00fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 41a1
Capabilities: [90] Subsystem: Biostar Microtech Int'l Corp Device 3108
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b5) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fe500000-fe5fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #1, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 41b1
Capabilities: [90] Subsystem: Biostar Microtech Int'l Corp Device 3108
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fe400000-fe4fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #2, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Biostar Microtech Int'l Corp Device 3108
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) (prog-if 20 [EHCI])
Subsystem: Biostar Microtech Int'l Corp Device 3108
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at fe606000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation H61 Express Chipset Family LPC Controller (rev 05)
Subsystem: Biostar Microtech Int'l Corp Device 3108
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05) (prog-if 01 [AHCI 1.0])
Subsystem: Biostar Microtech Int'l Corp Device 5207
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 26
Region 0: I/O ports at f0b0 [size=8]
Region 1: I/O ports at f0a0 [size=4]
Region 2: I/O ports at f090 [size=8]
Region 3: I/O ports at f080 [size=4]
Region 4: I/O ports at f060 [size=32]
Region 5: Memory at fe605000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 41d1
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
Subsystem: Biostar Microtech Int'l Corp Device 3108
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 3
Region 0: Memory at fe604000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at f040 [size=32]
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
Subsystem: Biostar Microtech Int'l Corp Device 230a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at d0004000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at d0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Not readable
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 3b-03-00-00-68-4c-e0-00
02:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller (prog-if 30 [XHCI])
Subsystem: Biostar Microtech Int'l Corp Device 6300
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at fe500000 (64-bit, non-prefetchable) [size=32K]
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [68] MSI-X: Enable+ Count=8 Masked-
Vector table: BAR=0 offset=00002000
PBA: BAR=0 offset=00002080
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <2us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <2us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Kernel driver in use: xhci_hcd
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller (prog-if 30 [XHCI])
Subsystem: Biostar Microtech Int'l Corp Device 6300
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fe400000 (64-bit, non-prefetchable) [size=32K]
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [68] MSI-X: Enable+ Count=8 Masked-
Vector table: BAR=0 offset=00002000
PBA: BAR=0 offset=00002080
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <2us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <2us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Kernel driver in use: xhci_hcd
[8.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: TSSTcorp Model: CDDVDW SH-222BB Rev: SB00
Type: CD-ROM ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: WDC WD10EZEX-00W Rev: 1A01
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: WDC WD10EZEX-00W Rev: 1A01
Type: Direct-Access ANSI SCSI revision: 05
[8.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
lsusb identifies my network device as:
Bus 005 Device 004: ID 0cf3:1002 Atheros Communications, Inc. TP-Link TL-WN821N v2 802.11n [Atheros AR9170]
I have version 1.9.9 of carl9170-1.fw in /lib/firmware
--
Alan Curry
^ permalink raw reply
* Problem with b43 monitor mode (14e4:4331)
From: Brian Candler @ 2016-07-24 10:31 UTC (permalink / raw)
To: linux-wireless
I am trying to get monitor mode working on a Macmini6,2 (late 2012
server) running Linux. This device has built-in Broadcom wifi. However I
can only see Beacon and Probe frames, not user traffic.
OS: Ubuntu 14.04, but with the linux-generic-lts-xenial kernel (4.4.0).
The server is connected to wired ethernet, so the wifi interface is
unused apart from this attempt to monitor other wireless traffic.
The broadcom device has PCI ID *14e4:4331* which I see listed as
supported at
<https://wireless.wiki.kernel.org/en/users/Drivers/b43#Known_PCI_devices>
<https://wireless.wiki.kernel.org/en/users/Drivers/b43#Known_PCI_devices>
Here is how I'm trying to set it up, following
<http://sandilands.info/sgordon/capturing-wireless-lan-with-ubuntu-tcpdump-kismet>
root@brian:/data# ifconfig wlan0 down
root@brian:/data# iwconfig wlan0 mode monitor
root@brian:/data# iwconfig wlan0
wlan0 IEEE 802.11bg Mode:Monitor Tx-Power=0 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
root@brian:/data# ifconfig wlan0 up
root@brian:/data# iwconfig wlan0 chan 6
root@brian:/data# tcpdump -i wlan0 -n -s0 -c 10000 -w file.pcap
tcpdump: WARNING: wlan0: no IPv4 address assigned
tcpdump: listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus
radiotap header), capture size 65535 bytes
Then I try generating some wireless traffic on the same channel from a
different device. But the results only show frames which are "Beacon",
"Probe Request" or "Probe Response":
root@brian:/data# tcpdump -r file.pcap | wc -l
reading from file file.pcap, link-type IEEE802_11_RADIO (802.11 plus
radiotap header)
1913
root@brian:/data# tcpdump -r file.pcap | egrep -v 'Beacon|Probe
Request|Probe Response'
reading from file file.pcap, link-type IEEE802_11_RADIO (802.11 plus
radiotap header)
root@brian:/data#
I did notice "Power Management:on" in the iwconfig output, but I can't
turn it off:
root@brian:~# ifconfig wlan0 down
root@brian:~# iwconfig wlan0 power off
Error for wireless request "Set Power Management" (8B2C) :
SET failed on device wlan0 ; Invalid argument.
Any ideas what I'm missing? According to
<https://www.aircrack-ng.org/doku.php?id=b43> b43 should have quite good
support for monitor mode.
Many thanks,
Brian Candler.
P.S. Additional chipset/module information
root@brian:/data# lsmod | grep b43
b43 413696 0
mac80211 733184 1 b43
cfg80211 557056 2 b43,mac80211
ssb 65536 1 b43
bcma 53248 1 b43
root@brian:/data# lspci -vnn | grep 14e4
01:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme
BCM57766 Gigabit Ethernet PCIe [14e4:1686] (rev 01)
Subsystem: Broadcom Corporation NetXtreme BCM57766 Gigabit Ethernet
PCIe [14e4:1686]
01:00.1 SD Host controller [0805]: Broadcom Corporation BCM57765/57785
SDXC/MMC Card Reader [14e4:16bc] (rev 01) (prog-if 01)
Subsystem: Broadcom Corporation Device [14e4:0000]
02:00.0 Network controller [0280]: Broadcom Corporation BCM4331
802.11a/b/g/n [*14e4:4331*] (rev 02)
root@brian:/data# modinfo b43
filename:
/lib/modules/4.4.0-28-generic/kernel/drivers/net/wireless/b43/b43.ko
firmware: b43/ucode9.fw
firmware: b43/ucode5.fw
firmware: b43/ucode16_mimo.fw
firmware: b43/ucode15.fw
firmware: b43/ucode14.fw
firmware: b43/ucode13.fw
firmware: b43/ucode11.fw
license: GPL
author: Rafał Miłecki
author: Gábor Stefanik
author: Michael Buesch
author: Stefano Brivio
author: Martin Langer
description: Broadcom B43 wireless driver
srcversion: 6046FCC9190ABD5D296D2D2
alias: ssb:v4243id0812rev10*
alias: ssb:v4243id0812rev0F*
alias: ssb:v4243id0812rev0D*
alias: ssb:v4243id0812rev0C*
alias: ssb:v4243id0812rev0B*
alias: ssb:v4243id0812rev0A*
alias: ssb:v4243id0812rev09*
alias: ssb:v4243id0812rev07*
alias: ssb:v4243id0812rev06*
alias: ssb:v4243id0812rev05*
alias: bcma:m04BFid0812rev2Acl*
alias: bcma:m04BFid0812rev28cl*
alias: bcma:m04BFid0812rev1Ecl*
alias: bcma:m04BFid0812rev1Dcl*
alias: bcma:m04BFid0812rev1Ccl*
alias: bcma:m04BFid0812rev18cl*
alias: bcma:m04BFid0812rev17cl*
alias: bcma:m04BFid0812rev15cl*
alias: bcma:m04BFid0812rev11cl*
depends: mac80211,ssb,bcma,cfg80211
intree: Y
vermagic: 4.4.0-28-generic SMP mod_unload modversions
parm: bad_frames_preempt:enable(1) / disable(0) Bad Frames
Preemption (int)
parm: fwpostfix:Postfix for the .fw files to load. (string)
parm: hwpctl:Enable hardware-side power control (default off)
(int)
parm: nohwcrypt:Disable hardware encryption. (int)
parm: hwtkip:Enable hardware tkip. (int)
parm: qos:Enable QOS support (default on) (int)
parm: btcoex:Enable Bluetooth coexistence (default on) (int)
parm: verbose:Log message verbosity: 0=error, 1=warn,
2=info(default), 3=debug (int)
parm: pio:Use PIO accesses by default: 0=DMA, 1=PIO (int)
parm: allhwsupport:Enable support for all hardware (even it if
overlaps with the brcmsmac driver) (int)
root@brian:/data# modinfo b43legacy
filename:
/lib/modules/4.4.0-28-generic/kernel/drivers/net/wireless/b43legacy/b43legacy.ko
firmware: b43legacy/ucode4.fw
firmware: b43legacy/ucode2.fw
license: GPL
author: Michael Buesch
author: Stefano Brivio
author: Martin Langer
description: Broadcom B43legacy wireless driver
srcversion: 8AD21A1A794B063800B1A08
alias: ssb:v4243id0812rev04*
alias: ssb:v4243id0812rev02*
depends: mac80211,ssb,cfg80211
intree: Y
vermagic: 4.4.0-28-generic SMP mod_unload modversions
parm: pio:enable(1) / disable(0) PIO mode (int)
parm: bad_frames_preempt:enable(1) / disable(0) Bad Frames
Preemption (int)
parm: fwpostfix:Postfix for the firmware files to load. (string)
root@brian:/data# head /sys/module/b43/parameters/*
==> /sys/module/b43/parameters/allhwsupport <==
0
==> /sys/module/b43/parameters/bad_frames_preempt <==
0
==> /sys/module/b43/parameters/btcoex <==
1
==> /sys/module/b43/parameters/fwpostfix <==
==> /sys/module/b43/parameters/hwpctl <==
0
==> /sys/module/b43/parameters/hwtkip <==
0
==> /sys/module/b43/parameters/nohwcrypt <==
0
==> /sys/module/b43/parameters/pio <==
0
==> /sys/module/b43/parameters/qos <==
1
==> /sys/module/b43/parameters/verbose <==
2
root@brian:/data# dmesg | egrep 'b43|wlan0'
[ 3.994522] b43-phy0: Broadcom 4331 WLAN found (core revision 29)
[ 3.994897] b43-phy0: Found PHY: Analog 9, Type 7 (HT), Revision 1
[ 3.994906] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2059, Revision
0, Version 1
[ 3.994907] b43-phy0 warning: 5 GHz band is unsupported on this PHY
[488620.730061] b43-phy0: Loading firmware version 666.2 (2011-02-23
01:15:07)
[488629.221640] device wlan0 entered promiscuous mode
[488695.406184] device wlan0 left promiscuous mode
^ permalink raw reply
* Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
From: Christian Lamparter @ 2016-07-24 17:45 UTC (permalink / raw)
To: Alan Curry
Cc: chunkeey, linux-wireless, netdev, linux-kernel, Al Viro,
alexmcwhirter
In-Reply-To: <201607240335.u6O3ZE81014171@sdf.org>
Hello,
I added Al Viro to the CC (probably not necessary...)
On Sunday, July 24, 2016 3:35:14 AM CEST Alan Curry wrote:
> [1.] One line summary of the problem:
> network data corruption (bisected to e5a4b0bb803b)
>
> [2.] Full description of the problem/report:
> Note: although my bisect ended at a commit from before 3.19, I have the
> same symptom in all newer kernels I've tried, up to 4.6.4.
>
> The commit was:
>
> >commit e5a4b0bb803b39a36478451eae53a880d2663d5b
> >Author: Al Viro <viro@zeniv.linux.org.uk>
> >Date: Mon Nov 24 18:17:55 2014 -0500
> >
> > switch memcpy_to_msg() and skb_copy{,_and_csum}_datagram_msg() to primitives
>
> The symptom is that downloaded files (http, ftp, and probably other
> protocols) have small corrupted segments (about 1-2 kilobytes long) in
> random locations. Only downloads that sustain a high speed for at least a
> few seconds are corrupted. Anything small enough to be received in less
> than about 5 seconds is not affected.
>
> If I download the same file twice in a row, the corruption is in different
> places in each copy.
>
> If I try to do a git clone, it fails a few seconds into the "Receiving
> objects" stage with a deflate error.
Thanks for the detailed bug-report. I looked around the web to see if it
was already reported or not. If found that this issue was reported before:
[0], [1] and [2] by the same person (CC'ed). One difference is that the
reporter had this issue with rsync on multiple SPARC systems. I ran a
git grep on a 4.7.0-rc7+ (wt-2016-07-21-15-g97bd3b0). But it didn't find
any patches directly referencing the commit. I'm not sure if this issue
has been fixed by now or not. I would greatly appreciate any comment
about this from the "people of netdev" (Al Viro? Alex Mcwhirter?).
As for carl9170: I'm not sure what the driver or firmware can do about
this at this time. You can try to disable the hardware crypto by setting
nohwcrypt via the module option. However, this might not do anything at all.
> [3.] Keywords: networking, carl9170
>
> [4.] Kernel information
> [4.1.] Kernel version (from /proc/version):
> Multiple versions are known to be affected, from 3.19 to 4.6.4
>
> [4.2.] Kernel .config file:
> For testing I built with make x86_64_defconfig followed by enabling the
> carl9170 driver, which adds these lines:
> CONFIG_ATH_COMMON=m
> CONFIG_ATH_CARDS=m
> CONFIG_CARL9170=m
> CONFIG_CARL9170_LEDS=y
> CONFIG_CARL9170_WPC=y
>
> [5.] Most recent kernel version which did not have the bug:
> That would be the predecessor of e5a4b0bb803b39a36478451eae53a880d2663d5b
> which is v3.18-rc6-1620-g17836394e578
>
> [6.] no Oops
>
> [7.] A small shell script or example program which triggers the
> problem (if possible)
>
> This command fails reliably for me when running an affected kernel:
>
> git clone git://git.kernel.org/pub/scm/git/git.git
>
> (I'm including all the standard format stuff suggested by REPORTING-BUGS,
> but I think you can skip from here to section 8.7 without missing anything
> relevant)
Yes, I removed it for the most part. If anyone is interested in the details:
Here's a link to the original post @LKML [3].
>
> [8.] Environment
> [8.1.] Software (add the output of the ver_linux script here)
>
> Mostly Debian 8.5 stable packages here.
>
> [8.3.] Module information (from /proc/modules):
>
> When I tested with the x86_64_defconfig + carl9170 kernel, there were
> hardly any modules built, and I reproduced the problem after booting with
> init=/bin/sh, so no unnecessary modules were loaded. Currently running a
> normal 4.6.4 kernel which is showing the bug.
>
> [...]
> [8.7.] Other information that might be relevant to the problem
> (please look in /proc and include all information that you
> think to be relevant):
>
> lsusb identifies my network device as:
>
> Bus 005 Device 004: ID 0cf3:1002 Atheros Communications, Inc. TP-Link TL-WN821N v2 802.11n [Atheros AR9170]
>
> I have version 1.9.9 of carl9170-1.fw in /lib/firmware
Just one additional question: Is the TL-WN821N connected to a USB3 port?
Regards,
Christian
[0] <https://lists.debian.org/debian-sparc/2016/06/msg00160.html>
[1] <https://marc.info/?l=gentoo-sparc&m=145766845820114&w=2>
[2] <http://permalink.gmane.org/gmane.linux.ports.sparc/22507>
[3] <https://lkml.org/lkml/2016/7/23/184>
^ permalink raw reply
* Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
From: Al Viro @ 2016-07-24 19:02 UTC (permalink / raw)
To: Christian Lamparter
Cc: Alan Curry, linux-wireless, netdev, linux-kernel, alexmcwhirter
In-Reply-To: <1659922.nTqITfJpFk@debian64>
On Sun, Jul 24, 2016 at 07:45:13PM +0200, Christian Lamparter wrote:
> > The symptom is that downloaded files (http, ftp, and probably other
> > protocols) have small corrupted segments (about 1-2 kilobytes long) in
> > random locations. Only downloads that sustain a high speed for at least a
> > few seconds are corrupted. Anything small enough to be received in less
> > than about 5 seconds is not affected.
Can that sucker be reproduced with netcat? That would eliminate all issues
with multi-iovec recvmsg(2), narrowing the things down quite bit.
Another thing (and if that works, it's *NOT* a proper fix - it would be
papering over the problem, but at least it would show where to look for
it) - try (on top of mainline) the following delta:
diff --git a/net/core/datagram.c b/net/core/datagram.c
index b7de71f..0ee5995 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -734,7 +734,7 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
if (!chunk)
return 0;
- if (msg_data_left(msg) < chunk) {
+ if (iov_iter_single_seg_count(&msg->msg_iter) < chunk) {
if (__skb_checksum_complete(skb))
goto csum_error;
if (skb_copy_datagram_msg(skb, hlen, msg, chunk))
^ permalink raw reply related
* [PATCH 0/3] staging: wilc1000: Fine-tuning for two function implementations
From: SF Markus Elfring @ 2016-07-24 20:15 UTC (permalink / raw)
To: linux-wireless, devel, Austin Shin, Chris Park, Glen Lee,
Greg Kroah-Hartman, Johnny Kim, Leo Kim, Tony Cho
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <558EB32E.6090003@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Further update suggestions were taken into account
after a patch was applied from static source code analysis.
Markus Elfring (3):
Delete an unnecessary check before the function call "release_firmware"
One function call less in mac_ioctl() after error detection
Reduce scope for a few variables in mac_ioctl()
drivers/staging/wilc1000/linux_wlan.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
--
2.9.2
^ permalink raw reply
* [PATCH 1/3] staging: wilc1000: Delete an unnecessary check before the function call "release_firmware"
From: SF Markus Elfring @ 2016-07-24 20:20 UTC (permalink / raw)
To: linux-wireless, devel, Austin Shin, Chris Park, Glen Lee,
Greg Kroah-Hartman, Johnny Kim, Leo Kim, Tony Cho
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <dbc8c4f3-a234-9b6a-b6a4-9c7ef45d5d31@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Jul 2016 21:00:20 +0200
The release_firmware() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/staging/wilc1000/linux_wlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
index 3a66255..cdef645 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1223,7 +1223,7 @@ void wilc_netdev_cleanup(struct wilc *wilc)
vif[i] = netdev_priv(wilc->vif[i]->ndev);
}
- if (wilc && wilc->firmware) {
+ if (wilc) {
release_firmware(wilc->firmware);
wilc->firmware = NULL;
}
--
2.9.2
^ permalink raw reply related
* [PATCH 2/3] staging: wilc1000: One function call less in mac_ioctl() after error detection
From: SF Markus Elfring @ 2016-07-24 20:22 UTC (permalink / raw)
To: linux-wireless, devel, Austin Shin, Chris Park, Glen Lee,
Greg Kroah-Hartman, Johnny Kim, Leo Kim, Tony Cho
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <dbc8c4f3-a234-9b6a-b6a4-9c7ef45d5d31@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Jul 2016 21:15:23 +0200
The kfree() function was called in two cases by the mac_ioctl() function
during error handling even if the passed variable did not contain a pointer
for a valid data item.
Improve this implementation detail by the introduction of another
jump label.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/staging/wilc1000/linux_wlan.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
index cdef645..7b1ebcc 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1130,7 +1130,7 @@ static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
if (copy_to_user(wrq->u.data.pointer, buff, size)) {
netdev_err(ndev, "failed to copy\n");
ret = -EFAULT;
- goto done;
+ goto free_buffer;
}
}
}
@@ -1144,11 +1144,9 @@ static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
goto done;
}
}
-
-done:
-
+free_buffer:
kfree(buff);
-
+done:
return ret;
}
--
2.9.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox