Dell Pro Max 16/18 Plus (2025 model) pre-release discussion — MB16250, MB18250

[yslalan]

https://github.com/LevinAi-arch/rtx-5070ti-laptop-160w-power-limit/releases/tag/v1.8.0

Interesting repo. Just modified a few lines of code to make it work with the RTX PRO. 

 

[SuperMG]

1 hour ago, yslalan said:

https://github.com/LevinAi-arch/rtx-5070ti-laptop-160w-power-limit/releases/tag/v1.8.0

Interesting repo. Just modified a few lines of code to make it work with the RTX PRO. 

 

Hello. Can this work for RTX Ada Lovelace mobile cards? 

 

Because I found this: https://github.com/timmyy123/nvidia-power-control

[yslalan]

Ada and Blackwell should both work. You may just need to add logic to detect the device name properly.

 

27 minutes ago, SuperMG said:

Hello. Can this work for RTX Ada Lovelace mobile cards? 

 

Because I found this: https://github.com/timmyy123/nvidia-power-control

 

[SuperMG]

20 minutes ago, yslalan said:

Ada and Blackwell should both work. You may just need to add logic to detect the device name properly.

 

 

No way my 4090 150W MXM card can do 175W+ easily on my Clevo? But I would get limited by the power resistors (R006)...

 

And power limiting could work too... Back then we used the bugged Nvidia drivers to power limit our mobile GPUs.

[delboi]

I’m investigating this further with the recurrent WHEA-Logger Event 17 / PCIe AER events on a Dell Pro Max 16 Plus MB16250 with Core Ultra 9 285HX. They occur during early Windows boot across multiple unrelated PCIe endpoints: Intel BE200 Wi-Fi, NVMe SSD and NVIDIA GPU.

Raw WHEA/CPER records show the same AER signature:
UncorrectableErrorStatus = 0x100000 = Unsupported Request
CorrectableErrorStatus = 0xa000 = Advisory Non-Fatal + Header Log Overflow

Captured TLP headers decode as PCIe Configuration Read Type 0 requests, apparently probing absent functions/BDFs during early PCI enumeration. Some requests occur only microseconds apart.

Linux PCI enumeration source:
https://github.com/torvalds/linux/blob/master/drivers/pci/probe.c

Linux PCIe AER documentation:
https://www.kernel.org/doc/html/latest/PCI/pcieaer-howto.html

Intel Arrow Lake Series 2 specification update / errata:
https://edc.intel.com/content/www/us/en/design/products/platforms/details/arrow-lake-s/core-ultra-200s-series-processors-specification-update/errata-details/

Relevant Intel erratum: ARL068 — PCIe Gen5 Link Exit from L1 Sub-state Low Power State. It specifically mentions short back-to-back PCIe configuration-space accesses as one trigger condition.

Dell also has an official article stating that boot-time WHEA-Logger ID17 is “expected behavior as per Intel” on certain earlier Intel HX systems. Note that Dell’s listed affected systems are 12th-gen/HX platforms, not the MB16250/285HX, so it does not by itself prove this newer system is expected to behave the same way:
https://www.dell.com/support/kbdoc/en-uk/000216115/laptops-with-12th-gen-and-12th-gen-hx-intel-core-processors-may-display-warning-message-whea-loggerid17

WHEA-17 itself is quite generic, and I think the associated symptoms may be more significant than the event alone. In my case, I’ve seen intermittent freezing and occasional mouse slowdowns. Dell support has also told me that some users experience BSODs or system crashes. What I’m really looking for here is other people’s ideas, observations and possible avenues to investigate

[whyshchuck]

20 hours ago, delboi said:

I’m investigating this further with the recurrent WHEA-Logger Event 17 / PCIe AER events on a Dell Pro Max 16 Plus MB16250 with Core Ultra 9 285HX. They occur during early Windows boot across multiple unrelated PCIe endpoints: Intel BE200 Wi-Fi, NVMe SSD and NVIDIA GPU.

(...)

WHEA-17 itself is quite generic, and I think the associated symptoms may be more significant than the event alone. In my case, I’ve seen intermittent freezing and occasional mouse slowdowns. Dell support has also told me that some users experience BSODs or system crashes. What I’m really looking for here is other people’s ideas, observations and possible avenues to investigate

Answering your hardware-swap question - sibling model here (Pro Max 18 Plus, same 285HX CPU):

- System board (motherboard): replaced. No change.
- Discrete NVIDIA GPU module: physically replaced. No change.
- Whole unit: I was given a different unit (fresh Windows, different RAM/disk/
  panel). Same behaviour returned - and two units showed an identical WHEA-17
  signature side by side.
- BE200 Wi-Fi: not physically removed in my case, so I can't speak to that.

One difference worth noting: my sustained AER doesn't come from Wi-Fi/NVMe/GPU at
boot like yours - it's from the USB4/Thunderbolt host-router downstream port
(PCI\VEN_8086&DEV_5786), i.e. my dock link. So for me the BE200 doesn't look
central, though the common 285HX / ARL068 angle still fits.

Net: board swap, GPU-module swap and a full-unit swap all failed to fix it, which
points at the platform rather than a single removable part.

[delboi]

12 hours ago, whyshchuck said:

Answering your hardware-swap question - sibling model here (Pro Max 18 Plus, same 285HX CPU):

- System board (motherboard): replaced. No change.
- Discrete NVIDIA GPU module: physically replaced. No change.
- Whole unit: I was given a different unit (fresh Windows, different RAM/disk/
  panel). Same behaviour returned - and two units showed an identical WHEA-17
  signature side by side.
