#ubuntu-kernel 2005-09-12
<desrt> BenC; ping
<TheMuso> 
<fabbione> morning
<doko> do our kernels have VIA longhaul support? (http://radagast.bglug.ca/epia/longhaul.html)
* netjoined: irc.freenode.net -> kornbluth.freenode.net
#ubuntu-kernel 2005-09-13
<dilinger> BenC: *poke*
<fabbione> morning guys
<BenC> hey
<fabbione> hey BenC 
<fabbione> BenC: how is it going?=
<BenC> pretty good
<BenC> fabbione: did any of the other security patches in your 2.6.10 upload have to do with 2.6.12?
<fabbione> BenC: we have one or two patches we need to portfoward from .10 to .12
<fabbione> BenC: i was planning to do it tomorrow
<BenC> can you send them to me?
<BenC> I can get to them today
<fabbione> there is the hyperthreading patch (it's already in the archive)
<fabbione> and we need to check CAN-2005-1913
<fabbione> the hyperthreading one is a very old CAN
<BenC> already in the 2.6.12 archive?
<fabbione> no.. it's in .10 only
<fabbione> and we need to portforward it to .12
<fabbione> i did recheck all the security stuff while i was doing .10
<fabbione> and we miss that one in .12
<fabbione> and need to check the one for 1913
<fabbione> it was in .10 package for long time, but never applied
<fabbione> don't ask me why :) i didn't do that release
<fabbione> so you can just grab the .10 sources from the archive
<fabbione> and you will get all of them
<fabbione> in any case the ht is important
<BenC> ok, I'll take care of that today for 2.6.12
<fabbione> perfect
<fabbione> BenC: you probably recall that hw bug in p4 + ht processors
<fabbione> when i started .12 i did purge that patch, because i was pretty sure upstream did fix it
<fabbione> yesterday it did pop to my mind to check it again
<BenC> fabbione: that ht patch is really security related?
<BenC> maybe I'm looking at the wrong patch
<BenC> ht.dpatch, security related, ok
<BenC> is ht insecure?
<Mithrandir> BenC: it appears so, yes.  You can get leakage of data from one process to another.
<BenC> there's no workaround for it other than disabling it?
<Mithrandir> I think it's a hardware problem, so no
<BenC> fabbione? 
<dilinger> BenC, fabbione: so, now that i've finally got an internet connection, i'm going to set up the sunfire and offer debian/ubuntu to use it as a buildd
<dilinger> BenC: this is the machine that has the silo-booting-from-iso9660 problem, btw
<dilinger> BenC: so if you get bored and feel like figuring out what's up w/ it, i can hook up a serial console and let you play
<BenC> dilinger: I'd be interested
<BenC> if I ever find time
<BenC> that UltraIII boot from cd problem has been haunting me for awhile
<dilinger> i'll set it up over the weekend
<BenC> mainly because I don't have the hw to reproduce it :)
<BenC> does that system have LOM?
<dilinger> yea, i remember you saying that, which is why i offered
<dilinger> i believe so, although i've not played w/ it
<BenC> if you can set that up (telnet or serial) that would be best
<BenC> I'm sure I'm going to need a lot of hard power cycles, and I don't want to bug you every 10 minutes :)
<dilinger> i assume you'll need me to burn cds anyways
<BenC> ah, true, didn't think about that
<BenC> does the box have a cd burner in it?
<BenC> then I could boot to the system and do my own
<dilinger> no, but the box that's hooked up to its serial does
<BenC> doesn't get around the need for you to be at my beck and call though
<dilinger> i figured i'd just give you an account on there, w/ access to serial and the burner
<BenC> can you put a cdr capable drive in it? just IDE for the cd, right?
<dilinger> true, but it's in my apt, so it won't be a problem
<dilinger> i believe it's ide
<BenC> I work weird hours when I do off-time stuff though
<jbailey> Reminds me that I should ask the grub sparc guy how it's going.  He had module and kernel loading working, but I don't think he actually had it booting the kernel.
<jbailey> But he did have it coming up and loading the grub filesystem modules and such.
<dilinger> hm
<BenC> jbailey: wow, that'd be a nice improvement
<dilinger> BenC: what do you suppose would happen if you attempted to boot off an iso9660 image that wasn't on a cdrom?
<BenC> dilinger: not sure that's possible
<BenC> openboot has to think it's a cdrom
<BenC> and first-isofs.b has to actually be on a cdrom
<dilinger> ok
<BenC> well, it atleast assumes such things when using firmware calls
#ubuntu-kernel 2005-09-14
<fabbione> morning guys
<lamont> make[1] : Entering directory `/build/buildd/linux-restricted-modules-2.6.12-2.6.12.2/debian/build/2.6.12-8-hppa32/madwifi'
<lamont> Makefile.inc:101: *** KERNELPATH: /usr/src/linux-headers-2.6.12-8-hppa32 does not exist.  Stop.
<lamont> lrm needs new build-deps for hppa... sigh.
<lamont> fabbione: any uploads planned?
<lamont> and it needs sparc build-deps.  then linux meta packages (and therefore ubuntu-base, iirc) become installable...  this is a pre-req for d-i working
<fabbione> lamont: meh dude.. it can be done, but i so much didn't want to build restricted on sparc
<fabbione> d-i works fine here.. even without restricted stuff
<lamont> fabbione: then fix linux-meta
<fabbione> and it builds fine
<lamont> hrm.. let me rephrase that...  pretty sure that livecd generation will be b0rked.  or some such
<fabbione> we don't even build normal CD for sparc :)
<fabbione> i am happy with netboot for breezy
<fabbione> all sparcs can do that
<lamont> yeah, well... this'd kill it.
<fabbione> well i will work on it this weekend after i change server 
<lamont> my goal is at least a base-livecd, just because.
<fabbione> and so on
<lamont> right
<fabbione> i need to move w-b and other stuff to the server
<fabbione> so that the sparc is more free to build
<fabbione> at that point i can add restricted
#ubuntu-kernel 2005-09-15
<zul> hey sorry i havent been around the past couple of days work is really really really hectic though
<zul> in fact im there now :)
<jbailey> zul: Sick.  What's happening?
<zul> jbailey: clients keep sending us spreadsheet for test cases and sometimes the data is invalid so I been keep asking to reload the data, and I have to keep doing QA regenerating the messages sent to the server. fun fun
<zul> and im also in toronto monday/tuesday so i have to get this done by sunday night
<jbailey> Nasty.
<jbailey> Noone should ever have to go to Toronto.
<jbailey> ;)
<zul> exactly my point..
<zul> oh since the toronto film festival is on we have a hotel in brampton for god's sake
<zul> oh and i got accepted for sponsorship 
<zul> to go to ubz
<fabbione> hey zul
<fabbione> so are you coming to ubz?
<zul> i hoping i have to ask for some time off
<jbailey> zul: You're working this weekend, take it as time in lieu.
<jbailey> For entertainment, I'm running the ltp.
<jbailey> Anyone know if the authors of this are actually competent or not?
<jbailey> Wow, I've never seen anything drive this machine up to a loadavg of 18 before..
<sedak> hello !
<sedak> fabbione, are u here ?
<fabbione> sedak: sort of
<sedak> hello fabbione 
<sedak> can you have a look at my package now ?
<sedak> the wlan driver ...
<fabbione> it's like.. saturday evening...
<sedak> ok
<fabbione> sedak: nothing personal really.. it's just that i am really busy
<sedak> no it's fine, i understand
<sedak> i just keep coming at the wrong times :-)
<sedak> but i think it would relieve thousands of ubuntu users to have this packages, it would be nice to have it available soon ;-)
<fabbione> sedak: a package that lands in universe is still not part of the CD
<fabbione> so it won't help as much as you think
<sedak> yes, that's true
<sedak> but maybe i could write a patch for the kernel after that if you want to ...
<fabbione> and MOTU's should really learn to look to a bit of everything
<fabbione> sedak: it won't make breezy anyway
<sedak> yes i know
<fabbione> the kernel is almost super frozen
<sedak> that's why i am not in such of a hurry
<fabbione> sedak: if you can wait after breezy we can get it in the kernel directly
<fabbione> and everybody is happy
<fabbione> but for that you will have to start poking BenC
<fabbione> i am out of the kernel :)
* fabbione needs 5 minutes break
<sedak> and i don't really know how well this driver work, so that's why i created a module package, so that people can test it
<sedak> ok i'll do that :-)
<marty> I have  a system with a SCSI drive and Ubuntu Install can not detect it. Anyone know how I can install on that drive?
<marty> I have  a system with a SCSI drive and Ubuntu Install can not detect it. Anyone know how I can install on that drive?
<jbailey> marty: Best to try on #ubuntu
<jbailey> marty: My initial guess, though, is that if it's not detected, it might just not be supported byLinux.
<marty> jbailey, thanks. Ya, not much response in the #ubuntu forum. It's a shame because this system is really old. It would be nice if like Red Hat, ubuntu had a driver disk.
<jbailey> marty: Mmm, perhaps.  It's so rarely needed, though.
<marty> true
#ubuntu-kernel 2005-09-17
<karlheg> What is the correct command line for 'make-kpkg' to build an Ubuntu 'linux-image' package that creates an initramfs when it is installed?
<Lathiat> karlheg: the ubuntu kernel packages wdont use make-kpkg
<Lathiat> karlheg: make-kpkg is for makign custom kernel packages, the ubuntu packages have their own build system using normal debian stuff
<karlheg> I tried what seemed obvious, and it fails, complaining about the '-m' option being illegal.
<Lathiat> (aiui)
<karlheg> Ah.
<karlheg> Is a 2.6.13.1 on the near horizon?
<Lathiat> I beleive we are far too late in the release cycle to move to 2.6.13
<Lathiat> (however I have no idea on the actual plans for that, if any)
<karlheg> Perhaps 'mkinitramfs' ought to be drop-in compatible with 'mkinitrd'?
<karlheg> I thought it was, for some reason.
<karlheg> I think I see the problem.  I used the '--mkimage' switch.  I think if I drop that, it won't try to use the '-m' option for the mkinitrd command... perhaps that will get me an initramfs??
<jbailey> karlheg: Eh? =)
<jbailey> mkinitramfs ought to be drop in compatible.  Did I miss something?
<karlheg> I'm trying to build a kernel using 'make-kpkg'.
<karlheg> The -m switch is not implemented.
<jbailey> Right, because the previous kernels didn't use it.
<jbailey> What is trying to do so?
<jbailey> That was a way of specifying the tool to generate the cramfs.  It's the Wrong Thing with initramfs, and the current kernel packages don't use it.
<jbailey> If make-kpg does, it needs to be fixed to not.
<karlheg> Ok, it works.
* jbailey hates custom kernels and wishes they would all Go Away(tm)
<karlheg> If you don't use the '--mkimage' switch to make-kpkg, it works fine and the initrd image is really an initrams.
<karlheg> I want to use software suspend2 because the one in the Ubuntu stock kernel does not work on my laptop.
<karlheg> Suspend2 is a lot better; I wish it was in the stock kernels.
<karlheg> The latest release of Suspend2 is a patch against 2.6.13, and so I cannot simply use the Ubuntu linux source.
<jbailey> How old is your laptop?
<karlheg> It's fairly new.
<jbailey> suspend to ram works should work on almost all newish laptops AFAIK.
<karlheg> ... a year and a half or so.
<jbailey> Which one?
<jbailey> To answer your earlier question - breezy will ship with 2.6.12
<jbailey> UVF was quite awhile ago.
<mjg59> jbailey: Unless they use non-Intel chipsets, in which case it's a bit of a crapshoot
<mjg59> karlheg: Have you filed a bug?
<jbailey> mjg59: Are via ones bad, too?
<mjg59> jbailey: Well, the one I have is
<jbailey> =)
<karlheg> It's a Uniwill 244II0
<karlheg> No bug has been filed.
<karlheg> Suspend to RAM works, partially.  It suspends and resumes, but on resume, the keyboard is dead.
<karlheg> Suspend to disk, with the default configuration after a fresh install of hoary with subsequent upgrade to breezy will suspend, but on resume will reboot during reload.
<karlheg> I need to reboot now.  BBL.
<jbailey> mjg59: Is that the usb issue you were talking about on resume from suspend to disk?
<mjg59> jbailey: Yes
<jbailey> Cool.
<Mithrandir> mjg59: does std/str work with SATA now?
* jbailey tries to remember if he tried STD on his ppc/sata system.
<mjg59> Mithrandir: Yes
<mjg59> jbailey: No, the breakage is purely that USB doesn't work after resume
<jbailey> Ah, okay
<jbailey> mjg59: Around?  In server mode, usplash drops you at the console with the loading things rather than the login tty
<jbailey> Is that expected?
<Mithrandir> mjg59: excellent, I'll see if I can break it, then
<jbailey> Is  NTFS_RW still experimental?
#ubuntu-kernel 2005-09-18
<mjg59> Hmm. There's a Yukon-2 driver in the netdev tree.
<BenC> isn't that the broadcom variant that skge wont work for?
<mjg59> Yes
<BenC> netdev is in a git tree, isn't it?
<jbailey> BenC: Will you suck in Chuck's patch for 11237 soonish?
<mjg59> Hmm. Allegedly, anyway. I can't find it.
<mjg59> Wuh?
<mjg59> It's in -mm, but I can't find it in netdev's git tree
<mjg59> Madness
<BenC> I need checks baz archive url again
<BenC> chucks
<mjg59> Ah, found it
<mjg59> BenC: http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff_plain;h=821dc07095d73b757bfc9d5f162e2efb954172f8;hp=caf39e87cc1182f7dae84eefc43ca14d54c78ef9
<mjg59> Doesn't quite apply cleanly, but looks like the fixup is trivial
<mjg59> If we don't have sk98lin yet, can we have that instead?
<BenC> yeah
<BenC> odd that it needs a seperate driver
<BenC> makes me think of the whole 8139cp/8139too driver
<BenC> I mean if syskonnect can make a single driver for all of them, why not the kernel devs :)
<BenC> ok, I've got the diff, I'll add it to the repo today
<BenC> thanks for the pointer
<doko> BenC: could you have a look at http://bugzilla.ubuntu.com/show_bug.cgi?id=15092? I cannot reproduce that, neither in unstable nor breezy
<mjg59> BenC: Could you possibly grab http://www.codon.org.uk/~mjg59/tmp/swsusp.diff ?
<mjg59> Fixes bogus error checking and actually outputs some sensible information in failure cases
<BenC> doko: me either, all those devs are created on my machines
<BenC> doko: doing the test shown in the bug report works for me (all devs recreated)
<BenC> maybe it's a udev bug?
<BenC> the bug report shows 0.068, and I have 0.060 on my machine
<BenC> mjg59: got it, will add it today
<mjg59> Ta
<doko> BenC: ok, thanks
<BenC> anyone know why my initrd shows up as a ASCII cpio (reported by 'file')?
<BenC> and how do I mount the thing manually
<BenC> (ppc)
<mjg59> BenC: Uhm. Because it's an initramfs?
<mjg59> It's just uncpioed into a tmpfs
<mjg59> You don't mount it
<BenC> ah
<BenC> always used an initrd with a filesystem  put into ramdisk
<mjg59> Yeah. Now we have the future! :)
<mjg59> initramfs allows all kinds of cool stuff - you can just combine multiple cpio files, and they'll all be extracted into the filesystem
<BenC> for some reason, that makes me feel like an old fart
<BenC> "I remember when we used to have a filesystem for the initrd"
<mjg59> We've only just changed over
<BenC> cool
<jbailey> BenC: This is why I need your help on the ibook things.
<jbailey> BenC: It looks like the kernels are doing the wrong things in thoses cases, it never ever runs /init
<mjg59> Hm. Maybe I should try to get an ibook out of Mark.
<mjg59> It would make some things much easier.
<BenC> I should get an ibook for my laptop too (good excuse to get one)
<jbailey> I think it's only older ones. =(
<jbailey> mjg59: So you need another 6 laptops at your door.
<BenC> jbailey: the problem seems to be related to the xfs filesystem
<jbailey> BenC: I don't see how it could be.
<jbailey> Nothing knows the filesystem at that point.
<BenC> well, if it never gets to init then true
<BenC> I can't see any of it being directly related to it being an ibook either though
<BenC> I can't see how that could possibly affect it
<BenC> you know, when I had this similar problem on my i386 that I upgraded from debian to breezy, I had an ext2 filesystem
<jbailey> BenC: My theory was that OF was doing something weird with the initrd.
<jbailey> But I can't even prove that.
<BenC> I also don't think it is the kernel
<BenC> he reported that rebuilding his 2.6.12-3 initrd caused that kernel to fail the same way
<BenC> one thing is for sure though, the ramdisk_size is too small
<BenC> hmm, I thought mjg59 said it was using tmpfs, is that newer than this bug report?
<jbailey> BenC: No, he rebuilt it with initramfs and got it to fail.
<jbailey> No, the changeover was late in the -6 cycle from mkinitrd to mkinitramfs
<BenC> maybe I misunderstood the bug report
<jbailey> My understanding is that every instance, old and new of him using mkinitramfs fails to execute /init on the initramfs.
<jbailey> And that every instance of him using mkinitrd succeeds in doing the initrd bootup (/linuxrc)
<jbailey> What I'd like is if there were some way to have the kernel printk the equivalent of an 'ls' in a test kernel before it chains
<jbailey> Just to prove that the stuff is actually on the tmpfs.
<jbailey> tmpfs/rootfs/ramfs, whatever it is.
<jbailey> Woohoo, another vmware bug.
<jbailey> Desperately need that BusLogic fix. =(
<jbailey> And I don't understand how hotplug is picking it up now for VmWare installations.
<BenC> vmware 5 works
<BenC> vmware 4 doesn't
<BenC> you want me to port ls to the kernel? :)
<jbailey> BenC: Ah, does vmware 5 use something other than BusLogic?
<jbailey> BenC: Well, I was hoping for an iteration over the directory entries, or something.  Dunno, I always imagines there'd be a debug helper fuction in there already for that.
<BenC> yeah, it uses a fibre channel controller
<jbailey> I can't imagine I'm the first one to want to know what the kernel thinks of a filesystem.
<jbailey> BenC: Zul said he had a patch to make BusLogic hotpluggable.
<BenC> hmm, my initrd has /init, not /sbin/init or /linuxrc
<jbailey> Right.
<BenC> yeah, I think he sent it to me
<jbailey> initramfs boots with /init now.
<BenC> or it's in his repo that I will sync from today
<jbailey> Cool.
<jbailey> When you have a test i386 kernel handy, can you let me know?
<jbailey> I'll put out a call for testers to these people.
<BenC> yeah, sure
<BenC> will be late this evening before I have a build done
<jbailey> Tjat
<jbailey> That's fine.
<jbailey> I need to afk for about 30m.
<BenC> the quiet var in the kern command line for the initramfs needs to be a little more rebust
<BenC> no way to to quiet=no or noisy to counteract it temporarily
<BenC> does ybin need to be rerun if you edit /etc/yaboot.conf?
<BenC> jbailey?
<jbailey> I think so, yes.
<jbailey> BEcause it needs to copy it to a partition type that OF understands.
<jbailey> But that might just be for yaboot upgrades.
<jbailey> (Likeyaboot might just know how to read it and where to find it)
<BenC> that guy with the ibook fstype problem, is he on IRC?
<BenC> jbailey: oh, and in regards to the G5 ppc64 kernel no rebooting, I can confirm and reproduce it
<jbailey> Two of them are, yes.  Lemme dig up that
<jbailey> BenC: Oh, is that a known bug (The G5)
<jbailey> It's really annoying.
<jbailey> I assumed I had b0rked my setup somehow.
<BenC> my G5 with the colony 4 CD doesn't reboot when I tell it to
<BenC> it says "Rebooting" and drops to a shell
<jbailey> My g5 current breezy doesn't reboot.
<jbailey> Well, I get a Ctrl-D to shell or enter to continue.
<BenC> colony 4 live cd
<jbailey> Like it's fliped to single user mode.
<jbailey> Now that I know it's a real bug, I can troubleshoot it.  Do you have a bugzilla number?
<BenC> probably because I'm using live-cd, there's no password
<jbailey> The sideffect is that it also leaves the last mounted date on the volume wrong.
<BenC> just goes right to shell
<jbailey> So I have a 60gb fsck every boot.
<BenC> heh, hold a sec
<BenC> weird, someone just reported I bug I just experienced with loop device
<jbailey> This machine is about due for a pave and replace, but I don't have other drives big enough to store the data in the eantime.
<BenC> I think it's a mount bug though
<BenC> jbailey: 14898 mentions it
<BenC> and 15162 has the actual bug
<jbailey> I've confirmed 15162 and added myself to the cc: list.
<jbailey> I'll try to look at it later.
<jbailey> I really need to squish a few initramfs bugs first.
<BenC> I'm going to try to get a kernel for that ibook bug
<jbailey> BenC: Thanks.
<fabbione> MEHHH
<fabbione> guys.. how do i disable a module from being loaded?
<Lathiat> by hotplug?
<fabbione> the isp2100 driver is borked
<Lathiat> or in general?
<mjg59>  /etc/hotplug/blacklist
<fabbione> and it doesn't let me boot
<fabbione> NO
<fabbione> i need to do it at boot..
<fabbione> first install
<mjg59> Oh
<mjg59> With trouble
<fabbione> the driver is an isp1020
<fabbione> or it seems like
<Lathiat> fabbione: isp or ipw?w
<fabbione> and i only have console here to irc
<fabbione> isp
<fabbione> BenC: dude?
<fabbione> it's a scsi driver...
<mjg59> fabbione: There's no kernel way of doing it. You'd need to ask kamion.
<fabbione> i guess there is only one way for now..
<fabbione> remove the controller...
<BenC> yeah, probably the only way
<fabbione> yeah
<fabbione> too bad because it's a combo scsi + lan from a sparc64
<fabbione> nice board
<fabbione> and i only needed the lan to be hounest
<Lathiat> btw, a boot option to exclude specific modules or somethign could possibly be usefull
<BenC> debian-install/exclude-modules=isp1020,xxx,yyy
* BenC lays patent claims on that
<BenC> what would be nice is the installer to store something in nvram about which module it is about to load, and then on reboot it can say "Last time we tried to load module XXX, it failed, do you want to skip it this time?"
<fabbione> hmm i am gonna try that
<fabbione> i did swap the card already...
<fabbione> worth a test
<BenC> oh, that debian-installer thing was made up, it wont work :)
<BenC> just a suggestion for implementation
<fabbione> DIE!
* Lathiat laughs
* BenC scores 1 for BenC, fabbione 0
* fabbione files a bug on broken qlogic isp 1020 as CRITICAL!
<jbailey> fabbione: Don't kill Ben, you'll have to do kernel work again if you do...
<fabbione> jbailey: i need blood :P
<jbailey> fabbione: Meat eater.
* jbailey hides.
<fabbione> ehhe
<jbailey> Ugh, I tought 28 days were done with.
<jbailey> How is it supposed to get below zero at this rate for November?
<jbailey> do we support qemu on our kernels?
<Lathiat> jbailey: qemu doesnt need qemu support unless you want the accelerator
<jbailey> Ah, neat.
<jbailey> 'k, I'll look at that then.
<Lathiat> err
<Lathiat> the second qemu was supposed to be 'kernel'
<jbailey> It's all good. =)
<Nafallo> morning all :-)
<Nafallo> we have rt2400 and rt2500. maybe we should have rt2570 (usb rt2500) also? 
<Nafallo> hmm, seems dead. I'll come back another day :-).
#ubuntu-kernel 2006-09-11
* Starting logfile irclogs/ubuntu-kernel.log
<Mithrandir> BenC: hiya; I have a bunch of servers which seem to have problems with the md code somewhere.  They keep chucking one of the drives out of the raid array; those machines are running dapper.
<BenC> Mithrandir: did this start with the latest dapper kernel?
<Mithrandir> BenC: no, we've seen it for a while.
<BenC> Mithrandir: ah...not sure, haven't heard of that problem before now
<BenC> zul, crimsun: ping, re: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/52649
<zul> looking
<zul> shoot..ok
<zul> could you reverse that patch?
<BenC> can you find the commit for it?
<zul> sure..
<zul> http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commit;h=5aae548f78f22a7069342fecad3f9e2e8d308c55
<BenC> thanks
<zul> no probs
<zul> my bad again
<zul> or alan cox's bad..
<BenC> hehe
<Mithrandir> zul: can I whine at you about xen? :-)
<zul> sure..
<Mithrandir> have you had a chance at poking the firewall so I can mirror from you?
<zul> not yet..
<Mithrandir> and do you have packages for the stuff you managed to get working?
<zul> i uploaded them last night this morning
<zul> although amd64 didnt build last night because of the .config i used
<zul> i didnt have a chance at the firewall because i was trying to fix xen ;)
<Mithrandir> ok, then. :-)
<zul> is there somewhere i can put it other than on my home connection so where you can get it and mirror it
<Mithrandir> I don't have any systems I can just give out accounts on, unfortunately. :-/  At least, none I can think of offhand.
<zul> hmm...
<Mithrandir> I guess I could give you an account on my home system.  It won't be fast, but I can easily enough mirror it to somewhere else.
<zul> ok..
<zul> ill just create a new git tree with my latest crack and scp the tar ball over
<Mithrandir> you'll be able to push to that and I can mirror it further.
<Mithrandir> what do you want as your user name?
<zul> zul
<Mithrandir> do you have a pgp key somewhere?  (Preferably signed)
<zul> yep check launchpad
<zul> https://launchpad.net/people/zulcss
<Mithrandir> heh, you're two hops from me.
<zul> heh..
<Mithrandir> zul: ok, mail or http://pastebin.ca/166920
* fabbione feels the missing link 
<Mithrandir> fabbione: willy.
<fabbione> zul: didn't we exchange fingerprints?
<zul> we might have
<neuralis> zul, Mithrandir: i'm happy to provide a (very fast) git repo for the xen work
<neuralis> (we plan to deploy shortly on the laptop.org servers.)
<zul> that would be nice thanks neuralis what do you need from me?
<neuralis> zul: nothing, your ssh key is up, will have it ready in a second
<Mithrandir> neuralis: thanks a lot. :-)
<neuralis> zul: repo at git+ssh://zul@dev.laptop.org/git/projects/ubuntu-xen
<neuralis> zul: conf instructions for pushing at http://dev.laptop.org/wiki/ImportingYourProject (not sure how familiar you are with git, ignore if you're comfortable)
<neuralis> Mithrandir: np
<zul> neuralis: quite comfertable :)
<neuralis> zul: okay, give that a go, let me know if you have trouble (your ssh key on lp is wrapped for some reason; i unwrapped it manually)
<zul> hmm..weird
<neuralis> what's up?
<neuralis> oh, the lp wrapping
<zul> yeah
<Mithrandir> neuralis: mind giving me access to it too?
<neuralis> Mithrandir: sure, can you wait about 45 minutes? i'm about to run out very briefly
<Mithrandir> sure
<Mithrandir> neuralis: (tfheen on lp, ssh key also available on http://err.no/dotfiles/ssh/authorized_keys , unwrapped)
<neuralis> Mithrandir: eh, created it now; tfheen@dev
<Mithrandir> thanks a lot
<Mithrandir> zul: I'll just nuke your account on aine, then
<neuralis> aye
<neuralis> zul: back soon, leave a message here if your key acts up.
<zul> yep go ahead
<zul> neuralis: ill upload soon im not really suppose to be doing ubuntu stuff at work
<Mithrandir> zul: if you feel like telling when you're done pushing, that'd be lovely.
<Mithrandir> and with that I'm off to make some food
<zul> Mithrandir: probably wont be for another hourish..
<zul> This upload queue does not permit SECURITY uploads.
<zul> oops..
<zul> Mithrandir: ping
<zul> its up
* dilinger yawns
<zul> hey dilinger 
<dilinger> hiya
<dilinger> BenC: i've got one more sata_mv-related patch for you for dapper's kernel; hopefully a) it fixes all the issues i've been having, and b) i can get it in before the next kernel release
<BenC> dilinger: ok
<dilinger> BenC: here's the patch against 2.6.18-rc6: http://thread.gmane.org/gmane.linux.ide/13037/focus=13053
<dilinger> the code is different in 2.6.15; here's the patch for that: http://mouth.squishy.cc/~dilinger/sata_mv.patch
<dilinger> haven't filed a launchpad bug on it yet because i'm waiting for an ACK from jgarzik 
<dilinger> oh man.  filesystem corruption that you discover while doing a libc6 upgrade is the best!
* dilinger didn't really need any working commands, anyways.
<zul> working commands is overrated
<dilinger> BenC: eh, nm.  there's still some corruption occuring w/ 2.6.15 that's not showing up w/ 2.6.18-rc*.  i'll need to start bisecting before i know what specifically is causing it
<Mithrandir> zul: yay, great.
<zul> right im going home...later
<Philip5> is there a way to use git the way you use cvs to just fetch the latest versions of ubuntu-2.6.git without using clone to have it all?
#ubuntu-kernel 2006-09-12
<zul> Philip5: yes if you have a copy already then git pull
<Philip5> zul: well, that's what i thought but getting a copy at first can be plenty of data to download
<zul> true buts its only once
<zul> ../in theory
<Philip5> i cloned the ubuntu-dapper.git and got like 400 mb
<Philip5> is'n that the draw back with git compared to cvs?
<Philip5> where i can get a snapshot and take it from there
<zul> there isnt one
<Philip5> but it would be a good feature
<zul> it would but we dont have one right now
<Philip5> true... and that was what i thought
<Philip5> but i could have use a feature like that :)
<neuralis> Philip5: lightweight checkouts (and partial checkouts) are the most commonly requested git features; it's reasonable to expect git will grow support for them
<Philip5> it would be nice
<Philip5> i have to make a custom made kernel with ubuntu and want as many of the patches the standard use in it and therefore it would be nice to catch the tree as a snapshot
<Philip5> now i had to play sherlock holmes and search the net for all of them instead
<zul> Philip5: ah...have you tried apt-get linux-source-2.6.17?
<zul> linux-source-2.6.17 - Linux kernel source for version 2.6.17 with Ubuntu patches
<Philip5> i need even newer with the -mm patch
<Philip5> have brand new hardware that are not supported until right now
<zul> jmicron?
<Philip5> zul: how could you guess... ;)
<zul> Philip5: because i sent a patch to BenC a couple of days ago for edgy
<Philip5> zul: great
<Philip5> right now i'm building the kernel and have to make my own ubuntu livecd with it to get everthing installed
<mjg59> zul: Can you flag the bug pending if it isn't already?
<Philip5> zul: do you know if the jmicron will be backported or is it more likely with new kernel in edgy?
<Philip5> new=newer
<zul> mjg59: pretty sure i already did but ill double check
<zul> more likely in edgy
<dilinger> cool, jgarzik took the sata_mv fix
<AnAnt> anyone knows when the MMC fix will be available ?
<Philip5> have anyone here by chance tried to build the latest squashfs3.1-r2?
<Philip5> with the patch i mean
<Philip5> it breaks for me
<Philip5> don't where to ask about this otherwise
<Philip5> know..
<drew> does 'Ubuntu kernel development discussion' include asking about possible bugs in edgy?
<fabbione> hey BenC 
<BenC> hey
<fabbione> BenC: can you please pull from my edgy branch? i have the usual gfs2/gfs/dlmfs updates
<drew> I asked this before: does 'Ubuntu kernel development discussion' include asking about possible bugs in edgy?
<fabbione> drew: bugs -> launchpad
<BenC> fabbione: sure thing
<fabbione> BenC: thanks
<fabbione> BenC: jbailey is looking into glibc install issue
<fabbione> tomorrow i will spend sometime to look at lvm
<fabbione> upstart is no go on sparc
<fabbione> at least on Niagara
<fabbione> i need to check on the normal sparc too
<BenC> I need to take pictures of my latest project
<fabbione> and we should really really start some install tests for edgy
<BenC> Inserted a 20Gig driver into a Watchguard Firebox X 2500
<BenC> and installed Ubuntu Edgy on it
<BenC> even got the LCD panel working
<fabbione> ah nice
<BenC> LCD 2x20 panel w/backlight, and 4 buttons...
<fabbione> ehehe
<BenC> plus it has 6 ethernet ports
<fabbione> not bad
<fabbione> anyway gfs is rock solid
<fabbione> gfs2 still has some issues but upstream is working on our bugs
<fabbione> otherwise we are good
<BenC> ok, cool
<BenC> http://www.watchguard.com/products/x2500.asp
<fabbione> neat toy!
<BenC> used to work for them, so I have like 8 of their boxes laying around doing nothing
<BenC> setting this one up for the T1 firewall
<fabbione> is it Gigabit or just fastether?
<fabbione> feeeehh my son is crying like hell
<fabbione> bbl
<BenC> it's fast ethernet rtl8139C+
<mvirkkil> Where can I find out if the edgy kernel has the patch for DEVICE_ZD1211B (mentioned here http://reactivated.net/patches/linux-kernel/2.6.17/zd1211rw.patch) and especially my device with the id 0x1215 ?
<BenC> mvirkkil: It should have it
<mvirkkil> BenC: Ok, thanks. Guess I'll need to give edgy a shot then. (it didn't go in to 2.6.17, but it should be in 2.6.18 iirc.)
<BenC> I put it in 2.6.17
<BenC> for edgy
<BenC> or a similar patch at least
<mjg59> BenC: I've got some more suspend patches for you
<BenC> mjg59: ok
<mjg59> BenC: Any idea when the acpi stuff I sent you will be merged?
<mvirkkil> BenC: Excellent. Thankyou very much :)
<BenC> mjg59: Today I'm merging all outstanding patches from you guys and preparing another edgy uploaad
<mjg59> BenC: Rock
<mjg59> BenC: Mailed - should be a tarball of 5 patches
<BenC> ok
<mjg59> I may have a few more for you later
<zul> heh...everyone take down BenC 
<BenC> mjg59: wow, you sure know how to pack a lot of commits into a short email :)
<BenC> 195 commits
<mjg59> The ACPI one?
<mjg59> Yeah
<BenC> yeah, it was 154 alone
<mjg59> That was fun
<BenC> everything applied, one of your last pm-fixes didn't apply cleanly, but it was just a one-line offset I had to fix
<mjg59> Cool
<mjg59> I win at patches
<mjg59> BenC: Oh, hang on, I've triggered a build failure
<mjg59> Hang on, I'll clean it up
<BenC> heh, sweet...it's your fault this time :)
<mjg59> Hm
<mjg59> It might actually be fixed by the patch I've previously sent you
<BenC> well, they are all in there...I'm starting some builds so I'll find out pretty quickly
<Mithrandir> BenC: you're aware that we're frozen for knot 3 now, right?
<Mithrandir> BenC: (just so you don't end up uploading a new kernel in the middle of the freeze)
<BenC> Mithrandir: when is knot-3?
<Mithrandir> BenC: Thursday, hopefully
<BenC> mjg59: looks like the builds went ok except for t he ABI bump
<BenC> Mithrandir: ok, I'll plan an upload for Friday then
<mjg59> BenC: Yeah
<AnAnt> BenC: btw, do you  know when the MMC fix will be on the Ubuntu repos ?
<BenC> AnAnt: next upload
<AnAnt> BenC: well, I mean, when do you guys upload ?
<BenC> I upload on Friday I hope
<AnAnt> ok, thanks
<zul> oh goody...i can send you more patches then
<BenC> mjg59:
<BenC> arch/ia64/kernel/acpi.c: In function 'acpi_parse_fadt':
<BenC> arch/ia64/kernel/acpi.c:632: error: dereferencing pointer to incomplete type
<BenC> arch/ia64/kernel/acpi.c:635: error: dereferencing pointer to incomplete type
<BenC> arch/ia64/kernel/acpi.c:638: error: dereferencing pointer to incomplete type
<BenC> mjg59: should it do struct fadt_descriptor_rev2 -> fadt_descriptor_rev2_minus?
<BenC> actually, looks like it can just use the rev1 struct since it has the same members that the functions uses
<mjg59> BenC: Hm
<mjg59> Let me take a look
<mjg59> BenC: Yeah, just fadt_descriptor
<BenC> no rev?
<mjg59> Rather than rev anything
<mjg59> Right
<BenC> ok
<mjg59> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=236ee8c33277ab48671995f26dc68a4639936418
<TeePOG> good evening
<TeePOG> if I installed edubuntu with the i386 installation disc on an AMD64, how do I get the K8 kernel?
<mjg59> You probably don't want to do that
<TeePOG> how so?
<mjg59> Because the i386 distribution uses functionality not provided by the amd64 kernel
<mjg59> vm86, specifically
<TeePOG> ok...
<BenC> and not all ioctls are thunked for 32-bit userspace to a 64-bit kernel
<TeePOG> will I get any benefit from the k7 kernel? i need as much as i can get, this machine will run vmware with *doze in
<BenC> so things like usb printing may not work
<TeePOG> i see
<BenC> TePOG: there's not much else to gain, the -k7 kernel is suggested though
<TeePOG> we're using network printers anyway, so usb printing is a non-event
<TeePOG> thanks a lot BenC
* TeePOG starts downloading the amd64 ISO
<TeePOG> lol
<TeePOG> goodnight all
<BenC> mjg59: drivers/ide/ide-io.c:160: error: 'pm' undeclared (first use in this function)
<BenC> caused by your last patches
<BenC> mjg59: I think it just needs rq-> prepended to it, can you check?
<mjg59> BenC: Oops
<mjg59> BenC: Yeah
<mjg59> My error
<mjg59> Woo
<BenC> ok, thanks
<mjg59> The tifm driver works now
<zul> right im going home ttyl
<ivoks> bye
* Mithrandir commits a few fixes to the xen tree.
<BenC> mjg59: ...
<BenC> drivers/built-in.o: In function `ide_wait_not_busy':
<BenC> (.text+0x88270): undefined reference to `touch_nmi_watchdog'
<BenC> on ppc
<mjg59> Oops
<neuralis> Mithrandir: do those fix bug 59997? i haven't had a chance to look at it in detail yet
<mjg59> Can you #ifdef that with CONFIG_I386?
<mjg59> Or is it CONFIG_X86?
<mjg59> Whichever one covers amd64 and i386
<Mithrandir> neuralis: hopefully that was fixed by zul's last upload?  If not, I'll fix it, yes.
<neuralis> Mithrandir: only if it hasn't hit the archive yet; still fails with the latest packages that are there
<Mithrandir> neuralis: hmm, ok. :-/
<Mithrandir> I'll poke it
<neuralis> thanks
<mjg59> BenC: Any chance you can do 59851?
<BenC> yeah, can do
<mjg59> Ta
<mjg59> It's a regression over dapper right now
#ubuntu-kernel 2006-09-13
<mvirkkil> The zd1211rw driver is trying to load the firmware from /lib/firmware/zd1211/zd1211b_ub and failing with return code -2
<mvirkkil> Any suggestions?
<crimsun> well, it's the wrong dir for one
<mvirkkil> crimsun: yes, that's what I figured :) I'll bug BenC about it tomorrow. 
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: that console patch for that bug, it touches code that I don't even have enabled since I did the console-power patch the last time
<BenC> mjg59: should I revert my patch and add this one?
<mjg59> BenC: Console patch for which bug?
<BenC> 59851
<BenC> the one you mentioned earlier
<mjg59> Erm, hang on
<mjg59> I thought that was just ACPI/SATA integration
<mjg59> Oh
<mjg59> He's pointed at an entirely unrelated patch
<mjg59> Sorry
<BenC> should I take the patch anyway? :)
<mjg59> Nope
<mjg59> http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-5/linux-2.6-sata-ahci-suspend.patch?rev=1.1&view=markup looks like a better bet
<mjg59> It's still not the one we want, but we probably /do/ want that one :)
<BenC> does it fix that bug?
<mjg59> Probably, yeah
<mjg59> Though we also want the sata acpi stuff
<zul> BenC: when is the t1 connection coming
<BenC> zul: 11/02
<zul> cool
<BenC> can't wait to watch them run copper through the cow pastures
<zul> heh you'll have to take pictures
<BenC> mjg59: patch applied
<mjg59> BenC: Ta
<mjg59> BenC: I'm working on the sata-acpi patch
<BenC> ok
<BenC> Trying to upload by Friday, for reference
<BenC> Friday or Saturday
<mjg59> Oh argh this is awkward
<zul> BenC: ping
<BenC> zul: aye
<zul> xt_tables_info didnt come until 2.6.16 did it
<zul> stupid netfilter
<BenC> I think so, yeah
<zul> hmmm...then why am i killing myself over this stupid patch (hypothetical) for amd64
<mvirkkil> Would anyone be interested in helping me get to the bottom of the issues mentioned at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/60222 ?
<zul> Mithrandir: will take a look in a  little bit
<Mithrandir> zul: hmm?  You meant mvirkkil ?
* mvirkkil is hoping that he did
<zul> Mithrandir: yeah i did
<kbyrd> BenC: got a sec?
<BenC> yeah
<kbyrd> How do you want the vmware-server sources?
<kbyrd> Just the sources? or the debian directory too?
<mvirkkil> BenC: This is probably of interest to you https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/60222 ?
<kbyrd> *click*
<BenC> just sources
<kbyrd> ok, but remember the resulting player-kernel and server-kernel modules need to conflict with each other.
<BenC> yes, that's no problem
<kbyrd> I'll have a URL for you in  a  bit.
<fabbione> BenC: did you remember to pull/merge from me?
<fabbione> BenC: or do you want me to merge from you and re-push?
<BenC> fabbione: Got it
<fabbione> BenC: thanks
<BenC> mvirkkil: will fix it now
<mvirkkil> BenC: Any hints what might be causing the trouble I'm having (mentioned in the comment)? 
<mvirkkil> I'll gladly debug this as to the best of my abilities, but I just don't have a clue what to do next,
<mvirkkil> I've tested the dongle in windows using the same AP and the same settings (afaict), and it works there. 
<BenC> MODULE_AUTHOR("Ulrich Kunitz");
<BenC> MODULE_AUTHOR("Daniel Drake");
<BenC> contact one of them
<mvirkkil> BenC: ok.
<mvirkkil> BenC: When can I expect the fixed version (re the firmware issue) to be downloadable? 
<BenC> I'm uploading on Friday, so sometime after that (day or two)
<pitti> hi
<pitti> BenC: not sure whether you are aware of it, zul's last breezy kernel has a strange FTBFS
<pitti> BenC: do you have some time today to take a look at it?
<pitti> BenC: (I bounced you the log, same failure on all arches)
<pitti> BenC, zul: I know I'm getting on your nerves, but I'd like to see this update pushed out soon :/
<zul> pitti: the patch that we included for the ebtables only one of them applies
<BenC> I'll take a quick peek
<zul> see this patch http://70.29.61.171/ubuntu/kernel/ebtables-2.dpatch
<BenC> pitti: where did you send the email?
<BenC> s/where/when/
<BenC> I don't seem to have it
<zul> this is the one causing the problem the second chunks are causing the problems because the struct doesnt exist
<pitti> BenC: some minutes ago
<infinity> Is this the part where I (again) beg people to test build before uploading? :)
<zul> infinity: probably
<BenC> infinity: That doesn't seem to help me when buildd scripts break my broken stuff :)
<infinity> BenC: Heh.
<kbyrd> infinity, benc: email sent with the URL to the vmware-server-kernel sources, thanks.
<BenC> kbyrd: thanks, since next kernel is an ABI bump, it's an opportune time to put it in
<BenC> I'll probably include it with the kernel upload on Friday
<kbyrd> Nice. If I can get out from underneath my current schedule pressure on a different product, I'll actually get a vmware-server package together, and maybe fix a lot of the mess with vmware-player.
<kbyrd> One nice thing about the next vmware-player package, we move the EULA out of the package and into the UI.
<BenC> kbyrd: One thing I noticed about vmware-player is that it is a little broken on amd64
<BenC> I needed to create some symlinks for gdk stuff to the path it expected so it would work
<BenC> but I've been using it since creating those vmware-player-kernel and updated vmware-player packages
<kbyrd> If you get a chance, email me the details.
<kbyrd> I'm running 64-bit UI but it's from an internal branch.
<zul> bbl...need to go to the doctor with the wifey
<kbyrd> Before that, I ran the release version and it ran fine with the ia32-libs installed.
<kbyrd> Wait. I remember now. Something recently happend with a c++ lib, right?
<kbyrd> That is, I had to move a library on my amd64 bit system to force player to use the right library.
<BenC> infinity: FYI, I am moving all firmware to lrm next time around
<BenC> I think
<BenC> It means moving nic-firmware udeb to lrm as well
<Mithrandir> that'll cause a lot of systems which work today and which haven't lrm installed to break.
* kylem blinks at BenC.
<infinity> BenC: Did you discuss this with mdz?  That's a pretty drastic change.
<BenC> we discussed it a bit in germany
<infinity> BenC: Also, lrm already has a nic-restricted-firmware udeb.
<BenC> I need to finalize it with him and you
<infinity> So, you'll just be beefing it up, I suspect.
<BenC> Mith's argument is my main concern
<BenC> so it might just be edgy+1
<BenC> but the "Ubuntu GNU/Linux" dream would require this change
<Keybuk> couldn't we have a linux-firmware package instead?
<Keybuk> that at least makes it obvious
<BenC> yeah, would trim down the install base for people that don't need all of lrm
<BenC> build it right out of lrm, and have linux-restricted-modules depend on it
* JanC wonders whether there exists not one single open source firmware then?
<Keybuk> JanC: most firmware doesn't even have source code
<Keybuk> the binary blob _is_ the preferred form of editing for it
<Keybuk> half the time, it had some source, which was compiled, then hand edited for size, and then binary patched subsequently
<Keybuk> etc.
<Keybuk> I know one firm that do the first version in C, then strip all the calling conventions just leaving the asm
<Keybuk> and then edit that from there on
<Keybuk> etc.
<Keybuk> silly really
<JanC> well, even then the assembler source could be "open source"
<JanC> even if no one understands anymore what it does  ;-)
<Keybuk> assembler source is the binary
<Keybuk> it's a 1:1 match
<Keybuk> consider a firmware blob to be a .png file
<Keybuk> you open it, modify it, and save it again
<infinity> In the cases where that's truly the case, it's fine, really.
<JanC> except that assembler source _can_ be documented
<Keybuk> infinity: I would be very surprised if there were cases where that wasn't the case
<infinity> But we ship some firmware without free licenses, and just turn a blind eye, currently.
* infinity glances at his ipw firmware.
<Keybuk> JanC: true, but hardware companies don't
<JanC> well, that's exactly what I was wondering: why don't they release documented assembler source?
<JanC> if it's GPL'ed, they could even benefit from it
<JanC> people could fix bugs that make even their Windows drivers work better  ;-)
<Keybuk> JanC: because they've never written any documented assembler source?
<JanC> I guess it's not that difficult to insert the original C-comments into the assembler to start with, but they probably really don't care...
<BenC> zul: ping
<mdz> BenC: I don't recall the firmware discussion; what's the rationale?
<BenC> mdz: It was more of a passing conversation than a discussion :)
<mdz> BenC: also, there seems to be a delay in your email; your last couple of replies have been old, and I've received no reply to my most recent emails
<BenC> there was talk about Ubuntu GNU/Linux, and the topic of the firmware in the kernel came up
<BenC> mdz: It's either my smtp server, or direcway's...I'll see if I can rule out mine
<BenC> hmm...smtp.direcway.com is rejecting most of my outgoing mail
<BenC> "Contains FortiGuard URL's"
<BenC> stupid
<BenC> interesting
<BenC> I'm being used to bounce emails somehow
<JanC> FortiGuard is some anti-virus &anti-spam filter ?
<BenC> it's direcway's filter catching emails coming from my smtp server that are being relayed for some outside hosts
<JanC> if you don't use FortiGuard, their filter is broken  :-P
<JanC> well, my ISP's filter is broken too, but fortunately I can disable it, and i also have a (secured) relay on a dedicated server that I rent with some friends...
<BenC> it's not broken, it's absolutely right
<BenC> I have email being relayed off my smtp server
<BenC> and I don't know why because I have relay hosts set to my internal network only...I think it may be something with my TLS config changes to exim causing it
<zul> BenC: pong
<lupine_85> hi, quick question about the edgy rt2x00 legacy drivers...
<lupine_85> ...is it really necessary to continue to use the July 2005 codebase for them? e.g. rt2400 is "Ralink RT2400 802.11b WLAN driver 1.2.2 - CVS 2005/07/11"
<lupine_85> the later code - even the newest beta - is much more stable, especially for the rt2570 driver
<zul> BenC: can you revert this patch as well http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commit;h=5aae548f78f22a7069342fecad3f9e2e8d308c55
<zul> is the via quirks crap
<BenC> zul: it should revert from pulling from dapper
<BenC> check and make sure it is
<BenC> zul: it should revert when I pull from dapper
<BenC> zul: check to make sure
<zul> ok
<zul> its a bit too late for hrtimers isnt it?
* lupine_85 wonders if he can ask a question about some code in the edgy kernel here
<mjg59> Lure: Sure
<Lure> lupine_85: ^^^ ;-)
<lupine_85> hehe
<lupine_85> It's about the rt2x00-legacy drivers
<lupine_85> according to modinfo, the code is a year old... I was wondering if there was a reason for that?
<lupine_85> e.g. Ralink RT2400 802.11b WLAN driver 1.2.2 - CVS 2005/07/11
<BenC> because they are legacy and not updated/worked on
<lupine_85> they're still worke don
<lupine_85> there have been two new betas since then :)
<lupine_85> http://rt2x00.serialmonkey.com/
<BenC> well, file a bug and I'll see if I can update them :)
<lupine_85> ah, a bug...
<lupine_85> ...I mentioned it in a specification
<BenC> against linux-source-2.6.17
<lupine_85> ok, will do :)
<lupine_85> ok, bug #60282
<lupine_85> thanks for the pointer
<zul> ttyl
<mjg59> BenC: Just pushed you a patch for fixing some fan-related stuff
<Philip5> anyone here know about how the livecd use the casper scripts or know someone who do?
<Philip5> or a ubuntu livecd channel?
#ubuntu-kernel 2006-09-14
<neuralis> zul: still getting an error unpacking xen-utils-3.0 on x86_64. 
<zul> neuralis: what error?
<neuralis> zul: it can't find module blkbk which causes xend to fail starting
<zul> hmm...ok ill take a look
<zul> can you do modprobe blkbk
<neuralis> nope, don't have that module
<zul> ok ill take a look soon
<neuralis> no rush, thanks
<BenC> mjg59: got it, thanks
<_sah_> sorry if this is the wrong place to ask, but nobody else seems to be able to answer. Are there plans to add MPT Fusion SAS RAID support to the ubuntu-server kernel? If so, when? Thanks.
<infinity> _sah_: modinfo mptsas
<infinity> _sah_: What's wrong with that one?
<_sah_> the kernel that ships with the ubuntu-server install CD does not support RAID on these devices. AFAIK the driver was updated somewhere between 2.6.15 and 2.6.16 and ubuntu ships with 2.6.15
<infinity> Oh, you're talking dapper.  Check.  I did the above on an edgy machine. :)
<infinity> Not sure how updating the fusion stack in dapper would/could destabilise OTHER fusion drivers, for the sake of new hardware support.
<infinity> But that's not my call.
<_sah_> yes, dapper
<_sah_> who is the one to talk to about this? As dapper is being used as base for the LTS version, it would be nice to use that one.
<infinity> BenC would be the man to discuss this with.  The Fusion stack is generally pretty stable, but doing large driver updates on a stable kernel is always risky.
<infinity> Oh, he's only been idle 50 mins..
<infinity> BenC: Ping.  Still around?
<_sah_> Is there an email address I could use or a particular good time to contact BenC on this channel?
<zul> you might want to start by opening a bug in launchpad
<_sah_> it has already been filed as Bug #37452
<_sah_> apparently no solution could be found back then. we are in exactly the same situation as described in the bugreport.
<_sah_> I have no idea of how git, etc. works but if someone would give me some pointers on how to create a server install cd with a custom kernel I would be more than happy to give it a try.
<_sah_> Have to go now. Thanks for your help so far.
<zul> morning
<fabbione> zul: didn't you go to sleep today?
<zul> fabbione: yep i did..
<fabbione> so what are you doing up at 3am?
<zul> for the meeting
<zul> besides katie is talking in her asleep again
<fabbione> dude.. the only reason why you wake up at 3am is to either get laid or get a beer or watch porn while your wife talks in her sleep
<zul> heh..or i cant sleep
<fabbione> that's solvable with beer
<zul> im beerless though
<rodarvus> are you wineless too?
<zul> i dont like wine
<fabbione> he is also dickless^Wbrainless
<fabbione> :P
* fabbione hides
<zul> hah hah
<zul> and xen is still stuck on 2.6.16
<Mithrandir> you did some work on getting it up to .18, didn't you?
<zul> yeah 
<fabbione> xen sucks.. it will never get merged upstream
<zul> heh i was playing with esx today
<Mithrandir> fabbione: there appears to be a small bit of movement around it upstream.
<fabbione> Mithrandir: yeah but most core kernel guys don't like it
<zul> bbl
<zul> BenC: i guess you dont have a 2.6.18 git lying around for edgy+1 do you?
<makx> edgy is not based on 2.6.18 dooh
<BenC> zul: I think edgy+1 will be 2.6.19
<BenC> but to answer your question, no
<zul> ok..
<fabbione> BenC: fixed glibc have been uploaded.. just waiting knot-3 to be out for acceptance
<fabbione> it also reduces the size of the initramfs of about 2.5MB on sparc
<BenC> col
<BenC> err, cool
<fabbione> and that should make Niagara boot again
<fabbione> (testint it right now)
<fabbione> Loading initial ramdisk (6290368 bytes at 0x1FF800000 phys, 0x40C00000 virt)...
<fabbione> old PHYS address
<fabbione> we will still need to understand why it corrupts
<fabbione> but this will give us a bit of time to do it
<fabbione> [    5.145560]  checking if image is initramfs... it is                               
<fabbione> score
<BenC> I already know why, remember :)
<fabbione> right, but we still need:
<fabbione> a) understand why .15 can boot using the same PHYS
<fabbione> b) get a fix ;)
<fabbione> oh crap we also need to get infinity to kick silo back
<fabbione> now the headers should be available for it to build
<fabbione> but that's not really important
<fabbione> .10 we have is basically .12
<fabbione> and the rebuild didn't even boot
<BenC> mjg59: ping
<BenC> mjg59: Can you look at https://launchpad.net/bugs/53381, follow the linux bug, and tell me if we should be defaulting ec_intr to 0?
<mjg59> I don't think so
<mjg59> It breaks all sorts of other things
<mjg59> Get him to retry with the new acpi code after the next upload
<zul> BenC: ping another question for you
<BenC> zul: shoot
<BenC> mjg59: ok, thanks
<zul> im going to be doing a xen-restricted modules which consist of the nvidia kernel module, and i was going to call the .ko file nvidia-xen does that sound reasonable?
<Mithrandir> why not just let it still be named nvidia.ko?
<BenC> zul: I suspect you don't need to do that, since the modules will be in a separate module directory anyway
<zul> ah true...i didnt think of that
<BenC> zul: why not just build it all out of the same lrm?
<BenC> we can just add new flavours
<Mithrandir> BenC: because lrm is restricted, xen is universe
<BenC> add depends for the xen header packages
<BenC> Mithrandir: so?
<Mithrandir> BenC: restricted can't build dep on universe, afaik?
<BenC> we can't have lrm build-dep on universe?
<Mithrandir> ttbomk, no
<BenC> that sucks :/
<Mithrandir> not without putting it in multiverse
<BenC> would xen make sense in multiverse?
<Mithrandir> multiverse can build-dep on universe.
<zul> i thought multiverse was for non-gpl stuff
<Mithrandir> just not the other way around.
<Mithrandir> zul: non-free, not non-gpl
<zul> ah
<Mithrandir> zul: else, we'd have to punt X and other stuff to multiverse, which would be a shame. :-)
<zul> meh..
<zul> you know what i meant :)
<Mithrandir> yeah, I do
<fabbione> BenC: up to room up for UDS?
<BenC> fabbione: hell yeah
<fabbione> done :)
<fabbione> BenC: i will invite also David since it's close to where he lives
<BenC> cool
<zul> sparc is not being built on hoary is it?
<Mithrandir> correct.
<zul> ok..
<Mithrandir> zul: you're working on xrm now?
<zul> Mithrandir: im at work right now, but will fit some time into it tonight
<Mithrandir> zul: do you want my preliminary stuff or is that useless for you?
<zul> Mithrandir: that would be good it would give me a starting point
<Mithrandir> I'mm make them work with the current xen from git then
<zul> cool
<Mithrandir> s/mm/ll
<Mithrandir> and then put them somewhere
<zul> Mithrandir: ill probably add a domU kernel as well this weekend
<Mithrandir> zul: coolie.  I don't know if I'll have time for it, but maybe I'll get around to do the update-initramfs magic and such
<zul> that would be super as well, but isnt that handle by kernel-package?
<Mithrandir> apparently not
<zul> hmm..
<zul> right im heading home...later..
<Philip5> what is the abi-file in /boot used for? and second... when i make a kernel from vanilla kernel source with make-kpkg i don't get a abi-file
<Philip5> how do i make one and do i need one?
#ubuntu-kernel 2006-09-15
<fabbione> morning guys
* dilinger waves
* Starting logfile irclogs/ubuntu-kernel.log
<BenC> hey fabbione
<fabbione> hey BenC 
<fabbione> BenC: i am trying to debug why my ia64 doesn't boot... hopefully i will be able to tell you something when you wake up
<fabbione> i am also seeing some random CPU soft lookups on Niagara
<fabbione> i am sure David and I fixed that in .15
<dilinger> BenC: at some point i'll probably get more sata_mv hardware and try to make it work in dapper again.. but for now, i had to send the hardware back
<fabbione> but i am wondering if we did push the wrong button somewhere
<BenC> fabbione: ok
<fabbione> at least upstart works on ia64
<fabbione> modulo serial console
<fabbione> BenC: booting mkinley instead of itanium works fine... but this is kind of strange because for dapper it was the other way around
<fabbione> BenC: did you pull from me by anychange?
<fabbione> i can't see the commits in the shortlogs
<BenC> pretty sure I did
<fabbione> or did you only fetch the objects?
<fabbione> if not, don't sweat it.. i will have another update relatively soon
<fabbione> oh there it is
<fabbione> yes
<fabbione> i found it
<fabbione> it was in all that ACPI noise
<fabbione> oh btw.. did you ever get around to play with that webcam?
<fabbione> [    4.694425]  BUG: soft lockup detected on CPU#11!
<fabbione> [    4.694435]  Call Trace:
<fabbione> [    4.694442]   [000000000043417c]  smp_percpu_timer_interrupt+0xbc/0x160
<fabbione> humps
<fabbione> do you see the same on your e3k?
<doko_> are lrm supposed to work with the recent kernel?
<fabbione> doko_: edgy?
<doko_> fabbione: yes
<fabbione> doko_: nvidia works here just fine
<doko_> fglrx doesn't, and the ath0 driver isn't loaded on my notebook
<fabbione> can't say.. i don't use any of these
<mjg59> BenC: You seem to have reverted the threaded ACPI stuff, but not added the replacement code I sent?
<mjg59> BenC: There was 0003-Fix-fan-control-on-HP-hardware
<mjg59> Also you haven't added the fan fix code I sent on Wednesday, but I guess you just haven't got to that yet :)
<zul> Mithrandir: http://virt-manager.et.redhat.com/screenshots.html
<Mithrandir> zul: shiny.
<Mithrandir> zul: you going to package it?
<zul> yep, ill put it on my list for this weekend
<imbrandon> hey zul can i poke you for what is possibly a stupid question
<zul> sure
<imbrandon> heh i just noticed ( by installing a knot3 canidate ) that my lappy is cpu scalling, normaly this is good BUT i dident think ppc's scaled
<imbrandon> its a 800mhz ppc ibook
<zul> heh i only do intel :)
<imbrandon> ;)
<zul> but someone else might know
<imbrandon> i was just wondering becosue afaik ppc dident scale the cpus but i coudl be totaly off base
<imbrandon> could*
<imbrandon> and ppc people alive awake ?
<zul> imbrandon: the last ppc i had was in grade 7 and it didnt scale ;)
<imbrandon> hahhaha
<imbrandon> a full 33mhz or none ;)
<mjg59> imbrandon: Mobile PPCs scale
<imbrandon> mjg59, ok that would explain it as its a lappy ;)
<imbrandon> thanks
<imbrandon> just wanted to be sure guidance power mgr wasent botched
<imbrandon> ok later guys, thanks 
<mjg59> BenC: Got the patches I sent?
<BenC> mjg59: yeah
<mjg59> BenC: Cool
<mjg59> zul: have you pushed the jmicron driver?
<mjg59> It doesn't appear to be in git
<zul> mjg59: i sent the driver though the ml
<mjg59> zul: You might want to chase that up
<zul> https://lists.ubuntu.com/archives/kernel-team/2006-September/001050.html
<zul> BenC: ping ^^^
<BenC> zul: got it, just trying to get a dapper kernel out
<zul> BenC: Cool
<mjg59> Ok, just making sure it doesn't get lost :)
<zul> heh...any people can stop emailing me
#ubuntu-kernel 2006-09-16
<ph8> hi guys
<ph8> I'm hoping to get some more info on bug 57502 - I'm really hoping it'll make it into a build soon as my system's pretty much useless until it does
<ph8> Do you know if there's any chance of that happening?
<eyequeue> i really miss the SysRq feature, is there any way to enable it easily?
<ph8> I've pm'ed BenC as I *think* he's the maintainer, forgive the intrusion if it bothers you :)
<mjg59> eyequeue: We ship with sysrq
<eyequeue> mjg59, cool!   i guess that means my box keeps locking up hard then, since the kb is unresponsive
<eyequeue> mjg59, but at least now i know :)
<eyequeue> thanks
<mjg59> ph8: It ought to be in the next upload
<ph8> awesome! the next daily upload? or the next upload of the kernel (which would be a daily upload in about a week?)
<mjg59> The next upload of the kernel
<mjg59> Which should be in the next few days
<mjg59> I can't give you precise timing, I'm afraid
<ph8> ok - is there no way for me to implement it ahead of time and is there any chance this first upload will fail or is it a pretty straightforward patch?
<mjg59> It's pretty straightforward
<mjg59> The patch is written and queued
<ph8> cool. Cheers - I guess it's not possible for me to compile the kernel.org kernel for my install disk and then update to the ubuntu kernel at a later date?
<ph8> wanted this server working sooner rather than later 
<ph8> oh well, cheers mjg59 
<BenC> zul_: ping
<ernstp> Can I use usplash on amd64 in edgy?
<zul_> BenC: i took the night off last night but pong
<zul> hey BenC 
<ph8> ah ben
<ph8> and zul!
<ph8> just the people
<ph8> I only have one quick question
<ph8> This kernel patch for Jmicron support (which i can't do *anything* without (as far as i'm aware)) - do you happen to know when it will make it into one of the edgy dailies?
<ph8> I managed to get around the cd drive not detected issue with a usb-disk boot but it can't detect either of my sata IIs, so i'm assuming that's also a symptom of the problem
<BenC> ph8: by the end of the weekend it will be in dapper and edgy
<ph8> fantastic!
<ph8> so if i grab a daily on monday i'll be able to finally get something installed? :)
<ph8> or do you think it'll be in sunday's?
<ph8> there might be hope for fitting this server by the 20th yet :p
<zul> ph8: is it amd64 or x86?
<ph8> amd64
<ph8> well. intel core 2 duo so EMT64
<zul> thats too bad i could have built you one if it was x86
<ph8> argh!
<ph8> well i was going to run x86, but i'm told it can't recognise > 3gb of ram and with the intel core2duo i'd be limiting the chip's performance with x86
<ph8> does that sound right?
<ph8> i'm worried i'll run into lots of 64 bit compatibility issues or something when i try to install apache
<BenC> ph8: You will be able to get it out of the archive by Monday
<BenC> dapper-proposed-updates and edgy
<zul> whee...we are builidng xen0 and xenU kernels now
<ph8> ok, thanks Ben - hopefully i'll get it installed monday night
<ph8> and zul for the fix :)
<zul> no probs
<ph8> and now for a newbie question (i'm aware i have asked far more than the one i promised, feel free to ignore me)
<ph8> I want to compile grsec into my ubuntu kernel, for the obvious reasons, do many people do this? if so there only appears to be versions of grsec available for the latest kernel.org kernel which means that half the patch gets rejected on the ubuntu one
<ph8> is there some sort of package for it..?
<zul> BenC: ping according to the changelog kernel-package v10.056 has support for 2.6.18
<crimsun> nice work on xen* in edgy, zul 
<zul> thanks..
<zul> there is a couple of more things i have to do though :)
<desrt> any word on why git is messed up?
#ubuntu-kernel 2006-09-17
<BenC> desrt: what's messed up with it?
<crimsun> (thanks for the merges, BenC)
<BenC> crimsun: If you didn't notice, the stuff like you and zul have been sending me for dapper are now going into dapper-proposed-updates before they ever see dapper proper
<crimsun> BenC: excellent (yep, noted the delay)
<BenC> crimsun: So if you want people to test the stuff, they have to add dapper-proposed-updates to sources.list, and manually install linux-image-2.6.15-50-<flavour> and linux-restricted-modules-2.6.15-50-<flavour>
<BenC> the dapper-proposed-updates ABI will _always_ be -50
<BenC> there will be no proper tracking of ABI in proposed-updates
<crimsun> ah, great. Thanks for that info.
<BenC> but LRM will always be rebuilt after a new kernel, so it wont have a severe affect
<BenC> I'm still debating on whether to have a proposed-updates linux-meta
<BenC> also, kernel for proposed-updates will always contain latest stuff from -security too, so ppl don't need to worry about losing security updates
<BenC> I need to make a wiki page for this stuff
<crimsun> A mail to -announce would help, too (unless I missed a post?)
<BenC> yeah, still need to do that
<BenC> well, I need to ask Matt about that kind of exposure
<desrt> BenC; i just learnt that you can't do a git clone from http://www.kernel.org/
<desrt> that's all :)
<BenC> ah
<BenC> I don't run the script that lets it work over http
<desrt> BenC; there's a regression on my laptop between 2.6.17-6-686 6.18 and -7-generic 7.20
<desrt> i want to find it
<BenC> acpi, network?
<desrt> resume from sleep
<desrt> it locks on resume now
<BenC> it's almost surely fixed in current git
<BenC> and will be uploaded tonight
<desrt> i don't know enough about git to even get a diff between the two versions -- nevermind bisect
<desrt> oh. awesome.
* desrt tries out a daily to find out for sure
<desrt> no sense in leaving a bug sitting open that's fixed already :p
* desrt gets 6283ed
<desrt> not fixed in 09-14 daily build, fwiw
<BenC> that one didn't contain the new acpi code
<desrt> cool.
<BenC> infinity: ping
<zul_> argh...it hates me
<zul_> dpkg-gencontrol: error: Illegal package name `xen-headers-2.6.16-11.2-generic-xenU'
<BenC> it's the multiple -'s
* ajmitch would say it's the U
<BenC> yay, dapper-proposed kernel is ACCEPTED, pending an archive maintainer approval of course
<fmasi> helo i was trying to aply Andrew Morton's -mm Kernel patch for 2.6.17-mm6 in kernel linux-2.6.17.13 but i got the folowing message: patching file usr/Makefile
<fmasi> Reversed (or previously applied) patch detected!  Assume -R? [n] 
<fmasi> what sould i do
<desrt> fmasi; don't try to apply -mm patches to ubuntu kernels
<desrt> fmasi; -mm is a delta vs. the vanilla kernel.  ubuntu has a lot of changes vs. vanilla a lot of them which are probably from -mm already and others which will conflict with those in -mm
<fmasi> desrt, i rying whith vanilla kernel
<desrt> why did you come here?
<desrt> in any case -- make sure your -mm patch is the same version as your kernel
<fmasi> becouse i use ubuntu and i like to know if you recomend to use some of the ubuntu patch agest vanilla kernel
<desrt> it's recommended to run the ubuntu kernel ;)
<fmasi> couse ubuntu daper dont have the 2.6-17 taht i nead
<fmasi> i realy nead 17 or up
<desrt> ah.  i see.
<desrt> edgy has .17
<desrt> and i'm guessing if you're building your own kernel you don't really need stability
<desrt> so maybe you want to give edgy a spin
<desrt> knot3 just came out
<fmasi> not realy but its alweys good
<fmasi> i like to stay whith daper but runing 17
<fmasi> i try edgy on vmware
<desrt> that's gonna get funky :)
<fmasi> i building an experimental serevr and the sata2 controler is only suported bu .17 and up
<fmasi> just for home end use but still
<fmasi> like to test and use my brend new sata2
<desrt> oh.  if that's the problem then figure out the patch that fixed the sata2 controller and apply it to linux-source-2.6.15
<fmasi> how can i figure that out its my first time trying to patch a kernel
<desrt> oh.
<fmasi> do you have eny totorial link i can read
<desrt> no.  not really.
<desrt> is it a new driver?
<desrt> or support added to an old one?
<fmasi> i reading http://www.ubuntuforums.org/showthread.php?t=217657&highlight=2.6.17 and some other tutorials
<fmasi> its new i ges
<fmasi> its a Promyse fasttrack TX4200
<fmasi> i run on some docs that say its on vanilla 2.6-17 and up
<desrt> have you tried the ubuntu dapper kernel yet?  ben always pulls in all sorts of newer drivers from later kernel versions....
<fmasi> so i giv it a try and it whorks
<fmasi> it dont work
<desrt> maybe you'll get lucky
<desrt> maybe not :)
<fmasi> it dident whork
<fmasi> sniff
<fmasi> i have a 2.6-17 runing and it whorks
<fmasi> i dont know if i should just do a modprob for the daper one maby
<fmasi> how do i know whith modul to load
<desrt> dapper keeps a list of PCI IDs supported by each driver and autoloads drivers for you if it sees the PCI card
<fmasi> so it dont whork
<fmasi> sniff
<fmasi> will have to kip whith vanillha 2.6-17
<fmasi> do you recoment using it nature or do i put some souce on it (patches i mean)
<fmasi> choclate or caramel maby lol
<fmasi> becouse i read sme nice stuf on mm patches (and some bad too ) so i dont know i i sould use a patch or not
<desrt> ok
<desrt> i can't find a driver with that name in the kernel
<desrt> -mm is the same deal with any prerelease stuff
<desrt> it's a heck of a lot more likely to crash
<desrt> but it might have features/bugfixes that you need
<fmasi> i ges if i dont know of eny thing i nead more i dont nead it 
<fmasi> what about reiser4 is is safe to use it ? is it bether to try it whith mm patches ?
<desrt> you're really far off topic for this channel
<desrt> i have no idea what the answers to these questions are
<desrt> but i suspect they're along the lines of "might be fun but make sure you have good backups"
<fmasi> ok thx for the help
<fmasi> i try just the vanillha kernel then
<fmasi> tune it up a but but kep whith vanillha
<rmjb> hello
<rmjb> are there any issues with the asus.c file in the kernel?
<desrt> ... ?!?
<desrt> like how it doesn't exist?
<rmjb> well, i'm following this guide on dapper: https://wiki.ubuntu.com/KernelCustomBuild
<rmjb> and when I start the kernel compile it errors early on at an asus.c file, sorry I can't say where, I already rm -rf'ed the thing and I'm re-git-ing it
<rmjb> if there's nothing known broken, is that guide the correct one to follow to upgrade a dapper kernel?
<johanbr> rmjb: I've never tried that method. I do "fakeroot make-kpkg --initrd kernel_image" in the kernel source dir and that works well, giving me a .deb at the end.
<rmjb> do you take your config from the boot directory or use the ones delivered in debian/configs/<ARCH>?
<johanbr> rmjb: I usually make my own.
<johanbr> That way, I don't build a ton of modules I'll never have any use for. If you don't mind the extra build time, I'd imagine either of your suggestions would work fine, though.
<rmjb> okay, thanks
<rmjb> I'm not building a kernel for efficency, I was recommened to try that by the gphoto guys to see if my mtp player would work better
<rmjb> I'll just use the config from /boot
<TheMuso> c
<zul> d
<ph8> do daily builds stop at the weekends? there doesn't seem to have been one released since knot3?
<desrt> ph8; new upload to edgy soon
<desrt> (was supposed to be last night, actually)
<desrt> in any case, not long of a wait
<ph8> cheers desrt, does that mean a new daily will be released or will it only be available through apt?
<desrt> i don't know.
<[lt] BCC32> Is anybody here who can answer some questions about Linux Hotplug Subsystem ?
<ph8> why not ask and see? ;)
<davmor2> Hi I'm having difficulties with 64 bit edgy.  From knot3 live cd and from up-to-date install I get a soft lockup on cpu0 on shutdown or restart.
#ubuntu-kernel 2007-09-10
<__dmr__> can anybody tell me how to append a custom identifying string to a kernel built with the debian/rules script from git?
<zul> edit the top level makefile
<__dmr__> set EXTRAVERSION?
<zul> uh huh
<__dmr__> thanks. will add to wiki.
<abogani> BenC: Are you around ?
<derjohn> hi, as I still miss linux-image-2.6.22-.*-xen in the amd64 repo of gutsy, I want to build the kernel myself. Usually I use make-kpkg for the job, but i read severa times about the "new building infrastructure" - do we now build kernel debs differntly (i.e. dpkg-buildpackage or such) ? ( zul ? )
<jmg> derjohn: did you get your question answered?
<xhaker> derjohn, https://wiki.ubuntu.com/KernelCustomBuild
<derjohn> well, I also asked here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/133986 . It looks like the package has been fixen, I can see the -xen kernel in i386 repo, but not in amd64 ....
<derjohn> xhaker, thx for that link, that was exactly what I was looking for. But I still hope, the package will appear soon, so I dont have to complile myself ..
<xhaker> in the topic
<xhaker> Latest news: -rt and -xen kernels re-added
<xhaker> it seems they are there
<xhaker> yes
<xhaker> oh.. amd64
<xhaker> BenC, amd64-xen ?
<zul_> next upload
<xhaker> derjohn, ^^
<xhaker> thanks zul_ 
<derjohn> zul, whooohooo! c00l !
<derjohn> someone might close https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/133986 then ...
<derjohn> zul, ah, it's you ;) 
<clever> my ubuntu kernel(2.6.25-29) keeps having kernel panics randomly
<clever> and lvm is also locking up durring pvmove(2.6.15-28)
<Chorus> clever - what does the kernel panic say?
<clever> Chorus: checking
<clever> i have it logged somewhere
<clever> paste bining...
<clever> damnit
<clever> winblows doesnt want to help me:P
<clever> doing everything it can to keep linux broken
<clever> chorus: http://pastebin.ca/690270
<clever> Chorus: thats just 1 of several panic msgs i have logged
<clever> the lvm lockups produce no logs at all
<slavik> question about the gutsy kernel, is it confirmed to support the w83267ghf super I/O chip for lm-sensors? (lm-sensors site says the code is in .21, but I would like to make sure that gutsy has it.)
<zul> if it made it into linus kernel tree for .21 then it most likely made it into gutsy for .22
<slavik> is it a bad idea to use the current gutsy kernel in feisty?
<clever> ive tried using the 6.06 kernel in 7.04
<clever> to see where a driver module bug came up
<clever> but it wouldnt boot
<clever> and the bug exists in all kernels in 7.04
<bullgard4> When has been the 2.6.20 kernel, and when has been released the 2.6.22 kernel?
<BenC> 2.6.22 was released about 2 months ago
<BenC> 2.6.20 about 6 months prior
<derjohn> BenC, EHLO! I have a question about ipw3945. I suxx to use that for notebooks that suspend and resume. I saw iwl3945 already in 2.6.22 which does not need the regulatory daemon. But iwl.* is quite buggy in 2.6.22, there were lots of changes in 2.6.23. Is there any change that ubuntu backports it or includes the driver from intel's website (which should be very close to what 2.6.23 has ...)
<BenC> derjohn: we're looking into the newer iwlwifi driver, but it requires some tricky things because of dependency on newer mac80211 stack
<derjohn> BenC, fine that there is already progress, so I dont have to file a buglet. Maybe you should take 2.6.23 and rename the versionstring to 2.6.22-ubusuperbackport and save lots of work? *g* </Just Kidding> thanks for you effort ....
<derjohn> BenC, btw, about notebooks: Is there a plan to bring queueprotect out of the box? I think several notebooks and hdds support thinks similar to hdaps. It would be sad if users like me would have to recompile only for that feature. how to you guys solve that on your notebooks?
<bdmurray> BenC: So some 2.6.22 bugs for Wednesday?
<BenC> bdmurray: yeah
<zul> the netboot installer is neat
<paran> BenC: what is problems with pulling in a new mac80211 subsystem together with iwlwifi? lots of other modules that use it and so might break, or something else?
<BenC> paran: exactly that
<BenC> the in-kernel mac80211 is used by a few other drivers, and too big of a risk to just up it to a completely new API
<paran> BenC: as I suspected. but it sounds like you have some plan, the "tricky things" you mentioned? having a new iwlwifi-driver would be good as basicly all new laptops seem to have intel 4965agn wifi :)
<BenC> paran: were aware of this, but current 4965 works and we don't want to risk degrading that, or other things in order to update it :)
<BenC> especially just a little more than a month before release
<ivoks> please don't :) ipw3945 untill yesterday didn't work :)
<paran> BenC: off course, I am only curious :)
<BenC> we wont be switching 3945 support to iwl
<BenC> gutsy will support 3945 through ipw3945
<paran> by the way I just installed 2.6.22-11 and is again without debug packages. I have put a patch on LP here if somebody could take a look: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/92553
<lamont> BenC/amitk: you saw my pull request for hppa abi files?
<BenC> lamont: yeah, my fault, I had taken hppa out of my getabi script
<lamont> ah, ok
<lamont> http://buildd.mmjgroup.com/gutsy-stage0/ is a good base for it if the kernel isn't in ports.u.c...  and I'm working on getting that done this week, to make everyone's life easier
<lamont> ( I uploaded -11.32hppa1 to gutsy-stage0, so as long as the files are there in -11.33, I don't need a special upload just for that...)
* lamont lunches
<bdmurray> My laptop has stopped suspending and hibernating is 'pmi action' a good alternate way to test?
<IntuitiveNipple> bdmurray: Usually I do it from a virtual terminal....
<IntuitiveNipple> ... edit /etc/acpi/sleep.sh and add "set +x" to the top of the file (to enable reporting of script commands)
<IntuitiveNipple> then from the terminal I do "sudo /etc/acpi/sleep.sh force | tee /var/log/sleep.log
<IntuitiveNipple> It helps to capture the point where things get mixed up
<IntuitiveNipple> The recent updates have fixed the problems I was seeing with suspend, and the snd-hda-intel issues too
* lamont wonders if sound is working again in -11
<IntuitiveNipple> lamont: Which bit?
<slavi1> is there a problem with 2.6.20-16 kernel in feisty and usb keyboards?
<derjohn> BenC, did I get it right that the iwl won't make it into gutsy? (but lateron?)
<BenC> derjohn: no, iwl is already in gutsy, but it's not new enough to support 11n, just a/b/g for 4965 chips
#ubuntu-kernel 2007-09-11
<bullgard5> IntuitiveNipple: ping
<kousotu> hey BenC_
<kousotu> hey BenC
<kousotu> lol
<kousotu> playing msical nicks are we?
<Mithrandir> BenC: (or somebody else): do we have any idea what the kernel version we'll be wanting for 8.04 is?
<BenC> Mithrandir: most likely 2.6.24
<Mithrandir> ok
<Mithrandir> thanks
<verwilst> hellow
<verwilst> anyone have an ETA when the amd64 version of the xen kernel will be available?
<verwilst> i know it's been patched to include amd64 in git
<amitk> verwilst: most probably there will be a new kernel upload by the end of this week or beginning of next
<verwilst> sweet
<zul> gday
<superm1> in the latest gutsy kernel there has been an abundance of unionfs errors, i looked for a bug but didn't see one, so i just wanted to double check if the unionfs maintainer was aware, or if I should still file
<superm1> it shows up in the mythbuntu dailies (and also the ubuntu dailies)
<zul> i think there is a bug already open but dont quote me on that
<superm1> the only one i was finding was https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/138866
<superm1> but thats not exactly the same 
<evand> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/138915
<superm1> i'll add a dmesg and syslog to that bug as well
<evand> whoops, that was intended for #ubuntu-installer.  Sorry about that.
<kousotu> to what channel woul ndiswrapper questions go?
<zul> #ubuntu
<kousotu> figures...
<kousotu> the guy I'm trying to avoid is there
<kousotu> but it's a simple enoughquestion, I'm just unsre of the answer
<ScottK> If you were running Gutsy, you could as in #ubuntu+1
<ScottK> as/ask
<kousotu>  I have, and he's there too...
<kousotu> always spiitin the same crap at me..
<kousotu> wel, and there's thisI justnoticed: 10:21]  <IdleOne> kousotu: you should realy look into buying hardware that is supports/supported by linux
<kousotu> I'm on a laptop, the onnly external anything I'm using in my mouse
<kousotu> lol
<kousotu> [10:26]  <ikonia> kousotu that kernel module is not happy
<kousotu> (for my reader)
<kousotu> is that a kernel issue?
<kousotu> ScottK: I am running gutsy, fiesty doesn't like my hardware, it's too new
<kousotu> lol
<ScottK> OK.  Then #ubuntu+1 is the channel you want.
<kousotu> gutsy is running beatifully, save a few minor prblems
<kousotu> I pasted from +1
<kousotu> [10:52]  <ikonia> kousotu thats one of the problems with linux in general, you've got to make sure you have good hardware support or you'll have problems at a very low level
<kousotu> [10:52]  <ikonia> its jusan unfortuanate truth at the moment
<kousotu> ScottK: maybe you cn answer my question?
<ScottK> No, sorry.
<kousotu> damn..
<zul> BenC: having problems? :)
<BenC> zul: yeah, mid-week brain farts :)
<zul> hehe
#ubuntu-kernel 2007-09-12
<heno> happy kernel bug day!
<heno> I'm going through some NEW bugs here: https://wiki.ubuntu.com/UbuntuBugDay/20070912
<BenC> heno: hey
<BenC> heno: I'll be joining you soon, just getting up
<heno> good morning BenC
<pj_og> Hi! I installed the ubuntu-server, but the base system doesn't boot. I have no idea why. I can boot memtest86+, but trying one of the kernels results only in a "reset". What now? The installation itself went absolutely smooth no error or so. But then rebooting into the base system doesn't work. I was told on #ubuntu-installer to ask the question here since the generic and server kernels...
<pj_og> ...might be different. what now?
<pj_og> It's on a HP Vectra with 64 MB RAM.
<pj_og> Why would the generic (installer) kernel run on it but the server kernel not?
<Nafallo> pj_og: what cpu-family is that? AFAIK the server is aimed at i686.
<pj_og> i think it's a pentium 2 or so
<pj_og> so that might be the reason, right?
<Nafallo> not sure. P2 might be i586, not sure.
<Nafallo> BenC: wake up and tell us? :-)
<pj_og> could I try an install with the normal ubuntu install-CD and use the generic kernel?
<pj_og> would that be reasonable?
<zul> BenC: id appreciate it if we got the xen amd64 fix before the next upload or even better cherrypick from me tree ;)
<BenC> zul: yeah, I'll pull it in
<BenC> zul: you did a build/boot test, right?
<zul> yep
<zul> not the amd64 stuff though since I dont have one but it should work
<Mithrandir> zul: you can test in qemu, at least.
<zul> i could
<BenC> zul: well it needs a build test at least
<BenC> as Mithrandir will tell you, the buildd's are not a testing infrastructure :)
<zul> BenC: i can do another build test tonight probably
<zul> actually i can probably do one right now
<zul> ill let you know the results of the build test in a couple of hours 
<BenC> zul: also, can you triage bug #135041
<zul> is that the xen-create-image one?
<BenC> yeah
<zul> sure no problems
<BenC> zul: thanks
<abogani> BenC: Hi Ben.
<abogani> BenC: Are there particular reason why fglrx and nvidia are not enabled in l-r-m for rt ?
<BenC> abogani: only because I haven't added the fix yet...they will be
<BenC> it's the GPL_ONLY symbols getting used, is the reason
<abogani> BenC: Which symbols ?
<BenC> don't recall which ones
<abogani> The not-yet-applied fix contain a workaround for rcu* GPL_ONLY symbols. Are there other ?
<abogani> Today i compiled l-r-m and insmod-ed the nvidia-legacy driver without any gpl-symbol related warnings. 
<osmosis> if I copied  /lib/modules/2.6.20-16-server/kernel/drivers/hwmon/w83793.ko   into my  /lib/modules/2.6.19  directory...do you think it would work ?
<maks_> no
<zul> *grumble* *grumble*
<bullgard4> What kind of files are stored in /usr/share/doc/linux-doc-2.6.20/Documentation/hwmon/ ? What is meant by 'hwmon'? No doubt that this is an abbreviatiation for hardware monitor.
<zul> BenC: ping
<zul> linux-image-2.6.22-11-xen_2.6.22-11.33_amd64.deb linux-headers-2.6.22-11-xen_2.6.22-11.33_amd64.deb
<BenC> zul: sweet
<zul> im just about to push a couple of fixes to my tree and ill request another sync
<zul> er pull
<bdmurray> zul: I'm curious about the hid simple driver and bug 84965.
<zul> bdmurray: the keyboard one? yeah its requires an api that hasnt made it upstream yet
<zul> and it looks like it hasnt been accepted by the usb people yet either
<zul> bdmurray: i talked to BenC about it a couple of weeks ago and it was rejected
<bdmurray> That is patch that other distros carry though?
<zul> im not sure
<zul> users have probably patched their own kernel
<bdmurray> There was a comment about "I've resorted to using other distros for a few months now."
<bdmurray> Maybe its gentoo. ;)
<zul> bdmurray: probaly ;)
<zul> bdmurray: its probably not fedora because they dont carry the patch either
#ubuntu-kernel 2007-09-13
<tza_> is there documentation regarding 2.6.20-16+ kernel upgrades and nvidia 8-series card difficulties?
<defendguin> is there anyway to tell the fan on the processor to kick it up a few notches?
<defendguin> i'm using gutsy and every since the upgrade to  2.6.22-11  i've noticed the fan doesn't come on as often as necessary   my cpy is at 67 deg C and the fan isn't on at all
<defendguin> normally it should be blowing really hard right now
<defendguin> now 69 deg
<defendguin> 70
<defendguin> the fan isn't even spinning up
<defendguin> 72 
<defendguin> 74
<bullgard4> Why is /sys/class/hwmon empty?
<xhaker> I need to talk to an acpi wiz
<xhaker> mjg59, can I try to show you something?
<xhaker> I think i've fixed an acpi bug, but would like to confirm that the solution is acceptable
<xhaker> anyone?
<bullgard4> Wie kriege ich heraus, welcher Treiber bei mir fr die Temperaturmessung zustndig ist? 'lsmod | grep temp' gibt nichts aus. 
<xhaker> Bug #116185
<xhaker> hmm
<xhaker> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116185
<maks_> bullgard4: english channel also for dev ask on #ubuntu
<bullgard4> maks_: I have put here a question in English. Why did you not answer it?
<Krystof> Hi.  I am interested in working to get r818x support (noted as missing in bug #129407), but I'm not sure how best to help.
<xhaker> Krystof, try to find patches for that feature
<thom> bullgard4: this is not a support channel. it's for development only
<Krystof> what, other than the pages mentioned in that bug report?
<amitk> bullgard4: do you have a HW sensor on your motherboard?
<mjg59> xhaker: Sure
<xhaker> mjg59, i've commented on the kernel tracker
<xhaker> mjg59, http://bugzilla.kernel.org/show_bug.cgi?id=8757
<xhaker> mjg59, and attached a patch
<xhaker> please read that, and then ask me whatever you need
<xhaker> mjg59, what do you think. I seem to have fixed. I just don't know if i did in the correct place
<bullgard4> amitk: I do not understand you well: Yes I have, otherwise I could not tell you that at present the temperatur of thermal zone 1 is 46 C and of thermal zone 2 is 43 C.
<amitk> bullgard4: anything in /sys/bus/i2c/devices?
<amitk> bullgard4: do you _know_ what kind of HW monitor you have on your board?
<mjg59> bullgard4: Because you either haven't loaded a driver for your hardware, or there isn't a driver for your hardware
<mjg59> We don't expose the ACPI information in there yet
<amitk> mjg59: are there plans to duplicate ACPI information into hwmon?
<mjg59> Yes
<mjg59> Everything in /proc/acpi is gradually being moved to sysfs
<bullgard4> mjg59: Thank you very much for explaining.
<xhaker> mjg59, did you have time to peek at that acpi bug?
<mjg59> xhaker: I have, but it's too complicated for me to really understand right now
<mjg59> I'm also not convinced that the patch is correct
<xhaker> mjg59, i've set the bug in ubuntu to high, hope you be alert if something arises on the kernel tracker.. they're probably gonna test that patch soon enough
<mjg59> RIght, I can see that that patch would avoid the problem, but I don't think it actually fixes it
<mjg59> Or is that how the code looks in 2.6.23?
<xhaker> mjg59, i haven't checked 2.6.23, i've went another root and it led me that place.. 
<mjg59> xhaker: Right, but I don't know why unconditionally returning AE_OK there would be the right thing to do
<xhaker> mjg59, think about it.. if we're setting the _BST method serialized to avoid future errors it makes sense not to break things
<xhaker> mjg59, yes, i understand.. i'm sure they'll take a look at it upstream
<xhaker> mjg59, they probably will come up with something that does exactly the same in another level
<mjg59> xhaker: It would be more helpful to find out which bit of code in 2.6.23 fixes it
<xhaker> it's not easy for me to do something like that.. i only have the ubuntu-gutsy tree here
<xhaker> mjg59, can you suggested an easy way to compare
<xhaker> with 2.6.23
<mjg59> xhaker: Use git log to work out which commits touch that area, apply each of them in turn
<xhaker> mjg59, i've found a patch that produces a fix for that problem
<xhaker> mjg59, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c0d127b56937c3e72c2b1819161d2f6718eee877
<xhaker> mjg59, i'm not sure if that's 2.6.23 though
<mjg59> xhaker: Does applying that to our kernel fix things for you?
<xhaker> i'm testing just now.. and it does
<xhaker> i've applied with patch -p1, i'm not too found on git
<xhaker> and it rejected 1 hunk, but i applied it manually. maybe git has some mechanism to apply it cleanly
<xhaker> now running it.
<xhaker> mjg59, i'm kinda astonished at my ability to find a cure 2 times without error
<xhaker> mjg59, i thought i would hit and miss more
<xhaker> i mean.. miss most of the times
<zul> hey fabbione 
<fabbione> hi zul
<zul> BenC: ping im seeing a couple of bugs about ncq breakage can we add like an optional kernel parameter that disables ncq
<derjohn> zul, what about the -xen kernel on amd64 ? Upload ?
<zul> derjohn: not in my hands right now my tree has to be cherry-picked first
<derjohn> zul, mon cheri ;) Well, who may I bug about that ? 
<zul> derjohn: ive been bugging already ;)
<derjohn> whooohooo! fine ;)
<BenC> it'll happen for tomorrow's upload
<derjohn> BenC, whoooo! Ubuntu has Xen Support from tomorrow on? cool !
<BenC> we have xen support now :)
<BenC> just not 64-bit
<derjohn> Well, I head about it, but seldom use machines < 4GB :) 
<zul> we always had xen support at one point another ;)
<derjohn> BTW: on i386 the xen kernel doesnt still boot due to a pae vs. non-pae mismatch.
<derjohn> I use 2.6.22-11 something. 
<zul> are you using xen-3.1 or something else?
<derjohn> there was a bug that was resolved, but that didnt fix the problem.
<derjohn> zul, I dist-upgrade twice a day to get gusty running as i like ...
<derjohn> hypervisor 3.1 and sine some days linux-xen
<zul> lets take this somewhere else
<derjohn> k
<derjohn> I'll make screenshot (digicam) and file a lauchpad-bug ?
<zul> sure
<evand> why was /win 22
<evand> whoops
<bdmurray> BenC: I've seen a couple of bug reports where people are interested in getting a 2.6.23 patch backported to 2.6.22 is there a special way to identify those bugs?
<BenC> bdmurray: some how marking them as a "patch available" would be helpful
<bdmurray> BenC: Okay, one that I am looking at has the upsteam commit information is that sufficient too?
<BenC> yeah, the commit SHA means it's just a git-cherry-pick command for us
<bdmurray> so a cherry-pick would be easier for you than someone creating a patch for 2.6.22 from 2.6.23?
<bdmurray> BenC: If so then using cherry-pick as a tag might work well
<BenC> bdmurray: yeah, that sounds good
<BenC> bdmurray: and yes, it is much easier, mainly because it retains all history, and it magically gets merged when we move on to 2.6.2[34]  for gutsy+1
<newz2000> just today I started having a problem with 2.6.22-11 that's been fixed for a while. I reported it before for 2.6.20. Should I file a new bug, since it's a new kernel, or should I add comments to the old bug? (problem is that the sound is incredibly quiet, even at full volume)
<newz2000> old bug is marked "fix released"
<bdmurray> newz2000: open a new task on the old bug for 2.6.22
<IntuitiveNipple> Probably best to attach to the previous bug, against Ubuntu linux-source-2.6.22
<IntuitiveNipple> Do we have a known-issue with LiveCD and unionfs BUG/Oops? is it being worked on?
<mjg59> It's known
<IntuitiveNipple> The bug #138915 report?
<bdmurray> newz2000: if you need specific help opening the task let me know
<newz2000> bdmurray: I've never opened a task, I'm looking, but I don't see how to do that
<IntuitiveNipple> I was wondering if unionfs needs digging into
<bdmurray> I personally just change the url
<newz2000> I'm using bugs.edge.launchpad.net
<bdmurray> so if it it says 2.6.20 change it to 2.6.22 and press enter
<bdmurray> Then it'll tell you it doesn't need fixing there and there is a button to say it also needs fixing in blah
<newz2000> ok, will do
<IntuitiveNipple> newz2000: "Also affects > Distribution/package" then "Ubuntu" then "linux-source-2.6.22"
<mjg59> BenC: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/125855 - I thought you were going to pull that patch some tiem back?
<BenC> mjg59: ah, will get it
<newz2000> what's needed for soundcard bugs? lspci -vv, uname -a, anything else?
<mjg59> BenC: Thanks
<BenC> mjg59: we're doing git work today, pulling, patches, etc...if you see anything you want in, feel free to do a tree and ping me for a pull
<mjg59> Ok
<mjg59> I sent a pull request to the list - have you grabbed that?
<bdmurray> newz2000: actually lspci -vvnn is preferred now and DebuggingSoundProblems at w.u.c has the stuff
<amitk> mjg59: i will get that
<newz2000> bdmurray: thanks
<mjg59> BenC: Also, ata_ignore_hpa seems to be defaulting to 0 again
<mjg59> That's a regression from feisty
<BenC> mjg59: there was supposed to be a patch to module-init-tools to default that in /etc/modprobe.d/ somewhere
<BenC> to avoid changing the code
<mjg59> That sounds rather more fragile
<mjg59> Why not just change the code?
<mjg59> Anyway, doesn't seem to be present in the latest version
<Keybuk> BenC: I thought we agreed that changing defaults of module options was better in the code
<Keybuk> that's what we always did in the past
<Keybuk> (since a package-shipped conffile causes more pain to change or remove than simply allowing users to add a file to change the in-code default)
<BenC> Keybuk: I much prefer to show our changes from default upstream behavior using methods that were meant for doing that :)
<mjg59> Default upstream behaviour here is broken. We should just fix the bug.
<Keybuk> BenC: patches?
<Keybuk> branches?
<Keybuk> :-)
<BenC> I agree in this case upstream behavior is broken, so we could just change the in-kernel default
<BenC> but I think using modprobe.d files better document cases where we stray from upstream's defaults
<Keybuk> disagree
<Keybuk> we should never use modprobe.d files to override a kernel default to a different default of our own
<Keybuk> that's why we have our own kernel source tree
<DexterF> hi
<DexterF> where can I get the patches for the ubuntu 7.04 kernel alone, not the patched kernel src
<zul> you can look at the git tree but you cant get the patches alone
<DexterF> -.-
<DexterF> ok, next: can I install a vanilla kernel or does ubuntu need certain patches at all cost?
<zul> yes you can isntall a vanilla kernel we add patches to better support some hardware but these questions are more suited for #ubuntu or you can check the wiki
<DexterF> the thing is: the 7.04 kernel totally screws my USB subsystem. I'm having all kind of issues with whatever I plug in. wifi stick on a hub - no go. usb card reader only reads cards when it feels like (works a charm on three other OS/distros)
<DexterF> well, the #ubuntu people sent me right here
<bdmurray> BenC: Did I mention bug 137734 yesterday?
<BenC> bdmurray: can you get ubugtu in here?
<Mithrandir> just ask Seveas?
<Mithrandir> or I can do it
<bdmurray> BenC: I'll see what I can do.  It seems to be a regression in the last feisty update
<Mithrandir> bug 12345
<Seveas> @config channel plugins.bugtracker.bugsnarfer True
<ubotu> OK
<Mithrandir> bug 1234
<ubotu> Bug 1234 on http://launchpad.net/bugs/1234 is private
<Mithrandir> bug 12345
<ubotu> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]  https://launchpad.net/bugs/12345
<Mithrandir> \o/
<bdmurray> bug 137734
<ubotu> Launchpad bug 137734 in linux-source-2.6.20 "Alsa support for Ensoniq 1371 breaks when updating to kernel revision 16-generic" [High,Triaged]  https://launchpad.net/bugs/137734
<Mithrandir> Seveas: cheers
<Seveas> np
<BenC> bdmurray: sounds to me like he has a locally compiled module that broke with the ABI bump...not our problem
<BenC> bdmurray: he needs to recompile the module under the new kernel headers
<bdmurray> What ways can triagers determine that modules are locally compiled?
<BenC> Mithrandir, Seveas: thanks
<BenC> bdmurray: the tip for me is the dmesg, where it says "disagrees about version of symbol FOO"
<BenC> bdmurray: that means that the module is not compiled against the running kernel, and that just isn't possible with a module that came with the kernel
<bdmurray> BenC: Yeah, that seems kind of obvious now.  Generally speaking though from dmesg we have no way of knowing if somebody compiled a module on their own if it does work though right?
<BenC> bdmurray: not at the moment, but we've been tossing around the idea of signed modules, and tainting for non-ubuntu provided modules
<BenC> which will show up
<bdmurray> BenC: Alright thanks.  How could one confirm that it was a locally compiled module? Would modinfo do it?
<bdmurray> In regards to the Feisty soudn bug
<BenC> bdmurray: modinfo may show a path that you can tell isn't installed by our packages...also srcversion in modinfo can be compared to a known good source
<bdmurray> Great, thanks.  My lunch is getting cold. bbiab
<DexterF> 1371 fine here on 16-generic
<BenC> DexterF: thanks for testing that
<DexterF> BenC: np, coincidence, got such a card in my video box. disabled it for anotherr reason tho, onboard sound and the card got confused sometimes. one time onboard was 0 and the card was 1, next boot just the other way round.
<BenC> DexterF: there's a way to force that in /etc/modprobe.d/ with some mod param
<BenC> like id=0 for one module and id=1 for the other
<DexterF> uh huh, but tell Joe User to do that stunt ;)
<BenC> point :)
<DexterF> umm. since I'm here... I got a lot of USB troubles that I don't have when running the live DVD. how is the live kernel different?
<DexterF> is it possible live doesn't have suspend support? I suspect USB_SUSPEND to be the culprit
<Mithrandir> BenC: when do you expect the first 2.6.23 upload to happen? (If you have an date)
<BenC> Mithrandir: very soon after gutsy+1 opens
<Mithrandir> ok
<zul> BenC: if I find the drivers for bug 139449 could we get it in for gutsy?
<ubotu> Launchpad bug 139449 in ubuntu "Lenovo 3000 N200 fingerprint scanner support." [Undecided,New]  https://launchpad.net/bugs/139449
<BenC> zul: it's not a driver
<BenC> zul: fingerprint scanners are supported with bioapi, a userspace library
<zul> ah ok
<zul> gotcha
<BenC> we would need the library, plus pam_bioapi module to make use of it
<zul> http://home.gna.org/aes2501/index_en.html 
<BenC> zul: ah, so I guess some devices require a driver :)
<BenC> ones like mine just require the bioapi, and it communicates through usb device files
<BenC> hiddev I think is what it uses
<zul> yeah so ill try to get a patch tonight hopefully
<BenC> doesn't make much sense
<mjg59> zul: The aes2501 does nothing useful at the moment, does it?
<BenC> there's nothing in our system that uses it
<mjg59> It's purely a scanner. We need code that can actually compare fingerprints
<mjg59> Then that needs to be integrated into v4l
<zul> mjg59: i dont know i havent looked at the code yet
<zul> mjg59: it looks kind of icky.. http://svn.gna.org/viewcvs/aes2501/trunk/aes2501.c?rev=15&view=auto
<zul> right im going home for the day later
<DexterF> guys where do you store your .config? installed a source package, no .config in there, neither in the tarball it gave me
<JanC> DexterF: did you look in /boot ?  ;)
<DexterF> duh
<mdomsch> BenC: I put a patch in https://bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/120049
<ubotu> Launchpad bug 120049 in linux-source-2.6.22 "header_postinst_hook should use /etc/kernel/header_postinst.d instead" [Medium,Confirmed]  
<mdomsch> rtg and I discussed earlier this week when he was here
<verwilst> hellow
<verwilst> i just git-clone'd zul/ubuntu-gutsy.git
<verwilst> how do i build the xen kernel again plz? :)
<BenC> don't use that
<BenC> oh, wait, maybe that's the one that has the right kind of patch
<BenC> verwilst: fakeroot debian/rules custom-binary-xen
<verwilst>  /usr/bin/fakeroot: 152: debian/rules: not found
<verwilst> hm
<verwilst> it exists though
<verwilst> nm :p
<verwilst> misleading error
<verwilst> building ;)
<verwilst> next kernel release is for the next couple of days, right?
#ubuntu-kernel 2007-09-14
<amitk> zul: Do you want me to pull both commits since 0a7ecab0094bf5b59586eb8e2a2071c1740eba9a?
<arooni__> zomg so many updates today for gutsy..... what changeD?
* BenC nickserv identify Marcme2
<zul> oooh..
<zul> you might want to change that
<BenC> oops
<amitk> :-D
<zul> need more coffee BenC?
<BenC> wonder where the extra 'e' after /m came from
<BenC> glad I only use that password here :)
<zul> hehe
<evand> Can someone take a look at bug 139453?  mjg59 suspects it's a kernel issue, rather than usplash.
<ubotu> Launchpad bug 139453 in usplash "colors are left on the screen after blanking with usplash enabled" [High,Triaged]  https://launchpad.net/bugs/139453
* #ubuntu-kernel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<manchicken> Is power-management (e.g. battery levels and monitoring) a kernel issue or a user-land issue?
<johanbr> Depends on exactly what the problem is.
<manchicken> Problem is that both under KDE and GNOME I get the power management programs telling me that I'm switching onto or off of AC power incorrectly.
<manchicken> Also, much of the time on battery power the program is either reporting no power on the battery incorrectly.
<manchicken> Also, my machine doesn't seem to want to come back from suspend to RAM, so that's another problem.
<manchicken> I'm guessing that since I'm running Gutsy that System76 isn't going to be all that interested in helping, so I'm trying to find someone who might be able to sort the problem out.  I'm guessing that the power-management problems may be in HAL or maybe dbus (not sure how the power-management programs fetch their data), but I'm pretty sure that the suspension issue is ACPI/kernel related.
<manchicken> allee: What's going on?
<allee> manchicken: hey! dadchecken. 
<manchicken> Howdy :)
<manchicken> brb, gotta call the fire dept
<allee> manchicken: oh :)
<JanC> manchicken: I guess you can ask/inform the system76 guys, as I guess they _will_ be interested to have working equipment to sell, even after the gutsy release  :)
<manchicken> Yeah
<bdmurray> manchicken: so many questions. ;) You could look at /proc/acpi/battery/BAT0/[state|info]  to see what the kernel says about your battery
<manchicken> True.  I'll get into more of that once I'm done dealing with this real-life fire.
<manchicken> brb.
<johanbr> manchicken: Try looking at the files in the /proc/acpi directory. If the information there is incorrect, it's a kernel issue.
<manchicken> So that sucked.  Anyway, I'll take a look at /proc/acpi
<manchicken> I am getting some weirdness.
<manchicken> Sometimes it says charged but has "unknown" for present rate or remaining capacity.
<manchicken> Now it says I'm charging, but the cord is most certainly disconnected.
<manchicken> So that sounds like a kernel issue then?
<manchicken> The temperature seems a bit off, too.  It's switching back and forth between 5 C and 48 C
<JanC> 5 & 48 C you mean  ;)
<JanC> but that sounds quite wrong indeed
<JanC> I have seen some weird things underfeisty a couple of times, but couldn't reproduce it
<manchicken> Yea
<manchicken> I'm just putting what the file had in it :)
<manchicken> The power management and suspension stuff is really impacting me negatively though.
<manchicken> Right now it's telling me that it's going to take 27 hours to charge my battery, which I'm pretty sure is wrong.
<manchicken> I'm guessing System76 doesn't have any IRC channels though.
<bdmurray> manchicken: you'll want to submit a bug report regarding the kern then
<bdmurray> kernel even
<manchicken> Okie dokie.
<bdmurray> and attach a tarball of /proc/acpi
<bdmurray> in addition to the the kernel teams minimum bug requirements
<manchicken> Where might I find those?
<manchicken> (the minimum requirements that is)
<bdmurray> http://wiki.ubuntu.com/KernelTeamBugPolicies or something close to that
<manchicken> Much thanks.
<manchicken> I'll try to either post to an existing report or post a new one.
<bdmurray> No problem
<manchicken> This is interesting.
<manchicken> In syslog I get very unusual keycode error messages reported whenever I unplug or plug in the AC adapter.
<bdmurray> I imagine your BIOS is up to date
<manchicken> bdmurray: I'm unaware of how to change or check such a thing.  I'm guessing System76 would give me such an update over their repository.
<manchicken> If my situation only somewhat resembles that of another bug, should I just add my addition to that bug report, or should I post a new bug report and cite that it is similar to another?
<bdmurray> manchicken: Your bug sounds very hard specific and so the best idea is to submit a separate bug report
<bdmurray> and mention that it is similar
<bdmurray> s/hard/hardware/
<manchicken> Righto.
<manchicken> I'm also emailing System76 support.
<manchicken> Bug #139701 reported.
<ubotu> Launchpad bug 139701 in linux-source-2.6.22 "Under Gutsy on System76 Darter, battery state information is often incorrect." [Undecided,New]  https://launchpad.net/bugs/139701
<bdmurray> manchicken: that bug report looks great - thanks
<manchicken> Not a problem.  I hope it helps someone fix a problem :)
#ubuntu-kernel 2007-09-15
<bullgard4> What is meant by 'volume SSN' in ACPI 3.0a specification's Figure 15-5 'OS Initialization'?
<magnetron> hello. i noticed that the latest version of aircrack-ng will make it into gutsy. however, the off-the-shelf madwifi-ng cannot make use of the new features of the aircrack-ng suite, unless it's patched. The aircrack-ng provides this patch at http://www.aircrack-ng.org/doku.php#driver_patches. Is this patch applied in Ubuntu?
<kraut> moin
<DexterF> hi
<DexterF> ran into an NFS problem here, the "16 groups limit" namely. is the 2.6.22 src in gutsy patched against this?
<mjg59> BenC: The MSI-disabling patches from fesity are missing from gutsy
<mjg59> BenC: There's been a large number of patches from feisty that simply never made it to gutsy, and I've asked for a list of them several times. This is the third or fourth regression I've tripped over as a result. Could you please actually generate that list?
<bullgard4> How is 'Intel Architecture Personal Computer' defined, particularly what is the difference to 'IBM-PC'?
<mjg59> It's not
<magnetron> hello. i noticed that the latest version of aircrack-ng will make it into gutsy. however, the off-the-shelf madwifi-ng cannot make use of the new features of the aircrack-ng suite, unless the driver is patched. The aircrack-ng provides this patch at http://www.aircrack-ng.org/doku.php#driver_patches. Is this patch applied in Ubuntu?
(verwilst/#ubuntu-kernel) ah, and they get synced back to the main tree manually now and then?
(amitk/#ubuntu-kernel) verwilst: in general they are short-lived changes that get into ubuntu 
(amitk/#ubuntu-kernel) verwilst: yes
(verwilst/#ubuntu-kernel) https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132726
(ubotu/#ubuntu-kernel) Launchpad bug 132726 in linux-source-2.6.22 "linux-xen for x86_64" [Medium,Confirmed]  
(verwilst/#ubuntu-kernel) in this bug zac bowling says that amd64 isn't patched at all
(amitk/#ubuntu-kernel) verwilst: xen support for amd64 has been added to ubuntu this week AFAIK. It should be available next week
<verwilst> yeah, i've seen commits 35hours ago :)
<verwilst> that's why i was confused :)
<verwilst> so next week it's kernel time :)
<verwilst> can't wait
#ubuntu-kernel 2007-09-16
<kraut> moin
#ubuntu-kernel 2008-09-08
<Hovefirse> Hiya folks. I'm trying to apply a patch to my dvb-drivers, and just want to make sure that IÂ´m on the right track. I'm running 8.04 in command line mode, uname -r gives me "2.6.24-19-generic". I've fetched the source to /usr/src with the commands "sudo apt-get build-dep linux-image-$(uname -r)" and "sudo apt-get source linux-image-$(uname -r)", which gives me the directory "drwxr-sr-x 22...
<Hovefirse> ...root src       4096 2008-09-08 22:06 linux-2.6.24" with lotsa stuff in it. I'll do the patches, right, and compile the whole shebang with a make-command. Will that be it, or is there anything else I should consider?
<smb_tp> Hovefirse, Have you already looked at https://help.ubuntu.com/community/Kernel/Compile ?
<Hovefirse> smb_tp: yep, read it through, but since this is my first time I wanted to have some Live Aid along the road!
<smb_tp> Hovefirse, The best way to start the compile is to call "fakeroot debian/rules binary-generic" (if you want a generic kernel. You better not use the make commands directly (especially NOT "make mrproper")
<Hovefirse> smb_tp: OK. So, will the fakeroot...-command take care of the compiling process?
<smb_tp> Hovefirse, fakeroot helps for the packaging (where you need some files with root privileges). The compile is controlled by debian/rules which is a makefile
<Hovefirse> smb_tp: Hmm...OK. It's all a bit new to me, but hopefully it'll clear in time. My situation is simple: I have a driver (dvb) that I want to patch - do I really have to recompile all and everything, or is there anyway of just remaking this particular driver?
<smb_tp> Hovefirse, You will get a *.deb package in the directory above the kernel directory
<mkrufky> Hovefirse: im curious which driver you want to patch
<Hovefirse> mkrufky: The patch is for the following file: --- linux/drivers/media/dvb/ttpci/av7110_ca.c   2007-05-19 13:44:15.000000000 +0200
<smb_tp> Hovefirse, Not if that driver is inside the kernel. You always need the complete symvers rebuild. Which doesn't get done if compiling only parts.
<mkrufky> what feature are you trying to enable by the patch, Hovefirse ?
<mkrufky> it's in the kernel, smb_tp
<mkrufky> he'll have to rebuild the entire kernel if thats what he wants to do
<Hovefirse> mkrufky: It's needed to enable the functionality of a conax-card reader. vdruses it
<mkrufky> it makes SOOOOO much more sense to just use the development tree on linuxtv.org
<mkrufky> ...and it will work with your ubuntu kernel... the only problem is that it will break cx88-alsa and saa7134-alsa, and maybe a webcam driver or two (or three)
<Hovefirse> mkrufky: Hey, I'm ready to buy that ;)  Mind telling me more?
<mkrufky> but if all you care about it dvb stuff....
<mkrufky> Hovefirse: see here:  http://linuxtv.org/repo
<smb_tp> mkrufky, Most likely since the dvb stuff is back in the kernel and not in lum anymore. :)
<mkrufky> when was dvb-core and all its drivers in lum ??
<mkrufky> never that im aware of
<smb_tp> mkrufky, not the core, but we had the cx88 and saa7143 there because of the alsa parts. Hmm, probably they are not dvb drivers. I admit I lack the fine difference (its somehow video)... ;-)
<mkrufky> as per my recommendatiom, yes, saa7134-alsa and cx88-alsa were in LUM separately, because ubuntu used a new alsa subsystem
<mkrufky> that doesnt affect av7110, smb_tp
<Hovefirse> mkrufky: Hmm...does that page do what I aim to do? My vdr-system works. I want to watch pay-channels (I have a paid card and a cardreader), but I have understood that the dvb-drivers have to be patched in order to enable this (together with the sc-plugin for vdr). 
<mkrufky> I CANT TELL YOU HOW TO DO THAT
<mkrufky> but
<mkrufky> what i CAN tell you how to do, is to patch a dvb driver and install that into your ubuntu kernel
<mkrufky> and yes, if you use the repository on linuxtv.org, you can apply your patch, build the tree, and install the new drivers into your ubuntu kernel
<mkrufky> please note:
<Hovefirse> mkrufky: I wouldn't want to know anything about paid channels, you see - all I want to do is patch my driver 
<mkrufky> any time you get a kernel update from ubuntu, you will have to do "make distclean" inside the v4l-dvb tree from linuxtv.org, and repeat the process
<mkrufky> yup... i cant talk to you about pay channels
<mkrufky> anyway... now this is off-topic... i'll be in #linuxtv if you have questions about that build process
<android6011> how is support for ar5007eg wireless cards coming in intrepid?
<android6011> the last alphas i have tried dont recognize the card at all even though it says atheros driver installed
#ubuntu-kernel 2008-09-09
<tjaalton> is there an ETA for the .27-3 kernel?
<cropalato>  sorry for the newbie question. Where can some one get info about become a kernel developer?
<CarlFK> smb_tp: amd64 - if i installed just that (so not apps/modules) would it help any?
<CarlFK> i wouldn't have network, and maybe even no shell, so I wouldn't be able to upload logs
<CarlFK> but I would be able to see if it pauses at the same point 
<smb_tp> CarlFK, It is just the same code just amd64 version for some others to test. So I don't expect a different behaviour.
<CarlFK> figured as much
<smb_tp> CarlFK, Sure you can try. If that works, then maybe there is a 32/64 bit problem lurking
<CarlFK> smb_tp: cat /proc/cpuinfo model name	: AMD Turion(tm) 64 X2 Mobile Technology TL-60
<CarlFK> dpkg: error processing linux-image-2.6.27-3-generic_2.6.27-3.3smb5_amd64.deb (--install):
<CarlFK>  package architecture (amd64) does not match system (i386)
<CarlFK> guessing it is looking at the current .. um... os
<smb_tp> CarlFK, Oh yeah. It looks at you installed architecture. You can force it but all your binaries are 32 bit so this probably won't work
<CarlFK> all we need is for it to boot, not ... um;  be usefull, right ?
<smb_tp> CarlFK, At some point the ramdisk takes over and that would be 32bit stuff (i don't think there is biarch support), so it might not get very far...
<CarlFK> um.. magic happend
<CarlFK> carl@dv67:~$ uname -a
<CarlFK> Linux dv67 2.6.27-3-generic #1 SMP Mon Sep 8 22:51:51 UTC 2008 x86_64 GNU/Linux
<CarlFK> shell, network...
<smb_tp> CarlFK, Oh right, should probably have more confidence in biarch support then. :)
<CarlFK> [    0.000000] Command line: root=UUID=270934eb-b4c5-4f17-87e4-8ebea9d98ed3 ro highres=off nohz=off vga=6 
<CarlFK> no pauses - what params do you want ?
<smb_tp> CarlFK, ok, that combination has worked with i386 kernel too
<CarlFK> yes
<smb_tp> CarlFK, without "highres=off nohz=off" with "apic=debug debug" 
<smb_tp> CarlFK, Only need to know whether this stops or not. Logs/dmesg only if it happens to _not_ pause
<CarlFK> ok
<CarlFK> what is this ï»¿biarch support?
<CarlFK> it paused. at least it isn't a surprise :)
<smb_tp> Ok, so in this case i don't need anything more at the moment
<doko> rtg, BenC: apparently neither gcc-4.1 and gcc-4.2 is needed to build kernels in intrepid on community ports. is this correct?
<rtg> doko: dunno. I've yet to look at the community ports packages.
<rtg> doko: Ben is on vacation this week.
<timbba> Hello. I have Ubuntu Hardy kernel 2.6.24-21. This kernel is buggy and I know that > 2.6.25 kernels work with my machine. How can I get newer kernel to Hardy and all necessary packages (linux-ubuntu-modules, linux-headers and linux-image)? Some packages are missing from Intrepid and PPA  repositories..
<CarlFK> timbba: not 'best' but good enough: wget http://people.ubuntu.com/~smb/bug254668/linux-image-2.6.27-3-generic_2.6.27-3.3smb5_i386.deb  dpkg -i <that>
<rtg> timbba: try the kernel PPA at http://ppa.launchpad.net/kernel-ppa/ubuntu
<timbba> I have tried already PPA kernels.. there are no ubuntu-modules packages, so my wifi isn't working
<rtg> timbba: 2.6.27 has LUM folded into the package, so LUM is no longer needed.
<timbba> So I can get kernel packages, but how about those modules for my wifi card (Zydas based)
<rtg> timbba: if they aren't in the 2.6.27 package, then they are not supported.
<timbba> oh god.. so nobody can't get Zydas wifi to work?
<rtg> I can't remember. you'll have to look in the kernel source for 2.6.27-rc5
<amitk> timbba: what card is it?
<timbba> edup something :)
<timbba> timbba@media-timbuktu ~ $ dmesg | grep zd
<timbba> [   32.583130] zd1211rw 2-2:1.0: eth0
<timbba> [   32.583145] usbcore: registered new interface driver zd1211rw
<timbba> [  165.221220] zd1211rw 2-2:1.0: firmware version 4605
<timbba> [  165.261183] zd1211rw 2-2:1.0: zd1211 chip 079b:004a v4330 high 00-60-b3 AL2230_RF pa0 g----
<amitk> timbba: that doesn't help a lot
<timbba> timbba@media-timbuktu ~ $ lsusb
<timbba> Bus 002 Device 002: ID 079b:004a Sagem 
<amitk> timbba: is it in http://linuxwireless.org/en/users/Drivers/zd1211rw/devices?
<timbba> yes it is: Sagem  	XG760A  	zd1211  	079b  	004a  	AL2230
<amitk> timbba: then please file a bug in launchpad describing how the device is not working. From a quick glance, it looks like intrepid's 2.6.27-based kernel should have support for it. No separate modules needed.
<timbba> it doesn't find the firmware.. that is the problem. The card itself is recognized
<CarlFK> timbba: that would be the "ï»¿describing how the device is not working"
<timbba> ok :)
<amitk> timbba: 'ls -l /lib/firmware'
<timbba> how about copying firmware from previous kernel?
<amitk> timbba: exactly... :)
<timbba> oh.. I have already removed 2.6.27 kernel so there is just...
<timbba>  ls -la /lib/firmware/
<timbba> total 12
<timbba> drwxr-xr-x  3 root root 4096 2008-09-09 17:21 .
<timbba> drwxr-xr-x 15 root root 4096 2008-09-09 17:20 ..
<timbba> drwxr-xr-x  3 root root 4096 2008-09-02 05:51 2.6.24-21-generic
<timbba> but I will give it a try.. I'll copy the firmware after I have reinstalled the kernel... Let's see what happens
<amitk> rtg: I forget why we moved from /lib/firmware/<kernel version>/* to /lib/firmware/*. And do our packages handle that transition?
<rtg> amitk: Ben's contention was that firmware didn't change enough to bother keeping separate copies per ABI. For most drivers that's probably true. I assume upgrades are handled, but I've not a dist-upgrade in a bit (since FireFox didn't work on some web sites, I went back to Hardy)
<amitk> probably a good idea
<pgraner> Hello Everyone... I'm standing in for BenC today (he is on holiday) for the Weekly Kernel IRC Meeting.
<pgraner> ogasawara: Can you tell us how we are looking wrt to 2.6.27?
<pgraner> [Link Regressions https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-2.6.27 ]
<ogasawara> pgraner: from my point of view I think we are looking quite good with the move to 2.6.27
<ogasawara> pgraner: there are the noted list of regressions (link above) but I have gotten good feedback from a handful of those bugs that they will be resolved with the next kernel we release
<pgraner> Looks like we are sitting at about 30 regressions, with most of them having fixes upstream or plans to get them fixed soon.
<ogasawara> pgraner: for example the suspend/resume issues should hopefully go away
<pgraner> ogasawara: great
<ogasawara> pgraner: some of the boot failures will look to also be resolved
<pgraner> ogasawara: we are sitting at about 70 bugs fixed by 2.6.27 
<pgraner> [LINK https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=fixed-2.6.27]
<ogasawara> pgraner: yup, so if we stuck with 2.6.26 we'd have to consider most of those unresolved then
<pgraner> So far the feeling of the kernel team is that there are no real show stoppers and that we are on track for GO decision on the 14th per [LINK https://wiki.ubuntu.com/KernelTeam/2.6.27-kernel-plan]
<pgraner> rtg: is looking at RaLink RT2860 LP# 210725 issues
<pgraner> s/rtg:/rtg/
<tjaalton> when will -3 be uploaded?
<rtg> tjaalton: as soon as -rc6 is in the can.
<tjaalton> rtg: ah, thanks
<pgraner> anyone from the kernel team have anything to add?
<rtg> pgraner: I think it's Stefan thats looking inti the RaLink driver stuff. He built a DKMS package IIRC.
<pgraner> rtg: ah, correct for some reason I had you down for it. I guess I'm trying to give you too much to do...
<rtg> I'm going to start putting some of the DKMS packages on the kernel PPA, so that they are semi-official
<pgraner> correction smb_tp will be looking at the RaLink RT2860 LP# 210725 issues
<pgraner> Any questions?
<pgraner> Ok I guess we'll call this meeting over for today. If anyone has questions or follow up questions you can post them here and I will answer or you can email me at pgraner@canonical.com.
<pgraner> thanks!
<johanbr> I've been bitten by a usb bug which has existed upstream since 2.6.25 and which prevents me from connecting to my Motorola phone. A patch exists, but is not yet accepted upstream. Is there any chance this patch could go in?
<laga> johanbr: https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/263217 ?
<johanbr> laga: Probably not. 2.6.24 works fine for me, but later kernels don't, which is the opposite of what's stated in that bug report.
<johanbr> There's a discussion archived at http://permalink.gmane.org/gmane.linux.usb.general/8532
<laga> there's a test PPA
<laga> maybe you can try that kernel
<laga> the problem sounds familiar ;)
<johanbr> I doubt it'll work, but I could try.
<Bor_Ed> evening. is it too late to request v4l-dvb/mantis driver to be included for intrepid yet? the driver gives ~270 dvb card and stick drivers available and builds currently without issues on 8.10
<laga> 270 *new* dvb boards?
<CarlFK> Bor_Ed: is 270 a count or a model number?
<Bor_Ed> module count
<Bor_Ed> including frontend, jingles and bells
<laga> and how is it different from the v4l-dvb tree included in the current kernel?
<Bor_Ed> doesn't support the dvb-c or dvb-t devices around europe that well
<laga> so you're basically suggesting that the kernel devs should include regressions? ;)
<Bor_Ed> well, I was pointed to here from #ubuntu-devel since the driver level stuff belongs to you guys (I heard, no pun)
 * laga is not a kernel dev, just for the record
<Bor_Ed> I read that mantis is getting to v4l-dvb kernel tree but not in time for release of 8.10
<laga> but as one of the mythbuntu guys, i'm interested in better DVB support
<Bor_Ed> I had to fetch and compile the mantis tree but it worked as a charm on first trial on stock intrepid with build-essential&the rest of the deal
<laga> if it's not even in v4l-dvb yet then changes are probably slim
<laga> maybe it'd be possible to cherry-pick certain (new) device drivers
<laga> but that's just my opinion ;)
 * Bor_Ed is long time linux user and spotted the lack of feat in current ubu... servers still stay on debian, sorry :D
<Bor_Ed> afaik, mantis is getting merged to v4l-dvb at some point in the future, the prob is though that currently v4l-dvb kernel driver doesn't support much more than couple of dvb-s decoders
<Bor_Ed> <RANT> and ati binary driver still refuses to build so I could have DRI </RANT>
<BenB> hi... I'm trying to install the latest Linus kernel. I have the kernel compiled, but can't get an initrd generated.
<BenB> I would really like to avoid make-kpkg and creating and installing deb packges. lacking another way that I knew of, I tried that, and it doesn't work....
<BenB> first,  the -append-kernel-version freaks out on the -rc5 plus my -foo
<BenB> so, I dropped that
<BenB> second, it aborts with "arch/xen/ not found". well, yes, that dir does not exist in latest kernels. why does it have to try to build a Xen kernel? I just want an initrd!
<BenB> so, I pass --arch "x86_64", but then it fails with "I do not know where the kernel image goes to [kimagedest undefined] ... Please specify a subarch, and try again.."
<BenB> I am stuck
<BenB> nevermind the last one. I accidentially passed "x86" as arch
<BenB> it still trips over the -rc5, though, even without --append-kernel-version
<BenB> I had to clean everything and rebuild from scratch. that'll take almost 1h *sigh*
<BenB> is there any way to create an initrd without make-kpkg? that takes 20 minutes for me *without* any code or config changes. i.e. first make-kpkg takes 1h20m, second (directly afterwards) takes half an hour (!). creating in initrd takes seconds (e.g. on suse).
<mjg59> BenB: mkinitramfs
<BenB> mjg59: thanks!
<BenB> (I wish I'd have known that 2 hours earlier)
#ubuntu-kernel 2008-09-10
<Scorviper> ï»¿ï»¿I'm new to linux and i'm having a  issue with installing vcast rhapsody, imesh, and tunebite......i tried using wine but that didn't seem to help What Should I Do? I'm willing to try anything to get these programs to work cause i use them to upload music onto my LG VX9900 i know of no other way to upload the music to my phone..any info would be much appreciated please PM me with any ways to solve my problem  Thank You.... i'm
<tjaalton> 2.6.27-rc6 released :)
<xivulon> cking ping
<cking> hi
<xivulon> I seem to have problems mounting ntfs devices on wubi boot
<xivulon> When I use mount.ntfs I get "Device or resource busy"
<xivulon> When I use mount -t ntfs I get "No such device"
<xivulon> I did run chkdsk /r and the disk should be clean, also tried on 2 separate partitions
<xivulon> that is using today's daily
<xivulon> but had the issue for a few days
<cking> Via the loopback and using 2.6.27-2 or 2.6.27-3 kernel?
<xivulon> no just plain ntfs mounts at the very beginning of the boot process 
<tjaalton> where is this -3 available?
<cking> tjaalton: soon :-)
<tjaalton> bah :)
<xivulon> cking this is when mounting the host device before mounting the loop device therein
<cking> xivulon: can you put in a bug report, meanwhile I try to reproduce this and see what is going wrong as one today's priorities.
<cking> s/one today's/one of today's/
<xivulon> cking, I guess we can reuse https://bugs.edge.launchpad.net/wubi/+bug/268123
<xivulon> as davmor2 has been experiencing the same issues it seem
<cking> xivulon: please to. I've not yet looked at this one - it's in my inbox though
<cking> xivulon: did this work on a 2.6.26 kernel?
<xivulon> cking it's the kernel in the latest daily, 2.6.27-2
<cking> xivulon: ok - I will investigate why this is occuring.
<xivulon> thanks a lot
<cking> no problem
<xivulon> on a side note, VirtualBox gets into funky kernel crashes when I try to boot wubi (hardy host, intrepid guest)
<xivulon> or endless loops
<xivulon> I am far more concerned with the first issue though on real hardware though
<cking> xivulon: this is fixed in 2.6.27-3 - there is a workaround too:
<xivulon> ah good to know, it will simplify my testing life
<cking> xivulon: boot intrepid with the boot paramater  noreplace-paravirt as a temporary workaround. this removes the paravirt run time kernel patching which causes a bug in VirtualBox. 
<cking> It will be fixed in VirtualBox 2.0.2 apparently.
<xivulon> thanks
<cking> Meanwhile, I put a workaround in 2.6.27-3 which means you won't have to use the noreplace-paravirt 
<cking> but for now noreplace-paravirt is worth using - it will run much slower though :-(
<xivulon> yes I can boot in VB now :) and yes it is slower
<xivulon> I do run into the ntfs mount problem in VM as well...
<xivulon> any command you want me to run before I run off to the office?
<cking> xivulon: no.. I think I have enough info to keep me busy
<xivulon> thanks in advance cking
<xivulon> once there use syncio :)
<cking> xivulon: will do
<xivulon> cjwatson: did you have any chance to look into 243105?
<tjaalton> uhm, vista upgrade broke my e1000e, "The NVM Checksum Is Not Valid"
<siretart> does the ubuntu live cd autoload the kernel module dm_mod?
<cropalato> any body know about a noise at the audio card with 2.6.27 kernel?
<onewhirled> Can you tell me what kernel options need to be set in order for wubi to boot?  I have loop and cryptoloop, ntfs and so forth.  The current Intrepid amd64 (for my intel core 2 duo) 2.6.27 based kernel doesn't boot, so I am trying to build my own.
<onewhirled> I have already commented on a bug in launchpad on this issue, but would like to determine the possible problem with the current Intrepid kernel.
<onewhirled> I have been building my own kernels for years, so I think my basic build configuration is sane.  I can boot the older 2.6.24 based kernels, but when I run lsmod and read the dmesg output, I don't immediately spot any significant difference between the 2.6.24 kernel and my build.
<onewhirled> I have tried booting my own 2.6.27-rc6 kernel, but it is failing with the same error as the Intrepid kernel.
<smb_tp> onewhirled, With current Intrepid alphas boot problems might be hpet related. You might try "noapictimer" or "highres=off nohz=off" to get it booting.
<smb_tp> onewhirled, If you build your own kernel, there have been several patches from Thomas Gleixner that were fixing timer related things.
<smb_tp> onewhirled, -rc6 should have those fixes. So it is probably something different. Any way to determine where it stops?
<onewhirled> I don't know how to debug wubi at this point.
<onewhirled> I have a chat going with one of the Ubuntu testers in a different window.  He indicated the possibility that the problem is a combo issue between wubi and kernel code.
<onewhirled> https://bugs.edge.launchpad.net/wubi/+bug/268123
<onewhirled> When the boot fails, it seems to drop to the initrd (I think) command line.
<onewhirled> There is debugging info on the screen, but I'd rather not send a picture of the screen.
<onewhirled> I will ask the guy in the tester room.  Thanks.
<smb_tp> onewhirled, Hm, ok. Don't know that much details of wubi. Ok. 
<johanbr> laga: I tried the kernel images in the bug report you pointed me to yesterday. Didn't help.
<pwnguin> anyone know the triaging USB counterpart to #
<pwnguin> #
<pwnguin> sudo lspci -vvnn > lspci-vvnn.log 
<mkrufky> lsusb is to lspci as usb itself is to pci itself , pwnguin
<pwnguin> gimme a sec to parse that
<mkrufky> in other words...
<pwnguin> so lsusb supports -vvnn
<mkrufky> lsusb does for usb what lspci does for pci
<pwnguin> i know that much, but the details are what counts here ;)
<mkrufky> there is no -n for lsusb ... it already shows you the vid:pid in numerical form 
<mkrufky> s/"vid:pid"/"vid : pid"/1
<pwnguin> anyone know about bluez-firmware?
<pwnguin> its in debian but not ubuntu -- and a user is reporting their bluetooth wont work without it
<pwnguin> https://launchpad.net/bugs/156133
<johanbr> I'm affected by a USB bug that stops me from connecting to my motorola phone. This bug has existed since 2.6.25, but earlier kernels work fine. A patch exists, which is not yet accepted upstream. Is there any chance this patch can go in?
<pgraner> johanbr: make a request to the kernel-team mailing list with the justification and rational with link to patch and it will get considered
<johanbr> Alright, will do. Thanks.
<balbir> Not sure if this the correct place to ask, but I have a user space library for a kernel feature, that I want to package for ubuntu, anybody willing to point me to the procedure to do so? links?
<Ampelbein> balbir: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<balbir> Ampelbein: Thanks
<kirkland> Sep 10 17:49:42 t61p kernel: [ 2039.652738] wifi0: rx FIFO overrun; resetting
<kirkland> Sep 10 17:55:04 t61p kernel: [ 2362.330855] rix 514 (0) bad ratekbps 0 mode 1
<kirkland> i'm getting those with the Intrepid 2.6.27 kernel, unfortunately
<kirkland> rtg: ^ any ideas?
<vindictive> has anyone had a problem with running vmware with the latest ubuntu kernel?  sometimes when you move your mouse between VMs, the ctrl + alt + shift keys stop working
<vindictive> you have to reset the keyboard map for it work again
<vindictive> from my reading at launchpad, it seems they've traced the problem to something in the kernel
#ubuntu-kernel 2008-09-11
<johanbr> Does anyone know if I have to subscribe to post to the kernel-team mailing list?
<Syco54645> hello, i am trying to compile vanilla but when i run mmake-kpkg clean it errors with a few things.  error is pasted here http://pastebin.ca/1199588  does anyone have any ideas?
<amitk_> xit
<amitk_> exit
<Syco54645_work> hello, i finally got vanilla to compile for me but now the headerfile deb that it creates is causing an error for others, they can no longer compile.  the error is aparently "the directory doesnt exist.. /lib/modules/2.6.26.5-v.4aaao/build"
<pwnguin> anyone know what this kernel-helper boot process is up to?
<pwnguin> its eating like 20 seconds at boot
<wgrant> pwnguin: It should run each time you get a new kernel. It will copy the kernel to last-good-boot.
<pwnguin> http://people.cis.ksu.edu/~jld5445/intrepid-20080911-9.png
<pwnguin> am i reading that right?
#ubuntu-kernel 2008-09-12
<munckfish> Hi, I have a proposed update for the linux-ports kernel sat in my Git tree. The changes are for the PS3. I can't test on any of the other architectures unfortunately.
<munckfish> could someone explain what the process should be to get these changes reviewed and included?
<munckfish> Should I just send a [request pull] message to the kernerl-team list? Or should I try to find folks to test it on other architectures first?
<munckfish> also, I appreciate it's late on in the Intrepid cycle, so any advice on how or if at all this is likely to get included would be great.
<amitk> munckfish: please send a pull request to kernel-team. How are the changes impacting other arches?
<munckfish> amitk: ok I'll do that. The other architectures will be affected in that I re-synced to 2.6.25.16. Most of the few patches I had to apply should only affect powerpc.
<munckfish> One patch fixed a boot hang introduced in 2.6.25.10 by code in 
<munckfish> drivers/usb/core/hcd.c
<munckfish> A diffstat of my changes/patches not including the re-sync is here: http://paste.ubuntu.com/46120/
<munckfish> My tree is here: http://kernel.ubuntu.com/git?p=dmunckton/ubuntu-intrepid-ports.git;a=summary
<amitk> munckfish: a quick glance doesn't reveal anything catastrophically wrong :) Hopefully stable tree updates shouldn't kill other arches.
<munckfish> amitk: great thx for looking over it
<munckfish> amitk: so is your main focus on lpia support? I notice that's in the name of your tree on zinc
<amitk> munckfish: for the moment, yes
<munckfish> ok thx for you help
<amitk> munckfish: np
<rtg> smb_tp: have you tried sending your depmod changes to the maintainer?
<smb_tp> rtg, No not yet. Since the bug I created them seems to be not solved by that (at least there still might be something missing)
<smb_tp> s/bug I/bug for which I/
<rtg> smb_tp: you were definitely on the right track.
<smb_tp> rtg, Probably the machanism that loads the modules for usb devices should stop at the first driver that is successfully loaded
<rtg> smb_tp: that seems like a modprobe issue
<smb_tp> rtg, Either modprobe or the framework around (suspect hal but just by gut feeling, no proof). You also had some issues with ordering. Did you get around them with this patch
<rtg> smb_tp: yep - it solves the case where a new module with a different name supersedes an existing module with regard to device IDs
<rtg> and still preserves the search order
<smb_tp> rtg, yours was a pci driver IIRC
<rtg> smb_tp: yep - but I'm sure USB would suffer the same issue
<smb_tp> rtg, The ordering problem in any case. I could see it on two of my machines. Depending on creation order of the dirs the order in which the ids/drivers where listed just changed
<rtg> smb_tp: as long as the 2 modules have the same name, then ordering is done correctly, right?
<smb_tp> rtg, Yes, and only in that case. Actually that is with or without the patch handled differently. If there is a module with the same name, only the one with the highest priority (search order) will be kept.
<smb_tp> For drivers that supply the same pci id, both are listed in the modules.* files
<rtg> smb_tp: that as is it should be, so that blacklisting the first module allows you to load the second module.
<rtg> but that only works if they have a different name
<smb_tp> rtg, yep (to one) if they have the same name (second statement)
<smb_tp> rtg, Or I am confused... Let me rethink
<rtg> smb_tp: you're right.
<rtg> smb_tp: I think you should engage the maintainer on these issues.
<smb_tp> rtg, Right, if there are already two corner cases this makes sense. And your case is even solved by a change
<smb_tp> rtg, Marco d'Itri?
<rtg> smb_tp: dunno, who's in the changelog?
<smb_tp> rtg, Him (beside of me and you for the last minor changes. :))
<Q-FUNK> howdy!  recent 2.6.27 uploads seem to have broken fbdev.  I cannot get any login prompt on vcons, even when booting in recovery mode. is there any change in how the fbdev modules are compiled that would explain this and how do I fix it?
 * elkan76 hi everybody!
<Wellark> nice.. I have a laptop with unsupported rtl8187 wireless and (broken) r8169 wired
<Wellark> no network for me :)
<Wellark> will provide more info later.. :/
<elkan76> Sorry but where can i find the diffrences for the last propossed kernel 2.6.24-21 generic
<elkan76> I'm using the previous version of 2.6.24-21, and after the last update, my wireless drop down. I have a Broadcom 4318 AirForceOne rev.02 and Hardy Heron.
<elkan76> Thanks for any indication
<elkan76> Ohh and my module is b43... :)
<Wellark> ok. I used python (no network, no access to compilers or kernel source) to patch the usb id of my rtl8187 usb device to rtl8187.ko and got the wireless working so it's just a matter of adding the ID to rtl8187_dev.c
<Wellark> but now dns is not working (might have something to do with NetworkManager doing something smart with resolv.conf) and I can't download any packages atm..
<Wellark> does anyone have the interface specification from realtek for r8169 chipsets?
<elkan76> Hi, i find three bugs that are similar, but in different dates, there are a common factor??
<elkan76> https://bugs.launchpad.net/ubuntu/+bug/269533
<Kano> hi, does somebody else have got lots of
<Kano> [46591.657036] ata2: EH pending after 5 tries, giving up
<Kano> [46591.657045] ata2: EH complete
<Kano> ?
<Kano> with latest 2.6.27-3.4
<Kano> seems to be the pata-amd
#ubuntu-kernel 2008-09-13
<Wellark> OK. not good. r8186 has not had any updates in over a year..
<Wellark> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/net/r8169.c;h=5ec7752caa4806c7a2adb10d898c11e04a39583f;hb=605bebe23bf6ac66c0a717e663a7baa2f981294d
<Wellark> and the same goes for rtl8187..
<laga_> !seen benc
<laga_> hum. no seen bot-.
<laga_> i know he's on a vacation. OTOH, he committed something to git so i figured he might be back already
<Syco54645_AAO> hello, i compiled my own kernel using make-kpkg and it generated the kernel image and also the headers in deb format.  however when others install them they can no longer compile.  why is that?
#ubuntu-kernel 2008-09-14
<hudnix> Hi guys. After doing the latest partial dist-upgrade of Intrepid, nvidia-glx-177 module won't install. Anyone else having problems (and is this the right forum for this?) I'm using a geforce 6200.
#ubuntu-kernel 2009-09-07
<NoelJB> does anyone know what to install for linux headers if installing linux-image-virtual?  there doesn't appear to be a matching headers .deb.  thanks.
<hyperair> it's linux-headers-virtual
<NoelJB> hyperair, yes, I see that (now) via apt-cache, but it doesn't get built when following https://help.ubuntu.com/community/Kernel/Compile
<hyperair> what's the command you used?
<NoelJB> Looking at linux-headers-virtual, though, it tells you that linux-headers-server is the matching one.
<NoelJB> hyperair, command?  for what?
<hyperair> for compiling kernels?
<NoelJB> debian/rules updateconfigs; debian/rules clean; AUTOBUILD=1 fakeroot debian/rules binary-debs
<hyperair> ah
<hyperair> hmmm
<NoelJB> resulted in image-{virtual,server,generic}, headers-{generic,server} and the libc-dev
<hyperair> ah then install the -server one
<hyperair> the -virtual headers say that it's the same variant, right?
<NoelJB> yes, from apt-cache show linux-headers-virtual: "This package will always depend on the latest kernel headers available for virtual machines (which are the same headers as for the server flavour)"
<hyperair> yeah, so install the -server headers!
<NoelJB> so that's the answer.  I suppose I would have to build linux-meta to get the .deb.
<NoelJB> hyperair, LOL I will.  I hadn't found that when I asked :-)
<NoelJB> hyperair, thanks :-)
<cooloney> NoelJB, yeah, hyperair is correct. There is no specific -virt flavor kernel anymore.
<cooloney> NoelJB, -server flavor kernel can support all the virt requirement such as kvm, xen
<NoelJB> cooloney, interesting, when installed, it appears as 2.6.31.9-generic-pae
<cooloney> NoelJB, so weird.
<NoelJB> cooloney, so I thought, too.
<NoelJB> cooloney, OK, something's odd.  MY build of if has the -server inside the -virtual, but when I quickly installed via apt-get into a VM, it says it did virtual, but I see generic-pae.
<NoelJB> unless generic-pae is what it does for 32-bit?  hmmm.
<cooloney> NoelJB, your machine is 32-bit or 64-bit?
<NoelJB> cooloney, both.  my host is 64 bit.  my builder VM (for building packages I intend to use) is 64-bit.  I was playing with a 32 bit Kubuntu VM, and wanted to see what (if any) benefit would come from the linux-virtual-image.  answer: none.  it blows up trying to boo it.
<NoelJB> cooloney, so that may explain why it was -pae in one, and -server in the other.
<cooloney> NoelJB, -pae is for 32bit machine extension, which supports more than 4G memory. 
<NoelJB> cooloney, I know what it is.  :-)  which is why it dawned on me that it might be because it was a 32 bit VM.  In any event, I won't spend more time on it for now.
<cooloney> NoelJB, yeah, i agree with you, 32bit VM -> -generic-pae, 64bit VM -> -server
<xkr47> hello, has anybody considered trying ck's BFS patches ?
<rudl> hi there! can one tell me in a short maner what the debian.master - folder is for and how to deal with it- make-kpkg seems to have problems with it..
<evon> I was trying to build my kernel and got this error arch/i386/kernel/process.c:586: Error: suffix or operands invalid for `mov' can anyone help?
<rudl> debian.master: what is that folder for, it seems to be new..??
<evon> you talking to me rudl?
<rudl> anyone up and running in here?
<evon> i am trying to compile a custom linux kernel to support fatx partitions
<evon> I am using this howto http://www.xbox-linux.org/wiki/How_to_include_FATX_support_in_a_regular_Linux_kernel
<cooloney> rudl, since we add some flavors to support arm SoC, we keep debian.master as our master branch debian packaging control stuff
<rudl> evon: no, not directly.. Sorry, have to leave for a meeting.. grrr
<cooloney> rudl, while debian.mvl for marvell soc specific debain control stuff
<evon> can anyone help me at all?
<rudl> cooloney: so why do i get this stuff when cloning the git- repository for jaunty?
<rudl> cooloney, okay, where do I find documentation about this directory, because make-kpkg fails because of the debian.master- directory
<cooloney> rudl, sorry for the delay, i just checked the git log of debain.master directory of jaunty git tree
<cooloney> rudl, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=history;f=debian.http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=history;f=debian.master;hb=HEADmaster;hb=HEAD
<rudl> cooloney, "403 Forbidden - Invalid file parameter "
<rudl> cooloney, btw: thanks for your support
<cooloney> rudl, my pleasure, actually the author of this change might be on vacation.
<rudl> coolney, well: so debian is now "split" into debian and debian.master.
<rudl> coolney, FYI: This doesn't compile with current make-kpkg. Caused by the sed -e 's/ debian//g' -e 's/\.deb//g' it tries to deal with '.master' - (my case: 'crypto.master') wich is obviously not there
<rudl> coolney, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=14618fc13a66f053b3680274b7ea18766664f435
<rudl> cooloney, sorry, wron spelling, see my lines above to coolney
<cooloney> rudl, no problem. i just ping the smb for that. i did not try make-kpkg at all
<apw> rudl, the directory is an abstraction mechanism to allow branches to be made more easily
<smb> cooloney, "the" smb??? ;-)
<cooloney> smb, sorry, 
<apw> there may well be issues with make-kpkg, but you would need to make sure you have cleaned the tree correctly if you are using the git source
<cooloney> smb, adding 'the' to an noun name word is one of my typical typo
<smb> cooloney, No problem. I was mostly joking
<rudl> apw, all fine with me, just trying to "simply" compile a kernel, as I need to get rid of IPV6, as fetchmail delivers to exim using ipv6 and ipv6 is down using ip6tables.. I've come a long way so far..
<smb> rudl, Actually one of the last security updates added an option to disable ipv6
<cooloney> smb, i am also trying to sync with thie debian split change to my Android debian packaging.
<cooloney> smb, is there any wiki page about that?
<smb> cooloney, Sorry not (yet)
<rudl> smb, "option?" what kind of option- kernel- option?
<cooloney> smb, no problem, i will follow your patches anyway
<smb> rudl, http://bugs.launchpad.net/bugs/351656
<ubot3> Malone bug 351656 in linux "IPv6 cannot be disabled on Jaunty" [Medium,Fix committed] 
<smb> cooloney, That is what I did for repeating it on intrepid. In the commit messages there is a little info about it
<smb> rudl, ipv6.disable=1 on kernel command line
<smb> rudl, Though it might be in proposed only atm. checking...
<legend2440> when compiling a ubuntu kernel is    kernel-package    the best method?
<rudl> smb, thanks for the shortcut, just seen what you mean- didn't know theese echo 1/0 > proc are called options
<cooloney> legend2440, generally, we use fakeroot debian/rules build-binary
<smb> rudl, Yeah, but unfortunately they are broken in Jaunty and the fix was a bit complex and had some issues (though I cant remember which)
<smb> rudl, Ok, for the option you need to enable proposed for the moment
<legend2440> cooloney: thanks is there a good tutorial for that method?
<rudl> smb, no problem so far, I prefer not to COMPILE what I don't need, had a hijacker on my system using ipv6 once- well, all was safe for ipv4 - and ipv6 was open like a "barn door"
<rudl> smb, but for understanding: what do you mean "enable proposed"? I am allmost 100% autodidact so I am not familiar with such gramar
<rudl> smb, you mean something like --enable-proposed?
<rudl> Well, I'll consider both variants- cooloney- thanks for the hint to git- log. Didn't know it's that perfectly usefull. Shall be able to reproduce to original structure and compile with make-kpkg that way..
<smb> rudl, In the gui on installation source tick proposed update. Though that gives you everything in proposed
<smb> rudl, I also got a PPA with the latest kernel (usually): https://launchpad.net/~stefan-bader-canonical/+archive/jaunty
<rudl> smb, aah.. we talk about the apt- sources
<cooloney> legend2440, please look up in our wiki https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
<legend2440> cooloney: thank you 
<rudl> smb, phuu- too much shortcuts for the moment.. what an earth is a ppa?
<smb> rudl, Personal Package Archive
<rudl> smb, ppa- nice and short.. one more to learn, but thats what you have to deal with when you dance with the kernel-devils.. ;)
<rudl> Well, I gota work- thanks a lot for your help- guess I'll be able to fix my problem that way. I'll have another compiling- session this evening..
<smb> rudl, Heh, well actually PPAs are not restricted to us. You'll encounter them quit often
<jk-> fish4pie
<jk-> d'oh!
<apw> jk-, i know what you are doing for the rest of the morning
<smb> jk-, Can you give us the account information too :-P
<jk-> apw: it's already done :D
 * jk- wipes brow
 * jk- remembers to change the keyboard around before trying to log into the other machine
<legend2440> i have compiled ubuntu kernels in the past with varying degrees of success. i of course get the image and header deb files but i don't recall ever seeing the abi file  ie   abi-2.6.28-15-generic. how is that created and what is it for?
<smb> apw, I think I need you to have a second glance on bug 423296 with me. I checked on the mentioned DIDL patch and got the feeling you missed something there.
<ubot3> Malone bug 423296 in linux "regression: linux-image 2.6.28-15.51 in jaunty-proposed breaks brightness control of T500" [Medium,Triaged] https://launchpad.net/bugs/423296
<smb> Patch came in for bug 228399
<ubot3> Malone bug 228399 in linux "Closing lid results in kernel panic visible on VT-1" [High,Fix committed] https://launchpad.net/bugs/228399
<apw> smb, hrm
<smb> apw, My suspicion is that in the non-kms case (maybe even upstream) there is nothing that call acpi_video_register() after deferring it previously
<apw> hmmm.
<apw> smb, thats not sounding right is it
<smb> No not really.
<smb> Missed that somehow on the review
<apw> pretty sure thats a pretty simple backport, and so likely bust upstream too ... hrm
<smb> Well it is not that simple. There was much more code
<apw> smb, actually not sure how this would trigger?
<smb> A lot KMS stuff
<smb> In the upstream patch it will as for:
<smb> @@ -312,6 +370,11 @@ int intel_opregion_init(struct drm_device *dev)
<smb>         if (mboxes & MBOX_ACPI) {
<smb>                 DRM_DEBUG("Public ACPI methods supported\n");
<smb>                 opregion->acpi = base + OPREGION_ACPI_OFFSET;
<smb> +               if (drm_core_check_feature(dev, DRIVER_MODESET)) {
<smb> +                       intel_didl_outputs(dev);
<smb> +                       if (!resume)
<smb> +                               acpi_video_register();
<smb> +               }
<smb> but only with KMS I guess
<smb> Though probably nobody does much without KMS as it is so neat
<apw> smb, we can call it on module load, as it _may_ be called from acpi_video_init
<apw> static int __init acpi_video_init(void)
<apw> {
<apw>         if (intel_opregion_present())
<apw>                 return 0;
<apw>         return acpi_video_register();
<apw> }
<apw> module_init(acpi_video_init);
<apw> so we should only end up with it not there if we don't have the opregion
<smb> That is the place to deffer it
<smb> You get the problem if you have an opregion, then you do not register acpi video
<apw> you mean there is no later, try again
<smb> yep
<smb> That other code if from the upstream patch
<smb> In the backport I see no try again
<apw> yep but htat code is specifically MODESET only
<apw> so ... it got removed on backport as we don't have kms there
<apw> which implies its bust in non kms mode in both ... hrm
<smb> You might try with your i915 devs to disable kms and see whether you got backlight control
<apw> yeah can do that.  interesting that they managed to test this and have it work for them
<apw> i guess they tested it didn't explode, but not that it worked
<smb> Well actually I have not looked upwards whether it was changed again.
<apw> bah grub has changed, no menu
<apw> how do i get it back!
<smb> set the hidden timeout to false in /etc/default/grub
<apw> and if it won't boot without me fixing it, how do i do that
<smb> despair
<smb> maybe try to boot something external
 * apw puts up the 'not acceptable' flag
<apw> s'ok, seems that holdiing down shift gets you the menu back
<apw> smb, ok turning off modeset and i still have brightness control here
<apw> so i guess i have h/w which has its 'opregions' initialised
<apw> smb, do we have anything which fails the test?
<smb> apw, I would need to check on the aspire. There is a follow up patch to unregister acpi_video on unload too
<smb> Not that we currently need it as we do not do it
<apw> crap, so fail all round
<smb> I suppose it needs a few additions. But, depending on the effort, maybe better fix the new regression than to revert the initial patch as that was a crash
<apw> perhaps yes.  we need to figure out if this is flawed upstream generally too
<apw> as for a fix, i think we need to redo the check after the opregions are enabled
<smb> Yep, load it there and make sure we also unload it
<smb> Hm, thinking twice, the Acer is a poor test as it never had a working acpi video
<apw> indeed i am not at all sure why we need anything other than too only do the acpi thingy once and only once after the intel_opregion_init()
<smb> The only complicated thing is that the intel driver is initialized much later
<smb> apw, But somehow it feels that if you try to do that you need at least to do intel_didl_outputs, otherwise I see no other initialization
<apw> +       /* Must be done after probing outputs */
<apw> +       intel_opregion_init(dev);
<apw> we are expecting that to make the opregion appear
<apw> but it looks like we should be expecting that to i
<apw> do the init too
<apw> smb, it does look like we simply should have +       return acpi_video_register();
<apw>  after that
<apw> as we didn't do it before
<smb> From the description the need to defer acpi_video_init is that you need to have the list of display devices populated. In the backport this is not done as far as I see
<lool> apw: hey do you have some script and/or instructions to create a kernel for a LP bug; I basically want to rebuild karmic's linux with a patch for a LP xxxxxx bug and need to update changelog and use a proper version tec.
<lool> I see you often push kernels with lp-xxxxxx
<lool> The bug I'd like to produce a test kernel for is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/404421
<ubot3> Malone bug 404421 in linux ""Failed to restore crtc configuration: -22" on i915" [Medium,Confirmed] 
<lool> or do you just do this by hand?
<apw> mjg59, you about ?
<apw> lool, i just nod the changelog and build it by han
<apw> hand
<lool> ok thanks
<mjg59> apw: Hi
<apw> mjg59, just looking at this fix for the Intel crashes, when the opregion is not initialised and you call acpi methods on it
<apw> and noting that we end up never registering acpi in non KMS mode ... trying to work out if thats soluable
<apw> the patch in 74a365b3f354fafc537efa5867deb7a9fadbfe27
<mjg59> You need the connector list to populate DIDL, and that#s only available with KMS
<apw> and without KMS that init comes from the X server one presumes
<mjg59> Sorry for typing - broke my arm yesterday, still getting used to it
<apw> oh no!  ouch
<mjg59> Right, and X has no way to pass that info
<apw> so we'd need to intuit it later somehow
<apw> we are seing regressions due to that change, in a backport to non-kms
<lool> is there an easy way to build i386 kernel .debs on amd64?
<smb> lool, create a linux32 chroot
<lool> hmm ok
<lool> thanks
<apw> mjg59, so it seems that 'most' intel hardware that 'requires' it either doesn't really require it, or is being initialised before hand
<apw> i wonder if there is any way to tell either way, as not initialising acpi blindly seems to regress for a number of platforms
<lool> The upstream Makefile will properly pass -m32 if compiling a 32 bits kernel on amd64
<apw> lool but to get it compiled the same way, its much safer to do it the same as the buildds
<apw> making the chroot is pretty cheap
<lool> Well I'd have to create the chroot, install bdeps again, setup ccache again... and I'm lazy   :-)
<lool> If this can work for cross-compiling ARM packages, it should work for x86-32 right?
<lool> Since it's just for a test kernel for my test machines and for testers well I guess it's not a big risk I guess
<apw> perhaps so indeed
<mjg59> apw: Not that I know of
<Polterge|st> hey can anyone in here tell me does the new real time kernel for Karmic work with compiz ?
<Polterge|st> or does compiz crash it ?
<ghostcube> Polterge|st: compiz is not kernel related
<Polterge|st> no that isn't what I said
<Polterge|st> :)
<Polterge|st> I asked if this real time kernel crashes if I am running compiz 
<ghostcube> how should this happen
<Polterge|st> in the past the last real time kernel would crash if someone was running compiz
<ghostcube> eh ?
<ghostcube> on jaunty ?
<apw> Polterge|st, not heard any reports of it, but we don't monitor those kernels closly
<Polterge|st> also on suspend
<Polterge|st> what kind of results are people getting out of the real time kernel and can it be installed on 32 bit ?
<ghostcube> never heard that compiz crashes rt for me it hadent 
<apw> Polterge|st, i have no reason to use it
<Polterge|st> but does anyone know whether the real time kernel will work on 32 bit ?
<Polterge|st> or is that version buggy ?
<ghostcube> hmm it should work on 32 bit afaik
<ghostcube> why do you want the rt kernel btw
<Polterge|st> I think I will try to install it from repos
<Polterge|st> this is worth trying out anyway
<Polterge|st> it would have better latency than this stock kernel
<Polterge|st> I have pulse audio almost perfect in Karmic Alpha 5
<Polterge|st> I just need to try a better kernel
<evon> I was trying to build my kernel and got this error arch/i386/kernel/process.c:586: Error: suffix or operands invalid for `mov' can anyone help?
<evon> I was trying to build my kernel and got this error arch/i386/kernel/process.c:586: Error: suffix or operands invalid for `mov' can anyone help?
<evon> building a kernel and got this error make[1]: *** [arch/i386/kernel/apic.o] Error 1
<evon> make: *** [arch/i386/kernel] Error 2. can anyone help?
<apw> evon what version are you trying to build
<evon> 2.6.9
<evon> apw with an xbox patch
<evon> apw: http://www.xbox-linux.org/wiki/How_to_include_FATX_support_in_a_regular_Linux_kernel
<apw> evon, and what are you trying to build it on?
<mjg59> evon: 2.6.9?
<mjg59> I suspect people might have cared in 2005...
<apw> those xbox patches go up to at least 2.6.16
<evon> apw: ubuntu
<evon> apw you think i should try to patch a different kernel then?
<apw> 2.6.9 is well anchient
<mjg59> evon: Ubuntu never shipped 2.6.9
<evon> lol
<evon> another question is once I patch this kernel will i be able to mount fatx filesystems on my desktop?
<apw> +       tristate "FATX fs support (DANGEROUS)"
<apw> +       depends on EXPERIMENTAL && BROKEN && !LBD
<apw> its not even guarenteed you'd be able to do it with the patch it seems
<mjg59> evon: If you're talking about x-box DVDs, no
<mjg59> They can only be read with an actual xbox DVD drive
<apw> mjg59, interesting, some kind of h/w drm'y poop?
<evon> mjg59: no i'm talkin about usb's with fatx FS and HD with fatx FS
<mjg59> Yeah
<mjg59> evon: How do you have a fatx hard drive?
 * apw shudders
<evon> mjg59: from the xbox
<mjg59> apw: There's two DVD TOCs - the normal one just gives a small image with a video telling you to put it in an xbox. There's a command that needs to be sent to the drive firmware to get it to read the real TOC
<mjg59> evon: Ah
<evon> mjg59: so would i be able to?
<apw> mjg59, heh now that is plain mean
<mjg59> evon: In theory
<Kano> hi, when can we expect rc9 based kernel
<evon> ok cool
<evon> is 2.6.15 a good kernel to use? the latest xbox patch offered is for that version
<apw> Kano, when its been tested
<Kano> well intel without kms is broken,but luckly u uses it
<apw> evon, i'd not define anything that old as good in general
<Kano> cjwatson: did you optmize your initramfs code
<apw> intel without kms is broken on 2.6.31-rc9?  on what hardware?
<evon> apw: why is that? my intention is only to have that kernel as an option my grub. not to use it all the time
<Kano> apw: on vt switch on all i think, but can only test q45
<apw> evon, what is your ubuntu release
<Kano> vt switch or X shutdown
<evon> mint based on jaunty
<apw> evon, no idea if you'll be able to boot with such an old kernel on that userspace, thats a major delta
<evon> oh i c. So i would have to get an old version of ubuntu or something to get this to work?
<apw> you might have to yes, worth trying it first
<apw> you checked there are no userspace tools to read fatx?
<evon> nope. I have been looking for days
<Kano> cjwatson: http://paste.debian.net/45952/
<Kano> cjwatson: a) the modprobe check is absolutely useless as you can modprobe every module even without hardware
<Kano> cjwatson: b) if you want to test for hardware you can check the loaded modules after udev
<Kano> cjwatson: the current result of your code was that intel-agp and i915 is loaded on every system and FB=kms
<apw> evon, it seems odd that xbox support stopped at 2.6.16 ... kinda implies they found another way
<evon> apw: I've haven't come across anything. if you do please let me know
<evon> apw: i've google searched all over for fatx support linux but i've come up with no way of fixing the prob. and there are many others with no solutions either
<apw> evon, might be worth trying to ask the original authors of the patch what happened to it
<evon> apw: ok
<karl86> hi guys, after my machine has been running for a certain amount of time it seems to loose the ability to recognise when a cd is in the drive. Is there something I can restart (other than the machine) to get it back?
<johanbr> now that ipv6 is built-in (not a module), what's the recommended way of disabling ipv6?
<johanbr> oh... /proc/sys/net/ipv6/conf/all/disable_ipv6 I guess
#ubuntu-kernel 2009-09-08
<legend2440> looking at config-2.6.28-15-generic i see that CONFIG_HZ=250 and that # CONFIG_HZ_1000 is not set. would there be any noticeable benefit to recompiling  with CONFIG_HZ_1000 enabled?
<maxb> What's the proper way to request a backport of an upstream kernel cset as SAUCE? Straightforward bug on the linux package?
<amitk> smb: You set LSM_MMAP_MIN_ADDR to 0 for the x86 archs
<smb> yes
<amitk> I don't see that documented in the Kconfig
<amitk> what does that do?
<amitk> I need to decide what to set it to for ARM
<smb> Upstream added a hard low barrier for the mmap addresses. So if you set LSM_MMAP_MIN_ADDR to any value you cannot change the mmap_min_addr in the running system to something lower than that
<smb> There is a DEFAULT_MMAP_MIN_ADDR which sets the default value, and the LSM version is the lower barrier
<amitk> aah, I get it now
<smb> Changing that to 0 might be a temporary solution until we know how to allow certain applications access to lower regions with that in effect
<amitk> and I presume a sysfs interface allows one to change it to any value between DEFAULT_MMAP_MIN_ADDR and LSM_MMAP_MIN_ADDR
<smb> correct
<smb> err
<smb> no
<smb> you can change it to anything between LSM_MMAP_MIN_ADDR...max
<amitk> LSM_MMAP_MIN_ADDR <= DEFAULT_MMAP_MIN_ADDR <= max ?
<smb> The DEFAULT is just the initial starting point after boot
<amitk> so LSM_MMAP_MIN_ADDR <= DEFAULT_MMAP_MIN_ADDR <= max ?
<smb> I cannot remember to have seen code to make sure DEFAULT is bigger or equal than LSM_MIN
<smb> It probably is assumed you act sensible
<amitk> ok, in any case LSM_MMAP_MIN_ADDR=0 allows userspace policy overrides w/o any sideeffects?
<smb> I would say so
 * amitk goes about changing the ARM values to 0
<smb> The thing is maybe, for security reasons, you want to have it set so normal userspace cannot go below a certain value and then define some security framework exceptions for those special apps that really need it
<amitk> smb: I was hoping that the 0 recommendation was from our security team
<amitk> and that they are working on policy to enforce it
<smb> amitk, Well the 0 was from our security team because the upstream change broke the current interface. I still have to get back to them with that proposeal/question
<amitk> ogra: regarding bug 423767
<ubot3`> Malone bug 423767 in linux-fsl-imx51 "please enable rt3070sta in the imx51 kernel" [Medium,New] https://launchpad.net/bugs/423767
<amitk> ogra http://pastebin.ubuntu.com/267080/
<amitk> that driver is currently x86-only
 * ogra points to #mobile
<amitk> ogra: re: bug 424400
<ubot3`> Malone bug 424400 in linux-fsl-imx51 "DM9601 or Pegasus based USB NICs dont find their MAC address under 2.6.31-100-imx51" [High,New] https://launchpad.net/bugs/424400
<amitk> is this a bug only with the imx51 flavour or x86 as well?
<amitk> nevermind, it seems to work on i386 according to you last line in your report
<ogra> amitk, its not my bug :)
<amitk> you reported it
<ogra> and i cant reproduce it with any NIC i have 
<ogra> i moved it out of another bug that got very confusion because it had ten different things going on
<ogra> its Tobins bug
<amitk> ok
<ogra> amitk, tobin has a million of starnge things going on with his setup ... using a chain of USB KVMs, i still think its power related or his board is screwed
<amitk> ogra: who is Vladimir Vukicevic?
<ogra> no idea
<ogra> where do you see him ?
<amitk> bug 418238
<ubot3`> Malone bug 418238 in linux-fsl-imx51 "Ethernet (FEC) not functional on Babbage with 2.6.31" [Medium,Incomplete] https://launchpad.net/bugs/418238
<ogra> oh, wait
<ogra> yeah, i remember him, he has a B1 
<amitk> FSL?
<ogra> he hangs around in #ubuntu-armel
<ogra> i dont think so
<ogra> FSL doesnt touch the B1 platform anymore
<ogra> (he is vlad in -armel)
<amitk> neither do I (touch the B1, that is). Atleast for now.
<ogra> right, feel free to say its not supported and mark it invalid ... or dup it against the actual NIC bug
<ogra> i suspect once the NIC works generally it will work on the B1 too
<amitk> ogra: I don't see any other nic bug
<ogra> hmm, didnt i file it 
<amitk> so I changed the description on that to be applicable to B2
<amitk> https://bugs.edge.launchpad.net/ubuntu/+source/linux-fsl-imx51
<ogra> ok
<ogra> fine with me
<Twigathy> rar
<Twigathy> I just got a kernel oops... is this dead hardware or a bug in the kernel? http://paste.lisp.org/display/86753 (Last line is `[  954.886783] Fixing recursive fault but reboot is needed!')
<amitk> lool: ogra http://people.canonical.com/~amitk/mx51/linux-image-2.6.31-100-imx51_2.6.31-100.8_armel.deb has the rt3070 wireless enabled. (Plus the non working sound driver)
<ogra> amitk, installing ...
<lool> Twigathy: no idea
<lool> amitk: ok thanks
<ogra> amitk, you didnt break it hard enough, still boots properly ;)
<amitk> damn. I need to work harder.
<ogra> heh
<ogra> http://paste.ubuntu.com/267256/
<amitk> ogra: btw, did you insmod the sound driver last time?
<ogra> no, it was loaded automatically
<amitk> ok
<ogra> i rmmodded all sound stuff and modprobed it though
<ogra> neither gave any msg in dmesg
<ogra> amm
<ogra> hmm even
<ogra> http://paste.ubuntu.com/267260/
<ogra> ogra@babbage2:~$ sudo iwlist scan 2>&1|grep ^wlan
<ogra> wlan4     Interface doesn't support scanning : Network is down
<ogra> ogra@babbage2:~$ sudo ifconfig wlan4 up
<ogra> SIOCSIFFLAGS: Unknown error 132
<ogra> amitk, so i'D say that driver does noting helpful for us atm
<amitk> too bad
<ogra> amitk, oh, it didnt work because the kernal always loads rt3070sta and rt2800usb at the same time ....
<ogra> amitk, rmmodding both and then modprobing rt3070sta gets me this intresting output: http://paste.ubuntu.com/267302/
<amitk> aaah. yet another rt* driver that tries to load multiple drivers
<amitk> rt* device
<ogra> well, the outcome of the dmesg info looks very intresting
<ogra> some kind of ascii art
<amitk> heh
<maxb> hi, is a backport of an upstream changeset that fixes the acerhdf fan control driver to work on more kinds of Aspire One something that could be considered for SAUCE in karmic?
<amitk> maxb: is it already going into 2.6.32? If so, yes. Pointer to a bug and a patch sent to kernel-team@lists.ubuntu.com are appreciated.
<maxb> according to kernel patchwork it's currently in acpi-test
<maxb> so aimed at 2.6.32
<maxb> http://patchwork.kernel.org/patch/39701/ <-- this is it. So, I should file a bug against "linux" sourcepackage and then email kernel-team?
<amitk> maxb: yes, thats about right.
<maxb> ok, will do
<rtg> bjf, did 2.6.31-203.9 fix your Dove video issues?
<bjf> rtg, I didn't test that build, I tested the one I had done with the patch
<rtg> bjf, hint, hint...
<bjf> rtg, ack
 * amitk takes a break. Back in 40 mins for the meeting
<rtg> amitk, fix committed for bug #359049
<ubot3`> Malone bug 359049 in linux-mvl-dove "imx51 udeb hardcodes linux version in vmlinuz binary name" [High,Fix committed] https://launchpad.net/bugs/359049
<amitk> rtg: ack, thanks
<rtg> amitk, thought I'd save you an hour of groveling around in kernel-wedge
<bjf> rtg, actually you saved me, I was going to tell amitk I'd take care of it
<amitk> rtg: you probably did. I have no idea what changing bdep from y to n does
<rtg> amitk, actually, it was suffix, bdep isn't set
<amitk> aah, ok
<amitk> I'll pull in that patch to my rebased tree
<amitk> rtg: does wireless-crda come from a completely separate source package?
<rtg> amitk, it comes from a couple of git repositories
<rtg> amitk, see debian/scripts/update-crda-from-git.sh
<rtg> git://kernel.ubuntu.com/rtg/wireless-crda.git
<amitk> thanks
<amitk> rtg: hmm, it doesn't seem to be compiled for arm...
<rtg> amitk, uh, no, probably not
<amitk> I wonder how kernel packages are being installed in the arm live images currently. Because dpkg -i linux-image-2.6.31-100-imx51_2.6.31-100.8_armel.deb fails due to lack of wireless-crda
<amitk> lool: ogra ^
<rtg> amitk, good question
<amitk> rtg: the control file has Architecture: any
<rtg> amitk, oh, well then its built for any arch supported by the buildd
<amitk> rmadison wireless-crda
<amitk> wireless-crda |        1.7 |        jaunty | source, amd64, i386
<amitk> wireless-crda |       1.10 |        karmic | source, amd64, i386
<amitk> rtg: any clue why it isn't available for arm ^ ?
<rtg> amitk, I just tried pciutils, it only shows up for amd64 and i386
<amitk> packages.ubuntu.com shows the same
<amitk> rtg: it could be because arm packages lives on ports.ubuntu.com
<apw> TheMuso, seems our hda pcbeep channel is not well.  if you do enable it the sound is no longer pure tones but a nasty rasp
<Q-FUNK> ogasawara: anything new? :)
<Q-FUNK> I seem to notice initramfs hooks to dump a kernel panic to a file with kexec-tools and makedumpfile but where is the file dumped to?
#ubuntu-kernel 2009-09-09
<panda|phenom> cooloney, hi, morning :)
<cooloney> panda|phenom, moring
<cooloney> panda|phenom, your nick name is cool
<panda|phenom> cooloney, hehe
<panda|phenom> so i come to ask for thinkpad dock station support status in ubuntu
<panda|phenom> my laptop is lenovo T61P, and recently my project need to use a parallel port Jtag debugger, so i have to bought a dock station,
<panda|phenom> but unfortunately, i didn't make it work yet. is that ubuntu kernel already support this device? or i need to file a bug ask for hardware enablement?
<cooloney> panda|phenom, yeah, you'd better to file a bug, since i don't have such hardware
<panda|phenom> cooloney, oh, file this bug at: https://launchpad.net/ubuntu/+bugs ?
<panda|phenom> cooloney, actually, i can ship this dock station to you, if you are glad to help :)
<cooloney> panda|phenom, i don't have the T61P, either. heh
<cooloney> panda|phenom, yeah, please file the bug there
<jjohansen> ericm_: your packages arrived today
<ericm_> jjohansen, thanks man
<ericm_> panda|phenom, should require no driver to support a dock parallel
<ericm_> panda|phenom, it's a dock or a port replicator?
<panda|phenom> ericm_, well, let me check ...
<panda|phenom> ericm_, http://www.newegg.com.cn/Product/66-c00-126.htm
<panda|phenom> ericm_, seems it's a dock, not just a port replicator?
 * jk- looks
<ericm_> panda|phenom, that's a port replicator
<ericm_> panda|phenom, a dock will usually have a DVDROM expansion or a second hard drive
<panda|phenom> ericm_, oh, i see, it's called mini-dock
<ericm_> panda|phenom, some of my ex-colleagues in Marvell used TP61 with this port replicator and they worked well, shouldn't require any specific driver to support that
<ericm_> panda|phenom, I'm not sure if you have configured the ECP/EPP mode of the parallel port OK so that the JTAG debugger may sometimes be confused about that
<jk-> panda|phenom: does the parallel port work when the t61p is not docked?
<panda|phenom> ericm_, em, i think i've enabled IEEE 1284 transfer mode :(
<panda|phenom> jk-, oh, there is no parallel port on T61P, parport only exist on port replicator
<ericm_> panda|phenom, if you are using blackstone II, it should be in ECP mode
<jk-> panda|phenom: ah
<panda|phenom> ericm_, BTW: what's the major difference between port replicator and dock station?
<panda|phenom> ericm_, seems both USB port on T61P and mini-dock can work at the same time
<ericm_> panda|phenom, honestly I don't know - that's explained by IBM :-)
<panda|phenom> ericm_, s/IBM/Lenovo now :(
<ericm_> panda|phenom, yes, and usually some USB ports on the port replicator are actually the same ports on your T61P itself
<ericm_> panda|phenom, that's why they are called port replicator - they are not equipped with another USB chip inside, just some wired out
 * jk- had a dock with a PCI slot in it
<panda|phenom> ericm_, sounds interesting, is that mean parport on replicator only works if there already one parallel port on my laptop?
<ericm_> panda|phenom, there is one, but not enough space to have the physical port on your laptop, and the port replicator just wired that out
<ericm_> jk-, yeah, that's a dock
 * ericm_ suffers a whole day apt from mirrors.kernel.org showing only 718B/s
<panda|phenom> ericm_, i see, thanks for your clarify :)
<ericm_> panda|phenom, you are welcome, bro
<panda|phenom> ericm_, drop your buggy ADSL, use 3G :)
 * ericm_ is poor to afford 3G
<panda|phenom> jk-, so how much for your dock? is that portable? or still need to plug external power supply?
 * ericm_ found 3G from china mobile is even slower
 * ericm_ thinks the carriers are all evil here
<jk-> panda|phenom: oh, it was pretty old; this was when I had a T40
<jk-> pretty big too; had space for a PCI card inside :)
<panda|phenom> jk-, oh, seems designed for 3D game player, to extend additional PCI-E video card.
<jk-> nup, just plain PCI
<panda|phenom> ericm_, don't worry, SB(expo2010) meeting in Shanghai is coming, everything will be fine soon.
<ericm_> jk-, you can install a G400 PCI version, hehe
<jk-> :D
<ericm_> panda|phenom, I hope so
<panda|phenom> jk-, yes, Voodoo II card, or Banshee
 * panda|phenom highly suspect bought a broken mini dock-station, contacting re-seller ...
<cooloney> jjohansen, you are so kind, bro.
<cooloney> jjohansen, do you need us to buy something from China for you?
<jjohansen> cooloney: heh, no I can't think of anything I need/want atm.  And really letting you guys use me as a shipping address is np.
<cooloney> jjohansen, thanks, i guess ericm-afk prepared some gifts for your kids
<jjohansen> cooloney: yeah he said he would, they will love it :)
<cooloney> jjohansen, yeah, that is very special 
<lool> amitk: https://launchpad.net/ubuntu/karmic/+source/wireless-crda/1.10 wireless-crda is built on all arches
<lool> amitk: However rmadison only gives results for main arches, not ports
<amitk> lool: yeah, I figured that out a bit later. Sames for packages.ubuntu.com
<amitk> lool: but why isn't it installed along with the kernel in the rootfs I have.
<lool> amitk: How did you install your rootfs?
<lool> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu-imx51/latest/livecd-20090909-armel.out definitely reports wireless-crda in the squashfs
<amitk> lool: I'm not using a livefs. I used ogra's script to create a rootfs.
<ogra> ogra@babbage2:~$ dpkg -l wireless-crda|grep ^ii
<ogra> ii  wireless-crda                       1.10   
<ogra> amitk, ^^^
<ogra> its installed by default btw
<ogra> linux-meta-imx51 pulls it into the installation 
<ogra> amitk, just install linux-imx51, that should get you everything 
 * amitk wonders if his rootfs is too old
<amitk> root@babbage:~# apt-cache policy wireless-crda
<amitk> wireless-crda:
<amitk>   Installed: (none)
<amitk>   Candidate: 1.9
<amitk>   Version table:
<amitk>      1.9 0
<amitk>         500 http://ports.ubuntu.com karmic/main Packages
<amitk> It is probably a very old rootfs
<amitk> root@babbage:~# apt-cache policy linux-imx51  
<amitk> linux-imx51:
<amitk>   Installed: (none)
<amitk>   Candidate: 2.6.31.5.16
<amitk>   Version table:
<amitk>      2.6.31.5.16 0
<amitk>         500 http://ports.ubuntu.com karmic/main Packages
<Ng> I'm not entirely sure if this is upstream yet, but http://bugs.freedesktop.org/attachment.cgi?id=29294 looks interestingly worthy
 * Ng hrms at bug #281732 and the changelog therein
<ubot3> Malone bug 281732 in linux "Mute button not properly working on  current Lenovo Thinkpads x200/x200s , t400/t500, X300/X301, & W series" [Medium,Fix released] https://launchpad.net/bugs/281732
<Ng> that entire bug seems almost entirely invalid, and the new behaviour is wrong and the osi=Linux thing seems superficially terrifying
<Ng> the mute button and notifications worked perfectly in previous karmic kernels, and jaunty kernels on X300/301
<Ng> and afaik osi=Linux is strongly discouraged
<toabctl> hi all
<toabctl>  i try to cross-compile the kernel with: ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnu- make -j4 zImage
<toabctl> /usr/bin/arm-linux-gnu-ld: no machine record defined
<toabctl> /usr/bin/arm-linux-gnu-ld: no machine record defined
<toabctl> make: *** [.tmp_vmlinux1] Fehler 1
<toabctl> ^^ that is the error.
<toabctl> any idea what the problem is?
<amitk> apw: do we have a way to tracking future concerns for the kernel?
<smb> amitk, Future concerns?
<amitk> bug 426280 might contain a patch that we might want to pull in for k+1. How do we log it so it isn't lost in the ether.
<ubot3> Malone bug 426280 in linux "On ARM platforms with write-allocate caches, I-cache may be populated with garbage after copy-on-write page duplication" [Undecided,Invalid] https://launchpad.net/bugs/426280
<smb> Not sure whether this has been done before but probably a blueprint might be used for things like that
<amitk> smb: Blueprints has too much overhead. I was thinking of a wiki page listing features that we are keeping an eye on for the future (along with links to patches, discussions, bug number, etc.)
<smb> In the end the blueprint for the review of non-upstreamed code ends up similar. As the documentation is in the spec wiki... And the blueprint is just to let you not forget the spec exists ;-)
<amitk> hehe
<tjaalton> smb: hey, you released a new l-u-m for hardy which includes a pci-id for an intel lan device we need, but is it usable from the netboot installer?
<tjaalton> aiui it isn't
 * smb tries to remember what aiui was...
<tjaalton> "as i understand it" :)
<smb> tjaalton, But for the new drivers they should have been added to config to get into the udebs
<smb> tjaalton, Ah, thanks. :)
<tjaalton> it would be nice to allow new pci-id's for lan cards to the proper kernel, since the netboot environment is useless unless the booted kernel supports them
<smb> tjaalton, Maybe you could try it with the proposed version. I had test version where I forgot to add it into the udebs.
<tjaalton> it has happened twice for us, getting new hw that dapper/hardy didn't support 6mo after release, and it wasn't worth the effort to get it supported before the next release :/
<tjaalton> smb: but it can't load the udebs
<tjaalton> since there is no network
<tjaalton> or?
<smb> tjaalton, Hm, I urgently should get a bit more time to play with the netboot stuff. But were would it get any drivers from?
<smb> It probably needs to get into the initrd there...
<tjaalton> smb: right
<tjaalton> there are ways to work around it, but none of them is "nice"
<tjaalton> we are using jaunty now anyway, but these machines have intel gfx on them, and that's not working too well ;)
<smb> tjaalton, So I need to find out who prepares those pieces...
<tjaalton> smb: yes, I'm not sure if building the d-i images pulls in l-u-m modules too.. but if it does that's great
<tjaalton> I think cjwatson is responsible for building the images?
<cjwatson> tjaalton: cdimage team
<cjwatson> (which includes me, but is not limited to me)
<cjwatson> d-i doesn't include l-u-m at the moment, AFAIK
<cjwatson> um, let me check that
<smb> cjwatson, At least we have a debian/d-i/modules/ubuntu-modules in LUM
<cjwatson> yeah, that doesn't mean it's in the initrd. let me check though
<cjwatson> oh, sorry, mistaken, it is
<cjwatson> should just be a d-i reupload then
<smb> cjwatson, So the udebs are pulled through tftp in the netboot installer? (trying to understand the connections better)
<cjwatson> the initrd is built statically on the buildds
<cjwatson> other udebs not in the initrd are fetched using http or ftp
<cjwatson> (at run-time)
<cjwatson> the purpose of the initrd is to include enough bits for the installer to start up and fetch more bits of itself
<smb> Ah, ok. So network modules is something sensible to have in there
<cjwatson> yes
<cjwatson> but the set of udebs that's included varies depending on the initrd type
<cjwatson> the initrd included on CDs doesn't need network drivers
<cjwatson> that's why the kernel spits out lots of udebs, to give d-i flexibility
<smb> What defines what goes in there. I presume some configuration outside the kernel package
<cjwatson> debian-installer/build/pkg-lists/...
<cjwatson> let me know once the new l-u-m has built and is in the archive, and I'll upload d-i
<smb> Ah, ok. So I can look in that when in doubt about what goes in or not. Thanks. Let me quickly check that
<cjwatson> build/pkg-lists/netboot/i386.cfg:7:ubuntu-modules-${kernel:Version}
<cjwatson> etc.
<cjwatson> (actually, ubuntu-modules goes in both cdrom and netboot; the split isn't very good, but it isn't worth changing now since ubuntu-modules is no longer in karmic
<cjwatson> )
<smb> They wait in binary NEW atm
<smb> cjwatson, True. Thanks for the info.
<cjwatson> smb: processing
<Keybuk> when I get a kernel panic, the system kexecs into a new kernel
<Keybuk> is that because I have some package installed, or is that installed by default now?
<AnAnt> amitk: Hello, thanks for the CONFIG_USB_DEVICEFS , I have a question though, you suggested that software should otherwise use libusb instead of usbfs, right ?
<smb> I would think this is a crashdump feature
<amitk> Keybuk: i believe that is desired behavious due to crashdump
<amitk> AnAnt: yes
<Keybuk> amitk: but we don't have that enabled by default, right?
<AnAnt> amitk: but the README.Debian of libusb-0.1-4 says:
<AnAnt> libusb uses a pseudo-filesystem known as 'usbdevfs` or 'usbfs` to access
<AnAnt> the USB devices connected to your machine.
<amitk> Keybuk: I think we do. lieb worked on it last IIRC.
<Keybuk> amitk: eep
<Keybuk> there's something of a critical bug with it
<Keybuk> it mounts the root filesystem
<AnAnt> am I looking at a wrong libusb ?
<Keybuk> without any regard to the contents of the system or hardware clock
<amitk> AnAnt: http://libusb.sourceforge.net/api-1.0/ is the right one.
<kervel> hi, i'm trying to roll my own linux-backports-modules-karmic (i'm trying to find a solution for ath9k problems that are in karmic since july)
<kervel> and i'm trying to disable rfkill and dynamic power management for now ... so i changed config.mk and commented out some code. but i'm not sure if this is the right thing to do (is config.mk used ?)
<kervel> if i look with iwconfig powermanagement is still enabled even tho i disabled the DEFAULT_PS option..
<AnAnt> amitk: thanks
<kervel> https://bugs.launchpad.net/bugs/378156 <-- this bug (and its duplicates)
<ubot3> Malone bug 378156 in network-manager "UNR Ath9K unstable connection" [Undecided,Confirmed] 
<smb> kervel, If you want to change configuration options, you need to change in debian/config/...
<kervel> smb: but these files are all empty ...
<smb> kervel, Just saw that. That was where they *used* to be... 
<kervel> i grepped the entire thing for CONFIG_CFG80211_DEFAULT_PS ... only found config.mk
<kervel> and then another question: now i do it by downloading the source, then replacing the compat-wireless-2.6 folder in it by the one i got from git .. but is there a way to track the entire thing in git ?
<smb> kervel, git://kernel.ubuntu.com/ubuntu/ubuntu-karmic-lbm.git
<smb> kervel, It looks like it uses config.mk in some way. Though there are some scripts involved too
<smb> rtg might know better
<kervel> :)
<kervel> i'm trying to find out how to change the kernel config in linux-backports-modules-karmic (found config.mk but not sure)
<rtg> smb, you can't ask me questions in the first 13 seconds after I sign on
<smb> rtg, Sorry I know thats a bit mean
<rtg> kervel, look under debian/config
<kervel> rtg: everything empty there
<rtg> huh
<smb> kervel, It seems config.mk is the most likely place
<kervel> yeah, or it would be magic
<rtg> kervel, oh, right. for compat-wireless config.mk is where stuff is enabled.
<kervel> ah ok ... thanks. i wonder if there is a way to see if my config changes really changed something (they didn't workaround the bug for sure, but i wonder if that is because something messed up in the build or because it is just not related to the bug)
<kervel> i disabled CONFIG_CFG80211_DEFAULT_PS (because somebody hinted this could cause unstable ath9 connections) but iwconfig still shows power mgmt
<smb> kervel, Does it show it enabled or just available?
<kervel> it shows "on"
<kervel> and on my jaunty box (where ath9k is working fine after installing lbm) it is showing "off"
<smb> kervel, Hm, ok. There is also a default ps level... did you touch that too? (probably unset it)...
<smb> Not sure how good this compat-wireless env is at resolving dependencies...
<kervel> i always did full rebuild
<kervel> with pbuilder
<kervel> so i guess it won't be dependencies
<smb> kervel, Sorry, what I meant is that CONFIG_DEFAULT_PS_LEVEL=1 might still cause something even if CONFIG_DEFAULT_PS=n is set...
<kervel> the level i set to 0, i should try to unset it
<rtg> zul, do you have a bit to smoke test the ec2 kernel I built?
<zul> rtg: i might smoser would be a better person to ask though
<rtg> zul, k, I'll track him down.
<smb> kervel, Actually this like makes the build fail. Comparing this to the stock kernel the default value is 1 if set and 0 if unset. So, in theory you should have done the right thing
<kervel> smb ok then i'll abort
<kervel> but still i wonder why it keeps saying that power management is enabled... maybe the mac80211 stack is not part of the lbm ?
<smb> kervel, In the past it was prefixed with lbm_cw_ to keep is apart from the kernel version. But that might be different
<kervel> you mean the module object file ?
<smb> Those for commonly used modules, yes. But I must check
<kervel> i grepped for lbm_cw_ in /lib/modules ... no results
<kervel> so i guess it has changed
<kervel> and the generated deb file really contains ath9k.ko
<smb> Yes, looks like it only changes some firmware file names
<kervel> anyway, i'm unsure what to do next. i'm willing to invest some time in trying to get these problems solved, the problem seems to affect a big part of the ath9k users, also on other distributions (fedora and mandriva i found, and the bug is also in kernel bugzilla) but seems i ran out of things to try
<smb> kervel, I see you have added some references to upstream bugs. If one is a good match you might work with Luis directly (potentially open a new one if the other don't look close enough)...
<kervel> smb you mean upstream ?
<kervel> sorry, i have no idea who Luis is ..
<smb> kervel, Yes
<smb> Luis R Rodrigues (from Atheros)
<kervel> ah ok..
<kervel> let me try with the existing ones first
<tjaalton> smb, cjwatson: thanks! (got distracted for 2h..)
<smb> kervel, Yes this might be most promising. Also I saw on some something about instructions to gather debugging data. That might be helpful too
<cjwatson> Keybuk: I thought that got handled over to mvo
<cjwatson> Keybuk: https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-linux-kernel-crash-dump
<Keybuk> maybe
<Keybuk> you have to install kernel-crashdump which doesn't look like it's in by default
<Keybuk> anyway, it will screw over your filesystem clock ;)
<Keybuk> (if your hardware clock is in localtime)
<amitk> ogra: lool: perfect! Thanks.
<lool> cool
<ogra> :)
<mxzypltk> anyone have luck with installing latest e1000e intel drivers on 9.04?  readme states it cant be compiled and has to use modprobe.  Im able to assign ip and ping but disappers with reboot...    
<hyperair> imo find some way to get it to use dkms
<mxzypltk> yeah - im just soo close.  need to use it for a capture card.  and the lack of support making me crazy.
<jjohansen> Alright, running a bit late here
<jjohansen> For those interested in UEC/EC2 this is the kernel status update
<jjohansen> Currently, karmic AMIs are running on an Intrepid kernel
<jjohansen> we have built and smoke tested a vanilla 2.6.31 kernel
<rtg> jjohansen, any luck getting the Karmic ec2 branch to run?
<jjohansen> rtg: it was still building a minute ago
<jjohansen> rtg: has kindly packaged the 2.6.31 kernel changes to the Karmic kernel
<rtg> jjohansen, how will we know if its stable? Is there some kind of testing that we can run?
<jjohansen> rtg: first test is just smoke testing, do we get console, can we log in
<jjohansen> then there is a round of testing the server team performs, on various services
<jjohansen> testing long term stability is going to require keeping an AMI up and testing those services over time
<rtg> jjohansen, and the server team is onboard to run those tests?
<jjohansen> rtg: I am unsure of when they will run them, but when we have a smoke tested kernel, we can hand it over to them to start test
<jjohansen> s/test/testing
<jjohansen> I think they will just hit a subset or the tests at first
<jjohansen> I know smoser has been playing with the vanilla 2.6.31 kernel aki
<rtg> jjohansen, ok, how about dropping a  note to the k-t list when you have an Ubuntu kernel booting?
<jjohansen> rtg: will do
<Kano> hi, could you pull latest updates from git? they fix especially problems with intel drm
<Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e6890f6f3dc2d9024a08b1a149d9bd5208eea350
<Kano> that patch finally fixes a stupid problem in .31 since ages
<rtg> Kano, we'll pick those changes up when final is released.
<rtg> bjf-afk, should I be expecting a pull request for Dove ?
<bjf> rtg, yup, still recovering from trashing my laptop, should have it tested real soon now
<rtg> bjf, no rush on my part
<bjf> rtg, in the next 30 min or so
<amitk> cking: know of any cmdline tool to interpret /dev/input/event* ?
<bjf> rtg, understand, but I want to get it in and a build started
<cking> amitk, not off the top of my head. 
<cking> smb, ^^ amitk's question?
<smb> Hm, lsinput only lists some attributes... no me neither
<cking> amitk, http://smackerelofopinion.blogspot.com/2009/08/input-utils-package-are-bunch-of-tools.html
<cking> input-events perhaps?
<robbiew> cking: do I need to open a bug for the -10 kernel not suspending issue...or is that already "in the books"?
<rtg> robbiew, bluetooth?
<robbiew> yes...on my laptop
<robbiew> but I don't think it's on my mini9...and seeing there too..let me check
<rtg> robbiew, try 'sudo rfkill block bluetooth', then suspend (just to be sure)
<cking> robbiew, this is new to me (or my memory is going)
<robbiew> rtg: no change
<robbiew> only thing that happens is wireless resets
<rtg> robbiew, ok, sounds like a new bug
<robbiew> will open
<smccl__> test
<Kano> rtg: you have got out of tree changes in your git that conflict with the latest fix
<Kano> in the intel drm
<rtg> KanI imagine apw will fix those when he gets round to rebasing.
<robbiew> rtg: bug 426906
<robbiew> fyi
<ubot3> Malone bug 426906 in linux "Suspend/Hibernate not working in -10 kernel" [Critical,Confirmed] https://launchpad.net/bugs/426906
<Kano> well thats one of the issues with that bug, but not all ;)
<amitk> cking: thanks. I'll try that
<cking> amitk, if it's not in my blog, it's not in my head :-)
<rtg> apw, if you would be so kind, please have a look at bug #426908 (to which I've assigned you). I seem to be having some infrastructure difficulties.
<ubot3> Malone bug 426908 in gnome-system-monitor "gnome-system-monitor crashed with signal 5 in _XError() (dup-of: 322445)" [Undecided,New] https://launchpad.net/bugs/426908
<ubot3> Malone bug 322445 in gnome-system-monitor "[Jaunty] System monitor crashed when trying to end a process (bluetoothd)" [Medium,New] https://launchpad.net/bugs/322445
<rtg> uh, that would be bug #426906
<ubot3> Malone bug 426906 in linux "Suspend/Hibernate not working in -10 kernel" [Critical,Confirmed] https://launchpad.net/bugs/426906
<cking> rtg, I'm not sure apw is around at the moment
<rtg> cking, well, I'm sure he'll see it eventually
<cking> when his migrane wears off
<rtg> jjohansen: I've ec2 kernels on my PPA if you're still waiting on a  build
<kilian______> hey there, i am using karmic 2.6.31 and looking for the sco.ko module - couldnt find it. But it used to be in the repo in older kernel-packages. Is it now compiled into the kernel or was it dropped?
<kilian______> ok, just got a hint from somedbody else, anyways thanks and bye
<jjohansen1> rtg, smoser: i386 EC2 test kernel up and smoke tested aki-f700e09e, ari-c900e0a0
<smoser> karmicified ? or from rtg's ppa
<jjohansen1> smoser: its my build of the topic branch, I am going to try the ppa now
<rtg> jjohansen1, did your build not work?
<jjohansen1> rtg: no it worked, but it took a few tries with EC2, I wasn't getting anything to connect at first.  Not even the stock alpha5 ami
<jjohansen1> even with the user data field being passed
<jjohansen1> rtg: and EC2 has been real slow for me today
<rtg> jjohansen1, do you think its an issue with the kernel, or some transitory infrastructure problem?
<jjohansen1> rtg: infrastructure, it wasn't just our kernel.  But every one I tried
<rtg> jjohansen1, please update the bug report with your test results.
<jjohansen1> rtg: will do
<rtg> bjf, mvl-dove is building
<billybigrigger> hey all, anyone alive to answer a question?
<billybigrigger> why are ubuntu's kernel version's different from upstream? i noticed that upstream 31-rc9 was released and days before ubuntu already had 31-10 released
<billybigrigger> how does this work?
<rtg> billybigrigger, the package version is unrelated to the upstream kernel version
<billybigrigger> ok, so what are some good sources to follow ubuntu's kernel?
<billybigrigger> i usually follow linus' git tree...kernel.org
<billybigrigger> does ubuntu have anything like that for it's kernel?
<rtg> billybigrigger: http://kernel.ubuntu.com/git or git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git
<billybigrigger1> ahhh thanks
<kervel_> hi smb, i built the ath9k packages again, and now iwconfig shows power:off. i have really absolutely no idea why it now shows power:off
<kervel_> the only thing i could think of is that i rebuilt the deb quite a few time without updating the version number. maybe pbuilder doesn't like that or so
<bjf> rtg, thanks for the build
<billybigrigger1> does anyone here work with the v4l2 gspca kernel modules?
<billybigrigger1> my webcam hasn't worked throughout this whole .31 cycle
#ubuntu-kernel 2009-09-10
<mdomsch> superm1, around?
<superm1> mdomsch, yeah
<superm1> whats up?
<mdomsch> nothing major, just noting the last dkms commit wasn't quite complete; you need to update Makefile too, as that's what's generating .orig.tar.gz
<mdomsch> (I think)
<superm1> mdomsch, you mean http://linux.dell.com/git/?p=dkms.git;a=blobdiff;f=Makefile;h=68d1ba0c000da1ac3a1fc5ecdee2ddf3e43079e9;hp=6f082bc43115d2c5765d9b20a3cf0102c0364dd3;hb=055aa92dd408938e284c7559fb0b3691f68b124a;hpb=d6b4e7f6199b741e7d236195dedb1095d76088e2 ?
<mdomsch> no. the permalink is still named .orig.tar.gz
<mdomsch> but the git commit says it's not .orig
<superm1> oh both are being generated actually
<superm1> they should realistically be symlinks of one another, but that's a build bug
<mdomsch> ah.
<mdomsch> the .orig is the only one in the permalink/ dir
<superm1> nope, they're both there
<superm1> http://linux.dell.com/dkms/permalink/dkms-2.1.0.1.tar.gz
<mdomsch> ugh; sure enough.  bad eyes.
<mdomsch> dashes and underscores
<superm1> yeah, it's easy to miss
<mdomsch> sorry for the noise then
<cooloney_> ericm_, can access the kernel team page on wiki.ubuntu.com?
<ericm_> cooloney_, wait
<mvo> has anyone had a hang on "pci 000:00:00.0: Found enabled HT MSI Mapping" on a amd64 at boot? I get this regularly (the line is repeated 10 times
<ericm_> cooloney_, I can access the page
<cooloney_> ericm_, thanks, i can now, it is very slow
<Kano> hi, when will the tree be rebased on .31 final?
<ogra> before kernel freeze :P
<Kano> i am waiting for it
<apw> Kano, when its tested as always !
<ogra> so wait a little more then ... 
<Kano> apw: i tested vanilla kernel, it fixes my intel problems
<apw> what intel problems you seeing?  
<Kano> without kms it crashed on vt switch or X shutdown. well in the kernel log it is shown as suspend fix, as this was triggered then too even when kms was used
<Kano> just before the .31 release
<ogra> whats the bug # ?
<Kano> ogra: i use a slightly different kernel config with those KMS entries not set
<apw> Kano, ahh gpu hangs on suspend/resume perhaps?
<Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e6890f6f3dc2d9024a08b1a149d9bd5208eea350
<apw> that could well be my 'gpu hang' on attempting to suspend then
<cooloney_> apw, if a config option depends on CONFIG_BROKEN, does that mean the config option is broken?
<apw> it means that they don't believe that that support works yes
<cooloney_> apw, if i want to enable that config option, where can i enable CONFIG_BROKEN firstly?
<apw> i don't think you can, i think you'd have to patch it to not have that
<cooloney_> apw, yeah, thanks, i did the dirty things just remove the dependence of BROKEN. and build the kernel for some testing
<apw> yeah pretty sure you'd not want to turn on BROKEN it would likely turn on a lot of stuff
<cooloney_> apw, for boardcom BCM4312 wifi device, i found we have 2 drivers
<cooloney_> apw, one is open source b43 driver but it needs to enable to support low power phy on my platform
<cooloney_> apw, and the other is BCM STA driver which is close source, it also has some problem.
<cooloney_> apw, do you know which is more popular? i don't think I can debug the STA driver 
<apw> yeah have no idea.   a problem indeed.  the open source one is easier to fix clearly as we can see it
<apw> but BROKEN is not encouraging
<Kano> cooloney_: many kanotix users use the sta with a little dkms script
<Kano> patched to work up to .31 using gentoo patches
<Kano> cooloney_: http://kanotix.com/files/fix/dkms/broadcom-wl-dkms.sh
<cooloney_> Kano, thanks, since i have 2 candidate to test, I will try the b43 driver firstly. 
<Kano> try if you like
<cooloney_> Kano, thanks a lot
<cooloney_> Kano, i will try that
<Kano> well the wl driver is needed for some devices which are not supported by the other one
<rtg> apw, did you get a chance to repro the suspend failure with -10 on your mini-10?
<apw> seems to work on my -10 ...
<rtg> drat
<apw> rtg though i think i know which fix fixes the issue, and i think its in linus v2.6.31
<apw> am test building the rebase now, its so minor its not even an abi bump
<rtg> are all of the suspend failure machines based on Intel graphics?
<apw> i cannot tell as yet, i have asked in the bug
<rtg> apw, ok, thanks.
<apw> should have a kernel for testing pretty soon, and if i've done it right ready to upload too
<apw> rtg i presume our .orig files are simply linus' tarball from www.kernel.org
<rtg> apw, yep
<apw> cool
<apw> rtg, can i confirm that the virtual image should be happy with grub-pc as a bootloader same as all the other images
<apw> seems it got missed in the conversion
<rtg> apw, I think we should ask zul
<apw> rtg damn he isn't about, and its in my tree rght now... hrm to pull it or not to pull it
<Kano> apw: when do you commit the new kernel?
<apw> likely today sometime ...
<Kano> will you add ati r600 kms/3d patches later
<apw> not sure we know as yet what if any ati patches we need
<Kano> well in #radeon they told me tomorrow or so they will update em again
<Kano> for fedora
<Kano> airlied of course
<apw> indeed so
<apw> i rely on our X peeps for guidance on that side
<Kano> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/392039
<ubot3> Malone bug 392039 in fglrx-installer "initramfs scripts hard-coded to load i915; blocks loading fglrx" [Undecided,Confirmed] 
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138
<ubot3> Malone bug 380138 in linux "Do NOT disable HPA by default -> leads to data loss" [Medium,In progress] 
<Kano> whats the status on that
<apw> why would loading i915 block loading of fglrx
<apw> regardless of it being stupid
<Kano> well older drivers are blocked, not that 9.10 driver, but olders are
<Kano> basically you could check for the /sys entry for drm if kms is used
<apw> as far as i know that is being worked on
<apw> i think its completely redundant
<Kano> yes, the modprobe too because thats a think of udev
<Kano> udev loads it anyway
<Kano> why was the hpa setting not reverted? if it is stored in the hd you just have to tell the ppl to use hdparm
<Kano> the -N option can set it temporary or permanently
<Kano> if you use -N pSECTORCOUNT then it is permanent
<Kano> if somebody has a 32 gbyte limit he should  just check the jumpers on the hd
<Kano> absolutely pointless to remove hpa by default
<Kano>  max sectors   = 1953525168/1953525168, HPA is disabled
<Kano> when you check with -N
<Kano> and then set a lower number than the max then HPA is enabled
<Kano> maybe add a little wiki page and point those few users to that
<Kano> for all others it is critical to remove it as they could overwrite data which is overwritten by the bios
<Kano> and especially raid systems will fail when it is removed till full poweroff
<apw> we decided on a hybrid approach, but its not yet there, slipped thorugh the net
<apw> rtg, ok the general feeling on #u-server is that grub2 is completely reasonable addition...
<apw> Kano, the initrd stuff is ongoing, still on target for karmic
<Kano> you dont need  hybrid appoach, just teach your users how to get rid of hpa
<rtg> apw, looks good so far as I can tell. upload it
<apw> ack
<apw> rtg, do we announce non-abi bumping uploads?
<rtg> apw, not normally, but you could still announce that this is the last rebase, blah, blah...
<apw> fair point will do
<jjohansen> time for the UEC/EC2 kernel status update
<rtg> jjohansen, what do we know since yesterday?
<jjohansen> we have some testing from a couple users
<jjohansen> Eric Hammond is one of them
<jjohansen> I repushed the aki, and ari's last night with more descriptive image names
<jjohansen> as Eric suggested
<rtg> has he had any success or failures?
<jjohansen> yes, the kernel has been reported as booting
<jjohansen> there have been failures with modules, but that is expected as the ppa needs to be installed to get the new modules for the kernel
<rtg> how about runtime stress? there are huge changes in the VM core for Xen wrt 2.6.31
<jjohansen> There has not been any run time stress testing that I am aware of yet.
<rtg> jjohansen, so what does Eric need from us in order to facilitate his test efforts?
<jjohansen> He has asked for more descriptive AKI, ARI names (done)
<jjohansen> and PPA so he can install modules
<jjohansen> both are available
<rtg> jjohansen, assuming the ec2 source package gets uploaded soon, then he can likely use that?
<jjohansen> yes
<rtg> from the main archive, I mean
<jjohansen> right, he just needs a source for modules
<rtg> ok, anything else worthy of note?
<jjohansen> not that I am aware of
<rtg> jjohansen, maybe we should be having this on #ubuntu-server 'cause there are more folks in that channel that might care about ec2
<jjohansen> rtg: I will run that past smoser, zul and if they agree post out a mail
<rtg> jjohansen, good, meeting adjourned?
<jjohansen> yes, I think so
 * smoser reads backscroll
<smoser> soryr i wasn't here earlier, i mistook GMT and UTC
<jjohansen> smoser: you agree with moving this little meeting to #ubuntu-server
<smoser> sure
<jjohansen> smoser: heh, sorry my bad should have sent out as UTC
<smoser> so, above you brought up 2 things
<jjohansen> smoser: would an hour later be better for you
<smoser> i say move to #server tomorrow
<smoser> doesn't matter this is fine. just didn't translate.
<smoser> anyway
<smoser> so 2 things
<smoser> 1. modules
<smoser> the one issue that people had there was with CONFIG_LOOP=m. it is solvable, and i posted how to solve it to the bug.
<smoser> but i think we want the configs as much as possible to model the normal server configs
<jjohansen> right, I saw that. thanks
<smoser> (maybe that is the case with the server, but my -generic shows CONFIG_LOOP=y)
<rtg> smoser, since the ec2 kernel is a separate source package we can make the config options different then the master branch kernel.
<smoser> i'd just like to have 'ubuntu-on-ec2' as much as possible "just like" ubuntu-server
<smoser> rtg, i'm saying that even if we can, i think in general we should not
<jjohansen> smoser: okay will look at the configs and see what else jumps out
<rtg> smoser, no problem here.
<smoser> jjohansen, kexec i know of... but that is just a personal interest as i'd love to try kexec updating my kernel :)
<smoser> so, lets try to make the configs as similar as we reasonably can
<smoser> 2.) second thing is naming on ec2
<smoser> i'm wanting to put together a doc on how we should name things what buckets to use.  in the past we've been wildly inconsistent.
<smoser> one thing that stinks is that its a global namespace, and if we say we're going to use 'canonical-kernels' and someone jumps in and takes that bucket name we get screwed :)
<rtg> smoser, will this affect the source package name? or is this an Amazon thing
<smoser> i think amazon thing only
<rtg> smoser, before I write the MIR, do you want to change the name from ec2 to uec?
<smoser> thats not really a problem with the single name, but if there are limits to the contents of a bucket (apparently at least there were size/number-of-files limits) and we used canonical-kernels-XX, someone could grab future names.
<zul> traditionally everything has been uploaded to canonical-cloud-{us,eu}
<smoser> zul, possibly its just an issue with different people (you, soren, me) (probably mostly me) doing it
<smoser> but i just would like to have consistent naming everywhere.
<zul> and traditionally ive called them vmlinuz-2.6.xx-yy-<arch>
<smoser> rtg, this is a 'ec2' kernel. not related to uec (well, unless they're doing uec on xen...and very old xen, but i dont think that is likely supported)
<smoser> zul, ill make sure that i look at what you've used in the past
<jjohansen> rtg: we should consult with mdz on the name
<smoser> sure, thats fine. but it really is an ec2 kernel.  the uec kernels people will use will likely be -server based (or -virtual)
<rtg> jjohansen, why? did he have a strong opinion? Its not like this kernel is gonna work anywhere other then Amazon or CenOS 5.0
<jjohansen> rtg: there was some strong opinions expressed a few weeks ago
<jjohansen> rtg: just want to double check before we commit
<smoser> well, using uec here would be confusing
<smoser> as most uec would be kvm (full virt) and this thing wouldn't boot
<zul> rtg: no necessarily the xen hypervisor is backwards compatible
<rtg> zul, hmm. I'll ask the question of the key players in email
<zul> rtg: sure
<Q-FUNK> re
<Q-FUNK> ogasawara: is there anything else I can do with bug #396286 ?
<ubot3> Malone bug 396286 in linux "2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
#ubuntu-kernel 2009-09-11
<eltoozero> hi guys, trying to file a bug, need to figure out which package is appropriate, a little help?
<jjohansen1> eltoozero: what kind of bug
<eltoozero> bug #420363
<ubot3> Malone bug 420363 in gnome-bluetooth "[eee 901][karmic]system freeze when toggling wifi while bluetooth disabled" [Undecided,New] https://launchpad.net/bugs/420363
<eltoozero> as you can see I originally filed as bluetooth
<eltoozero> but it happens when wifi is toggled, but only after bt is toggled.
<eltoozero> there is a video of the freeze attached to the bug.
<eltoozero> full freeze, black screen, a console cursor and mouse cursor remain.  REISUB is ineffective, full shut down required.
<eltoozero> I was just now directed from #ubuntu-bugs to inquire here, michag suggested I check syslog to see if there is wisdom to be gained there
<jjohansen1> eltoozero: kernel is the linux package
<eltoozero> yes, what can I do to establish if this is a kernel related issue?
<eltoozero> I suppose the alternative would be the rt2860, or bluetooth, that's what I need help with.
<jjohansen1> eltoozero: if it is a full freeze it is at least partially kernel related, even if it is a driver
<eltoozero> jjohansen1, ok cool, what can I do to help?
<jjohansen1> eltoozero: hrmm can you trigger it using rfkill from a vt?
<eltoozero> that's something to try; for clarification, by vt you mean ctrl-alt f1
<jjohansen1> yes
<eltoozero> cool, I'd like to see if anything shows up in syslog as well, I'll test that, thank you.
<jjohansen1> doing it from the vt console if rfkill triggers the bug we might get a trace back
<eltoozero> brb, reproducing freezes is fun. :)
<eltoozero> hang on now, when I do an rfkill list, I get two bluetooth adapter entries...
<eltoozero> eeepc-bluetooth: Bluetooth, and hci0: Bluetooth
<mjg59> That's normal
<eltoozero> thank you mjg59, on to the crashing.
<eltoozero> of course it works fine from vt...
<eltoozero> the problem is triggered from the fn-f2 hotkey, at least that's how I've been reproducing it
<eltoozero> if I can only get it to happen via that method, and not via rfkill, what does that indicate?
<jjohansen1> that rfkill isn't the problem :)
<eltoozero> so, reproduce the way I know how and check syslog I suppose would be the next logical step?
<jjohansen1> yes
<jjohansen1> though if it is a full freeze I don't expect anything will make it to the log
<jjohansen1> eltoozero: when you tried the console, did you try getting bluetooth into an unknown state via graphical interface and then switching to console and using rfkill
<eltoozero_> jjohansen1, nothing in syslog before the reboot
<jjohansen1> eltoozero: when you tried the console, did you try getting bluetooth into an unknown state via graphical interface and then switching to console and using rfkill
<eltoozero> yes
<eltoozero> unintentionally, it was in the unknown state to begin with
<eltoozero> the rfkill toggle does not affect the unknown status of the adapter as shown in the indicator applet
<jjohansen1> okay, so the question becomes what is different between using rfkill on the console and the hotkey
<eltoozero> on top of that I can't always reproduce the unknown status on the adapter, it will freeze even if it is reporting on/off correctly, bluetooth just has to be toggled.
<jjohansen1> eltoozero: yes but it does show something is broken in the driver
<jjohansen1> eltoozero: can you include the command that is invoked by your hotkey
<eltoozero_> jjohansen1: on a different box so I don't drop myself like a fool
<jjohansen1> eltoozero: hrmm, this could also be a bias issue
<jjohansen1> s/bias/bios
<eltoozero_> k, hit me.
<jjohansen1> fn+f2 will kick would be bios/acpi
<eltoozero_> I'm running the most updated bios for my hw, I can disable bt in the bios and when I boot it's recognized as such
<eltoozero_> initially I tried shutting wifi/bt off in the bios, enabling via gui, then shutting off to reproduce the bug
<eltoozero_> everything works until that last wifi disable, but it does disable
<jjohansen1> right, what I mean is it might not be playing nice with the driver
<eltoozero_> access the bios right after the crash, it's disabled.
<eltoozero_> I did find this previously, https://wiki.ubuntu.com/Hotkeys/Troubleshooting
<jjohansen1> eltoozero_: hrmm I found a couple other references to fn-f2 freezing the machine
<eltoozero_> it appears the key is generating the XF86WLAN event
<mjg59> rfkill may freeze Eees if you're using one of the broken vendor wireless drivers
<mjg59> They don't play nice with the PCI hotplug
<eltoozero_> sounds good, what would be a suggested workaround? locate a more appropriate driver?
<mjg59> Which driver are you using?
<eltoozero_> rt2860
<eltoozero_> can I be more specific?
<mjg59> Yeah that's the vendor driver from staging
<eltoozero> I see in the dmesg is says rt2860sta and "you have been warned"
<eltoozero> (love it)
<mjg59> rt2800pci doesn't seem to have been merged to mainline yet
<mjg59> Not sure what the situation is there
<eltoozero> mjg59: https://lists.ubuntu.com/archives/kernel-team/2009-July/006564.html
<mjg59> Yeah
<mjg59> So right now you're stuck with the broken driver
<eltoozero> hey, them's the breaks.
<mjg59> But I suspect that's your problem
<mjg59> And that if you unload rt2860 you won't be able to generate the hang
<jjohansen1> that would be my bet as well
<eltoozero> sounds reasonable, I'm sure it's really just a better idea to get a well supported wifi chip.
<mjg59> It should be reasonably supported in the not-too-distant future
<eltoozero> mjg59: where would I go to aid in that goal?
<mjg59> Searching linux-wireless may be your best bet
<mjg59> The mailng list
<eltoozero> cool, so the drivers that are included are likely _not_ the manufacturers drivers, because of copyright/firmware, correct?
<eltoozero> the question being, is it worth it to try their reasonably up-to-date source for the chip
<mjg59> The long-run plan is to have a rewritten driver that actually uses the Linux wifi stack
<mjg59> Rather than the vendor drivers, which don't integrate cleanly
<mjg59> rt2860 is a lightly cleaned up version of the manufacturer driver
<mjg59> rt2800pci will be the rewritten Linux one
<eltoozero> from the rt2800pci page it doesn't seem to indicate my chipset in their support list
<eltoozero> based on the following Ralink chipsets: rt2400, rt2500, rt2570, rt61 and rt73.
<eltoozero> but I totally follow you
<eltoozero> very helpful guys, thanks for all the info and guidance.
<eltoozero> mjg59, jjohansen1, keep up the good work.
<JanC> mjg59: do you mean that there is a tiny chance that there will be Ralink drivers that support multithreaded/multicore CPUs after all those years?  ;)
<mjg59> One hopes
<JanC> I've never had real problems to get them work on a P3, but IME anything like a P4, Core/Core2 Duo, etc. will magically work or not work depending on the system's mood today...  :-/
<JanC> (sounds like timing-based concurrency problems...)
<cooloney> ericm_, ikepanhc are you guys using grub2 in your karmic?
<cooloney> i did see any menu for me to select the right kernel for booting
<ericm_> cooloney, y
<ericm_> cooloney, did or didn't?
<cooloney> didnt
<ericm_> is that a fresh installation?
<ikepanhc> cooloney: not yet, I am still using grub to boot karmic kernel/filesystem
<ikepanhc> cooloney: you mean you can not find menu.lst?
<ikepanhc> cooloney: grub2 has different format and name
<cooloney> ericm_, yup fresh
<cooloney> ikepanhc, indeed
<cooloney> ikepanhc,  it should be the grub.cfg
<ericm_> cooloney, that shouldn't be
<ericm_> cooloney, my fresh installation here works perfect
<Q-FUNK> TheMuso: I notice that a while back you removed keyboard map hooks from initramfs.conf, stating that console-setup takes care of that.  now, where is the console-setup hoow to copy that keyboard map to initrd?
<cooloney> ikepanhc, but when i boot my machine, there is no such menu for me to pick up a right kernel
<ikepanhc> It is automatically generated by /usr/sbin/grub-mkconfig 
<cooloney> ikepanhc, great, grub2 config is right, but i did not see the menu selection screen
<cooloney> did you?
<ericm_> cooloney, then what did you see on your boot? And can you even boot into _one_ kernel?
<ikepanhc> cooloney: I am not using it, I still spend most of my time on Jaunty
<cooloney> ericm_, just booting into our splash screen, progress bar then enter gdm
<cooloney> very quick
<cooloney> ikepanhc, got it. 
<cooloney> i just wanna try an old version kernel. but the grub2 don't let me choose
<ericm_> cooloney, ESC doesn't help right?
<cooloney> ericm_, just tried ESC, too quick for me, i missed 
<cooloney> ericm_, booting too quick is a pain for developer, heh
<ericm_> cooloney, hammer on your desktop to slow it down
<bjf-afk> cooloney, if you hold the shift key you should get the grub2 menu (so I've been told)
<cooloney> bjf-afk, thanks god, let me try. bjf-afk  is every where, cheers
<cooloney> bjf-afk, i appreciate, shift works,
<bjf-afk> cooloney, from what I can tell *lots* of people are running into the same issue :-)
<cooloney> bjf-afk, i have to recode this shift trick into my Zim wiki notes, thanks, -:)
<hyperair> is anyone familiar with an issue where plugging in an earphone after resuming from suspend/hibernate does not mute the speakers?
<Q-FUNK> howdy!  what should we do about bug #396286 ?  we've narrowed down the exact upstream git commit that broke it and filed a bug upstream in their bugzilla.
<ubot3> Malone bug 396286 in linux "2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
<Q-FUNK> or actually, the first commit in a series of subsequent ones that made it difficult to simply revert one git commit.
<Q-FUNK> ogasawara helped me track down the exact commit but, at this point, we'd need people who actually know kernel internals to jump in and help LKML fix it.
<smb> Q-FUNK, Let me have a look at it
<Q-FUNK> smb: thanks! :)
<smb> Q-FUNK, Interesting. Seems atm only the nag-mails from Rafael come in. That patch that seems to break things looks nicely short... I try to sink into that a bit. But for completeness: what kinds of filesystems are involved? Only ext3, ext4, other?
<Q-FUNK> ext3
<Q-FUNK> well, it's not just one commit.  it's the first commit in a long series to implement.. was it ACL... in various filesystems.
<Q-FUNK> and indeed, no feedback except automated nag mails from Raphael.
<smb> Yeah posix acl... thingies
<Q-FUNK> or well, Ingo Molnar replied on LKML that he'd rather get the crash dump as plain text rather than a picture and then he left it at that.
<Q-FUNK> IIRC, AL Viro, who made those changes, was the one who said that he could not see how adding posix acl to /sys would make the kernel crash at bootup.
<smb> The interesting part is why does it only blow into your face... Which is always hard if that happens before you have something to write it to... A problem with the pictures often is that you miss the (more valuable) top part. Or parts as often there are more than one
<Q-FUNK> AFAIK neither of them bothered actually chekcing what my most recent snapshot shows.
<Q-FUNK> right
<Q-FUNK> here, to prevent that, I'm puposely booting with a huge framebuffer.  it fits more content on screen.
<Q-FUNK> 1280x1024, IIRC
<smb> yeah, this does not look bad and has the top of it
<smb> ok, sort of when cleaning an inode up.
<Q-FUNK> yup, right from the uname at the start of the crash until the cursor stopped flashing.
<Q-FUNK> somewhat tiny fonts, but I use a tripod to mount the camera, so the amoutn of fuzz is minimized.
<smb> Its definitely one of the better ones. My eyes do not burn while looking at it. :)
<Q-FUNK> and yes, it seems that it buggers on some inode.
<Q-FUNK> however, it's unclear to me whether it's an inode on the / filesystem in ext3 or something else.
<Q-FUNK> I cannot remember if it was Ingo or Al who suggested that this looks like a crash while mounting /sys
<smb> Let me spend a bit of time to think about it. It could well be that it is one of the virtual fs'es and maybe some other code that forgets to do things right. Somehow it must be something that is usually not used, otherwise everybody would see it
<smb> It might be helpful to know what is special on a Geode (never saw one)
<Q-FUNK> I could paste the cpuinfo
<Q-FUNK> It's basically a 586 with some extra more recent instructions, plus some amd-specific things
<smb> Its maybe not the cpu only but the system as a whole. Meh, not very specific
<Q-FUNK> should I paste fstab also?
<smb> Wait a bit with that. For the moment I guess there is reasonable evidence. If I think we need more I would as in the report...
<smb> Last sysfs file touched was sys/power/resume... thats also good to know
<Q-FUNK> ah.  acpi issue then?
<smb> Sorry, it might be somewhere in the report but have you tried with a busting version and acpi=off on the commdandline?
<Q-FUNK> busting version?
<smb> err, I was trying to say a kernel version that usually does not boot
<Q-FUNK> ah, right
<Q-FUNK> no, but I could try.  just a sec.
<Q-FUNK> still crashes
<Q-FUNK> noticed the line on top that says BUG: could not handle paging request at *****
<Q-FUNK> did something try to request tons of memory and barfed with a buffer overflow?
<smb> My suspicion would rather be (as it starts with that acl patch) that one of those pointers get set to something not -1 without being a real address and then are tried to get freed on destroy inode... But why needs a bit more meditation
<Q-FUNK> ok
<smb> Hm, actually you could do me a favour and get me the address of the first BUG that happens on the current karmic kernel -10.something. I just need the IP: ... (like __destroy_inode+...) Then I check this more exactly here
<smb> If you would add that info to the report I can check up later on
<ankur> is this where i can ask kernel related question...?
<Keybuk> apw: when's a good time to send you a kernel patch?
<apw> Keybuk, is there a bad time?  clearly if you want it in A6, its going to be tight
<Keybuk> sent to kernel-team
<Keybuk> it's a fairly critical bug fix
<Keybuk> and we need to test it first, to get the other half of the bug fix
<apw> Keybuk, what do you need?
<apw> a kernel with that bodged on, so you can test?
<Keybuk> yes please
<Keybuk> it's a fix for ext4 to not write the "last write time" field of the superblock when the filesystem is mounted read-only
<apw> that would be clearly against the spirit of read-only
<Keybuk> indeed
<Keybuk> (it's replaying the journal from an unclean shutdown)
<Keybuk> the problem is that it gets that time from the system clock
<apw> yeah i got hit by that 'your last mount was in the future, full fsck engaged'
<Keybuk> when the filesystem is mounted read-only on boot (by either the kernel or the initramfs), the system clock contains whatever was in the hardware clock
<Keybuk> and that's not necessarily UTC
<Keybuk> right
<Keybuk> this is the fix ;)
<apw> why we never hit it before?
<Keybuk> because Ted has blamed Ubuntu for the apparent clock issues
<Keybuk> saying we had "buggy init scripts"
<Keybuk> and he even included a hack in e2fsck that checked whether you were running on Ubuntu, and simply ignored the issue
<apw> sounds like ted :)
<Keybuk> I removed the hack, because we *don't* have buggy init scripts, because we spent a long time making sure they were right
<Keybuk> and then these bugs started showing up again
<mjg59> All problems exist in userspace
<Keybuk> it's refreshing to discover that they are actually kernel bugs in the ext3/4 filesystem code ;)
<apw> good on you for your being pig headed and stubourn :)
<Keybuk> the only reason they seemed to affect Ubuntu is because
<Keybuk> err
<Keybuk> we have users
<apw> hehe shhhh
<apw> everyone will want them
<mjg59> The real issue is how widespread having the clock in local time is
<mjg59> I suspect that's far more widespread with Ubuntu than most distributions
<apw> windows defaults to that
<mjg59> Quite
<Keybuk> anyone who dual-boots with windows will have it in local time
<apw> so any dual boot setup will have it
<Keybuk> it's probably true that we have more "ordinary users" who do such a thing
<apw> so we are more vunerable to it through that
<Keybuk> whereas other distros have a higher proportion of Linux purists
<apw> all true.  but a bug is a bug, and finding and squashing it is good
<apw> Keybuk, a PPA needed, or some downloadable .deb's enough for you for this testing
<apw> and if the latter, what arch is most useful so i can build that first
<Keybuk> downloadable is fine
<Keybuk> _i386
<apw>     that point, for people who are east of GMT and who make their clock
<apw>     tick in localtime for Windows bug-for-bug compatibility, and this will
<apw> nice description
<apw> Keybuk, that fix only fixes ext4 ... 
<Keybuk> yes, Ted would like to know whether this is the right fix
<Keybuk> if it is, he'll fix ext3 too
<Keybuk> apw: I know, I'm genuinely shocked
<Keybuk> I fully expected Ted to find *some* way to blame Ubuntu in the description ;)
<apw> Keybuk, you got a bug for this in LP ?  so i can use the number?
<Keybuk> do you know, we don't
<Keybuk> let me file one
 * apw slaps self for not filing one midnight now - 24hours when he hit it
 * apw waits with baited breath
<Keybuk> bug #427822
<ubot3> Malone bug 427822 in linux "fsck says last write time in future" [Undecided,New] https://launchpad.net/bugs/427822
<Keybuk> I've deliberately left an e2fsprogs task there since that's where people will look
<apw> very sensible
<apw> and close it won't fix there not invalid so it stays searchable
 * apw fires up the hoover
<Keybuk> I'll leave it open for now
<apw> yeah i meant in the long run
<apw> Keybuk, we likely have to get this done by monday eve to get this in the alpha
<Keybuk> yes
<Keybuk> this bug is pretty much hitting everyone
<Keybuk> so I think we should consider it critical for the alpha
<apw> ack ... i am sure you would have reason to get it by the freeze anyhow as its bad, but just stating the obvious
<apw> it takes soooo damn long to get a kernel these days
<Keybuk> sure, we can hold up alphas easy enough though :p
<Q-FUNK> smb: come again?
<smb> Q-FUNK, yep
<Q-FUNK> smb: what was it that you wanted me to add to the bug?
<Q-FUNK> smb: address of the first BUG?
<Q-FUNK> smb: ah, you mean the crash output? the first line that starts with BUG?
<smb> Just the address of the unhandled pointer reference with the latest ubuntu kernel
<smb> so I can have one compiled here with debugging info and check the exact location of the crash
<smb> right
<smb> but the line is that which starts with IP: ...
<smb> directly below of the BUG: line
<Q-FUNK> BUG: unable to handle kernel paging request at ffffb4ff
<Q-FUNK> this?
<Q-FUNK> ah
<smb> below that which was: IP: [<c01f716b>] __destroy_inode+0x4b/0x80
<smb> Mainly to check that it is still 0x4b and not moved to somewhere slightly off
<Q-FUNK> smb: added
<smb> Q-FUNK, Ok, thanks. Now I only need to have the compile done. Thanks so far
<mjg59> Keybuk: It'll hit far fewer after BST ends :p
<Keybuk> mjg59: :D
 * apw muses about online fsck, was it btrfs which did that?
<mjg59> softupdate FFS does
<mjg59> But softupdates are brain meltingly difficult
<apw> Keybuk, could we not have left the ted bodge in, but made it produce an message or something ... so we don't get hurt by it all the time?
<apw> you only care to know if you have stopped it occuring after all
<apw> and the pain level is very high from this thing
<apw> as an example your test kernels are off the table while my machine is rebooting
<apw> and its been fsck'ing for 20 mins already
<Keybuk> apw: karmic is not being released tomorrow
<Keybuk> I would rather fix this properly and *know* it's fixed
<Keybuk> rather than bodging out the error just for people running an unreleased version ;)
<apw> but the fact is just print a vile error when the bodge was applied would give you just the same information and not mean i lose an hour every tiem i915 breaks
<Keybuk> no it wouldn't
<Keybuk> because the vile error isn't printed
<Keybuk> there's a splash screen in the way
<apw> heh for you maybe ...
<Keybuk> if you want to bodge it for yourself, just stick that buggy_init_scripts thing back
<Keybuk> zelda scott% cat /etc/e2fsck.conf 
<Keybuk> [options]
<Keybuk> 	buggy_init_scripts = 1
<apw> oh it still in there excellent
<apw> will do that given the massive instability i seem to have today
<apw> Keybuk, that patched kernel is now available at: http://people.canonical.com/~apw/lp427822-karmic/
<jjohansen1> the EC2 kernel status meeting has been moved to #ubuntu-server and will start at 16:00 UTC (ie. 2 min)
<Q-FUNK> smb: thanks! what should I pay attention to when I boot your test kernel?
<smb> Q-FUNK, As I don't hope much its a double free it likely just runs into the bug again with just a slightly different address.
<smb> If it boots, then you would see WARNINGs in dmesg...
<Q-FUNK> ok
<smb> I try to make a v2 that juggles around with the structure elements. So if something blindly writes it should then hit the same private pointer as before... but that I have to build
<Q-FUNK> lemme grab my camera and ake a snapshot of that one.
<smb> Q-FUNK, No worries about a picture
<smb> If its still the same bug
<Q-FUNK> smb: result pasted
 * smb looks
<smb> Ok, I nearly expected that. I am building another one right now and will upload it as soon as it is done.
<Q-FUNK> ok
<Q-FUNK> I'll wait for that and test it.
<erichammond> pgraner: Did the weekly Karmic meeting displace the daily EC2 kernel meeting today?
<smb> Q-FUNK, Ok, its uploaded. A little warning, as I cheated a bit with the abi number, external modules (including dkms) get confused. So if using nvidia or fglrx for example, those fail to load.
<rtg> erichammond, jjohansen1 bodged the meeting time and is now at the dentist
<apw> erichammond, i think the EC2 meeting is at the top of the next hour
<apw> oh perhaps not
<rtg> erichammond, the only significant kernel issues that I'm aware of is the 4gb i386 trap warning. smoser is supposed to try an image with libc6-xen
<rtg> apw, were you able to test 'ext4: Don't update superblock write time when filesystem is read-only' ?
<apw> rtg, i added the patch to a kernel for Keybuk ... 
<apw> Keybuk, did you manage to test it yet?
<rtg> apw, weren't you suffering from it?
<smoser> we can do it whenever (the meeting) and as far as i am aware the only issue is bug 427288 (4gb i386)
<ubot3> Malone bug 427288 in linux "Karmic i386 EC2 kernel emulating unsupported memory accesses" [High,Triaged] https://launchpad.net/bugs/427288
<apw> i was in the sense that i hit it on reboot yes
<apw> but when i do hit it it takes 40 mins to recover, and i was in the release meetings :/
<erichammond> okeydoke.  I was asked to attend the meeting, so I set my alarm a couple hours early :-/
<erichammond> Seems like things were covered in the Karmic release meeting which I accidentally stumbled into.
<rtg> erichammond, good. I think we'll skip the ec2 meeting today pending results from smoser
<Q-FUNK> smb: Geode has built-in video.  no prolem with that :)
<ajish> can some one help me how to enable kdb in ubuntu 2.6.28-14-generic
<Q-FUNK> smb: victory!
<smb> Q-FUNK, Unfortunately just partially.
<Q-FUNK> smb: whatever you did, it boots.  it however hangs up later at the apparmor loading step.
<Q-FUNK> smb: well, you've at least succeeded in isolating the issue
<smb> The corruption might still be in place, but instead of hitting the i_acl pointer and being visible on boot, it would affect the private pointer and might go unnoticed
<smb> At least it seems that the change seems quite isolated, seems to be only at this one location...
<smb> Q-FUNK, I wonder whether apparmour failing later is a clue or just coincidence because of the silently modified structure... But I guess that needs a bit more thinking... :)
<Q-FUNK> Linux geode 2.6.31-10-generic #32bug396286v2 SMP Fri Sep 11 16:26:56 UTC 2009 i586
<Q-FUNK> smb: that, I wouldn't know.
<Q-FUNK> brb
<apw> cjwatson, did you say our grub2 was updated with the potential fix for the blammo?
<cjwatson> no
<cjwatson> Robert still seems to be working on it - the Debian bug's been updated
<cjwatson> I think I'm waiting for it to go upstream at this point
<apw> sound indeed
<apw> bah lost the link to the debian bug ... don't have it by any chance do you?
<amitk> ogra: lool: First cut of the freescale kernel rebased to 2.6.31 and all patches upto sdk1.6 applied -> http://people.canonical.com/~amitk/mx51/linux-image-2.6.31-100-imx51_2.6.31-101.8_armel.deb
<amitk> I'll be reordering/cleaning up a little bit, but this is the meat of it.
<lool> ogra: thanks
<lool> err amitk, thakns
<lool> amitk: How did the kernel work for you?
<lool> amitk: Could you comment on the latest patches?  Fixes or new features or...?
<cwillu_at_work> I get the impression that the upstream kernel people aren't aware that a desktop becomes unusable under any io load?
<jjohansen1> cwillu_at_work: it just depends on your definition of usable and load
<jjohansen1> :)
<cwillu_at_work> D:
<cwillu_at_work> but seriously :p
<cwillu_at_work> I don't understand why my mouse cursor should ever stop moving in response to _disk_ load
<cwillu_at_work> I thought this was supposed to have been taken care of years ago :p
<cwillu_at_work> and then I thought that having 4gb of ram to fit my 2gb working set and still have 2gb left over for caching was supposed to make me forget about my troubles
<cwillu_at_work> It just feels like we've made no gains in interactivity, despite the improving metrics that are intended to reflect that
<cwillu_at_work> brb (groan if you must :p)
<erichammond> Would it make sense to link from https://wiki.ubuntu.com/KernelTeam to https://www.google.com/calendar/hosted/canonical.com/embed?src=50d02kfdekgcjdcpc970hh83f0%40group.calendar.google.com&ctz=America/New_York ?
#ubuntu-kernel 2009-09-12
<mzz> Hi! I'm looking for a vmlinux file for jaunty's kernel (to feed to oprofile and/or sysprof). Iiuc my options are to upgrade to the jaunty-proposed kernel so I can use a linux-image-debug from http://ddebs.ubuntu.com/pool/main/l/linux/ or to build my own?
<cwillu> mzz, http://www.codeguru.com/forum/archive/index.php/t-415186.html
<cwillu> actually, nvm, that approach doesn't work with oprofile
<mzz> cwillu: I'm not married to oprofile but I do want symbols
<cwillu> yep, that's the thing that makes that approach not work
<dandel> hmm... anyone know how to go about reopening bugs on the official kernel bugzilla?
<doctormo> Need advice on developing or finding something to hook up a serial port to keyboard input.
<cwillu> Can somebody comment on Polygon's difficulties with 2.6.31 from the mainline kernel at the end of bug #423379?
<ubot3> Malone bug 423379 in linux "Random machine lockups under load [jaunty] [karmic]" [Undecided,Confirmed] https://launchpad.net/bugs/423379
<cwillu> He's worked around by compiling his own and skipping the new config items, but my sense is that things shouldn't break that way
<superm1> mjg59, any updates on that patch for catching xf86wlan for dell-laptop?  
<mjg59> superm1: On my list
<ia> hello. I'm not a very good expert in git, so my question about using git with ubuntu-karmic kernel git source tree. Sometimes after 'git pull' i've got CONFLICT messages (that's because rebasing occurs in source tree on a 'server side', i suppose). So, my question is - could you tell me, please, which the best way to make regular pulls without problems and point me, please, some workflows/usecases about this?
<karl> hi all, i try to get a eeepc module working in the 2.6.31 kernel, however it does not seem to find a i2c adapter. 
<karl> does anyone know how to list all available i2c adapters ?
#ubuntu-kernel 2009-09-13
<Unggnu> hi all
<Unggnu> Could somebody please take a look at this report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/421662
<ubot3> Malone bug 421662 in linux "Intel 3945ABG WLAN doesn't work with Ubuntu Kernel in Karmic [regression]" [Undecided,New] 
<Unggnu> It is a regression to previous Ubuntu versions and the Vanilla kernel
<Unggnu> bye
#ubuntu-kernel 2010-09-13
<MTecknology> wow.. it's unreal how busy the kernel ML is
<amitk> MTecknology: lkml?
<MTecknology> amitk: on lists.ubuntu.com
<MTecknology> amitk: and the bugs running through ~ubuntu-kernel-team
<amitk> yeah, it has certainly grown over time
<MTecknology> I decided to hop out of ~ubuntu-kernel-team and hop into teams that are more specific to my interest - probably not a big deal considering the lack of involvement I've had.
<MTecknology> I aimed too high - tried to do too much stuff - and now I have simple projects that are over a year old and still unreleased :(
<MTecknology> ok.. nappy time
<apw> drew212, yes if your touchpad is missing a bug is needed
<ikepanhc> apw: about bug 634702
<ubot2> Launchpad bug 634702 in linux (Ubuntu) "Kernel 2.6.35-19 fails to boot Lenovo S10-3 (affects: 1) (heat: 8)" [Critical,In progress] https://launchpad.net/bugs/634702
<ikepanhc> I believe the new module intel_idle is the root cause
<apw> ikepanhc, interesting
<ikepanhc> but dont know much about the module, any idea who we shall ask?
<smb> I guess it would be something to bring up on the acpi mailing list
<ikepanhc> The S10-3 use N450 as CPU
<smb> Maybe cc Len Brown
<apw> well if we have proven its the cause, like via black-listing, then acpi list sounds good, and the authors of course
<smb> good morning btw... :)
<apw> moin
<ikepanhc> good morning .eu :)
<ikepanhc> will write to Len Brown
<ikepanhc> you guys have any N450 machine?
<smb> ikepanhc, But don't forget linux-acpi, I want to watch the thread. ::)
<apw> ikepanhc, i would email the authors of the commit which adds it
<apw> cc: acpi and len, its the authors who are most likely to have a clue
<ikepanhc> I wonder it happens on all N450 machine or only S10-3
<smb> Hm, No I only have old 270s
<apw> ikepanhc, i would not be supprised if it is all, perhaps a search for those symptoms may help
<kengyu> ikepanhc, iirc, samos is N450?
<jmg> hi all
<jmg> i need to do an instruction trace on the kernel
<jmg> what debugger should i use?
<jmg> kdb and kgdb dont seem to be in the repos
<jmg> hmm
<jmg> hi balbir
<balbir> jmg: hi
<jk-> jmg: what are you looking to do?
<jk-> (ie, what would you like to trace? or do you want to step through a particular function?)
<jmg> get an instruction trace for usb-storage operations
<jmg> so i can figure out what instructions to use in a tool im writing
<jmg> the instruction trace for overwriting a file would get me a long way
<apw> sounds like you want a usb trace more than an instruction trace
<jmg> i cant read usb
<jmg> if i could, that would help
<apw> there is some way to trace usb traffic
<jmg> yeah i saw it
<jmg> debugfs
<smb> https://wiki.ubuntu.com/Kernel/Debugging/USB
<TeTeT> are there any known USB problems in the Lucid kernel, especially on T61/x61? A customer reports problems on 3G (USB), printers (USB) and wonders if there's a known issue
<smb> TeTeT, Vaguely known at most. I think I remember some reports but not really details
<smb> And it depends an "problems"
<smb> problem not being detected at all or traffic problems
<TeTeT> smb: problem as in arbitrarily happening losses of devices, e.g. 3g no longer working, printing not possible
<TeTeT> smb: I try to get more details from the customer, but they have themselves problems collecting detailed information from the field
<smb> TeTeT, Those rather not known and may be device specific or not. Can you make sure problems are reported for each device (if it is not something like all usb traffic is broken after some time)
<TeTeT> smb: yes, will file bug reports as soon as I get enough details
<jmg> ok the usb trace
<RAOF> Hm.  How can I work out what's the most recent commit in the drm-intel kernel PPA build?
<RAOF> Or, more specifically, how can I tell whether the commits that should fix bug #600453 have landed in there.
<ubot2> Launchpad bug 600453 in linux (Ubuntu) "[arrandale] [i915] DELL E6510: blank screen on boot (Intel GPU) (affects: 16) (heat: 143)" [High,Confirmed] https://launchpad.net/bugs/600453
<jmg> i cant read it :(
<apw> RAOF, there is a COMMIT file in the newer result directories which have the commit id which was built
<apw> RAOF, the latest build is in 'current' always
<cking> apw, where is the list of current kernel team bugs for maverick?
<smb> cking, https://wiki.ubuntu.com/Kernel/Tagging
<jmg> f***ing usb, how does it work?
<apw> jmg, heh now that is is a big question
<smb> jmg, Have you looked at the link I posted?
<apw> not sure what you think you'll find from an instruction level trace thats going to be easier to understand
<smb> (assuming you have problems getting the trace)
<apw> i thought there was a library for interacting with usb devices
<apw> libusb i think is the one, perhaps that would have documentation too
<jmg> smb: yes
<jmg> libusb is what i will use to write my tool
<jmg> one i know what to send
<jmg> once*
<jmg> maybe i should just read the usbms spec heh
<apw> cking, bouncy?
<apw> mjg59`, just saw your backlight writeup, has the kernel side stuff hit mainline>
<apw> (it sounds like a very sane approach to the moras)
 * apw lunches
<mjg59`> apw: Not yet
 * smb is back
<apw> mjg59`, ta for the info, very interesting none the less
<DrKenobi> Hi! I'm looking the log of the meeting about bug triage of last Saturday. Where can I find it?
<smb> http://irclogs.ubuntu.com/2010/09/11/%23ubuntu-classroom.html
<smb> DrKenobi, ^
<DrKenobi> smb, thanks! great! I think it would be great to have this link at https://wiki.ubuntu.com/Kernel/BugTriage/Summit/Maverick It would be helpfull
<smb> DrKenobi, I guess you will have the power to do that. ;-)
<DrKenobi> I can? OK, I'll try. Just a basic question: this is automatically generated, or someone has to copy/paste?
<smb> These are automatically generated daily by channel (I guess limited to ubuntu channels)
<smb> This channel is there as well
<DrKenobi> Great. I knew the chat the channels history (log?) was stored, but I never found it. Thanks.
<mjg59`> apw: Needs to go through Richard Purdie's tree, and I think he's stuck in Portland at the moment
<n1ght0wl> hey guys.
<n1ght0wl> i saw strange kernel oopses with maverick kernel tag 2.6.35-20.29 from ubuntu-maverick repository built on ubuntu-lucid on x86_64.
<n1ght0wl> kernel oops can be achived by running lshw command which in most cases hangs and cannot be killed using kill -9.
<apw> n1ght0wl, yes that one we know about, the fix should be in the -21.30 kernel when it hits the archive
<n1ght0wl> apw: thanks.
<n1ght0wl> apw: is there any url related to this problem?
<n1ght0wl> is this it?
<n1ght0wl> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/636679
<ubot2> Launchpad bug 636679 in linux (Ubuntu) "[119903.693261] BUG: unable to handle kernel NULL pointer dereference at 00000008 (affects: 1) (heat: 6)" [Undecided,New]
<n1ght0wl> thanks alot guys!
<apw> tgardner, ok talked to cjwatson and it seems that now that linux-libc-dev is bumped to -803 we cannot upload anything (for armel) which is lower than that, full stop
<apw> tgardner, the recommendation is therefore to bump the abi component for linux-libc-dev above that for the maverick master
<apw> tgardner, he has given me some techniques to use for that, so am going to try them out
<apw> what a mess
<tgardner> apw, I think we need a bodge in the rules that checks for master which is the only branch that should build linux-libc-dev
<apw> tgardner, yeah i am also liking that idea ... explode on build
<apw> i'll do that as well
<apw> ogasawara, fyi armel maverick is failing, know what it is and am working on it
<cnd> pgraner, what's the status on the firmware updates?
<pgraner> cnd, no status yet, keep with what we have for now
<cnd> pgraner, you're killing me :)
<tgardner> apw, I have 2.6.36-rc4 amd64 natty kernels on tangerine.buildd:~rtg/natty/kern if you'd like to experiment with your i915 issues
<apw> tgardner, sounds interesting
<sconklin> apw, ogasawara: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/629711
<ubot2> Launchpad bug 629711 in linux (Ubuntu Maverick) (and 2 other projects) "[Maverick] Removing external display on Vostro 3500 corrupts the screen (affects: 1) (heat: 8)" [High,Triaged]
<ogasawara> sconklin: thanks, looks like that patch just landed in 2.6.36-rc4 and Cc'd stable
<sconklin> ogasawara: cool. That was in the queue for the bugchat we didn't have today, so I wanted you to know
<ogasawara> sconklin: I'm going to wait a few days and hope the 2.6.35.5 stable lands so we can rebase Maverick before freeze
<ogasawara> sconklin: so we might get it for free, regardless I'll build them a test kernel with the patch
<apw> ogasawara, just waiting on the last test build before i ship you the ti-omap-disaster patches
<ogasawara> apw: cool, I was going to apply you patch and re-upload to get armel building again as well as having the kernel rebuilt against the latest gcc
<Sarvatt> apw: regarding the mainstream kernels, comedi should be fixed now  - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=10022a0675a8f8722068d956a798f1fddb02e71c
<apw> Sarvatt, in theory the patches should self-stop applying
<Sarvatt> oh, nice!
<Sarvatt> not sure if it was even still being applied, i just noticed it upstream
<apw> if you look at that one, its gone ... all by itself ... http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc4-maverick/
<Sarvatt> awesome :)
 * apw pats self on the back, the first time its worked :)
<kees> smb: when do you want to do the next kernel security update?
<smb> kees, want? (must be a trick question) We likely want the current lucid proposed in updates
<kees> smb: heh. I guess I mean "when would it be best?" :P
<smb> kees, I guess so. :) I will have a look at the sru status tomorrow and then its probably worth starting to pass some processing on to bjf and sconklin this time.
<kees> okay, cool
 * apw wanders off to gte some food in
 * tgardner lunches
 * smb wander towards eod
<bjf> ogasawara: am doing some patchwork cleanup
<bjf> ogasawara: i'm looking at "musb: move usb_add_hcd to the core init code from gadget code (v2)" by Bryan Wu which you have under review
<bjf> ogasawara: was it really a pull request or just a discussion?
<ogasawara> bjf: I think it was just a discussion and last I remember bryan was still waiting for feedback
<bjf> ogasawara: can I also mark the "xsave" patches as rejected?
<ogasawara> bjf: not till kernel freeze
<ogasawara> bjf: as it was dependent on them getting us test cases by kernel freeze if I'd consider applying to maverick or not
<ogasawara> bjf: for lucid SRU they're a nack
<ogasawara> s/lucid/maverick
<bjf> ogasawara: ah, your waiting for the winged pigs to appear
<ogasawara> bjf: exactly :)
<ogasawara> bjf: so I'll mark them as rejected on thurs
 * cking calls it a wrap
<bjf> np
<smoser> apw, jjohansen says there is some kernel/upstart bug that is related to bug 606373
<ubot2> Launchpad bug 606373 in linux-ec2 (Ubuntu Maverick) (and 3 other projects) "cloud-init output does not get to console when booted with pv-grub and ramdisk (affects: 1) (heat: 73)" [Undecided,New] https://launchpad.net/bugs/606373
<smoser> do you happen to know that bug number ?
<apw> bug #554172
<ubot2> Launchpad bug 554172 in upstart (Ubuntu Maverick) (and 5 other projects) "system services using "console output" not starting at boot (affects: 208) (dups: 16) (heat: 924)" [Medium,Fix released] https://launchpad.net/bugs/554172
<apw> smoser, ^^
<smoser> danke
<jjohansen> yeah
 * ogasawara lunch
<jjohansen> -> Lunch
 * jjohansen -> running errand back in a bit
<bjf> ogasawara: i'm confused by lbm version numbers I'm seeing
<ogasawara> bjf: for which release?
<bjf> ogasawara: lucid
<bjf> ogasawara: if I bring up the "Synaptic Package Manager" and type in "linux-backports-modules-alsa" in the "Quick search" box ..
<bjf> ogasawara: I see modules with the description of "Backported drivers for alsa-driver snapshot"
<bjf> ogasawara: as well as "Ubuntu supplied Linux modules for version 2.6.32 ALSA snapshots."
<bjf> ogasawara: 2.6.32-25.22 is what I just recently uploaded and was built, I don't know what these "2.6.32.25.27" versioned packages are
<ogasawara> bjf: that looks like the meta package version
<bjf> ogasawara: there is a lbm meta package?
<ogasawara> bjf: the linux-meta package generate lbm meta packages
<bjf> huh
<bhuey> got an nvidia module crash
<bhuey> softirq hang
<bhuey> trying to file a bug report is a pain
<bhuey> anybody ?
#ubuntu-kernel 2010-09-14
<TheMuso> bjf: When you get a minute, could you possibly kick the alsa modules daily builds over to new ABIs?
<TheMuso> Thanks in advance.
<bjf> TheMuso: lucid daily is already at -24 could do -25 for proposed
<TheMuso> bjf: Ah ok, I don't think -25 matters for proposed at this point, but what is disturbing is that some users have filed audio bugs using the proposed 2.6.32-25 kernel.
<lag> Can someone test this for me?
<smb> lag, this?
<lag> cd to a git repo and issue: BRANCHES=$(git branch) && echo $BRANCHES
<smb> maybe BRANCHES="$(git branch)"?
<lag> Nope
<smb> and echo "$BRANCHES"
<smb> lag, The version with all "" works... now without
<lag> I'm more interested to know where it's acquiring the directory listing from?
<smb> Trying to find a logically sounding explanation but it has to do with shell expansion somewhat
<smb> lag, ah because you have a * in the result
<jk-> :D
<lag> Ah!
<lag> Well spotted
<lag> BRANCH=`git branch | grep \*` && echo ${BRANCH#* }
<lag> Woooooooo
<smb> lag or BRANCH=$(git branch | awk '/^*/{print $2}') ;-)
<lag> I'd just typed up a similar line using sed :)
<lag> But I think yours is more readable, I'll use that
<smb> At least it helps me that awk can look very much like C
<lag> Really?
<jk-> or
<jk-> set -f; BRANCHES=$(git branch); echo $BRANCHES
<jk-> i guess you don't want the * though..
<smb> heh, a hundred ways to do it
<jk-> BRANCHES=$(git branch | tr -d '*'); echo $BRANCHES
<smb> lag, Yeah, you could do a git branch | awk '/^*/{printf("%s\n", $2);}' as well
<lag> I like smb's first one :)
<lag> Have you all finished flexing your Bash muscles now? ;)
<jk-> b=$(git branch); echo "${b/\*/}" <- one less fork
<lag> Clearly not :)
<jk-> :D
<smb> The winner of most unintuitive code today is .... jk-  ;-P
<jk-> woot!
<jk-> b=$(ls .git/refs/heads/)
<smb> That would mean we understand how git actually works...
<jk-> so +1 for a layering violation too?
<smb> hehe, yeah. unfortunately you cannot trust it even when using the commands as apw and me found out for git remote show -r
<lag> I have a new favourite 
<lag> BRANCH=`git branch | grep \* | cut -d ' ' -f 2`
<lag> Simple, effective
<jk-> lag: you only want the current branch?
<lag> Yeah
<jk-> i'd go for the awk then :)
<lag> I like the awk version
<lag> But this one is easier to read: BRANCH=`git branch | grep \* | cut -d ' ' -f 2`
<smb> It probably has more every-day-use commands. And having a third fork unlikely will really matter 
<lag> It'll only be run once for every compile
 * apw starts his UHS prep ... with a haircut
<lag> What do we have to wear for UHS?
<AceLan_> lag: I think you'll get a new t-shirt for it
<jk-> pants
<jk-> :)
<lag> T-shirt sounds good
<lag> :)
<lag> AceLan_: Is your lecture prep'ed?
<AceLan_> lag: http://shop.canonical.com/index.php?cPath=14 # Ubuntu Polo Shirt (Black)
<lag> Could be worse :)
<lag> I'm assuming I don't have to pre-order it?
<AceLan_> lag: don't worry, I'm pretty sure you'll get one for free
<lag> I still haven't spent my joining voucher
<jjohansen> ha, I forgot all about the joining voucher, /me hasn't spent it either
<AceLan_> me neither :p
<cooloney> Canoical shop doesn't ship goods to China, so me either
<diwic> In addition, the shipping cost takes half the voucher
<diwic> lag, the dress code is actually listed as "Smart trousers, not jeans" and ubuntu t-shirt, which I assume Fanny will provide when we get there
<lag> Great, thanks David 
<lag> cooloney: You can always send it to me :)
<cking> smart trousers? Hrm.
<cooloney> lag: haha, yeah, i will ship an new iphone4 and ipad to you
<jk-> woot, free gear
<smb> diwic, I would treat the dress code with care. Its copied over regardless of occasion and you might look strange around the geeks. :)
<cooloney> lag: and pls bring them to UDS for me
<cking> does it specify smart socks too? Can I wear multi-coloured ones?
 * smb does not want his clothing to be smarter than himself
<cking> dress code did not specify underwear
<smb> diwic, Would you have an explanation on the feedback to bug 587546. It seems reported as the patch in proposed has no effect (must admit I have not looked really at details). 
<ubot2> Launchpad bug 587546 in linux (Ubuntu Lucid) (and 3 other projects) "Pulseaudio fails after several seconds (affects: 1) (heat: 41)" [Low,Fix committed] https://launchpad.net/bugs/587546
<lag> cooloney: I didn't mean the goods, I meant the voucher
<lag> cooloney: But if you want to ship anything to me, I'd be happy to bring it over to UHS/UDS
<cooloney> lag: np, you are so kind. heh
<cooloney> lag: anything you need we bring from China, just tell us
<lag> All the tea
<lag> Actually I'd quite like a 'Naja atra'
<cooloney> lag: what's 'Naja atra' is green tea?
<cooloney> you know green tea is common in China
<lag> :D
<lag> The first request was "All the tea", as in "All the tea in China"
<lag> You will have to Google Naja atra for yourself :)
<smb> lag, You have a big suitcase and know some people working for the airline and customs? ;-)
<lag> For which item?
<lag> :)
<lag> I don't think I have a big enough suitcase for all the tea in China
<lag> For a few Naja atra maybe :)
<smb> Likely all of them. But especially the Naja atra I guess
<smb> :)
<smb> Probably cking and apw want a different plane than you back as well. :-P
<diwic> bjf, guess what - it's ABI bumping time!
<apw> smb-afk, he'll be stuck in customs for the duration when they find out he is a purper
<apw> diwic, heh bad boy
<diwic> apw, ?
<apw> bumping the abi
<diwic> apw, sounds like an inspiration for a rap song? 
<apw> diwic, so very true
<smb> diwic, Could it be inspirational enough to have a quick look into the question I asked before? :-P
<diwic> smb, what question? Do you want me to repost the patch with a changed commit message?
<smb> apw, Or stuck there for long on his way back should they find a "present" like that.
<smb> replay: diwic, Would you have an explanation on the feedback to bug 587546. It seems reported as the patch in proposed has no effect (must admit I have not looked really at details). 
<ubot2> Launchpad bug 587546 in linux (Ubuntu Lucid) (and 3 other projects) "Pulseaudio fails after several seconds (affects: 1) (heat: 41)" [Low,Fix committed] https://launchpad.net/bugs/587546
<diwic> smb, okay, I'll have a look as soon as I've done with another bug
<smb> diwic, Thanks a lot
<cking> apw,  https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=ath9k&orderby=-importance
<mapet> Can anyone tell me how I can add a custom version string to my kernel build, if I compile the official kernel with "debian/rules binary-generics"? I don't want it to be overwritten on each apt-get upgrade...
<apw> mapet, normally I exit the top of the debian.master/changelog and use my own version there
<mapet> apw, iirc this didn't worked for me but I'll try it again. thank you
<diwic> In average, how many days does it take from I send a patch to stable@kernel.org to that the Lucid users can enjoy their fixed bug?
<smb> diwic, That depends on quite a lot of variables to be giving a good average. How long from Greg accepting it to releasing it, how long from that till we get it into the archive and from that depends when its possible to upload to proposed and then how long it take to go to updates
<tgardner> diwic, it can sometimes take weeks, which is why we often have a (pre-stable) inclusion.
<smb> i guess a minimum can be at least three weeks on good days...
<smb> (to get into updates)
<diwic> tgardner, so how long is our own baking cycle compared do that? 7 - 14 days? 
<tgardner> diwic, roughly
<smb> diwic, yes. as upstream stable updates usually are larger rather the 14 days in proposed
<diwic> so waiting say 5 - 7 weeks in total is not unusual?
<smb> Hopefully we can improve that a bit but at least it was
<smb> But i'd say 3 to 4 weeks could be common
<diwic> right, the long security-blocking-sru discussion
<diwic> How do I know on what waiting list a stable patch actually is? 
<smb> Yes, that has some impact at least to the in the proposed to updates time. People can get patches quicker when installing at least proposed but even better pre-proposed
<smb> diwic, When it has been released in an upstream stable release you can check when that gets applied to the master repo. When it is in there it moves on to proposed uploads (which you probably could check with git describe --contains on our master repo)
<diwic> smb, someone should write up a wiki page on how to know where an update is
<diwic> smb, so my patch is currently present in stable-queue.git, queue-2.6.35 but not queue-2.6.32
<diwic> That's not good odds I assume
<smb> diwic, Someone probably should
 * smb looks innocent
<smb> diwic, And yes, that does not seem good
<smb> diwic, Could it have failed to apply cleanly there?
<smb> In that case Greg accepts bribes in form of backported patches
<diwic> smb, I gave him a 2.6.32 backport but was perhaps too late
<smb> It might just be pending another batch of applies from his inbox. Its hard to say
<diwic> so after it has been in queue-2.6.xx for x days, it moves to another tree and is there for x days
<smb> diwic, He may or may not move it into review-2.6.xx in that repo and sends out review mails, gives people about three days to reply or not and then takes the set that is there after that and imports it into the various 2.6.x.y trees
<diwic> smb, and then it moves into ubuntu-lucid (e g)
<diwic> smb, and then to pre-proposed, then to proposed, then released
<smb> diwic, Right, so when it is released in the 2.6.32.y tree we pick it up prepare a patchset with it and do the usual tracking bug and quick review, then apply it to the repo and from there an automatic script picks up the checkins and creates the pre-proposed. The proposed uploads are more manual as they need to take into account whether there is something in proposed we want to go to updates first, or whether a security update comes in soon an
<smb> d such. But at some point it gets uploaded to proposed
<smb> and then after about 2 weeks (if trere have been no regressions detected) it will get moved on
<vanhoof> diwic: this has been helpful for me (if you've not seen it): http://people.canonical.com/~ubuntu-archive/pending-sru.html
<smb> diwic, The upload itself also can get delayed as each package uploaded to the proposed pocket needs to be accepted manually by an sru team archive admin
<smb> vanhoof, right this shows what bug reports are claimed to be fixed by a proposed upload. And red is a bad verification and green a good one
<smb> blue is nobody cared (yet)
<smb> The sru team tries at least to have a certain percentage  of the bugs successfully verified and no regressions before moving it to updates, even if it has been there for the two weeks
<diwic> how often does greg do a "review round"?
<smb> depends, sometimes every two weeks, sometimes it takes longer. Probably depends on the queue and his workload
<diwic> vanhoof, thanks, it just shows the stuff in proposed, which has it's purpose. I'm trying to understand the patch flow (flowchart, anyone)? 
<smb> diwic, You know its the "new guys" job to fix the crap documentation of the old guys. ;-P
<diwic> smb, oh, I just became much older ;-)
<smb> :)
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<sconklin> http://www.pcpro.co.uk/news/361108/intel-unveils-sandy-bridge
<vanhoof> sconklin: nooooooooooo
<vanhoof> :D
 * smb curses under his breath. tgardner could you fix a nomination for me please? bug 638115
<ubot2> Launchpad bug 638115 in linux-backports-modules-2.6.32 (Ubuntu) "linux-backports-modules-wwan-2.6.32 fails to upgrade properly (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/638115
<tgardner> smb, done
<smb> tgardner, thanks
<apw> vanhoof, heh, thats written by a friend of mine
<vanhoof> apw: I was hoping it was all a dream
<vanhoof> apparently its not :)
<tgardner> apw, ogasawara: did you notice that gcc was uploaded _again_ ?
<ogasawara> tgardner: wtf, again?
<tgardner> about 30 minutes ago
<apw> tgardner, thats 4.5 which version do we use ?
<tgardner> I thought it was 4.5.
<ogasawara> I though it was 4.4
<tgardner> hmm, don't have a maverick machine handy.
<tgardner> ogasawara, you're right. it is 4.4
<apw> yeah looks like its 4.4. we are using by default, so i think we are ok 
<apw> tgardner, ogasawara, EXCEPT, 4.4 just got uploaded too
<apw> 10 mins ago
<tgardner> apw, thats what Mathias was referring to in the other channel
<tgardner> looks like we should be OK
<ogasawara> well, I was thinking of doing another upload today anyways to make sure the -virtual deb sizes shrink back down
<tgardner> ogasawara, you have any other patches you'rethinking of taking?
<ogasawara> tgardner: the others on the ml which are mainly pre-stable patches
<tgardner> I guess that was a dumb question, huh?
<ogasawara> tgardner: I'm also still hoping for 2.6.35.5 to land so we can sneak that in before kernel freeze too
<tgardner> ogasawara, Thursday, right? thas gonna be tight.
<ogasawara> tgardner: yah, we'll have to see.
<cking> hrm, got this error on my server:
<cking> [ 4655.729368] fwts: Corrupted page table at address 7fd769f1e606
<cking> [ 4655.729466] PGD 129845067 PUD 139e43067 PMD 12f527067 PTE bff6463abff64235
<cking> [ 4655.729625] Bad pagetable: 000d [#1] SMP 
<cking> [ 4655.729695] last sysfs file: /sys/devices/pnp0/00:05/rtc/rtc0/wakealarm
<cking> [ 4655.729796] CPU 0 
<ogasawara> manjo: do you think you're going be throwing any last minute patches my way re WD?
<tgardner> cking, is it fwts detected that the page table is corrupted?
<cking> tgardner, it trips that warning from the kernel
<apw> heh no it was simply the victim
<cking> dunno why as yet. Ah, it's repeatable.
<tgardner> cking, well, thats the first step
<apw> probabally you are looking somewhere nasty ... but ick
<cking> hrm, only disassembling the DSDT
<vanhoof> ogasawara: i have 20 patches I'm planning to submit tomorrow at 11pm ET
 * vanhoof *hides*
<smb> ogasawara, I may be trying to pre-stable a little update that fixes a (not sure how minor) problem with /proc/<pid>/maps for you to decide. 
 * ogasawara slaps vanhoof
<tgardner> vanhoof _better_ hide.
<vanhoof> haha!
 * vanhoof is done w/ patches for maverick
<ogasawara> smb: ack
<vanhoof> im glad i've not been slapped yet ;)
<tgardner> vanhoof, thats apw's trick.
<apw> ogasawara, i think that vanhoof just said you can ignore anything from him from now on :)
<ogasawara> cking: I wanted to ask you about bug 612741 which is linked to your kernel-maverick-bios-test-automation blueprint...
<ubot2> Launchpad bug 612741 in acpi (Ubuntu) "uncommanded shutdown (affects: 1) (heat: 100)" [Medium,Incomplete] https://launchpad.net/bugs/612741
<ogasawara> cking: the bug isn't exactly about the fwts itself, but rather a bug where you had them run the fwts
<ogasawara> cking: did you really want that linked to the blueprint?  as it shows up as an open work item for you
<cking> ogasawara, it should be removed
<ogasawara> cking: cool, I'll remove it.
<cking> ogasawara, you are too kind
<cking> thanks
<bjf> cking, i think i've fixed the issue with the daily iso building and it's building them now
<cking> bjf, thanks!
<tgardner> ogasawara, I'm looking at these powertop patches. the first one (at least) appears to be a backport.
<tgardner> ah, guess Yong says tha in the into email
<tgardner> intro*
<ogasawara> tgardner: yah, the first is upstream.  not sure about the status of the 2nd patch w/ regards to upstream.
<tgardner> ogasawara, well, I'm making sure he got the backport right. it looks a bit different.
<ogasawara> tgardner: he bodged the first attempt that's for sure
<tgardner> which is why I'm looking at it a bit closer
<tgardner> ogasawara, the 2nd patch has all of the SATA statistics gathering done within the interrupt handler. I'm not sure that''ll land upstream intact.
<vanhoof> apw: hew now :)
<apw> vanhoof, can't hear you :)
<vanhoof>  /mode +v vanhoof
<vanhoof> :)
<smb> ogasawara, apw Ok, pushed my little contribution. Though I am not completely sure about its importance or effect 
<ogasawara> smb: looks reasonable enough and seems you've tested it works
<smb> Mostly. I think I was bad and tested before that it does not work right now and the change itself just repeats or reuses the changes from Linus for the rest.
<JFo> vanhoof, what goodies do you want in my slide deck for UHS?
<smb> ogasawara, And well a very similar change was used to get Xen working again on Hardy
<JFo> I am outlining the general versus the private bug/group concept
<apw> ogasawara, are you aware of the thread "Final Maverick i830, i845g, i855 support" ... they are likely to be asking us to revert some patches
<ogasawara> apw: yep, was going to ping RAOF to get his final recommendation to drop the KMS disablement patches
<ogasawara> apw: but I think he might be traveling today
<apw> ogasawara, cool as long as you are aware i can go back to sleep
<vanhoof> JFo: what do you mean
<JFo> I'm building my slide deck for UHS
<JFo> is there any OEM team/ HWE stuff you want me to add?
<vanhoof> JFo: well what are you talking about
<JFo> I'm writing about the bug process
<vanhoof> ah
<JFo> sorry
<JFo> should have said
<vanhoof> "vanhoof quit being dense?"
<JFo> lol
<vanhoof> JFo: bug process is not something that the OEM has to deal with, they file as normal, and i've put together a linking concept to track distro bugs
<JFo> right
<JFo> I left that bit out as I don't think it would be useful to them
<JFo> basically I am proposing that, unless they have NDA or pre-announced hardware, that they use the general process
<vanhoof> yeah thats a fair statement
<JFo> k
 * tgardner spams ogasawara with more patch mail
<kstailey> good day (or whenever)
<apw> good 'now'
<JFo> hi kstailey :)
<kstailey> hi jFo
<apw> bug #563481
<ubot2> Launchpad bug 563481 in linux (Ubuntu) "BUG: Bad page state in process soffice.bin pfn:111e42 (affects: 4) (dups: 1) (heat: 45)" [Undecided,Incomplete] https://launchpad.net/bugs/563481
<kstailey> I'm sure there are others.
 * smb wonders whether he saw that mails on the stable list
<JFo> kstailey, is that patch in stable?
 * JFo hasn't had the chance to look
 * kstailey checking
<smb> Me neither
<ogasawara> it didn't look like it was upstream yet
<ogasawara> so I assume it's not in stable
<apw> kstailey, so are you looking for a test kernel with this patch in, ie, is this patch well tested yet?
<smb> The description soehow sounds like I saw it somewhere, but as long as it is not upstrream it won't go stable
<kstailey> now I am peeking at drivers/char/hpet.c in lxr
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - September-28 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<smb> Seems that mail went to linux-acpi a month ago. But I don't seem to see a response
<kstailey> it's not here http://lxr.linux.no/#linux+v2.6.35.4/drivers/char/hpet.c#L972
<kstailey> but maybe it should be
<kstailey> :)
<kstailey> I may have some more HP Proliant DL145 G2 systems to test on
<JFo> I apologize, but I need food :)
<JFo> bbiab
<kstailey> I'm going to look for a server to test the patch on.
<smb> Hm, it looks like this is a proposal to handle a bios bug. Might need some query upstream to get it moving probably
<kstailey> The system we experienced this bug on is deployed by using the "nopat" kernel option in grub
<kstailey> as a work-around
<kstailey> http://en.wikipedia.org/wiki/Page_Attribute_Table
<apw> kstailey, you good to make a test kernel ?
<kstailey> I'm still looking for a machine to test on
<kstailey> Is it OK to test on Lucid or are you particular about me testing on Maverick? 
<kstailey> I'd rather test on Lucid myself
<smb> Well it seems it would be the same upstream
<smb> You may try some of the more recent mainline kernels in lucid to compare against
<kstailey> OK
<kstailey> well first thing's first let me get my server
<smb> Its a bit latish here to get my head around it now. The patch itself looks at least reasonable to me but I wonder why there has been no response upstream to it
<kstailey> I'm also going to peek at RHEL6 to if Red Hat is workong on this
<vanhoof> kstailey: http://rhkernel.org/RHEL6
<sconklin> thanks everyone for your support in the Developer Board meeting
<tgardner> sconklin, like smb said, it'll be nice to not have to do your job :)
<ogasawara> jjohansen: you'd mentioned you were planning to submit some Maverick patches?  any eta for those?
<jjohansen> ogasawara: yeah, sorry I'll post them today.  They are done.  I just need to get them pushed out
<ogasawara> jjohansen: ack
<jjohansen> that and I have been testing the amazon one
<ogasawara> tgardner: that first power top patch you re-did for yong, it doesn't look like the rtpm_status_show() originates from 8d4b9d1bfef117862a2889dec4dac227068544c9
<tgardner>  oguh, lemme look
<tgardner> ogasawara, ^^
<tgardner> ogasawara, hmm, what was I smoking? Did I get confused because he added it?
<ogasawara> tgardner: it actually looks like his patch removed it?
<tgardner> ogasawara, ok, now I'm totally confused. lemma go back and repeat what I did.
<ogasawara> tgardner: I have a feeling yong isn't using our maverick repo
<tgardner> ogasawara, no, likely its the Linaro repo
<tgardner> ogasawara, ok, you cherry-pick it and see if you get anything different.
<ogasawara> tgardner: ack
<ogasawara> tgardner: if we cherry-pick 0fcb4eef8294492c8f1de8236b1ed81f09e42922 first, then 8d4b9d1bfef117862a2889dec4dac227068544c9 cherry-picks cleanly
<tgardner> ogasawara, I only had minor, seemingly innocuous conflicts. huh. I guess I missed the dependency.
<ogasawara> tgardner: 0fcb4eef8294492c8f1de8236b1ed81f09e42922 seems to fix up rtpm_status_show that we currently have in Maverick
<tgardner> ogasawara, ok, well lets go that route. clean cherry-picks...
<ogasawara> tgardner: ack, will respond to the list that I've gone the clean cherry-pick route
<sconklin> ogasawara: I'm only aware of one open work item that I had, does that match your reality?
<ogasawara> sconklin: yep
<sconklin> ok, I just postponed it.
<ogasawara> sconklin: cool, thanks
<sconklin> I'm not sure it's needed so much, Need to ask RAOF
 * ogasawara lunch
 * tgardner has brcm80211 working in natty. seems to connect OK, but borks on removal.
<DoYouKnow> Hi. Anyone know if/when BCM4328 development support will be included in the kernel, or if it can be enabled in maverick?
<kstailey> @DoYouKnow wrt Broadcom have you seen this http://thread.gmane.org/gmane.linux.kernel.wireless.general/55418
<ilmari> I had a quick look a that and couldn't find anything about BCM4328 support there (I have that chip in my work laptop)
<kstailey> you didn't read the entire thread
<ilmari> I did
<ilmari> nothing about 4328 there, only 4329 and some other chipsets
<ilmari> when I said "at that" I meant the driver source itself
#ubuntu-kernel 2010-09-15
<kees> is there some plan to get people off of the 2.6.36-999 kernels once maverick releases officially?
<ogasawara> kees: not that I'm aware of.  the mainline kernels are an elective install so it seems inappropriate for us to then force them back to the Maverick kernel.
<kees> ogasawara: fair enough.
<ogasawara> kees: but that's just my initial opinion
<ogasawara> RAOF: if your about, let me know what the final verdict is for the KMS disablement patches as I'll need to get them reverted asap to make the kernel freeze deadline.
<jjohansen> rebooting
<apw> RAOF, morning ... 
<apw> did we bottom out on KMS, i think we need to revert those today to get them in in time
 * smb has completed the morning scan of email
<smb> morning all
<smb> RAOF, If you are around, are you the radeon guy or is that Sarvatt ? (one day I am hopefully able to remember)
<cooloney> apw and smb morning
<smb> cooloney, \o
<apw> morning alll
<smb> apw, https://patchwork.kernel.org/patch/120327/
<apw> smb, apparently there is a bug in LP for the above patch: bug #563481
<ubot2> Launchpad bug 563481 in linux (Ubuntu) "BUG: Bad page state in process soffice.bin pfn:111e42 (affects: 4) (dups: 1) (heat: 45)" [Undecided,Incomplete] https://launchpad.net/bugs/563481
<apw> found it while closing down tabs overload
<smb> ah right that was it
<amitk> ikepanhc:  did you receive any HW schematics during the lange51 engagement?
<ikepanhc> amitk: maybe only blocks
<ikepanhc> amitk: let me check
<amitk> ikepanhc: could you forward me whatever material you did receive?
<ikepanhc> amitk: sure
<amitk> ikepanhc: thanks!
<smb> apw, enable_mtrr_cleanup
<ikepanhc> amitk: found three emails, forwarded.
 * apw lunches
<apw> bah uk banks SUCK
<smb> apw, Still around or went away to smash the bank
<apw> smb, am in the damn bank now ... waiting
<smb> apw, Hope without a gun. :-P What the heck did they (not) do?
<apw> they need my id to open a savings account (bloody sarbains-oxley)
<apw> but the woman with nothing to do can't see me i have to see one of the busy ones
<smb> Not her expertise. Yeah that sucks. But the id stuff if now European
<apw> its a passport, so its not worth the paper its printed on anyhow
<smb> heh, not sure whether the uk ones are worse but the german ones likely carry your dna information
<smb> (I am exaggerating, but either they have started or will soon to put your fingerprints on an id chip there)
<apw> smb, i have an old one, they will be adding them soon i think prob in my next one
<smb> apw, Me too. Will be bloody expensive to get one then. With the great added value of having an rfid chip that already had been proven to be easily destroyed if one wants to...
<apw> hehhe
<apw> smb, that args testing kernel is http://people.canonical.com/~apw/args-debug-maverick/
<apw> smb it has specific debug for the mtrr thingy and alll args debugging turned on
<smb> apw, A good, was about to ask you. 
<apw> be interested in the dmesg with it on
<smb> Test with just enable_mtrr_cleanup showed the same result as before with the 2.6.35-21 kernel
<smb> ok
<apw> smb, wassit say
<smb> "smb was preempted away and just now is installing it"
 * smb feels like having IPI issues :-P
<smb> apw, mtrr cleanup deemed enabled but it does not do it. bugger
<apw> so it says deemed enabled ? but does not say deemed needed ?
<smb> right, did not see that
<smb> hmmm... maybe it thinks pat is better?
<smb> apw, ^
<apw> smb, no it means that it decided it would not work or not required, i will check
<smb> apw, dmesg.aa1.debug1 at the usual place
<apw> ta
<apw> smb, could you shove cat /proc/mtrr somewhere (/QUERY or a chin or ...)
<smb> sure. a sec
<smb> apw, mtrr.bad@chin
<cassidy> hi guys. I have a system freeze which is 100% reproducible. What's the best way to gather info for the bug report? kerneloops doesn't seem to catch it
<smb> cassidy, "ubuntu-bug linux" to gather generic stuff. And then proceed from there
<cassidy> yeah I know that, but is there a way to get info from the freeze?
<apw> smb, do you have an older kernel on that machine you could get an /proc/mtrr off of?
<apw> cassidy, if its freezeing hard ie its not accessible over the network or console then not really
<smb> apw, Not very much more, I could boot from a Lucid install
<cassidy> apw, yeah
<smb> cassidy, If its possible to cause the freeze after switching to a vt it may show something
<apw> smb, well i know why it won't clean your mtrrs at the moment ... you have a write-protect in there
<apw> trying to work out why it might care
<cassidy> smb, which terminal ?
<smb> cassidy, vt1 with ctrl-alt-f1
<cassidy> ok I'll try that
<smb> apw, So a dmesg from a lucid disk is ok? Can do that relatively quick
<apw> smb, s'ok not worth it, just found the change which you are being hit by
<smb> apw, a ok. more smartness?
<apw> more safety
<smb> *sigh*
<apw> pgraner, looked over latest pres. and it looks much better
<ogasawara> has anyone seen RAOF about?
<vanhoof> Sarvatt: ^^
<Sarvatt> RAOF is at the X developers summit
<ogasawara> Sarvatt: maybe you can answer my question then... I need to know if we need to drop those KMS disablement patches from the kernel.
<Sarvatt> yeah, we've already switched the server to use fbdev
<ogasawara> Sarvatt: ok cool, I'll drop the patches then.  thanks.
<pgraner> apw: thanks
<Sarvatt> well, xserver with the change isn't uploaded yet, he didn't find a sponsor before he had to get on the plane
<Sarvatt> but he does intend for those to go away yeah
<apw> Sarvatt, if we don't drop them today and upload them they won't make the release ...
<apw> kernel freeze is tommorrow
 * Sarvatt nods
<Sarvatt> i'll try to find a sponsor for his packages, things are crazy right now because the latest mesa upload broke unity on intel
<ogasawara> that's not good
 * ogasawara looks around for diwic and jj as they have outstanding patches we need by today too
<bjf> ogasawara: diwic is on a walkabout today
<ogasawara> bjf: hrm, his might have to wait for an SRU then to Maverick
<apw> ogasawara, ok confirmed the archive goes to freeze mode at midnight tonight (and thats UTC I assume)
<apw> so even now we are going to have to stroke the arm binaries through
<ogasawara> apw: yep, which means I want to upload within the next few hours to be safe
<apw> ogasawara, yep
<apw> smoser, how much output would you say comes out before the lost information
<ogasawara> apw, tgardner: what about ti-omap4, is that good to go?
<apw> not sure that has changed has it?
<tgardner> ogasawara, I was kind of waiting to see if the cache line bounce fix helped, but it doesn't really seem to be a complete fix. I could upload with lag's timer config patch.
<ogasawara> apw: I saw tgardner applied lag's high res timers config patch, so I think that's it
<apw> lag, know of anything else
<smoser> apw, well, http://paste.ubuntu.com/494225/ . look at line 520 and on.
<smoser> so we get kernel output to console
<smoser> then, ramdisk output to console
<smoser> then early forked command output
<smoser> then exec upstart
<smoser> at some point it disappears for 6 seconds or so
 * lag checks
<lag> Nope
<smoser> so in that pastebin, we're missing lines like "[1]: X, could not write to /handler"
<smoser> where X is 2-5
<tgardner> ogasawara, given lag's lack of patches for now I'll wrap up ti-omap4 and git 'er done
<ogasawara> tgardner: awesome, thanks.
<smoser> i wonder how nefarious "mountall: Disconnected from Plymouth
<smoser> " is
<smoser> as that is the message that is written to the console when all else is lost
<apw> smoser, indeed, so the hello world is missing right ?
<apw> is the first thing missing
<smoser> no
<smoser> the initital "hi world" gets there (line 900)
<smoser> the second hi world goes to a file in the filesystem
<smoser> (and it gets there, but thats not surprising)
<apw> smoser, right but the one after the 'wait till / is read-write' loop
<apw> is the first thing missing
<smoser> no. that one goes to a file
<smoser> see the { } >> ${out}
<smoser> the things missing is "echo "[${SECONDS}]: $i, could not write to ${out}""
<apw> you don't know that do you?
<smoser> for all the failures (there were 4 of them)
<smoser> i dont know what ?
<smoser> in /handler, i know that : "[2]: wrote to /handler after 5
<smoser> "
<apw> the first thing to the console after we have transitioned from r/o to r/w is "wrote to ${out} after $i"
<apw> ahh
<apw> so we are missing 3,4,5 of that and 1-6 of the second loop plus the 'write to out after $i'
<apw> all of that is missing
<smoser> missing 3 and 4, 5 wouldn't be written because the /handler write would succeed.
<smoser> right.
<smoser> and then "reports" messages up to i-6
<smoser> i=6
<apw> smoser, can you disable plymouth i wonder
<apw> like rename it away and see what happens
<smoser> i can try
<smoser> apw, if you want to poke or look at the instance you can get to ubuntu@ec2-67-202-31-38.compute-1.amazonaws.com
<smoser> i'll try removing plymouth
<tgardner> ogasawara, ti-omap4 is in the pipeline
<ogasawara> tgardner: thanks
<cking> having fun with your nick lag?
<lag> See #ubuntu-arm for details :)
<lag> ogra: Was using my name in vain, so I changed it
<ogasawara> jjohansen: just the person I've been waiting for
<ogasawara> jjohansen: I need your patches asap as the archive freezes at midnight UTC, ie in 8 hrs
<jjohansen> hey, sorry I am getting the pull request together now
<ogasawara> jjohansen: perfect
<apw> jjohansen, fyi the lost output during boot issue is looking like its a plymouth issue; we are off the hook
<smoser> apw, thanks.
<jjohansen> apw: yeah I was just talking to smoser
<apw> ahh ok, i'll shut up then :)
<smoser> apw, you have a suggestion other than just race as to why i would see it on ec2 but not euca ?
<tgardner> smoser, just the fact that its a race makes it somewhat random
<jjohansen> apw: yeah it is strange, as setting the console in upstart was working for me but not smoser
<apw> smoser, either timing, or the plymouth support for passing on the data works with not-ec2 and not with it
<jjohansen> so it is definitely a race
<apw> perhaps its plymouth is unable to open the console before it redirects it or something
<apw> perhaps its plymouthd which hit the race
<smoser> well, but we should then have been able to work around that
<smoser> with our hack of keeping the fd open
<smoser> so, for the moment, i wont care.
<smoser> now on to looking at plymouth. thanks apw and jjohansen for your help at redirecting my pointed finger.
<smoser> :)
<apw> plymouth may yet point back at us i guess
<jjohansen> hehe
<ogasawara> jjohansen: thanks for the patches.  I assume that's all of them?
<jjohansen> ogasawara: one more comming, for EC2
<jjohansen> it should be in the mail queue
<ogasawara> jjohansen: ack, /me looks for it
<apw> ogasawara, update on the armel issue, looks to be simply the packages being stuck in NEW, i've gotten an AA to sort them but cannot confirm yet its the only issue.  but its likely that was it
<ogasawara> apw: ok cool.  Am planning to upload in about 10min.
<apw> ogasawara, GruMaster is rebooing and will re-test the update then
<apw> hopefully that will be 'ok'
<ogasawara> apw: k, lemme know the results.  I'll wait to push the button till I hear from you.
<ogasawara> apw: I want to do a quick test build anyways before uploading
<apw> ogasawara, best i can tell the arm issue is confirmed ok, ie. was the binary NEW issue only, so from my side you are good to go
<ogasawara> apw: sweet.  my build should finish in a few minutes and then I'll upload.
<apw> ogasawara, there may be a string issue with linux-meta, but that is very minor and we've got more time on that
<ogasawara> apw: ack
 * ogasawara lunch
 * ogasawara really goes to lunch
<hallyn> regarding bug 639712, i assume there is a particular reason why CONFIG_DMAR=n ?
<ubot2> Launchpad bug 639712 in libvirt (Ubuntu) "PCI Pass Through via libvirt cannot remap IRQ's (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/639712
<achiang> random question, purely for informational purposes - does ubuntu and/or canonical have a test farm of random hardware for kernel folks to use?
<nigelb> yes, they are called volunteer testers :p
<achiang> nigelb: ha.
<achiang> the case i'm thinking of is, random user reports an issue; instead of kernel developer asking the user to run a test and wait (indefinitely?) for the results, the developer could just try reproducing on the appropriate machine in the farm
<nigelb> that I don't know
<achiang> again, i'm not necessarily proposing that we do such a thing -- only asking if such a thing already exists.
<achiang> lamont: ^^ ??
<JanC> achiang: I know there is some test hardware, certainly for the hardware that's "certified" to work with Ubuntu
<JanC> so, hardware from the companies that pay Canonical
<JanC> a large farm of random hardware would be rather expensive I think  ;)
<JanC> well, maybe not for older hardware (people could volunteer their old hardware for that)
<achiang> JanC: nod.
<achiang> thanks
#ubuntu-kernel 2010-09-16
<JanC> maybe we could set up a distributed test farm of machines spread all over the world, but then a lot of care should be taken that it is done in a very secure way (we don't want it to be taken over by a spammer or DDoS network or such!)   ;)
<bjf> bug 640033
<ubot2> Launchpad bug 640033 in grub-installer (Ubuntu) "maverick daily server iso (Sept. 15, 2010) fails to install grub on raided drive set (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/640033
<melkor> I have been using the maverick backports lts kernel and today on an update it wouldn't fully install.
<apw> melkor, that probabally means it has not been fully built in terms of linux, lbm, and meta, should sort itself shortly
<lag> diwic: Hi
<diwic> hi lag
<lag> I need your help? 
<lag> What's it like to be wanted? :)
<diwic> lag, I like to help people :-)
<lag> Have you heard of an sdp4430?
<diwic> nope
<lag> What about a twl6040?
<diwic> nope
<lag> sound/soc/omap/sdp4430.c
<lag> sound/soc/codecs/twl6040.c
<lag> The sdp4430 is an audio chip
<lag> The twl6040 is a companion CODEC
<lag> They are connected together on the Panda
<lag> They used to be connected together on the Blaze
<diwic> I haven't looked into the soc stuff at all, but there is a first time for everything, I suppose.
<lag> Sound works on the Blaze, but not on the Panda
<lag> I would like to know how to debug
<apw> jjohansen, smb, i just became input only on mumble ... i can hear you but my machine X has hung ... ARGS
<diwic> so no audio at all, right?
<lag> Right
<diwic> is the card detected? see /proc/asound/cardX and "aplay -l"
<lag> I have two versions of the image
<lag> One contains a few hacks - I'll send you the email
<lag> Sent
<diwic> lag, so you could either read my triaging class I had on IRC last Saturday
<lag> Was that logged anywhere?
<diwic> lag, or you could upload an alsa-info to canonical's pastebin and let me do it for you
<lag> How do I do that?
<lag> It is just a command line thing?
<diwic> https://wiki.ubuntu.com/Audio/AlsaInfo
<diwic> Triaging classes: http://irclogs.ubuntu.com/2010/09/11/%23ubuntu-classroom.html
<lag> Okay
<lag> Did you see those files I sent you?
<lag> I'm not entirely sure what they set up
<lag> Once applied to the image alsa-info provides this: http://paste.ubuntu.com/494653/
<lag> I'll also run alsa-info on a system where the hacks aren't applied 
<lag> diwic: --^
<diwic> so regardless of hack or not, sound is not working?
<lag> Correct
<lag> For me at least
<lag> I know someone with the same board that sound is working
<lag> I'll ask him to send me his kernel, but he's not up until this afternoon
<diwic> so the files there sets the mixer in specific ways
<lag> Without them my Sound Preferences applet says "Dummy Output"
<lag> With them it says SDP4430
<diwic> that's probably the default.pa doing that, which opens the chip in a specific way
<lag> Again, without them my volume icon in the panel is greyed out
<lag> Okay
<lag> This is how it looks without the files included: http://paste.ubuntu.com/494657/
<diwic> I don't know much of those chips unfortunately
<diwic> but you could try "speaker-test -c2 -Dhw:0,0" and see what happens
<lag> Playback open error: -22,Invalid argument
<lag> Oh, let me try the other image
<diwic>  "speaker-test -c2 -Dhw:0,0 -F S32_LE -f 48000" ?
<diwic> sorry
<diwic>  "speaker-test -c2 -Dhw:0,0 -F S32_LE -r 48000" 
<lag> Just booting
<lag> Is there any way to ask the system which port it's playing the sound out of?
<diwic> If you run "aplay -l", it should give you a list
<diwic> is that the list you're looking for?
<lag> I don't hear any sound from speaker test
<diwic> so then there's probably something on the chip, e g routing-wise or mixer-wise that needs fixing
<lag> The thing I don't understand is that the same configuration was used with the board's predecessor
<lag> So aplay -l gives me a list of devices
<lag> But the kernel must know which device/port it's attempting to play sound out of?
<lag> On board speaker, headphone jack, aux, etc
<diwic> and you can select which one in your call to speaker-test (-Dhw:0,x) where x is the number
<lag> Each device is card0 - subdevices 1/1 - subdevice #1
<lag> How do I differentiate? 
<diwic> card 0: SDP4430 [SDP4430], device 3: Tone Playback null-codec-dai-3 [] 
<lag> Oh card0 device0
<diwic> = hw:0,3
<lag> 0:3?
<lag> Got it 
<lag> Let me try
<diwic> but it might also be that the outputs are controlled by either the mixer or some other magic in the driver
<diwic> with "alsamixer -Dhw:0" you can fiddle around with the mixer settings
<lag> Okay, leave it with me
<diwic> okay, I'll go and have some lunch now
<lag> diwic_lunch: speaker-test doesn't work on my desktop either?
<diwic_lunch> lag: for speaker_test, try "plughw" instead of "hw"
<lag> What does: "Sample format not available for playback: Invalid argument" mean?
<lag> Setting of hwparams failed: Invalid argument
<diwic> lag, so, your hardware only supports one or a few samplerates and sample formats (e g 16 bit signed, little-endian). If you use "hw" in your argument to speaker-test (or in default.pa, btw), it will use the format you specify and only that. If you use "plughw", there will be a plug layer added that converts the sample-rate and sample format for you
<diwic> lag, so "Sample format not available for playback" means you tried to use a sample format the hardware does not support.
<lag> With plughw:0,0 I get: Playback open error: -22,Invalid argument
<lag> With plughw:0,8 it looks like it works, but it's actually silent and gets stuck on "0 - Front left"
<diwic> lag, is that on the omap or on your desktop?
<lag> omap
<lag> When I use hw or plughw with 0,6 I get sound from HDMI
<diwic> so if HDMI works, you're actually getting some kind of sound, that's good news I suppose
<apw> that hdmi is on and nothing else is the inverse of most of our normal issues
<diwic> apw, :-) 
<apw> lag, on my lappy to get hdmi i have to switch 'hardware' on sound preferences
<apw> r
<apw> the profile on the hardware tab
<diwic> apw, that's on the gnome/pulseaudio level. We're doing things at the ALSA level currently. But you have a point. lag, is PulseAudio running? 
<diwic> lag, perhaps that's interfering with our tests.
<lag> apw: There is nothing in the HW tab
<lag> diwic: Yes it is
<lag> As is gconf-helper
<diwic> lag, try stopping it and see what that does for the tests ( https://wiki.ubuntu.com/Audio/StopPulseaudio )
<lag> Still nothing
<lag> [ 1361.951721] asoc: no valid backend routes for PCM: SDP4430 Media 
<lag> I'm assuming that's bad
<diwic> lag, I'm assuming likewise...
<diwic> lag, I grepped the kernel tree for "backend routes" but couldn't find anything
<lag> sound/soc/soc-core.c
<lag> Near line 505
<ogra> diwic, lag is talking about omap4, not omap ;)
<ogra> (different tree)
<diwic> okay, I was just checking sound-2.6.git
<jdstrand> smb: hi. I haven't read my email yet but I wanted to mention that I'm here now to shuffle the security kernel along until kees comes online
<jdstrand> smb: whenever you're ready
<smb> jdstrand, The src package are all on chinstrap now, up to now I did only a regression test on lucid-amd64 and hardy-xen. More test kernels are either building or pending upload
<smb> As the changes modify only compat stuff probably amd64 only test might be ok
<smb> But maybe better do some i386 as well
<tjaalton> jdstrand: you got one ready?
<jdstrand> smb: so are these something I should upload to the security ppa?
<jdstrand> tjaalton: no, smb is preparing them
<tjaalton> jdstrand: ok
<smb> jdstrand, If we want to speed up things we can upload them and should anything come up throw them away
<jdstrand> smb: I think that would be a good idea. I had a glance at some of the upstream commits and they didn't seem too intrusive
 * jdstrand goes to upload them
<smb> tjaalton, I currently have them only on chinstrap. jdstrand would it be ok to place kernel packages somehwere open?
<smb> jdstrand, Beside of breaking the build when backporting they seem to be ok. :-P
<jdstrand> we can build them in the ubuntu-security-proposed
<apw> ogasawara, about ?
<jdstrand> smb: it's just the too issues that came up yesterday, right?
<jdstrand> s/too/two/
<smb> jdstrand, yes only those two
<jdstrand> k
<tjaalton> smb: do you have them for jaunty as well?
<smb> tjaalton, yes
<tjaalton> smb: excellent
<jdstrand> give me a few minutes and I'll let you know they are uploaded
<smb> jdstrand, issue #1 seems to affect all, issue #2 only jaunty-maverick
<smb> jdstrand, Do you have an exploit for compat1?
<jdstrand> I think mdeslaur came across one this morning
<jdstrand> mdeslaur: did you play with it any yet?
<jdstrand> mdeslaur: ^
<apw> i suspec that is best discussed in private
<jdstrand> apw: it is public
<jdstrand> but we can go somewhere else
<apw> heh but pointing people to the exploit just makes it even easier 
<apw> the rest of the discussion is fine, just that one titbit
<jdstrand> sure (though it was pointed out to us in another public channel), but I take your point
<mdeslaur> smb: the exploit we have only works for RH, it would need to get all the ubuntu offsets added to it
<jdstrand> mdeslaur: can you discuss in #security
<mjg59> Everyone hates us :(
<mdeslaur> haha
<tjaalton> mdeslaur: the one "rh specific" exploit works fine on jaunty as well
<tjaalton> confirmed here
<mdeslaur> tjaalton: the one for issue #1?
<tjaalton> mdeslaur: compat1, yes
<smb> So they hate us too. :)
<mdeslaur> tjaalton: oh, I need to try it then
<mdeslaur> tjaalton: thanks
<tjaalton> the patch didn't look ksplice'able.. :/
<tjaalton> at least not trivially
<jdstrand> smb: I'm guessing ogasawara is taking care of maverick?
<smb> jdstrand, ack
<smb> jdstrand, She already has uploaded
<jdstrand> smb: can you respin 2.6.31-22? it has lucid-security for the distribution name
<smb> jdstrand, doh
<smb> jdstrand, yes
<jdstrand> smb: thanks
<jdstrand> smb: will there be new kernels for lucid arm?
<smb> jdstrand, I believe kees agreed that we don't do them as this is 64bit only
<jdstrand> smb: ok cool
<tjaalton> smb: do you have an ETA for the debs?
<smb> tjaalton, If they should come from sec-proposed jdstrand may have
<tjaalton> smb: ok, thanks
<jdstrand> smb: can you respin dapper? the upload was rejected: "The source linux-source-2.6.15 - 2.6.15-55.87 is already accepted in ubuntu/dapper and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload."
<smb> jdstrand, wtf, *sigh* yes 
<jdstrand> hardy, jaunty and lucid are now in https://edge.launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages
<jdstrand> smb: I think you meant to do this, but I want to be sure. 2.6.32-25.43 is in lucid-proposed, but we just uploaded 2.6.32-24.43 to lucid-security
<smoser> apw, thanks for your help yesterday. bug 606373 is now fixed.
<ubot2> Launchpad bug 606373 in plymouth (Ubuntu Maverick) (and 5 other projects) "cloud-init output does not get to console when booted with pv-grub and ramdisk (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/606373
<smb> jdstrand, Yes this one of all is intentional
<jdstrand> hehe, cool
<smb> jdstrand, I'll do a re-upload there asap
<jdstrand> tjaalton: ^ sources are uploaded and building presently
<tjaalton> jdstrand: yeah, getting them now, thanks :)
<tjaalton> i've got 8 cores to build it on
<apw> smoser, most excellent i like bugs that end 'fixed'
<smoser> me too, especially *before* a freeze :)
<apw> smoser, heh there is that, what was at fault in the end?
<smoser> you can read the final 2 comments.  but basically i ended up adding 'console=hvc0' to the kernel command line.
<smoser> that way plymouth repeats the data it stole to hvc0
<smoser> if you dont have console= it doesn't repeat it for you.  there is no way i could see to tell it "please repeat it to /dev/console"
<apw> smoser, i don't think it can repeat to /dev/console as it is stealing the output to there via an ioctl magic
<apw> so it would self recurse to itsself if it pushed it into there
<smoser> well, it unsteals it on exit
<smoser> so it could buffer, unsteal, write
<apw> smoser, ahh i see, yes it could do that 
<smoser> but i guess that would generally be broken for its purposes of prompting and such
<smoser> or, i guess, it could just not steal (I've read "You shall not steal." somewhere before)
<jdstrand> smb: ok, dapper and karmic uploaded
<ogasawara> apw: did you need something earlier
<jdstrand> smb: now that they are building, I am going to let you and kees finish the testing/publication since I have a stack of mozilla updates I need to get out today. if you need me, holler
<smb> jdstrand, ok sure
<smb> jdstrand, Thanks for getting them building
<apw> ogasawara, wondered if you remembered dropping some nouveau noaccel patches in maverick
<ogasawara> apw: it's not ringing a bell
<ogasawara> apw: but if they were there and are not now, then it likely happened
<jdstrand> smb: sure, np :) I went ahead and updated the cve tracker marking maverick as released, dapper and hardy not affected by CVE-2010-3301, and everything else 'pending'
<ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3301)
<smb> jdstrand, most of it should have been in our branch of it. beside the maverick things
<smb> jdstrand, at some point it might be good to merge them back
<jdstrand> smb: ack
<apw> ogasawara, ack will let you know the outcome of the patch testing
<ogasawara> apw: looks like the archive will officially freeze at 1700 UTC
<apw> ogasawara, hrm 
<apw> i presume they ahve been waiting for the mesa/untity fixes
<tgardner> ogasawara, so I still have time to upload ti-omap4 ?
<diwic> so if I want to get a fix into libffado + udev within the next two hours, who should I bug about that? :-)
<bjf> diwic: talk to the hand
<diwic> bjf, the hand? If you mean myself, I'm not a MOTU.
<apw> didn't think that was going to translate
<tgardner> ogasawara, nm, mpoirier's patch is for maverick master
<bjf> diwic: http://en.wikipedia.org/wiki/Talk_to_the_hand
<ogasawara> apw: not sure, but it sounded like Daviey would appreciate a few extra mins to get a quick fix.
<ogasawara> apw: so robbie said he'd hold off till 1700
<ogra> nah,. robbie was bribed with a kettle full of beer it seems
<apw> i can't see us wanting to spin master at this point either way
<ogasawara> yah, I'd like to avoid a respin of master if we can help it
<apw> the bug here is that macpros need noveau.noaccel to boot on the live CDs with this kernel, seems we dropped the fixes from lucid (likely resonably)
<apw> so its release notable anyhow
<apw> and i don't have confirmation that putting the patches back helps yet, so i can't even suggest we put it in
<ogasawara> apw: doesn't cooloney or cnd have a macpro?
<diwic> bjf, aha :-) Just like I thank my editor for "keeping tabs" instead of converting them to spaces...
<apw> ogasawara, yeah ... strange neither of them has mentioned it
<bjf> apw, are you sure they are dogfooding?
<apw> bjf, likely not
<tgardner> apw, I blasted HEAD on ubuntu-maverick-meta ti-omap4
<apw> tgardner, ack
<apw> tgardner, what did i do, push the tag and not the branch or something silly?
<tgardner> apw, I homogenized the commit log entry and redid the tag
<tgardner> JFo, bug chat?
<JFo> ooh, yes
<JFo> sorry was distracted
 * tgardner lunches
 * jjohansen -> lunch
 * ogasawara lunch
<vanhoof> does anyone know off hand the max memory ubuntu will support?
<vanhoof> 10.10. specifically, i386+pae and amd64
<tgardner> vanhoof, I don't think there is a practical upper limit, though PAE will incur some overhead.
<vanhoof> tgardner: gotcha ... looking at a machine that can scale up to 192gb :)
<tgardner> vanhoof, I have some amd64 servers with 132GB
<jcrigby> tgardner, is there a way to override module checking for just one modules?
<vanhoof> tgardner: cool, this would typically call for i386, which has me fearful 
<achiang> vanhoof: unlike cpus, there's no hard coded limit in .config for memory
<vanhoof> achiang: well im wondering max vs supported, along w/ factoring in this might require i386
<vanhoof> i386 seems like a bad idea here
<achiang> yes, i386 would be bad
<tgardner> jcrigby, yep, lemme check.
<tgardner> vanhoof, i386 is definitely a bad idea
<tgardner> jcrigby, perhaps not. I was thinking perm-blacklist, but excludes symbols from the ABI check. Maybe you could just hack out the module name from the ABI module file?
<tgardner> that excludes*
<jcrigby> tgardner, the hack will work.  I had to move a driver from m to y
<tgardner> jcrigby, you can always add an ignore.modules file
<jcrigby> tgardner, maybe I'll just do that
<tgardner> but that ignores the whole module check
<jcrigby> tgardner, while I have you here I'll mention that I have a new kernel coming.  Just a sync with last ubuntu
<jcrigby> I know the freeze is on so I'll let the important people figure out how to get it through
<tgardner> jcrigby, ok.
<ogasawara> jcrigby: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Overriding module check failures
<ogasawara> jcrigby: so I think if you create a modules.ignore file and add the name of the module to that file it should ignore it in the checks
<jcrigby> ogasawara, thanks
<jcrigby> ogasawara, ok dumb question do I put it in the new or old abi directory?
<jcrigby> ogasawara, its got to be old right since new is generated
<tgardner> jcryour new abi directory doesn't exisat until prepare time
<lag> Has anyone else been taken into #ubuntu-unregged?
<ogasawara> jcrigby: add it to the old
<jcrigby> tgardner, ogasawara: ok thanks
<smoser> anyone have thoughts : http://paste.ubuntu.com/494924/ (bug 567334)
<ubot2> Launchpad bug 567334 in linux (Ubuntu) (and 1 other project) "blocked tasks delay cloud-init for 240 seconds (affects: 2) (heat: 31)" [Medium,Triaged] https://launchpad.net/bugs/567334
<smoser> what could cause the "blocked for more than 120 seconds." messages ?
<tgardner> smoser, a really high load average, or the host has an incorrect concept of time.
<smoser> hm.. well, it isn't time being bad like skipping 120 seconds. its not htat bad.
<tgardner> smoser, a really high load average?
<smoser> i've seen it at boot on ec2, this is someone seeing it long after boot.  by design boot should be as high load average as possible, but doesn't normally last 120 seconds.
<tgardner> smoser, if the hypervisor is over subscribed it might happen
<smoser> well, yeah, i thought you might say that.
<smoser> and of course a.) it *is* oversubscribed, and b.) theres nothing i can do about it.
<smoser> but i just can't imagein its that over subscribeed, to where performance was unable to boot in 120 seconds or something.
<tgardner> smoser, I assume your instance came up eventually and stopped puking in the log?
<smoser> the times i've waited, yeah, ssh server eventually does come up
<tgardner> smoser, have you reproduced this since your plymouth hack?
<tgardner> console hack, I mean
<smoser> personally no.
<smoser> let me see if the person who just did today was using an image from today
<tgardner> smoser, when these tasks recover its always been load related
<tgardner> smoser, I can reproduce it on bare metal using 'stress'
<smoser> hm..
<smoser> so, the person reported it just now was running apache, ~ 30 minutes after boot, but not with console=hvc0 on cmdline
<tgardner> smoser, thats more likely to have an impact at boot time.
<ogasawara> tgardner: your lts backports kernel blueprint... can I postpone the "interlock with QA to set support levels" and the "investigate MIR" work items?
<ogasawara> bah, I just missed him
<kees> ogasawara: did maverick get smb's fixes for mlock + the new stack guard page?
<ogasawara> kees: I believe so, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=1ccc5359a8f055b153a2e0cfec02a594a8443360
<ogasawara> kees: ^^ that commit correct?
<kees> looks like it, yeah
<kees> weird. which build did that make it into?
<kees> I'm running Ubuntu 2.6.35-20.29-generic 2.6.35.4
<kees> and it seems to be failing
<ogasawara> kees: I think it just got into the most recent, 2.6.35-22.32
<kees> ah-ha! I will go reboot again
<ogasawara> kees: as I recall he mentioned he had a last minute patch for me before freeze
<kees> ogasawara: excellent.
<undriedsea> Hey everyone, I am having trouble calling set_pages_rw (from <asm/cacheflush.h>) in my kernel module (I get Unknown symbol set_pages_rw). Does the kernel not export this function? Is there a way to find out what the kernel version of a kernel is exporting?
<undriedsea> Should I just read the address for the function from System.mapxxx?
<achiang> undriedsea: it sounds like you're writing an out-of-tree module?
<undriedsea> yes
<achiang> undriedsea: anyway, it also sounds like you shouldn't be using that API anyway, based on comments in the header file
<achiang> and reading the address from System.map is a *really* bad idea
<undriedsea> why is that?
<achiang> undriedsea: in general, the kernel is specific about what it exports. if it's not exporting a symbol, there's usually a good reason for it, such as proper encapsulation, not wanting out-of-tree modules to become dependent on it, etc.
<achiang> undriedsea: in any case, what's wrong with using set_memory_rw ?
<achiang> that symbol is exported GPL
<undriedsea> I am working on a project that requires my kernel module to modify the system call table. Since it is no longer exported, I was using System.map to find it and I was setting it to writable so I can make my modifications 
<undriedsea> is it, let me double check something
<mjg59> undriedsea: If you're working on something that wants to modify the system call table then you can implement it in any way you want - upstream is never going to approve
<mjg59> There's no "correct" way to do it
<achiang> right. i was thinking about how to say that... ;)
<undriedsea> I have no intent of it getting accepted, I only want my end users to be able to load it
<mjg59> You have no guarantee that any method you use will continue working with even minor kernel updates
<mjg59> So just ship your end users a modified kernel
<mjg59> It's the only way to be sure
<undriedsea> really-- :( thanks
<undriedsea> If I forgot to put MODULE_LICENSE ("GPL"); in my mod, would that by why  set_pages_rw was not working?
<achiang> yeah, i guess just EXPORT_SYMBOL(set_pages_rw)
<undriedsea> why is reading from the System.map a bad idea?
#ubuntu-kernel 2010-09-17
<kees> ogasawara: looks like -22.32 is missing the guard page change
<ogasawara> kees: hrm, were there additional patches besides the one I mentioned earlier?
<undriedsea> Hi everyone, I'm having a problem with a kernel module crashing when I attempt to modify the system call table. Which would be expected, except that I have made its page in memory writable before attempting this feat. Any ideas would be very much appreciated :) http://codepad.org/W3ThQbb8
<AceLan_> undriedsea: wow, interesting
<undriedsea> lol, are you being sarcastic Ace? I know its not terribly complex, but it has me stumped
<AceLan_> undriedsea: no, I never thought of you can modify sys_call_table by that way
<jk-> undriedsea: are you just trying to catch calls to sys_open?
<undriedsea> yes, but this is just a test. I have a bunch of system calls I need to hook into at a low level. LD linking is not good enough for me because apps could call the syscall directly and not use the C lib, and I need to handle that
<lifeless> undriedsea: there is a runtime patching system for the kernel some US guys wrote a few years back; they do this sort of thing and much more complex too - have a look into that
<jk-> are you looking to modify the syscall's behaviour, or just monitor it?
<undriedsea> in this test I am monitoring. I will be changed the behavior
<undriedsea> *changing 
<undriedsea> I will take a look at that lifeless. I still, for my own sake, would really like to understand why my code does not work
<jk-> undriedsea: also, you can still do this in userspace via ptrace()
<undriedsea> thanks jk, I thought about that, but for the project the context switch overhead would kill performance
<undriedsea> I realize this is the old/dirty way to intercept a syscall, but it is also very fast- and I can't think of why that code does not work. However, I must confess- I have not spent much time with this kernel 
<jk-> undriedsea: so what's the oops message you're seeing?
<undriedsea> Sep 16 19:51:02 kdev kernel: [  145.012726] BUG: unable to handle kernel paging request at ffffffff81551390
<undriedsea> that is the address of the system call table
<undriedsea> or actually sys_call_table[__NR_open]
<jk-> could you paste the rest of the log?
<jk-> err, pastebin, not paste in the chan
<undriedsea> sure http://codepad.org/O01qFsdz
<undriedsea> Thank you for bothering to take a look :)
<jk-> and what's the instruction at init_module+0x51 ?
<jk-> (could you pastebin a disassembly of init_module?)
<AceLan_> undriedsea: I got BUG: at set_memory_rw() function call
<AceLan_> undriedsea: not OOPS
<undriedsea> that is interesting, what is your platform? I am amd64
<undriedsea> Also, did you change the sys_call_table address to match your own system AceLan?
<jk-> AceLan_: yeah, it's probably bugging in change_page_attr_set_clr, because the page address is not page-aligned
<AceLan_> undriedsea: a normal i386 kernel
<undriedsea> jk, can I use hexdump to do that?
<AceLan_> undriedsea: sure, I changed the address
<jk-> undriedsea: objdump -d 
<jk-> undriedsea: you're probably seeing that WARN_ON_ONCE too
<undriedsea> jk: the dump http://codepad.org/FcHuSS0c
<undriedsea> jk: do I need to make sure my call to set_memory_rw is 4k aligned?
<jk-> undriedsea: it should be, but that's not what's causing the oops
<jk-> also, are you sure that this disassembly matches the module that you inserted to cause this oops?
<undriedsea> Maybe- I ran that objdump on the .o, should it have been on the .ko ? (n00b sorry...)
<jk-> on the .o is fine
<jk-> but the oops log reports that your init_module function is 0x70 bytes in size, whereas the disassemly would indicate that it's 0x49 bytes
<AceLan_> undriedsea: read this # http://www.downloadpipe.com/forums/linux/Problem-set_memory_rw-ftopict76420.html
<AceLan_> system call table is on .rodata section and set_memory_rw() doesn't
<AceLan_> allow change attributes on .rodata sections(not .text) 
<undriedsea> my .ko dump is much larger
<undriedsea> Thanks ace!
<undriedsea> I guess I will have to modify the page table directly to accomplish my goal
<undriedsea> :(
<jk-> or patch sys_open
<AceLan_> undriedsea: yes, you have to export sys_call_table 
<undriedsea> That would require my end users to install a custom kernel wouldn't it, rather than just install my module?
<AceLan_> undriedsea: you have to modify the kernel :(
<jk-> but this is all pretty ugly, what are you actually trying to do?
<jk-> AceLan_: exporting it will only expose the linkage, will still be able to refer to it by symbol address
<undriedsea> I am writing a process live migration module, I need to capture sys_calls and translate file handles, process IDs etc. For example, a process might get moved to a machine where its PID conflicts with an existing PID, so I need to hide this
<undriedsea> If I was writing this 6 years ago before all this stop exporting the sys_call_table, make it RO nonsense, it would be much easier :)
<AceLan_> wow, sounds so cool, process moves among machines
<undriedsea> Well, I hope it is cool when I am done, or I will be working on my masters project a looong time lol :)
<AceLan_> undriedsea: how about not real move the process, indtead of recreating the same one on another machine?
<undriedsea> Those are the same things, I am doing two things, replicating the process state, and hiding namespace issues (file handle number, PIDs, semphore ids, etc)
<undriedsea> I cannot change the PID even after moving becuase the programmer of the application may have made a call eariler to get the PID and their code might now be depending on that value
<AceLan_> right, very reasonable
<undriedsea> There are other methods besides doing what I am doing, but they are either slow (because the involve kernel/user-mode context switches) or they only capture syscalls made through the standard libraries (which means I could not migrate applications which directly make system calls)
<AceLan_> undriedsea: have you to use 2.6 kernel? I think modify sys_call_table in 2.4 kernel is much easier
<undriedsea> So I guess I will be directly changing the page table using the low level instructions because the kernel is silly and won't do it
<undriedsea> You are correct, however, I want people to be able to do useful things with the result of my project
<undriedsea> I could just make my own kernel build that turns the security off in 2.6 too, but ideally, I only want people to need to load a module (if at all possible)
<jk-> undriedsea: what are you doing about kernel state - open files, sockets, etc?
<undriedsea> replicating it
<jk-> how?
<undriedsea> By keeping track of kernel state of live migration processes and recreating that state on the new host. The unique identifier might not match, but my namespace translation later takes care of that
<undriedsea> or will, I am just getting started
<jk-> undriedsea: have you read Eric Roman's survey of Checkpoint/Restart implementations?
<jk-> undriedsea: and Zhong and Nieh's CRAK paper?
<undriedsea> CRAK and ZAP yes, I will look for Erics
<undriedsea> I found the code that is killing me,  832        if (!pgprot_val(mask_set) && !pgprot_val(mask_clr) && !force_split)
<undriedsea>  833                return 0;
<undriedsea> http://lxr.linux.no/#linux+v2.6.31/arch/x86/mm/pageattr.c#L818
<jk-> you can control the fd table, so you don't need to worry about translating FDs
<undriedsea> fd, file descriptors?
<jk-> yep
<undriedsea> cool, that will be nice
<undriedsea> When looking at System.map, what do the single character values after the address and before the symbolic name denote?
<AceLan_> undriedsea: The "How to get sys_call_table" and "Simple sys_call_table hook" might useful # http://www.slideshare.net/fisher.w.y/rootkit-on-linux-x86-v26
<undriedsea> AceLan, that is very interesting, thank you
<lag> diwic: Hi
<diwic> Hi lag
<lag> I'm assuming you have a vast array of test audio files?
<lag> Do you have any S32_LE?
<diwic> lag, naah, but use the plug layer and it will convert it for you
<lag> Okay
<lag> Cheers
<lag> I'll probably be pestering you a few times today - stay alert ;)
<diwic> lag, or if that doesn't work, I can create one in audacity for you
<lag> Cool, thanks
<diwic> ogasawara, ping
<lag> diwic: Can you come into #ubuntu-arm?
<bjf> JFo: cranberry is now running lucid
<JFo> excellent
<diwic> bjf, I talked to takashi about his dailies, he said they were created after midnight, his time. So if you run your script approx UTC+3, that would be optimal
<bjf> diwic, thanks, I can make that happen
<diwic> bjf, great :-)
<bjf> diwic, where does takashi live?
<diwic> bjf, in Germany I believe. 
<diwic> bjf, which is UTC+1 +DST
<bjf> diwic, ok, that puts him 9 hours ahead of me
<diwic> bjf, and me as well then - amazing you're up already ;-)
<smb> diwic, UTC+2
<bjf> diwic, it's 7 a.m. already! where has the day gone?
<diwic> smb, UTC+1 in winter and UTC+2 in summer, right?
<smb> right
<diwic> same as here.
<diwic> smb, you are from Germany as well, right?
<smb> I am, yes. I am never sure about Takasi thoug. :)
<bjf> diwic, so his midnight should be my 15:00 
<smb> People tended to believe GregKH to be in Germany, too as he has a suse.de email address as well. 
<smb> bjf, Its 4:10pm here if that helps
<JFo> brb
<bjf> smb, the math still works out :-)
<bjf> diwic, time on the cron job has been adjusted
<diwic> bjf, thumbs up
<cnd> ogasawara, manjo: bug 641320
<ubot2> Launchpad bug 641320 in linux (Ubuntu) "Touchpad is not working since last kernel update in maverick (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/641320
<cnd> due to the new ALPS patch
<cnd> manjo, why did you push the dell patch instead of the patch on LP that had bug fixes in it?
<manjo> cnd, I picked the patch from the LP 
<manjo> cnd, and jerone tested it at dell 
<cnd> oh, someone on the LP bug thought it wasn't that patch
<cnd> they thought it was the upstream patch
<cnd> either way, we probably need to revert the patch
<apw> perhaps one of you could confirm we didn't end up taking the upstream patch
<manjo> cnd, :) heh funny coz you recommended that  patch in the 1st place 
<cnd> heh, I pointed it out :)
<apw> it may have been assumed it was the same and that one cherry-picked instread
<cnd> no recommendation
<cnd> just that it has some fixes the dell one doesn't
<cnd> btw, sorry if I'm a bit curt
<cnd> in the middle of xds :)
<apw> cnd/manjo, which was the original bug
<cnd> apw, I need to dig it out
<cnd> http://bugs.launchpad.net/bugs/632884
<ubot2> Launchpad bug 632884 in linux (Ubuntu) (and 1 other project) " Add support for Intellimouse Mode in ALPS touchpad on Dell Latitude series Laptops (affects: 1) (heat: 10)" [Undecided,Fix released]
<bjf> manjo, cnd, this sounds like the problem davidm is also having
<cnd> manjo, apw, the sauce patch in ubuntu doesn't match the LP patch
<manjo> cnd which lp patch are you taking about ? 
<apw> cnd, seems to match the 'final patch' link
<manjo> The final patch can be found here:
<manjo> https://patchwork.kernel.org/patch/118834/
<manjo> that is what I pushed 
<cnd> manjo, which is the upstream submitted dell patch I said not to use :)
<manjo> cnd, I don't see any other patch there 
<cnd> manjo, it's on the LP bug
<Sarvatt> cnd: bug work right so soon after you get done with a talk? you're a machine! :)
<cnd> heh
<cnd> http://launchpadlibrarian.net/54076279/2.6.35-alps-730264-imps-emulation.patch
<apw> dammit this is serious, we have pushed the final maverick kernels
<cnd> manjo, that's the patch I pointed to ^
<apw> to get this fixed we need to get an exception
<cnd> from https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/550625/comments/154
<ubot2> Launchpad bug 550625 in linux (Ubuntu Lucid) (and 2 other projects) "Alps touchpad is recognized but synaptics clients and scrolling do not work (affects: 113) (dups: 9) (heat: 576)" [Medium,Incomplete]
<apw> bjf, does davidm have a bug also ?
 * apw will switch the patch and get some test kernles out to these bugs
<bjf> apw, yes, though he's been unable to actually file it due to LP timeouts
<manjo> cnd, there is no mention of 550625 in 632884 so when you asked me to help with 632884 I did by picking up the final patch there 
<apw> manjo, there is though in comment #1
<apw> manjo, anyhow i'll get some kernels together
<cnd> apw, might I suggest just pulling the patch?
<cnd> git revert
<cnd> the patch hasn't been reviewed upstream and we're so late
<cnd> and the trackpads still work without the patch, just not with scrolling support
<apw> cnd, i thought you needed that in to get multi-touch or some shit
<cnd> apw, nope
<cnd> it was just a bug I wanted someone to look at
<cnd> since I had seen someone in the community had worked on the patch some
<cnd> I didn't want it to fall through the cracks
<cnd> and disappear forever into LP :)
<hallyn> oh goodie, i get to blame manjo for breaking my tp :)
<manjo> cnd, so why did you ask me to look at it if it was not important ? 
 * hallyn shakes his fist
<cnd> I never said it was important :)
<cnd> I just said someone should look at it
<Sarvatt> there are quite a large number of bugs against synaptics at least regarding the alps scroll situation that i'm moving over to that one right now, I wouldn't say its unimportant. not having touchpad scroll is a pretty crappy user experience
<cnd> Sarvatt, it's not whether it's important or not
<cnd> it's that we're in kernel freeze
<cnd> and we aren't positive that we won't add more regressions with the patch from LP
<apw> Sarvatt, right, we really are past the point where we want to make any changes as someone has to respin every CD as a result
<apw> and we have no time to get any testing on it, i'll mark the bug for consideration after release
<apw> (the original one) and we can then test it more thoroughly
<cnd> my hope was that someone would take a look at the LP patch many weeks ago, put it in a development kernel, and then we can work on upstreaming it
<cnd> then oem services wanted proper alps support, and manjo and vanhoof looked at it a week or two ago
<cnd> timing just wasn't as good as one could hope :(
<cnd> and I didn't have enough time to work the bug properly myself...
<robbiew> JFo: ping
<JFo> robbiew, pong
<JFo> s'what I get for working on 2 machines
<robbiew> JFo: nevermind...was going to ask you about I bug, but I decided it was easier to just ask the submitter as a comment ;)
<JFo> heh
<apw> hallyn, hey ... i'm just reverting that patch and will have some test kernels in about 10 mins for testing if you could confirm the revert fixes you
<hallyn> apw: cool
 * JFo stepping out for a bit. some errands and packing to complete before flying for Taipei tomorrow.
<ogasawara> kees: about?  want to check back with you about the stack guard change you said was missing?
<ogasawara> kees: I'd only applied the one patch from smb - http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=1ccc5359a8f055b153a2e0cfec02a594a8443360
<ogasawara> kees: is there additional patches I need to get applied?
<ogasawara> jjohansen: re "[PATCH 3/3] UBUNTU: SAUCE: AppArmor: allow newer tools to load policyon older kernels"
<ogasawara> jjohansen: is there something you want modified with that patch per tetsuo's comments?
<hallyn> apw: actually gotta run for a bit, i'll test when i get back
<ogasawara> jjohansen: we might have a chance to get that fixed and squeezed into a last minute upload
<kees> ogasawara: let me check if it passes now that I've rebooted
<kees> ogasawara: doesn't seem to pass
<kees> smb: the test still fails on maverick with that applied ^^
<smb> kees, hm...
<kees> oh wait
<kees> I'm still on the wrong kernel, one sec
 * smb holds his breath
 * ogasawara crosses fingers the right kernel works
 * smb turns slightly purple...
<kees> kees@sec-maverick-i386:~/qa-regression-testing/scripts/kernel/guard-page$ cat /proc/version_signature 
<kees> Ubuntu 2.6.35-22.32-generic 2.6.35.4
<kees> kees@sec-maverick-i386:~/qa-regression-testing/scripts/kernel/guard-page$ ./split-stack stack start changed due to mlock call (0xbfa2c000 != 0xbfa4b000)!
<kees> still fails
<smb> kees, is there more output to look at?
<kees> fails on hardy even. *scratch head*
<ogasawara> kees: how critical is this for landing in Maverick's release?
<ogasawara> kees: as we've likely got one last shot for an upload
<smb> I would say not very critical
<ogasawara> smb: so it could potentially be resolved via an SRU post maverick release?
<smb> Yes, sounds reasonable
 * kees will boot an upstream vanilla kernels
<kees> s/s$//
<smb> kees, But those addresses seem to be too far apart to be one page...
<smb> kees, Thats weird
<smb> Do you have the full output of maps somewhere?
<kees> smb: it goes from:
<kees> bff13000-bff34000 rw-p 00000000 00:00 0          [stack]
<kees> to:
<kees> bff13000-bff33000 rw-p 00000000 00:00 0 
<kees> bff33000-bff34000 rw-p 00000000 00:00 0          [stack]
<kees> across the mlock call
<smb> kees, There does not seem to be a whole in there to me
<smb> err hole
<kees> hm? but the thing that got called "stack" got chopped up
<kees> maybe I misunderstood the issue?
<smb> I suppose
<smb> wron would be
<smb> bff13000-bff33000 rw-p 00000000 00:00 0
<smb> errr what would be bff333000 +4k.
<jjohansen> ogasawara: yes, if we can squeeze it in
<smb> kees, Seems to be an unfortunate example
<ogasawara> jjohansen: yep, just get me a patch to the ml asap
<jjohansen> ogasawara: okay
<smb> The problem _was_ that you saw a gap between  the vmas
<apw> smb, 4k == 1000 hex
<smb> apw, ta
<kees> 7fff810d6000-7fff810f7000 rw-p 00000000 00:00 0                          [stack]
<kees> vs
<kees> 7fff810d6000-7fff810f5000 rw-p 00000000 00:00 0 
<kees> 7fff810f6000-7fff810f6000 rw-p 00000000 00:00 0                          [stack]
<kees> smb: there's a gap between 7fff810f5000 and 7fff810f6000
<kees> is that the bug?
<kees> my testcase is wrong, I guess.
 * smb scratches his head
<kees> I thought it was the fact that the stack got misidentified
<smb> kees, That looks more broken than anything I saw
<ogasawara> jjohansen: if you prefer, just give me two patches, one to revert the original SAUCE patch and then the fixed up version
<jjohansen> ogasawara: okay
<smb> kees, The problem was that the first page of a stack vma got hidden (start was moved up one page). 
<kees> that would seem to be what the "gap between 7fff810f5000 and 7fff810f6000" demonstrates
<smb> kees, May be what you posted last. 6000-6000 (basically size 0)
<smb> The 6000-5000 looks really weird
<apw> smb, thats doesn't say 6000->5000
<kees> okay, the kernels before the guard page show:
<kees> bfdd1000-bfde6000 rw-p 00000000 00:00 0          [stack]
<kees> into
<kees> bfdd1000-bfde3000 rw-p 00000000 00:00 0 
<kees> bfde3000-bfde4000 rw-p 00000000 00:00 0          [stack]
<apw> it says d6000->f5000
<kees> so the split is "ok". it's the _gap_ that is bad.
<smb> apw, ah ok missed that
<kees> I'll fix the test case
<smb> kees, But the second exapmple has no gap, right? bfdd1000-bfde3000 and bfde3000-bfde4000
<smb> kees, oh ah
<smb> kees, yes
 * kees nods
<smb> kees, the split is ok. but the address range should be connected
<kees> I thought the bug was the splitting at all. I didn't realize the gap
<kees> right
<kees> fixing testcase...
<apw> it always has to be split cause the permissions differ after the mlock
<kees> apw: though oddly, the state of mlock isn't shown in maps
<kees> (nor vma growth direction)
<apw> kees, indeed, maps is a little useless
<apw> kees, might be more in smaps
<tseliot> apw: it seems that the following commit was included after 2.6.35-20:
<tseliot> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c41d68a513c71e35a14f66d71782d27a79a81ea6
<tseliot> apw: this breaks fglrx
<tseliot> compat_alloc_user_space(), that is
<apw> tseliot, how does it manifest, what breaks
<tseliot> apw: I get error: implicit declaration of function âcompat_alloc_user_spaceâ
<tseliot> apw: when trying to build the kernel module for fglrx
<smb> tseliot, ITs likely because they exported thy symbol GPL
<apw> tseliot, try converting the call to arch_compat_alloc_user_space()
<smb> EXPORT_SYMBOL_GPL(compat_alloc_user_space)
<apw> ahh ... doh
<tseliot> apw, smb: I could use arch_compat_alloc_user_space() but would this work on previous 2.6.35 kernels?
<ogasawara> ogra, mpoirier: bug 630885, is that release critical?  or ok as a post release SRU?
<ubot2> Launchpad bug 630885 in linux (Ubuntu) (and 1 other project) "Preinstalled Maverick netbook image has no display on omap3 EVM (no LCD) (affects: 1) (heat: 14)" [Undecided,In progress] https://launchpad.net/bugs/630885
<apw> tseliot, nope
<tseliot> apw: it was a rhetorical question ;)
<ogra> ogasawara, we dont have such HW in the team, probably for linaro 
<ogra> ogasawara, but since i expect changes for omap3 anyway it wouldnt do harm to have it too
<tseliot> smb: do you mean to say that they did EXPORT_SYMBOL_GPL(compat_alloc_user_space) in the fglrx code?
<smb> tseliot, No they made the export like that in kernel/compat.c
<smb> Before that it was an inline function
<apw> tseliot, no he is saying the kernel has been changed to only export it to GPL stuff
<tseliot> smb: ah, I get it now
<mpoirier> ogasawara: the request came from a TI guy - is we get it in great, otherwise that's just life.
<apw> tseliot, sounds like you have just need to include a header though
<apw> as the code you are compiling is GPL right, the shim is GPL
<ogasawara> mpoirier: and the patch itself is going upstream?
<mpoirier> ogasawara: I wish it could...
<mpoirier> but haven't had any luck with all our beagle work.
<ogasawara> mpoirier: tgardner had inquired
<smb> tseliot, yeah, mabe including <linux/compat.h> works
<mpoirier> yes, tgardner and I have talked about it.
<tseliot> apw, smb: including <linux/compat.h> works but I can't because it's GPL while the file that should include it is not
<mpoirier> ogasawara: I'm thinking about enlisting outside key contributors to help with the push up.
<ogasawara> mpoirier: might be good to post the result of the discussion to the mailing list so we're all in the loop
<apw> tseliot, add a shim funtion in the gpl file ?
<ogasawara> mpoirier: and I assume I should add the additional provenance for the patch?
<mpoirier> ogasawara: should we mumble ?
<ogasawara> mpoirier: sure
<MTecknology> I've been playing with compiling the kernel and trying to figure it out on that level. I got myself stuck though. I'm missing a module (I assume) but I have no idea what module it might be.. My system boots pretty nice. It even loads to TTY7 (only 1 and 7). This is what I wind up seeing. http://pastebin.ubuntu.com/495371/ (Maverick). Any chance I could get a little pointer?
<jjohansen> ogasawara: patches should be on the list now
<ogasawara> jjohansen: great, thanks
<tseliot> apw: ah, so a simple function that calls arch_compat_alloc_user_space() in asm/compat.h?
<smb> tseliot, I probably would rather do a simple function that call compat_alloc_userspace (to get the benefit of the additional checks) which is defined in a gpl'ed code
<apw> tseliot, indded as smb suggests
<apw> fgrlx_alloc_user_space() { compat_aloc_user_space() }
<apw> stylee
<apw> and that should be compatible either way i think
<apw> thus showing how stupid the whole export_gpl stuff really is, as you can comply with the rules
<tseliot> apw, smb: ah, so I could add that function in asm/compat.h and the thing would be legal? This would mean adding something like #define ALLOC_COMPAT_LEGACY (or a better name) so that fglrx can see whether it needs to call fgrlx_alloc_user_space() at build time.
<smb> No, not changing anything in the normal kernel code. This should go into the fglrx code (the part that is gpl)
<tseliot> smb: this is what they currently do in fglrx:
<tseliot> void* ATI_API_CALL KCL_IOCTL_AllocUserSpace32(long size)
<tseliot> {
<tseliot>     return compat_alloc_user_space(size);
<tseliot> }
<apw> and they do that in non-GPL file right ?
<tseliot> yep
<apw> but they ahve a GPL file, so change that to fgrlc_alloc....(size)
<apw> and add an identicle wrapper to the GPL file
<apw> as i say, the separation is pointless
<apw> hallyn, kernel for testing is at: http://people.canonical.com/~apw/lp641320-maverick/
<apw> tseliot, do u mumble ?
<tseliot> apw: yep but I need to connect the microphone
<apw> might be easier to talk
<tseliot> apw: right but my microphone doesn't seem to be detected...
 * tseliot blames it on pulseaudio
<MTecknology> Is there a ureadahead module in the ubuntu version of the kernel that's required to boot - even if you don't have ureadahead?
<tseliot> apw: ok, it works now, let's talk
<tseliot> apw: where shall we talk?
<apw> we are in cafinated conversation ... under Kernel
<smb> tseliot, kernel teams caffeinated conversation
<tseliot> smb, apw: ok, I'm there
<tseliot> apw: can you hear me?
<smb> He cannot
<tseliot> oh
<smb> In fact none of us. :)
<tseliot> ok, let me reconfigure mumble
<tseliot> smb, apw: now it's telling me that my password is wrong. I'll give up on mumble for now.
<tseliot> apw, smb: were you suggesting that I define the function in the GPL file and export the function?
<tseliot> the fgrlx_alloc_user_space() function that is
<smb> Right, you do it in the GPL file and export it (or link) it to the non-gpl file
<tseliot> ok, I see what you mean now
<tseliot> thanks
<tseliot> smb, apw: thanks a lot for your help
<smb> np :)
<hallyn> apw: that kernel is good
<apw> hallyn, thanks can you update the bug pls
<hallyn> apw: done, thanks
<hallyn> though now, periodically the x display just hange.  right now i'm typing typing typing and not seeing anything, but i'tll suddenly just catch up  maybe
<ogasawara> apw: http://pastebin.ubuntu.com/495420/
<ogasawara> apw: http://pastebin.ubuntu.com/495429/ - updated revision
<Sarvatt> would something like this work for all of these vaio F series that need i8042.nopnp? http://sarvatt.com/downloads/patches/vaio-vpcf-i8042-quirk.patch
<Sarvatt> VPCF1290X VPCF126FM VPCF12S1E VPCF12M1E VPCF121FD are the models i've found so far needing it
<mjg59> Given that Windows uses pnp to identify i8042 devices, that seems very much like the wrong fix
<Sarvatt> mjg59: thanks, it was a shot in the dark. it looks to be all VPCF12xxx devices, VPCF11xxx that hallyn has doesn't need the quirk to have the touchpad working
<mjg59> Sarvatt: What's the bug number for this?
<mjg59> Sarvatt: And does it have dmesg in both cases?
<Sarvatt> there are a whole rack of bugs i'm noticing now that i'm looking and haven't condensed them yet, one sec i'll get you a list. they all have this in dmesg
<Sarvatt> [    1.377980] PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
<Sarvatt> [    1.377982] PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
<mjg59> Awesome
<mjg59> Sarvatt: Need acpidump as well
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/636638
<ubot2> Ubuntu bug 636638 in linux (Ubuntu) "Touchpad is not detected on Sony VPCF126FM (affects: 1) (heat: 848)" [Undecided,New]
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/641169
<ubot2> Ubuntu bug 641169 in linux (Ubuntu) "alps touchpad sony vaio recognized, but not working (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> ^ that one has acpidump but no dmesg, he put his dmesg in another bug
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/638219
<ubot2> Ubuntu bug 638219 in linux (Ubuntu) "Touchpad does not work on Sony Vaio VPCF12M1E (affects: 1) (heat: 1692)" [Undecided,New]
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/636842
<ubot2> Ubuntu bug 636842 in linux (Ubuntu) "Touchpad not found on Sony Vaio VPCF12S1E (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> sorry for the spam
<mjg59> Sarvatt: I think 641169 is different
<Sarvatt> it is, kind of, we were working through that with him in #ubuntu-devel and he was hitting 2 bugs at once
<Sarvatt> he needed the fix for that bug + i8042.nopnp to actually work
<mjg59> Which one did you say had acpidump?
<Sarvatt> oh shoot, getting my bugs mixed up
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/641324
<ubot2> Ubuntu bug 641324 in linux (Ubuntu) "Sony Vaio touch pad is not working (affects: 1) (heat: 10)" [Undecided,New]
<Sarvatt> let me ask these people for acpidumps :)
<Sarvatt> http://launchpadlibrarian.net/55810189/vaio_bug.txt 
<mjg59> Interesting. That should definitely be picked up.
<mjg59> There's a PNP0F13 device.
<mjg59> But it's got an invalid _HID
<mjg59> Maybe we're ignoring it in that case
<mjg59> Sarvatt: My suspicion is that this is an issue in the acpipnp parser
<mjg59> Sarvatt: Bet http://fpaste.org/NDs1/ will fix it
<mjg59> Or, at least, will result in it crashing in some entertaining way
<apw> clap4ham
<Sarvatt> i'll try to condense these bugs and submit a bug to b.k.org
<mjg59> apw: ...
<Sarvatt> oh, nice
<apw> heheh ...that poor password 
<apw> thats why i have a different screen saver password to anything useful :)
<mjg59> Sarvatt: It certainly looks like we stop parsing acpipnp devices if there's an invalid HID, and this HID is certainly invalid
<apw> done that twice this week already :)
<cking> doh
<mjg59> It's supposed to be three letters followed by four hex digits. Instead it's SNYALP0012
<mjg59> Thony
<apw> its only my screen lock password, thats why it has to be different
<mjg59> Sarvatt: http://marc.info/?l=linux-acpi&m=127563868423035&w=2
<Sarvatt> mjg59: \o/ thank you for looking at it and the heads up on that patch
 * ogasawara lunch
<jjohansen> -> lunch
<robbiew> ogasawara: regarding the Kernel Freeze Exception, just cut and paste that email into the bug comment...that should be enough
<ogasawara> robbiew: you're reading my mind, doing that right now
<robbiew> ;)
<robbiew> I figured I didn't need to say it, but didn't want you thinking we needed separate bugs for each bugfix or something nuts like that :)
<ogasawara> robbiew: bug 641618
<ubot2> Launchpad bug 641618 in linux (Ubuntu) "Maverick Kernel Freeze Exception (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/641618
<ogasawara> robbiew: will respond with the bug# in email to keep everyone informed
<robbiew> ogasawara: cool..thnx
#ubuntu-kernel 2010-09-18
<MTecknology> Is there anything special a custom kernel would need to work in 10.10 as opposed to 10.04?
<jjohansen> MTecknology: nothing comes to mind, what kind of failure are you seeing
<MTecknology> jjohansen: I've just been playing around - right now when I boot I get a kernel panic not being able to mount the root fs
<jjohansen> MTecknology: well you probably need to build it in a Maverick chroot
<MTecknology> i did that
<jjohansen> and make sure you have devtmpfs configured
<MTecknology> probably didn't do that..
<jjohansen> hrmm, I thought that was required for Lucid, but maybe it was just a recommends and would fall back to mounting dev on tmpfs
<MTecknology> oh.. CONFIG_DEVTMPFS ?
<MTecknology> that's enabled
<jjohansen> hrmm, perhaps a driver?
<jjohansen> I am assuming you have the same filesystems
<MTecknology> ya, I'm using Ext4 for everything
<jjohansen> can you mount from the command line in the initramfs?
<MTecknology> I've been building it without initramfs support
<MTecknology> I was trying to make the smallest little kernel that would work on my system - I was wondering what I could wind up with
<jjohansen> ah
<MTecknology> I'm running on the generic kernel now - ran lspci -vvkk and made sure everything that showed up was enabled in the kernel
<jjohansen> is your grub boot line right for your rootfs
<jjohansen> are you doing it by dev, uuid?
<jjohansen> grub1, or grub2
<MTecknology> grub2 - Ubuntu 10.10
<MTecknology> root=/dev/sda1
<MTecknology> http://dpaste.com/245224/
<MTecknology> heh... why doesn't it use the UUID when I run update-grub2?
<MTecknology> I'll try with uuis
<MTecknology> s/s/d/
<jjohansen> hrmm I'm not sure
<jjohansen> but if root is manually specified I don't think it will change it
<jjohansen> have you tried mounting an ext4 partition as ext2 in 2.6.36?
<MTecknology> no
<jjohansen> should work but maybe there is a regression there
 * jjohansen is just taking stabs in the dark
<MTecknology> this is maybe odd though.. when it boots - it shows a listing of partitions - but it's sdb1,2,3,4
<MTecknology> there's no sda listed
<jjohansen> hrmm that would do it
<jjohansen> I wonder why the ordering changed
<MTecknology> I'll try it with that....
<MTecknology> nope
<jjohansen> can you try uuid?
<MTecknology> I did and it didn't work
<MTecknology> I'd offer my .config but I imagine you're too busy to look at something like that. :P
<jjohansen> hrmm, is sdb usually listed?
<MTecknology> I don't know - it was just listed in the kernel panic
<jjohansen> sadly I am atm, as I am about to leave for dinner
<jjohansen> can you do it with an initramfs?
<jjohansen> just as an experiment
<MTecknology> how do you build it that way?
<MTecknology> I build without module support too - if that breaks things
<jjohansen> update-initramfs -k version 
<jjohansen> shouldn't as long as everything you need is compiled in
<MTecknology> alrighty - I'll rebuild the kernel - toss it in there, then run that
<MTecknology> I could let you take off for dinner, take a nap, try it, and then bug you if it works or doesn't
<jjohansen> you'll need to update-grub to so it gets the initramfs line
<MTecknology> ok
<jjohansen> okay, I might be back on later
<MTecknology> thanks for the help - very much appreciated :)
<jj-afk> np
<torti> hi. in ubuntu 10.10beta when i install linux-source, extract the .tar.bz2, do "make oldconfig" and "make modules_prepare" before installing the vboxdrv (virtualbox 3.2), the resulting vboxdrv.ko has magicversion 2.6.35.4, thus cannot be loaded since the kernel has 2.6.35-22-generic. is this normal in the beta or is this a bug?
<torti> i think 2.6.35.4 comes from ubuntu's /boot/config-2.6.35-22-generic, because it has: CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.35-22.32-generic 2.6.35.4"
<torti> (i can't type that fast. i copy-and-pasted it, because i initially asked that question in #ubuntu-devel)
<bjf[afk]> tgardner: where you at?
<tgardner> bjf[afk], slc
<bjf[afk]> ah
<tgardner> 6 hour layover before tokyo
<diana1068> hi guys!!!
<diana1068> hellooooooo!
<diana1068> can anybody help with my little problem?
<diana1068> i got a problem with upgrading my current kernel 2.6.32-24 to 2.6.32-25.1
<diana1068> plz someone write me back if u will see this message. thank u
<oasik> I having problem with installing new kernel
<oasik> I compiled and installed this kernel git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel
<oasik> I having problem with installing new kernel
<oasik> my system is ubuntu 10.04
#ubuntu-kernel 2010-09-19
<sconklin> http://www.engadget.com/2010/09/18/intel-wants-to-charge-50-to-unlock-stuff-your-cpu-can-already-d/
<bullgard4> At startup my Maverick Beta computer writes after 1,8 s : "Magic number: 10:86:987". What does this number refer to?
<bullgard4> At startup my Maverick Beta computer writes after 1,8 s : "Magic number: 10:86:987". What does this number refer to?
<bullgard4> I understand that it designates USERHASH:FILEHASH:DEVHASH. But why does Ubuntu publish these 3 numbers?
<u456503> Hi all
<u456503> Is somebody here ?
<u456503> I'm trying to compile the kernel using this tutorial: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<u456503> I'm using Ubuntu 10.10
<u456503> but there are some files *.patch to be applied
<u456503> can some one help ?
<u456503> hi oracle
<oracle> hi 
<oracle> so many kernel updates recently
<u456503> stable candidates, yes
<u456503> Do you run an Ubuntu ststem ?
<u456503> http://twitter.com/gregkh/status/24873562442 from Greg
<oracle> yes i run two ubuntus
<oracle> 2.6.27
<oracle> weird
<u456503> oh, can you explain how to apply the ubuntu patches, on the latest mainile ?
<u456503> the links: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc4-maverick/
<u456503> and: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<u456503> I am not an expert, if you can help ?
<u456503> hi chrisccoulson
<chrisccoulson> hi u456503
<u456503> can you view the last discution ?
<u456503> I'm trying to compile the latest kernel
<u456503> but there are some patces, not included in mainline
<u456503> there is somebody to upstream them ?
<u456503> or I am on the wrong channel ?
<u456503> in 5 minutes I will quit
<etheretic> 'ello
<etheretic> running iotop, get error "CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %" making it impossible to analyze the iowait pest i'm afflicted with. ubuntu 10.04 kernel 2.6.32-4.
<lifeless> ttps://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/532490
<etheretic> bug or feature?
<etheretic> ah.
<etheretic> h
<lifeless> its going to be reenabled according to the master bug
<lifeless> perhaps you need a newer kernel ?
<etheretic> er. have one handy? not very competent w. linux, btw.
<lifeless> no, I don't sorry :)
<etheretic> thought 32-24 was latest. pardon above typo.
<etheretic> 2.6.32-24
<etheretic> lifeless: i have rtfm'ed on the iowait issue, but found no applicable solutions. it arises when running firefox/oolite/amule, and causes said programs to crash after having paralysed my comp (acer notebook) for 2-30 minutes.
<etheretic> not sure how kernel-related it is. but #ubuntu was mum on the issue.
<lifeless> I suggest reading up on disk tuning - DMA etc. Could be that.
<etheretic> hdparm?
<etheretic> timings look ok.
<etheretic> 580/46 cached/buffered. nothing spectacular, but not abysmal either.
<sfw> Does anyone know how does kernel module loading in Ubuntu work? Is it any different from Gentoo? This is NOT a troll question or something. For example I try to switch cpu into ondemand mode and it explicitly requires I modprobe "powernow-k8". How does Ubuntu handle this? Im just learning a bit.
<mjg59> sfw: Which requires it? Ubuntu or Gentoo?
<mjg59> There's no modaliases for CPUs, so it's always necessary to explicitly load cpufreq modules
<mjg59> Ubuntu (and most sane distributions) have a startup script that looks at your cpu vendor, family and flags and uses that to figure out which module to load
<sfw> mjg59: So ubuntu does not use kerneld and uses kernel autoloader? What startupscript are you refering for please, init in initramfs?
<mjg59> sfw: kerneld?
<mjg59> It's been a while since I checked exactly how it works in Ubuntu - I /believe/ that it's called /etc/init.d/powernow.something
<sfw> I remember pretty good I wasnt required to modprobe powernow with 10.04. It was already somehow loaded.
<sfw> Kerneld is from here: http://tldp.org/HOWTO/Kerneld/introduction.html    And I got info about it from here:http://tldp.org/HOWTO/Module-HOWTO/index.html
<Nafallo> likely /etc/init.d/ondemand I think
<sfw> mjg59, so ubuntu probably uses init.d to automatically load the module. Hm. I just wonder if a program can force kernel module be loaded automatically. In the case of devices its done by udev AFAIK
<Nafallo> hmm. no. that doesn't actually load modules
<sfw> I mean it detects devices and issues modload.
<mjg59> sfw: kerneld doesn't exist in modern kernels
<Nafallo> ah. looks like the powernow stuff is compiled into the kernel, and then /etc/init.d/ondemand sets the ondemand for cpus that supports it.
<sfw> mjg59: this is what I was fearing)
<mjg59> sfw: In the modern world, when a device is created it generates a uevent. That gets picked up by udev, which reads the modalias file and asks modprobe to load any modules with a modalias that matches the device's. CPUs are system devices and don't have modaliases.
<sfw> Nafallo: Ok, that pretty clears things up, ty
<sfw> mjg59: Thanks a lot for explanation! So software usually should not load or ask to load any kernel modules?
<melkor> are there any maverick kernels that have fixed this issue?  http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-root-rights-1081317.html
<melkor> I'm using the lts maverick backports and it is not fixed.
#ubuntu-kernel 2011-09-12
<apw> jk-, we were indeed but internet was spotty at best where we were and the lounge on the wrong concourse (and behind the wrong security)
<apw> ppisati, morning ... its quiet out here today
<ppisati> apw: hey
 * apw is very tired... how you doing ?
<ppisati> apw: i thought everyone was still still sleeping... :)
<ppisati> well, confused but ok
<apw> well i am in a sitting position, i would not like to comment on my wakefulness
<ppisati> auhauha :)
<ppisati> i think i need some more coffee before i can consider myself awake
<apw> ppisati, two large cups in, and i am still unsure
 * ppisati updates the laptop to Oneiric...
 * apw waits for ppisati to drop off the net
<ppisati> i'm on the desktop
<gema> so, based on tiredness levels, you guys had a good time on the conference?
<gema> *at
<apw> gema, yeah, not bad thanks
<gema> :)
<ppisati> btw my laptop is stuck at "fetching complete"
<ppisati> it feels the jetlag too...
 * ppisati -> out for some grocery
<apw> jk-, about ?  am getting errors from pwparser making hashes, about utf8
<apw> jk-, bah ignore me, out of date version
<brendand> bjf - hi
 * ogasawara back in 20
<ppisati> apw: what was the ^ thing to fix dependency problem?
<apw> ppisati, do you mean apt-get install ubuntu-desktop^
<ppisati> apw: ok, that one
<ppisati> i just did a dist-upgrade
<ppisati> but it complains about some lacking dependencies
<ppisati> like gnome-desktop, unity-2d and nautlius
<ppisati> doh
<ppisati>  
 * sforshee -> dr appt
<ppisati> herton: maverick/mvl-dove should be ok
<ppisati> herton: check it out
<herton> ppisati: ack
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0 || Ubuntu Kernel Team Meeting - September - 13 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<tgardner> ogasawara, re: 'x86, x2apic: enable the bios request for x2apic optout', both emetrald and Sandybridge server print 'x2apic not enabled, IRQ remapping init failed' (which is expected I think)
<tgardner> emerald*
<ogasawara> tgardner:  yep, I got the same testing results here (eg interrupt remapping fails so x2apic is not enabled, which is expected)
<ogasawara> tgardner: I'm still waiting to hear back from yingying about her testing results
<tgardner> ogasawara, given the proximity of freeze I thought we should get it in master-next for  some testing
<ogasawara> tgardner: agreed.  I'm going to do one last upload tomorrow prior to kernel freeze on thurs.
<ogasawara> tgardner: you guys have any discussions with greg last week as to what the next long term kernel version will be?
<tgardner> ogasawara, nope, he wasn't there. I did chat with Rheinhard Tatler (sp?) about it likely being 3.2
<bjf> apw, did you ship that system today :-)
<apw> heh not yet, i'll get msm on the paperwork
<pgraner> ogasawara, when you notify of a new kernel what addresses do you send it to?
<tgardner> pgraner, should be the k-team list and ubuntu-installers list
<tgardner> assuming an ABI bump
<pgraner> tgardner, ack thx
<BenC> Hey guys, has the venue for the next UDS been decided?
<bjf> BenC, yes, we are going back to orlando
<BenC> saweet
<BenC> is there a wiki page up yet?
<bjf> BenC, looking
<BenC> I'm going to try to get my employer to send me
<bjf> BenC, http://summit.ubuntu.com/
<bjf> BenC, will look for a pointer to the hotel
<bjf> BenC, http://www.thecaribeorlando.com/Caribe-Royale/
<BenC> bjf: thanks
 * tgardner --> lunch
<mfilipe> sforshee, the intel bug (vga weavy) I fixed with adapter vga->dp and I bought a displayport monitor hehehe
<mfilipe> thanks for your time and efforts to help fix that problem
<mfilipe> :)
<sforshee> mfilipe, glad you found a solution, hopefully we'll get it fixed anyway though :)
 * apw wanders off ...
<beata|coyote> Howdy! I'm doing some experimenting with an old laptop. I wanted to try some arbitrary ACPI modification, and I found the DSDT overwriting guide, found the initrd override patches, but they don't patch at all cleanly. Any suggestions?
 * jjohansen -> lunch
 * tgardner --> EOD
<broder> hmm...are there still going to be any natty srus? i'm trying to figure out if it's worth trying to get e8e7a2b8cc cherry-picked onto natty (fixes an i915/dri/dpms-related program lockup)
#ubuntu-kernel 2011-09-13
<Sarvatt> broder: there's only been 2 kernel SRU's to natty so far and 2.6.38.x is dead so things need to be recommended manually, absolutely yes :)
<broder> ok, cool. i'll try to learn how the process works and send off the patch :)
<ppisati> morning *
<apw> ppisati, morning
<ppisati> looks like LP is down...
<ppisati> ok, it's back
<apw> ppisati, for maintenance ?
<ppisati> no no
<ppisati> just got the Oops page for some reload in a row
<ppisati> now it's ok
<apw> ppisati, ahh yes she does do that to annoy one
<ppisati> they respun natty, or so it seems...
<apw> respun ?
<ppisati> yep
<ppisati> respin
<apw> do we know why this time ?
<ppisati> just deleted the email, but there was a regression in a patch
<ppisati> patch reverted and kernel respinned
<ppisati> and thus all the derivative pkgs got a new tracking bug
<apw> ahh nice
<apw> ppisati, bah ... we didn't sign your key last week
<ppisati> apw: want it now? :)
<apw> bah humbug
<apw> ppisati, didn't realise you were signing the tags too ... we must remember to do it the next time we are together
<ppisati> k
<sladen> ogasawara et al: bug #834725 - are we short of a kernel interface that powertop needs?
<ubot2`> Launchpad bug 834725 in powertop "Powertop fails to report number of wakeups/events" [Medium,Triaged] https://launchpad.net/bugs/834725
<ogasawara> sladen: I'm unaware of anything off the top of my head, we' have to investigate further
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<ppisati> herton: natty has been respinned, but natty/ti-omap4 doesn't depend on natty/master thus i'm invalidating the tracking bug
<herton> ppisati: ok
<ppisati> herton: not so fast: http://paste.ubuntu.com/688351/
<herton> ppisati: hmm I didn't run the script for a while, may be something changed in lpltk. Are you running with the latest python-launchpadlib-toolkit from arsenal-devel ppa?
<ppisati> herton: actually i was running the vanilla py-lpltk
<herton> ppisati: the vanilla should not work, does it work updating to latest python-launchpadlib-toolkit? (# apt-add-repository ppa:arsenal-devel/ppa; apt-get update; apt-get install python-launchpadlib-toolkit
<herton> ppisati: I'm going to lunch, let me know if it doesn't work
 * herton -> lunch
 * ogasawara back in 20
<ppisati> herton: worked fine, thanks
<ppisati> for the kernel irc meeting: arm status -> http://paste.ubuntu.com/688380/
<apw> ppisati, not going to be around to deliver it ?
<apw> bjf, ^^
<bjf> apw, no one cares about arm
<bjf> :-P
<ppisati> :)
<ppisati> luckily no ones care about arm... :)
<ppisati> sent an email on the k-t m-l
<ppisati>  /quit
<jjohansen> ogasawara, apw, tgardner: so I have been looking at CONFIG_DYNAMIC_DEBUG (last of the work items) and I don't see a reason to enable it on production systems.  It requires debugfs be mounted and then you can dynamically enable/disable per call site, code that used pr_debug()/dev_dbg().
<jjohansen> Its okay for debugging when you insert extra debug code using these or the bug is near code already there using those.  So I am recommending it as another debug tool when building debug kernels, but don't see the point on enabling it on production systems.
<jjohansen> ogasawara: I will close off the work item
<ogasawara> jjohansen: ack, thanks.
<apw> jjohansen, sounds good, just note that in the spec in the results section
<jjohansen> apw: ack
<tyhicks> jjohansen: Take this with a grain of salt, but I thought that dynamic debug was now the preferred way to log debug messages as opposed to each subsystem having their own one-off way of logging debug messages?
<tyhicks> jjohansen: For example, eCryptfs is way too verbose for a filesystem, but what is dumped out to syslog is a great help for me to triage bug reports
<jjohansen> tyhicks: hrmm right
<tyhicks> jjohansen: I was hoping to switch everything over to dynamic debug at some point so that a user can flip the switch when they hit problems and get me useful debug messages
<jjohansen> tyhicks: I look some more, I am not opposed to having it on.  I'll look some more at what subsystems are using it.
<tyhicks> jjohansen: Good idea - maybe no one is using it. I don't care one way or the other, at this point, since eCryptfs doesn't currently use it
<bjf> ##
<bjf> ## Kernel team meeting in one hour
<bjf> ##
<bjf> apw, did you ship the box ? :-)
<apw> should be going in the morning
<apw> i am sick of it filling up my hall ...
<jjohansen> rebooting
<bjf> ##
<bjf> ## Kernel team meeting in 7 minutes
<bjf> ##
<jjohansen> ogasawara: I have an ecryptfs patch upstream I would like to squeeze into today if possible
<ogasawara> jjohansen: sure, send it to the list asap.
<jjohansen> ogasawara: ack
<kirkland> jjohansen: cool, which one?  trailing garbage?
<ogasawara> jjohansen: I plan on uploading this afternoon
<kirkland> ogasawara: missed you in Santa Rosa last week -- running trail by hotel and weather were both exceptional!
<jjohansen> kirkland: uhm can't remember but I think so.  I cherry-picked it last week but didn't get to testing it
<kirkland> jjohansen: k
<ogasawara> kirkland: I think I would have died :)  I literally haven't ran for over a year now.
<kirkland> ogasawara: wow!  no kidding!  I did eight miles, from the hotel into a bunch of vineyards, and back, 59F (which is over 40 degrees cooler than here right now)!
 * ogasawara decides to break out the running shoes today
<apw> sconklin, all those !verified reversions, is there someone needing a kick on those?  or is it just many people
<sconklin> it's many people, and a number of reasons. I'd have to look but I think the most common is "I've found a workaround, and although I have a reproducer and reported it, I have no interest in helping you"
<kirkland> ogasawara: i'm early, but on track and signed up for the next Austin Marathon
<apw> sconklin, shame we can't apply a patch to stop their work around working too
<sconklin> there's also some "I told you it fixes the problem when it was a one-off patch applied for a test, I see no need to test your -proposed kernel"
<sconklin> and a lot of just never getting a response at all to the calls for testing
<sconklin> it's all in the bugs which were linked
<apw> sconklin, welll lets hope discovering we arn't going to fix it if they ignore it will shake them up
<sconklin> The ecryptfs and nouveau ones were especially annoying. The ecryptfs one got pulled from 2 or 3 kernels
<apw> sconklin, that sounds like the one jjohansen is trying to put into oneiric
<sconklin> https://bugs.launchpad.net/ecryptfs/+bug/509180
<ubot2`> Ubuntu bug 509180 in ecryptfs "ecryptfs sometimes seems to add trailing garbage to encrypted files" [High,Fix released]
<apw> jjohansen, ^^ is that the one you are talking about ?  
<jjohansen> apw: checking
<jjohansen> apw: no https://bugs.launchpad.net/ecryptfs/+bug/816387
<ubot2`> Ubuntu bug 816387 in ecryptfs "ecryptfs kernel panic when rebooting/shutdown" [High,Fix released]
<apw> so it sounds like kirkland was intereested in the ones we've just reverted for lack of testing
<jjohansen> I did look briefly at 509180 and that is why I wasn't sure
<broder> newbie question - where is the natty kernel in the sru cadence right now?
<jjohansen> rebooting
<apw> broder, i think that was jut reported on #ubuntu-meeting
<broder> apw: oh, ok. i think i see it, thanks
<apw> broder, and i think it is 'unverified fixes now reverted, awaiting QA before release'
<sconklin> broder, this is a good place to look any time http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
 * broder awesome. that is very helpful
<apw> Phase:  CopyToUpdates
<apw> Tags:  certification-testing-passed, kernel-release-tracking-bug, lucid, qa-testing-passed, verification-failed 
<apw> that doesn't seem to make much sense for the lucid one, given copy to * are invalid too
<apw> sconklin, herton ^^
<sconklin> That's because it was stopped at the last minute from being published due to the i915 regression
<sconklin> The "Phase" still reflects the phase it was stopped in
<apw> perhaps shank should say "Unknown (was XXX)" when it sees Incomplete
<kirkland> apw: was it a lack of testing, or was the patch clearly shown to cause regressions or not fix the issue?
<sconklin> those represent some well defined states, and it is going to take some deeper discussion before changing them
<apw> kirkland, lack of testing i think was the report ... sconklin the ecryptfs patch reversion was !tested right
<sconklin> lack of testing
<kirkland> apw: sconklin: who has that responsibility?  the community?
<sconklin> kirkland: generally the reporter, or whoever cares
<kirkland> sconklin: hmm, okay
<jjohansen> kirkland: reporter, community or someone who is interested and can reproduce.
<kirkland> jjohansen: okay, thanks
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0 || Ubuntu Kernel Team Meeting - September - 13 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0 || Ubuntu Kernel Team Meeting - September - 20 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<salty-horse> hi. anyone around? looking at <https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview> I see the section about fsam7400 and a consideration for dropping it. there's another, more recent implementation called fsaa1655g: http://ubuntuforums.org/showthread.php?t=1530962
<salty-horse> what does it take to include it by default?
<ogasawara> salty-horse: the best way to have it included by default is to get the driver included upstream.  I'm not in favor of carrying an out of tree driver, especially one which looks like it was last touched in 2006.
<salty-horse> ogasawara, the one i linked seems to be from 2010
<salty-horse> upstream == debian?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703180 any chance this could be fixed before final?
<ubot2`> Ubuntu bug 703180 in linux "SD card reader doesn't work on new Dell XPS" [Undecided,Confirmed]
<ogasawara> salty-horse: by upstream I mean the upstream linux kernel
<salty-horse> hmm.. well I have nothing to do with that project, and I'm not a kernel hacker. it does seem to prevent me and others from having a functioning machine
<ogasawara> salty-horse: might be best to get in touch with the driver maintainer and ask if they'd work to get the driver upstream
<salty-horse> emailing
<ogasawara> jjohansen: how's that ecryptfs patch coming?
<jjohansen> ogasawara: give me 15 min, I am just compile testing
<ogasawara> jjohansen: ack
<dupondje> ogasawara: don't know if you could check https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703180 and maby put priority or so? Cause alot of people seem to hit this bug :)
<ubot2`> Ubuntu bug 703180 in linux "SD card reader doesn't work on new Dell XPS" [Undecided,Confirmed]
<jjohansen> ogasawara: heh, go turns out my tree was a couple few days out of date, the patch is already in
<ogasawara> jjohansen: heh, cool works for me.
<ogasawara> dupondje: I'll take a look and triage that bug in a bit.  gotta get a kernel out the door first.
<dupondje> thx :)
 * jjohansen -> lunch
<kees> apw: woooo, run your merge & export, loooooots of CVEs closed now that the arms published :)
#ubuntu-kernel 2011-09-14
<asac> we have problems getting http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ath6k.tar.gz :) ... wonder if we have that in any ubuntu firmware package in archive?
<asac> found it in linux-firmware (obviously) ... thanks
<apw> Trying 2a01:450:10:1::10...
<Kano> hi, since 2 weeks no updates to mainline kernel. why cant somebody change the git repo?
<apw> Kano, hadn't considered it, we have enough problems due to that breakin as it is
<Kano> couldnt be a huge change in your script i think
<Kano> also i forgot how to update the kernel config with your package, something with update-config or so?
<apw> probabally not even a change there, probabally only need to change the remote url
<apw> fakeroot debian/rules updateconfigs
<Kano> ah
<Kano> i did a grep in the rules and did not find it
<Kano> also i had to remove the dpkg >... depend, why is that there?
<Kano> hmm, maybe fix your target
<Kano> debian/scripts/misc/kernelconfig: line 130: /root/kernel/linux-3.0.0/debian/scripts/misc/splitconfig.pl: Permission denied
<Kano> in your release package
<apw> thats a 'problem' introduced by the orig+patch format for debian
<apw> those are not really intended for use against the package but in the git repo
<apw> where the permissions are honoured
<Kano> chmod 755 there
<Kano> same for config-check
<apw> yep, you simply cannot represent that in the package
<Kano> but you can add that in the rules
<apw> patch does not carry executable information at all, and can not do so
<Kano> thats not impossible
<apw> yeah, but we never use it that way ever, its not our process model, so we'd never notice
<apw> the normal debian way is not chmod, but to change it to like $(PERL) script or $(SHELL) script
<Kano> well then use that
<apw> or i could spend my time fixing cves
<apw> its a priority thing, its not a priority as noone working they way we intend would ever hit it
<apw> and they will hit the cves
<apw> but we'd happily accept a patch if someone figured out all the places it is needed
<Kano> what was the reason to add dpkg >..?
<Kano> not mentioned in changelog
<apw> in which release
<Kano> oneric
<apw>     UBUNTU: [Config] Make linux-libc-dev coinstallable under multiarch
<Kano> ok, i dont build that, can ignore that
<Kano> it build still too much, like tools/source/doc with emtpy packages
<apw> yep, we only turn those off for debugging builds, and its simpler to handle the empty packages than add a bunch of handling to the control file generation to turn them off
<Kano> i would prefer when they would not build at all when i disable em
<Kano> i dont see those in mainline too
<apw> right in mainline i use the uber-complex 'rm' command to remove them before syncing them out
<Kano> well if you have got free time maybe consider em not to build
<apw> i have considered it, i have even got patches to do it, and it makes the rules vile and complex
<apw> for something we never use
<apw> and afterall they are our packages to build our kernel not all things to all men
<Kano> well they would be more usefull
<Kano> i always try to write scripts as generic as possible
<cking> generic for whom?
<apw> so do we but at some point one has to trade genericity for maintainability
<apw> we have to maintain them for years against old kernels and that is not free
<Kano> well i just want to script all changes i need against your packages
<apw> so what you are saying is, its too much effort for you to fix the packaging, but you think we should
<Kano> well you know the packageing
<apw> indeed, so which is more important for your kernel
<apw> having pretty packaging that allows a derivative to build easily, or having CVEs fixed in your kernle
<apw> as right now, that is what you are stopping me doing
<Kano> well i mainly use that for live mode, i need mainline builds...
<Kano> for the hd installs
<Kano> i write a tiny script for every kernel update, but there is no update
<Kano> daily is of course always the same script
<apw> yep the entire kernel.org infrastucture being compromised has been a huge problem
<apw> not least because it has _prioritised_ security fixes above _ALL_ELSE_
<apw> now i wonder why that would be
<Kano> you mean for the older kernels?
<Kano> the latest is on github, that should be no problem to build rc6/daily
<apw> yep, indeed and i'll put it on my todo list
<Kano> is armel somehow differently handled? not that i would use it but
<Kano> http://paste.debian.net/129942/
<apw> no its not handled differently
<Kano> why is there no 1000 hz for it then
<apw> perhaps because it can't do 1000Hz ?
<Kano> maybe
<cking> 1000Hz for arm is a bit excessive isn't it?
<apw> 1000HZ == 10% powerformance cost too
<Kano> what bootloader is used on arm?
<apw> depends on the board they are all different pretty much
<Kano> the wireless-cdra package is weird, it has got no depends but
<Kano> crda: error while loading shared libraries: libnl-genl.so.3: cannot open shared object file: No such file or directory
<apw> sounds like a bug to me
<AnAnt> Hello
<AnAnt> I am developing a kernel module under Ubuntu, sometimes this module causes the PC to freeze, is there a way to get dmesg (or whatever debug info) output over the network ?
<apw> AnAnt, netconsole might do it, depending how hard it freezes
<AnAnt> apw: how about serial port (note, the PC does not have a serial port, but I can use a USB/serial converter)
<apw> usb serial can work sometimes, again depending on how hard the kernel is crashing
<tgardner> apw, need to bounce gomeisa for kernel update
<apw> tgardner, ACK now is as good a time as any
<AnAnt> apw: thanks
<apw> tgardner, let me know when its done i have some builds pending
<tgardner> apw, its bouncing, should be back up in 90 seconds or so
<AnAnt> apw: how to do it on serial ?
<apw> AnAnt, usb serial? 
<AnAnt> apw: yes
<apw> just add console=ttyUSBN I think
<AnAnt> ok, thanks
<AnAnt> apw: so I can only set the serial console during boot?
<apw> i believe so ... never heard of any way to add them
<AnAnt> apw: ok, thanks a lot
 * ogasawara back in 20
<cking> apw, git://kernel.ubuntu.com/cking/pmdebug.git --> systemtap/s3.stp  led_flash()
<ppisati> herton: lucid was respinned, and the reverted patchset was only the i915, right? i'll invalidate all the derivative arm lucid bug trackers
<herton> ppisati: yep
<apw> $ ps -ef | grep gcc | wc -l
<apw> 282
<apw> $ ps -ef | grep cc1 | wc -l
<apw> 41
<hallyn> so is there a non-kernel.org mirror of Linus' tree right now?
<apw> hallyn, yes
<hallyn> Need to base some patches on it to send upstream...
<apw> git://github.com/torvalds/linux
<hallyn> apw: great, thanks
<ogasawara> ubuntu-oneiric$ git push origin :Ubuntu-P-sync
<ogasawara> remote: *** Deleting a tag is not allowed in this repository
<ogasawara> remote: error: hook declined to update refs/tags/Ubuntu-P-sync
<ogasawara> To git+ssh://zinc.canonical.com/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-oneiric.git
<ogasawara>  ! [remote rejected] Ubuntu-P-sync (hook declined)
<ubot2`> ogasawara: Error: I am only a bot, please don't think I'm intelligent :)
<ogasawara> error: failed to push some refs to 'git+ssh://zinc.canonical.com/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-oneiric.git'
<ogasawara> apw: ^^ I assume that's due to the new restrictions in our repo?
<apw> ogasawara, yeah, hmmm, thats neither a signed tag, nor is updating them allowed ... hmmm ... push it as a branch for now perhaps
<ogasawara> apw: ack
<apw> we can likely just add an exception for that tag namespace
<apw> :q
 * apw punches unity in the face repeatedly ... _do_not_paste_my_output_in_the_wrong_window_that_might_be_my_password_
<_ruben> :q is your password? good to know :)
<ogasawara> heh
<apw> heh luckily not, but it might be safest if it was
<_ruben> ;)
<apw> "smb, what time is it there?" would make a good password
<hallyn> hm, laptop isn't even that hot, but just shut itself down...
<hallyn> nothing in syslog
<apw> hallyn, how quickly
<apw> and its not suspended is it?
<hallyn> no, it just acted as though i'd hit the power button
<apw> we seem to have a new suspend on idle on AC
<hallyn> it also wasn't idle, i was in the middle of typing :)
<apw> so ... like you pressed it (full shutdown messages) or like you held it
<hallyn> like i held it
<hallyn> no shutdown msg
<hallyn> nothing in syslog at all for several mins before booting up
<apw> hallyn, running what release, which kernel
<hallyn> oneiric, uptodate
<apw> not see that, no
<hallyn> thermal0/temp is showing 84000 - whatever that means
<apw> could be anything, likely as not 84c
<apw> but hte units are not easy to determine at times
<hallyn> I've had this happen once or twice before, but when it was much hotter, and I do believe that file was around  100 when i rebooted
<apw> 105 is a common 'i am turning of NOW' value
<hallyn> i think i once deduced it actually did correspond to degrees celsius, don't recall how/why
<apw> indeed they are often listed in /proc/<somewhere>
<apw> cking, where is the thermal trip stuff hidden in proc ?
<cking> apw - i'm on a call at the mo
<hallyn> serge@sergelap:/sys/devices/virtual/thermal/thermal_zone0$ cat trip_point_0_temp 
<hallyn> 98000
<apw> ahh there you go then, but if you are at 84c that in of itself is worrying
<apw> are you fanning?
<hallyn> I'm down to 70 now
<hallyn> yeah, fan is always goin gon this thing
<apw> thinkpad ?
<hallyn> vaio f11
<apw> what is your machine doing that 70c is a sane temp ?
<hallyn> I had shut down u1 some time before, so i was just doing a libvirt build, running kvm, and playing a song...
<apw> it'd want to be compileing on something
<apw> so you are kicking the crap out of it, so perhaps 70 is expectable
<hallyn> well, it's an 8-core 8G laptop, I don't take it easy on it
<hallyn> no serioualy this thing easily hits 90
<hallyn> but i dont' think it had hit 98
<apw> that sounds like pretty poor thermal control.  an 8 core thingy in a laptop, mental
<hallyn> all right, i guess i'll keep a little display up with the temp values
<apw> yeah good plan try and keep some history
<hallyn> heh, i had to quickly choose something when i joined canonical.  i'd have preferred a good desktop and a netbook.  but this thing mostly serves me well
<hallyn> all right, i'll ping back if it does it again without hitting 98
<hallyn> thanks
<apw> hallyn, made the same mistake myself
<hallyn> I guess in about 1.5 years I'll start looking for a kick-ass desktop :)
<hallyn> (this is one of those times i'm happy to be using wmii so i can just change my status shellscript :)
<hallyn> hanging steady at 67 right now
<tgardner> apw, dpkg-buildpackage is just a script. AFAICT it simply adds -jX to MAKEFLAGS before running debian/rules. 
<apw> hmmmm
<tgardner> I haven't quite been able to simulate it by hand yet
<tgardner> ppisati, do you want the ti-omap4 kernels uplaoded with the DMA/SMP performance fix ?
<tgardner> apw, ogasawara: pushed 'UBUNTU: [Config] Fix binary-% build target' to oneiric master-next
<ogasawara> tgardner: ack
<apw> tgardner, nice
<tgardner> I'll figure out the AMKEFLAGS business and build it into debian/rules somehow
<tgardner> MAKEFLAGS*
<hallyn> apw: say do you know of a way to set the trip_point? file isn't writeable...  and a simple sbuild of libvirt-bin quickly brought temps to 92 (trip point being 98)
<apw> hallyn, normally they are bios set and bios enforced, they are exposed to allow the OS to help in heat managment i expect
<tgardner> hallyn, trip points are typically the domain of BIOS/SMI AFAIK
<hallyn> drat
<apw> i really don't think you should be hitting anywhere near it if the bios was managing fans correctly
<hallyn> at least 94 seems to be another, 'passive' trip point.  I guess I should go read up.  must be some discussion online
<apw> it must burn your hands if you go anywhere near the case
<hallyn> it gets warm, but not that bad.  
<hallyn> maybe one of those fancy powered laptop stands would help :)
<apw> i am suspicious that there are a number of bioss out there which do not handle the fans, but they ship windows drivers to override the fans to make things work
<hallyn> oh!  actually, i guess sony had a bios update about this.
<hallyn> but the damned thing isn't usable in linux or even in windows 2008
<hallyn> now, this time after it hit 94 it started going down.  so maybe the 'passive' trip poitn didn't trip last time, and so it kept climbing?
<hallyn> maybe i should drop by the sony store
<tgardner> hallyn, maybe you should be using tangerine
<hallyn> tgardner: i was just compiling libvirt...
<hallyn> that would feel like abusing resources
<tgardner> hallyn, well, it beats having your laptop sizzle
<hallyn> true
<bjf> hallyn, i use http://pastebin.ubuntu.com/689370/ to jam the fans on for my thinkpad, don't know what you'd need to change for it to work for you
<hallyn> bjf: yeah, i might have to bypass the kernel's trip point and have my own little daemon bump up the fan.  good idea.
<tgardner> its gotta have support in the platform driver
<hallyn> yeah and i don't see a fan control under /sys/module/sony_laptop
 * tgardner --> lunch
<apw> bjf, did you get the magic for bootchart ?  as i have just seen one with the lines which was generated this week
<bjf> apw, yes been working on it all a.m. :-)
<apw> bjf, can you make sure you also turn on initcall_debug on the test boots and grab the dmesg as well
<bjf> apw, ack
<jjohansen> rebooting
<htorque> ogasawara: hi! bug 834725 â looks like this is not a bug in linux after all, right?
<ubot2`> Launchpad bug 834725 in linux "Powertop fails to report number of wakeups/events" [Undecided,Confirmed] https://launchpad.net/bugs/834725
<ogasawara> htorque: was just about to comment there.  indeed, I do not believe this to be a kernel issue.  so I was going to close out the linux task.
<htorque> good, thanks :)
 * jjohansen -> lunch
<smoser> smb, do you happen to be around ?
<smoser> http://groups.google.com/group/ec2ubuntu/browse_frm/thread/57ff20c6370f7bb9
<smoser> we should have someone look at that.
 * ogasawara bails a little early for an appointment, back on later.
<jj-afk> back on later
<openfly> well that sucks
#ubuntu-kernel 2011-09-15
<LLStarks> hi, will there be any new daily kernels before kernel.org comes back?
<ppisati> morning *
<apw> LLStarks, we hadn't expected it to be away for so very long
<apw> morning
<janimo> does the kernel team do cross builds of ARM kernels when testing?
<ppisati> janimo: i always cross compile
<ppisati> janimo: from time to time, i do a native kernel compilation but it's way too slow
<janimo> ppisati, is the process written up somewhere, is the kernel wiki up-to-date?
<ppisati> janimo: uhm
<ppisati> janimo: don't think so
<janimo> ppisati, :D
<ppisati> janimo: but baisally you have to
<ppisati> janimo: export $(dpkg-architecture -aarmel); export CROSS_COMPILE=arm-linux-gnueabi-
<janimo> I'd like to use that approach for the ac100 package which has an external git tree
<ppisati> janimo: fakeroot debian/rules clean; fakeroot debian/rules binary-$flavour
<ppisati> and that's it
<janimo> ppisati, ok. How do I set up the tree initially. Vanilla kernel upstream flavour and over that some deb/ubuntu specific directories
<ppisati> janimo: yep, somehow
<janimo> then I git pull/rebase/cherry pick and do a new debsrc build
<ppisati> janimo: more or less is what i did with the omap4 kernel
<ppisati> janimo: look at the oneiric/omap4 branch
<ppisati> janimo: the first... 5? 6? commits
<ppisati> janimo: are the "debianification" of a vanilla linux tree
<ppisati> more or less
<janimo> ppisati, thanks will check
<smoser> smb, did you see my ping from yesterday when you were sleeping ? 
<tgardner> smoser, smb is on vacation this week
<smoser> ok. then i'll open a bug. htank you tgardner 
<smoser> i swear, you let people take vacation ?
<tgardner> smoser, well, I didn't have a lot of choice :)
<tgardner> ogasawara, do you still want to add these last 2 patches from the list onto master-next ?
<ogasawara> tgardner: was just looking at them.  might as well get em onto master-next as I'm sure we'll do another upload prior to release.
<ogasawara> tgardner: but I'm following SRU policy so want 2 ack's before applying
<tgardner> ogasawara, ack
<tgardner> ogasawara, I also dumped the 'ata: make DVD drive recognisable on systems	with Sandybridge CPT chipset' patch on ubuntu-p so we don't lose it.
<ogasawara> tgardner: cool, thanks
<jonpry> can someone take a look at https://bugzilla.redhat.com/show_bug.cgi?id=699156 i've verified it is still happening on 3.1-rc4. Working on a year of this.
<ubot2> bugzilla.redhat.com bug 699156 in kernel "Large amount of acpi interrupts on lenovo y560p with 2.6.38+" [Unspecified,New]
<jonpry> while rc4 is definitely the coolest running kernel to date. (73C at idle), it seems to have taken the interrupts to a new level. Over 100k per second now. 
 * ogasawara back in 20
<jjohansen> rebooting
 * tgardner --> lunch
<hallyn> Is there a url to point to about the official stance on kernel backports to LTS?
<ogasawara> hallyn: I'm unaware of anything myself, but tgardner would probably be the one to ask if something did exist.
<hallyn> ogasawara: ok, thanks.  I thought something came out of UDS about 'official' support.  will wait for tgardner :)
 * ogasawara lunch
<tgardner> hallyn, yes, there is official LTS backport support. 
<hallyn> tgardner: is there a URL to point people to?  
<tgardner> hallyn, not as far as I know. I think details are to be announced at UDS. you could bug risk spencer for details in the meantime,.
<tgardner> rick*
<hallyn> tgardner: ok, but the official ones are the linux-image-server-lts-backport-natty etc packages (not kernel-ppa) right?
<hallyn> tgardner: thanks
<tgardner> hallyn, correct. all official packages are in Lucid main
<hallyn> great, thanks
<tgardner> hallyn, any idea where I could find a kernel.org mirror that might have a copy of b43-open/ucode5.fw ?
<hallyn> tgardner: whose tree was that in?  i only found out here yesterday about Linus' github mirror :)
<hallyn> and that's not there, sorry.  
<tgardner> hallyn, from dmesg: 'May 9 13:39:19 (none) user.err kernel: b43-phy0 ERROR: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefull read all instructions on this website'
<tgardner> hallyn, I think I found it in openwrt.
<hallyn> yikes. that sucks
<hallyn> I'm really curious to see if they'll figure out the attack vector used
<tgardner> I'd sure like to see kernel.org reappear.
<jjohansen> rebooting
<Kano> hi, you could add those 2 patches or best bring em to mainline .39/3.0
<Kano> http://www.marcet.info/2011/08/dib0700-race-conditions-in-2-6-39-1-and-3-0
<Kano> otherwise some dvb-t dongles do not work
<Kano> tested and verified
<Kano> http://kanotix.com/files/hellfire/ubuntu-3.0.0/kanotix-dvb-fixes.txt
#ubuntu-kernel 2011-09-16
<jonpry> is there an ACPI support group or recovery channel?
 * apw looks out blearily ...
<cking> jet lagged still?
<apw> a bit perhaps, not sure, just feeling lethargic this morning
<apw> a couple of beers last night did not help i suspect
<htorque> hi! i have no idea where to ask, but maybe you can help me out: yesterday i experienced a strange thing where "killall opera" killed opera and xchat.
<htorque> i killed opera, because unity's alt-tab switcher preview for opera showed me the xchat window and i thought that's just another unity bug. that seems rather scary, what could cause this? 
<apw> htorque, i have never seen that myself.  killall iirc uses the command lines listed in /proc/$$ to identify matching processes.  So a bug in killall or a bug in kernel display of those could trigger this.  Also a bug in display of your command line could also do so, say you ended up really running killall a ... i get that sometimes in bash with wide terminals
<apw> its unlikely that those kinds of bugs could also trigger a miss match of the preview, however coincidental that might be, as that is done via X properties ... specificially the X class for unity
<htorque> it would just be a strange coincidence that also unity's... right :)
<apw> i suspect that actually xchat may have already been lost and just its preview retained in unity
<htorque> it was actually the other way round - opera was kinda lost. :-/
<htorque> and i only killed opera, according to my bash history
<htorque> could this be caused by memory corruption (ie. a hardware error)?
<apw> right what i am suggesting is that xchat was actually 'gone' already ie the process was dead, unity was confused and showing xchats last output as the preview for opera, so when you killed opera that got rid of the preview
<htorque> i see. now: how do i reproduce that? :P
<apw> cking, its POSTPONED ...
<apw> htorque, heres hoping that the unity updates get rid of it :)
<cking> apw, me made a typo? eh?
<apw> cking, or your internal dictionary is corrupt
<cking> the latter
<apw> cking, ok you corrected it already, but then deleted the workitem and orphaned one
<htorque> apw: k, thanks for your answer! at least now i have something to check if that should happen again. :-)
<cking> apw, my fail
<apw> cking, was the item meant to get deleted? as i have the update here if you need it
<cking> which item?
<apw> - [colin-king] pre-test program to confirm what output devices they may have: POSTPONED
<apw> +
<apw>   [sconklin] investigate video DDC pin: TODO
<apw> you did that, which deletes an item and replaces it with a blank line, which leaves steves item in the lurch
<apw> but i am unsure if you intended to delete it or not
<cking> yep, it was intentional to delete that, I think I moved it up and made a note
<apw> oh yeah off the top of my screen, doh, so i'll unorphan that item then
<apw> cking, ok fixed
<cking> thanks, my fail
<apw> cking, so the items you deleted i think actully both are DONE
<apw> the first the result was "we are not going to do this"
<apw> and the second the work went into the debug repo not the kernel, but you did the work
<apw> cking, so i think you should write a section for each in the results section of the spec (just a couple of sentances on why/where the work was done) and then mark them :DONE
<apw> else the work you did just dissappears
<cking> hold on - can I get back to this, I'm doing a tutorial at the mo - I will take you advice and fix it up at 11.30am
<apw> cking, yep
<apw> cking, this is irc, just ignore me until you have time, that is the nature of irc
 * cking is single threaded
<apw> who isn't
<ppisati> the "look into generating a trimmed down config for debug purposes" in the "Kernel Configuration Review" was more of a request from me to what interesting options i could turn to ease debugging: i think i was looking for some magic switch like "turn off smp, turn off cc optimization, etcetc" to avoid having to do that by hand everytime
<ppisati> so, to what status can i put this item like "it never made any sense"? POSTPONED? don't think so
<apw> pgraner, this from a grub prompt: hwmatch ${prefix}/gfxblacklist.txt 3
<apw> pgraner, then: ec
<apw> pgraner, then: echo $?
<apw> (ignore the ec)
<apw> pgraner, then: echo $match
<apw> pgraner, then: set
<apw> and see what the gfx thingies are set to
<apw> pgraner, what i get is only the modeswitch black flicker just before plymout and a white flash as lightdm starts, the first is unavoidable, the second is a bug
<apw> wmatch ${prefix}/gfxblacklist.txt 3
<apw> arrgle
<pgraner> apw, cool, let me update my laptop first and see what it does, then I'll get back to this machine
<cking> apw, I've updated the s3/s4 spec with copious amounts of notes now ;-)
<cking> and added some wiki page updates else where too
<cking> so it was a good exercise in dotting the i's and crossing the t's
 * ogasawara back in 20
<diwic> ogasawara or apw, what are the odds for 3.2 vs 3.3 vs 3.4 for Ubuntu 12.04?
<ogasawara> diwic: not sure, we havent really discussed it yet.  I believe there was talk about 3.2 at plubmers
<diwic> ogasawara, which means all feature development for kernel must happen within a few weeks from now...?
<diwic> I think the 3.2 merge window opens soon
<ogasawara> diwic: that would be the case if we went with 3.2
<ogasawara> diwic: if there are reasons to go with a newer kernel, probably best to make sure we're aware going into UDS as that's where we make the decision
<diwic> ogasawara, yeah, I'll try to attend that session. For me a later kernel is always better (less things to backport)
<tgardner> ogasawara, in reality we're not gonna choose a kernel version until January. UDS is simply too early to know for sure.
 * ogasawara nods
<diwic> tgardner, sure. It just is good to have some kind of feeling for it. I mean, should we go for 3.2, FeatureFreeze for kernel is ~4 months ahead of FeatureFreeze for userspace
<tgardner> there are a lot of competing pressures, not all of which I can predict.
 * apw nods sagely
<diwic> tgardner, of course. As long as there as get to add my pressure I understand that it will not always prevail :-)
<apw> we have had a lot of benefit from .32 being a long-term kernel
<apw> we would love to have 12.04 on a similarly long-term kernel
<diwic> but in short, there's a real chance it might be 3.2, so better safe than sorry and try to do kernel development for P asap
<diwic> apw, sure. Is 3.2 going to be such a long-term kernel?
<apw> that is something we need to figure out for sure
 * apw looks at the sun longingly ... i am gonna drift off while its still nice ... see yas
<sforshee> sconklin, looks like commit bbeaf8811 introduced an i915 regression in natty -- bug 838181
<ubot2> Launchpad bug 838181 in linux "External monitor connected trough mini DisplayPort wired to integrated Intel AGP is properly recognized and configured but has no sync" [Medium,Triaged] https://launchpad.net/bugs/838181
<sconklin> sforshee, whee
 * sconklin is wondering if it's time to remove the word 'stable' from upstream updates
<sforshee> sconklin, actually that one didn't come from stable :(
<sconklin> heh
<sconklin> I take back everything bad I ever said about upstream
<sforshee> sconklin, do you just want to revert the commit, or do you need me to do something with it?
<sconklin> sforshee, I'm looking but I will likely revert and respin
<sforshee> okay, let me know if there's anything you need me to do
<sconklin> sforshee, ok, thanks. I flagged the tracking bug, so it can't get released
<sconklin> sforshee, nice job isolating this, thanks!
<sforshee> sconklin, it looks like this one's already in -updates, the patch was in 2.6.38-11.47
<tgardner> ogasawara, hey, I got upstream b43 working with open firmware in 3.1-rc6. maybe we're close to seeing the last of wl
<sconklin> sigh.
<ogasawara> tgardner: \o/
<sconklin> ok, then normally we just ship this version and fix it in the next. I'll unblock the tracking bug and stick the revert onto master-next. Actually, I'll talk with the author first, they probably want to get it fixed properly
<ogasawara> tgardner: should we consider pulling it into lbm?
<tgardner> ogasawara, there is some merit to that idea. I need to track down the provenance and licensing of the open firmware so I can add it too the linux-firmware package
<ogasawara> hrm, I just realized I haven't been bumping lbm ABI and uploading
<tgardner> ogasawara, tsk, tsk.
 * ogasawara add it to today's todo list
<tgardner> ogasawara, as for backporting, we'll get the b43 work for free with compat-wireless
<ogasawara> tgardner: ah cool
<tgardner> ogasawara, it may actually work with the oneiric kernel with the proper firmware
<tgardner> ogasawara, oh, thats just way cool. b43 works like a charm with 3.0.0-11
<ogasawara> tgardner: nice, ship it
<tgardner> ogasawara, don't you have an Inspiron 1501 with b43 ?
<ogasawara> tgardner: nope, inspiron 1420 iwl3945
<tgardner> ogasawara, hmm, are you experiencing wifi slowdowns with 3945?
<ogasawara> tgardner: none here, but I don't use that laptop much aside from running mumble on it
<tgardner> ogasawara, ok. there is alot of bitching about 3945 performance lately
<ogasawara> tgardner: I'll see if I can get any metrics to confirm
<ogasawara> bjf, jjohansen: you guys going to be knitting today?
<bjf> ogasawara, nope, don't plan on it
<vanhoof> tgardner: manjo was looking into a wifi perf issue on a 6250 iirc which he could only reproduce on oneiric
<vanhoof> tgardner: believe he said his router was N only fwiw
<tgardner> vanhoof, I've tested a couple of the intel parts against N only. they aren't as fast as I'd like, but they are at least as good as 100 Mbit.
<manjo> with mainline RC4 it is even worse 
<vanhoof> tgardner: what do you use for testing?
<vanhoof> tgardner: i have a couple cards floating around as well here
<tgardner> vanhoof, WRT310N is the AP, 6300 and 6250 (I think) for wifi card
<vanhoof> tgardner: test wise, something like iperf?
<tgardner> vanhoof, yes
<jjohansen> ogasawara: yep
 * ogasawara heads in to meet up with pdx mafia
 * jjohansen heads to meet up with the pdx mafia too
 * tgardner -> lunch
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703180
<ubot2> Ubuntu bug 703180 in linux "SD card reader inaccessible without pci bus rescan" [Undecided,Confirmed]
<dupondje> somebody could check this? should really get fixed is my idea ;)
#ubuntu-kernel 2011-09-17
<beata|coyote> Eh. I'm sitting down to debug the dock/undock capability on this laptop, and I'm not really sure where I should start.
<shbk> hello, may be someone 'll help. i want to find out how many keys my keyboard has.  i have tried lshw , lspci,  hwinfo, sysinfo,hardinfo.  i am planning if this bash function to use it in c++ via   system() call, afterward receive output, parse it and take what i needed. i 've  almost all info about system which is needed.  but I'm confused with keyboard. how can i do this in c++ or bash?
<Donnie2> hi
<Q-FUNK> is Brad Figg here?
#ubuntu-kernel 2011-09-18
<bullgard4> How is the 'machine hardware name' defined that the command '~$ uname -m' outputs? '~$ info coreutils 'uname invocation' returns the additional information: "sometimes called the hardware class or hardware type" and does not give a definition either.
#ubuntu-kernel 2012-09-10
<green7> Hey, I want to know how does Ubuntu manage process synchronization? Particularly, how does it implement locking?
<green7> can anyone clarifY?
 * henrix -> lunch
<MCR1> Hi everyone :)
<MCR1> I wanted to report that Kernel 3.6 (tested RC1 and RC4) breaks SSL. Uploading to launchpad for example is impossible with current Kernel 3.6.
<MCR1> Are you aware of that ?
<dileks> MCR1: what makes you believe that? any logs you can paste?
<MCR1> dileks: Simply try it. It works on all 3.5 versions, once I upgrade to 3.6 it stops working. It creates a lock, but no data is transmitted...
<dileks> I am not on your system. what ubuntu-release do you use? any third-party repos involved?
<MCR1> dileks: I have to do a bzr break-lock then, while with Kernel 3.5 all works. I am on Quantal here.
<dileks> are you using ubuntu mainline kernel or self-compiled ones?
<MCR1> dileks: Mainline kernel.
<dileks> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc5-quantal/
<dileks> rc5 is out
<MCR1> I just tried RC1 and RC4, but I can try RC5 also and then report here (might take a while though...)
<dileks> I am here on ubuntu/precise amd64 with linux-next kernel
<MCR1> dileks: Can you try if SSL works if you are using 3.6 on Precise ?
<ricotz> MCR1, btw what makes you think SSL is broken?
<MCR1> ricotz: It does work on Kernel 3.5, but not on 3.6 - that makes me think it is the Kernel's fault - because nothing else changed
<MCR1> ricotz: Also I tried 2 different 3.6 kernels and multiple 3.5 ones -> always the same effect -> works on 3.5, but not on 3.6
<ricotz> MCR1, so you can't get any ssl connection with e.g. firefox?
<MCR1> ricotz: uh, I did not try that - but I cannot upload to launchpad anymore (which uses SSL)
<MCR1> bzr push fails
<ricotz> MCR1, that is why i am asking bzr might not be the best to confirm such a problem
<MCR1> ricotz: You might be right on this one :)
<ricotz> while the kernel isnt responsible for that in the tighter way
<ricotz> this might be a network driver problem
<ricotz> or a nic firmware problem
<MCR1> sure, but the normal internet works
<MCR1> ricotz: I will try to run more tests later, then I can make sure it is SSL
<ricotz> just saying it doesnt sound plausible to blame the kernel for ssl not working
<MCR1> also 3.6RC5 is untested here yet
<MCR1> something's fishy, believe me
<ricotz> good luck then
<MCR1> thx
<rtg> henrix, herton: natty is done, right ? no more changes ?
<herton> rtg, yes
<rtg> good
 * ogasawara back in 20
<orated> Hello! After completing modprobe operations on kernel module, is there any thing to do so that I don't have to repeat modprobe steps on every system boot?
<rtg> orated, you couls add it to /etc/modules
<rtg> could*
<h00k> I'm having an interesting tcp-session issue with the latest kernel for ubuntu+1
<h00k> booting from an older kernel resolved the issue - I'm not sure if it has to do with my wireless adapter or the kernel itself, but the kernel log was full of tcp problems.
<h00k> Has anyone else reported similarly?
<jsalisbury> h00k, it would be good to open a bug in Launchpad.  That would help to track all the appropiate info and let others mark as a duplicate if they are seeing it too
<h00k> jsalisbury: yes, I will do so. The only problem is that it filled up my / so I had to remove it. Later when I'm home, I'll try to reproduce, get a log, and submit it.
<h00k> Also, I have to get it before it gets too big for my internet to upload it :/
<jsalisbury> h00k, you could open the bug with the previous kernel, so you don't have issues.  Then post the errors you are seeing in the log
<infinity> ikepanhc: Is that armadaxp kernel in PPA ready to copy?
<infinity> ikepanhc: The precise one, that is.
<infinity> ikepanhc: I was about to copy it, but wasn't sure the point of your cryptic paste in the tracking bug. :P
<ikepanhc> infinity: yes, the 3.2.0-1608.13 is ready for copying
<infinity> ikepanhc: Check.  On it.
<ikepanhc> infinity: thanks :)
<vanhoof> ikepanhc: up late? :)
<ikepanhc> vanhoof: fall to sleep at 7pm, now no idea how to get to sleep
<vanhoof> ikepanhc: beer?
<ikepanhc> vanhoof: I perfer something stronger
<vanhoof> lol, vodka?
<ikepanhc> good idea :)
 * rtg -> lunch
 * cking -> EOD
 * ogasawara lunch
<rtg> ogasawara, what do you think about an upload to fix these trackpad/touchpad and Apple gmux bugs ?
<ppisati> back online...
<ogasawara> rtg: sounds good to me, I'll kick off test builds and upload
<rtg> ogasawara, its a non=ABI bumper
<ogasawara> cool
 * rtg -> EOD
<dantti> hi, is there a chance to get this option enabled in quantal kernel? it's been a while without comments on the bug report... https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1003090
<ubot2> Launchpad bug 1003090 in linux "Please enable HID_BATTERY_STRENGTH (on xorg-edgers and quantal kernel packages)" [Medium,Triaged]
<jcs3f364363> Hi, I wish to report a kernel 3.5.3 bug. I've never do this before, I don't even know if I am in the right place. I was wondering if someone could help me.
<jcs3f364363> Trying to use the integrated webcam makes the system freeze(No ctrl+Alt+Backspace, no ctrl+alt+F1 F2...). This didn't happened with 3.2.0 kernel
#ubuntu-kernel 2012-09-11
<cooloney> ppisati: hey, paolo
<orated> Hello! Is there a documentation on how and what all devices are mapped in /sys and/or /proc? I'm not able to find details on the same in FHS doc.
<cwillu_at_work> orated, /sys is a kernel interface; fhs has nothing to say about it
<cwillu_at_work> Documentation/sysfs-rules.txt and Documentation/filesystems/sysfs*.txt in the kernel tree documents it
<cwillu_at_work> pay particular attention to sysfs-rules.txt if you're making something that uses it
<cking> orated, http://www.kernel.org/doc/Documentation/filesystems/proc.txt
<orated> Yes, thanks. I remember accessing those documentation for GPIO - http://www.kernel.org/doc/Documentation/gpio.txt (and http://squidge.sourceforge.net/gpio/README.txt) On the same line, is there any command which gives the table for GPIO pins as shown in the second link or is it from datasheets?
<orated> cwillu_at_work:  cking:  On the same line, is there any command which gives the table for GPIO pins as shown http://squidge.sourceforge.net/gpio/README.txt  or is it from datasheets?
<cking> orated, that I don't know
<cwillu_at_work> general-purpose-io pins are commonly defined by the specifics of the (hardware) installation
<orated> cwillu_at_work: Yes, but is the last table shown in the link possible within linux? I just thought if its from data sheets or accessible from kernel
<orated> Ah-ok!
 * henrix -> lunch
<dobey> hi all. is there a 3.6-rc kernel packaged up anywhere that would be installable on precise?
<amitk> dobey: deb http://ppa.launchpad.net/ubuntu-x-swat/q-lts-backport/ubuntu precise main
<amitk> dobey: ^^^ contains kernel and Xorg from Q (which will be supported going forward)
<amitk> dobey: or you could add just the kernel team PPA for a kernel
<amitk> don't have a link handy
<dobey> amitk: that is only 3.5.0 though it seems
<dobey> does it have Intel video code backported from the mainline 3.6 branch?
<amitk> dobey: aah, you're right. I somehow read "Q kernel on P" into your question. The kernel team PPA has a mainline 3.6-rc
<rtg> dobey, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc5-quantal/
<amitk> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<amitk> aah, rtg got there first
<dobey> rtg: oooh, great, thanks. is that installable on precise?
<rtg> dobey, yep
<dobey> awesome. i will try that. thanks
<arges> rtg, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1032874
<ubot2> Launchpad bug 1032874 in linux "Mount command on extended partition hangs forever during install" [High,Triaged]
<smoser> why do our kernels print cmdline twice ?
<smoser> http://paste.ubuntu.com/1199019/
<rtg> smoser, I'd think that is how grub is doing it. Look at your local dmesg. the command line doesn't appear to be duplicated there.
<smoser> its not grub
<smoser> that was loaded with pxe
<smoser> but you might be right.
<smoser> i can't refute it.
<ogra_> i have that here too ... 
<ogra_> no PXE involved
<ogra_> bith have different prefixes though
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ogra_> Command line: vs Kernel command line
<rtg> smoser, I only see one thing duplicated: 'initrd=amd64/generic/precise/commissioning/initrd.gz'
<rtg> oh, printed again later down. never mind.
<smoser> i meant printed twice
<smoser> right.
<ogra_> on omap4 kernels i inly see "Kernel command line"
<ogra_> *only
<rtg> huh, on X86_64 I only see it printed once.
<ogra_> on precise x86_64 its twice 
<rtg> 3.2.0-31-generic ?
<ogra_> ogra@anubis:~$ grep -i command /var/log/dmesg
<ogra_> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-29-generic root=UUID=64ce333b-aa6d-495e-9f01-cf5d4410184d ro acpi_enforce_resources=lax splash quiet vt.handoff=7
<ogra_> [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-29-generic root=UUID=64ce333b-aa6d-495e-9f01-cf5d4410184d ro acpi_enforce_resources=lax splash quiet vt.handoff=7
<ogra_> ogra@anubis:~$ uname -a
<ogra_> Linux anubis 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<ogra_> havent rebooted, .31 is installed already though 
<rtg> ogra_, ok, I wasn't searching for the right string.
<rtg> smoser, is this causing you issues, or are you just curious why its printed twice ?
<smoser> rtg, not causing me issue. just wondering.
<smoser> and came across it when i was looking at an arm log
<smoser> and i think it only had one of these.
<ogra_> yeah
<ogra_> ogra@panda1:~$ grep -i command /var/log/dmesg
<ogra_> [    0.000000] Kernel command line: ro quiet splash root=UUID=2acc5a3d-1639-4f68-86e5-f7ef0354e00d
<ogra_> ogra@panda1:~$ 
<rtg> smoser, so the first line is arch specific, arch/x86/kernel/setup.c. the second time its printed is from init/main.c which is generic
 * rtg -> lunch
 * cking --> EOD (way too long today)
 * rtg -> EOD
<jjohansen> bjf: I have not been able to duplicate your apparmor test failure, can you send me some more info from those qa machines?
<bjf> jjohansen: like what? i can open a bug and do the normal apport-collect.
<jjohansen> bjf: yes please, I would also like the mount info
<bjf> jjohansen: can do
<jjohansen> bjf: also I have confirmed that the test suite is building locale versions of somethings for certain tests.  Eg. the parser tests are done against a local built version.  However the kernel tests do use the kernel and installed packages and are only locally building the test support programs
<jjohansen> I have added it to our to do, to have all tests support testing against the installed packages
<bjf> jjohansen: ack
#ubuntu-kernel 2012-09-12
<Prf_Jakob> Is Tim Gardner in here?
 * rtg upgrades his laptop to quantal....
 * henrix -> (late) lunch
<Prf_Jakob> rtg: Hey
<rtg> hmm?
 * Prf_Jakob Bornecrantz
<Prf_Jakob> vmwgfx guy
<rtg> does it work for you ?
<Prf_Jakob> I haven't test it actually 
<Prf_Jakob> But I can do that.
<Prf_Jakob> I'm wondering if you will cherry pick those to patch and maybe even the dumb_fb patch?
<rtg> Prf_Jakob, the first patch is in Ubuntu-3.5.0-14.15, and is coming in Precise.
<Prf_Jakob> Ah ok good
<rtg> I'm reluctant to pick the FB patch since it does represent a more radical change
<rtg> Prf_Jakob, the bug reporter did indicate that the minimal patch solved his issues
<Prf_Jakob> the xf86-video-vmware packages install a modprobe rule that does the same.
<rtg> Prf_Jakob, I'm fine with leaving it up to user space to do that
<Prf_Jakob> Ok
<rtg> Prf_Jakob, the first patch is in Precise Ubuntu-3.2.0-31.50 (likely still in -proposed)
<Prf_Jakob> k thanks
<hggdh> folks, I would really appreciate a look at bug 1049395, we have had 5 failures on 7 runs on it
<ubot2> Launchpad bug 1049395 in linux "ext4: kernel BUG at /build/buildd/linux-2.6.38/fs/buffer.c:2900!" [Undecided,Confirmed] https://launchpad.net/bugs/1049395
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues September 18th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<bjf> hggdh, i'll look but as i was explaining yesterday, i've seen this occasionally myself and of the 13 commits that have gone into natty in the last two kernel versions, _none_ are against ext4. they are mostly networking or ecryptfs
<bjf> hggdh: you could try 2.6.38-15.66 for comparison
<doko> ogasawara, can somebody bump the ABI in linux-meta-lowlatency?
<doko> quantal
<ogasawara> doko: I don't see it needing an ABI bump yet for quantal, ie it's at -13.  am I missing something?  I do see it needs rebasing to -14 though.
<doko> yeah, maybe rebasing. I see in NBS:
<doko> linux-headers-3.5.0-13
<doko>    	linux-headers-3.5.0-13-lowlatency	universe	amd64 i386
<ogasawara> rtg: ^^ think you could rebase apw's lowlatency kernel and upload to universe today?  I've gotta bail here in a second.
<rtg> ogasawara, can do
<ogasawara> rtg: thanks
 * ogasawara heads downtown
<hggdh> bjf: OK. I will tag it qa-testing-passed, but I still do not like the number of failures
<bjf> hggdh: can you test the previous kernel version?
<hggdh> bjf: I can hack around it, yes, doing it manually
<rtg> bjf, have you upgraded to Quantal on a machine that referenced the X packages in https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport ?
<hggdh> bjf: I will first re-run it to have a full repeat, then I will retest the current -updates kernel
<bjf> rtg, no, all 3 of my test systems are servers and i've not tried that here at home, i could pretty easily though
<rtg> bjf, If you've got a VM that would be handy. it seems some of the packages don't get updated. I'm suspecting some version issues.
<jbicha> hey, bug 1049650 is annoying
<ubot2> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,Incomplete] https://launchpad.net/bugs/1049650
<rtg> sforshee, did your gmux crack do this ? ^^
<sforshee> rtg, I seriously doubt it. It's not even an apple machine.
<rtg> sforshee, its about the only think even vaguely related to video
<sforshee> rtg, apple-gmux shouldn't load unless the right hid appears in the ACPI tables, and it should only be there on apple machines
<rtg> sforshee, right
<jstultz> Curious if anyone in Ubuntu is looking at the pstore infrastructure (using it to capture oops logs, etc)?
<rtg> jstultz, I think cking had some interest in it
<jstultz> rtg:  cool
<cking> well, my UEFI boxes with Quantal do save kernel log messages to the UEFI variable space, so that's a debugging win for me
<cking> not exercised pstore yet though
<jstultz> cking:  cool :)  part of why I ask, is that Anton Vorontsov at linaro has been working on getting some of the android features merged into pstore
<jstultz> cking:  so for instance on arm, it can use persistent-ram (doesn't clear on warm reset) instead of bios provided flash to store dmesg logs..
<jstultz> cking:  also there's been recent work to get ftrace output captured by pstore
<cking> jstultz, that's a nice debugging feature. could have done with that several years ago working on ARM devices.
<jstultz> cking:  but i just wanted to make sure these features were promoted enough so folks who might be able to integrate them know they're there.
<cking> jstultz, when are these changes going to land in mainline?
<jstultz> cking:  3.6
<jstultz> cking:  they should all be there already
<jstultz> (the ftrace bits may still be pending for 3.7..  )
<cking> ok, so Quantal+1 now
<jstultz> cking:  yep... 
<cking> jstultz, are these just ARM only features? the ftrace in pstore sounds like a cool idea, but probably uses up lots of memory
<jstultz> cking:  the hope is that pstore will abstract some of the uefi vs arm differences
<jstultz> cking:  not necessarily..  i think you can size the memory space..  
<jstultz> cking:  it just helps to get exactly what functions were called right before an oops
<cking> jstultz, indeed, that would be a big win 
<jstultz> cking:  the arm only aspect of the persistent-ram part of pstore is really only hardware based..
<jstultz> most x86 hardware clears ram state over warm reset... 
<cking> ok
<jstultz> if an architecture doesn't clear ram, then it should be usable.
<cking> indeed, pity about x86 PCs clearing memory really.
<jstultz> and we can still try to log to ram regardless, but we just won't find anything on reset
<jstultz> (although that could be wasteful.. but atleast provides a way to avoid configuration twiddling)
 * cking adds it to his list of things to examine and test on suitable kit
<jstultz> cking:  anyway, just wanted to raise awareness... thanks for listening! :)
<jstultz> cking:  feel free to ping me or cbou on #linaro-kernel if you have further questions
<cking> jstultz, I appreciate you letting me know, much appreciated :-)
<cking> ack
 * rtg -> lunch
 * henrix -> EOD
<rtg> arges, flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid
<rtg> _msr tbm topoext perfctr_core arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1
<arges> rtg, yup it has avx and fma4
<arges> rtg, https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/956051
<ubot2> Launchpad bug 956051 in eglibc "libc6 crash while running 'xm'" [High,Confirmed]
 * rtg -> EOD
#ubuntu-kernel 2012-09-13
<cr3> hi folks, is there a way to determine whether a system supports vpro technology because I'm particularly interested in AMT support? for example, might there be something in /proc/cpuinfo that I could check?
<stgraber> cr3: it's unlikely to be exported as a CPU flag but it might show up in the dmi (look at dmidecode). From a quick test here on two machines that have AMT support, I'm not seeing anything obvious, though I don't think I have it turned on on any of these so that might explain it
<cr3> stgraber: ah, I was hoping it would show up even when it was turned off. I'm mostly curious about AMT potential to spare me from having to look in all the BIOS menus
<queency> hello all i'm using ubuntu9/04 can someone direct me to install power save to my machine
<MCR1> bryceh, RAOF, shadeslayer: Hi :) Just FYI: I've now tested 3.6-RC5 (~kernel-ppa/mainline) and SSL uploading (at least to launchpad) is still broken (did not get it to work on any of the 3.6RCs, while it works on the same system with all 3.5 versions)...
<RAOF> MCR1: SSL uploading to launchpad is broken by the kernel?
<MCR1> RAOF: Yes, I am pretty sure about it.
<RAOF> That's going to be an *awesome* bug once it's found.
<MCR1> Once I downgrade to 3.5 there are no problems anymore
<MCR1> If I push a new branch in 3.6 for example the branch gets created on launchpad, but no data is ever pushed (empty branch) and I have to bzr break-lock it.
<MCR1> The dialogue for entering the SSL password does not appear also...
<caribou> quick noobie question : what needs to be added to a kernel module source code to avoid the "tainted kernel" mention ?
<caribou> i.e. I'm writing a 10 lines module and I want to avoid tainting the kernel with it
<amitk> caribou: what is your module's license?
<caribou> amitk: I'd say GPLv2, it's just for testing
<cking> MODULE_LICENSE("GPL"); is requirec
<cking> or MODULE_LICENSE("GPL v2");
<amitk> right
<caribou> cking: amitk: thanks
<caribou> cking: just trying to hack my own slab corrupting module ;)
<amitk> caribou: so you _are_ trying to taint the kernel, only in a different way ;)
<caribou> amitk: I'm chasing a nasty slab corruption bug, I'm trying to build a systemtap probe that will trigger when slub_debug gets enabled
<caribou> amitk: but you're right :)
<caribou> amitk: cking thanks
<dileks> initramfs-tools-0.99ubuntu13.1+dileks1.debdiff: http://paste.ubuntu.com/1202471/
<dileks> hmm, shall I add debian-bugnos
<dileks> looks good <http://nopaste.snit.ch/165713>
<dileks> http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=commitdiff;h=71ece1498644e162e2d7271098e97d52d18ce3e2
<dileks> http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=commitdiff;h=1d6b272f9ce08d8f6f5eee56f5382f25a8a3a5ef
<sforshee> rtg, I dunno, that's really weird
<rtg> sforshee, I was just reading your comments. perhaps it is binutils
<rtg> sforshee, I'm updating my local chroot to see if I can repro
<sforshee> rtg, I did build the same source in a precise chroot and saw that there was some space between video_cards and video_cards_end
<sforshee> rtg, but it's absolutely bizarre that you bisected to that commit
<rtg> sforshee, I was getting a different symptom, e.g., black screen. I did see the unknown video mode thing at least once.
<rtg> sforshee, where do you find setup.elf ?
<sforshee> rtg, after doing build generic it's in debian/build/arch/x86/boot
<sforshee> *build-generic
<rtg> sforshee, ack
<cking_> bother, just bricked a laptop
<rtg> cking, I managed to wreck mine twice yesterday, but no bricking was involved (at least at the BIOS level)
<cking> this one just hung, reboot, no life whatsoever
<rtg> cking, pull the batter and reset the EC ?
<rtg> battery*
<cking> now on boot there is no splash and the fan spins madly and that's it.  Can't pull the battery, it's a ultrabook, need to open it up
 * cking rummages around for some suitable tools
<hallyn> stgraber: have you heard any updates in teh last two days about the netns bug?
<cking> bah, intel primier support, punch me now and get the pain over and done with
<stgraber> hallyn: nope. Last thing I heard was that 3.6 "might" have a fix for it but cooloney still had to figure out which
<hallyn> ah, thx, that's the nick i was looking for :)
<rtg> rtg@salmon:~/ubuntu/ubuntu-quantal$ readelf -s ./debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card
<rtg>    138: 00003658     0 NOTYPE  GLOBAL DEFAULT   12 video_cards
<rtg>    151: 00003658     0 NOTYPE  GLOBAL DEFAULT   12 video_cards_end
<hallyn> stgraber: i noticed it wasn't on the kernel hotlist...  but i guess that's automatically defined
<rtg> sforshee, ^^ this is with current toolchain building Ubuntu-3.5.0-13.14
<rtg> sforshee, gonna build with precise just to be sure
<sforshee> rtg, that looks about like what I got. As long as I'm understanding the code and linker scripts correctly that means the video_cards array is empty.
<rtg> sforshee, that certainly would appear to be the case. I'll know for sure after compiling against precise ()which will be done in a few minutes)
<sforshee> rtg, The array being empty is the only thing that makes sense to me anyway. We should end up with a minimum of 1 usable resolution if video_vga is included in video_cards[].
<rtg> sforshee, with Precise tool chain:
<rtg> rtg@salmon:~/ubuntu/ubuntu-quantal$ readelf -s ./debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card
<rtg>    160: 000042ec     0 NOTYPE  GLOBAL DEFAULT   12 video_cards
<rtg>    173: 00004340     0 NOTYPE  GLOBAL DEFAULT   12 video_cards_end
<sforshee> rtg, yep, now there's something there
<rtg> sforshee, so next lemme back out the recent binutils update in my quantal chroot
<bjf> jjohansen: bug 1050430 - i'm just now getting back to this
<ubot2`> Launchpad bug 1050430 in apparmor "QRT regression test failure on quantal" [Undecided,New] https://launchpad.net/bugs/1050430
<rtg> doko, bug #1049650 might be a tool chain issue. how can I build gcc-4.7 4.7.1-7ubuntu1 from source ? Is there a bzr branch that I can pull from ?
<ubot2`> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,In progress] https://launchpad.net/bugs/1049650
<doko> rtg, likely. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687448 popped up as well. can you reproduce this? I'll provide you with (some) toolchain builds
<ubot2`> Debian bug 687448 in gcc-4.7 "Kernel compiled with 4.7.1-8 fails to boot" [Normal,Open]
<rtg> doko, I can tell just from the build whether the kernel will work. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1049650/comments/6
<ubot2`> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,In progress]
<doko> rtg, could you check with https://launchpad.net/ubuntu/quantal/+source/binutils/2.22.90.20120816-2ubuntu1 ?
<rtg> doko, gimme a bit
<rtg> doko, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1049650/comments/8 for build results. Its definitely different.
<ubot2`> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,In progress]
<rtg> and likely better.
<rtg> doko, a kernel built with that binutils actually boots.
<jjohansen> bjf: thanks
<bjf> jjohansen: if you need more, just ask. apport-collect not working on that system. it's a lab system and i can just let you have at it if you like
<jjohansen> bjf: okay, I'll get back to you on that
<orated> Hello! Where can I find information related to sound and webcam? Like how one can interface GPIO from /sys. Is there a similar way to fetch data and interact for
<orated> webcams and sound card.
<jsalisbury> rtg, Are you familiar with what firmware should be included on the mini.iso?  There is a bug talking about missing wireless firmware: bug 1047092
<ubot2> Launchpad bug 1047092 in linux "Mini.iso doesn't load wireless drivers" [Medium,Confirmed] https://launchpad.net/bugs/1047092
<rtg> jsalisbury, this seems to be more of an installer issue if /lib/firmware is missing
<jsalisbury> rtg, ok that makes sense.
<rtg> arges, you around ?
<arges> rtg, yes
<rtg> arges, working on the eglibs stuff. do you have to install it after installing the xen hypervisor ?
<rtg> eglibc*
<arges> rtg, you should be able to reproduce with just xen according to the bug
<rtg> bug #956051
<ubot2> Launchpad bug 956051 in eglibc "libc6 crash while running 'xm'" [High,Fix committed] https://launchpad.net/bugs/956051
<rtg> arges, oh, it reproduces just fine
<arges> rtg, ok good
<rtg> xm[1324] trap invalid opcode ip:7f5273faa5fc sp:7fff1bea09d0 error:0 in libm-2.15.so[7f5273f68000+f9000]
<arges> rtg, then we can try the test package ... let me get the link
<arges> rtg, https://launchpad.net/~christopherarges/+archive/ppa-test/+sourcepub/2629659/+listing-archive-extra
<rtg> arges, shall I just add that PPA an then update ?
<arges> rtg, umm
<arges> rtg, just realized there are a ton of debs
<rtg> yeah, which uis why its easier to just update
<arges> rtg,i have a bunch of stuff in this test ppa... let me clean it up
<rtg> arges, quota is the only other Precise package
<arges> rtg, the problem is we need to test the lucid package... so not sure if PPAs will let you add and install the other version
<rtg> ah, lucid
<rtg> arges, I have a lucid chroot installed. couldn't get the lucid kernel to boot, so installed precise instead
<arges> rtg, we could try installing this version over the precise eglibc... (although that might be pretty risky)
<rtg> arges, yeah, lemme try the chroot first
<arges> rtg, cool. you should be able to add the PPA that way since eglibc and libhugetlbfs are hte only packages there. so should be safe enough
<rtg> arges, OK, lemme make sure I can repro the problem under the lucid chroot. it requires xen-utils-common
<rtg> arges, hmm. xen-utils-common did not appear until oneiric. how can you repro this issue under lucid ?
<arges> rtg, btw here is the other related bug
<arges> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/979003
<ubot2> Launchpad bug 979003 in eglibc "libc incorrectly detects AVX support" [High,Confirmed]
<arges> rtg, looking for another way to reproduce
<arges> rtg, ok getting more info one second
<rtg> arges, ack
<vanhoof> rtg: natty EOL's real soon now, right?
<bjf> vanhoof: yes, i'm loading the gun as we speak
<vanhoof> bjf: fire in the hole!
<bjf> vanhoof: the *last* kernel is in the pipe right now
<vanhoof> bjf: cool, just saw a bug come across re: natty and I was pretty sure we're really close to EOL :)
<bjf> vanhoof: the door is closed and locked
<vanhoof> bjf: you set a chair behind the door too, yeah? :)
<bjf> vanhoof: yup and booby trapped
<vanhoof> bjf: lol
<cking>  I wil miss natty. not
<cking> bjf, what will the stable team do with all that extra time now natty is not being maintained? ;-)
<bjf> cking: quantal
<cking> nngggg
<bjf> cking: when one drops another is picked up
<cking> its like burying one's  grandma and getting a baby in one go
<bjf> cking, the king is dead, long live the king (or queen)
<orated> Hello! Where can I find information related to sound and webcam? Like how one can interface GPIO from /sys. Is there a similar way to fetch data and interact with sound card/webcam?
 * cking -> EOD (literally)
<alexbligh1> Is there a /maintained/ backport of the Precise kernel to Lucid? (a la lts-backports)
<vanhoof> alexbligh1: dont believe so, no
<alexbligh1> vanhoof, ok, that's a pity. Are the lts-backports kernels simply the Oneiric (or whatever) sources within a Lucid build environment? IE if I set up something to sync the sources automatically and publish a repo, would that be it? Or is it more complex than that?
<alexbligh1> (OTOH may be I should just take all the excuses I can find to u/g everything to Precise)
<vanhoof> alexbligh1: I'm not entirely sure if that's how they're formally built but I have done similar with success in the past
<alexbligh1> vanhoof, ok, thanks, useful.
#ubuntu-kernel 2012-09-14
<infinity> Is there a plan for a new kernel upload built against the latest binutils?
<infinity> ogasawara: ^?
<ogasawara> infinity: indeed we should, I'll prep an upload right now.
<infinity> ogasawara: Thanks.  I was going to do a d-i upload, and then realised that would end up baking in the broken kernel, so figured I'd hold off. :P
<ogasawara> infinity: I've got it ready to upload, I just want my quick test build to finish since it's got a single patch in it.  eta 10min.
<infinity> ogasawara: Check.  Does that single patch cause an ABI bump too?
<infinity> ogasawara: (Not that I mind if it does, just curious)
<ogasawara> infinity: nope, it shouldn't
<infinity> Kay, if it's not an ABI bump, care to skip the -proposed thing, and just upload straight to release?
<infinity> Doesn't really buy us anything to artificially delay the fix if there won't be package skew or anything.
<ogasawara> infinity: I can
<infinity> Danke.
<infinity> Of all the Leanns I know, you are definitely somewhere in the top ten.
<infinity> *nod*
<ogasawara> infinity: I demand to be #1!  screw the top 10.
<infinity> There are so many inappropriate ways to read the second half of that.
<infinity> Well, only one way, really.
<infinity> But it's inappropriate, regardless.
<ogasawara> infinity: ok, uploaded.
<infinity> \o/
<ogasawara> infinity: I'll try and keep an eye on it, but I'll be drinkin with the other managers too, so not sure how reliable I'll be
<infinity> ogasawara: Meh, s'all good.  I'll poke it from time to time, and re-upload d-i laterish, or in the morning.
<infinity> ogasawara: It can't actually be much more broken on x86 than it currently is, so not much to keep an eye on. :P
<ogasawara> infinity: ack
<infinity> ogasawara: Don't you enjoy that warm fuzzy feeling you get when the kernel has regressed so hard that you could upload emacs, call it linux, and it would still work just as well?
<infinity> ogasawara: In other words, go drink.  And give my manager a hard time.
<ogasawara> infinity: heh, will do :)
 * henrix -> lunch
<doko> rtg, I'm having difficulties to reproduce #1049650. even with the binutils that you did check with, I always see the same offset
<doko> rtg, I'm having difficulties to reproduce #1049650. even with the binutils that you did check with, I always see the same offset
<rtg> doko, the binutils you uploaded yesterday still has the problem.
<doko> rtg, yes, however even using the 2.22.90.20120816-2ubuntu1 one, which you do report success with, apparently has the problem. see the comment in the report
<rtg> doko, getting there ....
<doko> rtg: was the chroot you did use for testing up to date?
<rtg> doko, well, that is odd.
<rtg> doko, pretty much. lemme try again
<doko> I was trying to provide some object files for the issue, but can't seem to build the correct ones
<rtg> doko, up to date chroot:
<rtg> rtg@salmon:~/ubuntu/ubuntu-quantal$ readelf -s ./debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card
<rtg>    147: 00002f3c     0 NOTYPE  GLOBAL DEFAULT  ABS video_cards
<rtg>    148: 00003650     0 NOTYPE  GLOBAL DEFAULT  ABS video_cards_end
<doko> rtg, with the old binutils?
<rtg> (quantal-amd64)rtg@salmon:~/ubuntu/ubuntu-quantal$ dpkg -l|grep binutils
<rtg> ii  binutils                             2.22.90.20120913-1ubuntu1 
<rtg> doko, makes me wonder if the kernel ogasawara uploaded last night built correctly. guess I can check that out quick enough.
<doko> rtg: yes, the amd64 build log shows the correct version
<rtg> doko, correct, but did the kernel get linked correctly ? will it boot, etc.
<rtg> doko, ogasawara: downloaded new kernel. seems to work.
<rtg> lemme build on gomeisa again. its got a virgin chroot.
<doko> I'm currently building on osageorange
<doko> $ readelf -s debian/build/build-generic/arch/x86/boot/setup.elf | grep video_cards
<doko>    138: 00003660     0 NOTYPE  GLOBAL DEFAULT   12 video_cards
<doko>    151: 00003660     0 NOTYPE  GLOBAL DEFAULT   12 video_cards_end
<doko> this is what I get on osageorange
<doko> rtg: ^^^
<rtg> doko, I don't think thats gonna work too well
<doko> rtg: which gcc-4.7 package did you use for the build on salmon?
<rtg> doko, what is salmon? a buildd ? looks like the amd64 kernel built on allspice last night.
<doko> <rtg> (quantal-amd64)rtg@salmon:
<rtg> doko, oh, it a local SandyBridge server that I have. duh. forgot.
<rtg> doko (quantal-amd64)rtg@salmon:~/ubuntu/ubuntu-quantal$ dpkg -l|grep gcc
<rtg> ii  gcc                                  4:4.7.0-5ubuntu1                                          amd64        GNU C compiler
<rtg> ii  gcc-4.7                              4.7.1-8ubuntu1                                            amd64        GNU C compiler
<doko> strange
<doko> rtg: I would like to understand why I get different results (osageorange non working), and the buildd (working, as you tested)
<brendand> cking - is the mailing list for you and the other people working on fwts 'fwts-team@lists.launchpad.net'?
<cking> brendand, try fwts-devel instead of fwts-team
<rtg> doko, while the buildd kernel is working, the linker issue may be different on that machine. without being able to look at setup.elf we can't say for sure.
<brendand> cking - is it private?
<cking> nope
<doko> rtg: maybe add a readelf -s to the build?
<rtg> doko, yeah, perhaps. lemme mess with your chnistrap package again first.
<doko> rtg: it's just odd that the buildd kernel works, while I still see the issue on osageorange
<rtg> doko, we don't _know_ that the buildd kernel linked correctly. that fact that it works on my laptop is inconclusive.
<doko> ahh, so how can we tell? 
<rtg> doko, lemme do a local sbuild with some debug. that shold be about as clkose to the buildds as I can get.
<doko> rtg: after you did that, could you (with the same binutils version) rebuild with cpp-4.7 and gcc-4.7 4.7.1-7ubuntu1? I'm starting to think it's not a binutils issue after all
<dantti> hi, is there someone I could poke to get this changed before Quantal? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1003090
<ubot2> Launchpad bug 1003090 in linux "Please enable HID_BATTERY_STRENGTH (on xorg-edgers and quantal kernel packages)" [Medium,Triaged]
<doko> $ readelf -s debian/build/build-generic/arch/x86/boot/setup.elf|grep video_cards
<doko>    160: 000041a4     0 NOTYPE  GLOBAL DEFAULT   12 video_cards
<doko>    173: 000041f8     0 NOTYPE  GLOBAL DEFAULT   12 video_cards_end
<rtg> doko, so that looks right. different gcc-4.7 ?
<doko> rtg: -7ubuntu1
<rtg> doko, so you're thinking -8ubuntu1 might be broken ?
<doko> rtg: yes, and not binutils. maybe you did test with the old compiler yesterday?
<rtg> doko: dunno,
<rtg> doko, so, the archive reaper has already cleaned out -7ubuntu1. Do you have those packages stashed somewhere ?
<doko> rtg: you can get the older ones by the publishing history
<rtg> doko, ah, thats good to know
<rtg> doko, egads, there are a lot of .deb files there. Is there a handy way to install the ones I need ?
<hallyn> stgraber: looking at the "Release Meeting 2012-09-14" email, I don't see the netns bug in the "Summary of bugs working on by team".  Do you have the bug# handy?
<doko> rtg: you only need cpp-4.7 and gcc-4.7. install using dpkg --force-depends
<rtg> doko, ok, gimme a bit.
<doko> <jakub> doko: from quick look at the kernel, I'd say the kernel is buggy
<stgraber> hallyn: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1021471
<ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Triaged]
<doko> <jakub> doko: I'd say used attribute is a must in the #define __videocard struct card_info __attribute__((section(".videocards")))
<doko> <jakub> doko: because when it declares static __videocard var = { ... }; then the compiler has all rights to just nuke those as unused
<doko> rtg: ^^^
<hallyn> stgraber: thanks
<hallyn> ogasawara: ^ bug 1021471 wasn't on the list of quantal bugs the kernel team is looking at?
<ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Triaged] https://launchpad.net/bugs/1021471
<ogasawara> hallyn: that should have been on the list, I seemed to have missed getting it on there
<ogasawara> hallyn: and it should be getting worked by cooloney
<hallyn> ogasawara: phew :)  thanks
<rtg> doko, ack
<rtg> doko, this seems to be somewhat random. I just built with binutils 2.22.90.20120913-1ubuntu1, cpp-4.7  4.7.1-8ubuntu1, and gcc-4.7 4.7.1-8ubuntu1.
<rtg> readelf -s /home/rtg/ukb/quantal/amd64/master-next/ubuntu-quantal/debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card
<rtg>    147: 00002f3b     0 NOTYPE  GLOBAL DEFAULT  ABS video_cards
<rtg>    148: 00003650     0 NOTYPE  GLOBAL DEFAULT  ABS video_cards_end
<rtg> lemme try an sbuild
<doko> strange
<doko> rtg: and wondering why the Ndx column sometimes has ABS, sometimes 12
<ppisati> seems like i'm finally back...
<cking> welcome back ppisati
<ppisati> :)
<doko> rtg: adding the used attributes on osageorange:
<doko> $ readelf -s debian/build/build-generic/arch/x86/boot/setup.elf | grep video_cards
<doko>    159: 000041a8     0 NOTYPE  GLOBAL DEFAULT   12 video_cards
<doko>    172: 000041fc     0 NOTYPE  GLOBAL DEFAULT   12 video_cards_end
<rtg> doko, I'm wondering why video_cards is treated special in the kernel ? how are you applying the used attribute ?
<doko> --- arch/x86/boot/video.h.orig  2012-09-14 14:06:49.005979707 +0000
<doko> +++ arch/x86/boot/video.h       2012-09-14 13:43:47.116013331 +0000
<doko> @@ -80,7 +80,7 @@
<doko>         u16 xmode_n;            /* Size of unprobed mode range */
<doko>  };
<doko>  
<doko> -#define __videocard struct card_info __attribute__((section(".videocards")))
<doko> +#define __videocard struct card_info __attribute__((used, section(".videocards")))
<doko>  extern struct card_info video_cards[], video_cards_end[];
<doko>  
<doko>  int mode_defined(u16 mode);    /* video.c */
<sforshee> doko, your readelf output still doesn't really look right, that array should be bigger
<rtg> it should be 3650-2f3b
<doko> sforshee, maybe, however I'm trying to reproduce the values which rtg does get. currently I can't
<jsalisbury> rtg, cjwatson took a look at bug 1047092 and re-assigned to linux-firmware.  Looks like a packaging fix is needed?  Anyone specific you think I should ping about this?
<ubot2> Launchpad bug 1047092 in linux-firmware "Mini.iso doesn't load wireless drivers" [Medium,Triaged] https://launchpad.net/bugs/1047092
 * ppisati is shuffling cables around...
<rtg> doko, ogasawara: my sbuild produced an empty video_cards section, which is also likely what happened on the buildd
<ogasawara> jsalisbury: I'm prepping a patch for that bug right now
<jsalisbury> ogasawara, cool, thanks
<ogasawara> jsalisbury: rather I have the patch, just kicking off a test build to confirm the fw shows up in the udeb
<jsalisbury> ogasawara, ok
<ogasawara> jsalisbury: I've told cjwatson on ubuntu-devel I'll upload shortly
<jsalisbury> ogasawara, ahh, I see that now :-)
<rtg> ogasawara, you're also adding zd1201 as well ?
<ogasawara> rtg: I did
<ogasawara> rtg: added zd1201.fw and zd1211/*
<doko> <rtg> readelf -s /home/rtg/ukb/quantal/amd64/master-next/ubuntu-quantal/debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card
<doko> <rtg>    147: 00002f3b     0 NOTYPE  GLOBAL DEFAULT  ABS video_cards
<doko> <rtg>    148: 00003650     0 NOTYPE  GLOBAL DEFAULT  ABS video_cards_end
<rtg> doko, that looks right. is that with the 'used' attribute ?
<doko> rtg: could you tar up the boot dir for this build and put it somewhere? it also would be good to get the preprocessed source files for this dir
<rtg> oh, nm. I pasted that.
<doko> right
<rtg> doko, what is the boot dir for a build ?
<rtg> doko, do you mean the full build directory ?
<doko> rtg: debian/build/build-generic/arch/x86/boot/  *.o and setup.elf
<sforshee> doko, actually looking closer I think your output looks correct and rtg's is too big. There should be 3 card_info structs linked in the section, and they aren't all that big.
<rtg> sforshee, hmm, I never thought to check the size. if what you're saying is true, then what fills the 715H in my case ?
<sforshee> rtg, no idea
<sforshee> rtg, doko's section is 84 bytes, or 28 bytes per struct, which is about right if pointers and ints are 32 bits
<rtg> sforshee, this is amd64
<sforshee> rtg, right, that's the only part that doesn't make sense
<sforshee> rtg, but that still wouldn't account for that much of a difference
<doko> rtg: this code is built with -m32
<sforshee> rtg, and I get the same results in an amd64 chroot
<rtg> doko, hmm, so we add 'used' to the attribute definition and call it good ?
<doko> for the kernel, maybe. however I would like to followup upstream. currently I can't get the .o file built by hand. maybe I'm missing something
<sforshee> rtg, I think it makes sense to add __used to the definition of __videocard. Otherwise the variable does look unused within the file.
<doko> sforshee, rtg: if I look at the verbose build log, then this vesa-mode.o is built with -o arch/x86/boot/.tmp_video-vesa.o however I can nowhere see where it's moved to the final name/place
<doko> and: $ gcc -m32 -c -Os -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -ffreestanding -fno-toplevel-reorder -fno-stack-protector video-vesa.i
<doko> $ nm video-vesa.o         U boot_params
<doko> 00000000 T vesa_store_edid
<doko> 00000000 b vginfo
<doko> what am I missing?
<rtg> doko, chinstrap.canonical.com:~rtg/boot.tgz
<sforshee> doko, scripts/Makefile.build does the move to the final name
<sforshee> doko, see cmd_modversions
<doko> sforshee, what I'm looking for is a video-vesa.i, and the command to build the video-vesa.o
<doko> sforshee, hmm, even in verbose mode, parts of rule_cc_o_c are hidden :-/
<sforshee> doko, yep
<doko> sforshee, could you help with this?
<sforshee> doko, sure, what do you need?
<doko> a video-vesa.i, and the command to build the video-vesa.o
<doko> because I get something different with the commands I did paste
<arges> cking, hey
<cking> arges, hiya
<doko> sforshee, hmm, I'm missing the ld -r call maybe
<doko> rtg, I'm surprised that it works with your tarball, because:
<doko> $ nm video-vesa.o 
<doko>          U boot_params
<doko> 00000000 T vesa_store_edid
<doko> 00000000 b vginfo
<rtg> sforshee, doko: I'm inclined to upload with this 'used' attribute patch so we can get a working kernel in the archive.
<doko> rtg, I can't say that adding the attribute would be wrong
<sforshee> rtg, I think we send it upstream as well, because to me it just looks correct
<rtg> sforshee, doko: agreed
<doko> after the kernel is built, I'd like to revert the binutils change, after testing that I get the same result with the used attribute
<sforshee> doko, are you actually seeing the command to build video-vesa.i in your verbose build?
<doko> sforshee, yes, I saved that and added -save-temps
<sforshee> doko, I'm not seeing it. I thought it was just a debugging feature anyway.
<doko> sforshee, so we now have three section sizes. 0 without the used attribute, 84 with the attribute, and rtg's even bigger one. however the bigger one is only seen by rtg, correct?
<sforshee> doko, I've never seen the bigger one
<rtg> doko, as far as I know that is correct.
<doko> sforshee, I set KBUILD_VERBOSE=1 in the env
<sforshee> doko, I have that too, just not seeing any .i files generated when I run build-generic
<doko> sforshee, you have to explicitly add -save-temps
<sforshee> doko, ack
<rtg> hmm, grub 2.0 sure looks different.
<doko> rtg, am I needed for the grub issue too? ;)
<rtg> doko, no, I was just noticing menu differences.
<sforshee> doko, in my experimentation .tmp_video-vesa.o doesn't have the __ksymtab section, so I think it just gets renamed to video-vesa.o
<doko> ahh, ok
<doko> sforshee, rtg: was -fno-toplevel-reorder recently added to build this file?
<rtg> doko,  no change to scripts/Makefile.build since Jan 24
<doko> because with gcc-4.6 -fno-toplevel-reorder, the symbol is emitted, but not with gcc-4.7. but I don't see a behaviour change on the branch
<sforshee> doko, that option has been in arch/x86/boot/Makefile since at least 3.3
<sforshee> doko, is what you're looking for how you can generate video-vesa.i? Because I'm not getting one even with -save-temps.
<doko> sforshee, well, let's stop with it for now.
<sforshee> doko, okay
<rtg> doko, ogasawara, sforshee: Uploading linux_3.5.0-14.18_source.changes: done.
<ogasawara> rtg: ack
<doko> ahh, and at least 4.7.0 -fno-toplevel-reorder had this symbol emitted too. so this did change on the branch
<rtg> doko, so that option was removed in 4.7.1 ? The description says, "When this option is used, unreferenced static variables are not removed."
<doko> rtg: no, actually this might be the root cause.
<doko> and it works in gcc-snapshot. so I'll have to look when this did change. I see the same behaviour in Debian, so it's not caused by any Linaro change
<kirkland> cking: hey!  is there an easy way to tell if my i7 has the rdrand instruction?
<kirkland> cking: anything in /proc/cpuinfo or the like?
<kirkland> cking: I'm guessing "not", as I tried to run your rdrand test, and I got :-)  Illegal instruction (core dumped)
<kirkland> cking: http://smackerelofopinion.blogspot.com/2012/08/simple-performance-test-of-rdrand.html fwiw
<cking> kirkland, see http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide - rdrand_check_support()
<cking> kirkland, or grep "rdrand" in /proc/cpuinfi ;-)
<cking> * /proc/cpuinfo
<cking> kirkland, I've updated the code to test rdrand CPU features.
<cking> oops, nope, failed
 * ppisati -> gym workout
<cking> kirkland, fixed now
<rtg> doko, when you have figured out root cause, please add your explanation to bug #1049650 for _why_ 'used' is a required attribute so that when I punt this patch upstream I can point to something factual.
<ubot2> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,Fix released] https://launchpad.net/bugs/1049650
<kirkland> cking: neat, thanks
<dileks> checking for video_cards... so this is good? http://nopaste.snit.ch/166160
 * cking spots a jump in page hits on the blog
 * rtg -> lunch
<dileks> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1049650/comments/4
<ubot2> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,Fix released]
<dileks> ok, than precise gcc-4.6 is not affected
 * cking --> EOD
 * henrix -> EOD
<infinity> rtg: You seem to have left some debug code in your kernel upload that broke !x86.
<rtg> infinity, damn, I didn't think about that.
<infinity> +$(build_cd) readelf -s `find . -name setup.elf` | grep video_card
<infinity> At the very least, I didn't check the rest of the diff.
<infinity> But it chokes there, for obvious reasons.
<rtg> infinity, I left there on purpose so we could see the section sizes, but they won't exists for !x6
<rtg> infinity, ok, I'll fix and re-upload
<infinity> Danke.
 * ogasawara lunch
<rtg> infinity, ogasawara: Uploading linux_3.5.0-14.19.dsc: done. (sigh)
<ogasawara> rtg: ack
<rtg> ogasawara, I'm not gonna bother with the LTS upload until there is a substantive change
<infinity> rtg: Thanks.
<ogasawara> rtg: yah, sounds good
 * rtg drifts away for the weekend...
<geofft> Is there a recommended way to recompile a single kernel module with different Kconfig options?
<geofft> preferably without recompiling the entire kernel?
<geofft> I'm trying to make sense of debian/rules.d but not having much luck :)
<geofft> Looks like you can play some dirty tricks that start with `fakeroot debian/rules config-prepare-check-generic`
<geofft> I'd be happier if I somehow got a .deb out of this process, but I do have the .ko I want.
#ubuntu-kernel 2012-09-15
<lamont> silly question....
<lamont> on a server install w/o network-manager (let's say lucid or precise), what causes interfaces to be configured automagically when link shows up?
#ubuntu-kernel 2012-09-16
<siretart> small question, do the kernels from ppa:ubuntu-x-swat/q-lts-backport have aufs enabled or not? I see it enabled in config-3.5.0-14-generic: CONFIG_AUFS_FS=m - however, I fail to find the aufs.ko in any .deb package.
<orated> Hello! How do I fetch the update as mentioned here -https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1019321/comments/31 - to fix sound issue?
<ubot2> Launchpad bug 1019321 in linux "USB sound card not detected on beagleboard xM" [Medium,Fix released]
<hggdh> for the linux 3.0.0-26.42 kernel, shouldn't there be a linux-headers-3.0.0-26 package? I see a depends from linux-headers-(virtual|generic|server) to it, but I cannot find this package
<infinity> hggdh: Looks there to me
<infinity> (base)adconrad@cthulhu:~$ rmadison linux-headers-3.0.0-26
<infinity> linux-headers-3.0.0-26 | 3.0.0-26.42 | oneiric-security | all
<infinity> linux-headers-3.0.0-26 | 3.0.0-26.42 | oneiric-updates | all
<hggdh> infinity: sorry, I am looking for the LTS HWE packages.
<hggdh> infinity: this is what apt-cache shows me: http://pastebin.ubuntu.com/1209869/
<hggdh> (output from a Lucid system, with -proposed enabled
<hggdh> and my fault for not stating it was on the LTS HWE
<hggdh> or, a more self-explanatory output: http://pastebin.ubuntu.com/1209879/
<infinity> hggdh: Oh special.  I think launchpad kinda oopsed it out of existence.
<infinity> I wonder how many other files from that upload went the same way...
<infinity> hggdh: Remind me tomorrow and I'll see if there's a way we can resurrect that, but I fear we might need a no-change rebuild (or we can just skip this SRU cycle for lts-backport-oneiric and pick it up next time).
<infinity> hggdh: For now, I suspect you'll want to fail the testing on it, so I know not to promote it later. :P
<hggdh> infinity: roger, and ack
#ubuntu-kernel 2013-09-09
<ppisati> moin
<smb> morning
 * ppisati goes for the big monday upgrade...
<ppisati> 218 pkgs, cross your limbs
<smb> what could possibly go wr#!Â§$
<ppisati> ok, i lied
<ppisati> i did a dist-upgrade
<ppisati> and it's now removing all the unity-scope*
<ppisati> besides, i never used them so...
<ppisati> :)
<smb> we don't need them :)
<smb> ppisati, Only got 152 to upgrade and none to remove. Must already have them removed and I did not miss them. :-P
<ppisati> you lucky :)
 * ppisati -> reboot
<ppisati> sees to work
<ppisati> seems
<smb> Keyboard is flakey
<smb> :)
<ppisati> :)
<ppisati> no, that's me :)
<smb> infinity, Could you please press the accept button for Xen 4.2.2 in Raring?
<smb> ppisati, We cannot be faulty. It must be the computer. ;)
 * ppisati should try to ditch pidgin and go back to... $whatever we ship
<apw> ppisati, for me my at-tab and dash invokations now take 20-40s to occur
<apw> morning all
<apw> alt-tab
<ppisati> uhm no, alt-tab is still fast
<ppisati> andi admit i never use the dash
<smb> apw, morning. always or only first
<apw> oh i never use dash _intentionally_ but when i do now it freezes my desktop for 30s
<apw> oh every time, always
<ppisati> nope
<smb> Hm, ok. I only see a very long time the first time I bring it up
<ppisati> still fast
<ppisati> even the dash
<apw> smb, i am very glad i did not upgrade my desktop to daily-quality
<smb> apw, Yeah, me too.
<apw> my main non-fixed workhorse agent57 is now in the scrap pile thanks to it
<apw> i am pretty sure it is not kernel because that machine is one of the very boxes i test kernels on before upload
<ppisati> "haswell i5 + ati gpu" box is ok
<smb> awesome
<RAOF> apw: Hm, sounds like the intel regression in mesa that I thought was fixed, then fixed again, and then fixed another time?
<apw> and my typing useage style makes this bug immediatly obvious
<apw> RAOF, need some of your bees back ?
<apw> RAOF, how could i confirm ... this is a baby (read old) atom
<RAOF> apw: Nah, that'd bee a tjaalton problem now :)
<apw> heh :)
<RAOF> Oh, you're trying to use a 915?
<apw> heh
<RAOF> :)
<apw> RAOF, so it cannot be ubiquitus can it, i think my other i915 is ok, i think
<RAOF> ??? :(
<smb> apw, So maximegalon seems to come up with latest updates and that is a similarly old atom and i915
<apw> i am upgrading another aom to the same level to see if it is affected too
 * apw parays this is not one of those "it could never have worked" bugs, the ones which only exhibit for me
<apw> also ... i have "blacker" cursors today, is that normal
<smb> apw, mine is Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03)
<RAOF> apw: Not normal, but you're not alone.
<apw> mine is a D4xx/D5xx/N4xx/N5xx integrated ..
<apw> RAOF, yeah i have inverted cursors
<smb> apw, Hm... mine is not blinking and solid right now but seems bright enough
<tjaalton> apw: huh, so dash is slow for you?
<smb> apw, tjaalton Oh great, mine is not slow ... it does not appear at all
<smb> now the whole dash turned grey
<smb> apw, Something likely unrelated but maybe we should have a look: "perf samples too long (5012 > 5000), lowering kernel.perf_event_max_sample_rate to 25000"
<smb> Those I think I remember appearing more often recently
<apw> smb, yeah the slower machines seem to say things about that, i assume it is benigh
<apw> but knowing would be good
<apw> tjaalton, on that machine, yeah like hit alt, have nothing moving or changing but the cursor for like 40s
<apw> then it appears half filled, then wait a bit more
<tjaalton> nice
<apw> 35d by naieve counting == seconds
<smb> apw, Ok, yeah, seems I have exactly the same
<apw> the launcher scrolls on just fine if i use meta+N to get to windows
<apw> smb, how is alt-tab
<smb> There is now a shadow dash
<smb> Have not tried yet as it was so slow to even get the first thing up
<apw> yeah it is half there i think, like that is the start of it fading in
<tjaalton> looks like it's filed as #1222602 
<apw> bug #1222602
<ubot2`> Launchpad bug 1222602 in mesa (Ubuntu) "Bad performance on GMA950" [Undecided,New] https://launchpad.net/bugs/1222602
<apw> tjaalton, to downgrade mesa, do you have a list of packages i would need to actually downgrade
<apw> (so i can confirm this)
<tjaalton> libgl1-mesa-dri -glx
<apw> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1222351
<ubot2`> Launchpad bug 1222351 in unity (Ubuntu) "alt-tab and alt tap hang unity for 20s or so before operating" [High,Triaged]
<apw> was the bug i filed, which if this reproduces i will reassign and dup appropraitly
<apw> tjaalton, thanks will test noe
<tjaalton> yeah 9.1.x was confirmed on the other bug to be fine
<apw> ok about to test will let you know
<apw> tjaalton, ok ... confirmed, mesa downgrade fixes behaviour
<apw> will update the bugs
<tjaalton> thx
<apw> if there is anything one can do to help find this ... let us know, it sounds like you have two testers here
<tjaalton> i'm looking at upstream changes since 9.1
 * apw bets they are untested on atom :)  till now
<tjaalton> well, gen3 isn't that uncommon
<tjaalton> "i915: Remove all the HiZ code from i915"
<tjaalton> perhaps
<smb> We probably have two different i915 generations as well
<tjaalton> i915..i945 is gen3
<tjaalton> http://en.wikipedia.org/wiki/Intel_Extreme_Graphics#Third_generation
<tjaalton> throw in these atoms too
<smb> tjaalton, Ah ok, I just thought apw's netbook had something slightly newer than mine
<apw> tjaalton, they are on gen7 inhouse i would think
<apw> so that is 4+ versions older, "what are they"
<tjaalton> apw: probably so
<apw> tjaalton, i am feeling retarded how do i find the exact GMA I have
<tjaalton> apw: lspci probably
<smb> apw, check for the pci id
<apw> 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller
<smb> apw, I would assume something along gma 3150
<apw> that seems rather wishy washy
<smb> apw, -vvvnn
<tjaalton> aka gma3150
<apw> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a011] (prog-if 00 [VGA controller])
<smb> apw, mine is a 0x27ae, so gma950
<tjaalton> pineview
<smb> apw, a011 is 3150
<apw> cool, ok so smb is the same as the OR and i have added my chipset to the title
<apw> smb, could you 'affects me' on it
<smb> apw, Hm, newer but looks like slower, less pipelines...
<smb> apw, think I have
<apw> ok good
<apw> smb, title says 'me and one other' which would be the OR
<smb> apw, mine says me and two other 
<apw> smb, i hate launchpad some days
<smb> But as the title changed to add your gma3150 I thnk we look at the same. :)
<apw> oh i see, when you update one you have, it +1's the number _you_ have
<apw> not the actual number, POC
<apw> tjaalton, i think you and i may have collided updating the title, and i may have bolloxed your update
<smb> apw, Speaking of breakage... my FFE for Xen-4.3 in Saucy got approved over the weekend... :)
 * apw hates LP more
 * apw adds smb to the list
 * smb thought he was already on it in the tops region
<tjaalton> heh, I added [gen3] there now, it should cover it all
<apw> great
 * apw moves smb up the list, rapidly
<smb> At least moving up ranks *somewhere*. Though on the "todo" list would be so much better. :-P
<apw> smb, can you test 'resume' performance on your gen3, i am finding a good 10s of "i am on, but there is nothing to talk to password wise" before i can use that box
<apw> *down* on that one, *down* i say
<smb> apw, I think that moves priority of what I can test as well
<apw> bah, tuche' m'lord
<smb> apw, suspend/resume seems to be ok (only one attempt)
<apw> smb, it works fine, it just seems reallly slow to let me start typing the password
<apw> ie the backlight comes on immediatly but gnome screensaver is not talking to me for ages
<smb> apw, Yes, but no that looks good, too
<smb> It even comes up quickly without needing another keypress
<apw> i guess that means there is something i can fix, perhaps something installed
<smb> Either that or a slight difference between gma950 and 3150
<apw> yeah
<apw> one or t'other
<smb> Wasn't that the machine that more often than the rest seemed to suffer from i915 problems
<apw> yeah this machine was a bit of a lemo
<apw> lemon
<tjaalton> this was actually filed upstream months ago, no reply.. https://bugs.freedesktop.org/show_bug.cgi?id=64202
<ubot2`> Freedesktop bug 64202 in Drivers/DRI/i915 "Enabling opengl 2.1 on intel gen3 breaks the Unity desktop (and possibly others)" [Normal,New]
<tjaalton> there's a workaround too
<Gsport> will linux ever be fixed?
<apw> Gsport, heh
<Gsport> intel grafics suck
 * apw really hopes not, else there is no reason to pay me
<apw> Gsport, heh no i think it sucks as much as any other, just cause it is developed in the clear it is more obvious
<Gsport> i have to respect your opinion i suppose
<Gsport> IMHO intel isnt dead it just deserves to die
<smb> tjaalton, Ok, that environment variable override does work for me, too
<tjaalton> good
<apw> Gsport, i think someone who is willing to engage and share their data is to applauded, even if they are not the most powerful GPU makers
<apw> it isn't like you have to buy their products if you don't like them, vote with your wallet
<apw> tjaalton, ok that bug upstream implies that unity needs to adapt
<tjaalton> could be
 * apw wonders what the recommendation is, pin mesa back or switch the environment
 * apw tries the env for completeness
<ppisati> brb
<apw> tjaalton, confirming the /etc/environment thing here as well
<apw> ppisati, how utterly broken is calxeda
<apw> given this is about the 40th patch we are applying for it
<apw> tjaalton, i don't know if you saw the somewhat off topic comment in the bottom of the mesa bug, it seems the "unity puts the second screen in a place you can no longer render to it" bug is back (if they are accurate)
<apw> henrix, i see that kees fixes for those various CVEs are starting to trickle in via the HID tree
<apw> (and i assume you have the same searcher i do to find them :))
<henrix> apw: yeah, i've already started updating cvetracker with those :)
<apw> henrix, heh i noticed when i went to add them :)
<apw> saved me the effort
<apw> kees, hey ... it seems only half of your input cves arrived in linus' tree, are the others coming via some other route or is there some issue we should know about
<hashken> I want to know if process virtualization is enabled in a particular kernel
<hashken> What flags should I check for in the kernel config file?
<apw> hashken, what sort of virtualisation?
<hashken> I want to know if this particular kernel can support mininet - https://github.com/mininet/mininet
<apw> hashken, do you mean lxc or something else
<hashken> A brief description of mininet from the github page
<hashken> Mininet creates virtual networks using process-based virtualization and network namespaces - features that are available in recent Linux kernels. In Mininet, hosts are emulated as bash processes running in a network namespace, so any code that would normally run on a Linux server (like a web server or client program) should run just fine within a Mininet "Host". The Mininet "Host" will have its own private network interface an
<hashken> Switches in Mininet are software-based switches like Open vSwitch or the OpenFlow reference switch. Links are virtual ethernet pairs, which live in the Linux kernel and connect our emulated switches to emulated hosts (processes).
<hashken> I am not exactly familiar with virtualization and stuff.
<apw> so that sounds like it uses network namespaces and openvswitch, so i would expect that to work on later releases if anywhere
<apw> as we keep pretty much up on the leading edge there for openstack and the like
<smb> It still would not be completely clear what feature is being looked for. Openvswitch in in the kernel and relatively complete in Saucy/3.11 
<smb> To run VMs is also supported in the kernels
<smb> or containers
<apw> yeah i am going on the page which that above snippet came from, which sounds like it is trying to use something lightweight to simulate many hosts, basically a cut down lxc as they are all under ones control and not malicious
<hashken> I am actually seeing if the raspberry pi kernel can support mininet
<hashken> So, I actually need to know the kerenl config flags that are related to virtualization
<hashken> I have been able to find the flag fornetwrok namespaces - CONFIG_NET_NS
<hashken> But, process virtualization is such a general concept, that I have not been able to find the relevant flags.
<hashken> Since you guys have a much better idea about the kernel than me, I am hoping that you will able to point out the appropriate flags to make mininet work.
<apw> hashken, well indeed, there a are a lot, i would look at the init/Kconfig which has all the namespaces which are 'generic' listed, search for NET_NS
<smb> hashken, This sounds like you are looking for a containerization, so probably a mix of cgroup and *_NS options
<apw> and whether openvswitch is in the version you are using, harder to say
<smb> Hm looking at the readme and checkign with Saucy, there is a mininet package in the archive
<smb> I would assume then this works with the stock ubuntu kernels
<smb> https://github.com/mininet/mininet/blob/master/INSTALL
<smb> States the only requirement would be NET_NS
<smb> and openvswitch 
<Kaloz> Hi. I would like to ask for the merge of two bugfixes into the generic kernel for saucy. Who should I bug about them? ;)
<ppisati> apw: ah, i keept thinking the 'disable module check' + abi bump are enough
<smb> Kaloz, If those fixes are upstream in Linus tree and picked up by upstream stable they will be in the Saucy kernel automatically at some point.
<ppisati> *keep
<smb> Kaloz, When unsure you can point out the fixes on kernel-team@lists.ubuntu.com
<Kaloz> smb: yeah, but as one of them breaks booting, if those fixes get late, saucy won't install
<Kaloz> smb: do I have to subscribe there or is it internal?
<apw> ppisati, well that patch didn't disable the module check either
<apw> or if it did it did it against the wrong abi
<smb> Kaloz, Ok, so for that one you should file a bug (if you have not already) with ubuntu-bug linux. The list is public and you don't have to subscribe. Just takes a bit longer then as you have to get trhough moderation
<ppisati> apw: no, it didn't
<apw> Kaloz, so you might email the kernel-team mailing list with the patches and ask for them as well, a bug always helps focus the mind
<Kaloz> smb: there's a bug, but it seems $randomuser can set it to "Fix released" so I'm afraid it will stay below radar or be missed in the noise
<apw> Kaloz, if it isn't fixed change it back
<apw> and ... what is the bug number
<smb> Kaloz, Right, and I would write the email in addition
<Kaloz> apw: okay, I'll wait for the second ones upstream submission and send mail to there
<Kaloz> apw: 1197451
<smb> bug 1197451
<ubot2`> Launchpad bug 1197451 in linux (Ubuntu Raring) "Ubuntu fails to properly boot on Macbook Air 2013 6,1 & 6,2" [High,Triaged] https://launchpad.net/bugs/1197451
<apw> bloody macs
<Kaloz> apw :P only haswell I was able to pick up
<smb> Kaloz, and yes, fix committed should be only set by us when we apply it
<Kaloz> apw: anyways, with the help of the Intel guys that one is fixed, and with the help of the hda maintainer sound fully works, too. actually, everything works almost flawlessly with linux now
<Kaloz> smb: as I can't switch it back to Triaged, Confirmed or In Progress fits better for you?
<smb> Kaloz, I switched it back to triaged
<Kaloz> ok, thanks
<apw> smb, heh so did i
<apw> i hate LP
<smb> apw, Which lp does not care about. :-P
<smb> +1
<smb> Hm, that upstream report looks like that was CSM not working but EFI did?
<Kaloz> EFI does, but only with the patch
<smb> ah ok, have not read through all comments
<Kaloz> otherwise LPSS makes the kernel puke and it happens before framebuffer gets initialized
<Kaloz> so one gets no output at all :P
<apw> Kaloz, that fix hasn't hit linus' tree as yet, so ... we are going to be resistant on picking it up
<apw> in case it changes
<Kaloz> apw: well, it's surely affects the macs, but if you check the patch, it could fail on other systems, too.. I know it's queued for 3.12, but stable was added in CC -- no idea when Linus would merge it
 * henrix -> lunch
<smb> Looks to be in linux-next which is a good sign
<rtg> apw, just sent you an email re: aufs fails to load. your changes in -5.10 may have broken it
<apw> rtg, ack
<apw> rtg, upstream aufs foobar on release, am sorting out
<rtg> apw, ack. I assume this'll require an upload to fix.
<apw> rtg, yes code fix required, will get it on the tip as soon as i have it tested
<apw> i think it should be abi agnostic, so we can shove it in quick
<rtg> apw, aufs may not change the ABI, but 'mfd: rtsx: Read vendor setting from config space' does. drat.
<ppisati> brb
<rtg> apw, rebased and pushed ABI bump
<apw> rtg, ok will get this test done and shove mine on the top
<rtg> ppisati, rebooting tangerine for kernel update
<ppisati> rtg: ack
<rtg> ppisati, though, as usual, it doesn't seem to wanna reboot without a power cycle.
<ppisati> rtg: yep
<rtg> ppisati, tangerine is back
<ppisati> rtg: cool, thanks
<rtg> apw, there is a bug about the aufs bits: bug #1222407
<ubot2`> Launchpad bug 1222407 in linux (Ubuntu) "3.11.0-5.11 has broken aufs support (needed for docker)" [Undecided,Confirmed] https://launchpad.net/bugs/1222407
<apw> rtg ok ta will reference that
<rtg> apw, looks like a simple thinko ?
<apw> just a bit of code which got lost in a rearrangement indeeed
<rtg> henrix, kamal, bjf: bug #1222442 is a straightforward regression with analysis. please check our other stable releases to see if they are affected. 
<ubot2`> Launchpad bug 1222442 in linux (Ubuntu) "Linux kernel regression: Links on CIFS shares" [Undecided,Incomplete] https://launchpad.net/bugs/1222442
<henrix> rtg: looking...
<apw> a
<bjf> rtg, if there is a fix, we are cranking this week so we could get this fixed up right away
<rtg> bjf, chat of Ben to see if its been reported in debian
<rtg> chat up*
<henrix> rtg: bjf: the fix is already upstream (757c4f6260febff982276818bb946df89c1105aa) and ben's 3.2 kernel containing it is currently under review
<smb> rtg, I think gomeisa might be pending a reboot too. Right now I could interrupt what I am doing if it is otherwise idle
<rtg> smb, hmm, I think it is up to date
<kamal> rtg, henrix, apw: the change that the reporter says introduced the bug is
<kamal> upstream commit 62106e9 cifs: only set ops for inodes in I_NEW state
<kamal> and it *has* been applied to all stable trees
<smb> rtg, Yeah, should have looked before. I *thought* I had seen it but probably some other host
<henrix> kamal: yeah, check my msg ^^^ (forgot to highlight your nick :) )
 * smb logs in into too many
<kamal> henrix, doh!
<henrix> kamal: the fix for that bug is tagged for stable and is under review for precise
<henrix> kamal: i've it queued for Q as well, but i'll probably just SRU it as i won't be releasing a 3.5 this week
<kamal> henrix, and it looks like I've already applied the fix to 3.8-stable, but you have *not* applied it to 3.5-stable
<henrix> kamal: i did (today!) :)
<kamal> henrix, ah ha!
<apw> rg
 * smb lends apw a t
<apw> rtg, just pushed some updated aufs bits which fix the current issue
<apw> smb, thanks, i needed that
<bjf> henrix, please SRU it and as long as you are doing yours, please do the precise one as well
<henrix> bjf: ack
<henrix> kamal: have you released 3.8 with this fix, or shall i SRU it as well?
<rtg> apw, cool. will package and upload after I've finished reviewing my pile of LP bugs.
<apw> rtg, ack and thanks
<kamal> henrix, bjf: I have released it (in 3.8.13.7) ... it already appears in raring's master-next
<bjf> kamal, ack
<henrix> kamal: cool, so i'll just prepare the P and Q patches
<kamal> henrix, agreed
<rtg> kamal, there is a note on the k-team list for you regarding 3.8 stable: "nouveau fix for ubuntu kernel" 
<kamal> rtg, thanks! will look shortly
<rtg> bjf, kamal: its an obvious bug fix and should likely get applied before the next turn of the crank
<bjf> rtg, ack, can do
<rtg> kamal-afk, bug #1222627 appears to be made just for you
<ubot2`> Launchpad bug 1222627 in linux (Ubuntu) "Suspend stopped working after the 3.8.0-30 upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/1222627
<apw> r
<apw> rtg, i didn't put the bug link in that aufs update, cause it was scripted
<rtg> apw, I'll get it in
<apw> rtg, ta
<rtg> apw, I'm gonna upload this kernel since the aufs bug is causing some real issues.
<apw> rtg seems appropriate
<bjf> kamal-afk, i'll sru the nouveau driver fix (unless you've already done it)
<henrix> bjf: while we're at regressions, i never managed to get any reply from bug #1215513
<ubot2`> Launchpad bug 1215513 in linux (Ubuntu) "System locks up, requires hard reset" [High,Incomplete] https://launchpad.net/bugs/1215513
<henrix> bjf: the one on the staging zram bug
<kamal> bjf, I haven't looked at the nouveau thing yet ... feel free to handle it.
<bjf> kamla, done
<rtg> kamal even
<bjf> henrix, greg sob'd it, it must be good
<rtg> besides, its a staging driver....
<henrix> bjf: rtg: agreed.. so we just keep it as it is and i'll try to keep an eye on other regressions on this driver
<bjf> henrix, no, let's go ahead and sru that fix and get it into this cycle
<henrix> bjf: oh, ok. so... iirc the backport isnt trivial and i would rather revert the commit that introduced the issue then having an untested (possibly broken) fix.
<henrix> bjf: but i'll have to look again to the fix (there has been a weekend since last time i looked!)
<bjf> henrix, ack, go for the simple fix if the backport is a pita
<henrix> bjf: ack
<dave_> hi, what should I use for grouper: "fakeroot debian/rules binary-omap4" (from https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile)
<rtg> dave_, I use 'dpkg-buildpackage -d -B -aarmhf -us -uc'
<dave_> rtg: I was trying this all weekend. It builds. But I can't deploy the zImage (via abootimg) on grouper. It won't boot.
<rtg> hmm, well that is a different issue
<dave_> rtg: what am I supposed to do once 'dpkg-buildpackage -d -B -aarmhf -us -uc' is finished? How do I get the kernel (boot.img) replaced?
<rtg> dave_, there is some abootimg magic that I can never remember. perhaps ogra_ does.
<ogra_> just run flash-touch-kernel ... it should dtrt
<ogra_> root@ubuntu-phablet:/# flash-touch-kernel -h
<ogra_> usage: flash-touch-kernel [path to kernel]
 * rtg -> lunch
<ogra_> (needs zImage|vmlinuz)
<dave_> where does flash-touch-kernel come from?
<ogra_> initramfs-tools-ubuntu-touch 
<ogra_> it is preinstalled on the device
<ogra_> (and undocumented on purpose :) )
<dave_> yes, flash-touch-kernel is on the device. But how is that supposed to work? I can cp a zImage over and flash it on the device???
<ogra_> yes
<ogra_> adb push zImage /tmp/
<ogra_> adb shell
<dave_> let me try that
<ogra_> flash-touch-kernel /tmp/zImage
<ogra_> (you could also just install the .deb of your build, flash-touch-kernel will be called automatically if you do that
<ogra_> )
<dave_> (when I was trying to install my .deb files,  got an error msg saying smth like "cannot write to /system/.." or similar)
<dave_> "flash-touch-kernel /tmp/zImage" does not work. My zImage is not good I guess.
<dave_> "fastboot flash boot saucy-preinstalled-boot-armhf+grouper.img" and I'm back in business :-)
<dave_> So let me see, 'dpkg-buildpackage -d -B -aarmhf -us -uc' should work on raring?
<rtg> dave_, I build on precise using  gcc-4.6-arm-linux-gnueabi
<phillw> Hi, is the fix for bug 1218691 noteworthy to kernel team / bug-team / ubuntu+1 ?
<ubot2`> Launchpad bug 1218691 in linux-firmware (Ubuntu) "Possible missing firmware /lib/firmware/radeon/KAVERI" [Low,Triaged] https://launchpad.net/bugs/1218691
<rtg> phillw, its benign (unless you have a Radeon that requires the Kaveri firmware)
 * apw gives up for the day
<dave_> rtg: gcc-4.6-arm-linux-gnueabi is not available on raring. I am using 4.7 here. But I also tried on precise + quantal (chroot) with gcc-4.6-arm-linux-gnueabi. On quantal I can build complete. Maybe I should try that zImage with flash-touch-kernel...
<rtg> dave_, we had trouble with 4.7 and higher. it would not produce a bootable kernel
<phillw> rtg: in my tiny opinion, having the warning message still flag up is a pain and could lead to further bug reports. However, I leave it in your good hands :)
<dave_> rtg: OK
<dave_> rtg: precise and quantal both good?
<rtg> phillw, I'm hoping the kaveri firmware is upstream by the time saucy releases
<rtg> dave_, same cross compiler IIRC, so yeah it should be
<phillw> rtg: is there anyone I should ask about https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1218691/comments/4
<ubot2`> Launchpad bug 1218691 in linux-firmware (Ubuntu) "Possible missing firmware /lib/firmware/radeon/KAVERI" [Low,Triaged]
<phillw> it is there, just possibly needs a sponsor?
<rtg> phillw, get the radeon guys to send a patch to Ben Hutchings <ben@decadent.org.uk> to include the Kaveri firmware 
<phillw> rtg: do they have a channel? 
<rtg> phillw, the linux kernel mailing list (which the radeon devs should know about)
<phillw> rtg: thanks, will do :)
<dave_> what is "build-generic-lpae" good for?
<apw> dave_, larger memory systems (in arm land)
<rtg> apw, what happended with you "giving up" for the day ?
<dave_> am I supposed to use ./debian/build/build-generic/arch/arm/boot/zImage for grouper, or "./debian/build/build-generic-lpae/arch/arm/boot/zImage" ?
<rtg> dave_, I think you're not building from the right branch
<dave_> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git
<dave_> git checkout -b grouper remotes/origin/grouper
<rtg> you should be building from the grouper branch (which does not contain an lpae flavour)
<dave_> huh?
<rtg> well, that looks right wrt  the branch name.
<dave_> well, I just tried a new "./debian/build/build-generic/arch/arm/boot/zImage" and it still doesn't boot on my grouper
<dave_> how would I skip building drivers, if I'm in a hurry?
<dave_> (I'm a little more familiar with the AOSP build process)
<dave_> Looks like I was indeed not on the grouper branch.
<dave_> woah, I'm in
<dave_> rtg + apw: thank you. "which does not contain an lpae flavour" was solving it for me :)
<rtg> dave_, cool
<dave_> ...and "flash-touch-kernel /tmp/zImage" is helpful info. But I need to master abootimg too. Thank you!!
<rtg> dave_, as for skipping drivers, there really aren't any shortcuts because of debian packaging.
<rtg> nuless you _really_ know what yuo're doing
<rtg> unless*
<dave_> aha. well, normally I do. I just made a mistake in my chroot. didn't have git installed... lalala
<dave_> my I ask how long it takes for you to build, say, grouper from scratch?
<rtg> dave_, 5-7 minutes on my 4-way 80 CPU server
<rtg> longer on my laptop
<dave_> "4-way 80 CPU"?
<rtg> dave_, its kind of noisy too
<rtg> oops, only 64 hyper-threads
<ogra_> oh, cking is already gone 
<dave_> rtg: are you honest?
<rtg> ogra_, of course. we chase him off every day at 5P
<ogra_>  [    0.000183] Calibrating delay loop (skipped) preset value.. 13.53 BogoMIPS (lpj=67677)
<ogra_> :)
<ogra_> 13.53 ... funny value for a 1.6 GHz CPU on boot 
<rtg> dave_, processor	: 63
<rtg> vendor_id	: GenuineIntel
<rtg> cpu family	: 6
<rtg> model		: 46
<rtg> model name	: Intel(R) Xeon(R) CPU           X7550  @ 2.00GHz
<ogra_> i'll try to catch him tomorrow then 
<dave_> I admit it takes longer that 5-7 minutes on mine. But won't say how much.
<dave_> boot.img via abootimg working also. Life can be good.
 * rtg -> EOD
<dave_> Why no adb logcat during boot? Or is there a trick?
<ogra_> during boot ?
<dave_> yeah, link on that other OS, you know.
<dave_> like
<ogra_> no, we are not that other OS :) our logs live in /var/log 
<ogra_> but you can use /system/bin/logcat to get logcat output from the android container
<ogra_> (it isnt in PATH)
<dave_> When this other OS is installed I can run "adb logcat" on my laptop and if the grouper is connected via USB I can watch it boot, from very early on. When I have Ubuntu installed, "adb logcat" shows nothing during boot.
<dave_> Above, I was talking about the system log, not the kernel log. The kernel log can be watched during boot like so: adb shell cat /proc/kmsg (on the other OS). Maybe just a simple adb thing, that can be enabled?
#ubuntu-kernel 2013-09-10
<ppisati> moin
<ppisati> brb
<smb> morning
<ppisati> smb: debscripts?
<smb> ppisati, devscripts
<ppisati> smb: ah, deVscripts :)
<smb> ppisati, yep :)
<apw> NETSPLIT FUN
<smb> I am back
<ppisati> bug 1223261
<ubot2`> Launchpad bug 1223261 in flash-kernel (Ubuntu) "dtb concatenation support" [Undecided,New] https://launchpad.net/bugs/1223261
<ppisati> lool: ^
<ppisati> lool: dtb concatenation support for our arm multiplatform kernel
<ppisati> lool: in this initial patch i specifically added support for only one board (panda)
<ppisati> lool: the shell code is a bit ugly IMO, feel free to improve it
<ppisati> lool: give it a look when you've time
<ppisati> lool: :)
<ppisati> lool: and i'll have another patch (for calxeda this time) in the afternoon, albeit it's trivial this one
<lool> ppisati: ok; I'll try to squeeze some time on this then
<Guest40083> test
 * henrix will be afk for a bit
<slangasek> rtg: hi, is there anything further I should do with bug #1223195 to make sure it's on y'all's radar?
<ubot2`> Launchpad bug 1223195 in linux (Ubuntu Saucy) "efivarfs built as a module in saucy, so not mounted at boot" [High,Triaged] https://launchpad.net/bugs/1223195
<rtg> slangasek, didn't see it yet. its now on my radar.
<slangasek> ok :-)
<rtg> slangasek, I'm assuming that not having debugfs, securityfs, spufs, binfmt_misc, and fusectl built in isn't really causing problems ?
<slangasek> rtg: which of those aren't built in?
<slangasek> rtg: ah, binfmt_misc isn't; it's possible that something else is loading that for us and mounting the fs
<rtg> perhaps debugfs as well
<slangasek> rtg: I included that list more as a "if you're marking this as 'required' in the config, you might want to do the same for these others"
<rtg> slangasek, right.
<slangasek> oh... and pstore just got added to the list
<rtg> wtf is spufs ?
<rtg> looks like the rest are already built in
<ohsix> cell has psus
<rtg> ohsix, its not showing up 'cause we aren't building  a cell flavour
<bjf> henrix, what did we decide about that zram issue?
<rtg> bjf, revert ?
<bjf> rtg, that's my vote as well but henrix was taking a fresh look at the upstream fix
<rtg> bjf, hmm, I've already pushed the revert
<bjf> rtg, hadn't gotten to my email yet. that works for me.
<henrix> bjf: yeah, i've sent the revert earlier today
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<henrix> bjf: i'll be sending a revert request to the stable ML, CC'ing upstream authors. they may actually be interested in providing a backport of the real fix
<bjf> henrix, i'm good with the revert
<bjf> henrix, thanks for looking
<henrix> bjf: cool. i'll keep ktml on CC for that revert request
<apw> henrix, ok ... finally ... have a look at the matrix now
<henrix> apw: will do
<apw> henrix, i think that represents reality for the 'pre-release-pocket-version' ones
<henrix> apw: wow!!!! 62 to 33!
<apw> henrix, heh yeah there was a lot of trash sitting there being ignored
<apw> it is somewhat more readable now too
<henrix> apw: ok, i'll go through it this afternoon see if everything's ok (i always leave a tab open with the 'old version' of the matrix so that i can compare it ;) )
<henrix> apw: thanks a lot for that
<apw> henrix, heh yeah me too.  i have hand verified all the changes it made and they all refer to version in the past as far as i can tell, so i am pretty sure it is ok
<apw> henrix, as you said there was a lot of stuff pending when it was not-affected in the actual release
<henrix> apw: cool. you'll be the 1st one to know if i find anythin strange :)
<henrix> thanks again
<apw> henrix, i am sure, but let me know indeeed
 * apw wanders out for a bit to get some supplies
<rtg> apw, cking: I've set CONFIG_EFI_VARS_PSTORE=m. I think upstream has fixed the BIOS bricking characteristics.
<rtg> (for saucy)
<apw> rtg, ok
<apw> henrix, all well in cve matrix land ?
<henrix> apw: so far i haven't found anything weird :)
<apw> henrix, ok good :)
<apw> henrix, any sign of the other half of kees' patches appearing anywhere ?
<henrix> apw: nop, nothing yet
<apw> oddness indeed
<henrix> he hasn't replied to you, right?
 * henrix remembers apw asking him on irc
<apw> nothing i have seend indeed
<smb> jsalisbury, Just to give you a heads up... looks like the meeting bot resigned
<jsalisbury> smb, ok
<jsalisbury> smb, thanks for the heads up
<smb> jsalisbury, Just watching the server team coping without :)
<jsalisbury> :-)
<ppisati> bug 1223439
<ubot2`> Launchpad bug 1223439 in flash-kernel (Ubuntu) "highbank: generic-lpae support" [Undecided,New] https://launchpad.net/bugs/1223439
<ppisati> lool: and while there, look at this too, it's a one-liner
<lool> ppisati: sorry, did (slowly) some gstreamer stuff this pm
<lool> I still have f-k patches in my debian inbox that I haven't checked out in 2 weeks too, so I do get reminded of this daily  :-)
<ppisati> lool: don't worry, i'll prod about it in the coming days too :)
<TsarObomba> Hery guys, it was suggested I ask here when I asked in ubuntu. Basically I have an question abpout making a very simple udev rule
<TsarObomba> But i cannot for the life of me wrap my head around the syntax of the udev rules system
<TsarObomba> Its to change the permissions of my thinklight without having to do it each time i power on
<TsarObomba> so this: chmod 666 /sys/class/leds/tpacpi\:\:thinklight/brightness
<TsarObomba> I would like to make that into a udev rule, but i dont understand the syntax at all, ive looked at a couple guides
<rtg> apw, have you looked at bug #199345 ? (whilst you are looking at HV graphics issues)
<ubot2`> Launchpad bug 199345 in Infobase "Provide a way to delete objects" [High,Confirmed] https://launchpad.net/bugs/199345
<rtg> make that bug #1199345
<ubot2`> Launchpad bug 1199345 in linux (Ubuntu) "Can't install on Hyper-V Server 2008 R2 SP1 (error video)" [High,Confirmed] https://launchpad.net/bugs/1199345
<apw> rtg will stick it on the list and chat with utl
<apw> TsarObomba, /lib/udev/rules.d/40-ia64.rules has an example of changing the permissions on a 'thing' when it appears
<apw> TsarObomba, /lib/udev/rules.d/40-qemu-system-common.rules has an exmaple of setting group ownership with paired permissions if that is more what you want
<apw> other files in that same directory should hlpe you sort out the matching syntax
<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 September 17th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati -> EOL
<henrix> he was such a nice guy...
<apw> heh ...
<kees> apw, henrix: "has he replied to you?" was that me as the "he"? or is there anything I can do to help with HID stuff?
<apw> kees, yo yeah you were :)  wondering where the "other half" of your 12 or so patches went
<apw> kees, only about half seems to have landed in linus' tree
<apw> kees, CVE-2013-2888->2897 ones
<kees> apw: one of the RH HID guys NAKed a portion of them, so I did a v2, which he ACKed half of, and he's going to take a crack at v3 on the last 2 remaining ones.
<apw> kees, ahh so they are being 'improved' and will come along in time
<apw> henrix, ^^
<henrix> apw: yep, saw that. thanks kees
<kees> the RH HID dude was out last week, so nothing was moving. the conversation has continued this week, though.
<henrix> cool, so they may actually land before rc1
<apw> as long as we arn't being dumb and missing them, i am happy
<kees> hehe
<kees> and frankly, as long as you have the Report ID one (the first one), you're good. the rest are not as horrible.
<apw> henrix, heh do we ahve the 2888 one yet ?
<henrix> apw: yes, we do
<henrix> apw: we have 2888, 2892, 2896, 2898 and 2899
<apw> henrix, then ... why is 2888 still needed across the board
<apw> hmm
<henrix> apw: oh, by 'we do' i meant 'its in linus'
<henrix> apw: but not applied yet
<apw> heh ... good enough
<henrix> apw: i've actually sent the patches for Lucid to the ktml. but not for the other series
<henrix> apw: for the 2888, i mean
<apw> henrix, i was only worried it was applied and not showing, if it is not applied i am good
 * henrix -> EOD
<apw> bjf, i see raring failed to build, some module went walkies
<bjf> apw, ack, working on it
<bjf> apw, thanks
<phillw> rtg: are you about?
<rtg> phillw, about to take off for lunch
<phillw> okies, enjoy lunch, I'll pastebin up where I've got up to with bug 1218691 We need some help :)
<ubot2`> Launchpad bug 1218691 in linux-firmware (Ubuntu) "Possible missing firmware /lib/firmware/radeon/KAVERI" [Low,Triaged] https://launchpad.net/bugs/1218691
<phillw> rtg: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1218691/comments/5
<ubot2`> Launchpad bug 1218691 in linux-firmware (Ubuntu) "Possible missing firmware /lib/firmware/radeon/KAVERI" [Low,Triaged]
<rtg> phillw, the issue I have is that I don't know the provenance or licensing of these files. I'm not gonna include them in Ubuntu's linux-firmware package until I have a paper trail from AMD
<rtg> they shuold also be included in the upstream repo first, and ben will have the same concerns
 * apw was going to say the same thing ... those are random files on the internet how do we even know they are firmware
<phillw> rtg: apw can you update the bug, I'm well out of my depth here :/
 * rtg -> lunch
<apw> phillw, updated
<phillw> apw: thanks, I'm only an iso tester :)
<apw> testing is always useful :)
<phillw> apw: indeed... https://www.virtualbox.org/ticket/12001 kills vBox in Raring using the Saucy kernel series... but that is never going to get an SRU. Testing has its moments :)
<phillw> apw: rtg https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1218691/comments/7  could you comment as to where to go from here (or even, please, subscribe to the bug - so as to take me out of the loop of things I don't have knowledge of how to deal with ?) :) Thanks, phillw
<ubot2`> Launchpad bug 1218691 in linux-firmware (Ubuntu) "Possible missing firmware /lib/firmware/radeon/KAVERI" [Low,Triaged]
<rtg> phillw, let this one go for now. AMD will eventually publish their firmware just like they have for the other zillion firmware files that they have, hopefully in time for 13.10 release. If not, then I'll SRU these files when they become published from the right source.
<phillw> rtg: should it be marked as triaged? aka, we know about it and it will be dealt with :)
<rtg> sure
<phillw> ahh, it is... just the debian bit I cannot alter :D
<phillw> thanks, one less bug on my hit list :D
<phillw> should the warning message be mentioned in any release notes for people who do update / upgrade just to let them know it can be safely ignored, as opposed to the other option of pulling in drivers that may well bork their system? https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1218691/comments/3
<ubot2`> Launchpad bug 1218691 in linux-firmware (Ubuntu) "Possible missing firmware /lib/firmware/radeon/KAVERI" [Low,Triaged]
 * rtg -> EOD
#ubuntu-kernel 2013-09-11
<ppisati> moin
<bjf> night :-)
<ppisati> bjf: sleep well :)
<ppisati> robher: just for ECX1000? is it ok on ECX2000? i mean cpuidle
<ppisati> robher: that's what the patch says, but i wanted to check
<smb> morning
<ppisati> smb: moin moin :)
 * apw yawns ... moin ppisati
<apw> smb, morning
<smb> apw, ppisati, morning
<smb> apw, I hope that is just fluke and coincidence but after dist-upgrading my haswell on saucy this morning it locks up somewhere on boot...
<smb> not really locked up but not completing it
<apw> ppisati, this IDLE config change, am i expecting that to only apply to generic and not generic-lpae
<apw> ppisati, /me replies in email
<apw> henrix, are we good matrix wise, found anything else dodgy ??
<henrix> apw: nop, i believe we're good
<henrix> apw: i reviewed the matrix yesterday and found nothing 
<apw> henrix, sweet, happy again
<henrix> :)
<apw> henrix, have we missed CVE-2013-2237
<apw> in 3.8 stable or something?  it seems 3.5 got the fix
<apw> (we do both 3.5 and 3.8 stable right ?
<apw> )
<henrix> apw: i believe the fix is in 3.8 queue, but let me check...
<apw> ahh we don't release them on the same schedule then ?
<henrix> apw: yeah, 3.8 is currently under review and it contains the fix
<henrix> apw: no, we actually have different schedules. this is mainly due to the fact that 3.5 is much older so it gets fewer patches
<henrix> apw: so, they end up being released with a different cadence
<apw> henrix, heh, i think i am supprised it is ahead :)
<henrix> apw: :) just coincidence, i believe. i don't think that's always the case
<henrix> anyway, i don't have strong arguments about having different cadences for different stable kernels. i just think its natural, but happy to do otherwise
<apw> henrix, oh no it is your baby as it is ... how you think it should work is how ...
<apw> henrix, i noticed it only as it seemed inconsistant in the matrix, and you have assured me it is covered, so i am good
<henrix> apw: ack :)
<robher> ppisati: yes, the cpuidle fix is only needed for highbank. The driver will not initialize on midway.
<rtg> ppisati, kamal, sconklin, jjohansen, bjf: rebooting tangerine for kernel update
<ppisati> rtg: ack
<jjohansen> rtg: can you give me 2 mins
<rtg> jjohansen, shit, already pulled the trigger
<rtg> sorry, I didn't think anything was going on
<jjohansen> heh its okay, I was just in the middle of a kernel copy, I can start it over when it comes back up
<rtg> jjohansen, besides, what are you doing up so early anyways ?
<jjohansen> rtg: oh, its more like up late debugging
 * henrix -> late lunch
<rtg> apw, whats up with the tools naming scheme changes ? I need to update the goldfish meta package.
<apw> rtg, bah got distracted ... will sort them right now, so you can see what the pattern is
<rtg> grumble, server issues. back in a few....
<rtg> ppisati, kamal, sconklin, jjohansen, bjf: P.S. - tangerine is back if you hadn't already noticed
<sconklin> ack
<ppisati> rtg: cool
<rtg> jsalisbury, cking, henrix: rebooting gomeisa for kernel update
<jsalisbury> rtg, ack
<henrix> rtg: ack
<cking> rtg: ack
<apw> bjf, i think we decided that shanky will be happy with random packages in the ckt ppa as long as there are not release-tracking-bugs for them
<infinity> apw: We've had random packages in the PPA before (and there's at least one in there now), so I'd hope so.
<bjf> apw, shanky only cares about bugs and doesn't care about the ppa (mostly) just to match packages with versions in bugs
<apw> bjf, perfect as i have dumped some ~preN packages in there :)
<bjf> apw, should be all good
<apw> rtg, are all your changes for goldfish in the archive, i want to spin these changes against a clean tip
<rtg> apw, the meta, or the kernel ?
<rtg> apw, I'm working on i386 for goldfish, but I'll just merge after you push your tools package renaming
<apw> ok ack
<u-k-i-t> jsalisbury: bug 1212977. Tested today's ISO images and no change. The error remains even with the fix for bug 1223195.
<ubot2`> Launchpad bug 1212977 in linux (Ubuntu Saucy) "saucy daily-live images are unbootable on Dell Optiplex 990; stuck in BusyBox shell" [High,Confirmed] https://launchpad.net/bugs/1212977
<ubot2`> Launchpad bug 1223195 in linux (Ubuntu Saucy) "efivarfs built as a module in saucy, so not mounted at boot" [High,Fix released] https://launchpad.net/bugs/1223195
<jsalisbury> u-k-i-t, can you run uname -a and confirm you are running the 3.11.0-7.13 kernel
<u-k-i-t> jsalisbury: Will do. The kernel on the iso manifest says it is that version, but will double check.
<u-k-i-t> jsalisbury: Yes a uname -a at the initramfs prompt failure point. Shows it running 3.11.0-7 #13.
<jsalisbury> u-k-i-t, thanks for checking.  We'll have to investigate further.
<u-k-i-t> jsalisbury: Ok
<LinuxGol_>  /me is running HP Pavilion Slimline 3100n desktop PC running Ubuntu 13.04 server and kernel 3.8.0-30-generic.  seeing i2c i2c-3 sendbytes NAK bailout error every few seconds
<apw> LinuxGold, siy
<apw> LinuxGold, sounds like you should file a bug, and (if you know) add what kernel did not do this
<LinuxGold> siiy?
<apw> .
<apw> LinuxGold, keyboard/finger failure
<LinuxGold> looked in google, seems to be a bug reported on nouveau -- not sure if that was the specific bug?
<apw> so you use nouveau, do you have an nvidia card
<LinuxGold> sent email to kernel-team email
<LinuxGold> yes
<apw> i think as we said in response to that, file a bug and let us know the number
<LinuxGold> shamm@minecraftsrv:~$ lsmod | grep i2c
<LinuxGold> i2c_algo_bit           13413  1 nouveau
<LinuxGold> i2c_nforce2            13020  0 
<apw> that will get us all sorts of h/w info
<apw> and let us track it
<LinuxGold> k
<LinuxGold> looking for url to report bug to
<apw> 'ubuntu-bug linux' would be the command
<LinuxGold> aha
<LinuxGold> executing
<LinuxGold> #1015165 -- incomplete
<LinuxGold> ah
<LinuxGold> i2c-4 not i2c-2
<LinuxGold> having problem with bug website
<LinuxGold> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1224004
<ubot2`> Launchpad bug 1224004 in linux (Ubuntu) "i2c i2c-3: sendbytes: NAK bailout." [Undecided,New]
<LinuxGold> thanks apw
<rtg> apw, I'm ready to wrap goldfish and upload
<apw> rtg, go ahead without me, i need to do more testing
<apw> i'll rebase on you
<rtg> apw, will do
<LinuxGold> is there any way to disable the annoying NAK messages?
 * rtg messed up the goldfish upload. doh!
<ogra_> rtg, not that anyone makes use of it yet 
<rtg> ogra_, well, it would be easier for someone to use if I actually got the build working.
<ogra_> heh
 * rtg -> lunch
<TsarObomba> im connected to a buildbox that also acts as a desktop on the remote end
<TsarObomba> im wondering if its possible to rebuild the nvidia mpodule for the box before I reboot
<TsarObomba> (using a non-stock kernel here)
#ubuntu-kernel 2013-09-12
<xequence> infinity: I'm traveling until Monday. Is the 3.5 SRU a big hurry? 
<bjf> xequence, you should be fine, the cycle is just starting we haven't even gotten all of *our* kernels in the pipe yet.
<xequence> bjf: Thanks. Wasn't sure if it was the scheduled SRU. Next week then. 
<amitk> apw: smb`: morning! Do you guys have recommendations for an x86 machine brand (remote access of serial preferable) to use for kernel build and boot testing?
<amitk> s/of/through
<ppisati> moin
<smb> morning
<smb> amitk, Maybe not really machine brand. I'd probably look for a newer Xeon based board. You probably need to think a bit more storage controller as one older in one of our builders rather slows things down. Personally I like supermicro boards with IPMI controller for remote administration.
<amitk> smb: thanks will look at something with a supermicro
 * apw whines
<amitk> smb: our main usecase is testing patches against x86 as we mangle various core subsystems
<amitk> smb: so a server class machine isn't a requirements per-se. We're looking for wider coverage across x86 cpu generations
<smb> amitk, Yeah, I just said Xeon for compile time. If you are not need a lot and quick you probably can just go with some i5 or i7.
<smb> IPMI was what I found just too useful when working from somewhere else and having complete control over the box at home (reset, turn off). Intel has that AMT stuff but frankly it seems they don't wnat it to be used by "normal" people without Windows
<smb> apw, Whassup? Bad morning or just morning in general?
<apw> ugg morning, no
<smb> apw, Just go back to bed man. :) (in case you are not still)
 * ppisati -> reboot
 * apw has a long and intense chat with apt-cacher-ng about its performance
 * apw gets his 12lb sledge out and wacks her a few times
<smb> apw, You need some lower expectations
<apw> smb, heh just discovered that nightly 'maintenance' has been failing for the last 4 months, so it has not been expiring volatile files
<apw> and after much f*king about with it, a manual zap of the cache was required to sort its head out
<smb> Heh, I could imagine I got the same here... Not really likely to find out one has too many files
<apw> no, except when they are volatile and don't get appropriatly timed out
<apw> so you get a release updater from april
<smb> apw, With your down, my pragmatic fix would have been rm -rf cache/* 
<apw> yeah i did that, that was the sledge hammer
<smb> ah
<apw> and in fact its behaviour is random, sigh, a few refreshes and all is well, wtg
 * henrix -> lunch
<apw> rtg, yo ... goldfish, was there meta changes to go with your kernel changes, i don't see 'em in the repo
<rtg> apw, not yet
<apw> rtg, do you have 'em done somewhere so i can base on top of it ?
<apw> even if they arn't final yet
<rtg> apw, there is a goldfish branch in ubuntu-saucy-meta
<apw> rtg, yeah am based on that, but there is no i386 in there, if you anr't planning one that is ok i can ignore
<rtg> apw, no, that I don't have yet
<apw> ok i'll ignore and we can cross that when we get there
 * rtg relocates
<rtg> apw, https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4959398/+files/buildlog_ubuntu-saucy-i386.linux-goldfish_3.4.0-0.4%7Epre1_FAILEDTOBUILD.txt.gz
<apw> rtg yeah saw ... am fixing ...
<bjf> ppisati, P and Q ti-omap kernels ?
<rtg> apw, do you have Mir running on any radeon GPUs ? I tried it on my Lenovo last night. It fell over with a resounding thud.
<ppisati> bjf: i'm finishing one thing, than i'll do those
<bjf> ppisati, cool, just a reminder
<apw> rtg, i don't think i have a radeon ... and i am unsure where i am running mir :)
<apw> how did you detect you were
<rtg> apw, I set it up according to instructions on the wiki
<apw> rtg, oh ... i see :)  got a pointer
<apw> rtg yes hang on
<rtg> infinity, whats the story on reiserfs in debian land ? I can't seem to find a discussion about _why_ reisferfs has been removed.
<infinity> rtg: Because jail?  I have no idea.  You'd probably want to talk to Ben about it.
<rtg> infinity, just wondered if you any insights. was just reading the ubuntu-devel thread
<infinity> rtg: It's not something I've been following because I have zero carefactor.
<rtg> xnox is proposing to disable it in the kernel, but I'm not so sure.
<bjf> -1
<apw> xnox, yo ... what was the background to debian dropping reiser ... i can see that we should drop it in the installer ... but kernel side we carry a heap of things enabled cause they are there and nothing more
<xnox> bjf: rtg: it's not supported in upstream kernel, hence the reasoning to remove it in the debian kernel config. Are you going to maintain/keep-building reiserfs in newer kernels and backport stacks?
<xnox> apw: why should anyone use reiserfs today?
<xnox> apw: or floppy disks?
<rtg> xnox, how is it not supported ? There have been 3 commits in the 3.12 merge window
<xnox> rtg: oh, wow =)
<apw> xnox, indeed but we have a floppy disk support just in case
<xnox> apw: ok. one sec.
<apw> for that one special character somewhere in iceland who uses one
<xnox> apw: who also someone has PAE capable kernel?! =)
<xnox> s/someone/somehow/
<bjf> xnox, if it's in linus' tree there there is still "support". is it broken? is it trashing peoples data?
<apw> hey i don't have to agree with all the decisions we have to amke :)
<TsarObomba> hmm ikonia is not here, dangit
<xnox> rtg: apw: bjf: so here is the original email from Ben Hutchings https://groups.google.com/forum/#!topic/linux.debian.maint.boot/QO187Szy2_o with the list of modules he is dropping in the debian kernel config.
<xnox> rtg: apw: bjf: at the same time debian-installer dropped support for those as well (e.g. reiserfs, ufs [!kfreebsd-any] )
<rtg> xnox, that hardly seems to be sufficient justification. there are plenty of drivers that are 'barely maintained upstream'
<xnox> rtg: ok. But is it ok for the installer to drop support for those filesystems in Ubuntu?
<rtg> xnox, yes
<xnox> and relevant udebs.
<apw> xnox, so that just says that they won't package reiser so that it could be used in the installer
<xnox> whilst stock kernel keeps on building them.
<apw> xnox, it says nothing about whether they kernel is still using them
<rtg> xnox, I'm fine with that as well since only the installer (really) uses udebs
<apw> producing them
<apw> xnox, perhaps we need a bug for this in which we can list the udebs you no longer need, and we can adjust as appropriate
<xnox> apw: true. I didn't check if the kernel config was actually changed to drop those, or whether it was a pure udebs change.
<apw> xnox, the wording as i read it is talking only about udeb changes
<rtg> xnox, its just a packaging change
<apw> and indeed perfectly sensible ones i suspect, who uses floppies for instalation media now
<apw> get your pile to 2000 floppies and start feeding
<xnox> apw: first operating system I installed in my life was with a CD-ROM drive.
<xnox> =/
<xnox> and my last three machine don't have CD-ROM drives & installed with usb-sticks.
<xnox> rtg: bjf: apw: ok, sorry about the confusiong wrt. dropping installer support vs [ udebs as well [vs kernel config/modules as well]]. Please reply on the mailing-list that e.g. "kernel team will keep the config, but can drop udebs on request and doesn't mind not supporting those options in the installer"
<xnox> or some such.
<rtg> xnox, too late, I already did
<rtg> reply on the list, I mean
<xnox> rtg: thanks. I had some delay receiving it. So only received it after yours "too late, I already did"
<xnox> =) thanks a lot.
<rtg> no prblem, email isn't exactly real time
<apw> rtg, ok in the ckt PPA is a set of linux, linux-meta, linux-goldfish, and linux-meta-goldfish packages, with the proposed changes for linux-tools applied.  they are all ~preN
<rtg> apw, ack
<apw> rtg, i am basically happy the concept is there i think and if you have no objections would proposed to upload them (with basically no other changes)
<apw> so ... let me know :)
<rtg> ok. gimme a bit
<apw> once they are in and good, i'll do the 'rest of the world' to match
<apw> rtg, no rush
<apw> rtg, if you are looking for 'why is it like this' type information the whole why is documented in the linked bug
<rtg> apw, ack
<TsarObomba> Hi, I am having an intermittent issue with a 3.10 kernel on 13.04, on two different machines, and even on arch too
<TsarObomba> It intermittenly just hangs on boot and does nothing
<TsarObomba> And these are different patchset 3.10 kernels too it happens on
<TsarObomba> Has anyone seen this on 3.10? How may I try and troubleshoot?
<TsarObomba> I know that yes, they are not official ubuntu kernels, but they are pacvkaged for ubuntu and lots of users use them.
<TsarObomba> And it also happened using a 3.10 mainline kernel from the ubuntu kernel ppa mirror
<apw> TsarObomba, i don't think a significant number of people ran with 3.10, though my feeling was 3.10 wasn't very good
<apw> i have had much less pain with 3.11
<TsarObomba> good to hear
<TsarObomba> One of my favorite patchsets should have 3.11 soon
<TsarObomba> pf already does, but they dont package for debian or ubuntu, so i gotta wait for the guy who makes those packages to update his mirror
<TsarObomba> And liquorix (the guy from zen kernel, damentz, makes it) hasnt updated. they just did 3.10.3 last night
<rtg> apw, what branches have you pushed with the tools packaging name changes ?
<apw> rtg, ok ubuntu-saucy master-next and goldfish, ubuntu-saucy-meta master and goldfish, all pushed
<rtg> apw, cool, thanks
<TsarObomba> Does ubuntu have a ubuntupatched 3.10 kernel?
<TsarObomba> for 13.10 or something?
<TsarObomba> I know it has mainline, but id like to pull the .config from a ubuntu patched kernel
<apw> TsarObomba, the config in teh mainline kernel build was seeded from the ubuntu config at the time.  there are also tags for all out kernels in the git repo including any 3.10 uploads we did, you can also get those same source trees from the archive
 * rtg -> lunch
<TsarObomba> i found what i was lookiung for
<TsarObomba> im trying to recompile a 3.11 kernel
<TsarObomba> with a different patchset and make it for deb
<TsarObomba> apw: where could i maybe find the source for the deb of the mainline kernels?
<TsarObomba> like this: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-saucy/
<TsarObomba> I just want the .config from it
<TsarObomba> i guess i can open up the deb
<apw> TsarObomba, the config is applied as one of the patche sin the mainline kernel directory
<TsarObomba> eh
<TsarObomba> its ok
<TsarObomba> i just extracted the deb and pulled it
<apw> TsarObomba, we try and be very transparent to allow people to reproduce you
<apw> s/you/what we have done/
<TsarObomba> yup
 * rtg -> EOD
<ChickenCutlass> apw, ping
<DarkPlayer> hi, i have a question which may no directly fit in here, but maybe someone can still answer it: I am currently working with mount namespaces and want to get a single directory to have write access while the parent directory should have read only access (The directories are on the same mount point).
<DarkPlayer> is it possible to do a mount bind before unsharing the mount namespace so that i can remount the filesystem as readonly while the mount bind still keeps right access?
#ubuntu-kernel 2013-09-13
<ppisati> moin
 * smb whines to infinity about not pressing a button for a whole week
<apw> DarkPlayer, not 100% sure about that, i had a feeling bind mounts had options though, as in you could bind mount -oro but i have never tried
<apw>     Is-a-big-hairy-idiot: Linus Torvalds <torvalds@linux-foundation.org>
 * henrix -> lunch
 * apw pops out to the shops
 * jsalisbury rebooting a few times
<bjf> ppisati, around ?
<ppisati> bjf: yep
<bjf> ppisati, you're going to hate me
<ppisati> bjf: that's impossible i love you
<bjf> ppisati, i did the rebase last cycle while you were on vacation. i didn't push the branch. you need to redo your rebase.
<bjf> ppisati, but don't do it until Mon.
<bjf> ppisati, and i love you also
<ppisati> bjf: P or Q?
<bjf> P
<ppisati> bjf: push it, i'll redo
<bjf> ppisati, if you look at the tracking bug you will see that it thinks it's been released
<bjf> ppisati, i just did
<ppisati> bjf: ah, until Mon
<ppisati> bjf: i missed that part :)
<bjf> ppisati, that's when i knew i'd screwed up
<TsarObomba> jpoin #ubuntu-ops
<apw> heh
 * smb calls it a week
 * apw things a beer is in his future
 * henrix -> EOW
 * cking thinks it's time to slack off
<crass> on 3.8.0-19-generic, looks like hardlinking from one filesystem to the same one though on a mount bind'd path fails
<crass> is this a known issue?
<diwic> https://bugs.launchpad.net/touch-preview-images/+bug/1219057
<ubot2`> Launchpad bug 1219057 in unity8 (Ubuntu) "volume up/down key is not working anymore with the new indicator-sound" [Undecided,In progress]
<diwic> ogra_, ^
<diwic> oops, wrong channel
<cyphermox> does anyone know whether there's an issue currently with cgroups in the latest kernel?
<cyphermox> I'm having an issue with a lxc container starting but that doesn't have /sys/fs/cgroup/memory/lxc/memory.use_hierarchy
<cyphermox> or you know, could be an issue with lxc :D
#ubuntu-kernel 2013-09-14
<mikeit> test
<mikeit> color
#ubuntu-kernel 2014-09-08
<dgadomski> hello everyone
<dgadomski> I've been informed about an issue with failing /etc/init/udev-fallback-graphics.conf
<dgadomski> it tries to load vesafb module, but in the latest kernel configurations this module is compiled in (CONFIG_FB_VESA=y)
<dgadomski> my guess is this udev-fallback-graphics.conf is not needed in such configuration
<dgadomski> could someone please take a look at this?
<infinity> zequence: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1364293
<ubot5> Ubuntu bug 1364293 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<jtaylor> hi, under 3.16.0-14-generic in utopic my cpuis kept at its lowest frequency under full cpu load (4 times yes)
<jtaylor> any hints at debugging the source?
<jtaylor> on a desktop machine (amd phenom x2)
#ubuntu-kernel 2014-09-09
<jtaylor> never mind was thermald
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 3 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues September 16th, 2014 - 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.
<achiang> kamal: ping
 * achiang wonders if anyone is interested in taking a look at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331077
<ubot5> Ubuntu bug 1331077 in linux (Ubuntu) "[Lenovo ThinkPad Edge E540] suspend/resume failure" [Medium,Triaged]
<kamal> achiang, pong
<achiang> kamal: nevermind. i was just generally whining but realized it was unfair to just ping you :)
<kamal> achiang, good 'cuz I don't want any part of yer BIOS bug there, man ;-)
<kamal> achiang, at least, that's what I got from the bug report -- is this not something that Lenovo just needs to fix?
<achiang> kamal: i've only left canonical 2 days ago... did BIOS vendors start fixing their bugs this week?
<kamal> achiang, oh yeah, did you not get the memo.  they fixed 'em all.  all the bugs.  now you can go off to your new gig with a smile!  ;-)
<achiang> ;)
<hallyn> sforshee: heh, was trying to get 'fuseext2 -o allow_others' to work, which is documented in fuseext2 -h.  finally noticed that allow_other actually works!  minor typo
<hallyn> sforshee: beautiful.  i can look at an ubuntu cd image with fuseiso, etc.  very nice.  now i suppose i should try to build a cd image
#ubuntu-kernel 2014-09-11
<Kano> hi, do you intend to backport hawaii support or just use 3.17?
<ohsix> google "graphics enablement stack"
<ohsix> s/graphics/hardware
<Kano> i mean for utopic
<TJ-> If 12.04 has the tTusty HWE and devices supported by that HWE require firmware, shouldn't the HWE packages also Depends on the matching "linux-firmware" from Trusty, rather than the original 12.04 package, in order to provide the firmware? Otherwise, there's not much point to the HWE package if it is being installed to support a new device ?
<rtg> TJ-, we generally just backport the necessary files to the existing package. Do you have some in particular ?
<TJ-> rtg: Yes, a query from a user in #ubuntu for the rtl8188:
<TJ-> modinfo $(awk '/10EC.*8179/{print $3}' /lib/modules/`uname -r`/modules.*) | grep ^firmware
<TJ-> firmware:       rtlwifi/rtl8188efw.bin
<TJ-> But that isn't in the linux-firmware of 12.04; it was first introduced for Saucy according to packages.u.c
<rtg> TJ-, can you start a bug report. I'll follow up.
<TJ-> rtg: Surely, thanks.
<TJ-> rtg: Against linux-firmware?
<rtg> TJ-, yup
<TJ-> rtg: Or against the HWE package and it's depends?
<TJ-> rtg OK
<TJ-> rtg: japro bug 1368301
<ubot5> bug 1368301 in linux-firmware (Ubuntu) "12.04 missing rtlwifi/rtl8188efw.bin when HWE is installed" [High,Triaged] https://launchpad.net/bugs/1368301
<rtg> TJ-, ack
<japro> TJ-, thanks
<TJ-> rtg: Thanks for the rapid fix
<japro> oh wow, thanks
<rtg> TJ-, np. watch for the email requesting you to test it.
<TJ-> rtg: That'll be japro - the user that reported this
<rtg> ack
<mandeep> Hey all , I want to take backup of all user config. Can anyone suggest me some way to take necessary config files. Just copied ~/.* files and just want to know which else files I must copy like in /etc folder.
<infinity> zequence: Another ping about https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1364293
<ukiwi> Apologies in advance if this is the wrong forum for such questions but this is driving me nuts...
<ukiwi> Greetings! I'm having a really hard time mapping the four colour buttons on my Logitech Harmony Smart Control Remote to scan-codes. I can see that the kernel is receiving these events when I 'cat /sys/kernel/debug/hid/events' (03 f5 01 00 00). I'm then editing my /lib/udev/hwdb.d/custom.hwdb with the right USB vendor/model (keyboard:usb:v046DpC150*) and my entries should be like other similar events - e.g.  'KEYBOARD_KEY_
<ukiwi> c0069'. After running 'udevadm hwdb --update && udevadm trigger && udevasm control --reload' they're still not working. I suspect my raw events (03 f5 01 00 00 etc) aren't the same as 'c009a' etc. Can anyone help?
<ukiwi> Greetings! I'm having a really hard time mapping the four colour buttons on my Logitech Harmony Smart Control Remote to scan-codes. I can see that the kernel is receiving these events when I 'cat /sys/kernel/debug/hid/events' (03 f5 01 00 00). I'm then editing my /lib/udev/hwdb.d/custom.hwdb with the right USB vendor/model (keyboard:usb:v046DpC150*) and adding entries which I assume should be like other similar entries - 
<ukiwi> e.g. 'KEYBOARD_KEY_c0069'. After running 'udevadm hwdb --update && udevadm trigger && udevasm control --reload' they're still not working. I suspect my raw events (03 f5 01 00 00 etc) aren't the same as 'c009a' etc. Can anyone help?
#ubuntu-kernel 2014-09-12
<eviljoel> Excuse me if this is the wrong place to ask this question.  I'm am doing something security sensitive.  I was wondering if there is a secure way to git clone the latest kernel source?
<eviljoel> ...or anyway outside of git.
<hyperair> apt-get source?
<hyperair> and verify signatures
<hyperair> which latest kernel source do you want?
<hyperair> ubuntu's tree? or the vanilla tree?
<hyperair> you can just clone normally, and verify the signature
<eviljoel> Ubuntu's tree.
<ohsix> git for the kernel are gpg signed
<eviljoel> Is the source signed?
<hyperair> as long as you can verify securely that the HEAD commit sha1 is correct, you can be guaranteed that the whole tree is correct
<hyperair> guaranteed reasonably securely, as far as sha1 is concerned, that is.[
<eviljoel> Let me think on this for a second.
<hyperair> you can also verify the tag's signature (GPG)
<hyperair> which guarantees everything referenced by the tag
<hyperair> i.e. the commit pointed to by the tag, all of the commits in its history, and all of their tree states
<eviljoel> OK, I'm fairly familiar with gpg.  What command would I use to do that?
<hyperair> git tag -v
<hyperair> git tag -v v2.6.31, for example
<hyperair> again, everything's guaranteed by sha1 uniqueness
<hyperair> which is pretty secure. it's exceedingly difficult to find a sha1 collision, and even harder to find a valid git tree out of all the collisions
<eviljoel> I'm less familiar with git.  If I want the latest tag version, how do I get that?
<eviljoel> Alright, it seems to be 'git describe --abbrev=0 --tags'.
<eviljoel> Alright, so I'm not sure if this is going to work for my threat level.  There appears to be multiple people who sign the ubuntu tags.  If there is a large number of people signing ubuntu tags, that makes the verification process a lot harder.
<eviljoel> So far this appears to be the best way to get secure source:  https://help.ubuntu.com/community/Kernel/Compile#Option_B.29_Download_the_source_archive
<eviljoel> ...but it says right at the top that the source isn't up to date.
<eviljoel> How much out of date will it be?
<eviljoel> So, I'll try one more time because I have to leave soon.  How out of date is sudo apt-get source linux-image-`uname -r`?
<eviljoel> ...typically, not just right now.
<xperia> hi all. what ppa do i need to add on a 14.04 system to be able to fetch the 3.16 ubuntu kernel sources so i am able to rebuild it like this here => https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<xperia> I need to rebuild the ubuntu Kernel with reiser4 support for the Kernel version 3.15 or 3.16 to be able to run it on a 14.04 System
<zequence> infinity: Ah, sorry. Had not noticed. Will do that shortly
<cmagina> running into an issue with the insertchanges rule for a kernel branch i am working with where the command exits without error, but the changelog entry is empty
<cmagina> clearly something wrong with either my branch, environment, etc. just no idea what that could be as i am not as familiar as i would like with these tools
<rtg> cmagina, have you done a startnewrelease ?
<cmagina> rtg, yeah, the commit is there as well
<rtg> cmagina, do you have your branch pushed somewhere I can get at it ?
<cmagina> rtg, no, but i can push it
<cmagina> rtg, git://kernel.ubuntu.com/cmagina/trusty-xgene.git 3.13.0-35.62+lomond.1+pcidbg
<rtg> cmagina, maybe because it can't figure out your version scheme, but thats just a guess
<cmagina> rtg, ah, thanks for taking a look. guess i'll fill it out manually for now and ask dannf about it when he gets back
<zequence> infinity: Ok. Building..
<cmagina> does the ubuntu-trusty/master-next branch get turned into a deb anywhere for arm64 on a regular basis?
#ubuntu-kernel 2014-09-14
<alkisg> Hi, linux-hwe-generic doesn't exist in trusty. Is there any way to specify that "in all my Ubuntu LTS installations, I always want the newest hwe stack" ?
<mlankhorst> alkisg: no because switching between hwe stacks is a manual process
<mlankhorst> you can switch the kernel, but you would need to switch xorg-server too
<alkisg> mlankhorst: so what does linux-hwe-generic stand for?
<alkisg> When it's to be used?
<alkisg> E.g. what would happen if I installed that back in 12.04.2? It would install lts-quantal?
<mlankhorst> no idea.. try to find out I guess. :P
<mlankhorst> i guess it might be just kernel
<alkisg> hwe is just about kernel, yes, but I'm not sure when to use it
<mlankhorst> seems to be kernel only
<mlankhorst> there's no hwe stack for utopic yet, so I guess that's why that package does not exist yet
<alkisg> It would be nice for it to exist for documentation purposes though
<alkisg> linux-hwe-generic depends on linux-image-hwe-generic
<alkisg> linux-image-hwe-generic depends on linux-image-generic-lts-trusty
<alkisg> ...since it's "depends" and not "recommends" or something, I really wonder how that will work with point releases...
<alkisg> Or maybe hwe is only for the next lts kernel...?
<alkisg> And not for point releases?
<mlankhorst> theres no lts kernel for trusty yet
#ubuntu-kernel 2015-09-07
<Tehdastehdas> I have an ideological quarrel with Linux kernel development:
<Tehdastehdas> Lenovo ThinkPads are in my opinion let overheat by the kernel bullheadedly sticking to standard procedure instead of using a workaround known to help many computers having overheating problems: setting the fan to maximum speed using fan control "disengaged" mode. I present my case here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1491797 from a different angle from the original slow fan bug report filed 2011 here: 
<Tehdastehdas> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/751689 Result: won't fix: the assigned developer recommends to approach Lenovo with the problem, although it would be way easier to smarten up the kernel and get users to accept the kernel update than to have all affected users to fetch and install a BIOS update Lenovo hasn't even made yet. Yes, the root causes are Lenovo's faulty ACPI design and many laptop's barely suff
<ubot5> Ubuntu bug 1491797 in linux (Ubuntu) "Shuts down when supposed to suspend as a reaction to self-caused overheat, session lost" [High,Won't fix]
<ubot5> Ubuntu bug 751689 in linux (Ubuntu Precise) "[Lenovo Thinkpad x201s] Overheat due to slow fans when on 'auto'" [Critical,Confirmed]
<Tehdastehdas> icient cooling system, but they can be worked around via software in many ways (non-standard maximum fan speed and/or CPU throttling and/or intermittent suspending to cool down), so I think it should be worked around as default, because Ubuntu is commonly used on these faulty machines, and the users are suffering.
<apw> Tehdastehdas, ok.  This is the machine which you have drilled holes in the case of ?
<Tehdastehdas> yes, but I did drill the holes around the original intakes to avoid disturbing the designed flow pattern
<apw> Tehdastehdas, as I see the position, this specific machine is not representative of its kind (x201s are pretty common in our circles), and that therefore a general solution is not going to work here.  Did you try out using a specific thermald profile for this machine?
<apw> ~.
<diwic> wily is going to run 4.2, right?
<tjaalton> yes
<tjaalton> already is
<diwic> tjaalton, we probably want to backport the i915 -> hda patch set there too, then
<diwic> tjaalton, since that isn't in 4.2 
<tjaalton> and the maybe 60 other commits for skl, yes
<diwic> tjaalton, ok, fair point
<tjaalton> now that they're in linus' kernel
<apw> oh goody, 60 patches, you are making me _so_ happy
<tjaalton> I haven't counted
<tjaalton> but vivid just got >50 patches
<tjaalton> though some of it was sync to current 4.2
#ubuntu-kernel 2015-09-08
<Tehdastehdas> apw, I didn't get the part about the machine not being representative of its kind, as many machines in the original slow fan bug report comments are claimed to run their fans faster and CPUs cooler in the fan control disengaged mode. I haven't tried tweaking thermald, as reading this https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues , my thermal-conf.xml and its manual page I can't understand how to redefine fan 
<Tehdastehdas> speeds so that 'disengaged' mode would be the new highest speed.
<Tehdastehdas> "Currently, the Linux kernel thermal ACPI module implements these controls. So, based on the validity of configuration data, this can be a very efficient method for thermal controls. But, it was observed that many systems donât have this configuration data or have invalid data, preventing the kernel module from taking timely action." https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon
<Tehdastehdas>  Which channel should I go to for thermald support?
<rbasak> Is smb on holiday? Any idea when he's back?
<apw> rbasak, yes, and err ...
<apw> rbasak, is this about dpdk, if so arges may be in the loop
<Tehdastehdas> I wrote about the Lenovo slow fan bug to the thermal_daemon (thermald) mailing list.
<rbasak> apw: yeah, dpdk. Thanks. I wanted to clarify some bits about upstream's build system that smb would know, but I can look or wait until next week.
<apw> Tehdastehdas, sound like a plan
<apw> rbasak, arges was involved in deep review so if you have queries, do ask 
<jpds> apw: You seen https://askubuntu.com/questions/670106/igb-detected-tx-unit-hang ?
<apw> jpds, nope, kamal henrix a nice regression in stable for you ...
<henrix> apw: looking
<henrix> oh joy
<henrix> jpds: are you able to reproduce this igb bug?
<jpds> henrix: Nope, I saw some people in #ubuntu-server complaining about it
<henrix> jpds: ah, thanks.  i'll try to get a test kernel built (still looking at the bug).  i'll just add a link to that kernel in the bug (bug #1492146)
<ubot5> bug 1492146 in linux-lts-utopic (Ubuntu) "igb Detected Tx Unit Hang" [Undecided,Confirmed] https://launchpad.net/bugs/1492146
<jpds> henrix: Asked the person to join here
<henrix> jpds: cook, thanks
<bananapie> Is there a page somewhere that lists the differences between Ubuntu's kernel and vanilla kernel?
<rozie> I was hit by kernel bug http://askubuntu.com/questions/670106/igb-detected-tx-unit-hang can I expect it to be fixed in next kernel release?
<rozie> right now I downgraded to 3.16.0-46-generic (Ubuntu 14.04 LTS). have spare machine for tests.
<henrix> rozie: i'm looking at that bug (bug #1492146), and i'll try to have a test kernel built in a bit
<ubot5> bug 1492146 in linux-lts-utopic (Ubuntu) "igb Detected Tx Unit Hang" [Undecided,Confirmed] https://launchpad.net/bugs/1492146
<henrix> rozie: would you be able to test it, to see if it actually fixes the issue?
<rozie> henrix: which solution exactly?
<henrix> rozie: looks like a bad backport in one of the patches in the 3.16.0-48.64 kernel
<henrix> rozie: there were a bunch of hyper-v related patches in this kernel; the test kernel will simply revert them, as i suspect that one of these patches is incorrect
<henrix> (incorrect = bad backport)
<henrix> rozie: i've uploaded a test kernel here: http://people.canonical.com/~henrix/lp1492146/v1/amd64/
<henrix> rozie: i've also included in that URL the patches i'm reverting.  i believe the 'bad' one is the first one, so i had to revert them all :-/
<henrix> rozie: if you could give it a spin would be great
<henrix> rozie: i'll also add this URL (and request for testing) in the bug
<rozie> OK, installing http://people.canonical.com/~henrix/lp1492146/v1/amd64/linux-image-3.16.0-48-generic_3.16.0-48.64~14.04.1~lp1492146v1_amd64.deb and http://people.canonical.com/~henrix/lp1492146/v1/amd64/linux-image-extra-3.16.0-48-generic_3.16.0-48.64~14.04.1~lp1492146v1_amd64.deb right now
<henrix> rozie: awesome, thanks!
<rozie> booting... I have about 1 hour left, so it would be great if we manage to fix/test it in this time
<rozie> henrix: booted. looks stable
<henrix> rozie: awesome, thanks.  if you're not able to reproduce the issue with this kernel, then i guess you're done for now ;)
<henrix> rozie: we'll eventually respin this kernel again (probably today), and i'll eventually ask in the bug for people to re-test again before releasing
<henrix> (2 'eventually' in the same sentence...)
<rozie> I'll be probably available tomorrow around 9AM UTC
<rozie> feel free to give specific version to test. the good thing is I have spare machine and independent access ;-)
<rozie> if you need anything, I'm available for 45 min more today
<henrix> rozie: awesome, thanks.  i'll ping you if i have a final version ready tomorrow
<rozie> :-)
<jpds> rozie: Do you have an askubuntu account to update the page?
<rozie> jpds: I have lauhchpad, but noscript blocks CSS for askubuntu. works fine for ask.openstack
<jpds> Hmm
<rozie> I know, it's another channel thing ;)
<rozie> used another browser
<rozie> jpds: can you tak a look? any other info needed?
<jpds> rozie: I think henrix has an eye on the ball
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<willcooke> hi mjg59 - I was reading this the other day:  http://mjg59.dreamwidth.org/34868.html  -  did your patches get in to the kernel?
<mjg59> willcooke: Still working on reverse engineering the Intel driver so I can figure out the blacklisting
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<cristian_c> jsalisbury: hi
<jsalisbury> cristian_c, hi, I never got a response from upstream.  I'll ping them again and cc the bug
<cristian_c> jsalisbury: ok
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Sep 15th, 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. || Channel logs: http://irclogs.ubuntu.com/
<rtg> henrix, kamal: ad1ed2a9dd4c435d6a3ce470211db9a8d107c3e0 should be added to the 3.19 stable kernel
<henrix> rtg: wow! that patch has enough context to see the bug :)
<rtg> henrix, yeah, it seems like a no brainer
<kamal> rtg, henrix: jesus you're not kidding!  ack, I'll pick it up
<kamal> rtg, do we know when it got broken?
<rtg> kamal, the driver was added in 3.19, the locking fix came in 4.0
<kamal> rtg, good.  thanks.
<psivaa> cking: hello,
<psivaa> Not sure if you're still interested in health-check results in http://ci.ubuntu.com/smokeng/trusty/desktop/i386/20150908/13806/health-check/
<cking> psivaa, i'll just have a look...
<cking> psivaa, \o/, excellent!
<psivaa> cking: There were a couple of failures in the last couple of days and since we moved the hosts the VM installation takes place, we're wondering if the failures have anything to do with the VM host migration
<psivaa> cking: one of such failures is https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-amd64-smoke-health-check/321/artifact/utah-810-trusty-amd64_master.run_2015-09-07_12-09-29.yaml/*view*/
<cking> psivaa, are the failures still occurring?
<psivaa> cking: they appear to be 'flaky'. i.e a rerun passes
<cking> hrm, yep, the failure on the URL shown above is probably a sporadic memory allocation that skewed the rates
<psivaa> the failed ones on https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-amd64-smoke-health-check/ have all the same test failure, but as i said they pass on reruns
<cking> i'll eyeball those in a while, I've got some food waiting for me to be eaten..
<psivaa> cking: sure, we'll be happy to leave that to see if that settles down. Please feel free to ping us back if you think that the host migration being any reason
<cking> psivaa, let's see if it settles down, if not, then lets dig into it deeper
<psivaa> cking: sounds good
#ubuntu-kernel 2015-09-09
<cking> amitk, who do I sent patches to for idlestat nowadays?
<cking> *send
<amitk> cking: send them to sched-tools@lists.linaro.org list
<cking> ack, ta
<amitk> thank you
<cking> amitk, seems like my patch is stuck in the list's moderation queue
<amitk> cking: cleared the queue now. Surprising since I see you as subscribed to the list
<cking> amitk, i subscribed after I posted the patch
<amitk> cking: aah :)
<amitk> cking: and that might be the reason it didn't offer me the chance to whitelist your email id
<psivaa> cking: there have been a couple of instances of the same health-check failures, if  you're interested:
<psivaa> https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-i386-smoke-health-check/
<cking> psivaa, i'll peek at those tomorrow morning, thanks!
<psivaa> cking: ack, thank you
<cking> why is it we always get a minor glitch the day before we release fwts? at least the regular build recipe and regressions tests catch these
<apw> heh, always the way
#ubuntu-kernel 2015-09-10
<henrix> rozie: hi! i've just commented bug #1492146 about a new kernel available in -proposed
<ubot5> bug 1492146 in linux-lts-utopic (Ubuntu) "igb Detected Tx Unit Hang" [High,Confirmed] https://launchpad.net/bugs/1492146
<henrix> rozie: it would be great if you could check if that kernel fixes the issue
<rozie> gimme like... 15 minutes
<henrix> rozie: awesome!  thanks ;)
<rozie> henrix: can you give me direct link to packages? I see it's in the proposed, but would like to avoid adding repos
<henrix> rozie: here's the links:
<henrix> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-lts-utopic/linux-image-3.16.0-49-generic_3.16.0-49.65~14.04.1_amd64.deb
<henrix> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-lts-utopic/linux-image-extra-3.16.0-49-generic_3.16.0-49.65~14.04.1_amd64.deb
<henrix> rozie: not sure if at this moment you care about other packages (headers, for example)
<rozie> thx. I dont care about headers. just got lost in complicated Ubuntu repo structure ;/
<henrix> rozie: heh, no prob
<rozie> just kidding, but got use to Debian, as it's my primary OS and Ubuntu is... different
<rozie> but haven't found this kernel on packages.ubuntu...
<rozie> anyway, rebooting...
<rozie> looks fine at first glance, but let it work for 5 mins
<henrix> rozie: sure, not in a rush.  I really want to make sure the bug is fixed ;)
<apw> henrix, was that the wholesale revert ?
<henrix> apw: yep
<henrix> apw: 14 patches being revert
<apw> ouch
<apw> did the bug get shoved out of fix-released at the saem time ?
<henrix> we'll need to take another look at these backports.  and... i'm not sure i changed it to 'triagged' again (although i remember i commented on the bug)
 * henrix goes check
<apw> henrix, thanks ... i'd not want that to get lost as a result
<henrix> apw: no, iirc joe is currently working on that bug so he probably actually changed it back
<rozie> 523 packets transmitted, 523 received, 0% packet loss, time 526808ms - looks fine :-)
<henrix> rozie: awesome!  thanks for testing ;)
<henrix> rozie: would you please add a comment to the bug, and change the 'verification-needed-trusty' to 'verification-done-trusty' tag?
<henrix> rozie: (i can do that for you if you're busy)
<rozie> already commented, pls change tag
<henrix> rozie: cool, thanks
<henrix> infinity: fyi ^^
<LocutusOfBorg1> Hi, I don't remember who handles the virtualbox kernel modules
<LocutusOfBorg1> but virtualbox 5.0.4 is out, claiming full compatibility with kernel 4.2
<LocutusOfBorg1> you might want to sync changes
<apw> LocutusOfBorg1, sounds good, thanks
<apw> LocutusOfBorg1, mostly i do for what it is worth
<popey> Anyone noticed massive slowdown on 4.2? My desktop is pretty much unusable while doing IO
<popey> 15s to open a terminal
<tjaalton> i've noticed something similar, building a kernel and doing anything is very sluggish
<cking> popey, I'll sort out some testing against 4.2 and see what's going on
<cking> popey, what's your config in terms of system / CPUs/ HDD/SSDs etc
<cking> and what kind of I/O are you doing?
<rtg> tjaalton, you ought to be able to provide some numbers if you're doing builds. 
<rtg> that seems pretty deterministic
<tjaalton> numbers?
<popey> cking: i7 / one HDD (spinning rust) / 8GB RAM
<tjaalton> I have ivybridge, 240GB ssd, but home is on btrfs..
<popey> only thing it's doing is an rsync backup to another machine over gbe
<tjaalton> kernel trees on ssd
<popey> sandybridge cpu, ext4 filesystem
<rtg> tjaalton, build times with 4.1 v.s. 4.2 ?
<cking> why does my heart sink when btrfs is mentioned...
<popey> backup seems to be chugging along, load average is 4.5
<tjaalton> ah, well the build is fine I think, just that doing anything interactive at the same time is sluggish
<popey> no btrfs here :)
<tjaalton> cking: hehe
<cking> ok, let me do ext4 first as that's our default ;-)
<popey> thanks
<cking> np
<davmor2> cking: https://i2.wp.com/ak-hdl.buzzfed.com/static/2014-10/7/19/enhanced/webdr05/anigif_original-grid-image-18241-1412725925-4.gif
<cking> hrm
<davmor2> cking: just visualising the the heart sinking :)
<cking> ah, yes ;-)
<tjaalton> more specifically, my $HOME is on a four-disk btrfs HDD RAID
<tjaalton> raid10-ish
<LocutusOfBorg1> thanks apw 
<LocutusOfBorg1> apw, where are the sources for the module?
<LocutusOfBorg1> here? http://kernel.ubuntu.com/git/ubuntu/linux.git
<apw> LocutusOfBorg1, so we update the module directly from the binaries the dksm package produce
<apw> though right now i assume we ahve it patched locally
<LocutusOfBorg1> so you provide a .ko module?
<LocutusOfBorg1> thanks
<apw> yes
<apw> but we need the real dkms package updated, which i htink was what you were telling me i hsould (and will) do
<LocutusOfBorg1> I thought you were copy-pasting the sources in the kernel tree and providing a build during install :)
<LocutusOfBorg1> exactly, I guess this is the best way to do
<LocutusOfBorg1> like we do with vbox-dkms
<LocutusOfBorg1> having them inside the kernel is really awesome :)
<apw> we are indeed pasting in the sources, but i do that from the result of the virtualbox package making the source for the dkms package
<apw> if any of that makes any sense
<apw> yeah needed for some clouds apparently
<cking> popey, i've kicked of a range of file systems tests, i'll get back to you once they are complete (probably next week)
<cking> s/of/off
<popey> cking: super, thanks
<rul_> Hi. Old kernels aren't being autoremoved despite being marked as auto and not being in "APT::NeverAutoRemove"... any hint on how can I debug this issue? 
<rul_> debugging autoremove I can see this lines
<rul_> Following dep: systemtap:amd64 2.3-1ubuntu1 Suggests linux-image:amd64 , provided by linux-image-3.2.0-59-generic:amd64 3.2.0-59.90Marking: linux-image-3.2.0-59-generic:amd64 3.2.0-59.90, Curr=3.2.0-59.90, Inst=3.2.0-59.90
<rul_> it's like the old kernel aren't removed because they're suggested by systemap
<apw> those all do provides:linux-image .... infinity ^
<infinity> apw: systemtap's dep is bogus.
<infinity> "we recommend you have a kernel installed" is about the most useless dep I can think of.
<infinity> "Depends: computer".
<apw> yeah it cirtainly is ...
<apw> ok so we should get that ripped
<apw> rul_, can you file a bug against systemtap please and tell me the number
<infinity> rul_: To confirm, if you remove systemtap, do kernels autoremove happily afterward?
<infinity> apw: It's also possible that our provides is a bit overzealous there, and we should be providing virtuals like linux-image and linux-headers from the metapackages instead of the real packages.
<infinity> apw: But can't go back in time and fix all the old kernels to do that.
<apw> infinity, moving the provides to the to the meta-pacakge is an interesting idea
<infinity> apw: It would get us the behaviour we'd prefer if something did depend on one of those virtuals.  We don't want a one-off ABI-versioned package installed, we want the meta, so people actually get upgrades.
<apw> infinity, yes, seems appropriate
<infinity> apw: (I still think it's a bug for anything to depend on the virtuals anyway, but some stuff from Debian does, and it's not worth the delta to fix them all)
<apw> when rul_ gives me his bug, i'll file one off that for linux/etc to move them
<infinity> apw: Anyhow, only something we could fix for >= wily, since stable releases have tons of kernels with the provides already baked in.
<apw> infinity, right get it fixed before the next lts
<rul_> yup, I've marked systemtap package as auto and suddenly all old kernels can be autoremoved
<rul_> filling the bug
<rul_> #1494481
<apw> bug #1494481
<ubot5> bug 1494481 in systemtap (Ubuntu) "linux-image Suggests cripples old kernel cleanup" [Undecided,New] https://launchpad.net/bugs/1494481
#ubuntu-kernel 2015-09-11
<alkisg> Hi, I think I've found a bug in overlayfs, could someone please check that I'm not doing something wrong, before I file it upstream?
<alkisg> As root: cd $(mktemp -d); mkdir lower upper work root; truncate -s 4G lower/sparse; mount -t overlay -o workdir=work,upperdir=upper,lowerdir=lower overlay work; truncate -s 0 work/sparse; umount work
<alkisg> The error: truncate: cannot open âwork/sparseâ for writing: Value too large for defined data type
<alkisg> I.e. the truncate function call, fails on big files, when the underlying file system is overlayfs
<apw> alkisg, what you are doing looks valid to my eye
<alkisg> Thank you apw, should I send a mail to the unionfs kernel ML?
<apw> alkisg, to the maintainers of overlayfs in the first instance, as in whats in MAINTAINERS for fs/overlay
<alkisg> Thank you very much
<mjg59> alkisg: https://github.com/docker/docker/issues/11700 ?
<mjg59> We ran into that
<apw> alkisg, seems like a copy up issue, as it is failing in open, opening it for write (if i am reading the trace right)
<alkisg> mjg59: looking into that...
<alkisg> apw, it fails for 2200M, it succeeds for 2000M, but it takes a very long time to truncate it, like it's trying to copy the file contents which imho it shouldn't
<apw> alkisg, it is absolutly copying it up
<apw> as truncate is "open for write, then ftruncate(N) on the fd"
<mjg59> alkisg: Presumably failing at 2G
<alkisg> Right
<alkisg> Hmm so when I want to empty some files, `truncate -s 0` isn't really an efficient way to do it... :)
<alkisg> I thought the truncate function would special-case 0 there
<apw> alkisg, the problem is not truncate, but the fact to use it you have to open the file
<alkisg> Hmm and also overlayfs doesn't use blocks, lists etc, so it wouldn't be able to actually "truncate" a file in half without copying it first
<alkisg> I.e. mark the rest of the blocks as unused etc
<apw> alkisg, right, though at the time we open it all we are saying is "open this so i can scribble on the current contents"
<apw> and in that case all it can do is make sure it is on upper
<alkisg> Gotcha
<apw> that it fails on 2G+ is broken, but it will always be _slooow_
<alkisg> Right, so I'll change the ltsp code so that it doesn't use truncate, but the bug still needs to be reported upstream
<alkisg> I couldn't an official source for the maintainer though
<alkisg> I think it's miklos, but I don't see his name in overlay.txt...
<alkisg> s/an/find/...
<apw> it is miklos yes, the main MAINTAINERS file in the top level lists them all
<apw> alkisg, to: miklos cc:linux-unionfs
<alkisg> ty!
<alkisg> Reported to http://permalink.gmane.org/gmane.linux.file-systems.union/408 and fixed in LTSP, https://bugs.launchpad.net/ltsp/+bug/1494660. Thank you guys.
<ubot5> Ubuntu bug 1494660 in LTSP "Replace truncate with tee to avoid overlayfs issues with big files" [Low,Fix committed]
<apw> alkisg, i also see someone has worked up a fix for the fundamental issue, though if you can avoid the copy up ... all the better
<alkisg> We avoided it, but e.g. `useradd` fails on live booted PCs because it's using truncate (lastlog == sparse file of 3 GB on a system that uses LDAP)
<alkisg> So we'll keep an eye on that in case we find other side effects until overlayfs is fixed upstream
<apw> alkisg, right, i am saying someone on linux-unionfs looks to have a simple fix
<alkisg> I understood. Ah, could you give me the link?
<alkisg> Ah, a reply to mine, ok
<alkisg> :)
<psivaa> cking: hello, about that failing health-check test, (which passed in today's run btw) do you think it would be beneficial to retain the old host  for any debugging.
<psivaa> We're having to handover the machine to the IS, but can retain for another week
<cking> psivaa, i don't think we're going to gain much by keeping hold of the old host
<cking> so let it go
<psivaa> cking: ack, thank you
<TJ-> apw: ping re: cryptsetup
<apw> TJ-, i am blank, remind me
<TJ-> apw: You signed off a couple of recent package uploads; I was wondering if you're semi-maintaining it ?
<apw> i might :)
<TJ-> apw: I work with LUKS/dm-crypt/cryptsetup extensively, and there are a couple of related issues showing with Wily which lead to non-boot regresssions
<apw> TJ-, sounds bad
<apw> i think i just merged it, so if you want to change it thats all good
<TJ-> apw: do you have 5 minutes to discuss/bounce ideas?
<apw> sure go ahead
<TJ-> apw: I've used LUKS with keyscript= in crypttab for several years. The basic script simply takes the KEYFILE passed to it and reads it. That's worked fine with Upstart. Now, with systemd-cryptsetup, that is broken because it doesn't support keyscript.
<apw> TJ-, "you don't want to do it like that"
<apw> good old systemd and its "i do everything you should use and nothing you do" support
<TJ-> apw: systemd-cryptsetup does support finding/loading the keyfile directly, however, so if it doesn't require any special steps that will still work
<TJ-> apw: systemd-cryptsetup complains about unknown option keyscript= though, regardless. If the user takes notice of that and removes the keyscript= option from cryptsetup it breaks the initramfs cryptroot script causing failure to unlock te container with the rootfs
<TJ-> apw: Currently the cryptsetup initramfs hook script knows its a problem and will report "cryptsetup: WARNING: target LUKS_OS uses a key file, skipped"
<TJ-> apw: That doesn't help the user though. I'm wondering if we shouldn't have the script simply assume the crypttab 'initramfs' option and do the cryptsetup install to the intrd.img regardless, rather than having no cryptdisk support at all
<TJ-> apw: The hook script doesn't know if the LUKS slots may also contain a passphrase which the user can type instead of the key-file, but it does know cryptsetup is required to unlock the container with the rootfs in
<apw> TJ-, you mean we are keying off that command line option to work out what file to put in the initrd
<apw> TJ-, but systemd tells us to get rid of it?
<TJ-> apw: we're keying off the crypttab entry for the container, and not installing cryptsetup at all if there is a key-file defined but no kescript
<TJ-> apw: systemd-cryptsetup complains each time it sees 'keyscript=' which could lead to users (like me!) trying to tidy things up
<apw> TJ-, so i tend to agree if we know root needs crypt to unlock we should always install that
<apw> TJ-, even if it won't work, it definatly won't work without
<TJ-> apw: It can be over-ridden in crypttab using the 'initramfs' option, but its not obvious
<TJ-> apw: OK, I'll work up a patch and a bug report and let you know when its tested
<apw> thanks.
<apw> anything that gets them a step nearer to working is good, if root is in a container that needs it, it should be in the initrd even if we don't have enough info to actually open it
<TJ-> Yeah... with keyscript= it's not a problem, so for users upgrading they should be OK, but for new users it could be an issue
<TJ-> Getting the required support into systemd-cryptsetup is going to be a big job; upstream wants to use the kernel key-ring and the  PasswordAgents API
<apw> TJ-, whatever is hard for everyone i am sure
<TJ-> apw: makes sense, but a lot of work :)
<TJ-> PA means easy support for SmartCards and other devices withou hackish scripts
<TJ-> apw: got a fix in, cryptroot::get_device_opts() expands the existing  warning, recommends a pass-phrase, and doesn't return an error, so the device is included. "cryptsetup: WARNING: target LUKS_OS uses a key file, but no keyscript is set. Please ensure there is also a typed pass-phrase set"
<jdstrand> cking: thanks for the super-quick turnaround for thermald! :)
<cking> jdstrand, no problem, I had the fix already,so it was a no-brainder
<cking> *brainer
 * jdstrand nods
<jdstrand> still though-- very nice :)
<jdstrand> cking: hope you enjoy your weekend :)
<cking> cheers, thanks, you too
<cking> jdstrand, and thanks for testing it :-)
<jdstrand> I think it was literally the least I could do considering the rapid turnaround :)
<jdstrand> but, you're welcome :)
<TJ-> apw: There are other similar bugs (e.g. bug 1487127) I'll squash whilst I'm at it, so they can be rolled up into one update. This issue is bug 1494851
<ubot5> bug 1487127 in cryptsetup (Ubuntu) "cryptsetup preventing proper boot swap AND root on crypt device together" [High,Triaged] https://launchpad.net/bugs/1487127
<ubot5> bug 1494851 in cryptsetup (Ubuntu) "initramfs cryptroot hook script doesn't install cryptsetup if keyfile but no keyscript" [Undecided,In progress] https://launchpad.net/bugs/1494851
#ubuntu-kernel 2015-09-13
<dsmythies> It seems the mainline PPA kernel 4.3RC1 compiles failed. It seems that kernel compile now needs the libssl-dev package to be installed. Once I installed that package my compile of kernel 4.3-rc1 completed, albeit with a ton of dpkg-genchanges and "Use of uninitialized value" warnings at the end. 
<bkero> Heya guys. I'm trying to get the 4.3rc1 mainline kernel. The build script is broken. It's expecting some openssl headers to be installed it looks like: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3-rc1-unstable/BUILD.LOG.amd64
<dsmythies> bkero: You were not in the room when I wrote earlier. You need the libssl-dev package installed to compile now. Also instead of compiling with "deb-pkg" using "bindeb-pkg" works a bit better, but I still get 532 lines of crap at the end and the .changes file that I do not want.
<bkero> dsmythies: I usually just grab the debs and install those -- not compile myself
<bkero> dsmythies: possible to fix the build server? :)
<dsmythies> I do not know anything about the build server. I just stopped by this IRC channel after having grief this morning, and baiscally finding what you found also.
<bkero> ah ok
<dsmythies> bkero: If you are in a hurry for it, I could drop a built amd64 4.3-rc1 on my web site for you.
<bkero> Nah, i have one. Thanks though.
<dsmythies> Commit 3716001bcb7f5822382ac1f2f54226b87312cc6b does the messing around with the deb-pkg option and introduces the bindeb-pkg build option as "the old way". Does anybody know why the bindeb-pkg option now introduces the change file. I ask becuase maybe I don't know somrthing about the bigger picture. 
<dsmythies> I am suggesting that in scripts/package/builddeb this stuff:
<dsmythies> +else
<dsmythies> +       dpkg-genchanges -b > ../${sourcename}_${packageversion}_${debarch}.changes
<dsmythies> +fi
<dsmythies> shouldn't be there.
<bkero> dsmythies: hey, could you throw those debs for 4.3.0-rc1 up somewhere? :)
<dsmythies> bkero: O.K. give me a few minutes. (and by the way, my upink data rate is not great, so be prepared for a snooze while you wait.)
<bkero> dsmythies: Don'tworry about it, compiling my own now :)
<bkero> THought it would save me some time, but I decided to do it myself because I need a few new config options.
<dsmythies> ... Oh. O.K. Report back if your compile is O.K. Mine was, and I have been running it for over 5 hours now (but didn't stress it yet).
<bkero> I'm sure it'll be fine. Just need to get libssl-dev on the build servers so others can benefit.
#ubuntu-kernel 2016-09-12
<om26er> Hi! Where shall I report bugs for the RPi kernel in Ubuntu ? Apparently the kernel does not enable `CGroup CPUset controller` and `CGroup pids controller` this is needed for LXD container resource control
<apw> om26er, against the linux-raspi2 package, and let us know the bug number here
<om26er> apw, I reported the bug: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1622655 sorry for missing logs, reported it from the desktop.
<ubot5> Ubuntu bug 1622655 in linux-raspi2 (Ubuntu) "Enable CPUset and pids CGroup controllers for RPi kernel" [Undecided,New]
<om26er> apw, on a slighly different note, what are the plans for linux 4.6 update for the Pi kernel ?
<apw> om26er, i am assuming we will follow our master on that, we are working on 4.6 and 4.8 for that
<om26er> apw, you mean whenever its updated in yakkety(or +1), the RPi kernel will be updated as well ?
<apw> om26er, i mean it should be being looked at, and happen sometime after master updates
<rtg> om26er, we already have a rpi2 v4.8 based kernel in ppa:canonical-kernel-team/ppa
#ubuntu-kernel 2016-09-13
<ogra_> rtg, i rememebr we used to have a discussion about crda in the ubuntu-core snap/rootfs ... which resulted in me removing it there ... do you remember the reason ? 
<ogra_> (i'm just doing a seed cleanup and the package came back ... )
<ogra_> apparently wlan workks without it on the pi3 and dragonboard ... 
<apw> ogra_, is that safe ?  given that gives you information about what is legal in your juristiction ?
<rtg> ogra_, well, crda is only required if the device has non-firmware based wifi. sforshee is probably a lot fresher on the topic these days.
<ogra_> apw, i dont know ... happy to keep it ... but irc there was a reason why we dropped it 
<ogra_> seemingly my two boards that have onboard wlan worked before it came back 
<ogra_> it doesnt seem to make a difference in functionallity 
<apw> ogra_, you are in a location with quite a wide set of frequencies ... dunno ... i don't recall the original discussion so ...
<ogra_> if it makes sense to have it i'll happily keep it ... if it is just unused ballast it doesnt mmake sense though 
<rtg> ogra_, it is certainly in use for those wifi adapters where the protocol stack runs on the host CPU
<rtg> wireless-regdb is still getting patches and being maintained by sforshee
<ogra_> like intel ?
<rtg> oglike intel
<rtg> ogra_, ^^
<ogra_> ok
<ogra_> that makes snese then 
<ogra_> enough for me to keep it 
<ogra_> (i guess the NUC guys will actually like to have it available then :))
<trippeh_> the firmware-based ones I've seen also uses crda and wireless-regdb by intersecting the OS provided tables and the firmware ones.
<trippeh_> I guess so it is possible to introduce new restrictions without a fw update.
<trippeh_> at least ath9k does this
#ubuntu-kernel 2016-09-14
<mequarks_> anyone: does freenode host a proper channel for ubuntu core ("snappy")?
<greg_> Howdy
<greg_> I see a lot of oopses when disconnecting my webcam with 16.04. Where can i report this and how ?
<apw> greg_, as that is likely kernel related i would start by reporting a bug against the ubuntu kernel after the oopses have occured (run ubuntu-bug linux)
<horms> I'm wondering if this is an appropriate place to ask about linux-stable patches being included in Ubuntu Kernels. In particular the 3.13.0 kernel for Trusty
<apw> horms, ask away
<horms> I have some PCI quirks and IDs added by patches which are in mainline since v4.5. I recently asked for them to be backported to linux-stable as far back as v3.10. Most of the relveant linux-stable maintainers have done so. I am now wondering if/how they might migrate into 3.13.0 for Trusty as this turns out to be a particuarly important kernel for the hardware in question.
<rtg> horms, send a request for inclusion to kernel-team@lists.ubuntu.com
<horms> ok, can do. thanks
<apw> though i assume as we still seem to be pulling in stables for trusty that it would end up there at some point
<horms> right, that was my assumption. sooner would certainly be better than later for us.
<rtg> I can never remember what are the actively maintained stable kernel versions
<apw> if we are going to expedite them before a stable is pulled we will need a bug against the kernel anyhow
<apw> with the details in
<horms> ok, i can file a bug if that is needed
<horms> 3.13 is not maintained by mainline. 3.14 is eol. 3.12 and 3.16 are the closest releases to 3.13 that are maintained by mainline
<rtg> horms, if the patch is already staged for stable, then directly requesting it likely won't get it published any sooner.
<horms> ok
<horms> that is fine
<horms> i'm wondering if there is some way to predict when it might be pulled in from stable
<rtg> horms, however, if 3.13 isn't maintained, then direct requests are the only way to get a patch included
<horms> oh, ok
<horms> that is clear enough
<apw> isn't that the one debian is now maintaining ?
<horms> I'm not clear on who is maintaining which mainline kernels
<horms> (though i should probably make a list :)
<rtg> horms, kernel.org has a list of stable and longterm kernel versions
<horms> Yes, I am looking at it now. I just meant I wasn't sure who was maintaining each item on that list.
<rtg> horms, all stable releases come through git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
<horms> Right. What I meant was that I believe different individuals are responsible for different branches of that tree. Greg KH does some. Jiri Slaby does or at one stage did another. I guess its not particularly important to this discussion.
<horms> Thanks for answering my questions. I'll go ahead and arange a bug report and email request.
<bdmurray> rtg: bug 1620525 seems to be about yakkety but you mentioned a xenial kernel version?
<ubot5> bug 1620525 in linux (Ubuntu Yakkety) "sbuild with overlayfs fails in yakkety" [Critical,Triaged] https://launchpad.net/bugs/1620525
<rtg> bdmurray, they are the same kernel, to date Xenial kernels are simply pocket copied to Yakkety. We have not migrated to 4.8 just yet.
<bdmurray> rtg: okay, got it
<elmo> hey - on a brand new laptop I'm getting MCE events due to the CPU getting too hot - this may be a dumb question - but is that in any way expected?
<elmo> (it's a lenovo T460s, if it matters - running Ununtu 16.04)
<elmo> Ununtu?  Also, Ubuntu
<stgraber> elmo: I'd very strongly recommend you run a kernel that's a bit more recent than 4.4 on a Skylake system
<stgraber> elmo: I'm on the 4.6 kernel that briefly went into yakkety-proposed on mine and it's allowing the package to go into much deeper sleep states than the 4.4 kernel did
<elmo> uh
<elmo> OK
<elmo> is there a 4.6 I can install on 16.04 easily?
<elmo> also, not being funny, but if it's that bad, shouldn't we be fixing it for everyone?  (I appreciate that may not easy)
<stgraber> elmo: you may also want to update your firmware as they fixed a bunch of power management issues in there recently-ish
<elmo> stgraber: does that require Windows?
<stgraber> elmo: nope
<elmo> OK - I'll look into that, thanks
<rtg> elmo, you could also try lts-yakkety 4.8.0-8.9 in ppa:canonical-kernel-team/unstable
<stgraber> elmo: grab the .iso from lenovo, run geteltorito against it, run losetup -a on the output, mount /dev/mapper/looopXYZ somewhere, and copy the content to a USB stick, then reboot and boot frrom it
<stgraber> in my case I don't even bother with the USB stick and just copy the FLASH directory and the .EFI to /boot/efi and add a temporary boot entry with (efibootmgr), but that's because messing with EFI is easier for me than finding a usb stick :)
<elmo> stgraber: thanks, that's super helpful and will avoid a lot of flailing
<elmo> rtg: will do
<stgraber> elmo: what MCE message do you see in dmesg? just going to grep on mine to see if I'm seeing anything like it
<stgraber> rtg: I actually just grabbed that one and was going to give it a try, see what powertop thinks of it :)
<elmo> stgraber: https://pastebin.canonical.com/165584/
<elmo> err, right, sorry this is a public channel
<rtg> stgraber, its getting close to what we're gonna release. I'm just awaiting some apparmor bits from jjohansen
<elmo> http://paste.ubuntu.com/23179449/
<rtg> we're still a couple of weeks from getting it into proposed
<stgraber> elmo: hmm, so I'm still seeing this on the 4.6 kernel, though I've got events = 1 instead of events = 210, not sure that qualifies as much better though :)
<stgraber> elmo: would also be interesting to know what's actually happening to the CPU, whether it was in non-turbo and got slammed or whether it was actually running at turbo speed and was just forced out of it because of heat
<elmo> stgraber: hmm, I'd have to be watching htop/powertop at the time it fires to tell right?
<stgraber> elmo: yeah, cking may have some magic script to log frequency changes in his crazy testsuites though. Otherwise, you'd need to watch cpuinfo or something to see what frequency it's running at...
#ubuntu-kernel 2016-09-15
<india_lima> hey, I'm experiencing an issue that I think might be a kernel bug, and I just reproduced it using the latest upstream mainline kernel... Should I still file a ubuntu-kernel bug report?  Or just file one directly at bugzilla.kernel.org?
<Guest_84854> allah is doing
<Guest_84854> sun is not doing allah is doing
<Guest_84854> moon is not doing allah is doing
<Guest_84854> stars are not doing allah is doing
<Guest_84854> planets are not doing allah is doing
<Guest_84854> galaxies are not doing allah is doing
<Guest_84854> oceans are not doing allah is doing
<Guest_84854> mountains are not doing allah is doing
<Guest_84854> trees are not doing allah is doing
<Guest_84854> mom is not doing allah is doing
<Guest_84854> dad is not doing allah is doing
<Guest_84854> boss is not doing allah is doing
<Guest_84854> job is not doing allah is doing
<Guest_84854> dollar is not doing allah is doing
<Guest_84854> degree is not doing allah is doing
<Guest_84854> medicine is not doing allah is doing
<Guest_84854> customers are not doing allah is doing
<Guest_84854> you can not get a job without the permission of allah
<Guest_84854> you can not get married without the permission of allah
<Guest_84854> nobody can get angry at you without the permission of allah
<Guest_84854> light is not doing allah is doing
<Guest_84854> fan is not doing allah is doing
<Guest_84854> businessess are not doing allah is doing
<Guest_84854> america is not doing allah is doing
<Guest_84854> fire can not burn without the permission of allah
<Guest_84854> knife can not cut without the permission of allah
<Guest_84854> rulers are not doing allah is doing
<Guest_84854> governments are not doing allah is doing
<Guest_84854> sleep is not doing allah is doing
<Guest_84854> hunger is not doing allah is doing
<Guest_84854> food does not take away the hunger allah takes away the hunger
<ogra_> !ops
<ubot5> Help! lamont, zul, T-Bone, mdz, or jdub
<ogra_> oh, fun
<ogra_> apw, ^^ why are you not on that list ? 
<Guest_84854> water does not take away the thirst allah takes away the thirst
<Guest_84854> seeing is not doing allah is doing
<Guest_84854> hearing is not doing allah is doing
<Guest_84854> seasons are not doing allah is doing
<Guest_84854> weather is not doing allah is doing
<Guest_84854> humans are not doing allah is doing
<Guest_84854> animals are not doing allah is doing
<Guest_84854> the best amongst you are those who learn and then teach quran
<Guest_84854> one letter read from book of allah amounts to one good deed and allah multiplies one good deed ten times
<Guest_84854> hearts get rusted as does iron with water to remove rust from heart recitation of quran and rememberance of death
<Guest_84854> heart is likened to a mirror
<Guest_84854> when a person commits one sin a black dot sustains the heart
<Guest_84854> to accept islam say that i bear witness that there is no deity worthy of worship except allah and muhammad peace be upon him is his slave and messenger
<Guest_84854> read book http://www.fazaileamaal.com
<ogra_> phew ... over
<henrix> yeah, now lets all open that link
<henrix> :)
<ogra_> haha
<ogra_> well, we really need to update this ops list 
<henrix> yeah, i thought apw was on it
 * ricotz hopes for merged 4.4.20/21 for xenial
<henrix> ricotz: nop, those 2 stable releases have not been applied to xenial git tree yet
<ricotz> henrix, that was my point ;)
<henrix> ricotz: well, there's a pull request in the ubuntu kernel mailing-list for 4.4.20.  so that one won't probably take too long to be in
<ricotz> henrix, I see, should be useful to sync i915_bpo with 4.7.4
<ricotz> tjaalton, hi, ^
<rtg> dannf, linux 4.8.0-9.10 in ppa:canonical-kernel-team/unstable with your config changes.
<danielthebague> Does anyone know if the ralink rt3290 wireless adapter will be supported in the next stable release?
<rtg> danielthebague, it is reference in 4.8, so I would assume so. In that case support for that device will be released in 16.10
<eipi10> i just installed ubuntu mini 14.04 and then lxde.  the OS is upgraded to 14.04.5, but the kernel is still 3.13-95.  earlier, I installed the same 14.04 ubuntu mini.iso but with Lubuntu-minimal desktop during the installation, and afterwards, while doing the standard updating/grading, the kernel bumped up to 4.2... Linux-generic is installed.  What am I missing?
<eipi10> pls
<apw> eipi10, the kernel stream is set by the base install, even when basefiles gets updated and so the nominal os version is uppped
<apw> eipi10, you have to opt into the hwe kernels explicitly
<eipi10> ah, hardware enabled
<eipi10>  linux-hwe-generic
<eipi10> ?
<eipi10> yep..ok.  thanks!
<rtg> eipi10, linux-generic-lts-xenial in your case I think
<eipi10> thanks.
<eipi10> btw, do you have an opinion as to opting for 14.04 instead of 16.04.  Is that ridiculous?
<rtg> that depends on the user space features you want. 14.04 is still well supported.
<eipi10> yeah...kinda of a dumb question considering you have no idea what's going on on this end.
<eipi10> cheers
<apw> generally you want the newest base which will well for you, to get the maximum longevity
<Stillinthepub> Is there a wirelles driver for the ralink rt3290 in the latest stable kernel release
<_ami_> i have been trying to write driver for  a usb based gpio i/o expander. i able  to create gpio at host side.. the only issue is to attach irq to these pins. i know i need to create irq_chip for the gpio_chip.
<_ami_> i called gpiochip_irqchip_add() and on call to request_irq, i can see entry of new irq in /proc/interrupts.
<_ami_> but the ISR in not getting called when event occurs
<_ami_> what could be the reason?
<apw> one assumes you need to program the expander chip with the interrupt information, i assume you have done tha
<_ami_> apw: my hardware is based on avr (vusb)
<_ami_> apw: i wrote a demo driver which emulates GPIOs : 
<_ami_> https://github.com/amitesh-singh/ldd/blob/master/platform/gpio-irqchip/gpio-irqchip.c
<_ami_> gpio accedd device: https://github.com/amitesh-singh/ldd/blob/master/platform/access-gpio-modern/access-gpio.c
<_ami_> access*
<_ami_> i just wonder why irq handler is not called whenever i do echo 1 > or o > value in /sys/class/gpio/gpio<N>/  ?
<_ami_> on cat /proc/interrupts
<_ami_>  36:          0          0          0          0  irq-gpio   0  platform-gpio-device
<_ami_> but the IRQ functions nver get called on setting gpio state to 0 or 1
<_ami_> do i need to raise or wake up irq whenever gpio is set?
<_ami_> apw: is it a problem with irqchip object setup?
<apw> oh then i would expect you to have to take explicit action when you handle the write yes
<_ami_> apw: how to do it?
<_ami_> its not softirq
<_ami_> which api to use to raise irqhandler explicitly ?
<apw> _ami_, can say i know sorry
<_ami_> ok, np.  thanks
<tjaalton> huh, how come linux-firmware isn't backported to older lts's as-is?
<tjaalton> anyway, interesting that a dvb stick works fine on xenial but not on trusty with xenial kernel and xenial firmware
<tjaalton> claims it can't find the fw
<tjaalton> oh, that's only loaded when the device is actually being used, which my xenial box didn't do
<tjaalton> and that fw is not in linux-firmware
<tjaalton> dvb-demod-si2168-b40-01.fw
<tjaalton> for pctv triplestick
<elmo> rtg: http://paste.ubuntu.com/23183199/
<rtg> elmo, whoa, that seems really broken. guess I'll go fix that.
<rtg> I was kinda sure I _had_ tested that.
<rtg> elmo, I should point out that you won't get a signed kernel until it gets into proposed (linux-signed-generic-lts-yakkety)
<elmo> rtg: oh, err - so I'll need to turn off secure boot then?
<rtg> yes
<elmo> rtg: OK
<rtg> elmo, doh! The LTS kernel is still building, so of course there is nothing to install. I uploaded a new version earlier today.
<elmo> rtg: aha
<elmo> rtg: will retry tomorrow then, thanks
<rtg> elmo, though it does seem strange that the meta package published before all of the dependencies were done building.
<apw> elmo, that is because the older metas are missing build depends on the binaries
#ubuntu-kernel 2016-09-16
<_ami_> apw: calling generic_handle_irq() explicitly on GPIO does the job which i wanted. 
<_ami_> :)
<apw> _ami_, cool
<_ami_> apw: obviously this is the way. emulation of hardware irq to software irq to linux. gutted to not understand this at first place. :/
<tjaalton> does the meta package get an update for sru only when the kernel is migrated to -updates?
<apw> tjaalton, the meta-package migrates with the kernel as it moves -proposed to -updates
<tjaalton> sure but does it get bumped for the abi only once or with every kernel abi change?
<tjaalton> one guy claims that xenial-proposed didn't have an update for linux-generic..
<tjaalton> yeah it's there
<tjaalton> should've just checked myself :)
<apw> tjaalton, -meta gets updated for any ABI change in linux, and copies out to -proposed with the kernel as a matched pair always
<tjaalton> yeah, thanks
<tjaalton> for confirming
<apw> np
<rtg> elmo, 'apt-get install linux-generic-lts-yakkety' works a little better now that things are done building
<elmo> rtg: thanks, will try
<apw> rtg, that reminds me you commiteed that "use src_pkg_name in udebs" thing to yakkety ...
<apw> rtg, that can't be on the main branch else it breaks the derivative kernels, that is an lts-foo only patch, and so has be carried on those explicitly
<rtg> apw, hmm, I guess none of the derivatives build udebs this far. Perhaps we could modify the patch so that it works on mainline ?
<rtg> thus far*
<apw> we'd only notice when d-i is built as it is only in the name of the linking package to that
<apw> it won't break the linux-raspi2 for instance, just any d-i respin we did for that
<apw> rtg, and yes, prolly the right thing to do is make that do some kind of if on src_pkg_name and if it is linux-lts-* then use that, else linux
<apw> on the master branch, but in the past we have just carried it on the linux-lts-X branch and been happy
<rtg> apw, I think this regression appeared when we adopted the modern d-i layout for kernel-wedge. This is the first I've encountered this particular udeb generation bug.
<apw> rtg, the src_pkg_name thing, or the one i just fixed
<apw> the one i just fixed was introduced by me in the rejig 
<apw> the src_pkg_name thing has been done to all the trees up to now as far as i know
<apw> its nothing to do with the bit which kernel-wedge plays with
<apw> rtg, in lts-wily for instance that change is squashed into "UBUNTU: [Packaging] Wily LTS backport"
<rtg> apw, look at Precise, commit 2fcd9ea38097d1d27837b7a407d3f264e2cf4c7c. Looks like henrix ran into the same problem independently.
<rtg> apw, nm, I was on the wrong branch
<apw> rtg, we had a variety of messes with that, one has the default the other way and alllll the derivates have the reversing patch
<apw> but it is only lts-foo that cannot use the approved linux-<thing>-flavour form because it annoyingly duplicates the flavour names
<apw> so it is logical for that exceptional branch to carry the exception, or as we said earlier to bodge it in master using the name prefix
<rtg> apw, I'll work on bodging it so we don't have to remember to port it to every LTS kernel going forward.
<apw> rtg, fine with me
<GhostLyrics> We bought a new machine, installed 16.04 and our software setup and now our hardware RAID controller refuses to work after ~3-4 days of uptime with kernel messages similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703356
<ubot5`> Debian bug 703356 in src:linux "megasas: Failed to alloc kernel SGL buffer for IOCTL (ref.#688198)" [Important,Open]
<GhostLyrics> So, what do I do? Wait and hope for this to be fixed? Downgrade to 14.04.X since I don't see if my RAID is healthy when running 16.04?
<GhostLyrics> not the best question or wording, I know, but that bug has been open for 3 years 
#ubuntu-kernel 2017-09-11
<girlielt> hello
<girlielt> How do I make by own kernel, and load it?
<girlielt> where are the tools
<girlielt> is anyoen here?
<girlielt> ???????????
<girlielt> ??????????????                                                          
<girlielt>                                                                                                                                                                                                                                                                                                                                                                                                
<girlielt>                                                                                                                                   
<girlielt>         
<girlielt>    
<girlielt>      
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>   
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>  
<girlielt>                                                                                                                                                                                                                                                                                                                                                                                               
<girlielt> cachio: ?
<girlielt> are you there
<girlielt> I know you are there
<girlielt> so speck up
<cachio> hi
<cachio> girlielt, what do you need?
<girlielt> cachio: I need to fuckk you
<girlielt> NOW
<jjohansen> sforshee: the current iteration of LSM stacking patches are http://kernel.ubuntu.com/git/jj/ubuntu-artful.git/log/?h=lsm-stacking  I know there are some revisions coming but with plumbers and LSS this week I don't expect them for a while
<sforshee> jjohansen: you want those pulled into artful?
<jjohansen> sforshee: if we can delay a little bit that would be good, but you might want to start playing with them on your end
<jjohansen> I am hoping to get a better feel of things this week, at plumbers and LSS
<jjohansen> and we can make a call after that
<sforshee> jjohansen: sounds good. I'll be a plumbers too.
#ubuntu-kernel 2017-09-12
<tjaalton> shouldn't overlayfs still be available on 4.10? my schroots on xenial don't work because it says "unknown filesystem type 'overlayfs'"
<tjaalton> or is it called 'overlay' now
<tjaalton> changing the chroot config seems to work
<smb> tjaalton, I think I vaguely recall something about name changing... but then there is a lot of things changing all the time. Guess if it works for you, it must be that
<tjaalton> okay, must be that then
#ubuntu-kernel 2017-09-13
<lamont> 4.12.0-13 -- is it a bad thing that the block device driver throws illegal opcode oopses?
<lamont> paste.ubuntu.com/25524681
 * lamont will file a bug in the morning
<FurretUber> Hi, I have installed the kernel version 4.13.1 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.1/ but it has many errors on my notebook. It wouldn't turn off or suspend and dmesg messages like https://pastebin.com/Qu7FEUvH appeared. I rebooted to kernel 4.10.0-33
<FurretUber> "Rebooted" like pressing the power button because NetworkManager and wpa_supplicant never allowed it to turn off
<FurretUber> I was using the mainline kernels because my notebook has power management problems. It is Skylake but the package C state never goes higher than 3
<FurretUber> As a consequence, the battery don't last more than 12 hours suspended, while on Windows 10 it don't use even 1% of battery in 12 hours
<s10gopal> hi
<s10gopal> anyone online ?
<mightyiam> Hey, kernel team. Thank you for awesome work. I daily drive your work. I came here to ask whether you could consider backporting a patch that'll let me use my graphics card properly, without disabling acceleration with `nomodeset`. This nouveau mailing list thread should explain it: https://lists.freedesktop.org/archives/nouveau/2017-August/028730.html . And here is my log: http://paste.ubuntu.com/25529150/ .
#ubuntu-kernel 2017-09-14
<Gray> Hello
<Gray> May I ask why I can still launch kernel that build by myself when enabled secure boot?
<Gray> I boot from shim,grub2 to kernel.
<Gray> And I am sure I have enabled secure boot from BIOS menu.
<Gray> I have checked the BIOS would block unsign shim.efi. And I also checked shim would block the unsign grub2.
<alex_hoh> have you import your public key to DB or MOK?
<Gray> I don't do that. 
<Gray> So I should not entry to OS.
<Gray> But I still entry to OS that build by myself.
<Gray> What's the problem with that?
<Gray> By the way, who is familiar with Chongqing city in China?
#ubuntu-kernel 2017-09-15
<LocutusOfBorg> hello apw, a new virtualbox is out :)
#ubuntu-kernel 2017-09-16
<ircsri> Hi kernel experts, can someone help me resolve an Nvidia graphics driver issue with 16.04 LTS recent kernel upgrade. Here's what I tried from the community: https://ubuntuforums.org/showthread.php?t=2369833&page=2 
