[00:00]  * persia had nothing to do with it
[00:00] <mahmoh> persia: you did twist arms during the sprint though ;)
[00:00] <mahmoh> gently
[00:22] <persia> Is anyone especially attached to Headless/omap3, now that we have server images?
[00:24] <persia> Oh, nevermind.  I'm reading the wiki page wrong.  the answer has apparently been "no" for some time.
[04:39] <lilstevie> ogra_, you about?
[04:53] <Openfree`> about arm assemble constraint,  "USAT r0, #7, r5"  => should I use "i" for value #7 ? seems not correct..
[04:58] <Openfree`> usat Rd, #sat, Rm , #sat should be 0-31 value for arm, what should be the constraint? "i" not the right
[06:50] <Spider-Pork> morning
[09:04] <LPhas> hello everyone
[09:38] <ogra_> oh my
[09:38] <ogra_> http://www.fedora.org/
[09:40] <LPhas> hello, i got a problem. i installed ubuntu-arm on a pandaboard using the netinstall package as "ubuntu server". then i installed xinit and startx worked, in VGA resolution with framebuffer, then i installed pvr-omap4 (without rebooting)and startx kept working in VGA resolution. today i rebooted my pandaboard and now i get this http://hpaste.org/48969
[09:41] <ogra_> looks like you are missing bits on either the kernel or X side
[09:42] <LPhas> well
[09:42] <LPhas> i solved it with touch ~/.Xauthority ( O_O )
[09:43] <ogra_> oh, so it works fine now ?
[09:43]  * ogra_ hasnt used xinit in years
[09:43] <LPhas> right, you are ubuntu user :p
[09:44] <Spider-Pork> ogra_: do you remember my problem with audio input and ubuntu headless?
[09:44] <Spider-Pork> I solved it
[09:44] <ogra_> well, i only work with what we ship :)
[09:44] <Spider-Pork> it works correctly on headless too
[09:44] <LPhas> well. "works fine" but i still get vga resolution
[09:44] <LPhas> and i'm not sure it's using pvr_omap4 instead of framebuffer
[09:44] <ogra_> smells like the driver isnt getting the correct EDID data
[09:44] <ogra_> Spider-Pork, how did you solve it ?
[09:45] <Spider-Pork> well, I installed ubuntu headless
[09:45] <Spider-Pork> then alsa and pulseaudio
[09:45] <ogra_> yeah, these bits are indeed missing in headless :)
[09:46] <Spider-Pork> then applyed the two commands in the bugfix page
[09:46] <Spider-Pork> HiFi and Record
[09:46] <ogra_> right
[09:46] <Spider-Pork> then i booted into ubuntu netbook and stored in a file the amixer configurations with alsactl store
[09:47] <ogra_> erm
[09:47] <Spider-Pork> then rebooted with ubuntu headless, copyed in the config file and restored it with alsactl resotre
[09:47] <Spider-Pork> *restore
[09:47] <ogra_> that happens automatically and you wouldnt need to boot into netbook
[09:47] <ogra_> a simple alsactl store would have sufficed
[09:48] <Spider-Pork> store what?
[09:48] <ogra_> but alsa calls that on every shutdown anyway
[09:48] <Spider-Pork> on my headless there wasn't alsa configurations
[09:48] <ogra_> so theoretically a reboot should have done the same
[09:48] <ogra_> if you have alsa-utils installed at least
[09:49] <Spider-Pork> i used the netbook alsa configurations (that is correctly working with audio line-in)
[09:49] <Spider-Pork> no wait
[09:49] <ogra_> /var/lib/alsa/asound.state holds the mixer states between bootzs
[09:49] <ogra_> it is re-written on every shutdown with the currently applied mixer settings
[09:49] <Spider-Pork> my ubuntu netbook is corretly working, my ubuntu headless wasn't
[09:50] <ogra_> right, then there was something still missing
[09:50] <Spider-Pork> yep
[09:50] <ogra_> but you shouldnt need to copy data
[09:50] <Spider-Pork> ah
[09:50] <ogra_> removing /var/lib/alsa/asound.state and calling alsactl store should get you what you need
[09:50] <Spider-Pork> ok i'll try it :)
[09:51] <ogra_> i think it is mentioned in the bug by tobin (GrueMaster)
[09:51] <Spider-Pork> i solved it with the power of the noobs
[09:51] <ogra_> well, it works for you :)
[09:51] <Spider-Pork> use the power, noob
[09:51] <ogra_> would just be good to find a way that doesnt need a second machine ;)
[09:51] <ogra_> for people having the same issue
[09:51] <Spider-Pork> yep
[09:52] <Spider-Pork> i will test it
[09:52] <ogra_> if you found a way, please comment on the bug :)
[09:52] <Spider-Pork> yep
[09:53] <LPhas> http://comments.gmane.org/gmane.comp.embedded.pandaboard/754 i'm looking at this guide, i installed pvr_omap4 and other pvr packages but i don't have neither omap_gpu module nor pvrsrvinit am i missing something?
[09:53] <Spider-Pork> the community helped me, so i will do the same :)
[09:53] <ogra_> LPhas, did it compile the modules with dkms on next reboot after installing the package ?
[09:54] <ogra_> you should just install the graphics metapackage
[09:55] <ogra_> ubuntu-omap4-extras-graphics
[09:55] <ogra_> from https://launchpad.net/~tiomap-dev/+archive/release indeed
[09:55] <LPhas> ogra_, i installed it, but i did'nt manually compile nothing
[09:55] <ogra_> not you, the system should autocompile
[09:56] <ogra_> well, the package actually :)
[09:56] <LPhas> well it seems to me that it compiled stuff
[09:56] <LPhas> i recall it used kernel headers
[09:56] <LPhas> should i remove/reinstall it?
[09:56] <ogra_> ARGH
[09:56] <ogra_> who pointed you to that guide
[09:57] <ogra_> thats super broken
[09:57] <ogra_> just adding the ppa and installing the meatapackage will suffice
[09:58] <ogra_> if you did any of the manual steps in there its doubtful that your system still functions the way it was intended (with all the automatisms)
[09:58] <LPhas> google
[09:58] <LPhas> and no, i didn't do any manual step
[10:00] <ogra_> well, wait for robher clark or rsalveti to get up ... they are both pvr specialists
[10:00] <ogra_> err
[10:00] <ogra_> robher, sorry, that wasnt for you
[10:00]  * ogra_ curses autocompletion
[10:00] <ogra_> i meant robclark
[10:00] <LPhas> ok thx
[10:01] <ogra_> you were also using headless, right
[10:01] <ogra_> ?
[10:01] <LPhas> headless==?
[10:01] <ogra_> server
[10:01] <LPhas> mh yeah
[10:01] <ogra_> oh, wait, and you are using oneiric ?
[10:01] <LPhas> ubuntu-desktop failed to install due to dependencies problems
[10:02] <LPhas> mmh where oneiric was like "development version" something like that?
[10:02] <ogra_> yes
[10:02] <LPhas> yep
[10:02] <ogra_> lsb_release -a
[10:02] <ogra_> that should tell you
[10:02] <ogra_> i dont think anyone toucvhed pvr for oneiric yet
[10:03] <LPhas> yep, oneiric
[10:03] <ogra_> so its a matter of luck if it works at all
[10:03] <LPhas> but hey, i would be more than happy to use a more stable version
[10:03] <ogra_> natty should just work
[10:03] <LPhas> mh
[10:03] <LPhas> but i need to install it from netinstall image
[10:03] <LPhas> cause i don't have a 4gb sdcard
[10:04] <ogra_> netinstall is still pretty young ...
[10:04] <ogra_> you could use headless and then install the netbook task
[10:05] <LPhas> uhm
[10:06] <LPhas> headless will fit on the 2gb sdcard? and the i'd have to move / on the usb stick
[10:06] <LPhas> manually
[10:06] <ogra_> headless should fit on 1GB
[10:07] <ogra_> at least if you dont use it much beyond doing the basic config before copying to USB
[10:08] <LPhas> heh, let's do some dd work to save the current system and have a try
[10:37] <lilstevie> ogra_,  I have a few questions for you when you have a moment
[12:02] <alemariusnexus> Hi. Has anybody else experienced problems with the PowerVR SGX GLES2 driver on Natty lately?
[12:04] <rsalveti> what kind of issues? panda or beagle?
[12:05] <alemariusnexus> Pandaboard. It seems that the depth buffer is screwed up: http://noend-rpg.de/users/alemariusnexus/error.png vs. http://noend-rpg.de/users/alemariusnexus/correct.png
[12:07] <alemariusnexus> I don't have problems on my desktop computer, and PVRFrame (the PowerVR GLES "emulator") doesn't show this error, too
[12:19] <alemariusnexus> It might be a problem in my application. But since it appears on my Pandaboard only and since I can't imagine what kind of error in my application could cause this, I suspect it might be a driver problem (also, I had another problem which is very likely to be a driver bug in a Qt program)
[12:27] <LPhas> using the installer in headless img for omap4/pandaboard, everyhing is messy, is there a dimension of the serial console i've to use to see it correctly?
[12:29] <LPhas> like this http://imageshack.us/photo/my-images/197/screenshot3gv.png/
[12:29] <brendand> LPhas - a lot of sort of question mark characters?
[12:31] <LPhas> yeah, there are a lot of question mark charters, a lot of misplaced charters and generally the layout is broken
[12:36] <LPhas> meh, i'd really like to have a way to install a stable version with the netinstaller
[12:37] <LPhas> i mean, shouldn't be only matter of writing the proper apt configuration file?
[13:07] <mahmoh> is anyone else seeing init @100% after heavy IO loads? 2.6.38-1309 #14 on panda?
[13:08] <mahmoh> PS. running threaded IO
[13:27] <fredim> Someone used ubuntu-arm on Mini6410?
[13:49] <persia> fredim, The processor on that board can't run Ubuntu.  Debian should run nicely on that.
[13:50] <Martyn> Fixed OpenMPI upstream.   1.5.4 release imminent
[13:51] <Martyn> Also getting a source deb pulled together in debian...
[13:54] <persia> 1.5.4!  My, we're a bit out of date for that.
[13:55] <lilstevie> persia: I haven't forgotten about that package btw, just been a bit busy
[13:57] <persia> lilstevie, Totally understood.
[13:59] <persia> lilstevie, Based on https://wiki.ubuntu.com/OneiricReleaseSchedule, we have until 11th August, although I'd like to try for a bit sooner, just to have time to be sure we make that deadline.
[14:00] <persia> Also, I'll not be around so much 22 July to 1 August (although someone else may also be able to sponsor), so my personal timing goals aremore complicated.
[14:01] <Martyn> persia : The reason we're so far behind, is that until 1.5.2, there was no ARM support
[14:01] <Martyn> and the ARM tarball was broken (missing files) until just now, since the ARM maintainer was building from SVN
[14:01] <Martyn> so now it's getting fixed, and it should all work nicely for 1.5.4.  I'm testing daily
[14:02] <lilstevie> persia: well if we need to get something done https://github.com/lilstevie/samsung-kernel-tab/commits/GT-P1000-gingerbread/
[14:02] <persia> And the other architectures are all sufficiently well supported with 1.4.3?
[14:02] <lilstevie> persia: but that does have big bugs
[14:02] <Martyn> Sort of
[14:02] <Martyn> it's considered the "stable" release
[14:02] <lilstevie> I haven't sync'd for a bit
[14:03] <Martyn> but it's missing features that are becoming important to users of OpenMPI ... 1.5.3 is mainline in Sid right now
[14:03] <Martyn> so it's probably time to move Ubuntu server up to 1.5.3 as well, and make sure to provide an alternatives config
[14:03] <persia> lilstevie, If you haven't found time by next week, I'll try to find time for first packaging and upload of that, directly from git.  If you find time, and we can publish a *working* kernel where you understand the packaging, that's considerably preferable.
[14:03] <Martyn> well, 1.5.4 rather
[14:04] <lilstevie> persia: :)
[14:04] <persia> Martyn, Hrm?  My rmadison tells me sid has 1.4.3-2.1
[14:04] <Martyn> Hmmm .. I've been working with the guys to make the .dsc ...
[14:05] <persia> http://packages.qa.debian.org/o/openmpi.html
[14:05] <Martyn> maybe they are waiting for 1.5.4?
[14:05] <Martyn> yes, I see
[14:07] <persia> They're probably waiting, indeed.
[14:17] <Martyn> Mrrf.
[14:17] <Martyn> 1.4.x series, though 'stable' is also ludicrously behind in features
[14:18] <Martyn> and 1.6.x won't be out for a long while..
[14:18] <Martyn> this is the old odd/even kernel problem...
[14:18] <persia> Well, it's a stable/unstable thing.
[14:19] <persia> Lots of folks do that in ways that don't appear so obvious in version numbers.
[14:19] <persia> But there's no reason we can't put it in oneiric, if we had some volunteer who would continue to make sure it works for 18 months (hint)
[14:21] <Martyn> *chuckle*  Yes, I kno
[14:22] <Martyn> I just need to finish packaging it up
[14:23] <persia> Sylvestre is also an Ubuntu dev, so you probably want to get it into Experimental, and sync from there if he agrees, just to avoid potential checksum mismatches later.
[15:57] <LPhas> any idea on why i get this http://imageshack.us/photo/my-images/36/screenshot4ag.png/ in installing ubuntu headless?
[15:57] <LPhas> could be some minicom settings?
[15:58] <GrueMaster> Not off hand.  The settings look ok, from what I see on the bottom of the screen.
[15:59] <GrueMaster> Can you run screen on your system?  If so, try this:  screen <serial port> 115200
[15:59] <GrueMaster> I.e. screen /dev/ttyUSB0 115200
[16:01] <infinity> LPhas: Minicom is a lousy terminal emulator, nothing new there.  As GrueMaster says, try screen.
[16:01] <LPhas> well, with screen i get only gibberish
[16:02] <LPhas> oh, no, ok it seems working right now
[16:03] <LPhas> lol what is that? wait i'll make a screenshot
[16:03] <LPhas> http://imageshack.us/photo/my-images/15/screenshot5hc.png/ this is with screen
[16:05] <GrueMaster> I have never seen that before.  You have something strange going on, possibly with your serial port.
[16:07] <LPhas> that's quite strange because with minicom that part of the boot is fine
[16:07] <LPhas> and also yesterday the ubuntu netinstall was fine
[16:08] <LPhas> and yet, you were right
[16:09] <LPhas> i changed usb port for my serial/usb adapter and now is fine with screen O_O
[16:09] <LPhas> computer science is weird
[16:14] <GrueMaster> Could be a data flow issue.  I have seen weird things happen with one hub vs a different one, both are USB 2.0
[16:15] <LPhas> GrueMaster, true
[16:16] <LPhas> still, it's a pity that there isn't a netinstall for stable
[16:18] <GrueMaster> There may be a way to do it.  I am going to test a method today (once I get all these new usb enclosures filled and online).
[16:53] <LPhas> phas@panda:~$ sudo
[16:53] <LPhas> sudo: must be setuid root
[16:53] <LPhas> that's strange
[16:54] <LPhas> well ok i probably lost some permission while moving on usb duh
[16:58] <GrueMaster> How did you do the move from SD to USB?
[16:59] <LPhas> sudo mv
[16:59] <LPhas> well
[16:59] <LPhas> sudo cp -r
[16:59] <LPhas> but i should have fixed
[16:59] <LPhas> i just activated root in /etc/shadow and fixed permissions on /usr/bin/sudo
[17:05] <GrueMaster> I usually do: sudo su;tar -cf - . | (cd <target> ; tar -xvf -)
[17:06] <GrueMaster> It also has the benefit of one thread doing reads and the other doing writes.
[17:06] <LPhas> makes sense
[17:06] <LPhas> next time i'll try it
[17:06] <LPhas> or if permissions problems starts to get an issue
[17:09] <LPhas> actually the only problems seems to be that i get
[17:09] <LPhas> Processing triggers for man-db ...
[17:09] <LPhas> fopen: Permission denied
[17:09] <LPhas> on aptitude ugrade
[17:11] <LPhas> ouch, is this normal? http://hpaste.org/48974
[17:11] <GrueMaster> The find error is normal.
[17:12] <LPhas> ok
[17:12] <GrueMaster> Not that it is right, just happens all the time.
[17:12] <LPhas> eheh
[17:13] <GrueMaster> Well, if you were expecting perfection, you should have used...hrm.  Nevermind.
[17:13] <GrueMaster> :P
[17:13] <LPhas> i used everything else that run on pandaboard
[17:13] <LPhas> so what i expect here from ubuntu-arm is a miracle :p
[17:15] <GrueMaster> I'm trying, but am still stuck on that whole wine from water issue.
[17:15] <GrueMaster> Priorities.
[17:15] <LPhas> there are probably powders for that
[17:17] <GrueMaster> Just don't expect good things to happen if you spray your system with Miracle Grow.
[17:18] <GrueMaster> (sadly I have heard of people doing much stupider things).
[17:18] <LPhas> what's Miracle Grow?
[17:19] <GrueMaster> Some plant food sold in stores in the US to make plants grow faster.
[17:20] <LPhas> oh i see
[17:26] <LPhas> aaand ok, we are at the point where startx starts in framebuffer with VGA resolution
[17:27] <GrueMaster> Hrm.  Can you install read-edid?
[17:27] <LPhas> read-edid?
[17:27] <LPhas> but i still haven't install pvr-omap4
[17:27] <LPhas> i'm about to try
[17:27] <GrueMaster> Don't need it.
[17:27] <LPhas> uhm
[17:28] <GrueMaster> This will see what the edid data is coming from the monitor.
[17:28] <LPhas> where "monitor" is a television
[17:28] <LPhas> (starting to run out of monitors here)
[17:30] <GrueMaster> heh.  I know the feeling.  That's why I have an HDMI switch.
[17:31] <LPhas> heh, my monitor has some hdmi ports
[17:31] <LPhas> but it's painful to switch
[17:32] <LPhas> that's weird
[17:32] <LPhas> i installed read-edid
[17:32] <LPhas> and i have parse-edid as an executable
[17:32] <LPhas> but i can't find get-edid
[17:33] <GrueMaster> hmmm.  Not finding edid on my system.  Should be at /sys/devices/omapdss/display0/edid.  Use "cat /sys/devices/omapdss/display0/edid | parse-edid"
[17:34] <LPhas> mmh i can't file an edid file in  /sys/devices/omapdss/display0/
[17:35] <GrueMaster> Hrm.  Wonder if it got left out of the kernel.  Shouldn't have been.
[17:36] <LPhas> mmh wait a second here
[17:36] <LPhas> # Booting kernel from Legacy Image at 80000000 ..
[17:36] <LPhas> is it normal that he says "Legacy Image"?
[17:36] <GrueMaster> yes.
[17:36] <LPhas> ik
[17:36] <LPhas> ok
[17:37] <LPhas> well, let's try another monitor/hdmi cable
[17:40] <LPhas> lol
[17:40] <LPhas> it was the usb cable
[17:40] <GrueMaster> usb cable?
[17:40] <LPhas> hdmi cable
[17:40] <LPhas> stupid hdmi cable
[17:40] <GrueMaster> oh.  ok.
[17:41] <LPhas> that's weird too
[17:41] <LPhas> a hdmi cable that let you use only vga resolution
[17:42] <LPhas> now should i try to  install pvr_omap4 from the ti repository right?
[17:42] <GrueMaster> It was probably not getting the edid signal.
[17:42] <LPhas> yep
[17:42] <GrueMaster> Go for it.
[17:42] <LPhas> should i use TI OMAP release PPA or TI OMAP trunk PPA
[17:43] <GrueMaster> Not sure.   Probably trunk, but I don;'t know which has the latest stuff.
[17:50] <persia> "trunk" probably has newer stuff, but "release" probably has stuff TI thinks is release-worthy.
[17:50] <persia> For oneiric, "trunk" is probably best: when the underlying environment isn't stable, expecting stable add-ons is dreaming.
[17:58] <LPhas> GrueMaster, i think i've got it, gg
[17:58] <GrueMaster> cool
[17:58] <LPhas> just this two errors bothers me
[17:58] <LPhas> (EE) AIGLX: reverting to software rendering
[17:58] <LPhas> (EE) Keyboard: Couldn't open mtdev device
[17:58] <LPhas> if they do mean something
[17:59] <GrueMaster> Unless it isn't working, I would ignore those.  I think they are for multi-touch.
[17:59] <GrueMaster> Not sure.
[18:02] <LPhas> now the last omap4-related matter is to get omap-gstreamer work
[18:03] <LPhas> is it in the ti ppa that you know?
[18:05] <persia> There have been some gstreamers in the TI PPA.  I'm not sure if any of them are compatible with oneiric.
[18:05] <LPhas> i'm not on oneiric
[18:05] <LPhas> i switchet to nanny
[18:06] <persia> Oh, heh.  In that case, there's likely to be something.
[18:06] <LPhas> basically i look for the hardware decoding support for h264
[18:06] <persia> If there isn't, the uploader of the maverick version is very likely to be lurking around in this channel, and may respond to a ping.
[18:07] <LPhas> i saw that there's a gstreamer_h264
[18:07] <LPhas> and the usual gstreamer h264 plugin is in good
[18:07] <persia> This is probably what you want :)
[18:07] <LPhas> so it may be it
[18:49] <LPhas> thx guys, i think that it's tyme to bothers #gstreamers guys
[22:24] <mahmoh> so I'm seeing init consume 100% cpu on panda while/after running IO and threaded IO tests (PTS)
[22:24] <GrueMaster> Installing phoronix now on 2 systems (third is still imaging from netinst).
[22:25] <persia> mahmoh, Is there some spinning job spewing to /var/log/syslog?  When you strace init, what is it doing?
[22:27] <mahmoh> haven't checked that but I'll add it to the list
[22:31] <cmagina> persia: i've run strace on it and it is looping, waiting for something
[22:32] <cmagina> persia: if you watch its process state, you can actually see it go to sleep between checks
[22:35] <GrueMaster> Well, this can certainly pose a problem.  I have two panda systems with identical mac addresses.  Sigh.
[22:35] <GrueMaster> And as a result, my dhcp server has assigned them the same IP address.
[22:36] <mahmoh> set the ethaddr in uEnv.txt or boot.scr
[22:36] <GrueMaster> yep.
[22:36] <mahmoh> actually, once you boot the linux kernel you should have unique macs
[22:37] <GrueMaster> Nope.
[22:37] <GrueMaster> Both systems have been powercycled since netinstall finished.
[22:37] <mahmoh> unless both your boards came from the same die?
[22:37] <GrueMaster> u-boot is hardwired for the same mac.
[22:38] <GrueMaster> Definitely not same die.  One is ea1, the other is a1.
[22:38] <mahmoh> the u-boot mac is 00:02:03... yours should not be that once booted
[22:38] <GrueMaster> Hrm.  Then something isn't right in my world.
[22:39] <GrueMaster> I can log into each independently via serial console, but that has limits (not to mention that my serial console is being upgraded).
[22:40] <GrueMaster> But they both show the same mac/ip.
[22:40] <mahmoh> what's the mac?
[22:40] <GrueMaster> 2e:40:70:f0:12:06
[22:40] <persia> cmagina, Could you paste one or two repetitions of the strace?
[22:41] <mahmoh> so mine both start with 2E:40:.... but diverge from there, odd
[22:42] <cmagina> persia: i wish i could, but apparently i failed to record it.  on a good note, mahmoh has been able to preproduce this, so we can get one as soon as he hits it again
[22:42] <mahmoh> cmagina: persia: I'll reproduce.  If it appears to be a problem, where should the bug land?  kernel, init, server-arm?
[22:43] <persia> I can't say without a bit more information.  I'd guess upstart, but that's a completely uninformed guess at this point.
[22:44] <persia> The 'init' executable is provided by upstart, which ought only do job processing.  It may be that some job is spinning, in which case the job provider is at fault.  It may be that upstart is spinning internally, in which caes it's a bug in upstart.
[22:44] <persia> It may be that some kernel interface changed and something that is supposed to be a wait in userspace has converted to a poll (unlikely), which would make it a kernel issue.
[22:45] <persia> Most likely is that something else is spinning, and making N requests of init, which upstart is trying to service, making it look like upstart is at fault.
[22:47] <mahmoh> and why do I see a bunch of "omapdss DISPC error: timeout waiting for EVSYNC", is that just an artifact of the panda-usb connectivity?
[22:48] <GrueMaster> that is the fb driver whining.  Safe to ignore.
[22:48] <cmagina> looking through the logs i gathered from mahmoh recent repro, i noticed that the pts tests were hung
[22:48] <persia> It's bug #781318
[22:48] <ubot2> Launchpad bug 781318 in linux-ti-omap4 "omapdss DISPC error: timeout waiting for EVSYNC" [Medium,Confirmed] https://launchpad.net/bugs/781318
[22:48] <cmagina> [31200.956817] INFO: task tiotest:1615 blocked for more than 120 seconds.
[22:49] <GrueMaster> Or bug 758486
[22:49] <ubot2> Launchpad bug 758486 in linux-ti-omap4 "omapdss DISPC error on Panda platform" [Medium,New] https://launchpad.net/bugs/758486
[22:49] <persia> There's a chance that this could be driving odd stuff in udev, which could in turn be spinning upstart, but this is very unlikely, as more folk would see the problem.
[22:49] <mahmoh> yeah but it's annoying on the server iamge
[22:49] <mahmoh> iamge
[22:49] <mahmoh> image
[22:50] <persia> GrueMaster, I thought 781318 was it being noisy as headless, and 758486 was about failure to resume from suspend cleanly.
[22:50] <GrueMaster> Read the bug reports.
[22:50] <persia> I did.
[22:51] <GrueMaster> This is a simple matter of someone filing a duplicate bug.
[22:51] <persia> Are they duplicates?  The messages are different.
[22:51] <mahmoh> rsalveti: GrueMaster: I've also confirmed I can load and run from a USB memstick (fatload usb 0 ..., root=/dev/sda2)
[22:52] <mahmoh> rsalveti: ^ with your patch u-boot, I have to validate the package version [soon[
[22:52] <mahmoh> ]
[22:54] <GrueMaster> persia: Only slightly different messages, but they are caused by the same failing kernel FB code.  I already did the leg work with rsalveti last cycle.
[22:54] <mahmoh> rsalveti: GrueMaster: and root=USB-SATA (root=/dev/sdb2) booting from MMC/SD
[22:54] <persia> GrueMaster, Ah, that makes sense.
[22:55] <GrueMaster> It was supposed to be fixed with the edid update code that apparently never made it in.
[22:56] <persia> cmagina, That's probably just an artifact of the CPU spinning on something else.  Unless a thread is asserting realtime, it shouldn't care if it doesn't get execution slices very often (although it's nice to warn the user in case it's all batch processing and the user needs to get more cycles or reduce the load)
[22:56] <persia> Ah, that's extra annoying.
[22:56] <persia> (and cooloney isn't idling yet :( )
[22:57] <cmagina> persia: agreed, i'm still looking over the logs i did collect, hopefully there will be something of interest
[22:57] <GrueMaster> I thought paulo was the arm kernel guru now.
[22:57] <GrueMaster> (ppisati I think is his nick).
[22:57] <persia> Dunno.  cooloney is still assigned both those bugs.  If they ought be reassigned, I leave that between them.
[23:16] <GrueMaster> mahmoh: So in your USB testing above, was that with the kernel & initrd on USB or are they still on SD?
[23:17] <mahmoh> both
[23:18] <mahmoh> I loaded from MMC then booted to USB first, then tried loading from USB then booting to USB (sticks)
[23:18] <persia> Does that mean that we've reached a point that if we put the right u-boot in flash/MMC then we can boot from USB cleanly?
[23:18] <GrueMaster> Sweet.  So in theory, we can just have x-loader (MLO) and u-boot.bin on SD, or even no SD and u-boot.bin pushed via usbboot.
[23:18] <mahmoh> yes
[23:18] <mahmoh> right
[23:18]  * persia celebrates reaching parity with other architectures
[23:19] <persia> mahmoh, Does it still need to be FAT?  Can we load off e.g. ext4?
[23:20] <GrueMaster> I wonder if elmo can utilize this in the buildd cluster?
[23:20] <mahmoh> ooh, good question, I think it should be able to load off of ext2, I'll try it after my tests complete
[23:21] <persia> For extra points, load directly out of /boot on USB-SATA :)
[23:21] <mahmoh> persia: that won't work :( drivers on;y support sticks
[23:21] <mahmoh> only
[23:22] <mahmoh> or so I'm led to believe
[23:22] <persia> mahmoh, Considering there's no way in the USB spec to distinguish sticks from other things that provide USB class-compliant storage facilities, I suspect you've been misinformed.
[23:23] <persia> (or perhaps I have)
[23:23] <mahmoh> persia: tell that to the driver considering it only detects one USB storage device out of two (usb-stick & usb-sata) - guess which one ;)
[23:23] <persia> That said, the drivers might not be class-compliant, or be horridly buggy for certain sorts of storage characteristics.
[23:24] <mahmoh> you always see USB-FDD/USB-HDD etc. in bios so there has to be some diff., maybe it's based on size?
[23:24] <persia> USB-FDD is something else.
[23:25] <persia> Rather than representing a mass-storage device, it represents a removable storage device.
[23:25] <mahmoh> well that's supported though in u-boot, haven't tried though
[23:25] <persia> Do you have one?  I have some dusty ones somewhere if it especially needs testing.
[23:25] <persia> Not sure if I have any floppies for it, mind you.
[23:25] <GrueMaster> u-boot "should" support usb-sata, but may not be enabled for panda.
[23:26] <persia> There's no "enable"ing to do for that.
[23:26] <mahmoh> I do have one but do we really want to test it, except for curiosity's sake?
[23:26] <persia> USB MSC is USB MSC, and *doesn't* indicate whether it's one or another implementation.
[23:26] <GrueMaster> config flags?
[23:26] <persia> mahmoh, Up to you.  It's a time/interest thing.
[23:27] <mahmoh> when I'm super bored ... == never
[23:27] <persia> GrueMaster, Really?  Please don't tell me that someone created configuration flags to turn on/off buggy behaviour.
[23:28] <mahmoh> persia: no, that's never been done before, ever.
[23:28] <GrueMaster> well, considering usb support existis in u-boot since jaunty, but only recently for omap...
[23:28]  * persia reviews version 1.3 of the spec, just to be sure
[23:28]  * mahmoh has some land in FL to sell to persia
[23:28] <persia> GrueMaster, Oh, perhaps.  But there really shouldn't be any way to turn on or off USB<->SATA gateways.
[23:29]  * persia offers discount shares on a new alligator belt factory
[23:29] <mahmoh> it's probably just an addressing space issue, can't support more than X gig so USB-SATA isn't an option?
[23:30]  * GrueMaster offers to trade Oregon Coast property w/ ocean views for property in florida).
[23:30] <persia> Or rather, if the device is more than some size, it fails to load, and is skipped.
[23:30] <persia> That's buggy, but not configurable (and would work fine with a 2G USB PATA device)
[23:30] <GrueMaster> mahmoh: What filesystems does u-boot support?  Could be as simple as no ext4 support.
[23:31] <persia> mahmoh, Could you verify the Subclass code for your two USB devices (working, not working)?
[23:32] <persia> (lsusb -v)
[23:32] <mahmoh> I'm running ext3, so maybe
[23:33] <mahmoh> GrueMaster: actually no, there's a fat fs and it doesn't detect the device
[23:34] <GrueMaster> ext3 is ext2+journal.  Fully backwards compatible.
[23:34] <mahmoh>   bDeviceSubClass         0    for both
[23:34] <persia> Right.  So if both are MSC, and both are bDeviceSubclass 0, then they are the same.
[23:35] <GrueMaster> Could be a simple "find 0-1 devices and return) thing.
[23:35] <persia> Is there anything other than vendor/device identifiers (name, number, etc.) that differs in the descriptors?
[23:35] <mahmoh> iConfiguration          4 USB Mass Storage  vs. iConfiguration          0
[23:35] <persia> Which is which?
[23:35] <mahmoh> bmAttributes         0xc0  vs  bmAttributes         0x80
[23:36] <mahmoh> flash/works vs sata/not-recognized
[23:36] <persia> Where is that?
[23:36] <mahmoh> iInterface              6 MSC Bulk-Only Transfer   vs   iInterface              0
[23:37] <mahmoh> in lsusb -v
[23:37] <persia> So, which is which?  Are these all in the same order?
[23:37] <mahmoh> why don't I just pastebin it all for you?
[23:37] <persia> May as well.
[23:37] <persia> One of those devices looks misimplemented, but I may be mistaken.
[23:38] <mahmoh> http://pastebin.ubuntu.com/642971/
[23:38] <mahmoh> it's possible but they both work in linux
[23:38] <mahmoh> the usb-sata was the cheapest I could find ;)
[23:39] <persia> Not surprising.
[23:39] <persia> It only implements a subset of MSC, specifically BBB.
[23:40] <persia> Side effect is that it would have poor performance with multiple parallel IO streams.  Depending on the backing store, and caching, etc. this may not matter.
[23:40] <persia> Your USB stick supports CBI, which is a richer instruction set.
[23:41] <persia> I'm perfectly willing to believe that u-boot only supports CBI devices, but I'll assert that this is unrelated to the backing store.
[23:44] <persia> Your USB stick *should* have iConfiguration of 4 (USB Mass Storage), but in practice it doesn't matter, as it's defined at the interface level.
[23:47] <persia> Oh, heh, I am out of date.  1.3 says "Usage of CBI for any new design is discouraged.".
[23:48] <persia> This is probably worth a bug, as without BBB support, even USB "sticks" of the future may not work.
[23:49] <mahmoh> persia: who's going to write it up?  I'm sure everyone would love that support in u-boot, I know I would!  Then you could have a real boot partition that really boots and updates easily!
[23:50] <persia> mahmoh, As you have hardware known to be recognised *AND* not-recognised, I suspect you're a natural candidate.
[23:50] <rsalveti> mahmoh: cool, the u-boot binary from the package should work the same way as my binary
[23:50] <persia> Pass me the bug number and I'm happy to comment based on what I know of USB specs
[23:50] <rsalveti> the patch is integrated and package uploaded
[23:51] <mahmoh> rsalveti: how difficult would it be to get usb-sata support in u-boot?
[23:52] <rsalveti> mahmoh: didn't work for you?
[23:52] <rsalveti> I believe it should behave the same way as when using with a pen drive
[23:52] <rsalveti> at least the usb protocol should be the same
[23:53] <mahmoh> rsalveti: usb-flash-drive is recognized but usb-sata-drive is not
[23:53] <mahmoh> I thought I read that it wasn't supported, only sticks
[23:53] <rsalveti> oh, ok
[23:54] <mahmoh> rsalveti:   31 Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB
[23:54] <mahmoh>   32 flash sticks and USB network adaptors.     http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=blob;f=doc/README.usb;h=a8a4058de122d6c068d9cb91b218bdc89919c0b8;hb=HEAD
[23:55] <rsalveti> mahmoh: I believe my sata disk did work
[23:55] <rsalveti> using with usb
[23:55] <rsalveti> let me check
[23:55] <persia> What!  There's a static list in udev detailing which devices to support?
[23:56] <mahmoh> rsalveti: if it does work then pls tell me which controller/oem so I can get a couple ;)
[23:57] <persia> mahmoh, Try inserting the vendor/device pair for your device into the u-boot code.  That might be enough to make it work.
[23:57] <mahmoh> that means I'll have to build it ;)
[23:58] <rsalveti> mahmoh: run lsusb at ubuntu and paste me the output of your usb disk
[23:58] <persia> rsalveti, http://pastebin.ubuntu.com/642971/
[23:58] <persia> mahmoh, Really, compilation isn't scary :)
[23:59] <persia> There are nice scripts that do everything for you.  You only have to type `debuild -b`