[08:04] <JoshuaL> Since the kernel freeze is in 3 days I have a request, can someone please take a look at this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/754825
[08:10] <JoshuaL_> Oops, kernel panic
[08:11] <apw> JoshuaL_, that is the 'staging' driver for broadcom chips right?  does your system work ok with the proprietry wl driver ?
[08:12] <JoshuaL_> apw: its the driver enabled by default, the same happens with the proprietary driver 
[08:17] <apw> JoshuaL_, if the panic is the same with the prop driver then i suspect that the brcm80211 driver has not been disabled correctly
[08:19] <JoshuaL_> apw: ok, how can i check if it is disabled properly and if not how do i disable it then?
[08:22] <apw> JoshuaL_, it would make sense to see if brcm80211 is blacklisted in /etc/modprobe.d/* .... if it is not make a new file blacklist-brcm80211.conf containing 'blacklist brcm80211'
[08:22] <apw> (all when the prop driver is enabled) and see if that works as a combination
[08:23] <apw> the brcm80211 driver is very flaky as far as i know at the current release
[08:24] <JoshuaL_> blacklist-bcm43.conf is present, ill add the blacklist-brcm80211.conf and see if it helps
[08:24] <apw> JoshuaL_, thanks
[08:24] <JoshuaL_> apw: isnt it an idea to have it disabled by default in the final release?
[08:25] <apw> JoshuaL_, yes may well be ... will decided based on your testing
[08:25] <apw> its enabled on all my systems with those chips but seems to silently do nothing with wl in place so you are slightly unique
[08:25] <apw> but it also seems odd that installing bcmwl does not add the disable
[08:26] <JoshuaL> Oops, after my last message i had the kernel panic, could you please repeat what I had to blacklist?
 blacklist-bcm43.conf is present, ill add the blacklist-brcm80211.conf and see if it helps
 JoshuaL_, it would make sense to see if brcm80211 is blacklisted in /etc/modprobe.d/* .... if it is not make a new file blacklist-brcm80211.conf containing 'blacklist brcm80211'
[08:28] <JoshuaL> apw: thanks. isnt it an idea to disable the driver by default in 11.04?
 its enabled on all my systems with those chips but seems to silently do nothing with wl in place so you are slightly unique
 but it also seems odd that installing bcmwl does not add the disable
[08:29] <diwic> poor dude
[08:29] <apw> yep he has a bad case of the bouncy bouncy
[08:30] <JoshuaL> it makes me happy to hear that I am unique :D
[08:30] <JoshuaL> :p
[08:30] <diwic> hmm, that was the old one disconnecting though, thought he had another panic
[08:32] <JoshuaL> i am going to reboot so the bad driver gets disabled, brb
[08:32] <apw> diwic, heh me too
[08:35] <JoshuaL_> back, is there anything i could do to collect more information to solve the problem?
[08:36] <apw> JoshuaL_, the quality of that driver is so bad right now just avoiding it seems to be the recommendation ... i don't think its going to mature for a few upstream kernel releases
[08:36] <apw> it is one of the drivers which truly deserves to be in staging
[08:36] <JoshuaL_> ok :)
[08:37] <apw> still at least it exists and is improving, better than nothing
[08:37] <JoshuaL_> true
[11:23] <ppisati> kexec -l /boot/vmlinuz-2.6.38-1207-omap4 -append="console=ttyO2 ..."
[11:23] <ppisati> Memory for crashkernel is not reserved
[11:23] <ppisati> Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
[11:23] <ppisati> but if i add "crashkernel=16M" and flash-kernel
[11:23] <ppisati> the board dioesn't boot anymore
[11:23] <ppisati> so, what's the magic to get kexec work on ARM?
[11:23] <ppisati> i'm just following: LP517841
[11:25] <ogra_> i think ericm and cooloney worked on kexec support on arm in the past 
[11:25] <ogra_> (but gave up when it broke over and over again)
[11:25] <ppisati> let's see if they are still around
[11:33] <apw> ppisati, does that work without a 'where' part?
[11:34] <ppisati> apw: it should figure out where to reserve memory by itself
[11:35] <ppisati> apw: that's what the kdump doc says
[11:35] <ppisati> http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt
[11:35] <ppisati> crashkernel=size[KMG][@offset[KMG]]
[11:35] <ppisati> the funny thing is that, all the docs i found about kexec didn't mention this crashkernel= option
[11:35] <apw> ppisati, ahh ok, supprised for most use cases you need to also know where it is ... but that shouldn't stop it working i ugess
[11:36] <ppisati> so i wonder if it has been added later
[11:36] <apw> you shouldn't need a crash kernel if you are just using it for kexec though should you ?
[11:36] <ppisati> nope
[11:37] <apw> ie if you are kexec 'load' then reboot or whatever you do these days
[11:37] <ppisati> apw: the i guess you need to specify where the "new" kernel is loaded
[11:37] <apw> i thought when you -l'd it it just found enough space in memory for it anywhere
[11:37] <ppisati> actually is the kexec tools that complains about that option
[11:37] <apw> then copied it to the normal place on actuall hand over
[11:37] <ppisati> that was the plan, but it complains
[11:38] <ppisati> kexec -l ...
[11:38] <ppisati> Memory for crashkernel is not reserved
[11:38] <ppisati> Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
[11:38] <ppisati> Then try loading kdump kernel
[11:38]  * apw wonders if there are two load options
[11:38] <apw> or possibly that simply it cannot find enough memory to load it
[11:39] <ppisati> perhaps the second one
[11:39] <ppisati> the kexec man page states:
[11:39] <ppisati> kexec -l /boot/vmlinux --append=root=/dev/hda1 --initrd=/boot/initrd
[11:39] <ppisati> and then
[11:39] <ppisati> kexec -e
[11:40]  * apw whines about installing kexec-tools to just look at the man page regenerating his initramfs
[11:41] <apw> ppisati, oddly there are two load options '-l' and '-p' and the message you get is what i'd expect from -p
[11:42] <ppisati> kexec-tools broken?
[11:42] <apw> possible
[11:43] <apw> i would try -p for giggles and see what it does
[11:46] <ppisati> on mvl-dove it doesn't complain about the missing crash-kernel=
[11:48] <apw> ppisati, wihch kernel did you say it was complaining?
[11:48] <apw> i wonder if there is a kexec config difference on omap4
[11:48] <ppisati> yep, omap4
[11:49] <ppisati> Linux panda 2.6.38-1207-omap4
[13:36] <fairuz>  Hi, If I patched my kernel with a xxx.h, and I build an external modules that uses xxx.h. I've tested it on the patched kernel and it works. Is it possible to use the module (by recompiling of course) with an unpatched kernel? or will it complaining about the missing xxx.h?
[13:46] <apw> fairuz, all depends where the xxx.h is, if its with the module source it should be foudn
[13:57] <fairuz> apw: ok ty
[14:07] <ogasawara> apw: \o/ welcome back!
[14:14] <apw> ogasawara, YAY!
[14:52] <jjohansen> apw: Bug #757549
[14:54] <apw> bug #757549
[14:54]  * apw hits ubotu
[14:55]  * smb thinks ubotu has quit
[15:00]  * ogasawara back in 20
[16:16]  * apw goes to touch test natty on his main dev box
[16:34] <donri> I'm having sound issues with ALC892 in Maverick and I'd like to try a more recent kernel. Do I have to build myself?
[16:35] <lag> apw: Why doesn't checkpatch like emacs?
[16:41] <lag> apw: Specifically, it's tabs
[16:43] <apw> lag, define not liking them, how does it complain
[16:44] <lag> It's not checkpatch's fault, it's Emacs
[16:44] <lag> 0001-Framework-for-exporting-System-on-Chip-information-v.patch:69: WARNING: line over 80 characters
[16:44] <lag> #69: FILE: drivers/base/soc.c:22:
[16:44] <lag> +                                                                                 struct device_attribute soc_attrs[])
[16:44] <apw> suspected as much
[16:44] <lag> Auto indentation 
[16:44] <apw> emacs is stupid at times
[16:45] <apw> s'why real men don't use it :)
[16:45]  * lag tuts
[16:45] <lag> I like it :)
[16:45] <lag> It's never done this before though?
[16:45] <lag> All looks good in the file, but when you run checkpatch I receive a million errors
[16:46] <lag> I thought you may have heard of it before and have a solution?
[16:47] <apw> its nearly 15 years since i gave up on emacs for wrecking my wrists, sorry :)
[16:47] <lag> :(
[16:47] <apw> it must think you want spaces though
[16:47] <lag> Okay, thanks anyway
[16:47] <apw> you could try unexpand to clean up on it
[16:47] <lag> It only happens for function parameters 
[16:48] <apw> oh that may be deliberate
[16:48] <apw> thats a gnu ism
[16:48] <apw> to use '    ' to fix auto indent on those
[16:48] <lag> Why put 1500 spaces?
[16:48] <lag> Use what?
[16:48] <apw> so that if you display tabs as 2 characters they line up or something
[16:49] <lag> What's '   '?
[16:49] <apw> those are spaces :)
[16:49] <lag> Checkpatch winges about spaces
[16:49] <apw> there are setting on c-mode to control that sort of thing iirc
[16:50] <apw> yes as it should, gnu c formatting is not right for the kernel
[16:50] <apw> they have different and equally bizarre rules as the kernel
[16:50] <apw> there is a guide on how to configure emacs for the kernel somewhere
[16:51] <lag> Even git doesn't play nicely with emacs
[16:51] <lag> +static ssize_t ux500_get_family(struct device *dev,
[16:51] <lag> +                                                               struct device_attribute *attr,
[16:51] <lag> +                                                               char *buf)
[16:51] <apw> lag see the very very large bit of lisp in Documentation/CodingStyle
[16:51] <apw> lag, that is just poor presentation of epicly long lines
[16:51] <lag> You'll have to expand XChat if you want to see what I'm talking about
[16:52] <apw> see chapter 9 'You've made a mess of it'
[16:52] <lag> That could work
[17:11] <lag> apw: Didn't work
[17:11] <lag> apw: How annoying!
[17:12] <lag> apw: This isn't something I've noticed before?
[17:13] <apw> lag, hrm you are hosed :)
[17:13] <apw> must be a change in emacs
[17:18] <donri> Is recompilation the only option to get a more recent kernel?
[17:18] <donri> Maverick
[17:30] <apw> donri, more recent than what?
[17:35] <donri> apw: than the 'linux' package in main
[17:35] <apw> for maverick no there is nothing offered officially
[17:36] <donri> ppa?
[17:41] <apw> donri, not that i can recall no
[17:42] <donri> okay thanks
[17:42] <kirkland> JFo: hey
[17:42] <kirkland> JFo: I just wanted to make sure that https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090 is on your radar
[17:42]  * JFo looks
[17:43] <JFo> kirkland, I don't usually look at qemu-kvm bugs. Does it need a kernel patch?
[17:43]  * JFo reads some more
[17:43] <JFo> ah yeah
[17:44] <JFo> I see serge's comments
[17:44] <donri> how about something like http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-rc2-maverick/ ?
[17:44]  * JFo adds a kernel task
[17:44] <kirkland> hallyn: am i correct in reading that https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090 is kernel-only, ie, no bug in qemu-kvm userspace, right?
[17:44] <kirkland> JFo: i just marked it high/triaged/B2 against linux
[17:44] <kirkland> JFo: feel free to adjust according to your standards ;-)
[17:44] <JFo> kirkland, you beat me to it :-)
[17:44] <JFo> will do
[17:45] <kirkland> JFo: ;-)
[17:45] <kirkland> hallyn: i think the qemu-kvm task to that bug should be marked invalid
[17:45] <JFo> I've tagged it so it will show up in our hot list
[17:46] <kirkland> JFo: you da man
[17:46] <JFo> ogasawara, https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090 which you are probably already looking at. :-)
[17:46] <JFo> kirkland, no, that is you. I am the man standing next to da man :)
[17:49] <hallyn> kirkland: yes, i believe so
[17:49] <kirkland> hallyn: cool, i updated accordingly already
[17:52] <hallyn> kirkland: thx
[18:04] <kirkland> jjohansen: any progress on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/610597 ?
[18:05] <jjohansen> kirkland: no, I was poking at it and reproduced, and then it kind of fell by the wayside to a couple critical bugs
[18:06] <jjohansen> kirkland: aufs suffers from the same basic thing though
[18:06] <kirkland> jjohansen: okay, i just noticed it was milestoned against b2
[18:06] <kirkland> jjohansen: right
[18:06] <kirkland> jjohansen: it's not critical to me, i was just wondering if it was really a b2 bug
[18:06] <jjohansen> well, hrmm I guess not
[18:07] <jjohansen> that is its not going to get done for beta2
[18:07] <jjohansen> kirkland: also the best solution I have come up with is entirely userspace
[18:08] <kirkland> jjohansen: oh?
[18:08] <kirkland> jjohansen: something i can put in ecryptffs-utils?
[18:08] <kirkland> jjohansen: what is it?
[18:08] <jjohansen> kirkland: its walking the mounts late in resume
[18:09] <kirkland> ah
[18:09] <kirkland> jjohansen: so mountall?
[18:09] <jjohansen> yeah possibly, I hadn't decided on where exactly, but that is a candidate
[18:10] <kirkland> jjohansen: okay, well, i've moved the milestone on the linux part of that bug to ubuntu-later, rather than natty-b2
[18:10] <kirkland> jjohansen: feel free to update if you change your mind ;-)
[18:10] <kirkland> jjohansen: or perhaps adding a task for mountall
[18:11] <jjohansen> kirkland: oh, thanks.  I just might I want to poke at it a little more before adding the mountall task
[18:13] <jjohansen> kirkland: of course I can see some kernel dev that could be done for it, might be fun to start sending out udev events, that propogate up a mount chain :)
[18:13] <kirkland> jjohansen: k
[18:23] <JFo> <-lunch
[18:44]  * apw calls it a day ... this is toooo much like work
[19:22] <kirkland> JFo: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/751689
[19:22] <kirkland> JFo: me, jdstrand, and slangasek  have all hit this bug in the last few days
[19:23] <jdstrand> last few days? I've hit it all cycle
[19:23] <jdstrand> it affects the maverick kernel too (it's in the bug)
[19:24] <kirkland> jdstrand: yeah, i've been hitting it in Maverick randomly for a while now
[19:24] <kirkland> jdstrand: but i've hit it 2 days in a row (for the first time) on Natty
[19:33] <jdstrand> kirkland: you just need to hit all 8 cpu/threads for a while
[19:40] <jjohansen> hey vendors need to stop shoving 45W parts in little machines
[19:40] <jjohansen> s/hey/heh/
[19:53] <JFo> kirkland, ok thanks
[19:55] <kristian-aalborg> jjohansen: ping - private?
[19:56] <jjohansen> kristian-aalborg: can you wait 30 min?
[19:56] <kristian-aalborg> sure
[19:56] <kristian-aalborg> I didn't mean to stress you :)
[20:12] <slangasek> kirkland: hum, I never hit this bug before upgrading to natty, and I was running my system at full-throttle at various points during UDS
[20:12] <slangasek> now I've hit it 4-5 times in the past two weeks
[20:22] <stgraber> kirkland: +1 on x201s ;) Had the issue twice today working with kvm ...
[20:24] <hallyn> slangasek: which bug?
[20:24] <hallyn> oh, you all are having the kvm memory bogosity?
[20:24] <hallyn> all on x201s?
[20:25] <slangasek> hallyn: no, kernel failing to throttle the CPU when it hits the thermal threshold
[20:25] <slangasek> and the machine shutting down when it hits the critical point
[20:25] <slangasek> either it's a kernel bug or I've worn out my fan in the past 6 months :)
[20:25] <stgraber> laptop going from 60C to 100C in 5 minutes, then triggering emergency shutdown ...
[20:26] <hallyn> doh
[20:26] <stgraber> I have a "watch -n1 cat /proc/acpi/ibm/thermal" running on my external monitor, as soon as I see it reach 98C I usually start killing kvms :)
[20:27] <slangasek> hah
[20:27] <stgraber> gets down to 60-70C really fast after that :)
[20:32] <jjohansen> sadly the better we make use of the cpu, the more likely this is to happen
[20:32] <jjohansen> not saying there isn't a bug here,
[20:50]  * jjohansen -> lunch
[20:58] <kirkland> stgraber: interesting, i hadn't tied the heat to my use of lots of kvm's yet;  thanks for the pointer
[21:00] <stgraber> kirkland: today with AC/heating fighting at the office (new building ...) just starting an ubuntu desktop install would get my laptop to 100C
[21:01] <kirkland> stgraber: wowsers
[23:48] <lrf0808_> Hello!