18:58 <hexdump01> are there any known quirks for very early snow chromebooks? i have one from oct 2012 which hangs with mainline reliably without any useful traces on memtest 1500M or a make -j 4 kernel build

18:58 <hexdump01> i have another later snow which runs absolutely stable from the same sd card

18:59 <hexdump01> i found out about bitfix and updated the full firmware to a newer version without the bitfix problem, but it did not change anything

19:00 <hexdump01> if i run my root file system as chroot from chromeos it is running absolutely stable, so looks like the chromeos kernel has something in it to work around the potential problems of this chromebook

19:01 <hexdump01> i also tried a few other things without them changing anything: lower cpu clock, disable frequency scaling, setting the cooling maps to cooler temps, disable one of the cpu cores

19:03 <LiquidAcid> hexdump01, does "disable frequency scaling" also include devfreq?

19:04 <hexdump01> i increased the opp cpu voltages slightly, booted with init=/bin/bash to have nothing else around, tested with mem=1024M, tested a kernel with CONFIG_MEMTEST - nothing of all that helped or gave useful debug info

19:05 <hexdump01> Liquidacid: i did set cpufreq/scaling_[min,max]_freq to the same freq, so only for the cpu

19:13 <LiquidAcid> hexdump01, maybe try to do the same for devfreq, should be some way to config the governor in /sys/class/devfreq

19:22 <hexdump01> Liquidacid: thx, i'll give this a try ... but i guess the cromeos kernel does use deffreq as well ... i guess its more some quirk in the early hardware which is somehow worked around in the cros kernel and fixed in later hardware