From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Mario.Limonciello@dell.com, mika.westerberg@linux.intel.com,
whitequark@whitequark.org, heikki.krogerus@linux.intel.com,
linux-kernel@vger.kernel.org
Subject: Re: A different PD controller firmware problem?
Date: Sat, 10 Nov 2018 15:13:52 -0500 [thread overview]
Message-ID: <20181110201352.GA2203@thunk.org> (raw)
In-Reply-To: <20181108211540.GG1080@thunk.org>
On Thu, Nov 08, 2018 at 04:15:40PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 06:00:59PM +0000, Mario.Limonciello@dell.com wrote:
> > > Sortly after 12:30am US/Eastern, I got a low power warning on my
> > > system, and the battery power had dropped below 10%. Apparently the
> > > laptop was not accepting any charge any more. I tried doing a suspend
> > > to ram, and then unsuspended it, and it still wasn't accepting any
> > > charge, even though the adapter indicated it was plugged in and
> > > supplying power. I then did a power cycle, and still the laptop
> > > didn't indicate it was charging with a USB C 45W power supply plugged
> > > in.
> >
> > Just to be clear was this a Dell adapter or another manufacturer?
> >
> > If it's non-Dell, there could easily be an untested combination of controllers
> > and one getting into a bad state.
It happened again, just now. Unfortunately I didn't have a Dell
charger handy when it did, but it was the same symptoms. One
interesting thing that I did discover is that by observing the voltage
being negotiated via USB-C PD, using a Satechi USB-C power monitor, I
discovered that when the laptop gets into this state, while the laptop
is suspended or powered off, it will negotiate to 5 volts at 3 amps
(assuming the power supply supports it). So apparently the problem is
that the PD controller on the XPS 13 was refusing to negotiate any
other voltage *besides* 5 volts. The fact that it could negotiate 3
amps means that it was doing USB-C PD negotiation; it was just doing
so... badly.
As before, the problem persisted across multiple USB-C power sources,
and I could switch between them so long as the laptop was booted into
Linux, suspended, or powered off but with a power supply attached.
The way the problem got fixed is by unplugging the power supply with
the laptop in a powered of state. Apparently that (and only that)
will reset the problem in the EC or USB-C PD controller.
If there is something that I should try next time (other than trying
to use a Dell USB-C power supply; I'll start carrying it around in the
future), please let me know. I couldn't find any obvious EC Logs that
I could download, unfortunately.
Firmware versions:
<tytso.root@cwcc> {/usr/projects/linux/ext4-fsverity}, level 2 (master)
1008# fwupdmgr get-devices
XPS 13 9370 System Firmware
DeviceId: 8a21cacfb0a8d2b30c5ee9290eb71db021619f8b
Guid: 7ceaf7a8-0611-4480-9e30-64d8de420c7c
Guid: 43ea5588-d9a4-5031-8ad3-308045302d6b
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a
Plugin: uefi
Flags: internal|updatable|require-ac|supported|registered|needs-reboot
Version: 0.1.5.1
VersionLowest: 0.1.5.1
Icon: computer
Created: 2018-11-10
KXG50ZNV1T02 NVMe TOSHIBA 1024GB
DeviceId: f954c7acdf5fab61aeaca1cd71d29ea5ade6992f
Guid: 4d0aed03-a30c-52c6-99e7-a8977797c3d9
Guid: ad9fe8f7-cdc4-52c9-9fea-31b6f4988ffa
Serial: Y77S10C8TYAT
Summary: NVM Express Solid State Drive
Plugin: nvme
Flags: internal|updatable|require-ac|registered|needs-reboot
Vendor: Toshiba America Info Systems
VendorId: NVME:0x1179
Version: AADA4102
Icon: drive-harddisk
Created: 2018-11-10
XPS 13 9370 Thunderbolt Controller
DeviceId: 8885ea984074c84d636e5458d6b6d12649df2e5d
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-11-10
prev parent reply other threads:[~2018-11-10 20:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1e8398f2c1790890f40b69f12e2934e3@whitequark.org>
[not found] ` <20180903140623.GD15112@kuha.fi.intel.com>
[not found] ` <28522bb57c5d8f49416b9174b19b1625@whitequark.org>
2018-09-05 13:24 ` USB type-C altmode support for UCSI Heikki Krogerus
2018-09-05 13:34 ` Mika Westerberg
2018-09-05 13:50 ` Mario.Limonciello
2018-09-05 14:13 ` whitequark
2018-09-07 11:04 ` whitequark
2018-09-10 21:25 ` Mario.Limonciello
2018-09-11 9:32 ` Mika Westerberg
2018-09-11 13:02 ` Mario.Limonciello
2018-10-06 6:01 ` A different PD controller firmware problem? Theodore Y. Ts'o
2018-11-08 18:00 ` Mario.Limonciello
2018-11-08 21:15 ` Theodore Y. Ts'o
2018-11-10 20:13 ` Theodore Y. Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181110201352.GA2203@thunk.org \
--to=tytso@mit.edu \
--cc=Mario.Limonciello@dell.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=whitequark@whitequark.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.