XPS 13 9310 WiFi randomly shuts down (AX500-DBS)

I have the same problem on the second day after I received the brand new PC. Sometimes it happens one or two times everyday, sometimes it happens 1 time every 3 days. No idea how to fix it. I write this message using a cable connection.

I think the linux guys may have figured things out better than us.

Something with the motherboard and/or BIOS is not catching the card before booting the system up, so the device manager knows the card is there but not powered on. 

Issue was caused by this udev rule, which I got from here:
ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"
Should have read the sentence about devices not powering up again more closely.

SOURCE: https://bbs.archlinux.org/viewtopic.php?id=261153

This is related to Active State Power Management. 

APM is controlled by BIOS. 

The BIOS disabled it for some reason (for conflicts?).
PCIE requires ASPM but L0s are optional (so L0s might be disabled and only L1 enabled).
The BIOS might not have been programmed for it.
The BIOS is buggy.

PCI Runtime Power Management may also be an issue - This is also BIOS related, no? (If so, this is likely why my thunderbolt ports would not charge two days after receiving my 9310 in the mail.)

00:1c.0 PCI bridge: Intel Corporation Device a0b8 (rev 20) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 123
Bus: primary=00, secondary=56, subordinate=56, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: 8c300000-8c3fffff [size=1M]
Prefetchable memory behind bridge: [disabled]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Dell Device 0991
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [200] L1 PM Substates
Capabilities: [a00] Downstream Port Containment
Kernel driver in use: pcieport

I question this device's ability to play nice with the AX500:

Intel Intel® Platform Controller Hub (PCH) – Device ID (A0B0-A0B3, A0B8-A0BF) Chipset (PCH-LP) PCIe 4.0 at 8GT/s x4 Root Complex
Aug 07, 2020

I did a whole bunch of homework last night. 

Where can I find logs that show what errors are occurring with BIOS, PCI bridge and network card?

Ideas why this is happening:

1. ACPI fudgery with the BIOS
   
   
   
2. PCI Bus not sending voltage fast enough to the ax500 (qca6390) for it to be recognized. Can we change boot priority in BIOS?
   
   
   
3. AX500 does not support S3 power state, or cannot for some reason wake up from S3 power state? Likely drivers or BIOS?

Bus Check. This notification is performed on a device object to indicate to OSPM that it needs to perform a Plug and Play re-enumeration operation on the device tree starting from the point where it has been notified. OSPM will typically perform a full enumeration automatically at boot time, but after system initialization it is the responsibility of the ACPI AML code to notify OSPM whenever a re-enumeration operation is required. The more accurately and closer to the actual change in the device tree the notification can be done, the more efficient the operating system’s response will be; however, it can also be an issue when a device change cannot be confirmed. For example, if the hardware cannot recognize a device change for a particular location during a system sleeping state, it issues a Bus Check notification on wake to inform OSPM that it needs to check the configuration for a device change.

1 Device Check. Used to notify OSPM that the device either appeared or disappeared. If the device has appeared, OSPM will re-enumerate from the parent. If the device has disappeared, OSPM will invalidate the state of the device. OSPM may optimize out re-enumeration. If _DCK is present, then Notify(object,1) is assumed to indicate an undock request. If the device is a bridge, OSPM may reenumerate the bridge and the child bus.

While Linux again, I think this has something to do with all out problems:

https://groups.google.com/g/linux.kernel/c/wjDkOvnOnr0

https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/300-series-chipset-on-package-pch-datasheet-vol-1.pdf

PCI Slot A0B8 that is where the WLAN is-
Power settings under device manager:

Current power state:
D0

Power capabilities:
00000089
PDCAP_D0_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D3_SUPPORTED

Power state mappings:
S0 -> D0
S1 -> Unspecified
S2 -> Unspecified
S3 -> Unspecified
S4 -> D3
S5 -> D3

https://docs.microsoft.com/en-us/windows-hardware/design/images/wifi-1.png

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/wi-fi-power-management-for-modern-standby-platforms

