PDA

View Full Version : Linux on G20



whatdoesthisbuttondo
02-01-2015, 03:23 PM
Problem solved. Turns out this rig does need a rather new kernel (3.18+), and some kernel parameters to work properly.

I'd suggest going for Fedora21, as it is already shipping with kernel 3.17 on installation media, and currently is on kernel 3.18.9 after updating.

Here's how to install:

1) in bios, set "force primary display to gpu (the nvidia)
2) boot the installation media (use uefi boot) with kernel parameters "pci=nocrs pci=realloc"
3) install as usual (the wifi will only start working after step 5, so use cable connection)
4) add rpmfusion-free and rpmfusion-nonfree repositories
5) update system to latest packages
6) install latest available nvidia driver from rpmfusion according to their instructions !!!DO NOT REBOOT YET!!!
7) disable kernel secure boot, since nvidia drivers are not signed: "sudo mokutil --disable-validation"

You'll have to enter and confirm a password. Then reboot, you'll be promted to enter uefi shim (a blue screen, press any key when asked)

8) in the shim, enter password letters you are asked for, and disable secure boot option.

That's pretty much it, leading to...

9) install steam, start gaming :)


Gaming performance under linux is very solid on this rig, I get same if not slightly better performance as windows (though on windows I'm on "max performance" settings, on linux I use "auto-powersave" and "quality").

Fans are working a little more unsteady under linux, while they are completely quiet when idle (windows has a constant low rpm noise), they do more aggressive "bursts" when system is under load. They'll spin up faster to higher rpm, and then back down, while windows has a constant increase in rpm.

Performance when doing day-to-day work and simple multimedia is way better, the system is a lot more responsive, and it does not for example have the short freezes when playing HQ video streams that occur every 5-6 minutes on my windows installation.

Overall a very nice rig for linux, even though the installation was kind of a hassle.

toronto699
02-01-2015, 03:28 PM
http://rog.asus.com/forum/forumdisplay.php?148-GR-series-console-PCs-and-Tytan-G-CG-Gaming-PCs
g20 threads

whatdoesthisbuttondo
02-01-2015, 06:12 PM
Thanks for your link, I specifically posted here since it is a Linux question.

Just skimming through the G20 threads there, I suppose you are hinting that I should simply return the system immediately and get something else instead?

toronto699
02-01-2015, 07:14 PM
yes I tried to install Linux also , but my major problem was BSODs on 2 G20 machines W 8.1 asus support suggested RMA but since the G20 did not work right out of the box I returned them both as u can see in the G20 thread many problems with the G20
I bought an Alienware X51 instead and I asked questions on the alienware forms before I made my decision to buy

whatdoesthisbuttondo
02-01-2015, 11:28 PM
Alright, thanks for the advice. Turns out I'll have to return the system anyways, as it appears the WiFi adapter is faulty and causing both the routers I tried to do constant roll-overs.

I guess the issue with not detecting the WiFi properly might have something to do with that too.

Too bad really, it does perform better than I expected with my games and I really liked the small form factor.

whatdoesthisbuttondo
02-03-2015, 05:18 AM
Turns out the system reset to get windows back to factory image does not work, and the dealer (understandably) refused to take the thing back.

Looks like I'll be keeping the thing for a while, as the hardware doesn't show signs of giving up soon.

I'll update here with my Linux adventure story on this rig, currently Ubuntu 14.10 is up and running, on a single core (since acpi does not work at all), integrated hd4600 gfx and no wifi.

I have the feeling that this is going to be one hell of an uphill battle though, judging from looking through bios settings, and the amount of trouble for just getting a barebones installation running.

Even running on just one core it is incredibly snappy under Linux though compared to the pre-installed windows with all those "extra value" software addons ;-)

whatdoesthisbuttondo
02-05-2015, 12:55 AM
Still no luck getting the system to run properly. In case another poor soul stumbles upon this journal, probably next to my corpse and a computer showing a blank screen, please arrange for a proper burial and use this information to your advantage.

First thing, you'll probably want to get a basic installation done. This isnt as easy as it sounds, so after making the necessary arrangements for booting your EFI-ready installation media, do this:

- set graphics to force CPU to primary in bios
- plug in monitor to integrated graphics

Now boot your installation media, and pass the kernel parameter "acpi=off", as without this your journey might come to a premature end due to the integrated graphics flooding your logs with gigabytes (not kidding, about 300Mbytes/sec) of ACPI error messages, and potentially rendering the live system unusable.

Installation should work without any major issues, if you want internet you have to plug in a cable though. Booting into your new system, pass "acpi=off" again, and adjust your grub configuration accordingly.

You'll now have a running system, with only a single core due to disabling acpi. You can either stop there and enjoy, or try to get the nvidia gpu running.

If you do continue, go to bios again, and this time force graphics to pcie primary, and plug the cable into your nvidia gpu.

You can do a failsafe check, and continue with the acpi disabled. You'll probably end up in efifb fallback mode and a 1024x768 resolution.

Now try to enable acpi again. If the open-source driver does recognize the gpu properly (at least for the GTX760 variant it does not), you'll have a mostly working system apart from wifi.

I've not yet managed to get the proprietary nvidia driver to work, 331.113 as supplied with Ubuntu 14.04 does not recognize the card either. My attempts at installing a more recent version from nvidia downloads have so far resulted in a FUBARed installation, I'll probably try with Fedora21 next and see what comes out of it.

