[00:00] JFo: not really, take a look at comment 19 [00:00] hmmm [00:00] ok, so we have apport data for Jaunty... [00:01] JFo: yup, so they've provided the requested info [00:01] excellent [00:01] JFo: the only thing it seems they did not do was test the latest upstream kernel [00:01] so this one needs to be sent upConfirmed for Jaunty, Test Upstream [00:01] JFo: right [00:01] excellent [00:01] sorry, I keep saying that [00:01] JFo: actually just a reminder to test upstream if they could [00:02] so, standard response from the bug jam page [00:02] JFo: since it was already asked if they could test upstream in comment 19 [00:02] right [00:02] yup [00:02] ok [00:03] JFo: we can actually remove the "needs-kernel-logs" tag since they ran the apport-collect command [00:03] ok [00:03] JFo: unfortunately removing the tag is a separate step from posting a comment and updating status [00:03] ah [00:03] ok [00:04] JFo: if you look at the bug description you'll see the list of "Tags" [00:04] I see them [00:04] JFo: click on the little yellow pencil icon at the end of the list [00:04] and the 'edit' icon :) [00:04] heh, right [00:05] just removing needs-kernel-logs, yes? [00:05] JFo: yup [00:05] ok [00:05] JFo: so one last thing, setting the Importance [00:05] ok [00:06] JFo: for the most part, bugs usually fall under the Medium Importance [00:06] I can't change that [00:06] ok [00:06] JFo: hrm, must be a bugcontrol thing. I'll change it [00:06] ok [00:06] yeah, permission related as the tool tip tells me [00:07] or hover text or what have you [00:07] :) [00:07] JFo: once you feel comfortable enough triaging bugs, you'll want to apply for membership to ubuntu-bugcontrol [00:07] ok [00:07] sounds good [00:07] JFo: it requires a small application process where you submit 5 bugs you triaged in order to prove you know what you're doing [00:08] JFo: ok, lets move to the next bug [00:08] JFo: bug 307780 [00:08] I'm with you [00:08] Malone bug 307780 in linux "Suspend/Hibernate Not Working" [Undecided,Incomplete] https://launchpad.net/bugs/307780 [00:09] JFo: this is another Incomplete bug, but you'll see they never responded to the last inquiry for information [00:09] so we need to ping them again? [00:09] JFo: actually, if they don't respond after 6weeks, I close them [00:09] ah [00:09] good call [00:10] so this one is well over that [00:10] JFo: I post a comment why we're closing it and let them know they are free to reopen the bug at any time [00:10] JFo: https://wiki.ubuntu.com/KernelTeam/BugDay/20090623#Old Incomplete [00:11] JFo: that's a typical stock reply that I'd use for that scenario [00:11] great [00:11] JFo: you probably can't set it to Won't Fix, so go ahead and set it to Invalid [00:11] so technically they don't get closed, they just get set to WontFix? [00:11] ok [00:12] JFo: Won't Fix, Invalid, and Fix Released are all considered closed states in launchpad [00:12] ok [00:12] but able to be reopened [00:12] I see [00:12] right [00:12] done [00:13] JFo: I think we're ready to tackle some of the bugs on the bug day list now [00:13] ok === bjf is now known as bjf_afk [00:14] JFo: I know we can look at the community sections, but lets steal some from Tim Gardner's list (he's away on vaca) [00:14] heh [00:14] I'm ready [00:14] JFo: bug 352484 [00:14] Malone bug 352484 in linux "Wireless network not working, System lock-ups with Intel 4965 wireless" [Undecided,New] https://launchpad.net/bugs/352484 [00:15] JFo: so as you read, the focus of the developer's list of bugs are wifi related bugs [00:15] I see that [00:16] JFo: for some drivers, like the iwl4965 driver, there are a few extra things they can test [00:16] k [00:16] so they have tried backports [00:16] do we need kernel logging for this too eventually? [00:16] or is this separate [00:17] JFo: we'll want to ask a bunch of things. even though they tested linux-backports-modules-intrepid, we need them to test the newer Jaunty release [00:17] ok [00:18] JFo: if the issue remains in Jaunty, they should also try linux-backports-modules-jaunty [00:18] right [00:18] JFo: then run apport-collect to get debug files [00:18] JFo: also, I usually like to request they also confirm against the latest upstream compat-wireless stack [00:18] k [00:18] makes sense [00:19] so, standard response from the bug jam page for backports [00:19] JFo: it's sorta a lot to ask the bug reporter, bug if you make it a simple multi-step process it's much easier [00:19] looks like [00:19] JFo: so we'll likely want to mix and match some of the stock replies [00:20] I see [00:20] JFo: basically combining the "Test Jaunty" and "Test linux-backports-modules-jaunty" stock replies [00:20] ok [00:21] JFo: whenever I ask someone to test the latest upstream compat-wireless stack I tag the bug "compat-wireless" [00:21] right [00:21] JFo: likewise if I ask them to run apport-collect, I tag "needs-kernel-logs" [00:21] makes sense [00:23] done.. very straightforward [00:23] see what you think [00:23] :) [00:24] all I did was add the backport stuff before the 'let us know' bit and added an 'Also,' [00:24] JFo: looks great. one small nit pick is when I paste the apport-collect command, I usually insert the actual bug # [00:24] ah [00:25] I didn't see that [00:25] <- slack [00:25] enabling them to copy/paste the command [00:25] JFo: no worries. it's usually not an issue until you run into the bug reporter that copies and pasts verbatim and complains apport-collect crashes [00:25] I should have seen that [00:25] heh [00:26] JFo: lemme see if I can find another good example under the Community section before I turn you loose to do a few on your own [00:26] heh, ok [00:28] lets look at bug 21344 [00:28] Malone bug 21344 in linux-source-2.6.22 "Hang when loading ipw2100" [Undecided,Won't fix] https://launchpad.net/bugs/21344 [00:28] wow 2005 [00:28] JFo: it's an oldie [00:29] JFo: so one thing I want to start preventing is Triaged bugs which stagnate [00:29] I can certainly understand that [00:29] JFo: as you pointed out, this was reported way back in 2005 and the most recent comment was back in Dec of 08 [00:30] I see that too :-/ [00:30] JFo: and that was from the janitor no less, so the last real comment was back in Sep 08 [00:30] yeah [00:30] do we need a 'Check for Jaunty' here? [00:30] JFo: Triaged to a developer should indicate a bug is up to date ready to be worked on [00:30] or is there something more [00:30] ah hah [00:30] ok [00:30] JFo: yup, so pretty much go through the same motions of asking the test against the latest release [00:30] but this is ooooold version [00:30] ok [00:31] cool [00:31] kick back to incomplete as well, yes? [00:31] JFo: yup [00:31] cool [00:31] JFo: so you'll notice a lot of triaging can be pretty redundant sometimes [00:32] yeah [00:32] but very necessary [00:32] JFo: there are some shortcuts, to make that easier :) [00:32] nice :) [00:32] JFo: first I'd point you to the launchpad greasemonkey scripts (noted in the bug day page) [00:32] scripts or built in LP tools? [00:32] ok [00:32] JFo: both [00:33] :) [00:33] JFo: I'd direct you specifically to the stockreplies gm-script as well as the karma suffix [00:33] ok [00:34] * JFo needs to unpack his Jaunty Lappy [00:34] the stockreplies will allow you to save canned responses, like test jaunty, test linux-backports-modules, and inject them automatically with a single click [00:34] oooh [00:34] I likey [00:34] the stockreplies gm-script is also capable of also setting the status and importance [00:34] very nice [00:35] JFo: I'm even lazier though and will often revert to using launchpadlib to knock out a whole list of bugs [00:35] hahahaha [00:35] I like that even more :) [00:35] JFo: but I'll save the launchpadlib stuff for a later date [00:35] ok [00:35] this is good ofr now [00:36] JFo: best to make you triage old school first [00:36] I need to understand first [00:36] yes :) [00:36] how often do you generate the list of bugs for the devs? [00:36] JFo: I generate them every 2 weeks [00:36] for instance, if I wanted to look over some of these this weekend... [00:37] ok good :) [00:37] JFo: but I'd be happy to generate some custom lists for you if you like [00:37] well, if it isn't too much trouble [00:37] I'd like to have a good list to tackle if you think I am up to it [00:38] JFo: definitely. let me put together a few groups of bugs for you to work on. I'll email you it tomorrow. [00:38] wonderful [00:38] I look forward to it [00:38] JFo: hope this quick triage session helped [00:38] immensely [00:38] JFo: obviously feel free to ping/email me with any additional questions [00:38] I'm glad to see that I will be able to help quicker than I thought [00:38] ok, will do [00:42] well, thank you for that excellent training ogasawara [00:42] I'll hold off for today on the bugs until I see the list tomorrow [00:43] JFo: sounds good. thanks for helping out [00:43] maybe I can help tackle some of the backlog [00:43] no problem at all :) [00:43] JFo: indeed, that would be great === fddfoo is now known as fdd [07:31] <\sh> how can we get rid of klibcs ipconfig inside the initramfs really fast...it's a nightmare in enterprise environments using PXE/NFS rootfs mounts === hito_jp0 is now known as hito_jp [10:17] What does 'mmc' stand for in /usr/src/linux-source-2.6.28/drivers/mmc/core/sd.c? [10:19] multimedia card [10:19] bullgard4, multi media controller? [10:19] (SD cards) [10:20] as far as I know its those controllers supporting multiple card types [10:20] yeah, or rather contrller :) [10:20] (damned i'm constantly using o's since a few days ... and cant find where they go) [10:21] ogra, o's? [10:23] overdose on style guide consumption? [10:25] ogra, smb Thank you for explaining. [10:28] is rfkill likely to be somewhat broken in 2.6.31 atm? [10:29] Ng, Assuming on the fact there has been a rewrite: maybe [10:30] it's just that i noticed that in 2.6.30 the gnome bluetooth thing showed two killswitch tickboxes for my thinkpad's internal bluetooth adapter which correctly disabled it, but they don't in 2.6.31 [10:31] there is a likelyhood of rfkill horkage yes [10:31] thought you should report it [10:38] ok [11:30] * apw notes that his machine is much happier under build loads with the latest karmic kernels [13:38] apw: I'd agree about the latest kernels and performance under I/O load [13:38] its been a revelation, i can no build a kernel in the background wihtout need for ionice [13:39] I've got two parallel builds going, with the UI much more responsive than before [13:39] shame my disk is still really slow, but it's definitely an improvement [13:40] i've not seen a single compix fade out since i've been running 31-* kernels, was normal before with heavy load [13:41] I thought I was seeing a little improvement with .31, but the -2.16 seems to be a lot better again === akgraner__ is now known as akgraner === bjf_afk is now known as bjf [15:45] smb, whatever happened to your mmc patch? [15:45] Pierre thinks there might be a better solution and wanted to investigate that [15:46] any sign of the better soln? [15:46] But I have not heard of something better [15:46] No [15:47] maybe worth a poke as we are carrying your patch [15:47] You certainly can change the block layer to carry additional references [15:47] I did poke (not sure how long ago) to get the answer above [15:48] ok good enough then [15:48] the worry is if its a differnt soln. we may get it without a collission with yours and carry both [15:49] apw, Found it, the answer is from first of Jul [15:49] so pretty recent then [15:49] right. His answer was "I plan to have a closer look at this first. I believe your solution is [15:49] a workaround and doesn't solve the real issue. As such, I want to have [15:49] one more go at finding and fixing the real problem before committing [15:49] this. Your analysis should help a lot in that effort. [15:49] " [16:25] cking_, i am pushing your first bisect kernel now, should be about 15 mins [16:26] cheers! [16:31] cking_, http://people.ubuntu.com/~apw/cpu-bisect/ [16:57] apw.. nearly tested [16:57] nearly? [16:57] yeah.. double checking to be sure [16:57] positive or negative? [16:58] I will let ya know in a jiffy [17:00] first time the hibernate screwed up [17:04] hrm and 2nd time around hibernate gets loads of I/O errors... [17:04] bah so hibernate may not work at all [17:05] looks hosed to me [17:05] will make a bisect tricky [17:06] let ,me do one more test [17:07] is it an amd? [17:18] Nope, Intel [17:21] * cking_ wastes time fsck'ing disc after screwed up hibernate :-( [17:23] this is annoying. some times it works, some times it does not. [17:25] makes testing more time consuming. [17:27] * smb can't stand the tension any longer and leaves for a happy place... [17:28] have a nice beer time smb [17:28] cking_, ta :) === cking_ is now known as cking [17:30] cking, any luck? [17:30] cking, what is a sonoma processor? we have an old patch for them in your name [17:31] * cking tries to recollect [17:31] what's the commit id? [17:32] some kind of pentium M I believe [17:34] 2nd gen Centrino [17:34] apw, http://en.wikipedia.org/wiki/Centrino#Sonoma_platform_.282005.29 [17:35] odd we are carrying a patch for it [17:35] why odd? [17:37] Is this for cpufreq-centrino? [17:38] cpufreq/speedstep-centrino.c [17:39] Yeah [17:39] The issue there was that the different Sonoma models need different frequency/voltage tables [17:39] So you have to get the information from ACPI, but some machines were missing it [17:39] You could patch it to add one table, but there was no way to know which you should use [17:46] The freq/voltage tables can be selected from from the cpu id info, and max cpu setting. [17:46] it's not pleasant, put it that way. [17:48] s/max cpu/max freq/ [17:49] * cking suspect apw is working his way through a gazillion patches [17:50] cking, its odd cause we are still carrying it so long after [17:50] and yeah a lot of reading [18:01] hrmph. phase of the moon bug this one. [18:02] 2.26.27*18 FAIL, OK, OK [18:03] 2.6.27*10 OK, OK [18:03] 2.6.27*14, FAIL, OK, OK [18:03] 2.6.27*12, OK, OK [18:04] apw, ^^ it's not easy to reproduce 100% of the time. [18:04] gonna take a break, neck is killing me. [18:04] cking, hrmmm ... bottom [18:05] Gonna revist this again later when it's cooler and my neck is under some pain killers [18:07] cking, it'll wait [23:18] hi ogasawara [23:18] JFo: hiya, just getting your list of bugs I promised put together [23:18] excellent :)