Talk:MSI GS65

Unblocking wifi after sleep

When the laptop is resumed from sleep mode the killer wifi card is hard blocked by rfkill. The only way I've found to fix this by pressing the airplane mode key (FN + f10) twice. The suggested methods (using rfkill or reloading the iwlwifi module) don't work for me. Can anyone confirm this? Jorrifransen (talk) 10:47, 23 July 2018 (UTC)

Not to necrobump this thread but I'm posting this here for posterity in case someone stumbles on it with the same issues. I'll be editing the article at some point too.

—

I've digged into the DSDT table and found a way to restore the airplane fn key's functionality and mitigate the radio being forced off after resume from S3, all without having to use acpi_osi or editing the DSDT table. It's fairly straightforward, too, as the radio killswitch is entirely managed by the platform's EC (Embedded Controller).

The DSDT initializes the EC, which, among many things, writes an OS version nibble at offset 0x34. this nibble is determined by _OSI checks, which is why acpi_osi partially fixes the issue (but messes up other things). Crucially, if this nibble is 0x3 or lower (aka "Windows 2009" or lower), the switch's functionality is restored. With no acpi_osi changes, the value should be 0x50. There's also a bit at offset 0x2e which controls the airplane mode. Writing 0x01 at that location disables all radio, while writing 0x09 restores all radio. This can be used to restore wifi and bluetooth automatically upon resuming from sleep.

—

Now, there are a couple ways of writing to the EC:

• Editing the DSDT table to alter the OperationRegion field of the EC's device definition (you could even write your own methods to dynamically control it using ACPI calls at runtime if you're the tinkerer type)
• Writing directly to the EC's memory from userspace during regular OS operation.

I'd say the second method is preferred, because it doesn't require editing the DSDT at all and is easy to setup and modify (most changes will be temporary, however). Especially since there's already a tool for writing to MSI laptop ECs that's mentioned in the article: isw^AUR! It's advertised for controlling fan curves but it can do so much more; indeed, it gives full control over the EC through ec_sys. From here, writing scripts and/or systemd units to automate the whole thing is trivial.

—

Here are the commands you can use:

• restoring the radio killswitch: write 0x30(48)_{Windows 2009} or 0x20(32)_{Windows 2006} at offset 0x34

# isw -s 0x34 48

• toggling radio devices: write 1 (disable) or 9 (enable) at offset 0x2e

# isw -s 0x2e 9

—

EDIT: after more testing on my end, it seems simply setting byte 0x34 to 0x30/48 is enough to nullify the disabling of wifi after waking from sleep. Not sure, but I haven't observed the wifi being hardblocked on S3 wake as long as that byte has that value. Confusing! Being able to programmatically toggle the firmware switch is still something that may be useful, though.

—

You can then easily write a small systemd unit (or edit the one that comes with isw) to automate this:

[Unit]
After=sleep.target

[Service]
Type=oneshot
ExecStart=isw -s 0x34 48
ExecStart=isw -s 0x2e 9

[Install]
WantedBy=multi-user.target sleep.target

Be careful when writing to the EC, though. Some memory locations persist between boots and require flushing the EC RAM to reset. Also, these offsets are based on the EC in my own GS65 Stealth Thin 8RF with EC firmware version 16Q2EMS1.105. They should be identical for you but do check that the values at these offsets are congruent with the ones I've given above before touching anything using isw -c to dump out the EC's RAM.

—

Closing notes: disabling the radios using the killswitch is kind of jank, because some drivers don't really like having devices hard-disabled from under their noses during operation. most of the time they recover fine, but I've had some weird stuff happening, like the bluetooth module falling off the usb bus and never coming back until reboot, or the wifi having trouble autoreconnecting to my network. There's more stuff that could be done to make it more reliable, udev rules maybe? idk.

There'd be value in continuing to dig into the tables and the EC to find why the radios get disabled when sleeping in the first place, as well as any other little nuisance that could be fixed, but I get that most people don't exactly derive pleasure from looking at cryptic disassembled ASL for hours, they just want their machine to work. This fix ties up the GS65 linux experience nicely already.

—

I hope this helps someone out there! Idioticacid (talk) 23:24, 16 May 2024 (UTC)

Can't confirm. In my case, the FN + f10 has no effect at all. Do you have a different model? Check the serial number. Is there anything different about your setup? Bwrsandman (talk) 15:05, 23 July 2018 (UTC)

I am using bumblebee with the modesetting and nvidia driver. I'll have to check the serial number later, but it's a model for the dutch market. Jorrifransen (talk) 19:01, 5 August 2018 (UTC)

To get FN + f10 hotkey to work you probably have ACPI_OSI=! ACPI_OSI="Windows 2018" or somesuch in your kernel parameters, then you can trivially unblock WIFI and Bluetooth after suspend. Alu1 (talk) 22:18, 5 September 2018 (UTC)

Well acpi_osi="Windows 2018" worked with BIOS .10D, but now doesn't with .10E. None of these strings work either: sudo strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort. I think the main page should be updated since the suggestions do not work and have not for some time. Alu1 (talk) 20:54, 17 September 2018 (UTC)

Correction acpi_osi=! acpi_osi="Windows 2006" works, 2009 works, BUT 2012, 2013, 2015 do not.Alu1 (talk) 21:15, 17 September 2018 (UTC)

I can confirm that adding acpi_osi=! acpi_osi="Windows 2006" to the kernel parameters indeed fixes the airplane (FN + f10) key. I can also confirm that pressing this key twice will fix the airplane mode wake up. It's not an ideal solution but it's definitely better than hibernating to fix it. Bwrsandman (talk) 02:57, 15 October 2018 (UTC)

Touchpad disabled after sleep

My touchpad is occasionally being disabled after sleep. xinput --list does not show the touchpad at all anymore when this happens. Reloading the psmouse module does not seem to fix this. Is anyone else experiencing this? Jorrifransen (talk) 10:50, 23 July 2018 (UTC)

Haven't seen this happen either. Does pressing fn+f3 do anything? Bwrsandman (talk) 15:05, 23 July 2018 (UTC)

No it does not, I've also tried pressing it twice (like the airplane mode key) but this doesn't work either. Jorrifransen (talk) 19:03, 5 August 2018 (UTC)

I have since begun experiencing this. No clue what causes it. It seems to happen on any os or live cd that I try at random intervals. Bwrsandman (talk) 03:14, 15 October 2018 (UTC)

Did you have TLP enabled? Reikdas (talk) 11:58, 14 April 2019 (UTC)