- BE200 Wi-Fi: not physically removed in my case, so I can't speak to that.

One difference worth noting: my sustained AER doesn't come from Wi-Fi/NVMe/GPU at
boot like yours - it's from the USB4/Thunderbolt host-router downstream port
(PCI\VEN_8086&DEV_5786), i.e. my dock link. So for me the BE200 doesn't look
central, though the common 285HX / ARL068 angle still fits.

Net: board swap, GPU-module swap and a full-unit swap all failed to fix it, which
points at the platform rather than a single removable part.

Thanks for the response

I am starting to think this is a fault domain which a PCIe signal integrity issue somewhere between:
 

The remaining fault domains are approximately:

1. CPU PCIe Root Complex / Root Port hardware — including the host-side PCIe PHY/receiver.
2. Motherboard PCIe channel — traces, connectors and other physical elements between the Root Port and endpoint.
3. Power delivery affecting the PCIe subsystem.
4. PCIe reference clock / clocking behaviour.
5. Firmware/software-controlled PCIe behaviour — UEFI/BIOS, ACPI/platform power management, link-state management, link training/retraining and related platform configuration.

Your full-unit replacement result is particularly interesting to me because Dell is currently discussing replacing my MB16250 with a Certified Refurbished unit.

Was your original machine new or refurbished, and was the complete replacement Dell supplied new or refurbished? If refurbished, do you know anything about its previous repair history?
 

One concern I have is what Dell's refurbishment validation actually tests at PCIe level. I have been using PCIe Lane Margining at the Receiver (LMR) under Linux as part of my investigation. My understanding is that this interface exists specifically to assess receiver timing/voltage margin rather than merely checking that a PCIe device enumerates, negotiates its expected link speed/width and passes ordinary functional tests.

I don't know whether Dell performs LMR or equivalent PCIe electrical-margin validation as part of its refurbishment/QA process, so I'm not claiming that they don't. But if the validation is primarily functional, I wonder whether a machine with a marginal PCIe path could pass refurbishment testing and only show the problem intermittently in normal use.

I've raised this investigation with Intel as well as Dell, including the WHEA/AER evidence and the Lane Margining results, and I've asked Intel engineering to help interpret the processor/platform side rather than simply treating WHEA-17 as an endpoint failure.

I've also supplied Intel with the Intel CrashLog/PUNIT side of the investigation. We have structurally decoded records containing MTL/NS rev9 and ARL/CDS rev3 data, including reason values 0x24 and 0x09, but we don't have verified public definitions that turn those values and the remaining payload into a diagnosis. I've therefore asked Intel to interpret the complete CrashLog/PUNIT evidence using the appropriate platform definitions, and to assess whether anything there correlates with the PCIe receiver/AER behaviour.

I also approached PCI-SIG about the Lane Margining/AER side. They wouldn't provide technical support directly because that support is a membership benefit, so Intel/Dell and the upstream tooling are currently the routes I'm pursuing.
 

One additional wrinkle: while auditing the Linux pcilmr testing I found an issue in the retained source concerning restoration of the Link Control/ASPM bits after margining. I've raised that upstream rather than ignoring it, because it potentially affects interpretation of some experimental runs. It doesn't explain the spontaneous Windows WHEA history, which predates those tests, but it does mean I'm being careful to separate test-induced/retraining observations from ordinary-use failures.

That's partly why your replacement result interests me so much. If your replacement was refurbished and subsequently reproduced the same class of behaviour, I'd really like to understand what Dell actually validates on these machines before they go back into circulation—particularly whether anything equivalent to PCIe receiver-margin testing is performed.

I did have the USB4 come up even though I'm not using a dock. The field engineer who was asked to exchange the port refused to as it had one system board change already. I am wondering if there is a wider manufacturer defect like the xbox360 red ring one.

Have you ever run Lane Margining at the Receiver on your 285HX machine, particularly the Thunderbolt/USB4 path that reports 8086:5786? If the topology exposes margining-capable host, endpoint or retimer receivers, comparing those results could be very useful.

[delboi]

21 hours ago, whyshchuck said:

Answering your hardware-swap question - sibling model here (Pro Max 18 Plus, same 285HX CPU):

- System board (motherboard): replaced. No change.
- Discrete NVIDIA GPU module: physically replaced. No change.
- Whole unit: I was given a different unit (fresh Windows, different RAM/disk/
  panel). Same behaviour returned - and two units showed an identical WHEA-17
  signature side by side.
- BE200 Wi-Fi: not physically removed in my case, so I can't speak to that.

One difference worth noting: my sustained AER doesn't come from Wi-Fi/NVMe/GPU at
boot like yours - it's from the USB4/Thunderbolt host-router downstream port
(PCI\VEN_8086&DEV_5786), i.e. my dock link. So for me the BE200 doesn't look
central, though the common 285HX / ARL068 angle still fits.

Net: board swap, GPU-module swap and a full-unit swap all failed to fix it, which
points at the platform rather than a single removable part.

Quick follow-up question: I’m located in the UK and curious about the global scope of this issue. If you can share, even broad geographic or continental data would be great. I understand Dell sources different parts regionally (such as keyboards), so I'm wondering why replacement units across regions are experiencing the same failure mode.

If anyone wants to run the PCIe margin test, here are the details: https://www.dell.com/community/en/conversations/dell-pro-max-laptops/pro-max-16-plus-mb16250-pcie-lane-margining-baseline-results/6aaa303258cc775fd9775935

It reminds me of the original Xbox 360 'Red Ring' which stemmed from lead-free solder transitions, factory glue, stress test exacerbating the glue/lead-free solder, and inadequate cooling.