[00:04] <Kano> hi, could somebody add the new r8169 firmware for .39?
=== jjohansen is now known as jj-afk
[00:07] <jj-afk> running errands back in a bit
[00:29] <ogasawara> slangasek: hi, I plan to do another kernel upload on this friday.  I suspect we'll have at least 1-2 more uploads past that up until kernel freeze on april 14th.
[00:29] <slangasek> ogasawara: ok, thanks - I'll pass that on to wookey who's working on linux-libc-dev
=== jj-afk is now known as jjohansen
=== _LibertyZero is now known as LibertyZero
[06:14] <skaet> JFo, ogasawara - interesting one from tonights scan through the beta bugs... https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/745947
[06:14] <ubot2> Launchpad bug 745947 in debian-installer "Fails to display video after grub (kernel lacks video output)" [High,New]
=== calc is now known as Guest79151
=== calc is now known as Guest76172
[08:46] <smb> cking, Good morning. Has the noise and dust ceased? :)
[08:48] <cking> smb, not quite - windows being fitted as we speak 
[08:49] <smb> cking, Oh no, you got Windows into the house! (quite lame I know)
[08:51] <cking> de da
[08:51] <cking> At least I don't need any service packs
[08:52] <smb> That is what you think now. :-P
=== skaet is now known as skaet_zzz
[09:08] <_ruben> unless you about painting and stuff yourslef, you'd need a service pack ;)
[09:09] <_ruben> (typing over a high latency connection sucks)
=== doko_ is now known as doko
[14:44] <tgardner> ugh! speaking of patch bombs. 2.6.35.12 has 275 patches.
=== skaet_zzz is now known as skaet
[15:22] <tgardner> ogra_, how is ti-omap4 going? did you get your image constructed with the new kernel?
[15:23] <ogra_> tgardner, yep, all fine, the beta is already being pre-published
[15:23] <ogra_> tgardner, thanks for the quick fix
[15:23] <tgardner> ogra_, did it solve many of the bugs that are outstanding? or do you know yet?
[15:24] <ogra_> well, the highest outstanding one is still the highmem issue, thats not solved, but it adds a proper HDMI driver again
[15:25] <ogra_> we are still waiting for userspace fixes for sound, kernel wise it should be fine though
[15:25] <ogra_> beyond that i think all hardware kind of works now with that kernel
[15:25] <tgardner> ogra_, ok. pgraner was just mentioning to me that there are a number of outstanding bugs that we should follow up on
[15:26] <ogra_> oh, i dont know which ones he refers to then
[15:26] <ogra_> do you have a list ?
[15:26] <ogra_> and is that natty or maverick =
[15:26] <ogra_> ?
[15:26] <tgardner> ogra_, he mentioned something about iso tracker.
[15:26] <tgardner> natty (AFAIK)
[15:29] <pgraner> ogra_, https://bugs.launchpad.net/bugs/746133
[15:29] <ubot2> Launchpad bug 746133 in linux-ti-omap4 "Video loses sync on omap4" [Undecided,New]
[15:29] <pgraner> https://bugs.launchpad.net/bugs/746137
[15:29] <ubot2> Launchpad bug 746137 in linux-ti-omap4 "Page allocation failure on omap4" [Undecided,New]
[15:30] <pgraner> https://bugs.launchpad.net/bugs/651302
[15:30] <ubot2> Launchpad bug 651302 in alsa-lib "No sound in omap (beagle, beagleXM)." [Low,New]
[15:30] <ogra_> 746133 ... heh, the .38 kernel uses the .35 driver now, so the bug was forward ported alongside i think
[15:30] <pgraner> ogra_, they were reported against beta1
[15:30] <ogra_> pgraner, trhe alsa-lib one is the bit i mentioned above, no kernel bits involved anymore
[15:31] <ogra_> we're waiting for alsa-lib and pulse fixes from TI for that
[15:49] <JFo> I iz back
[15:49] <JFo> skaet, that is an interesting bug
=== yofel_ is now known as yofel
[15:54]  * skaet glad Jfo finds it interesting....   and glad pgraners forward on the other interesting ones too.  :)
[15:55] <JFo> skaet, well, 'interesting' in a "I have no idea what to do with it." way ;-)
[16:01] <skaet> :)
[16:46] <tgardner> ogasawara, the archive has thawed. you could fire up a kernel today (just to keep the mirrors busy)
[16:47] <ogasawara> tgardner: cool, I'll get it goin
[16:48] <tgardner> ppisati, do you have the right HW to help debug natty ti-omap4 issues?
[16:51] <tgardner> GrueMaster, isn't there an ARM enablement team to which you ought to subscribe the omap4 bugs you're filing?
[16:51] <tgardner> ah, ubuntu armel porters
[16:51] <GrueMaster> tgardner: I usually do when I go through and triage.  I hardly ever triage when filing bugs during release testing.
[16:52] <tgardner> GrueMaster, thats a fine distinction that is lost on me
[16:52] <GrueMaster> Ubuntu-armel-porters is usually added to the subscribed list.
[16:53] <GrueMaster> Try testing 8 images on 2 different very slow platforms in one day and you will understand why I didn't add them
[16:54] <tgardner> ogra_, since you administer Ubuntu-armel-porters, how about adding Paolo Pisati and Bryan Wu ?
[16:54] <ogra_> i do ?
[16:54] <ogra_> hmm, sure, np
[16:54] <tgardner> ogra_, you are listed as an admin
[16:57]  * ogra_ wonders why cooloney isnt in that team 
[16:57]  * tgardner does as well
[16:57] <ogra_> not that it has any use though apart from bugmail subscriptions 
[16:57] <ogra_> added both
[16:57] <tgardner> I'm convinced that they don't get enough bug mail
[16:57] <ogra_> haha
[16:58] <ogra_> i could subscribe them to unity-2d, that generates about 50-100 per day
[16:58] <tgardner> ogra_, thats probably not necessary :)
[17:04] <tgardner> ogasawara, I'm also working on getting linux-backports-modules-2.6.38 NEWed
[17:05] <tgardner> I wonder if Clint can do that now?
[17:06] <ppisati> tgardner: yep, panda is ti-omap4
=== herton is now known as herton_lunch
[17:07] <tgardner> ppisati, I've gotten you subscribed to a couple of omap4 natty bugs
[17:07] <ppisati> tgardner: k
[17:07] <ppisati> GrueMaster: any tickets in particular?
[17:08] <tgardner> ppisati, bug #746137
[17:08] <ubot2> Launchpad bug 746137 in linux-ti-omap4 "Page allocation failure on omap4" [High,New] https://launchpad.net/bugs/746137
[17:08] <tgardner> bug #746133
[17:08] <ubot2> Launchpad bug 746133 in linux-ti-omap4 "Video loses sync on omap4" [Undecided,New] https://launchpad.net/bugs/746133
[17:14] <GrueMaster> tgardner: Those are the most recent bugs.
[17:15] <GrueMaster> I'll have to dig a little to see if there are others.  We just had this kernel dumped in last minute for release testing, so I haven't had a chance to do thorough testing yet.
[17:25] <ppisati> lp653002 and lp746133 look very similar
[17:34] <rsalveti> ppisati: it's probably the same one, but the newer happens with 38
[17:35] <rsalveti> and the new hdmi driver 
[17:35] <rsalveti> at that time we closed for natty because we were still using 35
[17:43] <ppisati> rsalveti: how to reproduce it? because with xperf -copywin i don't get the "omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX"
[17:44] <rsalveti> ppisati: from current discussion at linaro it seems to be related with pm
[17:44] <rsalveti> and cpu frequency scaling
[17:44] <rsalveti> ppisati: bug 732912
[17:44] <ubot2> Launchpad bug 732912 in linux-linaro-omap "omapdss DISPC error: GFX_FIFO_UNDERFLOW" [Undecided,Confirmed] https://launchpad.net/bugs/732912
[17:44] <rsalveti> also happens with omap 3
[17:49] <rsalveti> ppisati: interesting that you're unable to reproduce with xperf -copywin
[17:49] <rsalveti> that didn't happen even with 35
[17:50] <ppisati> rsalveti: FWIW i can't even do cpu scaling :)
[17:50] <ppisati> flag@flag-desktop:~$ uname -a
[17:50] <ppisati> Linux flag-desktop 2.6.38-1207-omap4 #10 SMP PREEMPT Thu Mar 31 18:12:49 CEST 2011 armv7l GNU/Linux
[17:50] <rsalveti> ppisati: yeah, just noticed it's not activated at our kernel
[17:50] <rsalveti> so the omap 3 bug is probably not related with this
=== herton_lunch is now known as herton
[17:50] <rsalveti> ppisati: were you able to hit this issue at least once?
[17:51] <rsalveti> I'm not, and I'm using my panda for days
[17:51] <ppisati> rsalveti: just booted this kernel
[17:52] <ppisati> rsalveti: tried with xcopywin but no blank
[17:52] <rsalveti> GrueMaster: what did you do to hit this bug?
[17:52] <ppisati> rsalveti: letf it there, idle, screensaver kicked in, but i can resume it
[17:52] <tgardner> ogasawara, Natty LBM is NEWed. do you suppose the dep-wait gizmo will work if you just upload LBM before the kernel headers are built?
[17:53] <GrueMaster> rsalveti: I was hitting it while filing a bug report on it.
[17:53] <ppisati> rsalveti: i'll leave it there a bit, let's see
[17:53] <ppisati> perhaps it's really connect to pm and cpu scaling
[17:53] <GrueMaster> Monitor directly plugged in.
[17:53] <ppisati> since we don't have it
[17:55] <ogasawara> tgardner: no idea
[17:55] <kamal> when might we expect the ubuntu-oneiric.git repo to be created?  (I can haz 2.6.39 now? ;-)
[17:55] <ogasawara> tgardner: I can give it a try though
[17:56] <tgardner> kamal, patience lad, she's working on it.
[17:56] <ogasawara> kamal: I'm half way through getting it created
[17:57] <tgardner> kamal, but I keep bugging her to do other stuff.
[17:57] <kamal> ogasawara: thanks very much :-)
[17:57] <kamal> tgardner: well quit it!
[17:57] <tgardner> kamal, can;t help it. I'm just naturally annoying.
[17:58] <ogasawara> wasted the better have of yesterday and this morning figuring out that some of the reverts didn't completely revert the original patch, but have that fixed up and am on track again now.
[17:58] <rsalveti> ppisati: but the omap 3 one is related with the ondemand governor 
[17:58] <rsalveti> and we're probably already using full speed
[17:58] <rsalveti> but something we should check, I'm not that sure
[18:01] <ogra_> rsalveti, heh, define full speed
[18:01] <ogra_> we wanted to push XM to 1GHz and i dont think we did 
[18:01] <rsalveti> ogra_: not xm, panda
[18:01] <ogra_> ah, you mentioned omap3 above
=== sforshee is now known as sforshee-lunch
[18:02] <ogra_> omap4 runs at full speed 
[18:02] <rsalveti> yeah, but was also talking about the omap 4 issue
[18:02] <rsalveti> that's something I'm not yet sure 
[18:02] <rsalveti> I mean, the cpu seems to be running at full speed
[18:02] <rsalveti> but don't know about the rest, like the bus that could affect the video
[18:03] <ogra_> ah
[18:04] <ogra_> yeah, that makes sense
[18:05] <ogasawara> tgardner: lbm uploaded, we'll see what happens
[18:07] <tgardner> ogasawara, indeed, I see 2.6.38.2 has a bunch of ath9k goodness, so I think I'll update compat-wireless for Lucid/Maverick.
[18:07] <tgardner> plus some mac80211 stuff
[18:07] <ogasawara> tgardner: cool, I was also going to strip natty lbm of the older cruft like compat-wireless-2.6.37 etc.
[18:07] <tgardner> ogasawara, ack
[18:12] <ogasawara> tgardner: hrmph, "Rejected:
[18:12] <ogasawara> The signer of this package is lacking the upload rights for the source package, component or package set in question."
[18:12] <tgardner> ogasawara, bummer. guess I can do it, or you can annoy cjwatson about it.
[18:13] <ogasawara> tgardner: I suspect it needs to be added to the right ACL's before I can pull the trigger, I'll ping cjwatson
[18:13] <tgardner> ogasawara, k, lemme know
[18:24] <ogasawara> tgardner: upload issue is fixed
[18:24] <tgardner> ogasawara, cool
[18:30] <slangasek> tgardner: hi, I just noticed that the change for bug #663090 has the effect of raising not only the hard limit for NOFILE, but also the soft limit, and the latter isn't wanted; for the moment the impact is minimal because pam has to shadow these defaults anyway so I can selectively fix up for purposes of user sessions, but how can we fix the kernel default too?
[18:30] <ubot2> Launchpad bug 663090 in linux "Please raise file descriptor hard limit to 4096 (but keep soft limit at 1024)" [Medium,Fix released] https://launchpad.net/bugs/663090
[18:30] <slangasek> technically this bug is not fixed because both hard and soft limits are now at 4096 :)
[18:30] <tgardner> slangasek, um, I though that was just the hard limit.
[18:30] <slangasek> tgardner: asm-generic/resource.h:
[18:30] <slangasek>         [RLIMIT_NOFILE]         = {       INR_OPEN,       INR_OPEN },   \
[18:31] <tgardner> oops.
[18:31] <tgardner> lemme look closer
[18:31] <slangasek> ok 
[18:34] <tgardner> slangasek, how are these numbers used in practice? In the kernel the limits really have no impact as far as initial memory allocation.
[18:34] <slangasek> tgardner: if your process is at the limit, you cannot open another fd
[18:34] <tgardner> I guess I'm wondering the difference between soft and hard
[18:34] <slangasek> the process itself can adjust the soft limit
[18:35] <slangasek> the hard limit is a hard limit that only root can adjust
[18:35] <slangasek> well, that only root can /raise/ - you can lower your own hard limit
[18:35] <slangasek> so we want these limits to be different because 1024 is a safe default for all processes, but some processes need to opt in to using more fds
[18:36] <slangasek> in this case the soft limit is a safeguard to protect processes from themselves when they don't know what to do with that many fds, rather than a resource limit
[18:37] <tgardner> slangasek, ok, makes sense. I suspect the 2 entries in that structure imply hard and soft limits. do you think the soft limit should be proportional to hard, e.g., INR_OPEN/2 ?
[18:38] <slangasek> I dimly recall that there are some old userspace paradigms that assume 1024 is the max number of fds they ever need to care about, so a hard-coded value of 1024 is probably best
[18:40] <slangasek> heh, when I say "I dimly recall", it's written in the first line of the bug description :)
[18:41] <tgardner> slangasek, ok, I'll fix it as soon as I can drill into the bizarre macro depths used to init this struct
[18:41] <tgardner> ok, found it
[18:45] <tgardner> ogasawara, so, I'm gonna squash 0ad40e118007ff770e2479f5afcdb9103782b4ba and the update to INR_OPEN into one patch so that we're not carrying 2 SAUCE patches for the same fix. you cool with that? you'll just have to remember the next time you rebase master-next.
[18:48] <bdmurray> I ran across bug 745511 and did a quick search of oops reports and found ~40 similar ones.  Would it help and be correct to consolidate them?
[18:48] <ubot2> Launchpad bug 745511 in linux "WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait 0x36f/0x3e0 radeon " [Undecided,New] https://launchpad.net/bugs/745511
=== sforshee-lunch is now known as sforshee
[18:54] <ogasawara> tgardner: cool, works for me
[18:55] <tgardner> ogasawara, k, just pushd +master-next
[18:58] <tgardner> must have food
=== tgardner is now known as tgardner-lunch
[19:08] <bjf> SURGEN GENERAL WARNING
[19:08] <bjf> The following reports can induce depression:
[19:08] <bjf>    http://people.canonical.com/~kernel/reports/regressions-update-report.html
[19:08] <bjf>    http://people.canonical.com/~kernel/reports/regressions-release-report.html
[19:08] <bjf>    http://people.canonical.com/~kernel/reports/regressions-potential-report.html
[19:08] <bjf> .
[19:08] <bjf> the last column "C" is time from last update the last comment was added
[19:08] <bjf> the age column is time from last update the bug was created
[19:08] <bjf> the date text in those columns is: days.hours.minutes   so 5.1.13  is 5 days, 1 hour, 13 minutes ago
[19:08] <bjf> note: if you hold down the shift you can sort using multiple columns
[19:09] <bjf> .
[19:09] <bjf> These are in addition to:
[19:09] <bjf>    http://people.canonical.com/~kernel/reports/sru-report.html
[19:09] <bjf>    http://people.canonical.com/~kernel/reports/versions.html
[19:11] <bdmurray> bjf: just an fyi I have a script that retags bugs tagged natty and regression-update to regression-release
[19:12] <bjf> bdmurray, good to know, right now i'm just trying to formulate my attack plan
[19:14] <bdmurray> bjf: I was thinking the apport hook could use an SRU removing regression-potential as an option for Maverick and earlier
[19:14] <bjf> bdmurray, agreed, we should not be creating any more of those
[19:15] <bdmurray> also I'm not really sure it makes sense to tag apport-package bugs a regression
=== shadeslayer_ is now known as shadeslayer
[20:07] <mdz> I just resumed from suspend, and it was very slow, lots of disk activity, and I noticed a whole bunch of kworker kernel threads running
[20:07] <mdz> any guesses what this means?
[20:11] <tgardner-lunch> mdz, natty? I was just reading an LKML discussion from Dave Jones complaining about something similar.
[20:11] <mdz> tgardner-lunch, yes, natty
[20:11] <mdz> tgardner-lunch, I saw a thread on lkml about worker threads with dave jones in it, but they were talking about them consuming a lot of CPU
[20:12] <mdz> mine are all idle, but there are 92 of them
[20:12] <mdz> hmm, looks like they've started to die, it's down to 10
[20:13] <mdz> dmesg is quiet, no indication of what they were doing
=== tgardner-lunch is now known as tgardner
[20:17] <tgardner> mdz, hard to say what was going on. how many worker threads? should only be one per hyper-thread.
[20:17] <tgardner> 92, nm
[20:17] <tgardner> I'm also thinking of kswapd
[20:18] <mdz> I seem to be using a lot of swap (1G)
[20:19] <tgardner> mdz, does slabtop show anything interesting?
[20:19] <mdz> tgardner, hmm, I've never used slabtop before. I wonder what's interesting
[20:20] <mdz> biggest thing is ext4_inode_cache at nearly 200M
[20:20] <tgardner> mdz, excessive consumption of memory indicating a possible application leak
[20:20] <mdz> http://paste.ubuntu.com/587937/
[20:21] <tgardner> mdz, mine is about 54M
[20:22] <tgardner> mdz, how about 'top' with meminfo
[20:23] <mdz> shutting down chromium freed 500M of the swap
[20:23] <tgardner> ah, kind of a hog
[20:23] <mdz> top (now) says:
[20:23] <mdz> Mem:   3065212k total,  1923540k used,  1141672k free,    55888k buffers
[20:24] <mdz> Swap:  2955924k total,   567932k used,  2387992k free,   695928k cached
[20:24] <mdz> wow, it actually freed 1G of memory too
[20:24] <tgardner> seems like it might have a leak
[20:24] <mdz> maybe time to give firefox 4 a chance
[20:24] <tgardner> mdz, how many tabs did you have open?
[20:25] <mdz> tgardner, maybe 25?
[20:25] <mdz> there were 31 chromium processes running
[20:25] <tgardner> mdz, it just seems like 92 kworker treads is a lot
[20:25] <tgardner> thread*
[20:26] <mdz> tgardner, could a memory shortage account for the kworker threads somehow
[20:26] <mdz> ?
[20:26] <tgardner> mdz, not the number of threads, just the activity under low mem pressure (I think)
[20:27] <tgardner> I'd think the number of threads is proportional to the number of tabs
[20:48] <mdz> tgardner, closing chromium didn't cause any kworkers to go away (once things were calmed down to 10 of them)
[20:49] <tgardner> mdz, confused. you said there were 92, now there are 10, right?
[20:50] <mdz> tgardner, shortly after resume, there were 92. after I came on here and started talking about it, I went back to count them, and there were only 10 running (I used scrollback to count the 92)
[20:50] <mdz> so most of them exited on their own apparently
[20:50] <tgardner> mdz, dunno, maybe chromium was firing up worker threads to refresh pages or something.
[22:42] <JFo> jjohansen, are you around?
[22:42] <jjohansen> JFo: yep
[22:42] <JFo> do you have a moment to take a look at a bug for me?
[22:42] <JFo> it is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/746751
[22:42] <ubot2> Launchpad bug 746751 in linux "kernel: [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 30)" [Critical,New]
[22:43] <JFo> hggdh just pinged me about it
[22:43] <jjohansen> ewww, just the discription is ugly
[22:43] <JFo> if not, it can wait until tomorrow
[22:43] <JFo> heh, yeah :-/
[22:44] <JFo> thought maybe you would have some insight on it, or at least more than I have :)
[22:45] <jjohansen> JFo: nothing off of the top of my head but it certainly looks to be a regression that we should be able to bisect
[22:46] <JFo> ok, thank you for looking. I'll see about getting more eyes on it tomorrow
[22:46] <JFo> well, I am off to grab some food... and perhaps a beer :)
[22:46] <jjohansen> JFo: I'll poke a little, but I expect it won't be too hard to track down
[22:47] <jjohansen> JFo: enjoy
[22:47] <JFo> cool, thanks jjohansen :)
[22:47] <JFo> I will try :-D
=== sconklin is now known as sconklin-gone