(LINUX) https://github.com/BeastRoms-Devices/kernel_realme_RMX1927/blob/master/Documentation/devicetree/bindings/cnss/cnss-wlan.txt

https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/pci-power-management-and-device-drivers

https://www.mail-archive.com/acpi-bugzilla@lists.sourceforge.net/mail2.html

https://www.mail-archive.com/acpi-bugzilla@lists.sourceforge.net/msg49180.html

https://github.com/BeastRoms-Devices/kernel_realme_RMX1927/blob/master/Documentation/devicetree/bindings/cnss/cnss-wlan.txt

https://lore.kernel.org/lkml/CAA8EJpp7cJO9Dej3uicPA0+BccqVjs=VphDmGSj05t7SeypAfQ@mail.gmail.com/T/

n Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote:
> > > > > > > On 28/01/2021 22:26, Rob Herring wrote:
> > > > > > > > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Some Qualcomm platforms require to power up an external device before
> > > > > > > > > probing the PCI bus. E.g. on RB5 platform the QCA6390 WiFi/BT chip needs
> > > > > > > > > to be powered up before PCIe0 bus is probed. Add a quirk to the
> > > > > > > > > respective PCIe root bridge to attach to the power domain if one is
> > > > > > > > > required, so that the QCA chip is started before scanning the PCIe bus.
> > > > > > > >
> > > > > > > > This is solving a generic problem in a specific driver. It needs to be
> > > > > > > > solved for any PCI host and any device.
> > > > > > >
> > > > > > > Ack. I see your point here.
> > > > > > >
> > > > > > > As this would require porting code from powerpc/spark of-pci code and
> > > > > > > changing pcie port driver to apply power supply before bus probing happens,
> > > > > > > I'd also ask for the comments from PCI maintainers. Will that solution be
> > > > > > > acceptable to you?
> > > > > >
> > > > > > I can't say without seeing the code. I don't know enough about this
> > > > > > scenario to envision how it might look.
> > > > > >
> > > > > > I guess the QCA6390 is a PCIe device? Why does it need to be powered
> > > > > > up before probing? Shouldn't we get a link-up interrupt when it is
> > > > > > powered up so we could probe it then?
> > > > >
> > > > > Not quite. QCA6390 is a multifunction device, with PCIe and serial
> > > > > parts. It has internal power regulators which once enabled will
> > > > > powerup the PCIe, serial and radio parts. There is no need to manage
> > > > > regulators. Once enabled they will automatically handle device
> > > > > suspend/resume, etc.
> > > > >
> > > >
> > > > So what you're saying is that if either the PCI controller or bluetooth
> > > > driver probes these regulators will be turned on, indefinitely?
> > > >
> > > > If so, why do we need a driver to turn them on, rather than just mark
> > > > them as always-on?
> > > >
> > > > What's the timing requirement wrt regulators vs WL_EN/BT_EN?
> > >
> > > According to the documentation I have, they must be enabled right
> > > after enabling powering the chip and they must stay enabled all the
> > > time.
> > >
> >
> > So presumably just marking these things always-on and flipping the GPIO
> > statically won't be good enough due to the lack of control over the
> > timing.
> >
> > This really do look like a simplified case of what we see with the
> > PCIe attached modems, where similar requirements are provided, but also
> > the ability to perform a device specific reset sequence in case the
> > hardware has locked up. I'm slightly worried about the ability of
> > extending your power-domain model to handle the restart operation
> > though.
>
> I think this is an abuse of 'power-domains'. Just define the
> regulators in both WiFi and BT nodes and have each driver enable them.

I think it is too late to enable regulators in the WiFi driver. Even
if I modify the/pci code to register devices basing on the OF nodes
(like we do for PPC and Sparc), necessary link training/hotplug
handling should happen outside of the WiFi driver.

> They're refcounted. If that's still not enough control over the power
> sequencing, then create a 3rd entity to do it, but that doesn't need
> to leak into DT. You already have all the information you need.

