[00:21] <elwood> hi
[00:22] <elwood> i've a broken usb-port on my pc, the kernel.log is full of "garbage" about it. There is a way to stop the scan for this port? it'a kernel or udev question?
[00:23] <IntuitiveNipple> A port or a host controller?
[00:23] <IntuitiveNipple> short of disconnecting it physically, there's no way to disconnect a port from a host... often the ports are shared by multiple host controllers, too.
[00:24] <elwood>  hub 1-0:1.0: unable to enumerate USB device on port 4
[00:24] <elwood> this is the log, just and always the port 4
[00:25] <elwood> with hal i can drop all the log to /dev/null? this is the first thing that pop-ups in my mind :)
[00:26] <IntuitiveNipple> no, the report is from the kernel module.
[00:26] <elwood> ok, and i suppose there is no parameter for the module
[00:26] <IntuitiveNipple> maybe try repairing or disconnecting the port?
[00:27] <elwood> so i can remove it physically, this is the way
[00:27] <IntuitiveNipple> maybe not 'remove' it but electrically disconnect it so the hub doesn't try to select it... but that would require some in-depth systems knowledge. There's no way to isolate it from the kernel that I know of.
[00:28] <elwood> IntuitiveNipple, even if i recompile without log info for the kernel?
[00:28] <IntuitiveNipple> That's rather a drastic approach - what if something else happens and there's no reports?
[00:29] <elwood> a disaster, well thanks IntuitiveNipple 
[00:29] <IntuitiveNipple> You could add a rule to syslog.conf
[00:29] <elwood> uhm
[00:29] <elwood> a filter on this warning
[00:30] <IntuitiveNipple> no, you can't filter on text, but you can set a rule so it doesn't log messages from particular facilities.priorities
[00:30] <elwood> this is what i means with "filter", well you make me find a reasonable solution, thanks again IntuitiveNipple 
[00:50] <dandel> apw, you there?
[01:03] <IntuitiveNipple> He's probably fast asleep in bed this time of morning
[01:12] <dandel> uck... i need a rebuilt copy of the 2.6.25 mainline
[01:13] <dandel> the one that is on the ubuntu mainline section won't boot enough to help with generating a git disection. 
[01:14] <dandel> i keep having 2.6.25 stall just after saying done on the section, Begin: Running /scripts/local-premount ...
[01:16] <IntuitiveNipple> You could use break=top to drop into the initrd and poke around
[01:16] <dandel> add that where?
[01:17] <IntuitiveNipple> kernel command line
[01:17] <dandel> ok
[01:17]  * dandel checks
[01:17] <IntuitiveNipple> In the /init script is loads of calls to maybe_break XXXXX and if XXXX matches the command-line's break= it'll stop
[01:17] <IntuitiveNipple> Or, use just "break" and it'll stop at top anyhow
[01:18] <IntuitiveNipple> You can break at other places; need to look in the /init script (in the initrd) to decide which ones to use)
[01:19] <dandel> it appears that it gets stuck mounting
[01:20] <dandel> 2.6.24 and 2.6.26 work, but 2.6.25 stalls out
[01:20] <IntuitiveNipple> What I sometimes do is add "set -x" to the top of the /init script so I can see all the script commands executing... if it pauses/gets stuck the last ones on screen are a bug clue
[01:20] <dandel> ?
[01:21] <IntuitiveNipple> It causes the shell to write out all commands it is about to execute
[01:21] <dandel> where do i put that exactly?
[01:22] <IntuitiveNipple> 2nd or later lines in /init, in the initrd. You'll need to extract and then repackage the initd image
[01:22] <dandel> ><;
[01:23] <IntuitiveNipple> I've got some documentation on how to do that as part of a laret article
[01:23] <IntuitiveNipple> http://tjworld.net/wiki/Linux/Ubuntu/NetbootPxeLiveCDMultipleReleases#ExtractInitrd
[01:24] <IntuitiveNipple> To extract the image see the section "Extract Initrd" and after changing the script, see "Rebuild Initrd"
[01:24] <dandel> ok...
[01:26] <dandel> ok.
[01:27] <dandel> add set -x just after...  #!/bin/sh ?
[01:27] <IntuitiveNipple> Yes
[01:29]  * dandel boots to see what happens.
[01:31] <dandel> oops lol... forgot to add it to grub.
[01:32] <IntuitiveNipple> :p
[01:32] <IntuitiveNipple> did it spew the commands though?
[01:33] <dandel> i'll find out
[01:35] <dandel> it's not finding it ><;
[01:38] <IntuitiveNipple> which 'it' is not finding what 'it' ?
[01:39] <dandel> the custom initrt... found the issue tho
[01:40] <dandel> although, i wish i could flat out disable system beep on a lot of things
[01:40] <dandel> hmm
[01:40] <dandel> interesting
[01:41] <dandel> stops at the command... mount -w -t ntfs -o locale=en_US ( ya get the rest )
[01:42] <dandel> it appears it's running the mount commands wrong
[08:18] <maxb> smb_tp_: Hi, ubuntu-intrepid-lbm.git doesn't contain the final debian/changelog update and tag for the latest package, did it remain accidently unpushed locally with you, perhaps?
[08:19] <smb_tp_> maxb, hi, let me check
[08:20] <smb_tp_> maxb, Yeah, sorry. Pushing in a sec
[08:21] <smb_tp_> done
[08:21] <maxb> thanks :-)
[08:23] <maxb> Hmm. my git is claiming there is no tag for this release?
[08:25] <smb_tp> maxb, Too early in the morning to do two steps...
[08:25] <maxb> heh
[08:25] <smb_tp> Now
[08:25] <maxb> I guess that answers my next question: the insertchanges/commit/tag isn't automated anywhere?
[08:26] <smb_tp> maxb, No, has to be done manually. And it has to be pushed separately (it least I had problems doing it in one go)
[08:27] <smb_tp> So This time the tag was created, but I had to "push --tags"
[08:28] <maxb> Yeah, git's a bit mystical to me. I don't really understand when you do and don't need --tags
[08:29] <smb_tp> To me it looks like a extra thing just for tags. So git fetch --tags just updates the local tags and git push --tags sends them
[08:30] <smb_tp> Without tags it seems only to do the actual contents
[08:31] <maxb> the fetch/push documentation hints that it tries to transfer tags relating to commits that are being transferred. But I have a feeling that's not always worked as claimed for me.
[08:32] <maxb> or I've not quite understood the algorithm, anyway
[08:32] <smb_tp> Same with me. So I use it in that way that seems to work with my thinking (if I do not forget the steps)
[09:44] <_ruben> bugger .. dkms isnt picking up my second make command as specified in dkms.conf :(
[09:49] <IntuitiveNipple> syntax issue?
[09:53] <_ruben> could very well be .. but im not seeing it .. lemme pastebin my conf
[09:55] <_ruben> http://paste.ubuntu.com/136597/ .. i tried both MAKE[1] and MAKE[10] .. as the result of the 2nd make are marked with [10] directives
[09:56] <IntuitiveNipple> _ruben: Why not simply use a Makefile and call it once?
[10:01] <IntuitiveNipple> _ruben: but, to use MAKE[10] you need a MAKE_MATCH[10] rule too
[10:18] <_ruben> IntuitiveNipple: hmm .. didnt think of the MAKE_MATCH directive .. but i can think i can solve it at makefile level indeed
[10:18] <IntuitiveNipple> MAKE_MATCH is required if you use MAKE[>0]
[10:20] <_ruben> then there's a bug in the docs:
[10:20] <_ruben> https://help.ubuntu.com/community/Kernel/DkmsDriverPackage#Configure%20DKMS
[10:20] <_ruben> it mentions just a MAKE[1]
[10:21] <IntuitiveNipple> _ruben: man dkms
[10:27] <apw> IntuitiveNipple, hey ... bug #331415 ... have you a current status on that one, its on our regressions list :)
[10:27] <ubot3> Malone bug 331415 in linux "request_firmware() fails on resume from suspend" [Medium,Triaged] https://launchpad.net/bugs/331415
[10:28] <IntuitiveNipple> apw: WIP it's a biggie. I'll update it later on
[10:29] <apw> IntuitiveNipple, thanks ... be good to sync up on it before the meeting this evening
[10:31] <IntuitiveNipple> It's a time-consumer! every driver has to be examined and figured out... I'm doing a little bit at a time
[10:36] <IntuitiveNipple> apw: I think it can loose it's regression-potential since it's always been like that :)
[10:36] <IntuitiveNipple> apw: removed tag
[10:37] <apw> IntuitiveNipple, thanks for that ... one less to worry about
[10:37] <IntuitiveNipple> yeah... I was combing the list yesterday, managed to find a few that moved closer to a resolution
[11:02] <amitk> hehe... Linus' 2.6.29 release mail got flagged as SPAM in gmail :)
[11:04] <amitk> apw: can you pull the levers on a new mainline build?
[11:04] <amitk> apw: or tell me how to
[11:04] <apw> amitk, which one you missing.  there is a build in progress right now, so its probabally the one you wanted
[11:05] <amitk> apw: 2.6.29 final?
[11:05] <apw> i think i saw it doing a .27 and a .28 ...
[11:05] <apw> ok will check when these finish
[11:05] <apw> and i will get the thing running out of cron this week
[11:05] <apw> the triggers are automatic in theory
[11:07] <apw> amitk, yeah its just done 27.21, its on 28.9 and will do .29 next i believe
[11:07] <apw> so in the next hour or so
[11:07] <amitk> cool, thanks apw 
[11:08] <TheMuso> c
[11:08] <apw> i have been monitoring the builds, and so hand triggering what is meant to be a cron job
[11:08] <apw> so its a simple matter of shoving it in cron (or should be)
[11:11] <dandel> apw, the bug i'm on is stuck until the 2.6.25 kernel gets fixed on boot ><; (it gets stuck on mounting )
[11:11] <amitk> apw: do you do a allmodconfig?
[11:11] <apw> nope, they are built using our ubuntu configs
[11:11] <apw> make oldconfig from those
[11:11] <apw> we can override config options where neceessary
[11:13] <apw> like for hardy we reenable some wireless stuff which is in lbm
[11:14] <amitk> ok
[11:17]  * Kamping_Kaiser gazes at the wall
[12:42] <amitk> apw: bug #322311 and bug #338316 marked as 'Won't Fix' for the two arm flavours
[12:42] <ubot3> Malone bug 322311 in qcontrol "orion5x armel flavour should provide input-modules" [Undecided,New] https://launchpad.net/bugs/322311
[12:42] <ubot3> Malone bug 338316 in linux "Please add a MV78XX0 arm flavour" [Wishlist,Won't fix] https://launchpad.net/bugs/338316
[12:42] <apw> amitk, cool
[12:44] <rtg> apw, amitk: were there other bug fixes besides VFP for those flavours that we can remove?
[12:46] <apw> i don't recall doing any
[12:52] <amitk> rtg: I mentioned ce65d39bbcfaa3c0150891122df79f5ab2db550d needed to be reverted
[12:53] <rtg> amitk: see 14b2f940288288774f74414a0902d578d29d9076
[12:54] <rtg> amitk: oops, nm
[12:56] <amitk> hehe
[12:56] <rtg> amitk: ok, you're right. tehre were 2 VFP patches and I missed the second.
[12:58] <rtg> amitk: I'm not familiar with all of the ARM model names. To which flavour does the Feroceon CPU belong? orion5x or mv78xx0 ?
[12:59] <amitk> rtg: mv78xx0
[12:59] <rtg> amitk: thanks
[13:27] <_ruben> http://paste.ubuntu.com/136726/ .. i forgot skipabi=true on the first run .. do am i missing here? or is a clean+rebuild needed or something?
[13:53] <cooloney> bradF, did you boot up with your own rootfs
[13:54] <cooloney> bradF, amitk i also boot up my own kernel.
[13:56] <cooloney> as bradF said, we need to download the kernel to 0x00100000
[13:57] <cooloney> that is the entry point of the kernel image
[13:58] <amitk> right
[14:00] <cooloney> amitk, how about the kernel command line of your board?
[14:00] <cooloney> i try to mount the rootfs with my own kernel
[14:02] <cooloney> after replacing the kernel of ogra image with my own, the kernel cannot mount rootfs
[14:04] <amitk> root=/dev/sda2
[14:04] <amitk> i use root on a usb stick
[14:05] <cooloney> OK, i will try, thx
[14:11] <cooloney> it is so weird
[14:12] <cooloney> http://pastebin.ubuntu.com/136755/
[14:12] <cooloney> amitk, what kind filesystem are you using on the usb stick?
[14:13] <amitk> cooloney: ext2
[14:14] <rtg> amitk: is ext3 built in?
[14:15] <amitk> rtg: yes, i think so
[14:16] <amitk> yes, it is
[14:16] <rtg> amitk: it even says so
[14:16] <amitk> rtg: what does?
[14:17] <cooloney> rtg, yes, ext3 built in
[14:18] <rtg> amitk: No filesystem could mount root, tried:  ext3 ext2 cramfs vfat msdos
[14:18] <amitk> aah, right
[14:18] <amitk> cooloney: do you have initramfs loaded?
[14:18] <rtg> amitk: noinitrd on the command line
[14:18] <cooloney> amitk, currently no
[14:19] <cooloney> RedBoot> fconfig
[14:19] <cooloney> Run script at boot: true
[14:19] <cooloney> Boot script: 
[14:19] <cooloney> .. clock 800
[14:19] <cooloney> .. fis load kernel
[14:19] <cooloney> .. exec -c "console=ttymxc0,115200 console=tty1 root=/dev/sda2 rootdelay=10 ro noinitrd"
[14:19] <amitk> USB_STORAGE is built-in. Is your usb disk supported w/o modules?
[14:20] <amitk> and is the rootfs on /dev/sda2?
[14:20] <cooloney> amitk, do you think i should add "fis load initramfs"
[14:20] <cooloney> sorry, what is "w/o modules?"
[14:20] <rtg> yeah, shouldn't root be /dev/sda1 ?
[14:21] <amitk> cooloney: do you need any special modules besides usb-storage
[14:21] <cooloney> OK, let me try it.
[14:21] <anubhav> cooloney: can you append "rootwait" to your command line
[14:22] <cooloney> anubhav, i will try it
[14:25] <cooloney> amitk, rtg anubhav thanks, i found root is sda1 as ext3 on my usb stick
[14:26] <rtg> cooloney: makes sense to me
[14:26] <cooloney> since this usb stick is from colleague freeflying
[14:26] <cooloney> i did change it's content at all
[14:26] <cooloney> amitk, should i build my own rootfs from scratch?
[14:27] <amitk> cooloney: you don't have to
[14:27] <cooloney> i just need to boot the board to command line console over serial for development, i guess
[14:27] <amitk> right
[14:27] <rtg> cooloney: babbage?
[14:27] <cooloney> rtg, yes
[14:28] <cooloney> babbage early version
[14:28] <rtg> cooloney, amitk: does it work with SATA yet? I'cve got one, but the USB drive is _really_ slow.
[14:29] <cooloney> rtg, i dont have sata on my side, just know SD and USB stick is ok 
[14:30] <rtg> cooloney: looks like you build the kernel? Our Freescale port using the cross compiler tools?
[14:31] <amitk> rtg: it was native built
[14:31] <cooloney> rtg, right, i cross compiler our jaunty kernel to zImage
[14:31] <amitk> rtg: but you can replace the kernel with a cross-compiled one
[14:31] <rtg> amitk: Sourcery G++ Lite 2008q3-72
[14:31] <cooloney> and downloaded the zImage to boot up now
[14:32] <amitk> rtg: yeah, good enough
[14:32] <cooloney> amitk, i replaced the kernel from ogra image with my own kernel from cross-compiled one
[14:32] <rtg> amitk: its interesting because its the first time I've seen the cross compiled kernel booted. Its just verification that it works taht way.
[14:34] <amitk> rtg: you mean the first time you've seen cross-compilation used for something other than build verification?
[14:34] <rtg> amitk: in this particular case, yes
[14:35] <amitk> rtg: I've been using cross compiled kernels for the last month or so while we were integrating and testing the babbage flavour
[14:35] <rtg> amitk: its certainly a much faster way to build, isn't it?
[14:36] <amitk> rtg: hell yeah! I'd go nuts doing this in Qemu or natively
[14:36] <rtg> the babbage was taking several hours per flavour
[14:36] <bradF> cooloney: haven't tested my own rootfs yet, just the kernel
[14:37] <amitk> rtg: it takes about 15-20 minutes on my rather old desktop machine for the babage kernel
[14:37] <rtg> amitk: :) I can beat that by 15 minutes.
[14:38] <cooloney> amitk, rtg are you talking about cross-compiling babbage kernel on x86 machine?
[14:38] <amitk> rtg: showoff!
[14:38] <amitk> cooloney: yes
[14:38] <rtg> cooloney: dual quad core w/18GB RAM.
[14:39] <bradF> cooloney: that's how I am building my kernels
[14:40] <bradF> cooloney: rtg likes to brag :-)
[14:40] <cooloney> rtg, really cool
[14:40] <cooloney> bradF, lol
[14:40] <cooloney> guys, let me test on my side
[14:40]  * rtg thinks bradf has computer envy.
[14:40] <amitk> cooloney: you were _not_ cross-compiling until now?
[14:41] <bradF> rtg feels sad for rtg
[14:41] <cooloney> i always cross built
[14:41]  * bradF feels sad for rtg
[14:41] <cooloney> but dont know the time
[14:41] <rtg> amitk: that was the whole point of this discussion, e.g., I noticed that he booted a cross compiled kernel.
[14:41] <cooloney> hehe, let me collect the timing info
[14:42] <amitk> right... 
[14:43] <bradF> amitk: what's the word on the 'securityfs' for AA? should I chase that?
[14:44] <bradF> amitk: just saw your email...will try it
[14:45] <rtg> is there still an AA upstream to send it to ?
[14:45] <amitk> bradF: it certainly seems worth a shot to see if enabling securityfs is all thats needed. Though I vaguely recall having tried that.
[14:46] <amitk> rtg: If there isn't, then what're we doing carrying around that patch and letting it bitrot?
[14:46] <rtg> amitk: Its a topic for UDS, but I'm thinking this is the last release with AA.
[14:47] <amitk> interesting
[14:48] <cooloney> can i reproduce this bug on my side?
[14:48] <cooloney> if bradF needs help, i can join in
[14:48] <bradF> cooloney: are you talking about the apparmor bug?
[14:48] <cooloney> right
[14:48] <cooloney> AA = apparmor, if i am not wrong?
[14:48] <rtg> cooloney: correct
[14:49] <bradF> it's easy to repro, just go into your config and change the CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE from 0 to 1
[14:49] <bradF> cooloney: then if you don't have my patch, it will oops
[14:50] <rtg> bradF: with your latest patch (which I have not applied), how does it behave? Just the usual VFS can't find root halt?
[14:50] <cooloney> ok, booting oops?
[14:50] <bradF> cooloney: yes, booting oops, every time
[14:51] <cooloney> great, i will try 
[14:59] <bradF> rtg: yes on "can't find root"
[15:00] <cooloney> cross-compiling imx51 deb package on my side nees 13m
[15:00] <rtg> bradF: so, we're just trading on oops for another? albeit a bit more understandable.
[15:00] <rtg> one*
[15:00] <bradF> rtg: going to hook up a rootfs and see if it comes all the way up (looks like cooloney will probably try this as well)
[15:01] <bradF> rtg: are you talking about the securityfs?
[15:01] <rtg> bradF: yes
[15:01] <cooloney> bradF, yes, i plan to do it. but it seems that it will take too much time to build a root fs on my side
[15:02] <amitk> rtg: if AA truly needs securityfs, then it should be a autoselected dependency
[15:02] <bradF> rtg: the missing securityfs doesn't cause an oops, just that AA is not doing anything
[15:03] <rtg> bradF: ok, thats what I wanted to know. With the patch you can boot a rootfs, but without AA support, correct?
[15:03] <bradF> rtg: let me run a couple of tests, but yes that is what I believe
[15:04] <rtg> bradF: ok, when you're comfortable send me a pull request.
[15:06] <bradF> rtg: will do
[15:07] <bradF> amitk: i understand your point and depending on my testing my submit another patch 
[15:07] <bradF> s/my/may/
[15:07] <amitk> bradF: sure, take your time.
[15:08] <charlie-tca> I downloaded today's images, they passed md5sums. I burned the Xubuntu jaunty-alternate-i386.iso to a cd-r. It passes the cd integrity check with no errors. I attempt to install to a hardware system. It fails with 
[15:08] <charlie-tca> Warning: file:///cdrom/pool/main/x/xkeyboard-config/xkb-data_1.5-2ubuntu9_all.deb was corrupt
[15:09] <charlie-tca> (I burned another cd-r that works) Should I report this as a bug?
[15:09] <amitk> charlie-tca: this is best reported on #ubuntu-devel
[15:09] <charlie-tca> Okay, thanks
[15:11] <bradF> amitk: the kernel I just booted with the securityfs enabled seems to be working!
[15:11] <amitk> interesting
[15:12] <amitk> so it _is_ a dependency
[15:12] <bradF> amitk: [42949373.670000] AppArmor: AppArmor Filesystem Enabled
[15:12] <bradF> amitk: yup
[15:12] <rtg> bradF: so I should expect some config changes along with the oops prevention?
[15:14] <bradF> rtg: they are independent of each other but the config change is necessary to run AA on imx51 (and all other flavours)
[15:14] <apw> the oops prevention is moot if its a dependancy and so recorded in the config
[15:15] <amitk> bradF: this kernel is w/o your oops prevention patch?
[15:15] <bradF> amitk: it has both
[15:15] <bradF> amitk: however, it should work without my oops patch, will test
[15:15] <rtg> bradF: see if it works with just the config change
[15:15] <amitk> bradF: yeah, that would be interesting
[15:16] <bradF> apw: I see your point
[15:16] <apw> it does sounds like an unrecorded interdependancy to me
[15:18] <amitk> though the oops prevention is what triggered the securityfs config light-bulb if I understood bradF correctly.
[15:18] <bradF> apw: it still seems like it should handle a missing securityfs a little better than an oops
[15:18] <bradF> amitk: yes
[15:18] <apw> bradF, not if its a depanancy, it should just be linked in the Kconfig magic
[15:19] <apw> and then become impossible to enable without the securityfs enabled
[15:29] <cooloney> bradF, is this boot oops?
[15:29] <cooloney> [42949373.670000] AppArmor: Error creating AppArmor securityfs
[15:29] <cooloney> [42949373.700000] AppArmor: AppArmor protection removed
[15:30] <bradF> cooloney: after that you should get am actual oops and a backtrace
[15:30] <cooloney> bradF, right, i reproduce it
[15:31] <cooloney> thx
[15:31] <bradF> cooloney: http://pastebin.ubuntu.com/136819/
[15:35] <bradF> cooloney: it looks like you just need to enable the security fs and you don't need the patch I put out
[15:36] <cooloney> bradF, thx, i can test your method on my side
[15:43] <apw> cking, any idea waht a bcdDevice means in the context of usb?
[15:43] <Keybuk> apw: device id in binary coded decimal
[15:44] <Keybuk> USB is *all about* bcd
[15:44] <apw> hrm, so something above and beyond its normal id's
[15:44] <apw>   idVendor           0x04ce ScanLogic Corp.
[15:44] <apw>   idProduct          0x0002 SL11R-IDE IDE Bridge
[15:44] <apw>   bcdDevice            0.78
[15:44] <apw> so that is a triplet in usb land?
[15:45] <Keybuk> i think so yea
[15:45] <Keybuk> it's basically the version number
[15:46] <_ruben> hmm .. recompiling kernel is taking up a fair amount of cpu sys % .. i'd expect just usr .. then again, havent rebuilt kernels in ages :p
[15:46]  * apw learns yet another new thing today
[15:46] <cooloney> apw, IMO, it is right, 
[15:46] <cooloney> idVendor           0x05ac Apple, Inc.
[15:46] <cooloney>   idProduct          0x8242 
[15:46] <cooloney>   bcdDevice            0.16
[15:47] <apw> Keybuk, any  idea what waht base the output is in 
[15:47] <apw> is it decimal, or hex or?
[15:47] <cooloney> it is just a version number as Keybuk said
[15:47] <apw> right but the output of the lsusb command what base is it in there
[15:48] <cooloney> yes, lsusb will convert the binary code to such version number
[15:48] <IntuitiveNipple> apw: decimal
[15:48] <Keybuk> apw: binary coded decimal
[15:48] <cooloney> it should be 0x1600
[15:49] <cooloney> right?
[15:49] <Keybuk> http://en.wikipedia.org/wiki/Binary-coded_decimal
[15:49] <apw> hrm, i see, so its literally in hex in some sense
[15:49] <Keybuk> right you literally read the hex
[15:49] <Keybuk> 0110 is read is 1.10
[15:50] <Keybuk> 0206 is 2.06
[15:50] <Keybuk> etc.
[15:50] <apw> ok, so yeah bcd is hex format but you arn't allowed to use some of the combos
[15:50] <apw> thanks
[15:50]  * apw puts USB on his idiot idea list
[15:51] <rtg> IntuitiveNipple: I'm just looking at your RCU backport. Is that patch in response to smb_tp's RFC on boot pauses?
[15:52] <Keybuk> apw: USB is great!
[15:52] <Keybuk> it's ALL about the ids ;)
[15:52] <Keybuk> every gadget has a vendor and a product id
[15:52] <cooloney> Keybuk, really, it should be 1.10 = 1001
[15:52] <Keybuk> and a device version number
[15:52]  * apw slaps Keybuk ... get a grip man :)
[15:53] <Keybuk> and each device may have multiple configurations
[15:53] <cooloney> 2.06 = 0602
[15:53] <apw> cooloney, that _all_ depends on your endiannes
[15:53] <IntuitiveNipple> rtg: Yes, it is backported from the upstream commit 
[15:53] <Keybuk> depending on the configurations, you then have multiple interfaces
[15:53] <cooloney> apw, for usb it should be lsb little endian
[15:54] <rtg> IntuitiveNipple: I got that part. I was wondering _why_ you did the backport.
[15:54] <Keybuk> and only then do you actually find out what the device *is* :p
[15:54] <Keybuk> cooloney: err, is it?
[15:55] <Keybuk> I'm pretty sure it's big endian
[15:55] <IntuitiveNipple> rtg: Ingo Monar in the upstream bug thought the commit may solve the issue, so I figured we should try it against our tree
[15:55] <IntuitiveNipple> s/Monar/Molnar/
[15:55] <apw> the kernel is behaving as if 0074 -> 0.74
[15:56] <rtg> IntuitiveNipple: is there a repeatable test case that you know of?
[15:56] <sconklin> maria/join #ubuntu-meeting
[15:56] <cooloney> idVendor           0x1d6b Linux Foundation
[15:56] <cooloney>   idProduct          0x0002 2.0 root hub
[15:56] <cooloney>   bcdDevice            2.06
[15:57] <cooloney> 0x002 = 2.0
[15:57] <Keybuk> cooloney: right, and if you cat the usb device's bcdDevice
[15:57] <IntuitiveNipple> rtg: No - I was waiting for Stefan to produce some test kernels for the users reporting on the bug 
[15:57] <Keybuk> you'll see 0206 in there
[15:57] <Keybuk> 0206 -> 2.06
[15:57] <rtg> IntuitiveNipple: ok, I'll annoy smb_tp
[15:57] <IntuitiveNipple> rtg: :)
[15:58] <smb_tp> rtg, I am not listening
[15:58] <Keybuk> idVendor and idProduct are 32-bit words
[15:58] <BUGabundo> hi
[15:58] <Keybuk> idVendor assigned by a central naming authority
[15:58] <Keybuk> idProduct assigned by the vendor
[15:58] <rtg> smb_tp: take your hands off your ears, I can't hear you.
[15:58] <Keybuk> then for each product, you have a bcdDevice which supplies its version number
[15:58] <BUGabundo> 6 out of 10 resumes my laptop gets so slow that I'm required to reboot it
[15:58] <Keybuk> err 16-bit words
[15:58] <BUGabundo> how can I debug this?
[15:58] <smb_tp> rtg, Huh?
[15:59] <Keybuk> bcdDevice is 4 4-bit bcd numbers, representing the version number of the device
[15:59] <BUGabundo> I noticed that setting cpu to performance "fixes" this
[15:59] <rtg> smb_tp: kind of wrecks your mind, huh?
[15:59] <BUGabundo> but once I set it back to OnDemand slowness returns
[15:59] <cooloney> Keybuk, but we should firstly receive lsb until msb
[16:00] <Keybuk> cooloney: ?
[16:00] <smb_tp> rtg, Not _that_. But to answer, yeah aÍ wanted to do that, I'll write it down to remember as soon as I am finished with what I am doing right now
[16:00] <cooloney> Keybuk, first receiv 06 then 02 for 2.06 bcdDevice
[16:01] <rtg> smb_tp: k, just note that the window for Jaunty is closing.
[16:01] <Keybuk> cooloney: why?
[16:01] <BUGabundo> ok, you guy are busy... I'll come back latter
[16:02] <smb_tp> rtg, yeah, I hope I am done with that stupid thing in a little
[16:02] <cooloney> Keybuk, usb device should send out 06 firstly then 02
[16:06] <Keybuk> cooloney: err, why?
[16:08] <IntuitiveNipple> Spec 8.1 Byte-order is LSb
[16:08] <Keybuk> bcdDevice is not specified as a byte
[16:09] <Keybuk> the things specified as a byte are the ones beginning b, like bNumInterfaces
[16:09] <cooloney> Keybuk, you are right, i confused bcdDevice with some values like wLength
[16:09] <Keybuk> the entire bcd field is sent in reverse, yes
[16:09] <Keybuk> but as one unit
[16:09] <cooloney> right,
[16:11] <Keybuk> wLength is a word, so that entire word would be sent in reverse
[16:11] <Keybuk> not each individual byte
[16:11] <cooloney> exactly, cause i met a bug before which took me last of time
[16:11] <cooloney> right, for wLength we need so le16 helper function to get their value
[16:11] <cooloney> s/so/some
[16:11] <Keybuk> (I could be massively wrong, but I'm fairly sure I'm not :p)
[16:11] <cooloney> Keybuk, you're right on bcdDevice
[16:12] <IntuitiveNipple> all bits and fields are sent least-significant _bit_ first according to the spec
[16:12] <Keybuk> right, it's a serial bus ;)
[16:12] <IntuitiveNipple> multi-byte packets travel LSB wise
[16:13] <IntuitiveNipple> s/packets/fields/
[16:13] <Keybuk> LSB or LSb? :p
[16:14] <cooloney> 0x00, 0x02, /*  __le16 bcdUSB; v2.0 */
[16:14] <cooloney> we need set lower byte to 0x00 and higher one to 0x02
[16:14] <IntuitiveNipple> both... bits are LSb fields are LSB
[16:15] <cooloney> when we initialize a usb2_rh_dev_descriptor in drivers/usb/hcd.c
[16:15] <cooloney> right
[16:15] <cooloney> IntuitiveNipple, right
[16:16] <cooloney> wLength  = le16_to_cpu (cmd->wLength); 
[16:19] <cooloney> we need le16_to_cpu for word value,
[16:19] <cooloney> drivers/usb/core/hcd.c:	0x00, 0x02, /*  __le16 bcdUSB; v2.0 */
[16:19] <cooloney> drivers/usb/core/devices.c:	u16 bcdUSB = le16_to_cpu(desc->bcdUSB);
[16:22] <Keybuk> that could be the HCI bit
[16:22] <Keybuk> it all gets complicated ;)
[16:22] <Keybuk> bus sends it one way, the host in the computer turns that around and sets it another way, but then the CPU in the computer turns it around and sends it yet another
[16:24] <cooloney> i think we just need take care of those 16bits field in usb descriptor structures. 
[16:25] <cooloney> usb le16_to_cpu to help us out
[16:25] <cooloney> s/usb/use
[16:25] <Keybuk> depends where in the kernel you're looking
[16:26] <Keybuk> everything above the hcd uses CPU ordering, I think
[16:26] <Keybuk> so bcdDevice=0x0110 -> 1.10
[16:26] <Keybuk> might be wrong on that one
[16:27] <Keybuk> the hcd spec might end up needed that as Intel-CPU ordering (since Intel wrote it :p)
[16:28] <Keybuk> so that becomes 0x10, 0x01  (0001 0000, 0000 0001)
[16:28] <Keybuk> but then the bus spec says the entire field is LSB, so over the wire it's 0000 1000 1000 0000 I thijnk
[16:28] <Keybuk> feel free to go mad any point
[16:29] <cooloney> i guess so, 
[16:30] <cooloney> hcd is a driver which should take care of this order
[16:30] <Keybuk> (bearing in mind of course that on an Intel machine, bcdDevice=0x0110 ends up as 0x10, 0x01 in memory *but* 0x01, 0x10 in memory on something MSB)
[16:30] <cooloney> but the order from usb hardware controller should be fixed as spec said
[16:31] <Keybuk> the kernel doesn't talk to such a device
[16:31] <Keybuk> the kernel talks to the Host Controller
[16:31] <Keybuk> which is a different spec
[16:31] <Keybuk> the host controller does the wire stuff
[16:31] <cooloney> right, host controler is a hardware which take case of the data transfer
[16:31] <Keybuk> anyway, if there was an original question here, we've strayed a long way from an answer to it ;)
[16:32] <cooloney> but hcd is host controller driver which is a software driver in kernel to handle that data from hardware
[16:32] <cooloney> yes,
[16:32] <cooloney> but i do like to discuss something with you guys here 
[16:32] <Keybuk> no, the host controller is the pci device
[16:32] <Keybuk> the host controller driver talks to the host controller
[16:33] <Keybuk> the host controller talks to the hardware
[16:33] <cooloney> oh, pci stuff is in pc domain
[16:33] <cooloney> if in SOC like iMX51, the usb host controller is directly memory mapped
[16:34] <cooloney> hcd controls it directly.
[16:34] <Keybuk> sure, but they talk the hcd protocol, not the usb protocol
[16:34] <Keybuk> so you'd have to pick up the xhci, ehci, ohci or uhci spec and see what that says for data transfer ;)
[16:34] <Keybuk> if mucking around with the hcd driver
[16:35] <Keybuk> everything about the hcd driver, ie. when writing usb drivers, just do what the Linux kernel docs say
[16:35] <cooloney> right, 
[16:37] <cooloney> for imx51 or other soc, the usb host controller does not support ehci/ohci/uhci 
[16:37] <Keybuk> it doesn't?
[16:37] <cooloney> they use their own register layout and need a new driver
[16:37] <cooloney> drivers/usb/musb
[16:37] <cooloney> it is a usb driver for Davinci/omap/Blackfin
[16:37] <cooloney> mentor graphic ip
[16:37] <Keybuk> it at least vaguely pretends to be ehci
[16:38] <Keybuk> not that I can get my imx51 to boot today
[16:39] <cooloney> oh, imx51 does includes EHCI host and USB OTG from ARC
[16:39] <cooloney> the host mode driver in USB OTG should not be EHCI
[16:44] <Keybuk> oh yeah, I remember why I hate this thing
[16:44] <cooloney> usb is always my headache.
[16:44] <cooloney> -:))
[16:45] <cooloney> especially in embedded world
[16:47] <Keybuk> yeah, this has that silly fsl-ehci thing that's a platform device
[16:53] <cooloney> Keybuk, sorry, my mistake
[16:53] <cooloney> the USB OTG of imx51 also supports EHCI
[16:54] <cooloney> drivers/usb/host/ehci-arc.c
[16:54] <cooloney> drivers/usb/host/ehci-fsl.c is for the EHCI host
[19:21] <Turl> hi
[19:21] <Turl> can you suggest any other information for https://bugs.launchpad.net/bugs/348093 ?
[19:21] <ubot3> Malone bug 348093 in linux "Brightness keys ACPI events are not translated to keycodes" [Undecided,New] 
[19:22] <Turl> (and confirm & set priority maybe?)
[21:44] <sourcemaker> are there known problems with the 2.6.29 kernel?
[22:13] <Kano> hi rtg , could you fix at least the linux-headers package when you dont add my aufs fix?
[22:13] <Kano> there are some missing files
[22:14] <Kano> acpi/acpica/ dir is missing
[22:15] <Kano> there are 3 headers in it
[22:18] <Kano> well there are more, but fglrx needs 3
[22:18] <Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=tree;f=include/acpi;h=5ef3a2cd591223bf069be60037f2c576023752aa;hb=HEAD
[22:18] <Kano> this is not in the headers