The_Fox
02-06-2015, 11:13 PM
Hello,

I have a good and a bad message for you. You are not alone with your problem, I had and have it, too.
I completed an apprienticeship as a computer scientist 2 years ago, so I tried to find the source problem and a solution, since I need Ubuntu for my work at home. I bougth that PC, because it has good power efficiecy, looks pretty cool and has good components inside. For 1700€ there should be not such big mistakes, but there are.

By booting from a live CD or starting installation of Linux it fails because of a ACPI Error (You dont need to try other distrubutions, I also tried Ubuntu from 12.04.1 - 14.10, Debian, SteamOS, etc.). The Logfile is spammed with ACPI messages until the disk (or with live CD the RAM) is out of space. Straigth with a SSD that is a big problem twice. I tried to find the thing causing the problem and found it, but its very sobering:

I executed an acpi dump and deassembled it, so I got the acpi/dsdt tables included in the BIOS/UEFI. I looked trough the code and found 2 mistakes:

1. In the Method of choosing the operating system, there is no entry for Linux. There are only entries for:
- Windows 2009 -> Windows 7
- Windows 2012 -> Windows 8
- Windows 2013 -> Windows 8.1

The method is executed and choses the rigth interfaces for the according operating system. There is no Linux entry, but that should in normal usage be no problem because many manufactures doesnt include entrys for linux so linux is in generally compatible to Windows 7 interfaces. The problem is caused by the second mistake:

2. In the acpi/dsdt tables are used windows specific meta-characters and windows specific programming, which the linux-acpi-interpreter cant resolve. The acpi/dsdt tables are not programmed in the common way which is and should be the default way. In contrast they programmed it in the not common windows way.

That second point is causing the problem. Linux based operating systems are not able to access the acpi interface in the rigth way, in the common way, so the only way to run linux at G20 at this moment is to switch acpi off, which is related to other big problems: Hardware is running hot and a higher power consumption -> PC defects in a few months, maybe few years.

This problem also causes your graphics card is not working in linux and your nvidia drivers not finding your graphics card. In the logfiles there is a ACPI problem occured in: [\_SB_.PCI0.GFX0.GSSE]. PCI0.GFX0 is the PCIe interface of the graphics card, so if the ACPI/DSDT table was programmed in the common rigth way, it would also work correct.

There are 2 other correct sultions which would solve it:
1. I patch the acpi/dsdt table by my own and compile it in the latest linux kernel to upgrade my/our ubuntu with it. This is related to a lot of work and to work in acpi much more, to understand and see more than 100 pages of code.
But that I will not do, because when you buy a computer for 1700€/2500$ you should not have to programm your own *** BIOS/UEFI!!!!

Solution:
2. ASUS patches the tables in a BIOS/UEFI Update. This would be the common and normal solution. With a rigth implementation of ACPI in the BIOS/UEFI linux and the grapics card should work very smooth on G20.

I really hope they do so, but I discussed the problem with collegues of mine and we have all the same opinion:
ACPI related bugs in linux happen very often in new ASUS Mainboards and also in a few mainboards from other manufactures (but a lot of asus models particular). Windows 8 was very bad for microsoft, related to the new GUI, and a lot of people said, that they want to try linux now. We are all quite sure, that microsoft payed for that "bug" in new BIOS/UEFI of manufactures. Therefore following original Bill Gates Mail detail from 1999. Thats not a joke, thats a real traceable mail:
Bill Gates Mail detail from 1999 to employees, Microsoft:
“One thing I find myself wondering about is whether we shouldn’t try and make the “ACPI” extensions somehow Windows specific. It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work. Maybe there is no way to avoid this problem but it does bother me. Maybe we could define the APIs so that they work well with NT and not the others even if they are open. Or maybe we could patent something related to this.”

So with the intruduction of the new BIOS -> UEFI in year 2012 it seems that microsoft, which is one of the main developers of UEFI, is reaching it goals. The only hope is that ASUS will patch the BIOS/UEFI, if there are enough people crying for linux. I will send a mail to asus support, but of course the most mails are cancelled with responses, that ASUS doesnt causes the problem, linux is the problem and people which dont have the possibility to search through the code will believe it.

It would be nice, if you and other that have problems with linux would post here a message. So the support will hopefully change their mind.

Best regards,

an angry customer from ASUS for years now.

P.S.: If ASUS really doesnt patch the BIOS/UEFI, I will send it back and never buy something again from ASUS. If ASUS patches it, I can ignore the initial problems with that computer and ASUS, because until now I didnt had any problems with ASUS, yet ;)

whatdoesthisbuttondo
02-06-2015, 11:18 PM
Small update, as of kernel 3.18, the wifi works properly.

Still no dice with the gpu, my investigation so far shows that this is not a driver issue (the drivers itself support that specific gpu just fine), but rather a problem with early boot, the gpu does not have it's IO windows assigned properly, and the drivers naturally do not like this.

This might be a kernel issue, buggy firmware, or both combined. I'm going to switch to the mainline kernel next since there apparently has been some work done on ACPI and PCI as well as similar issues with at least two systems running Radeon gpus being under investigation, from my point of view it makes the most sense to jump on that train as the devs are actively working on these parts, and the 3.18 and below kernels likely won't see much backporting unless it is small fixes.

