You are not logged in.
@vilefridge personnality I've use the last one but with this wiki
https://wiki.archlinux.org/index.php/Ch … tion_media
Also as you can see, the original image have a bug after 2013.10.01
Note: Due to a bug (FS#40637) in recent versions of the 64-bit Arch Linux Install Medium (after 2013.10.01), a 64-bit installation with the official image is not currently possible. The instructions below outline a method of modifying the image so that it will boot properly and a 64-bit installation can be performed.
Last edited by melkir (2014-12-22 01:59:37)
Asus K73SD : ArchLinux | W8 ~ Acer C720P : ArchLinux | ChromeOS
Offline
Just a heads up, wireless may not be detected in the 3.19-rc1 kernel without the CONFIG_ATH9K_PCOEM config option.
grep 'CONFIG_ATH9K' on config from linux-mainline (3.19rc1) AUR package, please be aware that it seem to be generated with 3.18.0
CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K_BTCOEX_SUPPORT=y
CONFIG_ATH9K=m
CONFIG_ATH9K_PCI=y
CONFIG_ATH9K_AHB=y
CONFIG_ATH9K_DEBUGFS=y
CONFIG_ATH9K_STATION_STATISTICS=y
# CONFIG_ATH9K_DYNACK is not set
CONFIG_ATH9K_WOW=y
CONFIG_ATH9K_RFKILL=y
# CONFIG_ATH9K_CHANNEL_CONTEXT is not set
CONFIG_ATH9K_HTC=m
# CONFIG_ATH9K_HTC_DEBUGFS is not set
grep 'CONFIG_ATH9K_PCOEM' on the auto updated .config by building 3.19
CONFIG_ATH9K_PCOEM=y
So the config was auto enabled, didn't checked why, wireless of course working.
p.s. If anyone want I can upload linux-mainline 3.19rc1 with the two drm patches to fix gpu hangs.
Edit: here's the link, it's the AUR's linux-mainline package with just the two drm patchs, no any other change related to chromebooks.
Last edited by dhead (2014-12-22 16:08:04)
Offline
Good news, kernel 3.19rc2 will include Chris Wilson's drm fixes
https://lkml.org/lkml/2014/12/23/472
Edit: These are the two which fixes the hangs
drm/i915: Force the CS stall for invalidate flushes
drm/i915: Disable PSMI sleep messages on all rings around context switches
Last edited by dhead (2014-12-24 08:14:26)
Offline
Good news, kernel 3.19rc2 will include Chris Wilson's drm fixes
https://lkml.org/lkml/2014/12/23/472
That's great news!
Offline
Good news, kernel 3.19rc2 will include Chris Wilson's drm fixes
https://lkml.org/lkml/2014/12/23/472Edit: These are the two which fixes the hangs
drm/i915: Force the CS stall for invalidate flushes
drm/i915: Disable PSMI sleep messages on all rings around context switches
Aaaand there it is. I'm going to compile it tomorrow and give it a run.
Offline
rc2 looks great so far, right now the pre-built linux-mainline packages of miffe got CONFIG_ATH9K_PCOEM enabled (as the config from 3.18 is auto enabling it).
when 3.19 will reach testings we need to check and nag the maintainer to enable it if it isn't enabled.
Offline
rc2 is working fine with no additional patches. I'm sure I'm missing something though. Just got it booted last night so I haven't had much time for testing.
Offline
linux-mainline rc2 on AUR doesn't seem to include the patches "backlight-dell-11.patch" and "v10-tpm_tis-verify-interrupt-during-init.patch" from linux-mainline-chromebook also on AUR, though.
Are they no longer necessary with changes made to linux-mainline rc2 on AUR?
I do know it does include the GPU hang patches, though.
Last edited by ibrudiiv (2015-01-01 21:34:20)
Offline
linux-mainline rc2 on AUR doesn't seem to include the patches "backlight-dell-11.patch" and "v10-tpm_tis-verify-interrupt-during-init.patch" from linux-mainline-chromebook also on AUR, though.
Are they no longer necessary with changes made to linux-mainline rc2 on AUR?
Perhaps the Dell backlight patch should be dropped since no one volunteered to test it? A TPM patch has been accepted by the TPM maintainer, who has submitted a pull request to the security subsystem maintainer, who will hopefully submit a pull request to Linus during the 3.20 merge window. So maybe the TPM patch won't be needed starting with 3.20.
Offline
Perhaps the Dell backlight patch should be dropped since no one volunteered to test it?
Didn't realize that, sadly.
A TPM patch has been accepted by the TPM maintainer, who has submitted a pull request to the security subsystem maintainer, who will hopefully submit a pull request to Linus during the 3.20 merge window. So maybe the TPM patch won't be needed starting with 3.20.
Sounds good. Thanks for the reply, scot14.
Offline
ibrudiiv wrote:linux-mainline rc2 on AUR doesn't seem to include the patches "backlight-dell-11.patch" and "v10-tpm_tis-verify-interrupt-during-init.patch" from linux-mainline-chromebook also on AUR, though.
Are they no longer necessary with changes made to linux-mainline rc2 on AUR?
Perhaps the Dell backlight patch should be dropped since no one volunteered to test it? A TPM patch has been accepted by the TPM maintainer, who has submitted a pull request to the security subsystem maintainer, who will hopefully submit a pull request to Linus during the 3.20 merge window. So maybe the TPM patch won't be needed starting with 3.20.
Can you explain the backlight patch? I'm running the rc2 but I compiled it myself from git and install using the traditional method. I did find out the tpm patch was still needed as you noted. However, my backlight works as intended with xbindkeys installed. Am I misunderstanding what the backlight patch is?
Offline
scot14 wrote:ibrudiiv wrote:linux-mainline rc2 on AUR doesn't seem to include the patches "backlight-dell-11.patch" and "v10-tpm_tis-verify-interrupt-during-init.patch" from linux-mainline-chromebook also on AUR, though.
Are they no longer necessary with changes made to linux-mainline rc2 on AUR?
Perhaps the Dell backlight patch should be dropped since no one volunteered to test it? A TPM patch has been accepted by the TPM maintainer, who has submitted a pull request to the security subsystem maintainer, who will hopefully submit a pull request to Linus during the 3.20 merge window. So maybe the TPM patch won't be needed starting with 3.20.
Can you explain the backlight patch? I'm running the rc2 but I compiled it myself from git and install using the traditional method. I did find out the tpm patch was still needed as you noted. However, my backlight works as intended with xbindkeys installed. Am I misunderstanding what the backlight patch is?
I'm not too sure but as you said xbindkeys is enough to make it work. I suppose the patch stuck around for longer than necessary.
Offline
ridobe wrote:scot14 wrote:Perhaps the Dell backlight patch should be dropped since no one volunteered to test it? A TPM patch has been accepted by the TPM maintainer, who has submitted a pull request to the security subsystem maintainer, who will hopefully submit a pull request to Linus during the 3.20 merge window. So maybe the TPM patch won't be needed starting with 3.20.
Can you explain the backlight patch? I'm running the rc2 but I compiled it myself from git and install using the traditional method. I did find out the tpm patch was still needed as you noted. However, my backlight works as intended with xbindkeys installed. Am I misunderstanding what the backlight patch is?
I'm not too sure but as you said xbindkeys is enough to make it work. I suppose the patch stuck around for longer than necessary.
I see. Thanks for the quick reply. So, it appears as though we are only one commit away from having a kernel work out of the box.
Offline
I see. Thanks for the quick reply. So, it appears as though we are only one commit away from having a kernel work out of the box.
Yep! Hopefully. I'm looking forward to trying out linux-mainline later today from linux-mainline-chromebook, though, since I'm getting a new SSD in for my C720!
It's gonna be excellent when the core kernel works the same way.
Offline
ibrudiiv wrote:ridobe wrote:Can you explain the backlight patch? I'm running the rc2 but I compiled it myself from git and install using the traditional method. I did find out the tpm patch was still needed as you noted. However, my backlight works as intended with xbindkeys installed. Am I misunderstanding what the backlight patch is?
I'm not too sure but as you said xbindkeys is enough to make it work. I suppose the patch stuck around for longer than necessary.
I see. Thanks for the quick reply. So, it appears as though we are only one commit away from having a kernel work out of the box.
The Dell backlight patch is only needed for those using the Dell 11 Chromebook. I think it's a speculative patch, unconfirmed to work by any Dell owners. But suspend won't work correctly if the EHCI modules are loaded (I'm assuming the stock kernel would normally load them). See https://wiki.archlinux.org/index.php/Chromebook for how to disable with a kernel command line parameter.
Offline
ridobe wrote:ibrudiiv wrote:I'm not too sure but as you said xbindkeys is enough to make it work. I suppose the patch stuck around for longer than necessary.
I see. Thanks for the quick reply. So, it appears as though we are only one commit away from having a kernel work out of the box.
The Dell backlight patch is only needed for those using the Dell 11 Chromebook. I think it's a speculative patch, unconfirmed to work by any Dell owners. But suspend won't work correctly if the EHCI modules are loaded (I'm assuming the stock kernel would normally load them). See https://wiki.archlinux.org/index.php/Chromebook for how to disable with a kernel command line parameter.
The backlight on my Dell 11 works fine with the stock kernel. I'm using the John Lewis rom, does that matter?
Last edited by mrshankly (2015-01-03 18:55:04)
Offline
The backlight on my Dell 11 works fine with the stock kernel. I'm using the John Lewis rom, does that matter?
Yes, his firmware duplicates the video pci id's of the C720, so the kernel applies the backlight quirk.
Offline
just noticed this on 3.19rc3, not sure if it's in 3.18, the usb related error message finally changed into:
kernel: usb 1-4: language id specifier not provided by device, defaulting to English
Offline
just noticed this on 3.19rc3, not sure if it's in 3.18, the usb related error message finally changed into:
kernel: usb 1-4: language id specifier not provided by device, defaulting to English
I was getting that one on 3.18 as well, specifically on linux-mainline-chromebook 3.18.
Last edited by ibrudiiv (2015-01-09 16:40:22)
Offline
Ignore, I figured it out, I was being an idiot and using the wrong partition scheme.
Last edited by rollhax (2015-01-11 02:27:54)
Offline
I'm not sure if I'm the only one who's bothered with it but here's a GPU slowdowns update.
After using 3.19rc4 for a 1~2 days here's what I'm seeing:
1. No more crashes and segfaults in journald (I believe they were mainly of drivers/gpu/drm/i915/intel_pm.c) which were accompanying the slowdowns of the GPU which in turn were appearing usually on heavy usage of Chromium (running another app that use the GPU like Kodi or image editor will hasten the appearance of the slowdowns). Edit: I'm a bit confused, nothing changed in i915 since rc2.
2. No more crashes and segfaults in journald when running testdisplay (from intel-gpu-tools) with an external monitor attached.
3. I still experiencing slowdowns (though maybe less frequent) that usually accompanied by the error message "*ERROR* uncleared fifo underrun on pipe A".
Other 3.19 regressions (not specific to rc4):
4. When a slowdown occur and I kill Chromium (changing to tty2) Xorg stays unresponsive and I need to kill it too, I can't remember if this started on rc4 or rc2 but this definitely a 3.19 regression. Edit: I was wrong, this isn't specific to the slowdowns, by just changing to tty2 and back to the desktop on tty1 the desktop is becoming unresponsive and this doesn't seems to be related to the kernel, this is xf86-video-intel-2.99.917-1 regression.
5. Flash in Chromium started triggering GPU slowdowns, usually at the end of longer videos (40min), this happened to me three times in the last 7 days.
Another thing that only since 3.19rc2 I noticed (and not yet with rc4):
6. Connecting an external monitor will hasten the appearance of slowdowns, it might be related to 2. so maybe this have been changed in rc4.
Anyway, I think I'll update to rc5, test it for a few days and then open a bug about the fifo underrun as it's now the only GPU related error I'm seeing in the logs.
Last edited by dhead (2015-01-21 15:55:30)
Offline
Forget what I said about Xorg being unresponsive, it's xf86-video-intel-2.99.917-1 regression.
Offline
Haswell GT1 GPU bugs update:
I've chatted with Intel's Chris Wilson on IRC and from my logs he confirmed the following are bugs that worth reporting:
1. wrong size wm entry cause *ERROR* CPU pipe A FIFO underrun, from his tone I understood this a minor issue. https://bugs.freedesktop.org/show_bug.cgi?id=88714
2. [HSW GT1] trying to flip between 2 buffers of different strides, this one is probably the cause of the slowdowns when using Chromium. https://bugs.freedesktop.org/show_bug.cgi?id=88716
* The third issue is a regression of xf86-video-intel 2.99.917, running X on vt1, changing to tty2 and back will make the desktop (Gnome) unresponsive. Chris tested this in Ubuntu and didn't saw any problem so this might be Arch packaging specific, I'm waiting for someone else to confirm it at https://bugs.archlinux.org/task/43534 .
Notice that for the extra logging I used kernel parameter drm.debug=0xe .
Offline
If you using my AUR package xkeyboard-config-chromebook for mapping the keyboard then please support my feature requests for libxkbcommon.
The RedirectKey action in xkeyboard-config will make sure Chromium, Firefox and LibreOffice will respect the hotkeys which mapped with a patch for xkeyboard-config.
In X this works OK-ish and gives me a usable solution but in Wayland it doesn't work as libxkbcommon doesn't support the RedirectKey action.
I opened the following issues in libxkbcommon's Github repository:
1. add RedirectKey action, this one is the important one, https://github.com/xkbcommon/libxkbcommon/issues/18
2. add support for setting repeat in symbols, https://github.com/xkbcommon/libxkbcommon/issues/19
If you care about having this feature in Wayland then I urge you to post there and tell the developers you want it as I did chatted with one of the developers and he told me that this feature is big and will complicate things and no one ask for it yet so their motivation for adding it isn't high.
You can try today and see how the RedirectKey action works in a X session by compiling the package from chromebook_redirect_key branch on my Github repo at
https://github.com/dhead666/archlinux-p … chromebook
Offline
* The third issue is a regression of xf86-video-intel 2.99.917, running X on vt1, changing to tty2 and back will make the desktop (Gnome) unresponsive. Chris tested this in Ubuntu and didn't saw any problem so this might be Arch packaging specific, I'm waiting for someone else to confirm it at https://bugs.archlinux.org/task/43534 .
It works fine while using LXDE here. I can start X and switch back and forth without any problems.
Using xf86-video-intel 2.99.917 and linux-mainline 3.19-rc5 on HP14 chromebook.
Offline