[18:51] <nosse1> Are you familiar with bugs like this on omap: [ 2361.163635] BUG: soft lockup - CPU#0 stuck for 61s! [dpkg:1737]
[19:03] <persia> nosse1: I've seen that error reported for all sorts of architectures.  Unfortunately, I don't know the cause.  I'm fairly certain it's not OMAP-specific though.
[19:04] <nosse1> persia, thanks. I'd just wanted to check if it was something familiar on omap.
[19:04] <Martyn> what's the error?
[19:04] <Martyn> sorry, just popped in, so I don't have the backscroll
[19:05] <nosse1> [ 2361.163635] BUG: soft lockup - CPU#0 stuck for 61s! [dpkg:1737]
[19:05] <rsalveti> nosse1: which kernel are you urins?
[19:05] <persia> BUG: soft lockup - CPU#0 stuck for 61s!
[19:05] <rsalveti> *using
[19:05] <rsalveti> nosse1: the TI one?
[19:05] <nosse1> I'm running the TI-one yes, the "official" lucid ti-omap won't work for AM3517
[19:06] <nosse1> It could seem to me that the lockup occurs on heavy disk activity. And since I'm running NFS root, it could perhaps be related to that?
[19:09] <rsalveti> could be, but hard to say without more information from the kernel
[19:09] <nosse1> Yeah, I know. Except the kernel doesn't tell any more
[19:10] <nosse1> Another thing: I have X up and running (yeah!).
[19:10] <armin76> Martyn: did i ask you if you had sound running on the tegra?
[19:11] <nosse1> What apt target do you guys use when testing? "ubuntu-netbook" has unknown packages which doesn't seem to be available yet
[19:11] <nosse1> Do you have a all-in-one target which pulls down the gnome desktop?
[19:12] <persia> That'd be ubuntu-desktop, but ubuntu-netbook is significantly lighter-weight in terms of requirements.
[19:12] <persia> Which bits of ubuntu-netbook aren't installing?
[19:12] <nosse1> persia, hold on
[19:15] <nosse1> persia, cancel that. It seems all packages are available now
[19:16] <persia> There's sometimes architecture skew with the mix of arch:all and arch:any binaries (because the arch:all binaries are built on i386), but it doesn't typically last that long, unless something broke (which means it needs fixing).
[19:16] <persia> If you get a persistent issue with metapackage installation, it may well be a bug needing fixing.
[19:16] <persia> (but I'm glad to hear this isn't the case right now)
[19:17] <persia> That said, according to https://launchpad.net/builders there are 19 packages that are out-of-date on armel (waiting to build).
[19:19] <nosse1> Are there any commercial developers here in this forum? (perhaps not on sundays)
[19:19] <nosse1> I'm uncertain if we should register our products on the ARM machine registry or not
[19:20] <nosse1> and I'd like to know what other mfgs are doing
[19:21] <Martyn> armin76 : Since I'm very server-oriented, I haven't even tried to get sound working on the tegra
[19:21] <Martyn> armin76 : I've even disabled video, to get the memory back
[19:21] <persia> nosse1: Do you need a special MachineID for your hardware?  If so, you'll want one.  If not, there's little point.
[19:22] <Martyn> nosse1 : I'm a 'comercial developer'
[19:22] <armin76> Martyn: nod :)
[19:23] <nosse1> persia, I'm not sure i need one. You use machineid whenever the kernel isn't aware of the HW its running on, right? If that is true, I guess we don't need one
[19:24] <persia> I don't really understand when it's needed, but I think it's part of kernel compilation: if you can run a multi-board kernel, I think you don't need it.
[19:40] <nosse1> Alas, it seems NFS root is the culprit of the kernel crashes
[19:41]  * nosse1 wish that the AM3517 had a SATA disk connector...
[19:49] <persia> Anything designed to have disks should have such a controller, but MTD rules when it comes to local data.
[20:16] <nosse1> persia, do you mainly use USB or SD MTDs?
[20:16] <persia> I've never used an MTD that wasn't on-board.
[20:17] <persia> I'm fairly certain that neither USB nor SD allows one to actually use the MTD drivers.
[20:29] <nosse1> persia, you need a fairly large mtd if you want to do development on it. E.g. for building packages (since Ubuntu builds natively). Do you know how it's done in the build farm?
[20:29] <hrw> morning
[20:30] <nosse1> (I'm somewhat bothered here having to reboot my target whenever I do a larger apt install)
[20:31] <persia> nosse1: I'll say that an MTD is inappropriate for doing development: for that you want spinning disks.
[20:31] <hrw> yes
[20:31] <persia> I believe the build farm uses SATA-over-USB but I may be mistaken.
[20:31] <hrw> connecting 1.5TB disk over usb is easy
[20:31] <persia> That's probably overkill :)
[20:31] <nosse1> Ah.
[20:32] <hrw> persia: I have such one connected to sheevaplug
[20:32] <DanaG> I'd rather use an esata-bearing sheeva. =þ
[20:32] <hrw> or rather had as I have some problems with sheeva so disk is connected to desktop
[20:32] <nosse1> Because we need to make one ourselves unless we somehow can build packages natively on our large build farm
[20:32] <hrw> DanaG: I bought sheevaplug year ago when it was new stuff
[20:33] <hrw> nosse1: connect sata-over-usb and pray that TI ehci will work
[20:34] <nosse1> So it's about praying for one or the other. One=NFS, Other=ehci.... NFS crashed once more *sigh*
[20:34] <persia> ehci is probably more stable than NFS in most ways.
[20:34] <hrw> nosse1: 16GB sd is other option
[20:34] <persia> I remember that NFS was discussed for the LP build farm and rejected, but I don't remember why.
[20:35] <persia> hrw: If you like buying new SD cards :)  (but 4-8G is enough for most packages)
[20:35] <hrw> nosse1: quite cheap, easy to buy and omap3 can drive 3 mmc/sd slots
[20:35] <hrw> I have here device with omap3 and 3 sd slots. mmc0=rootfs, mmc1=userfs, mmc2=sdio/wifi/bt
[20:35] <nosse1> How's wear levelling handled on SD? Is it the SD firmware, or is it up to the host SW?
[20:36] <hrw> SD itself
[20:36] <nosse1> ...and from what I've heard it spans from excellent to horrible
[20:37] <hrw> yes
[20:37] <nosse1> Reliable brands: SanDisk, Kingston ?
[20:38]  * nosse1 needs to shop SD cards tomorrow
[20:38] <hrw> sandisk
[20:38] <hrw> avoid kingston rather
[20:39] <DanaG> hmm, where can you get a cheap sdio wifi?
[20:40] <DanaG> I wanna' try one in my host computer's sdhc controller.
[20:40] <hrw> DanaG: no idea
[20:40] <hrw> DanaG: here I have marvel8686 in two devices - both on sdio
[20:40] <hrw> and 3rd one has it on spi bus
[20:40] <DanaG> Something weird with the Ricoh reader in Windows: it assumes the whole disk is one partition (even if it's not true)... and then can't comprehend what partition type.
[20:41] <hrw> common
[20:41] <DanaG> I end up having to use "rw-everything" (awesome tool, by the way) to essentially "setpci" as I would have to on Linux... and then it reattaches to the SDHC controller instead of the Ricoh controller.
[20:41] <hrw> brand new cards sometimes do not have partition table
[20:41] <DanaG> http://intr.overt.org/blog/?p=59
[20:42] <DanaG> The card I was testing with, was my beagle (two partitions).
[20:43] <DanaG> Once I did that, it then showed partitions properly.
[20:43] <DanaG> I'm curious to try some SDIO card with the thing.
[20:43] <hrw> DanaG: nice
[20:45] <DanaG> I did the writing value on the mmc controller function, specifically.
[20:56] <hrw> but - is each sd controller also sdio capable?
[20:59] <nosse1> hrw, After skimming the RM from TI, it seems so
[21:00] <hrw> nosse1: I know that i.mx31, omap3, pxa2xx are sdio capable. no idea about others