[00:00] <DanaG> I find that even my AHCI host system needs initrd, since the ahci driver is no longer built-in.
[00:02] <rcn-ee> rereading bug report... rlameiro does it work if you leave a usb-flash connected when you remove and insert another device?
[00:03] <rlameiro> rcn-ee: didnt tried
[00:03] <rlameiro> i will try now
[00:03] <rlameiro> need to reboot first
[00:04] <rlameiro> rcn-ee: thats another weird thing
[00:04] <rcn-ee> okay, no rush.. we had something like that on the beagle.. at one time everything had to be plugged in at boot.. weird things would happen if all devices where removed then added.. so the trick was to leave something connected.. 2.6.29 days..
[00:04] <rlameiro> i plugged now the hub and it didnt recognied it
[00:05] <rlameiro> it needs to be connected at boot
[00:05] <persia> rlameiro, You don't want to not use an initrd: theoretically it works without one, but that path is very poorly tested, and prone to issues.
[00:09] <rlameiro> rcn-ee: !!!!! WORKS!!!!!!!
[00:09] <rlameiro> how can i mount my flash drive on the cli
[00:10] <rcn-ee> mkdir ./tmp ; sudo mount /dev/sdxX ./tmp
[00:11] <rcn-ee> so it sounds like an ehci bug.. when no devices are connected it turns to a state and new devices don't get it out..
[00:11] <rlameiro> yeap
[00:11] <pwnguin>  /win 14
[00:12] <rlameiro> rcn-ee: how do i know th xX on the sdxX ??
[00:12] <rlameiro> sorry for the newbiness
[00:12] <rcn-ee> no problem... "sudo fdisk -l" L.. is easiest
[00:14] <rcn-ee> thinking out loud and googleing..... isn't there a "debug-usb" option for the bootargs?
[00:15] <rlameiro> rcn-ee: so, is there a correction for this bug?
[00:17] <rcn-ee> on the beagle it was: use a newer kernel that worked better... but that was 2.6.27/28/29 days.. so i dont' think that one applies..  I'm looking on google for a way to debug the usb subsystem on bootup, maybe that would show something..
[00:20] <rcn-ee> rlameiro, does your current kernel have "cat /boot/config-* | grep CONFIG_USB_DEBUG" ?
[00:21] <persia> I think most of the DEBUG config options aren't used (and `grep CONFIG_USB_DEBUG /boot/config-*` is faster)
[00:22] <persia> Unless there's a way to change them via boot parameters, might need a special kernel build.
[00:22] <rcn-ee> yeah it is thanks. ;)  rlameiro does it also happen with my kernel?
[00:22] <rcn-ee> take me about 3 minute to build one if it does..
[00:22] <persia> (we had issues in the past with kern.log overflowing the SD cards, and had a firm discussion with the kernel team)
[00:23] <rcn-ee> yeah, that's way to wear out an SD card quickly. ;)
[00:23] <rlameiro> rcn-ee: yes it did  happend with you kernel
[00:23] <rcn-ee> okay, then it'll be a valid test, just take a moment..
[00:23] <persia> Filled them up back in the early imx51 days when folks were using pre-pre-pre-production hardware.  I ended up writing a syslog.conf fragment so that people could complete the installer.
[00:25] <rcn-ee> I'm seeing something similar with my hacked up lucid NetInstall, the 2.6.35 kernel's HID input it noisy, the log is unreadable..
[00:28] <rcn-ee> okay they are up... rlameiro uImage and modules here.. and yes it's about 20kb download. ;) good for beer breaks..  http://rcn-ee.homeip.net:81/testing/lp-646985/CONFIG_USB_DEBUG/
[00:46] <rlameiro> rcn-ee: what did you put on your kernel?
[00:46] <rlameiro> its working
[00:47]  * persia dislikes heisenbugs intensely
[00:47] <rcn-ee> crap, what? did my previous build work? alli changed was two configs...
[00:47] <rlameiro> well
[00:47] <rlameiro> stoped working...
[00:47] <rlameiro> wow
[00:47] <rcn-ee> yay! ;) the logs should have more usb stuff..
[00:48] <rlameiro> where is the log file?
[00:49] <rcn-ee> it should be in the system log... off the top of my head i don't remeber which one.. but "dmesg > log.txt" then pastebin that log.txt should give us an idea of what's happening..
[00:50] <persia> /var/log/kern.log most likely
[00:50] <persia> Oh, and /var/log/dmesg.log may also be interesting, but likely less verbose.
[00:50] <rcn-ee> so both just incase. .;)
[00:50] <rlameiro> rcn-ee: http://dl.dropbox.com/u/1333955/usb.txt
[00:51] <rlameiro> dmesg > ub,txt :D
[00:51] <rlameiro> i forgot how cool is piping :D
[00:52] <rcn-ee> humm.. usb: resume on port1, status -19
[00:53] <persia> Next trick: `pastebinit /var/log/dmesg`
[00:53] <rlameiro> dont be scared its a 10 port hub
[00:53] <persia> The one with the extra socket on the end?
[00:54] <rlameiro> http://pastebin.com/P613QrxR
[00:54] <rlameiro> persia:  its trust one
[00:54] <persia> different than mine then :)
[00:55] <rlameiro> http://www.trust.com/products/product.aspx?artnr=16131
[00:56] <rcn-ee> humm, i'm stumped. ;)  i'd add that dropbox link to the launchpad bug, we are going to need one of the ti/nokia usb guys to look at it..
[00:57] <rlameiro> good that you mentioned it
[00:57] <rlameiro> i could delete it otherwise
[00:57] <persia> Better to put the original file into the bug, rather than the link to dropbox, just in case.
[00:57] <rcn-ee> you could upload it too.. then not worry about hosting it..
[00:58] <rcn-ee> it looks like it's defintelly stuck in suspend mode...
[00:59] <rlameiro> i can try with a diferent hub
[00:59] <rlameiro> 4 ports self powered
[00:59] <rlameiro> will it make diference?
[00:59] <rcn-ee> it might... if it fails it's just more ammo for a bug..
[01:00] <rlameiro> ok
[01:03] <rlameiro> http://pastebin.com/RmnF40NZ
[01:03] <rlameiro> with the other, this was faster failing
[01:06] <rlameiro> rcn-ee: http://dl.dropbox.com/u/1333955/usb4.txt
[05:34] <Neko_> is there a uboot irc channel?
[09:18] <persia> Neko_, Used to be #u-boot, but has been deregistered.  Dunno to where folks may have migrated (if they did).
[13:41] <ajay> hi all i have ubuntu 10.04 kernel and Serial controller: Device 4348:3253 but minicom is not working on this
[13:41] <ajay> i mean no boot message i  am able to get over serial port
[13:50] <persia> The images we produce don't use serial console by default.
[13:50] <persia> You'd have to do something special to get one (add it to kernel command line, etc.)
[13:56] <rcn-ee> hey persia, how frozen is the kernel for new patches? ;)  With the help of some meego guys, we figured out which 11 patches cherrypicked from 2.6.36 make the display work correctly on 2.6.35.. ;)  I'll file a bug and list the patches, so you guys can decide. ;)
[13:56] <rcn-ee> duh, i should list teh board... devkit8000
[13:58] <persia> rcn-ee, Which kernel?
[13:59] <persia> (the answer will be somewhere between jello and cabonite)
[14:00] <rcn-ee> the 11 patches were merged in the 2.6.36-rc with tony's merge.. they apply cleanly to the 2.6.35 kernel..  They basicly fix the power rails so the display actually gets setup properly...
[14:00] <persia> I should have asked: "Which kernel source package in Ubuntu?"
[14:01] <rcn-ee> um.. the combined omap3/x86 tree.. it only touches arch/arm/mach-omap2/board-devkit8000.c
[14:02] <persia> "linux"?  That would be "carbonite".  We have to show security fault, major regression, user data loss, etc.
[14:02] <persia> But we can prepare a set of patches to be dropped immediately post-release as an update.
[14:04] <rcn-ee> right now it'll bootup: omapfb error or something about can not init display....
[14:05] <rcn-ee> the problem with these boards, not a lot of people have them so it's not a big % (i don't even have one to test)  But i can file a bug link to the patches then if someone tries to run ubuntu with a devkit8000 will have a bug to read and help debug. ;)
[14:08] <persia> Please do file a bug.  Extra points for shepherding the patches through the SRU process to make them available post-release.
[14:08] <persia> Folks won't be able to use the display first-boot, but ought be able to update, and use it second boot.
[14:09] <rcn-ee> true..  and since they are merged, maverick+1 will work out of the box.. (pending some random breakage patch. ;))
[14:49] <rlameiro> afternoon
[14:50] <rlameiro> jo-erlend_igep:hey, wasnt you that had a problem with wifi on igep?
[16:29] <rlameiro> igep is going to launch a 1ghz version with OMAP3730
[18:56] <rlameiro> saturday its really slow over here...