[00:01] <ndec> rsalveti: hi... i was looking at your omap3 sgx packages.. and learn quite a few nice tricks that I didn't know. cool!
[00:03] <rsalveti> ndec: cool, feel free to copy from it :-)
[00:04] <ndec> rsalveti: for sure... the thing I didn't know was the xx.udev and xx.upstart... we have such files in our pkgs, but we are handling them in .install... will fix this.
[00:05] <rsalveti> ndec: yep, nowadays we have debhelpers for everything :-)
[00:09] <persia> ndec, It's worth checking all the completions of dh_ : most modern rules files don't invoke any of the debhelper scripts manually, but end up using lots of features.
[01:32] <GrueMaster> persia: still hanging around?  I have questions regarding dove audio.
[02:06] <persia> GrueMaster, back now.  Please ask.
[02:07] <GrueMaster> I was looking at the dove audio issue.  We hit this before in bug 451635 early in Lucid & karmic.
[02:07] <ubot2> Launchpad bug 451635 in pulseaudio (Ubuntu Karmic) (and 8 other projects) "defaults need adjustment on dove X0 for audible audio (affects: 1) (heat: 11)" [Undecided,New] https://launchpad.net/bugs/451635
[02:08] <GrueMaster> Unfortunately, Marvell has changed codecs since then.
[02:09] <GrueMaster> It used to be an AD1980 codec.  It is now an RT655.
[02:09] <GrueMaster> From what I can tell, it only exposes what in HD audio would be the 3 main outputs (front, rear, and center/lfe).
[02:10] <GrueMaster> No headphone jack.
[02:11] <persia> Is it the case that those 6 channels are producing audio when one tries?
[02:11] <GrueMaster> Physically, it has 6 RCA jacks on what would be the back of the board.
[02:12] <GrueMaster> On the front between VGA and serial are the mic & headphone jacks.
[02:12] <GrueMaster> From what I can tell in the driver, these are not connected.
[02:12] <GrueMaster> Not sure about the physical wiring yet.
[02:13] <GrueMaster> Speaker-test works fine on the RCA plugs.  But no playback from Rhythmbox (pulseaudio actually spikes up to 50% CPU).
[02:13] <persia> Do you get any input or output from anywhere?
[02:14] <persia> Ugh.  That usually comes from internal resampling when it's misconfigured.
[02:14] <GrueMaster> I initially tried the fix we made to pulseaudio in Lucid, but no effect.
[02:15] <GrueMaster> I can try to muck up the alsa bits, but I really am out of my element on pulseaudio.
[02:16] <GrueMaster> At least I still have my X0 running Lucid for reference.
[02:16] <persia> That pulse hack doesn't seem like enough to me.
[02:16] <GrueMaster> Not that it does much good.
[02:17] <GrueMaster> The pulse hack is what got the right controls working in Lucid.  I'll have to see if it still works on Maverick on that board.  I doubt that it will, though.
[02:19] <GrueMaster> I guess I need to figure out how to get the existing audio to go through pa first.  Then I can look into the HP & Mic.
[02:21] <persia> OK.
[02:21] <persia> I've just looked through the pulse mapping configuration.
[02:22] <persia> I think the method you used last time remains the right way to address it: first make sure you have all the outputs in ALSA, then review the mapping in the pulse configuration.
[02:24] <GrueMaster> Ok
[02:25] <GrueMaster> I'm looking at alsamixer now and will compare with lucid on X0.
[02:26] <persia> I think I understand what crimsun was doing, and we can probably replicate that if we need, but I think the more important part is that you aren't seeing the headphones in ALSA.
[02:27] <persia> (at least for the problem with the mic & headphone jacks)
[02:28] <persia> For the "it doesn't work in Rhythmbox on the RCA jacks" issue, I have a sense that we'll end up with a slightly different solution if we try to sort that now vs. first getting everything represented in ALSA, and I'd rather only try to do it once.
[02:28] <GrueMaster> Ok, nothing in alsamixer affects HP jack.  Very odd.
[02:28] <persia> Not really, if the jack isn't exposed.
[02:29] <persia> alsamixer can only act on elements exposed by the driver
[02:29] <GrueMaster> Well, yea.  Just odd that if it isn't used, why is it on the board.
[02:30] <GrueMaster> I guess I will need to dig for specs on that codec then.  Usually the codec driver exposes all to alsamixer.
[02:30] <GrueMaster> It currently shows a lot more than the machine dai has defined.
[02:30] <persia> I expect there is intent to use it eventually, but it wasn't a priority for porting.
[02:31] <persia> It's not an issue if there is stuff not exposed in the DAI, as long as it's also not wired to anything :)
[02:31] <rsalveti> cooloney: hey!
[02:32] <rsalveti> cooloney: third time I'm compiling the kernel and seems to be fine
[02:32] <rsalveti> will continue stressing the system to see if I still get the bus error
[02:33] <cooloney> rsalveti: hey, man. do you mean 2G:2G split with npitre's VMALLOC_END patch?
[02:33] <rsalveti> cooloney: yep
[02:33] <cooloney> yeah, i think so
[02:33] <rsalveti> highmem = 0k
[02:33] <cooloney> that's is workaround for us, if we have to workaround it before 10/10 release
[02:34] <cooloney> rsalveti: exactly
[02:34] <rsalveti> will let it running during the night, let's see if it'll go well
[02:34] <cooloney> cool
[02:34] <cooloney> i am trying to find out highmem usage when bus errors pop up
[02:34] <cooloney> any suggestion?
[02:34] <cooloney> i think we already enabled CONFIG_DEBUG_USER
[02:35] <rsalveti> cooloney: hm, that's what I was going to ask you
[02:35] <rsalveti> CONFIG_DEBUG_USER=y
[02:35] <rsalveti> yep
[02:38] <cooloney> i enabled CONFIG_DEBUG_PAGEALLOC=y
[02:39] <npitre> cooloney: just recreate the bus error, then see what dmesg says about it
[02:39] <rsalveti> also, shouldn't we set user_debug at the cmdline?
[02:40] <npitre> cooloney: you should get a full register dump and stack trace, etc.
[02:40] <rsalveti> npitre: Unhandled fault: imprecise external abort (0x1406) at 0x2b805000
[02:40] <cooloney> rsalveti: yeah, like that.
[02:40] <rsalveti> and the kernel build: internal compiler error: Bus error
[02:41] <cooloney> npitre: http://pastebin.ubuntu.com/499410/
[02:41] <cooloney> something like this
[02:45] <npitre> hmmmmmm
[02:46] <npitre> you will have to dig in the OMAP4 and/or the Cortex A9 manual to find out about what may cause an imprecise external abort
[02:47] <npitre> is it possible to boot this thing with L2 cache disabled?
[02:47] <npitre> that would be another thing to test
[02:51] <npitre> also, does the stack backtrace go back to __dabt_svc or __dabt_usr?
[02:58] <GrueMaster> persia: Sweet.  They are using a Realtek ALC655.   I say that because they always have had excellent documentation online.
[02:58] <persia> Oh, nice!  This oughtn't be that hard at all.
[03:09] <cooloney> npitre: let me try to disable L2 cache.
[03:10] <cooloney> npitre: and it looks like the oops is from __dabt_usr()
[03:58]  * freeflying 
[04:03] <npitre> cooloney: strange
[04:04] <npitre> cooloney: this actually looks like if the external abort occurred while the CPU was already in __dabt_usr
[04:13] <cooloney> npitre: yeah. i am digging in the Cortex manual.
[04:13] <cooloney> for imprecise external abort, it looks like no specific root cause.
[04:15] <cooloney> but there is an errata of Cortex A9 MPCore
[04:15] <cooloney> npitre: 743626: An imprecise external abort received while the processor enters WFI may cause a processor deadlock
[06:41] <rsalveti> cooloney: npitre: ouch, got the bug without highmem :-(
[06:42] <rsalveti> but now a little different: Bad mode in data abort handler detected
[06:42] <rsalveti> let me paste it
[06:43] <rsalveti> and now instead of a bus error I got a segfault in gcc
[06:44] <rsalveti> the only difference is that I'm not building the kernel with -j3
[06:44] <rsalveti> *now
[07:07] <rsalveti> this bad mode issue seems worse than the external abort...
[08:04] <hrw> morning
[14:43] <jo-erlend> can I use debs for maemo in Maverick?
[14:45] <jo-erlend> thought I'd try x2goclient on my igepv2 and see if it's a viable thinclient in my environment, but the only ARM packages I can find is for maemo.
[14:47] <rsalveti> persia: thanks for the review, will go over it later today
[14:54] <ogra> oh, did he find aynthing ?
[14:54]  * ogra didnt get any inof about it 
[14:55] <jo-erlend> just can't get inof? :)
[14:56] <rsalveti> ogra: sent just for me, will go over the list then and ask you a new review :-)
[14:57] <rsalveti> if we're fine, we can try to push them
[15:00] <ogra> rsalveti, awesome
[15:07] <cwillu_at_work> jo-erlend, if you can get a source package, rebuilding it is probably straightforward;  otherwise, the deb may or may not work, depending on a bunch of stuff
[15:07] <jo-erlend> I've never created a package before.
[15:09] <persia> rsalveti, Mind you, it's *very* pedantic: don't worry if some things turn out to be annoying or hard.
[15:10] <isbric> is there any way to bypass oem-install on first boot?
[15:11] <persia> isbric, There are a bunch of ways, but that would leave you without a user.  What are you seeking to accomplish?
[15:11] <isbric> http://elinux.org/BeagleBoardUbuntu#Lucid_10.04.1
[15:12] <isbric> i dont have a monitor, thats the main problem
[15:13] <rsalveti> persia: sure, np :-)
[15:13] <isbric> "Note: On first boot, you must use an DVI/LCD monitor, oem-config seems to force tty0.. 2nd boot you can switch to serial by default.."
[15:15] <isbric> persia: trying to finish the install with ttyS0
[15:20] <persia> isbric, Ah.  I understand.  I think there's no way to complete it with the current images.
[15:20] <persia> I think you'd need to build new images that used the debconf front-end for configuration, but I don't know that anyone defined an oem-config harness for that interface.
[15:32] <cwillu_at_work> jo-erlend, sorry, went afk
[15:32] <cwillu_at_work> jo-erlend, that's not what I asked :p
[15:32] <jo-erlend> cwillu_at_work, did you ask me anything?
[15:32] <cwillu_at_work> jo-erlend, if you can get a source package for the deb, then there's a good chance that dpkg-buildpackage will Just Work and give you a working binary deb that you can then Just Install.
[15:33] <cwillu_at_work> jo-erlend, I didn't use a question mark :p
[15:33] <jo-erlend> really? That'd be nice.
[15:33] <jo-erlend> I'll have to look into that.
[15:33] <cwillu_at_work> jo-erlend, you on ubuntu right now?
[15:33] <jo-erlend> yes.
[15:33] <cwillu_at_work> jo-erlend, open a terminal, make an empty directory, cd into that directory
[15:34] <cwillu_at_work> next, apt-get build-dep xsplash
[15:34] <cwillu_at_work> next, apt-get source xsplash
[15:34] <jo-erlend> seems they don't make source debs available. They publish tar.gz packages only.
[15:34] <cwillu_at_work> okay;  that's not impossible to deal with either :p
[15:35] <cwillu_at_work> generally, unpacking the tar.gz, and then running ./configure, then make, will compile the package
[15:35] <cwillu_at_work> if one is lazy at that point, a make install will generally install it, or you can use checkinstall to make a deb of questionable quality
[15:35] <cwillu_at_work> in many cases, that's everything you need
[15:35] <jo-erlend> checkinstall is new to me.
[15:35] <cwillu_at_work> !checkinstall
[15:36] <ubot2> checkinstall is a wrapper to "make install", useful for installing programs you compiled. It will create a .deb package, which will be listed in the APT database and can be uninstalled like other packages. See https://help.ubuntu.com/community/CheckInstall - Read the warnings at the top and bottom of that web page, and DO NOT interrupt CheckInstall while it's running!
[15:36] <jo-erlend> thanks. I'll go read now. :)
[15:37] <cwillu_at_work> more fun to just dive in :)
[15:38] <jo-erlend> hehe, not when things go wrong and you have to spend a week fixing the problems you wouldn't have had if you spent the ten minutes reading the manual first. :)
[15:44] <jo-erlend> ok, I've give it a go. Thanks. :)
[16:34]  * rsalveti lunch
[17:01] <rlameiro> morning
[17:03] <rlameiro> are there any know USB bugs on IGEPv2 or Beagle board?
[17:04] <rlameiro> i searched in launchpad and found nothing, maybe I am doing someting wrong
[17:04] <ogra> there are known HW bugs with beagle afaik
[17:04] <ogra> with the pre-C4 boards
[17:05] <rlameiro> ogra: the problem is that a device only works if pluged on start up
[17:05] <rlameiro> and if i take it out, and try to put something there again, it will not enumerate
[17:05] <ogra> what board specifically (nobody here has an IGEP2)
[17:05] <rlameiro> I have :D
[17:06] <ogra> well, let me rephrase ... what beagle ? :)
[17:06] <rlameiro> http://pastebin.ubuntu.com/499799/
[17:06] <ogra> which revision
[17:06] <rlameiro> ahh
[17:06] <rlameiro> IGEPv2 revision 3
[17:06] <rlameiro> its one of the most recents one
[17:07] <ogra> since the arm team doesnt have IGEP2 its very likely that we miss bugs there
[17:07] <ogra> (and very unlikely that we get them fixed in time for maverick this late in the cycle, but you can try)
[17:07] <ogra> i wouldnt expect more than one kernel upload for omap3 anymore before release though
[17:08] <ogra> (i know there are already a bunch of IGEP2 fixes, if you can send patches along with the bug they might make it in)
[17:09] <ogra> s/fixes/pending fixes/
[17:09] <rlameiro> problem is that i am not a programer
[17:09] <rlameiro> just user, trying to put the board making sound properly
[17:09] <lool> rlameiro: That sounds like a bug; I think you should file it against the kernel you're running
[17:10] <jo-erlend_igep> rlameiro, I have the same board and the same problem.
[17:10] <rlameiro> I even bought a 30USD hub, bigger than my board to check if it was because i was using to much power on the usb rail...
[17:10] <devilhorns> ogra, speaking of maverick ... is there anything that you need from me for that release ? (any more bugs, etc, etc) ?
[17:10] <ogra> devilhorns, no, but i got you access to the upstream tree
[17:10] <jo-erlend_igep> rlameiro, have you tried rsalvetis recent kernels?
[17:10] <rlameiro> jo-erlend_igep: ok, so we can join forces :D
[17:10] <ogra> devilhorns, mail coming with URL
[17:10] <devilhorns> ogra, w00t ! :) thanks :)
[17:11] <jo-erlend_igep> rlameiro, gladly. One big problem here, is that those who know what to do, don't have the hardware and we who have the hardware doesn't know what to do. :)
[17:11] <ogra> lool, does linaro possibly have fixes ubuntu could pull in ?
[17:11] <rlameiro> jo-erlend_igep: problem is that i Cant file bugs against other kernels that arent from ubunto or linaro
[17:11]  * devilhorns now has to learn bzr for commits :)
[17:11] <rlameiro> no one will look at them
[17:11] <rlameiro> i want to fix ubuntu
[17:12] <ogra> rlameiro, you should probably talk to the linaro guys, they might have patches for the issue we are just missing in the ubuntu kernel
[17:12] <jo-erlend_igep> rlameiro, I've been acting as rsalvetis bot for a few days, and now screen and networking is working. Bluetooth and sound is not working and I cannot connect to wpa-protected wifis.
[17:12] <lool> ogra: I didn't hear of a fix for this specific issue
[17:12] <ogra> lool, ok
[17:12] <ogra> but you seem not to see it in linaro
[17:12] <rlameiro> ogra: why doesnt canonical just order a board, or even ask one for free? its only 145€....
[17:12] <lool> jo-erlend_igep: Oh WPA was working for me with libertas-firmware
[17:13] <lool> ogra: I didn't say that
[17:13] <ogra> rlameiro, we'll likely do that for natty ...
[17:13] <ogra> lool, no, was an assumption i shamelessly made :)
[17:13] <lool> rlameiro: You're asking weird things  :-)
[17:13] <rlameiro> free boards?
[17:13] <lool> rlameiro: In any case, Linaro is also trying to support IGEP in their own OMAP kernels, and we do have some IGEPs
[17:13] <jo-erlend_igep> lool, really? I have installed libertas-firmware.
[17:13] <ogra> rlameiro, for maverick our main focus is and was omap4, we also did omap3 but only focusing on beagle C4 and XM
[17:14] <rlameiro> free board is awesome :P
[17:14] <ogra> for natty we might add IGEP2 to our list of HW to work with
[17:14] <lool> rlameiro: You're asking Canonical to spend money and (more importantly) engineering time on IGEP; if you wonder why it's not being done, it's just because of the cost versus other things we could work on   :-)
[17:14] <rlameiro> ogra: I got that, only problem is that almost no one has omap4, but omap3
[17:14] <rlameiro> anyway, it is not my bussines anyway
[17:14] <lool> jo-erlend_igep: I didn't test in the last couple of weeks, but it was the only thing which worked for me, yes
[17:15] <ogra> omap4 vs omap3 will change quickly as soon as the boards are on the market
[17:15] <lool> rlameiro: You're looking at the problem from the angle of "what would be the most profitable to the community", but another angle to the question is how to pay the engineers working on bugs
[17:15] <jo-erlend_igep> I wonder how much faster omap4 will be IRL.
[17:15] <rlameiro> ogra: true, but that means that the people that already have ompa3 boards need to go for ompa4.....
[17:16] <rlameiro> lool: I will glady donate for specific things
[17:16] <rlameiro> not for beagle Xm
[17:16] <jo-erlend_igep> didn't we use to have "bounties"?
[17:16] <ogra> rlameiro, well, our team is small we only have so much manpower to support three arches currently
[17:16] <rlameiro> ogra: I know, and it is nothing against you, really
[17:16] <lool> rlameiro: This is a nice thing of you; thanks for offering that!  I'm afraid Canonical itself is not setup to receive direct user donations (AFAIK), but perhaps you can offer a bounty to an interested developer/company to fix our pet bugs?
[17:17] <rlameiro> people have always to much work, and to few people
[17:17] <ogra> rlameiro, i didnt take it as something against me/us :)
[17:17] <lool> rlameiro: True
[17:17] <lool> What would be interesting is whether the bug is also present on other OMAP3 boards like beagles or beagle XMs
[17:17] <rlameiro> lol, why would it be against you???
[17:18] <lool> and also whether it's present in the upstream tree or not
[17:18] <ogra> rlameiro, we like to fix bugs (and as you can see on rsalveti helping jo-erlend, we even do it actively as good as we can)
[17:18] <lool> It might just be a kernel config being mis-set
[17:18] <ogra> rlameiro, the main problem is the time of release you approach us
[17:18] <ogra> a month ago everything was easier
[17:18] <rlameiro> ogra: I know. my only problem is with the "upper" people
[17:18] <ogra> the later we get into the cycle the harder it gets to make changes
[17:19] <ogra> which "upper" people ?
[17:19] <rlameiro> they market ARM as the big bet , but then puts little engineers on it and then they need to make everything
[17:19]  * jo-erlend_igep is really grateful for the help rsalveti has given him.
[17:19] <ogra> we actually can work fine with community members to fix HW we dont have but that requires far more time
[17:20] <ogra> which measn such things need to show up earlier in the cycle or they will suffer from our focus on HW we actualyl have
[17:20] <rlameiro> ogra: and I really love to do that to :D
[17:20] <rlameiro> I filed some bugs already and help debuging some stuff also
[17:20] <ogra> yes, i saw that
[17:20] <ogra> and you are doing great :)
[17:20] <rlameiro> yea early on the cycle i couldnt even boot my board with ubuntu....
[17:21] <ogra> i also dont want to turn you down in what you do, i'm just trying to explain the situation
[17:21] <rlameiro> ogra: you dont need to explain, you make a great job in here, believe me.
[17:21] <lool> rlameiro: Is there a LP bug # for the USB issue you mentioned earlier?
[17:21] <ogra> if you file a bug it will definitely be taken care of ... its just not clear if it will make it into the release or has to wait for an update or worst case for next release
[17:22] <rlameiro> lool: no, thats why i felt it was weird, because its a really common thing
[17:22] <lool> ogra: By whom?
[17:22] <ogra> lool, for what ?
[17:22] <lool> rlameiro: Would be good if you could file it, explaining which devices you're testing, on which USB port etc.
[17:22] <ogra> lool, the SRU or the next release ?
[17:22] <lool> ogra: You say it will be taken care of
[17:22] <ogra> by the kernel team or us
[17:22] <ogra> or linaro
[17:22] <jo-erlend_igep> rlameiro, the USB issue, as I understand it, is that if you disconnect and reconnect a USB device, then it's not  being recognized? Does this also affect keyboard and mouse?
[17:23] <lool> ogra: Are you folks committed to fixing OMAP3/IGEP bugs?
[17:23] <ogra> or a combination of these
[17:23] <ogra> no
[17:23] <ogra> but there is interest on our side to have them fixed
[17:23] <ogra> as there is interest to get all other omap3 HW working
[17:23] <lool> Oh ok, you were saying "it will definitely be taken care of", so I wondered
[17:23] <rlameiro> jo-erlend_igep: yes, my mouse isnt reconigzed after I unplug something
[17:23] <ogra> someone will do it, i'm sure
[17:23] <jo-erlend_igep> rlameiro, have you tried the new kernel from rsalveti?
[17:24] <ogra> lool, i know rsalveti cant sleep if bugs exiost in the world :) and i know mpoirier has interest in IGEP2
[17:24] <jo-erlend_igep> rlameiro, I no longer have that problem, but I remember having it in the beginning.
[17:24] <rlameiro> no, jo-erlend_igep but as i said, i wanted to help debug stuff in ubuntu, but it seems i will need to use other kernels
[17:25] <lool> ogra: Ok; I don't want jo-erlend_igep and rlameiro to be disappointed if you say it will definitely be taken care of, but then it might not
[17:25] <lool> I'm certainly interested in having it in our list of Linaro IGEP bugs if it can be reproduced with Linaro kernels
[17:25] <ogra> lool, well, given linaro uses that HW i would expect you guys to hit the same bug at some point for example ...
[17:25] <ogra> so there might be a patch that suits both teams
[17:25] <rlameiro> lool: I iam runing a linaro kerne
[17:25] <rlameiro> *kernel
[17:26] <lool> rlameiro: And you have the same issue?
[17:26] <rlameiro> lool: yes
[17:26] <jo-erlend_igep> rlameiro, I'm using rsalvetis kernel. The only thing that doesn't work, is audio, bluetooth, and possible wlan. I haven't had time to really look into the wlan issues yet.
[17:26] <rlameiro> lool: the most recent linaro kernel on the repos
[17:26] <armin76> lool: you don't get cool hw anymore? :P
[17:26] <lool> armin76: ?
[17:26] <ogra> armin76, IGEP2 isnt cool ?
[17:26] <armin76> well, its not an omap4
[17:27] <lool> I don't have OMAP4, no
[17:27] <rlameiro> jo-erlend_igep: for the wlan, you need to put the libertas firmware in helper by hand, i am not sure if they are opensource
[17:27] <ogra> its also not a tegra2
[17:27] <ogra> nor an xscale
[17:27] <lool> rlameiro: Nope; but the package in multiverse worked forme
[17:28] <lool> rlameiro, jo-erlend_igep: So would either of you please report the USB issue with the exact kernel version, USB port, and device you folks are using?
[17:28] <rlameiro> IGEPv2 wat the first dev board to have LAN, wifi, bluetooth 512/512mb on the market
[17:28] <ogra> GrueMaster, hey, i fixed the "all headers installed" issue :)
[17:28] <jo-erlend_igep> lool, I no longer have that issue, so that'll be a bit difficult.
[17:28] <GrueMaster> cool
[17:28] <ogra> tomorrows images will only ship the actually needed headers
[17:28] <lool> jo-erlend_igep: Oh you *don't* have the USB issue, so it got solved by a kernel update?
[17:28] <GrueMaster> Heh.  Promises, promises.  :P
[17:28] <rlameiro> lool: where do i file it? lp?
[17:28] <ogra> heh
[17:28] <lool> rlameiro: Yup
[17:29] <lool> rlameiro: Ideally, just "ubuntu-bug linux-linaro" or linux if you're running an Ubuntu kernel
[17:29] <jo-erlend_igep> lool, I _think_ one of salvetis kernels fixed it. That is to say: I think I had the problem, but if I did, I don't anymore. :)
[17:29] <lool> jo-erlend_igep: hmm ok
[17:29] <ogra> so there is a patch *somewhere*
[17:29] <ogra> :)
[17:30] <ogra> hidden in rsalveti's branch on the ubuntu git server i bet :)
[17:30] <jo-erlend_igep> lool, not the best comment for a bug: «This was maybe fixed by something that somebody might have done.»
[17:31] <lool> jo-erlend_igep: Yeah
[17:31] <lool> I'm counting on rlameiro to file the bug though, as he is seeing it
[17:31] <ogra> jo-erlend_igep, "that was fixed with a manual build i got from ... "
[17:31] <ogra> ;)
[17:33] <rlameiro> doing it now, plus debbuging
[17:42] <mpoirier> berco: good morning
[17:43] <mpoirier> Irg: good morning
[17:46] <rlameiro> done lp#646985
[17:46] <rlameiro> done lp #646985
[17:46] <ubot2> Launchpad bug 646985 in linux-linaro (Ubuntu) "[IGEPv2 board] The USB systems cease to work after an unplug event on linux linaro kernel (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/646985
[17:47] <rlameiro> lool: ping
[17:48] <rlameiro> jo-erlend_igep: maybe you can comment on this bug saying what kernel you use and that you dont have the problem anymore
[17:49] <lool> rlameiro: Could you note which of the USB ports you're using?
[17:49] <lool> rlameiro: Hub/no hub and the like
[17:49] <rlameiro> ok
[17:51] <jo-erlend_igep> rlameiro, sure.
[17:51] <rlameiro> lool: updated
[17:51] <lool> rlameiro: If you're tempted to compare with the Ubuntu omap kernel, that would be interesting
[17:52] <rlameiro> lool: it didnt work also
[17:52] <lool> I'm personally kicking builds of linux and linux-omap with the Linaro OMAP; perhaps these might hint at what's wrong?
[17:52] <lool> rlameiro: Could you note which version you tried?
[17:52] <rlameiro> wich version of the ubuntu kernel?
[17:52] <lool> rlameiro: If that's the latest, then I'll add a task on the Ubuntu omap kernel
[17:52] <lool> rlameiro: yup
[17:53] <lool> Grmpf, my vm went down again
[17:53] <lool> this is tiring
[17:53]  * rsalveti back
[17:54] <rlameiro> lool: it was this version linux-image-2.6.35-22-omap
[17:54] <lool> rlameiro: Do you have the version of the package as well?
[17:54] <lool> rlameiro: The "version" in the package name is just the ABI
[17:54] <rlameiro> .33
[17:55] <jo-erlend_igep> rsalveti, I never installed the linux-firmware-image_2.6.35.4+43_armel.deb package. Should I?
[17:55] <lool> rlameiro: Ok, that's almost the latest kernel in Ubuntu, and the latest one doesn't seem to touch anything related
[17:55] <rsalveti> jo-erlend_igep: you could, don't know if it'll make any difference for you
[17:56] <lool> the only ARM change is "Adding vdd_sdi regulator supply to OMAP3EVM
[17:56] <lool> "
[17:56] <rsalveti> depends on what firmwares you actually need
[17:56]  * rsalveti reading the backlog
[17:58]  * rlameiro is going to eat something, bugs make him hungry
[18:01]  * prpplague gives rlameiro some fried beattles and baked crikets
[18:04] <rsalveti> jo-erlend_igep: are you sure you're using the same hardware rlameiro has?
[18:05] <jo-erlend_igep> almost.
[18:05] <jo-erlend_igep> rlameiro, you're using igepv2 rc?
[18:05] <rlameiro> I am using a IGEPv2 rev 3
[18:05] <rlameiro> rc 3
[18:05] <jo-erlend_igep> oh. I'm using rc1.
[18:06] <rsalveti> hm
[18:06] <rlameiro> in the back i have RC and a 3 writen by hand
[18:07] <rlameiro> jo-erlend_igep: can you check yours?
[18:07] <rlameiro> in the back?
[18:07] <rsalveti> rlameiro: without the usb-hub, does it also happens when you just use a mouse?
[18:08] <jo-erlend_igep> rlameiro, I just did. It sais IGEP 0020 RC and then a hand written 1.
[18:08] <rsalveti> I mean, using the mouse directly, without an usb-hub in the middle
[18:08] <rlameiro> not sure, i will need to reboot and all the process again, but the mouse is usb 1.1 and the usb host oin the board is just/only 2.0, ence the need of a hub
[18:08] <rlameiro> ok, more is more recent
[18:08] <rsalveti> hm
[18:12] <rlameiro> rsalveti: did you had acces to igep's kernel source?
[18:12] <rsalveti> got the access to the website, but still didn't download it
[18:13] <rsalveti> let me take a look on it
[18:13] <rlameiro> do you want me put it on my dropbox for you?
[18:14] <rsalveti> rlameiro: it'd be good to test with the stock kernel from igep, maybe they have the patch already but just didn't publish it
[18:14] <rlameiro> rsalveti: with the mouse directly connected to the USB host on board, nothing
[18:15] <rsalveti> rlameiro: nothing you mean it wasn't even recognized during boot?
[18:15] <rlameiro> is there some tool that allows to visualize the diff of 2 kernel folders?
[18:15] <rlameiro> rsalveti: yes
[18:15] <rsalveti> diff would be enough, but I'm looking more to a git tree or something like that
[18:15] <rsalveti> to see the patches
[18:15] <rlameiro> but as I said, it is a 2.0 port, so it needs a hub to recognise a 1.1 usb
[18:16] <rlameiro> they have a git repo
[18:16] <rsalveti> rlameiro: do you have any other usb device that's 2.0?
[18:16] <rlameiro> rsalveti: i am afraid not, everything is 1.1 compliant
[18:17] <jo-erlend_igep> rlameiro, may I suggest that you try the rsalvetis kernel and see if that fixes it? At least that would confirm that something has changed in a good way.
[18:18] <rsalveti> http://git.igep.es/
[18:18] <rsalveti> the weird thing is that I don't have any usb-related patch...
[18:21] <rlameiro> jo-erlend_igep: yes, i think i will do that
[18:21] <jo-erlend_igep> is it possible that I had that problem with the Poky installation that came with the board, come to think of it. I'm just not sure anymore.
[18:21] <jo-erlend_igep> rlameiro, great, then we will know for sure.
[18:26] <rlameiro> rebooting...
[18:29] <rlameiro> rsalveti: happens the same
[18:29] <rlameiro> with you v4 image
[18:29] <rsalveti> rlameiro: so this is probably related with your board revision
[18:29] <rlameiro> weird..
[18:29] <rsalveti> I'm digging the git tree to see if I see something
[18:30] <rsalveti> rlameiro: do you have the board changelog between revisions?
[18:30] <rlameiro> jo-erlend: can you unplug your hub and plug it again to se if it works?
[18:30] <rsalveti> I'd bet we have a link for it, just didn't find it yet
[18:30] <rlameiro> rsalveti: i am searching it
[18:31] <rsalveti> usb: make disconnect and suspend interrupts work again
[18:31] <rsalveti> from kernel changelog
[18:31] <rsalveti> let me dig the commit
[18:31] <rsalveti> rlameiro: ^
[18:32] <rlameiro> hummm
[18:32] <rsalveti> http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=commitdiff;h=8ea712c38bd5e948d8f2a14d0c5bf4551032fe5b;hp=6fe3e7e1222a3ade418ad8c3b0542686a9a41f30
[18:34] <rsalveti> but I believe we have this commit already...
[18:34]  * ogra_ac guesses that will interfer with other omap boards
[18:34] <rsalveti> we already have it
[18:34] <ogra_ac> ah
[18:35] <jo-erlend_igep> rsalveti, I just did. Everything works.
[18:35] <rsalveti> their tree is based on 2.6.33 =\
[18:35] <ogra_ac> ugh
[18:36] <rlameiro> so, it could be because this is a different tree?
[18:37] <ogra_ac> its three versions behind the current development tree
[18:38] <ogra_ac> *and* it is a separate tree (linux-omap vs linux)
[18:38] <rsalveti> good thing is that it seems they are maintaining a tree by rebasing their changes to 2.6.36
[18:38] <ogra_ac> ah cool
[18:39] <rsalveti> yup, much easier to get the fixes :-)
[18:39] <rlameiro> rsalveti: http://dl.dropbox.com/u/1333955/MAN-PR-IGEP.0020.HW_USER_MANUAL.pdf
[18:40] <rlameiro> page 16 starts talking about revisions, mine is a revision C.
[18:42] <rlameiro> jo-erlend: can you please confirm you revision, if it is C or not?  if it is a B revision it should have writen on the board in white IGEP0020-RB1
[18:43] <GrueMaster> Just fyi, I did a hot unplug, wait 10s, plug of my usb hub on my beagle.  Everything (keyboard, mouse, network, and usb drive with test media) came back no problem.
[18:51] <GrueMaster> Interesting info in the beagle manual on the C3>C4 changes.  *Might* be applicable.  "Uboot:  Turning on VAUX2 for the EHCI fix" and A more advanced fix for the EHCI noise issue on Rev C3 board. This involves a
[18:51] <GrueMaster> change in the power circuitry for the 1.8V rail supplied to the EHCI PHY interface. The power is now derived from the VAUX2 on the TPS65950 through a
[18:51] <GrueMaster> filter circuit.
[18:51] <GrueMaster> I wonder if any of that applies, since the IGEP is based on the beagleboard designs.
[18:51] <rsalveti> rlameiro: http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=commitdiff;h=4911716a8b50fa080e613d2005d7d9a81255c0ca;hp=77fd21409771b51a3969da1f1724854901071e3f
[18:52] <rsalveti> at this patch there's the code to identify the revisions, and set the correct pins for wlan and bt
[18:52] <rsalveti> not related with usb though, but should also be applied
[18:53] <rsalveti> I'm fetching the tree but I'm getting 14KiB/s :-(
[18:53] <rlameiro> rsalveti: they have slow servers
[18:53] <jo-erlend_igep> rlameiro, as I understand it, mine is revision c rc 1.
[18:54] <rlameiro> ok, so mine has a 3 writen by hand, so it shouldnt be an hardware change, else they would write it on the board, its just for tracking of lots maybe
[18:55] <lool> rsalveti: I think they have newer trees than .33
[18:55] <lool> and at least for the kernel, they are sending some patches upstream
[18:55] <rsalveti> lool: they have, these links I sent are all target for 2.6.36
[18:56] <lool> rsalveti: http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=shortlog;h=refs/heads/linux-2.6.35.y for instance seems to be their .35 tree
[18:57] <rsalveti> lool: I'm trying to fetch the tree to see all the patches that could be important for us
[18:57] <rsalveti> but will take a while, very slow server
[18:58] <lool> you're pulling from a linux base, right?
[18:58] <lool> I mean --reference
[19:00] <rsalveti> lool: this branch is a merge branch from linaro, it seems
[19:00] <rsalveti> not a rebase one, so need to check the differences comparing trees
[19:00] <rsalveti> but doesn't seems to have any important fix related to usb
[19:02] <lool> rsalveti: From linaro really?
[19:02] <lool> I was expecting from linux-omap
[19:02] <rsalveti> lool: well, there's a merge from linaro
[19:03] <rsalveti> http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=commitdiff;h=0a500156f2acfe06f270ba02ac004bae548e12d2;hp=27498d7ece6e964b9350aaad1fda1bd3d67e5c25
[19:03] <rsalveti> rlameiro: lool: maybe this patch could help
[19:04] <rsalveti> setting gpio for external vbus
[19:05] <rlameiro> maybe
[19:06] <rlameiro> its possible that is related to some change on the voltage when its unplugged that shuts down the power to that bus
[19:06] <rsalveti> rlameiro: once the fetch is completed I'll generate a new deb for you to test
[19:07] <rsalveti> rlameiro: could be
[19:07] <lool> rsalveti: I find it really cool that they merge from Linaro
[19:08] <rlameiro> rsalveti: i just dont get why does it work with jo-erlend_igep ...
[19:09] <rlameiro> well, there is always the chance of hardware bug
[19:09] <rlameiro> very unlikely, but possible
[19:09] <rsalveti> rlameiro: yep, and could also be related with the peripherals he's using
[19:09] <rsalveti> rlameiro: are you sure your usb hub is not pulling energy from the usb?
[19:09] <rsalveti> it very common to find usb hubs that doesn't respect that and pulls a lot of energy from the usb
[19:09] <rlameiro> this one, no, i bought it today on porpuse, beacuse of that
[19:10] <rsalveti> even the powered ones
[19:10] <rlameiro> it has is own power supply
[19:10] <DanaG> I've seen some USB hubs that, when powered, push power back into the upstream port.
[19:10] <rlameiro> well, that i cant say..
[19:10] <GrueMaster> rlameiro: What is the ps supplied amperage?
[19:10] <rsalveti> urgh, that's ugly
[19:10] <DanaG> Rosewill has some USB hub power-adapters that give well over 5 volts when not heavily loaded.
[19:11] <rlameiro> GrueMaster: the hub power supply its rated at max 2 Amp
[19:11] <GrueMaster> Ok.
[19:11] <GrueMaster> That should be fine then.
[19:11] <rlameiro> and outputs 5v, so its not regulated inside the board
[19:11] <rlameiro> well, at least AFAIK.... i didnt opened the hub yet
[19:12] <rsalveti> you could measure it
[19:12] <rlameiro> but the power supply is a switching power, so it should be regulated
[19:12] <rsalveti> let's also wait to see if this patch could make any difference for you
[19:12] <GrueMaster> I have the same powersupply currently powering my hub on my beagleboard (and my beagleboard is drawing power from it using a USB<>PS connector).
[19:12] <rlameiro> dont have in here my multimeter
[19:13] <rlameiro> GrueMaster: I was thinking in doing that :D
[19:13] <rlameiro> but for now, my igep board uses a palm power supply from my old m515
[19:13] <rlameiro> max output current is 1 Amp...
[19:14] <GrueMaster> Hmmm.  I wonder if it is enough?
[19:14] <rlameiro> well, i dont know, maybe
[19:14] <rlameiro> let me check the hardware reference
[19:15] <rlameiro> GrueMaster: 5Vcc / 1A
[19:16] <rlameiro> it should be enough
[19:17] <GrueMaster> I see that.  Still, could be wavering.  If you can, try a beefier ps.  The board will only draw what it needs.  Just keep it at 5v.
[19:17] <rlameiro> typical is 650 mA, Max is 750mA, so it is more than enough
[19:18] <rlameiro> but i will try with another PS. maybe from an atx ps that i converted to bench PS
[19:19] <rlameiro> problem is that my electronic materials are at my parents garage....
[19:19] <rlameiro> no space on the condo..... GRRRRR
[19:19] <GrueMaster> Just be very careful.  We can't help if you fry your board.
[19:20] <rlameiro> GrueMaster: dont worry :D I play with electronics for a while :D
[19:21] <rlameiro> i wonder if this problems happens with the default poky on the nand...
[19:28] <rsalveti> rlameiro: wait it a bit until I deliver you a new kernel, don't know how secure could be your usb hub
[19:28] <rsalveti> at least the one I got I could easily fry the usb port
[19:29] <rlameiro> ok, i wait
[19:29] <rlameiro> lol
[19:29] <rlameiro> no prob
[19:29] <rlameiro> i send it back to ISEE :D
[19:29] <rsalveti> then I had to remove a resistor from it to avoid pulling from the usb port
[19:29] <rsalveti> haha :-)
[19:29] <rlameiro> oh, you say the usb hub gets fried???
[19:30] <rsalveti> no, the usb port from my computer, or board
[19:30] <rlameiro> lol, that is not a problem, i just go to the shop and say, hey this port doesnt work!!!
[19:30] <rlameiro> :)
[21:14] <rsalveti> rlameiro: http://people.canonical.com/~rsalveti/kernel/linux-image-2.6.35.4+_2.6.35.4+-5_armel.deb
[21:15] <rsalveti> with the vbus patch
[21:15] <rlameiro> rsalveti: thanks :D
[21:15] <rlameiro> I will test it soon
[21:16] <rsalveti> rlameiro: cool
[21:49] <rlameiro> rsalveti: what is linux-firmware-image_2.6.35.4+-5_all.deb for?
[21:59] <rlameiro> rsalveti: update-initramfs: Generating /boot/initrd.img-2.6.35.4+
[21:59] <rlameiro> /etc/kernel/postinst.d/update-notifier: 17: gettext: not found
[22:00] <rlameiro> it output this error
[22:04] <rsalveti> rlameiro: linux-firmware should be the default firmware pack from the kernel
[22:04] <rsalveti> you probably don't need it
[22:05] <rsalveti> rlameiro: hm, try installing gettext and try it again
[22:15]  * rsalveti brb
[22:24] <rlameiro> rsalveti: this one has your network driver patch?
[22:24] <rlameiro> t took alot time to bring it up
[22:24] <rlameiro> dmesg at 65 seconds from boot
[22:24] <rlameiro>     8.168334] libertas_sdio: probe of mmc1:0001:1 failed with error -2
[22:24] <rlameiro> [   68.503753] net eth0: SMSC911x/921x identified at 0xe0808000, IRQ: 336
[22:28] <rlameiro> rsalveti: same thing
[23:02] <rlameiro> uInitrd is really needed?
[23:03] <rlameiro> what does it have inside?
[23:23] <Neko_> rsalveti, I have a related question, what on earth actually creates the uInitrd and uImage stuff from kernel packages?
[23:23] <Neko_> I could not find a single line of code or script that uses uboot mkimage
[23:32] <zumbi> Neko_: flash-kernel
[23:37] <Neko_> oh okay
[23:40] <zumbi> it should depend on uboot-mkimage too (at least on debian does)
[23:40] <Neko_> ah but I installed uboot-mkimage but not flash-kernel
[23:40] <Neko_> well okay
[23:42] <rlameiro> is the uInird really needed?
[23:44] <rcn-ee> rlameiro, pre-lucid that default for my kernels.. more things work better with a uInitrd...
[23:48] <rlameiro> rcn-ee: ok, but what is inside of it?
[23:48] <rlameiro> sorry for the newbiness
[23:49] <Neko_> modules, busybox, some inity stuff
[23:49] <rlameiro> so, the kernel could boot without it, could it?
[23:50] <Neko_> it can and it does
[23:50] <Neko_> but things like the splash screen are in there
[23:50] <rlameiro> ohhhh
[23:50] <rlameiro> ok
[23:50] <rlameiro> lol
[23:50] <rlameiro> uInird uncompreassing and reading takes half the time of my kernel booting
[23:50] <Neko_> and maybe some ureadahead stuff? I'm not sure.. it would make sense that the initrd precache from disk
[23:50] <rlameiro> so i think i will drop it
[23:51] <Neko_> one thing I do know is without initrd maverick sometimes takes 30 seconds to get to login, but with, it's never more than 15.. sometimes it's 9 ;)
[23:51] <Neko_> it's important because ubuntu and every other linux distro assumes you've got one and stuff gets shuffled in there
[23:51] <rlameiro> ok, now you are talking :D
[23:52] <rlameiro> but it dosnt have driver and stuff inside of it, does it?
[23:52] <rcn-ee> it's got your modules. ;)
[23:53] <rlameiro> lol, so i am debugging stuff with other modules...
[23:53] <rcn-ee> correct, are you just trying to speed things up?
[23:54] <rlameiro> no, just trying to prove that something is wrong with my usb host
[23:54] <rlameiro> it doesnt work...
[23:54] <rcn-ee> igepv2 right? the ehci or otg?
[23:54] <rlameiro> as last resort, i used the igepv2 kernel
[23:54] <rlameiro> but they dont have uInitrd
[23:54] <rlameiro> hence the question
[23:55] <rcn-ee> you can boot, then generate one. ;)
[23:55] <rcn-ee> then reboot..
[23:55] <rcn-ee> you can actually boot with the wrong different uImage/uInitrd's (it won't use it.) generate a new uInitrd and then reboot..
[23:56] <rlameiro> but if i boot with another kernel, the modules inside uInitrd will not load if they arent build against it, true?
[23:56] <rlameiro> ah ok
[23:56] <rlameiro> well, then is confirmed
[23:56] <rcn-ee> exactly.. so hopefully you extract the modules to your rootfs.. and that rootfs driver (extX) is builtin...
[23:56] <rlameiro> either it is hardware bug, or some stuff igep needs to add to the kernel :D
[23:57] <rlameiro> not my fault, not ubuntu fault, not linaro :D
[23:57] <rcn-ee> btw, is it the ehci or otg port?
[23:57] <rlameiro> ehci
[23:57] <rlameiro> host