[00:21] hi [00:22] 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] A port or a host controller? [00:23] 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] hub 1-0:1.0: unable to enumerate USB device on port 4 [00:24] this is the log, just and always the port 4 [00:25] with hal i can drop all the log to /dev/null? this is the first thing that pop-ups in my mind :) [00:26] no, the report is from the kernel module. [00:26] ok, and i suppose there is no parameter for the module [00:26] maybe try repairing or disconnecting the port? [00:27] so i can remove it physically, this is the way [00:27] 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] IntuitiveNipple, even if i recompile without log info for the kernel? [00:28] That's rather a drastic approach - what if something else happens and there's no reports? [00:29] a disaster, well thanks IntuitiveNipple [00:29] You could add a rule to syslog.conf [00:29] uhm [00:29] a filter on this warning [00:30] 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] this is what i means with "filter", well you make me find a reasonable solution, thanks again IntuitiveNipple [00:50] apw, you there? [01:03] He's probably fast asleep in bed this time of morning [01:12] uck... i need a rebuilt copy of the 2.6.25 mainline [01:13] the one that is on the ubuntu mainline section won't boot enough to help with generating a git disection. [01:14] i keep having 2.6.25 stall just after saying done on the section, Begin: Running /scripts/local-premount ... [01:16] You could use break=top to drop into the initrd and poke around [01:16] add that where? [01:17] kernel command line [01:17] ok [01:17] * dandel checks [01:17] 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] Or, use just "break" and it'll stop at top anyhow [01:18] You can break at other places; need to look in the /init script (in the initrd) to decide which ones to use) [01:19] it appears that it gets stuck mounting [01:20] 2.6.24 and 2.6.26 work, but 2.6.25 stalls out [01:20] 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] ? [01:21] It causes the shell to write out all commands it is about to execute [01:21] where do i put that exactly? [01:22] 2nd or later lines in /init, in the initrd. You'll need to extract and then repackage the initd image [01:22] ><; [01:23] I've got some documentation on how to do that as part of a laret article [01:23] http://tjworld.net/wiki/Linux/Ubuntu/NetbootPxeLiveCDMultipleReleases#ExtractInitrd [01:24] To extract the image see the section "Extract Initrd" and after changing the script, see "Rebuild Initrd" [01:24] ok... [01:26] ok. [01:27] add set -x just after... #!/bin/sh ? [01:27] Yes [01:29] * dandel boots to see what happens. [01:31] oops lol... forgot to add it to grub. [01:32] :p [01:32] did it spew the commands though? [01:33] i'll find out [01:35] it's not finding it ><; [01:38] which 'it' is not finding what 'it' ? [01:39] the custom initrt... found the issue tho [01:40] although, i wish i could flat out disable system beep on a lot of things [01:40] hmm [01:40] interesting [01:41] stops at the command... mount -w -t ntfs -o locale=en_US ( ya get the rest ) [01:42] it appears it's running the mount commands wrong [08:18] 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] maxb, hi, let me check [08:20] maxb, Yeah, sorry. Pushing in a sec [08:21] done [08:21] thanks :-) === smb_tp_ is now known as smb_tp [08:23] Hmm. my git is claiming there is no tag for this release? [08:25] maxb, Too early in the morning to do two steps... [08:25] heh [08:25] Now [08:25] I guess that answers my next question: the insertchanges/commit/tag isn't automated anywhere? [08:26] 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] So This time the tag was created, but I had to "push --tags" [08:28] Yeah, git's a bit mystical to me. I don't really understand when you do and don't need --tags [08:29] 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] Without tags it seems only to do the actual contents [08:31] 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] or I've not quite understood the algorithm, anyway [08:32] 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] 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] _ruben: Why not simply use a Makefile and call it once? [10:01] _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] 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] _ruben: man dkms [10:27] IntuitiveNipple, hey ... bug #331415 ... have you a current status on that one, its on our regressions list :) [10:27] Malone bug 331415 in linux "request_firmware() fails on resume from suspend" [Medium,Triaged] https://launchpad.net/bugs/331415 [10:28] apw: WIP it's a biggie. I'll update it later on [10:29] IntuitiveNipple, thanks ... be good to sync up on it before the meeting this evening [10:31] 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] apw: I think it can loose it's regression-potential since it's always been like that :) [10:36] apw: removed tag [10:37] IntuitiveNipple, thanks for that ... one less to worry about [10:37] yeah... I was combing the list yesterday, managed to find a few that moved closer to a resolution [11:02] hehe... Linus' 2.6.29 release mail got flagged as SPAM in gmail :) [11:04] apw: can you pull the levers on a new mainline build? [11:04] apw: or tell me how to [11:04] amitk, which one you missing. there is a build in progress right now, so its probabally the one you wanted [11:05] apw: 2.6.29 final? [11:05] i think i saw it doing a .27 and a .28 ... [11:05] ok will check when these finish [11:05] and i will get the thing running out of cron this week [11:05] the triggers are automatic in theory [11:07] amitk, yeah its just done 27.21, its on 28.9 and will do .29 next i believe [11:07] so in the next hour or so [11:07] cool, thanks apw [11:08] c [11:08] i have been monitoring the builds, and so hand triggering what is meant to be a cron job [11:08] so its a simple matter of shoving it in cron (or should be) [11:11] 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] apw: do you do a allmodconfig? [11:11] nope, they are built using our ubuntu configs [11:11] make oldconfig from those [11:11] we can override config options where neceessary [11:13] like for hardy we reenable some wireless stuff which is in lbm [11:14] ok [11:17] * Kamping_Kaiser gazes at the wall [12:42] apw: bug #322311 and bug #338316 marked as 'Won't Fix' for the two arm flavours [12:42] Malone bug 322311 in qcontrol "orion5x armel flavour should provide input-modules" [Undecided,New] https://launchpad.net/bugs/322311 [12:42] Malone bug 338316 in linux "Please add a MV78XX0 arm flavour" [Wishlist,Won't fix] https://launchpad.net/bugs/338316 [12:42] amitk, cool [12:44] apw, amitk: were there other bug fixes besides VFP for those flavours that we can remove? [12:46] i don't recall doing any [12:52] rtg: I mentioned ce65d39bbcfaa3c0150891122df79f5ab2db550d needed to be reverted [12:53] amitk: see 14b2f940288288774f74414a0902d578d29d9076 [12:54] amitk: oops, nm [12:56] hehe [12:56] amitk: ok, you're right. tehre were 2 VFP patches and I missed the second. [12:58] 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] rtg: mv78xx0 [12:59] 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] bradF, did you boot up with your own rootfs [13:54] bradF, amitk i also boot up my own kernel. [13:56] as bradF said, we need to download the kernel to 0x00100000 [13:57] that is the entry point of the kernel image [13:58] right [14:00] amitk, how about the kernel command line of your board? [14:00] i try to mount the rootfs with my own kernel [14:02] after replacing the kernel of ogra image with my own, the kernel cannot mount rootfs [14:04] root=/dev/sda2 [14:04] i use root on a usb stick [14:05] OK, i will try, thx [14:11] it is so weird [14:12] http://pastebin.ubuntu.com/136755/ [14:12] amitk, what kind filesystem are you using on the usb stick? [14:13] cooloney: ext2 [14:14] amitk: is ext3 built in? [14:15] rtg: yes, i think so [14:16] yes, it is [14:16] amitk: it even says so [14:16] rtg: what does? [14:17] rtg, yes, ext3 built in [14:18] amitk: No filesystem could mount root, tried: ext3 ext2 cramfs vfat msdos [14:18] aah, right [14:18] cooloney: do you have initramfs loaded? [14:18] amitk: noinitrd on the command line [14:18] amitk, currently no [14:19] RedBoot> fconfig [14:19] Run script at boot: true [14:19] Boot script: [14:19] .. clock 800 [14:19] .. fis load kernel [14:19] .. exec -c "console=ttymxc0,115200 console=tty1 root=/dev/sda2 rootdelay=10 ro noinitrd" [14:19] USB_STORAGE is built-in. Is your usb disk supported w/o modules? [14:20] and is the rootfs on /dev/sda2? [14:20] amitk, do you think i should add "fis load initramfs" [14:20] sorry, what is "w/o modules?" [14:20] yeah, shouldn't root be /dev/sda1 ? [14:21] cooloney: do you need any special modules besides usb-storage [14:21] OK, let me try it. [14:21] cooloney: can you append "rootwait" to your command line [14:22] anubhav, i will try it [14:25] amitk, rtg anubhav thanks, i found root is sda1 as ext3 on my usb stick [14:26] cooloney: makes sense to me [14:26] since this usb stick is from colleague freeflying [14:26] i did change it's content at all [14:26] amitk, should i build my own rootfs from scratch? [14:27] cooloney: you don't have to [14:27] i just need to boot the board to command line console over serial for development, i guess [14:27] right [14:27] cooloney: babbage? [14:27] rtg, yes [14:28] babbage early version [14:28] cooloney, amitk: does it work with SATA yet? I'cve got one, but the USB drive is _really_ slow. [14:29] rtg, i dont have sata on my side, just know SD and USB stick is ok [14:30] cooloney: looks like you build the kernel? Our Freescale port using the cross compiler tools? [14:31] rtg: it was native built [14:31] rtg, right, i cross compiler our jaunty kernel to zImage [14:31] rtg: but you can replace the kernel with a cross-compiled one [14:31] amitk: Sourcery G++ Lite 2008q3-72 [14:31] and downloaded the zImage to boot up now [14:32] rtg: yeah, good enough [14:32] amitk, i replaced the kernel from ogra image with my own kernel from cross-compiled one [14:32] 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] rtg: you mean the first time you've seen cross-compilation used for something other than build verification? [14:34] amitk: in this particular case, yes [14:35] 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] amitk: its certainly a much faster way to build, isn't it? [14:36] rtg: hell yeah! I'd go nuts doing this in Qemu or natively [14:36] the babbage was taking several hours per flavour [14:36] cooloney: haven't tested my own rootfs yet, just the kernel [14:37] rtg: it takes about 15-20 minutes on my rather old desktop machine for the babage kernel [14:37] amitk: :) I can beat that by 15 minutes. [14:38] amitk, rtg are you talking about cross-compiling babbage kernel on x86 machine? [14:38] rtg: showoff! [14:38] cooloney: yes [14:38] cooloney: dual quad core w/18GB RAM. [14:39] cooloney: that's how I am building my kernels [14:40] cooloney: rtg likes to brag :-) [14:40] rtg, really cool [14:40] bradF, lol [14:40] guys, let me test on my side [14:40] * rtg thinks bradf has computer envy. [14:40] cooloney: you were _not_ cross-compiling until now? [14:41] rtg feels sad for rtg [14:41] i always cross built [14:41] * bradF feels sad for rtg [14:41] but dont know the time [14:41] amitk: that was the whole point of this discussion, e.g., I noticed that he booted a cross compiled kernel. [14:41] hehe, let me collect the timing info [14:42] right... [14:43] amitk: what's the word on the 'securityfs' for AA? should I chase that? [14:44] amitk: just saw your email...will try it [14:45] is there still an AA upstream to send it to ? [14:45] 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] rtg: If there isn't, then what're we doing carrying around that patch and letting it bitrot? [14:46] amitk: Its a topic for UDS, but I'm thinking this is the last release with AA. [14:47] interesting [14:48] can i reproduce this bug on my side? [14:48] if bradF needs help, i can join in [14:48] cooloney: are you talking about the apparmor bug? [14:48] right [14:48] AA = apparmor, if i am not wrong? [14:48] cooloney: correct [14:49] it's easy to repro, just go into your config and change the CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE from 0 to 1 [14:49] cooloney: then if you don't have my patch, it will oops [14:50] 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] ok, booting oops? [14:50] cooloney: yes, booting oops, every time [14:51] great, i will try [14:59] rtg: yes on "can't find root" [15:00] cross-compiling imx51 deb package on my side nees 13m [15:00] bradF: so, we're just trading on oops for another? albeit a bit more understandable. [15:00] one* [15:00] 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] rtg: are you talking about the securityfs? [15:01] bradF: yes [15:01] 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] rtg: if AA truly needs securityfs, then it should be a autoselected dependency [15:02] rtg: the missing securityfs doesn't cause an oops, just that AA is not doing anything [15:03] bradF: ok, thats what I wanted to know. With the patch you can boot a rootfs, but without AA support, correct? [15:03] rtg: let me run a couple of tests, but yes that is what I believe [15:04] bradF: ok, when you're comfortable send me a pull request. [15:06] rtg: will do [15:07] amitk: i understand your point and depending on my testing my submit another patch [15:07] s/my/may/ [15:07] bradF: sure, take your time. [15:08] 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] Warning: file:///cdrom/pool/main/x/xkeyboard-config/xkb-data_1.5-2ubuntu9_all.deb was corrupt [15:09] (I burned another cd-r that works) Should I report this as a bug? [15:09] charlie-tca: this is best reported on #ubuntu-devel [15:09] Okay, thanks [15:11] amitk: the kernel I just booted with the securityfs enabled seems to be working! [15:11] interesting [15:12] so it _is_ a dependency [15:12] amitk: [42949373.670000] AppArmor: AppArmor Filesystem Enabled [15:12] amitk: yup [15:12] bradF: so I should expect some config changes along with the oops prevention? [15:14] rtg: they are independent of each other but the config change is necessary to run AA on imx51 (and all other flavours) [15:14] the oops prevention is moot if its a dependancy and so recorded in the config [15:15] bradF: this kernel is w/o your oops prevention patch? [15:15] amitk: it has both [15:15] amitk: however, it should work without my oops patch, will test [15:15] bradF: see if it works with just the config change [15:15] bradF: yeah, that would be interesting [15:16] apw: I see your point [15:16] it does sounds like an unrecorded interdependancy to me [15:18] though the oops prevention is what triggered the securityfs config light-bulb if I understood bradF correctly. [15:18] apw: it still seems like it should handle a missing securityfs a little better than an oops [15:18] amitk: yes [15:18] bradF, not if its a depanancy, it should just be linked in the Kconfig magic [15:19] and then become impossible to enable without the securityfs enabled === maco_ is now known as maco [15:29] bradF, is this boot oops? [15:29] [42949373.670000] AppArmor: Error creating AppArmor securityfs [15:29] [42949373.700000] AppArmor: AppArmor protection removed [15:30] cooloney: after that you should get am actual oops and a backtrace [15:30] bradF, right, i reproduce it [15:31] thx [15:31] cooloney: http://pastebin.ubuntu.com/136819/ [15:35] cooloney: it looks like you just need to enable the security fs and you don't need the patch I put out [15:36] bradF, thx, i can test your method on my side [15:43] cking, any idea waht a bcdDevice means in the context of usb? [15:43] apw: device id in binary coded decimal [15:44] USB is *all about* bcd [15:44] hrm, so something above and beyond its normal id's [15:44] idVendor 0x04ce ScanLogic Corp. [15:44] idProduct 0x0002 SL11R-IDE IDE Bridge [15:44] bcdDevice 0.78 [15:44] so that is a triplet in usb land? [15:45] i think so yea [15:45] 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] apw, IMO, it is right, [15:46] idVendor 0x05ac Apple, Inc. [15:46] idProduct 0x8242 [15:46] bcdDevice 0.16 [15:47] Keybuk, any idea what waht base the output is in [15:47] is it decimal, or hex or? [15:47] it is just a version number as Keybuk said [15:47] right but the output of the lsusb command what base is it in there [15:48] yes, lsusb will convert the binary code to such version number [15:48] apw: decimal [15:48] apw: binary coded decimal [15:48] it should be 0x1600 [15:49] right? [15:49] http://en.wikipedia.org/wiki/Binary-coded_decimal [15:49] hrm, i see, so its literally in hex in some sense [15:49] right you literally read the hex [15:49] 0110 is read is 1.10 [15:50] 0206 is 2.06 [15:50] etc. [15:50] ok, so yeah bcd is hex format but you arn't allowed to use some of the combos [15:50] thanks [15:50] * apw puts USB on his idiot idea list [15:51] IntuitiveNipple: I'm just looking at your RCU backport. Is that patch in response to smb_tp's RFC on boot pauses? [15:52] apw: USB is great! [15:52] it's ALL about the ids ;) [15:52] every gadget has a vendor and a product id [15:52] Keybuk, really, it should be 1.10 = 1001 [15:52] and a device version number [15:52] * apw slaps Keybuk ... get a grip man :) [15:53] and each device may have multiple configurations [15:53] 2.06 = 0602 [15:53] cooloney, that _all_ depends on your endiannes [15:53] rtg: Yes, it is backported from the upstream commit [15:53] depending on the configurations, you then have multiple interfaces [15:53] apw, for usb it should be lsb little endian [15:54] IntuitiveNipple: I got that part. I was wondering _why_ you did the backport. [15:54] and only then do you actually find out what the device *is* :p [15:54] cooloney: err, is it? [15:55] I'm pretty sure it's big endian [15:55] 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] s/Monar/Molnar/ [15:55] the kernel is behaving as if 0074 -> 0.74 [15:56] IntuitiveNipple: is there a repeatable test case that you know of? [15:56] maria/join #ubuntu-meeting [15:56] idVendor 0x1d6b Linux Foundation [15:56] idProduct 0x0002 2.0 root hub [15:56] bcdDevice 2.06 [15:57] 0x002 = 2.0 [15:57] cooloney: right, and if you cat the usb device's bcdDevice [15:57] rtg: No - I was waiting for Stefan to produce some test kernels for the users reporting on the bug [15:57] you'll see 0206 in there [15:57] 0206 -> 2.06 [15:57] IntuitiveNipple: ok, I'll annoy smb_tp [15:57] rtg: :) [15:58] rtg, I am not listening [15:58] idVendor and idProduct are 32-bit words [15:58] hi [15:58] idVendor assigned by a central naming authority [15:58] idProduct assigned by the vendor [15:58] smb_tp: take your hands off your ears, I can't hear you. [15:58] then for each product, you have a bcdDevice which supplies its version number [15:58] 6 out of 10 resumes my laptop gets so slow that I'm required to reboot it [15:58] err 16-bit words [15:58] how can I debug this? [15:58] rtg, Huh? [15:59] bcdDevice is 4 4-bit bcd numbers, representing the version number of the device [15:59] I noticed that setting cpu to performance "fixes" this [15:59] smb_tp: kind of wrecks your mind, huh? [15:59] but once I set it back to OnDemand slowness returns [15:59] Keybuk, but we should firstly receive lsb until msb [16:00] cooloney: ? [16:00] 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] Keybuk, first receiv 06 then 02 for 2.06 bcdDevice [16:01] smb_tp: k, just note that the window for Jaunty is closing. [16:01] cooloney: why? [16:01] ok, you guy are busy... I'll come back latter [16:02] rtg, yeah, I hope I am done with that stupid thing in a little [16:02] Keybuk, usb device should send out 06 firstly then 02 [16:06] cooloney: err, why? [16:08] Spec 8.1 Byte-order is LSb [16:08] bcdDevice is not specified as a byte [16:09] the things specified as a byte are the ones beginning b, like bNumInterfaces [16:09] Keybuk, you are right, i confused bcdDevice with some values like wLength [16:09] the entire bcd field is sent in reverse, yes [16:09] but as one unit [16:09] right, [16:11] wLength is a word, so that entire word would be sent in reverse [16:11] not each individual byte [16:11] exactly, cause i met a bug before which took me last of time [16:11] right, for wLength we need so le16 helper function to get their value [16:11] s/so/some [16:11] (I could be massively wrong, but I'm fairly sure I'm not :p) [16:11] Keybuk, you're right on bcdDevice [16:12] all bits and fields are sent least-significant _bit_ first according to the spec [16:12] right, it's a serial bus ;) [16:12] multi-byte packets travel LSB wise [16:13] s/packets/fields/ [16:13] LSB or LSb? :p [16:14] 0x00, 0x02, /* __le16 bcdUSB; v2.0 */ [16:14] we need set lower byte to 0x00 and higher one to 0x02 [16:14] both... bits are LSb fields are LSB [16:15] when we initialize a usb2_rh_dev_descriptor in drivers/usb/hcd.c [16:15] right [16:15] IntuitiveNipple, right [16:16] wLength = le16_to_cpu (cmd->wLength); [16:19] we need le16_to_cpu for word value, [16:19] drivers/usb/core/hcd.c: 0x00, 0x02, /* __le16 bcdUSB; v2.0 */ [16:19]