whatdoesthisbuttondo
02-06-2015, 11:40 PM
The method is executed and choses the rigth interfaces for the according operating system. There is no Linux entry, but that should in normal usage be no problem because many manufactures doesnt include entrys for linux so linux is in generally compatible to Windows 7 interfaces.

That is actually considered "best-practice", the kernel developers themselves discourage vendors from using the Linux identifier.



2. In the acpi/dsdt tables are used windows specific meta-characters and windows specific programming, which the linux-acpi-interpreter cant resolve. The acpi/dsdt tables are not programmed in the common way which is and should be the default way. In contrast they programmed it in the not common windows way.


Found that out as well while investigating the firmware, that is certainly not best-practice, but should not be a critical problem either.



This problem also causes your graphics card is not working in linux and your nvidia drivers not finding your graphics card. In the logfiles there is a ACPI problem occured in: [\_SB_.PCI0.GFX0.GSSE]. PCI0.GFX0 is the PCIe interface of the graphics card, so if the ACPI/DSDT table was programmed in the common rigth way, it would also work correct.


Some random ACPI error messages are quite normal, and not necessary a big issue. That specific one is somewhat related to gpu power management and idle state, it goes away completely if you use the nvidia gpu in fallback mode.

It is still a problem with normal operation on the Intel gpu though, as it will spam the message ring to a point that will flood a 50GB filesystem in a matter of minutes.

The actual problem with the gpu not being recognized is in PCI bridge issue at early boot, it fails to get BARs assigned properly. It is quite possible that ASUS isn't solely responsible for that problem and it is in fact a kernel issue, especially given that similar (possible regression introduced around 3.13 kernel) issues are currently under investigation.



1. I patch the acpi/dsdt table by my own and compile it in the latest linux kernel to upgrade my/our ubuntu with it. This is related to a lot of work and to work in acpi much more, to understand and see more than 100 pages of code.


I've contemplated working on the DSDT myself, but as the system does run somewhat acceptable with full acpi enabled, I'll postpone that for now and focus on the PCI bridge issues.



Solution:
2. ASUS patches the tables in a BIOS/UEFI Update. This would be the common and normal solution. With a rigth implementation of ACPI in the BIOS/UEFI linux and the grapics card should work very smooth on G20.

Couldn't agree more. Especially given that these days, it is not that uncommon to consider a gaming rig with a form factor like this as a CUDA platform.

The_Fox
02-06-2015, 11:51 PM
Hey,

its nice that others with neccessary knwoledge in computers are working on that problem too.

In my angry first post I forgot to write about the WIFI Issue. I also resolved it. Thats randomly not an ASUS problem:
G20 uses relative new RTK8812AE WIFI card. Drivers for it are included in kernel 3.18 but there could be problems, because they are in experimental state. In later kernels there should be no problems with WIFI anymore.

Will write to ASUS support and hope, that you and others will follow up my support request.

whatdoesthisbuttondo
02-07-2015, 12:02 AM
I got to admit, I was severely annoyed when I first tried to get Linux running. I specifically bought the ASUS rig as I've had good past experiences with their hardware, especially my current main laptop, a ZenbookPrime, does work extremely well on Linux, zero issues unlike many other laptops I've used.

Needless to say, with the trouble that the G20 gave me so far (not only Linux, but Windows as well), ASUS dropped down quite a bit on my list when buying the next hardware.



In my angry first post I forgot to write about the WIFI Issue. I also resolved it. Thats randomly not an ASUS problem:
G20 uses relative new RTK8812AE WIFI card. Drivers for it are included in kernel 3.18 but there could be problems, because they are in experimental state. In later kernels there should be no problems with WIFI anymore.

From what I can tell so far, the wifi driver in 3.18 works without issues. It might be beneficial to disable the onboard lan, as that is also known to cause issues on some setups, so I've turned that off in firmware for now.

Good thing is though that 3.19 will bring some ACPI and PCI rework, and there are currently developers working on similar issues, so we might get lucky there. I'll dig into the issue further and try to confirm it is the same problem, and see if I can add to the already existing tickets.

The_Fox
02-08-2015, 04:15 PM
Hello,

I prepared the support request with the neccessary information about the issue and a link to the thread here. Will send it on tuesday.



Found that out as well while investigating the firmware, that is certainly not best-practice, but should not be a critical problem either.

Some random ACPI error messages are quite normal, and not necessary a big issue. That specific one is somewhat related to gpu power management and idle state, it goes away completely if you use the nvidia gpu in fallback mode.

I also thougtht, that the PCIe Bridge could cause problems, since here is a 90 adapter used to put mainboard and full graphics card into that small case and that adapter perhaps is causing trouble, so the nvidia drviers cant find the graphics card through the adapter. Perhaps that could be the problem, in addition to the bad tables.

I think the wrong configuration in the acpi table could cause, that the interface doesnt work properly and so the graphics card or the adapter doesnt get at least enough power to run. In fallback mode I think acpi is disabled, at least a few functions, so that issue is crossed over?

Did you managed it that it runs now? With that GPU issue I sadly have no idea to fix it by myself, besides sending that support request.


I've contemplated working on the DSDT myself, but as the system does run somewhat acceptable with full acpi enabled, I'll postpone that for now and focus on the PCI bridge issues.

