lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 9 Nov 2018 16:36:46 -0800
From:   João Paulo Rechi Vita <jprvita@...il.com>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Luca Coelho <luciano.coelho@...el.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
        Johannes Berg <johannes.berg@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Intel Linux Wireless <linuxwifi@...el.com>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, linux@...lessm.com,
        João Paulo Rechi Vita <jprvita@...lessm.com>
Subject: Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi

Hello Marcel,

On Thu, Nov 8, 2018 at 11:49 PM Marcel Holtmann <marcel@...tmann.org> wrote:
>
> Hi Joao Paulo,
>
> >>>> I think Canonical were facing some wifi fw load error from some 8260
> >>>> earlier module during the BT still loading the fw.
> >>>> I believe we had later 8260 sku that fixed this issue.
> >>>
> >>> But there are already 8260 that is affected by this bug in the wild.
> >>>
> >>> Search "Bluetooth: hci0: Failed to send firmware data (-38)” and there are lots of user are affected.
> >>
> >> which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon.
> >>
> >> So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders.
> >>
> >
> > I have a Lenovo Yoga 900 which presents this problem and has the same bootloader / firmware information as Kai-Heng already posted:
> >
> > [    5.992426] Bluetooth: Core ver 2.22
> > [    5.992438] Bluetooth: HCI device and connection manager initialized
> > [    5.992442] Bluetooth: HCI socket layer initialized
> > [    5.992444] Bluetooth: L2CAP socket layer initialized
> > [    5.992450] Bluetooth: SCO socket layer initialized
> > [    6.004941] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
> > [    6.010922] Bluetooth: hci0: Device revision is 5
> > [    6.010923] Bluetooth: hci0: Secure boot is enabled
> > [    6.010924] Bluetooth: hci0: OTP lock is enabled
> > [    6.010925] Bluetooth: hci0: API lock is enabled
> > [    6.010926] Bluetooth: hci0: Debug lock is disabled
> > [    6.010927] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
> > [    6.014253] bluetooth hci0: firmware: direct-loading firmware intel/ibt-11-5.sfi
> > [    6.014256] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
> > [    6.613961] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> > [    6.613966] Bluetooth: BNEP filters: protocol multicast
> > [    6.613974] Bluetooth: BNEP socket layer initialized
> > [    6.983804] Bluetooth: hci0: Failed to send firmware data (-38)
> >
> > And the following product id and revision, from usb-devices:
> >
> > T:  Bus=01 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
> > D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
> > P:  Vendor=8087 ProdID=0a2b Rev=00.01
> > C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> > I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> >
> > I understand the drawbacks with the approach presented here and lack of clear explanation of the problem, but I can confirm these patches work around the problem on my machine. Is there any extra info or test result I can provide to help debug this? I can also dedicate time to help write a different solution if some guidance is provided.
> >
> > Kai-Heng, did you end up filling a Bugzilla entry for this?
> >
> > Please CC-me on the replies as I'm not receiving emails from linux-bluetooth or linux-wireless anymore.
>
> our hardware teams from the Bluetooth and WiFi side really need to look at this. An inter-dependency between the firmware loading of two otherwise independent drivers is really not what I want to see upstream. However I have no idea which boot loaders are affected or if this is something that might be even possible to be fixed in operational firmware. If you can create a binary btmon trace file with the error happening and getting really every single message from the boot we might get a bit further to understand where it goes wrong.
>

After blacklisting iwlwifi and btusb so they don't get automatically
loaded I started btmon and was able to reproduce the problem by
manually loading the modules with "sudo modprobe iwlwifi & sudo
modprobe btusb". I'm sending the full kernel logs and btsnoop trace
from btmon attached. Let me know if I can provide anything else to
help debug this.

Thanks,

--
João Paulo Rechi Vita
http://about.me/jprvita

View attachment "iwlwifi-btusb-firmware-load-concurrency.log" of type "text/x-log" (78884 bytes)

Download attachment "iwlwifi-btusb-firmware-load-concurrency.btsnoop" of type "application/octet-stream" (588326 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