Please provide updated Thunderbolt NVM on LVFS for XPS 9370
Closed this issue · 32 comments
The Thunderbolt NVM on LVFS has been last updated in January, and has version 28:
https://fwupd.org/lvfs/device/4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
While the Dell website was updated in June and has a Windows installer for version 33:
https://www.dell.com/support/home/us/en/19/drivers/driversdetails?driverId=CV9CP
Please provide the updated version on LVFS as well.
I also asked for this on the support forum but got no reply: https://www.dell.com/community/Linux-Developer-Systems/Please-provide-updated-Thunderbolt-NVM-for-Dell-XPS-9370/td-p/6104414
Can you please test this? It's been added to the testing metadata, so you may need to manually download it or enable the testing remote.
https://fwupd.org/downloads/925aaf439fc1b66aea20fb3868534e3853902c9d-ThunderboltFirmwareUpdateLinux_4.33.18.004.cab
@superm1 Thanks for the prompt response. I'm running on Fedora so YMMV on Ubuntu, but let me share what I got.
I enabled lvfs-testing by editing /etc/fwupd/remotes.d/lvfs-testing.conf and setting Enabled=true but gnome-software does not find it. However gnome-software is known to be flaky with this, so I then used the fwupdmgr command line, which worked.
fwupdmgr refresh
fwupdmgr updateOutput is:
Specified firmware is already installed '0.1.4.0'
Downloading 33.00 for XPS 9370 Thunderbolt Controller...
Fetching firmware https://fwupd.org/downloads/925aaf439fc1b66aea20fb3868534e3853902c9d-ThunderboltFirmwareUpdateLinux_4.33.18.004.cab
Downloading… [***************************************]
Updating 33.00 on XPS 9370 Thunderbolt Controller...
Decompressing… [***************************************]
Authenticating… [***************************************]
Restarting device… [***************************************]
There was some screen flashing (external screen turned off, then the internal turned on, then internal off external on...) but it seems to be working.
fwupdmgr get-devices tells me the following now:
XPS 13 9370 System Firmware
DeviceId: 8a21cacfb0a8d2b30c5ee9290eb71db021619f8b
Guid: 7ceaf7a8-0611-4480-9e30-64d8de420c7c
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a
Plugin: uefi
Flags: internal|updatable|require-ac|supported|registered|needs-reboot
Version: 0.1.4.0
VersionLowest: 0.1.4.0
Icon: computer
Created: 2018-07-06
XPS 9370 Thunderbolt Controller
DeviceId: ec5934ab8dd8b133ffb810f4d6de1c4c33fa16a0
Guid: 4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
Summary: Unmatched performance for high-speed I/O
Plugin: thunderbolt
Flags: internal|updatable|supported|registered
Vendor: Dell
VendorId: TBT:0x00D4
Version: 33.00
Icon: computer
Created: 2018-07-06
Modified: 2018-07-06
UpdateState: success
After a reboot I got this:
XPS 13 9370 Thunderbolt Controller
DeviceId: ec5934ab8dd8b133ffb810f4d6de1c4c33fa16a0
Guid: 4d86f168-e1cc-5995-afd3-ae9df6a14f5e
Guid: 4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
Summary: Unmatched performance for high-speed I/O
Plugin: thunderbolt
Flags: internal|updatable|supported|registered
Vendor: Dell
VendorId: TBT:0x00D4
Version: 00.00
Icon: computer
Created: 2018-07-06
Now it seems to think it's version 00.00 and running fwupdmgr update again reflashes it to 33.00 again.
Further observations:
- After turning it off and on again (instead of rebooting), it says
33.00correctly. - When I boot the machine with nothing plugged into either Thunderbolt ports,
fwupdmgr get-deviceswon't see the Thunderbolt device. - In fact sometimes when the ports are not in use, the Thunderbolt device simply disappears from
lspcientirely a little while after bootup.
@Venemo Would you please mind to share a bunch of things:
- Verbose output from fwupd daemon (
-v)? I'd like to confirm if anything looks awry. - Your current BIOS settings for Thunderbolt (what security level, do you have Thunderbolt boot support enabled, etc).
- A
dmesgoutput from an instance that it shows up with00.00
Regarding your observations:
Now it seems to think it's version 00.00 and running fwupdmgr update again reflashes it to 33.00 again.
The only time I've heard of this is when we've hypothesized there has been a race condition with turning off force power using intel-wmi-thunderbolt. I've never seen it first hand, but we've discussed increasing the timeout delay for this reason. If you can readily reproduce it I think your logs will help determine if that's correct.
After turning it off and on again (instead of rebooting), it says 33.00 correctly.
That's consistently working now?
When I boot the machine with nothing plugged into either Thunderbolt ports, fwupdmgr get-devices won't see the Thunderbolt device.
What kernel version are you using? Do you have the intel-wmi-thunderbolt module available?
In fact sometimes when the ports are not in use, the Thunderbolt device simply disappears from lspci entirely a little while after bootup.
That's expected behavior. The thunderbolt controller will power off when not in use.
@superm1 Sure, here you go:
Verbose output from fwupd daemon (-v)? I'd like to confirm if anything looks awry.
[root@timur-xps ~]# fwupdmgr get-devices -v
XPS 13 9370 System Firmware
DeviceId: 8a21cacfb0a8d2b30c5ee9290eb71db021619f8b
Guid: 7ceaf7a8-0611-4480-9e30-64d8de420c7c
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a
Plugin: uefi
Flags: internal|updatable|require-ac|supported|registered|needs-reboot
Version: 0.1.4.0
VersionLowest: 0.1.4.0
Icon: computer
Created: 2018-07-06
XPS 13 9370 Thunderbolt Controller
DeviceId: ec5934ab8dd8b133ffb810f4d6de1c4c33fa16a0
Guid: 4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
Summary: Unmatched performance for high-speed I/O
Plugin: thunderbolt
Flags: internal|updatable|supported|registered
Vendor: Dell
VendorId: TBT:0x00D4
Version: 33.00
Icon: computer
Created: 2018-07-06
(fwupdmgr:4918): Fu-DEBUG: 00:02:09.996: no unreported devices
[root@timur-xps ~]#
Your current BIOS settings for Thunderbolt (what security level, do you have Thunderbolt boot support enabled, etc).
Thunderbolt is enabled, thunderbolt boot is disabled, and "no security" is set. (Btw, is there a command to get this from smbios?)
A dmesg output from an instance that it shows up with 00.00
EDIT: sorry, I don't have it. Maybe if I downgraded to the previous version and then upgraded to the latest again, it would happen again. But not sure how to do that.
If you can readily reproduce it I think your logs will help determine if that's correct.
I've definitely seen this when I upgraded from the factory version to 28.00 but honestly not sure how I did it. At that time I think I just used gnome-software to upgrade.
That's consistently working now?
Yes.
What kernel version are you using?
[root@timur-xps ~]# uname -a
Linux timur-xps 4.17.3-200.fc28.x86_64 #1 SMP Fri Jun 29 20:50:32 CEST 2018 x86_64 x86_64 x86_64 GNU/Linux
Do you have the intel-wmi-thunderbolt module available?
[root@timur-xps ~]# lsmod | grep thunder
thunderbolt 143360 0
intel_wmi_thunderbolt 16384 0
wmi 32768 5 intel_wmi_thunderbolt,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
That's expected behavior. The thunderbolt controller will power off when not in use.
When is it considered "in use"? Only when I have a Thunderbolt 3 peripheral connected or anytime when there is something plugged into those two ports? Currently I've got this thing connected on one port (but I think it's too cheap to be real Thunderbolt) and a Type-C to DisplayPort cable to the other.
Uh...
One more thing, while we are at it. This is off-topic here and unrelated to Thunderbolt but I'm not sure what is the proper channel for asking about it. Can you please take a look at this? https://www.dell.com/community/Linux-Developer-Systems/How-to-update-the-SSD-firmware-of-the-9370/m-p/6098121
@superm1 Edited my previous post. The dmesg that I posted was a normal one, not from an instance when it was 00.00 - sorry.
Verbose output from fwupd daemon (-v)? I'd like to confirm if anything looks awry.
Sorry I meant the daemon. As in either modify the systemd unit for fwupd.service or manually launch the executable it uses with -v
Do you have the intel-wmi-thunderbolt module available?
It looks like it is in use and loaded. I want to see the fwupd log though to see what happens with it's use.
When is it considered "in use"? Only when I have a Thunderbolt 3 peripheral connected or anytime when there is something plugged into those two ports? Currently I've got this thing connected on one port (but I think it's too cheap to be real Thunderbolt) and a Type-C to DisplayPort cable to the other.
It depends on what alternate mode was negotiated and which port your're using for what's going to happen. I believe it's likely that if you have something that's doing USB 3.x you're going to have to have the TBT controller spun up because the 3.x signal comes from the TBT controller if i'm not mistaken on that notebook.
One more thing, while we are at it. This is off-topic here and unrelated to Thunderbolt but I'm not sure what is the proper channel for asking about it. Can you please take a look at this? https://www.dell.com/community/Linux-Developer-Systems/How-to-update-the-SSD-firmware-of-the-9370/m-p/6098121
Sorry, not currently possible from Linux.
Regarding the right place to ask, you did ask in the right place. Enough people need to be making noise about it though for the social media team to be able to bring it through and make a case.
Sorry I meant the daemon. As in either modify the systemd unit for fwupd.service or manually launch the executable it uses with -v
I did a systemctl stop fwupd and then /usr/libexec/fwupd/fwupd -v let it run for a while and then pasted the output here: https://paste.fedoraproject.org/paste/0ZAOsHLuiKMxIFbI~gZJqQ
Sorry, not currently possible from Linux.
That sounds a bit underwhelming, especially considering that it wouldn't take a lot of effort. I took a look at Toshiba's command line SSD utility (called clout) and it recognizes the drive, just doesn't have the firmware updates. (Not surprising, considering the utility is from 2016.) However it does have an argument to use a raw user-supplied binary.
So it's just a question of extracting the actual firmware from that exe and passing it to the tool. At least that's how it seems. OCZ did have proper Linux support before Toshiba bought them, so maybe if they got a nudge from one of their OEMs, they would pick up the pieces.
(EDIT: yes I extracted the exe but it was unclear which file is the actual firmware and didn't want to flash a random binary to my SSD.)
Regarding the right place to ask, you did ask in the right place. Enough people need to be making noise about it though for the social media team to be able to bring it through and make a case.
Sounds reasonable.
So it's just a question of extracting the actual firmware from that exe and passing it to the tool. At least that's how it seems. OCZ did have proper Linux support before Toshiba bought them, so maybe if they got a nudge from one of their OEMs, they would pick up the pieces.
I don't doubt the existence of a binary only utility that might be able to do it today with the correct payload.
There's more to it than this in terms of building a sustainable method to safely update drives.
As you've probably noticed Dell is supporting fwupd for all the devices supporting firmware update thus far on Linux. This requires implementation in a standards based or open source method. All of the security around firmware delivery is auditable and out in the open. You can update UEFI firmware, Thunderbolt controller, MST controller, and TPM in Dell devices this way. Properly supporting firmware updates for SSD should operate the same way.
Making that happen requires more than just a nudge from an OEM.
I believe it's likely that if you have something that's doing USB 3.x you're going to have to have the TBT controller spun up because the 3.x signal comes from the TBT controller if i'm not mistaken on that notebook.
If you meant the xHCI controller, it doesn't bring up the NHI too. You'll see only the bridges and the xHCI controller (which is usually down, even when a TBT device is connected, as long as there is no USB directly connected).
@superm1 Thank you, point taken.
If you want, I could try to help reproduce the 00.00 problem, but for that I'd need some help with how to reflash the older version of the NVM.
@Venemo I don't believe there is a policy on TBT NVM that will prohibit downgrade. You should be able to flash by using fwupdmgr's downgrade command.
I'm having now th 00.00 problem in my Dell xps 9370.
Every reboot it says theres a new update from 00.00 to 28.00, I apply the update and I get the same "update available" message on next reboot.
Here is my info:
fwupdmgr get-devices
Intel AMT [unprovisioned]
DeviceId: 088df415cdee883ec89563e41e6d495924250174
Guid: 2800f812-b7b4-2d4b-aca8-46e0ff65814c
Summary: Hardware and firmware technology for remote out-of-band management
Plugin: amt
Flags: internal|registered
Vendor: Intel Corporation
Version: 11.8.50
VersionBootloader: 11.8.50
Icon: computer
Created: 2018-07-18
XPS 13 9370 System Firmware
DeviceId: 8a21cacfb0a8d2b30c5ee9290eb71db021619f8b
Guid: 7ceaf7a8-0611-4480-9e30-64d8de420c7c
Plugin: uefi
Flags: internal|updatable|require-ac|supported|registered|needs-reboot
Version: 0.1.4.0
VersionLowest: 0.1.4.0
Icon: computer
Created: 2018-07-18
UHD Graphics 620
DeviceId: 8de6c7959053fd5798006dcc63590d33fa5e51cb
Guid: 8eb8bd2e-0fca-5aba-9aa8-f341e0aa4482
Plugin: udev
Flags: internal|registered
Vendor: Intel Corporation
VendorId: PCI:0x8086
Icon: audio-card
Created: 2018-07-18
XPS 9370 Thunderbolt Controller
DeviceId: 530da46b1b85999b72ed17f9e1c8e9afbf249f35
Guid: 4d86f168-e1cc-5995-afd3-ae9df6a14f5e
Guid: 4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
Summary: Unmatched performance for high-speed I/O
Plugin: thunderbolt
Flags: internal|updatable|supported|registered
Vendor: Dell
VendorId: TBT:0x00D4
Version: 00.00
Icon: computer
Created: 2018-07-18
Unifying Receiver
DeviceId: f36352fbb6865b799fbc2ae575e75ddbfa329163
Guid: 77d843f7-682c-57e8-8e29-584f5b4f52a1
Guid: 9d131a0c-a606-580f-8eda-80587250b8d6
Summary: A miniaturised USB wireless receiver
Plugin: unifying
Flags: updatable|supported|registered
Vendor: Logitech
VendorId: USB:0x046D
Version: RQR12.07_B0029
VersionBootloader: BOT01.02_B0015
Icon: preferences-desktop-keyboard
Created: 2018-07-18
uname -a
Linux xps 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
dmesg : https://pastebin.com/n6sXj0u6
Any more info to help?
@jfisbein if you can please try this PR to see if it helps:
fwupd/fwupd#605
You can generate distro packages following instructions here:
https://github.com/hughsie/fwupd/tree/master/contrib
If it persists, can you please:
- Modify the
fwupd.servicesystemd unit to add-vtoExecStart - Power off your machine and power it back on. See if the behavior continues to happen.
- If it does happen please share the journal output generated by
fwupd.service(the verbose in it will help to see if this timing is still off).
@superm1 In the meantime there is a yet newer version here - released on 24th July. Can you please upload this newer version to fwupd too? Thank you.
Hi @superm1, I'm starting my summer holidays just now, I'll be able to do some test next week.
HI, any news on this?
The problems with thunderbolt and thunderbolt-power identified by this bug are fixed in fwupd 1.1.1 and later. We had fixes to both plugins thanks to these comments.
@Venemo regarding that file uploaded you linked that's a thunderbolt driver not an NVM firmware.
NVM 33 is promoted to stable now though, so thanks everyone for the testing here.
I'm having the 00.00 version issue too, now the v33.00 has been released to the stable channel. Now it's asking to update it again each time I boot the machine.
My fwupd version is 1.0.6 under Ubuntu 18.04.1 with kernel 4.18.5, and I can't find the repo from which update it to 1.1.x. Looks like 1.1.x version is only available in cosmic branch, not bionic.
@AbelVM soon we'll tag 1.0.x a stable release with same patches and SRU that to Ubuntu.
If this behavior is bothering you, you can blacklist thunderbolt plugin in fwupd configuration file.
It just stopped nagging me, without any action on my side. fwupdmgr get-devices now states version 33.00 as expected instead the 00.00 one.
The 00.00 version issue is back :(
The sru still isn't accepted into Ubuntu.
For now you can install the snap instead which will get you a newer version of fwupd.
apt remove fwupd
snap install fwupd --classic
I was experiencing the same problem but it turns out that an after updating the kernel from 4.14 to 4.19 everything started working normally. Maybe this might help other users.