All Activity

Despite having windows updates turned off they still force them through. Can’t seem to boot into safe mode (only F2 for BIOS works), no other device available to create a recovery disk. Any ideas? Edit* For some reason the bios had gone back to RST instead of AHCI, switched back and it’s fixed.

i Just tested it and was able to access the Bios in full UEFI whit an external keyboard. If your RTX 5000 cant pull more than 90w, i think its becous of the VBios

You can get the Alienware 17 R1 120Hz, sliderfra has one. It has AVX 2 instructions for the CPU and it's compatible with RTX PEG. You can sell back the M17X R4 if you want or not.

I’d like to upgrade to the best GPU I can if i got a very good deal, but I’m worried about the bottleneck and whether the performance would really be worth it with the 3940XM. I’m also not sure if it’s worth doing the whole 120Hz eDP cable setup and all the other modifications.

At that time I didn’t really know what else I would need to change. My M17x R4 has the 60Hz LVDS display and the 3-pipe heatsink, so I wasn’t sure what would be required for a 3060/4060 upgrade. That’s why the RTX 3000 seemed like the safer option at the time. Unfortunately I don’t think I have any warranty on the 3000.

For that price and with a bit of extra money, you could have bought the RTX 3060 or 4060 MXM! RTX 3000 = RTX 2060 Mobile. I sell an RTX 4070 MXM, compatible with 120Hz M17X R4 and AW17 R1. Any warranty of the 3000?

Here’s the link from ebay https://ebay.io/m/S2OXcM

I bought it back in May as open box condition from ebay for $305, so I don’t really know how it was used before I got it. It worked fine for me and temps were usually around 68–72°C under load, then it suddenly shut off while gaming. And I don’t have a multimeter to check the components🫤.

You should look with the multi-meter, every components then... But is it worth it? Did you buy the card brand new or used? How was it used before?

The black plastic insulation next to the MXM slot is still there. I also insulated the X-bracket area with a tape but the charger still trips. With the RTX removed or the GTX 765M installed, the charger works normally. So it looks more like a short on the RTX board itself.

Can you use some kapton tape to cover the X-bracket metallic zone? And retry? Does your motherboard still have the black plastic filter next to the MXM slot? It's to avoid short-circuit.

I also thought it could be the heatsink, but I tested the RTX installed without the heatsink with the laptop powered off and just plugging in the charger still makes the charger LED shut off. With the RTX removed, or with my GTX 765M installed, the charger works normally. I don’t see any obvious burnt capacitors either. Before it died the GPU was usually around 68–72°C at 96–99% load, so it was performing well and wasn’t heavily thermal throttling. So I’m thinking there may be a short somewhere on the RTX board itself.

Maybe it's shorting between the heatsink and the GPU's components? Happened to me. Make sure to have a properly set heatsink with the correct thermal pads. No burn marks on the tiny capacitors? Was your GPU heavily thermal throttling before? If it's completely dead then... There are options to upgrade to a 120Hz display and to a better RTX 4060/4070 card.

Hi guys, My RTX 3000 suddenly shut the laptop off while gaming. Now the charger LED goes out immediately when I plug it into the laptop with the RTX installed. I tested with battery removed and i had the same issue I removed the RTX and the charger light stays on I plugged in my old 765m in and charger works normally So it looks like the fault is on the RTX 3000 itself. I don’t see any obvious burnt components. Could it be a shorted mosfet or capacitor or vrm component, and is this usually repairable?