From my point of view the proposed design (with three nodes) exactly
represents the hardware: the power-handling part, the WiFi part and
the BT part. If you don't like the power domains, would regulators be
better from your point of view? The "power" device providing a
regulator to be used by the child nodes. For the BT part the regulator
is fine, while for the WiFi...

The major problem with regulators in this case is that they are
typically enabled by the device driver itself, rather than by parent
device/bus code. And in the WiFi driver case the WiFi chip should be
already up and running before probing the ath11k driver.

Maybe it would still be better to take a step back and just introduce
'vcc-child-supply' entry to the pcie-qcom device tree node or to the
PCIe bridge node? This would also cover cases of PCIe mezzanine boards
when the on-mezzanine devices are visible through the PCIe bus, but
the mezzanine is powered by a separate voltage regulator. It would not
be possible to describe child devices in the device tree node, but
rather it would be possible to describe that there might be devices
behind the PCIe bridge, they must be powered on using a referenced
regulator. This starts to sound like a kind of PCI hotplug.

This would result in the following nodes:

pcie0: pci@1c0000 {
compatible = "qcom,pcie-sm8250";
[....]
bridge@0,0 {
compatible = "pci17cb,010b", "linux,regulator-hotplug";
[....]
vcc-children-supply = <&qca6390>;
/* known WiFi card */
};
};

pce1: pci@1c08000 {
compatible = "qcom,pcie-sm8250";
[....]
bridge@1,0 {
compatible = "pci17cb,010b", "linux,regulator-hotplug";
[....]
vcc-children-supply = <&vdc_gpio13>;
/* unpredictable devices on the mezzanine card */
};
};

--
With best wishes
Dmitry

SOURCE:https://www.spinics.net/lists/linux-pci/msg104507.html

PCI devices like QCA6390 have a separate firmware image for the m3
micro-controller. Add support to load the firmware using m3.bin file.

On x86 and other non-qcom platforms, host needs to explicitly tell the firmware
to use the internal sleep clock. Some QCA6390 modules have OTP burnt with
external sleep clock selected, and these modules can't work expectedly unless
firmware selects internal sleep clock.

DELL - HELP US!

Thank you, guys.

I had the same issue today, followed your advice, reset BIOS and I got it!

Hope never see this problem again.

Wow - I cannot believe how painful this experience has been with Dell!  It's March at this point.  I first purchased my initial xps 9310 in December 2020.  I spent countless hours with their tech support and then was escalated to a senior rep who "promised" she was going to fix this well documented issue.  The motherboard was replace as well as the hard drive with on an onsite visit.  Eventually they asked that the laptop be returned to a depot in TX in the US.  They "fixed" the machine and it was returned to me.  A few days later the same random drop of wifi on AX500-DBS driver was happening.  I gave up in frustration and ended up returning my laptop to the retailer.  They were super nice about it and took it back after over 60 days.  

I purchased a BRAND new one about a week ago.  It worked great for a week and now the same issues started happening this morning.  Random wifi drops and the only way to 'fix' them is to go into F2 reboot sequence and do a factory default on the BIOS.  While this fixes the issue temporarily, the drop of connection happens again.  That means a) this is not an isolated issue and b) dell STILL has not fixed this issue after 3 months.  I cannot understand how the can in good conscience sell this laptop and/or acknowledge this known issue and work with Killer to get this resolved.

I have wasted more time than I'd like trying in vain to get this resolved and don't think anyone in Dell management team is listening to their front line reps or the the customers.  This is a $2K USD laptop and consistent wifi isn't too much to ask.

Cajag1 - I have the same problems (See previous messages) but I found that when the wifi went off the only way to get it back was to switch the machine off and restart it. Just doing a restart would not work!!

I have bios 2.0.0 installed in the laptop and have not found it necessary to boot by your method.

Hey @gando1 - first thanks for your note back.

I should have been more clear - I had to restart the laptop and do the F2 - Factory Defaults Bios settings to get the Wifi back up.

Are you saying that after you upgraded to Bios 2.0 the intermittent wifi drop went away?  As a test I've done a clean windows install and upgraded to the 2.0 BIOS as well.  I can come back here and post after a week or so of use to see how it works out.

