#ubuntu-kernel 2005-10-17
<dilinger> fabbione: ping
<dilinger> fabbione: i'm off to boston for a few days
<dilinger> fabbione: try not to break the sunfire ;)
<mkrufky> goodbye all ... 
<dilinger> fabbione: worst case, i can have my roommate restart it, but it'll be a pain, and turnaround time will probably be slow (he gets home late)
* netjoined: irc.freenode.net -> brown.freenode.net
<fabbione> dilinger: i will try :)
<zul> morning
#ubuntu-kernel 2005-10-18
<fabbione> hey BenC 
<johnm> Just curious about something. Do any of you guys use keychain?
<fabbione> keychain?
<\sh> the gentoo keychain tool?
<fabbione> what's that?
<johnm> keychain was originally written years ago. Think drobbins did it. I had a hand in changing it, and recently it's changed a load more as well. it's a keychain/agent tool. Awesome for gpg-agent and ssh-agent.
<fabbione> i don't
<johnm> makes life a LOT easier when dealing with ssh/gpg keys.
<johnm> Wondered if anyone used it :\
* \sh never used it even during his gentoo days
<fabbione> johnm: i prefer to do it manually
<fabbione> i don't like automatic management of my keys
<Mithrandir> ssh-agent isn't exactly much overhead anyway.  Log in, run ssh wherever and have the keys stored in the agent.
<johnm> fabbione: I assume you dont scp/ssh/sign a load of stuff in one go? ;)
<johnm> Mithrandir: nah your right., the only thing is adding the keys automagically etc.
<fabbione> johnm: i do.. i just don't use these agents
<Mithrandir> johnm: ssh='ssh-add -l > /dev/null 2>&1 || ssh-add ; \ssh'
<Mithrandir> does that for me.
<johnm> Anyways.. just a question. Was curious about something related.
* fabbione did sign hell of a lot of keys
<johnm> fabbione: gpg-agent is a godsend when it comes to 500+ file signoffs.
<fabbione> http://keyserver.kjsl.com/~jharris/ka/2005-10-02/top50table.html
<johnm> fabbione: I can't imagine typing passwords win 500+ times at once ;)
<fabbione> <- number 24
<johnm> s/win/in/
<fabbione> johnm: that's why you use other methogs
<fabbione> methods
* \sh looks forward to ubz..
<Mithrandir> johnm: why do you sign 500 files?
<johnm> Mithrandir: I could go into it, but it'll probably start a flamewar ;).. Basically.. every actual signing is part of a seperate process. The signing off is done to validate the security of a Manifest.
<\sh> ah..ebuild process
<Mithrandir> johnm: I'd probably just use my smart card then.  Punch the code and it's valid until I pull the card out of the reader.
<fabbione> johnm: we are not THAT religious
<fabbione> but if it is used for gentoo release, it must be crap
<fabbione> :P
<johnm> Mithrandir: I've done that before.
<johnm> fabbione: heh.
<johnm> Funnily enough I properly watched Shuttleworths talk at debconf
<johnm> it's actually quite surprising how similar all the camps are, but because of misconceptions of the way people think/act it brings this kind of segregation.
<johnm> The release process is nothing like I stated.
<johnm> re: gpg signing.
<\sh> fabbione: lol..don't mention this on #gentoo-dev ,)
<fabbione> johnm: you are talking to ex crux maintainer :)
<fabbione> johnm: really.. i did try everything out there without preconcetions
<fabbione> but i still like to kid about stuff
<fabbione> hence the ":P"
<johnm> Picked up on it :) - Was just on my mind this morning anyways.
<johnm> tbh...
<fabbione> johnm: i mean.. i am even REDHAT CERTIFIED ENGINEER!!!
<johnm> Gentoo devs in many cases hate gentoo users.
<\sh> johnm: social problems will never be solved with technical things
<johnm> fabbione: lol, you dont want to know what I think about that! positive I suppose tho ;)
* fabbione is not happy about that, but it still shows on google
<\sh> fabbione: u paid money for it?
<fabbione> \sh: not a single penny...
<fabbione> my company did :)
<fabbione> not Canonical of course
<fabbione> one i was working for before
<johnm> Anyone recommend a good podcast app?
<fabbione> johnm: there is one positive thing about the RHCE
<johnm> (gtk2)
<fabbione> the coffee mug you get at the end is pretty good :)
<johnm> fabbione: lol.
<fabbione> i admin RH can produce really good cups
<\sh> fabbione: hmmm...i have a red fedora...wanna have it?
<johnm> fabbione: an RHCE is one of those funny thigns which even though everyone worth his salt thinks they're a bit umm.. unusual. Companies recognise it as about the only real proof of someones skills re: linux.
<johnm> depends on company of course.
<\sh> fabbione: or my redhat baseball cap? which is somehow used when I was painting my house the last time
<johnm> Anyone go to LWE
<johnm> ?
<johnm> Alan turned up in a full-on Red Hat hat.
<fabbione> johnm: actually it was a request from the company but for very different reasons other than a piece of paper
<fabbione> at the end i gained a 2 weeks paied holidays from my company at the price of making an exam
<johnm> fabbione: like most certs? to show company competancy and claim benefits from suppliers?
<fabbione> no no
<fabbione> nothing like that
<\sh> hehe...I should wear the fedora during ubz...wearing a ms shirt and have my trolltech shirt as kilt replacement
<fabbione> johnm: i will explain another time :)
<johnm> fabbione: :)
<johnm> no one podcast here? :)
<\sh> the good thing of the rhce is the practical exam
<johnm> I actually quite like RH for pushign out the RHCE certs.
<johnm> At least it's a foundation for companies better accepting linux as a viable alternative. A way to source staff
<\sh> the bad thing is, that matthew szulik is not as kewl as bob young was...
<johnm> cool techie, or cool stylish? ;)
<\sh> johnm: no...charisma
<johnm> definately.
<\sh> bob greeted any new employee of redhat personally...so after u started for rh, u had one week of brainwashing in raleigh
<\sh> and the first thing was...hey, i'm bob and I'm glad to have u on board
<johnm> Thats a good thing! An awful lot of RH staff relocate, so to be greeted like that is comforting. Reminds me a lot of AntiTrust though ;)
<\sh> that reminds me, to look for the signed book of "under the brim" from bob...i have to take it with me to ubz for sivang
<\sh> ah not brim ,)
* fabbione heads off
<\sh> under the radar
<johnm> \sh: good book.
<\sh> yeah
<chmj> damn, I missed fabbione 
<zul> heylo
<zul> bah...so i have to learn git now? ;)
<BenC> yep yep
* BenC is setting  up the git tree now
<zul> wohoo..so i can actaully start working again ;)
<zul> are we going to have  a git tutorial?
<fabbione> morning guys
<BenC> hey fabbione
<fabbione> hey Benc
<BenC> zul: search for "Git kernel hacker's guide"
<Yagisan> what kernel is planned for dapper ? .13 ?
<BenC> .14
<Yagisan> BenC - thanks
<zul> need...git...:)
<BenC> nothing there yet, but the tree is located at kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
<BenC> going to create the debian directory and start checking in stuff today (external drivers and other git tree pulls)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | The kernel is not in, please leave a message after the beep...OOPS, unable to handle kernel paging request | Not quite ready to use, but new dapper kernel tree starting at rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git | Git guide: http://linux.yyz.us/git-howto.html
<jbailey> Wow.  I wonder how long until some write a module to pull from git to bzr so that youcan move back to bzr? =)
<jbailey> someone writes.
<jbailey> I'm clearly awake. =)
<BenC> well, I have to finish a script that will convert git to bzr, so it wont be long :)
<jbailey> *lol*
<infinity> I guess this means I need to learn git.
<infinity> It can't treat me any worse than baz has.
<jbailey> git's slightly easier than bzzr.
<jbailey> Unlike bzr, git has documentation.
<jbailey> (In fairness, when I was learning bzr, it too had documentation.  It just required a newer pull from source than I had by two days...)
<dilinger> cogito also has command line completion
<dilinger> cg-<tab>
<dilinger> it was a little weird at first, but it's definitely grown on me vs bzr help and friends
<jbailey> dilinger: True.  Although bzr comes with bash_completion bits.
<jbailey> So it's not that big of a penalty
<BenC> the main thing git will buy us is being able to pull in external trees more easily
<jbailey> Yeah, certainly.
<jbailey> Even the parisc folks have finally come around to using git. =)
<BenC> if it wasn't for that, we really wouldn't have much of a reason to use it
<dilinger> i'm not incredibly impressed w/ git performance
* jbailey adds "make parted and mdadm not suck on ppc" to his dapper list.
<dilinger> i need to give bzr 0.1* a test run on some kernel trees
<jbailey> I haven't done much with the weave format stuff yet.
<jbailey> BenC: When/how do you want wishlist items for the next kernel build?
<zul> BenC: anyone can commit to the git tree?
<BenC> jbailey: anytime
<BenC> jbailey: any big items will be slated for the UBZ kernel agenda
<BenC> general things like "include driver foo", just do a bug :)
<zul> when is the meeting going to be?\
<BenC> zul: no, just like before, work from local tree, request pull when you have something I need to include
<jbailey> BenC: Just a note that ext2 and cramfs can now be made modular on all arch's.  I'll file a bug.
<BenC> zul: not sure which day yet
<zul> i hope it will be the last day since ill be tere
<jbailey> zul: You can't get here sooner?
<jbailey> zul: At UDU, usually Bofs had multiple sessions over multiple days
<zul> nope working..
<jbailey> To give people think time.
<zul> cool
<jbailey> Bah.  You're gov't.  They can't fire you, can they? =)
<zul> i was government...now im private again
<jbailey> Well, there's still time to find a gov't job. =)
<zul> hehe
<zul> wha there is no git package?
<infinity> cogito
<zul> ah
<lamont__> jbailey: can be made modular on all architectures that support intramfs.  fix that.  kthxbye
<jbailey> lamont__: Any architecture that doesn't support initramfs is fucked for > 2.6.12 anyway, so doesn't much matter. =)
<jbailey> lamont__: I'm more actively considering getting that ia64 here, though.
<lamont__> ah, there is that.. guess we'll have to track that down...
<jbailey> The baseboard heater across the room is clearly not enough for this room inthe winter.
* lamont__ likes that... 
<lamont__> heh
<jbailey> And the one behind the desk has too much risk of frying cables.
<jbailey> lamont__: In all likelyhood, we'll get hppa done before ia64.
<jbailey> Simply because I don't need to reboot the hppa to track those bugs, it's all userspace.
<lamont__> ah, coolness
<jbailey> I'm going to need your help on ia64 to get it done soonish.
<jbailey> Hmm
<jbailey> Or I could ask bdale if he's got a box with remote reboot and console that I can use.
<lamont__> jbailey: ok.  and I'll be happy to pester the nice kernel gurus here.
<lamont__> zx2000's shipped to the developers should allow that...
<jbailey> lamont__: It's a simple enoughj problem.  "Make get_byte work, kthxbye"
<jbailey> The zx6000 I got definetly does.
<jbailey> I just didn't have any facility for it where it's colo'd.
<jbailey> And that colo is 6 hours drive from here.
<BenC> this is starting to suck...
<BenC> can't do the kernel work from here very well, since it's dialup, but doing the repo stuff from the DC is a pain given the firewall
<jbailey> *lol*
<jbailey> I remember when my net connection went down, sitting at the local starbucks equivalent on the wireless doing glibc builds. =)
<BenC> hehe
<BenC> I think I may try using my sparc at the colo
<fabbione> BenC: yo dude..
<BenC> yo
<fabbione> BenC: how is it going with git and stuff?
<dilinger> jbailey: coffee shops smell :(
<fabbione> hey dilinger 
<dilinger> hey
<fabbione> dilinger: i am cleaning up sunfire
<dilinger> ok
<fabbione> so you can pack it and ship it :)
<dilinger> ok
<dilinger> well, that won't happen til nov
<dilinger> aiui
<fabbione> dilinger: it's running breezy.. but i guess you don't mind :P
<dilinger> davem's going to korea
<dilinger> heh, nope
<fabbione> dilinger: yup.. 
<fabbione> dilinger: i am just taking down the buildd stuf
<fabbione> stuff
* dilinger backports bzr to hoary
<fabbione> so you can power it off
<dilinger> fabbione: are we going to see a breezy sparc install iso?
* dilinger noticed the announcement and amd64/i386/ppc images, but no sparc
<fabbione> dilinger: no, only netinstall
<fabbione> dilinger: i did an announce about sparc/hppa/ia64
<dilinger> hm, i should update my cogito packages too
<fabbione> the problem is that apt-get BUSERROR on everything that's not deb http:// or deb ftp://
<fabbione> so if you use file for cdrom it errors out
<fabbione> and d-i dies
<fabbione> unfortunatly we figured that a bit too late
<dilinger> jbailey: then again, the dentist's office that i'm in now smells like doctor
<dilinger> not much better :)
<dilinger> fabbione: d'oh.  can't that be fixed via update or something?
<fabbione> dilinger: nope..
<fabbione> because that requires a d-i rebuild and a ISO republishing
<fabbione> that's NO NO NO
<fabbione> dilinger: we will fix it for dapper
<fabbione> netinstall is a very good starting point for now
<dilinger> ok
<dilinger> yea
<fabbione> not many sparcs have cd either
<dilinger> figure sparc people should know how to netboot
<fabbione> dilinger: you can kill sunfire
<fabbione> i have done
<fabbione> thanks
<fabbione> a lot
<dilinger> np
<dilinger> i'll kill it when i get back home on monday or so
<dilinger> i'm sure it'll crash before then :)
<dilinger> mm, cute dental assistant
<fabbione> dilinger: i doubt.. no load = no crash
<fabbione> dilinger: does it have a LOM? if so i can power it off from here
<fabbione> or does it sends you back to OBP on poweroff?
<dilinger> fabbione: it does have LOM, but i've never played w/ it
<fabbione> dilinger: that's ok with me.. iirc linux push the machine back to LOM on poweroff
<fabbione> it does a real poweroff
* fabbione shuts it down
<fabbione> done
<fabbione> you can just ask your friend to unplug the power in the worst case
<jbailey> dilinger: Sorry.  I figured for the snapshots that anyone who'd care that badly could upgrade to breezy.
<jbailey> dilinger: It should still work on sid/sarge/etc afaik
<jbailey> etch
<dilinger> right, we can't upgrade to breezy until we make sure openafs is stable on breezy's kernel
<fabbione> ok guys
<fabbione> have fun
<fabbione> i am off till tomorrow
<jbailey> Bah =)
<jbailey> dilinger: Where's your sense of adventure? =)
<dilinger> it died in my 37th reiserfs disk corruption
<dilinger> by the 36th one, i was still doing ok; just a little shaken
<serrador> jbaile?
<jbailey> serrador: nick highlights work best when you don't use partial names. =)
<serrador> I miss typed
<serrador> OK
<serrador> I'm on channel now
<serrador> jbailey
<jbailey> yes?
<serrador> How can I help you to debug  the chain loader problem with grub and lilo?
<jbailey> Bug#?
<serrador> #15537
<serrador> Hello?
<jbailey> On the phone, just a sef.
<serrado1> ok
<jbailey> Ah right, this bug.
<serrado1> ok
<jbailey> The bug is a it confusing because someone else has added a bunch of stuff to it.
<serrado1> now I'm running a test system
<jbailey> Are you also ona jfs root?
<serrado1> no
<serrado1> just plain ext3
<serrado1> I use a test system running ubuntu
<serrado1> the others are with debian
<serrado1> I think the problem is with the way initrd is built, but my expertise with that software is not enough to figure where the problem is exactly.
<jbailey> What was the install done from?
<jbailey> (Like which breezy release)?
<serrado1> The install was done upgrading from hoary
<serrado1> all packages were updated except hoary's kernel
<serrado1> which i kept just to be safe
<serrado1> actually it is updated in at regular intervals
<jbailey> Mm, no idea then.
<jbailey> We don't support that combination at all, and I have no exposure to it.
<jbailey> Why did you do everything but the kernel?
<jbailey> glibc is far more dangerous and likely to break things. =)
<serrado1> I tested glibc before. I work in a derivative distribution called molinux, so I have some familyarity with the process
<jbailey> The whole kernel boot sequence changed between hoary and breezy.
<jbailey> So I can't really help you until you update to a breezy kernel.
<jbailey> There are some known places where if you are using an older initrd-tools, for instance, your system will become unbootable
<jbailey> This sounds like that problem.
<serrado1> It is strange, because initrd tools are from breezy
<serrado1> I assume that then similar configurations will fail an upgrade to breezy when released
<serrado1> we have arround 10000 desktops deployed which can fail, that could  be a big headache
<serrador_ubuntu> Package: initrd-tools
<serrador_ubuntu> Versions:
<serrador_ubuntu> 0.1.78ubuntu2(/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_breezy_main_binary-i386_Packages)(/var/lib/dpkg/status)
<serrador_ubuntu> Reverse Depends:
<serrador_ubuntu>   linux-image-2.6.10-5-386,initrd-tools 0.1.75ubuntu2
<serrador_ubuntu>   initrd-netboot-tools,initrd-tools
<serrador_ubuntu>   bootcd-mkinitrd,initrd-tools
<serrador_ubuntu> Dependencies:
<serrador_ubuntu> 0.1.78ubuntu2 - coreutils (16 (null)) fileutils (18 4.1.9) stat (2 3.0) cpio (0 (null)) cramfsprogs (2 1.1-4) dash (0 (null)) util-linux (2 2.11b-3) lsb-base (2 1.3-9ubuntu3)
<serrador_ubuntu> Provides:
<serrador_ubuntu> 0.1.78ubuntu2 -
<serrador_ubuntu> Reverse Provides:
<jbailey> It's posible it will work, it's possible it will fail.
<jbailey> IT's not a supported configuration at all.
<jbailey> initrd-tools is in universe, so if it's broken in any way, it's not going to get fixes.
<jbailey> I still don't understand why you'd do an upgrade of everything except the kernel?
<jbailey> It's really not the most likely thing to break.
<serrado1> I have both kernels installed, the old hoary and the new breezy
<BenC> you need to boot the breezy kernel
<BenC> the only thing we can really guarantee with older kernels is that for upgrade they will run, but you generally want to reboot wit the newer kernel
<serrado1> I want to boot with it, but the thing I'm trying to explain is that it fails to boot
<BenC> the new kernel fails to boot?
<serrado1> and if I want to do anthing in ubuntu I have to use the older hoary kernel.
<serrado1> yes
<serrado1> breezy kernel fails to boot
<BenC> so the old kernel works on breezy after upgrade, but ht ebreezy kernel doesn't?
<BenC> what doesn't work with the newer kernel?
<jbailey> serrado1: You said the bug was with the older kernel...
<serrado1> jbailey: probably I did not understand
<serrado1> BenC: The kernel stops booting and drops me a busybox shell
<serrado1> no init sequence is started
<BenC> did you try using initramfs and doing "dpkg-reconfigure linux-image-`uname -r`"?
<BenC> well, init is started if busybox starts, so it isn't a kernel issue
<jbailey> serrado1: From that shell, what happens if you type fstype </dev/FOO
<jbailey> Where /dev/FOO is your root device
<serrado1> im booting it now
<serrado1> ( phone)
<serrado1> FSTYPE=ext3
<serrado1> FSSIZE=393217
<BenC> cat /proc/mounts
<serrado1> no such file or directory
<BenC> what's the last message before you get hte busybox shell?
<serrado1> target filesystem doesnt have /sbin/init
<serrado1> The fist error I can see is:
<serrado1> FATAL: Module unknown not found
<serrado1> just before trying swsuspend
<serrado1> [4294679.528000]  swsusp: Suspend partition has wrong signature?
<serrado1> Done.
<serrado1> in the following messages it is trying to mount root devices:
<serrado1> but fails with a " no such device"
<jbailey> What's the device?
<jbailey> serrado1: /win 6
<jbailey> Feh
<serrado1> i suppose it tries to mount /dev/hdb1
<BenC> I've only seen that error on jfs and xfs installs
<serrado1> Is it resolved for those filesystems?
<serrado1> on the initrd, after executing /scripts/local-top
<serrado1> there is logged a failure trying to acces /dev/cdrom
<serrado1> does initrd use udev?
<BenC> have you tried switching to initramfs
<BenC> ?
<serrado1> Default initrd uses initramfs?
<serrado1> I think I'm using initramfs on this kernel initrd.img
<serrado1> but' im not sure
<serrado1> where is the mountroot command invoked by init?
<serrado1> one question more
<serrado1> inside modules directory, there are not any kernel module
<BenC> on your rootfs, or in the initrd?
<serrado1> on initrd
<BenC> dpkg-reconfigure linux-image-2.6.12-9-386 (or whatever your kernel image name is on this machine)
<serrado1> same error
<serrado1> could you loopback mount your initrd.img and tell me what is inside modules, please?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New (non-working) git tree for dapper: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git / branch ubuntu-2.6.14 | Git guide: http://linux.yyz.us/git-howto.html
<BenC> serrado1: why not just check your hoary initrd
#ubuntu-kernel 2005-10-19
<jbailey> Ah, missed him.
<jbailey> I suspect that he's feeding a different root= in grub than he thinks he is.
<zul> evening
<zul> so...got a question when are you guys gonig to be arriving in montreal? i say we get together for dinner on saturday nightish
<iram> Hello all, I'm trying to figure out what the ubuntu specific patches to the kernel are.  I'm need to use kernel 2.6.13 and I'm just not sure what the reprocussions of using a virgin kernel are.  I've looked around a bunch trying to find this information but I can't find it anywhere.  Can anyone give me some pointers on where to find this.
<crimsun> iram: install linux-patch-ubuntu-2.6.12
<crimsun> iram: if you need to use 2.6.13 for a specific driver, feature, or fix, you may well find it easier to backport it
<iram> crisun: what I am trying to get is the ite 8212 driver that is in the 2.6.13 kernel.  I am currently using the driver on a fedora installation but they kernel team for fedora has included it since 2.6.12.  I read the release notes from 2.6.13 and it is now included in the stock kernel (after being tested in fedora).  How would I go about 'backporting' this specific chunk of code.  The other issue is that apparently 
<iram> the ide code has been changed a lot in 2.6.13 so it may be kind of hard to just yank that code
<typo> coud someone please explain to me how I can create a package just like "linux-image-2.6.12-9-686"?
<mjg59> typo: apt-get source linux-image-2.6.12-9-686; cd linux-source-2.6.12-2.6.12; dpkg-buildpackage -rfakeroot
<typo> mjg59: great, thanks
<typo> mjg59: it doesn't have a .config, is that normal?
<mjg59> typo: That's generated when you do the dpkg-buildpackage
<mjg59> It builds several different kernels
<typo> mjg59: oh, great, and how can I enable ACPI debug?
<mjg59> The configs are in debian/config
<typo> can I make it build just the -686 kernel?
<mjg59> Easiest way is just to delete all the configs except the 686 one
<typo> will it try to build the kernels for the other arches?
<mjg59> Nope
<typo> how can I add an extra version to the packages so that they're parallel instalable?
<typo> with the ones in breezy I mean
<BenC> it's non-trivial
<typo> ok, no problem then
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New (non-working) git tree for dapper: git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git ubuntu-2.6.14 | Git guide: http://linux.yyz.us/git-howto.html
<zul> hmmm?
<typo> the compile failed with: "drivers/acpi/i2c-acpi-ec.c:322: error: `ACPI_EC_COMPONENT' undeclared (first use in this function)"
<typo> anyone know what this is?
<BenC> yeah, means you have conflicting patches
<typo> all I changed from the original was adding CONFIG_ACPI_DEBUG=y to the config
<BenC> ah
<typo> BenC: how? I didn't patch anything
<BenC> well, could be that the debug code isn't well tested
<typo> seems to be the "ACPI_FUNCTION_TRACE" macro
<typo> anyone know where this is defined?
<zul> grep it
<zul> BenC: is there something in the git tree now or am i just crazy?
<typo> zul: should I try .h or .c?
<typo> found it: include/acpi/acmacros.h
<BenC> zul: there is, but after doing a clone, do "git checkout ubuntu-2.6.14"
<BenC> I know it's counter to what I wanted to do, but all work will be in a branch :)
<typo> yes, the macro is defined to empty when debug is off
<typo> so how can I build a kernel with acpi debug?
<BenC> just remove that one ACPI_FUNCTION_TRACE line
<BenC> or comment it out
<typo> BenC: it probably happens in all of those lines
<typo> or not?
<typo> oh, that file doesn't exist before the ubuntu patches
<typo> for a centrino laptop should I use 386 or 686?
<typo> for testing I mean
<mjg59> 686
<typo> ok
<typo> and how do I remove a patch from the build?
<BenC> you don't remove the patch
<BenC> if ACPI_FUNCTION_TRACE is broken, then you're looking at a lot of work, really
<typo> BenC: maybe it's just in the i2c patch
<typo> removing it is that hard?
<BenC> possible
<BenC> no, just edit debian/patches/00list-9.23
<BenC> first do "fakeroot debian/rules clean"
<BenC> git's shared object directories are cool
<typo> if I remove that one then the "drivers-acpi-add-devacpi" patch fails
<fabbione> hey BenC 
<typo> I was trying to debug this: "https://bugzilla.ubuntu.com/show_bug.cgi?id=8140" but I guess it's not to be
<BenC> which one did you remove?
<BenC> hey fabbione
<fabbione> BenC: pulling your tree from kernel.org is quite of a puzzle :)
<fabbione> davem 1) Clone Linus's tree
<fabbione> davem 2) Clone locally, from that, a tree named "ubuntu-2.6" or whatever
<fabbione> davem 3) In the ubuntu-2.6 tree, pull from Ben's with the "ubuntu-2.6" tag as the last arg
<fabbione> otherwise we get plenty of errors
<BenC> fabbione: that's not how I did it
<fabbione> BenC: that's what we had to do :)
<typo> BenC: external-drivers-acpi_i2c-acpi-ec.dpatch
<fabbione> what's another solution?
<BenC> do the command in the topic and then do "git checkout ubuntu-2.6.14"
<BenC> I created the tree just like Linus told me
<fabbione> ok
<BenC> so if it's wrong, blame Linus :)
<fabbione> OHH
<fabbione> i think it's because i missed the tag at the end
* fabbione tries again
<fabbione> BenC: we need to do a git pkg for Ubuntu
<fabbione> the one we have inside cogito is old
<typo> BenC: any other idea? to do this or to debug it some other way?
<fabbione> anyway i need to run off now...
<BenC> fabbione: I guess I'll be nominated to maintain git since I'm forcing people to use it :)
<fabbione> BenC: nah. i will prepare the pkgs
<fabbione> it's okl
<fabbione> ok
<jbailey> Isn't git in universe? =)
<fabbione> jbailey: cogito is
<dilinger> isn't git as well?  istr git being broken out of cogito
<dilinger> yuck.  cogito's changelog is a bit scary; binaries being removed, readded, renamed...
<dilinger> the debian package is also horribly out of date
<dilinger> bah
<dilinger> i know what i'm doing today
<typo> BenC: I now have this: "ABI has changed!  Refusing to continue; please update the ABINAME accordingly."
<typo> how do I update ABINAME?
<typo> anyone know?
<dilinger> the ABINAME is in the package name
<typo> and how do I change it?
<dilinger> by changing the control file, i would assume
<dilinger> linux-image-2.6.12-9-386
<dilinger> the ABINAME there is '9'
<typo> and that's where I change it?
<dilinger> i'm not certain where else it might need to be changed, but debian/control is a good start
<typo> I'm guessing debian/abi/ has something to do with it
<typo> disabling the abi check would also work
<typo> anyone know how to do that?
<typo> from debian/rules I'm guessing touching debian/abi/i386.ignore will do that
<BenC> typo: debian/rules bumpabi
<BenC> and also the ignore will make it continue
<BenC> bumabi will change the abi name to -10
<fabbione> BenC: that's weird..
<fabbione> i did the git pull and git checkout from people
<fabbione> but there is no debian/ ?
<fabbione> i was on git web that you commited it
<BenC> fabbione: git checkout ubuntu-2.6.14
<fabbione> ahh
<fabbione> so everything needs to be presented with the branch tag
<fabbione> thanks :)
<BenC> once you checkout with the branchname, you are good
<fabbione> yup
<BenC> then everything will default to that branch
<fabbione> ah perfect
<fabbione> so in future i will just git pull to update the tree
<BenC> right
<fabbione> i will need to figure later how to commit/publish the brach without accessing your repo directly
<fabbione> but that's monday task :)
<fabbione> BenC: are you using a cronjob to sync with kernel.org?
<BenC> commit is local, then you can push it anywhere you want, but back to my repo is best
<fabbione> or do you need to do it manually?
<BenC> not currently
<fabbione> ok
<BenC> right now, I am manually syncing to kernel.org so that I can get some sort of checking for commits
<fabbione> hmm did you create the repo with the g+s so i can commit?
<fabbione> because otherwise that can be an issue
<BenC> should be, let me check
<BenC> what sort of stuff are you going ot be working on?
<fabbione> right now i am only setting up the enviroment
<BenC> ok
<fabbione> but i will need to commit stuff for cluster and ocfs2
<dilinger> bah
<fabbione> dilinger: yo
<dilinger> cogito upstream has their own debian stuff
<fabbione> dilinger: i will make clean gi pkgs next week
<fabbione> dilinger: no cogito
<fabbione> git even
<BenC> keep all your work local until I write up the commit details (log style, etc)
<fabbione> BenC: i am not going to do anything without your approval, while we test the bits :)
<fabbione> also because at the best, the kernel doesn't even compile
<dilinger> fabbione: well,i'm looking at cogito now
<BenC> in order to keep everything clean with this commit-all stuff, we need good logging
<fabbione> BenC: yup
<dilinger> since i want to build bzrweb and update gitweb, might as well
<fabbione> dilinger: most kernel hackers don't use cogito for different reasons
<BenC> what is cogito?
<BenC> as opposed to git
<fabbione> BenC: cogito is an simplified UI for git
<fabbione> BenC: cogito uses git as backend
<fabbione> nothing fancy
<BenC> ah
<BenC> makes it easier for cvs folks, I assume?
<fabbione> the real issue is that cogito Depends: git (= $special_version)
<fabbione> when git moves forward much faster
<BenC> so far I like git
<fabbione> BenC: yeah sort of
<BenC> one thing I like is that I have one main linux-2.6 repo locally, and my ubuntu and linux1394 repo's share the majority of hte objects with it, and it saves space
<dilinger> fabbione: what reasons are that?
<fabbione> dilinger: the missing allignment is the first.. 
<fabbione> dilinger: that creates problems for them to keep in sync
<fabbione> anyway
<fabbione> gotta go
<fabbione> cya sunday
<fabbione> or later
<dilinger> or maybe i should drop gitweb (can't find bzrweb anymore), and break out the code in tailor for reading distribution RCSs
* dilinger blinks
<dilinger> http://nautilus.homeip.net/~lele/
<dilinger> that's a little disturbing
<typo> BenC: it failed because it was expecting to find "debian/build/linux-image-2.6.12-9-386_*i386.deb" and there was a 686 image there instead
<typo> I guess deleting the 386 config wasn't a good idea after all
<BenC> if it got that far, then it might be done
<BenC> is there a .deb image in the directory below your build?
<typo> BenC: yes, there's a deb here, I'm going to try this one
<typo> BenC: It worked, I got a 2.6.12-9-686 kernel with ACPI debug on
<typo> BenC: it hangs after "Executing all Device _STA and _INI methods:........."
<typo> BenC: if you need the other stuff I can write it all down
<typo> BenC: anything else please ask
<typo> BenC: the bug is here: https://bugzilla.ubuntu.com/show_bug.cgi?id=8140
#ubuntu-kernel 2005-10-20
<Solatis> hello
<Solatis> question: what is the difference between linux-kernel-headers package and linux-source-x.x.xx packages ?
<Solatis> since linux-kernel-headers is still at version 2.6.10, while running kernel version is 2.6.12 in breezy
<Solatis> so i'm not able to compile any kernel modules
<infinity> linux-kernel-headers is for compiling user-space applications, not for compiling modules.
<infinity> For compiling modules, you want linux-headers-`uname -r`
<infinity> (You also want gcc-3.4, though you'd probably find that out the hard way soon enough)
<Solatis> infinity: haha yes, already found that out
<Solatis> and thanks, linux-headers-`uname -r` worked
<fabbione> we don
<fabbione> we don't Depends: gcc-3.4 for several reasons tho
<fabbione> one is that you might want the headers or source just for reading
<fabbione> and you so much don't want us to pull a gcc for that
<infinity> A Depends or Recommends might have been nice, but too late now.
<infinity> Something to fix for dapper, though, since I highly doubt dapper's kernel will be built with gcc-4.0
<infinity> dapper+1, maybe.  If we're lucky.
* infinity is reminded of the old days of having gcc272 installed as "kgcc", since 2.95 didn't cut it.
<fabbione> infinity: we discussed it already
<fabbione> we agreed on a Suggests:
<infinity> Err, I meant "A Suggests or Recommends", not Depends.. So,yes, we're onthe same page.
<infinity> A Recommends may be better than a Suggests, though.  The people who would be browsing kernel headers for fun are the same people who know how to tell their package manager not to install Recommends, everyone else probably wants the compiler by default.
<infinity> (Which is precisely what Recommends means)
<fabbione> let them have fun to figure out how to trash their kernels :)
#ubuntu-kernel 2005-10-21
<chuck_> afternoon people
<zul> ok i get it..
<dilinger> hm
<dilinger> we're not planning on gcc4 kernels for dapper?
#ubuntu-kernel 2005-10-22
<infinity> Is the kernel planning on liking gcc4 well enough to be stable for 5 years?
<infinity> And is it going to do so in the next month?
<infinity> If not, I think we're stuck with gcc3.4 :)
<zul> everninng
<zul__> everybody still on holiday?
<fabbione> hey zul
<BenC> hey
<fabbione> hey Ben
<fabbione> BenC: i finally got the git export properly
<BenC> fabbione: cool
<fabbione> but i can't manage to push it to my server
<fabbione> David was talking about gitd or rsync
<fabbione> but git push rsync:// farts on me
<BenC> why doesn't git push ssh:// work?
<fabbione> Cannot push to rsync://
<fabbione> there is a specific exception in git-push script
<fabbione> no idea why
<BenC> what does it say when you do "git push ssh://people.ubuntu.com/..." ?
<fabbione> i can try that.. gimme a sec
<BenC> make sure you supply ubuntu-2.6.14 after the url, so it pushes the right branch
<fabbione> ssh: ssh: Name or service not known
<BenC> show me your command line?
<BenC> git-send-pack people.ubuntu.com:/home/bcollins/public_html/repos/ubuntu-2.6.git ubuntu-2.6.14
<fabbione> AHHH
<BenC> give that a try aswell
<fabbione> git push ssh://rookery.warthogs.hbd.com/
<fabbione> fatal: / doesn't appear to be a git directory
<fabbione> Killed by signal 1.
<fabbione> fatal: unexpected EOF
<BenC> git push ssh://people.ubuntu.com//home/bcollins/public_html/repos/ubuntu-2.6.git ubuntu-2.6.14
<BenC> that is the right push line
<fabbione> that's if i want to push into your archive... right?
<fabbione> what if i want to branch...
<fabbione> and expose my archive for you to pull from
<BenC> then use your branch name at the end
<BenC> git branch fabbione-2.6.14
<fabbione> ok..
<BenC> git checkout fabbione-2.6.14
<BenC> (do work)
<BenC> then push
<fabbione> so we need to land into the same repo
<fabbione> i cannot publish it let say in my home dir on people
* fabbione is utterly confused by git atm
<BenC> yeah, you can do that aswell
<BenC> hold a sec...
<fabbione> sure
<BenC> git clone -n -l -s /home/bcollins/public_html/repos/ubuntu-2.6.git fabbione-2.6.14
<BenC> mv fabbione-2.6.14 fabbione-2.6.14.git
<BenC> do that on rookery
<BenC> and it will create a git repo for you with shared objects with mine (reduces space usage)
<BenC> then you can push your stuff there
<BenC> mv fabbione-2.6.14/.git fabbione-2.6.14.git
<BenC> use that line second
<fabbione> ok it seems to work
<fabbione> i don't need a real branch
<fabbione> just the option to work on the same tree
<fabbione> but push to you async for crack
<fabbione> error: remote 'refs/heads/ubuntu-2.6.14' object 180a764cccdd44c16050c25716a9f814c1955a47 does not exist on local
<fabbione> crap
<fabbione> git push ssh://rookery.warthogs.hbd.com/home/fabbione/public_html/archives/fabbione-2.6.14.git ubuntu-2.6.14
<fabbione> so i didn't change branch.. just pushing like you said
<BenC> hold a sec
<fabbione> sure
<BenC> ah
<BenC> do a pull
<fabbione> done i am already in sync
<BenC> still getting the message?
<fabbione> trying again
<fabbione> take into account that i did this in my tree
<BenC> it's saying that a revision on the remote doesn't exist in your local copy
<fabbione> pull from you
<fabbione> ok.. let me explain what i did first
<fabbione> pull from you
<fabbione> pull from linus
<BenC> where did you clone from?
<fabbione> pull from davem
<fabbione> you
<fabbione> i did clone from you
<BenC> why the pull from linus and davem?
<fabbione> BenC: for fun? i need to stretch my wings on git
<fabbione> and then i want to publish this tree somewhere else other than your
<fabbione> since i don't want to mess it up
<BenC> ok, you're going to need to take your local .git/ directory and copy it to rookery
<BenC> make that your initial repo and push to it
<fabbione> oook..
<fabbione> that's crack :)
<BenC> it's weird that your missing an object that the remote has :)
<fabbione> $ cd linux-2.6
<fabbione> $ rsync -a --verbose --stats --progress \
<fabbione>    rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
<fabbione>    .git/
<fabbione> this is according to the guide.. could it make sense that we need to do it from you too?
<fabbione> actually.. no i want to get this right in the right way
<fabbione> not with hacks
* fabbione kills his local repos
<BenC> yeah, that guide is for ancient git bins
<BenC> me personally, I did "git clone ssh://people.ubuntu.com/home/bcollins/public_html/repos/ubuntu-2.6.14"
<fabbione> git clone ssh://rookery.warthogs.hbd.com/home/bcollins/public_html/repos/ubuntu-2.6.git ubuntu-2.6.14
<fabbione> starting from here now
<BenC> then I did some work, and periodically I do "git push"
<fabbione> yes, but you push in your own archive :)
<fabbione> that's already there
<BenC> actually, what you want first is to do the local clone on rookery
<BenC> then on your desktop do the clone from your personal git repo
<fabbione> right
* BenC writes all this down for the doc
<fabbione> BenC: we also need to think one second how do we want to keep pathes in git
<fabbione> i don't think .dpatch is efficent anymore
<fabbione> not if we want to push changes upstream
<BenC> as of this moment, everything is going to be in the repo
<BenC> no patches, directly applied
<fabbione> BenC: exactly what i was thinking...
<BenC> so far I have merged almost all the external drivers
<BenC> read "git log" and you'll see the format for the log messages
<fabbione> in the newest versions? or just from .12?
<BenC> newest versions
<fabbione> cool
<fabbione> i need to push you the new redhat and ocfs2 crack
<BenC> 2 or 3 of them have been merged in 2.6.14-rc, so they just got left alone
<fabbione> BenC: yes.. some of them were there already in .13 like sc
<fabbione> and idiotify
<BenC> where is the latest cluster patch? I couldn't find anything as new as what was listed in external-drivers?
<fabbione> BenC: sources.redhat.com
<doko> fabbione: found the biarch sparc thing
<fabbione> but let me deal with it
<BenC> doko: sweet
<fabbione> BenC: because their upstream is really really messy
<BenC> fabbione: sure
<fabbione> doko: cool, send it here
<fabbione> BenC: they have like a few branches and they manage to get confused by themselves
<BenC> doko: is gcc4.1 expected to compile the kernel?
<fabbione> BenC: like fixes that goes in STABLE branch are not propagated and viceversa
<BenC> fabbione: hehe
<infinity> BenC : Probably, but are we willing to risk a "supported for 5 years on servers" release on a compiler that may produce panicking kernels?
<fabbione> BenC: it took me a month or 2 of fights with them to get that right
<fabbione> BenC: and they still manage to miss the STABLE branch
<infinity> BenC : I'd push for 3.4 in dapper, and 4.x as the kernel compiler in dapper+1, even if it's not ready (cause dapper+1 is good place to be testing shit that might break hideously)
<BenC> infinity: servers are going to be 2.6.12 based anyway
<fabbione> BenC: no no no
<infinity> BenC : Ugh, we're not going with jdub's crackful suggestion on that, are we?
<fabbione> who said .12?
<infinity> That's nuts.
<BenC> where is this all being discussed?
<fabbione> BenC: i just had a big fight with jdub about that crack
<fabbione> ubuntu-devel mailing list
<infinity> Maintaining two kernel branches is confusing to users, and a pain for us.
<fabbione> infinity: that's my Copyright :P
<BenC> only thing I've read about it so far is what mark emailed to ask me
<infinity> Anyhow, jdub's just spouting opinions, not policy, we'll all get to yell about this at UBZ in person.
<BenC> I'm not sure supporting a kernel for 5 years is sane in any case
<fabbione> eheh exactly
<BenC> 5 years ago, 2.2.7 was released
<BenC> try supporting that now
<infinity> Hey, 2.2.7 was solid, dude.
<infinity> :)
<fabbione> still better than 2.2.11
<BenC> yeah, on your grandma's hardware :)
<fabbione> after that the 2.2 serie was crack
<infinity> I suspect we may need to come up with a point-release plan to update stuff like kernels (for server/desktop) and X drivers (for desktop) occasionally, while not compromising overall stability.
<infinity> Thankfully, modular X is making the latter job easier.
<infinity> Hopefully rolling kernel driver updating shouldn't be too much hell either.
<infinity> RHEL manages to get away with point releases for hardware updates and such, so I'm sure we can manage.
<fabbione> infinity: well we get back to the same point...
<BenC> I'm hoping that a revamped development model for our kernel will make it easier for us to move from one version to the next
<fabbione> developing release foo + preparing service pack X for bar
<fabbione> we don't have the resources :)
<infinity> Well, we shouldn't be changing much of anything in dapper except for installability support.
<infinity> IMO.
<infinity> So, hardware support, and nothing else (other than the usual security and critical -updates)
<infinity> So, assuming we can get our act in gear enough for that, we're okay.
<BenC> personally, I think the kernel should have two branches, one that is targeted for next release, and if there needs to be, a second that is following the latest upstream release
<fabbione> BenC: we did try that in hoary
<BenC> e.g., when 2.6.14 becomes final, we keep that branch for dapper, and immediately start on 2.6.15-rc1 just to follow the code
<fabbione> it was horribly confusing
<BenC> but 2.6.15-rc branch doesn't have to be uploaded
<infinity> And it can be parallelized a bit.  Say, a month after dapper+1 releases, we decide dapper+1's kernel looks pretty stable and well-tested, we push it back into Dapper-revision1
<fabbione> BenC: that will help to release .15
<BenC> just kept up-to-date
<BenC> just thinking that moving to the next kernel will be a lot easier if we don't wait so long for the code to diverge from our working setup
<BenC> we're at 2.6.12, and starting this whole 2.6.14 thing is a real pain (but a good experience, since I have an excuse to scrap as much as I want :)
<fabbione> BenC: we did the "following code very close game"  when we did open hoary
<fabbione> with a 2.6.12-rc2 i think
<fabbione> and started with that
<BenC> so breezy's kernel was being worked on during hoary?
<fabbione> the main issue is that when we approach release, there is really not so much time to play around in syncing
<fabbione> BenC: immediatly after hoary was released
<BenC> ah
<BenC> well, for 2.6.15, it will be mostly just doing "git pull"
<BenC> you can even be in the 2.6.15 branch, and do a pull from the 2.6.14 branch to make sure we have all the little security fixes merged
<BenC> it's not that I expect that the branch will build, just keeping the code in sync so it isn't so hard to merge stuff later (easier to merge from day one, than jump from 2.6.14 -> 2.6.16-rc3)
<fabbione> yup
<makx> fabbione: will you use the debian unified packaging?
<makx> i mean you were the first to introduce that model..
<fabbione> makx: probably.. 
<fabbione> we are changing sort of RCS and way of handling patches and so on
<fabbione> makx: so perhaps yes, perhaps no
<makx> i read the git part. :)
<fabbione> it depends how it fits :)
<BenC> what is debian unified packaging?
<makx> well before you had the separeted source and images debs xu build stuff
<infinity> Building all the arch-specific kernels from one source package, I assume.
<infinity> And scrapping that would be dumb.
<fabbione> BenC: the old DEbian system was -> upload source -> wait -> upload pkg that b-D on source to create -image- -> wait -> upload d-i stuff to update .udebs
<fabbione> BenC: we do all from the same pkgs
<makx> it works quite good for anyone beside the mips/mipsel maintainer.
<fabbione> and that's what debian did adopt except for the .udeb side
<BenC> ah
<BenC> yeah, I don't think we'll change the way the build works :)
<fabbione> BenC: we will stick to that model of building everything, but we might want to look at the Debian way of building
<fabbione> last time i checked it was more polished than ours
<fabbione> dunno right now, given the amount of people hacking in it
<infinity> That's not surprising.  Debian's "arguing about stuff for 12 months before, during, and after implementation" method may be slow, but it produces polish eventually.
<makx> fabbione: do you build uml?
<fabbione> makx: no
<jbailey> What's the value in uploading a binary "source" deb?
<makx> isn't that a dpkg limitation.
<infinity> Has nothing to do with dpkg.
<BenC> jbailey: back when ports were way out of sync, and had wildly different "upstream" kernel versions, it was the only way to do things
<jbailey> BenC: Ah, okay.
<jbailey> I had always assumed it was something to do with making custom kernels easier.
<infinity> It has to do with people wanting our source to build custom kernels, without having to "apt-get source" and figure out how to build with the maintainer scripts.
<infinity> Which is scary and weird for most people.
<BenC> that's true too
<jbailey> I'd love to see all hacks that make custom kernels easier go away.
<jbailey> But that's my hatred of custom kernels and the bugs they cause. =)
<infinity> I run custom kernels built from upstream source.
<infinity> <shrug>
<infinity> But I can see why people may prefer to use our source.
<fabbione> infinity: that's becuse you are australian
<infinity> (close tracking of security issues, for instance)
<infinity> fabbione : I'm Canadian, dude.
<fabbione> EVEN WORST
<fabbione> and you live in .au
<fabbione> tsk tsk :P
<jbailey> Right, but if people do their own kernels, we can make no promises about things running.
<infinity> My granmother was Sicilian, does that help?
<fabbione> infinity: no
<fabbione> ;)
<jbailey> Our bits are all tested as one piece together.
<infinity> jbailey : Yes, and?
<infinity> jbailey : You can't stop them from making custom kernels, so making it pointlessly hard is silly.
<makx> we had scary questions about allowing the user to nitpick the applied patches.
<fabbione> that won't happen with git :)
<jbailey> infinity: I think it actually makes it harder for hacking on our kernels to do it this way.  For any other package, apt-get source, hack, debuild, is enough.
<fabbione> one tree with all patches applied :)
<infinity> jbailey : apt-get source, hack, debuild works for the kernel.
<makx> btw a scary tree yours. :-P
<infinity> jbailey : But it produces a bunch of images, with our default configs.  And is nonintuitive for people to make one custom image out of.
<makx> fabbione: nice than you wont need the patch apply business of the current targets.
<makx> it should cope with empy debian-patches dirs.
<jbailey> If someone can't figure out which .deb to install, they're probably not clueful enough about their system to spend time building their own kernel.
<infinity> It's not about which deb.
<infinity> It's about the build taking 8 hours.
<jbailey> Although a hack to debi to only install packages that are already installed might be nice. =)
<fabbione> i am off
<fabbione> later guys
<fabbione> BenC: i will come back as soon as the git clone is done
<fabbione> connection to the DC sucks
<infinity> And I still prefer "make menuconfig && fiddle around && make-kpkg foo" to mucking around in the linux-source-2.6.12 source package for the sake of one image build.
<infinity> We should fix our copy of make-kpkg to use '--stem linux' as the default, though, instead of '--stem kernel'
<infinity> But, y'know.  That's cosmetic.
<infinity> I'm all about discouraging users from building custom kernels if they don't have to (I'm running the breezy kernel on my laptop, and the freedom to not care is a bit nice), but poeple have reasons to do so at times.  Such is life.
<infinity> Discouraging people from doing out-of-band kernel builds is good thing (ie: make bzImage && make install), but we can't PREVENT that, only educate people about the joys of make-kpkg.
<jbailey> Mmm.
<jbailey> I guess I'd like to eventually see us move the kernel to being part of ubuntu-standard
<jbailey> That way if we add an inotify patch or whatnot, there's always that promise that these patches are there on a running system.
<jbailey> And to be able to commit to that sort of tight integration.
<infinity> Still doesn't stop me from booting another kenrel if I so choose.
<infinity> The insaller does install the linux-$(arch) metapackage that pulls in automatic upgrades, we can't do much better than that.
<BenC> we could force a signature in the kernel that grub verifies :)
<BenC> then people would have to replace grub in order to boot a custom kernel
<BenC> for "supported" systems, I almost think it would be vital to have such a feature
<BenC> especially something in dmesg or ksymoops output (like tainted does now for unsupported modules)
<infinity> And now I'm rebuilding the kernel and the bootloader, pushing me from one unsupported package to two.  Yay.
<BenC> the grub thing isn't so much to keep them from booting a custom kernel, just to make it easier for us to know about it
<BenC> get grub to spit out a message that says "YOU ARE BOOTING AN UNSUPPORTED KERNEL. YOU DO SO AT YOUR OWN RISK"
<infinity>  /proc/version is all you need to know it's a custom kernel.
<infinity> Not sure how grub will help you, since you're not watching them boot.
<BenC> not if they use our source and add stuff to it
<infinity> (Also, every system I build custom kernels on doesn't have a head, so I'd never notice the bootloader anyway) :)
<infinity> I run supported kernels on desktops.
<infinity> BenC : Erm, even if they use our sources, /proc/version will tell you it's custom.
<infinity> it won't be tagged as being built on our buildds, for one.
<infinity> And the build date won't be one of ourss, etc.
<BenC> that's true
<Yagisan> infinity: can't I just manually patch that in :)
<infinity> If you manually patch your kernel to look just like one of ours, you're probably not going to be blaming us if it doesn't work either.
<BenC> would be nice if we could have the buildd's so that when it built an ubuntu kernel, it would force the build date and builder to that of the changelog entry for the version
<infinity> Seriously.  These sorts of countermeasures are to prevent idiots from begging for support on unsupported configs, not to prevent EVERYONE from using their computers effectively.
<infinity> BenC : That would have to be done in debian/rules, and then it would also apply for people rebulding from apt-get source.
<BenC> wouldn't have to be
<infinity> Well, we do already do DC-specific things by way of really broken hacks (like checking that /CurrentlyBuilding exists), but we shouldn't.
<infinity> CurrentlyBuilding may not be around forever, as it is also a hideous hack.
<jbailey> Especially since you know you'll see in the forums about 2 days after "I don't know why, but if I mkdir /CurrentlyBuilding it works MUCH BETTER"
<BenC> lol
<infinity> Every once in a while, I consider a DDoS on the forums.
<infinity> But then I think better of it.
<infinity> What with the whole "I could get fired" thing and all.
<jbailey> Well.  It would be your fault for using all of the DC machines to do the DDoS. =)
<infinity> *cough*
<infinity> I wouldn't JUST use DC machines.  I'd jeopardize my Debian account by using every Debian host I have access to as well, sheesh.
<infinity> THINK, MAN, THINK.
<Yagisan> What's the most common reason that people build their own kernels ? I build mine for sec patches that will never go mainstream
<jbailey> Yagisan: My opinion?  I think themost common reason is that people assume that a new kernel will fix all of their troules.
<infinity> I build for stability on server systems.
<jbailey> So they grab a new one and just build it.
<jbailey> Basically insufficient shinyness.
<infinity> On the desktop, I only build new kernels when playing with new features (testing new DRI, etc)
<infinity> So, yeah, on the desktop it's all about either development work or bling.
<infinity> On the server side, I feel I have real justification to build new kernels.
<Yagisan> I had a proposal for universe kernels based on the main kernel + sec patches up for discussion for MOTU
<infinity> Like PaX and grsec and such?
<Yagisan> exactly
<jbailey> Is it possible to work those patches in a way to allow them to be runtime selectable?
<infinity> If you could maintain the forked flavours in complete lockstep with the main sources, including building lrm packages for multiverse, I'd not have too many issues with it.
<infinity> But I'd want to see a commitment to maintaining lockstep source reuse.
<Yagisan> jbailey: for many of them - no
<jbailey> Ah, too bad.
<Yagisan> infinity: I'm only interested in doing it - if the patches apply to mains kernel
<infinity> Yeh, they'd have to apply cleanly, obviously.  But more than that, MOTU would have to commit to doing releases to -security each time we do a release of the main kernel to -security, either.
<Yagisan> infinity - for myself I need pax, and possibly rsbac (to provide an alternative for selinux)
<makx> Yagisan: irc grsec doesn't cope with the 2.6 release speed.
<infinity> In practice, people are horrible at separating supported from unsupported, and the kernel is not a good place to test that.
<jbailey> Reminds me that ajmitch is supposed to send me selinux bits for initramfs-tools this week
<Yagisan> makx: I know, but they do have cvs releases
<makx> Yagisan: and that's against latest stable?
<Yagisan> makx: they have a cvs against .12
<makx> bleeh that's old.
<Yagisan> makx: but I don't use it - I use pax
<Yagisan> makx: well - I said I don't use it - I see a pax against .14rc
<makx> Yagisan: i thougt the main dev of pax quited..
<makx> # blah to many typos sorry.
<Yagisan> makx: nope - he discovered he is human
<Yagisan> infinity: when the first dapper kernels appear in the archive - I'll see if I can do up a proof of concept
<Yagisan> that can pull it in, and create hardened kernels - so only a kernel-patch-foo package is needed in universe
<johnm> Yagisan: makx: I just pushed out a release (not ubuntu related) which is grsec against 2.6.13.4, the only reason it skipped .12 was because of a massive internals rewrite. mostly related to rbac.
<makx> johnm: not that i would thouch that piece.
* makx was just curious..
<Yagisan> johnm: I'm interested, but unless I can patch it against the main kernel, and pass the motu revu - I can't submit it
<johnm> Yagisan: that shouldn't be any problem at all imo.
<BenC> fabbione:? 
<zul_> gday
<BenC> hey
<hkais> hello
<hkais> anyone here who works with xen in ubuntu/debian?
<hkais> I'm looking to support if necessary, but I do not know how and what to do for the XEN
<hkais> hmm really nobody here?
<BenC> probably just no one could answer you :)
<zul_> BenC: i finally have git going
<zul_> and i have made a change last night yay...but how do we push stuff to you?
<BenC> are you able to put a git repo where I can pull from it?
<BenC> if not, you'll have to send me git pushes via email
<zul_> ok..
<zul_> so i can mailbomb you ;)
<BenC> git-mailsplit will help a lot :)
<zul_> heh...actually i can place the patches on my homepage if you want and you can get them from there
<BenC> fabbione: ping
<BenC> zul_: emailing me a legit git push object would be best
<BenC> that way when you merge it and you pull, it will reflect properly
<BenC> when I merge it, and you pull, that is
<zul_> ok...not a problem
<spiekey> hiho
<hkais> hi
<hkais> next try...
<hkais> I am searching for someone who is currently working with/on XEN in combination with ubuntu or debian unstable, anyone here?
<hkais> I want to support if necessary for a port XEN3
<hkais> hmm okay i will try it in the debian kernel channel
<fabbione> BenC: pong?
<fabbione> Unpacking 101726 objects
<fabbione> fatal: unable to read e9066604fd66fe0be7600f74d295b95e8fac474c
<fabbione> Killed by signal 1.) done
<fabbione> fatal: early EOF726) done
<fabbione> fatal: git-unpack-objects died with error code 128
<fabbione> BenC: that's the result of several hours of pulling :/
<fabbione> BenC: that's weird.. doing a fresh pull now
<fabbione> there are like 4000 objs less?
<lamont__> why doesn't the breezy kernel find my sound card??? huh???
<lamont__> ew
<lamont__> Neomagic Corporation NM2200
* lamont__ consults the forums, feeling dirty
<crimsun> well, there's snd-nm256, but I don't think that's yours
#ubuntu-kernel 2005-10-23
<crimsun> lamont: got your sound working yet? If not, try sudo modprobe snd-cs4232 port=0x534 cport=0x538 mpu_port=-1 fm_port=0x388 irq=5 dma1=1 dma2=0 isapnp=0
<crimsun> lamont: values to some of those params may differ, but it should be the idea
<svenl> hi guys.
<svenl> BenC: i hear you are the new guy in charge of the ubuntu kernel.
<svenl> i am testing ubuntu/breezy on pegasos, and fixing the remaining problems.
<svenl> BenC: i would like your comment on 15573, which allows the marvell gigabit ethernet to support hotplug.
<svenl> fabbione: hi.
<fabbione> svenl: ho
<fabbione> hi even
<svenl> fabbione: do you have a powerrpc 2.6.14-rc4 kernel handy somewhere, i just did a breezy install and wants to play with the new marvell sata driver.
<fabbione> no i don't
<fabbione> we are still working on the tree
<fabbione> portforwarding the patches and stuff
<svenl> ok.
<svenl> you have too much patches :)
<fabbione> no
<svenl> fabbione: i will use the debian kernel for testing, may work.
<fabbione> we are just switching RCS at the same time
<svenl> fabbione: BTW, what about : #15573
<fabbione> svenl: you need to wait for Ben
<fabbione> i don't have commit access yet
<svenl> fabbione: i will probably not be online later when he is active, can you ping him about it ? 
<svenl> fabbione: where will it go ? 
<fabbione> svenl: i won't be online either
<fabbione> but he reads backlog i think
<svenl> fabbione: cool.
<fabbione> svenl fabbione: where will it go ?  <- ???
<svenl> i had hoped to see it in breezy.
<fabbione> if it goes in, will be for dapper
<svenl> fabbione: in what kind of kernel packages, breezy-updates, breezy+1, ?
<svenl> :/
<fabbione> dapper
<svenl> i will need to do a custom build then.
<svenl> but then it will br broken again in each subsequent upgrade.
<svenl> which sucks.
<zul> heylo
<zul> anyone care to explain this 2 kernel business?
<Yagisan> zul: if I understood it correctly - it's like this
<Yagisan> zul: we have source a, we add patches b + c to create -foo, and we add patches c + d to create -bar
<Yagisan> zul: It all uses 'a' as the base source, to keep updates in sync
<Yagisan> zul: That is of course assuming I understood it correctly
<zul> hmmm...ok...ill go read the thread again
<fabbione> zul: yeah.. more or less like Yagisan says
<fabbione> zul: but even simpler
<fabbione> -server will be source a+fix(b)
<fabbione> desktop will be source a+fix(b)+shinyfeature(c)
<fabbione> basically server will be more conservative
<BenC> most likely server will be the same source with shinyfeatures(c) disabled, correct?
<BenC> most shinyfeatures are configurable and non-intrusive
<fabbione> BenC: if we can do that, yes
<fabbione> BenC: anyway a long thread explode on ubuntu-devel mailing list
<fabbione> and it's a good idea you look at it and answer too
<fabbione> BenC: i finally managed to get a checkout of your tree
<fabbione> did you grab the cloop source pristine from Debian or just ported our patch?
<fabbione> iirc we did add an extra fix to it, that for one reason or another never made upstream
<fabbione> but in any case we have it in .12 as reference
<BenC> trying to remember
<fabbione> BenC: now we should try a commit if you have time..
<BenC> sure
<fabbione> ok.. just a one liner change in debian/changelog
<fabbione> i did the change
<fabbione> now git commit
<BenC> fabbione: can you bounce me the primary email to that thread so I can comment? I'm not sub'd to -devel yet, and when I do today, I still wont be getting most of it
<BenC> edit, git-update-index <file>; git commit
<BenC> hold a sec before the commit
<fabbione> sure
<BenC> use this template
<BenC> [UBUNTU:] 
<BenC> PatchAuthor:
<BenC> UpstreamStatus:
<BenC> space after first line
<BenC> wait, is this an external driver?
<fabbione> BenC: no, just a one liner change as test commit
<fabbione> we did never try if it work
<BenC> ok, then use that template
<fabbione> since it will commit to your tree
<fabbione> or should at least
<BenC> and the last line should read "Signed-off-by: Fabio ..."
<BenC> you are pushing to my tree or yours?
<fabbione> BenC: iirc there was a file to stick that Signed-off-by:
<fabbione> to your tree
<BenC> fabbione: git commit -s
<BenC> that will do it if you have the proper env vars set
<BenC> GIT_COMMITTER_NAME=Ben Collins
<BenC> GIT_COMMITTER_EMAIL=bcollins@ubuntu.com
<fabbione> that i don't think i do
<fabbione> exacly
<BenC> first line should look like:
<BenC> [UBUNTU:ppc]  Disable serial 8250 initialization on PMAC
<fabbione> ok, but i am going to change only your email address in debian/changelog as a test commit
<fabbione> so i will write:
<fabbione> [UBUNTU:debian]  Test commit - fix Ben email address
<fabbione> does that fit?
<fabbione> we only want to check if it works..
<mkrufky> sorry to barge in on the conversation.... are you guys moving away from Baz and towards -git ?
<fabbione> mkrufky: see /topic :)
<mkrufky> lol
<mkrufky> oops
<fabbione> BenC: ok. trying to commit now :)
<mkrufky> awesome.....
<BenC> sure, that will work
<fabbione> BenC: hmm it didn't like GIT_COMMITTER_EMAIL
<fabbione> Signed-off-by: Fabio M. Di Nitto <fabbione@gordian.(none)>
<fabbione> but the env var is there
<BenC> sure you exported it?
<BenC> run "git-var GIT_COMMITTER_IDENT"
<fabbione> you
<fabbione> echo $GIT_COMMITTER_EMAIL
<fabbione> fabbione@ubuntu.com 
<BenC> export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
<BenC> see if that helps
<fabbione> it does.. but it's weird
<fabbione> they are in .bashrc
<fabbione> oh well crappy
<fabbione> i will lart the bash maintainer later
<BenC> if you don't export it, it's only a local var, not an env var
<fabbione> than it shouldn't take the NAME either.. but it does :)
<BenC> it got that from gecos probably
<fabbione> oh right
<fabbione> [UBUNTU:debian]  Test commit - Fix Ben C. email address.
<fabbione> Signed-off-by: Fabio M. Di Nitto <fabbione@ubuntu.com>
<fabbione> # On branch refs/heads/ubuntu-2.6.14
<fabbione> #
<fabbione> # Updated but not checked in:
<fabbione> #   (will commit)
<fabbione> #
<fabbione> #       modified: debian/changelog
<fabbione> except for the blank line between [UBUNTU
<fabbione> and the Signed off
<fabbione> do you want me to add anything else?
* fabbione commits
<BenC> nah, that looks good
<fabbione> CRANKY
<fabbione> Author: Fabio M. Di Nitto <fabbione@gordian.(none)>
<fabbione> it still got the Author line wrong
<BenC> GIT_AUTHOR_NAME/EMAIL too
<BenC> where are you committing to
<fabbione> i committed only on the local tree
<BenC> and you are going push to your rookery tree, right?
<fabbione> not with these bad info.. no
<fabbione> let see how undo works :)
<fabbione> ok perfect..
<fabbione> i am satisfied
<fabbione> Author: Fabio M. Di Nitto <fabbione@ubuntu.com>
<fabbione> BenC: git revert is fun :)
<fabbione> BenC: did put all these things somewhere on the wiki or in a doc?
<BenC> yeah, in a doc that I still need to post to the wiki
<fabbione> BenC: ok :)
<fabbione> that will be really helpful :)
<zul> yep yep
<fabbione> BenC: i think that the idea of helpers is good, but the fact that we will push into the kernel the same crack as in desktop.. hmm i am not so convinced about it
<fabbione> BenC: if you mean different configs on the same tree than i am more ok with ti
<fabbione> like disabling software suspend and stuff  like that
<svenl> hi BenC .
<svenl> about #15573
<svenl> do you have any coments ? 
<BenC> svenl: sure, I'll get it into dapper's kernel for sure
<BenC> fabbione: I meant same source tree, different configs
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: can you tell me about external-arch-i386-kernel-reboot_reboot-thru-bios?
<BenC> -static int reboot_thru_bios;
<BenC> +static int reboot_thru_bios=1;
<BenC> I think that may be causing our "machine halts instead of reboot in breezy" problem
<BenC> brb
<mjg59> I asked you to drop that patch
<mjg59> I thought we had done
<BenC> maybe it was
<BenC> nope, it was in breezy
<BenC> fabbione: ping
<mjg59> BenC: Ok. We fixed the problem another way, so it should have been removed
<mjg59> It can still be overridden with reboot=h
<BenC> scheduled for 9.24
<svenl> BenC: would have been nice to have it fixed for breezy though.
<BenC> svenl: I can think of a few dozen bugs that would have been nice to have fixed for breezy :)
<BenC> fabbione: around?
<svenl> BenC: well, sure, but this one had a patch, and was orthogonal to everything else, and the patch was written especially for ubuntu, and it would have taken maybe 5 minutes to apply it.
<svenl> BenC: and now we have to wait again 6 month to get a version of ubuntu who really works on pegasos, and we can thus not ship ubuntu DVDs which each outgoing pegasos machine.
<svenl> BenC: unless we hack the iso and produce our own kernels.
<svenl> BenC: which are a nightmare with regard to security updates.
<svenl> BenC: still, there was not even a comment on the bug report.
<BenC> considering the bug was never called to my attention until now, it's not surprising that it didn't get in
<svenl> BenC: yeah, well, the bug was filled against the ubuntu kernel package on sept 16.
<BenC> what would you like me to do?
<svenl> does this mean that the ubuntu BTS can't be thrusthed.
<svenl> BenC: i guess there is nothing to do except use a time machine :/
<HiddenWolf> svenl, what's pegasos?
<BenC> every bug has a priority, and that close to release, the patch wasn't a priority, since it wasn't a regression
<BenC> HiddenWolf: A hacker's only developer board
<svenl> HiddenWolf: the only powerpc desktop still selling.
<BenC> usually, anyone using it would be compiling their own kernel
<svenl> BenC: that is pure bullshit.
<svenl> BenC: the debian kernel works perfectly on it, and i have not seen people recompile their kernels since a long long time.
<BenC> ok, I stand corrected
<HiddenWolf> svenl, I agree it sucks, but please stay cool.
<svenl> BenC: but then, nothing ever came from the ubuntu/debian kernel co-operation tproject.
<svenl> HiddenWolf: well, i am a bit disapointed, but cool.
<BenC> svenl: look, I've only been the kernel maintainer ofr a few months for ubuntu
<BenC> so taking out your agression on me will get you ignored more than anything
<jbailey> svenl: Septembe 16th is way after most of the freezes.
<svenl> BenC: i aplogize, i didn't want to sound agressive.
<BenC> well, you were way across the agressive line
<svenl> jbailey: well, there are at least 3 ubuntu folk with pegasos machines, aren't there.
<svenl> BenC: sorry.
<svenl> jbailey: donated pegasos machines even :)
<jbailey> svenl: Sure.  And you'll notice that as soon as we moved into the new release cycle that I asked you right away about it.
<HiddenWolf> svenl, the ubuntu guys get buried under bugs. The project is still young, and the userbase has exploded. Please do the math. If you really care about a bug, you should try and take proactive action and bring it to the attention.
<jbailey> svenl: That way we can deal with it early and make sure that it's ready for the next release.
<svenl> jbailey: and not a single one of those tested breezy installs on it :)
<jbailey> svenl: Thinking of which, got a new OF for me for the yaboot CD bug? =)
<svenl> HiddenWolf: whatever, still, there are only 15k bugs in the BTS, so i wonder how this is supposed to work.
<BenC> svenl: it'll get better in dapper, and I'll try to squeeze in the fix you pointed out for a breezy update
<HiddenWolf> svenl, that is 15.000 bugs on Ubuntu main in a year.
<BenC> that's about all I can promise at this point
<svenl> Maybe i am spoiled by the debian system, but when i file a bug, i don't expect it to be ignored.
* BenC notes he has over 400 bugs on the kernel alone
<svenl> BenC: yep.
<BenC> svenl: it wasn't ignored, but bugs do take priority
<svenl> BenC: when i get no reply, it is ignored.
<svenl> BenC: proof of it is that it wasn't fixed.
<svenl> jbailey: please get yaboot fixed first, i filled a bug earlier.
<HiddenWolf> svenl, you are really not helping your case here.
<jbailey> svenl: Breezy isn't open for uploads yet.
<svenl> BenC: i wonder about the right way to handle this kind of bugs, there is a balance between letting a bug smolder in the BTS, and bothering the ubuntu guys.
<BenC> at that point, I was stretching my limits by trying to go through all the old bug
<jbailey> svenl: If you'd like guarnateed response time, we do offer support contracts. =)
<svenl> jbailey: hey, you promised me those grub2 .deb sources.
<BenC> svenl: no response doesn't mean it was intentionally ignored
<jbailey> svenl: They're on the pegasos.
<BenC> svenl: I can't send an email to all bugs saying "I got your bug, but it wont be fixed for breezy"
<jbailey> I should load up the old OF so I can boot.
<svenl> jbailey: could you send them to me ? 
<BenC> svenl: anyway, you've got my response here now, so let's move on
<jbailey> svenl: Yup
<svenl> BenC: well, i am not some random unknown guy, so you could have thrusted me more, especially as the fix went into debian the exact same day, and the fix only needed copying the patch over and adding it to the next build, it would have taken maybe 1 minute, and it only affected a module present only on the pegasos, and tested nowhere else.
<svenl> BenC: so, yes, i am happy that you didn't not send such a mail, as it would have taken you more time to apply the fix.
<svenl> but as said, enough spoken about this.
<svenl> jbailey: BTW, about support contracts, do i then get a share of the money back for the work i do on let's say parted ? 
<svenl> jbailey: so it should work both way.
<HiddenWolf> svenl, you just said "enough spoken about this"
<HiddenWolf> svenl, please leave it at that.
<jbailey> svenl: No, sorry.  But if someone with a support contract asks us to fix a bug, then we do our best to do it.
<jbailey> svenl: If we contract with you to fix a bug, we'd expect you to do that.
<mjg59> svenl: The patch in the attachment is bad, anyway. Why's it #including stuff at the end of the file? Why does it have another random hunk in it?
<svenl> jbailey: and how many time i got asked to fix parted issues and make uploads ? 
<svenl> mjg59: the patch in the debian package is fine, and was hinted to back then.
<jbailey> svenl: I can pretty much promise you so far that none of those requests have been on behalf of our customers.
<svenl> mjg59: just grab it from there.
<svenl> jbailey: yeah, whatever. just saying it goes both way.
<mjg59> svenl: The patch that you pointed at in subversion is *not fine*
<jbailey> svenl: *exactly*  We don't have any commitment from you to respond in a timely manner.
<jbailey> We don't count on it.
<svenl> mjg59: ah, yeah, strange, it builds in debian 2.6.12 and 2.6.13 and 2.6.14-rc4 packages, so ? 
<jbailey> If you're swamped with bugs, take a vacation or whatever, you'll respond when you have time or get to that point in the queue.
<svenl> jbailey: yeah, i am not convinced.
<mjg59> svenl: Why does it contain code that's nothing to do with the problem being solved? Why does it have a #include on line 1600?
<jbailey> *shrug*
<svenl> jbailey: but let's not speak about this.
<jbailey> I'm not trying to convince you of anything.
<svenl> mjg59: let me check.
<svenl> +#include <linux/pci.h>
<svenl> this one ? 
<svenl> mjg59: to be able to do +               { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360) },
<mjg59> Yes. Put it with all the other #includes.
<mjg59> And what's the first hunk of the patch all about?
<svenl> mjg59: i agree that it could be put in front, but it is cosmetic.
<mjg59> What's the status of this patch? Is it being pushed upstream?
<svenl> mjg59: you may want to rediff it anyway.
<svenl> mjg59: it will be pushed upstream.
<svenl> # Upstream status: In the process of being submitted, may need a bit of
<svenl> # cleanup in order to not break embedded arches using this controller, but
<svenl> # should not be a worry for debian.
<svenl> nor ubuntu either.
<mjg59> svenl: So you're complaining that a patch that isn't even guaranteed to apply against the tree you want it applied to wasn't applied?
<svenl> mjg59: well, am i supposed to do your job also.
<svenl> mjg59: chances are very very good that it applies, unless you have patched this file yourself, but as it is used only for embedded stuff, you probably didn't.
<mjg59> If you want an enhancement added, then it's far more likely if you make it as easy to do so as possible
<mjg59> Which includes fixing cosmetic issues and making sure that the diff doesn't include random other shit
<svenl> mjg59: also, i have no idea.
<svenl> mjg59: you all suck.
<svenl> mjg59: that are just excuses.
<svenl> and you perfectly know it.
<zul> okie dokie
#ubuntu-kernel 2006-10-16
<tfheen> BenC_: can you please mark the bugs fixed with the latest kernel upload as fixed or untarget them from 6.10?
<two-face> Hi
<two-face> Coud someone please help me with bug #61987?
<two-face> well ..
<tfheen> BenC_: I closed most of the bugs, but bug 57146 is still listed; please fix that when you get aroud.
<zul> grrr...stupid opensolaris
<fabbione>    8     0  488397112 sda
<fabbione> ^^ Firewire 800 disk :)
<zul> cool
<fabbione> now let see if i can get this Apple USB TV card to work in linux :)
<zul> what are you gonig to use it for?
<fabbione> storage and video recording.. in theory the Mac can boot from it
<zul> sweet
<fabbione> so i am pondering a real dual boot machine
<pfs> hello
<fabbione> neuralis: so what's the bug?
<newz2000> Hey foks, got an opportunity to try and diagnose a problem we've been having with several of our servers and dapper's kernel.
<newz2000> foks == folks
<newz2000> We have 6 servers and while they boot ok with dapper, the network doesn't come up.
<fabbione> newz2000: ok.. mind to explain?
<fabbione> does it work in edgy?
<newz2000> we don't have physical access to the server, so we need to be careful...
<siretart> hi
<newz2000> can we test edgy's kernel reasonably safely?
<newz2000> (siretart is the admin for the server we're currently diagnosing)
<fabbione> newz2000: hold on.. what kind of server? can we get lspci? dmesg and all the other stuff?
<fabbione> ah ok
<fabbione> siretart: we need the usual things to understand what's the problem
<fabbione> does the kernel recognize the eth at all?
<siretart> fabbione: 2.6.12 without any problems
<newz2000> I have an idea, where we could create an rc script that waits 5 min and tries to ping or something. If failure, replaces grub menu and reboots.
<fabbione> what chipset is that?
<newz2000> Grabing whatever diagnostic we need.
<fabbione> newz2000: one thing at a time...
<siretart> fabbione: http://paste.debian.net/14983
<newz2000> you bet
<siretart> fabbione: this is the kernel output when 2.6.15 is up (and no network available)
<siretart> >> lspci
<siretart> 0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II]  (rev 78)
<siretart> 0000:00:12.0 0200: 1106:3065 (rev 78)
<siretart> anything esle I can provide?
<fabbione> one second..
<fabbione> siretart: i guess those machines don't have iLO or something like that.. do they?
<fabbione> i would try to boot with acpi=off 
<siretart> iLO?
<fabbione> siretart: remote console management
<fabbione> that **** SET: Misaligned resource pointer: debbb722 Type 07 Len 0 is kind of scary
<siretart> fabbione: no that I knew. If it has, heno or newz2000 should know about
<newz2000> we don't have remote mangement.
<siretart> I would have tried pci=noacpi
<newz2000> Which is why I sugested the auto-reboot idea before we start testing too much.
<fabbione> who has phisical access to the machines?
<newz2000> server admins
<newz2000> not us
<siretart> I was reading grub manual for how to setup a failsafe grub with autoreboot in case the machine doesn't come up, wanted to try that tomorrow
<fabbione> who are the server admins?
<siretart> serverpronto.com
<fabbione> ok
<newz2000> siretart: the computer boots ok now.
<newz2000> disabling acpi probably won't change that
<newz2000> we need a "reboot on no network" I think.
<fabbione> newz2000: if you don't have phisical access, that's the only way
<fabbione> just make sure to do it properly
<newz2000> fabbione: Seen anything out there pre-made?
<fabbione> nope
<fabbione> anyway i would still try the acpi=off
<fabbione> drivers/acpi/resources/rslist.c:                              "Misaligned resource pointer %p", resource));
<newz2000> what kind of diagnostic info would be useful from a running but non-network accessible kernel?
<newz2000> Something of the form of xyz > /tmp/reboot.log
<siretart> the thing is that I need to leave RSN, but will be available tomorrow again
<newz2000> siretart: let me make sure I have access to the server. I can do this.
<fabbione> newz2000: i would check if arp is working to see where the driver breaks.. mii-tools to see if the chip is powered on properly and there is network cable detected
<fabbione> once you have arp/mii-tols you can go up for an icmp test with ping
<newz2000> siretart, what is the IP on that server?
<fabbione> you don't want to save in /tmp
<fabbione> it's cleared on each reboot
<fabbione> use /root or something that's permanent
<newz2000> oh. Yes, that's bad. 
<newz2000> ok
<newz2000> siretart: nm, I'm in.
<newz2000> siretart: can you withstand a little downtime if I work on this for a bit?
* newz2000 assumes so or it wouldn't have been upgraded
<siretart> newz2000: it would be nice if you could announce that on #ubuntu-motu
<newz2000> ok.
<siretart> newz2000: and shutdown vsftp, postgres and apache2
<siretart> these services are needed for revu, if they are off, nothing bad can happen [tm] 
<newz2000> won't that happen gracefully on reboot? (i.e. aren't your rc.? scripts good?
<siretart> sure, they will be started
<fabbione> and shutdown too
<siretart> I'm rather afraid of broken imports while shutting down
<siretart> but thats only an unlikely chance to happen
<siretart> more likeley ppl on #ubuntu-motu will screem
<newz2000> ok, so I should announce, and wait for people who might be working to finish before rebooting.
<siretart> that would be nice. but otoh, we are >< close before release, and revu isn't likely to be used ATM
<siretart> we have other things to do at this point
<newz2000> ok, I'll announce.
<siretart> ok, need to run now
<newz2000> siretart: thanks
<siretart> I'll read the backlog in this channel!
<siretart> newz2000: thanks that I leave now? ;)
<newz2000> siretart: thanks for giving us the opportunity to figure this out. :D
<siretart> ;)
<newz2000> fabbione et al: what do you think about this: http://rafb.net/paste/results/GbXvjW41.html
<newz2000> any suggestions for a better way to ensure it doesn't run continually?
<newz2000> any other useful data that can be included there?
* newz2000 is testing it locally first
<newz2000> good thing I tested. :D Missing space in the if statement.
<neuralis> fabbione: around?
<fabbione> neuralis: yes
<newz2000> fabbione: can I confirm: The best way to boot with acpi=off is to add that to the end of the kernel line in grub?
<fabbione> newz2000: yes
<newz2000> thanks. Just giving people a chance to finish then will try it.
<zul> BenC_: we are using -rc2 now are we?
<newz2000> fabbione and others: acpi=off didn't seem to work. I've opened a reboot ticket as my reboot script also didn't work.
<newz2000> This implies something else is going on, because I tested the reboot script and believe it works.
<newz2000> The server company has a note on their support site explaining a patch may be needed to support the hardware.
<newz2000> https://serverpronto.infolink.com/modernbill/user.php?op=menu&tile=faq&_j=questiondetails&_id2=13
<BenC_> zul: I'm updating to latest git almost daily
<zul> okie dokie
<mjg59> newz2000: It's not possible to view that page without a login/password
<newz2000> oh, sorry. I'll pastebin it.
<newz2000> http://rafb.net/paste/results/LygzfM71.html
<fabbione> hey BenC_ 
<fabbione> BenC_: i just plugged a 500GB firewire drive to my PB :)
<fabbione> BenC_: works like a charm
<fabbione> BenC_: btw i did look at sparc-utils FTBFS.. it's code that you already touched (that infamous _syscall1 in sparc32.c)
<fabbione> BenC_: it should be really easy for you to fix it.. and i really have no clue what's complaning about
<BenC_> fabbione: Ok
<fabbione> BenC_: thanks a lot dude...
<fabbione> i am calling it a day and heading to bed
<fabbione> 15 hours in the day .. i am trashed
<BenC_> g'night
<ivoks> 'night
<zul> c ya fabbione 
<shwag_> Not sure who I need to talk to about this. Edgy doesnt support my ethernet nor my wireless drivers on my dell laptop, but they both work fine on dapper.
<shwag_> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/66454
<carthik> Hi, for laptop suspend/hibernate etc bugs, should I assign or subscribe the kernel team? Thank you.
<shawarma> carthik: I've been told you should never assign them to anything, but at most subscribe them.
<carthik> shawarma, thank you.
<shawarma> carthik: Nevertheless, launchpad usually have sane defaults for subscribing the right teams to stuff.
<shawarma> carthik: ...so if you have guess the right package (in your case either the kernel or acpi-support), the right teams should be assigned automatically.
<carthik> shawarma, True. Maybe I should set the package to acpi-support. Thank you.
<shawarma> carthik: any time.
<crochat> Where can I see the list of "specialy" added modules, like "r1000" or "ipw3945" in the Ubuntu kernels ?
<shawarma> crochat: As in modules not available in the vanilla kernel?
<crochat> shawarma: Exactly
<tfheen> you can't easily, AFAIK
<tfheen> oh, or read debian/README.Ubuntu-External-Drivers in the source.
<crochat> I've corrected some issues with libata in the 2.6.18, and now, I need to have the same added modules as in the 2.6.15 from Dapper ;-)
<zul> later
<crochat> tfheen: Where did you get the file README.Ubuntu-External-Drivers ??
<tfheen> crochat: from the source package
<crochat> tfheen: I searched a lot in many packages... but I didn't found any detailed information like that...
<crochat> tfheen: In the Ubuntu package "linux-source-2.6.15-27" ?
<tfheen> in the source package named linux-source-2.6.17, not the binary package of the same name, no.
<crochat> tfheen: Oh, I see... Since Edgy, the addon modules seems to be in separated packages
<crochat> tfheen: Ok, I'll lose too much time trying to integrate the Ubuntu addon modules in the 2.6.18 tree
<crochat> tfheen: So I have to apply a patch made for the 2.6.18 in the Ubuntu 2.6.17 tree... do you think it should be possible ?
<crochat> tfheen: It's a correction against the sata timeout
<crochat> tfheen: The messages like: "ata2 is slow to respond. Please be patient"
<tfheen> crochat: should be easy enough, I'd imagine.
<tfheen> just pull down the git tree and cherrypick the patch
<crochat> tfheen: I found this patch to solve my timeout problems, but the patch was "only garbadge" (picked up from a mailing list), so I made another patch, that I pasted here: http://pastebin.ca/205444
<newz2000> what problems might arise from running an edgy kernel on dapper?
<tormod> newz2000, should be safe from what I have heard.
<newz2000> tormod: thanks, will give it a try I think.
<shawarma> crochat: You should file a bug in launchpad and attach your patch there. Additionally, it might be a good idea to post it on lkml.
#ubuntu-kernel 2006-10-17
<siretart> we are trying to build a custom kernel based on the ubuntu kernel sources
<siretart> the problem:
<siretart> vmhost:~# modprobe ide-core
<siretart> ide_core: Unknown symbol touch_nmi_watchdog
<siretart> FATAL: Error inserting ide_core (/lib/modules/2.6.17.13-ubuntu1-fai-kernels/kernel/drivers/ide/ide-core.ko): Unknown symbol in module, parameter (see dmesg)
<siretart> does anyone has an idea which kernel option must not be selected as module but must be compiled in for this to work?
<fabbione> CONFIG_X86_LOCAL_APIC
<gnomefreak> what are chances of initramfs-tool causing an unstable interneet connection?
<fabbione> 0
<gnomefreak> so i should still expect the issue
<tfheen> -5, more likely.
<gnomefreak> it hasnt happened since the initramfs-tools update
<makx> fabbione: thanks for the edgy i-t fixes :)
<fabbione> i-t???
<makx> oh ups it was infinity sorry
<fabbione> ah
<makx> initramfs-tools
<infinity> makx: Cnofusing me with Fabio is pretty hard...
<infinity> makx: He's, like, 12 times my size.
<fabbione> infinity: and 12 times prettier
<fabbione> :)
<infinity> Uh huh.
<zul> heh
<infinity> zul: I'll bug you another day about whatever it was I wanted to bug you about... I'm going loopy from having worked ~15 hours today, so I think I'm going to go let my brain fizzle in the corner.
<zul> infinity: sure no problem ill let your brain go pop
<makx> infinity you had a patch of having all those modules one/line
<makx> do you have it still lying around?
<makx> sorry never met fabbione nur you infinity in rl :)
<porkpie__> BenC:hi .....did you manage to build the kernel for the PE 1950 ???
<Trae> Keybuk, sorry about the bug post.  Just very frustrated.
<Keybuk> you can imagine how the developers feel?
<Trae> It's a classic example of "Works for me" 
<Trae> heh
<Keybuk> your mail read like "IF THIS ISN'T FIXED, I'M NEVER USING UBUNTU AGAIN!"
<Trae> If it doesn't affect you, life is good. :)
<Trae> I never said that
<Keybuk> no, but that's how it read
<Trae> no...
<Keybuk> look at the last line of your mail
<Trae> It was... a "I really love Ubuntu and hate to have to even THINK about using anything else" post.
<Trae> yeah... have they dealt with the bug, or have they switched distro's.  There are only two options.
<Keybuk> you say yourself that most other distros are also affected by this bug
<Trae> Either deal with the bug, or use another distro.  There is no grey area there.
<Trae> At any rate.
<Trae> yah
<Trae> that is true
<Trae> Keybuk, the odd thing is, it was working with Breezy before hand.  :/ 
<Trae> anyway
<Trae> Is there someone that can help me compile a new kernel?
<Keybuk> right
<Keybuk> this is a kernel problem
<Keybuk> or more likely an ACPI virtual machine problem
<Trae> I know this isn't the "Help Trae with kernel issues" channel
<Keybuk> it really needs a line-by-line diff of a kernel that works and a kernel that doesn't
<Keybuk> trying different patches until one finds the line of code that breaks/fixes it
<Trae> Keybuk, yeah, and that sounds scary.  
<Keybuk> it is scary
<Keybuk> your bug is scary
<Keybuk> if you had a nice, simple one like "Applications is spelt wrong" then it would be easy :p
<Trae> haha
<Keybuk> can you get to Mountain View in a couple of weeks time?
<Trae> heh
<Keybuk> https://wiki.ubuntu.com/KernelCustomBuild
<Trae> I've been  unemployed for about 3 months
<Trae> doubt I can afford to fly out to Mtnview
<Trae> Would  love to.... 
* Trae used to live on Rock St. heh
<Trae> from the wiki: You got to this page by mistake, but checked it out because it looked interesting. Believe me, this isn't interesting at all
<Trae> haha
<zul> argh...i was 4 tickets away from winning a raffle
<Infecto> hi all 
<Infecto> thanks for repering bug :) https://launchpad.net/distros/ubuntu/+bug/65005
<Infecto> in part only :) 
<Infecto>      Thermal 1: active[1] , 55.0 degrees C
<Infecto>      Thermal 2: ok, 56.0 degrees C
<Infecto>      Thermal 3: ok, 21.0 degrees C
<Infecto> Thermal 2 should be active to 
<mjg59> Why?
<mjg59> What are its trip points?
<Infecto> its to hoot 
<Infecto> to to to 
<Infecto> and works difrend when i restart 
<Infecto> after resume forms suspend to ram the steps are changing 
<mjg59> What are thermal 2's trip points?
<Infecto> critical (S5): 115C
<mjg59> So no, thermal 2 shouldn't be active
<Infecto> ehn i restart it will be 
<Infecto> when 
<Infecto> 115 its to much 
<mjg59> I don't think that information means what you think it means
<Infecto> hmm 
<Infecto> but the true is that the steps are changing when i restart 
#ubuntu-kernel 2006-10-18
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-10.33 uploaded. Most likely the final edgy kernel | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | KernelFreeze in effect | edgy+1 kernel https://wiki.ubuntu.com/KernelDevelopmentShift
<fabbione> BenC: you still alive
<fabbione> ?
<BenC> sort of
<fabbione> nothing importnat.. i was just reading the docs for .19 kernel
<fabbione> are you already merging stuff?
<fabbione> if so.. gfs2 should be taken fully from upstream (and not in ubuntu/fs)
<fabbione> drop gfs1 and i will readd it later
<fabbione> (less merging pain for you)
<fabbione> i think the only other bit i was touching was dlmfs, that one can come from upstream too (together with gfs2)
<infinity> BenC: What are the odds of another kernel upload before we release?
<BenC> fabbione: gfs2 and dlm are from stock, I already got gfs1 in there and compiling
<infinity> BenC: (And if there is one, can you sneak the ia64 header fix in, so klibc is no longer FTBFS?)
<BenC> infinity: slim
<infinity> Alright.  Can you sneak it in anyway, "just in case"? :)
<BenC> can you email me about the fix? I'll forget by morning :)
<infinity> BenC: jbailey filed a bug.
<BenC> I'm a little backed up on bugs
<infinity> Which, of course,I can't look up due to LP being down..
* infinity checks his mailbox.
<fabbione> BenC: cool.. i will make sure to update it then
<infinity> [Bug 66253]  Missing header in linux-libc-dev causes FTBFS in klibc on ia64
<infinity> BenC: ^^^
<BenC> infinity: Ok, I have it open in firefix now, so that should remind me
<infinity> Danke.
<crochat> Hello !
* bluefoxicy pokes with Malone #66820 if anyone's interested, it's also linked to the kernel bug tracker.
* bluefoxicy then heads out to get food
<mdz> unless the kernel skins and eats kittens it's finished for edgy
<BenC> mdz: Good to know, I have a bug report about a skinned kitten, but it was never eaten
#ubuntu-kernel 2006-10-19
<bluefoxicy> mdz:  nah, it doesn't skin and eat kittens, it just cries about missed IRQs
<bluefoxicy> mdz:  the related bug on the kernel bug tracker says it sometimes breaks other (perfectly working) hardware; but I haven't personally seen that symptom
<kinema> Are there any 2.6.18 kernel packages availiable anywhere?  The module for my NIC wasn't mereged until 2.6.18rcsomething
<gnomefreak> kinema: kernels.org
<kinema> I would tell you that I was looking for packaged beta Ubuntu kernels but I'm assuming that you already knew that.
<zul> no there is no 2.6.18 for ubuntu
<Trae> how do you do the apt-get install kenrel-headers`uname-r`  trick.  (or is what I typed it?)
<tfheen> Trae: type it just as that, yes.
<Trae> tfheen, thank you kindly
<infinity> s/kernel/linux/
<tfheen> except it's linux-headers- and not kenrel-headers . :-P
<tfheen> (not the dah)
<tfheen> dash, even
<Trae> oh
<gnomefreak> tfheen: i subscribed you to a bug report more of a request someone filed to update opera in commercial repos. Its not important but i understadn you were the dev that did that
<infinity> Even better would be "apt-get install linux-headers-`uname -r | sed -e 's/[0-9\.-] *//'` ... But I guess that's slightly harder to communicate.
<tfheen> gnomefreak: yes, I'll tend to it when edgy is out.  I'm absolutely drowned in the release now.
<gnomefreak> i figured that
<gnomefreak> just wanted to let you know about it
<tfheen> yeah, np
<tfheen> it's not fallen off my radar, just not prioritised ATM
<Trae> hmm shouldn't apt-get install linux-headers-`uname-r`   automagically install the right one?
<Trae> errm... linux-headers`uname -r`  heh
<infinity> Trae: It'll install the right one for now, but if you have the "linux-686" and "linux-headers-686" packages installed (for instance, pick your flavour), then the kernel and headers will get updated together with security updates, etc.
<infinity> Trae: linux-headers-`uname -r` even.  You missed the dash.
<Trae> hmm thought I tried it both ways
<infinity> (Note that there's nothing magic about `uname -r`, it's just shell substitution that means "echo the output of the command 'uname -r'")
<Trae> there it goes
<Trae> I must have typed something wrong
<Trae> hehe
<Trae> sorry and thanks
<gnomefreak> oh cool that never worked for me before :)
<scoates> anyone particularly good with kernel modules? http://sourceforge.net/forum/forum.php?thread_id=1595813&forum_id=278158 .. this is on edgy
#ubuntu-kernel 2006-10-20
<Administrator> 2.6.17-10.33 kernel panics
<Administrator> at least the current one of that version in edgy, is that a known bug?
<infinity> Administrator: You might have to be a bit more specific.
<Administrator> infinity, ill report more detailed error in a min or 5/10.
<Administrator> infinity, kernel panic not syncing: attempted to kill init kernel_thread helper| above the ther error messg |  process swapper and kernel trehad helper i running 2.6.17-10 generic
<Administrator> I can debug further, i do not have a serial console or whatsoever..
<infinity> If you can take a picture of the panic, perhaps?
<infinity> I have to run, but Ill be back in 20/30.
<Administrator> infinity, you there?
<Administrator> i can send you ...
<Administrator> through mail or dcc ...
<infinity> adconrad@ubuntu.com
<infinity> Though, once we determine that it's a bug, and in what package, I'd prefer if you file a bug and attach the image. :)
<Administrator> i am a bit bussy today, i'll mail you the images asap and at the end of the day i'll file the bug if things calm down a bit.
<Trae> what package is mkinitrd in?
<makx> you update-initramfs from initramfs-tools
<infinity> mkinitrd is well and truley obsolete.
<makx> yes bug on ftp.debian.org is placed, it will soon be gone
<Trae> A friend of mine was trying to help me get a fresh kernel compiled
<Trae> he doesn't run Ubuntu though, he runs Gentoo
<zul_> different ways of working but we dont use mkinitrd as infinity said
<Trae> I'm in /usr/src/linux (it's a symlink to /usr/src/linux-2.6.18.1   I've already done make && make install && make modules_install  and edited grub.  
<Trae> I got a kernel panic though when It tried to boot
<Trae> Cannot open root device hda1
<Trae> it says put in a valid root= thingy
<Trae> heh
<zul_> Trae: check the wiki there is documentation on how to compile a kernel
<makx> why do you want a hand build kernel?
<Trae> makx: you haven't seen me whinging in here aboutthe laptop overheat bug? :)
<Trae> makx: hehe
<Trae> I'm a graphic designer, dealing with this kernel stuff is way over my head sadly.
<makx> hehe is not a reason :-P
<Trae> :P
<Trae> so here is the odd thing
<makx> yes so use the provided linux images
<Trae> oh let me find the bug
<Trae> https://launchpad.net/bugs/22336
<Trae> check this out... I was able to compile the kernel for like an hour without the laptop overheating or rebooting
<Trae> yet 4 mins of playing a Youtube video, and the thing shuts down on me!?
<makx> hmm mjg59 is not around he is the local acpi guru
<makx> Trae what release are you using?
<Trae> Dapper Drake
<makx> did you try the Edgy release candidate - the live cd?
<Trae> I tried beta
<Trae> hmm
<makx> and?
<Trae> no haven't tried the RC
<Trae> the Beta had the sameproblem.
<Trae> I will try the RC though
<Trae> and of course use the Final
<makx> beurk
<makx> hmm if i were you i'll wait for the acpi master to show up
<infinity> Trae: Laptop overheating bug?
<Trae> infinity: https://launchpad.net/bugs/22336
<infinity> Okay, this is sad to admit, but I suffer from this bug, and just "cope".
<infinity> I'll get my laptop in front of BenC and mjg59 in Mountain View, and see if the three of us can nail it down.
<infinity> It actually seems to be bad hardware design mixed with slow response times on throttling.
<thom> mjg59's not gonna be there afaik :(
<Trae> like clockwork
<infinity> (The bad hardware design in my case being that the video RAM is WAY too close to the CPU, and when I overheat in a split second, the video corrupts and the machine crashes)
<Trae> 4mins into the youtube video and kerpow
<Trae> heh
<infinity> thom: Oh, well, BenC and I can deal then.
<Trae> infinity: really you have this too? 
<Trae> infinity: you a kernel developer?
<Trae> infinity: w00p!
<Trae> wish I was going to be in Mtn View too.
<Trae> infinity: whoa,that's quite insightful
<Trae> re: ram being too close
<Trae> infinity: I will volunteer to help you do whatever you need on this laptop.  Even give youguys ssh access if need be
<zul_> infinity: ill be there as well
<Trae> infinity: traemccombs {at} gmail d o t com
<Trae> :)
<Trae> I'll try and lurk here in case you might need me.
<Trae> Keybuk: morning!
<Trae> :)
<Keybuk> heyhey
<Trae> Keybuk: infinity says he suffers from the same bug!
<Keybuk> oh, that's cool
<Trae> Keybuk: and is going to work with BenC in Mtn. View
<Trae> Keybuk: sucky for him, good for us hopefully.
<zul> argh...who the hell puts their log files in html
<infinity> MSN messenger?
<zul> no exceed on demand
<infinity> Trae: I can't say if it's the *same* bug, as the variables (CPU type, drivers involved as a result, etc) are pretty different, but the end effect is certainly the same (rapid rise in temperature, throttling and/or cooling not kicking in fast enough to cope)
<infinity> Trae: So, it could be an underlying timing bug that lives a bit higher up the stack than the individal CPU power drivers.
<infinity> Trae: Anyhow, I don't have any time (or the knowlege of that part of the codebase) to look at it in the next week, so there's no hope of it making edgy, but maybe we'll work up some patches for you to test a few weeks after release.
<Trae> infinity: no worries, as always, triple my money back if I'm not 100% satisfied :)
<tuxmaniac> Hi All.
<tuxmaniac> My Card reader on my Compaq laptop not working since I updated to the 2.6.17 series
<tuxmaniac> It worked in the Dapper kernel versions
<Keybuk> BenC: around?
<BenC> Keybuk: yeah
<Keybuk> BenC: have been trying to trace the reboot() syscall to find out whether the kernel actually calls sync() before powering down or not
<Keybuk> but not having much luck
<BenC> Keybuk: I don't know for sure, but I do know that I see scsi disk sync messages on reboot on power down
<BenC> filesystems should sync on umount (or remount ro)
<mjg59> infinity: On your Thinkpad?
<BenC> and I think the block layer handles hw level syncs for any devices with dirty cache
<infinity> mjg59: Yeah.
<infinity> mjg59: I can blow it up pretty spectacularly.
<infinity> mjg59: It *seems* to be heat/throttle related, but given that the same sort of things that generate heat also do other evil things to one's system, I can't be completely sure.
<mjg59> infinity: Entirely not Linux's problem
<infinity> Well, in the words of the bug submitter, "I can't reproduce this in Windows".
<mjg59> As far as I can tell, at least. Is it really getting to more than 91 degrees?
<mjg59> When I say "not Linux's problem", I mean "The hardware may be making assumptions that are not guaranteed"
<mjg59> Thinkpads don't have any OS-level fan control
<mjg59> And they're not supposed to throttle until 90 degrees CPU temp or so
<infinity> Yeah, I've been curious about that.
<infinity> Fan usage patterns seem drastically different in Win32 and Linux, but I'd swear the kernel does no fan control.
<infinity> So I have no idea WTF is up with that.
<mjg59> If you have no /proc/acpi/fan/*, the kernel does no fan control
<infinity> I do not. :)
<mjg59> For whatever reason, Windows probably drives the hardware in such a way that it generates less heat
<infinity> The only time the fan on this EVER spins into vacuum mode is on POST.  Which is worrying.
<infinity> (In Windows, it'll vacuum every once in a while on its own)
<mjg59> The processor is probably never getting hot enough to trigger it
<Keybuk> BenC: hmm, I'm trying to determine whether the "sync(); sleep(2)" is necessary in /sbin/reboot
<Keybuk> we already know that ifdown'ing the interfaces and putting the drives to standby is unnecessary
<BenC> Keybuk: Probably not necessary, but "better safe than sorry"
#ubuntu-kernel 2006-10-21
<zul> BenC: do you need a newer udev for 2.6.19?
<BenC> zul: Don't think so
<zul> ok
<zorglu_> q. i got a dapper on 2.6.15-26-386, and it just trashed (aka disk active all the time and no more answering ping), i rebooted and /var/log/message is full of oom-killer, is there a way to determine the source of this ?
<zorglu_> like the name of the process which consume the memory so suddently
<neuralis> there's no guarantee that it was any one process, and discovering which process the oom killed, in particular, will not give you much of any useful information.
<zorglu_> well it was a box which was running not doing anything but running a azureus bittorrent (which was not transfering anything)
<zorglu_> and from /var/log/message all the swapped was used
<zorglu_> usually on the same condition, it has like 380 of free ram + 1gbyte of swap free
<zorglu_> so something did consume this 1.4gbyte of memory :)
<zorglu_> and quite 'out of the blue' as the box was not doing anything i know of
<neuralis> i don't really care about the situation on your machine; i was merely answering your question.
<zorglu_> ok :)
<zorglu_> so anybody around willing to help ? 
<neuralis> i don't see what kind of help you're looking for. in general, no, it's not easily possible to figure out which conditions led to an oom after you've rebooted.
<zorglu_> well i would like to determine what caused this box, which was quite idle, to use 1.4gbyte
<zorglu_> so i ask for more info
<zorglu_> to people who may care :)
<neuralis> yes, and i just told you that it generally can't be done.
<zorglu_> ok will retry later on a more active hour, see ya
<neuralis> sigh.
<fabbione> neuralis: hey dude
<neuralis> fabbione: hey, i was sick all week and never made it to the office
<fabbione> neuralis: feeling better now?
<neuralis> somewhat, i can mostly walk now
<fabbione> neuralis: ouch
<fabbione> neuralis: i did install the t2000
<neuralis> ah, cool. so you did the bios upgrade?
<fabbione> i left a text file in /root of the gw what i did install and changed
<fabbione> no, i didn't do the alom update. the machine can work without but crashes at reboot
<fabbione> and there is no way on earth to backport the driver to dapper
<fabbione> it pulls in too many changes all over
<fabbione> so we will need to live with edgy
<neuralis> that was my suspicion when i dug around git, yeah :/
<fabbione> the major bloker are the changes to the scsi_sas transport layer
<fabbione> otherwise it was a matter of a sed call to revert mutex to semaphores
<neuralis> gotcha. yeah, i remember looking at the scsi_sas stuff and thinking that's not going to fly..
<fabbione> nope
<fabbione> i did install on sdb btw.. 
<fabbione> you can trash the install if you want
<neuralis> well, it's unfortunate we can't have a lts release on it, but edgy works well, so it's probably not that big of a deal.
<fabbione> the gw is all set for you to grab a new installer and do a netboot/netinstall
<neuralis> great, thanks.
<fabbione> just read the file i left there
<neuralis> yep, read it already.
<fabbione> i also created an account for me on the ALOm, so you can change the admin passwd
<neuralis> will do.
<fabbione> and you did place eth0 on the external network btw
<fabbione> it took me a while to figure it wasn't on the internal one :)
<neuralis> i didn't have a static ip allocated for the machine yet, so it was just picking up an external ip from dhcp, yes
<neuralis> i'll create a short page on the wiki about the t2000 rev2 requiring edgy, so there's record of it.
<neuralis> by the way, do you know why the machine has a pci card with an fpga on it? 
<neuralis> i sort of boggled when i saw that
<fabbione> soirry had to go for my son
<neuralis> np
<fabbione> yeah i know about the dhcp.. i configured .21 static 
<fabbione> the pci card you saw is the ALOM
<fabbione> it's ppc based card.. 
<neuralis> right, i figured, but i'd have assumed they pressed their own asics for that. why on earth an fpga? 
<fabbione> no idea
<neuralis> maybe it's cheaper if they're doing really low volumes..
<fabbione> same volumes as Niagara's :)
<neuralis> yeah
<fabbione> ok i am off again to play with my son
<fabbione> ttyl
<neuralis> cheers
<neuralis> oh, by the way
<neuralis> am i misremembering, or does d-i not have a way of running a b&w install (i.e. not sending the ansi color codes)?
<fabbione> it does autodetect :/
<fabbione> neuralis: look for sparc64-installer spec for feisty
<fabbione> it will make you happy
<neuralis> okay, cool. yeah, partitioning with boot on raid and root on lvm on raid took about 2 hours over 9600bps. 
<MouseJstr> If I was hoping for a new pre-built kernel variant, should I just add a note to the effect in the EdgyIdeas/Kernel wiki page?
<freeflying_> malone #67458
<justin420> hi all. anybody help with building a kernel on ubuntu dapper the correct ubuntu way? that includes the ubuntu splash image? and all other ubuntu features?
<crimsun> wiki page. (topic)
<Xal2> Hi
<Xal2> are the daily kernel builds built with the latest kernel?
#ubuntu-kernel 2006-10-22
<Hobbsee> anyone around here today?  i know it's a sunday
<crimsun> (sort of)
<Hobbsee> i've found out a few regressions from dapper, with wifi cards not being detected/not working in edgy.  i've got no idea if it's too late to fix bits of this
<tfheen> it's too late.
<Hobbsee> okay
<tfheen> sorry, but I just can't take the risk of new kernel at this point.
<tfheen> maybe edgy-updates.
<Hobbsee> tfheen: yeah, fair enough.  that would be a candidate for edgy updates?
<Hobbsee> tfheen: it was more of a question of "do you guys care about fixing it at all, for edgy"
<Hobbsee> or just say "wait till edgy+1"?
<tfheen> depends on what cards it is, I guess, but -updates is not my domain.
<Hobbsee> tfheen: fair enough.  an atheros card, and a few others.
<Hobbsee> tfheen: who's the contact for -updates?
* Hobbsee kicks her brain for not working
<tfheen> atheros is madwifi-ng, isn't it?
<infinity> Indeed.
<Hobbsee> tfheen: https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.17/+bug/66176  i believe it's in l-r-m, it's certainly madwifi
<tfheen> puppies are wonderful small creatures.
<tfheen> hmm, make sure that guy isn't using network-manager
<infinity> Hobbsee: That thread is bordering on useless, mind you. :/
<Hobbsee> infinity: it was partly a test in "what woudl they do, being asked for info"
<infinity> Hobbsee: Like the "my ipw2200 doesn't work" guy.  If the ipw2200 driver was broken, we'd definitely know.  I suspect a large number of these people are seeing non-kernel bugs, or have configuration issues.
<Hobbsee> infinity: but yeah, i know
<Hobbsee> true that
<Hobbsee> like i say, it was a question of "if the developers want to know about this, then what sort of stuff will they give back?  useful, or not?"
<Hobbsee> which the answer is mostly no, of course
<tfheen> if ipw2200 was broken, half the development team would be unable to work and we'd all be screaming at the top of our lungs. :-)
<Hobbsee> hehe
<Hobbsee> yeah, i thougth so
<infinity> Exactly. :)
<infinity> Though the same goes for madwifi, really.
<Hobbsee> yeah, well
<infinity> And, while it's perpetually "half broken for a few bits of hardware", it can't possibly be as bad as it's made out.
<Hobbsee> true that.  works fine here.  mind you, my marvell card...
<infinity> Yeah, that's a different story.
<Hobbsee> apparently it has drivers distributed, but arent activated by default.  *shrugs*
* Hobbsee shuts up about things that she only partially understands
<ivoks> zul: shouldn't xen depend on bridge-utils?
#ubuntu-kernel 2007-10-15
* #ubuntu-kernel  [freenode-info]  if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
* Starting logfile irclogs/ubuntu-kernel.log
<kraut> moin
<Kano> hi, how about adding dm.h to let truecrypt compile to headers package?
<TheMuso> Kano: Its kinda a bit late for gutsy now.
<Kano> you usually update kernel later too
<elmarco> hi
<elmarco> I had some trouble with gutsy upgrade on T60
<elmarco> [ 6986.340000]  device-mapper: table: 254:3: linear: dm-linear: Device lookup failed
<elmarco> [ 6986.340000]  device-mapper: ioctl: error adding target to table
<elmarco> this is spamming the console
<elmarco> and udevd is growing fast in memory (about 80mb now)
<elmarco> somehow, could it be related to my hd not being lvm, and having a HPFS/NTFS partition?
<mjg59> elmarco: Remove evms
<Lutin> anyone has some time to have a look at bug #129910 ?
<ubotu> Launchpad bug 129910 in initramfs-tools "tty[1-6]  are active but display nothing in Gutsy" [Critical,Triaged]  https://launchpad.net/bugs/129910
<Lutin> .w 15
<Lutin> err. sorry
<elmarco> mjg59: merci Matthew, will try that
* lamont  looks at http://launchpadlibrarian.net/10002934/buildlog_ubuntu-gutsy-hppa.linux-backports-modules-2.6.22_2.6.22-14.7_FAILEDTOBUILD.txt.gz and wonders if -14.9 is expected to fix that
* Starting logfile irclogs/ubuntu-kernel.log
<Lutin> for the nth time ..... would anybody be kind enough to dedicate five minutes of his precious time looking at bug 129910 ?
<ubotu> Launchpad bug 129910 in initramfs-tools "tty[1-6]  are active but display nothing in Gutsy" [Critical,Triaged]  https://launchpad.net/bugs/129910
<cypherdelic> My Gutsy still spawns to BusyBox and I have to manually luksOpen my encrypted LVM. Any Suggestions??
<maks_> try to pass rootdelay=9 or appropriate to boot cmd
<cypherdelic> My Gutsy still spawns to BusyBox and I have to manually luksOpen my encrypted LVM. Any Suggestions??
<cypherdelic> maks_: kernel		/vmlinuz-2.6.22-14-generic root=/dev/mapper/system-root ro vga=6 rootdelay=9
<cypherdelic> is that korrekt?
<maks_> why don't you try?
<maks_> i have zero idea about the failure you are touching ;)
<cypherdelic> i will but i ask if that is the correct spot where i have to put rootdelay=9???
<maks_> and if i'd say something wrong?
<cypherdelic> i dont know you
<cypherdelic> hold it brb
#ubuntu-kernel 2007-10-16
<verwilst> zul?
<thully> Hi - I lost suspend as of the -13 Ubuntu kernel (bug #151016), and I'm currently looking to get this debugged.  Any pointers?
<ubotu> Launchpad bug 151016 in linux-source-2.6.22 "New in 2.6.22-13: No video after resume from suspend on MacBook" [Undecided,New]  https://launchpad.net/bugs/151016
<thully> One thing - I noticed this:
<thully> clockevents: remove the suspend/resume workaround^Wthinko
<thully> in the changelog, and I'm wondering how I may test "un-removing" this patch.  This patch was applied to the tree at the same time I started having suspend issues...
<thully> (unapplied - as of -13 when the issue started)
<cathya> does ubuntu dapper drake dont have build-essential?
<JanC> cathya: it has, see http://packages.ubuntu.com/build-essential
<JanC> it's not installed by default though
<kraut> moin
<cathya> thanks JanC
<slomo> hi, is it somehow possible to limit the dma mode used by pata_sis to udma66 (or even 33) instead of 100? one of my machines fails to boot because of this after an upgrade to gutsy
<abogani> slomo: hdparm?
<slomo> without getting the machine to boot at all? :) some kernel commandline parameter would be nice
<abogani> slomo: You are right :-)
<slomo> seems that there are many problems with pata_sis... too bad that the sis5513 isn't there anymore
<abogani> slomo: I mean set ide=nodma via kernel cmdline and after set udma33/66 with hdparm :-)
<slomo> abogani: of course that doesn't work either as the pata_sis is not ide stuff
<slomo> any other ideas? :)
<abogani> slomo: no, sorry :-(
<slomo> would be nice if the gutsy kernel package could at least contain the sis5513 module so one could work around this *sigh*
<abogani> slomo: Are you already tried to blacklisted bogus driver and use ide-generic or ata-generic instead?
<slomo> good idea, let me try that
<slomo> abogani: ide-generic gives a kernel panic at boot :)
<abogani> slomo: :)
<slomo> so let's try ata-generic now ;)
<slomo> abogani: hm this loads pata_sis although i blacklisted it
<slomo> ok, installing feisty again now...
<slomo> ok, so what is the easiest way to test a new version of a kernel driver without rebuilding the complete kernel?
<slomo> seems that the pata_sis driver in linus' git tree has quite some changes, one them sounding the one i need
<slomo> whatever, this module probably should be updated before gutsy release... otherwise it's a regression at least on one of my systems since feisty
<mdomsch> rtg: https://bugs.launchpad.net/dell/+bug/125816
<ubotu> Launchpad bug 125816 in linux-source-2.6.22 "linux-image postinst matches header_postinst_hook for postinst_hook incorrectly" [Undecided,Confirmed]  
<mdomsch> still horked
<rtg> mdomsch: I'll bug BenC since he did it (or didn't as the case may be)
<BenC> I was pretty sure I got that fixed
<mdomsch> unless I'm looking in the wrong place in git
<BenC> rtg: I thought you took care of the image postinst scripts in gutsy
<mdomsch> the ubuntu-gutsy kernel package, debian/control-scripts/postinst file
<BenC> All I did was the headers-postinst
<mdomsch> headers-postinst is correct
<mdomsch>      $header_postinst_hook   = "$1"  if /^\s*header_postinst_hook\s*=\s*(\S+)/ig;
<mdomsch> postinst is wrong
<mdomsch>      $postinst_hook   = "$1"  if /postinst_hook\s*=\s*(\S+)/ig;
<mdomsch> notice the missing ^
<BenC> mdomsch: DKMS uses headers-postinst, or both?
* mdomsch looks again
<mdomsch> ahh, I drop config files into the header_postinst.d/ and postinst.d/ dirs, I don't muck with the config files anymore
<mdomsch> (except to remove where I had mucked with them before)
<rtg> mdomsch: how about generating a patch and sending it to kernel-team@lists.ubuntu.com ?
<mdomsch> so dkms won't get bit by this - but anything else would
<mdomsch> http://launchpadlibrarian.net/8537056/kernel-package_10.065ubuntu5-6.diff
<mdomsch> is the basis of the patch
<rtg> mdomsch: I know, but thats only of use for Feisty, correct?
<cypherdelic> Thanks to Developers of Asterisk, Cedega, Compiz-Fusion, FreePBX, Gentoo, Trixbox, Ubuntu, VirtualBox and all the great stuff i've not mentioned. You really make my day. :)
<BenC> rtg: basically just add ^\s after the first '/'
<mdomsch> yeah - looks like it didn't get redone when these moved to gutsy
<mdomsch> ok
<BenC> ^/s* I mean
<cypherdelic> and VDR and WINE ;)
<BenC> cypherdelic: you're welcome
<mdomsch> rtg, patch uploaded to the bug
<cypherdelic> BillyG@BilliesHomeframe$ sudo killall linux && sudo modprobe vista && ./vista-take-over-world
<cypherdelic> segmentation fault
<rtg> mdomsch: thanks
<mdomsch> np
<cypherdelic> DonBush@Whiteframe$ sudo falseflag --target $HOME --match 911 && sudo mount /dev/africom && sudo killall iran && dd if=/dev/america of=/dev/world && sudo killall rebels
<cypherdelic> segmentation fault
<slomo> BenC: ping? could you get the pata_sis module updated for gutsy from linus' git tree? currently udma5 is broken and older chipsets with udma33 are not supported at all... well, and it makes one of my machines fail to boot while it worked fine with feisty and sis5513 (?) :)  edeb614c1c8388b354d93ff7790317cc5d6a38ec and 4761c06cb39011c9cc3fef9e6bbfb4c50ceb307d and 4f2d47cfddc84969b6934893fc40132750ae3b5e seem to be the most useful, others are wort
<slomo> h a look
<ringe> I've got a problem with modules not loading in 2.6.22-14-generic in bug 134193
<ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed]  https://launchpad.net/bugs/134193
<edsiper> hi guys, why I can't read /proc/PID/maps files ?, files has 444
<edsiper> (as normal user)
<ringe> edsiper: sudo
<edsiper> ringe, I know, but I want to know if it's a security issue or just a bug
<edsiper> I never got a permission denied trying to read some maps file
<bullgard4> What stands the acpi wakeup device AZAL for?
<ringe> stgraber: depmod fixed the problem :)
<stgraber> ringe: cool :)
<ringe> thanks a bunch (2.5 tons to be exact)
<verwilst> ringe: np mate
<stgraber> ringe: np, now the question is why wasn't the "depmod -a" done at package install time as it should but as we don't have similar issues with Gutsy testing I'd assume that it was a weird update bug
<ringe> stgraber: Maybe it has to do with updating while mirrors are syncing - which causes "missing" packages?
<stgraber> yes, ideally the metas and all -<kernel version number> packages should be installed at the same time
* Starting logfile irclogs/ubuntu-kernel.log
* Starting logfile irclogs/ubuntu-kernel.log
<verwilst> zul: ping again :d
<verwilst> zul: the patch in pm might be our solution, no?
<verwilst> zul: let me know what you think about the patch please!
#ubuntu-kernel 2007-10-17
<dholbach> BenC: reassigned
<dholbach> milestoning it for gutsy-updates
<dholbach> thanks BenC
<BenC> dholbach: thank you
<h3b> hey @all
<verwilst> zul: ping
<verwilst> zul: back
<cr3> what are the major differences between the -server and -generic kernels?
<cr3> I'm trying to look for the config files on kernel.ubuntu.com but can't seem to navigate the tree properly to find the files for kernel and generic build
<elmo> cr3: install the packages, they're in /boot ?
<cr3> elmo: I'm lazy, I was hoping the git tree would allow me to simply get the files I need
<amitk> cr3: debian/config/i386
<amitk> cr3: config.server and config.generic are the diffs, config is the common file added to both
<cr3> amitk: I'm not seeing config.server nor config.generic?
<amitk> cr3: In <kernel-src>/debian/config/i386?
<cr3> amitk: my bad, I seemed to be looking under the wrong tree. where I was looking, i386 was a file rather than a tree. I'm all good now
<cr3> amitk: that's weird, diff config.server config.generic returns nothing!
<SirBob1701> hey do you guys have anything to do with tty/grub?
<SirBob1701> or should i check the main channel
#ubuntu-kernel 2007-10-18
<amitk> cr3: I see many changes, for the server config, the IO scheduler is deadline, highmem is enabled, etc.
<cr3> amitk: I see many changes by having downloaded the package as suggested by elmo, but the git tree looked the same. maybe I'm not looking at the right root: ubuntu/ubuntu-gutsy.git
<amitk> cr3: that sounds right.
<cr3> I'm grepping for CONFIG_HZ under /usr/src/linux/Documentation for more details about this kernel configuration parameter, but nothing is coming up. Is there another location to look for documentation about specific configuration parameters?
<verwilst> is -xen based on -server?
<verwilst> as in, server oriented?
<johanbr> cr3: sched-nice-design.txt in the Documentation directory.
<cr3> has the CONFIG_X86_BIGSMP configuration option been deprecated?
<cr3> nevermind, I was looking at the wrong configuration. so, why isn't CONFIG_X86_BIGSMP enabled in the server kernel?
<SirBob1701> you guys doing anything about the tty's being dropped after the upgrade?
<kraut> moin
<AnAnt> Hello ?
<xipietotec> are there known issues with the low-latency kernel and suspend?
<xipietotec> I'm having issues with suspend only being able to sleep 1 of my cpu...it does this somewhat randomnly for lengths and lengths at a time, without me changing any of my settings. I thought this might be an nvidia thing, so I loaded vesa...same issue. The only thing I can think of is it might be an issue with the low-latency kernel
<verwilst> hi zul
<verwilst> hi * ;)
<ln-> would it be possible to get this bug fixed in dapper's kernel: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/65631
<ubotu> Launchpad bug 65631 in linux-source-2.6.15 "skge driver broken: invalid call to spin_unlock causes system crash" [Undecided,Confirmed] 
<ln-> i do know how to use the attached patch and fix the problem for myself, but each time the kernel gets updated the patched driver is replaced and we need to manually copy the patched driver back to all four affected systems at the office.
<ln-> i can only imagine how many people world-wide are experiencing random mysterious system lockups because of this bug.
<verwilst> ln-: i have nothing to do with ubuntu-kernel-development, but it strikes me as silly that it's not patched by default by now idd
<Whoopie> To all of you: WELL DONE!
<verwilst> zul: ping
<zul> verwilst: yeah?
<verwilst> zul: the patch i gave you, did it help?
<zul> verwilst: no doesnt apply
<verwilst> or did it look like it would help
<verwilst> oh?
<zul> its for 2.6.18
<verwilst> hm
<verwilst> how's your clock fix?
<verwilst> had any crashes yet since?
<zul> i used clock=pit nope
<verwilst> hm
<verwilst> and performance-wise?
<verwilst> any downsides?
<verwilst> zul: and -xen, is it like -server? server-oriented?
<zul> no desktop it uses -generic kernel
<verwilst> i mean tuned for throughput
<verwilst> hm
#ubuntu-kernel 2007-10-19
<TheMuso> c
<TheMuso> argh
<Kano> https://bugs.launchpad.net/ubuntu/+bug/150531
<ubotu> Launchpad bug 150531 in ubuntu "dmraid45 not in kernel" [Undecided,New] 
<Kano> did you see that
<Kano> http://people.redhat.com/heinzm/sw/dm/dm-raid45/dm-raid45-2.6.22.1-20070724.patch.bz2
<Kano> a kernel patch is required for this
<Kano> otherwise raid 5 on motherboards would never work
<Geoffrey2> hey folks, Tribe 5 would not load at all on my system due to what appears to be a kernel problem with the ATI SB600 chipset.....is there any chance that might have been resolved before the official release?
<meta-paonia> pastebin for the kernel guys http://paste.ubuntu-nl.org/41158/
<meta-paonia> Same subject as Geoffery2 almost
<JanC> eh, tribe 5?
<Geoffrey2> I get the starting menu, pick the run/install option, the kernel progress bar appears, then I get a memory allocation error and the whole system hangs
 * JanC checks the dial on his time machine
<meta-paonia> oh hey - win has SP's we can have an ubuntu 7.10.1.1.1.1.1 if we need to
<Geoffrey2> Cannot allocate resource region 1 of device 0000:00:14.0
<meta-paonia> aaaah XSource - breaking things again I see, no?
<XSource> ?
<meta-paonia> XSource you should look at pastebin http://paste.ubuntu-nl.org/41158/
<Geoffrey2> well, the way Mozilla keeps adding numbers with each release, I would expect to see a version 3.0.0.0.1 sometime soon
<XSource> meta-paonia: are you sure that's for me?
<JanC> meta-paonia, if you want to be helped, you probably should try another way...
<meta-paonia> JanC - perhaps I need some instruction on this
<Geoffrey2> the tricky part for me is that to debug the problem, I've been told I'd need to run some routines under Gutsy and paste the results...since Gutsy won't even load for me, that's just not possible
<JanC> Geoffrey2, Ubuntu 7.10 was released yesterday, did you try the final version?
<Geoffrey2> JanC, no, I haven't downloaded that one yet...guess there's nothing to lose by trying
<JanC> well, I'm sure the developers won't even try to fix things if you didn't try the last version  :)
<howfixbadubuntu> howfixbadubuntu?
<kraut> moin
<Geoffrey2> ok, I downloaded, burned and booted with the official Gutsy release...still will not load,....[26.197607] PCI: Cannot allocate region 1 of Device 0000:00:14.0
<Geoffrey2> the system hangs at that point, upon rebooting I get an error from the BIOS
<Kano> hmm that dmraid kernel patch did not work, maybe just patch dmraid itself
<Kano> have to check
<TheMuso> c
<TheMuso> ugh
<Geoffrey2> anyone here who can help me figure out what appears to be a kernel bug?
<Geoffrey2> Gutsy is giving me an allocation error when I try to run it, it can't allocate region 1 of device 00:14.0, which appears to be the ATI SB600
<ln-> is anyone here involved with ubuntu kernel development?
<JanC> Lure_, can you please fix your connection?  :)
<Geoffrey2> hello all.  Gutsy will not load properly for me, I'm receiving an allocation error...cannot allocate region 1 of device 00:14.0, at which point Gutsy hangs
<JanC> Geoffrey2, did you file a bug report?
<Geoffrey2> ok, now....a bug report was already on file for this problem, but it was filed for Tribe 5....however, the response to the bug filing was they needed more information, and to run certain routines and post the results...problem being of course that since the problem prevents Gutsy from loading at all, there's no way to run the routines
<JanC> Geoffrey2, you could at least add that it still doesn't work, and ask for clarifications  :)
<Geoffrey2> JanC: the problem was listed under Tribe 5, since it's also occuring in the official release, would I want to start a new topic, or just include a comment under the Tribe 5 filing that the problem is still occuring in the release version?
<JanC> I think you should add it to the same bug and maybe update the bug details
<Geoffrey2> ok, hopefully it can get resolved somehow, because I love Ubuntu, and really would like to move up to Gutsy
<jknight> The upgrade to Gutsy broke suspend for me, so I'm rebuilding my kernel (https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/121653)
<ubotu> Launchpad bug 121653 in linux-restricted-modules-2.6.22 "[gutsy] fglrx breaks over suspend/resume" [Wishlist,Confirmed] 
<jknight> i haven't built a kernel in a while (couple years)
<jknight> i see that there are instructions for building kernels "the ubuntu" way.  Is there any difference between the ubuntu kernel sources and just getting and building source from kernel.org ?
<jknight> (sorry got dropped)
<johanbr> The Ubuntu kernels have lots of patches that aren't in the kernel.org kernels.
<jknight> anything breaking ?
<jknight> broad question, sorry
<jknight> i mean: there's no reason a kernel.org built kernel shouldn't run fine with ubuntu, right ?
<zul> it should be fine
<jknight> ok, thank you
<johanbr> zul: No problems with apparmor?
<zul> dont think so
<jknight> great.  I just had to change CONFIG_SLUB to CONFIG_SLAB because CONFIG_SLUB seems to break suspend when using ati drivers.
<jknight> little bump in the gutsy upgrade.   
<jknight> rebooting now, guess i'll find out
<Kano> so, tested the patch to use dm-raid with raid 5 on 2 systems
<Kano> it works, but requires a patched dmraid too
<Kano> it has to load the module
<Kano> http://kanotix.com/files/thorhammer/updates/dmraid/
<Kano> use that as base
<Kano> +
<Kano> http://people.redhat.com/heinzm/sw/dm/dm-raid45/dm-raid45-2.6.22.1-20070724.patch.bz2
<Kano> then it does work
<Kano> combined output of 2 systems:
<Kano> http://paste.debian.net/40179
<Kano> dmraid binary is for etch, do not use it, compile it...
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97655
<ubotu> Launchpad bug 97655 in linux-source-2.6.20 "dmraid45 target please" [Wishlist,Confirmed] 
<Kano> btw. no patch is in conflict
#ubuntu-kernel 2007-10-20
<Gunner_Sr> Is gutsy (2.6.22) supporting custom DSDT?
<IntuitiveNipple> Yes
<Gunner_Sr> IntuitiveNipple: thanks.
<Gunner_Sr> what is policy for custom DSDTs into the kernel release?
<IntuitiveNipple> Gunner_Sr: /etc/initramfs-tools/DSDT.aml and then rebuild the initrd
<IntuitiveNipple> Gunner_Sr: [   15.718612] ACPI: Looking for DSDT in initramfs... successfully read 23334 bytes from /DSDT.aml.
<Gunner_Sr> IntuitiveNipple: thanks again, go that. I notice that there seems to be alot of questions on the forums about ACPI support. where is the best place to find out what work was done in Gutsy, especially catering for laptops?
<IntuitiveNipple> here :)
<Gunner_Sr> IntuitiveNipple: lol
<IntuitiveNipple> actually, for what has been done, the mailing list archives for kernel-team
<Gunner_Sr> okay. will creating the custom DSDT give me better control over the fan management?
<IntuitiveNipple> It could, if you have a had BIOS DSDT and know how to edit the DSDT to correct the issue
<IntuitiveNipple> s/had/bad/
<Gunner_Sr> okay, need to do some more investigation on it then looks like.
<Gunner_Sr> what entries should I see in the /proc/acpi/fan?
<IntuitiveNipple> I fixed this one up for some reason, but can't remember why now :)
<Gunner_Sr> I notice that here is toshiba_acpi and thinkpad_acpi, but no dell is there a reason?
<IntuitiveNipple> fan depends on the system, my Vaio doesn't report it but it has one, but it would be like /proc/acpi/fan/FAN/state
<Gunner_Sr> humm, that's what I would expect to see. I have two fans and don't see anything, interesting.
<IntuitiveNipple> Does the dmesg output give any clues?
<Gunner_Sr> when I use i8k it knows there are two fans as well, one is controllable, the other is showing a weird state of -22
<Gunner_Sr> no, dmesg does not give me anything.
<Gunner_Sr> I email dz@debian.org to see if he came across anything in earlier kernel releases and maybe it would shed some light on it.
<IntuitiveNipple> I'd guess things like that, on Dell, will be solved for 8.04 since it is an LTS release
<Gunner_Sr> in connection to i8k.
<Gunner_Sr> yep, I guess so.
<Gunner_Sr> thanks again
<kraut> moin
<damianc> kernel panic~!
<bmk789> is this not the right place to get help with my kernel?
<dvheumen> Hi guys, I know this is not the ideal place to ask this question, but I think one of you might be able to help me... I've compiled a custom kernel with the CFS patch and I read somewhere that there should be a few sched_... options in /proc/sys/kernel. I can only find 1 ... /proc/sys/kernel/sched_compat_yield
<dvheumen> Is there any other way I can check if CFS is truly working?
<dvheumen> ow sorry, I'm just now reading the title
<cathyal> this is pretty funny but i must ask who is a cron geek
#ubuntu-kernel 2007-10-21
<Geoffrey2> when booting from the Gutsy live CD, I'm getting around a lockup by adding hpet=disable to the boot command
<Geoffrey2> I'm not sure what that command does, but it seems to work....how would I include that when booting from the hard drive?
<lolalolbola> hi 
<lolalolbola> is anyone active here 
<lolalolbola> i do not see any messages 
<lolalolbola> people ... wake up ... 
<kraut> moin
<cornucopia> I just compiled kernel 2.6.23 , since in gutsy repo apparmor-modules-source is no more, is there a quick and dirty way of getting apparmor running?
<verwilst> what version of apparmor is in the gutsy kernel?
<verwilst> i've compiled my own kernel with apparmor 2.0.2
<verwilst> and get these messages:
<verwilst> Loading AppArmor profiles /sbin/apparmor_parser: Unable to add "/bin/ping".  Profile doesn't conform to protocol
<verwilst>  Profile /etc/apparmor.d/bin.ping failed to load
<verwilst> hm, 2.1 ...
<verwilst> grm, that's pre...
<verwilst> why package a -pre version of apparmor for production...
#ubuntu-kernel 2008-10-13
<EmigrantMTChris> I'm doing a kernel bisect to help narrow down where a bug in the kernel was introduced, and have a few questions. Would this be the proper place to ask?
<johanbr> EmigrantMTChris: Yes, but now is probably not the best time of day for getting an answer.
<EmigrantMTChris> Thanks, I'll ask again tomorrow.
<elmargol> Ever tried to run intrepid on a hardy kernel? :/ I don't know anything else to do :(
<elmargol> I'm frustrated :(
* abogani changed the topic of #ubuntu-kernel to: "Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Moved to 2.6.27 kernel for Intrepid/8.10. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.27-7.10 based on 2.6.27 final"
<Ng> elmargol: I was running intrepid on a hardy kernel for a while, seemed to mostly work
<elmargol> on the nvidia forums they suggest idle=poll as a boot parameter? what exactly does this?
<elmargol> on a quick google search i could not find any informations
<elmargol> kde4 and the vanilla 177.80 is totally broken :(
<mdz> mjg59: there's a quote from you in bug 256887 which says we ought to be able to use the default hotkey mask in thinkpad_acpi, but testing (bug 222796) indicates that using the default breaks the volume and brightness keys for several models
<mdz> mjg59: I'm considering whether we need to go back to 0xffffff for now
<mjg59> mdz: Breaks in terms of what behaviour? It's certainly possible.
<mdz> mjg59: breaks in that no ACPI events are generated for those keys
<mdz> mjg59: they still work (in hardware), but we don't get any notification of the change to userspace
<mdz> changing the mask back to the old default of 0xffffff gets them working fine
<mjg59> Ah, right. Upstream doesn't like the keys that have direct effects in hardware sending events
<mjg59> So yeah, you might need a broader mask for that case
<mdz> mjg59: given how close we are to release, I'm inclined to just revert it to the old default rather than fish around trying to figure out which bits we need.  do you see any practical problem with that?
<mjg59> Not really, no
<ivoks> are you guys talking about acpi keys?
<ivoks> hot keys
<mdz> ivoks: yes
<ivoks> mdz: fwiw, toshiba laptops are really broken atm :/
<mdz> ivoks: that isn't worth much on its own; can you point to a bug report?
<ivoks> give me a second...
<ivoks> bug 261318
<mdz> ivoks: thanks
<ivoks> i've tried creating a fdi file for hal, but that failed since i don't know hal that much :/
<mdz> the thinkpad_acpi commit which adds the warning says:
<mdz> 3. Attempts to set hotkey mask to 0xffffff, which is almost never the
<mdz>    correct way to set up volume and brightness event reporting (and with
<mdz>    the current state-of-the-art, it is known to never be right way to do
<mdz>    it).
<mdz> unhelpfully, it doesn't explain what *is* the correct way to set up volume and brightness event reporting
<mdz> I don't know of another way to get at this data
<crevette> hello
<crevette> I've a problem with my webcam, since few weeks ago
<crevette> problem with webcam should be reported against kernel ?
<mdz> mjg59: the old code checked which X driver was in use (intel|ati|radeon) and only changed the mask for those three.  do you know why?  the changelog doesn't say, and I don't see why nvidia-based thinkpads wouldn't need this
<crevette> hey mjg59
<mjg59> At that point only those drivers supported xrandr1.2
<mdz> mjg59: ok, so it's obsolete and I'll drop it. thanks.
<crevette> it seems the pwc driver reports it can works in v4l2 but is this mode the output is just a plain green color
<crevette> it used to works fine 2 weeks ago
<mdz> afaik, thinkpads only ship with intel, ati and nvidia, and all three of those support xrandr 1.2
<crevette> but I don't know it used v4l or v4l2
<mjg59> crevette: Reporting v4l2 is probably correct. Something's just broken in the driver.
<mjg59> mdz: Only newer nvidia, and only if you're using nv
<mdz> mjg59: we don't write that into xorg.conf anymore, so only the X server knows which driver it will use
<mjg59> Yup
<mdz> mjg59: all thinkpad-keys seems to do is generate an input event.  what harm would that do if the driver doesn't support xrandr 1.2?
<mjg59> It's not thinkpad-keys
<mjg59> It's whether the hotkey generates the BIOS event or an input event
<mdz> mjg59: so if the key is included in the mask, it generates an acpi event.  if it isn't, what happens in that case?  the documentation says "the firmware will handle it", but in this case, we're only asking for notification
<mdz> will masking out the brightness keys on some models prevent the hardware from adjusting the brightness?
<mdz> (it doesn't on any hardware reported in the bug)
<mjg59> mdz: For video switch, you're not just asking for notification
<mdz> mjg59: ok, I understand.  I'm happy to let the driver decide what to do for the video switch key.  the problem I'm trying to address is the regression in getting events for volume and brightness.
<mjg59> Yeah. In that case, setting the wider mask should be fine
<mdz> mjg59: the old code was: "if intel|ati|radeon driver, set mask to 0xffffff".  the new code would be: "set mask to (recommended_mask) | (bitmask for volume and brightness keys).  sound ok?
<mjg59> Yeah
<mdz> thank you
<crevette> mjg59: I can't find a package v4l2 is it libv4l-0?
<mjg59> crevette: v4l2 is a kernel API
<mjg59> It specifies how userspace communicates with the camera
<crevette> a, /me is a total newbie in video thingy
<crevette> mjg59: okay so I open the bug against the kernel
<Kano> hi
<Kano> interested in a simple patch for one c6600 (compal jhl90) webcam?
<Kano> just id addon to uvcvideo
<Kano> hi rtg 
<rtg> Kano: hi
<Kano> rtg: i have got a patch for uvcvideo and compal jhl90 barebone based systems
<Kano> just made it, as simple as for the akoya
<rtg> Kano: send it to kernel-team <kernel-team@lists.ubuntu.com>
<Kano> no time,but i uploaded it
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.27-uvcvideo-jhl90.patch
<Kano> straight forward
<Kano> just compied last section and added id, thats all
<Kano> bbl
<mdz> mjg59: if you have a moment to eyeball http://launchpadlibrarian.net/18497499/hotkey-setup-222796.diff that would be appreciated
<mjg59> mdz: Looks good
<mdz> mjg59: thank you
<mdz> it gets things working again on my T42, doesn't break anything on the T61
<mdz> and I've asked a bunch of folks to test
<Ng> did something relating to USB autosuspending change in the last couple of intrepid kernels?
<rtg> Ng: something broke?
<Ng> rtg: sort of the opposite - I was playing around with setting the /sys/devices/pciblah/usbfoo/power/level to "auto" a week or so ago to stop my laptop's fingerprint scanner and webcam consuming power, and now they seem to come up set to "auto" all the time
<Ng> I'm pretty sure that stuff shouldn't be persistent ;)
<Ng> (also I'm fairly sure the fingerprint scanner is actually active, because it's warm and after my playing around it would come up cold)
<rtg> Ng: CONFIG_USB_PERSIST is no longer an option in Intrepid. hmm.
<Ng> yeah I couldn't see anything having changed in the /boot/config- files, nor anything relevant in the changelog
<tseliot> rtg: did my patch solve your problem with nvidia?
<rtg> Ng:  we need an rf-kill switch for webcam and finger print sensor.
<rtg> tseliot: I still had library conflicts, so I ended up installing Intrepid from scratch. I'm pretty well setup for it anyways since I always have /home on a  separate partition.
<rtg> Thanks for the response, though.
<tseliot> no problem
<Ng> rtg: that would certainly be nice. This is hardly an important problem, I'm just a bit confused why it seems to have changed
<rtg> tseliot: the twinview setup works well.
<tseliot> good :-)
<rtg> tseliot: will you have time to explore the issues regarding nvidia-glx-177 under Hardy?
<tseliot> rtg: yes, sure
<Ng> oh, I seem to be looking in the wrong place is all, I'm looking in /sys/devices/pci0000:00/*/*/power/level and that's just finding the USB hub devices
<Ng> in other news, I'm seeing http://picasaweb.google.co.uk/cmsjtenshu/Misc#5256616902573945746 occasionally on boot. Seems to be too early for X to be the culprit, and it causes a total kernel wedge (I had it once when not using usplash and the console was similarly corrupted, no sign of an OOPS)
<Ng> tjaalton has seen it too I believe
<rtg> Ng: BenC is supposed to be working on the uvesafb stuff
<rtg> Ng: frannkly, I'd like to see a short enough boot time that we can do away with usplash.
<Ng> rtg: definitely, but this seems to happen with or without that, and it's part way through the boot sequence and not obviously reprodicble, afaics
<Ng> (and fwiw, I don't have v86d installed)
<tjaalton> we should replace usplash with plymouth for jaunty
<rtg> Ng: that was a usplash screen in the URL you referenced, isn't it?
<AnAnt> Hello, is there any info that I should add to bug 281451 ?
<persia> Good day.  Anyone bored and feel like reviewing the current state of the -rt patches for intrepid?
<Ng> rtg: yeah, but I've had what seems to be the same crash on one boot where I'd disabled usplash.
<rtg> Ng: if you could catch one with quiet disabled , that might be helpful. My wedges have only appeared with usplash
<Ng> tjaalton: or we should boot quickly enough not to need either :D
<tjaalton> Ng: heh, let's be realistic here ;)
<Ng> rtg: I'm moderately sure the one I saw was with quiet disabled (I generally either boot usplash or remove "quiet splash") and there was no oops, but the screen was pretty garbled
<Ng> I'll at least pay more attention to where it happens
<Ng> tjaalton: ;)
<rtg> persia: where are you hiding them?
<persia> rtg, They're applied by quilt at build-time from http://ppa.launchpad.net/abogani/ubuntu/pool/main/l/linux-rt/linux-rt_2.6.27-2.4.dsc
<persia> abogani, Has been working on them : I'm only interested because of the impending kernel freeze, and wanting to make sure that it doesn't get missed.
<rtg> persia: his package isn't really affected by the freeze, is it? In fact, the freeze is a good thing from his perspective.
<persia> Actually, yes, it's affected by the freeze.  It's a kernel freeze.  That's all the kernels.
<rtg> persia: I thought it was a universe package ?
<persia> rtg, It is, but also a kernel.
<persia> (so it has to follow both sets of rules)
<rtg> persia: his quilt set doesn't apply.
<persia> RIght.  It did on the 10th.  I suspect it needs a refresh.  I'll go poke him.  Thanks.
<rtg> persia: it fails in some recent ACPI changes.
 * persia will test to make sure it works before asking for review next time
<mdz> Ng: are you using VESA (vga=) or the default svgalib stuff?
<rtg> persia: its a hard one to review anyway since there is a zillion patches. mostly one can only test if it builds and runs.
<Ng> mdz: I've not consciously made any changes to the console screenmode, so there's no vga= on my kernel commandline
<persia> rtg, The Studio folk did a bit of build&run testing, and it was looking pretty good (although clearly it now fails to build).
<mdz> Ng: I agree with rtg, try it without quiet and see if it always hangs at the same spot in the boot process
<persia> Do you guys want to look at anything more closely before it gets uploaded?  I just expect that there will be a number of bugs against "linux" that are -rt specific, and would prefer it didn't have anything too insane in it.
<mdz> Ng: if you can, track it down from there.  if not, then try removing splash and see if it's still reproducible (and if you can get a panic)
<rtg> persia: once its working, I'll build it and run it on a laptop, smoke test it at least.
<Ng> mdz: will do. As I said, I'm pretty sure I've had it once without "quiet splash" and there was no kernel output, but I'll try and provoke it later
<Ng> it seems kinda random :/
<mdz> Ng: if you and tjaalton are experiencing the same problem, that's certainly enough to open a bug
<persia> rtg, OK.  I'll come back when I've confirmed it's working again.
<mdz> Ng: (use "ubuntu-bug linux" to get your hardware info automatically attached)
<Ng> mdz: will do
<rtg> Ng: is it always the same peripheral set? network cable connected? that kind of stuff.
<Ng> rtg: hmm, I've had it both with and without network cable, but it occurs to me that I may only have seen it while on battery
<rtg> Ng: good. its likely not random at the point that its wedging.
<Ng> might be bug 263782 but the comments there seem to cover more than one actual bug
<AnAnt> Hello, is there any info that I should add to bug 281451 ?
<AnAnt> Launchpad bug 281451 in linux "uvesafb does not support 1280x800 resolution for NVIDIA graphics adapters" [Undecided,New] https://launchpad.net/bugs/281451
<Ng> rtg: ironically X just crashed, so I rebooted and disabled "quiet splash" and the crash happened and garbled the console. before I could get a camera on it my laptop switched off and then back on again (some kind of watchdog?)
<Ng> it seemed like it was just printing something about VESA, but I don't see that in any normal boot logs
<rtg> Ng: how bizarre. Maybe the BIOS sets a ACPI timer in case the boot process fails.
<Ng> I did wonder if it was linux's reboot-on-panic stuff, but a) I think that defaults to 30seconds, b) I don't think it would look like a power cycle
<rtg> Ng: thats why I think its a  BIOS thing. perhaps it triple faulted.
<Ng> I'll do some reboot loops tonight until I trigger it again and try and figure out from approximate timing, where it's at
<rtg> cking: whats your experience when testing the triple fault method of rebooting? Does it appear like a power cycle?
<cking> cking: it's a good way of resetting the processor - I suppose it's the nearest we have to power cycling the processor
<cking> ^rtg^
<cking> oops
<rtg> cking: I understand that, but I was asking if it looks like a  power cycle or just a warm boot.
<cking> rtg: I am not 100% sure - http://en.wikipedia.org/wiki/Triple_fault describes it as best as I could find. I would make sure that the magic number that needs to be set in memory before issuing it to indicate the kind of warm/cold reboot method used by the BIOS on reboot
<cking> rtg: write a zero to location 0x472 for a cold reboot
<cking> then issue a triple fault
<Ng> well, I filed bug 282700 rather than assume it's 263782
<rtg> cking: dude, you're going way to deep. I just wanted to know if it _looks_ like a power cycle. you know, all the blinky lights go off, then back on.
<cking> rtg: not sure - I didn't look at the blinky lights - superficially it looks like a power cycle  - like a normal BIOS or keyboard reboot to me 
<cking> As vulcan death grips go it seems as good as the other methods I tested
<rtg> :)
<Ng> (fwiw I described it as looking like a powercycle because literally every LED on the laptop, including the one in its power button) went off and then all flashed on, as if it had been power cycled)
<Ng> but that's the less important aspect of this, why it's crashing in the first place is more important ;)
<rtg> Ng: actually, how its crashing is of interest, but its often not clear why until you know the cause.
<rtg> catch-22
<Ng> fair enough :)
<cking> rtg: A reset could occur by writing 0x6 to port 0xcf9 (an Intel PCI chip reset)  - causing this style of reset too.
<abogani> persia, rtg : I just uploaded a synced version of the rt patchset on my PPA.
<BenC> rtg, cking, amitk: on holiday today (rtg, shouldn't you be too?), but have lrm in the works to be uploaded before COB
<rtg> BenC: I should be on holiday, but there are lots of things to do.
<rtg> BenC: lrm to fix firmware files issues?
<BenC> rtg: firmware udeb, copyright file
<BenC> most likely uvesafb will be reverted to vesafb...there's no way for me to reproduce the corruption
<rtg> BenC: uvesafb seems to be causing widespread problems.
#ubuntu-kernel 2008-10-14
<bizhan> Hi All, question on msleep within kernel driver, I have a multi-thread process which one of the threads call an ioctl to a driver, inside this driver I have placed msleep() to defer time for the calling thread but it seems it puts the entire process into sleep, does anyone have any idea? 
<mjg59> bizhan: What are you trying to do?
<mjg59> msleep() will block the process, yes
<mjg59> If you want to let the process continue then you need to use a workqueue or something
<mjg59> Schedule some work on it and then return
<Kano> hi rtg , did you look at the uvcvideo patch?
<rtg> Kano: you mean the patch that you had no time to send to the kernel team mailing list? nope, I had no time to download it or look at it.
<Kano> well had to go yesterday
<Kano> it is only very small, just take a look
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.27-uvcvideo-jhl90.patch
<Kano> but really usefull
<Kano> i guess there are lots of different laptops out there based on that compal base
<wgrant> rtg: Hi. I was pointed to you for debugging why my Dell laptop's brightness keys appear to never send release events in Intrepid. superm1 and others also suffer from this issue.
<Vuokko> hello
<rtg> wgrant: is there an LP report associated with this issue?
<wgrant> rtg: Bug #261721
<rtg> wgrant: so you think if it was behaving properly, the little brightness gizmo would disappear immediately after you release the brightness control key?
<wgrant> rtg: No, it would stick around for a while. But I can see lots of events in xev, and turning of X key repetition fixes it.
<wgrant> s/turning of/turning off/
<rtg> wgrant: how do you turn off key repetition?
<wgrant> rtg: System->Preferences->Keyboard
<rtg> wgrant: aren't the brightness keys ACPI events?
<wgrant> rtg: Not here, AFAICT.
<wgrant> I can set them for keyboard shortcut actions, for example.
<rtg> wgrant: huh, I'm not seeing the issue on my Dell laptop. What happens if you make the repeat interval longer?
<wgrant> rtg: I believe that setting's broken at the moment...
<wgrant> rtg: How old? Mine's an Inspiron 630m from early 2006.
<rtg> wgrant: XPS M1710, maybe 18 months old?
<wgrant> Hmm.
<wgrant> rtg: Does xev say anything about the keys?
<rtg> wgrant: I'm only getting one event per touch.
<Vuokko> I have Fujitsu loox netbook and I was wondering if Ubuntu could put patch from http://panic.cs-bristol.org.uk/~jules/fujitsu-u810-debian-install-notes.html to enable keyboard lights. Am I asking something impossible?
<rtg> Vuokko: email your path with an explanation of what it does to kernel-team@lists.ubuntu.com
<rtg> wgrant: ok, I sometimes see 4 events with a single button press.
<wgrant> rtg: When I have no g-p-m running to catch the events, and have repeating off, I just see http://paste.ubuntu.com/57424/. No corresponding release.
<wgrant> Hmmm
<wgrant> I note that the keys will only work once, unless I VT switch.
<rtg> wgrant: well, see if you can find other folks with the same problem 'cause it isn't going to be something I'll get to for the next few weeks.
<rtg> release is approaching, and there are some pressing issues.
<rtg> need coffee...
<wgrant> And huh... subsequent keypresses appear once the VT is switched back.
<wgrant> But only one for each key ever appears.
<ctshh> hi everyone... is there a known way of making a kernel only boot on a processor with a specific processor number, ie. let it _not_ boot on just any given processor?hi everyone... is there a known way of making a kernel only boot on a processor with a specific processor number, ie. let it _not_ boot on just any given processor?
<ctshh> oops. wtf??? sorry.
<ctshh> once would have been enough i guess :)
<rtg> ctshh: its likely it has to boot one the same CPU every time, but you can look for phrases like 'affinity'
<rtg> s/boot one/boot on/
<ctshh> ok, my bad: i mean on a specific cpu as in "my cpu, but not yours" - as mine has another procesor number (ie processor ID!) as yours.
<rtg> ctshh: haven't the foggiest
<ctshh> me neither :)
<ctshh> this question doesnt seem to come up too often...
<rtg> BenC: are you still thinking about reverting from uvesafb ?
<pgraner> rtg: any word on the screen corruption issues, mario pinged me.
<rtg> pgraner: hence, my question to BenC
<pgraner> rtg: I had it happen to me on an Intel graphics chip last night, then it went away and hasn't happened yet
<BenC> pitti said his got fixed recently, although I have no idea how
<BenC> rtg, pgraner: but yeah, after I do this linux-firmware split from lrm, I'll do a new kernel upload reverting back to vesafb
<pgraner> BenC: can you run that one down in time for the meeting?
<BenC> pgraner: and re: HPA, it is not new to intrepid
<BenC> pgraner: run it down?
<pgraner> BenC: what pitti did
<BenC> pgraner: he assumed I fixed it, so I am chalking it up to a fluke
<pgraner> BenC: on HPA, the issue is that in Hardy systems with HPA "just worked", now in intrepid they are crapping out on boxes with a HPA disk
<pgraner> BenC: we owe Mario more than "chalking it up"
<rtg> BenC: What's LRM -7.10 ? Isn't that the firmware split?
<BenC> pgraner: Uh, no, I mean I am ignoring the fact that pitti says it is fixed for him because there's no reason it should be
<BenC> pgraner: I am reverting to vesafb, and that's about the best answer we can give
<BenC> rtg: No, that was just udeb's and copyright
<pgraner> BenC: Ok, understand, do we have root cause other than we are just reverting?
<BenC> rtg: cjwatson wants firmware split out, and have an upgrade path for people that didn't have lrm-common
<rtg> BenC: oh, I didn't look into the diff.
<BenC> pgraner: root cause is that uvesafb is a little buggy
<pgraner> BenC: ack
<BenC> pgraner: vesafb will at least put us back to what worked in hardy
<rtg> pgraner: maybe this is the last release for usplash. we can spend all winter working on the 5 second boot.
<pgraner> rtg: thats the plan...
 * BenC would be amazed if we could get gdm up in 5 seconds
<pgraner> BenC: you didn't see the X changes keithp is doing and some of the other bits to get us closer.
<rtg> BenC: well, its simply a matter of taking unrealistic short cuts.
<pgraner> rtg: s/short cuts/tradeoffs/
<BenC> does it involve kernelmodesetting?
<pgraner> BenC: nope, most of it was ripping cpp out of X at start up
<BenC> cpp?
 * BenC hopes that isn't /usr/bin/cpp
<pgraner> BenC: the C preprocessor
<mjg59> xkb file compilation
<BenC> wow, I never knew that sort of crap was taking place at X startup
<mjg59> Turns out that caching the compiled keymap is some kind of performance win
<BenC> who would have thought
<sebner> hi, mighty kernel guys. already plans for jaunty and ext4?
 * BenC needs more coffee
<rtg> sebner: the next kernel upload will have EXT4_DEV enabled.
<Kano> ext4 tools in repo?
<sebner> rtg: what do you mean with "next kernel upload". I'm curious because jaunty will have at least 2.6.28 (I suppose) and in 2.6.28 is ext4 now marked as stable ;)
<rtg> according to keybuk we have the latest from Ted.
<rtg> sebner: Intrepid is 2.6.27, and therefore has the development version of ext4
<sebner> rtg: therefor I was asking about "Jaunty" and ext4 ;)
<Kano> did somebody else found gspca problematic in 2.6.27?
<rtg> sebner: you'll have to wait until after the December UDS for us to make that decision.
<Kano> it seems it can even stop booting - at least the cam is not working...
<sebner> rtg: any vision about the chances?
<BenC> pgraner: seems in intrepid, we moved to making HPA honored by default, which was due to pressure from upstream (alan cox, among others)
<rtg> sebner: about it being the default? the likelyhood is high.
<BenC> pgraner: way back in edgy we ignored the host protected area
<sebner> rtg: cool. thx for the info :)
<BenC> pgraner: which was to keep consistency across the move from ide to pata
<BenC> pgraner: ide has always ignored hpa by default
<pgraner> BenC: so do something need to happen in the installer so that we fence that portion off to avoid crashing?
<rtg> sebner: besides, Jaunty is most likely going to be a 2.6.29 or perhaps even .30 kernel. ext4 will have matured some by then.
<sebner> rtg: .30?? 27 is just out and 1 kernel version every 2,5 months .. hard :)
<pgraner> Kano: the gspca bits userspace patches are being applied and seem to be working for me.
<Kano> pgraner: for skype?
<Kano> and what about boot problems with webcam?
<pgraner> Kano: we are packaging skype for Intrepid and it will have the fixes either patching or the LD_PRELOAD method before GA
<BenC> pgraner: it would seem so
<pgraner> Kano: other than you I've seen no other boot probs with the web cam
<BenC> pgraner: the kernel is DTRT
<Kano> pgraner: it was a laptop, could not boot when it was connected.
<pgraner> BenC: ack, we need to get with the platform guys to get this sorted
<BenC> pgraner: On it...
<Ng> rtg: re the bug with hangs and visual corruption on boot, I think it's happening very shortly after intel_agp loads (dunno if you saw the comment on th ebug, but i added a couple of pictures of it happening without usplash
<Ng> which seems like it could be a prime candidate, I guess
<rtg> Ng: we  were just having a conversation about reverting to vesafb as the preferred frame buffer driver. hopefully the usplash corruption issue will be moot.
<Ng> I don't think I'm using uvesafb though, I have log messages suggesting it fails
<Ng> but I've never understood console video modes very well, I don't use them enough to care ;)
<rtg> Ng: or do I.
<rtg> s/or/nor/
<Ng> [    2.833626] uvesafb: vbe_init() failed with -22
<Ng> [    2.833715] uvesafb: probe of uvesafb.0 failed with error -22
<Ng> that's the last thing uvesafb has to say for itself
<rtg> Ng: what does get loaded? vesafb16 ?
<Ng> hmm, maybe I am using uvesafb then, because that's the only kernel module I have loaded which matches "vesa"
<amitk> Ng: IIRC, that error has got to do with not having 'v86d' installed
<amitk> Ng: try installing v86d to check if your problems go away
<Ng> amitk: will do, although I've tried that at several points in the cycle and had things generally get worse, like X failing to start ;)
 * amitk nods
<BenC> Ng: ignore it for now, we're making vesafb the default again
<Ng> ok
 * Ng purges v86d with fire
<Ng> I'll do some more reboot loop testing when i spy a new kernel with that change :)
<rtg> Ng: x86 or x86_64? I can provide a test kern.
<Ng> x86
<rtg> Ng: 10 minutes (or so)
<Ng> groovy :)
<rtg> Ng: http://people.ubuntu.com/~rtg/vesafb for test kernels
<Ng> rtg: ta
<persia> I thought I was here.  Wonder how it fell off the list.
<BenC> persia: It will have to be done separately
<BenC> we can't have lrm build-dep on something we aren't directly supporting
<BenC> persia: I'm curious if fglrx and nvidia dkms build ok with it
<persia> BenC, Rather, to have l-r-m generate l-r-m source so l-r-m-rt can build-dep on it.  That's what abogani wanted.  If that's infeasible, the source can be copied.
<BenC> persia: just copy the source...there's only 4 modules there (and firmware will get moved to another package and be arch/kernel indep)
<persia> I'll ask to have the dkms stuff tested.  I know at least nvidia isn't rt-safe, and crashes.
<BenC> well, firmware is already arch/kernel indep
<persia> OK, so the linux-firmware (or whatever) package should be safe to just have linux-meta-rt depend upon?
<BenC> persia: right
<persia> OK.  Cool.  Thanks.
<jdong> so what's up with CONFIG_EXT4DEV_FS? would I still be an insane idiot to attempt ext3->ext4dev?
<jdong> (yeah I know, I am one ext4 or not)
<Vuokko> what's the fuzz about ext4? isn't ext3 good enough?
<laga_> no. obviously not
<Vuokko> nothing is ever good enough :(
<laga_> 640k...
<philsf> is there anything (testing) I can do to help fix bug #55567 in time for intrepid? It includes a hardware driver inclusion.
<philsf> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/55567
<Ng> rtg: no good I'm afraid, I got the same corruption/crash on the 16th boot
#ubuntu-kernel 2008-10-15
 * ogra has massive probs trying to build amitk's linux-lpia package, wasnt the bi check dropped in intrepid ? 
<ogra> http://launchpadlibrarian.net/18547672/buildlog_ubuntu-intrepid-lpia.linux-lpia_2.6.27-4.6_FAILEDTOBUILD.txt.gz shows that it fails in abi-check-lpia even though i added appropriate ignore files
 * ogra gives up and hopes someone else will then build a -4 kernel for lpia
<maestrolinux> Hola
<maestrolinux> alguien sabe donde descargar el 2.6.27 x64 deb
<rafal> hi
<rafal> are there some test versions for 2.6.27 yet?  im on 8.04 adm64
<persia> limcore, Test versions for 2.6.27 exist only in 8.10.  8.04 is exceedingly unlikely to receive them.
<limcore> can I somehow test 8,10's kernel and perhaps drivers, while remaining (other software) at 8.04?
<CMD_L1N3> hello
<CMD_L1N3> my question is about kernel devel but about the kernel i think
<CMD_L1N3> i just updated my kernel and now my printer doesn't work
<NCommander> I have some questions on how the ubuntu git tree rebases new releases into the tree
 * NCommander is attemtping to figure out how to rebase the linux-ports tree
<NCommander> The log on some of the tags suggests its merged and not rebased on a new release, but I'm not sure if thats right or not
<mdz> can anyone tell me what this means?
<mdz> ACPI: EC: missing confirmations, switch off interrupt mode.
<mdz> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080609]
<mdz> kernel problem or BIOS problem?
<apw> mdz, they don't exactly have a lot of helpful comments in there do they
<NCommander> Anyone here a kernel git wizard?
 * NCommander is trying to figure out how to rebase the git repo without it exploding in my face
<apw> which repo you looking at
<NCommander> linux-ports
 * NCommander kicks xchat
<NCommander> I'm trying to rebase from 2.5.24 which is the basis of that repo against linus 2.6.27 tree
<NCommander> But I don't think I"m doing it right since I either seem to pull old patches into the tree, or it stops every patch with a conflicts
<apw> thats a big jump
<apw> can you paste the url you cloned the original from
<apw> then i can try it and see what it does to me
<NCommander> Yeah
<NCommander> But the ports tree has relatively few Ubuntu specific patches
<NCommander> apw, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid-ports.git;a=summary
<NCommander> (thats the ubuntu/ubuntu-intrepid-ports.git branch)
<NCommander> Personally, my gut instinct is to merge, but thats a bad idea since the Ubuntu patches will get pushed into the history instead of sitting ontop
<apw> my gut concurs
 * NCommander notes he has a dislike for git
<NCommander> Damn tool nearly as painful to use as CVS when it comes to preventing yourself from shooting yourself in the foot
<NCommander> and it used to be close to arch in terms of user friendlyness :-P
<apw> they do appear to be merging the stable branch in there
<NCommander> The ports repo has seen no love this release
<NCommander> Myself and TheMuso are working to make at least powerpc ports not suck
<apw> my rebase stops on the first patch with what appears to be a trivial merge which i would have expected git to detect and merge
<NCommander> yeah
<NCommander> Same problem
<NCommander> It looks like they did SOMETHING to break the repos history
<NCommander> But of which I'm am unsure
<NCommander> I'm tempted just to take the debian folder, and start with a fresh 2.6.27 tree
<NCommander> hey BenC 
<NCommander> BenC, I was wondering if you can help solve a rebasing mystery with linux-ports (and help create a kernel.u.c account)
<apw> NCommander: went through the whole rebase, can't say i was very careful but the main pain is near t
<apw> the beginning, most of the merges seemed pretty and most of the last bunch of patches rebased ok
<zul> rtg: the patch is attached to the email I sent to the kernel team mailing list
<rtg> zul: i saw that, but I'm lazy and git pulls take 2 commands.
<zul> rtg: im lazy too and I dont have the git tree setup for intrepid
<rtg> zul: so what is this: http://kernel.ubuntu.com/git?p=chucks/ubuntu-intrepid.git;a=commit;h=73d6bbb5e0dcdb902c37ef2bc2925de600dd0172
<zul> old junk git tree
<D2_WON> Hi guys, i have a problem... i have installed Kernel-2.6.24.21-rt on Ubuntu Hardy by linux-rt package. After a while time, the system crashes and generate I/O Error, and i can not run any process. Sorry for my bad English.
<abogani> D2_WON: Can you report exactly the I/O Error?
<abogani> persia, rtg : I just uploaded a synced version of the rt patchset on my PPA (against 2.6.27 7.11) together to lrm-rt package. Moreover I have tested rt kernel with DKMS packages (in my case with nvidia video driver) and it works.
<elmargol> Is there a new feature in intrepid to change the clock speed of my nvidia GPU? or memory?
<rtg> BenC: so what is the new firmware package? my i3945 isn't working too well after an update a few minutes ago.
<BenC> rtg: linux-firmware, but it isn't up yet
<rtg> BenC: its breaking my rice bowl. no firmware, no wireless.
<rtg> BenC: I sure like this USB stick as an install medium. cuts it down to about 8 minutes.
<BenC> I need to set mine back up
<BenC> I wonder when the next publisher run is...linux-firmware is still pending
<BenC> rtg: do you want me to just send you the firmware file?
<rtg> BenC: I've been using Evan's usb-creator package.
<rtg> BenC: I'm just reinstalling. I had a version that worked, so I'll just avoid updating. the i3945 issue is related to kernel and not much else.
<BenC> rtg: zinc:~bcollins/ if you need it
<rtg> BenC: 'tanks
<ScottK> What source package provides linux-firmware?  My test server (running the server kernel) can't seem to find it and so is a bit stuck at the moment.
<rtg> ScottK: wait until the archive catches up. its in a bit of flux right now.
<ScottK> OK.
<chrisf_> has beenc been around?
<chrisf_> benc
<chrisf_> hey ben :)
<ogra> speaking of the devil :)
<chrisf_> i know him
<chrisf_> its been quite awhile since i spoke to him tho
<ogra> so my sentence is even more true :)
<chrisf_> yeah!
<ogra> (he hides his little horns under a basecap since i know him ;) )
<chrisf_> heheheh
<chrisf_> right now i am thinking of fooling around with the kernel as usual :)
<chrisf_> fix this nvidia bug once and for all
<chrisf_> its driving me crazy
<ogra> just get better HW :)
 * ogra is all intel on his laptop
<chrisf_> hehehehe
<chrisf_> i wish :P
<chrisf_> if i had the cash, i would buy all amd
<chrisf_> and use a company that supports linux
<ogra> heh
<chrisf_> timecop on that other network i chat on, will be mad that i ditched windows
<chrisf_> but vista sucks
<chrisf_> this is much nicer
<ogra> yeah
<laga_> timecop? i think that rings  a bell
<chrisf_> yeah ben and i know him
<chrisf_> he is on efnet
<laga_> the GNAA guy?
<chrisf_> i hardly ever go on efnet anymore
<chrisf_> yeah
<laga_> oh god ;)
<chrisf_> i dont op on his channel lwz anymore
<chrisf_> i dont know if its apropriate to use teh full channel name here on freenode
<chrisf_> dont know the aup
<chrisf_> the network i chat on now, does not like people to mention anything about p2p and other grey area things..
<chrisf_> laga_: did you talk on lwz on efnet before?
<laga_> no. 
<chrisf_> i used to op there many moons agao
<chrisf_> before timecop was in GNAA
<chrisf_> laga: i quit going there because my interests are not in computers as much anymore
<mdz> rtg: I tried unloading and reloading iwl3945 and its dependencies a few hundred times on davidm's machine, and can't get it to crash
<rtg> mdz: BenC and I are speculating its an interrupt problem. He pointed out a bug report that says something else: http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1778#c15
<BenC> mdz: It seems to be a race with other modules loading in parallel
<BenC> guessing on the same IRQ (not much reason for a race otherwise)
<rtg> mdz: can you 'cat /proc/interrupts' on Davids machine?
<BenC> chrisf_: if you want to go all opensource, buy intel :)
<chrisf_> yeah :)
<chrisf_> ben: i guess iam behind the times LOL
<chrisf_> BenC: Long time no see! :)
<mdz> rtg: http://paste.ubuntu.com/58006/
<mdz> 217:      99246          0   PCI-MSI-edge      iwl3945
<rtg> mdz: ah, try booting with nomsi (after removing the /etc/modprobe.d load delay)
<BenC> hmm...MSI
<rtg> mdz: rather, thats 'pci=nomsi'
<BenC> we had to disable MSI by default on a previous release, but I think it was affecting e1000
<BenC> chrisf_: yeah, been awhile
<rtg> yeah, but the 3945 is about the same vintage
<chrisf_> ben: congratulations in being a part of the ubuntu team :)
<BenC> rtg: oooh...someone on the original bug report did mention that disabling iwl3945(rfkill) and using e1000 resulted in a hang as well
<BenC> chrisf_: Thanks, been here more than 3 years now :)
<chrisf_> ben: now i have two things i want to play with ubuntu muhahha installing WoW and getting nvidia's piece of trash top run on this
<chrisf_> i am already having WoW withdrawals
<mdz> davidm: ^^
<BenC> chrisf_: install Ubuntu, and you should get nvidia enabled without much problem
<chrisf_> yeah i have ibex on here now
<chrisf_> and nvidia is being a little *** to me
<rtg> chrisf_: nvidia-glx-177 ?
<BenC> chrisf_: System => Administration => Hardware Drivers
<chrisf_> naww card is too old
<chrisf_> nvidia-glx-96
<BenC> chrisf_: that panel will tell you exactly which one you need, and install it for you
<mdz> rtg: I've spoken to davidm, and have him trying two things
<chrisf_> yeah it wont install or compile the module
<BenC> chrisf_: what's the compile log say?
<rtg> mdz: make sure he's remove the modprobe load delay.
<mdz> rtg: 1. reproducing the failure with an instrumented modprobe, so that we can try to see which modules are being loaded in which order at the point when it hangs
<mdz> rtg: 2. pci=nomsi
<mdz> rtg: I already did
<rtg> mdz: cool
<BenC> mdz: that's likely to be enough to offset the race to not happen
<mdz> BenC: I told him how to back it out in case it doesn't trigger anymore
<chrisf_> Error! Bad return status for module build on kernel: 2.6.27-7-generic (i686)
<chrisf_> Consult the make.log in the build directory
<chrisf_> /var/lib/dkms/nvidia/96.43.05/build/ for more information.
<chrisf_> Installing initial module
<chrisf_> Error! Could not locate nvidia.ko for module nvidia in the DKMS tree.
<chrisf_> You must run a dkms build for kernel 2.6.27-7-generic (i686) first.
<chrisf_> Done.
<tseliot1> chrisf_: see this bug report: https://bugs.launchpad.net/bugs/251107
<tseliot1> it doesn't depend on us
<chrisf_> yeah nvidia
<chrisf_> hasnt fixed there stuff
<mdz> BenC,rtg: he's just hung it with pci=nomsi
<rtg> drat
<chrisf_> ben: hehe i am no longer in florida
<chrisf_> this place is for the birds
<chrisf_> i hate the cold weather!
<mdz> rtg,BenC: is there any way to get the kernel to log a message whenever a module is loaded? that would be handy here
<rtg> mdz: I'm not seeing anything.
<mdz> rtg,BenC: I've just noticed that david has a modified boot process which is loading modules in parallel with the rest of the boot process
<rtg> mdz: how is his different then Jane's ?
<mdz> rtg: I don't have access to Jane's system at the moment, but I highly doubt she would have that change
<mdz> it might be a useful way to try to trigger the problem though, dunno
<rtg> mdz: I'm sure her's is stock.
<mdz> rtg: you can try it by commenting out the logic which calls udevsettle in /etc/init.d/udev
<mdz> rtg,BenC: do we have any strong indications that either silbs or davidm's problem is actually related to 3945?
<BenC> mdz: yes
<BenC> mdz: sleeping 5 seconds before loading 3945 solves it
<mdz> BenC: given that it's a race, that workaround you provided could easily throw things out of whack and cause it to not trigger
<mdz> even if the problem isn't in 3945
<BenC> mdz: the bug report has 10 dupes and lots of subs that all have found it to be iwl3945 (blacklisting other modules doesn't help)
<BenC> 3945 is the common factor
<mdz> BenC: the description says that -1 worked while -2 didn't.  has anyone bisected?
<mdz> or reviewed the diff?
<chrisf_> hmm aptitude is pretty nice
<BenC> I haven't
<BenC> but then, I can't reproduce it either
<chrisf_> ben: from what i am reading, nvidia really doesnt want to support legacy users
<BenC> mdz, rtg: Got to get a kid off the bus and fix dinner...
<mdz> iwl3945 didn't change at all between -1.2 and -2.3
<rtg> mdz: as far as I can tell, it's had no love in awhile.
<chrisf_> well i gotta reboot, as i was speaking they updated the nvidia packages
<chrisf_> reboot
<rtg> mdz: 32 bit kernel?
<davidm> rtg, in conversation with mdz I just realized that while I have the Intel Corporation PRO/Wireless 3945ABG hardware I am not really using it as my machine is hooked via Ethernet
<rtg> davidm: its still loading, and that is when you are getting hung up.
<rtg> davidm: that's a 32 bit kernel, right?
<davidm> yes
<davidm> 32 bit machine
<rtg> davidm: maybe thats why I can't repro. I'm resinstalling with i386
<davidm> my Ethernet controller is Intel Corporation 82573L Gigabit Ethernet Controller
<rtg> davidm: e1000e ?
<davidm> Yes
<davidm> This 'pci=nomsi' did not effect the bug, still happened.
<rtg> davidm: yep, heard that.
<davidm> rtg, OK, just making sure :-)
<rtg> davidm: drat, I'm 10 for 10 on a 32 bit kernel. no hangs. I'm gonna blast off for awhile.back in a couple hours.
<mdz> davidm: please put that info into the bug as well, bug 263059 seems closest
<NCommander> hold BenC 
<NCommander> *hola
<mdz> BenC,rtg: davidm just managed to reproduce without usplash, on a text console
<mdz> BenC,rtg: seems like a hard hang, no sysrq possible
<NCommander> BenC, I sent you an email requesting a kernel.u.c account so I can work on the linux-ports tree for PowerPC.
<mdz> I'm having him attach a photo to the bug
<mdz> rtg: he has it reproducing on the console more often than not.  maybe we should try instrumenting the driver to see where it's breaking?
<davidm> hellp
<davidm> hello
<davidm> that is 
<davidm> rtg, my laptop is now doing 3+ out of 5 locking at boot with usplash not in boot so you can see much better what is going on.
<davidm> rtg, do you or pete want my laptop for testing?  I can fedex out tonight
<davidm> rtg, pgraner either of you about?
<ARCKEDA> Lovely.
<mdz> davidm: tried phoning pgraner?
<davidm> I did no answer home or cell
<davidm> I'm about to call Tim
<mdz> davidm: random theory: could you try temporarily disabling the hwclock init script, which runs directly after S10udev, and see if that affects it?
<davidm> Will do
<davidm> about to reboot.
<davidm> OK that was fun, mdz no real change, first two boots good, next 4 NG then a good one and I'm here reporting.
<mdz> davidm: thanks for checking
<mdz> davidm: since you've had a few more boots, can you comment on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/263059/comments/95 ?
<davidm> NP, for sure it's more broken then not at this point.
<davidm> Will do
<mdz> davidm: if we can confirm that, it should narrow the field a lot, and perhaps rtg can chase it down
<davidm> It stops in differnt places, sometimes at the channels line, sometimes past that into another driver
<mdz> davidm: I know, but I'm only interested in the lines coming from 3945 and 80211
<mdz> davidm: the normal sequence is:
<mdz> [   17.379861] iwl3945: Detected Intel Wireless WiFi Link 3945ABG
<mdz> [   17.523620] iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels
<mdz> [   17.524272] phy0: Selected rate control algorithm 'iwl-3945-rs'
<mdz> but I have never seen it get as far as that third line when it hangs
<davidm> OK, I'll go punch the reboot button a bunch more and pay close attention to the lockup points.
<davidm> back in a bit.
<davidm> I have my shipping box by the by so I can send this unit out.
<davidm> OK, documented a series of hangs one after the other.
#ubuntu-kernel 2008-10-16
<pgraner> davidm: pong, sorry eating
<davidm> pgraner, my laptop is now able to reproduce the bug very well 8 out of 10 boots.
<pgraner> davidm: ok, did the workaround solve it?
<davidm> Do you want it?  I can fedex it to you or tim since it now is in text mode boot
<davidm> workaround does solve it.
<pgraner> davidm: its definitely a race, its just a matter of narrowing down what with the 3945 driver
<davidm> It also alwayst gets past USB boot sequence so you can use serial console if you need it.
<pgraner> rtg: ping... see above
<davidm> I have about 20 minutes to drop off time here.
<pgraner> davidm: does it have a real serial port?
<davidm> nope, just USB
<davidm> But USB is getting up before the hang from what I see.
<davidm> And as I say I'm in text mode so you can printk debug with it.
<davidm> usplash is hard off
<pgraner> davidm: is it hard hung, i.e. does the caps lock toggle on and off?
<davidm> hard hung
<davidm> no caps lock, no alt/printscreen t or 9 all locked solid
<pgraner> davidm: can you live without it for a few days? If so send it to rtg this way he has one that repros it
<davidm> I'm off on Friday so I have no issue giving you unit until Monday
<pgraner> davidm: ok send it to rtg, you have the addr?
<davidm> I need address to do so
<pgraner> davidm: via email
<davidm> OK
<davidm> I'll fedex for early delevery
<pgraner> davidm: you have mail
<davidm> OK
<davidm> OK have address will try to get FedEx to take it.  I'll be off line use phone to get me if need be
<emma> what type of error would this be: FATAL error inserting battery /lib/modules/..../acpi/batery.ko): no such device.
<NCommander> emgent, offhand, I'd say a bad one. It sounds like your kernel modules went and ran away
<NCommander> er, emma 
<emma> That's trouble.
<TheMuso> To me it sounds like the module in question can't find the hardware its designed to work with.
<emma> I got it from aptitude while installing xserver-xorg in the cli only mini.iso on a computer that's quite old.
<NCommander> emma, is it a laptop?
 * NCommander notes that should have been the obvious first question
<emma> The odd thing is, besides that fatal error, xserver-xorg runs.
<NCommander> Well, the fatal error sounds like its being caused by modprobe and not xorg
<emma> Nope not a laptop. This is an old dino-puter, I got it for fun and experimenting with linux. :) It's a Dell Optiplex GX1, Pentium III.
<emma> At install it said it had to force aspci
<emma> acpi that is.
<khaeru> Hello?
<mdz> anyone online with an iwl3945 to debug?
<NCommander> Sorry, iwlagn here :-/
<NCommander> I might be able to dig one up mdz 
<NCommander> mdz, speaking of things to debug, do you know what is needed to get a kernel.u.c account?
<amitk> NCommander: it helps to be a regular contributor first before requesting an account.
<amitk> NCommander: what are you planning to work on?
<NCommander> linux-ports kernel
<NCommander> I want to start work on rebasing to 2.6.27 in a side tree so once jaunty is available, and a kernel team member can sign off on it, it can become the jaunty kernel. I'm sorta irked at the age of the -ports kernel
<amitk> NCommander: why can't that be done by just pulling the current ports tree and doing it locally? Once you have something to show, there won't be a reason _not_ to give you an account :)
<NCommander> At the moment, the 2.6.25 tree is someone fracked 
<NCommander> *somewhat
<NCommander> I dunno what happened to it, but git explodes during a rebasing attempt
 * NCommander did have one of the kernel gurus also try it to rule out user error ;-)
<NCommander> so its more grab linus's tree, and start it again
<amitk> NCommander: 2.6.25 -> 26.27 is enough of a big jump that some attempts at rebase might fail because some patches become obsolete and cause conflicts. So we are better of discarding those patches. Trying 'git merge' to 2.6.27 final might get you there quicker. Then we can figure out the actual 'diff' and recreate a new tree.
<NCommander> Well, normally I'd agree
<NCommander> But its failed on trival patches as well
<NCommander> ITs like git can't see that this patch applies cleanly
<NCommander> (on the rebasing)
<NCommander> I personally felt it might be easier to just take the clean 2.6.27 drop, drop debian on it, then pop off each patch individually (there are maybe 15-20 tops)
<NCommander> (the debian folder that is)
<amitk> NCommander: i agree. 'git format-patch -o /tmp <commit id>' will help you export all ubuntu/ports patches on top of Linus' tree
 * NCommander nods
<NCommander> Pretty much what I was thinking
<ogra> amitk, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497200 is there a way that we get that driver in before final ? 
<amitk> NCommander: if you came back with such a tree, someone would have a easier time recommending you for a kernel.u.c account. :) But we will be glad to help while you do this...
 * NCommander wishes bzr-git existed
<NCommander> Oh well
<ogra> NCommander, not only you :)
<NCommander> I just wanted a place where I could upload my tree more or less
<NCommander> I don't have a machine where I canpush a git repo to
<ogra> NCommander, easy to solve btw, you just need to convine linus to switch upstream :)
<NCommander> Ouch
<NCommander> I personally wish he switched to monotone
 * NCommander likes mtn
<amitk> ogra: one thing at a time... mobile kernel first :)
<ogra> amitk, indeed, that would only be for post freeze, no hurry :)
<amitk> ogra: when is freeze?
<NCommander> amitk, well, I'm fairly new to kernel development, but the -ports kernel has seen no love pre-hardy when it was forked from the normal one, and I think if we're going to have usable ports, this needs to change :-/
<ogra> amitk, slangasek said something like "morning-ish UTC" 
<amitk> NCommander: agreed. we discussed this in kernel team meeting on tuesday
<amitk> ogra: today?
<ogra> yes
<NCommander> amitk, well, I'm a -ports user, REVU is on a sparc box. Its really pathetic that all the ports die because no one can maintain the kernel :-/
<ogra> amitk, it obviously didnt happen yet
<ogra> amitk, whoops it happened right now when i was typing the above 
<ogra> heh
 * amitk groans
<ogra> (see -devel)
<LimCore> hi, in 2.6.27 (ubuntu 8.10, amd64) - compared to 8.04 on same box (acer laptop single core), CPU usage is awesome (98% in C3 when idle, was 1% on 8.04 bue to probably kernel problem)
<LimCore> this rocks
<LimCore> however, now one thing causes wakeups (70 per second)
<LimCore> i915@pci:0000:00:02.0
<LimCore> I didnt see that one on 8.04... any ideas?
<LimCore> oh ok.  this is only when desktop effects are active.  I guess this is because it uses OpenGL mode...
<mdz> NCommander: if you have a 3945 system, debugging for bug 263059 would be greatly appreciated
<NCommander> I'll see if I can dig one up
<rtg> Ng: did you catch this little factoid re e1000e corruption? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=67d9b90a1c844bf1c6daaffd2c60561fc8c445f7
<Ng> rtg: yeah, I was gonna ask if we're going to take that :)
<Ng> I know basically nothing about ftrace, but it makes me wonder if it's possible it's causing other subtle weirdnesses
<rtg> Ng: test building now.
<rtg> Ng: its possible. I'm getting David M's laptop this morning 'cause it exhibits Jane's i3945 related crash. Its really weird and racy.
<amitk> rtg: 5 reboots without a hand on the 3945 now
<amitk> s/hand/hang
<rtg> mjg59: what happens if you access an I/O mapped register after pci_disable_device() ? I imagine its somewhat HW dependent.
<Ng> rtg: is your test build going to yield a handy .deb? If so I could do more reboot testing of my weird boot crash/corruption tonight
<mjg59> rtg: In principle, I don't think the device should decode it
<Ng> but that's purely me hoping and wishing that it will magically go away with ftrace ;)
<rtg> Ng: actually, I think its worthy of an upload.
<Ng> fair enough
<amitk> Ng: I'll have a .deb soon if you are on amd64-generic
<Ng> newp, i386
<Ng> I like my proprietary media to work ;)
<jdstrand> amitk: fwiw, I've got a similar issue with ipw2200, and I got 9 successful boots with the 10th a hang
<amitk> jdstrand: bug #?
<rtg> amitk: can you instrument your i3945 driver such that you can tell when the rf-kill handler is called?
<jdstrand> bug #284406
<rtg> mjg59: so you think it would wedge?
<rtg> i.e., stop the PCI bus.
<mjg59> No, it should just cause an aborted write
<mjg59> /shouldn't/ wedge it
<jdstrand> rtg: I don't seem to have a way to enable rf_kill. Fn+F5 will toggle it to 1, but it goes to 0 on reboot. I can disable it in the bios, but then ipw2200 isn't detected/loaded during boot
<pgraner> BenC: ping
<amitk> rtg: mdz already sprinkled some printks around rfkill_init() this morning. The .ko is attached to the bug.
 * amitk back in 15 mins (dinner)
<rtg> amitk: I don't have hardware yet. It should get delivered soon.
<amitk> rtg: I have a kernel compile going with FTRACE disabled. I'll tell after that.
<rtg> amitk: pull from the repo. I've already committed taht stuff
<mdz> amitk: so you can reproduce the bug now?
<mdz> jdstrand: I have a T42 I can test, any hints on reproducing bug 284406?  upgrading it to intrepid at the moment isn't practical, but I can test a CD
<jdstrand> mdz: not really-- just patience. I've gone as many as 9 consecutive successful reboots
<jdstrand> s/reboots/boots/
<jdstrand> mdz: I did have associate=0 in modprobe.d/ due to another bug that was fixed in 7.11, but removing that file makes no difference
<amitk> rtg: yes, I already pulled and building the kernel now. Almost done
<amitk> mdz: yes, I can reproduce, but very infrequently. Once in 10 tries or so...
<amitk> rtg: I'm not having too much luck reproducing after adding debug to the kernel cmdline
<mdz> jdstrand: at what point did this regression get introduced?
<mdz> asac,all: is there any clarity on whether bug 259157 needs to be fixed in userland or kernel?
<jdstrand> mdz: I am trying to ascertain that. I *definitely* know I never saw this in hardy. I thought I saw it in 2.6.26-5.17 once this morning, but am trying to reproduce that currently
<jdstrand> mdz: unfortunately, this is not a machine I actively use, so I may have well been hitting good boots all along in the cycle
<jdstrand> (though I seem to remember at least one time before the latest kernel that I had a hang, but didn't have time to troubleshoot)
<mdz> BenC: what is the resolution to be for 246269 (uvesafb)?
<amitk> *sigh* 20 reboots now without a hang.
<mdz> rtg: did the hardware arrive?
<rtg> mdz: yep - cloning /home
<mdz> rtg: great
<mdz> rtg: did it hang when you booted it up?
<mdz> I'm wondering if maybe it's tickled by what sort of APs happen to be nearby, if any
<rtg> mdz: on conf call, I'll be done in a bit.
<asac> mdz: there is no userland solution for atheros ... the previous we had used the wpasupplicant madwifi module
<asac> which doesnt work anymore i think
<asac> mdz: (thats for ath) ... for orinoco the solution could be user land, but the code changed considerably in NM and i havent received a single complained about it (and therefore no testers)
<asac> mdz: so to answer your question: atheros -> fix in kernel (though at least some appear to work with latest drivers); orinoco -> maybe userland
 * jdstrand finally got smart and created /etc/rc2.d/S19rebootme so he doesn't have to hand hold his laptop through endless reboots
<BenC> mdz: we uploaded a new kernel with vesafb as default
<mdz> BenC: we reverted from uvesafb to vesafb?
<BenC> mdz: right
<mdz> BenC,rtg,amitk,pgraner,cjwatson,slangasek: targeted kernel bug review on its way to your mailbox
<rtg> mdz: if the rf-kill switch is enabled, then the AP should have no influence
<rtg> ohh ah, locked up.
<mdz> rtg: good point, several of us tried that
<rtg> mdz: on another note, I upload Intrepid LBM about 4 hours ago. need to get Steve to release it.
<rtg> mdz: hmm, fixing this bug it gonna be difficult if I can't _ever_ get David laptop to finish booting. 5 for 5 on boot hangs
<mdz> rtg: he's managed to get it very reliable
<mdz> rtg: his boot process is modified from stock (he's not waiting for udevtrigger to finish before continuing)
<mdz> init=/bin/sh should get you in of course
<rtg> mdz: how does that effect rf-kill processing? I assume its udev tha does that as a result of ACPI events.
<mdz> rtg: the normal boot process does essentially "udevtrigger; udevsettle"  davidm's just runs udevtrigger and keeps going.  so it would mean that there are other init scripts running in the background while udev is still loading modules
<mdz> it probably gets to runlevel 2 or so before it's done loading modules
<davidm> 8 out of 10 will lock
<davidm> mdz i think you put udevsettle back
<rtg> davidm: I think I'm 10 for 10. init=/bin/sh never gives a prompt, I had to use break=top
<mdz> davidm: I did, but then you took it out again last I checked
<davidm> you may want to boot a cd
<davidm> nope i never touched it 
<mdz> rtg: so it's possible that it's one of the startup scripts in rcS.d after S10udev which tickles the bug
<davidm> that made the lock happen earlier
<paran> where have the linux-image-debug-* packages gone in intrepid?
<amitk> rtg: will wireless backports happen before release? if so, I'll skip bug #
<amitk> rtg: will wireless backports happen before release? if so, I'll skip bug #284354 for now.
<rtg> amitk: I'm not sure yet. I've been to busy with other stuff to get back top it.
<rtg> I have committed the current compat-wireless, but it didn't seem to work, e.g., would not connect.
<jdstrand> mdz: fyi-- 31 consecutive successful boot with 2.6.26-5.17-generic. moving on to 2.6.27-2.3...
<mdz> jdstrand: don't tell me, put it in the bug :-)
<jdstrand> mdz: I did :)
<mdz> paran: bug 253904
<amitk> rtg: since you are having more luck than I at reproducing the 3945, could you add the following debugging lines: https://pastebin.canonical.com/10277/
<rtg> amitk: what's the dump_stack() gonna show you?
<paran> mdz: thanks, so they are on ddebs? why? you really need kernel debug symbols to use things like oprofile or systemtap that are both in the normal archive :(
<amitk> rtg: the call stack, I got a freeze (only twice yet) right before that. I was hoping to get something out before the freeze
<rtg> amitk: gimme a bit. I rebuilt the module without rf-kill. its altered the problem enough that david's laptop appears to boot more reliably. no hnags after 4 tries.
<amitk> rtg: sure, take your time. I am about to put this on an automatic reboot loop and call it a day.
<rtg> amitk: later...
<Kano> hi, did you see that 2.6.27.1 hotfix?
<laga_> Kano: nobody in here follows upstream development
<laga_> you should have learned that by now
<Kano> well but that disables the root cause of the e1000 problem
<Kano> i would say it is very important
<laga_> i think an intel developer has submitted that patch to the kernel-team list
<Kano> disable CONFIG_DYNAMIC_FTRACE due to possible memory corruption on module unload
<Kano> you do not explicit need that patch,but at least disable it
<Kano> the patch would not hurt however
<rtg> alreay committed to the Intrepid repo
<rtg> *already
<Kano> is config changed?
<rtg> the Kconfig change is the patch
<Kano> ok
<Kano> will compile new snapshot then
<crimsun> ugh, we really need something like hal-info for HDA quirks.
<mjg59> Being able to set the mappings from userspace would help a great deal
<mjg59> As would being able to parse the .inf files
<solarion> is there any hope of getting the elantech touchpad driver into intrepid?
<solarion> It always goes quiet when I say that.  :/
<amitk> solarion: the ditro was frozen today and we release in 2 weeks. So nobody wants to add another driver at this late stage.
<amitk> *distro
<solarion> amitk: the request's been in since Hardy, and likely before
<solarion> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/123775
<solarion> yes, this bug is clearly over a year and a quarter old
<amitk> solarion: but clearly at that time it was an out of tree driver with no future. So it made it to the -mm tree later. What happened next? Do you know the story?
<solarion> I've no idea
<solarion> I just want to disable tap-to-click and enable scroll areas.  :)
<amitk> solarion: I suggest you right to the author here:  http://arjan.opmeer.net/elantech/ and ask him why the driver is still outside the tree after 3 major kernel versions.
<amitk> s/right/write
<solarion> amitk: good point
<solarion> there.  Sendified.  :)
<amitk> let us know what you hear back
<jdstrand> well, it took 36 tries (!) to get the boot hang (bug #284406) with 2.6.27-3.4, but ony 6 with 2.6.27-2.3... gotta love race conditions :(
<rtg> jdstrand: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/263059/comments/148
<rtg> its likely they are the same hang.
<jdstrand> rtg: excellent-- is it worthwhile to retest 2.6.26, or do you have enough to go on at this point?
<rtg> jdstrand:  I'm gnarling into that function, and I've solicited some advice from the wireless guys (no response yet)
<jdstrand> rtg: well, I've got this thing on a loop so I can let it churn away...
<rtg> jdstrand: instrument the ipw2200 driver so that it prints some locators, preferably just before and just after the call to ieee80211_register_hw()
<jdstrand> rtg: can you paste what you used for iwl3945?
<rtg> jdstrand: just do 'printk(KERN_INFO DRV_NAME " %d\n",__LINE__);' where DRV_NAME is something like 'ipw2200'
<jdstrand> rtg: ok, easy enough
<amitk> rtg: i've been looking at the link-order angle of this bug.
<amitk> but since 3945 is a module, that doesn't apply
<amitk> but is the order in which userspace triggers these module loads fixed? and if so, where is it?
<rtg> amitk: oh, defintely. David was able to get it more often by messing with udev settling
<amitk> where is keybuk when we need him?
<rtg> amitk: see /etc/init.d/udev. comment out the 'udevadm settle' clause in the restart option.
<solarion> amitk: looks like it might be in 2.6.28
<solarion> too late for intrepid, unfortunately
<amitk> solarion: first thing in jaunty though :) Did he mention why it took this long?
<solarion> amitk: no, but I didn't really ask that; I asked what was keeping it from going in-tree
<amitk> ok
 * solarion digs for the linux-kernel archive posting
<solarion> http://www.uwsg.iu.edu/hypermail/linux/kernel/0810.2/0404.html
<amitk> nice
<rtg> amitk: I've chased it as far as the rtnl_lock() in ieee80211_register_hw()
<amitk> rtg: the two times I did get a freeze, I saw all messages from ieee80211_init_rate_ctrl_alg()
<amitk> rtg: interestingly, https://bugs.edge.launchpad.net/ubuntu/+bug/263059/comments/128 finished pci_probe on every hang
<amitk> ^ using mdz's instrumented modules
<rtg> amitk: i just had it lock up _after_ the i3945 module init completed.
<amitk> ok. that makes more sense.
<amitk> or that is what I am seeing the bug reports
<amitk> rtg: comment out udevadm settle in restart or start option?
<rtg> amitk: mdz commented out the clause in restart (on David's machine).
<amitk> huh
<amitk> rtg: do you have then X60?
<rtg> amitk: T60
#ubuntu-kernel 2008-10-17
<cathyal> im just wondering
<cathyal> if things break in  ubuntu
<cathyal> do we always have to go into CLI to fix things
<lifeless> depends how broken it is
<lifeless> every operating system I know of has a CLI right at the very bottom :P
<lifeless>     ^ current
<cathyal> And some you can use without ever having to open it up, others not so much.
<AnAnt> Hello, can someone reply me on those bugs: 283330  & 281451
<AnAnt> 283330 is Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller not working properly 
<AnAnt> 281451 is uvesafb (and vesafb) does not support 1280x800 resolution for NVIDIA graphics adapters
<amitk> AnAnt: uvesafb is no longer default. The next kernel will revert back to vesafb.
<AnAnt> amitk: ok, vesafb has same problem
<amitk> rtg: so it has a physical switch to turn off the radios? and it is set to off?
<rtg> amitk: it must be one of these slider switches on the front.
<amitk> right
<rtg> amitk: I'm booting it to be sure
<rtg> amitk: yeah, that was it.
<rtg> amitk: have you _ever_ gotten yours to hang?
<amitk> rtg: you might be right about 3945 being the red herring. I just got it to hang again, right after sdhci and bt init
<amitk> this was only the third time 
<rtg> amitk: with 3945 blacklisted?
<amitk> nope
<amitk> unfortunately i just reverted to the distro kernel instead of the instrumented one
<Keybuk> [context]
<Keybuk> have been looking at the iwl3945 problem
<Keybuk> on my laptop, I have a kernel with most things compiled in
<Keybuk> only "drivers" are not, and on my laptop, the only driver is the iwl3945 card
<Keybuk> it still locks up from time-to-time
<Keybuk> and the lock up is during udev module loading, not kernel
<Keybuk> it's a Dell Latitude D420, not a Thinkpad
<rtg> Keybuk: 32 bit?
<amitk> Keybuk: another good data point if it isn't a thinkpad
<Keybuk> 32-bit, aye
<rtg> Keybuk: what happens if you compile in the 3945 ? I'll bet it stops hanging.
<Keybuk> I did not try that :)
<rtg> I can do that. How do I automate a reboot?
<Keybuk> as in make your laptop continually reboot?
<amitk> rtg: reboot in rc.local?
<Keybuk> put it in rc.local?
<rtg> does that give udev time to settle?
<Keybuk> udev settles inside its own init script
<Keybuk> if you're seeing the lock up some time after ... then that's a whole big important data point
<rtg> Keybuk: exactly
<Keybuk> err
<Keybuk> rewind
<Keybuk> you're seeing the lock-up after udev's init script has exited?
<Keybuk> later on in the boot sequence?
<rtg> Keybuk: mdz commented out the udevadm settle clause in restart on this laptop.
<Keybuk> interesting
<Keybuk> I must admit, mine is commented out too
<Keybuk> when I put it back, the lock up doesn't hapepn
<rtg> Keybuk: what does that do?
<amitk> Keybuk: i would've expected it to be commented out in the start clause
<Keybuk> then again
<Keybuk> I call settle later on, and the only thing I do in the meantime is activate swap, fsck and mount the root disk
<amitk> ..unless udev gets started in initramfs and the (re)started in rootfs
<rtg> but what does 'settle' do? How does it alter the timing?
<amitk> rtg: man udevadm says it makes sure the udev queue is empty
<Keybuk> rtg: udev listens to kernel uevents
<Keybuk> obviously by the time it's started, it's missed a *huge* number of them
<Keybuk> so it "triggers" them again by walking /sys and writing "add" to all the uevent files
<Keybuk> which makes the kernel send them again
<Keybuk> so it ends up with a queue of events it needs to process
<rtg> so in effect that means it waits for modules to finish loading before proceeding ?
<Keybuk> "settle" does not exit until the kernel's event seqnum and udev's event seqnum are equal
<Keybuk> err
<Keybuk> kiiiiinda
<Keybuk> it means that all of the devices that the kernel knew about when "trigger" were run, have at least had first-stage processing completed
<Keybuk> this may involve loading modules, yes
<Keybuk> and would wait for those modprobe commands to finish
<Keybuk> *BUT*
<Keybuk> loading those modules may have additional side-effects, such as further probing, further devices or interfaces showing up
<Keybuk> and those may have yet more modules to load
<Keybuk> settle may not wait for those
<rtg> hmm, quite asynchronous (as it should be)
<Keybuk> iwl3945 has no firmware?
<amitk> it does
<Keybuk> weird
<Keybuk> I can't see the call for it
<ajunior> exist a solution (patch) for e1000e driver?
<rtg> its called ucode in the driver
<Keybuk> oh
<Keybuk> I thought all the firmware got separated out?
<rtg> Keybuk: iwl3945_read_ucode()
<Keybuk> there's a /lib/firmware/iwlwifi-3945-1.ucode after all
<amitk> ajunior: fixed in the ubuntu tree. will be in next kernel.
<Keybuk> rtg: right, that uses request_firmware()
<Keybuk> my point is that I can't *see* that request from userspace
<ajunior> TKS
<rtg> Keybuk: I think thats not relevant. with rf-kill switch enabled the hang still happens.
<Keybuk> well, firmware loading affects timings that's all
<Keybuk> as in the modprobe will have to request a firmware
<Keybuk> which is another udev event
<Keybuk> which may affect settle (though shouldn't, because I think the modprobe blocks for it)
<rtg> Keybuk: agreed. but it in this case it doesn't seem to make a difference.
<Keybuk> no...
<Keybuk> I'm just weirded out by the missing request :p
<Keybuk> oh
<Keybuk> no
<Keybuk> I'm just being stupid
<Keybuk> I see it now
<Keybuk> I forgot that firmware now appears as $DEVPATH/firmware/$ID
<Keybuk> rather than /sys/firmware
<Keybuk> :p
<Keybuk> could it be related to device renaming perhaps?
<rtg> Keybuk: you mean eth1 --> wlan0 ?
<Keybuk> swapping eth1 and eth0
<Keybuk> and yeah, renaming wlan0 to eth1 :p
<rtg> Keybuk: that seems like a something the nested lock checking would catch.
<rtg> its an rtnl lock
<amitk> there was a related renaming isse queued for the stable tree that I pulled in: 7b54c00efa87f519ae30f09bdbb11aaf6644605f
<Keybuk> we don't call ifup on the device unless it's in /e/n/i (it isn't for me) and that's only after the device appears
<Keybuk> could it be something network manager is doing on the device?
<Keybuk> though that is quite late in the boot relatively
<rtg> Keybuk: the hang happens long before X starts, so no NM in play.
<Keybuk> NM starts in userspace first
<Keybuk> rc2/S28
<rtg> hmm, ok
<Keybuk> my really stripped down boot replicates it, you see
<Keybuk> that is
<Keybuk>  udevd
<Keybuk>  trigger
<rtg> amitk: I have that commit in my test kernel.
<Keybuk>  swapon -a -e
<Keybuk>  fsck /
<Keybuk>  mount /
<Keybuk>  update mtab, make tmp directories
<Keybuk>  udev settle
<Keybuk>  start dbus
<Keybuk>  start hal
<Keybuk>  start gdm
<Keybuk>  ifup -a
<Keybuk>  start NM
<Keybuk> --
<rtg> Keybuk: can you get the kernel to trigger a stack dump or anything?
<rtg> mine locks so hard that caps-lock light is wedged.
<Keybuk> no :-/
<rtg> Keybuk: do you mind getting stuck with this bug? I've gotta send David's laptop back to him pretty soon.
<rtg> plus, I'm a bit out of my depth.
<Keybuk> "getting stuck" ?
<rtg> Keybuk: how else should I phrase it? I'm assigned to it in LP.
<Keybuk> I don't mind helping debug in spare time, but I don't really have enough free time to devote myself to it :-/
<rtg> Keybuk: I think if we work around it by delaying the i3945 module load, we can side step the issue for now. I believe it _will_ come back to haunt us during our effort to improve boot times.
<Keybuk> delaying how?
<rtg> insert a 5 second delay in the modprob entry.
<Keybuk> it's not clear to me that it's actually racing anything but itself
<Keybuk> sleep 5 would just extend the udevsettle by 5s too :p
<rtg> Keybuk: I am quite sure its not an issue with the i3945 driver, at least not directly. Jamie can reproduce it with ipw2200.
<Keybuk> what else do you think it is?
<Keybuk> \o/
<Keybuk> just got it without "quiet" ;)
<AnAnt> Hello, can someone look at those bugs: 283330 & 281451
<rtg> I've seen the i3945 complete its initialization before hanging. with rf-kill enabled, thats the last thing that happens in that device driver. hangs occur randomly during and after i3945 module loading.
<Keybuk> rf-kill enabled?
<rtg> Keybuk: the little slider switch  that disables wireless.
<Keybuk> right, that's disabled for me
<Keybuk> ie. radio is on
<AnAnt> I have reported a bug similar to 283330 last year (111756), yet I never got any response about it yet
<rtg> ok, the other way around.
<Keybuk> first hang was after
<Keybuk> iwl3945 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
<Keybuk> second hang had two more messages
<Keybuk> iwl3945: Detected Intel Wireless WiFi Link 3945ABG
<Keybuk> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
<Keybuk> so it's not quite happening at the same point each time
<rtg> Keybuk: I've found that with wireless 'enabled' the hang happens less often. Its about 50/50 with wireless disabled.
<rtg> and it definitely happens at different points in the boot sequence.
<Keybuk> right
<Keybuk> but I've elimated that from my tests
<Keybuk> it is entirely unrelated to any software alongside
<Keybuk> I get the hang with only the modprobe :p
<rtg> so, you're saying it really _is_ the i3945 driver?
<Keybuk> it looks like it to me
<rtg> what about the ipw2200 data point?
<Keybuk> what's the other network card in the Thinkpad?
<rtg> e1000e
<Keybuk> tg3 here
<AnAnt> bdmurray: there you are
<Keybuk> rtg: am trying loading only the 3945 driver in isolation repeatedly
<Keybuk> so far, it doesn't hang
<Keybuk> which is interesting
<rtg> Keybuk: if you're really sure its i3945, then that lends credence to my suspicion that its hardware related. Perhaps its some kind of PCI bus setup issue?
<Keybuk> well, I'm confused as to what else it could be
<rtg> The Hardy driver is quite different. Jamie was unable to reproduce this hang with 2.6.26-5.17-generic, all subsequent released _did_ hang.
<amitk> Keybuk: lool has already tried the modprobe/modprobe -r test on the 3945 over 700 times. Couldn't reproduce it.
<Keybuk> amitk: yeah
<Keybuk> that's downright weird
<Ng> I forget if I asked this before, but is there any display corruption ever?
<rtg> Ng: related to this hang?
<Keybuk> it seems like it only hangs if udev calls modprobe ?!
<Ng> rtg: yeah
<rtg> Ng: I've never noticed any.
<Ng> ok, 'cos my random boot hang that does have corruption seems to happen shortly after iwl4965 loads
<Ng> well, iwlagn now, but whatever
<rtg> I wonder if this is something we ought to solicit Intel's help with?
<Ng> err no wait I'm on crack, it's intel_agp that's implicated in mine. As you were ;)
<NCommander> amitk, ping, if you get this before you commit my patch
<amitk> NCommander: done
<rtg> Keybuk: would you comment in #263059 why you think its driver related. I'm not exactly sure how you've come to that conclusion. In the meantime I've gotta get this laptop shipped.
<Keybuk> well
<Keybuk> I don't get the hang if I don't load this driver ;)
<rtg> I agree with that, but its not conclusive.
<Keybuk> I *think* it has something to do with the interface being renamed
<Keybuk> that always seems to be the last thing that happens before the hang
<rtg> well, I have a little time. I'll instrument that code. its pretty straightforward IIRC.
<Keybuk> and if I disable that rule in udev, I haven't had the hang yet
<rtg> Keybuk: I don't read udev very well. which rule is that?
<Keybuk> the persistent-net ones
<Keybuk> you need to remove the 7x one that has the rule
<Keybuk> and the 6x one to stop the rule coming back
<Keybuk> what's ecb(arc4) ?
<rtg> dunno
<elmo> crypto stuff
<Keybuk> hmm
<rtg> Keybuk: which 60* rule are you talking about? Can't see anything net related.
<Keybuk> sorry
<Keybuk> 75-persistent-net-generator.rules
<Keybuk> and 70-persistent-net.rules
<rtg> 75-persistent-net-generator.rules whitelists eth and wlan, so won't they be ignored?
<Keybuk> I just moved the files out of the way :p
<rtg> are these rules created during install according to installed HW ?
<Keybuk> each boot
<Keybuk> though I just ruled that out
<Keybuk> finally got one to hang without them
<Keybuk> they were just adding time
<rtg> hmm, dead-end
<Keybuk> this is baffling
<Keybuk> it did:
<Keybuk>  modprobe tg3 (for eth0)
<Keybuk>  seems to have finished
<Keybuk>  iwl3945 messages
<Keybuk>  Tunable channels blah
<Keybuk>  modprobe ecb(arc4)
<Keybuk>  iwl3945 0000:0c:00.0: PCI INT A disabled
<Keybuk>  *hang*
<rtg> so, it didn't make it to the device rename.
<Keybuk> I didn't include the device renaming stuff
<Keybuk> so it would never try
<rtg> by the time you see 'iwl3945 0000:0c:00.0: PCI INT A disabled', the module inti is complete.
<Keybuk> do you get the hang if you disable the e1000 from loading?
<rtg> Keybuk: lemme try.
<rtg> Keybuk: still locks up
<Keybuk> ooooh
<Keybuk> "Dazed and confused, but trying to continue"
<Keybuk> the full error message of that
<Keybuk> Uhhuh. NMI received for unknown reason b1 on CPU 0.
<Keybuk> You have some hardware problem, likely on the PCI bus.
<Keybuk> Dazed and confused, but trying to continue.
<Keybuk> -- 
<rtg> Keybuk: my feeling exactly
<Keybuk> while loading the iwl3945 driver
<Keybuk> rtg: you think this is a hardware problem?
<rtg> its certainly hardwar'ish
<Keybuk> I tend to doubt that hypothesis
<Keybuk> because the hardware in question isn't even one piece, but across multiple types of laptop
<Keybuk> and its only *this* driver that triggers it
<Keybuk> or, at least, this family of drivers :p
<rtg> Keybuk: could be the family of PCI interface chips used in these adapters.
<Keybuk> why would it only occur now, with 2.6.27 ?
<Keybuk> and why only when loading the iwl* driver alongside another driver
<Keybuk> sounds much more like the driver is failing to correctly lock out the PCI bus to me
<rtg> Keybuk: whats the other driver? I disabled e1000e and it still happened.
<Keybuk> any pci driver fwict
<Keybuk> both tg3 and the pcmcia socket adapter seem to do it for me
<Keybuk> but only when combined with iwl
<rtg> Keybuk: that kind of makes sense. 
<Keybuk> that's why the modprobe loop doesn't work
<Keybuk> you're only loading/unloading iwl3945
<Keybuk> but if you load two drivers at once, you get the hang or crash
<rtg> which 2?
<Keybuk> (I'm doing while true; do modprobe iwl3945 & modprobe tg3; done)
<rtg> and that hangs?
<Keybuk> yeah
<Keybuk> and if it doesn't hang, I get that cute error message sometimes ;)
<rtg> are you unloading them first?
<Keybuk> yes
<rtg> outstanding.
<rtg> finally, got it to do something.
<rtg> or you did, rather.
<rtg> Keybuk: so, I should look at the difference between Hardy and Intrepid start-up.
<Keybuk> what's the difference between the drivers?
<rtg> Keybuk: in Intrepid the i3945 init is seperate from the other iwl drivers. They were more common in Hardy. Beyond taht I'll have to study them a bit before I know more.
<NCommander> does anyone else here work on the lpia kernel beside ScottK and amitk who can answer some questions?
 * ScottK declaims all knowledge of anything in the kernel and suspects that maybe NCommander is thinking of persia.
<NCommander> we
<NCommander> StevenK
<NCommander> Damn autocomplete
<NCommander> *er
<Keybuk> yeah
<Keybuk> a dozen times now, have the hang just with the modprobe loop with two modules in it
<Keybuk> all I have running is udev (no rename rules or anything - and can't see any side-effects with --debug on)
<Keybuk> even the filesystem isn't writable, and no swap mapped
<rtg> Keybuk: get that stuff in the bug report please. Its gonna be key in finding root cause.
<Keybuk> bug# ?
<rtg> Keybuk: 263059.
<rtg> Keybuk: one of the major differences that I see right off is that the PCI device is disabled at the end of the probe in Intrepid, whereas its left enabled in Hardy.
<Keybuk> weird
<Keybuk> ifconfig eth1 up
<Keybuk> SIOCSIFFLAGS: No such device
<rtg> Keybuk: you should boot Hardy and see if you can still reproduce it.
<Keybuk> this is just with a normal boot trying to get my debugging info out :p
<Keybuk> oh
<Keybuk> had the kill switch on
<Keybuk> heh heh heh
<rtg> borked, huh?
<Keybuk> PEBCAK
<rtg> Keybuk: you mean no lspci?
<Keybuk> no, lspci is still there
<Keybuk> sysfs is still there
<Keybuk> it's even still listed in ifconfig
<Keybuk> but any ioctl return -ENODEV
<Keybuk> and the dmesg implies the interrupts are disabled
<rtg> Keybuk: in fact, the interrupt isn't even assigned if rf-kill is enabled.
<Keybuk> so it's in a state I'm not familiar with ;)
<rtg> Keybuk: yeah, the last thing the driver does is pci_disable_device()
<Keybuk> but it enables it later if the kill switch is off?
<Keybuk> or does it not call pci_disable_device() if the kill switch is off?
<rtg> if wireless is enabled (i.e., kill switch is off), then pci_enable_device() is called at if-up time.
<rtg> this is a change in behavior from Hardy.
<Keybuk> I'm wondering whether there's some invalid state going on based on the kill switch status
<Keybuk> and if the switch is off, the invalid state lasts _less_ time than when it's on
<Keybuk> and while in that invalid state, other pci drivers can hang the system
<rtg> you can't get this to happen if kill-switch is off?
<Keybuk> I can, just much less so
<Keybuk> which to me implies the time window of the hang is less if the switch is off
<Keybuk> when it's on, it's much more regular
<rtg> well, there is certainly less code in the driver being executed when the switch is on.
<trenton_> Apologies if I intrude, but have run out of options. I'm trying to get 2.6.27 on hardy is this posible? Without compiling that is.
<rtg> trenton_: kernel-ppa
<rtg> https://edge.launchpad.net/~kernel-ppa/+archive
<trenton_> rtg: thanks
#ubuntu-kernel 2008-10-18
<NCommander> amitk, ping
<mnemo> is there anyone from the intrepid kernel release team here? if so, please consider cherry picking this patch for intrepid --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/285572
<oneunshamed> not really related to unbuntu - but if any of you guys are into collecting celebrity memorabilia, etc - the company I am working for is streamcasting (w/ interactive bidding) the Bob Hope estate auction going on right now in Hollywood. http://www.auctionnetwork.com/
<oneunshamed> cool concept at the very least :)
#ubuntu-kernel 2008-10-19
<uwe__> is there something wrong with the repo right now?
<uwe__> i get remote end hung up when i try to clone it
<uwe__>  git clone git://kernel.ubuntu.com/ubuntu/ubuntu-inrepid.git
<NCommander> uwe__, it worked fine for me easierly
<uwe__> my url is right?
<NCommander> Checking
<NCommander> uwe__, you had a typo
<NCommander> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-intrepid.git
<NCommander> Try that
<uwe__> ...
<uwe__> thanks for help
<uwe__> i just found out today that there is a git repo
<uwe__> makes testing much easier
<NCommander> uwe__, lol ;-)
<nigel_c_> Gidday all. I'm seeking to prepare ppa kernels with TuxOnIce applied to git. I've tried Hardy and Intrepid.
<nigel_c_> In both cases, building after uploading fails.
<nigel_c_> With Hardy, it's trouble with the custom flavours. Do I _have_ to build them all? If not, what's the best way to disable one or more?
<nigel_c_> With Intrepid, I get "Previous or current ABI file missing". Not sure how to proceed there either.
<NCommander> Nicke, hey
<NCommander> nigel_c, what kernel are you trying to build?
<NCommander> You usually need to move the ABI folder to build it
<NCommander> nigel_c, for every time you build a new verson, you need to bump the kernel version
<NCommander> hey amitk
<nigel_c> NCommander: I'm working from current git, so...
<NCommander> nigel_c, Whats the current version in debian/changelog, and whats in debian/debian
<nigel_c> Yeah, I think 2.6.27-7.10.
<NCommander> er, debian/abi
<nigel_c> k. will look
<NCommander> What do you have in debian/abi?
<nigel_c> ls debian/abi/
<nigel_c> 2.6.27-7.10  perm-blacklist
<nigel_c> changelog: linux (2.6.27-7.11) intrepid; urgency=low
<NCommander> Hrm
<NCommander> That SHOULD work
<NCommander> run fakeroot debian/rules check, tell me the error
<nigel_c> I'm sure I've done something wrong :) Will do.
<nigel_c> fakeroot debian/rules check
<nigel_c> make: *** No rule to make target `check'.  Stop.
<nigel_c> (Trying in intrepid)
<NCommander> Are you at the base of the kernel folder?
<nigel_c> Yeah,
<nigel_c> And git status says the tree is completely clean.
<NCommander> Ok ...
<NCommander> very strange
<NCommander> What is the specific build failure you got?
<nigel_c> If I switch back to origin (the tree I'm pulling into), it still says no rule to make check.
<nigel_c> http://launchpadlibrarian.net/18682125/buildlog_ubuntu-intrepid-amd64.linux_2.6.27-7.10%7Etuxonice1_FAILEDTOBUILD.txt.gz
<mnemo> is there anyone from the intrepid kernel release team here? if so, please consider cherry picking this patch for intrepid --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/285572
<NCommander> Oh
<NCommander> the PPA versioning thread is causing issues
<NCommander> er
<NCommander> not thread
<NCommander> the ~versionX
<NCommander> Rename the 2.6.27-7.10 ABI file from debian/abi to 2.6.27-7.11
<NCommander> And reupload to your PPA
<NCommander> THat should get you a successful build run
<nigel_c> Okay.
<NCommander> nigel_c, aren't ther kernel packages fun ;-)
<nigel_c> :)
<nigel_c> I've been trying this on and off for a few days, so I won't argue :)
<nigel_c> Okay. Starting an upload now.
<nigel_c> I'm on ADSL1, so this will take a while :)
<nigel_c> Thanks for your help NCommander - I'm going to head off to bed now (Eastern Australia) and check the results in the AM.
<NCommander> ok
#ubuntu-kernel 2009-10-12
<MTecknology> Where can I pull down the kernel source and default .config?
<lifeless> debcheckout linux-x-y-z
<MTecknology> !info debcheckout
<ubot3`> Package debcheckout does not exist in jaunty
<MTecknology> !search debcheckout
<ubot3`> Found: 
<MTecknology> lifeless: ?
<Darxus> Heh.
<Darxus> MTecknology: You already have the .config you're using, somewhere in /boot/.
<Darxus> There is a linux-source package...
<MTecknology> thanks :)
<Darxus> You're welcome.
<MTecknology> hopefully I actually know enough to go mucking around in it :P
<lifeless> the linux-source package isn't quite the same as the repo
<lifeless> its output during the build, as opposed to whats used to build packages
<lifeless> if you want to build a new package, you want to use apt-get source or debcheckout
<lifeless> $ dpkg -S debcheckout 
<lifeless> devscripts: /usr/bin/debcheckout
<Darxus> Or make-kpkg...
<MTecknology> 4 days until freeze - anything important left to finish off?
<MTecknology> 2.5 min left to pull it :P
<MTecknology> "These are 'Null' algorithms, used by IPsec, which do nothing." ... what's the point of this?
<MTecknology> CONFIG_CRYPTO_NULL
<hzhang__> ericm_, if so, <ericm> phenompanda, test build has no prob with latest kernel - EABI without OABI_COMPAT
<lifeless> testing
<hzhang__> ericm_, what's the difference between those two binaries?
<hzhang__> ericm_, like size vmlinux, how much data section and bss section squeezed ?
<MTecknology> wow.. you guys pack a whole lot into the kernel
<jk-_> MTecknology: testing, i'd say
<MTecknology> jk-: I think there's always a lot in there - just part of having a distro that "just works"
 * MTecknology loves "make all modules_install install"
<Darxus> I'm wondering how much benefit there would be to a program that figured out what hardware you have and recompiles a custom kernel for you.
<Darxus> Something that "just works".
<MTecknology> Darxus: not a bad idea but that would be hard considering some people will install ntfs-3g only the second they need it
<MTecknology> ar similar
<ericm_> hzhang__, haven't compared yet - wait moment
<MTecknology> Is there any reason for this setting? drivers/block/cciss.c:3153: warning: the frame size of 1056 bytes is larger than 1024 bytes
<ericm_> hzhang__, ok will check once compilation is done here
<ericm_>    text	   data	    bss	    dec	    hex	filename
<ericm_> 3211565	 250208	 112336	3574109	 36895d	vmlinux.with_oabi_compat
<ericm_>    text	   data	    bss	    dec	    hex	filename
<ericm_> 3204537	 250112	 112336	3566985	 366d89	vmlinux.no_oabi_compat
<ericm_> withou oabi_compat, code size seems to shrink a bit, but not data section, is this what you expected?
<hzhang__> ericm_, well, not a very good news, but also worthy to give a try ...
<hzhang__> ericm_, 7KB text section and 80Bytes data ... 
<hzhang__> ericm_, thanks, anyway :) 
<ericm_> MTecknology, for testing - most drivers are built-in instead of being module - so comes the size
<MTecknology> ericm_: compiling the default kernel less some stuff takes a long time :P
<MTecknology> I didn't realize how much is needed for a kernel that will "just work" for everyone
<ericm_> hzhang__, yes - I guess that's significant for your environment ;-)
<hzhang__> ericm_, well, once you try this "nm --size -r vmlinux | head -10" for search for big symbols
<hzhang__> ericm_, you will always get a 8K bytes symbol  in data section - "init_thread_union"
<ericm_> MTecknology, I see - thanks
<hzhang__> ericm_, 8K, is that a must? seems others are quite tiny, no more than 4KB 
<MTecknology> How do I update grub2 to use the newly installed kernel?
<ericm-afk> MTecknology, /boot/grub/grub.cfg?
<MTecknology> ericm_: I didn't know if update-grub would do it or not
<ericm_> MTecknology, supposed so - I haven't done a kernel upgrade yet
<ericm_> MTecknology, are you installing a kernel package or something you built yourself?
<MTecknology> I built one
<MTecknology> ericm_: looks like update-grub does work
<ericm_> MTecknology, cool
 * ericm_ will be back in a while
<Keybuk> so here's a fun one, after a few hours this machine slows down to an absolute crawl
 * Keybuk wonders how the hell he'd go about debugging that
<amitk> Keybuk: nothing showing up in iotop or latencytop?
<Keybuk> no, that's the curious thing
<Keybuk> I'll check again next time it does it
<apw> Keybuk, perhaps a memory leak, take a snapshot of slabinfo when you are working and compare to when you are broken
<Keybuk> it's gone slow now
<Keybuk> so what should I look for?
<Keybuk> latencytop says
<Keybuk> Scheduler: waiting for cpu                        107.7 msec        100.0 %
<Keybuk> unusable now - so shall reboot
<Keybuk> then compare
<Keybuk_> I was going to do the "at least Linux boots fast" joke
<Keybuk_> but it didn't boot at all!
<Keybuk_> "VFS: unable to mount root" PANIC
<Keybuk> apw: the biggest difference in slabinfo during slowness and after reboot is in buffer_head
<Keybuk> now:
<Keybuk> buffer_head        17048  17064    112   36    1 : tunables    0    0    0 : slabdata    474    474      0
<Keybuk> while slow:
<Keybuk> buffer_head       143563 143568    112   36    1 : tunables    0    0    0 : slabdata   3988   3988      0
<apw> whats head -1 of that say
<Keybuk> slabinfo - version: 2.1
<Keybuk>  ?
<Keybuk> or did you mean
<Keybuk> # name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
<apw> yea
<apw> that doesn't sound like an earth ending amount
<apw> hrm
<Keybuk> indeed
<jk-> you can end the earth with the slab allocator? cool.
<apw> oh yeah :)
<Keybuk> apw: nothing really revealing in iotop or latency top either
<Keybuk> I wonder whether it's this dodgy "you want hardware? I get you hardware!" SSD
<apw> does it recover on a reboot?
<apw> i'd expect ssd effects to be more ongoing
<Keybuk> no, that's what's making me think
<Keybuk> it only recovered after a physical power off and on again
<apw> hrm
<Keybuk> next time it does that, I'll see whether just the reboot makes it recover or not
<Keybuk> it was a bit hard to this time due to the empty initramfs issue
<apw> we have an empty initramfs?
<Keybuk> yes, seen it a couple of times now
<Keybuk> initramfs update gets borked
 * apw struggles to understand why installing one kernel now means we rebuild the grub config 2x
<apw> especially now its as slow as nose-juice
<apw> Keybuk, that reminds me, dispite usplash being back there is a fair gap between the end of usplash and x starting, is that expected?
<Keybuk> I guess
<Keybuk> X takes a second or two to start
<apw> as we're not changing mode i am supprised usplash can't persist till X zaps the display
<apw> for KMS setups
<apw> iisn't that what plymouth does, just exits leaving the display message, and asks X to leave it alone?
<Keybuk> basically yes
<Keybuk> but we've never figured that patch out
<Keybuk> and it may be that usplash's svgalibness prevents it
<Keybuk> much as it pains me to suggest it, we may have to do plymouth and forgo nvidia-glx users wrath
<Lure> can somebody review request to cherry-pick from linus (if new kernel is planned): bug 392017
<ubot3`> Malone bug 392017 in xserver-xorg-video-intel "kms and nonkms use different display names. HDMI-1 vs DVI1" [Unknown,Fix released] https://launchpad.net/bugs/392017
<apw> rtg i am looking at an issue with slow mount on usb disks, and it feels like readahead simply doesn't work ... seen anything like that?
<rtg> apw, mounting a rootfs on a USB disk?
<apw> this is simply mounting a vfat filesystem, it does a scan of the fat to work out free blocks cause 'the other' doesn't keep the superblock stats up to date
<apw> from what i can see its submitting read ahead but not getting any benefit at all
<apw> performance wise
<apw> and wondering if it rang a bell
<rtg> apw, do you think the I/O scheduler setting has anything to do with it?
<apw> seems the same with cfq and with deadline
<rtg> then no, I've not encountered it
<jjohansen> apw: is it usb hd or a usb flash?
<apw> its a rotating disk in this case
<jjohansen> apw: could it be because it is fat, and has to read in the fat table
<jjohansen> s/table/tables/
<apw> yep its defiantly fat and the fat table thats the issue
<apw> but ... they added readahead support for it for this very operation
<apw> and it seems to be triggereing, but the performance simply sucks, like its not there
<rtg> apw, I mounted as fairly large ext3 USB disk just yesterday with no noticeable delays
<apw> rtg, non-fat are not affected, this is a specific fat pattern triggered issue
<rtg> apw, the moral of the story is, don't use FAT.
<apw> it used to work, now it doesn't ... something broke
<apw> from the evidence i have to hand it implies readahead is not working
<apw> which would impact everything and everyone
<rtg> apw, oh, that seems a bit more serious
<apw> if i am reading this right its taking 1min40 to read 7mb
<apw> 76mb in 1:40 ... still unreasonable even for a harddrive
<jjohansen> apw: yikes that is bad
<apw> yeah not even sure why it would be that bad even without read ahead, as its doing linear reads anyhow
<jjohansen> apw: if it is close to the same with and without read ahead, and the figure is that bad I would think it is something else that is broken
<smb> apw, If everything is linear the device cache should have a performance boost. The question is whether bios are correctly merged into larger requests or whether small ones get sent down
<apw> well without readahead they are syncronous 512 byte sector reads
<apw> with it in theiry they should be dumped in in 256 sector chunks
<smb> wasn't device read ahead 128 sectors?
<apw> this is being done explicitly in the fs
<smb> hm, there is another setting defined in the device queue
<smb> in /sys/block/sd?/queue/read_ahead_kb (ok, it actually 128 kb)
<apw> yep, but this is explicit, so even if the one you mention there is not working this one is definatly occuring
<smb> right, if the fs does this too, this should generate requests of that size at least. 
<smb> Actually there has been another thing (maybe on the vfs layer) which would adapt on the amount of sequential hits...
<Lure> rtg: thanks for takin care of bug 392017
<ubot3`> Malone bug 392017 in linux "kms and nonkms use different display names. HDMI-1 vs DVI1" [Low,Fix committed] https://launchpad.net/bugs/392017
<rtg> np
<rtg> smb, apw: you guys never answered my question about CONFIG_X86_PAT
<smb> rtg, no not really. And I got no idea why it was/is unset
<rtg> smb, what harm do you foresee if its enabled?
 * apw is supprised to find it is off
<smb> I cannot claim complete understanding but as it is the default there should not be much harm
<rtg> which is why I'm pushing the issue.
<rtg> ok, I'm gonna turn it on for Beta
<cking> it's been around for quite a while - anyone seen any other distros with kitten killer X86_PAT bugs?
<rtg> cking, yeah, I'm a bit boggled that we don't have it enabled.
<cking> and there's a nopat kernel boot option isn't there if it causes an issue with broken H/W
<rtg> yep
<apw> rtg beta, didn't we aleady ship beta?
<rtg> apw, uh, you know, the next kernel whatever it is.
<apw> heh :)
<cking> hehe - there are SuSe discussions on why Ubuntu left it out w.r.t. the e1000e bug way back
 * cking wonders if the citysprint emailer is actually not human - in which case, I may have failed the turning test
<cking> s/turning/Turing/
<rtg> cking, you couldn't 'turn' on a dime?
<rtg> jjohansen, you gonna put the full court press on the ec2 i386 regression?
<jjohansen> rtg: yep
<rtg> jjohansen, thanks.
<jjohansen> right now I am doing clean rebuilds of and akis of everything
<rtg> jjohansen, you should rewind a re-do the rebase yourself. IIRC I had a conflict that I solved, but perhaps I flubbed it.
<jjohansen> rtg: will do, just want to double check with a second build, it is easy too easy to mess something little up
<pgraner> cking: sorry, didn't realize we were in the DT channel
<cking> pgraner, why upgrade the BIOS - the version on that PV is the same as the one on my one which runs Karmic OK
<pgraner> cking: Didn't know, I usually try and keep boxes up to the latest 
<cking> living life on the bleeding edge again..
<cking> pgraner, I kinda helped them iron out all the Linux-centric BIOS issues, so it should be OK
<cking> ..but if you like pain, I'm not stopping you upgrading ;-)
<pgraner> cking: nope I"m good, I just assumed that the one on the box was old and could use a bump
<cking> pgraner, I kept 4 of these boxes upto date, so they are good IMHO
<pgraner> cking: cool
<Darxus> I had /window 15
<Darxus> Oops.
<lamont> where did my broadcom-working state go ?
<lamont> meh... is network mangler, not kernel
<rtg> lamont: this is a binary blob driver, right?
<lamont> rtg: it's a perfectly functional driver.... network mangler just failed to bring it up
<lamont> ifconfig and it's happy
 * rtg thinks binary blob and perfectly functional is an oxymoron
<lamont> well, functional is totally separate from _SUPPORTABLE_ :(
<UnitesSta> New facebook! Win 1 of 5000 IPODS NANO 5G! http://vk.com/reg3329057
<UnitesSta> New facebook! Win 1 of 5000 IPODS NANO 5G! http://vk.com/reg3329057
<Whoopie> rtg: Hi, did you think about enabling CONFIG_PCIEASPM? It saves some power on laptops.
<rtg> Whoopie, its still marked experimental.
<Whoopie> rtg: what about enabling the CONFIG_, but disabling by default so that the user can enable it via sysfs?
<MTecknology> So... I downloaded the kernel source, used the same config that's in /boot, compiled and installed using "make all modules_install install", and booted to it but it died on boot complaining about not being able to remove /forcefsck on read-only file system
<MTecknology> I didn't make any modifications to the kernel..
<Whoopie> rtg: it's enabled in config.flavour.powerpc-smp
<rtg> Whoopie, send an email to the k-t list and I'll consider it later.
<Whoopie> ok, thanks
<rtg> MTecknology, I has something similar happen to me on a fresh install today. what is your clock setting? 
<MTecknology> rtg: how do I check that?
<rtg> MTecknology, from your BIOS during boot. it must be ahead of the file system
<MTecknology> I'll check once I finish an update
<MTecknology> what does that change?
<rtg> MTecknology, make sure your clock is set to the current time (less your UTC offset).
<MTecknology> You mean set the clock to UTC?
<MTecknology> or the local time
<rtg> MTecknology, yep
<MTecknology> ok
<MTecknology> ntpdate won't update the bios clock, will it?
<MTecknology> 12 Oct 15:49:25 ntpdate[8258]: adjust time server 91.189.94.4 offset -0.018734 sec
<rtg> MTecknology, it won't if the clock is too far out of date
<MTecknology> I'll stop doing an update and try it
<SyL> is this a place I can ask for help on kernel panics on ubuntu 9.10? 
<MTecknology> rtg: it was spot on
<rtg> MTecknology, you mean your BIOS clack was correct?
<rtg> clock*
<MTecknology> ya
<rtg> MTecknology, hmm, I think Keybuk has been futzing about with some fsck type stuff.
<MTecknology> Keybuk: ...... -_-
<MTecknology> rtg: it's not because of the way I built it then?
<MTecknology> I built it the same way I learned how in gentoo
<rtg> MTecknology, does the original kernel do it?
<MTecknology> no
<rtg> what version is your original kernel?
<rtg> cat /proc/version
<MTecknology> 2.6.31-13-generic
<Keybuk> MTecknology: yes?
<MTecknology> Keybuk: rtg said it might be you breaking things
<Keybuk> MTecknology: what's up?
<MTecknology> rtg: Linux version 2.6.31-13-generic (buildd@yellow) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu7) ) #44-Ubuntu SMP Sat Oct 10 15:27:14 UTC 2009
<rtg> Keybuk, we've both noticed some issues with fsck failing to run on first boot is the bios clock is behind the file system
<Keybuk> failing to complete you mean?
<rtg> Keybuk, no, won't even start. drops me to a shell
<Keybuk> wah! unexpected inconsistency! sky is falling! etc.
<Keybuk> right
<rtg> known issue ?
<Keybuk> yes, it's your fault
<rtg> oh, I like that.
<Keybuk> :D
<Keybuk> tell me a bit about your setup?
<Keybuk> installing into virtualbox?
<rtg> no, bare metal.
<MTecknology> same here
<Keybuk> machine previously had Windows on it?
<MTecknology> this had windows on it until I got home 2yr ago
<rtg> no, it had Hardy. I was installing Karmic from scratch.
<Keybuk> rtg: what did it have before Hardy?
<rtg> dunno, I got it from Intel. its an SDP
<rtg> the clock was 2 years behind.
<Keybuk> what was the UTC setting on Hardy?
<Keybuk> and, most importantly, what did the clock in the top-right say while you were installing?
<Keybuk> two years?! :p
<Keybuk> behind isn't usually an issue
<rtg> Keybuk, I never noticed that it was so far behind until fsck wouldn't run.
<MTecknology> Keybuk: i bought the system, got home, installed ubuntu - it came w/ vista
<Keybuk> MTecknology: you wiped Vista?
<MTecknology> the timeon this system was less than 1/10 second off
<MTecknology> ya
<MTecknology> i don't like raping computers
<Keybuk> MTecknology: ok, so your bug is pretty simple
<Keybuk> when you installed Ubuntu, you didn't notice that the clock in the top-right was actually N hours fast
<Keybuk> (where N is the timezone offset between you and UTC)
<MTecknology> I installed from the alternate cd
<Keybuk> so you rebooted, and the "last mount" time of your filesystem was then in the future
<Keybuk> you connected to a network (hi!)
<MTecknology> my issue is....
<Keybuk> and that resync'd your clock back to reality
<Keybuk> and saved that time back into your hardware clock
<Keybuk> then next time you rebooted, fsck failed because the last mount time was in the future
<Keybuk> and dumped you to the world's least helpful shell
<Keybuk> if you ran fsck -y like it DID NOT SAY then everything was fine
<Keybuk> and now it won't happen again
<Keybuk> the reason this happened is because Windows had the hardware clock in "local time"
<Keybuk> but every other OS in the universe, including Ubuntu, puts UTC in the hardware clock
<Keybuk> because anything else is INSANE
<rtg> it would be helpful if ntpdate would correct for more then 3600 seconds (at least during install)
<Keybuk> since you wiped Vista, the clever bit of the installer that checks for Windows and adjusts the configuration to use local time didn't see it
<MTecknology> I pulled the kernel source, grabbed the config from /boot, compiled the kernel with that exact same config and installed using "make all modules_install install", When I tried to boot to the kernel I just compiled it hung on saying can not remove /forcefsck on read-only file system.
<Keybuk> rtg: I believe that ntpdate will correct any amount of jump
<MTecknology> I can't boot beyond that
<Keybuk> MTecknology: what else is on screen?
<MTecknology> i can't remember but I don't really know how to take a screenshot of that either.
<Keybuk> MTecknology: a camera phone is ideal ;)
<Keybuk> the forcefsck thing is an error caused by a previous error, the previous error is really important
<MTecknology> not that phone - won't be able to read it
<Keybuk> but I reckon you have the "I didn't make an initramfs for my custom kernel" bug
<MTecknology> oh
<rtg> fsck -y corrects the original problem?
<MTecknology> probably..
<Keybuk> rtg: I patched e2fsck today to always repair a future last mount/write/check time as long as it's no more than 24hr in the future 
<MTecknology> Keybuk: i didn't do that - so you're probably right..
<Keybuk> I'm sure Ted will ignore that as long as possible, but the RH e2fsck maintainer has already said they want that patch
<rtg> Keybuk, 24 hours being the normal Windoze correction factor?
<Keybuk> MTecknology: I already have a fix for that, can you install packages on that box?
<Keybuk> rtg: 24 hours being the most a clock can be out due to timezone error ;)
<MTecknology> i hope I can..
<rtg> Keybuk, right
<MTecknology> Keybuk: I only have one system
<Keybuk> MTecknology: and you're testing development releases on it? :)  Brave man
<Keybuk> even I don't do that <g>
<MTecknology> I learned gentoo on this thing over a weekend :P
<lifeless> Keybuk: 26 hours I think
<MTecknology> I ran 9.10 on this thing back around 9.05
<lifeless> Keybuk: there is some weird corner case overlap - the world is > 24 hours around :)
<Keybuk> lifeless: no, this is only relative to UTC remember
<Keybuk> so it's actually +/- 13.5 hours or something
<Keybuk> but 24 is easier to remember the number of seconds for <g>
<lifeless> Keybuk: right, -13 to +13 == 26 ;)
<MTecknology> Keybuk: so - how do I get that fix?
<MTecknology> 13?
<Keybuk> MTecknology: it will take the buildds a few minutes
<Keybuk> MTecknology: daylight savings in sheepland
<Keybuk> type thing
<MTecknology> i'm confused!
<MTecknology> oh
<MTecknology> i hate dst...
<lifeless> MTecknology: +12 + DST
<MTecknology> Is this part really needed? "apt-get build-dep linux-ubuntu-modules-$(uname -r)"
<lifeless> ah
<lifeless> tonga is +13
<MTecknology> most things in there shouldn't be needed to build the kernel..
<lifeless> without needing DST
 * rtg is outta here for the day
<lifeless> and the line islands at +14
<lifeless> http://en.wikipedia.org/wiki/Time_zone
<lifeless> -11 to +14 is the largest gap w/out DST considerations
<MTecknology> ah.. I see - that's the "ubuntu way" to compile the kernel
<MTecknology> Is there anything wrong with using linux-source?
<MTecknology> Keybuk: will I still need your patch for that?
<Keybuk> linux-source is the kernel source
<Keybuk> I think everyone builds from GIT though
<Keybuk> MTecknology: are you on i386 or amd64?
<MTecknology> amd64
<lifeless> linux-source is fine for rolling a custom kernel; if you're working on the kernel packages for ubuntu, you need the kernel package source
<MTecknology> so if I'm just going to roll out my own - then use git to get the kernel source - otherwise use the ubuntu kernel package?
<Keybuk> oh, it failed to build
<Keybuk> lifeless: that is the kernel package source ;)
<Keybuk> MTecknology: I may need a few more minutes at this ;)
<MTecknology> Keybuk: ok - can you explain the parts that matter to me?
<Keybuk> MTecknology: is the machine on a wired network interface?
<MTecknology> wireless
<Keybuk> can you plug it into a wire?
<Keybuk> if not, does your wireless use WPA?
<MTecknology> ya
<Keybuk> or can you boot the kernel that you didn't make?
<MTecknology> I'm in that
<Keybuk> ah great
<MTecknology> the kernel I made won't boot and I just wiped it
<MTecknology> I'm just trying to trim down the extra junk in the kernel that I don't need
<MTecknology> like XFS support - I don't need it and this laptop never will
<Keybuk> ahh
<Keybuk> you know that we don't build in XFS support, right? :)
<Darxus> Hah.
<MTecknology> it was in there..
<MTecknology> in the config in /boot
<MTecknology> CONFIG_XFS_FS=m
<Keybuk> that means it's a module
<MTecknology> build in as a module
<Darxus> MTecknology: There is something very important here you don't understand.
<MTecknology> I did say like though - there's a lot I'd like to knock out - I want to try to get a 10sec boot on this system
<MTecknology> Darxus: what's that?
<Darxus> MTecknology: Stuff built as a module that you don't use never gets loaded.  So changing it from a module to not being compiled at all gains you nothing (except compile time).,
<MTecknology> i get that
<MTecknology> when I'm looking at menuconfig again I can pick out some other things
<MTecknology> I'm not saying that I think the ubuntu kernel is wrong - I'm just a glutton for punishment - and breaking things is fun
<MTecknology> but when I use the exact same config to compile it and it breaks - I get confused
<Darxus> Ah, well, are you using the source package that builds the linux-image packages, or the linux-source package?
<MTecknology> linux-image
<Darxus> Hmm, weird.
<MTecknology> I'm pulling the git source now
<MTecknology> does that have a default .config in it?
<Darxus> MTecknology: Yes, in pieces.
<MTecknology> that last part makes me want to ask for additional information
<Darxus> cat debian.master/config/config.common.ubuntu debian.master/config/i386/config.common.i386 debian.master/config/i386/config.flavour.generic > .config
<Darxus> That'll get you an i386 generic .config.
<MTecknology> interesting..
<Darxus> You're likely to be able to extrapolate the other possibilites.
<MTecknology> you mean like debian.master/config/i386/config.common.i386.iwant.amd64.instead ??
<MTecknology> :P
<Darxus> Ha.
<Darxus> find . -name "*config*" will show you your options.
<MTecknology> Receiving objects:   2% (33347/1335407), 9.20 MiB | 59 KiB/s    
<MTecknology> this is going to take a while
<Darxus> Heh.
<Darxus> Have you run the thing to pick an optimal mirror?
<MTecknology> nope
<MTecknology> what's that?
<Darxus> I recommend it.
<Keybuk> I didn't think we have mirrors of our kernel source
<MTecknology> should I do this as a normal user and make a copy of the source to work on?
<Darxus> In one of the ubuntu gui package management things, theres a place where you can specify your mirror, and there's an option to select "other" or something, and then "select optimal mirror" and it pings them all or something.
<MTecknology> Darxus: I'm pulling from git though
<Darxus> Keybuk: Why wouldn't the kernel be included in the mirrors.... ohh, get, nevermind.
<MTecknology> my university just throttles to 60K
<Darxus> er, git
<Darxus> Ew.
<Keybuk> MTecknology: https://edge.launchpad.net/~ubuntu-boot/+archive/ppa/+build/1289150/+files/mountall_0.2.2~boot2_amd64.deb
<MTecknology> should I do this as a normal user and make a copy of the source to work on?
<Keybuk> if you install that, hopefully you could boot custom kernels ;)
<MTecknology> or will I be making my .config in the krepo
<MTecknology> Keybuk: how long until that makes it into karmic?
<MTecknology> and it's installed :)
<Keybuk> MTecknology: depends how long it takes me to watch the rest of FlashForward without interruptions
<Keybuk> and apply a couple more bug fixes after that <g>
<MTecknology> oh
<MTecknology> hm... sounds like it makes more sense to make a copy of the part of the git branch that I want instead of working inside it
<Womble2> Which package is the aufs2 source in?
<jjohansen> Womble2: its under the ubuntu dir in the kernel tree
<Womble2> OK
<otay> I want to connect two qemu quests via serial connection so I can do some debugging. Does anybody have any idea how to do this?
<MTecknology> Keybuk: do I want to do "git checkout Ubuntu-2.6.31-13.44" ?
<MTecknology> How long does it take you guys to compile the ubuntu stock kernel>
<mase_wk> MTecknology: that depends entirely on the machine you use to do it
<MTecknology> mase_wk: ya - I was just curious
<MTecknology> what kind of system do you have and how long does it take?
<MTecknology> I should use concurrency next time
<mase_wk> i have an AMD Athlon(tm) 64 Processor 3000+ , i usually compile under a clean VM environment though so it takes about 1/2 a day
<MTecknology> to compile the ubuntu kernel?
<mase_wk> well last time it was a kernel.org kernel
<MTecknology> Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz
<MTecknology> only seems to take a couple hours for me
<mase_wk> well i am doing mine on a VM too
<mase_wk> virtualbox at that so its not something speedy like xen
<mase_wk> if you want to speed up your time you can disable many of the modules that you don't need
<mase_wk> if you are never going to have a SAN then you can remove all of the drivers / files systems associated with that etc..
<MTecknology> that's part of the reason I'm doing this :P
<mase_wk> your compiling a kernel because you want to reduce your compile time ?
<mase_wk> =)
<MTecknology> no - because I want to trim it down
<MTecknology> loading the kernel is ~75% of my boot time
<mase_wk> i doubt that
<mase_wk> how big is your kernel ?
<MTecknology> default
<MTecknology> right now I have yet to actually compile a kernel that works
<MTecknology> in ubuntu anyway
<mase_wk> mine is 3.8mb
<mase_wk> if you have trouble loading 3.8mb at boot you have other issues
<MTecknology> 7.3Minitrd.img-2.6.31-13-generic
<mase_wk> thats not the kernel
<mase_wk> thats the initrd
<mase_wk> you don't have to remake the kernel to remake the initrd
<MTecknology> ** 3.8Mvmlinuz-2.6.31-13-generic
<mase_wk> you can just remove modules from the initrd
<MTecknology> how do I do that?
<mase_wk> mkinitrd
<mase_wk> you can specify which modules you want to include
<MTecknology> thanks
#ubuntu-kernel 2009-10-13
<MTecknology> compiling any kernel always seems to burn a hole in my leg
<MTecknology> there's something about compiling a kernel using the .config I got from gentoo that seems to make things not work
<MTecknology> In a way - I'm not surprised at all
<spstarr> erm, how come alsa snd-aloop is not found in kernel?
<spstarr> my sound card has no PCM/mixer capture support and needs aloop
<MTecknology> I was looking at CONFIG_SPI and saw "up to several tens of Mbit/sec.  Chips are addressed with a" I'm guessing that should be s/tens/tenths/
<MTecknology> Any ideas why this broke? http://pastebin.ubuntu.com/292024/
<hzhang__> ericm-Zzz, LOL , still not get up?
<hzhang__> hi, anybody familiar with IGMP protocol in kernel ipv4?
<ericm> hzhang__, naw actually is up
<hzhang__> is that a must option for common usage?
<hzhang__> ericm, yeah, got my email? i saved 6KB finally for remove OABI_COMPAT
<ericm> hzhang__, yes - you're a poor man - struggling for saving 6KB :-)
<ericm> hzhang__, so finally you are able to build a EABI kernel without OABI_COMPAT?
<hzhang__> ericm, oh, i just comments off those #error in kernel/time.c
<hzhang__> ericm, and seems kernel is ready for EABI
<ericm> hzhang__, seems your kernel is a hybrid one :)
<jk-> MTecknology: what source is this, and what .config have you used?
<MTecknology> jk-: I pulled the source from git and I took the default .config for my profile and started removing some stuff
<jk-> MTecknology: which git tree?
<jk-> "for your profile" ?
<MTecknology> git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git
<jk-> ok, cool
<MTecknology> to get the default .config I did this - cat debian.master/config/config.common.ubuntu debian.master/config/amd64/config.common.amd64 debian.master/config/amd64/config.flavour.generic > .config
<MTecknology> I compiled and it worked
<MTecknology> now I'm having troubles pin pointing where I screwed up
<jk-> ok, maybe diff your config against the original one that you got from 'cat ...' ?
<MTecknology> i'm scared to :P
<jk-> 'cat .... | diff -u - .config'
<MTecknology> I just did diff file1 file2
<MTecknology> http://pastebin.ubuntu.com/292029/
<ericm> anyone knows that ath9k broken after resume is a known issue?
<jk-> MTecknology: why such a difference?
<MTecknology> ericm: first googgle result - did you try rmmod ath9k, then modprobe ath9k ?
<MTecknology> jk-: I sat down and tweaked for about 2hr
<jk-> my first guess would be to disable CONFIG_DEBUG_KERNEL
<ericm> MTecknology, tried google - seems to be a known issue - but need confirmation (and unfortunately I don't have the hw, just looking into this issue reported by others)
<MTecknology> jk-: it is disabled
<jk-> or start from a clean .config, then change small things, and test between changes
<MTecknology> Symbol: DEBUG_KERNEL [=n]
<MTecknology> ouch
<MTecknology> there's no easier way to see where I screwed up?
<jk-> you could find out what's defining both 'debug' symbols
<MTecknology> How can I do that?
<MTecknology> I'm confused why there would be two things defining that symbol now but not earlier - I didn't add anything extra
<jk-> do you have ndiswrapper enabled?
<MTecknology> it's an option in the kernel that was * by default iirc
<MTecknology> CONFIG_NDISWRAPPER=m
<MTecknology> m* 
<jk-> (ndiswrapper seems to define a non-static 'debug' symbol)
<MTecknology> If I drop that - will I have issues running flashplugin-nonfree... I'm guessing so but it's worth a shot
<jk-> no, it's for windows wireless drivers
<MTecknology> oh - i was under the assumption that that plugin used it in some way
<jk-> nope
<MTecknology> I'll try it like that :)
<MTecknology> thanks
 * MTecknology crosses fingers
<MTecknology> I expect something to break - just like it to compile so I can get an error thrown at me that says something like "Hey moron; don't disable this!"
<MTecknology> jk-: where did you find that information?
<jk-> MTecknology: just looked for non-static debug vars
<hzhang__> ericm_, LOL, hybrid kernel ...
<MTecknology> jk-: that fixed it :)
<MTecknology> now to see if I can boot up with it
<MTecknology> I made the kernel get scared
<MTecknology> then it ran away
<MTecknology> Something about needing to find it's roots
<MTecknology> How can I pull up the error that it threw?
<Womble2> Sounds like you disabled the driver for your disk controller
<MTecknology> how can I see what driver I need for it?
<Womble2> 'lspci -v' will show you which driver is used for each device under the current kernel
<Womble2> though it's not always easy to work out how that's labelled in the configuration menus
<MTecknology> shiny :)
<MTecknology> I already see what you mean :P
<MTecknology> here it is http://pastebin.ubuntu.com/292050/
<MTecknology> this looks relevant - SATA controller
<Womble2> So you want ata_piix and ahci (not sure if you *need* both)
<MTecknology> thanks :)
<MTecknology> another 30min to recompile :P
<MTecknology> I think it takes about that long
<Womble2> Less than 5 minutes with a minimal config
<MTecknology> hm?
<Womble2> ...and more than one core
<MTecknology> I'm trying to trim the default config down as far as I can
<Womble2> Why?
<MTecknology> for fun mostly
<MTecknology> and for a really really fast boot time
<MTecknology> I'm considering dropping X and moving to framebuffer displays too...
<Womble2> You don't actually need to disable drivers for that, but building in the ones you do need can help
<MTecknology> that compile took ~3min
<Womble2> and then getting rid of initramfs (but not all distributions support that and I don't know whether Ubuntu does)
<MTecknology> ya - leaving them out seems to cause an infinitely long boot time
<Womble2> I mean, you build the drivers you need as built-in (=y) not modules (=m)
<MTecknology> I heard initramfs can speed it up a lot - if this works I was planning on trying it
<MTecknology> ya - I prefer built-in  but making everything built-in won't help either
<MTecknology> I'm going to try this out - brb
<Womble2> Personally I have no interest in doing that on production machines, but I do driver development and fast rebbooting is useful :-)
<MTecknology> unable to moutn root-fs on unknown-block
<MTecknology> same error as before 
<Womble2> Did you include the filesystem?
<MTecknology> that dang kernel is so scared of me it just wets it pants
<MTecknology> Ext4, ya
<MTecknology> Do I need to have Ext{2,3} even if I don't use them?
<Womble2> no
<MTecknology> The whole system is either Ext4, swap, or extended
<MTecknology> what do I need to get to an extended partition?
<Womble2> nothing special
<MTecknology> ok
<MTecknology> only /boot isn't on an extended partition
<MTecknology> Is there any way to get teh exact error that came up?
<Womble2> serial console / netconsole / camera
<MTecknology> I can try my camera phone..
<Womble2> you did specify root= on the kernel command line, right?
<MTecknology> I assume that was set - I'm only modifying the source
<MTecknology> http://imagebin.ca/img/x-JURGKX.jpg | http://imagebin.ca/img/dx09FZq.jpg
<MTecknology> the phone takes a cleaner image than I thought if I really try to stay steady
<MTecknology> you can see how glossy the screen is - w/ my reflection
<MTecknology> it has no idea what sda5 is...
<Womble2> Check that you have CONFIG_MSDOS_PARTITION=y
<Womble2> oh, I know, you're missing sd
<Womble2> SCSI disk support
<Womble2> SATA is much like SCSI at the protocol level so you have to enable that
<MTecknology> I just saw that
<MTecknology> the msdos part
<MTecknology> which options should I enable for scsi?
<MTecknology> I searched for scsi and that's right around massive
<MTecknology> SCSI_DH?
<Womble2> CONFIG_BLK_DEV_SD
<MTecknology> I'll try that out :)
<MTecknology> I wonder how long this build is going to take
<MTecknology> Womble2: thanks for the help :)
<MTecknology> hopefully this just works nice and perfect and I'll be smart enough to do only a few things at a time and build-in things I know I'll need
<MTecknology> Womble2: sorry, I had to run off
<MTecknology> That part is working - now I need to figure out what I need for ecryptfs and another very minor error
<MTecknology> Womble2: thanks again for all the help :D
<MTecknology> thanks to everyone else too :)
<MTecknology> I guess I was wrong with what I thought I needed - but I can't imagine making ecryptfs work should be too hard to find
<panda|phenom> ericm_, well, finally, fixed SLOB for my nommu board
<ericm_> panda|phenom, you are genius bro - what's the prob?
<panda|phenom> ericm_, only 2.5MB to run kernel, busybox, stream server and web server
<panda|phenom> ericm_, no, i'm poor, compound_order must be run on the head.
<panda|phenom> ericm_, so use virt_to_head_page(objp) instead of virt_to_page(objp)
<panda|phenom> ericm_, anyway, uclinux is amazing ... LOL
<ericm_> panda|phenom, you must have fun then :-)
<panda|phenom> ericm_, ah, well, i'm still a newbie and there are so many code i can't understood ... long way to go ...
<ericm_> panda|phenom, hey you are a panda - so don't worry about that
<cankoy> is this patch included in karmic? http://bugzilla.kernel.org/show_bug.cgi?id=13121
<ubot3`> bugzilla.kernel.org bug 13121 in BIOS "Buggy _BCM - acer aspire 5720G, 5710Z, 5315" [High,Closed: code_fix] 
<csurbhi>  cankoy, yes! I can see it in karmic
<cankoy> csurbhi: does it also cover 5715Z? I asked a number of times there, but it's ignored so far.
<csurbhi> let me check, i am just making a patch and verifying that
<csurbhi> cankoy, reading the comments there, i think the patch should work for 5715Z
<cankoy> csurbhi: as of 2.6.31.4, I still don't see http://bugzilla.kernel.org/attachment.cgi?id=21801. 
<csurbhi> if you get the latest karmic 
<csurbhi> release
<csurbhi> i mean the source code and do a git log drivers/acpi/video.c\
<csurbhi> thats the first commit that will pop
<cankoy> ok, thanks
<csurbhi>  cankoy, you seem to be right 
<csurbhi> |the patch for 57151Z is not yet in
<csurbhi> have u filed a bug in launchpad ?
<cankoy> no, should I? 
<cankoy> if that's the only way to get noticed, then I can..
<csurbhi> yes, please do. I will apply it if a bug is filed
<csurbhi> :)
<csurbhi> cankoy, also can u ask in bugzilla about the merge of this patch upstream ?
<cankoy> csurbhi: https://bugs.launchpad.net/ubuntu/+source/linux-ports-meta/+bug/450288
<ubot3`> Malone bug 450288 in linux-ports-meta "fix for Acer Aspire 5715z brightness keys missing" [Undecided,New] 
<rtg> apw, smb: what do you guys think about the bluetooth connection patches?
<apw> rtg, hard to tell how vast they are from his email
<rtg> apw, isn't your block elevator patch suitable for stable?
<smb> rtg, Would need to look at the actual patches, but might be reasonable
<apw> ok the first two are small and obvious
<smb> rtg, elevator one, I think yes
<apw> the last needs more reading but it seems to be trying to reference count the devices ... 
<apw> my only worry is they are pretty late, and i don't have any bluetooth devices to test with
<apw> rtg on the readahead, yes, it need submitting upstream and cc: stable, on my list for today
<rtg> apw, do you want to change our commit log (e.g., add Cc: stable...) ?
<apw> heh, i could but normally i'd rebase it to mainline before sending and would add it then
<rtg> apw, ok
<apw> those bluetooth things seem to have hit real mainline too
<smb> rtg, the 3rd one is a bit misty but it is upstream ...
<smb> the other two look ok
<rtg> apw, they are all cherry picks and apply cleanly, which is why I asked him to send them upstream for stable.
<apw> yeah ... i guess normally i'd say wait for that, but freeze throws spanners in that
<rtg> apw, well, if they _do_ come via stable, then smb can deal with them in a couple of weeks
<apw> :))
<smb> :-P
<MTecknology> rtg: this is getting fun :)
<rtg> Brian did point out that they are not regression fixes, but rather improvements.
<apw> if i had some h/w to test with i might say shove them in now
<apw> not having a clue if they work after is a concern
<apw> i think my radio keyboard is exactly that some bespoke keyboard wireless thingy
<smb> From the policy point of view they fix a problem, though not an oops or hang and they are not enablement really, so....
<rtg> smb, which is why I've been considering them.
 * apw asks on X if they have anything they can test with
<rtg> apw, I think Marcel must already be headed to KS since he's not on the wireless channel
<smb> Rather keep things working after cycles of unplug / plug... We could say its "only" affecting bluetooth, so it could not get worse
<smb> Though my headset did work remarkably well with karmic
<apw> heheh ... bluetooth bashing
<rtg> apw, you and smb are gonna have to give me a lesson in block devices in NC. wtf is failfast?
<smb> rtg, telling the scsi layer to not bother with error recovery
<apw> rtg thats the thing where a multi-path device can say 'don't retry here, retry higher in the stack'
<smb> too much
<rtg> ah, ok. thats makes a bit of sense in a SAS env
<csurbhi> :q
<apw> anyone know what the ima layer is?
<apw> ima_path_check ?
<apw> Integrity Measurement Architecture
<apw> rtg what was your feeling on that barrier thing for vios?
<rtg> vios?
<apw> the null write barrier log spam thing
<apw> virtual io service thing
<rtg> apw, is that in stable? clearly I have not encountered it yet.
<apw> no it was the one i pushed to our list, for server
<rtg> apw, I am totally confused 'cause I have no idea what you're talking about.
<apw> the patch you punted on :) 
<smoser> rtg, ping
<rtg> apw, I _intended_ to include it. I take it I missed it along the way?
 * apw thought so, but i may have missed you not missing it
<rtg> apw, what is the log message?
<apw> block: silently error unsupported
<apw>         empty barriers too
<rtg> apw, hmm, its in the list archive. guess I missed it.
<apw> rtg is the next upload going to be a bumper?
<rtg> apw, dunno yet
<smb> rtg, Are the sec fixes in?
<rtg> smb, the 2 CVE's ?
<smb> yup 
<smb> (which one of them would be a bumber)
<rtg> as of Ubuntu-2.6.31-13.45
<apw> don't see them in .45
<rtg> appletalk: Fix skb leak when ipddp interface is not loaded, CVE-2009-2903
<rtg> sgi-gru: Fix kernel stack buffer overrun, CVE-2009-2584
<rtg> those 2, right?
<rtg> actually, they went into Ubuntu-2.6.31-13.44
<MTecknology> If I do "git checkout Ubuntu-2.6.31-13.45" where is that?
<smb> sounds about  right
<MTecknology> Or is that checked out right into the root git directory? I've never used git
<apw> rtg, ahh it was a bumper, but it wasn't a bump
<apw> MTecknology, it cheecks out that tag into your working directory
<rtg> apw, it was a bullshit bumper, so I ignored it
<apw> yeah i can see that, makes sense, didn't realise we could do that :)
<apw> as in we had any mechanism for it
<rtg> apw, do you have the patch for bug #420423 in a repo somewhere that I can fetch?
<ubot3`> Malone bug 420423 in linux "Running karmic as virtual machine with virtio hard disk outputs I/O errors" [High,In progress] https://launchpad.net/bugs/420423
<apw> rtg sure
<MTecknology> apw: Thanks, I was confused because it builds as "2.6.31.3" instead of something like "2.6.31-12"
<apw> MTecknology, that depends on how you do the build.  a make makes .3 as thats the 'base'.  a debuild makes -12 .debs
<MTecknology> apw: and they're the exact same thing after I install it except for naming?
<smb> MTecknology, Likely not, for probably different configs
<apw> depends on where you get your .config i'd say, but otherwise ...
<MTecknology> I'm making my own
<rtg> apw, can you take care of the EC2 meta package while I sort out this next kernel upload. see the k-t list for my response to smoser
<smb> MTecknology, Then it is cleanly not the same. :)
<apw> rtg ack
<rtg> I clearly need coffee. biab
<smoser> thanks apw, rtg
<MTecknology> smb: I meant the differenve between how I build them, not versus getting it from the main branch. My config.1 is the same as the main branch, config.{2,3,4,5} are different. (Keeping checkpoints for nice builds as I go)
<smb> MTecknology, The tree is then the same as from which -13.45 was build
<MTecknology> thanks
<smb> git log should be at the last commit which is checking in the release with that message
<apw> the git tree is our master source repository, all uploads are built from there
<MTecknology> git feels almost like a smart version of cvs..
 * apw laughs
<MTecknology> that's only after ~30min working with it - but that's my first impression
<apw> rtg:   git://kernel.ubuntu.com/apw/ubuntu-karmic lp420423
<Keybuk> apw: I'm beginning to believe that this laptop's problem could be overheating related
<MTecknology> Keybuk: that burns.. I've had that issue a few times (thankfully on my system only once)
<MTecknology> Not sure if you guys care and probably not at all for another 3 days but I'm finding this interesting - http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html
<apw> rtg, ok we have sent you some email on the .4 update
<lamont> soren: around?
<rtg> apw, pulled lp420423
<apw> rtg ack
<apw> rtg smoser linux-meta-ec2 uploaded
<smoser> thanks.
<lamont> smb: any word on bug 445456?
<ubot3`> Malone bug 445456 in linux "kvm hangs booting windows XP Pro SP2 or later, since at least 2.6.28-15" [High,New] https://launchpad.net/bugs/445456
<lamont> I guess I should add the requested info....
<smb> lamont, other than me asking for that info. no. To be honest even with it there I had not much time for any bugs
<lamont> figures
<rtg> apw, pushed master with all of the stable updates. still doing build and smoke testing.
<apw> rtg cool
<rtg> apw, note the top commit, CONFIG_X86_MCE=y
<lamont> interesting... the 2.6.28-11 kernel with karmic user space decides that I don't get my thumbpad
<apw> heh nice, who needed that
<rtg> apw, I'm looking at what armel.mk produces. in the master rules, shouldn't linux-headers, linux-doc, and linux-source be specifically excluded for armel ?
<apw> i believe that is ok, note they are _all
<apw> talking to maxb etc it seems that i386 runs debuild -b, but all other arches do debuild -B
<apw> which only makes the one file
<rtg> apw, huh, lemme try that
<rtg> apw, damn, works likes a charm
<apw> yeah i was supprised too.  i fixed the .mk then made it herre and had those _all's and asked on #u-d and they said that that was basically how its meant to work
<apw> all really does mean all, just we then say 'don't do all' for all other arches
<rtg> apw, perhaps I should be changing my makefiles to reflect that, i.e., use -b for i386 and -B for all others.
<apw> yeah maybe, its a lot quicker for arm for one
<apw> rtg i now have some good testing on a usb hack for those Huawei E169 USB dongles which broke in 2.6.32.2 ... the fix is a hack from benh, and i think we'll get a proper fix later ...
<apw> but ... its those G3 sticks ... which are quite popular
<apw> so to consider it, or wait for the real thing for the first SRU
<rtg> apw, k-t list yet?
<apw> no just got the feedback, and wondering if its sane to take the hack
<rtg> is it device specific?
<apw> http://launchpadlibrarian.net/33442788/patch0
<apw> thats the hack ...
<apw> its pretty generic ... i am leaning to waiting
<smb> Would me my feeling too
<rtg> oh, that is a gross hack, isn't it :)
<slacker_nl> hello, can anyone help me? i got a mail regarding bug 446110
<ubot3`> Malone bug 446110 in linux "-12 kernel causes boot to halt at initramfs shell / boot hangs with "waiting for root file system"  " [Undecided,New] https://launchpad.net/bugs/446110
<apw> rtg its pretty scarey ... i think waiting is the order of the day
<apw> slacker_nl, what was the email about?
<slacker_nl> the janitor came by and talks about linux-meta and linux packages, reported the bug via apport, so I would assume the correct package was selected from the get-go
<CarlFK> smb:  bug 254668   - any point in digging into this more, or should it be closed as fixed?
<ubot3`> Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] https://launchpad.net/bugs/254668
<apw> slacker_nl, yeah apport has a tendancy to chose linux-meta when you use linux-image-generic as the package to report against
<slacker_nl> apw: that is what happend
<slacker_nl> apw: can ignore the message ?
<apw> slacker_nl, so if your bug was a realy bug, something kernel not working-y then the janitor did the right thing
<apw> slacker_nl, sure can, we'll find the bug now its in the right place
<slacker_nl> apw: k, cool
<smb> CarlFK, It might be interesting to see your full dmesg in there. It would be interesting to see whether that kernel argument would have helped with the older kernels (not sure you are keen on trying to go backwards, though)
<CarlFK> smb: box isn't in use right now, so I can try a few things
<CarlFK> ill post dmesg
<smb> CarlFK, Cool, thanks. I would at least have a work-around documented for older kernels if we close this as fixed now
<Keybuk> apw: so I changed my governor to powersave
<Keybuk> and so far this machine hasn't hung
<Keybuk> and it's fan is nowhere near the 747 levels it was at yesterday
<apw> heheh.  sounds a bit dodgy
<Keybuk> yeah
<Keybuk> it's a Dell XPS 1330M
<Keybuk> we don't support those, right? <g>
<Keybuk> M1330 even
<apw> manjo, pgraner, either of you having trouble with your M1330's ?
<manjo> nope
<pgraner> apw: I haven't run Karmic on it since my wife appropriated it
<apw> ah yess ...
<apw> manjo, so you don't get any overheating issues?
<manjo> apw, upgraded this morning ... have not noticed it 
<manjo> apw I mostly run on battery... is the over heating while charging ? 
<Keybuk> basically for me, after a few hours usage, the machine crawls to a slow snails pace
<bjf-afk> **
<bjf-afk> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf-afk> **
<rtg> I've been running an XPS1330 with no heat issues
<Keybuk> it needs a physical power off to be well again
<Keybuk> overheating is just a theory
<manjo> apw, ordered a dell 10V a week ago... but won't get it before the sprint, dell takes 2 weeks to ship
<apw> manjo, doh
<apw> manjo, so ... keep an eye out for going as slow as snot
<manjo> apw, with ssd this time 
<rtg> Keybuk, the next kernel will have MCE enabled, maybe you'll get some more error info.
<manjo> apw, so we have a machine to test ssd issues now 
<manjo> apw, machines + 1 May be 
<apw> the 10v ? 
<manjo> yes
<Keybuk> rtg: *nods*
<Keybuk> that's interesting
<Keybuk> I unplugged it from the mains as manjo hinted
<Keybuk> and the temperature has already dropped 10 C
<Keybuk> and the fan just throttled down
<rtg> ooh, ACPI
<manjo> Keybuk, I recharge when I am suspended ... 
<manjo> Keybuk, I have a HUGE battery 
<manjo> Keybuk, just plugged mine in ... will see the change
<apw> Keybuk, i wonder if you battery could be sickening
<manjo> Keybuk, what are you using to check temp? 
<Keybuk> apw: don't think so, it's holding a reasonable charge
<Keybuk> apw: >90% of design capacity
<Keybuk> this laptop has mostly been on a shelf until my other one failed
<manjo> Keybuk, don't hear the fan yet .... speed is normal
<Keybuk> manjo: cat /proc/acpi/thermal_zone/THM/temperature
<apw> Keybuk, hmmm sounds ok
<Keybuk> apw: the only thing it was used for was itunes and lightroom under windows
<manjo> Keybuk, temperature:             44 C
<Keybuk> I took the drive out, put an SSD in, and have been using this as a backup
<Keybuk> manjo: I'm down to 48 C now
<Keybuk> this is the nvidia model, so it might run hotter than yours if yours is the intel model? :P
<manjo> Keybuk, 44C with power plugged in 
<Keybuk> it was 65 C at the point it went really slow
<manjo> Keybuk, yes intel on mine 
<Keybuk> again, heat is just a guess here :p
<Keybuk> though it's kinda interesting that I can actually touch the bottom of the laptop now
<Keybuk> and all I've done is unplug the power
<manjo> Keybuk, 44C and holding
<Keybuk> it's holding at 48 C here, but hasn't quite finished the apt-get upgrade run
 * amitk grumbles at a new pop-up dialog telling me my battery is discharging when I pull the power on the laptop
<Keybuk> upgrade finished, and the fan just went even quieter
<apw> Keybuk, and if you put the ac back?
<Keybuk> apw: just giving it a few more minutes, then will see
<Keybuk> power back in now\
<Keybuk> (temp has climbed to 51 C so far)
<apw> mad
<manjo> Keybuk, mine has gone up by 1C
<manjo> my temp just dropped to 40C
<manjo> mad
<Keybuk> 52 C now
<Keybuk> if anything I'm doing less on it right now than I was when it was in its 40s
<Keybuk> I'm not upgrading openoffice for a start!
<apw> my laptop sits at 49c right now
<apw> on power
 * apw pulls the plug
<smb> my netbook on 61
<smb> (though I am running a hell lot of stuff (including looking at apw)
<apw> mine is staying around 49/50 with or without power (dell)
<apw> rtg is that a wrap on 14.46 ?  a
<apw> and was the bump generic
<rtg> apw, a bit of both. X86_MCE was the actual bumper, but I also wanted some version seperation.
<rtg> apw, henceforth, only OMFG kitten killers will require another upload.
<apw> so i shouldn't need to bump arm as i rebase them?  or would you recommend a separation there too?
<rtg> apw, wouldn't hurt
<amitk> apw: can we sneak in a last-minute patch + upload for imx51? brad just got a patch from FSL that fixes two important bugs
<amitk> verifying currently...
<apw> rtg ack
<apw> amitk, i'll get back to you before i tie the ribbon then
<bjf-afk> apw, I've also got a config bug that I need to fix for dove
<apw> bjf-afk, is dove in the can ?
<apw> ok ... get it out to the list asap pls
<rtg> apw, bumping the ABI for ARM isn't nearly as important.
<apw> rtg yeah, just aa annoyance more than anything
<apw> but i like the idea of a nice shiney new kernel
<apw> we should probabally bump for the first one after release to maintain the old kernel too
<rtg> apw, thats typically what I do, just to separate it from -proposed v.vs release
<Darxus> Does the kernel currently have a year 2038 bug?
<apw> Darxus, very likely ...
<apw> luckily we have a few years to get it sorted
<Darxus> So I should open a bug for it?
<rtg> somebody just shoot me if I'm still doing this job in 2038
<apw> i would think thats an upstream issue, but is anyone going to care for a while
 * apw racks a round
<Darxus> Now seems like a better time to fix it than later.
<manjo> apw, new 31-13 causing problems for me on nvida HP proliant ... don't see any splash or gnome just blank screen
<apw> does nvidia work on -13 ?
<apw> is that binary drivers or oss ones?
<manjo> apw, it did a dkms install of the modules ... 
<apw> fu
<apw> fun
<manjo> let me try older kernel .... again .. 
<manjo> apw, -12 is ok 
<apw> manjo, fun ... so what changed
<apw> is there a dkms log to see if the driver was happy
<manjo> will look after the meeting 
<Keybuk> (up to 55 C now :p)
<apw> Keybuk, very strange
<Keybuk> apw: it's been climing since the battery became fully charged
<apw> very odd
<Keybuk> nothing interesting in dmesg
<Keybuk> (not that I'm expecting MUAHAHAHA! BURN!!! in there)
<rtg> jjohansen, X86_MCE doesn't seem like a good idea for EC2, agreed?
<jjohansen> rtg: agreed
<MTecknology> How can I know if it's safe for me to disable CONFIG_X86_RESERVE_LOW_64K?
<rtg> jjohansen, Uploaded linux-ec2_2.6.31-302.7 if you wanna build your own.
<Darxus> I added a couple options to the varies fragments of the .config, but it still wants me to run make oldconfig.
<Darxus> I can't see what's different from the make oldconfig output from my version of the config.
<Darxus> Any idea what I'm missing?
<Michalxo> hello! I got directed here from ubutnu-bugs.. this is my bug... https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/429249
<ubot3`> Malone bug 429249 in gnome-power-manager "[Karmic] keyboard locked/freezed unable to type anything" [Undecided,New] 
<Michalxo> any fixes around? :-/
<jjohansen> rtg: thanks
<zongo1> Hi! I have a question about karmic's initrd and my dvb-t stick. It seems that the firmware is not included in the initrd which makes my computer pausing for a minute when resuming. Is this a known problem?
<MTecknology> What's the difference between Ubuntu-2.6.31-14.46 and Ubuntu-2.6.31-302.7 ?
<manjo> jjohansen, around ? 
<jjohansen> yeah
<TheMuso> /c
#ubuntu-kernel 2009-10-14
<Darxus> Wow, new upstream merged two days before kernel freeze.
<MTecknology> What's the difference between Ubuntu-2.6.31-14.46 and Ubuntu-2.6.31-302.7 ?
<MTecknology> obviously the numbers - I'm just curious what the really high numbers are used for
<billybigrigger> does anyone here maintain submit fixes to upstream for the gspca v4l2 modules?
<billybigrigger> maintain/submit
<billybigrigger> rather :P
<MTecknology> I tried to build a package and when I did "make install" I got this error. I'm wondering what's missing in the kernel to make it work. "include/linux/autoconf.h or include/config/auto.conf are missing."
<billybigrigger> just wondering how i go about getting my webcam to work, it hasn't worked throughout the whole 2.6.31 kernel development, and i was hoping by now that it might have been fixed
<billybigrigger> do those files exist in your kernel source directory?
<MTecknology> me?
<MTecknology> ya
<MTecknology> they do
<MTecknology> billybigrigger: do you know ho to find out what option compiles the files?
<billybigrigger> no
<billybigrigger> haven't done any compiling for months
<MTecknology> I'm shooting for a 2.5MB kernel
<billybigrigger> since A2 :P
<billybigrigger> oh
<billybigrigger> hehe
<MTecknology> 12min to dload vbox - hurray crappy internet
<Darxus> I got the kernel source package to build and boot patched with both the bfs cpu scheduler and the bfq i/o scheduler.
<xteejx> hi guys, member of bug control here, there is a bug 425756 in the Ubuntu kernel which affects the SB6/700 sata controller with an ata soft lockup, there seems to be a patch at http://kerneltrap.org/mailarchive/git-commits-head/2008/6/14/2122314 does this look any good, and is there any chance we can get it in? :)
<ubot3`> Malone bug 425756 in linux "[Karmic] cd/dvd drive not detected ." [Undecided,New] https://launchpad.net/bugs/425756
<L_X_> hi there! I have a little trouble installing the backports-modules
<xteejx> !ubuntu
<ubot3`> Ubuntu is a complete Linux-based operating system, freely available with both community and professional support. It is developed by a large community and we invite you to participate too! - Also see http://www.ubuntu.com
<xteejx> oops
<xteejx> L_X_, the place for help and asking questions is #ubuntu this is the kernel teams IRC chatroom :)
<L_X_> only in launchpad (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/445931) it says to ask the question here... maybe you should clarify...
<ubot3`> Malone bug 445931 in linux "linux-backports-modules-karmic not installable, dependency problem" [Undecided,New] 
 * L_X_ is heading to 
 * L_X_ is heading to #ubuntu
<L_X_> cya
<xteejx> Kernel Team: Sorry to be a pain, but I'd appreciate if you could look at that patch if/when you're not busy bug 425756 with patch :)
<ubot3`> Malone bug 425756 in linux "[Karmic] cd/dvd drive not detected ." [Undecided,New] https://launchpad.net/bugs/425756
<xteejx> and thank you
<csurbhi> In hotplugging, a bus probe occurs after which a matching driver probes a device. The driver is chosen based on the device id and the vendor id.
<csurbhi> Is this understanding right ?
<csurbhi>  Or does a bus driver probe for every device (without looking at the device id) ?
<smb> csurbhi, It is add devid,vendorid based. When a new device appears it will register to a bus and each driver already registered with that bus will get its probe function called with the device id until one driver claims it or no more drivers are present. As there s an add event for the device udev can match that id of the device with alias strings of drivers and load one if one is found which is not already present. New drivers registering ag
<smb> ain get their probe function called with every device on the bus, which is not yet claimed.
<csurbhi> ok
<csurbhi> but is not  /lib/modules/modules.alias looked at to modprobe a particular driver?
<smb> right, that file is generated from the information in the modules when you run depmod
<csurbhi> i thought that the bus looks at the vendor id and the product id and then looks at the modules.alias and then appropriately that driver module gets inserted
<smb> the bus (from the kernel) does nothing here. It is udev that loads modules
<smb> if you insert a device, this jsut generates an add event and causes currently loaded drivers to be called
<csurbhi> but what happens if a driver (compiled as a module) for a device is not yet loaded
<smb> if you do a modinfo on a driver you will notice alias strings, these are used to make the modules.alias file and that is used by udev to match an add event on a bus with a driver
<csurbhi> right..so who generates the event on the bus
<Keybuk> what bus?
<csurbhi> because that event should have the device id and the vendor id
<csurbhi> when you add a device an event is generated. on a bus ? so who generates that ?
<smb> I would call it the bus subsystem (not sure this is the correct term)
<Keybuk> when new devices are detected, the subsystem driver creates stub kernel objects for them
<csurbhi> yes.. thats why i said that the bus might look at the device id and the vendor id
<csurbhi> ok.. but i get it
<csurbhi> ..
<Keybuk> the properties of those kernel objects include things like their port id, and any bus-specific information like vendor id, device id, etc.
<Keybuk> driver core creates entries in the /sys filesystem for these
<Keybuk> and it sends a message on a special netlink socket announcing the new device
<Keybuk> it then *also* runs its internal match table against built-in and already loaded modules
<csurbhi> yes.. and then udev gets this message looks at the module.alias and modprobes the device driver
<csurbhi> :)
<Keybuk> and those modules may claim the device (in which case they take over the kernel object and begin added more details, like interfaces and device nodes)
<Keybuk> udev receives this message
<Keybuk> inside this message is a "modalias" string
<Keybuk> this is a single string made up of the important kernel object information
<Keybuk> the format of the string is generally <subsystem>:<info>
<Keybuk> so for example, a PCI subsystem modalias would look like
<Keybuk> pci:v00001180d00000843sv00001028sd00000209bc08sc80i00
<Keybuk> while a USB subsystem modalias looks like
<Keybuk> usb:v413Cp8126d0367dcE0dsc01dp01icE0isc01ip01
<Keybuk> as you can probably tell, inside that is the vendor id, device id, etc.
<Keybuk> modules themselves have match tables which are used in the kernel to match against a module
<Keybuk> from these wildcard modalias strings are generated
<csurbhi> ok
<Keybuk> these have the "any of these" bits of the string replaced by *
<Keybuk> and you can see these by running modinfo on a module
<Keybuk> # modinfo ricoh_mmc | grep alias
<Keybuk> alias:          pci:v00001180d00000843sv*sd*bc*sc*i*
<csurbhi> two questions 1) at boot time, how is a bus driver claimed ?
<Keybuk> so whenever it receives a netlink message with a modalias in it, udev calls "modprobe $MODALIAS"
<Keybuk> modprobe matches the string against the known module names, and known module aliases
<Keybuk> using wildcard matching
<Keybuk> and thus you end up with a particular driver loaded
<Keybuk> as this driver loads, its _init() function will bind it in-kernel to any kobjects
<Keybuk> and since it's loaded, any new devices it claims will be bound in-kernel too
<Keybuk> that's it ;)
<Keybuk> csurbhi: I have answered that question above
<csurbhi> so by this logic a driver should be invoked only when a device id is registered in it
<Keybuk> yes
<csurbhi> if a device id is not registered it should not be called
<Keybuk> I don't know what you mean by "called"
<csurbhi> called = invoked
<Keybuk> a driver is not bound to a device that it hasn't claimed
<Keybuk> I don't know what you mean by "invoked"
<Keybuk> drivers aren't called or invoked, they claim devices
<Keybuk> the devices become bound to the driver
<csurbhi> but a modalias of a driver will have a device id and a vendor id
<Keybuk> csurbhi: not necessarily
<Keybuk> it's quite valid to have a modalias wildcard match that matches all devices
<Keybuk> pci:*
<Keybuk> that would be a driver that can claim any pci device
<Keybuk> (for example)
<csurbhi> ok
<Keybuk> that'd be bad though, only one driver can claim any one device
<Keybuk> there are drivers that match entire device class or interface classes though
<csurbhi> but then what is the point of this:
<Keybuk> usb-storage for example
<Keybuk> alias:          usb:v*p*d*dc*dsc*dp*ic08isc06ip50*
<csurbhi> less 2.6.28-15-generic/modules.alias | grep sdhci
<csurbhi> alias pci:v*d*sv*sd*bc08sc05i* sdhci_pci
<csurbhi> yes.. exactly
<Keybuk> csurbhi: exactly my point
<csurbhi> have a v*d* ?
<csurbhi> why have that ?
<Keybuk> any vendor's device, that has a PCI base class of 08 and subclass of 05
<csurbhi> could there be a clash ? when another driver for eg: says bc*sc*
<csurbhi> and one driver says v*d*
<Keybuk> had to look that up
<Keybuk> and some eejit has moved pci.ids
<Keybuk> PCI class 08 is "Generic system peripheral"
<Keybuk> subclass 05 is "SD Host controller"
<csurbhi> hmmm...thanks a lot :)
<Keybuk> so you have a case there where there is a generic kernel driver for that entire device class
<csurbhi> that helped me a lot.. :) 
<Keybuk> that's actually a Linux tendancy
<csurbhi> now i get it
<Keybuk> if you can do away with a driver-per-device and instead have generic drivers that deal with the special cases through quirks, that's a big WIN!
<Keybuk> yes, you're quite right that if you added another driver that matched the same device (e.g. by vendor/device id) they would clash
<Keybuk> both would be able to claim the device
<Keybuk> in which case there are rules about which one wins
<Keybuk> (look at the modules.order file :p)
<csurbhi> i can see a sdhci-pci driver getting called and failing and then another driver getting called.. and i was wondering why the sdhci-pci was getting called.. i can now see why !
<Keybuk> a driver is quite permitted to decline a device
<Keybuk> "oh, I don't know about *this* one"
<csurbhi> ok
<Keybuk> in which case, the next driver in line can have a go
<csurbhi> yess
<csurbhi> now i get it :) thanks a lot !!
<csurbhi> one more question
<csurbhi> i also read somewhere
<Keybuk> the Windows developers hate this
<csurbhi> that hotplugging could be scpi intermediated
<csurbhi> :)
<Keybuk> gregkh gave a wonderful presentation at a devcon about Linux driver core
<Keybuk> and the windows people were sitting with dropped jaws
<csurbhi> :D
<Keybuk> they have nothing as simple and elegant as this ;)
<csurbhi> :)
<csurbhi> boy !!! thanks a lot!!!!
<Keybuk> csurbhi: I'm not sure how scpi applies in this question?
<Keybuk> did you mean acpi?
<csurbhi> i not get the whole thing !! i took a great deal of time looking at why ricoh_mmc was getting called after a sdhci-pci driver
<csurbhi> now i get it completely !!! wow !
<csurbhi> yes.. i meant acpi
<Keybuk> oh wow that was a totally freaky guess
<Keybuk> I picked ricoh_mmc simply because it was the last thing with a pci modalias in my udev log ;)
<csurbhi> heehee
<Keybuk> right
<Keybuk> ACPI is a whole world of pain
<csurbhi> so can u pleaee tell me how this thing works
<csurbhi> when acpi mediates ?
<Keybuk> everything I am about to say is a lie
<csurbhi> i believe u
<csurbhi> :P
<Keybuk> but it's a lie that explains how things work
<Keybuk> ACPI is a system that allows your computer to have software that is executed by the kernel
<Keybuk> when the kernel needs to do something (e.g. enumerate the PCI bus), it actually runs this special software
<Keybuk> this special software is run on a virtual machine that Linux implements
<Keybuk> and produces the results the kernel expects
<Keybuk> this can also deal with interrupt handlers, and so forth
<Keybuk> the side-effects of running this software ideally include programming chips on the board to do the right things
<Keybuk> that way the kernel doesn't need to know how to program the MMC
<Keybuk> or PCI controller
<Keybuk> the motherboard can know that
<csurbhi> so cool
<Keybuk> but the motherboard doesn't need an operating system on it
<Keybuk> so the kernel executes code on the motherboard's behalf
<Keybuk> so on boot, the kernel will begin executing the acpi code
<Keybuk> this will result in the hardware being programmed correctly
<Keybuk> linux arranges (through standard acpi methods) for pci hotplugging to be enabled
<Keybuk> this may require, for example, that when a card is hotplugged that further acpi methods are invoked to communicate with the pci controller and find out what happens
<Keybuk> but this results in Linux's registers being updated
<Keybuk> so it can know what cards were added/removed
<Keybuk> and can arrange for the new card to be initialised
<Keybuk> or resources of the old card to be freed
<Keybuk> etc.
<csurbhi> ok
<csurbhi> so when its not acpi mediated, the pci subsystem gets the interrupt when a device is added
<csurbhi> whereas when it is acpi initiated, acpi gets the interrupt
<Keybuk> no, it's still all done with interrupts the old fashioned way
<Keybuk> the difference is that when not using acpi, Linux has to do the leg work to talk to the pci controller
<Keybuk> and has to know every detail about your pci controller
<Keybuk> whereas with acpi, that is somewhat abstracted
<csurbhi> ok
<csurbhi> and one last question
<csurbhi> the modules.order
<csurbhi> who creates that and based on what ? 
<Keybuk> the kernel build system creates that
<Keybuk> based on the order that modules are listed in its Makefiles
<csurbhi> ok
<csurbhi> :)
<Keybuk> this is the same order that the code would be statically linked into the kernel if they were all built-in
<csurbhi> ok
<csurbhi> thanks a lottt
<csurbhi> that was veryy insightful
<joaopinto> hello, is the generic kernel built with PAE enabled ?
<joaopinto> oh, its linux-image-2.6.31-14-generic-pae
<apw> amitk, bjf, all new shiney arm kernels of both types are in the archive
<apw> lool, i belive you should find a good linux-libc-dev for armel in the archive now
<wzssyqa> [Bug 447791]
<ubot3`> Malone bug 447791 in linux "after update to 2.6.31-13,the virtual Console Huap" [Undecided,New] https://launchpad.net/bugs/447791
<happyaron> hi team, could I ask which package should we exactly file bug against for this bug? ^^^
<bjf> apw, thanks, looks like I might have a regression on mvl
<bjf> bug 450940
<ubot3`> Malone bug 450940 in linux-mvl-dove "Regression in linux-mvl-dove 207 and later causes Y0 boards to hang seconds after booting" [High,Confirmed] https://launchpad.net/bugs/450940
<lool> apw: Thanks
<lool> apw: I did see the build output the package at least
<apw> bjf, hrm, is that your new fix or something in the rebase do we think
<bjf> apw, I've not touched dove other than that config issue, possible rebase / stable updates fallout, not sure
<apw> hrm yes it was a simple config change.  then again the rebase shouldn't have changed much core it was mostly stable updates and that was pretty limited
<apw> and cirtainy nothing on the mvl-dove boot i'd think 
<lool> Too bad we cant bisect it -- exactly what was to be solved by rebasing the tree  :-)
<lool> we could cherry pick stable updates on top of the previous mvl tag and see how long it works
<MTecknology> Did you guys know that rolling your own kernel can be heap load if fun and irritation :)
<Keybuk> rtg: got one for you
<Keybuk> ext4 doesn't seem to be syncing data on shutdown or SysRq-S
<Keybuk> an explicit sync() does seem to work
<rtg> Keybuk, that seems more like one for Ted
<MTecknology> did I break something?
<Keybuk> well, it's causing me at the moment to fail to boot after upgrading the kernel ;)
<Keybuk> because the initramfs is trunctated
<rtg> Keybuk, ick!
<rtg> Keybuk, so, we don't normally sync() on shutdown or reboot? it should sync on unmount.
<Keybuk> we don't call sync() no
<Keybuk> the kernel should do that
<rtg> Keybuk, does rootfs get unmounted before shutdown? I'd think it couldn't as long as /sbin/init was alive.
<Keybuk> yes
<rtg> so that should sync
<Keybuk> of course, now that I look at it, I can't find that sync
<Keybuk> maybe ext4 doesn't sync the filesystem on remount readonly now?
<rtg> hell if I know
<rtg> its hard to imagine that an issue this systemic would not have been noticed already
<Keybuk> doesn't look like it does now
<rtg> Keybuk, drat, lemme wrap up LBM. are you gonna file a bug? this seems like a show stopper.
<Keybuk> the kernel comment for reboot() says you should sync() first
<rtg> how can remount readonly _not_ sync first? especially if there are not outstanding I/O errors.
<Keybuk> it just doesn't
<Keybuk> ext3 clearly does
<Keybuk> ext4 clearly does not
<Keybuk> this looks like a change in ext4 relatively close to .31
<rtg> Keybuk, well, we should confirm this with Ted
<Keybuk> I'm going to put the sync() call back into reboot anyway
<Keybuk> it's probably for the best
<rtg> Keybuk, do shutdown and reboot go through the same path at some point?
<Keybuk> yes
<rtg> app sapce or kernel?
<Keybuk> app space
<Keybuk> kernel is quite different
<rtg> I haven't looked at the shutdown path in the kernel since 2.4 days
<Keybuk> let's see if this fixes it
<apw> Keybuk, so how did you notice, ext4 always dirty on reboot?
<Keybuk_> that seemed better
<Keybuk_> will probably need to do a few of those to be sure
<apw> Keybuk, so how did you notice, ext4 always dirty on reboot?
<rtg> apw, I'm wondering if this might have something to do with the KVM folks complaining about fsck on boot
<apw> rtg very likely ...
<apw> i am supprised noone noticed before, like you or me
<Keybuk> apw: no, truncated files or empty files after reboot
<rtg> Keybuk, I must update kernels several times a day on different machines.
<csurbhi>  but there was an article on lwn about truncation of files for ext4
<Keybuk> yeah, but depends how much gets flushed to disk
<Keybuk> speed of reboot
<Keybuk> etc.
<Keybuk> reboot here is fast, I'm on SSD, but it's *ahem* not production
<apw> Keybuk, i note my main lappy is still ext3, but my 10v is ext4 and i've not seen it there
<csurbhi> it seems that it does a sync only after a timeout and before that if you reboot or shutdown, u can loose data
<apw> but its likely i am idle for ages before reboot often
<csurbhi> http://lwn.net/Articles/322823/
<Keybuk> apw: I've been doing a lot of "update-initramfs -u ; reboot" in the last 24 hours
<Keybuk> and that's when I've noticed it
<apw> oh is this the cause of your bust initramfs you mentioned ... hrm
<Keybuk> possible
<Keybuk> anyway, comment in the kernel above the definition of reboot() says you must call sync() first
<Keybuk> so I call sync() first :p
<rtg> it sure can't hurt
<apw> Keybuk, i wonder what use there is to not sync and hit reboot ...
<Keybuk> apw: speeeeed
<apw> Keybuk, speedily losing my data, yay
<apw> bjf, did you say your y0 was ok on that kernel?
<bjf> apw, so far so good
<apw> bjf, so panic 'less'
<bjf> apw, because it's Y0 and now Y1 I panic 'less'
<apw> bjf, basically it works on all your h/w ?
<bjf> apw, it works on my Y0  and lool's Y1
<bjf> apw, I've not had a chance to test my Y1
<bjf> apw, these are not fat machines to install onto
<apw> no i guess not
<bjf> *fat*fast
 * apw didn't even see that
<lool> bjf: so you coulduse yesterday;s image to install and then upgrade to today's kernel?
<bjf> lool, yup, doing that
<MTecknology> How can I find out if I have any EFI firmware?
<rtg> MTecknology, unless you are running a recent server, then you likely _don't_ have EFI. 
<rtg> apw, care to have a look at karmic LBM?
<MTecknology> rtg: thanks
<apw> rtg sure
<Q-FUNK> smb: howdy! is there anything else I should test for the Geode bug?
<smb> Q-FUNK, Hi there. As much I hate to say so, the last days have been busily filled with other work, so I never had much time to get back to that.
<MTecknology> kernel freeze is tomorrow, isn't it?
<Q-FUNK> smb: understood. please let me know if there's anything else I can do.
<Q-FUNK> s/if/r/when
<rtg> MTecknology, its effectively already frozen.
<smoser> jjohansen, you re-run your kernel tests ?
<smb> Q-FUNK, Sure will do. I'll put any updates into the bug
<smoser> i do remember that we had some intermittent issues with kernel logs, but nothing since we attached chuck's patch that i was aware of.
<Q-FUNK> smb: ok.  I'm just wondering how we're gonna manage to fix this on time for Karmic's release, though.  right now, the whole Geode product line no longer works on Ubuntu, which pretty much kills the investment that Canonical made into LTSP.
<jjohansen> smoser: not yet, and I haven't seen any problems since chucks patch either until yesterday
<smoser> bugger
<smoser> do you happen to have available to you the region that they failed in ? you might wnant to try ther eagain
<Darxus> This is why freezes should happen sooner and be more strict :)
<smb> Q-FUNK, It is quite unlikely that this will happen in the Karmic release. The kernel freeze is tomorrow. We will have fix it in later updates.
<Darxus> Wow.
<Q-FUNK> smb: sad to hear.  
<smb> Q-FUNK, Yes, I know
<Q-FUNK> smb: espeically considering that support for older geodes already fell down a few kernel releases ago and the bug was not acted upon.
<Darxus> Is LTSP still usable under hardy?
<rtg> smb, have we broken something in the 386 flavour?
<Q-FUNK> Darxus: yes and no.  support for Geode x86  CPU is currently broken, which essentially kills support for the most wide-spread CPU used in thin clients.
<Darxus> Ah, Geode is a CPU, thanks :)
<Darxus> I would be more comfortable with this if I felt it was less likely to happen on an LTS release, but I see kernel freeze wasn't any longer for Hardy.
<Q-FUNK> Darxus: hardy was the release that broke if for older Geode variants, actually.  it's never been fixed.
<Q-FUNK> now, karmic broke it for more recent Geode variants, which affects the OLPC as well.
<Darxus> Wow.
<smb> rtg, It is a one byte corruption in inodes early on boot, but as far as I can tell only on geode
<Darxus> The ubuntu release process is weird :)
<Q-FUNK> all this because upstream kernel developers cannot be bothered with answering bug reports.
<Darxus> Q-FUNK: Ah, that sucks.
<Darxus> Q-FUNK: Does it work in upstream?
<Q-FUNK> meanwhile, smb does his best to pinpoint the source of the regression, but he has so much work on his hands that he's unlikely to figure out the solution on time for Karmic.
<AlanBell> ooh, did someone say OLPC?
<Q-FUNK> Darxus: as I already said, upstream is the one that broke it.
<Darxus> Q-FUNK: Ah, okay.  I didn't catch that.
<Q-FUNK> AlanBell: yup. OLPC support broken starting with Karmic, due to upstream regressions in kernel.
<AlanBell> did it ever work? I didn't think the DCON drivers were in the Ubuntu kernel
<Darxus> (I guess submitting an upstream bug report is sufficient implication that the problem was upstream.)
<Q-FUNK> AlanBell: yes, they are in the standard kernel
<AlanBell> at the moment mine never unfreezes the display after the open firmware bit
<Q-FUNK> AlanBell: well, the problem is not DCON support as much as the fact that kernel 2.6.31 flat out won't boot on Geode LX.
<AlanBell> oh, mine flashes the microphone light after 10 seconds or so which I thought was an indication it was doing some stuff
<Q-FUNK> AlanBell: the kernel dies sometimes during the loading of the initramfs image.
<AlanBell> isn't the viglen mpc-l a geode?
<Q-FUNK> AlanBell: viglen products use either a geode GX or a geode LX, depending on which one you're talking about.
<AlanBell> quite a few Ubuntu-UK people have the MPC-L. There was a special discount offer via the Ubuntu-uk podcast
<Darxus> Do you think, for LTS releases, kernel freeze and final freeze should be doubled, to a month?
<Daviey> AlanBell: *IS* still the offer L(
<Daviey> :)
<AlanBell> hi Daviey 
<Daviey> \o
<popey> pip pip
<AlanBell> popey has an MPC-L
<popey> or two
<AlanBell> will they boot Karmic is the question
<AlanBell> live CD should prove it one way or the other
<popey> i dont have cd, i can try off a usb stick, if that helps
<popey> or pxe
<AlanBell> popey: is it a geode GX or a geode LX?
<popey> http://popey.com/~alan/viglen/hardware.html says it's a GX2
<AlanBell> ah, so that might work
<AlanBell> apparently the kernel 2.6.31 flat out won't boot on Geode LX
<smb> Q-FUNK, I just noticed in the latest dmesg, that there is a crashkernel line in the parameters. Has that been always enabled when you booted newer kernels? The original boot with 2.6.30 does not seem to have one. Maybe just desperate but ...
<popey> 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
<Q-FUNK> smb: I installed crashkernel recently.  actually, I think that was pulled by recent ubuntu-standard.
<Darxus> Any objection to me adding "geode" to the title of that bug?
<smb> Hm, then rather not. The bad pointers seem to start right after mounting the root fs. Before much else is done... :/
<apw> popey, did you try the very latest kernel, there were a couple of allocation off by two bytes style bugs fixed in .46
<popey> I haven't done any testing at all yet
<popey> mine run hardy, I'm just here in case someone needs something confirmed/tested
<Q-FUNK> Darxus: I just updated it now
<smb> Q-FUNK, Also, as apw said, it might be at least worth a check with -14.46
<AlanBell> anything I can do on the OLPC to confirm whether or not this is the bug I am stumped by?
<Q-FUNK> smb: I check with every new kernel that pops up.  if any of them ever fixed anything, I'd report it. :)
<apw> so you checked .46 today
<Q-FUNK> AlanBell: yes.  boot with usplash disabled and snap a picture of what happens when it freezes.
<apw> smb, it would be good to report the addy of the i_default_acl ptr in the debug next time
<apw> so we can see if its one inode its reporting or 10 differnet ones
<Darxus> Q-FUNK: Thanks.
<apw> as you cannot get the name
<Q-FUNK> apw: yup.that one crashes too.
<smb> apw, Ok, I update the patch with that
<apw> smb, as it occurs really early in boot, you could consider printing the addy of every inode too as they are added to dcache, with the file
<apw> a
<apw> and see if we get a name that way
<apw> i guess that does assume we ahve some way to collect a long boot output
<smb> apw, I already had the check whenever one was looked up, and that seems to happen rare to never
<apw> smb, i see in the last one there are three bad ones at 83583s in ... so very late in the day
<apw> smb, when you report it, are you releasing the inode then?  ie. its guarenteed to be a different one?
<smb> apw, Yes this actually reverses the claim that it only happens early
<smb> apw, Yep, the inode gets released just the call to release the acl struct is suppressed
<jjohansen> smb: which bug# is this again?
<dhillon-v10> ogasawara: hi, did you recieve my email
<smb> jjohansen, bug 396286
<ubot3`> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
<AlanBell> Q-FUNK: I don't think the OLPC would do usplash as the kernel is loaded from open firmware rather than grub
<AlanBell> I get an Open Firmware screen indicating it is loading the kernel then the ramdisk image into memory, then it should start the kernel and the kernel should start the DCON screen after it gets going. That never happens
<ogasawara> dhillon-v10: I did, unfortunately haven't had time to dig into it
<dhillon-v10> <ogasawara> that's okay, I know that you are very busy but its something interesting I can assure you that :)
<superm1> apw, so re what happens with the half of the patch that's already applied, you aren't able to get wifi enabled still if you boot with it turned off
<superm1> with my other half applied it works properly in either scenario
<rtg> superm1, looking at it.
<dhillon-v10> <ogasawara> I'll talk to you later bye
<jjohansen> smb: what problem with AppArmor did you see with bug 396286, AA uses the inode in very limited ways so it would be good to know what exactly you were seeing
<ubot3`> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
<smb> jjohansen, None in the end. But I like to try to blame apparmor first
<jjohansen> smb: ah, what made you think there were AA problems
<smb> jjohansen, Just as the first messages came in one case after apparmor loaded profiles
<jjohansen> hrmm, well that isn't any help for debugging this :(
<smb> jjohansen, No especially after running with apparmor turned off and still getting the problem. So it is not the reason
<jjohansen> smb: I was just hoping it would be another avenue of looking at the problem
<jjohansen> smb: your and apw discussion failing to get the name peaked my curiousity
<apw> we have an inode getting corrupted, specifically the i_default_acl gets mushed
<apw> and we find out too late to find the name of the file as the dentry has gone
<smb> jjohansen, I am about to update the patch. but unfort. at the time off seeing (inode destroy) the names are likely gone
<apw> so was trying the inode num and device out the inode as they are likely there
<jjohansen> smb: yeah that seems to be always the case
<jjohansen> smb: is the address reliable enough to stick a hardware debug watch on it
<smb> jjohansen, that is what we need to find out
 * jjohansen will be interested to see the results
<apw> sadly the aa off by two has been ruled out ... was hoping
<jjohansen> haha, I guess smb wasn't joking when he said he wanted to blame AA first :)
<apw> heh nope :)
<jjohansen> thats alright, I do too.  The LSM is so invasive, that and AA used be mucking around with the vfs, so it was much more likely
<Q-FUNK> jjohansen: except that I *did* try purging AA and it did not resolve the issue.
<jjohansen> Q-FUNK: yeah, not saying it is the problem, just that it is a good first candidate to suspect
<jjohansen> any LSM module really
<Q-FUNK> jjohansen: smb indeed first thought about AA being the culprit, except that purging it didn't solve it.
<jjohansen> Q-FUNK: yeah, though I was hoping he was actually seeing something in AA when it wasn't disabled as that might have been another avenue to debugging the problem
<smb> Q-FUNK, I am right now compiling a new debug version, which I will upload as soon as it is done, just be prepared that it has received no boot testing and its later into a long day here... :-P
<apw> superm1, this dell patch set seems to stop dell laptop loading completly for the mini10
<Q-FUNK> smb: noted :)
<superm1> apw, which is intended behavior
<apw> it is loaded on my mini 10 now, is it doing nothing?
<superm1> apw, it doesnt do anything there, you are supposed to use compal-laptop
<superm1> apw, smbios 17,11 doesn't work on compal laptops made  this year or earlier
<apw> superm1, hrm i have both loaded
<superm1> apw, so you can try to run rfkill block on the dell-laptop rfkill interface for the mini 10, but it won't do anything useful.  if you run rfkill block for the compal-laptop interface, it will actually block
<apw> superm1, well as it has wl poop in it i assume it actually won't ?
<superm1> apw, actually it should still work with wl
<apw> wild /me tries
<apw> superm1, so it does ... amazing
<superm1> apw, yeah that's some stuff i wrote into compal-laptop earlier this cycle
<apw> shame its not connected to the wireless button on the keyboard still
<superm1> apw, yeah still have a problem that FN-F2 is spitting out what looks like the wrong keycode though
<superm1> once can figure out why the kernel thinks that FN-F2 is the same as XF86AudioNext, then that part can be fixed
<superm1> it's more troublesome for the 11z which actually does have an XF86AudioNext key too
<apw> heh
<sconklin> apw and rtg, I'm looking at changing the CONFIG_VERSION_SIGNATURE setting for netbok-lpia, I'm not sure how the files in debian/rules.d get included. What's different for the case of "fdr binary-custom"? 
<rtg> sconklin, the rules files get included in debian.master/rules (or whatever the topic branch name is). This must be for Hardy still?
<rtg> did we convert Hardy to the abstracted build yet?
<sconklin> rtg: oh yeah, sorry. I'm stuck in the past :)
<sconklin> there's a sed string substitution done by 2-binary-arch.mk that's not happening in the lpis case for the binary-custom target
<sconklin> er lpia
<rtg> sconklin, custom binaries were handled in special places. it'll take me a bit to remember
<rtg> sconklin, look in 6-binary-custom.mk
<apw> yea
<rtg> but why is the netbook branch building  a custom binary? that was for xen, etc
<sconklin> rtg: I don't know, I inherited it
<apw> rtg it was always a custom-binary lpia, and i just moved the patches to the branch and made them null in the custom bit
<apw> probabally should have been converted ... but
<rtg> apw, oh, its all rushing back. ick!
<apw> i know... stem that memory tide you will hurt self
<sconklin> there be dragons here
<rtg> apw, if folks are to continue building lpia in the netbook branch, we should normalize it with master.
<rtg> sconklin, anyway,  6-binary-custom.mk is where the majik happens
<sconklin> rtg ok thanks
<sconklin> oh yeah, custom-prepare- instead of prepare-
<SyL> I'm getting hard freezes about 2 minutes after booting like clockwork when it boots normally. it works find when I boot into the rescue mode. can someone tell me what is the differences?
<Darxus> SyL: What do you select when rescue mode asks how you want to procede?
<SyL> Darxus: when grub boots (hitting escape) I see the menu to select the kernel I want. the rescue mode is from that. 
<Darxus> SyL: Right, then it asks you if you want to drop to a root shell or something, right?
<SyL> once I'm there I do the "drop to root" item and when I select that, it asks for root password and it works
<Darxus> Heh, yeah, there's a bunch of other stuff that runs normally.  Pretty much everything.
<Darxus> SyL: I think your best chance of debugging is the kernel debugger.
<Darxus> Assuming you're not getting anything in logs, like /var/log/syslog
<SyL> Darxus: I have an identical box which is running 2.6.28-* fine. 
<SyL> Darxus: yeah, there is nothing in messages, kern, syslog, etc. 
<SyL> just freese and I have to reboot again
<Darxus> SyL: So you have a bad bug in the current kernal, and the way to figure out what's going on is the kernel debugger.
<rtg> superm1, you around? looking at your rfkill patch.
<SyL> but it almost happens after a minute and 30 seconds
<SyL> Darxus: and how do I select that? 
<Darxus> SyL: Report a bug with the command "debian-bugs linux"
<superm1> rtg, sure, what's up?
<rtg> superm1, how does the dell-laptop driver get notified when the physical rfkill switch changes?
<superm1> rtg, input interface, that was mjg59's first patch
<Darxus> SyL: I don't know, it might not be packaged.  If it's not packaged it probably means patching and recompiling the kernel, which is not something the average user is expected to do.  File the bug.
<superm1> rtg, dell_rfkill_update gets called when the keypress arrives over the input interface
<rtg> superm1, but the key code event isn't sufficient to tell you the state of the switch, is it?
<rtg> dell_rfkill_update() simple tioggle the existing state
<superm1> rtg, unfortunately not.  it's just XF86WLAN.  so you need to keep track of the state in the driver
<superm1> exactly
<rtg> simply toggles*
<rtg> so, if you boot with rfkill enabled it detects the state of the kill switch, then depends on key codes thereafter?
<superm1> Yup
<superm1> by doing it this way you don't lose soft kills that were manually set either
<rtg> ok, I get it. I've added a couple of comments, but have left the code intact.
<superm1> sounds good.  whenever mjg59 has his new i8042 stuff ready, i'll rework this on top of that too
<SyL> Darxus: ok, so I'm SOL until it's fixed. gotcha
<SyL> Darxus: thanks
<Darxus> SyL: It won't get fixed if you don't submit a bug.
<Darxus> SyL: Also, if you submit a bug, people who know a *lot* more than me about the ubuntu kernels will see it.
<SyL> Darxus: I am submitting a bug. I don't seem to have debian-bugs command, which package is that in? 
<Darxus> ubuntu-bugs, sorry.  Did I say debian?
<SyL> Darxus: that makes more sense, thanks. =) 
<SyL> Darxus: what package is ubuntu-bugs in? 
<Darxus> apport?
<Darxus> Yes.
<Darxus> Ah, ubuntu-bug, not plural.
<SyL> Darxus: that was it, thanks. 
<SyL> Darxus: one last thing. is there a way to force grub to force you to pick a kernel? 
<Darxus> SyL: Probably.
<Darxus> SyL: Probably by setting the timeout to unlimited.
<Darxus> SyL: http://www.gnu.org/software/grub/manual/html_node/Configuration.html#Configuration
<Darxus> SyL: Set timeout to something big.
#ubuntu-kernel 2009-10-15
<Notch-1> hi, any news about the loop module? still =y?
<MTecknology> Notch-1: it is by default
<MTecknology> Notch-1: I'm running w/o it
<MTecknology> 1.5hr later..
<geoff918> I recently tested my system, which works, and I can't add it to this page: xbRiAnNa o7x
<geoff918> oops
<geoff918> this page: https://wiki.ubuntu.com/KernelTeam#Contacts
<geoff918> https://wiki.ubuntu.com/KernelTeam/Grub2Testing
<geoff918> geeze...
<geoff918> Anyway, I have an Acer Aspire 5610
<Notch-1> MTecknology: yeah, i'm recompiling, again :D
<MTecknology> Notch-1: I think I'm done tweaking for now - the kernel size is down to 2.2MB
<Notch-1> this really sucks, i could use a clean default normally-upgradable kernel...
<Notch-1> i don't want to tweak
<MTecknology> Notch-1: why aren't you using that?
<Notch-1> i need to use loop-aes..
<Notch-1> my life was seriously better when it was =m
<MTecknology> did you file a bug about it?
<Notch-1> yeah, it's an old story...
<Notch-1> in few words, some people care too much about some microseconds at boottime
<MTecknology> you mean me?s
<Notch-1> i don't think so, since you seem to don't know the problem yet, but i don't know so much... look here if you want to know... https://bugs.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902
<ubot3> Malone bug 342902 in loop-aes-source "Build error: âstruct bioâ has no member named âbi_hw_front_sizeâ" [Medium,Triaged] 
<Notch-1> beside, the original real compiling bug, indipendent of the the kernel configuration, was never fixed because this thread ended in nothing. so even if i recompile the kernel without loop, i still need to download the loop-aes source from sourceforge because the repositorys one is bugged... there are 2 unhandled problems with loop-aes since jaunty
<Notch-1> i hope that you used the correct version for karmic, there were 2 or 3 bugged ones, i don't have the versions now... this will solve one problem, at least...
<MTecknology> sorry - internet died
<MTecknology> I didn't even know if that sent
<MTecknology> Notch-1: I meant the millisecond thing - I now have a 10sec boot across the area I care about
 * MTecknology hoping that I didn't remove something I need
<Notch-1> ah you did that for the boottime? :D
<MTecknology> hm?
<Notch-1> you recompiled the kernel to speed up the boot? i will never do that :D anyway i was talking about the default configuration, the people that make decisions that should be best for everybody... sigh...
<MTecknology> sorry :(
<MTecknology> how is it that you're recompiling it?
<Notch-1> i told you, this freakin loop module...
<MTecknology> how is it that you're recompiling it? - not what are you trying to do
<MTecknology> I just pulled the git branch, grabbed the default .config (tossed it together from 3 .configs), make menuconfig, make all modules_install install && update-grub
<Notch-1> ah
<Notch-1> not exactly, it's very hard to find the original formula :D
<MTecknology> the ubuntu kernel is rolled out differently, but that's because it reaches a larger base
<Notch-1> anyway yes with git, the exact current version
<Notch-1> with AUTOBUILD=1 skipabi=true skipmodule=true fakeroot debian/rules binary-debs
<Notch-1> after a menuconfig and a clean off course
<MTecknology> sounds harder than what I did
<Notch-1> what you mean?
<MTecknology> did you wind up making a .deb?
<Notch-1> hard it's not good, i prefer soft :D
<Notch-1> you mean just rebuild the kernel and replace it by hand?
<MTecknology> When you finished creating the kernel, did you have a .deb package you could install with dpkg?
<Notch-1> yes
<MTecknology> then you went the hard route ;)
<MTecknology> do you have ccache installed?
<Notch-1> i understand, but wich is the softer one?
<MTecknology> softer?
<MTecknology> I mean that you went through more effort than you needed to if you're making a kernel for your system only
<Notch-1> ah ccache, i read about it...
<MTecknology> You should install it - it makes a difference when you compile
<MTecknology> What proc do you have?
<MTecknology> how many cores
<Notch-1> softer=better
<Notch-1> just one
<MTecknology> 1cpu with 1core ?
<Notch-1> this is not the real problem, i recompile on an old notebook, i just don't want to
<MTecknology> After you finish doig make menuconfig, then run this command and you will have your new kernel built and installed  -->  export CONCURRENCY_LEVEL=3; export MAKEFLAGS="HOSTCC=/usr/bin/gcc CCACHE_PREFIX=distcc"; make all modules_install install && update-grub
<Notch-1> i don't want to speed up the recompile, i just wish to not have to at all... it's not a matter of time
<MTecknology> You can copy the .config from the existing kernel too..
<Notch-1> noted, thanks
<MTecknology> I'm tryiing ot find the command I used
<Notch-1> but i don't know if i will use it, i want the simplest way possible...
<MTecknology> that is the simplest
<MTecknology> You can just use  "make all modules_install install && update-grub" if you want
<Notch-1> anyway my grub can't be reached from my booted system, i'm inside a kexec :D
<MTecknology> Here's what I used to get the .config cat debian.master/config/config.common.ubuntu debian.master/config/amd64/config.common.amd64 debian.master/config/amd64/config.flavour.generic > .config
<MTecknology> I've been building the kernel from my home directory :P
<MTecknology> the git branch is at ~/Downloads/ubuntu-kermic
<MTecknology> s/e/a/
<Notch-1> :D
<Notch-1> i'm not bash :D
<MTecknology> I learned how to compile a kernel on Gentoo
<MTecknology> You can ommit && update-grub
<Notch-1> commit && update-grub to recompile?
<MTecknology> This part uses 3 compile processes which is good for 2 cores; it uses gcc to compile, and it sets the compile to use ccache which helps emilinate redundant processor calls -> export CONCURRENCY_LEVEL=3; export MAKEFLAGS="HOSTCC=/usr/bin/gcc CCACHE_PREFIX=distcc";
<MTecknology> This part compiles the kernel, compiles the kernel modules, and installs them where they need to go -> make all modules_install install
<MTecknology> this part updates grub configs so the newly installed kernel will be used update-grub
<MTecknology> this part updates grub configs so the newly installed kernel will be used -> update-grub **
<MTecknology> hopefully that all made sense
<MTecknology> This can help you too - https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
<MTecknology> I'm going to go watch tv w/ my gf - bbl
<Notch-1> yes yes, thanks, i understand but i already know that, i messed up my last question, sorry :P
<Notch-1> i was thinking that you were saying that on gentoo is different
<Notch-1> enjoy, see you
<Notch-1> and thanks for the tips, next time i'll try to speed it up, maybe it will be less painful..
<MTecknology> Notch-1: gentoo actually lets you pull the kernel sources using the package manager - some things are different - but what I told you is universal across most any distro
<MTecknology> now... what is it in the kernel that I don't have that makes the system run cooler
<marcriera> hello everybody. does anyone know why karmic koala release candidate is shipped with a vanilla kernel?
<marcriera> pgraner: hello, i have a question about kernel versions on 9.10. I was wondering if when the final release comes it will come with the actual 2.6.31 or it will switch to another kernel release. Many thanks.
<marcriera> to myself : http://en.wikipedia.org/wiki/Linux_kernel#Versions    . I understand that the even-odd stile is not working any more. so 31 is not vanilla. i guess ubuntu will remain on it for a while. 
<pgraner> marcriera: I'm not sure what you mean. 9.10 has 2.6.31.4 plus some backported fixes.
<pgraner> marcriera: it was announced back May that 9.10 will ship with 2.6.31
<marcriera> pgraner: i'm sorry i bother you. I work with a group of researchers and the like the 2.6.31 improvements, and i was not sure ubuntu will stay with 2.6.31 when it passes from RC to final release. I was still thinking about the even-odd vanilla-stable stile releases. 
<marcriera> pgraner: thanks for you clarification. We will migrate to 9.10 , starting tomorrow , and start using the 2.6.31 for developing pourposes. thanks again.
<dtchen> oh, oops
<dtchen> bah, wrong channel
<RainCT> Hi
<RainCT> Touchpad and WLAN don't work anymore on Karmic with the new kernel (-14), the previous one (-13) still works. Any idea?
<ogasawara> RainCT: can you tell me the specific kernel version where it's failing (cat /proc/version_signature)
<ogasawara> RainCT: some rfkill patches went in recently
<ogasawara> RainCT: and are you on a Dell?
<RainCT> no, ASUS EeePC 1005HA
<ogasawara> RainCT: hrm, can you open me a bug using "ubuntu-bug linux"
<ogasawara> RainCT: that'll get me all your specific hw info etc
<RainCT> no connection :)
<ogasawara> RainCT: no wired?
<RainCT> awesome, USB mouse doesn't work either o_O
<RainCT> ogasawara: connecting it to the router with an Ethernet cable doesn't seem to do anything either
<RainCT> (ethernet didn't work on Jaunty, but did with previous Karmic kernels)
<ogasawara> RainCT: hrm, what about saving to a USB and then attach to a launchpad bug
<ogasawara> RainCT: want to see dmesg, sudo lspci -vnvn, and the /proc/version_signature
<RainCT> ok I think that'll work (running ubuntu-bug just said "no such file or directory: /proc/asound/cards" btw)
<RainCT> (and someone with another eeepc just confirmed he has the same problem with today's update)
<dtchen> you've got some serious resource contention, then
<ogasawara> RainCT: if you can, point any others with the same issue to your bug in lp
<apw> RainCT, can you also attach a dmesg output from the -13 (clearly marked as from the working one)
<ogasawara> RainCT: and the USB mouse regression, is that also between -13 and -14?
<RainCT> I believe so, haven't tried it with -13
<dtchen> RainCT: err, wait. is this issue reproducible with linux-backports-modules-alsa-2.6.31-14-generic purged?
<apw> RainCT, and is it directly connected or via a hub
<RainCT> directly. USB sticks aren't showing up as /dev/{s,h}d* either
<RainCT> dtchen: trying that now
 * apw wonders if udev is still running
<RainCT> ps shows 1 upstart-udev-bridge and 3 udevd
<apw> on the usb sticks, does anything appear at the end of the dmesg when you shove them in?
<RainCT> dtchen: postrm gives "Exec format error"
<RainCT> (disregard someone else having the same problem, he asked for a bug number but hasn't tried updating yet.. doing so now)
<RainCT> dtchen: actually the files in /var/lib/dpkg/info/linux-backports-mod../* are all empty
<RainCT> fsck complained when I rebooted after the update so it may be because of file corruption
<dtchen> RainCT: ext4 for /var ?
<RainCT> yes
<dtchen> RainCT: what version of upstart?
<RainCT> dtchen: 0.6.3-9
<dtchen> RainCT: regardless, it sounds eerily like the sync() issue that Keybuk mentioned for ext4, although it should have been worked around in that version of upstart that you have installed
<dtchen> RainCT: http://pastebin.com/d3d01c4bf has the contents of /var/lib/dpkg/info/linux-backports-modules-alsa-2.6.31-14-generic.postrm
<Keybuk> that was only a guess
<Keybuk> I took the sync() out ages ago, and only noticed corruption recently
<Keybuk> so I put it back on the basis lots of things in the kernel source said THOU SHALT SYNC!
<Keybuk> it's entirely possible we have an O M G ext4 bug in there
<Keybuk> at some point, we should probably mention it to slangasek
<dtchen> i know i've been able to trigger it in 2.6.32-rc1, but uh, that was 2.6.32-rc1
<Keybuk> rtg: have you been naughtily backporting patches again? :p
<RainCT> OK, reinstalling the kernel fixed everything
<ogasawara> RainCT: sweet, so no regressions now?
<RainCT> ogasawara: nope :)
<rtg> Keybuk, I love being naughty, but I'd like to know what for?
<Keybuk> rtg: ext4
<rtg> not recently.
<rtg> perhaps in stable, lemme check
<Keybuk> colin says he's getting reports of grubenv being zero sized too
<Keybuk> which would bit the "not written before reboot" pattern too
<Keybuk> (and I've seen that!)
<RainCT> WLAN is worse than using the latest drivers (even with backports-modules-wireless installed), but that isn't a regression from previous Ubuntu kernels (and it's certainly better than Jaunty, where it didn't work at all)
<rtg> Keybuk, "xt4: Don't update superblock write time when filesystem is read-only" is the most recent in the changelog
<Keybuk> right, it won't be that one
<rtg> thats also the last touch in git
<Keybuk> hmm, that's annoying
<rtg> git log fs doesn't show anything either. I thought maybe jbd might have been messed with
<dtchen> rtg: / apw: thanks very much for the wireless and alsa backports, BTW
<rtg> dtchenno problem. did the ALSA stuff actually help?
<rtg> dtchen: ^^
<dtchen> rtg: some people so far
<dtchen> trying to get everyone to test it
<dtchen> at least jerone's problem with the dells is progressing
<dtchen> alsa-side it's fixed, just need to twiddle the right PA bits now
<apw> rtg i thought the alsa in there was alsa-stable, and so pretty close to .31
<rtg> apw, its whateveris in alsa-drivers snapshot 1.0.21
<rtg> which is what dtchen suggested I use
<apw> fair enough
<dtchen> apw: pretty far from .31
<dtchen> it's much closer to .32
<dtchen> so it's 2.6.32 + quirks and fixes from 20091012
<dtchen> i.e., no core changes from .32
<apw> dtchen, cool
<apw> dtchen, is it me or did the last updates trigger some alsa control lossage agian... i had to go enable a bunch of capture things on dell
<dtchen> apw: meaning alsa-utils upload?
<dtchen> apw: it shouldn't have, but there're too many reports of further regressions
<apw> last couple of times i've updates things alsa things have gone haywire, no idea if kernel or userspace much
<apw> i do seem to have a bunch more alsa controls than last time i looked
<dtchen> apw: in your case, is it mixer settings being muted?
<apw> i had a couple of those muted, and a couple of captures without the red CAPTURE L R at the bottom
<apw> never seen that CAPTURE thing before ...
<dtchen> apw: hmm, is it just capture elements being muted or playback elements as well?
<apw> streaching my memory now, likely just capture elements
<apw> i think the speaker mute was me
<dtchen> if it's just capture elements, that's likely the symptom that jerone described
<dtchen> particularly if you've a model affected by the latest quirk changes (HP dv series)
<RainCT> dtchen: (ah, installing the alsa backports thing worked here to get the microphone working on the eeepc 1005ha)
<dtchen> RainCT: yes, as expected
<dtchen> that's part of the massive mic-switching infrastructure that was dumped into 2.6.32
<dtchen> hence why lbm is a good idea for newer HDA
<rtg> apw, we should go through our list of UBUNTU patches (once again) and figure out which ones should go upstream and/or stable.
<apw> yep we should next week?
<rtg> seems about right
<apw> excellent
<rtg> I'll wait until you are bleary eyed Wed night, after a few beers. then we can do it.
<apw> heheh
<h00k> I'm having terrible kernel panics on my laptop, I was wondering where linux-crashdump actually dumps useful information to?
<ogasawara> h00k: the following might help https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe
<h00k> ogasawara: ahha, thank you!
<h00k> ogasawara: it must not be able to figure out what is going on because I don't get anything with apport :(
<h00k> standby
<h00k> lemme play around and see what I can do
<h00k> am I assuming that when it freezes and the numlock/capslock light flash that its a kernel panic?
<h00k> yeah, forcing the kernel oops is not having my laptop reboot itself.
<h00k> Yeah, I'm not having any luck :( I really hope that other people aren't having this problem, I'd like to get as much info to the developers as I can
#ubuntu-kernel 2009-10-16
<h00k> I still cannot get these kernel panics to report.
<h00k> I really hope the issue is known
<MTecknology> h00k: what's happeneing?
<h00k> MTecknology: it occasionally freezes, caps-lock+numlock blink
<h00k> I haven't found anything in specific to cause it
<h00k> nothing gets logged or reported with apport/linux-crashdump
<MTecknology> did you try fsck, spinrite, and memtest?
<MTecknology> or watch the heat on the system? acpi -t
<MTecknology> just what comes to mind first
<MTecknology> I prefer acpi -tf..
<h00k> fsck is okay, spinrite, no, memtest yeah
<h00k> test is okay
<MTecknology> :S
<h00k> er, acpi is okay
<h00k> *temp
<h00k> spinrite, I don't see that in the repos
<MTecknology> it's not
<h00k> k.
<MTecknology> but a bad drive probably isn't your issue
<h00k> smartctl repors drive as passed
<h00k> its a laptop a little over a year old
<h00k> I take extremely good care of it
<MTecknology> that is odd
<MTecknology> I guess you tapped my knowledge - file a bug?
<h00k> with what information, thats the hard part:(
<MTecknology> what does uname -a give you?
<h00k> er, my laptop is having a kernel panic, no errors logged, nothing appears wrong, apport isn't reporting it with linux-crashdump installed, it won't reboot after I initiate a kernel-oops as described on the kernel debugging recipe wiki
<h00k> Linux hookbox 2.6.31-14-generic #47-Ubuntu SMP Thu Oct 15 02:08:08 UTC 2009 GNU/Linux
<MTecknology> update your kernel - maybe by change it will fix the issue
<h00k> oh, I do have updates, hang a sec
<h00k> let me see if the kernel is included.
<MTecknology> -15 was released today
<h00k> I'm just worried other people are having these problems and don't know what to report
<MTecknology> oh, I'm thinking server has -15
<h00k> MTecknology: it hasn't hit what ever repo I'm pulling from yet
<MTecknology> ya, I was thinkin something else, sorry
<h00k> its okay
<TheMuso> 15 hasn't been released afaik
<TheMuso> And according to the karmic git repo, it hasn't either.
<MTecknology> TheMuso: 21:37 < MTecknology> ya, I was thinkin something else, sorry
<MTecknology> ;)
<TheMuso> oh ok
<MTecknology> TheMuso: made ya look though :)
<MTecknology> I wish I knew something else to suggest...
<MTecknology> TheMuso: any ideas?
<MTecknology> h00k: otherwise I guess the best you can do is just file the bug with that info..
<h00k> MTecknology: I...er...suppose. yeah.
<MTecknology> h00k: sorry :(
<h00k> MTecknology: under ubuntu-kernel, I don't see "report bug"
<h00k> ta-da!
<h00k> okay.
<h00k> working on it, anyway.
<h00k> I keep getting launchpad oops'
<h00k> I'll work on it anyway.
<MTecknology> h00k: apparently technology hates you?
<MTecknology> I have that going on now..
<h00k> MTecknology: apparently.  This netbook is rockin'
<h00k> MTecknology: :)
<MTecknology> ttyl
<TheMuso> Sorry guys, no ideas.
<amitk> dinh: any luck reproducing the USB errors?
<bdrung> hi, what's the status of the ATA TRIM support in karmic?
<bdrung> my ssd supports the trim command (indilinx controller, firmware version 1819)
<apw> TheMuso, yo ... you about?  have a query about linux-rt
#ubuntu-kernel 2009-10-17
<kendrick> Hi, I'm having an overheating issue that starts somewhere between 2.6.31-11 and 2.6.31-14 on an acer aspire 5315. Where can I properly fill this bug? I tried following the online guides but i guess because this is the beta version "ubuntu-bug linux" tells me this is not a genuine Ubuntu pakage.
<maxb> it is not because its a beta that it says that
<maxb> try ubuntu-bug linux-image-$(uname -r)
<maxb> kendrick: ^
<kendrick> what kernel image would i use if i only know that the bug lies somewhere between -11 and -14 or should i try to narrow it down myself first?
<Womble2> It's a Keybuk!
<Keybuk> It's a Womble!
<Womble2> Yes
<lamont> kendrick: I might file it against -14 and mention that it worked in -11, and is broken in -14
<lamont> though in any case, you'll be filing it against the 'linux' package, not the binary
<kendrick> I wrote about an overheating problem I am having on kernel 2.6.31-14 and I was wondering: when I send my problem information using "ubuntu-bug linux-image-2.6.31-14-generic" should I be booted up in that kernel?
<jjohansen> kendrick: that is the easiest way
<Darxus> install: cannot stat `debian/linux-bfs-image-2.6.31-14bfsbfq1-generic-pae/boot/vmlinuz-2.6.31-14bfsbfq1-generic-pae': No such file or directory
<Darxus> That's a discouraging error.
<Darxus> Found my problem.
<Darxus> I renamed the pae package linux-bfs (incorrectly) and the virtual package linux-bfs-bfq.  And it was... transitioning between them.
<Darxus> I need to un-hardcode this stuff.
<xteejx> Hi guys, I am triaging bug 425756, it's against the kernel, to do with hardware detection, I've set it Triaged as I believe there is enough information for someone to look at it. Can someone from Kernel Team confirm there is enough information please?
<ubot3> Malone bug 425756 in linux "[regression karmic] cd/dvd drive not detected" [Medium,Triaged] https://launchpad.net/bugs/425756
<xteejx> note: its a regression from hardy
<b2bf> hi everybody. i maybe messed up with libraries and when i try to compile my kernel it returns with drivers/built-in.o: In function `con_init':vt.c:(.init.text+0x1969): undefined reference to `.L1454'  anyone may help?
<Darxus> After karmic is released, you guys will accept a patch to make the linux source package name less hard coded, right?  Renaming it every release is painful.
<dtchen> err
<dtchen> it's linux.
<dtchen> are you referring to the _binary_ package linux-source-2.6.foo?
<Darxus> No.
<Darxus> dtchen: I've been making a patched version named linux-bfs-bfq.
<Darxus> And there is a bunch of stuff in the package for automating renaming, but it's not used in a lot of places.
<Darxus> I'm just talking about changing it so I only have to modify the package name in a couple places.
<dtchen> well, sure, i'm certain patches would be reviewed
<Darxus> Thanks.
<Darxus> A big part of the problem is, "linux" is far from a uniq string I can just search and replace on.
<feniix> Hello
<feniix> Can anybody tell me or point me to a how to on how to force the make-kpkg command create the .dsc .diff.gz and .changes files to uploadad to ppa using dput?
<Darxus> feniix: That's probably an inappropriate way to create something for upload to a ppa, even if it's possible.
<feniix> I have applied the con kolivas patch to the latest 2.6.31 kernel from karmic and I would like to be able to upload it to ppa (or do I need to create those files manually?)
<feniix> oh :/
<Darxus> feniix: I'm doing the same, properly :)
<feniix> what would be the appropiate way?
<feniix> :D
<Darxus> I already did 2.6.31-13 with v.303, I'm currently updating to 2.6.31-14 with v.304.
<feniix> cool :)
<Darxus> feniix: Well, the hard way is to patch the existing linux sourc package that produces basically all the ubuntu kernel packages.  Which is what I do.
<Darxus> feniix: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424927
<ubot3> Malone bug 424927 in linux "include Brain fuck Scheduler" [Wishlist,Confirmed] 
<Darxus> feniix: It looks like my test build will be done soon.  I expect to upload the new version within an hour, so the new stuff will be available today.
<feniix> I did a git clone from the ubuntu git karmic repository 
<Darxus> feniix: I actually dropped my version with just bfs and am now doing bfs+bfq.
<Darxus> I've never used git :P
<Darxus> feniix: I'd really appreciate testing of the new version later today.
<feniix> ok, I am already running 304. but would be more than willing to try yours
<feniix> so far no issues
<Darxus> Thanks.
<Darxus> Yeah I haven't had any problems.
<feniix> I am on a T61  intel gfx 4gigs (ubuntu 32)
<ubot3> feniix: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 1978, column 8
<Darxus> I've been running it since I got it to build, 8 days.
<Darxus> feniix: Looks like you found a bug in ubot3.
<feniix> I am on a T61  intel gfx 4gigs (ubuntu 32)
<ubot3> feniix: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 1978, column 8
<feniix> lol
<feniix> yeah
<Darxus> ubuntu 32
<Darxus> (ubuntu 32)
<Darxus> Weird.
<feniix> have you notice big improvements using bfq against cfq?
<feniix> I am on a T61
<feniix>   intel gfx 4gigs
<feniix>   intel gfx 4gigs (
<feniix>   intel gfx 4gigs (ubuntu 32)
<feniix> T61  intel gfx 4gigs (ubuntu 32)
<ubot3> feniix: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 1978, column 8
<Darxus> feniix: No.  But I haven't tried.  I suspect it would be easier to notice goinb back to CFQ.
<feniix> T61  intel
<feniix> T61  intel gfx
<Darxus> It built.  212 minutes.
<feniix> T61  intel gfx 4gigs
<feniix> T61  intel gfx 4gigs (
<feniix> T61  intel gfx 4gigs (ubuntu
<feniix> T61  intel gfx 4gigs (ubuntu 32
<ubot3> feniix: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 1978, column 8
<feniix> lol
<feniix> go figure
<feniix> T61  intel (ubuntu 32
<feniix> T61  intel gfx (ubuntu 32
<feniix> T61  gfx 4gigs (ubuntu 32
<ubot3> feniix: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 1978, column 8
<feniix> T61  4gigs (ubuntu 32
<Darxus> T61
<feniix> T61  gfx 4gigs (ubuntu 32
<feniix> T61  gfx 4gigs (ubuntu 32
<feniix> T61  intel gfx 4gigs (ubuntu 32
<Darxus> Very weird.
<ubot3> feniix: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 1978, column 8
<feniix> yep
<feniix> T61  gfx 4gigs (ubuntu 32
<Darxus> Test booting.
<feniix> see you
<feniix> leave a message when the ppa is uploaded
<Darxus> $ uname -a
<Darxus> Linux dancer 2.6.31-14bfsbfq1-generic #48 SMP Fri Oct 16 22:11:17 EDT 2009 i686 GNU/Linux
<Darxus> $ dmesg | egrep -i "bfs|bfq"
<Darxus> [    0.553546] io scheduler bfq registered (default)
<Darxus> [    1.497336] BFS CPU scheduler v0.304 by Con Kolivas.
<Darxus> Sweet.
<Darxus> Building source package, which takes about 5 minutes, then I'll upload, then launchpad with spend a few hours building.
<feniix> :)
<feniix> Draxus: can you tell me the process of building the package the way you did?
<feniix> Draxus: apt-get source linux-image (and then modify it and apply patches?)
<Darxus> feniix: It's in the bug I gave you a link to.
<Darxus> feniix: I uploaded the source package.  1 hour till it starts building, then about 3 hours to build.
<Darxus> feniix: If you don't care about renaming the package it's easy.
<feniix> aaah
<feniix> cool, found that part
<Darxus> Make sure you get the stuff about disabling ABI and modules checks.  That's a pain.
<feniix> Yeah saw your messages
<feniix> I will wait for your ppa first, and then will try to see how does the build process work
<feniix> at first I thought you uploaded binary only packages to the ppas, but now I see its a continuous build system and builds the packages itself
<Darxus> Yeah.  It won't let you upload binaries.
<Darxus> Although dput will let you, and then you'll get an email that you suck.  Annoying.
<Darxus> You get an email that your upload was accepted or rejected.  And if a build fails.  I wish you got one when all builds completed.
<feniix> funny
<feniix> if you use ppa.launchpad.net without https
<feniix> you get access to full directory listing
#ubuntu-kernel 2009-10-18
<Darxus> Just started building.
<Darxus> feniix: Hah.
<Darxus> Oh, neat, all the ppas.
<Darxus> Looks like 3,158 of them.
<Darxus> feniix: My updated linux-bfs-bfq packages just finished building in my ppa.
<tiger2wander> Hello everybody!
<tiger2wander> Could you talk to me what new in Ubuntu Karmic kernel?
<tiger2wander> My current version is: 2.6.31-14-generic #47
<hyperair> is anyone here involved in the PM stack of the kernel?
<hyperair> i've been trying out tuxonice for the past few days and have noted that tuxonice resumes *extremely* fast compared to uswsusp and the kernel method ubuntu uses. however, for some reason or other tuxonice won't get accepted in the mainline kernel.
<hyperair> something i've noted however is that while tuxonice appears to take less time, it's mostly because uswsusp and the kernel method take ages to swap out stuff after resuming
<hyperair> as in, it resumes for ~half a minute, and then it swaps out for another two to three minutes.
<hyperair> so anyway, something i was thinking about was that if more pages are copied out of the swap during the resuming process instead of allowing it to all be swapped out later, it'd end up faster.
<hyperair> or we could just have the tuxonice patch applied onto the ubuntu kernel and use that instead, since it appears to have support for usplash and works really fast (we're trying to get ubuntu to work faster after all)
<AceLan> hyperair: hihi, I also using the tuxonice patch on karmic kernel, it's really good
<hyperair> i was hesitant while i didn't compile kernels, but as long as i'm using PHC, i'll have to continue compiling kernels so i figured i might as well test out tuxonice =p
<AceLan> hyperair: I have a tuxonice branch, if you would like to keep up with karmic, you can try to use my branch # http://kernel.ubuntu.com/git?p=acelan/ubuntu-karmic.git;a=summary
<hyperair> nah, i'm following the zen kernel
<hyperair> but thanks anyway =)
<hyperair> but i think it'd be really beneficial to ubuntu if we used the patch in ubuntu
<AceLan> you can raise this issue on ubuntu kernel mailing list
<hyperair> hmm maybe i should eh
<AceLan> so that we can discuss this further
<hyperair> are there any discussions i should know about before doign that, though?
<hyperair> i mean when i was having my uswsusp vs kernel method arguments with some other ubuntu developers, it seemed as if it was discussed a lot already and for some reason or other (that i still don't understand) we're using the kernel method and no other
<AceLan> I don't know if the kernel team discuss this issue before
<hyperair> who's in charge of PM stuff anyway?
<hyperair> when i was still poking around, i saw a bunch of random names, but no real team working on it
<hyperair> and when it comes to hibernating/suspending issues, there really are a lot
<hyperair> aside from hibernating being painfully slow by default
<AceLan> I think Tim Gardner is in charge of karmic kernel now
<AceLan> and after karmic released, Stefan Bader will take over it
<hyperair> the kernel or suspend/hibernate or both?
<AceLan> everything
<hyperair> i see
<AceLan> but I think it's too late to add tuxonice to karmic kernel
<hyperair> yes, i understand that.
<AceLan> maybe lucid
<AceLan> the 10.10
<AceLan> 10.4
<AceLan> :p
<hyperair> so there is a possibility then
<hyperair> 10.04
<AceLan> yes
<AceLan> reise this issue early has more chance to add it
<hyperair> alright
<hyperair> if someone could raise it at some UDS or other it'd be awesome
<hyperair> and since i'm at the other end of the world, i don't exactly feel up to dropping by uds
<AceLan> please send an email to kernel-team@lists.ubuntu.com , I'll followup add some comment
<hyperair> sure
<AceLan> I'll attend UDS and maybe make an demo to kernel team
<hyperair> cool!
<AceLan> but my English is not so good
<hyperair> hmm
<AceLan> so... I don't know if I could make enough attention
<hyperair> it's worth a try imo
<hyperair> =p
<AceLan> sure, I'll try it
 * AceLan &
<hyperair> heh
<hyperair> AceLan: i've just posted
#ubuntu-kernel 2010-10-18
<smb> lucent, Seems there is a fix for you heading our way through stable. :)
<Kano> hi, where is i386 for 36rc8
<ogra_ac> Kano, for natty ?
<Kano> mainline
<ogra_ac> ah, no idea ... for natty it might have ended up in universe ... happens sometimes with a new release 
<Kano> only amd64 available
<ogra_ac> yeah, probably a packaging issue ... might be though that most of the kernel team is on vacation this week
<ogra_ac> pre-UDS week is a typical time for that
<apw> Kano, it didn't build, upstream bug
<Kano> ah
<apw> the build log clearly shows the error, there is a subsequent upstream commit
<apw> lag, http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D
<Kano> so rc9/final will build again
<apw> lag, https://wiki.ubuntu.com/Kernel/MainlineBuilds is where they are documented
<apw> Kano, yes, likely the daily after it built
<apw> someone didn't do their build tests before submitting their patches there
<apw> lag, https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed
<jcastro> pgraner: you need to start accepting/declining sessions here or they won't get scheduled: https://blueprints.edge.launchpad.net/sprints/uds-n/+settopics
<diwic> jcastro, what's the deadline for me who wants to have a session but has no privileges to authorize them?
<jcastro> diwic: we keep scheduling all through UDS depending on room, speaking to the track lead sooner will help
<diwic> jcastro, so can I affect the scheduling algorithm by saying I want to attend some sessions (and the scheduler will try to make them non-overlapping), and if so, how?
<jcastro> you affect it if you mark yourself as essential when you subscribe to a blueprint
<jcastro> if you just subscribe yourself it will do it's best to not overlap, but "essential" is what guarantees it not to happen
<jcastro> https://blueprints.edge.launchpad.net/ubuntu/+spec/appdevs-desktop-n-opportunistic-apps-stable-release
<jcastro> it's the subscribe thing on the right.
<jcastro> red people are essential
<diwic> so for how long can this rescheduling appear?
<jcastro> what do you mean?
<diwic> I mean, if I subscribe to two currently overlapping sessions, will one move?
<jcastro> I believe so
<jcastro> it's supposed to prevent them from being scheduled in the first place like that
<apw> jcastro, when is primary scheduling going to occur (or has it already)
<diwic> right, but the scheduling has already begun, and I can still subscribe to blueprints, right?
<apw> jcastro, i think pete is on-site today so unlikely to respond
<diwic> jcastro, just to take it to the extremes, can I on next monday realize that I want to attend two sessions going in parallel, mark myself, and it will reschedule, confusing all other people currently walking towards that room?
<jcastro> apw: it's supposed to have been occuring over the past few weeks, do any of you have power to approve blueprints? Most tracks have one or two assistants
<jcastro> diwic: no, that doesn't happen
<jcastro> diwic: I recommend subscribing to the ones you want
<apw> jcastro, how does one find out who has, i am pretty sure i do not
<jcastro> then using your personal schedule to make sure they don't collide
<jcastro> apw: it would probably be the people who did it last time
<jcastro> apw: let me look
<apw> that likely means pgraner and ogasawara 
<jcastro> apw: yep, you are correct
<apw> who are both on-site today
<diwic> jcastro, thanks for the answers, I'm just trying to figure out how the system works :-)
<apw> i probabally need to get self added to that list, will have to hastle pete when he is back
<jcastro> diwic: duct tape and parachute cord.
<apw> jcastro, coo advanced
<jcastro> apw: he can't add, only people on the techboard unfortunately. If you ping pitti or colin ask them to put you in ~uds-organizers
<jcastro> apw: if you have an idea of what pete wants I suggest you ask them and tell them you talked to me
<apw> (i was assuming they would need his authorisation)
<jcastro> well, if leann is around later today she can just clean up the queue
<apw> yeah no idea of their availability later ... i'll see what i can do
<smb> She is onsite as well
<apw> yep
<jcastro> apw: I can approve obvious ones if you'd like
<jcastro> like the typical review sessions you always have, etc.
<apw> those i think are already done are they not?
<jcastro> let me check
<JFo> bug handling needs to be scheduled if it isn't already
<jcastro> JFo: done!
<apw> jcastro, is https://blueprints.edge.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review approved enough ?
<lag> apw: Pseudo-terminal will not be allocated because stdin is not a terminal.
<JFo> thanks jcastro :)
<jcastro> apw: yep, ok I think I see the problem, the linaro hardware ones are piling up
 * apw looks vague
<jcastro> apw: ok I will send them both a mail reminding them. When you see pete mention to him that it's probably a good idea to get one other person in the uds team
<apw> jcastro, oh is he in charge of hardware-*
<apw> jcastro, will do
<jcastro> apw: yeah, it's more of 2 UDSes
<apw> jcastro, could you shove over https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review and https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance, we are going to defiantly need both of those
<jcastro> ok
<apw> jcastro, i know that doesn't help you with your issues
<jcastro> getting them in there does. :)
<apw> jcastro, who is handling blueprints which have no track prefix ?
<slow-motion> http://paste.ubuntuusers.de/399129/ that is the dmesg and wscan output from my terratec cinergy t2. before maverick it was working. why does it stopped working?
<jcastro> apw: they have to have track prefixes or they don't get scheduled at all
<apw> jcastro, and is anyone sweeping for them >?
<apw> i see a qemu- prefix
<jcastro> I have the power to rename some of them
<jcastro> but mostly it's up to the person who filed it to fix it
<apw> i wonder if we should have a report or script which spams people if they are using a stoopid prefix
<jcastro> well, theoretically if you file a blueprint most people check after a while to see if it got scheduled
<cking> jcastro, how does one see if a blueprint is scheduled?
<jcastro> cking: check the schedule with the track view: http://summit.ubuntu.com/uds-n/track/hardware/
<cking> jcastro, hrm, so any idea why my bp is not there?
<jcastro> cking: link?
<cking> https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements
<cking> back in a mo - kids...
<jcastro> cking: ah, it hasn't been approved yet that's why
<jcastro> cking: apw, ogasawara, or pgraner needs to accept it
<apw> cking, jcastro done
<jcastro> ta
<jcastro> apw: that's basically it, ensure the sessions are accepted and they'll autoschedule
<cking> apw, ta
<jcastro> apw: the cron job runs hourly to autoschedule btw, so accepting them won't show up right away. During UDS it will run much quicker.
<apw> jcastro, no worries ta
<cking> thanks jcastro
<cking> sconklin, http://www.youtube.com/watch?v=4YZeX8ti7Io&feature=player_embedded
<sconklin> cking: fun!
<cking> sconklin, makerbot + lego = fun :-)
<sconklin> there's a new model of the makerbot out with a conveyor which dumps completed objects from the build platform, so you can make multiple copies
<cking> nice
<apw> jcastro, ok there was some confusion on linaro as to what to do, so they have some cleanup todo ... when thats done i should be able to approve the right ones in short order
<jcastro> rock and roll
<lucent> smb: Yeah, glad to hear it's on the radar. Discussion with Stefan Richter proved out and I found the commit which broke my firewire setup. 
<smb> lucent, Yep, saw his mail today and also a pull request for Linus for .36
<lucent> it's kind of ... I don't get star struck but hey having my first and last name on something being submitted to Linus Torvalds, kind of makes me feeling shy in a hurry
<smb> Its the kind of thing that makes the whole thing running. :)
<lucent> yes, I see :)
<lucent> there's one more regression I want to address soon, in the mct_u232 usb serial module
<lucent> do you know who I would begin discussion with about that?
<smb> Hm, usb serial may be big GregKH... You could either check in git who normally is the last one signing of that driver or in the MAINTAINERS file (to find mailing lists)
<lucent> got it, thanks
<smb> So yes, seems to be him and/or linux-usb@vger.lernel.org. And a good backing is when you can say you tried one of the mainline (very recent) kernels and its still broken. Did I tell you where to find the mainline kernel. Forgot whom I already told
<smb> lucent, ^
<lucent> thank you, and yes I have been testing with mainline to do rough bissection
<smb> ok, cool :)
<lucent> my last question about the kernels is when I build a custom kernel, how do I change the version so that it is unique when I install the resultant deb packaging?
<lucent> there were "new" and "old school" methods described on the Ubuntu wiki
<lucent> the "new" method does not say how to set my own versioning
<lucent> say, "DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic"
<smb> What I usually do is modifying the first line in debian.master/changelog to have an extension like "+debug1" or so
<lucent> okay, by modifying the file, and not an environment variable?
<smb> right
#ubuntu-kernel 2010-10-19
 * smb yawns
<amitk> smb: \o
<smb> amitk, Dude!
<smb> Still alive? :) I saw you ride the same plane to Orlandi
<smb> o
<amitk> smb: cool, will see you in frankfurt on sunday then...
<smb> Yep
<amitk> I guess that will be one of the "ubuntu" flights
<smb> Well I think I only saw ogra on the same flight. But searching the wiki is kind of error prone. And it does not show the non-canonicals
<smb> At least it reaches cab allowance mass. :)
<amitk> heh
<apw> amitk, hey
<amitk> apw: howdy?
<apw> i hear you are linaro power management dude, checking you have the abilty to sort out getting your blueprints accepted
<apw> you have a lot sitting on the queue for uds-n, but not yet waved through to the agenda.  i can help if not
<apw> amitk, looks like you have 25 blueprints proposed, at the moment
<smb> apw, speaking of those, what was the sort of target we wanted the proposed testing one be? We spoke about that but I already forgot
<amitk> apw: I'll have to remove all the proposals except the 4 that are correctly named
<apw> smb, i think we thoguht it should be a qa one really, maybe we need to look at marjo's ones to see if there already is one to go to or see if he wants to take it on
<amitk> apw: or are you talking about all of linaro?
<apw> amitk, i am talking about just the ones with your name on ... i assume most are just tracking prints to hold work items and don't need sessions?  i can accept/reject them for uds-N if you can't; if you tell me the four that need sessions i can sort out getting those in and the rest off the agenda
<smb> apw, Ok. Want me to sent him an email?
<apw> amitk, to get them on your work items list you need to get them series-goal of natty rather than sprint of uds-n ... if that makes sense
<apw> amitk, overall i've been asked to help linaro clean up their blueprints so we can see the wood for the trees on the blueprint queue as you all seem to have proposed all of your blueprints rather than just the ones needing sessions
<amitk> apw: my 4 blueprints that I care about start with "hardware-linaro-n-meta-"
<amitk> apw: everything else doesn't require a session
<apw> amitk, excellent ... happy for me to run through them and sort the sessions out then ?
<amitk> apw: and for those 4, I want back to back double sessions, one per day
<amitk> apw: yes please
<apw> amitk, sadly i am not able to target things in linaro projects to natty series-goal, you need a linaro 'driver' for that
<amitk> apw: I can do that (only for the 4, right?)
<apw> amitk, if you want the blueprint to carry work items which show up on the burn-down stuff then that blueprint needs a series-goal, likely thats all of them ... presume you using blueprints as 'jobs to do' prints
<amitk> apw: yes, but we have our own "project" - linaro-pm-wg (https://edge.launchpad.net/linaro-pm-wg) with our own series and milestones
<amitk> and natty doesn't show up in that series
 * apw realises there really should be a like #ubuntu-uds channel like #ubuntu-release where you can find help with things and discuss things like this
<amitk> we also have our own burn-down infrastructure
<apw> amitk, ah good point
 * apw looks where the are looked for in your burndown
<amitk> apw: http://people.canonical.com/~pitti/workitems/linaro-pm-wg/all.html
<apw> amitk, oh you may be ok actually it may not be tied to a release
<apw> then you'd not need to target them all, and you save loads of effort!
<amitk> apw: we've had to shoehorn of lot of stuff to fit into the ubuntu-way for uds though we don't strictly follow the milestones and processes
<apw> yeah i bet, the process doesn't fit snugly for us where it was designed for
<amitk> apw: so will you reject everything but the 4?
<apw> amitk, working on it now
<amitk> apw: many thanks and a beer pledge :)
<apw> amitk, nice :)
<apw> amitk, do you have the names of the four you wanted accepted, i only saw two on the way through
<apw> so i can double check they are right
<amitk> apw: https://blueprints.edge.launchpad.net/linaro-pm-wg (The first four in there marked essential)
<apw> amitk, so you personally only have 1 session (2 hours)
<apw> ok all of those first 4 are accepted, i'll see about getting them 2 hours next
<amitk> apw: yeah, others have been assigned to those metas. And if you could, please spread around the double slots so that one is in the morning session, one in afternoon, etc. And only 1 session per day. And start the monday session in the afternoon.
 * amitk believes a #ubuntu-uds helpdesk is definitely called for...
<apw> amitk, heh if they were even on the agenda at all we'd be looking better, looks like the importer is stuck
<amitk> bi-annual circle of pain
<apw> i know ... so much stuff is other- i think it broke
<smb> big badaboom?
<amitk> badaboom
<smb> So we probably need someone who knows how to negotiate... ;-P
<apw> amitk, ok ... currently your 'prints arn't making it into the scheduling system, something todo with a filter ... they are working on it and hope to have it fixed today
<amitk> apw: ack, thx
<apw> amitk, now who can i talk to about the toolchain linaro prints
<amitk> michaelh1 on #linaro
<apw> what timezone is he ?
<amitk> NZ, I'm asking if he's around
<amitk> likely not
<apw> amitk, seems late there for him
<apw> amitk, i see that michael has actually named a subset of his blueprints foo-linaro-n-*, so i think i can just accept the ones in that form and reject the rest 
<apw> amitk, trying to debug this issue with the blueprints, could you move https://blueprints.edge.launchpad.net/linaro-pm-wg/+spec/hardware-linaro-n-meta-pm-tools to 'Drafting' or 'Discussion'
<amitk> apw: i remember him mentioning doing the renames
<amitk> apw: marked all four as discussion
<apw> amitk, does http://summit.ubuntu.com/uds-n/track/hardware/ look like what you intended
<amitk> apw: almost - can you interchange cpufreq with multicore? (thursday and monday)
<apw> amitk, you bugger ... 
<amitk> apw: I hope it doesn't involve hacking assembly code :-p
<apw> amitk, nope ... which on monday ... i've got them both off now
<apw> and forgotten which was which already ... doh
<amitk> apw: lol, so cpufreq on monday and multicore on thursday
<apw> amitk, how about that
<apw> sadly you have to use the day views to move things at the mo (due to a bug) so three windows are involved
<apw> amitk, its a good job we are doing these long ones now, its not easy to get them in
<apw> even this early
<Ampelbein> hi there! For a lcd-display driver I need the usbhid_modify_dquirk symbol address, but I can't seem to find it in /boot/System.map. Can you point me in the right direction on where to look?
<apw> Ampelbein, which release are you trying to find it in
<amitk> apw: looks good!
<Ampelbein> maverick, 2.6.35-22-generic
<apw> Ampelbein, in maverick it is a static function so its not exported at all
<apw> amitk, keep your fingers crossed people leave them alone
<apw> i don't think i can lock them or anything
<apw> Ampelbein, also was static in lucid
<Ampelbein> apw, ok, that means kernel patching for me then :-( thanks!
<apw> amitk, as it is so hard to get things scheduled i am going to assume that the toolchain ones which are named correctly are the ones he wants in and the others not, and he can correct them if not afterwards
<apw> else there will be no slots for them left
<apw> smb, have you marked your participation (particularly essential ones) on your blueprints, being the owner or assignee or anything else has no effect on the attendance thing
<smb> smb, No; I guess I should do so now
<smb> apw, And probably I should stop talking to myself
<JFo> lag, morning... reading the e-mails and thread on the subject now :)
<JFo> my only concern is that I will be in Cambridge for Plumbers that week
<JFo> will you be there too?
<apw> JFo, i think he wandered off
<JFo> ah
<JFo> morning apw 
<JFo> :)
<apw> morning JFo 
<lag> I'm back
<JFo> lag, will you be at Linux Plumbers?
<lag> Yeah :(
<JFo> so yeah, we'll both during that meeting :)
<lag> That's gonna suck
<JFo> shrug* :)
<JFo> so yeah, 4AM to 4:45AM then
<JFo> since they are exactly 12 hrs off from this TZ
<lag> Ouch
<JFo> yours is 3:15 to 4 AM
<JFo> if we keep that schedule
<JFo> meaning, if we are present for the whole thing, we will have been up all night
<JFo> :)
<JFo> yay!
<lag> Get the coffee on the go
<JFo> yup
<JFo> and get in bed early that next night :)
<JFo> I've responded to his e-mail
<JFo> so we shall see
<JFo> only thing I see possibly impacting us is if we need to call in to them
<JFo> but I am sure we can work around that
<lag> Skype
<JFo> yep :)
<persia> apw, My opinion (which I think I've stated before) is that we ought just have powerpc be in the main kernel, to avoid config issues and scheduling issues.
<persia> I understand that this may not happen, for workflow reasons.
<persia> I'll continue to want it discussed each UDS until I don't notice differences in kernel function between architectures, but I don't have any strong expectations about conclusions.
<apw> persia, right now about the only thing thats not in the main kernel is the meta package, so yes that is on my agenda at the moment
<persia> I thought so, from the spec name.  Just figured I'd make sure when you raised that spec in another context.
<apw> cool on the same page then
<persia> Never doubted it :)
<lyhana8> please patch is to be done on fglrx kernel module to compile again on kernels with CVE-2010-3081 fixed
<ubot2> lyhana8: The compat_alloc_user_space functions in include/asm/compat.h files in the Linux kernel before 2.6.36-rc4-git2 on 64-bit platforms do not properly allocate the userspace memory required for the 32-bit compatibility layer, which allows local users to gain privileges by leveraging the ability of the compat_mc_getsockopt function (aka the MCAST_MSFILTER getsockopt support) to control a certain length value, related to a "stack pointer
<lyhana8> need for ubuntu 10.04
<dupondje> could somebody take a look @ https://bugs.launchpad.net/bugs/604122 ?
<ubot2> Launchpad bug 604122 in linux (Ubuntu) "mmc0: Got command interrupt 0x00030000 even though no command operation was in progress. (affects: 2) (heat: 14)" [Undecided,Confirmed]
<JFo> dupondje, looking
<apw> lyhana8, i thought that that was fixed already ... tseliot <--
<tseliot> apw, lyhana8: yes, that was done some time ago
<apw> tseliot, thought so ... lyhana8 do you have -updates enabled on this system
<dupondje> JFo: revert https://lists.ubuntu.com/archives/kernel-team/2010-May/010660.html, and it works again. So something must be broken in the sdhci driver ?
<JFo> I was wondering about that. it is affected only by the config change yes?
<dupondje> seems so
<JFo> odd
<JFo> apw, if you get a sec, could you take a look at bug 604122
<dupondje> its quite annoying, as it makes SD cards useless on my computer now :s
<ubot2> Launchpad bug 604122 in linux (Ubuntu) "mmc0: Got command interrupt 0x00030000 even though no command operation was in progress. (affects: 2) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/604122
<JFo> dupondje, I can imagine
<JFo>  or lag ^^
<JFo> if one of you are available
<dupondje> the weird thing is that it sometimes works, sometimes not ...
<JFo> that is odd
<JFo> so if you change the config it works all the time?
<JFo> just wanting to have it clear in my head :)
<lag> I can take a look
<smb> JFo, apw dupondje Though what the option does is to activate some code do disable some controller which otherwise inteferes with the generic driver. Does this really work with the option disabled?
<dupondje> well I reverted that change, and then it worked without issues. Can try it again (was somewhere in the development stage of maverick) :)
<JFo> dupondje, that would be awesome if you don't mind
<dupondje> wait :) i'll boot my quadcore ^^
<JFo> cool, thanks :)
<smb> lyhana8, For that compile failure all the ubuntu packages should be fixed by now.
<dupondje> btw, can I build kernel with pbuilder ?
<apw> ogra, does https://blueprints.edge.launchpad.net/ubuntu/+spec/hardware-arm-n-omap-edid-autodetection need a UDS session ?
<dupondje> building, gtg now, back in a hour :) then building will be done I guess also
<lyhana8> smb: since when? cause I tried yeasterday and it wasn't working on Linux Mint 9 = Ubuntu 10.04
<smb> lyhana8, tseliot has uploaded packages the week after that security update went out
<smb> tseliot, I forgot the dkms package name again display-drivers something?
<tseliot> smb: fglrx-installer
<lyhana8> what is the package version I should look for?
<tseliot> lyhana8: four weeks ago I uploaded 2:8.723.1-0ubuntu5 which contains the fix
<smb> tseliot, Is that Lucid?
<tseliot> lyhana8: if you don't have it, it's likely that you don't have -updates enabled
<tseliot> smb: yep
<tseliot> here you can see the source for each version of Ubuntu: https://launchpad.net/ubuntu/+source/fglrx-installer
<tseliot> it was bug 642518, BTW
<ubot2> Launchpad bug 642518 in linux-restricted-modules-envy-2.6.24 (Ubuntu Karmic) (and 14 other projects) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx (affects: 283) (dups: 240) (heat: 2098)" [Undecided,Invalid] https://launchpad.net/bugs/642518
<smb> tseliot, That probably confused me because the binary is called differently
<tseliot> lyhana8: or maybe you installed a more recent version of the driver and you're not getting the update because of that
<tseliot> smb: yes, the binary is just fglrx
<smb> tseliot, Which is what lyhana8 has to look for in dpkg -l :)
<lyhana8> I got the right version 2:8.723.1-0ubuntu5
<lyhana8> smb: I got:  fglrx-modaliases                      2:8.771-0ubuntu1
<tseliot> lyhana8: 8.771? I'm wondering where you took that from
<lyhana8> the binary package probably. I tried to compile from their .bin
<lyhana8> s/.bin/.run/
<tseliot> lyhana8: try with "sudo apt-get --purge remove fglrx" and then "sudo apt-get install fglrx" and let me know if there are any errors
<tseliot> lyhana8: if there are errors, I'd like to see them
<apw> slangasek, you have a number of other-linaro-* blueprints, just confirming that they all need sessions ?
<lyhana8> tseliot: my problem was that install the fglrx driver trigger this error: http://pastebin.com/3QbWsruq
<tseliot> lyhana8: it's not the same problem then. The security update prevented the fglrx module from compiling.
<lyhana8> tseliot: those log are from yesterday, I didn't get any error installing fglrx fglrx-amdcccle
<lyhana8> (just minutes ago)
<tseliot> lyhana8: that confirms my theory. It must be something else
<lyhana8> tseliot: well it may be that the fglrx package in the repo isn't the good version
<tseliot> lyhana8: no, it can't be that. It's a completely different problem
<tseliot> lyhana8: please file a new bug report about it
<lyhana8> my card is a Mobility radeon HD 5470, which is supported by ati driver 10.9
<slangasek> apw: the ones that are targeted to uds-n should be the ones that need sessions, yes
<apw> slangasek, cool, most of your fellow creators have made all of their blueprints targeted to uds-n
<apw> (probabally due to the create link they used)
<slangasek> more likely due to it being their first time through the process and not having thought through whether each blueprint needs a session
<slangasek> strangely, I don't see any way to *un*target a blueprint to a sprint
<JFo> ok, stepping away for a bit. I'll be back around in a bit.
<avinashhm> hi, is there any way to remove windows line ending from patch .. [^M] .. i tried fromdos and :s/^M//g .. .but after this, my patch isn't applying .. any help ...
<smb> avinashhm, to do s/<ctrl-v><ctrl-m>$//g should work. But maybe there is more broken than line ending? Like linebreak added by mailer
<avinashhm> smb, but number of lines still are same .. but some how something is getting disturbed .. not sure ..
<bjf> avinashhm, meld is a good tool to look at the differences between two files, it might help
<smb> avinashhm, Would you be 100% it was ok with the ^Ms. It could have been broken when sending, before you received it
<avinashhm> bjf, ... hmmm.. let me try it now ... 
<avinashhm> smb, .. possible ... :-) ...
<cking_> dos2unix works well in munging windows line endings to UNIX convention
<avinashhm> cking_, yep ...  i suppose now a days its known as fromdos .. .[ package of tofrodos ] ...
<dupondje> I tried to build kernel with pbuilder, but now I get: EE: Previous or current ABI file missing!
<dupondje> any ideas guys ? :)
<kamal> dupondje: ah, the dreaded (but very very common) ABI check failure ... this will help:
<kamal> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<kamal> or
<kamal> https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
<kamal> find "ABI" on those pages to read about how and why you need to disable the ABI check.
<kamal> dupondje: specifically for pbuilder builds, the "skipabi=true" method won't work for you ... you'll need to touch the 'ignore' files as directed in https://wiki.ubuntu.com/KernelTeam/KernelMaintenance section "Overriding ABI check failures" item #2.
<manjo> JFo, !!! you on mumble?
<JFo> manjo, nope, do I need to be?.
 * ogasawara lunch
<cking_> time to call exit(EXIT_SUCCESS) on another day
 * jjohansen -> lunch
<Edgan> Anyone knowledgeable about realtime kernels in the channel?
#ubuntu-kernel 2010-10-20
<papillon81> hi. i'm looking for Ike Panhc. is he usually here?
<jjohansen> papillon81: he is usually around a little later, try back in 3 or 4 hours
<papillon81> jjohansen: i'll probably be in dreamland by then, but will be back later...
<jjohansen> papillon81: well try again a little later, I am not sure how early he will be on
<papillon81> thx
<papillon81> ikepanhc: ping
<ikepanhc> papillon81: hi
<lucent> more kernel regression fun
<lucent> I have to wonder if any of my hardware functions better with the 2.6.35 release, or if it all regressed / stayed the same
<lucent> so many improvements that I did not test (with enough time to submit bugs) before the stable release, sigh
<smb> lucent, If any of the things work better with the most recent 2.6.36 mainline kernel, there is a chance that things simply improve soon. There are already two stable updates pending and a third one on the horizon for Maverick.
<lucent> smb: good news is good :)
<apw> https://blueprints.edge.launchpad.net/sprints/uds-n
 * cking reboots
<papillon81> ikepanhc: hi. I tested your patches and ideapad-laptop seems to get loaded now. however, when I press buttons I only get kernel messages in dmesg from atkbd "unknown key pressed". should it already switch on/off the WIFI and BT?
<ikepanhc> papillon81: it means when key pushed, EC will send at keyboard scancode
<papillon81> ikepanhc: ok, but does the switch do some real witching in the background? or is this yet to be implemented?
<ikepanhc> papillon81: as I know, when event happened, driver will generate KEY_WLAN and applications will turn on/off rfkill
<papillon81> ikepanhc: ok, I'll test that next
<ikepanhc> papillon81: which ideapad-laptop you use?
<ikepanhc> papillon81: the first one I post on LKML?
<papillon81> ikepanhc: ideapad s12 nvidia ION
<papillon81> ikepanhc: ah, sorry
<ikepanhc> papillon81: I mean the driver source code
<papillon81> ikepanhc: i#M using the code in 2.6.36-r8 (latest git) plus your changes from your git
<ikepanhc> papillon81: those patches only has rfkill part
<ikepanhc> papillon81: I am planing to write hotkey part and will update on my git and post to LKML
<papillon81> ikepanhc: sounds good
<papillon81> i'll observe your git
<ikepanhc> papillon81: and please let me know if you find out there are any bugs or anything you would like to discuss
<papillon81> sure, that's why i'm testing it
<papillon81> :)
<ikepanhc> :)
<JFo> manjo, sorry I missed your ping yesterday
<JFo> you still need to talk to me?
<manjo> np
<manjo> ;=
<manjo> 0
<JFo> :)
<avinashhm> hi, i am trying to use dump() to dump the stack trace ... Is there any header file, which i need to include ??
<tgardner> apw, ima: use of radix tree cache indexing == massive waste of memory
<avinashhm> its dump_stack() .. so i was using the wrong api .. 
<komputes> JFo: smb: Could you please look into correcting Bug #530277 or mark it wontfix adding your notes on why it is not possible to correct this issue. It's a shame if we can get this hardware working on a certified machine.
<ubot2> Launchpad bug 530277 in linux (Ubuntu) "0cf2:6250 ENE Technology, Inc. card reader not supported (affects: 41) (dups: 4) (heat: 202)" [Medium,Confirmed] https://launchpad.net/bugs/530277
<smb> komputes, You seemed to have found the explanation in some other but. Wasn't that clear enough. Not sure who certified it, but you cannot add support to a usb device with vendor specific protocol without knowing what that would be
<komputes> smb: I didn't quite understand what you said there, no. sorry.
<komputes> smb: acer certifies their computers with canonical, any chance of being able to get that info through cr3
<komputes> smb: the "vendor specific protocol" bit i mean
<smb> komputes, Normally card-readers act like usb storage devices. So you do not need a special driver. But this one only tells you to use a vendor specific protocol. That can be anything. So you would need a special driver for that hardware. And for that you would need specs
<smb> komputes, And for the cr3 part. Shouldn't you happen to be very close to him? ;-)
<komputes> smb: extremely, would you like me to try and get a contact with the manufacturer so we can look into correcting this?
<smb> komputes, Frankly, are we getting paid for that?
<komputes> ;)
<komputes> smb: I'll let you know
 * smb suggests to let the HWE team know
<komputes> smb: who leads that?
<cking> komputes, hughhalf
 * manjo going down for a reboot 
<tgardner> bjf, how long does daily-iso-builder.sh normally run?
<tgardner> on tangerine, that is
<bjf> tgardner, i've not paid much attention but wouldn't think more than 30 minutes max
 * jjohansen -> lunch
 * ogasawara lunch
<pgraner> apw, you about?
<lag> Not seen him for a while
#ubuntu-kernel 2010-10-21
<proverse> I think I have a regression between 2.6.36-rc7 and -rc8 regarding wifi, not sure where to writeup the bug or what would be needed
<proverse> anyone avail to help?
<proverse> also what is drm-intel-next ?
<papillon81> ikepanhc: hi, I tested ideapad-laptop. Almost all special buttons worked. what did not was the wifi/BT switch and the Play/Pause, Stop, FF, REW buttons
<ikepanhc> papillon81: I guess the brightness/volumn control, touchpad switch, works fine
<ikepanhc> papillon81: those key enabled because of BIOS (DSDT) or they will generate an keycode
<ikepanhc> papillon81: they are not enabled by ideapad-laptop yet
<papillon81> ikepanhc: yes, they work
<papillon81> IIRC, the Camera switch is also working without ideapad-laptop
<papillon81> ...let me check
<ikepanhc> papillon81: ya
<ikepanhc> papillon81: the camera key just power on/off the camera, you can try to press the key and use dmesg to check
<ikepanhc> papillon81: usb camera will disappear and reappear
<papillon81> ikepanhc: well, it looks like most of it works without the driver already
<papillon81> the play/pause... keys do not as they produce no key event
<papillon81> wifi produces an event, but no connection/disconnection happens
<ikepanhc> papillon81: how you see the event? from dmesg which says unknown scancode?
<papillon81> ikepanhc: yes
<ikepanhc> papillon81: oh, some ideapad model will report scancode when hotkey pressed, but not all of the ideapad
<papillon81> BRB
<lag> Morning smb
<lag> Hi ikepanhc :)
<smb> lag, morning
<ikepanhc> good morning .eu
<lag> :)
<lag> Are you packed and ready for UDS
<ikepanhc> me? not yet
<ikepanhc> I am used to pack 6hrs before departure
<ikepanhc> and hope nothing missed
<ikepanhc> s/hope/pray for/
 * abogani waves all
<lag> :)
 * apw waves to ikepanhc 
<apw> ikepanhc, can you point me to the oem public trees
<ikepanhc> git://kernel.ubuntu.com/hwe/oem-master.git
<apw> ikepanhc, thanks :)
<ikepanhc> apw: :)
<abogani> By the way the natty-meta package contain a typo in README file at line 6.
 * smb spots gkh signs
<apw> boing
<smb> Not so much "boing" than "whoosh" (or how would a erupting volcano sound?)
<cking> eh?
 * smb is causing confusion by merging two statements hours apart on irc
<tgardner> apw, are you working on a 2.6.36 final for natty? I can do it if you're busy. then we can leave natty alone for a few weeks.
<smallfoot-> when put 2.6.36 in ubuntu?
<smallfoot-> when put in ppa?
<apw> tgardner, will do it :)
<lag> JFo: 
<JFo> lag
<JFo> :)
<lag> What do we do?
<lag> Where do we go?
<JFo> no idea
<smb> clueless
<JFo> was wondering that myself
<smb> as the rest of us
<lag> Good job we had this test :)
<JFo> indeed
<lag> This could have been the real thing
<lag> smb: No
<lag> smb: We have a video conf call
<smb> lag, "We" have not
<smb> :)
<JFo> lol
<JFo> lag, you see that ping?
<JFo> just invited you lag
<komputes> JFo: I would like to compile my own kernel as MTecknology posted on his latest blog post. Are you or is anyone able to walk me through this or point me to a guide which tells me the best way to do this on Ubuntu?
<komputes> MTecknology: btw, I can't find the .config for kernel options on http://profarius.com/content/what-you-need-do-after-installing-ubuntu-1010
<JFo> komputes, there should be some information in the /Kernel wiki pages at wiki.ubuntu.com/Kernel
<JFo> let me know if you have trouble finding them
<komputes> JFo: ok, wel thanks to ogasawara and the LPI201 study guide, I know the basics. But I will try my best to do this without being too much of a pain. :-)
<JFo> heh, no problem :)
<sconklin> the maverick distro master branch has been updated with the merge of the security release. Thanks to Brad for doing this.
<MTecknology> komputes: ?
<MTecknology> oh
<MTecknology> komputes: http://profarius.com/sites/profarius.com/files/kernel.config
<MTecknology> komputes: keep in mind that it's created by a psycho
<MTecknology> komputes: It wasn't listed at the bottom of the page for you?
<komputes> MTecknology: wow, right on time. cheers and congrats on the engagement
<komputes> nope
<MTecknology> komputes: thanks :)
<MTecknology> I'll look into why.
<komputes> MTecknology: do you recommend any particular build method from here for doing this: https://wiki.ubuntu.com/Kernel/Dev
<komputes> MTecknology: if you can add the commands you used to your post, I would find it extremely helpful.
<MTecknology> komputes: make menuconfig; make all install
<MTecknology> komputes: I said phsycho :P If you're looking to do it the 'right' way, then you probably want to not follow my advice :P
<komputes> MTecknology: where to I place the config, can I see your config file in curses menu view?
<komputes> I'm experimenting, no worries
<MTecknology> ls -a
<komputes> MTecknology: are you asking for a listing of the kernel source dir?
<MTecknology> komputes: no
<komputes> k
<MTecknology> komputes: that's where the .config is
<komputes> err. where?
<komputes> top level of the kernel source?
<komputes> sorry, I'm a virgin at this
<komputes> many attempts, never success
<komputes> JFo: MTecknology: "make menuconfig" returns the error "Requires ncurses-devel" but the correct package name is libncurses5-dev
<MTecknology> komputes: actually.. ncurses-dev
<komputes> oh, ok
<komputes> MTecknology: ncurses-dev is purely vityual pounting to libncurses5-dev ;)
<komputes> virtual*
<komputes> should we report to make a change to the error (from ncurses-devel to ncurses-dev)
<MTecknology> komputes: it's not an error
<MTecknology> komputes: other package managers use the virtual package ncurses-devel, for some that is the package
<komputes> ok
<smoser> hey. so, i'm trying to figure out what changed between 'linux-image-2.6.32-308-ec2 2.6.32-308.16' and 'linux-image-2.6.32-309-ec2 2.6.32-309.18'
<MTecknology> You're not dealing with something that's ubuntu-centric, it's linux-centric :)
<smoser> looking a the changelog for the newer version http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-ec2/linux-ec2_2.6.32-309.18/changelog
<smoser> it does not even include 2.6.32-308.16
<komputes> understood.
<smoser> i'm guessing that the entries for 2.6.32-309.17 and 2.6.32-309.18. but programmatically, that would be difficult to determine since i can't locate the source version in the changelog
<smb> smoser, Some upload versions can get eradicated when security replaces a version in proposed
<smoser> it seems that that entry got dropped
<smoser> the changelog entry got dropped though
<smoser> both those versions did exist
<smoser> http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-ec2/linux-ec2_2.6.32-308.16/changelog 
<smb> If it did not leave proposed it did not officially exist
<smoser> it did leave proposed
<smoser> (it made it into an image created 20100923 that do not include -proposed in their sources.list)
<smb> smoser, Hm, right. .16 would actually have been a security release
<smoser> i'm guessing its just human error, and also that only the changelog entry for 2.6.32-308.16 was dropped, and not actually the changes.
<smb> If I am not wrong and the .16 was a security update, then those changes should normally not get dropped when rebasing to a newer version of the master kernel
<smoser> 308.16 was a security release. 
<smb> Yes, so I am quite confident that this is just an error within the changelog
<smoser> i'm not trying to be accusing, i'm just wanting to make sure that there isn't a hole in the process that dropped those security fixes.
<smoser> and ideally, that in the future, even the changelogs wouldn't get dropped
<smoser> i'm trying to write a tool that shows me what differed between two builds, and want to grab new changelog entries.
<smb> Right. The rebasing itself is safer than the changelog because that needs manual intervention to get it right
<smoser> right. humans are incompetent
<smoser> :)
<smb> Agreed :) But in general it could get difficult to compare changelogs
<smb> Its already sometimes confusing for the master tree. But rebase branches are worse
<komputes> MTecknology: My docs says Kernel configuration settings are stored in a file named .config. Historically, this file was saved within your kernel source to /usr/src/linux or /usr/src/linux-kernel-version, but this is no longer the case. Older applications (based on the standard libc) required /usr/src/linux, but the introduction of a new library, glibc, eliminated that dependency. So I simply placed it in the linux-2.6.35-MTeck/ dir and r
<komputes> an "make menuconfig" and I'm now going through all the changes you made. Very cool :-)
<komputes> Especially cool with split screen terminal
<smoser> thanks smb . just kindly take note of my "please try to get changelog entries correct" request.
<MTecknology> komputes: there's also make xconfig, but I think menuconfig is better
<smb> smoser, note taken
<smb> :)
<komputes> MTecknology: I'm aware of these ways to do it: make config, make menuconfig, and make xconfig
<komputes> MTecknology: menu is still my favorite
<komputes> MTecknology: few questions about disabled configurations: pass kernel param to init, LZO vs Gzip kernel compression, POSIX msg queue, BSD process accounting, export task, namespaces - how can i better understand what these are and what is the result of disabling them?
<MTecknology> komputes: look at the help for it
<MTecknology> komputes: then look at the code or online
<komputes> MTecknology: ok, help wasn't working, but I found it - not quite english, but I kind of understand
<komputes> MTecknology: do you remove upstart from your system and simply use init?
<MTecknology> komputes: nope, upstart is still there
<komputes> MTecknology: and disabling CONFIG_INIT_PASS_ALL_PARAMS does not mess that up?
<MTecknology> komputes: I didn't say upstart still worked the way it's supposed to :P
<komputes> muahahaha
<maakri>    
<anarsoul> hi there
<anarsoul> what's sane way to load custom DSDT table in ubuntu 10.10?
<anarsoul> DSDT table for my laptop is broken (thermal and battery methods are incorrect) and so I need to load my custom DSDT
<apw> anarsoul, as i recall things there is no offical way to do that, as you can brick your laptop
<mjg59> anarsoul: Incorrect in what way?
<apw> i believe the approved approach is to quirk round the deficienies
<anarsoul> mjg59: thermal provides incorrect info about CPU temperature (sometimes stick at 70C and fan works all this time)
<anarsoul> and battery method provides some heuristic info about capacity instead of get this info from smart controller
<anarsoul> so it's dangerous to use laptop on battery with default DSDT table
<mjg59> apw: Well, approved approach is for people to either get the bugs fixed in Linux or, if Windows has the same behaviour, return the hardware for being broken
<anarsoul> as it can kill battery because it can't detect correctly when it's broken
<anarsoul> mjg59: windows has the same behaviour
<apw> mjg59, well put
<anarsoul> and I can't return this hardware
<mjg59> anarsoul: Your hardware's broken, then!
<anarsoul> it's 3year old laptop
<mjg59> There's an interface in debugfs that lets you override individual ACPI methds
<anarsoul> mjg59: wrong answer
<anarsoul> it works with fixed DSDT table
<anarsoul> mjg59: yeah, I know, it does not fit
<mjg59> Then you get to build your own kernel
<anarsoul> as it can override only methods
<anarsoul> but I need to override OperationRegion aswell
<anarsoul> mjg59: I remember there was a patch that allowed to load custom dsdt from initramfs
<anarsoul> why it was removed?
<mjg59> anarsoul: It got rejected upstream
<anarsoul> so what?
<apw> anarsoul, because people would load random dsdt's into their system
<anarsoul> ubuntu keeps much their custom patches
<apw> anarsoul, where someone on a bug suggested a mod for a different system
<anarsoul> why not to keep another one?
<apw> anarsoul, and as you can do genuine dammage to your system 
<apw> anarsoul, it was seen as too dangerous
<anarsoul> apw: you can damage your system by overriding acpi method via debugfs
<apw> anarsoul, indeed that is also true
<apw> but that was the reason the patch wasn't maintained
<apw> too easy for a naieve user to follow instructions to try and modded dsdt on the wrong laptop
<anarsoul> apw: oh, it's easy to do "sudo dd if=/dev/urandom of=/dev/mem"
<mjg59> anarsoul: If you're competent to modify ACPI tables then you're competent to rebuild your kernel
<apw> anarsoul, yep you can shoot self in the foot a number of ways, but people seemed to like loading random dsdts that fixed things for other people
<anarsoul> mjg59: yeah, but it takes my and cpu's time
<apw> anarsoul, its all a balance
<anarsoul> mjg59: and I can't react on each security update
<ppetraki> hi all
<ppetraki> quick question
<ppetraki> is  echo 1 > /proc/sys/kernel/panic_on_oops supposed to work?
<ppetraki> cuz it's not panicing :)
<tgardner> ppetraki, try /proc/sysrq-trigger
<komputes> MTecknology: at the end of the compilation, I get many errors relating to ndiaswrapper. Do you know which path in the menu config I need to go to disable the ndis (module?).
<ppetraki> tgardner, Tim, the goal is to panic on some mysterious oops we've been seeing, the systems are unattended
<MTecknology> komputes: press / and search
<tgardner> ppetraki, well, I think you can do that from user space. see Documentation/kdump/kdump.txt in the kernel tree
<ppetraki> tgardner, I'll take a closer look, thanks
<komputes> MTecknology: found it but once i press exit i do not know the path to get to it
<komputes> MTecknology: it brings me the help page only - can't turn it on/off
<MTecknology> komputes: you need to follow the path it gives you
<komputes> MTecknology: awesome, thanks
 * ogasawara lunch
<komputes> MTecknology: OK! :-)   I finally finished compiling, no errors. I had to change compression (gzip) and strip out rtl and ndis networking extras. So what now?
<MTecknology> komputes: you installed it?
<komputes> MTecknology: well I did "make all install" not quite sure what that accomplishes, but it looks like it finally compiled without errors
<MTecknology> update-grub2
<MTecknology> reboot
<MTecknology> you should read the Makefile
<komputes> orly? nice...
<MTecknology> don't remove the generic kernel until you really know what you're doing and know how to fix things when it breaks
<komputes> no, i don't inted to remove the ubuntu stock kernels at all
<komputes> and this is a scratch box
<komputes> MTecknology: I'm reading the makefile, you actually understand this?
<MTecknology> :P
<komputes> MTecknology: rebooted, kernel won't boot properly, when i run it in recovery mode I quickly see an error regarding VBIOS table
<komputes> it makes two short beep noises
<MTecknology> komputes: yup, that's the fun in compiling your own kernel :)
<MTecknology> komputes: look on the gentoo install manual and it'll help you start to understand it better
<komputes> MTecknology: will do. thanks for all your help today, what an adventure
<MTecknology> komputes: np, make sure to enjoy
<savasci> hi. I am taking an OS class in university, we did some kernel manipulation( adding a system call), after installing the new kernel, for every boot it says " starting up Uncompressing Linux... Ok, booting the kernel". does that means any problem, any way to avoid this uncompressing stage?
<komputes> MTecknology: I'm guessing it's one of the first three here: http://www.google.com/search?q=gentoo+install+manual
<sconklin> savasci: it's normal, and you want to leave it that way. The kernel in memory has a lot of zero-filled data, and compressing it makes it a lot smaller on disk
<sconklin> http://www.ibm.com/developerworks/library/l-linuxboot/index.html
<hyperair> hi. where can i find out more about ubuntu dropping support for things below i686?
<hyperair> it seems the lubuntu folk are pretty upset about this.
<JFo> ogasawara, just responded on that e-mail you forwarded
<JFo> sorry for overlooking that :-/
<ogasawara> JFo: no worries.  not sure how much help he'll turn out to be.
<JFo> every bit helps :)
#ubuntu-kernel 2010-10-22
<kees> ogasawara: who is driving the natty kernel?
<ogasawara> kees: apw and tgardner
<kees> okay, cool. I will subscribe them to my kernel-krack track :)
<ogasawara> heh
<bjf> ogasawara, my test build of armel has failed the modules check for omap, complaining that smsc911c is missing
<ogasawara> bjf: I can't remember, did one of the patches build in that module or maybe disable it?
<bjf> ogasawara, i'm trying to determine that, it's builtin now
<ogasawara> bjf: I want to say it was changed to being built in.  and I also want to recall I shoved in the file to tell it to then ignore the module check.
<ogasawara> commit 6de80403735ba5339a83895ac5591596aacf721e
<ogasawara> Author: Leann Ogasawara <leann.ogasawara@canonical.com>
<ogasawara> Date:   Tue Oct 5 11:35:37 2010 -0700
<ogasawara>     UBUNTU: ARM: Temporarily disable module check for armel
<ogasawara> commit a192fd144b602f72caece44ec2ff3dfaedf8d325
<ogasawara> Author: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
<ogasawara> Date:   Thu Sep 23 01:09:08 2010 -0300
<ogasawara>     UBUNTU: [Config] Remove CONFIG_FIXED_PHY and move CONFIG_SMSC911X from m to y for omap
<ogasawara> bjf: were the correct ABI files included when the next release was started?
<bjf> ogasawara, ok, will look at it later, pulled new abi files, probably related, the old abi tree was deleted
<bjf> ogasawara, the ignore file is in the abi tree so when I pulled down a new set and deleted the old, i lost the change you'd added
<bjf> ogasawara, good thing i did a test build (almost didn't bother)
<ogasawara> bjf: ah, makes sense then
<proverse> what is drm-intel-next folder / build in the kernel-ppa?
<RAOF> proverse: That's a build of the drm-intel-next kernel tree; it's the development tree for the intel drm module.
<proverse> drm is direct rendering something, yesno? worth trying with a core i3-350m (integrated graphics), especially since the i915 module is complaining with recent kernels (2.6.35+) ?
<RAOF> Yes, that's right.
<RAOF> What's the i915 module complaining about for you?
<proverse> hang on will get the dmesg lines
<proverse> [   13.613936] intel ips 0000:00:1f.6: Warning: CPU TDP doesn't match expected value (found 25, expected 35)
<proverse> [   13.613965] intel ips 0000:00:1f.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18
<proverse> [   13.614121] intel ips 0000:00:1f.6: failed to get i915 symbols, graphics turbo disabled
<proverse> [   13.614290] intel ips 0000:00:1f.6: IPS driver initialized, MCP temp limit 65535
<proverse> [   14.000308] agpgart-intel 0000:00:00.0: Intel HD Graphics Chipset
<proverse> [   14.001778] agpgart-intel 0000:00:00.0: detected 131068K stolen memory, trimming to 32768K
<proverse> [   14.078991] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
<proverse> [   15.303978] fb0: inteldrmfb frame buffer device
<proverse> [  998.652812] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
<proverse> the "failed to get i915 symbols..." seems to be the most telling line
<proverse> maverick beta circa september I was able to get 1400+fps in glxgears, smooth flash video playback, etc.
<proverse> recently its been about 60fps in glxgears and stuttering as well
<proverse> *stuttering video
<psusi> why would the kernel emit a change event for a disk partition?  I thought you got a change event for the disk itself when the partition table was changed, but I'm seeing change events on the partition for no apparently reason when lvm activates logical volumes, and this causes a feeback loop
<RAOF> proverse: So, 60fps in glxgears is because intel now has working vsync support - 60fps is exactly the expected value for glxgears FPS on most displays.
<RAOF> Secondly: that dmesg is just saying that the ips module won't do the dynamic overclocking thing for your GPU that the core processors can do.
<psusi> in udev that is
<jk-> smb: hey
<Ian_Corne> The latest kernel patch for natty doesn't fix the rds local root exploit
<Ian_Corne> just so you know
<Ian_Corne> it's fixed on lucid, maverick, karmic but not for natty
<lucent> not surprising, good to know as a user though
<Ian_Corne> why is it not surprising?
<Ian_Corne> it's patched for the other kernels..
<Ian_Corne> is there anything holding it back
<lucent> natty is not a stable release
<lucent> so why would it matter to fix a security bug?
<apw> Ian_Corne, yeah we don't generally stress about security issues in the development kernel as it should never be in production anywhere
<apw> and all of the fixes come down to us from upstream
<Ian_Corne> ok :)
<apw> got a pointer to the fix ?
<Ian_Corne> Guess I'm booting in 35 for the time being then
<Ian_Corne> I'll look it up
<apw> cirtainly before the first alpha we do not expect anyone to be really actually running the kernel in anger, especially when its in the -rc1/2 range as we jump between releases
<Ian_Corne> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=799c10559d60f159ab2232203f222f18fa3c4a5f
<Ian_Corne> Yeah I just upgrade as soon as I can always :)
 * lucent eyes the beginning of a facepalm forming subconciously in his own limbs
<apw> Ian_Corne, that seems to be in that latest natty tree
<apw> and therefore in the latest kernel ?
<Ian_Corne> hmm
<Ian_Corne> I just tried it on the .36-1 kernel 
<Ian_Corne> and the exploit worked
<Ian_Corne> I'll try again
<apw> which -1 kernel?  whats the full version number
<Ian_Corne> I'll check in a second
<Ian_Corne> ah there's another kernel update also with -1
<apw> yep, wasn't an ABI bumper, and it was very small update, so it wasn't worth the pain
<Ian_Corne> ok :)
<Ian_Corne> I'll try it asap
<apw> yes that fix is between -rc8 and final, so would be in .7 and not .5
<Ian_Corne> it was -1.6
<Ian_Corne> going to -1.7
<Ian_Corne> [*] Exploit failed to get root.
<Ian_Corne> :)
<BluesKaj> during update dpkg locks my system trying to install a kernel module/linix image that it can't find (2.6.32.24-generic) . Apt just sits there hungup.
<eagles0513875> and it seems the kernel he mentions is in lucid 
<BluesKaj> actually it's grub trying to regenerate a new .cfg file 
<cking> apw, you around?
<apw> cking, hi
<debarshi> I would like to use a driver present in linux-next.git, but not in the current Ubuntu 10.04 kernel. I would prefer to create a separate package for the module instead of having my own kernel package.
<debarshi> I have found out about Module Assistant, but I am not sure how to proceed.	
<debarshi> I am trying to extract the driver directory somewhere else and then create a package, but I am having trouble with the kernel make files.
<tgardner> debarshi, use dkms. see bcmwl-kernel-source for an example
<debarshi> Ok.
<jendap__> hi
<jendap__> I've read about ppa backporting new kernel to old releases
<jendap__> there is ppa:kernel-ppa/ppa repository
<jendap__> but it has natty development kernel backported for lucid now
<jendap__> so the question is: is there a repository with maverick kernel (2.6.35) backported to lucid (LTS)?
<apw>  jendap__ yes that is correct, the maverick kernel has now released and so the backport of that is in the main archive
<apw> it _may_ only be in -proposed at the moment as it very soon after maverick release
<jendap__> so will it be there later?
<apw> where?
<jendap__> I need it for servers, so LTS would be nice, but I need 2.6.35 kernel
<apw> jendap__, its only supported for servers anyhow
<apw> linux-lts-backport-maverick | 2.6.35-22.34~lucid1 | lucid-proposed | source
<apw> so yes, it is in -proposed at the moment, so you can enable that if you want to install it
<apw> it shoul migrate to -updates shortly when the appopriate bake time has completed
<jendap__> how can I enable "-proposed" ?
<apw> https://wiki.ubuntu.com/Testing/EnableProposed
<jendap__> apw: thanks! that should be it :-)
<apw> jendap__, thats the docs i know about, but its a pocket like updates etc so ypu can add it to sources.list manually if yopu don't have a graphical interface
<apw> install the meta package to ensure you get updates
<jendap__> apw: thanks!
<apw> linux-image-server-lts-backport-maverick i think is the one you want to install
 * ogasawara bails for appt, back in a bit
<jendap__> apw: all servers upgraded, thanks
<Leon_Nardella> Hi! What is the possibility of having goo.gl/Gc3a be backported into Maverick?
<apw> Leon_Nardella, no idea what that even is ... we don't commonly backport new functionality into released kernels
<Leon_Nardella> apw, I wouldn't call it new functionality. It fixed the input audio in some Microsoft webcams.
<jendap__> Leon_Nardella: yit was merged to linux 2.6.36 - so netty kernel will work
<apw> Leon_Nardella, presumably its never worked before as its new func in .36
<apw> but if you want to propose it, emailing the patches to kernel-team list with justification is the normal way forward
<apw> that lets us see the extent of the patches and decide from that
<Leon_Nardella> apw, ok
<apw> the smaller the patches the higher your chances 
<greearb> Hello!  I'm trying to put a custom ubuntu-natty kernel on Ubuntu 10.10 live-cd.
<greearb> The first problem I'm having is that it seems aufs is not being compiled, so the live-cd will not boot.
<greearb> aufs does appear to be in the kernel config file properly, however...any ideas what I might be doing wrong?
<greearb> ahhh, makefile has aufs dir commented out..and it won't build in ubuntu-natty kernel..
#ubuntu-kernel 2010-10-23
<lucent> bug 657081 needs some love from anyone who knows how to get changes applied to Maverick
<ubot2> Launchpad bug 657081 in linux (Ubuntu) "New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/657081
<lucent> (from stable)
<crimsun> lucent: please reference the upstream linux-2.6 git changeset hash in a comment
<crimsun> lucent: depending on the invasiveness of the changesets, you might want to submit it for inclusion in 2.6.35.x (send an e-mail to stable@kernel.org)
<lucent> oh. okay.
<lucent> crimsun: it's a revert, "Revert commit 54672386ccf36ffa21d1de8e75624af83f9b0eeb"
<lucent> does that make sense?  or does the revert have its own hash for the action of reverting
<crimsun> it does make sense, and yes, a revert has its own git changeset hash.
<crimsun> you're of course speaking of commit aa0170ff
<lucent> oh okay, so there's some point where my brain stopped working :)
<lucent> now I am looking and making sense of http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.36
<lucent> two minutes before, I was too confused to notice
<lucent> commit 7f81c56cf29c0af66a1d0cdbce48441cdaf9fa16
<crimsun> err, not precisely
<crimsun> 7f81c56c is the merge changeset
<crimsun> the actual commit to cherry-pick is aa0170ff
<lucent> add to the bug, thanks for the guidance
<crimsun> yw
<lucent> seperately I have affected some USB serial code, which is up for review to be included in 2.6.37-rc1
<lucent> is it helpful for me to file a launchpad bug about that?
<lucent> the cause is determined, upstream knows, just that I'm confused how will Ubuntu kernel get these changes
<crimsun> it depends on the Ubuntu release(s) to which you're referring.
<crimsun> if it's the current development one (2.6.37), then the changes are rebased nominally in natty.
<lucent> okay, you're right... I did not say.  I'm thinking of Maverick
<lucent> Maverick is the only release that is affected by my findings of the usb serial and firewire regressions, here, because the regressions are since 2.6.35
<crimsun> the easiest approach in that regard is to request that the relevant changeset(s) from linux-2.6.git be merged into 2.6.35 stable via gregkh
<lucent> ah okay
<PascalFR> bug #660302
<ubot2> Launchpad bug 660302 in module-init-tools (Ubuntu) "e1000e ethernet link down (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/660302
<PascalFR> anyone has eth which uses e1000e on maverick ?
<lucent> not I
<ai2097> I'm trying to build/install a custom kernel following <https://wiki.ubuntu.com/KernelTeam/GitKernelBuild>, but step 8 (make-kpkg) fails. Tail-end of output (with the command issued at the very end) at: <http://pastebin.com/67rhtEVh>
#ubuntu-kernel 2010-10-24
<ai2097> Found the problem preventing the GitKernelBuild instructions from working. I edited the instructions to include the hack/workaround that got make-kpkg working for me. There might be a better way to do it.
<Sarvatt> ai2097: installing kernel-package from debian will fix it too http://packages.debian.org/sid/kernel-package
<ai2097> Sarvatt: Ubuntu's version of that package is 12.033, the one from the link you provided is 12.036 -- so, Ubuntu's default repository is just out-of-date? That would've been nice to know before traipsing through the guts of that build. Oh well. That probably is the better way to do it, if it works. ;)
<AnAnt> Hello, I am working on a package that contains a couple of kernel modules, one of them  only compiles for 32-bit machines, while the other compiles for both 32 & 64-bit, how can I add a check in the makefile to disable the 32-bit only module while building on 64-bit machine ?
<AnAnt> nevermind, it is already handled in upstream Makefile
#ubuntu-kernel 2011-10-17
<VladimirShushkov> Hi, mates! Sorry for my english and maybe stupid queston. I dont use linux for a long time since the times of kernel 2.6.10 maybe. Now I have installed Ubuntu and I want to rebuild my kernel. I want to compile kernel 3.0. I tried to find ppa for this kernel. I just added ppa:kernel-ppa/ppa to my repository. But after apt-get update and trying to execute "apt-get install linux-headers" I didnt see linux-headers v.3.0, only 2.6.38. Maybe I 
<ohsix> why do you want to build your own kernel?
<ohsix> you can install kernel packages from mainline that are built almost nightly, or you can install something like xorg-edgers which has a 3.0 kernel in it; to support the updated drivers in the same repo
<jk-> VladimirShushkov: `apt-get install linux-headers-$version` ?
<VladimirShushkov> ohsix: Why do you ask about reasons to build new kernel? Is it bad idea? In the past I used slackware linux and always built my own kernel after linux installation. I built some of kernel features right in kernel but some left in modules. Building of you own kernel give you some definition. Also in the past I found that some of kernel features (e.x. packet filtering features) were not included in kernel nor in modules. Maybe today is diff
<VladimirShushkov> jk-: Sorry, I dont understand what do you mean. As I said after typing apt-get install linux-headers- and pressing tab I see all candidates for installation: root@WorkstationX:~# apt-get install linux-headers-
<VladimirShushkov> linux-headers-2.6.38-10              linux-headers-2.6.38-8-virtual
<VladimirShushkov> linux-headers-2.6.38-10-generic      linux-headers-generic
<VladimirShushkov> linux-headers-2.6.38-10-server       linux-headers-lbm-2.6.38-10-generic
<VladimirShushkov> linux-headers-2.6.38-10-virtual      linux-headers-lbm-2.6.38-10-server
<VladimirShushkov> linux-headers-2.6.38-11              linux-headers-lbm-2.6.38-11-generic
<VladimirShushkov> linux-headers-2.6.38-11-generic      linux-headers-lbm-2.6.38-11-server
<VladimirShushkov> linux-headers-2.6.38-11-server       linux-headers-lbm-2.6.38-8-generic
<VladimirShushkov> linux-headers-2.6.38-11-virtual      linux-headers-lbm-2.6.38-8-server
<VladimirShushkov> linux-headers-2.6.38-8               linux-headers-server
<VladimirShushkov> linux-headers-2.6.38-8-generic       linux-headers-virtual
<VladimirShushkov> linux-headers-2.6.38-8-server
<smb> VladimirShushkov, I think it would be linux-headers-<something> while the something is the same as you see when you run uname -r
<smb> (like generic or generic-pae or server)
<smb> morning .+
<VladimirShushkov> ohsix: thanks, xorg-edgers is what i need. One stupid question. What do you mean saying mainline? Is it kernel.org? Because when I used slackware I just downloaded kernel source in tar.bz2 format and used it.
<smb> VladimirShushkov, It is the same, but instead of taking certain tar version, the source is taken from git directly and then compiled with the same configuration options as the released kernel packages. Any ubuntu specific modules are missing, but those are less often needed.
<Q-FUNK> howdy! any news on re-enabling vesafb on mainline kernels?
<VladimirShushkov> smb: Thanks for your explanation. As I see mainline doesnt contain kernel 3.0 for natty, only for oneiric. If I will use oneiric kernel dont I break depencies?
<smb> VladimirShushkov, There are no hard dependencies. The natty or oneiric postfix rather tells you which config options where used to build the kernel. There always may be problems but rather due to the fact that a newer kernel could potentially have changed interfaces to user-space. Though 3.0 in Natty is working 
<VladimirShushkov> smb: thank you!
<smb> Q-FUNK, No (though that merely means "I have no clue whether there are news")
<Q-FUNK> smb: ok :)
<apw> ppisati, yo ... cve-tracker ?
<ppisati> are you and smb mentally connected? :)
<smb> ppisati, Didn't you know. ;-P
<ppisati> good to know :)
<ppisati> anyway
<ppisati> https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master?
<ppisati> this one?
<smb> Not if you want to change anything
<smb> That is the other teams original copy
<ppisati> https://code.launchpad.net/~canonical-kernel-team/ubuntu-cve-tracker/kernel-team
<ppisati> ok
<ppisati> this one
<smb> Yup, looks better
<smb> ppisati, Anything in special that you need to achieve?
<ppisati> no no
<ppisati> just flip a cve status
<ppisati> seems lp and cve tracker are not connected yet
<smb> ppisati, They should be. But its something that apw has to trigger (or any real person). So it probably just runs or ran
<apw> ppisati, they are connected but there is security-team latency involved
<apw> but there isn't any problem flipping the state if you want to
<apw> though other than 'not-affected' there isn't many that make sense to apply manually
 * apw watches his upgrade go at 160k/s ... sigh
<apw> i presume the mirrors are still being hammered
<apw> ppisati, for -2479 do you know which commit added the the huge page support in error ?
<ppisati> apw: huge page support was added in 71e3aac0724ffe8918992d76acfe3aad7d8724a5
<apw> ppisati, so we can represent when something is added too on the break-fix line and get the not-affected status for free ... /me tries it out on this cve
<Kano> hi apw , why are daily builds older than rc9?
<apw> older in date or older than commit list
<Kano> they are not build
<apw> that is not really an answer to the question
<Kano> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/
<Kano> 10-04 is older than rc9 date
<apw> but by the looks of it linus has not pushed his master bracnh correctly to kernel.org
<Kano> but there are much  newer commits there
<apw> there == where ?
<Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
<Kano> what should be wrong there?
<apw> Date:   Sun Feb 20 10:15:57 2011 -0800
<apw> interesting, the latest commit if you pull the branch from kernel.org is nothing like that in gitweb
<Kano> really weird
<Kano> well usually i parse web gits to dl snapshots
 * apw switches mainline over to github again, we'll see if that changes anything
<Kano> any diff there?
<apw> Kano, take a while before we know
<apw> cking, yo ... i have just confiermed my 35s of black screen is a win7 thing, if i set acpi_osi="!Windows 2009" it no longer occurs :(
<Kano> did anybody manage to suspend a system booted via uefi correctly?
<apw> what sort of machine is it, ie is it real uefi
<apw> and not broken mac near a bit efi
<Kano> i7 with q67
<apw> you could easily be the first
<apw> does the machine suspend if you enable bios emulation?
<Kano> it does not even suspend correctly win7 64 bit sp1 via efi
<Kano> it works fine booted via mbr
<Kano> somehow suspend does not seem to be that easy with efi...
<apw> nope, efi is a bit of a disaster at the moment
<nusch> Is there avaiable or could someone build for me standard 3.0.0-12-generic with CONFIG_RCU_TRACE option enabled ?  
<apw> nusch, i doubt there is one available, i might be able to make you one, what you need it for
<apw> (and which architectures)
<Kano> bbl
<nusch> I installed new RAM and got message about RCU detected CPU 0 stall
<nusch> trying to examine where exactly it locks
<apw> did it come out of the stall ?
<nusch> yes
<nusch> kernel runs about 30x slower than normally
<nusch> looking at tty lines
<apw> and you get constant stalls ?
<apw> all from adding some new RAM ?
<nusch> yes
<nusch> 8GB instead of previous 4GB
<nusch> this is x86_64
<apw> doesn't seem like a change we'd expect to affect the kernel
<apw> none of those values are exactly remarkable
<smb> If you assume the RAM has no flaw
<apw> and you've run a memory check?
<nusch> memtest looks ok
<nusch> and it boots on another hardware without problems
<nusch> some people sugested buggy BIOS, is it correctable by kernel?
<apw> i wonder where it got put, in the memory map
<apw> if it is a physical layout issue triggered by the bios, not so easy
<apw> could you pastebin a dmesg from the kernel with 8G inserted
<apw> i wonder if the mtrrs could be wrong
<smb> Yeah either that or maybe the timing goes wrong. Some BIOS may decide something bad based on what is in SPD
<nusch> I asked people at ##kernel their also suggested mtrr but said it's ok, here is my dmesg https://bugs.launchpad.net/ubuntu/+source/linux/+bug/875655
<ubot2> Launchpad bug 875655 in linux "Kernel extremally slow after upgrade from 4 to 8GB RAM on x86_64 machine, "RCU detected CPU0 stall"" [Undecided,Confirmed]
<nusch> it was run with kernel mem=3G, becuse otherwise unusable. Here is another http://pastebin.com/YtLNPiCc with 8GB inserted and no kernel mem= option
 * smb wished that dmesg would not just print the hard to understand mask format...
<smb> Though it feels like only the first 3G and then 1G above 4G are cacheable...
<nusch> smb, and what is the reason of such behaviour ?
<smb> nusch, Don't know exact. Actually I start to wonder whether it matters that much in 64bit mode... My system here also only has the first 4G declared in mtrrs and does not care that much
<nusch> smb, and what about PAT, if PAT is enabled doesn't it mean MTRR don't have to strore correct information ?
<smb> Thinking along similar lines. But I am sufficiently in doubt about my knowledge here...
<smb> nusch, Theoretically there could also be the problem that the module reports incorrect RAM timing (or the bios fails to make a sense of it). Unfortunately netbooks usually have nothing useful (in the sense of tunable) as a bios
<nusch> I hope that's not striclty hardware issue, that's why I want check it with CONFIG_RCU_TRACE
<smb> nusch, Maybe you could add the output of "sudo dmidecode" to the bug report. That may contain some more bits of info
<nusch> smb, I have no access to this computer at the moment , can send evening, but if it helps I have DSDT dump there
<smb> nusch, Don't think the DSDT helps us here. That would be rather static info, while the dmidecode could show some info about what the bios detected/has set up
<nusch> ok, will try that this evening, BTW could I pass commands like dmidecode | tee  to kernel init= parameter ? Because it was not possible to boot system to bash prompt anytime. I was only able to sysrq reset or poweroff after few seconds pressing keys
<smb> nusch, It should be ok to run the command even with mem=3G. As long as the memory module is present the bios will configure it and dmidecode reports it. Just the kernel make no use of the additional memory
<nusch> ok
 * ogasawara back in 20
<bjf> ogasawara: are you still handling the oneiric kernel or has the batton been passed to stable ?
<ogasawara> bjf: should probably pass to stable now
<Q-FUNK> who updated the mainline kernel today? :)
<evt> Can someone explain the "isra" suffix I see on some symbols via /proc/kallsyms? (ex: do_anonymous_page.isra.40())
<nusch> smb: here is my dmicodede you asked http://pastebin.com/bKeT9iuw
<nusch> smb, sorry that one was without one module mounted, paste in a moment
<pmatulis> jsalisbury: hello sir, do you still need any vm's on kvm-server-2?
<DBO> hi, I am having issues with my realtek wireless. rtl8192ce is the wireless driver I am currently using. It seems to randomly stop talking to my access point at which point I have to reconnect to keep talking
<DBO> it really makes pushing to bzr a frustrating experience :)
<jjohansen> DBO: your lucky it doesn't oops your machine, what kernel version are you using
<jjohansen> DBO: I have found the oneiric driver much better than (still not good), the natty one
<DBO> oneiric latest
<DBO> is there a better driver to use?
<DBO> or something I can do to improve its stability and usefulness?
<bjf> ogasawara: what's your timeframe on uploading the first precise kernel ?
<ogasawara> bjf: am about to send out email for the proposed -generic and -server config flavors.  Assuming I get Acks, I'd like to upload tomorrow.
<bjf> ogasawara: cool
<Q-FUNK> bjf: we have separate desktop and server flavors, now?  are the desktop ones full preempt?
<jjohansen> DBO: try black listing the rtl8192ce driver and see if another of the rtl drivers will handle it
<bjf> Q-FUNK: that's a question for ogasawara 
<Q-FUNK> Ã¶Ã¶, yes
<ogasawara> Q-FUNK: we have separate flavors at the moment, we're proposed merging them.  the desktop uses the voluntary preemption model.
<Q-FUNK> ogasawara: why merge them?  
<DBO> woops, xchat crashed
<ogasawara> Q-FUNK: because aside form the preemption model and the scheduler, the configs are almost identical
<bjf> Q-FUNK: this is being discussed on the ubuntu kernel team mailing list
<Q-FUNK> ogasawara: the preemption model is already a significant factor.
<ogasawara> Q-FUNK: that's why we're discussing on the mailing list
<ogasawara> Q-FUNK: and I'd like to keep the discussion there rather than having separate discussion on IRC and email
<Q-FUNK> ogasawara: ok.  fair enough :)
<Q-FUNK> ogasawara: have you and apw had the time to figure out why 'vesafb' is missing from default mainline builds, btw?
<ogasawara> Q-FUNK: sorry I haven't looked as I thought you'd discussed with apw
<ogasawara> Q-FUNK: as he is the primary care taker of the mainline builds
<Q-FUNK> ogasawara: we did.  sorry if the hierarchy of the kernel team seems unclear to me at times.
<Q-FUNK> ogasawara: we however never came to a definite answer about it.  I noticed a new mainline build toda, but vesafb was still missing.
<DBO> jjohansen, okay I tried that, no joy, blacklisting rtlwifi and rtl8192ce results in no wifi :/
<jjohansen> DBO: :(
<DBO> is it possible that the driver isn't dealing with network manager doing its "scans"
<ogasawara> Q-FUNK: might be best to follow back up with him tomorrow?  I think he reset the mainline builds to point to github earlier today.
<Q-FUNK> ogasawara: that's possible. I'm not updated on the situation. I'm merely waiting for vesafb to return so that I can test mainline as jsalisbury requested on several bugs.
<jjohansen> DBO: from what I have seen, no its the driver having problems
<DBO> jjohansen, is there anything I can do? It kinda makes hacking on Unity hard :P
<jjohansen> DBO: I found a usb wifi dongle fixes the proble :/
<DBO> jjohansen, are we dependent on a fix from realtek or can we FOSS our way to a win here?
<jjohansen> DBO: well FOSS away, but as I hear it the driver is pretty poor and needs a lot of work.  It certainly take someone who knows their way around the wireless driver stack
<DBO> jjohansen, I wasn't intending to imply *I* would fix it, more looking for hope :)
<DBO> I'll see if I cant order an intel wifi card and just be done with it
<DBO> swapping out hardware is fun
<jjohansen> DBO: hehe :)  I can give you the hope that I have only seen it crash oneiric once, which is better than natty where it was taking out the machine every 30 min
<DBO> jjohansen, I have to admit, I find it a bit discouraging that the driver is in such a poor state
<jjohansen> yeah /me too
<DBO> jjohansen, I've never done wifi driver work, but I am an experienced hacker, is this a whole other world of pain or could I potentially help out here?
<jjohansen> possibly, its just a driver, nothing magical.  You need to learn the wifi driver stack some and maybe have card specs
<jjohansen> I've never had the time to chase it
<DBO> last one and I promise to leave oyu be: http://www.newegg.com/Product/Product.aspx?Item=N82E16833106061 will that be trouble free?
<apw> Q-FUNK (and ogasawara), i know why it is missing at least, it can no longer be a module -- fixing it is on my list
#ubuntu-kernel 2011-10-18
<tkamppeter> When will the kernel SRU for Oneiric be ready, for example to fix bug 872711 which prevents half of the USB printers not being detected?
<ubot2> Launchpad bug 872711 in linux "Kernel does not report some USB printers correctly, making them not being detected by CUPS" [High,Fix committed] https://launchpad.net/bugs/872711
<smb> morning .+
<abogani> smb: morning
 * apw yawns
<apw> tkamppeter, i would expect it to be uploaded very soon though that is now in the hands of the stable team and their cycles
 * apw has to reboot ...
<gentoo_drummer> anyone here?
<gentoo_drummer> has anyone tried ubuntu 11.10 command line installation under vbox? i get to a blinking underscore screen forever
<smb> gentoo_drummer, Have not tried vbox. But done an alternate installation under kvm and xen...
<smb> gentoo_drummer, you got past the syslinux boot screen I assume? Or when does it get stuck?
<gentoo_drummer> smb: i get past the ubuntu 11.10 splash screen and then it stays on the underscore forever
<gentoo_drummer> 10.10 works though
<gentoo_drummer> how do i do a distupgrade to oneiric?
<gentoo_drummer> just put oneiric-ocelot in apt.sources and then dist-upgrade?
<TeTeT> gentoo_drummer: sudo do-release-upgrade
<smb> gentoo_drummer, You could try to remove the quiet and splash words from the opetions and see what happens then
<TeTeT> gentoo_drummer: or, from GUI, update-manager
<smb> or do as TeTeT said for updating, will take you through 11.04 though
<gentoo_drummer> how can i get to verbose through grub boot screen?
<smb> gentoo_drummer, When you boot from cd, there is one key for options (f6 or so but not sure), then escape and edit the line. It has "quiet splash" which when removed gives you verbose
<gentoo_drummer> smb: i mean when pressing "c" to get to the grub boot screen
<gentoo_drummer> is there a command to boot in verbose from there?
<apw> gentoo_drummer, sadly not, you have to jump through several hoops
<gentoo_drummer> gosh
<apw> you have to change the =$foo bit to =text
<smb> gentoo_drummer, for the kernel you want to boot its e
<apw> then on the command line remove quiet and splash and add debug
<smb> then edit the line there to remove the quiet and splash
<smb> and then ctrl-x to boot it
<Kano> apw: is rc10 building now? was tagged 6h ago?
<Kano> or same problem like with daily?
<apw> we only check at 9am UTC so it would have started about then if it was ready by then
<Kano> well it was tagged before 9 utc
<apw> then its in the build queue, looks like there was another stable release too which gets done first
<Kano> ah which one?
<apw> v3.0.7
<Kano> ah
<Kano> with dvb fixes?
<apw> if they are in mainline
<Kano> you didnt add the 3 patches i showed you, did you?
<apw> to the mainline builds, no, they are what they say they are, virgin unchanged mainline builds
<apw> for them to have random patches on top would not make any sense for our use case
<Kano> no for your o release ernel
<apw> the release kernel no, it was frozen already
<Kano> 3.0.7 misses em too as i see
<apw> upstream stable isn't being fed very well it seems
<Kano> do you intend to base a kernel on 3.0.7?
<apw> yep, most likey we'll upload a 3.0.6 plus fixes shortly, and then the next cycle will have 3.0.6
<apw> 7
<Kano> why dont skip 3.0.6?
<apw> cause what we have has had some time to settle and there is always a new one on the horizon
<apw> not that it is my call at the end of the day, but there is little point in rushing out stuff
<apw> as they normally find problems in one update and produce a fix for it
<Kano> ok, any estimate for 3.0.7?
<apw> a couple of weeks or so
<apw> herton, hey ... has anyone formally handed over the oneiric kernel to you in stable ?
<herton> apw: yep, steve talked to leann yesterday
<apw> herton, ok good ... we need to keep in mind there is an lts-backport for it too which needs uploading as well
<apw> herton, where are we in the cycle for stable, we likely should push the update for oneiric sooner than later as there is already a heap of stable on there
<Kano> apw: whats the reason that rc kernels are not written as ~rc
<herton> apw: the first oneiric update is in progress now (bug 876701), will take care of lts-backport as well
<ubot2> Launchpad bug 876701 in linux "linux: 3.0.0-13.21 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/876701
<Kano> in the version
<Kano> rc is always newer than first release kernel with mainline builds
<apw> herton, you are a star -- thanks a lot
<apw> Kano, never thought about it, the names are only meant to be unique as they are 'install, test and remove' kernels not intended for longterm use nor do we provide any updateable sources
<Kano> well maybe kanotix users test more of our mainline build than yours ;)
<apw> maybe, maybe
<Kano> i basically like pure kernels, custom patches needed to fix something is always annoying
<ogasawara> apw: I suspect we'll only have a handful of specs for UDS which need an actual meeting slot, I wonder if we should spread them out over the week rather than monopolizing a single day
<apw> ogasawara, other than the version flavours discussion i suspect they can float forward
<apw> i think the plan with putting them together was to allow the rest of the week for us to go to things
<apw> but actually that really doesn't make any difference where they are
<apw> friday afternoons is often prep for party time as well
<ogasawara> apw: I'm guessing we're only going to have 4 (config, delta, version, stable), so was thinking to just schedule 1 per day
<apw> can't see anything wrong with that
<ogasawara> herton: I assume you or bjf will be having a stable kernel blueprint for UDS? or are you guys pretty much just turning the crank now and don't need to work out further details?
<apw> i am sure there will be people wanting to input on it
<herton> yes, probably will be good to have at least one session
<herton> ogasawara: I'll wait bjf to show up and see with him
<ogasawara> herton: ack
<bjf> oh mistress of the dark, i hear you have questions
<ogasawara> hehe
<ogasawara> bjf: was just assuming you and herton would want to have a stable kernel session at UDS?
<bjf> ogasawara: blueprint wise .. though we are just turning the crank i think we are expected to do a uds session so that people can have somewhere to whine
<ogasawara> bjf: heh was assuming it would be more of a bitch session
<bjf> ogasawara: we'll nod and tell everyone we will take their input seriously .. and then do what we want
<smb> bjf, Will you play some annoying music as well?
<bjf> ogasawara: just the usual
<bjf> smb, i'll put that on the list
<ogasawara> bjf: ok, I'll throw a stub blueprint together for you guys to fill in later and throw it in the schedule
<smb> Cool, then we feel just as with any support line... :)
<bjf> ograsawara, "state of the cadence" kind of thing
<bjf> ogasawara: are we "other-p-kernel-*" ?
<ogasawara> bjf: "hardware-p-kernel-*"
<bjf> ogasawara: nice that there is a "kernel" track which we are not allowed to use :-)
<bjf> i guess only linaro has kernel issues
<ogasawara> bjf: you want me to assign you or bjf to this blueprint
<ogasawara> bjf: heh, you or herton
<bjf> ogasawara: me please
<ogasawara> bjf: https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-sru-cadence
<bjf> ogasawara: i'll be sure and thank you properly at uds
<bjf> :-)
 * ogasawara back in 20
 * apw notes it makes as muh sense for us to be foundations-kernel as hardware-
<bjf> beer-p-kernel 
<bjf> kind of "flows" eh?
<gema> apw, bjf: don't complain, we are other-p...
<apw> bjf, nice lets go for that
<apw> bjf, actually or .... poolbar-p-kernel
<bjf> gema, it's in my contract "required to complain, bitch, whine"
<apw> "like a grumpy old man"
 * gema goes to check her contract, being QA she expect to have even more rights than bjf...
<gema> btw, bjf do you guys run any kind of static code analyser on the kernel?
<bjf> hahaha ha ha HA!
<gema> I will take that as a no :D
<smb> not us as such, but isn't that coccinelle thing somehting like that?
<apw> that more happens upstream yes, on the raw kernel
<bjf> gema: actually, i do think there are static analyzers that upstream does
<gema> smb, apw, bjf: but if they are run upstream, we don't benefit from then in our specific bits of the kernel, right?
<bjf> gema: our kernel differences are very minor in reality
<smb> no, thats why we try to keep our bits as small as possible (amongst other)
 * bjf not sure he likes the implication that the kernel team has tiny bits
<gema> bjf, smb: thanks! 
<smb> bjf, aren't we always told size does not matter? ;-P
<bjf> smb, they just tell us that to make us feel better, but they lie
<bjf> gema: http://lwn.net/Articles/208312/
<bjf> gema, i knew linux had written one
<gema> bjf: thanks!
 * herton -> lunch
<apw> BAH unity just stopped updating my laptop screen like it was hung
<apw> only cause i could see my external monitor could i tell it was actually just that screen
<apw> ogasawara, are you ready for precise kernels to be uploaded to pre-proposed ?
<ogasawara> apw: just about, I want to make a quick tweak to the VIRTIO bits you pointed out (ie disable except for -virtual), and I want to rebase to -rc10
<apw> ogasawara, so i can add them for tommorrow 
<ogasawara> apw: yep
<jsalisbury> ogasawara, bjf, I'm seeing lots of new possible duplicates for bug 836250 and many people are reporting as affecting them ( /me included ;-) ) 
<ubot2> Launchpad bug 836250 in network-manager "[Oneiric] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [High,Confirmed] https://launchpad.net/bugs/836250
<ogasawara> jsalisbury: so are you able to test a few things, like boot back into a Natty kernel and confirm it's not an issue?
<jsalisbury> ogasawara, I could give that a try, but I may have to do it later since its my primary laptop
<jsalisbury> ogasawara, I can also ask others affected by this to try Natty
<ogasawara> jsalisbury: ack.  I also thought tgardner did some extensive wifi testing but he wasn't able to reproduce a lot of these issues.
<jsalisbury> ogasawara, yes, I did see that thread
<DBO> jjohansen, so I am still running into issues with the rtl8192ce module. I found that if I do ips=0 that *seems* to fix it (hard to tell). Should I report this any further or just modify my machine and move on?
 * apw notes they are lenovo's ... they are always troublesome
<jjohansen> DBO: it would be good if you could file a bug, and add that information
 * jjohansen is going to have to try that as well, and see if it works for me
<DBO> so now I have to ask a somewhat silly question
<DBO> how can I make this permanent (rather than just use modprobe)
<apw> /etc/modprobe.d contains various files which have examples, you could make a new file there in a similar form
<herton> ppisati: bug 877497 is the correct one to be worked on linux-ti-omap4 update for oneiric, the other ones I already closed (should be ignored)
<ubot2> Launchpad bug 877497 in linux-ti-omap4 "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/877497
<DBO> jjohansen, 20 minutes and no disconnects so far, this is pretty much a record for me
<DBO> :)
<DBO> still replacing the card... but no rush nwo :)
<jjohansen> DBO: nice
<ppisati> herton: yep, saw it
<ogasawara> bjf: I assume you're aware the daily bug report email is stuck on Friday Oct 14
<bjf> ogasawara: no, will look into it though
<DBO> jjohansen, false alarm, it might have improved it for a bit, but it just did it again :/
<jjohansen> DBO: :(
<DBO> jjohansen, https://bugzilla.redhat.com/show_bug.cgi?id=729618
<DBO> that looks interesting
<ubot2> bugzilla.redhat.com bug 729618 in kernel "rtl8192ce reloads firmware all the time" [High,New]
<jjohansen> DBO: hrmm, interesting
<apw>  DBO reference that in the ubuntu bug you make
<DBO> yeah
<DBO> it looks liek the driver stops receiving beacons...
<cking> is there a kt meeting this week?
 * smb thinks not until after the big meeting called uds
<bjf> cking: no further irc meetings until post uds
<cking> ah, usual pattern
<Q-FUNK> ogasawara: I'm not involved on the kernel list, but I would have one simple request:  if the team decides to keep distinct server and desktop kernels, please rename -generic to -desktop.
<bjf> bug #873119
<t3_> Greetings. I'm having a problem with KVM in 2.6.38-11-server and was wondering what problems I might run into if I use 2.6.38-12-generic (bug seems to be fixed there)? I'm using standard HW...
<bjf> t3_, have you tried the 2.6.38-12-server ?
<t3_> That would make a lot of sense... I must have missed it.
<t3_> I'm not seeing that in the list of kernels, what repo is it in?
<bjf> t3_: it's in -proposed right now
<t3_> bjf, thanks.  I'll grab that one instead and see if it fixes the issue.
<bjf> t3_: cool, let us know if it doesn't
<t3_> bjf: will do, ttyl
<twb> I'm a bit confused; I git cloned the lucid kernel repo, copied the .config from /boot of a lucid box, did a "make deb-pkg", installed it, did a "update-initramfs -c -k xxx".  The resulting ramdisk was 71MB where it should've been more like 13MB
<twb> I noticed that the -Os option was off in .config, but AFAIK it was like that already; I didn't mess with it.
<twb> I suppose the other likely thing I did different, was compiling on hardy
<twb> Building it with -Os doesn't help; the resulting ramdisk is 68MB
<twb> WTF, man.
<twb> I'll try building it inside a lucid chroot (hence gcc 4.4 or so)
<jjohansen> twb: did you strip it?
<twb> Not explicitly, but IME make deb-pkg does that for me
<twb> I'll check
<twb> Ah, good catch
<twb> So why didn't it strip them?  Is it just that the 2.6.32 kernel predates that feature in the deb-pkg approach?
#ubuntu-kernel 2011-10-19
<twb> OK, so I built 3.0 with "make deb-pkg" on hardy, and it gave stripped packages.  So I guess the builddeb script as at 2.6.32 is just too stupid to do that :-/
<twb> I don't really wanna go back to make-kpkg
<twb> Actually make it wasn't stripped, I only looked at the .deb size (5MB instead of 150MB), but that might just be because I used defconfig instead of the allmodconfig-esque ubuntu .config
<twb> not stripped.
<twb> Aaand nor are the .ko's in my personal ones, so "make deb-pkg" doesn't normally strip, either.  Mea culpa.
<twb> OK, it turns out to be simple -- pass INSTALL_MOD_STRIP=1 to build and then strip, or unset CONFIG_DEBUG_INFO in your .config to avoid building debugging symbols in the first place.
<twb> The former is handy if you want to go back and "make debug-package" or so (can't remember the exact target name).
<jonpry> how can i debug an acpi problem?
<cemc> hi. I'm trying to rebuild the latest hardy kernel package. I've got the .dsc, I've changed what I wanted, then uploaded it to my ppa, but it doesn't build: https://launchpadlibrarian.net/83147123/buildlog_ubuntu-hardy-i386.linux_2.6.24-29.94~cemc111019~ppa1_FAILEDTOBUILD.txt.gz . it's complaining about some missing ABI files. I have no idea what I need to do. never messed with a kernel package before. any pointers would be appreciated
<matei1> hi, I have a question about Ubuntu 11.10 on EC2: is it possible to use transparent hugepages in the latest cloud kernel? the /boot/config-* file says that CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y, and I have an application that uses madvise with MADV_HUGEPAGE, but I don't see any AnonHugePages created in /proc/meminfo
<smb> cemc, Probably https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI is closest to help
<sroecker> hi, does the kernel bugzilla work again?
<smb> Does not seem so
<sroecker> bummer, i would like to have a look at http://bugzilla.kernel.org/show_bug.cgi?id=36152 to fix bug 706039
<ubot2> Launchpad bug 706039 in isight-firmware-tools "Can't produce data in UYVY" [Undecided,Confirmed] https://launchpad.net/bugs/706039
<ubot2> sroecker: Error: Could not parse XML returned by bugzilla.kernel.org: timed out (https://bugzilla.kernel.org/xml.cgi?id=36152)
<cemc> smb: thanks!
<apw> bah everyone i go to answer has always gone, so frustrating
<smb> apw, Was that the hugepage question?
<apw> yeah
<apw> actually and one futher up in scrollback ... sigh
<smb> Has been gone almost immediately after asking
<apw> moin
<smb> (well almost a bit strechted)
<smb> moin
<smb> apw, Actually you could answer me, I am not completely sure. Would say it should work, even finding some old information that it may depend on the hypervisor, too. 
<apw> i would think it is very dependant on the hypervisor supporting it, as it would need to support the PTE formats etc
<smb> Right, so ec2 actually may not work as they are on 3.4.x at most
<apw> and even if it is available at the hypervisor i would expect it to be a configurable option and probabally off by default
<smb> Found some 2yr old info about required boot arguments for the hypervisor and guests, but those did not appear in the current wiki. Which could mean the wiki is incomplete or the option is gone..
<apw> yeah, i presume you can tell from the proc/cpuinfo cpu flags that xen gives you
<apw> it also depends on xen giving you contigious physical ram, and i am not sure it does that either by default
<apw> smb, cifs is the in kernel samba implementation i think right?
<smb> apw, well the sort of guest part I think
<apw> right that bit yes
<apw> do you have a samba server on the network your hardy box is on ?
 * apw has a cve which i wonder if anyone can reproduce on hardy
<smb> apw, Yes, the test system can access it
<apw> so the bug in theory is you use cifs to mount it, then you use another user to mount it but without a password, and it "reuses" the password the kernel already has allowing the second user access too
<smb> I guess I can give it a try...
<apw> if you have time that would rock, as i have a patch for it, but who knows if it works
<smb> apw, any preference on 32 or 64 bit?
<apw> no specification either way in the bug, so i assume it is generic
<smb> apw, Ok, so it seems to incorrectly work as you described it
<apw> that is awsome
<apw> smb, you 32 or 64 bit
<smb> apw, 64bit
<alexbligh> I am attempting to build a new flavour of ubuntu kernel (oldstyle/xenlinux xen, for 3.3 hypervisor). My kernel builds fine, but as it makes a vmlinuz not a bzImage, it doesn't package. I can see there are bits in debian.master/rules.d to control this on a per arch basis (though I don't understand them). How do I control on a per flavour basis?
<apw> alexbligh, how are you triggering the build
<alexbligh> fakeroot debian/rules binary-myflavour
<apw> alexbligh, the output file requested is controled by the debian.<branch>/rules.d/<arch>.mk file
<alexbligh> right, but arch is amd64. I only have a flavour. Or do I need to do a whole new arch?
<apw> install_file    = vmlinuz
<apw> isn't a vmlinuz a bzImage anyhow ?
<apw> its not an x but a z
<alexbligh> The XEN patches cause it not to produce the bzImage.
<alexbligh> No, I don't think they are the same
<apw> build_image     = bzImage
<alexbligh> At least not according to the debian patch which says "we can't load a bzImage so load a vmlinuz for now"
<apw> have you changed tha t?
<apw> kernel_file     = arch/$(build_arch)/boot/bzImage
<apw> and indeed that ?
<alexbligh> You mean in debian.master/rules.d/amd64.mk?
<apw> yep
<alexbligh> I haven't changed that file at all, because I wanted amd64 to continue to build. I only wanted the targets to change for my flavour.
<apw> i am pretty sure we have the same problem with powerpc in older releases
 * apw isn't sure you can do that
<alexbligh> ok. that's not the end of the world.
<alexbligh> so build_image should be vmlinuz
<apw> alexbligh, we don't normally want to make the originals when we make a derived branch like that
<alexbligh> install_file should be vmlinuz (as it is at the moment)
<alexbligh> and kernel_file should be what?
<apw> build_image should be what you type when you type make in a native tree
<alexbligh> vmlinuz
<apw> kernel_file should be whatever it makes when it builds it when you do that :)
<apw> its a bit of a guessing game
<alexbligh> Kernel: arch/x86/boot/vmlinuz is ready  (#2)
<alexbligh> that then :-)
<apw> yeah that sounds about right
<alexbligh> apw, thanks
<apw> np
 * apw notes that you are all going to get a spurious v3.1-rc10 build announcement ... i hope
<ogasawara> herton, bjf: just fyi http://people.canonical.com/~ubuntu-archive/pending-sru appears to mention there is a separate report for our kernel SRU's, but the url it points to is invalid, ie it points to http://people.canonical.com/~ubuntu-archive/pending-sru
<ogasawara> herton, bjf: bah, http://kernel.ubuntu.com/~kernel-ppa/reports/sru-report.html is the invalid url location
<bjf> ogasawara: nice, it actually points to the ~kernel-ppa location where it used to be
<bjf> ogasawara: i'll mention it to pitti
<ogasawara> bjf: yah, didn't know if you wanted to set up a re-direct to get pitti to fix it
<bjf> ogasawara, it's been broken forever so not many people must be using it
<bjf> ogasawara: pitti has fixed his script and it will be fixed in the next update
<ogasawara> bjf: cool
 * ogasawara back in 20
<herton> apw: ogasawara: did you saw this error before when uploading to c-k-t ppa? Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
<herton> I'm trying to upload the new linux-lts-backport-oneiric, the packages were signed by bjf
<herton> I already uploaded packages signed by him and it went ok, may be the fact the package is new has something to do with it
<smb> herton, whether new or not should not matter. maybe the signage key was accidentally not the one in lp...?
<herton> smb: nope, the key is ok, matches the lp one
<ogasawara> I think if it's the first upload of the new package, you might new core dev privs to do so?  I swear I might have hit something similar doing lbm at one time
<ogasawara> herton: I think I had to have tgardner do the first upload, and after that I was ok
<smb> ogasawara, herton Oh, maybe right because its new new (as not in the upload rights list)
<ogasawara> smb: yep
<herton> ogasawara: hmm ok, only tim is core dev?
<smb> yep
<ogasawara> herton: and I think he's out until UDS?
<smb> but you could ask cjwatson to add the package to the list I guess
<herton> calendar shows him on vacation until this friday. I'll ask cjwatson if he can see this
<bjf> smb, looks like tim's "hit by bus" rule applies here, we should probably get apw and ogasawara and maybe yourself as core dev ?
<bjf> smb, need more than one
<smb> bjf, Yeah, me and apw have it on our list... Just always seemed "too hard"
<ogasawara> smb: yah, seems like a lot of extra work for not much more gain
<ogasawara> herton: have you gone before the DMB yet to get your kernel upload rights?
 * ogasawara meant to ack your application
<bjf> ogasawara, he hasn't yet
<herton> ogasawara: I'm with my application ready, but the October 24th date is a not good one, since tim may be is away and sconklin too, and the timing is not good, I was thinking of sending the application for the meeting after
<herton> october 24
<ogasawara> cool
<smb> herton, now try to upload lts-backport again...
<herton> smb: still the same
<smb> Hm, bjf what is your lp username again?
<bjf> smb: brad-figg
<smb> bjf, OK seems solved... It was only a fake error. And our upload rights actually do not matter as everything goes via ppa. But I guess it does not hurt if our package uploader rights mtach what damage we could do via the ppa
<herton> yeah, the builds are showing on c-k-t ppa despite the error, so should be ok
<ogasawara> bjf, jsalisbury: are you guys going to want to have an official UDS kernel bug session, or can we just chat over a pint of beer at the bar
<bjf> ogasawara: beer!
<ogasawara> heh, I probably didn't even need to ask :)
<jsalisbury> ogasawara, beer works for me :-D
<jsalisbury> ogasawara, bjf or both
<bjf> ogasawara, jsalisbury, don't need a session
<jsalisbury> bjf, ok
<ogasawara> apw: before I forget again, we're planning on sticking with the 3 digit version scheme for Precise right?
<apw> i think its likely, we should think about it at UDS and check before we upload 3.2
<ogasawara> apw: yep, I pretty much forced us to the 3 digit when I uploaded 3.1.0 yesterday, but am banking on the fact we'll be using at least 3.2
<jsalisbury> ogasawara, bug 876996 looks like a regression that prevents an install/upgrade of Oneiric
<ubot2> Launchpad bug 876996 in linux "Ubuntu 11.10 fresh install crashed" [High,Triaged] https://launchpad.net/bugs/876996
<hggdh> ogasawara: can you reset bug 871899? I wrongly set the kernel verification task as completed
<ubot2> Launchpad bug 871899 in kernel-sru-workflow "linux: 2.6.32-35.78 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/871899
#ubuntu-kernel 2011-10-20
 * smb yawns
 * _ruben copy-cats smb 
<hrw> hi
<hrw> does someone here work on intel backlight support in laptops
<hrw> ?
<Kano> hi apw 
<Kano> apw: the current symlink is missing, i need that for my script
<Kano> apw: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
<Kano> this one
<apw> Kano, yes that is correct, right now the revamp of the builds does not generate it
<Kano> can you add it again
<apw> it'll return at some point yes, it not the worst bug i have in the rewrite yet
<Kano> can your create it manually?
<Kano> i have got a tiny script that parses that url
<Kano> http://kanotix.com/files/fix/mainline/install-daily.sh
<Kano> i would love if there would be latest links for each kernel
<Kano> for 3.2 you could use ~rc
<Kano> btw. i have got several bug reports for realtek gbit nics, do you know of  a working fix?
<Kano> some use the "official" realtek driver as fix (outside tree driver, but that is no real solution)
<Kano> http://ubuntuforums.org/showthread.php?t=1022411&highlight=rt+8111&page=9
<apw> that sounds about right re: rtl drivers
<hrw> can someone check how many brightness level has on intel laptop?
<Kano> mal den pc wechseln...
<hrw> mine thinks about nearly 2mln levels - makes backlight applications useless
<apw> hrw in the real work it has many many, last i looked gsd was doing something stoopid and moving 3-4 steps out of the 8 at a time
<hrw> apw: with <3.1 kernel I had 15 steps and it was working 
<hrw> brb
<smb> If that should have meant intel gfx laptop. Mine has 10 or 1 depending whether you look at the acpi or intel subdir
<apw> hrw so you are on precise already ... hmmm
 * smb thinks the new releases codename will cause a lot of un-precise statements... 
<hrw> apw: on this laptop yes
<hrw> smb: acpi one reports 15 but do not react to changes, intel one reports ~2000000 levels and reacts to cahnges
<smb> hrw, The netbook I was comparing with is on Oneiric only, but behaves the opposite way. So acpi does react intel does not. But it also has an odd value in bl_power
<hrw> smb: I do nto use this laptop so often
<smb> hrw, So which setting is set to those ~2000000 max_brightness or something else?
<hrw> smb: max_brightness yes
<hrw> 1992060 to be exact
<smb> Hm, ok. Maybe always was an odd value somewhere. If you had a way to quickly boot back into an older kernel, you might check whether its acpi that changes there
<smb> Maybe just for some reason the newer kernel switched what it uses for control...
<hrw> would have to install older kernel and prefer to not do that now
<smb> hrw, Alternatively if you have an old desktop cd/dvd you could boot into trial mode there
<hrw> smb: booting to oneiric kernel would take less effort ;D
<smb> hrw, At least you would not have to _install_ an older kernel. ;)
 * smb tries to remember those backlight runes...
<hrw> acpi_backlight=vendor one?
<smb> Yes, just the other setting. video..?
<hrw> no idea
<hrw> I used acpi_backlight=vendor with <3.0 kernel
<smb> So that would force it not to use acpi
<smb> =video should be the opposite
<smb> Though that normally passes control to some vendor driver (like thinkpad_acpi or so...)
<hrw> asus_laptop here
<hrw> [   26.734876] asus_laptop: Backlight controlled by ACPI video driver
<smb> Hmmm
<smb> So have you used acpi_backlight=vendor for 3.1?
<hrw> nope
<hrw> BOOT_IMAGE=/vmlinuz-3.1.0-1-generic root=/dev/mapper/lucek-rootfs ro loop.max_loop=256 loglevel=0 pcie_aspm=force quiet
<smb> Then I would try that again...
<hrw> worth try cause fn+F6 does not bump backlight but gives acpi kernel errors
<hrw> [18360.424842] ACPI Exception: AE_AML_BUFFER_LIMIT, Index (0x0000000000000074) is beyond end of object (20110623/exoparg2-418)
<hrw> [18360.424866] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.STBR] (Node ffff880138a40118), AE_AML_BUFFER_LIMIT (20110623/psparse-536)
<hrw> [18360.424888] ACPI Error: Method parse/execution failed [\_SB_.PCI0.VGA_.LCDD._BCM] (Node ffff880138a392f8), AE_AML_BUFFER_LIMIT (20110623/psparse-536)
<hrw> [18360.424911] ACPI Error: Evaluating _BCM failed (20110623/video-364)
<hrw> [18360.424920] ACPI: Failed to switch the brightness
<smb> tbh, if you had to use it before it was likely because your acpi bios is broken (which would not be the first one). And that is not expected to be fixed by having a newer kernel...
<hrw> yep
 * smb forgot what _BCM meant exactly but it definitely was something controlling the backlight. 
<cking> the AML buffer limit is not pleasant, and _BCM sets the brightness level
<smb> something like backlight control method or so. just cannot remember
<smb> but yes
<smb> sounds like the value it reads from the ec is out of bounds
<cking> _BCM  -> (Set the Brightness Level) section B.6.3 of the ACPI spec
 * smb probably foolishly tries to find a meaning behind the acronym
<hrw> Backlight Control Method?
<cking> Brightness Control Method
<smb> that was my guess, yes. :)
<smb> Ok brightness then. :)
<smb> cking, Ta
<cking> I'd extract the acpi tables, disassemble the DSDT and look at it - you could extract the tables and run _BCM inside acpiexec and see what it's doing wrong 
<cking> http://smackerelofopinion.blogspot.com/2010/03/debugging-acpi-using-acpiexec.html
<hrw> thx, will check on tuesday while travelling
<brendand> herton - did you get my note on the maverick tracking bug?
<herton> brendand: yep, I changed the bot here, next time it should set the task automatically to invalid for maverick bugs
 * ogasawara back in 20
<jsalisbury> ogasawara, bjf, I've been seeing lots of duplicates and and increase of people affected for bug 843431 
<ubot2> Launchpad bug 843431 in linux "Logitech camera microphone does not work / makes "chipmunk" sound" [Medium,Triaged] https://launchpad.net/bugs/843431
<jsalisbury> ogasawara, bjf, there is a proposed patch in comment #42
<ogasawara> jsalisbury: ack thanks, I'll take a look in a bit
<jsalisbury> ogasawara, thanks, some of the duplicate bugs report the mainline kernel fixes the issue as well.
<ogasawara> jsalisbury: cool
<apw> jsalisbury, perhaps copy the information up into the main bug when you find useful things like that
<jsalisbury> apw, OK, I'll do that from now on
<apw> or like "duplicates say 'foo' see comment blah" and a link to it
<herton> ppisati: your ti-omap4 branch for oneiric doesn't pull clean, it's missing a change which was on main ti-omap4
<ppisati> uh?
<ppisati> let me check
<herton> ppisati: it misses "Make TASKSTATS require root access, CVE-2011-2494" change, probably was not up to date when you closed the release
<ubot2> herton: ** 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-2011-2494)
<ppisati> ok, let me fix it
<tseliot> is tgardner online today?
<smb> tseliot, no on vacation till friday (including)
 * herton -> lunch
<ppisati> herton: the fix was already in master, so we got it for free
<apw> tseliot, i assume what you needed tim for we covered ?
<tseliot> apw: absolutely. Thanks again guys
<apw> cool, good, yay
<jsalisbury> Do you happen to know if there is a way to identify if a system has a sandy bridge cpu?  Is there a flag in cpuinfo, or can I tell by the model name?
<apw> smb, where is the local version of your .33 tree
<apw> (not kernel.org)
<smb> apw git://kernel.ubuntu.com/smb/linux-2.6.32.y-drm33.z.git
<hggdh> herton: there?
<herton> hggdh: yep
<hggdh> herton: I had not noted the lucid tracking bug was not yet ready, and tested it -- and marked it done. Will it mess up the scheduler?
<hggdh> herton: bug 871899
<ubot2> Launchpad bug 871899 in kernel-sru-workflow/verification-testing "linux: 2.6.32-35.78 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/871899
<herton> hggdh: no, it's fine. There is still one bug to be verified for lucid, but I think it'll be. About the state is ok, just it would have to be retested if the verification "fails"
<hggdh> herton: good to know. And, of course, what I did is valid as long as there is no change to the package
<brendand> herton - when do you reckon we go to verification-done then? today or tomorrow?
<herton> brendand: It can be done today, I'll see what's pending
<smb> herton, would that be bug 614853 	
<ubot2> Launchpad bug 614853 in linux "kernel panic divide error: 0000 [#1] SMP" [Undecided,Fix committed] https://launchpad.net/bugs/614853
<herton> smb: correct. May be we can mark that as verification-done, since no one will be able to check that in 1 week it seems
<smb> herton, that is sadly correct
<smb> But I guess we can consider it ok as it has been passed quite a while in the ec2 topic branch
<herton> indeed. I'll comment on the bug and tag it, then release the update for the certification team
<smb> cool thanks
<herton> brendand: verification done, feel free start lucid testing
<brendand> herton - thanks!
<hallyn> oh fooi - after upgrading netbook from natty to ocelots, ad-hoc is once again not supported.  now i'll need to remember which driver i switched to that did :)
 * ogasawara lunch
<hggdh> bjf, smb: I have bug 879151 as from the testing on bug 872660, and I am holding my ack pending your review
<ubot2> Launchpad bug 879151 in linux-lts-backport-maverick "WARNING: at /build/buildd/linux-lts-backport-maverick-2.6.35/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0xb1/0xf0() " [Undecided,New] https://launchpad.net/bugs/879151
<ubot2> Launchpad bug 872660 in kernel-sru-workflow "linux-lts-backport-maverick: 2.6.35-30.61~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/872660
#ubuntu-kernel 2011-10-21
<EtienneG> hey guys!  Quick q.: when is the next SRU for lucid scheduled?
<herton> EtienneG: if everything goes well, current one will probably released next week, once testing finishes (current SRU being tracked in bug 871899)
<ubot2> Launchpad bug 871899 in kernel-sru-workflow "linux: 2.6.32-35.78 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/871899
<herton> the next one I think will be prepared right after UDS
<EtienneG> herton, cool stuff, thanks herton!
<EtienneG> herton, do we have a calendar, or a report, or somesuch to track these?  I'll bookmark it and refer t it in the future.
<herton> EtienneG: we have a report of all SRUs in progress here: http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
<herton> we also have a calendar, but it's not always reliable, because of regressions etc. it may offset sometimes
<herton> usually each SRU cycle is each 3 weeks
<EtienneG> herton, yeah, I understand the cadence is three weeks but likely to slip due to regression.  At least, if I can track what the *plan*, it is already a start!  :)
<herton> EtienneG: we have an internal google calendar with the likely schedule, but it's not public I think
<herton> s/it's not/nothing
<hggdh> herton: btw, did you see my comment on bug 872660?
<ubot2> Launchpad bug 872660 in kernel-sru-workflow/regression-testing "linux-lts-backport-maverick: 2.6.35-30.61~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/872660
<herton> hggdh: yep, https://bugs.launchpad.net/ubuntu/+source/linux-lts-backport-maverick/+bug/872660/comments/5
<ubot2> Launchpad bug 872660 in kernel-sru-workflow/regression-testing "linux-lts-backport-maverick: 2.6.35-30.61~lucid1 -proposed tracker" [Undecided,In progress]
<hggdh> herton: I agree, but I needed it. I cannot decide for the kernel team
<herton> hggdh: sure, no problem. This warning shouldn't hold the update
<hggdh> herton: all yours to promote to updates
<herton> ack
<hggdh> now, for the next
 * ogasawara back in 20
<herton> ppisati: on next fsl-imx51 update, you will be able to use verify-release-ready from kteam-tools to check for common problems like missing tracking bug etc., before pushing. The same is true for all other arm branches, except mvl-dove from maverick, as the script doesn't like the lucid version being used, I'll take a look if it's feasible to fix
<herton> ops, in fact on mvl-dove from maverick it doesn't like the missing abi files
<ogra_> lucid is dead for armel
<ogra_> EOL message should have gone out last week (sadly it wasnt yet), dont put work into lucid distro stuff
<herton> ogra_: true for lucid mvl-dove, but maverick mvl-dove should still be updated from what I got
<ogra_> herton, i was more referring to fsl-imx51
<ogra_> dove exists in maverick, but to my knowledge we never supported a kernel for it
<ogra_> (in maverick that is)
<herton> ogra_: good news, once official word gets out
<ogra_> yeah, i was promised the announcement for last friday ... i'll hunt down kate today
<gentoo_drummer> I used the command line installation since i hate unity and installed xfce. the system is incredible fast, even quicker than my debian and i was wondering if someone could tell me how can i get the default ubuntu font rendering
<gentoo_drummer> any ideas guys/
<gentoo_drummer> ?
<ogra_> and you expect the kernel team to know that ? thats brave :)
<gentoo_drummer> :P
<ogra_> try #ubuntu-desktop ;)
<gentoo_drummer> well.. i assume that kernel team tweks with things
 * ogra_ guesses they are to understaffed to have time for that :)
<ppisati> herton: cool, thanks! :)
<hggdh> herton: do we have a backport from Oneiric?
<ogra_> herton, so i just talked to kate ... the actual 18 months for lucid are only over on the 29th so EOL announcement for lucid will go out then, but please dont do any kernel work on lucid arm kernels anymore, would be wasted time
<herton> hggdh: yes, tracked in bug 878811
<ubot2> Launchpad bug 878811 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-13.21~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/878811
<herton> ok
<hggdh> herton: it does not show up on http://people.canonical.com/~kernel/reports/sru-report.html ?
<herton> hggdh: no, I don't know why, bjf ^
<hggdh> herton: since I already have lucid loaded, I will go ahead and do 878811 also; of course, may redo if verification fails
<herton> hggdh: ok. http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html lists it though
<bjf> herton, hggdh, will look into it
<ogra_> herton, so i also just confirmed again, there was never a dove kernel in maverick, if there is thats a big mistake and its definitely not supported by any of us (or you)
<herton> hmm ok
<herton> going to lunch, bbl
<bjf> ogra_: that is quite amusing since we did ship a mvl-dve maverick kernel (2.6.32 based) and have been supporting it since release
<ogra_> bjf, yes, we never should have done that, that kernel was for NCommanders tests and should have been removed from the archive before release day
<ogra_> bjf, wrt dove in maverick we only support the userspace
<bjf> pgraner: ^ nice eh?
<ogra_> (sorry, i didnt even know that kernel exists, i (nor anyone else but NCommander) wasnt involved in dove after lucid)
<ogra_> the more intresting question is, is there a way to remove it from a released archive ....
<ogra_> if its there now, i guess it should see security maintenance at least, would be good to avoid that
<bjf> ogra_: we work on it every 3 weeks
<ogra_> ugh
<ogra_> what a waste of manpower
<hggdh> herton, bjf: bug 879516, I am failing this kernel
<bjf> hggdh: any reason that bug is private ?
<hggdh> bjf: a security test failed
<hggdh> bjf: you should have access, I subscribed the kernel team
<hggdh> bjf: I will move straight ahead to the Oneiric proposed kernel now, and check it
<bjf> herton, hggdh, the lts-backport-oneiric tracking bug is not on the sru-report because the tracking bug was not added to the changelog
<hggdh> bjf: ah, thank you
<herton> bjf: ack, I thought it could be this, since we weren't able to create the bug report earlier
<herton> and put in the changelog
<hggdh> herton: jj found the issue on the oneiric backport to be a test case failure; as such, I am tagging it -passed
<cnd> bjf, do you know who does the wiki gardening for the kernel team?
<cnd> I'm wondering how to create a table with borders
<bjf> cnd we've let it go to weeds
<cnd> urg
<bjf> cnd there's a moin style/syntax help page that explains it
<bjf> i think
<cnd> I can't find anything on borders though
<cnd> and the ubuntu wiki by default doesn't show borders
<cnd> which makes it hard to read tables
<cnd> oh wait, I can check the release schedule page
<cnd> that has borders
<cnd> or not
<herton> hggdh: ok, cool
<tathi> I just reformatted an old ubuntu box and installed 11.10, and while it installed the rt61pci driver automatically, my wireless card isn't picking up the router's SSID.
<tathi> (connect to hidden network works fine, as do all other computers in the house)
<tathi> Should I be reporting this as a bug?
<ohsix> how long did you wait for the ap to show up
<tathi> It took me probably 15-20 minutes to figure out how to get it up, find the SSID from another box, and all that.
<tathi> So long enough, I think.
<ohsix> there are a few moving parts, and unless something is very broken it's not the kernel or the driver
<tathi> Hrm.
<ohsix> nm-tool can display what networkmanager sees, the applet might have its own criteria for displaying stuff
<tathi> Any other suggestions?  It worked fine under Ubuntu 9.04 this morning, then I spent an hour or so reinstalling.  Didn't move the computer, so the hardware should still be fine.
<tathi> What applet?
<ohsix> that fancy thing on your desktop that actually shows a list of things to connect to is just a small part of it
<tathi> Ah.  I was mostly poking around with command-line tools, though I didn't change anything.
<tathi> lspci, iwlist, lshw, that sort of thing.
<ohsix> nm-tool should pretty much tell you all you need to know, delete the connection for the ap you're trying to accessing, disable networking, reenable; check and see if nm-tool shows the ap you're interested about
<tathi> I'll try that.  Thanks!
<tathi> Nope, same thing.
<tathi> Well, I suppose I could pull the card and test it on another computer in case it randomly broke at the same time I upgraded the software...
<tathi> Seems odd that it can connect fine though.
<ohsix> same thing what? nm-tool doesn't list the ap?
<tathi> right.
<tathi> If it's connected, it lists the normal stuff.
<tathi> Disconnect, and it still lists the ap.
<ohsix> what driver was it again?
<tathi> disable networking and delete entry, enable it again and still no ap.
<tathi> rt61pci
<ohsix> can you post the output of dmesg to a pastebin
<tathi> grr...don't have xclip.  yeah, hang on.
<tathi> http://pastebin.com/ebpjssCs
<tathi> Is this the right place to ask this?  I could go find someone else to bother... :)
<ohsix> well, #linux-wireless
#ubuntu-kernel 2011-10-22
<erle-> what team is in charge for proprietary drivers (fglrx)?
#ubuntu-kernel 2011-10-23
<Omie__> Hi! I need some help understanding memory allocation during boot process
<Omie__> I wish to get myself some space allocated and I need its physical address..
<Omie__> I started with alloc_bootmem but realized it returns virtual address too 
<Omie__> i also looked at alloc_low_mem in mm/init_32.c, placing code in init/main.c .. at start_kernel() etc.. 
<Omie__> not quite getting it.. anyone could point me at right direction ?
<Omie__> is there anyone reading this ?
<Ceno3x> Hi guys. I'm trying to build a source package from a custom kernel I'm doing but I can't seem to find information on how to do it anywhere
<Ceno3x> I want the source package so then I can upload it to launchpad. Could someone give me a pointer in the right direction?
#ubuntu-kernel 2012-10-15
<parampam> hello, I've been trying to build the mainline kernel (from kernel.org) and even though it compiles every time I boot it hangs at "loading ramdisk", when I boot with nomodeset the system boots, but the resolution is messed up
<parampam> I'm using nouveau, is there anything ubuntu specific that I need to do besides fakeroot make-kpkg --initrd --append-to-version=-some-string-here kernel-image kernel-headers
<parampam> ?
<parampam> the 3.6 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6.2-quantal/ works fine
 * smb yawns
 * henrix -> lunch
<black_puppydog> hey all. I just read about the "new" send/receive feature of btrfs and asked myself if there are any apps in development to use this feature for fast backups? 
<xnox> black_puppydog: offtopic for this channel =) as you are asking about userspace tools....
<black_puppydog> yeah, I thought that too, but xouldnt come up with the right channel for this. any pointers?
<xnox> black_puppydog: #ubuntu or #ubuntu-server
<black_puppydog> ok, #ubuntu seemed too general, but why #ubuntu-server ?
<black_puppydog> I am talking abouta normal desktop machine
<black_puppydog> well, laptop actually, still....
<ashwini> http://codepad.org/0eVoe3vI kernel module, http://codepad.org/tkbUSE6r user code, http://codepad.org/C2fxD5Yv make file : I am trying to write a simple char driver, using mmap in user space. The problem is my code is working fine for 20 - 4K bytes, but I want to mmap 10024 bytes. At this value (BUFF_LEN 10024 and +) it is crashing. Any idea how to make it work for 10024 ? or any hint or suggestions ?
<xnox> black_puppydog: you can try #ubuntu-desktop. #ubuntu-server has more poweruser crowd who are more lickely to take backups =)
<ppisati> apw: are you around?
<apw> ppisati, yep
<ppisati> apw: cool, is your panda hooked up?
<apw> ppisati, its off and not where i am right now, what do you need?
<ppisati> apw: nothing, just a check
<apw> ppisati, i can boot and update it tonight if that is useful
<ppisati> apw: do you connect it to an hdmi or dvi monitor?
<apw> i use the connector nearest the edge of the board 
<ppisati> apw: and your monitor?
<ppisati> apw: do you remember if you are using an hdmi->dvi cable or hdmi->hdmi cable?
<apw> ppisati, i cannot visualise it right now, monitor has both
<apw> i'd have to look at it in the flesh
<ppisati> apw: ok, anyhow, if you can try beta2 on it that would be nice
<apw> ppisati, rather than the release ?
<ppisati> apw: yeah, you should get a black (or blue) screen before installer comes up
<ppisati> apw: at least, it happens to me and jsalisbury
<ppisati> apw: bot to ogra and rsalveti
<ppisati> *not
<apw> odd
<ppisati> apw: this while using the hdmi output on the board and an hdmi->dvi cable
<jsalisbury> ppisati, I see it when using the DVI output and an hdmi->dvi cable
<ppisati> jsalisbury: right
<rtg_> apw, I've got 3.7-rc1 rebased and am finding the configs generation to be quite tedious. I know you've had a slicker way of doing this in the past. Care to share ?
<apw> rtg_, as in how do i do the update configs part ?
<rtg_> apw, right, I keep having to repeast many of the same answers for each flavour/arch
<apw> rtg_, i do that via "script"
<apw> rtg_, so i run script, in the contained shell i make updateconfigs
<apw> rtg_, then i answer for one arch
<apw> rtg then i give up, and ^C and exit the script
<rtg_> apw, then append your answers to the common config ?
<apw> rtg_, then i use chinstrap:~apw/config2rules on that file
<apw> rtg_, and put that in debian.master/config/OVERRIDES, then run updateconfigs
<apw> making sense ?
<rtg_> apw, OVERRIDES is what I was looking for.
<apw> rtg_, then i do the same next arch adding to OVERRIDES until done
<rtg_> apw, yep, makes sense
<rsalveti> ppisati: so it seems there are a lot to test actually
<rsalveti> dvi alone, hdmi alone, dvi+hdmi cable, hdmi+dvi cable and different board revs
<ppisati> rsalveti: ?
<rsalveti> because with my setup, and with my boards, I'm not able to reproduce this issue at all
<rsalveti> I just need to find a hdmi->dvi cable here
<ppisati> rsalveti: that's why i'm trying to get more people to test it
<ppisati> rsalveti: so far, me and jsalisbury can reproduce it
<ppisati> rsalveti: you and ogra no
<rsalveti> ppisati: please also document at the bug all the board revs you tested
<ppisati> rsalveti: done
<rsalveti> great, thanks
<ppisati> is there a way to kick a QA test?
 * jsalisbury needs to reboot.  brb
<ppisati> ogra_: ^
<bjf> ppisati, what exactly are you asking?
<ppisati> bjf: that they take a panda, and try to reproduce lp 1065902
<ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
<ppisati> bjf: with their hw setup
<bjf> ppisati, you can ask hggdh, i know they have several
<ppisati> bjf: if they have more setups, better
<ppisati> hggdh: ^
<bjf> ppisati, hggdh would know what testing they are currently doing with them
<ogra_> ppisati, yeah, what bjf said
<hggdh> ppisati: sorry, was in a meeting
<hggdh> ppisati: what do you need there?
<ppisati> hggdh: we would like to ask you to try and reproduce lp 1065902
<ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,Confirmed] https://launchpad.net/bugs/1065902
<ppisati> hggdh: how many panda setups wo you have in the QA lab?
<ppisati> hggdh: just dd beta2 img on an sd card, pop into your panda, boot it and wait a couple of minutes
<ppisati> hggdh: if the desktop doesn't show up (you get a black/blue screen) you hit that bug
<hggdh> ppisati: where is the beta2 image?
<ppisati> hggdh: else it's ok
<ppisati> hggdh: it's all written in that lp bug
<hggdh> ppisati: if it helps any, I already reproduced it locally
<ppisati> hggdh: good to know
<ppisati> ogra_: rsalveti ^
<hggdh> (my setup is similar to yours, HDMI->DVI connection
<ppisati> then it's not just me and jsalisbury 
<hggdh> ppisati: IIRC, I also added the bug to the ISO QA list -- don't really remember, though, ran a truckload of tests during the weekend
<ppisati> hggdh: nice, thanks
<hggdh> yeah, I added it to the ISO results
<rsalveti> ppisati: were you able to reproduce it with a real hdmi connector/monitor?
<rsalveti> or with the dvi->dvi
<ppisati> rsalveti: hdmi on the board, dvi on the lcd -> i get it
<ppisati> rsalveti: hdmi on the board, hdmi input (e.g my tv) -> it's ok
<rsalveti> ppisati: and dvi->dvi?
<ppisati> rsalveti: dvi output on the board, hdm9
<ppisati> rsalveti: hdmi->dvi cable to my lcd (ok, but crappy resolution)
<rsalveti> ok, thanks
<ppisati> brb
<skaet> ogasawara, is there an ETA on when the release notes updates from kernel team will be done?
<ogasawara> skaet: doing it now
<ogasawara> skaet: 20min?
<skaet> thanks.   :)  that'll help.
 * ppisati -> gym
<JoseeAntonioR> ogasawara: hey, have a second for a PM?
<ogasawara> JoseeAntonioR: busy at the moment, feel free to message me and I'll get to it when I can
<JoseeAntonioR> thanks
 * rtg ->  lunch
<develtech> hi
<develtech> every one! i have question regarding tcrypt module 
<develtech> any one used trcrypt
 * henrix -> EOD
 * rtg_ -> EOD
#ubuntu-kernel 2012-10-16
<tjaalton> hmh, power consumption is up on quantal, my t420s takes 15W when it used to take only 7-8W on precise
<tjaalton> while idle
<hyperair> that's a huge difference.
<tjaalton> yeah
<tjaalton> double-checked that it's not using optimus :)
<hyperair> hm
<caribou> guys, I have a git bisect question for you
 * hyperair has noticed power consumption increases over the years, but couldn't really attribute it to power consumption regressions or battery degradation.
<caribou> I have an issue where it works on older kernel (3.2.0-29.46) and fails in newer kernel (3.2.0-31.50)
<tjaalton> powertop doesn't show the acpi estimate anymore, so I'm looking at the gnome power stats
<hyperair> tjaalton: acpi can estimate? i thought that was purely a powertop calculation.
<tjaalton> huh, now it shows ~9W
<caribou> which git bisect bad/good version should I use ?
<caribou> git bisect start Ubuntu-3.2.0-31.50 Ubuntu-3.2.0-29.46 ???
<hyperair> caribou: bisect was meant to find regressions, so bad is always after good.
<hyperair> if you're trying to find a commit to cherrypick, you have to manually invert that logic yourself, or git bisect gets confused.
<caribou> hyperair: so since I'm after a regression, the command above would be correct then ?
<hyperair> caribou: yep
<caribou> hyperair: great, I wasn't too sure and I don't want to start bisecting the wrong way !
<caribou> hyperair: thanks a lot
<hyperair> caribou: np. and yeah i know how terrifying kernel bisects are :-)
 * hyperair had to run a 20-step bisect once
<hyperair> that was horrifying
<caribou> hyperair: well, this one is ~8 steps. 
<hyperair> ah have fun
<caribou> hyperair: an issue with iscsi hanging the kernel with latest Precise kernel
<caribou> hyperair: https://bugs.launchpad.net/bugs/1056746
<ubot2> Launchpad bug 1056746 in linux "kernel panic on iscsi target disconnect" [High,Incomplete]
<hyperair> hmmmm maybe it wasn't 20 steps.. 2^20 seems to be on the order of a million commits or so
<tjaalton> ok, the power consumption is back to normal levels, dunno what was wrong there for a (long) while
<hyperair> hmm.
<hyperair> weird.
<cking> tjaalton, how are you measuring power consumption?
<cking> try measuring using "powerstat"
<tjaalton> cking: oh, didn't know of that tool
<tjaalton> just used gnome power applet (?)
<cking> tjaalton, its one I hacked up when doing ACPI battery calibration tests last cycle
<tjaalton> ah, nice
<tjaalton> ~7.8W with bluetooth turned off
<cking> tjaalton, that sounds better
<tjaalton> yes :)
<psivaa> apw ping
<psivaa> apw: re bug 1066883, i have tried with 3.5.4 and it fails with that too with plymouth-splash enabled
<ubot2> Launchpad bug 1066883 in linux "Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
<apw> psivaa, when you say "without plymouth-splash" is that just removing splash from the command line ?
<psivaa> apw: i renamed /etc/init/plymouth-splash.conf to /etc/init/plymouth-splash.conf.disabled
<apw> psivaa, so did you try removing splash at grub?  did that work also?
<psivaa> apw: i did not try removing splash at grub
<apw> psivaa, that would be a good test as well
<psivaa> apw: ill try that now then
<psivaa> apw: i tried with kernel command line disabling of quite splash with 3.5.3 but its failing on that
 * henrix -> lunch
<smartboyhw> Er when will the 3.7-rc1 mainline build be built?
<apw> if smarty was here, i could tell hi that they are building now
<habach> Hi, I am too new here and have some silly questions, why I cant see any chatting?
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> habach, it is release week so people are busy, but ask and you may even get an answer :)
<ppisati> reboot, brb
<rtg> apw, dropping the async rootfs patches fixed the 3.7-rc1 boot problem. I pushed the reverts and will reset the tag to a working commit
<apw> rtg, ack
<ricotz> rtg, hi, thanks for rebasing ubuntu-r :)
<rtg> ricotz, looks like its working now
<ricotz> is the latest branch suppose to built
<ricotz> hmm, i see
<rtg> ricotz, master-next is the current working version. the tag is Ubuntu-3.7.0-0.1-rc1
<ricotz> i am running into this error "cp: cannot stat `drivers/media/dvb/dvb-core/*.h': No such file or directory"
<ricotz> building with http://paste.debian.net/plain/201094
<rtg> ricotz, fdr clean;echo "dpkg-buildpackage -B -us -uc 2>&1 |tee log.txt"|schroot -c quantal-amd64
<rtg> assuming you have a quantal schroot
<ricotz> rtg, i don't ;)
<ricotz> but i don't want to build all flavors
<rtg> you don't need one, it'll build on precise or quantal
<ricotz> just the generic one
<rtg> ricotz, there is only one flavour now
<ricotz> oh
 * rtg -> lunch
<ricotz> rtg, thanks
<apw> bjf, can we stagger the builds for SRUs, you are eating the distro buildds and it is release week
<bjf> apw, henrix ^
<bjf> henrix, let's hold off until after the release
<henrix> apw: ah, sure. i've uploaded oneiric and lucid only
<bjf> apw, can they just be re-queued and have their priority dropped?
<apw> henrix, it is best to confirm on #ubuntu-release before dropping things on the queue during release week
<apw> bjf, no as the buildds are idle, so they pick up the job regardless
<henrix> apw: ack, i'll do that.
<apw> bjf, as long as we have only one building at once, we'll likely not get told off
<apw> henrix, its just this week thats critical
<henrix> apw: sure. i'll hold off any uploads
<henrix> apw: and ping the release channel first
<apw> cool thanks
<bjf> henrix, you can have everything else ready and when the release goes out, upload
<henrix> bjf: ack
<apw> sounds great
<bjf> henrix, this cycle has an extra week in it anyway due to UDS
<henrix> bjf: yep, makes sense. so i'll hold all the uploads for now.
<henrix> bjf: i was too eager to try my new powers :)
<bjf> lol
<bjf> henrix, they should only be used for good, not evil
<henrix> bjf: heh
 * henrix -> EOD
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues November 13th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<geofft> What's the right way to write a (local) package that includes a kernel module?
<hallyn> hey - in which package is the openvswitch kernel module from upstream shipped?
<hallyn> seems like it should be in generic..
<hallyn> hm, is it built-in?
<rtg_> hallyn, might be
<hallyn> nope
<hallyn> but i can't find the module...
<rtg_> hallyn, CONFIG_OPENVSWITCH=m for ubuntu-r
<hallyn> and q
<rtg_> checking
<rtg_> net/openvswitch/
<rtg_> hallyn, is that what you're looking for ?
<hallyn> rtg_: find /lib/modules/ -name "openvswitch*" gives me nothing
<hallyn> (on a fresh quantal instance)
<rtg_> hallyn, did you install extras ?
<rtg_> linux-image-extras*
<hallyn> trying
<rtg_> hallyn, you should be using the meta package for -server or -generic
<hallyn> rtg_: I'm not installing a kernel, just firing up canonistack instances with latest quantal ami
<hallyn> should those be installed by default?
<hallyn> assume not if called 'extras' :)
<rtg_> hallyn, since that uses the -virtual meta package, linux-image-extra won't be installed
<hallyn> rtg_: sudo apt-get install linux-image-extra-virtual worked for me, thanks!
<rtg_> hallyn, np
<hallyn> i suspect openvswitch-datapath-source's README.debian should mention that.  (but will note that for later)
 * rtg -> EOD
<arges> sforshee, hi
#ubuntu-kernel 2012-10-17
<bizhanMona> Hello, I am trying to debug an issue using debug version of the Ubuntu kernel. My questions, what package I need to download for ubuntu kernel source for 12.04? and how to recompile it? Thx
<cking> smb, http://stackoverflow.com/questions/11002316/meaning-of-g-inline-assembly-constraints-equals-vs-plus-etc
<diwic> hi, what's the easiest way to look at the assembly code for a function in the precise kernel?
<diwic> never mind, found it
<Hauke> where do I find the git repo this change was mad against? http://patchwork.ozlabs.org/patch/182913/
<Hauke> for kernel 3.7 CONFIG_MEDIA_USB_SUPPORT should also be activated
<Hauke> and CONFIG_NF_NAT_IPV4=m
 * henrix -> lunch
<rtg> ogasawara, grumble. bug #1067543
<ubot2> Launchpad bug 1067543 in linux-backports-modules-3.2.0 "Add comapt-wireless v3.6 stack to Quantal LBM" [Undecided,New] https://launchpad.net/bugs/1067543
<sforshee> Hauke, if you haven't found the git repo for those config changes yet it's git://kernel.ubuntu.com/ubuntu/kteam-tools.git
<ogasawara> rtg: bah, I'll send an update.
<rtg> ogasawara, I had to chuckle when I saw that given our previous conversation.
<needhelp112> hello 
<needhelp112> maybe somebody can help me:
<Hauke> sforshee: thanks for the link
<needhelp112> can somebody explain me, where i can find the implementation of the wireless lan active scanning interval?
<needhelp112> i've seen that different devices are sending probe request (active scanning for access points) in different intervals
<needhelp112> but, i don't know where the "scanning behavior" is implemented
<needhelp112> maybe somebody can help me?
<Hauke> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc1-quantal/ misses linux-headers-3.7.0-030700rc1_3.7.0-030700rc1.201210161007_all.deb
<rtg> Hauke, might be awhile before we get to that. apw is working on release tasks.
<apw> hmmm
<cking> apw, hmmm?
<apw> cking, lack of headers, odd
<cking> ah
<Hauke> rtg: thank's for the info
<sforshee> apw, missing headers seems to be due to some reorganization of drivers/media. Some cp commands referencing that path are failing.
<marrusl> hi folks...  I have some reports of random ivybridge system freezing esp under io load, but hard to pin down.  And I have to say I'm seeing the same pattern on my sandybridge asus.
<marrusl> seems like some fixes have been released for freezing issues, but they don't seem to be gone.  just curious if there were other current open bugs... what I can do to help, etc.  I'm trying mainline 3.6.2 right now on my machine.
<marrusl> my customer seems to be having success with mainline/v3.6.1-quantal/
<apw> sforshee, indeed we sort of knew that headers change was coming
<jsalisbury> marrusl, I can perform a revers bisect since there is success with 3.6.2.  We just need to identify the last version that had the bug.
<marrusl> jsalisbury, it's not direct to reproduce, but I have a couple of ideas to do so.
<jsalisbury> marrusl, it would be good to know the results of 3.6.2 and 3.5.7
<jsalisbury> marrusl, ok
<marrusl> jsalisbury, it seems to me that for a while now, whenever I install a new KVM machine, my system performance just dies.  and I do get syslog messages.
<marrusl> jsalisbury, ok, then we should be able to further trace the commits back to 3.2?
<jsalisbury> marrusl, sure if that is when this issue started happening.  Does it happen in Precise?
<marrusl> jsalisbury, we'll have to see if my problem is precisely the same as the customers.  they are ivybridge/precise , I'm running sandybridge/quantal.
<marrusl> the descriptions are really feel similar (I know, i know...)
<jsalisbury> marrusl, ahh, ok
<apw> psivaa, hey ... i've just asked for some dmesg's on that boot race thing
<marrusl> but yeah, i have no idea if it's the same.  or if we're looking at a whole pack of bugs.   
 * marrusl shakes fist at intel
<psivaa> apw: sure ill add them to the bug
 * smb wonders about this connection still working...
 * smb waves to cking 
<cking> smb, it seems to be working
<smb> Ah good, it seems all of Canonical was gone for a moment...
<bjf> smb, mumble keeps dropping on me here
<smb> bjf, Well I claims to be up for me, but nobody would answer my screams... :)
<bjf> smb, i don't see you in my mumble client
<smb> Ah, now it realized it is in trouble
<psivaa> apw, the dmesg's are attached now, sorry i had to do a fresh install, hence the delay
 * sforshee is reminded he has parent-teacher conferences today, back later
 * ppisati -> gym
<cking> bah, mushed up my chroot
<marrusl> jsalisbury, ha.  already had a gpu lockup (which wasn't a symptom before) on 3.6.2.
<marrusl> maybe i should try something else.
<jsalisbury> marrusl, Maybe test the Precise kernel to see if you can reproduce the issue like the Customer?
<marrusl> jsalisbury, is there a 3.2 build for quantal?
<marrusl> reinstalling is not appealing.  though I won't rule it out.
<jsalisbury> marrusl, sure.  You should be able to install any of the 3.2 kernel debs on a quantal system.
<jsalisbury> marrusl, One second, I'll post a link to all the Precise kernels.
<marrusl> jsalisbury, whew
<marrusl> yes, I assume this will be beyond the powers of apt
<jsalisbury> marrusl, This is the top level page for all Ubuntu releases:
<jsalisbury> https://launchpad.net/ubuntu/+source/linux
<jsalisbury> marrusl, Precise specific kernels are at:
<jsalisbury> https://launchpad.net/ubuntu/precise/+source/linux
<jsalisbury> marrusl, Drill down into the specific kernel version under "Releases in Ubuntu"
<jsalisbury> marrusl, on the next page, drill down for your arch under "Builds"
<marrusl> this thread seems to be on point... I've been seeing "CPU0: Package power limit notification (total events = 159)" for a while
<marrusl> https://bbs.archlinux.org/viewtopic.php?pid=1176631
<marrusl> well, i'll get more details as I go.
<Eimann> is there any reason why the non-platform specific headers package isn't build properly in the daily builds at the moment?
 * Eimann checks the build.log
<Eimann> apw: do you know this out of your head? I don't  see anything strange with dh_builddeb
<apw> Eimann, for 3.7-rcX?  yes the headers have moved
 * cking -> EOD
<Eimann> apw: yes 3.7-rc
<Eimann> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
<apw> yep headers have moved upstream and will take a bit of fixing
<kamal> rtg: regarding Kyle Fazarri's Cypress driver pull requests ...  You say we should only use the "cherry picked from" syntax for refs into Linus' tree?   Precise commits shouldn't include "cherry picked from" references to Quantal master branch?  (Do we not consider quantal master immutable at this point?   I'm not arguing, just trying to fix my own mis-understanding).
<rtg> kamal, Quantal is only just now immutable, but as a rule of thumb commit without context are always from Linus' repo
<rtg> commits*
<kamal> rtg: ok, got it.   so we note that you ACK'ed both of the SRU's anyway despite that glitch, and despite the improper BugLink: syntax.   Should we clean them up and re-submit, or  will you make those fixes for us at apply time?
<rtg> kamal, I'll fix them when I apply. I was just awating a second ACK (which I now have)
<kamal> rtg: got it, ok thanks very much\
<rtg> kamal, I'm currently working on squashing ubuntu-r which has about a bazzilion commits
<kamal> rtg: yeah, you have fun with that :-)
<rtg> kamal, its a giant pain in the ass
<bizhanMona> Hello, I am trying to debug an issue using debug version of the Ubuntu kernel. My questions, what package I need to download for ubuntu kernel source for 12.04? and how to recompile it? Thx
 * rtg -> lunch
 * henrix -> EOD
<zenx> I am trying to build util-linux but it gives an error compiling. Checking the logs it mentions that uclibc was built without large file support but I have it selected in the config
<zenx> ups
<zenx> wrong channel
<rtg> ogasawara, pushed ubuntu-r with a major fold down. I've still got a few of the patches that I need to breakup before I can finish folding down the debian directories. This insight has given me some thoughts on how to judge incoming config patches, i.e., break them up if they're gonna write outside the deian directory (as many of our ubuntu directory patches do)
 * rtg -> EOD
<ogasawara> rtg: ack
<ogasawara> rtg: I thrown down a note in the config blueprint I file to remind us to chat about it
<rtg> ogasawara, good
<maxb> Is it possible to have update-initramfs search and use modules from /lib/modules/$(uname -r)/extra ?
<maxb> I have a really really weird problem on an Asus UX21A ... Pressing Fn+F5 ("brightness down") works as expected but Fn+F6 ("brightness up") when pressed multiple times seems to block further hotkey events for a few seconds. I've chased this as far as seeing that the delays are visible in the ACPI events viewed via acpi_listen. Can anyone suggest further things to look at to figure out whether or not this is a BIOS problem?
#ubuntu-kernel 2012-10-18
<StFS> Hi. I filed a bug because the headphone jack on my dock doesn't work and I'm told that some line has to be added to a "quirk table". I found a line for a T430s in sound/pci/hda/patch_realtek.c and I want to add one for my model (the T430).
<StFS> the line I found is: SND_PCI_QUIRK(0x17aa, 0x21fb, "Thinkpad T430s", ALC269_FIXUP_LENOVO_DOCK)
<StFS> so my question is basically, how do I figure out what the values should be for my computer/dock?
<StFS> the bug I filed is here (it has more hw info): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1060372
<ubot2> Launchpad bug 1060372 in linux "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,Confirmed]
 * cwillu_at_work looks at smb suspiciously
<cwillu_at_work> smb, recall anything about [PATCH] sched: Fix race in task_group()?
 * smb hasn't done nuthing anywhere
<cwillu_at_work> well, lkml says you reported the bug it fixed :p
 * smb remembers vaguely... more than two days ago...
<smb> ;)
<cwillu_at_work> as it happens, bisect blames that patch for my server not booting anymore :p
<smb> I believe lkml says it was Peter who fixed it. Me merely was anyoing him enough
<cwillu_at_work> is he on irc?  I wish to annoy him too! :p
<smb> Nah, not here... an I wonder whether that bisect is really true...
<cwillu_at_work> I'm pretty confident
<cwillu_at_work> I was already suspicious of that patch before I started
<cwillu_at_work> it's one of 16 patches that 3.6-rc1 and 3.5.5 have in common
<cwillu_at_work> and those are the two kernel versions that stopped booting
<smb> Would "noautogroup" change something there?
<cwillu_at_work> https://lh5.googleusercontent.com/-0DY-YYhgvzs/UHdB-BQdzMI/AAAAAAAAAEg/QhY9rgxnv98/s811/2012-10-11  <- crash in question
<cwillu_at_work> which, on the kernel cmdline?
<smb> yep
<cwillu_at_work> give me a minute to try
<cwillu_at_work> smb, yep, it boots with noautogroup
<smb> cwillu_at_work, Ok, I might have to admit it is related. :-P Wonder what on your server is so different that it happens while on none of those I use it does...
<cwillu_at_work> well, it's probably older than most things you're testing
<cwillu_at_work> it's a lucid box
<smb> That maybe, but this is in a very central place in the kernel, used not only on server and I would not think any netbooks especially powerfull... 
<smb> Hm, anyway, you should make it fail with a current kernel (for which there are still ddebs I could pull) and create a bug report with the trace, kernel version and bisection result in it
<cwillu_at_work> the trace is rather hard to get too
<cwillu_at_work> to
<smb> So it is not always showing up?
<smb> Or just scrolling off
<cwillu_at_work> scrolling off, early'ish in boot
<cwillu_at_work> I haven't had any luck getting netconsole to work, but that may just be me mistyping an address
<smb> Hm, there was also some option to make earlyprintk crawl...
<smb> or maybe pause_on_oops=<seconds>
<cwillu_at_work> well, the trick is more getting something better than a photo, no? ;p
<smb> ah here boot_delay=<milliseconds> (but below 10000)
<cwillu_at_work> I can get a photo every time
<smb> As long as the photo is not so blurry that my eyes and brain hurts it is ok
<smb> yours is not bad
<cwillu_at_work> well, was the above so blurry that your... k :)
 * smb has seen much worse
<smb> And that one at least has most of the top of the message which is also sometimes a problem
<cwillu_at_work> yeah, if I leave it for more than 2 seconds, a whole whack of other oopsen show up
<cwillu_at_work> short enough that autofocus becomes a problem :p
<smb> Heh, yeah
<cwillu_at_work> pause_on_oops sounds useful there though
<cwillu_at_work> suspect I'll make that a local default
<smb> Hm, on a quick glance at the code the most likely cause would be that p->sched_task_group has not been set when set_task_rq() tries to access things from it...
<smb> but that should be at least set to &root_task_group...
<smb> cwillu_at_work, Just to be sure, this happens on that machine also with the default/stock ubuntu kernels (to rule out any slightly different configuration)
<cwillu_at_work> smb, lucid remember :p
<cwillu_at_work> the kernels on the mainline page don't install from 3.6 onward
<smb> and a 3.6 kernel in the crash ;)
<cwillu_at_work> (complaints about libc)
<cwillu_at_work> smb, btrfs on anything but the latest kernel is suicidal
<cwillu_at_work> (I have extensive backups, etc)
<cwillu_at_work> but the kernel config is just a make oldnoconfig after cp'ing the existing stock config from /boot to .config
<cwillu_at_work> smb, I'm not looking for support, I'm just looking for the right body to poke to get it fixed in mainline :p
<cwillu_at_work> although the noautogroup suggestion was useful, and allows me to get actual btrfs testing work done in the mean time, for which I'm grateful :)
<smb> cwillu_at_work, Still that does not answer the question: Have you seen the crash with for example the mainline kernel we build? 
<cwillu_at_work> you don't build a 3.6 mainline kernel that will install on lucid
<smb> ?
<smb> Have you tried?
<cwillu_at_work> sec, I'll get the exact error, but yeah, I've tried
<cwillu_at_work> if memory serves, it's a libc version bump from quantal that it doesn't like
<smb> hm, ok... that in some way sounds familiar
<cwillu_at_work> (just waiting for linux-image-3.6.2-030602-generic_3.6.2-030602.201210121823_amd64.deb and company to download
<cwillu_at_work> I don't blame you for making me check of course; rule #1 in #btrfs is "The user lies" ;p
<smb> cwillu_at_work, Btw, don't know whether you know, you could checkout upstream kernels and then take the patches from the mainline page of the same version and then locally build with the exact same config
<smb> cwillu_at_work, Well, not only btrfs ;-P But even without that there is enough space for misunderstandings
 * xnox seriously considers to turn off his btrfs highlight =))) too much chatting going on ;-)
<cwillu_at_work> only reason I'm asking in this particular channel is that I recognized your name on the commits :p
<smb> And I want to make sure we don't have a case where for some reason there is a slightly different configuration which nobody was considering
<smb> Well yeah, unfortunately the state before is as broken... which I had to fight with
<cwillu_at_work> linux-headers-3.6.2-030602-generic depends on libc6 (>= 2.14); however:
<cwillu_at_work>   Version of libc6 on system is 2.11.1-0ubuntu7.10.
<cwillu_at_work> that's actually just the headers package though
 * cwillu_at_work reboots to test
<cwillu_at_work> and boom
<smb> ok, so that is at least out of the way
<cwillu_at_work> smb, image from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6.2-quantal/ blew up in the usual way
<smb> Now I hope I did not screw the backport...
<cwillu_at_work> there's a 3.6 backport for lucid?
<smb> nah, but I did make upstream backports, though 3.6 should have it from upstream *pfew)
<smb> yeah 3.6-rc3 had it...
<cwillu_at_work> rc1 had it
<cwillu_at_work> and 3.5.5 had it
<cwillu_at_work> there's only 16 patches in common between those :)
<smb> 3.5 could even be the variant from upstream, the problem was that files were shuffled around a lot early in 3.5
<cwillu_at_work> when I say "3.5.5 had it", I mean "the git tag v3.5.5 from upstream's -stable repo"
<smb> I had assumed that. The patch itself was not marked stable but I submitted it at least for 3.2/3.0 (I think). Then Greg decided it should be in 3.5, too. It was ok, just not as urgent.
<cwillu_at_work> ah, okay
<cwillu_at_work> yeah, I haven't run a 3.2 or 3.0 kernel in a while
<cwillu_at_work> I also haven't needed to restore from backups in a while?
<cwillu_at_work> this is not a coincidence :)
<smb> Yeah, yeah, barfs (<- cking ;))
<cking> smb, don't blame me, blame the spelling checker ;-)
<psivaa> apw: good morning and i've just added the dmesg of a failed boot with --verbose added that slangasek asked for in bug 1066883
<ubot2> Launchpad bug 1066883 in linux "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
<henrix> smb: i was reading the irc logs and i was wondering whether the bug referred by cwillu_at_work could be bug #1055222
<ubot2> Launchpad bug 1055222 in linux "Kernel panic on reboot after sched_autogroup_enabled disabled" [Undecided,Confirmed] https://launchpad.net/bugs/1055222
<smb> henrix, Does that not sound like the opposite?
<smb> sched_autogroup_enabled=0 == noautogroup
<henrix> smb: yes, it occurs only when you disable the autogroup, but the traces point to similar place
<henrix> it's easily reproducible
<smb> henrix, I am sure I have been using noautogroup at least recently without problems but maybe
<smb> Again, this would require actually reading the bug report I was not aware of before
<henrix> smb: i can reproduce it in a precise kernel and even on a quantal running 3.7-rc1
<henrix> anyway, i'm trying to get more info about this
<smb> henrix, I can try to see whether it crashes for me as well with sysctl but it might be a similar reason
<smb> Assuming some init was forgotten to the copy of the autogroup variable
<smb> (which I suspect)
<henrix> smb: ok, thanks
 * ppisati -> out for lunch
 * henrix -> SIGFOOD
<caribou> Q: I've just finished bisecting/testing a revert on latest Quantal & Precise kernels for a bug : LP: #1056746
<caribou> right now, I've assigned the bug to myself
<caribou> but should it be assigned to an official team instead ?
<caribou> but 1056746 is causing iscsi to hang reboots when multipath is active
<rtg> bug #1056746
<caribou> bug 1056746
<ubot2> Launchpad bug 1056746 in linux "kernel panic on iscsi target disconnect" [High,Confirmed] https://launchpad.net/bugs/1056746
<caribou> hmm, need to go change the title
<rtg> caribou, if you're pursuing the bug then leave it assigned to yourself
<caribou> rtg, yep I am
<caribou> arges will help me format the patch submission later so I don't send rubbish to the list
<ogasawara> rtg: did quantal lbm make it through to the archive?
<rtg> ogasawara, as did the meta package (I think)
<rtg> ogasawara, I chatted with the folks on #ubuntu-release about it, I think I remember it being accepted, then I raced off to ride bikes and drink beer and all else was forgotten.
<rtg> damn, another dya has started.
<rtg> ogasawara, https://launchpad.net/ubuntu/+source/linux-backports-modules-3.5.0
<ogasawara> rtg: right, seems like it's missing there
<rtg> ogasawara, its there, its just not been published
<rtg> I'll bug 'em about it
<ogasawara> rtg: thanks, gotta jump on a call here
<slangasek> psivaa: bug #1066883> great, thanks; will peruse that output later today
<ubot2> Launchpad bug 1066883 in linux "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
<rtg> ogasawara, no good deed goes unpunished :) bug #1068125
<ubot2> Launchpad bug 1068125 in linux-backports-modules-3.5.0 "Quantal LBM should not generate udebs" [Undecided,In progress] https://launchpad.net/bugs/1068125
<psivaa> slangasek: ok, yw
<ogasawara> rtg: ack, I'll clean it up.
<brendand> bjf, henrix - what is the cadence looking like now? will regression testing be after or before uds?
<brendand> http://people.canonical.com/~kernel/reports/sru-report.html is not very forthcoming
<henrix> brendand: we're holding it a little bit until the release so that we're not using the buildds for kernels
<brendand> henrix, so it's not built yet?
<brendand> henrix, in that case it will be after uds for regression testing i guess?
<henrix> brendand: no, it is not. we are not supposed to upload anything to the buildds during this period
<henrix> brendand: i believe this cycle will be extended to 4 weeks
<brendand> henrix, ok, thanks!
<henrix> brendand: np
<henrix> bjf: ^ that's correct, right?
<henrix> brendand: anyway, i expect to start uploading kernels later today or tomorrow.
<StFS> Hi. I was just fixing a small bug with my dock audio output (added a single line to the quirk table). Anyways, I built my own kernel-image .deb but it has the same version as the one that is installed from the repo. So first question: how do I change the version number for the package that I'm building? Second question: is there some naming that I could use so that if a new kernel-image becomes available in the repo it will still be installed over the
<henrix> StFS: you can take a look at https://wiki.ubuntu.com/Kernel/Dev/KernelBugFixing (section "Building and Uploading the Package")
<henrix> StFS: it suggests the use of '~'
<bjf> brendand, https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
<bjf> brendand, we discussed this with ara, the week of uds will be an additional verification week and the week after will be testing
<brendand> bjf - sounds like a plan
<rtg> ogasawara, you gonna throw up the day 0 kernel today ?
<ogasawara> rtg: I wasn't planning on a 0 day
<ogasawara> rtg: was just gonna let it do it's normal SRU cycle
<rtg> ogso, just let the stable team do it ?
<ogasawara> rtg: yep, I didn't see anything urgent on master-next
<bjf> ogasawara, we have the conn :-)
<rtg> ogasawara, 2 stable updates in the pipe, but should likely go through Q/A
<ogasawara> rtg: yep, I'd prefer those get some baking before going up
<rtg> bjf, then its officially yours. I'll go back to worrying about signed modules
<bjf> rtg, ack
<bjf> henrix, herton, sconklin, ^ quantal is ours
<herton> ack
<henrix> \o/
 * ogasawara back in 20
<apw> rtg, now we know the name of r, are you going to fix the repo name ?
<rtg> apw, already did
<apw> hmmm, my update worked, odd
<rtg> apw, ln -s ubuntu-raring ubuntu-r
<bjf> apw, are the buildds free to use again?
<apw> bjf, we're not released as yet, so not sure
<bjf> apw, ack
<apw> bjf, oh word on the street is you are good to get back on your SRUs
<bjf> apw, cool, thanks
<bjf> henrix, ^ you are free to engage
<bjf> :w
<rtg> its a target rich environment
<apw> rtg, so i am assuming you are owning -r rebases for now ... in the interim i am going to liase with infinity et al about what they want in R 'before' toolchain etc
<rtg> apw, almost done
<apw> rtg, cool.  i suspect our headers are going to be a mess after the 3.7 update, so it seems wise to put a 3.6 for the initial opening/bootstrap
<rtg> apw, likely. there is a Ubuntu-3.6 tag
<apw> rtg, i see it, thanks for remembering :)
<rtg> ppisati, apw: I'm done with the ubuntu-raring smack down. went from 300'ish patches down to 108
<rtg> ppisati, I'll start building with your arm patches here shortly
<apw> rtg nice
<ppisati> rtg: i've two more
<ppisati> rtg: they are from Q, it seems you forgot them
<rtg> ppisati, I'd gotten about as far as you did before I got tired of rebuilding and just gave up on arm altogether
<rtg> ppisati, go ahead and post 'em and I'll pick them up
<ppisati> rtg: ok, give 5mins and i'll send these two (usb stuff)
<ppisati> ack
<ppisati> rtg: patches sent
<tyhicks> rtg, cking: bug 338914 is a pretty minor bug that no one would hit unless they tried pretty hard
<ubot2> Launchpad bug 338914 in linux "Proper cipher support isn't checked at mount time" [Undecided,Fix committed] https://launchpad.net/bugs/338914
<rtg> tyhicks, true, buts its also an easy patch
<tyhicks> rtg, cking: It probably isn't worth the cycles needed for backporting and verifying it
<tyhicks> it is easy
<tyhicks> rtg: If you (or cking, rather) don't mind doing the work, I won't stop you. Just wanted to mention that it isn't a big deal. :)
<rtg> tyhicks, no problem, its already in the pipeline and cking has an easy verifier
<tyhicks> (Thanks a bunch for helping to stay on top of eCryptfs bugs in Ubuntu, btw!)
<tyhicks> sounds good!
<rtg> tyhicks, you're my special project :)
<tyhicks> heh... I hope that's a good thing
<rtg> tyhicks, nah, its just that I've always been an ecryptfs proponent, so I keep a special eye out for bug fixes etc
<tyhicks> We definitely have the most eCryptfs users, so that's a good thing
<cking> yup, and it's no big deal for me to keep on top of these patches to SRU
<cking> tyhicks, BTW, I'm going to see if I can construct some eCryptfs tests to bump up the gcov coverage rate
<tyhicks> cking: Great!
<tyhicks> cking: I've always wanted to add eCryptfs support to xfstests to automatically pick up the large number of tests that they have (and actively add new tests), but I've never had the chance
<tyhicks> cking: Keep that option in mind as you plan out what you want to do
<cking> tyhicks, yep, lets call that a 13.04 work item
<bjf> tyhicks, cking i think that would be fairly easy to add to our existing tests
<tyhicks> Hmm... making xfstests know about stacked filesystems may help overlayfs testing, too
<bjf> tyhicks, cking we already run the xfstests
<tyhicks> good to know
<cking> bjf, yep, we can discuss that at UDS
<kroson_> Hi everyone, and congratulations for Ubuntu 12.10 release. Can you tell me if upgrading from kernel 3.5 to kernel 3.6 in 12.10 is a safe procedure?
<kroson_> thanks
 * rtg -> lunch
 * ppisati -> EOD
<alexbligh1> now you guys have got quantal out (congrats) is there a plan for quantal-backport kernel for precise?
<alexbligh1> (as in 'in the precise repo')
<rtg> alexbligh: yes, but you know you can also get it from https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport until its official in teh archive
<alexbligh> rtg, thanks. it was more for our customers than for me. AFAIK just installing the q .deb works now on p.
<rtg> alexbligh: it'll show in due course when things have settled a bit from the release. I'll pursue getting it uploaded tomorrow.
<alexbligh> rtg, great. No rush from me. We'll just have the normal run of people complaining that they can't install our stuff on arcane-hardware-du-jour and our normal solution is to point them at a backported kernel.
<ogasawara> rtg: so we have bug 1026831 which is linked to from https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-kernel-misc, but we also have https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates
<ubot2> Launchpad bug 1026831 in debian-installer "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [Undecided,Invalid] https://launchpad.net/bugs/1026831
<rtg> ogasawara, I'll use the second one
<rtg> https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates
<rtg> ogasawara, bug #1068281
<ubot2> Launchpad bug 1068281 in linux-meta "Quantal LTS kernel in Precise" [Undecided,Fix committed] https://launchpad.net/bugs/1068281
<ogasawara> rtg: ack
<rtg> bjf, https://launchpad.net/ubuntu/raring still indicates armel
 * ogasawara lunch
<bjf> rtg, indeed it does
<bjf> rtg, but then you know how hard it is to removes a flavour let alone an arch
<manjo> rtg, in 12.04 we had /lib/modules/3.2.0-32-generic/build but in 12.10 we don't have the 'build' directory anymore ? 
<maxb> I have a /build on 12.10
<rtg> manjo, likely a function of upstream build changes, but its a detail that I can't remember
<manjo> maxb, you said /build ? 
<maxb> By which I mean I'm being a lazy typist and mean /lib/modules/$(uname -r)/build
<manjo> rtg, I was looking for .config Module.symvers Makefile which used to be under /lib/modules/$(uname -r)/build
<manjo> maxb, interesting I just installed 12.10 and I don't have that build directory 
<maxb> maxb@zenbook:~$ ls -lA /lib/modules/3.5.0-17-generic/build/Module.symvers 
<maxb> -rw-r--r-- 1 root root 844882 Oct  9 20:56 /lib/modules/3.5.0-17-generic/build/Module.symvers
<maxb> manjo: And if you 'apt-get install linux-headers-generic' ?
<manjo> hmm installing 
<manjo> maxb, you saved me ! 
<manjo> thanks 
<manjo> maxb, I guess header-generic is not installed by default anymore .. but that makes sense 
 * cwillu pokes smb with a sysctl.conf entry
<cwillu> "kernel.sched_autogroup_enabled = 0" in /etc/sysctl.conf is what makes my machine different; should have thought of that when you said "noautogroup"
 * rtg -> EOD
#ubuntu-kernel 2012-10-19
<cwillu_at_work> smb`, not sure if you got the message; the thing that henrix_ pointed out is correct
<smb> cwillu_at_work, I saw the email exchange yesterday but not having set any brain power on it. And now I have one more important thing to archive first: coffee...
<cwillu_at_work> let the hunt begin!
<smb> Mischief managed!
 * apw yawns
 * smb shares some coffee
<apw> sounds like a good plan indeed
<apw> henrix, yo ... so i see you are wrapping an sru kernel for quantal
<apw> henrix, you need to be aware for quantal there is now an additional package to prep
<henrix> apw: ah, the signed thing?
<apw> henrix, indeed the signed thing
<henrix> apw: ok, i have completely forgot about that indeed
<apw> there is a new repo, ubuntu-quantal-signed, which you need to checkout, then that needs to have the exact same version as the main kernel -- it has an update-version script in it which should sync the two for you
<apw> it can and should be uploaded at the same time as linux, it has binary dependancies in it to make it build in the right order
<apw> when you get to preparing that package, it makes sense for me to review that one
<apw> henrix, ^
<henrix> ok, cool.
<henrix> i have already pushed the other git trees
<henrix> so i was going to prep the pkgs
<henrix> i'll take a look at this new package in a few minutes
<henrix> and ping you for review
<apw> henrix, is there a sensible page i can add the details of how it works etc
<apw> in the wiki.  the nearest i can find is https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePackageBuilding but it seems somewhat thin on detail
<henrix> apw: let me have a look...
<apw> henrix, the basic plan with linux-signed is to run update-version ../ubutu-quantal; and then package the result up.  the update-version thing prints out the signing and commit commands to simpify use
<henrix> ok, i'll give it a try in a few and ping you if any doubts. /me was sure there was a more detailed wiki page where this could be added...
<henrix> maybe i need more coffee to find it...
<caribou> smb: would you have a minute to take a look at an EC2 kernel panic trace ?
<smb> caribou, maybe... though I am not sure I want to ... yet another one... Oh well anyway... where?
<caribou> smb: I'll PM you the pastebin link
<wmp> who can look: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1068340
<ubot2> Launchpad bug 1068340 in linux "I havent second thread" [Medium,Incomplete]
<caribou> smb: just want to know if this rings a bell to you
<wmp> and why i cant add 2 attach in one comment?
<caribou> smb: I've been trying to setup kernel dump on an test EC2 instance but didn't have any luck
<smb> caribou, crashdump does not work for pv guests
<caribou> smb: I expected that :)
<cwillu> smb, just a heads up, given that you weren't cc'd:  [PATCH] sched, autogroup: fix kernel crashes caused by runtime disable autogroup
<smb> cwillu, Did you see the change I am wondering about. Maybe you want to try it
<cwillu> I saw your patch
<henrix> apw: ok, so i've pushed to my git tree the new Q -signed package. do you have some time to take a look at it?
<smb> caribou, If you can reproduce it on a local xen host you could use xen dumps
<caribou> smb: k
<henrix> apw: there's another script (download-signed)... what's its purpose?
<smb> cwillu, Ah ok, so they moved things a bit... *shrug* if that helps
<smb> cwillu, Thanks for the heads up... was that in upstream already or right now "only" on mailing lists? Need to make sure to backport that as well to stable
<cwillu> I just got it 30 minutes ago
<cwillu> mailing list
<cwillu> yep, they didn't cc stable either; I'll test it tomorrow and poke them re: cc if nobody has yet
<cwillu> er, re: cc'ing stable
<apw> henrix, download-signed is part of the workings of the packag
<apw> package
<apw> it is used at build time on the buildds, not something you use
<henrix> apw: ack
<apw> henrix, will have a look now
<henrix> apw: cool, thanks
<apw> henrix, ok my bad you had an out of date tip, you'll need to redo that :/
<henrix> apw: heh, no prob. gimme 1 min
<apw> henrix, somehow i had managed to push the tag and not master, not quite sure how i managed that
<henrix> apw: done
<apw> henrix, looks good to me
<henrix> apw: i guess we'll have to change the shankbot to handle this new pkg as a task in the tracking bug
<apw> henrix, yeah i recon so indeed
<henrix> apw: so, there's nothing special to build this pkg, right? a regular dpkg-buildpackage will do the job, correct?
<apw> henrix, exactly that
<henrix> apw: cool
<apw> henrix, ok pushed -signed, and pushed the two missing tags
<henrix> apw: great, thanks
<dupondje> Somebody else is noticing shutdown issues sometimes?
<dupondje> Like 1 on 10 times, shutdown just freezes, and I have to pull the power :(
<dupondje> any hints to debug this?
<tjaalton> is the old 3.1 packaging from early precise around somewhere?
<tjaalton> huh, git of course
<henrix> apw: just to confirm: i *must* upload linux-signed_3.5.0-18.29_source.changes right after linux_3.5.0-18.29_source.changes, right?
<apw> henrix, the world won't end or anything if you don't.  they can be uploaded together safely.  linux-signed should be uploaded each time linux is abi bump or not.
<henrix> apw: ok, understood. thanks :)
<apw> henrix, expect linux-signed to fail 'depwait' which will resolve itself when the main build completes
<apw> this is normal
<henrix> apw: ack
<apw> henrix, when you are getting shankbot fixed we need to check it is making bugs for lowlatency
<apw> for quantal
<henrix> apw: ok, we'll do that as well.
<apw> henrix, i assume you haven't uploaded quantal yet ?
<henrix> apw: no, not yet. but i was about too...
<apw> henrix, cool, i just didn't see it in the tree
<henrix> found any prob?
<apw> s/tree/PPA
<apw> no no problem, i was going to do the lowlatency rebase
<apw> and upload that to the PPA as well
<henrix> ok, cool. i'll be uploading it in a min. need to download the .orig.tar.gz first :p
<apw> henrix, btw currently linux-signed only exists for linux, there is no linux-*-signed as yet
<apw> heh
<henrix> apw: does that mean we'll have to create the other -signed pkgs? 
<apw> henrix, not as yet, we're only supporting signed boot on linux for now
<henrix> apw: ah, ok. uff
<apw> henrix, it is likely we will get more -signed packages for some branches in the future, but not for now
<henrix> ack
<caribou> Q: is there some kind of wrapper around git-send-email to automate patch submission ?
<henrix> apw: building. as you referred, the -signed pkg failed due to deps. i'll retry it later once amd64 is done
<caribou> like automating patch numbering in subject: & such ?
<einonm> caribou: git send email does that for you, e.g....
<einonm> git format-patch <first ref>...HEAD
<einonm> then git send-email 000* --to etc
<caribou> einonm: yeah, I've done that & used the git send-email command on the Wiki
<caribou> einonm: doesn't seem to number the patch in the subject though. Maybe it needs to be done manually
<einonm> caribou: hmmm, not in my experience... can you be more specific about the commands you're using?
<einonm> caribou: It's actually the git format-patch line that formats the email header. You'll need to pass it a list of the git commits to number them correctly
<caribou> einonm: maybe that's because I only have one commit
<einonm> yes. It doesn't number a list of one patch
<caribou> einonm: I followed the description here : https://wiki.ubuntu.com/Kernel/Dev/KernelBugFixing#Forward_the_Commit_for_Approval
<caribou> einonm: ok, I'll test with two patches
<einonm> If there's only one patch, is there a need to number it?
<einonm> just a list of commit refs will do, you don't have to specify a range all the time
<einonm> but for a single ref, it will create a list of the patches between that and the HEAD, so for a list of individual patches, you'll need to specify <first~1>...<first> <second~1>...<second> etc
<caribou> einonm: you're right, I just tested with 2 commits & it numbers it correctly.
<caribou> einonm: thanks for pointing that out
<einonm> no probs :)
<apw> henrix, it will retry itself without your intervention shortly after the end of the main build.  i confirmed this behaviour in my PPA previously
<henrix> apw: ack
<apw> caribou, how are you dumping the patches, git format-patch seems to have numbered them before i feed them to git send-email
<einonm> I was talking crap about giving a list to format-patch. It only takes a single range ...
<einonm> but to always number, you can use the -n option, even if there's only one patch
 * henrix -> lunch
<doko> apw, rtg, ogasawara: gcc-4.7 in r will be published in 5min. time to upload the kernel headers
<apw> doko, ack
<caribou> apw: yes, indeed, unless there is only one patch
<apw> caribou, ahh yes, that would make testing seem like it didint
<caribou> apw: just wanted to get things right for my first patch submission :)
<apw> heh ... always a good idea indeed
<caribou> apw: well, it's on its way now, & tested on Quantal & Precise
<caribou> apw: should something be done on the public bug (i.e. identify it for Quantal & Precise or such) ?
<apw> caribou, yeah it should be targetted to same indeed
<apw> bug #?
<apw> even if we say no and Won't Fix them they should exist to document the decision
<caribou> apw: LP: #1056746
<apw> bug #1056746
<ubot2> Launchpad bug 1056746 in linux "kernel thread hang on iscsi target disconnect when multipath is active" [High,In progress] https://launchpad.net/bugs/1056746
 * caribou needs to update the title: multipath is not mandatory
<apw> caribou, is this alreayd fixed upstream ?
<caribou> apw: yes. I cherry-picked the commit & tested it
<apw> ok i'll close it for raring then
<caribou> apw: submitted the patch for review to the ML ~1h ago
<caribou> hence my questions regarding git send-email
<apw> yep ... i've "given" the P and Q tasks to you and closed out the R
<apw> caribou, are you subscribed to the mailing list ?
<caribou> apw: yes, 
<caribou> but for some reason, I didn't receive my email, I suspect that something went wrong
<caribou> though I switched off the Digest Mode just before sending the mail
<apw> caribou, its sitting waiting on moderation which implies you used a different addy to the one you subscribed with
<caribou> apw: lemme check
<apw> hopefully i just stroked them through
<caribou> apw: email address is correct. Could it be caused by the Digest mode ?
<apw> no don't think so
<caribou> apw: ok, figured it out, it left my laptop with my username (caribou@canonical.com), not my real email address.
<caribou> ssmtp blunder
<caribou> default setup doesn't allow overriding the From: field
<apw> caribou, ok that makes sense then, and the emails have come through now i've approved them
<caribou> apw: I just fixed my ssmtp setup & tested again. Shouldn't happen again
<henrix> smb: i didn't had a chance to try your autogroup patch yet
<henrix> smb: i'll try to do it later today, or during the weekend
<smb> henrix, Actually there seems that cwillu found some other version somewhere
<smb> not sure he also fwd to you, a sec
<henrix> i don't think so. can you forward it to me?
<smb> henrix, done
<henrix> smb: thanks
<henrix> smb: ah, it makes sense. i'll give it a try later
<smb> henrix, ok cool. I just had no time really to find out exactly where that is upstreaming wise
<henrix> smb: i found it in lkml, no replies yet. i'll test it and provide some feedback
<smb> henrix, ah ok
<rtg> apw, whats the story with linux-signed 3.5.0-18.29  FTBS ? Are you on top of that ?
<henrix> rtg: it failed due to dependencies, i believe. i should have waited a little bit more before uploading it.
<henrix> rtg: i'll retry it later
<henrix> rtg: (however, i haven't checked the logs yet)
<rtg> henrix, shouldn't it have gone into DEPWAIT ? or is that just PPAs ?
<henrix> rtg: ppa i believe. the main pkg is still building
<tjaalton> i'm trying to bisect something, and building 3.1 would be the first step (to see if the fix is in 3.1 or 3.2), but checking out for instance 92f8343feec from the precise tree shows that the diff to v3.2 is suspiciously small, compared to v3.1..v3.2
<tjaalton> how can I verify that it really is based on v3.1?
<einonm> tjaalton: clone Linus' Linux repo and perform a diff of the relevant tags?
<tjaalton> einonm: that's what I'm doing
<tjaalton> v3.x are from there
<einonm> you mentioned that you were using the precise tree, I'm talking about Linus' tree taken from kernel.org. 
<tjaalton> I have the remote added
<apw> tjaalton, normally i use git log then look for '    Linux '
<apw> to find out what the next closing commit from linus was
<tjaalton> Linux 3.2.14
<tjaalton> great :)
<apw> apw@dm:~/git2/ubuntu-precise$ git describe 92f8343feec
<apw> v3.2.14-236-g92f8343
<einonm> ah, I see - you can check out using a tag instead of a ref
<apw> sometimes that will tell you what you want
<apw> except when it says 'Ubuntu-' something
<einonm> what about 'git checkout v3.1'?
<tjaalton> einonm: I need the packaging too, though I could do a selective merge there
<apw> Ubuntu-3.1.0-2.3
<apw> tjaalton, that looks to be the last 3.1 based kernel
<tjaalton> apw: yes
<tjaalton> so I assumed that by branching from that I'd get 3.1 + packaging, but no :)
<apw> well it appears to have been uploaded, so i would expect that too
<apw> tjaalton, you would need to checkout the TAG and not the commit which _now_ has UBUNTU: Ubuntu-3.1.0-2.3 on it
<apw> tjaalton, as the closing commit has since been rebased
<tjaalton> hmm ok
<apw> we rebase until release
<tjaalton> yeah this looks a lot better, thanks :)
<apw> tjaalton, though if it was built in the archive, the librarian has the binaries anyhow, so you could just test those
<tjaalton> apw: I need to add one commit on top of it anyway
<ppisati> brb
<rtg> caribou, is caribou@canonical.com bogus ? I got a bounce
<caribou> rtg: yes, wrong ssmtp setup when I sent to the list
<caribou> rtg: got that fixed. apw had to force the email through
<rtg> caribou, ok, then read my response to the list.
<caribou> rtg: but I just got your reply to the list
<apw> doko, hey, do actually have a compelling reason to take 3.6 headers over 3.5 at this point
<apw> doko, i ask as the changes are pretty small, and we are slightly worried about the untested nature of the kernel itself
<doko> apw, I thought you did want to start with 3.7?  the reason for the new headers is to catch ftbfs early.
<doko> the untested nature of the kernel would be one more reason to build the headers from a separate source ;)
<apw> doko, we're in a hole with headers from 3.7, they have changed the kernel side of them and we are still sorting the fallout; so the latest we could do is 3.6
<apw> doko, though in that case we'd have headers advertising features the kernel didn't have, i suspect that'd also not go well !
<apw> doko, i am working on 3.7 header issues now, but i'm not sure there is value in waiting for us
<rtg> doko, I think we should stick with 3.5 until we've got some mileage on 3.7. its still kind of a steaming pile.
<doko> ok
<cking> doko, which version of gcc will be using for 13.04?
<cking> doko, did you get any time to look at my email concerning gcc 4.7.x and kernel GCOV issues?
<BlackNarcissus> Hello all. I ran into a serious bug during 12.10 install, and someone on ubuntu-bugs told me to report it under linux and to check with you guys. When installing on a laptop with nvidia integrated graphics, the system is not properly cooled, temperature goes above safety limits and shuts down, thus interrupting the install.
<BlackNarcissus> It's  Bug #1068626
<ubot2> Launchpad bug 1068626 in linux "System Overheats and Shuts Down during Install" [High,Incomplete] https://launchpad.net/bugs/1068626
<doko> cking, 4.7.x, sorry, not yet. could you check with gcc-4.7 from debian unstable too?
<cking> doko, ok, I will do that on monday
 * ppisati -> EOW
 * cking too EOW
<henrix> almost beer o'clock here so...
 * henrix -> EOD
<bizhanMona> Hi, I have a new Ivy bridge mother board running Ubuntu 12.10. I am trying to identify a source of hardware interrupt for 0.1 msec periodicity. Any idea ?thx
 * smb -> FEOW
<rtg> jsalisbury, when you Cc stable, put it in the commit log, e.g., "Cc: stable@vger.kernel.org". that way you won't get hate mail from the gkh bot.
<jsalisbury> rtg, yeah, I realize that now :-)
 * jsalisbury tries round two
<rtg> jsalisbury, don't forget '[PATCH v2]' in the subject.
<jsalisbury> rtg, ack
<jsalisbury> rtg, and no cover letter 
<jsalisbury> rtg, do I also Cc the maintainers in the commit log, or just on the email to lkml?
<rtg> jsalisbury, I generally use get_maintainers.pl and Cc everyone (and everything) on the list except LKML. I generally direct the email to LKML
<jsalisbury> rtg, thanks.  
 * rtg -> lunch
<Ergo^> hello, i want to use 3.6 kernel on ubuntu 12.10 - but the docs say that mainline kernels are missing ubuntu patches in them, is there a place where i can get a prerelase kernel with all the patches ?
<Ergo^> or should i just grab the "current" one ?
 * ogasawara lunch
 * rtg -> EOW
#ubuntu-kernel 2012-10-20
<infinity> bjf: Did Andy muck something up with https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1068866 or is there a reason the bot hasn't set the promote-to-proposed task as confirmed by now?
<ubot2> Launchpad bug 1068866 in linux-lowlatency "linux-lowlatency: 3.5.0-18.18 -proposed tracker" [Medium,In progress]
<wmp> hello, i want to use 3.6.2 kernel, but on this kenrel i have wrong resolution and i havent wifi. What i should doing to have wifi and good resolution?
<bjf> infinity, shankbot doesn't like it, i'm debugging
<bjf> infinity, i have fixed it enough that it set the promote-to-proposed task
<infinity> bjf: Out of curiosity, was it something Andy (or I) screwed up, or was the bot just broken?
<bjf> infinity, it was the bot
<infinity> bjf: Kay, good to know.
<bjf> infinity, for some reason, it is a "new" package that we are tracking
<bjf> infinity, was andy doing tracking bugs for previous versions ?
<infinity> Nope, this was the first time it got a derivative tracking bug.
<infinity> Andy's only been doing uploads since quantal opened, which didn't have tracking bugs into it went stable, of course.
<bjf> infinity, ok, there is that plus work done to support raring
<bjf> infinity, we don't "officially" support that package do we?
<infinity> Nope.
<infinity> Just has tracking bugs for convenience.
<infinity> We could probably cut the QA tasks on it down to just one quick smoketest.
<infinity> Cause it's identical to the mainline, except for two patches, so really, we just want to know it installs/boots/reboots, and it's good enough.
<bjf> infinity, so we _do_ want QA to test it (at least boot test it) ?
<infinity> Yeah, probably that would be the Verification-testing task, the others (Cert and regression) could be auto-set to Invalid.
<infinity> And security sign-off.
<bjf> that seems close to being "supported"
<cafetiere> bjf yeah i did it to not confuse as it was in the ppa, if i used it wrong do educate me :)
<infinity> bjf: Nah, all SRUs require verification, even when they're not "supported".
<bjf> cafetiere, the bot just didn't have any knowledge of that package, your usage was just fine
<infinity> bjf: But "verification" is a long way off from the rigorous kernel QA we do, which is entirely unnecessary for this package.
<bjf> yes, but given the amount of work QA is doing, asking them to test non-supported packages seems like i'll be asking to get punched by pgraner
<infinity> bjf: Oh, no, I'm not implying that Canonical QA would be doing the Verification-testing, just that someone needs to do a quick smoketest.  For some value of $someone.
<bjf> ok, so "someone" will smoketest it and set the verification task. and that "someone" won't be QA
<jtaylor> just out of curiosity, why are transparent huge pages not enabled in ubuntu by default?
<infinity> bjf: If they key off that task for their own workflow, best to auto-set it to invalid too, and we can just set a verification-needed tag on the bug for someone to do normal SRU verification.
<cafetiere> I'd like to see it held until master paasses or not if we can do thats
<infinity> cafetiere: I'd be doing that anyway.
<bjf> cafetiere, i'll ask herton to think about that
<cafetiere> shankbot might be able to help there
<infinity> But certainly, it would be cool if the bot did it for me, so I don't have to think. ;)
<bjf> sounds like UDS fodder
<cafetiere> bjf add it to the uds beer adgenda perhals
<bjf> cafetiere, wfm
<bjf> cafetiere, doing so now
<cafetiere> thanms typing is hard enough on here
<bjf> ack
 * infinity almost forgot to process linux-signed in NEW...
<bjf> cafetiere, added to the agenda
<wmp> hello
<wmp> i need to use kernel 3.6.2 in 12.10, how to do it? I test mainline kernel and all work, but i havent wifi and good resolution
<infinity> Define "need".
<cafetiere> the only 3.6 kernels packaged are the mainline ones
<wmp> infinity: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1068340/comments/16
<ubot2> Launchpad bug 1068340 in linux "I havent second thread" [Medium,Confirmed]
<jtaylor> apt-get source linux-image* in quantal points to the precise git, not quantals
<apw> jtaylor, hmmm
<apw> jtaylor, will get it fixed
<jtaylor> thx
<jtaylor> do you happen do know why transparent huge pages are not enabled by default in quantals kernel?
<apw> jtaylor, hmmm nope, i thought they were on in P, so i'd expect they remain on
<jtaylor> according to http://kernel.ubuntu.com/~kernel-ppa/configs/ they were never on
<jtaylor> (only via madvise)
<apw> hmmm actually, perhaps they were on, and then in P there might have been VM corruption issues, and off it went ... smb might remember
<apw> jtaylor, 
<apw> jtaylor, http://bugs.launchpad.net/bugs/1069204 <-- fix applied
<ubot2> Launchpad bug 1069204 in linux (Ubuntu Quantal) "[quantal] Vcs-git: points to precise" [Medium,Fix committed]
#ubuntu-kernel 2012-10-21
<infinity> ogasawara / bjf : There's a linux-lts-quantal in precise-proposed/new for ABI 17.  Wouldn't it make more sense to get the 18 one in matching the current ABI in quantal-proposed, so we don't fall one SRU cycle behind?
<infinity> henrix_: ^
<bjf> infinity, rtg did the .17 last week around release time, i expect henrix to put out a 18 this coming week
<bjf> infinity, that's my story and i'm sticking to it
<swex_> hello all
<swex_> I wonder why my 12.10 ignoring my /etc/modprobe.d/blacklist.conf 
<swex_> I want to disable samsung_laptop module at boot time
<swex_> but I still can lsmod it after reboot, so I have to rmmod it by hands each reboot
<swex_> which are other ways kernel decides to load this module?
<apw> swex_, i would expect blacklist.conf to work ... what did you add there
<swex_> apw, I've added: blacklist samsung_laptop
<ricotz> apw, hi, were some changes which would make a local kernel build not working on other machines? e.g. automatically using some optimizations which won't work on other cpus?
<ricotz> apw, i expect a local build on quantal amd64 to work everywhere like it used to, ah i forgot i mean the raring kernel branch which behaves that way since the 3.6 imports
<apw> ricotz, not intentionally no
<ricotz> apw, i see, this is just a theory, i can't really debug it since the kernel panics on boot
<apw> ricotz, its more likely a machine specific bug rather than optimisation
<apw> and its hardly -rc2, so its going to be buggy
<ricotz> apw, yeah, although it happened with 3.6.0 too
<ricotz> apw, ah also the mainline builds of 3.7rc1 or rc2 working fine
<apw> ricotz, so it could be a config issue in -r or the ubuntu-delta, you could build -rc2 with the raring config
<ricotz> apw, currently doing that
<ricotz> apw, maybe this one tells you something http://people.ubuntu.com/~ricotz/tmp/VID_20121021_123209-123609-21102012.mp4
<ricotz> (which is raring master-next merged with rc2)
#ubuntu-kernel 2013-10-14
<ppisati> moin
<smb> ppisati, morning
<ppisati> 328 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<ppisati> doh!
<ppisati> smb: moin
<diwic> good morning
<diwic> how are we looking towards picking 3.13 vs 3.14 for the 14.04 LTS?
<apw> diwic, i wouldn't like to say we have relly had a look at that yet, though we tend to be conservative.
<smb> apw, and Morning! :)
<diwic> apw, ok. It's just a few weeks until 3.13 merge window opens, so better start working on anything one wants in the kernel if you're going for that one...
<apw> smb, yo, you got it done!
<apw> diwic, indeed
<smb> apw, Err, mostly. If working from a room full of boxes, unsorted stuff and half-setup counts as "done". :-P
<apw> smb, yeah it counts and will do for years :)
<smb> apw, I would hope for a little less. :)
<apw> smb, oh we all hope :)  but it takes a long time to settle in
<infinity> zequence: You doing your regression-testing on those lowlatency kernels soon?
<zequence> infinity: shortly, yes :)
<infinity> zequence: \o/
<smb> infinity, Hm, did we recently add arm64 to arches we build?
<infinity> smb: I see you've been paying attention...
<smb> infinity, No not really, but there is this sudden compile failure of blktap... :-P
<infinity> smb: Heh, yeah.  I think apw and I talked about it a week ago or something.
 * smb was packing and unpacking boxes for the last week
<apw> smb, yeah we didi indeed
<apw> we all got a lot of emails about failed builds
<smb> apw, Heh, I guess. Well we can talk at some point about where I could test build any fixes I attempt
<infinity> Oh, no, we talked about blktap vs. blktap-dkms in reference to powerpc.
<infinity> That arm64 failure is just plain bad C, probably.
<smb> Looks to me like some constand is not defined the same way or in the same header
<apw> i guess the bigger question is should he react or ignore it till T
<smb> *contant
<smb> bah
<smb> grr
<smb> *constant
<apw> you should have brought all the keys from your keybaord with you
<infinity> blktap isn't seeded, so I'd be fine if someone wanted to fix.
<infinity> But if the fix ends up being in glibc/linux headers, fuck it. :P
<smb> apw, I beleive I did, just my fingers are now used to some less delicate work
<smb> infinity, Suppose it can wait then
<apw> heheh ... i did some hammering, putting in that fence you saw, and omg my hands became like clubs for days after
<apw> i seemed to lose individual finger control completely
<smb> apw, Stupid adjustment thing... :)
#ubuntu-kernel 2013-10-15
<snadge> latest saucy kernel wont do dual display on whatever ivy bridge intel chip is in this mac mini
<snadge> latest mainline drm-intel-next .. does work
<apw> snadge, what happens when you try to do that, and what is the bug #
 * apw yawns
<snadge> apw: i didn't look for a bug number
<snadge> which means if i did look for one.. and there wasn't one, i'd feel obligated to report the issue / look into it further
<apw> snadge, with a bug of this nature (likely h/w related) it is best to file one yourself so we have that h/w info and let it be dupped to another bug if it is truly the same
<snadge> its an ivy bridge cpu, i5.. mac mini late 2012 model
<snadge> so its not anything special or unique.. hd4000 (i think).. im not at work to beable to confirm it
<snadge> i went straight for an intel-drm-next nightly.. so I have no real information as to what actually fixes it, and what the actual problem is
<snadge> im more motivated to help fix this problem.. than I am to help figure out a known and reported issue in fedora, that remains unsolved
<snadge> which prevented me from installing it alongside OS X
<apw> snadge, heh if it is a mac it is unique, likely different from even other macs of the same h/w revision; that is apple's way
<apw> snadge, so if you file a bug against linux (ubuntu-bug linux) and put in that the fact you have tried a speciifc kernel, i'll ask our defect analyst to look at it, he can help you bisect for the actual fix
<apw> (a specific kernel where it is fixed)
<apw> if you get me the bug# i'll get it to them
<snadge> apw: thanks .. that makes it really easy, i'll do that now
<snadge> actually, it will have to wait until im at work tomorrow morning, I forgot to enable remote access
<ppisati> http://paste.ubuntu.com/6239978/
<ppisati> may i have your opinion on this?
<apw> whos
<ppisati> there two things that i don't understandL
<ppisati> 1) why a driver should add a device file (/bus/platform/devices/ahci) - that's the dtb work, the driver shall just find it and attach
<ppisati> 2) why the hell it's calling itself?? a recursive probe?
<apw> thats not a dtb path that is a sysfs path
<apw> i assume something else is using the directory ahci in there, probabally the module (buiultin?) called ahci
<apw> who would have the right after all
<apw> i think i would expect a cirtain amount of self reference, as if it is a bus driver
<apw> then it would 'add itsself' as a new bus, which would cause the bus to be scanned, whcih if it is the host provider on the bus would cause it to be called to probe the bus members it just added
<apw> as remmber a module probe is a 'late' thing
<apw> so we have to ask everything which might be near it to try and be probed again
<apw> to see if the new driver which just loaded would attach to them
<apw> so its all very circular
<apw> and it is possible it is self locking on the ahci directory if they haven't handled that right
<apw> ppisati, which tree is this
<ppisati> apw: saucy
<apw> master-next ?
<ppisati> apw: yep
<apw> is the machine usable when this happens at all
<ppisati> drivers/ata/ahci_imx.c::imx_ahci_probe()
<ppisati> apw: yes
<apw> ie can you look at /sys to see if there is an ahci and who it belongs to
<apw> ls -l /sys/bus/platform/devices/ahci
<apw> and see what it belongs to
<ppisati> apw: i think it belongs to the imx_ahci driver
<ppisati> because
<ppisati> in imx_ahci_probe()
<ppisati> there's this call
<ppisati> ahci_pdev = platform_device_alloc("ahci", -1);
<ppisati> and that's the one that triggers the add of ahci etcetc
<ppisati> you say that someone else already added thatd evice before, ok
<ppisati> possible
<apw> well i suspect we'll find that it was imx_ahci, but do check
<apw> if so then we know it is self adding and not telling itself it did
<ppisati> flag@linaro-ubuntu-desktop:~$ ls -la /sys/bus/platform/devices/ahci/
<ppisati> total 0
<ppisati> drwxr-xr-x 3 root root    0 Jan  1  1970 .
<ppisati> drwxr-xr-x 4 root root    0 Jan  1  1970 ..
<ppisati> -r--r--r-- 1 root root 4096 Oct 15 10:41 modalias
<ppisati> drwxr-xr-x 2 root root    0 Oct 15 10:41 power
<ppisati> lrwxrwxrwx 1 root root    0 Jan  1  1970 subsystem -> ../../../../bus/platform
<ppisati> -rw-r--r-- 1 root root 4096 Jan  1  1970 uevent
<apw> cat that uevent
<ppisati> flag@linaro-ubuntu-desktop:~$ cat /sys/bus/platform/devices/ahci/uevent 
<ppisati> OF_NAME=sata
<ppisati> OF_FULLNAME=/soc/sata@02200000
<ppisati> OF_COMPATIBLE_0=fsl,imx6q-ahci
<ppisati> OF_COMPATIBLE_N=1
<ppisati> MODALIAS=of:NsataT<NULL>Cfsl,imx6q-ahci
<apw> and is that the right driver, the one which barfed
<ppisati> right
<apw> then we can suppose that the driver can add it more than once... which its not meant to, and would be a bug
<ppisati> apw: let me test one thing
<ppisati> two other kernels that i saw around, compile this as =y instead of =m as we do
<ppisati> and indeed, compiling this as =y, avoid the problem
<ppisati> i'll send an email upstream bot it
<apw> ppisati, ack
<ppisati> but IMO it's a bug
<apw> its definatly a bug
<ppisati> and another question at thsi point would be: why compiling it in doesn't make it happen?
<ppisati> uhm
<apw> ppisati, ordering is differnet
<apw> and init is differnet, so we will init the modile much much earlier, so there are no devices to probe
<apw> and do the probe 'later'
<ppisati> right
 * ppisati -> lunch
<tjaalton> apw: bah.. looks like I need some fixing to do :/
<tjaalton> need/have
<apw> tjaalton, for ?
<tjaalton> apw: build error due to the recent quantal pull
<tjaalton> worked fine for raring, must have missed something (like, a build test..)
<apw> tjaalton, *slap*
<apw> that doesn't exactly inspire confidence it has even been tested
<tjaalton> well, HAS_DDI was added to 3.8.13.1, quantal's ubuntu/i915 hasn't been updated past 3.8.13
<tjaalton> should I do that too?
<tjaalton> eh, 57 changes
<tjaalton> probably not
<tjaalton> 56
<tjaalton> *commits
<apw> heh ... i think ot
<apw> not
<apw> tjaalton, so should i rip these off here again
<tjaalton> apw: maybe so
 * ppisati goes out for a bit
<tjaalton> or add 26c2b3a4e572263 from v3.8 stable
<apw> tjaalton, sigh
<tjaalton> though it's trivial to change the patch too
 * apw rips the second fix
<apw> so you can get a pair to gether which have been tested
<tjaalton> thanks
<tjaalton> i'll sort it out tomorrow
<tjaalton> but, in theory, shouldn't it be ok to sync it with the stable tree?
<apw> yeah if it is in there we will get it without help when stable do their next syn
<apw> sync
<apw> but, i'll not step on their toes on that, so you can either wait on that or include it in your replacement
<apw> its too near saucy release to keep too much state in my brain :)
<tjaalton> heh, ok
<tjaalton> noones syncing the quantal ubuntu/i915 though
<apw> no indeed, we assume people will be getting new shiney from later kernels
<rtg> apw, so we can ignore the raring pull request for i915_hsw also ?
<apw> or that you will be sending us shiney new updates
<apw> tjaalton, has that raring one been tested ?
<tjaalton> rtg: that should work, though you can hold off on that too
<tjaalton> apw: yeah, raring got that extra commit via stable already
<tjaalton> i'll build test both tomorrow though to be sure..
<rtg> tjaalton, ok, I'm happy to ignore you in the mean time :)
 * rtg goes back to firmware issues
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<tjaalton> rtg: feel free :)
<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 October 15th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jsalisbury> Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues October 22nd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues October 22nd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<rtg> apw, have you tried todays ISO on an EFI system ? am having some trouble getting it to reboot. It worked fine last week.
<apw> rtg .... hmm not the iso, i have the current kernel on, well this ctual machine
<apw> actual
<rtg> it booted well enough, but its not really a good experience
<rtg> hmm, must be lunch time
<bjf> rtg, i'll try it on my macbook air
<rtg> bjf, yeah, this is a gigabyte MB. it behaves odd sometimes.
<infinity> We had a lubuntu tester claim that amd64+mac wouldn't reboot post-install for him too.
<infinity> Could be the same thing.
<infinity> Given that amd64+mac is EFI by definition.
<bjf> infinity, will know shortly. installing right now
<infinity> If it's kernel-related, we're pretty much too late to fix it anyway.
<infinity> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238836
<ubot2> Launchpad bug 1238836 in ubiquity (Ubuntu) "System does not reboot after installation" [Undecided,Confirmed]
<infinity> Oh, then someone else piggybacks with a similar bug with i386.
<infinity> Which wouldn't be EFI.
<infinity> So, that's unhelpful.
<rtg> mine reboots normally thereafter
<bjf> infinity, mine install and boots just fine. couple minor issues: 1. indicator garbage during install (mouse over made it go away); 2. No "please remove your install media and hit return" message seen. (i just waited, hit return and it did the right thing); 3. Upon first bootup and log in i got a crash with indicator-datetime-service.
<infinity> So, your number 2 could be what others see as a failure to reboot.
<bjf> infinity, could be
<rtg> I'm guessing thats right
<infinity> If it's not actually a reboot failure but rather just the usual recurring "reboot message doesn't show because $reasons" bug, we might be able to find a fix for that.
<infinity> Could one or both of you follow up to that bug with your experience(s)?
<infinity> bjf: The two indicator bugs are pretty unlikely to be addressed for release.  Hoping the crash gets SRUed, though.
<bjf> infinity, bug comment added
<infinity> bjf: Danke.
<brendand> can anyone tell me why/when 'Extended CMOS Year' is printed?
<brendand> is it on resume?
<apw> brendand, is that the exact string, and what series
<brendand> Extended CMOS year: 2000
<brendand> and i'm using saucy
<apw> infinity, that not saying "please remove" thing, mostly in my experience is saying it on vt1 but not switching there
<apw> bjf, when it happened did you still have graphics on the screen instead of VT1
<bjf> apw, no, i was on VT1 (i think) no graphics
<snadge> yesterday  I was asked to report a bug for the linux package.. im at work now on the affected machine
<snadge> can i report the bug whilst using the mainline kernel that doesn't have the bug? .. or should i reboot into the affected kernel
<snadge> which means i lose my second display .. i guess temporarily
#ubuntu-kernel 2013-10-16
<apw> snadge, file the bug against the linux-image-NNN which is the broken one
<apw> and say which you are running in the commentary
 * apw yawns
<apw> morning ...
 * smb goes to get more tea
<tjaalton> apw: so, should I create a 'update i915_hsw to current 3.8.13.x' pull request first, and then the two new commits on top of that? 
<tjaalton> it's just a bit of manual work
<apw> tjaalton, that going to be like commits
<tjaalton> yeah
<apw> 57 commits
<apw> ?
<tjaalton> right
<apw> hmmm ... for SRU
<tjaalton> they just keep piling up :)
<tjaalton> bad kamal :)
<apw> i guess if we have applied them 
<apw> already for 'master' then they should be on hte ubuntu version
<tjaalton> yup
<tjaalton> I'll try with a few to see how awkward it is..
<apw> tjaalton, ok thanks ... i guess
<tjaalton> hmm, yesterday I got 57 commits as the diff, but only 37 now
<tjaalton> ah, that's the pure stable tree diff.. raring has more
<kamal> tjaalton, what'd I do?
<kamal> tjaalton, apw ... should I be terrified about whatever it is that you're talking about here ...  because I am!
<apw> yes, you should indeed, you are getting the blame at least
<kamal> apw, while I'm sure the blame is rightly directed . . .  what exactly am I getting the blame for?  :-)
<apw> needing 37 patches for i915 in quantal
 * kamal looks sideways at apw
<kamal> next you'll point out that we need 137 patches for i915 in precise!
<apw> yeah the 37 in q is to avoid that in p i think
<kamal> apw, are we really talking about quantal here?   tjaalton mentioned raring above (and I maintain 3.8, not 3.5, anyway) . . .  anyway...
<tjaalton> kamal: no worries, just kiddin ;)
<tjaalton> +g
<kamal> I am of course open to suggestions, but it seems implausible that we could call any 37-patch set reasonable for application to "stable"
<tjaalton> kamal: it's from your stable tree :)
<kamal> oh oh, do I have this all backwards?
<tjaalton> the diff .13..13.11
<kamal> oh.  in that case . . .
<kamal> I'm sure those patches are freaking awesome! . . .  perfect code, fully worthy of stable!  ;-) ;-) ;-)
<apw> i think he was saying the quantal needs a bunch of fixes already applied in stable for raring, but on quantal, or something
<apw> i am hoping some day he will send us a pull so we cna review
 * kamal goes back to hiding under a rock then :-)
<tjaalton> so I went through the 57 commits that git claimed that is the diff between .13 and raring, but in fact a bunch of those were already in .13, so the diff between quantal i915_hsw and raring is around 36 commits
<tjaalton> three only in raring, and one of those valid for haswell
<kamal> tjaalton, I'm curious about the three only in raring (you mean they're in raring, but not in 3.8.13.11, right?) ... send me that list?
<tjaalton> kamal: yeah I bet they are awesome, that's why I think it makes sense to merge to ubuntu/i915 in quantal :)
<kamal> (not that that relates to your quantal project)
<tjaalton> kamal: 0d0ecad2c0dd07e, e8c14411e539718, 0009bd009e9ec8b
<kamal> tjaalton, thanks
<tjaalton> the first one didn't make it upstream, actually
<rtg> jjohansen, when Linus merges 'Apparmor bugfixes for 3.12' you should propose both patches for stable
<jjohansen> rtg: ack, I will check if there is anything for stable. However I think all the bug fixes sent up lately have only been against the 3.12 pull request
<rtg> jjohansen, oh, right. 13.10 is carrying the AA development branch.
<jjohansen> yep
<smoser> hey
<smoser> stupid question
<smoser> (familiar pattern when smoser speaks)
<smoser> https://launchpadlibrarian.net/149319334/overlayfs_inotify.patch
<smoser> on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147
<ubot2> Launchpad bug 882147 in coreutils (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,In progress]
<smoser> could we have that ? if its functional? or help push it upstream ? 
<smoser> googling for CONFIG_INOTIFY_STACKFS doesn't really show anything
<bjf> smoser, that's not implemented upstream, downstream or any of the tributaries
<smoser> the patch is not.
<smoser> overlayfs is upstream, right?
<bjf> smoser, you are asking about inotify interfaces, right?
<bjf> smoser, in overlayfs
<smoser> overlayfs is upstream. right?
<smoser> i'd like to have inotify support in overlayfs, because lots of stuff sucks without it.
<smoser> i see that patch which seems to report that it is adding inotify to overlayfs
<xnox> apw: ^
<xnox> smoser: no, it doesn't not work and has performance penalty.
<smoser> doesnt work woudl be enough reason to not have it 
<smoser> :)
<smoser> xnox, you've tried it thoug?
<rtg-afk> smoser, overlayfs is not yet upstream
<smoser> ah. ok. i had thought it got accepted.
<rtg-afk> smoser, multiple attempts,. but no joy yet
<smoser> right. ok. well, move along then, nothing to see here.
<smoser> i saw that patch and hoped magic inotify support materialized from the ether
<smoser> xnox, you've tried it?
 * rtg -> EOD
#ubuntu-kernel 2013-10-17
<RoyalDogBiscuits> Heya. Mark has talked many times about "ultrasmooth" graphics. This is achieved with a low-jitter kernel. 
<RoyalDogBiscuits> Please see:  http://ovekarlsen.com/Blog/turning-ubuntu-12-04-into-a-professional-low-jitter-os/
<RoyalDogBiscuits> I can answer any questions.
<RoyalDogBiscuits> Low-jitter reduces interrputs in the datastreams, giving continuous graphics and audio, that is optimal for a multimedia computer OS.
<RoyalDogBiscuits> For instance Doom 3 which is a very jitter sensitive game, that Carmack not long ago stated was taxing even on modern computers, runs with accurate 72fps. 
<RoyalDogBiscuits> This also on a core 2 duo, and GTX 280.
<RoyalDogBiscuits> Doom 3 does three passes pr Open GL frame.
<RoyalDogBiscuits> interrupts :)
<ohsix> why did you change your name?
<ohsix> and only considering the kernel as a source of jitter is going to majorly miss all the real issues
<RoyalDogBiscuits> ohsix: It is tried and tested, there is no other real issues.
<rtg> apw, suppose we oughtta do a signed package for Saucy LTS ?
 * henrix -> lunch
<apw> rtg, hmm, i suppose we might indeed
<rtg> apw, are you still the expert there ?
<apw> rtg, yeah i'll take the action indeed
<arges> smb: hi
<smb> arges, maybe... :)
<arges> : ) 
<arges> smb: bug 1007082
<ubot2> Launchpad bug 1007082 in linux (Ubuntu) "BUG: Bad page state in process node pfn:8e9d9" [Medium,Incomplete] https://launchpad.net/bugs/1007082
<jpds> Anyone know how I can start to figure out why my laptop is a lot hotter on saucy?
<apw> jpds, it is sitting on your lap ?
<jpds> apw: Partially, but the fan is spinning a lot more than what I'm use to.
<cking> maybe install a raring kernel and see if that changes things
<apw> jpds, shame you didn't upgrade 3m ago :(
<brendand> how does dmesg get the timestamps used to mark entries?
<brendand> is it possible to get that number at any point?
<brendand> this number '[ 9231.618344]'
<brendand> which i guess is seconds after boot
<kamal> tjaalton, hey, so regarding those in-raring-but-not-in-3.8-stable haswell commits . . .   I'd be happy to take the two from upstream in 3.8-stable, if you were to request that
<kamal> tjaalton, that would be raring's e8c14411e539718 and 0009bd009e9ec8b
<tjaalton> kamal: yeah, do you need a formal request?
<kamal> tjaalton, yes please... an email to me with cc: stable@vger.kernel.org .   The upstream commits to request are:
<kamal> commit 21ad833075801a7cd81b5ef1604ffc6c600e5ff9 upstream.
<kamal> commit 7b9f35a6dd72f89452c58bbdbaf063027bf857ec upstream.
<tjaalton> ok, I'll cc the authors too so they can yell 'no!' if they want :)
<kamal> tjaalton, sure sounds good (I'll also do that when I actually queue up the patches)
<tjaalton> not that I think they should
<tjaalton> i'm working on backporting power well changes for haswell, it doesn't support hdmi/dp audio on 3.8 currently
<tjaalton> but getting that in stable might be asking a bit too much, currently at five patches and it's not fully there yet
<kamal> tjaalton, um . . .  does that relate to 2124b72e6283c4e84a55e71077fee91793f4c801 (which I'm about to queue for 3.8-stable, as requested by Shuduo Sang)
<tjaalton> kamal: yes, it needs the other four patches
<kamal> tjaalton:  212b72e drm/i915: don't disable the power well yet
<tjaalton> or at least it applies cleanly after them
<tjaalton> but it's not enough; after unplugging the cable, the hdmi/dp audio device is still listed on audio properties
<tjaalton> works fine on 3.11
<tjaalton> and apparently on 3.9-rc5
<kamal> tjaalton, hmm.   I backported 212b72e to 3.8 with no fuss at all (didn't apply cleanly, but was an easy/obvious port).    I wasn't aware that it needed any other patches, but ...
<tjaalton> huh, ok
<kamal> see my email (in kteam@) to Shuduo, asking whether it's really even relevant for 3.8
<kamal> Subject: Re: stable: 2124b72e6283c4e84a55e71077fee91793f4c801 need backport
<kamal> tjaalton, . . . . so now I'm confused.
<tjaalton> well, I thought 7f35610cc33cf7ee0797dc684ccc0057742dc12a is just as wanted
<tjaalton> but, we'll see after some testing
<tjaalton> if the one patch is enough then that's good
<kamal> I can't find 7f35610cc33cf7ee0797dc684ccc0057742dc12a  (which repo?)
<tjaalton> oops, mine :)
<tjaalton> hang on
<tjaalton> fa42e23c1055a4 is better
<tjaalton> so, the bisection showed the proposed patch fixing things, but of course i915 got 265 other commits to the driver since 3.8..
<kamal> tjaalton, well, fwiw fa42e23c1055a4 applies cleanly to my 3.8 tree
<tjaalton> yeah it does
<kamal> tjaalton, and I'd take it if requested (and assuming it actually compiles :-)
<tjaalton> the other commits I'm testing with are cb10799c194369633b18, 6b25a88752e8e and d5f21e4072645d0
<tjaalton> but wth.. now I see that this branch doesn't have 2124b72e6283c, grr
<tjaalton> so I'll just rerun the tests, maybe things work after pulling it
<kamal> tjaalton, ok, lmk what you want to do after you sort it all out.  fwiw, all three of those ^^ look fine to me also.
<tjaalton> ok cool
<brendand> cking, thanks for the answer on dmesg
<tjaalton> since the primary target is the quantal i915_hsw driver they're probably fine there but would be silly not to have them on 3.8/raring too
<tjaalton> especially since it's all haswell anyway
<kamal> tjaalton, agreed, plus it makes my life easier for future i915 stable merges
<tjaalton> sure
#ubuntu-kernel 2013-10-18
<F41L> Having issues with 3.11 kernel. My 13.10 installation disc is even affected.
<F41L> Possibly related to graphics? (AMD Radeon 7000 series) but recovery mode also locks up soon after entering.
<F41L> booting 13.10 using 3.8 kernel appears to work somewhat normally, despite a KDE error on login.
 * apw groans
<ppisati> so, if you disable a feature in a pkg, and that feature built a file that was later referenced in a debian/*.install file, the build fails
<ppisati> so the real question is: how do i know which feature build what? or it's just a tril and error process? i guess the second one...
<apw> normally trial and error indeed
<infinity> ppisati: You either be intimately familiar with the configure and Makefiles or you build the package and see what changed. :P
<ppisati> and, let me guess, i can't reuse the ppaX id after a build failure
<infinity> Nope.
<infinity> Good thing there's an unlimited number of integers.
<infinity> Also, good thing we have mechanisms for testing these things LOCALLY, so you don't have to look a fool with dozens of PPA test builds. :P
<infinity> *hint, hint*
 * ppisati thinks infinity is a peeper...
<RAOF> Also, the â-ncâ option to debuild might be of interest to you.
<apw> jodh, hey ... what is the startpar-bridge job for?  it seems to start a lot on my test box here
<jodh> apw: sysvinit -> upstart transition-type stuff: slangasek's baby.
<apw> jodh, oh ... hmmm i think
<apw> jodh, it must run like 50 times on boot
<brendand> cking, hi
<cking> brendand, hi
<brendand> cking, what you mentioned about getting the local time of cpu0
<brendand> cking, is that accesible in /sys or /proc?
<cking> brendand, why do you need this?
<brendand> cking, we want to write a hook for pm-suspend that gets the clock time at the start of the suspend process
<brendand> cking, and also at the end of resume
<cking> brendand, how about the easy way: "echo PM-SUSPEND-HOOK-START" | sudo tee /dev/msg ... and at the end of the test grep for it in dmesg
<cking> oops, I mean /dev/kmsg
<brendand> cking, because fwts is rude and zaps kmsg
<brendand> !
<brendand> cking, :)
<brendand> cking, we're using fwts to invoke the suspend (in order to get device-check etc) and it is clearing kmsg 
<brendand> cking, although i'm not positive that's after the hook runs
<erle-> i just reported a bug with waking up after suspense to RAM
<cking> brendand, why not file a bug against fwts and specify what you want and I can look into adding it
<erle-> there is a crash report in /var/crash
<erle-> is it save to just append it?
<erle-> or may it contain private data?
<brendand> cking, we want to measure the time from the beginning of suspend to when the system is suspended. then from when it is requested to resume until user space is resumed
<brendand> cking, if that sounds doable i can file a bug
<brendand> cking, we're trying to do it at the moment but it's a little rough around the edges
<brendand> i mean we *are* doing it
<cking> brendand, doesn't fwts already report the duration of the suspend?
<brendand> cking, we're not interested in the time it slept for though
<brendand> cking, and does it report those things seperately or only the total duration?
<cking> brendand, yup, it does not do what you require, I could add that though
<brendand> cking, well, i don't want you to do my job for me, but if it would be more suitable to add it to fwts then i'd take you up on it
<cking> and/or not make it nuke the kernel messages
<cking> brendand, when do you require a solution?
<brendand> cking, well we want to get this fixed for 12.04.4
<brendand> cking, let me file a bug
<erle-> bjf, crash report is coming :)
<cking> brendand, file a bug and I will mull over it and get back to you on monday if it is easily do-able or not
<brendand> cking, https://bugs.launchpad.net/bugs/1241638
<ubot2> Launchpad bug 1241638 in Firmware Test Suite "FWTS to measure the time from invoking suspend to suspend, then the time from waking system to user-space resume" [Undecided,New]
<cking> ack
<slangasek> apw: yeah, startpar-bridge triggers an awful lot
<slangasek> apw: it becomes obsolete once everything is managed by upstart and not by sysvinit
<apw> slangasek, with --debug on my test rig here (read a very slow machine) it is seemingly vomiting as the predominant output
<slangasek> yes, it will do that
<slangasek> its rules is 'start on started JOB!=startpar-bridge or stopped JOB!=startpar-bridge
<slangasek> '
<slangasek> s/rules/rule/
<slangasek> so that's an awful lot of starts and stops, unfortunately
<apw> so that starts and checks if yo umeant an oldstyle script i assume
<erle-> jsalisbury, hi, i am the guy with the suspend bug
<erle-> jsalisbury, i tried 3.12 and it works
<jsalisbury> erle-, which bug number is it?
<erle-> will saucy get kernel 3.12 or are you just planning to backport the fix?
<erle-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1241582
<ubot2> Launchpad bug 1241582 in linux (Ubuntu) "system freezes after suspend to RAM" [High,Confirmed]
<jsalisbury> erle-, thanks.  Saucy will stay on the 3.11 kernel.  The next step is to identify the commit in 3.12 that fixes this and see if it was already sent for inclusion in the stable tree.
<jsalisbury> erle-, we should probably test the latest 3.11 stable kernel first to see if it's already fixed there.
<erle-> you mean upstream 3.11?
<jsalisbury> erle-, if it's not, we can perform a reverse bisect to find the fix in 3.12
<jsalisbury> erle-, correct.
<jsalisbury> erle-, I'll post the links to upstream 3.11 in the bug report.
<erle-> this?
<erle-> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/
<erle-> kernel.org says 3.11.5 is latest
<jsalisbury> erle-, yup, that's it.
<jsalisbury> erle-, it would be great if you can test that one 
<erle-> i would like a statement about the safety of apport in regards to privacy, i am somewhat curious
<erle-> also about the files in /var/crash
<ogra_> erle-, apport isnt developed by the NSA ... does that suffice ?
<ogra_> (selinux is)
<erle-> ogra_, i mean, does it take care of not to include potentially private information into reports?
<erle-> like passwords in memory dumps
<erle-> i dont like my passwords dumped on launchpad, you know? :)
<jsalisbury> erle-, there is some info here: https://wiki.ubuntu.com/Apport
<ogra_> oops, sorry i  mistook apport with apparmor
<ogra_> (since this is the kernel channel my brain tripped over this)
<apw> erle-, we don't take memory images from crashes in the normal case
<erle-> jsalisbury, just another reboot and we will know
<jsalisbury> erle-, great
<erle-> jsalisbury, works
<erle-> jsalisbury, and yes, i made sure that grub picked the right one
<jsalisbury> erle-, thats good news.  that means the fix will make it into Saucy when it gets the 3.11.5 updates.
<erle-> jsalisbury, yes
<erle-> and i personally will just keep this one now
<erle-> but i will purge the 3.12rc
<jsalisbury> erle-, ok
<bjf> erle-, those commits should hit -proposed towards the end of next week and -updates in approx. 3 weeks
<erle-> bjf, don't you think that this will hit a lot of users with certain hardware?
<erle-> 3 weeks seems long
<bjf> erle-, it takes 3 weeks to work though our stable process there are quite a few (197) commits in the next update and we like to do a little testing before just putting it out
<erle-> bjf, yes, i understand that, it was just a comment
 * apw will be calling it a week in about half hour
<rtg_> ppisati, can you have a look at bug #1239800 ?
<ubot2> Launchpad bug 1239800 in linux (Ubuntu) "Soft lockup when running bonnie++ only at 1600 mt/s" [Medium,Incomplete] https://launchpad.net/bugs/1239800
<erle-> jsalisbury, do you have any link to a kernel changelog that refers to my problem?  (you don't have to look for one, but if you found one already i would be interested)
<jsalisbury> erle-, I didn't do any searching on what specific commit fixes the bug
<erle-> jsalisbury, ok
<erle-> will 3.11.3 or something come into ubuntu release before 3.11.5 or wont it come at all?
<erle-> maybe even a earlier version than 3.11.5 fixes the issue
<erle-> but i dont want to try them all now
<jsalisbury> erle-, 3.11.0-11.17 was already rebased to 3.11.3.  So there is always the possibility it was fixed in 3.11.4
<rtg> jsalisbury, saucy master-next is up to 3.11.5
<jsalisbury> rtg, ack.  
<jsalisbury> erle-, so the next saucy release will be based on 3.11.5
<erle-> thank
<erle-> and that means the 3 weeks you mentioned, right?
<jsalisbury> correct
<erle-> and if anybody asks for help with this, i will propose updates-proposed for the meantime
 * rtg -> EOW
<sn0wb1rd> Hello geeks, I have the "3.2.0-49-virtual" version of kernel on my 12.04 Ubuntu virtual machine. I am experiencing some issues with xfs with and found that this commit https://github.com/torvalds/linux/commit/3948659e30808fbaa7673bbe89de2ae9769e20a7 fixes the problem in 3.4 version of the kernel. There is no virtual kernel available for 3.4 or anything higher than "3.2.0-49-virtual". How do I backport the change and rebuild my kernel to include 
<sn0wb1rd> this fix?
<sn0wb1rd> Also is it possible to request for virtual kernel images for recent versions of kernel?
<bjf> sn0wb1rd, that looks like a pretty trivial fix. please file a bug and add that information to the bug
<sn0wb1rd> bjf: that is awesome. filing a bug now.
<sn0wb1rd> bjf: Is this about getting virtual kernel images for recent versions of kernel?
<bjf> sn0wb1rd, no, that will help get the fix into the kernel. then we'll roll out new kernels.
<sn0wb1rd> Ok, I'll file a bug with the information I have.
 * bjf is now afk
<sn0wb1rd> bjf: https://bugs.launchpad.net/ubuntu/+bug/1241848
<ubot2> Launchpad bug 1241848 in Ubuntu "Request for updated Ubuntu virtual kernel images" [Undecided,Confirmed]
#ubuntu-kernel 2013-10-20
<ShapeShifter499> hi 
<ShapeShifter499> right now I have to compile a kernel with few modules built as static instead to get a trackpad to work
<ShapeShifter499> how do I get the kernel devs to merge said changes so I don't always have to compile to update kernels?
<ShapeShifter499> This problem affects all Acer C7 Chromebooks who's users (like me) have mod the bios in order to run a stock Ubuntu system in place of Chrome OS
<apw> ShapeShifter499, you would want to file a bug against the package 'linux' and describe what you are having to build in and why.  it seems most likely that building them in is not necessary if the appropriate module aliases were present, but we can tell that from that bug
<apw> once it is filed shove the bug number in here, so we can find it
#ubuntu-kernel 2014-10-13
<jungle_bg_> There is a problem with the git repo for the saucy kernal source. I have been trying to get the ubuntu kernal source for saucy. This failed for me and someone else in #ubuntu confirmed:  git clone git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git
<apw> jungle_bg_ (N,BFTL), the repo has been archived because saucy is no longer supported, archived repos are in git://kernel.ubuntu.com/ubuntu-archive
#ubuntu-kernel 2014-10-14
<rtg> tseliot, the lts-utopic kernel is in https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa is you wanted to start testing nvidia and fglrx DLMS drivers in Trusty.
<rtg> if you wanted*
<rtg> DKMS* - sigh, can't type today.
<tseliot> rtg: ok, I'll test it. Thanks
<jduck> hello
<jduck> has anyone seen problems with the -37 kernel on 14.04 ?
<jduck> i'm getting weird behavior where incoming packets are not making it back to my userspace programs
<jduck> i rebooted into a -32 kernel and its not happening
<jduck> has anyone else seen this?
<jduck> this channel is so dead!
<rww> It's a coordination channel, not a support channel, so people don't tend to sit around waiting for questions to appear.
<apw> jduck, i do not recall seeing anyone mentioning anything like that, no.  some sort of example so we know waht sort of data might help.
<jduck> fair enough
<jduck> all i did was ran ping 8.8.8.8. after a bit i saw packet loss, so i used tcpdump and saw the packets were still coming in, but not making it to ping program
<apw> jduck, and this wasn't during the recent 8.8.8.8 outage i assume.  so i guess if you could file a bug on linux from the broken one, and add some example ping output from the broken one, and the working one you have; do include both version numbers in the report
<jduck> apw: no, the packets were definitely coming back from 8.8.8.8 (LOL)
<jduck> where do i file such a bug? do i have to sign up?
#ubuntu-kernel 2014-10-15
<binBASH> jduck: read on here https://wiki.ubuntu.com/Kernel/Bugs
<apw> jduck, "ubuntu-bug linux" will pick up the various things we normally ask for
<ubuntu42> Where are the release notes/change summary for Ubuntu 12.04.5 ?
<ubuntu42> "This page does not exist yet. You can create a new empty page, or use one of the page templates."
<ubuntu42> https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.5
#ubuntu-kernel 2014-10-16
<jtaylor> hm is the bisect wiki still up to date?
<jtaylor> I run into one dead end or wrong path after the next
<jtaylor> or I'm just to dumb to read the prerequsite section  ...
<tseliot> apw: the only dkms package (that I maintain) that needs an update for lts-trusty is bcmwl. rtg doesn't seem to be online but perhaps you can let him know
<apw> tseliot, ack
<apw> tseliot, and what about lts-utopic, as that will be in your balywick in the near term
<tseliot> apw: sorry, I really meant to say lts-utopic, not lts-trusty
<apw> tseliot, even better, thanks
<jduck> sorry guys, haven't had time to report the kernel bug. i'm really surprised no one else is seeing it.
<tzn> Hi guys
<tzn> Iâm looking for a way to get source for this kernel linux-image-3.11.0-18-generic_3.11.0-18.32~precise1_amd64.deb package
<tzn> any hints?
<tzn> Well, I;m particualry interested if this was fixed http://www.cvedetails.com/cve/CVE-2013-6382/
<rww> tzn: I believe it is. If you look towards the end of that page, you'll see a bunch of USN links. Open them all, find the one that applies to your system, and check the version number it mentions as being fixed is lower than what you have
<rww> if I'm reading right, http://www.ubuntu.com/usn/USN-2113-1/ , which says it was fixed in 3.11.0-17
<tzn> Thanks, this is what I learned as well
<jtaylor> hm what ubuntu kernel does mainline 3.13.8 correspond too? that may have introduced bug 1381815 from utopic into trusty
<ubot5> bug 1381815 in linux (Ubuntu) "left touchpad button stopped working in 3.16.0-22.19" [Undecided,Confirmed] https://launchpad.net/bugs/1381815
<apw> jtaylor, 3.13.0-21.43 to 3.13.0-23.45 inclusive were based on 3.13.8
#ubuntu-kernel 2014-10-17
<Sk> Suppose a user level application access a file on disk, how do we get the accessed data at kernel level??
<Sk> please help!
<apw> the application must trigger the access somehow, either via the read system calls, or accessing an mmap etc.  you would see the data i the calls which handle those
<jtaylor> alright I think I have triaged bug 1381815, anything more I need to do besides hoping someone looks at it?
<ubot5> bug 1381815 in linux (Ubuntu) "left touchpad button stopped working in 3.16.0-22.19" [Undecided,Confirmed] https://launchpad.net/bugs/1381815
<jtaylor> oh trusty is still in proposed
<jtaylor> is the process for propose regressions the same as regular sru?
#ubuntu-kernel 2014-10-18
<Laney> jtaylor: mark the sru bug verification-failed
<jtaylor> also for the kernel? that never gets verification-needed
<jtaylor> but added it, a extra tag should not harm :)
#ubuntu-kernel 2014-10-19
<iri> If I install debs from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17.1-utopic/, are they signed and so forth, or is there another thing I need to do to verify then?
<iri> s/then/them
<apw> iri, they are not signed, no.  they are not designed for anything other than testing; they are semi-official builds purely for debug
<iri> I'm now resorting to building my own from git://kernel.ubuntu.com
<iri> Or alternatively, can I install a signed utopic kernel on my trusty machine? Is there a straightforward way to do that?
<apw> iri, there will be utopic kernels for trusty pretty much as soon as utopic releases on thursday
<iri> ah, great. Based on the 17.x series?
<iri> *3.17 series?
<apw> nope, utopic isn't 3.17 
<apw> it is 3.16
<iri> k
#ubuntu-kernel 2015-10-12
<UNIm95> apw: Hi. I have tried to update my kernel to   3.13.0-66-generic with linux-image-generic package. But i got Kernel oops.
<UNIm95> apw: My first bug report was here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1497184
<ubot5`> Ubuntu bug 1497184 in linux (Ubuntu Vivid) "Kernel-panic with 3.13.0-64.104 generic kernel (BUG at net/core/skbuff:1290)" [High,Fix released]
<UNIm95> After 3.13-64 kernel in 14.04 i cannot use  ubuntu at all
<smb> UNIm95, Hm, what upload number (dpkg -l |grep linux-image) is that? Should be 108 to be safe
<apw> UNIm95, yeah what smb says, we'd need a specific version number and an indication of whether the kernel oops is the same as that bug
<UNIm95> smb: 3.13.0-66.107
<smb> UNIm95, Ok, 107 unfortunately had another "issue" you should update once more to get 108
<UNIm95> apw: smb Now i'm using web interface of freenode. I havo sound notifications.
<UNIm95> I have no sound notifications
<UNIm95> Ok. Im will try now.
<UNIm95> But after *64 kernel i cannot use my computers.
<UNIm95> When i boot i choose *-63 kernel
<smb> UNIm95, Ok, sound issues might be part of the problems. One general thing, if you need a computer to be more stable you should disable the proposed pocket once you are good.
<apw> you can update from any of the older kernels
<UNIm95> smb: No! I have no sound issues. I have noticed you answer only yet.
<smb> UNIm95, ah ok. got it
<UNIm95> usually I'm using pidgin.
<UNIm95> And i got another error.
<UNIm95> while updating
<UNIm95> E: libpam-systemd: 55.2632:package is in a very bad inconsistent state; you should  reinstall it before attempting configuration
<apw> UNIm95, normaly apt tells you what to run to get out of the mess at the bottom
<UNIm95> Ok. Last error with libpam-systemd was my fault. I fixed version of this lib in synaptic.
<UNIm95> I'm going to reboot. I hope i can boot with *-66.108
<smb> That one work for me at least
<UNIm95> Ok. Now booted without problems.
<UNIm95> No oops messages or errors while loading.
<smb> Sounds good. :)
<UNIm95> smb: Not really. With *-64.* I got random kernel panic.
<UNIm95> smb: usaully first 30 minutes was everything ok.
<smb> UNIm95, Well yeah, the initial one in proposed had those issues and was replaced later (again same abi number but incremented upload), then there was a -65 which you seemed to have missed (which was ok as far as I can tell). And now you somehow unfortunately went straight to the next one that caused problems.
<smb> UNIm95, As I said before, on machines that need to be more stable, you should disable the "proposed" pocket after you are done testing (often you are asked to enable it to verify something)
<UNIm95> smb:  But prororsed have new Firefox, Chromium and thunderbird. This apps i need for  work and life.
<smb> UNIm95, Actually no. The proposed pocket has updates first before the go to updates (as a wider testing). If you want things as soon as possible, yes, proposed helps. But you also can get a kernel that breaks your machine (like you did). Not that we really want that to happen too often but ... things happen.
<UNIm95> smb: Ok. Thanks for information. I thought than only proposed keeps some apps updated. 
<apw> right, allays bear in mind that -proposed is where all the testing occurs, so things in -proposed are effectivly untested when the appear
<apw> updates in -proposed migrate to -updates when they are deemed good enough
<smb> Yeah that ^ :)
<apw> in this case the .107 kernel failed that testing and was replaced without ever reaching -updates, win
<smb> In those cases it is good to have more people with proposed enabled to catch things. But it seems there might be a slightly better explanation needed so all those understand the implications and the risk.
#ubuntu-kernel 2015-10-13
<FourDollars> Hi, how to make udeb from Ubuntu kernel tree?
<FourDollars> Is there any target for `fakeroot debian/rules`?
<FourDollars> OK, I found it. It is binary-udebs.
<tseliot> apw: BTW, I've just found out why I couldn't build drm-intel-nightly using exactly the same code that you use for the mainline PPA. Building in trusty fails, as the build dependencies are probably a little too old (e.g. libusbip-dev), whereas building in a wily chroot seems to be working
<apw> tseliot, hmmmm, i thought we built the nightlies there too ?
<apw> (in trusty)
<tseliot> apw: I'm not really sure. All I know is that I ran into a number of failures in trusty
<apw> tseliot, i think i am expecting problems indeed, so supprised if working in my builds
<tseliot> if they are trusty chroots, then it could be magic ;)
<caribou> Any reason why /etc/kernel/postinst.d/initramfs-tools is executed when we remote a kernel package ?
<caribou> i.e. rebuilding  the initrd.img just prior to delete it ?
<caribou> s/remote/remove/
<apw> caribou, for linux-image-extras we do that, as you have removed only half the kernel, and the initrd should match it
<caribou> apw: ok, got it
<caribou> apw: I need to account for that in the kdump-tools hooks as it hoses the symlnks
<caribou> symlinks
<caribou> apw: since it reruns the kernel hooks for that package version, the symlinks are re-created for that version which we do not want
<apw> i think we check in ours that they are the same
<apw> and don't change them
<caribou> apw: the symlink I'm talking about are the /boot/kdump/initrd.img for the smaller one I produce
<caribou> well kdump-tools produce
<apw> caribou, right, yes, you'll want to do something similar, if we are making the new one ponit to the same place, don't update that or .prev
<caribou> indeed
<caribou> well, that's not going to make my life simpler as I don't know if I'm removing a package or adding one when I run the postinst hook
<caribou> and it is the postinst hook that creates the /boot/kdump/[initrd.img|vmlinuz] links
<caribou> apw: ^^^
<apw> caribou, right ... but this is triggering out of postrm in the kernel, you will still want to make a new one
<apw> caribou, what we do is readlink the "current" link and if its what we want to set it to, we assume reinstalation and ignore link changes
<apw> caribou, by which i mean, what we do in the kernel in postrm for extra is to still make a new initrd
<apw> caribou, as you might stop there, switching to -virtual for instance
#ubuntu-kernel 2015-10-14
<caribou> apw: smb: I'm thinking of changing my approach regarding the creation of symlinks to /boot/kdump/[initrd.img|vmlinuz]
<caribou> I'm thinking of having /usr/sbin/kdump-config take care of the symlink management
<caribou> since I have no way to know which is the proper initrd to use upon install/removal of kernel packages
<apw> caribou, "make links point to the running kernels vmlinuz and corresponding smaller initrd" at load time ?
<caribou> apw: yes
<apw> caribou, not a bad idea _if_ you are sure you can write to the fs at the itme it happens
<caribou> apw: because, if the kernel hook make the symlink, adding a newer kernel package will make the symlink to files that have not been booted yet
<caribou> apw: yes, I think that root is mounted rw when kdump-config loads the kexec command; I'll check
<apw> caribou, i'd expect it to be late enough indeed, but worth checking
<smb> hm... or is that link required at all? if you can figure out what the link should be at boot time...
<caribou> apw: and it makes the kernel hook simpler as it doesn't have to worry about the kdump-config specifics
<apw> caribou, yeah
<apw> smb, yes because it is baked into a config file the user may change
<caribou> smb: yes, kdump-config relies on it to issue the kexec command
<apw> smb, so they can make it a specific older kernel, or leave it be and they get the matching kernel
<caribou> if the symlink doesn't point to an existing file, the kexec load command will fail
<apw> and caribou that is a much saner semantic
<apw> "kdump kernle will match your runnign kernel" always, not the latest one you installed but maybe not the one you booted
<caribou> apw: then I can make kdump-config list available kernels & choose one specific to link as an option
<apw> caribou, yep, all much nicer
<caribou> apw: ok, I'll work on this.
<apw> and right now they can just edit the config to make it point at a specific one
<apw> right ?
<caribou> apw: it will not make 15.10, doubtful on it being SRUed so we may have to increase crashkernel= for a while
<apw> caribou, its presumably not huge huge ?   and it fixed a real bug ... so we might get it through
<caribou> apw: right now, it default to the booted kernel and doesn't even use the variable in the config file
<caribou> apw: maybe, we'll see
<caribou> I should have it working by EOD
<apw> caribou, nice thanks
<gQuigs> I just did a fresh install of Wily and linux-headers-generic linux-image-generic thermald are showing up to be autoremoved
<gQuigs> has the packaging changed to make that make sense?
<gQuigs> (I actually did the reinstall because I accidentally removed the kernel - which I recovered, but then btrfs partition had other issues)
<apw> gQuigs, no that is not correct, as withouth the first two you would not get updates, the third would be held on by the second iirc, somewhere linux-generic has gone missing, and it should not
<apw> gQuigs, iirc if you file a bug against ubiquity it will upload the install logs which might help
<apw> infinity, ^ is it ubiquity?
<apw> stgraber, yo, so jjohansen has looked at that lxc test suite hang, and it seems the profile needs to be updated in T to something newer
<gQuigs> apw: I'll try to reproduce it and file a bug if I can
<apw> gQuigs, i suspect it doesn't happen all the time, else we'd hear about it a lot, if you still ahve the instance which failed, then the logs for the original install are kept for bug reporting
<gQuigs> ok, will do
<stgraber> apw: and how is that not a regression? :)
<apw> stgraber, it is a regression, but the change in the kernel is for a cve
<stgraber> ok
<stgraber> jjohansen: what needs changing?
<apw> stgraber, there is a new check int he profile, one which must have been added in later releases, as V is ok with this kernel change
<stgraber> apw: would be helpful to know what exactly so we can SRU it ASAP
<apw> stgraber, heh yeah there is that, erm, when i looked the profiles were very similar even T->W 
<stgraber> lets see if I can diff those quickly then
<apw> stgraber, its something mount related, hrm, and jj did check that the old kernel will not implode with the update, whatever it was
<stgraber> apw: so far looks like it's stuck at the same spot, it's a pretty long test so maybe it's just not done yet, but doesn't look too good so far
<apw> bah
<apw> stgraber, so much for that fixing it, though i am sure jjohansen tested the same, we need to find out what needs putting in specifically to make sure its in the one you updated to
<apw> stgraber, that said the ppc64el is just finishing so they wern't submitted that long ago, how long odes that whole suite take on i386 anyhow ?
<stgraber> apw: arm64 and ppc64el always fail, only amd64 and i386 matter
<apw> stgraber, right, i only entioned it because it is runiing, and it would have been submitted at the same time as the ones we care about, bounding how long ago it was run
<stgraber> apw: yeah, I'm watching the live adt console here
<stgraber> and amd64 and i386 got past test-symlink which means they're currently in test-ubuntu and have been for 20+ min from what I saw
<apw> stgraber, right, same, i just don't know how long a good run takes
<apw> 15m it seems, looking back 3 or 4
<apw> if it is still at the same place in 15m then we need to fnid out from jjohansen what he had to add
<apw> to confirm that was what we tried
<stgraber> I still have a hard time understanding why the change I did would help. I mean all the other tests which also do start containers are passing fine...
<apw> stgraber, it was meant to be to do with empty paths somewhere, removed things under other things, something like that
<stgraber> hmm, ok, sounds like the description of most apparmor bugs ;)
<apw> heh yeah there is that, sadly :)
<gQuigs> apw: reported here - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1506169  looks like linux-generic was installed, but removed by one of my first changes after install
<ubot5`> Ubuntu bug 1506169 in ubiquity (Ubuntu) "fresh install - linux-headers-generic linux-image-generic python-notify thermald can be auto removed" [Undecided,New]
<stgraber> apw: still stuck
<infinity> gQuigs: Do you have the apt log(s) from that system too?
<infinity> gQuigs: Certainly not an installer bug if something you install after the fact is removing linux-generic, but would still be good to hunt it down.
<stgraber> jjohansen: when you're around. http://launchpadlibrarian.net/221223666/lxc_1.0.7-0ubuntu0.3_1.0.7-0ubuntu0.8.diff.gz isn't enough to fix the current hang in lxc-test-ubuntu, what else do we need?
<stgraber> oh, and that diff is pretty useless because it's not diffing the right thing...
<gQuigs> infinity: attached the logs, but I still don't really understand why it was removed...
<infinity> gQuigs: Well, it would have told you it was happening, assuming you used apt from the command line?
<infinity> gQuigs: It pays to actually read the "The following packages will be removed" stanza before saying yes.
<gQuigs> infinity: :) indeed, except I was using the graphical drivers widget to install the nvidia driver
<infinity> gQuigs: Oh, aptdaemon, not apt, so it happened behind the scenes with ubuntu-drivers-common.
<infinity> gQuigs: Lemme try this in a chroot with apt and see what it says.
<infinity> gQuigs: Your URL to the PPA is a 404.  Which PPA was it really? :)
<gQuigs> infinity: - https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
<infinity> To be fair, there's also a minor installer bug here that we should be marking the second-level metas as manual too, I think.
<infinity> So if someone decides to, say, remove headers, they don't lose their kernel.
<infinity> Pretty sure d-i DTRT there, while ubiquity might not.
<infinity> cyphermox: ^
<infinity> Actually, this bug might be mine in the livefs creation.
<infinity> I'll look in a second.
<infinity> But none of that excuses a package bumping off linux-generic. :P
<gQuigs> infinity: hmm, I did a vm test and just apt-get installing the packages doesn't mark it for removal
<gQuigs> it= linux-generic
<infinity> gQuigs: Indeed.  Doesn't here either.  Might have to mock an nvidia card being installed somewhere here, so I can reproduce the ubuntu-driver-common behaviour. :/
<gQuigs> infinity: do you think a livecd test (on my hardware) would be useful?  what extra logs/debug to take?
<infinity> gQuigs: I'd kinda want to drive, just to experiment.
<infinity> gQuigs: Booting to a live session, installing SSH, and giving me access to abuse might be helpful. :P
<cyphermox> infinity: most things in ubiquity are just running d-i bits, were you talking specifically about the metas?
<gQuigs> infinity: hmm :P - but yea, I guess I might as well confirm that it's reproducible on just the livecd 
<infinity> cyphermox: Yeah, the kernel/meta bits aren't d-i driven, IIRC.  But it's also mostly there in the livefs before ubiquity even touches it, so it might be my bug. :P
<gQuigs> infinity: what would be the first thing you would look at/
<infinity> gQuigs: I'd run 'ubuntu-drivers list' from the CLI after adding the PPA, check what it thinks it wants to do, try that in both apt and filtered through aptdaemon, experiment, I dunno.  No exact science here when debugging other people's software. :P
<gQuigs> will give that a try in a bit
<cyphermox> I'm supposed to have an nvidia card here somewhere, but I can't find it
<infinity> cyphermox: Really?  The one I have here is larger that most computers, it's hard to miss.
<infinity> But it's also in a machine I don't feel the overwhelming urge to reboot right this second.
<cyphermox> well, I wouldn't have a machine to put it in anyway
<jjohansen> stgraber: I added the rule
<jjohansen>    mount options=(rw,bind) /dev/pts/ptmx -> /dev/ptmx,
<jjohansen> to the lxc-start profile, that debdiff is NOT sufficient because it doesn't have a rule that matches
<jjohansen> I just reinstalled and tested again, and it still works for me
<stgraber> jjohansen: so I was told that wily's lxc is working properly, is that wrong?
<jjohansen> stgraber: I think so but I didn't go in and verify last night
<jjohansen> stgraber: now it is possible, there is another bug, something fixed in wily and not trusty that is also affecting this too. I haven't compared yet
<stgraber> jjohansen: ok, so current diff from what I uploaded to trusty to current git master is:    mount options=bind /dev/pts/ptmx/ -> /dev/ptmx/,
<stgraber> oops
<stgraber> http://paste.ubuntu.com/12784047/
<jjohansen> ah, yeah that diff should do it
<stgraber> ok, so I need to cherry-pick that part into our stable branch too, then re-sru it...
<stgraber> jjohansen: ok, re-synced our apparmor in all upstream branches, will update the SRU now
<jjohansen> stgraber: ack
#ubuntu-kernel 2015-10-15
<ianclark001> Hi all, today I found myself unable to boot (specifically to get past the full-disk encryption screen). I couldn't find a way to retrieve any meaningful information as to why this was. I'm able to boot using the recovery mode, and everything works fine when using 3.19.0-28-generic, but 3.19.0-30-generic just won't boot.
<ianclark001> Would be super-appreciative of any guidance as to how I should approach debugging / resolving
<smb> Hm, if people would give a little time to respond...
<caribou> apw: smb: do you guys have good ties with the Debian kernel people ?
<caribou> I'm thinking of proposing my "small initrd" changes to Debian as well
<caribou> I see that dannf is in the team, I'll probably ping him about this later
<smb> caribou, We (ok, probably apw more) have talked to Ben a few times...
<caribou> smb: on a side note, who "owns" the /boot directory ?
<apw> caribou, i'd not call our ties strong no, they should be better than they are, i guess henrix talks to ben a fair bit on security topics
<caribou> I mean who whould mostly be concerned about kdump-tools putting stuff there ? the kernel team ?
<apw> between us and the bootloader people
<smb> Maybe a shared interest between kernel and grub...
<caribou> apw: I just don't want to ruffle feathers by adding stuff there
<apw> did we decide it had to be in there, i thought they were loaded after we had filesystems
<apw> else /var/lib/kdump or whatever is an option
<caribou> apw: hmm, true; might be better there, let me test
<caribou> apw: I need to test. kexec is mostly concerned there
<apw> ack
<caribou> apw: ok, thanks for the info
<caribou> apw: smb: I will write a blog post about the proposed changes
<apw> nice
<caribou> apw: FYI - file system availability is not an issue here
<caribou> the kexec call at boot time goes and reads the content of vmlinuz & initrd.img in memory for later use
<caribou> hmm, well that's only true for the vmlinuz
<caribou> nevermind, initrd.img goes in memory too
 * caribou is making his way into kexec sources
<apw> caribou, right they are both loaded at "setup time"
<apw> so its all about the kdump job, where it comes in the boot process, whether it is after wait for filesystems or not
<caribou> apw: kdump-config load happens late at boot time
<caribou> apw: it happens after network-online.target
<apw> then i'd say it matters not where they are in a disk sense
<caribou> apw: I had a doubt for a while on wether kexec was loading them only when triggered so I went back to the source to check
<apw> caribou, no it definatly has to load them at init time, else it would rely on a lot of the kernel working to dump, which would defeat the purpose
<caribou> apw: indeed
<aisrael> I'm running 15.10 and noticed (after a failed reboot) that there's no packaged for the signed kernel for 3.16.0-41-generic (looks like the last signed is -30). Is there something I'm missing, or should I downgrade kernels (this is on a Mac Mini so the signed kernel is important)
<apw> aisrael, do you have linux-signed-generic installed ?
<aisrael> apw: Yes, sorry. I have 3.16.0-41-generic signed. I meant to say that there's no signed package for 3.19.0-30
<apw> aisrael, ok i am utterly confused, you are installinling linux-lts-vivid-generic ?
<apw> aisrael, to swithc up from lts-utopic to lts-vivid ?
<apw> or did you upgrade utopic to vivid ?
<aisrael> apw: I upgraded from trusty -> utopic -> vivid
<aisrael> I just found the signed package -- it wasn't installed when I upgraded last, so I might be wasting your time. :(
<apw> aisrael, ok and do you have linux-signed-generic package installed
<apw> as it is that that makes sure the signed kernels get installed as we release them
<aisrael> apw: Aha. I did not have the meta package for the signed kernel installed
<apw> and that would account for the lack of a signed one then
<aisrael> I'll reboot that machine and verify that worked (and I'll add notes to the Ubuntu on Mac docs to note that requirement)
<aisrael> apw: That fixed it, thank you!
<lfaraone> jsalisbury: can you also upload a sig on the SHA256SUMs for your latest build in http://kernel.ubuntu.com/~jsalisbury/lp1500751/ ? :) 
 * lfaraone is paranoid, sorry.
<jsalisbury> lfaraone, sure
<jsalisbury> lfaraone, done.  In a file named: signature-lp1500751-commit-90dcba7ee
<ogra_> grmpf ... 
<ogra_> does anyone know a way to make devtmpfs re-populate /dev ? i ran a broken script that wiped my dev dir and dont want to reboot
<apw> ogra_, maybe you can retrigger udev to repopulate it
<ogra_> apw, i tried that ... it doesnt recreate the initial nodes 
<ogra_> in the end i bit the bullet and rebooted 
<ogra_> (i had a semi populated /dev ... but all block devices were missing etc)
#ubuntu-kernel 2015-10-16
<cking> In file included from /usr/include/endian.h:36:0,
<cking>                  from /usr/include/powerpc64le-linux-gnu/sys/types.h:216,
<cking>                  from ../../../lib/libspl/include/sys/types.h:32,
<cking>                  from ../../../lib/libspl/include/atomic.h:30,
<cking>                  from atomic.c:27:
<cking> /usr/include/powerpc64le-linux-gnu/bits/endian.h:26:4: error: #error Both BIG_ENDIAN and LITTLE_ENDIAN defined!
<cking> apw ^^ any ideas why?
<diwic> cking, on latest Linuxcon there was some sales keynote about powerpc switching to little endian. Might be related?
<apw> cking, waht is that building .. is that kernel or userspace bits
<cking> userspace zfs libs
<onezip> Hi everyone, quick question, how would you get the memory address of the syscall table from within a module ?
<onezip> thanks in advance
<cking> apw, i suspect something is suspect in /usr/include/endian.h
<hallyn_> drat.  dropped by to beg cking for a trusty-lts port of his zfs packages 
<hallyn_> but he no here
<apw> hallyn_, heh he is having enough trouble getting it into wily
<hallyn_> apw: :(
<hallyn_> guess i could try zfs-fuse again.  though asi recall i did have a few problems with it 2-3 years ago
#ubuntu-kernel 2015-10-17
<david__> Hello. I just filed this bug : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1507150 . Can someone look over it and let me know if I am missing any information ?
<ubot5`> Ubuntu bug 1507150 in linux (Ubuntu) "[all variants] - Radeon HD3650 - radeon.dpm=1 - ring 0 stalled for more than 10" [Undecided,New]
#ubuntu-kernel 2015-10-18
<alkisg> Hi, some other developer has previously written this little script for kernel name selection in LTSP:
<alkisg> http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/view/head:/server/share/ltsp/plugins/ltsp-build-client/Ubuntu/020-kernel-selection
<alkisg> I think it's both out of date and wrong, isn't it? E.g. is "linux-image-omap4" a valid kernel package name now?
<alkisg> Should we just default to "linux-image-generic" for all architectures?
#ubuntu-kernel 2016-10-17
<caribou> morning, is there a 'trick' in the kernel build sequence to avoid changing the ABI during the build ?
<caribou> I'm trying to only rebuilt the bzImage for a kernel bissect w/o rebuilding all the modules
<caribou> Is forcing ABINUM in debian/rules sufficient ?
<apw> caribou, what are you doing, adding a patch oro something ?
<caribou> apw: just bissecting b/w two kernel version (4.7 <-> 4.8) to identify a problematic commit
<apw> slam skipabi=true skipmodule=true (or is that skipmodules=true) on the build
<caribou> apw: ok, will try that
<robertfoss> apw: ^
<apw> robertfoss, ?  (assume i have the memory of a goldfish on Temazepam
<robertfoss> apw: you mentioned some kernel patches to get it compiling with gcc 6.2
<apw> oh that, i think i mentioned to work with pie, but i think we are using gcc5 for kernels
<mamarley> I haven't tried the regular kernel in a while, but the mainline kernels are still compiled with GCC 6.  I know the 4.4 kernel that was in Yakkety for a while was compiled with GCC 5 though.
<robertfoss> mamarley, apw: I just ran a git clone from trunk on a 16.10 box, but it does not compile due to PIE/PIC issues
<apw> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/yakkety/commit/?id=d0fb5a1973caeb761d82f5a863b139e23e7f0671
<apw> robertfoss, might be that one, that is meant to be making its way upstream from the author
<robertfoss> apw: thank you! I'll check it out
<michael-vb> Hello all.  Sorry for this hit-and-run reporting (have to move fast, but will stay logged in).
<michael-vb> I reported a couple of days ago that recent daily builds did not work in a 32-bit VirtualBox VM - the first modeset happens after grub, but the first kernel message does not.
<michael-vb> Wanted to say that 4.9.0rc1 still shows the same.
<michael-vb> (Afk, but will read the scroll-back later.)
<jacalope> Hello folks, I'm having a perpetual kernel panic after trying to return from suspend in my Samsung laptop using (K)ubuntu: http://paste.ubuntu.com/23339007/
<jacalope> 4.4.0-* kernels panic, but if I go back to 4.2.0-38-generic, I can get in.
<jacalope> The link is where I booted with a liveusb and got dmesg and dump files from var/crash -> http://paste.ubuntu.com/23339007/
<jacalope> Using 16.04
<apw> jacalope, that looks like a very unhappy wireless driver or something like that
<apw> jacalope, if you file an actual bug we can do a bisection on that maybe
<apw> jsalisbury, ^
<jacalope> apw: thanks. I'm trying to work through filing it as a bug. First time doing that, so it's a bumbling process :)
<jacalope> apw: Wait. Should I file with ubuntu/launchpad, or directly with linux/kernel?
<apw> jacalope, i'd start with us, we cna tell you to do that if we cannot help
<jsalisbury> apw, ack
<jsalisbury> jacalope, from a terminal run this: ubuntu-bug linux
<jacalope> jsalisbury: That returns a "the problem cannot be reported" dialog box from apport-- Of course I've booted using an older 4.2 kernel so its message makes sense to me. 
<jacalope> Since the 4.4 kernel panicked, do I need to file bug another way?
<jsalisbury> jacalope, you can also go directly to the launchpad web interface: 
<jsalisbury> https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<michael-vb> (Back briefly...) (18:02:37) michael-vb: Hello all.  Sorry for this hit-and-run reporting (...)
<michael-vb> Would be interested if anyone knows more about that.
<apw> michael-vb, with yakkey ?
<michael-vb> Right.
<michael-vb> 4.8.0 worked fine, everything I tried since 4.8.0-999 October 11 hung, including 4.9.0rc1.
<michael-vb> (Really have to run, will stay logged in...)
<apw> i guess i want to know what you mean by 4.8.0, is that the official yakkety kernels ?
<apw> the others you are mentioning are mainline builds, so often don't work with corner cases
<jacalope> jsalisbury: apw: I submitted a bug report regarding the kernel panic: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634214
<ubot5`> Ubuntu bug 1634214 in linux (Ubuntu) "kernel panic on resume from suspend with 4.4.0 kernels" [Undecided,New]
<jacalope> I did my best, if any more info is needed I am more than obliged to provide.
<rtg> jacalope, try 'sudo modprobe -r iwlwifi' before you close the lid.
<jacalope> rtg: will be happy to, but I can't get back into any of my 4.4 kernels at the moment
<jacalope> that removes the wireless driver before suspending, right?
<rtg> jacalope, right, looks like your wifi adapter is an older model (i2400), though I am still looking
<rtg> is this really WiMAX ?
<jacalope> It has WiMAX, yes, but I've never used that particular functionality
<rtg> jacalope, that appears to be what is crashing.  Once you can get booted into a 4.4 kernel please attach the list of modules (lsmod)
<jacalope> I've never really understood what the WiMAX is for, tbh. WiFi functionality has worked pretty well, except for the occasional > service network-manager restart trick
<rtg> jacalope, WiMAX is a different kind of wireless, but it is sort of a failed technology
<jacalope> Yeah, booting into 4.4 is the current issue. The system just hangs with the kernel panic. Is there a way around that?
<rtg> jacalope, can you boot into an older kernel ? catch the boot process at the grub prompt ?
<jacalope> Like, is there a locked file or something? Every 4.4 kernel I have is panicking, but the 4.2 lets me in. Seems odd to me since I've used 4.4 for months
<jacalope> yeah, I can get into grub and 4.2
<rtg> a 4.2 kernel should be fine for getting the modules list. you can also blacklist the i2400 driver once you've got a filesystem mounted.
<jacalope> rtg: ok, I've attached the lsmod output to the bug report.
<rtg> jacalope, ok, read up on http://askubuntu.com/questions/110341/how-to-blacklist-kernel-modules and blacklist i2400m and i2400m_usb.
<rtg> jacalope, this also has some good tricks, especially at the end using the kernel command line: https://wiki.archlinux.org/index.php/kernel_modules
<jacalope> ok, scanning now. Just to confirm, add the "blacklist xxxx" lines at the end of blacklist.conf? (There seem to be files specializing in some way, e.g. blacklist-modem.conf etc.)
<apw> jacalope, you could make a like blacklist-jackalope.conf as long as it ends .conf
<jacalope> ok, so I added my blacklist-jacalope.conf file (thanks for that btw) and rebooted into 4.2. lsmod doesn't report i2400m or i2400m_usb.
<jacalope> However, 4.4 still seems to panic, or at leas the visual results appears the same
<hans109h> can someone help explain why every 15 minutes my kernel log says kernel: [ 1682.088022]  sda:
#ubuntu-kernel 2016-10-18
<michael-vb> apw: (19:35:44) apw: i guess i want to know what you mean by 4.8.0, is that the official yakkety kernels ?
<michael-vb> (19:36:22) apw: the others you are mentioning are mainline builds, so often don't work with corner cases
<michael-vb> I was successful with both the Yakkety and the mainline 4.8.0 kernels.  For some definition of successful (I am actually trying to find out if a bug in ACPI is really fixed in 4.9 as the maintainer stated).
<michael-vb> apw: for information: I added an I/O-APIC to the VM and now I get "Failed to find cpu0 device node", then "Gave up waiting for root device[...]".
<apw> michael-vb (N,BFTL), does 4.8.1 boot, we had a problem with old configs and some of the older builds have had to be rebuilt; 4.8.1 was rebuilt yesterday so may not have, and may now boot
<caribou> Hi, if I build from git with skipabi=true skipmodule=true, can I assume that a later rebuild of bzImage only will allow me to boot a different kernel ?
<caribou> I mean, I don't want to rebuild all the modules during the bisection, only rebuild bzImage
<om26er> jsalisbury: Hi!
<om26er> jsalisbury: so there seems to be a new proposed patch, can you please build with that? (see email from the upstream kernel guys)
<om26er> jsalisbury: also are you in The Hague ?
<apw> om26er, he is not over there
<om26er> apw: ack, thanks
<jtaylor> apw: btw the dm raid fix worked and my machine hasn't exploded yet :)
<jtaylor> thx
<apw> jtaylor, awsome :)
<jsalisbury> om26er, I'll build a test kernel with the patch and post it shortly
<jsalisbury> om26er, I built a test kernel with the proposed patch from Upstream: http://kernel.ubuntu.com/~jsalisbury/lp1627108/upstream/
#ubuntu-kernel 2016-10-19
<samkottler> hi!
<samkottler> I'm running into an issue with setting net.ipv4.neigh.default.gc_thresh1/2/3 on the 3.13.0-98-generic kernel on precise where I get the follow message when running `sudo /sbin/sysctl -w net.ipv4.neigh.default.gc_thresh1=128`: error: "Invalid argument" setting key "net.ipv4.neigh.default.gc_thresh1"
<samkottler> The problem starts in the 3.13.0-97-generic kernel, 3.13.0-96-generic works fine.
<samkottler> Has anyone seen this before?
<samkottler> http://kernel.ubuntu.com/git/ubuntu/ubuntu-precise.git/commit/?h=lts-backport-trusty&id=563cf19389d8e999e69d6c94995966aeaf7c3a08 and http://kernel.ubuntu.com/git/ubuntu/ubuntu-precise.git/commit/?h=lts-backport-trusty&id=7b82096b0ebc9bf487b390fe970d66ffa5a5774e seem related.
<apw> samkottler, i have not heard reported before no.  could you file a bug with "ubuntu-bug linux" and add all that detail
<apw> samkottler, and let us know here the bug number
<michael-vb> apw: I talked to you a couple of days ago about problems running current mainline kernels in a virtual machine.  I just took a boot log over a serial console.  Lots of symbol version disagreements, mainly for mcount.
<michael-vb> http://paste.debian.net/883626/
<om26er> jsalisbury: Hey! that fixes the bug
<michael-vb> Repaste: (11:51:32) michael-vb: apw: I talked to you a couple of days ago about problems running current mainline kernels in a virtual machine.  I just took a boot log over a serial console.  Lots of symbol version disagreements, mainly for mcount.
<michael-vb> (11:51:39) michael-vb: http://paste.debian.net/883626/
<michael-vb> And update: still affects the current daily.
<samkottler> apw: done! https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1634892
<ubot5`> Ubuntu bug 1634892 in linux-lts-trusty (Ubuntu) "Setting net.ipv4.neigh.default.gc_thresh1/2/3 on 3.13.0-97.144 or later causes 'invalid argument' error" [Undecided,New]
<apw> samkottler, ta
<michael-vb> apw: quick ping again.  "No time just now" is fine too though.
<apw> michael-vb, i did look over it, that looks a lot like a missmatched initrd and kernel
<michael-vb> apw: does that mean user error or package error?
<apw> michael-vb, not 100% sure, i've not had any time to try that speciifc kernel on a vm here yet
<apw> we are rather slammed doing z-opening
<michael-vb> Had to think for a minute before I got that one...
<michael-vb> Any ideas in the mean-time?  Or just build my own kernel?
<michael-vb> apw: the mainline kernels are without any Ubuntu patches, aren't they?  I just reproduced a problem with mainline 4.8.0 that we saw with the Yakkety live kernel.  That means that it is probably nothing to do with you, doesn't it?
<om26er> jsalisbury: ping
<jsalisbury> om26er, hey
<om26er> jsalisbury: the last kernel fixes the issue
<om26er> time to release the patch :D
<jsalisbury> om26er, that is good news.  Do you want to let upstream know, or do you want me to?
<om26er> jsalisbury: I can do that, but if you do it, that would be better,.
<jsalisbury> om26er, Ok, I'll reply and see if this will be the final version of the patch.
#ubuntu-kernel 2016-10-20
<xnox> i wonder if i can run LTS kernel on yakkety, such that i get CLS for my laptop
<smb> xnox, you surely can run then 18.04 kernel ... at some point
<xnox> hm. i'm wondering why we don't keep lts ga kernel in yakkety. Or like forward copy it.
<xnox> i should be able to pin to xenial kernel package i think. things should generally work.
<smb> xnox, its just that I wonder why you want that
<smb> (and don't assume I have any idea at this time of day about what this CLS ramblings are)
<xnox> live patchign
<xnox> because it is stated that live patches are not currently built/released for yakkety kernel
<smb> xnox, so what? its not like you could not reboot your laptop :-P
<caribou> guys, I must be missing something obvious with my kernel rebuilds:
<caribou> even when building the generic package with skipabi=true skipmodule=true, I'm not able to reboot with a rebuilt bzImage 
<caribou> it just doesn't find the root device upon reboot
<caribou> FYI I'm working on a bisect & don't want to have to rebuild all modules each & everytime
<caribou> apw: smb: any thought ? ^^^
<caribou> if you're not too busy of course :)
<smb> caribou, hm... frankly for bisecting I usually (most of the time its on mainline trees anyhow) copy a /boot/config-... into .config and run "make -j32 deb-pkg INSTALL_MOD_STRIP=1"
<smb> There is some auto incrementing version of the packages that way, too
<caribou> smb: which Mainline tree did you use ? kernel.org one ? last time I tried, it complained that it could no find debian/control
<smb> Just one needs to be careful what number is used with the latest build (they might jump back and forth)
<caribou> smb: I would prefer to use the mainline as I can't use non-linear tags for the bisect
<caribou> smb: let me try your command again
<smb> caribou, yes the kernel.org one
<smb> caribou, note its is just plain make and not dpkg-buildpackage or so
<boulabiar> Hi, how to bug report the new kernel livepatch ?
<boulabiar> after installing, my laptop can't sleep anymore
<boulabiar> ubuntu-bug canonical-livepatch don't work, because the package is installed via snap
<henrix> boulabiar: i guess you'll need to use https://bugs.launchpad.net/ubuntu/+source/canonical-livepatch/+filebug
<boulabiar> henrix: something went wrong with the page you asked my to use
<boulabiar> I've written a full paragraph, then when i clicked send, an error appeared, I repeated this 2 times...
<henrix> boulabiar: ah, so launchpad is probably in one of those days
<ogra_> apw, did you forget to binary-new the linux-raspi2 package in xenoal-security/-updates ?
<ogra_> (seems the images that QA tries to test here at the sprint all ended up with 4.4.0.1029.29)
<smb> ogra_, the version number sounds like the one I would expect
<ogra_> smb, 
<ogra_>  linux-raspi2 | 4.4.0-1029.36 | xenial-security/universe  | source
<ogra_> vs
<ogra_>  linux-raspi2 | 4.4.0.1029.29 | xenial-security/universe  | armhf
<ogra_> brad is on it though, i pinged him in person
<apw> ogra_, what is wrong with those versions ?
<apw> remember one is source and the other is a binary from a _different_ source
<ogra_> apw, we need 4.4.0-1029.36 in the archive as binaries
<ogra_> ogra@anubis:~/datengrab/images/snappy$ rmadison -s xenial-updates,xenial-security linux-raspi2
<ogra_>  linux-raspi2 | 4.4.0-1029.36 | xenial-updates/universe  | source
<ogra_>  linux-raspi2 | 4.4.0-1029.36 | xenial-security/universe | source
<ogra_>  linux-raspi2 | 4.4.0.1029.29 | xenial-updates/universe  | armhf
<ogra_>  linux-raspi2 | 4.4.0.1029.29 | xenial-security/universe | armhf
<ogra_> there is no armhf binary for 4.4.0-1029.36 anywhere 
<apw> ogra_, the binary is _not_ called linux-raspi2 ?
<apw> you are asking rmadison for binaries only called linux-raspi2
<ogra_> oh man 
<apw> try -S
<ogra_> indeed you are right, thoughh why do we only get .29 in the snaps then
<ogra_> https://launchpadlibrarian.net/290161189/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
<ogra_> thats a build log from 2h ago 
<apw> ogra_, the linux-raspi2 package is from linux-meta-raspi2 and that is the ight number for that
<ogra_> Get:5 http://ftpmaster.internal/ubuntu xenial-security/universe armhf linux-image-raspi2 armhf 4.4.0.1029.29 [2324 B]
<apw> you should have linux-raspi2 at 4.4.0.1029.29 (note no - in the version)
<apw> and linux-image-4.4.0-1029 at 4.4.0-1029.36 which is from linux-raspi2
<ogra_> hmm
<ogra_> Get:2 http://ftpmaster.internal/ubuntu xenial-security/universe armhf linux-image-4.4.0-1029-raspi2 armhf 4.4.0-1029.36 [35.3 MB]
<ogra_> there is actually is
<apw> right, so that is exactly as expected
<ogra_> then i dont get whyy all the bugs are still there :(((
<apw> ogra_, which bugs, ones which are fixed in the -proposed kernel ?
<smb> ogra_, because it only fixes security
<smb> ?
<ogra_> (teh kernel i tested from proposed yesterday was not oopsing on boot ... the QA team now tests it and has unbootable imges again)
<apw> ogra_, they are not in that kernel it was an embargoed security fix
<ogra_> err
<apw> ogra_, that is exactly expected
<ogra_> so you didnt base on that one ? 
<apw> that is _how_ embargoed cves work
<ogra_> damn 
<ogra_> well, we need the one from proposed today 
<apw> no we would never do that, it was an untested CVE CRD release
<apw> ogra_, that is gone
<ogra_> so is there any way to get the fixes in today (we tested the hell out of the proposed kernel yesterday to make sure it can land asap)
<apw> ogra_, that doesn't have the aa fix bear in mind
<ogra_> it is essential for the snappy RC image that we need to release this week
<ogra_> (and what you have in the archive is unbootable anyway on pi3 currently)
<apw> ogra_, i might be able to resurect the previous version but that won't have the aa fix which we respan for
<sbeattie> ogra_: jjohansen may have a kernel you can use which was based on the -proposed kernel with the raspi2 fixes + the needed apparmor fix.
<ogra_> sbeattie, for the archive ? 
<sbeattie> in a ppa
<apw> oh yeah thats right, we could do that because there was jj's kernel in a ppa
<jjohansen> ogra_: so based on kernel that was in updates yesterday + the apparmor fix
<jjohansen> https://launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-devel
<apw> ogra_, anyhow, i'll see where we are with the respins
<sbeattie> s/updates/proposed/
<ogra_> can we somehow fast-path that in ? (i have the QA team here and i can spin snaps for them from the PPA to get everything tested)
<jjohansen> sbeattie, orgra: so again this is not based on -proposed but on -updates from yesterday
<jjohansen> the xenial -proposed kernel has the apparmor backport from yakkety on it
<sbeattie> jjohansen: oh, updates?
<jjohansen> yeah -updates from yesterday
<ogra_> jjohansen, well, we have a kernel that oopses on boot, that was the released kernel and the one formerly in updates ... 
<ogra_> the only kernel that boots is the one that was in -proposed yesterday 
<apw> ogra_, cna you remember the version number ?
<ogra_> i can dig it up, i have a test image but that needs some time since i need to set up gear to boot it to run uname 
<apw> ogra_, can you build images/snaps whatever against a PPA
<apw> if not then it is no point in me trying to find it
<ogra_> apw, ppisati said it should just be  >= 4.4.0-1028.34  but thats obviously not true when the former proposed kernel wasnt even used
<apw> what should be ?
<jjohansen> ogra_: so xenial -proposed should not be vulnerable to the aa bug, the yakkety version of apparmor had refactored that code and due to that had the fix in it already
<ogra_> apw, the one with all the fixes :)
<apw> i need a specific exact version as i have to reach blind into the archive
<ogra_> yes, i know 
<jjohansen> the ppa has the -updates kernel with the apparmor fix based on the assumption you would a released kernel
<ogra_> as i said, that requires some work
<ogra_> jjohansen, right, but -updates is a step back and wont boot without some bootloader hackery first 
<ogra_> apw, i'll ping you as soon as i can give you the version
<jjohansen> ogra_: got it, so I just want to confirm for you from an apparmor pov the ppa kernel based on yesterdays -updates and the xenial -proposed kernel should be functionally equiv. ie not have the bug
<apw> ogra_, oh, a thought, isn't the download of the package from -proposed in the logs of the image build which was good; rather than booting it
<ogra_> apw, \o/ ... sorry it took so long, found the package version in a build log 
<ogra_> Get:5 http://ftpmaster.internal/ubuntu xenial-proposed/universe armhf linux-image-raspi2 armhf 4.4.0.1028.28 [2324 B]
<ogra_> and
<ogra_> Get:1 http://ftpmaster.internal/ubuntu xenial-proposed/universe armhf linux-image-4.4.0-1028-raspi2 armhf 4.4.0-1028.34 [35.4 MB]
<ogra_> does that help ?
<apw> ogra_, yes that helps, thanks.
<yoasif> hi, is there any documentation or way of getting the "extras" package for mainline kernel builds?
<tjaalton> i'm hit by https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1635115
<ubot5`> Ubuntu bug 1635115 in grub2 (Ubuntu) "grub fails zfs root filesystem detection due to failed checksum" [Undecided,Confirmed]
<tjaalton> my home server fails to boot after latest updates to xenial
<tjaalton> oh well, no time to fix it now..
<mamarley> Ooh, that should be probably be marked Critical.
<apw> i am not sure zfs is support as root/boot is it?
<tjaalton> not in the installer, but i see no reason to make it harder
#ubuntu-kernel 2016-10-21
<maccam94> is there a build for the linux-generic-lts-utopic kernel with the DIRTY COW patch?
#ubuntu-kernel 2016-10-22
<apw> maccam94 (N,BFTL), that kernel is now off general support, you should upgrade to the latest lts kernel to get security updates
<uebera||> Hi. Anyone using canonical-livepatch? Given that there was a recommended/automatic kernel update (-> 4.4.0-45 or higher for Xenial), I would have expected that the status message for the then-active 4.4.0-40 kernel would have included a notification by now (1.5 days later)... Is there a recommended place where one can discuss canonical-livepatch behaviour?
<apw> uebera||, here is probabally a reasonable place currently, i am not sure if any of the engineers with that knowledge are arround right now
<apw> uebera||, oh 4.4.0-40 was never released so it likely does not have livepatches
<uebera||> apw: This would actually be another warning I'd expect from the output of "canonical-livepatch status --verbose"
<apw> uebera||, that does not seem unreasonable ...
#ubuntu-kernel 2016-10-23
<tmus> I'm intermittently seeing "Buffer I/O error on device nvme0n1p2, logical block xxxxx" in dmesg, followed up by system meltdown (no access to storage at all). This is a Samsung NVMe device in a new Skylake Thinkpad. Poweroff/Poweroff brings the system back until the next time, which could be days or just minutes. Linux 4.9-rc1 (Ubuntu mainline packages) but seen on the normal Ubuntu 16.10 kernels as well.
<tmus> Known issue?
<apw> tmus, not know to my knowledge
<tmus> apw, thanks - i'll dig a little further before logging a bug
#ubuntu-kernel 2017-10-16
<tseliot> apw: hey, can you approve nvidia-graphics-driver-384, please? It includes the changes you suggested, and one more fix
<apw> hmmm, not me apparently
<apw> tseliot, i meant, i could but it already got accepted
<apw> the queue was emptry when i got there
<tseliot> oh it was
#ubuntu-kernel 2017-10-17
<metaphysician> Is this error a cause for worry? https://paste.debian.net/plainh/67a457bb What does it mean?
<apw> metaphysician, as both are Corrected i doubt it
<apw> if you start getting a whole lot of 'em more so
<metaphysician> apw: just these two errors per boot.
<apw> if they are consistent on boot even less so for me
<apw> likely somethign settling and scaling back
<mamarley> soee: Have you tried out the 4.14-rc mainline kernels yet?  I decided to try out -rc5 but for me AppArmor seems to be denying everything and I was wondering if you had the same issue.
<soee> mamarley: no since rc3 i think as it failed with nvidia drivers
<ricotz> mamarley, better use the ppa builds instead of mainline builds
<mamarley> ricotz: Which PPA is that?
<ricotz> mamarley, https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable
<mamarley> Ah, I didn't know about that one.  Thanks!
<mamarley> As I suspected, the same thing happens with that kernel too.  I suspect this is an upstream bug then.
#ubuntu-kernel 2017-10-18
<hallyn> hm, having a weird corruption issue on 4.13 kernel on artful.  Create an empty file (truncate -s 30G), qemu-nbd attach it, create pv/vg/lv and thinpool-provision;  setup a slew of filesystems;  umount, disconnect, and ...   corruption
<hallyn> serge@lxd1:~/sandbox$ sudo qemu-nbd -f raw -c /dev/nbd0 /var/lib/lxd/disks/disk2.img
<hallyn> Failed to set NBD socket
<hallyn> Disconnect client, due to: End of file
<hallyn> ohei.  nbd1 doesn't complain though.  
<hallyn> (on zesty this all worked fine, exact same recipe, worked many times on zesty, failed 3x on artful)
<hallyn> ok so let's try a reboot - though that didn't work last night, but there could always be >1 issues
<cpaelzer> hi hallyn: you point to 4.13 - did you already have a chance to run the same with the zesty kernel but the artful lvm/nbd tools?
<hallyn> cpaelzer: no, i haven't.  i was kind of constrained in where i coudl run for the results i wanted, but i guess for reproducing this i can be anywhere.
<hallyn> well this is frustrating :)
<cpaelzer> hallyn: still corrupted?
<cpaelzer> hallyn: do you have your "reate pv/vg/lv and thinpool-provision;  setup a slew of filesystems" in a way you could share it to cross check over here?
<hallyn> cpaelzer: yeah, mostly - it's kindof a general tool so there's extra cruft, but it's mainly using https://github.com/atom-deps/lpack/blob/master/setup_lvm.sh  and https://github.com/atom-deps/lpack/blob/master/lpack_unpack.sh
<hallyn> TBh kernel commit 7a362ea96d0df873397be04f4556e92f7e37c5ec looks suspect: "nbd: clear disconnected on reconnect"
<hallyn> All right let me (1) setup a zesty vm and reproduce there, (2) do-release-upgrade -d there but not reboot, then finally reboot into artful kernel;  and see which of those three work
<hallyn> but imma do that at the coffee shop, back in a afew
<cpaelzer> I tried with losetup but things worked for me (slightly reduced e.g. no snapshotting)
<cpaelzer> interested what you'll see in your test in the zesty vm
<hallyn> note this is using nbd not losetup
<hallyn> lol maybe https://lkml.org/lkml/2017/7/21/294
<hallyn> cpaelzer: weeeeeel crap.  cannot reproduce on vm on my own host.
<hallyn> oh, well, maybe it's a race.  now it's acting funky.
#ubuntu-kernel 2017-10-19
<slangasek> jsalisbury: is this bug something that you're seeing crop up in Ubuntu 17.10? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1724911
<ubot5> Ubuntu bug 1724911 in linux (Ubuntu) "text VTs are unavailable on desktop after upgrade to Ubuntu 17.10" [Undecided,New]
<apw> slangasek, have you tried booting without vt.handoff set ?
<slangasek> apw: I have tried nothing beyond what I've reported in the bug so far :)
<slangasek> apw: I mentioned vt.handoff because that was one of the things I suspect and I will try to debug :)
<apw> slangasek, i will note i just switched to vt3 and have a getty on there on my intel based latop
<apw> x250
<slangasek> apw: docked? vt.handoff y/n?
<apw> and it is interactible
<apw> not docked right now, though i have been, and with vt.handoff set
<slangasek> k
<apw> i will check next time i am docked to see if it differs then
<apw> would you have booted docked ?
<slangasek> apw: yes
<apw> likely i booted undocked, and docked later, anyhow, will look to see what happens to the vts when i dock next
<apw> which i will try to do after food
<apw> slangasek, though if gdm is on vt1 it is not entirely obvious we should be handing off to vt7
<slangasek> apw: yes, and I'm trying to decide whether that is reasonable and safe to change in SRU
<slangasek> if vt.handoff is the culprit for my current problem, that certainly tilts the needle
<slangasek> apw: problem reproducible with vt.handoff disabled.
<apw> slangasek, if it is not an urgent fix for anything we should change it in bertie basset
<apw> and evaluate it there, will add it to my BB board to remind self
<slangasek> yep
<apw> slangasek, i've just slammed this into mu dock and i have VTs on both screens
#ubuntu-kernel 2017-10-20
<apw> slangasek, ok and this morning i have slammed it in, and have no VT3 content
<apw> slangasek, so definatly not consistent
<LocutusOfBorg> so, folks any news about the new VBOX kernel implementation?
<LocutusOfBorg> sforshee, ^^
<LocutusOfBorg> I'm going to upload virtualbox 5.2 soon(TM)
<LocutusOfBorg> that should have something similar to the kernel driver
<apw> LocutusOfBorg, nothing from me on that, though i will say i think i have managed to make your "lower the kernel module version" suggestion work to unbreak the DKMS tests and allow them to be separated
<sforshee> LocutusOfBorg: I've applied the fix and turned the option back on in our 4.14 kernel, I haven't heard any compelling reason that we need to turn it back on in 4.13
<sforshee> still haven't done any work on sorting out having multiple vboxvideo module though
<LocutusOfBorg> I don't want it for 4.13 :) 4.14 is fine
<LocutusOfBorg> I'm talking about 18.04
<sforshee> yeah we'll have it enabled there, as long as it is working ;-)
<sforshee> LocutusOfBorg: will 4.2 support 4.14?
<sforshee> *5.2
<LocutusOfBorg> sforshee, https://www.virtualbox.org/pipermail/vbox-dev/2017-October/014836.html
<LocutusOfBorg> probably some fix is successive 
<sforshee> cool, thx
<LocutusOfBorg>     Update: The Guest Additions image with the 5.2.0 release fails to work with recent Linux guest kernels. Please try this image which we believe fixes the problem. For experimental Linux 4.14 support, please try this image. Both should work on all older guest systems too: please file a report on the bugtracker if they do not.
<LocutusOfBorg> seems not
<LocutusOfBorg> sforshee, https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=731d628393426d91ac8e901b0ef76dc6571f2930
<sforshee> LocutusOfBorg: awesome, thanks!
<LocutusOfBorg> e6742e1021a5cec55fab50a0b115c65217488eda <-- do you have it?
<LocutusOfBorg> also 25ff38ca79a9336ea34cc0d0b0b0b39ad7836d28
<LocutusOfBorg> they seems to come from the kernel, so I suppose your kernel module if you have an up-to-date master branch, will be working better than the vbox one :)
<sforshee> LocutusOfBorg: both were in 4.14-rc1, our unstable tree is currently at -rc5 so yes we have them
<LocutusOfBorg> wonderful
<slangasek> apw: how do you think we should approach pinning this down?  Should I start with a kernel bisect, or is there useful dmesg output I should pull in?
<apw> slangasek, gawd i am not sure, a grose bisect with 4.11 4.12 maybe helpful to start with, sigh
<slangasek> alright
<slangasek> I figured I'd start with "find me the first 4.13 kernel from the artful devel series and see what happens"
<apw> slangasek, yeah, not really sure what the trigger here is, i can see i stil do not have vts having undocked
<apw> slangasek, not sure if it was the s/r which broke it
<slangasek> right, undocking never got me my vts back
<slangasek> bdmurray: ^^ since you have the same bug
<apw> slangasek, now is it docking which breaks it, or s/r which breaks it, or
<apw> as i had it docked with vts, i suspct it is not the dock
<slangasek> s/r ?
<apw> suspend/resume, that is the other thing that occured for sure since i docked and undocked with vts
<slangasek> for me, the problem happens when the kernel driver has two displays when it first inits
<slangasek> so a s/r cycle might be the same
<apw> i didn't s/r with two displays though
<slangasek> ok
<slangasek> conclusion: shit is broken
<apw> i had vts, docked, had vts, undocked, had vts, resumed, docked, checked and did not have vts
<apw> so, i don't know if i had them between resume and docked, sadly
<bdmurray> it happens for me on first boot too
<slangasek> jsalisbury: wrt LP: #1724911, you ask for a mainline 4.14 kernel test, but I would not be quick to rule out this being a sauce-related bug; can I get a mainline kernel build somewhere that corresponds to 4.13.0-16-generic for testing?
<ubot5> Launchpad bug 1724911 in linux (Ubuntu) "text VTs are unavailable on desktop after upgrade to Ubuntu 17.10" [High,Confirmed] https://launchpad.net/bugs/1724911
<apw> slangasek, that is based on 4.13.4 ... (see /proc/version_signature)
<slangasek> ok
<apw> slangasek, so in theory the mainline equivalent is http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.4/
<apw> which did at least build
<jsalisbury> slangasek, thanks for trying mainline, it would be just a good data point.
<TJ-> Heads-up for the nvidia driver packages failing to build. In v4.14 AMD has introduced Secure Memory Encryption (SME) and, in the mainline builds at least, it is enabled by default. CONFIG_ARCH_HAS_MEM_ENCRYPT and CONFIG_AMD_MEM_ENCRYPT. The GPL-only symbol sme_me_mask causes the nvidia drivers to fail to build. I reported this upstream. Thomas Gleixner replied to the thread saying this symbol will not
<TJ-> have it's GPL tag removed. The only option is to set CONFIG_AMD_MEM_ENCRYPT=n but obviously that means the AMD devices (where this SME is introduced) cannot use it. or Ubuntu kernel builds that have to be hardware-agnostic this isn't a solution. So, we could be heading for a problem for the DKMS builds of nvidia (and other) out-of-tree drivers.
<apw> TJ-, happens every now and again, and something gets fixed
<slangasek> jsalisbury, apw, bdmurray: ok good news, LP: #1724911 is fixed upstream in 4.14rc5.  Which kernel should I test next?
<ubot5> Launchpad bug 1724911 in linux (Ubuntu) "text VTs are unavailable on desktop after upgrade to Ubuntu 17.10" [High,Confirmed] https://launchpad.net/bugs/1724911
<apw> slangasek: awesome
<apw> slangasek: I assume rc4 was bad, so a jsalisbury bisect between sounds good
<slangasek> also, I get apparmor denials on dhclient with 4.14rc5.
<slangasek> apw: I didn't test with rc4, is that the next one I should do?
<slangasek> should I report those apparmor denials somewhere?
<slangasek> (should something have rebuilt apparmor caches for the new kernel version?)
<slangasek> quite a lot of denials actually
<slangasek> but only dhclient matters to me ;)
<apw> slangasek: well there is likely different apparmor in mainline
<slangasek> apw: 4.13 mainline didn't give me these denials, I was able to get online
<slangasek> 4.14, I had to debug
<mamarley> slangasek: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1721278
<ubot5> Ubuntu bug 1721278 in apparmor (Ubuntu Artful) "apparmor="DENIED" operation="create" profile="/usr/sbin/cups-browsed" w/ 4.14-rc2 and later" [Undecided,Confirmed]
<slangasek> yep, that looks like the one
<apw> slangasek: something between 4.13 and 4.14rc5
<apw> to narrow the window
<slangasek> wk
<slangasek> k
<apw> though rc4 is more likely to work than rc3 etc
<apw> work in general
<slangasek> yeah but bisect log 2 etc etc
<slangasek> I'll go straight to rc1 :)
<slangasek> jsalisbury: can you help me out with bisect builds for LP: #1724911?  I think I've done all the testing that can be done against http://kernel.ubuntu.com/~kernel-ppa/mainline/
<ubot5> Launchpad bug 1724911 in linux (Ubuntu) "text VTs are unavailable on desktop after upgrade to Ubuntu 17.10" [High,Confirmed] https://launchpad.net/bugs/1724911
<jsalisbury> slangasek, sure thing.  I'll review what kernels you've tested so far, and post the next one to test in the bug.
<jsalisbury> slangasek, I updated the bug.  
<jsalisbury> We can't bisect between 4.13.8 and 4.14-rc1 because they are not linear versions. The bug could have been introduced by a 4.13 stable update.
<jsalisbury> slangasek, It would be great if you can confirm 4.13 final also has the bug.  I'll asume it does and start a bisect between 3.13 final and 4.14-rc1.
<jsalisbury> I'll post a link to that test kernel in the bug when it's done building.
<slangasek> jsalisbury: ok, thanks
#ubuntu-kernel 2017-10-21
<TJ-> Has CONFIG_SECURITY_APPARMOR_UNCONFINED_INIT=y functionality been folded into the Artful 4.13 kernels?
