[07:21] <apw> Daviey, mainline'ing anything is a big effort
[07:35] <jjohansen> Daviey: and generally if you mainline it you become the maintainer unless you can get someone else to take it over
[07:46] <smb> morning
[07:48] <ppisati> hey Stefan
[07:48] <smb> Morning Paolo
[07:48] <apw> smb, morning
[07:48] <smb> an Anday... :)
[07:48] <smb> mean Andy
[07:49] <ppisati> morning * <= wildcard :)
[07:50] <smb> ppisati, Usually "Good TOD *" ;)
[07:57] <Daviey> crap.
[08:12] <smb> Daviey, Pleasure to meet you (again), too. :)
[08:14] <Daviey> smb: o/ :)
[08:18]  * abogani waves all
[08:22] <cking> all very polite here
[08:22] <smb> cking, Wait till we are awake... :)
[08:23] <cking> yeah, when the coffee kicks in..
[08:35] <apw> cking, yo nobby
[08:37] <cking> thanks apw, much appreciated
[08:40]  * ppisati -> away 10mins...
[08:41] <roadmr> quick question, do most bluetooth devices use the btusb driver? or are there some / many that don't?
[08:49] <apw> roadmr, i think some do not, i have no feel for how many tho.
[08:50] <roadmr> apw: thanks, so I'm better off not assuming they all do then
[13:00] <ogasawara> skaet: sorry I missed your pm yesterday, probably best to drop in here for kernel related release issues in case I'm unavailable
[13:00] <ogasawara> skaet: as far as the system freeze on upgrade from natty to oneiric, that's likely indicative of an issue with the natty kernel vs. oneiric as you won't be running the oneiric kernel at that point.
[13:01] <ogasawara> skaet: is there a bug number you can point us to?
[13:25] <ogasawara> cjwatson: bug 837332, I can just revert that config change for now.
[13:25] <ubot2`> Launchpad bug 837332 in linux "missing efi-modules udeb" [Undecided,Confirmed] https://launchpad.net/bugs/837332
[13:26] <ogasawara> cjwatson: it likely the quickest fix and I can then re-upload
[13:26] <cjwatson> ogasawara: you think we should try to shove that in for beta then?
[13:26] <cjwatson> I assumed you'd made the config change for some other reason ...
[13:27] <ogasawara> cjwatson: it was made per a review of our modules which were not enabled as modules
[13:28] <cjwatson> I was test-building http://paste.ubuntu.com/677973/
[13:28] <cjwatson> hm, I think future process for that kind of thing probably ought to include consideration of udebs ...
[13:28] <ogasawara> cjwatson: indeed
[13:30]  * cjwatson asks on #-release, since a kernel upload at this point might well cause problems
[13:32] <cjwatson> (that diff's slightly wrong, still testing)
[13:35] <ogasawara> cjwatson: i'd be in favor of just reverting at this point, we can make the config change and udeb fix up after beta-1
[13:36] <cjwatson> ogasawara: actually, built-in is really better for efivars from my point of view
[13:36] <cjwatson> ogasawara: it means d-i can always know reliably what platform it's on
[13:37] <cjwatson> we can deal with it being modular, but it's more effort
[13:37] <ogasawara> cjwatson: sounds reasonable to me, I'll just add that to our enforcer then that is should remain built-in
[13:37] <cjwatson> so I wonder if it's worth it
[13:37] <ogasawara> cjwatson: it's a quick one line entry in our enforcer
[13:37] <cjwatson> unless it has some negative impact on non-EFI systems or something, but I didn't think it did
[13:37] <ogasawara> cjwatson: I don't believe so
[13:37] <apw> yeah a case of s dependancy we are unaware of really, and so its gotten pushed out
[13:38] <cjwatson> yeah, its init is trivial if EFI is disabled
[13:38] <cjwatson> ok, in that case an enforcer entry would be great from my POV, thanks
[13:38] <apw> yeah we use those to both ensure the setting and to contain documentation as to why, so we don't undo it without thinking
[13:39] <ogasawara> cjwatson: ok, will prep the config revert and add to our enforcer
[13:39]  * ogasawara keeps an eye on #ubuntu-release for the final work if it's ok to upload
[14:20] <ogasawara> bah, stupid abi check fails
[14:21]  * ogasawara bumps abi
[14:21] <apw> ogasawara, moving  a module builtin from module shouldn't fire the abi checker should it?
[14:22] <ogasawara> apw: I didn't think so either.  I disabled the module check but it's still vomiting on the abi check
[14:22] <ogasawara> II: Checking ABI for generic...
[14:22] <ogasawara>     Reading symbols/modules to ignore...read 0 symbols/modules.
[14:22] <ogasawara>     Reading new symbols (9)...read 12089 symbols.
[14:22] <ogasawara>     Reading old symbols (9)...read 12089 symbols.
[14:22] <ogasawara> II: Checking for missing symbols in new ABI...found 0 missing symbols
[14:22] <ogasawara> II: Checking for new symbols in new ABI...found 0 new symbols
[14:22] <ogasawara> II: Checking for changes to ABI...
[14:22] <ogasawara>     MOVE : register_efivars                         : drivers/firmware/efivars => vmlinux
[14:22] <ogasawara>     TYPE : register_efivars                         : (unknown)EXPORT_SYMBOL_GPL =>
[14:22] <ogasawara>     MOVE : unregister_efivars                       : drivers/firmware/efivars => vmlinux
[14:22] <ogasawara>     TYPE : unregister_efivars                       : (unknown)EXPORT_SYMBOL_GPL =>
[14:22] <ogasawara> WW: 2 symbols changed location
[14:22] <ogasawara> EE: 2 symbols changed export type and weren't ignored
[14:22] <ogasawara> II: Done
[14:22] <ogasawara> make: *** [abi-check-generic] Error 1
[14:22] <ogasawara> Failure(2)
[14:23] <apw> well for me i'd just ignore the abi and call it the same, noone should be relying on those and they are moves only
[14:23] <apw> tgardner, ^^ ?
[14:23] <apw> otherwise they will have to spin the installer and all that jazz
[14:23] <ogasawara> apw: yep, that's what I'd like to avoid
[14:23] <tgardner> apw, ogasawara: ack
[14:23] <ogasawara> apw, tgardner: ack, so I'm gonna disable the abi check too and upload
[14:24] <tgardner> ogasawara, go for it.
[14:33] <bjf> ##
[14:33] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:33] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:33] <bjf> ##
[14:50] <tgardner> ogasawara, do you use kteam-tools/buildscripts/build-mkppa to do your test builds ? I'm thinking about flipping the switch to add '-j...' if parallel builds are supported for the release.
[14:51] <ogasawara> tgardner: I've been using stefan's build scripts (build-prep and build-start)
[14:52] <tgardner> ogasawara, which ultimately calls target-scripts/run-build
[14:54] <ogasawara> tgardner: and I believe that uses CONCURRENCY_LEVEL?
[14:55] <tgardner> ogasawara, CONCURRENCY_LEVEL only applies to the kmake. My changes will build multiple flavours in parallel. It appears to cut most release builds by 50-75%
[14:55] <tgardner> with the side effect of totally burying the build server.
[14:56] <ogasawara> tgardner: well I'm gonna change to your build scripts then :)
[14:56] <tgardner> this won't affect archive buildds
[14:56] <tgardner> ogasawara, gimme a bit and I'll have some patches for you to test
[15:19] <tgardner> ogasawara, pull-request sent
[15:22] <tgardner> ogasawara, forgot to mention, don't set concurrency. it'll be automatically set according to NR_CPUS
[15:25] <ogasawara> just FYI, powerpc and arm are going to fail to build for 3.0.0-9.15 due to the enforcer checking only for CONFIG_EFI_VARS=y
[15:25] <ogasawara> needs to be CONFIG_EFI_VARS=y|!CONFIG_EFI_VARS
[15:30]  * ogasawara back in 20
[16:00] <bjf> ##
[16:00] <bjf> ## Kernel team meeting in one hour
[16:00] <bjf> ##
[16:02]  * tgardner lost a server hard drive
[16:03] <smb> those probably should not be carried around... 
[16:04] <cking> tgardner, damaged HDD or just forgot where you put it?
[16:04] <tgardner> cking, Seagate SAS died on boot
[16:04] <cking> not good, how old is that then?
[16:05] <tgardner> cking, I'm not really sure. I was testing the ability to write a 1TB file yesterday and began to experience many errors.
[16:05] <tgardner> I think it was this drive.
[16:07] <cking> time to dd straight to the raw device to see if that fails I suppose...
[16:07]  * tgardner trots back to his server room for an extended visit
[16:25] <apw> cking, are there options for shutdown like there are for reboot (=b etc)?
[16:25] <mjg59> apw: No
[16:25] <mjg59> apw: On non-EFI systems there's only one way to shut down anyway
[16:25] <apw> mjg59, thanks one less thing to check
[16:26] <cking> thanks mjg59
[16:26]  * smb wonders what /sys/power/disk does
[16:26] <mjg59> Depends if it's configured to use platform or shutdown
[16:26] <smb> Right, I thought that was an option to tweak the shutdown
[16:26] <mjg59> Either S5 (which is equivalent to power off) or S4 (which is bsaically the same but the firmware may do odd things)
[16:27] <mjg59> S4 is nominally a sleep state rather than shut down
[16:28] <smb> Ok, ok. Just remember some hw would not work with platform but with shutdown...
[16:28] <smb> Err
[16:28] <smb> mean Ah ok...
[16:29]  * smb is not good at splitting himself into two channels...
[16:56] <bjf> ##
[16:56] <bjf> ## Kernel team meeting in 4 minutes
[16:56] <bjf> ##
[17:00] <ppisati> o/
[17:02] <cking> ppisati, in #ubuntu-meeting 
[17:07] <Book_em_Dano> The bootup process is halted with a message that a "soft lockup was detected on CPU#1 ...(modprobe:XXXX)" and that it has not responded for 61 seconds, what is this error indictative of?
[17:08] <apw> driver init for that driver is likely broken and causing a lockup
[17:13] <Book_em_Dano> How can I resolve this issue?
[17:21] <bjf> ogasawara, note, heat on new bugs (the bugs that show in the daily mail) is going to be pretty low, so though I have no problem adding it, i'm unsure of it's value
[17:22] <ogasawara> bjf: yah, that's true.  don't add it for now, it'll just add clutter with little to no value then.
[17:24] <bjf> ogasawara, not to harp (much) but that's where i see the value in the 7-day and 30-day html reports, they can give you an idea of what is really "hot"
[17:24] <ogasawara> bjf: indeed.  I just have to remember to look at those reports
[17:25] <ogasawara> bjf: that's why I like the morning bug email, it fits nicely with my daily routine (wake up, check email...)
[17:25] <ogasawara> bjf: is there an ubuntu qa irc channel, I want to see if I can get access to a machine in cert
[17:26] <Book_em_Dano> Can resolve the soft lockup w/o reinstalling Ubuntu?
[17:55] <Book_em_Dano> Can I resolve the soft lockup w/o reinstalling Ubuntu, by some other means?
[17:59] <ppetraki> Book_em_Dano, pass 'nosoftlockup' in addition to your kernel parameters
[21:02] <tgardner> ogasawara, 3.0.4 is a clean rebase on master-next. are you still rebasing ?
[21:07] <ogasawara> tgardner-afk: I've got it rebased, was doing a test build but trying to use your scripts and needed to make some tweaks
[21:07] <ogasawara> tgardner-afk: test build just about finished and then I'll push
[21:52] <Book_em_Dano> I tried inputting the nosoftlockup boot parameter via grub2 to offset a soft lockup error during the bootup process, but as soon as I tried to execute it, a "alloc magic is broken at 0x7fcf2660" error appeared; what is causing this error, is grub corrupted?