[00:36] tmzt, yeah thats the thing, its built in :) [00:36] mmmmm. amarula and cofee with the beer... nom nom :) [00:54] ojn was it you who I was asking about the binutils --fix-cortex-a8 thing? [00:54] awesome rsalveti thanks so much for the help. it was the " " that I shouldn't have added [00:54] pebkac :) [01:46] Neko: well, we talked about it, yeah. [01:53] so is that stuff (and the plt stuff too that was talked about in may) in linaro-gcc? :/ [02:17] Neko: no idea. I don't work with linaro, nor ubuntu. :) [02:18] :D [02:18] why did we even get to this conversation even [02:20] 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] :) [02:35] yep :] === lilstevie is now known as lilstevie|ZNC === Neko is now known as NekoSleep [07:11] hi [07:11] who know upstart? [07:11] com.ubuntu.Upstart.c [07:11] job_process.c [07:19] exit === JaMa|Off is now known as JaMa [12:45] ho [22:18] rcn-ee, oooooo [22:18] rcn-ee, I got a nice crashing bug with ks8851 [22:19] 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] rcn-ee, completely locks up the board [22:19] intermittent, had no idea what was causing it until I tripped over a solid repro case by mistake [22:20] 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] 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] rcn-ee, tx for sure, not certain about the others [22:22] I've been seeing hangs for 'no reason', without any network traffic to speak of [22:23] 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] 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] 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] 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] 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] .35 [22:25] I've been running on .35rc5 for a while, but it's reproduceable on the latest .35 as well [22:26] incidently, do you know if there's any fixes for mii state not getting reported properly? [22:26] 2.6.35.7-l6 is the one I was running [22:30] 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] 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] 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] rcn-ee, http://patchwork.ozlabs.org/patch/40247/ [22:34] hang on, I can get you the oops that came along with the crashes [22:37] yeap, that is the tx fix for the silicon bug, i have that in my patchset. (from micrel's patch dump) [22:38] nothing newer on their ftp site.. [22:42] rcn-ee, http://pastebin.com/srkcrPAM [22:44] 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] ? [22:46] it does lock up the whole board :p [22:46] kinda sorta [22:46] 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] this is what Tristan's patch was fixing : http://pastebin.com/rWbCsnhN