[00:36] <topfs2> tmzt, yeah thats the thing, its built in :)
[00:36] <topfs2> mmmmm. amarula and cofee with the beer... nom nom :)
[00:54] <Neko> ojn was it you who I was asking about the binutils --fix-cortex-a8 thing?
[00:54] <topfs2> awesome rsalveti thanks so much for the help. it was the " " that I shouldn't have added
[00:54] <topfs2> pebkac :)
[01:46] <ojn> Neko: well, we talked about it, yeah.
[01:53] <Neko> so is that stuff (and the plt stuff too that was talked about in may) in linaro-gcc? :/
[02:17] <ojn> Neko: no idea. I don't work with linaro, nor ubuntu. :)
[02:18] <Neko> :D
[02:18] <Neko> why did we even get to this conversation even
[02:20] <ojn> Because I said "I can't believe Freescale hasn't fixed their silicon", and you said they have but you have old hardware that you need the fix for. :)
[02:21]  * ojn goes to find a tv couch instead.
[02:21] <ojn> :)
[02:35] <Neko> yep :]
[07:11] <peter__> hi
[07:11] <peter__> who know upstart?
[07:11] <peter__> com.ubuntu.Upstart.c
[07:11] <peter__> job_process.c
[07:19] <peter__> exit
[12:45] <hrw> ho
[22:18] <cwillu> rcn-ee, oooooo
[22:18] <cwillu> rcn-ee, I got a nice crashing bug with ks8851
[22:19] <rcn-ee> hey cwillu, catching up on the irc log, so some issues with ^ ;)  just got back from texas.. so how nasty is the bug..
[22:19] <cwillu> rcn-ee, completely locks up the board
[22:19] <cwillu> intermittent, had no idea what was causing it until I tripped over a solid repro case by mistake
[22:20] <cwillu> rcn-ee, remember my muttering about how the driver's 'cable connected' state didn't seem to make it to network-manager, even though mii-tool reported it fine?
[22:21] <rcn-ee> does it occur just idle, or in a tx state or rx state..  i talked to micrel before, and we had some work arounds for a tx silicon bug..
[22:21] <cwillu> rcn-ee, tx for sure, not certain about the others
[22:22] <cwillu> I've been seeing hangs for 'no reason', without any network traffic to speak of
[22:23] <cwillu> but if I pull half a meg from the beagle over the network, while mii-tool is in its polling mode, and restart network manager during the transfer, the whole system will gradually lock up
[22:23] <cwillu> sysrq-w (?) ends up showing a couple dozen tasks blocked in uninterruptable sleep (many of which have no network activity involved in them)
[22:24] <cwillu> so, disabling my fake-mii job (which works by restarting network-manager whenever mii-tool detects a change) occasionally (but often several times in a row) locks up the system
[22:24] <cwillu> I know there's no cable state changes involved though, which confuses me:  the crash doesn't occur unless network manager is restarted
[22:25] <rcn-ee> humm, that sounds like the same old TX bug..  I'll set up my rig again, something must have changed to bring it back.. which kernel version?
[22:25] <cwillu> .35
[22:25] <cwillu> I've been running on .35rc5 for a while, but it's reproduceable on the latest .35 as well
[22:26] <cwillu> incidently, do you know if there's any fixes for mii state not getting reported properly?
[22:26] <cwillu> 2.6.35.7-l6 is the one I was running
[22:30] <rcn-ee> checking out micrel's ftp site, the last i had from them was April 2010.. there might be something newer, otherise i'm not sure about the mii state..
[22:31] <cwillu> now that I know what it is, I've set things up to restart the network when a particular connection dies instead of using mii-tool, but yeah, it'd be nice if cable-plug events worked :)
[22:32] <cwillu> rcn-ee, this definitely wasn't related to 'heavy traffic' (looking at "fix ks8851 snl transmit problem", if that's the patch you're referring to)
[22:34] <cwillu> rcn-ee, http://patchwork.ozlabs.org/patch/40247/
[22:34] <cwillu> hang on, I can get you the oops that came along with the crashes
[22:37] <rcn-ee> yeap, that is the tx fix for the silicon bug, i have that in my patchset. (from micrel's patch dump)
[22:38] <rcn-ee> nothing newer on their ftp site..
[22:42] <cwillu> rcn-ee, http://pastebin.com/srkcrPAM
[22:44] <rcn-ee> interesting, very weird the omap spi side crashed.. (so 50/50 ks8851/omap spi)...  on the dumps i saw before it was the ks8851 side that crashed and it would lock up the whole board..
[22:45] <cwillu> ?
[22:46] <cwillu> it does lock up the whole board :p
[22:46] <cwillu> kinda sorta
[22:46] <cwillu> sorry, I need to run, but I'll be around later, and I can do testing on this now that I know how to reproduce it
[22:47] <rcn-ee> this is what Tristan's patch was fixing : http://pastebin.com/rWbCsnhN