I don't know much about xHCI so Mathias can comment on that. I do
remember seeing messages like:
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
in the past but not sure if it is only with ICL. It is also weird that
the TCSS xHCI is doing anything if you plug TBT 3 device since USB
BTW, did you enable any Linux specific configuration in the BIOS? For
example to enable S3 (many systems I've seen default to s2idle
nowadays).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Thanks for the logs. It seems like the BIOS does not handle S3 exit
properly and leaves the Thunderbolt host router unconfigured. I wonder
if there is a BIOS upgrade for this system and have you tried that?
--
You received this bug notification because you are a member of Kernel
Packages, which
Can you also attach full dmesg of the boot so that we can see the
initial PCI configuration? Now all the dmesgs are missing that
information.
When it initially works, do you boot with the dock connected or not?
--
You received this bug notification because you are a member of Kernel
Packages,
On "legacy enumeration" systems, such as this one the BIOS SMI handler
enumerates the PCI bridges before handing off to the OS. The bridges
here are the TBT host router bridges so no need for any authorization.
--
You received this bug notification because you are a member of Kernel
Packages,
Hi, the BIOS is expected to configure the PCI bridges leading to the TBT
controller but it does not seem to do that:
[3.725792] pci :06:00.0: bridge configuration invalid ([bus 00-00]),
reconfiguring
[3.725799] pci :06:01.0: bridge configuration invalid ([bus 00-00]),
#528
Keep in mind that there are two *separate* issues:
1. Bug off-by-one bug in intel-spi driver that causes CMP bit to accidentally
set to 1. This results BIOS
being read-only. The bug was fixed by 9d63f17661e2 ("spi-nor: intel-spi: Fix
broken software sequencing
codes") in
#520, #522
Actually it matters if commit d9018976cdb6 is missing with this
particular BIOS/system because every time you boot the system, the BIOS
resets to default when it finds BCR register is changed. This is
different issue than the CMP=1 issue most of the users have reported.
This one also
#518
Hmm, you already compiled and booted the v4.15-rc7 kernel using my
instructions, right? It should have that fix so booting that kernel
should keep your BIOS working. You can remove the custom patch by
running command "git reset --hard HEAD^". Then you can rebuild and
install it.
--
You
Actually I think I know what is going on. I think the "unpatched" kernel
might miss commit d9018976cdb6 ("mfd: lpc_ich: Do not touch SPI-NOR
write protection bit on Haswell/Broadwell") and in that case the BIOS
resets to defaults each boot.
--
You received this bug notification because you are a
#514
No, this is not the same issue at all. The original "buggy" off-by-one
write never took place because the flash chip does not have that
SPI_NOR_HAS_LOCK bit set in the first place (and it was not there in
v4.13 either). So this is something else.
Christian, do you have Windows there? If
#512
But for the serial flash chip Christian has, the original kernel does
nothing as well (except read the JEDEC ID) so this issue cannot happen.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
#510
That's really weird because in your system both patched and unpatched
kernels are doing exactly the same thing (read JEDEC ID, nothing more).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
#506
Christian, I think you got the patch properly applied but based on the
output your serial flash is "s25fl064k". Looking at the table in
drivers/mtd/spi-nor/spi-nor.c:
{ "s25fl064k", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) }
So this flash chip does not have SPI_NOR_HAS_LOCK and
This is what I typically do when I compile a custom kernel on a new
machine. You need development tools like git, gcc, gmake etc. but I
guess many distros have most of that stuff already installed. I did not
try these so there might be typos and something could be missing.
These steps should help
#493
You can build your own kernel so that you first apply the patch in the
bug description. Then boot to that custom kernel which should clear the
CMP bit from the serial flash and your BIOS should be functional again.
Let me know if you want instructions how to patch and build a custom
kernel.
#474
If you have status register 2 bit 6 set. e.g it reads 0x40 or something
like that, you can just clear that bit and the chip becomes read/write.
For more information about the status register you can find if you find
"w25q64dw" datasheet (or whatever the serial flash chip you have there).
#469
I mean you can clear that one status register bit (CMP) using dediprog
(or any other tool, or software as we do in step 8. fix) and your old
serial flash works just fine.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
#467
The BIOS and the chip are fine, there is only that one bit (CMP, bit 6)
set in the second status register that makes the whole chip read-only.
You can also use some external tools, like dediprog to clear the CMP bit
and the BIOS should work again. The fix in step 8. does the same in
This particular bug cannot affect Dell XPS 13 9350 as it is based on
Skylake and the intel-spi driver does not even support it.
However, in order to boot Linux I think you need at least to switch the
SATA controller to AHCI mode as described in:
Sorry about the delay but we wanted to make sure the proposed fix can
recover the two test systems we have reliably before asking others to
try it.
I've attached a patch to this bug that should fix the still affected
systems. It applies on top of v4.15-rc6 and I'll be sending it upstream
as well.
Can someone who still has the problem try v4.15-rcX kernel instead? It
got few fixes for the atomic sequence handling and might explain why not
all systems recover.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I think the reason why 4.14.x works is because of commit 9d63f17661e2
("spi-nor: intel-spi: Fix broken software sequencing codes").
The current theory is that for certain serial flashes (those
Thunderbolt support for PCs is included in v4.13-rc1 and later kernels.
Do you have a possibility to try the latest mainline kernel?
Note the userspace support is not yet ready so you need to authorize
device manually. See for example:https://www.kernel.org/doc/html/latest
This definitely sounds like a platform/configuration issue rather than a
driver bug.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1708043
Title:
Lenovo X1 Carbon Gen5 fails to resume
All of them are expected to work. Usually the default is "User
authorization".
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1708043
Title:
Lenovo X1 Carbon Gen5 fails to resume
Thanks for the information. I'll go through them.
Aaron, can you try to switch security level of your machine to the same:
Security Level - Display Port and USB
and see if the problem reproduces?
--
You received this bug notification because you are a member of Kernel
Packages, which is
Thanks Aaron. So as expected the Thunderbolt controller is not there.
Only xHCI when USB-C device is connected.
Dean, is there something special you have connected to the machine?
Aaron, who has exactly the same machine and BIOS, can't reproduce the
issue you have reported.
--
You received this
Did you do any settings in BIOS related to Thunderbolt? Sometimes there
is an option called "Force power" which basically turns power on the
controller always. In normal cases that option should be disabled.
Also can you attach acpidump (along with the other things I requeted) of
the system to
Can you also try the attached patch? It should apply on top of
v4.13-rcX. I'm guessing ICM is not running on the Lenovo system so we
should start it but skip all the link reset things. Please post dmesg of
this test as well.
** Patch added: "Start ICM if it is not started"
Also can you attach full dmesg when you boot the system using v4.13-rcX
kernel?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1708043
Title:
Lenovo X1 Carbon Gen5 fails to resume
Dean, just that I understand this correctly. Do you have anything
connected to the Thunderbolt port?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1708043
Title:
Lenovo X1 Carbon Gen5
32 matches
Mail list logo
