[10:13] <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:14] <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:15] <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:16] <lool> smb: The above likely affects oneiric, natty and maverick   :-/
[10:16] <lool> I'm testing natty at the moment
[10:17] <smb> lool, Ok, let me know any results, I'd start with Maverick patches
[10:18] <jjohansen> smb: at this rate we should just get rid of the inclusion list
[10:19] <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:20] <smb> I at least believe there was still enough of missing ones.
[10:21] <smb> Though its true that at least filesystems might be on a "could be needed" list in general
[10:23] <jjohansen> smb: yeah, I think a hybrid approach some parts inclusion, some parts exclusion would work better
[10:24] <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:26] <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:27] <jjohansen> smb: I don't think we do yet, though we should
[10:27] <jjohansen> smb: updated the misc blueprint
[10:29] <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:31] <jjohansen> smb: yeah lets ping the server team and see what they have first
[10:31] <lool> smb: Right, same issue on natty
[10:32] <smb> lool, ok, I check whether the same patch applies to both or whether I need slightly different ones
[14:20] <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:21] <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:22] <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:23] <hallyn> smb: thanks, will do
[15:06] <smb> jjohansen, Ok, so I just opened up https://blueprints.launchpad.net/ubuntu/+spec/other-kernel-o-server-requirements 
[15:07] <jjohansen> smb: thanks
[15:11] <smb> hggdh, smoser Daviey ^ Idea would be to add any loose/open ends to the whiteboard.
[15:12] <hggdh> smb: roj
[15:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <ericm|ubuntu> ppisati, nice
[16:01] <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:03] <herton> ah now I see, patch was wrongly applied on oneiric
[16:04] <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:05] <herton> tgardner: yep, the revert is because the troublesome commit was reverted on stable, but kept on 2.6.39-rc + the fix
[16:06] <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:08] <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:09] <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:10] <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:12] <herton> yes, but we shouldn't revert the fix on oneiric, so we need to revert the revert on it :)
[16:13] <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:14] <tgardner> smb, shit disappears from master-next dev trees all the time
[16:16] <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:17] <tgardner> herton: its as if it never existed.
[16:17] <tgardner> you gotta love rebase :)
[16:18] <herton_> tgardner: yeah, saw here now on a new fetch it's ok, thanks
[16:38] <smb> tgardner, bjf Updated the cve-tracker with a mass rename update from jdstrand. Before changing things, be sure to pull
[16:40] <bjf> smb, wonder if this will bust apw's report
[16:41] <smb> bjf, Hm, dunno. I probably write a note to him (and probably myself to remind him of the note on Tuesday)
[16:42] <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:43] <smb> Oh, wait maybe I get confused. Was that a report _for_ apw or one generated _by_ him?
[16:44] <smb> And what report exactly anyway... *sigh*
[16:45]  * smb looks longing towards the nice cool can of cider in the fridge...
[16:47] <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:48] <bjf> jcastro, is there a "simple" way the summit system can figure out the conflict?
[16:49] <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:50] <jcastro> right
[16:50] <jcastro> I just moved it
[16:50] <jcastro> you're good
[16:50] <bjf> jcastro, thanks
[16:51] <bjf> jcastro, if there were a way to say that we were "required" to be at the roundtable, would that help?
[16:55] <bjf> jcastro, is there somewhere else besides this channel that you'd like me to bring these to your attention ?
[16:56] <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:57] <bjf> jcastro, ok, same issue with Tuesday 9:00 with the "Ubuntu support for Intel UEFI firmware"
[17:03] <JFo> <-lunch, bbiab
[17:09] <jcastro> bjf: fixed
[17:09] <bjf> jcastro, thanks
[17:49] <Kano> hi jjohansen , didnt you want to fix the 32 bit daily builds?
[17:50] <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:51] <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:52] <Kano> well all my scripts work with .39 kernel. every nv/fglrx
[18:45] <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:47] <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:48] <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:49] <bjf> kees, that may have been the case that i tagged it incorrectly, but i need to go back and look again
[18:50] <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:51] <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:52] <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:58]  * bjf -> lunch / errand
[18:59]  * tgardner --> lunch
[20:01]  * jj-afk -> lunch
[20:34] <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:49] <serge_> two xfs snafus on natty in one day.  I'm getting suspicious
[21:11] <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:12] <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:13] <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