<mmind00>
philhug: do you have the debug_ll enabled? ... mass production coreboots do not configure the uart clocks, so if debug_ll wants to print something, it get stuck
<philhug>
mmind00: I just applied the patch from arch and don't see it configuring the clocks. thanks for the hint.
<philhug>
trying now with debug_ll disabled
<philhug>
mmind00: much better, thanks :)
<mmind00>
philhug: great to hear :-)
gb_master has quit [Remote host closed the connection]
markm has joined #linux-rockchip
gb_master has joined #linux-rockchip
<c0d3z3r0>
mmind00, rperier: hey guys, I got a kernel panic with current linux-next. looks like a problem with arc emac but I'm not sure. maybe you could have a look at this? http://pastebin.com/mAj10umD
cristian__c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
<mmind00>
c0d3z3r0: looks like arc_emac_poll does something wrong? But I've never looked deep into the arc-emac so far
<c0d3z3r0>
mmind00: hmm… rperier and naobsd had that problem in 9/2014 :S
<sjoerd`>
c0d3z3r0: It's a someone known issue nobody really had time to look into afaik
<c0d3z3r0>
sjoerd`: oh bad :( I had a short look at it but my kernel knowledge isn't that good
<gb_master>
I guess you're talking about the skb_panic problem I was having with rk3188... sadly, afaik, it has never been solved and this made my radxa rock completely useless with the mainline kernel, as the eth makes it panic after a few secs. anyway, rperier was giving it a look back in the days
<c0d3z3r0>
gb_master: the panic appears very randomly on high load as well as on idle state…. and the makes squeaky noises when receiving o.O :D
<gb_master>
c0d3z3r0: I don't remember squeaky noises... anyway, my radxa panic'ed every single time after a few secs after booting
<gb_master>
c0d3z3r0: as I needed the mainline kernel for other reasons, I had to switch to alternatives to rk3188
<c0d3z3r0>
gb_master: which board do you have now?
<gb_master>
rpi2... at least, is continuously supported. a thing that rockchip (and a lot of other companies), apparently, doesn't do
<gb_master>
sadly, I don't know much about kernel dev, otherwise I would have tried to help. as long as this bug isn't fixed, radxa will be kept in its box
<c0d3z3r0>
gb_master: same here
<gb_master>
c0d3z3r0: I don't know if the dev on the rk3188 is still active here... as far as I saw, a lot of movement is going on rk3288 and further. hopefully, somebody will fix it someday
<c0d3z3r0>
gb_master: I hope so.. I had some time for playing with barebox on the rock and my debian installer. today I was really happy that I got everything working but than …. kernel panic
<gb_master>
c0d3z3r0: I really hope so. Things are going better with rk3288 and mainline?
<c0d3z3r0>
gb_master: I don't have any rk3288 board. just rpi b, rpi 2 and radxa rock
<gb_master>
c0d3z3r0: just like me. identical.
<c0d3z3r0>
gb_master: odroid-xu4 looks nice
<gb_master>
c0d3z3r0: if it's maintained/mainline, then it's already a GOOD point :)
<gb_master>
c0d3z3r0: aaaaaaaaand you're right. and status is not that bad. as far as I remember, the video is still suffering in the mainline
<c0d3z3r0>
gb_master: hmm looks like the odroid works with mainline, too. at least cpu, usb 3.0 and ethernet
<gb_master>
c0d3z3r0: I have no idea. but I don't want to spend more money on this stuff. I'm fine with the rpi2 now and I hope I'll be able to use the rr soon
<c0d3z3r0>
gb_master: yeah, it would be really great if someone could fix the ethernet on rr.
<gb_master>
c0d3z3r0: rperier, you're our only hope :)
<c0d3z3r0>
gb_master: I have to leave now cya
<gb_master>
c0d3z3r0: enjoy
<mmind00>
gb_master: just picking up the question from 21:28 ... yes our rk3288 support in mainline is a lot better at the moment
<mmind00>
gb_master: mainly due to the big effort coming from the Chromebook project
nighty^ has quit [Quit: Disappears in a puff of smoke]
<philhug>
mmind00: I guess it's best if I track your for-next branch for veyron-speedy?
<mmind00>
philhug: depends on what you want to do ;-) ... my "for-next" feeds directly into the linux-next tree together with all other maintainer-trees ... but that doesn't give you output on the internal display yet [display-port driver is still in flight]