A status update on the WHEA-17/PCIe investigation. I would be interested to hear how Fedora 45 Beta or newer (at the time of writing comes with 7.2 kernel), or another Linux distribution, behaves for anyone here with this issue. Intel asked me to test with Linux kernel 7.2. On my Ubuntu setup, I saw no AER messages with 7.2.6, even after PCIe lane-margin testing, whereas I obtained AER reports under 7.0. The margining tool still reported failing results under the test settings used, so the quieter log does not establish that the link’s electrical margin improved. I am keeping those observations separate rather than calling 7.2 a fix. There is an important limitation: the initial tests were not a like-for-like comparison. My earlier 7.2 boot used pcie_aspm=off, and its native AER reporting enables were off, unlike the 7.0 session where AER was demonstrably reporting errors. We therefore need to verify both the power-management configuration and the reporting path before comparing results. An empty error log is inconclusive when error reporting is not operating equivalently. I also looked at Linux commit c855c992, a generic PCI power-management change present in 7.2. It concerns L1.1/L1.2 link substates—not L2—and their configuration around device sleep/wake transitions. The issue was reported with NVIDIA H100 hardware, but the change is in common PCI code. It is not documented as an ARL068 workaround, and I have not established that it explains my results. Intel lists ARL068 for the relevant Core Ultra HX processor family used by the MB16250. However, an erratum applying to a processor family is different from proving that a particular machine’s errors are caused by it. Corrected AER/WHEA events and failing margin results do not, by themselves, identify ARL068. Back in Windows, I captured a burst of 13 corrected WHEA-17 event records during a short session of manual device scans, without running lane margining. That gives us a specific activity to investigate for repeatability, rather than relying only on intermittent freezes. It does not yet establish that scanning caused the errors, identify the faulty component, or prove that Windows is responsible. I have also not established that those corrected events and the freezes share the same cause. Is anyone already running Fedora, Ubuntu or another Linux distribution on their Pro Max 16/18 Plus? I would particularly welcome results from 7.2, but other kernel versions are useful too—especially from people who also see WHEA-17 in Windows. My Ubuntu image booted 7.0.0-30-generic, and I added 7.2.6-070206-generic separately. I am interested in Fedora as a way to test a normally maintained newer kernel, not as a confirmed workaround. Most people here are Windows users, so this is not a request to reinstall or switch operating systems. Anyone already comfortable with Linux could help build a comparison. Reports from machines that do not show the problem would be useful as well. For anyone contributing, the useful details are: Machine/configuration: model, BIOS version, CPU/GPU/SSD models, SSD firmware if known, and whether you were on AC or battery or using a dock. Software/settings: distribution, exact kernel version (uname -r), Windows build for comparison, relevant driver versions or whether the GPU/Wi-Fi drivers are loaded, and any custom PCIe or power-management boot options. Observation: what you were doing, when and for how long, any AER/WHEA records or actual freezes/timeouts, and whether native AER reporting was confirmed active or has not yet been checked. The aim is to establish whether there is a repeatable difference on the same hardware, with comparable settings and working error reporting, and whether other owners see it too. That would give us a stronger test case to take back to Dell and Intel, and to submit through Microsoft Feedback Hub for investigation of the Windows behaviour. I am not claiming Linux has a workaround Microsoft is missing, that ARL068 is the root cause, or that the hardware has been cleared. I would like to turn the observations into evidence that the engineering teams can compare and investigate.

Try with Secure Boot disabled as well. EDIT: In addition, disabling the Above 4GB MMIO BIOS assignment while enabling above 4g decoding should fix the PCI resources error. Resizable BAR option is not visible on my P775TM1.

Do you have above 4g decoding and resizable bar turned on ? In the bios . Might actually fix the issue related to ram .

No you cannot use standard MXM 3.0 b or 3.1b cards in the clevo laptops that have separate power connections . The slots are wired differently

These will not work without a wire mod . Cisco uses proprietary MXM cards ( the wires I forget which ones are reversed but they are related to power or ground ) that's why your cards don't work . You need two clevo / MSI MXM cards with the power connectors . Be aware 3080s draw up to 125 watt . So make sure your cooking is sufficient m I have a single 3080ti in mine . It's a 200 watt monster of a GPU i have a GTX 1060 in there just for emergency in case the 3080 exercise croaks . The laptop will auto switch to pcie MXM 1

I replaced a K5100. The old pads were just fine. They don't degrade, unless you've had water in there, or had it apart before and torn them up. I wouldn't worry about it. Do clean off and replace the grease though, every time that surface separates.

Iam replacing old K3100, i bet these pads are quite not good, i want to have a good heat transfer on the P5000, i was looking at 0.2mm high PTM7950 from Honeywell, they should be alright, right?

I replaced nVidia with nVidia, and reused the same original pads. Seems to work just fine. If you're replacing AMD with nVidia, then I wouldn't know.

I was able to change the edp output but i have no way of testing it with the quadro p4200 cause i brick my m6700s mxm slot when i was adjusting the thermal pads. i copy the code section from the quadro p4000 engineerng vbios to a quadro p4200 oc imac vbios. anyone be interested of trying out this vbios for edp output? P4200_R2test3