01:01 <amstan> naobsd: will something like this not work? http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/mali-drivers-veyron-1.20-r16.run

01:01 <amstan> naobsd: you can ask mmind00 which version he had working with x11, at one point we removed that for chromeos

01:23 <naobsd> amstan: libMali for Mali-T76x can work with Mali-400?

01:23 <amstan> naobsd: that's the one we're using for the rockchip chromebooks

01:23 <amstan> afaik that's the same chip firefly uses

01:23 <naobsd> amstan: I know

01:23 <amstan> so i don't see why it wouldn't work

01:24 <naobsd> amstan: I know it works with Mali-T76x

01:24 <naobsd> amstan: what I'm asking is about Mali-400

09:32 <mmind00> naobsd: nope ... that are completely different hardware generations (utgard as mali400 and midgard as mali-Txxx)

09:34 <mmind00> naobsd: if you also look into the chromeos repo, it even looks like they have different drivers for Samsung (T6xx) and Rockchip (T764) ... and of course we cannot be sure how hardware-specific the differences are ... aka we're not even sure if the veyron driver would run on a different T764 chip

09:40 <mmind00> amstan: Dominik was nice enough to include a special path in his build script for me, so as long as some parts of ChromeOS are still x11-based we'll still also get updated x11 drivers :-)

09:40 <mmind00> amstan: and I guess after this, I'll have to pester Rockchip for updates

09:42 <mmind00> or maybe we can switch to libv 's tamil directly when the time comes *still keeping hope* ;-)

11:35 <mmind00> I've now also made my mali installer script for Debian(-based) distributions available: https://github.com/mmind/mali-driver [I've asked the Chromeos people and nobody complained about this so far :-) ]

11:36 <mmind00> caveat: libGL.so* also gets diverted, but nothing provides a new symlink currently ... so things like KDE may stumble without a manually generated libGL symlink

11:55 <rperier> don't compute something... mwifiex is for Marvell-based chipsets (throught PCIe, sdio or usb) ... on the firefly ... this is an AP6335... that's a broadcom chipset no ?

11:58 <rperier> it seems different between boards :/

12:00 <naobsd> yes, I know Mali-T7xx and Mali-400 are different...

12:04 <mmind00> rperier: correct, firefly has something from Broadcom, while the Chromebooks (at least the two I've seen so far) use a Marvell based module

12:06 <rperier> yeah... it won't help for maintanability :/

12:08 <mmind00> why?

12:09 <mmind00> rperier: i.e. the Broadcom chip is supported by the brcm80211 (I think the brcnfmac variant) it seems

12:10 <mmind00> rperier: the rk3368 uses this too ... it currently probes, loads firmware but does not talk to anything yet

12:10 <rperier> I see

12:11 <mmind00> rperier: the broadcom cards seem to always need some sort of .txt file describing stuff, so I currently tend to like the Marvell stuff better ;-)

12:11 <rperier> you mean that the driver does not support devicetree ?

12:12 <mmind00> both are sdio devices ... they don't need to care about devicetree at all

12:13 <mmind00> rperier: broadcom modules seem to require both a binary firmware as well as txt file (loaded as firmware too) that describes specific implementation details

12:14 <rperier> I did not touch to any sdio device yet on linux ;)

12:15 <rperier> (but that's a good opportunity to learn things)

12:15 <mmind00> rperier: sdio devices are auto-discoverable (as you can of course plug and unplug different sd-cards)

12:16 <mmind00> rperier: concerning the ap6335: this is what I've pulled from the rk3368-r88 flash for the ap6335 used there: https://bpaste.net/show/3c99b2d52574

12:17 <mmind00> so these seem to set brcmfmac5339-sdio settings for the ap6335 module or so

12:19 <mmind00> rperier: somewhere on the firefly firmware there should be similar file ... but named differently and in a different location

12:20 <mmind00> would be interesting if this then does contain the same values

12:22 <rperier> I will look at it, I will reflash a standard distro on my firefly and then I will pull the content of the emmc to my laptop

12:47 <rperier> https://bpaste.net/show/7431642545f3

12:47 <rperier> files are different

13:05 <mmind00> rperier: interestingly also different version 1.2 vs 1.7

19:31 <rperier> seriously... even with a kernel 4.0 btrfs is a bull..$$$$$ , that's the second time that my fs crashes because my laptop was not restarted correctly

19:32 <rperier> I never had this kind of problem with ext4...

19:32 <rperier> :/

19:33 <amstan> rperier: i've been doing fine with it

19:33 <amstan> rperier: Linux alex-desktop 4.0.2-1-ARCH #1 SMP PREEMPT Thu May 7 06:47:54 CEST 2015 x86_64 GNU/Linux

19:34 <rperier> I am on arch too, the distro works like a charm since many years... I just switched to btrfs few months ago...

19:34 <amstan> rperier: though.. i don't restart often(sleep every day), or without unmonting properly

19:34 <amstan> why do you shutdown wrong?

19:35 <rperier> because when I suspended my laptop (which works fine usually) it did not work, and it freezed (a kernel hangs, nothing very serious)

19:35 <amstan> ah

19:35 <rperier> :)

19:35 <amstan> try doing a sync before suspending somehow..

19:36 <amstan> how's the recovery process like anyway?

19:36 <amstan> when it refuses to mount

19:37 <rperier> yeah but the system was completly frozen, so it was impossible to do a sync

19:37 <amstan> ...before, see if there's a pre-suspend script somewhere'

19:38 <amstan> rperier: https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks

22:53 <karlp> the idea that you have to shut down specially first is a ground level failure for a filesytem IMO. shit's gonna break, it had better recover

23:38 <amstan> karlp: i agree, i was just proposing some mitigations