You are not logged in.
I installed Arch on my chromebook a couple of days ago. Unfortunately 64 bit installation with the newest 2014.10.01 doesn't work and the "mem=1536m" kernel parameter doesn't make a difference.
Thanks for trying it out and the detailed report.
Offline
SolarBoyMatt wrote:If parchedas is currently MIA, I wouldn't mind building those packages in the mean time, but for linux-mainline-chromebook, remind me, which patches should be kept, and which should be discarded? Are the Dell 11 backlight and C720p touchscreen patches are still needed? The only one I use anymore is the tpm patch, but I want to be certain.
I think the C720P patch is in 3.17, the Dell backlight patch is orphaned, https://patchwork.kernel.org/patch/4971571/ may be in 3.18 and https://patchwork.kernel.org/patch/4975201/ is in linux-next and should also be in 3.18.
Hey everyone,
I updated linux-chromebook and linux-mainline-chromebook since parchedas seems to be MIA right now. I left linux-chromebook mostly the same, but I redid linux-mainline-chromebook from scratch.
https://drive.google.com/folderview?id= … aring#list
linux-chromebook:
* Updated to 3.16.3 source
* Updated tpm patch to scot14's new version
linux-mainline-chromebook:
* Updated to 3.17rc7 source
* Applied scot14's new tpm patch
* Added scot14's USB descriptor patch
* Enabled light-sensor module for C720 (ISL29018 module)
* Removed all other patches from linux-chromebook except Dell 11 Backlight patch as they've been officially merged in
I tested linux-chromebook quickly and everything seemed to work fine, but let me know if there are any issues, especially for anyone with a Chromebook other than the C720/C720P.
Offline
@SolarBoyMatt
Thanks for updating the package.
I believe that you can press the file request button and ask for changing the packages status to orphan and then you could own them (I believe by submitting an update package).
I spent some time determining these values (while working on getting hibernate to work).
The most important ones are:
- enable_ppgtt (it set to 2 as default in my driver, playing a video using Xv extension will crash the server)
- use_mmio_flip (activating this option prevent memory corruption wiht my setup)
- powersave (if not set, it won't survive an hibernate/resume cycle)
- enable_cmd_parser (if not set, less stable... this option is obscure to me at this time)
- enable_psr (Linus set it to 0 by default in 3.17-rc1, previously it was on by default. It did not work with his notebook but it works fine with mine)Also, as I'm working on stabilizing my HP ChromeBook 14, it looks like a good idea to disable "glamor" extension (because of the Xorg server, not i915 module) and to prevent any use of glx-tls in Mesa (load forced by glamor). It looks like there are stabilities issue with it and glamor accel is never used as SNA is the new default one.
My Xorg (with SNA accel) is now stable since I have recompiled Mesa without glx-tls and disabled glamor.
the bug report.
@zeig
Thanks for your notes about the i915 module options.
I'm on kernel 3.17rc7 and after dropping the default values the kernel parameters left are:
drm.vblankoffdelay=1 i915.semaphores=0 i915.modeset=1 i915.use_mmio_flip=1 i915.enable_ppgtt=1 i915.reset=0 i915.lvds_use_ssc=0
I'm now testing only with
i915.semaphores=0 i915.modeset=1 i915.use_mmio_flip=1 i915.enable_ppgtt=1
Removed i915.reset=0 was describe as dangerous by one of XBMC devs, i915.lvds_use_ssc=0 as it seems to need i915.reset=0, and I saw some weird lines when playing a video with vaapi so maybe drm.vblankoffdelay=1 is to blame.
Last edited by dhead (2014-10-04 18:52:51)
Offline
Thanks! Is the 64-bit installer boot parameter "mem=1536m" required?
I installed Arch on my chromebook a couple of days ago. Unfortunately 64 bit installation with the newest 2014.10.01 doesn't work [...]
I've checked, the ISO that worked successfully for me was 2014.08, might be worth a try (although John Lewis' latest ROM might be what made it work for me).
Offline
I have used both versions of arch. The i686 version seem's to use less memory. With my little 720p only having 2GB of memory, that seems to be the way to go.
@SolarBoyMatt, I would love to test your kernels but you did not provide a i686 version.
Offline
I have used both versions of arch. The i686 version seem's to use less memory. With my little 720p only having 2GB of memory, that seems to be the way to go.
@SolarBoyMatt, I would love to test your kernels but you did not provide a i686 version.
How much difference would you say? 10% less? 25%? I've been considering trying the i686 too.
Offline
I have used both versions of arch. The i686 version seem's to use less memory. With my little 720p only having 2GB of memory, that seems to be the way to go.
@SolarBoyMatt, I would love to test your kernels but you did not provide a i686 version.
I didn't build i686 versions since the majority of us here have a 64-bit install, but if someone will use them I can build the i686 versions too. That being said, I won't be able to test them before hand, since I run 64-bit Arch on this as well.
Offline
Fair enough. I may switch back to a 64-bit install in the future, if support and the community is leaning that direction. Thanks for the reply.
Offline
I can confirm that the latest 64-bit arch iso still doesn't boot up (correctly) with the stock firmware.
I'd love to install Arch on this thing, though.
Currently running this custom Xubuntu distro specifically tweaked for the Acer C720 (so things work nicely out of the box), but I'm missing Arch for some reason?
I will try out the workaround suggested in the wiki to get the live env up and running.
Offline
Fair enough. I may switch back to a 64-bit install in the future, if support and the community is leaning that direction. Thanks for the reply.
Luckily both packages needed a rebuild, so I went ahead and did the 32-bit versions as well. You can download them here https://drive.google.com/open?id=0B_be4 … authuser=0. Like I said, I have no way to test the 32-bit versions, so please let me know if there are any issues, and same goes for any chromebooks other than the C720.
I was also able to get in contact with parchedas, who said he's been very busy lately, so he orphaned the AUR packages, and I've now taken over maintaining them.
Hopefully if scot14's latest patches make it into 3.18, 3.17 will be the last branch we need to patch (3.17 patches are mainly just to get suspend working without kernel parameters/tmpfiles on stock firmware).
Last edited by SolarBoyMatt (2014-10-07 14:06:28)
Offline
..did the 32-bit versions as well. You can download them here https://drive.google.com/open?id=0B_be4 … authuser=0. Like I said, I have no way to test the 32-bit versions, so please let me know if there are any issues, and same goes for any chromebooks other than the C720.
I'm using your 32-bit versions and they seem to work OK. Suspend works after waiting about 4 minutes, only giving errors on xhci_hcd, usb 1-3 and 1-4 when opening the lid again.
Sofar I have only edited grub with..
/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="tpm_tis.interrupts=0 modprobe.blacklist=ehci_pci"
Will check if i need to apply the before mentioned fixes. I'm not all to familiar with this all. In any case, thanks for every effort.
Last edited by Takkie (2014-10-07 22:59:43)
Offline
You don't need either those kernel parameters if you're using the patched kernels. All of those suspend related issues you mentioned are known behaviors on both linux-mainline and linux-mainline-chromebook, and shouldn't really be anything to worry about.
Offline
Suspend works after waiting about 4 minutes, only giving errors on xhci_hcd, usb 1-3 and 1-4 when opening the lid again.
Does suspend also work immediately after the boot process completes?
Offline
You don't need either those kernel parameters if you're using the patched kernels. All of those suspend related issues you mentioned are known behaviors on both linux-mainline and linux-mainline-chromebook, and shouldn't really be anything to worry about.
in that case, it works, no other issues found yet.
Takkie wrote:Suspend works after waiting about 4 minutes, only giving errors on xhci_hcd, usb 1-3 and 1-4 when opening the lid again.
Does suspend also work immediately after the boot process completes?
No, I have clocked it once more and it takes about 2m30s after boot before suspend activates after boot with lid closed.
Offline
No, I have clocked it once more and it takes about 2m30s after boot before suspend activates after boot with lid closed.
Thanks for testing, this is helpful. The 2m30s sounds like a problem related to TPM.
If you power off, boot up, open a terminal window and run "sudo systemctl suspend", how long until the screen blanks? Once it blanks, and then the power button is pressed to resume from suspend, how long until the screen unblanks? How long after the screen unblanks until the system becomes responsive again?
Also, what is the output from "dmesg|grep tpm"? It should be something like
[ 0.171388] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[ 0.215289] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working, polling instead
Last edited by scot14 (2014-10-08 14:06:17)
Offline
Takkie wrote:No, I have clocked it once more and it takes about 2m30s after boot before suspend activates after boot with lid closed.
Thanks for testing, this is helpful. The 2m30s sounds like a problem related to TPM.
If you power off, boot up, open a terminal window and run "sudo systemctl suspend", how long until the screen blanks? Once it blanks, and then the power button is pressed to resume from suspend, how long until the screen unblanks? How long after the screen unblanks until the system becomes responsive again?
Also, what is the output from "dmesg|grep tpm"? It should be something like
[ 0.171388] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[ 0.215289] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working, polling instead
power on > login: 7s
login > suspend: instant
suspend > power: instant
dmesg|grep tpm:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-linux-mainline-chromebook root=UUID=07007c2c-4b88-40fc-9321-dfda8fbfecb0 rw quiet tpm_tis.interrupts=0 modrpobe.blacklist=echi_pci,echi_usb,echi_hcd nmi_watchdog=panic,lapic
But when redo-ing my grub to "quit nmi_watchdog=panic,lapic" only there is nothing in dmesg for tpm.
Offline
power on > login: 7s
login > suspend: instant
suspend > power: instantdmesg|grep tpm:
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-linux-mainline-chromebook root=UUID=07007c2c-4b88-40fc-9321-dfda8fbfecb0 rw quiet tpm_tis.interrupts=0 modrpobe.blacklist=echi_pci,echi_usb,echi_hcd nmi_watchdog=panic,lapic
But when redo-ing my grub to "quit nmi_watchdog=panic,lapic" only there is nothing in dmesg for tpm.
Are you using John Lewis' firmware? If so, there will be no entries in dmesg about tpm and there should be no need for the tpm_tis kernel parameters, but you would need to either use a kernel (like linux-chromebook/linux-mainline-chromebook) that doesn't include the ehci modules or blacklist them (e.g. with the "modrpobe.blacklist=echi_pci" kernel parameter).
We might be able to troubleshoot more if you reproduce the 2m30s delay and then post the output from dmesg along with a description of what happened with the lid and when.
Offline
I am using stock firmware with linux-mainline-chromebook (which uses your latest tpm patch) and with no additional kernel parameters.
dmesg | grep tpm:
[ 1.325133] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[ 1.372314] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working, polling instead
While I have not timed when I can get suspend from the lid, I can at least get it work instantly with 'systemctl suspend'
Offline
I am running Arch 64bit on Acer C720 Chromebook with no patch and waiting 3.17 kernel.
I checked www.kernel.org. The web page shows "Latest Stable Kernel: 3.17" on big yellow square button.
But It shows below
"mainline: 3.17 .........."
"stable: 3.16.4 ..........."
"........................."
...........................
So, I am just wondering the next kernel update in Arch linux is 3.17 or 3.16.5.
Which one?
Amazing !
Offline
So, I am just wondering the next kernel update in Arch linux is 3.17 or 3.16.5.
Which one?
Next kernel will be 3.17, it's already in the testing repository https://www.archlinux.org/packages/test … _64/linux/.
Offline
I added the microphone fix to the wiki, you only need it for the built in microphone, if you're using a headset then this isn't needed.
Works for me well on Gnome 3.14 (tested with gnome-sound-recorder).
Please update if this working for you on other desktop environments and update the wiki if more settings needed on other environments (.asoundrc).
Don't forget to enable the microphone and increase its volume.
https://wiki.archlinux.org/index.php/Ch … xing_Audio
Edit: Also works great on the new Chromium Hangouts app and extension, pretty amazing Linux experience.
Last edited by dhead (2014-10-09 22:24:26)
Offline
Last night i installed arch (only base install) on c720.
Latest install media (2014.10.1) is working in 64bit mode without any additional parameters or modifications when using John Lewis's latest custom ROM (040914).
Also I was able to install and boot using SYSLINUX, but installation using syslinux-install_update is still not working (using all three parameters for full automatic install).
These are three step necessary to boot using SYSLINUX (assuming that your boot drive is first partition on /dev/sda):
copy SYSLINUX files:
# syslinux-install_update -i
using fdisk make /dev/sda1 bootable:
# fdisk /dev/sda
at prompt select option a
install 440 byte MBR code:
# dd bs=440 conv=notrunc count=1 if=/usr/lib/syslinux/bios/mbr.bin of=/dev/sda
Offline
I added the microphone fix to the wiki, you only need it for the built in microphone, if you're using a headset then this isn't needed.
Works for me well on Gnome 3.14 (tested with gnome-sound-recorder).Please update if this working for you on other desktop environments and update the wiki if more settings needed on other environments (.asoundrc).
Don't forget to enable the microphone and increase its volume.https://wiki.archlinux.org/index.php/Ch … xing_Audio
Edit: Also works great on the new Chromium Hangouts app and extension, pretty amazing Linux experience.
Sadly it didn't work for me. Before I only had "options snd_hda_intel index=1" in /etc/modprobe.d/alsa.conf and the microphone has always been working, but when I raise the volume above a certain level it will simply go mute, and unfortunately I am experiencing the same issue with the configuration you have posted.
Oh I wanted to mention that I do use kde4 and the microphone behaves as described system wide, regardless if a system application or a web application such as hangout for instance. Also on the picture below its shown the maximum volume level I can raise the microphone ( and its very low btw), beyond that microphone dies.
Thanks
Sun Netra T1 DC200 (x6 cluster) OpenBSD 5.4; Sun Ultra 5 OpenBSD 5.4; Futro S500 FreeBSD 10.0; Chromebook c720 ArchLinux; etc
Offline
@Latrina
Are you on kernel 3.17 ? if so then did you also tried the other model I mentioned in the wiki ?
If you're on 3.16 then try alc283-chrome .
Edit: I on 3.17 (linux upstream, no chromebook package) and Gnome 3.14 and without adding the model alc283-dac-wcaps the mic isn't usable at all, when adding the model I don't have the volume limitation that you described.
Last edited by dhead (2014-10-11 15:18:37)
Offline
I installed linux-mainline-chromebook, but the track pad still isn't working. I also made the xorg configurations from the wiki. Is there something else that needs to be done?
Offline