[08:43] <hrw> morgen
[08:58]  * cwillu pokes
[08:59] <cwillu> you're not rcn-ee :/
[10:50] <hrw> if I want to change something in ubuntu kernel config for panda how to get .config in other way then cp /boot/config-*?
[10:51] <cwillu_at_work> hrw, that's the only way, unless /proc/config has been enabled in the kernel (which it hasn't in ubuntu afaik()
[10:52] <hrw> cwillu_at_work: "apt-get source linux-ti-omap4" gave me ubuntu source package but it uses split config
[12:39] <sebjan_> hrw: to get the running defconfig, just run zcat /proc/config.gz
[12:40] <hrw> let me rephrase question: how to get kernel config from inside of linux-ti-omap4 source package?
[12:42] <sebjan_> hrw: ok, sorry. the config shall be in a folder debian.ti-omap4/config/config.common.ubuntu. Do you have this file in the source package?
[12:45] <hrw> yep - but tahts all?
[12:46] <sebjan_> hrw: yes, what did you expect?
[12:46] <hrw> preferred to be sure - split configs exists for a reason
[12:47] <sebjan_> hrw: right, it is not used in this case, not sure why actually...
[12:48] <hrw> sebjan_: one flavour only
[12:49] <sebjan_> yes, it makes sense...
[14:28] <ogra> hrw, so looking at your genesi f-k patch, it seems to expect that /boot is a vfat
[14:28] <ogra> that wont work
[14:49] <hrw> ogra: flash-kernel is set of hacks already
[14:49] <ogra> hrw, that doesnt solve the probelm that /boot cant be vfat :)
[14:49] <hrw> on smarttop it is ext2 by default
[14:50] <hrw> smartbook I mean
[14:50] <ogra> oh, that seems fine then, is it the same on smartbook ?
[14:50] <ogra> ah
[14:50] <hrw> markos_: does smarttop has /boot/ also on pata drive like it is in smartbook?
[14:51] <ogra> and does it use ext2 too ?
[14:51] <ogra> :)
[14:51] <markos_> ogra: initially it used vfat but now with new uboot it's able to use ext2 as wel
[14:51] <markos_> but yes
[14:52] <ogra> hrw, well, if its all ext2 then your patch seems fine to me
[14:53] <markos_> it needs a uboot upgrade though
[14:53] <hrw> ogra: I would prefer rewrite of whole script but no devices to check does it works properly on all
[14:53] <markos_> old smarttops will have to be upgraded first
[14:54] <ogra> hrw, i would prefer we split flash-kernel in functions and device spcific parts ... but i guess that needs wider discussion with debian-arm
[14:54] <hrw> yep
[14:54] <ogra> i.e. have a flash-kernel-common package that provides script snippets we can source
[14:55] <hrw> ogra: even flash-kernel can get rewrite properly
[14:56] <ogra> well, heh
[14:56] <ogra> f-k is somewhat constantly being rewritten
[14:56] <hrw> compare omap_flash_kernel and efikamx_flash_kernel functions
[14:57] <hrw> both have update_uImage_symlink() update_initrd_symlink()
[15:00] <ogra> hrw, well, theye functions come from NCommander for his generic update
[15:00] <ogra> which is very broken anyway
[15:01] <ogra> they neerd fixing all over
[15:01] <ogra> *need
[15:04] <hrw> I am a bit tired of rewriting update scripts again and again
[15:04] <hrw> few years ago I merged 5-6 zaurus update scripts into one
[15:04] <ogra> right
[15:04] <hrw> took year to get it tested on all supported devices and 2-3 developers more
[15:04] <ogra> what i want is device specific functions separate from HW specific ones
[15:05] <ogra> i.e. update NAND ... update u-boot_vfat separated from the omap or dove or whatever functions
[15:06] <hrw> it looks like omap and dove support was added by ubuntu
[15:06] <ogra> yes
[15:06] <ogra> omap was initially aded by me, dove comes from NCommander
[15:07] <ogra> both were completely redone when NCommander added the "improved subarch detection" stuff
[15:07] <hrw> style is completely different
[15:07] <ogra> yes
[15:07] <ogra> it was initally identical
[15:07] <ogra> but the spec was implemented in a way to use uname instead of /proc/cpuinfo
[15:08] <ogra> which breaks the style
[15:10] <ogra> hrw, for that part you should discuss with NCommander
[15:11] <ogra> this change also introduces bugs for unsupported boards ... i.e. it makes it try to flash to NAND on blaze (where no nand exists)
[16:18] <hrw> how to get default set of kernel options for arm device in ubuntu?
[16:22] <ogra_ac> hrw, /boot/config-$(uname -r)
[16:22] <ogra_ac> for source config, ask the kernel team
[16:22] <rsalveti> don't know exactly how the kernel selects the default options for arm in general
[16:22] <hrw> k
[16:22] <rsalveti> but at the git repository you can already check what is common
[16:22] <rsalveti> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=debian.master/config/armel/config.common.armel;h=0f0e053b1780d9d67b9c0ac7d1051fabf3d176b8;hb=HEAD
[16:22] <rsalveti> for example
[16:22] <rsalveti> as the master repo has both omap and versatile
[16:22] <ogra_ac> well, the actual config is merged from nippets during package build iirc
[16:22] <rsalveti> yup
[16:22] <ogra_ac> *snippets
[16:23] <hrw> ok
[16:23] <hrw> thx
[16:23] <rsalveti> hrw: but the "default" options is something that maybe someone from the kernel team can help you
[16:23] <ogra_ac> easiest is really to just wget the binary and dpkg -x it i bet
[16:23] <hrw> ok
[16:23] <hrw> trying to make efikasb kernel to be more ubuntu like
[16:24] <ogra_ac> build a package ;)
[16:24] <hrw> already did
[16:25] <ogra_ac> ah, cool
[16:25] <rsalveti> there are also some extra ubuntu sauce generally applied at ubuntu's kernel
[16:25] <rsalveti> don't know if you wan to check those too
[16:25] <rsalveti> hrw: and which version are you building? the stock 2.6.31 kernel?
[16:25] <ogra_ac> you should add them if possible, often distro userspace features correspond to them
[16:26] <hrw> rsalveti: yes 2.6.31.14.6
[16:26] <hrw> and do not plan to add ubuntu patches on top of it
[16:26]  * hrw is not kernel hacker
[16:27] <cooloney> oh, are you guys talking about linaro kernel or ubuntu kernel?
[16:27] <ogra_ac> what i did for the ac100 kernel was to ssh into my panda that had a source tree, copy the config to .config and then run make menuconfig on both
[16:27] <hrw> none of those cooloney
[16:27] <cooloney> rsalveti: how's going, had a nice vacation?
[16:28] <cooloney> hrw: got this, man
[16:28] <ogra_ac> its very time consuming to do it that way but you will end up with modtly identical configs
[16:28] <ogra_ac> *mostly
[16:28] <rsalveti> cooloney: yup, very nice :-)
[16:28] <cooloney> rsalveti: great. man
[16:29]  * cooloney just read a news, Marvell release a qual-core ARM chip
[16:29] <hrw> CONFIG_SCSI_MULTI_LUN is not set in TI-omap4... bad
[16:29] <rsalveti> cooloney: how was plumbers?
[16:30] <rsalveti> hrw: ti-omap4 unfortunately doesn't contain all arm common defines at the master repo
[16:30] <cooloney> http://www.marvell.com/company/news/press_detail.html?releaseID=1447
[16:30] <cooloney> rsalveti: very good
[16:31] <cooloney> met several linux-omap folks and other ARM guys
[16:31] <hrw> rsalveti: extra fun is that efikas have usb-wifi which rt2800usb does not want to load firmware for (and same firmware works with staging driver)
[16:31] <rsalveti> cooloney: cool :-)
[16:32] <cooloney> hrw: what's CONFIG_SCSI_MULTI_LUN for?
[16:32] <rsalveti> hrw: haha :-)
[16:32] <cooloney> hrw: i guess it is for some multi volume USB disk?
[16:32] <hrw> cooloney: Prompt: Probe all LUNs on each SCSI device
[16:32] <hrw> cooloney: think: real multislot card readers for example
[16:33] <ogra_ac> does the efika have that ?
[16:33] <hrw> cooloney: and I have one of those
[16:33] <hrw> ogra_ac: I have such on usb
[16:33]  * GrueMaster drools over the marvel XP specs.
[16:33] <ogra_ac> oh, that doesnt show as usb disks ?
[16:33] <ogra_ac> intresting
[16:35] <hrw> ogra_ac: without multi_lun only CF works. with: cf, sd, ms, xd
[16:35] <ogra_ac> well, then we should enable it asap
[16:35] <ogra_ac> file a bug ;)
[16:35] <hrw> ogra_ac: popular cheap multislot readers have one controler so one card at time. this one handle 4 cards at same time
[16:37] <cooloney> hrw: good point. could you please file a bug, then we can SRU a patch
[16:37] <hrw> bug 672635
[16:37] <ubot2> Launchpad bug 672635 in linux-ti-omap4 (Ubuntu) "enable CONFIG_SCSI_MULTI_LUN (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/672635
[16:39]  * ogra_ac triages it properly
[16:40] <cooloney> hrw: thx, man, you are so quick
[16:41] <ogra_ac> sbambrough, hey
[16:41] <sbambrough> hey ogra_ac
[16:41] <ogra_ac> sbambrough, are you subscribed to ubuntu-devel ?
[16:42] <ogra_ac> (the mailing list)
[16:42] <ogra_ac> i sent some questions regarding the possibility about using linaor kernels to it today, might intrest you too
[16:42] <ogra_ac> *linaro
[16:43] <sbambrough> ogra_ac,  I don't believe I am
[16:43] <ogra_ac> https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031952.html
[16:43] <ogra_ac> cooloney, ^^^ something to bring up at the kernel team meeting i belive
[16:46] <sbambrough> ogra_ac, your right they do interest me, though I don't have any answers right now
[16:46] <cooloney> ogra_ac: ok, got it.
[16:46] <ogra_ac> sbambrough, yeah, i dont expect answers right now, but we need to find some ;)
[17:51] <rsalveti> ogra_ac: were you able to test the new qt packages?
[17:51] <ogra_ac> rsalveti, yes
[17:51] <rsalveti> and?
[17:51] <ogra_ac> Illegal instruction
[17:51] <ogra_ac> :(
[17:51] <ogra_ac> see the bug
[17:51] <ogra_ac> tiago also commented
[17:52] <rsalveti> oh, cool, too much emails at my inbox
[17:53] <ogra_ac> sadly it doesnt seem to work as expected
[17:53] <ogra_ac> tiagos test of just running the lib seems to show no misdetectin though
[17:55] <GrueMaster> Might be another failure point.
[17:55] <ogra_ac> i.e. i dont get the processor features line he mentions
[17:55] <ogra_ac> GrueMaster, well, its definitely NEON related given just building it with NEON disabled makes it all work fine
[17:56] <GrueMaster> What I mean is it may be code that is ouside the run-time detection.
[17:57] <rsalveti> ogra_ac: remember he's using qt 4.7.1 while posting at the bug
[17:57] <ogra_ac> rsalveti, yeah
[17:57] <rsalveti> maybe this processor features is not there for the version we're using
[17:57] <rsalveti> I don't get it even on panda
[17:57] <ogra_ac> yup
[17:58]  * ogra_ac hasnt set up his panda yet for cross checking
[17:58] <GrueMaster> What's the bug number again?  I can test the code on my dove to verify.
[17:58] <ogra_ac> i have barely unpacked my suitcase
[17:58] <rsalveti> bug 664431
[17:58] <ubot2> Launchpad bug 664431 in qt4-x11 (Ubuntu Natty) (and 2 other projects) "QT on armel is built with NEON by default (affects: 2) (dups: 1) (heat: 30)" [Undecided,New] https://launchpad.net/bugs/664431
[18:01] <rsalveti> ogra_ac: does it also crashes while running QT_NO_NEON=1 mumble?
[18:01] <ogra_ac> yep
[18:02] <rsalveti> could be the case that the features thing is not working the way expected
[18:02] <ogra_ac> yes, i would expect so
[18:02] <rsalveti> I don't believe it was ever tested on a no-neon hardware
[18:02] <ogra_ac> to sad that slangasek already dropped the working packages
[18:03] <slangasek> "working"?  those packages were sitting verification-failed for some time before I removed them
[18:03] <rsalveti> would be good to trace the error
[18:03] <ogra_ac> slangasek, huh ? who did set that ?
[18:03]  * ogra_ac checks the bug
[18:04] <Jefro> hi all - if anyone has a second to help me get rcn-ee's scripts working for a beagleboard, I'd love a hand
[18:04] <ogra_ac> slangasek, now thats weird, while i see that pitti set it to failed i dont get why
[18:04] <slangasek> ogra_ac: because it was reported to regress on non-NEON systems
[18:05] <ogra_ac> Jefro, best is to wait for rcn-ee for that
[18:05] <ogra_ac> slangasek, err, no, exactly the opposite
[18:05] <ogra_ac> slangasek, it fixed it for non-NEON systems
[18:05] <slangasek> oh right; it was reported to regress on NEON systems
[18:05] <Jefro> ogra_ac - thanks
[18:05] <ogra_ac> which is nonsense

[18:06] <ogra_ac> given we announce that no library in maverick will do NEON
[18:06] <ogra_ac> so it breaks a commitment
[18:06] <slangasek> no library in maverick will *require* NEON
[18:06] <ogra_ac> right
[18:07] <ogra_ac> given that QT in maverick can currently only be build with statically having NEON on or off my upload was a proper fix
[18:07] <ogra_ac> that upstream tried to add dynamic detection doesnt make the fix less valid
[18:09] <ogra_ac> until we have a dynamic fix in place at least
[18:10] <rsalveti> ogra_ac: I also believe it is a post release regression to just disable it at qt
[18:10] <rsalveti> I know we're saying we're building without neon by default
[18:10] <rsalveti> but would be strange for users to have qt running slower because of an update
[18:10] <ogra_ac> well
[18:10] <rsalveti> doesn't make sense to me
[18:10] <ogra_ac> talk to davidm
[18:11] <rsalveti> that's why I thought it would be better to just fix the run time detection
[18:11] <ogra_ac> i had a pretty strict request to switch it off immediately
[18:11] <rsalveti> ogra_ac: why? it's a ubuntu discussion in general, I understand the problems
[18:11] <ogra_ac> yes, i agree that runtime detection is a better fix, but if it doesnt work we have to fix it another way
[18:12] <rsalveti> sure, in case it doesn't work we just disable it
[18:12] <ogra_ac> and apparently the only way is static atm
[18:12] <rsalveti> but first let's try to get the proper fix in
[18:12] <ogra_ac> right
[18:12] <ogra_ac> but the "proper" fix seems ot require far more currently
[18:12] <ogra_ac> since just backporting from upstream doesnt seem to work
[18:13] <rsalveti> it seems, let's at least get the correct trace
[18:13] <rsalveti> and identify what's happening
[18:13] <rsalveti> don't think that will take a lot of time
[18:13] <ogra_ac> no
[18:14] <ogra_ac> what i'm concerned about it that i already drown in mail from people running QT apps on the ac100, that the working packages were removed from proposed is a bit disturbing
[18:14] <rsalveti> I know, but let's give at least one or two days to try to get the proper fix
[18:14] <ogra_ac> yes
[18:15] <rsalveti> now that you have the hardware and can try to trace the problem
[18:15] <rsalveti> if we're unable to fix, push the new packages without neon at all and we're fine
[18:15] <ogra_ac> right, though i wont do that tonight anymore ... i'm jetlagged and did get off a plane less than 24h ago
[18:16] <rsalveti> ogra_ac: sure, take your time
[18:16] <rsalveti> ogra_ac: go to sleep then :-)
[18:16] <ogra_ac> i would have tested during plumbers, but they dont have an elmo (read: the network there was so bad that most of us couldnt even get their mails)
[18:17] <rsalveti> yeah, elmo rocks
[18:17] <rsalveti> uds was perfect
[18:17] <ogra_ac> to early for bed yet ... need to stay up to get my schedule correct
[18:17] <ogra_ac> just thinking is a bit hard atm :)
[18:17] <rsalveti> :-)
[18:18] <ogra_ac> plumbers was depressing overall
[18:19] <rsalveti> ogra_ac: why? no interesting stuff to discuss this year?
[18:19] <ogra_ac> now that they are over upstart vs systemd they start bashing us for copyright assignment
[18:20] <rsalveti> haha, they will always find something to complain :-)
[18:20] <ogra_ac> well, there was intresting stuff but i didnt like the mood
[18:20] <ogra_ac> also seeing how lennart pulled strings to make all upstreams use systemd and Keybuk not being there at all to be able to stop that was annoying
[18:20] <ogra_ac> seems that many userspace things will defauolt to systemd in the  near future
[18:21] <ogra_ac> i.e. gnome-session will go away
[18:21] <rsalveti> got it
[18:21] <ogra_ac> all in all it felt like a redhat/intel conference
[18:21] <ogra_ac> i felt very misplaced
[18:21] <rsalveti> but it was, somehow
[18:21] <ogra_ac> yes
[18:22] <ogra_ac> its just sad to see that so many important decisions are made there and that they are made with an anti ubuntu attitude in mind
[18:53] <GrueMaster> ogra_ac: rsalveti:  Ok, after many interruptions, I finally downloaded the QT library from https://launchpad.net/~rsalveti/+archive/armel/+files/libqtcore4_4.7.0-0ubuntu5_armel.deb and it seems to be ok on my dove.
[18:53] <ogra_ac> GrueMaster, you can run mumble ?
[18:53] <ogra_ac> thats my testcase on the ac10
[18:53] <ogra_ac> 0
[18:53] <GrueMaster> Haven't tried mumble.
[18:54] <GrueMaster> This is on my dove buildd (rack in basement).
[18:54] <rsalveti>  should fail while loading mumble
[18:54] <ogra_ac> right
[18:54] <GrueMaster> Other system has been offline since Dallas.
[18:54] <ogra_ac> you should get a SIGILL
[18:55] <GrueMaster> I ran it according to the instructions in the bug, comment #30.  Will find some test apps.
[18:55] <ogra_ac> comment 30 is useless with our version
[18:55] <ogra_ac> 8as you can see from the above discussion)
[18:57] <rsalveti> could -mfpu=neon optimize general fp code at the qt build?
[18:58] <rsalveti> then it'll fail for sure
[18:58] <GrueMaster> I may give my son some spare hw next time I see him.  He knows a lot about QT.
[18:58] <ogra_ac> GrueMaster, just run mumble ;)
[18:58] <ogra_ac> thats a safe test
[18:58] <ogra_ac> no need to install a desktop for that, just use ssh -X user@dove mumble
[18:58] <GrueMaster> I can't.  The system has a minimal install for building.  No X.
[18:59] <GrueMaster> Still need to install for dependencies.
[18:59] <ogra_ac> use a chroot
[18:59] <ogra_ac> its not that it will take much time with a local mirror
[18:59] <GrueMaster> I'll unpack my A0 and get it running in a bit.
[19:00] <GrueMaster> It looks like it will take 64 minutes just to pull the PPA packages.
[19:00] <GrueMaster> They're not mirrored.
[19:00] <ogra_ac> ah
[19:02] <GrueMaster> Not sure if it is my end or lp, but I am only getting 3.8K/s pulling the packages from rsalveti's ppa.
[19:09] <rcn-ee> Jefro, ping
[19:11] <Jefro> rcn-ee hey!  thanks - I am having difficulty with the beagleboard script
[19:11] <rcn-ee> hey Jefro,which of the scripts are you haing issues with? is it doing something odd?
[19:11] <Jefro> ./setup_sdcard.sh gives me a syntax error
[19:12] <Jefro> ./setup_sdcard.sh: line 333: syntax error near unexpected token `>'
[19:12] <rcn-ee> that might be a bashism.. ;)
[19:12] <Jefro> it must be.  the line has a " &>> " in it.
[19:13] <rcn-ee> is that the 'sd.log' part of the script? you can just comment that out, it's just to make it less noisy..
[19:13] <Jefro> I succeeded in getting it to work by putting a space between & and >> but now I think I probably should have just taken out the & and put a 2&>1 at the end
[19:13] <Jefro> ah, ok - looking
[19:13] <Jefro> yes, that is the sd.log line
[19:14] <Jefro> the resulting image, however, fails to boot on my xM A2
[19:14] <Jefro> well, it boots up to a certain point but then fails with 'no init' and leaves me at an (initrd) prompt
[19:14] <rcn-ee> yeah, just nuke the "&>> ${DIR}/sd.log"  i'll come up with something else to work better with dash..
[19:15] <rcn-ee> That's weird, what was your full "./setup..." line?
[19:15] <rcn-ee> (i have an A2 i test it on..)
[19:15] <Jefro> ./setup_sdcard.sh --mmc /dev/sdf --uboot beagle --use-default-user
[19:15] <Jefro> I'll try it again, just a sec (currently running rsalveti's preinstalled image)
[19:16] <rcn-ee> weird, that's perfect....
[19:18] <rcn-ee> by chance is it 16/8g card? i've had some users report problems with that, but haven't been able to replicate it..
[19:19] <Jefro> 4G Kingston card
[19:19] <Jefro> oops, no, that's the other one - this is a 4G no-name card
[19:20] <Jefro> I'll try it on the Kingston card
[19:21] <rcn-ee> another thing, if the script dies on error, it actually doesn't finish building the image..
[19:23] <Jefro> it looked like it completed - running now on different card
[19:24] <Jefro> looks like it completed.  the last line is "Formatting Boot Partition."
[19:24] <rcn-ee> that's not even close.. ;)
[19:24] <Jefro> hoo boy.  is there a -v I can turn on?
[19:24] <Jefro> I'm running this on Ubuntu 8.10 BTW
[19:24] <Jefro> if that makes a dif
[19:25] <rcn-ee> not really, it's a pretty simple/stupid script.. ;)  the last thing it really says "Populating rootfs Partition"
[19:26] <Jefro> ha... well, that may be why it only got as far as initrd!
[19:26] <rcn-ee> i'm suprised it got that far... if it died after building the first fatfs, there shouldn't have even been an uImage...
[19:27] <Jefro> it looks like it populated the boot partition
[19:27] <Jefro> this is for a "getting started" article, so I may go with rsalveti's premade script for now and point readers at the rootstock instructions if they want to go further.  Does that sound reasonable?
[19:27] <rcn-ee> so maybe 8.04 just didn't like the "&>>"...  format fatfs, copy bootloader, format ext, copy rootfs...
[19:28] <Jefro> very possibly.  I'll try it on my laptop, which has 9.10 installed.
[19:30] <rsalveti> Jefro: pre-installed image is easier for the first moment
[19:30] <rsalveti> then you can point for advanced customizations
[19:30] <rsalveti> and also rcn-ee's kernel
[19:30] <rsalveti> in case people want to hack the normal ubuntu image
[19:31] <rcn-ee> rsalveti, you guys ready for another sru the next "xm"? ;) (u-boot)..
[19:31] <rsalveti> rcn-ee: haha :-)
[19:32] <rcn-ee> i saw them on the u-boot list, and went oh my..... ;)
[19:35] <rsalveti> rcn-ee: that's why for natty we'll be upgrading the x-loader/u-boot when needed
[19:35] <rsalveti> or at least warn the user that he needs to update it, and create a tool for it
[19:36] <rsalveti> but yeah, sru all around :-)
[19:36] <rsalveti> GrueMaster: later on if you want to help and have enough time, please help getting the qt trace
[19:37] <GrueMaster> Will do.
[19:37] <rsalveti> so we can find where and which instruction is breaking qt
[19:37] <rsalveti> I'd like to get some kind of qt benchmark, to compare the performance with and without neon
[19:38] <rsalveti> will try to dig one at the qt examples/tests/demos files at the git tree
[19:38] <Jefro> rsalveti rcn-ee thanks for the help
[19:39] <GrueMaster> Thats why I want to get my son involved.  He can create one.
[19:50] <rlameiro> ogra_ac: are you running on the AC100?
[19:52] <rsalveti> GrueMaster: do you remember where you got the cpuburn package while stressing panda at dallas?
[19:53] <rsalveti> don't remember if vstehle gave us or we just got it somewhere
[19:53] <ogra_ac> rlameiro, yes, i do
[19:54] <vstehle> rsalveti, GrueMaster, you need to grab the latest cpuburn at http://pages.sbcglobal.net/redelm/ and compile the arm binaries
[19:54] <rsalveti> vstehle: cool, thanks
[19:54] <rlameiro> ogra_ac: How is it working? does everything works now? I am lining to buy one... on amazon
[19:54] <rsalveti> need to push that to our archive
[19:54] <rsalveti> orbarron: ^
[19:54] <Jefro> rcn-ee - new data point, when I used 9.10 to write the card it did get all the way to "populating rootfs" but still doesn't boot:  "No init found." and an (initramfs) prompt.
[19:55] <ogra_ac> rlameiro, nope, things are slowly getting better i think, but i havent tried any of the new hacks from phh yet
[19:55] <vstehle> (I requested packaging in Bug #651576)
[19:55] <ubot2> Launchpad bug 651576 in cpuburn (Ubuntu) "cpuburn now has Cortex-A8 and Cortex-A9 versions, please build for armv7a (affects: 1) (heat: 95)" [Undecided,New] https://launchpad.net/bugs/651576
[19:55] <rlameiro> ok
[19:55] <rlameiro> i go to the ac100 to see if I can extract more info ;)
[19:55] <ogra_ac> they are just trying to get backlight on/off on lid close to work
[19:56] <cwillu_at_work> rcn-ee, poke poke
[19:56] <ogra_ac> i personally was traveling fo ra few weeks, just got back yesterday
[19:56] <rcn-ee> hey cwillu_at_work that zippy still failing?
[19:56] <cwillu_at_work> hey;  only when I start up the network
[19:56] <cwillu_at_work> haven't been able to get any kernel messages out of it though
[19:57] <prpplague> cwillu_at_work: zippy giving you trouble?
[19:57] <rcn-ee> so every boot...  how do you like the ck patchset?
[19:57] <cwillu_at_work> prpplague, ooo, both of you at the same time :)
[19:57] <prpplague> cwillu_at_work: zippy or zippy2 ?
[19:57] <cwillu_at_work> 2
[19:57] <cwillu_at_work> prpplague, ks8851 troubles, specifically
[19:58] <cwillu_at_work> rcn-ee, nothing conclusive yet;  I'm using it on this desktop, and it seems to be an improvement, although I'm waiting another week until I say that for sure
[19:58] <cwillu_at_work> (the problem with long uptimes is that you're never sure if things are faster because you rebooted, or because of the thing you changed that caused you to reboot)
[19:58] <rcn-ee> okay, cool...  i have a patchset saved on my work machine for the ck stuff that i'm about to push.. ;)
[19:59] <rcn-ee> true true..
[19:59] <cwillu_at_work> prpplague, want to know about my ks8851 troubles? :p
[19:59] <prpplague> cwillu_at_work: yea
[20:00] <cwillu_at_work> prpplague, cable plug events don't seem to make it to network manager et al
[20:00] <cwillu_at_work> prpplague, I hacked something up with mii-tool (which polls the mii status directly once per second) to simulate the behaviour
[20:00] <prpplague> cwillu_at_work: do the events show up on the CL level?
[20:00] <cwillu_at_work> nope
[20:00] <prpplague> interesting
[20:01] <prpplague> you using it with a panda or beagle?
[20:01] <cwillu_at_work> beagle
[20:01] <cwillu_at_work> c3 and c4
[20:01] <GrueMaster> vstehle: pulling it now.
[20:01] <cwillu_at_work> prpplague, no, the _interesting_ part is that if I restart network manager _while_ copying data to a local machine _while_ mii-tool is running, everything dies
[20:01] <prpplague> right now i only have panda's at my desk, i'll have to pick up a beagle from the office to do some testing
[20:02] <prpplague> interestin
[20:02] <cwillu_at_work> I think I have a stack trace around still
[20:02] <cwillu_at_work> it dies in a weird fashion too :)
[20:02] <cwillu_at_work> processes go into uninteruptable state;  I _think_ it's when they try to access the network, but I'm not certain  (x will hardlock, for instance)
[20:02] <cwillu_at_work> sysrq-w shows them in that state though
[20:03] <cwillu_at_work> the end of the dmesg is a preempt count oops or something
[20:03]  * cwillu_at_work looks for it
[20:11] <cwillu_at_work> sorry, my hairy electrician called
[20:11]  * cwillu_at_work starts looking again
[20:11] <cwillu_at_work> prpplague, http://pastebin.com/ZPXdqwfw
[20:11]  * prpplague looks
[20:11] <cwillu_at_work> I've got another trace with some magic sysrq info as well
[20:12] <prpplague> cwillu_at_work: interesting
[20:16] <cwillu_at_work> sysrq log coming
[20:20] <cwillu_at_work> prpplague, http://pastebin.com/vdrrr8iL
[20:20]  * prpplague looks
[20:21] <cwillu_at_work> prpplague, I don't know that it's related, but::  I had rcn-ee compile me a 2.6.36 with ck2 (con kolivas's patchset with scheduler and vm changes) for kicks;  it works fine under fairly heavy load for days, until I connect the zippy's ethernet and configure the interface;  moments later, the system hardlocks
[20:22] <cwillu_at_work> I haven't been able to capture any messages from such a failure though
[20:22] <prpplague> just a rough guess would be that the communication with the KS8851 is getting part of the packet trashed and it is trying to read beyond the allocated packet
[20:22] <prpplague> i'd have to check but there were some similar problems reported with blaze
[20:23] <prpplague> (blaze uses the KS8851 in the exact same way as the zippy2)
[20:24] <cwillu_at_work> prpplague, I _don't_ get the problem unless I have both mii-tool running _and_ I restart network-manager _and_ there's network activity at the wrong time
[20:25] <cwillu_at_work> I've noticed this sporadically when poking a beagle remotely (i.e., the far end of a 128kb link), but I can trigger it every time if I scp a couple hundred megs locally, with "mii-tool -w" running, and then restarting network-manager with the transfer still running
[20:26] <cwillu_at_work> my guess is that mii-tool is holding something open that network-manager causes to be reset or whatever, at the same time as a packet comes in and does what you said before
[20:26] <cwillu_at_work> sporadically == once or twice a day
[20:27] <prpplague> interesting
[20:27] <cwillu_at_work> since I disabled my mii-tool hack, (restarting network-manager when an ssh connection dies rather than when mii-tool -w spits out a line), I haven't seen a single crash yet in two weeks
[20:29] <cwillu_at_work> I'm also suspicious that my ck2 crashes are related, given the scheduling changes + the "note: omap2_mcspi[14] exited with preempt_count 1" I get from a non ck2 kernel
[20:29] <cwillu_at_work> just can't prove it :p
[20:29] <cwillu_at_work> I've got several beagles and zippies and sd cards that I can duplicate this on, too :p
[20:32] <cwillu_at_work> (note, those two traces are on different kernels;  the earlier was 2.6.35rc5, longer one was 2.6.35.7
[21:06]  * cwillu_at_work pokes at prpplague 
[21:07] <cwillu_at_work> fixed it yet? :D
[21:08] <prpplague> cwillu_at_work: i'll have to see if i can replicate it on a beagle, all i have right now are pandas
[21:08] <cwillu_at_work> can a panda use a zippy2?
[21:08] <RXShorty> Hello all +~
[21:09]  * cwillu_at_work shorts RXShorty to ~neutral
[21:09] <RXShorty> Does anyone here has a Sharp Netwalker?
[21:10] <RXShorty> The reason I ask that Ubuntu 9.04 is getting old with packages, maybe someone already made a 10.04 version?
[21:12]  * rsalveti brb
[22:01] <ndec> rsalveti: hi
[22:02] <ndec> rsalveti: i was looking at pixman build log on LP, and it seems that it got compiled with NEON enabled. is that expected?
[22:02] <ndec> ogra: hi. see ^^^ in case you are here too
[22:04] <armin76> ndec: pixman has runtime neon detection
[22:04] <ndec> armin76: really? that's cool. i didn't know
[22:05] <ndec> armin76: is that documented?
[22:05] <armin76> ndec: i'm not sure, you'd have to ask ssvb since he did the work
[22:13] <ndec> armin76: looking at src, i think it's implemented in pixman-cpu.c, function _pixman_choose_implementation(). thanks for the tip
[22:21] <cooloney> ndec: could you please help to take a look at this bug 666267
[22:21] <ubot2> Launchpad bug 666267 in linux-ti-omap4 (Ubuntu) "Cross compiled headers package breaks DKMS compilation (affects: 1) (heat: 226)" [Medium,New] https://launchpad.net/bugs/666267
[22:22] <cooloney> ndec: after some discussion with andy and tim, we need some testing
[22:27] <ndec> cooloney: hi. sure we can test. where you able to test?
[22:28] <cooloney> ndec: oh, i am working from our Boston office these 2 days, don't have hardware to test
[22:28] <cooloney> ndec: will be back to home this Thursday
[22:28] <ndec> cooloney: ok. will try to see tomorrow from the office then. vstehle might be able to test this
[22:28] <cooloney> ndec: yeah, great.
[22:29] <cooloney> ndec: i think it's a bit little later for you guys
[22:29] <cooloney> now.