What do you mean, that it runs somewhat acceptable with full enabled. You mean after corrected the GPU issue, dont you?
Do you think, if the bridge issue is resolved all other should and will work ok, except the log issue?

If the system would run ok with acpi full enabled and the graphics card is identified in the rigth way to use nvidia drivers, so that you can use it, all I would do is only disabling the logging of that lines or perhaps the other way the logdeamon completely. Do you see any further problems, perhaps that after disabling the logging of these lines with a filter (They are very, very fast logged!) there will be an increased CPU workload, because the syslog filter has to do much work?

How do you think to resolve the GPU problem, how to start or how to investigate that issue? I doesnt really know where or how to start with it?

Best regards,

The_Fox
02-10-2015, 08:25 PM
Hello,

I sent my support request, I hope they will answer soon.

In meantime I tried Kernel 3.19, which was released yesterday. Sadly still no luck. With kernel 3.19 the WiFi card seems to work very good, but still same Issues with the ACPI Errors in the Logfiles and the graphics card. The rigth way is, that they have to patch the BIOS/UEFI. But as I said, there are a lot of other mainboards from ASUS where yuo have a lot of trouble linux.

Does anybody managed to run SteamOS on it? Officially ASUS supports SteamOS on that machine and its linux based. I already tried but failed. If SteamOS will work very well, perhaps we can extraxt its ACPI Interpreter or Tables to compile into kernel?

Best regards,

The_Fox
02-11-2015, 07:37 PM
I got my answer from support.

Despite at official ASUS ROG Site the G20 is advertised as Steam Machine and fully compatible with SteamOS, it is not.
As expected they say, that only Windows8.1 is supported, so all is fine.

F*** ASUS. Will sell it now and never buy anything else from ASUS again...

whatdoesthisbuttondo
02-12-2015, 01:52 PM
Despite at official ASUS ROG Site the G20 is advertised as Steam Machine and fully compatible with SteamOS, it is not.


Can you give me a link where they claim it to be compatible with SteamOS? Where I am living, the system not supporting SteamOS despite such a claim would legally entitle me to a vendor fix or a full refund.

As for SteamOS, it is a Debian (Wheezy) based Linux flavour, currently they are on Kernel 3.10, so I highly doubt that even with the additional firmware SteamOS is shipping, the G20 will support it.

whatdoesthisbuttondo
02-12-2015, 02:11 PM
I also thougtht, that the PCIe Bridge could cause problems, since here is a 90 adapter used to put mainboard and full graphics card into that small case and that adapter perhaps is causing trouble, so the nvidia drviers cant find the graphics card through the adapter. Perhaps that could be the problem, in addition to the bad tables.


Since the conveniently placed warranty sticker does prevent me from taking a closer look at the adapter, this shouldn't be a problem. I've worked with such adapters in the past on a variety on server hardware, those typically are "dumb" adapters boards without any logic components.




What do you mean, that it runs somewhat acceptable with full enabled. You mean after corrected the GPU issue, dont you?
Do you think, if the bridge issue is resolved all other should and will work ok, except the log issue?


