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