=== hugh__ is now known as Guest91770
[02:32] <StFS> Hi. I filed a bug because the headphone jack on my dock doesn't work and I'm told that some line has to be added to a "quirk table". I found a line for a T430s in sound/pci/hda/patch_realtek.c and I want to add one for my model (the T430).
[02:33] <StFS> the line I found is: SND_PCI_QUIRK(0x17aa, 0x21fb, "Thinkpad T430s", ALC269_FIXUP_LENOVO_DOCK)
[02:33] <StFS> so my question is basically, how do I figure out what the values should be for my computer/dock?
[02:33] <StFS> the bug I filed is here (it has more hw info): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1060372
[02:33] <ubot2> Launchpad bug 1060372 in linux "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,Confirmed]
=== smb` is now known as smb
=== yofel_ is now known as yofel
[08:08]  * cwillu_at_work looks at smb suspiciously
[08:08] <cwillu_at_work> smb, recall anything about [PATCH] sched: Fix race in task_group()?
[08:08]  * smb hasn't done nuthing anywhere
[08:09] <cwillu_at_work> well, lkml says you reported the bug it fixed :p
[08:09]  * smb remembers vaguely... more than two days ago...
[08:09] <smb> ;)
[08:10] <cwillu_at_work> as it happens, bisect blames that patch for my server not booting anymore :p
[08:10] <smb> I believe lkml says it was Peter who fixed it. Me merely was anyoing him enough
[08:10] <cwillu_at_work> is he on irc?  I wish to annoy him too! :p
[08:11] <smb> Nah, not here... an I wonder whether that bisect is really true...
[08:11] <cwillu_at_work> I'm pretty confident
[08:11] <cwillu_at_work> I was already suspicious of that patch before I started
[08:12] <cwillu_at_work> it's one of 16 patches that 3.6-rc1 and 3.5.5 have in common
[08:12] <cwillu_at_work> and those are the two kernel versions that stopped booting
[08:12] <smb> Would "noautogroup" change something there?
[08:13] <cwillu_at_work> https://lh5.googleusercontent.com/-0DY-YYhgvzs/UHdB-BQdzMI/AAAAAAAAAEg/QhY9rgxnv98/s811/2012-10-11  <- crash in question
[08:13] <cwillu_at_work> which, on the kernel cmdline?
[08:13] <smb> yep
[08:13] <cwillu_at_work> give me a minute to try
[08:16] <cwillu_at_work> smb, yep, it boots with noautogroup
[08:18] <smb> cwillu_at_work, Ok, I might have to admit it is related. :-P Wonder what on your server is so different that it happens while on none of those I use it does...
[08:18] <cwillu_at_work> well, it's probably older than most things you're testing
[08:18] <cwillu_at_work> it's a lucid box
[08:20] <smb> That maybe, but this is in a very central place in the kernel, used not only on server and I would not think any netbooks especially powerfull... 
[08:22] <smb> Hm, anyway, you should make it fail with a current kernel (for which there are still ddebs I could pull) and create a bug report with the trace, kernel version and bisection result in it
[08:23] <cwillu_at_work> the trace is rather hard to get too
[08:23] <cwillu_at_work> to
[08:23] <smb> So it is not always showing up?
[08:24] <smb> Or just scrolling off
[08:24] <cwillu_at_work> scrolling off, early'ish in boot
[08:24] <cwillu_at_work> I haven't had any luck getting netconsole to work, but that may just be me mistyping an address
[08:25] <smb> Hm, there was also some option to make earlyprintk crawl...
[08:26] <smb> or maybe pause_on_oops=<seconds>
[08:28] <cwillu_at_work> well, the trick is more getting something better than a photo, no? ;p
[08:28] <smb> ah here boot_delay=<milliseconds> (but below 10000)
[08:28] <cwillu_at_work> I can get a photo every time
[08:28] <smb> As long as the photo is not so blurry that my eyes and brain hurts it is ok
[08:28] <smb> yours is not bad
[08:29] <cwillu_at_work> well, was the above so blurry that your... k :)
[08:29]  * smb has seen much worse
[08:30] <smb> And that one at least has most of the top of the message which is also sometimes a problem
[08:30] <cwillu_at_work> yeah, if I leave it for more than 2 seconds, a whole whack of other oopsen show up
[08:30] <cwillu_at_work> short enough that autofocus becomes a problem :p
[08:30] <smb> Heh, yeah
[08:31] <cwillu_at_work> pause_on_oops sounds useful there though
[08:31] <cwillu_at_work> suspect I'll make that a local default
[08:37] <smb> Hm, on a quick glance at the code the most likely cause would be that p->sched_task_group has not been set when set_task_rq() tries to access things from it...
[08:39] <smb> but that should be at least set to &root_task_group...
[08:41] <smb> cwillu_at_work, Just to be sure, this happens on that machine also with the default/stock ubuntu kernels (to rule out any slightly different configuration)
[08:41] <cwillu_at_work> smb, lucid remember :p
[08:41] <cwillu_at_work> the kernels on the mainline page don't install from 3.6 onward
[08:41] <smb> and a 3.6 kernel in the crash ;)
[08:42] <cwillu_at_work> (complaints about libc)
[08:42] <cwillu_at_work> smb, btrfs on anything but the latest kernel is suicidal
[08:42] <cwillu_at_work> (I have extensive backups, etc)
[08:43] <cwillu_at_work> but the kernel config is just a make oldnoconfig after cp'ing the existing stock config from /boot to .config
=== henrix_ is now known as henrix
[08:44] <cwillu_at_work> smb, I'm not looking for support, I'm just looking for the right body to poke to get it fixed in mainline :p
[08:45] <cwillu_at_work> although the noautogroup suggestion was useful, and allows me to get actual btrfs testing work done in the mean time, for which I'm grateful :)
[08:46] <smb> cwillu_at_work, Still that does not answer the question: Have you seen the crash with for example the mainline kernel we build? 
[08:46] <cwillu_at_work> you don't build a 3.6 mainline kernel that will install on lucid
[08:46] <smb> ?
[08:46] <smb> Have you tried?
[08:47] <cwillu_at_work> sec, I'll get the exact error, but yeah, I've tried
[08:47] <cwillu_at_work> if memory serves, it's a libc version bump from quantal that it doesn't like
[08:48] <smb> hm, ok... that in some way sounds familiar
[08:49] <cwillu_at_work> (just waiting for linux-image-3.6.2-030602-generic_3.6.2-030602.201210121823_amd64.deb and company to download
[08:50] <cwillu_at_work> I don't blame you for making me check of course; rule #1 in #btrfs is "The user lies" ;p
[08:52] <smb> cwillu_at_work, Btw, don't know whether you know, you could checkout upstream kernels and then take the patches from the mainline page of the same version and then locally build with the exact same config
[08:52] <smb> cwillu_at_work, Well, not only btrfs ;-P But even without that there is enough space for misunderstandings
[08:53]  * xnox seriously considers to turn off his btrfs highlight =))) too much chatting going on ;-)
[08:53] <cwillu_at_work> only reason I'm asking in this particular channel is that I recognized your name on the commits :p
[08:53] <smb> And I want to make sure we don't have a case where for some reason there is a slightly different configuration which nobody was considering
[08:54] <smb> Well yeah, unfortunately the state before is as broken... which I had to fight with
[08:55] <cwillu_at_work> linux-headers-3.6.2-030602-generic depends on libc6 (>= 2.14); however:
[08:55] <cwillu_at_work>   Version of libc6 on system is 2.11.1-0ubuntu7.10.
[08:55] <cwillu_at_work> that's actually just the headers package though
[08:55]  * cwillu_at_work reboots to test
[08:57] <cwillu_at_work> and boom
[08:57] <smb> ok, so that is at least out of the way
[08:57] <cwillu_at_work> smb, image from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6.2-quantal/ blew up in the usual way
[08:58] <smb> Now I hope I did not screw the backport...
[08:59] <cwillu_at_work> there's a 3.6 backport for lucid?
[09:00] <smb> nah, but I did make upstream backports, though 3.6 should have it from upstream *pfew)
[09:01] <smb> yeah 3.6-rc3 had it...
[09:01] <cwillu_at_work> rc1 had it
[09:01] <cwillu_at_work> and 3.5.5 had it
[09:01] <cwillu_at_work> there's only 16 patches in common between those :)
[09:02] <smb> 3.5 could even be the variant from upstream, the problem was that files were shuffled around a lot early in 3.5
[09:06] <cwillu_at_work> when I say "3.5.5 had it", I mean "the git tag v3.5.5 from upstream's -stable repo"
[09:09] <smb> I had assumed that. The patch itself was not marked stable but I submitted it at least for 3.2/3.0 (I think). Then Greg decided it should be in 3.5, too. It was ok, just not as urgent.
[09:09] <cwillu_at_work> ah, okay
[09:10] <cwillu_at_work> yeah, I haven't run a 3.2 or 3.0 kernel in a while
[09:10] <cwillu_at_work> I also haven't needed to restore from backups in a while?
[09:10] <cwillu_at_work> this is not a coincidence :)
[09:11] <smb> Yeah, yeah, barfs (<- cking ;))
[09:11] <cking> smb, don't blame me, blame the spelling checker ;-)
[10:02] <psivaa> apw: good morning and i've just added the dmesg of a failed boot with --verbose added that slangasek asked for in bug 1066883
[10:02] <ubot2> Launchpad bug 1066883 in linux "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
[10:10] <henrix> smb: i was reading the irc logs and i was wondering whether the bug referred by cwillu_at_work could be bug #1055222
[10:10] <ubot2> Launchpad bug 1055222 in linux "Kernel panic on reboot after sched_autogroup_enabled disabled" [Undecided,Confirmed] https://launchpad.net/bugs/1055222
[10:11] <smb> henrix, Does that not sound like the opposite?
[10:11] <smb> sched_autogroup_enabled=0 == noautogroup
[10:11] <henrix> smb: yes, it occurs only when you disable the autogroup, but the traces point to similar place
[10:12] <henrix> it's easily reproducible
[10:12] <smb> henrix, I am sure I have been using noautogroup at least recently without problems but maybe
[10:12] <smb> Again, this would require actually reading the bug report I was not aware of before
[10:13] <henrix> smb: i can reproduce it in a precise kernel and even on a quantal running 3.7-rc1
[10:14] <henrix> anyway, i'm trying to get more info about this
[10:14] <smb> henrix, I can try to see whether it crashes for me as well with sysctl but it might be a similar reason
[10:15] <smb> Assuming some init was forgotten to the copy of the autogroup variable
[10:15] <smb> (which I suspect)
[10:16] <henrix> smb: ok, thanks
[10:25]  * ppisati -> out for lunch
[11:10]  * henrix -> SIGFOOD
[12:38] <caribou> Q: I've just finished bisecting/testing a revert on latest Quantal & Precise kernels for a bug : LP: #1056746
[12:39] <caribou> right now, I've assigned the bug to myself
[12:39] <caribou> but should it be assigned to an official team instead ?
[12:40] <caribou> but 1056746 is causing iscsi to hang reboots when multipath is active
[12:40] <rtg> bug #1056746
[12:40] <caribou> bug 1056746
[12:40] <ubot2> Launchpad bug 1056746 in linux "kernel panic on iscsi target disconnect" [High,Confirmed] https://launchpad.net/bugs/1056746
[12:40] <caribou> hmm, need to go change the title
[12:42] <rtg> caribou, if you're pursuing the bug then leave it assigned to yourself
[12:42] <caribou> rtg, yep I am
[12:42] <caribou> arges will help me format the patch submission later so I don't send rubbish to the list
[12:50] <ogasawara> rtg: did quantal lbm make it through to the archive?
[12:51] <rtg> ogasawara, as did the meta package (I think)
[12:52] <rtg> ogasawara, I chatted with the folks on #ubuntu-release about it, I think I remember it being accepted, then I raced off to ride bikes and drink beer and all else was forgotten.
[12:53] <rtg> damn, another dya has started.
[12:54] <rtg> ogasawara, https://launchpad.net/ubuntu/+source/linux-backports-modules-3.5.0
[12:58] <ogasawara> rtg: right, seems like it's missing there
[12:58] <rtg> ogasawara, its there, its just not been published
[12:58] <rtg> I'll bug 'em about it
[12:59] <ogasawara> rtg: thanks, gotta jump on a call here
[13:23] <slangasek> psivaa: bug #1066883> great, thanks; will peruse that output later today
[13:23] <ubot2> Launchpad bug 1066883 in linux "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
[13:24] <rtg> ogasawara, no good deed goes unpunished :) bug #1068125
[13:25] <ubot2> Launchpad bug 1068125 in linux-backports-modules-3.5.0 "Quantal LBM should not generate udebs" [Undecided,In progress] https://launchpad.net/bugs/1068125
[13:25] <psivaa> slangasek: ok, yw
[13:25] <ogasawara> rtg: ack, I'll clean it up.
[13:26] <brendand> bjf, henrix - what is the cadence looking like now? will regression testing be after or before uds?
[13:27] <brendand> http://people.canonical.com/~kernel/reports/sru-report.html is not very forthcoming
[13:27] <henrix> brendand: we're holding it a little bit until the release so that we're not using the buildds for kernels
[13:28] <brendand> henrix, so it's not built yet?
[13:28] <brendand> henrix, in that case it will be after uds for regression testing i guess?
[13:28] <henrix> brendand: no, it is not. we are not supposed to upload anything to the buildds during this period
[13:28] <henrix> brendand: i believe this cycle will be extended to 4 weeks
[13:29] <brendand> henrix, ok, thanks!
[13:29] <henrix> brendand: np
[13:29] <henrix> bjf: ^ that's correct, right?
[13:30] <henrix> brendand: anyway, i expect to start uploading kernels later today or tomorrow.
[13:52] <StFS> Hi. I was just fixing a small bug with my dock audio output (added a single line to the quirk table). Anyways, I built my own kernel-image .deb but it has the same version as the one that is installed from the repo. So first question: how do I change the version number for the package that I'm building? Second question: is there some naming that I could use so that if a new kernel-image becomes available in the repo it will still be installed over the
[14:06] <henrix> StFS: you can take a look at https://wiki.ubuntu.com/Kernel/Dev/KernelBugFixing (section "Building and Uploading the Package")
[14:06] <henrix> StFS: it suggests the use of '~'
[14:19] <bjf> brendand, https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
[14:20] <bjf> brendand, we discussed this with ara, the week of uds will be an additional verification week and the week after will be testing
[14:21] <brendand> bjf - sounds like a plan
[15:00] <rtg> ogasawara, you gonna throw up the day 0 kernel today ?
[15:01] <ogasawara> rtg: I wasn't planning on a 0 day
[15:01] <ogasawara> rtg: was just gonna let it do it's normal SRU cycle
[15:02] <rtg> ogso, just let the stable team do it ?
[15:02] <ogasawara> rtg: yep, I didn't see anything urgent on master-next
[15:02] <bjf> ogasawara, we have the conn :-)
[15:02] <rtg> ogasawara, 2 stable updates in the pipe, but should likely go through Q/A
[15:03] <ogasawara> rtg: yep, I'd prefer those get some baking before going up
[15:03] <rtg> bjf, then its officially yours. I'll go back to worrying about signed modules
[15:03] <bjf> rtg, ack
[15:03] <bjf> henrix, herton, sconklin, ^ quantal is ours
[15:04] <herton> ack
[15:05] <henrix> \o/
=== elmo__ is now known as elmo
[15:06]  * ogasawara back in 20
[15:30] <apw> rtg, now we know the name of r, are you going to fix the repo name ?
[15:30] <rtg> apw, already did
[15:30] <apw> hmmm, my update worked, odd
[15:31] <rtg> apw, ln -s ubuntu-raring ubuntu-r
[15:32] <bjf> apw, are the buildds free to use again?
[15:33] <apw> bjf, we're not released as yet, so not sure
[15:33] <bjf> apw, ack
[15:33] <apw> bjf, oh word on the street is you are good to get back on your SRUs
[15:34] <bjf> apw, cool, thanks
[15:34] <bjf> henrix, ^ you are free to engage
[15:35] <bjf> :w
[15:36] <rtg> its a target rich environment
[15:45] <apw> rtg, so i am assuming you are owning -r rebases for now ... in the interim i am going to liase with infinity et al about what they want in R 'before' toolchain etc
[15:45] <rtg> apw, almost done
[15:46] <apw> rtg, cool.  i suspect our headers are going to be a mess after the 3.7 update, so it seems wise to put a 3.6 for the initial opening/bootstrap
[15:47] <rtg> apw, likely. there is a Ubuntu-3.6 tag
[15:48] <apw> rtg, i see it, thanks for remembering :)
[16:10] <rtg> ppisati, apw: I'm done with the ubuntu-raring smack down. went from 300'ish patches down to 108
[16:10] <rtg> ppisati, I'll start building with your arm patches here shortly
[16:11] <apw> rtg nice
[16:11] <ppisati> rtg: i've two more
[16:11] <ppisati> rtg: they are from Q, it seems you forgot them
[16:11] <rtg> ppisati, I'd gotten about as far as you did before I got tired of rebuilding and just gave up on arm altogether
[16:12] <rtg> ppisati, go ahead and post 'em and I'll pick them up
[16:12] <ppisati> rtg: ok, give 5mins and i'll send these two (usb stuff)
[16:12] <ppisati> ack
[16:32] <ppisati> rtg: patches sent
=== sforshee` is now known as sforshee
[16:50] <tyhicks> rtg, cking: bug 338914 is a pretty minor bug that no one would hit unless they tried pretty hard
[16:50] <ubot2> Launchpad bug 338914 in linux "Proper cipher support isn't checked at mount time" [Undecided,Fix committed] https://launchpad.net/bugs/338914
[16:50] <rtg> tyhicks, true, buts its also an easy patch
[16:50] <tyhicks> rtg, cking: It probably isn't worth the cycles needed for backporting and verifying it
[16:50] <tyhicks> it is easy
[16:51] <tyhicks> rtg: If you (or cking, rather) don't mind doing the work, I won't stop you. Just wanted to mention that it isn't a big deal. :)
[16:51] <rtg> tyhicks, no problem, its already in the pipeline and cking has an easy verifier
[16:52] <tyhicks> (Thanks a bunch for helping to stay on top of eCryptfs bugs in Ubuntu, btw!)
[16:52] <tyhicks> sounds good!
[16:52] <rtg> tyhicks, you're my special project :)
[16:52] <tyhicks> heh... I hope that's a good thing
[16:53] <rtg> tyhicks, nah, its just that I've always been an ecryptfs proponent, so I keep a special eye out for bug fixes etc
[16:54] <tyhicks> We definitely have the most eCryptfs users, so that's a good thing
[16:54] <cking> yup, and it's no big deal for me to keep on top of these patches to SRU
[16:57] <cking> tyhicks, BTW, I'm going to see if I can construct some eCryptfs tests to bump up the gcov coverage rate
[16:57] <tyhicks> cking: Great!
[16:58] <tyhicks> cking: I've always wanted to add eCryptfs support to xfstests to automatically pick up the large number of tests that they have (and actively add new tests), but I've never had the chance
[16:59] <tyhicks> cking: Keep that option in mind as you plan out what you want to do
[16:59] <cking> tyhicks, yep, lets call that a 13.04 work item
[17:00] <bjf> tyhicks, cking i think that would be fairly easy to add to our existing tests
[17:00] <tyhicks> Hmm... making xfstests know about stacked filesystems may help overlayfs testing, too
[17:00] <bjf> tyhicks, cking we already run the xfstests
[17:00] <tyhicks> good to know
[17:00] <cking> bjf, yep, we can discuss that at UDS
[17:19] <kroson_> Hi everyone, and congratulations for Ubuntu 12.10 release. Can you tell me if upgrading from kernel 3.5 to kernel 3.6 in 12.10 is a safe procedure?
[17:19] <kroson_> thanks
[17:40]  * rtg -> lunch
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[18:02]  * ppisati -> EOD
[18:13] <alexbligh1> now you guys have got quantal out (congrats) is there a plan for quantal-backport kernel for precise?
[18:13] <alexbligh1> (as in 'in the precise repo')
[18:15] <rtg> alexbligh: yes, but you know you can also get it from https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport until its official in teh archive
[18:30] <alexbligh> rtg, thanks. it was more for our customers than for me. AFAIK just installing the q .deb works now on p.
[18:31] <rtg> alexbligh: it'll show in due course when things have settled a bit from the release. I'll pursue getting it uploaded tomorrow.
[18:32] <alexbligh> rtg, great. No rush from me. We'll just have the normal run of people complaining that they can't install our stuff on arcane-hardware-du-jour and our normal solution is to point them at a backported kernel.
[18:38] <ogasawara> rtg: so we have bug 1026831 which is linked to from https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-kernel-misc, but we also have https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates
[18:38] <ubot2> Launchpad bug 1026831 in debian-installer "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [Undecided,Invalid] https://launchpad.net/bugs/1026831
[18:39] <rtg> ogasawara, I'll use the second one
[18:39] <rtg> https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates
[19:13] <rtg> ogasawara, bug #1068281
[19:13] <ubot2> Launchpad bug 1068281 in linux-meta "Quantal LTS kernel in Precise" [Undecided,Fix committed] https://launchpad.net/bugs/1068281
[19:14] <ogasawara> rtg: ack
=== rsalveti_ is now known as rsalveti
[19:36] <rtg> bjf, https://launchpad.net/ubuntu/raring still indicates armel
[19:37]  * ogasawara lunch
[19:37] <bjf> rtg, indeed it does
[19:38] <bjf> rtg, but then you know how hard it is to removes a flavour let alone an arch
[19:49] <manjo> rtg, in 12.04 we had /lib/modules/3.2.0-32-generic/build but in 12.10 we don't have the 'build' directory anymore ? 
[19:50] <maxb> I have a /build on 12.10
[19:50] <rtg> manjo, likely a function of upstream build changes, but its a detail that I can't remember
[19:50] <manjo> maxb, you said /build ? 
[19:51] <maxb> By which I mean I'm being a lazy typist and mean /lib/modules/$(uname -r)/build
[19:51] <manjo> rtg, I was looking for .config Module.symvers Makefile which used to be under /lib/modules/$(uname -r)/build
[19:52] <manjo> maxb, interesting I just installed 12.10 and I don't have that build directory 
[19:52] <maxb> maxb@zenbook:~$ ls -lA /lib/modules/3.5.0-17-generic/build/Module.symvers 
[19:52] <maxb> -rw-r--r-- 1 root root 844882 Oct  9 20:56 /lib/modules/3.5.0-17-generic/build/Module.symvers
[19:53] <maxb> manjo: And if you 'apt-get install linux-headers-generic' ?
[19:53] <manjo> hmm installing 
[19:53] <manjo> maxb, you saved me ! 
[19:53] <manjo> thanks 
[19:54] <manjo> maxb, I guess header-generic is not installed by default anymore .. but that makes sense 
=== henrix is now known as henrix_
[20:51]  * cwillu pokes smb with a sysctl.conf entry
[20:51] <cwillu> "kernel.sched_autogroup_enabled = 0" in /etc/sysctl.conf is what makes my machine different; should have thought of that when you said "noautogroup"
[21:12]  * rtg -> EOD
=== lifeless_ is now known as lifeless