Except for the video card issue, with recent kernels there appears to be no other glaring issues, power management (at least the minimal parts ASUS didn't disable in their "optimized" default firmware settings) does work fine, mass storage has no issues, and all other hardware is working as well.

In fact, the system does perform a whole lot better on Linux than the bloatware-ridden Windows installation it ships with.



Do you see any further problems, perhaps that after disabling the logging of these lines with a filter (They are very, very fast logged!) there will be an increased CPU workload, because the syslog filter has to do much work?


The log spam when running under integrated graphics is indeed a problem, I'm seeing around 70% cpu load on a single core due to the sheer speed the messages are generated, and obviously increased fan noise. That issue needs to be resolved at the source, simply filtering them out is not gonna cut it.

However, running on the dedicated GPU does solve that problem somehow, and as the GTX760 does run reasonably cool if it isn't under load I dont see a huge issue there if I can get the card to work.



How do you think to resolve the GPU problem, how to start or how to investigate that issue? I doesnt really know where or how to start with it?


I've been a bit busy with other projects the past few days, so haven't had a chance for in-depth investigation, currently I'm still catching up on the exact implementation of the pci probing and resource allocation with the newer kernels.

Once we know what exactly goes wrong where (not an easy task to debug, as I'm currently limited to collect the relevant data typing blind on a black screen), I see two options to approach this, the good one obviously being a proper generic fix for this and related issues, and the bad one kludging a band-aid fix (possibly as ugly as directly hardcoding the required resource assignments for our problem child into a custom kernel).

The_Fox
02-12-2015, 09:41 PM
Very bad support:

At first I would like to say, that as expected I got no help from asus support and he was even harshly:

In my first response I got the answer, that they dont support any linux distro and SteamOS, but he will send up my technical request to the according team. That answer was friendly and ok, although I think either he didnt sent it up or the team wont care.
Next I asked what to do now, because ASUS advertised it as Steam Machine, at lest "fully compatible with SteamOS". I bougth it for that reson and it doesnt work properly. The Link is here: http://rog.asus.com/325082014/gaming-desktop-pcs/rog-gr8-console-pc-and-g20-small-form-factor-gaming-pc-faq/

Scroll rigth down and in the G20 text is following:

"What OS does it come installed with? Can I run SteamOS?
The GR8 is pre-installed with Windows 8.1 and is fully compatible with SteamOS should users wish to install it.
Will there be a Steam Machine (PC) version?
Yes! When Valve launches its Steam Machine software, ROG will offer a version with SteamOS pre-installed and the Steam controller bundled"

The same sentences are above in the G8 section. Unfortunately in the text here from G20 section is "GR8" written down like above in G8 section. It should be clear, that this is a mistake from copying the same information from G8 to the G20. Unfortunately they will get the law, because exactly GR8 is written down, despite it is in G20 section, all other information are about G20 and it should be clear that the mistake is from copying the information. Furthermore there are a lot of other review pages, which say that you can run SteamOS if you like, but they arent from asus itself. So I think you wont be able to give it back, but perhaps you have a retailer who doesnt want much trouble and gives you your money back, although he doesnt have to. That would be bad for my, because I cant give it back and so I will have to fix it alone :)

I asked the support what to do now with the PC, because I cant use it properly, but I only got an harish answer that the text says only that there will be a bundle with SteamOS in future and that they doesnt support operating systems in beta, like SteamOS.
Doesnt sounds like the official statement in G20 text "The GR8 is pre-installed with Windows 8.1 and is fully compatible with SteamOS should users wish to install it."

After that I wanted to write back, that he doesnt answered my question what to do now with the PC and if I get my money back from asus, but I discovered that he simply closed my support request. Very nice from the support.

Next steps:

At weekend I want to try a few other things. SteamOS, Ubuntu and Devian have all the same kernel. Perhaps there is a distribution which is able to deal better with the issue, if we have luck. I will try mandrivia and openSuse. I will try to run SteamOS properly, too.
Perhaps I have done something wrong at first try with SteamOS. At least when they launch theire bundle of G20 with SteamOS and controller it should run ok and they will have to support it. I doesnt really know why SteamOS should run and Ubuntu, with the same kernel, doesnt. Perhaps we can find the solution in SteamOS then.

The other solution is in future to use SteamOS completely as linux OS. I dont know exactly, however I dont think SteamOS is an full operating system to work with...

Perhaps I can find out something more in weekend. It is disgusting, that after buying a PC for much money you have to work around some issues until you can use it properly with an other operating system. In correct behaviour the hardware should be seperated from software and operating system. Although I am really pissed, I cant give it back and anyway it is a good PC with windows.

I already deleted the restore partition and installed clear fresh windows 8.1 without bloatware and only installed the neccessary drivers. It runs better now, but its windows...
You will have to install at least the WLAN and LAN drivers, since windows doesnt include any internal drivers for that special card.

Best regards,

whatdoesthisbuttondo
02-12-2015, 10:24 PM
Thank you for that link, at least for me and local law, that has me in the good position should I decide to return it. Still like the system and form-factor though, so I'll see if it can't be forced to behave.



I doesnt really know why SteamOS should run and Ubuntu, with the same kernel, doesnt. Perhaps we can find the solution in SteamOS then.


SteamOS in current version does ship with a pretty old kernel, and from reviewing the pci probing and resource allocation against more recent kernels I see there are quite a few differences. Notably, there is also changes in the way of deciding what are valid memory locations for BARs (and in turn created problems with some radeon gpus at the time), which I assumed I had already ruled out as the problem, but I'll look into that again.

Since the kernel that SteamOS ships is also a distribution-specific kernel, it might even be possible there are some non-standard modifications done to it (though I doubt that Valve did fiddle with such integral components), but in any case the source for it is available, so if the secret is burried somewhere in there it can be found.

I'll see what SteamOS has to say about the hardware, and raise a ticket with Valve support too, maybe they are more cooperative in this matter, it is their brand afterall and they should have more interest in handling hardware issues on supposedly compliant platforms.



I already deleted the restore partition and installed clear fresh windows 8.1 without bloatware and only installed the neccessary drivers. It runs better now, but its windows...


Heh, fun thing is, mine came with the restore partition already broken and unusable fresh out of the box. Cost me the better part of a day to get the system running again after Windows decided to go into suicide mode with the borked VirtuWatt, drivers and initial updates.

The_Fox
02-15-2015, 03:22 PM
Found following out:

Install OpenMandriva:
I tried to install OpenMandriva, since its based on the redhat kernel and not on debian kernel. Installation process desnt work due to an ACPI Error, linke other distributions. Before further work on it, I discarded the idea brcause I think it will result at the same point like ubuntu or in other ACPI errors later. I didnt tried OpenSuse because I could bet on it, that it will have the same results.

SteamOS:
Because no other Linux distro is working I tried to install SteamOS as "later official supported" OS.
Funny thing, support response to me was:
1. We doesnt support any other linux distributions than SteamOS!
2. We dont support StemOS, since its in beta!

Alrigth, they dont support any other distro than steamOS and of course they dont support steamOS because beta.
I tried SteamOS and I can tell, that other than described under the official Link:
http://rog.asus.com/325082014/gaming-desktop-pcs/rog-gr8-console-pc-and-g20-small-form-factor-gaming-pc-faq/#G20
its not "fully supported" and deosnt work.

In intallation process I had to switch in UEFI the graphics to CPU only. With Auto or PCI graphics card, it doesnt work. After installation, the graphics still only work with forcing CPU graphics. No chance with the Nvidia graphics card. You can start StemOS witch CPU graphics, but there appears a loud and noisy cheep. At least the kernel and syslog isnt spammed with acpi errors.

So I think SteamOS based on debian kernel has the same PCI graphics problem than all other distributions. The graphics cards isnt working at all. Propabley its caused from the PCI adapter or the graphics power supply or any other F U C K I N G thing, in any case its a problem which can be resolved with an update of the BIOS/UEFI. Because ASUS said they will launch an bundle with SteamOS, when SteamOS is out of beta, the graphics have to work later together with SteamOS and so they will have to fix their UEFI and to release an update.

I belive that with that update the graphics card will work smooth on ubuntu, too. Then it should be possible to install Ubuntu or any other distribution without any problems.

If later Ubuntu will still not work very well, I will install SteamOS when its supported.
SteamOS isnt a full OS for working with the PC, but still better than windows. Since SteamOS is based on debian you can install almost any software from debian packages and so a lot of ubuntu stuff, too.

There is an other problem: SteamOS now is based on debian 3.10 and as expected the G20 WLAN device is not working, since drivers for it are first included in kernel 3.18. It is funny how ASUS will try to resolve that in theire SteamOS bundle. I gave the installation of debian kernel 3.19 in StemOS a shot. Doesnt work, since StemOS will not boot with the new kernel.



So after all I will keep F U C K I N G-windows for a while, until an UEFI update is released and Ubuntu or StemOS work fine with that update. I hope that ASUS will provide the UEFI update before they launch theire SteamOS + G20 bundle, bacause it could take a few more months or perhaps years until SteamOS is ready and they will launch the bundle.
I think that perhaps we will have some more luck with the SteamOS developers than with the very bad asus support, too. It would be nice if you could post the response from StemOS team, if they have some news or they managed it to make SteamOS to run successfull on G20.

Best regards,

whatdoesthisbuttondo
02-17-2015, 07:48 PM
Somewhat good news from the frontlines, seeing I'm writing this from my Ubuntu 14.10 installation, on a nice 1920x1080 resolution using the Geforce GPU, even connected on my WiFi network :cool:

At the moment, I'm using the open-source nouveau driver, so the system isn't exactly ready for hardcore gaming just yet, but that is a battle for another day.

In the end, it all came down to a few magical kernel parameters, and let Linux do it's magic probing for devices without taking any hints from firmware whatsoever:

pci=nobios pci=nocrs pci=realloc

I'd suggest blacklisting the nouveau module (or nvidia if you use proprietary drivers) when first booting, and add the following kernel parameter:

vga=vesa

This should give you at least some interaction options, in case there are more problems. Anyway, if you already end up in lightDM login screen, go ctrl+alt+f1 to go into your console. Issue the following command

sudo service lightdm stop

to bring down the display manager, then load the modules necessary for the nouveau driver using

sudo modprobe drm
sudo modprobe nouveau

and if all goes well, you should notice your screen already going to a nice 1920x1080 resolution. Now fire up the display manager again using

sudo service lightdm start

and login to your system. Adjust the resolution to what you'd normally use, update grub with your magic kernel parameters, remove any module blacklistings you don't need anymore, and enjoy.

Tested with kernel 3.18.5 which also gives the rtl8821ae drivers working, but it should probably work with lower kernel versions as well.

The_Fox
02-18-2015, 09:08 PM
Hello,

congrats for your running setup!
Unfortunately, I didnt managed it even with your description.

1. I Installed Ubuntu 14.10 with bootoption acpi=off(In GRUB menue I entered it rigth after quiet and then started installatoin process with F10)

Next I tried it first with 14.10 default kernel before upgraded to kernel 3.18.5 with the same results.

2. Started witch acpi=off, then entered in "etc\modprobe.d\blacklist.conf"; "blacklist nouveau" at the end.

3. Restart with bootoption "vga=vesa". Since I blacklisted nouveau, I cant get any picture. There is no with onboard and no with graphics card. This happens even with no bootoption set. And its not possible to switch to virtual console ctrl+alt+F1

4. Restarted with bootoption "acpi=off". Removed the blacklist nouveau. With acpi=off set as bootoption, I cant modprobe nouveau, It says there is no such device. That failure should be ok because acpi=off.

5. Restart with no bootoption, switched hdmi cable to onboards. Go to virtual console and executed:

sudo service lightdm stop

sudo modprobe drm
sudo modprobe nouveau

sudo service lightdm start

6. Restarted witch bootoptions: "pci=nobios pci=nocrs pci=realloc" and hdmi in graphics card. Nothing.


After trying witch the 14.10 default kernel, I tried it also with kernel 3.18.5. Could you please desribe again excactly what you have done to manage it :)

