Proton: Multiple games crash with Ryzen 3xxx

Created on 31 Jul 2019  Â·  115Comments  Â·  Source: ValveSoftware/Proton

There's some reports of users upgrading their hardware to Ryzen 3xxx processors and games that were previously working for them are now failing with SGDT instruction cannot be used by applications. in dmesg and large Proton logs that are mostly full of access violations.

This issue report is to track the general umip compatibility of that processor generation.

References:
https://github.com/ValveSoftware/Proton/issues/1417#issuecomment-516725375
https://github.com/ValveSoftware/Proton/issues/2386#issuecomment-516802877
https://github.com/ValveSoftware/Proton/issues/2909#issuecomment-515681003 https://github.com/ValveSoftware/Proton/issues/2909#issuecomment-516275599

2997

Workaround:
Add clearcpuid=514 as a kernel boot option to disable UMIP support.

Most helpful comment

Last week I sent a kernel patch upstream that adds SGDT/SIDT/SMSW emulation for 64-bit processes, it was merged and should be in v5.4.

Since then, 32-bit apps have been found which use the SLDT instruction (not emulated by the kernel in any mode): steamwebhelper.exe (from Steam for Windows), and GTA IV (launched from Proton).

I'm working on a patch for Wine itself that emulates all instructions for both 32- and 64-bit, so there won't be any need to patch kernels or wait for distributions to backport the kernel patch.

All 115 comments

@kisak-valve hey, I saw you asking someone else for line counts for this issue. Are you still interested in this for some other game ( Devil May Cry 5)? :)
grep c0000005 steam-601150.log | wc -l gives me 903 lines.

Tested this with Monster Hunter World. Same result
"MonsterHunterWo[11594] ip:14dc8d588 sp:227108: SGDT instruction cannot be used by applications." in dmesg

Ryzen 3700X owner. Just installed Fedora 30 today with an updated iso to get around the rdrand instruction bug affecting systemd. Both Monster Hunter World (582010) and Resident Evil 2 (883710) crash at launch. Proton log is 63MB for Monster Hunter World and 1.1GB for Resident Evil 2.

Same results in dmesg:
MonsterHunterWo[5868] ip:14dc8d588 sp:227108: SGDT instruction cannot be used by applications.
re2.exe[7974] ip:15330398d sp:527338: SGDT instruction cannot be used by applications.

I found this, if this helps.

