[gshulegaard]

I bought a 9343 XPS 13 on release and it was horrible. Overtime it got better, but on first boot here is a list of issues it had:

* Resume from suspend didn't work and often left machines in an usable state. Relatively simple workaround was to disable suspend but definitely caught you off guard the first couple times.

* Keyboard would insert multiple characters per key press. This made the machine unusable without an external keyboard.

* There was a null pointer issue in the WiFi driver so if you were connected to WiFi but tried to switch networks it would trigger a full blown kernel panic. Workaround was to buy a USB -> Ethernet adapter so you could line in your network.

* Track pad issues to the point that the laptop required an external mouse.

I don't know if I remember all of the issues, but you can dig through the Dell Sputnik forum to find all sorts of old forum posts about issues...here is one from my own post history:

https://www.dell.com/community/Linux-Developer-Systems/Vario...

I spent a lot of time reporting, debugging, fixing, and helping other users try to fix issues in the early days.

In Dell's defense, they upstreamed the fixes so fixing a lot of the issues like resume from suspend and the keyboard was as simple as updating kernels. Additionally, the null pointer WiFi driver bug was fixed in a subsequent driver release.

But these changes didn't get included until several kernel releases later and the only way to unbrick/make the laptop usable was to hotfix/upgrade your kernel to an unstable version. But for a $1500+ laptop to come out of the box in an unusable state was extremely painful for early adopters. And I would say that my experience was far from perfect.

Sounds like they have improved greatly and I am still a tremendous supporter of the Sputnik effort at Dell (and overall fan)...but I (personally) wouldn't dismiss people's comments about it being imperfect.

[contras1970]

that list reads like my typical woes with MS Windows... half the time or more they're caused by the hardware, not the software: ask anyone who does device driver programming.

back in the day (Windows XP era) i bought components and built a gaming computer, nothing extravagant but Windows, because games. there was a very narrow window between the newly installed vanilla OS booting up and BSODing. the problem disappeared once i managed to install drivers from the CD that came with the motherboard (had to act quick before the BSOD would hit).

hardware is crap.

    commit 277918494930ec3fb0c7fdbd4d35060a3bc6d181
    Author: imp <[e-mail]>
    Date:   Thu Oct 25 17:17:11 2018 +0000

        Update comment for AMI00[12]0 override.
     
        The AML is even stupider than always returning 0. It will only return
        non-zero for an OS that reports itself as "Windows 2015", at least
        on the Threadripper board's AML that I've examined.
     
        Those AMLs also suggest we may need this quirk for AMI0030 as well.
        There may be other cases where we need to override the _STA in a
        generic way, so we should consider writing code to do that.

    diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
    index 515370d5584..bed7ecd411c 100644
    --- a/sys/dev/acpica/acpi.c
    +++ b/sys/dev/acpica/acpi.c
    @@ -2222,10 +2222,10 @@ acpi_DeviceIsPresent(device_t dev)
            status = acpi_GetInteger(h, "_STA", &s);
  
            /*
    -        * Onboard serial ports on certain AMD motherboards have an invalid _STA
    -        * method that always returns 0.  Force them to always be treated as present.
    -        *
    -        * This may solely be a quirk of a preproduction BIOS.
    +        * Certain Treadripper boards always returns 0 for FreeBSD because it
    +        * only returns non-zero for the OS string "Windows 2015". Otherwise it
    +        * will return zero. Force them to always be treated as present.
    +        * Beata versions were worse: they always returned 0.
             */
            if (acpi_MatchHid(h, "AMDI0020") || acpi_MatchHid(h, "AMDI0010"))
                    return (TRUE);