Thank you very much.

Best regards,

whatdoesthisbuttondo
02-19-2015, 02:03 AM
Well, let's see if we can figure out what the problem is.



There is no with onboard and no with graphics card. This happens even with no bootoption set. And its not possible to switch to virtual console ctrl+alt+F1


Even in that case, the virtual console is there and usable, you just can't see a picture. This is somewhat annoying, but you can still collect some valuable diagnostic data, and view it later when booting again with options that give you at least basic graphics:

1) enter username
2) enter password
3) dmesg > myboot.log
4) sudo reboot
5) enter password


First we should probably try to recreate the exact configuration I have on my end. In bios, I have this:

- uefi boot in "windows" mode
- fast boot disabled
- intel onboard lan disabled
- graphics set to "force primary display pcie"

I've installed a 14.04 Ubuntu (didn't have 14.10 install media at hand) with the cable switching method, force primary display to cpu and acpi=off as described before, and upgraded that to 14.10 the normal way.

Then I upgraded the kernel to one of the candidates (3.18.5) for the upcoming 'Vivid' release of Ubuntu, you can download the exact kernel here:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.5-vivid/

You'll need three files:

linux-headers-xxx-generic_yyy_amd64.deb
linux-headers-xxx_all.deb
linux-image-xxx-generic_yyy_amd64.deb