umip is one Intel security function, which protect(#GP exception)
  below instructions in user mode:
    * SGDT - Store Global Descriptor Table
    * SIDT - Store Interrupt Descriptor Table
    * SLDT - Store Local Descriptor Table
    * SMSW - Store Machine Status Word
    * STR - Store Task Register

Ryzen 3700X, Wolfenstein Youngblood :
grep c0000005 steam-1056960.log | wc -l gives 152 lines.
grep exception steam-1056960.log | wc -l gives 907 lines.
[ 9920.972119] umip: Youngblood_x64v[25225] ip:14d481e87 sp:327358: SGDT instruction cannot be used by applications.
I tried GTA V, no problem.

I believe this issue is also happening on the Epic Games store version of Metro Exodus (in case that helps at all) I'm also experiencing it with Shadow of the Tomb raider.

And here I have my shiny new 3600 next to me, ready to install sometime next week... sigh.

AMD pushed out updates to AGESA that fixes RDRAND issue (for example Asrock X570 Taichi got it already). Is SGDT problem related too?

Yeah my board has AGESA 1.0.0.3 ABB update recently. Hope thats the one.

Please post if it fixes that for you or not.

I won't know until sometime next week, believe it or not I'm waiting for this new thermal paste to show up before I install the 3600. Bios is updated in preparation non the less.

I updated the BIOS on my Asus Prime B450M-A to version 1804
Update AGESA 1.0.0.3 Patch AB to improve compatibility;
It doesn't help with Wolfenstein Youngblood.

@poke86: same SGDT issue? Can you please report it to AMD directly? I'm still waiting for my new CPU, so can't do it yet.

UMIP provides fixups/fallbacks for certain instructions, including SGDT. However, this excludes processes in long mode (i.e. 64 bit applications). See the documentation here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/umip.c#n289

So, as far as I can see, everything works as it should and the game or wine is at fault here.

everything works as it should and the game or wine is at fault here.

But they apparently work with older Zen processors, and only Zen 2 is a problem. Why is that?

I flashed my Gigabyte board today with the AGESA 1.0.0.3 update (F42a) and still the same.

have you guys also tried to roll back to proton 4.2-9? 4.11-1 has some issues.

That's a good question, but as far as I can tell, Zen 2 is the first AMD architecture to support UMIP. Does anyone know which Intel CPU architectures support it?

Edit: it certainly isn't available (or enabled) on my Skylake system even though support for it is compiled into the kernel. You can check with dmesg | grep UMIP. It should print "x86/cpu: User Mode Instruction Prevention (UMIP) activated" if it is enabled.

have you guys also tried to roll back to proton 4.2-9? 4.11-1 has some issues.

I tried it with 4.2-9 and 3.16-9 before 4.11-1 came out and it doesn't change anything, for Youngblood at least.

Yeah, I tried older versions of Proton too.

Edit: it certainly isn't available (or enabled) on my Skylake system even though support for it is compiled into the kernel.
You can check with dmesg | grep UMIP. It should print "x86/cpu: User Mode Instruction Prevention (UMIP) activated" if it is enabled.

Nothing on Ryzen 2000 too.

Has someone tried a custom kernel with UMIP disabled?

CONFIG_X86_INTEL_UMIP=n
or
Processor type and feature - Intel User Mode Instruction Prevention

btw the feature isn't available if you disable support for Intel CPUs in the kernel

There also is a chance that UMIP is disabled by firmware/BIOS on many (older?) mainboards and notebooks even though the CPU technically supports it. It's hard to find information about this feature.

It seems "clearcpuid=514" in the Bootoptions should disable UMIP without the need to compile a custom kernel - maybe some zen2 owner could test it?

Maybe Valve could put up a kernel with UMIP disabled on their PPA, like they did for fsync?

Has anyone tried the clearcpuid=514 boot option?
I can't test it, because I can't reboot now.

i am willing to try but do not know how, can you elaborate on where i add that?

when using grub: https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter

i wouldn't make it permanent, but just try it for one boot by pressing "e" and adding it there :)

It looks like the first Intel CPU architecture to support UMIP is Cannonlake. Cannonlake doesn't really exist in practice, so it's not a surprise that nobody has noticed the issue yet.

So i added clearcpuid=514 to my grub and booted and Monster Hunter World launched correctly. It does seem like this is the cause.
Edit -
Assassin's Creed Odyssey also works now.
I am currently running a r9 3900x, 1080ti on pop os

Great, thank you!
I'll try it for Wolfenstein Youngblood when I get home... In 10 hours or so ^^

Is there a way to use this fix without having grub?

Is there a way to use this fix without having grub?

How come you use linux without grub? Are you from the stone age and still use LiLo?

BTW: I'll try the grub tweak tonight, and give soem feedback about it.

Is there a way to use this fix without having grub?

How come you use linux without grub? Are you from the stone age and still use LiLo?

Maybe systemd-boot?

Can anyone try it with Resident Evil 2 Remake, I have to wait for 26 hours to test it.

Is there a way to use this fix without having grub?

How come you use linux without grub? Are you from the stone age and still use LiLo?

Maybe systemd-boot?

Does he use Arch? (since centos/debian/ubuntu/fedora still use grub2)

@ashmonger I use Solus, and it doesn't use grub, in theory it uses goofiboot.

It works with MHW and DMC 5. Should work with RE2, too.
Thanks.

Is there any benefit to use non-grub2 bootloader?

Looks like it's the kernel bug wine or any program shouldn't know this protection and use the empty table.
Probably after that https://marc.info/?l=linux-msdos&m=147876036616306&w=2 they remove the original approach.

I'm not sure that this is a kernel bug, as the point of UMIP is to prevent userspace calling this functions.
I think it's more wine/proton bug that the blocked call yields a crash?

Confirming that adding clearcpuid=514 to kernel boot options now allows Shadow of the Tomb Raider AND Metro Exodus to boot for me.

I had started a wine bug report about this not knowing what the cause was originally.

I've updated with this info.

https://bugs.winehq.org/show_bug.cgi?id=47571

Is there a way to use this fix without having grub?

You'll have to search how to append kernel parameters to whatever boot loader you are using.

Just to be clear, because it seems that some take this as a solution: UMIP is a security feature and disabling it is a workaround at best. Plus, there is a chance that "clearcpuid" will be removed as a boot option in future kernels.

For anyone interested why it's 514, see here. It's surely not a solution, but a workaround.

Hope a proper fix turns up soon.

From here: https://lwn.net/Articles/738209/

When enabled, however, UMIP will change the behavior that certain applications expect from the operating system. For instance, programs running on WineHQ and DOSEMU2 rely on some of these instructions to function.
[...]
In order to not change the behavior of the system (i.e., a SIGSEGV signal should not be generated when using these instructions), this implementation traps the #GP fault generated by the CPU and emulates SGDT, SIDT and SMSW. with dummy returned values. This should be sufficient to not break the applications mentioned above.

Does this mean that workaround is broken and Wine is expecting something else?

Wolfenstein Youngblood runs after applying the workaround.

From here: https://lwn.net/Articles/738209/

When enabled, however, UMIP will change the behavior that certain applications expect from the operating system. For instance, programs running on WineHQ and DOSEMU2 rely on some of these instructions to function.
[...]
In order to not change the behavior of the system (i.e., a SIGSEGV signal should not be generated when using these instructions), this implementation traps the #GP fault generated by the CPU and emulates SGDT, SIDT and SMSW. with dummy returned values. This should be sufficient to not break the applications mentioned above.

Does this mean that workaround is broken and Wine is expecting something else?

I posted this as comment 7 on this thread, based on the error giving a general protection fault it would appear this workaround isn't in place at all - note that that patch was written by an Intel employee, it may be that it was only applied to Intel processors featuring UMIP and AMD hasn't gotten to including theirs in the same workaround.

It's also possible that since this was written the plan changed. I think we would need someone with an Intel Cannon Lake CPU to verify if this is an AMD specific issue or not, as I don't believe any Intel CPUs older than Cannon Lake support UMIP.

The workaround (emulation of instructions) is probably not broken. The UMIP implementation simply elects to not emulate these instructions in 64-bit mode, though. See my post above which links to the source code. Since all affected games appear to be 64-bit, it works exactly as advertised.

I guess the idea behind this is that the emulation should only be needed for legacy 32-bit applications and that more recent 64-bit applications then have a more strict UMIP policy and should be fixed instead.

more recent 64-bit applications then have a more strict UMIP policy and should be fixed instead.

Is that a problem with Wine that's using those instructions, or actual 64-bit games are doing it? There is no way to fix them if the later is the case.

the main question is it 32bit games or 64bit? If it happens for 32bit wine it means kernel bug if it still happens for 64bit wine it means Wine bug.

Same than @poke86, Wolfenstein:Youngblood works fine with the tweak.

I'm using my 3600 now on kernel 5.0.0-21 (popOS) and haven't had any crashes yet. Is this only affecting certain kernel builds?

I'm using my 3600 now on kernel 5.0.0-21 (popOS) and haven't had any crashes yet. Is this only affecting certain kernel builds?

Have you launched any of the games listed in this thread? I have a 3900X and can duplicate it unless I enable the workaround. It's also possible popos has the workaround already but that seems somewhat unlikely given how recent this is.

Sadly I don't have ANY of the games mentioned in this thread :(

Was keen on monster hunter world, next time it goes on special.

I might have GTA5 but thats on rockstars store app or something, been very long time since I even checked..

@jarrard some games still worked fine for me. For instance: Sekiro was entirely playable without the workaround. Examples not working for me were Shadow of the Tomb Raider, Metro Exodus, and I THINK that Far Cry: New Dawn was also affected.

Yeah, it's only a few games. The ones affected on my library are mainly all Capcom games.
Doom 2016, Sekiro etc. all worked w/o the workaround.

After 1 week of troubleshooting I found this haha I was desperate to found a workaround for SOTTR, it is strange that all the other the proton games worked fine without this.

I'm using my 3600 now on kernel 5.0.0-21 (popOS) and haven't had any crashes yet. Is this only affecting certain kernel builds?
no, it is certain proton games, lucky you

Shadow of the Tomb Raider

I have Rise of the Tomb Raider, do you think that might be borked?

Just had a system freeze on my 3600 with warthunder, think my system freezed yesterday also.,

No explanation for freeze.

Can anyone try it with Resident Evil 2 Remake, I have to wait for 26 hours to test it.

The workarounf fixes the problem for me also playing RE:2 Remake. Using manjaro @ 5.2 Kernel with systemd boot.

Also same problem with F1 2019, I have this log in dmesg :
umip: F1_2019.exe[29557] ip:158538f14 sp:2276e8: SGDT instruction cannot be used by applications.

I just thought that I would confirm that with clearcpuid=514 I no longer encounter crash with SoTR or AC:Odyssey.

Did anyone figure out a proper fix for it?

Probably something for Linux 5.4

@jarrard: did you see patches for it?

Not yet, but it looks like Linux kernel 5.3 is pretty much wrapped up.

I'm asking if anyone actually found a solution.

I would like to know also, a proper solution not a workaround that is.

Also, why are games even using this instruction to begin with?

you are sure that kernel is at fault? it looks more like a wine bug. does it happens with native games on linux?

@logan001 https://bugs.winehq.org/show_bug.cgi?id=47571 The WINE developers don't care.
Native games are fine.

Well, the Kernel does what it should - prevent instructions from userland (as the name UMIP implies ^^)
I'm not sure why some windowsgames use these instructions (or is it wine that is mapping it wrong?), but i think wine is the area where this has to be fixed?

well if native games works without problem that i guess wine should fix their software. but first they will blame everybody else as they seems to do and probably they will probably wait for some1 else to fix their software. after all there are so many patches to wine.....

@logan001 https://bugs.winehq.org/show_bug.cgi?id=47571 The WINE developers don't care.
Native games are fine.

well if native games works without problem that i guess wine should fix their software. but first they will blame everybody else as they seems to do and probably they will probably wait for some1 else to fix their software. after all there are so many patches to wine.....

Can we please keep off topic chatter and insults to a minimum? This is a bug report thread, not a discussion forum. Many people are subscribed to the issue to track actual updates and solutions.

On top of that, this is Valve's official bug tracker, the bug was posted by someone affiliated with Valve, and Valve employs multiple Codeweavers employees with commit rights to wine. The idea that 'wine devs don't care' is frankly absurd and insulting.

@Vash63 How is that bug report still UNCONFIRMED?

Does anyone know any progress on this?

Is it possible my initial Wine bug report does not accurately reflect the problem? I don't mean to be impatient. I simply don't want to muddle things by not accurately describing the problem on the wine bug tracker.

I would also be interested in more recent progress on this issue. This is really bad for Ryzen 3000 owners like me as well. A kernel boot parameter is not a sufficient solution I'd choose to put up with, but it may point us in the right direction to fix this issue, right?

The kernel boot parameter simply disables support for that instruction. It doesn't really help fixing the issue the right way.

Yes, but can't the WINE devs implement something to detect the use of this instruction and provide a solution? e.g. ignore the instruction or run a different instruction that fits as a workaround? Not sure about that one at all, but for me it seems like it's in the hands of WINE devs.

I have reproduced the problem with multiple games, and am testing out a kernel patch which I'll send upstream shortly. For now, the clearcpuid=514 kernel argument should be used as a workaround.

I have reproduced the problem with multiple games, and am testing out a kernel patch which I'll send upstream shortly. For now, the clearcpuid=514 kernel argument should be used as a workaround.

Hey, is everything going fine so far? Any more information would be warmly appreciated!

Last week I sent a kernel patch upstream that adds SGDT/SIDT/SMSW emulation for 64-bit processes, it was merged and should be in v5.4.

Since then, 32-bit apps have been found which use the SLDT instruction (not emulated by the kernel in any mode): steamwebhelper.exe (from Steam for Windows), and GTA IV (launched from Proton).

I'm working on a patch for Wine itself that emulates all instructions for both 32- and 64-bit, so there won't be any need to patch kernels or wait for distributions to backport the kernel patch.

This is absolutely fantastic to hear! Great work! Very clean code as well. I like it!

@mrpippy Is there any chance to see it in 5.3?

@mrpippy Is there any chance to see it in 5.3?

No, 5.3 is almost released.

Train Sim World 2020 is also affected. It started crashing after a recent update and applying the clearcpuid=514 workaround allows it to run.

After using clearcpuid=514 I am still getting system crashes when playing World of Tanks, although it is not running in proton but in wine 4.15. I also got this issue after upgrading to Ryzen 3xxx.
https://bugs.winehq.org/show_bug.cgi?id=47768

Last week I sent a kernel patch upstream that adds SGDT/SIDT/SMSW emulation for 64-bit processes, it was merged and should be in v5.4.

Since then, 32-bit apps have been found which use the SLDT instruction (not emulated by the kernel in any mode): steamwebhelper.exe (from Steam for Windows), and GTA IV (launched from Proton).

I'm working on a patch for Wine itself that emulates all instructions for both 32- and 64-bit, so there won't be any need to patch kernels or wait for distributions to backport the kernel patch.

It works with the 5.4rc kernel, thanks.

AMD Ryzen 3800x, Asus C8H, Ubuntu 19.04.
Installed Kernal 5.4.0-050400rc6 using UKUU and Devil May Cry 5 is working again.
*****mrpippy you are amazing*****

The workaround for games that need Media Foundation doesn't seem to work on the 3900x. I searched protondb, and I couldn't find anyone who got it to work using 3900x, however it seems to work for the other 3xxx parts with lower core counts.

I tried using kernel 5.4.0-rc8 and the clearcpuid=514 parameter, and it still didn't solve the issue for me.

Can you manually disable 4 cores or so and test? I think there is a way to do this.

No sure how to disable cores specifically, but I disabled SMT and that fixed it!

Hello @momumi, linux 5.4-rc1+ contains x86/umip: Add emulation (spoofing) for UMIP covered instructions in 64-bit processes as well which means that you are not affected by the issue tracked here and the workaround is not necessary.

Should I open a separate issue for my case then? This issue said This issue report is to track the general compatibility of that processor generation., but I'll open a separate one if that's better.

That's a fair point, when this issue was opened the root cause was unknown and that comment is out of date. I've adjusted it to better reflect the issue tracked here.

A hyperthreading issue is distinctly different from the issue tracked here. You may have some luck tinkering with taskset. Maybe something like taskset -c 0-11 %command% in your game's launch options could have an effect?

That worked too. It seemed to work for any combination of 16 cores or less, so using taskset -c 0-15 command% is a better workaround than disabling SMT.

Not surprised you had this issue, initial threadripper users faced similar problems, even under windows, for certain applications.

Just to report that I'm running Kernel 5.4.5 on ArchLinux with 3700x :

$zgrep -i umip /proc/config.gz            
CONFIG_X86_INTEL_UMIP=y

And just had this issue on AceCombat 7 :

[22743.282370] umip: Ace7Game.exe[70104] ip:14d1c53b2 sp:5ffcc8: SGDT instruction cannot be used by applications.
[22743.282371] umip: Ace7Game.exe[70104] ip:14d1c53b2 sp:5ffcc8: For now, expensive software emulation returns the result.
[22746.478897] umip: Ace7Game.exe[70104] ip:145f8bfcf sp:5f7038: SGDT instruction cannot be used by applications.
[22746.478898] umip: Ace7Game.exe[70104] ip:145f8bfcf sp:5f7038: For now, expensive software emulation returns the result.
[22746.570335] umip: Ace7Game.exe[70104] ip:1471667a5 sp:5ffb40: SGDT instruction cannot be used by applications.
[23098.322609] umip_printk: 35 callbacks suppressed
[23098.322611] umip: Ace7Game.exe[70104] ip:1523bacf3 sp:5fcf88: SGDT instruction cannot be used by applications.
[23098.322613] umip: Ace7Game.exe[70104] ip:1523bacf3 sp:5fcf88: For now, expensive software emulation returns the result.
[23098.387702] umip: Ace7Game.exe[70104] ip:1523bacf3 sp:5fcf08: SGDT instruction cannot be used by applications.
[23098.387704] umip: Ace7Game.exe[70104] ip:1523bacf3 sp:5fcf08: For now, expensive software emulation returns the result.

Yeah been getting some odd system freezes with my 3600 on kernel 5.4.6. Wasn't sure what causes it, should have checked the logs.

@DistantThunder Does the game work normally? The “For now, expensive software emulation returns the result.” line indicates that the kernel emulated the instruction, so Wine and the game shouldn’t even know anything happened.

The messages are annoying though, especially for games that use these instructions a lot.

@mrpippy Hi, sorry to put you on the clock, thanks for looking.

The game completely froze when the issue happened. For now, I disabled exposing the platform's hardware UMIP capability, I'll try to grab a trace with the feature enabled.

Hello, since I upgraded from core i5 2500K to Ryzen 3600X, all Steam games crash at start with Proton 5.x.
I have no problem to launch them with Proton 4.11-12

I tried the clearcpuid=514 trick (it indeed removes "umip" flag from /proc/cpuinfo ) but it does not work to remove the crash for Proton 5.x games.

I tried also 3 kernels with no difference in the result : 5.3.0 (latest official from Ubuntu), 5.4.18-050418-generic, 5.5.2-050502-generic (All test in Ubuntu 19.10)

Hello, since I upgraded from core i5 2500K to Ryzen 3600X, all Steam games crash at start with Proton 5.x.
I have no problem to launch them with Proton 4.11-12

I tried the clearcpuid=514 trick (it indeed removes "umip" flag from /proc/cpuinfo ) but it does not work to remove the crash for Proton 5.x games.

I tried also 3 kernels with no difference in the result : 5.3.0 (latest official from Ubuntu), 5.4.18-050418-generic, 5.5.2-050502-generic (All test in Ubuntu 19.10)

Can't reproduce it on Manjaro with Ryzen 3700X

The workaround for games that need Media Foundation doesn't seem to work on the 3900x. I searched protondb, and I couldn't find anyone who got it to work using 3900x, however it seems to work for the other 3xxx parts with lower core counts.

I tried using kernel 5.4.0-rc8 and the clearcpuid=514 parameter, and it still didn't solve the issue for me.

I have a 3900x. Danganronpa V3 and Monster Hunter World: Iceborn, which both require Media Foundation, are running fine.

I found success using proton-ge-custom 5.1, adding clearcpuid=514 to /etc/default/grub, and using taskset -c 0-11 %command%. proton-ge-custom doesn't have a gamefix for Danganronpa V3 yet but I submitted a PR for it.

taskset -c 0-11

I assume that this is limiting the process to the first 12 threads, or in this case it would be just the 12 cores of the 3900x and not its threads.,

The workaround for games that need Media Foundation doesn't seem to work on the 3900x. I searched protondb, and I couldn't find anyone who got it to work using 3900x, however it seems to work for the other 3xxx parts with lower core counts.
I tried using kernel 5.4.0-rc8 and the clearcpuid=514 parameter, and it still didn't solve the issue for me.

I have a 3900x. Danganronpa V3 and Monster Hunter World: Iceborn, which both require Media Foundation, are running fine.

I found success using proton-ge-custom 5.1, adding clearcpuid=514 to /etc/default/grub, and using taskset -c 0-11 %command%. proton-ge-custom doesn't have a gamefix for Danganronpa V3 yet but I submitted a PR for it.

I was completely wrong. The problem has nothing to do with my Ryzen CPU. It's the RX 5700 XT that does not support the new D9VK included in Proton 5.x

Now I have to pass PROTON_USE_WINED3D=1 %command% to every DX9 game launched with Proton 5.x

Edit : and I finally got rid of this flag too : I already had vulkan installed ... but only for 64bit games !
I just needed to do this for 32bit vulkan.
$ sudo apt install mesa-vulkan-drivers:i386

RX 5700
works for me

You could try AMDVLK, or RADV driver.

i'm running fedora 32 with kernel 5.7.10-201.fc32.x86_64
i'm unable to launch the game, it show a black screen at startup, ryzen 3900x, rx580.

I tried everything, any suggestion?

This bug was seen on my setup as well and the workaround was the huge. I tried many OSes/versions of wine/compiling from source etc. This was the ultimate issue (as the workaround finally resolved the issue). This app (Everquest) worked previously with my different/old hardware. Disabling UMIP worked.
Ryzen 3800x.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

raikirii picture raikirii  Â·  3Comments

AwesamLinux picture AwesamLinux  Â·  3Comments

lucifertdark picture lucifertdark  Â·  3Comments

AwesamLinux picture AwesamLinux  Â·  3Comments

leifmetcalf picture leifmetcalf  Â·  3Comments