[01:28] <mfilipe> hi! I updated my kernel today and it doesn't show more the splash screen to decrypt my lvm
[01:28] <mfilipe> :S
[01:30] <mfilipe> anyone here with same problem?
[06:42] <ppisati> moin
[07:19] <smb> morning
[07:36]  * apw yawns
[08:03] <mnemoc> hi, I'm trying to make a .deb out of a kernel for a cortex-a8 soc I'm unofficially maintaining. what's the right way of making make-kpkg produce an uImage instead of vmlinuz? also, it seems only --arch arm is supported, will this work on armel and armhf?
[08:05] <ppisati> mnemoc: to get an uImage instead of vmlinuz, use make uImage
[08:06] <mnemoc> ppisati: when building manually sure, my doubt is when using this `make-kpkg` thing. I want to share a .deb people could just use...
[08:07] <mnemoc> or `make-kpkg` is the wrong approach?
[08:24] <cking> smb, apw, some more benchmarks: http://zinc.canonical.com/~cking/iosched/postmark
[09:15] <ppisati> ok, this is funny
[09:15] <ppisati> if i'm logged in in another tty (say via ssh(
[09:15] <ppisati> then the serial is ok
[09:15] <ppisati> else we start loosing chars
[10:00] <brendand> Daviey, are there backport kernels for servers too?
[10:09] <Daviey> brendand: we share a kernel, so yes.  I cannot comment on server specific regression testing.
[10:10] <brendand> Daviey, sorry - i actually didn't ask a detailed enough question. what i meant is are there Q series backports for Precise server and which PPA do i get them from? is it the same as for desktop?
[10:27] <ppisati> brb
[10:49] <Daviey> brendand: same as desktop, we now share kernels
[10:58]  * ppisati -> out for food, later
[12:37] <brendand> once i've enabled the https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport ppa, is it a matter of just doing  dist-upgrade to install the quantal kernel?
[12:37] <tgardner> brendand, nope, you have to install the kernel meta package thats in that PPA
[12:38] <brendand> tgardner, linux-meta-lts-quantal ?
[12:38] <tgardner> brendand, seems about right
[12:39] <brendand> tgardner, sure does. i'm only suspicious because it's not been picking it up on my own precise install. trying on vbox now
[12:40] <brendand> tgardner, still says unable to locate package
[12:40] <brendand> weird
[12:40] <brendand> i enabled with apt-add-repository and then did apt-get update to make sure
[12:40] <tgardner> brendand, because thats the source package name ? try one of the binaries.
[12:42] <brendand> tgardner-afk, right, so linux-image-generic-lts-quantal
[13:08] <brendand> cking - i still haven't managed to catch vanhoof about where to raise firmware bugs. any chance i could raise them in fwts itself and move them later?
[13:08] <brendand> cking - i've a few, including some criticals, from quantal testing
[13:09] <cking> brendand, well vanhoof is on vacation, so you won't get much from him from the next week. so file them against fwts and then we will sort this out later when he gets back. did you send him an email about it?
[13:10] <brendand> cking, not yet. i will and cc you on
[13:10] <brendand> cking, this is one of the criticals. actually looks pretty bad : http://paste.ubuntu.com/1040728/
[13:11] <cking> brendand, ok - file a bug as per usual
[13:13] <cking> lemme know the bug number and I can eyeball it too
[13:14] <brendand> https://bugs.launchpad.net/fwts/+bug/1013168
[13:14] <ubot2> Ubuntu bug 1013168 in fwts "Asus ET2012E fails checksum test" [Undecided,New]
[13:17] <cking> brendand, so it looks like the kernel has loaded the ACPI tables, so can you add the output from "sudo acpidump" to the log so I can see why fwts is complaining
[13:18] <brendand> cking, assuming the system is still booted to access it, yeah. otherwise tomorrow (or maybe later today)
[13:18] <brendand> cking, one sec
[13:19] <brendand> cking: ubuntu@201201-10354:~$ sudo acpidump
[13:19] <brendand> sudo: acpidump: command not found
[13:19] <brendand> ??
[13:20] <sforshee> brendand, sudo apt-get install acpidump
[13:21] <brendand> sforshee, well yes
[13:21] <cking> ..sorry I was answering a phishing scam call just then
[13:24] <brendand> cking, i assume you'd expect acpidump to be installed already?
[13:24] <cking> brendand, nope, I just guessed you may know how to install it
[13:26] <brendand> cking, ok ok, i was just checking that you weren't relying on it for fwts to do it's job
[13:27] <brendand> cking - looks like a little networking issue in the taipei lab. i'll have to check it with our lab engineer. i think he'll be around later, either that or tomorrow
[13:27] <cking> brendand, nope, thats all taken care of in fwts
[13:27] <brendand> cking, at the moment i can't install anything on that system
[13:28] <cking> brendand, OK - well I will look at see if it's now a critical issue for Quantal. I believe it used to be bad issue a while ago.
[13:42] <tgardner> jsalisbury, ppetraki, henrix, ayan, jjohansen - rebooting tangerine for kernel update soon
[13:42] <tgardner> ppisati, ^^
[13:43] <jsalisbury> tgardner, ack
[13:43] <henrix> tgardner: ack
[13:43] <ppisati> ack
[13:44] <brendand> cking - http://paste.ubuntu.com/1040784/
[13:44] <cking> brendand, I've updated the bug and will add some better intelligence to fwts.  See the bug for the full description of what's wrong
[13:44] <brendand> cking, ok
[13:44] <cking> thanks for the data too
[13:45] <brendand> cking, no problem. i was just about to note that acpidump spat out 'Wrong checksum for XSDT!' on stderr, but you reached that conclusion already
[13:45] <cking> :-)
[13:46] <brendand> cking, so fwts was actually the right place ;)
[13:46] <cking> of course:-)
[14:04] <cking> brendand, I've got a fwts fix to help with this kind of issue, it will appear in the next release of fwts within a week or so
[14:05] <brendand> cking, no problem. we'll be looking out for it
[14:12] <tgardner> smb, gomeisa needs rebooting for kernel update
[14:12] <smb> tgardner, Ok, then I start my build when thats done. I am off it
[14:52] <jsalisbury> bjf, herton, henrix: Looks like a regression in 3.2.0-25: bug 1013093
[14:52] <ubot2> Launchpad bug 1013093 in linux "Latest kernel causes purple screen of death" [High,Confirmed] https://launchpad.net/bugs/1013093
[14:53] <henrix> jsalisbury: yeah, i was actually looking at it
[14:54] <henrix> jsalisbury: i guess we need to get a little bit more info from the bug reporter
[14:54] <jsalisbury> henrix, cool, thanks.  
[14:54] <henrix> jsalisbury: np
[14:54] <jsalisbury> henrix, yeah, I asked for him to disable splash to try and capture more info
[14:54] <henrix> jsalisbury: yep, that should give us something to work with
[14:57] <jsalisbury> henrix, thanks for looking
[14:58] <jwi> jsalisbury: and check if fglrx is built properly on the new kernel :)
[14:59] <jsalisbury> jwi, ok.  Anything specific to look at to check that fglrx was built properly?
[15:04] <jwi> jsalisbury: jockey/dkms log files? afair fglrx also complains to dmesg if there's a version mismatch.
[15:04] <jsalisbury> jwi, ok, thanks!
[15:05] <ppisati> http://blogs.skype.com/linux/2012/06/skype_40_for_linux.html
[15:05] <ppisati> whoa!
[15:05] <ppisati> after years on stagnation, a new relase i can't belieive it!
[15:05] <ppisati> *of
[15:06] <cking> I don't believe it
[15:06] <cking> which universe are we living in again?
[15:09] <apw> bjf, what is going on with master-next on precise ?
[15:09] <apw> bjf, its based on Ubuntu-3.2.0-24.37 but master is -26 ?
[15:09] <apw> henrix, ^^
[15:09] <apw> herton, even ^^
[15:09] <bjf> apw, looking
[15:09] <henrix> apw: checking
[15:10] <tgardner> didn't get rebased ?
[15:11] <apw> twice ?
[15:11] <bjf> apw, i know we are working on the start of the new cycle
[15:11] <apw> how did we make -26 from -25 if its not in master-next, makes no sense
[15:12] <tgardner> apw, dunno, but it _is_ a straightforward rebase.
[15:12] <henrix> ok, so that's probably a coordination issue..? i don't usually do the rebase (no permissions) and i guess usually herton does that
[15:12] <sconklin_> I pushed that yesterday, maybe I screwed it up
[15:12] <bjf> apw, we'll get it sorted
[15:14] <apw> i don't think i want to have to rebase master-enxt every time i want to make a test kernel, that seems to defeat the point of it being the 'next' kernel
[15:14] <apw> its the last kernel plus some random crap if its not up to date?
[15:14] <tgardner> apw, agreed. 
[15:15] <jsalisbury> bjf, herton, henrix, looks like one more regression in 3.2.0-25: bug 1013183
[15:15] <ubot2> Launchpad bug 1013183 in linux "Sound playback stopped working in 3.2.0-25" [Medium,Confirmed] https://launchpad.net/bugs/1013183
[15:15] <henrix> apw: right, i guess that's my fault there. whenever i ask a sponsor to push a kernel, i never check he has done the rebase and i never explicitely ask him to do that
[15:16] <tgardner> apw, whats interesting is that 2 of the recent hwmon patches I submitted disappear when rebased against master.
[15:17] <apw> tgardner, yeah its clearly doubly broken as its more than one behind
[15:17] <apw> fingers crossed nothing got lost
[15:17] <sconklin_> I know what happened, and I'll fix it.
[15:17] <jwi> tgardner: i think 3/4 and 4/4 of your fam15h_power patches have already landed in oneiric (and precise) through -stable
[15:17] <tgardner> jwi, I think so too
[15:17] <sconklin_> Unless someone else also rebased or forced, I have everything I need to fix it
[15:17] <apw> sconklin_, do you know we won't have lost anything or do we need to review the mailing list
[15:17]  * apw hasn't done that
[15:18] <jwi> tgardner: yep, 3.0.31 and 3.2.17
[15:18] <sconklin_> I know for sure (because I always check) that the commit before I pushed matched what is now in master
[15:19] <sconklin_> and what was pushed was an old local branch that I still have. So I can take the additional commits that were made on that and rebase them onto master and we shoudl be good
[15:19] <tgardner> sconklin_, looks like.
[15:21] <tgardner> sconklin_, what if you just rebase master-next against master ?
[15:23] <sconklin_> tgardner: that would be a mess because of the differences in abi bumps and such. Easiest thing it to cherry pick the 5 commits and force it back up
[15:24] <tgardner> sconklin_, hmm, I rebased it wothout any problem.
[15:24] <tgardner> no conflicts
[15:25] <ogasawara> bjf: just got off my manager call, gonna dip out for 5min and be back for our SRU call
[15:25] <sconklin_> and you got these five commits:?
[15:25] <sconklin_> 158e492 hwmon: (fam15h_power) Fix pci_device_id array
[15:25] <sconklin_> 8e701b3 hwmon: fam15h_power: fix bogus values with current BIOSes
[15:25] <sconklin_> e8bbc41 hwmon: (fam15h_power) Increase output resolution
[15:25] <sconklin_> c763cca hwmon: (k10temp) Add support for AMD Trinity CPUs
[15:25] <sconklin_> 876c6d1 x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it
[15:25] <bjf> ogasawara: ack
[15:25] <sconklin_> tgardner: 
[15:25] <tjaalton> tgardner: test-building the intuos5-branch, i'll send a pull request on the list later :)
[15:26] <tjaalton> (rebased on current master)
[15:26] <tgardner> sconklin_, 2 of them disappeared cause they were already in a stable update that was on master but not on master-next
[15:26] <sconklin_> ack
[15:26] <tgardner> tjaalton, ack
[15:26] <sconklin_> ok, why don't you push that and then I'll check against what I have here. That way I'll preserve everything I have for sure
[15:27] <tgardner> sconklin_, ok, one sec...
[15:27] <tgardner> sconklin_, done
[15:27] <BenC> tgardner: How's the e500mc looking? I'll be in San Antonio from Sunday to Friday next week, so I'm hoping to have good news for some folks while I'm there :)
[15:28] <tgardner> BenC, I sent email yesterday to you and the list NAK'ing the pull request.
[15:28] <sconklin_> tgardner: checking
[15:28] <BenC> tgardner: I didn't get an email
[15:28] <tgardner> hmm, lemme check where it went
[15:28] <BenC> And no one has processed my request to sub to kernel-team@ yet
[15:28] <bjf> tgardner: it made the mailing list
[15:29] <tgardner> BenC, https://lists.ubuntu.com/archives/kernel-team/2012-June/020706.html
[15:29] <BenC> Wait, I see the list stuff
[15:34] <BenC> tgardner: I suspect you don't have enough experience in the powerpc community to make some of the assumptions you have in this email. Replying now.
[15:34] <tgardner> BenC, you're absolutely correct, which is why I asked about it.
[15:35] <BenC> You asked, but without the possibility that these patches may be more relevant now :)
[15:36] <tgardner> BenC, its gonna be  a hard sell given the other inclusion criteria, but we can duke it out on the list.
[15:36] <sconklin_> tgardner: looks ok, I also verified that the 2 commits that disappeared were really there . Thanks.
[15:36] <tgardner> sconklin_, np
[15:36] <sconklin_> apw: thanks for the alert
[15:41] <BenC> tgardner: One of the main issues at hand here is that Freescale Power CPU/SoCs are about to reach critical mass, and either I can put Ubuntu in front of it, or it can be behind it. A good portion of our customers are looking to the cloud, and I think Ubuntu puts them in a better place, but if the install/support isn't there, then I have no pull with my fellow engineers and the pin heads to make Ubuntu tier one for them. They will buckle to 
[15:41] <BenC> buzz and executive requests to go with that other distro
[15:43] <BenC> linux# git log | grep '@freescale.com' | wc -l
[15:43] <BenC> 4560
[16:28] <BenC> tgardner: would you be open to a patch that simply adds the e500mc support as a build target first, and then I can work on each of the rest of the patches individually?
[16:28]  * ogasawara back in an hour, pediatrician
[16:29] <BenC> The PHY/MDIO stuff is mainly to support the 10G SoC based ethernet, so I can work on that separately (all of my [Upstream] based patches are accepted upstream, so you can safely assume those will get merged at some point, but please consider including them now to avoid the unneeded delay).
[16:31] <BenC> Actually the MDAC one is required to make things compile
[16:32] <BenC> And the PCI one is required to make things boot, but they have been accepted upstream (PCI by benh, mdac by the mdac maintainer)
[16:58] <mfilipe> hi! I use lvm encrypted and now I updated my kernel to 3.2.0-25-generic-x86_64. So, after that update my kernel doesn't show the splash screen to inform the password to decrypted my lvm. What is wrong? Anyone know something about that?
[17:02] <bjf> mfilipe: please file a bug, this sound similar to another reported problem but we'd like the bug anyway
[17:03] <henrix> mfilipe: are you able to introduce the passphase from a terminal? (Ctrl-Alt-F5, or other F*)
[17:03] <tgardner> BenC, lemme get back to you. I gotta step out for a bit.
[17:07] <bjf> mfilipe, if you can keep an eye on the bug once you've filed it, we'd like some help in finding the regression
[17:11] <cking> apw, smb, I've finally written up those ioscheduler tests results - kept on getting distracted today, so it's a bit later than I anticpated
[17:13] <smb> cking, cool. well it wasn't like expecting you to get something today... :)
[17:21] <cking> smb, I re-built those graphs, did some analysis and wrote it up while doing other bits and bobs, the usual kind of stuff really
[17:22] <smb> cking, Yes, I had a bit of a look and at least read the summary. Just intended to say that it was clear it is a bunch of stuff to put together, so no need to think you are late
[17:23] <smb> cking, The graphs look a bit less scary when starting at 0 ;)
[17:23] <cking> yep, gnuplot needed some love
[17:36] <mfilipe> henrix, the screen stay black but I put the passphase seeing nothing and the kernel accepts 
[17:36] <mfilipe> bjf, ok, I will report it
[17:36] <mfilipe> thanks
[17:36] <henrix> mfilipe: ok, so you're actually able to boot?
[17:36] <bjf> mfilipe: thanks
[17:36] <mfilipe> henrix, yes
[17:36] <henrix> mfilipe: ok, cool. can you please post the bug number once you've reported?
[17:37] <mfilipe> I boot but without see the field for passphase 
[17:37] <mfilipe> yep
[17:37] <henrix> mfilipe: thanks
[17:37] <mfilipe> I will reboot here to generate clean logs to bugreport 
[18:05] <mfilipe> henrix, bjf: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1013315
[18:06] <ubot2> Ubuntu bug 1013315 in linux "Kernel doesn't show splash screen to decrypt LVM" [Undecided,New]
[18:06] <bjf> mfilipe: thanks
[18:06] <henrix> mfilipe: ack, will take a look
[18:06] <mfilipe> ;)
[18:20]  * cking -> EOD
[18:36]  * smb out
[19:42]  * ogasawara -> dentist, back in a bit
[19:55]  * tgardner -> EOD
[20:06] <henrix> mfilipe: still around?
[20:20] <mfilipe> henrix, yes
[20:21] <henrix> mfilipe: right, so i was looking at the bug and i was wondering if you could:
[20:21] <henrix> 1) test mainline kernel as suggested by the last comment in the bug report
[20:21] <henrix> 2) make sure the issue is not present in the old kernel (i.e., just reboot into the old kernel to check)
[20:22] <henrix> finally, i guess we will need to do a bisect to find the offending commit(s)
[20:22] <henrix> could you try 1) and 2) and post results into the bug report?
[20:23] <henrix> then, we could start the bisect, by building kernels so that you can test them until we find the faulty commit
[20:27] <mfilipe> ok, I will do that
[20:28] <henrix> mfilipe: thanks