Install all these files, which should also add a configuration to the grub boot menu for you.

For the sake of recreating my exact config, add this to module blacklistings, some asus specific stuff for netbooks and laptops we do not need:

blacklist eeepc_wmi
blacklist asus_wmi

Then reboot, and edit the kernel command line, adding "pci=nobios pci=nocrs pci=realloc" and see what happens.

You can actually leave out the vga=vesa, and don't need to blacklist nouveau. If everything goes well, then we are happy. If not, we need to take a look at your dmesg output first (you can collect as described above).

First we will look at the very top, to check if it took out parameters properly, you should see something like this:

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.18.5-031805-generic root
=UUID=e6298eed-7674-42fe-a295-c0f5d7f77ee3 ro pci=nobios pci=nocrs pci=realloc v
t.handoff=7

There will be a lot of initialization messages, a few isolated acpi related error messages, and then we look for this:

[ 0.232550] pci 0000:01:00.0: [10de:1187] type 00 class 0x030000
[ 0.232559] pci 0000:01:00.0: reg 0x10: [mem 0xf6000000-0xf6ffffff]
[ 0.232567] pci 0000:01:00.0: reg 0x14: [mem 0xe8000000-0xefffffff 64bit pref]
[ 0.232576] pci 0000:01:00.0: reg 0x1c: [mem 0xf0000000-0xf1ffffff 64bit pref]
[ 0.232581] pci 0000:01:00.0: reg 0x24: [io 0xe000-0xe07f]
[ 0.232587] pci 0000:01:00.0: reg 0x30: [mem 0xf7000000-0xf707ffff pref]

This is the video part of your nvidia gpu. We should see some more initialization stuff, and then see the device get its resources assigned, there should ideally be no error messages here:

[ 0.262244] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 0.262246] pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
[ 0.262249] pci 0000:00:01.0: bridge window [mem 0xf6000000-0xf70fffff]
[ 0.262251] pci 0000:00:01.0: bridge window [mem 0xe8000000-0xf1ffffff 64bit pref]

There are less lines than we see above, but if you look at the ranges, you'll see that all the requested ranges are covered, it simply merged the two 64bit prefetchable bridge windows, the only issue we have is that the other two merged bridge windows we got are not prefetchable, but this should only result in a slight performance impact (and might be the case on windows as well, I have not checked).

Some more log messages we are not interested in, and then we should see nouveau driver taking over the device:

[ 2.543211] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0e4070a2
[ 2.543213] nouveau [ DEVICE][0000:01:00.0] Chipset: GK104 (NVE4)
[ 2.543214] nouveau [ DEVICE][0000:01:00.0] Family : NVE0
[ 2.543232] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image...
[ 2.543236] nouveau [ VBIOS][0000:01:00.0] ... signature not found
[ 2.543237] nouveau [ VBIOS][0000:01:00.0] checking PROM for image...
[ 2.581121] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid
[ 2.581123] nouveau [ VBIOS][0000:01:00.0] using image from PROM
... lots of stuff that is not really important...
[ 3.026091] nouveau [ DRM] allocated 1920x1080 fb: 0x80000, bo ffff8802109d3c00
[ 3.026147] fbcon: nouveaufb (fb0) is primary device
[ 3.290748] Console: switching to colour frame buffer device 240x67
[ 3.292070] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[ 3.292071] nouveau 0000:01:00.0: registered panic notifier
[ 3.295408] [drm] Initialized nouveau 1.2.1 20120801 for 0000:01:00.0 on minor 0

If you have all the above stuff in your dmesg output, then our issue is somewhere else, for example a botched xorg config. If some parts diverge with error messages, we'll have to look at those and see what goes wrong.

The_Fox
02-22-2015, 07:58 PM
Thank you very much for your help.
I wasnt able to try it yet, because I am ill at the moment and prefer to stay in bed. In a few days I will try it and send my results.

In the meantime I sent the results and that statement, that SteamOS isnt supported, to a countrywide IT newspaper and they really supported me in that question. So they sent an official request to ASUS, if SteamOS is supported now or not. They wrote an article about the G20 a few moths ago. They thougth like many others, that SteamOS is supported on G20 because ASUS said so. They wrote to ASUS that they should clarify it. Perhaps ASUS will fix it to run SteamOS on the G20 after a few nasty questions from IT reporters or bad, true reports of the G20.

I am very sure, that when ASUS manages it to run SteamOS on G20, Ubuntu and other distros should run, too. Espicially Ubuntu, since its based on debian kernel like SteamOS and SteamOS has similar issues with the graphics card.

Thank you very much and best regards,

The_Fox
02-24-2015, 06:10 PM
Thank you very much, I tested it and it works partially.

