[14:32] <sveinse> rsalveti: I'm getting "no such device" when I'm trying to modprobe the omaplfb.ko driver (from the SGX drivers). Are you familiar with this error?
[14:57] <rsalveti> sveinse: hm, no, never had this error
[15:06] <sveinse> rsalveti: OK. I will investigate. I suspect some kernel setting as the board (&kernel) is new to me and I have not tested SGX on it yet. I'm using the Gumstix Overo Fire board now
[15:06] <rsalveti> hm, ok
[15:07] <sveinse> there are some boards who uses TI's linux repo, while others are using the official linux repo
[15:08] <sveinse> Not that I really have understood the relationship between them, i.e. why TI cant work on the official one instead
[15:13] <sveinse> rsalveti: devmem2 is used solely for identification, not for setup/configuration, right?
[15:13] <rsalveti> sveinse: just identification
[15:13] <sveinse> In the new driver, devmem2, isn't installed and isn't used from the rc.pvr init script
[15:13] <rsalveti> the pvrsrvinit is the one who initialize the sgx
[15:14] <sveinse> Love your upstart adaptation BTW ;)
[15:15] <rsalveti> :-)
[15:27] <may_null> bö
[16:19] <ScottK> In the package ffcall, configure hangs indefinitely on armel in Ubuntu, but works fine in Debian.  The problematic check is http://paste.ubuntu.com/544914/.  I was wondering if someone might have a suggestion as to what the problem is.
[16:41] <sveinse> rsalveti: I found all headers I needed inside the SGX driver now
[16:41] <rsalveti> sveinse: cool
[16:41] <sveinse> I think they have started to do so with the 4.0 driver
[16:42] <sveinse> You have to search though.. But in that world nothing is logical
[16:42] <rsalveti> haha, true
[16:46] <sveinse> Can one preload a library in armel?
[17:31] <guerby> rsalveti, hmm the board crashed, last thing in ssh tail -f /var/log/messages
[17:31] <guerby> Dec 17 15:32:58 gcc44 kernel: [41654.445434] ptrace of non-child pid 4443 was attempted by: gdb (pid 4446)
[17:31] <guerby> power cycling now
[17:31] <rsalveti> ouch
[17:34] <guerby> rsalveti, it's back online, if you want to see /var/log/messages
[17:34] <rsalveti> guerby: sure, thanks
[17:34] <rsalveti> guerby: did you have any serial access?
[17:34] <guerby> rsalveti, the board did not answer ping, the usually blinking LED near the SD card was not blinking, the network LED were on
[17:34] <rsalveti> sometimes we get just the kernel trace without any messages at the logs
[17:35] <rsalveti> ok, kernel probably crashed
[17:35] <guerby> rsalveti, I think I have a USB serial cable somewhere if you think it's useful
[17:35] <rsalveti> guerby: it's good to have it connected at uart for cases like this one
[17:36] <guerby> rsalveti, ok will try to get serial over the weekend
[17:36] <rsalveti> and I'll try to debug the mem issue this weekend too
[17:36] <rsalveti> many other issues around these days
[17:37] <guerby> rsalveti, :)
[17:37] <guerby> rsalveti, munin graph: http://gcc12.fsffrance.org/munin/fsffrance.org/gcc44.fsffrance.org.html
[17:38] <rsalveti> cool
[17:39] <guerby> rsalveti, bigger iron here :) http://gcc12.fsffrance.org/munin/fsffrance.org/gcc10.fsffrance.org-cpu.html
[17:39] <guerby> http://gcc12.fsffrance.org/munin/fsffrance.org/gcc10.fsffrance.org-memory.html
[17:39] <guerby> thanks AMD :)
[17:39] <rsalveti> wow :-)
[17:40] <guerby> rsalveti, no RAM issues :)
[17:41] <rsalveti> for sure!
[22:20] <kimitsu> hello
[22:20] <kimitsu> it's a good channel for linux on pda ??
[22:47] <GrueMaster> As long as the pda is armv7 capable, maybe.