[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D0880587-6660-4DD2-8C20-BCE00AB0CA2E@canonical.com>
Date: Fri, 5 Oct 2018 16:30:41 +0800
From: Kai Heng Feng <kai.heng.feng@...onical.com>
To: Marcel Holtmann <marcel@...tmann.org>
Cc: Matt Chen <mattsled@...il.com>,
Luciano Coelho <luciano.coelho@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Johannes Berg <johannes.berg@...el.com>,
"Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>,
linuxwifi@...el.com, Kalle Valo <kvalo@...eaurora.org>,
"David S. Miller" <davem@...emloft.net>,
linux-wireless <linux-wireless@...r.kernel.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
Hi Marcel,
> On Oct 4, 2018, at 2:25 AM, Marcel Holtmann <marcel@...tmann.org> wrote:
>
> Hi Kai-Heng,
>
>>> 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.
Here’s the dmesg | grep Bluetooth:
[ 6.086600] Bluetooth: Core ver 2.22
[ 6.086618] Bluetooth: HCI device and connection manager initialized
[ 6.086621] Bluetooth: HCI socket layer initialized
[ 6.086625] Bluetooth: L2CAP socket layer initialized
[ 6.086632] Bluetooth: SCO socket layer initialized
[ 6.107794] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[ 6.112803] Bluetooth: hci0: Device revision is 5
[ 6.112805] Bluetooth: hci0: Secure boot is enabled
[ 6.112805] Bluetooth: hci0: OTP lock is enabled
[ 6.112806] Bluetooth: hci0: API lock is enabled
[ 6.112807] Bluetooth: hci0: Debug lock is disabled
[ 6.112808] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[ 6.115231] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
[ 6.210353] Bluetooth: hci0: Failed to send firmware data (-38)
[ 8.153357] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 8.153358] Bluetooth: BNEP filters: protocol multicast
[ 8.153362] Bluetooth: BNEP socket layer initialized
[ 13.563790] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[ 13.568806] Bluetooth: hci0: Device revision is 5
[ 13.568808] Bluetooth: hci0: Secure boot is enabled
[ 13.568809] Bluetooth: hci0: OTP lock is enabled
[ 13.568810] Bluetooth: hci0: API lock is enabled
[ 13.568811] Bluetooth: hci0: Debug lock is disabled
[ 13.568813] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[ 13.569072] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
[ 15.220327] Bluetooth: hci0: Waiting for firmware download to complete
[ 15.220805] Bluetooth: hci0: Firmware loaded in 1618764 usecs
[ 15.220877] Bluetooth: hci0: Waiting for device to boot
[ 15.233031] Bluetooth: hci0: Device booted in 11881 usecs
[ 15.233274] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc
[ 15.236794] Bluetooth: hci0: Applying Intel DDC parameters completed
[ 17.232497] Bluetooth: RFCOMM TTY layer initialized
[ 17.232505] Bluetooth: RFCOMM socket layer initialized
[ 17.232510] Bluetooth: RFCOMM ver 1.11
I’ll file a Bugzilla if we need full dmesg as attachment.
>
> 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.
Apology for the hammer approach, which is the best way I can think of. Of course it’s much better if we can solve this without the ugly hack.
Kai-Heng
>
> Regards
>
> Marcel
>
Powered by blists - more mailing lists