| ciberBOB | hey guys just need some link or recommendations for initiatives in the development of the Linux kernel and contribute something to the community | 02:33 |
|---|---|---|
| ciberBOB | not is channel for disscusion for kernel developer ? | 02:34 |
| * abogani waves | 08:57 | |
| abogani | smb_tp: Please remember to pull from my git tree to obtain PREEMPT_RT support update for Hardy. | 08:57 |
| smb_tp | abogani, I will do. :) Thanks for the reminder | 08:58 |
| abogani | smb_tp: Sorry to bother more and more. :-) | 08:58 |
| smb_tp | abogani, Hey, no problem. You had the work with it. | 08:59 |
| abogani | Are there some plan to change build system for kernel flavours (obviously generic/server excluded) ? Will it remain "out" (as did in Intrepid) or return to "in" (as did in hardy)? | 09:04 |
| abogani | Perhaps BenC know it ^^^ | 09:06 |
| smb_tp | abogani, I frankly don't know at the moment. Ben might know. Or amitk, did you catch discussions about that ^^^ | 09:13 |
| amitk | smb_tp: abogani: change build system for what again | 10:40 |
| amitk | ? | 10:40 |
| smb_tp | amitk, If I understood correctly the question was about -rt flavour | 10:41 |
| amitk | smb_tp: -rt flavour integrated into the Ubuntu kernel? | 10:42 |
| smb_tp | amitk, Into the build. But I think the intention was there to have a separate tree like lpia and ports. But I am not remembering well | 10:43 |
| apw | amitk, just was trying to edit the config lists in the a1 jaunty kernel and got the following error from armel | 11:22 |
| apw | About to configure armel config.iop32x | 11:22 |
| apw | make[1]: Entering directory `/home/apw/git2/ubuntu-jaunty' | 11:22 |
| apw | /home/apw/git2/ubuntu-jaunty/Makefile:449: /home/apw/git2/ubuntu-jaunty/arch/armel/Makefile: No such file or directory | 11:22 |
| apw | make[2]: *** No rule to make target `/home/apw/git2/ubuntu-jaunty/arch/armel/Makefile'. Stop. | 11:22 |
| apw | make[1]: *** [sub-make] Error 2 | 11:22 |
| apw | make[1]: Leaving directory `/home/apw/git2/ubuntu-jaunty' | 11:22 |
| apw | make: *** [editconfigs] Error 2 | 11:22 |
| amitk | apw: this is with 'debian/rules updateconfigs'? | 11:25 |
| apw | d/r editconfigs | 11:25 |
| amitk | apw: hmm.. not sure if editconfigs can work on a different arch | 11:28 |
| amitk | apw: I know why now... | 11:30 |
| amitk | it should work... patch coming up | 11:30 |
| apw | amitk, cool ... will give it a try | 11:35 |
| apw | (when it appears) | 11:35 |
| amitk | apw: pushed.. | 11:39 |
| apw | amitk, got it, seems to work just fine for me ... thanks | 11:45 |
| amitk | np | 11:46 |
| apw | better warn BenC that the jaunty tree has commits on top of it | 12:21 |
| amitk | BenC: ^ | 12:23 |
| BenC | apw, amitk: Got it, thanks | 12:40 |
| BenC | amitk: have you compiled the current tree on armel to make sure things are good? | 13:05 |
| amitk | BenC: another trivial change to getabis pushed. | 13:07 |
| amitk | BenC: I haven't. I can kickstart a build now. | 13:07 |
| BenC | amitk: thanks, I want to upload today and I just need to make sure armel will build | 13:25 |
| mkrufky | smb_tp: hello. I have some additional sms1xxx changesets that I merged into a separate branch. These changes depend on the ones pending from last week. Would you prefer that I generate a pull request against the last changeset in my last request, or should I just generate a whole new one with all pending changes altogether? | 14:06 |
| mkrufky | ...and yes, I have LP's created, etc... some of the LP's are private bugs for the Belmont project .... the fixes can go both to Belmont and Hardy | 14:07 |
| smb_tp | mkrufky, since I did not get to those yet, I would prefer one new one with everything together. | 14:08 |
| mkrufky | ok, i will send that right now | 14:08 |
| mkrufky | thanks in advance :-) | 14:08 |
| smb_tp | mkrufky, Ah, ok. Could you probably open dummy ones for the private bugs. I know it is a bit tedious but then the references to those can be publicly be followed | 14:09 |
| BenC | A list of modules that I had to disable in jaunty kernel has been sent to kernel-team@ if any gets that forward porting feeling | 14:09 |
| apw | smb_tp, just found and interesting work around for my dell studio 15 hang, which fits with your suspicion of cpu concurrency issues | 14:10 |
| mkrufky | smb_tp: I can just make the bug public -- there isnt actually any private info in there .... you should just ignore the pull request to mfrey INSIDE the bug report though | 14:10 |
| BenC | If you're not sure what that feeling feels like, it's a cross between a burning and slight tingling in the area of your brain where common sense takes place | 14:10 |
| apw | a script to disable all but one cpu for the suspend cycle sort it out | 14:10 |
| rtg | apw: https://bugs.launchpad.net/bugs/300159 | 14:12 |
| smb_tp | mkrufky, Hm, I should be able to ignore that. rtg what do you think of that? | 14:13 |
| apw | rtg that one looks 'fun' too, but i think the issue is actually: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/276943/ | 14:14 |
| mkrufky | i just say to ignore because my belmont pull requests are in separate branches against his git tree | 14:14 |
| rtg | smb_tp: if there is nothing proprietary in the bug, then just make it public. | 14:14 |
| mkrufky | i been using separate branches for belmont vs hardy mainstream, so that u guys can just pull / merge without any issue | 14:14 |
| mkrufky | yeah i will do that | 14:15 |
| rtg | apw: I just noticed that other folks have come up with the same work-wround. | 14:15 |
| smb_tp | mkrufky, Ok, great. Maybe you could refresh my memory with a mail to kernel-team if you are ready. ;-) | 14:15 |
| apw | its alll a bit frightening, stupid userland s/w accessing h/w, ouch | 14:15 |
| mkrufky | smb_tp: yes, will send that mail in a few minutes | 14:16 |
| smb_tp | mkrufky, Cool, thanks. :) | 14:16 |
| rtg | off-lining is actually a normal part of suspend, but its also almost the last thing that happens before calling ACPI to suspend. | 14:16 |
| apw | yeah the key seems to be not-onlining them again for 10s | 14:17 |
| apw | so that X has woken up and posted the h/w before they arrive | 14:17 |
| apw | if this suggested bodge patch is right it may be that we are loading irq handlers and not waiting for all cpu's to get with the program before dri interrupts start raining in ... its possible an rcu grace period wait in the dri driver would fix it | 14:18 |
| rtg | apw: sounds like it could be lieb's VT race. | 14:19 |
| apw | i thought the bug there was that the switch didn't occur correctly, in that overlapping vt switches could get lost | 14:19 |
| apw | this is definatly some kind of parallel hardware init problem | 14:19 |
| rtg | apw: I think it can manifest itself in a variety of ways. I assume you can reach your laptop over the network when its gets wedged on resume? | 14:21 |
| apw | nope, when it wedges its _hard_ gone | 14:22 |
| rtg | apw: well, then that isn't the VT lock. | 14:23 |
| apw | by suspending from a text console, i can resume correctly to there, and wait long enough for wireless to come back up | 14:23 |
| apw | then login from my 'tv' system, but when i switch to X she dies, and the cpu is pegged | 14:23 |
| apw | the network connection then times out | 14:24 |
| BenC | apw: even after waiting some time after resume? | 14:24 |
| apw | yeah ... its the switch back to X which takes the machine out | 14:24 |
| apw | and this workaround seems to demonstrate its lack of smp locking somewhere | 14:25 |
| BenC | apw: what xorg driver? | 14:25 |
| apw | the bug may well be in X dri drivers, or the real kernel dri drivers, its not clear | 14:25 |
| apw | intel xorg driver, i915 dri module | 14:25 |
| apw | other people are reporting it in other dri modules, so its likely a systemic failure across the family | 14:30 |
| mkrufky | email sent, smb_tp | 14:32 |
| smb_tp | mkrufky, ok. got it and put on todo list | 14:32 |
| mkrufky | thanks | 14:32 |
| apw | rtg this linux backports module (intrepid) seems to crap out if the directory above the build is dirty? is that reasonable? | 15:29 |
| rtg | apw: no, its not reasonable, but it happens. it doesn't match correctly if there are old .deb files from a [previous version. | 15:30 |
| apw | at least i am not going mad | 15:30 |
| rtg | I've fixed many of the packages. | 15:30 |
| rtg | apw: since I'm working on Intrepid LBM today, I'll get that fixed. | 15:31 |
| apw | sounds good, thanks | 15:31 |
| apw | its the imagelist=$(cat .... bit which seems to die | 15:31 |
| rtg | thats the one. | 15:32 |
| rtg | rm -f ../*.deb and it should be OK. | 15:32 |
| apw | yeah will do that for now, to confirm my lbm patch actually builds | 15:32 |
| rtg | apw: I'm about to do a complete update from upstream. | 15:33 |
| apw | of the wireless yes? | 15:33 |
| rtg | for wireless, are you adding some new driver? | 15:33 |
| apw | yeah we talked about it last week, its a backport of some nic driver | 15:33 |
| rtg | apw: I had a vague memory of that (which should be OK) | 15:34 |
| apw | as its put in there now it would be independant of your changes | 15:34 |
| rtg | r8169, right? | 15:34 |
| apw | just trying to confirm i did it right by building it which is challenging at best | 15:34 |
| apw | yeah thats the one | 15:34 |
| amitk | rtg: I think the intrepid kernel has the same problem, IIRC | 15:34 |
| amitk | rtg: imagelist one, I mean | 15:34 |
| rtg | not too surprising. | 15:35 |
| rtg | it goes back as far as dapper | 15:35 |
| apw | its taken me sometime to work out what i needed in my chroots to get it building, and then a while to build them | 15:35 |
| BenC | apw: in buildscripts git there is a shell script that will create schroot compatible tarballs for chroots, complete with all the build requirements for the kernel | 16:29 |
| BenC | apw: if you want to just complete your current chroot's, there's a listing of the extra packages needed in there as well | 16:30 |
| apw | nice | 16:31 |
| apw | thanks BenC | 16:31 |
| BenC | np | 16:38 |
| * BenC needs more coffee | 16:38 | |
| apw | the markets are up 9.2% ... hmmm | 16:38 |
| amitk | apw: for how long? | 17:03 |
| amitk | BenC: I got a build failure on ARM. will investigate now. Should I pull in cjwatson's patches as well? | 17:05 |
| BenC | amitk: I already pulled them and pushed | 17:05 |
| amitk | BenC: ok. I'll rebase and fix configs. | 17:06 |
| * amitk is going to setup cross-compilation now. Qemu builds are painful | 17:08 | |
| BenC | amitk: does qemu take advantage of multicore? | 17:10 |
| amitk | BenC: it does have a -smp option. I have it set to 3. It improves things a bit. | 17:12 |
| apw | amitk, heh they are closed, so at least until tommorrow morning | 17:14 |
| apw | amitk, are we going to have some kind of cross-compile porter? | 17:14 |
| amitk | apw: I'll post instructions to setup a cross-compile toolchain. And then we can ask IS to do it on a fast porter machine. Ideally I would like Ubuntu to provide a cross-compiler package so that it is automatic. | 17:18 |
| apw | that sound perfect | 17:18 |
| BenC | amitk: best bet is to talk to doko...debian used to (may still?) have a cross-compile toolchain package, so it might not be too hard to do | 17:23 |
| === mcasadevall is now known as NCommander | ||
| kirkland | smb_tp: ping, regarding https://bugs.edge.launchpad.net/ubuntu/+source/iscsitarget/+bug/278625 | 18:04 |
| kirkland | smb_tp: i merged a new iscsitarget package for jaunty, but this problem remains | 18:05 |
| kirkland | smb_tp: it seems that the kernel module code contained in the source of the new package fixes the "can't unload modules" problem | 18:05 |
| kirkland | smb_tp: is this module code something that can be merged into the kernel modules code? what's the rules/policy/process for doing so? can you help? | 18:06 |
| smb_tp | kirkland, yeah there was some proc (or sysfs) change | 18:06 |
| kirkland | smb_tp: cool, you're on top of it? | 18:06 |
| smb_tp | kirkland, I am not that familliar with why it isn't in the kernel. There was a guy involved who is the maintainer of the package. Maybe he is more up to it | 18:06 |
| kirkland | smb_tp: so what is in the kernel, iscsitarget wise? | 18:07 |
| kirkland | smb_tp: seems we ship an iscsci_trgt.ko | 18:07 |
| kirkland | smb_tp: is that from upstream? | 18:07 |
| kirkland | smb_tp: do they publish some additional code that's not upstream yet? (i don't get it) | 18:08 |
| smb_tp | kirkland, In Intrepid its in the kernel because lum went in there | 18:08 |
| smb_tp | kirkland, I think the kernel itself has nothing of it | 18:08 |
| kirkland | smb_tp: so lum includes module code that's not in the kernel.org kernel? | 18:08 |
| smb_tp | kirkland, yes | 18:08 |
| kirkland | smb_tp: cool, and what's the process for getting that code update? | 18:09 |
| kirkland | smb_tp: ie, could we import the "working" iscsi_tgrt code from this package? | 18:09 |
| smb_tp | kirkland, For Intrepid that is basically what I did. | 18:09 |
| smb_tp | kirkland, There is a BOM file with the location of the original download | 18:09 |
| smb_tp | kirkland, IIRC iscsitarget.sf.net | 18:10 |
| kirkland | smb_tp: cool, so will you be doing the same for Jaunty, at some point? | 18:10 |
| smb_tp | kirkland, since there is a bit stacking on my queue and my memory isn't sometime lacking it would be good to add a pointer via kernel-team mailing list ;-) | 18:12 |
| kirkland | smb_tp: okay, cool. what's that address, please? | 18:13 |
| rtg | kirkland: we'll have to for Jaunty since iscsitarget FTBS | 18:13 |
| kirkland | rtg: thanks | 18:13 |
| smb_tp | rtg, Are you on it | 18:13 |
| smb_tp | ? | 18:13 |
| kirkland | rtg: right now, package upgrades of iscsitarget will fail too, because it can't unload the modules on the initscript "stop" | 18:13 |
| rtg | yeah - we'll get there eventually. | 18:13 |
| smb_tp | kirkland, Oh just for general "reminders" kernel-team at lists.ubuntu.com :) | 18:16 |
| s0ullight | hi guys | 18:16 |
| BenC | just about to boot the jaunty kernel... | 18:24 |
| BenC | WARNING: I'm getting ready to do a force push | 18:26 |
| smb_tp | BenC, Did you pull the uvcvideo patch? | 18:30 |
| BenC | smb_tp: yeah, just did a pull to make sure I have everything | 18:31 |
| smb_tp | BenC, Cool. pfew :) | 18:31 |
| s0u[]ight | what kernel is this new release using atm? | 18:32 |
| NCommander | hey BenC | 18:33 |
| rtg | sconklin: did you get that? My nick isn't registered, so I never know if private chats work | 18:38 |
| BenC | NCommander: yo | 18:40 |
| NCommander | BenC, how goes 2.6.28? | 18:40 |
| sconklin | rtg: yeah, I got it | 18:41 |
| calc | BenC: i think you found a perpetual energy machine in your stove :-\ | 19:02 |
| rtg | smb_tp: speaking of iscsitarget, did you build test the Intrepid commit? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=8c09ecb39475e13bc86dc6df3c7fa787abc34aae | 19:13 |
| NCommander | calc, BenC's cooking can't be that bad | 19:14 |
| smb_tp | rtg, At least I always wanted it. I am not sure anymore... | 19:14 |
| rtg | huh? | 19:15 |
| smb_tp | rtg, I might suffer from too many nested interrupts. I thought I had test build it might be just an intention that got dropped | 19:18 |
| rtg | smb_tp: well, reverting it allows the compile to continue. I'll figure it out later this afternoon. | 19:19 |
| smb_tp | rtg, Hm, found some debs with a matching git with iscsitarget on ronne. | 19:19 |
| smb_tp | rtg, but that was 9.18... | 19:20 |
| rtg | smb_tp: probably some header that changed. | 19:20 |
| smb_tp | rtg, maybe. if you don't get to it maybe send me an email with the build log | 19:22 |
| rtg | smb_tp: don't sweat it. I'll get it figured out after lunch. | 19:23 |
| smb_tp | rtg, no worries. :) enjoy. | 19:23 |
| rtg | sconklin: you can work around that build failure by reverting the last commit to ubuntu/iscsitarget | 19:23 |
| smb_tp | rtg, I am off after one more mail | 19:23 |
| sconklin | rtg: ok, thanks. | 19:24 |
| lamont | how do I get kvm to _NOT_ stop doing stuff when I iconify the window? | 19:27 |
| lamont | because I'd like to set the machine to doing a task and then not have the window occupying realestate until I want to go look at it.... | 19:28 |
| amitk | cross compiling is sooo much more bearable... | 19:30 |
| amitk | rtg: I've fixed armel configs and all four flavours compile now. Pushed fixes to jaunty. Could you inform BenC when he gets back? | 20:51 |
| rtg | amitk: sure, I'll even do some test building. | 20:52 |
| amitk | rtg: thanks. Good night... | 20:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!