[03:25] <DanaG> http://www.phoronix.com/scan.php?page=news_item&px=ODc3NA
[03:25] <DanaG> Matches my opinion of ARM stuff.
[03:44] <RobotGuy> I just built a fresh Ubuntu image using rootstock.  It boots up fine, but won't go to the internet. Network settings are as they should be except for the fact the iface shows as usb0 instead of usb1.
[03:51] <RobotGuy> Does rootstock not install kernel modules into images??
[03:52] <rsalveti> RobotGuy: not by default, you need to request it to install the kernel package you want
[03:58] <RobotGuy> OK, how do I know what kernel packages are available.  I want the latest.
[04:03] <rsalveti> RobotGuy: it depends on which machine are you using
[04:03] <rsalveti> there's one kernel for omap 3 and another for omap 4, for example
[04:03] <RobotGuy> BeagleBoard-xM
[04:04] <RobotGuy> OMAP3
[04:05] <rsalveti> then calling with --seed linux-image-omap should get you the latest omap 3 kernel
[04:07] <RobotGuy> OK, thanks.  I'm rebuilding my image now.
[04:13] <RobotGuy> Do I need something like kernel-sources to get the sources for the kernel image?
[04:13] <RobotGuy> Or maybe linux-config-omap ??
[04:13] <rsalveti> generally to build modules you just need the kernel headers
[04:14] <rsalveti> but you can also get the sources from the deb package itself
[04:14] <RobotGuy> I need the entire kernel sources in my case.
[04:15] <RobotGuy> I need my kernel sources and config to match the kernel that is running.
[04:15] <rsalveti> maybe linux-source-2.6.35 is what you need
[04:15] <rsalveti> the config is already installed with the linux-image-omap
[04:15] <rsalveti> you can find it at /boot
[04:15] <RobotGuy> OK, good.
[04:17] <RobotGuy> I think the kernel stuff should be mentioned on the rootstock part of the wiki.
[04:19] <rsalveti> RobotGuy: sure, feel free to add it there
[04:20] <RobotGuy> I'm planning to. :)
[04:22] <RobotGuy> What do I have to do to gain write access to the wiki?  Where do I sign up?
[04:23] <rsalveti> RobotGuy: if you already have an account at launchpad all you need to do is to sign up
[04:23] <rsalveti> I believe it's on the left-up corner
[04:24] <rsalveti> sorry, right-up
[04:30] <RobotGuy> Seems easy to miss.  I found a create account link by clicking login.
[04:45] <RobotGuy> I'm getting an Internal Server Error when I try to edit a page.  Do I need special access to edit?  I see the edit link.
[04:46] <rsalveti> you should be able to edit it normally
[04:46] <rsalveti> probably a bug at the wiki system, or server atm
[04:46] <rsalveti> ubuntu
[04:47] <rsalveti> argh, wrong terminal
[06:02] <RobotGuy> Are there any know networking issues with a BeagleBoard-xM?? I can't ping out or access the internet in any way and yet all my networking settings are correct. It sees the network interface as usb0.
[06:04] <RobotGuy> An unoffical "ubuntu" setup works fine on the network.
[06:17] <DanaG> RobotGuy: there are two network interfaces on xM: usb-ethernet on board, and the host USB thingy (like with mobile phones).
[06:25] <RobotGuy> Only usb0 is seen as a network device.
[06:25] <RobotGuy> Which seems odd because another "ubuntu" setup seens usb0 and usb1 but only usb1 works for network.
[06:26] <RobotGuy> I need the usb-ethernet.
[06:27] <DanaG> WEird... I'd expect usb-ethernet to be eth0.
[06:27] <RobotGuy> DanaG: That's not what it comes up as on the other setup. It comes up as usb1
[06:27] <DanaG> WEird.
[06:27] <DanaG> Granted, I haven't used xM first-hand.
[06:28] <RobotGuy> Perhaps.
[06:28] <DanaG> What's the actual driver behind the usb-ethernet?
[06:32] <RobotGuy> The only module loaded is usbhid. :(
[06:32] <RobotGuy> I don't know the actual driver that works for the ethernet on a Beagle-xM.
[06:33] <DanaG> Weird.  Maybe compiled-in?
[06:34] <RobotGuy> Well, it isn't working so I am guessing it isn't compiled in.
[12:32] <ogra_ac> ndec, is there a call today ?
[12:42] <cwillu_at_work> rcn-ee, hey, anything of interested re: micrel?
[12:42] <rcn-ee> nope, haven't heard back...
[12:43] <rcn-ee> how's the week testing of bfs gone? any odd things show up?
[12:43] <cwillu_at_work> my desktop's still working great
[12:43] <cwillu_at_work> haven't been able to do much with it on the beagle though, given the network trouble
[12:44] <cwillu_at_work> (chrome is <3 though :p)
[12:44] <rcn-ee> it is sweet...  it's after i ran it on the beagle for the first time i switched everything to it..
[12:45] <cwillu_at_work> I also like how I don't need any extensions to get it running in kiosk mode :)
[12:46] <cwillu_at_work> although:  css rounded borders kill the scrolling performance on arm, for some reason
[13:00] <cwillu_at_work> rcn-ee, too bad about the lack of / searching
[13:00] <cwillu_at_work> ctrl-f is such an annoying combination to type for searching
[13:01] <rcn-ee> yeah it is.. then if the page isn't fully loaded you have to kill the search and redo..
[13:01] <rcn-ee> just can't hit enter again..
[13:38] <cwillu_at_work> rcn-ee, got a maybe-working serial link now, going to try to get more info from that zippy + ck2 lockup
[13:48] <cwillu_at_work> sysrq-9 is maximum verbosity, or sysrq-1?
[13:57] <cwillu_at_work> rcn-ee, nothing shows up when it locks up
[13:58] <rcn-ee> that's a bummer...  did this not occur in a previous version? thinking of bisecting..
[13:59] <cwillu_at_work> good question, let me check
[13:59] <cwillu_at_work> (I've been using 2.6.35 for a while)
[13:59] <cwillu_at_work> will take a minute, need to restore the old uImage before I can download anything :p
[14:02] <cwillu_at_work> installing v2.6.36-dl3 now
[14:07] <cwillu_at_work> installed, rebooting
[14:13] <cwillu_at_work> rcn-ee, no crash on v2.6.36-dl3
[14:19] <cwillu_at_work> oops, spoke too soon
[14:20] <cwillu_at_work> rcn-ee, crash on v2.6.36-dl3 :p
[14:25]  * cwillu_at_work pokes rcn-ee_at_work?
[14:25] <rcn-ee_at_work> cwillu, any luck with 2.6.36, just drove to work so don't have the backlog.. ;)
[14:25] <cwillu_at_work> :p
[14:26] <cwillu_at_work> no.  It still locks up
[14:26] <cwillu_at_work> I'm testing without network-manager in the loop though
[14:26] <cwillu_at_work> and bam :p
[14:26] <cwillu_at_work> it's not network-manager :p
[14:26] <rcn-ee_at_work> sweet, i was going to skip 2.6.36, to buggy.. ;)
[14:26] <cwillu_at_work> nothing in the logs either
[14:26] <cwillu_at_work> I can has a 2.6.35-ck2? :p
[14:26] <cwillu_at_work> no idea if it applies :p
[14:27] <rcn-ee_at_work> i tried 2.6.35-ck2 yesterday, it's fails to build some of the crc modules...
[14:27] <rcn-ee_at_work> any chance does 2.6.37-rc1 work any better.. (the dss2 stuff is iffy in that release) but there's lots of omap changes..
[14:28] <cwillu_at_work> I'll try it
[14:28] <rcn-ee_at_work> cool
[14:28] <cwillu_at_work> also, there's a ck patchset for 2.6.35
[14:29] <rcn-ee_at_work> i had tried: 2.6.35-ck1
[14:29] <cwillu_at_work> and it didn't build?
[14:30] <rcn-ee_at_work> nope, it's failing with some of the crc modules.. (doesn't care if it's builtin or external)
[14:30] <cwillu_at_work> define failing? :)
[14:31] <rcn-ee_at_work> (fired off a rebuild.. didn't save error message.. ;) )
[14:32]  * cwillu_at_work suspects foul play
[14:34] <cwillu_at_work> downloading 2.6.37-rc1-dl0
[14:35] <apw> ogra_ac, have we worked out if the omap3 kernels from linaro are good enough as a drop in replacement for our CDs ?
[14:36] <ogra_ac> apw, no, we havent yet
[14:36] <ogra_ac> apw, see my mail that i sent to ubuntu-devel
[14:37] <ogra_ac> apw, they have to be moved to main in any case and we have neither commitment from the kernel team nor from the security team for the maintenance period
[14:37] <apw> ogra_ac, well my take from that thread was that they weren't that interested in doing supported versions, so it is down to distro to handle support if we go that route
[14:38] <ogra_ac> i cant move them to main if nobody commits to take over the 18months of security and SRUs
[14:38] <ogra_ac> apw, right, but nobody in distro spoke up yet
[14:39] <apw> ogra_ac, yeah its hard for us to commit until the resources settle down
[14:40] <ogra_ac> apw, right, so i think for A1 we will have to go with omap4 only for now
[14:40] <ogra_ac> until i can get commitment
[14:41] <ogra_ac> and hope the things have settled before A2
[14:41] <apw> ogra_ac, ok that sounds sane i guess
[14:42] <ogra_ac> if there are new arches (which i'm more concerned about than omap3) we will likely have to revisit that anyway
[14:43] <ogra_ac> and i dont expect them to show up before A1
[14:43] <apw> ogra_ac, yeah thats all noise till we have the go to do them, so i am ignoreing them
[14:43] <ogra_ac> i try to but its hard ;)
[14:44] <cwillu_at_work> rcn-ee_at_work, booted with network attached, which failed every time on the 2.6.36
[14:45] <cwillu_at_work> rcn-ee_at_work, heh, on the other hand, picocom is complaining that /dev/ttyS2 isn't a tty :p
[14:45] <cwillu_at_work> oh, nope
[14:45] <rcn-ee_at_work> yeap, it's /dev/ttyO2
[14:45] <cwillu_at_work> just locked up
[14:46] <cwillu_at_work> rcn-ee_at_work, I still have entries for ttyS2, is that expected?
[14:46] <cwillu_at_work> and why the hell did that change in the first place? :p
[14:47] <rcn-ee_at_work> it's using the 'omap' serial driver now over the generic serial... dma/etc improvements..
[14:47] <rcn-ee_at_work> new in 2.6.37-rc1, so it'll screw every user up.. ;)
[14:47] <cwillu_at_work> and it had to change the name?
[14:47] <cwillu_at_work> ... that's gratuitous and borderline abusive
[14:48] <rcn-ee_at_work> Yeah... compatibility nightmare..  but S is for the serial, and O is for omap serial.. ;)
[14:48] <cwillu_at_work> I hate you.
[14:48] <cwillu_at_work> but anyways, 2.6.37 hangs too :p
[14:48] <rcn-ee_at_work> dang it..
[14:48] <rcn-ee_at_work> did anything in the old 2.6.34 work?
[14:49] <cwillu_at_work> let me try again without the network plugged in just to make sure it's the same'ish problem
[14:49] <cwillu_at_work> rcn-ee_at_work, believe so, used it for a while
[14:49] <cwillu_at_work> 2.6.34 had that memory leak though
[14:50] <rcn-ee_at_work> yeah it did.. but if the other thing works, we will have something bisect with. ;)
[14:50] <cwillu_at_work> can't we bisect 2.6.35 -> 2.6.36?
[14:50] <rcn-ee_at_work> i thought 2.6.35 failed too.. it worked?
[14:51] <cwillu_at_work> 2.6.35 is fine, unless I do stupid mii-tool tricks
[14:51] <cwillu_at_work> I've got 10 days uptime under 2.6.35.7-l6
[14:52] <cwillu_at_work> twice in a row too :p
[14:52] <rcn-ee_at_work> ah so a new bug with 2.6.36...
[14:52] <cwillu_at_work> yes
[14:52] <rcn-ee_at_work> and that's the one you can't get a backlog with right?
[14:53] <cwillu_at_work> when it hangs under 2.6.36 or .37, nothing comes over the serial link when it dies
[14:53] <cwillu_at_work> it just hardlocks
[14:54] <cwillu_at_work> now, the serial link is coming via rsyslog, so it's possible that a more direct approach would get something, but...
[14:54] <cwillu_at_work> 2.6.37 seems to have the same hang
[14:55] <rcn-ee_at_work> fires up his test rig.. it'll take a little bit.
[14:56] <cwillu_at_work> also, just a reminder in case it's relevant, the ks8851 driver does give some irq warnings
[14:56] <cwillu_at_work> under all kernel versions
[14:57] <cwillu_at_work> under 2.6.37, when I attach the network cable (but before I run dhclient or network manager to configure it), I get "NOHZ: local_softirq_pending 08"
[14:58] <cwillu_at_work> hmm, there's an bug message in 2.6.37's bootup re: ioremap call on system memory
[14:58] <rcn-ee_at_work> yeah the nohz has been around since like 2.6.32..
[14:58] <cwillu_at_work> that's in a call from omapfb though, so I don't think it's related
[14:58] <rcn-ee_at_work> the ioremap has patches for queued for rc2
[14:59] <rcn-ee_at_work> another one of the reasons i'm planing to skip 2.6.36..
[14:59] <cwillu_at_work> rcn-ee_at_work, I also get Spurious irq 95: 0xffffffdf, please flush posted write for irq 56
[14:59] <cwillu_at_work> this happens when the network interface is finally configured
[15:00] <cwillu_at_work> hmm
[15:00] <cwillu_at_work> I don't get that in 2.6.36/37 though
[15:00] <cwillu_at_work> it seems to crash when it would be showing up
[15:00]  * cwillu_at_work doublechecks
[15:02] <cwillu_at_work> rcn-ee_at_work, yep, I never see those on kernels that crash
[15:03] <ndec> ogra_ac: yes, there is a call. i am connected.
[15:03] <cwillu_at_work> I get the spurious irq's on .35 moments after I start using the network
[15:03] <ogra_ac> ndec, i'm a few mins late
[15:32] <rsalveti> ogra_ac: pool/main/a/alsa-utils/alsa-utils_1.0.23-2ubuntu3.4_armel.deb
[15:33] <ogra_ac> gar
[15:52] <cwillu_at_work> rcn-ee_at_work, still around?
[15:52] <rcn-ee_at_work> yeap
[15:52] <cwillu_at_work> got a stack trace \o/
[15:52] <cwillu_at_work> however, most of it scrolled off the top of the screen :p
[15:52] <rcn-ee_at_work> sweet
[15:53] <cwillu_at_work> omap2_mcspi_work shows up 5th line from the bottom
[15:53] <cwillu_at_work> let me muck a bit more and see if I can get it to do the same to the serial port
[15:56] <cwillu_at_work> ooo, hope
[15:58] <cwillu_at_work> rcn-ee_at_work, got it
[15:58] <cwillu_at_work> sec while I paste it
[16:03] <cwillu_at_work> rcn-ee_at_work, http://pastebin.com/tMZ5Lrfh
[16:03] <cwillu_at_work> that looks familiar :p
[16:06] <cwillu_at_work> rcn-ee_at_work, for reference, the errors I got with stupid mii-tool tricks:  http://pastebin.com/raw.php?i=vdrrr8iL
[16:07] <cwillu_at_work> the trace is as identical as can be expected with two different kernel versions
[16:08] <cwillu_at_work> kthread -> work_threader [-> process_one_work] -> omap2_mcspi_work -> complete [-> __raw_spin_lock_irqsave]
[16:08] <cwillu_at_work> er, worker_thread
[17:17] <cwillu_at_work> rcn-ee_at_work, any chance you could spin me a preempt_voluntary kernel?
[17:19] <rcn-ee_at_work> from stable?
[17:19] <rcn-ee_at_work> 2.6.35.8?
[17:19] <cwillu_at_work> no, 2.6.36 or later
[17:19] <cwillu_at_work> with or without ck2, doesn't matter
[17:20] <rcn-ee_at_work> sure..
[17:21] <rcn-ee_at_work> although, my work network is slower then molasses right now so it might take a bit to upload.. ;)
[17:22] <cwillu_at_work> np, heading out for lunch right away anyway
[19:11] <cwillu_at_work> (back)
[21:57] <cipher> how can I build a rootfs for armv7a (beagleboard) without qemu
[21:58] <cipher> I've been playing with rich nelson's omap-image-builder but run into trouble when trying to do the second-stage stuff
[21:58] <cwillu_at_work> rcn-ee, your mistake was letting me see you both leave for work and arrive at work this morning :)
[21:59] <cipher> what happens is the kernel panics when the qemu-system-arm tries to run the lucid kernel
[21:59] <cipher> not sure if my qemu version is bad but I can provide it if needed
[21:59] <cwillu_at_work> sorry, you're running it in qemu, or no?
[21:59] <cipher> I'm using rootstock to try and build a rootfs
[21:59] <cipher> rootstock uses qemu at some point for secondstage of debootstrap, this is my understanding
[22:00] <cipher> I'm more than happy to perform the second-stage stuff on the real hardware if that's possible, but I don't know enough about what it's doing
[22:00] <cwillu_at_work> use the static thingies
[22:00] <cwillu_at_work> sec
[22:00] <cwillu_at_work> (there's a comment to that effect in the script
[22:00] <cipher> I noticed it was looking for qemu-arm-static, but I don't have that
[22:00] <cipher> not sure what that is either
[22:00] <cipher> my first guess was that it was a statically compiled arm-softmmu
[22:01] <cwillu_at_work> it basically allows you to run arm binaries outside of qemu
[22:01] <cwillu_at_work> er
[22:01] <cwillu_at_work> that, plus bin-fmt-utils or whichever
[22:02] <cipher> why does this stuff need to happen with qemu anyway, can't it be done on the live hardware?
[22:02] <cwillu_at_work> cipher, the real hardware doesn't have much memory, has small slow disks, and a slow single-core processor
[22:03] <cwillu_at_work> I can do the whole rootstock process in 13 minutes on my server
[22:03] <cipher> I understand, but without knowing what the secondstage is I can't make that determination. looking through the debootstrap stuff it seemed it was unpacking some packages or some thing
[22:03] <cwillu_at_work> cipher, it's a debian install
[22:03] <cwillu_at_work> dpkg
[22:03] <cipher> I trust that it's done for a reason, just wondered what it is, thanks
[22:04] <cwillu_at_work> binfmt-support
[22:04] <cwillu_at_work> that's what I was looking for
[22:04] <cipher> any reference for what I should do
[22:05] <cwillu_at_work> install those two
[22:05] <cwillu_at_work> try it again
[22:05] <cipher> and what about qemu-arm-static?
[22:06] <cwillu_at_work> that would be the first
[22:07] <cipher> that's a package?
[22:07] <cwillu_at_work> yep
[22:07] <cwillu_at_work> if you don't see it, check for qemu-kvm-extras-static
[22:08] <cwillu_at_work> This package provides a static version of the QEMU ARM user mode
[22:08] <cwillu_at_work> emulation.  This is particularly useful in combination with
[22:08] <cwillu_at_work> binfmt-support: it permits running ARM binaries in an ARM chroot.
[22:08] <cipher> so my host system isn't actually ubuntu, I did build my own qemu with --static option.
[22:08] <cipher> I'm on debian lenny
[22:09] <cwillu_at_work> qemu-kvm-extras-static comes from debian afaik
[22:10] <cipher> hrm, sid I guess
[22:11] <cipher> wonder if I can just use my own qemu static that I compiled --static?
[22:16] <cipher> ah, from the way it sounds probably  not
[22:31] <cipher> so I installed the qemu-user-static package (which has qemu-arm-static) and tried again. I got a number of errors related to chown failing
[22:32] <cipher> /bin/chown: changing ownership of `/proc/sys/net/ipv4/conf/br0': Operation not permitted for example
[22:32] <cipher> I did run with sudo