#ubuntu-kernel 2006-03-06
<BenC> .git/info/refs maybe needed editing too
<BenC> not sure
<genstef> hi
<genstef> can you please include cs5535audio in the default config as module?
<BenC> don't see that module
<genstef> in alsa->pci
<BenC> yeah, I know where it would be, but it's not in the kernel source :)
<genstef> #ubuntu-kernel
<genstef> oops, sry
<genstef> BenC: :((
<fabbione> hey BenC 
<BenC> hey fabio
<fabbione> BenC: you really want to pull the last changes from me :)
<fabbione> BenC: we got |Viagara stable to death
<BenC> ok, pulling
<fabbione> great thanks
<genstef> BenC: well, so can I add it to ubuntu externally
<genstef> ?
<zul> freaking git is pissing me off
<pappan> how do i start about if i want to fix some defects in kernel ?
<pappan> should i search in bugs.ubuntu.com and find a defect and just start working on it ?
<BenC> genstef: sure, compile it against linux-headers-2.6
<BenC> pappan: launchpad.net/malone/
<BenC> look for bugs on linux-source-2.6.15
<pappan> BenC i have to search for linux kernel ?
<pappan> sorry got some
<jbailey> BenC: ping?
<BenC> jbailey: pong
<fabbione> hey jbailey 
<fabbione> Dear Jeff.. please upload glibc. the code is in CVS upstream too. kthxbye
<jbailey> BenC: When an amd64 livecd is booted on an i386 machine, there's a message that says "Long mode not available, get a 32 bit distribution" or something like that.
<jbailey> fabbione: In CVS upstream?  You sure?  It hadn't been submitted as of yesterday..
<jbailey> fabbione: Unless I missed it in mutt.
<jbailey> BenC: Is that a kernel message?
<jbailey> BenC: Tollef thought it was, and when I grep'd the syslinux source for the message I couldn't find it.
<fabbione> jbailey: it was about 8 hours ago
<jbailey> fabbione: Cool.
<BenC> long_mode_panic:
<BenC>         .string "Your CPU does not support long mode. Use a 32bit distribution."
<BenC> from arch/x86_64/boot/setup.S
<jbailey> BenC: Thats the one!
<jbailey> BenC: Any objection to a wishlist bug that says "This is not an amd64 machine.  Please install the i386 distribution of Ubuntu." or something like that?
<BenC> I can make it a config option to customize that
<BenC> I saw the message when I tried to install amd64 on my k8 Sempron cpu
<jbailey> Nice - that could wind up going upstream.
<fabbione> i am off for a while 
<fabbione> cya later
<jbailey> g'n FAbio
<BenC> later fabio
<jbailey> Interesting.  Isn't K8 sempron a long mode processor?
<fabbione> jbailey: no night.. i am gonna stay awake for the meeting
<jbailey> fabbione: Ugh, right.  How long from now is that?
<fabbione> but i want to spend sometime with wife
<fabbione> jbailey: dunno.. a few hours.. 9?
<fabbione> or something
<fabbione> it's 02:00 UTC
<fabbione> later
<BenC> jbailey: it's a 32-bit proc with k8 extensions
<BenC> it'd be the same as running 32-bit on an Athlon
<jbailey> Ah, okay.
<jbailey> Making it configurable would be cool, though, so that we can put something in there that is a little more guiding.
<jbailey> "Athalon processors are not all amd64s.  kthxbye"
<jbailey> Do you want a Malone wishlist for this?
<BenC> already done
<BenC>  This is not an amd64 machine.  Please install the i386 distribution of Ubuntu.
<BenC> oops
<BenC>   * x86_64: Make a default config option for when amd64 is booted on i386. Set
<BenC>     our defaults to something more Ubuntu specific.
<jbailey> BenC: Thanks!
<BenC> sweet, my sparc boots without manual intervention now
<fabbione> BenC: that's due to the new udev :)
<BenC> yeah, I recompiled it to test the change, and it worked
<BenC> finally got all my machines back up
<fabbione> BenC: add deb http://www.fabbione.net/ubuntu dapper main
<BenC> with my ia64 down, I had no serial console to the sparc, so couldn't get it booted :)
<BenC> not sure what was wrong with the ia64, but it's all good now
<fabbione> udevplug that goes find /sys -name "uevent" - exec touch {} \;
<fabbione> segfaults on ia64
<fabbione> that's why no modules get loaded at all
<fabbione> and you are left with busy box
<fabbione> i can tell you :)
<fabbione> i have console on it
<fabbione> what i am not sure about is if it is a kernel or udev problem, but i will tell you later when i am back from dinner+movie
<fabbione> BenC: probably your SMP hangs on the e3k should have gone noe
<fabbione> now
<BenC> I'm starting a 6-way build, so I'll have updated kernels soon
#ubuntu-kernel 2006-03-07
<infinity> BenC: https://lists.ubuntu.com/archives/ubuntu-users/2006-February/068781.html
<infinity> BenC: ^--- Your fault, or udev's?
<BenC> hold a sec
<BenC> depends if something like "cat /dev/input/event#" worked or not
<infinity> Well, you may want to followup with the user, or ask him to report it in Malone...
* infinity really wishes we could get a Malone gateway for reportbug to post to...
<fabbione> BenC: ping?
<BenC> fabbione: pong
<zul> heylo
<fabbione> hey zul
<zul> how is it going?
<fabbione> BenC: hey dude.. usual pull from my branch :)
<BenC> ok
<BenC> zul: you got anything for me?
<fabbione> BenC: more SUN4V merges and i did bump B-D on kernel-package to fix a frigging annoying problem with sparc32 dpkg-buid... sparc64 dpkg-build..
<fabbione> kernel-package is of course already in archive
<BenC> fabbione: ok
<zul> BenC: yeah i ll email you the patch tonight
<fabbione> thanks dude...
<BenC> np, thanks
<fabbione> BenC: i also noticed a missing symbol building a scsi driver..
<BenC> sym2 scsi driver?
<BenC> oooh, yeah, I see it
<BenC> that's bad
<fabbione> you should have the message on the other chan
<zul> i almost have my quietboot patch ready for grub
<fabbione> yes
<fabbione> i saw it on sparc
<fabbione> no idea on other arches
<fabbione> but i think it's the same
<BenC> ah, it's on sparc64, but it isn't EXPORT_SYMBOL so modules can use it
<fabbione> ok :)
<fabbione> i didn't really have the time to check
<BenC> easy fix, I'll get it in
<doko_> jbailey, BenC: interesting for ia64 only. which linux-kernel-headers package shoudl be included in ia32-libs-dev? currently there is linux-kernel-headers_2.6.11.2-0ubuntu16_i386.deb
<jbailey> doko_: The word I got from the folks at HP is that newer itanics don't do ia32, and therefor we should drop ia32 compatability.
<jbailey> That's why lkh doesn'thave the multiarch stuff in it for ia64.
<doko_> so should we drop it still for dapper?
<fabbione> hmm spanking of ia64..
<fabbione> let's look at that udev/kernel boot problem
<Keybuk> which one is that?
<fabbione> Keybuk: i saw udevplug segfaulting while parsing /sys
<fabbione> the result is that no modules are loaded...
<fabbione> but i didn't have time to dig it
<fabbione> (found it yesterday)
<fabbione> Keybuk: don't worry.. i will come back to you, if the bug is udev :)
<BenC> my ia64 boots fine
* fabbione modprobes Overfiend.ko
<BenC> no segv's that I saw
<Keybuk> if it's a udevplug segfault, then it's likely a udevplug bug anyway
<Keybuk> it shouldn't SEGV
<fabbione> BenC: you told me yesterday that it didn't boot?
<Keybuk> gimme a backtrace
<fabbione> Keybuk: in a sec.. firing up console...
<BenC> fabbione: that was a hw issue it seems
<doko_> jbailey: I still leave it in for now
<BenC> fabbione: anyway I can try to reproduce?
<jbailey> doko_: Sure, I'm not fussed.  That's just why I didn't do it.
<fabbione> BenC: i am booting my box now
<fabbione> BenC: it looks like a kernel problem..
<fabbione> let me check if it is the last one
<doko_> jbailey: that would let us reduce ia32-libs to a more sane size
<BenC> does ia64 need to bufforce udev?
<BenC> need the
<fabbione> BenC: no i don't think so
<fabbione> the patch was for alpha/sparc/hppa
<BenC> great, my ia64 doesn't appear to be rebooting
<fabbione> it's kernel bug
* BenC wonders if it suffered the sym2 bug he just fixed in sparc
<fabbione> introduced between -15- and -16-
<fabbione> nope
<fabbione> it's parsing /sys makes baby jesus cry
<fabbione> i am taking a trace now
<BenC> is there a kernel message?
<BenC> wow, ia64 has too man registers
<BenC> any idea what file it is?
<fabbione> BenC: see /msg
<BenC> can you run lsof and see?
<fabbione> there is also a new warning during boot i don't like
<fabbione> ACPI: PCI Root Bridge [PCI0]  (0000:00)
<fabbione> kernel unaligned access to 0xe0000040fffcfb44, ip=0xa000000100303581
<fabbione> kernel unaligned access to 0xe0000040fffcfb7c, ip=0xa000000100303581
<fabbione> kernel unaligned access to 0xe0000040fffcfbb4, ip=0xa000000100303581
<fabbione> kernel unaligned access to 0xe0000040fffcfc04, ip=0xa000000100303581
<fabbione> ACPI: PCI Root Bridge [PCI4]  (0000:80)
<fabbione> i didn't see it before
<fabbione> i only have busybox here
<BenC> acpi has always been broken on my ia64
<fabbione> ok
<BenC> it actually always oopses and disables the IRQ
<fabbione> i can probably get to console
<fabbione> if there was a frigging find in busybox...
<BenC> let me run out to the barn and see what's on my screen
<fabbione> the scsi driver loads fine..
<BenC> sorry fabio, mines actually booting fine with -16
<BenC> I forgot that if someone is on the phone, I lose wireless to the barn
<zul> fabbione: busybox is quiet easy to modify...i have done it before..:)
<BenC> I need to get a 5.8ghz cordless phone
<fabbione> zul: i know.. that's not the issue..
<fabbione> BenC: hmm ok
<BenC> fabbione: pull/push from your repo
<zul> ah
<fabbione> BenC: what kernel?
<fabbione> BenC: i am with itanium-smp
<BenC> fabbione: one I just built, itanium-smp
<BenC> what scsi driver do you use?
* fabbione modprobes again Overfiend.ko
<BenC> it may be related to the driver's sysfs support
<fabbione> YOU SHOULD ALL DIE
<BenC> rmmod Overfiend
<fabbione> it's sym53c8xx
<fabbione> eheh
<BenC> rm -f /lib/modules/`uname -r`/misc/Overfiend.ko
<fabbione> but i am getting there to a trace
<fabbione> getting there
<fabbione> stracing on 9600 bps console is SLOW
<BenC> strace -o temp, then tail :)
<fabbione> there is no tail in busybox i am afraid
<fabbione> not the one for initramfs
<BenC> ah
<fabbione> oh craptastic
<zul> hell ill just send the patch now...BenC you have new email...you bastard
<fabbione> BenC: did you build your kernel from git?
<BenC> fabbione: of course :)
<BenC> zul: thanks biatch
<fabbione> BenC: that might be why
<fabbione> i think the bug is in the scsi driver
<BenC> fabbione: because our git repo is the almighty accumulation of stability? :)
<BenC> well, sym2 is updated in our repo
<BenC> give it a go
<fabbione> yeah
<zul> BenC: no problem..
<fabbione> nope
<fabbione> but now i have a strace
<fabbione> open("/sys/class/misc/efirtc/uevent", O_WRONLY <unfinished ...>
<fabbione> +++ killed by SIGSEGV +++
<BenC> efirtc, hmm
<fabbione> testing git now
<fabbione> time to build, etc,
<BenC> EFI time service
<fabbione> yeps
<BenC> nothing funny in the module
<BenC> efirtc is built-in
<BenC> tickling the file on my system doesn't cause any problems
<BenC> echo 1 > /sys/class/misc/efirtc/uevent
<fabbione> let me try with git
<Keybuk> BenC: I think udevplug writes "poke" to uevent files, not "1\n" ;-)
<Keybuk> jbailey probably would rather it wrote "does this tickle? he he he he"
<BenC> hehe, I tried and accidentally typed "poker" :)
<fabbione> BenC: ehe
<remon> good afternoon
<remon> I've a question about an alsa driver, but I think it's also related to the kernel (2.6)
<remon> the echoaudio driver is in the alsa-driver package from 1.0.8rc2, but not included (don't know for some specific reason) in the kernel source. It would be lovely if the ubuntu kernel are compiled with the echoaudio drivers included too!
<fabbione> remon: please file a wishlist bug on malone. http://launchpad.net/malone
<fabbione> component: linux
<remon> fabbione: thanks, will do so! 
<remon> (trying now myself to build an ubuntu kernel with the echoaudio driver added to the kernel source, does it help if I report the results? )
<fabbione> it helps if you provide a non intrusive patch
<remon> fabbione: I'll see if I can make one, if it works of course.....
<remon> hmm, I'm having a bit trouble with using launchpad: "No revision control details recorded for 2.6.15 "
<remon> it seems the linux kernel aren't (yet) managed by launchpad ?
<zul> i think you might want linux-source
<remon> zul: thanks, will try that one 
<remon> I'm only able to find this one: https://launchpad.net/products/linux
<remon> and there are bug reports etc, but for some reason it complains with the above message
<remon> ah, found the correct page, filling a report now! :)
<BenC> remon: file a bug and mark it for Ubuntu and the linux-source-2.6.15 source package
<remon> BenC: ok
<jbailey> BenC: Tickling is so much more sensual than poking. ;)
<zul> especially with a feather
<zul> did i just say that?
<fabbione> jbailey: what about spanking? :)
<fabbione> BenC: same story with git
<fabbione> BenC: i can trigger the error just with the echo
<jbailey> fabbione: Sure, but I think I would have trouble saying that we spanked the events out of the kernel.
<jbailey> Think gentle, soft and loving.
* fabbione goatses' events
<fabbione> BenC: it must be something local because it works on others ia64 too
<BenC> zul: I don't think your patch will help...list archives I've read show people trying to disable the check aswell, but it ends up create an eth0 with a bad mac address
<BenC> even more discouraging is that it is reported to happen even with Intel's e100 driver
<BenC> doko_: ping
<doko_> BenC: pong
<BenC> doko_: I just scyned the latest mISDN CVS snapshot, and it is the same as what I already have in the kernel
<BenC> 2006-03-02
<BenC> ftp://ftp.isdn4linux.de/pub/isdn4linux/CVS-SnapshotsmISDN-CVS-2006-03-02.tar.bz2
<BenC> missing / before mISDN
<doko_> hmpff, I trusted the Debian maintainer ;-/
<doko_> sorry
<BenC> no problem
<BenC> if there's some different config I need to do, just let me know, but I think I enabled as much as I could without conflicting with stock isdn drivers
<doko_> so the Fritz/AVM driver is still disabled, correct?
<mjg59> BenC: The sky2 module seems to be missing from the udebs?
<doko_> BenC: which compiler do you use to build parisc64 kernels?
<BenC> doko_: hppa64-linux-gcc, IIRC
<BenC> I think the package is gcc-hppa64 or something
<heatxsink> hello all
<heatxsink> hi FireRabbit 
<BenC> mjg59: ok
<FireRabbit> hi
<heatxsink> are there any plans on including the lastest bluez kernel patch in any of the 2.6.15 ubuntu kernels?
<mjg59> BenC: Which is the driver for the new Macs, so it would be nice :)
<BenC> ok :)
<BenC> heatsinx: Already done, will be in the 17.24 upload, which will happen in about 30 minutes
<heatxsink> WHAT?
<heatxsink> BenC:  awesome!!!!!!!!
<mjg59> BenC: Any chance you can enable EFI support? Adds 8k to the kernel.
<BenC> mjg59: sure
<BenC> mjg59: what's the config option?
<mjg59> CONFIG_EFI
<mjg59> Also CONFIG_EFI_VARS
<mjg59> Then I have a couple of patches to send you, but I need to figure out the framebuffer stuff first
<BenC> ok, it wont be in 17.24, but I have it already in for 17.25
<mjg59> Thanks
<mjg59> BenC: Why is -386 CONFIG_SMP=n?
<mjg59> It means I'm only getting one core up with the install kernel
<fabbione> mjg59: you gain nothing at install time with SMP
<fabbione> and it is safer choise to make the system boot
<fabbione> +able
<mjg59> fabbione: Uhm. Do we ship -686 kernels on the CD now?
<fabbione> mjg59: on -server yes
<mjg59> This isn't a server
<fabbione> don't think so on desktop
<mjg59> So an installed system won't end up with SMP. Hmm. That seems less than ideal.
<fabbione> it was the same as warty/hoary/breezy
<fabbione> there is no way to stick another kernel on the CD
<mjg59> But we could shift the -386 kernel to be SMP now
<mjg59> Since there's no performance hit
<mjg59> But there /are/ an increasing number of dual-core systems on the market
<mjg59> Hmm. It's slowed right down. I wonder why.
<mjg59> I suspect overheating, but it's hard to tell...
<mdz> we've had problems in the past with SMP kernels on UP systems; I think we ought to wait until after dapper
<fabbione> mjg59: even if we have SMP on, HT is disabled anyway
<mjg59> fabbione: No, real dual-core systems
<fabbione> mjg59: ah ok
<mjg59> Right, now I just need to reinstall MacOS so I can actually boot this...
<mxpxpod> mjg59: what machine?
<mjg59> Imac
<mxpxpod> the new one, with the dual core?
<mjg59> Yeah
<mxpxpod> sweet... so linux runs on it, eh?
<mjg59> Yup
<mxpxpod> how about the macbooks?
<mjg59> Small number of kernel changes needed. I need to figure out how to tie the framebuffer to the hardware.
<mjg59> I'll let you know when I have one :)
<mxpxpod> heh
<mdz> BenC: has there been any feedback from the community on the server kernel?
<mdz> BenC: are people using it; does it give them what they want?
<BenC> people are using it
<BenC> I've no idea if it's serving a purpose
<BenC> mdz: I've had response mostly in the way of bug reports, which have been resolved, but it does show it is getting used
#ubuntu-kernel 2006-03-08
<bluefoxicy> startkeylogger
<heatxsink> so 2.6.15-16-23 doesn't have that bluez patch?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-17.24 uploaded (\./) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<fabbione> hey BenC 
<BenC> hey fabio
<fabbione> BenC: sparc buildds are up and running
<fabbione> :)
<BenC> kick ass
<fabbione> BenC: if you can be so kind to pull/push from me i have a few |Viagara bug fixes from davem
<fabbione> RTC driver and SMP
<BenC> fabbione: btw, this time around, I kept all the ABI files for all 6 architectrures :)
<fabbione> now it is stable :)
<BenC> ok
<fabbione> yeah i saw
<fabbione> no abi changes
<BenC> great, now Sun can send me one so I can use it :)
<fabbione> i wish i could get one too :)
<BenC> if they send me two, I'll sneek one into Germany for you :)
<fabbione> eheh
<fabbione> too bad i won't be in Germany
<fabbione> my wife delivery is right at that time
<fabbione> so i might or not come..
<fabbione> it depends how i "fell"
<BenC> ah, yeah, don't want to take a chance of missing that delivery
<fabbione> yeah exactly
<fabbione> https://launchpad.net/+builds 
<fabbione> BenC: i wanted to talk to you about silo too
<fabbione> how bad would it be to move it to git? (including history)
<fabbione> tailor did convert the svn repo without a glitch
<fabbione> or gime davem and me svn commit rights? :)
<BenC> would probably be easier to convert to git
<BenC> drop it on master.k.o
<fabbione> yeah
<fabbione> http://people.ubuntu.com/~fabbione/silo.tailor.conf
<fabbione> use this tailor config to import trunk into git
<fabbione> with history
<fabbione> of course change the paths to what fits you best :)
<jbailey> BenC: *poke*
<BenC> jbailey: yo
<jbailey> BenC: FCare to join us on the call? =)
<BenC> oh crap
<BenC> give me about 2 minutes
<jbailey> *lol*
<mjg59> Hm.
<BenC> shitty...both my USB2 systems work fine with a USB2 storage device
<BenC> why can't I get a broken ehci like everyone else
<mjg59> BenC: How's your IDE knowledge?
<BenC> suitable for questions, not sure about answers though :)
<mjg59> I have a PATA controller here
<mjg59> If I drive it with ata_piix (the libata driver), it works fine
<BenC> via, intel, promise?
<mjg59> Intel
<BenC> intel, ok
<BenC> ahci is broken?
<mjg59> If I drive it with piix (the drivers/ide one), it doesn't work
<mjg59> No, this isn't a SATA controller
<BenC> ah, right, piix
<BenC> what sort of error messages from piix?
<mjg59> Or rather, it seems fine until I load ide-cd, at which point I get a spew of "failed opcode" errors and then interrupts rise at about 1000 a second
<BenC> this seems familiar...I think there's a bug like this in lp
<BenC> I can't wait for 2.6.16 when most everything is in libata
<BenC> will be a nightmare for upgrades, but it will be worth it
<BenC> can't seem to find it right now
<BenC> want to try the 2.6.16-git piix.c in dapper's kernel?
<BenC> nm, no code changes in 2.6.16-git
<jbailey> BenC: Why a nightmare for upgrades?
<jbailey> initramfs-tools ought to just load the right driver based on the PCI ID, shouldn't iT?
<BenC> the switch to libata based IDE will make things go from /dev/hda to /dev/sda
<BenC> if we had been using UUID based root and filesystem mounting all along, it wouldn't be a problem
<BenC> however, there's also initramfs support for find-root or something like that
<BenC> maybe it can help detect the changes
<mjg59> Or udev can magically make them appear as hdwhatever anyway
<mjg59> (I'm not convinced, but...)
<BenC> hmm...I wonder if udev can rename devices for PATA to a corresponding hd instead of sd :)
<jbailey> Ouch, that's nasty.
<jbailey> Is this a permanent change?
<doko> BenC, mjg59: what package/setting does turn on power management for hd's? shutting down hd's in a server install doesn't seem to make sense
<jbailey> Like will all IDE devices then be sda'ish evermore?>
<BenC> doko: not sure...
<mjg59> doko: To the best of my knowledge, no package does it
<BenC> jbailey: pretty much...I think the long term plan is to move everything to libata/PATA
<BenC> doko: do you have the -server install, or just normal ubuntu?
<jbailey> BenC: Ah, okay.
<doko> BenC: -server install
<doko> so normal install CD, but -server install, server kernel
<BenC> doko: complain to fabbione...he's responsible for much of -server stuff
<BenC> doko: dapper?
<doko> yes
<BenC> yeah, he'd be interested in that
<fabbione> BenC: nope.. it's a .15 thingy to shut down disks all the time
<doko> fabbione: ^^^
<fabbione> doko: ^^
<BenC> fabbione: are you sure it's not some default in hdparm.conf?
<BenC> or perhaps even a BIOS setting
<fabbione> even if i boot with .15 and stay at "Choose language" in d-i the disks are turned off
<fabbione> BenC: it didn't happen with .12
<fabbione> even my raid5 of 6 disks does go to sleep once in a while
<BenC> can it be overridden with hdparm?
<doko> I can confirm this, .12 didn't spin down the disks
<BenC> -server could have customer settings
<BenC> custom
<fabbione> BenC: dunno...
<fabbione> i am not a fun of hdparm
<mjg59> BenC: Probably best to figure out why the kernel is setting it...
<fabbione> mjg59++
<BenC> could be a good reason though :)
<BenC> most people want that...but I guess it could be changed for -server
<mjg59> BenC: We can set the timeout from userspace
<fabbione> no userland tricks pretty please
<BenC> can you get the hdparm output for .12 and .15 and see if there's some difference?
<fabbione> BenC: yes i think i can
<fabbione> BenC: but not right away
<mjg59> But by default, the kernel ought to be leaving them runnning
<BenC> then I can track down in the kernel
<BenC> np, just email it when you can
<fabbione> BenC: i also got hints from elmo about -server kernel
<fabbione> BenC: like using a more sane deadline scheduler by default
<BenC> looks like we'll be getting a powerpc-pseries kernel back, BTW
<BenC> IBM is offering to test it for us
<fabbione> ah nice
<fabbione> ask benh for a config
<fabbione> he has access to one
<BenC> I wish we could get someone to get mkvmlinux+oldworld boot working again too
<fabbione> why?
<fabbione> BenC: you could ask sven luther
<fabbione> but that would also mean shipping 20 CDs for powerpc
<BenC> uh, heh, might pass
<fabbione> one for each possible arch/subarch/underarch combination
<fabbione> :P
<BenC> don't forget the uberarch's
<fabbione> ehe
<jbailey> Are there any oldworld systems that people still care about?
<jbailey> I thought you had to go back quite a ways to find them.
<BenC> infinity claims he has a G3 that needs oldworld boot
<BenC> but I don't think he cares enough about it to get it working :)
<bluefoxicy> Can somebody give this bug a proper looking at and set appropriate status and severity so it gets assigned faster
<bluefoxicy> https://launchpad.net/distros/ubuntu/+source/linux-meta/+bug/32072
<bluefoxicy> kernel NULL pointer dereference in 2.6.15-14-amd64-k8
<bluefoxicy> don't know if it was found and fixed by -17
#ubuntu-kernel 2006-03-09
<Mez> aq: you tried the daily kernel?
<aquarius> In a bang-up-to-date dapper, I don't seem to have the bcm43xx module, but CONFIG_BCM43XX=m in /boot/config-2.6.15-17.386. Have I done something wrong?
<aquarius> what's a daily kernel?
<Mez> see topic
<Mez> ah
<Mez> they dont have a recent one
<aquarius> I don't understand how /boot/config can say it's a module but the module not be present
<Mez> aquarius, what kernel? -386? -686?
<aquarius> -386
<Mez> BenC is the guy to ask. ... lol
<Mez> I'm just checking why I have it
<aquarius> BenC: ping?
<aquarius> BenC: Kamion says the following is broken in latest dapper kernel:
<aquarius> Kamion obj-$(CONFIG_NET_BCM43XX)       += bcm43xx/
<aquarius> Kamion from drivers/net/wireless/Makefile
<aquarius> Kamion that needs to be CONFIG_BCM43XX now
<infinity> BenC: I could test OldWorld booting, but I've always just used BootX from MacOS (ever since quik and I discovered we had irreconcilable differences), so I've never much cared.
<BenC> does BootX from MacOS boot the standard vmlinux kernel file?
<mjg59> Awh, I miss quik
<mjg59> And the fact that my oldworld machine had no graphics driver in the firmware
<mjg59> Actually, I don't
<heatxsink> hello all, which version of the kernel are those Bluez patches in?
<infinity> BenC: Yes, I only build the one kernel, I don't do anything wonky.
<infinity> BenC: Though, I've never tested an Ubuntu kernel on the machine.  I should probably try that at least once, to satisfy curiosity and see if it works.
<infinity> BenC: (It's just running my own build of vanilla 2.6.15.4 right now)
<BenC> infinity: if it boots the prebuilt kernel, then it should be ok
<BenC> heatxsink: 17.24
<zul> heylo
<heatxsink> BenC:  is tha twhat I have now?
<heatxsink>  2.6.15-17-686
<BenC> I have no idea what you have
<BenC> looks like it
<heatxsink> WOOT
<heatxsink> BenC:  how would I confirm it?
<BenC> uname -a
<heatxsink> so the 17 = 17.24?
<BenC> yeah, 17.24 was the first -17
<heatxsink> oops
<heatxsink> haha
<psusi> man... I still can't quite wrap my head around gitk
<BenC> don't think I could use gitk...I just use the git-core tools
<BenC> oh, gitk is that graphical thingy that tries to make sense of all the clone/merges for trees and stuff
<BenC> yeah, that's a bit too much information :)
<psusi> yes
<psusi> if I just do a cg-log -c, that's nice for linear development, but whenever there's a merge, the commit just says merge from xxx
<psusi> well, WTF got merged in?
<psusi> heh
<psusi> so I fire up gitk to see what sort of patches were in that branch that was merged
<psusi> but all the forks and merges make a rather complex graph that is hard to follow
<psusi> I think I'm starting to get it sorted out though
<Mez> BenC, the kernel should use bzr ;)
<BenC> Mez: when Linus uses it, I will :)
<Mez> ;)
<psusi> is there some easy way to throw emacs into the correct code style mode for the kernel?
<tiefox> why the new version of the kernel, 2.6.15-17 does not have the bcm43xx wireless drivers?
<psusi> hrm... cg-diff -c fails because it can't find gawk... bug?
<crimsun> sounds like a missing depends on gawk, since we have mawk by default
<psusi> yea... I noticed, we have mawk... wonder why cg doesn't just use that?
<psusi> especially since cg-log -c can colorize without gawk
<mxpxpod> what heppened to the bcm43xx module in the kernel?
<mxpxpod> s/heppened/happened/
<mjg59> mxpxpod: It fell out by accident
<mjg59> Should return soon
<mxpxpod> :(
<mjg59> The config name changed, but Ben forgot to update the makefiles to match
<mxpxpod> so, 18.25 will have it, eh?
<mjg59> Should do
<mxpxpod> how soon?
<mjg59> Not sure
<mxpxpod> darn
<bigon> Hi, I have bugrepported https://launchpad.net/distros/ubuntu/+bug/23010 for about 5 mouths, is it possible that this problem comes from a broken kernel header under ppc?
<psusi> ok, so I have my kernel patch... I committed it to my local git tree, and git-format-patch'ed it... now how do I post it to lkml?  I don't want to just paste it into thunderbird right?
<mjg59> Hmm.
<mjg59> I'm onto 32 kernel builds now.
<cjb> psusi: Thunderbird is the mailer least likely to not screw up your patch, I'm afraid.
<cjb> You do want to just send it inline, with a changelog entry and Signed-off-by:, so pasting it would work if your mailer were sane, but it's difficult to get Thunderbird to leave preformatted text alone.
<psusi> what if I just attach it?
<psusi> is there an easy way to get an old fashioned mail program set up so I can just pipe it there?
<cjb> psusi: Patches are preferred inline, not attached.
<cjb> You can just use mail(1), if it's installed.  Send a mail to yourself first to check it comes out okay.
<psusi> don't have it installed
<psusi> but it looks like I got thunderbird to not munge it
<psusi> I can't believe email still has these problems
<psusi> you are't supposed to send lines longer than 72 chars because the readers don't rewrap, but then sometimes you want to so data doesn't get munged.. 
<psusi> I don't see why you don't just let the reader wrap at 72 if it wants to, at the user's option...
<cjb> Yes.  Patches should be MIME attachments, really.  There's nothing problematic about it.  But people like to comment on them, and when there are comments we want them to be inline and quoted properly etc.
<psusi> mime disposition = inline?
<psusi> looks to me like when it's attached, thunderbird marks it as inline, so it shows inline when read, and is quoted properly when I reply
<cjb> psusi: Mime disposition is just a hint to the mailer; not all mailers will present an attached patch as inline.
<psusi> if it says it should be presented inline, and is text/plain, then wouldn't it be broken not to do so?
<psusi> even for plain text readers like mutt
<cjb> I think it may be the case that mutt presents it inline, but then doesn't include it in a quoted reply when you press 'r'.  I think the real reason this stuff doesn't change is that Linus uses pine, and pine is more broken than most mailers about it.
<psusi> omfg, you're kidding?
<psusi> how the hell can anyone use that pile of shit?
<psusi> at least, anyone who gets more than 10 message a day?
<cjb> I honestly don't know.  :)
<cjb> He uses a text editor (microemacs) that's a decade or two old, too.
<psusi> seriously.... unless they've rewritten it since I last used it, pine chokes on large mailboxes because it has to read and parse the entire spool when you open it every time
<psusi> does it even handle threading?  heh...
<cjb> I think it's possible to achieve everything people want with pine.  I just don't think it's *fun*.
<psusi> or easy
<psusi> or efficient
<psusi> pine would shit itself if it tried to open my lkml mailbox... 23,019 messages that take up a bit over 100 MB
<dilinger> hm
<dilinger> wtf?
<dilinger> kernel packaging no longer includes patches?
#ubuntu-kernel 2006-03-10
* #ubuntu-kernel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* lamont grumbles at the lack of a linux-image-2.6.15-16-amd64-generic_2.6.15-16.23_i386.deb
<crimsun> it's actually suffixed with _i386?
<crimsun> (i.e., there's http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.15/linux-image-2.6.15-16-amd64-generic_2.6.15-16.23_amd64.deb)
<lamont> BenC: your kernel hates me
<BenC> lamont: what's up?
<lamont> BenC: linux-image-2.6.15-16-amd64-generic_2.6.15-16.23_amd64.deb panics very early during boot, in pci_mmcfg_read
<BenC> lamont: why can't you just dpkg-deb --extract, dpkg-deb --control, change the Arch, and dpkg-deb --build it back :)
<BenC> what sort machine
<lamont> and, interestingly, 2.6.12-10-amd64-generic dies (2.6.12-10.28) with a segv during initramfs
<lamont> that's what I did do to create the _i386.deb that is installed...
<lamont> HP pavilion a1130n
<lamont> OTOH, since 2.6.15 has that motherboard's double-time issue from 2.6.12 fixed for i386 as well as amd64, I'm now running an i386 kernel
<lamont> which boots, (woot), and also eliminates that pesky issue wherein the scanner didn't work (PSC 2510, ioctls had some issues with 32-user/64-kernel)
<lamont> whcih may or may not be fixed in 2.6.15 - can't check when it doesn't boot
<lamont> BenC: having a bootable system again (that correctly keeps time), makes it so that I'm much less grumbly - I'll try -17.24 tomorrow evening, I expect
<lamont> I'll also work on getting my amd64 dev/test machine booted
<BenC> ok
<BenC> 2.6.15 is working on my Athlon 64, so that's about as much testing as I've done
<mxpxpod> BenC: ping
#ubuntu-kernel 2006-03-11
<mxpxpod> mjg59: any word on when 18.25 is going out?
<mjg59> mxpxpod: Nope
<mjg59> Up to BenC. The fix for bcm43xx is in git, though
<mxpxpod> hrmm
<mxpxpod> it would suck to have had bcm43xx up until now and then not have it for release
<mjg59> It'll be there for release
<mxpxpod> ah, cool
<mxpxpod> maybe I'll just use the last kernel release until the next comes out
<mxpxpod> thanks mjg59
<mjg59> BenC: Just sent you another Mac patch
<mjg59> That should be everything needed to get the installer running
* cjb wonders how crazy it would actually be to have an inotify watch over every directory under /.
<Mithrandir> cjb: takes forever to set up, but it'd work.
<zul> heylo
<fs> fabbione: ping
<fabbione> fs: pong?
<fs> fabbione: hey =)
<fabbione> yo
<fs> I have a question regarding the amd64 kernel flavours
<fabbione> -> BenC :)
<Mithrandir> hi fs
<fabbione> i don't maintain kernel anylonger :)
<fabbione> fire it up tho
<fs> I see you dropped the smp flavours, and implemented an smp-noop-locking patch?
<fabbione> yes that is correct
<fs> I just wanted to know what the upstream status of this is, I hear it was rejected?
<fs> what are the future plans regarding it?
<fabbione> afaik there were 2 patches
<fabbione> one that was dropped
<fs> we are thinking about dropping some flavours too
<fabbione> and one that has been considered recently (that we include)
<fabbione> but i have no idea what's the status
<fs> the i386 one in -mm?
<fabbione> you need ask Ben for details..
<fs> hey Mithrandir :)
<fs> btw :)
<fabbione> that's all i know
<fs> ok
<fs> BenC: ping
<fs> :)
<fs> fabbione, you still do ocfs2 stuff?
<fabbione> yes
<fabbione> i still do ocfs2 and GFS
<fs> good to know :)
<fabbione> ocfs2 is upstream now
<fabbione> so you get it with .16
<fabbione> GFS it's in -mm afaik
<fabbione> GFS2
<fabbione> at least the DLM is in
<fabbione> not sure about the FS
<fabbione> but there is a git tree on kernel.org
<fs> yeah 
<fs> talking of git, what happend to the ubuntu-2.6 tree? i get errors when I try to pull lately
<fabbione> it's there...
<fabbione> you might need to clone it again
<fs> lot's of unknown remote refs
<fabbione> clone it
<fs> ok 
<fs> well that will take a while
<fs> ok thanks for the info so far, I'll wait for BenC to show up :)
<fabbione> ok
<fabbione> no problem
* BenC is here
<zul> yay! :)
<mjg59> BenC: I may have a new ACPI IDE patch for you, after I've tested it
<BenC> mjg59: ok, got all your other patches too
<BenC> trying to get them in before today's upload
<mjg59> Rock, thanks
<fabbione> BenC: please no ABI bump today
<BenC> hopefully not
<BenC> I have all the ABI's from 17.24 anyway, so it wouldn't hurt much :)
<fs> BenC, what is the upstream status of the smp-alt patch for amd64? we are pondering to add it to debian kernels too
<BenC> not upstream as far as I know
<BenC> may be in -mm, but haven't checked
<BenC> oh wait, amd64, is no where but here (exclusive!)
<BenC> I've been meaning to send it back to the x86 alt-smp author
<fs> yeah the x86 one is in mm
<fs> BenC, so it was not submitted yet? is it a port of the x86 alt-smp patch?
<BenC> yeah, it's almost exactly the same as the x86 one
<BenC> just a few extra's since some of the semaphore stuff on x86_64 is code blocks instead of just single instructions
<fs> ok thanks :)
<koke> hi! it seems the problems with headphone detection on snd-powermac are still there. is this a know issue?
<mjg59> BenC: We should consider disabling hwcrypto in ipw2200 by default - it's flaky
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-17.25 uploaded (Nigeria release) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<BenC> mjg59: mactel patches didn't make it to 17.25, since I needed to get things out quick for bcm43xx and niagara
<BenC> but it will be in there in two days when I upload again
#ubuntu-kernel 2006-03-12
<zul> heylo
<mjg59> BenC: Ok, no problem
<purpleidea> the newest updates to dapper flight 4 seem to WORK with a brand new inspiron 9400 laptop and SMP is available. don't know if it was you, but if you want me to send you some lovely debugging output, let me know, or i'll also be on the laptop testing team
<crimsun> meaning kernel 2.6.15-17.26?
<purpleidea> actually .24 although i hadn't played with it in a week or so because of exams so i'm not explicitly saying .24 was the first to work. but it hadn't been for a lot of people for a while
<airlied> fg
<airlied> doh..
<airlied> fg
<Lathiat> Hi guys - can anyone clarify the reason for the 2/2 address space split?
<crimsun> https://lists.ubuntu.com/archives/kernel-team/2006-February/000678.html
<Lathiat> thanks
<Mithrandir> BenC: 27862 ; why can't it be built-in?
<BenC> because having them built-in is against our whole modular kernel design
<BenC> if it's built-in and it is causing a problem, it cannot be unloaded
<BenC> or blacklisted
<Keybuk> if it's not built-in, it can't be loaded automatically though
<Keybuk> which means we force-load it through things like /etc/modules
<Keybuk> which ignores the blacklist
<Mithrandir> and on the live cd in a way which means there's no way around it.
<Mithrandir> it's not a problem to just load it, I'm just not sure it's a good idea
<mjg59> BenC: So the 2+2 split seems to be breaking other stuff as well
<mjg59> I think we ought to go back to 3+1 and then try to fix hibernate
<BenC> yeah, I'm doing that for 18.27, since it's an ABI bump anyway
<BenC> Keybuk, Mithrandir: building it in is, IMO, worse than it not loading, or having to force load it through /etc/modules
<BenC> there are a lot of mac sound chips that aren't really supported, and loading it causes all kinds of weirdness when it attempts to access false gpio's
<BenC> it doesn't really make things really bad off when it loads under those chips, but it looks really bad (lots of stuff in kern.log) and would be impossible to get rid of if built-in
<mjg59> BenC: Looks like getting the smart battery driver in was a good move - the Macbooks have them
#ubuntu-kernel 2007-03-05
* Starting logfile irclogs/ubuntu-kernel.log
<Mithrandir> BenC: ps3-kboot> uh, another copy of the linux kernel in the archive?
<varkatope> can i ask for a specific kernel driver module availability in feisty here?
<cjwatson> Mithrandir: it's necessary unfortunately - kboot doesn't work with 2.6.20 yet
<cjwatson> Ben tried fairly hard to make that work
<Mithrandir> cjwatson: hm, but it doesn't seem to actually build the kernel at any point?
<Mithrandir> sorry, it does.
<Mithrandir> I guess he'll want this in main too?
<cjwatson> yeah, it's needed for PS3s
<cjwatson> I think Ben's still working on making it work with 2.6.20
<Mithrandir> ok.
<Mithrandir> I'm not happy with it, but I see the point of it not working with 2.6.20 yet.  I wonder if having a policy that such packages should build-depend on the current linux-source and then ship the patches to go down to the version they want, then building with that would make sense or just be utterly insane.
<cjwatson> I think the patch might well be about as big as the kernel, so I don't see the point in this kind of case
<cjwatson> the only result of that would be that it would be a lot less comprehensible
<Mithrandir> extra incentive to get stuff working for the latest kernel because of the pain involved. :-)
<cjwatson> I understand the incentive, but I think the method is misplaced
<varkatope> where to ask/look if a specific chipset is supported by the kernel of feisty fawn?
<cjwatson> varkatope: look> apt-get source linux-source-2.6.20, debian/config/wherever; ask> bug report on linux-source-2.6.20
<varkatope> cjwatson: thx
<gilligan_> hi
<doko> bug 89851
<doko> <fabbione> doko: the heartbeat problem might be a missing kernel header..
<doko> <fabbione> ia64: checking for linux/icmpv6.h... no
<doko> <fabbione> i386: checking for linux/icmpv6.h... yes
<doko> <fabbione> doko: ^^ this one is the problem for sure.. you can see in the i386 build log that it then builds IPv6addr
<fabbione> doko: i said probably.. you need to check the header packages
<doko> on the list, but low prio
<gilligan_> http://gilligan.neuecouch.de/nl_socket.txt <-- could someone do me a favor and check if he can see what the problem with this simple netlink socket test is ?
<gilligan_> I don't get it
<BenC> Mithrandir: has to be a certain version. The 2.6.20 can't kexec kernels
<zul> besides sometimes its not trivial to go one from one version to the next.
<zul> there is a meeting today isnt there?
<gilligan_> hm.. still looking for some help on a netlink problem.. anyone?
<zul> hah...http://lists.xensource.com/archives/html/xen-devel/2007-03/msg00166.html
<zul> 13 year olds..
<Keybuk> zul: why does Xen need such an old kernel version?
<mjg59> Because Xen isn't in the main kernel tree?
<zul> Keybuk: Xensource doesnt even track the latest kernels and the one we have is from redhat
<Keybuk> right, I just mean has there been some known difficulty updating it to 2.6.20 or is it just that nobody's tried yet
<zul> Keybuk: there is some dificulty because of the workqueue changes and the paravirt-ops changes but opensuse only ported to 2.6.20 very recently and its not really tested yet
<zul> quintela from redhat is still in the process of porting 3.0.3 to 2.6.20
<Keybuk> *nods*
<zul> and Im in the process of porting xen-unstable from 2.6.18 to 2.6.21
<Keybuk> the reason that check is there is because we had some problems getting the feisty udev to work with older kernels than 2.6.19
<Keybuk> that could be fixed now though
<zul> cool
<Keybuk> I'll investigate and see whether we can't drop that back to a minimum 2.6.17 dep
<zul> that would be nice for the xen users who still want to use their compiled kernels as well
<Keybuk> I'm not sure how broken feisty would be with an older kernel though
<Keybuk> things like apport might not work, and may fail badly
<zul> true..Im hoping for feisty to base it off the proper kernel
<zul> mjg59: I doubt Xensource is looking for inclusion now
<kylem> xensource are <censored by the CoC>
<zul> heh...a bunch of <censored by the CoC>? :)
<kylem> jeremy has been doing a decent job getting xen-paravirt up to snuff.
<kylem> i'd be happy to do a backport in my spare time if you need help.
<zul> kylem: sure I was toying around with it this weekend
<zul> *sigh* https://launchpad.net/bugs/89665
<gilligan_> wow..what an idiot
* Starting logfile irclogs/ubuntu-kernel.log
<Kazz> Hey, does anyone know if there are problems with LDM (for accessing windows dynamic disks)?  It's part of the kernel, so I hope you don't mind me asking here...it seems to be compiled in, but it doesn't seem to be doing its job.
<Kazz> It wasn't working with 2.6.17-10-generic and it's still just showing everything as 1 SFS partition with -11 too when it should be showing the individual partitions inside of the "dynamic disk".
#ubuntu-kernel 2007-03-06
<crimsun> Kazz: please use https://answers.launchpad.net/ubuntu/+addticket instead.
<mjg59> crimsun: Have you had a chance to look at the Macbook patch?
<crimsun> mjg59: I just stepped off a plane, so no, but I've merged about 99% of the patch_realtek/sigmatel fixes. I'll look at it right now.
<mjg59> crimsun: Heh, no problem
<mjg59> crimsun: Thanks!
<mjg59> crimsun: Other than the wireless, it's pretty much the last thing on the todo list for that hardware
<crimsun> great
<Kazz> crimsun: Alright, thanks.  I'm gonna' try installing the 32 bit version of Ubuntu first, and I'll keep trying to figure out where the problem is.  If I still think it's in the kernel, I'll try that. :)
<varkatope_> hi
<mgalvin> crimsun: gigantenormous you say? supertasticful!
<mgalvin> crimsun: -9.16 did not fix the sound problem but i will be sure to try out the latest kernel as soon as it is ready
<mgalvin> crimsun: on the MBP that is
<zul> crap its freaking cold
<zul> feels like -40C with the windchill
<kylem> ... yeah.
<zul> thank god I had the car today
<kylem> cjwatson, are we able to get the country choice out of ubiquity/d-i in the installed system somehow?
<cjwatson> kylem: best to look at the locale
<kylem> cjwatson, darn. that doesn't really strike me as an effective way of determining it.
<mjg59> kylem: We actually want this information for modems as well
<kylem> perhaps we could store it somewhere?
<mjg59> Having it stored centrally would make sense
<mjg59> Then have scripts parse it
<mjg59> Makes it easier to deal with moving countries
<mjg59> Though ISTR that there's a spec for APs to tell cards what region they're in
<cjwatson> locale as in /etc/default/locale - it's not *that* hard to parse
<cjwatson> I could dump it somewhere else butt you'd still have to deal with (a) upgrades and (b) people moving and forgetting to change it
<cjwatson> s/butt/but/
<kylem> uhm.
<kylem> how is what language someone speaks a good indication of where in the world they are?
<kylem> or am i missing something really obvious...
<kylem> https://beta.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/90094
<kylem> perhaps network-manager should be extended, dunno.
<kylem> it's really moronic for this to be a module option instead of a WEXT.
<cjwatson> kylem: because the installer gives them a map of the world and tells them to select a place on it and then uses that to construct the locale?
<cjwatson> (in ADDITION to their language)
<cjwatson> ok, there's crap like pt_PT vs. pt_BR. How about their timezone instead?
<cjwatson> you'd have to map it to country but it's not too painful as long as people use the city zones (the installer does) rather than the generic ones like EST
<cjwatson> that's about all I can offer you
<kylem> hrm.
<mjg59> cjwatson: How about just dumping the point they clicked on somewhere?
<mjg59> cjwatson: We need a separate file containing it, in any case - in theory it's something that people need to change when they move the machine between countries
<kylem> mjg59, i think this is slightly more involved than i initially thought.
<lfittl> does anybody have an idea why lvm persistent major device numbers are ignored?
<varkatope> hi
<mgalvin> for future reference how does one capture a kernel oops to a file (or which file is the log stored in)? ...so i don't have to take screen shots like a fool :-/
<mjg59> mgalvin: If they've crashed the machine, they won't be in a file
<mgalvin> mjg59: in my case it does crash the machine
<Lure> mgalvin: dmesg > file ?
<mgalvin> ah, easy enough great thanks
<mgalvin> it was the rtl8180 oops which is hopefully fixed now... but good to know, thanks again
<mjg59> No, not fixed yet
<mjg59> But extra dumps probably don't help
<cjwatson> mjg59: the point they clicked on is adequately represented by the city as encoded in the timezone; I don't think that any finer resolution is useful.
<cjwatson> mjg59: also there exists reasonably well-presented UI to edit one's timezone which is a fairly natural thing to bother changing when you move countries, at least assuming you move timezones as well
<mgalvin> mjg59: well the commit message indicated it would at least not crash the machine (although wireless still does not work)... so this would at least give me a bootable system correct?
<mgalvin> i don't use the wireless as this is my desktop machine with the issue
<cjwatson> people won't bother changing things they don't have an incentive to change; "desktop clock wrong" is reasonable incentive
<mgalvin> so not a big deal (for me at least) past that point
<mjg59> cjwatson: Ok, that's probably fair, yes
<mjg59> It also means we already have a UI for that
#ubuntu-kernel 2007-03-07
<jack> hey is it ok for me to ask a non-dev question here?
<jack> I've tried #ubuntu :P
<varkatope_> hi
<lfittl> zul, I have an urgent xen problem, on one of my remote servers, xen keeps changing the mac address of eth0 to fe:ff:ff:ff:ff:ff, its an amd64, do you have an idea how to stop xen doing that?
<Mithrandir> eth0 in the domU or dom0?
<lfittl> dom0
<Mithrandir> hm, weird.
<Mithrandir> no idea, sorry.
<abogani> Someone can clarify to me one (stupid) thing about restricted modules?
<TheMuso> c/
<mjg59> kylem: 78288 looks like an issue with the IRQ handler, or something. 
<mjg59> But we'll want a 2.6.19 dmesg
<kylem> yes, yes it does.
<mjg59> Given that the chipset is getting IRQ 16, and it's IRQ 16 that's blowing up
<mjg59> So doesn't /sound/ like interrupt routing
<mjg59> Hm. But irqpoll works.
<mjg59> Gah. It'll be some trivial change in ata_piix, or something
<kylem> hm.
<kylem> i have the same thing, but no love with irqpoll.
<kylem> acpi=off works.
<mjg59> Gah.
<mjg59> What interrupt do you get without acpi?
<kylem> so i figured it was just proto hw bugs.
<zul> grr...kernel-package
<varkatope_> hi
#ubuntu-kernel 2007-03-08
<zul> wish us luck..
<Nafallo> zul: with? :-)
<dfgas> how do i upgrade to the newest kernel, i am using dapper
<dfgas> or is there a config.gz somewhere like on debian?
<pmjdebruijn> dfgas, you shouldn't use non-supplied kernel if it's not absolutely nescesary, with that said...
<pmjdebruijn> dfgas, look in /boot
<mkrufky> hello, folks
<mkrufky> i installed feisty last night... i was happy to find that certain firmware for v4l and dvb devices are now included with the distro
<mkrufky> however, there is 1 firmware image missing, that is needed for my device drivers... "dvb-usb-bluebird-01.fw"
<pmjdebruijn> mkrufky, did you already file a bug?
<mkrufky> i have received permission from DViCO for public distribution of this firmware, and it is perfectly legal for ubuntu to package it
<mkrufky> i did not yet file the bug, thought i'd jump in here and ask first
<mjg59> mkrufky: Best bet would be to file a bug with a link to the firmware and a link to the permission statement
<mkrufky> fyi, im not a user of this driver -- i am the author, and i assembled the firmware and put it onto linuxtv.org for distribution
<mkrufky> ok, i will do so.  thanks
<mkrufky> hmm, permission statement?
<mkrufky> all i have is an email from the CEO from the company saying "yeah, sure... you can host the firmware and distribute it -- no problem."
<mjg59> mkrufky: Hm. Does he say that other people can distribute it?
<mkrufky> he said that it is freely distributable
<mkrufky> did not impose any limits on WHO may distribute it
<mjg59> Ok
<mjg59> If you could quote that in the bug, that would help
<mkrufky> OK
<mkrufky> as of now, users can download the firmware using the dvb_get_firmware script included in the kernel source
<mkrufky> but i dont think that script is included in the stock distro
<mkrufky> anyway, i will file the bug, thanks
<tuxmaniac> Does all the Intel machines have the VT extension?
<tuxmaniac> I mean the modern ones.
<mjg59> Celerons don't
<mjg59> As far as I know
<kylem> mjg59, have they revved the celeron for core yet?
<mjg59> Dunno. Thought so.
<mjg59> Ah, not yet
<mjg59> June
<kylem> right.
<mjg59> http://www.vr-zone.com/?i=4657
<mjg59> Oh, Celeron M 520 might be Core
<JanC> "yay!" for useful product names...
<JanC> (not)
<fabbione> kylem: ping?
<kylem> pong
<fabbione> hey dude
<kylem> s'up?
<fabbione> can you give feisty this love: http://git.kernel.org/?p=linux/kernel/git/mfasheh/ocfs2.git;a=log;h=2.6.20_fixes please?
<fabbione> it's a set of ocfs2 fixes for .20
<fabbione> we got them from Oracle
<fabbione> and passed already their QA tests
<fabbione> already included in .21 git
<kylem> yeah, i guess so. ben's asked me to hold off uploading until he's back, but i'll queue them.
<fabbione> i am ok if you can queue them in the git repo
<fabbione> i could do it too... i am just, ya know.. lazy during holidays
<kylem> slacker.
<kylem> ;o)
<kylem> the fixes look ok.
<fabbione> yeah just make sure to grab the branch :)
<fabbione> thanks a lot dude
<kylem> np.
<kylem> enjoy the rest of your holiday.
<fabbione> we might need some GFS/GFS2 updates too.. but i will check on monday. Given that RHEL5 is going out next week, i need to see what they are releasing as stable
<fabbione> and sync
<fabbione> thanks.. i am indeed having some fun
<ivoks> is there any chance to get updated 3w-9xxx in dapper?
<ivoks> i've sent patches to mailing list
<ivoks> (i'm just wondering if that is possible at all)
<kylem> ivoks, possibly in -proposed. i think i have your patches queued in the next 'round of updates.
<ivoks> oh, great
<zul> afternoon...false alarm..:)
<mkrufky> mjg59: re: missing firmware....  what should i file the bug against?
<mjg59> linux-source-2.6.20
<mkrufky> ok, thanks
<mkrufky> Bug #90723 filed.
<lifeless> anyone around? I've got a query about hardware suport for dell 745 hardware
<mjg59> It's a, uh, dell?
<lifeless> yeah
<mjg59> So...
<lifeless> so theres a uni that has a bunch of these machines, were running debian, a friend of mine pointed their tech guy at me
<lifeless> apparently debian hates them, fc6 runs text mode only, no networking
<lifeless> I think its the optiplex 745
<lifeless> I'm going to put them in contact with riched as an education site, but knowing if we already work would be great.
<lifeless> http://admin.utep.edu/Default.aspx?tabid=40677
<mjg59> Graphics will be vesa only right now
<lifeless> thats not the same uni, but is probably the right specs
<mjg59> Oh, no
<mjg59> They're available in either Intel or ATI form
<lifeless> oh
<lifeless> sounds like you know about them already :)
<mjg59> Ethernet should work fine in feisty
<lifeless> is it vesa for both builds ?
<mjg59> No
<lifeless> ati - vesa, intel - i900 driver ?
<mjg59> Yes
<lifeless> the installer drops back to vesa IIRC, so it should be 'just works' either way ?
<mjg59> Correct
<lifeless> thank you very much
<lifeless> think the SATA controller is supported ?
<mjg59> Should be
<kylem> holy shit, how did it get to be 6pm.
<lifeless> it comes after 5pm.
<kylem> hmm. -ECHAN.
<kylem> lifeless, i have no recollection of it being 5pm. :)
<lifeless> why does FF hate me
<lifeless> ECHAN too
<lifeless> mjg59: one last question
<lifeless> for core2duo, is the EMT64 cd the right one ?
<mjg59> amd64, yes
<mjg59> Unless you want flash
<lifeless> right
<lifeless> but these machines are fundamentally 64bit
<lifeless> cool
#ubuntu-kernel 2007-03-09
<zul> xen-2.6.20 building now :)
<lifeless> cool
<lifeless> zul: zen for fisty would be so nice.
<dfgas> are there any precompiled kernels for dapper that is 2.6.19 or better?
<dfgas> or a repo i could use for it
<Ninjai> if i installed for example ubuntu + slax dual boot....and i am right now in ubuntu and doing: chroot /mnt/sda2 for example which stands for slax partition... what things will work and which wont work ??
<crimsun> that's really difficult to know offhand, as very few of us run slax
<xNinja> ok i have slax installed and now installing ubuntu 6.10
<Nafallo> this is not really a supportchannel either :-). maybe you want to try #ubuntu or #ubuntu-CC? :-)
<crimsun> I think xNinja wants #ubuntu
<xNinja> i am there but no one answering me!
<crimsun> I'll address this question there
<xNinja> thanks
<Tm_T> Hi kids.
<Tm_T> This might go slightly OT but:
<Tm_T> "Note: You need to have CONFIG_USB_NET_CDCETHER compiled either into the kernel, or as a module, in your kernel config."
<Tm_T> And with Ubuntu kernels, situation is?
<Tm_T> I'm totally out with kernel things.
<thom> Tm_T: grep CONFIG_USB_NET_CDCETHER /boot/config-`uname -r`
<Tm_T> Aah thanks.
<thom> np
<trueg> Hi guys
<trueg> Does the ubunto kernel by default enable CD/DVD drive auto-closing?
<maelcum> hi! i have an nforce 2 chipset and the system becomes very unresponsive during heavy disk i/o. this can be fixed by giving the kernel the "noapic" boot option. can this be added to some part of ubuntu so that it sets the option for this chipset?
<maelcum> i don't think that people realize that this is a fixable problem, so a bug on launchpad will probably not get very much attention.
<maelcum> iirc, i found the fix in some dark corner of the internet, nothing you'd expect the average user to find...
<zul> maelcum: submit a bug request and it will get looked at
<maelcum> zul: ok, i did that.
<zul> thanks
<maelcum> launchpad is the least annying bug tracker i have used so far, by two orders of magnitude.
<maelcum> *annoying
<Nafallo> :-)
<lifeless> kylem: around ?
<kylem> yes.
<lifeless> I've updated bug 88899
<lifeless> its buggered right this instant, is there anything more you want from me about it at this point ?
<kylem> not really, i have no idea what the problem is.
<kylem> can you attach your /proc/acpi/dsdt?
<lifeless> sure
<kylem> thanks.
<lifeless> done
<kylem> thanks. 
<seb128> hi
<seb128> pkl_: have you looked at bug https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/87078 ?
<seb128> do you think it'll be fixed for feisty?
<pkl_> seb128: have not looked at it yet.  It may be fixed for feisty, very much depends on whether I can identify the problem :-)
<seb128> k
<seb128> I think I'll just get a new network card then
<seb128> network crashing is really unproductive, I've not close all the things I'm working on, etc every time
<pkl_> seb128: there's a number of similar bug reports for different cards.  May be a related problem, in which case similar fixes may work etc.
<seb128> pkl_: k, let me know if you need extra details
<seb128> if that's not fixed for feisty I'll get a new card ;)
<pkl_> seb128: looking at bug 76489, a similar issue is reported.  This appears to be fixed by turning off TSO ("TCP Segmentation Offload") with "sudo ethtool -K eth0 tso off".  You could give that a go, and report back.  Thanks
<seb128> pkl_: ok, will
<seb128> $ sudo ethtool -K eth1 tso off
<seb128> Cannot set device tcp segmentation offload settings: Operation not supported
<mjg59> pkl_: 8029 is a ne2k-pci
<mjg59> The fact that it manages packets at all is sort of amazing
<pkl_> mjg59: yeah, I used to have some ISA based ne2k boards...
<pkl_> mjg59: a long time ago...
<seb128> the card was working fine with 2.6.17 :p
<mjg59> seb128: Diff the driver for the two cases?
<pkl_> seb128: a number of  the drivers used to work OK in 2.6.17, and so it's not as straight forward as a diff.  Kernel changes in other parts of the kernel maybe causing problems.... 
<mjg59> Actually, it doesn't seem to use workqueues, so there's a chance that just building the 2.6.17 driver would work
<pkl_> seb128: it is probably worth diff-ing the drivers in case just in case.
<seb128> mjg59, pkl_: ok, will do that
<mjg59> seb128: You'll need to check ne2k-pci and 8390.c
<pkl_> seb128: kyle has put a note on the comment asking you to try adding "irqpoll" to the kernel command line. 
<lifeless> kylem: I think my laptops power-on power-state affects it
<kylem> it's possible
<lifeless> kylem: I had booted off battery; I've just hibernated and powered on again with the power on
<lifeless> and once it came up removed and inserted the power lead and its happy now
<kylem> whacko.
<lifeless> yahuh
<leroutier> hello
<leroutier> got a systematic kernel panic when my webcam is plugged/ uvc driver is loaded
<leroutier> on feisty with latest kernel
<mjg59> leroutier: Got a bug number?
<leroutier> nope, not reported to launchpad yet
<leroutier> let me check if not a known prob
<leroutier> hum, no luck, I can't access to launchpad
<leroutier> I'll retry later, and come back here once the bug report is done
<leroutier> dmesg with kernel traces saved
<mjg59> Thanks
<leroutier> looks like the crash is in alsa "snd_pcm" (when webcam is plugged), so perhaps interaction with "snd_usb_*"
<leroutier> I'll come back once I have a proper bug report. ++
<leroutier> mjg59, still around ?
<leroutier> Bug #90922
<mjg59> leroutier: Just heading out - someone ought to take a look shortly
<mjg59> (19:30 here, food time!)
<leroutier> oh, sorry yes, you're in UK
<leroutier> have a good lunch
<leroutier> and no hurry for this crash. it's just a webcam after all
<JanC> 19:30 = food time ?
<JanC> for me that's more around 21-22h   :)
<JanC> (people tell me I should migrate to Spain ;-) )
<leroutier> yep, I was told in spain it's more around 21h
<leroutier> hard to find a place to eat around 10PM in UK (last time I was there)
<bdmurray> BenC: Could you explain bug 57502 to me?
<bdmurray> Or rather how could I find out if another one is similar to it.
<BenC> bdmurray: Can you give me that bug# again?
<leroutier> it was 57502
<bdmurray> JMicron SATA controller
<bdmurray> and I thought you mentioned an ICH8 controller too
<bdmurray> in that bug report
<BenC> bdmurray: What did you need explaining?
<BenC> bdmurray: I just added a note about the status of dapper
<bdmurray> BenC: I was trying to figure out if 58358 might be a duplicate
<BenC> bdmurray: This sounds more like the Marvel IDE issue
<BenC> bdmurray: Similar problem, but different driver
<BenC> JMicron is fixed in stock edgy
<BenC> fixed in dapper-proposed too
<BenC> Marvell driver didn't make it into edgy, but is in edgy-proposed
<bdmurray> BenC: and the JMicron is fixed on the Live CD too now?
<BenC> and I think dapper-proposed as well
<BenC> bdmurray: JMicron was fixed in edgy well before release, so all CD's
<BenC> unless it's some new chipset, but I haven't heard of anything from my JMicron contact
<bdmurray> Okay, cool.  Do you want to update 58358 or should I?
<bdmurray> regarding testing proposed
<BenC> bdmurray: Please do, but confirm it's a Marvell (lspci should show it)
<BenC> kind of hard to test proposed if they don't have an existing install (No CD support means no install)
<bdmurray> BenC: Okay, I asked for that.  "I ended up connecting my IDE CD ROM drive to SATA controller using a converter and that works now"
<bdmurray> So he should be able to test, right?
<BenC> yeah
<bdmurray> I got a new HP laptop yesterday
<kylem> working ok?
<bdmurray> Yeah, everything seems to just work so far with Feisty.
<bdmurray> It's all intel stuff - video and wireless.
<kylem> cool.
<kylem> suspend/resume? :)
<bdmurray> Suspend yes, Hibernate had an X issue on resume
<bdmurray> I could log into vt2 and had to restart kdm
<kylem> bizarre. ok.
<bdmurray> I got a CPU softlockup once and haven't been able to reproduce it
<bdmurray> I think I might have booted with the killswitch off when I got the softlockup
<zul>  /win 16
<zul> gah...Im so ready to go home
<bdmurray> bug 58358 seems to have an Intel IDE controller
<lamont> BenC: you around?
* BenC appears
* lamont needs to be in kernel_team on rookery so that he can do good things for hppa... I promise to be good
<lamont> probably works best if you request it,  rather than me... :-)
<lamont> thoughts?
<BenC> lamont: You can send an rt request and attach my blessing :)
<lamont> ok
* lamont goes to find his rt info
<BenC> lamont: I prefer if you push to a branch of the tree, and send pull requests to me to make sure I don't get conflicting tree's during an upload preperation
<lamont> np.  issue right now is EPERM trying to get to the tree at al
<lamont> all
<BenC> ah, total control :)
<lamont> sigh.  forgot to cc  you
<bdmurray> kylem: So I can get it to soft lockup 50% of the time by booting with killswitch off
<kylem> killswitch off meaning?
<bdmurray> The wireless switch on the laptop
<bdmurray> It's a physical switch
<kylem> so wireless on, in other words?
<bdmurray> no off
<bdmurray> I guess that is bad wording
<bdmurray> killswitch on == wireless off
<kylem> there's like quadruple negation here.
<bdmurray> I know my bad
<kylem> ipw3945?
<bdmurray> yes
<kylem> feisty kernel?
<bdmurray> yep
<kylem> bummer. i thought this was fixed.
<bdmurray> got a call trace this time. I guess I'll submit a bug
#ubuntu-kernel 2007-03-10
<rpereira> Hi.
<rpereira> How do I know if a git code was patched to the actual kernel version on Feisty?
<Nafallo> there is a kernel for edgy-security still coming? I plan to rewire some stuff when I have to reboot anyway :-)
<kylem> Nafallo, it's been uploaded... dunno if it's made it into the archive yet.
<Nafallo> haven't seen USN or edgy-changes :-)
<Nafallo> good anyway. maybe I get the disk before it's released then ;-)
<rpereira> kylem: How do I know if a git code was patched to the actual kernel version on Feisty?
<kylem> Nafallo, hehe.
<kylem> rpereira, the changelog?
<rpereira> kylem, I look for it.Thanks.
<rpereira> s/I/I'll
<Nafallo> grep ftw! :-)
<rpereira> kylem: I tried to find by myself but I didn't conclude if this patch (http://git.kernel.org/?p=linux/kernel/git/drzeus/mmc.git;a=commitdiff;h=e89bac488861ebadfca3a74321af19a262dcbd08) was applied to 2.6.20-9.15. I didn't found a patch id or something like that.
<rpereira> I tried to look for searching on this file: zless /usr/share/doc/linux-image-2.6.20-9-generic/changelog.Debian.gz
<kidanger> bonsoir
<kidanger> J'ai un modem fast 800, si je met  jour le noyau ca marche toujours ?
<Nafallo> -EWRONGLANG
<Nafallo> we speak english in here :-)
<kidanger> hoo sorry
<kidanger> i am french
<Nafallo> you might want to try #ubuntu or #ubuntu-fr or the like for support though :-)
<kidanger> and i have a problem
<kidanger> only english here?
<Nafallo> yes. and only development. for support, see the channels I posted :-)
<kidanger> :)
<kidanger> k sry
<kidanger> bye
<Nafallo> no problem :-)
<kidanger> lol
<Nafallo> XEN will not have securitysupport in 7.04 I guess?
* Nafallo ponders if anyone have written a MIR about kvm
<Keybuk> if I wanted to build a kernel identical to the Ubuntu one, but with one config change, how would I do that?
* Keybuk was trying to follow the docs, but they just don't work
<Keybuk> make: *** No rule to make target `updateconfigs'.  Stop.
<kylem> eh?
<kylem> debian/rules updateconfigs?
<Keybuk> yes
<Keybuk> I've clearly got the first step wron
<Keybuk> I did apt-get source linux-source, then tar xf linux-source-2.6.20.tar.bz2
<kylem> oh.
<kylem> just dpkg-source -x it...
<Keybuk> which
<Keybuk> the kernel image?
<kylem> apt-get source linux-source-2.6.20
<Keybuk> ok
<Keybuk> how do I change one config option and rebuild just my image?
<Keybuk> the AUTOBUILD...flavours=generic thing?
<kylem> do the updateconfigs, and then debian/rules binary-debs flavours=generic
<Keybuk> do you need AUTOBUILD=1 ?
<kylem> shouldn't
<Keybuk> kylem: oh yes, that's much better
#ubuntu-kernel 2007-03-11
<tweety> hi there, can i use 2.4 kernel in feisty ? (or howto get rid of 'FATAL: kernel too old')
<kylem> you should be able to, but you can't use an initramfs. what are you trying to do?
<tweety> trying to boot a feisty with my own 2.4 kernel "root=/dev/hda1 ro" (no initrd)
<tweety> and i got a kernel panic 'Attempted to kill init!'
<kylem> did you build in support for all your disk as modules or straight into the kernel?
<tweety> with a 2.4.34.1 i386 compile on a feisty (gcc 4.1.2) with no module support
<tweety> compiled*
<kylem> my other guess would be that upstart uses features that 2.4 doesn't have.
<kylem> i've not used 2.4 in years so it's kind of hard to say. :(
<tweety> i thinks it's ldconfig which report the 'FATAL: kernel too old'
<kylem> try export LD_ASSUME_KERNEL=2.4.20
<tweety> where ?
<kylem> oh, i guess if you can't boot that won't work. :/
<tweety> maybe in a init.conf like file
<tweety> i'll try with a custom initrd
<fabbione> nah you can't... glibc will require at least 2.6
<tweety> yep
<tweety> in dapper it worked, do u think it will on edgy ?
<fabbione> no idea
<fabbione> haven't used a 2.4 kernel in years
* Starting logfile irclogs/ubuntu-kernel.log
<tweety> and does someone know if ubuntu-hardened is still alive ?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-10.17 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules. | BUG STATUS (2.6.20): 281 Open, 70 Unconfirmed, 165 Unassigned
<mrec> BenC: ping
<kylem> god, how are there 70 unconfirmed again?
<zul> kylem: because they like to toy with you
<kylem> i should subscribe the ubuntu-bugs...
<kylem> to you.
<zul> no thats ok
<zul> thanks though
* ..[topic/#ubuntu-kernel:kylem] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-10.17 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules. | BUG STATUS (2.6.20): 281 Open, 55 Unconfirmed, 165 Unassigned
<zul> BenC: ping I have 2.6.20 running under xen and its a total dog at least x-windows at least
<BenC> zul: Is the paravirt not working well?
<xhaker> crimsun, you there?
<crimsun> xhaker: hi.
<xhaker> Hi daniel
<xhaker> I need your help
<xhaker> with an acer ALC883
<crimsun> if it's a support issue, we should move to #ubuntu or #alsa
<xhaker> i've been watching your commits for the kernel
<xhaker> move? really?
<crimsun> what's the issue precisely?
<xhaker> you've been fiddling with patch_realtek
<crimsun> yes, and it doesn't look like the majority of the changes have been merged yet
<xhaker> my realtek ALC883 only works when there is no asound.state saved
<xhaker> that's the real issue
<crimsun> that's a non-issue at this point: not all of the changes have been merged into Ben's tree
<crimsun> I'm happy to forward you a copy of the current diff so you can compile your own
<xhaker> please :)
<crimsun> email?
<xhaker> xhaker@gmail.com
<crimsun> git-format-patch -o ~ master
<crimsun> arr
<xhaker> fun fun
<crimsun> sorry, focus follows mouse is being wonky
<crimsun> sent.
<crimsun> Subject: Current HDA Realtek diff (against 2.6.20-10.17)
<stgraber> crimsun: Have you done any progress about my sound card issue ? I didn't see anything about that in the -10 changelog
<crimsun> stgraber: see above.
<crimsun> your issue is fixed in the patch_realtek.c fixes that I sent on March 6th
<crimsun> (and hasn't been merged yet)
<stgraber> ok, fine, thank you for your job
<crimsun> I had several outstanding conexant issues that should be fixed this evening
<xhaker> crimsun, do you want me to drop you a word after?
<crimsun> xhaker: sure
<xhaker> will do
<crimsun> I'm likely away from my irc client for a few hours, but a query would suffice
#ubuntu-kernel 2008-03-03
<Solarion> so, anyone around now?
<Solarion> man, my life is going to suck for a while then
<Kano> haha
<Solarion> Kano: is not funny.  filesystem horkage is no joke
<Solarion> maybe in ten years I'll be able to laugh
<Kano> what filesystem do you use
<Solarion> reiser is the only one atm
<Solarion> space is at a premium, but that's not the problem
<Solarion> lack of enabled usb persistance is my problem.
<Solarion> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197166
<ubotu> Launchpad bug 197166 in linux "[hardy] kernel should have usb persist mode built in" [Undecided,New] 
<Solarion> ubotu: thanks
<ubotu> You're welcome! But keep in mind I'm just a bot ;-)
<Solarion> ubotu: I know, but bots rock
<Kano> yes reiserfs is very tricky. you will lose your data fast when you oc your system or your ram is faulty...
<Solarion> I'm not doing either thing
<Solarion> but regardless, the reason I'm here is to discuss enabling USB pesist mode in the kernel
<Solarion> it doesn't actually turn on usb persist mode; it only enables it.
<Solarion> persist must still be turned on per device, so those users who don't need it won't feel the change
<Solarion> those (like me) who need it will have their lives suck much less
<Kano> you can recompile the kernel with that option with ease
<Solarion> so it's pretty clear-cut to me, but then I'm not an ubuntu let alone an ubuntu kernel dev, so I might have missed it
<Kano> did you do that
<Solarion> Kano: I'm doing it
<Solarion> I want to try to keep it semi-official, so I'd rather not keep doing it every time the kernel gets updated, which happens pretty often with hrdy
<Kano> just remove the meta package
<Kano> whats the problem
<Solarion> I then have to maintain the kernels myself?
<Solarion> is one of the reasons I use a distro?
<Kano> well maybe somebody adds your option, thats of course more easy
<Solarion> Kano: are you an ubutu kernel dev?
<Kano> no, i am from kanotix
<Solarion> Kano: yes, that is my hope; find out if I can get it enabled in the ubuntu build
<Kano> no problem to do that
<Kano> you could do that even via sed ;)
<Solarion> to do which?
<Kano> to enable options
<Solarion> yeah, I know
<Solarion> but enabling it in the ubuntu build is significantly more difficult, now isn't it?
<Kano> i do that this way
<Kano> yesterday somebody asked me to disable one option and then i disabled with via a sed command too - fully scripted
<Solarion> toll, aber das hilft mir net weiter
<Kano> guck dir das query an, in dem script sind einige tricks,wie man mit sed an config files rumspielt
<Solarion> ich kann doch mit config files rumgehn
<Kano> das bezweifle ich
<Solarion> das Problem is halt, dass ich usb persist mode in *ubuntus* kern aktivieren, nicht in meinem selbstgebauten
<Solarion> kannst ruhig tun
<Kano> naja ich kann den u kernel nicht Ã¤ndern, nur kanotix kernel
<Solarion> Kano: dann kannste mir net weiterhelfen.  :)
<Solarion> weiterbringen?
<Kano> im dem script im query findest aber alle infos wie man die config von u standard kernels Ã¤ndert
<Kano> wers nicht sieht ist blind
<Kano> bye
<Solarion> mensh, das letzte mal, als ich in Deutschland wohnte, hab' ich in DM bezahlt.  :)
 * Solarion notices that kano pm'ed him
<Solarion> ah well.  I'm still not blind then.  :)
<Solarion> sleeptime
<kraut> moin
<Solarion> mornin
<Solarion> this is a very quiet channel
<amitk> Solarion: you can start making the noise :)
<amitk> Solarion: were you the one requesting that USB_PERSISTENCE be turned on?
<zul> *sigh* who was asking me about nvidia xen stuff last week
<tjaalton> zul: _o/
<zul> tjaalton:  http://people.ubuntu.com/~chucks/nv-fix.diff is the fix for you
<tjaalton> zul: thanks!
<zul> np
<Solarion> amitk: yes
<Solarion> kraut: moin moin
<kraut> Solarion: hi
<Solarion> was fÃºr eine Art Kraut biste denn?
 * Solarion ist UNkraut
<kraut> sauerkraut, wenn du so weiter machst ;)
<Solarion> heh
<amitk> Solarion: I'll be looking at enabling USB_PERSIST sometime this week...if the default behaviour is off, then it should be in the next kernel.
<Solarion> amitk: it is, from the documentation I read
<Solarion> I'm compiling today's kernel (2.6.24-11) with it enabled to try it out
 * Solarion is rather a n00b when it comes to doing kernels the Ubuntu/Debian way.
<Solarion> amitk: ping
 * Solarion grabs lunch
<johanbr> crimsun_: Have you had any time for bluetooth testing? One thing that's happened is that the cvs version of the bluez audio service doesn't immediately drop the connection upon close, but reuses it in case an app reopens the connection in the next few seconds. This makes voip work much better.
<johanbr> I think it'd be nice to have this patch in Hardy.
<mario_limonciell> is there a trick to attempting to get a USB serial console up and running?  I've tried to include the usb-serial driver in the initramfs
<mario_limonciell> or will I have to recompile the kernel differently to allow this at least?
<fR_> hi, i'm trying to add a new option to the custom xen kernel config. what I've tried doing is modifing debian/binary-custom.d/xen/config.amd64, however when the scripts/kconfig/conf is run, it removes my option from the file it creates.
<fR_> is this the correct way to do this? can I make this conf script explain why it's rejecting the option?
<amitk> Solarion: hi
<Solarion> amitk: do you want/need the bug number or more information?>
<amitk> Solarion: no. As i said, I am looking into it now.. Hopefully I'll have it enabled for Hardy beta.
<Solarion> amitk: right, I was just trying to be helpful.  :)
<Solarion> amitk: thanks for looking in to it.
<Solarion> hmm, if it's not gonna be in before the beta, I'm gonna have to keep compiling my own until then, particularly for next week
<amitk> Solarion: thanks. We are in freeze for alpha 6 now, so it won't go in before beta
<crimsun_> johanbr: a bit but not on recent hardy due to gvfs being a bit unstable.  I'll check tomorrow's daily-live
<smb> mjg59: Hi Matthew, can you help me with a missing piece of powermanagement? When pressing the hibernate button I can follow the call chain until acpi_fakekey is called.
<smb> mjg59: What exaclty does acpi_fakekey do? Just sending a virtual keypress (to what)?
<mjg59> Yes, which should then be caught by hal and turned into a dbus event
<smb> mjg59: Which then would be handled by powermanagers listening there. Has there been a change you know of which could change defautls here?
<smb> mjg59: I am asking because I was looking at a report where the fakekey was called but the reporter claims there doesn't happen anything
<mjg59> Nothing springs to mind
<smb> mjg59: Hm, ok. Seems the next debugging step would then be to check for hal and dbus events. Or just plainly ask whether there is a power mannagement applet running... Thanks
<mjg59> xev should show the keystroke
<smb> mjg59: Got a log from showkay that shows the keypress. Could try xev as well but I expect this yields same results
<mjg59> Hm. Showkey wouldn't show it if it was from acpi_fakekey
<mjg59> So I suspect that's not what's happening
<smb> mjg59: Or it might just be unrelated. Just proving the key does something at all. But then xev would be a good candidate to go on. And maybe dbus-monitor
<BenC> smb: if showkey has it, it may just need to be mapped properly with the hotkeys-setup package for that particular model
<smb> BenC: It already does show up in acpid.log and call the correct action script, which does then an acpi_fakekey
<BenC> smb: hmm...sounds out of the kernel space to me then
<smb> BenC: Sounds like it. I just wanted to make sure I don't miss a bit. But I would generically suspect power management applets/daemons. 
<fR_> ok, I think the problem is that by selecting the XEN subarchitecture type, ARCH_SUPPORTS_MSI gets set to false, which prevents CONFIG_PCI_MSI, which is required by CONFIG_DMAR (the option I wanted to add). Does anyone here know anything about this? My understanding was that IOMMU is designed specifically for virtualization.
#ubuntu-kernel 2008-03-04
<cjb> Evening.  My Dell m1330 takes 25 secs to resume from S3, with latest hardy, due to the SATA link timing out.  Is it known?  dmesg snippet at http://pastebin.com/m563c7f79
<mjg59> cjb: I've seen that on other hardware, though mostly with older kernel.s
<mjg59> cjb: Do you see the same with gutsy?
<cjb> mjg59: Dunno, just got the laptop today and installed hardy.  Can find out, though.
<mjg59> That'd be helpful. You should be able to check from the CD.
<cjb> 'kay.
<mjg59> If it's a regression, that makes life much easier. Otherwise, we need to spend a while working out what's going on :)
<mjg59> Is this on every resume, or just the first?
<cjb> mjg59: possibly every resume *after* the first.
<cjb> wow, interrupt storm
<mjg59> Hm. Interestiny.
<cjb>     4 root      15  -5     0    0    0 R  100  0.0 169:56.08 ksoftirqd/0        
<mjg59> Yeah, you lose. What interrupt?
<cjb> not sure: http://pastebin.com/m571fa880
<cjb> still spinning on ksoftirqd, but the only thing increasing significantly is the timer interrupt at about 100Hz
<mjg59> cjb: Huh.
<mjg59> That's all very weird.
<cjb> works fine with Fedora/Rawhide, for whatever that's worth.
<cjb> oh -- the Fedora install is 64-bit, and Hardy is 32-bit 2.6.24-11-generic.
<mjg59> Hm. Kernel code should be generic.
* abogani changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-11.17 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 4, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<kraut> moin
<dda> hi everyone. not sure if such a question is ok here, but in #ubuntu nobody replies.. how to know what parameters can a kernel module accept? in particular, freq_table
<mjg59> modinfo
<dda> wow, that's really simple! thanks :)
<dda> now I see that there are no params for that module
<mathiaz> Hi ! I'm currently reworking the wiki pages of the ServerTesting Team. I was wondering what is the minimal information needed when filing a bug about a failed installation ?
<mathiaz> Let
<mathiaz> 's that user tried to install alpha5 on a poweredge 1950 and network and disk were not detected
<rtg> mjg59: BenC has promised to revisit the ACPI patch that I recently reverted for FTBS. cjwatson also mentioned that you had a VT switching patch ?
<BenC> mathiaz: lspci and dmesg are important for those types of bugs
<BenC> mathiaz: lspci -vvn to be exact
<mathiaz> BenC: lspci -vvnn or -vvn ?
<mathiaz> BenC: https://wiki.ubuntu.com/KernelTeamBugPolicies advises -vvnn
<mjg59> rtg: Yeah. I'll send the VT switching patch.
<rtg> mjg59: I'm gone Mar 6-26, but I'll make sure it gets on the kernel team ToDo list. Thanks.
<mario_limonciell> rtg, are you already gone for vacation, or got time for a quick question?
<rtg> mario_limonciell: still here for a couple more hours
<mario_limonciell> rtg, would it be out of the question to merge sky2 from linus' branch? It appears to resolve some pending suspend issues.  There are a number of commits that we are missing, so i'm not sure particularly which one it is that resolves it
<rtg> mario_limonciell: the best approach is either lum or lbm. It depends on how much change there has been.
<rtg> mario_limonciell: on 2nd thought, let me look at it.
<mario_limonciell> okay
<rtg> mario_limonciell: can you pop the sky2 driver into LUM, build it, and see if it solves your problems? There have been a lot of changes since 2.6.24. It may also be a candidate for LBM.
<mario_limonciell> rtg, I rebuilt my linux-image with it in place and it appears to resolve the particular issue that we were having 
<mario_limonciell> there is still a different suspend issue that happens occassionally (even if that driver isn't loaded), but the symptoms that we get with that old driver loaded don't happen with the new one
<rtg> mario_limonciell: the issue that I worry about is regressions if I put sky2 in the kernel (a non-elective package). Thats why I lean towards LBM.
<mario_limonciell> rtg, understandable.  
<rtg> mario_limonciell: its getting pretty late in the game for big changes.
<mario_limonciell> rtg, well i'll see if I can narrow down to a commit or two that resolve it particularly
<mario_limonciell> there are some memory alignment commits that I was leaning towards
<mario_limonciell> we'd prefer to avoid lbm if possible this time around -
<rtg> mario_limonciell: looking at the interwoven history of changes, that may be difficult.
<mario_limonciell> right.
<BenC> smb, cking, amitk, rtg: ping
<amitk> BenC: here
<rtg> BenC: yo
<cking> BenC: hi
<BenC> We'll get started and let smb catch up
<BenC> Ok, welcome to the kernel team meeting. We missed last week because the team was in Lexington for a sprint
<BenC> Details on out meetings can be found at https://wiki.ubuntu.com/KernelTeam/Meeting
<BenC> *our
<BenC> We'll start of we individual status
 * BenC is not typing well today
<BenC> I'll blame it on guitar hero
<BenC> amitk: Want to go first?
<rtg> 'cause your fingers are bleeding?
<amitk> sure
<amitk> Mainly worked with the UME team to get a ubuntu mobile image out to Intel
<amitk> have been working to integrate newer version of wlan and DRM kernel drivers for the Intel "Atom" processors, as they are now called
<BenC> amitk: How did the sprint work out for you last week? Did the time with the MID team help?
<amitk> next up is to looks the USB_PERSIST that we need to enabled to get out of the box support for eee pc and some other machines out there
<BenC> amitk: out-of-the-box, meaning "with the right kernel param", right? :)
<amitk> the sprint helped in clarifying the roles of kernel team and the mid teams. They have to do some of the lifting to ensure the Ubuntu has the latest drivers
<amitk> BenC: I am shooting for "enabled-via-sysfs"
<amitk> That's it from my end
<BenC> ok, thanks
<BenC> rtg: time to hear from you
<rtg> Besides a zillion bugs and patches applied, the single biggest thing I've worked on is the ABI breakage fixes.
<rtg> see https://wiki.ubuntu.com/KernelTeam/Sprints/Feb2008/HeadersABI
<rtg> Other then that, its just the minutia of kernel builds, uploads, ABI bumps.
<BenC> Oh, for anyone wanting to see what happened at the sprint, here's the low down: https://wiki.ubuntu.com/KernelTeam/Sprints/Feb2008
<rtg> I'm gone Mar 6-26.
<rtg> thats all from me.
<BenC> rtg: thanks
<BenC> cking: So how have things been going with you?
<cking> OK - working through the list of kernel bugs, the usual, patching, building, etc.. 
<cking> ..working out a better work flow now that I getting familiar with git and the various build machines
<BenC> cking: Preempted my next question :) Are you finding enough to do in general?
<cking> Yes.. and no.  Started to run a bit low end of last week.. ..but Monday comes around with more bugs..
<cking> ..are there any extra "challenges" then?
<BenC> Ok, ping me anytime if you find yourself running low
<BenC> Generally the blueprint list fills in, but this close to release, we don't have that anymore
<cking> ..well I did look at a few other kernel issues not listed on the bug list to get my karma rating up :-)
<BenC> cking: yeah, definitely don't let the hardy-buglist be your only source for bugs...there's lots more out there :)
<BenC> cking: ok, thanks
<amitk> cking: I am sure the MID guys would love to see you around too :)
<cking> amitk: yeah - how do I get my teeth into that domain?
<amitk> cking: you, Ben and I can perhaps discuss this offline
<cking> ok
<BenC> One thing would be to get the stock+build-system tree up for intrepid/lpia
<BenC> for the MID/UME folks
<BenC> Alright, not much to say about the bug list from last week except that we completely kicked its ass
<cking> Its a good feeling to do that
<smb> Oh well, just in case someones interested. ;-) I did mostly bugs. Beside of several smaller bugs, the one which was bigger timewise was the patchset for the i915. Otherwise trying to solve a duplicate vendor id issue upstream and evaluated how to get lum builds without installing the headers (for porter machines and build scripts).
<BenC> So great work there...only one bug got carried over from last week, and it's In-Progress
<BenC> smb: Ah, you're here...ok...
<smb> Yes, sorry. Failed to ping
<amitk> BenC: right. I cloned Linus' tree and copied over the debian/ dir. But it needs compile testing before pushing out the interpid trees.
<BenC> amitk: ok, good start, we'll keep that moving to hand over to MID/UME at UDS
<amitk>  As the plan stands, UME Interpid and Ubuntu Interpid will have identical git trees. I'll push something out next week.
<BenC> Ok, that brings the primary agenda to an end...
<BenC> First thing I'd like to address is rtg being out for March 6-26...we will be in a general kernel freeze till hardy release, so there wont be much outside of critical bug fixing during that time
<BenC> but we have some CVE work and testing (LTS=>LTS mainly) to handle, so the rest of us will have to pull his weight
<rtg> actually, I'm out Mar 5-26.
<BenC> Ok, so we wont see you after today until you are sun dried and fat from eating rattle snakes :)
<rtg> indeed.
<rtg> I'm getting short timers attitude.
<BenC> The other thing I want to point out is that we, the kernel team, have been slipping again on using this channel for general discussions
<BenC> I'm just as guilty (and probably to blame) for it...but we need to make a strong effort to keep discussions here and be more transparent
<BenC> And with that, I'd like to know if anyone has anything they would like to discuss
<smb> Hm, not currently
<cking> Nothing immediately comes to mind
<amitk> nope
<BenC> This would also be an opportune time for community to raise any issues
<BenC> Ok, thanks everyone...meeting is adjourned
<BenC> Have a great week, and see everyone next week (except rtg)
<cking> OK
<smb> Thanks. Till then
<smb> rtg: Have a safe trip
<zul> BenC: is there a chance for an iscsi fix im working on to get in for hardy?
<zul> its basically a cherrypick
<rtg> zul: request a pull so we can look at it.
<zul> okies
<rtg> zul: use the git protocol. I've found that http doesn't seem to work.
<zul> rtg: yeah I always use git
<zul> er...git protocol
<rtg> zul: no, I mean in the pull request, e.g., git://kernel.ubuntu.com/zul/ubuntu-hardy-xen.git
<zul> ok
<tjaalton> if you guys want a bug to work on, I've got a crasher which is confirmed :) (bug 189185)
<ubotu> Launchpad bug 189185 in linux "Thinkpad X61 hangs when removing from dock" [Medium,Confirmed] https://launchpad.net/bugs/189185
<j4k3b> BenC: do you have a second to talk privately?
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-11.17 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 11, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<Kano> hi, why does nobody learn from former mistakes?
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=fb82da6120f7a08405b314377750b17576802c56
<Kano> that does not only disable the modules which are in lum when you use: # CONFIG_SOUND is not set
<Kano> but also the sound modules of video drivers
<Kano> that patch is crap
#ubuntu-kernel 2008-03-05
<ember> hey
<ember> why :CONFIG_SND_VERBOSE_PROCFS was removed on -11?
<gmatht> I am trying to package compcache. Control.modules.in does not seem to be used by debuild. Am I correct in assuming that control.modules.in is only used when users compile there own modules using the module assistant?
<gmatht> Also, is there a recommended way of overriding "uname -r" in upstream modules?
<gmatht> adding a custom path with custom uname binary, or just patch the upstream source?
<kraut> moin
<Kano> hi, could somebody revert
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=fb82da6120f7a08405b314377750b17576802c56
<Kano> using sound off is no good
<Kano> not only "standard" alsa modules are affected also other modules which rely on alsa as build dep
<Kano> like the video ones you see which are removed too
<amitk> Kano: that commit will stay, we will move the video ones to LUM.
<Kano> but there are other external modules like em8300 which requrie sound
<amitk> Kano: rtg just pushed some changes that will build headers for LUM, so you should be able to compile these external modules against those headers
<Kano> then you can not simply use m-a a-i em8300?
<amitk> the headers will be searched for in order of preference - LBM --> LUM --> Kernel
<amitk> I am not an expert on m-a
<Kano> well just try it
<amitk> Kano: we will, once the move to split headers is complete :)
<jakeb_> good morning
<BenC> Good morning kernel ppl
<Nafallo> good day BenC :-)
<Nafallo> BenC: how are things?
<smb> Good morning
<zul> morning BenC 
 * BenC is just getting his first coffee down, so other than "good morning", he is not able to communicate
<zul> yuck..
<Nafallo> lol
<BenC> kylem: hey
<kylem> aloha.
<tseliot> BenC: have you received dholbach's email on EnvyNG?
<BenC> tseliot: yeah, but haven't had a chance to review things yet
<tseliot> BenC: no problem
<kagou> Hi
<kagou> trying to finf why my Right CTRL key don't work, i'v rebooted my Hardy system on recovery shell (root) to eliminate xorg problem. And i can say that Right Ctrl+C don't work here too
<kagou> i suspect a kernel problem
<kagou> any ideas or opinions ?
<BenC> kagou: does Left ^C work?
<kagou> i'v open Bug #198759 but now i'm going to assign it to kernel
<ubotu> Launchpad bug 198759 in xkeyboard-config "Right CTRL don't work" [Medium,Confirmed] https://launchpad.net/bugs/198759
<kagou> BenC, yes
<BenC> kagou: I seriously doubt kernel then
<BenC> kagou: run showkey...if it notices you pressing right ctrl, then it isn't kernel
<kagou> for left ctrl :
<kagou> 0x9C
<kagou> 0x1d
<kagou> pressed and left
<kagou> for right ctrl :
<kagou> 0x61
<BenC> I show 0x9d 0x1d for mine
<kagou> 0x61 0x61 0x61 0x61 0x61 0x61 0x61 
<BenC> For left, I show 0x61 0xe1
<kagou> benc same here
<BenC> kagou: then something has borked your right ctrl key mapping, if it shows 0x9c and not 0x9d
<BenC> kagou: did it ever work right? Does it work right from a livecd?
<BenC> err...wait
<kagou> right ctrl don't work since ...  a week
<BenC> your right ctrl key matches my right ctrl key
<kagou> i install fresh daily iso every 2 days
<kagou> 0x1d 0xe1 for right ctrl
<kagou> but right ctrl+C don't work
<BenC> so the key mappings match...which means it isn't the kernel (those are raw key codes from the kernel)
<kagou> Ok i understand. As i'am in recovery mode, just a root shell (no xorg etc.)
<BenC> kagou: does it work from the livecd (as opposed to your installed system)?
<kagou> i''v reboot mu notebook
<kagou> i use 20080305.2 daily-live-i386
<kagou> BenC, here, under Gutsy i have 0x61 0xe1 for right ctrl
<BenC> kagou: is that a gutsy livecd, or gutsy kernel with hardy userspace?
<kagou> under gnome-terminal right ctrl+C works :/
<kagou> On Hardy live, under gnome-terminal right ctrl+C works :/
<BenC> kagou: ok, if it works under livecd, it isn't the kernel
<kagou> BenC, indeed
<BenC> kagou: try creating a new user, login as them, and see if it works there
<BenC> if so, it's some local config in your homedir
<kagou> thank you.
<BenC> kagou: I assume you keep your homedir on these fresh installs?
<kagou> no
<BenC> kagou: Ok...the new user thing should help you out in tracking it down
<kagou> under Hardy live gnome-terminal Right ctrl+C work, not under hardy installed. Under Gutsy recovery root shell right ctrl+C work, not under hardy recovery root shell
<BenC> kagou: hmm...note that in the bug report
<BenC> kagou: not sure where to assign it though
<kagou> it's noted
<kagou> what a strange bug
<kagou> thank you BenC. Best regards
<hischild> i've been redirected here with a problem. Ubuntu doesn't seem to be able to recognize my second core. cpuinfo returns http://pastebin.com/f510a2e53
<tjaalton> hischild: what does 'uname -r' say?
<hischild> tjaalton, Linux hc 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
<hischild> oh wait
<hischild> that's -a
<tjaalton> nm
<tjaalton> it would have revealed if you had -386 kernel
<hischild> :-)
<tjaalton> I don't know what's wrong then..
<hischild> :( 
<hischild> the wierd thing is that on a previous install of ubuntu it recognized it just fine
<hischild> unless ... does acpi=off change anything related to this?
<abogani> hischild: What 'cat /proc/cmdline' say?
<hischild> abogani,  root=UUID=902c64c2-ffee-4902-a356-e3d705035c10 ro quiet splash acpi=off nmi_watchdog=0
<abogani> hischild: What are the reasons for last two options?
<hischild> abogani,  nmi_watchdog is because vbox wouldn't load properly without that option (during install i was told to add that option), the acpi=off is because my pc won't boot properly without it. If i leave that off it will reboot or freeze as soon as it hits gdm. 
<hischild> acpi=off only took about 10 hours to figure out 
<abogani> hischild: Please try this: reboot and in grub menu cut out "quiet splash acpi=off nmi_watchdog=0". Select recovery mode. When you have in front a prompt execute cat /proc/cpuinfo and report us. 
<hischild> abogani, isn't that the same as just selecting recovery mode? as that one only has "single" added to it
<abogani> hischild: I can't know if you have added these options manually. :-)
<abogani> only single is perfect
<hischild> alright i'll do that :-) back in a few min 
<johanbr> cking: About bug 124797 that you said was a HAL bug, I don't think that's right. On recent kernels, at least on my Inspiron 1420, the cpufreq directory for core 1 simply disappears. I don't think that's caused by HAL.
<ubotu> Launchpad bug 124797 in linux-source-2.6.22 "CPU Frequency Scaling Monitor applet on dual-core doesn't work after resume" [Undecided,Invalid] https://launchpad.net/bugs/124797
<gj_schouten> Hey someone knows how to make my hp zd8000 laptop less noisy and less heating using ubuntu hardy???? suggestions for using APM instead of ACPI and maybe powersaved instead of apmd????
<cking> johanbr: Hi, I think there are two issues here:
<cking> 1. The suspend/resume cycle does not restore the governor values properly, 
<hischild> abogani, alright i'm back ... yet to no avail, it hasn't changed. Gimme a sec while i pastebin it
<cking> 2. The missing cpufreq - which I will investigate further.
<hischild> abogani, http://pastebin.com/f447957ee
<johanbr> cking: Right. Thank you. Should anything be done launchpad-wise? (more info, file a new bug, reopen the old one, ...)
<cking> johanbr: I think open a new one, as it is quite different from the one reported at the start of the bug report.
<NthDegree> According to the 8.04a6 announcement the kernel now has a memory protection which randomises PIEs - can someone explain or elaborate on this as to what patching or technology is used for this?
<gj_schouten> anyone knows whats better when it comes to cpu overheating fan control using ubuntu on a hp zd8000 notebook??? acpi or apm and which daemons????
<Solarion> so I'm rolling my own kernel, and the /lib/modules/<kernel> directory is *huge* (well over several hundred MB) which runs me out of space; any idea why it's so huge?
<Solarion> by comparison, 2.6.24-11-generic is 112MB (the self-rolld kernel takes up well over 320MB)
<cking> johanbr: ..you can also refer to 124797 as background information.  I also suggest sending the usual dmesg information etc.. as required on bug reports
<BenC> NthDegree: it's been in the kernel for awhile, but you need to compile programs with the correct compiler options to make use of it
<BenC> Solarion: because you have CONFIG_DEBUG enabled, and we strip our modules after compile
<Solarion> ah
<Solarion> that might do it.  :)
<Solarion> is debug enabled by default?
<BenC> Solarion: find -name \*.ko | xargs strip
<BenC> do that before make install
<BenC> Solarion: we do it by default in our builds so we can get a vmlinux with debug symbols for linux-debug pkgs
<Solarion> BenC: I'm using the debian scripts to make this happen; what do I need to poke?
<BenC> Solarion: you mean make-kpkg?
<Solarion> yes
<BenC> can't help ya there...we don't use that for our builds
<BenC> maybe make-kpkg build, then the strip command I showed you, then make-kpkg binary
<BenC> or something similar
<Solarion> how about using debian/rules then?
<johanbr> cking: Alright. There's one bug open that already has the necessary information (bug #183033) and seems a better fit for the "cpufreq missing" issue. If you could have a look at that, it'd be much appreciated.
<ubotu> Launchpad bug 183033 in linux-source-2.6.22 "Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1" [Undecided,Confirmed] https://launchpad.net/bugs/183033
 * Solarion is going off of https://help.ubuntu.com/community/Kernel/Compile
<BenC> Solarion: wiki page in topic has info on that
<Solarion> thanks
<Solarion> building a kernel is easy if you blissfully ignore the distro, but I'm trying to do things The Right Way for a change
<cking> johnabr: will do - no problem at all
<NthDegree> BenC: this question may be OT but what compiler options does Hardy now use?
<abogani> hischild: Mmmmm You should check you cpu: 1) It don't have k8 flag 2) It don't have svm flag 3) have up that meaning "SMP kernel over UniProcessor"
<hischild> abogani, you're getting a little bit over my head with the technical terms .... what should / can i do?
<abogani> hischild:  Seems to me that this cpu isn't cpu the say to be... :-)
<BenC> NthDegree: no idea what userspace is doing...#ubuntu-devel might be better to ask
<hischild> abogani, i'm sure this is indeed an AMD Athlon 3800+ X2 ... it's always been this one ... it's specifically the one i bought .... 
<abogani> hischild: Joke apart: try to update BIOS. I don't have other advice. Sorry.
<hischild> :P
<hischild> abogani, right :( 
<abogani> hischild: just curious do you already tried with Hardy live?
<hischild> abogani, well tbh i'm more likely to go and try hardy then to flash my bios ... 
<hischild> but ... it used to work well in the past ... that's why i'm wondered
<gj_schouten> anyone knows whats better when it comes to cpu overheating fan control using ubuntu on a hp zd8000 notebook??? acpi or apm and which daemons????
<abogani> Ok. 
<abogani> tbh???
<abogani> :-?
<hischild> abogani, as soon as my laptop is running smoothly (missing a shitload of drivers ... have to use xp on it :( ) i'm goin to try hardy again
<hischild> tbh=to be honest
<abogani> Thanks. I'm not know IRC slang at all. :)
<hischild> abogani, no problem :-) 
<Solarion> why would debian/rules updateconfigs say 'No rule to make target updateconfigs'?
<BenC> Solarion: because you don't have our git tree installed
<Solarion> it requires the git tree?
<BenC> Solarion: the linux-source pkg doesn't include the build scripts
<Solarion> ah
<Solarion> that's not at all clear from the wiki page
<Solarion> so, I should really be building against the git tree?
<soren> I need some help with git. I'm trying to merge some of the virtio stuff from Linus' 2.6.25 tree. The virtio stuff we have in the kernel is based off of 2.6.24 with some changes from another git tree on top of it. To simplify the review for Linus, the patches were redone into more logical hunks, so even cherry-picking won't do. What would you do in such a situation? Rewind the patches we have locally (to get back to a clean 2.6.24) and then cherry-
#ubuntu-kernel 2008-03-06
<TomJaeger> Hi.  Is there somebody here who I can talk to about Bug #152187?
<ubotu> Launchpad bug 152187 in linux "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Unknown,In progress] https://launchpad.net/bugs/152187
<cjb> TomJaeger: I think it's an X bug; X doesn't rescan input devices on coming out of suspend, because it doesn't know we went to suspend.
<TomJaeger> cjb, it's a kernel bug and there is a fix for it.  My question is more along the lines of what needs to happen for this fix to be applied to the hardy kernel.
<cjb> TomJaeger: Neat, thanks for doing that work.  I have an M200 too.
<TomJaeger> The problem is that on the upstream side, there are two parties involved: the ACPICA and linux-acpi. This seems to delay things quite a bit.  I've been trying to get their attention, but it doesn't seem like upstream is going to fix that anytime soon.
<TomJaeger> Which is a shame since everyone pretty much agrees on what the correct thing to do is.
<cjb> That's frustrating.
<TomJaeger> yup
<TomJaeger> So the question is if it's possible to apply the fix to the ubuntu kernel even though the problem hasn't been fixed in upstream yet.  I think I can make a pretty strong case because (a) a fair amount of useres seems to be affected (any Toshiba tablet pc) and (b) for typical use patterns of a tablet pc, the problem is pretty severe (I, for one, would prefer Windows over linux any day of the week if the latter didn't support p
<TomJaeger> roper suspend).
<tjaalton> should the 'linux-restricted-modules-virtual' metapackage be removed, since there is no lrm for virtual, nor would it be useful
<soren> tjaalton: I'm surprised such a thing exists?
<tjaalton> soren: me too :)
<soren> tjaalton: linux-virtual doesn't depend on it, so I never noticed it.
<tjaalton> soren: hmm? looking at the linux-meta package seems like it _does_ depend on it
<tjaalton> oh wait
<tjaalton> soren: do you mean linux-image-virtual? the control-file does have linux-virtual that Depends on lrm
<tjaalton> but they exist only on i386
<tjaalton> *for
<soren> tjaalton: That's odd.
<soren> tjaalton: I distinctly remember installing linux-virtual in a vm with only main enabled and it worked.
<soren> tjaalton: This was a while ago, though.
<tjaalton> hum, the virtual machine can only be i386?
<tjaalton> and the descriptions are b0rked
<tjaalton> "Real time Linux kernel image"
<tjaalton> copy-paste ftw :)
<soren> :(
<kraut> moin
<eradicus> hi why do I get a file not found error module.h
<eradicus> here's the code
<eradicus> http://pastebin.stonekeep.com/1663
<eradicus> i already have build-essentials linux-source and linux-headers-generic and they have the same kernel version of my current
<eradicus> anyone who can help me please?
<amitk> eradicus: does your Makefile point to /lib/modules/<kernel-version>/build for the includes?
<eradicus> amitk, i have these in my Makefile
<eradicus> obj-m           := hellodriver.o
<eradicus> KDIR            := /lib/modules/$(shell uname -r)/build
<eradicus> PWD             := $(shell pwd)
<eradicus> default:
<eradicus>         $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
<eradicus> amitk, it compiles fine.
<eradicus> but when I do an insmod hellodriver.ko
<eradicus> it says file exists
<amitk> eradicus: what is the exact error?
<eradicus> insmod: error inserting 'hellodriver.ko': -1 File exists
<amitk> eradicus: ohh and what does 'lsmod | grep hello' return?
<eradicus> hellodriver             2432  0
<eradicus> amitk, it was loaded already :D
<amitk> eradicus: you already have a module loaded. Try 'rmmod hellodriver'
<eradicus> saw the message in dmesg
<eradicus> amitk, thanks 
<amitk> eradicus: no problems, good luck
<eradicus> amitk, ;)
<arcticpenguin380> does the kernel use 4k stacks?
<cking_> It depends, 4K or 8K
<BenC> Good morning kernelites
<abogani> BenC: Good morning.
<zul> morning
<smb_l> morning
<BenC> mdomsch: good morning
<mdomsch> BenC, good morning
<tseliot> BenC: did you have a look at EnvyNG?
<tseliot> tseliot: I really need your opinion on it. Let me know if there's something I can do to avoid waisting your time when you check it.
<abogani> ogasawara: Are you around?
<abogani> ogasawara:  Could you set #193659 on 'Won't Fix", please?
<gan> i am following the ubuntu doc of creating the live cd , but not supporting , it is coming upto mounting the filesystem 
<BenC> gan: That's more of a #ubuntu question
<gan> BenC, i feel its a pronb in kernel
<gan> BenC, i feel its a problem in kernel
<BenC> gan: does the actual livecd work for you?
<BenC> gan: not one you created
<gan> BenC, yeah 
<ogasawara> abogani: done
<BenC> gan: then it isn't a kernel problem
<BenC> gan: unless you compiled your own kernel, in which case we can't help you
<gan> BenC, i created the live cd , it is booting upto mounting the filesystem , then it got stop 
<gan> BenC, i compiled  a kernel for to create the live cd
<BenC> gan: then you are on your own basically...we can't debug the kernel you compiled
<BenC> gan: sounds like you are missing drivers, but other than that, you'll have to figure things out
<BenC> gan: why not just use a normal livecd for install...and if you want a custom kernel, do it on the installed system...why would you use a custom livecd like that?
<gan> BenC, the thing is booting propely when i boot from hardisk , the same is not working for live cd
<gan> yeah i cahnged the kernel of ubuntu then also i am facing the problem
<gan> yeah i changed the compiled kernel to ubuntu then also i am facing the problem
<BenC> gan: this is something you'll have to figure out on your own, or ask in #ubuntu
<BenC> gan: this isn't a kernel issue (and more specifically, isn't an issue with a kernel we provide)
<gan> BenC, thanks
<abogani> ogasawara: Leann sorry to bother you again! ;-)
<abogani> ogasawara: Bug #129542 was a confirmed bug that don't meet SRU requirements so it should be set "Won't Fix" (and not "Incomplete" that in IMHO is a wrong status). 
<ubotu> Launchpad bug 129542 in linux-source-2.6.20 "trouble accessing directory with quotes in read-only mode" [Undecided,Incomplete] https://launchpad.net/bugs/129542
<abogani> ogasawara: Thanks.
<ogasawara> abogani: I'll fix it up, thanks
<tseliot> BenC: if you're too busy, maybe someone else from the kernel team can have a look at EnvyNG so that mvo can upload it ASAP
<tseliot> BenC: I mean no disrespect
<tseliot> ;)
<tseliot> BenC: I appreciate your work
<BenC> tseliot: none taken...sorry I've been slow...the rest of the guys are busy as well, but I will get a look at it
<xivulon> There used to be problem with suspend-to-ram in loopinstallations related to fuse use (root inside file inside ntfs host). I just received some report from users that it now works!
<tseliot> BenC: ok, thanks
<xivulon> not sure what happened there, but I am quite pleased!
<BenC> xivulon: good to hear, even if it's unexpected :)
<xivulon> I will try to confirm that tonight and in case close the related bug report(s)
<xivulon> wanted to pass the news to mjg59 that had been looking at that some time ago'
<TomJaeger> ogasawara, hi, what are the chances of the fix for bug #152187 making it into hardy?
<ubotu> Launchpad bug 152187 in linux "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Unknown,In progress] https://launchpad.net/bugs/152187
<ogasawara> TomJaeger: I think smb and I are still monitoring the upstream progress so it's unlikely to hit Hardy at the moment
<TomJaeger> so we have to wait for upstream to fix this first?
<TomJaeger> fwiw, our upstream's upstream has fixed this already
<ogasawara> TomJaeger: what do you mean by "out upstream's upstream"?
<ogasawara> s/out/our
<TomJaeger> acpica
<ogasawara> TomJaeger: care to point me to a git commit id if you have it?
<ogasawara> TomJaeger: and has the patch been submitted to the upstream mainline kernel?
<TomJaeger> i don't know how they do their revision control, I'm not even sure it's public.
<TomJaeger> But it's in the changelog of the latest acpica release:
<TomJaeger> http://www.acpica.org/downloads/unix_source_code_cont.php
<TomJaeger> i've attached a hand-linuxified version of the patch to the linux bugzilla report, but apparently they have a conversion tool
<ogasawara> TomJaeger: have you submitted that patch to any other upstream mailing lists for review or just in the bugzilla?
<TomJaeger> for this to hit linux git, from what I gather, a few things need to happen first:  there was a typo in Robert Moore's patch, that needs to be corrected, then they need to linuxify the latest acpica and then there are some trivial changes in pnpacpi that need to be made.
<TomJaeger> ogasawara, just bugzilla, but I think they want to do it their way anyway.
<ogasawara> TomJaeger:  any idea when that will happen?
<TomJaeger> well, I'm new to all of this, so no
<ogasawara> TomJaeger: so basically to answer your original question, until upstream is happy with how the patch is the ubuntu kernel team most likely won't pull in any half-baked patches.  especially since Hardy is an LTS release.
<ogasawara> smb: care to comment here? ^^^
<TomJaeger> the thing is, everybody agrees on what needs to be done
<TomJaeger> okay, so how long before the hardy release date does this need to be fixed in upstream in order to make it into hardy?
<ogasawara> TomJaeger: anytime between now and Hardy kernel feature freeze which I believe is April 10.  otherwise it'll get pushed to Hardy+1 (Intrepid Ibex).
<TomJaeger> this is all very frustrating
<xivulon> BenC did you follow up on loop.c fastfs (http://lkml.org/lkml/2008/1/9/50) by any chance?
<xivulon> http://lkml.org/lkml/2008/1/9/50
<TomJaeger> ogasawara, does upstream mean linux-2.6 or acpi-test?
<ogasawara> TomJaeger: usually linux-2.6
<evenit> Hi all. I'm looking for help to compile a custom kernel. I have an this error message "/usr/src/linux-2.6.24 is not clean, please run 'make mrproper'"
<evenit> when building with "DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic "
<evenit> Can anyone help ?
<smb_l> ogasawara: Hi, sorry for the delay. Yes, I still am watching the original bugzilla for a final version, which then has to make its way upstream
<TomJaeger> ogasawara, smb_l, to give you an idea how slowly things are moving when it comes to acpica: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=acpica
<TomJaeger> this ain't gonna happen before April 10
<BenC> smb_l: it doesn't need to get into the kernel proper before we can take it, if it gets in acpica, we can review it on kernel-team@ for inclusion
<smb_l> BenC: ok, so I see what is there and post it on the list
<evenit> hi again.
<evenit> i'm still stuck with my "unclean" source tree and make requiring mrproper, even though  it will erase my debian directory... HELP!
<smb_l> evenit: How about mv debian <somewhere safe> then do mrproper and mv debian back?
<evenit> <smb_l> I believe I'm becoming dumb...
<evenit> <mb_l> You were right and compilation has started. Thanks.
<smb_l> evenit: np
<smb_l> philosophical question: given the option of either having acpi ac_adapter built into the kernel or loaded in the initramfs (so an fsck can check whether running on battery). Which would be the better choice?
<BenC> smb_l: init scripts...initramfs doesn't perform the fsck anyway
<smb_l> BenC: Not even for /? But right, for the rest its there.
#ubuntu-kernel 2008-03-07
<GrayFox> hey guys
<GrayFox> anyone who can help?
<GrayFox> http://pastebin.kubuntu-de.org/742867
<kraut> moin
<cjwatson> hey, does anyone know what happened to Ingo Molnar's patch to make relatime smarter? http://people.redhat.com/mingo/relatime-patches/improve-relatime.patch
<cjwatson> I don't really care about the mount options to a huge extent, but I'm turning on relatime by default in Ubuntu and it would be good if we had the "Is the previous atime value older than a day? If yes, update atime" bit
<cjwatson> which was at Linus' suggestion to avoid regressions in things like tmpwatch/tmpreaper, so I'm not sure why it hasn't been included
<cjwatson> http://lwn.net/Articles/244829/ <- context
<cjwatson> would also avoid regressing popularity-contest data
<amitk> cjwatson: I'm look at it now
<cjwatson> ta
<maks> cjwatson: afaik it is merged in fedora but not mainlined yet
<maks_> fedora always ahead :D
<cjwatson> Ingo works for RH, hardly surprising :P
<maks_> ;)
<cjwatson> is the Fedora kernel in git anywhere? having no luck finding it
<maks_> good old cvs
<maks_> http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/
<cjwatson> thanks
<maks_> you can see kyle busily working :) np cjwatson 
<maks_> need to watch that too for debian
<cjwatson> http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/linux-2.6-smarter-relatime.patch?rev=1.5&view=log
<maks_> yep
<cjwatson> amitk: want a bug?
<firas> hello ---- how  save Kernel IP routing table rules
<amitk> cjwatson: bug is appreciated
<firas> I lost them after reboot
<maks_> keep them in your pocket firas, wrong channel ask on #ubuntu for user support
 * soren discovers that it says "relatime", not "realtime" and now finds that the discussion is starting to make sense.
<abogani> soren: :-)
<firas> thank you MAKS   -- I will not do becuas  your hand some times visit my pocket
<maks_> firas you must mistake me for someone else :D
<cjwatson> amitk: bug 199427
<ubotu> Launchpad bug 199427 in linux "smarter relatime updates" [Undecided,New] https://launchpad.net/bugs/199427
<firas> MAKS is the thief of route rules be careful poeple 
<tjaalton> abogani: hey, there's a bug against lrm that needs some rt-love, bug 197130 :)
<ubotu> Launchpad bug 197130 in linux-restricted-modules-2.6.24 "[hardy] Black X screen and system halt after installing linux-rt" [Undecided,New] https://launchpad.net/bugs/197130
<abogani> tjaalton: Ok, thanks
<abogani> Seems to me that this patch is a good for inclusion in -rt...
<amitk> cjwatson: it seems to me from reviewing the patch that we ought to enable CONFIG_DEFAULT_RELATIME in our kernel to force all filesystems use relatime by default. Do you see any drawbacks in that?
<sivan> hi all
<abogani> amitk: IMHO dump would be affected, at least
<sivang> could anybody tell me if splash boot option is absolutely neccessary to have splashy doing it's thing when booting ?
<cjwatson> amitk: I was less convinced about that; that's more painful for users to disable since it's not so fine-grained
<sivang> I have it set up from the ubuntu package but nothing happens
<sivang> I tried highring it's start prio in rcS.d and rc1.d but nothing
<sivang> cjwatson: hey Colin
<sivang> amitk: fellow from Israel? :)
<amitk> cjwatson: so you plan on adding relatime to /etc/fstab?
<amitk> sivang: no, amit is a very common name in India :)
<cjwatson> amitk: already done :-)
<cjwatson> at least for new installs
<cjwatson> I sort of question adding it to existing installs
<sivang> amitk: Ah, heh pleased to meet you then
<amitk> cjwatson: that leaves all the upgraders out...
<amitk> sivang: you too
<cjwatson> amitk: your call
<amitk> abogani: does dump use atime instead of ctime and mtime?
<abogani> amitk: No, i wrong. Spoken before think. Sorry.
<cjwatson> amitk: IIRC you were working with ogra on making CONFIG_USB_SUSPEND a boot parameter, since some hardware likes it one way and some the other; did anything come of that?
<amitk> cjwatson: the key is to enable USB_PERSIST and make it runtime configurable. I think it is very much doable and I intend to work on it later today
<cjwatson> thanks
<BenC> Good morning folks
<abogani> BenC: Good morning, sir!
<BenC> cking_, amitk: I am prepping the next upload (-12.18), so if there is anything you want in, let me know now
<cking_> BenC: Nothing to add... fine by me.
<cjwatson> if either of the relatime thing I mentioned earlier or the USB suspend/persist thing are straightforward, I'd appreciate having those in beta
<cjwatson> did I remember to ask if anyone had picked up mjg59's VT font restoration patch?
<cjwatson> http://www.codon.org.uk/~mjg59/tmp/vt.diff
<cjwatson> I confirmed that it fixed the font restoration problems from the hardy-console spec for me
<amitk> cjwatson: mjg59's patch went in
<amitk> so did relatime
<amitk> working on USB persist now
<amitk> BenC: how long do I have? I am reviewing the USB persist config option.
<cjwatson> amitk: it did? awesome
<BenC> amitk: probably can do it
<BenC> amitk: I'm doing a test build now...make sure you pull before messing with config changes (had some updates to config files just pushed)
<tjaalton> BenC: check bugs 199037 and 189185
<ubotu> Launchpad bug 199037 in linux "Null bytes in files access by 2 or more NFS clients" [High,Triaged] https://launchpad.net/bugs/199037
<amitk> BenC: yeah.. looks like enabling CONFIG_USB_PERSIST in i386/generic should be enough for the needs of ogra and eee pc guys.
<ubotu> Launchpad bug 189185 in linux "Thinkpad X61 hangs when removing from dock" [Unknown,Fix released] https://launchpad.net/bugs/189185
<BenC> tjaalton: do they have tested patches?
<BenC> tjaalton: if not, I can't do much with them for this upload
<tjaalton> BenC: both are applied upstream
<amitk> BenC: great! so you decided to enable RELATIME by default :)
<BenC> tjaalton: well I assumed that the relatime patch was only useful if we did enable it :)
<cjwatson> heh, I'd already turned it on in the installer, but feel free to do it in the kernel too
<BenC> well the patch presented a new option, so I figured it should be turned on...is it safe to do so right before beta?
<amitk> BenC: the patch is fairly straight-forward and I am of the opinion that everyone (including upgraders) should benefit from relatime I/O savings.
<BenC> That's good enough for me, so I'll leave it on
<BenC> tjaalton: Just in time...I'll get both of those in, assuming they pass some trivial review and testing
<BenC> tjaalton: 199037, that commit is already in our kernel
<BenC> tjaalton: looks like it got cherry picked from some other report...so I'll mark this bug
<BenC> amitk: so with your config changes, is usb-persist enabled by default?
<BenC> smb: Tim had already bumped the ABI to -12, and the last one was -11...not sure what sort of ABI related failure you would have had though...are you sure it wasn't a module issue?
<smb> BenC: Not completely, I just saw messages about abi check failed and by reflex bumped the abi. :-(
<BenC> I'm doing a build now (reverted to -12), so I'll see what happens
<smb> BenC: Ok, I will do the same on one of the porters and on my build machine.
<BenC> amitk: I assumed that the USB_PERSIST thing was supposed to be enabled in config only, and we would add a mechanism to even then make it not enabled by default unless a proper kernel param was passed
<amitk> BenC: on a closer look that feature is already implemented, as a power/persist file for each USB device.
<amitk> so whatever device needs to enable it will just write to the 'persist' file from userspace
<BenC> amitk: ah, ok
<BenC> amitk: then maybe we should be consistent and enable it across the board?
<amitk> BenC: I have mixed feelings about it. It would allow more users to potentially shoot themselves in the foot...but on the other hand everyone running -generic (i386) has already been given the gun.
<BenC> amitk-afk: yeah, which is like 90%
<BenC> smb: ABI/module checks passed for me with -12 ABI set
<BenC> smb: perhaps the -11 ABI files weren't present when you tried the compile the first time
<amitk> BenC: so I should enabled it across the board?
<smb> BenC: Hm, I really have to look closer next time. :(
<BenC> amitk: sure, can't hurt any more than enabling for -generic x86
<BenC> it's not like people will install -386 to get around the problem :)
<amitk> heh, true
<amitk> BenC: and I surely don't want to suggest creating another flavour :)
<BenC> amitk: let me know when you have that ready...test build went fine, so I'm ready to upload
<amitk> BenC: done
<kraut> one general question, perhaps anyone could help me with this here: is it safe to give an user the possibility to use chroot /new/chroot via sudo as root? i am using a grsec-patched kernel, so it's not possible to mknod devices within the chroot.
<BenC> kraut: you're better off using schroot package
<BenC> amitk: thanks
<kraut> BenC: what's schrott?
<kraut> translated in german the word sounds not really trustable
<kraut> ah, i see.
<kraut> thanks BenC!
<BenC> Ok, -12.18 is away
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-12.18 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 11, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<BenC> I'm going to sign off for awhile to do some maint on my laptop...if anyone needs me, my mobile is on me
<amitk> smb: when Ben comes back online, could you tell him we need to respin the kernel. I forgot to push a lpia patch to solve a FTBFS. *sigh* I might do it over the weekend.
<smb> amitk: Ok, I will tell him. Might be I found my problem as well. Missing modules in virtual...
<amitk> smb: I mean the patch is pushed, but I might as well wait for all builds to be done before uploading another one
<amitk> smb: thanks
<smb> amitk: np. 
<smb> soren: should kvm modules be build for virtual?
 * smb goes for some food
<soren> smb: Nope.
<amitk> smb: Ben forgot to enable relatime on the custom flavours, I just pushed patches
<smb> soren: Hm, ok. It looks a bit like have been built before and this is being complained. Ok, then I try to fix that.
<smb> amitk: Ok, I will tell him later.
<amitk> heya kylem_ 
<xhaker> noticed the new kernel update. just ftbs. could you include https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/187121
<ubotu> Launchpad bug 187121 in linux "Udma not fully available in Acer 1694 Wlmi" [Medium,Confirmed] 
#ubuntu-kernel 2008-03-08
<scoundrel> hello all
<scoundrel> if anyone could help with this: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/199708 I'd really appreciate 
<ubotu> Launchpad bug 199708 in linux-source-2.6.22 "OOM killer kills all processes on an "empty" server" [Undecided,New] 
<bullgard4>  What is the function of the kondemand/0 process? How does it control the CPU clock frequency?
#ubuntu-kernel 2008-03-09
<Nilbus> referring to https://wiki.ubuntu.com/DebuggingKernelSuspend?highlight=pm_trace
<Nilbus> I have no "/sys/power/pm_trace".  Is that just not built into the current ubuntu kernel?
<Nilbus> s/built/configured/
 * Nilbus is having resume after suspend problems.
<johanbr> Nilbus: Might depend on architecture, I guess.
<Nilbus> johanbr, I'm on x86_64
<johanbr> Nilbus: So am I, and I have a pm_trace.
<Nilbus> I am on 2.6.22-14-generic
<tjaalton> I never have sound after suspend on my desktop, but reinstalling the module (snd_hda_intel) makes it work
<tjaalton> should pm-utils have quirks for situations like this?
<mjg59> No, because we can't reliably unload sound drivers
<tjaalton> so it's just a bug in the driver?
<mjg59> Yup
<tjaalton> mjg59: btw, the guy who demanded SHMConfig for synaptics now claims to have made a patch which does essentially the same without any (?) security problems
<tjaalton> it would grant access to the device if the user is in admin group
<mjg59> No.
<tjaalton> ..meaning not good enough?-)
<xhaker> snd_hda_intel @ linux-ubuntu-modules .12 is broken, shall I file a bug report about it?
<xhaker> ok, seems to be every snd* modules
<xhaker> s/modules/module
<xhaker> lots of Unknown symbol messages
<sourcemaker> how can I find the reason for a kernel panic? when I play the game enemy territory... the pc often hangs with a kernel panic... and I can only reboot the system "hard"...
<sourcemaker> is it possible to trace the kernel... when there is a kernel panic?
<sourcemaker> how can I find the reason for a kernel panic?
<ember> why SND_PROCFS and SND_INTEL8 is missing?
<xhaker> lp bug 200338
<xhaker> maybe
<xhaker> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/200338
<ubotu> Launchpad bug 200338 in linux-ubuntu-modules-2.6.24 "no sound hardy kernel 2.6.24-12 " [Critical,Confirmed] https://launchpad.net/bugs/200338
<ubotu> Launchpad bug 200338 in linux-ubuntu-modules-2.6.24 "no sound hardy kernel 2.6.24-12 " [Critical,Confirmed] 
<Nafallo> ehrm
<Nafallo> echo...
<DrZaius55> Howdy.. new to ubuntu (like it) long time gentoo user.  I'm used to compiling my kernel to optimize but I'm wondering how much things like "preemptible kernel" and "1000hz timer frequency" actually help performance for desktop systems?
#ubuntu-kernel 2009-03-02
<dtchen_> JanC: yes, or any bootloader
<dtchen_> heywood: aside from the echoing the value may not actually bring that core offline?
<mib_ykaad3> the ubuntu mainline kernel builds can be used on any release of ubuntu? even 8.04?
<mib_ykaad3> i'm talking about these - https://wiki.ubuntu.com/KernelMainlineBuilds
 * Panarchy syas Hi
 * Panarchy says Hi
<Panarchy> I have a modified Hardy Kernel (part of Debris Linux). I wish to replace this with the latest Intrepid Kernel. How would I go about doing this? RWW suggested "sudo apt-get install linux-generic", would that be the best way to do this, once I have installed Intrepid repostiories?
<lool> Folks, I just saw https://wiki.ubuntu.com/KernelMainlineBuilds and the instructions are relatively complex due to the manipulation of *.debs; did you consider setting up an APT archive instead?  You can do so easily with apt-ftparchive
<heywood> hello all
<Panarchy> hi
<heywood> dumb question.
<heywood> anyone know the difference between passing "noht" to the kernel at boot time (via grub's menu.lst) and issuing something like "echo 0 >/sys/devices/system/node/node0/cpu1/online"?
<anubhav> heywood:i heard that some kernel dont support the noht  param
<anubhav> so in those cases you can use the sys interface
<heywood> any idea where i could look up which do and don't? i'm reading docs for sysfs right now.
<heywood> oh, i'm running 2.6.27
<anubhav> just check the kernel sources
<smb_tp> IIRC noht is not present in recent kernels anymore, but max_cpus=1 would have the same effect
<anubhav> or you can write a script that checks /proc/cmdline and accordingly uses sys interface
<heywood> @anubhav: basically i'm trying to figure out how to reliably (but temporarily) disable hyperthreading
<heywood> i have a task that is sensitive to interrupts, and i want to see if disabling HT will help or hurt performance
<heywood> i have full control over the machine it's running on (so no need to make the script too smart or generic)
<heywood> so i know in advance what got passed at boot time -- since i get to pass it :)
<seaLne> does anyone know if the lockd regression fixed in 2.6.29 affects jauntys 2.6.28 kernel?
<rtg> Keybuk: does initramfs leave a log somewhere after remounting the real file system? I'
<Keybuk> rtg: no, what would you like to find out?
<rtg> I'm trying to figure out 0_kdump which works when run by hand.
<rtg> 0_kdump is installed in scripts/init-bottom by kexec-tools
<rtg> /usr/share/initramfs-tools/scripts/init-bottom, that is.
<b10h4z4rd> hi there ... i am trying to compile the latest (2.6.28-7) kernel via kernelcheck; the kerenel is built and the .deb file mdae .. but  it returns an error in installation: " Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.28.7-ultimate.postinst.d at line 1181.
<b10h4z4rd> someone an idea?  or a tip how to compile it another way ?
<anubhav> b10h4z4rd:https://help.ubuntu.com/community/Kernel/Compile
<amartin83>  Hi, i've been trying to upgrade kernel on my debian, tried the normal way and debian way, but there's always some errors end eventually kernel's not upgraded. Today need to upgrade kernel to the new one 2.6.28 or newer. Can someone please go with me through all the steps??
<wmat> amartin83: see here https://help.ubuntu.com/community/Kernel/Compile/
<wmat> amartin83: also see https://help.ubuntu.com/community/CategoryKernel
<amartin83> wmat, so maby better go through all steps again until errors occurs, but this will take some time couse as i remember it's a long process
<wmat> amartin83: it would take far longer for someone to lead you through it.
<wmat> amartin83: you should post errors as you encounter them
<wmat> amartin83: one note though, this channel is specific to kernel development, so you may not get much help
<amartin83> ok, i'll do that
<wmat> amartin83: you'd likely get more help in #ubuntu
<amartin83> oh, ok
<amartin83> just wonder, why there's always so much difficulties with kernel? Seen on many forums that people always get trouble, even if they do exactly like in recipe
<vbgunz> can someone help me troubleshoot a suspend/resume problem with a sata disk? I tried so many things but can never complete a bug report *because* my main disk dies on resume. I suspend to ram and it sleeps in seconds. I power up, takes about a minute and I have nothing but I/O errors to my disk :(
<wmat> amartin83: there's really too many variables out there to answer that question conclusively
<amartin83> wmat, thanks anyway
<vbgunz> when do I do the dmesg > ? ... after trying to resume right?
<BUGabundo> before and after according to apw
<apw> if you do it before you have more chance of not needing dmesg to be loaded from the disk
<apw> to run
<BUGabundo> humm try:
<BUGabundo> $dmesg ; sudo pm-suspend; dmesg
<BUGabundo> who knows.. maybe it works
<vbgunz> ok. will try it then... hold up, should I say dmesg > disk ; sudo pm-suspend; dmesg > disk?
<BUGabundo> no
<BUGabundo> tath would replace the 1st log
<BUGabundo> dmesg > disk ; sudo pm-suspend; dmesg >> disk
<BUGabundo> or
<BUGabundo> dmesg > disk ; sudo pm-suspend; dmesg > disk2
<vbgunz> ok, will try it then
<BUGabundo> apw: is there a flag or echo that can be done to increase the verbose of kernel output
<BUGabundo> while suspending/hibernate?
<vbgunz> about to do it. should I say sudo dmesg or no?
<BUGabundo> just do it
<apw> boot without quiet set
<BUGabundo> no need for that
<BUGabundo> dmesg doesn't need sudo
<apw> i would change to VT-1
<vbgunz> apw, I always do. everything says fine... the only thing that fails is apparmor. talking about couldn't load it or something
<apw> login there, run dmesg, then sudo pm-suspend
<vbgunz> ok, going for it, let me go to tty1
<BUGabundo> vbgunz: ping ??
<vbgunz> I can never resume from a suspend. I managed to get the dmesg after a fail suspend sent to a MS. here it is. can someone offer a clue as to whats wrong? http://dpaste.com/4775/
<vbgunz> I mean, well, I can *but* my sata is dead
<apw> vbgunz, yep looks like your disk and controller are out of sync, get that put into a bug on the kernel
<vbgunz> not sure what to do exactly :(
<vbgunz> am going to try pci=nomsi on the kernel parameter with IDE and then AHCI ... see if that works?
<apw> ok but get a new bug in launchpad filed
<apw> and add the information you have to it
<apw> so we can track it 
<vbgunz> is there a way, without rebooting and modding the kernel paramter to enable the pci=nomsi now?
<apw> ifconot that i know of
<IntuitiveNipple> apw: We've already got a bug report going since last week on this, which I am assigned to
<IntuitiveNipple> bug #334644
<ubot3> Malone bug 334644 in linux "[MSI MS-7374] suspend/resume failure [non-free: nvidia]" [Undecided,Incomplete] https://launchpad.net/bugs/334644
<apw> IntuitiveNipple, ahh good, then i can go back to sleep
<vbgunz> thats my bug
<IntuitiveNipple> apw: :p
<apw> vbgunz, how many didks do you have?  3?
<apw> the other two seem to have come back up, what is different about them?
<apw> you might want to try switching the two drives round
<apw> (two of the drives)
<IntuitiveNipple> apw: The lspci controller info says (non AHCI mode) but ahci reports it is managing the controller.
<IntuitiveNipple> apw: Also, vbgunz said "... I saw 2 options for AHCI in bios but they both instead say IDE..."
<vbgunz> ok
<manjo> smb_tp_, I fired off an email to mario, looking at the problem it looks like an installer issue 
<vbgunz> checking my mobo manual. sata port 5, 6 support AHCI and raid mode only... I am plugged into 1 and see nothing. I'll keep checking :)
<smb_tp_> manjo, The BIOS one or the other one?
<manjo> the other one 
<manjo> we had a fix for the raid stuff go in for jaunty
<manjo> fixed by cjwatson
<manjo> not sure of the bios one that I need to look at it on HW
<vbgunz> I have a MSI mobo, MS-7374
<manjo> smb_tp_, you think mario can give us access to such a hw ? 
<smb_tp_> manjo, He more likely than any other I would guess. But maybe I am the wrong to ask. ;-)
<manjo> :)
<vbgunz> well, let me try then to see if the pci=nomsi would work... brb
<dtchen_> rtg: / apw: any thoughts on reenabling PREEMPT for -generic for jaunty?
<apw> what is the driver?
<dtchen_> apw: resolving audio aberrations when PulseAudio is used in glitch-free mode
<apw> compared to turning off glitch-free mode it sounds like high risk adventure
<apw> why would we not turn off the glitch0free as it patently introduced glitches
<dtchen_> apw: i'm fine going either way regarding PREEMPT, but i need to know if i need to hack PulseAudio further
<apw> my feeling is that turning on something like that at this stage is risky
<dtchen_> apw: currently PulseAudio works around alsa-kernel and alsa-lib bugs regarding snd_pcm_avail*()  (being debugged in upstream alsa-devel)
<apw> pa has been broken all along, can we not just turn off glitch-free, its intent is only for use where latency is good
<apw> nad if latency is not good it is not appropriate
<apw> (to my reading
<dtchen_> the biggest problem is that the workarounds for snd_pcm_avail*() are only used if glitch-free is enabled
 * apw looks askance at the pile of doo doo that PA seems to be
<dtchen_> so to prevent PA from segfaulting when bogus data is returned, i'd need to alter PA to ignore the glitch-free checks
<apw> its a nightmare eitehr way
<dtchen_> i guess i just need to be diplomatic about suggestion that the checks are changed
<apw> is pa really readdy for primetime at all?
<dtchen_> suggesting*
<dtchen_> i think it's ready if all the stars are aligned, which requires kernel config changes
<dtchen_> well, i'll go ahead and make the changes to PA so at least it won't segfualt
<dtchen_> can't please everyone :)
<dtchen_> apw: thanks for your input
<IntuitiveNipple> dtchen_: I don't relish your position! I'd be screaming :)
#ubuntu-kernel 2009-03-03
<JanC> hm, why did Ubuntu kernel move from 300 to 250 HZ ?
<JanC> (I'd expect a change in the other direction...)
<apw> JanC, which version was it on 300?
<apw> thats an odd number for sure
<JanC> I thought it was on 300?  or am I so wrong?  (and 300 is one of the default values)
 * apw goes check
<apw> seems to have been 250 since edgy as far as i can tell
<apw> on generic and 100 on server
<vadi2_> Where can I find the process for filing a bug related to the kernel? (kacpid using more cpu time than xorg and firefox combined)
<amitk> vadi2_: does this help? https://help.ubuntu.com/community/ReportingBugs
<vadi2_> I'll give that a try
<vadi2_> hum
<vadi2_> nothing happened when I did ubuntu-bug
<vadi2_> (it asked to be run as root at first, did sudo after, and it just quit)
<apw> vadi2_, that doesn't sound right
<apw> the bug you mention sound familiar, what version are you running; cat /proc/version_signature
<vadi2_> Ubuntu 2.6.27-11.27-generic
<maco> is this a kernel problem or dhclient problem? when i switch APs within the same network / using the same ESSID, dhclient always gets no working leases. if i modprobe -r then modprobe iwlagn, dhclient works fine.
<maco> er it says no offers received and no leases in the db
<IntuitiveNipple> Does sudo iwlist <if> report both APs? I've seen issues where the 'old' weaker one is targeted rather than the one with the stronger signal.
<maco> i dont know. ill have to check next time, i guess.
<vadi2_> apw: need anything else from me?
<IntuitiveNipple> I also had an issue where APs linked via WDS had lost their link and so when switching to the 'remote' AP the PC couldn't get a DHCP lease (since it would come from the 'primary')
<maco> if iwlist is still seeing the old one (2 blocks away?) which conclusion would that count toward?
<IntuitiveNipple> maco: Sounds like stale records - what does the signal strength report?
<maco> well i'm connected to the 2nd one now. i just ran into this for the 3rd time i was switching buildings for classes and trying to reconnect to get back into #ubuntu-meeting and watch
<IntuitiveNipple> I can get a signal from 1/2 mile away when I'm out in the fields, but I do have a rooftop high-gain omni-directional mast.
<maco> so ive already unloaded and reloaded iwlagn
<maco> there are 15 APs in this spot with the same ESSID
<maco> they're supposed to let you move from one to the other without a blip
<IntuitiveNipple> It sounds like some kind of affinity to the original AP, can't think quite how though.
<IntuitiveNipple> Are any of them on the same channel?
<IntuitiveNipple> What you really need is to do a site-survey to determine which APs (MACs) and what signal strengths the adapter is seeing at the problem location. Also, what happens if you get on the 'second' AP first, then move back to the 'first'? Is that transition successful?
<maco_> welll there's today's panic
<maco> IntuitiveNipple: they vary between channels 1, 6, and 11
<maco> 7 on chan 1, 3 on chan 6, 4 on chan 11 right now
<maco> the one i'm on right now is one of the chan 1 APs
<IntuitiveNipple> maco: Are they positioned so as not to overlap on each where they share a channel?
<maco> i doubt it, since i can see this many from one spot
<maco> its some sort of cisco mesh thing the school does to try (and fail) to cover the entire campus
<IntuitiveNipple> It's always a problem using b/g with the limited channels available.
<maco> IntuitiveNipple: does that mean "tough cookies"?
<IntuitiveNipple> maco: It shouldn't; the client should handle it provided the signal/ratio isn't too low
<IntuitiveNipple> signal/noise ratio 
<UnixOne> Any explanation? I get the error "kernel maps protect is an unknown key" on bootup. Linux SGC-Abydoss 2.6.28.7-ultimate #1 SMP Tue Mar 3 18:19:03 CET 2009 i686 GNU/Linux
<UnixOne> Just compiled the latest stable kernel
<IntuitiveNipple> UnixOne: Using an atheros network device?
<UnixOne> IntuitiveNipple: I've no wlan. its a wired intel gigabit
<IntuitiveNipple> You need to uncomment /etc/sysctl.conf "kernel.maps_protect=1" I think
<IntuitiveNipple> See man 8 sysctl
<UnixOne> IntuitiveNipple: cool, I will try that. Thank you^^ 
<UnixOne> IntuitiveNipple: somehow everything is commented out in that file. is that normal?
<IntuitiveNipple> Default settings 
<IntuitiveNipple> something you've got installed is trying to check that key
<UnixOne> IntuitiveNipple: http://rafb.net/p/Kqsr9F60.html I commented it out. Are the other settings ok?
<IntuitiveNipple> Two things. maps_protect was removed by kernel commit 3bbfe05 2008-10-10 which came with v2.6.28-rc1
<IntuitiveNipple> Second. The key should not have the "sys." prefix.
<IntuitiveNipple> You must have some 'older' utility trying to make use of the key.
<UnixOne> IntuitiveNipple: ? I compiled it with kernelcheck. 
<UnixOne> will reboot. cu
<UnixOne> IntuitiveNipple: All errors fixed I just disabled #kernel.maps_protect = 1 it was enabled in /etc/sysctl.d/10-process-security.conf
<UnixOne> I don't understand how hardcore cracks @gentoo manage to speedup and hack their kernel that it reboot into a fully working system withing 7seconds..
<UnixOne> my machine took about ~25secs 
<UnixOne> which is still very fast. because I've a slim system with kde-core only
<UnixOne> ah... parallel execution^^ 
<mnemo> can anyone repro this bug? is it a kernel bug? --> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/336771
<ubot3> Malone bug 336771 in linux "system locks up when running "strace gdmsetup"" [Undecided,New] 
<maxb> "Latest kernel upload:" in topic is woefully out of date. Perhaps it should be removed outright?
* abogani changed the topic of #ubuntu-kernel to: "Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Released 2.6.28 kernel for Jaunty/9.04. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.27-8.26 based on 2.6.28.7 final"
* abogani changed the topic of #ubuntu-kernel to: "Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Released 2.6.28 kernel for Jaunty/9.04. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.28-8.26 based on 2.6.28.7 final"
<maxb> Is there a helper program/script which git tags using the version from the changelog, with a leading Ubuntu- as per ubuntu kernel conventions?
<maxb> I know about debcommit -r, but the leader doesn't seem to be customizable
#ubuntu-kernel 2009-03-04
<TheMuso> maxb: Not that I know of, but it certainly wouldn't be hard to whip one up, simply by pulling the version with a sed regexp.
<tcole> hello
<apw> maxb, our tree should already carry the tags
<apw> there is a script which is used in early release which could be adaped to do it, called retag
<apw> but if you are using our git trees the git tags should already be on them
<maxb> Yes, but I'd like to emulate whatever you do when I make myself a private build :-)
<apw> tagging is manual as we release
<LLStarks> morning.
<monreal> I have a problem with intrepid not booting because the initrd is not generated correctly... is this the right channel?
<rtg> monreal: what is incorrect about it?
<monreal> rtg: ok, well, this morning it did not boot... says "udevadm trigger is not permitted while udev is unconfigured." right at the beginning
<monreal> I googled for this but the only real match does not help
<rtg> hmm, seems like it might be a Keybuk question.
<rtg> monreal: was this after an update?
<Keybuk> this sounds like you rebooted *mid* update
<monreal> hard to say, the machine ran for some days
<monreal> Keybuk: don't think so
<Keybuk> or something called update-initramfs without a dependency on initramfs-tools (!!)
<rtg> monreal: can you boot an older kernel?
<monreal> well, I can boot the system with an old kernel and the old initrd
<monreal> .27-9
<BUGabundo> apw: here
<BUGabundo> I lot wifi
<BUGabundo> and seem not the only one
<rtg> monreal: good, do that, then run 'update-initramfs -u'
<apw> you lost wifi how?
<apw> you mean if you boot with the rfkill on, and then turn it off ?
<rtg> apw: LBM no doubt
<BUGabundo> linux-backports-modules-2.6.28 (2.6.28-8.7) jaunty; urgency=low
<BUGabundo>   [Stefan Bader]
<BUGabundo>   * scripts: Fix typo in prepare-compat-wireless.sh
<BUGabundo>     - LP: #332576
<BUGabundo>   [Tim Gardner]
<BUGabundo>   * Update to master-2009-03-03
<BUGabundo>   * Accomodate request_module() calls when munging module names.
<BUGabundo>  --  Tim Gardner <tim.gardner@canonical.com>  Wed, 04 Mar 2009 01:05:15 +0000
<BUGabundo> linux-backports-modules-2.6.28 (2.6.28-8.6) jaunty; urgency=low
<BUGabundo>   [Tim Gardner]
<BUGabundo>   * Added LPIA arch support
<BUGabundo>   * Bump ABI
<BUGabundo>  --  Tim Gardner <tim.gardner@canonical.com>  Tue, 17 Feb 2009 02:44:25 +0000
<rtg> BUGabundo: I'm working on it
<BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/193970?comments=all
<ubot3> Malone bug 193970 in linux "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Medium,Confirmed] 
<BUGabundo> ok rtg
<BUGabundo> thanks
<monreal> rtg: Isn't this the same that dpkg-reconfigure udev runs for example?
<BUGabundo> I had to reboot into -7 just to have wifi
<BUGabundo> and nvidia is also a mess!
<BUGabundo> only noveu works
<apw> BUGabundo, heh ... yes a bit of a mess there.
<rtg> monreal: probably, but your _are_ living on the bleeding edge.
<BUGabundo> I'll wait for a new kernel bump
<apw> if you weren't using lbm before you could deinstall that i believe
<BUGabundo> do guys have a time line? so I boot into -7 until then
<monreal> rtg: bleeding edge? this is intrepid...
<apw> BUGabundo, did you have linux-backports-modules before i asked you to install it?
<apw> if not then i believe just removing it should sort you out
<BUGabundo> let me check
<rtg> monreal: oh, I guess I assumed Jaunty.
<BUGabundo> linux-backports-modules-2.6.28-8-generic:  Installed: 2.6.28-8.7
<BUGabundo> yea it seem I had it already
<BUGabundo> I didn't manually installed it TODAY
<BUGabundo> if it was, it was there a while ago
<monreal> no... if it happened on some alpha distribution I would not care much... but this was supposed to be my stable system :(
<apw> BUGabundo, what version did you have before?
<BUGabundo> apw: no idea!
<BUGabundo> need to check aptlog
<monreal> is there a way to extract the initrds? I have a good and a bad .27-9 initrd, maybe the difference would tell what's wrong?
<apw> BUGabundo, well the previous version is still in the pool
<BUGabundo> ah?
<apw> BUGabundo, are you 32 ot 64 bit?
<BUGabundo> on my cache?
<BUGabundo> 64
<apw> http://gb.archive.ubuntu.com/ubuntu/pool/main/l/linux-backports-modules-2.6.28/linux-backports-modules-2.6.28-8-generic_2.6.28-8.6_amd64.deb
<apw> i believe that that would be the previous version, you could downgrade to that
<BUGabundo> ERROR:root:NvidiaDetection returned a error: dir modaliases/ not found
<BUGabundo> MarkUpgrade() called on a non-upgrable pkg: 'ubuntu-desktop'
<BUGabundo> this explains why NV sucks
<smb_tp> monreal, cat initrd|gunzip -c|cpio --extract --make-directories should work
<apw> BUGabundo, erp.  did you get something else in the upgrade?
<apw> that sounds unrelated to the lbm thing
<BUGabundo> 2009-02-18 10:07:43 status installed linux-backports-modules-jaunty 2.6.28.8.8
<BUGabundo> there it is.. the last one before today
<BUGabundo> apw never mind NV... wrong log
<BUGabundo> old apt.lg
<BUGabundo> not dpkg.log.1
<monreal> wtf, /sbin/udevadm is a script in the bad inited and a binary in the good one
<BUGabundo> apw: rtg does that help?
<apw> BUGabundo, sorry?
<monreal> besides /sbin/udevadm the initrds are totally identical
<apw> [ ]	linux-backports-modules-2.6.28-8-server_2.6.28-8.7_amd64.deb	04-Mar-2009 02:04 	1.2M	 
<apw> [ ]	linux-backports-modules-2.6.28-8-server_2.6.28-8.7_i386.deb	04-Mar-2009 02:04 	1.2M	 
<BUGabundo> (04:44:54 PM) freenode: 2009-02-18 10:07:43 status installed linux-backports-modules-jaunty 2.6.28.8.8
<BUGabundo> (04:45:21 PM) freenode: there it is.. the last one before today
<BUGabundo> apw ^^^^^^^
<apw> those two appear to be the broken one
<BUGabundo> I would believe so
<apw> the link i posted to you before was a link to the .deb of the version which preceded that
<apw> which would likley fix your issue
<apw> wget that down and dpkg -i foo.deb on it
<ogasawara> sbeattie: ok if I add a "linux" task to bug 329489 for the patch you provided
<ubot3> Malone bug 329489 in apparmor "locks on unlinked files leak memory in apparmor" [Medium,Confirmed] https://launchpad.net/bugs/329489
<sbeattie> ogasawara: uh, yeah. Doh.
<BUGabundo> apw so in the mean time removing it should fix it?
<apw> BUGabundo, no, if you had it installed before you updated, then you would want the older version i posted above
<BUGabundo> ok
<BUGabundo> apw: downgraded
<apw> BUGabundo, let me know if it works for you :)
<BUGabundo> no time now!
<BUGabundo> at work.. busy
<BUGabundo> that's why I needed it working
<BUGabundo> strange... it was working fine, I upgraded as I do every day... still worked
<BUGabundo> then when I tried to reconect to wifi... no more!
<apw> BUGabundo, strange indeed
<TheMuso> apw: Whats the status of getting the HDMI patches into the kernel for the dell hardware we have/are working with?
<apw> i thought the stuff kernel side was already in
<apw> mayhaps i miss remember
<TheMuso> apw: afaik there were patches that Mario pointed out to you that needed to be applied.
<apw> they got applied somewhere i thought
<apw> perhaps it was just a ppa kernel, hmmm
<apw> TheMuso, the short answer is i don't know for sure
<apw> and i need to go find out
<TheMuso> apw: Just checking, but I don't think so, as I have a separate branch locally that I rebase against mainline with, and the patches always have to be applied.
<TheMuso> apw: i.e I have to apply the patches every time I want the latest jaunty kernel for the dell I have access to currently.
<apw> TheMuso, is that branch somewhere i can see it, be good to compare it to anything i find
<TheMuso> apw: No, once I rebase against latest Jaunty I can push a tree to zinc if thats helpful.
<apw> TheMuso, that would be perfect
<TheMuso> ok will do so shortly.
<apw> TheMuso, sorry to be vague, i have 71 branches in my jaunty tree alone and some things slip through the cracks
<TheMuso> apw: np
<TheMuso> apw: git://kernel.ubuntu.com/themuso/ubuntu-jaunty.git has the hdmi related patches rebased on top of latest jaunty mainline in git./
<rtg> apw: I'll take care of the Jaunty HDMI stuff.
<apw> rtg ... ok
<rtg> apw: how did all of these patches get your SOB without going into Jaunty?
<apw> i assume they are signed off by me in the branch that i have here
<apw> TheMuso, where did you get your patch stack from
<apw> me ?
<apw> i did the collection of the patches a long time back and we made test kernels
<apw> i would have signed them as i pulled them into my branch ready for pushing to jaunty
<rtg> apw: I guess that wuold explain it
<apw> i assume that part is the bit which was missed
<TheMuso> apw: I asked Mario about the HDMI patches, and he referred me to a tree of yours if I remember correctly.
<apw> then that all fits with my expectation
<rtg> TheMuso: I assume this stuff is tested to work?
<apw> i was going to compare the two, but as i assume TheMuso has actually tested this pile, i would tend to use his
<TheMuso> rtg: Yes, I've been rolling hdmi enabled kernels every jaunty kernel upload for use on the dell notebook I currently have, and yes HDMI is working.
<rtg> TheMuso: cool, I'll pull it
<Keybuk> do we copy modules.order into /lib/modules/blah ?
<rtg> Keybuk: never seen that file.
<Keybuk> it's in the top-level of the build afterwards
<Keybuk> the word would me made of more kittens if you could include that in the kernel package in the /lib/modules/blah directory
<rtg> something new with Jaunty that I've not noticed?
<Keybuk> no, turned up about a year ago upstream,
<Keybuk> it's a file containing the order that modules would be linked into the kernel had they been built-ins
<Keybuk> modprobe will load modules in that order when multiple ones match
<Keybuk> ie. the modprobe order for a MODALIAS and the built-in order will match
<Keybuk> rather than being random
<rtg> Keybuk: there appears to be one in each subdirectory that creates a .ko. Do you want them all?
<Keybuk> no
<Keybuk> just the top-level one
<Keybuk> the kernel cats them all together as part of MODPOST
<rtg> there it is, couldn't see it for the forest.
<tcole> by the way, what is the correct next step for bug #300143?
<ubot3> Malone bug 300143 in linux "tablet devices show up as non-functional joysticks" [Medium,Triaged] https://launchpad.net/bugs/300143
<Keybuk> apw: you remember how we were looking into the problem of making built-in modules show up somehow to modprobe
<Keybuk> apw: it turns out that the kernel almost but not quite does this already
<Keybuk> e.g. /sys/module/printk :p
<Keybuk> it just looks like certain modules aren't showing up
<Keybuk> (like ata_piix)
<rtg> Keybuk: how is modules.order going to be affected by external build like LBM ?
<tcole> my question's been answered elsewhere, but thank you
<tcole> I'll submit the patch properly
<Keybuk> rtg: doesn't LBM install into updates?
<rtg> Keybuk: yep, but it also pre-empts module load order when /etc/modprobe.d/conf is set.
<rtg> Keybuk: depmod.d that is
<Keybuk> how do you mean?
<rtg> Keybuk: /etc/depmod.d/ubuntu.conf controls search order, which seems to preempt the order defined in modules.order
<Keybuk> exactly
<Keybuk> so if you have something in LBM, it'll be in updates, so preferred
<rtg> Keybuk: yep.
<Keybuk> isn't that desired?
<rtg> Keybuk: yes, which is why I asked if modules.order would have any affect in that case. If not, then I'm ok with it.
<Keybuk> great
<rtg> Keybuk: different topic. is it OK to make kexec-tools depend on initramfs-tools ?
<Keybuk> I can't see why not
<rtg> k
<kristian1> is this the kernel?
<maxb> How do I ask the latest linux-backports-modules to be in a different wireless regulatory zone?
<Wellark> could someone take alook at this, please: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/273152
<ubot3> Malone bug 273152 in linux-meta "New rtl8187b device ID" [Undecided,New] 
<Wellark> it's probably filed against wrong package as it's trivial and fix is attached, but it seems that jaunty kernel is missing the ID, too
<jbuncher> apw:  I just saw your post to Bug #327431, but I'm not sure how to test the version of linux-ubuntu-modules that you uploaded.  The package you want me to test has the 2.6.24-24 kernel numbering, but I don't have that installed.  Will I be able to test that package with the -23 kernel?
<ubot3> Malone bug 327431 in linux "iwl3945 cannot connect to hidden ssid WPA enterprise with Hardy 2.6.24-23 - Regression" [High,Incomplete] https://launchpad.net/bugs/327431
<apw> jbuncher, hrm, i built that against the latest kernel for hardy i guess.  i downloaded the headers to build it from the pool so it must be in there
<apw> http://gb.archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-2.6.24-24-generic_2.6.24-24.50_i386.deb
<apw> is probabally it
<jbuncher> apw:  Ok. I'll install that kernel first and test it (just to check if -24 fixed the problem anyway), then I'll try with the new -ubuntu-modules you uploaded.  It might take me a while to do, as I have to get my laptop repaired in the next day or so (dc power jack issues).
<apw> heh typical ... thanks for testing
<maco> does bug 270754 make sense to any of you?  the person says their computer worked fine until installing Intrepid either wiped or corrupted their BIOS.
<ubot3> Malone bug 270754 in ubuntu "8.10 Killed my motherboard?" [Undecided,Confirmed] https://launchpad.net/bugs/270754
<soren> What exactly is it that makes the iptables modules load when I run iptables for the first time?
<soren> Oh. Hah. Never mind :)
#ubuntu-kernel 2009-03-05
<JanC> maco: that sounds like broken hardware to me
<maco> JanC: yes, i know it sounds like broken hardware. the confusing bit is that he says on two separate motherboards, there were no problems at all until he installed ubuntu.
<maco> i cant figure how changing OSes could do that, but I figured if anything has the hardware access necessary, it'd be the kernel
<JanC> on my previous job we had on average 2 PCs or laptops dying like that every week, and there was only Windows on those systems  ;)
<JanC> (but of course there were a couple of thousand systems there)
<JanC> also, changing OS causes a lot of stress on a system
<JanC> most systems are idling 99% of the time, and then suddenly it has to do real work
<maco> so you think the install process overtaxed a low-quality system?
<JanC> maco: I think the system was already dying, but just got the last push
<JanC> of course there is no proof that ubuntu didn't cause this, but if it did, it clearly only happens under some rare conditions
<dtchen_> some of these conditions aren't so rare
<dtchen_> twiddling the registers on an entire revision of sigmatels shipping in Creative Sound Blaster Lives can brick the card
<JanC> dtchen_: what I meant was that their occurence must be very low
<JanC> it's not like you'll twiddle those registers on purpose ã
<dtchen_> but you would if you ever set the Tone control.
<JanC> you mean this bricking is built-in feature of that card
<dtchen_> it's worked around in the Windows drivers by explicitly disabling ever turning off the Tone control ;)
<JanC> fun
<JanC> but if that happens often there will be lots of bug reports / blog posts / etc.
<JanC> not 2 people with 3 dead systems that don't even show the same symptoms
<smb_tp> The problem currently is that the only visible hint with that "black screen" issue is that it seems those affected got multiple ACPI: Video entries with the -12 kernel but only one with the -13
<smb_tp> I have not found anything directly touching this. There has been one change that adds instances in the VGA case but that is not changing things.
<smb_tp> I tried to see whether it could possibly be the acpi integer change that converts that type to 64 bit, but the only response how that changes things is a bit fuzzy
<smb_tp> It would be helpful to know what NVidia changed from 173 to 180 but they are not very specific what exactly changed
<smb_tp> The only other changes to acpi/video* have been backlight issues and IIRC there are reports from desktop system as well. And I think its unlikely those got _BCL entries
<apw> smb_tp, don't suppose they do have _BCL no
<apw> so which mainline updates are in that -12 -> -13 transition?
<smb_tp> Quite a few. But mostly other areas. Lemme check
<apw> Ubuntu-2.6.27-12.28	2.6.27.13
<apw> Ubuntu-2.6.27-13.29	2.6.27.18
<apw> (from leanns list http://kernel.ubuntu.com/~ogasawara/kernel-version-map.html)
<smb_tp> Yep, those are the ones in the changelog as well
<apw> so there are loads in there, so it would be entirly legitimate to ask people to try the mainline kernels 14, 15, 16, 17, 18
<smb_tp> You have lrm for those?
<smb_tp> But ok, for intrepid its a dkms package for nvidia and ati
<apw> no
<smb_tp> It looks very much as those binary drivers are having problems
<apw> and they will fail dismally as the ABI is a mad number i assume
<apw> right ... i guess i will drop off now and reboot into this kernel and see if it hits me
<smb_tp> It might work, but you would need the headers for that mainline kernels, I guess
<smb_tp> Ok
<apw> smb_tp, ok that kernel was fine on my intel based laptop so ... no help there
<apw> smb_tp, we do have headers for the mainline kernels
<smb_tp> Ok, thanks anyways. I try mine here. So it might be an option. I have to fight one of my systems up and then whethher ths works
<apw> smb_tp, hehe always a nightmare ... work damn you machine
<smb_tp> apw, Well I am not innocent. There is never a good time for some maintenance... Got it up now. But I pretty much think this system is just too old for being affected. There is no acpi video driver entry for me and all wrks charmingly _with_ the 177 nvidia driver. :-/
<apw> so we are out of test kit basically for that, down to the bug submitters now
<smb_tp> Look like it. Got some new gear coming but that won't be today
<smb_tp> Darn, there is one other thing different. The good case uses VT7 the bad case VT9. At least for the one reporter were I got logs
<apw> VT9 ?
<apw> who uses VT 9 for anything ever
<Keybuk> I use VT14
<apw> Keybuk, hey you replied on my ifupdown upload that i had missed an update, and essentially need to do it again
<Keybuk> apw: I did, can you remember what I said? :p
<apw> where might i have found that in order to avoid that happening again
<Keybuk> you mean the -Q thing?
<apw> Note that the next upload of modprobe removes -Q entirely
<apw> So you might want to take that into account with your upload ;)
<Keybuk> ahh
<apw> oh its modprobe, hrm
<Keybuk> only by following the IRC discussion ;)
<apw> so thats module-init-tools
<Keybuk> yeah
<apw> so i couldn't have known hmmm
<apw> got a bug number for that one?
<Keybuk> no?
<Keybuk> it's not a bug
<Keybuk> it's a patch we had which was rejected upstream
<Keybuk> after some discussion I decided that upstream was right
<Keybuk> I'll just fix the packages that still use -Q as I go
<apw> hrrmmm ... -Q was discarded ... ok ... so whats the approved form
<Keybuk> modprobe -b <module name>
<apw> and the output?  do we want that?
<Keybuk> if you don't want output
<Keybuk> modprobe -q -b <module name>
<apw> isn't that what -Q brought?
<Keybuk> -Q was like -q but more so, the correct solution was just to fix -q ;)
<Keybuk> turned out the main error we cared about was just the blacklist one, which was added by a patch!
<Keybuk> you'll want || true if you want to ignore failures, of course
<apw> yeah -Q is -q + more slicence
<Keybuk> but then at this point I'd start asking why you're calling modprobe at all
<Keybuk> I didn't actually ask that before
<Keybuk> userspace should never need to call modprobe
<apw> i didn't ask that either!
<Keybuk> it looks like it's doing it for ipv6
<Keybuk> which we build in <g>
<apw> yep, to pull in ipv6, not sure if that might be reasonable
<apw> as in reasonable to probe
<apw> well i think it is built in now
<Keybuk> (and if you didn't build it in - it'll be automatically pulled in anyway because ipv6 has a net-pf-10 alias)
<Keybuk> ie. socket(PF_INET6, ..., ...) results in the _kernel_ calling modprobe ipv6
<Keybuk> well
<Keybuk> modprobe pf-net-10
<Keybuk> which translates to ipv6
<apw> but its reasonable to probe it, builtin or not, if its resonable to probe it when its a module at least
<apw> i can see how this might be a reasonable place to do that as its making new interfaces and the like
<apw> hrrm
<apw> how to tell is the question
<Keybuk> ifupdown (0.6.8ubuntu3) feisty; urgency=low
<Keybuk>   
<Keybuk>   * ifupdown.nw: modprobe ipv6 before configuring it.
<Keybuk>   (Closes LP: #7091)
<Keybuk>  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Fri, 30 Mar 2007 08:54:50 +0200
<Keybuk> that modprobe call is an Ubuntu patch to begin with
<apw> bah
<Keybuk> I suspect looking briefly at this that Fabio's debugging was wrong
<Keybuk> the real problem was that the old modprobe.d "alias net-pf-10 ipv6" line got commented out around the same time
<Keybuk> but hadn't turned up in the kernel yet
<Keybuk> certainly removing ipv6
<Keybuk> and running ifconfig
<Keybuk> brings the module back
<apw> could you send me an strace output of that happening
<apw> i'd like to know why its doing that before i rip out the call
<apw> (thanks)
<Keybuk> how do you mean?
<apw> i meant re-remove ipv6 and then strace the ifconfig which brought it back
<apw> ifconfig source still claims:
<apw> "ifconfig eth0 add ..." does not currently auto-load the IPv6 module.
<apw> but its sounding like its wrong
<apw> wanted to 100% confirm its loading for the right reason
<Keybuk> hmm, let me try this harder
<Keybuk> it may have come back for other reasons (ie. running apps)
<apw> or incoming packets or all sorts
<Keybuk> yeah, maybe
<apw> was one reason i left it in, even so
<apw> now we are checking tho
<Keybuk> if we still need it, then that line should be
<Keybuk> modprobe -q -b ipv6 || true
<apw> right
<apw> a agree with that
<apw> if only i could tell if we need it at all
<apw> arrgg
<Keybuk> ok
<Keybuk> best way to debug this ;)
<Keybuk> move the ipv6 module out of the way
<Keybuk> and reboot
<Keybuk> without any network
<Keybuk> then put the module back
<Keybuk> wait and see if it loads itself
<Keybuk> if not, then do an ifconfig
<apw> and for that i'd need a kernel which doesn't have it in ... pththth
 * Keybuk remembers to stop NM
 * apw guesses Keybuk is testing
<Keybuk> ok, interesting
<Keybuk> ifconfig will only open an AF_INET6 socket if /proc/net/if_inet6 exists
<Keybuk> so it specifically doesn't allow autoloading
<Keybuk> which is a bit odd
<apw> i saw that pathname in it
<apw> ok ... so thats _stupid_
<apw> but for the purposes of this fix, it should stay i guess
<Keybuk> it makes kooky sense
<Keybuk> ifconfig is just written wrong
<apw> does seem so doesn't it
<apw> so for the bug i am fixing would you be happy with it being in there
<Keybuk> it doesn't know what the address is until it knows what support there is in the kernel
<Keybuk> because you don't _say_ inet6 in the ifconfig invocation
<Keybuk> ::1 could be several different types of addresses
<apw> no point in me doing the upload if you are going to be unhappy :)
<apw> hmmm so is it checking for ipv6 to see if the addy should be ipv6 sort of thing
<apw> thats vile.  the bug is that you don't say
<apw> ifconfig eth0 ipv6 ;:1
<Keybuk> even if you say, it doesn't assume ;p
<apw> nnnng
<apw> thats pure-evil
<Keybuk> anyway
<Keybuk> yes
<apw> ifconfig-cryptonite
<Keybuk> that modprobe has to say ;)
<Keybuk> stay
<Keybuk> do you want to do that upload or shall I?
<apw> ok will respin that debdiff and get back to you
<apw> good practice
<apw> Keybuk, there is little enough reason for a kernel dev to do other packages, so its worth me getting my hand in
<apw> Keybuk, ok i've attached a new debdiff to the bug: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/107432
<ubot3> Malone bug 107432 in ifupdown "modprobe -Q is not 'silent enough' / ifup is too picky about return status." [Medium,In progress] 
<apw> has been tested in my ppa on a box i have setup for this bug
<Keybuk> apw: you didn't patch inet6.defn?
<apw> no that file is generated from the .iw file
 * apw goes reconfirm
<Keybuk> ah, I can't remember which way round that is ;)
<Keybuk> you're probably right
<apw> let me make absolutly sure
<apw> yeah it seems to be rebuilt when i do a -b
<apw> but i wonder why its in the package at all if its generated
<apw> Keybuk, this whole package is full of voodoo magic, this spec to .c converter is majorly vile
<Keybuk> I'd run a build and then make the source after the build
<Keybuk> just to make grep happy
<apw> ok ...
<apw> hrm, thats thrown up something odd
<apw> a change gone away, /me investigates
<apw> Keybuk, ahh ok, Jamesw didn't commit the changes to the generated files when he did his changes in 0.6.8ubuntu11, so my diff becomes poluted by those
<apw> i assume you are happy with that pollution 
<apw> (or i guess i could hand hack it off)
<Keybuk> yeah I'm happy with that ;)
<apw> Keybuk, ok its attached to the bug ... hope this one is good :)
<Keybuk> you want sponsorship for that? :)
<apw> heheh please
<Keybuk> apw: uploaded
<apw> Keybuk, you are a scholar and a gentleman
<Keybuk> np :p
<mjg59> Keybuk: http://kernel.ubuntu.com/git?p=scott/ubuntu-jaunty.git;a=commit;h=6c505f59997e6099535e2ea5409fececdaa87a57 - cdc_acm is a USB driver. How would you ever get a situation where the device node and hardware exist, but the module isn't loaded?
<Keybuk> mjg59: I was just being thorough
<Keybuk> there was a char-major-166-* for that one in every single distro's modprobe.conf files
<Keybuk> I'm perfectly happy for ANY of those to be rejected on the grounds of "no, we really don't need that"
<mjg59> I don't think many of them make sense in a udev world
<Keybuk> which serves as equal justification for removing the line from modprobe
<Keybuk> I agree
<Keybuk> but the kernel still has them for most drivers
<Keybuk> in fact, there seems to have been attempts to put them all in where they were missing where the driver has a hardcoded device major
<Keybuk> I figured someone in the moblin world or similar was doing it
<mjg59> Heh
<mjg59> Well, it's all harmless enough
<Keybuk> reminds me that I need to rebase those onto my linux-2.6 tree and send those that don't fall out to lkml, etc.
<mjg59> And they're the kind of trivial patches that can probably just be pushed to Andrew
<Keybuk> (not the option ones at the top, obv)
<mjg59> The PnP table stuff for floppy is also sensible
<Keybuk> yeah
<mjg59> Oh, ugh, I was going to fix wacom today
 * mjg59 goes to do that
<Keybuk> "fix" wacom?
<mjg59> input-hotplug-wise
<mjg59> The driver's basically beyond redumption, but still
<Keybuk> *nods*
<kirkland> rtg: hey, tyhicks just popped in for a bit
<kirkland> rtg: i told tyhicks that we'd like to get the jaunty kernel's ecryptfs sync'd
<rtg> kirkland: I've a conf call in 3 mins
<kirkland> rtg: fun ;-)
<kirkland> rtg: circle back around in a bit?
<rtg> A list of the missing commits would be nice
<kirkland> tyhicks: can you drum that up?
<kirkland> *tyhicks has git magic that kirkland lacks
<rtg> I didn't see much delta in fs/ecryptfs between Jaunrt and Linus tree
<tyhicks> rtg: missing commits from the current jaunty kernel to what's in the current rc tree?
<rtg> tyhicks: right, at least those that make sense
<tyhicks> rtg: will try to come up with a list
<rtg> tyhicks: thanks
<kirkland> tyhicks: i really want to get dmesg totally clean of ecryptfs errors before kernel freeze
<kirkland> tyhicks: https://wiki.ubuntu.com/JauntyReleaseSchedule, April 9th
<tyhicks> kirkland: when is kernel freeze?
<tyhicks> ok :)
<tyhicks> kirkland: I'd also like to slip in the umount_sigs patch that I'm just about ready to send upstream
<kirkland> tyhicks: okay, the exact nature of that is to ....
<kirkland> (I think I know the behavior, just want to make sure)
<tyhicks> kirkland: from the kernel side, we have access to a usage counter in the key struct
<tyhicks> kirkland: when userspace inserts a key, it increments the counter
<tyhicks> kirkland: My best solution is to check to see if the unlink_sigs flag is set at umount, if so, decrement the usage counter twice for the keys used for the mount
<kirkland> tyhicks: my preference would be to leave this out of Jaunty, and let it bake upstream for a bit
<kirkland> tyhicks: i'm happy with the key clearing in the shell script wrapper, and the documentation in the manpages
<tyhicks> kirkland: Ok, I keep forgetting that you are doing this in the shell script
<kirkland> tyhicks: yeah
<kirkland> tyhicks: the kernel stuff will be good stuff
<kirkland> tyhicks: but we're really in bug-fix mode only
<kirkland> tyhicks: feature freeze was several weeks ago
<tyhicks> kirkland: understandable
<kirkland> tyhicks: everything else in the diff between current jaunty and current rc is bugfixes, as i recall
<kirkland> tyhicks: that's mostly what we're looking for now
<Keybuk> rtg: any reason we don't just include fuse in the kernel by default?
<Keybuk> we force load it from /etc/modules anyway
<rtg> Keybuk: it didn't occur to me that was part of the startup. what uses it?
<Keybuk> rtg: GNOME
<Keybuk> and KDE
<Keybuk> e.g. ~/.gvfs
<Keybuk> if it were built into the kernel, it'd help us with a tricky issue of mounting /sys/fs/fuse/connections ;)
<Keybuk> plus we load it anyway, so it saves some boot work
<rtg> Keybuk: I've no real objections, but then I'm not real smart about fuse. Its just a file system driver much like ecryptfs, right?
<Keybuk> right
<Keybuk> ok I'll do a patch
<Keybuk> rtg: you may pull from the usual place (along with the other outstanding patches)
<Keybuk> I'll update userspace
<rtg> Keybuk: will we have /lib/modules/`uname -r` support for modprobe options in karmic?
<Keybuk> how do you mean?
<rtg> Keybuk: I assume you're going to remove all of the current modprobe options in favor of your kernel patches, (HPA for example). I'd like to revert that patch for Karmic in favor upstream, yet retain the ability to change defaults (such as a modprobe option that is specific to a kernel version)
<Keybuk> rtg: change defaults by patching the kernel
<Keybuk> that way, when the kernel options change name or parameters, or the module goes entirely, it'll show up as a merge conflict
<Keybuk> and if people build that module into the kernel, they'll still keep the changed default
<rtg> Keybuk: agreed, as well as remove superfluous settings from /etc/modperobe.d
<Keybuk> users can still override the options if they wish
<Keybuk> but we shouldn't ship anything that does
<rtg> Keybuk: is there a reason upstream doesn't like the MODULE_ALIAS stuff? It appears benign to me.
<Keybuk> how do you mean?
<Keybuk> the series of patches in my repo that add them?
<Keybuk> I'm going to send them upstream shortly
<Keybuk> they're more like SALT than SAUCE
<Keybuk> ie. don't add if they're already there, but don't take away :p
<rtg> I guess I'm wondering why it didn't happen long ago.
<Keybuk> oh
<Keybuk> I suspect they're just maintained by slightly inactive maintainers
<Keybuk> most of the modules have them
<Keybuk> and nobody had caught these ones up
<rtg> ok, then I'm gonna apply them to Jaunty. I had to muck with the 'Auto-load esp module when device opened.' to get it to compile.
<Keybuk> really?
<Keybuk> I did a test compile
<rtg> Keybuk: it was missing a header file
<Keybuk> odd
<rtg> I just pushed, how about rebasing your tree before I pull again
<rtg> for the FUSE patch
<Keybuk> ok let me try that ;)
<Keybuk> rtg: you didn't pick up the mwave one?
<rtg> Keybuk: hmm, don't know why not. 
<rtg> Keybuk: I did an interactive rebase a couple of time, maybe I accidentally dropped it.
<Keybuk> ok
<Keybuk> my branch updated
<rtg> Keybuk: pushed the mwave patch. do you really want to build in fuse on the armel flavours? I'm not sure they all use Gnome.
<rtg> I'll ask amitk or ogra
<Keybuk> I think we do
<Keybuk> there's so little overhead if it's not used
<Keybuk> rtg: pulled, rebased and pushed again
<Keybuk> all that's on top now is the fuse change
<amitk> rtg: they do plan to use gnome
<kirkland> rtg: did you ever com back around?
<kirkland> tyhicks: did you get rtg those commits?
<tyhicks> kirkland: working on it, today is not the best day for me, but I'm getting there
<kirkland> tyhicks: okay, cool
<tyhicks> kirkland: unfortunately, they are mostly changes that touch more than just ecryptfs
<kirkland> rtg: is this going to make next week's alpha?
<kirkland> tyhicks: oh
<rtg> kirkland: it could if ready by Monday
<kirkland> tyhicks: is that doable?
<rtg> and if there are no ABI bumpers in the patches
<kirkland> tyhicks: can we shoot for Friday, just to be safe?
<kirkland> tyhicks: know of any abi bumpers?
<tyhicks> kirkland: not sure just yet, still trying to just compile the list
<kirkland> tyhicks: k
<tyhicks> kirkland: I think I can have a list by Friday, but I won't be able to do any backporting that is required
<kirkland> tyhicks: k
<TheMuso> pgraner: Re the beep situation with your notebook, if I was to send you the patch I got from fedora, are you able to build your own kernel and test? If not, I can put one up somewhere for you.
<pgraner> TheMuso: sure won't get to it until Sat... I'm slammed tomorrow *sigh*
<pgraner> TheMuso: just post the patch to the bug and I'll get to it soonest
<TheMuso> pgraner: I'll attach it to the bug then.
<pgraner> TheMuso: :-)
#ubuntu-kernel 2009-03-06
 * dandel pulls ppa of latest 2.6.29 kernel.
<dandel> ><; fun... regression from irq changes from acpi persists.
<dandel> 0o fun... should i report the bug pertaining to acpi_irq to the ubuntu launchpad or the bugzilla of the linux kernel?
<dandel> does anyone know where i can get the 2.6.25 and 2.6.26 kernels as ubuntu packages?
<dtchen> dandel: if the bug is in an Ubuntu kernel, use LP
<dandel> dtchan it affects the kernel-ppa also
<dandel> 2.6.29 gives a different function error string when compared to 2.6.27 lol
<dandel> and i can't use lp for this, my bug i had for it, which is not solved got labeled as duplicate ( although the bug evolved as i found more issues between the 2.6.24 and 2.6.27 kernels )
<dtchen> it looks like 2.6.2[56] aren't in /mainline; they're not the base of any supported Ubuntu kernel releases
<dtchen> (discounting -ports)
<dandel> bug # 294323 is when i first found issue
<dandel> i kept it updated as best i could, in hope that it would be unflagged and fixed.
<dandel> hmm... actually it's faster than 2.6.27 on responding to change, however it still is not as fast to notice the change in the power plug as 2.6.24
<dandel> however, it still has issue of automatically kicking out of suspend when plugged in for some reason
<dandel> first suspend attempt always fails, then second one works
<amitk> dandel: if the problem is upstream, you could update the LP bug saying so, so that the triager might link it to bugzilla.kernel.org. Or, you could directly report it there.
<dandel> amitk, the issue is mainstream and i believe it appeared somewhere in 2.6.25 or 2.6.26
<amitk> dandel: I suggest updating the bug with this info _and_ if possible ping ogasawara who is the kernel QA
<dandel> amitk, i'll just make a new bug and make sure it refers to the old one on the lp tracker.
<dandel> wow... this is a new one 0o
<dandel> which lead to corrupted low memory ><;
<amitk> apw: is there way to revert things in a git index?
<amitk> IOW, revert the results of a 'git add .'
<apw> you can update the index as often as you like
<apw> if what was in the index was whats in a commit you can get that back
<apw> if its was an uncommpitted previous add, then no
<amitk> apw: it was uncommitted
<apw> so i believe that intermediat there is no longer linked
<apw> in theory it will still be in your object store
<apw> in a loose object ... so if there is something distinctive in it you might be able to find it
<apw> ie. its likely high effort, but it might be important enough
<amitk> I did "git am <mbox>; git reset --soft HEAD^;" But this leaves everything cached in the index. I want it to go back to the uncommitted state and allow me to add files interactively
<amitk> apw: probably not worth it trying to recover the object
<apw> hmm so i think you are saying you want the index to be HEAD^
<amitk> 'git add --interactive' allows this, but it is quite cumbersome to do it manually
<amitk> apw: yes
<apw> so i think you want git reset --mixed
<dandel> amitk, reported new bug as bug #338701
<ubot3> Malone bug 338701 in linux-meta "acpi_irq is not set properly." [Undecided,New] https://launchpad.net/bugs/338701
<apw> if you are already done the --soft
<amitk> dandel: thanks
<apw> i think a git reset --mixed HEAD might do the trick ... as you have already moved your HEAD back one
<dandel> it didn't add the mesg log tho.
<apw>        --mixed
<apw>            Resets the index but not the working tree (i.e., the changed files
<apw>            are preserved but not marked for commit) and reports what has not
<apw>            been updated. This is the default action.
<apw> so if a git show HEAD shows the commit against which you are trying to work
<apw> (now) then i think a git reset --mixed HEAD would reset the index only
<amitk> apw: --mixed for the win!
<apw> cool
<amitk> thanks
<apw> i always wondered why you might want that, now i know
<amitk> useful split out a patch :)
<amitk> *useful to
<apw> indeed :)
<amitk> apw: apparently it is the default action... Only I wasn't trying to be so smart
<apw> heh so it is, i think i use --hard almost exclusivly
<apw> i've used --soft rarely, and the default never
<Keybuk> apw: we did talk about an intrepid backport of the floppy patch, right?
<apw> Keybuk, yep, i am on the case
<Keybuk> ok, I'll update the bug
<apw> its building in my build far right now
<apw> i'll be doing it in a sec anyhow
<Keybuk> sure, just to track it for SRU purposes
<apw> Keybuk, i'll handle it .. .i am pushing some test kernels for intrepid now
<apw> when we have some test acks i'll push it through the SRU process
<apw> (of course it cannot fail as its an obvious patch but hey)
<apw> cking, battery discharge when suspended ... is there a sensible value we can make as the boundary from failure to success?
<cking> apw, not sure.. let me think for a minute about this.
<apw> a test isn't much of a test if it doesn't tell you if it was good or bad
<cking> probably not. in suspend you are keeping memory alive, and that's dependant on how much memory you have and so forth
<apw> yeah i guessed as much
<cking> the issue which is important is how much current is being drawn when in hibernation. One expects that to be zero - if it's not then something is not good
<apw> very true, so perhaps this test will become more useful once we start doing hib stuff ...
<cking> apw, yep. I think it should be on the agenda for hibernation testing. I wonder what horrors one will find...
<apw> a whole heap
<cking> the tricky part will be to factor out which part of the system is doing the current stealing
<rtg> apw: you have positive results on https://bugs.launchpad.net/bugs/193970. please push the patch
<ubot3> Malone bug 193970 in linux "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Medium,Confirmed] 
<apw> rtg thanks for the heads up.  i believe one of the testers was a Jaunty user, the other I am unsure.  so i propose pushing the jaunty one and holding intrepid until i have some solid results on there?  ok?
<rtg> apw: wfm. Jaunty is the only thing I'm intereted in right now.
<apw> fair enough... will get it in shortly
<tx2650> Hi. I can`t build promise tx2650 driver for the 8.10 kernel. Has anybody done that?
<wmat> tx2650: did you see this -> http://www.colinmackenzie.net/index.php?option=com_content&view=article&id=12:promise-satasas-driver-update-tx4650tx2650&catid=8:rotator&Itemid=7
<tx2650> yes. Tryed to build with warious patches, somebody said the .28 kernel supports it so I build that kernel and it didnt detect it, so baiscally I`m running out of optiones.
<tx2650> options*
<tx2650> from colins site I get  Error 2 on compilation
<tx2650> I noticed another one complaining about failed build on .27 kernel, so, it`s not my clumsiness
<wmat> I see success reports using 2.6.24-16
<wmat> but that doesn't help you much
<tx2650> :)
<tx2650> I had to upgrade to 8.10....Å¾
<tx2650> is there a way to downgrade to 8.04 or could I just build a .24 kernel?
<wmat> tx2650: just download the old kernel via synaptic or apt-get and install it. Then pick the old kernel at boot.
<tx2650> I tried that already but it says the package has no available version. I suppose I must set sth in sourcelist
<tx2650> how can I tell Intrepid to look for packages in Hardy repositories?
<wmat> tx2650: https://help.ubuntu.com/community/DowngradeHowto
<ion_> What does SAUCE mean in the changelog?
<rtg> ion_: its a patch that is not currently upstream.
<ion_> Whatâs the etymology? :-)
<rtg> as in 'special sauce'. I use it too keep track of patches that diverge from upstream
<ion_> Alright, thanks.
 * bradF is back
<NCommander> Are kernel mainline builds available for 2.6.29 kernels?
 * NCommander is having issues finding them.
<dtchen> NCommander: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<NCommander> thank you!
<dandel> dtchan, on the 2.6.29 kernel should i report bugs pertaining to that to the linux mainline?
<dandel> considering i am using the ppa kernel sources.
<dtchen> dandel: yes; please be sure to note the pedigree clearly in the bug report  (also, it's dtchEn)
<dandel> shows as all lower case here.
<dtchen> yes, it is lowercase, but it's an 'e' not an 'a'. Anyhow, no big deal. My nick-highlight just doesn't trigger if you misspell it.
<dandel> i did note the issue on 2.6.27 kernel, however i can't confirm the 2.6.26 and 2.6.25 kernel between long term.
<dandel> so it's tougher to track the originating kernel.
<dtchen> did you try the mainline .24 base?
<dandel> 2.6.24 worked fine
<dandel> so i haft to find 2.6.25 and 2.6.26 which are both not on the mainline package list.
<dtchen> well, only three kernel versions, then. Not too shabby ;-)
<dandel> i posted latest 2.6.29 dmesg but that changed when compared to 2.6.27.
 * dandel combs the changelogs as best i can to figure out where the possible change happened.
<dandel> !bug 338701
<ubot3> Factoid bug 338701 not found
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
#ubuntu-kernel 2009-03-08
<wgrant> Is there any chance of seeing a more recent aufs in Jaunty's kernel? I see something on the ML about recent versions of aufs1 requiring changes to build with 2.6.28, but I have custom kernels with it working fine.
<kjdro> hello. i'm using ubuntu 8.10 and i have this problem:usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> meaning .. to copy 2 GB of information to a 4GB usb stick takes a day .. 
<kjdro> can anyone help me speed up the transfer.. i'm trying to untar debian base system on to a flash drive
<kjdro> using ext3 Tryed first on ubuntu 8.04 and was slow.. and some forums i'w read that ubuntu 8.10 solved the issu.. so i downed 8.10 and used live cd ... whit boot option pci=routeirq .... still nothing...
<anubhav> kjdro:it works okay with windows?
<kjdro> sadly yes
<kjdro> but ... i cant untar to ext3 there...
<anubhav>  kjdro:why not untar it onto a FAT partition and then copy
<anubhav> kjdro:also file a bug with all the required info
<kjdro> well i need the debian base station on stick to boot up my debian-slug.. so i need ext3 file sistem... 
<kjdro> and well.. i tryed both aproaches.. untar in on hdd witch takes a few seconds
<anubhav> kjdro:have you filed a bug report?
<kjdro> then there is a bug files.. it always has been ... google it.. :D there are dosns.. 
<kjdro> the only problem is .. i cant find a workinf solution
<kjdro> working
<kjdro> even more sadly... i'm using livecd. no hdd space to install ubuntu
<kjdro> looking for a solution to speed up usb transfer without restarting 
<anubhav> kjdro:whats the output of  hwinfo --usb
<kjdro> well this: > block.5: /dev/sdc  .. and it hangs after 
<kjdro> hold on.. i see some movement
<kjdro> ok.. so this may take a while
<kjdro> > block.5.1: /dev/sdc geo  
<kjdro> i'm still copying some info on the stick.. really dont want to interupt... what is strange... is ... i tryed untaring .. and each time i start up again and mount usb drive.. it looks empty... like nothing has been copyed on it
<kjdro> > block.5.2: /dev/sdc serial 
<kjdro> ok so i gess .. this is a *bump* again.... yo alex_joni: che faci...  
<kjdro> alex_joni: esti ?
<kjdro> nvm
<kjdro> anubhav: are you there? take a look at this:
<kjdro> http://paste.ubuntu.com/128179/
<kjdro> this is the otuput....
<anubhav> kjdro:okay
<kjdro> everithing seems alright ?
<kjdro> to me at least it dose 
<anubhav>  kjdro:can you start a thread on ubuntuforums and provide the output of dmesg,lspci -vvn ?
<kjdro> of course
<anubhav> okay once you do that send me the link of the thread
<kjdro> http://paste.ubuntu.com/128181/
<kjdro> this is lspci
<kjdro> yeah well
<kjdro> in dmesg you could see a lot of:  usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> what specificly interest you so i use grep ...
<kjdro> or if you want all i could redirect output to a file 
<kjdro> witch is it ?
<anubhav> u can try  dmesg|tail 
<anubhav> okay complete dmesg will be better
<kjdro> yeah well:
<kjdro>  dmesg | tail
<kjdro> [43847.448129] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [43877.924184] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [43908.424156] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [43938.940085] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [43969.484291] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [44000.092150] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [44030.521669] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [44060.992622] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [44091.500371] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> [44122.144138] usb 8-1: reset high speed USB device using ehci_hcd and address 4
<kjdro> as i sad... :(
<kjdro> some 2 pages of that ore more in the full output of dmesg
<kjdro> well .. about the forum.. i read now.. well... kinda lack the time... right now.. 
<kjdro> my copy is at 41%.... since 9:00 am this moring .. now it's 14:09
<anubhav> can you try a plugging your device to a different port?
<kjdro> well only if i interupt the copy proces.. witch understandably is not what i want to do.. only if there would be a way to restart the copy where it left of.. skiiping the already copied files
<kjdro> is there ?
<anubhav> i think cp -u
<kjdro> hmmm ...
<anubhav> u can just check the man page
<kjdro> copy only when the SOURCE file is newer than the destination file or when the destination file is missing
<kjdro> your right..
<kjdro> now how do i copy multi structured paths... anyway .. give me a min to ready man cp
<kjdro> -r ...
<kjdro> ok
<anubhav> do you copy using the gui?
<kjdro> hmm final thought... will a sistem boot up if i copy all the files it needs using cp .. with dircetory structure to the root partition ?
<kjdro> i am usiong mc's copy
<kjdro> midnight commander
<anubhav> with cp you have to be carefull that it copies all symbolic links etc
<kjdro> aha... so best would be if i untar the file system directly... shiut...
<anubhav> yeah
<lesshaste> how do I get alt-sysrq to work in ubuntu?
<doctormo> I'm looking for advice, I have a serial device I'm going to try and reverse engineer. It's a USB <-> Serial chip which produces a /dev/ttyUSB0 as expected.
<doctormo> Given that the windows program works in wine, should it be easy to watch the io of wine to sniff out the protocol?
<JanC> is there any extra protocol involved?
<doctormo> JanC: Yes, the one that sends the images to be displayed on the device via serial.
<doctormo> I'm trying to find a guide on logging a processes io, but not having much luck
<JanC> ah, so there is more than the usb <-> serial chip
<doctormo> JanC: Yes, the ttyUSB0 is sym linked to wine's com1
<JanC> i guess there must be something that experienced reverse engineers use  ã
<doctormo> did you just use the katakana Shi as a smilie face?
<JanC> yep
<doctormo> are you Japanese?
<JanC> no, its use as a smiley probably started inside ubuntu-nl (although I'm not sure about that)
<doctormo> heh, oh well
<doctormo> Back to logging serial io... still no results in google. keep trying
<JanC> the "easiest" way would be to have a fake serial device that logs everything and sits between the app & the real hardware driver
<JanC> or maybe the driver that creates the ttyusb devices can already do that?
<johanbr> doctormo: There's something called usbsnoop for windows. It might work under wine.
<JanC> johanbr: as the app under wine accesses it as com1, that probably won't work?
<JanC> (wine doesn't know this is an USB device)
<JanC> doctormo: http://linux.die.net/man/1/slsnif sounds useful
<JanC> doctormo: and http://www.suspectclass.com/~sgifford/interceptty/
<doctormo> thanks
#ubuntu-kernel 2010-03-08
<zetheroo> how does one get bug fixes into the official kernel?
<lifeless> same as any other package, put a patch in the bug
<zetheroo> ok well this is the bug I am talking about 
<zetheroo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/278648
<ubot3> Malone bug 278648 in linux-ubuntu-modules-2.6.24 "[regression]snd-hda-intel sound input does not work at all with Conexant CX20549 (Venice) chips " [Undecided,New] 
<zetheroo> it's been almost a year since a fixed has been out ... and now it's come to updating to a kernel from a ppa repo ... 
<zetheroo> so what else needs to be done here?
<lifeless> crimsun: ^ you are the assignee
<zetheroo> not talking to me ... right!? 
<lifeless> zetheroo: thats right. Asking the bug assignee to comment.
<zetheroo> lifeless: oh ok ;)
<zetheroo> so there is nothing really that I can do ... 
<crimsun> zetheroo: most probably that needs to get into 2.6.32.y before it can get into Lucid's kernel
<crimsun> zetheroo: foremost, however, it needs to make it into upstream sound-2.6 master
<crimsun> zetheroo: I've been extremely busy with other bugs, but I will look at it this week.
<zetheroo> ok, thanks so much 
<zetheroo> anything I can do?
<zetheroo> I am no programmer :P
<zetheroo> just a humble user ... 
<zetheroo> crimsun: are you employed by Canonical ?
<zetheroo> hope that is not a rude question
<slytherin> is there any way pmu_battery module could be loaded on PPC by default? Without this module the power management does not work at all.
<tgardner> JFo, are you aware of any reports of Lucid LBM wireless drivers being unable to read firmware?
<JFo> not off the top of my head tgardner, but I can look
<tgardner> JFo, 'preciate it
<JFo> my pleasure
<cnd> apw: I've got some questions on how the mainline kernel is built
<cnd> you got a few mins?
<tgardner> cnd, maybe by thursday.
<cnd> heh
<apw> cnd wassup :)
<smb> tgardner, If its atheros there was some time with problems. But lucid should be past that
<cnd> apw, I tried using make-kpkg to make a custom kernel package based on mainline git tree
<apw> does make-kpkg work on any of our packages?
<tgardner> smb, iwlagn LBM refuses to read firmware.
<cnd> I found that it mostly worked except that the debian control scripts that come with make-kpkg are old and don't work right
<cnd> so a kernel from kpkg won't generate an initrd image
<smb> tgardner, Thats something different then I guess
<apw> i thought debian packages were supposed to contain them and indeed ours do?
<cnd> apw: so, I was wondering how your mainline builds are built
<cnd> apw, the initrd is generated by the postinst script
<tgardner> smb, yep, that something different, though I suspect its a generic problem. some interaction with udev but I haven't quite pinned it down.
<JFo> tgardner, is it in linux-backports-modules-2.6.31? or later than that?
<tgardner> JFo, for Lucid
<JFo> ah, I see
<JFo> one sec
<apw> cnd they are built by checking out the commit of interest, then checking out debian* from the tip of the release you want them built for, then rebuilding the configs and building
<smb> tgardner, Well the intermediate problem on atheros was the added EEPROM checking code which was buggy for a certeain time
<smb> tgardner, We still need to get the new LBM up for karmic to fix that
<tgardner> smb, nah, this is a straight up failure after calling udev/firmware.
<cnd> apw: how is versioning done, since the tip of the current release has the changelog for that release?
<cnd> apw: or, where's the scripts that manage all this, I could just poke around myself
<apw> versioning is overridden with somethign c-o-d specific. -999 abi and the date/time as upload number
<apw> cnd, scripts are in the kernel-tools repo, in the mainline-builds directory
<cnd> ahhh
<JFo> tgardner, I only see 5 bugs for .32 http://bit.ly/cN10Nh
<cnd> we still need to figure out what to do with kernel-package though... I'll try to figure something out
<JFo> but there is the issue of whether there are some hiding in the 10k
<JFo> that weren't reported against LBM
<tgardner> JFo, yeah, but it looks like nobody has encountered this firmware issue. 
<JFo> right
<JFo> only bug I have found in the general population was a firmware filename issue
<cnd> cking: will arrandale be supported in karmic at any point? or just lucid forward?
<cnd> cking: meaning full platform support (audio, usb, processor, graphics, etc.)
<smb> apw, Just FYI, todays c-o-d mainline kernel explodes into my face. Though thats somewhat expected in the merge window
<apw> smb, completely expected :)
<smb> apw, A pity as the kvm patches got merged there. :-P
<cking> cnd, I'm only focusing on the low-level issues with arrandale in Karmic at the moment (e.g. HPET,  TLB workarounds, TSC warping etc)
<cnd> cking: I've got a few people who opened bugs about platform issues with arrandale on friday
<cking> cnd, that don't surprise me
<cnd> cking: so there will be support, but not ready yet?
<apw> smb, ahh :/
<tgardner> apw, I'm pushing stuff to your LBM repo, added a preempt flavor. -mta is gonna need some love as well.
<tgardner> -meta*
<apw> tgardner, ok ... i can handle -meta
<apw> so perhaps i'll aim for for starting the process first thing tommorrow
<tgardner> apw, I'm seeing a lot a -prepare noise in LBM so I'm gonna have a look at that as a possibility for this firmware issue
<apw> tgardner, ack
<apw> tgardner, i pulled in your two previous updates and released them so we could get on testing the drm update
<apw> i am expecting a respin of everything anyhow for tomorrow
<tgardner> apw, saw that
<apw> tgardner, so if i get you a test image for the qcm-msm i assume you can test it?
<tgardner> apw, no hardware yet.
<apw> tgardner, oh ... hrm 
<apw> so i'll just rebase it, and build it, and call it good
<tgardner> apw, yep
<tgardner> apw, red herring in LBM. all the build noise is from ALSA
<Sarvatt> cnd: thats the intended behavior of kernel-package 12.x unfortunately :(
<cnd> Sarvatt: why is that?
<Sarvatt> you have to manually add the hook scripts to /etc/kernel
<cnd> Sarvatt: what if we put the ubuntu control scripts into the ubuntu kernel-package package?
<Sarvatt> /usr/share/doc/kernel-package/README.gz explains it
<Sarvatt> i think its a *horrible* choice but the author wanted it that way, i still havent got it fully set up right and i just build the initrd and update-grub manually after install
<cnd> Sarvatt: that's a huge readme, can you just explain what you are meaning?
<cnd> Sarvatt: I've gotten make-kpkg to autogenerate an initrd for me
<cnd> the problem was the included debian/postinst doesn't work in ubuntu
<Sarvatt> oh really?
<Sarvatt> /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs
<Sarvatt> that doesn't work?
<cnd> Sarvatt: I didn't see that file, but I'll take a look
<cnd> Sarvatt: I bungled up the first attempt I made at the correct debian/ scripts
<Sarvatt>  cp /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs \
<Sarvatt>     /etc/kernel/postinst.d/
<Sarvatt>  cp /usr/share/kernel-package/examples/etc/kernel/postrm.d/initramfs \
<Sarvatt>     /etc/kernel/postrm.d/
<cnd> so I'm rebuilding
<Sarvatt> Sorry for the long paste there
<cnd> we'll see how it turns out
<Sarvatt> then in /etc/kernel-img.conf you add 
<Sarvatt> postinst_hook = update-grub
<Sarvatt> postrm_hook   = update-grub
<cnd> Sarvatt: so there's some hooks that are added to run in the postinst script?
<Sarvatt> i haven't tried that yet, just found this readme yesterday but i've had this problem with kernel-package since 12.x came out over a year ago :(
<Sarvatt> yeah all the hooks are now in /usr/share/kernel-package/examples and you have to manually copy them to /etc/kernel/whatever for them to be added during make-kpkg
<cnd> Sarvatt: ok, so that's the upstream kernel-package way it seems
<cnd> I want to make a mainline kernel build that mimicks the ubuntu kernel as much as possible
<cnd> for that to work, I think I need to just grab the ubuntu kernel's control scripts
<cnd> and override the make-kpkg control scripst
<cnd> so perhaps we could ship the ubuntu control scripts as part of the kernel-package package
<cnd> not enabled by default
<cnd> but still available for you to use
<Sarvatt> doing it the mainline kernel way uses a totally different workflow than make-kpkg would since it requires the ubuntu git repos being around, why dont you just use the kernel-tools stuff instead of kernel-package?
<Sarvatt> I use git pull && cp /boot/config-whatever .config && make oldconfig && make-kpkg clean && CONCURRENCY_LEVEL=3 INSTALL_MOD_STRIP=1 fakeroot make-kpkg --initrd -append-to-version=-sarvatt kernel_image kernel_headers >buildlog.txt 2>&1 && cp ../*.deb ~/downloads/current/ && cp buildlog.txt ~/downloads/current/
<Sarvatt> straight from an upstream linux-2.6 directory
<cnd> Sarvatt: the reason for what I'm doing is to try to do a git bisect between .32 and .33
<cnd> probably doing a real make-kpkg like upstream would work fine
<cnd> but I want as few changes from ubuntu as possible
<cnd> so I want to use the ubuntu .config
<cnd> and packaging scripts
<Sarvatt> actually just using the mainline daily kernels is a good way to bisect without manually compiling
<Sarvatt> just start the bisect in your local tree, and find the date of each recommended commit and install the mainline daily from that day
<cnd> Sarvatt: that's good point... I'm not sure why I didn't think of that earlier :)
<cnd> though either way, figuring out how to make an "ubuntu-like" kernel using make-kpkg and documenting it is useful :)
<cking> smb, your ACK to the touchpad patch was understandably done with much consternation and gnashing of teeth 
<smb> cking, Its shocking how much bad hw is out there
<cking> it's shocking how much of it comes our way ;-)
<smb> cking, Or only we care to do it automatically. I guess it could be worked around by a module parm. Or is it only possible that way?
<smb> cking, I know there is a i8042.noloop...
<cking> I don't believe it is possible to work around it - an there are a shed load of broken bits of hardware coming out nowadays
 * smb wonders how many millicents you safe by not implementing the auxloop command
 * cking wonders if other OSes check for AUX LOOP
<cking> Hrm, looks likle the i8042.noloop may be a workaround - but it's hard for the user with a default install to figure that is needed when their mouse doesn't work
<BenC> Is it a known problem that when my laptop comes back from suspend, Xorg crashes?
<BenC> and I get the "Your X is in low res mode"
<manjo> BenC, what laptop is it ?
<manjo> nvidia intel graphics ?
<BenC> dell latitude 420, intel
<BenC> D420
<Keybuk> not known then
<BenC> latest lucid
<Keybuk> my D420 works ok
<BenC> easily reproducible, so I can get more info
<cnd> some nvidia users were seeing the same thing
<cnd> started this past week
<cnd> I was going to take a look at it myself cause I thought it may be a driver issue
<BenC> it's been happening for me for longer than a week
<BenC> maybe 3 or so
<cnd> BenC, got a bug report?
<BenC> not yet
<cnd> JFo: call me back?
<ogasawara> JFo: did you figure out why 531511 isn't showing on the list?  I think you need to add "linux-backports-modules-2.6.31" to the longnames list in KernelBugList.py
<ogasawara> JFo: I can send you a quick patch if that'll help
<JFo> yeah, I think that is the reason the numbers haven't been adding up
<JFo> if you don't mind
<ogasawara> JFo: sure, just a sec
<JFo> thank you
<cnd> cking, apw: that mem=nopentium fix, is that enabled automatically in lucid kernels?
<cking> no
<apw> cking, yes
<apw> commit 97684193e8c6fea095adcc4928f389b090559fc6
<apw> Author: Colin Ian King <colin.king@canonical.com>
<apw> Date:   Fri Feb 19 15:16:35 2010 +0000
<apw>     UBUNTU: Disable 4MB page tables for Atom, work around errata AAE44
<apw>     
<apw>     BugLink: https://bugs.launchpad.net/bugs/523112
<ubot3> Malone bug 523112 in linux "Intel Atom CPU can oops because of bug listed in Intel errata AAH41 and AAE44" [Medium,Fix committed] 
<cnd> apw, which kernel is that in?
<cnd> I'm seeing some odd freezes on my new dell mini
<apw> -16
<cking> oh yes, my slip
<cnd> apw, ok I don't have anything to report on that kernel (yet...)
<tgardner> apw, you OK with me uploading Lucid LBM ? it'll fix firmware load problems that have existed for the last couple of revs
<apw> tgardner, sure
<tgardner> apw, this'll also have a preempt flavour (in case you've not done -meta yet)
<apw> i'll get meta sorted out now
<apw> let me know when its uploaded
<apw> is it pushed?
<tgardner> yep
<tgardner> gimme 10 minutes and I'll have it uploaded
<cnd> tgardner: what was the fw issue?
<tgardner> cnd, new compat firmware load module plus new udev rules
<tgardner> apw, bombs away. lunchtime
<cnd> apw, still around?
<ogasawara> JFo: I know we're tagging bugs "needs-upstream-testing", I can't remember if we're then tagging ones that have been tested.
<ogasawara> JFo: something like "tested-upstream"
<JFo> I don't remember, but I think we have simply been removing the tag. I actually haven't been using it
<JFo> I need to
<ogasawara> JFo: yah, I'm wondering if you'd prefer we just remove the tag or tag them something like "tested-upstream"
<JFo> oh, my preference would be  'tested-upstream
<JFo> '
<JFo> so I can isolate those
<JFo> programmatically
<ogasawara> JFo: cool, I'll pass on the info
<JFo> only thing is, we run the risk of having bugs with tons of tag clutter
<JFo> cool
<cnd> tgardner: I though karmic didn't require an sru for linux-firmware-nonfree because it's in multiverse?
<cnd> linux-firmware may need an SRU for linux-firmware though...
<cnd> for jaunty that is
<tgardner> cnd, ah, I can never remember what needs 'em. I'm sure Martin will tell you
<cnd> tgardner: so the jaunty and karmic stuff has been uploaded where? to -proposed?
<cnd> I don't see them on https://launchpad.net/ubuntu/+source/linux-firmware-nonfree
<tgardner> cnd, they're being held until released by an archive admin. should happen by tomorrow...
<cnd> tgardner: ok. I'll add an SRU note in the bug too
<cnd> thanks
<cnd> tgardner: also, why did you need to change the versions?
<cnd> for jaunty and karmic
<cnd> I thought the packages had new version numbers
<tgardner> cnd, policy is to add a minor version for existing package within a pocket. a good example is linux-firmware which exists in both karmic and lucid. neither can have the same version number except for the initial sync.
<cnd> tgardner: so that basically means that once a package has been released for a new release (i.e. lucid), all packages for the previous release have to increment the minor version?
<tgardner> cnd, correct
<cnd> k
<cnd> tgardner: I noticed that no one is subscribed to linux-firmware-nonfree bugs
<cnd> should the c-k-t or kernel bugs teams be subscribed, like is done for linux-firmware
<tgardner> cnd, well, I'm not real interested in supporting linux-firmware-nonfree (for obvious reasons)
<cnd> tgardner: ok
<tgardner> so, I _don't_ want to be subscribed. I'd rather have community take care of it.
<cnd> I understand that sentiment :)
 * cnd thinks we should get some mythbuntu people to take a look at it, since it's almost all dvb bugs
<tgardner> works for me. I'm happy to sponsor uploads, but I don't want to put anymore time into it then that
<cnd> tgardner: did you mean to mark bug 446454 as fix released?
<ubot3> Malone bug 446454 in linux-firmware-nonfree "Move dib0700 1.20 firmware out of linux-firmware-nonfree" [Undecided,In progress] https://launchpad.net/bugs/446454
<cnd> it's still in progress by you
<tgardner> cnd, the launchpad bot will change its state when the archive admin releases it
<cnd> hmmm... guess the package is taking a while to release then
<tgardner> lemme chack, I can't remember all of these versions
<tgardner> cnd, huh, dunno why its in progress. looks like its done to me.
<cnd> yeah, that's why I thought something fishy was going on
<tgardner> lemme chanck the changelog
<tgardner> check*
<jono> hey all
<jono> I need to install an upstream kernel to test a bug
<jono> I was given http://kernel.ubuntu.com/~kernel-ppa/mainline/ as a link 
<jono> is there a PPA line I should add to sources.list to test?
<tgardner> jono, nope. you gotta do it by hand.
<tgardner> dpkg -i ...
<jono> tgardner, just install the package?
<jono> cheers tgardner
<jono> I am going to see if I can provide any more info on https://bugs.launchpad.net/bugs/525902
<ubot3> Malone bug 525902 in linux "Network card keeps dropping the connection" [Undecided,Confirmed] 
<tgardner> jono, yep. we figured if you're not savvy enough to install a deb by hand, then you probably shouldn't be running mainline crack.
<jono> tgardner, wise
<jono> I assume I install -headers before -image?
<tgardner> jono, I just read the bug. Instead of mainline try linux-backports-compat-wireless
<jono> tgardner, is that in the Lucid archive?
<tgardner> jonhang on, I'll get the proper name
<jono> cheers
<tgardner> jono, linux-backports-modules-wireless-lucid-generic
<tgardner> but wait until tomorrow. I just uploaded a firmware fix today and its still building
<jono> tgardner, ahhh cool
<jono> will do
<jono> so are you aware of this bug?
<tgardner> jono, thats essentially 2.6.33 bits
<jono> cool
<jono> it just worried me that this could take down a bunch of T400s
<tgardner> jono, still reading the bug
<tgardner> ah, shirley-peak
<jono> ahhh
<lifeless> is there any chance of getting linux-backports-compat-wireless in the netboot img ?
<tgardner> so pgraner is talking to robbie about how to pursue this. its caught mark's interest as well
<jono> tgardner, this bug has?
<tgardner> not this bug per se, but the 5K intel series issues
<jono> tgardner, gotcha
<jono> well if I can help do any debugging, just give me a yell
<tgardner> jono, what kind of AP do you  have, and is it set for 802.11n ?
<jono> tgardner, I have had this issue with multiple access points
<tgardner> jono, same room I assume?
<jono> tgardner, I have had the issue in the same room and when not in the same room
<jono> most typically the AP is in a different room
<tgardner> jono, as long as its pretty close it ought to work fine
<jono> tgardner, so is this bug an issue with range?
<jono> in Karmic I had exactly the same AP and network card and no bug
<tgardner> jono,  I don't think so, it appears to be related to the 5K adapter. The 3K and 4K series seem to work fine.
<tgardner> jono, well, lets see if tomorrow's LBM makes any difference.
<jono> tgardner, no worries, I will test tomorrow and then update the bug
<tgardner> k, I'll get subscribed
<jono> thanks tgardner :)
<pgraner> crimsun: you about?
<bdmurray> JFo: https://bugs.edge.launchpad.net/~kernel-bugs/+patches
<JFo> bdmurray, excellent, thank you. This looks great
<bdmurray> JFo: well, thanks the launchpad team and bryceh - I was just pointing it out ;-)
<JFo> heh
<JFo> yep, thanks to them then, and thanks for pointing it out
<bryceh> I just wish that it gave a way to exclude the 'Fix Released' patches...
<JFo> bryceh, yeah, I noticed... it is cool though. I can work with it
<JFo> :)
#ubuntu-kernel 2010-03-09
<crimsun> pgraner: hi
<imbrandon> ok so i did a bit of googlin but my google-fu dosent seem to work, since my upgrade to 9.10 ( headless server ) my nic seems to goto sleep after a while ( even with activity ) , is there a way to tell the kernel/driver NOT to put the nic to sleep ?
<imbrandon> ever
<JFo> imbrandon, what hardware?
<imbrandon> JFo, via c7 proc ( x86 ) and the network cards are a rtl and a rine-ii
<imbrandon> both cards seems to be effected
<imbrandon> JFo, here is the output of uname,lspci,and /proc/cpuinfo
<imbrandon> root@enterprise:~# uname -a
<imbrandon> Linux enterprise 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 GNU/Linux
<imbrandon> root@enterprise:~# cat /etc/issue
<imbrandon> Ubuntu 9.10 \n \l
<imbrandon> root@enterprise:~# cat /proc/cpuinfo 
<imbrandon> processor	: 0
<imbrandon> vendor_id	: CentaurHauls
<imbrandon> cpu family	: 6
<imbrandon> model		: 10
<imbrandon> model name	: VIA Esther processor 1500MHz
<imbrandon> stepping	: 9
<imbrandon> cpu MHz		: 1496.425
<imbrandon> cache size	: 128 KB
<imbrandon> fdiv_bug	: no
<imbrandon> hlt_bug		: no
<imbrandon> f00f_bug	: no
<imbrandon> coma_bug	: no
<imbrandon> fpu		: yes
<imbrandon> fpu_exception	: yes
<imbrandon> cpuid level	: 1
<imbrandon> wp		: yes
<imbrandon> flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx up pni rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
<imbrandon> bogomips	: 2992.85
<imbrandon> clflush size	: 64
<imbrandon> power management:
<imbrandon> root@enterprise:~# lspci
<imbrandon> 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
<imbrandon> 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
<imbrandon> 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
<imbrandon> 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
<imbrandon> 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
<imbrandon> 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
<imbrandon> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
<imbrandon> 00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
<imbrandon> 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
<imbrandon> 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
<imbrandon> 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
<imbrandon> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
<imbrandon> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
<imbrandon> 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
<imbrandon> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
<imbrandon> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge 
<imbrandon> shut
<imbrandon> http://imbrandon.pastebin.com/tFCFMptx
<imbrandon> sorry wrong paste
<imbrandon> i'm assuming its the nic that goes to sleep because the system cannot be reached via ssh/smb/nfs/http when it happens
<imbrandon> but proceses still seem to run
<imbrandon> and nothing i can see in dmesg about it
<imbrandon> but the nic "wakes" when i pound on a keyboard thats attached, but its headless
<imbrandon> and resumes ssh sessions and http sessions etc as is it was never off
<apw> cooloney, so what missed the cut?  how big is it?  how well tested is it?
<cnd> apw, did the hid configuration get switched to a module?
<apw> cnd, i am considering it now, why?
<cnd> sorry, connection dropped
<cnd> apw, I was mostly just wondering if there was any more thought given to it
<apw> i was considering commiting it if it boots ok
<cnd> I would agree with that
<cnd> apw: also I have that patch to lower the log level of acpi resource conflicts
<cnd> I sent it to linux-acpi, it was refined according to what was stated there
<apw> thats just logging level change right?
<cnd> but I've not heard anything back since
<apw> so we can do that after the beta
<cnd> apw, at this point it's a log level change + message cleanup
<cnd> using %pR instead of [0x%lx-0x%lx]
<apw> still minor
<cnd> apw, I'm just not too familiar with their process, so I don't know when I'll hear anything back
<cnd> so I guess keep it in mind for whenever you feel we need to make a decision on it
<apw> if they are happy you may hear nothing
<cnd> yeah, but their git tree hasn't been updated either
<cnd> it's probably sitting in a queue of patches ready to be applied :)
<tgardner> cnd, thats just Len. He takes awhile sometimes.
<cnd> tgardner: ok, likely he'll have it applied before we have to make a decision without them?
<tgardner> not necessarily, but for something that minor we can make our own decision
<cnd> yeah
<cnd> just let me know if you need to make a decision basically
<cnd> since I'm new to the process I just don't know when that point is for lucid
<tgardner> cnd, have we seen the patch on the k-t list yet? I don't recall
<cnd> tgardner: no, but I can send it if you'd like
<tgardner> cnd, its likely the only way it'll get considered :)
<cnd> ok
<cnd> will do
<tgardner> cnd, P.S. since that patch will come post-freeze it'll also have to have an SRU justification.
<cnd> tgardner: ok, so I just need to put an SRU justification note in the bug, right?
<cnd> or also in the message sent to k-t?
<tgardner> cnd, SRU justifications only exist in the LP report. the SRU team doesn't follow the k-t list
<cnd> ok
<tgardner> though it doesn't hurt to add it in teh commit log message
<cnd> bdmurray: I see the wording of the "patch" checkbox when making an attachment is more clear that it's for solutions only
<cnd> thanks :)
<JFo> bdmurray, at what 'age' do those patch cases show up in the patch view you showed me?
<bdmurray> JFo: it should just show all of them, no age limit required
<JFo> bdmurray, it doesn't seem to be
<JFo> I only had 2 in the list the other day that were in an open state
<JFo> the rest were Fix Released
<JFo> it is only giving me 97 items
<JFo> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
<JFo> tells me that there are 113 items
<JFo> let me look a bit deeper
<bdmurray> hrm the 2nd link is just linux bugs and the kernel-bugs one should be more
<JFo> yeah, none of these are Fix Released
<JFo> bdmurray, I agree
<JFo> :)
<JFo> just wanted to give you some timely feedback after my initial investigation
<JFo> or rather I hope it is timely :)
<bdmurray> okay, thanks I'll look into it later today
<bjf> **
<bjf> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> **
<JFo> bdmurray, np
<bjf> ## 
<bjf> ## Ubuntu Kernel Team Meeting - in 45 minutes - #ubuntu-meeting
<bjf> ##
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<bjf> ## Meeting starting now - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<JFo> bryceh, have you issued a Call for Testing for the DRM stuff that was backported from the .33 kernel?
<bryceh> JFo, nope
<JFo> do you want me to do that?
<bryceh> JFo, however I did do targeted bug spamming around it to specific bug reports on -ati and -intel
<bryceh> JFo, yeah go for it
<JFo> bryceh, I can include whomever you want if there are any specific lists/etc.
<JFo> will do
<bryceh> JFo, write your email with care, lest you end up with way more bug reports than you bargained for ;-)
<JFo> oh btw bryceh, I am still chugging through that list you provided me of bugs to assign to the kernel task. Just wanted you to know I had not forgotten it
<apw> manjo, that reminds me, you skipped suspend/resume so quick that i didn't get to say anything
<bryceh> ah great
<apw> but ... we did get your patch in, and i am seeing some benefits already ... one bug where the battery is fingered as taking 10s to resume
<manjo> apw, only thing that remains is frequency based suspend resume 
<bryceh> JFo, I've been bumping a bunch more your way as I run across more drm bugs.  seems quite a few
<JFo> bryceh, I noticed a few more were tagged
<JFo> yep, I've seen them
<JFo> bryceh, I'll keep that page to check periodically
<JFo> so that you don't have to ping me on them
<manjo> apw, yes I also need to get the arsenal stuff in place so that I can start mass responding to those suspend resume stuff
<bryceh> I try to clearly mark ones that look like the new drm will fix them so hopefully those should be pretty straightforward to close
<bryceh> JFo, great
<JFo> bryceh, sounds good to me
<manjo> apw, currently over whelmed with this netbook stuff that seems to be put on high priority 
<apw> manjo, k
<manjo> apw, what did you have in mind wrt to suspend resume ? that you think I skipped over ? 
<apw> <apw> but ... we did get your patch in, and i am seeing some benefits already ... one bug where the battery is fingered as taking 10s to resume
<apw> i was going to say that your patch was in and proving useful
<manjo> ah! thanks 
<apw> jfo is the arsenal running at least the basic things automatically yet
<JFo> bryceh, I'll CC you on the Call for Testing so that it hits your radar
<apw> like the linux-meta retarget thing ...
<manjo> I would like some arsanel edu from JFo 
<JFo> apw, it is running in dry run. I am looking over its results daily for those that it should be catching
<JFo> I should have the basics running real mode by the end of tomorrow
<JFo> they are on my list
<apw> JFo, is it failing often enough that at least that one test can't go live?
<JFo> I just hadn't gotten to them yet
<bjf> apw, manjo, I can add that to the meeting minutes anyway
<apw> JFo, ok
<JFo> apw, no, it seems to be solid
<apw> bjf, thanks
<bryceh> JFo, oh cc ubuntu-x@ - we've got a lot of X oriented folks there who might participate
<JFo> just wanted to wait until I could focus on it and be sure that the changes I put in do not break them
<JFo> bryceh, will do
<manjo> apw, wonder if we could drop frequency based suspend resume from the blueprint 
<manjo> and move it to M+
<apw> manjo, if we arn't going to get to it we can postpone it
<apw> and it'll go yellow
<apw> (on the graph)
<manjo> apw, is that bad ? 
<manjo> or how bad is it on us ? 
<apw> its not sounding that important, and we'll be turning off apport before release ... so not the end of the world
<manjo> apw, coz I rather get real issues fixed instead 
<apw> yep, fine with me
<apw> push it POSTPONED 
<manjo> ok
<bryceh> JFo, btw I don't know if you saw my email to the platform team list but I've been auto-tagging bugs 'lucid' to differentiate out bugs that definitely affect lucid from those that might just be reports against old releases
<manjo> JFo, can we get some skype time together this week or so and talk about arsenal ? 
<bryceh> JFo, this has really helped me in narrowing down on the bugs I have to worry about
<JFo> yep, I saw it. Great stuff... just like what I am trying to do for kernel
<manjo> JFo, I need some schooling 
<JFo> manjo, sure
<bryceh> JFo, am thinking that approach could help you guys out too
<JFo> bryceh, every bit helps :)
<JFo> absolutely
<apw> bryceh, iwe have an arsenal script for that too :)
<apw> most of our bugs are already tagged as apport now does it
<JFo> bryceh, we started implementing, but I admit I got distracted
<bryceh> apw, awesome :-)
<manjo> JFo, just setup a time you are free ... sit on the porch with a cigar and team me ... 
<JFo> manjo, ok
<apw> JFo, we already have it
<JFo> apw, I know
<JFo> but I haven't been doing it manually like I needed to :)
 * apw looks confused for a second, then moves on
<manjo> JFo, send out a mail so that if anyone wants to listen in can... 
<JFo> will do manjo 
<manjo> JFo, thanks a ton 
<JFo> my pleasure
<apw> bryceh, what was that tag you added when you needed a kernel fix for a graphics bug?
<manjo> apw, JFo there was an idea to opensource the kernel-qa & reporting scripts that we have so that the locos can have their on testing workshop etc ... 
<bryceh> apw, it is 'xorg-needs-kernel-fix'
<manjo> apw, JFo something we can talk about at UDS or some place we meet 
<bryceh> apw, which I've sort of regretted picking because it takes way too much typing ;-)
<JFo> and 'resolution'
<bryceh> apw, but it's in finger-muscle memory now so not too bad
<JFo> manjo, yep
<JFo> bryceh, heh
<manjo> JFo, something you can add to your track at UDS
<bryceh> other tags we use for X are docced at https://wiki.ubuntu.com/X/Tagging
<JFo> manjo, sounds good
<bryceh> the tags 'freeze', 'edid', 'tv-out', 'font-size', 'resolution' and maybe 'black-screen' are ones likely to be drm bugs for drivers using KMS
<bryceh> so those possibly might be worthwhile tags to consider adding to the kernel bug tags list
<JFo> I've seen some ones tagged edid
<JFo> with kernel tasks
<JFo> bryceh, I guess the big issue is making sure I don't Invalidate the xorg task on ones that should retain it
<bryceh> JFo, be aggressive
<JFo> heh
<JFo> ok, will do
<bryceh> JFo, generally from what I've seen when a bug is identified as needing a drm fix, it'll just need a kernel patch to fix, and there's not work to be done on the x side
<bryceh> if it turns out there is, someone can always reopen the X task later when the work is clear
<JFo> bryceh, cool, I thought so, but that seemed like additional work
<JFo> :)
<JFo> <-trying to be a bit more efficient if possible
<bryceh> JFo, sure use your judgment and if in doubt leave the task.  I'm pretty aggressive at pruning them though
<JFo> sounds good bryceh 
<JFo> thanks
<apw> manjo, whats going on with bug #491210
<ubot3> Malone bug 491210 in linux "[i865G] Monitor Resolution limited to 800x600" [High,Confirmed] https://launchpad.net/bugs/491210
<apw> manjo, sorry missed, bug #507148
<ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] https://launchpad.net/bugs/507148
<manjo> just a sec
<JFo> bryceh, I just subscribed to the X ML, I wasn't aware that I wasn't already subscribed. :)
<JFo> sorry about that
<JFo> will resend in a bit
<bryceh> JFo, kewl.  it's pretty low traffic
<manjo> apw, talking to jdstrand .. give me a few mts 
<manjo> apw, skype you ?
<apw> sure
<manjo> your offline 
<apw> you're
<jono> tgardner, has linux-backports-modules-wireless-lucid-generic now built ready for me to test?
<tgardner> jono, yep
<tgardner> jono, you want linux-backports-modules-2.6.32 (2.6.32-16.7) lucid; urgency=low
<cnd> tgardner: is the lbm firmware any different than the linux-image firmware?
<tgardner> cnd, the files that exist there are no different, but the 6K firmware is new, and they may change during the Lucid life cycle
<cnd> tgardner: 6k firmware?
<cnd> 6050 by any chance?
 * cnd has a 6050 card, waiting for fw to drop from intel to be able to use it
<cnd> looks like just 6000 firmware...
<cnd> tgardner: I just looked at http://packages.ubuntu.com/lucid/linux-backports-modules-wireless-lucid-generic, but it doesn't list any files in the package
<cnd> is this the package you are pointing jono at?
<tgardner> cnd, thats a meta package
<cnd> oh
<cnd> ok
<cnd> let's see, where's the real package...
<cnd> yep, just the 6000 firmware, oh well
<cnd> hmmm... I'm beginning to wonder if cking's arrandale TSC issue isn't arrandale specific...
<tgardner> huh, I have a Radeon Xpress 200M that works pretty well in Lucid
<dyek> Hi! Any idea why using Ubuntu 9.10's vmlinuz-2.6.31-16-generic as DomU causes this Xen error? Error: (2, 'Invalid kernel', 'elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images') What is not generic loader about Ubuntu 9.10's -generic kernel?
<jjohansen> dyek: what are you trying to load?
<dyek> jjohansen: I'm currently using CentOS 5.4 as Dom0 (with a recent Xen hypervisor package -- Xen 3.4.2) and attempting to boot Ubuntu 9.10's kernel as DomU (I copied Ubuntu's kernel to Dom0's FS manually.)
<jjohansen> dyek: hrm, i386 or x86_64?
<dyek> jjohansen: CentOS Dom0 is x86_64, but Ubuntu is i386.
<jjohansen> dyek: do you have an initrd, initramfs
<dyek> jjohansen: I know I have initrd -- I copied the entire Ubuntu's /boot directory into Dom0's FS, naming it /boot_ubuntu.
<dyek> jjohansen: Not sure about initramfs.
<jjohansen> dyek: initramfs is just a replacement for initrd
<jjohansen> okay you should be good there then
<jjohansen> to be clear this is Dom0 complaining about the 9.10 kernel right?
<dyek> jjohansen: Yes. "xm create" results in the error.
#ubuntu-kernel 2010-03-10
<jjohansen> dyek: no immediate ideas, it should work, I made a note to check on it
<dyek> jjohansen: OK. Thank you!
<EruditeHermit> hello, is it possible to use the ubuntu kernel build system to build kernel packages and then not start from scratch if I modify a file on when building for the 2nd time?
<EruditeHermit> the make-kpkg clean purges all the old work
<BenC> EruditeHermit: if you are using make-kpkg, then you aren't using the ubuntu kernel build system
<EruditeHermit> BenC, I am using the instructions on this page. https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<EruditeHermit> BenC, could you please advise me as to the best way to build kernels then?
<EruditeHermit> a link to instructions would be enough
<EruditeHermit> hello, could anyone point me to the current method for building kernel packages on Ubuntu?
<jk-> EruditeHermit: check the build section at http://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<jk-> EruditeHermit: but, in general: fakeroot debian/rules binary-arch
<jk-> but it depends what you're trying to do: build using the ubuntu sources, or build an upstream (or other) kernel tree into a .deb ?
<EruditeHermit> jk-, I am trying to build an upstream kernel from git
<EruditeHermit> and make a deb package out of it
<jk-> ok, then make-kpkg is probably the best way then.
<jk-> (as you're doing..)
<EruditeHermit> however
<EruditeHermit> when I patch some of the files
<EruditeHermit> I don't want to rebuild the whole kernel
<EruditeHermit> just that one file
<jk-> then don't do the clean?
<EruditeHermit> hmm I think it complained
<EruditeHermit> but I will try again
<EruditeHermit> it was a while back
<EruditeHermit> so I was doing this
<EruditeHermit> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<EruditeHermit> so you are saying I can make changes to the source
<EruditeHermit> and then just do
<EruditeHermit> CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers
<EruditeHermit> and it will work?
<jk-> it should
<EruditeHermit> ok
<EruditeHermit> i will try
<EruditeHermit> will the fakeroot debian/rules binary method also work?
<EruditeHermit> I remember that was a quick way to build non kernel packages
<EruditeHermit> but i've never tried it for the kernel
<EruditeHermit> ah debbuild too
<jk-> use make-kpkg if you're not building from an ubuntu source tree
<jk-> upstream kernels don't have a debian/ directory
<EruditeHermit> yeah
<EruditeHermit> but once they are build once with make-kpkg does it not create the debian dir?
<EruditeHermit> jk-, once they are build once with make-kpkg does it not create the debian dir?
<jk-> yeah, it does the necessary stuff
<EruditeHermit> so after one make-kpkg build can you use the fakeroot debian/rules binary method?
<jk-> EruditeHermit: probably best to stick with one method
<EruditeHermit> ok
<EruditeHermit> you seem to be right
<EruditeHermit> it seems to continue building
<jk-> worst hotel internet ever
<jjohansen> jk-: that bad?
<jjohansen> worst hotel internet I ever had was just about unusable (really slow) and would die every 5 min, and then it was a crapshoot at reaquiring
<jjohansen> it was completely worthless, worse than having no internet because you wasted time trying
<jk-> just keeps losing the route; i seem to have a good connection to the AP
<jk-> true :)
<jk-> i guess it's "worst" because I paid for it this time :)
<jjohansen> ah yeah that sucks
<EruditeHermit> jk-, hey, I get the following error, can you help me rectify it? http://pastebin.com/YwAJMAws
<EruditeHermit> I think it has something to do with the fact that I tried to compile a different branch first
<EruditeHermit> which had the 2.6.29 kernel
<EruditeHermit> but I did do a make-kpkg clean before I tried to compile the new one
<EruditeHermit> jk-, hey are you about? it doesn't recognize that I patched files and therefore doesn't create new packages
<tgardner> cnd, not with preeemption. whats the wrinkle?
<cnd> tgardner: so there's a bug where a process is scheduling while atomic
<cnd> preempt_count is 0x10000100
<cnd> meaning 1 soft irq count + PREEMPT_ACTIVE
<cnd> so I'm thinking that a cond_resched was likely called during a softirq or tasklet
<tgardner> cnd, is this in a particular driver?
<cnd> the thing is that the stack trace from the "scheduling while atomic" bug doesn't seem accurate
<cnd> it lists the swapper task
<tgardner> a tasklet can reschedule, but not a softirq
<cnd> and the swapper task is in the middle of the acpi_idle_simple call
<cnd> a tasklet is run on top of a softirq...
<tgardner> whats the one run as a kernel threadcalled?
<cnd> workqueue?
<tgardner> ok, I always have to go look.
<cnd> yep, work queue, just checked
<tgardner> cnd, dunno, maybe ask smb. I'm a little rusty in that stuff.
<cnd> so, I saw this thread: http://lkml.indiana.edu/hypermail/linux/kernel/0904.1/01762.html (that's the last email in the thread, read previous replies as necessary)
<cnd> and they used function tracing to figure out what the stack was before the scheduling call
<cnd> but I would have thought that the stack listed in the "scheduling while atomic" bug would have been correct
<cnd> since we use 8K stacks
<tgardner> cnd, good luck with that. I gotta get some other stuff done before I get wound up in that.
<cnd> heh
<cnd> tgardner: if you have deep questions like that, where would you turn to get them answered?
<tgardner> apw, perhaps jj, smb
 * smb has now idea
<cnd> smb, you have no idea?
<cnd> or you now have an idea :)
<apw> cnd gcc doens't always record enough information to make stack back tracking poissible
<smb> cnd, Oh, yes. That is more it. 
<smb> That I have no idea
<cnd> everything makes sense if there's a separate task stack for soft irqs
<apw> though i think if you turn on function tracing in ftrace (a build option) i think all functions end up with frames else you can't function trace them either
<cnd> but that's now how we have our kernel set up
<jjohansen> cnd: _kmalloc way be the one doing cond_resched
<cnd> I'm currently building a kernel with CONFIG_DEBUG_SPINLOCK_SLEEP, which also adds sleep checking while atomic when cond_resched or might_sleep are called
<cnd> that gives us the stack trace of current as opposed to the stack trace of rq->curr given by the "scheduling while atomic" bug
<cnd> so maybe that will give us the stack trace of the offending softirq
<cnd> apw, I can't build a new kernel through fdr binary-generic:
<jjohansen> cnd: why?
<cnd> dpkg-deb - error: Debian revision (`debug') doesn't contain any digits
<apw> cnd how so?
<cnd> dpkg-deb: 1 errors in control file
<cnd> dh_builddeb: dpkg-deb -Zbzip2 -z9 --build debian/linux-image-2.6.32-16-generic .. returned exit code 2
<apw> <cnd> dpkg-deb - error: Debian revision (`debug') doesn't contain any digits
<apw> that seems pretty clear
<apw> did you add 'debug' to the end of your version?
<cnd> apw, isn't that something you recently changed though
<cnd> oh, I think I know why
<apw> nope nothing i would have done
<cnd> I did ~lpspinlock-debug
<apw> right so the - means two versions
<cnd> apw, I was thinking of your debug package renaming
<apw> nope
<apw> just take out the - don't think that is legal
<cnd> yeah, trying again
<cnd> jjohansen: why what?
<jjohansen> the debug stuff just covered with apw
<cnd> k
<apw> we assume the format of that in the packaging and a - busts everything, don't do that, it hurts
<cnd> oh, I think I get it now
<cnd> well... I need to think some more
 * cnd is still trying to figure out why rq->curr may be a different task than what's running on the processor
<cnd> apw, I noticed that there isn't an unreleased version at the top of the ubuntu-lucid git tree last night
<cnd> should there be one? (whenever I've pulled to a new version there was one)
<tgardner> cnd, he hasn't done a getabi yet
<apw> cnd quite normal while i am waiting for the builds to complete
<cnd> ahh
<cnd> ok
<apw> just do foo10 instead of ~foo10
<apw> until the start new release appears
<cnd> ok
<jjohansen> cnd: well is it a different task though?  the whole irq, softirq, tasklet stuff runs ontop of the current task,
<cnd> jjohansen: yeah, that's why I'm confused as to what's going on
<cnd> if the softirq is running on top of rq->curr, we should see a meaningful stack trace in the bug
<cnd> but we aren't
<jjohansen> cnd: the stack trace isn't even always right when not in irq
<cnd> jjohansen: because of the way it's compiled, or because of some kernel internal stuff?
<jjohansen> cnd: both of those, obviously compiling without stackframes makes stack traces a lot less accurate
<jjohansen> but compiler optimizations can delay when you would expect the sp to be updated etc
<jjohansen> the stacktrace should only be considered a best effort
<cnd> I'm guessing that's why the mailing list thread I saw used function tracing to get a more accurate trace
<jjohansen> cnd: yeah
<cnd> jjohansen: ok, I have an idea of how to go about getting definitive information out of the bug I'm working
<cnd> thanks
<_stink_> anyone know where I can find .debs of previous 2.6.32 versions for lucid?  it seems that -16 has broken virtualbox guest additions, and i'd like to go back to -15, but it's not in the repo anymore.
<_stink_> this install was just done today, so i don't have -15 installed locally and available via grub.
<tankenmate> anyone heard of any problems with the lucid livecd kernel / mdadm / kvm creating hangs / crashes?
<tankenmate> i was trying to install lucid from the livecd onto a md partition (all on a kvm guest machine), and after about 30-240 seconds the kernel just hard crashes..
<tankenmate> i looked on google / lkml and nothing obvious appeared..
<apw> kvm crashing, yes if it was 2.6.32-15 kernel
<tankenmate> any suggestions? deboostrap?
<apw> though that sounds like it was sooner than your issue
<apw> and it was resolved in later kernels, which one did you test with
<tankenmate> just a second... i'll get the version, it was from 2010-03-08 iso image
<tankenmate> Linux ubuntu 2.6.32-15-generic #22-Ubuntu SMP Tue Mar 2 02:23:29 UTC 2010 x86_64 GNU/Linux
<apw> as that was -15 i would retest with a later image containing the -16 kernel, there was some bad kvm patches in that version
<tankenmate> well the kvm host is running off jaunty, the guest is running lucid..
<tankenmate> hmmm i'll try with a karmic server install and debootstrap to lucid and see how it goes...
<tankenmate> weird thing is there was no oops, the kvm host didn't complain.. the virt machine just died, no logs, no errors nothing..
<tankenmate> almost like a triple fault or something...
<cnd> cking: ping
<cking> cnd, yo
<cnd> do you have any thoughts on the TSC issue for non-arrandale hw?
<cking> cnd, like it can be screwed up on them too?
<cnd> cking: bug 535077
<ubot3> Malone bug 535077 in linux "WARNING: at /build/buildd/linux-2.6.32/kernel/trace/ring_buffer.c:1984 rb_add_time_stamp+0x20c/0x220()" [Medium,Triaged] https://launchpad.net/bugs/535077
<cnd> a few dupes of that bug already
<cnd> booting with notsc fixed the issue
<cnd> and the ts in the bug begins with 0xfffffff
<cnd> so it looks very similar to what you found on the arrandale procs
<cking> yep - it's an issue apparently on some CPU's after coming out of S3 - and is listed in some Errata lists
<cnd> cking: so it's not just arrandale?
<cking> cnd, apparently 
<cnd> cking: what is the impact of notsc, would it be worth it to just disable tsc by default?
<cking> cnd, I posted a patch in the mailing list that can work around this bug - it stops an overflow 
<cnd> cking, even if it stops the overflow, the register still isn't correct right?
<cnd> won't it still cause issues?
<cking> cnd, yep, it's still get screwed. However,it may be worth seeing if a microcode update fixes it - this normally means getting a new BIOS which applies the microcode on boot
<cnd> cking: so what's the impact of notsc, and what if we just disabled it by default?
<cnd> is there some performance impact?
<tgardner> cnd,  I think it disables hi-res time of day measurements.
<cking> cnd, I really cannot see much of an impact - but this needs looking into - I was thinking we should disable TSC for L+1
<cking> tgardner, some I/O delay loop code uses it for sure
<tgardner> cking, disable on all 32 bit platforms ?
<cking> tgardner, not sure - I'd like to know which processors get the problem - it means surveying all the errata sheets :-(
<cking> it may depend on which machines have upto date microcode too
<cnd> cking: so your patch will disable the oops message, right?
<cnd> but it's just for the oops message you've been tracking?
<cking> cnd, the patch will fix the overflow, which causes the softlockup code to not produce stupid messages when the TSC warps to 0xffffffffxxxxxxxx
<cking> cnd, nope, I've also been trying to see if there is a fix to the generic TSC warp issue
<cking> (when coming out of S3)
<cnd> cking: ok, so for now what should we be doing when we see bugs that are caused by the TSC warp
<cnd> should I dupe them of some bug you are working on?
<cnd> or just note that it's harmless, but you can boot with notsc if you want to get rid of them?
<cking> cnd, yes, duping it would be useful - and note it's harmless and boot with notsc
<cnd> cking: what bug would you like me to dupe to?
 * cking looks
<cking> cnd, how about  bug 530487  - I addressed that yesterday
<ubot3> Malone bug 530487 in linux "BUG: soft lockup - CPU#2 stuck for 0s! [firefox-bin:1751] (during suspend/resume)" [Low,Fix released] https://launchpad.net/bugs/530487
<cnd> cking, ok thanks
<cking> let me modify the title of it to make it a little more generic too
<cking> done
<cking> cnd, since you deal with these more than me, can you get a list of CPUs which get hit by this TSC issue?
<tgardner> cking, I wonder if there is a way to test for this bogosity. Perhaps drive through an S3 state with an alarm wakeup during boot.
<tgardner> that'd just about wreck boot performance :)
<cnd> cking, I can try to make a list, where do you find errata for procs?
<cking> tgardner, and it may wreck the user experience if the machines have a buggy resume
<cking> I suppose we need to see what the ramifications of totally disabling it - is anything really that dependant on such precise timing?
<tgardner> cking, how about udec delays?
<tgardner> usec*
<cking> tgardner, well, there are the traditional busy loops method, or by looping and checking the TSC to my knowledge - the former is just as valid isn't it?
<cking> my concern is when you have a usec delay on a TSC that warps backwards over a S3 cycle - that could lead to some weirdnesses
<tgardner> cking, its been awhile, but wasn't one of the ways by reading an ISA port (which assumed a constant response time) ?
<cking> tgardner, not sure - things change and I get forgetful on these details
<cnd> cking, do you have a url for an errata for the tsc issue?
<cking> tgardner, the delayed io operations ultimately use __udelay, which can use TSC, or a delay loop. The TSC method does RT pre-emption, so notsc does have some effect on latency issues
<cking> cnd, only for Arrandale CPUs
<cnd> cking: that's fine for now
<cnd> I just would like to see what it says
<tgardner> cking, so the mythtv guys will have a cow since most of them run 32 bit.
<cnd> tgardner: I don't think they will (I'm one of them :)
<cking> tgardner, yep, so I think we disable tsc if it bugs users on the S3 case
<cking> ..but on a need-to-do-so basis rather than a blanket notsc default
<cnd> I've never noticed anything get terribly better when monkeying with higher prio stuff that would do preemption like that I think
<tgardner> cking, agreed
<cnd> cking: what if we just added a check for a huge out of bounds count in native_sched_clock: http://lxr.linux.no/linux+v2.6.33/arch/x86/kernel/tsc.c#L43
<cking> cnd, well, you know, somebody may want a udelay(1) to be pre-emptied because the iodelay is sucking away too many cycles!
<cnd> if so, set tsc_disabled = 1, and get the clock from the jiffies?
<cking> cnd, this scares me, I'm not sure if disabling it like this is a good idea on a fully running system with all CPUs in action
<cking> worth an experiment
<cnd> cking: if the tsc warping isn't causing issues, how is doing that going to cause issues?
<cking> cnd, I've seem it causes issues on Hardy on an Atom - a I/I delay on a hyperthread that got pushed to another CPU got confused when the TSC was skewed
<cnd> I/I delay?
<cnd> cking: if it got confused due to the tsc being off, how could it be worse if the jiffies result is off?
<cking> cnd, jiffies don't generally warp backwards
<cnd> cking: isn't that a good thing in this case?
<cnd> we don't want the clock to warp backwards
<cking> cnd, very true
 * cking needs to think harder
<cnd> the only issue I can see is when the switch occurs, if the jiffies calculation result would end up in a warp backwards relative to what the tsc result had been giving
<cnd> I don't know what the likelyhood of that occurring is
<cking> cnd, it happened - it caused me pain
<cnd> maybe we prevent it from switching to jiffies calculation if the tsc is unstable? (there's a var for that)
<cnd> cking: what do you mean by "it caused me pain", you didn't try this out yet did you?
<cking> cnd, I saw it happen on resume one in a few hundred cycles and figuring out what was happening w/o a console caused me pain 
<cnd> cking, that's just from basing clock on tsc, I'm wondering how likely it is that switching from tsc to jiffies calculation would result in a warping
<cking> cnd, good question - no idea. This needs some careful examination of the code
 * cking is exhausted of any more clock/TSC/delay knowledge. The devil is in the source code
<cking> ;-)
<cnd> heh
#ubuntu-kernel 2010-03-11
<pace_t_zulu> hey guys
<pace_t_zulu> is it true there is a kernel freeze tomorrow?
<crimsun> yes, but in effect it's already in place
<pace_t_zulu> crimsun, are you aware of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/535297 ?
<ubot3> Malone bug 535297 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000000000000028" [High,Confirmed] 
<pace_t_zulu> Malone?
<EruditeHermit> hello, can anyone help me with this error?
<EruditeHermit> http://pastebin.com/Hnriax64
<EruditeHermit> apparently its a bug with kernel package
<netritious> Hi, is it possible to obtain the linux-headers packages for kernel version 2.6.32-15 ? They appear to be unavailable in the repository, but they are needed to workaround an issue a few are having with 2.6.32-16 and VBox.
<apw> pace_t_zulu, Malone is the name of the launchpad software
<apw> pace_t_zulu, ubot3 can translate other bug numbers scemes like CVE numbers and so prefixes its results with where it found things
<pace_t_zulu> apw: thank you
<smb> cking, So what other things. beside suspend resume can cause a tsc warp`
<smb> ?
<cking> smb, not sure what triggers it, but I've seen it on Atoms - you sometimes see TSC warp warnings.
 * cking tries to think back 12+ months ago when he observed TSC issues on a N270.. hrm.. bit fuzzy
<smb> Are those the that messages with -<huge number> marking tsc unstable?
<cking> no - just small warping
<cking> big warp only observed when coming out of S3
<smb> Cause there is also the "Marking TSC unstable due to halts in idle", but probably thats the clocksource framework and not the things you looked at
<apw> smb, the "two ack rule" things count as having two acks if they are sent by a core-committer and acked by one other ... right?
<smb> apw, Usually not later. For now we could go with it
<apw> rtg i've pushed qcm-msm branch into linux-meta ... you'll have to upload it the first time i guess
<smb> apw, Thats why I usually pester two of you guys when I got a patch. :)
<tgardner> apw, k
 * apw pesters smb to look at tgardner's patch
<apw> tgardner, i'll get the other one done now
<cking> smb, if I recall, it's most probably an unstable TSC as reported by arch/x86/kernel/tsc.c
<tgardner> apw, the patch for -virtual ?
<smb> cking, Oh, so warp not only means warping around to 0 but also going faster forward or even back?
<smb> apw, tgardner was busy which one
<apw> tgardner, yeah am getting smb to review that
<cking> warp to zero --> wrapping,  warping where TSC seems to jump back/forwards in a manner that's not expected
<tgardner> cking, do you suppose that happens when ACPI is reefing on C states as well as S states?
<cking> tgardner, can't say for sure, but it may be possible for C states too to affect it
<tgardner> cking, that would make TSC well nigh unusable
 * cking agrees
<smb> It seems to be clear that tsc can halt in C states
<cking> smb, have we any evidence of that - perhaps we need to get a script that tests for this
<smb> cking, So that my problem. I havn't looked for some time but I thought that tsc is usually replaced by hpet for timer events
<cking> smb, maybe so, but TSC does seem to be used for udelay by default if I understand the code correctly
<smb> Right, probably we look/think of different usages
<cking> ..hopefully not missing any out
<smb> One thing is the clockevents framework for the monotonic and also the waking up/timer events (unfortunately its quite some time I looked at that code)
<cking> if the only good reason for using the TSC is lower-latency in udelay then maybe an alternative mechanism in udelay can be used and we ditch the TSC
<Q-FUNK> smb: it seems that AMD decided to get involved and contact the FIC engineering team themselves to solve bug #396286.  
<ubot3> Malone bug 396286 in linux "[Geode LX] [ION603] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
<Q-FUNK> one thing I'm wondering:  what tools do we have to probe the BIOS and print the manufacturer and build date, etc.?
<smb> Q-FUNK, sudo dmidecode
<smb> It would be nice to have someone look at that with some low lever hw information
<smb> Cause it looks like from a sw point of view I don't get farther
<Q-FUNK> smb: I suspected as much. Thanks for trying.
<smb> Q-FUNK, I hope at least the information we have can help there
<Q-FUNK> at least, the good news is that AMD considers what's left of the Geode market to be wrothy of salvaging enough to contact FIC themselves.
<Q-FUNK> hopefully, yes
<Q-FUNK> and it indeed seems that otavio was correct when he said that none of his other Geode hardware showed the symptoms.
<Q-FUNK> the program manager for AMD's embedded chips appologized on behalf of AMD, especially for the downfall of laying off Jordan Crouse, back then, and for having momentarily left Geode support in Linux and X.org in limbo.
<Q-FUNK> they now have one guy in US and a whole team in Taiwan working on both issues.
<smb> sweet
<Q-FUNK> they're barely coming up to speed on the basics of e.g. using git, but I have a feeling that it's only a question of time before things fall back into place.
<Q-FUNK> my only worry is whether any of those issues will be fixed on time for Lucid's release or not.
<Q-FUNK> I'd rather avoid the situation we had with the X driver on Hardy having to be resucitated after Hardy was released, but well...
<smb> It would have to be really fast to hit Lucid release. On the (maybe not  completely satisfying) side at least LTS gets a few point updates which rebuilds cd's
<apw> smb, in the first bit of good news of the day ... i plugged and external monitor into my lucid box and it didn't GPU hang on me ... so we do have the fixes :)  you are on there now
<smb> apw, \o/
<Q-FUNK> \o/
<apw> actually i've missed having IRC always visible
<apw> amitk, in mutt-patched how often do the stats on the left update ?
<Q-FUNK> apw: you position your IRC app in the second display?
<apw> Q-FUNK, i have today ... its 'only' 1280x1024 so too small for working on
<amitk> apw: you mean the unread count?
<apw> amitk, yeah the numbers over there
<amitk> apw: only when I move my 'cursor'
<amitk> or open another mail folder
<apw> as in C-n C-p in that left panel
<amitk> right
<apw> cool better than not seeing them
<amitk> you don't see them?
<Q-FUNK> apw: I wonder if I can do the same on this laptop running -intel.  when I'm at home, I'd love to slide specific apps on a separate display.
<apw> no i do, i mean them updating only when i take action is better than not seeing them at all as i was without -patched
<apw> Q-FUNK, works for me, this is a laptop.  added external, ran xrandr, and poop my desktop got wider
<Q-FUNK> apw: interesting.  do you get separate desktops or just one large virtual desktop area?
<apw> in the bad old days i used the 'tiny' laptop screen for irc et al and my 'huge' monitor for work ... but now my internal is bigger ...  
<apw> all one desktop you can have windows spanning the break
<Q-FUNK> hm.  ok. any way to have separate desktops, like in the old days?
<Q-FUNK> IIRC with xineramara we had separate desktops.
<apw> its not the default, i am sure its possible somehow, you'd have to ask on #u-x
<apw> as this is what i wanted, i am not moaning
<Q-FUNK> :)
<Q-FUNK> hm.  due to the timezone difference, my e-mail exchanges with AMD Taiwan are pracically real-time.  pity their firewall prevents them from using IRC.
 * apw reboots to test a kernle
<tgardner> apw, strange install problem on Karmic when installing a Lucid kernel: 'linux-image-2.6.32-16-server depends on binutils (>= 2.20.1)'
 * apw blinks
<tgardner> its not like we're still doing dynamic linking
<apw> tgardner, /me investigates
<apw> tgardner, is that a binary from the archive or one you made
<tgardner> apw, from my archive mirror
<smb> apw, Could that be because of linux-tools?
<tgardner> linux-image-2.6.32-16-server_2.6.32-16.25_amd64.deb
<tgardner> smb, linux-tools is a 'suggests'
<apw> smb, linux ... what he said
<apw> tgardner, i don't have that dep on a local build
<smb> apw, In one of my past attempts I was unable to install the kernel image without linux-tools
<apw> tgardner, can you less the package and paste your Depends: line
<apw> smb, yeah it changed
<tgardner> apw, Depends: binutils (>= 2.20.1), binutils (<< 2.20.2), libc6 (>= 2.8), libelf1 (>= 0.131), initramfs-tools (>= 0.36ubuntu6), coreutils | fileutils (>= 4.0), module-init-tools (>= 3.3-pre11-4ubuntu3), wireless-crda
<tgardner> its gotta be from ${misc:Depends}, ${shlibs:Depends}
<apw> wtf ? _two_ binutil depends
<apw> tgardner, which is the problem one ?
<tgardner> pretty tight constraints :)
 * apw wonders why i have none on my local builds ... arrrg
<tgardner> binutils (>= 2.20.1)
<tgardner> we kind of have to figure this out lest it raise hell with the kernel backports
<apw> well actually i suspect if you build it in a karmic chroot it'll be fine
<tgardner> apw, ok I'll do that
<tgardner> which is really the right solution anyway
<apw> yeah we would be building them there .. but why do we have such tight contraints from that
<tgardner> apw, I think its coming from the wildcard dependencies. I'll have to read up on them
<tgardner> apw, while we're at it, we should reexamine the 'Provides:' boilerplate. most of that stuff is no longer accurate.
<apw> tgardner, annoyingly for the linu-image package i put both those general defs together so we cannot tell by the position of the deps if some is from one or the other
<apw> but i suspect it is cause of the perf binary in there, it is tying us to the current binutils version
<apw> tgardner, i am starting to think it needs to come out into its own package
<tgardner> apw, right, but as you've pointed out the backports will get build in a Karmic environment anyways
<apw> into linux-tools flavour package
<apw> yeah. makes testing kernels on the wrong series a lot harder though
<tgardner> indeed
<apw> to it might make sense to pull it out to its own package
<apw> i will have a look how horrid that would be
<tgardner> yeah, its not like there is any real binutils dependency, is there? initrams doesn't use it, right?
<apw> nope ... its just cause of the binary i am sure ... perf
<apw> i'll pull it out and see if the deps get better
<apw> tgardner, what is a bit whack is my local builds have different deps:
<apw>  Depends: libc6 (>= 2.8), libelf1 (>= 0.131), initramfs-tools (>= 0.36ubuntu6), coreutils | fileutils (>= 4.0), module-init-tools (>= 3.3-pre11-4ubuntu3), wireless-crda
<apw> they would preclude install on karmic too, but they arn't the same which is most wack
<tgardner> why is the buildd different?
<tgardner> apw, could be we're just tilting at a windmill here
<apw> yeah i am not sure
<apw> i guess i need to review that chroot and rebuild it
<apw> i'll go split it out and we can see how it looks
<apw> it didn't seem sensible to have a separate package for one bin kernel version locked, but these deps will hurt our testing and so its prolly worth the pain
<tgardner> apw, yeah, but linux-tools doesn't have an ABI so how will you keep perf in sync?
<apw> linux-tools is the binary independant bits
<tgardner> oh, you mean a separate package just for perf?
<apw> we'd ahve to have a kernel matches binary package for the tool  linnux-tools-15-generic, move linux-tools to linux-tools-common
<apw> and have a linux-tools meta package
<apw> yeah thats the proposal.  i thought i'd try it and see how vile it was
<tgardner> what a pain in the ass
<apw> yeah... it probabally would have been the 'right' way to do it, we were lazy and it bites us on the ass
<manjo> apw, smb brb
<tgardner> apw, so, a Lucid kernel installs better when built under Karmic
<apw> good
<tgardner> now lets see if it withstands a stress pass
<cnd> apw: you remember anything that went in -16 that would cause bug 536858?
<ubot3> Malone bug 536858 in linux "USB-Audio devices do not show up as input devices" [Low,Invalid] https://launchpad.net/bugs/536858
<cnd> apw: nm, reporter invalidated the bug
<Ng> are we aware of any virtio problems in lucid atm? I've been trying to install the alpha 3 iso image inside a virtio kvm on my lucid laptop and it gets to the package installation bit and ends up IO erroring itself read-only
<daftykins> hi all, please excuse the newbie question... will Lucid be sticking with the 2.6.31 kernel through release and further?
<RAOF> No; it will be sticking with the 2.6.32 kernel though.  There are plans to pull newer kernels in post-release, but I don't know details of that.
<daftykins> ah yes my bad, typo/memory failure :) ah ok, thanks very much :)
#ubuntu-kernel 2010-03-12
<apw> Ng, we were missing some modules i believe in the older kernels whcih would have affected installation, try a daily around now, or beta-1 next week and see if its there
<apw> RAOF, morning
<apw> smb, i see stable is going mad:
<apw>   144 queue-2.6.32/series
<apw>   122 queue-2.6.33/series
<smb> apw, Yeah, I am anciously looking forward to look over it
<smb> apw, A lot of things all over the place on a first glance
<apw> smb, i see those kvm patches are in there
<apw> smb, or perhaps some of them, a few kvm patches anyhow
<smb> apw, Not all
<smb> Right
<smb> Not the breaky one
<smb> But this one has been fixed too
<apw> oh yeah you must tell me about that, what the issue was, when you arn't busy
<smb> apw, Oh, just grab a coffee 
<smb> :)
<apw> RAOF, so whats your feeling on our drm backport?  are we seeing generally better or the same reporting?
<RAOF> apw: It's superb for nouveau.
<RAOF> I don't think it's any worse than before :)
<apw> RAOF, that is good input, thanks
<Keybuk> huh
<Keybuk> I/O has crept to a crawl here
<Keybuk> dpkg is trying to unpack the linux kernel deb
<Keybuk> and it's taken over an hour so far
<tgardner> Keybuk, this is a bad thing
<chrisccoulson> Keybuk, i've noticed the same thing while doing some builds on my machine this morning
<chrisccoulson> unpacking any deb at the moment is taking forever....
<chrisccoulson> i thought it might just be me though
<tgardner> I've had the opposite experience. I think Lucid is much better at load leveling then Karmic.
<Keybuk> tgardner: this is a new bug
<Keybuk> first time I've ever seen it on lucid, and with 2.6.32-16
<Keybuk> sorry, this is the second time I've seen it
<Keybuk> but both have been with -16
<tgardner> Keybuk, I sure don't see anything since -15 that have affected the I/O path
<Keybuk> tgardner: it definitely isn't the scheduler
<tgardner> ah, unless 'sched: Fix SMT scheduler regression...'
<Keybuk> I/O scheduler anyway
<Keybuk> cause I tried changing that to noop
<tgardner> duo-core? try htop to see whats busy?
<apw> Keybuk, on -16 and not on -15 ?
<Keybuk> don't have htop
<Keybuk> apw: I didn't see it on -15
<tgardner> I've been doing -j8 builds while listening to tunes and surfing.
<Keybuk> but I didn't have -15 installed for long
<Keybuk> tgardner: it seems to be writing to disk that gets incrementally slower?
 * apw has been running -16 for some days longer than has been uploaded and not seen that
<tgardner> but an hour? thats ridiculous
<tgardner> is it actually doing anything?
<Keybuk> yes
<Keybuk> writing 4096 bytes at a time
<Keybuk> about one write a second
<apw> Keybuk, what does top say we are doing
<tgardner> can you write any other files whilst this is going on?
<Keybuk> apw: top just says dpkg
<Keybuk> in fact, top thinks dpkg is hardly using any CPU because it's entirely syscall
<Keybuk> tgardner: yes, other writes seem fine
<apw> percentage idle/wait etc ?
<Keybuk> apw: dpkg appears always in D state
<apw> well -15 -> -16 had drm33, apparmor update, and that SMT update
<apw> drm sounds unlikely, apparmor is only open stuff as far as i know
<chrisccoulson> Keybuk - i'm only noticing this issue with dpkg, and I'm also running karmic's kernel and still have the issue
<Keybuk> huh
<Keybuk> right, that just finished
<tgardner> apw, SMT update? could be a semantic change
<Keybuk> apt started a new dpkg run
<Keybuk> and that dpkg is running just fine
<apw> and the SMT update is supposed to be for core to core movment
 * apw wonders about what chrisccoulson just said
<tgardner> apw, which is why I asked if Keybuk has a duo-core
<apw> if its on karmic its unliekly a kernel issue me thinks
<chrisccoulson> and this dpkg change (37 hours ago) might be a clue:
<chrisccoulson> Call fsync(2) after writing files on disk, to get the atomicity
<chrisccoulson>       guarantees when doing rename(2). Based on a patch by Jean-Baptiste      Lallement <jeanbaptiste.lallement@gmail.com>
<Keybuk> tgardner: two dual-core Althon 64s
<apw> Keybuk, so he could be affected ...
<Keybuk> chrisccoulson: this is slowness in writes alone - within single files :-/
<apw> tgardner, would an awoken but not picked up runnable show as D though
<tgardner> uh, fiik
<apw> chrisccoulson, can you test the same operation
<apw> Keybuk, what op you doing exactly ... so i can try here
<tgardner> smb is knowledgeable 
<apw> Keybuk, and what version of kernel and dpkg do you have
<Keybuk> apw: dist-upgrade from wednesday to today
<gnarl> tgardner, huh? what makes you think?
<Keybuk> apw: don't know exact versions, because I'm mid upgrade :p
<apw> Keybuk, so -16.25 kernel
<tgardner> gnarl, 'cause you've dealt with I/O stuff in the past.
<apw> and dpkg?
<apw> Keybuk, what extract command line you using
<apw> so i am testing the exact same thing
<gnarl> tgardner, Heh, yeah in the past. And block layer. Not much help with filesystems
<gnarl> But it sounds strange that only dpkg is slow
<Keybuk> 2010-03-12 13:31:13 upgrade dpkg 1.15.5.6ubuntu1 1.15.5.6ubuntu2
<Keybuk> 2010-03-12 13:32:55 upgrade linux-image-2.6.32-16-generic 2.6.32-16.24 2.6.32-16.25
<Keybuk> so both dpkg and linux-image were upgraded in this run
<Keybuk> I must be running 16.24
<chrisccoulson> maybe we have different issues, but dpkg is painfully slow on my machine even with 2.6.31
<apw> can you not cat /proc/version_signature for us?
<Keybuk> Ubuntu 2.6.32-16.24-generic
<Keybuk> apw: I didn't know about that ;)
<apw> ok so its _not_ the SMT change as that is in .25
<Keybuk> maybe the SMT change fixes it? :p
<apw> Keybuk, uname -a also has the same info hidden in it
<apw> heheh
<apw> maybe
<tgardner> Keybuk, is it clipping right along now? you said it finished the one deb it was doing.
<apw> though what you are doing is mostly singly threaded so i'd doubt it
<Keybuk> yeah it's clipping along just fine now it's done that deb
<Keybuk> apw: ah, no, dpkg usually spreads across two cores when it unpacks
<tgardner> anything in dmesg indicating disk corruption?
<Keybuk> one core reads the deb, the other writes to disk
<Keybuk> tgardner: first thing I checked, nup
<apw> Keybuk, and t'is still slow as snot?
<Keybuk> apw: no, is fine now
<Keybuk> was just that deb
<apw> which deb?
<Keybuk> ironically, the kernel image one ;)
<apw> thats not even that big?
<Keybuk> oh, and kernel headers probably
<apw> headers is shit loads of files, an fsync after every single close would be bad performance wise
<apw> so it would depend what this change in dpkg actually does
<Keybuk> fsync() is supposed to be ok for ext4 no?
<Keybuk> huh
<apw> define ok.  if i read this description right it does it after every rename
<Keybuk> though saying that
<Keybuk> dpkg was upgraded first
<Keybuk> so that might have been done with new dpkg
<apw> which would likely be after every single file written, write tmp file, rename in
<Keybuk> yeah
<Keybuk> it would be
<apw> if it does that for small files, kiss your ass goodbye
<apw> Keybuk, there are 11692 files in a linux-headers file ... an fsync after ever one of those would be ... bad
<apw> sooo ... need to know where the fsync went
<Keybuk> yes
<Keybuk> I'm thinking you're right
<apw> normally if dpkg is updated in an update, that gets applied first before all others right?
<gnarl> On every extracted files it seems
<gnarl> And on directories as well
<smb> http://launchpadlibrarian.net/39182845/dpkg_1.15.5.6ubuntu2.debdiff
<gnarl> apw, ^
<apw> gnarl, thanks ... Keybuk got the git commit over on #u-d
<pgraner> tgardner: Hey jono tried that rfkill suggestion, no difference
<tgardner> saw that.
<pgraner> tgardner: I'd like to try and get to a root cause prior to you taking off next week
<pgraner> tgardner: anything I can do to facilitate that?
<tgardner> pgraner, I'm thinking that if an rfkill or 'modprobe -r' and 'modprobe' doesn't fix it, then its likely not a kernel issue.
<apw> tgardner, looks like they did add an fsync per file in pkg, and they did it for good reasons due to ext4 semantics being at the loose end of whats allowed ... so ... ouch
<apw> no the kernels fault directly
<tgardner> do we have one of these 5K parts somewhere in a laptop?
<tgardner> pgraner, ^^
<pgraner> tgardner: NM issue?
<pgraner> tgardner: not that I know of, we can ask the hw lab 
<tgardner> pgraner, possibly, but its kind of the whipping boy for all connection failures.
<pgraner> tgardner: any extra debug info we can get when it does crap out?
<tgardner> pgraner, lemme get him to do the modprobe dance thing.
<pgraner> tgardner: ack
<cr3> apw: I've been trying your suspend_test script in various combinations, one of which I find strange: 1. set acpi wake alarm; 2. run pm-hibernate; 3. pull the power plug out and immediately back in on a laptop without a battery.
<cr3> apw: oddly, the system doesn't resume after the wake alarm time, but works fine if I leave the power plug alone
<tgardner> cr3, I doubt there is battery backed RAM on a laptop, 'cause there is already a battery. does this test really make sense?
<cr3> tgardner: I'm not sure I understand, this is for a hibernation rather than a suspend. does hibernation rely on ram?
<tgardner> cr3, the ACPI alarm likely does
<cr3> tgardner: oh! I thought that was a cmos thing, makes sense then
<tgardner> cr3, CMOS on a standard AT motherboard has a battery. Thats why your BIOS loses its brains if that battery goes dead.
<cr3> tgardner: but that has a separate battery on laptops, right?
<tgardner> cr3, I think its likely the external battery in a laptop that serves that function, though I have to wonder why BIOS doesn't get scrambled when you pull the external battery. maybe I'm just all wet.
<cr3> tgardner: yeah, I was wondering the same thing (regarding pulling the battery, not regarding you being all wet... tmi)
<jjohansen> laptop usually have a small battery or capacitor for the CMOS
<jjohansen> I even have a laptop with a capacitor for the ram that gives me 2 min, to change the external battery during suspend
<tgardner> jjohansen, makes sense
<apw> cr3, you are relying on the EC to keep running without battery or mains, not sure that is reasonable
<tgardner> apw, I think that dpkg change is _really_ slowing things down.
<apw> its particularly painful for large packages like the kernel headers
<tgardner> one of my mojo fast serves has been updating for over an hour. Karmic->Lucid usually takes about 20 minutes
<apw> tgardner, pitti is asking questions in the MIR bug for ti-omap, which need answering before it can continue
<tgardner> apw, do you have the bug number handy
<tgardner> ?
<tgardner> nm, found it
<apw> not at the mo, google MIR ti-omap
<apw> thats how i find it each time
<tgardner> apw, responded. I should have looked first thing this morning. I get too dependent on my email filter to send me the right stuff at the right time.
<apw> tgardner, actually i think i got them to 'no brainer' position.  the general position of armel == 18month support only plus the fact i needs to be in main to get onto a CD ... means that its a slam dunk
<tgardner> apw, yeah, its not like they'll cause regressions or interactions with other packages
<cnd> tgardner: is that the normal process for a pre-stable patch?
<tgardner> cnd, close enough. its all a bit ad-hoc.
<cnd> k
<tgardner> cnd, it depends on whether smb demands an SRU as well
<cnd> ahh
<cr3> when I boot into the bios of a dell mini 10, the bios seems to indicate I'm not in supervisor mode. is there a way to get into the bios in supervisor mode?
<tgardner> cr3, whatya mean? Is it passworded?
<cr3> tgardner: if it's passworded, I can't even find where to enter the password. it allows me to boot into the bios, with f2, but it's just that some features are greyed out with some caption saying that they are only available in "supervisor mode"
<tgardner> cr3, maybe that equates to manufacturing mode? ask apw as he has one.
<apw> hrm not sure i've ever notices
 * apw reboots to find out
<cr3> apw: in the boot menu, I see this caption on the right: All items on this menu cannot be modified in use rmode. If any items require changes, please consult your system Supervisor.
<apw> cr3 do you have a security menu ?
<apw> if so what is on there 
<apw> i have 'Supervisor Password is: Clear'
<cr3> apw: supervisor password is: clear; user password is: set
<apw> User password is : clear
<apw> on mine
<apw> i think someone has added a password on it
<apw> not normal i'd say
<cr3> crap, but I can't even find how to get prompted for that password, at least I could try "ubuntu" or somesuch
<apw> there is a Set User Password just below
<apw> but i'd say its not meant to have one
<cr3> apw: greyed out, not accessible using the arrow keys
<apw> mine does not
<apw> i'd say if the supervisor password is clear it'd not need one, but ... hrm
 * cr3 considers either flashing the bios or opening up the darn thing to clear the cmos
<Keybuk> apw: OOOOOOH
<apw> Keybuk, WHEEE
<Keybuk> <insert Mary Whitehouse Experience Music>
<Keybuk> apw: that was a reaction to your mincore() patch btw
<apw> Keybuk, i thought it might be.  hopeing you are out from under plymouth enough to test it for me
<Keybuk> not yet
<Keybuk> but shortly
<clauden> hi kernelers
<JFo> hi clauden 
<clauden> hi JFo
<clauden> i seem to be digging myself into a hole trying to set up a diskless client with readonly filesystem...
#ubuntu-kernel 2010-03-13
<Tim42> I think I found a bug in 2.6.31-xx-powerpc, but I want to make sure its a bug (and not my own stupidity).
<holstein> hey guys.. if i have kernel 2.6.32-16-generic
<holstein> and i want to test something with the mainline kernel
<holstein> which one from...
<holstein> http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=D;O=A
<holstein> should i get?
<crimsun> holstein: meaning which one most closely is the basis?
<jjohansen> holstein: 2.6.32.9 would be the closest
<holstein> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html
<holstein> yup
<holstein> i should have said
<holstein> i got linked the map over in #ubuntu+1
<crimsun> my timing is spectacular :-)
<holstein> hehe
<jjohansen> but it would also be worth testing 2.6.33
<dyek> Hi! I'm using Debian Squeeze's kernel to boot Ubuntu 9.10's DomU (cause that is the only kernel that works with Xen for me so far). If I were to use Debian Squeeze's initrd, I get this error: "No filesystem could mount root, tried:", "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)". I suspect that that was caused by Ext-4 FS used on Ubuntu 9.10. I'm now trying to use Ubuntu 9.10's initrd, but copy Debian Squeeze's
<dyek>  initrd's lib/modules/2.6.32-trunk-686-bigmem directory into my Ubuntu-based custom initrd. I'm still getting the same error. Is there any tips if my approach can work and what other steps I need to carry out before it will work?
<jjohansen> dyek: which 9.10 kernel specifically?
<dyek> jjohansen: initrd.img-2.6.31-16-generic.
<dyek> jjohansen: Debian Squeeze's vmlinuz-2.6.32-trunk-686-bigmem kernel, though, works with Xen (3.4.2 -- rather recent version.)
<jjohansen> err modules in, lib/modules/2.6.32-trunk-686-bigmem won't work with a 2.6.31-16 kernel
<jjohansen> ext4 should be builtin to the 2.6.31-16 kernel
<dyek> jjohansen: OK. So, kernel module can never be moved to another minor version of kernel? Or with just a minor version difference, there is some chance that a kernel module will work with another kernel?
<jjohansen> generally no, its based off of the abi
<jjohansen> when building a kernel an abi "signature" is created and that has to match
<jjohansen> so even just changing config options can result in a kernel that needs different modules
<dyek> jjohansen: OK. So, the signature is the key! Thanks! ... I was told that "unknown-block(0,0)" means missing hdd-driver not FS.
<jjohansen> dyek: right that is probably the hdd driver
<jjohansen> but you mentioned 9.10 ext4 above
<jjohansen> have you tried a lucid kernel?
<jjohansen> its 2.6.32 based, and karmic will run ontop of the lucid kernel
<dyek> jjohansen: Yeah...I could only guess as I don't understand enough. Lucid kernel? Any pointer to it?
<dyek> https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-decision
<jjohansen> http://packages.ubuntu.com/lucid/admin/
<jjohansen> look for linux-image
<jjohansen> or you can grab the source from the git tree
<dyek> Thanks!
<dyek> http://lxr.linux.no/#linux+v2.6.33/Documentation/x86/boot.txt
<dyek> Protocol 2.10: (Kernel 2.6.31) Added a protocol for relaxed alignment beyond the kernel_alignment added, new init_size and pref_address fields. Added extended boot loader IDs.
<dyek> jjohansen:  Do you think if this change could be why I had problems booting 2.6.31 as Xen DomU? (And that maybe it is fixed in 2.6.32?)
<jjohansen> dyek: unlikely
<dyek> OK! Thanks!
#ubuntu-kernel 2010-03-14
<dyek> Hi! I tried Lucid (10.04) kernel and it still doesn't boot as DomU: Error: (2, 'Invalid kernel', 'elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images')
<dyek> Here is the difference between the kernel configs of Ubuntu's kernel (error booting DomU) and Debian's kernel (bootable as DomU) -- search for "CONFIG_XEN=y", maybe... Could someone include Xen DomU support in future please?
<dyek> Hmm...I think I might have found the reason why Ubuntu's kernel doesn't work as Xen DomU kernel -- it is likely caused by not setting CONFIG_M686 (I think CONFIG_M586 doesn't have the TSC support). https://lists.ubuntu.com/archives/kernel-team/2010-February/008727.html
<dns53> what is the best way to compile a kernel, i think i might need a kvm bugfix from .33 on my machine
<dns53> are there any good kernel ppa's?
<Hedge|Hog> dns53: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<dns53> thx
#ubuntu-kernel 2011-03-07
<fairuz> which process has pid = 0?
<RAOF> itih
<RAOF> fairuz: init.
<fairuz> RAOF: ty
<RAOF> (Which, in Ubuntu, will be upstart)
<fairuz> RAOF: does this process will run with the kernel?
<fairuz> RAOF: or just at the beginning
<RAOF> I'm not sure what you mean?
<fairuz> RAOF: when I do ps -A, I see that there is no pid 0, init is at pid 1
<RAOF> Ah.  Then maybe I meant âthere is no pid 0, but init is at pid 1â :{
<RAOF> Ah.  Then maybe I meant âthere is no pid 0, but init is at pid 1â :)
<fairuz> so pid 0 doesnt exist at all?
<RAOF> Now that I think of it, â0â is probably used as a flag value for pid.
<Krunch> init is 1
<fairuz> yes, I see that init is pid 1
<fairuz> i just wondering, since I saw a code that set the affinity of the processor
<fairuz> and it passes 0 for the pid argument
<fairuz> And I just wonder which process does have pid 0
<Krunch> for syscalls, passing 0 as a pid usually means "myself"
<fairuz> ah ok
<fairuz> that make sense
<Krunch> "If pid is zero, then the calling process is used." -- SCHED_SETAFFINITY(2)
<fairuz> Krunch: RAOF: ok all make sense now. Thanks
<fairuz> if we set sched_setaffinity to current process
<fairuz> that doesnt mean that if we start another process after that, it receive the same affinity?
<fairuz> it just affects the process that call the setaffinity, right?
<Krunch> read the friendly manual
<Krunch> A child created via fork(2) inherits its parentâs CPU affinity mask.
<fairuz> Krunch: yes i read it. Thanks. But my concern is if I launch a process A to start a hardware counter, then start the process B, and recall process A to stop the counter
<fairuz> so if I set the affinity in process A, it does not affect process B?
<fairuz> (process B is not a child of process A), consider its a random test case
<Krunch> i don't see why it would
<fairuz> ok
<Krunch> but just try
<fairuz> does mmap in user space do the same thing as ioremap in kernel space?
<apw> fairuz, nope
<omry> hi, got a new HP Envy and I am seeing some issues. brighness control keys are not working, touch pad is not wokring correctly and I also not sure turbo boost is working as it should (I see scaling up to 1.73ghz instead of up to 2.93ghz).
<fairuz> apw: ok. So is there a way to get a virt addr for a known phys addr in user space?
<omry> I am currently on the stock 10.10 kernel (2.6.35)
<omry> any recommendations?
<Krunch> fairuz: i doubt there is an API for that
<Krunch> fairuz: what you actually trying to do?
<fairuz> Krunch: just trying to write to a register in userspace
<fairuz> I want to avoid writing a device driver if possible
<Krunch> have you looked at ptrace?
<fairuz> Krunch: I dont think I get what you mean by using ptrace
<Krunch> the ptrace() system calls allows you to observe and modify processes, there is a flag specifically to change the registers
<Krunch> or you meant a hardware register or something?
<Krunch> s/hardware/pci or otherwise not general purpose/
<fairuz> yes i mean hardware registers, sorry.
<Krunch> i doubt you can go and mess the hardware from userland without writing a device driver
<Krunch> but there are some facilities like libpci
<fairuz> Krunch: ok.
<RAOF> You probably can go and mess with (at least PCI, probably more of) the hardware from userspace; X drivers used to be user-space, for example.
<Krunch> well, in principle you can do pretty much anything you want from userspace by poking around /dev/kmem :)
<fairuz> do you mean /dev/mem?
<Krunch> either
<Krunch> but don't do that
<fairuz> it's dangerous i assume?
<Krunch> it's tricky and it will break on every update
<RAOF> What sort of hardware are you trying to prod, anyway?
<Krunch> you can see an example of using libpci to change CPU MSR here http://timetobleed.com/enabling-bios-options-on-a-live-server-with-no-rebooting/
<Krunch> that's a much saner approach 
<Krunch> and i am confused, the MSR is not changed through libpci
<Krunch> depend what you are trying to do exactly
<fairuz> RAOF: it's PL310, a L2 cache controller for ARM
<RAOF> Funky.  No PCI for you!
<fairuz> RAOF: yes =)
<RAOF> X did (and still does, I believe) also have userspace I2C drivers, which might be closer to what you're after.
<fairuz> ok thanks
<fairuz> If it's too complicated, I'll just write a device driver for that
<fairuz> easier i guess
<tgardner> apw, ba04c7c93bbcb48ce880cf75b6e9dffcd79d4c7b
<pgraner> tgardner, http://www.linuxpromagazine.com/Online/News/Ubuntu-11.10-Named-Oneiric-Ocelot
 * smb wished they would get back to attributes he does not need a dictionary for
<JFo> I'll be referring to it as 'O'
<JFo> smb :)
<smb> Hm, ok something as dreamlike. Could be good or bad. :-P
<sconklin> http://who-t.blogspot.com/2011/03/how-to-dos-developer.html
<hallyn> Hi - bug 714335 was supposedly fixed in the -generic but not -server kernel.  Is that possible?  Or does rebuilding -server and -virtual kernels require a separate trigger?
<ubot2> Launchpad bug 714335 in linux "KVM SMP Linux Guests Hang on AMD" [Medium,Confirmed] https://launchpad.net/bugs/714335
<smb> hallyn, What makes you think that it should be fixed? IIRC that is one thing I had on my things to review still
<hallyn> smb: just that the bug submitter said it was fixed :)
<hallyn> smb: great, thanks I'll leave a comment to the effect that it's awaiting review
<smb> hallyn, One never knows what exactly was fixed where. Yes, and I try to get back to that next thing today
<smb> hallyn, I beleieve I started and was wondering about patch #1 which said something about moving a function but the patch looked like adding (probably because of the backport). And before I got to check against the upstream patch I must have been interrupted by something else
<hallyn> smb: yeah the original commit did the same thing and i didn't want to rock the boat.  (it 'moved' a function without removing the original one :)  
<hallyn> smb: thanks.  
<smb> hallyn, Ah ok. :)
<JFo> <-food
<LLStarks> hi, i was wondering if bug 621265 could get some attention. its had a fix ready for over a month yet still hasn't been backported to maverick.
<ubot2> Launchpad bug 621265 in linux "Slow Wireless Connection in Intel 3945abg" [High,Confirmed] https://launchpad.net/bugs/621265
 * jjohansen looks
<jjohansen> LLStarks: generally fixes like this wait on them moving into the upstream stable tree, of course the .35 tree is a bit different story
<LLStarks> even usability issues?
<LLStarks> how do i request an sru?
<jjohansen> LLStarks: you can send a mail to the kernel team mailing list
<smoser> smb, around ?
<kamal> apw: natty 2.6.38-6.33 is FTBFS (due to toolchain breakage?):  https://launchpad.net/ubuntu/+source/linux/2.6.38-6.33/+buildjob/2306132
<JFo> kamal, likely he is out with pgraner and the new folks since they are doing the 'new guy sprint'
<kamal> JFo: yup, well apw will surely enjoy knowing that natty kernel is borked when he returns from whatever den of iniquity they're um... "sprinting" at.  ;-)
<genux> lo. was wondering how to compile the new kernel on 11.04 ? what packages do you need, ? I have done apt-get build-dep linux
<genux> is there anyone here ?
<LLStarks> yryary
<genux> what packages are required to compile the present kernel ? just that I am getting errors with .size on assembly.. which could be a funny nasm ?
<jjohansen> genux: this is natty?
<genux> yep
<jjohansen> genux: friday we started noticing build failures, it seems to be a tool update issue
<kamal> genux: looks like this?:   arch/x86/kernel/entry_64.S:1544: Error: .size expression does not evaluate to a constant    <--- the toolchain problem
<genux> arh k. do you have any idea on what tool ? is it because of library's 32bit/64bit ? or is it nasm ?
<genux> yep
<jjohansen> atm you can get around this by building in a maverick chroot, but its an issue that will need to be resolved this week
<jjohansen> genux: I'm not sure yet, I didn't pursue it friday, and haven't looked at it today yet either
<genux> k.. I wiped off maverick :(. and installed alpha 3.
<jjohansen> but we do know that it builds fine in a tool chain from about a week ago, and on maverick
<jjohansen> genux: can you install a chroot env
<jjohansen> if you have space its easy, using a kernel team script
<genux> k cool :). shall do that instead :). thanks very much for the help.
<genux> ask a silly question but where would I get the kernel team script ?
<jjohansen> genux: just a sec I am looking that one up
<genux> yeah I have the space.. 120GB for the install
<genux> jjohansen: thanks :)
<genux> jjonansen: I would really like to learn more about the kernel process, is there any advice ? I have kernel device drivers book, but would like to re-write the acpi allocation for devices that *believe* the BIOS is saying where something is, but the BIOS has got it wrong. (a problem on my laptop tbh)
<kamal> genux, jjohansen: https://wiki.ubuntu.com/Kernel/Action/BuildChroot
<jjohansen> kamal: thanks, I have the worst time finding things since the wiki was reworked
<kamal> jjohansen: me too ;-)
<genux> jjohansen: thanks very much
<jjohansen> genux: as for kernel dev, Linux Device Drivers 3rd edition is a good starting point (its a bit dated, but its free).  The new edition of robert loves kernel book is fairly up to date as books go and is good
<jjohansen> kernel newbies is also a good start
<jjohansen> for Ubuntu specific stuff
<jjohansen> https://wiki.ubuntu.com/Kernel/Dev
<genux> yeah.. I have subscribed to the kernel newbies :).
<genux> thanks for the book (I have got the 3rd edition :) ) and shall get the other one :)
<genux> thanks for the ubuntu link.
<genux> thanks very much for the help
<jjohansen> unforntunately after a certain point its just diving into the code and trying to figure out what is going on (especially on linux, documentation is somewhat lacking)
<jjohansen> genux: also the most up to date kernel doc is in the linux kernel it self in the Documentation directory
<jjohansen> genux: np
<genux> tbh.. that is something that really interest me.. I have done c/c++/java/.net/php etc etc. and really want to get to learn the internals of the OS :) thanks very much
<genux> jjohansen: thanks, you have been really helpful :).
<jjohansen> genux: glad to be of some help
<genux> jjonansen: btw the wiki link, there is a scripts directory within the chroot-setup, chroot-setup/scripts/build-mkschroot, should that be a ln within the chrootsetup directory ?
<jjohansen> genux: ?.  I am not sure I follow, you can copy the script to your bin dir, or add it to your path element or execute it in place
<jjohansen> so I would normally do ./chroot-setup/build-mkschroot --arch=i386 maverick maverick-i386 http://archive.ubuntu.com/ubuntu
<jjohansen> oh and make sure I am in the directory where I want the chroot to be created
<jjohansen> and then to enter the chroot I use schroot
<jjohansen> schroot -c maverick-i386
<jjohansen> s/i386/amd64/  if you want to do a 64bit environment
<genux> jjohansen: thanks
<genux> :)
<jjohansen> the chroot is nice in that it carries processor personality so that you can have both i386 and am64 chroots on the same machine
<genux> very cool :)
<jjohansen> ie. build i386 and amd64 kernels and not have to think about it
<genux> thanks very much
<shadeslayer> quick question, can i make the squashfs of a maverick live cd from natty?
<shadeslayer> i mean will it be compatible>
<shadeslayer> we have squashfs-tools 4.1 in natty and 4.0 in maverick
<shadeslayer> ( i'm trying to get a fully updated maverick live CD with backports and updates enabled )
#ubuntu-kernel 2011-03-08
<Keybuk> linux-tools is uninstallable on current natty :'(
<lifeless> \o/
 * jjohansen reboot
<ncuster> hello, I am having the same issues building the kernel modules virtualbox via dkms that this user is: http://lists.debian.org/debian-user/2011/01/msg01508.html ... however I am using the stock pae ubuntu kernel instead of a custom built one. I installed the pae headers, but I am still having the same issue. Is there some other change I need to make so that I can build this module?
<Kano> hi, how different is -6 kernel to rc8?
<doko_> any idea when the fix for bug #605042 will be uploaded to lucid?
<ubot2> Launchpad bug 605042 in linux-fsl-imx51 "[armel] java fails to start with eglibc-2.12-0ubuntu4" [Critical,In progress] https://launchpad.net/bugs/605042
<fairuz> what is the equivalent library in kernel space for unistd.h?
<smb> doko_, I saw that patch just today submitted for sru. I don't think it was committed yet and then it would need another upload which I am also not sure when that could be.
<smb> sconklin, bjf Would you happen to know about fsl plans for Lucid?
<doko_> smb: we need the kernel on the buildd to fix it in eglibc ...
<tgardner> doko_, working on it...
<doko_> thanks
<fairuz> Hi, can I call smp_processor_id() in user space?
<mjg59> fairuz: No
<mjg59> fairuz: Also, unless you have affinity, it's not a meaningful thing to do
<mjg59> fairuz: You could be rescheduled to a different CPU between making the call and doing something with it
<fairuz> mjg59: I'm running a dual core cortex-A9
<fairuz> and I can set the affinity of a process
<mjg59> fairuz: Then sched_getaffinity will give you your affinity
<fairuz> mjg59: ah ok
<fairuz> mjg59: so a setaffinity will affect only one process right?
<mjg59> fairuz: Yes
<mjg59> See man sched_setaffinity
<fairuz> mjg59: ok ty
<mjg59> The first argument is the pid
<fairuz> mjg59: so basically we cant set an affinity for a program that not yet running?
<mjg59> fairuz: No, but you can launch it with taskset
<fairuz> mjg59: hmm whats that
<mjg59> fairuz: What are you actually trying to achieve?
<mjg59> fairuz: A command that launches a process on a specified set of CPUs
<fairuz> mjg59: actually i have a program..lets call it X
<fairuz> that i dont want to modify its source code
<fairuz> and I have another program that sets some hardware registers
<fairuz> so basically the flow is
<fairuz> 1) call my program, and set something
<fairuz> 2) call program X
<fairuz> 3) call my program again to reset something and colelct data
<fairuz> *collect
<fairuz> so if possible I want all of them to run on a processor of my choice
<Krunch> wrap all that in a shell script that you start with taskset
<fairuz> I already made a shell script to launch all that
<Krunch> unless you mean the two need to run on different CPUs, taskset is still the solution but you use it in the shell script
<fairuz> Krunch: ok, I think I have all the elements, So right now I just need to launch the script from taskset
<Krunch> and the affinity will be inherited by its children
<fairuz> what taskset will do exactly?
<mjg59> fairuz: taskset will set the affinity and then exec your process
<mjg59> fairuz: Which will then inherit that affinity
<mjg59> So taskset -c 1 myscript.sh will run myscript on cpu 1
<mjg59> And taskset -c 0 myscript.sh will run it on cpu 0
<fairuz> mjg59: Ah ok, so I set the affinity on a higher level
<fairuz> because right now I jsut set the affinity in my program, and not in program X
<Krunch> s/myscript/myscript and the processes it spawns/
<fairuz> and I know its wrong
<fairuz> Krunch: mjg59: ok thanks.. I think I get it now
<Krunch> well you can have the 1st program set affinity of program X as well if you know its pid but that's just more work while you can make it simpler by taking advantage of affinity inheritance
<fairuz> Krunch: but I dont think thats possible, because at the moment the 1st program runs, the program X is not yet launched thus it does not have any PID yet, right?
<Krunch> i am sure you can devise some ipc mechanism to give it the pid
<Krunch> but doing it that way is really useless work and complexity
<fairuz> Krunch: ok. I'll try taskset
<fairuz> So all programs launch by a script are considered the children of that script?
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<mjg59> fairuz: Yes
<fairuz> mjg59: I hope taskset is not arch dependant since I'm using ARM
<fairuz> some tools are not working on ARM
<fairuz> =(
<mjg59> I hope that too!
<fairuz> mjg59: Krunch: Thanks
<fairuz> So I imagine if I set taskset -c 3 myprog
<fairuz> then it up to the kernel to choose which processor it want myprog to run?
<Krunch> "-c3" means to run only on the 4th cpu
<fairuz> Krunch: I thougth it means cpu 0 and cpu 1 are chosen>
<mjg59> fairuz: No, -c is a list of CPUs, not a mask
<fairuz> mjg59: ok
<sforshee> pgraner, can you accept the natty nomination on bug 508516
<ubot2> Launchpad bug 508516 in linux "wakeup from sleep fails on toshiba nb305" [Undecided,In progress] https://launchpad.net/bugs/508516
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 30 minutes - #ubuntu-meeting
<bjf> ##
<Ntemis> hi
<Ntemis> please i need your help
<Ntemis> i just tried to update samba on my server and i f*** it up badly
<Ntemis> my server is ubuntu 10.10 and i tried to update to samba 3.5.8 from here
<Ntemis> ftp://ftp.sernet.de/pub/samba/3.5/debian/dists/lenny/main/binary-amd64/
<Ntemis> now i am left without samba
<Ntemis> and this:
<JFo> <-lunch
<JFo> bbiab
<apw> Ntemis, you tried to update from a lenny package?  i suspect that is not the best plan
<Ntemis> http://pastebin.com/NadhUFQg
<Ntemis> please help me unistall the conflicting packages
<Ntemis> i want my samba back :)
<Ntemis> could not find any deb for 3.5.8 version
<Ntemis> my kernel is 2.6.37.3 :)
<Ntemis> so i wanted to use the latest samba also, my fault
<Ntemis> fortunately i backed up my samba.conf
<apw> Ntemis, i would try and install the official version of samba
<apw> as the first step
<Ntemis> no go
<Ntemis> have a look in my pastebin
<Ntemis> packages have unmet  dependencies
<bjf> jjohansen, just a heads up, you've been dropped from the meeting agenda :-)
<jjohansen> bjf: okay
<jjohansen> bjf: shooting for 6 min next week :)
<bjf> jjohansen, heh, something like that
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-15 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<sconklin> JFo: you here?
<JFo> sconklin, yep
<JFo> am now
<kamal> jjohansen: fyi, the natty toolchain problem (".size expression ...") seems to be fixed in the archive now.  natty kernel build is no longer failing on Launchpad.
<jjohansen> kamal: oh, /me was just starting to look as I did an upgrade this morning and was seeing the failure locally
 * jjohansen goes to update again
<jjohansen> kamal: btw thanks for the heads up
<kamal> jjohansen: sure :-).  apw uploaded a new natty kernel, and it sees to be building fine on LP now.  I've successfully built amd64 on tangerine, and am testing i386 there now.
<kamal> s/sees/seems/
<kamal> jjohansen: natty kernel {i386, amd64} now building fine on tangerine again
<jjohansen> nice
<jjohansen> I've just sucked in the new tool chain locally and have fired off a test
<kamal> jjohansen: pretty massive breakage... I'm surprised it got into the archive at all in that state.  anyway ... back to the old grind.  ;-)
<jjohansen> yeah, well accidents happen, /me has had his fair share too
<bryceh_> apw, have you guys thought about backporting the support for ATI Cayman cards (http://www.phoronix.com/scan.php?page=news_item&px=OTE2NA)
<jjohansen> bryceh_: sigh, it will probably happen
<rishi> I am looking for the source for the linux-image-generic-lts-backport-maverick kernel. After reading https://help.ubuntu.com/community/Kernel/Compile and https://wiki.ubuntu.com/KernelTeam/KernelGitGuide I am unable to locate which Git tree to clone.
<rishi> I am trying diagnose a problem with the Mantis DVB driver and want to apply three patches from Linus' tree to test the issue.
<rishi> Any help regarding the location of the sources of linux-image-generic-lts-backport-maverick will be very helpful. Thanks.
<jjohansen> rishi: its in the lts-backport-maverick branch in the ubuntu-lucid repo
<rishi> jjohansen: Ok. Ok.
<rishi> I am just curious, what is the difference between http://kernel.ubuntu.com/~kernel-ppa/mainline/ and https://launchpad.net/~kernel-ppa/+archive/ppa ? Both seem to go by the name kernel-ppa, but have different content.
#ubuntu-kernel 2011-03-09
<RAOF> Hm.  I wish aufs wouldn't go all âApport would like to pop up and annoy you about this kernel oopsâ for each build I do in schroot.
<YokoZar> Hi, I've been campaigning for an increase to the hard ulimit (leaving soft ulimit in place) for some time now.  It's a simple change, but I'm worried it'll be lost by the wayside this release: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090
<ubot2> Launchpad bug 663090 in linux "Please raise file descriptor hard limit to 4096 (but keep soft limit at 1024)" [Wishlist,Confirmed]
<fairuz> Hi, morning
<fairuz> if I do taskset -c 0,1 myprog, Its up to the kernel to decide which cpu myprog will run?
<jk-> fairuz: if it's a single-process, yeah
<fairuz> jk-: ok.. taskset -c 0,1 myprog is the same as taskset 0x3 myprog right?
<jk-> fairuz: yep
<fairuz> jk-: thanks
<fairuz> jk-: I don't know it's the right channel to ask, but I'm trying to flush my L2 cache controller ( I have the register's addr and all )
<jk-> fairuz: flush a single cache line?
<fairuz> jk-: but when I try to write to the flush register of the controller, the kernel freezes
<fairuz> jk-: no, flush by Way
<fairuz> jk-: I mean I want to flush all caches
<fairuz> jk-: Does the kernel have any protection whatsoever thats prevents me from flushing the L2 cache?
<jk-> heh:
<jk-> BUGS
<jk->        The  current  implementation  ignores  the  addr  and nbytes arguments.
<jk->        Therefore, the whole cache is always flushed.
<jk-> (man 2 cacheflush)
<jk-> fairuz: I don't *think* so
<jk-> I'm not too familiar with x86 cache control
<fairuz> jk-: I think cacheflush is only flushing L1 caches
<fairuz> (I'm using ARM by the way), maybe  thats the problem
<jk-> ah
<jk-> so you're using mrc ... c7 ?
<fairuz> For flushing L1 cache, yes
<fairuz> I use CP15 instructions to flush the cache
<fairuz> but since my L2 cache is external, I think I cant use MRC...... to cache L2
<fairuz> *to flush L2
<fairuz> flushing L1 cache works well in my case
<fairuz> just L2 that brings problems
<fairuz> the registers are memory mapped and I dont know how it dont want to work
<jk-> man, the operands to mrc always get me confused
<jk-> fairuz: which platform?
<fairuz> jk-: OMAP4
<fairuz> cortex-A9 MP
<fairuz> jk-: you work on ARM too?
<jk-> fairuz: yeah, a bit
<jk-> what are you looking to do?
<fairuz> jk-: Actually I have a program that needs to flush both caches to make it works properly
<fairuz> in my platform the L2 cache is external
<fairuz> but all the registers are memory mapped
<fairuz> and I thought it should be easy :D
<jk-> fairuz: take a look at v7_flush_kern_cache_all, in arch/arm/mm/cache-v7.S
<fairuz> I can read some of the registers
<fairuz> but when it comes to the cache operation register, it freezes the kernel
<jk-> I'm not sure how your L2 behaves though.
<fairuz> jk-: Yes, I already took a look at it, I think it just flushes L1 caches
<fairuz> jk-:  It's a PL310 L2 cache controller
<jk-> might it snoop the L1 invalidates?
<fairuz> jk-: You mean? Actually I follow a sequence that are recommended in PL310 TRM
<fairuz> which is Clean L1, DSB, Clean & Invalidate L2, Cache Sync, Clean & invalidate L1, DSB
<jk-> I'm just guessing :)
<fairuz> jk-: It makes me frustrated..It should be easy =(
<fairuz> and I dont even know how to debug
<fairuz> does the kernel log even if it freezes?
<fairuz> i mean just before it freezes
<jk-> fairuz: I think it's going to wedge on the register write, so no logging.
<fairuz> jk-: =( bad news to me... I already tried to disable the interrupts before writing to the register but still no luck
<fairuz> jk-: I wonder what makes the kernel freezes
<fairuz> jk-: I'm thinking that the cache controller trying to clean the cache but the kernel is trying to write on it? So it's a never ending work
<fairuz> jk-: which explains the freeze?
<fairuz> jk-: is that possible?
<jk-> no idea sorry, I don't have any details about that cache
<jk-> you might be able to get some help on #armlinux though
<jk-> or #linaro, or #linaro-kernel
 * jk- heading out
<sconklin> 7873ca4e4401f0ecd8868bf1543113467e6bae61
<Kano> hi, is there a linux-meta 38-6 update somewhere
<fairuz> what static mapping means? can i still ioremap an address that is already mapped?
<sconklin> akgraner: you here?
<lool> Oy
<lool> linux-image-virtual seems to be missing some .kos (nls_cp*.ko notably) in maverick/i386, but they seem enabled in the config?
<lool> smoser: ^
<lool> Ok; at least the modules are missing consistently since lucid on both amd64 and i386
<lool> but they were present pre lucid, with 2.6.32 kernels
<apw> lool, can't be very important if they have been missing for 18 months without anyone noticing :)
<lool> Ok, debian.master/control.d/virtual.inclusion-list is the reason
<lool> apw: Yes, that's what's reassuring me
<lool> It seems like a bogus entry in debian.master/control.d/virtual.inclusion-list
<apw> likely excluded indeed
<lool> I would suggest that an exclusion-list should be maintained in parallel and that any mismatch shall fail the build  :-)
<apw> heh, sounds lovely
<apw> lool, actually the module lists in the abi stuff would catch a regression
<lool> apw: How would you catch a new module which you fail to install?
<lool> e.g. upstream adds cpxyz
<apw> well we'd only want to add those if they are useful
<apw> and generally we are including by class
<lool> apw: I guess that's fair enough, my personal preference is for the tool to be hard on me and force me to document it both ways  :-)
<lool> apw: What I find odd is that these things get built but not installed
<lool> apw: Why not disable the configs instead?
<lool> This would make the delta apparent in the config handling mechanism
<lool> fuse is missing too
<apw> that bloats the config delta, too.  this was a compromise
<lool> I wonder whether the config factorizer could keep most common configs at the top of the tree, and have overrides for the most uncommon ones instead of splitting configs as soon as one differs
<lool> oh well
<apw> i did try that, and it can be done, but it does make it much more confusing
<lool> Ok
<lool> I filed LP #732046 to let smoser and others chime in
<ubot2> Launchpad bug 732046 in linux "Missing filesystem modules in -virtual package" [Undecided,New] https://launchpad.net/bugs/732046
<lool> I propose fixing this in SRUs as well, but feel free to dsiagree
<lool> smb: Hey, to workaround LP #732046, I'd like to switch to another kernel; would you know whether I can run -server or -generic under EC2 vms?  do you have hints on how to do that?
<ubot2> Launchpad bug 732046 in linux "Missing filesystem modules in -virtual package" [Undecided,New] https://launchpad.net/bugs/732046
<lool> Daviey: Ah I think I'm a bit naive to do it from the vm, you are supposed to pass a kernel when starting the instance, so I'm supposed to provide an alternate aki
<smb> lool, That was Maverick?
<lool> I guess I should pass a pvgrub one
<lool> smb: yes
 * lool starts a kernel build to get the modules in the background
<smb> lool, So pvgrub is there already. I'd try to install a server kernel. 
<lool> smb: I did, then I did a grub-reboot on it and it didn't come up
<lool> but maybe I messed it up, I might not have waited long enough
<smb> lool, was that an m1.large?
<lool> No, c1.medium
<lool> i386
<smb> I think that got more than one cpu too. There is a bog that make reboot from within the instance not working
<smb> I think it is still waiting to get into proposed
<smb> You would need to reboot either from the web interface or the ec2 tools
<smb> And even that seemed to take a long time
<Daviey> EC2 makes me cry.
<lool> smb: right reboot didn't work indeed, but I used ec2-stop-instance -f
 * lool tries again, waiting longer for the machine to come up
<lool> Server.InternalError: Request could not be executed due to an internal service error
<lool> oh wow
<smb> lool, I was using ec2-reboot-intance
<smb> instance even
<smb> or instances
<smb> Command completion makes one forget details
<smb> lool, When looking for that bug it felt like taking 5minutes or so
<bdmurray> JFo: bug 707353 seems rather important
<ubot2> Launchpad bug 707353 in linux "[STAGING] Broadcom 4313 firmware fails to load because it is not present" [High,Confirmed] https://launchpad.net/bugs/707353
 * smb wonders whether that is that firmware that needs to be obtained with fw-cutter...
<smb> tgardner, ^ Do you happen to know that from memory?
<JFo> tagged it kerne;-key so it shows on our list
<JFo> thanks bdmurray 
<bdmurray> JFo: thank you
<JFo> <-lunch
<lool> smb: Couldn't get this pv thing to work; I installed linux-image-server which installed the -generic-pae flavor, and it's the first entry in grub.cfg, I grub-reboot 0 and sudo halt, then stop-instance, start-instance, and it still comes up as -virtual
<smb> lool, pv-grub is based on grub1, its /boot/grub/menu.lst that matters
<lool> apw: Sorry, was wrong earlier, lucid is unaffected
<lool> smb: aha, grub isn't installed anymore and grub2 is instead, that's why
<smb> lool, There should be some ec2-grub-bla-legacy too. I know its not the least confusign solution to have both files hanging around
<lool> grub-legacy-ec2
<smb> That should be the one
<smb> It generates menu.lst in parralel to grub.cfg
<lool> /usr/sbin/update-grub-legacy-ec2 doesn't pick up the generic-pae flabor
<lool> flavor
<smb> But on EC2 grub.cfg is just there to confuse people
<lool> Ignoring non-Xen Kernel on Xen domU host: vmlinuz-2.6.35-27-generic-pae
<lool> it seems to be looking for xen in the kernel name
<smb> Hm, I guess virtual
<lool> I just added the entry manually
<smb> I thought that there was some normal kernel installed too. But maybe again just to confuse
<smb> jjohansen, Do you remember whether there was any other kernel flavour that may be bootable in ec2? Until the missing modules is solved...
<jjohansen> smb: only -ec2 and -virtual
<lool> 2.6.35-27-generic-pae
<lool> wee
<lool> jjohansen: I just used -server which is /boot/vmlinuz-2.6.35-27-generic-pae
<jjohansen> smb: -generic and -server are close
<lool> it booted fine, just had to force the grub entry as the script wouldn't want to install it
<smb> jjohansen, sounds like it is possible 
<smb> ;)
<jjohansen> smb: yeah possible
<jjohansen> on maverick
<lool> yup
<lool> modinfo nls_cp437 is there, cool
 * jjohansen was thinking there was a config missing but, that isn't right either
<smb> practical proof. qed. pub.
<lool> smb: the next thing I would have done is rebuild linux-virtual myself with the same sources
<jjohansen> yeah I did end up booting some -server and -generic kernels during early dev
<lool> I would hope the modules would be accepted in this case
<lool> I do miss console output with the -generic-pae kernel
<smb> Well that could be the missing config
<smb> That xen console is not enabled
 * smb -> away
<smoser> lool, did you get what you were looking for ?
<smoser> i can hopefully help
<smoser> regarding reboot on ec2, that works fine.
<smoser> i reboot in tests that we run for every release, and loads of times when i'm testing cloud-init.
<smoser> it is as reliable as rebooting hardware
<smoser> well, i'll be around a bit today, and i'm back in tomorrow, if someone has questions. 
<kristian-aalborg> hi all... I have some kind of project going on: http://ubuntuforums.org/showthread.php?p=10541660#post10541660 - building a custom kernel, then moving it to another box
<lool> smoser: I found a workarund
<lool> smoser: I've sub-ed you to the kernel bugs
<lool> *bug
<lool> smoser: thanks!
<smoser> the -virtual kernels should be almost identical to -server... in natty we had some issues, so there are some differences.
<smoser> but other than that, they're largely just subsets.
<smoser> but it is now a full flavour rather than sub-flavor
<soren> smoser: orly? Since natty?
<smoser> maverick i think it is its own.
<jjohansen> yep, maverick is where it became its own flavor
 * soren is failing to keep up, apparantly. :(
<tumbleweed> how do I easily build an ubuntu kernel from the kernel git repo? I just want to test a single patch, so build-mkppa looks like it'll give me a source package I can build, but it seems to expect a debian/changelog to exist
<tumbleweed> s/kernel git repo/kernel-team git repo/
<jjohansen> tumbleweed: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<tumbleweed> jjohansen: oh, duh, I missed the clean
#ubuntu-kernel 2011-03-10
<skaet> apw, JFo - https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-03-11 available a bit earlier - still working through the A3 testing reports, so a few more updates may happen tomorrow.
<smb> bjf, I just changed my mind on that CVE. I think that anon_vma_chain does not exist in Hardy and Karmic
<bjf> smb, i've not applied it, go ahead and do what you feel is right
<smb> bjf, Yeah, just wanted to avoid you to grab it as you were the second acker
<smb> bjf, I would feel the right thing is to have the submitter actually test compile it. :)
<smb> bjf, He's probably sitting somewhere close to you
<sconklin> smb: good guess, I'll figure this out
<bjf> smb, yes, he will be beaten
<smb> bjf, Beating is not needed. You have to use the flakey coffee machine. Which I heard can be enough punishment 
<sconklin> smb: good idea. I'll use the coffee machine and then look at it
<smb> sconklin, Cool. I guess that one line just slipped in. It was not part of the original patch but part of the context.
<sconklin> smb, bjf - Revised (and test built) patches for Hardy and Karmic CVE have been mailed
<smb> sconklin, ack. should be ok now
<phillips321> hi all
<phillips321> has anyone got a guide to getting 2.6.38 on 10.10?
<diwic> sconklin, when is next deadline for upload to maverick SRU?
<sconklin> diwic: there is no real deadline, patches put on the -next branch will go into the next upload. I expect that the next Maverick upload will be late next week
<diwic> sconklin, cool, thanks.
<rishi> Hey guys, I think the natty-lts-backport that is there in the kernel-ppa breaks my Ethernet. I have nVidia MCP61 Ethernet chip.
<rishi> Is this known?
<rishi> I can help with debugging, bug report, etc..
<rigved> rishi: patience. maybe someone might be able to help.
<rishi> rigved: Yeah, no problem. :-)
<ogra> tgardner, poke
<tgardner> ogra, hmm?
<ogra> tgardner, can we have .38 as default for omap4 ?
<tgardner> ogra, yep, was just waiting for Tobin to pull the trigger.
<amitk> ogra: it works?
 * amitk is pleasantly surprised...
<ogra> tgardner, i think he answered the mail thread on monday or so ;)
<ogra> amitk, the BSp kernel from agreen
<amitk> ogra: right..
<tgardner> ogra, OK, I'll get it started building.
<ogra> tgardner, thanks :)
<amitk> tgardner: y'all going to ELC, I noticed
<tgardner> amitk, yep
<amitk> will see you there in a few weeks then
<tgardner> amitk, indeed. I'm back from London this Sat, then off to SFO 3 weeks later.
<amitk> tgardner: aah, kernel sprint?
<tgardner> amitk, yeah, new guy sprint.
 * amitk needs to plan a trip to london soon
<amitk> s/london/cambridge
<JFo> <-food
<tseliot> mjg59: is there an equivalent for acpi_video_register() (acpi/video.h) in linux 2.6.32? I'm trying to get a backlight with poulsbo
<tseliot> *backlight device
<lborda> Hi guys
<lborda> anybody comfortable with bonding with arp monitoring AND bridge? 
<rydberg> greetings, i wonder if someone can explain this, running latest stock kernel: "cat /sys/module/*/srcversion | sort | uniq -c"
<rhuddusa> forgive if this isn't the correct place to ask this. i upgraded from linux-image-2.6.32-29-virtual linux-image-2.6.35-25-virtual and now any ipsec ah & esp packet with wire size > 304 does not decrypt accross the wire.  i see encrypted packets transmitted and then received, but then they are lost.  if i switch back to 2.6.32, packets decrypt fine.  any ideas who to track down my missing packets? ifconfig doesn'
<rhuddusa> t show any errors. 
<rydberg> it seems to have occurred between 2.6.38-4 and 2.6.38-5
<rydberg> ... and it is still present in 2.6.38-6, and still present in mainline.
<rydberg> dkms packages will fail to install roughly 50% of the time because of this, for instance
<rydberg> timg, have you seen anything about this?
<JFo> rydberg, they are in London this week, so likely off getting dinner somewhere.
<rydberg> oh, i see
<rydberg> hey, jfo :-)
<JFo> hey rydberg :)
<rydberg> ill dig further on lkml to see if i find anything
<JFo> ok, I'd be interested in what you find, from a purely informational aspect.
<rydberg> sure thing
<rydberg> to confirm the problem, all one needs to do is run that line above, and see that some line has a number different from 1 in the first column *nudge nudge*
<BenC> rydberg: Is that really a problem, or just not what you expected?
<rydberg> expect that dkms packages compare srcversions and end up not installing the new version because it looks like the old one?
<rydberg> honestly, i dont know what the assumptions around srcversion are, but it sure seems likely that they all should be unique, and so they were, up to recently (checked in maverick too)
<BenC> rydberg: What I'm asking is if the srcversion being the same for two things is really a bug or not
<BenC> What two modules share the same srcversion?
<rydberg> i understand, i can't say for sure, other than there being little reason for it otherwise
<BenC> What modules have the same srcversion would be a good data point
<rydberg> any modules - please try it out, the line is cat /sys/module/*/srcversion | sort | uniq -c
<BenC> None of the ones on my system have the same
<BenC> so I'm asking you since you can reproduce this "issue"
<rydberg> what kernel version are you running?
<BenC> 2.6.32-8-generic
<rydberg> cnd confirms this problem also
<cnd> rydberg, ugh, dragging me into another problem :)
<rydberg> yes, this is between 2.6.38-4 and 2.6.38-5 ubuntu versions, somewhere in the 2.6.38-rc series
<rydberg> hehe
<BenC> Right, so check yours and tell me which modules share the same srcversion
<rydberg> it seems random, and completely unrelated stuff, like i2c_piix4 and joydev, k10temp
<rydberg> im going to bisect this on mainline git now, its not an ubuntu issue it seems
<BenC> Is it random on the same boot, or different between boots?
<rydberg> same number occuring between boots
<rydberg> you can look it up on the internet and get hits :-)
<rydberg> 533BB7E5866E52F63B9ACCB
<rydberg> there is one of them
#ubuntu-kernel 2011-03-11
<rydberg> failing commit is b7bd182
<rydberg> cfo, you said you wanted to know :-)
<rydberg> only it doesnt make sense so far...
<fairuz> Hi, I just need to write a line of code in privileged mode. Is there any way doing this than writing a device driver?
<jj-afk> fairuz: well a module, or modifying the kernel directly
<fairuz> jj-afk: module == device driver, thats what i'm trying to avoid
<fairuz> since i just want to write 1 line of code 
<jjohansen> fairuz: does it need to be permanent
<fairuz> nope
<fairuz> just for one time run
<fairuz> jjohansen: any idea on this? some system call or something
<jjohansen> ksplice
<fairuz> never heard of those
<apw> smb where did we get to with bug #539467
<ubot2> Launchpad bug 539467 in linux "SATA link power management causes disk errors and corruption" [Medium,Confirmed] https://launchpad.net/bugs/539467
<smb> apw, To the point that upstream said likely controller and whether we can build kernels for test ind whether medium savings is ok. 
<smb> medium is ok but I did not get to send a reply for that
<fairuz> hi, can i ioremap a same physical addr several times? or it it's not possible :)
<jjohansen> fairuz: maybe it would be platform dependent, the value returned isn't guarenteed to even be virtually mapped
<cking> off_t fwts_ebda_get(void)
<cking> {
<cking>         uint16_t *ebda;
<cking>         off_t    ebda_addr;
<cking>         if ((ebda = fwts_mmap((off_t)EBDA_OFFSET, sizeof(uint16_t))) == FWTS_MAP_FAILED) {
<cking>                 return FWTS_NO_EBDA;
<cking>         }
<cking>         ebda_addr = ((off_t)*ebda) << 4;
<cking>         (void)fwts_munmap(ebda, sizeof(uint16_t));
<cking>         return ebda_addr;
<cking> }
<cking> fwts spam
<sforshee> cking, didn't you discover an msr that gives the firmware version?
<cking> sforshee, I didn't get around to checking it out on various platforms I have here.
<cking> it's on my list of things to poke at
<sforshee> do you happen to have the msr number handy?
<cking> not off the top of my head
<sforshee> i guess you found it in the bios bits code?
<cking> nope, in section 28.4 vol 3b of the IA-32 arch docs
<sforshee> okay, i'll take a look, thanks
 * cking hopes he recalled the section correctly, it was 2 days ago
<cking> sforshee, how come - you want to check the f/w version?
<cking> I mean microcode version
<cking> http://mvogt.wordpress.com/2011/03/10/apt-btrfs-snapshot/ - nice
<sforshee> cking, wondering if a machine with a C-state hang could be due to old microcode
<sforshee> buggy old microcode, that is
<cking> who knows, worth a try
<smb> tgardner, Have you seen my comment about that screen corruption patch for mvl-dove? Not sure where it got pushed anyway. I did not see any update when fetching
<tgardner> smb, the mvl-dove branch in Lucid?
<tgardner> smb, ah, forgot to push
<smb> apw, Tejun sent some patch to try out for bug 539467. Currently building natty based test kernels and then update the bug
<ubot2> Launchpad bug 539467 in linux "SATA link power management causes disk errors and corruption" [Medium,Confirmed] https://launchpad.net/bugs/539467
<smb> tgardner, Ok, makes sense then. Btw, then you have to apply to maverick-mvl-dove as well as that wont propagate on rebase
<tgardner> smb, the Maverick branch is actually copied from Lucid.
<tgardner> IIRC
<smb> tgardner, Hm, maybe I confure mlv with fsl then. One of them we rebased on an older release. 
<smb> confuse even
<tgardner> smb, Maverick uses debian.lucid-mvl-dove/etc/update-from-lucid-mvl-dove
<smb> tgardner, Ah, ok. Ignore me then
<tgardner> smb, I ignore you only at my peril.
<smb> tgardner, I am mostly harmless. Anyway, I think I lost track of the all those arms a bit
<tgardner> smb, I have trouble keeping them straight myself.
<smb> tgardner, Ok, got the update now. Oh, and just to be a bit more verbose on that config change. I just feel it would help those of us who are not that good at remembering things and are lazy (like me) to have a bit more hinting in the description of the commit than just the buglink. That was my concern there but my reply was a bit short
<rydberg> cfo, regarding yesterday, bugfix and explanation can be found here: https://lkml.org/lkml/2011/3/11/156
<JFo> <-lunch a bit early today
<JFo> bbiab
 * smb -> b.o.c.
<JFo> T.G.I.F.
<smb> JFo, T'is Good It's Friday? :)
<JFo> heh, yep :-)
<kristian-aalborg> hi all
<kristian-aalborg> please have a look here: http://ubuntuforums.org/showthread.php?t=1703598 (about building and moving a kernel)
<jjohansen> kristian-aalborg: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<jjohansen> kristian-aalborg: that will create a .deb file you can then copy that over and install with
<jjohansen>   sudo dpkg -i linux-imageXXXXX.deb
<kristian-aalborg> hi jjohansen - I think I tried that and failed, but I'll try again ;)
<jjohansen> where XXXXX is replaced by what the file is actually named
<kristian-aalborg> yup
<kristian-aalborg> can't remember what went wrong, might have been me being in a rush
 * kristian-aalborg is gone for 25 mins
<komputes> Major regression on Toshiba Satellite T215D - 2.6.32 Lucid kernel works, 2.6.35-27 Maverick only shows a blinking cursor when booting.
<jjohansen> komputes: can you open a bug
<komputes> jjohansen: will do, just wondering if anyones heard about an existing issue with 2.6.35-27
<jjohansen> komputes: I remember their were issues during development, but I am not aware of any in maverick atm.  Thats not to say there aren't some or even that there aren't open bugs just not ones I am aware of
<BenC> komputes: is it the same if you boot without quiet on the kernel command line?
<komputes> BenC: I can have them try that, any other recommendation/tips are helpful.
<BenC> komputes: I might have some more beyond that suggestion
<komputes> BenC: do you need to know what the last few lines are before suggesting further actions/troubleshooting
<BenC> yeah
<komputes> k, thx
<BenC> Hopefully it wont still be an empty flashing cursor :)
<komputes> fingers crossed
<kristian-aalborg> can I have a progress bar or something when building the kernel?
<tim> hi, is it possible to build the linux_tools package with make-kpkg?
<rob_> Can anyone help with gitweb and Mantis on ububtu?
<bryceh_> JFo, add bug 715330 to your list.  Kernel patch upstream identified.
<ubot2> Launchpad bug 715330 in xserver-xorg-video-ati "Freeze after login with KMS enabled on Radeon HD6310" [High,Confirmed] https://launchpad.net/bugs/715330
<JFo> bryceh_, will do
<JFo> bryceh_, it is already on there due to one of the enablement tags
<JFo> :)
<JFo> thanks for the head's up though
<bryceh_> great
<JFo> will leave myself assigned and inquire with the folks on Monday if that is ok
<JFo> k, have a good weekend, safe travels and all that. I think I am going to go get some exercise.
<kristian-aalborg> I've done make localmodconfig, doing make menuconfig now - but I can't find APM??
#ubuntu-kernel 2011-03-12
<kristian-aalborg> sudo apt-get build-dep linux-image-$(uname -r) ---- this command wants to fetch 800 megs?
<jjohansen> yeah
<kristian-aalborg> it seems to want all kinds of things that should not be related?
<kristian-aalborg> also, using this: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel --- where do I insert the .config that I made?
<jjohansen> it does pull in a lot, but that is the way the packaging is set up.  your not the only one who wishes that it was better about what actually gets pulled in
<jjohansen> kristian-aalborg: put your config in the debian/build/build-XXXX/ directory
<jjohansen> be careful about how you do it though as the build may blow it away
<jjohansen> basically
<jjohansen> fdr clean sets you up
<jjohansen> fdr = alias for fakeroot debian/rules
<jjohansen> fdr prepare-XXX  eg. fdr prepare-generic
<jjohansen> will setup the build and configs  (fdr binary-XXX will do this if it doesn't find it done)
<jjohansen> and fdr binary-XXXX will build the kernel
<jjohansen> you can manipulate files within the build if you play with the debian/stamps/ files
<jjohansen> there is one for prepare, and another for build
<jjohansen> so do an fdr prepare-XXXX, then copy your config in
<jjohansen> then fdr binary-XXXX
<jjohansen> if you want to make a small change and not rebuild the whole kernel
<kristian-aalborg> jjohansen: sorry, was staring at another screen
<kristian-aalborg> reading your msgs now
<jjohansen> rm the debian/stamps/stamps-build file
<jjohansen> kristian-aalborg: np, I ignore irc to get work done all the time :)
<jjohansen> and then reissue the fdr binary-XXXX command to rebuild, it will then to a build that only recompiles what is necessary for your changes
<kristian-aalborg> jjohansen: did you see my premise - this is being built on one machine, then moved to another
<jjohansen> kristian-aalborg: yep, so the extra stuff may not be needed, but if you find you need to recompile for some reason its real nice knowing how to do an incremental build instead of waiting for the kernel to have to be fully rebuilt
<jjohansen> basically all these steps are to be done on the machine you are building on
<kristian-aalborg> yes
<jjohansen> then its just a simple copy the deb and dpkg -i
<kristian-aalborg> there's no debian/build?
<kristian-aalborg> I thought .config should reside in linux-2.6.32/ (for example)?
<kristian-aalborg> jjohansen: could you tell me the exact commands to use, in the order I should use them?
<jjohansen> kristian-aalborg: is there a debian directory?
<jjohansen> fakeroot debian/rules clean
<jjohansen> fakeroot debain/rules prepare-generic   (could use -server, -virtual)
<jjohansen> cp .config debian/build/build-generic/
<jjohansen> fakeroot debian/rules binary-generic
<jjohansen> kristian-aalborg: ^
<kristian-aalborg> one second
<kristian-aalborg> machine is busy, installing something
<kristian-aalborg> yes, there is a debian dir
<jjohansen> kristian-aalborg: okay, the debian/build dir will be created during the prepare-generic command
<kristian-aalborg> ah, ok
<jjohansen> kristian-aalborg: oh also do you want your deb to have a different name?
 * kristian-aalborg shudders to think how this was during the first years of linux
<kristian-aalborg> yes, I'd prefer that
<jjohansen> hehe
<kristian-aalborg> it asks me to make mrproper
<jjohansen> kristian-aalborg: your in a git tree right?
<kristian-aalborg> no
<jjohansen> hrmm,
<jjohansen> mrproper will blow away some of the things you need
<kristian-aalborg> using the apt-get method
<jjohansen> mv the debian directory out of the kernel tree dir
<jjohansen> do the make mrproper
<jjohansen> and then mv the debian directory back into the kernel dir
<kristian-aalborg> this is debian.master?
<kristian-aalborg> I have a backup of everything I downloaded... would it be easier to start there?
<jjohansen> kristian-aalborg: ooops yeah, you need the debian and debian.master directories
<jjohansen> you can either copy them in fresh or start clean
<kristian-aalborg> let's start clean, this dir is probably a mess now
<kristian-aalborg> apt-get source linux-image-$(uname -r) <--- this is what I have
<kristian-aalborg> and the .config that I made, of course
<kristian-aalborg> jjohansen: you there?
<jjohansen> sorry back now
<kristian-aalborg> no problem
<kristian-aalborg> I really should go to bed soon, though
<kristian-aalborg> I'd just love to wake up to a fresh kernel with APM support ;)
<jjohansen> kristian-aalborg: where you building within the linux-image installed in /usr or did you copy it out
<jjohansen> kristian-aalborg: if you were working withing the /usr package you may need to reinstall to get a clean source
<jjohansen> if you have both the debian and debian/master directories within your dir
<jjohansen> I would recommend just moving them out, and doing a make mrproper
<kristian-aalborg> it's not in /usr, it's in /home/kristian
<jjohansen> kristian-aalborg: ah, well thats good
<kristian-aalborg> yup
<kristian-aalborg> what to do now?
<jjohansen> you have a clean tree?
<kristian-aalborg> yes, I should have
<kristian-aalborg> the downloaded files and a .config, nothing more
<jjohansen> cd into kernel tree
<jjohansen> fakeroot debian/rules clean
<jjohansen> fakeroot debain/rules prepare-generic
<jjohansen> cp .config debian/build/build-generic/
<jjohansen> fakeroot debian/rules binary-generic
<kristian-aalborg> when should I put the .config in?
<kristian-aalborg> also, does this give me a kernel with a custom name as to avoid confusion?
<jjohansen> step after prepare-generic
<jjohansen> no, it doesn't rename - to provide a partially custom name
<kristian-aalborg> ... just saw it, sorry
<jjohansen> you need to edit the changelog file
<jjohansen> so after prepare-generic and before binary-generic (cp can come before or after)
<jjohansen> edit your debian/changelog file
<jjohansen> its top line will look something like
<jjohansen> linux (2.6.35-23.36) maverick-proposed; urgency=low
<jjohansen> edit the line to be something like
<jjohansen> linux (2.6.35-23.36~custom) maverick-proposed; urgency=low
<jjohansen> this will show up in the debs name
<kristian-aalborg> gotcha
<kristian-aalborg> the last command actually starts the building of the files, right?
<kristian-aalborg> judging from the errors I get, it looks like it...
<jjohansen> yes
<kristian-aalborg> sorry, box died.... luckily not the one I'm builing
<kristian-aalborg> on
<kristian-aalborg> okay, thanks a lot for helping out... I'm looking forward to trying this baby out tomorrow
<jjohansen> np
 * jjohansen is out of here too
<kristian-aalborg> morning
<kristian-aalborg> kernel building ends with "make: *** [abi-check-generic] Error 1" and no .debs to be found
<Tomba23> Hi, does anyone know, what is the maximal settable limit for number of file handlers the process can create? On 64bit?
#ubuntu-kernel 2011-03-13
<kristian-aalborg> hi ppl
<kristian-aalborg> wohoo, I think it's almost there :)
<kristian-aalborg> jj-afk: ping?
<kristian-aalborg> hurm, I got a make error due to missing modules
<jj-afk> kristian-aalborg: skip_modules=true fakeroot debian/rules binary-generic
<kristian-aalborg> I passed it with the skipmodule=true flag, but it seems that something's amiss
<kristian-aalborg> it asked me to run mrproper, now debian/rules is gone (which I kind of knew it would be"
<jj-afk> right you need to move debian/ and debian.master out before running mrproper
<kristian-aalborg> I cp'd them from my backup dir
<kristian-aalborg> I'm mostly trying to figure out why the process won't run... I'm not expecting a working kernel atm
<kristian-aalborg> I wonder if it's the .config I made which is at fault?
 * kristian-aalborg boots up other computer 
<kristian-aalborg> jj-afk: I got the git version of the kernel, then followed the instructions you gave me the other day... correct?
<jj-afk> yep
<jj-afk> it should work with either but I have only ever used the git tree
<jj-afk> if you are using the git tree there is a trick you can use with make mrproper
<jj-afk> instead of moving the debian and debian/master files, you can do
<kristian-aalborg> my .config is made by apt-getting the source, then make localmodconfig and make menuconfig 
<jj-afk> make mrproper
<jj-afk> git checkout -f
<jj-afk> the git checkout -f will restore them
<jj-afk> okay
<kristian-aalborg> that
<kristian-aalborg> is the correct way, right?
<jj-afk> be ware that fdr clean and fdr prepare-generic will destroy / overwrite the .config so you need to copy it in after those
<jj-afk> yes it will work
<jj-afk> you can also use
<jj-afk> fakeroot debian/rules updateconfig
<jj-afk> err make that editconfig
<jj-afk> it will ask you which configs to edit and do a make menuconfig, and update the debian/config files
<kristian-aalborg> I have the feeling something's fundamentally wrong
<jj-afk> then you won't need to copy in your config
<jj-afk> give editconfigs a try
<kristian-aalborg> yeah
<jj-afk> start clean with,
<jj-afk> fakeroot debian/rules clean
<jj-afk> git checkout -f
<jj-afk> err actually switch the order (git checkout first)
<kristian-aalborg> this dir is a mess, I should probably back to start
<jj-afk> fakeroot debian/rules editconfig(s) ?
<jj-afk> if you haven't committed anything
<jj-afk> git checkout -f will undo your changes
<kristian-aalborg> really? all of them?
<jj-afk> its a good way to get back to a clean state
<jj-afk> well usually, there are few files it isn't tracking, but yeah
<kristian-aalborg> sweet
<kristian-aalborg> I'm getting a bit annoyed with Linus, though ;)
<jj-afk> hehe :)
<kristian-aalborg> is it common for this stuff to fail this much or should I check if something's wrong with my system somehow?
<kristian-aalborg> both computers in question are running 10.4... should "just work", I'd figure
<jj-afk> kristian-aalborg: well it depends what your doing,
<jj-afk> if you suspect a problem, try a clean kernel build with no changes
<jj-afk> that should work
<jj-afk> if it doesn't you know there is a something wrong
<jj-afk> if your just doing config changes, the recompile can be made to be pretty fast if the build is cleared
<jj-afk> well it depends on the config changes
<kristian-aalborg> nothing is fast on a 2g surf ;)
<kristian-aalborg> by "cleared", you mean doing fakeroot debian/rules clean?
<jj-afk> sorry, if it isn't cleared
<jj-afk> if you are doing a rebuild, and your changes don't require a full rebuild then you don't want to do an fakeroot debian/rules clean
<jj-afk> you want to rm debian/stamps/stamps-build-*
<jj-afk> make your changes / copy in your new configs
<jj-afk> and then do fakeroot debian/rules binary-generic
<jj-afk> this will keep the old build .o files around and Make will uses timestamps to figure out what parts need recompiling
<kristian-aalborg> I'm  starting over, it's easier I think :)
<kristian-aalborg> jj-afk: I'm back to basics now - where do I start?
<jj-afk> kristian-aalborg: just build the kernel with no changes, and see how that goes
<kristian-aalborg> good thinking
<jj-afk> fakeroot debian/rules clean
<jj-afk> fakeroot debian/rule binary-generic
 * kristian-aalborg is on it
<kristian-aalborg> gah, computer died
<kristian-aalborg> hi again
<kristian-aalborg> something I was thinking of... why isn't there a server where you can upload your .config and then download the .deb?
#ubuntu-kernel 2012-03-05
<reisei> hello! I have strange issue: on shutdown, after unmounting devices I got this messages, that repeats in cycle: http://pastebin.com/fLM84Y2G Can you advice me, what's wrong with my configuration?
<apw> reisei, that is a device which has not been shutdown correctly by the looks of it, i assume this is an arm device
<apw> dupondje, as it doesn't seem to be in stable as far as i can tell you'd need to file a bug to track it
<smb> mornings
<apw> smb, moin
<reisei> apw: yep, you're right.
<ppisati> moin
<dupondje> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/946928
<ubot2`> Launchpad bug 946928 in linux "sysfs: can not remove 'bsg', no directory" [Undecided,New]
<apw> ppisati, seen anything with arm boards not halting right, with errors from interrupts after 'System halted.' ?
<reisei> apw: ppisati MUSB if off, btw
<ppisati> nothing lately
<ppisati> reisei: which board?
<reisei> ppisati: variscite
<apw> dupondje, what did you do to trigger this, i'd be supprised if anyone hit it
<ppisati> reisei: variscite? omap3? omap4?
<dupondje> Mar  4 23:08:39 laptop-jl kernel: [19951.765869] sd 17:0:0:0: [sdb] Attached SCSI disk
<dupondje> this was just before ...
<dupondje> hit it 2 times even yesterday :p
<reisei> ppisati: omap4460
<ppisati> reisei: kernel version?
<apw> dupondje, attaching and detaching external USB disks ?
<dupondje> apw: yea seems so
<dupondje> it doesn't break anything anyway
<dupondje> but less spam in console is always good :D
<reisei> ppisati: 3.1
<ppisati> reisei: wow, 4460 on pci module? http://www.variscite.com/products/item/76-var-som-om44-ti-omap4460
<dupondje> anyway gtg now
<dupondje> and its raining like hell :(
<ppisati> reisei: btw 3.1 didn't have all the necessary bits to support 4460
<reisei> ppisati: yep. 
<ppisati> reisei: 3.1 vanilla or linaro? and, in case of linaro, which tree?
<reisei> ppisati: what do you mean by bits?
<ppisati> reisei: i mean support for freq scaling and dvfs
<ppisati> reisei: without these, the cpu overheats quickly
<reisei> ppisati: linaro, but it's somehow fixed by developer of that module
<ppisati> reisei: if it's the 3.1 tilt tree, then you should be ok
<reisei> ppisati: how can I check it?
<ppisati> try booting a 4460 panda board
<ppisati> with that kernel
 * apw bounces for a new kernel ...
<apw> wish me luck
 * smb already got that
<ppisati> i updated yesterday my laptop and it was ok, except for a garbled lightdm
<smb> Have not noticed that here, but maybe there was a change in today changing that
<ppisati> smb: well, i'm on unity2d so could be a 2donly issue
<smb> ppisati, Is lightdm not always 2d?
<reisei> ppisati: I don't have an 4460 panda, just an old one :-)
<ppisati> smb: uhmm... good point... actually i get the garbled screen after i logged in but before the desktop is all setup
<ppisati> reisei: uhmmm.. our kernels are tailored toward a set of boards, could be that you have to tweak some settings
<ppisati> reisei: do you always get this panic?
<ppisati> reisei: do you have a screenshot?
 * ppisati -> coffee++
<smb> ah... think that sounds like have that for as far as I can remember (more or less) with nvidia or ati
<reisei> ppisati: Reboot goes well. Only on halt. I have dmesg log: http://pastebin.com/fLM84Y2G
<ppisati> reisei: it seems it's a known issue - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53767.html
<ppisati> reisei: you should look for any changes in that driver within latest linus. rmk or omap tree
<ppisati> reisei: or simply ask agreen since he mantains that tree and maybe he already faced that problem
<apw> BAH just had a graphics lockup, the old hang when pulling the launcher out of the side
<reisei> ppisati: ok, thank you!
 * smb wonders whether <super>+<alt>+<cursor> stopped moving the window in focus for other people too (ctrl+alt+shit+cursor right now... wonder was it really that before changing it to something involving super?)
<brendand> smb - same here. unity help says super+alt is the correct one
<brendand> smb - when i try that it does something in xchat, but not to the window
<pkh> i've just upgraded to the beta and the kernel doesn't appear to support dmraid out of the box -- is this a bug or did I miss something out in the upgrade?
<pkh> i'm back and running with the kernel from before the upgrade fine, but thought I shoudl report it anyway.
<smb> Well I remember that there was someone saying they would do yomething about those keys (either change shift+super to something not hurting or completely revert). Just not sure whether it really was a three finger press before...
<smb> pkh, Hm, I thought I did an upgrade test with a dmraid setup and it worked. But yes, please report it (if possible with dmesg from the failure and for comparision from before)
<pkh> k, will do -- report where though?
<smb> pkh, Launchpad bug report. 
<pkh> k, will get on it.
<smb> ubuntu-bug linux  (or dmraid) one of those we can change it later
<smb> pkh, ^
<pkh> ah, just relised that i don't think i'll be able to get a dmesg -- root is on dmraid, with new kernel I get left with that limited shell.
<apw> pkh, you might be able to mount a usb stick within it
<pkh> k, will ahve a play tonight and send whatever I can get hold of thought
 * ppisati -> out for lunch
 * tgardner reboots tangerine for kernel upgrade...
 * smb just checked dmraid with the latest kernel and it still seems to work (at least for non-root usage)...
<brendand> if an sd card reader is connected on the scsi bus, is there any way to tell that it's an sd card reader?
 * cking --> back in 25-30 mins
<htorque> hello everyone! would any kernel hacker with working systemtap be so nice and run the following as a user (user must be in groups 'stapdev' and 'stapusr'):
<htorque> stap -e 'probe vfs.read {printf("read performed\n"); exit()}'
<htorque> this fails for me on ubuntu and works on fedora, and i'd like to know if others see this too.
<tgardner> ogasawara, ppisati, apw: Precise arm* chroots on gomeisa are borken, so use tangerine. its something to do with qemu.
<ogasawara> tgardner: ack
<ogasawara> how is it I just learned I can cherry-pick a range of commits now
<ppisati> cool, latest kernel hangs on omap3
<tgardner> ogasawara, is that something new with the latest git ?
<ogasawara> tgardner: I think so.  it's awesome.  now if only I could do an interactive cherry-pick...
<ppisati> tgardner: afaik arm precise chroot have always been broekn due to a qemu bug
<ppisati> tgardner: they never worked
<tgardner> ogasawara, can you filter based on a directory or file ? e.g., git log prettyprint=online -- fs/ecryptfs
<tgardner> ppisati, its a host issue. works fine on tangerine (which is precise).
<ppisati> tgardner: ok
<ogasawara> tgardner: yep
<tgardner> ogasawara, so, something of the form 'git cherry-pick v3.2..HEAD -- fs/ecryptfs' ?
<ogasawara> tgardner: hrm, dunno about that.  /me tests
<ogasawara> tgardner: yep, that works
<tgardner> ogasawara, cool, stands to reason.
<tgardner> ogasawara, hmm, I wonder what it does about merge commits ?
<ogasawara> tgardner: I assume it'll vomit some type of conflict that'll need resolved
<tgardner> prolly
<ogasawara> tgardner: but for the most part, it's much easier to sync patches from P to Q now
<tgardner> yep, I can imagine
<tgardner> ogasawara, I assume you noticed I rebased sometime over the weekend ?
<ogasawara> tgardner: I did, thanks.
<cking> tgardner, my last ecryptfs patches probably need the SOB and buglink popped in to the patch before applying it to Natty - my fail to pop them in
<tgardner> ogasawara, I've been running it on one of my problematic wifi laptops. it seems to work pretty well..
<tgardner> cking, already taken care of
<cking> ta
 * cking will try to do it right next time..
<tgardner> cking, I figured its best not to annoy you with minutiae
<cking> :-)
 * smb had been assuming tgardner would do so, too
<tgardner> cking, besides, I have the magic bjf/herton script that will munge any patch with aplomb.
<cking> ah, nice one
<tgardner> cking, kteam-tools/maintscripts/maint-modify-patch
<tyhicks> cking: Judging by all the eCryptfs-related SRU work you've done on the kernel-team mailing list recently, me slapping on the 'Cc: stable@vger.kernel.org' tag isn't cutting it.
<tyhicks> cking: What can I do differently to help make sure these types of patches don't get lost?
<tgardner> tyhicks, some of these went onto Natty which is no longer a supported stable kernel.
<cking> tyhicks, I suspect that if they don't apply cleanly then don't land in stable
<tyhicks> cking: Right, but gregkh's scripts automatically alert me that something marked for stable didn't apply. I've only ignored 1 of those emails and that was a year or 2 ago.
<cking> and as tgardner said, for the Natty these need some love and attention
<tyhicks> So when I feel something is important enough to mark it for stable, should I also send it to the kernel-team ML after Linus takes it in?
<tgardner> tyhicks, that couldn't hurt
<tyhicks> tgardner: Sounds good - that is trivial for me to do
<cking> tyhicks, fortunately the list of outstanding patches for me to test and SRU is quite small now
<tyhicks> cking: Great! Thanks for all of the work you've done on that!
<cking> np
<tyhicks> cking: Hopefully I can change my workflow up a little where backports for certain releases don't get lost in the shuffle
 * cking nods
<tyhicks> (going forward)
<brendand> herton, bjf - we're trying to get the oneiric SRU done asap. could be tomorrow or maybe wednesday though
<bjf> brendand: huh
<brendand> bjf, last week was supposed to be the regression testing week. we're a little behind due to a few recent issues with our test systems
 * ogasawara back in 20
 * apw dispairs at the total inequality of computation on gomisa ... how can i have 1/5th of the build threads that leann does and yet get 1% of the forward progress
<apw> why do her threads get priority
<ogasawara> apw: they love me more :)
<smb> bjf, I wonder whether you are currently more successful in getting cobbler to update images. Whenever I run cobbler-ubuntu-import it obscurely fails and leaves a tmp-* distro around (upgraded to precise)
<bjf> smb, i'll send you my runes
<smb> bjf, Thanks. But beside that, is that a known breakage? IOW do they (server-team) know about it if yes?
<apw> ogasawara, i have been thinking about it and monitoring your builds and i cannot fathom it
<apw> ogasawara, i am starting to believe your priority is based on len(username) its about the only thing that makes sense to me
<apw> cking, how is your build progressing ?
<apw> cking, will you tell me when it completes
<cking> apw, like ogasawara has 90% of the cycles and I'm left with the crumbs
<cking> scheduler has US <-> UK biasing controls?!
<apw> len(ogasawara) > len(cking)
<cking> len(cking) > len(apw) WIN
<Sarvatt> there's always tangerine, but it builds kernels 3-4x slower than gomeisa does after it got upgraded to precise :)
<ohsix> any one reason?
<cking> all the cycles are being used by the HUD
<Sarvatt> it used to take 11 minutes vs gomeisa's 9 when it was on lucid, now that its on precise its 31 minutes
<apw> Sarvatt, that is positivly awsome ...
<apw> tgardner, do we still have a .32 kernel avail on tangerine ?
<cking> any physical changes on that box?
<apw> ogasawara, are your builds done ?
<Sarvatt> i noticed it first being slow on jan 20th but i hadn't built a kernel since december before that, tgardner said it was upgraded to precise in budapest
<tgardner> apw, its a precise user space
<ogasawara> apw: yep, they finished while I was away
<apw> ogasawara, perplexing your entire builds fitted into the last 1/3rd of mine, which took enormously longer than normal
<apw> i cannot fathom what the hell is wrong with the scheduling 
<ogasawara> apw: something is definitely amiss as I seem to always get priority, even when you've already been building ahead of me
<apw> tgardner, indeed, and was thinking perhaps a .32 kernel might let us see who is to blame for the performance loss Sarvatt is reporting
<apw> ogasawara, you use a higher concurrency for sure, but i don't seem to get a proportionate slice, and that i cannot figure
<ohsix> Sarvatt: i'd be interested in the cause of the slowdown if you find out; they did some io stuff that was supposed to alleviate a lot of suck from .32-3.2
<tgardner> apw, otp
<slangasek> herton: kees has uploaded your patch to udev for DM_COOKIE handling, after we discussed it yesterday at the global jam - thanks for the patch :)  Have you sent it to udev upstream?
<herton> slangasek, cool. Not sent upstream already, will take a look
<herton> s/already/yet/
<kees> it'd need to go with the timeout patch too
<herton> hmm indeed. apw, did you try to send the timeout patch, I think we would need to send both
<kees> apw: looks like while viro says i_uid should be valid, I think calling vfs_stat is the right fix for yama. I'll send a patch
<apw> herton, i did try, they said the kernel should not do that (emit events in the middle of handling one from udev) and they wen't going to take it
<apw> kees, if i_uid is meant to be valid (and i agree that is what al says) then why is what you are doing wrong as it is?
<herton> ok, so probably they will reject the DM_COOKIE patch also...
<herton> which depends on the timely patch
<apw> herton, i would expect them to, but trying to send it again (both indeed together if that makes sense) may not be pointless
<kees> apw: seemed easier than trying to plumb the logic into overlayfs, especially in the face of it maybe being a problem with other filesystems in the future.
<htorque> hi all! anyone here using systemtap?
<apw> kees, and the cost of calling stat there?
<cking> htorque, I tested systemtap on Precise with some kernel stap scripts last week
<tgardner> ogasawara, pushed a patch to ubuntu-precise-meta. please give it a quick looksee.
<ogasawara> tgardner: ack
<tgardner> smb, does VNC console access to a Xen VM require X components ?
<htorque> cking: you don't have it currently running i guess? i can't seem to get it to work as unprivileged user and wanted to know if it's just my setup or if it fails for other ubuntu users too (as the same steps work on fedora)
<tgardner> bug #944582 argues that xen-kbdfront should be included  in the virtual flavour
<ubot2`> Launchpad bug 944582 in linux-meta "xen-kbdfront module should be provided by linux-image-virtual or linux-virtual" [Undecided,New] https://launchpad.net/bugs/944582
<htorque> like running this as user (which must be in groups 'stapusr' and 'stapdev'): stap -e 'probe vfs.read {printf("read performed\n"); exit()}'
<tgardner> cking, is there a yama switch that you have to flip ?
<cking> htorque, I always run it using sudo
<htorque> cking: that's working here too
<smb> tgardner, On the guest I don't think so. The host, not sure, I did not by itself install things but never checked
<smb> tgardner, the kbdfront would likely be good for console... I'll look at it
<tgardner> smb, can you offer your opinion in the bug?
<cking> htorque, I need to load the .ddebs for /me to try it out, let me find a box where I can test this..
<smb> tgardner, Right, we should put that into the main package. Not sure why it is in extras...
<htorque> cking: that would be great (if it's no trouble to you).
<cking> it will take me a little while to set up (my ISP is rate throttling me at the mo)..
<tgardner> smb, ok, will do
<htorque> cking: yeah, downloading the 650 mb is no joy. :-(
 * cking nods
<smb> tgardner, Ah ok, would have send out a patch to change it otherwise
<tgardner> smb, its precise, I'll just do it.
<smb> tgardner, ack
<smb> tgardner, Either you were so quick or its already there but in the wrong place
<tgardner> smb, haven't done anything yet....
<kees> apw: that's the concern -- it's a bit expensive. semi-related -- why add the yama_permissions() function instead of using vfs_permissions()?
<apw> i am not adding yama_permissions ?
<apw> kees, ^^
<apw> kees, this is coming from someone doing a touch 1; chmod 444 1; ln 1 2 ... within an overlayfs and yama barfing ... its std higher level permissions
<smb> tgardner, I did a quick package check, it seems its there in precise but not in oneiric
<tgardner> smb, the path is wrong in oneiric. I'll send an SRU patch
<smb> tgardner, Bah, seems a type hit us. I sent a quickly whipped up patch to mailing list
<smb> tgardner, Nearly the same time
<smb> :)
<smb> tgardner, But yes, seems in Precise it is correct but it is wrong for Oneiric
<tgardner> smb, go ahead and send yours. I'll work on the meta package description updates
<smb> tgardner, Just hit the list
<kees> apw: the yama_permissions call from last year is what I mean -- why create that instead of using vfs_permissions ?
 * apw can't even find vfs_permissions now, let alone then <-- kees
 * kees goes looking
<kees> apw: ah! sorry -- inode_permission
<apw> that does a lot more than you already did, an i wasn converting 'generic_permission()' to somethign correct in the face of a permissions op
<kees> what about do_inode_permission()? that's nearly identical.
<apw> i worry slightly that you are in a LSM op, and you call that you are calling security_inode_permission
<kees> do_inode_permission avoids that, but is static.
<apw> do_inode_permission is definatly what it means, but as you say not exported
<apw> i think i'd refer back to you and ask what did you mean to check what permissions
<kees> okay, so I'll leave yama as-is, and for Q, we can remove the yama link restrictions in favor of upstream
<apw> as its always possible inode_permission is right
 * apw makes a note that overlayfs should be using it too
<apw> bah
<kees> it was unrelated to the overlayfs issue -- It was just a question I'd been meaning to ask you from when I converted the Yama link restrictions to the upstream VFS layer link restrictions
<apw> yeah an it is an unrelated note to self
<apw> that i adeded half that routine to overlayfs, and possibly i should using it
<apw> with a minor success under his belt, and having not figured out why everyeone gets prio i am giving up ... till tommorrow
<cking> htorque, I suspect you may need to configure systemtap-server to get it working w/o root privilege, but I'm darned if I can get it working at the moment, I'll give it a another try tomorrow
<dupondje> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/946928 , 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3 is the commit id in upstream? http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3
<ubot2`> Launchpad bug 946928 in linux "sysfs: can not remove 'bsg', no directory" [Medium,Triaged]
<jsalisbury> dupondje, yes, it appears to be in the linux-stable tree.  You should see it if you run the following in the linux-stable src tree:
<jsalisbury> git show 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3
<jsalisbury> dupondje, that commit is also in Precise.
<dupondje> lets see
<dupondje> jsalisbury: the commit is not there in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=tree;hb=HEAD
<jsalisbury> dupondje, hmm, interesting.  The commit is reported with git log, but it looks like the following is indeed not it ~block/bsg.c: 
<jsalisbury> -       sysfs_remove_link(&q->kobj, "bsg");
<jsalisbury> +       if (q->kobj.sd)
<jsalisbury> +               sysfs_remove_link(&q->kobj, "bsg");
<jsalisbury> dupondje, I'll do some further research and update the bug.
<tgardner> jsalisbury, you need to use --contains, e.g., 'git describe --contains 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3'
<jsalisbury> tgardner, ahh, that makes sense.  So that means the patch is in v3.3-rc4, but not in linux-stable.
<tgardner> jsalisbury, correct
<jsalisbury> tgardner, I wasn't aware the linux-stable tree would have commits for the mainline tree.
<tgardner> jsalisbury, well, of course it would. for example, 3.2 stable has all of the mainline commits up through v3.2. everything on top of that would be stable commits with a different SHA1
<dupondje> just cherry pick it :)
<tgardner> dupondje, already done
<dupondje> great
<jsalisbury> tgardner, So any commit to the mainline tree will automatically show up in a 'git log' run against the linux-stable tree, even if it isn't applied to linux-stable yet?  And when the commit is applied, it gets a new SHA-1?
<dupondje> tgardner: jsalisbury: changed bug to Fix Commited! thx
<jsalisbury> dupondje, thanks
<jsalisbury> tgardner, hmm, ok.  I can see all the tags up to v3.3-rc6 in the linux-stable tree.  
<tgardner> jsalisbury, its relative to the branch that its on, and perhaps how you've populated your repo. for example, if you've ever done a 'git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master', then you'll have _all_ of mainline regardless if the object is in a branch.
<tgardner> jsalisbury, its likely thats what greg k-h has done
<jsalisbury> tgardner, ok, I understand now.
<tgardner> dupondje, don't put URLs to gitdiff in a bug because the SHA1s are not immutable until the final kernel freeze before release.
<dupondje> oh didn't know
<dupondje> anyway :)
<jsalisbury> tgardner, Unless I'm searching wrong, I looks like the commit is not in 3.2.8, but it is in 3.2.9
<jsalisbury> tgardner, I run this command under both branches:
<jsalisbury> git log --pretty=oneline | grep 'bsg: fix sysfs link remove warning'
<htorque> cking: thanks, that's the only thing left for me to try. it's working under fedora though.
<jsalisbury> tgardner, but I only see the commit when on the 3.2.9 branch.
<cking> htorque, I suspect it is some user space foo config that we're missing
<smoser> smb, ping
<htorque> cking: would just be nice to know that foo and document it somewhere (ideally at both wikis). especially with user-space probing you want to be able to run stuff as normal user.
<tgardner> jsalisbury, you're looking at linux-3.2.y ? I'm not seeing it there.
<cking> htorque, i agree
<jsalisbury> tgardner, Yes, my .git/config file points to:  url = git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
<htorque> anyways, thanks again for trying. :-)
<jsalisbury> tgardner, maybe I'll blow it away and re-clone it.
<cking> htorque, I can't promise I can figure it out immediately, the workaround is run it with sudo for the moment I suppose
<tgardner> jsalisbury, there are a number of branches in that repo. make sure you have 'git checkout -f linux-3.2.y'
<jsalisbury> tgardner, ahh, maybe that's what I'm doing wrong.  I was getting the branches with git checkout v3.2.8 and git checkout v3.2.9
<htorque> cking: sure, no need to promise anything. it's good enough to know that it's no 'layer 8' issue for now. ;-)
<tgardner> jsalisbury, if you don't already have that branch, then 'git checkout -b linux-3.2.y remotes/origin/linux-3.2.y'
<jsalisbury> tgardner, not with the linux- prefix
<jsalisbury> tgardner, do you happen to know the difference between the v3.2.8 and linux-3.2.y tags?
<jsalisbury> tgardner, where v3.2.8 can be v3.2.N
<tgardner> jsalisbury, linux-3.2.y is a branch in which the tag v3.2.8 exists
<jsalisbury> tgardner, doh, right.
<jsalisbury> tgardner, so I was looking at the v3.2.9 tag in the master branch or linux-stable.
<tgardner> jsalisbury, yep
<jsalisbury> s/or/of/
<jsalisbury> tgardner, And the master branch in linux-stable contains the mainline commits as well?  That's why I was seeing that commit.
<tgardner> jsalisbury, yes, it probably _is_ Linus' master branch. I haven't looked too close.
<jsalisbury> tgardner, thanks for the help.  I think I have my head on straight now :-)
 * jsalisbury plans on studying all the branchs and trees closer.
<tgardner> jsalisbury, do a 'git branch -a' to see all of the remote branches in the linux-stable repository
<jsalisbury> tgardner, perfect, thanks!
<jsalisbury> tgardner, The linux-stable repository is making much more sense now.  Thanks for all the info.
<tgardner> jsalisbury, anytime
 * jsalisbury owes tgardner one more beer :-)
<cking> mmm. beer
 * tgardner thinks it good to have beer favors
 * tgardner -> EOD
<GrueMaster> sconklin: Are you online?  Questions on this power amp meter.
<sconklin> GrueMaster: I'm just barely still here, what's up?
<GrueMaster> I am failing in my attempts to get meaningful power from this atx harness.
<GrueMaster> I can get decent readings from a Via ITX board, but not on this arm board.  I have vamp'd into the 3.3v, 5v, and 12v power lines.
<sconklin> Do you get any readings at all? Are they all pretty high and don't show variation when the load changes?
<GrueMaster> The other issues is the closest I have to an electronics store is Ace Hardware, so connectors are hard to come by.
<sconklin> (high is a relative term)
<GrueMaster> The best reading I have seen is on 5v, but it is ~0.0000045 amps when booting.
<GrueMaster> For reference, a panda is drawing 1.5 amps.
<sconklin> when you are cutting into the power supply lines to measure current, are you sure you're cutting all the other lines with the same voltage?
<sconklin> You have to get it down to one supply wire and measure that
<GrueMaster> Yes.  All Orange (for example) are cut, and each group is twisted together and crimped into a connector, female on one side, male on the other.
<GrueMaster> I knew that.
<sconklin> I figured you did, but the symptom of very low current measurement is consistent with not having all the supply lines cut
<GrueMaster> Only wires left are common (black), +3.3v Sense, Power on, and power good.
<GrueMaster> I'm going by http://en.wikipedia.org/wiki/ATX#Power_connection_to_the_motherboard
<GrueMaster> Using the 20/24 pin connector for reference.
<sconklin> what's the board? It's possible that the current draw is really low if you're booting from flash compared with something else, for example
<GrueMaster> For this initial test, Marvell Dove (from pre-Maverick).
<GrueMaster> But even my beagle (omap3) draws 0.5 amps on power-up.
<sconklin> yeah I would expect something like that. microamps is not in the ballpark
<GrueMaster> The Marvell board is about the size of a full atx board.
<GrueMaster> The kill-a-watt on the other side of the PS is showing more amps than that.
<GrueMaster> Even given power drain.
<GrueMaster> I have also used a power supply tester to check amp loads.
<sconklin> I suppose it's possible that the meter fuse is blown for current measurement
<sconklin> have you moved it back to another board that gives a sane reading?
<GrueMaster> Yes.  Both Panda and Via ITX boards give sane readings.
<GrueMaster> Of course, after my last test, half the wires came out of their crimp connectors so I have to redo that.  PITA.
<sconklin> and the board uses 12V and 5V and 3.3V lines? and you're measuring the 5V line?
<GrueMaster> I have measured all three lines.
<GrueMaster> 5v is the only one that actually registered with the meter.
<GrueMaster> The only other thing I can think of is that the board is drawing from what ever power seems better.  But there aren't enough electronics on the board to do in-line voltage regulating.
<sconklin> I don't know what to tell you. The meter is working, because you tested it against another board
<GrueMaster> Yes, and it works well on other boards.
<sconklin> Inserting the meter shouldn't cause any changes in where it takes power from, so nothing should change 
<GrueMaster> Very frustrating.
<sconklin> and it boots and runs, right (I have to ask)
<GrueMaster> I'm going to rebuild the harness with the connectors soldered in so they don't fall apart.  Then I will try powering with them all unplugged to see if the board is drawing power via osmosis or something.
<sconklin> You could try opening the return line (black), and that will measure the return current for all the supply voltages. But that's a lot of wires.
<GrueMaster> Yes, I am monitoring it via serial console every time.
<sconklin> you've invented free energy.
<GrueMaster> I thought of chopping black, but I am limited by what I have available.  There are 8 black wires, and I have no easy way to put a connector in between.  I don't want to fry anything (even though I am using a board we don't care about).
<GrueMaster> I'll rebuild the cable and go forward.  I might have missed a power line, but not one of the main ones.  I'm positive about that.
<sconklin> ack, let me know
<GrueMaster> If this doesn't work, tomorrow I make a day trip to Fry's.
#ubuntu-kernel 2012-03-06
<drbcladd> Upgrade to 12.04b on Alienware m17 with Corsair SSD as sda. Reboot to kernel panic. Tried booting daily build on CD, same panic. Best information I have: squashfs was logging; pagefault, null RIP message, kernel panic "not synching fatal exception in interrupt" then a line with pid and "comm: mod probe tainted G      D"
<drbcladd> Posting in an effort to that disk to boot, sure, but also, what information can I give you when it doesn't even get to logging?
<drbcladd> Well, good people, it is just about my bedtime; I will hang out here later and see if I can provide useful information for bug hunting. Thanks to the kernel team for their hard work.
<GrueMaster> What ever happened to the 3 week SRU cadence?  I tested SRU kernels last week, the week before, now I am seeing yet another omap4 kernel SRU notification?
<GrueMaster> Can we have some semblance of a scheduled release?
<herton> GrueMaster, we are on the 3 week cadence, this week we will have new kernels prepared, nothing extra. Also there are kernels still from previous round that are pending or were not tested: a new maverick ti-omap4 with the fix for QA regression you identified (linux-ti-omap4 2.6.35-903.32, bug 942766, see the duplicate bug which was the update that you failed QA, fixed in this new one). And kernels from previous round still pending testing: linux
<herton> -fsl-imx51  2.6.31-612.33 (bug 931913), linux-mvl-dove 2.6.32-423.42 (bug 932240). For more information on pending updates, see http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
<ubot2`> Launchpad bug 942766 in kernel-sru-workflow "linux-ti-omap4: 2.6.35-903.32 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/942766
<ubot2`> Launchpad bug 931913 in kernel-sru-workflow "linux-fsl-imx51: 2.6.31-612.33 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/931913
<ubot2`> Launchpad bug 932240 in kernel-sru-workflow "linux-mvl-dove: 2.6.32-423.42 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/932240
<herton> And this is the schedule, https://wiki.ubuntu.com/PrecisePangolin/ReleaseInterlock, we are on the SRU prep this week (new kernels)
<GrueMaster> I see what appears to have happened.  Somewhere in the middle, I got side tracked with milestone testing.  Silly me.  
<GrueMaster> Actually, most of the testing had been done, was just waiting for me to pass/fail.  Babbage was the only straggler, and it is running now.
<rbasak> What would happen if I tried to boot precise userspace using a 2.6.32 kernel? Would it work? Is there any particular reason why it wouldn't?
<smb> rbasak, Chances it does work are reasonably good. The major problem would be interface changes. One would think of drm, but also sysfs had the tendency to change at some point in an incompatible way
<smb> But normally it is more problematic than going forward
<smb> (like booting a precise kernel in lucid userspace)
<smb> Because userspace tends to expect certain new features
<rbasak> smb: thanks. drm won't be a problem as this would be headless. This is for hardware that isn't upstream and would require separate enablement work
<rbasak> smb: I'll get them to try it :)
<smb> rbasak, The only way to say with more certainity. :) 
<rbasak> :-)
<smb> I recently booted 2.6.38 on precise in a vm which seemed to work. Did not go further, though
<apw> rbasak, i might expect it to work, but you get to keep all the pieces
<rbasak> Understood :)
<ppisati> smb: do you remember what's the script used to invalidate a tracking bug? i know it's part of kteam-tools but i don't remember the name off hand
<smb> ppisati, Its so long ago, I would not know from my memory. I think I may even just have set the status to invalid which likely is wrong... hmmm
<ppisati> smb: found
<ppisati> smb: kteam-tools/stable/check-release-tracking-bugs
<smb> "obviously"...
<ppisati> smb: yeah... :)
<ppisati> smb: i was AFK, could hear you but couldn't answer...
<smb> ppisati, No worries, I am just generally ranting into unspecific directions... :-P
<ppisati> smb: "ranting in the wind" that's a famous song...
 * smb thought that was "blowing in the wind" ;)
 * ppisati -> out for lunch
 * henrix follows ppisati 
<apw> :q
<henrix> apw: wrong buffer
<apw> sforshee, hey was there something for macbook brigtness in the -18 kernel ?
<sforshee> apw, there's a new driver that gets screen brightness adjustable for some macbooks
<apw> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/947748
<ubot2`> Launchpad bug 947748 in gnome-settings-daemon "Brightness control not working after latest update" [Undecided,Confirmed]
<apw> sforshee, then that is likely fallout
<sforshee> apw, I'll follow up
<tgardner> apw, grub2 just got uploaded with 20+ patches.
<apw> tgardner, deep joy
<tgardner> apw, I had the same revelation
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<sforshee> apw, I don't think the brightness thing is a kernel problem. I'm seeing it on a macbook air that does not use the new driver (the module isn't even loaded). Can't adjust backlight using the buttons or settings, but I can adjust it through sysfs.
<apw> sforshee, cool, can you point them at how to debug in the bug
<sforshee> apw, ack
<apw> seb128, ^^
<Laney> fwiw with the latest kernel my macbook pro doesn't suspend when I shut the lid, but running sleep.sh does suspend it
<Laney> what's the bug number?
<seb128> sforshee, apw: thanks
<seb128> Laney, bug #947748 is the one we discussed
<ubot2`> Launchpad bug 947748 in gnome-settings-daemon "Brightness control not working after latest update" [Undecided,Confirmed] https://launchpad.net/bugs/947748
<seb128> but it doesn't include suspend issues so far
<Laney> ok, I wonder if those are linked
<Laney> didn't check brightness
<tgardner> Laney, I'm sure sforshee has a bug on that somewhere. I experienced the same issue.
<seb128> sforshee, apw: g-s-d power code didn't change a lot, I would be a bit surprised if that's a g-s-d issue...
<Laney> tgardner: ah OK
<Laney> got a bit of a shock when returning home last night that the laptop was whirring away on the bed ...
<apw> sforshee, isn't Laney's issue more likely the edp issue ?
<tgardner> Laney, https://wiki.ubuntu.com/Kernel/MacEnablement
<Laney> mine is a 7.1
<sforshee> apw, could be
<Laney> lid suspend always worked until now, but to be fair I hadn't rebooted for weeks so was probably on a rather old kernel before
<sforshee> seb128, I'll reboot to the previous kernel and see if it works, but for this machine nothing should have really changed between kernels
<seb128> sforshee, thanks
<apw> Laney, there is an issue in which the internal edp is detected as external by g-s-d, and we do no suspend on lid if there is an 'external' monitory
<Laney> sorry, I don't know what edp means :(
<sforshee> embedded display port
<Laney> ah
<Laney> can I confirm this somehow?
<sforshee> seb128, can't adjust brightness with -17 either, and I know it used to work with that kernel
<seb128> sforshee, is the slider displayed in the ui?
<seb128> sforshee, do you know how to query udev for "backlight" devices?
<Laney> brightness works btw
<seb128> the code basically does devices = g_udev_client_query_by_subsystem (client, "backlight");
<sforshee> the slider appears briefly then goes away
<apw> seb128, did udev change ?
<seb128> apw, yes
<sforshee> so someone else was having touchpad problems because udev wasn't done when the desktop started, wonder if that could be happening here as well
<seb128> apw, but the change doesn't seem likely to create issues
<seb128> "do not exit across a pending DM_COOKIE"
<apw> seb128, well as sforshee said, booting the old kernel with this userspac is step one
<apw> if that works, then its kernel, else its not
<apw> and we will want to start downgrading udev, and g-s-d to see which of them it is
<seb128> right
<seb128> downgrading g-s-d next would be welcome
<seb128> sforshee, apw: btw the current gnome-desktop3 includes the edp fixes from sforshee
<seb128> i.e http://git.gnome.org/browse/gnome-desktop/commit/?id=11997d32313cd67f24cb26e18c562fa4b75ea36f
<seb128> not sure if that's the issue you were looking at for Laney's suspend issue
<Laney> I am testing -17
<Laney> but you don't suspect a kernel problem so :-)
<apw> Laney, i think they are saying if you have everything up to date squeeky new we might expect it fixe
<Laney> oh ok
<Laney> I dist-upgraded yesterday morning, so if it's since then then maybe
<sforshee> seb128, I installed g-s-d 3.3.90-0ubuntu4 and now my backlight buttons work
<seb128> sforshee, ok, great
<sforshee> also the keyboard brightness indicator displays correctly
<seb128> sforshee, is the slider in the power system settings ui showing as well?
<sforshee> seb128, yes
<seb128> sforshee, thanks for testing! and it's broken if you update gsd?
<seb128> sforshee, can you get a G_MESSAGES_DEBUG=all gnome-settings-daemon --debug for both version?
<seb128> sforshee, I would like to see what changed
<sforshee> seb128, going back to 3.3.91-0ubuntu1 makes everything break again
<sforshee> seb128, I'll get the debug output for you and put it on the bug
<seb128> oh
<seb128> sforshee, $ /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-brightness
<seb128> sforshee, what does that return?
<sforshee> seb128, it seems to be giving the correct values
<seb128> weird :-(
<seb128> there is basically 3 commits in the power code between those versions
<seb128> http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=0fc947c590ec40f492af16cef5e3de7775ba08ab
<seb128> http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=305057ac831b357a03bb3f244059048551321b71
<seb128> http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=d361fcee80bbcf8cf2dd692eb91b05800b29f5fb
<seb128> but I don't see any of those leading to issues
<seb128> the only one that could make it bail out is the < 0 check
<seb128> sforshee, what is you get the max value rather than the current one?
<seb128> does the value seem correct?
<seb128> --get-max...
<sforshee> seb128, the value is correct
<seb128> ok
<seb128> dunno then... I will look at the debug log and the code
<seb128> sforshee, thanks
<sforshee> seb128, what's the best way to get g-s-d launched with the debugging you asked for?
<seb128> sforshee, kill the running one and copy the command I gave
<seb128> kill -9 `pidof g-s-d`; g-s-d --debug
<seb128> if gnome-session is respawning it usually that will let you hijack it
<seb128> export G_MESSAGES_DEBUG=all first though
<seb128> that's needed for the logging to work
<sforshee> yeah, it's the respawning that gets in the way
<sforshee> seb128, just posted the g-s-d debug output to the bug
<seb128> sforshee, thanks
 * ogasawara back in 20
<GrueMaster> herton: Not sure you saw my post last night after yours, I had lost track of last week due to milestone testing and a huge amount of other work I was doing (so in essence I am missing a week of sanity).  :P
<Laney> I just checked with new everything and the suspend failure is still there, btw
<herton> GrueMaster, ok, np
<GrueMaster> At this time (barring the latest spin of SRU kernels) I believe I have tested everything to date.
<GrueMaster> Also, when will we be dropping the imx51 kernels?  Lucid was only 18 months for arm, and the last of the buildds should have been replaced with Panda now afaik.
<henrix> apw: here's the link: https://bugzilla.kernel.org/show_bug.cgi?id=22602
<ubot2`> bugzilla.kernel.org bug 22602 in FAT/VFAT/MSDOS "Oops while unmounting an USB key with a FAT filesystem" [Normal,Assigned]
<jsalisbury> apw: http://www.spinics.net/lists/linux-scsi/msg57577.html
<jsalisbury> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/738876
<ubot2`> Launchpad bug 738876 in linux "BUG: unable to handle kernel NULL pointer dereference at 00000000000000f0" [Medium,In progress]
<sandjkirkland> I am having issues with oneiric to where the computer freezes and the monitor goes white, at random. 
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Mar 13th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<davmor2> hey guys If I do a fresh install from the beta1 64bit desktop cd/usb it hard crashes the entire system starting the slide show for me on this system is there anything I can do to get some better logs to try and figure out what is causing it
<apw> davmor2, if you boot it and don't install does it survive being used ?  you might be able to figure out how to trigger the issue there perhaps
<apw> davmor2, i assume when you say hard crashes you have flash capslock, and you are unable to switch VTs
<davmor2> apw: it runs fine from usb (I don't have a cd/dvd here)  and I've run the code for the slide show from the desktop to see if it is that, that is causing the crash and nothing but with out fail if I run the installer I get the crash
<apw> davmor2, and the symptoms of the crash are?
<davmor2> apw: And yes not sure about the flashy led but there it no way to access the tty's
<apw> are you able to access the ttys from the live boot... i can't remember if its enabled
<apw> davmor2, how long do you have from hitting 'GO' to when it breaks in the slide show?
<davmor2> apw: so I hit the last continue button and then a few seconds pass,  the slideshow never starts and the system dies
<apw> so that must be when it does the formatting of your disks right ?
<apw> if it is crashing and you have a 'few seconds' you might be able to switch VT to whereever the kernel has its outptu going
<apw> so that you can see it when the panic comes (assuming it is one)
<davmor2> apw: I'm in millbank currently so I've run through it with ev to try and diagnose anything from ubiquity's side and nothing breaks it unless I do an install
<apw> davmor2, ahh ok, well we'll be in tomorrow also so if we don't make progress here, ask my body about it
<davmor2> apw: ah I'm back in wolvo tonight only down for today
<apw> davmor2, anyhow one of the other VTs has the raw kernel output i beleieve, if you can find that and switch to it before the crash you might get some more info
<davmor2> apw: Cool I'll try that tomorrow as I need the system today
<apw> you can try and find it in the live boot i presume, and look for something which looks like the bottom of the dmesg output
<apw> sandjkirkland, have you filed a bug for this issue?  do we know if the machine is completely dead, for example are you able to access the machine over the network when this occurs
<apw> jsalisbury, bug #938894 us t
<ubot2`> Launchpad bug 938894 in linux "BUG: unable to handle kernel paging request, __ticket_spin_lock+0x9/0x30 (dup-of: 922906)" [Medium,Incomplete] https://launchpad.net/bugs/938894
<ubot2`> Launchpad bug 922906 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c" [High,Confirmed] https://launchpad.net/bugs/922906
<apw> jsalisbury, is the one which i am less sure is a duplicate of the ticket panic
<davmor2> apw: the only thing I saw from tail on syslog was reference to an fb issue and at that piont if I flick back to the install it dies,  if I stay in the tty it seems to keep working
<davmor2> apw: I'll try and get some more tomorrow for you :)
<apw> davmor2, ok that might well be the hint we need i wonder if you might be able to install openssh-server into the live environ
<apw> and login remotly before triggering the install phase, that might do it
<apw> then you might get the end of the error before the machin
<apw> dies
<davmor2> apw: yeap I'll give it a bash tomorrow
<diwic> tgardner, could you explain what you mean with "The 12.04 installer will not boot a non-PAE CPU"? I mean, my custom ISO *does* boot and install a non-pae kernel.
<tgardner> diwic, I meant that the official  ISOs won't boot a non-PAE CPU.
<diwic> tgardner, ok. Which is why I made a custom ISO.
<diwic> tgardner, btw, it was also pointed out to me that the netboot iso/installer would support non-pae kernels.
<diwic> tgardner, https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-February/013276.html
<tgardner> diwic, hmm, that goes against what we decided at the TB meeting about non-PAE support. on the other hand, I don't care that much. non-PAE is going to be dropped for 12.10
<jdstrand> jsalisbury, ogasawara: hi, fyi it doesn't seem bug 911059 is fixed after all
<ubot2`> Launchpad bug 911059 in linux "Intel wireless randomly drops connection" [High,Fix released] https://launchpad.net/bugs/911059
<jdstrand> should I file a new bug?
<sandjkirkland> apw: sorry I was on another channel. When this happens I have to hard reboot. Its so random that sometimes I go days without issues and other times its 4 or 5 times in an hour
<apw> jdstrand, i wonder if that patch is simply not enough ...
<ogasawara> jdstrand: please do.  has the situation improved with the patch?
<jdstrand> ogasawara: hard to say. I'd like to say 'maybe?' it doesn't happen super frequently-- just a few times a day
<sandjkirkland> There isn't anything particular that I do that causes it. I can be on interent or libreoffice
<tgardner> ogasawara, have you pointed jdstrand at the 3.3 compat-wireless bits ?
<ogasawara> tgardner: oh yah, no I haven't
<tgardner> ogasawara, might be a good chance for some testing on it
<ogasawara> jdstrand: we've uploaded the linux-backports-modules-3.2.0 package which contains an updated compat-wireless stack from v3.3, you might want to give that a spin
<ogasawara> jdstrand: https://launchpad.net/ubuntu/precise/+package/linux-backports-modules-cw-3.3-3.2.0-18-generic
<tgardner> jdstrand, use linux-backports-modules-cw-3.3-precise-generic
<jdstrand> ok
<jdstrand> I filed 948235 just now
<ogasawara> jono: you're the original bug reporter for bug 911059 - have you noticed any further drops since running with the applied fix?
<ubot2`> Launchpad bug 911059 in linux "Intel wireless randomly drops connection" [High,Fix released] https://launchpad.net/bugs/911059
<apw> anyone got an oneiric box, if so could they pasteme the output of: grep -r AT_EMPTY_PATH /usr/include
<jdstrand> tgardner: after installing that package, is all I have to do rmmod iwlwifi ; modprobe iwlwifi?
<tgardner> jdstrand, nah, you'd better reboot since the protocol stack modules are also different
<jdstrand> ok
<herton> apw, /usr/include/linux/fcntl.h:#define AT_EMPTY_PATH		0x1000	/* Allow empty relative pathname */
<apw> herton, thanks ...
<GrueMaster> sconklin: Ping.  I got the meter working.  On the Dove, only the processor draws from 12v, so the amp readings were very low compared to the panda, which has a single feed for everything attached (including the USB>Sata SSD).
<GrueMaster> And I have it working on the dev board I need to test, with viable results.
<sconklin> GrueMaster: ok, if it's low enough, you should switch the leads over to the 400 mA jack, if you haven't already
<sconklin> glad to hear it's working
<GrueMaster> No, on the test platform, I can peg it out at 1.5A using lamp and ab.
<GrueMaster> It is going to be near impossible to get a decent set of readings for system wide testing, but this will at least give me core readings.
<sconklin> GrueMaster: ok, good deal!
<GrueMaster> Now to start honing my python skills and write some tests.
<apw> bug 944347
<ubot2`> Launchpad bug 944347 in grub2 "linux and initrd load very slowly on UEFI system" [Critical,Confirmed] https://launchpad.net/bugs/944347
<jono> ogasawara, sorry, was on a call
<jono> nope, works perfectly - thanks!
<apw> ogasawara, (without looking at all) i wonder if that fix is iwlNNN specific in some way, and actually more of those are affected
<ogasawara> apw: I was thinking the same
<ogasawara> apw: although jdstand is using the same driver as jono
<apw> ogasawara, erp
<ogasawara> apw: but jdstand mentioned in his bug that he ran with the upstream 3.3 kernel for a day without issue
<ogasawara> apw: so lbm might be promising in his case
<tgardner> ogasawara, I have a i4965 that really began to suck from from v2.6.39-v3.2. I've been running v3.3-rc4 and up for several weeks with really good results.
<jsalisbury> jono, do you have the following options still enabled: options iwlwifi 11n_disable=1 swcrypto=1
<jono> jsalisbury, I don't think so, where would I add those?
<jsalisbury> jono, You may have created a file in /etc/modprobe.d.  In that directory, can you run:
<jsalisbury> grep 11n_disable *
<jono> jsalisbury, nothing is returned
<jsalisbury> jono, cool.  And you rebooted since adding that option manually?
<jsalisbury> jono, with insmod
<jono> jsalisbury, yep, lots of times
<jsalisbury> jono, ok, thanks.
<ohsix> herton: re: the 2.6.38-13 kernel pushed a little while ago, i haven't seen a corresponding -dbgsym package in a while, am i misunderstanding their use?
<ohsix> i think it's in -proposed, dunno if dbgsym stuff matches
<herton> ohsix, which one is missing, I see the latest ones at http://ddebs.ubuntu.com/pool/main/l/linux/
<ohsix> 2.6.38-13.57
<ohsix> -generic
<herton> it's there: http://ddebs.ubuntu.com/pool/main/l/linux/linux-image-2.6.38-13-generic-dbgsym_2.6.38-13.57_amd64.ddeb
<herton> i386 also
<ohsix> they're .56 apparently, numbers are a little out of sequence, don't know the implication
<ohsix> hmm it's not being marked for upgrade
<ohsix> ok i'll try and get to the bottom of it, something is weird for sure
<ohsix> thanks
<herton> np, it should update if you have linux-image-2.6.38-13-generic-dbgsym installed already, may be there is something else
<ohsix> i don't know why the version of dbgsym i had installed was -56, the kernel i had wasn't
<ohsix> herton: the ddebs.ubuntu server won't bluff to you if you add it as a package source and do regular updates? (about 10 times a week, updating the package sources) i still only see .56 as the only available version (this is on 10.04)
<herton> ohsix, yes, it's not taking 13.57 even if you add ddeb natty-proposed archive, I think you should open a bug about it
 * tgardner -> EOD
<ohsix> against what, i'm a bit fuzzy on what's even happening, if it's on the ddebs server it should come in an update
<herton> I think it's an archive problem
<ohsix> it's all moot, i can check and see if it unfubars itself tomorrow; not enough time to fetch it today
<ohsix> thanks again for the info
<ohsix> all that .deb just to get vmlinux; it would be a huge boon just to package it by itself, and in a place that perf can find it :] (i've been told it might have been fixed to find it in the regular debug spot on newer versions, but i haven't checked)
<ohsix> in something that's not a -dbgsym package that is, i realize they're just built with normal packages and contained all the stripped stuff; something in the main repo with a vmlinux and the modules separate
<sandjkirkland> I am having issues with my computer freezing and monitor going white with oneiric. This does is so randomly it is impossible for a newbie as myself to determine the issue.
<ohsix> intel gpu? sandybridge or ivybridge? -> gpu asplode
#ubuntu-kernel 2012-03-07
<ppisati> moin
 * smb climbs out of morning mail swamp
<smb> morning
<apw> moin ...
<diwic> apw, hey, I remember you saying your USB mic sometimes showing up as an SPDIF device, is that correct?
<diwic> apw, (as well as the ordinary device) in the new sound settings UI
<apw> diwic, i suspect you are referring to the snowball i have showing up as two items ...
<apw> typically, i am not in the same place as it today :)
<diwic> apw hrm
<diwic> apw, do you have an alsa-info around where this mic is plugged in?
 * smb reminds apw of hassle job... probably too early though. :)
<diwic> apw, ok; I'll take the headsets today and when you have it ready, file a bug using "ubuntu-bug audio" and point me to it.
<apw> diwic, sorry no, that machine is off at the mo so can't even get to it remotly
<apw> diwic, poke me in the morning if i don't get it to you
<apw> smb, poking in progress
 * ppisati -> brb
<ppisati> guys, is there a way to move an archive from one of the builders to zinc?
 * ppisati -> out for lunch
<kki313> Hi, my notebook (Thinkpad X60) wakes up from suspend2ram while I carry it around (since 11.10, now with 12.04). Its getting pretty hot in its case. Should I file a bug or is this a known bug?
<apw> kki313, so the machine definatly sleeps in the first place, and then wakes some time later?  thats unexpectd.  not heard of it, so yes file a bug
<herton> ppisati, your Ubuntu-2.6.31-612.34 tag is signed with the wrong key (old key)
<herton> smb, ping
<smb> herton, what did I wrong?
<herton> smb, no, everything is fine :), it's another thing
<smb> he ok
<smb> shoot
<herton> smb, bjf was talking yesterday to me, we will have soon to take 3.2 stable maintenance, we want to see what you're doing with 2.6.32, we could leverage your work with 3.2
<ppisati> herton: let me check
<smb> herton, Ah ok. Though there is probably not the right things there which you need. Since I basically only followed another stable tree, there was no need to monitor the stable mailing list (actually that was not even possible back then)
<smb> herton, So potentially you can re-use the scripts for the mail announcements (need to find out how tightly those are tight into the special work flow)
<herton> smb, yes, it'll be different for this case. but there are some common things, we will need a place to hold a 3.2 stable too, and a place for the announcements, perhaps do the same as you do with 2.6.32+drm
<ppisati> herton: you are right, repushed
<ppisati> herton: check it out
<herton> ppisati, cool thanks
<smb> herton, Sure, I can let you have a look at the announcment scripts. They will need some tweakign but should be somehow usable. And the tree, it could be on kernel.ubuntu.com or kernel.org. I could host it but I have no doubts that someone of you may also get an account
<tgardner> smb, herton: given that the maintenance duties will rotate, lets host it on kernel.ubuntu.com
<smb> tgardner, Makes sense and really any place that is public is as good as the other
<tgardner> in fact, it could just be a branch in the ubuntu-precise repo
<herton> tgardner, hmm, but the branch would track 3.2 pristine, not our master, correct?
<tgardner> herton, correct
<smb> tgardner, I would probably make it a separate tree just to pointout its independancy
<tgardner> smb, actually, making it a branch in ubuntu-precise is a subtle advertisement, hmm?
<smb> tgardner, Well I would rather not tread into the same tracks as some other person. :-P
<smb> herton, I copied my notify-* scripts (2) to chinstrap as examples. The notify for a release will need some work because it is trying to be smart about a drm33 part.
<tgardner> smb, we're gonna get shit whatever we do.
<tgardner> so lets do what is most convenient for us
<smb> tgardner, Sure thing. I just would like to not act in a certain way just to proof we are ... too.
<arges> sforshee, hello
<sforshee> arges, hi
<arges> sforshee, i see that you fixed something in gnome-desktop3 : [GnomeRR] - Consider Embedded Display Port outputs as the laptop's built-in display
<arges> sforshee, how did you hit that bug?
<sforshee> arges, yep, that was causing macbook airs to not suspend when the lid was closed
<sforshee> you have to have a machine that uses eDP for the internal panel
<sforshee> then you just close the lid
<arges> sforshee, ok cool. wondering if it was similar to an issue i was seeing
<arges> thanks
<sforshee> arges, eve if it isn't identical it could be similar
<arges> true
<sforshee> gnome-settings-daemon was changed to not suspend if it thinks an external display is connected when the lid is closed
<sforshee> if that same logic is failing in some other way, you'll get the same results
<arges> sforshee, i'm getting some wierd errors when Fn-F7ing on thinkpads on natty, but I know it works on oneiric. I've ruled out the kernel, so I'm thinking gnome-settings-daemon or gnome-desktop
<sforshee> Fn-F7 is the suspend hotkey?
<arges> swap displays
<sforshee> oh
<sforshee> have you tried natty kernel to see if it fixes it?
<sforshee> i really have no idea what in userspace is handling that hotkey
<arges> yea i'll figure it out. I used the same kernel on both natty/oneiric and the oneiric one passed, and the natty one failed. so i'm thinking its a userspace gnome issue
<arges> i traced through the i915.debug stuff and found that its actually trying to pass the wrong resolution, so it looks like the kernel is doing what its being told
<arges> so i was going through the gnome-desktop3 changelog and saw your name : )
<kki313> apw, ok. Do you need special logs?
<cking> pgraner, https://wiki.ubuntu.com/Kernel/PowerManagement/PowerSavingTweaks
 * ogasawara back in 20
<jMCg> http://dpaste.com/713065/
<jMCg> This is great.
<jMCg> Looks like my PCI thingy is b0rked.
<jsalisbury> herton, bjf possible lucid 2.6.32-39.86 regression: bug 949080
<ubot2`> Launchpad bug 949080 in linux "sending ioctl 1261 to a partition!" [Medium,Confirmed] https://launchpad.net/bugs/949080
<tgardner> jsalisbury, not a regression. its a known (benign) issue
<jsalisbury> tgardner, cool, thanks.
<jsalisbury> tgardner, thanks, I just found details that they are just probing ioctls.  Updated the bug.
<tgardner> jsalisbury, yeah, I get them all the time, especially on dm sets.
<tgardner> jsalisbury, why do you think bug #946134 is a kernel issue ?
<ubot2`> Launchpad bug 946134 in linux "2.20.1-1ubuntu2 : renice crashed with SIGSEGV in __libc_start_main()" [Medium,Incomplete] https://launchpad.net/bugs/946134
<jsalisbury> tgardner, I saw "Crash on cold boot" in the description.  Should it belong in util-linux?
<tgardner> jsalisbury, dpkg -S /usr/bin/renice
<tgardner> bsdutils: /usr/bin/renice
<tgardner> jsalisbury, its a segfault in an application. its not clear that it is a kernel bug, so until then....
<jsalisbury> tgardner, ahh, ok.  I'll update the package.
<tgardner> jsalisbury, you mean, update the bug with the correct package name ?
<jsalisbury> tgardner, yes
<jsalisbury> tgardner, I updated the package name in the bug.  Thanks for the info.
 * ppisati -> EOD
<tgardner> bjf, herton: I pushed a patch Monday to ubuntu-oneiric-meta that needs packaging and uploading.
<bjf> tgardner: ack
<tgardner> ogasawara, I added the same patch to ubuntu-precise-meta. OK if I just upload it ?
<ogasawara> tgardner: yep, go for it
 * tgardner -> lunch
 * tgardner -> EOD
<ohsix> herton: that package showed up as an update a few hours later, i forgot that the index for the releases/types were separate from the files themselves, any idea how often (if periodic) the Packages.gz or whatever is regenerated on ddebs? i suspect that was the only issue
<herton> ohsix, I have no Idea as well on the frequency of it, an archive admin may have the answer to it (eg. you can ask pitti on #ubuntu-devel)
<ohsix> ah ok, thanks again! :D
#ubuntu-kernel 2012-03-08
 * apw finally gets his machine updated and booted
<apw> 1 day suspended, 200M of updates, sigh
 * smb reboots to get'em active
 * smb seems to be back
<smb> Just the screen vomit between lightdm and the desktop is always making me feel a little discouraged
<apw> i don't get that i don't think
<Daviey> smb / apw: I'd really like to bounce an idea off hallyn, but he is on hols.  What do you chaps think about enabling kvm vmx nested by default?
<smb> I think its the radeon driver forgetting to clear the graphics ram before displaying it
<apw> Daviey, does it even work ?
<Daviey> apw: yeah!  But not decalred as ready as svm, which is why upstream don't have it such.
<Daviey> svm nesting is enabled OOTB
<smb> Daviey, It would be nice if thoughts of enabling things would be presented before feature freeze though
<apw> Daviey, what option is it ?
<Daviey> apw: I'm still not entirely sure TBH.. I think it's actually a userspace thing.
<apw> i don't see any options mentioning nesting anyhow, kernel side
<Daviey> I think it is enabled kernel level, but just not exposed.
<Daviey> apw: I think it's a modprobe option?
<apw> i then think, we know so little about it we cannot comment
 * smb agrees
<Daviey> $ modinfo kvm_amd | grep -i nested
<Daviey> parm:           nested:int
<Daviey> $ cat /sys/module/kvm_intel/parameters/nested
<Daviey> Y
<Daviey> Okay, thanks anyway..
<apw> Daviey, sounds like the kernel side is all there, so ... as you say sounds like a userspace side thing
<Daviey> apw: Right, it was more of a 'have you heard that doing this would be NUTS?' kinda thing. 
<smb> no, but then we usually just stick to the defaults as long as nobody asks for something specifically. and the defaults cannot be nuts otherwise they would not be defaults... :)
<apw> Daviey, heh, no i think i only heard that we now had nesting at all this week actually
<Daviey> ok, thanks :)
<smb> RAOF, Is that something that you are aware (not so clean transition between lightdm and desktop for radeon) off or think it should be addressed?
<htorque> bryceh: hi! bug 899159 - this seems to be fixed in the xorg-edgers ppa, but i'm still getting (worse) hangs, just with a different number (0x7a000002 instead of 0x7b009004, which i initial got, but later couldn't reproduce anymore).
<ubot2`> Launchpad bug 899159 in mesa "[snb-gt2] GPU lockup render.IPEHR: 0x7b009004" [High,In progress] https://launchpad.net/bugs/899159
<htorque> should i open a new bug report (upstream?)?
<cking> apw, can you forward me the canonicloud scripts you were talking about yesterday evening?
<apw> smb, you wrote maint-getabis right?  seems it is trying to get ppc64 for oneiric for hendrix
<henrix> creating the ignore file didn't work
<apw> II: linux-image-3.0.0-16-powerpc64-smp_3.0.0-16.29_ppc64.deb
<apw> II: Downloading to kernel.ubuntu.com ... FAILED!
<apw> henrix, i think you can just ignore the fact it tried and failed to do it
<apw> you cirtainly don't need any files for ppc64 as the kernel is never built there
<apw> so it cannot fail the abi checks
<henrix> oh, unless... the ignore file should be debian.master/.../powerpc/ppc64.ignore and not debian.master/.../ppc64/ignore
<apw> henrix, though i would also say that in the tip of oneiric/master-next that i have, the ABI files are already up to date too
<apw> henrix, there is no point in making any files with ppc64 in their name
<apw> th
<apw> there is no such architecture
<apw> the error about ppc64 can be ignored, as there really really never are any and cannot be 
<apw> that is not a valid ubuntu architecture at all
<henrix> apw: ok, cool. so i'll just ignore the failure and later on confirm with the guys what they usually do
<henrix> apw: thanks
<RAOF> smb: Yes, I'm aware of that; I don't think it's a kernel or X bug; I should be able to get to it tomorrow or early next week.
 * RAOF sleeps
<apw> cking, those examples will be needing updated for you, i am just retesting them now
<apw> cking, some of the command output has changed format
<apw> cking, ok branch updated with fixed offsets
<smb> apw, Yes I wrote it. Possibly it needs ppc blacklisted. It would try to get anything that control.d indicates. Which is not always true
<apw> smb, there is a config in debian.<branch>/etc/getabi as well which lists the right things to get
<smb> apw, Nowadays maybe. This was working way before
<smb> And not sure it would be true for hardy...
<smb> anyway henrix may have a look at IgnorePatterns in the source script
<henrix> i will be taking a look at it later. i added this issue to my todo list.
<henrix> for now, i just ignored the ppc64 failure so that i can go ahead with the sru
<smb> henrix, ok. basically its likely just a IgnorePatterns["oneiric"] = Â² ".*_ppc64.deb" ] 
<smb> or whatever the package file would look like
<smb> s/Â²/"/
<henrix> smb: yeah, i've seen that on the script. i'll give it a try
<smb> henrix, If you later have a line that works for you, let me know then we can commit it to the repo
<henrix> smb: sure, i'll let you know. thanks
<henrix> smb: so, there are not releases supporting pp64 atm, correct?
<henrix> smb: i mean, this arch shall be *always* ignored?
<smb> henrix, That would be the meaning. I am just not completely sure this is true for oneiric and why nobody else had the issue otherwise
<smb> I know we were talking about dropping some ppc flavour though I thought for precise
<henrix> smb: this issue has been detected before by the other guys. its just that its not sorted out yet, due to these "unknowns" about the ppc support
<henrix> smb: at least, that was my understanding
<smb> henrix, Yeah, ppc comes and goes. its confusing
<henrix> heh
<henrix> thanks for your help. i'll let you know later when i revisit this script
<apw> smb, though in this case the failures are all ppc64, which never was an arch
<smb> inux-image-3.0.0-16-powerpc64-smp_3.0.0-16.29_powerpc.deb
<smb> probably meaning ppc64 as the flavour
<smb> So maybe the logic to find the right name is broken 
<henrix> the failure is in linux-image-3.0.0-16-powerpc64-smp_3.0.0-16.29_ppc64.deb
<henrix> linux-image-3.0.0-16-powerpc64-smp_3.0.0-16.29_powerpc.deb
<henrix> is working file ^^
<henrix> s/file/fine
<smb> Hm, maybe a side effect from apw'S cleaning up the description
<henrix> description?
<smb> I could be wrong. As much as I remember I try to make sense of what the vars.* files describe
<smb> Maybe just something I did not see when the script was written
<herton> apw, smb, I think this problem on maint-startnewrelease started with commit 3784816027fe117b43042d1ac5dff20bdc3579aa on natty repository, why that ppc64 stuff was added?
<apw> herton, because there was going to be a new arch, then there wasn't
<apw> as that is not hte official configuration for getabi, noone had noticed
<smb> So ok. In that case ignoring it sounds fine to me
<apw> and it being there is safe in the archive
<smb> ba no wonder nobody speaks to me on mumble... f...
<apw> smb, ?
<herton> yes, just confirming, it was what I had got previously I think, we always ignored it
<smb> apw, It broke
<smb> Nobody *can* hear me
<apw> smb, ahh you are there but no lips indeed
<smb> *sigh*
<apw> smb, flip some things randomly bound to help
<smb> apw, Well what I was saying to myself was that ppc64 in some way as a flavour name and a potential architecture is so little chance of not being confusing.  Especially when it never comes
<tgardner> smb, i386 is to amd64 as ppc is to ppc64 ?
<smb> tgardner, Not that I would be knowledgable there. But it would be my impression
<tgardner> smb, I think the ppc64 possibility is really dead now.
<apw> indeed powerpc is 32bit userspace (but has a 64bit kernel option) ppc64 would have been a 64bit userspace
<smb> Mabye just without the need to be compatible
<herton> may be the ppc64 stuff should be removed if it will not come as a new arch on the distro, I don't know, do we know if it'll really come?
<smb> apw, Isn't that a bit different from what we thougt?
<apw> herton, it was left in cause it doesn't really do any harm 
<apw> as nothing uses it even as tehre is no architecture
<apw> and it was a pig to get working and keep up to date
<apw> but there is also no reason to have it in anything other than P currently, probabally Q
<apw> so if it causes issues ripping it out isn't a problem
<smb> herton, Similar issues existed before, for that reason the ignore lists in getabis exists.
<herton> smb, sure, no problem in using IgnorePatterns for now
<smb> Maybe this time I can even put some explanatory comment there, so I will remember in two weeks
<cking> apw,  thanks for sorting out the scripts for me
<apw> cking, np they wern't working for me anymore, and i'm going to need em once uds opens
<herton> cking, I spammed yesterday the ecryptfs bugs for verification, I think most of them or all can be put as verified already where they are patches that went to stable in other releases, but natty didn't picked up as as 2.6.38 doesn't have stable releases anymore. Just did the normal spamming just in case as it is not clear whether we should verify stable patches that ended up in other releases (well extra testing will not do any harm if there is 
<herton> time to do them...).
<herton> *ecryptfs bugs for natty
<tgardner> herton, I marked at least one of the natty ecryptfs bugs as verified
<herton> tgardner, ack
<cking> herton, I verified the other 3 this morning
<herton> cool, yes saw sru-report now and everything is ok.
<cking> I did a clean -i386 install and ran the ecryptfs (and a manual test) to verify they worked - so it was a good sanity checking exercise
 * tgardner goes offline to break his router
<smb> sounds fun
 * ogasawara back in 20
<apw> jjohansen, would the following be bad:
<apw> [   44.510396] type=1400 audit(1331219759.479:9): apparmor="DENIED" operation="create" parent=772 profile="/sbin/dhclient" pid=773 comm="dhclient3" family="inet" sock_type="dgram" protocol=17
<apw> jjohansen, might that indicate we are preventing dhcp from working ... owner of the machine is reporting that they no longer have network
<apw> ogasawara, i have an update for the hyper-v support i'd like in the next upload, when is that likely to be ?
<ogasawara> apw: was going to plan one for tomorrow
<ogasawara> apw: go ahead and shove any patches you want in to master-next
<apw> ogasawara, sounds good, will have them tested finally today and get them in
 * cking reboots his AP
<apw> ogasawara, ok tested successfully, and patches pushed
<ogasawara> apw: ack, thanks
<bryceh> htorque, yeah since that one is believed fixed, let's start a fresh bug report.  
<htorque> bryceh: should this directly go upstream?
<bryceh> htorque, yes but would be nice to also have a launchpad bug for us to track
<bryceh> htorque, so do `ubuntu-bug mesa`, attach the dmesg and i915_error_state, steps to reproduce, and so on
<bryceh> then similarly to file it upstream.
<bryceh> if that seems like too much hassle, file the LP bug and I can forward it to fdo
<htorque> bryceh: it would be great if i could create such an apitrace log file, so this could be reproduces easier (right now i trigger it with a game installed through wine :-/). you don't happen to know how i can get such a log file?
<htorque> *reproduced
<bryceh> no I haven't played with apitraces myself so far, but agree that would be helpful to have
<bryceh> htorque, I'll find out for you
<thomi> Hi - for about a week now my webcam isn't recognised in precise. It doesn't show up in /dev/video0, so I'm guessing it's a driver issue. What can I do to diagnose and debug the problem?
<bryceh> htorque, alright this seems to be the best doc on using it:  https://github.com/apitrace/apitrace/blob/master/README.markdown
<htorque> bryceh: thanks
<bryceh> htorque, so, git clone https://github.com/apitrace/apitrace.git
<htorque> yeah, i have that
<bryceh> ok, cool so looks like it's called via `apitrace trace --api API /path/to/application`
<bryceh> htorque, hope that helps, let me know how it goes
<htorque> bryceh: will try it soon, i just hope it likes wine
<htorque> bryceh: oh, i just read that it can trace but not retrace directx calls. do you think i should try it anyway?
<bryceh> oh, hrm
<bryceh> well, couldn't hurt I guess
<bryceh> htorque, hmm you know wine might have a similar trace dumping thing
<bryceh> however I know even less about wine...
 * ogasawara lunch
 * cking --> EOD
 * tgardner -> EOD
<PioneerAxon> Hey all, by unknown cause, my kernel (3.0.0-14-generic) dumped these lines into log around 700MB, until I forced shutdown..
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287437] uhci_hcd 0000:00:1d.1: setting latency timer to 64
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287460] uhci_hcd 0000:00:1d.1: PCI INT C disabled
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287583] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287589] uhci_hcd 0000:00:1d.1: setting latency timer to 64
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287612] uhci_hcd 0000:00:1d.1: PCI INT C disabled
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287739] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287745] uhci_hcd 0000:00:1d.1: setting latency timer to 64
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287768] uhci_hcd 0000:00:1d.1: PCI INT C disabled
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287894] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287900] uhci_hcd 0000:00:1d.1: setting latency timer to 64
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.287924] uhci_hcd 0000:00:1d.1: PCI INT C disabled
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.288067] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.288074] uhci_hcd 0000:00:1d.1: setting latency timer to 64
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.288098] uhci_hcd 0000:00:1d.1: PCI INT C disabled
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.288227] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.288234] uhci_hcd 0000:00:1d.1: setting latency timer to 64
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.288262] uhci_hcd 0000:00:1d.1: PCI INT C disabled
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.288401] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19
<PioneerAxon> Mar  9 02:13:48 ubuntu kernel: [55080.288408] uhci_hcd 0000:00:1d.1: setting latency timer to 64
<ohsix> you have a not so very nice usb device
<ohsix> looks like it's taking the opportunity to put something to sleep, and it's flagging
<PioneerAxon> Yeah, but I didn't plug in anything...
<PioneerAxon> suddenly, it started using max CPU,
<ohsix> lsusb shows no devices? could be a mechanical problem too, or just a bug
<PioneerAxon> no new devices on lsusb
<ohsix> any devices.
<PioneerAxon> after restart, it is working normal
<PioneerAxon> yeah, I have webcam installed on usb
<PioneerAxon> FYI, I am on laptop..
<PioneerAxon> I guess, it would be some unknown problem, because I am using this kernel from a long time without any problem..
<PioneerAxon> unknown factor*
<PioneerAxon> Anyways, Should I submit  the log??
<JanC> PioneerAxon: next time please use paste.ubuntu.com or another pastebin if you want to show something longer than 2-3 lines...  ;)
<PioneerAxon> Okay, sure... Sorry for that..
<JanC> PioneerAxon: is this a one-time issue, or something you see often?
<PioneerAxon> No, this is the first time, anything happened, which forced me to shutdown..
<PioneerAxon> JanC: I am going to remove both logs, kernel.log and syslog. As no much useful information in those file, taking 1.5 Gigs on my disk..
<JanC> PioneerAxon: not as bad as the 50+ GiB ~/.xsession-errors I had recently...  ;)
<PioneerAxon> OMG!! 50 GB!! This is insane..
<PioneerAxon> JanC: how would anyone even handle that big file?? It is too much for any editor/tool..
<JanC> eh?
<JanC> 'less' handles it fine  ;)
<ohsix> so would vim ;]
<JanC> as do grep etc.
<PioneerAxon> No, I was talking about more GUI based log viewers...
<ohsix> less useful
<JanC> it's just really weird if you suddenly get out of diskspace errors on a $HOME where you didn't save/download anything but a couple of small documents recently
<JanC> PioneerAxon: GUI-based log viewers can handle that if they are well-written...   ;)
<PioneerAxon> yeah, gnome-system-log crashed twice while opening these 700 M files... :P
#ubuntu-kernel 2012-03-09
<jjohansen> apw: problem fixed and it wasn't in the kernel
<tdmackey> I
<apw> jjohansen, excellent thanks for your help
<jjohansen> apw: np, sorry for the problems, and wasting your time
<apw> jjohansen, no need to appologise, there are always issues, and them seeing we can resolved them in a timely fashion is good
<jjohansen> yeah I suppose, still feel bad when I caused the issue, but its not the only one this cycle, /me is on a roll
<apw> heh, nothing compared to the upstream issues we have consumed
<apw> at least someone is testing and finding them before release
<jjohansen> :)
<apw> jjohansen, was it luck that it was working for everyone else ?
<jjohansen> apw: yes
<apw> jjohansen, those are the best ones to find
<jjohansen> non terminated string, so it just depended on whether the string was dumped into zeroed memory
<jjohansen> this is when the compiler was deciding what features the kernel supported
<jjohansen> the precise kernel has a new interface for that
<apw> heh, and it should have been randome for everyone probabally, and yet 100% reproducible for him and not for anyone else in the company
<jjohansen> so the old kernel path would always work, the new for most people
<apw> how wack is that
<jjohansen> very
<apw> a good find, you know it would have worked perfectly until release week otherwise
<jjohansen> hehe, yeah
 * smb cries
<apw> smb, that bad?  break your coffee maker?  run out of coffee ?
<smb> So some launcher icons having strange colours is because of my desktop background
<smb> and they change colour everytime you change your background
<apw> !?! is this a bug or a feature?
<ubot2`> apw: Error: I am only a bot, please don't think I'm intelligent :)
<smb> apparently a feature
<jjohansen> smb: oh I hate that, is it as bad as the spilled cool-aid on my desktop bug
<apw> ubot2 i didn't even consider you present
<smb> jjohansen, Heh, I am not sure I know that
<smb> and apparently working scroll wheel for your terminals is a game of luck
 * ppisati -> reboot
<jjohansen> smb: I'll see if I can't dig it up, but it was related to choosing colors based off your background
<smb> jjohansen, Ah yeah, Paolo said they do that now as a feature. Maybe I get used to it
<smb> Just that I had been wondering all the time why they changed the colors into that particular one
<smb> ok, missing scrollwheel for terminals seems to be fixed by todays updates... I had not closed the one from before
<jjohansen> yeah, some time its a real mess, /me is particularly annoyed with the alt-tab switch where I can't tell which icon is being highlighted
<smb> That one gets me a lot of times
<smb> and the inconsistency of what moves between subselections of the same app
<smb> when you drop in the by time its tab. when you get there by cursor up its cursor left/right
<smb> oh, actually that seems to have changed
<smb> now its only that going in there by cursor will give you round robin within that new selection while dropping in by time gets you out when you go past the last entry
<jjohansen> yeah, /me is going to try the compiz switch again, its working again
<apw> jjohansen, compiz switch ?
<jjohansen> apw: compiz alt-tab switchers if you use ccsm you could still use them instead of the unity one at least until a few weeks ago when they where broken by a compiz update
 * jjohansen decided to give the unity one a good run but it hasn't grown on me at all
<apw> ahh ... jjohansen before you switch away from it, it also now has different settings, like switching within apps by default and stuff on the experimental tab
<jjohansen> apw: yeah
<apw> it also has whether its limited to the same viewport or not etc as tickies
<apw> depends what your issue is of course
<apw> but i was supprised at the slew of options it had grown
<jjohansen> yep, still don't like it.  I have several gripes
<jjohansen>   Its inconsistent, some time it pulls all an apps windows forward, some times it doesn't
<jjohansen>   I can't tell which app I am switching too
<jjohansen>   I loose spatial information on the window so I can be looking at the window I want but have to try picking it out of an icon, or wait for it to give a shrunken view of the window, which I still can't distiguish between when its between 3 or 4 terminals
<jjohansen> the spatial info loss is my biggest gripe, assuming that the bugs are worked out
<jjohansen> sigh, no the compiz application switcher is still buggy
<apw> jjohansen, i do find working out which one is highlighted difficult for some reason
<jjohansen> apw: it used to be a little easier, but they changed the highlighting color and now I find it really hard
<diwic> apw, the sound card name of your snowball mic?
<apw> diwic, hi
<apw> diwic, how do i find that out
<diwic> apw, so I got upstream's blessing for my solution to blacklist USB devices which don't have digital in/out, just need the card names to put in the blacklist
<diwic> apw, pastebin /proc/asound/cards
<diwic> with the mic connected
<apw>  1 [Snowball       ]: USB-Audio - Blue Snowball
<apw>                       BLUE MICROPHONE Blue Snowball at usb-0000:00:1d.7-4.5.4, full speed
<diwic> thanks!
<apw> that is showing two entries, one is 'iec958-stereo-input' the other 'Microphone'
<apw> though for all i know it really does have stereo support
<apw> it was expensive enoug
<apw> h
<diwic> the normal "microphone" input should enable stereo recording by default.
<apw> ahh ok, then yeah i don't need two :)
<apw> why do we get two?
<apw> oh interesting they are linked, the mute on one mutes both anyhow
<diwic> the iec958 shouldn't be there.
<diwic> it's a bug.
<apw> good enough
<diwic> apw, feel free to read bug 940145 if you're interested in more details.
<ubot2`> Launchpad bug 940145 in pulseaudio "USB analog only devices sometimes show up with digital profile as well" [Undecided,In progress] https://launchpad.net/bugs/940145
 * apw prepares to shift location ...
 * ogasawara back in 20
 * apw returns
<cking> apw -> pop stack into kent
 * apw smells coffee ... yumm
<tgardner> apw, that didn't take long.
<apw> apparently 1:45 which is a lot really
<cking> apw, M25/M20 slow then?
<apw> cking, no it was a pretty steady run, no expalnation other than faffing
<apw> ogasawara, closed a couple of WIs for the hyper-v stuff ...
<ogasawara> apw: sweet, thanks
<ogasawara> apw, tgardner: will likely upload 3.2.0-18.29 later today, gcc was uploaded yesterday so am going to wait for it to finish up its builds
<apw> ogasawara, sounds good
<tgardner> ogasawara, I updated tangerine/gomeisa chroots this AM with new gcc and binutils
<ogasawara> tgardner: cool, thanks.  yah, the only build still going is powerpc
<apw> ogasawara, any idea how long it takes on powerpc normally ?
<ogasawara> apw: previous build was ~9hrs
<apw> ogasawara, so another 5 then
<apw> ogasawara, if you want me to upload it in the morning, drop me a note
<ogasawara> apw: no worries, I'm hoping it'll just be finishing up before I usually bail.  If not, I'll check it this evening and upload.
<apw> if not, you know where i am :)
<smb> apw, ... in the basement right hand side room?
<tgardner> apw, there is a hyperv patch that you should cherry-pick after David Miller's latest pull request is honored; '10) hyperv network driver uses the wrong driver name string, fix from Haiyang Zhang.'
<apw> tgardner, ack
<tgardner> apw, its real subject line is "net/hyperv: Use the built-in macro KBUILD_MODNAME for this driver"
<tgardner> apw, huh, its already committed: d31b20fcc89efa8c5d3f5ea2720e08a286b69a36
<apw> tgardner, yay thanks ... will pull it over
<apw> tgardner, that must have been recent ... as tis not in my pull from this morning
<tgardner> apw, no, I think it was in the last few minutes
<apw> tgardner, and there it is ... will get it now
<cking> yawn
<apw> tgardner, ok pushed
<tgardner> apw, ack
 * apw reboots to test a kernel
 * tgardner has an appt, back in awhile.
<akgraner> apw ping?
<apw> akgraner, hi
<akgraner> apw - guess what is happening again - I'm getting heat issues but I don't know if it's chromium or something else
<akgraner> my machine has hit 90+ C temps 5 times in less than 5 hours
<akgraner> and shuts down hard
<apw> akgraner, same old machine that did it before ?
<apw> akgraner, this issue went away for the longest time didn't it
<akgraner> different machine
<akgraner> thinkpad now
<apw> akgraner, i assume it is on precise now?
<akgraner> the dell finally died a heat ridden death
<akgraner> apw, yep upgraded today
<apw> akgraner, and it was fine on oneiric ?
<akgraner> yep
<akgraner> just started today
<apw> ok so then ... we need to get a bug filed for this
<bjf> akgraner: is this after a few suspend/resumes or from cold boot and after some time running ?
<apw> and your first debugging task is to boot back into your oneiric kernel
<akgraner> It's docked 
<apw> and confirm it is ok in that combination, if so then we need to try the kernels in between
<apw> to see where it is coming from
<akgraner> I have have dual monitors as well - so first I lose a monitor then the heat pegs then it dies
<akgraner> apw, ok - let me put it through the paces again   and see if I can reproduce on purpose
<akgraner> the drop back the oneiric kernel and go from there
<apw> akgraner, sounds good ...
<apw> akgraner, bjf had a question, which might imply he has an idea what the issue is ^^
<akgraner> thanks - just thought I'd give you a heads up
<apw> akgraner, and what thinkpad model is it
<akgraner> bjf - after it's been running - longest time was a little over an houe
<apw> akgraner, i think he is asking is it from cold boot, use, break
<apw> akgraner, or is it cold boot, s/r a few times, use, break
<akgraner> bjf T410
<akgraner> no s/r
<akgraner> happen once from cold boot, the rest of the times during use
<apw> akgraner, when you have a bug filed, get the number to jsalisbury so he can do a bisect once you confirm that O is good and P is bad with the same userspace
<bjf> akgraner: i ask because i have a x301 and after some number of suspend/resumes it seems to forget to regulate the fans
<akgraner> apw - will do
<bjf> akgraner: i can "fix" it by just rebooting or I have a small script which i can manually adjust the fans
<akgraner> bjf - ahh ok...I'll pay closer attention and verify its not the fans  if it is I'll let ya know :-)
<cking> bjf, i'm looking at thinkpad fan controls at the moment, I'm doing some precise measurements with specific loads and comparing kernels etc
<cking> bjf, can you send me that script too?
<bjf> cking, sent
<cking> ta!
<akgraner> apw - so I just killed deja dupe and that looks like it was part of the issue
<cking> bjf, so the default "auto" seems not be OK for a load of users, I'm seeing how auto performs compared to different level settings
<apw> akgraner, the machine should not overheat under load really, something is wrong
<cking> akgraner, how old is the machine? My lenovo kept on rebooting because of thermal issues because the fan outlet was full of fluff
<akgraner> cking, I know - b/c of your post that's the first thing I check now :-)
<cking> fluff 'n' fans don't mix
<cking> its tempting to set the fan level to "full-speed" and see how hot it gets
<akgraner> apw - 2 years old
<akgraner> apw - Its an arrendale chipset
<apw> heh, !quality
 * cking shudders
<akgraner> cking, I hope it's because you a cold :-)
<akgraner> ok - I'll get this filed and let you all know more soon thanks!
<akgraner> apw - if would help and save time for all of us - I can share my screen and open a term for  you to have a look
<akgraner> you'll just have to tell me what you want to see etc
<apw> akgraner, i think what needs doing is something that'll take longish testing, so it'll make more sense for you to do it
<akgraner> no worries 
<akgraner> you know I don't mind :-)
<cking> akgraner, have you got a bug number I can put some comments into for this issue?
<akgraner> I will in a minute :-)
<cking> cool
<akgraner> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/951049
<ubot2`> Launchpad bug 951049 in linux "Lenovo T410 is overheating and shutting down" [Undecided,New]
<akgraner> cking, apw- I wasn't sure what all to say  - let me know if I need to add anything else right now
<cking> I will put some comments.. /me needs to reboot first
<Sarvatt> popey: do you  have that viewsonic monitor handy, and would you be willing to try some magic to possibly fix it? :)
<cking> akgraner, I've updated the bug with something to try for the next 24 or so hours. 
<akgraner> ok will do :-) thank you!
<GrueMaster> sconklin: Got a sec?  I was thinking about our power test measurement, and looking at http://www.amazon.com/Electronic-Specialties-695P-Current-Multimeter/dp/B000I17RAM/ref=sr_1_18?ie=UTF8&qid=1331320671&sr=8-18 as a possible better solution to tapping inline.
<GrueMaster> Wanted to know your thoughts.
<sconklin> GrueMaster: my first impressions are 1) 10 mA resolution really isn't good enough. and 2) you'd have to either still get down to a single supply line or be able to clip it over all the wires for a given voltage.
<sconklin> GrueMaster: but it should just plug into what we have, and for the price, if 10 mA is good enough resolution for you it might be worth a try
<akgraner> cking, neat  - poof magic  - now I hear the fans 
<GrueMaster> Clipping over the wires is easier than splicing in between.  That was my thought at least.
<cking> akgraner, that's good - lets see if it overheats with them on full tilt
<akgraner> cking, I'll let ya know
<cking> pop the details in the bug and we can work on finding out where it's going wrong
<cking> ta!
 * cking calls it a day
<tgardner> sforshee, re: bug #950320 - you should put the workaround to enable passive DFS channels in the bug.
<ubot2`> Launchpad bug 950320 in linux "[MacBook Air 4,1] Wireless scan fails to see APs on DFS channels" [Medium,Confirmed] https://launchpad.net/bugs/950320
<sforshee> tgardner, it's there in the bug description
<tgardner> sforshee, ah, its just damn hard to see.
<sforshee> I guess I could add ***WORKAROUND*** to make it easier to find ;)
<sforshee> tgardner, I made it a little easier to find
<tgardner> sforshee, yeah, that works
<sforshee> tgardner, sounds like broadcom is going to fix that problem by adding the custom domain to brcmsmac, but I don't know when we can expect it
<tgardner> sforshee, likely 3.4 timeframe
<sforshee> if we're lucky
<sforshee> the merge window will be pretty soon now
<tgardner> sforshee, perhaps you could accelerate the process by sending a patch to Linville as a bug fix.
<tgardner> sforshee, and Cc stable
<sforshee> tgardner, a patch to do what? add the custom domain?
<sforshee> I don't think I actually know what's valid for this broadcom-custom regulatory domain
<sforshee> although likely it's the same as the world domain but with passive scanning on the DFS channels
<tgardner> sforshee, is there a domain the allows passive scanning on DFS channels ?
<sforshee> tgardner, US does for sure
<sforshee> I guess I could detect X0 and override it with US and see what they think of that
<tgardner> seems like a hack. does the X0 come from EEPROM or something ?
<sforshee> tgardner, yes, from eeprom
<sforshee> it's definitely a hack, although it sounds like they already do something similar
<tgardner> sforshee, I thought you said X0 is bogus, right? Is that what causes mac80211 to use the world domain ?
<sforshee> tgardner, yes. X0 is something broadcom made up. Since CRDA doesn't know about it it results in using the default, i.e. the world domain
<tgardner> sforshee, well then, perhaps defaulting to a US domain isn't such a hack.
<sforshee> tgardner, it's still a hack, but not an unreasonable one
<sforshee> it might not be that hard to do the custom domain though, I'll look into it
<ohsix> isn't the world one the subset of all the regulatory domains
<ohsix> it's easy, i've done it before
<sforshee> when I send the patch I suppose broadcom can correct what I get wrong
<ohsix> you add it to crda, regen; sign it yourself and it's automatically used if put in the right place
<sforshee> ohsix, yes, but we want it to work by default
<sforshee> the one the kernel uses is hard-coded in the wireless core code
<ohsix> right, so ubuntu would sign it instead of having the linux-wireless guys key on it :]
<ohsix> really? i thought that went away a long time ago, or are you referring just to the broadcom driver?
<sforshee> nope, look at net/wireless/reg.c
<sforshee> world_regdom specifically
<ohsix> hm, i see
<ohsix> oh, world is in there; the rest are in crda
<sforshee> ohsix, there's a reasonable explanation for the DFS channels being disabled by default. See http://www.spinics.net/lists/linux-wireless/msg86540.html
<ohsix> DFS is the radar thing isn't it? afaik it was almost always off; so i can't really provide any input, i thought having added my own regdom to crda was useful :]
<sforshee> yes, it's related to ceasing transmission when radar is detected on the channel
 * apw gives it up
 * tgardner is about ready to give it up
<sforshee> quitters
 * apw sends sforshee 10 machines to debug, by monday
<sforshee> apw, par for the course ;)
<apw> :)
<apw> have a good 'en
<sforshee> you too
<Sarvatt> sforshee: awesome, thanks for the workaround! was wondering why i could never get on the 5ghz band on this thing
<sforshee> Sarvatt, I just noticed it earlier this week after I set up my new router and couldn't see my 5 GHz AP
#ubuntu-kernel 2012-03-10
<Drknzz> Hi everyone. I am trying to crosscompile a kernel for my Sony Ericsson device, but i am constantly getting errors about make not finding a compiler that IS there.... Help Please?
<philipballew> Can someone tell me if a patch from this bug has made it into the current 12.04 kernel or not. I am still getting the error
<philipballew> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652
<ubot2`> Launchpad bug 872652 in linux "screensaver backlight stuck off, system looks hung" [High,Fix released]
<awe> apw, ping
<awe> vanhoof, good morning
<akgraner> apw, cking, bjf  - no issues yet since I ran that script
<akgraner> and it looks like it was deja dupe that's causing the issues, however, I don't know why as it didn't do that before.  I'll keep digging around.  just wanted to let you all know
#ubuntu-kernel 2012-03-11
<deactivated> i'm trying to debug an apparent scheduler problem with 2.6.32-33-generic. the symptoms: CFS exec_clock has stopped updating. exec_clock on CPU 0 is approx. 1000x larger than the uptime. /proc/[pid]/stat/utime has stopped updating. /proc/[pid]/sched/sum_exec_runtime is zero. has anyone seen something like this?
<bmoez_> what version of kernel will be used in ubuntu 12.04 ?
<popey> bmoez_: 3.2
<bmoez_> popey: i'm testing ubuntu 12.04 and it's with linux 3.2.0.* versions, but, linux 3.2.6 is more better (and stable) and installig it from unofficial packages may cause some problems. why it will not be used?
<bmoez_> ubuntu 12.04 is lts
<popey> We test a specific kernel version but do backport stuff from newer kernels if that's useful/appropriate
#ubuntu-kernel 2013-03-04
<honcho> I am new to kernel programming and I am working on a test project (I understand there are things that already do this)that takes receives a packet via NETFILTER down in the kernel and just drops it. What i want to do is check if the packet against a list of approved ip's and ports. From what I have been reading passing the packet up into User Mode is my only option, especial if the list is sotred in a DB. I am curious wha
<honcho> t is the best way for a pacet to be pased to a user-mode program verified then have its findings sent back to the kernel module with a yes allow the packet or no drop the packet?
<honcho> I am new to kernel programming and I am working on a test project (I understand there are things that already do this)that takes receives a packet via NETFILTER down in the kernel and just drops it.
<honcho> What i want to do is check if the packet against a list of approved ip's and ports. From what I have been reading passing the packet up into User Mode is my only option, especial if the list is sotred in a DB.
<honcho>  I am curious what is the best way for a pacet to be pased to a user-mode program verified then have its findings sent back to the kernel module with a yes allow the packet or no drop the packet?
<lifeless> honcho: openflow controller does that
<honcho> looking that up now
<honcho> thanks
<honcho> is there a way to drop packets from user mode, or does that have to happen in a kernel module?
<ppisati> moin
<infinity> smb: *nudge*
<smb> infinity, hmmmm?
<infinity> smb: Do I get a linux-ec2 upload today?
<smb> infinity, Sure, if I can get out of Brad or henrix_ how I am supposed to make SB behave
<infinity> smb: https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/1137197 is waiting patiently on you. :)
<ubot2`> Launchpad bug 1137197 in kernel-sru-workflow "linux-ec2: 2.6.32-351.62 -proposed tracker" [Medium,In progress]
<smb> infinity, The git repo is pushed since Friday at least
<infinity> smb: How is shankbot misbehaving?
<smb> infinity, By completely ignoring me... well or I don't know how to tell him
<infinity> Ignoring what?  Until it's uploaded, there's not much for it to do.
<smb> infinity, Thought the magic now is to set upload-to-ppa to confirmed
<infinity> It doesn't upload for you...
 * infinity is potentially confused by what you're driving at.
<smb> infinity, Could well be that *I* am quite confused by the last email telling me not to set the prepare-task to fixed anymore
<smb> but instead change upload-to-ppa but then it may still be someone else that would do the upload (as they did before)
<infinity> smb: You're meant to just upload stuff to the PPA, and let the bot set prepare-* to Fix Released when it sees it all done, yes.
<smb> infinity, I guess the detail here is that before henrix_ was doing the uploads, I only did the git prepare
<infinity> smb: Ahh.  Well, you could ask him nicely to do so again. :P
<infinity> smb: But I'd personally prefer it if the person prepping the git tree also checked his work by making a source package.
<smb> infinity, Have to talk to him
<infinity> smb: And once you've done that, you may as well upload it.
<smb> infinity, I would not mind either if its clear that thats is the process
<infinity> smb: Well, I'd ask bjf, but he seems to have run away from the channel.
<smb> infinity, Oh, I think he does this thing, this sleep thing you know
<infinity> smb: I don't understand.
<smb> Hm, I am awake and its morning and he lives on the other side of the continent across the ocean...
 * smb thinks there might be a lot of smileys missing
<cking> it really is awkward having to sleep, we'd be so much more productive if we weren't mortal
<ogra_> ++
<infinity> cking: I've slept about three hours since Friday.  Are you implying that I'm immortal?
<smb> infinity, henrix, ok, I uploaded something (hopefully the correct lucid ec2) ;)
<infinity> henrix: I think smb either needs a crash course in process, or you need to upload linux-ec2 for him. :)
<infinity> smb: Hah, jinx.
<cking> infinity, a implies b does not mean b implies a ;-)
 * smb wonders whether he should have taken the opportunity to silently swap the ec2 kernel by the version without the big xen-classic patch...
<infinity> smb: ?
<henrix> infinity: smb: ok, i'm looking at the logs here... is there something you would like me to do? :)
<smb> infinity, you don't wanna know. these are not the robots you are looking for...
<henrix> or that's all sorted out?
<infinity> smb: Oh, as a Xen fan, you may be happy to know that Xen on ARM is already functional for both armv7 and armv8.
<infinity> smb: And they're upstreaming it all like good little boys.
<infinity> smb: So, it might beat KVM to full paravirt on ARM.  Neener, neener to the KVM people. :P
<smb> henrix, no, think we are good. we just need to clarify wheter I should do the uploads myself in future as well
<smb> infinity, As a Xen "fan" yeah, glad they do upstream. Though as not owning more arm than I really have to I would not have any hw to run it on
<smb> :)
<henrix> henrix: ack
<henrix> grr....
<henrix> smb: ack :)
<smb> heh :D
 * henrix needs to get out of weekend timezone
<infinity> henrix: You talk to yourself on the weekends?
<henrix> infinity: i do!
<smb> henrix, Probably that was part of the last email about using /changing the status of upload-to-ppa to confirmed. But I missed the part defining who would need to do the upload. I mean I am fine with doing it. Just need to add that to my brain. :)
<smb> infinity, me to... ok, mostly because I am the only one listening
<infinity> smb: I'm not sure if anything has formally changed WRT who uploads, but I'll reiterate that I'd rather the developer who prepared the tree actually create a source packages (and, I dunno, test build it, is that asking too much? :P), at which point, why would you then have someone else do exactly the same thing again, when you could just upload it yourself?
<smb> infinity, Right, well that actually was overdone in the past as I did a test-build which henrix repeated. So it has really some advanage to do it myself. It just was different process before. Not that it cannot be changed, but we just need to agree to do it differently (and have all the same recollection of how)
<smb> henrix, uh oh... 95% of ppa space reached
<henrix> smb: infinity: i'm ok with that as well. we just need to sync with bjf i guess
<henrix> smb: that's not good. there's probably lots of stuff to be deleted. i'll take a look at that
<infinity> There doesn't seem to be much cruft in there.
<smb> henrix, yeah, unfortunately junk is not collected automatically... 
<infinity> lts-backport-natty is about the only cruft...
<smb> infinity, hm, maybe depedns on the view... though I guess *you* would see it all
<smb> Used to be all the superseded packages lingering
<infinity> superseded ones should get deleted...
<infinity> In theory.
<infinity> (But no, I can't see any special view, I can't even see the views you see, since I'm not in the team)
<infinity> Someone should add me.
<smb> infinity, practically I see 177 packages in the delete view... We probably should get you there... think Tim was admin... and Leann
<infinity> Yeah.  I'd argue that adding me would be incorrect from an org chart POV, but that's BS, cause half the people in that LP team aren't Leann's reports.
<infinity> apw: Want to add me to ~canonical-kernel-team?  Kthx. ;)
<smb> infinity, agreed... oh apw could do too
<smb> infinity, he has not yet shown up...
<infinity> smb: He's in the channel, that's shown up enough for me.
<smb> Ok, its Monday, a day before the vUDS that still does not seem to have all sessions... 
<smb> infinity, Thats bip to you
<smb> Doh... having the delete PPA button right next to the view details one isn't very helpful on Monday mornings...
<smb> henrix, just a note (though maybe you know already) when you delete superseded packages, only select about 10 or so at a time
<henrix> smb: yeah, i guess i've been there already :)
<smb> henrix, ok, yeah... guess we all have. :-P
<henrix> smb: anyway, i can't see the ppa size... "Failed to fetch repository size"
<smb> henrix, yeah, just saw the 95% mentioned in the upload email I got
<smb> times out for me too
<henrix> ah, ok
<henrix> smb: lp is unusable atm, i'm getting timeouts everytime i try to do something
<apw> infinity, i don't have any objection, i can see a couple of positive benefits given the specific relationship you have, that whole tema is a bunch of mess
<apw> infinity, so i'll discuss with leann et al about a general overhall
<apw> henrix, you have to delete a very few at a time else it barfs
<apw> henrix, i managed to delete all of natty (4) at once
<infinity> apw: Yeah, the team doesn't relate to organisational units at all, or I wouldn't have asked.
<henrix> apw: 4 at once? wow! :p
<smb> henrix, Hm, I could at least do 3...
<henrix> yeah, but i'm unable to get a list of the packages. i keep getting a timeout
<apw> infinity, 'before' it was used for status and it wasn't great to have others on there, then we added -distro and it is now that so i think it should be ok
<apw> infinity, really we should have a separate -upload or -ppa group which has the ppa on it, but we 
<apw> should have done that a long time ago ... sigh
<smb> henrix, Hm, that seems to work for me... so maybe I should go deleting
<infinity> apw: Yeah, silly status tracking is why slangasek kicked me out of canonical-foundations. :P
<henrix> smb: i'm getting the timeout when i try to apply filters
<infinity> (Which is irksome, cause that punts me from PPAs and recipes that I used to have access to)
<smb> henrix, Ok, let me go ahead
<henrix> smb: ack, thanks
<infinity> Re-using OU/status teams for anything functional is probably a mistake.
<apw> he should jsut make a -status or -i-care-about and use that
<apw> or even -reports
<apw> yeah ... concur on organisational again functional
<apw> infinity, i see the l-lowlatency ones we did via PPA made it to -proposed, seemed ok i assume
<zequence> I've yet to test boot the lowlatencies. I'll do that now
<smb> henrix, Ok, I deleted all superseded packages except one per package. Still cannot calculate the current size but deletions do take some time. 
<henrix> smb: cool, thanks. for some reason, i'm still getting timeouts when i try to filter to see superseded packages only...
<smb> henrix, Oh maybe that is the reason. I did not attempt to. But in the overview the superseded are a different shade of gray
<henrix> smb: ah, right. so you just deleted them from the original listing. ok, i'll try to remember that next time :p
<smb> henrix, Hm, since that ec2 upload was a ABI change, I also prepared the meta package... Now how do I tell that in the bug? there is only a prepare-meta task, but since I should not change the other prepare task either, I am not sure?
<henrix> smb: afaik you just need to upload the -meta package. i believe the bot will figure out that there was an ABI bump and will look for it
<smb> ok,... lets see
<lantizia> apw, don't suppose you're about?
<apw>  lantizia, hi
<lantizia> apw, hey... sorry to bother you - do you recall https://bugs.launchpad.net/ubuntu/precise/+source/linux/+bug/1105230  ?
<ubot2`> Launchpad bug 1105230 in linux "CONFIG_SOUND_OSS_CORE{,_PRECLAIM} seem to have become reenabled in 12.04 and later" [Medium,Confirmed]
<apw> lantizia, some indeed ?
<lantizia> well I'd love to test the changes but it seems every kernel i've got from kernel-ppa-pre-proposed (precise) doesn't have the fix
<lantizia> i'm guessing for precise it'll say "fix released" when it's in the main repo... but right now it says "confirmed" so does that mean someone has made the changes somewhere in a pre-release kernel for precise?
<apw> nope, that means it is believed to be an issue there
<apw> the changes were stalled because turning off CONFIG_SOUND_OSS was difficult in the odler releases
<apw> i think we were intending to just turn off _PRECLAIM and see if that was enough
<lantizia> but it's only PRECLAIM that was causing the issue
<apw> and ... that does not seem to have been done
<apw> some of that would be because we would want to see the changes bake in raring for a bit without anyone noticing, for example the ubuntu-studio folk
<apw> who care about sound a lot more than we do generally
<apw> lantizia, you are using which kernel on precise there ?
<lantizia> well preclaim doesn't add or take away any function or feature - it just reserves the space for a feature that isn't even enabled anyway
<apw> indeed, but thats the process.  i think we can call raring baked without issues by now though
<lantizia> i suppose I'm saying - there is zero chance of anyone even noticing... if they do notice, what they'll be noticing is they now *can* use oss reserved addresses where as before they couldnt - but that's surely not going to break something
<lantizia> currently i'm on 3.5.0-18-generic
<lantizia> but i'm not sure if that's from the ppa's or not now ... i'd have to check
<lantizia> might have rolled back since it didn't do anything
<apw> ok so a quantal kernel, so i'll prepare some test kernels against P and Q and get you to test them
<apw> and if that works i can get it out for review and application
<lantizia> yay :D thank you very muchly
<lantizia> apw, i'm installing 13.04 in a VM to test the lack of PRECLAIM there for now (i.e. my mission to get osspd working which needs the OSS device name space available for it to fill)
<cking> bah, where did the morning go?
<maswan> henrix: Hey, did you need more testing, and if so what kind, for 1111416 (nfs4.1)?
<henrix> maswan: no, i guess we're good with that. i'll submit a patch to fix that
<henrix> maswan: sorry, i should have done that for this cycle already but completely missed it
<maswan> henrix: excellent!
<apw> lantizia, pointers to the test kernels in your bug
<lantizia> apw, ooh thanks - I can test the precise one on my physical machine, is it ok if I test quantal on a vm?
<apw> yes
<apw> assuming it can show the issue
<lantizia> and I'm testing them for... ?  just to see if it fixes my issue (which is using OSS name space)
<apw> yes, and to see they still boot of course, but the first tells you that
<lantizia> ok :D will let you know as a reply in the bug?
<apw> lantizia, and poke me here when you've done it, else i'll forget
 * ppisati is baffled
 * ppisati disappears for ~10min
<smb> henrix, This mornings operation cleansweep finally shows results. LP will let you know the repo size again. Its down to about 33%. :)
<henrix> smb: sweet! that was a nice cleanup :)
<smb> henrix, Yep. :) We could be even more aggressive by removing _all_ superseded, but hey. ;)
<henrix> smb: heh. i guess this cleanup will allow us to survive for a while now
<rtg> @ubuntu-devel: too long, couldn't read
<ogra_> lol
<lantizia> apw, So far so good...   http://www.lantizia.me.uk/so-far-so-good.jpeg
 * ogasawara back in 20
 * rtg uploads raring -10.19 rebased on v3.8.2
<apw> rtg, sweet
<rtg> apw, drat, forgot the orig tarball
<apw> rtg, meh, we'll survive
<rtg> I'll try next time...
<apw> good to point it out tho.
 * bjf back in 20
<bjf> back
<dirtyfreebooter> bjf: thanks for your link yesterday. that was exactly what I was looking for and was able to build the proper ubuntu kernel packages (with our needed patches)
<bjf> dirtyfreebooter, np
 * ppisati -> gym
 * smb curses about the day being gone that far already
<cking> smb, yep, it's been one of those kind of days
<ogra_> must be the weather
<apw> lantizia, did those kernels solve your issue
<lantizia> apw, well they boot - not got around to testing osspd yet as having diffculties with an app that needs to run through it (old 32-bit thing) will keep you updated though
<lantizia> gotta run right now though to bbl
<arges> for uds, I take it the kernel/hardware track is merged with foundations now?
<bjf> arges, yes
<arges> bjf: thanks just making sure i'm not missing something
 * rtg -> lunch
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 12th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<Hyperiant> I found a bug with a particular integrated sound card and have a fix; where do you guys prefer I report the bug?
 * rtg -> EOD
<jsalisbury> Hyperiant, It's best to open a Launchpad bug report and attach the patch there.
#ubuntu-kernel 2013-03-05
<stgraber> sforshee, mjg59, slangasek: so you know my bricked x230, I got a replacement one last week, well... I just bricked the replacement doing the exact same thing (by accident...)
<stgraber> so I think this rules out bad system board, or I'm terribly unlicky getting two units that decide to go brick just after I do the exact same thing
<stgraber> the "reproducer" appears to be: run current raring (3.8) on UEFI, connect to the internet using a phone over bluetooth, after a while, disconnect.
<stgraber> at that point, I seem to get a oops which makes me jump out of vt7, when trying to type anything, it's followed by a panic, listing some intel stuff (I remember seeing drm_ lines in there)
<stgraber> any attempt to reboot the machine after that fails to POST
<mjg59> stgraber: Ok. The patch I sent yesterday should fix it.
<stgraber> mjg59: ok. did you manage to reproduce this at all or did you just spot something wrong and fixed it?
<mjg59> stgraber: No, I just did something based on what Samsung told us was the problem
<mjg59> Haven't had an opportunity to reproduce yet
<stgraber> ok, hopefully Lenovo won't be too annoying when I ask them to replace a second unit with the exact same deffect as the one they just replaced ;)
<stgraber> by the time I get a fixed unit, the fix should be in our kernel so hopefully that'll be the last time this happens
<stgraber> sforshee: I'd very strongly recommend cherry-picking mjg59's fix immediately! (I'm by far not the only x230 raring user, ...)
<JanC> stgraber: assuming Samsung's problem is the same as Lenovo's?   :-/
<mjg59> Assuming that
<JanC> to be honest, I was going to try to get linux to boot on my Toshiba laptop using UEFI (currently it only boots when I enable legacy BIOS mode), but I'd rather not brick it...
<infinity> stgraber: You're making me very confident in my decision to run my ThinkPad in Legacy mode.
<stgraber> infinity: :)
<lantizia> apw, updated the bug as you asked
<apw> has everyone tested the g+ hangouts recently
<smb> Obviously I did... :-P
 * henrix has never used g+ hangouts
<apw> smb, obviously you did indeed, to test myself
<apw> and very kind of you it was too
<apw> henrix, i guess if you are only watching you may not care
<apw> else get on it !
<smb> apw, or vice versa. Haven't used them for long before that
<rtg> apw, seems to work for me the few times I've used 'em. gotta close mumble first though
<smb> rtg, seemed to work even with mumble running yesterday... of course it gets a bit confusing when pressing ptt
<apw> rtg, yeah i was using both together, but pretty ppt with smb online was a bad loop
<rtg> smb, my problem is that mumble/pulse in combination with G+ consume so much CPU that the fan starts howling.
<sforshee> mjg59, I assume the patch you're referring to is "efi: be more paranoid about available space when creating variables" ?
<smb> rtg, Ah yeah... probably thats when the pictures went bad too...
<aissen> rtg: I was wondering the other day why you removed tigon and bnx2x firmware from linux-firmware, and not from linux-image instead ?
<rtg> aissen, IIRC they were kernel version specific
<aissen> rtg: but so is linux-firmware, for which you have a branch per ubuntu release.
<aissen> rtg: also, it seems that linux-firmware has the most recent version, and the kernel only has an outdated version of the firmware.
<rtg> aissen, file a bug with specifics and I'll fix it.
<aissen> rtg: I don't use this driver or hardware so I don't want to cause a regression
<aissen> it just seemed weird
<aissen> when I was comparing the list of in-kernel firmware and in linux-firmware.
<rtg> aissen, so you don't know of any specific failures ?
<aissen> not at all, otherwise I would have filled a bug :-)
<aissen> rtg: I was just trying to understand the rationale of the removal in linux-firmware 1.88.
<rtg> aissen, primarily it was to decrease the size of the package and also accomodate kernel version dependencies
<bguthro> gordon, John tried to use the XCE DL, but it doesn't have any members...so now he's waiting for everyone to show up to a meeting that nobody got an invitation for.
<bguthro> oops wrong window. Apologies
<bryce> apw, btw remember that drm race bug from back when?  (bug #982889) I finally got to patching the xserver to check for EAGAIN, but actually it appears the kernel is giving us EACCES, and while sleeping for a bit does eventually get us working drm, we never get anything except EACCES from the kernel.
<ubot2`> Launchpad bug 982889 in xorg-server (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Critical,In progress] https://launchpad.net/bugs/982889
<bryce> apw, I'm going to ship my xserver patch as a "fix" but I think I'm just papering over breakage somewhere lower down.
<apw> bryce, that sucks bad things
<apw> bryce, but it also sounds sensible, sadly
<bryce> apw, so you might put that bug somewhere on your todo list to look at if you have time.  Seems the bug is cropping up more frequently now that SSDs are getting more pervasive.
 * rtg -> lunch
<sbeattie> bjf: FYI, I get an instant oops when schrooting with an overlayfs with the 3.5.0-26.40 kernel in quantal-proposed (bug 1147678)
<ubot2`> Launchpad bug 1147678 in linux (Ubuntu) "kernel 3.5.0-26.40-generic oops immediately when doing schroot w/overlayfs" [Undecided,New] https://launchpad.net/bugs/1147678
<bjf> sbeattie, ugh
<rtg> bjf, apw has a test suite for that IIRC
<bjf> rtg, ack
 * bjf wonders why he's not running it as part of the kernel tests
 * rtg wonders the same thing
<rtg> I'm pretty sure you can do a reasonable loopback test
<bjf> jsalisbury, ^ hotlist please
 * rtg -> EOD
<jsalisbury> bjf ack
#ubuntu-kernel 2013-03-06
<lantizia> apw, did you get my pm the other day (updated the bug too)
<apw> lantizia, oss bug ?  if so the patches went out today for review
<lantizia> oh cool you did get my message then :D
<apw> not any pm, but i saw an email
<lantizia> all it said was (sent a few hours before that email)... "Off to bed (as I'm sure you already are) - finally got back and home and finished testing... I'm basically reporting that it works very well indeed now using the osspd package from raring on precise and quantal"
<trailblazerz11> What's up with 3.9-rc1 mainline build?
<apw> trailblazerz11, what is wrong with it from your point of view
<apw> trailblazerz11, a more useful question would have been. "Does anyone know why the mainline build for 3.9-rc1 has no binary packages?"
<apw> which would have triggered my memory of cking asking me to add bc into the chroots for builds to allow 3.9-rc1 to build for him
<trailblazerz11> sorry, thanks for the reply
<rtg_> apw, whats up with the repeated mainline build emails ? 'Mainline Build v3.9-rc1'
<smb> rtg_, I suppose outfall of attempts to fix the new dependency on bc
<rtg_> smb, indeed, guess I'd better get that in the control file
<smb> rtg_, hm, yeah, would not completely rule out apw working on that too...
<apw> rtg_, i already added it
<apw> rtg_, yes it is about doing the builds till they work, which i think this final time they will
<apw> (it == build-dep: bc)
<rtg_> apw, just saw that. guess I'd better get that package added to the chroots
<apw> rtg_, yeah i've been putting that off, can you add them to precise as well as we build test kernels in the 'previous lts'
<apw> s/them/bc
<rtg_> apw, ack. I'll prolly just do it in general
<zyga> hey everyone, I seem to have found a regression in the kernel
<zyga> 3.8.0-5 works
<zyga> beyond that I get hangs on boot
<zyga> and unable to mount /sys/firmware/efivars
<zyga> I'm checking which of the three kernels that I have actually boots
<zyga> -10 does not boot to desktop
<zyga> nor does -11
<zyga> how should I proceed / file a bug?
<zyga> I seem to be able to boot into the recovery mode
<zyga> the actual filesystem that fails to mount is "/sys/firmware/efi/efivars"
<zyga> booting hangs on [S]kip or [M]anual
<zyga> so known good is 3.8.0-5, known bad is -10
<zyga> with equally bad -11
 * zyga waits around for someone to show up
<smb> and pressing "s" probably continues the boot...
<zyga> smb: yes
<smb> but yeah, filing a bug would be appreciated
<zyga> smb: but it does not finish normally, other errors show up and all I get is console in vt1
<zyga> smb: note: that's from _recovery_ boot
<zyga> normal boot just hangs
<zyga> smb: ubuntu-bug linux-image
<smb> zyga, just ubuntu-bug linux
<zyga> k
<zyga> on -5 now, apport found some bugs, let's see if that's it
<smb> wondering whether normal boots would continue by pressing s and just not show the message
<zyga> smb: ubuntu-bug does not work, claims that -5 is not an official package
<zyga> (bogus obviously)
<smb> zyga, think it does that if its not the latest one
<zyga> smb: I have the latest one installed
<smb> which probably only boots in recovery... if I ccould remember, there is a way to only save the report files...
<zyga> smb: but the error message is bogus, this _is_ an official package, I _have_ installed it, unless it's checking the one I'm running now
<zyga> smb: let me see if -11 works with recovery (I tried -10)
<zyga> ok, on -11, reporting the bug in text mode
<smb> zyga, think "ubuntu-bug --save=file linux" should allow to write the data to file
<zyga> oh, wireless crashed the kernel while I was doing that
<zyga> or just semi-crashed, the report is still going 
<zyga> that's one crappy day for having UDS sessions
<zyga> I keep getting screen full of kernel backtraces 
<zyga> I keep seeing dots printed, is that still apport?
<smb> zyga, usually the common rule is not to rely on the latest release (or update) while something important (conference, travel) goes on. But I know that is not very helpful
<zyga> smb: it's not that bad, I have a desktop that I'm using now but it's distracting from the sessions
<zyga> (20 minutes left)
<smb> zyga, might be... not sure there. If submitting the report directly is too problematic, try the --save and then I think apport-cli to upload the saved file
<zyga> smb: I suspended ubuntu-bug
<zyga> smb: then did ps aux
<zyga> and that hanged?
<zyga> I keep getting kernel backtraces everywhere
<smb> certainly not a very good state
<smb> what kind of hw is that?
<smb> (just wondering since it looks somewhat related to uefi changes)
<zyga> smb: core i7 (latest one, I guess that's ivy bridge)
<zyga> smb: broadcom wireless crap (wl), atheros ethernet (alx) 
<zyga> smb: the build is from lenovo, similar to ideapad but more 'value' market
<smb> zyga, not any samsung by chance... well iirc some people had fun with lenovo too
<smb> ok
<zyga> hehe, no :)
<smb> cking, do you remember... I thought someone had efi pain with some x something... 
<zyga> (it's running efi + signed kernel)
<zyga> ubuntu-bug keeps printing dots
<cking> smb, I'm trying to recall, but I can't think of it at the mo
<zyga> I can suspend that and poke around in /sys/ if you want
<smb> well if its done in a seperate thread it can do that for a while... 
<smb> zyga, Right now I could not say what to look for. 
<zyga> ok
<zyga> I'll let it finish
<zyga> and get ready for the first session
<smb> afaik none of the team was having similar issues... except ... cking I think your sdp completely imploded for other reasons
<cking> smb, yep, it lost it's mind and disabled auto CSM for some reason
<smb> zyga, as said I would not be sure whether printing the dots is done while waiting for a background process. If those are seperate thread and the other one hangs, there could be a lot of dots,,,
<cking> is that a bug in ubuntu-bug that needs reporting against ubuntu-bug?
<smb> cking, I'd rather not... the world may recurse for eternity
<cking> -ETOOMANYLEVELSOFINDIRECTION
<diwic> -ETOOMANYWORDSMAKESITHARDTOREAD
<diwic> although CamelCase doesn't look unix enough
<zyga> heh
<zyga> yeah
<zyga> I think it's dead jim
<brendand> bjf, is the proposed kernel cadence going to be discussed in the rolling release session coming up?
<bjf> brendand, which cadence are you  referring to? the sru cadence (not changing) or the daily, rolling cadence?
<brendand> bjf - well, maybe i should ask this in the session, but e.g. will raring be included in the -proposed cadence after it's released?
<geofft> Moving here from the room channel: would a "return true" autopkgtest in OpenAFS be reasonable, just to check compilability? 
<geofft> Will it get run against the PPA, and is there a way to sign up for notifications of test failures? 
<bjf> geofft, i think you are asking how to get a test integrated into the testing for the OpenAFS package. I think you'd want to discuss that with the maintainer.
<geofft> I think my question is more "how does that test run against the PPA kernel before it gets pushed to production" 
<geofft> (I'm talking with the folks who did the most recent OpenAFS SRU) 
<apw> geofft, i don't think we know how the autopackage tests integrate well enough to answer that.  pitti likely would knowb
 * rtg_ -> early lunch
<apw> geofft, i also query your 'compilability' is the only thing we care about, if you don't care if it works why install it at all
<geofft> apw: What I mean is that in the last like 5-6 years I've been using OpenAFS, I've never seen it build and not work right 
<geofft> apw: but it seems like half of all new kernel updates make it not build 
<apw> geofft, indeed, but the logical thing is to be aware of when it changes and to test it at those times
<geofft> apw: OpenAFS itself doesn't change. It's the lack of stable kernel API that breaks it 
<geofft> (It's GPL-incompatible free software, the situation sucks all around) 
<apw> geofft, right the kernle doesn't offer one of those, never has
<geofft> yeah 
<geofft> apw: I'm not asking for the kernel to start offering one 
<geofft> apw: I'm just saying, based on experience, new kernel minor versions have a good chance of breaking it in a way that it just won't compile 
<geofft> and approximately no chance of breaking it in a way that it compiles but doesn't run. 
<geofft> apw: I'm happy to write a more serious test that loads the module in a VM, but I don't think it'd be worth the overhead -- it wouldn't find anything 
<apw> geofft, if you had one of those you could run it against the kernels automatically as they appear in the PPA
<apw> and be apprised if there were issues
<geofft> sure, I can happily set up a local VM or something to do this. 
<geofft> I guess I'm just wondering if there's a way to do this on Ubuntu-run infrastructure, instead of a desktop in my living room 
<geofft> or adding more load to my organization's buildserver, or whatnot 
<geofft> it seems like the right place to do this test is with autopkgtest infrastructure, since it exists. 
<geofft> so the question is where to hook in infrastructure so we can say "hey hold up, we need another ./configure check in OpenAFS to handle this kernel API change" before you guys push a new kernel to rolling 
<apw> geofft, well if it was approved to hold the kernle for that that the britney runs would nominally hold it in -proposed
<apw> i am unsure that britney yet holds for autotest failures, but that is the plan
<apw> geofft, though if someone was activly maintaining openafs against the unstable kernel PPA we should never hit this issue
<apw> geofft, as although it seems good to add lots of infrastructe for these things, simply being informed there are new kernels and testing with them in advance is probabally a lot less work, especially as you already indicated it will fail half the time
<apw> as the time we want to find out this is going to fail is not when we shove a kernel into -proposed then be slaves to when someone fixes openafs, we want to know it is going to fail during the early -rcs and have it fixed by the itme we shove it in -proposed
<geofft> apw: Yeah, testing against earlier RCs is the right answer, and much of the time upstream is on the ball about adapting to the API change in master 
<geofft> Most of the time of that, upstream remembers to backport those to stable; most of the time of _that_, the stable fix goes into Debian 
<geofft> But occasionally things fall through the cracks. 
<apw> geofft, our current minimal process is to announce kernels on kernel-team@ and to tell specific individuals with key requirements, currently the binary video drivers and the server folk who have a few
<apw> geofft, with any new kerenl being in a test PPA it is trivial to make your own PPA for testing which depnds on our kernel PPA leading you to be testing against the said kernel
<geofft> sure 
<apw> geofft, though you need a VM or similar to install the kernel for dkms packages annoyingly
<geofft> there is packaging for building a module-assistant kernel, so maybe that can be abused to do a PPA test compile. 
<apw> something which did that on a regular (weekly perhaps) and reported back would be pretty easy to put together i recon
<geofft> Can I set up a PPA that will automatically rebuild when the kernel PPA gets changed? 
<apw> geofft, for dkms that doesn't help cause building the package does not trigger dkms to run
<apw> acdtually you just want a machine which has the kernle ppa attached and then just updates regularly
<apw> if the update fails that is likely cause of openafs failing to build
<geofft> yeah... is that what other people who care about DKMS do? I guess that's fine. 
<apw> i am unsure if they do it automatically, but that is the process in large part
<smaresca> in the linux-image-3.2.0-* debs from http://ddebs.ubuntu.com, I've noticed that 'struct slab' seems to be missing from debug type data
<smaresca> I was under the impression that even SLUB uses slab structs, so I was really confused that this was the case
<smaresca> is that an expected omission?
 * ppisati -> real life
 * rtg_ -> EOD
<apw> smaresca, it is not clear that it does use it
<smaresca> apw, i agree..I've been trying to find some sort of confirmation one way or the other
<apw> check include/linux/mm_types.h
<apw> there is shows the slub info overlaying the slab_page pointer, the slab * type pointer
<apw> you don't use both at once
<smaresca> apw, so even though a lot of SLUB code references slabs, it's more a question of overlapping terminology, and i've gotten myself confused unnecessarily?
<apw> smaresca, right they are 'slabs' in the sense they are typed memory pools
<apw> smaresca, they are not slabs as in controlled by struct slab.  they do i believe have a slab_info associated with them
<smaresca> apw, thanks for clearing that up for me
<BarkingFish> Hello guys :)  I know it's a pain, but I don't suppose any of you would happen to have the main files for kernel 3.8.0-2-generic floating around at all, please?  I've been given source to compile it myself, but my system doesn't seem to like that - next option is to search for someone with the headers, image-extra, and the image & -generic files please :)
<BarkingFish> sorry for disappearing, had a system restart to put through
<Sarvatt> BarkingFish: on https://launchpad.net/ubuntu/+source/linux you can click view full publishing history up top, scroll down to the version you want https://launchpad.net/ubuntu/raring/+source/linux/3.8.0-2.6 then click on the architecture under Builds to get the debs
<Sarvatt> the main headers package (not generic) is built on i386 for everything though so will need to get it from there if you're on amd64
#ubuntu-kernel 2013-03-07
<ppisati> moin
<apw> moin
<apw> ppisati, you are keen today
<ppisati> it's the weather
<smb> or insomnia
<ppisati> brb
<tseliot> apw: any progress on the "kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" issue?
<apw> tseliot, you'll have to remind me, vUDS seems to have flushed my memory
<tseliot> apw: bug #1073062
<ubot2`> Launchpad bug 1073062 in kmod (Ubuntu) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Undecided,Confirmed] https://launchpad.net/bugs/1073062
<tseliot> apw: modprobe fails when using something like ""alias nouveau off"
<apw> tseliot, oh yeah, hmmm i had a patch for that somewhere ... once i have unbroke'd this overlayfs issue i'll have another look
<tseliot> apw: thanks. Also, you want to send me the patch I can play with it here
<apw> tseliot, yeah i need to go find out what i did with it
<tseliot> ok
 * ppisati -> out for lunch
<xnox> I am removing old kernels, and os-prober is run many many many times. and it takes ages, because of all of my lvm snapshots =(
<smb> xnox, GRUB_DISABLE_OS_PROBER or so
<xnox> thanks.
<brendand> bjf - hi
<brendand> bjf - do you think it will be a problem if we run cert testing for the 3.5 kernel using 12.04.2 userspace instead of 12.10 userspace?
<brendand> henrix, ^?
<henrix> brendand: i can not antecipate any issue with that, as long as the kernel is the actually 3.5 Q kernel, compiled with the Q toolchain, etc
<henrix> brendand: but i don't see why we should do that as well...
<brendand> henrix, well it would be the one that is going to precise-proposed
<brendand> henrix, but the 3.5 kernel
<henrix> brendand: again, i am not aware of any issues but you may find them :)
<henrix> brendand: any user-space tools you use to access kernel interfaces in you tests may fail, etc
<brendand> henrix, what i mean is that you have e.g. this tracking bug: http://launchpad.net/bugs/1133429
<ubot2`> Launchpad bug 1133429 in kernel-sru-workflow/verification-testing "linux: 3.5.0-26.40 -proposed tracker" [Medium,In progress]
<brendand> henrix, if our certification tests were to involve installing 12.04.2 on systems, enabling proposed, dist-upgrading and running our tests, then that would be fine?
<henrix> brendand: i'm reluctant to say yes :)
<henrix> brendand: you would be certifying something different, right?
<henrix> brendand: do you have strong reasons for not installing 12.10?
<brendand> henrix, putting it the other way around, if we tested quantal would that be enough to say the same kernel will work fine on 12.04.2?
<brendand> henrix, otherwise we need to test a set of systems with quantal and a seperate set with 12.04.2
<henrix> brendand: correct. and i believe you need to do that -- for example, the kernel for 12.04.2 will be compiled with a differenc gcc version. and this may break something
<rtg_> brendand, the foundation layer components are different. I'm not sure you could say with 100% certainty that the kernel in Quantal behaves the same as the one in 12.04.2
<apw> ppisati, in our -omap kernel have you tested usb on more than one platform ?
<apw> ppisati, i hear rumours that usb only works "on one selected platform at once" in 3.8
<rtg_> sconklin, did you get around to sending your serial patch upstream ?
<brendand> henrix, rtg_ - one more thing. did i hear in the session yesterday that you plan to automatically roll people forward who start on 12.04.2?
<brendand> henrix, rtg_ - so they will go from 3.5 to 3.8 automatically
<brendand> henrix, rtg_ - and then on to the 12.04.04 kernel as appropriate
<rtg_> brendand, no, I think they will roll forward to the 14.04 kernel if they dist-upgrade
<brendand> rtg_, so there will be 3 or 4 different kernels that are supported in precise?
<rtg_> brendand, dunno yet. so far just the 2. it depends on if we actually release a 12.04.3 (which is not a given at this point)
<ppisati> apw: in 3.8, on some arm platform, different usb drivers cannot coexist
<ppisati> apw: but it's not our case
<ppisati> apw: tested it on omap and imx (at least)
<brendand> rtg_, hey what? 
<brendand> rtg_, you mean a different kernel for 12.04.3, or 12.04.3 at all?
<rtg_> brendand, yes to both
<infinity> ppisati: And highbank and armada? :P
<ppisati> infinity: we don't suport armada and highbank from the same kernel
<ppisati> infinity: at least not yet
<infinity> ppisati: But we should.
<ppisati> infinity: uh?
<ppisati> infinity: i'm integrating highbank now
<ppisati> infinity: but i've no plan for armada
<ppisati> infinity: shall we?
<rtg_> ppisati, in what kernel are you integrating highbank ? I thought we were done with them.
<infinity> ppisati: Well, it's probably fundamentally broken in 3.8, but we should do for 3.9 and beyond (though, it will likely require those USB patches that missed the 3.9 merge window due to being crack)
<ppisati> infinity: yeah, i know
<infinity> rtg_: I thought the concensus a few months ago was to integrate every useful platform that can be done in a generic zImage.  Have we now decided against turning on CONFIG options we don't like?
<ppisati> infinity: saw the patches, but so far we are still in 3.8 for R
<infinity> ppisati: *nod*
<rtg_> infinity, I was referring to a having a separate flavour for highbank. if the device tree based kernel woks for them, then fine.
<infinity> rtg_: Yeah, that's what Paolo was referring to with "integrating", I believe.
<ppisati> infinity: nope
<infinity> rtg_: Separate flavours are a no-go.  If the single zImage no work, we get highbank support when it does.
<ppisati> infinity: for me arm multiplatform is R/master
<infinity> ppisati: Pronoun fail.  When I said "that's what Paolo was..", my "that" meant multiplatform, not distinct flavours. :)
 * ppisati fails
<infinity> rtg_: Given that Rob is one of the most active DT and multiplatform committers upstream, if highbank doesn't work, it'll be both annoying and mildly amusing.
 * ogasawara back in 20
<sforshee> apw, you around?
<apw> sforshee, yep, hi
<sforshee> apw, so debian.master/config/annotations, is that used for generating the config review pages?
<apw> sforshee, yes that is the master list indeed
<sforshee> apw, I'm going to set CONFIG_PSTORE=n for i386 and amd64 for now, but in annotations there's a line saying it should be y
<sforshee> so I'd need to change it to p, and do one of these policy<...> things?
<apw> sforshee, or if it is dangerous, make it n regardless across the board
<apw> but yeah if its just x86 then    p policy<(arch amd64 i386 &/ value n) | value y>
<sforshee> apw, there's a ram backend that might be useful for arm. I want to turn it off of for x86 until it all bakes for a while and we're confident we won't brick any machines.
<apw> sforshee, sounds appropriate to me
<sforshee> apw, does this look right then?
<sforshee> CONFIG_PSTORE					p policy<(arch i386 amd64 &/ value n) | value y> note<Turn off on x86 until efivars is known not to brick machines>
<apw> yes
<sforshee> cool, thanks!
<apw> the / is a cut, so it says if we pass this do not recurse back to try other options; preventing the value y matching on i386/amd64
<sforshee> okay, got it
<apw> iirc you could write it as (arch i386 amd64 & /value n) | value y
<apw> if that was clearer to your mind
<rtg_> sforshee, gotta turn off ACPI_APEI as well since it selects PSTORE
<sforshee> rtg_, hmm. I'll have to check then if we want that for other reasons.
<rtg_> sforshee, I dumped this into raring: 'UBUNTU: [Config] CONFIG_PSTORE=n for x86' as well as reverted the 2 efivarfs patches.
<sforshee> rtg_, ack
<sforshee> hopefully that will keep stgraber from bricking his machine when he gets it fixed again :-)
<rtg_> indeed
<stgraber> yay!
<stgraber> I certainly wouldn't like to have to explain to Lenovo how I managed to brick a third machine ;) I already have a feeling it'll take some arguing to get the second one replaced...
<sforshee> stgraber, I wonder if there's some way to convince them to send the bricked one to their firmware engineers for diagnosis
<stgraber> sforshee: well, last time I didn't even get to talk to anyone on their side... I think we'd have more luck contacting their firmware people through the OEM contact at Canonical.
<sforshee> maybe that's worth a try
<user99999> hello
<user99999> how to change mouse dpi?
<bjf> brendand, i believe you need to test Q with Q userspace, P with P userspace (12.04) and LTS-Q with P userspace (12.04.02). i don't think we want to cheet at then find out we shouldn't have done that
<apw> user99999, i would think you would get a more inforned response on #ubuntu-kernel
<apw> user99999, i would think you would get a more inforned response on #ubuntu-x
<user99999> apw, #ubuntu-hu & #ubuntu not help ..
<apw> user99999, #ubuntu-x is the people who know most about graphical things, i would expect speed of mouse against the desktop to be something they would know how to change if it is indeed changable
<user99999> heavy the English .. :)
<user99999> I am Hungarian
<apw> user99999, #ubuntu-x may help ..
<user99999> apw, #ubuntu-hu beginner team ..
<apw> user99999, #ubuntu-x is a real channel name, really -x is the X team
<user99999> I see :)
<user99999> ty
 * ppisati goes out for a bit
<user99999> bb ppisati 
<user99999> apw, do you develop the kernel?
<apw> user99999, we do some yes
<user99999> apw, grt, linux kernel is best! :D
<user99999> X team sleep :D
<user99999> apw: please, you give me printscreen  your desktop
<BarkingFish> Good evening guys - I asked here last night if anyone happened to have a copy of the installation files for kernel 3.8.0-2-generic hanging around at all?  I need to install it and it appears to have been deleted from all repositories.  I'm testing for a problem with the ar5523 wifi driver, which became available in 3.8.0-2-generic, and stopped working on 3.8.0-3-generic :)
<BarkingFish> any help would be very welcome.
<adam_g> BarkingFish, http://launchpadlibrarian.net/129499992/linux-image-3.8.0-2-generic_3.8.0-2.6_amd64.deb ? linked to from https://launchpad.net/ubuntu/raring/amd64/linux-image-3.8.0-2-generic/3.8.0-2.6
<BarkingFish> the heck?  Bjsnijder sent me to launchpad last night, and it'd been deleted :)
<BarkingFish> Nice! Thank you, adam_g 
<BarkingFish> adam_g, i've got three of the files - the image-generic, image-extra and the generic headers, i forget what the fourth file i need is :)
<BarkingFish>  gotta reboot to go install some fixes to my system. back in a tick :)
#ubuntu-kernel 2013-03-08
<ppisati> moin
<apw> moin
<smb> morning
<cking> mornin
<cking> nggg, mumble fail
<diwic> I'm trying to run fdr editconfigs on gomeisa, but it fails due to a missing ncurses-devel package; what should I do instead?
<smb> diwic, You run that in a chroot?
<diwic> smb, no, hmm, maybe I should?
<smb> diwic, more likely you will have ncurses in there
<apw> diwic, and if we don't have it let me know
<diwic> apw, it worked in the precise-amd64 chroot, thansk
<apw> diwic, great
<ogra_> ppisati, did you see my PM last night ?
<xnox> Hello all =) is it just me or there is no: overlayfs, aufs, unionfs on the linux-nexus7 kernels ?! Can we enable them please =)))))
<ogra_> heh, fun
 * apw has a bad kernel panopoly day
<tseliot> apw: can you help with a little read-writer locks doubt, please?
<tseliot> *reader-writer
<tseliot> apw: I'm trying to replace rcu_read_lock/unlock with read_lock/unlock since the rcu calls are GPL_ONLY
<tseliot> apw: so, I was wondering if something like this could work (I don't have the hardware to test it): http://paste.ubuntu.com/5595857/
<apw> tseliot, i am unsure if you need the rmb as as the read_lock is a full barrier i believe
<apw> tseliot, but it seems workable in concept.  performance may suck of course
<apw> tseliot, of course ... i should say ... you need to make the current write side locking also take this new lock in write mode
<apw> else you have no locking at all :)
<apw> this wholel _GPL thing is a daft fabrication
<bjf> apw, overlayfs patch for quantal?
<apw> bjf, yes sitting here waiting to send ... doh
<apw> i am all out of sync following the 10 crashes i have had this morning
 * ppisati is updating his laptop to R: Goodbye Cruel World!
<apw> ppisati, did not work out well for me
 * apw runs a Q kernel on it
<ppisati> DOH
<apw> its that bad
<apw> (for me)
<ppisati> just started the do-release-upgrade thing
<ppisati> ok, i'll use a Q kernel on it
<apw> good luck with that, i have a gm45 and it is fucked
<tseliot> apw: I don't think there's any write_lock in the code. I had to introduce rcu_read_lock() (following the example of some open drivers) because upstream broke the API. I'm wondering how it may impact performance in the broadcom wireless driver...
<tseliot> s/impact/affect/
<apw> then who are you locking against if there is no other rcu in the thing
<apw> is it in the driver model somewhere, if so it might work sort of
<apw> but ... hmmm is all i can say
<tseliot> apw: so, this is my original patch for linux 3.8: http://paste.ubuntu.com/5596010/
<apw> well then you must be interlocking with something else in the core which is handling the write locking
<apw> essentially you are in a hole with no spade at this point as you should be using the same locking as they are, else you are wasting your time
<apw> but you can't because it is not exported.
<apw> you locking there i don't think does anything 
<apw> if it is not interlocked with the other side
 * henrix -> late lunch
<tseliot> apw: hmm... I see what you mean
<apw> tseliot, as long as you have the rcu_dereference, you can probabally get away with it int he common case, because read_lock_rcu is a bit of a noop in a lot of cases
<apw> (when preempt is off)
<apw> but if they are exporting the 80211 interfaces for use by non-gpl code, but those rely on GPL only locking ... it isn't really exporte
<tseliot> apw: are you suggesting that I get rid of the lock/unlock and that I simply use my local equivalent for rcu_dereference?
<apw> i am suggesting that to do that would be utterly wrong for so many reasons, but it might just about work
<apw> tseliot, what is not exported that you need
<tseliot> apw: I guess rcu_dereference is not GPL only, maybe only rcu_read_unlock and rcu_read_lock are
<apw> tseliot, they only are in some versions of rcu i think
<apw> only GPL only i think if we are using CONFIG_PREEMPT_RCU
<apw> debian.master/config/i386/config.common.i386:# CONFIG_PREEMPT_RCU is not set
<apw> debian.master/config/amd64/config.common.amd64:# CONFIG_PREEMPT_RCU is not set
<apw> which it isn't on our default kernels
<tseliot> apw: right now my original patch doesn't fail in Ubuntu but some developers on Arch Linux and another distro I can't recall are complaining about the GPL only issue
<tseliot> that would explain it
<apw> ahh then that makes sense
<apw> i think overall there is an issue with a core primative like rcu being gpl only
<apw> it really doesn't make sense in a fair world
 * tseliot nods
<tseliot> apw: but how can it be that they're exported as GPL only if that config is enabled?
<apw> becasue it is only __rcu_read_lock which is GPL only exported, and there are two version
<apw> one version for PREMPT on and one for PREMEPT off
<apw> the one for PREEMPT off is an inline with nothing much in it and is not exported at all
<apw> and therefore has no way to limit it
<tseliot> aah, I see now
<apw> the stupidity is you can (as far as i can see) take the code out of the middle of the function and inline it
<apw> into the code you have which is GPL (gpl with gpl is ok) and then use it from your proprietry code
<apw> as you are effectivly doing with rcu_dereference
<tseliot> right
<apw> it is also not clear it is not possible to randomly patch the kernel
<apw> to add a local_rcu_lock() function which is exported non-gpl which literally does rcu_lock_ ... its a farse
<tseliot> heh
<tseliot> do we have a kernel flavour with CONFIG_PREEMPT_RCU enabled?
<tseliot> or shall I just forget about it?
<apw> not that this driver would talk to as far as i know
<apw> i'll ask about it as well
<ppisati> back in 20
<tseliot> apw: otherwise I'll just copy & paste the code if CONFIG_PREEMPT_RCU is defined
<apw> its hard to see how that is illegal dispite it being utterly not what they want :)
<tseliot> :D
<tseliot> it makes me wanna do it just because of that ;)
<apw> tseliot, something to find and extract the code you need from the kernel source :)
<tseliot> :)
<ogra_> xnox, ppisati might be intrested in getting aufs/overlayfs into the nx7 kernel  :)
<xnox> ogra_: i just want sensible sbuild ;-)
<ogra_> well, the android source we have doesnt include either, needs porting work first 
<ogra_> and if we possibly play with overlays for the upgrade procedure, it will be needed i guess
<xnox> ogra_: how hard can it be? I thought android kernel doesn't care much about fs stack (as in doing / changing it extensively)
<ogra_> not sure what stgraber's exact plans are but it would definitely be helpful to have it for different test scenarios
<stgraber> so far I'm avoiding the use of an actual overlay filesystem because we can't be sure we'll have one in the kernel, but I certainly wouldn't mind having one ;)
<ppisati> xnox: open a lp bug please
<ppisati> xnox: i'm rushing out now
<xnox> psivaa: ok.
<psivaa> ppisati: ^ :)
<xnox> psivaa: sorry.
<xnox> ppisati: ack. it will be bug 1076317
<ubot2`> Launchpad bug 1076317 in ubuntu-nexus7 "please add aufs/overlayfs/unionfs support to android based kernels" [High,Confirmed] https://launchpad.net/bugs/1076317
<psivaa> xnox: np
<ppisati> xnox: nice
 * ppisati rushes out for some early workout
<cking> jsalisbury, i've forwarded you some background info and a possible workaround 
<jsalisbury> cking, awesome, thanks, Colin!
<cking> if we can get the ACPI tables though, I can check out my hypothesis, but there is no harm in spinning them a test kernel 
<jsalisbury> cking, cool, thanks
<ogasawara> bjf: next week is SRU verification week right?
<bjf> ogasawara, it's regression testing week
<ogasawara> bjf: ah, thanks.  can you point me to the calendar I should follow?
<bjf> https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock
<ogasawara> bjf: thanks
 * cking ~~-> catches the weekend
 * henrix follows
#ubuntu-kernel 2013-03-09
<MoPac> Hello -- during an in -place update from quetzal to ringtail, my boot partition ran out of space when installing the 3.8 kernel (100mb not enough for two kernels at once...sigh).  It threw a bunch of errors and then had me restart a couple of times and seems unstable. 
<MoPac> Is there an easy way for me to error-check and/or refresh the kernel files in my boot directory?
<MoPac> doing a manual install from cache search linux-image tells me I have the latest versoin, but I assume that didn't involve an integrity check
<geofft> You could run debsums on the linux-image-`uname -r` package. Or apt-get reinstall it. (You likely also want to run update-grub for good measure) 
<geofft> This is not a support channel, though. 
<MoPac> Ah, sorry about that.  I was directed by the second FAQ at https://wiki.ubuntu.com/Kernel/FAQ
<geofft> Oh, well, maybe it is. :) (I just started lurking here a few days ago 'cause I have some development things I want to work out with the kernel team) 
<geofft> (I'm not part of the kernel team, I'm just a user) 
<MoPac> I assume that I want the generic image and not the "extra" version?
<MoPac> I seem to remember seeing the word extra during the update process
<MoPac> Or would I need both, as some forum banter suggests?
<geofft> I'm not sure what you need, but it's easy enough to see if you have it installed (or partly installed) already 
<geofft> Run "dpkg -l" and the package name, and see if you get a line that starts with "ii" 
<MoPac> I don't have it -- I think that may have been the error, actually -- that there wasn't enough room for the extra package
<MoPac> Makes sense now.  But I'll clear it all out and add both
<MoPac> thanks for your help
<geofft> apw: does http://debathena.mit.edu/trac/ticket/1309 look like a correct summary of our discussion re OpenAFS? 
<geofft> Relatedly, uh, ubuntu-kernel@l.u.c is _ridiculously_ high-traffic. Is there a list that just gets emails about new kernel versions in the PPA? 
<cyril_> hi
<apw> geofft, that describes it pretty well indeed
<apw> geofft, not currently, but it might no be unreasonable to raise that on the list
<geofft> OK, will do 
<geofft> and thanks re confirming my writeup is correct 
#ubuntu-kernel 2013-03-10
<penguin42> bug 1093217   seems an odd one, but that one of the reporters seems to have tracked it down
<ubot2`> Launchpad bug 1093217 in linux (Ubuntu) "Ubuntu 12.04 10-20min boot delay (From 3.2.0.29->3.2.0.30) [Lenovo IdeaPad Z580]" [High,Triaged] https://launchpad.net/bugs/1093217
<penguin42> if someone who understands ACPI/DSDT could have a look at it then it would probably be good
<infinity> sconklin / apw: Need a linux-signed to go with the new linux for quantal in the PPA.
#ubuntu-kernel 2014-03-03
<raj_> "kernel: Cannot read proc file system: 1 - Operation not permitted. " getting these repeated messages  million times every minute in my syslog on 12.04 ubuntu VPS based on OpenVZ, anyone has any idea please   ???
<ppisati> yo
<cristian_c> Hello, I've submitted a bug report (regarding a kernel bug) on launchpad almost two years ago
<cristian_c> recently, the bug status has been set to Triaged and I was told to read this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel. I've read it but I've got some doubts yet. A dev has told me to contact the kernel team for preparing a faultless upstream report
<cristian_c> A question:
<cristian_c> 2) While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit.
<cristian_c> exactly, what have I to do, about this point?
<cristian_c> Any ideas?
<apw> ppisati, moin
 * apw has severe dajar-vue (and spelling failure)
<apw> cristian_c, i am sure we have had this conversation before no?  which bug #
<cristian_c> apw, ok, but I don't know I hae to do, anyway
<apw> if you tell us the bug number again, we can put the instructions in the bug
<cristian_c> ok
<cristian_c> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
<ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
<cristian_c> *have
<apw> cristian_c, you have tested the mainline kernel, and joe has marked this as needing a bisect
<apw> that normally means he will get to it when he gets a chance to start that bisect, and will put more instructions in the bug
<cristian_c> apw, ok, but I was told to open an upstream bug report too
<apw> i'll poke him when i see him (he is on a differnt timezone) to see where it is on his queue
<apw> if joe is going to do a bisect, it can wait i suspect (the upstream bug)
<cristian_c> apw, ok, then I'll look occasionally the report on Lauchpad from now on, in order to be informed of the transition to the next step
<xnox> how long does linux autopkgtest usually take? forever, and a half or just an eternity?! =)
<apw> xnox, it is building one flavour, so on a fast machine an hour, otherwise ... who knows
<apw> xnox, what package triggered it, so i can find it
<xnox> apw: initramfs-tools upload.
<xnox> apw: i'll just wait, I guess.
<apw> xnox, oh really, there is a merge of 115 pending review somewhere, damn
<apw> xnox, i am pleased to report that there seems to be no timing info in the previous one to guage it from
<apw> xnox, but i would guess that it took about 1.5 hours from the logs we do have
<xnox> apw: excellent. 115 -> done by who?
<xnox> apw: it's a tad late to do that past feature-freeze. I did the required cherrypick to unbreak intel-microcode package (which is also wanted by a customer)
<apw> xnox, moi, just checked and the bits you pulled in are (obviously) in it ...
<apw> xnox, yep, i actually did it before FF, but it has taken more time than it should to get the appropriate review, due to customers poking
<xnox> apw: cool.
<apw> xnox, it is in infinity's hands, he'll either sort it, or it'll go into U one way or the other
<xnox> apw: yeah, migrated 10 minutes ago. so 1.5h + ~0.5 for britney to notice is a good estimate.
<apw> great
<rtg> smb, pushed 'kvm, vmx: Really fix lazy FPU on nested guest' for bug #1278531
<ubot2`> Launchpad bug 1278531 in linux (Ubuntu Trusty) "nested kvm fails with trusty and upstream kernels" [Medium,Fix committed] https://launchpad.net/bugs/1278531
<smb> rtg, Thanks, it should sooner or later come via upstream stable, too
<rtg> yup, this way though it marks the bug fix released
<smb> Right, good thing as this blocked some other testing of Serge
<apw> rtg, when we due the next 3.13 you recon?
<rtg> apw, we should upload today. you've accumulated a bunch of ppc64el pconfig changes, plus the nested KVM patch
<apw> rtg, was trying to judge whether there was a stable "today" indeed for that reason
<rtg> apw, I don't think there will be, but I did push that KVM patch in advance of stable
<apw> yeah pleased to see that fixed, and in is good
<rtg> apw, I'll put a bow on it and do some test building
<apw> rtg, sounds good, thanks
<rtg> apw, you and infinity are sure about the 64K system pages patch ?
<apw> rtg, i think the moons are aligned there now, and its not like the builders take it without manual intervention
<apw> rtg, i haven't been sent an upload announcement for -meta, is that deliberate
<rtg> apw, dunno. I added the tracking bug, plus I also received the upload announcement
<rtg> apw, over zealous SPAM filtering ?
<apw> rtg, it is in LP so ... must be email or something, goodo
<henrix> kamal: i have yet another patch for our scripts, this time notify-stable-release
<henrix> kamal: could you please take a look here: http://paste.ubuntu.com/7028568/
<henrix> (i can send the patch to ktml, but since we're the only living souls using this script...)
<kamal> henrix, that looks fine to me too
<henrix> kamal: cool, thanks ;)
 * henrix admits most of the code was stolen from notify-stable-review ;)
<kamal> henrix, I thought it looked awfully familiar!  ;-)
<henrix> heh
<rtg> apw, Its curious that we don't have EARLY_MICROCODE turned on. I pushed a config patch and am gonna see how I can make it work on a Haswell
<trippeh> also needs a initramfs-tools update
<trippeh> debian has the needed bits in theirs
<rtg> trippeh, thats kind of what I was thinking as well
<trippeh> it was fairly easy to backport into to 0.103ubuntu*
<apw> rtg, ack
<trippeh> I guess initramfs-tools could use a debian sync ;)
<rtg> trippeh, not sure if wanna do a complete sync at this point. do you have a patch for your backport  that you mentioned above ?
<rtg> trippeh, looks like xnox has already done it '[f59e716] implement early initramfs support (Closes: #712521)'
<xnox> trippeh: are you joey? =)
<trippeh> rtg: sure.http://tomt.net/temp/early_initramfs.patch
<trippeh> ah
<trippeh> xnox: Nope.
<xnox> trippeh: ok, well a joey pinged me to do this early hours UTC, and it's been in release pocket since ~ 10:30 UTC, but I don't have a machine to test this on (one that would require e.g. intel-mircocodes)
<rtg> xnox, working on it... we didn't have the right kernel config enabled either
<xnox> trippeh: if you have hardware that needs this support, testing it would be good.
<xnox> rtg: whoops. I wonder if I should revert initramfs-tools upload then? cause all initramfs with intel-microcode package installed would then be broken-ish....
<trippeh> I've tested the backport I did on a bunch of 13.10 installs
 * xnox tries to reboot a generic machine to see if it will boot at all.
<xnox> trippeh: with or without kernel config change?
<trippeh> Hm. We do run our own kernels. Didnt check the version logic on ubuntu kernels
 * xnox reboots.
<rtg> xnox, gimme a bit to see what it actually does. I've got a bare metal Haswell that should load microcode.
<apw> rtg, i have a synced version of initramfs-tools already, which is pending reviwe at the moment
<trippeh> ah, the version logic is in the actual microcde-packages, duh
<rtg> apw, can we sync this late in the game ?
<apw> rtg, its a merge ... but ... that is up to the reviewer, it was submitted some time ago
<rtg> apw, there are quite a few changes since the last sync
<xnox> rtg: so, the initramfs with early micro-code is bootable. but my machine doesn't need any, as far as I know.
<xnox> rtg: the "traditional / late microcode" would be missing though with todays updates, so if we get kernel in soonish, it should be okish.
<apw> rtg, i synced it with before xnox's update and after
<apw> (as his changes were already in)
<xnox> rtg: well, it's frankenstein, our version number is fake, 103 is not the real base (our version number is fake)
<xnox> rtg: and we cherrypicked a lot of changes.
<apw> yes its a 0.99 version, i did a proper merge, pullig all out changes into patches in git
<xnox> apw: \o/ awesome =) where is it? can I grab it / review it?
<apw> xnox, i think infinity is already reviewing it, so it'd be sad to duiplicate effort
<apw> and as he was the one who made the 0.99 0.103 hy
<apw> hybrid, he likely should review it
<xnox> apw: he was also meant to do the merge... instead of sub-contracting it out =)
<apw> xnox, heh, well i did a merge some time back which got lost in the noise, so i was in a good position to redo it on the newer base, as i had done 99% of the work in idnetifying the changes
<apw> xnox, way back when in +1 days
<xnox> ah, lol =)
<xnox> apw: i wonder if +1 days will come back between 14.04.0 and 14.04.1 ;-)))
<apw> xnox, some hope
<rtg> xnox, so how do I get some verbosity during the kernel install to tell if its actually packaging the early ucode in the initrd ?
<apw> rtg, can't you unpack the initrd and have a look ?
<apw> zcat /boot/initrd | cpio -it
<apw> sort of thing?
<rtg> apw, all I'm seeing in the initrd is 'scripts/init-premount/intel_microcode'
<antarus> '12
<antarus> ugh
<trippeh> there is a verbose flag to initramfs-tools iirc
<trippeh> update-initramfs that is
<trippeh> it showed the early stuff going on for me
<apw> rtg, perhaps just run update-initramfs -u -v
<rtg> yep, that makes a bit more noise
<rtg> /usr/sbin/iucode_tool: No valid microcodes were selected, nothing to do...
<rtg> so, maybe the haswell doesn't need an update
 * rtg needs brain food, back in a bit after lunch.
<xnox> rtg: i installed intel-microcode package.
<xnox> rtg: then i modify /etc/default/intel-microcode
<xnox> rtg: IUCODE_TOOL_INITRAMFS=early
<xnox> rtg: IUCODE_TOOL_SCANCPUS=no
<xnox> rtg: then it will force include all of them as early microcode.
<xnox> rtg: initramfs will be "interesting"
<xnox> $ file /boot/initrd.img-3.13.0-13-generic
<xnox> /boot/initrd.img-3.13.0-13-generic: ASCII cpio archive (SVR4 with no CRC)
<xnox> rtg: $ cd `mktemp -d`;  cpio -ivd < /boot/initrd.img-3.13.0-13-generic 
<xnox> kernel
<xnox> kernel/x86
<xnox> kernel/x86/microcode
<xnox> kernel/x86/microcode/GenuineIntel.bin
<xnox> 862 blocks
<rtg> xnox, well, it at least hasn't broken anything. I'll try to find a CPU that actually needs an update.
<Prf_Jakob> So I'm about to send a very large patch to the ml with the vmwgfx hardware enabelment code, how do you guys want it? As a 256kb mail or as gz attachment?
#ubuntu-kernel 2014-03-04
<bjf> Prf_Jakob, how about as a pull requestion pointing at your public git repo?
<Prf_Jakob> bjf: kay, where is the ubuntu kernel located, due to holidays I'm only the messanger in this case.
<bjf> Prf_Jakob, git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
<Prf_Jakob> thanks
<ppisati> moin
<smb> Morning
<ppisati> rtg was faster than me, doh!
<apw> ppisati, ?
<ppisati> apw: i filled up an lp bug and for a staging-driver inclusion, but i didn't send the pull req yet
<ppisati> apw: woke up this morning just to find out that he dit it :)
<ppisati> proactive merging :)
<apw> heh
<apw> ppisati, that is actually more like psychic mergine
<marvin24> can this small addition to a device tree be added to trusty-unstable kernel (3.14)?
<marvin24> https://gitorious.org/ac100/marvin24s-kernel/commit/380d2091525792a7df5b7b948d07174bd602cb97
<marvin24> this is the last missing piece to get my ac100 booting out of the box
<apw> ppisati, ^^
<ppisati> apw: looking right now
<ppisati> given that it touches only the paz00 dts (aka ac100), i'm ok with it
<ppisati> just a question, did you try to upstream it?
<ppisati> marvin24: ^
<apw> smb, hey have you used lxc subuid stuff?  what does a default entry look like for moi
<smb> apw, No, I am ignoring lxc as hard as I can
<apw> smb, heh ok
<smb> sforshee, Maybe you had more time to play with that?
<smb> apw, I think I remember some mapping statements but not well enough
<sforshee> apw: did you read stgraber's blog post? It's a really nice guide to setting that up.
<smb> https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
<smb> apw, ^ Just got there too
<smb> :)
<apw> sforshee, thanks
<marvin24> ppisati: it's upstreamed already, but for 3.15 only
<marvin24> in fact, I was a few hours too late :-(
<marvin24> thanks!
<marvin24> FYI: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/tegra20-paz00.dts?id=5816898b9592b877209e91c493db946ab275d825
<apw> lxc_container: Could not set clone_children to 1 for cpuset hierarchy in parent cgroup.
<apw> sforshee, seen that ?
<apw> stgraber, hey ... user containers, can you have disjoint uid mappings such as below:
<apw> apw:200000:65537
<apw> apw:1000:1
<apw> lxc.id_map = u 0 1000 1
<apw> lxc.id_map = u 1 200000 65535
<apw> stylee ?
<apw> hallyn, about ?  i am having trouble using your reproduce by instructions, my containers won't start
<infinity> marvin24: Will that DT work with 3.13 too, or only 3.14+?
<marvin24> infinity: it won't work because it requires updates to the pwm and drm subsystem
<apw> then ... 
<marvin24> a bit unfortune for trusty, but well ...
<infinity> marvin24: I was afraid you'd say something like that.
<apw> not much point in pulling in the dt parts then
<infinity> apw: He was asking for it to be pulled into unstable, not master.
<infinity> That said, by the time trusty releases, unstable will have rolled over to 3.15rc, I suppose, and will include the commit from linux-next.
<infinity> Probably.
<infinity> marvin24: More curiously, are the other commits it depends on reasonably small and backportable to 3.13, or would that blow up the world (or cause our kernel team to vomit)?
<marvin24> infinity: I had 3.14 in mind, which may be the standard kernel at this time
<infinity> marvin24: Cause if we can make your platform go with trusty's generic kernel with very little effort, I doubt we'd say no.
 * ppisati usually vomits for no apparent reason
<marvin24> infinity: I'm not sure which one we need, but I can find out
<marvin24> this may also be helpful for other SoCs
<marvin24> which have problems to get the backlight up
<infinity> There are pills for that.
<apw> infinity, i would guess 17
<marvin24> seems that it is only useful for tegra now as the drm/kms drivers also needs some change
<marvin24> not worth the effort
<infinity> zequence: Are you going to get around to regression-testing the lowlatency SRU kernels?
<infinity> BenC: Can you smoketest the saucy linux-ppc kernels in -proposed on some of your kit?  I'm not home this week, so can't test on any of mine.
<stgraber> apw: yes, you can
<apw> stgraber, don't seem to be able to write it such that it will actually work, it just barf at the newuidthing step
<stgraber> apw: I take it your current uid is 1000 right?
<stgraber> apw: if so, you don't have to put it in /etc/subuid as you own it already anyway
<apw> stgraber, yeah that is me
<apw> stgraber, and i had the right incantion in the other bit ?
<stgraber> apw: I think the rest is fine, I'm just not sure the multi-line subuid is valid, so I'd just go with "apw:200000:65537" as the second one isn't required anyway
<stgraber> apw: I'm assuming you've put similar ranges as "g " entries and a matching line in /etc/subgid?
<apw> stgraber, yeah, ok so now i have one line in subuid/gid giving me the 200000 range and the below in default.conf:
<apw> lxc.id_map = u 0 1000 1
<apw> lxc.id_map = u 1 200000 65535
<apw> lxc.id_map = g 0 1000 1
<apw> lxc.id_map = g 1 200000 65535
<apw> and a create does this:
<apw> newuidmap: write to uid_map failed: Invalid argument
<hallyn> apw: why do you have the 'u 0 1000 1" lines?
<apw> or is it:
<apw> lxc.id_map = u 0 1000 1 1 200000 65535
<apw> lxc.id_map = g 0 1000 1 1 200000 65535
<apw> hallyn, i am trying to map container 0 to my main id for convienience
<apw> not that that works either, hurumph
<hallyn> no that won't work
<hallyn> well the first set of 4 looks ok
<apw> neither work
<zequence> infinity: yep. I'll do it today sometime
<infinity> zequence: Awesome, thanks.
<hallyn> apw: but you say "for convenience";  lxc-create sets up the rootfs so it shouldn't really be needed...  so is lxc-create failing, or lxc-start?
<apw> lxc-create is fialing with my setup using 0 == 1000, i was trying to do that to avoid having to have acls all over the place for 20000
<apw> lxc-create was failing trying to get to .local/share/lxc or similar, without a heap of acls
<hallyn> apw: it looks like a bug.  It's trying to run newuidmap on the same task twice which isn't doable
<apw> hallyn, that is kinda why i thought i might have to put them on the one line, as the command line for newuidfoo would look like that, no dice that way either
<apw> anyhow, with a heap of acls, things "work"
<hallyn> apw: no, lxc_usernsexec is supposed to just run newuidmap once.
<apw> hallyn, it does seem most logical to me to use my own id as root, so i can float round in my containes
<apw> containers
<hallyn> apw: nnnot. really...
<hallyn> you're not actually root in your container unless you start a new container anyway
<apw> indeed, but a lot of the filessytem is my root id, which is handy
<hallyn> if you trust your container :)
<hallyn> mind you, this is a huge bug, and i'm quite certain a regression.  your use case should be supported
<apw> in this case i prolly do indeed
<hallyn> MAN dh_shlibs is slow
<hallyn> apw: having received no response i was going to write/test/send a patch using vfssetxattr_noperms for trusted.overlafys today
<hallyn> stgraber: bad news, commit 0e6e3a41089c86447fef18e54c2796b312a57a94 broke it
<hallyn> hm, that's not the commit id :)
<hallyn> oh it is, it hels if i'm in a git tree to view it
<stgraber> hallyn: oh, hmm, so what did I break exactly? :)
<stgraber> apw: so you're using ppa:ubuntu-lxc/daily ? (the commit hallyn mentioned hasn't made it to the archive yet)
<apw> nope, not me, i use whats in the archive
<stgraber> hallyn: because I use multiple uid/gid ranges with my containers here and that clearly works...
<stgraber> hallyn: right, so apw is using lxc 1.0.0 final which didn't have that commit (that commit is aimed at 1.0.1)
<apw> that explains that then, get 'er uploaded :)
<hallyn> apw: hm, then i'm confused
<hallyn> ill go have breakfast.  bll
<apw> hallyn, i think it all makes sense now, i am doing somthing 101 will be able to do
<apw> so i'll stop doing that, cause it hurts, and add a heap of acls
<rtg> jodh, jsalisbury: whats the story on CONFIG_IPMI_HANDLER ? Is it going back to being a module ?
<mjg59> I'd recommend against doing that
<mjg59> Anything that uses IPMI operation regions may be randomly broken
<jsalisbury> rtg, configuring CONFIG_IPMI_HANDLER as a module fixes the bug, but it is also fixed as a module in 3.14 mainline, so we were also performing a revese bisect
<hallyn> apw: just to be sure, dpkg -l | grep lxc?
<hallyn> apw: what you do should be supported.
<jsalisbury> s/fixed as a module/built in/ in 3.14
<rtg> mjg59, looks like they are still working on it. I'll leave it built-in for now.
<hallyn> Oh I think I see the *actual* bug :)
<apw> ii  lxc                                                   1.0.0-0ubuntu4                         amd64        Linux Containers userspace tools
<hallyn> apw: i have a fix.  will send a in a bit to the list,
<hallyn> if you want to build your own, patch is http://paste.ubuntu.com/7033605/
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 3 minutes - #ubuntu-meeting ##
<BenC> infinity: Will do
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 18th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> rtg, you have prolly already noticed, but i pushed that config revert some time ago
<rtg> apw, yup
<rtg> apw, I'm messing with vmwgfx. If I can figure it out, then I'll upload later today. never can have too many kernels.
<apw> rtg, did you get a broken out version?
<rtg> I was working on it, but there is some confusing non-linearity
<apw> nasty indeed
<apw> rtg, i guss you can use the "squash" backport for comparison when done
 * apw seems to have a working patch for the overlayfs permissions on whiteout when using usernamespaces, one which doesn't make me hurl :)
<apw> hallyn, just building you some test kernels with my patch applied, will post a link shortly if you could test
<hallyn> apw: oh.  i'm working with that righ tnow too
<rtg> apw, it should be a simple matter of applying all of the patches to drivers/gpu/drm/vmwgfx since v3.13, but its kind of driving me nuts.
<hallyn> just using _noperm doesn't seem tow ork right
<hallyn> well (a) it needs to be gpl exported;  and (b) i may have just done it wrong, but it left me a visible symlink to the overlayfs-whiteout file
<hallyn> so i'm trying a build where i set the userns in the override creds
<apw> hallyn, right that is what i ahve done, 
<hallyn> ah
<apw> hallyn, do do it the other way you have to use them for reading as well (non-perm versions)
<hallyn> then we can see if we ended up with the same the exact same patch :)
<hallyn> and if not, why
<apw> and its jsut a mess, i have one of those working too, but the cred ns hack seems to work here
<apw> hallyn, http://people.canonical.com/~apw/overlayfs-perms2-trusty/0001-UBUNTU-ubuntu-overlayfs20-switch-to-the-init-user-na.patch
<hallyn> apw: looks good, thanks - I'll wait for yours to build then and test it.
<apw> hallyn, cool, should be soon ...
<apw> hallyn, annoyingly that is what i wanted to do first off, and the mention of the _noperm way side tracked me, i should have listened to self
<hallyn> apw: yeah...  now there's a reasonable chance ppl will want your patch to turn into some more general new override_creds() extension.  but we'll see.
<apw> hallyn, yeah, i recon there should be a "creds_ns(foo)" at least
<apw> more likely a "override_creds_system()" or similar
<apw> hallyn, kernels at: http://people.canonical.com/~apw/overlayfs-perms2-trusty/
<apw> let me know how you fare, they seem to work for me
<hallyn> thx, will do
<hallyn> apw: looks good
<hallyn> no wait
<apw> hallyn, ?
<hallyn> heh, sudo misuse.  looks good :)
 * apw slips out for an hour, will check in when i get back :)
<hallyn> apw: oh fwiw, patch is doing great.
<miseria> "los regalos, gustenos o no, hay que agradecer ante todo, el tiempo que esa persona dedico para pensar en ti" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<dpippenger> can anyone point me to the repo that contains the source files used to build the kernel located here? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.31-saucy/
<apw> hallyn, sweet, i'll push that on tommorrow, and shove it up as well
<apw> dpippenger, you need to fetch the commit in the file "COMMIT" from linus' mainline repo, and hten apply the patches in the same directory
<dpippenger> those patches seem incomplete, for example they reference firmware files that aren't part of the upstream kernel like bnx2x/bnx2x-e1-7.8.17.0.fw
<apw> dpippenger, they are made from that base, and the patches are git format-patch'd from there, so they should be complete; have you tried actually doing that?
<dpippenger> yes, I've gotten it to build up until the install phase, but kernel-wedge copy-firmware bombs because newer bnx* firmware is referenced in the packaging patches that generate the control data.
<apw> yep, we never make d-i from those images, nor use the full packaging flow either, they are just test builds
<dpippenger> I see
<dpippenger> ok, I was just concerned I was missing something since it didn't build clean
<apw> you likely can get it to work without those, disable_d_i=true or similar disables that
<dpippenger> ok, thank you
<apw> nope they are dirty hacks to get something for every tag, they are not intended to pass an uploaders review
<dpippenger> cheers all, have a nice day
#ubuntu-kernel 2014-03-05
<ppisati_> the sun is shining, wake up!
<smb> ppisati_, Its struggling, so do we :-P
<apw> ppisati_, it is shining here too, what gives?
<apw> moin
<brendand> cking, do you know which document specifies the length of different fields in DMI?
<brendand> sorry if i repeated myself, i think i dropped offline
<cking> brendand, somewhere on http://www.dmtf.org/standards/dmi, let me see..
<cking> http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf
<cking> it's a relatively easy spec, only 137 odd pages
<cking> brendand, some fields such as strings are NULL terminated
<brendand> cking, so for SKU number the length is BYTE and the type is STRING
<brendand> cking, does that mean the maximum length is 256?
<cking> lemme look it up in the spec first
<cking> brendand, nope, the byte size is an index into a table that contains null terminated strings
<brendand> cking, so there is no real limit on the length
<cking> brendand, let me read that bit up in the spec..
<cking> brendand, section 6.1.3 tells you about strings, the real limit is the Structure Table Length field of the SMBIOS Structure Table Entry Point
<cking> so the actual limit is 64K
<cking> -1 byte
<cking> ish
<brendand> cking, just a quick question - in that document SKU Number is said to be there since version 2.4 of the spec
<brendand> cking, but the latest version i see on the site is 2.0.1
<cking> http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf
<cking> that's version 2.8.0
<rtg> apw, you mentioned an overlayfs patch for the lxc dudes yesterday. how is that coming ?
<apw> rtg, i have a good working one, i am just about to boot and test a possibly simpler one
<rtg> apw, ack
<apw> hallyn, i have spun a much simpler patch for the overlayfs things, which i would love you to test as well, if that is good i will submit both upstream as options: http://people.canonical.com/~apw/overlayfs-perms3-trusty/
<apw> someone else can decide if going all nuclear is ok
<hallyn> apw: ok, building a vm to test
<apw> hallyn, great
<hallyn> apw: workign well.  now i'm going to do a release-upgrade inside an unprivileged clone;
<apw> great
<hallyn> that worked too, excellent
<rtg> sforshee, upload new firmware bits to trusty. https://bugs.launchpad.net/intel/+bug/1265436/comments/13
<ubot2`> Launchpad bug 1265436 in intel "Update firmware for 7260 / 3160 devices (Wilkins Peak)" [Undecided,New]
<rtg> uploaded*
<sforshee> rtg: ack, I just tried out the new 3160 firmware yesterday
<Fokkeeerrr> hi
<xnox> what is the minimum i386 cpu/machine specs our generic kernel support?
<xnox> is sse/pentium4 required?
<apw> i have mentally stored pentium4 + sse as the minimum, it was really a minimum at the libc level i think
<apw> slangasek, ^^ i think you were there when we made that decision in oh precise or something
<slangasek> apw: the libc6 minimum is still i686
<slangasek> SSE is definitely not required on i386 userspace
<apw> see people with memories ftw
<apw> hallyn, i take it you are happy :)
<hallyn> apw: yup :)
<apw> hallyn, ok i have shoved the decision upstream, but for now i assume you need something, so i would propose applying the second one.  but i'll let you read
<hallyn> read on lkml you mean?  i looked at the patch, looked good
<apw> hallyn, well i was more asking if you has a preference between yesterdays and todays
<apw> ie the one that looked like yours, and this shorter one
<apw> hallyn, and remind me do we ahve bug associated with this i shoudl be quoting?
<hallyn> apw: i think the one from today is better.
<hallyn> apw: no i guess there is no open bug
<apw> hallyn, ack and ack; i'll push todays and change it if things change upstream; i expect it'll be quiet
<cristian_c> Hi
<Prf_Jakob> rtg: Thanks for including the patches.
<rtg> vmware ? no problem.
<cristian_c> a long time ago, I reported a bug in launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
<ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
<Prf_Jakob> rtg: yeah :)
<cristian_c> in recent times there have been regressions too
<cristian_c> it needs bisect
<rtg> cristian_c, jsalisbury can likely help with that
<cristian_c> rtg, ok
<cristian_c> the doubt is about the request
<cristian_c> does it refer to regressions or original bug?
<apw> cristian_c, to know if the led color issue is fixed one would need the functioanlity to work
<cristian_c> apw, some releases have been suggested
<cristian_c> but they are very old kernel
<apw> cristian_c, well he is tyring to bracket when the issue appeared
<cristian_c> regressions are appeared only from December onwards
<cristian_c> *kernels
<cristian_c> 'wrote on 2013-12-31:	 #21 I've tested the 3.13.0-031300rc5 kernel and I noticed this bug getting worse compared to the previous kernels. Exactly, the switch between wifi on and off is very slow and the LED does not change color by pressing the button before or after performing the workaround.'
<jsalisbury> cristian_c, I requested the older kernels due to the Bug description.  It suggested the regression started in 11.10, is that not correct?
<cristian_c> apw, before then, the regressions did not exist
<cristian_c> jsalisbury, ok
<cristian_c> then original bug, not regressions
<cristian_c> :)
<cristian_c> thanks
<cristian_c> I've always found that bug since I have got that pc
<jsalisbury> cristian_c, Yeah, the kernel tested in comment #21 was a release candidate for the 3.13 kernel.  If the new issue that happenes with that kernel still happens with the latest 3.13 kernel in Trusty, then we should open a new, seperate bug for that.
<cristian_c> jsalisbury, ok
<cristian_c> then, it needs so
<jsalisbury> cristian_c, Ok.  I'll look for the new bug.  
<jsalisbury> cristian_c, For the original bug, you never had a prior kernel that worked?
<cristian_c> jsalisbury, I tried that pc with ubuntu at least since 2009
<cristian_c> I think with 2.6.x too
<jsalisbury> cristian_c, And the bug happened with the 2.6 kernel?  If that is the case, maybe it is not a regression.
<cristian_c> jsalisbury, I think that the original bug is not a regression
<cristian_c> jsalisbury, but I tried the workaround only later
<cristian_c> jsalisbury, I'll try the kernels you suggested
<cristian_c> :)
<jsalisbury> cristian_c, Hmm, if the bug is not a regression and still exists in the latest mainline kernel(3.14-rc5), then we should probably open an upstream bug report as well.
<jsalisbury> cristian_c, Ok.  Yeah, it would be best to test those kernels before reporting upstream.  That way we can confirm if it is a regression or not.
<cristian_c> at the beginning switch was not working and there was no blinking
<cristian_c> subsequently blinking appeared 
<cristian_c> then, I tried the workaround, and colors were inverted
<cristian_c> with 3.8.x series (ubuntu 13.04) too
<cristian_c> when I tried 3.13.x regressions appeared
<cristian_c> until now (3.14.x)
<cristian_c> with regressions workaround didn't work anymore
<cristian_c> (no color switch, neither reversed)
<cristian_c> jsalisbury, ok, I'll make the test with old kernels and I'll report results in launchpad bug page
<cristian_c> :)
<jsalisbury> cristian_c, thanks
<cristian_c> :D
#ubuntu-kernel 2014-03-06
<ppisati> hi
<apw> ppisati, hi
<cking> morning apw
<cking> hey, the 3.13.0-16 -proposed kernel breaks my USB on various thinkpads I have
<cking> apw, reverting 65482e0c807a50dc3ec9d59a7465801f9c56bf52 seems to fix it on a t440, I'm just going to try it on my x230
 * cking reboots to try it out
<cking> yup, that fixes it ;-)
<apw> cking, BAH
<cking> yup
<apw> on the broken kernel does enabling threaded irqs make it work again ?
<cking> not tried that
<apw> be a good data point for when "we" moan about it
 * apw has a looks see if unstable builds with the patch on so you can see if this combo works, ie. rtg missed another commit needed
 * cking wished it had been tested ;-)
<apw> i am sure he boot tested it, but he may not use USB in that combination.  it would have caught me though
<cking> it only caught me because of the low-latency vs generic testing I did last evening
<cking> threaded irqs make it work
<apw> cking, erp
<cking> lemme get an x220 rigged up and tested too
 * ppisati ponders why some modules are automagically loaded while others are not... 
<ppisati> but before that, food!
<wmp> hello, i where i can found kernel 3.11.0-16-generic to 12.04?
<wmp> server
<apw> wmp, you want an older kernel than the one in -updates yes ?
<wmp> yes, now i have 3.11.0.-17 and in them is bug
<wmp> i 3.11.0-15 works good, so i want check 3.11.0-16 and report
<wmp> apw: on 3.11-17 i have degradated raid on normal booting ubuntu, on rescure grub option works good
<wmp> on 3.11-15 all works good
<apw> wmp, ok there was no -16 for linux-lts-saucy as far as i can see
<apw> 3.11.0-15.25~precise1 then 3.11.0-17.31~precise1, and coming soon -18
<wmp> ok, so i should report that works on 3.11-15, and dont works  on 3.11.-17?
<apw> could you file a bug against linux-lts-saucy saying that indeed, and post the number here
<wmp> ok
<wmp> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1288703
<ubot2`> Launchpad bug 1288703 in linux (Ubuntu) "3.11-17 MDRAID degradaded in normal boot, but on rescure works good" [Undecided,New]
<apw> bjf, ^^
<apw> cking, ok this ehci issue does not affect my 32bit tester ...
 * apw boots up more kit to see if he can find anything to repo. this
<wmp> apw: hmmm, maybe i wrong debugging this bug...
<wmp> apw: works on 3.11-15 when i set it manual on grub, when i wait to timeot and grub chose this kernel automatical, server dont boot...
<cking> apw, let me try it on some other kit then
<apw> cking, t'is very odd to me
<cking> yep, it would appear that my tests are doubtful, but I will test on other kit and re-do my tests if required
<apw> cking, i have some more kit upgrading now to confirm deny
 * cking preps some older kit too
<apw> smb, have you used schroot copyfiles at all ?
<smb> apw, maybe
<xnox> Will "[Config] CONFIG_MICROCODE_EARLY=y" fix be applied across all kernels? (that is precise and all hwe kernels?)
<apw> xnox, would we normally want to apply this to older kernels?  noone has needed till now?
<apw> smb, bah it seems setup.copyfiles is per chroot, so i have to add it to them all, or do it myself
<xnox> apw: right, true. intel-microcode only started to want/use early firmware in 13.06, and 13.10 release is a short-lived one.
<smb> apw, Not sure I completely understand the context there. I assumed it was the part that automatically copies in some files which seems to be used automatically
<apw> smb, i want to add another file ... to copy in
<smb> apw, I thin there where at least a copyfiles file per template which contained the files
<smb> at least back in P
<smb> Like /etc/schroot/default/copyfiles
<zequence> apw: I think it's safe to put threadirqs back in. bug 1279081
<ubot2`> Launchpad bug 1279081 in linux (Ubuntu Trusty) "linux freezes with threadirqs parameter when rt73usb is loaded" [High,Fix released] https://launchpad.net/bugs/1279081
<rtg> apw, pushed 'Revert "UBUNTU: SAUCE: allow IRQs to be irq-threaded by default via config"'
<arges> rtg: tc qdisc add dev eth0 root netem delay 80ms
<arges> btw
<infinity> BenC: Did you do any linux-ppc/saucy smoketesting so I can release those kernels?
<wmp> apw: did you remember my problem with raid? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1288703
<ubot2`> Launchpad bug 1288703 in linux (Ubuntu) "3.11-17 MDRAID degradaded in normal boot, but on rescure works good" [Undecided,Incomplete]
<wmp> LOL, WTF...
<BenC> infinity: I did. All appears ok on my end
<infinity> BenC: Shiny, thanks.
<BenC> infinity: FYI, that need meta as well (I didn't prepare that one, forgot)
<infinity> BenC: I did meta and committed and pushed.
<BenC> infinity: Thanks
<infinity> I think I've done the last couple.
<infinity> And that's all the SRUs for this cadence released.  I can sleep soon now. :P
<infinity> BenC, zequence: As always, thanks for the work on the community kernels.  Catch you next cycle for more nagging.
<BenC> infinity: Thanks for manging my poor response time with diginity and patience :)
<infinity> BenC: I really think that one of these days we need to revisit why we need 5(!) flavours instead of 2.
<infinity> BenC: I can't help thinking there pretty much has to be a clever way to mangle things in early setup to work for all 32-bit and all 64-bit in two kernel images.
<BenC> infinity: Well, powerpc started with 3, so we just need to discuss the extra two, and I can explain them easily :)
<infinity> BenC: 2, not 3... powerpc and powerpc64
<rtg> _I_ would sure like to reduce the number of powerpc flavours
<infinity> BenC: You have 3 extra flavours on top of that.
<BenC> infinity: I can go into more detail, but if benh tells me he's not willing to do the work it will take, I assume it will take us mortals several months to accomplish
<BenC> infinity: Oh, right
<BenC> infinity: -e500 can go away for all I care. But I think it will be important when we get p-cubed out of our imaginations and into a production facility
<infinity> If you have no interest in >= trusty booting on e500, patches/pull-requests welcome to tear it out.
<infinity> Unless I should parse your sentence as "I don't care now, but I will again later".
<BenC> infinity: the latter
<infinity> Right, okay.  No point removing it just to revert the removal later then...
<BenC> infinity: If you feel like a phone call to get into the details, let me know
<infinity> I suspect if I replace all of our PPC buildds, rtg while whine a bit less, since sagari-class hardware building 5 flavours still beats armhf building two (by a fair bit).
<infinity> BenC: A call between you, me, and Tim wouldn't be a bad idea, when I'm not in China.
<infinity> BenC: Better still if I can talk Ben into joining, so we can get the upstream port maintainer view on this.
<rtg> infinity, I always cross compile for test builds anyways, so having a porter doesn't help much.
<infinity> rtg: Sure, I don't mean test builds, but archive builds.
<BenC> infinity: Ok
<infinity> rtg: When linux/ppc lands on ross or adare and I notice, I kill it and move it. :P
<rtg> infinity, right, I don't care about how long archive builds take. armhf is almost always last.
<BenC> infinity: BTW, we actually have metal for our 64-bit (proto) system
<infinity> rtg: So, except when testing end-to-end with tools, I imagine a single-flavour build will usually catch most things you care about (this would be more true after a config review, if all flavours are building the same set of drivers).
<BenC> One of our engineers ran some spec tests and it was 2-3 times better than the 2 x Xeon i5 machine we compared it against
<rtg> infinity, sure I can take short-cuts, but I don't want to _have_ to (other then using the cross compiler)
<infinity> rtg: Agreed.  I feel your pain (a lot more), since I test build all of Ben's SRUs on a quad-core 2.5G 970MP.
<infinity> I guess at least I'm not doing it on my 750...
<rtg> yup, I as least have giant servers to mess with
<rtg> at*
<infinity> BenC: Is that the Freescale powerpc64-emb thing, or some top secret POWER-based part I'm not allowed to know about yet?
<BenC> infinity: The former
<BenC> We actually showed off the first hot-off-the-press proto type board at an OpenCompute keynote a few weeks ago with MarkZ
<infinity> BenC: So, you really should find some cycles (or contract someone) to get some Freescale IFUNC bits in glibc to optimize string and memory functions a bit.
<infinity> BenC: Unless the generic PPC stuff actually runs really well for you.
<infinity> BenC: But IBM's been pulling out all the stops upstream to optimize the crap out of POWER4/5/6/7/8
<BenC> infinity: I'm aware. We are pushing as much as we can
<BenC> We, ourselves are working on getting OpenJDK optimized for our own iron
<BenC> That's a customer driven effort
 * infinity nods.
<BenC> infinity: And I'm happy to see that v8 is making progress :)
<infinity> BenC: v8 pretty much Just Works on IBM platforms now.  Has Andrew made any progress on your e500 kit?
<BenC> infinity: I'm not sure of his progress, but he was logged into and active on our e500mc dev box for a few weeks
<infinity> Cool.  If he gets it working, I'll happily take those patches for trusty.
<infinity> And I think you'll probably owe him some fine beverages, given that he's technically your competitor. ;)
<manjo> kamal, I have a cpu stress program ... wondering if I can send it to debian ....what would it take?
<manjo> kamal, any pointers will help
<bjf> manjo, how is yours different than the standard stress ?
<manjo> bjf, you mean the tool stress ? 
<manjo> bjf, what stress is supposed to be is a load generator, what it does for cpu is call sqrt of a random number 
<bjf> manjo, i mean http://linux.die.net/man/1/stress
<manjo> bjf, what I have is something that will exercise floating pt and integer code paths and also paths that deal with txt and data cache miss 
<apw> manjo, quake ?
<manjo> lol
<manjo> so the idea is that it could be used with our std cert 
<manjo> coz they depend on apt-gettable packages 
<manjo> or they think that would be the ideal way ... rather than integrating it and having to maintain it themselves 
 * apw deferrs to kamal on the whole thing
<kamal> manjo, sounds like you've got a program that hasn't yet been packaged, correct?  somebody would need to package it in order to contribute it to Debian.   cking is also working on getting a new cpustress tool packaged.  touch bases with him, yes?
<manjo> kamal, I have it packaged.. and building in a ppa ... but yes I will check with cking on what he is doing .. weirdly we might have the same thing going on 
<kamal> manjo, oh, you're one step ahead of me.  good man!  :-)   yeah, lmk what you and cking sort out.
<manjo> kamal, talked to cking ... I need a git repo it + cleanup and I can send you a link so you can review it 
<cking> it needs some spit-n-polish :-)
<hallyn> hm.  'fakeroot debian/rules binary-generic' should give me linux-headers*_all.deb right?
<hallyn> (cause it's not.  drat)
<bjf> hallyn, fdr binary-headers-generic   ... i think
<bjf> hallyn, actually, just binary-headers
<bjf> hallyn, so fdr binary-headers
<hallyn> bjf: thanks!
<hallyn> ok - what about linux-libc-dev? :)
<hallyn> binary-arch-headers maybe
 * hallyn finally found debian/rules.d :)
#ubuntu-kernel 2014-03-07
<ppisati> moin
 * apw yawns theatrically
 * smb tries to throw little pieces of paper
<smb> apw, Maybe I could be a little more polite and throw Shreddies. You want the regular ones or the new diamond ones. ;-P
<apw> funny i was shoving shreddies in myself when you said that, though we don't have no diamond ones
<smb> apw, Its just in your mind as cking found on the webs
 * apw looks for the camera in the corner of the room
<cking> http://www.youtube.com/watch?v=B8McutvNwtI
<smb> cking, Heh, yes that one
<smb> Good morning btw
<melodie> hi
<melodie> I could bring an information about the kernel 3.8-something which is in Precise, and the kernel 3.2.0-59 (replaced now), regarding the ndiswrapper module, and what occurs while compiling it. So there is an issue with ndiswrapper in Precise, but I will not take the time to report on Launchpad now. If someone is interested I can talk about it here
<melodie> this evening
<miseria> "Â¿quien eres tu, para decir que estoy loco?; nadie es perfecto, soy feliz a mi manera, intentalo y seras feliz" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-03-08
<TheDrums> I suppose since this isn't a support channel, it's not a good place to ask about fglrx interaction with the 3.13 series kernels and http://paste.openstack.org/show/28rf21AWxBP1gMLgcMUs ?
<apw> TheDrums, if i am reading that right it is an X backtrace from the x ddx driver for fglrx rather than the binary driver, #ubuntu-x might be able to help
<TheDrums> apw: OK, thanks.  It's the log from /var/log/lightdm/ since it of course failed to start.  Just been using last saucy kernel for now.
<miseria> "causa: vivir en la gloria; efecto: fomentar la pobreza: fin: morir de hambre. mision: destruir nuestro planeta" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<faqih_dan_kucing> Hello, have another build kernel atom for ubuntu ?
#ubuntu-kernel 2014-03-09
<SacredSkull> Hello
<SacredSkull> just joined to ask if anyone was having an issue with 3.5.0-47-generic (13.10) ?
<SacredSkull> I'm getting a root device timeout
<SacredSkull> works fine when swapped down to 46 via grub
<miseria> "disfrutamos hablando siempre de lo malo de los demas, pero nos duele en el alma cuando hablan mal de uno mismo" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2015-03-02
<smb> tseliot, Hey, we had been a look at bug 1426492 this morning as this has a ugly bus error in the logs. I just tried but could only confirm the problem of producing false crash reports issues, which actually seems to be a dkms one
<ubot5> bug 1426492 in nvidia-graphics-drivers-340 (Ubuntu) "nvidia-340 340.76-0ubuntu1: nvidia-340 kernel module failed to build" [High,Confirmed] https://launchpad.net/bugs/1426492
<smb> tseliot, Have you heard of any other "bus error" breakage or might that way of failing be a one off
<tseliot> smb: no, I haven't heard of it but DKMS seems to fail at random, or rather report failing even when it doesn't (LP: #1268257)
<ubot5> Launchpad bug 1268257 in nvidia-graphics-drivers-331-updates (Ubuntu) "nvidia-331-updates 331.38-0ubuntu3: nvidia-331-updates kernel module failed to build, with only error: "objdump: '... .tmp_nv.o': No such file"" [High,Triaged] https://launchpad.net/bugs/1268257
<smb> tseliot, Right, that is the way I see often enough and looks to be dkms' fault for using exec in the middle of /etc/kernel/postinst.d/dkms
<smb> Basically one attempt fails because the headers are not done, yet. then the next one succeeds and you get a crash report while everything is shiny
<tseliot> oh
<tseliot> smb: I think it's desirable to catch any failures though
<smb> tseliot, Adam had spotted this. Well but exec ends the current script, doesn't it?
<tseliot> yep
<smb> What we want is the error message about headers missing and probably not error the postinst for that special case
<tseliot> yes, I've just noticed
 * tseliot nods
<smb> tseliot, We should use one of those nvidia dkms fail reports to actually fix the dkms problem (which I see even in Trusty). I just was not sure whether the one with the bus error was "suitable"
<tseliot> smb: I think we have more than enough duplicates of 1268257 to make a point ;)
<smb> tseliot, I bet. :) Any of those you would prefer. That other one you mentioned is for 331.113... that be U or before.
<smb> Maybe I should open a new report against dkms and we can dup the nvidia ones against that as we see fit
<tseliot> smb: that would work too
<smb> tseliot, ok, so here we go ... bug 1427175
<ubot5> bug 1427175 in dkms (Ubuntu) "dkms postinst should handle missing headers" [Undecided,New] https://launchpad.net/bugs/1427175
<tseliot> smb: great, thanks. I'll also talk to upstream about it
<smb> tseliot, Ok, sounds good
<smb> bjf, sforshee, I think patch#3 which was sent for bug 1410852 really has some issue. Just did a backport myself which would not remove a function. Would it be enough to re-submit just that one or should I send all three again (which I just used for a test build)
<ubot5> bug 1410852 in linux (Ubuntu Trusty) "restarting container with a vlan interface results in kernel stack trace" [Medium,In progress] https://launchpad.net/bugs/1410852
<bjf> smb, do all 3 so it's all clear
<smb> bjf, ok. ack
<smb> bjf, sforshee, kamal, Ok, sent... of course with another (though slightly minor) glitch. Maybe if you apply it, maybe you can drop the OCD drop of that additional newline
<bjf> apw, so just how broken _is_ ipv6?
<bjf> apw, completely or only for certain cases?
<apw> bjf, as broken as it was last time, exploding at random several times a day
<apw> bjf, remember stgrabers issue ?
<bjf> apw, no
<apw> we had a bad backport in stable of an ipv6 sizing patch, which was triggering bangs on mapped ipv4 addresss
<bjf> apw, i'm trying to decide if it warrants a respin to fix this one issue or wait for the SRU cycle which starts today
<apw> kamal, what did we do last time, did we respin for it then ?
<apw> bjf, its pretty serious if you have ipv6 enabled and you are a server
<stgraber> last time I had to wait for two kernel updates (about a month) to get a fix
<stgraber> which meant reverting to a kernel with a known security issue on public facing machines...
<bjf> apw, sounds like a respin
<apw> oh we clearly don't care about you :)
<apw> stgraber, ugg
<kamal> iirc, we fixed and released it promptly, once the problem had been identified
<bjf> kamal, you did such a fantastic job last week ... :-)
<kamal> ... someone else doesn't want a turn?
<bjf> kamal, i'd be happy to do it
<apw> sforshee, anyhow i've written that up in the bug ... sigh ... i guess we need to apply it ... again
<bjf> will have to respin hwe-trusty as well
<kamal> bjf, I'm swamped (with the *other* IPv6 issue, among other things) ... if you want to take this one, that would be great.
<bjf> kamal, not a problem. i'll take it
<bjf> apw, i should just revert the second one and spin right?
<stgraber> kamal: previous bug was reported on the 20th of December, fixed on the 6th of January and released to -updates on the 2nd of February, you and I have a different definition of "promptly" :)
<apw> bjf, yeah that is the more correct version
<apw> stgraber, i don't think we were engaged with it till much later, when we started looking at it, it was quick (for us) from there
<apw> i blame those christmas things
<bjf> stgraber, we would have loved to have gotten to it quicker but were forced to take shutdown days ... so sorry
<stgraber> oh yeah, the whole 20th of December till early January was totally expected due to company shutdown :) It's just that to me a month doesn't really qualify as "promptly" :)
<stgraber> anyway, enough complaining for today :)
<bjf> sforshee, you want to do a quick respin of trusty and hwe-trusty? would be good practice :-)
<sforshee> bjf: well *want* might be a strong word, but I'm willing ;-)
<bjf> sforshee, it's yours to do. 
<bjf> sforshee, this should not be an ABI bump
<sforshee> bjf: ack
<gchao_> Hi
<gchao_> Is there someone who knows about kernel crashes? XD
<apw> gchao_, if you have a kernel crash, file a bug as that will get the requsite info from your machine
<gchao_> hi apw! thanks for the response
<gchao_> so filing a bug is standard procedure even if I'm just troubleshooting?
<apw> gchao_, if you want help from outside it is easiest to see things like the crash stack as they are large
<apw> if you have one you could pastebin it too, and someone might have ideas
<apw> as people are on varying timezones it is hard to keep abreast of the whole story if it isn't all in one place and the bug is a good place for that
<gchao_> The thing is - I don't even get a crash stack (the one under /var/crash/ ?) I was trying to use crash to debug it but nothing is there. A real "crash" never occurs, but it gets stuck in an endless panic loop
<gchao_> and seems to ignore the magic button.
<gchao_> magic key*
<apw> gchao_, that is tricky, can you get a photo of the errors perhaps when they start?
<apw> some kind of hint might tell someone enough to help
<pepee> I'd try using netconsole
#ubuntu-kernel 2015-03-03
<infinity> stgraber: You around?
<infinity> stgraber: If you have a reproducer the for ipv6 bug that's better than "wait 48 hours and see if my machine is still up", I'd love to have you test the kernels in the PPA quick-like, so we can turn them around ASAP.
<stgraber> infinity: I wish I did but no, the bug usually triggers within 24h of boot here. Even knowing the fix, hitting the actual codepath is kinda hard.
<stgraber> I can boot the kernel from the PPA now to at least confirm it's not any worse
<infinity> stgraber: Sure.  Given that we're 99.9% sure that 2-line revert is the right fix, I'd rather push it out quickly than wait for a long test cycle.
<infinity> bjf: You haz opinions on that?
<stgraber> yeah, I can certainly agree with that
<bjf> infinity, take a deep breath and push
<infinity> bjf: Good, we all agree, that means I'm only going to claim 33% of the blame when it goes wrong.
<bjf> infinity, i just blame sconklin
<infinity> bjf: But please do find suckers to do install/reboot smoketests of amd64/i386 for both trusty and lts-trusty before I push.
<infinity> bjf: They're all built (just waiting on lts-trusty/armhf)
<stgraber> I'm installing amd64 now
<stgraber> Linux athos 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<stgraber> so it boots fine at least
<infinity> stgraber: Shiny.  Was that trusty?
<stgraber> it was, yes
<infinity> stgraber: Mind snagging lts-trusty and just installing it with dpkg and rebooting that too?
<infinity> stgraber: Assuming its deps are satisfied in trusty, but I think they should be.
<stgraber> booting now
<stgraber> Linux athos 3.13.0-46-generic #77~precise1-Ubuntu SMP Mon Mar 2 23:24:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<infinity> \o/
<infinity> stgraber: Thanks for that.  Releasing trusty now, lts-t when it's done building.
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 10th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<cmagina> it appears that the utopic kernel did not get the fix for bug 1426043, so as of right now utopic will also not boot on arm64 boards
<ubot5> bug 1426043 in linux (Ubuntu) "kernel 3.13.0-46.75 fails to boot on arm64" [High,In progress] https://launchpad.net/bugs/1426043
<cmagina> vivid is the only one that already had the fix
<cmagina> well, not right now, but when the last sru kernel was released
<sforshee> cmagina: utopic will getting the fix from upstream stable in the sru cycle which starts this week
<cmagina> sforshee: ok, so when does that kernel release?
<sforshee> cmagina: in 3 weeks, give or take
<cmagina> sforshee: is that kernel available in proposed already?
<sforshee> cmagina: no, it will get uploaded tomorrow, then it will get copied to proposed when it finishes building
<cmagina> sforshee: one last question, is vivid-proposed using the 3.19 kernel?
<apw> cmagina, v3.q
<apw> cmagina, v3.19 is already in vivid release pocket
<cmagina> apw: ok, cool, thanks. just wanted to be sure that was not my problem with booting it on an arm64 board. must be something else then
#ubuntu-kernel 2015-03-04
<bjf> cmagine, i'm pretty sure we asked if we need to only fast track Trusty and was told yes
#ubuntu-kernel 2015-03-05
<kees> does anyone know how ppc64el handles CONFIG_COMPAT? it seems to have the ability to handle 32-bit syscalls, but I see no mention of CONFIG_COMPAT in defconfigs
<kees> oh, but it's in the Kconfig. nevermind!
<infinity> zequence: LP: #1427850 <--- That time again.
<ubot5> Launchpad bug 1427850 in Kernel SRU Workflow "linux-lowlatency: 3.2.0-78.80 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1427850
<infinity> zequence: Oh, and you've already done it.
<infinity> zequence: Way to be proactive; ignore me.
<MegaBrutal> Hello! When will 3.16.0-32-generic be released?
<bjf> MegaBrutal, it will hit -updates in approx. 2 weeks
<bjf> MegaBrutal, it will be in -proposed sometime today
<MegaBrutal> bjf: 2 weeks? Why does it take so long? Can you link some info about the Ubuntu kernel release cycle? (I was searching the Ubuntu wikis, but didn't find a table about the planned release dates or so.)
<bjf> MegaBrutal, it goes through testing and bug verification before -updates
<MegaBrutal> Can I help with that somehow?
<bjf> MegaBrutal, you can install the kernel when it hits -proposed and if there are any regressions file bugs against it
<bjf> MegaBrutal, https://wiki.ubuntu.com/Kernel/Handbook
<bjf> MegaBrutal, i haven't read that for some time so i'm not sure exactly what you are looking for is in there
<MegaBrutal> bjf: Actually, I expect it to fix Launchpad 1396889. This commit will do the magic: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-utopic.git;a=commitdiff;h=665cd5467479366d98930108db392a0785bf765a;hp=ce1161dde994bafe05f749f64c31904699239889 - but it will only appear in 3.16.0-32-generic, if I'm correct.
<ubot5> Launchpad bug 1396889 in linux (Ubuntu) "[Lenovo ThinkPad T400] kexec reboot fails" [Medium,Triaged] https://launchpad.net/bugs/1396889
<MegaBrutal> bjf: Btw, thanks for all the info! :)
<bjf> MegaBrutal, i'm looking but i don't see that fix in our utopic tree
<bjf> MegaBrutal, oh, one sec ... let me refresh my git tree
<bjf> MegaBrutal, the commit you reference in that bug has been in the Utopic kernel since the first 3.16.0-22.29 (and earlier)
<bjf> MegaBrutal, ignore me ... i'm still not awake
<MegaBrutal> bjf: Which commit? The one which introduces the bug, or the one which fixes it?
<bjf> MegaBrutal, yeah, i was looking at the bad commit not the fix
<bjf> MegaBrutal, so i'm on the same page now
<bjf> MegaBrutal, when the kernel hits -proposed the associated bug, which you created, will get "spammed" with a request to test and verify the fix. we expect you to do that.
<bjf> MegaBrutal, so, like i said it should hit -proposed today and you can test tomorrow and then follow the directions in the bug on how to mark it "verified"
<MegaBrutal> bjf: OK. But how Launchpad (or the team) will know that -32 will fix my bug? Sorry if it's a silly question, but the fix was merged under an entirely different LP report, and I don't see a connection. It seems like the fix was merged completely unrelated to my record.
<bjf> MegaBrutal, ah! in came in via a stable release. i should have noticed that. in that case there is nothing for you to do. if it fixes your problem then you can just mark the bug as "Fix Released" or ping me and i'll do it
<bjf> MegaBrutal, however, if you still have problems come back here and ping me or someone else on the kernel team and we'll look into it more
<zequence> infinity: Sometimes it happens
<MegaBrutal> bjf: Anyway, could you help me to triage 1423796? (Not sure it you're in charge for it, since it's not a kernel issue.)
<MegaBrutal> Why doesn't the bot look up the number? Simon says Launchpad 1423796!
<ubot5> Launchpad bug 1423796 in lvm2 (Ubuntu) "Unable to mount lvmcache root device at boot time" [High,Confirmed] https://launchpad.net/bugs/1423796
<MegaBrutal> Nah! :)
<bjf> MegaBrutal, if you had put "bug " or "lp " and then the bug #, the bot would have detected it
<bjf> apw, ^ that bug looks interesting
<apw> bjf, yeah, that deffo needs kernel side config for the initramfs changes, and likely initramfs-tools change for the other
<apw> as i am about to do the merge for that ... i'll poke it
<bjf> MegaBrutal, ^ there you go :-)
<MegaBrutal> bjf, apw: Wow, thank you! :)
<MegaBrutal> bjf, apw: Sorry for my lots of questions, but do you know what is Canonical IS department? In bug 1376088, I've been informed, they've opened a ticket there, and nothing has happened since then.
<ubot5> bug 1376088 in ubuntu-release-upgrader (Ubuntu) "No IPv6 address for changelogs.ubuntu.com" [Medium,Triaged] https://launchpad.net/bugs/1376088
<apw> MegaBrutal, yep that really is the ops people for the ubuntu.com department, that is being referred to
<apw> MegaBrutal, do you have a special need for that service over ipv6?  as they are slowly over time adding ipv6 in general to external services
<didrocks> hey apw, I have an overlayfs question for you (probably a stupid one)
<didrocks> remember the "is_path_is_mountpoint()" for systemd?
<didrocks> so, I'm trying to special case overlayfs for the simple use case I have as we discussed
<didrocks> meaning, I need to know if this path is referencing a file on overlayfs
<didrocks> I'm getting the file fd, then fstat it, -> st_dev -> getting the fspath with blkid -> probe -> get "TYPE" value through blkid
<didrocks> this all works well on most of file systems
<didrocks> but blkid_devno_to_devname(st.st_dev); return nothing on overlayfs
<MegaBrutal> apw: It is not very critical for me... but imho it really wouldn't take so much for such a great company to add an AAAA record to that address. (Most Ubuntu services have IPv6 connectivity already.) Currently, an IPv6-only Ubuntu host can't do a release upgrade without an AAAA record for changelogs.ubuntu.com.
<didrocks> am I doing false track and there is a magical way easier way to detect (and so special case) it?
<didrocks> going*
<apw> MegaBrutal, that it didn't get an address when archive.ubuntu.com did implies it is somewhere that doesn't have ipv6 currently
<apw> didrocks, i find it peculiar that we don't use /proc/mounts or something to work out if something is a mount point
<apw> MegaBrutal, but i do know the intent is to spread ipv6 around everything
<MegaBrutal> apw: archive.ubuntu.com has 2 addresses within 2001:67c:1360:8c01::/64. The upgrader first checks changelogs.ubuntu.com to verify whether there is an upgrade. Only then it turns to archive.ubuntu.com to actually download packages. So changelogs.ubuntu.com not having an IPv6 address is a single point of failure in a release upgrade.
<apw> MegaBrutal, i am not disputing that it is needed for ipv6 only systems, not that it is likely these things will be common at the current time
<didrocks> apw: so, you would just map if the file is a mount point matching the path to /proc/mounts?
<apw> didrocks, i am trying to work out why that isn't appropriate
<didrocks> apw: yeah, I have no idea, apart from perfs maybeâ¦
<apw> i guess you could fall back to that slow path when the normal one says it is a mountpoint
<MegaBrutal> apw: OK-OK. Anyway, you could also check LP 1396213 and LP 1391429 too. If you found the lvmcache stuff interesting, you'll probably like these too. :)
<ubot5> Launchpad bug 1396213 in lvm2 (Ubuntu) "LVM VG is not activated during system boot" [High,Confirmed] https://launchpad.net/bugs/1396213
<ubot5> Launchpad bug 1391429 in linux (Ubuntu) "grub-probe takes snapshot LV instead of origin" [Medium,Triaged] https://launchpad.net/bugs/1391429
<didrocks> apw: or maybe fallbacking if parent dir major is 0?
<apw> didrocks, yeah
<didrocks> sounds sane enough, I'll give it a try, thanks for the advice apw :)
#ubuntu-kernel 2015-03-06
<stepjohn> I've just checked out the kernel source from git and there isn't debian/patches dir. Where are the custom kernel patches stored for the ubuntu kernel?? Am I wrong in thinking that you patch the kernel?
<diwic_> stepjohn, patches are applied to the kernel, but as git commits, not as added files in debian/patches
<stepjohn> diwic_: Arrrrr OK now I totally get it 
<stepjohn> diwic_: branch apply patch, update changelog, tag , build 
<alexbligh1> Am I correct that CVE-2015-0239 / usn-2516-3 per http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-0239.html is fixed in the HWE kernel for trusty (i.e. linux-image-generic-lts-utopic) in 3.16.0-31.41~14.04.1 which (despite what it says on the page) is not released, the latest version being 3.16.0.31.24? If so, when would one expect 3.16.0-31.41?
<alexbligh1> I'm confused as it appears to be in utopic-security but not precise
<henrix> alexbligh1: where do you see that 3.16.0-31.41 isn't yet released?
<alexbligh1> henrix, http://packages.ubuntu.com/trusty-updates/linux-generic-lts-utopic and 'apt-get update'
<henrix> alexbligh1: you're looking at the -meta package.  here's the correct link: http://packages.ubuntu.com/trusty-updates/kernel/linux-image-3.16.0-31-generic
<alexbligh1> henrix, thanks - all very peculiar. I better find out why it's not installing then
<alexbligh1> henrix, a fresh install this morning didn't pull it in.
<henrix> alexbligh1: after the 'apt-get update', a 'apt-get dist-upgrade' should do the job
<alexbligh1> henrix, we used 'aptitude full-upgrade'. I'll try that too. It's also not appearing in a debootstrap build. Something odd is going on.
<infinity> alexbligh1: It's been upgraded just fine.
<infinity> alexbligh1: If you have linux-generic-lts-utopic 3.16.0.31.24, that depends on linux-image-3.16.0-31-generic
<alexbligh1> infinity, henrix: DaGoaty and I are currently working on a PEBCAK error
<infinity> alexbligh1: You can't have one without the other.
<alexbligh1> henrix, infinity sorry for the noise. Looks like what happened was we expected an update as of the CVE date, but it would appear we'd already got the update earlier. Then we looked at the meta package version not the image version when we didn't see another update. Sigh.
<henrix> alexbligh1: no prob!
<tinoco> hey guys
<tinoco> oops wrong #
<slangasek> smb: hi - question regarding nfs kernel interfaces
<smb> slangasek, you may try your luck...
<slangasek> smb: after switching to the nfs-utils systemd units, I noticed that rpc.idmapd wasn't being started on clients, only on servers; it turns out that, according to upstream, it's superseded by an upcall to /usr/sbin/nfsidmap
<slangasek> smb: can you help me figure out what kernel introduced support for this upcall?  I know that it was there at least in Linux 3.5 (http://serverfault.com/questions/415908/nfs4-rpc-idmapd-or-nfs-idmap-upcall)
<slangasek> that's obviously enough to cover us for LTS upgrades, but in the unlikely event that we had someone wanting to support NFS on an android kernel :P, I'd like to know what our story is
<smb> slangasek, I can try... give me a few minutes
<slangasek> smb: cheers
<smb> slangasek, So it seems the "new" method was introduced (added to Documentation/filesystems/nfs/idmapper.txt) with 2.6.37. However for a while (until 3.4) it required an option (NFS_USE_NEW_IDMAPPER) to be set at compile time. Which we did not do in Precise (3.2). Starting with 3.4 this was replaced by making new the default but automatically fall back (e6499c6f4b5f56a16f8b8ef60529c1da28b13aea NFS: Fall back on old 
<smb> idmapper if request_key() fails)
<smb> slangasek, Is that enough to help you?
<slangasek> smb: yes, thanks
#ubuntu-kernel 2015-03-08
<pepee> hi. can someone please tell me how to suggest a patch from upstream that, apparently, hasn't yet been merged in any kernel in ubuntu?
<apw> pepee, email it to the kernel-team@ list ... and likely file a bug too with all the details
<pepee> apw, there are a few bug reports already related to the patch, this is one of them:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313804
<ubot5> Ubuntu bug 1313804 in linux (Ubuntu) "[HP Pavilion dv6-6145eo Entertainment Notebook PC] Laptop display does not turn back on after resuming from suspend" [Low,Incomplete]
<pepee> apw, thing is, I'm not sure that it hasn't been merged, but I read some kernel changelogs and there is no mention of the patch
<apw> pepee, well what is the sha1 for the fix, that we can track
<pepee> not even the kernels in the mainline repos have the patch... AFAIK
<pepee> no mention in the CHANGES files
<pepee> apw, https://bugs.freedesktop.org/show_bug.cgi?id=42960#c57
<ubot5> Freedesktop bug 42960 in DRM/Radeon "Display does not work when resuming from suspend" [Major,Resolved: fixed]
<pepee> comment 63:  fixed in:  66c2b84ba6256bc5399eed45582af9ebb3ba2c15
<pepee> err, the only kernel that has the fix is 4.0-rc1
<pepee> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-rc1-vivid/CHANGES  ->  "drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary"
<henrix> pepee: that commit has been tagged for stable kernels, so it will hit our kernels soon
<pepee> henrix, ah, k, thanks
<henrix> pepee: actually, the 3.16 stable kernel already has that commit queued, so it should be in utopic kernel in the next SRU cycle (a couple of weeks from now)
<pepee> I'm using -proposed 3.16 in 14.04, but the fix doesn't appear in apt-get changelog
<pepee> ok, thanks apw , henrix 
<apw> what henrix said indeed
<pepee> tyvm, I'll wait for it and leave a comment in the bug report
<kjbsoabga> did usa & israel covertly supply isis with weapons like they did with al-qaeda to justify wars ?
<kjbsoabga> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosion with uncertain responsibles to make people fight?
<kjbsoabga> how many human was killed because usa actions included in the creative mess?
<kjbsoabga> i was prevented on facebook and twitter, so plz send my qs there to help limiting usa & israel aggression against others.
#ubuntu-kernel 2016-03-07
<manjo> rtg, I have a cust asking what the kernel version in 16.10 might be... 4.7 perhaps ? 
<manjo> apw, ^ ?
<apw> manjo, tends to be 2-3 later, so 4.6/4.7 is a believable answer, we tend to be more speculative on an lts + 1
<manjo> apw, ok cool I will tell them 4.7 is the best guess for today 
 * xnox read that as "more spectacular" instead of "speculative"
<apw> i think you mean awsome
<manjo> apw, yeah they are trying to figure out what the hwe kernel for 16.04.2 migh be because their platform will be certified with that kernel. 
<manjo> apw, and they have a few kernel patches to upstream
<apw> manjo, understnadable, but its too early to be sure
<xnox> apw, could you update https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1543165 ?
<ubot5> Launchpad bug 1543165 in linux (Ubuntu) "kernel: update kernel configuration" [High,Triaged]
<xnox> is it done / not done?
<apw> xnox, it is not done, it is on my list for today/tommorrow thoug
<apw> though
<apw> not that there is a whole heap of today left
<xnox> ack. tah.
<jtaylor> is there a chance bug 1248289 can at least be fixed for 16.04?
<ubot5> bug 1248289 in linux (Ubuntu) "Missing libunwind support in perf" [Medium,Confirmed] https://launchpad.net/bugs/1248289
<jtaylor> its just missing build depends and maybe a small change to a makefile
<jtaylor> bug 1396654 is probably a dup
<ubot5> bug 1248289 in linux (Ubuntu) "duplicate for #1396654 Missing libunwind support in perf" [Medium,Confirmed] https://launchpad.net/bugs/1248289
<jtaylor> oh already marked, I'm blind
<apw> jtaylor, are you saying all we need is your patch in the lsat comments ?
<apw> debian.master/control.stub.in: libunwind8-dev [amd64 arm64 armhf i386 powerpc ppc64el] <!stage1>,
<apw> oh it is libbfd-dev is it ... hmmm
<jtaylor> apw: I'm not sure if yuo need it in xenial, I needed on trusty
<jtaylor> might have been an older perf version
<jtaylor> let me just try if its still required in trusty
<jtaylor> apw: still is required on trusty
<jtaylor> apw: but interestingly it appears to not be needed in xenial
<apw> jtaylor, odd
<jtaylor> probably some binutils updates
<jtaylor> --as-needed does have some bugs
<jtaylor> might have been fixed in the meantime
#ubuntu-kernel 2016-03-08
<rkoornstra> question. In the kernel source I do see this: drivers/gpu/drm/i915/intel_guc_loader.c I see this define: 
<rkoornstra> define I915_SKL_GUC_UCODE "i915/skl_guc_ver4.bin"  However, in lib/firmware I see: /lib/firmware/i915/skl_guc_ver1_1059.bin  It seems linux-firmware doesn't come with the bin file it expects
<rkoornstra> should this be updated?
<tjaalton> rkoornstra: xenial has skl_guc_ver4_3.bin
<tyrog> Hi, what will be the default Kernel for Ubuntu 16.04 LTS?  4.4 or 4.5? Tnx
<tyrog> Because 4.5 will be released next week, more than a month before the final release of 16.04
<ogra_> 4.4
<ogra_> (4.4 is a long term support release, so it fits the 16.04 LTS scheme)
<tyrog> ogra_: tnx
<lamont> jsalisbury: good kernel, btw.  1543683 updated, can I expect that to be in the next kernel>?
<lamont> as in, can I re-install linux-image-generic and expect no regression?
<apw> lamont, almost cirtainly not :)
<apw> LP: #1543683
<ubot5> Launchpad bug 1543683 in linux (Ubuntu Xenial) "Fails to detect (second) display" [Medium,Confirmed] https://launchpad.net/bugs/1543683
<apw> lamont, as the next kernel is already in teh pipeline, so this is likely to hit the next one
<lamont> apw: right.  so stall a couple weeks, and check the bug status, and then if it's closed, I'm good?
<apw> yeah, your kernel should be 2-3 weeks out in -proposed
<apw> lamont, though i am sure jsalisbury will spin you a kernel in the middle with your bits on top
#ubuntu-kernel 2016-03-09
<lamont`> jsalisbury: updated 1543683 with a zomfg what have they done comment
<lamont`> because, no, randomly shoving all my windows around just because I locked the screen is not acceptable at all
 * lamont` will be downgrading again
<marlinc> Test
<apw> marlinc, works
<lamont> jsalisbury: I hate your kernel
 * lamont downgrades so that X doesn't decide to randomly move windows around everytime he locks the screen.  Or at least to confirm that it's because of the kernel
<apw> lamont, the kernel moves your windows, that seems unexpected, especially on a lock of the screen
<apw> its not like the kernle has any concept of windows at all
<apw> so it'd have to turning an output off or something on lock
<lamont> apw: I believe it's deciding that I'm single-headed
<lamont> OTOH, I propose to test that theory momentarily
<apw> lamont, does the external display turn actually off when you hit lock
<apw> that seems wrong to me, you could try xset dpms force on or something
<lamont> apw: the bug in question relates to the second display being not detected, and a patch to make it maybe work better
<lamont> and yeah, with 4.4.0-6.21~lp1543683Commit237ed86cReverted, the windows stay on the correct displays.
<lamont> apw: I'll make some time later today to test that theory better.
<lamont> jsalisbury: can I also get a 4.4.0-9.24~lp1543683Commit8d409cb minus the cherrypick and 237ed86c reverted to confirm it's truly just the display patches?
<apw> lamont, there is um HEAP of change on the -12 in DRM so it is also worth testing that if you have a window
<apw> especially if you have broadwell or later
<lamont> this is i915
<apw> right, but what serie,s i have i915 broadwell which is meant to be better with -12
<apw> not that i have it yet :)
<lamont> where would I see that?
<lamont> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
<apw> erm :)
<apw> 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
<apw> ok apparently you have something else
<lamont> agreed
<jsalisbury> lamont, I'll review the latest updates to the bug
<jsalisbury> lamont, and I'll build the kernel you asked for in the scroll back
<lamont> jsalisbury: woot
<lamont> known is 4.4.0-6-reverted: windows stay on the right display.  4.4.0-9-patched: windows migrate on lock
<lamont> I'd like to isolate that better
<jsalisbury> lamont, ack
#ubuntu-kernel 2016-03-10
<rbasak> apw: around? We're testing some upgrade paths for MySQL from Trusty to Xenial, and may be impacted by the "from" kernel version because I don't think the original Trusty kernel supports Apparmor on Unix sockets.
<rbasak> apw: we'll test this path, but we also want to test the Precise->Trusty->Xenial path.
<rbasak> apw: so the question is: do you know the set of kernels users can end up with on upgrading from Precise to Trusty?
<apw> rbasak, that sounds about fair analysis of the trusty -release kernel
<rbasak> apw: will they always end up with the Trusty non-HWE kernel, or is there a case where a user upgrading from Precise could end up with an HWE Trusty kernel?
<apw> rbasak, in theory all hwe kernels upgrade to the release kernel in the following LTS if we have done our meta-packages right
<rbasak> That's great. We'll check to be sure, but hopefully this will help reduce our test matrix, because then our Precise->Trusty->Xenial test will cover the Trusty -release kernel to Xenial case too.
<rbasak> Thanks!
<apw> rbasak, and yes during upgrade you run the old kernel the entire time, until the upgrade completes, so you do expect some issues until you reboot
<rbasak> Got it. Thanks!
<apw> i wonder if we support upgrading P->T->X without a reboot at T
<apw> i'd really hope not
<rbasak> I expect not. I'm not worried about that case.
<rbasak> Our reason for testing P->T->X is really the state in /var/lib/mysql etc.
<rbasak> But it also nicely covers the T -release kernel -> X case so we don't need to independently test that in theory.
<rbasak> Given that we're testing P->T->(reboot)->X
<rbasak> P->T->(reboot)->X->(reboot) I suppose.
<Skuggen> I'll do the upgrade from Precise to Trusty then, and verify that it has 3.13
<Skuggen> Thanks :)
<apw> of course that ship has sailed if we got it wrong
<Skuggen> It does say a restart is required, at least, after going from Precise to Trusty :)
<Skuggen> And now I'm on 14.04.4 with kernel 3.13.0
<caribou> Will any other release receive the 4.4+ kernels other than Xenial ? The crash tool fails to load these so I'm fixing it
<rtg> caribou, the last 14.04 point release (14.04.5 ?) will have the Xenial kernel.
<caribou> rtg: ok, I'll SRU the fix to Trusty as well
#ubuntu-kernel 2016-03-11
<Madkiss> hi folks
<Madkiss> sforshee: are you online? :)
<Madkiss> sforshee: i'm looking for the header packages for http://people.canonical.com/~sforshee/lp1505948/
<sforshee> Madkiss: let me see if I still have them
<Madkiss> that'd be superawesome :)
<sforshee> Madkiss: I have the _amd64.deb package but I never actually built the _all.deb package
<sforshee> anyway, I copied what I have to that same location
<Madkiss> Okay. I've tried to apply the two patches to 4.4.5, but the second one fails.
<Madkiss> patching file fs/fuse/fuse_i.h
<Madkiss> Hunk #1 FAILED at 24.
<sforshee> Madkiss: mine was based on our xenial tree, I think 4.4.4 was the latest we had applied but we also have extra patches that could maybe account for the differences
<Madkiss> most likely. I also tried to apply against 4.2-wily and that failed for the same reason. Is there a way I can get the source you used for your build?
<sforshee> definitely. It's at https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial, my build was based on the Ubuntu-4.4.0-11.26 tag
<Madkiss> thanks
<Madkiss> IOCB patch. ahum.
<Madkiss> sforshee: you don't happen to have the source tree still available, right?
<mamarley> Hmm, 4.4.0-12.28 seems to have disappeared from Proposed in Xenial.
<sforshee> Madkiss: I still have the source, yes
<Madkiss> fakeroot debian/rules binary-headers <= should give us the debs we're looking for, no
<Madkiss> ?
<apw> mamarley, its prolly on its way to -release, it dissappears in launchpad's view for a bit during that though it is always published in the archive proper in one or the other at all times
<Madkiss> apw: we fixed the fuse bug ;)
<Madkiss> or rather, Robert Doebbelin did.
<apw> Madkiss, nice ... do you have a pointer to the fix ?
<apw> rtg, ^ we might want to consider this for your -13
<mamarley> apw: Ah, OK.  Thanks!  I was wondering if it might have something to do with 4.4.5 that had just been released.
<Madkiss> apw: sforshee already has it
<Madkiss> http://people.canonical.com/~sforshee/lp1505948/
<sforshee> Madkiss: I'll build the header package for you, I'll let you know when it's done
<Madkiss> sforshee: thanks a bunch
<apw> sforshee, are those ready for primetime, or is testing still on going ?
<sforshee> apw: depends on how aggressive you want to be. I was going to send them upstream today after I test build on 4.5.
<apw> sforshee, ok sounds good, rtg ignore me
<sforshee> Madkiss: both the header packages are there now
<Madkiss> excellent, thanks!
<Madkiss> Okay. It looks like these do not work OOTB on Trusty systems with DKMS-enabled modules (because gcc 4.9 is required)
<apw> Madkiss, that is a xenial kernel, so yeah the dkms issues have not yet been worked out
<Madkiss> What's the correct way to get these patches into the lts kernel for trusty?
<apw> into the lts-xenial kernel ?  that will occur naturally, if you mena another one, then we need to get that info added to the bug (if not there already) so we remeber to do that
<Madkiss> linux-signed-image-generic-lts-wily in 14.04 is the one I mean
<apw> right so you want it in the wily family, so sforshee needs to submit those for sru once they are safe enough to get into xenial
 * Madkiss starts crying
<apw> Madkiss, heh, grinding out patches takes time ... though i am sure sforshee could make you an lts-wily with them applied too
<apw> for testin
<Madkiss> i'm already on it
<Madkiss> arrr
#ubuntu-kernel 2016-03-13
<mwhudson> am i confused or does the ubuntu kernel not include cpufreq_stats?
<mwhudson> oh http://askubuntu.com/a/577282
#ubuntu-kernel 2017-03-06
<LocutusOfBorg> hello apw, do you mind merging this? https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=bcdf0a6d1924367b99cf5c30b5f0e8f9bd0cb079
<LocutusOfBorg> background story: LP: #1669807
<ubot5> Launchpad bug 1669807 in linux (Ubuntu) "Allow Unity8 to run inside Virtualbox" [High,Incomplete] https://launchpad.net/bugs/1669807
<apw> LocutusOfBorg, will the next update to the dkms package contain that too ?
<apw> LocutusOfBorg, oh it already does, so you want that resync'd ... ok
<LocutusOfBorg> yeah
#ubuntu-kernel 2017-03-07
<ricotz> rtg, hi, I noticed the "Ubuntu-hwe-edge-4.10.0-9.11_16.04.2" tag but afaics there is no uploaded package
<rtg> ricotz, it is still in the CKT PPA
<rtg> ppa:canonical-kernel-team/ppa
<ricotz> rtg, hmm, no it isnt, that is why I am asking ;)
<ricotz> sorry, wrong tag, I meant "Ubuntu-lts-4.10.0-11.13_16.04.1"
<ricotz> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=hwe-edge
<rtg> ricotz, hwe-edge tracks the kernel that is in the Zesty release pocket. I won't upload again until the next Zesty kernel in proposed is promoted. In the meantime I'm getting the current hwe-edge kernel reviewd and (hopefully soon) promoted to the Xenial archive
<ricotz> rtg, I see, so despite it was tagged there was no actual upload?
<rtg> ricotz, nope, I was probably on autopilot at the time
<ricotz> rtg, ok
<ad-n770> good morning, I'm reading at zesty release notes (https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes) that kernel 4.9 is referred but seems that master branch at git://kernel.ubuntu.com/ubuntu/ubuntu-zesty does build kernel 4.10.0
<apw> ad-n770, that would have been for a beta or something, it is going to be a 4.10
<apw> the release notes are a live thing as we move through the varous phases
<ad-n770> that's good
<ad-n770> I'd would like to use 4.10 earlier in some ubuntu 16.04 systems, I mean before 16.04.3 hwe 
<ad-n770> there's any trick to install the zesty kernels into 16.04 systems that I could use ?
<ad-n770> or I should build my own package under 16.04 instead ?
<rtg> ad-n770, there is an hwe-edge kernel at ppa:canonical-kernel-team/ppa that is v4.10 based
<ad-n770> mmm, given that I'm going to push this kernel package in some production systems I think that I want to have a much tighter control on the what is exactly installed
<ad-n770> so probably I will go by building the kernel myself
<ad-n770> should be enough to build from git in 16.04 or do you tend to add extra patches for hwe kernels ?
<rtg> ad-n770, the only changes to hwe kernels is usually related to packaging
<apw> ad-n770, it is mostly just has the right depends for the older release, that one might have a revert or two for toolchain differences
<ad-n770> understood, thanks a lot for the information 
<rellis> kamal et al. Just wanted to let you guys know we've had the test aws kernel with 3.2.2 ixgbevf and 1.1.2 ena drivers and haven't had any issues  so far
<rellis> we have the test kernel on some r4's (use ena driver) and c3's (uses ixgbevf).. probably 10-15 hosts total now
<kamal> rellis, excellent, thanks very much for the feedback on that
<rellis> for sure, thanks very much for making the test version available in your ppa. also please don't take it away because i have a bunch of machines using it :)
<rellis> any idea when i might need to look to move from your ppa back over to the mainline linux-aws ?
<kamal> rellis, the switch to ixgbevf-3.2.2-k is still "under consideration", so honestly no I can't give any kind of projection there
<rellis> okay cool
<rellis> just thought id ask
<ad-n770> I'm not sure if I understand correctly the new rolling policy https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack
<ad-n770> does it mean that at 17.04 time the 16.04 repository will have -ga 4.4 -hwe 4.8 and -hwe-edge 4.10 ?
<ad-n770> or 4.10 will be only available for 16.04 about three months later for 16.04.3 release ?
<apw> ad-n770, i believe it means both, that -hwe-edge will be 4.10 at 17.04 release, and -hwe will be 4.10 at .3
<ad-n770> good
<ad-n770> mmm, then maybe I only need to wait a couple of months to get 4.10 availability in Ubuntu 16.04 
#ubuntu-kernel 2017-03-08
<xnox> why do we not enable swap accounting by default?
<xnox> # CONFIG_MEMCG_SWAP_ENABLED is not set
<rtg> xnox, it can be enabled on the kernel command line
<rtg> swapaccount=1
<xnox> rtg, sure, i learned that from all the docker guides. But given that we enable all the cgroups by default, shouldn't we enable swap accounting in the memory cgroup? as far as I understand without swap accounting, containers and/or systemd units can have run-away swap usage.
<xnox> whilst being under the RAM memory limits.
<rtg> xnox, I don't remember specifically, but the first line of the kernel help text is "Memory Resource Controller Swap Extension comes with its price in
<rtg>           a bigger memory consumption."
<xnox> ah, that's counter productive, isn't it =)
<rtg> other then that, I don't have any particular knowledge
#ubuntu-kernel 2017-03-09
<LocutusOfBorg> apw, please sync vbox kernel modules :p
<jcastro> jsalisbury: if you're around can we talk about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396654 ? 
<ubot5> Ubuntu bug 1396654 in linux (Ubuntu) "C++ demangling support missing from perf" [Medium,Triaged]
<jsalisbury> jcastro, sure
<jcastro> oh you're awake, I wasn't expecting that. :D
<jsalisbury> heh, yeah.
<jsalisbury> jcastro, that is an old bug
<jcastro> hey so, the vivid and utopic tags
<jcastro> if I wanted to make the case to bring this to $current_animal, how do I do that?
<jsalisbury> jcastro, you can just add the xenail, yakkety and zesty tags.  
<jsalisbury> jcastro, then probably just set the status to "New" instead of triaged or invalid
<jsalisbury> jcastro, setting it new makes it pop back up on my radar
<jcastro> do I leave the old release tags on there also?
<jsalisbury> jcastro, sure, it doesnt hurt anything
<jcastro> tags aren't the same as nominating for a series in lp are they? 
<jsalisbury> jcastro, no, the tags are just used for reports, mail filter and things like that.  Nomimating them for a series is where you would want to set the status to "Invalid" for utopic and other EOL releases
<jcastro> oh ok, we'll I messed that up, sorry, heh
<jsalisbury> that bug doesn't seem to have any nominations yet, but I can add them
<jsalisbury> jcastro, oh nevermind, you did already :-)
<jsalisbury> jcastro, I'll take a closer look at that bug today and see what can be done to resolve it.
<jcastro> hey so I wanted to convince the guy who was bugging me about it to send a patch
<jsalisbury> jcastro, I also added the tag "kernel-da-key".  That makes sure I see and read all email/comments for the bug
<jsalisbury> jcastro, yeah, if he already has a patch that would be great
<jcastro> he won't use lp or bzr though, this seems like a packaging bug, is there a git workflow?
<jsalisbury> jcastro, sure, he can use "git format-patch" and email it to the kernel-team mailing list
<jcastro> excellente, I'll encourage him to do that
<jsalisbury> jcastro, great
<jcastro> I was blindsided by "hey you guys haven't fixed this bug in 3 years" and I was like dang, at least try to ask somebody
<jsalisbury> jcastro, heh, yeah.  bugs usually expire after 6 months if there is no activity
<jcastro> right
<jcastro> also my "I thought mangled was the entire point of C++" probably didn't go over well lol. 
<jsalisbury> haha
<Vej> Hello! Could someone with knowledge about the kernel update process point Simon Davis (and me) to a resource about inclusion of that fix into the upstream stable. I run out of knowledge and manuals. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1663991
<ubot5> Ubuntu bug 1663991 in linux (Ubuntu) "Unable to Connect Third HDD via USB Hub" [Medium,Triaged]
<jsalisbury> Vej, I'll add a comment
<Vej> jsalisbury: Thank you very much!
<jsalisbury> np
<jcastro> jsalisbury: in hindsight, https://wiki.ubuntu.com/Kernel/Dev/KernelPatches is awesome
<jcastro> I wish I would have found that first
<Vej> jsalisbury: I am sorry, but that left more questions to me than clarifying things. That patch is already accepted into 4.10.1 (see https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a810007afe239d59c1115fcaa06eb5b480f876e9). Do we need to submit it again to get it integrated into  4.4.X, or will you cherry-pick/include from 4.10.1?
<jtaylor> is it possible to add some kind of automated test for bug 1396654? quite annoying having it break every few releases
<ubot5> bug 1396654 in linux (Ubuntu Zesty) "C++ demangling support missing from perf" [Medium,Incomplete] https://launchpad.net/bugs/1396654
#ubuntu-kernel 2017-03-11
<toothe> Hi all! I am trying to compile a kernel AND keep ZFS.
<toothe> When I downloaded the kernel source via apt source and compiled it, ZFS quit working
#ubuntu-kernel 2018-03-05
<TheNumb> Hi :)
#ubuntu-kernel 2018-03-06
<raidghost> apw: whats normal time on bug respond? Can it take months?
<ricotz> sforshee, hi, is there an eta for a 4.15.7 based build for bionic and xenial?
<sforshee> ricotz: I'll probably upload that to bionic-proposed in the next couple of days for bionic, less certain about xenial
<ricotz> sforshee, I see, I will go for a local build in the meantime then
<ricotz> sforshee, btw 4.15 is still the target for bionic?
<sforshee> ricotz: yes, 4.15
<ricotz> sforshee, alright, thanks
<ricotz> sforshee, minor ABI addition https://paste.debian.net/plain/1013429
<ricotz> sforshee, is it expected that the retpoline check-results are different on a xenial toolchain?
<sforshee> ricotz: that has nothing to do with retpoline, it's that a new exported symbol was added
<sforshee> and that won't be specific to building on xenial
<ricotz> sforshee, those were two notes and independent
<sforshee> oh
<ricotz> so ABI addition on bionic amd64 build
<ricotz> but the retpoline results differ on xenial e.g. building the bionic master-next tree on xenial
<sforshee> ricotz: I'm not sure about that, apw ^
<ricotz> I guess this is simple hiding this fact https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/?h=hwe-edge&id=1bd19edd819437a08c63fcfc600a7bcff0b89741
<sforshee> I won't be surprised at all that the retpoline results with one toolchain aren't comparable to those with another toolchain, I just don't know for certain
<ricotz> hmm, what is the purpose this check then?
<AlexAvadanii> hi! I see 4.15 is in https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=hwe-edge, but https://packages.ubuntu.com/source/xenial-updates/linux-meta-hwe-edge is still at 4.13, and I don't see it in proposed ... any idea when the transition will happen?
<steve667> Hi all, hope you're having a great day :D heeeeeey, got a question regarding Ubuntu 14.04 (sorry, kinda newbie). So, right now we have, on a couple of production servers, the kernel 3.13.0-142-generic, which is the latest one for it, I think. And looking for references for spectre/meltdown vulnerabilites, found that we could install the xenial kernel 4.4.0-116 for Ubuntu 14 with HWE, which includes the retpoline mitigation for varian
<steve667> t 2. So, my question is: If we need to have the three patches for the three vulnerabilities in Ubuntu 14 in a production environment, is this the way to go? installing xenial kernel with HWE? or is there a future release coming for Ubuntu 14 with the retpoline mitigation? thanks in advance for your attention and support :D
<TJ-> steve667: checking the changelog shows  "CVE-2017-5715 (Spectre v2 embargoed) // CVE-2017-5753 (Spectre v1 embargoed)" ... "- x86/asm/msr: Make wrmsrl_safe() a function"
<steve66__> :o really? was checking with the spectre checker and it said vulnerable. where can I check that changelog ? and thanks for your reply :D
#ubuntu-kernel 2018-03-07
<steve667> sorry for connecting/disconnecting, was in a couple of meetings due to that haha so, si that kernel patched to retpoline, maybe the script just didn't detected it (and since it's production, they don't let me compile the kernel by myself  so my options were: install xenial kernel on trusty if it's going to be stable or wait for a kernel release with the spectre variant 2). sorry for being obnoxius 
<steve667> hehehehe 
<steve667> Found the changelog https://launchpad.net/ubuntu/+source/linux/3.13.0-142.191
<steve667> thanks TJ :D 
<Moral_> Is there a possiblilty to submit a patch that is not upstreamed?
<Moral_> I was originally going to backport a patch, as we thought Bjorn had taken it but turns out he is running slow on patches.
<apw> Moral_, yes, it is not impossible to submit patches which are not upstream, we prefer them upstream where possible
<Moral_> Yeah, that's what I thought. I think someone on my team is  attending an Intel->ubutnu meeting next week we'll bring it up there.
#ubuntu-kernel 2018-03-08
<Martiini> where could I find kernel .config file for Lenovo z50-70
<Martiini> I'm an online kickbag asshole madafakaaa
<Suudy> It appears the retpoline patch in 3.13.0-143 prevents third party modules from being inserted.  I have a old (Clearcase) module that I have to compile on every kernel update.  But gcc-4.8.5 doesn't generate the retpoline code.  And the "noretpoline" command line option doesn't apepar to be in place.  And word on when this might be in place?  (I don't expect a backport of gcc-4.8.5 to have retpoline support).
<Suudy> Well, nevermind.  Perhaps retpoline is being backported to gcc.  https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1749261
<ubot5`> Ubuntu bug 1749261 in gcc-4.8 (Ubuntu) "Add amd64/i386 retpoline support" [Undecided,Confirmed]
<Suudy> :)
#ubuntu-kernel 2019-03-04
<bear38> arighi: Thanks for checking. So, recompiling the kernel it is in this case. Ty
<dijuremo> Hi Everyone, I am running 18.04 with kernel 4.15.0-45-generic and since the update, I am unable to log in to the virtual terminals. There seems to be an automatic carriage return being added, so I am unable to enter the password correctly.
<dijuremo> Are there any workaround or fixes for this problem?
 * apw wonders if this could be the tty EAGAIN issue
<apw> dijuremo, on the assumption you have confirmed booting back to the previous kernel fixes the issue; then there is a fix in -46 which might relate and it is worth testing that kernel (which is in -proposed right now)
<dijuremo> apw: Yes, going back fixes it. I am not sure which one was the last one that worked.
<apw> worth a try of -46
<dijuremo> I believe 4.15.0-43-generic was the last good one and both -44 and 45 have the issue.
<dijuremo> I just enable the proposed repo and install it, right?
<apw> i would only install the kernel, which should be in the canonical-kernel-team 'proposed' PPA
<bear38> Reading this conversation got me wondering. Where is the source code for 4.15.0-45 exactly? Or 4.15.0-46? I am able to find the following link, but that is for 45.48, and I have no idea waht that is. Link: https://launchpad.net/ubuntu/+source/linux-hwe/4.15.0-45.48~16.04.1
<bear38> Also FWIW virtual TTYs are working fine for me in 4.15.0-45 on 16.04 (ctrl + alt + f2). I know you are on 18.04 though.
<apw> bear38, there are tags in the ubuntu git repositories for each version exactly
<apw> 4.15.0-46 is an abi number, and the full version is alway longer; as the abi numbers are unique in the context
<apw> of the conversation it is easier to just use the short version as it is enough to identify the kernel
<apw> but it is only a partial version number, and there is a .N on the end at least
<bear38> apw: Thanks, so the official name for -45 includes the .48~16.04.1 suffix. I wasn't sure if the .48 meant it was somehow a middle build. Regarding the git repos though, I was able to find this, but am coming up dry: https://kernel.ubuntu.com/git/?q=4.15.0.45
<bear38> I'm not seeing where the kernel version can be selected there.
<apw> bear38, that is a top level of the gits repositories, but generally our master trees are elsewhere
<apw> bear38, for example the 4.15.0 kernels are bionic kernels and therefore here: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic
<bear38> apw: Thanks, I think I see. So these branches must already have the Ubuntu patches applied, right? Using the link I posted above I had to manually apply the patch.
<dijuremo> So I just booted an image which had 4.15.0-42 and it worked fine. My machine had 4.15.0-43 and it worked fine. On the machine I imaged with the 4.15.0-42 kernel, I installed the latest -45 and the problem is present. Next step, try the proposed one and will report back.
<dijuremo> I can confirmed that 4.15.0-46 from proposed repository fixes the problem.
#ubuntu-kernel 2019-03-05
<apw> dijuremo: great, that is currently expected to release formally "really soon" so you are good running it
<tomreyn> hi. maybe here's a better place (i previously brought this up in #ubuntu-bugs):
<tomreyn> is anyone able to comment on bug 1813873 ?
<ubot5> bug 1813873 in linux (Ubuntu Bionic) "Userspace break as a result of missing patch backport" [High,Fix committed] https://launchpad.net/bugs/1813873
<tomreyn> there was an assumption that the existing fixes would become available yesterday, but it doesn't seem to have happened, yet.
<_ruben> as silent as in the bug report itself ;)
<klebers> tomreyn, hi. The kernel update is in process of getting released to -updates, which should happen today.
<klebers> at least the 4.15 kernels
<_ruben> hooray, got released indeed ;)
<tomreyn> klebers: thanks for the feedback earlier.
<tomreyn> any idea about when to expect xenials?
<klebers> tomreyn, we had some issues with the xenial kernels and we are expecting to release them early next week
#ubuntu-kernel 2019-03-06
<tomreyn> klebers: thanks - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873/comments/53
<ubot5> Ubuntu bug 1813873 in linux (Ubuntu Xenial) "Userspace break as a result of missing patch backport" [High,Fix committed]
<klebers> tomreyn, thank you for the comment on the bug
<tomreyn> yw, IMO it's good to keep users informed - if time permits (it did for me).
<apol_> hi, I am trying to test some changes in the kernel, what I did was clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic, modify the files I need to change and call "fakeroot debian/rules binary-headers binary-generic binary-perarch"
<apol_> I'm running the resulting kernel, but I don't see the debug statements that I added, would anyone know what could I be doing wrong?
<apol_> anybody knows if it's possible to rebuild the kernel without having to "clear" first?
<apol_> i.e. with "fakeroot debian/rules binary-headers binary-generic binary-perarch" as advised in the documentation
#ubuntu-kernel 2019-03-08
<rbasak> o/
<rbasak> Could someone respond to https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2019-February/018257.html please?
<rbasak> Or do you want them redirected to a bug or kernel-team@?
<apw> rbasak, actually asking them to repeat themselves on kernel-team@ is likley sensible
<apw> as the options sound useful
<apw> sforshee, ^ something for dev perhaps
<rbasak> apw: OK thanks, I'll reply.
<apw> rbasak, thanks, i should doing it, but i'll not get round to it in a timely fashion; so thank you
<sforshee> we have one of those enabled already, just not the early printk one
<apw> sforshee, if we get that turned into a bug, either by them or us, then we can consider it
#ubuntu-kernel 2020-03-02
<zx2c4> cjwatson: we already ahve a project
<zx2c4> on launcpad
<zx2c4> similarly name
<zx2c4> d
<zx2c4> with the same logo
<zx2c4> the guy here created a new one, invited a bunch of random kernel devs, and made an empty ppa
<zx2c4> sounds pretty clearly malicious
<zx2c4> i emailed the guy and didnt receive a reply either
<zx2c4> i'm not going to add something to answers.launchpad.net, sorry
