| === yofel_ is now known as yofel | ||
| === solarion is now known as Solarion | ||
| === michaelh1 is now known as michaelh1|away | ||
| === smb` is now known as smb | ||
| lool | apw: Hey there; for LP #732046 I had requested inclusion of nls_cp437 in the virtual kernel, but unfortunately it isn't enough and iso8859-1 is needed as well; I've confirmed that it is the only missing bit though; would you mind adding fs/nls/nls_iso8859-1.ko to debian.master/control.d/virtual.inclusion-list? | 10:13 |
|---|---|---|
| ubot2 | Launchpad bug 732046 in linux "Missing filesystem modules in -virtual package" [Undecided,Fix committed] https://launchpad.net/bugs/732046 | 10:13 |
| smb | lool, You won't be very successful in reaching apw today. They got a royal wedding going on over there and got the day off | 10:14 |
| smb | I will have a look | 10:14 |
| lool | ah right | 10:15 |
| lool | How could I forget about the royal wedding | 10:15 |
| smb | Still better than to forget you own one (or any anniversary of it) :) | 10:15 |
| lool | haha | 10:15 |
| lool | smb: The above likely affects oneiric, natty and maverick :-/ | 10:16 |
| lool | I'm testing natty at the moment | 10:16 |
| smb | lool, Ok, let me know any results, I'd start with Maverick patches | 10:17 |
| jjohansen | smb: at this rate we should just get rid of the inclusion list | 10:18 |
| smb | jjohansen, Well, I think it is still better than to include everything | 10:19 |
| jjohansen | smb: well until we slowly have every driver asked for anyways | 10:19 |
| jjohansen | smb: I almost think its should be an exclusion list | 10:19 |
| smb | I at least believe there was still enough of missing ones. | 10:20 |
| smb | Though its true that at least filesystems might be on a "could be needed" list in general | 10:21 |
| jjohansen | smb: yeah, I think a hybrid approach some parts inclusion, some parts exclusion would work better | 10:23 |
| smb | jjohansen, Do we have some place to externalize/save that though for UDS-O? | 10:24 |
| smb | thought I meant | 10:24 |
| jjohansen | hrmm, we could drop it in misc blueprint | 10:24 |
| smb | jjohansen, I really should look by now, would we have a session between us and the server-team discussing any feature / idea / needs they got for us? | 10:26 |
| jjohansen | smb: I don't think we do yet, though we should | 10:27 |
| jjohansen | smb: updated the misc blueprint | 10:27 |
| smb | Ok. Thanks. Hm, yeah. I check to open that server-kernel blueprint. Though before I try to find out whether something possibly exists. | 10:29 |
| jjohansen | smb: yeah lets ping the server team and see what they have first | 10:31 |
| lool | smb: Right, same issue on natty | 10:31 |
| smb | lool, ok, I check whether the same patch applies to both or whether I need slightly different ones | 10:32 |
| hallyn | I'd like to see commit 332ab16f830f59e7621ae8eb2c353dc135a316f6 (add refcounting for lower inodes for ecryptfs) go into natty-updates. Should I open a bug? | 14:20 |
| hallyn | or just beg and promise a beer at dublin sprint? | 14:21 |
| smb | hallyn, A bug is better (though nobody will turn down any beers) | 14:21 |
| hallyn | heh, maybe i'll do both | 14:22 |
| hallyn | ok i'll submit, thanks | 14:22 |
| smb | hallyn, If you got the report, a quick mail about patch and report to team-ml increases the chances of not being overlooked | 14:22 |
| hallyn | smb: thanks, will do | 14:23 |
| === dimmortal1 is now known as dimmortal | ||
| smb | jjohansen, Ok, so I just opened up https://blueprints.launchpad.net/ubuntu/+spec/other-kernel-o-server-requirements | 15:06 |
| jjohansen | smb: thanks | 15:07 |
| smb | hggdh, smoser Daviey ^ Idea would be to add any loose/open ends to the whiteboard. | 15:11 |
| === bjf[afk] is now known as bjf | ||
| hggdh | smb: roj | 15:12 |
| ppisati | ericm|ubuntu: ping | 15:15 |
| ericm|ubuntu | ppisati, pong | 15:15 |
| ppisati | ericm|ubuntu: hi Eric | 15:15 |
| ppisati | ericm|ubuntu: in the past, didn't you use jtag on the dove board? | 15:15 |
| ericm|ubuntu | ppisati, yep | 15:16 |
| ericm|ubuntu | ppisati, which you need their xdb thing | 15:16 |
| ppisati | ericm|ubuntu: cool, which hw/sw did you use? | 15:16 |
| ericm|ubuntu | ppisati, it's called XDB or Extreme blah blah blah, cannot remember exactly | 15:16 |
| ericm|ubuntu | ppisati, you have to ask Marvell for the software and a usable license | 15:16 |
| ericm|ubuntu | ppisati, it's commercial :-/ | 15:16 |
| ppisati | ericm|ubuntu: i've a flyswatter with ARM TI 14 and 20 pins interface | 15:17 |
| ppisati | ericm|ubuntu: uhm, i hoped someone tried openocd on it | 15:17 |
| ericm|ubuntu | ppisati, that possibly won't work - a DIY-ed wiggler? | 15:17 |
| ericm|ubuntu | ppisati, I had | 15:17 |
| ericm|ubuntu | ppisati, didn't work very well | 15:17 |
| ppisati | ericm|ubuntu: which profile did you test? | 15:17 |
| ericm|ubuntu | ppisati, couldn't stop the cpu | 15:18 |
| ericm|ubuntu | ppisati, I cannot remember | 15:18 |
| ppisati | ericm|ubuntu: ok, if suddenly you remeber it, please let me know | 15:18 |
| ericm|ubuntu | ppisati, there were 2 or 3 - all tried but failed | 15:18 |
| ppisati | ericm|ubuntu: ah ok | 15:18 |
| ericm|ubuntu | ppisati, the only way is to use their XDB, and even so - it didn't work very well | 15:18 |
| ppisati | ericm|ubuntu: no, it's ok | 15:19 |
| ppisati | ericm|ubuntu: i;m tracking down a bug on ARM v7 | 15:19 |
| ericm|ubuntu | ppisati, ok | 15:19 |
| ericm|ubuntu | ppisati, and it's dove related? | 15:19 |
| ericm|ubuntu | specific? | 15:19 |
| ppisati | ericm|ubuntu: and i can reproduce it on every kernel and hw platform we have (ti-omap3/4) | 15:19 |
| ppisati | ericm|ubuntu: in my opinion it's a stack corruption so i wanted to test how that code path worked on another arm platform | 15:19 |
| ppisati | ericm|ubuntu: to double check my findigs | 15:20 |
| ericm|ubuntu | ppisati, ah ok | 15:20 |
| ericm|ubuntu | ppisati, cool - good luck then :-) | 15:20 |
| ppisati | ericm|ubuntu: unfortuntely it's an asm routine that is first relocated before the new kernel is kexeced | 15:20 |
| ppisati | ericm|ubuntu: so plain printk won't help here | 15:20 |
| ppisati | that's it | 15:20 |
| ppisati | trying to narrow the window :) | 15:21 |
| ericm|ubuntu | ppisati, so it's kexec related? | 15:21 |
| ppisati | ericm|ubuntu: kexec | 15:21 |
| ppisati | yep | 15:21 |
| ericm|ubuntu | ppisati, I'm having trouble with kexec on this imx53 board as well | 15:21 |
| ppisati | arm v7? | 15:21 |
| ericm|ubuntu | ppisati, yet do not have time to look into that further | 15:21 |
| ericm|ubuntu | ppisati, it would be good if you could find something | 15:21 |
| ppisati | wait | 15:21 |
| ericm|ubuntu | ppisati, so kexec doesn't work on TI omap3/4? | 15:21 |
| ppisati | yep | 15:21 |
| ppisati | broken in every release since... | 15:22 |
| ericm|ubuntu | ppisati, there were some issues but I believe they were addressed | 15:22 |
| ppisati | lucid? but lucid was a tech showcase | 15:22 |
| ericm|ubuntu | ppisati, kexec should be ok on marvell dove | 15:22 |
| ppisati | ericm|ubuntu: yep, works well there | 15:22 |
| ericm|ubuntu | ppisati, we had it fixed years ago | 15:22 |
| ppisati | ericm|ubuntu: but IIRC it's v6 over there | 15:22 |
| ppisati | ericm|ubuntu: yeah yeah, that's why i'm tryiong to debug the code there | 15:22 |
| ericm|ubuntu | ppisati, not really sure if v7 was enabled | 15:23 |
| ericm|ubuntu | ppisati, there was an issue that L2 wasn't flushed before disabled | 15:23 |
| ericm|ubuntu | ppisati, so the memory content is corrupted for the 2nd kernel | 15:23 |
| ppisati | ericm|ubuntu: anyway, read here for omap 3/4: | 15:23 |
| ppisati | https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/768249 | 15:23 |
| ubot2 | Launchpad bug 768249 in linux-ti-omap4 "kexec panic: external abort on non-linefetch (0x1008) at 0x03510000" [Undecided,New] | 15:23 |
| ppisati | actually there are at least 2 bugs here | 15:24 |
| ericm|ubuntu | ppisati, I'm having exactly the same bug on this i.mx53 board | 15:24 |
| ppisati | first, when we are to juno to the relocation code, the memory location we end up is wrong | 15:24 |
| ppisati | second, if i force a jump to the correct location, it panics later | 15:24 |
| ppisati | i dind't dig into the second one, since first i would like to know what's wrong the machine_kexec() | 15:25 |
| ericm|ubuntu | ppisati, let me look into that bug | 15:25 |
| ericm|ubuntu | ppisati, interestingly enough - though I propose to flush L2 before kexec, the existing code doesn't seem to address this issue yet | 15:25 |
| ppisati | another thing that i didn't add to that bug report is that if i interleave a flush_cache_all() in the second part of machine kexec() (after 121 and before 124) | 15:26 |
| ppisati | the memory location where we jump is the correct one | 15:26 |
| ppisati | so, IMO there's something rotten in: | 15:26 |
| ericm|ubuntu | ppisati, so on my i.mx53 board, kexec was actually able to jump to the 0x70008000 which is the place where the 2nd kernel starts | 15:26 |
| ericm|ubuntu | and panic somewhere at 0x7000800c or so | 15:26 |
| ppisati | uhm | 15:26 |
| ppisati | and the relocation code is there, right? | 15:27 |
| ericm|ubuntu | ppisati, be aware that flush_cache_all() doesn't necessarily mean flush L2 | 15:27 |
| ericm|ubuntu | ppisati, what do you mean by relocation code? | 15:27 |
| ericm|ubuntu | ppisati, that small block of code who moves the kernel to the memory start? | 15:27 |
| ericm|ubuntu | before the real jump? | 15:27 |
| ppisati | in machine kexec() first we copy the routine arch/arm/kernel/relocate_kernel.S::relocate_new_kernel() to reboot_code_buffer | 15:28 |
| ericm|ubuntu | ppisati, that's one thing I have concern, not really sure if the relocation code did it right, I just need a debugger to examine the memory content | 15:28 |
| ppisati | then we jumop to that routine that it actually load/move the new kernel | 15:29 |
| ppisati | add a printk | 15:29 |
| ppisati | ah no | 15:29 |
| ericm|ubuntu | ppisati, that won't work | 15:29 |
| ppisati | you can't check the last part... | 15:29 |
| ppisati | right | 15:29 |
| ppisati | yes, you need a jtag too | 15:29 |
| ericm|ubuntu | ppisati, the only reliable way to check that is to use jtag | 15:29 |
| ericm|ubuntu | ppisati, exactly | 15:29 |
| ppisati | yep | 15:29 |
| ericm|ubuntu | ppisati, but I believe the issue has the same root cause as the omap one | 15:29 |
| ppisati | if it's arm v7, i think so | 15:30 |
| ppisati | now i just took a break from this bug beacseu i was wasting too much time on it | 15:30 |
| ppisati | but i'll be back shortly | 15:30 |
| ericm|ubuntu | ppisati, yeah - go outside and have some fresh air | 15:30 |
| ppisati | and having another arm target working (jtag-wise) would be a huge help | 15:30 |
| ericm|ubuntu | ppisati, does your omap come with a debugger/software? | 15:31 |
| ppisati | ericm|ubuntu: i'm applying CVEs, is it the same as a walk outside? :) | 15:31 |
| ppisati | ericm|ubuntu: nope, i have my own jtag stuff | 15:31 |
| ppisati | wait | 15:31 |
| ppisati | http://www.tincantools.com/product.php?productid=16134&cat=251&page=1 | 15:32 |
| ppisati | 50 bucks | 15:32 |
| ppisati | and then you can get cables/adapters for ARM and MIPS target | 15:32 |
| ppisati | and it's natively supported by openocd | 15:32 |
| ppisati | it's really nice | 15:32 |
| ppisati | if you compare it to a Lauterbach | 15:32 |
| ppisati | that costs thousands | 15:32 |
| ericm|ubuntu | ppisati, nice | 15:33 |
| === jjohansen is now known as jj-afk | ||
| herton | tgardner: something strange, there is a notification on bug 764758 that it got fixed on oneiric, but the patch is relevant for natty only | 16:01 |
| ubot2 | Launchpad bug 764758 in linux "Revert now uneeded "x86, hibernate: Initialize mmu_cr4_features during boot" on Natty" [Undecided,Fix committed] https://launchpad.net/bugs/764758 | 16:01 |
| herton | ah now I see, patch was wrongly applied on oneiric | 16:03 |
| herton | sorry, didn't noticed this earlier | 16:04 |
| herton | the revert is only for stable (natty) | 16:04 |
| tgardner | herton, it shold have both the patch and the revert, right? | 16:04 |
| defiantredpill | Does anyone know where i can find the list of patches in the ubuntu kernel? | 16:04 |
| tgardner | herton, nm, not the revert. | 16:04 |
| herton | tgardner: yep, the revert is because the troublesome commit was reverted on stable, but kept on 2.6.39-rc + the fix | 16:05 |
| tgardner | defiantredpill, git is your friend. You can start here: http://kernel.ubuntu.com/git | 16:06 |
| herton | so 2.6.39 needs the fix, while the fix is not needed anymore on 2.6.38.x series | 16:06 |
| tgardner | herton, so I think I hear you saying Oneiric is OK ? | 16:06 |
| defiantredpill | thx | 16:06 |
| herton | tgardner: yes, we shouldn't apply the revert on it | 16:06 |
| herton | just explaining better: a fix for another long standing bug was made and applied on 2.6.39, with cc stable, and was applied to 2.6.38.x too | 16:08 |
| herton | but this fix introduce the hibernate regression | 16:09 |
| herton | *introduced | 16:09 |
| herton | a fix was made to 2.6.39, but stable guys decided to revert the commit on 2.6.38.x | 16:09 |
| herton | so 2.6.38.x doesn't need the fix anymore (so the revert I posted) | 16:10 |
| herton | while we don't need to do anything for 2.6.39 | 16:10 |
| tgardner | herton, right, so I think we're OK. | 16:10 |
| herton | yes, but we shouldn't revert the fix on oneiric, so we need to revert the revert on it :) | 16:12 |
| tgardner | herton, how about if I just make it disappear? | 16:13 |
| * smb 's mind boggles | 16:13 | |
| smb | I know it is a rebase tree anyway | 16:13 |
| tgardner | This one, right: UBUNTU: SAUCE: Revert "x86, hibernate: Initialize mmu_cr4_features during boot" | 16:13 |
| tgardner | smb, shit disappears from master-next dev trees all the time | 16:14 |
| smb | tgardner, well as I understand herton it got pushed out in a oneiric upload but meh | 16:16 |
| herton_ | tgardner: yep, this one (in case the reply didn't went, connection dropped here) | 16:16 |
| tgardner | herton: its as if it never existed. | 16:17 |
| tgardner | you gotta love rebase :) | 16:17 |
| herton_ | tgardner: yeah, saw here now on a new fetch it's ok, thanks | 16:18 |
| === herton_ is now known as herton | ||
| smb | tgardner, bjf Updated the cve-tracker with a mass rename update from jdstrand. Before changing things, be sure to pull | 16:38 |
| bjf | smb, wonder if this will bust apw's report | 16:40 |
| smb | bjf, Hm, dunno. I probably write a note to him (and probably myself to remind him of the note on Tuesday) | 16:41 |
| bjf | smb, well know as soon as the report cron runs again, top of the hour i think | 16:42 |
| bjf | s/well/we'll/ | 16:42 |
| smb | Oh, wait maybe I get confused. Was that a report _for_ apw or one generated _by_ him? | 16:43 |
| smb | And what report exactly anyway... *sigh* | 16:44 |
| * smb looks longing towards the nice cool can of cider in the fridge... | 16:45 | |
| bjf | jcastro, there is a uds-o conflict on monday at 10 with "Improve Suspend and Hibernate Kernel Debug" and the "Kernel Monday Roundtable" one is "hardware" the other is "other" | 16:47 |
| bjf | jcastro, is there a "simple" way the summit system can figure out the conflict? | 16:48 |
| jcastro | bjf: yeah manually scheduled roundtables don't get resolved, you can just click edit and drag it out of that slot | 16:49 |
| jcastro | bjf: I check those a bunch so if it starts to do that I move them, but if you run into that you can just fix it | 16:49 |
| bjf | jcastro, i don't want to change the roundtable, i want to have the other session autoscheduled to another slot | 16:49 |
| jcastro | right | 16:50 |
| jcastro | I just moved it | 16:50 |
| jcastro | you're good | 16:50 |
| bjf | jcastro, thanks | 16:50 |
| bjf | jcastro, if there were a way to say that we were "required" to be at the roundtable, would that help? | 16:51 |
| bjf | jcastro, is there somewhere else besides this channel that you'd like me to bring these to your attention ? | 16:55 |
| jcastro | bjf: yeah but the thing is the required thing needs a blueprint, so all I do is kick out sessions for tracks that are running roundtables | 16:56 |
| jcastro | it ends up being less work | 16:56 |
| jcastro | bjf: how you're doing it is fine. | 16:56 |
| bjf | jcastro, ok, same issue with Tuesday 9:00 with the "Ubuntu support for Intel UEFI firmware" | 16:57 |
| JFo | <-lunch, bbiab | 17:03 |
| jcastro | bjf: fixed | 17:09 |
| bjf | jcastro, thanks | 17:09 |
| === jj-afk is now known as jjohansen | ||
| === JanC_ is now known as JanC | ||
| Kano | hi jjohansen , didnt you want to fix the 32 bit daily builds? | 17:49 |
| jjohansen | Kano: ah yes, sorry I haven't gotten to looking at those yet | 17:50 |
| Kano | the last 32 bit kernel is rc4... | 17:50 |
| Kano | also did somebody notice that dvb-c has a much worse signal with .39 compared to .38? | 17:51 |
| jjohansen | Kano: unlikely .39 hasn't been the focus for the last few weeks | 17:51 |
| Kano | well all my scripts work with .39 kernel. every nv/fglrx | 17:52 |
| === eagles0513875 is now known as zz_eagles0513875 | ||
| === allison_ is now known as wendar | ||
| kees | bjf: I'm confused about CVE-2011-1182. it's marked as "released" (without versions) and "ignored" (without a reason). what's up with that CVE? | 18:45 |
| ubot2 | kees: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1182) | 18:45 |
| bjf | kees, for Lucid, Maverick and Natty the patches have already been applied via stable upstream releases | 18:47 |
| kees | bjf: ah-ha, okay. I'll have to find out which -security version they appear in. | 18:47 |
| bjf | kees. for Hardy, let me go back and look | 18:48 |
| tgardner | kees, apw has been working on a script to match stable updates and CVE commits. | 18:48 |
| kees | bjf: for hardy, if the code isn't vulnerable, "not-affected" is fine. "ignored" implies it's vulnerable, but for some reason we're not patching it. | 18:48 |
| kees | tgardner: excellent! | 18:48 |
| bjf | kees, bug 772543 shows when the patches came in | 18:48 |
| ubot2 | Launchpad bug 772543 in linux-mvl-dove "CVE-2011-1182" [Undecided,In progress] https://launchpad.net/bugs/772543 | 18:48 |
| bjf | kees, that may have been the case that i tagged it incorrectly, but i need to go back and look again | 18:49 |
| kees | bjf: okay, I see the upstream/stable version notes. I'll have to figure out where those are with respect to our published -security versions, update the old USNs, etc. | 18:50 |
| bjf | kees, some of those are probably in -proposed right now | 18:50 |
| bjf | kees, so "released" may have too strong a term | 18:50 |
| kees | ah! in that case, it should be "pending" (since they're not released) | 18:50 |
| kees | yeah :) | 18:50 |
| kees | this way I can examine the "pending" CVEs when writing up the USN (in the case of the CVE not showing up in the changelog, etc) | 18:51 |
| kees | anyway, this is part of the grey area to discuss at UDS :) thanks! | 18:51 |
| kees | oh! also, I've just EOL'd karmic, so you might want to pull in our u-c-t tree to see those changes so you can ignore karmic from now on. :) | 18:52 |
| bjf | kees, ok, those signals didn't exist in hardy, so that should have been "not-affected" i'll fix that up | 18:52 |
| kees | bjf: perfecto, thanks! | 18:52 |
| * bjf -> lunch / errand | 18:58 | |
| === bjf is now known as bjf[afk] | ||
| * tgardner --> lunch | 18:59 | |
| === jjohansen is now known as jj-afk | ||
| * jj-afk -> lunch | 20:01 | |
| lool | smb: Just a note that I tested a rebuilt natty kernel with the iso8859-1 module added under a natty ec2 instance and it solved the problem | 20:34 |
| serge_ | two xfs snafus on natty in one day. I'm getting suspicious | 20:49 |
| === bjf[afk] is now known as bjf | ||
| cwilson_ | So I have a long running copy of a file that is just over 4TB from one internal drive to a firewire drive mounted on the same system, transfer speeds start out in the 20-30 MB/s range but then after 24 hours it drops down to 5-8MB/s and then after another day or so the transfer drops down again to around 50KB/s. The big difference I see process wise after the first drop is the kernel flush process for the target drive being in D state all the time a | 21:11 |
| cwilson_ | rsync process that I'm using for the copy being in 'S+' state. | 21:11 |
| ohsix | what filesystems are involved? | 21:12 |
| cwilson_ | At the begining of the process when the speeds are high I am seeing both the flush process in D state but also the rsync process in D state, could this be related to how the kernel is flushing the file out? | 21:12 |
| cwilson_ | I am reading from an XFS filesystem and writing to an XFS filesystem | 21:12 |
| ohsix | ah, i don't have anything to add; i've just seen something like that but highly exaggerated with ntfs-3g as a destination | 21:13 |
| cwilson_ | cool, thanks | 21:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!