I have been very frustrated.  In general I like/love this laptop.  I must be nuts b/c after tinkering with the first laptop for almost 3 months, having a tech come in and replace motherboard and PCI HD, sending the unit to TX for a Depot repair - I went out and bought another XPS 9310.  I was so disappointed but not entirely surprised I had the same issues.  

As I said above, I'm going to try and BIOS upgrade and clean windows install and hopefully that will fix it.  

Wifi dropouts still occur with bios 2.0.0 but I cannot tell you the exact circumstances which causes the dropout.

I have found however that by keeping the laptop on mains power and power options on "never put the computer to sleep" +  I never switch the laptop off and I never seem to get any wifi drops . The drops only appear to happen at random times  when using on battery.

When I go to command prompt and run as administrator - type :

netsh wlan show wlanreport

the picture I get on mains power shows wlan drops occasionally but so fast they are not noticed 

On battery it is a totally different picture with lots of dropouts - I still do not know exactly what it means but still trying to work it out

I'm telling everyone - it is the power back on process with the device returning from S3/D3 or S4/D4 sleep and not going back to S1/D1 fast enough or receiving the message to do so. It has to do something with DELL's BIOS in relationship to the INTEL bridge and KILLER (QUALCOMM) Wireless chip. 

When the computer starts from shut down and does not turn Wi-Fi on, it is a very similar problem. The boot sequence does not give the Wi-Fi card enough Time ?AND/OR? Voltage to boot properly due to the Bluetooth chip being on the same bridge. This could change with the advice I copied from the UNIX/LINUX guys on prior posts. 

Dell can fix this, they are just too fonking incompetent or lazy to do so.

I bought this computer (Warranty, hard drive, ram, processor all maxed out) at the end of January and I have been able to use it maybe ten hours since purchasing it in almost 45 days. I regret buying a dell - I have spent more time on the phone with customer service than with my computer working properly since purchasing it. 

Dell, I love your customer service people as they are friendly and professional, but whoever decides on cutting costs on programming time and motherboard development / parts purchasing can go d!3 in a ditch. I have other complaints on recent purchases from dell (xps13 sleeve does not properly close with laptop in it???!) (wd19tb dock will arrive two months [with expedited shipping] after paying for it.) but I will save that for a different thread.

 Have you guys tried uninstalling Killer Control Center? I saw solution with other dell laptop with ax500 having similar problem. The solution posted was uninstall and reinstall ax500 minus the killer central applet.

I have already had service come to me twice and replaced my system board twice and my issue was fixed. This laptop is a nightmare but I need to keep it for work, Now I am dealing with no Wifi in Bios.  {None}  I cannot do a system recover/repair via Wifi anymore, but I was able to before. 

Tried uninstalling killer etc but that did not work (Didn't really expect it to!!)

A lateral thought - as Dell will probably have sold 100's of XPS13 laptops how is it that there is only a handful of people having this problem - over and over again? Could it be anything to do with the ISP or modem ? Just a thought!!

only handful of us chose maxed out 32g version.. on that has this buggy AX500,

Can you goto wifi network adaptor properties in device manager and in power management tab uncheck "allow computer to turn off this device to save power" 

please confirm if solved the wifi adaptor not starting after waking from sleep.. 

I go to Device manager - network adaptors - Killer wifi 6  AX500-DBS  but there is no  power management tab. There are some choices in the advanced tab but none to do with power - any more clues ??

I dont think its an ISP problem.

The same issue described by everyone appeared also in my laptop, XPS 13 9310, 32GB, 1TB.

It has happened two times already since i purchased it on 23/02/2021 and i live in Belgium.

By entering BIOS and resetting there, the adapter is now operational again. 

If you go to device manager, then click on the network adapter and then click on the events tab, you will see how many times the network adapter has failed to start.

For the price of this laptop (in my case 2200€), this is a serious issue. I will wait and see how it will go, otherwise i will ask for a replacement.