#ubuntu-kernel 2006-01-23
<zul> heylo
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-12.17 uploaded (I have no clever code name) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<mjg59> Ooh ooh ooh
<mjg59> Laptop docking support patches
* dilinger upgrades a server to dapper and  2.6.15-12.17, crosses his fingers, and reboots (remotely)
<dilinger> whee!
<dilinger> (22:19:27) Ian Gulliver: hung on detecting and activating hardware
<dilinger> (22:22:36) Ian Gulliver: 4 times now
<dilinger> (22:22:45) Ian Gulliver: looks like 2.6.15 fixes that nasty it-actually-boots-sometimes bug
<dilinger> heh.  there's some race in there
* dilinger beats udev w/ a crowbar
<zul> heylo
<doko> BenC: ping
<BenC> doko: pong
<doko> BenC: is there a way to influence the order how scsi disks are enumerated? I have one on a 3ware controller, which is the first in BIOS setup, but comes as third in the system (the two sata disks are first and second)
<BenC> doko: it's all in how the kernel reports PCI devices to udev, which it in turn loads the controller drivers in that order
<BenC> so it's all based on PCI ordering
<BenC> lspci will show you what you can expect
<BenC> if the sata controller comes before the 3ware one, then there's not much can so other than blacklist the sata controller from initramfs and have it load from the base system
<doko> not nice ... the 3ware has the highest ID
<doko> can this blacklisting be done persistant (for upgrades)?
<Mithrandir> doko: you can't even be sure the ordering is consistent.  Why do you want to see the controllers in a particular order?
<doko> remove the sata disks at some point and still have a bootable system
<Mithrandir> use by-label or by-uuid?
<lamont__> YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  _I_ _AM_ _INVINCIBLE_!!!!!!!!!!!!!!
* lamont__ uploads the new elilo so that we can toss initrd-tools
<doko> could somebody please kick out this robot ;-P
<BenC> sweet
<doko> Mithrandir: in grub?
<BenC> lamont: so can ia64 and hppa go to initramfs now?
<lamont__> just booted ia64 with initramfs
<Mithrandir> doko: grub is on the first drive the BIOS sees, you can't really change that.
<lamont__> BenC: now, for extra credit... tell me what magic is missing on both ia64 and hppa to have the network card autodetect and configure like it does on the first-class architectures...
<doko> yes, but it has root=/dev/sda5 , so this should be changed to something else?
<lamont__> BenC: and I'm just being blind today... can't see where that stupid question is coming from... (Install a boot block using the existing...)"
<lamont__> that is, I can't see why the kernel postinst doesn't ask the same question with grub
<lamont__> oh, wait.  that's sick.
<lamont__> there's no /etc/grub.conf
<lamont__> --> no question
<lamont__> and no grub run.
<lamont__> hrm.
<lamont__> BenC: I think that kernel-package needs to be updated to use debconf.... and that really hurts to say that.
<BenC> lamont: PCI devices need a MODULE_DEVICE_TABLE()
<BenC> that will help udev to know which driver to load when it sees that PCI device id
<lamont__> 0000:00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
<lamont__> that doesn't have a DEVICE_TABLE???
<lamont__> 0000:a0:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
<lamont__> I can believe that one's new enough not to.
* lamont__ reboots the box to see something
<lamont__> BenC: so, ia64 needs to depend elilo (>=3.6-1) and hppa/ia64 both need klibc-utils (>=1.1.16-1ubuntu1)
<lamont__> and then the initrd-tools Depend can go away
<lamont__> BenC: fresh boot shows eth0 present with a MAC addr, etc... but not configured.
<lamont__> ifup eth0 and everything is happy
<lamont__> so I think it's above the kernel...
<lamont__> udevd[784] : get_netlink_msg: unable to receive kernel netlink message: No buffer space available
<lamont__> I wonder if that's related... :-)
<lamont__>  * Detecting and activating hardware...
<lamont__> udevd[1726] : get_netlink_msg: unable to receive kernel netlink message: No buffer space available
<lamont__>    ...done.
<doko> Mithrandir grub lists root=/dev/sda5 as parameter, so this should be changed to something else?
<lamont__> hrm... probably
<Mithrandir> doko: if you use root=/dev/disk/by-uuid/$uuid-of-fs
<lamont__> and shortly after that:
<lamont__>  * Loading modules...
<lamont__> Linux Tulip driver version 1.1.13 (May 11, 2002)
<lamont__> tulip0: no phy info, aborting mtable build
<lamont__> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
<lamont__> eth0: Digital DS21143 Tulip rev 65 at 80001000, 00:10:83:7A:1F:35, IRQ 66.
<lamont__>    ...done.
<BenC> lamont: that's a auto etho0 to /etc/network/interfaces
<lamont__> BenC: right.  But I don't need that on i386
<lamont__> because of this:
<lamont__> mapping hotplug
<lamont__>         script grep
<lamont__>         map eth0
<lamont__> hence the "what magic is missing here" question
<lamont__> or maybe it's not... :-(
<lamont__> I just know that my i386, ppc, and amd64 boxen all autoconfig eth0, even without the 'auto eth0' in /etc/network/interfaces
<Mithrandir> lamont__: autoconfiguration of networks is kinda broken in dapper now.
<lamont__> Mithrandir: it didn't work in breezy either.
<lamont__> Mithrandir: how soon will the known borkage be fixed?
<Mithrandir> lamont__: ask scott
<lamont__> BenC: can I leave fixing the kernel package depends to you?
<lamont__> BenC: fwiw, klibc_1.1.16-1ubuntu1 is current everywhere but sparc, which is probably just an upload-not-done-yet thing
<BenC> yeah, fabbione is away for awhile
<BenC> I can do the kernel deps
<lamont__> thanks
<BenC> klibc is a initramfs-tools dep I think
<BenC> it's not for linux-image-* or kernel-package
<infinity> lamont__: I can bump the depends on klibc* in initramfs-tools for you.
<lamont__> infinity: ah, yeah, that'd be the place, huh?
<lamont__> infinity: or I can do it if you don't have an upload planned soon
<infinity> <shrug>.. I have the source sitting right here.
<infinity> (>= 1.1.16-1) should be fine, yes?
<infinity> (so it can go back to Debian like that too)
<infinity> Uploaded.
<makx> infinity: the evms hooks landed directly in evms with latest debian upload :)
<makx> i see that i need to sync to your repo for some nice arch support and copy_exec fixes.
<makx> i'm still wondering why ubuntu's modprobe has "-Qs"?
<makx> and i don't see that in our m-i-t..
<infinity> makx: I saw that.  Congrats.  I'll be merging that stuff in after my VAC.
<infinity> makx: With any luck, we're down to pretty much no diff, except for bugfixes and doc changes passing back and forth.
<infinity> (and some usplash junk)
<infinity> BenC: Can you please sync ipw2100 to 1.1.4 if you have a chance?
<infinity> BenC: (regarding: https://launchpad.net/products/network-manager/+bug/28544 )
<BenC> sure
<infinity> Danke.
<mjg59> BenC: Did you see my pointer to the Marvell wireless driver?
<BenC> I did, but it's lost in scrollback...can you email it to me where I know it will stay in my view?
<mjg59> Ok
<BenC> thanks
<mjg59> BenC: Address?
<BenC> bcollins@ubuntu.com
<mjg59> Done
<mjg59> Needs firmware, we probably want to ask for distribution rights
#ubuntu-kernel 2006-01-24
<mjg59> Marvell haven't been too bad in the past, AFAIK
<zyga> hello
<zyga> I'm trying to write a fuse based fs with some dynamic files
<zyga> I want something similar to /proc/foo where I can use cat to see the contents
<zyga> when I make my virtual files have size 0 and mode with I_SFREG I cannot cat it
<zyga> I need to supply some non-zero size to be able to read the content
<zyga> I was wondering if /proc is using some special way to handle this
<BenC> the size shouldn't have anything to do with it
<zyga> stat'ing files in proc and my fs does not show any difference :/
<BenC> read() operations don't even pay attention to the filesize
<zyga> BenC: maybe proc is using mmap interface
<BenC> cat doesn't
<BenC> read() is read()
<zyga> BenC: true, I didn't test that with a dumb program that relies only on read
<zyga> BenC: still, as long as stat returns 0 in st_size I cannot see the contents with cat
<BenC> there's lots of files in proc and /sys that show zero size and cat works on them just fine
<zyga> BenC: that's why I'm asking ... I don't know why this happens
<BenC> I'm doubting that has anything to do with it, but I'm also not familiar with fuse, so I'm not the right person to ask
<zyga> maybe that's something fuse-specific
<zyga> I see a sequence of stat, open and release (final close)
<zyga> I never see any reads
<BenC> did any of those fail?
<BenC> perhaps the open failed?
<BenC> strace cat /your/file
<BenC> should tell you if the open failed for some reason
<BenC> brb
<zyga> BenC, no
<zyga> BenC: I'm starting to see the problem
<zyga> the call doesn't fail, python has mixed the stat structure somewhat
<zyga> (python-fuse)
<zyga> I don't really know which field gets passed where, I'll sort this out soon
<zyga> what should be the st_size of a directory?
<crimsun> zyga: hmm, in-kernel fuse?
<crimsun> I see fuse 2.5.0
<zyga> crimsun: ?
<crimsun> zyga: what's triggering the bug?
<zyga> crimsun: I don't know yet
<zyga> crimsun: it seems that for files that have st_size == 0 the read function is never called
<zyga> I'm looking at python2.4-fuse now
<crimsun> sorry, I should have been more precise: What's your test case? (I guess you partially answered that)
<crimsun> fuse 2.5.0 has a bunch of fixes
* crimsun git pulls
<zyga> crimsun: I'm using 2.4.2
<zyga> python-fuse is automatically setting blocksize to 4096
<zyga> as well as hum...
<zyga> it's broken :P
<zyga> crimsun: by fuse 2.5.0, you ment fuse not, python-fuse, right?
<crimsun> right.
<zyga> crimsun, BenC: thanks for the help
<zyga> it seems to be a fuse issue but I'm not 100% sure yet
<zyga> I call it a day, night :)
<Mithrandir> BenC: have you had a chance to look at the unionfs problems on PPC in the live cd?
<zul> heylo
<BenC> Mithrandir: should be fixed in -13
<Mithrandir> BenC: great, thanks
<BenC> Mithrandir: #ubuntu-meeting
<Mithrandir> already there
<JaneW> mjg59: PING
<zooko> Greetings, folk of #ubuntu-kernel!
<zooko> I'm considering installing the dapper gcc and dapper linux-source on my breezy system and compiling the kernel.  If I do so, do you want to hear any resulting bug reports?
<BenC> it wont work well
<BenC> it would be the same as installing the dapper kernel images from breezy
<BenC> you would be better off just upgrading just the kernel image from dapper (and it's dependencies)
<BenC> the kernel really doesn't care where it's compiled, it's the system it's running on that really matters
<BenC> "installing the dapper kernel images" (not from breezy)
<zooko> BenC: thanks for the suggestions.
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-13.18 uploaded (The "Stick it to da man" Release) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<zul> slacker
<zooko> Hm.  I guess I'll go for gcc 4.0.whateverisindapper
<BenC> are you still going to rebuild dapper kernel source in breezy?
<zooko> Yes.
<BenC> Just want to make sure you realize that it's not going to build a kernel any different than what is in dapper
<BenC> it will be the same kernel (assuming you use the same .config's)
<zooko> Understood.  Although I'll have slightly different configs...
<zooko> I don't intend to request support from you on this.
<BenC> I wasn't going to give any, but I just hate seeing someone waste time :)
<zooko> I consider this channel to be for development, so I really mentioned it in case someone would say something like "Oh, please test such and such a bug while you do that" or some such.
<zooko> :-)
<BenC> I started 2.6.15-dapper kernel development on strictly breezy systems, so I know the outcome...your devices wont autoload, udev will become dumb and you'll typically be unhappy
<zooko> What's the IRC channel for Ubuntu-using-bzr?  I'm interested in listening to how people use bzr.
<zooko> Hm.
<BenC> #bzr? note sure
<zooko> That does sound intimidating.
<zooko> Maybe I can avoid some of those problems by updating my udev package to dapper...
<zooko> But now I am discouraged.  Maybe I'll stick with 2.6.12...
<zooko> OTOH it can't hurt to try.  ;-)
<BenC> it wont kill you thats for sure :)
<zul> unless a large wooden mallet pops out of your computer and hits you over the head...its a new driver in 2.6.15
<BenC> fortunately with udev broken, it never gets loaded
<zul> lol
<BenC> Try to avoid "modprobe kbd-electrocution" though
<infinity> BenC: Erk, I don't see an ipw2100 sync in that changelog.
<BenC> infinity: it was done...I thought I did the changelog entry
<BenC> but it's surely done (1.1.4)
<infinity> Guess I should have gone through the motions of reassigning that bug...
<infinity> Oh, it's done?.. Cool.
<infinity> Alright.  I'm on VAC as of now.
<infinity> lamont's your bitch now.
<lamont__> "By your command"
<doko> BenC, infinity, please could you have a look if iptables is worth updating? ftp://ftp.netfilter.org/pub/iptables/changes-iptables-1.3.4.txt
<BenC> is that the userspace stuff?
<BenC> supposedly, our userspace and kernel drivers are out of sync terribly
<Mithrandir> BenC: do you think a patch to add a label to swsusp images would have > 0 chance of being accepted upstream?
<BenC> what sort of label?
<Mithrandir> free-text, max 32 chars.
<Mithrandir> unused by the kernel, but we could use it for stuff like "make sure you're resuming from the image that says "Ubuntu-$(uname -r)" and not the one which says "SuSE-$(uname -r)"
<BenC> guess it all depends on what the purpose is
<Mithrandir> similar, we would have support for suspend on the live cd.  Suspend to an USB stick, resume from that later.
<BenC> ah, that does sound cool
<Mithrandir> yeah, I thought so.
<BenC> I would include it in our kernel, and I can push it upstream if you want
<Mithrandir> I have the kernel patch mostly done, but would need to test it, naturally.
<doko> BenC: iptables is userspace
<BenC> doko: doesn't it depend on some kernel stuff (kernel headers or something)?
<BenC> kernel-team@l.u.c has a user reporting problems with sync between kernel headers and iptables userspace
<doko> BenC: it does
<BenC> will the new version fix that?
<doko> BenC: I didn't check, I just scanned dapper/main for packages with new upstream versions
<BenC> if it helps that situation, then I'd say it's a good candidate for new upstream version
<BenC> we already know the current package/setup is broken
<zooko> So you know how I planned to compile 2.6.15-12.17 myself, on breezy?  And BenC warned me about this?
<zooko> Well, instead I installed the kernel image from dapper, and all of its dependencies.
<zooko> It *almost* works.  The only breakage that I can find is that one of my four hard drives is not detected.
<zooko> Unfortunately, I really need that one, so now I must dig myself out of this situation...
<zooko> Hm.  No /proc/config.gz.
<zooko> Ah, and when I install linux-headers-2.6.15-12 I get this bug which Ben Collins has already assured me is impossible...
<zooko> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.12/+bug/6384
<zooko> Uh-oh.  I upgraded dpkg and debfoster in order to see if this would make Ben's assertion true.
<zooko> Unfortunately it made it worse -- now I cannot back out of this situation anymore by using "dpkg --purge".
<zooko> Oh yes I can.  I just need to dpkg --purge the *other* package instead of the new and uninstallable one.  Good.
<zooko> I do hope that linux-image-2.6.12-9-amd64-k8 from dapper universe will recognize my fourth hard drive so that I can copy my work from it.
<zul> shouldnt you have a backup plan?
<aLeSD> hi akk
<aLeSD> all
<aLeSD> I have a question
<aLeSD> why default kernels in ubuntu don't use preemtive?
<aLeSD> another one is I'm compiling the kernel by hands... but it gives a kernel panic on rootfs mounting ... I use the usually make && make modules_install. I think it's because the support for the filesystem in ubuntu kernel is all modular (the most). Now how could I create an initd file by hands?
<mjg59> BenC: Waa NetworkManager oopses my kernel
<Mithrandir> hmm, they don't?
<mjg59> (-12, -11 was fine)
<Mithrandir> $ grep CONFIG_PREEMPT= /boot/config-2.6.15-12-686
<Mithrandir> CONFIG_PREEMPT=y
<BenC> mjg59: try -13, it should fix it
<aLeSD> Mithrandir: wow ... I have only the 6.12 in my repository
<BenC> daper kernels have preempt, not breezy
<BenC> dapper
<aLeSD> ok... could I compile my kernel by hand or I have to use make-kpkg
<aLeSD> ?
<aLeSD> ok ... stupid question... but It's my first time in ubuntu ... and i don't know how is it.. 
<BenC> you can do whatever you want, but make-kpkg is prefered
<aLeSD> ok I understand .-... make-kpkg
<mjg59> BenC: Is that in the archive?
<BenC> just uploaded today, so give it a few hours
<mjg59> Ok
<BenC> I assume you are getting an oops about "BUG in ...ieee80211"?
<mjg59> Yup
<zooko> For what it is worth, when I upgrade to 2.6.15 from dapper, everything works except for my promise raid controller 0000:00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02)
<zooko> 
<cjb> zooko: Is there a module for it?  Anything in dmesg?
<zooko> There is a sata_promise module loaded.
<zooko> /var/log/syslog:Jan 19 13:33:13 yumyum kernel: [   37.708288]  sata_promise 0000:00:08.0: version 1.03
<zooko> 
<zooko> "1.03" is the version of the promise bios.  Not sure if that is the same number as in my syslog there.
<BenC> modprobe sd_mod
<zooko> no output.  sd_mod now appears in the output of lsmod.
<zooko> It might or might not have been in lsmod before that.
<BenC> are the drives connected sata drivers, or just ata?
<BenC> just so happens that I got 4 promise 150 SATA controller cards in the mail from a very nice user today :)
<BenC> my ATA drive doesn't appear to be recognized, but I assume that's because the controller driver doesn't support it (or maybe the controller doesn't)
<tkup> how can I use a function from the kernel include files inside my module? I tried including the header file itself, but it didn't solve the problem. For instance, I included linux/swap.h but couldn't use any of the extern functions. Can anyone tell what I'm doing wrong?
<BenC> tkup: explain how you can't use it
<BenC> is it showing as unresolved when you load the module?
<BenC> if so, that's because the functions aren't exported for module use (with EXPORT_SYMBOL())
<tkup> BenC, that's right. the function isn't exported out. Does it mean that there's no other way but to reimplement that function?
<BenC> you can add the EXPORT_SYMBOL to the file where the function is, and recompile the kernel
<tkup> or link against that module that implements it,,,
<cjb> tkup: Well, the obvious answer is to export it yourself, and persuade the kernel maintainers that it's needed by your code.
<BenC> but you really should email linux-kernel@vger.kernel.org to see if your use of the function is correct or not
<cjb> If you don't want to persuade them of that because you're not writing code for public consumption, it shouldn't be a problem to build your own kernel.  ;-)
<BenC> tkup: unresolved functions in kernel modules like this isn't a matter of linker (ld) problems, it's the kernel enforcing what modules are allowed to do
<tkup> BenC, cjb  I'm interested in add_to_swap.  the module is already GPL but nothing to write home about... just working on something I thought was interesting to see it work
<BenC> I wouldn't reimplement the function (could create compatibility problems later on)
<BenC> really, you should email l-k about the function you are using, if you are interested in releasing the module
<BenC> see what they say about it, and maybe they could suggest the right way to handle it
<tkup> I guess I could do what you said for starters and see if the module is interested before I write lkml
<tkup> BenC, I'll email lkml and see if I should be using it at all
<tkup> thanks
<BenC> np
<BenC> sweet, I got pata working on the sata_promise driver
#ubuntu-kernel 2006-01-25
<zul> heylo
<Mithrandir> uhm, BenC?
<Mithrandir> git pull says:
<Mithrandir> fatal: Entry 'arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c' not uptodate. Cannot merge.
<Mithrandir> help?
<Mithrandir> apparently, that means "out of disk space".. :-p
<BenC> Mithrandir: it means  your local copy is modified
<BenC> git-status
<BenC> To get rid of all local changes: git-checkout -f 
<Mithrandir> no, it meant disk full.  I haven't touched anything in there
<BenC> weird
<Mithrandir> what's the easiest fix for the "I can't find the abi file" problem?
<Mithrandir> Missing /home/tfheen/ubuntu-2.6/debian/abi/2.6.15-13.18/abiname file.
<BenC> needs me to get all the abi files
<BenC> or you can cp -a debian/abi/2.6.15-13.1{7,8}
<BenC> or you can cp -a debian/abi/2.6.15-{12.17,13.18}
<BenC> the latter
<Mithrandir> also, ccache is love.
<BenC> yeah, I have that installed on all my build systems
<BenC> life saver
<Mithrandir> it still takes a long time to build on this laptop, but significantly less.
<BenC> just pushed the correct abi files, if you want to pull them
<Mithrandir> thanks.
<Mithrandir> I'll first test this new, shiny suspend label thing.  If we get it in upstream, it'll be my first kernel patch. :-)
#ubuntu-kernel 2006-01-26
<Chipzz> hi
<Chipzz> do you guys realize that the latest initramfs setup has broken home-made kernels built with make-kpkg beyond all belief?
<Chipzz> :/
<Mithrandir> Chipzz: uh, how so?
<Chipzz> networking not starting at all
<Chipzz> which is due to /etc/network/ifstate not being removed
<Chipzz> and output of e2fsck being spewed all over the console with brown * next to it
<Chipzz> (like failure messages)
<Mithrandir> that has nothing to do with custom or regular kernels.
<zooko> I have a custom kernel built with make-kpkg, and I have different problems than that.
<Chipzz> oh *sigh*
<Chipzz> this time it fucks up in the initramfs
<Chipzz> :/
<Chipzz> this is exactly why I have home-made kernels: to avoid the need for any crap like initrds and initramfs'es *at all*
<Chipzz> :(
<Mithrandir> maybe it fucks up because you did something silly when compiling your kernel, then?
<Chipzz> this kernel has worked ever since I installed ubuntu, and before that several months on a debian install
<Chipzz> (to be more precise: I recompiled the kernel form my debian system with the same config on ubuntu with make-kpkg)
<Mithrandir> yes, and?  If you're not using initrds, the initrd/initramfs can't break your boot.
<Chipzz> the reason it breaks is exactly because initramfs being run
<Mithrandir> don't use initramfs, then.
<Chipzz> ok, little question...
<Chipzz> why is /dev mkdir'ed in the initramfs?
<Mithrandir> because else it won't exist? :-)
<Chipzz> duh :)
<Chipzz> but why don't you put it in the initramfs in the first place>?
<Mithrandir> that'd work too.
<Chipzz> I was going to suggest the following:
<Chipzz> on debian I had devfs earlier
<Chipzz> but just in case that crapped up
<Mithrandir> newer kernels don't support devfs, though.
<Chipzz> I had the necessary device nodes in /dev
<Chipzz> (for the root filesystem)
<Chipzz> so even if for some reason the devfsd maintainer screwed up big time
<Chipzz> at the very least the / fs would still mount
<Mithrandir> well, we discover stuff at boot-time rather than relying on /dev/sda being the right node each time.
<Chipzz> maybe a good idea to actually ship /dev in the initramfs, with the necessary device nodes to mount / (and possibly /usr and /var and /tmp?)
<Mithrandir> or rather, you need to load the relevant module 
<Mithrandir> what's needed to mount the root filesystem?
<Chipzz> one device node ;P
<Chipzz> in my case, /dev/hda1 ;)
<Mithrandir> udev creates that when the device becomes available
<Chipzz> yes
<Chipzz> and what if the udev maintainer fucks up and udev doesn't start?
<Chipzz> ;)
<Chipzz> thing is
<Mithrandir> then your system becomes unbootable, but you switch back to your previous initramfs and boot happily using that?
<Chipzz> you *know* what device node will be needed to mount / at initramfs creation time
<Mithrandir> no, you don't.
<Chipzz> wouldn't that be the same device node your / fs is mounted at at that moment?
<Mithrandir> what's if your root device is an USB hard drive?
<Chipzz> ok, in most sane cases... ;P
<Mithrandir> installing to an USB hard drive is not a sane case?  A live cd is not a sane case?
<dilinger> i dunno who normally handles this, but i just uploaded ndiswrapper 1.8 to debian
<dilinger> there are misc bugs in 1.5 (which is in dapper) that are fixed in 1.8
<dilinger> might want to consider resynching w/ debian
<BenC> we don't sync that package with debian, plus we are in an upstream feature freeze
<BenC> but thanks
<BenC> version freeze I mean
* dilinger shrugs
<dilinger> ok
<dilinger> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338309
<dilinger> stuff like that is what you'll get when using ndiswrapper 1.5 w/ a newer kernel
<BenC> how new?
<BenC> we aren't going past 2.6.15 for dapper
<dilinger> that bug report is with 2.6.14
<dilinger> 1.5 is quite old
<BenC> 1.5 was released not too long after dapper started, which was only a few months ago
<dilinger> well, in terms of kernel releases, it's old
<zooko> Heh.
<dilinger> i assume you had to patch it to make it compile?
<dilinger> looks like 1.5 was released on halloween
<BenC> don't think so, maybe just the USB URB thing
<dilinger> a bunch of people compiled that 1.5 didn't compile w/ 2.6.14
<dilinger> complained, rather :)
<dilinger> anyways, just a suggestion
<BenC> ok
<zul> heylo
<mxpxpod> BenC: ping
<dilinger> ugh
<dilinger> this dapper box is having issues
<dilinger> disk read issues :/
<dilinger> rock!
<dilinger> i just upgraded to the latest initramfs/kernel packages in dapper
<dilinger> it looks like it fixed all the udev problems
<dilinger>  /dev/null and friends now even have the correct permissions
<BenC> mxpxpod: pong
#ubuntu-kernel 2006-01-27
<mxpxpod> BenC: ping
<BenC> mxpxpod: pong
<mxpxpod> BenC: are you running ppc?
<mxpxpod> BenC: because with the latest kernel (2.6.15-13), I get no sound card on my ibook g4
<BenC> mxpxpod: ls -l /proc/asound/
<BenC> and yes, I am using a pb G4
<BenC> redid a lot of the ppc sound stuff trying to make things work better, but it's untested on anything but toonie
<mxpxpod> BenC: I'm not currently in that kernel because I couldn't log into Gnome because of the sound issue
<mxpxpod> BenC: but /etc/init.d/alsa-utils fails to start because it can't find the sound card
<BenC> no sound prevented gnome from working?
<mxpxpod> that's what I'm figuring... I could be wrong
<mxpxpod> but when gnome tries to log in, gconf and gnome-keyring manager load, and that's it
<mxpxpod> BenC: also, when my ibook sleeps with the new kernel, it panics
<mxpxpod> BenC: I've gotta get going
<mxpxpod> BenC: but hopefully I can get a bug report up on malone tomorrow or monday
<gok> hi !
<gok> somebody speaks french ?
<gok> I have 2.6.12-10-686 linux kernel (ubuntu 5.10) and I do not arrive has to see disc ide on my controllor RAID via VT6410
<gok> but i see raid controller
<gok> gok@torax:~$ lspci |grep -i raid
<gok> 0000:02:04.0 RAID bus controller: VIA Technologies, Inc. VT6410 ATA133 RAID controller (rev 06)
<gok> does somebody have an idea?
<mxpxpod> BenC: ping
<BenC> pong
<mxpxpod> BenC: ok, I'm in the latest kernel... do you want to debug this soundcard issue?
<BenC> ls -l /proc/asound
<mxpxpod> want me to paste it here?
<BenC> sure
<mxpxpod> total 0
<mxpxpod> dr-xr-xr-x 2 root root 0 2006-01-22 10:06 card0
<mxpxpod> -r--r--r-- 1 root root 0 2006-01-22 10:06 cards
<mxpxpod> -r--r--r-- 1 root root 0 2006-01-22 10:06 devices
<mxpxpod> -r--r--r-- 1 root root 0 2006-01-22 10:06 modules
<mxpxpod> dr-xr-xr-x 2 root root 0 2006-01-22 10:06 oss
<mxpxpod> -r--r--r-- 1 root root 0 2006-01-22 10:06 pcm
<mxpxpod> dr-xr-xr-x 2 root root 0 2006-01-22 10:06 seq
<mxpxpod> -r--r--r-- 1 root root 0 2006-01-22 10:06 timers
<mxpxpod> -r--r--r-- 1 root root 0 2006-01-22 10:06 version
<BenC> this is an ibook?
<mxpxpod> ibook g4
<BenC> I get an entry like this:
<BenC> lrwxrwxrwx 1 root root 5 Jan 22  2006 Toonie -> card0
<BenC> do "lsmod | grep snd"
<mxpxpod> snd_powermac           72372  1
<mxpxpod> snd_pcm_oss            68480  0
<mxpxpod> snd_mixer_oss          23072  1 snd_pcm_oss
<mxpxpod> snd_pcm               109828  2 snd_powermac,snd_pcm_oss
<mxpxpod> snd_timer              29156  1 snd_pcm
<mxpxpod> snd                    72468  5 snd_powermac,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
<mxpxpod> soundcore              11716  1 snd
<mxpxpod> snd_page_alloc         12424  1 snd_pcm
<mxpxpod> it's like it doesn't see the snapper
<BenC> so you know it's snapper?
<mxpxpod> yeah
<BenC> actually, it's doing soemthing because snd_powermac has a ref count of 1
<BenC> so something is using it
<mxpxpod> is there a way to figure out what?
<BenC> do you have headphones?
<mxpxpod> yes
<BenC> try plugging them in, then unplugging them
<mxpxpod> BenC: ok, now what?
<BenC> does sound work now?
<mxpxpod> nope
<BenC> Can you send the output of amixer to http://pastebin.ubuntu-nl.org/?
<mxpxpod> it's one line
<mxpxpod> amixer: Mixer attach default error: No such device
<BenC> hrmm
<BenC> can you send the output of dmesg to pastebin?
<mxpxpod> yeah
<mxpxpod> http://paste.ubuntu-nl.org/7485
<mxpxpod> there's an oops in there
<BenC> I think I just found out the problem via another bug report
<mxpxpod> oh?
<BenC> hold a sec...
<mxpxpod> ok
* mxpxpod holds
<BenC> find /proc/device-tree -name layout-id
<BenC> then do :
<BenC> cat <file from above> | od -t x
<mxpxpod> it didn't give me a file from the find
<BenC> hmm, weird
<BenC> find /proc/device-tree | grep layout-id
<mxpxpod> nope
<BenC> rgrep snapper /proc/device-tree
<mxpxpod> Binary file /proc/device-tree/pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sound/compatible matches
<BenC> ok
* mxpxpod hopes he's helping
<BenC> yes, thanks for taking them time :)
<mxpxpod> no prob... any way I can help
<BenC> give me a minute to read the dmesg
* mxpxpod likes his sound working and his kernel not faulting
<BenC> stupid me
<BenC> I already have this fixed :)
<mxpxpod> oh?
<BenC> how long will you be around?
<BenC> I can give you a kernel to test
<mxpxpod> it'll take me forever to download
<mxpxpod> if you email me a link, I can download and test it tomorrow
* mxpxpod has a crappy connection here at home
<BenC> email me at bcollins@ubuntu.com, and I'll reply back with a link
<mxpxpod> awesome
<BenC> ppc sound is in real transistion, but it's going to be better in the end
<BenC> but it'll be better in the end when I'm done ;)
<mxpxpod> sweeet
* BenC repeats himself
<BenC> too little coffee
* BenC sends his wife to make more
<mxpxpod> :)
<mxpxpod> BenC: what kind of changes are you making?
<BenC> well, BenH did some new interfaces to access the ppc gpio's, and I'm switching the sound drivers to use them
<BenC> the old way used some real hacks, the platform function interface is the "macos" way, and should work better
<mxpxpod> awesome
<BenC> I had to use it to get sound working right on my 17" PB
<mxpxpod> ok, I sent you an email
<BenC> great, thanks
<mxpxpod> like I said, I'll grab it tomorrow... hopefully that's soon enough :)
<mxpxpod> BenC: thanks again
<BenC> np
<mxpxpod> BenC: by the way, do you have your ae working?
<BenC> ae?
<mxpxpod> airport extreme
<BenC> oh, yeah, been using it for some weeks now
<mxpxpod> I can't get mine to work at all
<BenC> bcm43xx driver, you'll need to extract firmware using fwcutter (bcm43xx.berlios.de), and put it in /lib/firmware/
<mxpxpod> oh, I've done all that
<BenC> you have to set the rate to 11M, or it wont work
<BenC> highest I've gotten to work is 36M
<BenC> but 11M is stable
<mxpxpod> BenC: does dhcp work with it?
<BenC>         pre-up iwconfig eth0 rate 11M
<BenC>         pre-up ifconfig eth0 up
<BenC>         pre-up sleep 2
<BenC>         pre-up iwconfig eth0 rate 11M
<BenC> I added that to /etc/network/interfaces for my card
<BenC> yeah
<BenC> I use dhcp, so it's all working well (just no wireless stats)
<mxpxpod> ah
<BenC> as far as I'm concerned, when it works at 54M and wireless stats are implemented, it will be 100% ready for wide use
<mxpxpod> :)
<mxpxpod> I'll try to figure it out sometime this afternoon
<mxpxpod> BenC: where do you have the pre-up stuff? underneath iface eth0 inet dhcp?
<BenC> yeah
<mxpxpod> BenC: also, do you use network-manager with it?
<BenC> no
<mxpxpod> how about wep?
<BenC> yeah, I use a wep key
<BenC> wireless-essid FOO
<BenC> wireless-key BLAHBLAH
<mxpxpod> I'm trying to figure out how to format my wep key
<BenC> I just put the hex
<mxpxpod> with no :'s or -'s?
<BenC> yeah
<BenC> no 0x either
<mxpxpod> right
<mxpxpod> hrmmm
<BenC> then "sudo ifup eth0"
<mxpxpod> she's not wanting to get an ip
<BenC> ^C and try again
<BenC> it's a little quirky, also check to make sure it's at 11M (iwconfig eth0"
<BenC> )
<BenC> I also have wireless-rate 11M in the file
<BenC> you have to really convince it to go to 11M :)
<mxpxpod> heh
<mxpxpod> whoa!!!!
<mxpxpod> whoa!!!!
<mxpxpod> brb
<BenC> heh, that didn't look good :)
<BenC> working for you now?
<bryanf> BenC: sweet
<bryanf> BenC: btw, this is mxpxpod
<BenC> yeah, I recognize the name from the email :)
<mxpxpod> BenC: yeah, that's cool
<mxpxpod> BenC: thanks for the help
<mxpxpod> now, if I could just get it so that my wife can use it without using the cmd line :)
<BenC> mine is auto up now, and it works well
<mxpxpod> cool
<mxpxpod> I gotta go
<mxpxpod> my wife wants to attack me ;)
<BenC> later
<mxpxpod> thanks again for the help
#ubuntu-kernel 2006-01-28
<TheMuso> c
<TheMuso> crap...
<psusi> is it just me or do the kernel packages postinst scripts interact directly with the user instead of going through debconf?  thus violating debian policy?
<psusi> whenever I upgrade it asks if you want to stop now, do you want to reinstall lilo?  do you want to erase lilo.conf? but all without synaptic realizing this and generating a gui prompt
* dilinger thinks you're bringing this up in the wrong channel
<dilinger> anyways, new kernel-package stuff is debconf-ized
<psusi> it just happened again upgrading dapper today
<dilinger> er, new kernel-package stuff in debian
<dilinger> dapper is still using 9.x
<dilinger> sid contains 10.x
<psusi> I see
<dilinger> which is all pimped^Wdebconf'd out
<psusi> nice
<psusi> you wouldn't happen to know much about debian-installer would you?  I'm trying to figure out the best way to integrate the dmraid-udeb package into it so it can detect hardware fakeraid disks before partman runs... can't seem to find anyone who knows that kind of stuff
<psusi> I was going to just rebuild partman with dmraid as a dependancy to get it installed and configured first... only the source package for partman doesn't appear to build a udeb at all... weird...
<mxpxpod> BenC_: ping
<zul> heylo
<zul> sorry i wasnt around this weekend was sick again
<fabbione> commit 2179d372d9f8b5fc5c189c89bc6a565a42151b23
<fabbione> Author: David Elliott <elliott@stcnet.com>
<fabbione> Date:   Wed Jan 18 17:43:08 2006 -0800
<fabbione>     [PATCH]  hfs: add HFSX support
<fabbione> 
<fabbione>     Add support for HFSX, which allows for case-sensitive filenames.
<fabbione> 
<fabbione>     Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
<fabbione>     Signed-off-by: Andrew Morton <akpm@osdl.org>
<fabbione>     Signed-off-by: Linus Torvalds <torvalds@osdl.org>
<fabbione> WHOOO HOOO
<fabbione> hey zul
<fabbione> BenC_: ping?
<BenC_> poing
<BenC_> fabbione: does that apply to 2.6.15?
<fabbione> BenC_: yo..
<fabbione> BenC_: dunno. i am just going trough .16 changelog
<fabbione> BenC_: you need to teach me to do cherry picking :)
<fabbione> BenC: ready to travel?
<BenC> git-cherry-pick 2179d372d9f8b5fc5c189c89bc6a565a42151b23
<BenC> yeah
<fabbione> BenC: remember to buy enough cigarettes for the entire week before you get to .uk
<fabbione> they are damn expensinve there
* fabbione wants .16 in dapper
<fabbione> the changelog is impressive
<fabbione> BenC: i guess git-cherry assumes you have the object in the same tree...
<fabbione> what if the object is in another tree?
<BenC> git-cherry would work
<BenC> I pulled some things from 2.6.16-git, but I have linus tree fetched into another branch
<fabbione> i will have to try
<fabbione> btw.. remember that webcam thingy?
<fabbione> i got almost all the code merged properly
<fabbione> it still doesn't work but i have a good idea what's wrong
<fabbione> at least the module doesn't crash one second yes and the other too
<fabbione> the original driver uses some i2c calls, while the modified once doesn't
<fabbione> the changelog claims for performance reasons
<fabbione> but it's fun to hack :)
<fabbione> it's basically the qc_sensor_vv6450 support for the quickcam driver that addes the quickam express
<BenC> fabbione: cool
* BenC has been hacking on pb sound
<BenC> well, ppc sound in general really
<fabbione> yeah i saw the commits
<fabbione> i am preparing the new git trees on my mac for london
<fabbione> and i will take the webcam with me
<fabbione> so we can have somefun after working hours :)
<BenC> I have a logitach webcam I should try to get working
<fabbione> BenC: wanna bet it's the same as mine?
<fabbione> +       { USB_DEVICE(0x046D, 0x08F0) },         /* QuickCam Messenger */
<fabbione> +       { USB_DEVICE(0x046D, 0x08F5) },         /* QuickCam Communicate */
<fabbione> is it one of these two?
<BenC> probably
<BenC> I'll check
<fabbione> if so the driver i am working on is the same :)
<zul> fabbione: you are such a geek..
<zul> as my wife would say
<fabbione> zul: ahah
<fabbione> BenC: http://people.ubuntu.com/~fabbione/dmesg.ppc
<fabbione> BenC: i got an OOPS on today's live cd 
<BenC> daily?
<fabbione> yeps
<Mithrandir> vely, vely shiny.
<fabbione> it's the last one generated by Mith
<Mithrandir> current as of three-four hours ago
<BenC> what is using squashfs?
<Mithrandir> the live cd, like, it's the root file system
<fabbione> BenC: do you need anything more from me or can you go on your own?
<fabbione> (for the livecd thingy i mean)
<BenC> I can do the rest, thanks
<fabbione> np
<doko> BenC, fabbione: is there some way to clear the scrollback buffer, so that I'm not able to see any content after I do a `clear'?
<BenC> no idea :)
<fabbione> doko: ??????
<BenC> not sure exactly what you mean though
<doko> when logging out on a console the screen should be cleared. just calling clear doesn't help, you are able to scroll back with Shift-PageUp
<Mithrandir> doko: clear + chvt?
<mxpxpod> BenC: ping
<BenC> mxpxpod: pong
<mxpxpod> BenC: wanna email me that link?
<BenC> still working on the problem with the oops on suspend/resume, which I should have done later today
<mxpxpod> BenC: cool
<BenC> don't want you to have to download two kernels to test all this
<mxpxpod> :)
<doko_> Mithrandir: hmm, but I'm not allowed to use chvt from the bash package, because it does have a lower priority
<mxpxpod> BenC: would there be any way to get the bluez stuff into the ubuntu kernel?
<BenC> not sure
<mxpxpod> and maybe not even the whole bluez patch, but at least the HID stuff for bluetooth input devices
<mxpxpod> not having my scroll wheel work on my bt mouse sucks
<BenC> have you tried loading hci_vhci?
<fabbione> BenC: did you check the USB ID for your webcam?
<BenC> can't find it
<fabbione> eheh
<fabbione> i started publishing the git tree on my archive dir
<fabbione> http://people.ubuntu.com/~fabbione/archives/qc-2.6.git/
<fabbione> but don't pull from it yet
<fabbione> if the USB ID matches go ahead and play with it
<fabbione> but it's not ready yet for inclusion
<mgalvin> is the kernel still being compiled with gcc-3.4?
<mgalvin> on dapper?
<zul> 4.0 i believe
<zul> or whatever you have on your system..
<zul> in other workds no it isnt :)
<zul> for kicks im going to try xemacs
<fabbione> BenC: git repo needs an ABI bump
<fabbione> or update abi files...
<zul> bleah...ugly
<fabbione> why?
<fabbione> there is nothing wrong in changing ABI
<fabbione> it only takes a few hours to propagate
<zul> sorry i was talking about xemacs
<fabbione> oh great
<fabbione> they just release an update for the quickcam
<BenC> what for?
<BenC> fabbione: if it's the ppc pmf_* stuff, it can be ignored
<BenC> only thing using it is snd-powermac
<mxpxpod> BenC: any luck?
<BenC> mxpxpod: not yet
<mxpxpod> BenC: just checking
<zul> hey guys what do you think? http://zulinux.homelinux.net/ubuntu/grub/image.xpm as a first try
<mxpxpod> BenC: ?
#ubuntu-kernel 2006-01-29
<sn9> 2.6.15-13 segfaults on boot. anybody interested in details?
<cjb> I'm not one of the developers, but I haven't heard of a bug like that; I think you should file a bug report.  Did previous kernels work?
<sn9> it's mostly a breezy system with a few packages from dapper. 2.6.15-9 worked considerably better than the breezy kernel
<sn9> someone evidently borked the keywest i2c driver after that
<sn9> that's what segfaults
<cjb> .. or it's your mix or kernel/userland.
<cjb> s/or/of/
<sn9> i have the dapper udev
<sn9> the system still boots like nothing's wrong, but things that rely on i2c are borked, like alsa
<sn9> dmesg is what revealed the segfault
<mxpxpod> BenC: ping
<fabbione> BenC: no it was firewire and another one that i can't remember
<psusi> fabbione, ahh, you're back from vacation I see?  enjoyed it I hope?  before you left you asked why I reassigned the dmraid bug to you instead of adam conrad?  he said he had no idea why it was assigned to him and that I should switch it to you
<fabbione> psusi: ok, in anycase since the package is in universe you can just ask MOTU to look/upload it
<fabbione> there is no need of me doing it
<psusi> ok....  right now i'm working on properly udebifying it and integrating it into partman... 
<fabbione> i am really of no use for it as it is
<fabbione> i still didn't get to look at the kernel problem i am having
<psusi> kernel problem eh?
<fabbione> = my system doesn't see the disks
<psusi> you aren't using both sata and pata are you?
<fabbione> i only have pata
<psusi> it seems current kernels don't like mixing the two
<psusi> ohh
<fabbione> nothing like that
<fabbione> the controller module is loaded
<psusi> wow, so it just doesn't see the disks at all eh?
<fabbione> but it sees no disks
<psusi> which controller is this?
<psusi> promise?
<fabbione> 0000:00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02)
<psusi> I believe the via module has to program the controller to run in non raid mode for the disks to show up normally, then it hands off to libata... maybe the promise module doesn't do that part?
<psusi> do the disks show up if you tell the bios to use non raid mode?
<psusi> ok... so that is the controller that supports both pata and sata... but you only have pata drives plugged in?
<fabbione> i didn't check anything yet
<fabbione> -ENOTIME
<fabbione> and -ELOWINTEREST
<psusi> I've seen a lot of problem reports about that controller and pata in recent kernels, but I had thought it was from trying to use both at once
<psusi> hehe
<psusi> earlier on in the bug history, you mentioned that it should eventually be assigned to installer-integration I think it was?   is it time for that now?
<fabbione> psusi: not without udeb and main inclusion report
<fabbione> you will need to test it first
<fabbione> + you are doing the installer integration
<fabbione> nobody knows better than you what you are doing
<psusi> ok.... I'll keep working on that then.... I think the udeb is ready... just need to modify partman to use it correctly from the setup cd.... espresso install from livecd should be easy though once that's working
<psusi> I guess I should start working on a main inclusion report then too eh?
<fabbione> psusi: the main inclusion report is a wiki page.. get teh code for partman working first
<psusi> ok....
<psusi> yea, I've seen the page
<dilinger> dapper + cryptdisks (dm-crypt) + 3ware + raid5 (swraid) + 700gb data is giving me such headaches :/
<dilinger> getting random unreproducible read errors
<psusi> poke at it with smartctl?
<dilinger> yea, already did
<dilinger> no smart errors, lm-sensors think everything is fine
<psusi> was getting some odd access denied errors in my daily backups on a server at work the last few days... had smartctl make it do it's long internal test... had a few completely unreadable sectors, and a TON of recoverable errors...
<fabbione> dilinger: meh dude....
<dilinger> psusi: also, rechecking is valid
<dilinger> psusi: ie, flac -t foo.flac will fail the first time, succeed the second time
<psusi> ohh, that's nice
<psusi> anything interesting in dmesg?
<dilinger> but it's about 3 flac files out of about 700GB
<dilinger> nope
<dilinger> kernel doesn't see any errors at all
<dilinger> i've only done smart short tests, though
<psusi> my via controller gets timeouts after I resume from suspend... it seems it needs longer than the kernel is willing to wait to wake back up
<dilinger> i guess i can schedule some long tests
<psusi> increased the timeout duration fixed it
<psusi> do the long one, yea... short doesn't seem to do much
<dilinger> this would be a lot easier if i could reproduce it easier.. as it stands, it takes about 2 days to run the full test
<psusi> also look at smartctl -A... see if it reports a number of recoverable errors
<psusi> why does it take 2 days?
<psusi> takes me ~30 mins on my 10,000 rpm drives here... took ~85 mins on the big 7200 rpm drives on the server at work
<dilinger> 'cause it's 700gb of data :)
<psusi> spread on multiple drives
<psusi> all the drives can be doing their tests at once ;)
<hub> hi
<hub> I have a huge kernel regression
<hub>  /etc/init.d/udev fails on startup
<hub> udevplug seems to be failing
<hub> any clue to help debugging?
<hub> (runnind dapper)
<fabbione> hub: #ubuntu-boot and the fact that udev fails is not necessarely a kernel fault
<fabbione> garbage_: can you please fix your connection? you are bouncing every 5/10 minutes
<oceandead> I'm sorry if I'm in the wrong place but I wasn't sure where to go with this (I didn't want to send email to a list - fearing this topic has already been brought up). Also, I haven't been able to participate in laptop-testing since Breezy Colony3 (will again be testing soon), so I'm also not sure if it's already been included or not. 
<oceandead> Anyway, I was wondering what the status of inclusion of rtl8180-sa2400 wifi chipset drivers might be.
<oceandead> I checked all the mailing list archives I could find but saw nothing about it. Anyway, the sourceforge page can be found here - http://rtl8180-sa2400.sourceforge.net - They (rtl8180-0.21) compiled fine for me under Hoary. I had problems compiling the CVS version under Breezy but luckily a user who successfully compiled them created a .deb package of the compiled drivers for i386. 
<fabbione> oceandead: if it is not in dapper, open a bug in malone
<oceandead> fabbione,  will do 
<oceandead> thanks 
<oceandead> and thank you all for all of your hard work 
<oceandead> be well! 
<hub> crap. somebody replied to me and I didn't get it
<hub> hi all btw
<fabbione> <fabbione> hub: #ubuntu-boot and the fact that udev fails is not necessarely a kernel fault
<hub> fabbione: okay, thanks
<mxpxpod> BenC: how's it coming?
<zul> morning
<zul> http://www.thesmokinggun.com/archive/0123061mugpair1.html
<fabbione> BenC: ping?
<fabbione> hey zul
<BenC> fabbione: pong
<fabbione> BenC: i did test the new amd64-k8 on UP
<fabbione> i still have performance problems when i am doing disk I/O
<zul> hey fabbione 
<fabbione> it's easy to reproduce when running dselect
<BenC> as compared to pre-SMP versions?
<zul> BenC: i got some patches for you later..
<BenC> zul: ok
<fabbione> BenC: yeps
<fabbione> what tests can i do before i leave tomorrow for uk?
<BenC> fabbione: can you recompiled -13 with CONFIG_SMP=n, and give me some numbers?
<fabbione> what numbers do you want?
<BenC> like bonnie or something
<fabbione> i can see a lot of interrupts
<fabbione> really an excess compared to .12
<fabbione> or .15 pre-smp
<fabbione> and the sata_promise doesn't see my disks, but i had no time to bisec that 
<BenC> are they pata disks, or real sata disks?
<BenC> current git will recognize the pata disks now (tested now that I have a promise sata controller)
<fabbione> pata disk on fasttrack that has a sata raid
<fabbione> it's a regression from .12
<fabbione> ah ok
<BenC> should work with current git
<fabbione> will check that with the next upload
<fabbione> 0000:00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02)
<fabbione> this onwe
<zul> brb
<fabbione> BenC: what was the option to disable the SMP2UP and let the kernel run without it?
<BenC> smp-alt-disable
<fabbione> ok
<fabbione> i will see if i can manage today
<fabbione> otherwise it will have to wait when we are back from uk
<zul> bleah..
<mxpxpod> BenC: how goes the suspend
<mxpxpod> BenC: ping
#ubuntu-kernel 2007-01-22
<dilinger> BenC: hey; any reason ubuntu kernels (as of edgy) don't have mmc_block?
<dilinger> ah, nm; i see #30335
<BenC> fabbione: git://ozlabs.org/srv/projects/yaboot/yaboot.git
<AnAnt> does ipw2200 in Edgy support WPA ?
<BenC> AnAnt: it should
<BenC> ask-and-leave
<BenC> love that
<tumbleweed> feisty kernel: PCMCIA Serial card (cellmodem) no longer works:
<tumbleweed> [  164.577689]  cs: pcmcia_socket0: time out after reset.
<tumbleweed> Linux liszt 2.6.20-5-generic #2 SMP Sat Jan 6 09:44:32 UTC 2007 x86_64 GNU/Linux
<tumbleweed> (I suppose I should have added)
<fabbione> you should file a bug in LP
<tumbleweed> ok
<tumbleweed> filed
<Kano> hi, how is responsible for linux-libc-dev?
<Kano> who
<Kano> dpkg -L linux-libc-dev|grep compiler.h
<Kano> that include file is missing
<Kano> please add it
<Kano> needed to compile w-pvrscan
<fabbione> Kano: fix w-pvrscan. compiler.h is not required
<Kano> well it is used for __user
<fabbione> it doesn't exist anymore so userland needs to cope with it
<Kano> thats not correct
<Kano> you have it in the 2.6.20 kernel headers
<fabbione> because it shouldn't be used by userland.. it's a kernel header only
<Kano> usr/src/linux-headers-2.6.20-5-generic/include/linux/compiler.h devel/linux-headers-2.6.20-5-generic
<Kano> in debian it is at the usual position
<fabbione> Debian has .18
<fabbione> a kernel that's 2 releases old
<fabbione> things change in time
<Kano> nope
<Kano> you missed that file even in edgy which had 2.6.17!
<zul> things dont change?
<fabbione> ok.. than we should all be running kernel 2.
<fabbione> 2.0
<mjg59> Uh.
<mjg59> What does w-pvrscan need __user for?
<Kano> dont ask me
<mjg59> It's only usefully defined if __CHECKER__ is set
<mjg59> Just delete any references to it
<mjg59> It ought to build fine
<Kano> ok. will update w-pvrscan
<mjg59> Looking at it, compiler.h is very very kernel-only
<mjg59> Including it in the user headers looks like an error
<mjg59> It really shouldn't be depended on
<Kano> you might be right
<zul> ummm.ok
<jes-o-mat> hi Kano :-)
<jes-o-mat> oh already gone :/
<Khem> Warning, couldn't open module wfb
<Khem> (II) UnloadModule: "wfb"
<Khem> (EE) Failed to load module "wfb" (module does not exist, 0)
<mjg59> Khem: That's an error from X, not the kernel.
<Khem> yeah wanted to put it in ubuntu room wrong tab :) thx
#ubuntu-kernel 2007-01-23
<kmc> hellow
<kmc> question
<kmc> not sure if this is the right place
<kmc> but does anybody know if we will get updated fuse modules
<kmc> to fix this bug
<kmc> https://bugzilla.samba.org/show_bug.cgi?id=3752
<zul> cool...i have my security clearance now..
<zul> i can go see if area 51 is true
<kylem> they had to move it because of you.
<zul> dang it
<CanadianMan> hello there
<CanadianMan> i came here cuz #ubuntu seemed a little over crowded and i think i might beable to get my question answered here
<CanadianMan> is anyone here answering questions?
<gnomefreak> ubuntulog: this is not a support channel
<gnomefreak> damn
<CanadianMan> opps my fault
<gnomefreak> CanadianMan: this is not a support channel
<CanadianMan> sorry
<n0u> is the lastest 2.6.20-5.7 fixed against rpc/krb oops ? (http://thread.gmane.org/gmane.linux.kernel/483786/focus=484322)
<n0u> btw linux-image-2.6.20-* should depends/recommends iptables 1.3.6+ (because of the netfilter changes in .20-rc)
<fabbione> nope it doesn't need to either Depends or Recommends
<n0u> for ex, using a efty 2.6.20 linux image on edgy (with its 1.3.5 iptables) doesn't work well, -m owner doesn't not work
<fabbione> you are not supposed to mix stuff.. and we don't support partial upgrades
<fabbione> either your run edgy or you run feisty
<n0u> ok i shouldn't use a efty kernel on edgy :)
<n0u> anyway, the most important thing is that you take trond's patch into consideration :)
<n0u> i'll find a way to have a recent kernel/iptables on edgy on my own :)
<jwendell> is true that feisty kernel recognizes ide as sata?
<jwendell> s/sata/scsi
<jwendell> like says https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/76194
<jwendell> BenC, is that true?
<Opu> .
<tepsipakki> can someone confirm if dapper kernel supports Intel 82573E gigabit ethernet OOTB?
<tepsipakki> at least the driver (e1000) mentions it, so I guess it's supported
<tepsipakki> I'll just advice the local math department to get Fujitsu Esprimos with those instead of the still non-working Broadcom :)
#ubuntu-kernel 2007-01-24
<\sh> BenC, feisty kernel 2.6.20-5 is not giving me any sound anymore...
<\sh> rebooting into edgy kernel
<gnomefreak> \sh_away: are you sure alsa isnt muted? a few people have complained about one of the updates muting sound
<BenC> \sh_away: If you have a hda conexant codec, it's possible that you need to run alsamixer to fix things up a bit
<gnomefreak> the person that i first heard this from it mutes on reboot
* gnomefreak didnt see any kernel related updates so i kind of ruled that out
<ogra> BenC, ping
<BenC> ogra: Yo
<ogra> can we get via eden support enabled in the -386 kernel ?
<ogra> http://h10010.www1.hp.com/wwpc/uk/en/sm/WF05a/35123-342039-342039-342039-637507-12235620.html
<ogra> i have some users with these
<ogra> they dont boot at all
<BenC> ogra: What's required to enable it?
<ogra> dunno ... i havent looked at the config yet ....
<ogra> i'll find it out
<BenC> -386 is a basic 486 minimum kernel
<BenC> a cpuinfo from the machine would help
<BenC> or from any via eden for that matter
<ogra> ok, i'll try to get one ... but thats a bit tricky without booting indeed :)
<BenC> I know the -386 works on my via proc
<BenC> EPIA M10k
<ogra> the guy having the prob tried his laptop which apparently works, so it must be a kernel option i guess 
<ogra> s/works/boots/
<BenC> It comes with 2.4 linux kernel, so you should be able to get /proc/cpuinfo from the base system
<ogra> ah, k
<ogra> i dont have a -386 config handy, but i think its CONFIG_MVIAC3_2 you need enabled
<ogra> BenC, SiCk is the guy having the problem 
<ogra> SiCk, can you boot into the flashcard on the HP ?
<ogra> and get us the output of cat /proc/cpuinfo ? 
<SiCk> yeah i can ogra
<SiCk> sorry, how do i do that?
<SiCk> i can boot in and get to the console
<ogra> boot the client without net connection i guess
<ogra> great
<ogra> just type "cat /proc/cpuinfo"
<SiCk> ah okay.. one minute, booting thsi up
<ogra> (without quotes)
<BenC> relevant lines are the "vendor_id", "model name" and "flags"
<BenC> cpu family and stepping would be helpful too
<SiCk> will do
<BenC> Can you descibe the failure during ubuntu boot?
<ogra> BenC, it just stops after "Uncompressing Linux..."
<BenC> is quiet and splash disabled?
<ogra> doesnt get to load the initramfs
<ogra> yep
<SiCk> \sh: cat/proc/cpuinfo:
<SiCk> not found
<SiCk> sigh
<ogra> you miss a space
<BenC> space
<ogra> cat /
<ogra> ...
<SiCk> duur Sick
<BenC> is this a netboot?
<SiCk> nope
<SiCk> this is booting off the flashdrive
<BenC> no, the ubuntu boot, is it from network?
<ogra> yes
<SiCk> ah, yes, pxe
<ogra> its an ltsp boot
<ogra> PXE
<BenC> are you sure it's the -386 kernel and not say -generic or -server?
<SiCk> vendor_id: CentaurHauls
<SiCk> cpu family: 6
<SiCk> model name VIA Samuel 2
<ogra> SiCk, can you do a "ls /opt/ltsp/i386/boot/" on the server afterwards ?
<ogra> so we can see you didnt end up with a wrong kernel package 
<SiCk> flags: fpu de tsc msr cx8 mtrr pge mmx 3dnow
<SiCk> yep.. ill do that now
<ogra> just check if there are many files with -386 as suffix ... or if you have -generic instead
<ogra> (should be -386 ... and i would have no explanation why it could be -generic)
<BenC> there should be no reason for it to not boot the -386 kernel...
<ogra> hmm
<SiCk> yeah, most are -386
<ogra> SiCk, any -generic in that list ? 
<SiCk> nope
<ogra> please do the same ls for /var/lib/tftpboot/ltsp/i386/
<ogra> and check for -generic as well there
<SiCk> apparently ther eis no such directory
<ogra> without the i386 then ...
<SiCk> remember this is edubuntu, it likes to move things around
<ogra> are you running edgy or dapper ? 
<SiCk> ah, that's 386 too
<ogra> i object that ... i would know if it would "move things around" :) 
<SiCk> dapper
<BenC> gotta reboot
<ogra> (i maintain it)
<SiCk> ahh haha, explains alot
<ogra> yeah, the missing ../i386/ indicates dapper
<SiCk> *in awe*
<ogra> but even the dapper -386 kernel should work afaik ...
<ogra> SiCk, yure a lucky guy ... we all sit here in a room at the ubuntu developer sprint :)
<SiCk> well i'm officially starstruck
<SiCk> haha
<ogra> SiCk, how critical would it be to set this server up with edgy ? 
<ogra> is it in production already ? 
<SiCk> not at all, we're sitting with another system, it basically works by sending video over cat-5e to plasma screens
<SiCk> we have loads of thin clients doing nothing
<ogra> wait a sec
<ogra> i'm just told we'll get a new kernel package to test ...
<SiCk> so instead of sending it from everywhere we'd like to have them displaying it from the plasma itself, the pc behind the screen
<ogra> so lets wait until thats done and i'll walk you through installing it
<SiCk> sounds good i think.. haha
<ogra> :)
<ogra> oki...
* ogra goes for a smoke then ...
<SiCk> enjoy :)
<\sh> well,,,kernel works again....strange that alsa was setting my headphone jack automagically...but I don't have headphone jack sensing ;)
<SiCk> ogra: any call on the kernel or will it be a while?
<ogra> kylem, ? 
<kylem> still building, shouldn't take much longer
<SiCk> not rushing or anything, i have all day, just wondering haha
<kylem> ogra, http://people.ubuntu.com/~kyle/kernels/ogra/2007-01-24/linux-image-2.6.15-27-386_2.6.15-27.50_i386.deb
<ogra> SiCk, ^^^^ download that one: cd /opt/ltsp/i386/tmp && sudo wget http://people.ubuntu.com/~kyle/kernels/ogra/2007-01-24/linux-image-2.6.15-27-386_2.6.15-27.50_i386.deb 
<ogra> SiCk, then: sudo chroot /opt/ltsp/i386 dpkg -i /tmp/linux-image-2.6.15-27-386_2.6.15-27.50_i386.deb
<SiCk> is this a full install? or just the kernel for the pxe?
<ogra> if thats done, hit ctrl-d to get to the normal system again and run: sudo ltsp-update-kernels 
<ogra> then boot the client
<ogra> thats only a new kernel image
<SiCk> ah okay
<ogra> followin the three steps above should work 
<SiCk> i shall try it
<SiCk> gotta run here for an hour guys
<SiCk> back soon and ill let you know how it goes
<SiCk> back guys
<SiCk> problem with the chroot bit.
<SiCk> setting locale failed
<ogra> ignore
<SiCk> said that twice and then i get
<SiCk> perl: warning: falling back to the standard locale ("C").
<ogra> right, ignore that 
<SiCk> ill go on to the next one then
<ogra> you can as well prefix the sudo dpkg -i with LANG=C
<ogra> that will suppress the warnings
<SiCk> ah okay
<ogra> but you can as well ignore them, they are just wanrings 
* SiCk crosses fingers
<SiCk> it weeeerkkkkss!
<ogra> YAY
<SiCk> ogra you are the greatest. you're loved by 3 people in this room.
<SiCk> and benc
<SiCk> 1 weeee question, i dont mean to push... how do i get this running as kiosk?
<SiCk> and is there software to manage eaach client from the server?
<ogra> SiCk, kylem did all the work, i only pointed you to the right person :)
<SiCk> kylem then, thankyouu!
<kylem> no problemo.
<ogra> SiCk, https://wiki.ubuntu.com/HowtoWriteLTSP5Plugins has a kiosk mode plugin ... look at what it does and do the same to your chroot
<SiCk> i just follow this whole guide then yep?
<ogra> SiCk, that would mean you need to rebuild your client chroot with ltsp-build-client ... following the steps in the code would work without it ...
<ogra> essentially its: install gdm and firefox, add /home and /var/lib/gdm to copy_dirs and rw_dirs in /opt/ltsp/i386/etc/defaults/ltsp-client-setup and set gdm in /opt/ltsp/i386 to autologin for a user you create in there 
<ogra> but anyway, this belongs to #ltsp or #edubuntu, lets not spam the kernel channel :)
<SiCk> ah good point.. see you there :D haha
<mjg59> kylem: Inserting an SD card into the TI readers doesn't generate a hotplug event
<kylem> pourque?
<mjg59> kylem: line 173 of drivers/misc/tifm_7xx1.c
<kylem> if we get a card insertion request it shouldn't be too hard
<mjg59> kylem: That needs to generate a hotplug event that requests tifm_sd.ko somehow
<mjg59> Which presumably requires some sort of modalias magic
<mjg59> Well, requests tifm_sd.ko in the case of it being an sd card
* kylem nods.
<mjg59> Oh, wait
<mjg59> There's a device_register call there
<mjg59> So maybe there is a hotplug event generated
<kylem> hehe
<mjg59> In which case, the bus_id is tifm_sd*
<kylem> ok. i'll beat up whoever our udev person is.
<mjg59> So there just needs to be something to tie that to tifm_sd.ko
<mjg59> Oh, rock
<mjg59> He's just checked in support for memory stick
<mjg59> ...and I've left my machine with the appropriate hardware in .au
<mjg59> kylem: So, uh, can you also update the tifm stuff from svn checkout svn://svn.berlios.de/tifmxx/trunk ? :)
<kylem> possibly.
<mjg59> Oh, no, wait
<mjg59> I may actually have hardware
<mjg59> It's so easy to lose track
<mjg59> Yeah, I win
<mjg59> I'll try to test that later
<kylem> thanks.
<mjg59> MS support would be kind of nice
<kylem> MS?
<kylem> memory stick?
<mjg59> Yeah
<mjg59> Oh, ha
<mjg59> I've only got one memory stick, and this machine will only accept pro
<mjg59> Need to buy some, I guess
<mjg59> Nngh, why is memory stick so expensive?
<zul> how much?
<mjg59> At least 25
<mjg59> As far as I can tell
<Mithrandir> strange, a 256MB memorystick is around 7 here.
<mjg59> The sony removable flash, rather than USB ones?
<Mithrandir> a sandisk stick.
<mjg59> I'm talking about Memory Stick, the Sony equivilent of SD or compact flash
<Mithrandir> yes, so am I
<mjg59> Ah, ok
<mjg59> Sandisk do them? Hm.
<Mithrandir> a memory stick pro, made by sandisk.
<Mithrandir> (not duo)
<mjg59> Yeah, looks like I could just about match that online
<BenC> zul: ping
<zul> BenC: pong
<zul> whats up?
<BenC> zul: Hey dude, have you had a chance to look at the breezy security stuff?
<zul> yeah i was doing it last night im about half way done
<zul> how come?
<sdrik> hello
<sdrik> I've done some testing of latest xen-3.0 and xen-source and want to report a success
<sdrik> I have a 2.6.19-1-generic (i386) dom0 running with 2 gentoo 2.6.16.28 domu and 2 edgy 2.6.17-5-generic domu
<zul> cool
<sdrik> I've done some patching on xen-source for various problems, what should I do with it ?
<zul> sdrik: submit a bug report in launchpad and ill look at it
<sdrik> zul: ok
<sdrik> zul: done
<zul> thanks
#ubuntu-kernel 2007-01-25
<n0u> 2.6.20-rc6 \o/ 
<zul> kylem: -30C outside with the windchill
<Lure> BenC: this simple patch fixes bad state problem on many newer HP laptops: https://bugzilla.novell.com/show_bug.cgi?id=179702#c106
<Lure> Can we get this into Feisty at least?
<Lure> BenC: this is kernel bug about it: http://bugzilla.kernel.org/show_bug.cgi?id=7689
<BenC> 23193 ?        S<     0:00 [ipw3945_w] 
<BenC> 23194 ?        S<     0:00 [ipw3945_d] 
<BenC> mucho better
<BenC> 23193 ?        S<     0:00 [ipw3945_w] 
<BenC> 23194 ?        S<     0:00 [ipw3945_d] 
<BenC> kylem: it's purty now
<Lure> [13:29]  <Lure> BenC: this simple patch fixes bad state problem on many newer HP laptops: https://bugzilla.novell.com/show_bug.cgi?id=179702#c106
<Lure> [13:29]  <Lure> Can we get this into Feisty at least?
<Lure> [13:39]  <Lure> BenC: this is kernel bug about it: http://bugzilla.kernel.org/show_bug.cgi?id=7689
<BenC> "bad state"?
<Lure> BenC: yes, w/o the patch (or modprobe -r psmouse before reboot), you get ACPI parts not working propelly (fans, battery) and slow boot
<BenC> Lure: I have that patc
<Lure> BenC: I did not see it in feisty (git)
<BenC> Atleast I am sure I included this patch at one point, or was considering it
<Lure> BenC: not here: http://zeus2.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob;f=drivers/input/serio/serio.c;h=f0ce822c1028741efabecf0cef37e1e356754eb5;hb=HEAD
<BenC> commit 2365e9585cdc207280bbda4017921aa8b6e5224a
<BenC> Author: Ben Collins <bcollins@ubuntu.com>
<BenC> Date:   Wed Jan 10 14:23:45 2007 -0500
<BenC>     UBUNTU: acpi/osl: Dedicated work queue for notify() execution
<BenC>     OriginalAuthor: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
<BenC>     OriginalLocation: http://bugzilla.kernel.org/show_bug.cgi?id=5534
<BenC>     Bug: 75398
<Lure> BenC: line 974 or so
<Lure> BenC: this is different one - this one helps with fan only
<Lure> this is kernel bug 5534 afair
<Lure> BenC: http://bugzilla.kernel.org/show_bug.cgi?id=5534
<BenC> Ok
<BenC> why isn't this in mainline kernel yet?
<Lure> BenC: the serio patch is for newer HP laptops (dual core and stuff) - I have some developers here that have to switch to Windows ;-(
<Lure> BenC: they are now back on Linux with workaround
<Lure> BenC: not sure - maybe in rc6?
<BenC> if it was, I'd have it here...I'll check
<BenC> Lure: not in -rc6
<BenC> Lure: there were lots of updates in -rc6 for serio...maybe test it when I upload next week, or compile out of git if you want
<\sh> BenC, are you planning to include the nozomi kernel drivers for the newer qualcomm 3G+ umts cards?
<BenC> Only if I get a bug showing me where the source and everything is :)
<\sh> benc: hehe ok :) 
<\sh> BenC, https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/81467
* Starting logfile irclogs/ubuntu-kernel.log
#ubuntu-kernel 2007-01-26
<pwnguin> so how does one use the kernel in the topic?
<tepsipakki> kylem: the new kernel in dapper-proposed works fine with the new tg3 that we have tested, thanks!
<kylem> excellent. i'm glad to hear that.
<tepsipakki> only problem is that I can't install the machine all the way using that kernel, since d-i doesn't know how to fetch stuff from both dapper and dapper-proposed :)
<tepsipakki> but, waiting for the official version
<kylem> you should be able to chroot into the install target and install the kernel from apt just after installing bootloader and just before rebooting.
<fabbione> hem
<fabbione> the installer is NOT supposed to fetch from -proposed
<fabbione> but it does fetch from -updates once the fix is propagated
<tepsipakki> fabbione: exactly, but the kernel-udebs are there
<fabbione> they are only in the pool
<fabbione> but not in the Packages files
<fabbione> (for dapper and -updateS)
<tepsipakki> it does, however, manage to get network up, which is the point
<tepsipakki> fabbione: ah!
<kylem> i don't think new kernels should go into -updates without extensive *extensive* testing.
<kylem> or possibly ever, i'm not really sure what we're going to do with them. the idea seems to be using -proposed to vet patches for merging, not to propogate.
<tepsipakki> kylem: that's cool, tg3 is fine for merging :)
<tepsipakki> fabbione: if the udebs are not in Packages, how did I manage to build d-i with -proposed?
<tepsipakki> or does it matter
<fabbione> tepsipakki: you can build it manually if you have -proposed in your sources.list
<fabbione> but it won't fetch udebs from proposed at install time IIRC
<tepsipakki> yep, ok
<kylem> tepsipakki, what was the bug # for that? have you posted the results to the bug?
<tepsipakki> kylem: not yet. let me find it
<kylem> ok, thanks.
<tepsipakki> https://launchpad.net/bugs/72696
<kylem> BenC, http://acpi.sourceforge.net/documentation/processor.html for the description between acpi P/C/T states.
<BenC> kylem: thanks
<mjg59> http://madwifi.org/browser/branches/dadwifi-openhal - win
<mjg59> kylem: You've got an Atheros, right? Fancy giving that a go?
<kylem> it's back in ottawa and only in minipci form, i'd need to take apart the laptop.
<kylem> i have the new atheros in my macbook though.
<mjg59> Yeah
<BenC> mjg59: sweet
<mjg59> That's what I was thinking of
<kylem> ok.
<kylem> that's hot.
<mjg59> I've got an Atheros somewhere here that wasn't supported with the last version of madwifi I tested
<BenC> I've got access to a laptop with an atheros that doesn't work with 0.9.2 either
<thom> mjg59: doesn't look like that has the pci ids for the core 2 duo MBP atheros part at least :/
<mjg59> thom: Easy to add
<mjg59> At least with openhal, we have /some/ chance of being able to get something working
<kylem> the MBP atheros needs a new HAL.
<mjg59> Does it need a new HAL, or does it need new IDs adding to the existing code?
<thom> mjg59: new HAL
<mjg59> Oh!
<kylem> i think a new hal.
<thom> mjg59: http://madwifi.org/ticket/1001
<mjg59> Rip it out of the macos X driver
<mjg59> It's madwifi based
<kylem> hmm. not a bad idea.
<thom> mjg59: ORLY? nice
* kylem is wondering how much trouble it would be to add ipw3945 support to OS X.
<kylem> so i can just replace the damned card entirely. :)
<mjg59> Or try hacking up openhal
<mjg59> I suspect that it's not actually that different
* kylem wonders what would be more work
<kylem> adding ipw3945 to macos, or making power management in linux not suck.
<Mithrandir> the former, so you should do the latter.
<gnomefreak> does dapper have an xen kernel?
<kylem> Mithrandir, heh. :)
<BenC> gnomefreak: nope
<BenC> mjg59: I think mine needed new hal...I added the ID's to current madwifi and it just crashed
<gnomefreak> BenC: we got people wanting a libc6-xen for dapper's existing version of glibc  and they were told not gonna be backported and they dont understand why
<BenC> gnomefreak: Because dapper can't run as a xen guest would be my best answer
<mjg59> BenC: Right, the current hal will refuse to run on them
<gnomefreak> k
<mjg59> That doesn't necessarily mean that there are significant differences
<BenC> and if they are compiling their own domU kernels, they can compiler their own libc6 too :)
<tepsipakki> hrm, my feisty-desktop is resetting the sata-port constantly when under load, should I blame the hardware or something else?
<kylem> mjg59, i'll go fetch my macbook from my hotel room after lunch and try to rip out the hal.
<Mithrandir> gnomefreak: because feisty has a completely different glibc version and we don't backport core libraries.
<gnomefreak> they were told that ;)
<mjg59> kylem: Hm. Though reading that bug, I'm not sure what's going on.
<mjg59> Apple may have changed to a new driver design.
<Mithrandir> yes, and I didn't see a response signifying that they didn't understand why glibc would not be backported.
<mjg59> Certainly older versions gave identical hal errors to Linux if you tried to run on an unsupported card
<gnomefreak> Mithrandir: came back with just the xen patches to create a libc6-xen for dapper's existing version of glibc
<kylem> mjg59, i toss binutils at it and see what sticks.
<gnomefreak> either way it means backporting core libs
<Mithrandir> gnomefreak: then that'd not be a backport, but a stable release update.  I doubt we would accept an update for such a core package to support functionality not in dapper.
<tepsipakki> it's normal that 2.6.17 won't boot on feisty? I'd like to debug the sata_sil reset thingie more..
<tepsipakki> http://lkml.org/lkml/2007/1/3/144
<kylem> gentoo users are muppets
<kylem> The Core2Duo is an improved Pentium 4 with 64 bit extensions (x86-64). Thus with GCC 4.1 the nocona architecture is the one to use in 32 bit mode:
<kylem>   CHOST="i686-pc-linux-gnu"
<kylem>   CFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe"
<kylem> (news at 11, i suppose)
<mjg59> Oh dear.
<thom> *boggle*
<zul> er..ok
<Mithrandir> they should use -pipe -pipe -pipe for better optimisations.
<kylem> if they'd just used x86-64, they wouldn't need -fomit-frame-pointer and get debuggability /and/ more registers still...
<kylem> not to mention just how wrong using a pentium4 instruction scheduler in core2 is
<mjg59> They've confused Core2 and Pentium D
<mjg59> The fact that Intel released two entirely different series of dual-core 64 bit CPUs probably didn't help
<kylem> only one of them was actually worth buying.
<mjg59> Well, yeah
<kylem> groo.
<zul> BenC: uploaded and emailed
#ubuntu-kernel 2007-01-27
<Slart> I've got a kind of general question about the linux kernel, is there a better channel for that kind of questions?
#ubuntu-kernel 2007-01-28
<zul> BenC: long shot...ping
#ubuntu-kernel 2008-01-21
<brandon> #ubuntu-sound
<brandon> hey, im just here on my quest to get sound to work on my laptop
<brandon> how do i use kernel?
<ripdisk> i need some help getting your kernel to boot, it's telling me it attempted to kill the idle task
<ripdisk> this is for the live cd
<ripdisk> i'm trying to install on an old laptop
<kraut> moin
<ripdisk> i guess nobody has anything to say about the kernel panic i'm getting, then
<Kano> hi
<Kano> hi rtg 
<Kano> when can we expect removed ids from bcm43xx and prism54 and iwl39/49 in lum?
<rtg> Kano: I am unaware of this issue. Have you started an LP report?
<rtg> Kano: in particular, what is wrong with iwlwifi?
<Kano> bcm43xx and ssb share same ids (ssb is used for the b43* drivers and works usually better)
<Kano> rtg: nothing is wrong with iwl, but it is disabled in the kernel - marked for inclusion in lum
<rtg> Kano: right, but I have not upload either for build. I have some other stuff to work on before I'm ready to upload.
<Kano> also the old prism54 module + new p54pci share use same ids, so remove it for both old modules
<Kano> rtg: they are disabled in git and when you build it you get no iwl..
<rtg> Kano: I'm aware of that, but the git repo is not in a consistent state at the moment.
<rtg> I'll get to it this week.
<Kano> waiting for it
<majikins> hi can anyone help me with a raid1 lvm setup on ubuntu server 7.10?
<majikins> when I test by removing one drive, i get dropped into initramfs prompt
<majikins> I've googled and have ensured that that the module file includes md and raid1
<majikins> ran update-initramfs -u as well
<majikins> now I'm stuck
<Kano> what do you use as root option
<majikins> I don't know what to answer to that? I'm a noob and followed a howto to get lvm and raid setup
<Kano> usually you get that problem when the root partition is not found. this can be specified using uuid or /dev/mappper/... in case of lvm
<majikins> ok - pls can you help me specify that - where do I go to?
<Kano> that was a general hint, i only use u kernels, not u itself
<smb> abogani: Hi Alessio, I wanted to quickly follow up on my mail about audit settings. Do you think audit syscall should be configured for -rt?
<abogani> smb: Stefan sorry for my poor english and for missed replay.
<abogani> smb: At the moment if audit syscall is or isn't configured it is unimportant for -rt.
<abogani> smb: Feel free to do the most convenient thing for you. Anyway i prefer to remain stick on -generic's configuration as soon as possible.
<abogani> smb: Thank you and sorry again for missed replay.
<abogani> s/soon as/
<smb> abogani: Alessio, no need to apologize for your english. Mine isn't perfect either. Ok, so (since i just added this to -generic) I will modify the -rt configurations as  well. Thanks.
<abogani> smb: Thank you for your kindness. 
<smb> abogani: Just noticed you already did the change yourself. Sorry for the bother then.
<laga> Kano: hey, do you use aufs or unionfs for your live disks?
<Kano> well i did some testing
<Kano> standard kanotix does not rely on unionfs or aufs, just when you want it you can enable it
<laga> Kano: i did some testing, too, and found unionfs 1.4 (which is in ubuntu) to be unusable with nfs branches. i was just wondering if you made aufs work on ubuntu's 2.6.24 :)
<laga> Kano: interesting. what do you use instead? symlinks to a tmpfs?
<Kano> but for next gen i need it. an image with network-manager does not work when unionfs is used but aufs makes network-manager working
<Kano> debian live based it is just a switch to set it to aufs or unionfs
<laga> nice
<Kano> i added the security perm patch to be able to compile aufs
<laga> adding such a switch is not hard, especially when you compile aufs with unionfs compatibility.
<Kano> you just need to add 2 files to the headers manually as they are not there by default
<laga> Kano: on ubuntu's 2.6.24?
<Kano> the standard headers are not enough
<Kano> i guess you could go without the c file if you put it into lum
<Kano> as it is only grepped
<laga> i wanna put it into lum, but i need to convince the kernel people first i suppose. also need to add some patches to the kernel itself as you said.
<Kano> one patch
<Kano> if you like i can create 2 kanotix ng images
<laga> Kano: do you still have your aufs source tree? i'd be interested in a copy. compilation is broken with the ubuntu kernel because of apparmor patches (IIRC)
<Kano> with your latest kernel
<Kano> i fixed compiliation of course, when you add the 2 files
<laga> Kano: i'm not an official kernel developer, i just need aufs for my work on mythbuntu
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-future/source/sec_perm-2.6.24.patch
<Kano> thats the only patch needed
<Kano> http://kanotix.com/files/thorhammer/updates/aufs/aufs_0+20071217-0+c0.kanotix.1.dsc
<Kano> latest snapshot patched for apparmor
<laga> Kano: thanks a lot! i'll take a look
<laga> debian/patches/06_remove_ia_file.dpatch - heh, i tried the same hack. does that work for you?
<Kano> the added patch is 05
<Kano> and 06
<Kano> maybe 06 is not needed anymore
<Kano> did not check
<laga> 06 is still needed last time i looked
<laga> ie there's no ia_file member anymore
<laga> (in the ubuntu kernel)
<laga> now that i think about it, maybe my problems were caused by some other missing patches.
<Kano> well i adopted the 05 patch from the old aufs from ubuntu
<Kano> fixed positions
<laga> Kano: i was talking to the aufs guy and he recommended some additional patches. i can forward the mail if you want to
<Kano> i wanted to write him too,but my mail was rejected
<laga> did you sign up on his mailing list?
<Kano> nope
<laga> if you want to send email there you have to sign up
<laga> your email address is master at kanotix dot com, right?
<Kano> yes
<Kano> thats not the adress i use to "write" but to get mails
<Kano> is basically only a forward
<laga> got mail
<Kano> laga: btw. i patch my kernels even with dmraid45
<Kano> updated dmraid of course too
<laga> dmraid is for those "fake" raid adaptors, right?
<Kano> yes
<Kano> ubuntu does not support raid level 5
<laga> raid 5 sounds nice. too bad i'm too cheap for that :)
<Kano> did not try it myself yet
<laga> ok, i need to run now. thanks a lot for your help, i'll try the patches ASAP.
<Kano> but patched the kernel even for 2 ubuntu users + updated dmraid for em *g*
 * laga wonders why make-kpkg produces kernel packages > 220MB with linux-sources and default ubuntu config while leaving
<Kano> laga: take a look at my scripts
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-future-pure/source/
<Kano> get-source*
<Kano> these compile a patched kernel, you can even add rc8 git patches with ease
<zdzichuBG> I believe getting http://lkml.org/lkml/2008/1/17/544 into Hardy kernel is out of question?
<Kano> splice-2.6.23.patch, put_filp.patch, and deny_write_access.patch.
<Kano> did you use those?
<Kano> i think some of em are autenabled
<Kano> hmm these are kernel patches, maybe i should add em too
<abogani> rtg: Are you around?
<abogani> rtg:  I have founded this meta-package: linux-image-debug-rt. Do you want provide a debug version for -rt kernel flavour? BenC always refuse to provide it...
<BenC> abogani: and we will still refuse to do so :)
<BenC> abogani: that's a huge package to keep around, plus I'm not sure the binary-custom build can handle DEBUG=y kernels+modules
<abogani> BenC: :)
<abogani> BenC: Could you cut out that meta-package?  For avoid to confuse users... Thanks.
<BenC> rtg: you get that?
<rtg> BenC, abogani: np.
<BenC> rtg: thanks
<abogani> rtg: Thanks! 
<rtg> abogani: linux-meta uploaded
<abogani> rtg: Thank you very much.
<Kano> rtg: when do you add iwl to lum?
<rtg> Kano: before I do the next upload.
<laga> Kano: thanks for your script, i'll try it in a few minutes. have you had the chance to add those additional patches?
<Kano> did not try, want to wait for the fixes i proposed
<Kano> but nobody likes to do those it seems
<laga> :)
<laga> ok, i'll add those patches then
<Kano> best add latest git patch too
<laga> no, i want to use a plain ubuntu kernel
<_MMA_> Hi guys. I having a user asking about using more than 3GB of RAM on -RT and -generic. Says server kernels do. Since I don't have 3GB of RAM and haven't had this issue I don't know what to say.
<stgraber> he can either switch to amd64 kernels (which shouldn't have the problem) or use the server kernel, highmem is AFAIK not enabled on other kernels
<crimsun> yes it is.
<crimsun> grep -i highmem /boot/config-2.6.24-4-generic  =>  CONFIG_HIGHMEM4G=y
<mjg59> crimsun: If it's mapped above 4GB (because there's PCI stuff in the way, or whatever) then it might need CONFIG_HIGHMEM64G
<crimsun> hmph, we don't enable 2/2 or full or whatever
<mjg59> That's not relevant for highmem
<mjg59> The 3:1 split is fine
<crimsun> no, the full option or whatnot
<mjg59> Mm?
<crimsun> oh, nevermind, misread the help.
<mjg59> It wouldn't help - with CONFIG_HIGHMEM4G you're still limited to 4GB of physical address space
<mjg59> And PCI has to fit in there
<crimsun> (the VMSPLIT_2G_OPT, which isn't even relevant here)
<mjg59> So many BIOSes leave a hole between 3 and 4GB and put the PCI stuff in there, and then map the RAM up >4GB
<mjg59> Which means you need CONFIG_HIGHMEM64G to get at it
<crimsun> fun
#ubuntu-kernel 2008-01-22
<tjaalton> hmm, new fglrx and nvidia drivers, I could update the l-r-m
<tjaalton> and fix other bugs as well
<tjaalton> fwiw both nvidia/fglrx are bugfix releases
<Kano> hi, did you notice that nvidia 169.09 is out now?
<kraut> moin
<xivulon> are you guys aware of http://lkml.org/lkml/2008/1/9/50 ?
<xivulon> don't seem to find any related bug in launchpad, do you think a new one is worthy?
<xivulon> that affects the windows-installer among other things
<BenC> xivulon: looks interesting, but I'm not sure we will take it as an out-of-tree patch
<BenC> xivulon: is it not in 2.6.24?
<zdzichuBG> BenC: same for http://lkml.org/lkml/2008/1/17/544 ?
<xivulon> BenC don't know whether it landed in 2.6.24
<xivulon> As mentioned it affects Wubi, Xen and other VM so an hardy patch would be handy
<BenC> xivulon: but it is quite extensive, and the regressions for normal use are unknown
<xivulon> BenC could that be switched on/off at runtime?
<BenC> xivulon: I patch for that would be better, but still unsure if we will accept it
<BenC> xivulon: generally we steer clear of patches to the core kernel
<xivulon> BenC kernel issues are beyond my skills I can only point things out
<laga> hi. i've tested the l-u-m update in #103044 and found some problems. i tried to do some triaging but i'm not sure if i've provided enough information. maybe someone in here can tell me if anything else is needed :)
<blueyed> Do you plan to use FAIR_CGROUP_SCHED instead of FAIR_USER_SCHED?
<blueyed> See https://bugs.edge.launchpad.net/ubuntu/+source/boinc/+bug/177713/comments/20
<ubotu> Launchpad bug 177713 in boinc "CFS in 2.6.24 kernel needs cpu_share adjustment for "niced" processes" [Medium,Confirmed] 
#ubuntu-kernel 2008-01-23
<ObsidianX> whats the actual binary that is the Power Manager app
<ObsidianX> i can't find it for the life of me
<ObsidianX> and i can't stand it
 * lamont grumbles.  I want -jDNAT for ipv6
<clever> lamont: but why?:P
<clever> with ipv6 you should be able to get a public ip for every system behind the 'router'
<lamont> clever: because I want to divert traffic bound for (say) $WEBSERVER to a local copy, or ditto for other traffic
<lamont> DNAT has nothing to do with SNAT
<clever> ah
<clever> i mainly use dnat for port forwarding
<clever> trafic from the web coming in geting directed to lan ip's
<lamont> that too.
<lamont> DNAT lets me have simpler firewall rules..
<lamont> mind you, before we get ipv6 DNAT, ip6tables needs to believe in -t nat...
<RAOF> Is there anything more I info can do for bug #184712?  Losing ACPI is annoying :(
<ubotu> Launchpad bug 184712 in linux "[regression] Asus F3Jm fails to work correctly without acpi=off" [Undecided,New] https://launchpad.net/bugs/184712
<mjg59> RAOF: Looks like it's stopping in acpi_early_init
<RAOF> mjg59: Ok.  What sort of extra info would be useful here?  PArticularly since this seems to affect previously-working kernels, which has me perplexed.
<mjg59> Yeah, nothing springs to mind
<RAOF> There wasn't a recent initramfs-tools update?  Could that even cause this problem?
<mjg59> Oh, hm. No, it's getting into timer setup.
<mjg59> Or possibly not
<mjg59> I'm afraid it's a bit hard to figure out where it's actually dying
<RAOF> The kernel doesn't happen to have an excesively_verbose option? :)
<mjg59> Are you able to build your own kernels?
<RAOF> I'm not set up for it, but I could.  I've done it before.
<mjg59> Ok
<mjg59> If you could grab the source and add something like
<RAOF> Oh, except the kernel building process has changed since then, I think.  I'll see :)
<mjg59> printk("Successfully enabled ACPI\n"); to drivers/acpi/bus.c in acpi_early_init after the acpi_enable_subsystem line, that would be great
<mjg59> Then we'll know whether it got out of ACPI or not
<RAOF> Ok.
<RAOF> Would you like me to build from Ubuntu git, or from the linux-source package?
<mjg59> git's probably a better bet
<RAOF> Right.
<RAOF> Man it takes a long time to git clone the kernel!
<lamont> RAOF: depends on how fast your link is... 200+MB takes a while
<RAOF> Well, it's clearly not saturating my local connection.  On the other hand, kernel.ubuntu.com is unlikely to be in .au
<lamont> rather
<lamont> san francisco from my trace
<RAOF> Well, it's done.  Now I can spin my CPU building it instead.
<Kred> Hi, I want to supply more details of a ACPI related bug that is already reported on Launchpad. Wiki tells me to supply tarball of /proc/acpi/ but fails to explain what commands to issue.
<Kred> When I try to tar it I get device busy
<Kano> hi
<RAOF> mjg59: Well, that took longer than I expected.  Also, nothing extra got printed out; it looks like it's hanging before it's hanging before acpi_enable_subsystem returns in acpi_early_init.
 * RAOF goes to update the bug.
<Kano> why are still iwl modules not in lum?
<RAOF> Kano: They are in my l-u-m-2.6.24-4-generic?
<Kano> they are diabled in kernel config and not in lum
<RAOF> Ah, sorry.  No they're not.  The firmware is there, and the modules are in linux-image-2.6.24-4-generic
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=a07606c45a19754bfd05e0cc2abff32207c5736c
<Kano> UBUNTU: Disabled iwlwifi preperatory to moving it to l-u-m.
<Kano> but they never arrived in lum
<tjaalton> ugh
<tjaalton> that's not released yet
<Kano> nad
<Kano> you can never release when you dont do that
<Mithrandir> Kano: whining about not-released source not being in sync is not helpful.  It'll be moved into lum before the next upload.
<Kano> that changes was made 6 days ago, i dont get what you are waiting for
<tjaalton> I'm pretty sure they know what they are using
<tjaalton> uh, doing
<Mithrandir> if you're building stuff from git and it's a problem for you, don't pull that commit.
<RAOF> In the unlikely event that someone's searching 'round for a bug to investigate with someone on the other end, I'm available for testing anything anyone can think of for bug #184712.
<ubotu> Launchpad bug 184712 in linux "[regression] Asus F3Jm fails to work correctly without acpi=off" [Undecided,New] https://launchpad.net/bugs/184712
<Kano> and no changes in bcm43xx and prism54 yet
<mjg59> RAOF: In that case, it sounds like it's hanging while enabling ACPI. Which is bizarre.
<mjg59> RAOF: You can prove that by sticking another printk just before the acpi_enable_susbsystem line
<RAOF> About as bizzare as the fact that it's affecting older kernels that used to work fine?
<Kano> i would let him try thorhammer rc7 with a kernel without config-ide
<RAOF> I'll stick that extra printk in.  And wait for the kernel to build.
<mjg59> Kano: ...
<mjg59> Kano: Have you actually *read* the bug?
<RAOF> mjg59: Any other printk's you'd like smattered around?  It takes me some time to build the kernel :)
<Kano> mjg59: standard kernels often stop with that message
<mjg59> RAOF: I'm pretty certain it's in there. If you want, you can spread some through acpi_enable_subsystem.
<mjg59> Kano: This is before any code affected by #ifdef CONFIG_IDE has been executed
<mjg59> Kano: We're still in init/main.c
<Mithrandir> RAOF: use ccache; that helps at least.
<mjg59> RAOF: TBH, I'd suspect BIOS weirdness at this point more than anthing else - can you try resetting that to defaults?
<RAOF> mjg59: As a part of a futile attempt to flash the bios, I already have.
<mjg59> RAOF: Hm
<mjg59> RAOF: Is the machine Ubuntu-only?
<RAOF> Yup.
<mjg59> Really, really weird.
<RAOF> Otherwise I could've flashed in Windows rather than wrestling with the "ez-updater" thing which apparently doesn't do anything at all.
<RAOF> I could possibly find some sort of windows rescue disk if it'd be useful.
<RAOF> mjg59: Right.  For those playing at home, my laptop locks up at the very start of acpi_enable_subsystem, and I've now flashed the bios to the latest version and it *still* happens.
<Toma-> https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/184788
<ubotu> Launchpad bug 184788 in linux-ubuntu-modules-2.6.24 "rtl8180 and rtl818x disabled in kernel Makefile" [Undecided,Confirmed] 
<Toma-> any chance of seeing those in Hardy?
<RAOF> Right.  For my final check, I'll try adding a DSDT file from the internest.
<rtg> Toma-: the rtl wireless drivers are enabled in the Hardy kernel.
<Toma-> rtl818x?
<Toma-> its in the source, but blocked by the makefile
<rtg> Toma-: CONFIG_RTL8187=m
<Toma-> yes indeed.
<Toma-> and rtl8180 and 818x?
<Toma-> its in linux-ubuntu-modules
<rtg> Toma-: Since the RTL family is upstream in 2.6.24, I do not intend to put them in lum.
<Toma-> 0_o
<rtg> Toma-: unless I end up backporting 'cause the upstream drivers don't work.
<Toma-> ok 
<RAOF> And for those playing at home, a custom dsdt from the internet fails to make any difference.
#ubuntu-kernel 2008-01-24
<RAOF> mjg59: You might be interested to know that ACPI worked this boot, for no obvious reason.  
<genewitch> What is the latest stable distro of ubuntu that uses a 2.4.x kernel?
<n2diy_> genewitch: curious, what is wrong with 2.6?
<RAOF> genewitch: I think the answer is "never".
<genewitch> Doesn't support my touchpad, but 2.4 kernel does (verified)
<RAOF> genewitch: From memory, Hoary had the option of a 2.4 kernel, but defaulted to a 2.6
<genewitch> oh ubuntu is young :-)
<RAOF> *Yes*
<genewitch> I wanted to install it with 2.4, and compile up to 2.6 if at all possible.
<genewitch> Sigh, i hate fedora, but thanks anyhow. i'll check hoary.
<n2diy_> genewitch: Sounds like you need a module, not a kernel?
<genewitch> May i query you?
<n2diy_> who me? yes.
<kraut> moin
<rtg> BenC: is there any reason that we shouldn't be using CONFIG_BLK_DEV_PDC202XX_NEW=m ?
<BenC> rtg: because we have a lib-pata driver that supports those devices
<rtg> BenC: not only that, but BLK_DEV_OFFBOARD is deprecated. missed that.
<rtg> abogani: have you tried the -rt build on hardy since I rebased yesterday?
<Kano> rtg: it seems you reverted iwl
<Kano> how about the bcm43xx + prism54 pci id remove?
<rtg> Kano: if you would file a LP report with the list if offending ID's, I would be happy to make that fix.
<Kano> rtg: very easy: all
<Kano> modinfo -F alias ssb bcm43xx
<Kano> are the same
<Kano> modinfo -F alias prism54 p54pci
<Kano> same for those
<abogani> rtg: No. Should i look in it?
<Kano> ssb is the loader for the new b43* modules. maybe add the firmware...
<rtg> abogani: there are a couple of FTBS issues. I fixed one, but now there is another compile error. Can you look at it?
<abogani> rtg: Ok.
<abogani> rtg: with fixes kernel compile and running fine here. Do you want an email based request pull as usual?
<rtg> abogani: applied. thanks.
<rtg> zul: how are those xen patches coming?
<zul> they are oming
<superm1> rtg, i was going to ask if there is going to be a plan for getting unionfs to be playing nicely with nfs for this LTS?
<rtg> superm1: from kees: ' rtg: AA upstream got back to me -- they have a fix and an update for the unionfs 1.2 branch too.'
<superm1> yay :)
<laga> yay
<laga> (great. almost had my workaround ready ;))
<rtg> superm1: I just uploaded a -5 kernel, but might be able to do it again tomorrow if it doesn't cause an ABI bump.
<laga> rtg: is there a patch somewhere?
<rtg> laga: thats what kees implied, but I haven't seen it yet. tomorrow...
<laga> rtg: good. thank you.
 * laga really appreciates that :)
<Kano> rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/185719
<ubotu> Launchpad bug 185719 in linux "remove duplicate pci ids bcm43xx/ssb prism54/p54pci" [Undecided,New] 
<Kano> you wanted it
<Kano> btw. there is a fix for a but i reported against gutsy
<Kano> which should be in mesa cvs
<Kano> affects hardy too
<frederico> xit
<frederico> sorry, wrong terminal, was a exit...
#ubuntu-kernel 2008-01-25
<CalvinH> is this the right channel to be asking nfs-kernel-server type questions
<CalvinH> ?
<kraut> moin
<Kano> hi could somebody merge 2.6.24 final + patch the bcm43xx + prism54 driver?
<Kano> https://www.directbox.com/sites/mybox/readentry.asp?FID=1109297&MID=220479520&OID=31
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/185719
<ubotu> Launchpad bug 185719 in linux "remove duplicate pci ids bcm43xx/ssb prism54/p54pci" [Undecided,New] 
<Kano> this
<RAOF> mjg59: And for the final weirdness in my ACPI saga, the laptop boots just fine if it's on battery, but not if it's on AC.
<rtg> Kano: patience 
<zul> this is probably not a good thing http://pastebin.ca/872062
<abogani> you make shudder to me
<amitk_> zul: is that a fix for XEN?
<zul> amitk_: yep
<zul> doing a test build now
 * amitk_ cringes
<mjg59> RAOF: Excellent. How m,ad.
#ubuntu-kernel 2008-01-26
<RAOF> mjg59: In fact, it's a even better: boot it up on AC, and it'll hang, _until_ you unplug it.  Then it continues as if nothing had happened.
<justin111> hi i have a problem that is related to the kernel (im pretty sure) and noone will help me from the normal ubuntu channel
<justin111> can anyone here help me
<justin111> hellllo
<RAOF> justin111: This channel isn't really for support.  Have you filed a bug on launchpad?
<bullgard4> "detlef@MD97600:~$ /usr/bin/lshal > ~/tmp/lshal.out" prints a line "Dumping 92 device(s) from the Global Device List:" What program compiles the 'Global Device List'? 
<kraut> moin
<Kano> hi, with the generic kernel i have dma off for my dvdrw drive
<Kano> i would suggest to use more pata drivers - best: all
<Kano> thats what i did for latest kanotix kernel
<Kano> and disable config_ide completely
<nturner> What is the plan for bug 164231?  The NFSv4 crash regression has been in the field for over a month, and it's not clear from that bug report (or any of the duplicates) that there is a plan to upload a fix.  
<ubotu> Launchpad bug 164231 in linux "NFS regression causes subsequent mounts from same superblock to silently use previous mount options" [High,Confirmed] https://launchpad.net/bugs/164231
<nturner> I'm sure there is a plan, and it would probably be comforting to many people if someone with authority posted short summary of said plan to that report.  =)
<laga> any news on the unionfs update that was supposed to happen a few days ago?
<laga> i'm referring to bug #103044
<ubotu> Launchpad bug 103044 in linux-ubuntu-modules-2.6.22 "kernel oops during boot on a nfs root diskless system, SRU TEST CASE" [High,Confirmed] https://launchpad.net/bugs/103044
#ubuntu-kernel 2008-01-27
<MidMark> hi guys, I've a 100% system lockup when inserting my broadcom 4311 wireless pcmcia card in hardy 2.6.24-5
<MidMark> is it normal?
<ln-> what does " Declined  for Dapper  by Kees Cook  "  mean?
<ln-> in this context: https://bugs.launchpad.net/bugs/cve/2006-7229
<ln-> and why?
<Nafallo> ln-: ask kees
<ln-> but what does it mean?
<Nafallo> ln-: that you should ask kees
<ln-> i don't see any keeses around here.
<Nafallo> channels : #ubuntu-server #ubuntu-bugs #ubuntu-motu  #ubuntu-devel
<ln-> m'kay
<crimsun> most of the core team is returning from London, so they may not be active until Monday business hours EST
<Nafallo> ugh! have they been here :-/
<calc> crimsun: and US people probably won't be active until Tuesday, since they had to work on their holiday
<crimsun> interesting.
<calc> crimsun: last Monday was MLK Day in the US so most switched their day off to this next Monday
<crimsun> right, I worked that day.
<SR71-Blackbird> is the ability to govern hardware as in controlling volumes and stuff fall under kernel development? I upgraded to the .24-5 and the volume control on my laptop isn't working. I was wondering if it is supposed to be a kernel related issue or just devel issue.. to file report
<Nafallo> SR71-Blackbird: volumes? partitions?
<Nafallo> oh. sounds.
<Nafallo> kernel or alsa. it will be pointed at the approciate package if youfile it wrong anyway.
<Nafallo> or crimsun might help ;-)
<crimsun> SR71-Blackbird: depends on the audio hardware.  What is yours?
#ubuntu-kernel 2009-01-19
<Kano> apw: did you read my mail about the blacklight patch?
<apw> you have asked for a revert yes?
<Kano> yes, because it is impossible do disable that patch
<Kano> for those which do not need it
<apw> .28 is out of sync with what is in .27 and we need to resolve that as part of a sensible fix for the whole thing
<Kano> also i wrote a 2nd mail about rt2860+rt2870, which works fine as backport from 2.6.29
<ivoks> i've sent a patch for drbd 8.3.0 on mailing list, but it's too big; could that one get included, so that we could merge newer drbd?
<Kano>  i got the same error, then i just added a link to my server
<Kano> but basically it is just from 2.6.29...
<ivoks> will do that next time :)
<Kano> apw: could you revert it until you find a better solution
<bcurtiswx> hey, is there anyone from the kernel team here?
<bcurtiswx> i have a bug i would like to discuss with someone
<smb_tp_> bcurtiswx, which bug?
<bcurtiswx> bug #277924
<ubot3> Malone bug 277924 in linux "kernel cannot find map file" [Undecided,Confirmed] https://launchpad.net/bugs/277924
<bcurtiswx> I don't know what else the kernel team would want in there, plus theres a "fix" mentioned at the end of the comments... 
<bcurtiswx> i can't push an importance on it, and i won't triage it until i get confirmation that the kernel team has enough information to fix it
<smb_tp_> bcurtiswx, let me just scan trhough that
<bcurtiswx> smb_tp_: ty
<smb_tp_> Hm, there seem to be two possible faults or solutions in there. One that claims the path is wrong and another saying rootdelay would change things. Can you tell me which is the case in your case?
<bcurtiswx> smb_tp_: well i haven't tested the rootdelay fix, i can if u would like.  All the rootdelay fix would suggest is that the kernel tries to find the system map too early.  I don't beleive the path is incorrect
<smb_tp_> I might have an influence if /boot is another partition than /, just by changing timings a bit. How is yor setup there?
<bcurtiswx> Disk /dev/sda: 500.1 GB, 500107862016 bytes
<bcurtiswx> 255 heads, 63 sectors/track, 60801 cylinders
<bcurtiswx> Units = cylinders of 16065 * 512 = 8225280 bytes
<bcurtiswx> Disk identifier: 0x9fee4f19
<bcurtiswx>    Device Boot      Start         End      Blocks   Id  System
<bcurtiswx> /dev/sda1   *           1       59681   479387601   83  Linux
<bcurtiswx> /dev/sda2           59682       60801     8996400    5  Extended
<bcurtiswx> /dev/sda5           59682       60801     8996368+  82  Linux swap / Solaris
<bcurtiswx> that was an fdisk -l
<bcurtiswx> the following is my df
<bcurtiswx> Filesystem           1K-blocks      Used Available Use% Mounted on
<bcurtiswx> /dev/sda1            471864592  32801912 415093300   8% /
<bcurtiswx> tmpfs                  1535548         0   1535548   0% /lib/init/rw
<bcurtiswx> varrun                 1535548       124   1535424   1% /var/run
<bcurtiswx> varlock                1535548         0   1535548   0% /var/lock
<bcurtiswx> udev                   1535548      2892   1532656   1% /dev
<bcurtiswx> tmpfs                  1535548       296   1535252   1% /dev/shm
<bcurtiswx> lrm                    1535548      2384   1533164   1% /lib/modules/2.6.27-11-generic/volatile
<smb_tp_> Looks like the default one disk autopartitioned one
<bcurtiswx> yup
<smb_tp_> Ok, I see it in the syslog on jaunty as well. Though the next line about symbols suggest it got system map somehow. Maybe you could verify the rootdelay. If that helps this is probably something timing replated in either grub or the init script. But probably grub. That is quite early in the boot 
<bcurtiswx> ok i will test it out, be right back
<bcurtiswx> smb_tp_ that did not fix the problem
<smb_tp_> bcurtiswx, Ok, would have been strange if it did
<bcurtiswx> smb_tp_: suggestions on importance of bug and if it has enough info for triage
<bcurtiswx> smb_tp_: ?
<bcurtiswx> smb_tp: wb
<smb_tp> bcurtiswx, Sorry, IRC doesn't like me today
<bcurtiswx> smb_tp: no problem, IRC hates everyone.  Do you have launchpad permissions to change importance of that bug?
<smb_tp> About this bug. I think it can be counted as triaged. Importance is low I would say  since it does not really affect usability of the systems
<Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/char/agp/intel-agp.c;h=7d8db5a611047bdf9179b002a25d0affc1516752;hp=9cf6e9bb017e6dca0b537bb04b70e5c49dbf705b;hb=a50ccc6c6623ab0e64f2109881e07c176b2d876f;hpb=4a6908a3a050aacc9c3a2f36b276b46c0629ad91
<smb_tp> bcurtiswx, I will see that it gets updated
<Kano> that would be maybe a good backport
<bcurtiswx> i can see that too (since im a bug traiger), i just don't have bug-squad permissions yet, so i can't set importance
<Kano> added g41 chipset
<smb_tp> bcurtiswx, So you need only importance set?
<bcurtiswx> smb_tp: yeah, but i already requested bug-squad to take care of it
<bcurtiswx> smb_tp: thx though
<smb_tp> bcurtiswx, Ok
<smb_tp> bcurtiswx, The puzzling question is still where the message exactly comes from. The "Inspecting", I do not find in the kernel, nor in the grub source code
<bcurtiswx> yeah, i couldn't find exactly where either
<bcurtiswx> im not knowledgeable to know exactly the right places to look, so im not going to say my search was anywhere near beneficial
<smb_tp> bcurtiswx, cking_ found the strings in ksyslogd
<CarlFK1> smb_tp: http://lkml.indiana.edu/hypermail/linux/kernel/0507.1/1601.html
<CarlFK1> that help?
<smb_tp> CarlFK1, Yes, seems to be the system log daemon
<smb_tp> bcurtiswx, ^^^
<bcurtiswx> CarlFK1: ty
<CarlFK1> you're welcome
<apw> Kano, that is likely to come in via the stable updates
<apw> Kano, i am looking at the revert you requested, doing some testing with some newer commits at the same time
<Kano> well there was now .1 i would add it until you get it
<bcurtiswx> hmm, idk how that helps fix my problem though
<bcurtiswx> that appears to show that the system map file is found, giving no "cannot find map file"
<bcurtiswx> yeah, all it helps to show its not the kernel... but who knows what.. lol
<cking_> bcurtiswx: I've updated the bug report according to my findings
<bcurtiswx> tyvm!
<bcurtiswx> cking_: would u update the bug to triaged and an importance you see fit? nobody has responded to me in #ubuntu-bugs
<cking_> bcurtiswx: OK
<bcurtiswx> cking_: ty
<CarlFK1> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317227
<ubot3> Malone bug 317227 in linux "skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP " [High,Triaged] 
<CarlFK1> how important is it for me to repo that without "Tainted: P"  (nvidia)
<CarlFK1> and I have logged 14 more netconsole dumps - http://dpaste.com/110823/  should I just keep attaching them till someone tells me to stop? 
<tjaalton> could someone pull the drm fixes I posted on the list?
<apw> tjaalton, its a holiday in the US today so i suspect people will be a bit slow picking those up
<tjaalton> apw: oh, I wasn't aware of that
<apw> martin luther king day i believe, cirtianly obama seems to be painting something on my tb
<apw> tv
<tjaalton> ok, I'll wait for a bit then
<apw> tjaalton, they were for jaunty correct?
<tjaalton> apw: yes
<CarlFK1> smb_tp_: thanks for the pointer to gentoo/test
<CarlFK> smb_tp_: any idea what the .deb version of "emerge -av boost" is?
<CarlFK> in installed libboost-dev boost-build libboost1.35-dev, still get a ton of errors like: crashClnt.cc:(.text._ZN5boost15program_options16validation_errorD2Ev[boost::program_options::validation_error::~validation_error()]+0xab): undefined reference to `operator delete(void*)'
<andrew_boy125> hi
<bgamari> Does canonical employ any kernel block subsystem developers?
#ubuntu-kernel 2009-01-20
<clerum> is there anything futher I could do to help get https://bugs.launchpad.net/ubuntu/+source/linux/+bug/254622
<ubot3> Malone bug 254622 in linux "TCP uses wrong MTU/MSS size for IPv6" [Medium,Triaged] 
<clerum> moved along?
<clerum> is there more information I could provide?
<clerum> unfortunatly I have no clue where to start in fixing this...and java is my only language so I doubt I would be much help
<apw> dtchen, hi there ... question about a quirk you are suggesting on a bug, about?
<JesperHansen> This seems like the right channel to ask this
<JesperHansen> Was wondering if there's an updated version of https://help.ubuntu.com/community/CustomRestrictedModules#Modify%20debian/rules somewhere. abi_version doesn't exist in the enlisted file debian/rules
<JesperHansen> Compared against linux-restricted-modules-2.6.27
<Kano> hi rtg ,did you read my mail about rt2860/2870?
<Kano> rtg: the drivers are working, no patching needed, you can copy em over from 2.6.29
<Kano> just dont forget to add the firmware as well
<rtg> Kano: I'' get to it later today. I just got back from 3 days off and have a bunch of emails.
<Kano> you will see the 2 firmware links for it in the mail
<apw> sconklin, hi, i did another change for the apport stuff, to send the stress log as well as the flag file.  this is up for review now
<sconklin> apw: I was just coming to those in my email for the morning
<apw> matt's emails yes?
<apw> sconklin, anyhow, just wanted you to know i had taken care of the strees.log part, so i think once all these changes hit the relevant packages we should be 'good'
<JesperHansen> Was wondering if there's an updated version of https://help.ubuntu.com/community/CustomRestrictedModules#Modify%20debian/rules somewhere. abi_version doesn't exist in the enlisted file debian/rules compared howto against linux-restricted-modules-2.6.27
<rtg> JesperHansen: Its in debian/rules.d/0-common-vars.mk
<JesperHansen> rtg: thanks
<JesperHansen> rtg: and abi_version has been renamed? Cant see its presence in there either
<rtg> JesperHansen: Its called abinum. The LRM package structure changed quite a lot from Hardy to Intrepid.
<JesperHansen> rtg: ye, I figured it was some old stuff I was trying to decipher 
<sconklin> apw: ack'd your patches for suspend/resume
<apw> ahh thanks
<sconklin> apw: git question - during a rebase of one branch onto another, which contains dozens of commits delta - I see a number of them apply, a few apply with three-way merge, it stops for me to manually merge a couple, and then at one point after I manually merge one and try to "git rebase --continue", I get the following from git:
<sconklin> Applying Remove lpiacompat
<sconklin> No changes - did you forget to use 'git add'?
<sconklin> and git is in a state where it thinks there is more to rebase yet can't seem to apply any changes
<apw> that means that the result of the merge was that there was no actual changes
<sconklin> oh well, then a rebase --skip should do it, right?
<apw> so either you forgot to git add the files which were changed, or the result was an unchanged files completely
<apw> at that point a git diff HEAD should be null, and then a git rebase --skip is appropriate
<sconklin> no, I definitely did an add, and status shows no uncommitted changes, so I'll just skip it, thanks
<apw> that sounds appropriate
<apw> i seem to remember something similar actually when i was doing my quick and dirty run at uds
<sconklin> I had forgotten that it's possibly to end up with no actual changes, ~especially~ when manually editing in a failed merge.
<apw> particularly for a patch called 'remove something'
<sconklin> haha
<apw> if it wasn't there, then removing it is already done, and the merge is null
<sconklin> right.
<apw> i actually think i had the same merge in the lpia tree i did
<smb_tp> kirkland, while we are waiting for the meeting. Do you happen to know issues with vol_id in the encrypted installation of Jaunty?
<kirkland> smb_tp: hmm, you should probably ask cjwatson about that
<kirkland> smb_tp: there were some blockers breaking lvm+crypt 
<smb_tp> kirkland, Well ok. When I think of encryption, you come to my mind. ;-)
<kirkland> smb_tp: :-)  woohoo
<smb_tp> :)
<smb_tp> kirkland, Generally, if I got a partition that contains the encrypted volume. Do you know whether it should get a special partition ID?
<kirkland> smb_tp: not necessarily ... i'm using encrypted LVM on my Intrepid laptop now, and my mount is just "/dev/mapper/vg0-lv0 on / type ext3 (rw,relatime,errors=remount-ro)"
<kirkland> smb_tp: which is what I named it when I installed
<smb_tp> kirkland, Ok, what I have here is vol_id on the initramfs being more stupid than the one in the rescue system (so it seems)
<kirkland> smb_tp: hmm
<smb_tp> The one from the rescue system shows the uid of it while the one from initramfs is confused because it thinks it might be swap or ecryptfs_LUKE
<HDAPS> Hi, just wondering if there is anyway to confirm that Disk Head Parking is enabled? "hdaps-gl" shows only a static image (kernel 2.6.28 on 9.04)
<Kano> rtg: you did not add the rtxxx drivers yet? what else do you need? i tested it already
<rtg> Kano: I'm just now looking at it.
<Kano> ok
#ubuntu-kernel 2009-01-21
<ratpoison> Hello! anybody know what this http://pastebin.com/m69cc4e49 is? 8.10 amd64 user. Symptoms are: system doesn't shut down properly, nautilus crashes and won't launch and dvds won't mount
<JesperHansen> ratpoison: I am thinking "underpowered" 
<tjaalton> huh, it takes a minute for qla2xxx to initialize on jaunty.. per path
<tjaalton> it seems to be trying to run modprobe using the pci id or such
<tjaalton> ok, so qla2xxx is still a module..
<smb_tp_> I am extremely puzzled by the generic acpi support. The way I understand this is: if a bios supports it the LCD object would have a _BCL method that returns the supported levels.
<apw> i believe that to be true from my experience on this bug too
<smb_tp_> Now we had those reports that some Thinkpads did not work correctly because the thinkpad_acpi driver backs out since there is generic support. And yes, the brightness proc file contains various levels.
<apw> so it must be later thinkpads then, t30 must be too old
<apw> what is your thinkpad?
<smb_tp_> Now I asked for the dsdt of those but when I look into there, I don't find any _BCL method
<apw> hmmm
<smb_tp_> mine is a T42p, doesn't have support
<apw> so pretty new
<smb_tp_> not in laptop world I would say
<apw> we have a couple of T6x's around
 * smb_tp_ thinks it is at least 3y old
<apw> yeah true
<smb_tp_> Hm, maybe mjg59, do you know whether I should find a _BCL method in the disassembly of a dsdt when a laptop supports the generic acpi brightness controls?
<apw> cking, might know such things too
<smb_tp_> yes maybe. 
 * cking looks at the documentation..
<smb_tp_> Actually I just looked at the dsdt of a sony and there it is.
<apw> so you are looking for the right thing
<cking> This method allows the OS to query a list of brightness level supported by built-in display output devices.
<cking> (This method in not allowed for externally connected displays.) This method is required if an integrated
<cking> LCD is present and supports brightness levels.
<cking> Each brightness level is represented by a number between 0 and 100, and can be thought of as a percentage.
<cking> For example, 50 can be 50% power consumption or 50% brightness, as defined by the OEM.
<cking> The OEM may define the number 0 as "Zero brightness" that can mean to turn off the lighting (e.g. LCD
<cking> panel backlight) in the device. This may be useful in the case of an output device that can still be viewed
<cking> using only ambient light, for example, a transflective LCD. If Notify(Output Device, 0x85) for âZero
<cking> brightnessâ is issued, OSPM may be able to turn off the lighting by calling _BCM(0).
<cking> ..so I suspect the answer is "should do"
<smb_tp_> Yeah, this far it sound just reasonable
<smb_tp_> Just that there are three reports from people with T61, X61s and r61 which can show you acpi brightness support indication but when I look at the disassemled dsdt there is nothing
 * cking looks at the spec a little more
<apw> does it have BCM and/or BQC
<smb_tp_> nothing
<cking> _BCM --> The OS will only set levels that were reported via the _BCL method. This method is required if _BCL is
<cking> implemented.
<smb_tp_> apw, maybe you can cross check. see bug 311716
<ubot3> Malone bug 311716 in linux "The slider brightness Applet has value inverted after the last update (2.6.27-11)" [Medium,Fix committed] https://launchpad.net/bugs/311716
<apw> smb_tp_, your fixes to allow switching both ways are not in jaunty are they?
<smb_tp_> take the dsdt from the last reporter, cking "iasl -d dsdt.bin" is correct,?
<cking> yep 
<smb_tp_> apw, no, they are only in intrepid
<apw>         /* First check for boot param -> highest prio */
<apw>         if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VENDOR)
<apw>                 return 0;
<apw>         else if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO)
<apw>                 return 1;
<apw>         /* Then check for DMI blacklist -> second highest prio */
<apw>         if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_DMI_VENDOR)
<apw>                 return 0;
<apw>         else if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_DMI_VIDEO)
<apw>                 return 1;
<apw> i see this in jaunty kernels, so there is something upstream in this area
<smb_tp_> They are slightly different. I patched it to return not 0 or 1 but a bitfield
<apw> ahh
<smb_tp_>         /* First check for boot param -> highest prio */
<smb_tp_>         if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VENDOR)
<smb_tp_>                 return ACPI_VIDEO_BACKLIGHT_FORCE_VENDOR;
<smb_tp_>         else if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO)
<smb_tp_>                 return ACPI_VIDEO_BACKLIGHT;
<smb_tp_> this way it can have both set. but that is hackish
<apw>         if (ACPI_SUCCESS(acpi_get_handle(handle, "_BCM", &h_dummy1)) &&
<apw>             ACPI_SUCCESS(acpi_get_handle(handle, "_BCL", &h_dummy2))) {
<apw> that seems to be the check for turning on ACPI_VIDEO_BACKLIGHT
<apw> so if you don't have those you shouldn't get it turned on
<smb_tp_> Exactly what I believed
<apw> smb_tp_, there is a shit load of debug in here for acpi
<apw> i wonder if we can get them to boot with that enabled
<cking> ..yeah.. boot eventually with all the debug turned on.
<apw> any idea how to turn it on?
<smb_tp_> Must check for intrepid. At some point you had to compile with ACPI_DEBUG set, which was not the default
<smb_tp_> Then you could use some bitmask setting. Should be in ./Documentation
<apw> it tells us things it finds and explicitly tells us it turns this on
<apw> where do i fine iasl
<apw> find
<smb_tp_> apt-get install iasl ?
<apw> odd its not recommended
<Kano> hi apw , it seems the blacklight hack is still in -5 kernel?
<apw> yeah we are still working on what to do about it over all
<Kano> not good
<apw> i have some tests out in the field on some new combinations
<Kano> will revert it for my build
<apw> it will be going, its just not clear what is going in in its place
<apw> smb_tp_, no i can't see either of those in that dsdt in the bug, so that should imply it is not found and enabled
<Kano> anybody responsible for linux-firmware package here?
<apw> whats the question
<Kano> well you need more firmware files
<apw> for drivers we have already?
<Kano> different ones for some dvb-t devices like hauppauge dvb-t
<Kano> additional ones for new rt28x0 drivers - like mentioned in my mail
<apw> i thought we got out hauppauge ones recommended by them
<Kano> http://www.wi-bw.tfh-wildau.de/~pboettch/home/files/dvb-usb-dib0700-1.20.fw
<Kano> you need that now
<Kano> you have got 1.10
<Kano> but 2.6.28 needs 1.20
<apw> you have emailed all this to the kernel list?
<Kano> maybe you can add a symlink from 1.20 to 1.10
<Kano> nope, but i mentioned ti before
<apw> irc stuff tends to get forgotten in minutes
<Kano> for some driver for that little xo there the firmware would be missing too
<Kano> bought a similar wlan device but that did not work with my simple id hack ;)
<Kano> but found out that the firmware was missing
<apw> one mail with all the firmware issues would be good
<Kano> will seek my notes
<Kano> but you saw the mail about rt2860+70 already?
<apw> no not seens that
<apw> i only see one from you about the brightness in my inbox
<Kano> i sent the other 10min later or so
<apw> oddness
<Kano> http://www.ralinktech.com.tw/data/drivers/RT2860_Firmware_V11.zip
<Kano> http://www.ralinktech.com.tw/data/drivers/RT2870_Firmware_V8.zip
<Kano> licence included
<Kano> ok, found these 2 + 3 others, will mail it
<Kano> mail sent
<apw> cool
<Kano> at least i did not see more right now
<Kano> it happens from time to time that i have to seek for firmware for others
<Kano> well the hauppauge dvb-t i own myself
<Kano> http://www.phoronix.com/scan.php?page=article&item=phoenix_hyperspace&num=1
<Kano> ups wrong channel ;)
<Kano> when can i expect a linux-firmware update?
<apw> not sure, others will need to review the changes and decide
<Kano> upload it somewhere an i will test it for you
<tjaalton> I'm getting strange disconnects when copied ~10GB from the usb drive to my local hd on jaunty. dmesg says something about "__ratelimit: 167 callbaks suppressed" and then a bunch of buffer i/o errors
<tjaalton> it's an ntfs file system, so using fuseblk
<tjaalton> oh, the __ratelimit is irrelevant
<smb_tp> right, just even more i/o errors
<tjaalton> yep
<tjaalton> might be just ntfs-3g failing..
<rtg> smb_tp: wireless normally works with the -rt kernel, right?
<rtg> Hardt -rt, that is.
<smb_tp> rtg, how do you think I know?
<smb_tp> I don't know of any reports, but that must not mean anything
<rtg> smb_tp: well, I guess one of would have noticed if no one's wireless worked with the Hardy -rt flavour. 
<rtg> s/of/of us/
<smb_tp> If they tried to probably yes. Not sure whether wireless and -rt are compatible
<rtg> smb_tp: bug #318219. Its loading the i3945, but doesn't appear to do anything after that. guess I'll have to load up one of my laptops.
<ubot3> Malone bug 318219 in ubuntu "Dell n-series won't wifi after reload of Ubuntu" [Undecided,New] https://launchpad.net/bugs/318219
<smb_tp> I fear as much. Do they user an -rt kernel in the bug?
<rtg> smb_tp: no (Ubuntu 2.6.24-4.6-generic), and I also just found an oops in his dmesg.
<smb_tp> rtg, -4.6 sounds pretty old. same problem with anything newer?
<rtg> smb_tp: I was just gonna suggest that he subscribe to -proposed
<smb_tp> -23.46 is in -updates
<smb_tp> even the released (guess thats the .1) is -16.30
<rtg> smb_tp: doh! thats the version of the kernel on the buildd, his kernel was 2.6.24-23-rt
<smb_tp> rtg, Ah, so latest but -rt
<smb_tp> rtg, Hm, the -rt code is pretty new
<rtg> smb_tp: he's still got an oops, looks like a sysctl is failing
<smb_tp> When I updated to -stable upstream alessio took the chance to get a new -rt patch into hardy
<rtg> hmm, maybe we should start looking there.
<amitk> useful link comparing various wear-levelling flash fs: http://free-electrons.com/pub/conferences/2008/jm2l/flash-filesystems.pdf
<cking> amitk: that's handy
<Kano> apw: i saw the patch is reverted now, what about the firmware update?
<apw> not something i am working on at the moment, not looked to see if anyone has looked at the other
<Kano> well a new kernel without firmware does not help that much
<rtg> Kano: what patch? the rt2860/2870 stuff?
<mous16> hi to all. I need the module aic7xxx_old. how can i compile only this module and than inserti it in the ubuntu precompiled kernel?
<rtg> mous16: make -C /lib/modules/`uname -r`/build M=`pwd`
<mous16> rtg: thanks! where I need to move with shell when i launch this make? and how I insert the module in the initrd? (this is the module of the scsi controller)
<rtg> mous16: aic7xxx_old must have a compatible makefile. the command line assumes you are in the same directory as the makefile. once the modules is compiled you can load it using 'sudo insmod *.ko'
<mnemo> mous16: I have this other macro to permanently install a .ko once I built it
<mnemo> alias modmake='make -C /lib/modules/`uname -r`/build M=$PWD modules'
<mnemo> moduse() {
<mnemo>         sudo cp $1.ko /lib/modules/`uname -r`/kernel/`pwd | awk "{print substr(\\$1, index(\\$1,\"drivers\"))}"`/$1.ko
<mnemo> }
<mnemo> so then to permanently use a .ko I just run "moduse drm" and drm.ko gets copied to the right location
<mous16> mnemo: I'm  having trubless in compiling the module. I'm using the kernel source in ubuntu repo, but it tell me that there isn't a make file...
<mnemo> mous16: so if you do like "mkdir my_kernel_code ; cd my_kernel_code ; apt-get source linux-image-2.6.28-4-generic ; cd linux-2.6.28/drivers/gpu/drm"
<mnemo> and then just do that comment rtg said
<mnemo> if you are in the drivers/gpu/drm part of the kernel tree it will build all the .ko's that are built from that dir etc
<mous16> with drm it seams to compile correctly all the modules interessed. but if i move to drivers/scsi/aic7xxx_old and give the same command it return: http://paste.ubuntu.com/107901/
<mnemo> mous16: ah yes, that directory does not have a "makefile" at all in it
<infinity> So, who's handling armel kernel flavors, and how do I talk them into doing a distro kernel for our buildds?
<rtg> infinity: me or amitk
<rtg> infinity: what are the buildd's and do you have a config?
<infinity> rtg: Which source is armel built from?  I see both linux and linux-ports failing on armel...
<rtg> infinity: its building from the Jaunty git repo, I'm aware of the FTBS (I think its fixed)
<infinity> rtg: The buildds are Marvell DB-78x00-BP Development Boards, and I have a monolithic config right now that works.  I see no reason why it can't go modular with an initramfs, though.
<rtg> infinity: the monolithic config is fine. I think all of the other flavours are like that.
<infinity> And now, the challenge of finding my original build tree with the config in it...
<infinity> *cough*
<infinity> Do proc or sys export a config somewhere from the running kernel, perchance? :)
<rtg> not in the distro kernel
<infinity> Oh, it's an option?  Almost certainly one I didn't enable, then.
<rtg> dunno what you're running on the buildd
 * infinity digs for his tree instead.
<rtg> if its there, then it'll be /proc/config*
<infinity> Nah, it's not, but I found my tree.
<infinity> Sitting in a qemu image on my laptop.
<rtg> infinity: is the qemu faster then native? these babbage boards with USB disk are sloooow
<infinity> rtg: qemu on my laptop is speedy, the Marvell buildds are MUCH faster.
<infinity> rtg: It's just that I had a chicken and egg problem where I couldn't build a kernel for the Marvell machines on the Marvell machines...
<rtg> rumor has it that we may get one or two as porter machines soon
<infinity> rtg: This is the kernel config I'm using: http://lucifer.0c3.net/~adconrad/armel-kernel-config
<infinity> rtg: And I'm setting up the porter machine as we speak. :)
<rtg> infinity: ok, the first thing I'll do with the porter machine is to test build your config.
<rtg> and rev it from 2.6.27 to 2.6.28
<amitk> infinity: you won't mind if we homogenize the config, will you? ...add things like netfilter, ipv6 and other bloated modules that are common across all flavours?
<rtg> amitk: aren't buildd's and porters all running stock Hardy?
<rtg> complete with module bloat
<infinity> All the other arches are stock hardy-server, yeah.
<infinity> If you plan to make it a generic marvell DB-78x00-BP kernel for re-use by end users and testers, then yeah, bloat it up.  I don't mind.
<amitk> rtg: true. But most ARM-folks are used to hand-crafting their configs like in the good old days. I don't want to encourage those expectations.
<infinity> If I'm going to end up being the only person who uses the kernel on my 6 machines, then no. :P
<infinity> I know that Marvell handed out a fair number of these boards to the Free Software community, some Debian people have them, etc.  So a generic kernel might actually get used.  Maybe.
<amitk> infinity: is this an orion5x-based machine?
<infinity> amitk: I don't speak codenames.  So.  Maybe?  I don't know?
<amitk> infinity: grep for ARCH or MACH in the config
<infinity> CONFIG_ARCH_MV78XX0=y
<infinity> # CONFIG_ARCH_ORION5X is not set
<infinity> That would answer that.
<amitk> hmm.. yet another flavour
<infinity> amitk: Oh, and it's uBoot based.  I assume (hope?) that our build system can automagically staple the uBoot bits on the image?  I had to do mine by hand.
<amitk> infinity: make uImage ought to do that. I don't think our build system knows about it yet.
<infinity> Anyhow, I'll get back to you guys when the porter machine's online, since I'm hearing that that's a prereq for getting my a distro kernel. :)
<infinity> s/my/me/
<rtg> it'll make it faster.
<rtg> rather, it'll happen sooner with a porter
<amitk> rtg: how did you merge the versatile config? Just copy it over?
<rtg> amitk: for i in config.* ; do cat config >> $i; done; rm config
<rtg> debian/rules updatconfigs
<amitk> rtg: aahh.. so the config failed on pulling from upstream?
<rtg> amitk: I got it from ogra, so I have no idea
<amitk> rtg: let me rephrase. Did you just merge the configs, copy over ogra's versatile config and then split config again?
<rtg> yes
<amitk> ok
<rtg> which has caused me some gief, missing modules etc
<rtg> s/gief/grief/
<rtg> amitk: where you is now? back in Europe?
<amitk> rtg: yeah...
<kirkland> rtg: \o/
<rtg> filename encryption?
<kirkland> rtg: your filename encryption kernel is working :-)
<kirkland> rtg: yup
<rtg> cool
<kirkland> rtg: $ ls
<kirkland> rtg: ECRYPTFS_FNEK_ENCRYPTED.FYZOEIsgDeUixETd-IcPajGrIikAQ4n6KRVe2BW2L0vIlNbyGJugWlyAkCgV9Mv1EBJ2Go2.z36IhdEoBEbxo2CxgC-1B4DMGD2J
<kirkland> rtg: $ ls Private/
<kirkland> rtg: doc
<kirkland> :-)
<kirkland> rtg: okay, i gotta finish the userspace utilities for it now
<rtg> kirkland: that'll mystify homeland security :)
<kirkland> rtg: my goal, of course
<radii> so I'm looking at the ubuntu/ubuntu-jaunty tree and it looks like c0399d55 "Enabled CONFIG_PID_NS=y for i386/amd64" reverts the previous 7 i915 commits -- fb8d31f8 428b85cb 29277168 30ee913c e7a95a8a c569e25c 4e5967f9.
<radii> should I mail kernel-team@ about it, or ping Tim directly, or ... ?
<radii> rtg: you around?
#ubuntu-kernel 2009-01-22
<AnAnt> Hello, will the opensource broadcomm wireless firmware (https://lists.berlios.de/pipermail/bcm43xx-dev/2009-January/008466.html) be used in next release of Ubuntu ?
<AnAnt> http://www.ing.unibs.it/openfwwf/
<JanC> AnAnt: they say that their open source firmware is not complete?
<Kano> b43?
<JanC> Kano: an open source firmware for b43
<Kano> i know that this exists,but did anybody try it
<JanC> I'm sure the authors test it ;) but they also say that it doesn't work yet with encrypted connections and some other wifi protocol features
<JanC> well, it seems like they might have fixed the encryption support since that mail
<Kano> would be good to include it then
<AnAnt> JanC: I don't think that HW encryption got fixed
<AnAnt> neither the QoS feature
<AnAnt> I followed the thread in their archives
<JanC> AnAnt: ah, they still only support SW encryption then?
<JanC> which is probably dead slow  ã
<AnAnt> ok
<JanC> (I didn't test it, that was just an assumption)
<AnAnt> so isn't anyone from Ubuntu following up with this firmware ?
<JanC> hm, maybe SW crypto is "good enough" for station mode (as opposed to e.g. AP mode where it would have to cater for multiple connections) ?
<JanC> seems like the rt2500* drivers don't implement HW crypto either
<rtg> apw: you mentioned you had some scripts you were working on for the vanilla kernel build.
<apw> yeah, i am testing them right now.  think i have the nameing sorted.  my plan is to complete a couple of test builds, then write up how i think we should be using them and email that out to the kernel-list
<apw> should happen today
<Kano> hi rtg , i saw you added the rt firmware, did you get my mail with some more missing firmware? the 2 for dvb devices are even mentioned in launchpad
<rtg> Kano: working on it
<Kano> you added d
<Kano> a-c still missing
<rtg> Kan RT works, right?
<Kano> no complains
<rtg> I'll get the rest of the firmware soon
<Kano> only usb tested so far,but i guess your kernel works for pci too
<Kano> what do you think of adding the new free b43 firmware?
<Kano> would be good when you dont need the fwcutter to go online
<CarlFK> smb_tp: you mind helping me get a Firewire ExpressCard  working?  (on the x64 box, any kernel.  tired ibex 32, nothing.  jaunty x64, pciehp module doesn't  exist 
<smb_tp> CarlFK, I can try. You got a bit more info? What exactly would you need? 
<CarlFK> smb_tp: lets start with: why isn't there a pciehp module for x64 jaunty?  there is for 32 jaunty 
<CarlFK> http://packages.ubuntu.com/search?suite=jaunty&arch=any&mode=filename&searchon=contents&keywords=pciehp
<CarlFK> lib/modules/2.6.27-1-386/kernel/drivers/pci/hotplug/pciehp.ko                   	 	linux-image-2.6.27-1-386 [not amd64] 	         
<smb_tp> CarlFK, Would have to have a peek at the source. Either its just a glitch in the config or some dependency thing
<CarlFK> ok - wanted to make sure there wasn't some alternative i should be trying 
<smb_tp> Hm, build when CONFIG_HOTPLUG_PCI_PCIE is set. Which it is on both
<CarlFK> carl@dv67:~$ sudo modprobe pciehp
<CarlFK> FATAL: Module pciehp not found.
<smb_tp> actually it might not be a module 
<CarlFK> doh
<CarlFK> carl@dv67:~$ dmesg|grep pciehp
<CarlFK> [    1.247944] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
<CarlFK> ok, so on to the next problem: 
<CarlFK> the card has 2 firewire and 1 usb.
<CarlFK> usb works (the lack of module was making me think magic)
<CarlFK> but the firewire doesn't (at least not the way the on board fw does)
<CarlFK> as in, I plug in a fw to onboard, hotplug happens, device is live
<CarlFK> plug into card's fw, nothign.  no dmesg, no change in lscpi.. 
<smb_tp> Hm, that means? Is any driver claiming /driving it=
<smb_tp> ?
<CarlFK> not that I can tell
<smb_tp> One thing to search for would be the pci id 
<CarlFK> lshw doesn't change when I plug in the card
<CarlFK> pci id coming up.. 
<CarlFK> I have it around here somewhere.  
<CarlFK> any idea how to query the EC buss?  (express card)
<smb_tp> Doh, all my hw is too old. Might it get added to the pci subsystem and just show up with lspci?
<CarlFK> nope
<smb_tp> lspcmcia
<CarlFK> sudo lspcmcia - nothing.
<CarlFK> sudo pccardctl info - nothing. same for status, ident, config
<smb_tp> Anything in /sys/bus/pci_express/devices ?
<CarlFK> yes.. digging
<CarlFK> http://dpaste.com/111904/  best I have so far...
<CarlFK> I put the card into a mac, and was able to get a pciid, which I posted somewhere,,,
<CarlFK>  0a:00.0 FireWire (IEEE 1394) [0c00]: JMicron Technologies, Inc. Device [197b:2380]
<CarlFK> and from the kino/dvgrab list: > The card  itself should be no different than the pcie jmicron cards I've got, which work  fine 
<smb_tp> just grep'ing the tree. nothing for 2380 in the upstream part. 
<smb_tp> neither in ubuntu specific modules
<smb_tp> do the other cards you got show up on lspci or any other place?
<CarlFK> I only have that one card
<CarlFK> tonight I can get a 2nd card.  its a ...evode? card
<smb_tp> Oh, nm. That was from a mailing list post. 
<CarlFK> right
<smb_tp> you said it has a usb part which is working. does that device show up?
<CarlFK> yes - under lsusb
<smb_tp> Hm, yeah. Make sense. One thing that might show a bit more would be to tune up the udev logging and listen to the events with udevadm monitor while plugging...
<CarlFK> smb_tp:  ever see the Far Side comic: "Bad dog Ginger.  Don't do that again Ginger.  No, no Ginger."  What the dog hears: "bla bla Ginger.  bla bla bal bla Ginger.  bla bla Ginger."
<CarlFK> that would be you me :)
<CarlFK> so what's this tune up the udev logging you speak of?
<smb_tp> CarlFK, Heh, no, not yet. :)
<smb_tp> Tune up is probably not best expressed. Better increase the log level "udevadm control --log-priority=debug"
<smb_tp> Then running "udevadm monitor --kernel --environmen --udev"
<smb_tp> shows the events as they come in
<CarlFK> carl@dv67:~$ sudo udevadm monitor --kernel --environmen --udev
<CarlFK> monitor will print the received events for: UDEV the event which udev sends out after rule processing; UEVENT the kernel uevent
<CarlFK> plug, unplug.. nothing 
<CarlFK> plugged a usb stick into the card's usb got stuff
<CarlFK> http://dpaste.com/111924/
<smb_tp> Grr... great. Seems I have no idea how this should work. :(
<JackWinter> i have a kubuntu 8.10 running in a vbox.  thought it would be a good idea to install the virtual kernel, but apt installed the server version.  are they the same or is something messed up ?
<rtg> JackWinter: they are the same. the virtual package is generated using binaries from the server flavour
<JackWinter> rtg: thanks
<JackWinter> are there any news on a rt kernel for 8.10 ?
<rtg> JackWinter: I'm not keeping up with whats going there, perhaps smb_tp can answer.
<JackWinter> i'll hang around a while
<smb_tp> rtg, AFAIK if there is one it is community supported as the -ports
<mnem0> rtg: did these intel fixes make it into the new kernel? --> https://lists.ubuntu.com/archives/kernel-team/2009-January/004178.html
<rtg> mnem0: those fixes are actually in the source for -5.12. I'm just not sure why they didn't show up in the diff.
<mnem0> ok great... im being hit by a really bad xorg crash bug which is fixed by these patches
<rtg> mnem0: well, I'm about to get the other ABI dependent packages uploaded so you should have an update tomorrow or the next day
<mnem0> sweet
<mnem0> thanks
<smb_tp> CarlFK, I talked over that on another channel. That firewire card should show up with lspci. Is that the only slot you got? Or have you tried to have the card in on boot to avoid hotplug?
<CarlFK> only slot, have not tried on boot.  will reboot now
<tjaalton> rtg: hum, I fetched the source for 5.13 and I can't see them in there
<rtg> hmm
<tjaalton> at least the one touching include/drm/i915_drm.h
<tjaalton> c0399d5596fb reverted it
<rtg> tjaalton: do a git log on that file. I think something ugly happened.
<rtg> 'UBUNTU: Enabled CONFIG_PID_NS=y for i386/amd64' wrecks it. wtf?
<tjaalton> yes
<tjaalton> basically what was said on the email ;)
<rtg> tjaalton: I think I managed to do that one all by myself. drat.
<rtg> I wonder if I messed up a rebase.
<CarlFK> smb_tp: having hte card in when I power up the box makes a new FW bus show up
<CarlFK> plugging in fw device now
<rtg> CarlFK: so it sounds like a hotplug problem.
<CarlFK> fw device is recognized.  yay.  now I can test to make sure I can capture and mix 2 fw cams on one laptop 
<tjaalton> rtg: thanks for fixing it, tomorrow will be a good day for -intel gfx ;)
<rtg> tjaalton: hope I got it right this time.
<tjaalton> rtg: at least git looks good
<tjaalton> and diff too
<Keybuk> time with intrepid modprobe on amd64 to do 10,000 nothings:  3m13.6s
<Keybuk> anyone care to guess how long with new modprobe? :)
<dtchen> 3m13.0s?
<Keybuk> no ;-)
<Keybuk> lower
<laga> 3m12.9s?
<Keybuk> lower
<laga> 3m12.8s?
<Keybuk> lower
<Keybuk> (this could take a while <g>)
<laga> yeah
<laga> about to go to bed, so just tell me ;)
<Keybuk> 16.4s
<laga> sweet!
<johanbr> Keybuk: how many nothings does it do at bootup?
<Keybuk> johanbr: modprobe nothing is a good way to measure the overhead of modprobe
<Keybuk> ie. how much time it takes to iterate through its indexes
<Keybuk> modprobe has always been more ridiculously more expensive than insmod
<johanbr> I wasn't trying to be sarcastic, or anything. Just wondering how much this would save in a real situation.
<Keybuk> so this new version plus patches seems to make it rather better
<Keybuk> seems to be around 2-3s
<Keybuk> of boot time
<johanbr> nice :)
#ubuntu-kernel 2009-01-23
<Keybuk> 6s in fact
<Kano> hi rtg , saw your firmware update, looks good. but something else now
<Kano> rtg: http://paste.debian.net/26668
<Kano> do you see that sis agp crash
<rtg> Kano: do you see any mention of this upstream?
<Kano> well the system boots still,but the crash does not look good
<rtg> Kano: do you have a PCI ID?
<Kano> http://paste.debian.net/26664
<rtg> Kano: huh, nothing obvious. start a bug report and attach those 2 files
<Kano> its not my system
<rtg> Kano: well then, get the user to do it.
<Kano> did you get the openfwwf to compile?
<Kano> http://www.ing.unibs.it/openfwwf/
<Kano> modprobe b43 qos=0
<Kano> means that it may require a kernel option, which could be made default
<CarlFK> when I remove/replace an Express Card, display fills with a pattern an the box hangs
<CarlFK> januty
<lool> Hmm I see that linux-restricted-modules-common in jaunty carries a /etc/modprobe.d/ipw3945; I think this is an old binary daemon that used to be required, but nowadays all 3945 cards will use iwlwifi, right?
<lool> It was dropped, but not rm_conffile()d
<rtg> amitk: are you working on ARM stuff today?
<apw> tjaalton, hey ... how is the drm headers issue going?
<tjaalton> apw: should be fixed now
<tjaalton> at least mesa built fine
<apw> tjaalton, perfect, just waht i wanted to hear :)
<tjaalton> yeah :)
<amitk> rtg: yes I am
<rtg> amitk: are you interested in adding armel support to LRM/LBM ?
<amitk> rtg: not at the moment. I don't see a usecase yet.
<rtg> amitk: ok, then I'm gonna whack on them so they they don't build at all. I'm currently getting failures 'cause the arch in debian/control is 'any'
<amitk> rtg: go ahead. I'll be busy getting the various flavours into shape
<rtg> amitk: wfm
<mnem0> rtg: tjaalton: I was hit by that intel waitForVBlank freeze bug and I had tested the "dont enable vblanks on disabled pipes" drm patch which worked great on my machine... but today when the .28-5 kernel installed my intel G45 machine got unbootable --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/320525
<ubot3> Malone bug 320525 in linux-meta "jaunty unbootable on intel G45 since .28-5 kernel update" [Undecided,New] 
<lool> apw: So you want a LP bug?
<apw> lool was asking if there is one?  or not
<lool> apw: Yeah and I replied not but happy to file one if you like
<lool> apw: Just tell me if you require one, I'll file one; otherwise no there's currently none :)
<apw> thats fine thanks for the info
<Keybuk> [97766.161127] ata1: exception Emask 0x10 SAct 0x0 SErr 0x1810000 action 0xe fro
<Keybuk> zen
<Keybuk> [97766.161135] ata1: SError: { PHYRdyChg LinkSeq TrStaTrns }
<Keybuk> [97766.161141] ata1: hard resetting link
<Keybuk> [97768.652032] ata1: COMRESET failed (errno=-32)
<Keybuk> [97768.652039] ata1: reset failed (errno=-32), retrying in 8 secs
<Keybuk> [97776.160058] ata1: hard resetting link
<Keybuk> [97778.548037] ata1: COMRESET failed (errno=-32)
<Keybuk> [97778.548044] ata1: reset failed (errno=-32), retrying in 8 secs
<Keybuk> [97786.160023] ata1: hard resetting link
<Keybuk> [97788.388036] ata1: COMRESET failed (errno=-32)
<Keybuk> [97788.388043] ata1: reset failed (errno=-32), retrying in 33 secs
<Keybuk> [97821.160023] ata1: hard resetting link
<Keybuk> [97823.388022] ata1: COMRESET failed (errno=-32)
<Keybuk> [97823.388028] ata1: reset failed, giving up
<Keybuk> [97823.388030] ata1.00: disabled
<Keybuk> eep
<rtg> Keybuk: did you break your drive?
<Keybuk> no, I don't _think_ so
<Keybuk> if I reboot, it comes back just fine
<Keybuk> any way I can bounce that?
 * Keybuk thinks vmware made the kernel think he broke the drive
<rtg> I doubt it, its likely boot essential.
<rtg> oh, is that from a VM?
<Keybuk> no, from the real system
<Keybuk> but this only happens when vmware is doing things, and never when vmware's modules aren't loaded
<rtg> 2.6.28-5 ?
<Keybuk> 2.6.27-11
<rtg> ah, intrepid. There were some recent VMware patches. lemme check when they went in.
<rtg> Keybuk: what kind of drive? '* libata: fix Seagate NCQ+FLUSH blacklist' went into -11.22
<Keybuk> seagate
<Keybuk> no, samsung sorry
<Keybuk> SAMSUNG SP2504C 
<rtg> Keybuk: the vmware changes haven't been committed yet
<CarlFK> ibex: I boot live cd with a firewire ExpressCard in, lspci shows the FW listing.  I pull the card out, lspci still shows it
<CarlFK> same with today's jaunty 
#ubuntu-kernel 2009-01-24
<domas> hi! I'm getting various kswapd deadlocks on our machines, like this one: http://p.defau.lt/?AftWGQnCtD1G80ZjIr7cyg - it seems any VFS pressure can cause this...
<MalikLamin> hey you all, I've just throw mysef
<MalikLamin> myself in the linux driver development, how do I compile and run my modules without compiling all the kernel
<MalikLamin> ?
<MalikLamin> does anybody know a good GUI for editing the linux source code
<mnemo> MalikLamin: emacs and vi has semi-GUI versions available.... some people use eclipse+CDT as well... or maybe anjuta would work?
<mnemo> MalikLamin: to compile all modules in the current directory execute this command:
<mnemo> make -C /lib/modules/`uname -r`/build M=$PWD modules
<mnemo> for example you can do this in .../drivers/gpu/drm to create drm.ko
<MalikLamin> ok
<MalikLamin> thanks mnem
<MalikLamin> mnemo
<mnemo> np
<MalikLamin> i will try kdevelop and ajunta or maybe eclipse
<mnemo> yea
<mnemo> MalikLamin: some people find cscope (command line) or kscope (GUI) useful for browsing .c sources
<mnemo> but the lxr website is also really useful for reading kernel sources
<mnemo> you can launch "cscope -R" in any directory containing .c sources.. and it will let you search for the definition of certain function names etc
<MalikLamin> ahnram, ok. So, if I do create a new module, isnt it necessary to recompile all the kernel????
<mnemo> MalikLamin: if you recompile a module you can either copy it into the proper place in the /lib/modules/kernel tree and then reboot, or you can just "insmod" it right there (but this is not permanent)
<mnemo> you never need to rebuild the kernel to use a rebuilt module
<MalikLamin> ok
<MalikLamin> I got
<aLeSD> hi all
<aLeSD> the realtime kenrel of the 8.10 is breoken ?
<aLeSD> the realtime extensions don't work with jack
<aLeSD> I'm thinking to install the old kernel
<aLeSD> I mean use the 8.04 kernel on my 8.10
<aLeSD> is it possible ?
<aLeSD> is anybody out there ?
<aLeSD> india
#ubuntu-kernel 2009-01-25
<seektherapy> hello
<seektherapy> picturesque: 
<seektherapy> are you there
<domas> yes
<domas> :)
<seektherapy> oh thank god
<seektherapy> i need some help
<seektherapy> I dont have sound on my Ubuntu 8.10 but i did before i upgraded... i see the icon on the top left but when i click it i get an error
<seektherapy> No volume control GStreamer plugins and/or devices found.
<seektherapy> Now.. i did find this site
<seektherapy> http://support.creative.com/downloads/?h=7   but i am so new i dont know how to configure it
<domas> so, you already know more about sound drivers than I do! :)
<seektherapy> only because i just saw that irc has a creative channel for ubuntu and i followed the link
<seektherapy> I am fairly good at hunting down info..now following directions is the hard part
<seektherapy> domas: can you please help me ...PLEASSSSSSSSSSSE
<seektherapy> Quick install
<seektherapy> =============
<seektherapy> In terminal,
<seektherapy> 1) Goto source directory
<seektherapy> 2) Execute make command as root
<seektherapy>    make
<seektherapy>    make install
<seektherapy> dont know how to do that
<pwnguin> (if it's not kernel related, you should probably take it to /msg)
<domas> :-( 
<domas> btw, my deadlocks seem to have gone away after upgrading to 2.6.28.1
<domas> which is good thing.
<pwnguin> nifty
<seektherapy> well someone told me in the Ubuntu devel channel that it was a kernel problem
<domas> having few hundred k of hardware in crashloops ain't fun
<domas> seektherapy: how to make is a kernel problem? :(
<pwnguin> sound is a many possible things problem
<domas> kswapd deadlocks is kernel problem, usually
<pwnguin> yes
<domas> I was ready to blame some hardware issue 
<seektherapy> I'm getting the run around.. sad and i am a girl trying to really learn Ubuntu and thought i could just hop in here and people would be nice to me
<seektherapy> Instead i feel like people are pushing me towards windows again
<pwnguin> well, we try to organize the channels around subjects and the like.
<domas> I use ubuntu just on servers, not much of sound experience ;-) 
<domas> except how to make FANS LOUDER
<pwnguin> teaching end users is just one part of what goes on in IRC
<domas> btw, my colleagues told that someone in #ubuntu-kernel told them kswapd activates only when system is out of memory
<domas> so, I was looking guilty for allocating 31GB to mysqld on 32GB box
<domas> but apparently any vfs pressure was causing those problems
<pwnguin> kswapd should run whenever
<domas> indeed
<domas> any vfs pressure should keep it working
<domas> any direction
<pwnguin> if you've got unused stuff, it'll kick it out for more cache
<domas> we usually set swappiness to 5 or so
<domas> so that rarely happens
<domas> anyway, I got those 'soft lockups' against pretty much everything
<domas> nc, tar, mysql, jfs/xfs, lvm, .
<domas> with standard hardy kernels
<pwnguin> a friend was saying he had terrible problems with 8.04 performance. was furious at ubuntu kernel team for patching or something, till he went back to debian and had the same problem
<domas> hehe
<domas> I'm quite happy about 8.04 performance
<domas> if not for crashes on 8-core boxes
<domas> I think some new nvidia northbridge chipset is causing troubles
<domas> uh uh, 2.6.28.1 isn't happy either: http://p.defau.lt/?Sz4O_rQGfmNopsaVYmbAKw
<seektherapy> YOU MEN NEED TO READ THIS SERIOUSLY AND PULL YOUR HEADS OUT OF THE CLOUDS !
<seektherapy> http://forums.thedailywtf.com/forums/t/10854.aspx
<seektherapy> instead y'all keep pretending everything is A OK
<seektherapy> this should really concern y'all
<domas> seektherapy: *shrug*, I have got 20 new servers that cost >10k$ each, which are not working as they should be, kernel problem
<seektherapy> not the point
<domas> I also have my own reasons to be frustrated
<seektherapy> the point is the adverage comsumer
<domas> average consumer should never care about drivers
<domas> or kernels
<seektherapy> According to WKOW TV, Abbie Schubert recently ordered a Dell laptop, expecting "your classic bread-and-butter computer." But when she unboxed the $1,100 machine that arrived, she didn't find bread and butter. She found Ubuntu.
<seektherapy> So she kept Ubuntu, giving up her chance for bread and the butter. Then she decided that Ubuntu doesn't always work like Windows. Her Verizon internet wouldn't load. She couldn't install Microsoft Word. And she said without Word and the internet, she couldn't take online classes at Milwaukee Area Technical College.
<domas> *shrug*, I'm mac desktop user :)
<seektherapy> then why are you here
<domas> because I run few hundred ubuntu servers? :)
<seektherapy> keep shrugging as dell boots you out
<domas> powering some of bigger web shops
<domas> oh, and we have dell servers, poweredges are just fine!
<seektherapy> not personal computers
<seektherapy> stop it
<seektherapy> its not about arguing its about the facts
<domas> and "not being able to install Microsoft Word" is probably the best anti-ubuntu argument
<domas> so go, stick to it
<seektherapy> domas: you seem old enough to know... not many women use linux because they dont know it
<seektherapy> not much user support
<seektherapy> when a person goes into a channel they are brushed off
<domas> there's very much same user support as you'd get from other OS vendors
<seektherapy> its like you wont it to fail
<seektherapy> oh.. no
<seektherapy> not true
<seektherapy> I am asking how to run a simple command and no one will help me with that.. most women dont have a clue about commands
<domas> exactly, you're asking in venue where people don't know how to explain simple commands
<seektherapy> so you dont know how to create a command
<seektherapy> i bet if my friend is online.. he would know right off
<pwnguin> domas: more like want to
<pwnguin> running make is easy
<domas> indeed :)
<pwnguin> getting someone who doesn't know make up to speed on all the other deficiencies, that's not fun
<domas> btw, which is the best channel for generic linux kernel questions? I have quite a few problems with 2.6.28.1 too, not just ubuntu kernels :(
<pwnguin> ive no idea
<pwnguin> i hear theres a secret irc channel
<domas> ages ago there was #kernel 
<pwnguin> but i havent the need
<domas> actually, it is still there
<seektherapy> oh god..y'all are so gay
<seektherapy> wasting my time here
<seektherapy> bye
<Kano> hi, did everybody notice 2.6.28.2?
<tjaalton> I noticed it's Sunday ;)
<sdf> Hello 
<sdf> How i can enable my second Xeon 550 Processor in 6.06 ?, I think i need a SMP kernel ? kindly Help me 
<CarlFK> sdf: at some point the default kernel was smp
<CarlFK> not sure about 6.06. see if there is a somekernel-smp  package 
<sdf> CalFk : there is SMP kernel available for 686 , But my system is Xeon 550 dual
<sdf> Is there any SMP kernel patch for 6.06 on i386 ?
<andersk> No need for patches.  The default (-686) kernel already supports SMP and should have no trouble running on your hardware.  Are you sure your second CPU isnât enabled already? 
<andersk> To check, you could run grep ^processor /proc/cpuinfo 
<sdf> andersk : I am sure it is disabled, cause it is shown but disables in command: lshw, i installed the 686 but it shows blank screen at startup , so i have switched back to 386 kernel, it is running just slow 
<sdf> shani@CISCOWALL:~$ grep ^processor /proc/cpuinfo
<sdf> processor       : 0
<andersk> The 386 kernel does not support SMP, but all the other ones do. 
<sdf> well dont know why my system donot supports 686 :/ , i thought there should be a SMP patch for 386 kernel 
<CarlFK> andersk: "686 but it shows blank screen" <- fix that :)
<sdf> yeah
<sdf> If you are a developer, then i can help you with more information 
<sdf> My system is Dell Xeon 550 dual with 1.5 GB RAM , and 20 GB hardisk , every thing is running as 386 kernel , but my second processor is disables so system is a bit slow
<CarlFK> sdf: pretty sure that kernel is not being worked on any more 
<sdf> aah
<sdf> What about 8.10 installer, It is also get hanged before reaching the live CD's Desktop ? it is also not supporting my system, whats wrong ? 
<sdf> i have changed many CD;s, removed all RAM, tried to run with 512 MB and 1.5GB of RAM, but it just show me a 8.10 logo with moving bar ? 
<CarlFK> ask in #ubutnu - there's a bunch of things you can do.  try the Alt cd would be my idea.
<sdf> https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/019983.html
<sdf> i got this answer from #ubuntu
<CarlFK> ask about: What about 8.10 installer, It is also get hanged...
<sdf> k
#ubuntu-kernel 2010-01-25
<tjaalton> 10:55 < airlied> jcristau: btw what did Debian move AGP from y->m
<tjaalton> 10:55 < airlied> it really really wants to be y
<tjaalton> 10:56 < jcristau> i don't know
<tjaalton> 10:57 < airlied> EDAC and AGP can fight also which usually ends up badly for AGP
<tjaalton> probably something to fix for lucid too
<apw> hrm
<apw> i thoght we already hit that interaction
<tjaalton> apw: AGP? seems like it's builtin on amd64, only checked i386 first
<apw> yeah, i thought we blacklisted edac or something to resolve
<tjaalton> ok
<apw> smb, do you remember something in jaunty or karmic about edac and agp ordering breaking drm .. and us sorting it?
 * apw bounces to switch kernels
<smb> apw, Hm, not with edac. I think to remember conflicts between agp and drm. Something with i915 being loaded causing problems
<apw> hmmm, it definatly rings a bell
<gnomefreak> is it the kernel that loads pdflush process found in ps aux?
<Kano> hi, is somebody working on  2.6.32.5?
<apw> thats on my plate as usual
<Kano> good, when will you push it
<apw> not likely to get to it today, tommorrow is more likel
<Kano> ok
<jcastro> does our kernel support these new broadcom crystal hd cards that are shipping with some of the new pine trail netbooks?
<Kano> more interesting would be mantis
<apw> jcastro, hrm no idea does anyone have one?
<jcastro> apw: I was determining if I should based on the answer, heh
<jcastro> When the card goes on sale by itself I will get one
<jcastro> apw: I saw they released some source and some gstreamer bits
<jcastro> but I wasn't sure about firmware
<jcastro> http://www.broadcom.com/docs/support/crystalhd/crystalhd_linux_20091229.zip
<jcastro> apw: I don't know if they've approached upstream or distros about it either
<jcastro> apw: I did read that they plan on having a pci-e version for people to plop into their existing media centers, which sounds pretty nice
<apw> jcastro, its not crossed my awareness no, but that doens't mean its not coming
#ubuntu-kernel 2010-01-26
<AceLan> if I got a git describe value, ex. v2.6.32-rc4-94-g80f5069 , how could I find that commit in the git tree?
<kengyu> AceLan, git tags -v v2.6.32-rc4-94-g80f5069 ?
<AceLan> kengyu: it's not a tag
<JFo> wonder if you can pipe to grep within a git command
<JFo> <-never tried it
<kengyu> JFo, I think it should work. 
<kengyu> AceLan, or git log and "/" your keyword?
<JFo> kengyu, good call, I haven't tried that yet either
<AceLan> kengyu: got it, thx
<JFo> AceLan, what worked?
<JFo> the git log command?
<AceLan> JFo: git log and use / to search
<AceLan> JFo: yes
<JFo> AceLan, cool :)
<vishalrao> Hello, please see http://lkml.org/lkml/2010/1/22/3 about disabling libATA NCQ for some SSD drives to avoid hangs...
<vishalrao> I'm trying to patch in my PPA at https://launchpad.net/~vishalrao/+archive/kernels
<apw> vishalrao, if those drives are 'bust' then we should get a launchpad bug filed and the patch attached to that bug, also it should be small enough for -stable
<vishalrao> i will attach a patch to already filed bug 502219 :)
<ubot3> Malone bug 502219 in linux "Kernel errors triggered with SSD storage" [Medium,Triaged] https://launchpad.net/bugs/502219
<vishalrao> amateur patch though, will require review/cleanup and apply
<apw> vishalrao, is that device something you have swapped into the machine its in, or is it the default part for that machine
<vishalrao> its my home desktop PC (self assembled) - got rid of my SATA HDD and placed in a retail model Crucial M225 128GB SSD 
<vishalrao> i changed BIOS from legacy IDE to AHCI (that enabled NCQ i believe)... works well for Win7 - but the ATA dmesg errors you might see in the bug dmesg
<vishalrao> note that passing kernel boot param " libata.force=noncq " resolves the issue... hence the patch suggested...
<vishalrao> apw: see above - i am off for a break.
<apw> smb, i am about to pull in a 2.6.32 dove branch i am feeling i should reset the abi number back to the mvl range ... ie 200 ... as i am bumping the primary version
<smb> apw, Yeah, sounds reasonable. Though, could it cause confusion with documentation about branches?
<smb> iow, the only problems would be in our heads, I guess
<apw> don't think so as -100 == fsl (native), -200 == mvl (native), -600 == fsl (older kernel), -700 == mvl (older kernel)
<smb> true. wfm, then
<apw> so we go from 2.6.31-702 -> 2.6.32-200 
<apw> i think that is logical and sensible
<smb> yes, other packages also reset their abi back when the version goes up, so it sound reasonable
<cking> hrm
<apw> cking, ?
<cking> just making sure I could write to the channel
<apw> heh ahh
<tgardner> apw, I've been reincarnated
<apw> tgardner, oh dear
<apw> thats going to take some getting used to
<tgardner> well, I'll bug the ops duded to let me have my old nick back
<tgardner> dudes*
<apw> phew
<bjf> test
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<DanaG> hmm, are the ubuntu mainline builds supposed to have Staging disabled?
<DanaG> Most specifically, I need the samsung-laptop driver.
<DanaG> hmm, my question about Staging in the mainline builds still stands.
<DanaG> Specifically, I need the samsung-laptop module.
<b0b_rox0r> hi, my ubuntu won't boot any longer, it stops beforce the rescue prompt, is this the right channel for getting help?
<acicula> b0b_rox0r: best try ubuntu or ubuntu+1 for support
<acicula> ones for current versions and +1 is the devel version
<b0b_rox0r> k thanks
#ubuntu-kernel 2010-01-27
<abogani> Hi All, Who of the Ubuntu Kernel Team are interested on low latency kernel flavour?
<jjohansen> abogani: I have some interest, but rtg is the one who kicked out the proposal and has been looking at it
<abogani> jjohansen: Ok Thanks.
<LLStarks> ogasawara_ are you there?
<LLStarks> anyone here that knows a thing or two about screen blanking?
#ubuntu-kernel 2010-01-28
<RAOF> apw: Can I get a linux-backport-modules-nouveau metapackage in your lbm ppa?  The DDX requires the kernel module, so I need a Depends line on something that'll ensure a kernel module.
<RAOF> apw: linux-backport-modules-nouveau is slightly broken; It creates a /sys/bus/pci/devices/0000:00:02.0/lbm-drm directory rather than /sys/bus/pci/devices/0000:00:02.0/drm, which breaks libdrm's KMS detection.
<Ng> the apport/whatever thing that asks questions about kernel oopses really needs "I don't know" answers to the questions
<Ng> I don't know if the oops I'm currently reporting happened before, or what caused it. I didn't even know my kernel had oopsed until the little crash icon appeared in the panel ;)
<smb> Ng, Heh, yeah maybe. But in a nutshell I'd use "no" then. Otherwise you would know. :-P
<Ng> smb: indeed, I had to say no, but how do you distinguish between "I don't know, so I said no" and "I definitely know the answer is no"? :)
<apw> heh ... not an unreasonable position
<smb> Ng, I fear only from users adding comments to the created bug. apw Yeah, we might need to think on that
<RAOF> apw: Good... morning?  :) I've tried your linux-backports-modules-nouveau PPA; it works nicely, modulo the issues that are in backscroll.
<apw> scrollback has no other messages from you here
<RAOF> It doesn't?  Ok.
<RAOF> So, the first one is just a general packaging wishlist: the DDX package will need to depend on something to ensure there's a nouveau kernel module.  A linux-backports-modules-nouveau{,-generic,etc} metapackage would be good.
<RAOF> The second one is that I think renaming drm -> lbm_drm breaks libdrm's KMS detection; libdrm walks /sys/bus/pci/devices/$DRMDEVICE/, looking for either a drm:controlD* file, or a drm/ directory containing a controlD* file.
<RAOF> The backports module creates a lbm_drm directory instead, so libdrm says that KMS is unavailable - and since the nouveau X driver no longer has userspace modesetting code, it bails when it detects that KMS is unavailable.
<RAOF> Patching out the DDX's check for KMS makes everything work swimmingly, though.  Compiz is back on my nouveau laptop :)
<apw> RAOF, ahh ... hrm ... ok the meta package is in the pipe once LBM goes into the main archive a meta package will come with it, i'll try and remember to get that uploaded to the PPA 
<apw> the lbm_ prefix is more problematic
<apw> as i thkn the /sys files are based on the module name, but i can investigate
<apw> i block renamed them all to avoid the checks in the twin drm drivers for 'mkdir must work' in sysfs
<abogani> Hi All, Someone could recall me how "updateconfigs" works?
<abogani> If it works obviously... Executing "fakeroot debia/rules updateconfigs" return a "dh_testdir: cannot read debian/control: No such file or directory".
<smb> abogani, Do a frd clean before that
<abogani> smb: frd?
<smb> abogani, My bad shortcut for fakeroot debian/rules
<abogani> smb: Yeah you are right: it works now.
<abogani> smb: Could you recall me how use updateconfigs? I just added a new flavour...
<smb> abogani, updateconfigs just goes through the flavours and sorts options that are common to common levels global, arch, flavour
<smb> debian.master/config.common.ubuntu defines options used by everything, i386/config.common.i386 those common for all i386 flavours and then i386/config.flavour.generic those specific to that flavour
<abogani> smb: Ok but where I should place the my-new-flavours-kernel-config-file (in way that will be considered by updateconfigs)?
<smb> abogani, note (not sure how much you followed the changes since hardy) there are no generated files in git anymore. You create those with fakeroot debian/rules clean and hopefully should be able to remove with a distclean
 * abogani really remain to Hardy times :-)
<smb> place it into debian.master/<arch>/config.flavour.<yourflavour>, then calling updateconfig should remove all stuff that is common to generic configs. Correct apw?
<apw> correct
<abogani> smb, apw: Thanks!
<LLStarks> ogasawara, you know alot about blanking, right?
<ogasawara> LLStarks: Uhh, I'm not sure what you mean by that.  Can you be more specific.
<ogasawara> LLStarks: better yet, point me to a bug # :)
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/496842
<ubot3> Malone bug 496842 in gnome-power-manager "Can't unblank my Inspiron 640m after a lid close" [Undecided,Confirmed] 
<LLStarks> ogasawara, that apport command does nothing after i answer the questions
<LLStarks> nvm
<LLStarks> it took a while
<ogasawara> JFo: did you say you put bug 502219 on the list?
<ubot3> Malone bug 502219 in linux "Kernel errors triggered with SSD storage" [Medium,Triaged] https://launchpad.net/bugs/502219
<JFo> let me check
<JFo> no, I don't have it
<JFo> will investigate and add
<ogasawara> JFo: thanks.  It was brought up in the ubuntu dev week talk, so figured might be good to look at
<JFo> certainly
<JFo> btw, I have copied off your talk today for review later.
<JFo> Maybe it will save you from some questions from me :)
<ogasawara> JFo: cool, they usually archive it to some link in a few hours
<JFo> yeah, I copied it and chopped out all the join/part messages
<JFo> so it is easier for me to read
<crimsun> _bjf: what do you think of enabling verbose debugging for the c-o-d alsa-driver builds?
<crimsun> _bjf: pro: ability to trace HDA codec init.  con: ring buffer spam
<crimsun> _bjf: for the pro, it's easier to detect when an incorrect quirk is being used or if an existing quirk needs to be modified.  (I already fixed an issue with my new laptop this way.)
<bdmurray> ogasawara_: I think bugs 414444, 413139 and 351119 might be dups ;-)
<ubot3> Malone bug 414444 in linux "[Sony Corporation PCG-FXA63(UC)] hibernate/resume failure" [Undecided,Incomplete] https://launchpad.net/bugs/414444
<ubot3> Malone bug 413139 in linux "[Sony Corporation PCG-FXA63(UC)] hibernate/resume failure" [Undecided,Incomplete] https://launchpad.net/bugs/413139
<ubot3> Malone bug 351119 in linux "[Sony Corporation PCG-FXA36(UC)] hibernate/resume failure" [Undecided,New] https://launchpad.net/bugs/351119
<moore> quick question: what's the difference between the kernels? specifically, who should be using the drm-intel-next kernels?
<RAOF> apw: If it's hard to change the lbm_ prefix it would be trivial to patch libdrm to also match in lbm_drm/controlD*.
<bryceh> heya RAOF
<RAOF> bryceh: Howdie.
#ubuntu-kernel 2010-01-29
<slytherin> TheMuso: apw: Is there any particular reason why bug 506546 is still not fixed?
<ubot3> Malone bug 506546 in linux-ports-meta "Bump version for karmic-security" [High,Confirmed] https://launchpad.net/bugs/506546
<smb> slytherin, The reason is that security is currently in progress
<smb> It will be fixed when all other images get updated
<slytherin> smb: What all other images?
<slytherin> Can you please point me to the latest upload for karmic-security?
<smb> the non-ports
<smb> slytherin, Not yet as it is not ou yet
<smb> We are talking about the security upload to come
<slytherin> Ok. But the last security release has been out for quite a while. So shouldn't this version bump be processed anyway? Otherwise those using ports are using less-secure kernels.
<apw> slytherin, yes that should have been yes.  we have tightened up proceedures to make it occur from the next one on
<apw> i think in part in response to your prodding
<smb> Correct, as there was a security release immediate it sounded like the quicker thing
<slytherin> Ok. If the security release is just a few days away then that is fine.
<smb> Its going through some final test now and should be there soon
<slytherin> oh, that's ok then.
<slytherin> thanks for all the info
<smb> slytherin, np, thanks for bringing that up. it has been a gap in the process
 * apw does the admin dance on the bug
<abogani> smb: Are you around?
<smb> abogani, yeah, at least physically
<abogani> smb: :-)
<abogani> smb: About karmic: 31.12 is already included into 18.55?
<smb> abogani, No, that is still waiting for security. -18.55 is up to 31.9
<abogani> smb: Ok. How can understand when 31.12 will be shipped with Karmic? $(head Makefile | grep EXTRAVERSION) is still valid?
<smb> abogani, Yes, that still gets updated when we pull in the upstream stable releases.
<abogani> smb: Thanks Stefan.
<smb> abogani, You're welcome :)
<bigcx2> hey all, i'm not sure if this is the right outlet for my question...
<bigcx2> but
<bigcx2> i'm trying to install karmic on a intel atom (ich7) chipset
<bigcx2> but i can't get my ethernet driver (e100) working properly
<bigcx2> it says in dmesg that it's correctly up and given an irq
<bigcx2> but that irq is never listed in /proc/interrupts?
<bigcx2> so dhclient says "resource temporarily unavailable"
<bigcx2> i've tried enabling PnP in my bios to no avail
<bigcx2> i haven't found anyone else out there that has a problem with this chipset
<bigcx2> does anybody have any suggestions? this almost seems like a bug, but i guess i figured someone else would have run into it by now
<Kano> hi, did you see 2.6.32.7?
<bigcx2> Kano: are you asking me?
<Kano> anybody who updates lucid
<bigcx2> Kano: sorry, thought you were referring to my question
<Kano> no idea what your question was
<bigcx2> nm you just joined!
<zul> ogasawara: ping 
<Solarion> does Karmic have ATA TRIM support?
<crimsun> Solarion: no
<crimsun> Solarion: you need to track 2.6.33 if you want features of that ilk (noting also that Linus tagged 2.6.33-rc6 recently)
<DanaG> hmm, are the mainline builds supposed to have "staging" dir entirely disabled?
<crimsun> DanaG: the best course of action is to file a bug and ask on kernel-team@
<mirsal> ogasawara, ping
#ubuntu-kernel 2010-01-30
<Solarion> is 2.6.33 gonna be in Lucid?
<Solarion> somehow, I thought trim was already done
<DanaG> .config:1056:warning: symbol value 'm' invalid for FB_VESA     .config:4418:warning: override: reassigning to symbol STAGING     .config:4419:warning: override: reassigning to symbol STAGING_EXCLUDE_BUILD     .config:4420:warning: override: reassigning to symbol SND_HDA_HWDEP     .config:4421:warning: override: reassigning to symbol SND_HDA_RECONFIG 
<DanaG> Looks like that's why staging is missing.
 * tc111 wonders if anyone still pxe / netboots anymore
<tc111> my served up pxe / netbooting livecds (looped) worked prior to upgrading to karmic, now none of them do. here's my config, what's wrong with my server config: http://paste.ubuntu.com/365130/
<JFo> tc111, people still PXE boot, but you will find more help in #ubuntu
<tc111> JFo: i wish...
<JFo> heh, it was worth a shot :)
<JFo> unfortunately the kernel team are in transit to the Platform Sprint
<JFo> so there is no one in here that would be able to help
<tc111> JFo: "Platform Sprint"?
<JFo> yeah, for Lucid
<DanaG> oh yeah, so anyway, I figured out what was up with staging.
<JFo> what is up with staging? DanaG 
<DanaG> http://ohioloco.ubuntuforums.org/showthread.php?t=1358346&page=11
<DanaG> (removed line breaks)  .config:1056:warning:  symbol value 'm' invalid for FB_VESA        .config:4418:warning: override: reassigning to symbol STAGING        .config:4419:warning: override: reassigning to symbol  STAGING_EXCLUDE_BUILD        .config:4420:warning: override: reassigning to symbol SND_HDA_HWDEP        .config:4421:warning: override: reassigning to symbol SND_HDA_RECONFIG
<DanaG> Zero of the staging drivers are being built.
<JFo> DanaG, that thread is quite busy. Is there a bug open on that?
<DanaG> hmm, not yet.  What would I report it against?
<JFo> linux package as a start. if that is wrong I'll change it.
<JFo> let me check something
<JFo> DanaG, I may be wrong
<JFo> it looks like we specifically do not want to build some drivers in the staging dir
<JFo> https://lists.ubuntu.com/archives/kernel-team/2009-April/005464.html
 * JFo checks the particular drivers
<DanaG> The thing is, check the log...
<DanaG> it's as if CONFIG_STAGING (that is, the whole menu!) is disabled.
<DanaG> I specifically want the samsung-laptop driver, and the r8192e driver (which is already in the ubuntu regular kernel).
<JFo> hmmm
<JFo> one sec...
<JFo> from what I am seeing you would have to build that driver manually
<JFo> but let me make sure
<JFo> DanaG, this thread may be helpful: http://ubuntuforums.org/showthread.php?t=1370135
<JFo> hmmm, maybe not
<DanaG> =Ã¾
<DanaG> the thing was a gift, so yeah, samsung is non-ideal, but I need to live with it.
<DanaG> Alternately, can that thing be built out-of-tree?
<JFo> should be able to
<JFo> maybe this will give some clues: http://usbip.svn.sourceforge.net/viewvc/usbip/linux/trunk/drivers/README?view=markup
<JFo> it isn't for the same package but the commands may help a bit
<DanaG> ah, thanks.  i'll check that out.
<JFo> ooh, or this DanaG http://www.cyberciti.biz/tips/compiling-linux-kernel-module.html
<JFo> or this http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
<JFo> when it rains it pours
<JFo> and finally this DanaG https://help.ubuntu.com/community/Kernel/Compile
<JFo> do let me know if any of those help
<JFo> that last one shows promise
<JFo> they are not trivial by any means
<DanaG> I'll have to try it another time... I'm not on that computer at the moment.
<JFo> hope I gave you something that will help :)
<DanaG> I've done whole-kernel compiles before; just not out-of-tree stuff.
<JFo> yeah
<JFo> this one: http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html looks to be of the most help
<mirsal> ogasawara, ping
#ubuntu-kernel 2010-01-31
<Laibsch> Hi, I got myself an ASUS 1005p this week.  As documented on http://wiki.debian.org/DebianEeePC/Model/1005P the current kernel doesn't yet properly support the Atheros wifi chip.  A simple recompile of the current lucid kernel with http://paste.debian.net/58163/ failed: https://launchpad.net/~r0lf/+archive/ppa/+build/1474787
<Laibsch> Hm, just realized I was compiling for karmic, that may be the issue.  Retrying for lucid to see if that works better.
<MTecknology> Anybody have any idea what happened here?  http://paste.ubuntu.com/366029/
<Q-FUNK> hi!  
<Q-FUNK> I just upgraded my Debian test host and noticed that, upon reboot, its kernel 2.6.32 mounted both / and /home as ext4, as defined in /etc/fstab, while my Ubuntu hosts only mount non-root partitions that way. 
<Q-FUNK> I was wondering if there's any significant diference between those kernels that could explain this?
<Q-FUNK> in both cases, we're talking about ext3 partitions that have been defined as ext4 in /etc/fstab to enable the compatibility mode.
<Q-FUNK> ogasawara: is there any final conclusion as to what will be done with bug #396286 ?
#ubuntu-kernel 2011-01-24
<apw> mjg59, i have wondered why we don't have synthetic ones for cpu types
<apw> smb, https://bugs.launchpad.net/ubuntu/+source/linux/+patches
<ilmari> the drm-intel-next kernel packages havent been built since the 13th
<cking> apw, https://wiki.ubuntu.com/Kernel/Reference/S3
<apw> ilmari, oddness
<apw> ilmari, hrrm something very odd there, just triggered it now and it is building
<ilmari> apw: thanks
 * ilmari needs to test a recent change for LP#680748
<apw> bug #680748
<ubot2> Launchpad bug 680748 in xserver-xorg-video-intel "[arrandale] flicker on LVDS laptop display with stripy patterns" [Undecided,New] https://launchpad.net/bugs/680748
<ilmari> apw: how long does the build usually take?
<apw> 2-3 hours, but i think it was queued second
<apw> Bisecting: 1999 revisions left to test after this (roughly 11 steps)
<apw> Bisecting: 1999 revisions left to test after this (roughly 11 steps)
<apw> sigh
<amitk> lol
 * apw  blames amitk .... its suspend that is bust after all
 * amitk doesn't care about suspend or hibernate...
<amitk> ... yet!
<amitk> apw: blame manjo 
<ilmari> apw: okay, I'll check the directory this afternoon (GMT)
<apw> ilmari, yep, its still building the mainline tip of the day, drm-intel-next is next
<apw> amitk, always :)
<mjg59> apw: Because system devices can't have modaliases
<mjg59> apw: Limitation of the driver core - someone's meant to be fixing it
<apw> mjg59, fair enough
 * apw struggles on with bisecting an amd64/i915  suspend hang ... 11 more to go
 * apw lunches 
<ara> hey guys!
<ara> how are you doing?
<ara> do we know when we are getting the new maverick -proposed kernel in the -proposed archive?
<tgardner> sconklin,  ^^
<sconklin> ara: pitti just copied it moments ago. The version you want is 2.6.35-25.44
<tgardner> cking, AceLan_: bouncing tangerine for security update soon.
<ara> sconklin, yes, I saw that, thanks!
<cking> tgardner, ok 
<apw> sconklin, how did you not go mad doing bisects
<JFo> need coffee, brb
<sconklin> apw it's not bad at all when you have fast builds on tangerine, and a couple of testers who get you results in 10 mins or less. I did 7 or 8 build/test cycles in a day and got a final result!
<tgardner> apw, Linus' tip has the doc build failure fixed.
<apw> sconklin, mine started about 'about 12'
<apw> tgardner, excellent will suck it up shortly
<tgardner> apw, we'll need it to procude an -rc2 based kernel
<tgardner> produce*
<sconklin> ugh. Mine started at about 8. I could have probably cut two off of that my guessing at a range of commits, but it wasn't worth the uncertainty
<apw> tgardner, yep
<apw> tgardner, is tangerine bouncing now ?
<tgardner> apw, yep, it takes a bit
<apw> tgardner, didn't want to start bisect 6 without waiting for the bounce
<tgardner> apw, I didn't realize you were in the middle of something. I could have waited. 
<apw> tgardner, nope not at all, it'll take all day at an hour a spin
<apw> just wanted to make sure you'd done it before i started a build
<tgardner> apw, besides some security updates, the armel chroot was hung and I couldn't get it to bail out.
<tgardner> apw, tangerine is back
<apw> tgardner, yep, utterly reasonable to bounce it ... didn't want to interfere
<apw> has held me up by exactly 25s
<apw> i think i can live with that
<cking> really?
<tgardner> apw, https://lists.ubuntu.com/archives/kernel-team/2011-January/014095.html
<ilmari> apw++ # new drm-intel-next build
<apw> ilmari, cool
<bjf> https://spreadsheets0.google.com/a/canonical.com/ccc?hl=en&key=tOvtWlTi17QL1bZm-0dCKEg&hl=en#gid=0
<bjf> https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs
<apw> bjf, can you point me at the brad arsenal classes branch, i've lost my mind and it
<bjf> apw, are you looking for: bzr+ssh://bazaar.launchpad.net/~arsenal-devel/arsenal/python-launchpadlib-toolkit/
<bjf> apw, or: bzr+ssh://bazaar.launchpad.net/~canonical-kernel-team/arsenal/kernel/
<bjf> apw, or: bzr+ssh://bazaar.launchpad.net/~arsenal-devel/arsenal/master/
<bjf> apw, that's all i know about
<apw> bjf, i thin the first one was the one i wanted, ta
<JFo> ah yes, the first one
<JFo> sorry I was no help there apw :)
<bjf> tgardner, can you accept my nominations on bug 706149 ?
<ubot2> Launchpad bug 706149 in linux "CVE-2010-4074" [Undecided,New] https://launchpad.net/bugs/706149
<tgardner> bjf, done
<JFo> <-lunch
<apw> Bisecting: 5 revisions left to test after this (roughly 3 steps)
<apw> GAH
<apw> https://www.launchpad.net/ubuntu/+source/linux
<hyperair> kernel bisects are painful
 * tgardner --> lunch
<apw> Bisecting: 2 revisions left to test after this (roughly 2 steps)
<poelzi> pah. 6.37 is the worst kernel ever
 * jjohansen -> lunch
<apw> poelzi, false, .38 is much worse
<poelzi> apw: hihi. but .38 is not a real release
<apw> .37 has been one of the better ones on my kit
<poelzi> i'm so unsure whats broken. kms, radeon, cachefiles,... i got so many tracebacks
<poelzi> kms is slow like hell here at least
<poelzi> but without it, x server makes even more trouble
<apw> poelzi, if you have backtraces get them into bugs and to us, as we are not seeing them
<bryceh> apw, hum didn't you tell me .37 was crackful and that all goodness was going into .38?
<apw> bryceh, i think i said that all of the crack was going into .38-rc1
<bryceh> apw, ah that's right... you said it didn't even boot
<apw> .37 has been pretty stable on everythiong i ahve but as noone lets me have nvidia or radeon h/w
<JFo> because you break things :P
<poelzi> apw: yes, i' m working on get them backtraced
<poelzi> apw: can you take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/706394
<ubot2> Launchpad bug 706394 in linux "kernel should have CONFIG_CFQ_GROUP_IOSCHED" [Undecided,New]
<poelzi> without it, the the cgroups io subsystem is useless and it's enabled
<bryceh> apw, if you have a desktop/server type box, then I'm sure $$ could be scared up to send you a few ati/nvidia cards 
<bryceh> however frankly >80% of the gfx bugs we hear about are on -intel anyway ;-/
<apw> bryceh, cause most people buy intel sadly
<bryceh> apw, likely so.  Also I think Intel does a bit more experimental gfx dev work in releases than the other guys.
<apw> yeah a bit of both in all likelyhood, cursed both ways arn't we
<manjo> tgardner, https://wiki.ubuntu.com/Kernel/Testing/UbuntuUEFI
<sforshee> patches for bug 659143 are in Linus's tree for 2.6.38
<ubot2> Launchpad bug 659143 in linux "64bit-only: regression: kernels >=2.6.34: rt2800pci: load firmware Error with ralink [1814:0781]" [Undecided,Fix committed] https://launchpad.net/bugs/659143
<sforshee> am I right in thinking this is something we'd want to fix in maverick SRU?
<tgardner> sforshee, seems reasonable if folks are actually encountering the bug
<sforshee> tgardner, well, 10 people have marked the bug as affecting them
<sforshee> the guy who reported the bug actually wrote the patches that fix it
<tgardner> sforshee, we really like SRUs to go through upstream first. dunno if this one has yet...
<sforshee> tgarnder, both patches are in 2.6.38-rc1
<sforshee> tgardner, ^^
<sforshee> typo
<tgardner> sforshee, cool, that makes it a lot easier
<manjo> bjf, not sure if this helps... git.alsa-project.org
<bjf> manjo, thanks but no, takashi does a daily snapshot of his git repo in a form that can be wrapped in debian packaging and uploaded for a daily build
<sforshee> tgardner, can you accept my nomination on bug bug 659143 ?
<ubot2> Launchpad bug 659143 in linux "64bit-only: regression: kernels >=2.6.34: rt2800pci: load firmware Error with ralink [1814:0781]" [Undecided,Fix committed] https://launchpad.net/bugs/659143
<JFo> I got it sforshee 
<sforshee> JFo, thanks
<JFo> np
<smoser> i need some help. there is a linux-image-2.6.32-312-ec2 in lucid-proposed
<smoser> but there is no linux-ec2 (built by linux-meta-ec2) there
<smoser> how would that normally be uploaded ?
<smoser> smb, ^ 
<bjf> smoser, sconklin and i are discussing it 
<bjf> smoser, it looks like we uploaded the package to our ppa and it got built but it didn't get copied to -proposed
<smoser> so... a copy is coming soon ?
<bjf> smoser, we are going to reach out to an archive admin
<sconklin> smoser: no answer from any archive admin, we'll keep trying and/or send email
<smoser> sconklin-away, bjf kirkland will address if you can paste in #ubuntu-devel what you need
<bjf> smoser, StevenK took care of it for us, thanks
<kees> smb`: I think the RO/NX+Xen issues have found a solution upstream. have you been following that thread?
#ubuntu-kernel 2011-01-25
<neur0n> hello?
<dsfg> can anyone answer a computery question
<jjohansen> dsfg: I can try
<dsfg> it's a dumb question and not about ubuntu
<dsfg> but how reliable is the info you get when you lookup an IP address to see which country it;s in?
<virtuald> not reliable at all since you can use a proxy or other form of tunnel, but i think it's usually right
<dsfg> ok im trying to find out where a person is, i got his IP
<dsfg> and he is really dumb with computers
<dsfg> so i dont think he even knows what  a proxy is
<dsfg> i just want to see if he's lying about being in california on vacation, when i look up his IP it confirms he is lying but maybe the IP is lying
<dsfg> instead
<jjohansen> dsfg: its fairly reliable, if there isn't a proxy
<dsfg> everywhere says the IP is on costa rica, so should i trust that?
<dsfg> i know he isnt smart enouhg to use a proxy
<dsfg> but is there anything else that would cause a perosns IP to be in costa rica
<jjohansen> dsfg: well there is potentially bugs, or cache poisoning
<dsfg> but for the most part it's reliable?
<jjohansen> err make that stale cache
<jjohansen> yes
<dsfg> IP depends on your ISP not your computer right?
<dsfg> i hope that question makes sense
<jjohansen> yes, mostly depends on your ISP
<dsfg> so, if someone had a laptop they bought in costa rica, but was in california using it
<dsfg> would they have a US or costa rican IP?
<jjohansen> US,
<jjohansen> its not like cell phones
<jjohansen> your "unique" device id would be the ethernet mac
<dsfg> what if he was on a cellphone
<dsfg> in california
<dsfg> using 3g
<dsfg> would he have a US ip or costa rica?
<jjohansen> hehe, that is an interesting problem
<jjohansen> it would depend
<dsfg> on what
<jjohansen> it would depend on how the cellular provided routed cell data traffic, and contracts with other cell carriers
<dsfg> i'm 99% sure he is on a laptop
<dsfg> using wifi
<dsfg> and not a cellphone weith 3g
<dsfg> it's not illegal to find someones IP and trace it to see what country theyre in, is it?
<jjohansen> generally you could accept that it will come from the cell carriers IP pool, so in US us carrier pool, in costa rica - that phone companies pool
<jjohansen> uh no
<dsfg> i feel like i did something wrong
<dsfg> and went snooping!
<jjohansen> well it might be, depends where you are
<dsfg> canada
<jjohansen> no
<dsfg> basically i think this guy is lying about being on vacation in california
<dsfg> cause his IP says he;'s still in costa rica
<jjohansen> geo location is done all the time, for targeting adds or giving you access to servers caching the data closer to you
<jjohansen> uh I am not even going to go there
<dsfg> but i guess i cant be sure
<dsfg> i can be like 99% sure
<jjohansen> it is possible, especially if you are judging from email, as that will likely go out to his isp smtp server which is in costa rica
<dsfg> nope
<dsfg> wasnt email
<jjohansen> I really can't tell you how likely it is, but geo location is right more often than not
<dsfg> okay cool
<dsfg> n ow ive been lied to :(
<dsfg> well ty vm guys
<diwic> anyone still around for ubuntu-audio-dev meeting?
<diwic> sorry wrong channel
<apw> diwic, heh :)
<diwic> apw, yeah I was a little late and was in a hurry :-)
<diwic> apw, I've done worse - the window was not scrolled down completely and so I kept writing and writing wondering why my text didn't show up ;-)
<apw> diwic, heh i've done that too, one does look a bit of a waz 
<ari-tczew> hello
<ari-tczew> mjg59: do we really need separate binary package for smartdimmer?
<ari-tczew> can smartdimmer be used with other drivers than nvidia?
<ari-tczew> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/nvclock/natty/changes?filter_file_id=smartdimmer.install-20090626033400-d3ab2kzykpm31he0-184
<apw> commit 9bea7f23952d5948f8e5dfdff4de09bb9981fb5f
<apw> Author: Rusty Russell <rusty@rustcorp.com.au>
<apw> Date:   Sat Jun 5 11:17:37 2010 -0600
<apw>     module: fix bne2 "gave up waiting for init of module libcrc32c"
<sconklin> apw:   https://wiki.ubuntu.com/Kernel/KernelBisection
<apw> sconklin, overall makes sense
<sforshee> apw: bug 215802
<ubot2> Launchpad bug 215802 in linux "rtl8187 link quality poor" [Undecided,Confirmed] https://launchpad.net/bugs/215802
<sforshee> apw: http://launchpadlibrarian.net/58772782/rtl8187.patch
<apw> bjf, looks like the CPU count change on maverick has popped the abi on amd64 ... pre-proposed build failed
<bjf> apw, looking
<bjf> apw, there's already an abi bump in that batch, i'll dig into it and work it out though
<bjf> apw, right after the last "start new release" is an "bump abi"
<tgardner> bjf, apw: I already bumped the ABI on Maverick.
<bjf> tgardner, apw, i'll look into the problem
<tgardner> bjf, no, I'm saying that I already fixed the build failure and re-pushed with the ABI bump. I simply rebased it so taht the build is bisectable
<bjf> tgardner, AH!
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<tgardner> bjf, I'm surprised there isn't an ABI bump required for Lucid. Lemme do a quick build
<apw> tgardner, ahh good
<tgardner> bjf, I'm gonna rebase maverick master-next once again in order t0 catchup with master
<bjf> tgardner, ack
<tgardner> bjf, just a quick check on gitweb to make sure I'm not gonna trash something....
<bjf> ##
<bjf> ## Kernel team meeting in 3 minutes
<bjf> ##
<JFo> <-lunch
<diwic> apw, this channel works for me
<apw> diwic, so i am not aware of there being a work-item gating someone for this docs
<apw> so where can i find out who is waiting on it
<diwic> apw, that's beyond my knowledge as I'm not really familiar with the work item infrastructure
<apw> diwic, well to be on the release team radar its gonna be in the work items system
<apw> but anyhow, who is waiting on it?
<diwic> apw, well, I'd say alessio / TheMuso
<diwic> apw, for making the lowlatency flavour
<diwic> apw, which, as I understand it, they want to have in universe for Natty 
<apw> well i am pretty sure allessio has already made one, so doesn't really need any documentation overall, its unlikely they are blocked
<diwic> apw, are we having information on how to best rebase with the official channels w r t SRU and security?
<apw> i am not sure i was expecting that to be in the documentation anyhow
<apw> rebases are all advertised on release in our repos
<diwic> apw, and I'm not sure alessio's kernel follows all conventions we want in its current state
<apw> diwic, no but last time he dropped out when we tried to help him and it got lost in the noise
<diwic> apw, but a document would help others to help out if one person "drops out"
<apw> yep, and it is on my todo list, but i'd not heard any real consumers so its not been a priority
<apw> poor Guest34014 
<diwic> apw, ok so my expectations on this document would be instructions for how to get SRU and security updates for a derivative flavour, as well as "convention" instructions
<apw> that can be encapsulated in one line however, "follow updates to master"
<apw> as all cves and sru's go there first
<diwic> apw, so now you've made half the document ;-) 
<apw> i guess i am not understadning why this is so hard for people 
<diwic> apw, can one get notifications when updates to master occur?
<diwic> apw, or do we have to poll once a day/hour/etc?
<tgardner> bjf, have we formally requested regression testing for kvm on the various releases?
<apw> diwic, there should be emails out to the kernel-team and installer when they occur in general
<bjf> tgardner, i believe it was discussed but not sure we formally requested such testing
<apw> diwic, also they should apper on the per-series changes list i guess
<diwic> apw, ok, so one can listen to them either manually or automatic (the latter preferred) - I'm not saying it's hard, it's just a lot of things to be aware of
<bjf> tgardner, part of the discussion was that QA was using that for testing rather than real HW and we had an problem with that
<apw> bjf, i presume you mean 'just kvm' in that context
<bjf> apw, correct
<apw> diwic, i am not against writing it, its just not at the top of my list.  i have a2 to worry about
<apw> diwic, i don't think there is much blocing people without it, so its not obviously a priority
<apw> diwic, i suspect anyone i would want making kernels ought to be up on how the packaging works well enough
<apw> diwic, to figure it out, or we should worry more about other things going wrong.  like linux-libc-dev getting wacked
<tgardner> bjf, in this case I'd like to verify that we've not regressed KVM gues support on the host under test.
<bjf> tgardner, sconklin and I will bring it up with QA
<tgardner> bjf, reference CVE-2010-3698 as a basis for your discussion
<ubot2> tgardner: The KVM implementation in the Linux kernel before 2.6.36 does not properly reload the FS and GS segment registers, which allows host OS users to cause a denial of service (host OS crash) via a KVM_RUN ioctl call in conjunction with a modified Local Descriptor Table (LDT). (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3698)
<diwic> apw, ok. so I'll try to communicate that this document won't be created within the coming weeks and given that, #ubuntu-kernel and the ML would be helpful in general for any specific questions.
<apw> diwic, as you know we are short of bodies right now even for the committed effort
<apw> diwic, seems about right yes
<diwic> apw, ok, thanks.
<diwic> apw, I'll send something out on the ubuntu-studio-devel ML about it
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - February-01 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<diwic> how many bits is a pointer in a 32-bit-pae kernel?
<tgardner> diwic, 32
<diwic> ok, thanks
<diwic> tgardner, so sizeof(buf2 - 8) would evaluate to "4"?
<jjohansen> diwic: no
<jjohansen> sizeof(buf2) - 8 might depending on what buf2 is
<tgardner> sizeof(void *) will evaulate to 4
<diwic> jjohansen, so I have discovered a bug where it says sizeof(buf2 - 8), it should say "sizeof(buf2) - 8"
<jjohansen> diwic: but you need to be careful with sizeof and structs, as C can pad them and return sizes different than you might expect
<diwic> jjohansen, so the question is what "sizeof(buf2 - 8)" would evaluate to in a 32-bit-pae kernel
<tgardner> diwic, sizeof(buf2 - 8) is definitely a bug
<jjohansen> diwic: ugh, I am surprised that even compiles
<diwic> jjohansen, I'm curious if it could be a security thing or if I should just fix it and send upstream
<diwic> fwiw, buf2 is a char[24]
<jjohansen> diwic: can you point me at the code?
<diwic> jjohansen, sound/pci/hda/hda_eld.c:384 
<jjohansen> diwic: natty?
<tgardner> apw, I pushed CONFIG_NR_CPUS=256 for natty amd64 -generic. Am boot testing on hoover.
<diwic> jjohansen, that line has been in there since 2008
<diwic> jjohansen, in function hdmi_show_short_audio_desc
<jjohansen> diwic, okay looking
<tgardner> diwic, it doesn't even make sense.
<tgardner> it really should be sizeof(buf2)-8
<diwic> tgardner, so far we agree :-)
<tgardner> diwic, have you confirmed that it fixes the problem?
<diwic> tgardner, the question is if it could evaluate to something larger than buf2
<diwic> tgardner, nope, don't have hw
<jjohansen> diwic: I don't see how it has any security concerns
<tgardner> diwic, you could write a short test program to see what it does.
<diwic> jjohansen, good. I'll then just send a patch upstream.
<diwic> tgardner, I did so and it seems to always evaluate to "8" on my amd64
<diwic> tgardner, so I guess it evaluates to a pointer
<jjohansen> diwic: yep, buf2 - 8 works out as a pointer
<tgardner> diwic, more likely it evaluates to the last constant in the sizeof() expression.
<diwic> tgardner, nope, tried sizeof(buf2-35) which also evaluates to 8
<tgardner> well, regardless, that code is busticated
<jjohansen> right, its an array - const which is identified as pointer arithmetic, so it returns a pointer to -8 from the start of the array and then takes the sizeof the pointer
<bjf> apw, you reported a bug against the wiki theme, what was the package name that you filed that against ?
<tgardner> diwic, don't forget to Cc: stable@kernel.org on tat patch.
<tgardner> in the commit message, not in email to LKML
<diwic> tgardner, agreed
<tjaalton> smb: hey, re bug 415353, do you mean that the proposed lucid kernel should have the patch you mentioned?
<ubot2> Launchpad bug 415353 in linux "karmic/lucid installation slow on "detecting network hardware" with bnx2x" [Medium,Fix released] https://launchpad.net/bugs/415353
<tjaalton> because it's not any different to the earlier ones
<smb> tjaalton, Hi, well not more differently what you tested last (which is the 90s delay)
<smb> But initially there were like hours delay reported
<tjaalton> the installer probes them twice
<tjaalton> and the timeout seems to be 100s and not 30 like on an installed system
<tjaalton> which is weird..
 * tgardner --> lunch
<smb> well the  100s (is near 90)
<smb> which is trying tree times a 30s timeout
<tjaalton> ok
<tjaalton> I'll try the kernel package
<smb> tjaalton, much appreciated
<tormod> fyi I get warnings about CONFIG_ACPI_PROCFS_POWER when booting the latest .38 mainline snapshot
<tjaalton> smb: success! though, there are ugly errors too
<tjaalton> smb: http://users.tkk.fi/~tjaalton/foo/dmesg.txt
<smb> tjaalton, If you place the dmesg into the bug report, I will have a look tomorrow. Possibly the backport needs some tweaking.
<tjaalton> alright, will do
 * smb has moved to the beer part of the evening and should not be trusted anymore. :)
 * tjaalton will follow shortly
<smb> tjaalton, but quickly glancing this may tell me that I need to pull in a few more changes from later. I went around some parts which seemed to add a new list of dependency relationships
<tjaalton> cool
<tgardner> apw, my emerald ran 3600 seconds of stress on 2.6.38-1 master-next
 * jjohansen -> lunch
<tgardner> zul, do you remember what xen version we used for Hardy?
<zul> tgardner: barely...it might have been 3.4
<zul> tgardner: gimme a sec and i can give you a better answer
<zul> tgardner: 3.3
<tgardner> zul, maybe 'UBUNTU: build/custom: Hello Xen 3.0.5'
<zul> tgardner: sounds right
<tgardner> zul, yep, I don't see any major updates after that. mostly small fixes.
<zul> tgardner: yeah it was when i was volunteering
<tgardner> man, that was awhile ago.
<zul> tgardner: it was...i still had hair :)
<JFo> I just love it when the Launchpad server disappears from under a script 
<lifeless> what happened?
<bjf> JFo, can you accept nominations ?
<lifeless> JFo: what happened?
<JFo> bjf, I can
<JFo> lifeless, I had a script running along nicely and then a huge stack trace basically meaning that the server disappeared
<bjf> jfo, please accept all my nominations https://bugs.launchpad.net/ubuntu/+source/linux/+bug/707649
<ubot2> Launchpad bug 707649 in linux "CVE-2010-4079" [Undecided,New]
<JFo> We have gotten a lot of help from various people in the #ubuntu-bugs channel. I'd like to thank charlie-tca specifically and several others in there whose nicks escape me at the moment for directing questions about kernel bugs to me. There have also been a ton of requests through irc to look at specific bugs. In those cases, and many like them, I am directing folks to the bug triage pages of our wiki. I hope that some of these folks will become re
<JFo> gular triagers, but that remains to be seen. :)
<lifeless> JFo: I treat such problems as high severity issues
<lifeless> JFo: did you get a OOPS in one of the headers? or could you pastebin the backtrace?
<ekoore> hi to all
<JFo> actually lifeless hang on a sec
<JFo> I may be experiencing connectivity issues
<ekoore> i have a small problem with the linux  kernel in my device
<JFo> bjf, all accepted
<bjf> JFo, your too kind
<JFo> lifeless, I have an install running and I told it to download updates as well. I don't normally
<JFo> :)
<JFo> bjf, it is my pleasure :)
<JFo> lifeless, so I may have accused LP unnecessarily in this case
<ekoore> JFo can you help me?
<lifeless> JFo: when LP goes wrong, please do file a bug (even if its a dupe - that guides heat after all)
<JFo> lifeless, I will indeed
<lifeless> JFo: however there isn't all that much we can do if you fill your net connection :P
<JFo> let me conduct a test in any case and I will let you know the results via bug if necessary
<JFo> lifeless, :-P 
<JFo> I wish
<JFo> ekoore, what is the nature of your problem?
<lifeless> JFo: as  background, we have 2 ssl front ends, 2 ha proxy load balances, and ~ 20 frontend appservers behind those
<ekoore> is a problemwith an acpi
<lifeless> JFo: so for that stack to just go awol is a Big Fricking Deal
<JFo> lifeless, I can definitely imagine
<lifeless> :)
 * JFo is about to rip his service provider a new one anyway
<JFo> ekoore, is there a bug open I can look at?
<ekoore> JFo: not, let me explain
<JFo> lifeless, thanks for inquiring. I can imagine you are quite busy constantly
<JFo> :)
<JFo> ekoore, ok
<ekoore> i work in a company: www.ekoore.com
<lifeless> JFo: I'm kept on my toes, yes :)
<JFo> heh
<ekoore> now i have to prepare a new device
<ekoore> multitouch with ubuntu
<JFo> ok
<ekoore> this device have a G-Sensor
<JFo> G-sensor?
 * JFo is unfamiliar
<ekoore> yes, accelerometr
<bjf> JFo, G-spot sensor
<ekoore> do you know?
<JFo> bjf :)
<JFo> ekoore, I see
<ekoore> sensor of gravitation
<JFo> I am vaguely familiar with those
<ekoore> this sensor cause a problem with acpi
<JFo> I see
<ekoore> when i rotate the tablet, the screen of the tablet power off
<ekoore> i have a solution:
<JFo> rotate as in from landscape to portrait?
<ekoore> this comand:
<ekoore> echo disable > /sys/firmware/acpi/interrupts/gpe11
<ekoore> i can write this comand in rc.locale file
<ekoore> but it is do only to the end of the boot sequence
<ekoore> is possible disabling this interrupt directly in the device
<ekoore> ?
<ekoore> directly in the kernel?
<ekoore> or to the start of boot sequence?
<ekoore> JFo, do you think that is possible?
<JFo> those are very good questions, but I don't know much about acpi events
<JFo> and the person I would normally ask is away for the day
<JFo> ekoore, do you think you would mind sending the above information to the team mailing list?
<JFo> that way the appropriate parties will see it and provide advice?
<ekoore> sure, this is not a problem
<ekoore> information about the problem?
<ekoore> where i have to write?
<JFo> ekoore, kernel-team@lists.ubuntu.com
<ekoore> and they answare me in email? 
<JFo> yes
<ekoore> ok JFo, thank you
<JFo> my pleasure ekoore 
<JFo> :)
<ekoore> JFo, do you know other person that can help me?
<ekoore> After that i send the email to the maling list
<JFo> I don't know of anyone who is available in this time zone
<ekoore> if they don't answare me
<JFo> but the people I have in mind will see it on the mailing list
<ekoore> where you come frome?
<JFo> what do you mean?
<ekoore> where do you come from?
<JFo> I am in the US
<ekoore> oh, i am in italy
<JFo> cool
<ekoore> california?
<JFo> no, I am in North Carolina
<ekoore> oh beautifoul
<JFo> yep, it is nice here
#ubuntu-kernel 2011-01-26
<lucent> what the heck, my USB-Serial adapter is now detected as an input device and not an RS232 port?
<lucent> and not 10 seconds later, now, it's detected correctly
<lucent> I'm so confused
<lucent> exact same issue as http://www.linux-archive.org/debian-user/53249-ttyusb0-not-appearing-solved.html
<apw> diwic, 32
<cking> apw, 58f6425eb92f54943878b0b3f9c1e51f99c2cb72
<ekoore> hi to all
<ekoore> i habve a problem with acpi event
<ekoore> do you can help me?
<apw_> yawn ... quiet today
 * ogra makes some noise
<apw> ekoore, whats up with it?  could you give some details, then someone might be able to
<tgardner> apw, are you still debugging something on natty?
<apw> tgardner, no i am pretty happy with it right now
<apw> tgardner, did you get a chance to 'stress' the master-next yesterday?
<apw> tgardner, working up to tying the bow, if your results are good ...
<apw> just pushing some binaries for smb et al to touch test and then it goes in
<tgardner> apw, yep, I dribbeled a note in IRC before leaving, but we all know how effective thath usually is. it withstood stress for an hour with loads of 130+
<apw> tgardner, ahh excellent
<apw> the .deb will be up in 0:34 seconds apparently
<tgardner> apw, I'll go back to my xen headache then
 * smb presses the on-button on the aspire one
<apw> smb, :)
<smb> tgardner, What kind do you have?
<tgardner> smb, CVE-2010-3699. do you still have a dom0 test machine?
<ubot2> tgardner: The backend driver in Xen 3.x allows guest OS users to cause a denial of service via a kernel thread leak, which prevents the device and guest OS from being shut down or create a zombie domain, causes a hang in zenwatch, or prevents unspecified xm commands from working properly, related to (1) netback, (2) blkback, or (3) blktap. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3699)
<smb> tgardner, I believe I still have the Hardy server installation, yes
 * smb rumbles through the harddrive collection. Yup its there
<smb> tgardner, So let me know when you got something that needs testing
<tgardner> smb, can you make sure a guest still boots on a dom0 host using tangerine:~/kern/hardy/kern-64/linux-image-2.6.24-28-xen_2.6.24-28.83_amd64.deb ?
<smb> tgardner, sure. let me boot up my box
<smb> tgardner, you are aware that -28.83 is in proposed. :) testbox was whining about downgrading. :-P
<smb> I mean .84
<apw> smb, when you get a chance: http://people.canonical.com/~apw/master-next-natty/
<smb> apw, next thing on list
<apw> ta man
<tgardner> smb, hmm, must have missed it. it took me close to 4 hours to figure out this patch.
<smb> tgardner, hmm. attempt  #1 -> box froze solid (no message seen but I have to switch vts to login). retrying...
<tgardner> smb, before you even started the guest?
<smb> tgardner, guest start was automatic from saved session
<smb> tgardner, Reboot after crash came up but without saved xen guest. And trying to start it returns an error (translated into function not implemented)
<tgardner> smb, shit. guess I'm gonna have to install some bare metal.
<smb> tgardner, For your own test system?
<tgardner> smb, yep
<tgardner> smb, unless you wanna debug this
<smb> tgardner, If you shove your patch over I can have a look. 
<smb> There is not much on dmesg you can see
 * apw opens his window, yep that is tangerine i can hear howling
<tgardner> smb, the patch and pull request are on the k-t list
<smb> tgardner, ok, I will put it on my list
<smb> apw, is next though
<smb> apw, So I guess I should not put another buld on it. :)
<JFo> heh
<apw> smb, 
<apw> smb, heh i am sure she won't mind
<smb> apw, Not quite ready yet, but soonish I may try scary-patch v2 for Lucid
<smb> apw, Ok, aspire one came up has screen and wireless and no obvious new complaints from acpi with your latest natty kernel
<apw> smb, most gratifying
<ekoore> hi apw
<ekoore> apw, do you can help me?
<apw> ekoore, so does the screen turn off in grub etc ?  i assume not ?
<ekoore> not, it poweroff only after grub
<apw> ekoore, and presumably only once we get to userspace, i assume something there is responding to it.  does the device have a network you could ssh in over and watch to see what is getting generated when the twist happens
<apw> input-events might tell you ...
<ekoore> yes
<ekoore> do you want the ip of the machine?
<apw> not really got time to poke it right now, trying to get the natty kernel sewn up
<apw> but i suggest you try and work out what key is getting generated in userspae
<apw> that likely can be disconnected
<ekoore> i have the same problem in usersace
<ekoore> can i do the comand for sisabling it, to the start of boot sequence, and not to the end, with rc.local?
<ekoore> what is the version of the kernel in natty?
<apw> ekoore, its going to be .38
<ekoore> ok i understand
<apw> ekoore, ok i've had a bit of a poke and cannot see an easy way to turn it off early
<apw> it seems to get turned on the first time when the consumer of the gpe starts, but i have no way to know
<apw> what might be triggering that
<ekoore> is not possible disabling it from the kernel source?
<apw> ekoore, i am sure you can change the kernel to prevent it being enabled, there is no obvious mechanism in there already to do so
<apw> ekoore, the assumption is that your bios asks for things to be enabled which make sense and it enabled them
<apw> i am told that a gpe11 would trigger methods _L0B or _E0B would be called as a result of that interrupt occuring and those must be triggering the blackness ... looking at those may be fruitful as you have the bios
<ekoore> apw, yes, but where is configurated the triggering of the blackness?
<apw> ekoore, the kernel will respond to gpe11 by calling the acpi methods listed above.  what those do is bios specific
<apw> the kernel does only what it is told to by the bios on those cases (as i understand it)
<ekoore> yes, i think that is a problem of the bios, but i want solve in the kernel
<apw> ekoore, well the kernel has no feature to turn off gpes by default as far as i can tell, so you'd have to add one, or bitch at your bios vendor
<apw> acpi_hw_low_set_gpe() seems to be the low level enable routine, somewhere in the call chain for that you'd want to add something to suppress it
<ekoore> with windows os, i don't have this problem
 * sforshee -> reboot
<apw> ekoore, and i am sure the kernel there has been modified to handle the bios brokeness
<apw> ekoore, as i am sure it has a machine specific module to handle this kind of thing
<apw> ekoore, as i say there isn't obviously a way to handle it without writing some code
<apw> ekoore, apparently noone has had this issue before, or if they have they have managed to get their bios fixed
<ekoore> in with way i can have the fix of the bios?
<ekoore> is needed the source?
<ekoore> or i can disassemble it?
<apw> ekoore, normally you report your issue to them and they fix it as far as i can tell
<cking> ekoore, fixing the BIOS is not easy - you need to engage with the vendor
<ekoore> is impossible solve from linux kernel?
<apw> ekoore, no not impossible.  just you need to write some code, as it is not already there
<ekoore> yes i understand, do you can help me in this?
<apw> i don't have the time i am afraid, no
<ekoore> is possible do a comand after the loading of the kernel?
<apw> ekoore, not early enough to guarentee you cannot ever his the issue
<cking> the only easy way to get insight at this point is to see if there any _L0B, _E0B methods in the ACPI DSDT and then see what they are doing
<cking> ..but you need to understand the AML code, which is a pain
<cking> ekoore, http://smackerelofopinion.blogspot.com/2009/10/dumping-acpi-tables-using-acpidump-and.html and http://smackerelofopinion.blogspot.com/2010/03/debugging-acpi-using-acpiexec.html maybe useful
<sconklin> http://www.pat-testing.info/recallnotice/sony-vaio.htm overheating Vaios due to a "firmware" problem
<apw> tgardner, did the armel natty chroots get updated?  i am seeing 'cp15 insn xxxx' blammos from qemu
<tgardner> apw, the natty armel chroots still don't work, so I disabled them
<apw> tgardner, oh i thought we had stale ones and they sort of worked
<tgardner> apw, I should remove the one on tangerine
<tgardner> apw, I probably messed up and did an update
<tgardner> ogra mumbled something at me about using Maverick debootstrap or qemu, but I never followed up on his suggestion
<ogra> hmm ?
<tgardner> natty armel chroot
<ogra> yeah, i got that, whats your prob ?
<tgardner> it don't work
<ogra> hmm, i havent used x86 hosts for a while, they should work though
<tgardner> ogra, gimme a bit, I can produce some error messages. it generally wedges the qemu session
<ogra> k
<tgardner> ogra, https://pastebin.canonical.com/42364/
<ogra> hmm, whats the command you used there ? 
<ogra> looks like an issue with your arch, is that amd64 or x86 ?
<tgardner> qemu-debootstrap --arch=armel natty /usr3/chroots/natty-armel http://mirror.rtg.net/ubuntu-ports
<tgardner> I: Running command: debootstrap --arch armel --foreign natty /usr3/chroots/natty-armel http://mirror.rtg.net/ubuntu-ports
<ogra> i think i have seen such an error on amd64 but not on x86
<tgardner> amd64
<tgardner> ogra, who has 32 bit servers these days?
<ogra> i do ... arm doesnt have 64bits yet :)
<tgardner> ogra, well, all of my dev boxes have a zillion CPUs, so i386 doesn't make sense on them
<ogra> well, but it sounds like a bug, if you have no option to build on an x86 machine i would suggest building a maverick chroot and dist upgrade that
<tgardner> ogra, k, I'll try that
<tgardner> sconklin, how is the SRU testing going?
<sconklin> tgardner: ask cert and qa
<sconklin> I don't know, and they don't have any status pages that I'm aware of
<tgardner> sconklin, they've got this one: http://people.canonical.com/~hwcert/sru-testing/current/
<sconklin> well ok, then, there's your answer
<tgardner> sconklin, the reason I ask is that there are some non-zero numbers in the failures column and wondered if you're getting push back on some of the patches
<sconklin> tgardner: in every case in the past, those have turned out to all be false negatives, and the cert team has given them a pass.
<sconklin> But it's a good question
<tgardner> sconklin, hmm, ok
<sconklin> I wish there was more detail about the tests
<sconklin> sru_disk_buf_read_perf_adv_tes doesn't mean anything to me
<sconklin> but I suspect a result of "command not found" is not a kernel problem
<tgardner> sconklin, I suppose next you'll be wanting a link to the test source code :)
<sconklin> sru_sleep_state_test failure looks like it may actually be a failure - that one is more worrisome
<tgardner> is that an S3 test I wonder ?
<sconklin> hmm, if you drill down, at least the first one if marked "Unresolved", while the second if fail. But they both show as fails on the status page
<tgardner> ogra, no joy on dist-upgrade from maverick to natty, same basic error
<ogra> but bootstrappping natty worked ?
<ogra> err
<ogra> maverick
<tgardner> ogra, yes, maverick works
<ogra> hmpf
<apw> all ogra's fault clearly
<ogra> i didnt touch qemu since 2 releases
<ogra> its your crappy hardware, use arm cortex-a15 :P
<ogra> can also have 100s of cores and terabytes of ram
<tgardner> ogra, well, we normally cross compile, but some stuff really requires a native armel environment.
<ogra> yeah
<ogra> i really dont know what makes qemu fail there, i know that slangasek is working on a new package from a different source for exactly the armel stuff
<ogra> but i dont know where that stands
<tgardner> ogra, if I filed a bug, would it be against qemu-kvm-extras-static ?
<ogra> yes, thats what holds the binfmt handlers
<tgardner> k
<apw> tgardner, yeah like the perf packages cause we don't support cross compilation in the archive
<bjf> apw, smb, tgardner, https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs
<slangasek> ogra, tgardner: the plan is that qemu-kvm-extras-static gets taken over by a new qemu-linaro source package as a transitional package
<ekoore> apw, cking, i am here
<tgardner> slangasek, sometime soon?
<slangasek> tgardner: within the week
<tgardner> slangasek, cool. I'll watch for it
<JFo> <- lunch and an errand... I hate taxes. :-/
<tgardner> slangasek, I assume your natty qemu-kvm-extras-static will work in a debootstrap on a lucid host?
<slangasek> tgardner: I also assume this :)
<slangasek> (I don't have any evidence one way or the other at the moment, but if it doesn't work, we'll want to fix it)
<apw> slangasek, i thought those packages were installed in the host, and loaded via init.  so wouldn't you need a native <host release> package to make it work in chroots ?
<apw> via the bin_fmt_misc thingy
<slangasek> apw: well, we will be providing backported packages
<slangasek> in the linaro ppa
<apw> slangasek, that makes sense to me, cool
<apw> is it ready yet, is it ready yet
<slangasek> apw: but if you're doing interpreter resolution in a chroot, the paths are resolved relative to the chroot
<apw> slangasek, they are, oh hrm really?
<slangasek> (qemu has multiple modes for this stuff and I never remember which name is which... but if you've got an x86 chroot with a smattering of arm executables, that's all done within the chroot)
<slangasek> apw: sure, otherwise it's an instant jailbreak :)
<apw> slangasek, heh well i guess that makes sense and everything
<apw> slangasek, i think i am thinking of the armel chroot all armel inside case ... but anyhow i am sure we will work it out when they exist
 * tgardner --> lunch
<tgardner> smb, using stock 8.04.1 and http://www.howtoforge.com/ubuntu-8.04-server-install-xen-from-ubuntu-repositories I was able to boot a xen image
<tgardner> apw, root@e1501:~# cat /proc/version
<tgardner> Linux version 2.6.24-28-xen (buildd@crested) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Wed Nov 24 10:58:54 UTC 2010
<tgardner> root@e1501:~# cat /proc/version_signature 
<tgardner> Ubuntu 2.6.24-4.6-generic
<tgardner> root@e1501:~#
<tgardner> apw, root@e1501:/boot# ls -l
<tgardner> total 36140
<tgardner> -rw-r--r-- 1 root root  420224 2008-06-18 10:51 abi-2.6.24-19-server
<tgardner> -rw-r--r-- 1 root root   74169 2008-06-18 10:51 config-2.6.24-19-server
<tgardner> -rw-r--r-- 1 root root   82909 2010-11-24 04:59 config-2.6.24-28-xen
<tgardner> drwxr-xr-x 2 root root    4096 2011-01-26 11:50 grub
<tgardner> -rw-r--r-- 1 root root 7517611 2011-01-26 11:39 initrd.img-2.6.24-19-server
<tgardner> -rw-r--r-- 1 root root 7239178 2011-01-26 11:32 initrd.img-2.6.24-19-server.bak
<tgardner> -rw-r--r-- 1 root root 7468145 2011-01-26 11:50 initrd.img-2.6.24-28-xen
<tgardner> -rw-r--r-- 1 root root 7467768 2011-01-26 11:50 initrd.img-2.6.24-28-xen.bak
<tgardner> -rw-r--r-- 1 root root  103204 2007-09-28 05:03 memtest86+.bin
<tgardner> -rw-r--r-- 1 root root 1162275 2008-06-18 10:51 System.map-2.6.24-19-server
<tgardner> -rw-r--r-- 1 root root 1129165 2010-11-24 04:59 System.map-2.6.24-28-xen
<tgardner> -rw-r--r-- 1 root root 1928216 2008-06-18 10:51 vmlinuz-2.6.24-19-server
<tgardner> -rw-r--r-- 1 root root 1895911 2010-11-24 04:59 vmlinuz-2.6.24-28-xen
<tgardner> -rw-r--r-- 1 root root  401328 2009-02-20 20:04 xen-3.2.gz
<tgardner> apw, debian/config/amd64/config.generic:CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-4.6-generic"
<apw> debian/rules.d/2-binary-arch.mk:        cat $^ | sed -e 's/.*CONFIG_VERSION_SIGN
<smb> tgardner, Ok, it really was the xen-3.3 stuff I took from hardy-backports. Thrown everything away and now had no problem in booting the kernel with the updated patch and run a new domU
<tgardner> smb, otp, back in a sec
<tgardner> smb, http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/59f097ef181b
<bdmurray> JFo: wrt to this kernel bug handling work item its just reviewing the existing kernel team debugging procedures right?
<bdmurray> JFo: the one assigned to me
<JFo> hmmmm, let me look
<JFo> I believe it was more to do with getting the qa team looking there for some reason, but I don't recall precisely
<JFo> or perhaps there was some documentation that was needed
<JFo> I can't recall
<JFo> let me see if I can find my notes
<bdmurray> What I recall is you all wanted somebody outside the kernel team to review the rewritten debugging procedures and I believe Kamal mentioned grub and boot options.
<JFo> ah, that tickles a memory
<kamal> bdmurray, JFo:  um...  I recently added this to the kernel team FAQ:  https://wiki.ubuntu.com/Kernel/FAQ#How do I add a Kernel Boot Parameter?
<kamal> make that:  https://wiki.ubuntu.com/Kernel/KernelBootParameters
<JFo> very nice kamal 
<kamal> (if that's even relevant to your conversation :-)
<JFo> :)
<bdmurray> so its stuff like that I / my team is supposed to review
<JFo> bdmurray, your recollection works for me as I seem to have relocated my notebook (tax season)
<kamal> bdmurray: I should have told somebody (you) about it I guess!  ooops.
<bdmurray> JFo: okay, I'll clarify the work item so its more definitive
<JFo> thank you sir
<soren> How do I see what a given file looked like at a given revision with git?
<RAOF> I *think* git show $SHA:path/to/file works
#ubuntu-kernel 2011-01-27
<apw> soren, if its not that then git cat-file -p  $SHA:path/to/file
<ricotz> apw, hello :), do you know if there is a package of Ubuntu-lts-2.6.35-25.44 for lucid already available?
<apw> ricotz, it does not appear so yet, it seems that kernel is lagging, with a previous version not yet promoted to -updates
<smb> The archive seems ok, but I guess nobody uploaded
<smb> I mean git
<apw> smb, yep, i know the previous one only just got promoted yesterday, and a newone uploaded, but it seems to be behind still
<ricotz> ok, thanks, so it will be available soon
<apw> i suspect the stable team has not gotten it in their process, and tim is still doing them when he has time
<smb> apw, lilely. as the repo is up to date. I guess we should/could just upload the latest version
<ricotz> smb, this would be nice
<ohsix> where can i get a hand with the information i've gathered trying to troubleshoot suspend problems
<ohsix> is there like a go-to guy or is it jus down to filing a bug
<apw> smb, yeah in general i think we can do that, but i suspect its better to get the stable peeps to do it, to make sure they are remembering
<apw> ohsix, its always worth getting all of it attached to a bug, file one with ubuntu-bug linux as that gets the machine info
<smb> apw, Yeah, probably
<smb> ricotz, That would be a few more hours 
<apw> smb, i wonder if the mainline builder should be at least shoving the latest tags into the kernel-ppa ppa
<apw> as i keep forgetting to do natty as well
<smb> For Natty surely. Maverick, maybe. Though probably it just should be on the list of steps when uploading a Maverick to proposed
<smb> apw, Are you still doing the mainlines on zinc?
<apw> smb, yep ...
<smb> poor machine. :)
<apw> smb, i am thinking both, that it should be something on the checklist for maverick, but also whether we could get the things uploaded
<apw> well it doesn't have to do so much for a PPA upload, just make the source deb and upload it
<ricotz> smb, alright
<apw> smb, i suspect if that mav kernel contains security then it should be expedited into lucid anyhow
<smb> apw, It might be something slightly less often. Ie only if there is a new closing tag
<apw> right
<smb> I guess as the process seems mostly automatic anyway, maybe the upload could go directly to the proposed staging ppa instead of kernel-ppa
<smb> Then there is one thing less to think about in the normal case for the stable team
<apw> smb, perhaps so, it is tricky to know if the automated build will work
<apw> but as yet it has not failed for me
<smb> apw, We should brig that up. Maybe there is a wiki page about that already, of which nobody has heard. :-P
<apw> heheh probabally
<ohsix> hrm i have the symptoms on this bug running the natty kernel https://bugs.launchpad.net/ubuntu/+source/linux/+bug/592780 going to try some of the stuff they said worked
<ubot2> Launchpad bug 592780 in linux "[Lucid] kernel suspend + resume works only once, 2nd timesystem freezes" [Undecided,Fix released]
<ohsix> it's probably my card reader; is there anything more finegrained than usbcore.autosuspend? like; do the separate drivers have knobs for it
<apw> ohsix, what system is affected
<ohsix> you mean model number? compaq cq60
<apw> ohsix, from the bug it seems worth checking out that usbcore.autosuspend thing
<ohsix> yea
<ohsix> i'm having a problem with the mav kernel too; it'll suspend but not wake up, it starts with some hd activity but doesn't get anywhere
<ohsix> yea, no dice on the usb thing
<ohsix> i gathered this earlier with netconsole http://paste.ubuntu.com/558898/
<ohsix> it's the successful suspend followed by the failure; and it consistently says its stopping the disk the second try
<ohsix> hrm, the pm_trace thing on the failed sleep always turns up in drivers/base/power/main.c:605
<apw> ohsix, that disk line being different is plain odd
<apw> ohsix, you definatly have a different cause to your issue than them then, i would recommend a new bug
<apw> and add that pastebin to it
<apw> ohsix, which kernel?  lucid ?
<ohsix> the natty kernel, 2.6.37-12 or something
<apw> ohsix, well that line is a resume line
<apw> ohsix, what is the whole of the magic line in the next boot ?
<ohsix> ya i looked at it already; too bad it doesn't say which device it's resuming
<apw> ohsix, can you paste the MAGIC line you got that from ?
<ohsix> do you mean the magic number? there are no further or more specific matches, the numbers are 0:900:740
<ohsix> hm, i assued the tracepoints were automatic, reading s2ram.txt says i might have to add some
<ohsix> 3rd number in the magic is supposed to be the device? dunno how to look it up if it could'nt look it up already
<ohsix> out of time for this today, i'll be back later
<ohsix> if you find any information i should digest when i pick it back up, msg me, bye :]
<rocky2> Hey can anyone help me with kernel debugging... using kgdb?
 * apw doesn't recall every using kgdb
<apw> but ask your question, someone might know
<apw> ohsix, get that bug filed, i suspect some more debugging needs enabling in suspend/resume as it appears that the machine started resuming which implies a failed suspend
<apw> rocky2, but ask your question, someone might know
<rocky2> Question is... the test kernel not waiting with kgdbwait parameter in grub. What could be the problem...
<stefanlsd> apw: just to let you know i'll test your kernels for bug #552311   - needed it for a while for kvm passthru
<ubot2> Launchpad bug 552311 in linux "CONFIG_DMAR is not set " [Medium,Incomplete] https://launchpad.net/bugs/552311
<apw_> sl
<apw_> stefanlsd i had about given up on getting testing for that one ... missed tgis upload either way
<stefanlsd> apw_: yeah, sorry. was subscribed to the other bug about it. will still do
<apw_> remin me of the big number would you
<stefanlsd> apw_: bug #639712
<ubot2> Launchpad bug 639712 in qemu-kvm "PCI Pass Through via libvirt cannot remap IRQ's" [Medium,Triaged] https://launchpad.net/bugs/639712
<noodles775> Hi! I want to trouble-shoot resume from suspend which broke recently on my maverick box... is http://ubuntuforums.org/showthread.php?t=1228332 the best place to start?
<tgardner> smb, tangerine:/home/rtg/kern/hardy/kern-64/ubuntu-hardy/debian/build/custom-source-xen
<smb> tgardner, So I think my and your version are functionally the same. The only difference is that I tried to make it look the same as the mercurial latest code
<tgardner> apw, https://kernel-tools.canonical.com/srus.html
<apw> cking, https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed/+packages
<apw> sconklin, hey
<sconklin> apw: hi
<apw> mumble ?
<apw> sconklin, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/705845
<ubot2> Launchpad bug 705845 in linux "Suspend on Thinkpad X200s worked in 2.6.35-24-generic but no longer in 2.6.35-25-generic" [High,New]
<apw> http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
<JFo> \o/
<JFo> :)
<apw> JFo, i think we need to include all of the regression-potential bugs on the kernel-key list
<apw> possibly regression-updates, but i suspect not yet as i suspect we are going to drown
<JFo> regression-potential has been deprecated, do you mean regression[proposed?
<JFo> err regression-proposed that is
<apw> i do indeed proposed
<JFo> ok
<apw> mean proposed yes
<JFo> I can definitely do that
 * JFo makes some minor tweaks
<JFo> I expect I shall have that up today (in the next little bit) so we can see those and the kernel-key ones as well
<apw> JFo, mumble ?
<JFo> one sec... was listening to some music :)
<apw> JFo, i think we need to get someone to run through all of the bugs on the key that are New and get them Triaged, and a priority assigned
<JFo> yep, I am looking at that now
<JFo> apw, want me to do that?
<apw> if you have time, that'd be great
<apw> these need special handling as we need to know wherre they worked previously and testing with the latest proposed/updates rather than necessarily upstream testing
<apw> that the current arsenal would request
<apw> we might want to special case t
<apw> the ones with regression-xxx on them in what we ask for 
<apw> sconklin, bjf, the key kernel bug list now has all the regression-proposed bug enumerated on it
<apw> JFo, i also wonder if we need to target them to the release they are reported on
<JFo> I was thinking that too
<JFo> I think it is a good idea
<JFo> hmmm
<JFo> looks like the only problem with that is that it doesn't show up in the overall list
<apw> as in if the natty task is gone then they are gone ?
<JFo> I see one that has a Natty task, but the buglist just shows it with everything else
<JFo> no, what I mean is, we are only able, currently, to show what they are milestoned for
<JFo> the script isn't giving us the release they are tasked for
<apw> JFo, hrm
<JFo> yeah
<JFo> I hadn't really noticed that before
<apw> JFo, yeah it is, thats the nomnation column, its separate from the milestone col ?
<JFo> hmmm
<JFo> yep, you are right
<JFo> I guess it is just broken for natty
 * JFo thinks that should  be a relatively simple fix
<JFo> ok, I have added all that should be needed
<JFo> let me do some testing to make sure I didn't break something
<JFo> and I'll get this change committed and pushed
<manjo> sforshee, git clone git://kernel.ubuntu.com/ubuntu/kteam-tools.git
<manjo> sforshee, https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting
<bjf> JFo, on this "key kernel buglist" page, i'd like to see a key which explains what the "comments" mean, for example, do I care about "cert team blocker"? "cert team pcert" ?
<JFo> those are just an enumeration of what tag we pulled those from
<JFo> I think we care, to varying degrees, about all of them :)
<JFo> but I do see what you mean bjf
<JFo> let me see what I can do
<JFo> I should be able to add some sort of legend to the page
<bjf> JFo, and "regression-proposed" is printed twice in the comments
<JFo> yeah, I've fixed that already
<JFo> thanks for pointing it out though
<bjf> JFo, i'd suggest dropping the image link at the top left of the page since it's broken and just takes up space
<JFo> huh, I hadn't noticed that.
<JFo> thanks
<JFo> huh, that is a launchpad librarian icon
<bjf> JFo, i'll wager that with the new corporate style, there is a different logo link
<JFo> I was just thinking that
<JFo> wonder where it is... ah well, I'll get it later
<bjf> JFo, don't think we really need it, just taking up useful space
<JFo> yeah, was just prettification
<maks_> just saw the 2.6.32.28.13
<maks_> there are some drm patches we fwd from 2.6.35, that you'd could also be interested
<maks_> in total they were eleven
<tgardner> smb, ^^
<maks_> smb: they are found in Debian 2.6.32-30.
<maks_> 2.6.35 longterm support forward ported them mostly fine.
<maks_> they are not all in bwh's git mirror, as it seem out of sync
<maks_> :/
<JFo> hiya skaet :)
<JFo> let me know if you have any new bugs for me.
<JFo> :-)
<smb> maks_, Hi, if there are drm patches for the combined tree, feel free to send them to our kernel-team mailing list. Unfortunately stable is so busy by now that one easyily overlookes things
<maks_> smb: asked bwh to sync git mirror
<cr3> hi folks, what might this mean in the udevadm output for a serial input device: E: PRODUCT=11/2/8/7321
<smb> maks_, Yup saw it. 
<maks_> afterwards I can send a combined mail with the sha1sum
<maks_> but really no time to fwd them each
<smb> maks_, I sked him to ping me when I can look. :)
<maks_> ok cool.
<smb> cr3, what udevadmn command? Did it fail? Otherwise it means that the environment variable PRODUCT has this value. :-P
<cr3> smb: udevadm info --export-db, nothing failed, just wondering what those numbers assigned to the PRODUCT environment variable mean: 11/2/8/7321
<smb> could be bus numbers as well as vendor product subvendor subproduct... Need to look at one example here
<cr3> smb: when comparing against lshal output, it seems that the "2" might mean hotplug_type, but nothing seems obvious about the other numbers
<apw> smb, a bit short for vendor etc arn't they
<cr3> smb: if it were vendor product subvendor subproduct, I wonder against which table those values can be looked up. since this is a serial input device, I don't think it maps to pci.ids, usb.ids and probably not pnp either
<smb> apw, Though it seems that they are
<smb> just shortened
<apw> shortened, as in 0011/0002
<smb> P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5
<smb> E: PRODUCT=19/0/6/0
<smb> E: MODALIAS=input:b0019v0000p0006e0000-e0,1,kE0,E1,E3,F0,F1,F2,F3,F4,F5,ramlsfw
<JFo> k, apw natty shows up in the nominations now
<JFo> and there are currently 86 bugs :-/
<JFo> I'm going through the new ones now
<smb> nSo we have <bus>/<vendor id>/<product id>/<version>
<cr3> smb: hm, where can those identifiers be looked up?
<apw> cr3 ... looking
<tgardner> bjf, can you review 'Karmic/Hardy SRU: thinkpad-acpi: lock down video output state access, CVE-2010-3448' ?
<ubot2> tgardner: drivers/platform/x86/thinkpad_acpi.c in the Linux kernel before 2.6.34 on ThinkPad devices, when the X.Org X server is used, does not properly restrict access to the video output control state, which allows local users to cause a denial of service (system hang) via a (1) read or (2) write operation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3448)
<cr3> apw: I looked at http://www-pc.uni-regensburg.de/hardware/TECHNIK/PCI_PNP/pnpid.txt, can't seem to map that to smb's output above
<apw> cr3, i think they are mostly fake
<cr3> apw: wild goose chase.. I prefer chasing sheep
<JFo> sforshee, don't forget to change status on your bugs so they reflect the latest. :)
<apw> cr3 ok think i have them
<apw> P: /devices/platform/i8042/serio1/input/input9
<apw> E: MODALIAS=input:b0011v0002p0008e0000-e0,1,2,k110,111,112,r0,1,amlsfw
<apw> #define BUS_I8042               0x11
<apw> so that mouse is on 'b0011' bus ID 11, which is BUS_I8042
<apw> include/linux/input.h
<cr3> apw: ok, so at least the <bus> part doesn't seem to be fake
<apw> 'fake' in the sense its an internal to the kernel numbering thingy
<apw>         input_dev->id.bustype = BUS_I8042;
<apw>         input_dev->id.vendor = 0x0002;
<apw>         input_dev->id.product = psmouse->type;
<apw>         input_dev->id.version = psmouse->model;
<apw> so for a mouse it does that ...
<apw> clearly 0x2 has no name
<bjf> tgardner, looking
<apw> but it is possible all mice are 2 there
<sforshee> JFo, trying to, but sometimes I forget, or maybe don't know that they require an update
<sforshee> any in particular you're referring to?
<apw>         dev2->name = "PS/2 Touchpad";
<apw>         dev2->id.bustype = BUS_I8042;
<apw>         dev2->id.vendor  = 0x0002;
<apw>         dev2->id.product = PSMOUSE_LIFEBOOK;
<apw>         dev2->id.version = 0x0000;
<JFo> sforshee, heh, no problem
<apw> cr3 that for a touchpad
<JFo> sforshee, when you ask for information, you can mark the bug incomplete
<JFo> and when you take actively working the issue, you can set it to In Progress, incomplete, etc.
<JFo> it is just so I can tell what the current state is
<sforshee> JFo, yeah, I know I've forgotten that a couple of times, I'll try to remember
<JFo> and if something has been incomplete for a while it gets automatically expired after a time
<JFo> sforshee, it isn't a big deal :)
<JFo> just wanted to remind
<cr3> apw: except for smb, he seems to have a vendor of 0
<apw> cr3, his i think was not a mouse
<cr3> apw: and I think to have version 7321, which seems like a heck of a high version
<smb> The random pick I made seems to be my acpi graphics device
<apw>         input->name = acpi_device_name(video->device);
<apw>         input->phys = video->phys;
<apw>         input->id.bustype = BUS_HOST;
<apw>         input->id.product = 0x06;
<apw> cr3, so i think his is his video card
<apw> you might find the other things more useful than the alias though
<smb> yep so  guessed
<apw> E: MODALIAS=input:b0019v0000p0006e0000-e0,1,kE0,E1,E3,F1,F2,F3,F4,F5,ramlsfw
<apw> P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input12
<apw> for example that is my video card
<apw> cr3 perhaps we might turn this round and ask what you are trying to work out
<jjohansen> rebooting
<apw> E: PRODUCT=11/2/8/7321
<apw> E: NAME="AlpsPS/2 ALPS GlidePoint"
<apw> from my dell
<cr3> apw: trying to accurately detect touchpad devices. I'm in the process of referring to capabilities/key under the input device in sysfs but, in doing so, I noticed the PRODUCT variable which I thought might provide additional information of interest.
<JFo> <- lunch
<tgardner> jjohansen, since you're somewhat xen qualified, please have a look at the Hardy xen SRU request on the k-t list.
<jjohansen> tgardner: hehe, yeah already looking at it
<tgardner> cool. thanks
<apw> JFo, we seem to have lost some closed bugs ... did we look at getting the tag searcher to keep closed bugs too ?
<JFo> apw, hmmm that may have been from me removing the ones that were in the manual list
<apw> JFo, i think that search for tags i gave you is selecting open only, and prolly a one liner to fix that
<JFo> yeah, I think that is possible
<apw> JFo, what was it called anyhow? i seem to have lost it
<JFo> I have it on my todo
<JFo> list-tag.py
<JFo> it is stored in the canonical-qa-tracking bzr branch
<JFo> apw, do you also want to see Invalid and Won't Fix?
<apw> JFo, i'd say so to start with, as those are dispositions of a sort
<JFo> ok
<apw> i suspect we need to work out how to make them dissappear like a month after they go closed
<apw> but we can work on that separate
<bdmurray> bug 708690 looks important
<ubot2> Launchpad bug 708690 in linux "Kernel 2.6.35-25-generic boots into command prompt rather than GUI" [High,New] https://launchpad.net/bugs/708690
<apw> bdmurray, nvidia binary drivers i suspect
<kees> sconklin, bjf: so, another kernel with security fixes landed in -updates without any notification to the security team. :(
<kees> (lucid)
<kees> where are maverick, karmic, and hardy? or is there no plans to do lock-step updates?
<apw> maverick was promoted this morning i think
<tgardner> kees, isn't this an archive admin issue? they are the ones doing the pocket copies. Or do you need to do the copy to -security as well?
<kees> tgardner: we have to copy to -security, publish USNs, possibly do ABI-tracked bumps, etc.
<kees> tgardner: this is the second time there has been no notification to the security team about kernels with CVE fixes :( where is this process dropping the ball? is the security team supposed to be watching something, the kernel team pinging us, or the archive admins pinging us?
<tgardner> kees, well, until we work through the backlog of CVEs, this is likely to happen with every promotion to -proposed, so we'd better figure out how to coordinate.
<tgardner> kees, how would you like to be notified?
<kees> tgardner: in a perfect world, all kernels for all releases would promote at the same time. is that possible?
<kees> tgardner: I'd like to know the day before it's planned to go out. if there is a fixed schedule, that works too.
<tgardner> kees, well, its up to the AA ding the pocket copying.
<tgardner> doing*
<kees> so it's not like "on the 2nd thursday of the cadence, kernels are published"?
<apw> bdmurray, yeah this guy says "I am using the most recent Nvidia graphics driver, obtained directly from Nvidia" so I assume he needs to know what the heck he is doing
<tgardner> kees, well, I think sconklin _does_ request pitti to do the copy, but it doesn't always happen like clockwork.
<sconklin> kees: no, releases are not and can't be synchronized
<kees> sconklin: okay, we'll find a way to adjust our USN practices.
<sconklin> even beyond that, with the new process, there's no guarantee that the same CVE gets applied to all kernels at the same time
<kees> sconklin: what I'd really like is for USNs to be timed to pocket copies, but that requires advanced notice of the pocket copying
<sconklin> also, in most cases, the pocket copies are done when cert is done or there's enough time in -proposed. we don't ask for it
<kees> okay, so it sounds like this notification does not need to be in the hands of the kernel team.
<kees> now, I'd like USNs to be proactive instead of reactive, so that needs to be coordinated with the pocket copying.
<bdmurray> apw: okay, thanks
<kees> who has traditionally done the copying? is it any archive admin, or is someone dedicated to the kernel cadence?
<tgardner> kees, I think its only pitti to date
<kees> okay, I will go pester him, thanks!
<kees> tgardner: what's the eta on hardy and dapper?
<tgardner> kees, I just pushed a xen commit for Hardy, CVE-2010-3699
<ubot2> tgardner: The backend driver in Xen 3.x allows guest OS users to cause a denial of service via a kernel thread leak, which prevents the device and guest OS from being shut down or create a zombie domain, causes a hang in zenwatch, or prevents unspecified xm commands from working properly, related to (1) netback, (2) blkback, or (3) blktap. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3699)
<kees> cool
<tgardner> kees, there is also one pending for dapper
<sbeattie> tgardner: same one or something different?
<kees> tgardner: right, but I mean, hardy and dapper weren't published in the last cadence cycle.
<tgardner> kees, not sure when sconklin et all will wrap those up in a bow
<tgardner> sbeattie, something different, CVE-2010-4078
<ubot2> tgardner: The sisfb_ioctl function in drivers/video/sis/sis_main.c in the Linux kernel before 2.6.36-rc6 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via an FBIOGET_VBLANK ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4078)
<tgardner> kees, since dapper/hardy aren't really part of the 2 week cadence, we can likely coordinate them better.
<kees> sconklin: in the future, can you merge unpublished changelogs (and just bump the version forward) to avoid things like Lucid's current changelog?
<sconklin> hardy, karmic, and dapper are sitting in proposed, waiting to be published. We don't really decide when. Usually at the point we are ready to put new ones in -proposed, we'll remind pitti that they are there
<kees> tgardner: why are the LTSes not part of the cadence?
<kees> so it sounds like pitti needs to be on this too?
<tgardner> kees, no test capacity with cert and qa
<sconklin> the cadence is interlocked with cert and QA, and they only test lucid and Maverick
 * kees starts crying
<jdstrand> whoa, seriously?
<sconklin> it's been coincidence so far that the pther match up, and we'd like to keep it that way, but it probably won't happen
<jdstrand> so security patches could conceivably go out without testing?
<tgardner> jdstrand, as they always have...
<tgardner> kees did the only testing
<sconklin> I love it when people first clue in to that . . .
<jdstrand> tgardner: well, they are going through -proposed now, and then pushed without the security team's knowledge
<kees> kernel team did boot testing, and I did regression testing. that's not "untested"
<jdstrand> tgardner: in the past, someone either from the kernel team or the security team would test
<sconklin> yeah, that's one of the major drivers for putting security fixes into the normal patch handling process
<tgardner> jdstrand, not always. we've had some regressions.
<jdstrand> kees: ok, I was under the impression that you were not aware of those kernels
<kees> jdstrand: "those"?
<jdstrand> 12:40 < kees> kernel team did boot testing, and I did regression testing.  that's not "untested"
<kees> I meant "In the past, kernel team did boot testing, and I did regression testing. that's not "untested""
<kees> not with these
<jdstrand> ah
<kees> with the "new process", QA does the boot and regression testing
<jdstrand> right, except not for anything before lucid
<kees> but now I'm told there is no QA team for anything other than stable and LTS
<kees> (er, most recent stable...)
<jdstrand> but the kernels are stilling using the same -proposed process
<jdstrand> which means they could miss at least our team's regression testing
<sconklin> kees: I think that cert and qa have been testing other releases as they can, but I don't think there's any guarantee
<kees> I just don't know any other way to say this: we need CVEs fixed in all the releases. this happened in the past, and it needs to keep happening, regardless of the process. I don't much care what the process is.
<jdstrand> if there isn't coordination, which there has been a problem with lately
<kees> if QA is doing the testing, and using qrt (which they say they are), I'm happy with that.
<jdstrand> kees: that assumes that the CVE fix/regression tests get run, which we have to know about them to write them and they have to be public
<kees> jdstrand: right, this whole process is only for public CVEs, and we write the test cases as we can.
<jdstrand> kees: which sorta implies we need to write the tests as soon as we see a CVE (if possible), and the 1 day alert that you mentioned
<kees> very few of the CVEs end up with viable test cases
<jdstrand> I'm also a little concerned about the comment about a CVE might be fixed in maverick, but not lucid
<jdstrand> that ec2 CVE is a prime example of why that can be a problem
<jdstrand> (rather the CVE for linux-ec2)
<tgardner> jdstrand, we attempt to fix the vulnerability in all the applicable kernels
<tgardner> that we support
<jdstrand> it seems all of this will a) get better with more coordination b) become a lot easier once the CVE backlog is caught up
<tgardner> jdstrand, yeah, we've still got 30 or more left
<kees> I'm worries that the older stable releases are not part of the cadence. I think that needs to be fixed first.
<jdstrand> so, as long as we are striving to work together (along with the pocket copying AA), things will improve 
<kees> s/ies/ied/
<kees> but it sounds like that's primarily a QA time issue?
<jdstrand> kees: it sounds like the kernel team is patching them
<jdstrand> kees: if they have only security fixes, the kernel team can upload those fixes to their ppa at the same time
<kees> steps are triage (security), patching(kernel+security), building(kernel), testing(qa), publishing(archiveadmin+security).
<jdstrand> kees: as the others. then just mention it to QA to test. if they can't, we can do qrt and publish through -security
 * tgardner --> lunch date
<komputes> JFo: Could you please have a look at this bug. Seems like an ACPI issue which causes the laptop to be seen as a desktop: https://bugs.launchpad.net/bugs/701561
<ubot2> Launchpad bug 701561 in indicator-applet "IBM ThinkPad X31 not seen as laptop - battery status not available" [Undecided,New]
 * JFo looks
<komputes> JFo: do we have an ACPI expert?
<apw> define seen as a desktop ... just no battery you mean?
<apw> i know of no 'desktop/laptop' differentiator in acpi
<komputes> apw: yes, plus laptop-detect report no indication that it is a laptop
<kamal> dmidecode provides a "Chassis Type" which indicates desktop vs laptop ...
<komputes> apw: oh ok, I must have been mistaking. Anyhow the applet always shows a thunderbolt (no battery/battery+AC icon)
<apw> kamal, so there is
<apw> and thats what the latop thing uses first
<kamal> I've seen a laptop that had that set wrong in some BIOS table, which led to various problems relating to lid/battery ...
<apw>         dmitype=$(dmidecode --string chassis-type)
<apw> what does that say on it komputes 
<JFo> huh
<JFo> komputes, also, it would be really helpful to get the apport-collected data here
<vanhoof> vanhoof@downer:~$ sudo dmidecode --string chassis-type
<vanhoof> Lunch Box
<vanhoof> lulz
<apw> komputes, could we get sh -x /usr/sbin/laptop-detect
<apw> vanhoof, is that the machine or something else?
<JFo> vanhoof, :)
<JFo> mine says Notebook
<apw> Portable
<apw> for mine, but thats ok too
<vanhoof> that was run on a mac mini
<vanhoof> Lunch Box ...
<kamal> komputes: just the output from this would be good:  sudo dmidecode --string chassis-type
<JFo> huh, for my desktop it says Unknown
<apw> komputes, oh and remember to tun laptop-detect with sudo
<apw> vanhoof, as in "out to `sudo dmidecode --string chassis-type`"
<vanhoof> apw: yup
<komputes> How does one find out the driver being used by a USB network card - I would like to add an entry to https://help.ubuntu.com/community/HardwareSupportComponentsWirelessNetworkCardsBelkin#USB
<komputes> apw: i will and let you know if the result is different
<apw> komputes, does lsusb -vv tell you ?  can't remember
<komputes> apw: idProduct and idVendor and a lot of verb info but no module. I never understood why lsusb doesn't have a -k feature for kernel module (like lspci)
 * jjohansen -> lunch
 * tgardner notes that the dapper build does not parallelize correctly
<kees> oops, I broke cpu hotplug
<apw> kees, tsk, let me guess ... nx
<kees> apw: well, related to that, but actually my ignore-the-bios-filter-for-nx code. https://lkml.org/lkml/2011/1/27/345
<apw> kees, bad kees
<kees> apw: whee
<apw> kees, could you email me any resolution as i will be pushing the A2 kernels very early next week at the latest
<apw> and i want to make sure that is in
<kees> apw: yeah, for sure. I'm under an OOo update at the moment, but if someone else doesn't confirm my fix, I'll try it.
<apw> ok
<jjohansen> back on later
#ubuntu-kernel 2011-01-28
 * virtuald wonders what systems hotplug cpus
<apw> virtuald, bigger ones :)
<virtuald> no shit :p
<RAOF> And laptop users who want to actually turn off a core.
<apw> but i think the hotplug also includes turning off cores to save .... what raof said
<virtuald> :>
<elmo> and people who want to be able to replace broken CPUs on the fly
<apw> elmo, that one was a given :)
<virtuald> don't we all want that :)
<diwic> apw, it seems linux has been updated to 2.6.38, but linux-meta is still at 2.6.37. Is this intentional?
<pscoe2> hi
<pscoe2> I am facing some problems with my ubuntu server
<pscoe2> some processes..on closing dont die.. but rather they stay alice with futex_wait_queue_me in their stack
<pscoe2> alive
<pscoe2> anyone has any idea about futex_wait_queue_me?
<apw> pscoe2, futexes are interprocess locks in userspace
<smb> pscoe2, Not immediately. But its even unclear what release you are talking of
<apw> pscoe2, what release you running, what processes are they, etc
<pscoe2> i am running 10.04
<pscoe2> LTS
<pscoe2> and the process is apache
<pscoe2> i can provide the stack if you need it
<apw> i would suggest filing a bug against apache, and get the stack trace in there so people can see it
<pscoe2> http://pastebin.com/T1qmS9Xv is the stack trace
<apw> pscoe2, that simply looks like a normal interprocess wait ... from the stack trace
<apw> from the info we have i am inclined to say its more likely a userspace problem than a kernel issue
<apw> so i would file a bug on apache, unless you have some specific reason to say its a kernel issue
<apw> pscoe2, is that the whole trace or is there more of that?
<pscoe2> but this process has been in state from 1296205546 seconds
<pscoe2> it is the data in the /proc/<pid>/stack file
<apw> pscoe2, a futex is userspace locking support, so if the other end of the lock is not exiting either it won't complete
<pscoe2> also i looked up on google about processes hanging on futex_wait_queue_me and found that there is a bug in ubuntu kernel which might lead to this
<apw> pscoe2, do you have a pointer to this information 
<pscoe2> http://www.uluga.ubuntuforums.org/showthread.php?t=1517043
<pscoe2> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/480497
<ubot2> Launchpad bug 480497 in linux "Various applications freeze on exit." [Undecided,Confirmed]
<apw> pscoe2, nothing in the kernel bug 480497 actually shows any kernel issue.  the processes are stuck on a futex waiting but they can be killed ... which implies futex misshandling
<ubot2> Launchpad bug 480497 in linux "Various applications freeze on exit." [Undecided,Confirmed] https://launchpad.net/bugs/480497
<apw> which wouldn't be a kernel issue unless you cannot get rid of the process 
<pscoe2> hmm..so if i can successfully do a kill -9 on the process it is not a kernel issue?
<apw> pscoe2, if the process dies when killed then its likely the kernel is doing what is intended yes.  there may be a bug but its as likley a futex producer consumer issue in userspace 
<pscoe2> hmm..
<apw> the kernel bug there is just a dog pile of issues with any app which might use pulseaudio ... so i am inclined to think its a bug with that for most of the games people
<apw> pscoe2, without knowing how apache is trying to use its futexs it is hard to know whats happening
<pscoe2> the issue i am facing has nothing to do with games though :)
<pscoe2> ok
<pscoe2> i do have another problem which i am facing on my personal laptop
<apw> so i would normally recommend starting at the consumer of the futex and see if they can tell us what they wanted to happen as against what did happen
<pscoe2> ok
<pscoe2> from time to time a process kslowd used to pop up eating most of my cpu power
<pscoe2> i read a lot about this problem only to find t has something to do with the mouse driver
<pscoe2> i am running ubuntu 10.10
<apw> yep i have seen that with grphics polling as well
<apw> is it still happening?
<apw> u t
<apw> u
<pscoe2> ya
<apw> i think the ones we knew about have been fixed nw
<apw> then that needs a kernel bug filed
<pscoe2> i upgraded my kernel to the newest version
<pscoe2> now a different process kworker eats up the cpu
<pscoe2> causing the same problem
<apw> pscoe2, that is the same process in essence, just its name has changed
<pscoe2> i am forced to use windows to keep my work going
<apw> heh nice for you
<pscoe2> i dont like windows though
<pscoe2> so anything i can do momentarily to ease the discomfort
<pscoe2> i do a renice on the process and decrease its priority
<pscoe2> that eases it up for a bit but is not a solution
<apw> we need a bug filed on the exact version you are seeing it: filed with ubuntu-bug linux
<apw> i am not sure those processes will respond well to being reniced
<pscoe2> everything hangs anyways
<pscoe2> i will file the bug..
<pscoe2> Thanks
<apw> pscoe2, there used to be kslowd debugging available, i don't know about kworker
<pscoe2> hmm..
<pscoe2> i guess i will boot in with the older kernel and try debugging kslowd
<diwic> apw, it seems linux has been updated to 2.6.38, but linux-meta is still at 2.6.37. Is this intentional?
<apw> diwic, yes ... we have issues booting it on arm
<diwic> apw, ok
<ohsix> apw: #709128
<apw> bug #709128
<ubot2> Launchpad bug 709128 in linux "suspendand resumes only works once, freezes on second suspend" [Undecided,New] https://launchpad.net/bugs/709128
<ohsix> hrm @ typo's and extra s's, must be tired
<apw_> cking: did he win yet ?
<kaushal> hi
<kaushal> I get CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO % at the bottom while running iotop
<kaushal> on 8.04
<kaushal> Please suggest/guide
<kaushal> what does it mean
<apw_> kaushal: 8.04 ... someone remind me which that is
<kaushal> I see this host has high IO
<kaushal> high IOwait
<smb> apw_, Hardy
<apw_> that option was not enabled in older kernels, as it was experimental and thought to cause performance regressions i believe
<kaushal> is there a way to look for reason why there was high IO ?
<apw_> smb: ahh, i doubt we are going to retroactivly enable anything back there for the general population
 * apw_ tried to remeber if blocktrace works on hardy
 * apw_ wished we at least called it 8.hardy.04 :)
<apw_> smb: can you remember if blktrace is that old ?
<smb> apw_, Not really wihtout more compelling reason and no I do not know either from the top of my head
<apw_> kaushal: worth trying blktrace, that might give you the hints you want
<apw_> (if it existed back in hardy days)
<kaushal> ok
<apw_> otherwise you might be forced to build a kernel with that enabled, not sure
<kaushal> ok
<kaushal> apw_: what does blktrace do
<kaushal> is there a way to know why there was high IO ?
<kaushal> At the moment there is no IO
<apw_> blktrace records the IO that is occuring, so you can review it to see where etc it is going, can help determine if it is swap etc
<apw_> only of use when the problem is occuring of course
<kaushal> so old history is lost ?
<kaushal> I dont see anything in syslog,dmesg
<kaushal> apw_: please suggest
<apw_> kaushal: nope i don't know of any persistant information of that nature which is kept, it would be simply too big
<kaushal> apw_: Thanks
<kaushal> apw_: any example to use blktrace
<kaushal> I mean some form of monitoring it 
<apw_> kaushal: there muct be some examples in the man, but not something i've used extensivly
<cking> apw, no idea
<apw> cking, he did in the end
<cking> rats, I missed that - got distracted
<JFo> sconklin, when you get a moment, I am looking over the arsenal scripts now. What tags do you want me to omit from my processing? I've found the place to add them
<JFo> :-)
<sconklin> JFo: hold on while I collect those tags for you
<JFo> k, thanks
<sconklin> JFo: anything with "kernel-tracking-bug" should not be spammed
<JFo> ok
<bjf> JFo, also anything tagged "kernel-release-tracker"
<JFo> k
<JFo> is it ever possible for one of the revert or reapply bugs to be brand new ever?
<JFo> wondering if they should be on there
<apw> JFo, is this the 'test upstream version' script ?
<apw> JFo, and did you get any joy from the launchpad dude ?
<JFo> still haven't heard from him
<JFo> yes, this is the one that asks for upstream testing
<JFo> apw ^
<JFo> hmmmm, there is still a cking lurking about :-)
<apw> JFo, we might want to modify waht it suggests for regression-*
 * JFo points apw at cking 
<JFo> apw, it looks like it is supposed to be ignoring them
<cking> hey, I'm just flushing my buffers for the week
<JFo> I am working to find out what it is actually doing
<JFo> cking, sure you are ;)
 * apw imagines cking on the crapper
<JFo> heh
<cking> that's not a pleasant visual image
<apw> cking, you are not meant to be able to see it by now
<smoser> smb, bug 708920, they've only seen it on the older lucid for sure.
<ubot2> Launchpad bug 708920 in linux-ec2 "Strange 'fork/clone' blocking behavior under high cpu usage on EC2" [Undecided,New] https://launchpad.net/bugs/708920
<smoser> but apparently it has to run a while to see it.
<sforshee> cnd, you know much about the ntrig synthesizers?
<smb> smoser, Yes, saw that somewhere in either mail or bug report. Still we should get confirmation about the newer image before spending time there and to find out we had been chasing a ghost.
<smoser> yeah. i'd agree.
<smoser> do you have an instance up ?
<smoser> maybe run some benchamrks, leave it up for a while.
<smoser> try to recreate on your newer instance..
<smb> smoser, I got one running at the moment. Though without anything running. I'll get same "noise" started and see where it leads
 * apw wa
 * apw wanders off to see a panto
 * tgardner wonders what is a panto ?
<elmo> tgardner: a show in a theatre that tends to involve lots of  audience interaction and is often aimed primarily at kids
<smb> pantomimes playing
<tgardner> elmo, that explains why apw is so jazzed :)
<JFo> <- lunch
 * tgardner --> lunch
 * jjohansen -> lunch
<JFo> enjoy
<JFo> :)
<sforshee> JFo, question about bug statuses when they affect upstream linux
<sforshee> do we set the status to fix released when the fix is in an rc kernel, or do we wait for the final release?
<JFo> we wait until it is in our kernel
<sforshee> for the "Linux (Ubuntu)" package, yes
<JFo> for upstreams we have a bugwatch that automatically does the upstream status change
<JFo> maybe I am misunderstanding
<JFo> want to chat via mumble?
<sforshee> maybe a more concrete example would help
<sforshee> yeah, that sounds good
<JFo> :)
 * vanhoof waves bye
#ubuntu-kernel 2011-01-29
<Kano> hi apw , i that you added rtl8192ce driver, but the firmware is missing
<Kano> in linux-firmware
<Kano> from the driver package in the firmware dir
<scotty^> G'day all.  Will the DRM kernel patches for the (non-Cayman) Radeon HD 6000 series cards be backported to Natty's 2.6.37 kernel?  Apparently they aren't too invasive.
<scotty^> They have been pulled into 2.6.38 but I'm not sure if that kernel will make it into Natty given it is only at 2.6.38-rc2 and it is getting late in Natty's development.  Any info on that?
<ohsix> still have until april, 37 got to release pretty fast
<scotty^> hmm
<scotty^> I hope so
<scotty^> According to the Wiki the Natty beta is scheduled for March 31st 2011.
<ohsix> can an individual submit their own hw? :D https://certification.canonical.com/ let them fix all the bugs
<H3r0> hello people I want to know how have ubuntu developments check the new kernels?
#ubuntu-kernel 2011-01-30
<lionrafael> I already asked this in the general channel, but no one answered so I assume it's a more complicated matter. Ubuntu doesn't mount my disks correctly when booting from lilo. It seems to be an initrd problem. http://pastebin.com/Syz3aFfk
<lionrafael> ignore that please. I'll stick to #ubuntu. Sorry for disturbing your channel
<ohsix> apw: it's looking like cgroup-bin was causing the failure
<LLStarks> ogasawara, i'd like to report session-wide color banding on intel with the .38 natty kernel
<ohsix> apw: should i file a new bug with cgroup-bin after i close the suspend one with a comment about it?
<holstein> kudos kernel team :)
<holstein> i just got an EEEPC 1001p
<holstein> installed lucid
<holstein> no wifi, and some hotkeys not working
<holstein> updated to the latest kernel
<holstein> and BOOM
<holstein> all is good
#ubuntu-kernel 2012-01-23
<Anon783> hello?
<Anon783> ANybody there?/
<Anon783> Who likes movies?
<ppisati> cking: did you ever use sshfs with any of our builders?
<cking> ppisati, nope
 * cking slips offline- really feeling rough today
<diwic> tgardner, hi there, would you mind doing me a favour and install "nano" on tangerine? Still haven't got accustomed to vi ;-)
<diwic> tgardner, ah wait, it's just in the chroots there are no nanos
 * diwic takes back the previous question.
<tgardner> diwic, well, I just installed nano in the normal login. does that work for you?
<diwic> tgardner, it seems to work now at least, so thanks!
<tgardner> bouncing tangerine in 5
<htorque> diwic: hi! what's new in your latest jack detection kernel (i.e., should we re-test)? and: what's the default value for 'model' parameter? if i don't set it to 'auto', jack detection doesn't work on my thinkpad.
<diwic> htorque, hi! thanks for testing the jack detection kernel!
<htorque> diwic: thanks for providing one ;-)
<diwic> htorque, in short, do you notice any regressions of any input/output when you use the model=auto approach?
<diwic> htorque, in short, model=auto is the future, so we would like to move as many machines as possible over to using model=auto
<diwic> htorque, there are news for realtek machines, but you were having a conexant IIRC, so for you it does not matter
<htorque> diwic: no, but i don't use any fancy stuff like audio over hdmi and alike. mic works, sound from the speakers work, sound from the headphone works, PA is not acting up - i'm happy with it. :)
 * diwic looks at htorque's alsa-info
<htorque> yeah, it's conexant
<diwic> htorque, cool, I'll submit a patch upstream to move your machine over to model=auto. How would you like to be credited in the patch (something like Tested-by: John Doe <john@doe.com> )
<htorque> diwic: do i need to show up at all? i'd prefer not to. ;-)
<diwic> htorque, that's ok as well.
<htorque> great, thanks for your efforts, jack detection is a really useful feature! :-)
<diwic> htorque, sent. http://mailman.alsa-project.org/pipermail/alsa-devel/2012-January/048315.html
<htorque> \o/
<tgardner> apw, see /var/run/nm-dns-dnsmasq.conf
<apw> tgardner, ok for me it contains ipv4 DNS from my local router, and ipv6 from my tunnel
<tgardner> apw, right. I guess my point is that its NM thats doing all this.
<apw> tgardner, yeah it used to run /etc/resolv.conf and now does this new file ... hmmm
<tgardner> apw, well, it still uses /etc/resolv.conf 'cause thats a libresolv thing, right? 
<apw> tgardner, i meant it used to write over /etc/resolv.conf and now it writes over this new one
<tgardner> apw, it still writes the default domain info into /etc/resolv.conf (as I would expect)
<apw> tgardner, ahh i don't have that in mine, but i prolly don't have one
<tgardner> no matter. I think the reason for the change must be for ipv6 support (as you said earlier).
<apw> yeah perhaps so
<vanhoof> tgardner: any idea if there are plans for cw-3.2 in oneiric?  digging around I found a bug filed against lucid
<tgardner> vanhoof, no plan. leann has only done Lucid LBM. Is there a need ?
<vanhoof> tgardner: there is, new uCode just landed for the 6235, 2200, 2230, 105, and 135 series cards, which are all supported in 3.2 
<tgardner> vanhoof, I am coincidentally looking at the ucode updates
<vanhoof> tgardner: would a new bug be preferred or just a series nomination on the existing lucid bug
<vanhoof> tgardner: yeah just saw they were posted friday evening
<tgardner> vanhoof, new bug I think
<brendand> bjf - hi
<bjf> brendand: hi
<tgardner> vanhoof, do you have a need for Maverick or Natty ?
<vanhoof> tgardner: nope, none
<tgardner> k
<brendand> bjf - is the next oneiric kernel in the pipeline soon?
<bjf> brendand: yes, why
<brendand> bjf - trying to get a rough idea of when we need to test it
<brendand> bjf - it's being prepared?
<bjf> brendand: if you look at the interlock schedule, it shows that this week is a "prep" week, next week will be verification and the following regression testing
<borudev> Hello, how is everyone? I had a quick question troubleshooting my ubuntu 11.10 server installation. I installed the same OS on 2 different servers and I'm experiencing the same problem. What happens is I turn on the server, it's ok for few hours, and then when I try to SSH to it, it get a time out, when I plug in the keyboard, and type something then I can connect to it again. Seems that 
<borudev> it's going to some kind of sleep mode. Note, no desktop was installed just pure server OS. Anyone had this issue before? what could cause it? Thanks
 * tgardner --> lunch
<apw> bjf, ok oneiric should be all sorted out
<bjf> apw, thanks
<apw> borudev, i have not seen that on any of my servers.  the default for suspend after a bit did change due to the fixing of a bug somewhere, but i thought that was in gnome somewhere
<ogasawara> tgardner: want me to do cw-3.2 for oneiric? or have you already started.
<tgardner> ogasawara, that would would be great. I just uploaded linux-firmware for precise, so we need to think about getting those firmware bits into oneiric.
<tgardner> I'm gonna ask if dropping Precise linux-firmware into Lucid/Oneiric -backports is appropriate. if so, then I'll have you add an install dependency on CW-3.2
<ogasawara> tgardner: ack
<ogasawara> tgardner: I also saw 3.3-rc1 is out.  I started prepping the Q repo on thursday before I bailed, so I'll try and get that finished up in the next day or so as well.
<tgardner> ogasawara, cool. I also messed with a bit, but lost interest after grinding through a bazillion new config options
 * ogasawara twitches at the thought of more config review
<tgardner> I did more then twitch. it was more of a violent recoil...
<lamont> did we possibly mess around with tickspersec or other time related stuff in lucid?  I have some wierd ntp behavior that I'm seeing
<tgardner> lamont, IIRC there was a stable update patch that prevents div by 0 after 200+ days. herton ?
<tgardner> bjf, herton doesn't seem to be around. do you remember that one ?
<bjf> tgardner: no, i don't remember that
<bjf> tgardner: herton is on a swap day
<tgardner> lamont, is it frequent enough that you can determine when it began ?
<lamont> http://paste.ubuntu.com/814622/ <-- tgardner, using  2.6.32-37-server #81-Ubuntu
<lamont> next you'll want to know what the kernel rev was before it was rebooted, huh?
<tgardner> lamont, uh huh
<lamont> that'll take a bit more digging
<tgardner> gaining 2 secs every few minutes seems like a bad thing
<tgardner> lamont, please start a bug using 'ubuntu-bug linux' and I'll get the stable team looking at it.
<lamont> tgardner: let me see how well that works there
<tgardner> lamont, I suppose its so firewalled it doesn't even know the outside world exists
<lamont> The program 'ubuntu-bug' is currently not installed.  To run 'ubuntu-bug' please ask your administrator to install the package 'apport'
<tgardner> lamont, well, we really need the HW and BIOS info, as well as http://paste.ubuntu.com/814622/ attached to the bug.
<lamont> tgardner: cool.  I'll grab that pile.  front end of lshw for the hw/bios info, I expect?
<lamont> and then marked as affecting lucid? or just filed against linux/lucid?
<lamont> tgardner: bug 920649
<ubot2> Launchpad bug 920649 in linux "ntp keeps resetting system time, losing sync" [Undecided,New] https://launchpad.net/bugs/920649
<tgardner> lamont, ack
<jsalisbury> lamont, you'll probably be asked to run the following from our bug bot: apport-collect 920649
<lamont> jsalisbury: yeah, trying to avoid actually installing apport on that machine.
<lamont> so I may need to dig into apport enough to find what that command would actually gather
<jsalisbury> lamont, ahh, ok.
<jsalisbury> lamont, The following would be helpful if you can't run apport:
<jsalisbury> 1) uname -a > uname-a.log 
<jsalisbury> 2) dmesg > dmesg.log 
<jsalisbury> 3) sudo lspci -vvnn > lspci-vvnn.log 
<jsalisbury> 4) cat /proc/version_signature > version.log 
 * tgardner -> EOD
<hallyn> is it possible to use /etc/apport/blacklist.d/ to blacklist kernel oopses?  (i get a ton of in_atomic ones.  apport won't let me report them anyway. sick of popups)
<hallyn> according to teh readme i'd need to do it by executable name...
#ubuntu-kernel 2012-01-24
 * smb rolls in
<_ruben> rollin' rollin' rollin' ... rawhide!
<smb> hehe... codin', codin' codin', 'though the hands are swollen, velocity gets rollin', precise! :-P
<diwic> smb, I posted a patch for some macbooks at 13/1 to the kernel-team ML, but it was never applied (or paid any other attention). Could you apply/review it?
<diwic> (I was poked by yet another macbook user yesterday who wondered why his audio was choppy...)
<smb> diwic, Let me see whether I can find it again. just depending on which release this is intended for, it needs more than one to look at.
<diwic> bug 909419 
<ubot2`> Launchpad bug 909419 in linux "[Several MacBooks (with PCI SSID 10de:cb89)] Choppy sound. Videos play double speed" [Undecided,In progress] https://launchpad.net/bugs/909419
<diwic> smb, it's for 12.04
<smb> found it
<smb> diwic, Looks ok and is actually in the queue for the next stable release. Will comment on your mail but ogasawara or apw may decide to just wait till the whole stable update comes out.
<diwic> smb, ok
<diwic> thanks
<_ruben> smb: moonlighting as a singer/songwriter? :)
<smb> _ruben, Unlikely as a singer. There are laws against that. ;) Now songwriter... probably get beaten up for some sense of humor...
<_ruben> heheh
 * cking reboots
<apw> diwic, hey about ?   you got a branch with the current jack patches including the backported fix?
<diwic> apw, sure
<apw> i wanted to test and may as well do so with an up to date kernel
<diwic> apw, http://kernel.ubuntu.com/git?p=diwic/ubuntu-precise.git;a=shortlog;h=refs/heads/jack-detection-backport
<diwic> apw, once tested, feel free to report to https://wiki.ubuntu.com/Audio/PreciseJackDetectionTesting :-)
<apw> diwic, that was the plan, i was thinking 7 people was a bit poor, so thought i could add a couple of test cases
<diwic> apw, nice, thank you
<apw> of course my machine may not work once this shiney X update is installed :/
<apw> diwic, you haven't digned off your backport patch
<apw> or indeed any of them
<apw> and as they are coming via you they should be, and i assume all this is now upstream in 3.3 right?  so we should know if the sha1s are stable and in linus
<diwic> apw, they should be in 3.3 all of them yes...
<apw> diwic, so if we are to take it, we will be asking you to confirm the sha1s are the same and update the cherry-picks to remove the git:// bit and to add a s-o-b to them all
<apw> diwic, in better news the patches trivially rebased to the -10 kernel
<diwic> apw, okay
<apw> diwic, i would say also add a blank line above the cherry picked/backported line and your signed off under it so it looks all shiney
<apw> picky picky apw
<diwic> apw, so how is it looking? That is if you don't find any regressions, and I do what you ask for this afternoon...?
<apw> diwic, heh not looked at the patches at all, just the commit messages, will let you know how my testing goes
<apw> though i have a fair bit of updating to go
<DroidII> Hi all, im still running 11.04 with a 2.6.38-11 generic kernel. Just wondering if there is a kernel that wont crash my thinkpad, or if i can get some assistence building my own...
<diwic> apw, btw if you build a kernel source package, you can send it to me, I can sign and upload it to the ppa. If you like.
<apw> DroidII, unsure ... what ones have you tested
<apw> DroidII, and which thinkpad nightmare is it
<DroidII> the last one i tried was 2.6.38-16 i think the last officail release for 11.04, laptop would not resume from standby, often crashed on reboot ...
<DroidII> haha, the T500
<DroidII> 38-11 has been great,but, im getting a lot of network issues, network manager died big time whilst overseas, and now WICD wont connect to cabled connections properly
<DroidII> i could be on 4 or 5 differant networks every day
<apw> yep networking in the main is very poor when you are in that environment, UDS is always a nightmare
<apw> DroidII, have you tested any later kernels?
<apw> diwic, i don't normally make source packages for test builds
<DroidII> i havetried to install a ver 3 kernel, but to no avail -- cant get grub to load it, so sorry, no
<apw> DroidII, i wonder why that would be, lucid can load them
<DroidII> maybe im doing it the wrong way then...
<apw> DroidII, you don't have powernap installed do you ?
<DroidII> looking in Synaptic package manager, the lastest available is 2.6.38-13.53....
<DroidII> no, I dont think so
<apw> worth checking as it kills most thinkpads on s/r
<DroidII> no, not installed
<apw> DroidII, is there an lp bug open for this ?
<DroidII> sorry, i have no idea
<apw> i'd say if you haven't filed one, that we say likely not
<apw> it would be the obvious first step, filing a bug aginst the kernel saying which one it works in and which not, and including the symptoms
<rbasak> ppisati: any news on bug 920511? I think the same issue is affecting the installer now. If we can't get it fixed today, can we roll back to a known working version in the archive?
<ubot2`> Launchpad bug 920511 in linux-ti-omap4 "Regression: netinst on panda armhf fails" [Critical,Confirmed] https://launchpad.net/bugs/920511
<ppisati> rbasak: i already have a working kernel, but i'm doing some more testing
<apw> ppisati, can i assign that LP to you then (as i have it open on my screen) ?
<ppisati> apw: yep
<apw> rbasak, i see you have a work around to keep working yes ?
<rbasak> apw: I did have, but now the issue is in the installer, and my brief attempt at using the same workaround there hasn't work. I haven't worked out what's going on yet.
<rbasak> My installer cmdline has always been a bit different: "console=ttyO2,115200n8 earlyprintk=ttyO2 text fixrtc omapfb.vram=0:24M vram=48M priority=critical"
<rbasak> No idea why, that's just what everyone else used and it worked
<rbasak> So I tried to merge this with the cmdline ppisati gave me yesterday and got: "console=ttyO2,115200n8 earlyprintk=ttyO2 text fixrtc elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 priority=critical" but this doesn't seem to have worked
<ppisati> to make cma work, you just need these two: "mem=456M@0x80000000 mem=512M@0xA0000000"
<ppisati> without thse, at boot time, the kernel doesn't reserve a pool where doing the allocation later
<ppisati> and thus drivers doing large allocation fail
<ppisati> since cma is not yet part of mainline
<ppisati> and since i've found at least one "home made" fix for this cma
<ppisati> i think the best solution is to revert it
<ppisati> rbasak: if i hand you a kernel, can you try it with the installer?
<apw> ppisati, sounds appropriate to me as well
<rbasak> ppisati: sure, but one moment - I think my complaints about the installer may be some hardware I swapped today. I'm trying it with the old disk.
<rbasak> ok, console=ttyO2,115200n8 earlyprintk=ttyO2 text fixrtc elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 priority=critical in the installer does appear to work
<rbasak> so that's a new thing today - I've had to change the installer kernel cmdline, but that's trivial for me
<apw> bah where did diwic go
<rbasak> applying the workaround after the installer is a pain though, because I have to physically pull out the sd card and write to it, and I can't automate that
<ppisati> rbasak: what if i hand you the kernel and you try it iwth the default cmdline?
<rbasak> ppisati: happy to test any kernel on the installer - that's really easy for me to do - I just need to know which cmdline to use, there is no default afaik.
<rbasak> ppisati: I have a script that wraps cobbler, I just need to give it URLs (or local files) for the kernel image, initrd image and the cmdline to use.
<ppisati> rbasak: cool, let me upload it
<ppisati> rbasak: http://people.canonical.com/~ppisati/linux-image-3.2.0-1404-omap4_3.2.0-1404.6~revertcma_armel.deb
<rbasak> and I seem to have a separate bug that causes a kernel panic when installing onto a new usb disk I ordered that arrived today :-(
<ppisati> rbasak: uhm, strange
<rbasak> might be the disk. it's usb bus powered
<ppisati> rbasak: ah, then if you don't have a proper ac feeding the board it could be a power issue
<ppisati> rbasak: anyway, please test it and tell me how it goes
<rbasak> ppisati: hmm. I was expecting u-boot wrapped kernel and initrd images. I can make a kernel image, but what should I do about the initrd? Will the installer need matching kernel modules?
<rbasak> right now I'm running this: python toecap.py --kernel=http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/uImage --initrd=http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/uInitrd --preseed=/root/preseed --mac-address=2e:40:74:ee:6c:0a --kopts='console=ttyO2,115200n8 earlyprintk=ttyO2 text fixrtc elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0
<rbasak> xA0000000 priority=critical'
<rbasak> so if I can have a replacement kernel and initrd in the format as at those urls then I can drop in a replacement for test
<ppisati> rbasak: ok, i'll upload the uImage and initrd
<ppisati> rbasak: wait
<ppisati> rbasak: i'm cleaning up initrd of all you stuff...
<ppisati> rbasak: http://people.canonical.com/~ppisati/1404-revertcma/
<ppisati> rbasak: .deb the kernel and the uImage/uInitrd it generates
<rbasak> ppisati: thanks, trying now. I'm to use the cmdline I was using last week, correct?
<ppisati> rbasak: right
 * rbasak switches back to yesterday's hard drive too
<rbasak> ppisati: there's an initrd problem but the kernel booted ok
<ppisati> rbasak: can you try with the panicing usb hdd?
<rbasak> sure
<rbasak> ppisati: it also works (but initrd fails) with the panicing usb hdd. http://paste.ubuntu.com/815282/ for this last run. But I think the panicing usb hdd may just be faulty
<Kano> hi apw , how about adding drm backports to 3.0 kernel?
<Kano> http://cgit.freedesktop.org/~eugeni/kernel/?h=3.1-drm-intel-backports
<Kano> there are backports
<ppisati> rbasak: ok, then i'll send the fix
<Kano> err 3.0 is also availabel
<rbasak> thanks ppisati!
<rbasak> So this USB disk is causing a voltage drop of 0.1V, powered off the pandaboard off USB which is powered by an AT PSU. Measuring at the board supply, it seems to hold >4.7V all the time. But the drive just keeps spinning up and down during boot. It seems to work OK on my laptop. When I was working with ppisati's workaround, this drive was causing the kernel to panic, but not always at the same point. Any tips? Still a power issue?
<ppisati> rbasak: AFAIK, it's common for the disk to spin up/down during reboot (at least that's what mine does)
<rbasak> I mean constantly, regularly, maybe about a 0.8s interval
<ppisati> rbasak: ah no, that's not common then
<rbasak> sounds very similar to a failed disk clicking
<ppisati> rbasak: btw, i'm using a power supply capable of 3.8A @ 5V
<rbasak> I was using one of those, then I switched to an AT PSU which I presume can do quite a bit more
<ppisati> rbasak: don't know
<rbasak> I might measure the current. Wish I had a CRO!
<rbasak> looks like max 1.2A when spinning up, 0.9A once spinning - including the panda
<rbasak> but it's only a cheap multimeter, I can't see spikes
<ppisati> ok, fix sent
<rbasak> to the archive?
<apw> cking, smb, http://people.canonical.com/~apw/jack-detection-precise/ <-- those jack patched kernels
<cking> ta
<apw> https://wiki.ubuntu.com/Audio/PreciseJackDetectionTesting for results
<diwic> hi, my Lucid machine just oopsed with 2.6.32-38 
<diwic> never seen it with 2.6.32-37
<diwic> caps lock and scroll lock are both blinking
<Kano> apw: which command do you use to build the final kernel from git with orig file?
<Kano> i mean the source package
<ppisati> rbasak: to the kernel ml
<apw> Kano, dpkg-buildpackage -S though you need to clean the tree first
<Kano> how do you clean it
<apw> fakeroot debian/rules clean
<Kano> that does not insert changes or?
<apw> nope that just cleans and preps the tree
<Kano> currently i am working on a script that rebases the tree and adds some changes+commits. 
<Kano> i just dont get my commits in the changelog
<apw> if you add a new changelog entry with fakeroot debian/rules startnewrelease
<apw> the f d/r insertchanges which insert a summary of the git log since the last release commit
<apw> ogasawara, hey, i am thinking about uploading just the three commits (as they arn't ABI bumpers) on the top of the precise tree
<apw> as one is an urgent CVE
<ogasawara> apw: go for it
<ogasawara> apw: I can then upload if one is an urgent CVE
<apw> ogasawara, i have already got the tree ready, if you are happy i'll just push it
<ogasawara> apw: sounds good
<apw> diwic, did you see cking's brokenness
<apw> +1)  ||
<apw> http://people.canonical.com/~apw/jack-detection-precise/
<apw> https://wiki.ubuntu.com/Audio/PreciseJackDetectionTesting
<diwic> cking, hrm, that's pulseaudio bug I believe I fixed, what is the installed version of PulseAudio (apt-cache policy pulseaudio) ?
<apw> diwic, is the pulse fix in your PPA only ?
<apw> diwic, i have just noticed that i have independant volume levels on headset and speakers now
<apw> diwic, as in they are presistant and independant
<apw> is that something new in precise or something your jack patches allow
<apw> diwic, also i seem to have a dead internal mic on my aspire one, but thats not a regression, is that easy to debug ?
<diwic> apw, 1) the fix is only in the PPA, but the bug should only be in the previous version of the PPA as well, so...which is why I'm curious what version of PulseAudio cking is running
<apw> ogasawara, have you been using a .orig yet on precise ?
<ogasawara> apw: I have
<diwic> 2) do have independent volumes you'll need support in both kernel and PulseAudio. PulseAudio support came in 11.10. Hardware support is increasing with the jack detection patches being a huge leap forward.
<diwic> apw, alsa-info for your acer aspire please (for triaging the internal mic)
<apw> diwic, will do
<cking> smb, the old workaround was: http://smackerelofopinion.blogspot.com/2009/11/audio-weirdnesses.html
<smb> diwic, Gosh remembered that to be the same on my older Aspire. Its the mic left and right channel being phased for complete annihilation
<smb> cking, I basically mute one half in alsamixer
<diwic> smb, yeah, that's what I was thinking of as well
<diwic> however for some realteks we have a fix for that, so if we're lucky apw has one of those and we can quirk it
 * cking wonders if most of the driver is basically quirks
<smb> Need to check my codec. I have little hope to have the same as him, but if it is realtek it probably is another addition to magic quirk
<diwic> cking, the problem with that workaround is that when you start changing between internal and external mic, you will essentially cancel out the non-inverted mic
<cking> diwic, ah, ok, so that's a cking fail then
<smb> Mine is Realtek ALC268
<apw> diwic, http://paste.ubuntu.com/815376/
<diwic> cking, a significant part of it. It used to be the majority, but Takashi is working on simplifying most of the quirks so things are improving.
<diwic> let me check ALC272X and ALC268
<smb> diwic, I would guess this also needs the exact model and maker
<diwic> nope, we have fixes only for ALC271X and ALC269 at the moment :-(
<herton> diwic, were you able to get a trace on the lucid crash? May be 2.6.32-38 introduced a regression
<diwic> herton, I took a photo but it didn't show much really, and the next time I booted it worked fine
<diwic> herton, first line of what was visible on screen was .... exit_notify+0x13/0x170
<diwic> and two lines down it says something about print_oops_end_marker, indicating I was not looking at the original error (I assume?)
<herton> hmm ok, yes, probably the real problem had scrolled up already
<diwic> cking, that's at least my logical conclusion from looking at your fix, but I haven't really tested it so I might be wrong
<diwic> but yeah, the inverted internal mics are one of the more common problems today that I haven't figured out how to best resolve yet
<diwic> herton, if it happens again, is there something one can do to see more of the original error?
<herton> diwic, may be using serial console/netconsole debugging or checking if something ends up saved on logs, or if there is some way to reproduce reliably
<tgardner> ogasawara, its not gonna work dropping linux-firmware into -backports because LBM is in main and we can't have a dependency like that.
<ogasawara> tgardner: ack
<tgardner> ogasawara, I'll probably just SRU the new iwlwifi ucode bits
<smb> diwic, If you need the complete data http://paste.ubuntu.com/815390/
<diwic> smb, thanks...
 * diwic wonders what Windows 7 would do about inverted mic
<matti> Hi folks.
<matti> How would I found out that #805341 is included in latest proposed from Ubuntu?
<matti> I cannot seem to be able to find it in changelogs, therefore I assume that the kernel wasn't built yet? :)
<Kano> apw: how about adding: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff_plain;h=93165b7774a04cf76bc46eb6c9181ab7a8b545d7
<matti> Hmmm...
 * matti is still looking.
<apw> Kano, that commit was in 3.2 ?
<apw> diwic, http://paste.ubuntu.com/815376/ for my alsa-info.sh
<Kano> apw: yes
<Kano> it works for more or less any kernel
<diwic> apw, thanks
<Kano> 1:1 from the knc1 site
<apw> Kano, so then its already in precise as uploaded, if it is wanted before then then someone has to file a bug and test it
 * diwic wonders if we can tweak the capture control node to always mute the right channel whenever internal mic is set as the input...hmm
<Kano> well 3.2 is problematic with rt2800pci
<Kano> therefore i use the 3.0 drm backports
<Kano> + knc1 patch
<Kano> the drm in 3.0 is not enough to drive 2 ports on intel snb correctly
<apw> diwic, i like the fact it says the mic is "Ext Left" when its on the right :)
<Kano> is ndiswrapper in 3.2 p already?
<Kano> and aufs
<diwic> apw, color and location is often wrong, probably since Windows 7 does not use that information...
<diwic> apw, or because the codec vendors do not know how the machine looks like 
<apw> yeah
<apw> Kano, no and no
<diwic> apw, with the advanced tab in hda-jack-retask you can correct that so it is on the right :-)
<apw> heh nice
<Kano> fakeroot debian/rules startnewrelease
<Kano> fakeroot debian/rules clean
<Kano> that does not add my changes to the changelog
<apw> indeed, if you read the scrollback you need f d/r insertchanges
<herton> matti, it should be landing in proposed this week
<herton> matti, you can check the linux-image package changelog, the bug will be cited on it
<Kano> insertchanges i tried first...
 * herton -> lunch
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
 * ogasawara back in 20
<herton> lamont, about bug 920649, what's the previous kernel running on that machine which worked (probably there is still something in the logs, or even the previous installed kernel on that machine could give a hint)
<ubot2`> Launchpad bug 920649 in linux "ntp keeps resetting system time, losing sync" [Undecided,In progress] https://launchpad.net/bugs/920649
<apw> ogasawara, ok tree is all updated, upload is in the hole
<ogasawara> apw: thanks
<matti> Hi herton 
<matti> herton: I did dig it out in the end :)
<matti> herton: I did not know where to look initially :)
<matti> herton: Too many places :)
<tgardner> ogasawara, I forgot to mention that Lucid i386 LBM FTBS'd. Have you had a look at that ?
<ogasawara> tgardner: it did? hrm, I'll take a look
<tgardner> sconklin, your mumble is silent
<sconklin> git@github.com:sconklin/autotest.git
<apw> $ glxinfo -l | grep -i GL_MAX_TEXTURE_SIZE
<apw>     GL_MAX_TEXTURE_SIZE = 8192
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Jan 31, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<hallyn> apw: so, going with Linus' suggestion of all devpts mounts being newinstance, out boot sequence would have to made /dev/ptmx a symlink (or bind mount), otherwise you can't get ptys.  That aside I see no problems (just an fyi).  not sure if that's deemed acceptable
<hallyn> s/out/our/
<sconklin> I'm back
 * tgardner --> lunch
<linux> hello
<linux> is anyone there
<linux> hello i have question regarding customization of kernel
<diwic> cking, what regressions are you seeing?
<cking> diwic, E: [pulseaudio] module-alsa-card.c: Assertion 'jack->path && jack->path->port' failed at modules/alsa/module-alsa-card.c:299, function report_jack_state(). Aborting.
<cking> Aborted (core dumped)
<diwic> cking, both machines?
<cking> nope, just the X220i
<diwic> what regression on the other one?
<linux> actually i am facing booting time error
<cking> diwic, no regression, /me made a typo, lemme fix the data, sorry
 * cking waits for the wiki to respond...
<diwic> cking, ok, *phew* -- what version of pulseaudio are you using on the x220?
<diwic> apt-cache policy pulseaudio
<linux> please can anyone help me  around over here
<cking> diwic, let me see if I've got the latest, I need to dig it out of my pile of boxes
<diwic> cking, because it looks like a bug I've already fixed 
<linux> hello
<cking> diwic, I've got a bad feeling that I didn't pull in the update after doing the add-apt-repository
<cking> gimme 5 mins
<diwic> cking, sure. Thanks for testing, btw. :-) 
<linux> i am facing sum issues in booting up the customized   kernel
<cking> diwic, pulseaudio: 1:1.0-ubuntu5-jackdectection2
<diwic> cking, thanks, that's the right one
<diwic> bbl
<linux> plz someone help me get out of this issue
<apw> linux, it would help if you provided some details on what you are seeing, and indeed what is customised
<ohsix> halp i built my root fs out of my kradleet kernelz
<linux> yes actually i used make menuconfig utility to customize
<apw> and what happens
<linux> kernel was customized successfully
<linux> generated two kernel header files with extension .deb
<linux> then i extracted them and updated grub
<linux> let me send you link from i followed the process
<linux> well if u can give me your mail id i can send you my issue with snapshots
<diwic> cking, if you're still around, can you send/pastebin me a pulseaudio log: https://wiki.ubuntu.com/PulseAudio/Log 
<cking> diwic, will do
<cking> diwic, http://paste.ubuntu.com/815683/
<cking> diwic, is that enough to be going on with for the moment? I need to pop-offline now
<diwic> cking, feel free to pop offline
<diwic> cking, I'm probably going to poke you tomorrow
<diwic> too tired to resolve the bug right now anyway
<cking> diwic, sure, no problem :-)
<arges_> apw, was it you or cking that was having issues with the jack detection patches?
<apw> arges_, cking
<arges_> apw, ah thanks. just updated the wiki and send an email to david
<jsalisbury> tgardner, Is there someone that is familiar with ppc: bug 919654
<ubot2`> Launchpad bug 919654 in linux "Very long delays during boot - BUG: soft lockup - CPU#0 stuck for 24s! [modprobe:290] - BUG: soft lockup - CPU#0 stuck for 21s! [Xorg:896]" [Medium,Confirmed] https://launchpad.net/bugs/919654
<arges_> jsalisbury, looking
<jsalisbury> arges_, cool, thanks :-)
<tgardner> jsalisbury, looks like the nouveau driver is pausing for a long time in nouveau_wait_eq() for a register value that it never gets.
<tgardner> jsalisbury, I assume this is a regression ?
<jsalisbury> tgardner, It may be.  The bug report stated this is a fresh install and he has no previous intstall to compare against.
<arges_> jsalisbury, don't have powerpc hardware anymore though... 
<jsalisbury> tgardner, I can ask him to try and install previous releases.
<tgardner> jsalisbury, you might also ask BenC. I think he's got some ppc HW
<jsalisbury> tgardner, ok will do, thanks
<tgardner> although he may not have nVidia HW
<jsalisbury> right
 * tgardner -> EOD
#ubuntu-kernel 2012-01-25
<bryce> apw, so this cycle it appears Intel has again shifted to a new drm-whatever branch as the new cool thing they're asking users to test.  drm-intel-fixes
<bryce> apw, the drm-intel-next-proposed branch seems to have been abandoned.  How irritating would it be to drop that branch and add drm-intel-fixes in the autobuilder?
<ohsix> bryce: talk to Sarvatt, i think he knows more than you'd hope to ask about that :D
<bryce> ohsix, I take it it's already been looked into?
<bryce> I pm'd about it the other day in fact, but haven't gotten his reply yet
<ohsix> about your question specifically i don't know, but he knows about all the trees and the intel drivers
<bryce> ohsix, ok thanks.
 * apw yawns ...
 * cking offers apw some coffee
 * apw offers cking a gold star
<cking> how nice
<apw> cking, we need a mumble tie breaker to know who is broken
<cking> apw, what have you broken?
<apw> cking, who knows, mine is above average in the working department normally
 * apw cries
<cking> apw is stuck in a twisty maze of pulse audio and mumble complexity
<apw> cking, right i will have to reboot, but i have an update in flight ... so ... i'll be a while
<smb> apw, Have you got the special pulse running there?
<apw> nope
<cking> what changed since yesterday (apart from a shed load of updates?)
<smb> one thing that sometimes helps me is
<smb> doing the usual killing of mumble and pulse
<smb> then start mumble but not immediatly connect
<smb> then go to config and set output to something like alsa
<smb> apply and set it back to pulse
<smb> then connect
<smb> (of course apply going back to pulse too)
<jk-> bah, mumble misbehaving
 * jk- heads out
<apw> bryce, ok switched that intel branch over to drm-intel-fixes
<reisei> hi, all. I have a question about DSS. So, in 2.6.38 with bootarg omapdss.def_disp=dvi I can choose the default screen. I start the system and when I plug the cable, the image appears. In 3.0.13 screen stays black and goes to power-saving mode. How can I fix it in 3.0.13?
<bryce> apw, sweet, thanks
<Daviey> diwic: around?
<diwic> Daviey, hi there
<Daviey> diwic: heya
<apw> diwic, Daviey has a mac 7,1 which is playing up
<Daviey> diwic: so... i have a ma
<Daviey> thanks apw 
<Daviey> diwic: The sound, following a fresh boot - the audio plays sounds 'out of order'
<apw> OH, Daviey this fix which went into that very very latest precice kernel
<apw> thats for a 7,1
<diwic> bug 909419
<ubot2`> Launchpad bug 909419 in linux "[Several MacBooks (with PCI SSID 10de:cb89)] Choppy sound. Videos play double speed" [Undecided,Fix released] https://launchpad.net/bugs/909419
<Daviey> So, for example, if i played audio saying "hello" the speakers would play "el-he-lo""
<apw> Daviey, do you have Ubuntu-3.2.0-10.18 ... if not get that and test
 * apw will be a bit dissapointed if it works :)
<Daviey> 3.2.0-10-generic :(
<apw> Daviey, check the # number
<Daviey> err
<apw> as the fix is only in the second -10
<apw> Linux dm 3.0.0-16-generic #26
<apw> that # number
<Daviey> 3.2.0.10.10
<Daviey> oh
<apw> nope that linux-meta
<Daviey> #17-Ubuntu
<apw> ok, there is an update then
<Daviey> updating
<apw> diwic, you will be pleased to know i slipped your fix in with some security updates
<apw> diwic, did you see anything about my mic in that dump by the way ?
<Daviey> apw slips it in.
<apw> f'nar
<diwic> apw, security fixes for 3.2? or are you talking SRU here?
<apw> diwic, yep for 3.2, vary rarely we get asked to expedite things out
<apw> even into development
<diwic> apw, so given the last bunch of testing (thanks for organising!), if I rebase my branch and add signed-off-by and remove "sound.git" where applicable, you think it's good enough to be merged before friday's upload?
<diwic> the jack-detection branch (sorry for changing topic)
<apw> diwic, arrrg ... got the link to that wiki page
<diwic> https://wiki.ubuntu.com/Audio/PreciseJackDetectionTesting
<diwic> cking just reported that his regression was fixed
<diwic> apw, and still waiting for response from arges but I'd assume it's the same one
<apw> cking, if your regressions are sorted can you fix your entry on the wiki ^^
<cking> ack
<apw> diwic, i think i lean to having it in if the testing is looking reasonable
<diwic> apw, and xyzzyman I've been in contact with and his regressions are resolved as well
<apw> as there is no better time than an alpha to get some testing
<apw> diwic, ok can you update his entry or get him to, that helps with convincing people
 * apw will test another box today at least
<apw> diwic, ok the PPA has kernel and pulseaudio, what is the ramifications if just the kernel makes it in
<ohsix> i think the kernel just enables the jack functionality to userspace, so without pulse the jacks wont work as a user expects
<diwic> apw, hmm, I'd make sure PulseAudio makes it in if the kernel does, but for the hypothetical/transient question: in general same behaviour as it is currently 
<diwic> apw, individual machines might get better jack detection
<diwic> apw, but the kernel must go first in order not to regress
<apw> i think mine does just with the kernel
<diwic> does what?
<ohsix> better jack detection
<apw> i think my acer had better behaviour with just the kernel change
<apw> i believe thats when it first split the volumes for headphone/speakers
<apw> ok so... we need to go first anyhow
<Daviey> diwic / apw: Doh, fresh boot - audio works fine.. thanks!
<Daviey> I was sure i tried postional_audio already tho :/.. oh well.
<apw> Daviey, users who moan when there is nothing wrong ... 
<apw> Daviey, ,.. and can't do testing right :)
<Daviey> apw: right.. damn slackers.
 * apw goes find a patch to stop Daviey's machine working again is some other subtle way
<Daviey> apw: honestly, there isn't much more you could do to make my experience less fun.
<Daviey> :)
<apw> :))
<apw> Daviey, don't challenge me
<Daviey> heh
<diwic> apw, just so I get this right. You wanted old-commit, blank line, signed-off-by <me> line, cherry picked from <sha> line. Is that correct? 
<diwic> or signed-off-by under the cherry-pick line?
<apw> diwic, old commit commentry and signed off by _them_ // <blank> // (cherry-picked ...) // BugLink: (if any) // S-o-b: _you_
<diwic> ok
<apw> #define ACC_MODE(x) ("\004\002\006\006"[(x)&O_ACCMODE])
<diwic> hmm, this one I wrote, so there's already a sign-off by me
<rbasak> What's the plan on getting the fix for bug 920511 applied please (https://lists.ubuntu.com/archives/kernel-team/2012-January/thread.html#18628) I realise that the issue is more complicated but I can't automate the workaround so my dev cycle is like treacle right now. Can we just get the reversion into the archive and sort the details later?
<ubot2`> Launchpad bug 920511 in linux-ti-omap4 "Regression: netinst on panda armhf fails" [Critical,In progress] https://launchpad.net/bugs/920511
<rbasak> AIUI, 921137 prevents me from automating the workaround
<rbasak> bug 921137
<ubot2`> Launchpad bug 921137 in flash-kernel "Flash-kernel-installer doesn't support d-i debian-installer/add-kernel-opts in preseed " [Undecided,New] https://launchpad.net/bugs/921137
<rbasak> This means that Ubuntu Server on ARM is uninstallable right now
<apw> bug 920511
<ubot2`> Launchpad bug 920511 in linux-ti-omap4 "Regression: netinst on panda armhf fails" [Critical,In progress] https://launchpad.net/bugs/920511
<apw> rbasak, i am being told that the arm team don't want the revert in, which is why we are holding it, they are happy with the work arround
<ppisati> rbasak: the arm decided for the booargs workaround, please ping orga/gruemaster/ndec/etctec
<ppisati> rbasak: see yesterday #ubuntu-arm log for a disucssion about it
<rbasak> OK, I wasn't aware of this. I'll speak to them - thanks
<apw> rbasak, so you either need to get them to agree we apply the fix, or pound on whoever supports flash-kernel
<rbasak> understood
<diwic> apw, modified commit messages now pushed to http://kernel.ubuntu.com/git?p=diwic/ubuntu-precise.git;a=shortlog;h=refs/heads/jack-detection-backport . Verified that all patches are in Linus' tree with same SHAs. 
<apw> diwic, excellent thanks
<apw> bryce, ok the first build is done and published
<apw> diwic, know anything about optimising mumble so it doesn't eat your machine alive ?
<ppisati> back in 10mins
 * apw drops to test a kernel
<apw> diwic, so just testing your new kernel on an oneiric userspace
<apw> diwic, and that also seemed to work, and gave me a new mic :)  the internal one, properly listed separatly
<apw> diwic, with its own mute so i can mute the internal and not the external mic, nice
<apw> diwic, ok on my dell the headphone is listed as unknown all the time, but does the right thing
<apw> diwic, as in the destination changes as expected, but the kernel doesn't know
<apw> (is that working or broken ??)
 * apw pokes diwic
<tgardner> herton, don't forget to upload Lucid LBM whilst doing the Lucid kernel
<herton> tgardner, ok
 * apw re-pokes diwic
<tgardner> cking, are you able to mount ecryptfs file systems using the current 3.2.0-10 kernel ? I'm getting this in dmesg: 'Mount on filesystem of type eCryptfs explicitly disallowed due to known incompatibilities'
<cking> tgardner, I'm running 3.2.0-10 fine with ecryptfs
<tgardner> cking, how about if you do this: 'mkdir -p .junk junk;mount -t ecryptfs .junk junk' and accept the defaults ?
<cking> lemme see
<tgardner> cking, hmm, maybe its because its stacked. it works in /tmp
<cking> works for me - but my home is not ecrypted
<tgardner> cking, I first noticed this on a server where /home is not encrypted. lemme try there on /tmp
<cking> tgardner, I get that now if I repeat those steps in my encrypted Private directory
<tgardner> cking, how are you stuffing the keyring ? dmesg: 'ecryptfs_parse_options: You must supply at least one valid auth tok signature as a mount parameter; see the eCryptfs README'
<cking> tgardner, this is where the pain begins
<tgardner> cking, mount normally prompts for these inputs
<cking> tgardner, fs/ecryptfs/main.c specifically checks that the lower fs is ecryptfs and then bails out with that error message "Mount on filesystem of type eCryptfs..."
<tgardner> cking, I get that, but now I'm trying on a server with no ecryptfs file systems mounted.
<cking> tgardner, and you still get that message?!
<tgardner> this is something that used to work
<tgardner> yes
<tgardner> lemme make sure it works on gomeisa (which is lucid)
<cking> tgardner, the README is rather impenetrable - I've not had much luck with the non-Private setup so far
<ppisati> tgardner: don't pull the cma revert yet, there's one patch missing and i've two config diffs that can stuffed in the same upload (thermal management&c)
<tgardner> ppisati, ack
<tgardner> cking, hmm, same behavior on gomeisa, but its running a 3.0 kernel.
<cking> tgardner, so how are you normally mounting this?
<tgardner> cking, this used to work on a Lucid desktop, so the keyring may have been stuffed: mount -t ecryptfs .junk junk -o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=y
 * cking compares his runes he was using yesterday..
<tgardner> cking, ok, it _still_ works on my Precise desktop, but only outside of the ecryptfs mount  point, e.g. /tmp
<tgardner> so, I think my issue on the server is the keyring
<tgardner> cking, can you send me your server runes ?
<cking> hrm, however, I was banging my head against the wall trying to mount using: mount -t ecryptfs -o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=y,passphrase_passwd=$ECRYPT_MOUNT_PASS $ECRYPT_PRIVATE_DIR $ECRYPT_CRYPTED_DIR
<cking> I had no luck and hence discussed this with dustin last night but got side tracked today. Lemme install Lucid on a spare box and see if this works on that
<tgardner> cking, I'd think a VM would work for testing this
<cking> tgardner, yup, good idea, I've got powerful enough H/W
<tgardner> cking, before you go to that trouble, lemme walk over to my server console and login. I'll bet this is a PAM vs SSHD issue.
<tgardner> bbiab
 * cking should config up a lucid box, so it's work that needs doing anyhow..
<tgardner> cking, hmm, same behavior even after a login to the console. perhaps we should consult our local expert tyhicks
<cking> tgardner, when he eventually comes on line later today then
<cking> so it works on lucid for you?
<tgardner> cking, only on a desktop. it didn't work on gomeisa
<cking> I was having issues with this yesterday trying to make it work on top of a loop back mount - I wonder if this is a generic issue 
<ogasawara> tgardner, apw: I'm planning to pull in diwic's jack detection patch set and smb's reboot syscall patch for Alpha-2.  Anything else I'm missing?
<apw> ogasawara, nothing i know of at the moment
<diwic> apw, back. So if it's listed as unknown all the time (in PulseAudio), it might help with the PulseAudio in the PPA, if that does not help, well - there are still machines to fix
<tgardner> ogasawara, has diwic pushed his fix? I've not seen the regression fix announcement come across the mailing list
<apw> diwic, i am not concerned as the user consumable behaviour seems ok
<diwic> apw, in particular machines using the model parsers inside the codec drivers, if that tells you anything
<reisei> 7
<apw> diwic, you should probabally send out a new pull request, as you have updated the patch commentary to make it pretty
<diwic> tgardner, the only regression found in the kernel was pushed and resolved the issue
<arges> diwic, hey that fix for pulseaudio worked for me. when your patches get in, will the pulseaudio package be updated as well?
<apw> diwic, and there you can say whats good
<diwic> tgardner, there have been two PulseAudio regressions whereas the second one is waiting to be build in a PPA.
<apw> diwic, those are not in the 'existing' pulse i assume right? so if the kernel goes in they don't get tickled
<diwic> arges, once the kernel is uploaded I'll try to push the new PulseAudio asap
<apw> don't get triggered, only if you have the PPA pulse
<ogasawara> diwic: I assume if I upload the kernel by Friday, will that give you enough time to coordinate the PulseAudio upload?
<ogasawara> diwic: I can get it uploaded sooner if it helps
<diwic> ogasawara, I'm counting on that; would that be Friday morning/evening US time?
<ogasawara> diwic: I'd usually wait till the evening on Friday in case of any last minutes patches thrown at us, but I can do the morning if that's easier for you.
<diwic> ogasawara, but yeah, doing it today or tomorrow gives me better margin
<ogasawara> diwic: let me shoot for today.
<diwic> ogasawara, excellent
<ogasawara> diwic: that should then be built by tomorrow and I can still upload again on Friday if I need to.
<apw> ogasawara, upload fun
<ogasawara> apw: I'm just waiting for the OMG we need these patches that will roll in on Friday at 5pm because no one bothered to test until Friday at 4pm
<apw> ogasawara, can i suggest we both have friday off, tgardner too
<apw> that might learn em
<ogasawara> heheh
<tgardner> ogasawara, yeah, I might have to skip out Friday for a power day.
<tgardner> powder*
<ogasawara> tgardner: you been getting a lot of snow?
<diwic> or a lot of babies ;-)
<tgardner> ogasawara, we did, but its all gonna melt today. 40F plus high winds
<ogasawara> tgardner: so you'll have a nice layer of ice over all that powder :)
<tgardner> ogasawara, yep, it'll suck
<ogasawara> diwic: just want to confirm git://kernel.ubuntu.com/diwic/ubuntu-precise.git jack-detection-backport is the correct branch to pull from and up to date with your latest changes?
<diwic> ogasawara, that is correct
<tyhicks> tgardner: Hey - still having trouble with the eCryptfs mount command above?
<tgardner> tyhicks, I'm about to send an email to you and kirkland` in a sec. 
<tyhicks> tgardner: sounds good
<tgardner> tyhicks, email sent
<tgardner> apw, git://github.com/sconklin/autotest.git
<apw> ppisati, zinc should be better now
<ppisati> cool
 * ppisati -> out for some grocery
 * tgardner -> lunch
<elops> I've started to use zram(ubuntu package zram-config) and I've noticed it gets full and then it's no help any more.  So I wrote a script to run every 5min that swapoff/on all the zram swaps at once.  The attempt is to force the population of disk swap to free up zram swap for less persistent swapping.
<elops> I beleve this is something that can better be handled by the linux VM machine, perhaps a component or sub-component of zram itself.
 * tgardner -> EOD
<kirkland> ogasawara: howdy!
<ogasawara> kirkland: heya
<jsalisbury> kirkland, o/  Good to see you around :-)
<kirkland> jsalisbury: hiya bud!
<kirkland> jsalisbury: *loved* the xmas card :-)  thanks!
<jsalisbury> kirkland, glad to hear it :-)
<bjf> ogasawara: heads up, i was playing with the security tests and one of them is hanging, the jjohansen is looking into it
#ubuntu-kernel 2012-01-26
<ogasawara> bjf: thanks.  out of curiosity, which test?
<bjf> ogasawara: seccomp_filter
 * ppisati -> dentist
<ppisati> anyone with upload rights, could you bump linux-meta-ti-omap4 in P? thanks
<apw> ppisati, will do, could you rebase linux-ti-omap4 again, there is an important security fix in the -10 series which you are missing, though i presume you'd go straigt to -11
<apw> ppisati, your bits are still in the new queue, so i can't do -meta yet
<ppisati> ah ok
<ppisati> i wanted to unf*ck the kernel first
<ppisati> since the images are screwed without this update
<ppisati> i'll do all the rebase today
<apw> ppisati, yep, thats reasonable
<apw> ppisati, oh that reminds me, sometime soon we want to retire the lucid/mvl-dove and start doing the work on maverick/mvl-dove
<ppisati> uhm, i din't touch any LMN kernels because i thought we were going to retire them soon
<apw> that has yet to be decided, those manager types are still talking
<smb> herton, Morning, you probably had not much time yet to settle down, but there has been a new release of 2.6.32.y since yesterday. Would you plan on pulling that for the next round of proposed that was just started?
<herton> smb, no, I think it can wait for the next round, unless there is something we want from this update
<smb> herton, Must admit I have not looked too deeply in there. Some random mmap thing sticks out in the headers. But things can be rather theoretical. This one does not yet seem to include anything about the ioctl fixup.
<smb> So I am fine either way. Just means I can do the ec2 rebase now. ;)
<apw> there is always a new round of -stable, they never end
<smb> exactly
<apw> at least with a 3 week candance we don't get more than 2 in any release
<smb> Was just wondering because this week is preparation week
<apw> smb, they all went up yesteday i think, so missed
<herton> smb, what's this ioctl issue?
<smb> apw, Indeed they did
<ppisati> the only thing certain in life is death, taxes and SRUs
<herton> hehe. yes, lucid finished build yesterday, we already have the packages done now for this round
<apw> smb, have we lost voice between you and me?  i heard you, ...
<apw> smb, herton and cking can hear me
<apw> smb, yay
<smb> herton, something to prevent / reject some ioctl calls on block devices. Not 100% sure whether that included also checking capabilites or just irgnoring some
<herton> ok
<ppisati> upgrading a beagle to P is a royal PITA!
<apw> ppisati, surly not for an ARM expert like you :)
<ogra_> ppisati, just estimate a week or two for it aynd dont be impatient ;)
<ppisati> :(
 * ogra_ hasnt touched beagles since two releases to prevent people around me from getting hurt and furniture in my house from breaking all of a sudden :)
<ppisati> do you use the boards to keep the furniture in place? :)
<ogra_> lol
<ogra_> well, one is my printserver, one monitors my heating system for the house and one sits on a shelf collecting dust 
<ogra_> the printserver one is actually nailed to the bottom of the printer table so you could say it keeps the furniture together at least :)
<cking> apw, http://uncyclopedia.wikia.com/wiki/Linux
 * ppisati -> lunch
 * tgardner bounces tangerine at the top of the hour
<ppisati> no patch applied to fsl-imx51 in 3 weeks?
 * tgardner reboots gomeisa for security kernel update
<herton> ppisati: yep, no new patches
 * herton having extra fun this morning with a dying hard disk
<ppisati> uhm
<ppisati> my natty repository is hosed
<ppisati> error: refs/remotes/origin/ti-omap4 does not point to a valid object!
<ppisati> why it happens?
<smb> because
<apw> ppisati, does your repo have an alternative (.git/objects/info/alternatives) and is it still there
<ppisati> apw: nope
<apw> then thats not normal
<apw> .git/objects/info/alternates <- sorry its alternates
<apw> ppisati, &&
<ppisati> [flag@newluxor ubuntu-natty]$ ls -la .git/objects/info/*
<ppisati> -rw-rw-r-- 1 flag flag 54 2012-01-26 14:51 .git/objects/info/packs
<ppisati> btw
<ppisati> it doesn't complain anymore now
<herton> ppisati: the maverick ti-omap4 pull is missing the tracking bug in the changelog
<joshhunt__> I've got a question about USNs if anyone can help. USN-1336-1 and USN-1342-1 provide the same patch. I see that 1342 applies to 10.04 and is a backport of oneiric. Is that the only difference?
<apw> ppisati, its stopped complaining, be afraid
<apw> joshhunt__, i believe that there is a USN per release yes, so thats entirly possible, touch you might like to confirm on #ubuntu-security
<ppisati> herton: sh*t! i was sure i ran the verify-release-check script
<ppisati> ah
<ppisati> herton: i had it local but i din't add/commit the change
<herton> ok, yeah sometimes happens :)
<joshhunt__> apw: thanks I'll check there
<ppisati> herton: ok, i fixed it now
<herton> ppisati: ack
<apw> ppisati, tgardner, they have just new'd linux-ti-omap4, am doing meta
<tgardner> apw, ack
<apw> ppisati, ok its in the pipe
 * herton -> lunch
<apw> ogasawara, so -8 -> -9 was 3.2.1 and "top down" coming in, the kexec vomit, and a small number of configs
<ogasawara> apw: definitely looks like some arm changes that went in
<apw> ogasawara, its a biggie, ppisati has a fun day ahead of him
<apw> ppisati, you might want to see if     UBUNTU: [Config] CONFIG_USB_FILE_STORAGE is deprecated
<apw> anything to do with it
<ppisati> ok, i'll do
<ogasawara> ppisati: keep us posted.  I'm planning one more upload anyways before the milestone, so I'll hold the upload until I hear from you.  I ideally want to upload by end of day tomorrow.
<ppisati> ogasawara: ok, i'll do
<tgardner> ogasawara, am running Precise master-next w/3.2.2 stable on several machines. seems OK so far.
<ogasawara> tgardner: cool.  was just about to do a build and test.
<ogasawara> tgardner: thanks for doing the rebase by the way.
<tgardner> ogasawara, I was motivated 'cause xfstests was causing some oops on  my emerald. gonna retry it this AM
<diwic> ogasawara, thanks for uploading the kernel yesterday, but is it normal for it to not be published at this time?
<ogasawara> diwic: normally it would have been built and published by now, but it seems powerpc is taking longer than usual to build.
<diwic> ogasawara, ok, so a little slower than usual, but no need to worry yet. Right?
<ogasawara> diwic: I hope not.  when I checked this morning powerpc was estimated to start building in about 2 more hours.
<diwic> ok.
 * ogasawara back in 20
<apw> tgardner, alt-F10 should toggle max by defualt it seems
<tgardner> apw, it maximizes, but down't minimize (which isn't a toggle)
<apw> tgardner, thats poo
<apw> documentation for this thing isn't worth a shit
<tgardner> apw, is this the correct invocation: sudo client/bin/autotest --output_dir=$HOME/autotest.wrk client/tests/xfstests/control
<apw> that should work if the control file makes sense
<apw> tgardner, the normal form is that, but remember the control files in the test directories are mean as samples
<tgardner> well, everything is failing at this point, but it does build the xfstests correctly
<apw> and you are meant to put together one representing the tests combinations you want to run
<tgardner> apw, the xfstests control file appears to be correct, but I did have to add TEST_DEV and TEST_DIR
<apw> tgardner, as the commentary there indicates, thats why they can only be seen as samples
<jsalisbury> tgardner, who is our omap expert, Palo?  bug 921934
<ubot2`> Launchpad bug 921934 in linux "mmc no longer detected on omap (BeagleXM) since 3.2.0.9" [Critical,Confirmed] https://launchpad.net/bugs/921934
<tgardner> jsalisbury, he is, and I think he's aware of this bug
<jsalisbury> tgardner, cool, thanks.  
<tgardner> ppisati, ^^
<__cr3> hi guys,i have a question.what do u guys expect from a fresher who wants to work in a company like canonical,redhat..etc which concentrates on kernel development...
<jsalisbury> smb, are you our virtual guy :-)  bug 921816
<ubot2`> Launchpad bug 921816 in linux "BUG: unable to handle kernel NULL pointer dereference at 00000030" [Medium,Confirmed] https://launchpad.net/bugs/921816
<mfilipe> hi guys! is there kernel-3.2 for oneiric?
 * apw calls it a day ...
<jsalisbury> smb, actually it's an EC2 issue
<arges> sforshee, could you hear me on mumble? 
<jsalisbury> arges, we can hear you
<sforshee> arges, we can hear you but you can't hear us
<arges> jsalisbury, sforshee yea I've had this problem for the last couple of weeks
<arges> let me try to fix it
<herton> ppisati: the oneiric ti-omap4 has a problem in the changelog, the email closing the change is outdated (and with extra <>)
<mfilipe> ogasawara, is there any kernel 3.2 for oneiric?
<ogasawara> mfilipe: not to my knowledge.  We only do the backport kernels for the previous LTS release.
<mfilipe> hum... thanks!
<ogasawara> mfilipe: if it's just for testing purposes, you could try installing the precise kernel in oneiric.
<mfilipe> no, I went a 3.2 official for oneiric. I didn't know that you won't backport kernels for oneiric and this is only for LTS release.
 * ogasawara bails for appointment, back in a bit
<ppisati> jsalisbury: yep, i'm already on it
<ppisati> herton: let me check...
<jsalisbury> ppisati, thanks
<lamont> herton: fwiw, -33 has been happy for about 24 hours
<lamont> I'm going to go to -35 a bit later today
<herton> lamont: hmm good to know. Points to a possible regression in the kernel indeed. I was playing with adjtimex, could help debugging in the bad kernel if it is indeed a kernel issue
<lamont> will advise
<ppisati> lpMMC on Beagleboard depends on TWL4030's GPIO lines, re-enable it.
<ppisati> See also:
<ppisati> ops
<ppisati> lp921934
<ppisati> bug 921934
<ubot2`> Launchpad bug 921934 in linux "mmc no longer detected on omap (BeagleXM) since 3.2.0.9" [Critical,Confirmed] https://launchpad.net/bugs/921934
<ppisati> ogasawara: ^^ - fix sent to the ml
<ogasawara> ppisati: ack, thanks.
<tgardner> ogasawara, pushed with some ABI directory module file corrections
<ogasawara> tgardner: cool thanks.  I was also going to add it to the config enforcer, just about have the patch done.
<tgardner> ogasawara, is that one worthy of enforcement ? I guess I don't know what it even does.
<tgardner> sconklin, xfstests: Failed 26 of 167 tests
<ogasawara> tgardner: we'll we'd flipped it to =m across the board per our review policy, so I'd like to have it in the enforcer so we don't forget and make the same mistake again.
<sconklin> Are you running the test list that I modified, or all tests?
<tgardner> ogasawara, ah, good idea.
<sconklin> see changes to control file
<patrickmw> bjf, I've run into all types of situations which is why I asked for more info
<tgardner> sconklin, I got tired of trying to get autotest to work, so I just ran ./check
<patrickmw> bjf, you have a few options here
<bjf> tgardner: i had no trouble getting it to work
<sconklin> tgardner: then you get to keep all the pieces. A bunch of the xfstest tests don't apply to ext4, so you have to set up a list of ones to run
<tgardner> I don't seem to be able to get any of the tests to run under the autotest umbrella
<tgardner> wonder what I've got wrong
<tgardner> sconklin, mostly I was looking for kernel crashes, which is why I ran everything.
 * cking bails out
 * tgardner -> EOD
<manjo> sconklin, SRU Question.. 
<manjo> will this patch make it in 11.10 though updates? or do I need to SRU it ? 
<manjo> commit c510eae377c773241ff0b6369a8f3581da941a51
<manjo> Author: Oliver Neukum <oneukum@suse.de>
<manjo> Date: Wed Sep 21 11:41:45 2011 +0200
<manjo>     btusb: add device entry for Broadcom SoftSailing
<manjo> ogasawara, ^ ? you know ? 
<sconklin> manjo: ask Brad or Herton, I'm on rotation to QA this cycle and I'm not following stable
<manjo> ah ok 
<manjo> bjf, ^ :)
<manjo> oops looks like its in 11.10 already ... 
<herton> manjo, it's included in 3.0.9, probably going in -proposed or already released
<manjo> herton, thanksa ton ... 
<herton> manjo, released in 3.0.0-14.23
<manjo> hmmm I seem to have 3.0.0.15 (that is what uname says)
<manjo> herton, sorry my bad... I think I messed up the IDs when I did a search
<Fudge> hi is this audio device supported in precise kernels Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) (rev 40)
<Fudge> been getting scratchy sound for first few minutes until seemingly extra audio streams come in
<ohsix> it wouldn't be showing up or making any sound if it wasn't supported
<Fudge> ok
<Fudge> so should ask pulse guys about scratchy sound?
<Fudge> thanks ohsix 
#ubuntu-kernel 2012-01-27
<jwi> jsalisbury: for the i915 edp regression in oneiric/precise, you might want to look into https://lkml.org/lkml/2012/1/25/203
<eQuiNoX__> hey guys
<larsk103> I have a weird problem with harddrives under the mpt2sas driver. When i do anything but 4k writes, the kernel reads from the drives before writing. These are 512 bytes sector drives, and the kernel seems to know this. Where can I report this?
<apw> ppisati, i see you found the MMC issue, nice
<ppisati> apw: yep
<apw> ppisati, did it take all night ?
<ppisati> apw: nope, i fnished yesterday around 21
<apw> ppisati, phew, i was worried you'd have to bisect and it'd take ages
<ppisati> apw: i prefer to do it manually
<ppisati> apw: there were modules that were more suspects than others
<ppisati> and i keep forgetting mumble in the morning...
<apw> t'is easy to do, i sometimes think i am using it when i am not
<ppisati> (EE) module ABI major version (10) doesn't match the server's version (11)
<ppisati> uhm
<RAOF> ppisati: What driver?
<RAOF> I thought I'd caught them all, but sufficiently badly-packaged drivers might have escaped me :)
<ppisati> RAOF: panda board
<ppisati> RAOF: let me upload the X log
<RAOF> That should use omapfb, right?  I thought that got a rebuild?
<RAOF> Thanks for the log.
<ppisati> RAOF: it's a dkms, the hw accelerated driver
<RAOF> That's the kernel driver; your error comes from the X server trying to load the DDX, which is different.
<ppisati> ah ok
 * ppisati is X ignorant...
<RAOF> Are your logs anywhere?
 * RAOF will go soon; it's 10pm
<ppisati> http://people.canonical.com/~ppisati/Xorg.0.log
<RAOF> Where does that come from?
<ppisati> RAOF: from my panda, dist-upgraded this morning
<ppisati> RAOF: http://paste.ubuntu.com/818693/
<RAOF> Where does that driver come from?  It doesn't appear to be in the archives.
<ppisati> RAOF: http://paste.ubuntu.com/818694/
<apw> RAOF, could it be a partner job ?
<RAOF> That's broken from the Xserver 1.11 transition.  It won't work until you rebuild it against the newer server.  Or, if it's closed-source, it won't work until PowerVR rebuild it against the new server.
<ppisati> well, it says: "pool/main/p/pvr-omap4/pvr-omap4_1.7.10.0.1.7-1_armel.deb"
<ppisati> do we have closed/outside world stuff in main?
<apw> ppisati, does this machine have any odd ppas on it
<ppisati> apw: let me check
<RAOF> âmainâ is the default component for PPAs.
<apw> its unlikely powervr is something we have source for, me thinks
<RAOF> This does indeed seem likely.
<apw> PowerVR SGX540 kernel driver for OMAP4 in DKMS
<RAOF> Also, is it really so hard to package X drivers?
<ppisati> yes, it comes from TI ppa
<apw> and the kernel driver isn't ... in the kernel
<apw> ppisati, ok so you need to get the arm folks to poke them to rebuild it
<ppisati> deb http://ppa.launchpad.net/tiomap-dev/release/ubuntu oneiric main #Added by so
<RAOF> We've got all this fancy dpkg-helper stuff!
<ppisati> ftware-center
<RAOF> ppisati: Yeah.  That driver's not going to work until it gets rebuilt against the new Xserver ABI.
<ppisati> got it
<ppisati> i'll poke them then
<ppisati> ogra_: ^^^
<RAOF> Consider it a tax on out-of-archive drivers ;)
<ppisati> rsalveti: ^^^
 * apw notes A2 is ... SOON
<apw> RAOF, i take it you have never been told there is a ti* wibble X driver to worry about
<ogra_> TI hasnt done an upload yet, not much we can do about this but pinging them (which happened)
<RAOF> apw: Indeed not.
<RAOF> Well, maybe I have, but I'd forgotten entirely.
<apw> ogra_, heres hoping you arn't gated on them for your A2 images
<ogra_> they are also working on an armhf version of the driver... 
<ogra_> apw, its a PPA driver ...
<apw> so presumably ppisati can remove it and get something working
<ppisati> cool, so i don't have to worry about it
<ogra_> indeed we arent depending on PPA stuff for oour images :)
<RAOF> Yeah.  I *did* check all the drivers in the archive.
<apw> i presume just his performance will suck
<RAOF> Although I would have missed a driver packaged as badly as that one - it doesn't even have a dependency on the X server!
<ppisati> apw: i personally prefer the server images
<ogra_> Ti doesnt manage to stick to our release schedule (their ubuntu team is to small) for that reason their stuff lives in the PPA
<ppisati> all the X/light/unity/$fancyferretgraphicstuff just slow down my board
<ogra_> as long as the xfbdev drver is working all is fine 
<ppisati> ogra_: that's working
<ogra_> (thats what we ship by default)
<ogra_> plan is actually to remove the PPA icon from the desktop as well and eventually get the pvr driver into the archive, but that hasnt happened yet and will need agreement from the TI side to stick to the release schedule (which is being discussed)
<RAOF> ogra_: Once it wanders archiveward, please give me a ping so I can fix up its packaging a little.
<ogra_> RAOF, i will ! thanks for the offer ... it will be multiverse anyway though (package has an EULA) 
<RAOF> That's fine.  I'd like to make sure it actually turns up on my sweep for drivers I'll break when changing Xserver ABI though :)
<ogra_> ah, indeed :)
<diwic> apw, still "Pending publication"...hmm...
<diwic> for 3.2.0-11.19
<apw> diwic, we were waiting on powerpc last night, i asked for it to be rescored
<apw> diwic, yay they are all there, will hastle someone
<apw> diwic, hopefully it'll be in shortly
<RAOF> Heh.  Poor powerpc
<apw> she is lagging and no mistake, even arm is getting done before her now
<diwic> apw, thanks a lot
<apw> diwic, ok ... they are accepted now, i'll go check meta
<ppisati> ppc hw is quite cheap nowadays, can't we throw more hw at it?
<ppisati> and, btw, why do we support ppc? :)
<apw> ppisati, i hear we have a box in house, waiting to be installed, but ... is is on the case
<apw> ogasawara, 3.2.0-11 now accepted, i've uploaded (your) meta
<_jmp_> ppisati: maybe one day Ubuntu will run on Playstation (ppc for now) as Game-OS :)
<apw> diwic, ok meta is now in the queue
<apw> diwic, so it should all be in the archive in about an hour
<diwic> apw, excellent
<ppisati> _jmp_: with only 256mb of ram? neeehhh... :)
<_jmp_> ppisati: PS4 maybe :D anyway... hi * :)
<ppisati> ogra_: on the beagle ml, people are reporting issue with beaglebone + armhf: kernel doens't boot, while O/armel was working fine
<ppisati> ogra_: http://groups.google.com/group/beagleboard/browse_thread/thread/370de0a4734bdd24/6a98b1623bf7a39d
<ogra_> ppisati, thats talking about images from elinux !
<ogra_> he rolls his very own kernel
<ogra_> talk to robert nelson ;)
<ogra_> (rcn_ee is his irc nick)
<ogra_> see the last mail in that thread
<ppisati> ogra_: acutally he says "BeagleBoardUbuntu#Precise_12.04_armhf_testing"
<ogra_> yes, that means he uses our userspace for his u-boot and kernel hackery
<ppisati> ogra_: he said he tried even upstream
<ogra_> i havent heard about issues from tobin with armhf on beagle yet, does he have different HW from yours ?
<ppisati> ogra_: don't think so
<ogra_> also note it doesnt talk about the beagle*board* at all
<ogra_> that thread is abotu the beagle*bone* (successor)
<ppisati> ogra_: yep i know
<ogra_> i dont think any of us has that HW
<ogra_> unless someone sends us some boes we wont be able to support it 
<ogra_> dont worry about it until we got some HW i'd say, we cant QA or test it at all without HW
<ppisati> k
 * herton -> errand+early lunch, back in +- 2h
<aquarius> cking, heya; any chance you have a bit of time to think about my u300s not suspending? (No problem if not, of course. :))
<davmor2> aquarius: it just hates you ;)
<aquarius> is a possibility, I admit it.
<cking> aquarius, quite frankly, i'm stumped by it - and our bios engineer is off on chinese new year at the mo
<aquarius> cking, there's a certain satisfaction that it's actually a real genuine problem and not just me, I suppose!
<aquarius> hibernate works (although I can't set the machine to hibernate from the gui, for reasons I do not understand)
<apw> (i am sure i asked this before, but i like to make sure) you don't have powernap installed do you
<aquarius> I doubt it, since I don't know what it is
 * aquarius checks
<aquarius> apw, I do not have it installed :)
<apw> and you don't take CPUs offline
<cking> apw, it's one of those mystery "hang" issues which exists outside of the kernel context
<smb> apw,  ogasawara, tgardner head up on bug 921816
<ubot2`> Launchpad bug 921816 in linux "BUG: unable to handle kernel NULL pointer dereference at 00000030" [Medium,Confirmed] https://launchpad.net/bugs/921816
<smb> Looks like seccomp patches are at fault
<eQuiNoX__> hey guys
<apw> smb, ok so not something thats critical, as nothing uses them ?
<smb> apw, No clue what is using them, but at least one thing from the seccomp qa regression tests does
<apw> smb, as far as i know the only thing that every _might_ use it is chromium-browser, but in the thread from the submitter there was an indication that it was not in use
<smb> apw, Yeah, seem we never heard anything before and it seems right now it may beonly triggered by the qa regression suite and maybe only on vms
<smb> Will test bare metal now
<apw> smb, sounds good, thanks
<tgardner> smb, will drewery had a new patch set proposed on the list awhile ago, but the upstream discussion was so lengthy that I chose to wait a bit.
<smb> tgardner, right, I have gone forward and made a kernel with all old seccomp patches reverted and his new version applied. That one seems not to cause a crash but some subtests to fail
<smb> (which could be because its not implemented or different or. ...)
<apw> definatly should ask kees and will about that, as we want to be on whatever he is upstreaming
<tgardner> apw, right. they ought to be online in a couple of hours
<smb> tgardner, apw I'd reply to will's mail to us. Just want to have the info about the old patcheset and the tests verified before I do
<apw> sounds ike a plan to me
<rsalveti> ogra_: ppisati: that abi incompatibility was expected 
<rsalveti> TI was just waiting the upload to happen to release a newer driver
<rsalveti> let me send an email to xavier so he can push it to the PPA
<ogra_> do you think they will do it before A2 ?
<rsalveti> and also request the armhf one
<ogra_> (would be helpful indeed)
<ogra_> i pinged nicolas about it but have no answer yet
<rsalveti> ogra_: generally xavier is quite fast on uploading a newer version
<ogra_> ah, great
<rsalveti> we'll see
<ogra_> yep
<rsalveti> let me send the email :-)
<ogra_> thanks !
<ogra_> :)
<eQuiNoX__> hey guys, it would be great if you could spend a minute to help me out here => http://askubuntu.com/questions/98995/system-programming-in-ubuntu. thanks for your time!
<ogasawara> smb: thanks for the note.  I believe that jjohansen was looking into the seccomp qa regression test failure.
<smb> ogasawara, Ah ok. Right now it seems to be reproducible on 64bit vm and bare metal and causing an oops. Just gathering more date about i386 and comparing to oneiric
<smb> ogasawara, Right, so oneiric seems to be ok. There is one failure of the tests for libcap but that is likely rather the test incorrect (/me hopes)
<jjohansen> smb: yeah hggdh opened Bug #921816 for it
<ubot2`> Launchpad bug 921816 in linux "BUG: unable to handle kernel NULL pointer dereference at 00000030" [Medium,Confirmed] https://launchpad.net/bugs/921816
<jjohansen> I haven't looked at oneiric yet
<smb> jjohansen, right. jsalisbury pinged me about that
<smb> jjohansen, Just did a run
<jjohansen> I had been holding off on the new version of seccomp waiting on the discussion
 * jjohansen doesn't actually expect we will carry the older version
<smb> jjohansen, Right now it looks like someting in precise together with the seccom patch is bad
<smb> jjohansen, Yep, I build a test kernel with the new version
<jjohansen> yeah
<smb> jjohansen, looks better but fails some subtests
 * smb is about to fire of a mail thread
<jjohansen> yeah, thanks for doing that I keep meaning to but ..
<smb> jjohansen, no worries. mail is out. btw, running test-kernel-security.py on oneiric I got one fail in the last test that tries to check for libcap (oneiric would have libcap2) and fails. It is less of a worry but probably should be looked after
<jjohansen> right
 * smb sent mail without waiting for slooooow i386 to finish update all other stuff...
<jjohansen> hehe, understandable
<ogasawara> tgardner: are you updating chroots on gomeisa by chance?
<tgardner> ogasawara, rebuilding them since they seem to have gotten borked. lemme go check on 'em
<ogasawara> tgardner: ok cool.  got some random error when trying to chroot into precise-amd64, so I'll just wait.
<tgardner> ogasawara, you might want to use tangerine. gomeisa seems to have a file system issue.
<ogasawara> tgardner: ack
<apw> tgardner, oh that sounds bad
<tgardner> apw, 20copyfiles: cp: not writing through dangling symlink `/var/lib/schroot/mount/precise-armhf-5b681eba-8a44-4335-a08e-f089dc799848/etc/resolv.conf
<apw> tgardner, isn't that a security thing, one of kees
<apw> tgardner, as in something valid, not broken FS
<tgardner> apw, a change in behavior then? this is a 3.0 kernel
<tgardner> and what is a dangling symlink ?
 * apw looks for the thing he is thinking of
<apw> tgardner, ok, i think i am thinking of hardlink things
<apw> tgardner, but a dangling symlink is just a symlink that points to a non-existant place
<tgardner> apw, yeah, I don't see anything in yama
<apw> and that directory there no longer exists cause its an schroot place
<tgardner> apw, the failure was on armel, so perhaps I should check that the x86'en chroots recreated OK.
<apw> i suspect that that may be being triggered by the resolvconf transition.  that changes your resolv.conf into a link i think
<tgardner> apw, ah, 'cause i386 has the same issue.
<apw> see if the resolv.conf is a symlink inside the chroot
<tgardner> apw, you mean precise is now a symlink? hmm
<tgardner> apw, well, its a link on my desktop. resolv.conf -> /run/resolvconf/resolv.conf
<tgardner> apw, I think this is actually a schroot problem with /etc/schroot/sbuild/copyfiles
<apw> tgardner, hmmm, well that just lists the files to copy
<tgardner> apw, right. its actually /etc/schroot/default/copyfiles
<apw> even that is just a list of files
<tgardner> which is used by /etc/schroot/setup.d/20copyfiles
 * ppisati -> the dove kernel is backing on tangerine, back in a bit
<tgardner> I think I'll ask on #ubuntu-devel. surely they have encountered this issue already.
<apw> etc/resolv.conf -> /run/resolvconf/resolv.conf
<apw> no i think this is the bug
<apw> that should not be an absolute link
<apw> it should be etc/resolv.conf -> ../run/resolv.conf
<apw> it should be etc/resolv.conf -> ../run/resolvconf/resolv.conf
<apw> the second one ...
<apw> so that it works in chroots from outside ... as the copy (20copyfiles) has to work from outside to see both files
<tgardner> apw, well, only if /run is mounted within the choot
<apw> run should be unique to the chroot right?  even if its not adding one, the directory should work
<tgardner> apw, so you think the ultimate bug is in the resolvconf package ?
<apw> i think its odd to use an absolute link like that ever, so i'd query if thats legal for this exact reason
<tgardner> apw, ack
<apw> if it is, then 20copyfiles needs to read all the links it finds and map / to the chroot
<apw> or use something more like 'cat source | chroot FOO cat - >destination
<apw> to do the copy
 * ogasawara back in 20
<tgardner> ogasawara, you're making tangerine squeal.
<ogasawara> :)
<apw> ogasawara, 420 ... ouch
<apw> "420:1 and falling" "344:1 and falling"
<ogasawara> bjf: there's complaints that rls-p-tracking-bugs.html is broken...
<smb> apw, Guess when its one anything else is our own problem
<apw> smb, :) indeed
<bjf> ogasawara: naturally
<apw> bjf, let me guess this is the first you have heard of it
<bjf> apw, yup
<ogasawara> I think this if the first people were aware (ie have looked at the page)
<bjf> ogasawara: let whomever know i'm looking into it
<ogasawara> bjf: will do
<ogasawara> bjf: it was pointed out in the release meeting
<bjf> ogasawara: figured as much
<ppisati> herton: what's the status of the lucid/master? is it ok? can i go ahead and rebase?
<herton> ppisati, yep, you can go ahead
<bjf> ogasawara: the report is back
<ogasawara> bjf: thanks
<brendand> tgardner - hi
<tgardner> brendand, hmm?
<apw> ogasawara, i just pushed an ipv6 config change onto your tree
<brendand> tgardner - do you think it would be important to test different wireless frequencies as well as different bands (e.g. 2.4Ghz and 5Ghz)?
<tgardner> brendand, not particularly, no.
<brendand> tgardner - cool
<tgardner> ogasawara, gomeisa should be back to normal in 10 mins or so
<ogasawara> apw: ack, thanks
<ogasawara> tgardner: k, I'll hammer on it next
<apw> ogasawara, it doesn't need to go in for A2 if you have already tested, it can happily wait for upload#1 after
<ogasawara> apw: cool, I think I'll let it wait then since I've just finished my test builds.
<apw> in fact not putting it in given all the other instability we have ...
<tgardner> ogasawara, gomeisa is ready to bend to your will.
<ogasawara> tgardner: thanks!
 * ogasawara debates ripping out all the seccomp patches for the Alpha-2 upload
<tgardner> ogasawara, it can't be any worse then the current situation.
<tgardner> ogasawara, and having just read the email list, kees agrees.
<arges> hey. i'm getting this odd error on my t420 where when I resume from suspend, it then re-suspends. is there a wiki on how to get verbose suspend info? or should I just file a bug and go from there. 
<arges> its somewhat rare for me. but annoying when it happens.
<tgardner> arges, you just missed cking, but I remember that the double suspend used to be a problem.
<tgardner> I can't remember what was causing it.
 * apw calls it a day ...
<ogasawara> tgardner: was that the same issue cking and him were debugging in budapest?
<tgardner> ogasawara, I don't recall if that was it.
<tgardner> seems like the double suspend issue was in Oneiric
 * tgardner -> lunch
<cking> gah, my AP is a pile of unreliable do do
<smb> cking, nah that is the new "this is the weekend" feature. :)
<arges> cking, hey! having some wierd double-suspend issues with my t420. are there some bugs I should look at? or verbose info I can get to see what the problem is?
<cking> arges, double -suspend? what's that
<arges> cking, sorry, so when I wake my laptop up. it resumes suspend. I see the login, but then it immediately goes back into suspend 
<arges> its not every time, so i occasionally hit this
<arges> but I want to get better info on it, so I can file a good bug / start looking into it
<cking> arges,  file a bug - then when it happens attach the dmesg output and the /var/log/pm-suspend.log so it can be eye-balled
<arges> cking, ok. will do
<ogasawara> arges: this is a wiki I found, but not the one I was thinking of...https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Debugging_Suspend
<arges> ogasawara, ok cool i'll read though this one too! thanks
<herton> arges, I remembered/found another one too, this may be useful, an excellent instrumentation cking did using systemtap, for debugging suspend: https://wiki.ubuntu.com/Kernel/Reference/S3SystemTapDebug
<ogasawara> tgardner: I'm ripping out the seccomp patches.  I've still got enough time to build, test, and upload.
<herton> but it would be more intended for the case of a hang
<cking> herton, this is kinda useful for hangs, but I'm unsure how useful my S3 scripts will be for a bounce
<herton> indeed
<arges> herton, ok that might be good for some deep debugging. i'll try to get a bug filed with dmesg / log info when I hit it again. thanks
<cking> arges, does google show anything useful, you can't be other other user running ubuntu on this machine?
<arges> cking, not sure what you mean by that.  i'm the only user on this machine 
<cking> arges, i meant, there must be loads of other people with this machine on the planet running ubuntu, so if it's a common issue you may find it with google ;-)
<arges> cking, yea i'll do that first
<cking> search is your friend ;-)
<cking> somebody make bzr run faster please!
<tgardner> ogasawara, ack
<jcastro> Hi, I'm looking for the generic backported compat-wireless package for oneiric, I think it's this one but it looks too specific to be the generic metapackage: http://packages.ubuntu.com/oneiric-updates/linux-backports-modules-cw-3.1-3.0.0-15-generic
<bjf> jcastro: i think you are looking for linux-backports-modules-3.0.0
<chrxn> Hail, Sages!
<chrxn> I am trying to compile with 1000hz timing in EC2 for use with VOIP. I'm using some instructions that I found for doing this, but I have hit a wall, and I don't know how to continue exactly.
<chrxn> This is the error ( http://pastebin.ca/2106891 ) I've encountered after following these instructions ( http://tinyurl.com/875emvt )
<ohsix> if the ec2 vm's can do hrtimers HZ is going to be somewhat moot unless you end up depending on a driver (loool virtual machine) that still relies on jiffies
<chrxn> So, even if this could be acheived,  and it could most likely by a more experienced person than I, it would be of little consequence?
<ohsix> yep
<chrxn> Thank you, oh sage.
<ohsix> you can see what sort of timers are being used by userspace software and kernel threads in /proc/timer_list
<chrxn> This is way over my head. It only took a jiffy of talking to you to know that my efforts are futile in doing this thing.
<chrxn> I will keep the kernel as-is.
<chrxn> Thanks for your guidance ohsix 
<ohsix> no problem
#ubuntu-kernel 2012-01-28
<kees> ogasawara: wheeee. 3.2 kernel just as I was needing features only in 3.2 :)  thanks :)
<ralphcor> I'm on 10.10 so manually purging old kernels doesn't do a dkms clean-up.  I'd like to know the correct way of doing so.  https://answers.launchpad.net/ubuntu/+source/dkms/+question/185568 hasn't really helped and Google knows little.  I thought a Launchpad Answer might help others Googling in future.
#ubuntu-kernel 2012-01-29
<shawn1> Hello
<shawn1> I've been trying to get my GTX 295 and GTX 460 SE to work on my system, but my system seems to be able to detect only half of the GTX 295
<shawn1> most times, my xserver won't even start up
<shawn1> I've contacted NVIDIA about this issue and have worked with them and they said that it's a kernel problem
<ohsix> using noveau?
<shawn1> proprietary
<ohsix> so the detection of the second card was said to have been a kernel problem
<shawn1> yeah
<shawn1> because lspci was only showing half of it
<shawn1> in the kernel log
<ohsix> did they give you any references or just say that it's a kernel problem because of lspci
<shawn1> I think it was trying to detect something on the address and it was trying to detect frequencies of 2,142 or up and if it's referring to memory frequency, the GTX 295 is just below 2Ghz
<shawn1> uhm
<shawn1> m
<shadows> I've got a POSIX programming puzzle that I'm trying to work out for Linux, has to do with termios and signals...  what's the appropriate channel to discuss?
<shadows> hint it's not school work ;  I have two programs and one of them returns from select() when I access a pseudo terminal, the other does not ;  I can see no clear difference in what each program is actually doing
<shadows> oh...  one of the programs *sets* errno
 * shadows facepalms
<ralphcor> I'm on 10.10 so manually purging old kernels doesn't do a dkms clean-up.  I'd like to know the correct way of doing so.  https://answers.launchpad.net/ubuntu/+source/dkms/+question/185568 hasn't really helped and Google knows little.  I thought a Launchpad Answer might help others Googling in future.
<anon^_^> Hi, sorry to bother chan, I was curious if the linux power regression was ever dealt with through a kernel SRU for 11.04 and 11.10
<anon^_^> http://www.phoronix.com/scan.php?page=article&item=linux_aspm_solution&num=1
#ubuntu-kernel 2013-01-21
<langka> cara mainin ini gimana
<ppisati> moin
<smb> ppisati, ciao
<ppisati> smb: hey Stef, freezing? :)
<smb> ppisati, No, should I? :)
<ppisati> smb: i head it's pretty cold up there
<ppisati> *heard
 * smb knows the concept of snow, contrary to most people in this other country
<apw> ppisati, moin
<ppisati> apw: moin
<psivaa> jsalisbury, our daily smoke tests are hit by bug 1100386. It would help if we know the ETA of a fix. thanks
<ubot2> Launchpad bug 1100386 in linux (Ubuntu) "Raring server installations on VMs fail to reboot after the installations" [High,Confirmed] https://launchpad.net/bugs/1100386
 * henrix -> lunch
<brendand> bjf, when is the next kernels going to be built?
<brendand> s/is/are/
<henrix> brendand: we're skipping this cycle due to the .2 release.  i guess next cycle wont happen before the 1st week of Fev
<brendand> henrix, are you waiting until after .2 is released or something?
<henrix> brendand: yes, that's the info i have. here's the email on the kernel mailing list: https://lists.ubuntu.com/archives/kernel-team/2013-January/024883.html
<henrix> brendand: so, i guess the idea is to get some more testing on the current kernels
<henrix> brb
<bjf> brendand, i hoping that the next cycle will start feb 7th though it may be after that. we'll have to see when .2 is "in the can" and we can put new kernels into -proposed
<bjf> brendand, we know that there will be a respin of quantal and lts-quantal at this point. we are working on a regression right now.
 * ppisati -> gym
<sforshee> apw, about?
<Kano> hi, where is the source for linux 3.5.7.3?
#ubuntu-kernel 2013-01-22
<bjf> kano:  git://kernel.ubuntu.com/ubuntu/linux.git linux-3.5.y
<nuxninja> hello
<ppisati> moin
<apw> moin
<smb> good morning apw ;-P
<psivaa> apw: smb: hello morning, would you know if anyone is looking at the issue in bug 1100386 ?
<ubot2> Launchpad bug 1100386 in linux (Ubuntu) "Raring server installations on VMs fail to reboot after the installations" [High,Confirmed] https://launchpad.net/bugs/1100386
<smb> psivaa, I think I had a quick look there yesterday and it seemed Joe was on it to some degree (or I got distracted and just forgot about it)
<psivaa> smb: ok thanks, it would be helpful, daily smoke is getting hit with this bug
<smb> psivaa, btw, just for future reference, I find it more helpful to have text files attached uncompressed. That gives you a bigger chance that I will actually look at them because I don't have to save them before that. ;)
<psivaa> smb: ack, ill remember that
<apw> psivaa, so this is server images only ?
<apw> ppisati, and is this xen or kvm, virtmanager can be either
<smb> Oh and is that virt-manager with xen or kvm or what?
<smb> psivaa, Hm, and not sure it is already in the report: how are those installs done? netboot /maas or really using any isos?
<apw> jodh, hey we have a case here where upstart is aborting, and dumping core, that seems utterly specious as the machine will panic instantly and not sync the dump
<apw> https://launchpadlibrarian.net/128694653/VBox_kernel_panic_i386_recovery.png
<psivaa> apw: smb: that is only for server images
<psivaa> it could be observed on both virt-manager and virtualbox as stated in the bug and the installation is using isos i did not use netboot or mass but preseeded and manual iso installations
<apw> virt-manager using KVM or virt-manager using Xen as the virtualisation tech ?
<psivaa> apw: virt-manager using KVM
<ppisati> brb
<rbasak> apw: hey, any known bugs with overlayfs and armadaxp? I have a regression between precise and quantal, looks like it affects raring as well.
<rbasak> Doesn't affect highbank
<rbasak> (in precise and quantal, not checked raring)
<apw> rbasak, nope, overlayfs is generic and used on other arm platforms ok
<rbasak> apw: I'll file a bug then. Thanks!
<apw> rbasak, what sort of regression is it ?
<rbasak> apw: it's broken :) http://paste.ubuntu.com/1558509/ - "mv" doesn't work for existing files in lowerdir. This breaks sbuild which is how I noticed it.
<apw> rbasak, what filesystem type is / in this case ?
<rbasak> apw: aha. That might be different between my armadaxp and highbank installs!
 * rbasak looks
<rbasak> apw: ext4 on both, but with slightly different options
<rbasak> armadaxp: /dev/sda2 / ext4 rw,relatime,data=ordered 0 0
<rbasak> highbank: /dev/disk/by-uuid/02fcfe14-c5ec-4371-9d59-7da564b2b428 / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0
<apw> rbasak, user_xattr is likely your problem
<rbasak> I'll try ripping that out now
<apw> perhaps the armadaxp is missing support for them in the kernel config (assuming you cannot just turn them on)
<rbasak> apw: one of us has this backwards. armadaxp does not have user_xattr but does have the issue. highbank does have user_xattr but does not have the issue
<apw> as the last thing it does before that error is:
<apw>         err = vfs_setxattr(newdentry, ovl_whiteout_xattr, "y", 1, 0);
<rbasak> Both fstabs are identical
<rbasak> I think I might follow you now.
<apw> rbasak, that is consistent, you likely need xattrs for userspace enabled which is what that flag enabled
<apw> so i suspect that some XATTR related config option is off in the kernel config
<rbasak> I see
<rbasak> # CONFIG_EXT4_FS_XATTR is not set
<rbasak> Should overlayfs be #ifdef'ing that vfs_setxattr line?
<apw> nope, it need to mark it as a whiteout, that is what i uses, xattrs
<apw> it should be on, your config is spack
<rbasak> Then overlayfs should refuse to mount with an upper dir without xattr enabled surely?
<apw> well some of its functionality works, so perhaps, perhaps not
<rbasak> OK fair enough
<apw> if it hurts, stop
<rbasak> So what do we do to fix this? Raring - enable it? And Quantal?
<apw> fix the config
<apw> it is wrong in both
<rbasak> Is an config change SRU acceptable for quantal?
<apw> it fixes a bug, so i can't see a reason to say no, it is enableing something whihc is on in _all_ other configurations
<rbasak> It is nice for sbuild to work on armhf for development work as reinstalls take ages.
<rbasak> OK. Do you need a bug filed?
<apw> so its not something to be scared of
<apw> bug> yes, as all srus need them
<rbasak> OK I'll do that now.
<rbasak> apw: thanks. You just saved me hours of tracking this down. I would have started a bisection :-/
<apw> rbasak, always worth asking
<apw> psivaa, just did an install using virtmanager with xen and that worked just fine
<psivaa> apw: ok, i have not tried with xen though, could it be then KVM related?
<apw> psivaa, could be, though less likely when you say virtual box has the issue too
<apw> rbasak, as overlayfs doesn't work that means we have never tested livecds with this h/w
<psivaa> apw: yes virtual box had the issue, and is your installation amd64 or i386 server?
<smb> psivaa, Perhaps you could provide us with the seed file and the steps to apply that to the install in the bug report?
<rbasak> apw: not sure there is a live cd for armadaxp :)
<apw> psivaa, i did a 64 bit install on a 64bit raring host
<einonm> Hi, is there an easy way to remove old self-compiled kernel files from an ubuntu install? I used 'make modules_install install' to install them.
<psivaa> smb: apw: ok, the panic occurred with both amd64 and i386 installs on amd64 host. Although the occurrence is more frequent on i386 installs. Ill add the preseed and steps for auto installs in the bug anyway
<smb> einonm, Depends on whether you made the version numbers simple to be recognized... rm -rf is simple
<einonm> smb: It's a linux-next tree, and I know where most of the files are, like /lib/modules and in /boot. But there's grub2 scripts that have changed also.
<smb> einonm, No, just re-run update-grub after you removed the files from /boot
<einonm> ok, I've been doing that - I hoped there was a ready made way. thanks
<rbasak> apw: filed https://bugs.launchpad.net/ubuntu/+source/linux-meta-armadaxp/+bug/1102970 - should that be linux-armadaxp or linux-meta-armadaxp or something else?
<ubot2> Ubuntu bug 1102970 in linux-meta-armadaxp (Ubuntu) "Missing CONFIG_EXT{3,4}_FS_XATTR breaks overlayfs" [Undecided,New]
<rbasak> ubuntu-bug led me to linux-meta-armadaxp which seems wrong to me
 * henrix -> lunch
<apw> jodh, hey ... so are we using upstart in the initramfs now ?
<jodh> apw: no.
<jodh> apw: the problem is bug 1096531. I've fixed this upstream, but it's not in Ubuntu yet.
<ubot2> Launchpad bug 1096531 in upstart (Ubuntu) "After touch /forcefsck and reboot: Assertion failed in log_clear_unflushed" [High,In progress] https://launchpad.net/bugs/1096531
<psivaa> smb: apw: i have just attached a preseed file to the bug 1100386 with steps 
<ubot2> Launchpad bug 1100386 in linux (Ubuntu) "Raring server installations on VMs fail to reboot after the installations" [High,Confirmed] https://launchpad.net/bugs/1100386
<jodh> psivaa/apw: I'm looking at doing a cherry-pick fix for bug 1096531 today.
<ubot2> Launchpad bug 1096531 in upstart (Ubuntu) "After touch /forcefsck and reboot: Assertion failed in log_clear_unflushed" [High,In progress] https://launchpad.net/bugs/1096531
<psivaa> jodh: ack, thanks
<apw> jodh, ok so the issue is actually reproducible on random boots of the installed image, could that still be that bug ?
<jodh> apw: I'm sure this is the same issue. See comment https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1096531/comments/4 for the triggering factors.
<ubot2> Ubuntu bug 1096531 in upstart (Ubuntu) "After touch /forcefsck and reboot: Assertion failed in log_clear_unflushed" [High,In progress]
<jodh> psivaa/apw: ... but to be convinced, could you please try the workarounds in #5 to see if you can still reproduce the problem?
<apw> jodh, ok just added --no-log to the kernel command line, and it is still reproducible
<jodh> apw: are you sure? the failure is coming from the logger code which should not be used with that option.
<apw> jodh, it is definatly getting to upstart as --debug emits lots of upstart output
<apw> jodh, yes, confirmed that --no-log is in the boot options always (added to /etc/default/grub)
<apw> and on 1 boot in 2 (ish) i get this hang, so this is probabally not the issue you see i recon
<apw> jodh, so my symptoms are the boot just stopping, immediatly after the fsck output
<jodh> apw: that must be a different issue. What environment are you seeing this problem in?
<apw> jodh, i've only seen it with server cd installs booted under kvm
<apw> jodh, this is occuring in my installed image on around half my boots
<jodh> apw: what's the cpu usage for the kvm process when it hangs? Is it spinning do you think?
<apw> jodh, if i strace the kvm process it is waking up on a 1s basis and doing a small ammount, not spinning
<apw> jodh, just did a boot with --verbose and it definatly is in upstart, i see the upstart bridge start then it clears the console and does the fsck, and wedged
<sforshee> apw, I bisected the wireless problem and found a commit from broadcom that introduced a bug, so it's not a ucode issue after all
<sforshee> apw, they've supplied a patch, care to test it?
<apw> sforshee, sweet, it is pissing me off regularly
<apw> sforshee, YES :)
<sforshee> apw, http://people.canonical.com/~sforshee/brcmsmac-txstatus-build/
<sforshee> I'm about to give it a spin on my machine, but it looks like it should get the job done
<cking> nice one
<jodh> apw: can you try booting to a shell, remounting rw, removing /forcefsck, then rebooting?
<apw> jodh, i doubt it even has that file, but will check
<apw> jodh, yeah that forcefsck is _not_ there, so this is not that, whatever it is
<jodh> apw: when did your problem start?
<apw> jodh, i am booting todays images, i am only aware of it from today, i have no information from before
<apw> jodh, i am only aware because it was reported as above by psivaa 
<apw> jodh, be i think they imply it is a recent issue
<apw> jodh, is there any further debug i can ask for above --debug ?
<jodh> apw: no. can you get a serial console log though?
<apw> jodh, maybe
<apw> jodh, ok it is possible to add the serial being logs
<apw> jodh, but when i log the output to there as well it doesn't reproduce any more
<apw> jodh, any other ideas ?
<jodh> apw: you could boot to a shell, remount / rw then create tty8.conf to "start on startup". That should allow you to login and see the status of the existing jobs.
<jodh> apw: does friendly-recovery work btw?
<apw> jodh, i am a kernel engineer :)  what the heck is that
<apw> jodh, i am just using the rare good boot to change things
<jodh> apw: select the "recovery" option on the boot menu :)
<apw> oh that i've used a few times, always successfully
<jodh> apw: it would be worth trying as that *is* actually being started by upstart.
<apw> jodh, ok i have done two of those and get to the menu and select 'continue normal boot'
<apw> jodh, and it boots fine, i will do a coupkle more, but i just got 
<apw> initctl: Event failed
<apw> on the console
<apw> jodh, could that be indicative of a lost event?
<jodh> apw: probably related to a failed job. We really need to see the console log.
<apw> jodh, cannot get it for you without losing the issue
<jodh> apw: can you try the tty8 trick? atleast then you should be able to login and sniff around.
<apw> jodh, that sounds good, what the heck is it
<jodh> apw: see above. Either create tty8.conf or modify tty[1-6].conf to 'start on startup' and reboot.
<jodh> apw: make that tty[2-6].conf.
<apw> ack
<apw> jodh, ok i seemed to have a login on tty8 when it booted normally, but in the 'broken' state i do not
<apw> though i did see init: debug for many 100s of lines before the occurance
<apw> jodh, so now i am very confused
<jodh> apw: how about booting without --debug and seeing if you can login in the wedged state: we can still see that job state then.
<apw> ok
<jodh> apw: I've got a fully up-to-date server and can't reproduce what you're seeing. A list of jobs would also be useful. I'm going to do the cherry-pick now, but could you raise a bug on this so we can track it?
<davmor2> hey guys is there a guide on debugging bluetooth issues anywhere I have a new Lenovo Ideapad y580 and the bluetooth constantly say Bluetooth is disabled whether it is on or off.
<apw> jodh, ok i still have nothing on /dev/tty8 odd
<jodh> apw: could this be a weird udev issue maybe?
 * ogasawara back in 20
<apw> jodh, it could indeed, bloody thing
<thotypous> hi, which should be marked duplicated of which? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101797  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101355
<ubot2> Ubuntu bug 1101797 in linux (Ubuntu) "On shutdown: âumount2: Device or resource busy, umount:/dev/sda2 busy - remounted read-onlyâ appears" [Undecided,Confirmed]
<ubot2> Ubuntu bug 1101355 in linux (Ubuntu) "can't umount home partition on 3.5.0-22-generic (works on 3.5.0-21-generic)" [Medium,Confirmed]
<jsalisbury> thotypous, 1101797 should probably be marked as a dup of 1101355
 * jsalisbury notices a famous guest on http://ubuntuonair.com/
 * ppisati goes out for a bit...
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 29th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jodh> psivaa: I'm just testing the fix for bug 1100386, but having issues on my SSD system. Looks like a kernel bug as opposed to an Upstart issue, but it's looking now like it'll be tomorrow realistically before the fix is uploaded to allow time to investigate.
<ubot2> Launchpad bug 1096531 in upstart (Ubuntu) "duplicate for #1100386 After touch /forcefsck and reboot: Assertion failed in log_clear_unflushed" [High,In progress] https://launchpad.net/bugs/1096531
<psivaa> jodh: ok thanks for the information, i assume you've seen the nomodeset related information that was added to the bug
<smb> Probably something in the cirrus drm module (or related). Not sure whether that can explain the virtualbox hang as well. 
<smb> Depends a bit what gfx hw they emulate. Xen for example has uses some different pci ids which do not cause the drm module to load. And I could not make it hang there.
<jodh> psivaa: yes - there seem to be 2 problems here.
<bguthro> I'm trying to google for the answer to this, but probably haven't gotten the right keywords. Is the ubuntu-raring.git repo planned on shipping with 3.8 - or will development continue to 3.9?
<ogasawara> bguthro: we'll ship Raring with a v3.8 kernel
<bguthro> ogasawara, thank you - much appreciated.
<ogasawara> bguthro: we'll eventually open a Raring+1, ie a 13.10 kernel, which will continue tracking the latest kernel, eg a 3.9 kernel once it opens
<bguthro> ogasawara, thanks. That seems to be a trend (or at least has been for the past 3, or 4 releases where I've been paying attention) - Is this done for all releases, or just the .04 releases?
<ogasawara> bguthro: it's something we try do for all releases, just makes maintenance going forward easier
<bguthro> ogasawara, understood. Thanks for the explanation.
<jsalisbury> bjf, herton, bug 1101666 appears to be a regression in Precise and Quantal related to inotify.  A bisect may be possible, just wanted to give you a heads up.
<ubot2> Launchpad bug 1101666 in linux (Ubuntu) "inotify fd leak" [Medium,Incomplete] https://launchpad.net/bugs/1101666
<bjf> jsalisbury, if you can get that identified "soonish" we can get that fixed for the point release. we (ogasawara) is working another regression at this time.
<jsalisbury> bjf, ack.  I'll kick off a bisect
<herton> jsalisbury, also this looks like related to the sauce/upstream fsnotify patches. Someone posted two day refering to two other bugs (1101355, 1101797). It looks related, so perhaps to cut time you can revert just the fsnotify patches and ask for testing.
<herton> *today
<jsalisbury> herton, ack, I'll do that.
<bjf> arges, you have any thoughts on bug 1101666
<ubot2> Launchpad bug 1101666 in linux (Ubuntu Quantal) "inotify fd leak" [Medium,In progress] https://launchpad.net/bugs/1101666
<arges> bjf: hi looking
<arges> bjf: jsalisbury : so which set of fsnotify patches are you reverting? the last set i cherry-picked from upstream
<jsalisbury> arges, yes, but just to build a test kernel for bug 1101666.
<ubot2> Launchpad bug 1101666 in linux (Ubuntu Quantal) "inotify fd leak" [Medium,In progress] https://launchpad.net/bugs/1101666
<arges> ok
<jsalisbury> bjf, arges, there seems to be another set of patches in comment #6 of bug 1101355 
<ubot2> Launchpad bug 1101355 in linux (Ubuntu) "can't umount home partition on 3.5.0-22-generic (works on 3.5.0-21-generic)" [Medium,Confirmed] https://launchpad.net/bugs/1101355
<bjf> jsalisbury, are you chasing both Precise and Quantal or focusing on one?
<jsalisbury> bjf, I figured I'd build a test kernel for both since there are reports for both
<bjf> jsalisbury, ack
<jsalisbury> bjf, for the revert anyway
<jsalisbury> bjf, hmm, I'm getting an ABI error during the build after reverting the patches:
<jsalisbury> II: Checking for changes to ABI...
<jsalisbury>     HASH : fsnotify_destroy_mark                    : 0x6f87a911 => 0xe80f7610
<jsalisbury>     HASH : fsnotify_alloc_group                     : 0xef67e06f => 0x81e56199
<jsalisbury>     HASH : fsnotify_init_mark                       : 0xfbfedde7 => 0x0098ed67
<jsalisbury>     HASH : fsnotify_add_mark                        : 0x82789f61 => 0x72e1be12
<jsalisbury>     HASH : fsnotify_put_group                       : 0x9ad3a0b6 => 0x95f2960e
<jsalisbury>     HASH : fsnotify_put_mark                        : 0x67507862 => 0x9e5033ad
<jsalisbury> EE: 6 symbols changed hash and weren't ignored
<jsalisbury> II: Module hash change summary...
<jsalisbury>     vmlinux                                 : 6
<jsalisbury> II: Done
<jsalisbury> make: *** [abi-check-generic] Error 1
<bjf> jsalisbury, i can believe that though i've not looked at the patches
<bjf> jsalisbury, is this P or Q that you are talking about?
<jsalisbury> bjf, what I posted above was from P.  But it happens to both P and Q
<bjf> jsalisbury, is 3.2.0-36.56 good or bad?
<jsalisbury> bjf, bad
<bjf> jsalisbury, and 3.2.0-36.57 is also bad?
<jsalisbury> bjf, actually 3.2.0-36.57 is bad.  I'm not sure about .56, but I can check
<bjf> jsalisbury, that would be best to try first
<jsalisbury> bjf, ack, testing 3.2.0-36.56 should be the same as reverting the fsnotify patches, correct?
<bjf> jsalisbury, it changes one set of fsnotify patches for another
<jsalisbury> bjf, right, got it.
#ubuntu-kernel 2013-01-23
<ricardo-he> hay
<ppisati> moin
<jodh`> apw: I think I may be seeing the same problem we discussed yesterday where your server dies on boot.
<jodh`> apw: I've got similar behaviour over here on a macbook, but it's definitely a kernel issue fwics
<shadeslayer> ogasawara: ping
<shadeslayer> ogasawara: golem.de : http://www.golem.de/news/linux-distribution-ubuntu-erwaegt-umstieg-auf-rolling-releases-1301-97086.html : says that Ubuntu will become rolling release citing that you said it
<shadeslayer> ( I haven't watched the video just yet )
<xnox> shadeslayer: it's not like that hasn't been pondered about before..... as usually it's all moot until there is a clear quality & testing & stability criteria.
<shadeslayer> okay, it's just that the tone of golem.de is "We're going to switch, soonish"
<shadeslayer> but then again, it might be just google translate
<psivaa> jodh: just wondering if you had chance to test the fix that you mentioned for bug 1100386
<ubot2> Launchpad bug 1100386 in linux (Ubuntu) "Raring server installations on VMs fail to reboot after the installations" [High,Confirmed] https://launchpad.net/bugs/1100386
<apw> jodh, yeah it seems to be made happier by 'nomodeset' on my virtual instances, which tends to say it looking like you is coincidence, and likely we are losing all console output
<apw> jodh, do you have any symptoms other than a hang ?  a nice panic perhaps?
<jodh> apw: no - nothing.
<jodh> psivaa: been attempting to test it all morning but everything I've touched so far today has broken (including kernel, compiler, apport, unity, router, sbuild :()
<psivaa> jodh: okay, good luck for the rest of the day :)
<jodh> psivaa: fix for bug 1096531 now uploaded.
<ubot2> Launchpad bug 1096531 in upstart (Ubuntu) "After touch /forcefsck and reboot: Assertion failed in log_clear_unflushed" [High,In progress] https://launchpad.net/bugs/1096531
<psivaa> jodh: thanks
 * henrix -> lunch
<apw> psivaa, do we know when the boot hang at fsck started ?
<apw> psivaa, when did it show up in your testing
<psivaa> apw: its after fsck started
<apw> psivaa, yes that one, what version did it first appear, what version of the kernel
<psivaa> apw: i need to check, 2 mins 
<apw> psivaa, thanks
<psivaa> apw: its fsck from util-linux 2.20.1
<psivaa> if that's you asked :)
<apw> psivaa, i think this is possibly a kernel issue, as you have only recently noticed it
<apw> psivaa, i assume you have an image which does not show this, and one that does, i want to know the kernel version in the last working one 
<psivaa> apw: i have a server image from the 9th Nov, but iirc this issue was noticed early jan, so checking if we have a newer image
<ogasawara> shadeslayer: there might be some issue with translation there, you should probably just watch the video.  I mentioned that a rolling release has only been a discussion at this point and nothing set in stone.  as xnox also noted, I mentioned in the interview the quality and stability aspects need to be in place before such a plan could move forward.
<shadeslayer> I see
<shadeslayer> It's just that I don't have enough bandwidth at the moment to stream :()
<shadeslayer> :)
<xnox> shadeslayer: you should definitely watch it. ogasawara was a real star in that interview: informative and inspiring. Overall very entertaining hangout.
<shadeslayer> :D
<apw> sforshee, so i have not been using it very long, but preliminary feeling is that this brcm fix has worked, i will be suing it a bit longer before i say for sure ... but i have been bitching much less about my machine with it
<sforshee> apw, great. It tested well for me too. It's already on the linux-wireless list, so I expect it in the next 3.8-rc.
<sforshee> apw, otherwise is brcmsmac working well on your machine?
<apw> sforshee, i think it is ok yeah
<apw> sforshee, if you get me the commit i'll push it to raring as a sauce patch, and it will either rebase out of existance or not depending if it makes the next -rc
<apw> as it is very annoying :)
<sforshee> apw, ack. I'll send it to the list in a bit.
<wookey> Hmm. I see that some bright spark decided that the correct name for the variable keeping the kernel's version of DEB_HOST_ARCH (e.g. 'arm') should be called 'build_arch'
<wookey> It's only used in the rules files. WOuld people object if I sent in a patch to rename it 'host_arch' to reduce cognitive dissonance?
<wookey> (I know the GNU naming is bloody confusding but as we are using that already for every else it seems peverse to use this)
<wookey> I guess it was called 'build' to distinguish it from 'header'. 
<apw> wookey, i guess that would be ok
<apw> wookey, i hate all of those names ... sigh
<wookey> yes it really hurts your head, especially if you don;t do it all the time
<apw> wookey, oh but is that really waht it is ?
<wookey> So anyone coming to it fresh is likely to get it all wrong
<wookey> do you know why we have 'build_arch and 'header_arch'? when are they different?
<apw> build_arch is actually the kernel arch one uses when making things
<apw> so the arch you are building for, is that HOST
<wookey> correct
<wookey> and the arch you are building on is BUILD
<apw> if you are changing it maybe kernel_arch might make more sense, as it is not an _ARCH in the sense of those arches anyhow
<wookey> and tools stuff probably doesn;t keep all this straight. I've fixed one bug. looking for more now. 
<wookey> right. that's a better name. thank you
<apw> and would probabally match header_arch as well
<apw> header_arch used to be different back when 32bit and 64bit x86 were different in the kernel, so it is possible it could reappear
<wookey> OK
<wookey> I'm not sure which is correct when building tools (which use that arch to find the syscalls, for example)
<wookey> doesn;t matter for 'arm', or 'arm64' but I'd like to get it right...
<wookey> I suspect header_arch...
<apw> wookey, you are likely right, hard to be sure
<apw> jodh, hey ... ok these machines are actually not dead at all, in fact we have just lost the console driver en-toto.  i need to find out what upstart thought was going on during early boot, is that recorded?
<jodh> apw: how 'early' are we talking?
<apw> jodh, i want to know what triggered plymouth to start
<apw> start on (started plymouth
<apw>           and (graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1
<apw>                or drm-device-added PRIMARY_DEVICE_FOR_DISPLAY=1
<apw>                or stopped udev-fallback-graphics))
<jodh> apw: could have been started in the initramfs.
<apw> jodh, basically i want to know what lit off that
<apw> jodh, i want to know what order and when these events occured in the boo
<apw> jodh, as we seem to be lighting off plymouth just before we switch framebuffers instead of just after
<apw> jodh, is that level of detail recorded anywhere on disk, can i ask for it
<jodh> apw: your best bet if you can't get a console log is to have plymouth.conf call 'set' or 'env' and write a persistent file. That will contain UPSTART_EVENTS (see http://upstart.ubuntu.com/cookbook/#standard-environment-variables).
<jodh> apw: that env var will tell you which events triggered plymouth to start.
<apw> jodh, ahh will have a go at that
<bjf> arges, jsalisbury any progress on the inotify bugs?
<arges> bjf: testing today on an earlier version
<jsalisbury> bjf, I requested testing of earlier kernels in all the bugs, I'll go check for updates now
<bjf> arges, jsalisbury have you been able to reproduce the issue?
<arges> bjf: ok i'lm looking at 1101666 and i haven't been able to reproduce yet
<bjf> arges, ack, was just wondering if were were dependent on testing by the reporters
<arges> bjf: so for this bug, essentially its to run this test program and expect an error of 'inotify_init: Too many open files'? am i missing something
<bjf> arges, that was my reading of the bug
 * ogasawara back in 20
<arges> bjf: i've tried in a 3.2.0-36-generic kernel, and a 3.2.0-32-virtual
<arges> and no luck reproducing
<arges> also looks like this user is reproducing on vmware fwiw
<arges> which i don't have
<jsalisbury> bjf, arges, so far only one person has done some testing.  3.2.0-36 the bug and 3.2.0-35 does not.  I've also asked for testing of 3.2.0-36.56 versus 3.2.0-36.57, but don't have those results yet.
<jsalisbury> s/3.2.0-36/3.2.0-36 has/
<bjf> jsalisbury, arges so this bug has been around for more than one release as i understand it so it's not a regression that just went in
<arges> jsalisbury: also looks like lino (the patch author is looking at this too)
<bjf> jsalisbury, arges though i'd like to get it resolved quickly and into the point release, i'm not going to wait a long time for it
<arges> ok i see a bash script in the comments, trying that too
<jsalisbury> arges, bjf, There is also this comment in one of the bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101355/comments/6
<ubot2> Ubuntu bug 1101666 in linux (Ubuntu Quantal) "duplicate for #1101355 inotify fd leak" [Medium,In progress]
<bjf> jsalisbury, yes we have seen that. we generally don't fix a regression by applying a bunch of new commits
<jsalisbury> bjf, arges, however, I haven't looked at those patches as of yet.
<jsalisbury> bjf, ack
<jsalisbury> arges, I haven't tried to reproduce it yet, are you working on that?  
<bjf> jsalisbury, but i'm not ruling it out
<arges> jsalisbury: i'm running the bash script in 1101666 comment #25
<jsalisbury> arges, ok
<arges> so far no problem on bare metal 3.2.0-36
<arges> after iteration 158
<arges> wait
<arges> nope I see the same issue
<arges> testing on earlier version 
<jsalisbury> arges, are you running .56 or .57?
<arges> umm
<arges> jsalisbury: this is a kernel with that headset patch on top... so let me re-test with an official build
<arges> too many things flying around
<henrix> jsalisbury: arges: i was able to reproduce the issue on a VM (kvm), after iteration 117
<arges> henrix: which version?
<henrix> arges: the version in -updates
<henrix> 3.2.0-36.57
<arges> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101666/comments/33
<ubot2> Ubuntu bug 1101666 in linux (Ubuntu Quantal) "inotify fd leak" [Medium,In progress]
<arges> this is also interesting
<henrix> ok, so i'll just build a test kernel reverting the fsnotify commits we added on 3.2.0-36.57 
<henrix> arges: jsalisbury: or do you have another suggestion?
<arges> henrix: no however do we think this is already verified?
<jsalisbury> henrix, shouldn't that just be 3.2.0-36.56 ?
<arges> and it looks like that fails from reading the comments. the only fsnotify patches are the ones i SRUed
<henrix> jsalisbury: well, 3.2.0-36.56 actually contains some of these patches already. 3.2.0-36.57 reverts some SAUCE patches and applies them again from mainline
<arges> henrix: did we test 3.2.0-36.57?
<jsalisbury> henrix, ok, got it.
<apw> so it seems we'd want to know if .56 was good (i believe we are saying .57 is bad)
<arges> althought the fsnotify patches in .56 (the original SAUCEd ones) exclude a single patch from that 9 patch series
<henrix> yes, .57 is bad. but most probably .56 is also bad.
<henrix> if you run git log --oneline Ubuntu-3.2.0-36.56..Ubuntu-3.2.0-36.57 you'll see they are pretty much the same, appart from one patch
<henrix> .57 = .56 + 692115c
<henrix> and i don't think we want to leave 692115c out
<arges> no
<arges> but I think its clear it causes a regression
<arges> despite fixing something else
<apw> welll knowing if .56 was good would tell us that indeed, is .56 good
<henrix> ok, i'll build .56 and test it
<jsalisbury> henrix, you can get .56 from here: https://launchpad.net/ubuntu/+source/linux/3.2.0-36.56
<henrix> jsalisbury: ack, thanks
<jsalisbury> henrix, under "Builds" per arch
<arges> also keep in mind that these 9 patches are in ubuntu-raring too
<arges> so i can test raring as well
<apw> jodh, ok that shows what i feared, that the efifb is being detected as a sane frambuffer, then recycled
<jsalisbury> arges, I believe the patches in 3.8 are different 
<arges> jsalisbury: well the ones in 3.2 3.5 are backports of the 3.8 patches
<apw> slangasek, can you remember whether we expect to use efifb as anything other than a fallback during bootsplash ?
<apw> slangasek, ie are there systems where that would be the only one commonly
<slangasek> apw: I don't know about commonly, but if there's no other framebuffer available I think we would wind up just using efifb?
<jsalisbury> arges, ok, were they backported from commit: 96680d2b9174668100824d763382240c71baa811 ?
<apw> slangasek, the issue i am seeing is in VMs, efifb comes up, we splash to it (or tell plymouth to anyhow) and then cirrus comes up and replaces it, failing cause it cannot replace the framebuffer
<arges> jsalisbury: that's the merge... 
<apw> slangasek, in the bad old world we had the same issue with vesafb and it went onto the 'fallback' thing to change the order
<jsalisbury> arges, ack
<apw> slangasek, efifb is triggering the same badness i believe here, and so i am considering whether we can not consider efifb as a primary display just as a fallback
<arges> testing .56 btw
<arges> jsalisbury: henrix : .56 also fails for me
<arges> 3.2.0-36.56
<apw> jodh, your mac which was showing perhaps the same issue.  for me the machine is coming up successfully with a completely dead console (no VTs no nothing)
<apw> jodh, but it is on the network, can you tell if yours is the same, if you can login have a look at /proc/fb which in my failing case was empty
<apw> jodh, if you can login i would also like a dmesg
<jodh> apw: will try to nagivate my menu "blind" and see what happens :)
<henrix> arges: i'm about to test it too
<arges> jsalisbury: Ubuntu-3.8.0-1.5 works fine up to 300 interations of this bash script 
<apw> jodh, would you not be beyond menus when it fails, ie booting
<arges> henrix: ok yours should fail also
<henrix> arges: yep :)
<jodh> apw: no - my menu waits for input by design. I can turn it off though...
<apw> jodh, oh you have your own menu after boot
<apw> soemthing i would not see
<jodh> apw: you're right - I've got it in the odd state now. There is *nothing* in dmesg for the kernel - first entries are for upstart.
<apw> so you can login ?
<jodh> apw: to be more precise, nothing from the kernel until *after* upstart has started.
<jodh> apw: logged in now.
<apw> jodh, well that is odd (re: dmesg being empty of kernel things)
<jodh> apw: keyboard lights fail to work which coupled with a blank screen led me to believe it was dead.
<apw> jodh, what does /proc/fb have in it
<apw> jodh, but can i have dmesg regardless please
<jodh> 0 inteldrmfb\n1 VESA VGA
<jodh> apw: sure...
<henrix> arges: ok, took me a while to reproduce as i was boot the wrong kernel :p
<apw> jodh, ok do you have upstart debug on, maybe we are losing the early dmesg due to size
<arges> oops
<apw> jodh, i am not sure i expect to see VESA loaded there, if you have inteldrmfb loaded ...
<apw> slangasek, ^^ we only load vesafb if we don't get a normal driver in the normal run of things right ?
<apw> jodh, let me know where you have put the dmesg, pastebin it perhaps
<jodh> apw: yeah - one sec. wondering if I can run 'apport-collect' again for the bug?
<apw> jodh, hmm no idea
<jodh> apw: seems you can: https://launchpadlibrarian.net/129184147/BootDmesg.txt (from bug 1103406)
<ubot2> Launchpad bug 1103406 in linux (Ubuntu) "kernel disabled console output and keyboard lights in early boot" [High,Confirmed] https://launchpad.net/bugs/1103406
<slangasek> apw: cirrusfb> isn't there an open bug report about this, which I filed and smb worked on for a bit?  Considering that we have *no console* in the EFI world until efifb is loaded, I don't think it's sane to treat efifb as a "fallback"
<apw> jodh, ok ... can we get an env >/FOO from -fallback-graphics on your system please
<bipul> I am looking some help for writing code in C for Packet capturing through libpcap in Linux(Ubuntu)
<apw> jodh, i want to know if it is seeing the intelfb right
<slangasek> apw: vesafb> yes, AFAIK we only load that via the upstart job you wrote for this
<jodh> apw: on it...
<apw> slangasek, so yeah we don't have a console till efifb starts true, but we get those when we are going to get a better one later as well
<apw> slangasek, which sounds like the vesafb issue in a sense
<ogra_> there is also /usr/share/initramfs-tools/scripts/init-top/framebuffer
<bipul> Any one here who can help me.
<apw> slangasek, we want to use efib, but only if we don't have something more useful
<slangasek> ogra_: which is also "fallback" in its logic
<ogra_> (indeed only if FRAMEBUFFER exists)
<slangasek> apw: why can we not fix the efifb->cirrusfb handoff?
<slangasek> I don't think we want the kernel to delay all video output until it has a chance to probe around and try to find a chip-specific video driver
<apw> slangasek, this is exactly the same handoff issue we had with vesafb, wherein upsteam said don't do that
<slangasek> hmm, is it definitely the same
<slangasek> ?
<apw> slangasek, output will come out on it, the issue is if plymouth has it open when the kernel trys to replace it
<apw> slangasek, then it cannot rip out efifb correctly, nor replace it with cirrus so we have none
<apw> slangasek, so i am not suggesting no output, just no splash on it
<slangasek> ah
<apw> so i guess it would be purple from grub if that is on
<apw> or in my case it has kernel dmesg vommit
<apw> as it is a server image
<slangasek> so you intend efifb to not be autoloaded?
<apw> i seem to be able to 'fix' my machine here by preventing efifb fb0 from triggering PRIMARY_DEVICE_FOR_DISPLAY
<apw> slangasek, i think it is builtin for reasons i now forget, so not stopping it autoload, just not marking it PRIMARY_
<apw> then it gets used, as a fallback rather than first
<apw> at least i think it should, it is very hard to tell here where its not innitialised long enough before the machine boots and turns off splash
<jodh> apw: http://paste.ubuntu.com/1563545/
<slangasek> apw: hmm, ok
<slangasek> I guess that sounds sane
<jodh> apw: ... but oddly, this time /proc/fb just contains '0 inteldrmfb'
<apw> jodh, in this case is /proc/fb showing the same two lines ?
<apw> jodh, ok that one seems a 'good' boot then
<slangasek> apw: can you confirm that if you make this change to efifb, the per-chip driver *does* get marked PRIMARY_ in its place?
<jodh> apw: no - this boot was also 'stuck'.
<apw> slangasek, it does in my VM here that triggers the issue, cirrus comes along very soon after and makes the same things happen
<apw> jodh, and a dmesg off that one
<slangasek> apw: "makes the same things happen" - I specifically want to know that it sets the PRIMARY_ flag, such that we don't have to wait for udev to settle before we get splash init
<arges> jsalisbury: ok i'm building a precise kernel with patches identified here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101355/comments/6
<ubot2> Ubuntu bug 1101666 in linux (Ubuntu Quantal) "duplicate for #1101355 inotify fd leak" [Medium,In progress]
<apw> jodh, i did find in my testing that the timeing change triggered by adding env > can change timing enough to cahnge the issue, which is also annoying
<jodh> apw: updated dmesg - http://paste.ubuntu.com/1563556/
<jsalisbury> arges, cool.  were those patches just missing from the original backport?
<apw> slangasek, sorry yes, that is what i am saying; env from fallback has
<jodh> apw: ack
<slangasek> apw: ok, then that sounds sane
<apw> slangasek, sorry from plymouth-splash has:
<apw> PRIMARY_DEVICE_FOR_DISPLAY=1
<apw> and what looks to be a sane pci id for the cirrus fake thing
<arges> jsalisbury: no the original backport that fixed the bug iw as looking at was 9 patches
<apw> slangasek, i assume where we only have efifb splash will be late of course
<arges> these 6 additional ones came later
<jsalisbury> arges, ahh, ok
<apw> slangasek, ok i will put together a patch for udev and we can get it tested officially
<arges> anyway building. i want to confirm that these new patches fix _both_ issues
<slangasek> apw: we may also need/want to touch udev-fallback-graphics to not try to load vesafb on top of efifb
<apw> slangasek, a point indeed, hmm i wonder what happens there
<apw> slangasek, i'll try preventing cirrus from loading in my case and see
<slangasek> ok
<arges> ok uploading
<apw> slangasek, ok it seems that we will try and load vesafb (as we surmised) but that actually that is ok because it fails
<apw> ERROR: could not insert 'vesafb': No such device
<apw> even with a VGA device installed rather than cirrus, because efifb has it, it fails to load
<slangasek> right
<slangasek> though we preferably would know this and fail silently instead of throwing noise to /var/log/upstart
<apw> i guess we could check /proc/fb for EFI VGA as well if we wanted to be paranoid
<slangasek> (IMHO)
<arges> jsalisbury: henrix : please test http://people.canonical.com/~arges/lp1101666/
<apw> slangasek, oddly it doesn't seem to record anything in there
<apw> slangasek, for that job even when i beieve it ran and failed
<slangasek> hmm, odd
<slangasek> well, we do call modprobe with '-q'?
<apw> slangasek, ahh yes, -q -b
<jsalisbury> arges, will do shortly.  just need to setup an environment to reproduce.
<arges> jsalisbury ok i'm testing on this end
<henrix> arges: do you have a link to gomeisa/tangerine with the .debs?
<arges> henrix: gomeisa.buildd:lp1101666/
<henrix> arges: cool, thanks
<arges> 300 iterations without a failure...
<arges> brb
<arges> 800 iterations without a failure
 * ppisati -> gym
<jsalisbury> arges, I'll test in about 10 minutes.  Just finishing up another bug
<henrix> arges: same here. and i've just started to run in parallel the inotify stress test that should trigger the original bug that should have been fixed by 3.2.0-36.57
<apw> arges, so is that a further 6 patches on top of what we have already in the tree ?
<psivaa> apw, so the hang issue started with Ubuntu 3.7.0-6-generic (20121213 raring server and later ones)
<psivaa> apw: i tried with 3.7.0.5-generic and earlier ones (20121212 and earlier images) and could not see the hang
<jsalisbury> arges, testing your kernel now.  I changes the script to run for 3000 iterations, so I'll just let it go
<jsalisbury> arges, crap, got a panic
<henrix> jsalisbury: inotify related, or something else?
<jsalisbury> henrix, idk yet.  Happened right at the login screen.  Booting again.
<henrix> ouch
<jsalisbury> henrix, ok, booted fine that time.  Let me do a few reboots, then I'll kick off the test.
<jsalisbury> henrix, arges, got another panic right at the login screen.  The RIP is effective_load() in the scheduler.
<jsalisbury> henrix, arges, This may be another bug, so let me see if I can reproduce it with the Precise kernel 
<henrix> jsalisbury: just curious, are you running on baremetal or VM?
<jsalisbury> henrix, baremetal
<jsalisbury> henrix, I let the script run that reproduces the bug, and it's at 2300 iterations without reproducing it.
<jsalisbury> henrix, I'll see if I can reproduce the panic shortly.
 * ppisati goes to find some food...
<apw> psivaa, thanks for the info
<ogasawara> jsalisbury_, henrix: what's the bug# for this fsnotify regression?  I wanted to throw it in this weekly status report
<jsalisbury_> ogasawara, bug 1101666
<ubot2> Launchpad bug 1101666 in linux (Ubuntu Quantal) "inotify fd leak" [Medium,In progress] https://launchpad.net/bugs/1101666
<ogasawara> jsalisbury_: thanks
#ubuntu-kernel 2013-01-24
<ppisati> moin
<apw> moin
<smb> apw, morning
<cking> morning + yawning
<smb> apw, and if you could not hear anything yet, your mumble is broken
<apw> my entire machine is broken at the moment, with root offlione
<smb> apw, Sounds rather annoying...
<apw> its the issue cking (i think) mentioned with intel ssds in quantal, with them being gone on resume
<cking> that one bitten you again?  my box seems to be ok nowadays
<ppisati> i experienced corruption with my intel + ssd in Q, but it was long ago
<cking> not seen the issue yet with 3.8
<apw> cking, that one is my one holdout on quantal, i should upgrade it
 * apw gets hit box back in one piece, may as well update at least while it is working
<smb> apw, My "fun" this morning was that I found that wl wasn't seeing my AP at home at all (though a bunch of the other ones around)
<apw> smb, heh, nice, did a reboot fix it ?
<apw> smb, remember it ended up in .TW after being at cking's place
<smb> apw, Nah, but I found out that it will find it when I change the AP to be only b+g and not b+g+n
<apw> perhaps its channels were turned off
 * cking blames his dodgy .tw AP
<apw> smb, hmmm, something you got during updates while here then
<apw> we did get a new wl relativly recently, in r anyhow
<smb> apw, something == replace b43 with wl because b43 tends to loose its mind too often
<apw> ahh
<apw> b43 is ... not great ... bcmsmac is better if it supports your h/w
<ohsix> i think it's heat related! :p
<apw> well it is now anyhow with sforshee's fix
<apw> a whole day without issues, a first for this month
<smb> apw, Naturally bcmsmac isn't usable for this
<apw> sigh
<ohsix> i've used b43 quite a lot; when it fails it has a time component to it
<apw> ohsix, joy ... heat, or leaks or something then
<ohsix> if i remove b43 for two minutes, i got another 15 or so out of it, pretty repeatable
<ohsix> theres separate thermal tables for ssb and the mac, i just figure they're incorrect on my particular thing
 * apw reboots again
<ashwini> Is there any way, I can make my char driver to exit gracefully if it tries to write or access unallocated pointer, right now it is crashing ??
<apw> ashwini, as in a kernel driver, not really 
<apw> ashwini, a common approach though would be to use your own wrapper function to pre-validate pointer writes where you are having trouble
<ashwini> apw : no way to handle this type seg faults ???
<apw> ashwini, and preventing the writes occuring
<ashwini> apw: thanks for the info. 
<apw> np
<wookey> apw: OK. I've fixed the tools build so it works for the random linaro kernel I was asked to fix (quantal linux-linaro-origen-3.7). Which kernel would you like raring patches against?
<apw> wookey, raring master is our 'gold standard'
<wookey> I had to leave out C++ demnagling feature in perf because cross libiberty-static is not availble (we can sort that in due course).
<apw> wookey, i have been wondering if we should be doing perf in the main kernel anyhow, one of the things i note the kernel source can do is produce a perf source 'output'
<wookey> debian has moved kernel tools to a separate source package, apparently
<wookey> that seems a lot more sensible to me
<apw> wookey, one advantage of pulling it out, would be to allow it to fall into universe so it doesn't have to pull the libraries in
<wookey> as all the cross-cvomlexity (and hla fthe build-deps) are in the tools bit
<apw> wookey, perhaps i should poke that first before you do the work
<wookey> fine by me. Any idea when you might get to that (as I currently have this 'mental set' loaded)
<wookey> in fact better than fine - I think it's  good plan.
<apw> i'll have a quick look now and see how easy it looks
<wookey> perfect answer :-)
<apw> wookey, any idea what the debian package name for the pulled out perf actually is
<wookey> erm no. linux-tools?
<apw> wookey, i am interested in whether they have kept it locked to kernel version or not
<wookey> there is a linux-tools source package
<apw> yeah, and the orig there looks like the tarball the kernel source makes too
<brendand> henrix, there is no change on the kernels being held for a few weeks, right?
<apw> wookey, i'll poke this some this morning, as this may well make more sense, as it can be shared between flavours
<henrix> brendand: actually, i'm currently respining Q and P kernels due to regressions
<apw> wookey, as i would love it to drop this into universe
<wookey> righty-ho
<brendand> henrix, you mean the ones that were just tested?
<henrix> brendand: yes. he need to revert a few patches to fix a regression, and add a new fix for another regression
<henrix> s/he/we
<brendand> henrix, hmm. what will happen after that - do we and qa need to retest?
<henrix> brendand: i'm not sure we'll need a full re-run in all the kernels. but at least the kernel that will go into .2 release should be tested, i believe
<brendand> henrix, do you have any info on the regressions? i want to do a test gap analysis to see if we could have caught it earlier
<henrix> brendand: sure, give me 1 sec and i'll point you to the bugs
<henrix> brendand: bug #1101666 and #1103320
<ubot2> Launchpad bug 1101666 in linux (Ubuntu Quantal) "inotify fd leak" [Medium,In progress] https://launchpad.net/bugs/1101666
<ubot2> Launchpad bug 1103320 in linux (Ubuntu Quantal) "Ubuntu 13.04 and 12.04.2: Login screen does not appear after installing OS on SL4545 G7" [Medium,Fix committed] https://launchpad.net/bugs/1103320
<henrix> brendand: the first one has a script that allows to reproduce the issue easily
<brendand> henrix, that's on a vm though it seems
<brendand> henrix, which doesn't concern us
<henrix> brendand: correct
<henrix> brendand: anyway, i'll ping bjf later and ask him about the QA and cert testing for these kernels.
<brendand> henrix, not sure if we have the other system affected by the lightdm problem. if it's down to the graphics hardware maybe we can find something with the same though
<brendand> henrix, huh - i thought that HW was a server
<brendand> henrix, we only run ubuntu-server on servers, so headless
<brendand> henrix, or by 'login screen' does it just mean the text prompt?
<Guest11170> #ask
 * henrix -> food
<apw> henrix, where are we with respinning quantal ?
<gema> can anyone tell me how many mounts are needed for a fsck to be done with ext4?
 * gema is trying to figure out how many reboots go by before a check is done on the drives, how often to expect it
<ohsix> it depends on the volume header, you can use tune2fs to either set it or display it
<ohsix> you can also drop a file in / to fsck all the drives at boot, but i don't know the name of the file or if it even works anymore
<gema> ohsix: I am rather trying to determine whether a problem we are seeing with bootspeed, which sometimes fails at the 17th/18th boot, can be related to a fsck of the drives
<gema> ohsix: I am going to try tune2fs
<ohsix> ah, then yea; tune2fs should be able to give you something
<gema> ack, thanks
<henrix> apw: currently building
<ohsix> i guess this is it, and also the value here; but the filesystem was created a looong time ago Maximum mount count:      23
<gema> ohsix: I have -1 as a maximum mount count
<gema> I wonder what the machines on the lab will have
<ohsix> interesting
<gema> ohsix: thanks a lot, you put me on the right track :)
<ohsix> that has to be set explicitly afaik
<cking> indeed it does
<apw> herton, are you asking panda|x201 to submit his patch to you :)
<herton> apw, yes :), but I also would like to see it on stable ML, for any other feedback regarding it
<sg20002> Hello. Can somebody help me with kenrel panic? I'm getting '/sbin/init: Accessing a corrupted shared library. And it's not telling me the library.
<ohsix> you'll need to find some way to run ldd on it ... but if you're getting that message there's probably a lot more wrong than just that one library, heh
<sg20002> ohsix: I can boot from live dvd. Can I then run ldd from it?
 * henrix wonders if we now have new (and faster) ppc builders.  quantal took 40 mins!
<BenC> sg20002: From my quick searching, it sounds like you've got some bogus and/or corrupt libraries, which means you may have to reinstall some things (or remove bad libraries that are in the way)
<BenC> henrix: we do
<henrix> \o/
<BenC> sg20002: what were you doing before this occurred, is probably the best question
<ohsix> sg20002: yes, but doing that and reinstalling the packages is easy enough; don't have time to walk someone through it tho
<BenC> sg20002: and this is not technically a kernel question, so you may have to move along to #ubuntu for more help
<ohsix> yea that
<sg20002> BenC: Asked in ubuntu already. Don't really know what happened before - the person who saw what happened is saying that he was just moving a large file and then it just died.
<BenC> sg20002: Of course, no one wants to admit they messed up :)
<BenC> sg20002: It's very likely that reinstalling libc6 package could fix this, but if you need help on how to do that, ask in #ubuntu
<sg20002> BenC: Yes, read somewhere that libc6 may be connected.
<BenC> sg20002: What I can say with almost certainty is that this is user error. Unless you have a bad hard drive, or experienced a kernel crash that someone corrupted on-disk structures.
<BenC> sg20002: every search I've seen about this error has been because someone did something dumb
<BenC> s/someone/somehow/
<sg20002> BenC: Ok, thanks. One more quesiton - I've got the kernel log, and it's full of weird messagess like this: Dec  4 13:03:32 lxc-host kernel: o0n_#C0n_#CCeD0ohlI"rCeD"rCeD0ohlI"rhlM:rn0M en0M en0M 0eI:ren0M en0M ea#M:rn0M CeD0oCeD0oh#MCtn_0r0eI:e0eI:eClM ca0#oenD"r0eI:eClMCtn_0rdn_#Ccn0M 0n#I0Che_M:Cn0I#0ae0I#CnlDM0n#I0Che_M:Cn0M"Cn0M"0n#I0CalD# he_M:ralD# Cn0M"Cn0M"oae_M:0n#I0Che_M:Cn0M"oalD# he_M:ralD# alD# Cn#I0CalD# alD# he
<sg20002> BenC: Does this look like a normal kernel log message?
<BenC> sg20002: Can you post that full kernel log on pastebin?
<sg20002> BenC: Sure. Though log is huge, here's a chunk of it: http://pastebin.com/q46jNMPn
<BenC> sg20002: specifically I'd like to see the chunk where the kernel messages go from sane to insane
<sg20002> Though it seems somewhat old and maybe the problem with it was fixed already.
<sg20002> Hmmm.
<BenC> about 100 lines +- that point
<sg20002> BenC: Seems that it started insane.
<BenC> sg20002: Can you check the older log (kern.log.1?)
<sg20002> BenC: That's the only one I found on that machine.
<BenC> sg20002: It's started to look like you've just been running a ticking time bomb for some time, but I'd like to see what started the whole thing
<BenC> sg20002: Then sadly, you will just have to reinstall libc6 and go from there
<BenC> If you do get it running again, I'd keep an eye on the kernel logs for awhile
<panda|x201> herton, yeah, I will send the patch to Stable list for you or other ppl like bwh to review, so do you have any time estimation for how long for the regular review process?
<sg20002> BenC: Hmm. How do you think, maybe I should just do a release upgrade since that machine is ubuntu 11?
<BenC> sg20002: sure, wouldn't hurt
<herton> panda|x201, not sure, it depends, probably on how much free time and availability people have to look at them, but it's a good idea to post there, also for any other stable maintainer to include in his maintained series if applicable
 * ogasawara back in 20
<wookey> apt-get --only-source source linux gets me linux_3.8.0-1.5.dsc, but apt-cache policy linux is 3.8.0.1.14. is that right?
<wookey> they don't look like matching source and binary...
<wookey> (in raring)
<smb> Version of .dsc looks right. Policy for linux returns the version number of the meta package (usually).
<wookey> ah yes - that's from meta. 
<apw> wookey, yeah its the silly "am i reporting binary or source package" where the two come from different sources
<wookey> yeah apt-cache policy doesn't seem to have a --only-source equivalent. this has irritated me before
<marrusl> hi folks...  is it possible to disable memory banks at the kernel level?  I'm guessing not but...
<BenC> marrusl: depends on what you mean by banks. You can limit how much memory the kernel exposes by using mem=X on the kernel command line (accepts things like 128M or 2G as argument)
<BenC> If you mean physically limiting it to a certain DIMMâ¦I don't think so
<marrusl> BenC, yeah it's a situation where we'd like to avoid pulling DIMMs physically from a thousand servers, but that looks like the only option.  :)
<marrusl> not just to limit the RAM, but actually to power down the bank.
 * ppisati -> gym
<wookey> apw: kernel tools detection of optional tool library features now working with MA paths. So we get unwind, and audit and dwarf and newt 
<wookey> Will inlcude in patch.
<apw> wookey, sounds good
<wookey> trivial when you find the right spot :-)
<wookey> it's all quite sensibly designed, it turns out
<apw> heh
<infinity> apw: What's the deal with these revert SRUs?  Are they 12.04.2-critical, do you know?
<apw> infinity, i'd say they probabally are, i hear that inotify is not working well as things are
<bjf> infinity, yes
<infinity> bjf: Alright, good to know.
<bjf> infinity, that's why we are doing them
<infinity> Looks like this was a forked branch that didn't include the ppc config and tg3 changes?
<bjf> infinity, are those recent changes that went into the tree(s)?
<infinity> bjf: At least the tg3 pulls landed before the fsnotify reverts hit the list, hence the curiority.
<infinity> curiosity, too.
<apw> infinity, for a revert like this it would be based off the master branch not master-next
<apw> infinity, as we are doing the utter minimum to the thing once tested
<infinity> apw: Check.
<infinity> Was mostly just curious if those changes could end up in the 12.04.2 d-i build, but I'd already counted on them not.
<bjf> infinity, this covers both Q and P, which are you talking about? i'm looking at the trees now
<infinity> bjf: Andy answered my question with the master versus master-next thing, I believe.
<bjf> infinity, i'm concerned about your "forked branch" comment
<infinity> bjf: That was me just not quite understanding your workflow that there are two heads, not one.
<bjf> infinity, ok, i think i'll have to discuss the master-next branches with henrix though, they don't look right to me
<henrix> bjf: which serie doesn't look right?
<bjf> henrix, quantal master-next
<henrix> bjf: note that i've picked what's on master-next and applied on master, and i haven't rebased master-next *yet*
<bjf> henrix, ah! ok, youre on it and i'll just shut up
<henrix> bjf: :)
<bjf> henrix, it was the rebase of master-next that i was going to discuss
<henrix> bjf: i'll probably do that tomorrow only, once everything is built and in ready for -proposed
<bjf> henrix, ack, makes sense
<jsalisbury> cking, bug 1098697 is interesting.  It seems like it could be due to wake on lan.  Still gathering additional data.  When wake on lan is enabled, does the OS stay running in some way?  Or is it controlled by the BIOS?
<ubot2> Launchpad bug 1098697 in linux (Ubuntu) "High Battery discharge rate when Laptop is off." [Medium,Incomplete] https://launchpad.net/bugs/1098697
<jsalisbury> cking, it meaning is wake on lan controlled by the BIOS
<cking> jsalisbury, WoL also keeps the network card active, even when the computer is powered off. 
<jsalisbury> cking, where does WoL run when the computer is powered off?  Is it running in the network card firmware?  
<cking> jsalisbury, I refer you to http://en.wikipedia.org/wiki/Wake-on-LAN
<jsalisbury> cking, thanks ;-)
<cking> jsalisbury, we have a test for this: "sudo fwts s3power" 
<cking> but it's only for laptops :-(
<cking> jsalisbury, https://lesswatts.org/tips/ethernet.php
<jsalisbury> cking, thanks!
<trijntje> ping jsalisbury
<trijntje> I noticed your comment on the bug report about grub-probe missing /
<trijntje> https://bugs.launchpad.net/ubuntu/quantal/+source/ubuntu-defaults-builder/+bug/1075876
<ubot2> Ubuntu bug 1075876 in ubuntu-defaults-builder (Ubuntu Quantal) "ubuntu-defaults-builder: only quantal 64bit does not build" [Undecided,Confirmed]
<trijntje> However, I've checked the log of a build on raring that was succesfull and the same line appears there, so it looks like that is not fatal
<jsalisbury> trijntje, looking
<jsalisbury> trijntje, do you also see this: "run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1"
<trijntje> jsalisbury: no
<trijntje> http://pastebin.com/spSp1ncM
<trijntje> those are the lines with run-parts from the succesfull log
<jsalisbury> trijntje, so maybe the grub-probe error is a red herring or it could also be that zz-update-grub doesn't handle that return code for Quantal, which is why I added the grub task.
 * cking - EOD
<jsalisbury> trijntje, hmm, I don't see zz-update-grub at all in those logs, even a non-fail message.
<trijntje> jsalisbury: I noticed that as well, maybe it has to do with the fact that the succesfull build was on raring
<trijntje> I'll try building for Quantal 32 bit to see what the logs say, but it will take a while on this netbook
<jsalisbury> trijntje, that would be great.  thanks
<trijntje> jsalisbury: sure, I'm the one asking for help ;) I'll ping you again when I have the log
<jsalisbury> trijntje, thanks.  it would be good if you can attach the log to the bug as well.
<trijntje> jsalisbury: will do, I'll also add a comment that the grub-probe error shows up in succesfull builds
<jsalisbury> trijntje, thanks
<trijntje> ping jsalisbury, Quantal 32 bit build succeeds and does not contain the zz-update-grub line in the log
<trijntje> I've also added the information to the bug report, thanks for your time again, I'm off for today
#ubuntu-kernel 2013-01-25
<BarkingFish> good morning :)
<BarkingFish> I wonder if someone could spare some time to help me please - i'm back in an old kernel because the one which came with raring's dev branch, 3.8.0-1, won't let me build ndiswrapper :(  Could someone please give me some ideas on how to fix this please?
<BarkingFish> I can't build manually, because make can't find the kernel version in /usr/src/linux-headers-3.8.0-1/ , and dkms won't add, build or install ndiswrapper, claiming the dkms conf already has it, and i can't add it more than once :)
<xnox> BarkingFish, I thought i fixed ndiswrapper!
<xnox> and I now wish you didn't disappear as I need somebody to test my ndiswrapper fixes!
<xnox> *sigh*
<infinity> xnox: It's all the rage in #ubuntu-kernel for people to ask for help and /part less than 10 minutes later.
<infinity> xnox: Eventually, you get so used to it, you just stop responding to people.  Even the ones who stick around.  All two of them.
<ppisati> moin
<smb> morning
 * apw yawns
 * apw waves to infinity
<caribou_> I have a twisted C compilation situation that I'd need advise for (for makedumpfile)
<caribou_> is here a good place to ask or #ubuntu-devel would be a better place ?
<caribou> in short, I have source code  lines that don't get compiled, even with optimization turned off
<smb> caribou, Both seems valid. On devel there might be even more people... Now that sounds quite odd...
<smb> Except there is some ifdefs preventing things... 
<caribou> smb: here is an output from gdb disassemble/m : http://paste.ubuntu.com/1569182/
<smb> caribou, which is mostly useless without the source
<caribou> smb: hold on let me fetch it for you
<smb> caribou, Hm, wait... I guess I remember the bits a bit
<caribou> smb: http://goo.gl/iZWUX
<caribou> smb: new lines are added after ...(vm_struct.addr...
<caribou> smb: only the first one added gets compiled in, the 3 others are left out
<caribou> smb: this is to fix makedumpfile so it can extract dmesg with the new variable-length record format btw
<smb> caribou, You are sure its not just cleverly optimized and you only get one assembly block?
<caribou> smb: well I removed the "-O2" out of the CFLAGS, so it shouldn't optimize
<caribou> smb: and there is no other specific CFLAG switch used (only -g and _LARGEFILE_SOURCE macros)
<smb> caribou, Still I would trust a printk in whatever READ_MEMBER_OFFSET is expanded to more that a disassembly. Could be figuring out that the values you are looking for are just relative to some common other offset
<caribou> smb: ok, I'll look at that, thanks
<caribou> smb: thanks for the tip, I think I found it !!!
<smb> caribou, ah, cool. :)
<caribou> smb: READ_MEMBER_OFFSET makes a call to read_vmcoreinfo_long which it typed 'long'
<caribou> smb: those 3 struct members were defined as uint16_t as opposed to the other being u64int_t
<caribou> smb: making them uint64_t gets them compiled...  :-/
<caribou> smb: ok, I must revisit my structure definition then,but I'm on the good path
<smb> Hm, still it would be useful to issue a warning at least if your destination cannot hold the return...
<caribou> smb: well, all the struct definition for the other vmcoreinfo data is defined as long, so I suppose the new ones should be as well
<caribou> smb: but I'll check that
<smb> caribou, certainly it should. And maybe the code is dropped because after conversion the truncated value is always 0, but still
<caribou> smb: I got to get a better understanding of how all this data that is put in the kernel's vmcoreinfo area is managed
<apw> henrix, bjf, we have "lost" the amd64 .ddeb for 3.2.6-36.57 and it was only brought to my attention at 8 days, too late to find out why or fix it.  pitti would like to be told when we are doing our next builds so he can track them
<henrix> apw: hmm... any idea how we lost them?
<apw> henrix, no we dont
<apw> and thats the problem, we keep losing them
<henrix> apw: ok. so, we're currently building P and Q
<henrix> apw: shall i ping pitti? or is he already aware of it
<henrix> ?
<apw> henrix, i've hold him about those two indeed
<henrix> apw: yeah, just reading logs in #ubuntu-devel :)
<apw> arges, you guys keep some .ddebs i beleive ... you don't happen to have linux-3.2.0-36.57 for amd64 do you ?
<cking> apw perhaps we should also archive these .ddebs automatically
<caribou> apw: lemme check, but I think that the .ddebs never made it to the archive
<caribou> arges needed them last week and never found them because they never made it to the archive
<caribou> apw: so since i mirror the archive, I didn't have it either
<caribou> cking: I *do* think so
<caribou> cking: I'm ENOSPACE on my own backup atm
<cking> caribou, yep, that is the main issue with kernel .ddebs
<caribou> cking: I'm mirroring *all* the .ddebs
<cking> yikes
<apw> cking, no we should get the damn thing fixed it cannot be that hard
<apw> cking, to simply keep some files
<cking> apw, that is very true
<apw> cking, hell it is what the archive does, only
<brendand> henrix, can i have links to the tracking bugs for the respun kernels?
<henrix> brendand: sure! for P: bug #1104061 for Q: bug #1103932
<ubot2> Launchpad bug 1104061 in linux (Ubuntu) "linux: 3.2.0-37.58 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1104061
<ubot2> Launchpad bug 1103932 in Kernel SRU Workflow prepare-package-meta "linux: 3.5.0-23.35 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1103932
<henrix> brendand: kernels are still building.
<cking> apw, http://smackerelofopinion.blogspot.co.uk/2012/11/non-linear-characteristics-in-draining.html
<henrix> brendand: also, i'm still waiting for the tracking bugs for the quantal lts kernel.
<infinity> henrix: We're vaguely blocked by IS having misplaced two thirds of our ARM buildd capacity.  I'm violently jamming the kernels through, and should have them copied out of the PPA into proposed by my morning.
<henrix> infinity: ack, thanks. yeah, i was expecting to have all of them build "by my morning" :)
<ppisati> infinity: "having misplaced two thirds of our ARM buildd capacity"???
<xnox> ppisati: datacenter move / reorg.
<apw> qevents"canonical.comu3wYhuKPCYvHs2R
<apw> what the hell is that even
<ohsix> a password?
<apw> ohsix, not one of mine, it looks like a bit out of the middle of some xml data i am looking at
<ppisati> xnox: ah ok
<apw> but why its in my but buffer instead of the stuff i wanted ... i don't know
<ogasawara> apw: I was gonna prep an upload for Raring.  We don't have a lot queued, but its been about a week and that brcm issue seth fixed seems reason enough.
<ogasawara> apw: you have anything else you want included
<apw> ogasawara, ack, nothing pending from me
<infinity> ppisati: rebase tracking bug is up for precise/ti-omap4
<infinity> ppisati: (quantal should be in shortly)
<ppisati> infinity: wasn't SRU frozen?
<infinity> ppisati: You missed all the excitement over the fsnotify reverts, apparently. :)
<infinity> ikepanhc: Ditto to you, armadaxp for P and Q will need a quick rebase for this.
<ikepanhc> quick rebase?
<infinity> ikepanhc: https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1105115
<ubot2> Ubuntu bug 1105115 in linux-armadaxp (Ubuntu) "linux-armadaxp: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> ikepanhc: The matching quantal bug should be up shortly.
<ppisati> infinity: ah, k
<ikepanhc> infinity: I've test build today and it looks good to me, can upload it in 1 day
<infinity> ikepanhc: Kay, shiny.  I want to be able to do a rushed QA/verification next week, so landing the rebases by Monday should be fine.
<ikepanhc> infinity: ack
 * herton -> lunch
<infinity> henrix: quantal rebase bugs are up (including the lts-quantal you were waiting on)
<henrix> infinity: yep. i've just exec'ed the bot manually to speed up things ;)
<infinity> henrix: Ahh, lovely.  Thanks. :)
<infinity> henrix: I was already copying, based on seeing that everything was published.
<henrix> infinity: cool. i'll have the lts building later today
<bjf> shankbot should monitor this irc channel so we can tell it to do things
<henrix> bjf: heh, that would be nice :)
<infinity> Does shankbot give me a grace period after I set promote-to-proposed to Fix Released before it goes looking for stuff in the archive?  Or is it just luck of cron timing?
<infinity> (I've been intentionally not setting it until after a publisher run and mirror push, but that does mean actually remembering to twiddle the bug an hour or so after I've done the work)
<henrix> infinity: i don't know the answer for that question, but i'm pretty sure herton does ;)
<infinity> henrix: Alright, I'm going to have a quick nap.  I'll look for lts-Q when I wake up. :)
<henrix> infinity: ack, thanks!
<infinity> (I'm also going to be naughty and Fix Release my task an hour early, let's see if the bot flips out about linux-signed not being in the archive yet)
<infinity> Well, a half hour early, I guess.  It should hit disk in ~30m.
<lantizia> Hi, I've noticed that the kernels shipping with 12.04 and 12.10 are coming compiled with a setting turned on that wasn't present in the config file of the kernel that shipped with 11.10
<lantizia> that setting is CONFIG_SOUND_OSS_CORE_PRECLAIM=y    and also   CONFIG_SOUND_OSS_CORE=y
<lantizia> given OSS was completely removed in the kernel back in 11.04 release was it?      Why has settings for it re-emerged in 12.04 onwards?   That setting it seems to preserves OSS device numbers in case you have OSS compatibility compiled in to the kernel - which clearly it doesn't any longer!!!
<lantizia> But whilst the setting is there, it prevents people from using OSS proxy/emulation techniques such as osspd (which uses fuse/cuse to fake /dev/dsp and redirects it to pulseaudio)
<lantizia> Can anyone help me (I'm not exactly the greatest developer ever, or know the inner workings of the ubuntu development cycle) to see if we can locate a rationale for this setting re-emerging!?
<xnox> lantizia: well each cycle there is config review where config changes are agreed upon. i'm not kernel hacker though so somebody like ogasawara or apw will probably know about it.
<lantizia> ok
<lantizia> omg it's in raring too
<lantizia> looks like raring is/was/unsure going to include an osspd package too (auto copied from debian sid which now has it)
<lantizia> no point if this setting stays in
<apw> lantizia, we would expect OSS to be off, so if it is on that is a fail as far as i know
<apw> lantizia, that said if noone has noticed for 15 months, then it cannot be a huge problem
<lantizia> apw, can I somehow petition to have it removed?  i mean it wasn't there in 11.10 (because OSS has totally been removed - let it die forever) - so someone put it back!
<xnox> well - ndiswrapper provides went unnoticed for a long time as well.....
<apw>   * [Config] CONFIG_SND_PCM_OSS=n using pulseaudio emulation instead
<apw> lantizia, that one there is the one we turned off to allow userspace emulation
<apw> of the OSS stuff
<apw> debian.master/config/config.common.ubuntu:# CONFIG_SND_PCM_OSS is not set
<apw> and it remains off
<lantizia> ok I'm no expert but from what I know osspd (OSS Proxy) basically uses FUSE/CUSE TO make fake /dev/dsp /dev/adsp /dev/mixer etc... so your ancient game/app thinks it's really talking to OSS
<apw> lantizia, if you think something else should be off, we would want a bug filed for that
<lantizia> no need for wrappers (which only work if libc is still compaible which a lot of the time it's not)
<apw> so we can evaluate it on its merits
<lantizia> CONFIG_SND_PCM_OSS isn't my issue
<lantizia> CONFIG_SOUND_OSS_CORE_PRECLAIM is
<apw> arges, you are a sound weeny, does any of your jack pants use OSS ?
<lantizia> as that prevents the creation of  /dev/dsp   /dev/adsp /dev/mixer
<lantizia> i have no idea what you're on about
<apw> lantizia, i am asking someone who does a lot of sound work if we need any OSS 
<apw> at all in his opinion
<apw> SOUND_OSS_CORE_PRECLAIM would default on if SOUND_OSS_CORE gets turned on, but it defaults off
<lantizia> ah sorry arges is a person (oops!) i thought you were saying you 'argues' the following :D
<infinity> https://lists.ubuntu.com/archives/kernel-team/2010-May/010647.html
<infinity> Looks like we intentionally disabled them way back when.
<ogra_> well, preclaim makes sure the device numbers for things like /dev/dsp are hogged all the time by the kernel
<apw> infinity, yeah and something has broght it back, sigh
<apw> ogra_, indeed
<ogra_> so if any userspace emu wants to create them the major devicenumbers are gone
<hggdh> smb: good afternoon, I got a Q for you -- on one of our test machines, running Raning/Xen, I am seeing lowmemorykiller messages being issued (killing libvirtd, xend, and others). The machine is idling... have you seen something like that?
 * apw tries turning it back off
<smb> hggdh, no
<infinity> apw: d5a54f43f357d4814f2c3d53ca3d5c3f6fddebe0
<lantizia> ogra_, it makes me cry :(  technically I have a cold but still...CRY
<infinity> apw: Pulled in by turning on OSS_MIXER, I suspect.
<apw> hggdh, raring/xen, i have recently set one of those up, i think i did when i made the host too small
<apw> smb, didn't we have to make it a bit bigger
<lantizia> osspd is a god send for getting really old Loki ported games working
<infinity> apw: Or, MIXER_OSS, rather.
<lantizia> and it seems the osspd package is going to be in raring (as it was copied from debian sid, and debian just packaged it) - so without fixing the kernel setting... it'll be useless
<smb> apw, Oh, hm, I did forget about that. Though I think I only saw some other messages not the memory killer... but not sure now
<apw> well they seem to be options which are selected, and just turning those two off they stay off
<apw> so i suspect we have them on for nothing ... 
<hggdh> the thing there is out of two machines with Raring/Xen, one does show it, the other does not. Both have the same setup for Xen (this is happening on Dom0)
<apw> infinity, based on what you found i think we are justified in turning it off for raring at least and we can see what happens
<smb> hggdh, Is dom0 set for ballooning or has it maxmem clamped?
<apw> lantizia, can you file a bug against linux and let me know the number so i have something to track it against
<apw> infinity, as far as i can see we have the core turned on, and no drivers using it, so its a complete waste of time
<lantizia> apw, unfortunately I've got this far and to this channel with the knowledge I have by wildly googling... I'm no expert.. i wouldn't even know how I'd file that bug
<apw> ogasawara, you seem to be the one who turned off OSS (the old sound thing) in maverick timeframe, a couple of core bits seem to be back on in R, know of any reason or can i slam them back off
<apw> lantizia, run "ubuntu-bug linux" in a terminal window and folow the prompts :)
<infinity> lantizia: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<infinity> lantizia: Or what apw said.
<smb> hggdh, And for the host seeing oom killer, check ps or top to find anything with a big mem footprint
<infinity> apw: They snuck back in in P, actually, when you pulled d5a54f43f357d4814f2c3d53ca3d5c3f6fddebe0
<hggdh> smb: looking
<infinity> apw: Since you're the one who did it, maybe you should ask yourself if you know why. ;)
<hggdh> smb: well, dom0_mem is set to 512k, max=512k...
<lantizia> infinity, is this the oss thing?
<apw> infinity, oh yeah.  looks like some kind of total fail on my part there, then i will unilaterally fix that in R for a start
<smb> infinity, Do you expect to remember anyone of us something that is more than 2 weeks old? ;-P
<infinity> lantizia: Yes.
<smb> hggdh, Ok, so that would be how I set my machine. Which runs a server install
<smb> hggdh, wait
<smb> hggdh, Did you say 512K?
<infinity> He had to have meant 512M.
<hggdh> smb: my bad. 512M
<infinity> If you can boot a dom0 with 512K, I want your setup.
<smb> infinity, Thats what I think he meant but better be sure
<hggdh> :-)
<ogra_> 512k are enough for everyone !
<apw> lantizia, drop me the bug number here when you have it so i can add it to the commit
<smb> hggdh, ok, so yeah 512M may be ok if dom0 does not run other services. Like mine...
<apw> ogasawara, did you do your upload yet ?
 * apw waits impatiently for lantizia to supply the bug number
<smb> apw is patiently as always... :)
<herton> infinity, yes, shank bot wait 1 hour after you set promote-to-proposed to Fix Released
<herton> *waits
<apw> smb, well i want to get this in before ogasawara does her thing
<infinity> herton: Oh, cool.  That's good to know.
<hggdh> smb: will recheck all. I can understand bzr going down on 512M, but not libvirtd
<herton> infinity, 1 hour depends on when the cron job executes, but is a minimum of 1 hour
<infinity> hggdh: If you have anything doing scary python things (say, something using the libvirt or xend python bindings to query/fiddle with stuff), 512M goes fast.
<infinity> hggdh: If you don't want to let your dom0 balloon, give it a swapfile.
<smb> hggdh, Well it does not matter what. If memory gets low *something* has to die. And if it is decided that libvirtd is worthwhile...
<hggdh> infinity: nothing much, usually, apart from building the whole of the kernel tests
<smb> infinity, Actually its always a good idea to have some swap file... 
<infinity> smb: Well, yes.  a dom0 without some healthy swap is probably asking for trouble.
<infinity> smb: (for domUs, running swapless may give you exactly the behaviour you want, depending, but for a dom0, it seems silly to potentially lose the whole system to an unanticipated commit spike)
<infinity> Well, not that you actually "lose the system" if xend or libvirt die.  But it sure looks like it to someone who doesn't know how to recover.
<ogasawara> apw: I have not uploaded yet, was doing some test builds and boots.  feel free to shove your changes up and I'll pull it in
<hggdh> well, just reproduced it by running 'bzr branch' -- LMK kicked in after a while, killed bzr *and* libvirtd
<smb> infinity, Yeah, I certainly would not want any server of mine have none
<ogasawara> apw: I'm not aware of any reason for configs to be flipped back on, other than maybe our cowboy did it
<hggdh> which is sort of a overkill. libvird memory usage did not change (visibly), so killing bzr should have been enough
<smb> hggdh, oom killers definition of "not important" not necessarily goes along with expectation
<hggdh> smb: most certainly agree :-)
<infinity> hggdh: Yeah, that's not really unexpected.  A dom0 that's also used for "real work" needs some healthy swap, and if you care about it also being performant, a ballooning config.
<hggdh> yeah. Will review the implementation on that, and add a bit of swap/balloon
<apw> ogasawara, give me a couple to just get this bug number in
<infinity> smb: It's been a long time since I looked at the oomkiller.  Does it intentionally try to avoid killing things with locked pages or any other such tricks?
<infinity> smb: (Like, it's possible xend and libvirt could be doing things to make themselves less easy prey)
<apw> lantizia, poke
<smb> infinity, It is probably as long or longer since I looked. I thought mlock may prevent things, but then also make the overall situation less good for other things
<lantizia> woops sorry my boss was chatting to me on IM
<lantizia> apw, I'm here!
<lantizia> apw, still need me to do something?
<apw> we are holding waiting for the bug number from you, so i can commit this change
<lantizia> ah! that command thing
<apw> lantizia, ^^
<infinity> smb: locking pages isn't usually the right answer to most problems, but in the xend/libvirt/qemu cases, it would almost seem to be what you'd want anyway.
<apw> yeah especially as probabally the guest memory is real and unswappable, 
<smb> infinity, *maybe* libvirt but xend is deprecated and written in python... 
<apw> but the "controller" for it may get shoved out
<lantizia> apw, I'm on 12.04 still - is that ok?
<infinity> smb: Given that your dom0 (or qemu host in the qemu case) kinda has one really important job, and everything else is secondary.
<apw> lantizia, yes
<infinity> smb: You can totally mlock in python.  Using ctypes.  It's evil.  Don't do it.
<lantizia> ok.. .not donee this before - signing in...
<smb> infinity, I did not even want to think about it. 
<lantizia> apw, is my bug that I'd like BOTH of the OSS related settings in the config to simply not be in there at all (they were not even in the config file for 11.10's kernel)
 * smb shudders
<infinity> smb: Heh.  They're rewriting xend in a real programming language as we speak, right?
<apw> lantizia, you are asking for them to be turned off
<lantizia> ok :D
<apw> i'll put the rest of the info in
<smb> infinity, There was an ocaml version but actually they moved the whole stack to use a library written in c
<infinity> smb: Right.  The C library.  That was what I remembered from UDS.
<infinity> smb: If they also write C tools that link to said library, it will be a glorious day.
<infinity> smb: (If all I ever see is python bindings and crappy python tools, congrats on not solving the problem)
<lantizia> apw, ok - i'm just quickly typing up the whole deal :S
<smb> infinity, They do (xm -> xl) but initially loosing the persistent domU management by that. Ok, it is better done in libvirt the same way as for kvm but then this needs the right libvirt for it. So even more that can go wrong.
 * smb goes into a corner and cries
<infinity> smb: libvirt and I don't get along even remotely.
<infinity> smb: Maybe it's matured by now, but the last time I tried using it, I just got very, very angry and went back to configuring VMs by hand.
<apw> infinity, it works ok as far as i can tell, mostly
<infinity> Which is, y'know, trivial anyway.  Simple config files for Xen, simple command lines for qemu.
<infinity> Or MESSY AS HELL XML files for libvirt.
<smb> infinity, apw also was not very amused, but mostly because of the quality of virt-manager
<infinity> Progress?
<smb> infinity, libvirt itself isn't that bad nowadays
<apw> it did make me mad a few times i guess, but it does seem to do the job pretty well
<apw> thought if i knew what the command lines for each were i might cry that i have been
<apw> through all that pain for something that easy
<apw> lantizia, bug # ?
<lantizia> apw, should I tick it's a security bug?
<infinity> lantizia: No, it's not.
<apw> no
<lantizia> ok :D
<lantizia> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1105230
<ubot2> Ubuntu bug 1105230 in linux (Ubuntu) "Removal of odd OSS options in kernel compile config file" [Undecided,New]
<lantizia> tada!
<lantizia> ooh i feel all warm and fuzzy
<apw> ogasawara, ok pushed and ready for your fun
<ogasawara> apw: awesome, thanks
 * apw isn't sure how keen he is to SRU this back as far as P
<infinity> apw: Seems reasonably harmless to do so.
<apw> infinity, if it just turns off like that i guess so
<infinity> apw: Assuming it doesn't end up disabling some esoteric driver that only built in 3.2
<arges> apw: whats up?
<apw> arges, wondering if your jack based setups use OSS drivers for anything
<arges> apw: no don't use OSS, just jack/alsa/pulse
<apw> ogasawara, i think i may have knobbed it
 * apw is investigating
<ogasawara> apw: ok, I'll wait to kick off new builds
<ohsix> osspd is close to being usable, but not
<ohsix> if you want to follow up on that :p
<ohsix> i couldn't make sense of why some of the io 'slaves' wouldn't exit, mathematica would spawn up to 32 then pulse and osspd would start giving up
<apw> ohsix, the problem here is the preclaim isn't it
<ohsix> yes, i was making a comment about the bug
<lantizia> ohsix, ossp is better (compatibility) wise than anything else out there
<lantizia> I even have an untested patch Tejun wrote for me on the linux mailing list that re-enabled mmap support
<ohsix> i don't disagree, but like i (sort of) said, it is almost trivial to find a case where it breaks
<lantizia> I've got Unreal Tournament, Railroad Tycoon 2, Alpha Centauri, SimCIty 3000 and Return to Castle Wolfenstein.... classic native linux games that _really_ need it to work
<ohsix> particularly the one open() one io slave breaks easily
<apw> ogra_, so would we think that just turning off _PRECLAIM would be enough for the older releases to make this work, to minimise the changes there
<lantizia> wrappers can fail due to incompatible libc implementations and such - so having something that looks like the real OSS is a god send
<lantizia> it's a shame to throw some of the best (and very few) commercial linux games away for just a sound issue
<apw> ogasawara, ok i have fixed raring, soz about that
<ogasawara> apw: no worries, thanks
<lantizia> apw, is this being fixed as far back as 12.04 then? wow
<apw> lantizia, what you running as a test bed.  i would like to see if just turning off one of these works in the odler releases
<lantizia> apw, I'm running 12.04 now
<apw> lantizia, i am thinking about it, the fix i have applied to raring is not goain back
<ogra_> apw, sounds like 
<apw> lantizia, i think it would be too much
<apw> but if turning off _PRECLAIM is enough that we might be able to do
<lantizia> yeah it's just PRECLAIM that is the issue
<infinity> apw: Ah-ha, so it was due to MIXER_OSS, I was right? :P
<ohsix> preclaim doesn't let anyone else get the major numbers for oss
<apw> ok ... i'll get you a kernel to test
<ohsix> in case the alsa/oss shim is loaded later
<ohsix> if you were wondering why there needed to be a preclaim :p
<apw> infinity, some shit i cannot see we would want on when we have OSS turned off officially, but i'll let someone testing raring confirm that :)
<apw> ohsix, yep
<infinity> apw: Well, it was off until that ARM merge, and no one complained in maverick or oneiric.
<lantizia> ohsix, whats "alsa/oss shim" ?
<apw> infinity, right i have no compunction turning it off, but if _PRECLAIM will do that is much easier to justify for SRU
<infinity> apw: True.
<ohsix> lantizia: it's a module from alsa that will wire up OSS to an alsa driver, with all the same drawbacks oss ever had :p (one open will block all users, oss and alsa)
<lantizia> ohsix, ah well - nevermind then lol
<wookey> apw: I filed current state of fix against raring: 
<wookey> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1105251
<ubot2> Ubuntu bug 1105251 in linux (Ubuntu) "Fix cross- linux-tools build" [Undecided,New]
<wookey> I've not checked that native builds are still correct (should be OK, but you never know)
<ogra_> apw, oooh ! i was under the assumption you took all our patches from the qunatal nexus7 kernel, i know for sure the first kernel had loglevel=1 
<ogra_> (which didnt help for these messages either btw)
<ogra_> using the patch you once wrote 
<ogra_> gah, yeah, the patch was dropped :(
<ogra_> console_loglevel = 4;
<apw> ogra_, you should be able to confirm that patch would help via 'loglevel=2' on the kernel command line
<ogra_> will try ... but i'm pretty sure it doesnt catch "err"
<ogra_> iirc it only swallows "info"
 * ogra_ grumbles about the broken reply-to setup of the kernel ML
<ogra_> apw, ok, the majority of messages is gone, i still get "Powering on wifi" "Powering off wifi" all over the screen though
<ogra_> apw, quieten_wifi_power_message.patch quietens that bit
 * ppisati -> rush to the gym
<lantizia> apw, did you say there was a kernel I was going to test for you?
<ogra_> lantizia, no, he said that the fix will go into raring with the next upload
<lantizia> ogra_, I'm sure there was something about just putting the preclaim fix into the previous two releases
<lantizia> and me testing that
<lantizia> lemme find it :S
<lantizia> <apw> ok ... i'll get you a kernel to test
<ogra_> ..."some shit i cannot see we would want on when we have OSS turned off officially, but i'll let someone testing raring confirm that :)" ...
<ogra_> that made me think its raring :)
<ogra_> anyway, you will have a kernel test request in the SRU bug you filed
<lantizia> but before he said what I pasted he was asking what I was running and I said 12.04
<lantizia> o_O what do I do with that then? :D
<ogra_> SRUs dont get into the archive unverified
<ogra_> the bug comment will tell you :) 
<ogra_> (once it is there)
<ogra_> if you are into gaming you should take a look at steam btw ;)
<lantizia> ogra_, already using it :D
<lantizia> Half-Life was released yesterday! lol took them FIFTEEN years to port it to linux :P
<lantizia> i wonder if anything else slipped back into the kernel config options when this ARM version accident merge thing happened
<ogra_> i remember runnning it when UT was recent 
<ogra_> and iirc it ran natively 
<lantizia> nah not HL, but UT was native
<ogra_> hmm, wasnt there a company providing a native runtime for it 
<ogra_> UT ran native, sure 
<lantizia> ogra_, nope... hell even wikipedia is saying it was released yesterday
<lantizia> although the original HL was kinda quake based (modified into GoldSrc)... GoldSrc itself has only just been ported to linux
<ogra_> ah, loki was the name i was looking for 
<lantizia> yeah they ported lots... I have Unreal Tournament, Railroad Tycoon 2, Alpha Centauri, SimCIty 3000 and Return to Castle Wolfenstein to get working with OSS Proxy once this is fixed
<ogra_> right, http://en.wikipedia.org/wiki/Loki_Software agrees with you
<lantizia> what does SRU mean and am I supposed to see it somewhere?
<ogra_> i thought i had HL running with a lokin installer too
<ohsix> but not mathematica bawww
<ohsix> see if the io slaves exit properly for all those games
<lantizia> i hope steam on linux will resurrect UT3 lol -  not willing to place any bets though
<lantizia> ohsix, I wouldn't even know how to check that - and RTCW needs mmap anyway so I can't test that one yet
<lantizia> not until I recompile the kernel with tejuns latest mmap fix
 * henrix -> EOD
<marrusl> I'm having trouble finding definitive proof if /proc/cpuinfo reflects "cpuinfo_cur_freq" or "scaling_cur_freq" from /sys.  I think it's the former, does anyone know for sure?
<vanhoof> marrusl: its scaling_cur_freq
<vanhoof> cpu MHz		: 2701.000
<vanhoof> ==> cpu1/cpufreq/scaling_cur_freq <==
<vanhoof> 2701000
<marrusl> vanhoof, thanks!  
 * cking -> EOW
<vanhoof> marrusl: np!
 * ogasawara lunch
<catbus1> Can anyone tell me if I am right about this? The kernel SRU for 3.5.0 has entered the 2nd phase (verification), and if there is any SRU request, it won't be reviewed until 2 weeks later. And if it's good to go, it will be in the -updates at the end of 2/28, 5 weeks later?
<lantizia> apw, arges, infinity, ogra_, ohsix:  RE: The OSS fix from earlier today....   I got in touch with Tejun (the author of osspd), joined the project on SourceForge and I'm making a mailing list (that'll include previous conversations a few of us have had over the last year or so in email)... would you be interested in being on the list and if so PM me what name/e-mail to add.
#ubuntu-kernel 2013-01-26
<penguin_> is anyone here a developer?
<lifeless> not a one, we're all novellists.
<chiluk> roses are red.
<lifeless> intel is blue
<penguin_> and redshift is amazing
<penguin_> sudo apt-get install redshift && redshift -t 6500:4900 -g 0.77
<penguin_> sudo apt-get install redshift && redshift -t 6500:4900 -g 0.77
<infinity> jjohansen: How did you want to deal with security sign-off for the current precise/quantal SRUs?  They don't technically fix any security flaws, but they're reverts to regressions that we landed in -security.
<infinity> jjohansen: I'm personally inclined to say we should probably copy the lot to security, due to the regression.  Thoughts?
<jjohansen> infinity: hrmm, yes I think copying them to security makes sense.
<jjohansen> hrmm were of the CVE patches where reverted?
<jjohansen> s/where//
<henrix> jjohansen: no, the reverts were not from CVE patches
<infinity> jjohansen: The reverts were purely for fsnotify regressions.
<infinity> jjohansen: But rather nasty ones at that.  I've already hung a couple of buildds due to that kernel.
<jjohansen> okay, I would say yes copy to -security, and if needed I can issue a nop USN detailing that its a fix for regressions
<infinity> jjohansen: That would be lovely.  So, if you could abuse the security-sign-off task to that effect, so the bot sets the right promotion tasks for me, that would be great.
<jjohansen> infinity: alright, it should be done in a couple minutes
<jjohansen> infinity, henrix: I am only seeing the precise tracking bug https://launchpad.net/bugs/1104061, do you have the quantal one handy?
<ubot2> Ubuntu bug 1104061 in Kernel SRU Workflow security-signoff "linux: 3.2.0-37.58 -proposed tracker" [Undecided,In progress]
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1103932
<ubot2> Ubuntu bug 1103932 in Kernel SRU Workflow verification-testing "linux: 3.5.0-23.35 -proposed tracker" [Undecided,In progress]
<infinity> jjohansen: http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html is handy.
<jjohansen> ah, yeah that is quite handy
<jjohansen> infinity: done
<infinity> jjohansen: Shiny, thanks.
 * henrix -> SIGFOOD
<ben1u> hello, I had last night a kernel panic on Ubuntu 12.04 after 7 days uptime. How can I find or dump it?
<ben1u> I mean how I can for the future find why it happened.
<Gaudasse> syslog ?
<ben1u> there is no information about that
<lantizia> apw, ogasawara, is there anyway I (a 12.04 user) can run/test the kernel changes related to #1105230 raised yesterday
<infinity> ikepanhc: Yay for the armadaxp uploads.  Do I get a matching -meta too?
<ikepanhc> infinity: not upload meta packages yet, will do so. upload kernel first because it takes time to build
<infinity> ikepanhc: Yeah, but no harm in doing both together, I don't copy them from the PPA until everything's ready.
<infinity> ikepanhc: (And it means you don't have to babysit)
<ikepanhc> :)
<infinity> ikepanhc: I'll go grab some breakfast and hope to see a meta when I get back. :)
<slain> hello
#ubuntu-kernel 2013-01-27
<infinity> ikepanhc: I guess I don't get metas afterall?
<infinity> ikepanhc: (This is what I meant by "if you upload them all at once, you don't have to babysit", cause I could be promoting and moving this mess along by now)
<ikepanhc> infinity: just uploaded, shall be done in any minutes.
<ikepanhc> infinity: fall to sleep too early yesterday :p
<infinity> ikepanhc: My clock's completely backward.
<infinity> ikepanhc: Ack.  You still there?
<infinity> ikepanhc: You dropped the changes from the last upload in your quantal meta.
<infinity> ikepanhc: err, precise, I mean.
<ikepanhc> infinity: eh... let me check again
<infinity> https://launchpadlibrarian.net/129646059/linux-meta-armadaxp_3.2.0.1613.19_3.2.0.1614.19.diff.gz
<ikepanhc> infinity: eh, you are right, give me another 10min
<infinity> ^-- That should have been 3.2.0.1614.20 and included the changes from 3.2.0.1613.19
<infinity> Hrm, it could be that Andy forgot to commit that revision to git.  That would do it.
<ikepanhc> I will replay it. Just 10min
<ikepanhc> uploaded, wait ppa finishing package verify
<infinity> ikepanhc: Would have more sense to keep Andy's previous changelog, and then just do your version bump on top, but oh well.
<infinity> ikepanhc: Other than the changelog being weird, this at least produces the same source and binaries, so I'm happy enough with it.
<ikepanhc> infinity: is there any guidebook for debian packaging? I am starting to think it would be better if I can read it
<infinity> ikepanhc: Well, I'm not sure a guide book here would have helped, it's just common courtesy to not wipe out a previous changelog entry. :)
<infinity> (In this case, I doubt Andy cares about attribution, so the diff is just "weird", rather than anything else)
<ikepanhc> yes, that's what confusing me, since we have two .1614.19 in changelog. that will make changelog weird in any way
<infinity> Well, my suggestion would have been to just include Andy's change, and then change your version to 1614.20, dropping the 1614.19 change entirely.
<infinity> But too late now.
<infinity> Since you can't reuse 1614.20, and doing ANOTHER upload just to twiddle the changelog more is pretty pointless.
<ikepanhc> infinity: btw, thanks for the review. I am glad that you let me know that I shall review the diff after upload
<infinity> ikepanhc: s/after/before/
<infinity> ikepanhc: Please. :P
<infinity> ikepanhc: Grab the old source, and "debdiff old.dsc new.dsc"
<ikepanhc> understood.
<infinity> After is a little late, especially in the case of "oops, I did something weird and now I can't reuse that version number, so I get to have a strange changelog that documents my mistakes or mysteriously skips version numbers to hide them". :)
<infinity> So, for the sake of buildd resources and your own pride, review diffs before upload. :)
 * ikepanhc nods
<ikepanhc> I can not agree more
<infinity> People staging in PPAs actually get it a bit rougher here.
<infinity> Cause once you've uploaded to the PPA, the version is used up, and the package has eaten a few buildds.
<infinity> People uploading directly to $stable-proposed get to have me yell at them from a queue review, and I can reject the package and they can redo it as if it never existed.
<zequence> apw: lowlatency sources are updated. Did you want me to do something more this time?
#ubuntu-kernel 2014-01-20
<ppisati> it's monday! :)
<ppisati> 3.13 is out. rejoy!
 * smb re... err enjoys his Monday cup #1
 * apw yawns extravigantly
<brendand> cking, hi
<cking> brendand, hi there
<brendand> cking, i've got a little fwts conundrum
<cking> what's the problem?
<brendand> cking, if a test has some subtests that are skipped, the overall status will be skipped
<brendand> cking, at the moment we ignore skipped tests, even though some of the sub tests may be FAIL as well
<cking> brendand, ok, which particular test(s) are that give you that issue?
<brendand> Test           |Pass |Fail |Abort|Warn |Skip |Info |
<brendand> ---------------+-----+-----+-----+-----+-----+-----+
<brendand> method         |  286|   18|     |     |  121|     |
<brendand> ---------------+-----+-----+-----+-----+-----+-----+
<brendand> Total:         |  286|   18|    0|    0|  121|    0|
<brendand> ---------------+-----+-----+-----+-----+-----+-----+
<brendand> cking, can we ignore the Fails because the overall status was Skip?
<cking> brendand, give me a an example of a test so I can get some better context
<brendand> cking, the 'method' test - as here
<cking> so why can't you just check for FAILs first as these take precedence
<brendand> cking, we use --stdout-summary
<brendand> cking, that says SKIPPED
<cking> OK, that sounds like a bug, I'll look at that today
<cking> yep, I'll fix that so it reports FAILED if any fails are found, it looks like it picks up an inherited status from the last subtest
<cking> brendand, thanks for spotting that
<cking> ok, figured out the bug, I'll send a patch out today
<brendand> cking, i can create a subtask to our checkbox bug and could you update that when it's fixed?
<cking> brendand, sure
<brendand> cking, https://bugs.launchpad.net/fwts/+bug/1252186
<ubot2> Launchpad bug 1252186 in checkbox "Some HIGH/CRITICAL failures in fwts related tests cannot be detected by checkbox" [Medium,In progress]
<apw> cking, you are gnuplot savvy, my old plots which plot to gnuplots own interactive mode "click to dismiss" stylee, have stopped working after upgrades, you seen that ?
<cking> apw, no, I've not used it on trusty
<cking> normally I have to grok the docs or google for stuff in gnuplot as I can never remember how to use it 
<apw> its almost like the default terminal is not 'x-window' any more
<cking> hrm, that is annoy
<cking> ing
<apw> whe you start gnuplot on saucy what does it say terminal is set to ?
<cking> apw, i really can't recall (useless eh?)
<henrix> apw: Terminal type set to 'wxt'
<apw> ahh ta
<cking> wxt? what's that?
<henrix> no idea!  haven't been using gnuplot for ages :p
<apw> probally WindowXTerm or something
<apw> and 'wxt' is not an option any longer
<apw> bah
<smb> The world is constantly changing to annoy us
<ppisati> don't worry, i heard there's a comet going struck us.. it won't be for long...
<apw> smb, this raid56 thing you did.  you know it can't do anything but offset 0... can we use device mapper to fix where its not at offset 0?
<apw> smb, ie, lay down a linear mappnig at offset N which makes a device we can use at offset 0
<smb> apw, raid45 but yes it probably might be done. Technically no problem more a question how well that fits into userspace
<apw> smb, like my md raid0 inside lvm things
<apw> smb, welll i thnk you make up that table for the new type in userspace?  so i think its a matter of makng the table bigger in the same place ?
<smb> apw, And I did not want to spend too much effort if there would in practice be no offsets != 0
<smb> apw, Currently the userspace does not create linear tables for the raid drives
<apw> indeed, and i do wonder (in my email reply) if we should have a call-for-testing on it, to try and find out
<smb> apw, So it is a matter of adding that functionality
<apw> as yes, if there are none, it is moot
<smb> apw, All true... actually I probably should email out the code oto ubuntu-devel as I have not heard anythng aback from xnox 
<apw> right, the linears mappings would be supurflous if there is no offset, just popped into my head when replying and thought i would put it in yours so i can forget :0
<smb> apw, Yeah
<apw> henrix, beat me to it with the cves :)  nice
<smb> Oh yeah, that scary one
<henrix> apw: :)
<henrix> apw: it was tagged for stable, so it was easy to spot
<apw> ahh i found it the a different way, but when i went to paste it in, there it was :) and the autotraiger had started chewing on it 2m before
<apw> henrix, ugg, this huge patch is erm huge.  I think we might need another fix patch which I have pointed to in my reply.
<henrix> apw: looking...
<apw> henrix, otherwise it looks to be ported as correctly as any review can see anyhow
<henrix> apw: yeah, you're right.  it looks like we should also apply f81152e3
<henrix> hmm... i'll need to go throught the stable trees as well to make sure all kernels have this fix
<henrix> apw: thanks ;)
<apw> henrix, thank you indeed
 * henrix goes have some food before looking at this
<apw> a plan indeed
<Faux> My Trusty HP EliteBook 8570w with an GK107GLM [Quadro K2000M] hardlocks going into X on 3.13.0-4, only gets vesa-y resolutions (800, 1024) on 3.13.0-2 (and sometimes X just vanishes), but works fine on 3.13.0-1.  How do I report this?
<apw> ubuntu-bug linux to file a bug against the kernel
<Faux> Okay, cheers. :)
<Faux> Hah, it refuses as I'm booted into a kernel that's no-longer in the repo.
<henrix> apw: ok, looks like all the stable trees already contain the additional fix.  shall i update the cvetracker to include this additional sha1?
<Faux> #1270818 is my bug report, if anyone has any questions.
<apw> henrix, yeah i recon so
<apw> bug #1270818
<ubot2> Launchpad bug 1270818 in linux (Ubuntu) "nouveau(?) breaks or hangs in 3.13.0-4, -2, but not -1 on GK107GLM [Quadro K2000M]" [Undecided,New] https://launchpad.net/bugs/1270818
<henrix> apw: ack, will do
<cjwatson> I could use help in tracking down bug 1270228, if anyone has some time
<ubot2> Launchpad bug 1270228 in linux (Ubuntu) ""Loading partman-xfs failed for unknown reasons. Aborting" error in trusty server installations" [Undecided,New] https://launchpad.net/bugs/1270228
<smb> apw, Are you looking at this ^?
<apw> smb, i am not currently, are you interested in poking that ?
<smb> apw, Yeah I can have a look. Just wanted to avoid us going off both on the same
<xnox> I am back from holliday and rebooted my desktop.... which did not end well.
<xnox> linux-image-3.13.0-1-generic boots, while linux-image-3.13.0-4-generic does not.
<xnox> i get bad screen resolution, kernel tracebacks, dropped into busybox which says that my rootfs device by uuid is not present =)
<cjwatson> smb: one thing I forgot to say: to reproduce the out-of-memory part of it, you'll need kvm -m 512 or otherwise limit memory to match what the CI testing is doing
 * xnox is puzzled.
<xnox> (otherwise it's fully up to date)
<smb> cjwatson, Ok, ack. 
<apw> xnox, nvidia graphics ?
<xnox> apw: intel hd / motherboard built in, I may however have inappropriate amount of *gl* packages installed which pulls in all sorts.
<smb> xnox, I think I saw someone else having issues ... but that was with vmware gfx. Maybe check whether you see some issues with the drm driver and simple-framebuffer..
<BenC> apw: I'm rebasing on master-next for trusty, if that will be of any help
<xnox> apw: i'll wait for nvidia upload, and test that kernel, to shoot down one thing at a time.
<apw> BenC, thanks, thats on my list for 'next' :)
<BenC> apw: Ok, it's done
<smb> apw, Hm, would you know from the top of your head whether rootfs might be closely related to tmpfs?
<smb> apw, Or iow I wonder whether the "maddening" part of d1969a84dd6a44d375aa82bba7d6c38713a429c3 could not be true for rootfs
<cjwatson> I think rootfs is a tmpfs instance if you have tmpfs enabled and aren't using rootfstype=.  See init/do_mounts.c
<smb> cjwatson, So that might lead to the above commit which is not yet in 3.13.0-4 to be a possible culprit
<cjwatson> I certainly wouldn't have got there from the commitdiff, but the description looks plausible
<smb> Yeah, the change looks like and OMG but not directly would lead to the  effect
<cjwatson> tmpfs does indeed use percpu counters to keep track of block usage
<smb> So I would add that to the bug report and I am sure someone is already preparing a rebase to 3.13 release version
 * smb is away for a bit
<apw> Faux, test kernel in your bug
<apw> smb, ok that commit is in the tree now, there is a test kernel by luck with it in on http://people.canonical.com/~apw/lp1270818-trusty/ if that helps
<apw> though i was proposing to upload it today anyooo
<apw> smb, and as you correctly say the existing -4 does not have that fix
<Faux> apw: Sorry, I don't follow.
<apw> Faux, i have built a test kernel which may fix your issue and posted the link to it in your bug
<Faux> Ah, I shall have a look tomorrow (work machine).
<Faux> Thanks.
<apw> ogasawara, i am thinking about wrapping up a new trusty with 3.13 in it, anything pennding from you ?
<apw> smb, did you bottom out on whether that percpu fix was your issue ?
<cjwatson> it looks very likely to me ...
<apw> ok i will get this thing tied up with string
<SpamapS> Anybody hear reports about ext4 resize problems with 3.11.0-15-generic on i386?
<apw> SpamapS, not that has come to my notice
<SpamapS> apw: I may have had some corruption.. trying to reproduce
<smb> apw, Yeah as cjw said, it looks quite likely. And since it needs to be tied up into an installer iso and we are very likely doing the 3.13 final soonish anyway...
<smb> SpamapS, There was something that I remember only very vaguely. Though it may have been an unusually large resize and I cannot remember exactly whether that was at that point just not done before or broken. Nor can I remember whether it got solved or was lost to workstack overflow...
<smb> Hm rather looks like forgotten... bug 1233075
<ubot2> Launchpad bug 1233075 in linux (Ubuntu) "resizefs failure with raring" [High,Confirmed] https://launchpad.net/bugs/1233075
<apw> smb, hmmm maybe indeed
<apw> though i thought we saw some fixes for things like that recently
<smb> apw, Which one? the resizefs?
<apw> yeah particularly ext4 extending i thought ... hnmm
<smb> apw, Not sure, somewhere in the bug report it was said that resize to 20G might be enough to reproduce, so I would try that tomorrow with T (if I can remember that long)
<apw> smb, sounds like a plan
<pkern> http://www.heise.de/newsticker/meldung/Kuenftiges-Init-System-der-Linux-Distribution-Debian-Zwischen-Patt-und-allgemeiner-Abstimmung-2088684.html
<pkern> Oops, sorry. Not meant to paste that. -_-
<tilgovi> apologies if this is not a good channel for a support question like this... i just got the brand new x1 carbon (i7) from lenovo and I've got it all set up and dual booting fine, but resume from suspend doesn't work and I was hoping someone could help me debug it.
<tilgovi> the big issue is that this model has no leds for hd activity and pressing buttons seems to do nothing at all to resume
<tilgovi> so the debugging pages about resume are not helpful. there's little info to collect. the suspend log looks normal, but i don't even know how to begin looking at the resume
<tilgovi> again, I know this isn't a support channel, but since i'm able and willing to dive deeply in here, and there are probably few people with this hardware right now, i thuoght i'd come straight to the kernel folks
#ubuntu-kernel 2014-01-21
<phillw> hi good people.. i seem to have builds
<phillw> ali@amjjawad:~/src/linux-3.13$ ls /boot/*3.13*
<phillw> /boot/config-3.13      /boot/initrd.img-3.13.0  /boot/vmlinuz-3.13
<phillw> ali@amjjawad:~/src/linux-3.13$ 
<phillw> what is the nest step?
<phillw> ali@amjjawad:~/src/linux-3.13$ ls -al /boot/*3.13*
<phillw> -rw-r--r-- 1 root root    161299 Jan 20 21:13 /boot/config-3.13
<phillw> -rw-r--r-- 1 root root   2116315 Jan 20 21:14 /boot/initrd.img-3.13
<phillw> -rw-r--r-- 1 root root 131261285 Jan 20 23:08 /boot/initrd.img-3.13.0
<phillw> -rw-r--r-- 1 root root   2475801 Jan 20 21:13 /boot/System.map-3.13
<phillw> -rw-r--r-- 1 root root   5357936 Jan 20 21:12 /boot/vmlinuz-3.13
<phillw> sorry, missed the file sizes
<phillw> oops.. runs away.. this was a debian installer issue... sorry.
<ppisati> yup
<apw> ppisati, yupper ?
 * apw yawns at the moon
<Faux> bug #1270818 apw: That new kernel is delicious and seems fine, thanks.
<ubot2`> Launchpad bug 1270818 in linux (Ubuntu) "nouveau(?) breaks or hangs in 3.13.0-4, -2, but not -1 on GK107GLM [Quadro K2000M]" [Medium,Incomplete] https://launchpad.net/bugs/1270818
<Faux> I commented the ticket.
<ppisati> apw: can you still see the moon over there?
 * ppisati is reading kernelnewbies 3.13 summary...
<apw> ppisati, a laudible goal ... and no, no actual moon
<smb> apw, Ok, that was painful but you got the second ack for henrix cve patch now
<henrix> \o/
<smb> apw, About the resize problem... I wonder whether I should maybe sit back until the the 3.13 rebase is in the daily so the percpu counting thing has not chance to have another weird effect
<apw> yeah possible
<apw> smb, ack ta
<Kano> Hi, why is 3.13 final without .orig.tar.xz?
<apw> lazyness
<apw> smb, -5 just hit -release
<xnox>  -5 solved my boot problems (compared to -4) so I'm happy =) thanks everyone.
<apw> xnox, great
<smb> apw, Ok, kinda failed replacing the kernel inside the cloud.image and did the resize with the -4 kernel. This surprisingly worked though leaving a 30G image pretending to be almost full (so ext4 suffered as well at that point). Reboot with -5 made things look good again. So there is a chance that resize is working except with that ugly kernel
<apw> smb, yeah sounds plausible
<brendand> bjf, those -proposed kernels still held up?
<smb> apw, Ah I found the resolution about the resize problem in the past. It was the journal overflowing (when creating the image small and then resize to quite large). Not sure whether the kernel can or actually does better recovery for that now but in general it should be avoided by the cloud-images now being created with an explicit journal size large enough to handle the resize
<smb> SpamapS, ^ But your issues may have been related to the percpu counters madness (if you used the 3.13.0-4 kernel
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 4th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* jsalisbury changed the topic of #ubuntu-kernel to: <new topic message>
<SpamapS> smb: regarding resize issues.. I do have a very large resize reserved because I am making cloud images where I don't know how big the root will be...
<SpamapS> bin/disk-image-create:MKFS_OPTS="$MKFS_OPTS -E resize=274877906944"
<SpamapS> smb: but, as yet, I have not recreated the problem
 * apw reboots to get a kernel which can add up right
<apw> that makes a heck of a difference, some 28G of space was mia
<jsalisbury> op #ubuntu-kernel
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 4th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<sforshee> hallyn: anyone I should cc when I send this tty patch upstream? Right now I have you and ebiederm.
<hallyn> sforshee: that's probably good...  since alan cox gave up on tty i'm not sure;  maybe greg kh.
<hallyn> but eric and me + lkml is good
<sforshee> hallyn: greg is one of the maintainers so he'll be included
<sforshee> should be going out soon
<hallyn> sforshee: great, thanks.  whatever happened to tracking down who's pinning the console?
<sforshee> hallyn: I updated the bug earlier. lxc sets /dev/kmsg as a symlink to /dev/console, and upstart opens /dev/kmsg.
<hallyn> sforshee: aaah.  interesting.  last night i looked to see if lxc could be to blame and i noticed the kmsg handling but figured that was just a bind mount and couldn't be it :)
<sforshee> hallyn: I'm not really sure if lxc needs to do something different or if upstart needs to realize that kmsg might be a symlink and use O_NOCTTY. I'll let you and jodh fight that one out ;-)
<hallyn> sforshee: i'm probably ok saying that we just don't redirect kmsg for unprivileged containers;  but then if the kernel patch goes through it's moot.
<sforshee> hallyn: I think it's an undesirable situation with or without the kernel patch
<apw> sforshee, are you sending this patch to "us" as well ?
<sforshee> apw: yes after upstream validates its correctness
<sforshee> apw: I added cc stable anyway, so assuming it's acceptible it will get to us one way or another
<apw> sforshee, sounds perfect thanks
<bdmurray> xnox, cjwatson: given the precise branches of ubiquity are out of date how should I submit a fix for bug 1051935 for 12.04.4?
<ubot2`> Launchpad bug 1051935 in ubiquity (Ubuntu Precise) "Fails with SystemError when too many files are open" [High,Triaged] https://launchpad.net/bugs/1051935
<cjwatson> bdmurray: https://code.launchpad.net/~ubuntu-installer/ubiquity/precise-proposed looks up to date to me
<cjwatson> we don't care about the UDD ones
<bdmurray> cjwatson: ah, okay thanks
#ubuntu-kernel 2014-01-22
<miseria> "compartimos nuestro planeta, dando lo lindo de nuestra vida y olvidando lo propio, cuidate y piensa en ti" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<ppisati> hallo :)
<ppisati> dawn of the irc channel
<apw> thats not dawn, thats night of the living irc channel
<ppisati> :)
 * smb moans
 * apw does his best zombie impressions -- *Bwains*
<smb> apw, I don't think we do have to do much to make zombie impressions... :-P We are natural at this time of day
<dholbach> hiya
<dholbach> could somebody have a look at https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1256949 please and see if there's anything left to be found out by the reporter?
<ubot2`> Launchpad bug 1256949 in upstart (Ubuntu) "Dell Latitude E5420 doesn't boot if killswitch is turned to "radio off"" [Undecided,Incomplete]
<dholbach> jodh, ^ was there anything left to be done by the report from your end?
<jodh> dholbach: I've added a couple of extra ideas on the bug.
<dholbach> thanks jodh
<apw> jodh, that --debug screenshot does not seem to ahve any upstart debugging yet rc is clearly run, they cannot have done it right can they ?
<apw> jodh, or does it, and it just stops saying anything "way up there"
<apw> dholbach, jodh, anyhow as johd says the machine is "up" but stuck and we need to see what it is doing and for that the console somewhere is going to be needed me thinks
<jodh> apw: hmm, I think you are right - looks like they booted with --verbose instead.
<dholbach> apw, I'll tell the guy with the laptop to have a look at the bug again  :)
<apw> jodh, it is also odd tehy cannot get a shell on ttyN given it gets pretty far and "starting" has definatly fired
<jodh> apw: ack. I've put a few other thoughts on the bug.
<apw> henrix, i take it you arbitrarily added the "rose" fix to just CVE-2013-7266 
<henrix> apw: yes, i did added to the cvetracker
<apw> henrix, but only on that one not all 10 or so
<henrix> apw: hmm... right, only in *one* CVE.  i'll go add it to the others as well
<apw> henrix, i ask cause quatal is showing just that one not fixed of the set
<henrix> apw: ah, i didn't took a look at the matrix since yesterday.  /me goes fix that
<henrix> apw: thanks
<apw> np
<apw> henrix, as none of those are actualy "rose" related CVEs technically they _are_ fixed then the first commit is on, we want the second as a fix for the first but the CVE is fixed without it
<apw> just rose no longer works right.  so from a CVE tracking point of view we probabally don't care about the second one, only that it does get applied
<henrix> apw: yep!  so... you're suggesting that i should open a bug instead?
<apw> yeah i think with hindsight adding it to the tracker is a fail, and we should just track it with a bug
 * henrix was about to push the cvetracker changes...
<apw> as we will say we fixed the cve much later than we did with the second commit in there, as they came in separate upstream stables
<henrix> apw: just fyi: bug #1271519
<ubot2`> Launchpad bug 1271519 in linux (Ubuntu) "Restore old recvmsg behavior after CVE-2013-7266 fix is applied" [Undecided,Triaged] https://launchpad.net/bugs/1271519
<apw> henrix, hey thanks ... will have a think about using the bug to trigger self closure :)
<henrix> apw: no prob.  i'm reverting the additional sha1 from CVE-2013-7266, leaving a link to the bug# in the commit comment
<henrix> apw: just to be clear, i am reverting it from the cvetracker :)
<apw> henrix, got you indeed thanks
<vic1>  Is git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git maguro branch the right kernel ?
<vic1> for Galaxy Nexus phone
<vic1> I have a need to re-build the kernel for latest touch 14.04 running currently on my Galaxy phone
<vic1> When i try to install my compiled kernel with latest ramdisk, i get a crash with init crashing
<vic1> hd_attach thr:60 started
<vic1> Broadcom Dongle Host Driver: register interface [wlan0] MAC: 00:90:4c:11:22:33
<vic1> wifi_set_power = 0
<vic1> <3>Invalid Device Structure
<vic1> =========== WLAN placed in RESET ========
<vic1> <6>fsa9480 4-0025: cable detect change, from 'unknown/none' to 'usb-peripheral'
<apw> there are similarly named branches in the trusty repo for the trusty release
<vic1> apw: was that answer to my query?
<apw> vic1, it was intended for youyes
#ubuntu-kernel 2014-01-23
<vic1> Kernel Experts: 
<vic1> Could i get the exact kernel source git tree that was used to generate: trusty-preinstalled-boot-armhf+maguro.img
<vic1> Maguro(samsung galaxy nexus) Kernel source tree is what i am looking for Ubuntu Touch.
<ppisati> moin
<apw> ppisati, moin
<smb> apw, If you ain't hearing anything your mumble is broken
<apw> or my ear is currently remote
 * apw bets 10p on the latter
<smb> or that
<smb> apw needs ears on strings
<hvn3> hi, I run precise on armhf (beagleboard-xm) and need to add xenomai. I tried codesourcery but that doesn't do it. Linaro people directed me here. Can someone please help me out. Thank you.
<brendand> cking, hey - which of your ppa's has the version of fwts with the stdout-summary fix?
<cking> https://launchpad.net/~colin-king/+archive/ppa, but only a trusty build
<cking> brendand, we hope to spin a 14.01.01 release to address this before the week is out
<brendand> cking, ok
<apw> hvn3, not sure what you are asking really?
<brendand> cking, when will 14.01.01 be out?
<cking> brendand, hopefully end of this week if it builds OK today
<hvn3> apw: I'm asking if someone here can direct me to info on cross-compiling a xenomai-patched precise-kernel to armhf
<hvn3> apw: it needs to run on omap3
<hvn3> apw: the tools I have found so far only cross-compile to either armel or armv6, not to armhf and armv7
<ppisati> hvn3: i'm reading the xenomai doc right now
<ppisati> hvn3: hold on
<hvn3> ppisati: ty
<ppisati> hvn3: you already did the "scripts/prepare-kernel.sh --linux=..." step, right?
<ppisati> hvn3: you just need to recompile a patched kernel, don't you?
<hvn3> ppisati: at got stuck at that point, because it tells me the kernel is unsupported.
<hvn3> ppisati: I used a vanilla-kernel btw, not a ubuntu kernel-source
<ppisati> hvn3: https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile
<ppisati> hvn3: FAQ section, point 6
<ppisati> hvn3: make ARCH=arm omap2plus_defconfig
<ppisati> hvn3: edit .config to suit your need
<ppisati> hvn3: (you better try it with make ARCH=arm menuconfig since - i guess - xenomai adds some menu entries and you want to select that)
<ppisati> hvn3: and then
<ppisati> hvn3: make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- uImage
<hvn3> ppisate: I read that now....I stopped reading that because it mentioned omap4
<ppisati> hvn3: when you did "scripts/prepare-kernel.sh --linux=..." did you use the --arch= switch?
<ppisati> hvn3: "3) Ok, but what about my Beagle/XM? How do i compile a kernel for an omap3 board?"
<hvn3> ppisati: does arch=arm differ from ARCH=arm ?
<hvn3> ppisati: I used arch=arm
<hvn3> ppisati: not in capitals
<ppisati> hvn3: ARCH=arm is used during the kernel compilation, --arch=arm is when you patch the kernel src tree with xenomai
<ppisati> hvn3: ok, there's some confusion let me recap...
<ppisati> hvn3: these are the steps that you should take to make it work:
<ppisati> hvn3: (since you are using a vanilla kernel) checkout a vanilla tree somewhere
<ppisati> hvn3: make ARCH=arm omap2plus_defconfig
<ppisati> hvn3: edit .config as stated in https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile, FAQ point 6, subsection b
<ppisati> hvn3: make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- uImage
<ppisati> hvn3: and follow the remaining step
<ppisati> hvn3: if it boots, then you have kernel tree and .config that you know it works with your hw and your userspace
<apw> hvn3, arch=arm and ARCH=arm are completly different to make
<ppisati> hvn3: after that (make a backup copy of .config)
<ppisati> hvn3: and follow the xenomai instructions
<ppisati> hvn3: scripts/prepare-kernel.sh --linux=$YOURKERNELTREE
<ppisati> hvn3: sorry, add the "--arch=arm" switch at the command above
<ppisati> hvn3: make ARCH=arm menuconfig and tweaks the config
<hvn3> ppisati: yes, I tried that and got error, but will try again
<ppisati> hvn3: and finally "make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- uImage" and follow the rest
<hvn3> ppisati: thank you for helping out so far
<ppisati> hvn3: first make sure you have a vanilla kernel AND a vanilla config working with your hw, then take the xenomai patches
<ppisati> hvn3: because if you start patching a kernel that you never tested, you'll never know if those patches are bad, the config was already broken, the kernel didn't support your board, etcetc
<ppisati> hvn3: baby steps
<hvn3> ppisati: I have the 3.2.0-55-omap kernel running right now....would it be safer to get a ubuntu-kernel source ?
<ppisati> hvn3: the kernel that you are going to use depends on xenomai (since you want to patch it with it later on), so which kernel does xenomai support?
<brendand> cking, someones hooking me up with a test system - i'll let you know in a few hours if it works
<cking> brendand, ok, thanks
<hvn3> ppisati: as far as I see, the xenomai FAQ only mentions the hardware it supports, not kernels. So I assume it supports all recent kernels.
<ppisati> hvn3: i wouldn't be so sure, you better find out first
<ppisati> hvn3: and when you found out which kernel it supports, you make that version work (config and compilation wise) with your board
<ppisati> hvn3: and only after that, you apply the xenomai patches, reconfig and recompile
<hvn3> ppisati: ok, ty for the advise
<hvn3> ppisati: ty for your help and time
<apw> ppisati, do we still support linux-fsl-imx51 in lucid (i presume not)
<ppisati> apw: nope
<ppisati> apw: we dropped support for all the arm topic branches in L AFAIK
<apw> great
<ppisati> apw: cve?
<apw> yeah, just noting we are running processing on that branch for nothing, so getting rid of it
<brendand> cking, the fix looks good. cheers!
<cking> brendand, cool, thanks for letting me know :-)
<zequence> infinity: There's a problem with the saucy -lowlatency. From what I can tell, it includes the right code, but the debian/changelog file only shows 3 master commits since 3.11.15
<infinity> zequence: Oops.  Want to fix that up?
<infinity> zequence: I'm in no rush to copy it over ASAP.
<apw> zequence, you hsould be able to reset to the previous lowlatency tag and remake it
<zequence> apw: Ok. I'll try that
<zequence> infinity: apw: I'm applying for upload rights to ubuntustudio-* packages. Also, linux-lowlatency, but I suppose that might not be necessary anymore. If anyone of you could endorse me that would be really helpful. micahg is the person who has been most active in sponsoring our packages, so he'll probably add a few words here too https://wiki.ubuntu.com/zequence/DeveloperApplication
<zequence> I realize you don't know that much about my packaging skills, and tbh, I need a lot more practice, but the ubuntustudio-* packages are pretty straightforward, and I do maintenance on most of them
<zequence> Things went better with saucy this time. I'm uploading soon
<zequence> infinity: did you get the reject message too?
<infinity> zequence: Why would I get reject messages on your uploads?
<infinity> zequence: You didn't reuse the same version number did you?
<infinity> zequence: You can't reuse versions, even if you delete the old one.  Just bump the build number, so it's -7.10
<infinity> (Don't bother with a new changelog entry, just edit the top line and re-tag and rebuild the source)
<infinity> 17.10, even.
<zequence> infinity: Just guessing. LP might be able to send pigeon post until I know it doesn't ;)
<zequence> infinity: It's up now.
<infinity> zequence: Great, thanks.
<brendand> does anyone know what is happening with the -proposed kernels?
<brendand> are they waiting for 12.04.4 release?
<apw> brendand, that is my understanding yes, that they are all holding for the point release which in and of itself was delayed
 * apw muses that if they hold much longer we might consider respinning them for stables throughout
<rtg> apw, here is a 3.13 bug we ought to keep an eye on (from LKML): '[BISECTED] Linux 3.12.7 introduces page map handling regression'
<rtg> smb, ^^
<apw> rtg, looking
<smb> rtg, hm looking
<rtg> dunno if it requires 3.13 host as well
<smb> Hm, yeah that sounds like something we had reports too and was somewhat related to anonymous pages (at least that flag seemed present most of the times)
<rtg> apw, smb: here is another good one: 'fanotify use after free.'. Seems like 3.13 might have some gotchas for awhile.
<apw> rtg lets be glad we ahve a few stables before release
<rtg> oh yeah
<smb> rtg, Uhm, well for those bad page thing... not sure how much of numa code was around then but we got a bug report unresolved for something looking reaaalyly similar for Lucid
<smb> Need to try that testcase there
<rtg> apw, you (or your minion) are still planning to produce a low-latency kernel for Trusty, right ?
<apw> rtg, yeah, the question which has been raised is as to whether to pull it into master-next
<rtg> apw, are there no extra patches now ?
<rtg> apw, perhaps you should add this to the sprint agenda
<apw> there is one patch, but that changes the default for a configuration option
<apw> so we could carry that and it be only config them
<apw> rtg, already on there
<rtg> apw, ack
<apw> i was presuming i would sort out the fat kernel and meta in a ppa, we could decide that on monday and upload them together or not
<rsalveti> apw: rtg: did a rebase for manta (aosp 4.4.2) based, tested and working fine with the 4.4.2 port that I'm working on: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/manta-kitkat
<rsalveti> can any of you get this merged into the 'manta' branch and upload the package to the ppa? don't yet upload to the archive as we need to first switch the android code officially (like done with mako and flo)
<rtg> rsalveti, acl
<rtg> ack*
<rsalveti> rtg: thanks
<rsalveti> rtg: would also be nice to have the meta package in the ppa as well
<rtg> rsalveti, I didn't think y'all were using a meta package
<rsalveti> rtg: it's used by our android build system to find the package name (because of the abi)
<rtg> rsalveti, ok, can do
<rsalveti> awesome, thanks!
 * apw reboots to test a grub2 beta
 * apw is somewhat supprised to be back ..
<apw> cjwatson, just installed and booted my efi system (secure boot _off_) with your new grub2 from -proposed
<apw> cjwatson, all seems to be ok, only noticed a '*' marker on the menus, other than that it seemed the same
<cjwatson> I think that was deliberate
<apw> it didn't seem like a bad thing, just noticed it
<cjwatson> apw: yep, http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=a59a9826fd56efe350933ef73cba3a42b97a52b9
<apw> cjwatson, it seems to let me select other kernels, and edit things, i have an issue with ctrl- not working in the exec screen but i seem to remember that was there before for me
<apw> cjwatson, but worth checking next reboot if ctrl-x works ok for you
<cjwatson> apw: ok.  does the help screen still advise ctrl-x?
<apw> yeah, the help is the same, and F12 or whatever it is works ok
<apw> i think it is a bios issue, as hitting C-x gives me an X 
<cjwatson> even outside grub?
<apw> only in grub
<cjwatson> bit sceptical of that being a bios issue then
<cjwatson> I vaguely recall some attempt to improve EFI keyboard handling but I can't find it now
<apw> i'll downgrade and confirm its there before either way
<cjwatson> ta
<apw> cjwatson, ok confirmed ctrl- issue is there in the 2.0.22 version as well
<cjwatson> ah ok
<cjwatson> so I guess that could just be crazy bios
<cjwatson> thanks for the testing
<apw> yeah i suspect so, and it is a pre-release job, so i am not so concerned about it
<rtg> rsalveti, manta -5.20 uploaded. I'll get the meta package in a bit
<apw> and i have "or Fn" keys which work just fine
<rsalveti> rtg: great, mind also doing the meta package for flo?
<rtg> rsalveti, np
<rsalveti> awesome
<kirkland> I'm curious if anyone here has experience using amtterm to get console output on Ubuntu?
<kirkland> I have a couple of systems that have Intel AMT enabled;  and I can use it successfully to remotely power on/off systems
<kirkland> but I haven't succeeded yet with getting console output
<kirkland> I've tried following http://manpages.ubuntu.com/manpages/trusty/en/man7/amt-howto.7.html
<kirkland> but that manpage talks about inittab, which, of course, doesn't exist in Ubuntu
<kirkland> cking: you seem like my most likely candidate to have tried ^  :-)
<cking> kirkland, i've not used that
<kirkland> cking: bummer
<mjg59> I have also not tried that
<kirkland> mjg59: wow, you either, huh?
<mjg59> I've played with most of the other features. And cried.
<kirkland> mjg59: it's a bit wonky, isn't it
<kirkland> where would I put "T2:2345:respawn:/sbin/getty ttyS2 115200 vt100-nav", if not inittab?  I'm guessing somewhere upstarty...
<mjg59> kirkland: /etc/init/ttyS2.conf
<mjg59> kirkland: Compare to tty1.conf, etc
<kirkland> mjg59: excellent, thanks
 * cking likes the man page section "More fun with AMT",  yeah, right
<kirkland> cking: :-P
<kirkland> cking: self-extracting archive
<cking> fun as in "poking oneself in the eye with a red hot poker"
<kirkland> heh
<kirkland> cking: oh, btw, I encountered something very odd this week, something that gave me many hours of headache
<kirkland> cking: realtek USB ethernet adapters
<kirkland> cking: we had a bunch of them, all identical, some worked, some didn't
<kirkland> cking: ie, dmesg could see some, but not others
<cking> kirkland, duds or something more bizarre?
<kirkland> cking: perhaps more bizarre; not dudes
<kirkland> cking: after poking at it for several days, we noticed that the ones that didn't show up as NICs
<kirkland> cking: actually showed up as cdrom/optical devices
<kirkland> cking: when running windows, you get a popup, that a cdrom exists with some drivers you need to install
<cking> kirkland, there is some special magic that makes them switch mode, I can't recall what it is
<kirkland> cking: you do that, and then it clears some flag
<kirkland> cking: after which it looks like a nic again
<kirkland> cking: we couldn't figure out how to clear that flag in Linux (though we didn't try too hard)
<kirkland> cking: cool, so you've encountered these before
<cking> kirkland, something like usb-modeswitch, I've seen this on a USB 3G modem dongle
<cking> isn't it something like "ZeroCD" mode?
<cking> http://en.wikipedia.org/wiki/Virtual_CD-ROM_switching_utility perchance?
<kirkland> cking: interesting, I'll definitely try it if I get access to another one of these dongles
<apw> kirkland, try ejecting the CD rom device, that is commonly what occurs on the 3G modems
<apw> kirkland, you ask it to eject and that makes it go awayand the modem or whatever appear
<cking> that's a nice trick
<kirkland> apw: heh, cool :-)
<apw> cking, it makes some sense for sure
#ubuntu-kernel 2014-01-24
<ppisati> yawn
<apw> ppisati, do we still test pandas with 3.13?  infinity was trying to switch the omap4 images to generic kernel and was having trouble with framebuffer and network?  
<apw> and ... morning
<smb> apw, mourning morning
<apw> i normally am mourning bed at this time of the morning
<ppisati> apw: i tried that last week, network was definitely, but didn't test the framebuffer
<smb> apw, lazy git
<apw> was definalty working or not working
<ppisati> apw: working
<ppisati> apw: http://paste.ubuntu.com/6807371/
<apw> ppisati, prolly need to get you and infinity together next week to figure out his pain in the installer
<ppisati> apw: let me see the framebuffer
<apw> ppisati, perhaps upgrade it to -5 as well, i am amazed it works so well for you -4 being a bit of a turkey
<ppisati> eh
<ppisati> apw: let's see -5
<apw> -4 had a hideous brown paper bag in a core allocation primative, it is very bad generally :)
<ppisati> apw: flag@panda:~$ uname -a
<ppisati> Linux panda 3.13.0-5-generic #20-Ubuntu SMP Mon Jan 20 19:57:47 UTC 2014 armv7l armv7l armv7l GNU/Linux
<ppisati> flag@panda:~$ sudo mii-tool 
<ppisati> eth0: negotiated 1000baseT-HD flow-control, link ok
<ppisati> fb seems to be broken though
<ppisati> my bet is that infinity has an old boot loader
<apw> ppisati, thanks at least we know it isn't systemic, is the boot loader upgradble ?
<ppisati> apw: manually repleaceable? yes
<ppisati> apw: do we do it automatically? AFAIK no
<ppisati> apw: but let's check when he appears
<ogra_> we dont do it automatically ... i would have loved to back then but always got pushback "uboot is like BIOS ... we dont replace the BIOS either on upgrades"
<ppisati> ogra_: oh, there you are, hello Olli :)
<ogra_> :)
<apw> ppisati, sounds like a plan to me, thanks
<apw> henrix, this set of fixes for CVE-2013-0160, as it does not do the INOTIFY bit due to the lack of that feature in that release, how does it avoid the issue
<henrix> apw: since this fsnotify isn't in lucid, the user can't actually monitor a ptmx without reading atime/mtime
<henrix> hmm....
<henrix> but now that i think about it, i may be wrong
 * henrix goes back into old code to check if this is actually true
<apw> fsnotify is there, the nonotify flag isn't, right ?
<henrix> yes, it is
<apw> henrix, worse it seems to have inotify and fsnotify "unmerged" in there, gah
<henrix> so... ok, let me take a closer look at this.  i guess i assumed something that is not true :/
<apw> henrix, though you also tested it, so perhaps the test is bogus, not sure
<apw> henrix, in better news the bit which introduces the very basic support looks pretty easy to backport (commit ecf081d1a73b077916f514f2ec744ded32b88ca1)
<henrix> apw: yes, i've used the PoCs and they don't work with these backports. *however* the PoCs don't use fsnotify, they read the atime
<apw> henrix, thoguh it has a fix applied on top to change the constant (12ed2e36c98aec6c41559222e311f4aa15d254b6)
<apw> henrix, ahh that would explain it then, so i think those two are trivial to backport, if we ignore the rest of the functionality that is for, ie all the other bugs FANONOTIFY is meant to fix :)
<apw> though in the backport the inotify bits need to be in the "if"
<henrix> apw: yep, makes sense.  sooooo.... let me send myself a NACK and go take another look at this
<henrix> apw: and thanks for keeping your eyes open!
<apw> i've replied with the bits of info here summarised, and ... that is why we do peer review of these things, as it is unrealistic to expect people to never make an error, never happen
<henrix> cool!  so, i'll work on these 2 additional backports and re-tests.
<henrix> thanks ;)
<apw> henrix, wonderful indeed
<apw> there is an inotify_watch oro somethign which ought to allow you to confirm it doesn't work
<apw> inotifywait -m /dev/ptmx
<apw> i think that is the baby which should show it
<apw> henrix, ^^
<henrix> apw: ah, nice. i'll use that for additional testing.
 * apw tries to confirm that works
<apw> as alll my kernels are fixed :/
<apw> seems that someone has been toooo efficient
<brendand> does anyone here know much about hdd parking? we're trying to test it and it seems atm as if there's a lot of different implementations, only some of which are supported
<brendand> hdaps being one that works
<apw> brendand, do you mean parking as in "oh shit i am falling and likely there will be some hitting real soon, park NOW"
<apw> brendand, and if so, then not much is know but yes, it is a fragmented secret sauce part of the h/w eco system
<brendand> apw - what other kind of parking is there :/ ?
<apw> well parking is just then "putting the heads away", you do this on poweroff of the drive, sometimes on idle
<apw> and in some cases on "oh shit i am falling"
<apw> i would call it "emergency HDD parking" or something to be clear you mean that 
<brendand> apw - do you know any other implementations (that are supported in ubuntu)?
<apw> but cirtainly it has never been something we have investigated, so no i don't think we do know
<apw> i doubt any are configured automatically correctly
<apw> as from even the hdaps for IBM stuff is randomly model specific, gah what a mess
<brendand> apw, yes - somebody needs to take the initiative to make a standard interface for it
<apw> henrix, ok ... confirmed that without your patches at all lucid shows the inotify issue using the test above
<henrix> apw: ack, thanks. i haven't reached that point yet -- still building test kernel, and will re-test in a few minutes
<apw> henrix, figured i would test an unfixed kernel first :)
<henrix> yep, makes sense :)
<apw> henrix, as the lucid installs i have are server only, i ran that on the console and then ssh'd in
<henrix> apw: i've just tested in a vanilla lucid VM as well and confirmed your test result ;)
<apw> henrix, yay
<henrix> apw: hey...?
<henrix> what's up?
<apw> henrix, nothing: yay == poisitive sounds for your confirmation of my test result
<henrix> apw: ahh! :)
<henrix> apw: and i've just finished my testing with v2 of the patchset.  just finishing the cover letter and will send it in a bit
<apw> henrix, sweet
 * henrix curses AUFS
 * Kaloz is wondering why anyone would use aufs
<henrix> beats me :)
 * Kaloz handles henrix the note about the current year ;)
<Kaloz> we never adopted unionfs/aufs, went straight to overlayfs from mini_fo
<rsalveti> apw: updated tree for flo (new nexus 7): http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/flo
<rsalveti> apw: tested and working fine with my 4.4 based image, so can already be pushed to the archive
<rsalveti> apw: just need a new release + meta
<rsalveti> apw: grouper rebase for kitkat: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/grouper-rebase-kitkat (also tested with 4.4)
<rsalveti> apw: but that would need to go into a PPA for now
<apw> rsalveti, ack
<apw> rsalveti, do i need to interact with someone to upload the flo one or can i dump it in -proposed
<rsalveti> apw: just dump it in proposed
<rsalveti> argh, wrong monitor (contro + w) :-)
<apw> heh focus fail, a common problem with unity in my experience
<ogra_> we just need to add eyetracking via webcam ... and use focus follows eyes
<ogra_> trivial stuff :P
 * henrix sends v2 of CVE fix and runs
<apw> rsalveti, ok flo in the queue
<apw> rsalveti, do this grouper rebase is just to 3.1.10 its not a 3.4 rebase
<apw> rsalveti, so ... is still a 3.1 kernel then ... just checking
<rsalveti> apw: yeah, still 3.1, just rebase on top of the 4.4.2
<rsalveti> changes
<apw> ok
<apw> rsalveti, ok uploaded grouper to ckt PPA
<rsalveti> apw: great, thanks
#ubuntu-kernel 2014-01-25
<slangasek> is anybody else seeing a problem with latest kernels in trusty where filesystems are filling up with invisible usage, that clears up on reboot?
<slangasek> (problem seen with 3.13.0-4-generic; have just rebooted to 3.13.0-5-generic, waiting to see if the problem manifests again)
<jarkko> i would like to ask why ubuntu maintains the kernel themselfs
<Faux> jarkko: Relative to what?
<jarkko> i just want to know why ubuntu maintains the kernel themself
<jarkko> or is it just backportig drivers?
<ogra_> jarkko, every distro does that ... you need to do packaging and testing to make sure it works in context of the rest of the distro 
<jarkko> really?
<antarus> The kernel configuration process is pretty complicated, and there are lots of decisions ot be made
<ogra_> (and you will also find that every distro maintains its own kernel config)
<antarus> what features work, what features don't work, what features make sense for Ubuntu, what features do not
<ogra_> right
<jarkko> so basically the same kernel can be very different on other distro?
<ogra_> yes
<ogra_> well, differently configured
<antarus> and differently patched
<ogra_> right
<jarkko> never thought that
<antarus> although sharing (or poaching) patchsets is pretty common ;p
<jarkko> well i have compiled kernel few times and noticed lots of things i have no idea
<miseria> "dicen, que el ser humano es un programa del universo; Â¿sera que la muerte es solo un cambio de actividades?" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<jarkko> i mean the config
<ogra_> jarkko, fedora builds all its security in userspace around selinux ... ubuntu does the same with apparmor ... you cant have bot that the same time enabled in the kernel ... 
<ogra_> just as an example 
<ogra_> s/that the/at the/
<jarkko> do you have any opinion replacing iptables?
<ogra_> not really ... 
<ogra_> i dont use it 
<ogra_> (not really necessary on ubuntu ... ports only get opened if a userspace process listens on them, in ubuntu there is a "no open ports by default" policy so the risk is pretty low)
<jarkko> really?
<ogra_> (unless you explicitly install something that is supposed to listen indeed ... like a webserver ... but then you should know that port 80 is open for it)
<jarkko> how can i confirm that?
<ogra_> use another machine ... get familiar with nmap and scan your ubuntu install from there 
<ogra_> a default desktop install will only have DHCP and MDNS open ... 
<jarkko> does every kernel release need hard patching?
<ogra_> thats something you should ask the kernel team during the workweek ... they are rarely around on weekends ;)
#ubuntu-kernel 2014-01-26
<xnox> slangasek: 3.13.0-4-generic is known to be buggy in a few ways. -1 or -5 are all fixed.
<pvl1> if im going to compile a custom kernel, should i use the ubuntu kernel's instead of kernel.orgs?
<apw> jarkko_, "hard patching" assuming you mean "is every ubuntu kernel patched relative to its mainline equivalent" then that is a yes
<jarkko_> what those patches usually are? fixes or drivers?
<apw> jarkko_, and we use ufw by default (for network security) which uses a simple "DENY everything EXCEPT" framework using iptables at the kernel level
<apw> jarkko_, fixes which arn't yet upstream yet, extra drivers not yet upstream, that is about it, plus our own configs
<slangasek> xnox: yah, that's what rtg tells me
#ubuntu-kernel 2015-01-19
<zequence> infinity: lowlatency building
<yossarianuk> hi - can I ask questions regarding recompiling the ubuntu kernel here? (i.e kernel + ubuntu patches)?
<apw> yes you can
<yossarianuk> cool  - well I have posted a thread here - http://ubuntuforums.org/showthread.php?t=2261375  explaining the issue . basically the linux-source package doesn't compile when using  'debian/rules binary-headers binary-generic' - but make-kpkg does work.
<apw> yossarianuk, which package are you calling the linux source package ?
<apw> as in actually "linux-source-<something>"
<yossarianuk> sorry -  i.e  'apt-get source linux-image-$(uname -r)'
<yossarianuk> I remove some modules (and add the oss snd ones)   ''debian/rules binary-headers binary-generic'  - compiles the headers .deb fine - it goes through the entire process then errors at the end
<apw> yossarianuk, it is failing there because you have turned off some modules, and they are therefore not built, and the "modules going missing" detector is telling you off
<apw> that is there to stop us from losing modules without noticing the fact
<yossarianuk> ok the same config works with make-kpkg - do I have to manually edit a modules file then ?
<yossarianuk> i.e if I am changing the config where do I alter what modules are going to be built so I can use the 'debian/rules binary-headers binary-[flavour]' method
<apw> if your goal is to deliberatly turn off modules, you need to inform the checker of the fact by modifying the debian.master/abi/*/*modules file for the falvour; or by turning off the module checks with skip_modules=1 (something like that)
<apw> make-kpkg doesn't care at all what you do, it doesn't perform those checks
<yossarianuk> apw: thanks - I think I tried with 'skip_modules=1' => same
<yossarianuk> when I do updateconfigs doesn't that re-write the modules file.
<yossarianuk> I have put the error - http://pastebin.com/C3UVxN7H
<apw> yossarianuk, it is skipmodule=1, hense my ish the first time
<apw> yossarianuk, i had assumed you would look at debian/rules and find the correct option
<apw> yossarianuk, and ... no when you updateconfigs it does not update the abi/modules list because that is for the previous build, and is there for comparison with what you have now
<yossarianuk> thanks apw: i'll check exactly what options I tried (i did do various attempts) - I am sure I did use skipmodules/skip_modules... i'm @ work at the min (and did this @ home)
<yossarianuk> (nothing preventing me trying to compile from here - booth same CPU type..)
<yossarianuk> i'll give it another go....
<yossarianuk> (i wish the oss modules were in the ubuntu kernel.....) - some old games I play need OSS - aoss/pdoss do not work.
<apw> they interfere with the oss emulation that pulse does
<yossarianuk> in my experience oss emulation never works (maybe its my h/w - intel HDA)
<yossarianuk> with some games anyway
<yossarianuk>  namly paintball2 - works on all distros that don't remove the oss modules (i.e arch/debian stable/opensuse/fedora)
<yossarianuk> (on most I have to manually load the OSS modules though)
<apw> yossarianuk, and do we know why pulse oss emulation does not work for htem 
<apw> ?
<apw> diwic, we do still support oss emulation via pulseaudio right ?
<diwic> apw, uhm...PA certainly still has OSS emulation, but I wouldn't go as far as saying we actively support it - OSS is very old and unusual these dates
<diwic> apw, also I'm not sure that userspace emulation via pulseaudio can ever be as good as the kernel emulation, but take that with a grain of salt as I haven't investigated the issue in depth
<diwic> apw, now that I think of it, I think there was some mixer related stuff that was only in the kernelspace emulation and not in PA emulation. But if that was just Lennart being too lazy to implement it, or if it actually was impossible, I'm not sure
<apw> "you don't want to use that anyway" i am sure
<yossarianuk> all I know is every form of oss emulation I have ever tried (on multiple desktops/laptops) has never worked (hence be building a kernel with the modules in) - in the past the only way i've got paintball2 to work is build the kernel...
<yossarianuk> would be best to include the oss modules in the kernel but not activate/load them by default.
<yossarianuk> (imo)
<apw> diwic, i assume if we built them as modules and blacklisted them, that pulse would be ok
<yossarianuk> would save the odd random person like me having to compile kernels....
<yossarianuk> all other distro have them in the kernel btw
<yossarianuk> (all others that I have checked - even arch)
<apw> yossarianuk, could you file a bug against the package linux and write this reasoning down in it please, use ubuntu-bug linux, then we can consider it properly and note down the whys when we have
<apw> (and let me know the number here)
<yossarianuk> okie - i'll have to do it when @ home  - shall i include the issues I get with pulse emulation ?
<apw> yeah, and mention where they are available etc
<yossarianuk> ok - btw this is similar (old post - not mine..)
<yossarianuk> https://answers.launchpad.net/ubuntu/+question/238040
<yossarianuk> this too - http://askubuntu.com/questions/318396/oss-compat-package-does-not-create-dev-dsp
<yossarianuk> no /dev/dsp...
<yossarianuk> apw: I assume doing the report from kubuntu will be fine also ? (I can setup ubuntu if need be.)
<apw> that will work just fine
<yossarianuk> cool - cheers
<diwic> IIRC, the reason for removing OSS was that if somebody played back through kernel OSS emulation, that would block PA from outputting during that time (OSS got exclusive sound card access)
<apw> diwic, it was something like that, and i think there was something about if the modules were loaded something used it first too
<apw> diwic, so if they came back it would be blacklisted i think, so you'd have to force them in
<diwic> there have been talks over the years about a better kernelspace OSS emulation (that would route itself back into PA?!) but I don't think that has made it into mainline
<apw> heh ... trying to make my head hurt me thinks
<aeoril> What are good resources to learn OS theory, architecture, etc. to help with my long term goal of becoming a kernel/driver/module/vm programmer?  I bought "Modern Operating Systems" by Tannenbaum and it seems very promising, but it has typos and possible errors so I am not sure how good it is.  I want to long term slowly get into this type of development and work on Ubuntu doing it as 
<aeoril> part of the Ubuntu development community.  I am already reading various Ubuntu wikis and documentation, but am interested in starting out with stuff more like what I would learn at University to prepare myself as best I can.  Thanks.
<aeoril> kernel.org has a very nice set of articles for kernel newbies, but nowhere did I see mention of a bibliography of (text)books for theory and academic understanding of os and kernel development
<infinity> zequence: Thanks.  In -proposed now and ready for smoketesting.
<chris112> i'm running utopic and like to start using btrfs. would it be advisable to install kernel 3.17.1 from here http://kernel.ubuntu.com/~kernel-ppa/mainline/ ? any reason there is no 3.18.3 for utopic?
<apw> chris112, i assume you are rejecting the 3.18.3 because of the -vivid suffix?  this suffix indicates the release from which the config comes, whichever is nearest to the version
<apw> chris112, that said, if you are on utopic, the testing i have seen against btrfs has been pretty good on v3.16, much more so than v3.13
<umoukun> Hey all, is a list of all issues for a particular revision available somewhere?
#ubuntu-kernel 2015-01-20
<rsalveti> apw: mind taking care of https://bugs.launchpad.net/ubuntu/+source/linux-manta/+bug/1412543 ?
<ubot5> Launchpad bug 1412543 in Canonical System Image "udev bridge fails to get events from kernel (missing FHANDLE)" [High,Confirmed]
<apw> rsalveti, see it
<yossarianuk> chris112: you can use the 3.18.x kernels from mainline in 14.10 
<yossarianuk> the kernels in mainline ppa use the version they are targeted for - however just because 3.18 doesn't have 'utopic' in the version names does't mean they don't work in utopic ...
<chris112> yossarianuk, thx for the info. is it save to use the btrfs tools of utopic?
<yossarianuk> chris112: that I am not 100% sure of.
<yossarianuk> (not used btrfs in ubuntu yet at all - only opensuse / neptuneos)
<rsalveti> apw: thanks
<apw> rsalveti, i am assuming the normal plan and uploading them to the CKT PPA
<rsalveti> apw: yeah, just ping me once you get the packages in there
<rsalveti> I'll validate and copy them around
<apw> rsalveti, will do, mako is building, working on the otehrs now
<rsalveti> great, thanks a lot
<apw> rsalveti, ok it is all uploaded and building ... should be done in about an hour
<Odd_Bloke> I'm running the kernel tests in an Azure instance and have got to: https://pastebin.canonical.com/123777/
<Odd_Bloke> Nothing has happened in almost 20 minutes.
<Odd_Bloke> Is this a slow test, or has something broken?
<apw> Odd_Bloke, is that the ASLR test, i think it has to try several thousand times to check the distribution is random
<apw> Odd_Bloke, i cannot however say that i have run those recently to have a feel for how long
<smb> Yeah that test runs ages
<smb> ages being something of 40min+ depending on hw 
<rsalveti> apw: thanks
<thell> Hello. After a year of having hardware that seemed to enjoy crashing (almost daily) I now have a stable (for a week) non crashing core i7 4700MQ with i915 video driver while running Utopic with 3.19rc4! Woohoo!
<thell> My question is: What should I be monitoring for backporting of changes (I presume it was something in the drm-intel-next in Dec) to get back inline with Utopic kernels?
<Odd_Bloke> apw: smb: Thanks for the info.
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<trippeh> thell: there was just a bunch of intel gfx fixes that went into the upstream stable trees (not released yet)
 * thell cheers!
<thell> trippeh: I assume I should watch the changes file in the utopic kernel releases. Do you have a link of where you saw this so I can have an idea of what to watch for?
<dsmythies> I'll ask my questions after a few lines, they are related to (are exactly):
<bjf> cmagina, can you verify LP: #1404335 ?
<ubot5> Launchpad bug 1404335 in linux (Ubuntu) "xgene: BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059] on poweroff" [Medium,Confirmed] https://launchpad.net/bugs/1404335
<dsmythies> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765717
<ubot5> Debian bug 765717 in src:linux "linux-image-3.16-2-amd64: High CPU load with linux-image-3.16-2-amd64" [Normal,Fixed]
<dsmythies> https://lkml.org/lkml/2014/11/5/905
<dsmythies> The patch was submitted on Nov 6th, which I assume was in time for the 3.19 merge window, but it still doesn't appear in 3.19RC5.
<dsmythies> I cannot find any other references for it, nor any "ACK".
<dsmythies> Is there any to determine the status of the patch? Or might it be in limbo?
<dsmythies> Should I enter a launchpad bug report to track the issue within the Ubuntu context?
<apw> dsmythies, that sounds familiar
<dsmythies> apw, I was helping someone on Ubuntu forums with this issue. I saw you made a post on another thread there yesterday. I am now wondering how to follow up to ensure this get resolved.
<apw> dsmythies, ok the one i thought it was, it wasn't :) ... so ... yes please lets file a bug against "linux", using "ubuntu-bug linux"
<dsmythies> O.K. thanks.
<jsalisbury> ##
<jsalisbury> ## Ubuntu Kernel Team Meeting - in 10 minutes - #ubuntu-meeting
<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 January 27th, 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.
<Odd_Bloke> I'm beginning to think we may need to skip that stack collision test on (at least) Azure; about to hit the three hour mark. >.<
<apw> Odd_Bloke, you may be able to change the iteration count on that one, though it is likely hard coded
<Odd_Bloke> apw: It is hard-coded, regrettably.
<apw> Odd_Bloke, well "patch" can fix it then
<apw> if [ on hypervisor ]; then patch -p1 hyperv.patch
<Odd_Bloke> Ah, good point.
<apw> Odd_Bloke, it would be good to let one finish to find out how how long a "bazillion" iterations take, so you have a framework to work out a good "finish in 10m" number :)
<Odd_Bloke> Will see how it does on GCE (currently running the full qa suite there) to decide how to go about it.
<Odd_Bloke> Yeah, will definitely leave it going in to the evening.
<apw> Odd_Bloke, though ... it would be a lot more sensible if the iterations stuff did somethign saner, liek "run for 5m" 
<apw> Odd_Bloke, and it would maek a lot of sense to tell #security that this is out of control slow, and get a recommendation
<apw> Odd_Bloke, they may say ... if it isn't at least 10k iters its not worth doing sort of thing
<Odd_Bloke> Yeah, good idea.
<Odd_Bloke> I'll probably also look at splitting it out of the main run (in a downstream semi-hacky sort of a way) so it can get its own instance to run on.
<Odd_Bloke> That'll let us run it in parallel with the other tests, so it taking X minutes will be slightly less painful.
<apw> Odd_Bloke, a good plan, if you come up with a way to run the tests as groups or whatever "--not-aslr" "--not-all --aslr" or whatever, we should feed that back to the master
<Odd_Bloke> Sounds like a problem for Tomorrodd_Bloke.
<apw> Odd_Bloke, :) i know that man
<soee> hi, gusy when 3.18.3 will make its way into Vivid ?
<apw> soee, after the freeze for A2
<soee> apw: thank you
 * RAOF looks for a target to poor bees into.
#ubuntu-kernel 2015-01-21
<apw> RAOF (N,BFTL), I _always_ need a dose of bees
<yossarianuk> apw: sorry not sent a bug report yet about lack of oss modules yet - however I found an old post regarding it  - http://ubuntuforums.org/showthread.php?t=1656193
<yossarianuk>  SNDDMA_Init: Could not mmap /dev/dsp. 
<yossarianuk> - similar error for padsp
<yossarianuk> anyway - regarding rebuilding the ubuntu kernel source - I have found out what is causing the fail....
<apw> yes?
<apw> yossarianuk, ^
<yossarianuk> (sorry @ work..)
<yossarianuk> ill be a few secs..
<yossarianuk> ok - it builds fine as long as I don't add CONFIG_LOCALVERSION:
<yossarianuk> i.e - append to kernel release
<yossarianuk> if I add anything in that - i.e 'test1' the kernel goes through the entire build process then fails 
<yossarianuk> if I leave that blank it builds the linux-image package fine
<apw> yossarianuk, sounds about right indeed.  you should add something to debian.master/changelog, to the top entry'
<apw> +test1 to the end of the version number on that line
<yossarianuk> apw: ah - i.e the dch command ?
<yossarianuk> or just manual edit ?
<yossarianuk> i'll give it a go
<yossarianuk> thanks
<yossarianuk> This documentation should be updated.....
<yossarianuk> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<apw> manual edit i would recommend
<yossarianuk> thanks - i'll try that !
<yossarianuk> regarding the OSS snd issue - the apps are 32bit (on a 64bit system)
<yossarianuk> I should have the right deps though
<yossarianuk> and also it works 100% with a compiled kernel with oss mods...
<yossarianuk> I will make a bug report ...
<apw> yossarianuk, yep, community member edited that document to add that section which is, wrong ... sigh
<yossarianuk> well not wrong - just not complete.
<yossarianuk> You just can't get the staff.........
<apw> yossarianuk, no blatently wrong, using CONFIG_LOCALVERSION (as you found out) breaks the build
<apw> yossarianuk, though i am slightly supprised that the config-check didn't implode for that and stop you
<yossarianuk> apw: ah - so when I re-test should I just add to debian.master/changelog or do I add to debian.master/changelog as well as CONFIG_LOCALVERSION  ?
<apw> just add it to debian.master/changelog, nothing else
<yossarianuk> apw: thanks
<apw> the rest should come out in the wash as the build system runs
<yossarianuk> I can see if I have edit rights and change this ?
<apw> yossarianuk, i have already updated it
<yossarianuk> (want to test first anyway..)
<yossarianuk> nice one!
<apw> it is a wiki, it is easy to edit, which is both good and bad
<apw> depending on how knowledgable the editor
<yossarianuk> yeah - you sometimes get people (trolls) on purposely adding 'bad data'
<yossarianuk> apw:  just to confirm I should change the first line in debian.master/changelog
<apw> yes
<apw> linux (3.19.0-3.3) UNRELEASED; urgency=low
<apw> linux (3.19.0-3.3+test1) UNRELEASED; urgency=low
<apw> like that sort of thing
<yossarianuk> great cheers
<yossarianuk> i'll let you know if that works ....
<yossarianuk> apw: cheers - worked fine!
<Odd_Bloke> I'm hitting this error when running the kernel tests: http://paste.ubuntu.com/9806187/
<Odd_Bloke> I tried running them with sudo (i.e. sudo ./runner qa) which did address this, but other tests fail if they're run as root.
<Odd_Bloke> I can poke at fixing it myself, but didn't want to do so if someone could point me in the right direction. :)
<apw> Odd_Bloke, doesn't that show it running that failing sub comamnd as root ?
<apw> Odd_Bloke, ie with a sudo ?
<Odd_Bloke> apw: No, ./runner is being run as the ubuntu user.
<Odd_Bloke> I think it isn't logging what is failing.
<apw> Odd_Bloke, but the commands which are run have sudo on them in a lot of cases, perhaps the failing one needs it adding
<apw> Odd_Bloke, rather than running the whole of runner as root
<apw> Odd_Bloke, as clearly it expects to need to do that
<Odd_Bloke> apw: The failure happens in the call to shutil.copytree, which is within runner (i.e. the only way to get that particular line to be privileged is to run runner as root).
<apw> Odd_Bloke, do we know where it is trying to copy too ?
<Odd_Bloke> apw: I believe the three elements of the tuple in the shutil.Error line are from, to and error text.
<Odd_Bloke> Let me pull down that directory and see what does end up in there.
<Odd_Bloke> Oh, of COURSE it worked this time.
<apw> Odd_Bloke, oh good :<
<Odd_Bloke> I'm trying another full run, in case that's what triggered it.
<apw> yeha its going to be like first date nurves or something
<hallyn> apw: do you know of any firmware bug in recent sru which sould have prevented a desktop system from mounting some drives/filesystems?  
<sforshee> hallyn: which release? I think the only recent firmware SRU was some intel wireless updates.
<hallyn> sforshee: 2015-01-19 20:33:12 upgrade linux-firmware:all 1.127.10 1.127.11
<sforshee> hallyn: yeah, that one was only updates for iwlwifi
<hallyn> there was also a libc6 and multiarch update, maybe those are more likely
<sforshee> I suspect so. That would be some bad wireless firmware if it caused mount issues.
<hallyn> well, or a bad grub-update or something?
<infinity> hallyn: Blaming glibc for being unable to mount some filesystems seems far-fetched too.  What's the exact symptom?
<hallyn> infinity: i didn't say i blamed it for not mounting the fs.  all we know is it didn't get to mounting filesystems
<hallyn> the bug was reported third-hand, and machine owner does not speak english
<hallyn> bug reporter and victim machine (and its owner) are on differnet sides of whatever country they are in
<infinity> hallyn: Brilliant.
<hallyn> hm, what's your lp id actually?
<infinity> hallyn: So, it's hard to say without seeing the exact symptoms, but the bug/misfeature I run into all the time (just had to fix it on the ppc porter a few days ago) is that if fstab references a mountpoint that doesn't exist, mountall can hang.  Which is something you never notice until a reboot.
<infinity> hallyn: adconrad
<infinity> hallyn: A boot with init=/bin/sh and grubbing around in fstab can often be enlightening.
<hallyn> infinity: yeah that appears to be impossible, though iiuc maybe after feb 7 he can d oit.  sigh
<hallyn> (subscribed you to the bug :)
<infinity> hallyn: #?
<hallyn> the reason it interested me is bc it seemed similar to a container bug stgraber was seeing, where he is guessing that upstart's reexec failed
<hallyn> 1412671
<infinity> hallyn: Oh.  Weird.  Kay, if downgrading fixed it, it's not the mountall thing.
<hallyn> yeah, i really think if they'd powered it down and back up it would have been fine, just reexec failed.  
<infinity> hallyn: Err, but the bug is that it fails *on boot*.
<infinity> hallyn: Not on upgrade.
<infinity> hallyn: Really tempted to blame cgmanager. :P
<hallyn> yeah, well, i'll try to reproduce in a kubuntu vm i guess
<hallyn> who knows, maybe it *is* cgmanager
<infinity> Then again, I don't speak fluent nih_, but I don't see how the 7.1->7.2 delta could make things more broken.
<hallyn> or more importantly how cgmanager could block the system booting.  
<infinity> Yeah, that.
<infinity> hallyn: The upgrades/downgrades may well be a red herring, and he may just have a racy boot that's showing an intermittent mountall or upstart bug.
<hallyn> chuckle.  good point
<infinity> hallyn: But yeah, without the ability to do some good back-and-forth, it's kinda dead in the water until Feb7 anyway.
<hallyn> asked fo ra few more reboots :)
<hallyn> one would expect more such reports if this was a real sru regression
#ubuntu-kernel 2015-01-22
<RAOF> Gah! Stupid bloody kernel that loses my USB hub.
<backjlack> Hello!
<backjlack> Has anyone seen problems like netfilter not NAT-ing some ports?
<backjlack> (or stop nat-ing some ports after a while)
<plasmasnake> hi all, i'm just curious, any chance that linux 3.20 will make it into Ubuntu 15.04 if the RC comes around before april?
<apw> plasmasnake, it more depends how likely full release is to be out before release
<plasmasnake> apw: i see, yeah i guess based in historical data it's probably gonna be neck-and-neck
<plasmasnake> the open-source radeon driver is finally going to be getting fan control, so that's my main reason for asking
<apw> we need v3.20 to be a few week before to be viable
<plasmasnake> ah, probably extremely unlikely then
<jdstrand> jsalisbury: I responded to your question in bug #1413238. I put the bug back to New-- I'm not sure if that was correct to get it on your radar
<ubot5> bug 1413238 in linux (Ubuntu) " Intel i915 driver pauses and tracebacks" [High,New] https://launchpad.net/bugs/1413238
<jsalisbury> jdstrand, that will work.  Thanks, I'll take a look.
#ubuntu-kernel 2015-01-23
<Odd_Bloke> I fixed the permissions error I was seeing running the tests with: http://paste.ubuntu.com/9832685/
<Odd_Bloke> That copies the files to a temporary location before doing the permission munging.
<apw> Odd_Bloke, i don't htink i get why that helps any
<apw> Odd_Bloke, unless ... you arn't running as "USER"
<apw> $USER
<Odd_Bloke> apw: My best guess is that something is modifying the contents/permissions of self.autotest_results_root after the chown call happens; my code effectively takes a snapshot which avoids that happening.
<Odd_Bloke> But I'm not sure I would recommend it for inclusion upstream.
<apw> Odd_Bloke, the window between the chown and the cp is like near immediate, i just don't buy that
<apw> Odd_Bloke, can we check we are running as $USER there, as if $USER was something other than the name of the user we are, then we'd not be able to read them, the extra copy may be adding permissing to them or something
<Odd_Bloke> apw: Sure, will do.
<Odd_Bloke> user there ends up as 'ubuntu', as expected. :(
<apw> Odd_Bloke, so what was the actual errror from the copy as "ubuntu"
<Odd_Bloke> apw: "[Errno 13] Permission denied: 'autotest/client/results/default/ubuntu_qrt_kernel_panic.test-kernel-panic.py/debug/crash.amd64_killer.24949/report'"
<apw>         result, output = sh(r'sudo find %s -print | xargs chmod u+r' % (self.autotest_results_root))
<apw> what about adding that after the chmod +x line
<apw> as these files belong to you, and yet you cannot read them, wheresa root would be able to, on copy may well add u+r to them
<Odd_Bloke> That file was still owned by root:root when I examined it.
<Odd_Bloke> k
<Odd_Bloke> I really wish I could get this reproducible with less than a 2 hour test run. :p
<apw> Odd_Bloke, it was still root?  that seems, unexpectede
<Odd_Bloke> Yes, indeed.
<Odd_Bloke> I'm re-running the full suite (in lieu of a more concise reproduction) unchanged; will have another look at it then.
<Odd_Bloke> apw: http://paste.ubuntu.com/9835165/ is ls -lah output of the appropriate directory.
<Odd_Bloke> apw: http://paste.ubuntu.com/9835173/ is the stat output.
<Odd_Bloke> So it looks like report is created after core is modified (and copied?; guessing that's what the 'access' is).
#ubuntu-kernel 2015-01-24
<Dresk> https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1346828 - So what's going on with this bug?  This Intel chipset is possibly the most popular desktop / light server hardware being used, both on motherboards themselves, in single and dual PCI(-E) chips, and the work around is to disable TCP and Generic Seg offloading, one of the reasons we use the card.  Any word on it?
<ubot5> Launchpad bug 1346828 in linux-lts-trusty (Ubuntu) "eth0 (e1000e): transmit queue 0 timed out" [Undecided,Confirmed]
<trippeh> the *LM intel gige (eg built into chipset variant) has always been a pain for me.
<trippeh> tso/gso disabling always "fixes" them
<trippeh> they are especially wonky when forwarding (eg routing)
<makaveli0129> getting DMA: Out of SW-IOMMU space for 2048 bytes at device 0000:06:00.0 for my wireless card i've tried iommu=soft in the kernel params but still no dice
<makaveli0129> any idea's on how to fix it?
<makaveli0129> this is on kernel 3.13 and all relevant forums reference a bug in kernel 3.8 that was fixed in 3.9 but nothing in this version
<apw> makaveli0129, nothing specific springs to mind, bit if it works on other versions we should be able ti make progress
<apw> makaveli0129, if you file a bug against linux one of us can work through it
<apw> with you
<makaveli0129> apw: any idea on where to start troubleshooting? I had the same error for my sata drives yesterday but changing bios settings to ahci fixed those and now this one is coming up with the network card
<apw> well typically we would get you to try newer kernels in the hope it is fixed there
<apw> and then if so, use thst to try and find the fix
<makaveli0129> ok how do i create a bug never had to do it before the channels usually always fixed the problem
<apw> run "ubuntu-bug linux" in a terminal
<apw> that will suck up info on your hardware
<makaveli0129> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1414334
<ubot5> Launchpad bug 1414334 in linux (Ubuntu) "DMA Errors" [Undecided,New]
<apw> makaveli0129, ok i've put some info the bug, to get you started
<makaveli0129> how do i install the new kernel?
<apw> makaveli0129, that wiki page should have full instructions
<makaveli0129> yea i'm there now
<makaveli0129> thank you
<makaveli0129> quick question i have the below that i opened today it's the first time i submitted a bug but it shows as confirmed does that mean it really is a bug?
<makaveli0129> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1414334
<ubot5> Launchpad bug 1414334 in linux (Ubuntu) "DMA Errors "DMA: Out of SW-IOMMU space for 2048 bytes at device 0000:06:00.0"" [Undecided,Confirmed]
<saahil> hi there can i use linux-tools-3.16 for kernel 3.14.29 ?
<apw> ma
<DalekSec> apw: Heya, did you happen to see the question about 1346828?
#ubuntu-kernel 2015-01-25
<ricotz_> apw, hi, if vivid stays on 3.18 -- this would be something needed to fix intel accel -- http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d472fcc8379c062bd56a3876fc6ef22258f14a91 -- https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116
<ubot5> Freedesktop bug 76554 in DRM/Intel "[gm45] [drm:init_ring_common]: *ERROR* render ring initialization failed" [Normal,Needinfo]
<apw> ricotz_, we are not intending to be in on v3.18 indeed ...
<ricotz> apw, ok, i somehow got the impression since the 3.19 build was dropped from the kernel ppa
<ricotz> apw, 3.19 has the mentioned bug fix included
<apw> ricotz, yeah it was deleted because we were having a huge problem with that arm64 builds, so we needed to be able to upload a v3.18 to the PPA
<ricotz> apw, ok
<apw> ricotz, but ... it is safest to file a bug against linux with that info in, then i will remember to make sure
<ricotz> apw, i guess it is fine with 3.19 is the target, i am running the rc5 mainline build with works in this regard
<apw> ricotz, if you do file a bug for it, please shove the bug# in here
#ubuntu-kernel 2016-01-25
<xnox> apw, looking at the dumps of both our and rhel kernel images, it would appear that both are compressed, but somehow the offset where that begins is like miles further down the binary for ubuntu vs others.
<xnox> however not that dissimilar to debian with 10.3 MB
<caribou> Is there a way to trigger a rebuild of initrd.img for each installed kernel ?
<caribou> apw: arges has found an issue with kdump-tools when it is installed on system with more than one kernel package present
<caribou> apw: smaller initrd.img for kdump-tools will only be built for the current running kernel, not all the installed kernels
<apw> caribou, yeah you want to build but not rebuild them i guess
<apw> caribou, against all kernels
<caribou> yeah, build them
<caribou> apw: right now, the trigger will execute only for the current kernel
<apw> yeah that does (in hindsight) seem flawed, bah
<caribou> apw: maybe kdump-config should be responsible for building it if it doesn't find the proper file in /usr/lib/kdump
<apw> caribou, that isn't unreasonable, though would it delay boot ?  it should of course be rare and you definatly want the thing if you are asking to use it
<caribou> apw: yes it would. That's why I would rather have that done when we install the package
<apw> tricky
<caribou> apw: I had an enhancement for kdump-config to be able to correctly set symlinks for a kernel version given as an option
<caribou> something like kdump-config symlink {version}
<caribou> I could add a check that would build the file if it is missing. This would be a manual operation but would give the chance to fix the problem
<apw> yeah, that is also pretty good
<caribou> I'm not a fan of delaying the boot for that
<apw> right makes sense
<caribou> apw: ok, I'll look into that, thanks!
<apw> cool
<seanvk> The mainline-crack 4.4 and 4.5rcx kernels seem to be missing NVME support that exists in 4.3.  Anyway just FYI.  I've a Dell XPS 13 with NVME.  Noted that when installing 16.04 and attempting to use the newer kernels from mainline-crack
<apw> seanvk, hmmm, i'd expect 4.4. to work because that is now our -proposed kernel
<seanvk> Ah no, you are right apw 4.4 has it
<seanvk> Meant 4.5 only
<seanvk> maybe not - RC1 had it but the v4.4-wily 0003 patch does not
<seanvk> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-wily/0003-configs-based-on-Ubuntu-4.4.0-0.10.patch
<apw> 4.4-rc1 was built against a 4.3 config, 4.4 final was built against a 4.4 (and recent) config
<apw> so i am supprised it is not the other way round
<apw> seanvk, though there is a 4.4 kernel in -proposed which i am told does work with nvme
<seanvk> Ah, thanks, I will look there.
<seanvk> I'm in the process of building my own from the 4.3 config
<smoser> apw, what woudl produce /etc/kernel.conf ? and did you mean /etc/kernel-img.conf ?
<apw> smoser, i think that is part of an image iirc
<apw> smoser, as in it is in the live images and propogated onto your system
<apw> which is an oddity now i think about it
<smoser> apw, do you have other ideas ?
<smoser> the file is there.
<apw> smoser, whats in it ...
<apw> smoser, does it request the use of symlinks, and ... pastebin it
<smoser> diagnosis in that bug now.
<apw> the case is unimportant to the option valyue
<apw> smoser, also how are these chroots made, ie can i make one or get access to one you have made
<apw> smoser, as this is simply some perl that needs following through, its not rocket science
<xnox>  /etc/kernel-img.conf is carefully crafted, by kernel installers / re-initramfs-update-u code. And it's done for the debootstrap, and live-installer cases.
<xnox> on all arches.
<seanvk> apw: I tested Dell XPS 13 (Skylake flavor) with xenial-proposed 4.4 and it is not finding the NVME at all.  I will file a bug report tonight.  Current 4.3 does find the NVME.
<seanvk> apw: key difference is that 4.3 has CONFIG_NVMEM set, but 4.4 does not
<seanvk> It does
<seanvk> Not really clear.  Sorry for the back and forth.  Still not finding the NVME though the Dell.  I will file a bug report.
<user_8865> allah is doing
<user_8865> sun is not doing Allah is doing
<user_8865> moon is not doing Allah is doing
<user_8865> stars are not doing Allah is doing
<user_8865> planets are not doing Allah is doing
<user_8865> galaxies are not doing Allah is doing
<user_8865> oceans are not doing Allah is doing
<user_8865> mountains are not doing Allah is doing
<user_8865> trees are not doing Allah is doing
<user_8865> mom is not doing Allah is doing
<user_8865> dad is not doing Allah is doing
<user_8865> boss is not doing Allah is doing
<user_8865> job is not doing Allah is doing
<user_8865> dollar is not doing Allah is doing
<user_8865> degree is not doing Allah is doing
<user_8865> medicine is not doing Allah is doing
<stgraber> !ops
<ubot5> Help! lamont, zul, T-Bone, mdz, or jdub
<user_8865> customers are not doing allah is doing
<user_8865> you can not get a job without the permission of Allah
<user_8865> you can not get married without the permission of Allah
<user_8865> nobody can get angry at you without the permission of Allah
<user_8865> light is not doing Allah is doing
<user_8865> fan is not doing Allah is doing
<user_8865> businessess are not doing Allah is doing
<user_8865> america is not doing Allah is doing
<user_8865> fire can not burn without the permission of Allah
<user_8865> knife can not cut without the permission of Allah
<user_8865> rulers are not doing Allah is doing
<user_8865> governments are not doing Allah is doing
<user_8865> sleep is not doing Allah is doing
<user_8865> hunger is not doing Allah is doing
<user_8865> food does not take away the hunger Allah takes away the hunger
<user_8865> water does not take away the thirst Allah takes away the thirst
<user_8865> seeing is not doing Allah is doing
<user_8865> hearing is not doing Allah is doing
<user_8865> seasons are not doing Allah is doing
<user_8865> weather is not doing Allah is doing
<user_8865> humans are not doing Allah is doing
#ubuntu-kernel 2016-01-26
<seanvk_laptop> apw problem solved.  I needed to add nvme to /etc/initramfs-tools/modules
<seanvk_laptop> With that change proposed 4.4 kernel will find the nvme filesystem on boot on the Dell XPS 13 (Skylake + NVME)
<xnox> seanvk_laptop, bug #1532146
<ubot5> bug 1532146 in initramfs-tools (Ubuntu) "update-initramfs fails for MODULES=dep when root is on nvme device" [Medium,In progress] https://launchpad.net/bugs/1532146
<seanvk_laptop> Thanks xnox
<apw> seanvk, ahh that is about initramfs-tools not following the name, that i think is solved with the most recent upload too
<apw> manjo, there is a new merge of initramfs-tools in ppa:apw/ubuntu/initramfs-tools which with luck groks your specifier ... if you could test that one and let me know
<caribou> apw: what are you up to with the initramfs-tools upload that includes my nvme fix ?
<caribou> apw: & do you have a bug number for your upload ? I would like to tie my own bug to it
<apw> caribou, that should be in -proposed at least alreday
<apw> and yet ... it is not, wtf
<caribou> xnox: ^^^ This is the bug you asked me to upload earlier today
<apw> i even have the upload file for it
<apw> initramfs-tools_0.120ubuntu7_source.ubuntu.upload
<apw> and an accept email for it, so unless britney is promoting it right now, its mia
<apw> oh no that is for the PPA copy, hrm
<apw> caribou, anyhow using your bug #
<apw> caribou, and i will try that again
<caribou> apw: fine with me
<apw> caribou, ok removed the .upload file and uploaded it again, and there it is building ... so wtf is my only response
<caribou> apw: thanks!
<caribou> xnox was chasing me to upload it. I don't get it : now that I have core dev rights, people do expect to see me do actual real work :-)
<apw> caribou, it is a horror story :)
<apw> caribou, oh you have that machine with nvme, perhaps once you are happy 0.120ubuntu7 is working for you, you could test ppa:apw/ubuntu/initramfs-tools
<apw> caribou, that has the very latest 0.122 merge which i am working up to uploading
<caribou> apw: sure
<apw>  /b 3
 * smb tries 2b1 only
<xnox> apw, i can test too =) i've finally jumped the 17 hoops to get latest dell xps 15 installed
<apw> xnox, heh thanks, i've had pitti review two of them and they are uploaded, so just initramfs-tools now, anything you can test on that == yay
<cristian_c> jsalisbury: hi
<jsalisbury> cristian_c, hi.  I've been tied up on other bugs.  I hope to get back to yours sood.
<jsalisbury> s/sood/soon/
<cristian_c> jsalisbury: I've found a fix
<jsalisbury> cristian_c, oh, great!
<jsalisbury>  cristian_c If you post it to the bug, I can build a test kernel and then SRU it
<cristian_c> jsalisbury: I've rebuilt the driver with the fix, and polarity is fixed
<jsalisbury> cristian_c, thats great
<cristian_c> then, as usually, I can execute the workaround to set the triggers: none and phy0radio, in place of the default ones
<cristian_c> and it works
<cristian_c> jsalisbury: so, I'll post the details in the bug report page
<jsalisbury> cristian_c, nice.  Thanks so much for the good work!
<cristian_c> ok
<bjf> apw, who in this channel specifically should i be pestering for IBM bugs?
#ubuntu-kernel 2016-01-27
<leon_pegg> Good morning all, I would like to apply a patch to the kernel package and would like some guidance could someone please advise.
<leon_pegg> to provide a bit more information I am looking to patch the kernel with grsecurity
<apw> ok, ask ay specific questions you have and we'll try and answer
<apw> *any
<leon_pegg> How do i apply a patch to the kernel source package
<apw> leon_pegg, to be honest if applying a patch is a new thing you are going to find applying a monster like grsecurity a huge effort
<apw> leon_pegg, but ... i would start by checking out our git repository for the release to which you intend to apply it
<leon_pegg> apw: I have applied patches to raw source before but never to packages, and have built custom kernels before just not applied patches to deb packages
<leon_pegg> apw: whats the git repo address?
<apw> leon_pegg, was struggling to find it in our wiki *sigh* ... https://wiki.ubuntu.com/Kernel/SourceCode see the git bit there
<apw> leon_pegg, i would then apply the patch in git and build the source package from that
<leon_pegg> apw: thanks 
<leon_pegg> apw: fingers crossed it all goes well :D
<apw> leon_pegg, also, didn't grseurity stop producing patches in public anyhow ?
<leon_pegg> apw: they still provide the testing patches to keep supporting arch-hardened 
<apw> leon_pegg, against what kernel versions though
<leon_pegg> apw: kernel versions 3.1-4.3.4
<apw> so you might have some luck on 4.2 in wily then, but xenial is too new
<leon_pegg> apw: using wily on the desktops in the office so we should be good, we are still is discussions about applying grsec on the servers
<apw> leon_pegg, that is a big committment for sure, as you'll need to keep up to date with security release cadance
<leon_pegg> apw: exactly it is a huge commitment, and keeping up with security updates adds additional work. the plan at the moment it to trial on some of the desktops and progress from there after
<MaikZ> Hi, is there an escalation procedure we could follow to get some more attention on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398465 ?
<ubot5> Launchpad bug 1398465 in linux (Ubuntu) "Memory allocation failure, presumably in FUSE" [Medium,Invalid]
<MaikZ> Oops wrong bug sorry
<MaikZ> Well actually same bug, but https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1505948 is the version we reported :-)
<ubot5> Launchpad bug 1505948 in linux (Ubuntu Wily) "Memory allocation failure crashes kernel hard, presumably related to FUSE" [High,Confirmed]
<MaikZ> There is an out of bounds write somewhere in fuse_direct_io on 4.1 and higher that can panic the kernel (and reliably does, on our virtualization hosts)
<MaikZ> We're working around it by staying on 3.19, but that is coming uncomfortably close to being out of support we think
<apw> MaikZ, that doesn't look like a memory allocation failure, more like a memory arena corruption, a double free or something
<MaikZ> apw: Yes
<MaikZ> We booted a test machine with slub_debug
<MaikZ> And it confirms that something in fuse_direct_io wrote zero bytes into the "poison" areas
<MaikZ> Without slub_debug, that makes the kernel panic on some future allocation or deallocation.
<apw> is that info in the bug (save me reading it)
<apw> MaikZ, also are you able to test the 4.4 kernel in xenial-proposed easily for this ?
<MaikZ> If there's a .deb that installs on trusty, we should be able to do that fairly quickly yes
<MaikZ> Not yet, our storage vendor was supposed to add it but apparently didn't. I'll attach it.
<apw> MaikZ, well in principle those are nistallable there with lick
<apw> luck
<apw> MaikZ, and this won't affect "regular" consumers of ubuntu i assume, as you need to use fuse 3.0 to get async io right ?
<MaikZ> Not sure about the FUSE versioning, but I can confirm that the specific FUSE file system we use ships with its own, very recent libfuse.
<apw> and presumably you do not see this without
<MaikZ> We have been able to reproduce the kernel crash using ntfs-3g because fuse-devel was unhappy about a closed-source userspace part
<MaikZ> But that was also a fresh build
<MaikZ> So for testing 4.4, we could try grabbing .debs from this build: https://launchpad.net/ubuntu/+source/linux/4.4.0-1.15/+build/8880824
<MaikZ> And they should sort of work on trusty because kernel packaging hasn't fundamentally changed?
<apw> MaikZ, that would be my expectation, do get -extra if you need it
<MaikZ> Okay, one machine cleared of production workloads and 4.4 installed, let's see what happens.
<apw> MaikZ, i think it will break just the same, but that a good data point, i have found a suspicious  looking async path
<Madkiss> g'day
<apw> Madkiss, ?
<Madkiss> apw: MaikZ told me there's an interesting conversation going on here about a bug we reported several months ago, so I just thought i'd join and read :)
<apw> MaikZ, assuming that machine also goes pop, i might have a guess as to the cuase of this, if so then i might have a test kernel to try (soon)
<apw> MaikZ, if so, 1) would you be able to test it, and 2) i would need to confirm its not leaking instead of blowing up, so it'd need some monitoring
<MaikZ> We can install a custom build. What monitoring do you have in mind?
<MaikZ> There is sadly no metrics collection in that cluster.
<MaikZ> So I can't draw you pretty memory usage graphs.
<apw> MaikZ, well if it is the right fix then the machine will not blow up and things will be fine, if it is not then the machine may work fine and leak 96 byte memory blocks for every async IO and lose memeory over time
<apw> MaikZ, so I guess I am syaing we need to monitor the slabs are not growing out of control in this case
<apw> MaikZ, if your screenshot is accurate then like:  while :; do grep kmalloc-96 /proc/slabinfo; sleep 5; done
<apw> would be something to watch is similar to other machines
<apw> MaikZ, i assume if i am wrong then it will literally lose an entry for every single IO, so it should be obvious and spectacular
<MaikZ> Spectacular failure is our core business!
<MaikZ> I'm so far failing to reproduce the previous issue (slub_debug is silent, also no panic), but instead I/O has totally frozen on the test VM.
<MaikZ> With the 4.4 kernel.
<MaikZ> Or looks like it...some ops are getting through according to storage metrics.
<gQuigs> any thoughts on disabling mtrr for xenial?   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1163587
<ubot5> Launchpad bug 1163587 in linux (Ubuntu) "mtrr_cleanup: can not find optimal value, perhaps no longer needed?" [Medium,Triaged]
<apw> MaikZ, ok, after some further reading it doesn't look like that suspicious thing is suspicious
<MaikZ> I will let the 4.4 tests run overnight, the kernel might panic after a couple of hours. It usually happens within minutes but not always.
<apw> MaikZ, sounds good thanks
<apw> MaikZ, put any result info in the bug and let us know too here
<MaikZ> Sure.
#ubuntu-kernel 2016-01-28
<shanester> Hi Guys!  If my machine is locking up and the only thing printed in syslog is acii null (@^@^@^) and its not a kernel panic, is there anyway to have the system automatically reboot?
<MaikZ> You can check if the machine has a hardware watchdog.
<MaikZ> If so, http://packages.ubuntu.com/trusty/watchdog can use it to have the machine hardware reset if the OS locks up.
<apw> MaikZ, i put a test kernel in your bug, well they are uploading now
<MaikZ> Excellent
<MaikZ> The crash failed to reproduce overnight, but the storage vendor is testing independently, and I'll try a VM without IO quota tomorrow.
<apw> sounds good
<shanester> ty MaikZ
#ubuntu-kernel 2016-01-29
<hallyn> jjohansen: hey, on xenial master-next i'm getting a warning about sleeping from invalid context from kern_path in aa_move_mount+0x17c/0x320, happening on mount --move when apparmor-confined
<hallyn> jjohansen: do you know about it?
<jjohansen> hallyn: nope, can you open a bug, or just send me what you have
<hallyn> jjohansen: wlil do, thx
<hallyn> jjohansen: 1539349
<jjohansen> thanks
<apw> jjohansen, that isn't your new aa fix the one with Hack in its title is it ?
<jjohansen> apw: ugh that horrible hack, I guess you could call it a fix. But I have a large queue of outstanding patches that there just isn't time to finish up/push atm
<jjohansen> apw: tyhicks cherry picked that one patch because its required by something
<jjohansen> the real fix is typesplitting but, well that is still a ways out
<jjohansen> and we will never land that in wily and older kernels
<apw> no indeed, just wondered if ti was causing hallyn issue
<jjohansen> apw: which issue?
<apw> lp: #1539349
<ubot5> Launchpad bug 1539349 in linux (Ubuntu) "sleep from invalid context in aa_move_mount" [Undecided,Incomplete] https://launchpad.net/bugs/1539349
<jjohansen> no
<apw> as that i thought was the only aa change from -1 to -2
<jjohansen> I still need to poke at that tonight
<apw> as long as it isn't new in -2 that is fine with me
<apw> and i can't see how it could be now i apply brain as you don't mount those
<jjohansen> right, if they are there are other problems
<apw> Odd_Bloke, this link_in_boot bug, is there a build log for that somewhere ?
<caribou> beisner: just commented about LP: #1539546
<ubot5> Launchpad bug 1539546 in lvm2 (Ubuntu) "Service mountdevsubfs has to be enabled to start service lvm2" [Undecided,New] https://launchpad.net/bugs/1539546
<caribou> I had this problem in a few autopkgtests until pitti fixed the Xenial images late last night
<caribou> oups, sorry wrong room
#ubuntu-kernel 2016-01-30
<mogost> Guru, please help. I am desperate to seek at least a temporary solution. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1539843
<ubot5> Launchpad bug 1539843 in linux (Ubuntu) "External microphone does not work" [Undecided,Confirmed]
<wxl> hey folks. if i'm using linux-image-generic-lts-* is it safe to remove linux-image-generic?
<tsimonq2> wxl: I would think it would be safe, but check grub after you remove it and reinstall it if it breaks it
<wxl> tsimonq2: yeah thanks but i don't want to deal with breaking it XD
<tsimonq2> wxl: well try it!
<tsimonq2> wxl: I think it shouldn't break it
 * wxl sighs
<wxl> i'd rather hear something from the kernel team so i'll be patient
<wxl> if it takes longer than it would take me to fix it, maybe i'll go for it XD
<tsimonq2> XD
 * tsimonq2 leaves this to the kernel team but thinks they can back him up on this
#ubuntu-kernel 2016-01-31
<apw> linux-image-generic-lts-* should be equivalent to linux-image-generic and there thould be no issue removing the latter if one of the former is installed
<xnox> apw, hola =)
<xnox> I think i see what's going on.
<xnox> I've pasted a patch to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536810
<ubot5> Launchpad bug 1536810 in linux (Ubuntu) "kernel install failed /bin/cp: cannot stat â/boot/initrd.img-4.3.0-7-genericâ: No such file or directory" [High,Confirmed]
<xnox> it does mean a kernel upload, again =/ and thus no cloud images until 4.4 lands =/
<apw> xnox, but why is it copying it in the first place, it should only do that if something is wrong, it should be making symlinks, which we cna do to the non-existant file
<apw> xnox, yes in copy mode it will fail, but we should never ever use that
<apw> xnox, your patch essentially renders the deferred building null and void in all cases
<apw> what we need to work out is why we think we are unasble to use a symlink for htat combination
<xnox> apw, not in all cases, only on upgrade (e.g. not reinstall as far as i can see)
<xnox> apw, why kernel manages symlink of initramfs instead of update-initrmafs?
<xnox> wait a minute.
<xnox> apw, we change to '/' and check existance of 'initramfs.img' rather than checking 'boot/initramfs.img' for the link_in_boot case
<xnox> apw, http://paste.ubuntu.com/14800299/ ?
 * xnox tests
<xnox> apw, however, in /etc/kernel/postinst.d/initramfs-tools INITRAMFS_TOOLS_KERKEN_HOOK=1 is set.
<xnox> thus negating the deffered initramfs-tools update.
<xnox> apw, i'm chatting to ben here at fosdem.
<xnox> he totally fixed this bug 6 years ago.
<ubot5> bug 6 in Launchpad itself ""next 10 entries" at bottom of page" [Medium,Invalid] https://launchpad.net/bugs/6
<xnox> sorry 2
<xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738707
<ubot5> Debian bug 738707 in src:linux "linux-image-3.12-1-amd64: Failed to symbolic-link /boot/initrd.img-3.12-1-amd64 to initrd.img." [Normal,Fixed]
<xnox> apw, https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=373d086904305699561b1eb505c33b010c24de9b
<xnox> i shall try cherry-picking that.
<xnox> apw, i think we shall resync our maintainer scripts.
<apw> xnox, likely we should, but that is no small task
<apw> given we have split linux-image and they do not, so we need to test properly
<xnox> apw, right cherrypicking that one commit is easy. especially since it's quite easy to reproduce on amd64 with ben's steps from there.
<apw> xnox, so i'll have a look at pulling that in to what we have for now, and get an upload done early next week
<xnox> which is still slightly different from what i have ondisk in the old cloud image, and slightly different what live build does. but it smells as the closest thing.
<apw> might even be able to get it in tonight, will see
<apw> we are waiting on testing anyhow
<xnox> apw, i think we can build cloud images with ppa's enabled, and with proposed enabled. cherry-picking above mentioned commit will be like a good thing to do (it's a valid bug on ubuntu currently). But e.g. i cannot easily validate if that will fix livebuilders or not =/ cause that needs a livebuilder, which means having a launchpad do it.
<apw> xnox, oh if you can do PPAs i could ram one into our unstable PPA for testing
<apw> xnox, you'd need just s390x right 
<apw> xnox, those only take like an hour to build
<xnox> yeah.
<xnox> well arm64, powerpc64el, armhf are also broken. But i couldn't care less about them =)
<apw> xnox, right, to allow you to confirm this fixes your issue, i could build it such that the others blow up
<apw> xnox, if you can confirm a PPA would do for a test ...
<xnox> right.
<xnox> i need cloudy people.
<apw> xnox, i've uploaded a +apw1 to ppa:canonical-kernel-team/ubuntu/unstable which should build for s390x
<xnox> apw, tah.
#ubuntu-kernel 2017-01-24
<dmj_s76> apw: kamal: Still need to test a potential fix, but there's a quite annoying bug affecting installs on Nvidia systems with 10 Series (Pascal) GPUs.  When using Nouveau with the 4.8 kernel, the cursor is only drawn stuck in the top left corner.
<dmj_s76> The actual mouse pointer can be moved and clicked anywhere (though you can't see where it really is)
<dmj_s76> This makes it essentially impossible for people to use their mouse during install.
<bjf> dmj_s76, after install is it still broken?
<dmj_s76> I've talked with the Nouveau bugs and this is fixed in 4.10 apparently, and they pointed to a couple commits that implement the needed functionality.
<bjf> dmj_s76, is there an LP bug about it?
<dmj_s76> bjf: It's a problem any time you're running nouveau.  It's fixed once you install the proprietary driver.
<dmj_s76> bjf: I did find an existing bug report: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1646574
<ubot5> Ubuntu bug 1646574 in xserver-xorg-video-nouveau (Ubuntu) "Mouse cursor invisible or does not move" [Undecided,Confirmed]
<bjf> dmj_s76, ok, i think that makes it a kernel bug and not xserver
<bjf> jsalisbury, LP: #1646574 can i trouble you to whip up a test kernel with the 3 commits in comment #23?
<ubot5> Launchpad bug 1646574 in linux (Ubuntu) "Mouse cursor invisible or does not move" [Undecided,Confirmed] https://launchpad.net/bugs/1646574
<bjf> dmj_s76, if you would kindly test that kernel when it's added to the bug that would be fantastic. we can get the fix into the next SRU cycle for the kernel
<dmj_s76> bjf: hopefully we can fix this for the 16.04.2 iso.  I'm able to test the fix on a dozen nvidia machines.
<dmj_s76> bjf: Great!
<bjf> dmj_s76, nope, missed the window for that i'm afraid
<dmj_s76> hrm
<bjf> yeah, that sucks
<dmj_s76> bjf: There isn't even an iso with the kernel.
<dmj_s76> Nobody's been able to actually test how the iso works with 4.8 and the new graphics stack.
<bjf> dmj_s76, the kernel that will be used for the .2 release is the kernel that is currently in -updates
<bjf> infinity, ^ is true isn't it?
<jsalisbury> bjf, no problem
<dmj_s76> bjf: Yes, but there have been issues in the past that were only caught by testing the iso.  14.04.5 wouldn't boot with NVIDIA a week before release.
<bjf> dmj_s76, i'm just telling you what i know right now
<dmj_s76> bjf: Fair enough, not trying to be argumentative
<bjf> dmj_s76, if we are using the kernel that is in -proposed for the .2 release there is a chance we could get this fixed and into the .2 release
<bjf> dmj_s76, but i need infinity to tell me what he's using to build the .2 isos with
<bjf> dmj_s76, didn't mean to imply you were arguing. i understand your concern
<dmj_s76> bjf: Okay...yeah, there is a 4.8 kernel in -updates (which we've been testing with for our production image testing) but there hasn't been a daily iso yet with 4.8, which means there very well could be blocking issues.
<bjf> dmj_s76, we don't have any know regressions right now that would cause a respin of the 4.8 kernel but if this fixes your issue i'd probably respin to pick it up and have it in -proposed
<dmj_s76> This is a regression that does affect the yakkety iso (*way* too late...there was a lot going on at that time) but the 16.04 and 16.04.1 isos have worked well.  We're quite sure this will change when 4.8 lands.
<dmj_s76> bjf: Thanks, hopefully this works like a charm.
<bjf> yeah
<infinity> bjf: The final ISOs will ship with whatever kernel you and Andy tell is sane. :P
<bjf> infinity, hmm... ok
<infinity> dmj_s76: If this affected yakkety, why sit on it for 3 months before pointing out its criticality again? :/
<bjf> will discuss that with apw
<infinity> bjf: Andy's been twiddling linux-hwe for other reasons, so squeezing in a few other commits IF TESTED would be entirely fine.
<bjf> infinity, ack
<dmj_s76> infinity: We did drop the ball a little...didn't notice in time for yakkety and I got quite busy with other fires.
<dmj_s76> infinity: Thanks, we'll try to be a little more on the ball next time.
#ubuntu-kernel 2017-01-25
<jsalisbury> dmj_s76, bjf test kernel posted to bug 1646574
<ubot5> bug 1646574 in linux (Ubuntu Yakkety) "Mouse cursor invisible or does not move" [Medium,In progress] https://launchpad.net/bugs/1646574
<dmj_s76> jsalisbury: Thanks!  Will test
<dmj_s76> jsalisbury: bjf: The test kernel works here.  Will test more of course but I have a functioning cursor at the desktop without the nvidia blob.
<bjf> dmj_s76, we will respin yakkety with the patches applied and have it available for the .2 release kernel
<dmj_s76> bjf: Thanks, the patches seemed good in all my testing last night.  Will test again when they hit the .iso.
<bjf> dmj_s76, ack
<hwpplayer1> could you please give more information about last patches
#ubuntu-kernel 2017-01-26
<kees> apw: hm, you still want a dmesg for my weirdo secure_boot machine?
<apw> if you hzve it why not
<kees> okidoky. I can't imagine why /proc/sys/kernel/secure_boot would say "0" when the bios says it's enabled. :P
<apw> what was that bug number, want to make sure someone is looking into it
<kees> rtg asked me for the /proc details
<kees> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1658255
<ubot5> Ubuntu bug 1658255 in linux (Ubuntu Zesty) "Kernel not enforcing module signatures under SecureBoot" [Undecided,In progress]
<kees> okay, added dmesg.txt
<slangasek> apw: yo, so LP: #1659654 would be nice to not have
<ubot5> Launchpad bug 1659654 in linux (Ubuntu) "regression in linux-libc-dev in yakkety: C++ style comments are not allowed in ISO C90" [Undecided,New] https://launchpad.net/bugs/1659654
#ubuntu-kernel 2017-01-27
<smb> slangasek, bug report updated and follow-up patch submitted for SRU
<apw> smb, thanks
<slangasek> smb: thanks :)
#ubuntu-kernel 2017-01-28
<hwpplayer1> http://askubuntu.com/questions/877081/will-a-thinkpad-x61-run-ubuntu
<hwpplayer1> Maybe kernel team members can answer this question better
<hwpplayer1> do we have kernel book list ?
<hwpplayer1> at our pages
<hwpplayer1> http://askubuntu.com/questions/877190/ubuntu-16-04-cpu-stress-test
<hwpplayer1> Does kernel patch services include cpu test ?
#ubuntu-kernel 2018-01-22
<apw> hallyn, it sounds like you are conflating ubuntu abi numbers and upstream stable numbers
<jsalisbury> tsimonq2, apw I'll build a test kernel for that bug.
<tsimonq2> jsalisbury: Thanks.
<mamarley> It looks like the v4.15-rc9 mainline kernel (with the 4.15.0-5.6 configuration) (inadvertently?) disables several options related to Broadcom B43 and B44 chips, causing these chips to not work with that kernel.
<mamarley> And also a bunch of SSB-related configuration options, which are also related to these chips.
<apw> mamarley, are they new?  new ones are taken at their defaults
<mamarley> apw: I don't think so; these have been around forever.  I also checked the commit history and it doesn't look like anything related to ssb or b4x changed since -rc8.
<hallyn> apw: coudl be, are you saying the kaiser patches were backported to 4.4.0-109-generic ?  except it's from jan 9, and the magic sysfile telling me i'm safe isn't there :)
<apw> those sysfs files.are total rubbish in the main
<apw> V1 reports bad always iirc even with the patches which fix it applied
<jsalisbury> tsimonq2, I posted a test kernel to the bug.
<tsimonq2> jsalisbury: Thank you :)
<s10gopal> https://bugs.freedesktop.org/show_bug.cgi?id=104737 please help me
<ubot5> Freedesktop bug 104737 in DRM/AMDgpu "amdgpu module does not bind to 1002:6660 R5 M330" [Major,New]
<tomreyn> this is being discussed in #ubuntu now, where it belongs
<TJ-> the user is inexperienced but persistent :)
<hggdh> the shotgunned a lot of channel with the exact same Q
<jackpot51> I am seeing linux-signed-generic 4.13.0.31.33 show up when doing debootstrap and then an apt update/upgrade. I do not see linux-signed-image-generic (= 4.13.0.31.33), and this is causing a failure to upgrade. Can someone help me out?
<mamarley> apw: Even when I remove the parts of "0006-configs-based-on-Ubuntu-4.15.0-5.6.patch" that disable the SSB options, the options still end up getting disabled somehow when the kernel is compiled.  I'm trying to figure out why that is, but not having much luck.
<apw> jackpot51: against which archive pocket?
<apw> mamarley: that implies a config constraint is disabling them
<apw> typically a select or depends influencing the value
<mamarley> I figured it was something like that.  I'm not sure how to figure out which one though.
<mamarley> I went through all the CONFIG_SSB* options that are defined and ensured that the config has them enabled.
<mamarley> I mean that the config has their DEPENDS enabled.
<mamarley> apw: I figured it out, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=664eadd6f44b3d71dcc62d0a825319000de0d5c9 causes the problem.
<mamarley> The problem is, as far as I can tell, CONFIG_PCI_DRIVERS_LEGACY is defined only on MIPS.
<apw> and _LEGACY is that new, and off?
<mamarley> apw: According to https://cateee.net/lkddb/web-lkddb/PCI_DRIVERS_LEGACY.html, it was introduced in 4.9.  There doesn't seem to be a switch for it anywhere in the x86_64 menuconfig though.
<mamarley> And searching for that symbol in menuconfig shows "Symbol: PCI_DRIVERS_LEGACY [=PCI_DRIVERS_LEGACY]"/"Type  : unknown"
<mamarley> Even if I set CONFIG_PCI_DRIVERS_LEGACY=y in the configuration, the next time I run menuconfig it just removes it.  I think the committer must have forgotten to try compiling b43/b44/ssb on anything but MIPS with that patch.  I will open an upstream kernel bug.
<mamarley> Wait, it is actually nel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58eae1416b804d900014d84feadda7195007cc30
<mamarley> Oops, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58eae1416b804d900014d84feadda7195007cc30
<mamarley> https://bugzilla.kernel.org/show_bug.cgi?id=198555
<ubot5> bugzilla.kernel.org bug 198555 in Network "Symbol dependency issue prevents compiling SSB_PCICORE and dependants on x86_64 and possibly others since 4.15-rc9" [High,New]
#ubuntu-kernel 2018-01-23
<hallyn> apw: just got the 4.4.112 update :)
<hallyn> of course, now i'm watching the 4.4.113-rc1 :(  now with minty retpoline flavor
<blaze> how can I check the status of applied fixes (IBRS and IBPB)?
<jdstrand> apw, bjf (cc sbeattie, tyhicks): I booted a Lenovo IdeaPad U460 into the new 4.13 linux-generic-hwe-16.04 kernel and it immediately reboots when selecting it from grub
<jdstrand> apw, bjf (cc sbeattie, tyhicks): it can boot the 4.10 kernel fine
<jdstrand> apw, bjf: because it won't boot, I can't ubuntu-bug it. can you advise on how to report?
<apw> jdstrand, +filebug is your only real option
<jdstrand> apw: what would be good to attach?
<apw> jdstrand, and that is the -31 one yes ?
<tyhicks> jdstrand: the kernel team will know better but in the meantime, you may want to try booting with the "nopti noibrs noibpb" kernel command line options to see if there's any different behavior
<jdstrand> apw: meta is 4.13.0.31.51, kernel is 4.13.0-31.34~16.04.1
<apw> jdstrand, if you have nothing other than a blank screen then there is little to add, trying tyhicks options is the next step
<apw> jdstrand, is this the first 3.13 you have tried on this ?
<jdstrand> apw: it is the first 4.13, yes
<apw> ok
<jdstrand> the 4.10 was ok
<apw> yep, it has none of the new fun applied
 * jdstrand nods
<jdstrand> apw: is there a pre meltdown/spectre 4.13 kernel that would be useful to try?
<tyhicks> jdstrand: Ubuntu-4.13.0-21.24 is the pre meltdown/spectre 4.13 kernel
<jdstrand> ok, I'll try that to see if it is a 4.13 thing or a security patch thing
<jdstrand> apw, bjf (cc sbeattie and tyhicks): ok, I filed https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1744942
<ubot5> Ubuntu bug 1744942 in linux-hwe (Ubuntu) "Lenovo IdeaPad U460 fails to boot with 4.13.0-31.34~16.04.1" [Undecided,Confirmed]
<jdstrand> I'll now try different command lines and kernels
<jdstrand> I think it is a Westmere/Arandale if that is helpful
<jdstrand> (though you might want to check the bug to be sure)
<jdstrand> I also marked the bug 'Confirmed' to avoid the bot
<jdstrand> tyhicks: I don't see any 4.13.0-21 kernels in https://launchpad.net/ubuntu/+source/linux-hwe/+publishinghistory
<jdstrand> tyhicks: are you saying just boot the artful kernel?
<tyhicks> jdstrand: there was a 4.13.0-21 artful kernel so I just assumed there was a 4.13.0-21 linux-hwe kernel
<jdstrand> seems so
<jdstrand> that vintage is still 4.10
<apw> jdstrand, it would have been linux-hwe-edge back then
<jdstrand> ah
<tyhicks> oh, right... linux-hwe was bumped from 4.10 to 4.13
<jdstrand> also if it helps, it is an i386 install
<apw> jdstrand, it makes it less worrying :)  in the sense if it is broke you are in a smaller set
<apw> jdstrand, also does the latest 4.4 boot for you
<jdstrand> apw: I'll test that too
<apw> jdstrand, ta
<jdstrand> apw: honestly, I forgot I was using 4.10 on that machine so going back to 4.4 wouldn't be so bad
<jdstrand> we'll see how things go
<apw> jdstrand, and you finding an issue is always good
<albert23> jdstrand: does that system have more than 4GB ram?
<albert23> i have bisected a 32 bit boot failure with > 4GB ram and got 92a0f81... x86/cpu_entry_area: Move it out of the fixmap as first bad commit
<jdstrand> albert23: no. 4G
<albert23> hmm, I thought the >4GB was important as it boots fine when pae is disabled in the kernel
<apw> albert23, it might not matter how much ram you have just that you are or are not using pae
<jdstrand> apw, bjf (cc tyhicks and sbeattie): https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1744942/comments/1 
<ubot5> Ubuntu bug 1744942 in linux-hwe (Ubuntu) "Lenovo IdeaPad U460 fails to boot with 4.13.0-31.34~16.04.1" [Undecided,Confirmed]
<jdstrand> apw, albert23: note that pae is listed in cpuinfo
<jdstrand> apw: right now I'm in an up to date 4.4 kernel, and it seems to be working so I'll stay there for now
<jdstrand> (this is not my machine. if you need me to test kernels, I can, but possibily not immediately)
<albert23> jdstrand: pae is also shown when pae is disabled in the kernel, and top shows 3547 MB ram instead of 8000
<jdstrand> it only has 4G, I promise
<jdstrand> :)
<apw> jdstrand, sounds like a plan, we may have some h/w showing similar issues, so we can investigate
<tyhicks> bjf, apw: FYI, chrisccoulson hit an issue where he could not boot an artful VM with the new kernel that we determined to be related to the bad intel-microcode that was reverted yesterday
<tyhicks> here's the bad combination of versions:
<tyhicks> host kernel: 4.13.0-25
<tyhicks> host microcode: 3.20180108.0~ubuntu17.10.1
<tyhicks> guest kernel: 4.13.0-31
<tyhicks> bjf, apw: the guest kernel booted after updating the host kernel (4.13.0-31) OR applying the reverted microcode package (3.20180108.0+really20170707ubuntu17.10.1) in the host and rebooting
<tyhicks> I'm glad we reverted the microcode package yesterday
<tyhicks> I don't think there's anything for the kernel team to do here but I wanted to point out the combination of old host kernel, bad microcode, and new guest kernel could cause VMs to not boot
<tyhicks> the solution is to apply the updates in the host (either the kernel or microcode but both are ideal) and reboot
<apw> tyhicks, thanks, that is a good data point
 * alkisg still hasn't had any reply for "kernel reboots on i5's", https://bugzilla.kernel.org/show_bug.cgi?id=198529 ...
<ubot5> bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New]
<tyhicks> apw: btw, here's the stack trace from the guest kernel that chrisccoulson saw: https://www.dropbox.com/s/rt6v13rifm7qt8z/Screenshot%20from%202018-01-23%2014-25-00.png
<apw> tyhicks, i wonder if chrisccoulson reported a bug with that, with what he was doing to trigger it
<tyhicks> apw: he didn't but he could if it would help you all
<apw> tyhicks, all and any issues; we want to know as much as possible about htem
<tyhicks> ack
<apw> as any one may be impossible to fathom but that third one gives you insight into the set
<tyhicks> chrisccoulson: please file a bug to help out the kernel team track the issue that you hit (https://wiki.ubuntu.com/Kernel/Bugs)
<chrisccoulson> tyhicks, sure, will do
<tyhicks> thanks!
<albert23> alkisg: that's the same commit i found bad too, on i3-4010U (intel nuc)
<albert23> that commit is known bad, see https://lkml.org/lkml/2017/12/23/121, but the fix 2 commits later still doesn't work for me
<alkisg> albert23: on 32bit installation, or 64bit?
<albert23> alkisg: 32 bit
<alkisg> Thanks, I verified this on a number of i5 processors, but not on any i3's until you mentioned that one
<alkisg> Happens on: i5-3470, i5-4460, i5-4440, i5-6200U, and doesn't happen on i3-4170,  i3-7100, Q6600, Q8300, i5-4590
<alkisg> albert23: do you think we need to do something more, except the bisection I did to pinpoin the commit, and the bugzilla report?
<alkisg> I would have expected some reply until now...
<albert23> maybe mark is a regression
<alkisg> Could you? And also comment that it affects you too?
<albert23> I think it's better i you do it. At least Intel graphics never liked "me too's" in bug reports
<alkisg> I thought that more than 1 user need to confirm a bug in order to get in the "confirmed" state
<alkisg> Otherwise it's just monologue...
<alkisg> Anyways, I'll revert the schools to 4.4 kernel and leave it for them to solve it when they can
<alkisg> albert23: btw, does it boot for you if you pass acpi=off? It worked on most of i5's, but a teacher reported it didn't work for him
 * alkisg also notes that there are no instructions in the ubuntu wiki on how to revert to the non-hwe kernel series... in the past, there were...
<albert23> alkisg: yes, it does boot for me too with acpi=off
<alkisg> Nice
<albert23> hmm, apparently acpi=off also mean no PTI
<albert23> and also no PTI in a kvm guest and no PTI when the kernel is built  without PAE
#ubuntu-kernel 2018-01-24
<jmux> Hi. I tried to follow the documentation for submitting a patch for inclusion in Ubuntu Xenial kernel and feel a little bit lost.
<jmux> I've submitted lp#1745130 and I've written a mail to kernel-team@lists.ubuntu.com.
<apw> LP: #1745130
<ubot5> Launchpad bug 1745130 in linux-lts-xenial (Ubuntu) "Support rfkill-any led trigger for Fujitsu u727" [Undecided,New] https://launchpad.net/bugs/1745130
<apw> jmux, i have just approved your post to the list ... things patch wise are progressing slower than normal, because of meltdown/spectre causing respins all the time
<apw> jmux, but it looks like you have done the right things in general
<apw> jmux, if you could include the sha1 of the original fil upstream in the bug that would help application
<apw> jmux, doh you did in the bug, so all is well
<jmux> apw: Thanks. I'm not in a hurry. I even could patch the kernel. The HW is still in evaluation and I have more patches, which I have to send upstream first.
<apw> jmux, ack great
<jmux> apw: and I have to test 18.04, which will be our next rollout at the end of this year.
<jmux> jsalisbury: Thanks for the kernel for LP: #1745130. Have to leave in a few minutes. Works as expected.
<ubot5> Launchpad bug 1745130 in linux (Ubuntu Xenial) "Support rfkill-any led trigger for Fujitsu u727" [Medium,In progress] https://launchpad.net/bugs/1745130
<yetoo> How does one manually uninstall a kernel or debug its postinst script
<yetoo> because every time I try to uninstall a kernel dpkg spits out an error
<yetoo> You can view the error in the most recent attachments here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1744214
<ubot5> Ubuntu bug 1744214 in linux (Ubuntu) "Boots into initramfs with an error stating that the UUID of the main partition cannot be found when it actually exists" [Medium,Incomplete]
<smeso> yetoo: what's the output of `file /etc/kernel/postinst.d/vboxadd` ?
<TJ-> We've seen that issue before with /etc/kernel/postinst.d/vboxadd
<TJ-> yetoo: is the root file-system on LVM?
<TJ-> oh, no, it's presented as sda1 from disk/by-id/ata-VBOX_HARDDISK_VB5edd919d-c9befa35-part1 which has /dev/disk/by-uuid/d15b971c-a592-4259-b4fd-b74cf3c4d03c
<TJ-> I've seen the UUID problem when using LVM and passing ROOT=UUID=xxxx (which is an LV but vgchange -ay isn't fired)
<TJ-> yetoo: I'd check if something is being added/removed from the initrd.img that's breaking things; look in /usr/share/initramfs-tools/{hooks,scripts} and /etc/initramfs-tools/{hooks,scripts}
#ubuntu-kernel 2018-01-25
<pizzadude> hi
<pizzadude> is the mainline kernel going to be compiled with retpoline for spectre mitigation in the future?
<pizzadude> i mean the kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/
<pizzadude-> right now it's "Minimal generic ASM retpoline" but not full protection
<apw> pizzadude, we don't even have retpoline compilers in the main archive yet, so we need those first
<apw> beyond that if it needs configurations we can sort that out and rebuild some of the key kernels
<pizzadude-> ok but is it gonna be fixed in mainline eventually (i know its mainly used for debugging, but i hate waiting for kernel fixes to be backported)
<pizzadude-> ^thats not me
<pizzadude-> well, it's my nick but
<apw> ?
<pizzadude-> nvm
<pizzadude-> but yeah is it gonna be fixed eventually or is the mainline kernel "ppa" a red headed stepchild that canonical doesnt care about
<apw> the mainline ppa builds there are for debugging, we keep a weather eye on them, they are not official in any sense
<pizzadude-> yeah i know but some people use them
<apw> with meltdown/spectre we are likely to make more effort to get them working
<pizzadude-> them being "ubuntu kernels", mainline, or both?
<pizzadude-> sorry if im being annoying
<apw> the mainline builds test builds
<pizzadude-> thanks
<pizzadude-> .
#ubuntu-kernel 2018-01-26
<Sean_McG> hi, I'm wondering if the Ryzen NPT patch from 4.14 can be backported to the 16.04 HWE kernel. Documented here: https://level1techs.com/article/patch-npt-ryzen-better-performance
<TJ-> ^^^ Q from #ubuntu
<TJ-> Sean_McG: it'd be good to mention the mainline commit hash 
<Sean_McG> OK, let me find it
<Sean_McG> kernel.org Git URL OK?
<Sean_McG> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kvm/svm.c?h=v4.15-rc9&id=15038e14724799b8c205beb5f20f9e54896013c3
<TJ-> Thanks, so commit 15038e1 "KVM: SVM: obey guest PAT"
<Sean_McG> yessir
<sbeattie> it would be helpful to have a bug report.
<f_g> sbeattie: we carry that one in our downstream kernel, haven't filed it yet but it's on my TODO list.
<f_g> it's a straight-forward cherry-pick IIRC
<mamarley> apw: Can you switch the mainline kernels to being compiled on Bionic so they will compile with the retpoline-supporting GCC 7.3?
<maxb> Hello. I have just figured out that my Bluetooth woes in artful are due to incompatibility between the Intel 8260 wifi and bluetooth firmwares. Fixed firmware landed in linux-firmware.git in December: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit?id=fdee922a785212be7ccced6809b337290fdac971 but has not yet made it in to bionic.
<maxb> 1) Is this something someone would consider SRUing for artful?
<maxb> 2) Is there a planned resync of bionic's linux-firmware with upstream, or should I file a bug about that separately?
<maxb> Existing bug in LP: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1719210
<ubot5> Ubuntu bug 1719210 in linux (Ubuntu) "Bluetooth audio to A2DP headset no longer works following upgrade from 4.12 to 4.13 in artful" [Medium,Incomplete]
#ubuntu-kernel 2018-01-27
<TJ-> We have a PTI regression killing resume-from-hibernate for 4.13-0-25 onwards. One user has confirmed "nopti" fixes the issue.  Bug #1743094
<ubot5> bug 1743094 in linux (Ubuntu) "[regression] hibernation (freezes on resume) due to PTI" [Medium,Confirmed] https://launchpad.net/bugs/1743094
<Tomwolf> I have a bug that has been fixed upstream. The problem is that the kernel panic happens on first boot after fresh install. It was fixed in kernel 4.13.0-31.34 and while I understand that 18.04 will use 4.15 I can't find a way to get an ubuntu installed with a working kernel. Any tips on how to go about things? I've just recently decided to actually learn how to work with linux servers so bare with me if I'm ignorant.
<TJ-> Tomwolf: if you do the install but don't reboot at the end, you can start a terminal, chroot mount into the new rootfs, and "apt install linux-image-generic-hwe-16.04"
<Tomwolf> Thank you =) If I want to upgrade to 17.10 or even 18.04 on the development server, will that keep the hwe?
<TJ-> Tomwolf: Yes... hwe depends on the 4.13 kernel; later, hwe-edge will depend on 18.04's released kernel
<Tomwolf> Thank you =) now I don't have to 'settle' for running Centos 7 when I really want to use Ubuntu.
<Tomwolf> I appreciate the help @TJ- =)
#ubuntu-kernel 2018-01-28
<NickTux> Hello, can someone point me to the right direction on how to fix this build error ? https://is.gd/H4KYHJ 
<tomreyn> http://ck-hack.blogspot.de/2017/11/linux-414-ck1-muqss-version-0162-for.html
<tomreyn> did you do a web search for this error, yet?
<NickTux> tomreyn: Yes I did and found it. I have created a patch (local), applied and it worked. Thanks anyway.
#ubuntu-kernel 2020-01-20
<zx2c4> apw: ping again?
<zx2c4> debian has changed some package things
<zx2c4> binary package names are the same :https://packages.debian.org/sid/wireguard https://packages.debian.org/sid/wireguard-dkms https://packages.debian.org/sid/wireguard-tools
<zx2c4> binary package names are the same: https://packages.debian.org/sid/wireguard https://packages.debian.org/sid/wireguard-dkms https://packages.debian.org/sid/wireguard-tools
<zx2c4> but the source packages are now split into "wireguard" and "wireguard-linux-compat"
<zx2c4> https://packages.debian.org/source/sid/wireguard-linux-compat https://packages.debian.org/source/sid/wireguard
<apw> zx2c4: fun ... why have they done that now
<zx2c4> apw: i guess you havent read any of my emails or the several messages ive sent you on IRC in the last few weeks?
<zx2c4> ill resend you stuff
<zx2c4> one sec
<zx2c4> apw: sent again
<zx2c4> can you confirm you got the email and there isnt spam filter stuff happening?
<apw> zx2c4: you choose your moments, just accepted fully, and you change names, sigh
<zx2c4> apw: wait what?
<zx2c4> sorry, but no
<zx2c4> i emailed you about this a month ago
<zx2c4> a few times
<zx2c4> sent you messages in here
<zx2c4> poked sultan
<zx2c4> have been trying to get in touch with you to coordinate this
<cjwatson> zx2c4: the wireguard-linux-compat source package is already in focal-proposed, FYI
<zx2c4> oh, really? then what on earth is apw talking about
<zx2c4> when he says "just accepted fully, and you change the names"
<cjwatson> I'm not going to engage in telephone-game stuff, just giving information
<cjwatson> it might be that proposed-migration just needs to be hinted to migrate wireguard and wireguard-linux-compat together; not completely sure
<cjwatson> since both are valid candidates
<zx2c4> is there anything open source anywhere?
<apw> cjwatson: dunno we have delta, so perhaps they are out of sync
<zx2c4> both https://packages.ubuntu.com/focal/wireguard-tools and https://packages.ubuntu.com/focal/wireguard-dkms both indicate old packags
<cjwatson> apw: as I say they're both valid candidates
<apw> hmmm
<zx2c4> ideally you should just import dkg's packages and be done with it
<zx2c4> no need to do anything complicated
<cjwatson> zx2c4: I'm looking at rmadison output.  packages.ubuntu.com is not the best view
<zx2c4> there's been plenty of warning abut this
<cjwatson> The source packages in Ubuntu are the Debian packages with minor adjustments on top
<zx2c4> cjwatson: link to rmadison? never heard of this
<cjwatson> it's in the devscripts package
<cjwatson> Or you could look at Launchpad
<apw> zx2c4: yeah we were somewhere we understood and now we aren't so that is confusing and work and work is always annoying
<zx2c4> ah so i have to install ubuntu
<zx2c4> will look at launchpad
<cjwatson> https://launchpad.net/ubuntu/+source/wireguard and https://launchpad.net/ubuntu/+source/wireguard-linux-compat
<zx2c4> apw: yes, this is why ive tried to contact you every single week, sometimes several times, through differing means, for like a month or maybe more
<zx2c4> cjwatson: thanks
<zx2c4> cjwatson: oh, good, looks like those are up to date
<zx2c4> wireguard-linux-compat is one version behind, but i assume the verison bump will trickle down
<zx2c4> thats usually just a matte rof time, right?
<cjwatson> Will need a manual merge since there's an Ubuntu delta, but probably better to get the current set migrated to focal first
<cjwatson> On general principles
<apw> cjwatson: yeah I'll poke it
<cjwatson> ta
<apw> zx2c4: not your fault, I know I am the one burried
<zx2c4> cjwatson: for eoan i vaguely recall there being a delta because of a work around for some ubuntu kernel derp
<zx2c4> for focal, i dont anticipate that happening again
<zx2c4> so not sure there should be a delta. unless im forgetting something?
<zx2c4> apw: also, did you ever succeed in building the signed binary module?
<cjwatson> The reasoning is described in the changelog
<cjwatson> Which is visible from the LP links that I gave you
<zx2c4> ah thanks
<cjwatson> I haven't looked in detail, but it is clearly not just about "some ubuntu kernel derp" (whatever that means)
<zx2c4> oooo, right, getrandom and the demo test
<zx2c4> i remember now
<zx2c4> you're right
<zx2c4> thankfully those two patches are on top of the up-to-date wireguard package
<zx2c4> the new wireguard-linux-compat package doesnt have either of those patches
<zx2c4> and the one i had in mind has been dropped, per that changelog
<zx2c4> so that means the version bump should be a bit easier than usual
<zx2c4> ooo apparently this was done a few days ago by ` -- Unit 193 <unit193@ubuntu.com>  Fri, 17 Jan 2020 18:33:54 -0500`
<zx2c4> i wonder who that is
<cjwatson> That's all the naming I've ever seen for them; AFAIK they're an Ubuntu developer who consistently goes by a pseudonym
<apw> zx2c4: I did patches and got stalled
<zx2c4> apw: ah, could you pick that back up before focal hits?
<zx2c4> meaningful feature parity with the rest of linux seems like a valuable thing to have, given focal release will align more or less with 5.6
<hggdh> Although I am pretty sure it must be documented somewhere... could not find it: I installed linux-crashdump (18.04 instance under Azure), and sysrq c to test it. Crash kernel came up as expected (after I increased memory reserved to crashkernel), generated a crash file on /var/crash.
<hggdh> but the crash file did NOT have the vmcore. What am I missing (I have never had the need to use crashkernel on Ubuntu, so I am sort of surprised)
<apw> zx2c4, ok at least what is there is migrated
<zx2c4> wireguard-linux-compat is an old version, as i mentioned above. we're waiting in that to migrate next.
<zx2c4> Im not aware of any ubuntu-specific patched that youll need atop wireguard-linux-compat
<zx2c4> Seem like binary .ko distributed with the rest of Ubuntu kernel modules will be possible? Or planning on a package called wireguard-modules? Or?
<zx2c4> apw: 
<apw> zx2c4, that is my plan; likley linux-modules-wireguard i think
<zx2c4> Okay. In that case youll want to change the Requires of the wireguard package to use that name instead of wireguard-modules
<zx2c4> https://usercontent.irccloud-cdn.com/file/r4Tj6FtJ/Screenshot_20200120-234357.png
<zx2c4> https://usercontent.irccloud-cdn.com/file/Ic6CZxpM/Screenshot_20200120-234434.png
<apw> zx2c4, i'd provide whatever you are expecting
<apw> Provides:
<zx2c4> Oooo a provides matches a dependency, cool
<zx2c4> Thats so much nicer than the crazy metapackage system we have in Gentoo
#ubuntu-kernel 2020-01-21
<zx2c4> apw: looks like unit193 has saved the day again
<apw> zx2c4, the community rocks indeed
<apw> zx2c4, he did the merge i was going to do today; yay
<apw> zx2c4, so everything is in sync in focal for you yes?  you just need that email replied to ?
<zx2c4> apw: email replied to?
<zx2c4> Everything in sync except for the binary module
<zx2c4> Ill test unit193's work today to be sure
<apw> you were asking for some version links or somethign in email; or did you sort that
<apw> zx2c4, the binary is on my list
<zx2c4> www.wireguard.com/install/
<zx2c4> https://www.irccloud.com/pastebin/LN6BxPtX
<apw> zx2c4, ahh ok you are sorted there
<zx2c4> Pretty gnarly way of getting that info outta launchpad...
<zx2c4> If you know of a real api, id prefer that to scraping HTML
<gpiccoli> hggdh, what are the contents on /var/crash after the crash collection?
<gpiccoli> And what is the kernel version you're using and the release (Bionic, Eoan, etc) ?
<cjwatson> zx2c4: What's the problem statement for that last pastebin?  Something like "get most recent version of named packages in each of the Ubuntu archive and a given PPA"?  And do you want to restrict it to a particular suite (e.g. focal or focal-proposed) or do you just want anything that's anywhere in Ubuntu at all?
<zx2c4> cjwatson: "whats the latest version of a package from a certain PPA?" "whats the latest version of a package from 'upstream ubuntu'?"
<zx2c4> probably not restrict because ubuntu has weird policies about what gets backported
<zx2c4> and what im itnerested in is a general dashboard of, "are the maintainers bumping their packages"
<cjwatson> zx2c4: Maybe something like https://paste.ubuntu.com/p/DMbfHvw3D6/ then?  Two notes: (1) I changed the PPA queries a bit because you need to query by source package rather than binary; (2) that API sorts by descending version by default, which sounds mostly fine for this except be aware that the PPA has versions like 1.0.20200102-wg1~trusty, 1.0.20200102-wg1~eoan, etc., and "trusty" > "eoan"
<cjwatson> For an upstream view given (2) perhaps you just want to strip off the suffix
<zx2c4> cjwatson: oo, api.launchpad.net, excellent
<zx2c4> is this json-only or can i ask it for something in plain text?
<cjwatson> That method is documented at https://launchpad.net/+apidoc/devel.html#archive-getPublishedSources if you need to vary things
<cjwatson> JSON-only, but the | jq at the end gets you plain text
<cjwatson> (Well, I think you can possibly ask it for XML or something as well if memory serves, but who wants that)
<cjwatson> ... no, memory serves incorrectly, it is indeed JSON-only
<zx2c4> cjwatson: looks like you can get xml by passing Accept: with some sun xml type
<zx2c4> but anyway i got it working
<zx2c4> www.wireguard.com/install/ is now powered by that api
<zx2c4> lots of red in there since i *just* bumped the packages :-P
<cjwatson> good good
<apw> http://www.wireguard.com/install/
<hggdh> gpiccoli: just found out I fat-fingered... Sorry for the noise
<gpiccoli> np hggdh =)
<gpiccoli> glad it worked for you
<hggdh> so am I, so am I :-) trying to document the myriad different ways to setup & use crash in Azure
<gpiccoli> hehe
<bittin> Hello was there any Ubuntu Kernel Meeting today ?
<sarnold> bittin: I don't know if it was an official meeting but there was certainly discussion https://irclogs.ubuntu.com/2020/01/20/%23ubuntu-kernel.html and https://irclogs.ubuntu.com/2020/01/21/%23ubuntu-kernel.html
<Luna__> sarnold, thanks :)
<Luna__> and https://irclogs.ubuntu.com/2020/01/21/%23ubuntu-kernel.html
<Luna__> Wireguard talk, cool thanks gonna join a Thunderbird meeting in 2 minutes but cya guys next week
<zx2c4> tyhicks: https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1854225 can restricted wireguard bugs be shared with me in the future so there isnt the 4 month delay or whatever?
<ubot5> Ubuntu bug 1854225 in wireguard (Ubuntu) "Kernel oops and system lock up when invoking wg-quick up" [Undecided,New]
#ubuntu-kernel 2020-01-22
<tyhicks> zx2c4: hey - yes, that's easy to do
<tyhicks> zx2c4: will do in the future
<toni-patroni> will there be a focal kernel git mirror at https://kernel.ubuntu.com/git/ubuntu/ like for eoan and older releases?
<toni-patroni> currently only meta, lrm and signed "meta repos" are there
<toni-patroni> or should one just go with git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal ?
<apw> toni-patroni, the latter is the officall master.  not sure why the repo is missing though from the mirror
<apw> toni-patroni, ok ought to be there
<toni-patroni> apw: yeah, works now - thanks!
<zx2c4> apw: hows that binary module stuff going?
<apw> zx2c4, it is queued behind some general fixes for packaging for dkms mangling in general that i am doing right now
<zx2c4> ahh the machinery needs oiling
<apw> always does, doesn't it
#ubuntu-kernel 2020-01-23
<caribou> Hello,
<caribou> Is it normal that the network installation kernels in netboot.tar.gz higher than 4.15.0-20 do not have the NVME modules available ?
<caribou> I need a newer kernel for installation to work around LP: #1767992 but cannot see my NVMe on the host with kernels 4.15.0-60 and/or 5.3.0-18
<ubot5> Launchpad bug 1767992 in linux (Ubuntu) "Linux md raid-10 freezes during resync" [Undecided,Confirmed] https://launchpad.net/bugs/1767992
<apw> caribou, how are you installing the kernel
<apw> nvme might be built-in, or are you missing -extras and it is in ther
<caribou> that's the installation kernel so it is started by a PXE boot (it's a network install), hence it just runs busybox
<caribou> apw: ^
<caribou> I suspect that it has moved to -extra, but this one is not available at the first phases of network installation
<caribou> (I thought of checking here first before opening a bug on this)
<apw> ack
#ubuntu-kernel 2020-01-24
<sdhd-sascha> hi, 
<sdhd-sascha> I have a bond-device and added it to a bridge. 
<sdhd-sascha> I want to use this bridge for lxd and kvm, to expose all machines into the physical network.
<sdhd-sascha> Should i enable stp ? Because, if i add `stp: yes` to netplan - then my network is not reachable. 
<sdhd-sascha> (Not sure how to debug this issue. My network skills are not the best )
<sdhd-sascha> Currently it's ubuntu 20.04 - but had the same effect before in 19.10
<sdhd-sascha> Should i give the bond0 all mac-addresses from all physical interfaces ? (Currently don't know how to look into the arp-table of my switch)
<sdhd-sascha> E. g. MAAS gives the bond only one mac-address from one device (not sure, if the bond-mode does control this)
<nils_> sdhd-sascha, not sure if this is strictly kernel related. 
<sdhd-sascha> nils_: i'm too. Whom could i ask ? 
<sdhd-sascha> Some Ceph or Openstack people ... I look, for other channels ;-) thank you
<nils_> the bond device is connected to a switch? 
<nils_> It may be that enabling STP on the bridge interferes with the switch. 
<sdhd-sascha> nils_: yes. Good hint. :-)
<sdhd-sascha> I found #openstack. And there i get the information, that no `stp` is needed, because i didn't create loops on the host 
<sdhd-sascha> Thank you :-)
 * sdhd-sascha really need to refresh my network knowledge 
<zx2c4> apw: any repo where i can follow along your dkms reworking? ive been poking around launchpad to get a handle on it but havent found much
<apw> zx2c4, oh no, that is all local right now; the fight i have been having with the librarian and provides is over
<zx2c4> apw: oh my...
<zx2c4> O_o
<zx2c4> do you mean this whole thing with linux-module-wireguard "providing" wireguard-modules, which the wireguard metapackage depends on?
<apw> zx2c4, the support that would be used for that; but for the existing builds, nvidia and hte like
<zx2c4> ah gotcha
<apw> but the existing stuff was a bit of a mess to add to, and bugs in the first phase take hours to build
<zx2c4> zoinks
<zx2c4> well hopefully wireguard will just be "drop in"
<zx2c4> should have a relatively sane build system compared to nvidia....
<apw> yes, it should be easy, nvidia not so much
<zx2c4> apw: well let me know when i can try it out / when youve got something publish pushed
<fling> Is eoan at 5.4 now?
<fling> Am I supposed to get shiftfs patches from eoan if I want them for 5.4?
<fling> probably not
<gpiccoli> fling, eoan is 5.3 - the new release (devel), called Focal, is 5.4 AFAIK
<fling> gpiccoli: how do I clone it's repo using linus tree as base?
<fling> git clone --reference linux focal.git
<fling> what is the focal git repo? :P
<sarnold> fling: https://kernel.ubuntu.com/git/ubuntu/ looks to have one
<fling> thanks
<gpiccoli> I've been using this one fling : git://kernel.ubuntu.com/kernel-ppa/mirror/ubuntu-focal.git
<fling> n=5401 ; for c in $(git log fs/shiftfs.c | grep ^commit | sed s/commit\ // | tac) ; do git format-patch -1 --start-number $n $c ; n=$(($n+1)) ; done
<fling> this is how I get shiftfs patches ^ is there a better way to filter out what I need?