I tested a few other things, you recommended and first they didnt worked. By blacklisting the other asus packages that you mentioned, I discoverd that noveau is still blacklisted as well. Okey, so I enabled noveau and after Upgrade to 14.10 and software update the graphics card works with the mentioned bootparameters.

By the way, in the syslog I can read that "PCI: pci=nobios is not a known bootparameter". So it seems to me that they removed it and we dont require it, or do we?

Although the graphics card works now,:o i still have the issue with the spammed syslog and kern.log. I thougth these massages would dissappear, when we manage it that the graphics work properly?

Are the syslog and kern.log still spammed with the ACPI Errors in your system? If not, I overlooked something?! Or did you set a filter or disabled the log deamon?

whatdoesthisbuttondo
02-24-2015, 11:44 PM
Glad to see you're making progress.



By the way, in the syslog I can read that "PCI: pci=nobios is not a known bootparameter". So it seems to me that they removed it and we dont require it, or do we?


Nice catch, I've missed that somehow. In fact it appears that this has been removed in the newer kernels, so it should do nothing. Have not tested it yet though.



Although the graphics card works now,:o i still have the issue with the spammed syslog and kern.log. I thougth these massages would dissappear, when we manage it that the graphics work properly?


This is weird, I was under the impression that those disappeared for me as soon as I plugged the HDMI into the nvidia gpu and forced primary graphics to it.

My take on those was that they were related to power management on the card while it was inactive and the system was using the integrated graphics, maybe I was wrong there.

I'll check again if I maybe did change some power management settings in bios, not sure right now. I'll see that I can provide the complete settings I've used, maybe the issue is somewhere there.

Anyway, I did not filter these out, in fact I got rid of them pretty early on, back when the card wasn't working at all.

The_Fox
02-25-2015, 01:11 PM
I found out something else, what is a little bit strange:

If you set up in the UEFI Bootoptions "Other type OS" and not "Windows UEFI Mode", you cant load the ubuntu installer or start into LiveCD with the kernel Bootoption "acpi=off" set. With no kernel bootoptions set, you can start into LiveCD and run the installer, but it you cant use it properly, due to the log spamming.
You get the grub boot-menue and after choosing LiveCD or installation, the CD spins up shortly and after a few seconds it stops. Then there is no output at graphics card and cpu graphics?
Could you please confirm that?!

Thats little bit strange, but perhaps UEFI provides other dsdt tables or someting else from acpi, when '"Other type OS" is set?

A lot of issues and questions about that computer and integrated black box...

I hope ASUS will provide an update. Do you know when SteamOS releases? Ididnt found something else, that the release is slided into 2015 from last year.

tyler4tado
07-16-2015, 10:35 PM
I had the same problem as the rest of you here; I posted a new thread and managed to find a solution.
See the solution here:

https://rog.asus.com/forum/showthread.php?71429-Desperate-to-get-Linux-properly-up-and-running-on-my-Asus-ROG-G20AJ&p=519709#post519709
(https://rog.asus.com/forum/showthread.php?71429-Desperate-to-get-Linux-properly-up-and-running-on-my-Asus-ROG-G20AJ&p=519709#post519709)

Hope it helps someone. ;)

_ph03nix_
08-08-2015, 01:49 PM
Ok, I don't know if this is useful for anyone but after much trying and after reading a lot of webpages without success I got working as well my Kubuntu 15.04 on my ASUS G20AJ-NR042S (NVidia driver 346.87 - 1920x1080, no sound yet)

1. Disable fast boot in the BIOS

2. Leave Secure boot and CSM settings alone

3. Boot with your Kubuntu 15.04 USB drive and press 'e' to modify the grub settings and write (nomodeset acpi=off)

4. Connect to the internet (on my machine Wifi worked out of the box), select updates and install 3rd party software.

5. Install the Kubuntu and create your partitions accordingly. You just need to create the /, /home and swap partitions, and select the boot to be on the existing EFI partition (/dev/sdb2 on my machine)

6. Re boot your PC after installing and press 'e' again and add pci=nocrs pci=realloc nomodeset to your grub boot settings.

7. Upgrade your system with Muon updater.

8. Open konsole and modify your default grub settings as follows:
sudo vi /etc/default/grub, remove the splash and quiet from the GRUB_CMDLINE_LINUX_DEFAULT and add the following pci=nocrs pci=realloc nomodeset, the line should look like this:

GRUB_CMDLINE_LINUX_DEFAULT="pci=nocrs pci=realloc nomodeset"

Save and exit vi

sudo update-grub

9. Add the following 3rd party repository as follows:
sudo add-apt-repository ppa:xorg-edgers/ppa
sudo apt-get update
sudo apt-get install nvidia-346

10. Re boot.

J_A_M_E_S
12-26-2015, 11:30 AM
Hello All -

I followed the last post on the thread by _ph03nix_ and was able to get Ubuntu up 14.04.3 up and running with kernel 3.19.0-25. However, if I allow the kernel to upgrade to anything later than 3.19.0-25, the system will no longer boot. Same thing happens when I try an upgrade to 15.10.

I have included a screen shot of the error. Any idea what could be causing this or what I can do to resolve the issue?

The following settings are in grub at the time of attempted boot -

acpi=off nomodeset pci=nocrs pci=realloc

Any guidance is very much appreciated.

James