#ubuntu-kernel 2006-02-06
<zul> BenC: new crack for you
<BenC> ok
<zul> compiled tested and running it right now..
<zul> rt8180 is not in there yet though
<lamont> BenC: could I talk you into adding ns87415.ko to the ide-modules udeb on hppa with the next upload?
* lamont makes a note to get git setup on his work machine tomorrow, since it has the bandwidth to withstand git
<zul> later..
<pdr> just a quick question, is it intended to have 2.6.16 on dapper?
<lamont> pdr: upstream version freeze already happened.  I would doubt that 2.6.16 would hit dapper, unless something was very very very broken in 2.6.15
<lamont> and even then, probably not.
<crimsun> pdr: no, 2.6.15.x
<pdr> lamont, crimsun: thanks
<mjg59> BenC: I've just sent you a patch that updates the sdhci driver
<mjg59> It seems pretty stable here now
<sn9> BenC: awake?
<sn9> i finally rebooted for the first time since the -14 install
<sn9> i cannot get it to detect the tumbler's presence
<sn9> downloaded snd-powermac-[12] .ko
<sn9> -1 doesn't work either; -2 does
<sn9> sound is muted on wake from sleep
<sn9> any idea for a workaround?
<BenC> awake
<BenC> sn9: not sure about that sound issue
<zul> heylo
<zul> hmm....thats cool the rt8190 doesnt have sysfs support..
<zul> more hacking for me
<lamont-work>   git-core: Depends: libcurl3-gnutls (>= 7.15.0-1) but it is not going to be installed
<lamont-work> sigh
<lamont-work> git 4.3.20-7build1 - is that new enough?
<lamont-work> prolly not
* lamont-work backports the current dapper git-core to breezy
* lamont-work decides that backporting libcurl3-gnutls-dev is more work than he feels like atm
<zul> heh...i built from source
<lamont-work> zul: well, that is the alternative - new machine, etc.
<lamont-work> I tend to prefer packed .debs, just because I'm lazy
<lamont-work> zul: hey, speaking of lazy..  you wanna apply a diff for me?
<lamont-work> debian/d-i/hppa/modules/hppa/ide-modules needs to have ns87415 added to it
<lamont-work> hrm.. actually, maybe I'll use this as an excuse to actually learn git enough to be useful.
* lamont-work freshens his git tree at home
<lamont-work> "can I swap to a ramdisk?"
* cjb``` is considering one of:  http://www.techreport.com/reviews/2006q1/gigabyte-iram/index.x?pg=1
<zul> sorry lamont-work was at lunch
<lamont-work> np - still  watching the home machine catch up on way too many git patches
<lamont-work> up to 33/ now.
<zul> cool..
<lamont-work> does it count clear to ff/?
<zul> yep
* lamont-work needs --bwlimit= in git pull
<zul> hehe
<lamont-work> iz gonna hurt my bw bill
<lamont-work> esp since the next git-push is gonna do the same thing, no?
<lamont-work> or can I just hop onto rookery and get pull there?
<zul> i think you can hop onto rookery not sure though...bw is not really a problem for me
<BenC> lamont: only the first pull is big
<lamont-work> BenC: not when you last pulled right after BenC set up git...
<BenC> heh, pull more regularly :)
<BenC> you can always setup a git-fetch in cron
<BenC> then you can git-pull from the fetch branch and it's all local (and the git-fetch can be cron'd because it doesn't require merging)
<lamont-work> BenC: I sent you mail (which you can disregard), but wondered if my rookery git-tree was in the automerger...
<BenC> not yet
<BenC> actually, I don't automerge anyone
<zul> BenC: question for you did you have a look at my stuff yet?
<lamont-work> ah, ok.  well then.. in that case... pls apply the patch I sent you in the first place. :-)
<BenC> my message on wiki was just to make people be careful :)
<BenC> zul: not yet, I have a butt load of stuff from mjg and others I am working on now, I plan to pull from you tonight
<BenC> lamont: ok :)
<zul> BenC: ok
<lamont-work> and then I'll find something benign to tweak and see if I can drive git without hitting any cliffs.
<zul> wheeee...cliffs!!
<lamont-work> woot.  over half way. (8c)
<zul> freaking open office export the date properly!!!
<cjb> lamont-work: BTW, I use trickle http://www.monkey.org/~marius/trickle/ to rate-limit things like apt-get.  It's very simple.
<cjb> (It overloads read(2) with LD_PRELOAD and adds usleeps until you're at the rate you want.)
<lamont-work> cjb: thanks
<lamont-work> Filename: pool/universe/t/trickle/trickle_1.06-4_i386.deb
<cjb> trickle -d40 git-fetch .. should be enough to limit to 40KB/s download.
<lamont-work> BenC: if I set up a git-fetch cron, does the cronjob have to finish before I can merge from the tree, or is it consistant and/or locking as needed?
<lamont-work> maybe that's not clear. :(
<BenC> I think you can git-pull while a fetch is going
<BenC> should be atomic
<lamont-work> fb!  woot
<lamont-work> BenC: nice. thanks
<lamont-work> I assume the git-fetch cron thingy is in a faq somewhere
<lamont-work> hrmpf.
<lamont-work> 2nd rsync started now.  wonder how many of those there are.
<zul> lamont-work: finished yet?
<lamont-work> still pulling pack/pack-0741dd55e7c560f401c7f37120f3203ad8664bb0.pack
<zul> well its almost done then
<lamont-work> which is good, since it's put me over quota for tomorrow, too.
<zul> ouch..
<lamont-work> well, if I do nothing more until then end of tomorrow, I'll be back under quota.
<lamont-work> there.. that's more accurate
<zul> what if you over quota for something like for a week worth of data
<lamont-work> the start of the month can be like that... no time to build up extra quota-headroom
<lamont-work> it doesn't help that I wind up ctl-z ing it anytime I need interactive response in mutt on the machine at home...
<lamont-work> since it is maxing out the bandwidth across the hilltop (~170kbps)
<zul> does it cut you off for a week or do end up paying more?
<lamont-work> hrm... there's a 209kbps block in there
<zul> or it just throttles you?
<lamont-work> if I get to the end of the month, having used more than quota (with the prior month's headroom available), then I pay more
<zul> ah ok
<lamont-work> I think I had something over 300MB of headroom at the end of jan, so I get 3.5GB this month, if I must.
<lamont-work> and time < 56kbps doesn't count (5 minute blocks of time, looking at agregate use)
<zul> nifty...sounds communistic ;)
<lamont-work> the free-under-56k was added specifically for me...
<lamont-work> I usually come in at somewhere around 10-14GB total use for the month
<zul> oi..i dont think i use that much....i probably do though
<lamont-work> just put an iptables rule on input and ouput: "iptables -A INPUT; iptables -A OUTPUT" and see what the accounting has to say...
<lamont-work> well, "-I INPUT 1" if you have rules already
<cjb> Huh, wow.  Where do you live such that this is necessary, lamont?
<zul> mongolia ;)
<lamont-work> cjb: 802.11b co-op in rural colorado
<cjb> Awesome.
<lamont-work> I'm arguably on the border of DSL availability, as I keep reminding the phone company...
<lamont-work> but in the meantime, my internet connectivity is via an 802.11b link (1W ERP) to a hilltop 18 miles away
<zul> hehe
<lamont-work> it generally stays up, although bad weather at the hilltop desenses the receiver, and life sucks
<zul> its like two cans and a string interfnet
<lamont-work> it beats the hell out of dialup
<zul> true..
<lamont-work> still debating the relative merits of sucky-latency bouncing off the geo-sync satellite.
<zul> i havent had dial-up in like 6 years...except for the year i wasnt working
<lamont-work> dialup is what they offer here.
<lamont-work> well, I suppose isdn might be available too.
<lamont-work> I had that once
<lamont-work> cjb: www.cwx.net
<cjb> Yeah, been six years since dialup for me too.
<lamont-work> the cool part about a 3.2GB quota is that it's ~100MB/day, so you can just leave a window open with the total bw usage for the month (thank you iptables, cron and python) and easily read where you are at.
<lamont-work> 20060201.1250: 2257587:  67727
<lamont-work>                          26170
<lamont-work> 20060201.1300: 4400102: 132003
<lamont-work> 20060201.1305: 6435003: 193050
<lamont-work> 20060201.1310: 6889995: 206699
<lamont-work> total: 190,596,891
<lamont-work> hrm.. looks better in a non-proportional font
<lamont-work> that's time-at-end-of-5-min-block: bytes: bits-per-sec
<lamont-work> what it really means is that I run a local mirror, and sync it with a bw-limited script that makes sure that the archive, while possibly stale, always has a consistant set of packages/sources/release files
<lamont-work> thereby timeshifting the whole thing
<lamont-work> and then, when I'm tracking dapper, I suppliment that with sneaker-net bandwidth
<cjb> You'd think working with bandwidth-intense trees and needing to track a whole operating system would be incompatible with having a crappy net connection.  :)
<lamont-work> cjb: hence the sneaker-net bandwidth suplementation
<lamont-work> the part I haven't mentioned yet is that the home mirror took a crap last night (hard drive died), so I'm using a USB drive as a high-latency, high-bandwidth network connection to pull a copy of the site's mirror for the house.
<lamont-work> I really need to dust off my archive code and get back to just mirroring the packages I want, instead of everything
<lamont-work> cjb: also, that's why I was dealing with getting git on the work machine. or rather, thinking about it
<cjb> Ah, the "Never underestimate the bandwidth of a station wagon full of backup tapes." approach.
<lamont-work> exactluy
<lamont-work> 1ea 120GB packet.
<lamont-work> cjb: and for the correct quote, I believe it's: s/backup tapes/mag tapes, hurtling down the highway."
<lamont-work> wth is in that .pack file?
<lamont-work> which is over 100MB
<lamont-work> and the one from nov 24 is 96MB. ouch
<lamont-work> finished.  finally.
<lamont-work> 108MB
#ubuntu-kernel 2006-02-07
<BenC> mjg59: uuuugly, but rtl818[x7]  is in the tree
<BenC> and after some extra massaging, it's compiling aswell
<BenC> lamont-work: that's every bit of revision history since the kernel went into git
<BenC> plus all of ubuntu's history
<BenC> lamont: rsync is really crappy for git, no wonder it sucked
<BenC> you should use ssh to rookery
<mjg59> BenC: Thanks! Now we just need ACPI crack :)
<sn9> the most addictive kind ;-)
<JaneW> BenC: PING PING - meeting time
<fabbione> bubbalwz: wake up punk!
<fabbione> BenC: ping?
<BenC> fabbione: pong
<fabbione> hey dude...
<fabbione> i have a fix for the synaptic touchpad on PB
<fabbione> i am uploading a package for you to test
<fabbione> it almost works here
<fabbione> meaning that horiz is ok
<fabbione> vertical is still a bit slow
<fabbione> (assuming that you are using the default X config without touching synaptic stuff)
<fabbione> http://people.ubuntu.com/~fabbione/xserver-xorg-input-synaptics_0.14.3+seriouslythistime-0ubuntu3_powerpc.deb
<fabbione> try this
<fabbione> restart X 
<fabbione> and let me know :)
<BenC> ok, I'll give it a try here shortly
<fabbione> thanks
<zul> heylo
<zul> hey fabbione 
<fabbione> hey zul
<zul> how is the sprint coming?
<fabbione> it could go better
<fabbione> we all been feeling sick in the last 2 days
<zul> how come?
<fabbione> either a virus or somekind of food poisoning
<zul> oh that sucks
<BenC> mjg59: ping
<fabbione> BenC: he is talking with infinity 
<BenC> let him know that his acpi patches are in git :)
<mjg59> BenC: Hi
<mjg59> BenC: Thanks!
<BenC> mjg59: there was one conflict
<BenC> well, a couple caused by one previous patch that changed a max from 32 to 64
<BenC> but it's 256 in the current code
<mjg59> BenC: Yeah, we pulled an earlier version of that fix in
<mjg59> BenC: Can we have the smartbattery driver patch as well? :)
<BenC> does it need a patch?
<BenC> I was under the impression that we just needed userspace
<mjg59> BenC: I sent you a diff
<mjg59> At least, I thought I did
<mjg59> BenC: It can be done through userspace, though to be useful it needs to be in the kernel
<BenC> don't think so, but it may have gotten lost in the pile of rubble known as my INBOX
<mjg59> sbs.diff
<mjg59> I'll resend now, if you like?
<BenC> yeah, please
<mjg59> Ok, sent
<BenC> thanks
<BenC> don't think I have time for an upload today, but I'm trying
<BenC> worst case is tomorrow
<mjg59> No rush
<BenC> there are git updates if that will appease you though :)
<mjg59> I'm in London all day
<mjg59> Heh, yes
<zul> oh goody then you can look at my stuff as well ;)
<BenC> zul: yeah, pulling yours very soon
<zul> i added something like 5 more patches last night that ill bug you next week about
<zul> they arent compiled tested yet
<BenC> fabbione: what's the 2.6.12-9 ->2.6.12-10 regression bug now?
<BenC> zul: are they in your git?
<fabbione> BenC: i dunno. i will have to search for it
<fabbione> BenC: i plan to do the test build tomorrow for that bug
<zul> BenC: in my test tree
<fabbione> or probabl today
<zul> BenC: i wanna see about adding sysfs to rtl818x first though
<fabbione> BenC: rhcluster is missing from README.Ubuntu-external...
<BenC> Ah, ok
<fabbione> no biggie :)
<BenC> zul: pulled your changes
<BenC> zul: FYI, if you run "debian/rules updateconfigs" when you add a new config option, it will update all arch's
<zul> ah...ok...thanks
<BenC> 6 builds started...we'll see how this holds up
<sn9> BenC: around?
<BenC> sn9: yes
<sn9> i think the muting problem is rooted somewhere in your snd-powermac-2.ko because "alsactl store" is misbehaving
<fabbione> BenC: are you running the daily builds or just test builds?
<BenC> test builds
<BenC> sn9: well I knew it was a bug in the module :)
<BenC> but that's useful info
<fabbione> BenC: ok, do you have any plan to switch daily build to a crontab or something?
<fabbione> BenC: i would like to get something apt-get'able for the MTR
<BenC> fabbione: crontab didn't work out so well because builds could be broken at the time it ran
<BenC> I've been doing many push, but that's getting to be a pain
<fabbione> BenC: well that's a risk we take with a daily.. tough if it doesn't build
<fabbione> it's part of the game
<BenC> plus it requires me doing manual moving to rookery anyway
<fabbione> uh why?
<fabbione> you can push with scp
<fabbione> just create temporary ssh keys on the buildds
<fabbione> without passphrase and pass them to ldap for internal use only
<BenC> yeah, I could do that, but I'm not so sure james would like it :)
<fabbione> or ask james to make a push account fo ryou
<fabbione> he prefers an anonymous account to do that
<fabbione> so the risk is minimal
<BenC> yeah, he would prefer a anon account for the builds too
<fabbione> but since it's internal to the DC it should be relatively safe
<fabbione> btw next week we should get 4 sparc v210 at the datacenter
<fabbione> 3x1 CPU and 1x2 CPU @1.4G
<fabbione> they are Sparc IIIi cpu, so we might have to run the porter box in UP mode
<fabbione> David didn't fix the SMP problems on that CPU yet, but at least he has the hw now
<sn9> BenC: i'm at a loss as to how "alsactl store" could read the current state incorrectly when the gnome mixer gets it right
#ubuntu-kernel 2006-02-08
<zul> heylo
<zul> hey BenC 
<BenC> hey
<zul> how is the sprint going?
<BenC> not there
<BenC> I had to cancel
<fabbione> hey benC
<BenC> hey fabio
<fabbione> BenC: sup?
<BenC> not much
<BenC> trying to get a kernel out today
<fabbione> ok
<fabbione> i am waiting for bubba to test the megaraid fix on .12
<fabbione> also.. i have prepared the images for that possible binutils regression
<fabbione> i need to write info in the bug
<BenC> cool
<fabbione> i can't find the bugnumber agian
<fabbione> bah
<BenC> I had to go to bugzilla and follow the malone link
<BenC> 20771 or 20711 on bugzilla
<fabbione> found it
<fabbione> there
<mjg59> BenC: ajmitch mentioned that acpi updates seemed to have broken his machine, but I don't know if he's filed a bug yet
<BenC> the ones I just pulled in?
<mjg59> Yeah
<BenC> he did his own build?
<mjg59> Didn't get a very detailed report, though
<mjg59> Not sure
<mjg59> Have you done a daily?
<BenC> well a bug report would be premature considering there aren't any images with those updates yet :)
<mjg59> Heh
<BenC> damn, gotta hold off his build until I find out for sure now
<BenC> lots of stuff isn't working with -15 kernel on my P4 box
<BenC> keyboard being one of them, so I can't even login
<doko> BenC, fabbione: I did make a mISDN patch, http://people.ubuntu.com/~doko/misdn-2006-01-25.diff.bz2, taken from ftp://ftp.isdn4linux.de/, I didn't test it yet, don't have any hardware here. config options should be 
<doko> #
<doko> # Modular ISDN driver
<doko> #
<doko> CONFIG_MISDN_DRV=m
<doko> CONFIG_MISDN_AVM_FRITZ=n
<doko> CONFIG_MISDN_HFCPCI=y
<doko> CONFIG_MISDN_SPEEDFAX=y
<doko> CONFIG_MISDN_W6692=y
<doko> CONFIG_MISDN_DSP=y
<doko> CONFIG_MISDN_MEMDEBUG=y
<doko> so just disable the CONFIG_MISDN_AVM_FRITZ option
<BenC> doko: what's that patch do?
<doko> BenC: add the mISDN driver
<BenC> doko: I already did that
<mxpxpod> BenC: have you gotten anywhere with sound in the past few days?
<BenC> mxpxpod: nah, been trying to get some other things fixed
<mxpxpod> BenC: that's cool... as long as we get this figured out before april
<BenC> oh yeah, It'll get done way before then :)
<BenC> the fact that it's working is good, just need to tweak some things once I get time to look into it
<mxpxpod> cool
<mxpxpod> BenC: here's something strange that I've noticed... sometimes when I sleep my ibook, I'll resume and there will be a >10 syslogd's running
<BenC> that's odd
<mxpxpod> BenC: and it's usually when programs that use network interfaces are left running (at least that's what I've come to the conclusion)
<mxpxpod> BenC: and if I kill any of them, sudo doesn't work
<BenC> I can't even guess what would cause that
<mxpxpod> BenC: yeah, me either
<mxpxpod> I think I'm going to do a fresh install next week (mine is upgraded from breezy) and see how that works
<mxpxpod> BenC: another thing, when my ibook boots, it puts the airport extreme at eth2, but when I remove the module and modprobe it again, it puts it at eth1
<BenC> yeah, I'm not sure what the deal is with that
<mxpxpod> ok, so that's not just me
<BenC> same with mine, but if I blacklist the sungem module, it goes to eth0 without problem
<mxpxpod> haha
<mxpxpod> BenC: do you use spamassassin?
<doko> BenC: which version?
<BenC> mxpxpod: not on this machine
<BenC> doko: whatever was the latest CVS when I pulled it in
<mxpxpod> BenC: ok
<mxpxpod> BenC: brb.. I'm gonna go log on with my laptop
<bryanf> BenC: back
#ubuntu-kernel 2006-02-09
<psusi> I'm seing some strange behavior in blockdev I think... dd is writing out data to a cdrw and it looks like blockdev is buffering up hundreds of megs of data
<psusi> then dd says it hit the end of the device, and syncs, at which point it goes uninterruptable for 10 minutes while 300 MB of dirty buffers are flushed
<psusi> this only happens though if I have dd use a large block size like 256 KiB, with the default 2 KiB blocksize, blockdev appears to not buffer so much
<psusi> so dd reports a lower throughput midway through, but when it finally hits the end and syncs, it doesn't go uninterruptable for 10 minutes
<psusi> why is the block layer so strange? ;)
<BenC> psusi: buffering improves performance
<BenC> most things don't call sync, so your problem is kind of unique to dd
<psusi> BenC, yea... but only to a point... buffering 300 megs of sequential IO is a bit silly isn't it?  and more importantly, why does it buffer more when dd is sending down larger write()s?
<BenC> how do you know it's 300megs?
<psusi> with bs=2KiB it looks like the block layer is causing dd to sleep more to let the device catch up with the dirty buffer flushing
<BenC> more transactions, so block layer is flushing more often
<psusi> BenC, I'm guestimating because when dd goes to sync, the process goes uninterruptable in the sync for 10 minutes while the rest of the dirty buffers are actually written
<BenC> how much mem/swap do you have?
<psusi> why does the number of transactions do anything?  shouldn't the block layer see that there is already plenty of dirty buffers queued to the device waiting to be flushed adn block untill some of those complete?  regardless of block size
<psusi> gig of ram
<BenC> probably a better question for the kernel devs
<BenC> people familiar with the vm/block layers
<psusi> I suppose the buffering is good for apps that don't sync.... I guess what I don't like is that the sync goes uninterruptable for 10 minutes
<psusi> I need to clean up my aio dd patches and get them submitted
<psusi> aio avoids the D state which is nice
<psusi> of course, the drastically lower cpu load and somewhat higher throughput are nice too ;)
<BenC> do you really want to interrupt a sync()? :)
<psusi> I really want the process to die when I send it a SIGKILL ;)
<zul> heylo
#ubuntu-kernel 2006-02-10
<hectorC> Hello...
<hectorC> is there any kernel developer available for some information?
<hectorC> I'm part of a group of guys trying to develop an Ubuntu kernel with realtime preemption for pro-audio use... I just have some questions regarding the Dapper kernel
#ubuntu-kernel 2006-02-11
<zul> hey BenC back from london?
<BenC> never went :)
<zul> ah i thought you did
<zul> i have some new crack for you..
<zul> watching the super bowl?
<bubbalwz> BenC: one of the kernels fabbione setup for me worked
<zul> heylo
<fabbione> hey zul
<zul> hey fabbione how is it going?
<fabbione> i am tired.. otherwise fine
<zul> how was the sprint?
<fabbione> okish
<bubbalwz> sup fabbione
<fabbione> hey bubbalwz 
<fabbione> bubbalwz: not much.. trying to get back on track after the sprint
<bubbalwz> heh
<fabbione> i am dead tired and the plain was 2 hours late
<bubbalwz> that sucks
<fabbione> got no sleep.. at all
<fabbione> well just a bit
<bubbalwz> all the fscking?
<bubbalwz> so what did you change w/ the old kernel?  just add the pci ids?
<fabbione> what fscking dude.. i got nothing in the last 4 months since my wife got pregnant
<bubbalwz> oh thats right
<fabbione> bubbalwz: yes, only adding the pci id
<bubbalwz> huh, wonder why it got left out
<bubbalwz> and if there are others that are left out
<fabbione> i know why
<fabbione> i don't think there are others
<fabbione> basically the old megaraid driver had  a CATCHALLTHECRAPHWID at the end of the list
<fabbione> something that i did remove to make sure there was no overlap between old and new
<bubbalwz> right.. i gotcha
<bubbalwz> bizarre that i had the only id that was left out
<fabbione> anyway test the new kenrel and make sure the megaraid_* is in the initramfs
<bubbalwz> ok, i will
<bubbalwz> is that the only megaraid entry I need?
<fabbione> if it works, i will force to the new driver (preferred)
<bubbalwz> just megaraid_mbox ? 
<fabbione> otherwise i will put it in the new
<fabbione> let me check
<bubbalwz> or _mm
<fabbione> megaraid_mbox.ko  megaraid_mm.ko  megaraid_sas.ko
<fabbione> put all of them
<fabbione> it won't hurt
<fabbione> sas is probably from .15
* fabbione checks .12
<bubbalwz> yeah, sas aint in mine
<fabbione> ok
<bubbalwz> but is where i work.. so that's a little bizarre
<fabbione> add only _mm and mbox
<bubbalwz> ok
<fabbione> sas is .15 
<bubbalwz> so any idea how i could make a ubuntu cd that has the updated kernel on it (so I could reinstall my box)
<bubbalwz> or just wait till the next version? :)
<fabbione> why on heart do you want to reinstall?
<fabbione> earth even
<bubbalwz> also, will you make sure the added pciid makes it into future changes
<fabbione> yeah of course
<bubbalwz> fabbione: i was thinking about getting a new disk and converting raid1 -> raid5
<fabbione> if you can do netinstall i can give you a custom installer image to do that
<bubbalwz> ahh
<fabbione> otherwise wait for dapper
<fabbione> it's only 3 months ahead
<bubbalwz> i'll do that
<bubbalwz> cool
<fabbione> apr 20th
<fabbione> i can get the fix in .12 at the next security update or something
<bubbalwz> that'd be cool
<fabbione> but that doesn't propagate into the installer
<bubbalwz> right, i figured it wouldnt
<fabbione> but for reinstall just wait dappe
<bubbalwz> i'll get back to you tonight on the new kernel
<bubbalwz> ok
<fabbione> sure
<fabbione> i might not be online, just send me an email
<fabbione> or send me your wife..
<bubbalwz> i will
<fabbione> she knows the way here
<fabbione> :P
<bubbalwz> hah
<fabbione> ahah
* fabbione cuttles bubbalwz a bit
<bubbalwz> hey now
<bubbalwz> so i'll check back w/ you
<bubbalwz> thanks again for your help dude
<fabbione> sure
<fabbione> no problem dude
<fabbione> anytime
<bubbalwz> you've kept a ubuntu user :)
<fabbione> eheh
<fabbione> ok.. gdd is bringing is server with some kind of megaraid crap in it
<fabbione> so i can test that one too
<zul> hmmm?
<mjg59> BenC: Any chance you could pull softmac and bcm43xx again?
<BenC> I have it for next kernel, I'm about 30 minutes away from an upload
<fabbione> hi BenC 
<BenC> last sync I did two days ago, it locked up my system
<BenC> hey fabbione
<fabbione> BenC: i have a regression with 2.6.15-14-amd64-k8
<fabbione> compared to 13
<fabbione> the skge driver seems to be broken and it can't do ipv6 anymore
<BenC> odd, I didn't touch it
<fabbione> at least the address is configured but there is no ipv6 going
<fabbione> i saw one change in 2.6.15.1 that might be at fault
<BenC> will you be able to do a recompile with that backed out?
<fabbione> BenC: yes, that was the idea, but i wanted to warn you in the meantime
<fabbione> i still have a lot of performance issues with this kernel
<fabbione> i need to do the bisect stuff 
<BenC> it's likely something with SMP being enabled
<BenC> try recompiling with CONFIG_SMP=n
<BenC> I may revert amd64-generic to UP
<BenC> like we do for i386
<fabbione> yes i am cloning the tree for scratch puropose :)
<BenC> I'm pushing 2.6.15-15.20 final (just a changelog update)
<BenC> fabbione: feel like doing lrm/linux-meta later?
<BenC> if not, I think I can do it later tonight or in the morning
<fabbione> BenC: i won't be online for long :) but otherwise i can do them when i wake up tomorrow morning
<fabbione> it's like 5:20 pm here
<BenC> ok, if I can get to it, I'll put it in the topic
<BenC> if you get to it before I do, just > topic for me
<sn9> does -15.20 include snd-powermac fixes?
<BenC> yeah
<fabbione> BenC: ok. I will have some redhatclsuter updates for the next kernel. We will need to check OCFS2 together
<fabbione> because they do everything in git on top of .16
<fabbione> and i am a bit rusty on the code
<BenC> still an issue with dmasound needing to be loaded by someone, and suspend/resume leaves it disabled until volume is changed for another
<BenC> fabbione: ok
<sn9> it's not just suspend/resume
<sn9> it's mute on boot
<sn9> becuase "alsactl store" puts mute settings in the file
<crimsun> which element?
<sn9> not just one element
<crimsun> then which elements?
<BenC> crimsun: I wouldn't worry too much, it's a regression caused by my changes to snd-powermac
<sn9> but the ones that cause the muting are PC Speaker and the global muting. i'll look at the file in a min
<crimsun> BenC: ok.
<fabbione> BenC: tomorrow sparc buildd will arrive at DC :)
<fabbione> BenC: porting box will take a bit longer
<BenC> sweet
<fabbione> yeah
<BenC> did you see dave's niagra announce?
<fabbione> nope
<BenC> he's made the git tree public
<fabbione> ah
<fabbione> cool
<fabbione> niagra or niagara?
<fabbione> because i understood there are nics called niagra
<fabbione> that have nothing to do with niagara
<BenC> heh, which ever one is correct :)
<BenC> the sun4v
<fabbione> ok
<fabbione> niagara :)
<fabbione> BenC: start pulling from it :)
<BenC> it's targeted for 2.6.17 :(
<fabbione> i see
<fabbione> we need it in anyway
<BenC> pulling changes might get ugly
<fabbione> i think it won't be a big problem
<fabbione> according to him, it should just work on .15
<fabbione> and patch should apply clean
<fabbione> BenC: do you have the URL to the announce?
<BenC> nah, just an email
<fabbione> oik
<fabbione> ok
<BenC> sparclinux@vger.kernel.org ml
<BenC> Subject: Niagara work in progress GIT tree
<BenC> master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.17.git
<fabbione> i wonder how bad it is to just try to pull it :)
<fabbione> yeah i am looking at it on gitweb
<zul> niagra falls is nice but wet..
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-15.20 uploaded (No rest for the weary) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<mjg59> BenC: Right. I'll see if I can track down the ACPI issues.
<fabbione> BenC: btw.. with soyuz in place, i am not sure how long it will take to get stuff NEW'ed
<zul> BenC: did you watch the super blow?
<fabbione> speaking of super bowl.. did any of you recorded the 30 minutes game of super models in lingerie? ;)
<zul> its pay per view
<fabbione> you can still record it, can't you?
<zul> yeah but i didnt want to pay for it, besides my wife was home at time
<fabbione> ahhaha
<zul> besides you can probaly find a torrent for it
<zul> i am a cheap bastard
<fabbione> yeah
<fabbione> zul:  was the lingerie event part of the super bowl or did they do it separatly?
<zul> seperate 
<fabbione> ok
<fabbione> i only found the superbowl 
* fabbione is more interested in the other one :)
<zul> fabbione: the FCC would go ape shit if it was on regular tv
<fabbione> no wonder :)
<zul> i would search as well but im kind of at work
<fabbione> don't worry
<fabbione> it can wait a few days
<zul> heh...maybe i could get fired and then go work for canonical ;)
<zul> anyways time for lunch
<sn9> crimsun: i dunno, i can only see PC Speaker Playback Switch being wrong in the file
<mjg59> I have a driver that calls platform_driver_register, but its probe routine enver seems to get called. Anyone have any idea why?
<mjg59> Ah. Because platform devices don't probe.
#ubuntu-kernel 2006-02-12
<zul> heylo
<zul> heylo
* lamont-work wonders what the state of xen is in our 2.6.15 kernel
<lamont-work> s/xen/xen 3.0/
<zul> i dont think it works too well ;)
<zul> i think there is stuff in the wiki but i have never played with xen
#ubuntu-kernel 2007-02-05
<pkl_> BenC: hi
<BenC> pkl_: Hey
<pkl_> BenC: a good time to discuss kernel devel?
<BenC> pkl_: Yeah, give me about 5 minutes to finish up something
<pkl_> BenC: no problem.
<BenC> pkl_: Ok, I assume you've done a git clone from either kernel.org or rookery...if you did kernel.org, I would suggest rebasing on the rookery one
<BenC> pkl_: I also assume you've read the git-guide on the wiki and have used git before, so I'll skip all the redundant how-to-use-git stuff :)
<pkl_> Yeah, I used kernel.org.  Rookery is the Ubuntu repo?
<pkl_> Yes, I've used git before.  I started playing around with it in its early development
<BenC> On rookery.ubuntu.com /srv/kernel-team holds our repos
<BenC> it's the same as what's on kernel.org, but you wont be able to get to any non-public branches if and when we create them
<pkl_> I have _not_ used it for +1 year, and it seems more capable now.  Though kernel.org is now extremely slow :-)
<BenC> then there's that :)
<BenC> pkl_: Have you ever used kernel-package/make-kpkg from debian before?
<pkl_> No.  I've always been extremely disto agnostic.  I use so many distros that I used commands that work across them all.  I daresay it will b easier to learn the Debian processes :-)
<BenC> it's actually really horrible because it's a tool meant to work with almost any kernel version for almost any flavor of kernel
<pkl_> My guess is make-kpkg builds the kernel, modules, installs the kernel and rebuilds the initrd/initramfs as necessary.
<BenC> we'll actually stop using it for feisty+1, but since we have 4 releases using it now, you'll need to get used to it a little
<Mithrandir> initramfs-es are built on installation.
<Mithrandir> since you want to update them when you update bits of them, like usplash or something.
<BenC> It packs all of it up, and includes install hooks in the package for updating the boot loader and calling other tools to do the initramfs rebuild
<BenC> right, other packages can include initramfs hooks, so it's an at-install function
<pkl_> so, the initramfs is not explicitly rebuilt as part of the kernel install?
<BenC> it is as part of the install
<BenC> but there is no initramfs in the kernel package
<BenC> the kernel postinst hook calls update-initramfs
<BenC> which does the dirty work
<BenC> pkl_: Anyway, make-kpkg is only semi important for our work
<BenC> we use it almost like you'd use "make"
<pkl_> ok.
<BenC> the main part of the build is the ABI, and flavours/configs
<BenC> In debian/config/ you will find must of the ugliness that tells the build system what kernels to build for each architecture
<BenC> debian/config/$arch/ contains the per architecture config files
<BenC> there is a debian/config/$arch/config that contains the common parts for all flavours, and debian/config/$arch/config.$flavour for each specific flavour
<BenC> the build cats both of them together and does a "make oldconfig" to get things started
<BenC> the oldconfig will fail if there's any new questions that the config does not explicitly answer
<BenC> To update all the configs, you can do "debian/rules updateconfigs", this rebuilds all of the architectures
<BenC> and splits them using some magic in debian/bin/
<BenC> The splitting is done to make it easier to keep configs consistent per architecture
<pkl_> ok
<fabbione> morning pkl_ 
<BenC> Stop me if you have any questions
<pkl_> morning fabbione.  It's a really nice Sunny morning here in Wales., for a change!
<BenC> So when the build starts, it basically creates a copy of the source in debian/build/build-$flavour/
<BenC> for each flavour, cats the config, and does the build, then completes it by creating a .deb
<pkl_> BenC: ok.  I'm trying to look through the kernel while you say this..
<fabbione> feh.. it's -25 C here in Montreal
<BenC> fabbione: Blame Canada :)
<pkl_> toasty
<fabbione> Canada = the biggest sperm bank in the world....
<fabbione> it's enough you get out to freeze and store
<pkl_> Global warming hit Cabada yet?
<pkl_> s/Cabada/Canada/ :-)
<BenC> pkl_: The other nifty thing we do is track the ABI of our kernels...
<BenC> The debian/abi directory contains the ABI for the last uploaded release of the kernel
<BenC> after the build, it checks this (via a simple diff) to see if the ABI changes
<pkl_> Ok.  ABI to me means App Binary Interface??  How do you track that?
<BenC> We encode the ABI into our package name, and into the kernels EXTRAVERSION
<BenC> Modules.srcver
<BenC> each exported function (vmlinux and modules) is tracked in there with a hash of the function
<BenC> the hash is of the function name, it's arguments and return value
<BenC> this is something the kernel does already, we just use it to check if it changes
<BenC> so our package package versions are something like 2.6.20-6-generic, which EXTRAVERSION=-6-generic, and 6 is the ABI
<pkl_> Ok.  Sounds good.  I didn't know Debian did that.
<BenC> generic is the flavour
<BenC> I don't think debian does
<cjwatson> pkl_: (we'd had problems with modules outside the kernel packages breaking unexpectedly on what we thought were minor updates - this stops us getting caught out by forcing us to rebuild when the interface changes)
<cjwatson> Debian does now
<BenC> pkl_: Do not confuse anything we do with what debian may or may not do :)
<BenC> at least as far as the kernel is concerned
<BenC> pkl_: So, when you do a test build for a new kernel, if the ABI changes, you would see it error with that message, and you would bump the ABI
<BenC> how you bump the ABI is different with feisty and pre-feisty
<BenC> pre-feisty, you do "debian/rules bumpabi", and feisty you simply edit debian/changelog and change it in there (e.g. 2.6.20-6.12 to 2.6.20-7.12)
<BenC> Note, our minor version (.12 in the above example) is ever increasing, it does not restart at 1 when the ABI (major) increases
<pkl_> The debian/config dir only contains dirs for architectures supported by Ubuntu.  Hence no arm etc.  This implies parisc is supported?
<BenC> it's sort of a rolling counter of the builds we've done
<BenC> pkl_: parisc was supported, but hasn't been built since dapper, AFAIK
<BenC> I left it in there because I keep hearing rumors that lamont will revive it...and maybe that Kyle dude will fix it :)
<BenC> pkl_: Technically it doesn't mean we support it (like x86, ppc, x86_64, sparc), it just means we build it...parics and ia64 are community supported architectures
<pkl_> ok
<BenC> we build it, but only if non-paid people take the time to get it going
<BenC> pkl_: any questions so far?
<BenC> I'm saving all this to put into a wiki BTW, so a nice FAQ would be nice
* Nafallo understands it so far :-)
<BenC> lots of niceness
<pkl_> Simply editing the changelog to update ABI implies the build process checks this?
<BenC> yes
<BenC> it will rebuild the debian/control file, which lists all the packages
<pkl_> Obviously the changelog is not simply human readable as in many projects
<BenC> debian/control is built from debian/control.stub, which is further generated from debian/control.stub.in
<BenC> no, debian/changelog is very formatted
<BenC> in fact, in feisty, you do not edit at all, except to start a new release, or change the abi
<BenC> all the changelog entries are generated from git using "debian/rules insertchanges"
<BenC> "debian/rules printchanges" gives you a running list
<zul> kylem: i dont think you want to go outside today -39C with the windchill
<BenC> "debian/rules help" if you forget any of this
<Nafallo> kewl :-)
<zul> Hey BenC
<Nafallo> hi zul :-)
<zul> hi Nafallo 
<BenC> pkl_: In case it isn't obvious, "debian/rules" is the primary build entry for all debian packages :)
<BenC> zul: hey
<BenC> pkl_: Which brings us to actually building this bohemoth
<BenC> pkl_: When I do test builds, I simplify things, and just run "fakeroot debian/rules binary-debs"
<BenC> (you'll want to install the fakeroot program, it's a debian developers best friend)
<BenC> pkl_: If you only want to build a single flavour, useful for quick tests, do "debian/rules binary-debs flavours=foo", e.g. foo can be generic, which is the most common flavour
<BenC> either of those will leave you (if the build succeeded) a package in debian/build/
<BenC> which you can install and test
<BenC> For feisty, before any upload, I usually do full builds on x86, x86_64, powerpc, sparc and ia64, and I boot at least one kernel from each of those
<BenC> You wont have to worry about feisty uploads, but for security uploads, I would suggest doing at least as much, maybe a little more testing (considering it's a stable release)
<BenC> pkl_: absorb this, I'll be back in 10 minutes
* Lure likes this tutorial... ;-)
<pkl_> fakeroot debian/rules binary-debs" will build all flavours for the current architecture?  Can you build for all architectures (which would require appropriate cross-compilation environment)
<fabbione> pkl_: no you can't cross compile yet
<fabbione> it would require a bunch of changes in debian/rules
<fabbione> pkl_: we have porting machines for that
<fabbione> where you can build sparc/ppc etc..
<pkl_> Yes, I didn't think you could, but I thought I'd check...
<pkl_> Who hosts the porting machines?
<Mithrandir> Canonical.
<Mithrandir> they're in the London DC
<BenC> pkl_: The canonical wiki lists the machines, and also shows you how to use ssh proxy to get to them
<BenC> pkl_: There's one exception to the flavours bit, the lowlatency kernel is built as a modified generic kernel..it used debian/config/$arch/config.generic and manually seds some things
<BenC> you can ignore it for now, since it's not an officially supported kernel
<BenC> but just so you know how it gets created :)
<pkl_> if the porting machines are in London, you must have someone around to push the button if something goes wrong :-)(
<cjwatson> they're generally just for building - you don't have root on them
<pkl_> ok.  You can use the porting machines to build, but you mush have a machine locally (or ask someone who has) to build the new kernel.  No problem, just need to understand this.
<pkl_> build == boot. 
<pkl_> "to build the new kernel" -> "to boot the new kernel"
<Mithrandir> correct.
<Mithrandir> or just upload to feisty. :-P
* Mithrandir hides.
<Nafallo> since Mithrandir is the release manager I think we should do what he says ;-)
<BenC> Or just use Mith for all your guinea pig needs
<BenC> pkl_: One thing to remember (and Mith will no doubt re-enforce this) the buildd's are not test build systems :)
<Mithrandir> BenC: I only care about amd64, so as long as you don't break that, I'm happy. ;-)
<BenC> the buildd's are the machines that actually build the source we upload for users to eventually use
<Mithrandir> and if it builds, it ends up in the archive, which means that people will use it.
<BenC> when we upload, we should expect it to build
<BenC> right, so builds sent there are also not considered "testing"...especially in the cases of security updates
<BenC> feisty is sort of testing, but we try to not make it so bad :)
<Nafallo> word :-)
<pkl_> Yes, I actually do have all the support architectures at home , but not hppa, or ia64.
<BenC> don't worry about either of them...for stable releases, ia64 and hppa are not even considered important, and for devel like feisty, it's only partially important
<BenC> I'm not sure that security is supported for ports.ubuntu.com architectures
<Nafallo> i.e. if mark says that we will support either of them next cycle, they might be important ;-)
<Nafallo> BenC: they are probably just built, but I think we can ignore arch-specific CVEs :-)
<BenC> pkl_: Any questions thus far?
<Mithrandir> pkl_: while it's nice if you don't break hppa and ia64, I'm not too fussed about them if they do end up blowing up slightly.
<BenC> This is a lot of material, and  will be doing the wiki for it today
<Mithrandir> like, hppa is a catastrophe right now due to threads being fucked.
<BenC> I think sparc kernel is still FTBFS on breezy :)
<Nafallo> hehe
<BenC> no wonder I'm never up this early... the Sun is shining right in my eyes at this time of the morning
<cjwatson> that's your own fault for using sparc hardware
* cjwatson runs
<Nafallo> LOL
<fabbione> ahhaha
<pkl_> Sound ok.  The obvious thing to ask next is what do you do to 'test' a build.  Is this a defined framwork, automated, regression checked for etc.  Or is it ad-hoc?
<Mithrandir> so far, ad-hoc.  iwj is building some automated test suite, but I'm not sure how it applies to the kernel.
<fabbione> pkl_: "hey the patch applies! It's ready for stable.."
<fabbione> :P
<pkl_> Who still uses hppa?  It not as bad as MIPS (any desktop MIPS must be 10+ years old), but HP hasn't built parisc systems for years...?
* fabbione does
<pkl_> I used to use one 12 years ago!
* fabbione pats his 2 amiga's
<Mithrandir> pkl_: they do.
<Mithrandir> they finished the last CPU design of the line less than a year ago, iirc.
<pkl_> Running HPUX unfortunately (with such a broken compiler/asembler you had to use GCC and gas).
<pkl_> I still have my Archimedes/QL/SPectrum stull but never  turn them on now :-) 
<pkl_> I used to know the people who wrote parts of Amiga DOS (it was based on Tripos)
<fabbione> pkl_: i have a zx81 still working..
<fabbione> i did sell the Spectrum at the time :)
<pkl_> I butchered mine for a micromouse I built back in 1985 :-(
<cjwatson> my Spectrum+ died of terminal keyboard failure (repaired N times). bit of a standard problem with that model I think :(
<BenC> pkl_: I have some scripts that I use to build across all my machines
* Nafallo waits for the lkm and lm tutorials :-)
<BenC> pkl_: I have them in debian/bin/bens-build-scripts/ in feisty
<BenC> no docs, just a chunk of shell code
<pkl_> Yes, the membrane keyboard practically disintegrates.  Becomes brittle and snaps.  The keybaord on my Dragon 32 still works (even it's older) because it used old-fashioned makde/break leaf contact keyboard.
<BenC> pkl_: As far as testing, goes, I just do boot testing on all the machines I have (which is too many to list)
<pkl_> I don't think Ubuntu is anyworse at testing that other distros AFAIK.  Testing is, however, a bit of a disaster however WRT to the kernel.
<pkl_> Ok.  All sounds good so far :-)
<Mithrandir> pkl_: in the case of you managing to get a busted kernel into the archive (as in, completely busted), please do get in touch and we can make it so that nobody new is getting the kernel at least, and through that limit the damage.
<pkl_> Do you test the security fixes/patches.  Some of the security notices are (to say the least) hypothetical, and almost impossible to trigger? 
<BenC> pkl_: there's some docs on the ubuntu wiki about stable release uploads
<BenC> pkl_: We usually patch any CVE's that have been patched in 2.6.x.y git
<bubbasucks> sup ben
<BenC> even if hypothetical
<BenC> hey bubba
<cjwatson> StableReleaseUpdates on the wiki mostly just covers non-security uploads
<BenC> cjwatson: There's a kernel wiki regarding it's special case for proposed
<BenC> I think SRU wiki links to it
<BenC> cjwatson: Isn't there a wiki page for busted stable/security uploads from germany sprint?
<fabbione> hey Mr Wilson
<fabbione> https://wiki.ubuntu.com/StableReleaseUpdates
<fabbione> ^^ SRU
<cjwatson> BenC: I think so, but I don't remember the page name
<BenC> yay, lrm built
<BenC> cjwatson: fabbione says it's canonical wiki
<fabbione> yeah it's somewhere there.. i am looking for it
<BenC> who here has an atheros wifi?
<pkl_> I have...
<BenC> I need someone to actually tell me if it works with the lrm I just uploaded to feisty
<bubbasucks> whats that fab
<Nafallo> BenC: no luck with rt2x00 I guess? :-)
<pkl_> I can do that...though I'll have to reboot this machine
<BenC> rt2x00 got demoted
<BenC> using rt2x00-legacy stuff in git, but that's not uploaded yet
<Nafallo> oh. why so?
<Nafallo> demote that is
<Nafallo> not that I
<BenC> rt2x00 drivers don't build with the new d80211 stack
<Nafallo> ouch
<kylem> wow. ben's up early.
<kylem> morning.
<zul> hey kylem 
<fabbione> hey kylem 
<Nafallo> kylem: he wanted the sun in his eyes ;-)
<kylem> lol.
<Nafallo> hi kylem :-)
* kylem waves.
<BenC> sweet, the module checking code kicked in and caught some missing modules for -7.12 :)
<BenC> kylen: Been up for 5 hours now, your just lazy :P
<kylem> BenC, ... damn dude.
<bubbasucks> wow that is quite some process
<bubbasucks> so sounds like i need to get my old kernel working
<BenC> pkl_, kylem: I want to arrange a day this week (and hopefully every week) when the kernel team can meet regularly...how does 10AM EST, 3PM UK sound?
<bubbasucks> glad kernel's are special cases
<BenC> probably tomorrow or wed
<pkl_> sounds fine.
<BenC> bubbasucks: I would say that kernels made the rules instead of breaking them, but I'd probably get smacked down for that :)
<BenC> kylem: ?
<bubbasucks> ha!
<bubbasucks> sounds like the buerocracy at my old job
<BenC> heh, not really any bureaucracy here, just general put-you-in-your-place kind of stuff :)
<pkl_> Where did you work?  I know places with so much bureaucracy you could hardly get anything donw.
<BenC> canonical has the least bureaucracy of any place I've worked for
<BenC> we're starting to get some from basic growth, but it's the well needed kind
<bubbasucks> heh
<bubbasucks> brb 
<pkl_> The important thing is to avoid getting management types, especially ones where doing things by the book, and holding meetings are all important.
<pkl_> A three letter company I used to work for springs to mind.
<fabbione> BenC, bubbasucks: the problem bubba has might be a genuine driver bug. the pci is is in megaraid_mbox 
<fabbione> (checked the sources and module is loaded by initramfs)
<BenC> fabbione: is it an AMI?
<fabbione> but there are no /proc/partitions
<fabbione> BenC: dunno.. it's in the email bubba did send to us.. wait
<Eruantalon> How many people does canonical have working with the kernel? Any of them do upstream kernel development or is it just packaging?
<BenC> fabbione: Because I also have an AMI machine that is listed in mbox, but it's ignored because it isn't the actual raid device (it's just the processor)
<BenC> no driver is loaded for it
<fabbione> 0000:02:07.0 RAID bus controller: American Megatrends Inc. MegaRAID  
<fabbione> (rev 02)
<fabbione>          Subsystem: Dell PowerEdge Cost Effective RAID Controller  
<fabbione> ATA100/4Ch
<fabbione> BenC: ah... and what't the fix for that?
<BenC> Eruantalon: we have 4 as of today (Tim just started today), I used to do upstream linux1394, and Phillip does squashfs which will hopefully be upstream soon
<BenC> Eruantalon: Kyle does parisc
* fabbione does sparc and cluster sometimes and so to speak.. ;)
<BenC> fabbione: No fix, it's just not used...there would be another device that actually handles the raid, and if it's what I'm thinking, then it needs edgy-security to work
<fabbione> oh ok.. i guess we can get him to test that
<BenC> pkl_: Do you want to attempt a simple build from feisty git to see if you've got things going correctly?
<BenC> pkl_: You'd need kernel-package, kernel-wedge, fakeroot, debhelper and build-essential installed to start off
<fabbione> or apt-get build-dep linux-source-2.6.20
<fabbione> and fakeroot
<pkl_> Yes, I'm in the process of doing that.  I already discovered (though trail and error) the things I need :-)
<BenC> yeah, that works too :)
<Eruantalon> BenC: I just realised that you are the guy i read about in Behind Ubuntu that lives on a farm :-)
<BenC> pkl_: initially, if you have things to commit, run them past kernel-team@lists.ubuntu.com (which you need to subscribe to)
<BenC> Eruantalon: hehe, my infamous interview :)
<pkl_> Squashfs will, hopefully, be upstream early this year.  The work I was asked by LKML to do, has been done.  There's just one or two more little-ish things to be done before I resubmit.
<pkl_> Yup, I'm subscribed.
* BenC goes to do some wiki editing
<kylem> BenC, anytime is fine. sorry, was in the shower.
<BenC> hopefully I can bring it up to snuff and inline with jono's suggestions
<Nafallo> BenC: put meeting in topic maybe? :-)
<BenC> kylem: You shower? Are you really a kernel hacker?
<Nafallo> lol
<kylem> yes, a clean one.
<BenC> not very clean shaven though :)
<pkl_> BTW, I notice you've still got Squashfs 3.1 in the feisty kernel :-)
<BenC> pkl_: it's been working, so we haven't wanted to touch it :)
<kylem> BenC, haha.
<pkl_> Squashfs 3.2 has some nice updates.  It been harden to be more resiliant to corrupted filesystems (as a result of MoKB and a CVE).  It also has NFS support, which might be useful for one of the Ubuntu specs.
<fabbione> pkl_: just push the crack to the git tree ;)
<fabbione> ben will love that :)
<pkl_> s/crack/crap/g ?
<kylem> i think we have 3.1+patches in {dapper,edgy}
<fabbione> BenC: btw.. i just made you owner of the kernel team in LP... i think it was about time..
<BenC> fabbione: muchos gracias
<fabbione> BenC: hehe i just so totally forgot about it ;)
* fabbione officially passes the baton to Ben with only almost 2 years delay
<BenC> pkl_: crack == slang for new shit
<BenC> crap is something we reserve for xen only :)
<Nafallo> fabbione: :-O
<kylem> ugh.
<BenC> fabbione: Better late than never :)
<Nafallo> fabbione: two years already?
<Nafallo> :-)
<kylem>  183 N GNU/kFreeBSD Ma Bits from the Debian GNU/kFreeBSD porters
<kylem> why do i even bother trying to read my email?
<BenC> 1.33 years
<BenC> kylem: lol...crack or crap? :)
<Nafallo> ah. thought it wasn't two :-)
<BenC> coffee, cigarette...
<pkl_> I avoided Xen for a long time, not having an Intel machine for a long time.  It is really that bad?
<kylem> worse.
<Nafallo> hmm
<zul> oh its not that bad....hah..
<pkl_> The guys that wrote are pretty clever.  Ian Pratt was one of my drinking mates in Cambridge 11+ years ago.
<pkl_> Lhype/Lguest/Rustyvisor seems to be going quite well.  Anyone manage to see the talk at LCA?
<Mithrandir> Xen is lovely as long as you don't look at the code. :-)
<BenC> pkl_: I've been using kvm a lot, and it's actually pretty cool
<zul> pkl_: looking at the xen code has a tendency to make you go crazy or make people think that you are crazy :)
<fabbione> BenC: do you think you can take a look at https://launchpad.net/ubuntu/+bug/83412 ?
<fabbione> BenC: i am not 100% sure if it's the testcase or the kernel..
<fabbione> i did check the latest ltp version and it reports the same error
<BenC> fabbione: Could be 32-bit/64-bit thunking problem
<fabbione> it doesn't look like it
<BenC> I assume LTP builds/runs 32-bit code
<BenC> how can I reproduce it?
<fabbione> i would like to exclude the Niagara vs other sparc cpu case first
<fabbione> 100% on niagara
<BenC> my e3k isn't booted right now...been too cold to walk out to the barn to power cycle it :)
<fabbione> Reproduction steps:
<fabbione> 1. Install the ltp-kernel-test package.
<fabbione> 2. Run /usr/lib/debian-test/tests/linux/testcases/bin/shmt09
<fabbione> ok.. it's a minor problem for what i can tell
<fabbione> but i want to make absolutely sure it's a kernel issue before i ask david to look at it
<fabbione> BenC: define toocold ?
<fabbione> :P
<BenC> too cold for us Virginians
<fabbione> ah ok ;)
<fabbione> you should teach one of your cows to turn it on/off
<fabbione> "Clarabella: turn on!"
<BenC> you can keep your colder than Antarctica weather up there in Montreal :)
<fabbione> "Clarabella: turn off!"
<BenC> lol
<Mithrandir> or just buy a power switch
<fabbione> + remote ;)
<kylem> fabbione, how's mtl this morning?
<fabbione> kylem: cold... -20C and -30 with windchill
<zul> not that cold
<kylem> bummer. -37 here.
<fabbione> BenC: 32/64 bits makes no diff
<lamont> fabbione: it's cold either way, then?
<fabbione> lamont: yeah
<lamont> only -1C here
<bubbasucks> up
<bubbasucks> err, yo
<lamont> er, -2
<kylem> lucky lamont
<kylem> then again, you have like 10 ft of snow?
<lamont> kylem: it's been bitter cold the last few days...
<lamont> still have snow piles in town.  out here, we didn't pile it up so much, so it's mostly melted.
<kylem> ah.
<lamont> or blown to kansas
<kylem> haha.
<pkl_> BenC: lvm requires hardware VT support, which I have not (yet) got, except for the Mac which I tend to run in Mac OS X.  Pity because it seems quite good.
<pkl_> s/lvm/lkm/g
<BenC> kvm?
<BenC> Yeah, I have three boxes here with Intel support I've been testing it on
<pkl_> yeah, that's what it's called.
<pkl_> Silly, three letter acromyns.  Kvm always makes me think of Java (there is or was a Java VM called Kvm).
<BenC> pkl_: You have your launchpad account setup?
<BenC> kvm makes me think of keyboard-video-mouse switch
<kylem> he
<kylem> h
<BenC> pkl_: Make sure you do join the kernel-team at https://launchpad.net/~ubuntu-kernel-team
<pkl_> I'll check.  I set it up months ago, but I'm not what it is setup.  What should  I have?
<BenC> pkl_: You should have a launchpad account, done the Code of Conduct, added your gpg and ssh keys, etc.
<ivoks> is it possible to get newer 3w-9xxx in dapper during updates?
<ivoks> (for next kernel release?)
<BenC> ivoks: In proposed updates yes
<ivoks> BenC: do you need diff? 
<ivoks> :)
<ivoks> argh... git, right? :)
<BenC> yes, and send it to kyle
<kylem> no, send it to kernel-team@lists.u.c
<kylem> ;-)
<bubbasucks> ii  linux-image-2.6.17-10-generic                        2.6.17.1-10.34         
<ivoks> ok :)
<fabbione> BenC: according to bubba, he has -security
<BenC> hmm...not sure then, I'd have to check the dmesg/lspci output again to see what's up
<bubbasucks> [4294671.621000]  megaraid: found 0x101e:0x1960:bus 2:slot 7:func 0
<bubbasucks> (this is from 2.6.12)
<bubbasucks> 02:07.0 RAID bus controller: American Megatrends Inc. MegaRAID (rev 02)
<bubbasucks> 02:07.0 0104: 101e:1960 (rev 02)
<BenC> AMI, yeah, that's just a virtual device for the RAID processor
<BenC> no module is supposed to use it
<BenC> what's the sub vendor/device?
<pina> i received my CSA v11 today
<bubbasucks> where can i get sub/vendor device?
<BenC> lspci -vvn
<BenC> the second line I think
<bubbasucks> 02:07.0 0104: 101e:1960 (rev 02)
<bubbasucks>         Subsystem: 1028:0511
<pina> you guys want to read this?
<pina> bsd vs linux debate
<ivoks> i doubt it's a debate, probably holly war :)
* BenC avoids counter-productive debates
<pina> not a debate actually
<pina> its a summary acutally what the author thinks of the two
<bubbasucks> i thought holly wars only happened at Christmas time
<pina> http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php
<kylem> we don't care.
<bubbasucks> BenC: is that the right info?
<ivoks> pina: it's a personal opinion (i didn't read it, but "Conclusions" say: "Why do I run BSD?" and "Why Should you run BSD?", ending with "The End" chapters tell me that :)
<BenC> bubbasucks: Yeah, checking things
<bubbasucks> k
<pina> ivoks: precisely
<pina> :D
<BenC> "I run Linux because my job depends on it" is my clear response
<kylem> "I run Linux because it sucks less."
<ivoks> right
<pina> the technical report is what struck me as weird
<ivoks> well, this guy runs BSD cause "It Just Works.". I doubt that, but that's only me :D
<pina> he supports bsd there
<pina> hah
<BenC> well, I haven't seen it personally, but I've heard that BSD wireless stack smokes Linux
<pina> woah
<bubbasucks> if i didn't know ubuntu kernel devs, i'd be running windows
<kylem> BenC, it's a lot easier to do better when you don't need to ask anyones permission to commit code.
<zul> kylem: what? it doesnt give you a warm fuzzy feeling
<bubbasucks> or buy a mac pro
<pina> BenC: where did ytou read that about the wireless stack?
<BenC> kylem: or have 50 people doing different implementations? :)
<BenC> pina: On the linux wireless list, from a linux wireless kernel dev
<ivoks> wifi stack is better, i've herd it too
<pina> news to me
<kylem> BenC, they also don't support WPA or a myriad of other things.
<BenC> I'm not saying the actual BSD wireless drivers are better or worse, just that the core stack has got things we don't, like consistency
<kylem> dscape ftw.
<BenC> dscape is supposed to be our savior
<BenC> along with cfg80211 and other things
<BenC> kylem, pkl_: BTW, I might move the meeting back an hour or two to accommodate Tim's timezone
<kylem> sure.
<BenC> s/back/ahead/
<ivoks> ubuntu-dapper is correct git?
<ivoks> or -updates?
<kylem> for backporting 3ware? any of them will do.
<ivoks> there's no much backporting :)
<ivoks> 3ware provides .c and .h for 2.6.15 :)
<fabbione> BenC, kylem: 83412 at your will :P
<BenC> fabbione: Is it sparc specific?
<kylem> it's a compat bug.
<kylem> upstream bug.
<fabbione> kylem: yes.. sparc specific
<fabbione> BenC: ^^
<BenC> so it is 32-bit/64-bit :P
<BenC> probably affects ppc64 too
<fabbione> BenC: you still get the bug with 64bit userland
<BenC> Can you show me the test case again?
<fabbione> it's all in the bug...
<fabbione> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/83412
<BenC> Ok, checking
<fabbione> cheers dude
<BenC> fabbione: passes on ppc64, so it's sparc specific for sure
<BenC> I'll get the e3k booted in a bit
<fabbione> BenC: yeah check the code.. it might as well be a bug in the testcase
<fabbione> there are some ifdefined powerpc*
<kylem> hum.
<BenC> pre-built test cases...sort of dumb
<kylem> it probably is
<BenC> fabbione: You tried recompiling the test case with current feisty toolchain?
<kylem> we needed to patch shmt*.c for hppa...
<kylem> check shmt09.c for __sparc{_,_v9_}_ defines, if there's none, it's most likely a bug in ltp.
<BenC> shouldn't shmt* not need special casing?
<kylem> no.
<kylem> shm are very arch dependant.
<BenC> sounds like a flawed test :)
<kylem> no, it's the syscalls...
<fabbione> BenC: yes
<fabbione> BenC:  i did also rebuild the very latest tarball
<kylem> think about coherency on a VI cache.
<BenC> is it syscall numbering that's the problem?
<kylem> BenC, no. the design of posix shared memory.
<BenC> lol, posix
<kylem> i'll put my money on ltp bug.
<bubbasucks> bugs bugs
<bubbasucks> BenC: any suggestions?
<BenC> bubbasucks: still trying to check the id's
<BenC> mixed in with a dozen other things :)
<bubbasucks> yeah, i haven't quite got multitasking down myself
<bubbasucks> i got a billion things going on at work; a majority of them simply get auto-archived and never seen again
<jwest--> :)
<zul> gah...2.6.19.3 has been released
<jwest--> and reiserfs is borked on it
<zul> eh?
<jwest--> yeah
<kylem> From: Davis <oxrcevkwjd@boomerangengineering.com.au>
<kylem> Subject: The kernel and C library have become that
* kylem sighs.
<kylem> spam is getting clever.
<mjg59> Yes
<bubbasucks> but the from address's aren't
<bubbasucks> BenC: any suggestions?
<Nafallo> who uses reiserfs anyway? :-)
<Nafallo> woha. only ~2h30m after :-P
<jwest--> freebsd's kernel queues are more efficiently to a variety of asynchronous stuffs than linux?
<ivoks> again bsd :)
<jwest--> where
<jwest--> ok sorry
<jwest--> just wondering thats all
<ivoks> we had a conclusion about linux vs bsd
<jwest--> ok
<ivoks> linux is better cause our jobs depend on it
<ivoks> :)
<jwest--> haha
<jwest--> fair enough
<jwest--> you see i'm a kernel person, all that interests me is where and how far linux has gone with it
<ivoks> i'm not kernel person, i
<ivoks> i'm here just buging kernel people to include drivers i need for my servers :D
<jwest--> lol
<Nafallo> hi Scott!
<Nafallo> how's life? :-)
<jwest--> ok weird freebsd does a much better job with asynchronous then Linux does
<Keybuk> life is good
<Nafallo> that's nice :-).
<Nafallo> Keybuk: does that mean you are going to talk on lugradio anytime soon? :-)
<Keybuk> heh, you'd have to ask jono or mrevell :p
<Nafallo> if you have anything to talk about I will ;-)
#ubuntu-kernel 2007-02-06
<hed> quit
<lifeless> BenC: are you aware of cpufreq problems ? mine has stopped frequing
<BenC> lifeless: I know of an issue, yes
<BenC> I thought acpi-cpufreq took over all the CPU's the centrino-speedstep took care of, but it doesn't
<BenC> so I need to re-enable it
<zul> hey
<BenC> hey
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-6.11 - Things are getting solid now. Use it, but there are still a few missing modules.
<zul> heheh...crystal ball..
<zul> hey fabbione 
<fabbione> hi zul 
<bubbasucks> fabbione: yo
<fabbione> bubbasucks: hey
<bubbasucks> BenC: anything i should try? 
<fabbione> bubbasucks: i dunno...
<fabbione> bubbasucks: i think ben is the only one that can help now
<zul> sweet kqemu has been released under the gpl
<pmjdebruijn> indeed, very cool
<jwest--> sweet
<cjwatson> ioctl(5, FBIOPUT_VSCREENINFO, 0x7fffe749a670) = -1 ENOMEM (Cannot allocate memory)
<cjwatson> Any idea why that might be happening? I've been tracing through the fb_ioctl code path and can't find anywhere that could return ENOMEM
<cjwatson> FWIW the fb backend in use is vga16fb
<mjg59> cjwatson: I suspect the check_var function
<cjwatson> oh, hmm, I was looking at upstream source rather than ours
<cjwatson> mjg59: yeah, upstream check_var doesn't seem to ever return ENOMEM, but ours can
<mjg59> Hm. I'm sure I didn't write that.
<cjwatson> looks like making sure xres_virtual == xres and yres_virtual == yres would fix it
<mjg59> What are you actually trying to do?
<cjwatson> fix a usplash crash
<mjg59> Ah
<mjg59> Though we don't use vga16 for anything usplashy now
<cjwatson> we still do on amd64
<cjwatson> and yes, I know I'm getting rid of that
<cjwatson> but I'm trying to fix everything I come across before I make it go away
<mjg59> Heh. Ok.
<cjwatson> in case it bites us sometime in the future
<Keybuk> random question; do people run i386 or amd64 on Core 2?
<mjg59> I run amd64
<mjg59> I know some people run i386
<cjwatson> hmm, no, that doesn't fix it
<cjwatson> I guess vga16fb just can't do big resolutions
<cjwatson> which would make a certain amount of sense
<mjg59> cjwatson: That check is upstream
<mjg59> What codebase are you looking at?
<cjwatson> oh, my linux-2.6.git is out of date then
<mjg59> And yeah, vga16fb can't do anything other than 640x400/640x480
<mjg59> You can conceivably force it into lower resolutions, but certainly not really anything higher
<cjwatson> the maxmem it sets is a heck of a lot smaller than that
<cjwatson> it's at most 65536, and requires xres * yres < maxmem
<mjg59> In 16 colours only
<cjwatson> <=
<cjwatson> 256 too, in the tree I've got ...
<mjg59> No, that doesn't work
<mjg59> Not in any sane way, anyway
<cjwatson> ok, but I mean the check would apply to that if it worked
<mjg59> I don't think we've ever expected modesetting to work with vga16fb
<mjg59> But it comes up in 640x480x16
<cjwatson> maybe usplash should behave more gracefully if it can't do the mode-set
<mjg59> I thought it was supposed to handle that already?
<mjg59> That's why it returns the mode it set, rather than just assuming it got hte right one
<cjwatson> this is probably code I added
<cjwatson> it worked better elsewhere :-/
<cjwatson> I think it was part of teaching the bogl backend how to set resolution
<mjg59> Ah
<mjg59> Right
<cjwatson> I didn't realise that that would fail on some fb backends
<mjg59> Well, vesafb is an obvious example
<mjg59> You can't set modes at all
<cjwatson> perfect, usplash/amd64 resurrected
<cjwatson> will upload the bits llater
<cjwatson> later
<kylem> argh, muppets.
<zul> hmm?
<kylem> people are such god damned muppets. can they not understand the word ATTACH
<zul> hehe
<BenC> kylem: I asked lp to maybe do something like "You are trying to create a 9000 line comment...create attachment instead?"
<kylem> haha.
<kylem> Fuckwit Detector 9000
<BenC> the lack of monospace alone makes dmesg in comment crappy
<kylem> indeed.
<BenC> and don't get me started on lspci in comments :/
* kylem needs to beg for a dual quad-core machine. these build take ages.
<kylem> BenC, this one was lspci -vvxxx and -vvvv
<BenC> ugly
<fabbione> BenC: i know you asked an email.. but can you pull from the gfs2 nmw tree please? pretty please?
* fabbione does a very sweet look at  BenC 
<BenC> hehe
<BenC> what's the gfs2 repo URL?
<BenC> fabbione: ^^
<fabbione> http://hera.kernel.org/git/?p=linux/kernel/git/steve/gfs2-2.6-nmw.git;a=summary
<BenC> fabbione: Pulled
<fabbione> BenC: great.. thanks
<fabbione> BenC: i will give you GFS1 sometimes next week
<fabbione> so i can test both of them properly
<fabbione> be aware tho that GFS2 is getting tons of bug fixes because they are in a hurry to release with RHEL 5
<fabbione> so we might have to pull from them again
<lifeless> BenC: please let me know when cpufreq is back ... this machine is sooo sllooow pinned at 600Mhz
<BenC> ok
<lifeless> OTOH my battery life on the flight was awesome ;)
<bubbasucks> BenC: can i bug you some more?  just wondering what your ID search came up with
<jwest--> anything new
<jwest--> :D
<jwest--> so things are solid with 2.6.20-6.11?
<jwest--> :P
<lamont> why does 2.6.17-10-server hate my AIC-7902 U320 so much?
<lamont> about once a month, scsi goes belly up, and disk I/O starts getting EIO
<lamont> recovery is to reboot
<jwest--> linux I/O scalability issues again?
<lamont> dunno
#ubuntu-kernel 2007-02-07
<kylem> crimsun, ping
<BenC> kylem: Hey
<BenC> kylem: You busted acx :)
<kylem> eh?
<BenC> wait, I misread the diff
<BenC> I thought it lost the firmware_ver stuff
<kylem> i'm pretty sure it's ok
<kylem> i test bilt it
<BenC> but loading it would have been the problem
<BenC> the firmware_ver stuff was all custom code I added a while back to make it easier to change to a different firmware
<kylem> heh, i read through the diff too
<kylem> hmm, this alsa-firmware thing is confusing.
<BenC> was the firmware_ver merged upstream?
<BenC> kylem: FYI, debian/commit-templates/external-driver for new drivers
<kylem> no clue, i just read through the patch.
<kylem> BenC, eh? that's what i did.
<kylem> git commit -a -e -F debian/..
<BenC> damn, am I losing it or what
<kylem> get some sleep, hehe
<BenC> remind me not to review commits on 4 hours of sleep
<zul> i hear beer helps
<kylem> as long as it isn't a bad bear.
<zul> i was thinking kieths
<kylem> nm. inside joke.
<zul> meh..
<kylem> BenC, i thought the only removed firmware stuff was some legacy crap
<BenC> kylem: in acx? Yeah, some ancient shit
<kylem> hehe
<zul> remind me never to read the forums please
<BenC> I've managed to stay away from the forums
<zul> someone was spreading disinformation..
<BenC> misinformation on a public internet forum? Say it ain't so :)
<zul> i know!
<BenC> Next you'll be telling me Slashdot doesn't have trolls
<zul> hehe
<ajmitch> but the ubuntu forums are different! they're *official*!
<kylem> officially full of muppets.
<zul> night folks..
* kylem can't figure out where some of this alsa firmware is hiding.
<kylem> some of it is actually GPL and provides src.
<kylem> BenC, sounds good to me.
<BenC> $ file ubuntu/net/atl1/atl1_main.c 
<BenC> ubuntu/net/atl1/atl1_main.c: HTML document text
* BenC looks at kyle
<BenC> kylem: You sure you test compiled the HTML in the atl1 driver directory? :)
<kylem> uh. oops.
<BenC> 4 of them
<kylem> yeah, i clearly wget'd the wrong thing. shit.
<kylem> BenC, probably forgot to turn the option on.
<kylem> sigh. fucking kernel.org gitweb breaking my workflow.
<kylem> so, why did 3 of them work... weird
<BenC> heh
<kylem> christ. fucking kernel.org is so fucked.
<BenC> I'm uploading a new lrm tonight, but I'm delaying the kernel upload till after our bug day tomorrow, plus so I can merge some VMI patches
<kylem> fixed.
<kylem> will push in a second.
<lifeless> is the past tense wgot ?
<kylem> wifuckedup
<crimsun> kylem: pong
<kylem> crimsun, what's the deal with these alsa-firmware bits?
<kylem> i notice some of them are actually GPL and stuff, but i can't figure out where they're hiding
<crimsun> kylem: the ones in the upstream tarball of the same name or the source package on REVU [revu.tauware.de] ?
<kylem> the former.
<kylem> ah, i see.
<kylem> i didn't think to look in revu, thanks.
<TheMuso> c
<zul> guys, im just going through the linux-meta bugs and assigning them to the right component
<CyberSnooP> I'm getting a kernel Oops when booting herd 3 desktop cd. Anyone who can help me making a useful report out of it?
<zul> CyberSnooP: if you have a digital camera, open a bug report in launchpad and attach it to the bug report.
<CyberSnooP> well. It continues booting after the oops.
<CyberSnooP> I'm trying to get the dmesg output transferred to somewhere I can make a bug report from
<zul> dmesg > dmesg.txt and copy the dmesg.txt somewhere
<CyberSnooP> done so. Are there any hints on searching for previous reported bugs?
<CyberSnooP> well. there seem to be only 3 bugs (!!) in feisty. Searching by hand isn't that hard, or I just don't understand launchpad yet
<pkl_> BenC: ping
<CyberSnooP> ah.. well, if anyone cares: found the relevant bug (#76294), but that tells me to use a newer linux-restricted-modules, which I guess is pretty hard on a CD :(
<pkl_> the atheros bug?
<CyberSnooP> yep
<CyberSnooP> Could it be affecting the installation also? (since the installer also hangs on hardware detection)
<pkl_> kernel oopses often do random nasty things to the kernel, and so it could affect the installation yes.
<CyberSnooP> Are new 'nightly' desktop CDs up to date? Is it worth burning one of them an trying installation again?
<BenC> pkl_: yo
* ..[topic/#ubuntu-kernel:BenC] : BUG DAY!! | Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-6.11 - Things are getting solid now. Use it, but there are still a few missing modules.
<pkl_> BenC: hi, ready for the bug tutorial?
<BenC> yeah
<BenC> kylem: done coding HTML to help with bugs? :)
<kylem> heh
<cjwatson> CyberSnooP: don't use /feisty/+bugs or similar
<cjwatson> CyberSnooP: that doesn't mean what you think it means :) kernel bugs in feisty are on /ubuntu/+source/linux-source-2.6.20/+bugs
<cjwatson> CyberSnooP: hang on hardware detection> try booting with hw-detect/start_pcmcia=false; that was in the Herd 3 release notes
<CyberSnooP> cjwatson: sorry for the wrong bug report lookup, but I finally found the right set of bugs an found a exisiting bug report (atheros oops)
<BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bugs
<BenC> CyberSnooP: atheros oops should be fixed in latest lrm
<CyberSnooP> cjwatson: will try with special boot options, thanks for that hint :)
<kylem> can we blacklist modules from the kernel cmdline?
<BenC> Not in Herd3 though
<BenC> kylem: I wish
<kylem> shouldnt be hard to add...
<CyberSnooP> BenC: Yep, but I'm trying herd 3, so that doesn't really help right now :)
<BenC> CyberSnooP: Daily iso's
<BenC> 185 bugs in 2.6.20
<BenC> is there no sorting!?
<BenC> "kernel oops while installing win 2k sp2"
<BenC> heh, that looks funny
<zul> BenC: which one is that?
<pkl_> first things, how do you get a listing of all bugs in 2.6.20?
<BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bugs
<BenC> We need to start with bugs who's Status is !Unconfirmed
<BenC> check if we have any patches we can apply immediately
<BenC> 36885 is something we can fix with a dmi match entry
<BenC> kylem, pkl_: either of you know how to add dmi match for nolapic forcing, or should I do it real quick?
<CyberSnooP> BenC: can't find hw-detect/start_pcmcia=false in Release Notes (http://www.ubuntu.com/testing/herd3) but I wlil try it anyway. Is there anything usefull to report about the hw-detect hang (althought this probably isn't -kernel talk anymore)
<kylem> BenC, i can do that.
<kylem> i'll try to not write it in htm.
<kylem> l
<CyberSnooP> (note: I'm installer hang right now)
<BenC> kylem: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/36885 assigned to you then
<BenC> kylem: hehe
<pkl_> 36885 is confirmed...
<fabbione> BenC: or add a debian/rules to strip html at build time :)
<kylem> i've been doing some thinking, we need to sit down with colin and mdz at some point and think about how we're going to handle dapper.
<fabbione> even better.. patch gcc :)
<BenC> kylem: Good topic for next summit
<BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/64308
<kylem> i have a few patches that really should make it into stable, but it's kind of scary to think about, so i'd rather have two kernels, one which might actually propogate to -updates.
<BenC> looks like another dmi match entry
<BenC> kylem: We can't propagate to updates
<kylem> BenC, ? why not?
<zul> BenC: im just cleaning up linux-meta as well
<BenC> not because I don't want to, but because it's a real ugly issue with -security and -updates syncing
<kylem> ah.
<kylem> lazy archive admins, gotcha. 8)
<BenC> I was warned by adam that doing it would be the same as the ghost busters cross streams
<kylem> BenC, mind going through bug targetting in a bit?
<BenC> sure
<kylem> BenC, hey, don't forget, they crossed the streams to defeat zul...
<BenC> lol...so Chuck will die if we upload kernels to -updates
* kylem signs some packages.
* BenC ponders that one for a moment
<kylem> ;-P
<cjwatson> CyberSnooP: the release announcement had it (https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-February/000243.html)
<kylem> i do ever so much hate xen...
<zul> meh..
<zul> kylem: whats wrong now?
<kylem> zul, nothing.
<kylem> zul, just teasing.
* zul develops a complex
<BenC> pkl_: want to try your hand at a dmi match for disabling acpi-video on a particular bit of hw?
<mjg59> BenC: What was the reason for that?
<CyberSnooP> cjwatson: okay, but that says "5 minutes" and the alternate cd. I'm having a >5 minutes hang on the desktop one
<cjwatson> ah, probably not much you can do to avoid it short of grotty expert hacking
<pkl_> BenC: I can try, but dmi match means nothing to me...
<kylem> pkl_, it's basically like a pci id, but for the acpi bios, i guess.
<kylem> pkl_, works more or less like a pci quirk
<mjg59> kylem: Eh. Not quite - it's not anything to do with acpi
<CyberSnooP> cjwatson: It says it's loading 'aec62xx' and since I can't find a bugreport for that I was wondering if there is anything to report
<kylem> mjg59, ah, i just associate dmi with acpi, what's the diff?
<mjg59> pkl_: DMI is a spec for putting system information in the BIOS, including vendor and product strings
<kylem> oh. DMI is for SMBIOS?
<cjwatson> CyberSnooP: you sure that's the desktop CD? I wouldn't expect that level of information to be visible on the desktop CD
<cjwatson> CyberSnooP: what does the screen look like? blue with a white box in the middle?
<CyberSnooP> cjwatson: nope :) It's ubiquity with the GTK progess bar and a line below
<mjg59> pkl_: When all else fails, you can break drivers so they don't do something on machines with a given DMI ID
<CyberSnooP> However, I picked the dutch translation
<cjwatson> CyberSnooP: oh, I see, OK. same boot option is worth a try then
<BenC> pkl_: Basically you create a table of stuff to match a specific machine type based on it's dmidecode output
<mjg59> In some cases, it's appropriate - in others, it's arguably better to figure out why the machine is breaking
<CyberSnooP> okay, will do. Nothing to catch while it's hanging now?
<BenC> pkl_: drivers/acpi/sleep/main.c: Look for acpisleep_dmi_table
<pkl_> is this dmi match stuff already done in Ubuntu, and so there's a framework to look at to start from?
<pkl_> ah, ok.
<BenC> pkl_: Use that same logic to make the drivers/acpi/video.c driver not work for the machine in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/64308
<BenC> There's an attachment with dmidecode output
<pkl_> ok.
<mjg59> BenC: Uh, in future we're going to be moving to depending on more functionality provided by that driver
<mjg59> I'd prefer to spend a bit more time trying to debug it
<heno> Am I right in guessing that bug 80892 is a kernel bug or is that a brltty bug? the log says 'kernel: [  138.396000]  usb 3-1: USB disconnect, address 3' right after brltty tries to mount a USB device
<mjg59> BenC: Also, I can't actually see ACPI code being executed on modprobe, which leaves me a little concerned about why this is happening
<mjg59> Oh, I see
<cjwatson> CyberSnooP: well, you could look at 'ps ax' from a terminal to see what it's doing
<BenC> mjg59: Do you think it's fixable? I'm happy just disabling for feisty...it's a long standing bug
<cjwatson> CyberSnooP: could be unrelated to the pcmcia thing
<BenC> for that machine I mean
<CyberSnooP> cjwatson: sorry, you just missed it by 1 minute.. rebooting with new kernel option now. Will find out if pcmcia was the problem in about 30 minutes I guess :)
<cjwatson> CyberSnooP: *nod*
<mjg59> BenC: No idea. I've asked for more information.
<mjg59> BenC: The bugs marked as duplicates are entirely unrelated
<mjg59> I've de-duped them.
<BenC> mjg59: It sounds an aweful lot like a BIOS bug to me, but if you think it might be fixable, then have at it
<BenC> pkl_: dequeue that bug for now :)
<pkl_> hmm, ok, in the middle of reading the code.
<kylem> if there's only one thing this job is good for, it's touching parts of the kernel you would never, ever, otherwise touch.
<BenC> pkl_: Feel free to study the dmi match stuff...it's useful for workarounds like this
<kylem> like, why the fuck would i ever want to look at mmc... but yesterday...
<pkl_> yeah
<BenC> kylem: Yeah, like I gave up HTML coding a decade ago, but then yesterday... :)
<kylem> BenC, ferfuckssake.
<kylem> ;-)
* BenC wont let that one go for awhile
<mjg59> BenC: Oh, it's quite possible that it's a BIOS bug
<mjg59> But that doesn't mean it's unfixable
<BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/67810
<BenC> bug 67810
<BenC> can we get ubugtu in here?
<BenC> who maintains that bot?
<zul> seveas i think
<BenBugtu> 67810: bad hard disk noise on shutdown
<BenC> there, now I get warm fuzzies
<BenC> Anyone have any comments on that bug? Seems like upstream is ignoring it
<mjg59> I suspect just checking through the libata shutdown code would give a good idea about what's going on
<BenC> and the comments on it have digressed a lot
<mjg59> Yeah, we're not going to get anything useful out of the bug
<kylem> hehe.
<kylem> do we have the acpi ata driver in .20, hmm....
<BenC> "Does OpenSuse have a net-install..."
<kylem> BenC, oh yeah, i got that bug and was like "plonk"
<BenC> mjg59: Is there a working libata-acpi.c for 2.6.20?
<kylem> the blind, lead by the deaf, lead by the dumb.
<BenC> is that from libata-dev git?
<kylem> BenC, alan posted it the other day.
<BenC> kylem: "I see, said the blind man to the deaf man"
<kylem> might be a useful fallback.
<kylem> ICUP
<BenC> I'm waiting for the bug report that says "If I tap three times on the left side of my box, it works...can you code this workaround into the next kernel"
<bubbasucks> BenC: can i bug you real quick? just wondering what your ID search came up with
<BenC> "FIxed...included kick-box.ko, just use the tap=left-side, count=3 modparams"
<BenC> bubbasucks: I found nothing useful
<bubbasucks> so the pci ids were in megaraid_mm ?
<BenC> In megaraid_mbox
<bubbasucks> ok
<mjg59> BenC: Yeah
<bubbasucks> i'll try just including megaraid_mbox in initramfs
<bubbasucks> and take megaraid out
<mjg59> kylem: Nah, that's pata_acpi
<kylem> ah.
<mjg59> kylem: Which is different - it's actually a full pata driver
<mjg59> It just uses acpi to get resource information
<mjg59> So it's better than pata_generic
<zul> BenC: if you click your heels three times does it work?
<BenC> mjg59: Does it supercede libata-acpi?
<mjg59> No
<mjg59> Entirely different
<mjg59> libata-acpi provides acpi glue for libata
<BenC> Do we need libata-acpi in feisty?
<mjg59> pata_acpi is a driver
<mjg59> Yes
<BenC> where's it at?
<mjg59> lkml right now
<mjg59> It's not terribly important
<mjg59> Or libata-acpi? There's a branch of libata with it
<BenC> Ok
<BenC> Moving on to 74059: ata2 timeouts, fails to boot
<pkl_> BTW as a total aside, how long do people spend reading lkml?  I've not had time to look at it once this week.
<zul> i try to do it everyday
<zul> ...but thats just me
<CyberSnooP> cjwatson: I guess it's not pcmcia, the kernel boot option didn't help and ubiquity is hanging on "Module 'aec62xx' for 'IDE chipset support' is being loaded...'
<BenC> pkl_: I scan subjects...rarely do I read content unless it's interesting
<pkl_> yes, I like skimming it.  Pity kernel-traffic disappeared, that was a good way to catch up.
<CyberSnooP> pkl_: lwn is somewhat a replacement for kernel updates
<pkl_> is the openSuse comments of any relevance?  I notice 'More' didn't respond regarding the driver loaded
<pkl_> CyberSnooP: lwn is a sort of replacement, but is mainly complemented kernel-traffic.  Lwn concentrates on one or more selected kernel topics per week in depth, kernel-traffic just summarised all the traffic that week...
<BenC> Ok, pulled in libata-dev:acpi
<CyberSnooP> pkl_: that's true. Just stay subscribed to kt-distrib@... maybe they'll be back sometime :) 
<zul> BenC: #79331 our 2.6.20 supports rt73 now does it?
<BenC> zul: I'm a little skeptical...we actually should have always supported it, but now I've switched back to legacy
<CyberSnooP> someone here in the mood for determining why hw-detect stops on aec26xx? (I've got a hanging installation from herd 3 right now)
<zul> BenC: so ill reject it
<BenC> CyberSnooP: I can't even find that driver
<CyberSnooP> oh, sorry.. aec62xx
<CyberSnooP> at least, that's what is reported as the module name
<BenC> That module I can find :)
<BenC> CyberSnooP: Are you able to switch to the log console when it freezes, tried SysRq?
<CyberSnooP> it doesn't freeze and desktop is still usuable
<BenC> CyberSnooP: Maybe before it gets to that point you can delete that module from /lib/modules/...
<CyberSnooP> there is just no progress
<cjwatson> hang on, is it just the installer that hangs? or the entire system?
<CyberSnooP> so: just installer is dead. I do see 4 "modprobe" processes on "ps ax" output in terminal window
<cjwatson> modprobing what?
<BenC> so modprobe is hanging
<BenC> cjwatson: We need to donate some hardware to kernel.org or something
<BenC> gitweb is so useless
<CyberSnooP> hmm, i see even more modprobing going on. Lot's of modprobe -Q pci:.... and a modprobe -v aec62xx
<BenC> CyberSnooP: Can you list all the modules that you see being modprobed in ps?
<BenC> Maybe we could rsync all the git trees and provide a mirror
<CyberSnooP> BenC, will try.. pity there is no irc-client on the live cd, copy & pasting would have been nice now
<cjwatson> there's gaim, though it's not great
<BenC> CyberSnooP: telnet :P
<cjwatson> or you can just install one on the fly
<CyberSnooP> http://bram.vleur.nl/tijdelijk/ps-ax.txt
<CyberSnooP> scp does work :)
<cjwatson> that D-state modprobe doesn't look happy
<CyberSnooP> ah. D = Uninterruptible sleep  (usually IO). (didn't know that)
<BenC> kylem, pkl_: On to 75626: spurious 8259 interrupt disabled IRQ
* kylem sighs. it would be really nice if bugs.launchpad.net/# DTRT
<cjwatson> kylem: launchpad.net/bugs/#
<kylem> cjwatson, yeah, but i'm used to typing bugs. (for bts.)
<CyberSnooP> cjwatson: any other info that might be of any use?
<pkl_> isn't problems like that due to wrong DSDT tables?
<jwest-> anyone using vmware here? vmware by default installs scsci drives right?
<BenC> CyberSnooP: dmesg if you can
<jwest-> had an issue and i just booted scsi.s kernel  and bam it worked
<CyberSnooP> http://bram.vleur.nl/tijdelijk/dmesg.txt
<CyberSnooP> which looks like a dmess to me 
<BenC> CyberSnooP: wow, that's an ugly mess
<BenC> CyberSnooP: Do you have some whacked partition map or something on there?
<CyberSnooP> nope.. hda1 hda2 both ntfs, hda5 ext3 for root, hda 6 for swap
<CyberSnooP> fdisk -l /dev/hda output: http://bram.vleur.nl/tijdelijk/fdisk-l.txt
<BenC> The system keeps saying it's trying to read beyond the end of the device
<CyberSnooP> well, I do see the "does not end on cylinder boundary" warning for the first time (although they may have been here for quite some time)
<mjg59> BenC: We still have no HPA support for libata, BTW
<mjg59> That's pretty critical
<BenC> CyberSnooP: your partition map doesn't match what the kernel sees
<BenC> mjg59: Can you point me to where that is?
<CyberSnooP> well, I didn't repartition with the installer. I'm reinstalling from an (old) edgy installation on the same harddisk
<mjg59> BenC: Unimplemented
<CyberSnooP> (i didn't repartition at all in the mean time)
<BenC> CyberSnooP: weird...so this is a regression?
<mjg59> BenC: See idedisk_check_hpa in drivers/ide/ide-disk.c
<CyberSnooP> I would guess so. At least dapper installed cleanly on the same laptop, although I'm not really sure if it was exactly the same partitioning
<BenC> mjg59: Isn't this why you were suggesting we didn't switch to pata yet? :)
<mjg59> BenC: Probably
<BenC> I didn't actually switch that many
<mjg59> CyberSnooP: Oh, uh. You might actually be hitting this precise issue.
<CyberSnooP> (i did dist-upgrade from dapper to edgy, but since feisty wasn't booting I decided to go for the re-install.. there you have the woll story)
<BenC> mjg59: He can't be, he's still using an ide driver
<mjg59> Oh, right
<mjg59> Yeah, fair enough
<BenC> CyberSnooP: Where does feisty stop booting?
<CyberSnooP> after dist-upgrade
<CyberSnooP> It's a different problem I guess, since it didn't boot X
<CyberSnooP> I messed a lot with drivers, mesa and stuff during edgy
<BenC> so it booted, just didn't start X?
<BenC> cjwatson: Is there a way to drop to shell before livecd gets to starting up too much?
<CyberSnooP> yeah, sorry about the confusion. It did boot. although I'm not sure which kernel I last used
<CyberSnooP> (might have been 2.6.19)
<BenC> pkl_: Want to investigate #76489?
<BenC> Maybe there's some update to the r8169 driver...I'm leaning toward thinking it's an locking issue triggered because we have SMP by default
<pkl_> just let me have a loot at it...
<cjwatson> BenC: break=top? (or premount, or casper-bottom, or ...)
<BenC> maybe there's an updated driver somewhere
<BenC> CyberSnooP: Can you try booting with cjwatson's suggested cmdline and delete the aec62xx driver, then let the boot continue?
<BenC> see if that gets you through this, then we can investigate the problem afterwards
<CyberSnooP> suggested: break=top ?
<BenC> yeah, try that one
<BenC> loading aec62xx on my box doesn't produce a hang or errors
<CyberSnooP> well, break=top throuws me in a busybox with "(initramfs)" prompt
<maks_> how surprising :)
<CyberSnooP> but I'm not quite sure where the aec26xx module should be right now
<CyberSnooP> not in /lib/modules/2.6.20-6-generic 
<pkl_> BenC: I'll have a look at it.  What was the resolution re: bug no. 75626 (spurious 8259....)?
<CyberSnooP> oh  sorry, it is there
<bubbasucks> BenC: is the megaraid_mbox.c file online or available because i looked in 2.6.17 megaraid_mbox.c here (http://www.gelato.unsw.edu.au/lxr/source/drivers/scsi/megaraid/megaraid_mbox.c) and didnt see 101e 1960 1028 0511
<CyberSnooP> I found /lib/modules/2.6.20-6-generic/kernel/drivers/ide/pci/aec62xx.ko Just remove that file and it shouldn't complain further on?
<mjg59> What's loading that file?
<mjg59> BenC: I'll open a bug on the HPA issue
<BenC> CyberSnooP: that's what I'm hoping :)
<BenC> bubbasucks: gitweb on kernel.org, ubuntu-2.6 tree
<BenC> if you can get it to answer
<CyberSnooP> We'll find out.. (in 30 minutes :( )
<cjwatson> BenC: driver-backports ping?
<BenC> cjwatson: working on it while I'm doing bugs :)
<CyberSnooP> side-note: the new partitioner has gone crazy on me now
<BenC> There's something whacked about your partition map
<CyberSnooP> yeah, but this is an UI error i think
<BenC> Ah, ok, blame cjwatson then :)
<CyberSnooP> both the OK and Cancel buttons in the  "Edit partition" dialog stopped responding
<CyberSnooP> I'm getting to fast at using it after 6 install attempts
<BenC> Give it a second, sometimes there's lag after clicking it
<CyberSnooP> I gave it 90 seconds now
<CyberSnooP> killed all ubiquity, starting over now.. I'll try to be nice to the buttons
<bubbasucks> BenC: k
<cjwatson> CyberSnooP: ubiquity --debug and file a bug with /var/log/installer/debug, /var/log/syslog, and /var/log/partman attached please; use a password you don't care about in debug mode
<CyberSnooP> cjwatson: will do some other time I guess. It seems like some kind of race when I quickly hit the format checkbox and open the edit dialog
<CyberSnooP> cjwatson: besides this error the new partitioner is very nice though! Pretty usuable, quick, and to the point. 
<cjwatson> aha, I can fix that
<cjwatson> insufficient locking
<cjwatson> CyberSnooP: off-topic for this channel, but thanks, fixed for the next release
<CyberSnooP> cjwatson: hah... that's what I call "getting things done" :) While we're in this words-of-praise moment: mjg59: nice blog-article on suspend/resume with acpi 
<\sh> guys, what about HP P800 SmartArray SAS/SATA controller and 64bit LBA support in our kernel? I just need some practical experience with it, if it's working or not...a nice to have is a statement "yes, it works, even with a MSA 60 attached to it" or "yes/no, support is a bit flaky" or "no, smartarray driver doesn't support 64bit lba, means partitions greater 2TB" ;-)
<BenC> \sh: How about "I don't know?" :)
<kylem> mjg59, wow. we don't have HPA support yet? fucking hell.
<pkl_> what is _HPA_ support?
<\sh> BenC: then I say "hmmm..who could know" or "who has such a hardware, and runs it" or "ok, I'll google" ;)
<mjg59> Host Protected Area
<mjg59> Drives can flag a portion of themselves as unusable
<kylem> "utter retarded"
<mjg59> And then optionally password that
<mjg59> Unless you explicitly request that they disable that, the disk just appears smaller to the OS
<mjg59> Usually used for hiding recovery areas at the end of the disk
<pkl_> or port :-)
<mjg59> The problem is that at some point in 2.2, somebody added HPA support to Linux
<pkl_> port -> porn... joke
<mjg59> And decided that the sensible default would be to disable it
<mjg59> So people install Linux into the HPA-covered area without ever noticing
<mjg59> We can now never change that default
<mjg59> Except libata doesn't support disabling the HPA
<mjg59> Hilarity ensues
<kylem> fsvo hilarity...
<pkl_> okay, that's how manufacturers get away with supplying machines without Windows reinstall disks....
<kylem> right.
<mjg59> Yeah, it's basically impossible to fuck with it in Windows or DOS
<pkl_> But as Ubuntu does have HPA support, it will happily over-write it on the first instal.
<kylem> hmm. kernel could catch the access past the end of device, disable HPA, and restart the xaction...
<kylem> pkl_, it's only a problem going from edgy->feisty with pata, iirc.
<kylem> since libata for sata disks wouldn't ever have supported it.
<mjg59> Right
<mjg59> Though it would actually be interesting to test
<mjg59> The alternative is that the lack of HPA support somehow magically results in the entire disk being available
<kylem> but drivers/ide did, so when you boot a pata-*.ko system with it, you die horribly.
<mjg59> Though I'm pretty sure that's not the case
<CyberSnooP> aec62xx is still being loaded in hw-detect :'(
<kylem> mjg59, how much work is it to disable? restarting the bio shouldn't be too too hard, i would think.
<mjg59> kylem: Eh, almost none. 
<CyberSnooP> okay, I'm being evil now in the hope to progress somewhat. I've killed the "log-output -t hw-detect modprobe -v aec62xx" process, this however results in alim15x3 being modprobed and ALSO hanging
<CyberSnooP> so this seems to be a more general IDE-driver thing than specifically the aec62xx
<CyberSnooP> (hanging means: process state = D for the modprobe process)
<pkl_> did you check the modprobe -v aec62xx process did die?  It if was in an un-interruptible sleep, then killing it is impossible.
<CyberSnooP> pkl_: it didn't die. But the installer doesn't seem to care about that process
<pkl_> yeah, but the other modules being modprobed might...
<CyberSnooP> it goes on for every ide driver now. I've got 7 state=D modprobes right now
<bubbasucks> BenC: its not in there
<bubbasucks> http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=395174
<bubbasucks> there is a patch to add CERC ATA100 raid i believe
<bubbasucks> but it's not listed in your megaraid_mbox.c
<cjwatson> BenC,mjg59: what happened to the iSight firmware loader bits from mjg59's patch? The rest of it (uvcvideo driver update) seems to have been applied
<BenC> I just took the 0004-isight patch as-is...don't know about anything on top of it
<BenC> bubbasucks: Ok, applied that patch, so it will be in the next kernel upload
<cjwatson> the Apple Remote patch seems to be still missing
<cjwatson> mjg59: any idea of the iSight status? the firmware extractor was really a separate binary so I guess it shouldn't be in the kernel anyway
<cjwatson> ah, Apple Remote went into ubuntu/mactel/
<bubbasucks> BenC: so i'll need to downgrade my firmware to 6.61
<bubbasucks> hope that doesn't blow away my raid config
<mjg59> cjwatson: Uh. Which firmware loader bits?
<mjg59> I moved the firmware-loading in kernel
<cjwatson> mjg59: so you did; I must have an earlier version of the patch
<mjg59> Ah, ok
<mjg59> It still needs the extractor, yeah
<mjg59> I *really should* have an Apple next week
<mjg59> It's taking an age to get through Intel
<BenC> Anyone know if there's a project for rtl818x and rtl8187 that is newer than 1.5 years?
<kylem> BenC, there isn't, afaik.
<kylem> BenC, i think it's a dead-end chipset (no new hw)
<BenC> not dead to our users :/
<bubbasucks> BenC: it appears that CERC raid w/ FW>6.61 is broken in megaraid_mbox, but rolling back to 6.61 breaks disks >128GB
<BenC> I'd ask for a user to donate one of them so I can fix the crash, but then we probably wouldn't have any more users with the card :)
<BenC> bubbasucks: Do you have a disk > 128GB in there?
<bubbasucks> yep
<BenC> The patch doesn't say that > 6.61 is broken, just that if you have problems, try downgrading fw
<bubbasucks> http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/54a1ca21b839ebf1/4a0cd669217f3c7d?lnk=st&rnum=1#4a0cd669217f3c7d
<bubbasucks> http://linuxwarez.us/url/RwU4l9
<bubbasucks> ^ short version
<BenC> Still seems like fw > 6.61 isn't a sure fire problem, just that it might be
<BenC> hopefully it isn't for you :)
<bubbasucks> i'll give it a try
<bubbasucks> when will the next kernel be out?
<bubbasucks> Both Dell and LSI Logic have indicated that they no longer support these 
<bubbasucks> models in the 2.6 kernel. As a result, these adapters are not supported 
<bubbasucks> in Red Hat Enterprise Linux 4.
<bubbasucks> lame
<bubbasucks> time to go back to software raid...
<BenC> kylem: Can you check the work queue fixes in rtl_ieee80211 to see if they may be the cause of the regression in rtl818x (bug 78255)?
<kylem> sure.
<CyberSnooP> Just to let you know: Killing the "log-output modprobe"-processes was sufficient to make it to the end of the installer. Rebooting the installed feisty was hell (>300s) but after an update to today (with new restricted modules) it works perfectly
<BenC> CyberSnooP: Great, thanks
<pkl_> Regarding bug #75626 (Spurious 8259...) there's a bug on the kernel.org bugzilla with a huge number of similar problems with many more HP Pavilion laptops (bugzilla.kernel.org/show_bug.cgi?id=7562).
<kylem> brb. lunch.
<BenC> pkl_: You should be able to link the bug report on launchpad to that kernel.org bugzilla report
<BenC> pkl_: Click on Also affects: "Upstream..."
<pkl_> ok.
<BenC> and point it towards "linux" as the target and add the URL you gave
<BenC> kylem, pkl_: Updated ipw3945 to v1.2.0...might consider it for dapper and edgy
<BenC> requires new microcode as well
<mjg59> BenC: Any chance you can turn on CONFIG_PM_TRACE?
<mjg59> Contrary to what the docs say, the default is no longer to screw up the clock
<mjg59> And it's very handy for tracking down suspend/resume problems
<BenC> Sure
<mjg59> Sweet
<mjg59> Thanks
<BenC> I don't see that option
<mjg59> Might need PM_DEBUG enabled
<mjg59> Ah, yes
<BenC> ah, right
<BenC> mjg59: Want this enabled too?
<BenC>     Keep console(s) enabled during suspend/resume (DANGEROUS) (DISABLE_CONSOLE_SUSPEND) [N/y/?]  (NEW) 
<mjg59> BenC: Leave that at N, I think
<pwnguin> if today's bug day, ive got a pet bug in launchpad; it's got a patch attached and everything, just needs someone to look at it
<pwnguin> bug #77026
<mjg59> BenC: Uh, yeah. Weren't you supposed to be re-applying that?
<BenC> Thought I had that one in there
<pwnguin> well, you "fixed" it
<pwnguin> but it didnt work
<BenC> pwnguin: done
<pwnguin> huzzah
<pwnguin> i'll definately test it when it gets pushed out and report back :)
<BenC> It's pushed to git, but if you're waiting for it to be uploaded, it will probably be available tomorrow some time
<pwnguin> hmm
<pwnguin> im supposed to be doing some kernel development for my master's project
<pwnguin> although i doubt ill have git mastered in before it hits the repo
<BenC> https://wiki.ubuntu.com/KernelGitGuide :)
<pwnguin> noted, though i have a ton of bioinformatics lab to do today =/
<BenC> Why are people still filing bugs on 2.6.19 :/
<pwnguin> as in they don't know better, or as in it affects .19 only?
<zul> BenC: muppets
* ajmitch was still running .19 unti last night :)
<pwnguin> ajmitch: but did you file bugs against it?
<ajmitch> nah, I just couldn't be bothered rebooting
<pwnguin> heh
<pwnguin> my video card fan is too loud for that
<BenC> pwnguin: As in .19 isn't even in ubuntu anymore
<zul> heh...
<zul> not for main at least
<pwnguin> BenC: well, i meant like, they filed against .19 when they were running .20
<pwnguin> for "dont know better"
<BenC> no, they just haven't upgraded in 2 months :)
<pwnguin> well, those are easy ones to close
<pwnguin> "we think its fixed in .20. upgrade and retest"
<pwnguin> kthnxbye
<BenC> kylem: ping 33950
<cberl1> Is there any reason a kernel panic wouldn't leave some kind of log on the system when it appears?  Something strange going on with one of my servers.
<BenC> cberl1: Yeah, because it crashes so hard that disk write is either impossible, or dangerous
<pwnguin> cberl1: hope you have a serial cable / port
<cberl1> Okay, and possible solutions?
<BenC> cberl1: That sort of crash needs a screen to see and you can take a digital photo for a bug report
<cberl1> Ah, now there's the problem:  recreating the issue while having access to the console.  Can I reroute the console to an SSH session?
<BenC> No, else the system would be alive enough to use a shell too :)
<BenC> if you can redirect console to a serial (via the BIOS for example), then that would probably be best
<BenC> leave a screen'd minicom on it with capture enabled
<BenC> I do that frequently for my ultrasparc
<cberl1> Okay, minicom on another machine, I assume?
<pkl_> the machine with the other end of the serial cable...
<cberl1> Okay.  I'll have to dig up such a beast.  Don't have any other PCs available for that at the moment.  Might be able to reclaim one of the "thin clients" temporarily.
<cberl1> xconsole wouldn't work, would it?
<johanbr> I also think there are patches to do the serial console thing over USB or Ethernet instead. Does the Ubuntu kernel contain any of those patches?
<cberl1> xconsole looks like it might do the job for now - just keeping it open on my screen now, watching what's going on.  Quite a bit of traffic when you're the hub for 30 clients, eh?  :)
<kylem> BenC, sorry, my irc was gone completely haywire.
<BenC> kylem: I was going to insert an HTML coding joke here, but I think you've had enough :)
<kylem> heh.
<kylem> BenC, hmm. i think i posted a patch for that a while back, will update. need to repost the smapi stuff eventuall...
#ubuntu-kernel 2007-02-08
<kylem> huh, SLES10 uses 2.6.16
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-6.11 - Things are getting solid now. Use it, but there are still a few missing modules.
<Keybuk> so my machine doesn't actually halt/poweroff/reboot at the end of the shutdown process
<Keybuk> is that my fault or the kernel's?
<snail> Keybuk: "fault" is not the word you're after
<snail> have you googled for your motherboard name and ubuntu? 
<Keybuk> it worked yesterday :p
<mjg59> Keybuk: Kernels
<mjg59> Probably
<mjg59> At least, there's definitely a bug that can trigger that sort of thing
<mjg59> Easiest test is to go single user and then try halt -p
<Keybuk> actually, I think it's my fault
<cjwatson> try booting with reboot=b, too
<cjwatson> if that fixes it, a quirk could be added
<Keybuk> reboot --debug -f works just fine
<Keybuk> so, adding debugging code fixed it
* Keybuk weeps
<Keybuk> I didn't even touch reboot(8)
<Keybuk> it's failing in log_action_msg
<Keybuk> I really don't understand what's broken here
<snail> Keybuk: report it as a bug in launchpad with all the details
<Keybuk> that wouldn't help :p
<snail> Keybuk: it won't help you in the short term, no
<mjg59> snail: You realise keybuk is a senior developer on the Canonical payroll, right?
<cjwatson> snail: Keybuk is the author of the code in question
<cjwatson> at least of reboot(8)
<snail> i had no idea
<snail> sorry, i've been firefighting too long in #ubuntu
<mjg59> If he filed the bug, he'd just need to fix it himself anyway :)
<Keybuk> I frankly wouldn't know what to put in the bug report
<Keybuk> "stuff that worked just fine yesterday, and hasn't been changed, now doesn't"
<Keybuk> "yet is completely repeatable, and if I revert unrelated things, then it works again"
<cjwatson> it's feature freeze; of course stuff is falling over randomly with no reason
<Keybuk> I see you ordered snow especially ;p
* Keybuk rewrote shutdown yesterday ... but all that does is send upstart an event
<Keybuk> so that shouldn't be any different, damnit
<snail> Keybuk: divide and conquer on the unrelated things to find out which is breaking things?
<Keybuk> init: event_finished: Finished runlevel event
<Keybuk> init: event_emit: Pending runlevel/failed event
<Keybuk> ok, now that's interesting
<Keybuk> ok, that's just a bug
<Keybuk> it's because logd "failed" by being killed
<Keybuk> heh
<Keybuk> well, I said it was an unrelated change that broke it
<Keybuk> that's the problem -- logd wasn't running, so log_action_msg was failing
<kylem> morning.
<fabbione> hey kylem 
<BenC> hey hyle
<BenC> err, kyle
<fabbione> hyle = kyle->html ?
<JanC> no, hyle is the wrong spelling for heil...  :)
<kylem> morning.
* BenC is preparing to upload -7.12
<kylem> BenC, what's our plan for updates to the feisty kernel now that we won't be pulling regularly from upstream git?
<BenC> kylem: selective syncs
<BenC> pretty much the core kernel is frozen, but we'll continue to update ubuntu/* drivers as they release 2.6.20 compatible tarballs
<kylem> (i'm thinking about a few things in particular, i've got cxgb merged into ubuntu/ in my tree.)
<kylem> ((and i made sure it wasn't html this time.))
<BenC> hehe
<BenC> yeah, those sorts of things are still good
<fabbione> https://launchpad.net/ubuntu/+bug/83982
<fabbione> ^^ this is interesting
<fabbione> BenC: can you upload that LTP fix directly?
<fabbione> BenC: otherwise i guess i can do it on the fly
<kylem> uh.
<kylem> can we get him to test with a real file.
<kylem> you know, one that isn't a fucking sparse file. idiots.
<kylem> soooo why isn't alsa-firmware in universe...
<crimsun> I'll try to get that through today
<kylem> is here anything i can do to help?
<crimsun> yes, you can review it (i.e., comment), and advocate it for inclusion if you feel it's up to par
<kylem> ok.
<crimsun> (all ubuntu-dev members are already in the keyring; you may need to choose Recover Password to get your REVU password)
<crimsun> it only takes 2 advocates to upload the new package
<kylem> k
<kylem> BenC, did you just do a l-s-2.6.20 upload?
<BenC> kylem: Packaged one, just waiting for test build/boot to finish before uploading
<kylem> k.
<kylem> sorry, using some of the idle meeting cycles to go through my assignedbugs list.
<pwnguin> so its been a long time since i last compiled and installed a kernel. did the make system change a bit?
<kylem> pwnguin, not really, fakeroot debian/rules binary-debs flavours=flav1,flav2 is what i do for test builds when i don't want to wait for debuild...
<pwnguin> i pulled straight from git
<kylem> that'll still work
<pwnguin> so it will
<pwnguin> the flavor is like generic i hope
<kylem> BenC, who should i subscribe to bugs about firmware licensing?
<BenC> me and matt
<BenC> pwnguin: See team link in topic
<BenC> go to knowledge base, there's a doc there on building from git
<pwnguin> what a strange layout
<kylem> remind me to hurt david howells next time i see him.
<kylem> i for got how much i hated this INIT_WORK changes.
<kylem> if i had to guess, this is the problematic line:
<kylem>         ieee->set_chan(ieee->dev,ieee->current_network.channel);
<kylem> kyle@athena:...u-2.6.git/ubuntu/wireless/rtl_ieee80211% vi rtl_ieee80211_softmac.c
<kylem> BenC, this might help, dunno: http://people.ubuntu.com/~kyle/r8180-ieee80211-dev.diff
<mjg59> Hm.
<mjg59> It's kind of tempting to grab a couple more Broadcom cards.
<mjg59> Though the only 4311 I can find is 30
<kylem> eheh. crazy bastard.
<mjg59> kylem: Discussion on the lists makes it look like they're getting a handle on the 4311/2/8 issues
<kylem> nice.
<kylem> about darn time.
<mjg59> Hm. Think I can get Canonical to pay? :)
<BenC> mjg59: Hell, you might get Canonical employees to pay :)
<BenC> kylem: Or maybe just (priv)?
<BenC> kylem: Did we change that bit of code, or is that stock?
<mjg59> BenC: Heh
<mjg59> Looks like total cost would be 45 (or about $10000000000000)
<BenC> kylem: netdev_priv() seems to be duped by rtl_ieee80211_priv()
<BenC> heh
<kylem> BenC, i don't see anything obviously wrong with any of it.
<BenC> kylem: neither did I
<BenC> but it worked in edgy, same code
<BenC> so workqueue is my best guess
<kylem> i had thought the *ieee got corrupted, but it seems not.
<mjg59> Enf.
<mjg59> Someone's presumably going to have to port these to something sensible at some stage
<kylem> hmm?
<mjg59> kylem: Not the hacked rtl-ieee80211
<kylem> oh. right.
<kylem> i swear to god, when i'm fucking supreme dictator of the earth, everyone responsible for the linux wireless mess will be first up against the god damned wall.
<mjg59> kylem: http://cgi.ebay.com/VCTnet-AirXpress-802-11b-WLAN-WiFi-Card-PC11BR_W0QQitemZ290022770466QQihZ019QQcategoryZ74954QQrdZ1QQssPageNameZWD1VQQcmdZViewItem
<mjg59> kylem: That seems to be an rtl8180
<kylem> i need a laptop to put it in too. ;p
<mjg59> Oh man.
<kylem> haha. $9.99 + $30 USD shipping.
<mjg59> Don't you still have the X30?
<kylem> yeah, crashing my work machine every 10 minutes isn't terribly productive ;P
<kylem> christ. so when fedora specs that they want pimping wireless in FC7
<kylem> they really mean "pimping wireless for the shitty in-tree drivers"
<mjg59> Ah
<kylem> at least their wiki is finally unbroken.
<mjg59> Link?
<kylem> http://fedoraproject.org/wiki/Releases/FeatureWirelessFirmware?highlight=%28CategoryFedora7Features%29
<kylem> you'd think with the size of the workforce they have, they could be spending a little time improving this mess.
<BenC> they list bcm43xx..hehe
<kylem> muppetry.
<BenC> bcm43xx firmware is such a lost cause...unless someone at broadcom finally gets a clue
<BenC> "ipw3945, if upstream"
<kylem> BenC, i mailed alan about HPA, waiting to hear back.
<kylem> forgot to cc you and matthew, doh.
<BenC> hopefully it's a nice reply and not a "pata is experimental you twit" reply :)
<kylem> fedora is moving to libata-pata too...
<BenC> or even worse "it's working in -mm, but you need all of libata-dev to use it"
<kylem> i've looked...
<kylem> nothing annoys me more than people who constantly merge their patch work git trees
<kylem> so you have to pull the tree and diff versus linus to find all their changes instead of just looking at recent things in shortlog.
<mjg59> BenC: There's a patch that implements PM_TRACE for x86_64 on LKML
<mjg59> Any chance you can pick that up?
<BenC> mjg59: Email it to me please? I'm trying to get the current tree uploaded, and I can pull it for this weekends upload
<mjg59> BenC: Ok
<BenC> thanks
<kylem> i vote we rm -rf ubuntu/... fedora seems to get away with it.
<kylem> these drivers are such a fucking utter mess.
<mjg59> Eh, if you ignore wireless/ it's not too bad
<kylem> quiet, i'm agonizing.
<kylem> ;-)
<kylem> BenC, i'm guessing there's some kind of race bringing up the network device now.
<BenC> kylem: A race with the workqueue's?
<kylem> yeah, i don't see how, but i can't see any other way this could be occuring.
<kylem> BenC, did you get an lrm uploaded with that depmod fix?
<BenC> kylem: It's following the kernel upload in about an hour
<kylem> ok.
<kylem> perfect.
<BenC> just waiting for device-tree-manager to be in main
<kylem> s/-manager/compiler?
<BenC> err, yeah :)
* kylem nods.
<jaims> hi all
<zul> well that was fun..
<Nafallo> zul: working XEN or something? :-)
* Nafallo haven't had the nerve to try it lately ;-)
<zul> no..
<doko> BenC: please could you have a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408530
<BenC> doko: I'm at a loss on that bug report...anything in particular you wanted me to look at in there?
<doko> BenC: the rh guy mentioned a possible kernel vulnerability
<BenC> doko: Ah, I see
#ubuntu-kernel 2007-02-09
<Nafallo> BenC: hi! do you know of hand if grow for raid level 5 are implemented in the kernel yet?
<BenC> Nafallo: grow by adding a disk?
<BenC> if so, yes it is
<Nafallo> nice. remember what kernel version? :-)
<Nafallo> I have a user on #ubuntu-se that asks about it. running dapper :-P
<BenC> I'm pretty sure edgy supported it
<BenC> not sure about edgy
<Nafallo> nice. I tell him to dist-upgrade and try then :-)
<Nafallo> he wanted to compile 2.6.20 on dapper...
<Nafallo> I guess thats a dumb idea? ;-)
<kylem> no. it's fne.
<kylem> booting it might be hard though.
<kylem> 8)
<Nafallo> lol
<Nafallo> # CONFIG_MD_RAID5_RESHAPE is not set
<Nafallo> :-P
<BenC> Nafallo: I said the kernel supported it...I didn't say it was enabled :P
<Nafallo> :-)
<BenC> I will enable it for feisty though
<Nafallo> yay!
<Nafallo> so the next kernel will have it? :-)
* Nafallo won't update his server before beta or rc anyway ;-)
<BenC> yeah
<zul> hey foks
<Nafallo> hi zul 
<kylem> BenC, did you mean to send that to ubuntu-dveel?
<ivoks> anyone has an idea why linux-image packages in dapper and edgy depend on non-exsisting kernels? :)
<cjwatson> ivoks: soyuz issue, being addressed
<ivoks> thanks
<cjwatson> ivoks: see #ubuntu-devel topic
<ivoks> thanks once again :)
<BenC> kylem: No, the guy that sent it to me Cc's -devel, and I just reply-to-all and sent the reply there to
<BenC> he got moderated, I didn't :/
<poningru> so in edgy there is a dependency error that came up today
<BenC> I will go away soon
<poningru> k
<poningru> did you want the error?
<poningru> just making sure
<poningru> thanks
<zul> what happened I just got up :)
<BenC> poningru: You mean the linux-meta packages not being satisfied by a proper kernel to install...it's known
<BenC> s/I/it/ too :)
<BenC> I wont go anywhere
<poningru> BenC: thats the one
<poningru> thanks
<poningru> :)
<zul> heh by the number of bug reports there is alot people who use linux-meta :)
<poningru> well its -generic-header and -generic for me
<poningru> but yeah
<poningru> the -meta packages
<BenC> zul: linux-generic is installed by default on people's systems
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-7.13 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules.
<MadMan2k> might I ask a non directly development related question?
<MadMan2k> why do I get 500MB of modules when I compile the kernel myself using make-kpkg, while the official linux_image is only 70MB?
<MadMan2k> I used oldconfig
<Lure> MadMan2k: because you compile all varians (generic, i386, bigiron, lowlatency...)
<MadMan2k> makes sense :)
<MadMan2k> Lure: if I append "--arch generic" will it give me generic only?
<Lure> MadMan2k: generic+lowlatency (afair), but I build directly on git
<MadMan2k> is there a list of parameters with which the official kernels are being built?
<MadMan2k> I basically only want to apply 2 patches and leave everything else as is.
<kylem> BenC, ah ok
<dholbach> hello
<zul> hi dholbach 
<pkl_> dholbach: hu
<dholbach> from -6 to -7 it seems that my skge eth0 is not automatically enabled anymore - does anybody know what I could do to debug this?
<pkl_> you means it's recognised (ifconfig eth0 reports it), but it is not configured?
<dholbach> no, with -7, I have to   sudo ifconfig eth0 up   it myself)
<dholbach> then I get a message in syslog that it got enabled
<pkl_> so, once you've brought it up, it is okay, and it is configured?  How do you get your IP address?
<dholbach> I run  sudo dhclient  
<dholbach> if you run       wget http://daniel.holba.ch/temp/dmesg-{6,7}; diff -u dmesg-{6,7} | less       you will see the difference in what's happening
<pkl_> ok, I was going to suggest a dmesg when you all disappeared...
<dholbach> there's also the output of   lspci -vvnn   if you want that ( wget http://daniel.holba.ch/temp/vvnn-{6,7} )
<dholbach> (just look for skge at the bottom)
<dholbach> pkl_: you think I should file this as a bug?
<pkl_> dholbach: it's definately a bug, but not sure in what though.
<pkl_> dholbach: I'll have a look into how network interfaces are detected and brought up in Ubuntu.  What version of Ubuntu are you using?
<dholbach> pkl_: feisty, 2.6.20-7-generic on amd64
<dholbach> it's not terribly urgent, I can still use -6 - just didn't know if you need a bug report for that or how you proceed from there
<pkl_> dholbach: I'm not sure either (having not been here long).  Personally I would raise a bug report.
<dholbach> ok, I'll do that
<dholbach> and I'll try on my i386 later on, if it happens there too
<dholbach> bug 84218 - if you need more information, yell :)
<BenC> dholbach: So the module loads, and the device is present in ifconfig -a, it just doesn't get configured?
<BenC> dholbach: And going back to -6 (same userspace) works as expected?
<dholbach> -6 works as expected - I didn't try   ifconfig -a    , plain   ifconfig   didn't show it
<dholbach> I can reboot and try, if you like
<BenC> yeah, without -a, you'll only see the ones that are up
<BenC> if -a shows the device, then it's obviously working from the kernel side
<dholbach> just un moment
<pkl_> it comes up in the dmesg as recognised, but, it doesn't get configured.
<kylem> try the sky2 module instead.
<dholbach> it gets shown on   ifconfig -a  
<dholbach> kylem: I modprobed it, but still it doesn't get configured
<dholbach> BenC, kylem, pkl_: any more info I can get you?
<BenC> dholbach: If it gets loaded and recognized, the kernel pretty much did it's job
<dholbach> hum
<BenC> no idea why booting one or the other would change that, unless some uevent is missing
<BenC> do you use ifupdown, or network-manager?
<dholbach> the latter
<BenC> dholbach: Try ifupdown...if that works on both, then I suspect network-manager is being picky
<dholbach> looks like the output of lshal changed completely
<BenC> maybe the backend driver for skge needs to be updates for some trivial change
<dholbach> maybe network-manager doesn't like that, nm doesn't seem to know about eth0 at all
<kylem> oh.
* kylem didn't realize it was actually coming up properly.
<dholbach> do you think it makes sense to attach the lshal logs and reassign to network-manager?
<kylem> yeah.
<dholbach> okay
<dholbach> kylem, BenC, pkl_: thanks again - I reassigned it.
<kylem> ok. cool.
<kylem> dholbach, so it worked if you manually dhclient it?
<dholbach> yes
<kylem> ok. weird. ok.
<dholbach> sudo ifconfig eth0 up && sudo dhclient      makes it happy
<dholbach> (then I have to restart all the nm bits, so gnome knows it can download mails and browse porn, etc.)
<dholbach> b0ng
<kylem> hehe
<MadMan2k> my self-compiled kernels (make-kpkg/ oldconfig) are always bloated at ~500MB. how can I make it compile as small as the official kernels?
<pmjdebruijn> MadMan2k, erh, that's extremely weird
<pmjdebruijn> MadMan2k, make-kpkg should produce just as small kernels
<BenC> MadMan2k: if you are using the ubuntu config, disable CONFIG_DEBUG_INFO
<BenC> we have it enabled so that we can get the linux-debug images
<BenC> for oprofile and such
<MadMan2k> that might be it
<MadMan2k> gonna try it later - thx
<maks_> hey guys have you ever had reports of freezing lenovo 300 laptop on ntpdate cmd
<BenC> but we strip the vmlinux and *.ko's after the build
<BenC> maks_: Not that I can recall, but check launchpad
<BenC> kylem: do you have an ia64?
<kylem> not accessible, no.
<BenC> the new acx driver fails to build on ia64 because of the WLAN_* compat for it went missing...my i2k is dead for some reason
<BenC> maybe I can dig it up from git
<kylem> hmm.
<BenC> got it
<maks_> Benc: ok thanks
<maks_> Bugs in Linux: No results for search ntpdate
<BenC> kylem: I need you to set your umask on rookery to 664 at least for push's
<kylem> eh? what happened?
<BenC> kylem: And then run "chmod g+w . -R" in /srv/kernel-team/private/edgy-ubuntu.git
<BenC> kylem: perms blocking me on that git tree
<kylem> on .git/HEAD?
<BenC> No, objects
<kylem> uh..
<kylem> well, i got a pile of -EPERM, but done.
<BenC> weird
<BenC> -r--rw-r-- 1 kyle kernel_team 2055 Jan 22 13:05 0244a8d6ba0bdda6f4c15484843d349a6ed68b
<kylem> i don't see how you could be pushing the same objects as me.
<BenC> did you have a 464 umask? :)
<kylem> no.
<kylem> 002.
<kylem> er, 022
<kylem> now it's 002
<BenC> doh, writing inverted masks
<BenC> I meant 002, right
<kylem> eh?
<cjwatson> ITYM 202
<kylem> i'm confused.
<cjwatson> Ben meant to ask if your umask was 202, I believe
<BenC> when I said your umask, I wrote 664, I mean 002
<kylem> i figured.
<BenC> and then the 646 one
<BenC> unable to write sha1 filename ./objects/95/30784fabf34b7c01b564f2ad3d2b14100097b6: Permission denied
<BenC> that's what I got when pushing
<kylem> must be a dir with the wrong perms.
<BenC> not sure why it wouldn't let me create that object...maybe it'll work now
<kylem> drwxrwsr-x 2 kyle kernel_team 4096 Feb  9 16:57 ./objects/95/
<kylem> that's... right though.
<BenC> yeah, that works now
<kylem> sorry, i'm trying to clean my inbox a bit atm.
<kylem> all the canonical private lists missed my procmail rules since i started, so i'm trying to sort a bit.
<BenC> good luck...I hate cleaning my inbox more than I hate taking our the garbage
<kylem> hehe.
<cjwatson> ---Mutt: /var/mail/cjwatson [Msgs:9906 New:638 Old:1168 Post:9 Inc:52 79M] ---(threads/date)---
<kylem> i finally worked up the balls to expire everything more than a year old from my synched maildir.
<BenC> cjwatson: wow, my 19 emails seems a little humbled by that :)
* BenC has gotten liberal with the DEL key lately
<kylem> hmm, i really don't need to be on activity@ anymore...
<BenC> yay, two successful builds for 7.13
<zul> gah..
<zul> http://www.devxnews.com/article.php/3658001
<zul> xensource is not looking into getting included in upstream
<BenC> "legacy virtualization"?!?!
<zul> heh..
<BenC> "It lacks the benefits of para-virtualization performance enhancements that have been pioneered by Xen and are now being copied by VMware and Microsoft"!?!?!!
<BenC> what kind of crack is this guy on?
<zul> dunno
<BenC> "Pratt also explained that Xen is no longer actively seeking inclusion in the mainline Linux kernel either."
<BenC> lovely
<kylem> i think that's kind o fbullshit.
<BenC> it's a load of something, and it smells like my yard...bullshit sounds like a good guess
<kylem> hah.
<BenC> I think xensource likes Xen being hard and not integrated
<zul> xen likes to make me bald
<kylem> i think xensource wishes it was still a research project.
<BenC> I think it still is
<kylem> they seem to be trying very hard to make it a commercial product...
<pkl_> cynically, a lot of the para-vitualisation work that has gone into the kernel for kvm/Lguest may conflict with Xen.  They've had a lot of resistance to how they do things on lkml, and may not wish to change their code to be more inline with kvm/Lguest changes.
<pkl_> only a guess, but nothing else makes sense IMHO
<BenC> paravirt isn't supposed to get rid of conflicts
<BenC> err, is supposed to
<BenC> Xen/KVM/VMI should all be able to live together if paravirt is implemented correctly
<pkl_> yeah, which is why it doesn't make sense why they don't want to cooperate.
<BenC> It's odd how they can use paravirt as a selling point for them and against the other implementations in the same sentence
<zul> they are trying to cooperate
<zul> http://lists.osdl.org/pipermail/virtualization/2007-February/002004.html
<pkl_> but maybe they don't.  It may simply be sour grapes, they've been trying to get it accepted for two years, and a jhonny-come-lately has gone in with much less trouble.
<kylem> the johnny-come-lately was... several MEGABYTES less delta to the core kenrle.
<BenC> they say that kvm lacks paravirtualization, when that's simply not true...it's not in 2.6.20, but it's there
<pkl_> heh, but they're probably coming from the direction that their several megabytes more delta was valid...
<kylem> bullshit.
<BenC> not to mention that kvm needs a lot less paravirt enhancement for the same performance, when the implementation is complete
<kylem> they diverted huge swaths of core kernel code with #ifdefs instead of creating new abstractions.
<kylem> they shouldn't have to look too far to see why they never did, and probably never will get merged as it stands now.
<mjg59> Is the Xen code in Linux not just for the case where you want to run a paravirtualised Linux under Xen?
<BenC> the xen para-virt domU patch was horribly large and touched way to much core kernel
<mjg59> I almost got hired to do ACPI support in Xen
<kylem> mjg59, i don't recall how much the dom0 stuff mucked with.
<BenC> mjg59: No, up until recently, the Xen kernel stuff was dom0(hypervisor) and domU support all together
<mjg59> Oh. Well, unsurprising that they lose.
<pkl_> I'm not defending them, but I know how Cambridge university types think (having worked there).
<mjg59> pkl_: I'm still a Cambridge university type :)
<BenC> someone took the time to pull out the domU stuff with paravirt, but it was still a 500k patch, and touched > 150 files of core kernel
<mjg59> Eurgh.
<kylem> i think i'm ruined by being a kernel hacker first, and an academic second. i've been doing this since long before i started uni. ;P
<pkl_> mjg59: really, you work at the Computer Laboratory?
<mjg59> pkl_: No, I'm a geneticist
<BenC> no one knows why mjg59 works on the kernel considering his field of study :)
<pkl_> A lot of people at Cambridge have a superiority complex.  They may simply hate having come 2nd.
<kylem> BenC, masochism was my best guess.
<Nafallo> mjg59: do it! acpi is what I lack in XEN ;-)
<mjg59> Nafallo: Nnngh.
<kylem> pkl_, 2nd to what?
<mjg59> Rusty.
<pkl_> hm, second to kvm.
<mjg59> Heh
<kylem> oh.
<mjg59> Ian Pratt is actually really nice
<mjg59> Mind you, I say that about most people who've bought me booze
<BenC> lol
<pkl_> Yes, I used to know Ian Pratt, we went out drinking together in Cambridge several times each week for months whilst I worked there.
<kylem> mjg59, that's a pretty good system
<pkl_> Ian Pratt was finishing off his PhD, while I was working there as a post-doc.
<pkl_> Ian Pratt went on to get a college fellowship, while I realised without a Cambridge PhD there was liitle chance of progression (and I too old to apply for a college fellowship).  I got my PhD from Lancaster University, which at that time was doing multimedia computing research comparable to Cambridge.  I decided to go to Acorn to design a new multimedia operating system for them.  They went bust 2 years later, the operating system got cancelled
<pkl_> , and the rest is history.
<mjg59> I want to be the bestest kernel hacker with a genetics PhD in the world ever
<kylem> i think you already are, minus the phd part.
<kylem> but if you'd stop wasting your time with acpi maybe you could get that done. ;P
<mjg59> Bah.
<mjg59> I've written 150 lines of perl today.
<mjg59> That's most of a paper.
<kylem> hehe.
<kylem> why is perl so popular in biology?
<pkl_> because fortran is old-fashioned?
<mjg59> Because most genetics is just writing the right regexp
<kylem> pfft. fortran is a fine language.
<pkl_> I used fortran for a couple of things in 1985.  It was extremely popular at time in Physics and Engineering :-(
* kylem had to learn fortran a few years ago to help some friends debug some satellite simulation crap. painful.
<kylem> ancient code from goddard... in F77...
<kylem> (this was like, in 2001, F95 had been around for... a while...)
<pkl_> mjg59: BTW which department is in the New Museums site now the computer lab has moved?
<mjg59> pkl_: Various people grabbed it
<mjg59> Bits of archaeology, zoology, the computing service, materials...
<pkl_> kylem: at least you've never had to learn/use COBOL.  COBOL 66 lovely :-)
<kylem> heh. i've never even seen cobol code.
<kylem> BenC, this looks bad:
<kylem> Rejected:
<kylem> UploadError escaped upload.process: File linux-source-2.6.17_2.6.17.1-11.35.dsc
<kylem> as mentioned in the changes file was not found.
<kylem> -----BEGIN PGP SIGNED MESSAGE-----
<BenC> kylem: talk to pitti...might have something to do with the security>proposed pocket fixes
<kylem> sigh.
<BenC> maybe he didn't get all the files into the queue
<zul> kylem: you dont want to...believe me...they still teach it at algonquin when i was there
<BenC> Algonquin...I love saying that name
<pkl_> cobol or fortran?
<mjg59> My MBP should be turning up on Monday
<zul> pkl_: both
<mjg59> It seems to take years for Intel to get round to posting stuff
<kylem> mjg59, it's hot. enjoy OS X.
<kylem> :P
<pkl_> yuck, at least fortran is concise.  Cobol is a managers idea of a programming language, things are grouped together in parapgraphs.  And each line of code is a sentence.  No joke...
<kylem> yow.
<zul> pkl: heh i still remember the four dvisions of cobol thats about it
<pkl_> Perform para1 thru para8 varying counter by 1 until counter equals 10.  or something like that is a for statement.
* kylem cries.
<pkl_> yeah, the "initialization division".  Try typing that from the UK, and more often than not you type "initialisation division".  On a batch processing system, when compiles are added during the day, and run at night in batch mode, you can wait a whole day to find you've used a 's' rather than a 'z' :-(
<mjg59> BenC: 84238 - we should get 2.6.17 removed
<cjwatson> the computer lab was never all that much of the new museums site anyway
<cjwatson> I mean, the tower and stuff, yeah, but I kept finding new departments on the NMS that I'd never previously heard of
<cjwatson> the place is a TARDIS
<cjwatson> huh, 2.6.17 isn't gone already?
<mjg59> Well, either that or the user is awfully confused
<cjwatson> BenC: ack linux-source-2.6.17 removal from feisty?
<pkl_> yeah, I meant the bit of the NMS that the lab occupied.  All the 'junk' than had accumulated had to go somewhere, the cap computer was still stuck in a corridor when I was there.
<BenC> cjwatson: Sure, was just looking into filing a bug for it :)
<cjwatson> it does seem like a bug that we break 2.6.17's initramfs with feisty's tools, though
<zul> cjwatson: can you remove xen-source-2.6.17 as well?
<cjwatson> that will surely cause upgrade pain
<cjwatson> zul: what's current in feisty?
<zul> 2.6.19
<cjwatson> oh
<cjwatson> he ran mkinitrd
<cjwatson> not mkinitramfs
* cjwatson reassigns to initrd-tools
<cjwatson> zul: oh, I was confused by the source package being just 'xen-source' now
<cjwatson> BenC,zul: done
<zul> cjwatson: thanks..
<BenC> cjwatson: thanks
<fvaler> bochs?
<kylem> mjg59, fwd'd the mail from alan to you and ben. i'll try cooking a patch up on monda.
<pkl_> kylem: is that email about the para_acpi driver?
<pkl_> para -> pata
<kylem> no. HPA.
<mjg59> kylem: It's a pretty tiny amount of code
<pkl_> okay, the protected area stuff?
<mjg59> kylem: I suspect that the difficult bit is just getting it into a state where the libata guys will take it
<mjg59> pkl_: Yp
<pkl_> can you forward it me as well then?  I am apparently part of the kernel-team now?
<kylem> email?
<pkl_> ah, that's what you said it was.
<kylem> i was asking for your address, but i went and fetched it anyway.
<pkl_> oh good :-) phillip.lougher@canonical.com would have worked.
<cjwatson> BenC: could you have a look at bug 84094? symlinks seem to be buggered after installation
<pkl_> kylem: Diolch yn fawr... (that's thanks very much BTW in Welsh, as its about Alan).
<BenC> cjwatson: checking...
<fvaler> the linux kernel is more often than not in C or c++?
<fvaler> C isn't it
<mjg59> All in C
<pkl_> C and a small amount of assembler
<fvaler> Excellent
<fvaler> So only the windows kernel is in c++?
<fvaler> atleast large chunks of it are
<pkl_> No, Symbian (used on mobile phones) is C++
<fvaler> which would you guys p refer to use
<pkl_> Or a bastardised variant anyway.
<fvaler> c/c++ as far as the kernel goes?
<pkl_> C is lower-level, allows more exposure to the underlying architecture, is more efficient.  I wouldn't use C++ for anything personally.
<kylem> eh? anything you can do for a kernel in C, you can do in C++, you can even use almost all C++ language features in a kernel...
<fvaler> ok personally that sounds fine
<fvaler> kylem: exactly
<kylem> that said, i hate C++ with a firey burning hatred.
<fvaler> why?
<kylem> Mac OS X is written mostly in C++.
<fvaler> I really dont understand this
<fvaler> large chunks of windows is written in c++ as well
<kylem> because for a kernel, it's overkill unless you are a really lazy person.
<kylem> the only real benefit to Linux would be implicit "this" pointer for function pointers in a struct
<fvaler> BUt it doesn;t lack anything C can do it can't
<kylem> so you don't have crap like, sb->someop(sb, ...);
<kylem> g++ is slower than dragging source lines through molasses anyways.
<pkl_> this is a religous way, arguments for and against C and C++ can be made.  I've never liked C++ as it encourages abstraction and information hiding when in the kernel you don't anything that bloats or makes it slower.
<pkl_> way -> war
<kylem> c++ also encourages overuse of function pointers, which are pretty nasty on most processors.
<fvaler> kylem: actually i dont think you can use c+= for kernel
<fvaler> neither on windows or linux
<fvaler> The difficulty is controlling linkage for things such as template instantiations
<kylem> you can.
<kylem> you have to disable rtti.
<fvaler> http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx#EDE
<fvaler> C++ has RTTI.
<mjg59> The only C++ I'm familiar with in the Linux kernel is a huge pile of junk that the linuxant drivers wedge in
<kylem> ...
<fvaler> C++ without RTTI isn't C++. Furthermore, that's far from the only problem.
<pkl_> C++ is probably better for large projects with clear separation between components developed by multiple teams.  Often the gain in development is compensation for the (potential) loss of performance
<kylem> ok, you're either dense, or an idiot.
<kylem> one way or another, you're wrong, and this is off-topic.
<fvaler> kylem: i'm sorry?
<fvaler> C++ has RTTI
<kylem> -f-no-rtti
<kylem> welcome to my /ignore.
<fvaler> Woah
<pkl_> yes, this off-topic
<fvaler> Offtopic maybe but we're talking about the kernel actually
<fvaler> Just in C++
<kylem> kickban someone?
<fvaler> Peopple who disagree with you are idiots always?
<kylem> http://netlab.ru.is/exception/LinuxCXX.shtml
<mjg59> fvaler: Two issues:
<mjg59> fvaler: You're wrong that C++ can't be used in the kernel. It's just that if you do it, nobody will ever speak to you again.
<mjg59> fvaler: And secondly, this channel is for discussion of development of the Ubuntu kernel, not generic kernel issues
<fvaler> I understand but name calling over something he disagrees with is preposterous
<fvaler> Not mature
<fvaler> let's read his link anyway
<pkl_> fvaler: I've never treated anyone as an idiot for simply disagreeing.
<mjg59> Well, it's not a disagreement. It's a statement of fact.
<mjg59> But that's unimportant.
<fvaler> Ok
<fvaler> kylem: That research is about changing the linux kernel to support C++.
<fvaler> Note the implication that it doesn't support it.
<fvaler> It still doesn't.
<kylem> it never will. because it's a shitty language. now GO AWAY.
<kylem> take it to #kernelnewbies.
<zul> ok enough...this is totally offtopic
<fvaler> I'm at kernelnewbies
<fvaler> And they agree with what I said it simply doesn't
<zul> ENOUGH
<BenC> fvaler: Basic idea is that whether or not C++ will work, or can work in the linux kernel is completely irrelevant to this channel, and most people here probably feel that the topic is more trolling than anything
<fvaler> BenC: I gave up wrt to the topic and pretty much done
<kylem> fvaler, look, i'm sorry, but i /HAVE WRITTEN/ linux kernel c++ code before. classes and all. that's clearly C++. i don't want to argue anymore.
<fvaler> That paper doesn't say anything
<fvaler> The paper I gave you is about using C++ in ways that are compatible with the kernel; the point is that C++ isn't supported.
<fvaler> But yeah ok.
<kylem> maybe not fully, but you can certainly get by.
<fvaler> Not for the sake of arguing but lots of people have written C++ code for a kernel, and even more have compiled C code with a C++ compiler for a kernel
<fvaler> Dude my only point is it has no bearing on whether C++ is a language supported by the kernel.
#ubuntu-kernel 2007-02-10
<Nafallo> note to self: try out para-XEN on silverfairy
<mjg59> kylem: Rock, ipw3945 d80211 is now functional
<mjg59> I'll work on that tomorrow (in my wireless blitz)
<KenSentMe> I think there is a problem with the new 2.6.17-11 kernel along with nvidia kernel module. X won't start anymore and there are more people with this problem
<kylem> mjg59, you are so full of the awesome. thanks!
<kylem> mjg59, dscape ipw3945 is the one not-requiring the binary daemon, correct?
<mjg59> kylem: Correct
<kylem> BenC, did you manage to get acx going on ia64?
<kylem> BenC, (sorry, i didn't test build on the non-release arches... :(
<kylem> BenC, also, i'm thinking of switching feisty from doing MMCONFIG with fallbacks to whitelist MMCONFIG on some chipsets, but use DIRECT pci access by default, with fallback to BIOS. i've noticed quite a few bugs where turning on pci=nommconf fixes bugs. :(
<kylem> fabbione, aside from the delay, how was your trip home?
<fabbione> kylem: ok i would say...
<fabbione> managed to sleep almost all the flight
<fabbione> but i did miss a penguin to cuttle...
<kylem> yeah yeah, i'll ship it this week, relax a bit. ;P
<fabbione> hahaha
<fabbione> might as well wait May at UDS
<fabbione> reall
<fabbione> it's not worth shipping 
<kylem> well, netwinder with it.
<mjg59> http://www.microsoft.com/windows/products/windowsvista/features/details/networking.mspx
<fabbione> up to you really.. 
<mjg59> Find the "network mapping" section
<mjg59> Wonder how it does that
<kylem> haze of bong smoke, etc.
<kylem> UPNP probably
<fabbione> nmap ?
<fabbione> there are small and simple tools to do stuff like that
<fabbione> even one for linux
<mjg59> Including working out whether something's the other side of a bridge or not?
<fabbione> mjg59: last i used it it was about 4 years ago..
<fabbione> no idea what it can do now
<fabbione> but it's nothing different than HP OpenView discovery mechanism
<kylem> do the little linksys doohickeys to snmp?
<mjg59> Doubt it
<kylem> thought not.
<mjg59> I guess it's either upnp or (possibly) spanning tree?
<kylem> i wonder if i can use dmi to nix mmconfig... hmm.
<mjg59> kylem: I'm sure you can, but I'm fairly sure you don't want to
<kylem> right, i'd rather whitelist using it. heh.
<mjg59> Windows still doesn't use mmconfig
<mjg59> So I certainly wouldn't be unhappy disabling it by default
<kylem> agreed
<kylem> right now we do ANY, which does mmconfig -> direct -> bios fallbacks.
<kylem> the problem is we don't do a good job detecting broken mmconfig and so shit breaks in nasty ways. :(
<mjg59> kylem: Bad news is that I'm going to have to feed you some slightly updated d80211 code
<fabbione> mjg59: spanning tree won't help much alone..
<kylem> mjg59, what's the good news?
<fabbione> anyway
<mjg59> kylem: Give me a sec and I'll let you know how good bcm4311 support is now
<fabbione> i am off to turn off N+1 too many candles on my bday cake and play with my son a bit
<fabbione> cya on monday
<mjg59> Just need to grab the firmware and swap the cards
<kylem> mjg59, *hugs*
<mjg59> Once that's done, I'll give the new ipw3945 code a test
<kylem> thanks!
<mjg59> Just need to find some screwdrivers...
<mjg59> Jesus. Sony really don't make it easy to get at the mini-PCIe socket.
<mjg59> Gah. I've odne this before, but can't remember how.
<navber> guys
<navber> what was the xen issue y'day
<navber> from xensource
<navber> BenC: ping
<mjg59> Ok, so hal believes that I have no PCI devices
<mjg59> Other than that, things look good
<navber> dammit i want that link
<navber> :D
<navber> anyone recalls that ridiculous post on xensource?
<navber> or was it devxnews
<mjg59> Hm. Except I don't seem to be getting any incoming packets.
<navber> ok got it http://www.devxnews.com/article.php/3658001
<navber> what was the issue again ?
<navber> something about virtualization
<mjg59> navber: I have no idea what you're talking about
<mjg59> Oh. Now it's started working.
<navber> BenC and a few others were discussing it y'day
<mjg59> kylem: So I'm getting ~340K/sec with bcm4311 now
<mjg59> Which is much better than it used to be
<navber> you know during cross compilations the difficult bit is  building the cross compiler isnt it? ... but once its built then its a breeze
<mjg59> kylem: Ok, this is definitely better than what we've currently got. Just want to test on bcm4318 as well first.
<mjg59> kylem: Hm. Yeah, there's definitely some sort of issue where the card doesn't seem properly associated to begin with
<kylem> mjg59, with bcm4318 you mean?
<mjg59> No, bcm4311
<mjg59> Moving onto bcm4318 next
<mjg59> Just need to wait for the machine to finish updating before I swap the cards
<kylem> ah
<mjg59> kylem: Score. iwlwifi seems to work well.
<mjg59> kylem: bcm4318 still isn't great, though. I'm only getting about 50K/sec
<BenC> kylem: yeah, ia64+acx is building now
<BenC> and I saw the mmconfig thing too..your fix sounds reasonable
<mjg59> BenC: Did the new LRM get into the security upload?
<mjg59> I've seen a couple of bugs that could be explained by it being missing
<BenC> I'd have to ask pitti about that one
<mjg59> BenC: Also, current git seems to break hal
<mjg59> Updating hal to newer upstream code rectifies this
<BenC> How does the kernel break hal?
<BenC> lrm has trunk code of madwifi
<BenC> or do you mean the new-hal branch?
<mjg59> Not madwifi hal
<mjg59> hald
<mjg59> The userspace app
<BenC> ah
<BenC> too man hal's
<markedwards> Has the sky2 ethernet driver hang issue been fully fixed in the recent 2.6.17.11 kernel update?
<mjg59> !
* mjg59 manages to build dadwifi
<mjg59> With openhal
#ubuntu-kernel 2007-02-11
<markedwards> does anyone know the status of the sky2 lockup bug?
<kylem> mjg59, dude, awesome.
<pwnguin> is there a lag between launchpad's "published" status and availablility on the repos?
<pwnguin> launchpad says the new kernel was published on the 9th, and its still not available =/
<okaratas> hobarey, kernel image 2.6.17.11 is upgrading..
#ubuntu-kernel 2008-02-04
<Kano> hmm rtg still missing
<Kano> BenC: b43legacy is not bcm43xx, you need the first you could disable the 2nd
<Kano> btw. ndiswrapper 1.52 is out
<Kano> b43legacy is loaded via ssb
<Kano> b43legacy has no direct pci id, this has ssb, so absolutely useless to disable
<Kano> rtg: did you get my pm?
<rtg> Kano: I'm not registered, so I can't reply. (thats on purpose). This is supposed to be an open channel.
<Kano> does not matter, i have pm free for all
<Kano> you should not get any error
<Kano> why did you disable b54legacy and not bcm43xx?
<Kano> b54legacy is together with b54 triggered by ssb
<Kano> CONFIG_BCM43XX=m
<Kano> thats what you can remove
<Kano> be sure to use the new fireware -> b54-fwcutter instead of bcm43xx-fwcutter
<Kano> also ndiswrapper 1.52 was updated
<Kano> rtg_: how about fixing the bcm43xx / b54legacy issue
#ubuntu-kernel 2008-02-05
<abogani> rtg: Are you around?
<amitk> abogani: rtg should come online in 2-3 hours
<abogani> amitk: Thanks Amit. I have a problem on -rt. Can you help me, please?
<amitk> abogani: sure, what is it
<abogani> amitk: Thanks. After last (security) update of the kernel X don't want start at boot with nvidia X driver on 64bit (32bit works fine).... I suspect that the problem still live in Hardy.
<abogani> Where should I look?
<abogani> Do you have some suggestions?
<abogani> Who could explain me why 32bit version works fine and 64bit not?
<amitk> abogani: is the problem in Gutsy?
<abogani> amitk: Yes.
<amitk> abogani: I am checking the updates...
<abogani> amitk: I suspect that isn't dependent from last update only...
<abogani> I have only one 64bit system and i don't update/dist-upgrade often
<amitk> abogani: could you post the /proc/version_signature of the working and non-working kernels?
<abogani> Unofficial for both
<amitk> abogani: do you know the last tag where it was working?
<abogani> amitk: Sorry i don't remember. :-(
<amitk> that makes it a bit hard to narrow down the problem :)
<abogani> I know Amit ;-)
<amitk> abogani: Do you have the problem with Hardy Alpha 4?
<abogani> amitk: No Hardy (-rt) works very well but unfortunately my test system don't have a nvidia video card. Sorry but i don't enough computers :-)
<amitk> abogani: Do we _ever_ have enoughc computers? ;-)
<amitk> could you confirm with the Hardy live cd on the computer with the nvidia?
<abogani> amitk:  I'll do this test!
<abogani> amitk: Thank you for the moment! :)
<amitk> np
<tjaalton> abogani: reinstall the driver
<tjaalton> abogani: unless you are using -nv
<abogani> tjaalton: Ok i'll try that first! Thanks Timo.
<amitk> tjaalton: why?
<tjaalton> amitk: that's a valid question, but people have said that it helped..
<tjaalton> abogani: do you use the official driver or envy?
<tjaalton> abogani: also, the logfile would be nice
<amitk> tjaalton: packaging problem?
<tjaalton> amitk: with envy at least, our packages should be fine
<tjaalton> if the package doesn't divert some files, upgrading the server will break it
<tjaalton> I'm not sure if envy diverts libglx et al
<ogra> hey ... i seem to have lots of oopses recently with the -5 kernel related to tick_notify and _spin_unlock_irqrestore is that known ?
<ogra> it spills my logs and after some hours the system just hardlocks
<thegodfather> ogra: what about collecting those OOPSes?
<thegodfather> it's difficult to guess without
<ogra> well, in fact its always the same it seems
<thegodfather> well it doesn't help if you don't show us your OOPS ;)
<ogra> http://paste.ubuntu-nl.org/54836/
<ogra> there ist is :)
<thegodfather> ogra: it's somewhere in RPC code. i guess you are running NFS of somekind
<ogra> lets check, i'm not sure 
<ogra> ogra@laptop:~$ ps ax|grep nfs
<ogra>  6603 pts/0    R+     0:00 grep nfs
<ogra> #
<ogra> nop
<thegodfather> rpc
<ogra> ah, yeah
<ogra> the client stuff
<thegodfather> yeps
<thegodfather> do you have some aggressive acpi features enabled?
<thegodfather> well it's a laptop.. hmmm
<thegodfather> try to disable acpid or whatever is used for power manager now
<thegodfather> for what i can see something goes bad between the 2
<ogra> i dont do it explicitly and i think there is an APIC message during boot ...
<thegodfather> ACPI != APIC
<ogra> ACPI not connected to local APIC or so ?
<ogra> let me reboot i'll check
<thegodfather> try to boot with the usual options.. noapic noacpi or whatever they are called now
<thegodfather> because i run nfs/rpc stuff here but i don't see it
<thegodfather> on the other side i don't run any power management stuff
<ogra> (if booting wouldnt take 1h nowadays that would help :) )
<thegodfather> just press the reset button :)
<thegodfather> that's why we have journal FS'es
<thegodfather> ;)
<thegodfather> reboot -n -f will do
<ogra> time not connected to IO-APIC ... no ACPI in that meassage, i was wrong
<ogra> *timer
<ogra> well, that speeds up shutdown ... booting is the painful thing here :)
<ogra> to quote one of my favorite bugs: the worm on the screen is only 1cm long during boot and stops there for a minute or two *g*
<thegodfather> it should be easy to figure the problem
<thegodfather> there is only one call to spin_unlock_irq in the whole sunrpc driver
<ogra> i wiped the nfs stuff for now ... nothing i  need anyway
<thegodfather> and it might not even be a bug in sunrpc at the end
<thegodfather> the code didn't change since Aug.
<thegodfather> it's probably recalc_sigpending
<ogra> did we switch to tickless recently ?
<thegodfather> in .22
<ogra> ah, well, no probs with .22 
<ogra> might indeed as well be the new hal and its powermanagement 
<thegodfather> no
<thegodfather> this is a kernel bug... userland even if broken should not trigger this kind of OOPS'es
<thegodfather> the thing is:
<thegodfather> lock()
<thegodfather> dononething()
<thegodfather> unlock()
<thegodfather> and you are getting an OOPS in the unlock
<ogra> ah, right
<thegodfather> so it might even be the unlock operation to be broken (very unlikely)
<thegodfather> or the doonething that corrupts memory
<thegodfather> (as an example)
<thegodfather> anyway file a bug
<thegodfather> the file is net/sunrpc/svc.c
<thegodfather> there is only one call to that unlock thingy
<ogra> will do
<ogra> bug #89224
<ubotu> Launchpad bug 89224 in ubiquity "GrubInstaller failed with code 1" [Undecided,Incomplete] https://launchpad.net/bugs/89224
<ogra> ??
<ogra> oh
<ogra> bug #189224
<ubotu> Launchpad bug 189224 in linux "sunrpc causes kernel oopses on 2.6.24-5-generic" [Undecided,New] https://launchpad.net/bugs/189224
<ogra> :)
<kraut> moin
<Kano> hi BenC , lum is still -6 not -7
<rtg> Kano: upload are in process. patience.
<BenC> so?
<Kano> rtg: ok
<BenC> Kano: lum can't build until the kernel does
<Kano> well it did here already ;)
<rtg> BenC: he is pointing out that the git repo hasn't been updated, but I just have been busy this morning.
<BenC> ah, gotcha
<tseliot> BenC: did you have a look at my suggestions on the wiki?
<BenC> tseliot: haven't had a chance yet
<tseliot> BenC: I hope we can do this before February 14. Envy works great with my solutions
<benje> hello
<benje> we have found how to resolv disk detection under kernel 2.6.24 with the fujistu amilio laptop
<benje> patko, give the link to the modificated .config please
<benje> did we must open bug for this version of the kernel ?
<amitk> benje: that would be appreciated, thank you
<patko> benje, here is the working .config: http://paste.ubuntu-nl.org/54869/
<BenC> Ok, in case people haven't seen: https://wiki.ubuntu.com/KernelTeam/Meeting
<BenC> The regular IRC kernel team meeting is in session
<benje> amitk, it's need review to stay generic we take off the ide generic support for this is working 
<amitk> benje: please attach the config to the launchpad bug
<BenC> Agenda is at the URL above
<benje> BenC, this is for me ? 
<BenC> this is for the channel
<benje> amitk, which else file must we post the original dmesg and this for now 
<BenC> So a friendly request to hold off on general conversations until after the meeting
<amitk> benje: yes. We can continue this after the IRC meeting
<benje> ok
<BenC> We are going to make this quick, since everyone is fairly busy
<king_> ok
<BenC> rtg: You've uploaded 7.11 today to fix the build failures in the 6.10 upload...guess we'll know soon if the builds process
<rtg> indeed we will
<BenC> rtg: since you've been closest with the kernel tree this release cycle...is there anything we should be concerned about with beta coming up?
<rtg> some of the virtual features are new, virtio, kvm, etc. They are not part of 2.6.24.
<rtg> iwlwifi remains at 1.2.0, but most of the other wireless cards are supported upstream.
<rtg> there are some collision issues with legacy v.s. new drivers.
<rtg> hopefully, blacklisting in modules-tools-init will help that.
<BenC> I noticed the whole b43/legacy/bcm43xx issues...are they resolved now?
<rtg> we'll see.
<Kano> well it build the module
<rtg> I'm sure Kano will let me know if they aren't.
<Kano> the b43legacy
<Kano> but i really prefer removing the pciids
<BenC> Blacklisting is prefered, since it lets the user decide
<rtg> black listing is effectively the same.
<BenC> removing pci id's hard codes too much
<Kano> echo bcm43xx >> /etc/modules
<Kano> user decided
<Kano> ;)
<BenC> if the pci id's are removed, then the module wont bind to the device
<Kano> not automatically
<BenC> not at all, unless you echo the pci id's into newid in sysfs
<BenC> unless you are just commenting out the MODULE_DEVICE_TABLE() in the driver, and that's the same as blacklisting anyway
<BenC> but requires us to muck with the source
<rtg> There are more issues with bcm then just PCI ids, it also depends on the SSB bus driver.
<Kano> only the new one
<Kano> well new 2
<Kano> b43*
<Kano> both depend on ssb
<Kano> you could basically even disable bcm43xx
<Kano> debian did that
<rtg> We aren't gonna do that for now, so lets move on.
<BenC> Right, let's hash this out on kernel-team@ where it needs to be
<BenC> we know there is an issue, resolving it is beyond the context of the meeting
<BenC> rtg: anything else?
<rtg> I'm not as familiar with the current bug list as I should be.
<rtg> so, there are probably other issues.
<Kano> also has anybody else with the 64 bit no splash?
<BenC> well, I was looking past the bug list
<rtg> yep - I've seen it.
<BenC> Kano: off topic...
<Kano> thats a kernel issue
<rtg> this -7.11 upload is against the 2.6.24 rebase
<rtg> so, we'll have a stable code base against which to do our bug shooting.
<BenC> rtg: excellent
<rtg> thats it from me...
<Kano> or kernel config
<amitk> rtg: so we will go with upstream ALSA and iwlwifi for Hardy, correct?
<BenC> amitk: mobile...you were at the sprint last week...anything we need to worry about with the kernel+beta for them?
<rtg> amitk: correct.
<amitk> BenC: not really
<BenC> amitk: how important is 8.04 and 2.6.24 to UME right now?
<amitk> all the mobile code is self-contained in it's flavour patchset and will probably go beyond Hardy
<rtg> amitk squeaked in an lpia update this morning moments before I uploaded.
<amitk> 8.04 is important to the customer, but schedules are tight and they _might_ not make it. So we will move them to a PPA after Hardy
<amitk> rtg: yeah well.. I couldn't get back to sleep at 5am, so I pushed a patch instead ;)
<rtg> sounds like jet lag.
<BenC> insomnia goes hand-in-hand with last minute kernel patches, hehe
<rtg> and FTBSs cause insomnia.
<rtg> forgot to mention ndiswrapper updated to 1.52
<amitk> rtg: is there anything else (major) that we will switch to LUM and upstream for Hardy?
<rtg> nothing on the radar.
<BenC> Ok, I think that covers us as far as status right now
<BenC> Wanted to get some intros out of the way...joining us from a few weeks ago is Stefan Bader (sbader)...
<BenC> stefanb I mean
<stefanb> Hi :)
<BenC> And just starting with Canonical on the kernel team yesterday is Colin King (king_)
<king_> Hi too! :-)
<BenC> Both are generalist on the kernel team, and will help handle our main workload for hardy 8.04 and beyond to following releases
<BenC> And now some much needed, and usually avoided, discussion on our QA bug list
<maks_> left freebsd king_ ?
<king_> No.. I haven't touch FreeBsd for 10+ years now
<BenC> So anyone who hasn't seen it, ogasawara (who is on the QA team, concentrating on the kernel) maintains this page: http://people.ubuntu.com/~ogasawara/hardy-buglist.html
<BenC> It's an excellent starting place for community to work with the kernel team
<rtg> It needs serious love for the next few weeks.
<BenC> I'm sure ogasawara would appreciate feedback on this page as well (please, don't punish her inbox with requests to get your bug added :)
<BenC> Yeah, since 2.6.24 is released, and uploaded, this list is primary focus
<ogasawara> feedback would be great.  I suppose I should add a blurb to the top about what the list for anyone new
<BenC> The churn is at a minimum now, so stable code base to work from
<BenC> ogasawara: something like "Go away if you value your sanity"?
<ogasawara> heh
<maks_> have you already some nfs patches?
<maks_> we have reports that nfs on 2.6.24 is quite buggy
<maks_> aka does not sustain load
<maks_> both nfs v3 and v4
<BenC> ogasawara: One thing we discussed earlier was being more liberal with "Wont Fix" on some of these reports, and working harder to assign and respond to them more quickly
<BenC> maks_: is there an open bug report?
<maks_> http://marc.info/?l=linux-nfs&m=120220211505693&w=2
<maks_> lots of informal reports on channel too
<BenC> Ok, we'll investigate that
<ogasawara> BenC: so one thing I haven't done in the past few weeks is assign to anyone as I wasn't sure how much work you guys already had on your plates
<BenC> ogasawara: that's my fault...I've been slacking on initial processing of your list
<stefanb> I normally go forward and self-assign me from that list
<BenC> That's good
<king_> I probably need some assigning to me to kick off with
<BenC> king_: Oh, I can get you started off right :)
<king_> BenC: the more the merrier
<ogasawara> oh no, famous last words :)
<BenC> Ok, let's wrap this up so we can get back to work...any out-of-band issues to bring up?
<BenC> excellent...meeting adjourned then
<BenC> ogasawara: thanks for joining us on short notice
<ogasawara> np
<BenC> Thanks everyone, have a great week
<stefanb> see you
<king_> bye for now
<amitk> benje: so please attach the .config to the bug report and add an explanation if necessary
<rtg> amitk: ' hardy lpia   Successfully built  (NEW)'
<amitk> rtg: ofcourse! you thought I would commit a broken patch at 5am? ;-p
<rtg> amitk: and did you think I _didn't_ do a test build just to make sure?
<BenC> hehe
<tseliot> BenC: when can I ping you again?
<BenC> tseliot: let me get some lunch...in an hour?
<benje> amitk, ok
<tseliot> BenC: ok, thanks :-)
<amitk> rtg: :)
 * amitk -> groceries
<benje> amitk, do you need the old dmesg and the new . we start explain what's happened with std kernel
<amitk> benje: add everything that you feel is necessary.
<Kano> rtg: when i change version+ rules clean i have got this problem: http://paste.debian.net/48499
<rtg> Kano: use 'debuild -b' from devscripts to catch all of the package build deps.
<Kano> rtg: all installed, just not the other headers
<Kano> i only compile generic
<Kano> you have one binary
<Kano> utils/mod-dep
<rtg> Kano: build problems are outside my area of interest. Its building on the archive, so its right for me.
<Kano> rtg: you have too many binaries to build it on etch
<Kano> you usually dont need em
<rtg> Kano: The hardy release is built within the Hardy environment. That is all I really care about (or am responsible for).
<Kano> rtg: call it like you want: this is bad
<benje> amitk, there many problem :  boot with gutsy => kernel panic => soluce set noapic ; cd desktop gutsy noapic => no cdrom => must use netboot cdrom ;
<Kano> rtg: and: you only need to delete the file
<benje> do you think i must separate the post amitk 
<Kano> rtg: ubuntu/sound/alsa-driver/utils/mod-deps
<Kano> delete it and it will be created when needed
<benje> between gutsy and the kernel 2.6.24 ?
<rtg> Kano: you're right. How in the _fuck_ did a binary get checked in?
<rtg> yhis was a clean checkout from the ALSA HG repo.
<Kano> maybe add it in the clean rule extra
<rtg> Kano: the original source directory is cloned into a build directory before building. there should not be any binaries to begin with.
<Kano> LANG= grep ELF -Rs *|grep Binary
<Kano> pretty simple check for binaries
<rtg> Kano: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=summary
<Kano> fine
<tseliot> BenC: are you there?
<tjaalton> maks_: client or server? (NFS instability)
<amitk> benje: I would restrict the report to Hardy for now, since it is unlikely that this will be fixed for Gutsy
<benje> amitk, ok this is quick description with .config http://paste.ubuntu-nl.org/54902/
<tjaalton> maks_: seems to be server, so that's probably why I havent seen that
<benje> amitk, i take off all about gutsy ;)
<amitk> benje: looks good. Make sure to attach the .config as an attachment, not inline text
<amitk> benje: and leave the gutsy parts in there, it might help in debugging
<benje> ok amitk 
<benje> amitk, i found this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/178843 the message is the same for the first boot of 2.6.24 about noapic but not for the same model and not all the same problem . do i post to it or open a new one?
<ubotu> Launchpad bug 178843 in linux "kernel panic on boot in kubuntu 8.04 alpa 2 becouse of Apic" [Medium,Triaged] 
<benje> must i 
<amitk> benje: new bug with a comment listing the other bug number
<benje> amitk, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/189368 
<ubotu> Launchpad bug 189368 in linux "kernel panic with notebook Amilo Xa 2528 P5811 kernel 2.6.24" [Undecided,New] 
<tormod> would be nice if someone could look at, and at least triage/milestone bug #186062. thanks
<ubotu> Launchpad bug 186062 in linux-ubuntu-modules-2.6.24 "please update linux-wlan-ng (prism2_usb) to latest upstream version (>=1847)" [Undecided,New] https://launchpad.net/bugs/186062
<rtg> tormod: from here? linux-wlan-ng-0.2.8/src/prism2/driver
<tormod> rtg: no, from svn. Where do you document where the code comes from?
<rtg> tormod: I didn't do this one. the previous guy didn't leave any tracks.
<tormod> bad guy ;) svn://svn.shaftnet.org/linux-wlan-ng/trunk
<rtg> tormod: put the svn URL in the LP report so we can remember it.
<tormod> ok
<tormod> what about Ubuntu changes, are they documented beside the commit comment?
<rtg> tormod: I'll put a BOM file in the prism2_usb directory (Bill of Materials)
<tormod> anyway, the only Ubuntu changes I could see by looking at the git history, are included upstream.
<tormod> s/only//
<rtg> tormod: does it need an updated p80211 ?
<tormod> yes, they are hand in hand
<tormod> p80211 was supposed to be something general for several drivers, it ended up in monogamy with prism2
<tormod> I think l-u-m used to have p80211 as a subdir of prism2 or the other way around.
<rtg> tormod: ok, test building.
#ubuntu-kernel 2008-02-06
<tormod> thanks a lot
<rtg> tormod: it'll probably take a 3-4 days to show up in the archive.
<rtg> off to a mardi gras party.
<tormod> was just back from Carneval here :)
<rtg> I saw pictures of that in Brazil. Looks like fun. gotta go.
<tormod> 'night
<kraut> moin
<abogani> Morning all
<abogani> amitk: No way last -rt kernel flavour on amd64 with nvidia-glx-new driver didn't works.
<amitk> abogani: so reinstalling the driver doesn't help?
<abogani> amitk: "apt-get remove --purge nvidia-glx-new", reinstall and reboot don't help
<amitk> did you try the hardy live cd?
<abogani> amitk: 2.6.22-14.51 no, 22-14.47 works after depmod -a, before of the 22-14.47 works fine
<abogani> amitk: In your opinion where should i look? 
<amitk> abogani: have you tried the hardy live cd?
<abogani> amitk: Yes it works but it is -generic or i can select -rt on boot menu? :-)
<amitk> abogani: -rt is not on the live cd. You will have to install the -rt kernel separately
<abogani> so i should install Hardy, right?
<amitk> tjaalton: might have some more ideas
<tjaalton> abogani: what was the original problem?
<abogani> I can't explain to myself why, with the same hw, on 32bit works great and on 64bit is broken :-(
<abogani> tjaalton: After last (security) update of the kernel X don't want start at boot with nvidia X driver on 64bit (32bit works fine)....
<tjaalton> abogani: does it work if you disable usplash (nousplash on the kernel cmdline)
<abogani> tjaalton: Kernel loading all things without warning or error. lsmod nvidia return Ok. 
<abogani> X tell me this: (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module! Please ensure
<abogani> (EE) NVIDIA(0):     that there is a supported NVIDIA GPU in this system, and
<tjaalton> abogani: please put the full log somewhere
<tjaalton> also the part from dmesg where it loaded ok
<abogani> tjaalton: Ok
<abogani> tjaalton: I have removed all -rt packages (linux-image-*-rt, linux-ubuntu-*-rt, linux-restricted-*-rt) and i have reinstalled the same and it works!
<tjaalton> abogani: good to hear :)
<laga> tjaalton: any change #144322 will be fixed? (a bit off-topic in here, but since i just saw you here..)
<laga> s/change/chance/
<tjaalton> bug 144322
<ubotu> Launchpad bug 144322 in xserver-xorg-video-ati "interlacing broken in gutsy on radeon/ati open source driver" [Medium,Confirmed] https://launchpad.net/bugs/144322
<tjaalton> laga: try the package from https://wiki.ubuntu.com/XorgOnTheEdge
<laga> tjaalton: for the ati driver?
<tjaalton> yes
<laga> tjaalton: i compiled it manually from git and it didn't work a few weeks ago. of course, i'll try the package but i doubt it'll be fixed.
<tjaalton> laga: then your best bet is to post your results on the upstream bug :)
<laga> tjaalton: ah. which translates to "it'll never be fixed" because upstream is somewhat unresponsive
<tjaalton> laga: alex happens to work for AMD/ATI now
<tjaalton> so maybe it's not high priority, but will be fixed
<laga> well, i figured it wouldn't be fixed because he's too busy working for them right now :) 
<laga> there's a workaround so i'll be OK, though
<amitk> abogani: that is weird. We don't want to become windows, so it would be good to know what happened... ;-)
<ogra> thegodfather, dropping rpc sevices didnt help with bug 189224 ... i fear its actually the unlock thats broken for me (bug updated)
<ubotu> Launchpad bug 189224 in linux "sunrpc causes kernel oopses on 2.6.24-5-generic" [Undecided,New] https://launchpad.net/bugs/189224
<abogani> amitk: sounds reasonable :-)
<Kano> hi rtg ,did you see that alsa 1.0.16 final is out now?
<rtg> Kano: nope, but I'll pick it up in the next couple of days.
<Kano> i guess not much changed
<Kano> it was out today
<tll> Hi, it's there a rt2x00/rt73usb module backport for the gutsy 2.6.22 kernel through the module-assistant?
<rtg> tll: not to my knowledge. furthermore, its gonna be quite difficult because of changes in the mac80211 API.
<tll> rtg, thanks for answering - I know I'm a bit OT here. So make-kpkg is the only way out? I fear this will break the network-manager et al. stuff.
<rtg> tll: I have not used make-kpg in awhile. It stopped working for me during Gutsy.
<tll> rtg, I just got lazy and stopped using kpg and debian. I hate that the kernel/userlevel interdependency breaks things - so I switch to ubuntu and hope for faster release cycles. :) So here it caught me again. And I was buying ralink for the gnu-feeling ;( 
<rtg> tll: if you can get me open sources for the ralink drivers, I could put them in l-u-m.
<rtg> assuming, of course, that they work with 2.6.24 and have no license restrictions.
<tll> rtg, here: http://rt2x00.serialmonkey.com/rt2x00-cvs-daily.tar.gz, they should work with 2.6.24-rc1 and have no license restrictions, AFAIK, they are the only ones.  
<rtg> tll: the rtl series are already in the kernel: rtl8187_rtl8225.c and rt2x00/
<tll> rtg, yepp I know, so it's dist-upgrading to hardy then?
<Kano> rtg: as far as i know has rt73 problems with networkmanager
<rtg> tll: boot the live CD first. The wireless stuff ought to work (or not as the case may be)
<rtg> I've read that some folks are having better luck with wicd.
<tll> rtg, thanks good idea. I will check the cd and wicd, nm is often painful. 
<tll> Kano, yes and rt73usb is really broken with gutsy and my card. I will try rt73 and wicd, maybe they'll like each other.
<tll> http://wicd.sourceforge.net/wiki/doku.php?id=testing sounds like a hit, thanks. I will try now.
<Kano> with rt2500 others have got not problems, just rt73 seems stupid...
<Kano> rtg: wicd seesm to be a bit stupid, it shows WEP for WPA wlans..
<rtg> Kano: I didn't think WEP was possible for WPA. Perhaps its just a mis-type.
<Kano> it detects it false
<ogra> Kano, i dont have any problems here with the recent hardy kernel and the NM 0.7 packages from asac's ppa 
<ogra> (rt73)
<Kano> well i use hostap to test
<ogra> working fine with WEP here at home as well as with th WPA in our main office ... 
<ogra> i didnt try unencrypted though 
<ogra> that was the only mode that worked reliable in gutsy
<Kano> i never use wep, thats totally unsecure.. well forcing to use wpa1 worked however with that wicd
<maks_> Kano is to lame to have an open network :)
<asac> Kano: nm 0.7?
<Kano> asac: 0.6.5
<Kano> using that with hostap results in system crash after a few transfered bytes..
<asac> Kano: please try nm 0.7 from my ppa
<asac> Kano: do you use wext with wincd?
<asac> wicd?
<Kano> sure
<asac> then try nm 0.7
<Kano> but that wicd is not really stable
<asac> how?
<Kano> usually i write my network/interfaces manually 
<Kano> with that specific card
<asac> but still using wext for supplicant?
<asac> Kano: try https://edge.launchpad.net/~asac/+archive 0.7 in hardy please
<asac> and let me know. thanks
<Kano> asac: i use etch + my own backports
<asac> etch? why would this channel of any help then?
<Kano> asac: i use the ubuntu kernel - just a bit modified
<Kano> anything against reusing the kernel?
<asac> its your system :)
<Kano> btw. there is no network-manager-kde in your archive
<asac> that doesn't exist for 0.7 yet
<Kano> well i need the kde interface
<torkel> asac: will nm 0.7 be included in hardy or is it too late already?
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-7.11 | Latest news: 2.6.24 Release in Hardy | Kernel Team machine: http://kernel.ubuntu.com
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-7.11 | Latest news: 2.6.24 Release in Hardy | Next meeting: Feb 12, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<smb> mjg59: ping
<mjg59> Hi
<smb> Hi Matthew, I was told you would be a good contact regarding my current question of which hdaps driver might be more preferrable for ubuntu hardy. The one in the kernel or rather the one from tp-smapi (includeing the other stuff). For edgy you got tp-smapi into the kernel. But somehow stuff got dropped after that.
<mjg59> The smapi one is probably more useful in the long run
<asac> torkel: most likely hardy+1 (unless upstream goes final soon, which is unlikely imo)
<smb> It looked more recent and more powerful to me. I was wondering why nothing went into the mainline kernel. It was mentioned that this is rather due to some procedural reasons. Do you know a bit more of that history behind that?
<rtg> mdomsch: do you know anything about USB keyboards not working on recent syslinux? Specifically on Dimension E520 and 9200. This is a change in behavior from Feisty to Gutsy.
<amitk> mjg59: is there some question as to the provenance of the tp_smapi code?
<mjg59> amitk: No, I think all those got answered
<amitk> smb: ^^^
<smb> amitk: mjg59: Hm, still the statement from Shen Multinymous was: mainline inclusion will not happen any soon.
<TheMuso> c
<TheMuso> ugh wrong tab
<mdomsch> rtg, nothing here
<mdomsch> hmm, though sounds somewhat familiar
<mdomsch> ping hpa
<mdomsch> rtg, there was something either in syslinux or early boot that hpa had messed up briefly, but thought he had fixed
#ubuntu-kernel 2008-02-07
<kraut> moin
<soren> Does kernel-wedge work out dependencies?
<soren> Specifically, if I'm adding crc32c to debian/d-i/modules/crypto-modules, do I need to add libcrc32c manually, or does it look it up in modules.dep or something?
<tseliot> BenC: can we talk about EnvyNG now?
<tseliot> BenC: there are only two things to approve and it won't take long to review them
<tseliot> BenC: are you there?
#ubuntu-kernel 2008-02-08
<toyo|desk> do any of you in here know when bug #88746 will be patched?
<ubotu> Launchpad bug 88746 in linux-source-2.6.22 "ehci_hcd module causes I/O errors in USB 2.0 devices" [High,Confirmed] https://launchpad.net/bugs/88746
<ln-> let me guess: no.
<toyo|desk> ???
<toyo|desk> oh about my question?
<toyo|desk> dont know thought it would be worth a shot to ask
<toyo|desk> :P
<ln-> yeah. but i'm only a civilian, i have nothing to do with ubuntu development.
<toyo|desk> this bug pretty much renders my external hdd useless
<toyo|desk> as it "dies" randomly
<toyo|desk> when xfering data
 * toyo|desk is half tempted to build his own kernel based off of gentoo or suse or anything that dosent have this issue
<toyo|desk> lol
<ln-> why not switch to another distro altogether.
<toyo|desk> because I like this one, I just dont like that I cant use my external drive
<toyo|desk> :D
<toyo|desk> I used to use gentoo for several years, but that was way too much work, I eventually decided that I wanted to spend time using my computer rather than fixing it
<ln-> well gentoo is quite an extreme case in that sense.
<toyo|desk> switching from gentoo to kubuntu was like switching from an old punch card computer to OSX
<toyo|desk> anyway I am sorta confused by this marking of denied for gutsy on this bug report
<toyo|desk>  Declined  for Gutsy  by Henrik Nilsen Omma  
<toyo|desk> not sure what is up with that
<crimsun> toyo|desk: Ben gave a fairly sensible explanation in one of the comments.
<toyo|desk> oh
<crimsun> (I don't have the URL handy as I've already closed my Web browser.)
 * toyo|desk uses fing
<toyo|desk> df'alskfjlksdf
<toyo|desk> find even
<toyo|desk> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/228
<ubotu> Launchpad bug 88746 in linux-source-2.6.22 "ehci_hcd module causes I/O errors in USB 2.0 devices" [High,Confirmed] 
<toyo|desk> that comment?
<crimsun> toyo|desk: precisely.
<toyo|desk> but did they even figure out why it happens?
<toyo|desk> rather than using workarounds
<toyo|desk> or is this something that is slated to happen upstream at some point
<ln-> even if the cause and fix was known, it doesn't mean the bug would be fixed.
<toyo|desk> hmm yeah I wonder if a bug report exists on kernel.org for the same thing
<crimsun> well, there's an upstream bug.  See http://bugzilla.kernel.org/show_bug.cgi?id=5835
<ubotu> bugzilla.kernel.org bug 5835 in USB "High Speed USB devices don't work when ehci_hcd loaded, work if removed" [Normal,New] 
<crimsun> there seems to be a workaround there, too.
<crimsun> BTW, just a hint from past experience:  if you really, really want a certain something, then clone ubuntu-hardy.git, make the change, get lots of tests and testimony, and /then/ ask for a pull.
<toyo|desk> heh
<crimsun> have you tried David B.'s suggestion?
<toyo|desk> from kernel.org or launchpad
<crimsun> http://bugzilla.kernel.org/show_bug.cgi?id=5835#c72
<crimsun> (the former)
<ubotu> bugzilla.kernel.org bug 5835 in USB "High Speed USB devices don't work when ehci_hcd loaded, work if removed" [Normal,New] 
<crimsun> apologies for the URL spam.
<toyo|desk> the modprobe.conf workaround?
<toyo|desk> no I havent but I should try it
<crimsun> err, please don't use /etc/modprobe.conf, however.
<crimsun> i.e., echo options usb-storage delay_use=1|sudo tee -a /etc/modprobe.d/usb-storage   or thereabout
<toyo|desk> should I then reload the module
<crimsun> yes.  I'm not certain whether it requires a cold power-cycle.
<toyo|desk> :/
<toyo|desk> hmm it seems to be working so far
<crimsun> there's also http://bugzilla.kernel.org/show_bug.cgi?id=8692, which I believe is more relevant to you.
<ubotu> bugzilla.kernel.org bug 8692 in USB "USB storage freeze" [Normal,Assigned] 
<toyo|desk> attempting to xfer 8GB
<crimsun> comments #55 onward in the latter bugzilla entry are notable.
<toyo|desk> ugh I think that one is my true issue the other bugs may have added to it however
<toyo|desk> and yes I do have a VIA chip as well
<toyo|desk> :(
<toyo|desk> my 8GB xfer died at 96%
<toyo|desk> lol
<toyo|desk> so no the delay_use=1 didnt fix it
<toyo|desk> but yeah
<toyo|desk> after reading this thread I dont know if it will ever have a fix
<toyo|desk> guess the best thing to do is either get a usb controller that is not via chip or just deal with it
<toyo|desk> screw it I am due for another pc anyway
<toyo|desk> :P
<toyo|desk> just sucks because it of course works flawless in windows
<bullgard4> Where can I find a description of kacpid? (There exists a acpid man page but no kacpid man page.)
<kraut> moin
<tjaalton> hmm, the latest lrm doesn't have newer nvidia&nvidia-legacy. I'll add those
<Tonio_> hi
<Tonio_> any chance to see bug bug 183000 fixed for hardy ?
<Tonio_> talking about the launchpad bug of course
<Tonio_> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/183000
<ubotu> Launchpad bug 183000 in linux "please consider patch to add CIFS DFS support for hardy" [Medium,Triaged] 
<Tonio_> I can confirm the patches do work correctly, and missing dfs would be a real problem reguarding to lts, in coporate environment....
<Kano> hi rtg 
<Kano> i tried adding ath5k to lum, but somehow it did not compile
<laga> rtg: any ETA on a new LUM uploaded w/ aufs?
<Kano> laga: it has aufs
<laga> oh
<laga> rtg, Kano: just saw it. i must be blind
<Kano> did not check if there would be an update but aufs is included
<laga> yes, i was waiting for a new upload
<rtg> laga, Kano: stuff should be appearing in the archive by now, though I have not checked.
<laga> rtg: packages.ubuntu.com already has it
<laga> that's great news.
<rtg> now, back to fixing FTBS on sparc and ia64...
<rtg> Kano: is ath5k ready for prime time?
<Kano> wanted to test it, also for some others
<Kano> 2.6.25 will have it by default
<rtg> Kano: please do, but I'm not adding it to lum unless its relatively stable and functional. I'll talk to Luiz about it.
<Kano> could you help me a bit with my patch?
<Kano> how to modifiy the Makefile correctly, i added "obj-$(CONFIG_ATH5K)              += wireless/ath5k/"
<Kano> in the ubuntu makefile, added CONFIG_ATH5K=m to config
<rtg> sure, past into pastebin so I can see the whole Makefile
<Kano> but i think i have to modifiy the makefile of ath5k 
<maks_> we have tons of ath5k bug reports
<maks_> currently you need to be lucky afais
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic/source/lum-ath5k.patch
<Kano> thats my test patch
<Kano> ath5k-$(CONFIG_ATH5K_DEBUG)     += debug.o
<Kano> obj-$(CONFIG_ATH5K)             += ath5k.o
<Kano> i guess thats the part to change
<Kano> or do i just need to export CONFIG_ATH5K?
<rtg> Kano: change 'obj-$(CONFIG_ATH5K) += ath5k.o' to 'obj-m += ath5k.o'
<Kano> will try
<Kano> rtg: ok, that does not compile then...
<Kano> maybe too many changed needed
<rtg> Kano: it does not compile because the Makefile is wrong? or the source is wrong? in either case you're on your own.
<Kano> i think it needs changes to the wireless stack
<Kano> as you dont get it alone only as compat pack
<rtg> Kano: that would not surprise me at all.
<Kano> i guess i try a simpler module first like em8300...
<tseliot> BenC: can you review this patch please?
<tseliot> http://albertomilone.com/ubuntu/envy.patch
<tseliot> BenC: ping
<jayc> all: How do I fix this git push error?
<jayc> error: remote 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'. maybe you are not up-to-date and need to pull first?
<rtg> jayc: do a pull first, like it suggests?
<jayc> rtg: Nothing has changed in the remote git, do I still need to pull?
<rtg> jayc: try it, it can't hurt
<jayc> well I tried, and here is the log
<jayc>  Merge branch 'master' of ssh://zinc.ubuntu.com/srv/kernel.ubuntu.com/git/ume/hardy-ume
<rtg> jayc: so, you did 'git pull origin master' ?
<rtg> now try 'git push origin master'
<jayc> no, I just did `git pull`
<rtg> jayc: 'git pull' is shorthand for 'git pull origin master' if your config is setup correctly.
<jayc> ok, thought so
<rtg> what versio of git ? 'git --version'
<jayc> git version 1.5.2.5
<rtg> recent enough. can you now push?
<jayc> yes, 'git pull origin master' went through
<rtg> ok, now 'git push origin master'
<jayc> push also went through
<rtg> when you pull you are synchronizing with the repo. You have to do that if there have been any changes in the repo wrt to your repo.
<rtg> git it :)
<jayc> I'm sure the repo did not change, so I was not sure why a pull was needed
<rtg> jayc: I think amitk rebased against current Hardy 
<rtg> hmm, maybe not.
<jayc> No, I didn't see any log for rebase
<jayc> by the way, I had done a git-rebase  on my local git with ubuntu-hardy
<rtg> jayc: I just noticed that, which is why you had to pull first.
<rtg> you have 2 separate trees, both with common objects, but differe HEADs
<rtg> s/differe/different/
<jayc> git it, I mean got it, Thanks :-)
<rtg> np
<Kano> rtg: can you put that in lum: http://people.redhat.com/~heinzm/sw/dm/dm-raid45/dm-raid45-2.6.24-20080602a.patch.bz2
<Kano> it is usally a kernel patch
<rtg> Kano: is it in the 2.6.24.Y tree ? I thought I saw that one of the 45 stable tree patches dealt with dm-raid.
<Kano> no idea
<Kano> thats the needed dmraid module for raid level 5
<Kano> something nobody fixed since 2.6.20...
<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,Won't fix] 
<rtg> Kano: do me me a favor and attach the patch to the LP report. Be sure to mark it as an attachement.
<Kano> not just the url?
<rtg> No. the whole file.
<Kano> to the old 2.6.20 bug?
<Kano> or a new against 2.6.24?
<Kano> http://kanotix.com/files/gutsy/updates/dmraid/
<rtg> I'm only interested in Hardy. Can't fix older stuff.
<Kano> thats what i made for gutsy, should compile anywhere
<Kano> updated dmraid + patch
<Kano> you need both
<rtg> Kano: add the appropriate info to the bug report. I gotta go, so its gonna have to wait until Monday.
<Kano> ok
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/97655
<ubotu> Launchpad bug 97655 in linux-source-2.6.20 "dmraid45 target please" [Wishlist,Won't fix] 
<Kano> but it is the same as general linux bug
<Kano> usually all info is there already
<laga> Kano: i think he wants you to attach the patch *files* to the LP report
<Kano> so added it
#ubuntu-kernel 2008-02-09
<t105> hi!
<t105> i found some strange entries in my debug.0 : 
<t105> "... CFI: Found no ck804xrom @ffc00000 device at location zero
<t105> JEDEC: Found no ck804xrom @ffc00000 device at location zero"
<t105> ubuntu 7.10 (with xubuntu desktop)
<t105> i looked at mr. google, and it hinted something with sata-nv.c
<t105> (i have that nvidia ck804 on my dell t105 which requires it and 4 gigs of ram)
<t105> i was just wondering, if there is still some issue with that. i couldn't do cdrom install, but at least net install worked.
<t105> when i insert a cdr (it's a sata drive!), a desktop-icon appears but i get the message: "invalid mount option when attempting to mount volume"
<t105> and  there is one line in dmesg: "ck804xrom ck804xrom_init_one(): unable to register resource 0x00000000ffb00000-0x00000000ffffffff - kernel bug?"
<t105> i could attach some log files at launchpad..  just don't know where this might be right
<t105> ok, could be https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/90863
<ubotu> Launchpad bug 90863 in linux-source-2.6.20 "ck804xrom ck804xrom_init_one(): Unable to register resource ... kernel bug?" [Medium,Confirmed] 
<t105> posted my logs :)
<t105> cheers
<kraut> moin
<Kano> hi, did you notice that 2.6.24.1 update is available?
<eradicus> hi i'm getting this error  error: linux/module.h: No such file or directory
<eradicus> what could be the prob, i have linux-sources installed
<laga> you need the kernel headers IIRC
<lsz>  Hi everyone, i met some trouble when compiling the kernel. DNS is not availible now, and there is some error messages about this when booting. Who knows what's the problem?
<lsz> I mean, I can't view any webpages, or go to irc, in that kernel.
<eradicus> thanks laga
<laga> lsz: nobody can help you without the error messages 
<lsz> OK, I will look for that soon
<eradicus> laga, i'm still getting the same error
<eradicus> i've installed kernel-package, btw, i'm on gutsy
<laga> what are you trying to do?
<eradicus> i'm writing a module
<eradicus> *kernel module that is
<laga> ah.
<laga> can't help ya there :)
<Lure> I suspect kernel guys sponsor module-init-tools uploads like bug 114565 ?
<ubotu> Launchpad bug 114565 in module-init-tools "native Garmin-USB no longer working" [Medium,Triaged] https://launchpad.net/bugs/114565
<lsz> Modprobe vboxdrv failed. Please use 'dmesg' to find out why.Starting VirtualBox host networking...done. * Starting Avahi mDNS/DNS-SD Deamon avahi-daemonTimeout reached while wating for return valueCould not receive return value from daemon process.                                                               [fail]
<lsz> the error message was this.
<lsz> anyone knows whats this?
<alex_joni> lsz: did you use dmesg to find out what happened?
<lsz> no, because 1) that message is about the virtualbox, i think, and i don't use that often.
<lsz> 2) i don't know what's dmesg
<lsz> i just want to make the DNS to work
<alex_joni> dmesg is a utility which looks at the kernel messages, simply run 'dmesg' from a terminal
<lsz> oh my god, is it because i didn't turn it on in the sysv-rc-conf?
<lsz> alex_joni: thanks, i know dmesg now.
<lsz> should i reboot to find out that now?
<eradicus> hi Lure, i have linux-sources, module-init-tools, linux-headers and kernel-package, but still linux/module.h could not be found while doing a gcc -c custom_module.c
<eradicus> i have overridden init_module and cleanup_module
<laga> you probably need to specify the include directory
<eradicus> it should be <linux/module.h>
<laga> btw, there's a local root exploit for linux 2.6.16 -  2.6.24.1
<laga> s/16/17/
<ivoks> laga: you have some info?
<laga> it's on milworm, you can also google "vmsplice local root exploit"
 * laga closed firefox in an effort to get something done :)
<ivoks> i've found it
<Mithrandir> this is fixed in .1, right?
<ivoks> and it really works
<laga> Mithrandir: dont think so
<Mithrandir> there were vmsplice-related commits fixing two CVEs for .1
<ivoks> it doesn't affect dapper
<Mithrandir> the sploit doesn't work ootb on amd64 either.
 * laga doesn't have 2.6.24.1 here to try
<ivoks> doesn't work on i386 gutsy
<ivoks> it works only on 2.6.23 and 2.6.24
<Mithrandir> nor on amd64 hardy.
<ivoks> so... i386 on hardy
<Mithrandir> which still sucks.
<ivoks> yeah
<laga> oh.
<laga> there's two exploits
<laga> one works on 2.6.24.1 too
<laga> http://www.milw0rm.com/exploits/5092
<ivoks> nothing here
<ivoks> 50932 is hardy/386 only
#ubuntu-kernel 2008-02-10
<bullgard4> What is the function of kacpid? It seems not to be documented in the kernel documentation.
<mjg59> It's the kernel thread that handles acpi events
<bullgard4> mjg59: Thank xou very much for informing.
<tjaalton> the vmsplice-exploit is for 2.6.17-2.6.24, and verified working on 7.10
<tjaalton> http://blog.bofh.it/id_131
<tjaalton> that's a workaround for now
<h3b> tach zusammen
<bigon> I suppose that everybody is aware of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 ?
<ubotu> Debian bug 464953 in linux-2.6 "linux-2.6: mmap() local root exploit" [Critical,Open] 
<fijam> hello, terribly sorry to bother you but is there any eta on fix for http://bugzilla.kernel.org/show_bug.cgi?id=9924 ?
<ubotu> bugzilla.kernel.org bug 9924 in Other "Two vmsplice local root exploits" [High,New] 
<kraut> moin
<kraut> http://it.slashdot.org/it/08/02/10/2011257.shtml
<laga> wow. slashdot is really quick on the uptake
<kraut> that sounds so ironic ;)
<kraut> hi laga btw.
<laga> it was sarcasm, actually :)
<laga> hi kraut 
<kraut> <Md> kraut: if you have a 32 bit system and you cannot reboot it, you can load this module to block both exploits: http://www.linux.it/~md/software/novmsplice.tgz
<laga> http://it.slashdot.org/comments.pl?sid=448542&cid=22372790
<laga> there's an exploit which blocks the exploit :)
<kraut> lol
<laga> i've just read the comments on slashdot
 * laga removes eyes from head with a spoon
<cbx33> hey guys
<ivoks> hi
<cbx33> any eta for the local root exploit bug fix?
<ivoks> i'm building unofficial kernel packages for 7.10
<cbx33> i'm really interested in official stuff
<cbx33> do you have the fix documented?
<ivoks> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44
<cbx33> is that it
<ivoks> sad, isn't it? :)
<cbx33> yes
<cbx33> very
<cbx33> what a bad rep we'll get
<cbx33> ;)
<ivoks> ah, mistakes happen
<cbx33> indeed
<ivoks> at least we have a fix
<cbx33> ivoks have you tried the workaround script?
<cbx33> the one that adds the RET to the vmsplice memory location?
<ivoks> no
<cbx33> oh
<cbx33> ko
<ivoks> you have a link?
<cbx33> yes
<cbx33> http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c
<cbx33> see if it seems reasonable
<crimsun> ivoks: from backscroll, didn't you say it doesn't affect gutsy/i386?
<ivoks> crimsun: yeah, i did
<ivoks> this is new exploit
<ivoks> and this one works
<crimsun> oh, 3 not 2.
<ivoks> right, 3 doesn't work on gutsy
<crimsun> thank goodness I'm still running 2.2.26!
<cbx33> 3?
<cbx33> 2?
<ivoks> http://www.milw0rm.com/exploits/5092
<ivoks> http://www.milw0rm.com/exploits/5093
<cbx33> oh dear
<cbx33> is the fix the same for both?
<ivoks> i do hope so... :)
<cbx33> can't wait till the official fix is released
<ivoks> i have only one problematic server...
<cbx33> me too
<ivoks> all others are 6.06
<ivoks> or don't have users at all
<cbx33> no users at all?
<cbx33> or no users apart from ones you know
<ivoks> except me
<cbx33> ;)
<cbx33> yeh that's what mine are like
<cbx33> but i still want them patched ;)
<ivoks> of course...
<cbx33> maybe I'll recompile kernel
<cbx33> give me something to do
<cbx33> what's the official docs on kernel com/recompiling
#ubuntu-kernel 2009-02-02
<tjaalton> is the kernel frozen for alpha4 or are there going to be (non-ABI breaking) fixes coming in before a4?
<tjaalton> there's one particular patch for the drm subsystem, which would fix the problem with lost interrupts after a VT change (on intel gfx)
<tjaalton> it's not committed upstream yet, since they are still discussing if it's the right fix
<tjaalton> the bug in question is 320813
<rtg> tjaalton: there is still time, especially for something like this.
<rtg> I'd like to wait until it's actually committed to Linus tree (if that happens in time)
<tjaalton> rtg: ok, I hope it'll be committed by tomorrow
<tjaalton> upstream
<tjaalton> Linus actually signed-off the first patch :)
<rtg> tjaalton: please drop a note on the mailing list since I'm in Berlin at a sprint
<tjaalton> right, I'll forward the current patch
<lamont> rtg: now can I have an installable linux-hppa32/hardy-updates?  (makes installing _so_ much easier... :(
<rtg> lamont: uh, dunno. smb has been doing that. I'll be seeing him for beers shortly.
<lamont> heh
#ubuntu-kernel 2009-02-03
<emgent_> smb_tp: ping
<smb_tp> emgent_, pong
<Ng> is there a xen kernel for jaunty?
<TheMuso> apw: Do you have those rebase script tweaks in a git repo yet? If so I should take a look at them as part of my getting linux-libc-dev for !x86/armel upoaded.
<TheMuso> apw: Sorry, I'm on IRC for somewhat longer than I was just earlier.
<TheMuso> apw: Never mind, I see the lpia upload. I'll pull that tree and have a look.
<apw> TheMuso, yeah rebase-lpia should be the right one in the lpia tree
<TheMuso> apw: Yeah got it, I'm going to use rebase/retag-lpia and change them for ports and use them as a base.
<apw> TheMuso, cool.  if you need to ask anything about how its intended to work etc yell
<TheMuso> apw: Thanks, but I think I'll be right.
<praveen> is there any way for a thread to figure out if its is being traced by someone or not
<TheMuso> c
<TheMuso> apw, smb_tp, I am making progress. apw I have rebased based on your new script changes. Just need to make a few more changes before I'm willing to upload a git tree. I should have something ready tomorrow morning, given I'm not pulled away for discussions/meetings.
<apw> TheMuso, that is awsome
<smb_tp> TheMuso, Great
 * lamont has a kvm/intrepid question...
<lamont> so kvm host with winxp runninng inside it (so shoot me)... if the kvm window is in another workspace, it appears that (at least) when the windoze app is doing I/O, that it blocks because the window isn't in the foreground workspace...  how do I beat that into submission^W working anyway?
<lamont> no libvirt involved here - that makes me cry somewhat
<soren> lamont: JOOI... Compiz or no compiz?
<lamont> metacity
<lamont> metacity
<soren> Could you try with compiz? Just for fun?
<lamont> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<lamont> soren: that involves figuring out who to actually turn on compiz... and all of the pain that it causes
 * soren has a half baked hypothesis about the cause of this
<soren> lamont: just do "compiz --replace" in a terminal.
<soren> lamont: And when you get bored with all the wobbliness, do "metacity --replace".
<lamont> soren: the only really-missing bit from compiz for me is keyboardFocusPolicy == strict
<lamont> which, uh, is documented in the source of metacity...
<lamont>  :-)
<lamont> and available via gconf-editor
<lamont> well, that seems to have let it finish running
<lamont> I'll give it a better test next time I boot the beatsy
<lamont> beasty, even
 * lamont likes the way compiz/metacity --replace hijacks the terminal window by not daemonizing.
<lamont> well, maybe 'likes' isn't completely accurate
<soren> It's a feature.
<lamont> soren: for many bonus points and beers, port metacity-2.24.0/debian/patches/001_strict_focus.patch to compiz
<lamont> Q: when does the newly created window get focus?  A: NEVER
<lamont> soren: http://paste.ubuntu.com/113264/ explains _why_ switching to compiz didn't change anything...
<lamont> in that it didn't switch
<kennethr1> I think I'm getting a kernel panic on 8.10 via Wubi on Vista....I'm suspicious of the wireless...Broadcom BCM4311...how can I enable dumps/get  a backtrace?
<oly562> im trying to load this webcam, can someone help me out? im pretty good with linux, and it shouldnt take too long, i just need some tips or clues ok? let me know what you want displayed from cmdline and i will provide any info that you may need. thanks!!
<kennethr1> oly562: is it USB-attached?
<kennethr1> oly562: did you try just plugging it in?
<oly562> usb
<oly562> 2.6.24-19-generic
<oly562> Bus 005 Device 023: ID 041e:403d Creative Technology, Ltd WebCam Notebook Ultra
<oly562> kennethr1: you good with linux mods and drivers? web cams specifically
<kennethr1> oly562: what are you trying to do?
<oly562> your kidding right kennethr1 lolol
<oly562> nevermind dude. you should know by now
<kennethr1> oly562: no, I mean what isn't working
<kennethr1> oly562: are you trying to use skype? cheese? what?
<kennethr1> what's the problem
<oly562> cheese doesnt see it 
<oly562> camorama neither
<oly562> nor kopete
<oly562> so forth
<oly562> im trying to have my cam at least work locally
<oly562> on linux of course
<kennethr1> you're on 8.04?
<oly562> yes
<oly562> LTS
<oly562> VF0070 is my model for cam
<oly562> k so
<oly562> kennethr1 really didnt have much info did he
<oly562> lol
<kennethr> How can I enable kernel panic dumps?
<kennethr> How can I enable kernel panic dumps?
<maco> hi kernel people. ive been looking at bug 272530 for a while, and it's turning out to be something that can be fixed on some machines using a bios update. on other machines, the most recent bios doesn't help. i'm guessing it's still a bios bug, just one that's being ignored by some manufacturers. should it be invalidated, or is there some way the kernel can work around the issue?
<ubot3> Malone bug 272530 in linux "64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory" [High,Triaged] https://launchpad.net/bugs/272530
<dtchen> it's very much still a bios bug. if enough info is provided, namely dmidecode, it could be warned during boot.
<maco> dtchen: dmidecode? i dont know how to tell them to get that info
<maco> dtchen: and when you say "warned on boot" do you mean throwing up a "you have a bios bug, so this won't work" message or finding a way to work around it?
<dtchen> the former
<dtchen> dmidecode is shipped by default
<dtchen> in fact, some of the necessary info is already grabbed during boot; see /var/lib/acpi-support
<maco> oh just "dmidecode > dmidecode.txt"?
<dtchen> specifically, see /etc/acpi/start.d/10-save-dmidecode.sh
<praveen_> hiiii....i tried to fork a child and then create several threads in the child made each one of them say ptrace_traceme. Then I watched thoses threads execute and i observed that all threads become zombie. But the output of the ps command showed parent alive. Can anybody explain this thing
#ubuntu-kernel 2009-02-04
<philsf> hi, can someone please take a look at the following kernel traces? http://pastebin.ubuntu.com/113482/
<philsf> I'm not even sure what to put in a bug report, if this is the case. I think I'm having troubles similar to the closed bug #154591, in hardy (up to date)
<ubot3> Malone bug 154591 in linux "7.10 live cd does not boot, the error: udevd-event[2292]: modprobe abnormal exit" [Undecided,Fix released] https://launchpad.net/bugs/154591
<IntuitiveNipple> philsf: Post a new bug, subject "BUG: unable to handle kernel paging request" and tag it with "kernel-oops". Make sure to *attach* files with the reports requested at https://wiki.ubuntu.com/KernelTeamBugPolicies
<philsf> IntuitiveNipple: thanks
<TheMuso> Are you guys interested in troubleshooting a suspend/resume issue? On my macbook pro, suspend/resume fails if I am using the FOSS nv driver, yet resume works if I am using proprietary nvidia drivers.
<Kano> hi, it seems there is a depend on grub when you REMOVE kernels, why is that?
<Kano> when you installed grub-pc (grub2) it should work too
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=86eda75b0b200cf158efa007a94e1842ba9292cc
<Kano> bad comment
<henrik-hw0> rtg: what's the status of the rt2860 kernel that appears to have been included in the ubuntu kernel? can i assume it's based on the manufacturer supplied drivers?
<Kano> henrik-hw0: nope from staging, tested it first, u adopted it
<henrik-hw0> Kano: I just figured it it already was included there would be no point for me packaging it.
<Kano> and the firmware too
<henrik-hw0> Kano: Pardon the stupid question but does being in "staging" mean it's included in the source linux package but disabled?
<Kano> its the test section for new drivers
<henrik-hw0> I see...
<TheMuso> \/c
<Keybuk> err
<Keybuk> how does one set the essid of an interface in jaunty?
<rtg> Keybuk: iwconfig?
<Keybuk> that wasn't working
<Keybuk> NM it seems
<oly562> hello
<oly562> i am new to kernel mod builds and kernels on linux. Id like to follow the LDD3 book this next few months and learn how to build drivers. I am running ubuntu 2.6.24-19-server. im trying to follow the book, im currently in chap one and they have stated i need the build dir. it's there. now, im trying to run the hello.c file i just created from code example. Could someone help me a bit, as the Makefile or make cmd. also, where shou
<oly562> i will be able to follow along pretty well. i am ready for this challenge
<laga> oly562: hum. this is probably not the right place to ask.. maybe the ubuntu-kernel mailing list might be better.. also, your message got cut off :)
<laga> or maybe the kernelnewbies channel, but i'm not sure if they like distro kernels that much
<oly562> ic
<oly562> oh
<oly562> ugh lol thanks for telling me about the message
<oly562> where did it cut? last few words pleae
<laga> make cmd. also, where shou
<oly562> k
<oly562> thanks
<IntuitiveNipple> oly562: Your best bet is to look at the source code for the kernel, especially the individual drivers. Pick a small one and look at its Kbuild and Makefile to get an idea of how it is done.
<oly562> yah maybe in a year, i will come back and hang in here lol
<oly562> k
<oly562> im in the process of trying to git the kern code
<oly562> reading this now
<oly562> https://help.ubuntu.com/community/Kernel/Compile
<oly562> whats the cmdline version of synaptic called? trying to apt-get it
<oly562> this server is in init 3
<oly562> by choice
<oly562> i just started using ubuntu last month
<oly562> coming from rh and centos
<oly562> linux speaking
<oly562> dpkg?
<oly562> i thought there is a apt-get none gui prog
<oly562> but runs in cmdline with pretty colors
<oly562> menus so forth
<IntuitiveNipple> Use "sudo apt-get install git-core"
<IntuitiveNipple> then, create a directory to work in (I have a directory /home/all/SourceCode/) where all source packages are put
<oly562> adept?
<oly562> k
<oly562> ok
<oly562> perfect
<oly562> where will the source packages be? after git-core is installed
<oly562>  /lib or /usr/src
<oly562> and where do i run the make from ?
<oly562> sorry
<oly562> this is what stopped me in the past from continuing this journey... sighs
<IntuitiveNipple> See https://wiki.ubuntu.com/KernelGitGuide for info on downloading the Ubuntu kernel releases
<oly562> also when i reboot, will i need to modify grub menu?
<oly562> k
<IntuitiveNipple> For an installed system, the kernel headers are in  /lib/modules/`uname -r`/build
<IntuitiveNipple> 'build' is a sym-link to the actual kernel headers location
<oly562> ok
<IntuitiveNipple> must go, dinner time
<oly562> thanks nipple:)
<oly562> hah interesting nic
<oly562> ok, got it, sym-link. so for my hello.c should i place that in the build dir? or ~/home/someone/SourceCode
<oly562> i dont see how the make will find the file in my home dir
<oly562> so i do a symlink from home dir to .../build?
<oly562> i have no .config custom kern build. will i be able to do this in cmdline? i have no Xserver running. its a server
<oly562> im reading those links now.  bbiab
<oly562> please feel free to respond
<oly562> :) 
<oly562> is the term headers the same as saying kern source?
<TheMuso> oly562: No. The kernel source is the entire kernel source. Headers are only the header files needed to build modules outside the kernel.
<oly562> if i wanted to copy the "kern source" what directory is that?
<oly562> k
<oly562> where is the kernel source located
<oly562> typically by default if you git or grab it from cd during install
<TheMuso> oly562: Depending on the version of Ubuntu you are using, you would install the linux-source-kernelversion package, where kernelversion is the version of the kernel that Ubuntu on your system uses.
<oly562> hardy
<oly562> server kernel .19
<TheMuso> oly562: So linux-source-2.6.24 is the package you want. However if you would rather work with the git repo, then you need to isntall git-core, and clone the git repo to your machine and work on it there.
<oly562>  uname -r
<oly562> 2.6.24-19-server
<oly562> cp the git-core to a dir?
<TheMuso> yep so as I said, if you just want a source tarball of the kernel in use, install linux-source-2.6.24
<oly562> im not interesting in current
<TheMuso> oly562: No, you use the git clone command, git clone git://url.to/hardy-kernel.git
<oly562> this is just for testing and learnig from a bood
<oly562> book
<oly562> ok.
<oly562> where with git store this information
<oly562> so i can "clone" copy it to another dir
<oly562> i wouldnt want to ln -s it would it from that dir? and save some disk space would i?
<TheMuso> git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git
<oly562> yes i got that TheMuso
<oly562> what does the clone command do?
<oly562> just grabs the sources and puts in the cur dir?
<TheMuso> oly562: the clone command downloads the git repo and puts it in the current directory
<oly562> and once i have the source in a dir of my chose, i can do kernel mod builds in there?
<oly562> ok got it
<oly562> and.. build? from there as well?
<TheMuso> Yes
<TheMuso> If you only want to build modules against the kernel you are using however, you simply need to install linux-headers-2.6.24-19-server
<oly562> ok. once i build a new image, kernel, however it's called, i can then install it. right?
<TheMuso> If you make a deb package yes you can
<oly562> i have the headers installed they are in /usr/src
<oly562> hmmm... can you say a little more about that. or post a good ubuntu url for me to read up on that.. deb packaging?
<TheMuso> go to http://wiki.ubuntu.com/KernelCustomBuild for more information.
<oly562> all start grabbing the source , its like huge. isnt there a smaller one?
<oly562> got that link actually, just trying to clarify a few things, since im new to linux mod and kernel builds
<oly562> ill be doing this in cmdline , not using any gui 
<oly562> can you do a trunk'd post here for example of your /usr/src/uname... header/ what dir's i should see in there or say a few?
<oly562> ic arch block .config, crypto, Docum, drivers, kernel, Kbuild
<oly562>  du -sh /usr/src/linux-headers-2.6.24-19/
<oly562> 59M	/usr/src/linux-headers-2.6.24-19/
<oly562> and...
<oly562>  du -sh /usr/src/linux-headers-2.6.24-19-server/
<oly562> 7.0M	/usr/src/linux-headers-2.6.24-19-server/
<oly562> there is a big diff in size of those two dir's
<oly562> i would assume the 59m is the right one
<oly562> but. im running server as uname -r states
<oly562> i dont get it?
<oly562> its it becuz i did an upgrade or apt-get update b4 in the past?
<oly562> thanks 
<oly562> trust me all that you guys are saying is really helping me understand things now
<oly562> i have read things from the links, but i need to be certain of things. the howtos are not Always that clear
<oly562> im very cautious about loading things on my nix servers
<oly562> as you all well know, you can kill a box quickly ESpecially with kernel tuning and mod's, programs that require deps that BReak other progs, and hardware
<oly562> so... any info i may ask, will be greatly helpful
<oly562> git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git  is downloding
<oly562> 657,000 objects .... sighs
<oly562> at 588 kiB/s
<oly562> i guess about 20 mins there about, giving my buggy charter connection lately doesnt die...
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/209901
<ubot3> Malone bug 209901 in linux "webcam Logitech QuickCam Messenger  ID 046d:08f6 is not reconized" [Medium,Fix released] 
<Kano> did anybody patch that driver for 2.6.28?
<Kano> ubuntu has patches for 1.8, you need 3 
<Kano> err gentoo
<Kano> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/qc-usb-messenger/files/
#ubuntu-kernel 2009-02-05
<Kano> hi rtg ,did you read my mail about the webcam module?
<Kano> rtg: qc-usb-messenge
<Kano> together with all needed patches
<rtg> Kano: I have and am still considering them. It'll be next week before I can get back to them.
<Kano> well right now i did a dkms package, but would not hurt when it would be inside the kernel...
<Kano> just yesterday somebody had this webcam
<devillj> hi - i have a problem installing ubuntu server.  It keeps winging about pae support on the cpu. im using a mini-itx board with a c3 cpu - it have no pae support. Ive tried loading the virtual and generic kernels - they all have the same problem.  Is there a stock kernel i can use for ubuntu 8.10 or must i learn the black art of compiling my own ?
<Kano> use the generic one, that does not need pae
<devillj> it does - tried it about 2 hours ago
<devillj> fresh apt-get an all
<bgamari> Does Canonical employ any kernel developers?
<bgamari> particularly block I/O developers?
#ubuntu-kernel 2009-02-06
<BUGabundo> guys
<BUGabundo> can anyone take a quick look at https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/326142
<BUGabundo> ?
<ubot3> Malone bug 326142 in powertop "FATAL: Module cpufreq_stats not found." [Undecided,New] 
<BUGabundo> just trying to be sure, if it was simply removed from the kernel loaded modules
<henrik-hw0> rtg: got a minute?
<Keybuk> *sigh*
<Keybuk> nowhere can I find code to write the system clock back to the hardware clock
<Keybuk> there's a patch on lkml, but only for NTP
<soren> Keybuk: I thought hwclock did that?
<Keybuk> it does, if you remember to run it
<Keybuk> it seems to be one of those things that the kernel doesn't do "just because"
<soren> Ah, clever.
<Keybuk> to counter-point, the kernel _does_ set the system block from the hardware clock
<Keybuk> and does maintain the system clock across a suspend/resume
<maxb> Keybuk: What about this bit? http://lxr.linux.no/linux+v2.6.28.3/kernel/time/ntp.c#L224
<Keybuk> that's NTP-specific
<Keybuk> unless I'm reading this wrong
<elmo> doesn't the kernel use NTP internally?
<elmo> at least, I thought I recall discussions about heading in that direction, but I may be on crack
<Keybuk> how does it get to the NTP servers?
<Keybuk> kernel/time/ntp.c seems to be simply the implementation of adjtimex()
<maxb> Hi, is the deprecation of /proc/bus/usb documented anywhere in the upstream kernel?
#ubuntu-kernel 2010-02-08
<mirsal> hello
<lool> apw: Heya; on that ABI check issue with versatile, ISTR that you sometimes simply disable the ABI check and then download the ABI from the archive; is this what you would do in this case, or will you try updating it before upload?
<lool> apw: let me know if I can help removing this (IMHO last) blocker before upload
<apw> there wasn't an issue with the abi in my build, it was failing to build full stop
<apw> i am rebuilding it now to confirm i was not going mad
<apw> three scsi drivers i think it was, but i don't have the logs, hense the rebuild
<apw>   CC [M]  drivers/scsi/advansys.o
<apw> /home/apw/build/lucid/ubuntu-lucid/drivers/scsi/advansys.c:72: warning: #warning this driver is still not properly converted to the DMA API
<apw>   LD [M]  drivers/net/e1000e/e1000e.o
<apw> /home/apw/build/lucid/ubuntu-lucid/drivers/scsi/advansys.c: In function 'advansys_get_sense_buffer_dma':
<apw> /home/apw/build/lucid/ubuntu-lucid/drivers/scsi/advansys.c:8352: error: implicit declaration of function 'dma_cache_sync'
<apw>   CC [M]  drivers/net/hamradio/mkiss.o
<apw> make[4]: *** [drivers/scsi/advansys.o] Error 1
<apw> make[3]: *** [drivers/scsi] Error 2
<apw> make[3]: *** Waiting for unfinished jobs....
<apw> lool there is one of them
<apw> arch/arm/include/asm/dma-mapping.h: * Dummy noncoherent implementation.  We don't provide a dma_cache_sync
<apw> and arm claims to not support it, so ... lool how did you build it?
<lool> apw: See my latest merge request
<lool> apw: I fixed this in my second pull request
<apw> so you didn't test the first one?
<lool> apw: I apologized in the email because "make modules" seemed to succeed, but actually failed earlier in the log
<apw> ok
<lool> apw: I did make zImage (works) and make modules wihch I thought worked, but failed somewhere in the middle of the log
<apw> ok
<lool> apw: I'm used to getting "make error blahblah" at the end, but the kernel build process didn't print this which is why I missed the error
<lool> apw: Sorry about that
<lool> apw: I actually tested a .deb build for my second pull request, and it failed in the abi check stuff
<lool> Well I included the command I ran in the email
<apw> thats fine, you probabally would expect that
<apw> you've changes things radically
<lool> Sorry?
<lool> Ah my radical changes cause the abi change
<apw> you've changed the configuration radically, if that didn't trigger an abi bump i'd be worried
<lool> So my question above is how you'd like to handle it, either by building and updating ABI before upload or whether you'll disable the check, upload and then download the ABI from the archive
<lool> And whether you want a patch for that
<apw> i'll probabally do none of the above, and integrate .7 which will naturally trigger a bump and upload that
<apw> once its building
<lool> apw: Ok; I'm around if you have any question WRT to the latest pull request which should fix the first one
<apw> so is that lot on top of your previous push?
<lool> apw: No
<lool> apw: it's really readable
<lool> There were 3/4 distinct issues with modules, and then I also added patches to enable the ubuntu/ tree
<apw> it contains no information about what its based on that i can see and if its not on the previous push what is it on top of
<apw> if you use git request-pull it would tell me for free
<lool> apw: I didn't know about git request-pull
<lool> apw: it should be based on master after you merged my patches, but I'll recheck
<apw> ahh, yeah that is how most people generate those emails
<apw> ok, so on top of your previous stuff then
<lool> It's on top of 7784853ab4d2cb97b636554909b9f08b9ca2231a
<lool> Which is the merged UBUNTU: [Config] Large update to armel/versatile
<apw> ok got it
<apw> i'll juggle my tips to make it work out thanks
<apw> lool can i assume you've boot tested the result of this build, or do you want me to make some test .deb's
<lool> apw: I boot tested the zImages
<lool> apw: As I note in my email, the only thing which was needed to have useful kernels was the RTC clock fix
<lool> The only two issues I'm aware of with the kernel are kexec hanging (but that's a while topic of its own) and virtio hanging if you try to force building them in, but that's not expected to be supported anyway
<lool> http://paste.ubuntu.com/371586/ that's my TODO of stuff I worked on since the first pull
<apw> ok
<lool> NB: I don't actually have versatile hardware, it might be that the kernel doesn't work on versatile hardware, I only test in qemu -- that's probably obvious but just in case    :-)
<lool> apw: How do you mention a branch with git request-pull?
<apw> you push it up, and while on it _locally_ you make the request
<apw> that then confirms that the local branch is exposed under some name and reports that one
<lool> Ok; it's interactive then, thanks
<lool> I was surprized that the command-line flags and man page didn't mention that
<apw>        git request-pull <start> <url> [<end>]
<apw> its 'end' there, note though that its a _local_ sha1
<lool> Yeah, there's no branch name there
<apw> its an ending commit, the key is that some branch name on the remote points at it
<apw> you can in theory do
<apw> git push zinc <random sha1>:BRANCH
<apw> and git request-pull <random sha1>~N <url> <random sha1>
<apw> and expose N patches from that sha1
<lool> Ok; I'm used to manipulating branches and mentionning branches to other people, not SHAs, but SHAs are probably more robust
<apw> well thats the thing, if you just use branches it works
<apw> git push zinc BRANCH
<apw> git request-pull BRANCH~N <url> BRANCH
<apw> stylee
<apw> its just that the branch in the second one doesn't have to match what you pushed, and what its called UP THERE is what it gets named in the output
<apw> git push zinb FOO:BAR; git request pull FOO~4 <url> FOO
<apw> will mention BAR in the email, as thats what i a remote person can see
<lool> apw: Ok makes sense, thanks
<lool> apw: The wiki mentionned "SHAs" but it's really any revspec so a branch name will do and it's not as inconvenient as it seemed on my first reading
<apw> yeah
<apw> generally they write commit-ish, which once you know it means 'anything' is fine
<apw> i think the most confusing part is the disconnect between whether they are local or remote
<apw> rtg whats the best way to review the currently built-in subsystems, we wanted to review whether them being builtin really helps us any for lucid.  perhaps i shoudl prepare a list of what we builtin and send that to kernel-team for discussion?
<tgardner> that seems like a reasonable approach. I know BenC was annoyed by some of the PATA stuff being built-in.
<mirsal> ogasawara_, ayt ?
<ghostcube> hmm ureadhead is crashng on my karmic sometimes 
<ghostcube> how can i get the problem inside any log ?
<ghostcube> i see this on bootup deamon crashed for ....
<mirsal> ghostcube, https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe
<mirsal> ghostcube, I don't know if this is what you are looking for
<ghostcube> mirsal: thx, but maybe this isnt so well for what i wanna do The LKCD utility is not designed to gather helpful information in the case of a hardware caused panic or a segment violation
<ghostcube> i think its caused by any hardware
<ghostcube> but i willt try :)
<mirsal> ok :/
<CShadowRun> does anyone know how to revert an update? my friend just did an update on a fresh install of karmic and is now getting "Kernel Panic - not syncing: for safety"
<CShadowRun> or does anyone have any suggestions on how to debug this problem
<apw> CShadowRun, they should have older kernels on their machine, hold left shift to get the boot menu and select an older one
<apw> _if_ its the kernel which is broken
<CShadowRun> yea, that's what I thought, but tried it but the problem persisted
<apw> any idea what the panic itself is?
<apw> as thats the last line of it iirc
<CShadowRun> nope, it just says that
<CShadowRun> we saw it shortly after loading gdm and then switching to a tty
<CShadowRun> is there any log file we can look at that might tell us?
<apw> if gdm has come up it has booted most of the way
<CShadowRun> yea, he says he gets to login and mull around for a couple of minutes then it dies
<apw> i am pretty sure there is normally more than one line associated with that Kernel Panic line, either before or after it
<smb> Then maybe try to run it nomodeset?
<apw> if the machine is mostly up when it occurs there may be a full log in the /var/log/syslog or /var/log/messages
<smb> Also is it crashing just sitting on gdm or when you try to log in?
<apw> and can you login over the network when it crashes
<apw> you may be able to see the dump occuring on a pre-logged in remote connection
<CShadowRun> apw yea, definitely that's the only line
<CShadowRun> smb: we'll try nomodeset now
<CShadowRun> smb it crashes after a few minutes of being up no matter what, whether we login, sit at gdm, or use a tty
<CShadowRun> if nomodeset doesn't work we'll try and install openssh-server but it may well kernel panic during that
<smb> CShadowRun, Hm ok, so maybe you might be able to switch to vt1 and do a tail of /var/log/syslog...
<CShadowRun> smb the tty freezes aswell when the panic occurs
<apw> so it may be worth loggin in on VT1 and tail -f /var/log/messages ... also perhaps while :; do; dmesg; sleep 1; done on VT1
<smb> CShadowRun, The question was just whether you can quickly enough change to that and get log in before the crash. Another thing might be to narrow thing: to use "text" as kernel argument and avoid starting gdm at all
<CShadowRun> well we can do cat /var/log/syslog... before the crash
<CShadowRun> but surely that's useless?
<apw> no what we are saying is sometimes you cannot type any more
<apw> but output and applications which are already in cache can continue
<CShadowRun> oh
<CShadowRun> i see
<apw> so a script which output that file before the crash _may_ beable to do it later
<CShadowRun> we'll try to run while :; do; dmesg; sleep 1; then
<apw> yeha something like that _may_ be able to output more
<apw> you could also make sure loglevlel is high, loglevel=8 on the grub line
<CShadowRun> syntax error near unexpected token ';'
<apw> no ; after the do
<CShadowRun> so we'll try booting with loglevel=8 and text this time?
<smb> booting with debug on the command line also increases the amount of messages 
<smb> Meaning "debug" as a argument to the kernel command line
<CShadowRun> ok so ro text loglevel=8 debug quiet ?
<CShadowRun> we are just editing the line in grub
<apw> drop quiet
<smb> yeah
<CShadowRun> ok
<CShadowRun> I dropped splash too
<CShadowRun> we booted with that, still got the same single kernel panic line
<apw> and how long after boot do you get it, 
<apw> do you get a login prompt on VT-1
<CShadowRun> he says it freezes after about 10-15 seconds
<CShadowRun> and yea we get a login prompt
<smb> From the sound of it (as the original kernel now dies as well) it feels like either something not related to the kernel package or coincdental dying hw
<CShadowRun> while :; do dmesg; sleep 1; then -> bash: syntax error near unexpected token `then'
<CShadowRun> yea, maybe something else in the update is causing it
<CShadowRun> got no idea what though.
<CShadowRun> aha made the bash work :)
<smb> True. Still the "panic not syncing" sounds like kernel. But normally that goes with a backtrace of th failing code...
<CShadowRun> gonna try to type that fast and hope for more information
<CShadowRun> apw "while :; do dmesg; sleep 1; done" stops when the segfault occurs, nothing in the output about a backtrace
<apw> and you booted thre with the loglevel=8 ?
<CShadowRun> not this time sorry, we'll boot with that now
<CShadowRun> weird, the panic isn't happening this time
<CShadowRun> also, the number before the line in dmesg is the uptime right?
<CShadowRun> apparently every time it panics, it's always 42
<tgardner> apw, plymouth ? I had to remove it from my nVidia laptop
<apw> tgardner, yeah i think we are waiting for that to be resolved still
<tgardner> apw, i meant wrt to CShadowRun's issue
<apw> CShadowRun, karmic or lucid in your case?
<CShadowRun> karmic
<tgardner> nm
<apw> ok so not plymout
<apw> CShadowRun, you said 'when the segfault occurs' what made you chose those words
<CShadowRun> brain fart, lol
<CShadowRun> it doesn't say anything about segfault
<CShadowRun> apparently it's just randomly stopped freezing
<CShadowRun> ...weird, maybe a hardware issue?
<CShadowRun> it's very old hardware so that wouldn't suprise me
<apw> its a bit scarey
<tgardner> CShadowRun, how old? has it run stable on any other release?
<apw> does this have an adaptec scsi controller
<CShadowRun> tgardner: uhh, amd 1600mhz processor, 256mb ram, 20gb hard drive sort of old.
<CShadowRun> and no, he's just got it as a chuckout, it's been sitting in a cupboard for a while
<tgardner> CShadowRun, did you install X ? perhaps you should try just the server to begin with.
<apw> CShadowRun,  does this have an adaptec scsi controller ??
<smb> CShadowRun, Just trying to get down what could print that "for safety"... Is there an adaptec SCSI controller involved?
<CShadowRun> tgardner: well yea, X ships with karmic, it's just a normal karmic installation
<CShadowRun> hmm, how would I find out?
<apw> well if its up
<apw> then lspci
<smb> or in the worst case open the thing... 
<tgardner> or open the cabinet and look? something that old will likely have a discrete adapter
<tgardner> if not, the BIOS will display some info
<smb> Right, those adaptec bioses had there own message whn booting
<apw> ok yeah if the message was "Kernel panic - not syncing: for safety"
<apw> CShadowRun, that exact form, then its a panic for "for safety"
<apw> and those seem to be only in adaptec code
<apw> hrm ... recipent overload?
<tgardner> apw, its probably a HW issue, which is why it was in the chuckout bin to start with
<CShadowRun> nope, doesn't look like it has an adaptec in it
<CShadowRun> lspci | grep -i adaptec returns nothing
<apw> lsmod | grep aic ?
<CShadowRun> apw nope, nothing
<apw> well that interesting
<apw> you have no adaptec h/w and are getting mesages which only exist in adaptec drivers
<apw> you are a magician
<CShadowRun> apw: I have a reputation in ubuntu-uk of breaking...everything, somehow magically
<CShadowRun> so, that pretty much fits my everyday life :P
<apw> hrm
<apw> so push your lspci to a pastebin somewhere perhaps
<apw> and we can stare at it confusdly
<CShadowRun> apw: http://pastebin.com/f27ed6049
<CShadowRun> hmm, check out that unidentified SCSI storage controller.
<CShadowRun> maybe that's an adaptec device in disguise...
<apw> yeah could be, 9004 5078 would be one
<apw> CShadowRun, can we have your dmesg please
<CShadowRun> apw: http://pastebin.com/f8205eba
<CShadowRun> apw this is from a suscessful boot obviously
<CShadowRun> with no crashes as of yet
<tgardner> pata_via ?
<apw> [    0.838079] pata_via 0000:00:11.1: version 0.3.4
<apw> ok ... i am suspicious that you have h/w issues
<CShadowRun> I'm suspicious that it's a hardware issue too now since it's intermittant
<tgardner> apw, perhaps, but DMA issues might be intermittent.
<tgardner> CShadowRun, can you run the mem test for awhile?
<apw> as the adapetek driver looks for 9004 and you have 9204 which is via when it works
<CShadowRun> tgardner: yup
<apw> it may be time to push all the cards in
<CShadowRun> tgardner: we ran that yesterday and it passed
<CShadowRun> Oh well, seems to be working for now, I guess I'll chalk it up to hardware issue
<tgardner> CShadowRun, get the server edition and install that. it cuts out X and other GUI cruft
<CShadowRun> he wants it for office use though
<CShadowRun> so that kinda defeats the objective :P
<tgardner> CShadowRun, it will at least help isolate your issue. you can always install ubuntu-desktop after the fact
<CShadowRun> I guess
<CShadowRun> if it happens again we'll give it a shot
<mirsal> apw, ping
<AlanBell> ping bjf - want to talk about mootbot and moinmoin?
<JFo> apw or smb, I think we discussed at one point, but how do we set number of CPU's for the kernel?
<tgardner> JFo, you mean on boot?
<JFo> is it just a runtime option or can we specify in a config somewhere
<JFo> tgardner, maybe :)
<smb> JFo, maxcpus=x
<smb> JFo, on boot
<JFo> cool
<tgardner> JFo, there is also a maximum number supported, 64 on Amd64
<BugeyeD> what's the upper limit set to when building the kernel?
<JFo> I've been told that suse sets them way high. 128 for x86, 4096(!) for itanium
<BugeyeD> sorry, too late
<smb> JFo, hot removing them should work in theory but yields not to good results
<JFo> I see
<JFo> so we could, theoretically set them to some huge number?
<JFo> say 200 if we had them?
<JFo> BugeyeD, no problem
<BugeyeD> is 64 the same for workstation and server kernels?
<smb> JFo, I believe that requires more memory for the per-cpu arrays. Not sure how much the penalty is
<JFo> ah, ok
<JFo> but it is doable. do we have upper limits on the numbers smb?
<smb> JFo, I would have to use the source which I am too lazy right now... :/
<JFo> BugeyeD, you mean x64 CPU numbers yes?
<BugeyeD> yes
<JFo> smb, I understand :)
<JFo> BugeyeD, I think they should be the same then, based on what tgardner says
<JFo> so 64 it looks like
<JFo> as a safe bet
<BugeyeD> works for me. not sure why i'm seeing only 8, unless it's due to x86 arch
<tgardner> debian.master/config/i386/config.common.i386:CONFIG_NR_CPUS=8
<tgardner> debian.master/config/amd64/config.common.amd64:CONFIG_NR_CPUS=64
<JFo> I'm just guessing though :)
<JFo> ah hah, so it is 
<JFo> thanks tgardner 
<BugeyeD> thx guys
<JFo> BugeyeD, :)
<JFo> ask in here anytime
<JFo> there are people all over the world so the chances are good that you could get a relatively quick answer.
<bjf> AlanBell, sure
<amitk> dinh_fsl: does the tree clone now?
#ubuntu-kernel 2010-02-09
<bryceh> JFo, mind putting lp #507148 on the kernel team radar?
<JFo> I don't mind at all bryceh 
<JFo> done bryceh 
<bryceh> thanks
<JFo> np
<MTecknology> How hard is it to add the ext4 defrag patches?
<MTecknology> I just migrated this system from a dying drive. I'd like to reinstall all the packages, then run the defrag, then let my mind tell me it's as good as a fresh install
<akheron> do ubuntu kernels support xen domU like debian kernels?
<smb> akheron, I am not doing xen really, but I thought that was what the -virtual flavours are for
<akheron> ahh, ok
<akheron> smb: I don't see the XEN config options in -virtual
<smb> akheron, Were you looking in the git repo or in the files installed in /boot?
<akheron> in /boot/config-*
<akheron> and it confuses me that -generic-pae and -virtual conflict/replace each other
<smb> akheron, Well, virtual is basically made from generic-pae
<akheron> what do you mean by "made from"?
<smb> akheron, Hm, its strange. common.ubuntu sets a lot of XEN options and those should tickle down to generic-pae
<smb> akheron, Basically build generic-pae and rename some things in the package
<akheron> ok
<akheron> smb: is this new behaviour in lucid kernels?
<akheron> I'm using karmic
<akheron> I mean the XEN options in common.ubuntu
<akheron> smb: did you get my last lines?
<smb> akheron, No. seems to irc horkage happened
<akheron> 13:07 < akheron> smb: is this new behaviour in lucid kernels?
<akheron> 13:07 < akheron> I'm using karmic
<akheron> 13:07 < akheron> I mean the XEN options in common.ubuntu
<smb> oh those
<smb> <smb> No, was the same in Karmic. Or I should say it is like that in Karmic and I would need to compare that in Lucid. There have been other changes
<smb> <smb> I looked in the sources of the git repo. You only see the generated file in /boot
<smb> <smb> But its not as I would expect it. 
<smb> <smb> I think I need a bit more time to figure that out
<akheron> ok
<smb> akheron, Hm, seems X86_TSC is not set in the generic-pae config which then turns off XEN. Dammit this looks too familiar. apw didn't we talk about that some time ago. And sort of tried to figure if PAE naturally implies TSC (and I believe to remember it did)...?
<akheron> what's TSC?
<apw> yes thats familiar
<apw> i think it occurs because 486 doesn't support TSC or something
<apw> smb ^^
<smb> It must be something like that as it is set to =y in common
<apw> i rmember writing the problem up somewhere
<smb> apw, What was the acronym thingy again timestamp something?
<akheron> time stamp counter, it seems
<akheron> wikipedia ftw :)
<apw> hrm no idea :)  but its a clock tick counter
<smb> akheron, Yeah, wiki sounds reasonable there
<apw> now where the heck has that gone
<akheron> "The Time Stamp Counter is a 64-bit register present on all x86 processors since the Pentium", so it's not in 486
<apw> yeah and thering lies the rub
<smb> apw, Yes, I think I remember, we wondered whether we should move the base cpu to M586*somthing and what that would mean
<akheron> PAE is in Pentium Pro
 * apw watches mutt search his email
<apw> i think we did work out that you couldn't get PAE without TSC
<akheron> so, to me it seems that PAE implies TSC
<apw> yep, i think that was the concensus of the discussion, now where _IS_IT_
<akheron> :)
<smb> So with PAE only in pentium pro it seemed save to lift the M486 up as you would not get it running without.
<smb> And apparently we got lost at that stage
<tjaalton> is there a known bug about nfs4/krb5 mounts getting hung after the krb tickets getting expired, and refreshing not helping?
<tjaalton> on lucid
<apw> tjaalton, not that i am aware of
<tjaalton> apw: ok, I'll try .33rc7 to see if it's there too
<apw> ta
<tjaalton> 'ps' gets stuck too, this is from dmesg http://pastebin.ubuntu.com/372406/
<tjaalton> but probably just a resulf of the bigger problem
<smb> apw, I guess we should speak with that to John. (the m586/xen enablement)
<apw> smb yeah, cannot find it at the moment
<leleobhz> i want to try linux 2.6.32 because i want to know if a bug in my sata controller was fixed
<leleobhz> is better try kernel-ppa or use lucid kernel via apt-pinning
<leleobhz> ?
<apw> leleobhz, the lucid kernel is more likely to match your system so i'd try that
<apw> Keybuk, about?
<Keybuk> apw: sure
<leleobhz> apw, ok
<leleobhz> thanks! ill try
<apw> Keybuk, was wondering if we would have expected graphs for bootspeed today?
<apw> don't seem to have results since the 1st
<Keybuk> apw: installer broken in a new and different way
<apw> bah
<apw> its those foundations guys, cannot be trusted :)
<tgardner> apw, I'd still like some -preempt boot times as  well
<apw> hrm, thats 64 bit only right?
<apw> tgardner, ^^
<apw> if so i can't test that on the 'reference' platform as its 32 bit only
<tgardner> apw, yep, I need to respond on the mailing list to allesio about 32 bit issues.
<MTecknology> How hard is it to add the ext4 defrag patches? I  just migrated this system from a dying drive. I'd like to reinstall all the packages, then run the defrag, then let my mind tell me it's as good as a fresh install.
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
 * leleobhz think ubuntu kernel dont like HP machines.
<leleobhz> bonding module give-me a panic
<apw> MTecknology, couldn't say how big they are ... never looked
<apw> leleobhz, file a bug :/
<leleobhz> apw, i think to get a decent trace i must enable a serial console
<leleobhz> and i dont have a way now
<leleobhz> the calltrace is too big
<apw> annoying
<apw> you can change the font size perhaps on VT-1
<apw> consolechars -f /usr/share/consolefonts/Uni1-VGA8.psf.gz
<apw> something like that
<leleobhz> well, is a fb 1024x720 :p
<leleobhz> and the trace runs at least 4 pages
<leleobhz> ill see if serial port tell-me something
<leleobhz> ah, kernel told-me vga= is deprecated. where can i find the new way to set fb?
<Sarvatt> try video=resolution
<leleobhz> WxHxB?
<Sarvatt> WxH works at least
<leleobhz> nice
<Sarvatt> video=1280x800 or whatever
<Sarvatt> are you using KMS? you can change resolutions with fbset too
<leleobhz> Sarvatt, radeon
<leleobhz> i dont know if its usable
<Sarvatt> were you using lucid?
<leleobhz> Sarvatt, karmic
 * leleobhz wasnt happy with alpha until now
<bjf> leleobhz, what model HP is it?
<corecode> the newer linux kernels come with tools, specifically "perf"
<corecode> i can't seem to find a package containing it
<corecode> what's the opinion on how to package that?
<leleobhz> bjf, dc5750
<Sarvatt> hmm, I read the scrollback, I think you're more likely hitting a problem because the lucid kernel has radeon KMS enabled by default and the karmic userspace doesn't handle it too well, you might want to use the mainline ppa kernel instead or boot with radeon.modeset=0 appended to the kernel command line in grub
<leleobhz> Sarvatt, im not running lucid kernel now
<leleobhz> i found a strange issue with ubuntu kernel
<leleobhz> in this HP, the installer only runs well with noapic, nolapic and noapic
<leleobhz> with installed kernel everything goes ok
<Sarvatt> MTecknology: the ext4 defrag stuff was merged during the 2.6.29-rc phase I think? either that or 2.6.30, either way its been there for a long time now and works here, just have to compile e4defrag yourself
<leleobhz> where here i can find information about linux bridge?
<Sarvatt> hmm, wonder why e4defrag isnt included in our e2fsprogs actually
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
 * smb rushes in
<mirsal> apw, ping
<apw> hi
<mirsal> apw, oh, hi, I have a little question about aufs and this bug: #517151
<mirsal> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/517151
<ubot3> Malone bug 517151 in linux "aufs module build fails with CONFIG_AUFS_DEBUG in linux-source-2.6.31" [Undecided,In progress] 
<apw> bug #517151 ubbotu
<mirsal> apw, what's the right thing to to ? :p
<apw> so are you changing the config or building with the stock config
<apw> and how are you building it
<mirsal> apw, I think the stock config doesn't include CONFIG_AUFS_DEBUG
<mirsal> apw, I did it with a plain old make
<apw> so you seem to have determined that should you want to turn that on there is a bug in the source back there
<apw> is the code similar in lucid?
<mirsal> apw, no, you synced with an upstream snapshot, everything is fine in lucid
<apw> #include <asm/system.h>
<apw> #include <linux/bug.h>
<apw> #include <linux/init.h>
<mirsal> yes exactly
<apw> well it is actually similar, in that its like how your patch chagnes it
<apw> mirsal, well i think that your patch is fine as a patch for the issue, though its not clean why anyone would want to turn on that DEBUG
<mirsal> yes, that's my question actually: as the patch in lucid replaces the whole driver with an updated version, how should it be handled in karmic
<mirsal> ok
<apw> you will find resistance to fixing it i suspect as it doens't fix anything we build, and adds risk, and any consumer of it can just apply the patch to their source
<mirsal> apw, ok, actually I don't really care, I'm just looking for low hanging fruits in the kernel bug list in order to learn
<mirsal> right, if someone wants to debug AUFS they surely can apply a small patch
<apw> so i think you should cleanup your patch and attach it with your signoff to the bug
<apw> and then also send it to the kernel-team list
<apw> 'we' will then either apply it, or suggest that its not worth it, and then we can close the bug won't fix with the reasoning
<apw> and you are off the hook :)
<mirsal> ok, thanks :)
<apw> but the work you did looks good, even if it doesn't go anywhere in the kernel, as the reader can see how to fix it themselves and allows us to close the bug one way ot the other
<mirsal> :)
<apw> good job, thanks
<tgardner> apw, I cannot see any substantive difference in CONFIG_M586TSC and CONFIG_M586. they both set the same karmic compiler flag
<tgardner> ah, it enables X86_TSC
<apw> yep that is meant to be the only difference
<apw> obviously that would allow us then to re-enable XEN on top
<tgardner> apw, frankly, I don't see that as very risky
<tgardner> definitely do it for Lucid.
<apw> cool, that was my feeling 
<smb> Would we care enough for Karmic?
<tgardner> smb, likely for the pae flavour
<tgardner> perhaps generic as well
<apw> i think that some of the more brain dammaged things we support with generic dont have TSC
<tgardner> apw, thats only in the 386 flavour.
<smoser> apw, jjohansen did you sort out the linux-meta-ec2 ? issue ?
<smb> I'd vote for generic-pae. We all think there should be nothing that has PAE but not TSC
<apw> smoser, under control yes
<tgardner> smb, actually, it _can't_ be PAE without TSC
<apw> that was my reading of the info for sure
 * smb nods
<tgardner> so, does taht eman we only support Xen with -pae ?
<tgardner> that mean*
<smb> Xen only supports itself with TSC
<apw> its the -virtual flavour that is for xen
<apw> and thats made from -pae
<tgardner> and we build -virtual from -pae on i386
<apw> smoser, pushed
<apw> s/pushed/uploaded
<smoser> apw, thanks.
<smb> tgardner, So we currently only have no Xen enabled in -virtual because X86_TSC is not set because of M586TSC not being used
<apw> smoser, was an oversight on my part, i uploaded the kernel before travelling back
<tgardner> correct
<smb> tgardner, Sorry, I was trying to make a statement there
<apw> so the fun will be getting the XEN config options 
<apw> back ...
<smb> Guess we all agree then we want to enable it. 
<smb> apw, Not so bad
<smb> apw, Just enable CONFIG_586TSC in the flavour and the XEN stuff is in common
<apw> oh handy ... good
<smb> apw, it was just removed whenever you ran config
<apw> got you makes sense
<apw> i'll get that done then, do we need a bug?  only for karmic i guess
<smb> apw, Now we only need to remember ... bah, you were faster
<smb> Maybe there was one in the beginning...
<apw> i'll do it now
<apw> smb, see if you can find a bug on it :)
<apw> Bug #453073 is mentioned in the original email i had
<ubot3> Malone bug 453073 in linux "linux-image-virtual (i386): many modules missing on Karmic" [High,Fix released] https://launchpad.net/bugs/453073
<jjohansen> is it worth fixing for karmic?
<smb> apw, That one probably not :) it should be fixed
<apw> yeah i see that now :)
<smb> jjohansen, maybe cheap enough. or do you think pointing them at ec2 is fixed enough?
<jjohansen> ugh, I would like to keep the use of the ec2 kernel to an absolute minimum
<jjohansen> so yeah lets do this for karmic then
<smb> apw, akheron might have one as he was asking this morning
<smb> Not sure he is still around 
<akheron> smb: ???
<smb> akheron, Just wondering whether you had reported the missing Xen support as a bug.
<akheron> no
<akheron> should I?
<smb> akheron, Ok, I guess apw will do that now (or has done)
<akheron> ok
<apw> smb, i haven't as yet, as it wasn't clear we are doing this for karmic
<apw> if the decision is yes for karmic then we should file a bug
<smb> It felt it is yes.
<apw> if someone gets that filed, i'll get my email in there straight after
<smb> okok, I will do it
<apw> :)
 * apw lets smb get some karma
<smb> apw, bug 519448
<ubot3> Malone bug 519448 in linux "No XEN domU support in 32bit virtual flavour" [Wishlist,Triaged] https://launchpad.net/bugs/519448
<apw> smb, thanks ... i am soooo lazy
 * smb knows :-P
<apw> smb, ok pushed to the kernel-team list
<apw> smb, also nom'd for karmic for you
<smb> apw, Ok cool
<smb> apw, The patch for bug 516325 seems to be in your tree (coming from 2.6.32.7) but not released yet. Should I leave the Lucid task as commited or set it to released (as you probably soonish will do)
<ubot3> Malone bug 516325 in linux "ACPI: enable C2 and Turbo-mode on Nehalem notebooks on A/C" [Unknown,Fix released] https://launchpad.net/bugs/516325
<apw> as its not released i should hack the history to add it
<corecode> hey
<corecode> any opinion on how to package the tool "perf" that comes with the kernel sources?
<smb> apw, Ok, so I put it into committed state and assign it to you
<apw> ack
<akgraner> bjf, ping got a sec for some SCaLE testing talk?
<JFo> akgraner, I suspect he may still be at lunch
<JFo> he stepped out a few moments ago
<akgraner> JFo, no worries thx
<JFo> :)
<bjf> akgraner, i'm here
<akgraner> bjf, on Friday after 12 the testing area will be in place so you can start testing after noon ..
<bjf> akgraner, cool, we get in on Thursday
<bjf> akgraner, will we be able to get in early to setup and test our testing setup?
<akgraner> the drop won't be in place til noon
<bjf> akgraner, ok
<akgraner> :-(
<akgraner> will you be able to use the sticks at all this time?  if that is the case you can test outside the ubucon area
<bjf> akgraner, it is how it is.. we'll make out fine
<akgraner> we'll have wireless there but not a drop
<bjf> akgraner, we are taking a bunch of sticks, just in case we have network issues, we can still test
<akgraner> sweet - I have asked for a table outside the ubucon are for you all 
<akgraner> and you will have a dedicated test area right outside the main event on Sat
<akgraner> so people pass you going into the venue
<akgraner> and if you want you can even have someone at the Ubuntu Booth with sticks as well :-)
<bjf> akgraner, sounds good
<akgraner> great!  thx  let me know if you need more info or anything
<akgraner> hope that helps
<bryceh> bjf, pst --- https://wiki.ubuntu.com/X/Testing/NouveauEvaluation
<bryceh> bjf, finally I finished writing this up
<bjf> bryceh, thanks!
<crimsun> bjf: please bump the c-o-d karmic builds to -19 so that Ronald can verify the fix for #519066
<bjf> crimsun, will do
<crimsun> thanks
<Q-FUNK> ogasawara: hi!
<Q-FUNK> ogasawara: was a decision reached on 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
<ogasawara> Q-FUNK: hi, I believe smb was working on that.  I can check with him tomorrow about current status.
<Q-FUNK> ogasawara: please see my comment at the bottom.
<Q-FUNK> ogasawara: I mainly wanted to know whether my proposal to merge his simple patch into the stock lucid kernel was accepted.
<ogasawara> Q-FUNK: I don't know the current status of the patch smb wrote, so will have to wait to check with him tomorrow.
<Q-FUNK> ogasawara: despite the fact that it's not a proper fix, but that it nonetheless allows this hardware to boot,
<Q-FUNK> ogasawara: alright. :)
<bjf> crimsun, new karmic c-o-d available
<crimsun> bjf: thanks, I'll follow up with Ronald
<bdmurray> JFo: bug 517151 has a patch
<ubot3> Malone bug 517151 in linux "aufs module build fails with CONFIG_AUFS_DEBUG in linux-source-2.6.31" [Undecided,In progress] https://launchpad.net/bugs/517151
<JFo> bdmurray, yessir, it is on the radar
<bdmurray> JFo: awesome, I'll unsub the ubuntu-reviewers team then
<JFo> thank you :)
<bdmurray> maybe the ubuntu-reviewers team should just ignore kernel bugs if you are on top of them...
<bdmurray> JFo: ^ do you have your own monitoring system for bugs with patches?
<JFo> I do
<JFo> I have a url I use
<JFo> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
<JFo> I do a review in our weekly meeting for them
<bdmurray> JFo: I have a script that subscribes a team to bugs with new patches.  I could special case the linux package and have it subscribe you maybe? and not the team
<JFo> that sounds perfect
<JFo> bdmurray, one of my upcoming bug days will be bugs with patches attached
<JFo> but subscribing me would work fine
<bdmurray> JFo: okay, you've been subscribed to bug 492056
<ubot3> Malone bug 492056 in linux "Saitek X52 Joystick does not work" [Medium,Triaged] https://launchpad.net/bugs/492056
<JFo> thank you
#ubuntu-kernel 2010-02-10
<MTecknology> Sarvatt: thanks
<Sarvatt> no worries, it really doesn't help much for a ext3 to ext4 conversion regarding fsck times though at any rate, my converted one still takes ~3 minutes to fsck vs the 20 seconds of my native ext4 partition thats 4x bigger and I run e4defrag on it all every other month or so for the past year
<crimsun> apw: any chance for CONFIG_TASK_DELAY_ACCT to be enabled for -generic (lucid)?
<bjf> crimsun, it's best to make the request on the mailing list
<crimsun> bjf: right, enqueued
<apw>   * PCI: AER: fix aer inject result in kernel oops
<apw>     - LP: #unable to handle kernel NULL pointer dereference at 0000000000000350
<apw> smb, ^^ just noticed that in my printchanges!
<apw>     uartlite: ttyUL0 at MMIO 0xc8000100 (irq = 30) is a uartlite
<apw>     BUG: unable to handle kernel NULL pointer dereference at (null)
<apw> oops ... seems our LP handling is a bit weak
<smb> apw, you confuse me a bit
<apw> fdr printchanges is picking up BUG: text as a buglink and making it into a -LP :#<crap>
 * apw goes fix
<smb> apw, Oh, got it
<smb> apw, Thats is on your latet release?
<apw> smb, yep a stable update has tickled the bug ... strange
 * smb goes looking how that commit message looks in full
<apw> its just that line that matters
<apw> we check that BugLink: has an http* after it, but _not_ that Bug: has a number after it ... silly of us
<apw> easy to fix, except there is a major duplication of code here i think i should fix too
<smb> apw, It could be resulting from that we had something different before. /me is so forgetful. Might it have been Bug: #number?
<apw> yeah its the support for Bug: #nnnn,nnnn,nnnn which is broken
<apw> it matches non numeric forms too which is silly
<smb> apw, Very silly. To assume that "Bug:" R us
<apw> heh indeed :)
<smb> apw, Sounds like another thing I want to slurp in when you have fixed it
<apw> yep
<Keybuk> apw: no new bootcharts for today
<Keybuk> installer still broked
<apw> DAMN the installer
<Keybuk> SAVE THE EMPIRE!
<apw> shame we don't have an alpha- coming up, that would focus minds
<apw> mirsal, that patch looked good, and seems to have gotten the nod, nice
<smb> I am about to pick that up
<smb> Should do no harm, so...
<smb> apw, Rebasing seems evil for git describe --contains... grr 
<apw> well it'll always only be in the latest one
<smb> apw, So that ALPS protocol patch seems to be in since around Jan-27. Heard or seen an angry mop of ALPS users recently?
<apw> i've heard nothing about it no, but then i don't have a huge number of users either
<apw> but its in stable, so its 'offical' if nothing else
<smb> apw, Just was wondering about taking it in for Karmic
<smb> Even without it being on stable there
<apw> i believe we have a bug from someone with it in karmic right?  so we have a test subject at least
<smb> I believe there was something. I just need to check back whether it was "only" the maintainer. But I think it was someone with the problem for real
<dholbach> heya
<dholbach> I had my amd64 desktop machine freeze a couple of times this morning (music stuttering, X froze, couldn't ssh in, but magic sysrq still worked), but I didn't get anything in any logs, with the 2.6.31-20 kernel the machine is running for over an hour now without any problems - can anybody help me debug this somehow?
<matti> Hi dholbach 
<dholbach> hey matti
<smb> dholbach, Hmm, it might help slightly to know which kernel version was misbehaving...
<dholbach> smb: the most recent: 2.6.32-12.17
<dholbach> (generic, amd64)
<smb> dholbach, Ahh, so you can slap apw for that. :-P
<dholbach> I just wonder how I could debug it as there's nothing in any of the logs
<smb> One thing might be to have a watch on memory consumption
<alex_joni> also looking at the HDD led helps sometimes
<alex_joni> maybe it's swapping..
<dholbach> I was running 2 or 3 pbuilders, listening to music, fetching mails, surfing the web, so there was definitely some HDD activity and maybe I even ran out of mem (only 2G in there)
<dholbach> but how could that be related to the freeze?
<smb> And if ssh is not working, trying to ping
<dholbach> shouldn't it just swap and be done with it?
<smb> Depending on your memory it might swap out for a while and then start killing things or hang if there is something wrong with memory management
<dholbach> ok, gotcha
<dholbach> the machine was maybe running for 5-10 minutes, but yeah, next time I try using the current lucid kernel I'll have a look at it
<slytherin> smb: Free? Need to discuss linux-ports-meta bump in karmic.
<smb> dholbach, Can also be a deadlock on something. Thats probably harder to find out. On tight spinlocks the fans on laptops would go up, but desktops are sturdier
<dholbach> smb: ah, good to know - I'll let you guys know
<smb> slytherin, Yes. It might have been delayed by a mistake in the abi number
<slytherin> smb: Ok. Just wanted to know if you saw my message about same few days ago.
<smb> slytherin, Hm, a few days ago we were all on a sprint which is prone to miss messages. So it might be worth repeating
<slytherin> smb: Nothing special. I just wanted to point out that the wrong kernels were being pulled by security update i.e. -15 instead of -19.
<smb> slytherin, Ah, yep. I found out yesterday when going over the current versions. A -19 has been sent for upload yesterday, so I hope this hits today
<slytherin> great.
<smb> linux-ports-meta | 2.6.31.19.15 | karmic-security | source
<smb> Seems there, just was not copied to updates, which looks strange
<smb> I'll try to find someone to fix this
<smb> slytherin, So it seems its updated, but if you are behind a slow mirror (like me) it looks broken
<smb> slytherin, https://edge.launchpad.net/ubuntu/+source/linux-ports-meta
<slytherin> Ok. 
<slytherin> My last update was about 8 hours before.
<slytherin> I will check again when I go home
<smb> slytherin, Atm at least de.archive.ubuntu.com seems to slightly disagree. But launchpad usually knows better (or earlier)
<slytherin> hmm
<smb> slytherin, But the change was just 3hrs ago, so it just needs time
<slytherin>  know. I didn't actually check if the change was made already.
<amitk> apw: quick question regarding 'git fetch' on a remote repo
<amitk> if the remote repo is a local one (on the HDD), does git fetch copy the objects from that remote repo into the local one.
<amitk> ?
<JFo> I'm seeing a lot of 'deleting plymouth fixed my issue' bugs... who do I need to ping to look into those?
<JFo> :)
<amitk> JFo: Keybuk is our plymouth guy ;)
<JFo> okey dokey :)
<tgardner> amitk, I think it depends on how your local repo is defined, e.g., --reference, etc
<amitk> tgardner: what did you do to rtg?
<tgardner> amitk, someone stole my nick, so I had to register
<apw> amitk, yeah it does, though it may link them if you use -s i think it is
<amitk> tgardner: the remote is a subsystem maintainers tree that --reference's linux-2.6 in the same dir. So the real objects are in linux-2.6. I guess I need to monitor size of the directories next time I do this.
<tgardner> amitk, I'd think it would be smart enough to do the linking correctly
<amitk> apw: aah, so I'd end up with linux-2.6 objects in almost every git tree I have since I add a remote to linux-2.6 in them and run a 'git fetch linux-2.6'
<dholbach> apw, smb: now I can't reproduce the machine freeze any more - I've been test-pbuilder-ing chromium and the kernel and exposed the machine to some other work and it still hasn't frozen with 2.6.32-12.17
<dholbach> I'll let you know :)
<smb> We're sure you will :)
<dholbach> smb: I can't recall the last time where I was sitting there and saving "my work" like every 5 minutes :)
<apw> hehe ... we are making your experience more windows like every day
<JFo> oh dear
<JFo> :)
<smb> Just reminding people of good work practices :-P
<apw> i blame the triager :)
 * JFo runs away crying
<dholbach> JFo: I'll let you know when the machine freezes again - no problem!
<JFo> heh, thanks dholbach 
<apw> anyone know how stable the sha1's in the lnux-2.6-tip tree are?
 * smb has no clue
<Keybuk> JFo: the two people who know plymouth are the two people who can't replicate the bug
<JFo> Keybuk, interesting. hardware specific/related then
<Keybuk> no idea
<Keybuk> people are reporting it on hardware that I have
<JFo> odd
<Keybuk> it's at least partially a kernel bug
<Keybuk> since the result is that you end up in a situation that's supposed to be impossible
<JFo> right
<Keybuk> but it's kernel code that no engineer dares look at
<Keybuk> (the VT code)
<JFo> yikes
<Keybuk> you seem to end up in this strange situation where you're simultaneously on VT1 and VT7
<Keybuk> with X running
<Keybuk> but what you type into X ends up on the underlying VT
<Keybuk> and you only need Alt+F2 to move out of it, not the Ctrl key
<Keybuk> it's very weird
<JFo> sounds like it
 * JFo 's head hurts thinking about it
<Q-FUNK> howdy! has anybody found a fix for the initramfs-tools issue that just popped up?
<JFo> Q-FUNK, what do you mean?
<JFo> is that the  "update-initramfs fails: ./lib/udev/firmware.sh does not exist" issue?
<Q-FUNK> yup
<JFo> I believe so
<JFo> one sec
<JFo> Q-FUNK,  you should be able to apply http://launchpadlibrarian.net/39011493/udev-firmware.patch and then 'update-initramfs -u' again
<JFo> that is the fix I saw earlier
<JFo> it is from https://launchpad.net/bugs/519855
<ubot3> Malone bug 519855 in udev "update-initramfs fails: ./lib/udev/firmware.sh does not exist" [High,Triaged] 
<JFo> Q-FUNK, let me know how it turns out
<Q-FUNK> JFo: seems to help
<JFo> ok
<Q-FUNK> thanks!
<JFo> Q-FUNK, np
<Sarvatt> Keybuk: speaking of plymouth, it needs a little lucid only update for lbm-nouveau which will be landing soon - http://sarvatt.com/downloads/patches/plymouth-lbm-nouveau.patch
<Keybuk> go for it then
<ne78> How can i rebuild the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc7/ , linux-source-2.6.33_2.6.33-020633rc7_all.deb doesn't contain the debian directory where can i get it ?
<ne78> and there are no .dsc and orig files
<JFo> ne78, those are built kernels. I'm not sure what you are looking for.
<JFo> ah, wait
<JFo> I just read the rest of the first statement
<JFo> ne78, mainline builds are vanilla kernels built from the main source tree. linus' tree
<JFo> so there is no debian specific goodness if I am not mistaken
<abogani> Could anyone point out me on issues about running .31 kernels on Lucid?
<akheron> ne78, JFo: there's ubuntu specific .config AFAIK
<JFo> akheron, I was under the impression that they were vanilla builds that we automatically built and uploaded from the -stable branch
<ne78> yes my question was, where does the debian/ or debian.master come from ?
<ne78> how can i reproduce that build
<akheron> JFo: the -stable branch of what?
<JFo> of the linux tree
<JFo> apparently I was wrong
<JFo> we drop a modified debian directory in there
<ne78> yes that's what i'm looking for
<tgardner> JFo, at least thats the way he used to do it.
<JFo> I think the plan is to start using the built-in packaging target
<JFo> doesn't look like it is there anymore tgardner 
<JFo> or at least that is what ne78 is saying
 * JFo goes to look
<ne78> and the script that does that doesn't seem to be public
<tgardner> hmm, there is a wiki somewhere about mainline build foo
 * JFo looks for that too (good to bookmark)
<tgardner> JFo, should also be in teh build scripts repo, but taht appears to have moved
<JFo> ok
<JFo> thanks tgardner 
<JFo> found 3 pages in the wiki
<JFo> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds
<tgardner> JFo, maybe its in kteam-tools.git now
<JFo> ah hah, yes because amitk and smb cleaned those up at the sprint
<tgardner> ne78, git://kernel.ubuntu.com/ubuntu/kteam-tools.git
<smb> Oh, yeah. amitk wrote mail that everybody has ignored apparently :)
<JFo> lol
<smb> sorry
<ne78> cool
 * JFo has a forgettory instead of memory smb
<ne78> maybe a link from the ppa to that git would be useful
<tgardner> smb, I operate on a 'need to think about it' basis
<JFo> tgardner, I am with you there
<smb> Yeah, we figured when the repo suddenly vanished it will make people think
<tgardner> smb, indeed, your evil plan worked
<smb> Thank you. >:-)
<abogani> Could anyone pinpoint me on issues that I'll incur running 2.6.31 kernels on Lucid?
<Q-FUNK> ogasawara: hi! was any decision reached with smb about that Geode patch?
<ogasawara> Q-FUNK: I chatted with him, sounded like he didn't want to submit it for lucid since it's not a proper fix
<Q-FUNK> ogasawara: ok, so what's the solution then? risking to break support for a sub-architecture on an LTS release?
<mjg59> Declare geode unsuported? Nobody with the skills to do anything about it seems to be interested in fixing it.
<ogasawara> Q-FUNK: from reading the upstream bug it seems pretty specific to the hw that you have as upstream is unable to reproduce
<Q-FUNK> mjg59: that would be silly. you'd essentially render the whole LTSP project obsolete at the same time.
<ogasawara> Q-FUNK: and the patch that smb had didn't seem like a patch but rather adding debugging printk's
<Q-FUNK> ogasawara: upstream doesn't have access to similar hardware.
<mjg59> Yeah. Any approach that's just based on changing timings risks breaking when there's an unrelated kernel change
<Q-FUNK> I fully agree that adding printk's is an odd kuldge, but if it succeeds in making that particular kidn of hardware boot again, why not?
<Q-FUNK> ah.
<Q-FUNK> the thing is, that particular hardware is rather common about the thin client users covered by LTSP.  if an LTS suddenly drops support for it, that's gonna be a mess.
<Q-FUNK> s/about/r/among
<Q-FUNK> something just popped into mind:  do we have nightly builds of the upcoming ISO for Lucid?   if we do, I could make a USB stick and see if *that* displays the same symptoms, just  to rule out a progresssive corruptino of the filesstem on that hardware's hdd.
<ogasawara> Q-FUNK: there's the daily-live images - http://cdimage.ubuntu.com/daily-live/current/
<Q-FUNK> thanks
<Q-FUNK> nope.  not a corrupt filesystem.  booting from lucid alpha on a usb stick also freezes with the same issues.
#ubuntu-kernel 2010-02-11
<F40PH> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<F40PH> !ops
<iD_J> could someone explain to me what this means by "fix released"? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/356392
<ubot3> Malone bug 356392 in linux "[Acer, inc. Aspire 6530G] suspend/resume failure [non-free: fglrx]" [Undecided,Fix released] 
<iD_J> could someone explain to me what this means by "fix released"? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/356392
<ubot3> Malone bug 356392 in linux "[Acer, inc. Aspire 6530G] suspend/resume failure [non-free: fglrx]" [Undecided,Fix released] 
<amitk> iD_J: it means that the fix is available in a kernel update. But since you reported this on a 9.10 system and the 'fix' is to upgrade to 2.6.32, that status isn't right
<smb> Well it is right as the default task is always the development release. So if the status should be tracked for Karmic, this needs a nomination and so on
<apw> yeah i think the status is changed incorrectly, this seems to be working with mainline 2.6.32 and not with lucid kernels
<amitk> smb: i guess my point was the status was changed to fix released w/o opening a nomination for karmic (and probably makring it won't fix)
<smb> amitk, Ok, yeah
<smb> apw, I is probably working with lucid. The test was 9.10 (Kramic) with 2.6.32
<iD_J> it doesn't work with lucid
<iD_J> only the mainline kernel
<smb> iD_J, Ok so then its definitely the wrong status
<iD_J> smb: would you be able to sort it out? i don't really understand this stuff that much
<smb> iD_J, Can do. But this looks as needing a bit more clarification / debugging. If I read this correctly it was not only the kernel that got changed, but also the graphics driver. Is that right?
<iD_J> smb: the driver doesn't make a difference
<iD_J> the problem occurs with the open source one and the proprietary one
<smb> iD_J, Ok, yeah I saw there is a previous comment which is clearer. Which version of the mainline kernel did you use? And is it possible to go backwards in the mainline build to see when it stops working?
<iD_J> smb: i used the one i was asked to use, 2.6.32
<iD_J> i can do that, but it would have to be later today or maybe tomorrow
<smb> iD_J, That would be ok. I add some comments to the bug and set it back to triaged (open)
<iD_J> smb: thank you =]
<smb> iD_J, np :)
<matti> ;]
 * apw slams the lucid build system into karmic as an experiment
<abogani> Are there problems running a .31 kernel on Lucid? For example with udev or usplash?
<apw> abogani, a stock .31 is not expected to boot
<abogani> apw: Ok. How can armel kernel boot?
<apw> its not a stock .31 kernel, it is a kernel we have crafted for the purpose
<apw> why do you want to put a .31 kernel on lucid?
<abogani> apw: linux-rt is stick on .31
<apw> i don't suppose i want to know why you need an -rt kernel
<apw> at a minimum you would need the devfs patches and module.builtin patches from the fsl-imx51 branch to have a hope of booting correctly
<abogani> apw: Ok. I'll take a look. Thanks!
<apw> is there not an rt patch set for .32 yet?
<abogani> apw: No unfortunately
<hyperair> has anyone heard of an issue where touchpad and keyboard of a notebook doesn't work under any linux kernel? workaround being passing this kernel option: i8042.noaux
<smb> Hm noaux, I thought disables the use of the auxillary ports which normally ps/2 mice are connected to. But in general there were cases where that was broken. 
<hyperair> yeah, the touchpad doesn't work in either case.
<hyperair> but the keyboard only works with noaux set
<smb> Ah, ok. Make more sense that way
<hyperair> weird
<hyperair> http://ubuntuforums.org/showthread.php?t=1098767 <-- this
<hyperair> a friend of mine
<smb> Well it sounds as enabling the aux port causes so much noise/problems that the keyboard gets affected as well. The best chance is to create an upstream bugzilla report (probably after testing the latest mainline build) and try to get the attention of Dmitry Torokhov, who is the maintainer
<smb> If you boot with i8042.debug=1, you can gather a lot of debugging data in dmesg for him
<hyperair> smb: there was some. but i can't make head of tail out of it
<hyperair> smb: i've got his /var/log/kern.log here.
<hyperair> smb: also, windows works fine, it seems
<smb> Yes, the output is horribly cryptic, a very basic protocol.
<hyperair> smb: http://people.ubuntu.com/~hyperair/kern.log
<hyperair> it's kinda huge, but there are several test cases -- with noaux, with nomux, and with debug
<smb> While that is a lot, I don't see any messages that would be there if using the i8042.debug=1
<hyperair> all the way at the bottom
<hyperair> look for "i8042"
<smb> Ah, ok. Let me see whether I can find my ps2 cheat-sheet
<smoser> jjohansen, ping
<smoser> bug 520015
<ubot3> Malone bug 520015 in linux-meta-ec2 "bad dependencies on karmic linux-ec2, linux-image-ec2" [Undecided,New] https://launchpad.net/bugs/520015
<smb> hyperair, Hm ok: 20->read command byte returns 47 (does not decode well on my sheet, maybe too old), then 60 sets a new value. d3 tries to echo the value 5a back trough a loopback which fails. Then a9 is a aux test which seems to timeout (fe) Then the command byte is updated again with 47 and finally a f2 which I don't find in my doc.
<smoser> last night my karmic build ended up with 2 -virtual kernels and 2 -ec2 kernels in the image. i think its related to bug above. maybe it will fix itself?  something in the dependency resolution of linux-virtual and linux-ec2 ended up pulling 2 '-image' packages.
<smb> Bah, gone already. No patience those guys
<smb> smoser, There had been a mismatch in the meta and the kernel version numbers. In theory it should be fixed by now... Though I need to look
<jjohansen> smoser: I am hoping it will correct it self
<smoser> me too :)
<jjohansen> smoser: if it shows up again tonight, we will take another look at it
<Laibsch> Hi
<Laibsch> Keybuk suggested that bug 375148 may be a kernel bug.  Is it true that recent kernels don't allow nonfree drivers to have device nodes?
<ubot3> Malone bug 375148 in sl-modem "no more /dev/ttySL0 device node" [Medium,Confirmed] https://launchpad.net/bugs/375148
<Keybuk> not a kernel bug
<Keybuk> a change
<tgardner> Keybuk, one of the GPL only functions?
<Keybuk> tgardner: yeah, I have a vague feeling/memory about it
<tgardner> it wouldn't surprise me
<Keybuk> was wrt to the nvidia driver at plumbers last year
<Keybuk> drivers/base/core.c:EXPORT_SYMBOL_GPL(device_register);
<AnAnt> Hello
<Keybuk> though in the sl-modem case, tty_register_device() is still permitted
<Keybuk> __register_chrdev is permitted too
<Keybuk> so it should be possible to make the driver work given the current permitted interfaces
<tgardner> Laibsch, ^^
<Laibsch> great news
<Laibsch> unfortunately, something does not work
 * Laibsch needs to compile the latest package and restest
<Keybuk> Laibsch: you don't even need udev now of course
<Keybuk> we switched to devtmpfs in lucid
<Keybuk> so if the module is right, the kernel will make the device node in /dev for you
<AnAnt> Keybuk: thanks
<AnAnt> Keybuk: how about device_create, that's GPL only ?
<AnAnt> Keybuk: I found some old code for sl-modem that uses device_create, device_destroy, class_create, class_destroy
<Keybuk> those are GPL only
<AnAnt> is device_create similar to tty_register_device ?
<Keybuk> device_create is the underlying function
<Keybuk> I think it's ok if you register a tty device
<Keybuk> which is ultimately what you're after
<Keybuk> afaict the intent is that out-of-kernel non-GPL drivers can't invent new subsystems
<Keybuk> or new classes of devices
<Keybuk> but can implement a device which is handled by a kernel subsystem
<Keybuk> ie. you can write a non-GPL network driver, serial driver, tty driver, etc.
<Keybuk> but you can't write a non-GPL driver for something interesting ;)
<AnAnt> so, what should I use instead of the device_destroy, class_create, class_destroy for tty ?
<Keybuk> tty_register_device I guess
<Keybuk> if it does what you need
<AnAnt> ok
<Keybuk> then the ttySL0 will actually come from the tty subsystem
<Keybuk> which is probably right too
<AnAnt> tty_{un}register_driver instead of  class_{create,destroy} ?
<Keybuk> that kind of thing yeah
<Keybuk> the struct would change
<Keybuk> look at the existing modem drivers
<AnAnt> Keybuk: can you tell me of an existing modem driver ?
<Keybuk> the entire contents of driver/serial ?
<smb> iD_J, So you need more info on the suspend bug from this morning? So just for recap: 2.6.31 (ubuntu) works, 2.6.32 (ubuntu) not, 2.6.32 (mainline) does work and 2.6.32.6 and 2.6.32.8 work as well
<AnAnt> ok, thanks
<iD_J> nobody's tested 2.6.31 ubuntu
<iD_J> i remember it didn't work from karmic though
<smb> iD_J, Ok, so 2.6.31 was just a misunderstanding on my side
<iD_J> what happens next then?
<manjo> iD_J, do you have a launchpad bug ? 
<smb> iD_J, In theory this info gives the chance to find out what is different between Lucid kernel and 2.6.32.8 and try to think of what might cause it
<smb> manjo, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/356392
<ubot3> Malone bug 356392 in linux "[Acer, inc. Aspire 6530G] suspend/resume failure [non-free: fglrx]" [Medium,Triaged] 
<manjo> smb, thanks 
<iD_J> that doesn't sound easy
<abogani> Is it possible that a .31 kernel is able to boot on a Lucid system? If I don't misunderstand this don't should be possible.
<iD_J> it booted fine
<abogani> Someone told me that there are problems with udev and usplash if the kernel is < .32
<iD_J> i didn't have any problems
<iD_J> plymouth didn't work with any of the mainline kernels though
<abogani> iD_J: Ok so I have misunderstand all. Do you know what commit fix this?
<iD_J> commit fix?
<bjf> abogani, you don't want to mix new userspace with older kernels
 * JFo thinks that would break in nefarious ways
<abogani> bjf: I don't have choice.
<bjf> abogani, why would you not have a choice?
<abogani> bjf: linux-rt
<bjf> abogani, you can expect breakage in stange and interesting ways
<abogani> bjf: Are there some documentation about this problem?
<bjf> abogani, not specifically, you are just mixing abi's and that's not good
<tgardner> you guys are just being paranoid. .31 works fine with Lucid
<tgardner> note that we have 2 ARM branches based on .31 working under Lucid.
<abogani> tgardner: Could you confirm that problems with udev and usplash simply don't exists? And with Plymouth?
<tgardner> abogani, plymouth is a known issue. I've removed it for the time being. other then that things ought to "just work"
<abogani> tgardner: Ok thanks.
<iD_J> what happens with my problem now then?
<iD_J> is there anything i can do to move things along a bit?
<iD_J> bad times...
<Laibsch> I'd like to see if http://bugzilla.kernel.org/show_bug.cgi?id=15180 is fixed for karmic.  But I'm not sure anymore how to recompile a Ubuntu kernel. 
<ubot3> bugzilla.kernel.org bug 15180 in Wireless "new atheros chipset" [Normal,Resolved: code_fix] 
<Laibsch> http://blog.avirtualhome.com/2009/11/03/how-to-compile-a-kernel-for-ubuntu-karmic/ used to work nicely, but broke recently (just a few days ago)
<Laibsch> how am I supposed to recompile a kernel with a patch that is not in mainline, yet?
#ubuntu-kernel 2010-02-12
<Laibsch> I'd like to see if http://bugzilla.kernel.org/show_bug.cgi?id=15180 is fixed for karmic.  But I'm not sure anymore how to recompile a Ubuntu kernel. 
<ubot3> bugzilla.kernel.org bug 15180 in Wireless "new atheros chipset" [Normal,Resolved: code_fix] 
<Laibsch> http://blog.avirtualhome.com/2009/11/03/how-to-compile-a-kernel-for-ubuntu-karmic/ used to work nicely, but broke recently (just a few days ago)
<Laibsch> how am I supposed to recompile a kernel with a patch that is not in mainline, yet?
<abogani> [OT] Sorry to bother you. , I wondering on how many Ubuntu Kernel Team members plays with Arduino... If someone could review it ( http://revu.ubuntuwire.com/details.py?upid=7690 and https://launchpad.net/~arduino-ubuntu-team/+archive/ppa/+packages ) would be really appreciated! Thanks in advance!
<apw> Keybuk, hey ... did we get any times today?
<apw> i need my fix
<cking> abogani, a few of use use them - afraid the guys who really use them a lot are  not in the channel at the moment 
<cking> abogani, sconklin and hughhalf are the best ones to ask - I'm not acquainted enough with it to do the review any justice
<abogani> cking: Thanks anyway! :-)
<cking> abogani, I've email'd them so maybe they will give it a look when they are up
<abogani> cking: Really thanks!
<Keybuk> apw: I have times
<Keybuk> but no, installer broken still and colin's busy at work on mark stuff
<apw> Keybuk, got a graph i can look at?
<Keybuk> apw: not yet
<Keybuk> the kernel times are back in the 1.6s
<JFo> apw, I have the bugs jdstrand mentioned in the meeting up
<apw> JFo, ok ta
<apw> what a mess.  why do we find out soooo late it is all fucked
<JFo> dunno, but I have been hounding about all the plymouth fails we have
<JFo> and I have seen these type of failures lately too
<JFo> but I have left them mostly to bryce
<JFo> and most of these are against xorg too so there is that.
<JFo> apw, you want any of those on the list for Monday?
<abogani> tgardner: Is there a chance to have a preempt flavour for i386?
<tgardner> abogani, as I expressed in the kernel-team email, I'm not really interested in supporting another 32 bit variant.
<abogani> tgardner: Is there something that I can do for let you change your decision?
<tgardner> abogani, perhaps you should present some real use cases for a 32 bit -preempt version.
<tgardner> but be advised that I'm not interested in wasting resources on legacy hardware support.
<abogani> tgardner: Use cases: the Ubuntu Studio users.
<tgardner> abogani, lay them out in an email. Tell me _why_ Studio users can't use 64 bit?
<tgardner> them == use cases
<abogani> tgardner: I would want only avoid to cut off people whom still have 32bit system (Pentium M, P4 and so on).
<tgardner> abogani, email, I'm not having this discussion on IRC
<abogani> tgardner: Ok. I'll write it asap. Thanks!
#ubuntu-kernel 2010-02-13
<iD_J> is there a way to see why a suspend might have failed?
<iD_J> i need help compiling a kernel
<tobidope> can i ask module related questions here? i have a problem with acerhdf
<tobidope> ?
<matti> tobidope: Best route to take is to open a bug against it.
#ubuntu-kernel 2011-02-07
<ntemis> hi
<tgardner> smb, did you run out of interest before reviewing Dapper CVE-2010-3880 ?
<ubot2> tgardner: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)
<ntemis> my ethernet adapte supports jumbo frames but the driver dodnt let me go beyond 7k
<smb> No, I stumbled over the openvz fixup (which is attributed wrongly it seems) and then forgot about it.
<ntemis> it can do 9k
<ntemis> rlt 8111E
<smb> tgardner, No, I stumbled over the openvz fixup (which is attributed wrongly it seems) and then forgot about it.
<ntemis> in latest 2.6.35-25-server on x86_64
<ntemis> the kernel loaded 8169 driver
<smb> tgardner, Let me go back and do the Dapper one, but I think you should untangle the fix for openvz. (I'd probably do a separate patch anyway)
<ntemis> it should be 8168
<smb> tgardner, btw, when apw looked at it he noted that it seems to not only move it but the file modified had changed too. 
<ntemis> i searched realtek site and they have a proper driver there
<ntemis> r8168-8.021.00.tar
<tgardner> smb, hmm, I can't see anything wrong with it. maybe I'm just dyslexic this morning.
<ntemis> can you please include it in a natty kernel?
<apw> ntemis, we are unlikely to pull in one of their tarball drivers if we have good support from an in kernel driver
<apw> already ... those drivers are often very nasty to debug and harder to maintain
<smb> tgardner, Ah, no. I guess he might have been misled by kernel/net.. and net/...
<ntemis> http://218.210.127.131/products/productsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&ProdID=239
<ntemis> this is the ifo for the card
<ntemis> LINUX driver for kernel 2.6.x and 2.4.x (Support x86 and x64)
<ntemis> 	8.021.00	2011/1/27	56k
<smb> tgardner, The main issue is that the fixup is not required by your change/cve but was required by his. So the fixup would now be attributed to the wrong cve
<ntemis> apw: why is using the 8169 driver? the manufacturer produce a 8168 driver for it
<apw> because the upstream driver claims that device, thus are claiming to support it
<apw> and indeed your own report here is that it does at least for frames up to a cirtain size right?
<ntemis> yes
<tgardner> smb, you're referring to the openvz patch?
<ntemis> Supports jumbo frame to 9K bytes
<ntemis> see features
<ntemis> current driver only 7k
<smb> tgardner, Yes, that additional line (setting that variable to zero) was part of a previous cve. (apparently someone did not do a complete test-build ;-)). You just stumbled over it when trying your build.
<ntemis> and also i loose the connection every now and then on the server
<ntemis> random disconnection
<ntemis> no ssh at all
<ntemis> i have to restart the server
<apw> ntemis, the former i don't expect is very important, the second is an issue indeed
<apw> realtek have not tried to make our lives easy by just dumpiing out tarballs for every driver
<apw> they are not easy to intregrate, maintain, or debug ... we are therefore very resistant to pull them in
<ntemis> :)
<ntemis> so what now?
<apw> i would recommend trying the latest natty kernel to see if the random dropouts are there too
<ntemis> i have to binutils and linux tree and install the realtek ones?
<ntemis> can i use the generic 2.3.37 stable kernel for natty on my server?
<apw> ntemis, have you any reason to think they are working any better
<ntemis> they are the manuf drivers :) ;)
<apw> no comment
<ntemis> dont know untill tested
<ntemis> lol
<ntemis> o.k
<ntemis> can i use the 2.6.37 generic kernel in this server?
<ntemis> the one in ppa
<apw> there is no support for the mainline kernels, so they are probabally not recommended for long term use; they are intended for debugging
<ntemis> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-natty/
<ntemis> this will fuction ok on a 10.10 release?
<sconklin> smb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579276
<ubot2> Launchpad bug 579276 in linux "Lost network in KVM VM / virtio_net page allocation failure" [Medium,Triaged]
<apw> ntemis, it may, it has no ubuntu sauce, so it may have trouble
<ntemis> i just want to be able to use my server , now i have to force shutdown from power every now and then
<ntemis> olny way to comunicate is from that eth0
<ntemis> one final question apw
<ntemis> apw: is the v2.6.37-natty kernel includes drivers for the nic's or i have to load them manually
<apw> ntemis, as i say i would recommended testing with a latest natty kernel to see if that is fixed, helps us find fixed
<apw> ntemis, i would say it has the same drivers as previous versions so should support the same cards
<ntemis> you mean go for 2.6.38 rc?
<apw> ntemis, i would myself, i would pick the natty kerenl as it has the ubuntu sauce and is more likely to work with your userspace
<ntemis> am seeing this: v2.6.37-rc2-maverick/
<ntemis> what do you think?
<ntemis> or this:	v2.6.38-rc3-natty
<apw> i personally wouldn't run any of the kernel-ppa ones in a production env for very long, i would go for a full 2.6.37 without -rc if wanting 27, but again there are 27 based natty kerenls, i would use those
<ntemis> thanks
<tgardner> smb, so back to the Hardy review for Hardy CVE-2010-3880. Are you thinking the extra cruft should be folded back into the patch for CVE-2010-3876 (which is where it appears to have come from) ?
<ubot2> tgardner: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)
<ubot2> tgardner: net/packet/af_packet.c in the Linux kernel before 2.6.37-rc2 does not properly initialize certain structure members, which allows local users to obtain potentially sensitive information from kernel stack memory by leveraging the CAP_NET_RAW capability to read copies of the applicable structures. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3876)
<smb> tgardner, I probably would suggest the lazy mode. Which is split it off as separate patch and add references to 3876.
<tgardner> smb, OK, I'll get to it in a bit.
<apw> sforshee, can hear but not reply at the moment
<apw> running strace on X to ensure you got the command right for someone, is a _really_ stupid idea
<ntemis> apw: you here?
<apw> ntemis, s'up
<ntemis> i installed 2.6.37 natty
<ntemis> 64bit
<ntemis> all ok
<apw> ok so upstream has fixed something then
<ntemis> dont know yet
<ntemis> i will leave it on for a few days
<apw> ok
<ntemis> if it looses connection is a negative
<ntemis> am gonna try jumbo frames on this one to see any dif
<ntemis> nope
<ntemis> same output
<ntemis> SIOCSIFMTU: Invalid argument
<ntemis> am stuck at 1500 mtu
<ntemis> for now :)
<ntemis> i hope 11.04 is the sweet spot
<ntemis> all survive the update nfs server samba etc
<ntemis> hmmm....
<ntemis> server is faster on this kernel!
<ntemis> is it a placebo?
<apw> ntemis, depends what you are using it for, there are changes in there to make it more responsive
<ntemis> it is more responsive!
<ntemis> CPU usage 	27% user, 4% kernel, 52% IO, 18% idle
<ntemis> and responsive as hell
<ntemis> a job welldone!
<ntemis> Real memory 	3.87 GB total, 498.02 MB used
<ntemis> my god!
<ntemis> thanks guys
<ntemis> 2.6.37 rocks
<ogra> tgardner-afk, the plan for OMAP4 was that we have an installable .deb of .38 in the archive so people can install and test it, we wont build images with that 
<ogra> tgardner-afk, for *images* we need display, which is why i insisted to have it ready asap, a .deb and branch would be fine earlier
<bjf> ogra, so the OMAP4 flavour (non-display) that is built from main, will that be an officially supported flavour ? 
<ogra> bjf, that will become the natty kernel, once the missing features are in
<ogra> and yes, omap4 is an officially supported platform 
<ogra> (since maverick)
<bjf> ogra, i'm trying to ask (poorly i know) will there be two supported Natty OMAP4 kernels, one built from the master branch (2.6.38) and one built from the ti-omap4 topic branch ?
<ogra> no
<ogra> the actual plan is that we get a working .38 kernel before kernel freeze 
<bjf> ogra, and if that doesn't happen ?
<ogra> the prob is that .38 is not yet feature complete so we need .35 for images until thats done
<ogra> bjf, if that doesnt happen people will be killed i guess :)
<ogra> or something similar will happen 
<bjf> ogra, sounds like a plan ! :-)
<JFo> <-need more coffee, brb
<rigved> hi everyone...i created a initramfs for 2.6.32-28, which i had built eariler (following Linux Kernel in a Nutshell guide). when i try to boot into this in qemu, i get the error - unable to find udev. can anyone tell me what i'm doing wrong here
<apw> rigved, how did you make it?
<rigved> apw: you mean the initramfs?
<apw> rigved, yes
<rigved> apw: using mkintramfs
<rigved> apw: wait, i'll tell you the exact command
<rigved> apw: sudo mkinitramfs -f -o /boot/initrd.img-2.6.32.28 -v 2.6.32.28
<jjohansen> rigved: try sudo update-initramfs -c -k 2.6.32.28
<rigved> jjohansen: ok. wait, i'll give it a try
<jjohansen> rigved: you will also want to run update-grub after that so that grub knows about the new kernel
<psurbhi> smb, ping
<rigved> jjohansen: ya i had done that...i booted into the new kernel also...it showed me the Ubuntu 10.04 booting screen...with the dots...then it gave me this error and dropped me to a initramfs shell
<tgardner> ogra, whats your call on the minimal ti-omap4 kernel for Natty? Is there any reason folks couldn't use the Linaro kernel until TI can get graphics in shape?
<smb> psurbhi, hey, though I currently got only one eye and hand free
<psurbhi> smb, what happened?
<smb> psurbhi, I am on the phone :)
<psurbhi> heh
<psurbhi> i will wait for u
<rigved> jjohansen: so when i run this command it generated the image, but it couldn't find any files under /lib/modules/2.6.32.28/ in the guide it said to put the built kernel in a test folder.
<jjohansen> rigved: how did you build your kernel and how did you install it
<rigved> jjohansen: make O=~/linux/linux-2.6.32.28/ menuconfig.
<ogra> tgardner, see above :)
<rigved> jjohansen: then make modules_install.
<ogra> <ogra> tgardner-afk, the plan for OMAP4 was that we have an installable .deb of .38 in the archive so people can install and test it, we wont build images with that 
<ogra> <ogra> tgardner-afk, for *images* we need display, which is why i insisted to have it ready asap, a .deb and branch would be fine earlier
<rigved> jjohansen: then make O=~/linux/linux-2.6.32.28/ ARCH=i386.
<rigved> jjohansen: sorry that's make O=~/linux/linux-2.6.32.28/ ARCH=i386 install
<ogra> tgardner, we should have a kernel in the archive asap so we can see whats broken in TIs tree and track the progress, while it is currently starting off from mainline i expect many patches that are pre-promoted in that tree before they hit upstream 
<tgardner> ogra, so, you're willing to suffer the regression of no GUI for awhile? I'm not really interested in managing 2 ti-omap4 packages.
<ogra> well, no
<ogra> we need .35 for finishing off the GUI work on unity-2d
<ogra> i dont expect any changes to .35 
<ogra> none at all 
<ogra> just leave it rot and lets care for .38
<rigved> jjohansen: sorry again. i had typed sudo for the last two commands
<tgardner> ogra, so, you want me to carry yet another kernel _and_ meta package for Natty? Or can folks just use the Maverick kernel after I pull 2.6.38 into the Natty ti-omap4 branch?
<ogra> hmm, no, it needs a different name indeed
<ogra> we dont need a meta
<ogra> just a binary
<jjohansen> rigved: so the make install, make modules install should have put a kernel image in /boot/ and installed the modules in /lib/modules/
<jjohansen> rigved: so what do you have under /lib/modules/
<rsalveti> problem is that we want a new kernel but still need to use the older one to generate images
<ogra> tgardner, we still need meta and .35 for images 
<ogra> but threre wont be changes to it
<tgardner> ogra, could we get by with building the development kernel in a PPA ?
<apw> why can't the new kernel hang out in a PPA until its ready
<rigved> jjohansen: there are quite some files in /lib/modules/2.6.32.28/
<ogra> worst case that would suffice, yep
<rigved> jjohansen: i'm going to try to boot into qemu using the new initrd-img
<jjohansen> rigved: err I thought you said that lib /lib/modules/2.6.32.28/ was missing
<rigved> jjohansen: that's what update-initramfs said. but there are files under it
<apw> its not even clear we need it in a PPA, we do most testing with hand rolled .debs anyhow
<jjohansen> rigved: oh, okay I didn't realize it was only update-initramfs that was having the problem with that
<apw> ogra, its not even clear we need it in a PPA, we do most testing with hand rolled .debs anyhow
<jjohansen> rigved: maybe try update-initramfs -u -k all
<JFo> <- grabbing a bite to eat, back son
<JFo> soon*
<rigved> jjohansen: so in virtualbox i get a different error: ALERT! /dev/disk/by-uuid/blah blah blah does not exist. Dropping to shell. then i have a initramfs shell (busybox)
<rigved> jjohansen: now i'll try qemu
<rigved> jjohansen: then i'll try the other command which you gave
<ogra> apw, we want a .deb available asap, i dont care at all where we pull it from (it would be cooler to have it in the archive but indeed i dont want to add extra work for you guys)
<apw> ogra, so do we have a tree yet?
<tgardner> apw, ogra: we could do this in the pre-proposed PPA perhaps.
<apw> tgardner, if its arm does it need to be a de-virt one yet ?
<apw> still ?
<ogra> yes
<tgardner> apw, uh, you might be right
<ogra> until we get the pandas that are ordered since Nov.
<tgardner> apw, we only have one de-virt PPA, right?
<apw> yeah, and i'd say for this use case a cross-build is as good
<apw> so the main blocker is having a tree to make it out of
<tgardner> apw, well, we could carry a dev branch for awhile.
<rigved> jjohansen: same error in qemu.
<rigved> jjohansen: now i'll try the other command
<apw> tgardner, yeah i recon keep it in a separate branch but internally thinking its ti-omap4 until its ready, in the main repo
<ogra> apw, cross isnt an option 
<apw> then we can just shove it over the top
<apw> ogra, why not?
<tgardner> apw, my thoughts exactly
<ogra> we need the same thing we will get from the builders else testing is moot
<bryceh> [ 4635.189079] exe (9084): /proc/9084/oom_adj is deprecated, please use /proc/9084/oom_score_adj instead.
<apw> ogra, define the same ?
<bryceh> ^^ does such an error message indicate the oom handler got called?
<apw> its built witht he same compilers, just the cross versions
<ogra> note that we also want to be sure the toolchain dtrt etc
<apw> you normally test cross built ones
<psurbhi> smb, i am pushng off for dinner ... its very late in here.. wanted to discuss bug 709392
<ubot2> Launchpad bug 709392 in nfs-utils "NFS client does not submit "nfs_file_sync" write requests when the file open call includes O_SYNC." [High,Triaged] https://launchpad.net/bugs/709392
<psurbhi> maybe  tomorrow
<ogra> hmpf
<psurbhi> see you around!
<tgardner> apw, ogra: we can use the c-k-t PPA for Natty. It won't collide with anything going on right now. This should all resolve itslef by mid April
<apw> tgardner, yep fine with me
<ogra> tgardner, that sounds good
<tgardner> ok, resolved.
<apw> well other than the lack of a tree to package right ?
<ogra> i'm really more confident in natively built packages, sorry for being so stuck in that 
<tgardner> ogra, I'll respond to Sebastien and Nicholas
<ogra> thanks, i seem to have a mail prob i just tried to send an answer
<apw> ogra, you are right at the end of the process you can't say its deffo good unless its native
<apw> ogra, for the majority of the builds before that i recon you are fine, and you save 6 hours a cycle
<ogra> i would just like to exclude all possible issues so we can see the real probs with the code
<apw> then you pay 7 hours a spin, i'd be suicidal at that
<ogra> and i'm sure there will be enough
<apw> but its your life
<ogra> we dont user that kernel on any images so 7h are fine imho
<ogra> it doesnt block anything 
<herton> bryceh: nope, just that the process is trying to set oom_adj, it's a deprecated interface now
<herton> for oom parameter, process should use now oom_score_adj
<herton> Documentation/feature-removal-schedule.txt explains it better in linux source (/proc/<pid>/oom_adj section)
<ogra> whoever is ML admin for the kernel list, please reject the duplicated mail from ogra@grawert.net that will end up in your queue
<ogra> (it was also sent from ogra@ubuntu.com and got through the queue already)
<tgardner> ogra, thats me
<ogra> just throw it away please (if yuo do your admin work anyway, no need for extra action)
<tgardner> ogra, done
<ogra> bah, so you did extra action :P
<ogra> thansk :)
<bryceh> herton, thanks
 * tgardner --> lunch
<niemeyer> Greetings
<niemeyer> Is there a way to *reserve* a contiguous area of virtual address space within a process, without having it interpreted as an allocation (e.g. without hitting ulimit -v problems)?
<rigved> jjohansen: hi. i did some googling and found out that the problem is caused because the kernel is unable to mount a SATA HDD. So, in virtualbox, i changed the SATA HDD to a IDE HDD, and it worked. any idea what is happening here?
<zul> has anyone seen this on 2.6.38 with running kpartx? http://pastebin.ubuntu.com/564033/
<rigved> jjohansen: this is the bug report on launchpad - bug 576071
<ubot2> Launchpad bug 576071 in ubuntu "After upgrade to Lucid /dev/disk/by-uuid missing when booting with initramfs" [Undecided,Incomplete] https://launchpad.net/bugs/576071
<jjohansen> rigved: okay hrmm, I don't know anything atm but will take a look
<herton> zul: looks you hit the same bug as LP#700165
<herton> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/700165)
<ubot2> Launchpad bug 700165 in linux "qemu-nbd kthread becomes defunct on disconnect" [High,Fix released]
<rigved> jjohansen: i don't know what's happening exactly, i don't even understand teh bug report...but atleast now i can move forward in the kernel guide. thanks for your help. it's very late here. i'm off to sleep. good day
<kees> smb: oh! http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f12d3d04e8f6223276abb068c5d72852174b8c31 should fix the Xen issues with RO/NX. can you re-enable that for the Xen builds?
<niemeyer> kees: Any idea about the question above, or at least a direction I could look at?
<niemeyer> herton: Bem vindo, btw :)
 * kees reads backscroll
<niemeyer> Is there a way to *reserve* a contiguous area of virtual address space within a process, without having it interpreted as an allocation (e.g. without hitting ulimit -v problems)?
<niemeyer> kees: ^
<kees> I'm not sure what the difference between "reserve" and "allocate" really would be.
<kees> are you just trying to stop something from using a static range of memory?
<herton> niemeyer: obrigado :)
<niemeyer> kees: That's it
<niemeyer> kees: So that in the future the page can be mapped continuously with the previous page, if necessary
<niemeyer> kees: The trick being used now is to mmap() a big range with prot=0, and then changing the prot when it's actually needed
<niemeyer> kees: It all works well, except that the dumb backend of ulimit -v restricts address space for no reason
<niemeyer> (why the heck people use that)
<kees> out of curiosity, why do you care about contiguous future memory allocation?
<bguthro> kees / smb: I just noticed the kernel.org changeset above. Are there normally xen builds against the ubuntu kernel? If so - where could I find them?
<kees> bguthro: the "linux-ec2" (Xen guest) is part of the normal natty kernel builds of the "linux" source package.
<kees> niemeyer: anyway, you're only ever fighting against glibc, so you probably just want to use your own heap allocator.
<bguthro> ah. Its a domU kernel. that makes more sense...I was hoping for the dom0 white whale
<niemeyer> kees: It is "my own" heap allocator, actually :-) (Go's, to be more precise)
<niemeyer> kees: The algorithm gets simpler and faster with it
<kees> niemeyer: if you control the allocator, why do you need the reserve memory regions? you just need to not use them. :P
<niemeyer> kees: Because other libraries have their own allocators, which will get in the way and explode the application if the area is not reserved
<kees> niemeyer: right, I mean _replace_ the glibc allocator.
<kees> niemeyer: so that your allocator is being used for all calls.
<niemeyer> kees: I don't get what you mean.  Any library doing mmap() can take a page in a non-reserved space.
<niemeyer> kees: It doesn't matter what glibc is doing
<kees> niemeyer: ah, okay, sure. most just use malloc, though.
<niemeyer> kees: mmap() is used for other reasons besides building the arena for malloc
<kees> niemeyer: but anyway, I get what you're saying. I'm not aware of a way to mark mmap regions offlimits without actually allocating them.
<niemeyer> kees: Ok, cool
<niemeyer> kees: Do you know if there's a viable alternative to ulimit -v which doesn't hit the issue?
<niemeyer> kees: It looks like most people doing ulimit -v are really trying to restrict swapping
<niemeyer> kees: But the limit of virtual space is much more encompassing than this
<kees> how much are you reserving? most sane users of ulimit -v shouldn't be setting it too low
<kees> e.g. I use ulimit -v for local builds to make sure things like gcc and glibc testsuites don't wreck my system.
<niemeyer> kees: A lot.. or nothing, depending on the POV :-)
<niemeyer> kees: 16GB, for instance
<niemeyer> It's quite a bit, but nothing taking a 64bit space in account
<kees> O_o
<kees> are you really growing continugous areas so frequently that you can't just use realloc?
<bryceh> is   video=vesafb:off   the right way to disable vesafb?
<niemeyer> kees: That doesn't work for a memory arena.. we're talking about the thing that backs malloc()
<niemeyer> kees: realloc would mean all pointers inside the region shifting
<niemeyer> kees: This is possible in the future, but it's a much larger problem than the one we're talking about
<kees> niemeyer: but if it's for an arena why do you need it contiguous? can't you just have multiple arenas?
<niemeyer> kees: Yes, that was the old implementation.. a contiguous region makes things a lot simpler and faster.
<niemeyer> kees: E.g. 16GB is mapped with 22 bits (* page size)
 * kees wonders if the kernel anonymous mmap routine uses greedy or "after last" allocations.
<kees> i.e. alloc something, then alloc something 16GB later.
<kees> will the next mmap end up in the middle, or after?
<niemeyer> kees: Good question
<kees> niemeyer: it works...
<kees> wait, no
<kees> yeah, seems to work.
<kees> $ ./mmap 
<kees> 0x7f3b94f0c000 -> 0x7f3f94f0c000: 16384M
<kees> 0x7f3b94f0a000: ok
<kees> 7f3b94f11000-7f3b94f12000 rw-p 00000000 00:00 0 
<kees> 7f3f94f0c000-7f3f94f0d000 ---p 00000000 00:00 0 
 * kees attempts a larger secondary allocation....
<niemeyer> kees: Hmm.. I don't think I get it
<niemeyer> kees: This shows you're actually allocating 16GB, right?
<kees> nope.
<kees>     start = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
<kees>     end = mmap(start + 16L*1024L*1024L*1024L, 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
<kees>     more = mmap(NULL, 4096*1024, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
<kees> and more ends up below start, not above it
<niemeyer> kees: Ahh, ok
<niemeyer> kees: You mean below end?
<kees> so... maybe you can use that, but I have no idea how stable it might be.
<kees> no, 0x7f3b94f0a000 (more) is less than 0x7f3b94f0c000 (start)
<kees> looks like it's growing the heap down.
<kees> but this is probably all academic; there's nothing that says it won't change behavior at any moment. :P
<niemeyer> kees: Well, hmm.. I don't think I understand why the experiment proves something useful
<niemeyer> kees: You're allocating two pages consecutively, and they are 8k apart from each other?
<niemeyer> >>> 0x7f3b94f0a000 - 0x7f3b94f0c000
<niemeyer> -8192
<kees> niemeyer: because the kernel didn't allocate anything between 0x7f3b94f0c000 and 0x7f3f94f0c000, leaving a 16GB gap
<kees> and, ta-da, I broke it.
<kees> niemeyer: it looks like it's just finding "best match" for anonymous mappings
<kees> I can get it to alloc "start" below libc, and "end" after libc...
<kees> so... nevermind! :P
<niemeyer> I see
<niemeyer> kees: Was a valid experiment, though
 * kees nods
<bryceh> JFo, bug #711568 turned out to be a kernel regression.  Upstream has committed a kernel patch, mind adding this to the kernel team's list to look at?
<ubot2> Launchpad bug 711568 in xserver-xorg-video-intel "Dithering regression on Intel graphics with .38 Natty kernel" [Undecided,New] https://launchpad.net/bugs/711568
<JFo> I don't mind at all bryceh :)
<JFo> looks like apw beat me to the punch, but I went ahead and added the patch tag
<JFo> thanks for the heads up bryceh :)
<bryceh> sure
<bryceh> hopefully I'll have more to come.  There's been a spate of gpu lockups lately, something must be futzed in the .38 drm still.
<niemeyer> kees: How did you figure it wasn't deterministic?
<kees> niemeyer: I switched start/end to use PROT_NONE, and looked at the maps file.
<kees> niemeyer: there was all kinds of stuff between the two :(
<niemeyer> Hmmm..
<niemeyer> Ok
<kees> niemeyer: http://paste.ubuntu.com/564073/
<niemeyer> kees: Thanks
<kees> np
<niemeyer> kees: Hmmm
<niemeyer> kees: That's not a definitive answer I think
<kees> niemeyer: no, it shows it's pretty unstable.
<niemeyer> kees: What I mean is that the compiler can choose to allocate certain libraries in fixed addresses
<niemeyer> kees: This would affect such placement
<kees> niemeyer: right, but that's against packaging policy (libraries must be -fPIC)
<niemeyer> kees: Not really.. -fPIC just says the code should be relocatable
<niemeyer> kees: It doesn't limit the freedom to put such code in a given address
<niemeyer> kees: linker vs. compiler in this case
<kees> niemeyer: okay, yes, that's true.
<kees> but any pinning of objection locations would defeat the security purpose of ASLR
<bjf> JFo, can you accept nominations on bug #714732 and bug #714846 ? thanks.
<ubot2> Launchpad bug 714732 in linux "Maverick update to 2.6.35.11 stable release" [Undecided,New] https://launchpad.net/bugs/714732
<ubot2> Launchpad bug 714846 in linux "CVE-2010-4242" [Undecided,New] https://launchpad.net/bugs/714846
<JFo> bjf, I can indeed
<JFo> bjf, done
<JFo> :)
<bjf> thanks
<JFo> my pleasure
#ubuntu-kernel 2011-02-08
<ohsix> theres room for the usb end of things to be clever as well; like only sending drawing operations or doing delta coding in the driver
<ohsix> if it were pushing new pixels for every displayed frame it'd be pretty gimped
<ohsix> buffalo has a wireless usb one too
<RAOF> -ECHAN? :)
 * smb yawns
 * apw knows how smb feels
 * smb checks the clock and decides apw must be an imagination at this time of day
<psurbhi> smb, ping
<smb> psurbhi, Yup, whats up?
<psurbhi> smb, hie
<psurbhi> waned to discuss the nfs bug
<psurbhi> in case of Lucid, does not commit_inode() call WRITE rather than COMMIT?
<smb> Sure. Well from my tests it does do a WRITE with UNSTABLE and then a COMMIT
<smb> Which is valid nfs v3 behavior
<psurbhi> is this what you see for Lucid?
<smb> The issue seems to be that the description for what O_SYNC does for a nfs filesystem does sound like it shout switch back to the nfs v2 mode
<smb> Which is to send every write with the FILE_SYNC flag set
<smb> forcing the server to write out every packet before replying
<psurbhi> i thought that in Lucid, instead of a COMMIT a WRITE occurs
<smb> while nfs v3 uses the commit packet to force a write out
<psurbhi> in the upstream code, nfs_file_fsync() eventually calls COMMIT procedure (at the client side)
<smb> Not according to my log. And even from what I read from the bug report
<psurbhi> the bug report is for lucid
<psurbhi> for lucid i thought that a WRITE is called
<smb> The ibug report is about the fact that they use O_SYNC for the file open and still get the write/commit sequnec
<psurbhi> ok..
<psurbhi> in case of upstream instead of the WRITE, COMMIT is called
<smb> WRITE gets called in both cases but for the old mode it sets FILE_SYNC and for the new one it uses UNSTABLE
<smb> and additionally in the new case the WRITE is followed by a commit
<psurbhi> my understanding is that in the new mode (in the upstream kernel) it calls only COMMIT if the sync flag is used
<smb> No
<psurbhi> and since the data does get to the backing storage this should suffice
<smb> You see a write, write reply and commit, commit reply when you look at the screenshot
<psurbhi> for upstream code or lucid?
<smb> both
<psurbhi> for lucid, i cannot seem to see the commit
<psurbhi> and by tracing the upstream code i thought that nfs_file_fsync only calls COMMIT procedure
<psurbhi> no?
<smb> no
<psurbhi> but the same nfs_file_fsync in lucid calls WRITE
<psurbhi> let me check again
<smb> The writes use unstable (you cannot just call commit)
<smb> commit does nothing but to indicate a writeout/sync to the server
<smb> look at comment #10 in the private bug
<smb> psurbhi, And that is exactly the same as I saw in my wireshark logs
<psurbhi> in the upstream code, i can see that nfs_file_fsync() -> nfs_commit() -> nfs_commit_list() -> nfs_commit_rpcsetup()
<psurbhi> which ultimately calls COMMIT procedure
<smb> This is the function called for a sync
<smb> And only does a sync
<psurbhi> correct
<smb> The bug is about the fact that the write request(s) use UNSTABLE and not NFS_FILE_SYNC as flags to the write requests
<psurbhi> but this is the same function called for O_SYNC too
<psurbhi> so what i am saying is this
<psurbhi> that the semantics of O_SYNC say that the data needs to be backed on stable storage
<psurbhi> nfs specification does not say how to do that
<psurbhi> so a  client is free to do it with a COMMIT
<psurbhi> or with a WRITE
<psurbhi> where argument stable is FILE_SYNC
<psurbhi> in case of upstream code this is done with COMMIT
<psurbhi> in case of Lucid
<psurbhi> nfs_do_fsync() ultimately calls WRITE
<psurbhi> and does not mark the stable arg as "FILE_SYNC"
<psurbhi> so i think the code works well in upstream code
<psurbhi> but not for lucid
<smb> Well first. The wireshark logs look exactly the same for upstream and lucid. So I do not see where you get the wrong behavior for Lucid
<psurbhi> does the  COMMIT arise because of writeback behavior in Lucid?
<psurbhi> rather than a synchronous behavior?
<smb> Second the new mode is nfs v3 behavior and documentation about O_SYNC says it is supposed to switch back the way things are done to the mode nfs v2 used
<smb> which is to mark every wreite with sync
<psurbhi> but the nfs specification does not say anything about it
<psurbhi> or no?
<psurbhi> i mean the rfc 1813
<smb> The nfs spec says that a v3 client can use the new mode and the server responds in the new way. Or the old mode and the server responds in the old way. The spec does not directly say anything about O_SYNC there. That I found in some description about the file flags in Linux
<psurbhi> correct
<smb> http://www.faqs.org/docs/Linux-HOWTO/NFS-HOWTO.html#MOUNTOPTIONS
<smb> In addition to the above definition of synchronous behavior, the client may explicitly insist on total synchronous behavior, regardless of the protocol, by opening all files with the O_SYNC option. In this case, all replies to client requests will wait until the data has hit the server's disk, regardless of the protocol used (meaning that, in NFS version 3, all requests will be NFS_FILE_SYNC requests, and will require that the Server returns t
<smb> his status). In that case, the performance of NFS Version 2 and NFS Version 3 will be virtually identical.
<psurbhi> i agree on the part of hitting the stable storage
<psurbhi> but that could be done with COMMMIT too
<psurbhi> so i dont see why this should be a bug?
<smb> meaning that, in NFS version 3, all requests will be NFS_FILE_SYNC requests
<smb> which is not the case
<psurbhi> i think that NFS_FILE_SYNC is the return value?
<smb> no, its in the request as well
<psurbhi> and the description is when the whole filesystem is mounted with sync option
<psurbhi> somehow semantically its the same
<psurbhi> as the data needs to be written to the backing storage
<psurbhi> when the file is opened with a sync
<psurbhi> O_SYNC flag
<psurbhi> and about the O_DIRECT
<psurbhi> nfs_file_direct_write() is called in this case
<psurbhi> the comment for this code says the following
<psurbhi> We avoid unnecessary page cache invalidations for normal cached
<psurbhi> readers of this file
<psurbhi> I am not sure this is a good thing
<psurbhi> also, the rpcs are often optimised depending on if data is found in the client cache
<psurbhi> in this case, since we bypass the client cache totally
<psurbhi> there is no oportunity to do this
<smb> The sentence above talks about opening *files* (regardless of the mount option used)
<psurbhi> but the bug is not about the mount option
<psurbhi> its about opening a file
<psurbhi> with O_SYNC
<psurbhi> so the filesystem might nt have been mounted with sync flag
<smb> And that using O_DIRECT changes it is rather lucky as the testcase only uses a short data size
<psurbhi> i think the test case was just to show us
<psurbhi> that the bug exists
<psurbhi> in generic terms
<psurbhi> its not correct to use O_DIRECT
<psurbhi> when u need O_SYNC
<psurbhi> there could be multiple apps opening the same file at the client side
<psurbhi> or one app opening the file multiple times as well
<psurbhi> in such cases O_DIRECT for getting FILE_SYNC would not be the same
<smb> And I just said that using O_DIRECT I can see that the client can use the other mode. Not necessarily that this always will result in the right behavior
<psurbhi> correct
<psurbhi> i agree on that
<smb> The bug is about the fact that O_SYNC is described as changing the behavior
<psurbhi> but there was a comment about using this as a workaround
<smb> regardless whetehr the mount option sync was used
<psurbhi> and i dont see this being a work around
<psurbhi> smb, exactly
<psurbhi> so i am saying O_DIRECT cannot be a work around
<psurbhi> and I feel that in upstream code nfs_file_fsync() is used for O_SYNC
<psurbhi> and this uses COMMIT to gurantee data sync on stable storage at server side
<psurbhi> so i think this cannot be an upstream bug
<psurbhi> but ofcourse these are my thoughts
<psurbhi> if they help, then great..
<psurbhi> :)
<smb> Well this might be a shortcomming of the testcase
<psurbhi> oko
<smb> I can see a commit but this may result from the file getting closed
<psurbhi> exactly
<psurbhi> in case of lucid
<psurbhi> this is what i feel
<psurbhi> :)
<psurbhi> where as in upstream, irrespective of close, if O_SYNC is used, then COMMIT will happen
<smb> Ok, I see your point now
<psurbhi> ok, great :) thanks !!
<smb> psurbhi, Though I think that leads us to two issues
<smb> First, in lucid there might be a general problem of having not all the writes followed by a commit
<psurbhi> yessss
<psurbhi> :)
<psurbhi> in lucid fsync() too would never gurantee a COMMIT
<psurbhi> unless wbc->reclaim is set to 1
<smb> But secondly and this would be an upstream problem still, is that O_SYNC should give nfs2 behavior, which means all the writes should use writes with NFS_FILE__SYNC as a flg
<psurbhi> ok, on this one i differ
<psurbhi> because of what happens eventually to the data
<psurbhi> and by nfs rfc
<psurbhi> so that the client should be free to send whatever it wants to get the data to the disk
<psurbhi> could be through WRITE with stable=FILE_SYNC or with COMMIT
<smb> This is not about the data it is just : "ll requests will be NFS_FILE_SYNC requests"
<smb> all
<psurbhi> which will be the data+meta data
<psurbhi> which will happen with the COMMIT
<psurbhi> smb, correct
<psurbhi> and this is what i felt at first too
<psurbhi> but then decided against it because of the end result
<smb> IF all requests (including the write) are flagged with sync, you do not need the commit
<psurbhi> only write needs to flagged with SYNC
<psurbhi> O_SYNC gurantees that data is backed to the stable storage
<psurbhi> how the client achieves it 
<psurbhi> should not matter
<psurbhi> but i could be wrong here... maybe the semantics of the client matter 
<psurbhi> i am not sure
<psurbhi> but to me really since the data gets backed up
<psurbhi> O_SYNC from the applications perspective is achieved
<apw> psurbhi, yeah but that ignores the specific paragraph in the manual page which modified the behaviour ... right or wrong people should be able to assume the documented behaviour
<psurbhi> or it could be a documentation bug
<psurbhi> apw, which man page is this?
<apw> psurbhi, yeah it could, but advertised behaviour is often hard to change, even if it was a stupid thing to say originally :)
<psurbhi> agreed
<psurbhi> which man page is this really?
 * apw loses it, hang on
<psurbhi> also, i wonder why an application should look at the rpc flags? rather than the behavior?
<smb> apw, I found that on http://www.faqs.org/docs/Linux-HOWTO/NFS-HOWTO.html#MOUNTOPTIONS
<psurbhi> smb, ok
<smb> Not sure how official that is, but it may be a place the bug reporters looked at
<psurbhi> apw, smb, see you around then! 
<psurbhi> o/
<apw> psurbhi, sorry chatting about the issue on mumble
<psurbhi> ok
<apw> you are of course welcome
<_ruben> howdy, is there an "easy" way to capture kernel panics, as they tend to scroll off screen 
<herton> _ruben: there are some ways to capture crashes, a classic way is using serial console if you have a serial port on the machine
<herton> for serial console, on the machine you want to capture the crash, you enable serial console with:
<_ruben> its a vm (vmware esxi), so a virtual serial cable might be an option
<herton> console=tty console=ttyS0
<herton> ah ok, so you can try this way, enable serial console on the guest, and then attach a minicom etc. on capture machine/host
<herton> probably for vmware the setup is similar as 'Serial Console in VirtualBox' listed here: https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks
<herton> you may want to check that out
<_ruben> seems i can bind a serial port to a ip:port in esxi
<_ruben> if only it'd work
 * apw wanders to find a monitor ...
<_ruben> ah nice .. got it to work and caught the oops
<_ruben> wonder if this a bird or kernel issue : http://pastebin.ubuntu.com/564390/
<_ruben> i'd be inclined to think kernel, since quagga causes similar crashes
<_ruben> hm, this one doesn't even mention bird: http://pastebin.ubuntu.com/564402/
<_ruben> and then there's http://pastebin.ubuntu.com/564405/ .. everything's ipv6 related, but i dont see much (other) common factors
<herton> _ruben: not much ideas on this, the kernel shouldn't oops, I'm downloading the debugging symbols from this kernel to check more
<herton> (the ddeb package)
<_ruben> herton: the oopses happen within a minute after i enable ospf in bird6 .. since ipv6 support is fairly new in bird, it could very well be problem with bird(6) .. but even then, the kernel should be robust enough i'd say to handle userland "misbehaviour"
<herton> _ruben: meanwhile, you can try boot with slub_debug kernel parameter and test again, see if you get a report/different trace from slub, just to check if isn't some sort of memory corruption (double kfree, use after free, etc.) which makes code crash later, and different stack traces
<_ruben> herton: let me try that
<_ruben> herton: wow .. adding that option made it crash before i had a change to log in
<_ruben> hm, that was an ipsec related one
<herton> _ruben: did you got the oops/trace of this crash? probably is what is causing the corruption/bug
<_ruben> ah, that's quite likely actually .. part my ipv6 stuff runs over an ipsec tunnel with ipv4 on the outside and ipv6 on the inside .. and using the klips stack at that, let's try it with netkey .. and yeah, i got the oops, will pastebin it in a sec
<_ruben> http://pastebin.ubuntu.com/564425/
<herton> _ruben: most likely ipsec module is broken, it isn't stock in the kernel, do you know where you got it from?
<herton> I went to check but ipsec isn't on debug package/kernel, so should be a external built module
<_ruben> herton: it's part of openswan .. and there ipv6 is quite "new" as well .. i'll take it up with them .. currently running with netkey stack and so far no problems (but also no full functionality yet, config issues)
<_ruben> herton: thanks for helping so far tho
<herton> _ruben: no problem. and indeed then should likely to be a bug in openswan
<_ruben> now to figure out why this isn't working with the netkey stack .. grr
<nigelb> apw: poke? :)
<nigelb> I'm looking for volunteers for a ubuntu developer week session :D
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<Gartral> hello, I see a fix was posted for Gobi2k 3g radios in Kernel, (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554099?comments=all) but I can't use that Kernel due to a TPM-locked Kernel architecture.. and I was hoping the needed driver was available as a Module.. my other problem is I can't compile the module myself as until i fix 3g in ubuntu, my computer won't have internet.
<ubot2> Launchpad bug 554099 in linux "Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken" [High,Fix released]
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<smb> bjf, not yet
<JFo> bjf, I am here btw :)
<smb> bjf, You may rush the server team out
<Gartral> hello, I see a fix was posted for Gobi2k 3g radios in Kernel, (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554099?comments=all) but I can't use that Kernel due to a TPM-locked Kernel architecture.. and I was hoping the needed driver was available as a Module.. my other problem is I can't compile the module myself as until i fix 3g in ubuntu, my computer won't have internet.
<ubot2> Launchpad bug 554099 in linux "Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken" [High,Fix released]
<Gartral> hello, I see a fix was posted for Gobi2k 3g radios in Kernel, (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554099?comments=all) but I can't use that Kernel due to a TPM-locked Kernel architecture.. and I was hoping the needed driver was available as a Module.. my other problem is I can't compile the module myself as until i fix 3g in ubuntu, my computer won't have internet.
<ubot2> Launchpad bug 554099 in linux "Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken" [High,Fix released]
<smb> Gartral, This bug was there to track that there was a) no gobi_loader (program to load the firmware) and for Lucid the driver itself did not have support for those newer modems. So fix here means that for Lucid this was added to a backports-modules-wwan package and Maverick got a gobi_loader package. So first question would be on which release you are running?
<smb> Actually the last status updates in that bug were caused by the upstream bug being closed as fixed in 2.6.35-rc1
<apw> JFo, hey ... about ?
<JFo> apw, yeah mostly
<JFo> still suffering a bit of a headache
<apw> we haven't talked for a while, probabally about time we did
<JFo> not as bad as it was last night
<apw> nasty
<JFo> k, let me get my headset... one sec.
<Gartral> smb: 10.10 I stopped keeping track of the names
<Gartral> and I have Gobi_loader but the card won't connect, it Sees Verizon Wireless, but the logs keep saying there's no carrier
<smb> Gartral, Ok, that was Maverick. So in that the kernel driver should be ok
<smb> ah ok
<Gartral> smb: i'm not on the Ubuntu Kernel either, I'm on a chrome kernel.. as that's the only thing this hardware boots
<Gartral> which, should work, as it does in ChromeOS
<smb> Cannot speak from first hand experinece but it felt like firmware issues were quite a source of trouble
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - February-15 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<niemeyer> kees: About the issue we explored the other day: https://groups.google.com/forum/?pli=1#!topic/linux.kernel/MDIzfQMT3zU
<smb> I believe to have it available as a modem would be a sign that the kernel driver is supporting it. But then every provider seemed to have slightly different firmware files. Which one needs to get from the right provider.
<smb> I am afraid I would not know more to help. But the bug report definitely was not concerned with more than to make the modem detected by the kernel driver, not specific connection issues,
<kees> niemeyer: cool
<JFo> <- food. hopefully that will help the head a bit. biab
 * jjohansen -> lunch
<seidos> i'm trying to install an older kernel through the kernel-ppa but not sure what package to install after adding the ppa.  any ideas?
<GrueMaster> So I see an updated kernel for dove in lucid and maverick, but no notification (saw it on the kernel-meeting mintutes).  It appears to be a security update, but I'm not sure.  Does it need verification?  There are no tags, and no one on my team was subscribed.
<apw> sconklin, ^^
<bjf> GrueMaster, we'll try to send out email when the pocket-copy to -proposed happens, at least after we know it's happened
<bryceh> JFo, bug #714719 looks to be another kernel drm bug.  There's a kernel patch that needs tested.
<sconklin> GrueMaster, apw: I don't know, Tim produced that kernel, and he's out today.
<ubot2> Launchpad bug 714719 in xserver-xorg-video-intel "[i915gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000004)" [High,Confirmed] https://launchpad.net/bugs/714719
<JFo> bryceh, thanks :)
<sconklin> I meant I don;t know whether verification is required. and what bjf said
<bryceh> JFo, next action for that bug is probably to roll a kernel .deb with that patch for the user to test, but I'll leave it in your capable hands here out
<GrueMaster> bjf: It sat in proposed since 2/4.
<JFo> k
<bjf> GrueMaster, you are correct
<GrueMaster> All I ask is for more timely notification.  For some reason it never made the maverick-changes or lucid-changes mailing lists.
<bjf> GrueMaster, we are not expecting you to do anything with it at this point, though I suppose a boot test would be nice
<bjf> GrueMaster, because these are happening as a pocket copy from a PPA to -proposed, i'm assuming this is bypassing the process that sends email to *-changes
<GrueMaster> I guess I need to know what to look for when I do run across these to know I can ignore them.
<GrueMaster> Otherwise I get blindsided, which is very disruptive.
<bjf> GrueMaster, we'll work on it
<GrueMaster> :)
<kees> GrueMaster: stuff in -proposed isn't announced to -changes because it isn't considered "published" yet.
<GrueMaster> This confuses me then, as I get updates for omap/omap4 via that mailing list.
<apw> JFo, bryceh got that one will do something tommorrow
<bryceh> JFo, apw, the good news is as I'm grinding through all these gpu lockup bugs, I'm having decent luck identifying dupes.  I think among these scores of bug reports there's only maybe 4-6 'real' bugs
<bryceh> apw, still finding tons for that vesafb issue; bunch filed against maverick too
<JFo> bryceh, that is a bit of good news :)
<apw> bryceh, sound good, sub me to them all and get jfo to put them on the list
<apw> and i'll spin them all tommorrow
<JFo> yep yep
<bryceh> apw, will do
<kees> GrueMaster: do you run the q-r-t tests when doing kernel testing? You might want to compare notes with hggdh
<GrueMaster> kees: QRT?  give me a hint (or a link).
<kees> GrueMaster: one sec
<kees> GrueMaster: I find https://wiki.ubuntu.com/KernelTeam/StableKernelMaintenance that mentions it. though there are more scripts.
<GrueMaster> I did find lp:qa-regression-testing.  Is that the same?
<kees> GrueMaster: yup.
<GrueMaster> Ok.  Pulling.  Thanks.
<GrueMaster> We'll see how much of these work on armel.
<kees> GrueMaster: it should work; I designed them to work. :) usually test-kernel*.py gets run, excepting -hardening, since that's for future work. and the aslr may take forever on arm, so you might want to skip that too.
<GrueMaster> These platforms sit idle, so they can churn until they die.
<GrueMaster> Current platforms can run overnight or on the weekend if needed.
<GrueMaster> My goal is to have as much automated tests running as possible during down time (i.e. nights & weekends).
<kees> GrueMaster: cool
<GrueMaster> Only problem so far is my lack of time to learn python.  I'm also frustrated that my son snagged my only python book.
<GrueMaster> (kids - sheesh).
<ikepanhc> bjf: sconklin: hi, do you recall the email I send ago about hardy netbook-lpia branch? anything suggested?
<ikepanhc> s/ago//
<bjf> ikepanhc, did you send it to the mailing list or direct to us ?
<sconklin> ikepanhc: no, when did you send it?
<ikepanhc> bjf: direct to you
<ikepanhc> bjf: about two weeks ago
<ikepanhc> sconklin: ^^
<sconklin> I'm looking for it - I don't see it in my inbox
<ikepanhc> sconklin: ok, I will resend it :)
<bjf> ikepanhc, i see one from 10/15 of last year
<ikepanhc> weird....
<ikepanhc> ok, resent
<sconklin> I got it
<bjf> ikepanhc, i got it as well
<ikepanhc> :)
<ikepanhc> sounds like smtp blocks me :(
<bjf> ikepanhc, i'm cloning it now
<ikepanhc> bjf: thanks
<sconklin> ikepanhc: I'm about to leave for the day - I'll look tomorrow unless Brad has it covered
<ikepanhc> sconklin: ok, thanks
<bjf> ikepanhc, i should be able to get it reviewed today
<ikepanhc> :)
<bryceh> JFo, btw here's a list of the GPU lockup bugs on my radar - http://tinyurl.com/4t7gtyz
<bryceh> JFo, in case you want to pre-emptively sub apw to any of them
<bryceh> JFo, all the ESR: 0x00000001 ones I'm betting to be dupes but don't have evidence of that yet
<JFo> ok
<JFo> I'll have a look at them :)
#ubuntu-kernel 2011-02-09
<ohsix> neat
<ohsix> or some other parallel try-out type thing
<cjwatson> ohsix: you're leaking across channels, FYI
<ohsix> i sure am, argh; still getting used to them being in the same window
 * apw yawns
<smb> apw, Morning, I'd send you some coffee but it would be cold on arrival
<jk-> hey smb & apw
<smb> jk-, Man, long time no read. :)
<apw> jk-, lives
<jk-> he does
<apw> jk-, not drowing or burning then?
<jk-> not that I'm aware of
<jk-> apw: mind if I parameterise baseCommit in the printchanges target?
<apw> jk-, in principle no, but where you going to get the parameter
<jk-> make basecommit=deadbeef printchanges
<jk-> ^apw
<jk-> hm, wonder if that'll still work with insertchanges
<smb> I beleive insertchanges was just reading in output from calling printchanges. You know that you can get that relatively simple using git-ubuntu-log itself?
<jk-> smb: yeah, but insert-changes.pl may not pass the parameter to the newly-invoked make
 * jk- looks at git-ubuntu-log
<smb> jk-, Not sure what use case you have in mind. It could be a bit tedious to do it manually more often
<jk-> ah, yep, but that still needs the list of changes on STDIN
<smb> But I sort of often used git log <range> | .../git-ubuntu.log
<jk-> smb: for custom builds, where we can't always rely on 'Ubuntu-$(release)-$(prev_revision)' being the base of the new changes
<smb> (Hm, though in that case you probably really want a version in the topic branch that matches with your start commit messages...
<jk-> yeah, that would be a good plan.
<jk-> I should get a template sorted for starting a new topic branch
<smb> apw, (who apparently dropped into a not-enough-coffee coma :-P) probably has more ideas. Though it feels like it may be possible to externalize (as a config file) the search tag
<jk-> woot :)
<apw> jk-, you'd need to make insertchanges pass it through i suspect, though a as its a $(MAKE) printchanges job, i think you can just $(MAKE) basecommit=$(basecommit) and be compatible
<apw> perhaps the thing to do is allow the Ubuntu- pattern be a definable
<jk-> yeah, i like that idea
<jk-> will put something together to do that
<apw> if that was in the 0- file as a default, then your *.mk in th branch could override it
<jk-> yup :)
<psurbhi> smb, ping
<smb> psurbhi, hey, whats up
<psurbhi> smb, hey! just the nfs bug again :)
<psurbhi> smb, for the lucid code, did you see a COMMIT as a part of the vfs_write() ? Like, does vfs_write wait till COMMIT is over? I thought it did not wait for a COMMIT.
<psurbhi> Whereas I thought that with upstream code, COMMIT is a part of vfs_write() and it waits till the COMMIT is over.
<smb> psurbhi, Frankly I did not look at the code but the tcpdump created by the dd. And there every write is followed by a commit. And the strace of the dd does not show any sync calls
<psurbhi> ok, then i think in Lucid, vfs_write does  not wait for COMMIT
<psurbhi> so the write is not synchronous in that sense
<psurbhi> atleast this is what it seems from the code
<psurbhi> whereas in upstream vfs_write() ultimately waits for COMMIT to complete
<smb> psurbhi, But fact is the next write did not happen before the commit was complete
<psurbhi> ok
<psurbhi> maybe, i missed something.. :)
<psurbhi> if not, then its a bug in Lucid and not upstream.. and so needs fixing in Lucid
<psurbhi> right
<smb> It is complicated enough and I did not want to understand all of the details when the practical test seemed to be ok at least. :)
<psurbhi> but the dump could possibly be a co-incidence
<psurbhi> in which case we will end up invalidating the bug
<psurbhi> when it actually really is a bug
<psurbhi> did you see a COMMIT for every write when oflag=sync or even without it?
<smb> I 100 times coincidence? I would rather believe that we missed the way this is done. I did see a commit for every write (at least looking at it) and I did not try without sync
<psurbhi> ok, great
<psurbhi> smb, thanks
<smb> psurbhi, Sure. If you think we miss something, feel free to bring it up. I was more interested in seeing the tcpdump apparently doing the same thing.
<psurbhi> smb, ok! 
<psurbhi> looking at the code, i just got a feeling that lucid would not synchronously wait for the COMMIT to occur
<psurbhi> so i thought i will just bring it up once..
<psurbhi> and as you said it is complicated... maybe i did just miss something
<psurbhi> its not apparent that it waits on the COMMIT
<psurbhi> whereas with upstream, its very apparent that it does wait for the COMMIT
<psurbhi> but i am glad you have it verified :)
<psurbhi> if i find something else, i will bring it up
<smb> Things seemed to have changed around quite a bit. So it could be just better hidden. Ok, sure. :)
<cking> apw, you around?
<cking> apparently not
 * apw_ is still out and about ... back soon
<apw> cking, hiya
<apw> cking, had a suit fitting
<smb> apw, sounds terrible. ;-)
<apw> yeah terrible :)
<apw> smb have i missed anything
<smb> apw, Not that I am aware of (beside of cking) 
 * apw pokes cking for fun
 * smb does not think apw would miss the lovely crackling sound broken natty mumble does
<apw> no not that either
<cking> apw, just wondered if you were alive..
<apw> yeah had to go out and pick out my suit
<komputes> Hi JFo 
<JFo> hi komputes 
<komputes> JFo: would there be any chance that we could edit the "Mainline kernel" auto-response or the wiki page to simplify the process for new users. I have gotten many responses from people that they don't know what to do to install a mainline kernel. I was just wondering if we could simplify the process.
<JFo> I'm already working on something for that
<JFo> it is in my blueprint for n-bug handling
<JFo> actually there are 2 items there relating to that
<JFo> so the short answer is 'yes, we are doing something about that' :)
<apw> i suspect komputes is offering to help with wording
<apw> komputes, do you have some specific suggestions on how we could improve it based on their feedback
<komputes> I could if needed. I would first suggest step by step instructions, not too much copy. Then I would specify which kernel needs to be tested.
<komputes> JFo: A lot of people don't understand which packages they need to install or where to install them from. I would guess http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ is what you want tested?
<JFo> yep
<JFo> the wording is something I have been doing testing on
<JFo> the idea being that the comment points them to the mainline testing page of the wiki
<JFo> that would then have some information on how to determine what kernel they would need to test
<komputes> JFo: for example For example for 2.6.27.15 we have the following files, for i386 you would need those marked with B and C, amd64 take those marked A & C:  <- too complicated for most
<komputes> JFo: except for the fact that many people do not understand the wiki instructions and give up there or come back to us asking for clarification, common issue.
<bjf> JFo, what's the url for the mailine testing page in the wiki ?
 * JFo digs it up
<komputes> bjf: https://wiki.ubuntu.com/Kernel/MainlineBuilds
<bjf> komputes, thanks
<komputes> JFo: what I would suggest is that you link top the correct files (2 or 3 debs) directly from the command. Based on the Arch of the reported and the kernel you want tested.
<komputes> s/top/to/
<komputes> s/reported/reporter/
<komputes> need coffee, BRB
<tgardner> apw: did you make any progress on your lapic issue?
<sforshee> does anyone know if the state of the hpet/lapic timers would affect the ability of a machine to resume from S3?
<sforshee> i've got an Atom machine that usually takes about 5 min to resume, but with nohz=off highres=off it comes up immediately
<sforshee> the big difference I see is how these timers are used
<sforshee> and interestingly, 5 min is exactly how long it takes the hpet to wrap 32 bits on this machine
<apw> tgardner, not as yet no ... am going to try the -rc4 kernel shortly
<tgardner> apw: check for a BIOS upgrade
<apw> tgardner, yeah will do, i'll get the puppy registered today
<JFo> komputes, sorry, I got strangled on my breakfast and have been dealing with that for the last bit
 * JFo goes to look at the mainline page
<komputes> JFo: sounds bad, was the heimlich maneuver involved?
<JFo> nope, no one else here but me
<JFo> it was dicey for a bit there
<tgardner> apw, https://launchpad.net/~doctormo/+archive/wacom-plus
<komputes> tgardner: for a sec there I thought there was a graphical wacom settings utility... got all excited :(
<tgardner> komputes, nah, pgraner was asking me about including the device driver.
 * JFo goes for more water
 * cking wonders if JFo is going to drink it or swim in it
<JFo> right now try to drink it, but I did try to breathe my food earlier :-/
<bjf> JFo, how often are you regenerating your kernel-buglist-by-team report ?
<JFo> should be hourly
<JFo> bjf, ^
<bjf> JFo, ack
<bjf> JFo, on the top of the hour ? 
<JFo> should be, yes
<Sarvatt> komputes: you mean like http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=9863ccf9d99fdd712778b31197365723b9caa0be :)
 * JFo checks the cron job
<JFo> bjf, yep, top of the hour
<komputes> Sarvatt: I'm so happy
<Sarvatt> komputes: natty+1, it's part of the gnome 3.0 stuff :(
<komputes> Sarvatt: this does mean wacom settings will be in mouse prefs right?
<Sarvatt> there will be a new wacom one, yeah
<komputes> Sarvatt: makes me giddy like a light-headed teenager at a Beatles concert
 * komputes screams
<Sarvatt> it could be easily backported to our g-s-d if someone felt adventurous enough, was originally written for 2.3x
<herton> sforshee: may be in your atom machine you hit the same bug as here: https://lkml.org/lkml/2011/1/19/491
<bjf> JFo, IMHO bugs with a status of "Incomplete" should not be on the report
<sforshee> herton, afraid not, this isn't a recent regression
<sforshee> it hasn't worked for a long time, maybe not ever
<herton> ah ok
<sforshee> herton, although I may be hitting it, as resuming devices does take 3+ seconds, but the majority of the delay is before that
<JFo> bjf, I can understand the argument
<JFo> it is a relatively simple thing to ignore them, but I thought we would want to see them since they are technically an open state
<JFo> and due to the ability of the masses to set Incomplete, I didn't want us to miss something
<bjf> i like to think of it as a "task" list and as I work one and ask for more testing and mark it incomplete, i'd like it to fall off the list until the status changes back (but that's just me)
<JFo> well, I am open to that if that is the generally accepted method :)
<bjf> JFo, what is the "staging" tag about ?
<JFo> bjf, not sure
<JFo> I think that is the first I have heard of it
<bjf> i'm seeing it on a number of the bugs i'm looking at 
<bjf> looks like apport probably put it on
<JFo> mind dropping me a bug number?
<bjf> jfo bug #689974
<ubot2> Launchpad bug 689974 in linux "frequent failure to boot with 2.6.37-9-generic #22-Ubuntu" [Undecided,New] https://launchpad.net/bugs/689974
<JFo> thanks
<JFo> huh
<JFo> I'm not sure
<JFo> looks like there are only 100 of them
<JFo> let me grab something to eat and look at these a bit
<JFo> bbiab
<bjf> JFo, it's trying to indicate that it's related to a driver that is in "staging"
<JFo> ah 
<bjf> JFo, but it does it in a fairly brain-dead way
<bjf> JFo, that change has been in there for quiet a while, interesting that we / i just started noticing it
<JFo> I was just wondering about that as the bug numbers seem to indicate it is a recent thing
<bjf> JFo, the patch went into apport 2010-02-22
<JFo> huh
<JFo> wonder why we are only just beginning to see them
<JFo> well, now/recently
<JFo> hmmm, I just found a bug from Sept 09 tagged staging
<bjf> JFo, if the string "module is from the staging directory" is in one of the Dmesg logs, that tag is applied
<bjf> JFo, even if the bug has nothing to do with the driver
<bjf> JFo, i can understand wanting to flag it, that just seems like overkill, but maybe that's just me
<JFo> I think it is overkill as well
<apw> http://people.canonical.com/~apw/XXX.html
<bryceh> apw, ooh porn!
<bryceh> oh wait
<JFo> of a sort, I suppose
<JFo> If you are into that sort of thing
<herton> bug porn
<JFo> heh
<apw> JFo, ok i've pushed up a branch containing some fixes to the kernel key bugs page, the main changes are to split the tags into their own column to aid sorting by regression and by team, it also splits out Incomplete into their own table
<apw> JFo, branch is here lp:~apw/canonical-qa-tracking/cleanup and produces a page as at http://people.canonical.com/~apw/XXX.html ... if you concur with the changes you can merge it into the live version
 * JFo looks
<JFo> I like the report :)
 * JFo pulls the branch.
<cking> snap
<apw> thats what would happen if he _stood_ on it
<JFo> heh
 * JFo chews on the branch. Great source of fiber
<apw> JFo, so the report just updated and looks the same
<apw> i guess the cranberry version needs updating
<JFo> yeah, I am looking over the changes
<JFo> I haven't yet updated the branch
<apw> ok
<JFo> apw, what file did you change?
<JFo> wait, think I found it
<JFo> yep, I found it
<apw> bzr log -p will show you the commits and file actual chane
<sconklin> http://electronicdesign.com/article/digital/Bad-Transistor-May-Not-Cost-A-Billion-Dollars.aspx?cid=ed_newsletter&amp;NL=1&amp;YM_RID=`email`
<JFo> k, apw, it is up and the first one has been generated
<apw> JFo, excellent thanks
<bjf> JFo, minor nit, might change the title from "Upstream Bug Report"
<JFo> yeah
<JFo> bjf, fixed it
<JFo> it will take a bit to trickle up to cranberry
 * tgardner --> lunch
<tgardner> apw, Natty master-next is working pretty well on my Emerald Ridge. 
<tgardner> bjf, can you review the CVE-2010-3880 patches so I can get it off my list?
<ubot2> tgardner: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)
<bjf> tgardner, looking
<bjf> tgardner, done
<tgardner> bjf, and the patches for Dapper/Karmic/Lucid/Maverick ?
<bjf> tgardner, acking them as we speak
<tgardner> bjf, ah, sorry. got ahead of yourself
 * jjohansen -> lunch
<tgardner> bjf, I'm not seeing dapper. 
<bjf> tgardner, looking, don't remember reviewing it
<tgardner> that would explain it
<bjf> tgardner, i see a minor issue with that patch, email sent
<tgardner> bjf, responded
<bjf> tgardner, you dropped const, however the struct was chaged from "rtattr" to "nlattr" in other patches
<tgardner> bjf, huh, good point. better check that out.
<tgardner> bjf, corrected
<bjf> tgardner, that was my only issue, other than that it looked good
<bjf> tgardner, ack sent
<tgardner> bjf, thanks. good eye.
<vanhoof> sconklin: is dannf's update to bug 698883 sufficient for verification?
<ubot2> Launchpad bug 698883 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/net/tun.c:725! - tun_chr_aio_read+0x428/0x430" [Undecided,Fix committed] https://launchpad.net/bugs/698883
<sconklin> vanhoof: looking
<vanhoof> sconklin: making the -proposed rounds :)
<sconklin> vanhoof: you know we're rolling a new release of almost everything and anything verified will be carried over, right?
<vanhoof> sconklin: correct, but might as well get these knocked out sooner than later
<vanhoof> sconklin: unless you'd prefer i wait until the next upload
<sconklin> right, just wanted to make sure we had no misunderstandings about when these would pulish
<sconklin> publish
 * vanhoof knows
<sconklin> No, please verify as early as possible
<vanhoof> sconklin: I am in constant close contact with bjf[afk] :D
<sconklin> and as far as I'm concerned, that's as good as we can get for that one.
<vanhoof> sconklin: awesome, thanks
<sconklin> Since there were no regressions from someone who actually uses that driver
<sconklin> you expecting me to set the tag or will you do it once LP comes back
<sconklin> ?
<vanhoof> sconklin: happy to set it once its back
<sconklin> ok. I'm outta here, I'm blocked until LP comes back write-enabled
<vanhoof> sconklin-gone: see ya
#ubuntu-kernel 2011-02-10
<apw> JFo, the buglist is showing permissions errors
<bjf> apw, LP had some downtime, could be due to that
<bjf> apw, seems like it's back up, could be we need the next crontab refresh
<bjf> apw, hmm, it's launchpad authentication. i want to see if it has the same error, next cron iteration
<JFo> fixed
<JFo> that was it bjf
<JFo> failure due to LP being down
<bjf> JFo, that was what i was thinking, thanks for dbl checking
<JFo> no sweat
<bryceh> apw, bjf, JFo, I've just written a script to check if launchpad is up, readonly, in maintenance, unexpectedly down, or about to go down  for scheduled maintenance
<bryceh> http://bazaar.launchpad.net/~arsenal-devel/arsenal/python-launchpadlib-toolkit/view/head:/scripts/launchpad-service-status
<bryceh> I'm going to cron that to poll launchpad to see if it's up or not or expected down soon, and avoid running other cronjobs
<gaurav_pawaskar> Hi All, This is Gaurav. I am new to Ubuntu development. I want to contribute to Ubuntu kernel. Can anyone mentor me through initial stages?
<apw> bryceh, that is most excellent
<smb> apw, Morning
<apw> morning
<RAOF> Heidi ho, apw.
<smb> RAOF, He is called Andy not Heide. :)
<RAOF> :)
<apw> heheh
<apw> evening RAOF 
<apw> hi-de-ho right ?
<RAOF> Tragically unhip squares might right that as hi-de-ho, yes :)
<apw> ahh i am that indeed
<apw> RAOF, pushed a nice shiney new kernel in last night, more drm updates of course
<RAOF> I wonder how many eDP systems *that* breaks :)
<apw> oh all of them :)
<RAOF> ANd when e6510 systems will reliably work :)
<apw> RAOF, do you have any of those E6{4,5}10 systems ?  i have loads of 'critical' bugs on that and no responces to testing request
<RAOF> apw: I don't, but I know that we've got at least one e6410 at Lexington, and I think there's an e6510 somewhere around, too.
<apw> RAOF, i believe its them fileing the bugs, but they don't read them ... sigh
<apw> i am tempted to downgrade any critical bug to wish list after 7 days of ignoring my requests
<RAOF> :(
<smb> apw, http://www.hdmi.org/manufacturer/hdmi_1_4/hec.aspx
<diwic> apw, I'm trying to trace bug #708521. It's present as SHA 19593875 in ubuntu-natty.git, and so I assume it should be in the latest Natty upload, but the bug was not updated.
<ubot2> Launchpad bug 708521 in linux "Microphone not working on Lenovo Edge 13" [Undecided,In progress] https://launchpad.net/bugs/708521
<apw> diwic, trying to trace the fix for that bug yes ?
<diwic> apw, yes
<apw> AHH it came down from upstream
<diwic> apw, when you update from say 2.6.38-rc3 to 2.6.38-rc4, do you care about the buglinks between those?
<apw> on the development branch that doesn't work right ... hrm ... let me fiddle and see if can detect those and fix them automatically
<apw> i should care about them, but i suspect the way the tooling works its missing them
<apw> i should be taking account and am not.  will look at how to add that to my proceedures and will write something to close them out
<apw> so please leave that one as an exmaple
<diwic> apw, exmaple it is sir!
<apw> diwic, thanks for pointing it out
<diwic> apw, can I assume that since "git log" shows 2.6.38-3.30 as the latest commit, and that one is released per https://launchpad.net/ubuntu/+source/linux , that bug is actually Fix Released? 
<apw> yes it should be, i can see i am missing a lot of bugs, in this process and it is trivial to detect
<apw>     - LP: #701271
<apw>     - LP: #708521
<apw> those for the -rc3 to -rc4 update
<apw> i'll get something together to sort these out
<diwic> apw, thanks
<apw> its so obvious that this could occur, and its a one liner to get the information in the right format to add to the changelog which would have done them automatically ... sigh
<Guest80998> can anyone tell me from where can i learn kernel programming???
<apw> that is a very wide area, if you have good C skills and some assembly skills you should not find it hard
<apw> there are books about the kernel to give you overviews, but they are mostly out of date
<apw> i learned by doing
<Guest80998> apw: yes i do know C..and assembly i know very few commands...
<apw> then i'd recommend looking for a book about the kernel, and then pick a small area, something which interests you, and try and read and understand that bit of the kerenel
<apw> and work from there
<diwic> Guest80998, have you looked at http://kernelnewbies.org/ ?
<diwic> there's some resources as well
<diwic> s/'s/are
<apw> diwic, good point indeed, a handy leaping off point, and hints as to where to find like minded people
<diwic> apw, never tried that route myself though, more "here, fix this! ... Uhm, ok"
<diwic> ;-)
<Guest80998> apw: ok..basically i want to learn about networking and scheduling issues in kernel programming
<apw> diwic, me too, i started before it existed too ... but the "this i bust figure it out approach" worked well for me
<Guest80998> diwic: yes i am going through that link..thanks...:)
<Guest80998> diwic: i wanted to learn about kernel networking and scheduling..
<diwic> Guest80998, when you have learned scheduling, please teach me :-)
<Guest80998> diwic: sure..i will...:)
<diwic> apw, seems you succeeded, got fix-released emails already
<apw> diwic, manual based on the automated list, but yes done now
<diwic> apw, maybe I'm the first one sending buglinks to upstreams to a larger extent
<diwic> upstream linux i e
<apw> diwic, i found a fair number of my own as well ... just an oversite in thinking on how the link detector works
<apw> JFo, pushed a couple more changes to lp:~apw/canonical-qa-tracking/cleanup
<apw> JFo, one keeps closed bugs for 20 days before expiring them
<apw> JFo, second marks new and stale entries in the tables
<apw> example of the output is here: http://people.canonical.com/~apw/XXX.html
<apw> smb, i wonder if Fix Committed bugs are really in the same category as incomplete bugs 'pending' or something
<smb> apw, Hm, would think not really.
<smb> Though pending and fix commited could be. Do we have pending?
<apw> well what i am saying is Incomplete and Fix Committed are both the same in the sense they both mean we are waiting on someone else and not much is needed done with them
<smb> Hm well. Both are waiting states true. Though one has less work pending while incomplete is sort of not deterministic on its further way
<apw> smb, yeah i was wondering if Fix Committed should wander down to the bottom somewhere as they are really 'done' as far as most of us are concerned
<smb> Yes, that would feel better at least to me
<apw> so then the question is to move them to 'Closed' which they arn't ... or down with the Incomplete ones; calling that section 'Pending' or 'Waiting on someone else' or somethign like that
<smb> Personally I'd put them together with the closed ones and maybe call it "completed" or so
<apw> ok sounds like something we need to discuss wider and get a decision on
<apw> what do you think of the *NEW* markers etc, and of having some of the old ones on there, as in the XXX page above
<smb> Think it is a good idea. Maybe they could be colourized (eg. be red), that would at least help me to catch attention...
<apw> smb, i am sure they can, hmmm
<apw> smb, you know we could actually colorise the bug number with this information intead
<apw> or add the 'marker' in that column anyhow, as they are links changing the colour is prolly hard
<apw> oh but the background is changable
<smb> Yeah, I guess background would work. And surely it does not need to be in the tags section. 
<smb> At least for me color is quicker to catch than looking at the tags
<tgardner> apw, did you catch my note yesterday that 2.6.38-3.30 withstood stress for an hour on my hoover?
<apw> tgardner, yeah did, used that as the last bit of ack and uploaded it
<apw> and thanks for that
<tgardner> guess I ought to move those platforms out to the shop and turn 'em on full time.
<apw> could be
<tgardner> apw, I need to figure out a PXE boot setup so's we can test different kernels.
<apw> yeah that'd be nice, thoguh without remote console we are constrained
<tgardner> apw, well, I can pipe 'em both through serial
<apw> smb, how about that ... if the marks are in the tags field
<smb> apw, The new works for me. The stale comes in a color that is harder to catch for me
<apw> any ideas of better colours?
<smb> apw, Depends a bit. Bright yellow for a background would be ok. For text red would be better contrast on white but I guess you wanted to avoid red for stale
<apw> yeah, let me try colouring the background on the left
<apw> smb, what about that ... red == new, yellow == stale
<apw> (in the bug column)
<apw> i think i should use the green actually for that
<smb> Hmmm
 * smb sees less than before
<apw> yes its only 20 bugs, to get output faster
<smb> ah ok
 * apw regens with new colours
<smb> Is it just my monitor or is this yellow quite lame
<apw> its limp
<apw> sconklin, hey what do you think to this new colorisation of the bug number, green for fresh bugs (< week old) and yellow for stale bugs (no activity for >14 days)
<apw> http://people.canonical.com/~apw/XXX.html
<apw> smb, sconklin, thats the full page updated
<sconklin> yes, it's nice having an indication of whether bugs are old and incomplete vs new and incomplete
<smb> Indeed. The only issue is that this wimpy yellow won't draw my attention. But maybe id does not need to. :)
<apw> we can argue about colour, i used that more to be consistent with tone in the rest of the page, not cause i care about the specific ones
<smb> apw, Sure. And I am not the best person to decide on color. I'd be a bit extreme. :)
<apw> heh :)  indeed
<herton> I think it could have a improvement, move bugs with status 'Fix commited' to a new section, what do you think?
<apw> herton, yeah we have been wondering about merging them into a renamed section with the incomplete ones, or right out with the fixed ones
<sconklin> https://wiki.ubuntu.com/NattyReleaseInterlock
<herton> apw, ah right I seen discussion above now, well I agree, yeah they fall on incomplete case too, pending/waiting for feedback, but I personally prefer fix commmited be in a separated section as it's is pending work from our side not user/reporter, but any way should be fine
<janimo> apw, hello, as mentioned briefly at the rally, bug 715113
<ubot2> Launchpad bug 715113 in linux "Drop versatile support" [Undecided,New] https://launchpad.net/bugs/715113
<apw> janimo, do we have the new qemu packages already ?
<janimo> apw, yes, called qemu-linaro
<apw> janimo, where are those going to be made available?  will there be backports to lucid etc ?
<janimo> apw, AFAIK Linaro will have PPAs
<janimo> apw, is dropping only worth it if done across all supported series?
<persia> Could we not drop the support for older releases?  There's too much transition pain for users.  For natty, everyone ought be happy.
<apw> lucid is a consideration because of its LTS status
<JFo> apw, here now. Apparently the power flickered last night and the backup battery for my alarm is dead. :-/
<JFo> pulled the changes and looking at them now
<persia> apw, https://wiki.ubuntu.com/LucidLynx/ReleaseManifest doesn't have any ARM products listed as LTS, if that makes any difference.
<persia> Nor any versatile products, for that matter :)
<apw> persia, no i was most thinking of people using older releases as build infrastructure which is where this kind of thing is used
<apw> janimo, thanks for the heads up, i'll start some discussion with the main consumers of that flavour and see what they care about
<persia> To make sure we're not already in agreement: I'd like to keep versatile for lucid so that folks running lucid qemu/versatile don't need to change anything.
<apw> we'd not change somethign like that on lucid after release
<apw> this is for natty
<persia> Ah, OK.  I'm all in favour of dropping for natty and future :)
<janimo> apw, PPA from Linaro https://launchpad.net/~linaro-maintainers/+archive/tools/
<janimo> apw, so both lucid and maverick are there
<janimo> apw, right, I only meant natty .As far as the ARM team is concerned we don't care about versatile in this cycle and I understood dropping it helps with build time
<apw> janimo, ok just talking with our arm folks and they are going to think about it, do some testing and update the bug
<janimo> apw, thanks
<janimo> apw, out of curiosity is it a public channel this talking to arm folks going on? 
<apw> janimo, oh yeah, over on #ubuntu-arm
<apw> nothing behind the curtain :)
 * janimo slaps forehead and looks at backscroll in #ubuntu-arm
 * janimo is one of our arm folks :)
<persia> But as with all things, it's best to ensure least surprise.
<janimo> persia, true but I'd thought I file this sooner than later, to give time to process the bug and save a few hours on as many kernel builds as possible
<persia> Indeed.  Filing bugs is good.  Should be done early and often :)
<sforshee> mjg59, I haven't seen this patch appear in any public trees yet, did it get forgotten?
<sforshee> http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg01088.html
<mjg59> sforshee: Ah, sorry. I'll grab that
<sforshee> mjg59, np, thanks
<tgardner> bjf, I found a machine that looks like it supports dapper. its so old that it won't detect a USB keyboard at boot.
<bjf> tgardner, heh
<cking> is it steam powered?
<bjf> cking, http://www.flickr.com/photos/jwhilde/sets/72157618502033063/
<tgardner> cking, AMD athlon single core
<bjf> tgardner, cking, yes it is steam powered: http://www.flickr.com/photos/jwhilde/3551780793/in/set-72157618502033063/
<cking> LOL
<tgardner> someone has _way_ too much time on their hands
 * smb just discovered an amd slot-a board in his cupboard of ancient technology that even has an isa slot...
 * amitk just threw out a creative labs isa soundblaster while making space for HW a few weeks ago, scary how big it was...
<smb> Indeed, did not even remember how large the isa slot was. :)
<apw> heh ... hardware reminicing
<apw> i have have voodoo-1 card somewhere
<apw> JFo, about ?
<JFo> apw, yep
<apw> chat time ?
<JFo> sure, one sec...
<apw> JFo, balcony me when you get there
<JFo> ok
<JFo> my desktop just froze
<apw> heh
<apw> good old natty
<JFo> yup
<JFo> huh, and then rebooted
<apw> la la la can't hear you ... literally
<JFo> heh
<amitk> JFo: my desktop freezes and bring me back to the gdm prompt about 3 times a day, its fun.
<JFo> amitk, I feel for you. I hope this doesn't start a trend for me :-/
<apw> kees, about ?   wondering if you could test your bug #712075 ...
<ubot2> Launchpad bug 712075 in linux "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid" [High,Incomplete] https://launchpad.net/bugs/712075
<apw> kees, if i get some testing i can then ack the upstream patch too :)
<JFo> apw, ready to try again?
<JFo> I think I have it fixed now
<sconklin> http://freegeographytools.com/2011/how-the-fcc-plans-to-destroy-gps-a-simple-explanation
<apw> hey bryceh when you did lp type things did you ever work out how to find out if a bug is Incomplete with response etc ?
<bryceh> apw, I didn't look at that bit of code directly, but what I think it does is compare the date that the bug went Incomplete with the date of the last comment
<apw> bryceh, any idea how i'd find the first date ?
<bryceh> apw, yeah there's several dates exposed in the api, let's see
<bryceh> (browsing through https://launchpad.net/+apidoc/devel.html)
<bryceh> ok, looking at https://launchpad.net/+apidoc/devel.html#bug_task there is date_created which is the first date when it was created, and date_incomplete when it was marked incomplete
<bryceh> you can get a list of all the comments from the bug object (for comment in my_bug_task.bug.messages:)
 * apw looks
<bryceh> then each comment has a date...  comment.date_created
<apw> well there is a date_last_message which is the other half, so i am good there
<apw> i don't have a date_incomplete on the lpltk interface
<bjf> apw, the lpltk can get you a python collection of the comments and each one has a date_created property
<apw> bjf i think i have that date already on the bug, which has a date_last_message
<bjf> apw, yes
<apw> and i've just added a date_incomplete to the lpltk task and that seems to work
<apw> and i think the delta of those two is what bryceh was saying the search uses to compare ...
<apw> who maintains lpltk ??
<bjf> apw, bryce and i do for the most part
<apw> ahh ok ... then i'll let you know if this works :)
<kees> apw: I'll give it a shot; .38 was oopsing left and right for me earlier.
<apw> bjf, ok that matches what launchpad says ... thanks bryceh ... 
<bryceh> apw, sure
<apw> i will get you a merge request up shortly with the new lpltk accessor we need, but otherwise its easy :)
<bryceh> awesome :-)
<apw> as it seems to expose all of the dates for each state, it is entirly possible we could work out the previous state from that
<apw> and put it back :)
<bryceh> :-)
<bryceh> apw, that's a functionality I've wanted to have myself...  auto-reset back to Incomplete without response, when the person(s) commenting aren't relevant people
<bryceh> if that's what you're aiming for implementing, I say yay!
<apw> heh not, but i would also love that
<bryceh> troublingly, I just noticed I'm on .38-1, need to reboot to .38-2.  brb
<apw> hmmm, not good
<cking> check this out: http://www.ubuntu.com/certification/catalog
 * tgardner --> lunch
<apw> bryceh, ok the branch is here: https://code.launchpad.net/~apw/arsenal/python-launchpadlib-toolkit-task_date_accessors/+merge/49272
<apw> (well the merge for it)
<bryceh> apw, got it, looking now
<apw> bryceh, if you are preferring to be more minimal, i only _need_ date_incomplete
<apw> and i can respin it with just that if you prefer
<bryceh> yep, looks good
<bryceh> nah this is fine
<apw> http://people.canonical.com/~apw/XXX.html <-- JFo that now has incomplete with in the open section and without in the incomplete section
<JFo> nice :)
<apw> bryceh, i expect i'll be using the other ones pretty soon :)
<JFo> so only 6 incomplete waiting for us
<JFo> cool
<bryceh> something's effed up with the diff though - https://code.launchpad.net/~apw/arsenal/python-launchpadlib-toolkit-task_date_accessors/+merge/49272/+preview-diff/+files/preview.diff
<bryceh> but no biggie, I'll just use the commit diff
<apw> JFo, you'll need to update your lpltk once bryce has sucked up my fixes ... then you'll want the changes from: https://code.launchpad.net/~apw/canonical-qa-tracking/cleanup
<JFo> ok
<JFo> will fix
<apw> we need a new date accessor from lpltk to find out if there is a comment since incomplete
<JFo> ugh, I made too much for lunch
<bryceh> fixes sucked up
<JFo> k
 * apw suggests a fridge portion and a you portion
<bryceh> apw is being quite helpful this morning!
<apw> heh ... don't get used to it :)
<bryceh> solving all sorts of problems :-)
<bryceh> hang on I got a sheaf of bug reports...
<bryceh> ;-)
<JFo> k, pulled new lplib-tk
<JFo> grabbing cleanup
<JFo> k, changes pushed
<JFo> going to fixup cranberry
<apw> JFo, its likely running right now
<apw> JFo, we need to stop the 'upstream tersting and latest devel testing' for bugs with 'kernel-tracking-bug' and 'kernel-cve-tracker' its just noise
<JFo> yep
<JFo> it should be stopped
<JFo> I added those tags to the -new script
<JFo> and I have added that to the flow diagram
<JFo> so it shouldn't be an issue anymore
<apw> ok cool
<JFo> but your mileage may vary :P
<apw> get that on your status report :)
<JFo> heh, ok
<apw> JFo, once we have gone through all of the regression-proposed bugs and dispositioned them, we need to go through all the Undecided ones and set a priority ...
<JFo> ok
 * JFo adds to the TODO
<apw> bjf, sconklin, do we have a standard prio for all of your tracking bugs?  wishlist or a real prio ?
<bjf> apw, i've not been putting a prio on any of them
<sconklin> prio shouldn't matter - they are simply process trackers
<bjf> apw, at least not the release tracking ones
<bjf> apw, for the CVEs i've just been putting "low"
<apw> yeah i know, normal triage says 'take all undeicded and give them appropriate prio' which is confusing as there is none
<apw> bjf, for cves i think they should match the prio of the cve
<bjf> apw, probably
<apw> so perhaps trackers are just wishlist or something
<bjf> apw, but i'm fixing them, the are being committed, the bug is really just a tracker as i create the patch so prio doesn't really matter
<apw> bjf, indeed, but how does a nieve triager know that those ones should be ignored
<apw> we are making process which requires a lot of knowledge increasing barrier to entry
<bjf> apw, ah! the mythical "helpful community triager"
<JFo> heh
<apw> well i've spun the list three times and had to ignore yours specifically each time
<apw> JFo, ok the concensus is that 'tracking bugs for stable' should be Medium priority if they don't have priority
<JFo> ok
<apw> for when you do that run through
 * JFo makes a note
<JFo> k, the report has run and is up to date with the changes
<bjf> apw, tracking bugs: i'm marking status to "in progress", importance to "medium" and assigning them to the "Canonical Kernel Team"
<bjf> sconklin, JFo, ^
<JFo> bjf , k
<JFo> makes sense to me
<bdmurray> hallyn: is there a reason bug 689974 is fix committed instead of fix released?
<ubot2> Launchpad bug 689974 in linux "frequent failure to boot with 2.6.37-9-generic #22-Ubuntu" [High,Fix committed] https://launchpad.net/bugs/689974
<bdmurray> oh I think I get it now - you'll set to FR after testing later?
<apw> bdmurray, no i think its probabally lost
<apw> i don't think there is any chance of it moving as the change is clearly already out if he no longer has the problem on 2.6.37-12.26
<apw> bdmurray, i've asked serge to check on it and move it so
<bdmurray> apw: thanks
<bdmurray> apw: a while ago didn't you move all the linux-meta bugs to linux?  I've run across some being filed about linux-meta again and was thinking we could just automate that.
<komputes> Hi JFo, mainline kernel tested on X31, still no battery recognized (see recent attachment) - http://pad.lv/701561
<apw> JFo, is the arsenal linux-meta to linux
<apw> mover no longer running ?
<apw> see bdmurray comment above
<JFo> for some reason I think I see something running as you occasionally
<JFo> do you have one going?
<JFo> I don't run one that I know of
<apw> nope doesn't run as me
<JFo> hmmm
<JFo> I know we have something
<apw> only in the bad old days before i gave it to you
<JFo> ah
<JFo> maybe that is what I am thinking of
<apw> its one of the ones in the main arseel run script as far as i know
<JFo> I will look
<JFo> ok
<apw> this whole thing needs review, as we should be running the main passes at least every day
<JFo> yup
<JFo> that is the end goal I hope to have going soon-ish
<apw> well i am a little confused as some months ago it was reported we were now running them daily, and 'no longer as jfo' but as the kernel-janitor
<apw> so what happened to stop them
<JFo> we were
<JFo> I noticed broken logic in them
<JFo> so I stopped running them
<JFo> hence the items in the blueprint to determine what they are doing and fix them
<JFo> it is just taking forever to get done along with everything else</excuse>
<apw> well i suspect that its starting to show we're not doing those basics
<JFo> yes, it is
<JFo> and it has been for some time
<apw> so perhaps we need to get together and review and restart at least the basic ones like that one
<JFo> we are well behind where we need to be
<JFo> ok
<apw> that cannot be broken as its so trivial
<JFo> I don't think I've ever run that one
<JFo> so that has never been getting run by me
<apw> it was in the 'runall.sh' or whatever it was called
<JFo> hmmm
<apw> so it should have been running
<JFo> I don't see it
<JFo> still looking
<apw> JFo, ok in my copy of arsenal, there is a RUN ... which has as its 4th line 'retarget-new-bugs.py'
<apw> thats the one which does it
<JFo> ah
<JFo> yep, I recall that now
<JFo> can I get a new brain with bigger memory? kthxbai
<JFo> that is even in my crontab and I missed it
<JFo> sigh, now I have the hiccups
<JFo> :-/
<JFo> brb, gotta do something about these
<cking> that's all folks!
 * jjohansen -> lunch
<komputes> herton_: you da man!
<herton_> komputes: ? :)
<komputes> herton_: re:acpi=off
<komputes> good call ;)
<herton_> komputes: ah yes, you reported the bug, or just looking at it?
<komputes> herton_: working with the reporter
<bjf> JFo, for assigning a bug to the team, i see that both "canonical-kernel-team" and "ubuntu-kernel-team" have been used, do we have a preference ?
<tgardner> bjf, ubuntu-kernel-team is public
<JFo> I personally don't have one, I guess it depends on who we want to have getting e-mail on them
<JFo> and tgardner is, of course, right
<JFo> I prefer Canonical-
<JFo> if I were to prefer one
<tgardner> JFo, but that severley restricts the audience
<JFo> true, but that goes back to my 'depends who you want to have mail from it' statement
<JFo> :)
 * JFo splits hairs
<tgardner> JFo, for public bugs it ought to be anyone who's subscribed to the ubuntu-kernel team
<tgardner> if they don't like the email, then they can unsubscribe
<JFo> :)
<bjf> there are 52 active members in u-k-t and 29 in c-k-t
 * tgardner --> outta here
<bladernr_> anyone around who can answer what's probably a simple question about cpuinfo and sysfs?
<hyperair> !ask
<ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<JFo> lol bladernr_ 
<bladernr_> the question is: where does the data in /proc/cpuinfo and /sys/devices/cpu/cpuX come from?  same souce or do they get their data in different ways?
<bladernr_> sorry, was actually trying to phrase and type the question but hyperair beat me to it
<hyperair> bladernr_: use the source, luke ;-)
 * bladernr_ isn't smart enough to understand kernel source
<bladernr_> otherwise I wouldn't have asked :)
<hyperair> heh
<hyperair> nor am i, so i can't answer ;-)
<bladernr_> and sadly, a google search with the phrase /proc/cpuinfo yields a lot of noise
<hyperair> bladernr_: actually, what do you want to know?
<bladernr_> Well, I want to know if the data in cpuinfo and /sys/devices/cpu/cpu* comes from the same place, or if they each get data from the CPU directly using different mechanisms
<hyperair> er sorry, my brain slipped
<bladernr_> Is it worth my time writing code that will pull the data from each location and then compare core and physical package IDs to ensure they map 1:1 (as a test case)
<hyperair> i meant why
<hyperair> no it's not worth your time
<bladernr_> ok... that  makes life easier :)
<hyperair> =p
<hyperair> at the very least, the CPU IDs are fixed
<hyperair> across the kernel
<hyperair> including the process affinity stuff
<bladernr_> ok.  Cool.  
<bladernr_> Thanks
<bladernr_> :)
<hyperair> :)
<hyperair> now then, my left-right hand coordination is suffering, so i think i should head to bed
 * hyperair has to leave for work in 3 hours. how wonderful Â¬_Â¬
<JFo> bladernr_, I think it depends on what you are hoping to accomplish
<JFo> if you are just trying to determine that they are different, then no
<apw> bladernr_, they are basically different expressions of the same data ... /proc being the older
<bladernr_> apw:  ack... heh... this was an example of me mindlessly solving a non-existant problem ;-) then realizing it later
<hallyn> bdmurray: changed the status per apw's comment.  just wasnt sure whether it would come back :)
<bankix> Good morning.
<bankix> I need some help building an own kernel package for ubuntu
<bankix> I need a special patch in the kernel and would like to go the usual way by creating a new kernel package.
<bankix> Therefore I applied the patch, then updated the debian.master/changelog.
<bankix> The main problem is the version string for my package
<bankix> In the changelog, I used "linux (2.6.32-28-ctbankix1)".
<bjf> bankix, yes, that would be a problem
<bankix> With that version string, the version detection will fail and the constant LINUX_VERSION_CODE is empty in include/linux/version.h -- which will stop building the kernel with a compiler error.
<bjf> bankix, you could change the "-ctbankix1" to ".<some build number>~ctbankix1"
<bankix> Ah, tilde instead of dash?
<bjf> bankix, yes
<bankix> ... stupid me...
<bjf> bankix, but it probably wants the build number in there as well (don't know for sure)
<bankix> OK, so I just add "~ctbanix1" to the present version string in the changelog?
<bjf> bankix, for example: "2.6.32-28.86~mine"
<bankix> Thanks, I'll try right away :-)
<bjf> bankix, there is nothing special about the tilde, however period and hyphen *do* have special meaning, that's what you stumbled into
<persia> '~' also has a special meaning.
<bankix> I was using a dash up to now to change the version in other ubuntu packages.
<bankix> Should I generally switch to the tilde?
<persia> '~' sorts *before* nothing, which means that if 2.6.32-28.86 is installed, 2.6.32-28.86~mine will be perceived as a downgrade.
<persia> 2.6.32-28.86mine or 2.6.32-28.86+mine are both probably safer.
<bankix> Hm.
<bankix> So plus? Or no seperator?
<persia> bjf, Is '+' treated specially by the kernel versioning scripts?
<bankix> What should i choose?
<bjf> persia, don't know, i've not looked at them for how versions are treated
<persia> Heh.
<persia> bankix, Keep trying different things until you find something that works :)
<bankix> I could just give the + a try :-)
<bjf> persia, i'd gotten in the habit of using a ~ but didn't know about the *before*
<persia> Yeah, '~' has a special meaning, so that one can do "just before" versioning, which is useful for stuff like backports.
<persia> e.g. 1.2.3-4 is an upgrade from 1.2.3-4~backport, so that users get pushed over ABI transition boundaries, etc.
<persia> Because it was popular for backports, someone added it to some documentation on how to make a new version, but not quite (so you could revise again before release, if you like), targeting developers.
<persia> And that documentation ended up being spread widely, unfortunately.  Some has been fixed to recommend working on 1.2-3+mine rather than 1.2-4~mine for an upgrade from 1.2-3, but lots hasn't, and you likely got caught by one of the old ones (you are very much not alone)
<persia> Err, that should read "for a private upgrade from 1.2-3"
<bankix> OK, another question: I don't want my kernel being replaced by a newer version. Up to now I used apt-pining for this, pining the version and giving it a pin-priority of 1001.
<persia> That's the safest way.
<bankix> But that doesn't work, I'm offered updated kernels anyway.
<bankix> (the kernel just can't be replaced due to a readonly filesystem, so any update will exit with errors)
<bankix> Any idea how to "pin down" my own kernel properly?
<persia> pinning should offer you new kernels, but never install them unless you explicitly install it.  If that isn't working, file a bug against your package manager.
<bankix> Oh, it asks for permission.
<bankix> But I don't want the offer at all.
<bankix> Maybe I should rename tha package?
<persia> That's another option, although it raises different complications.
<bankix> e.g. to "ctbankix-linux-*" and add a "Provides" line to the package file?
<bankix> What complications would I have to face probably if I rename it?
<bankix> or how would you solve this?
<bankix> I'm open for any advices :-)
<bankix> btw: the + seems to solve my versioning problem, thanks a lot!
#ubuntu-kernel 2011-02-11
<persia> I don't know best practices for kernel rename (kernel packaging confuses me), but I believe you'd want to rename your headers, your -meta, etc. to match, as well as all the relationships.  There may be some packaging helper scripts that need adjustment.
<bankix> Uh.
<bankix> That sounds heavy
<bankix> I thought I could get away with a simple "provides: linux-*"
<persia> That's risky, because your meta will depend on the highest version of linux-*, and versioned provides don't work, and so when then next ABI change happens, you'll be offered an upgrade anyway.
<persia> Plus, your headers may not match, which could break building modules.
<bankix> OK, no renaming.
<bankix> But how to avoid updates?
<bankix> setting it to "hold" in the package database?
<persia> won't prevent offers
<bankix> Then I'm helpless.
<bankix> But thanks for your help
<bankix> I think the safest but hardest way would be to rename the package. This would prevent all offers and updates, except I offer an update myself.
<persia> Yes.
<bankix> OK, something to do next week :-)
<bankix> And I'll set up a quad-core tomorrow to get that compile batch done ...
<bankix> Thanks again and good night.
<bryceh> bjf, apw, JFo: new lpltk 0.4.2 uploaded to natty
<bryceh> ugh, my natty desktop is running into some kernel BUG - bug #716811
<ubot2> Launchpad bug 716811 in linux "[SandyBridge] kernel BUG at /build/buildd/linux-2.6.38/fs/nfsd/nfs4state.c:3132!" [Undecided,New] https://launchpad.net/bugs/716811
<bryceh> JFo, ^^ let me know if there's any more info I could gather that would be of help diagnosing it
<jk-> wow, that looks like a bogus BUG_ON
 * jk- fetches newer git tree
<jk-> ah, the bogusness has been fixed
<bryceh> JFo, #713864 may be worth adding to the kernel team's list to track; while it doesn't yet have a patch worth pulling it looks like they're narrowing in on one.
<bryceh> JFo, dang it, I meant bug #711591 there.
<ubot2> Launchpad bug 711591 in nouveau "does not detect resolution correctly(xserver-xorg-video-nouveau causes graphic corruption were you cant do anything)" [Critical,Confirmed] https://launchpad.net/bugs/711591
<al-maisan> Hello, upgraded to the 2.6.38-3.30 kernel this morning and laptop (thinkpad t410) froze twice on resume from suspend (nothing in /var/log/syslog) .. is this a known issue?
<al-maisan> FWIW the 2.6.38-2.29 kernel does not exhibit this problem
<al-maisan> the following upstream kernel change might be the "culprit": drm/i915/lvds: Restore dithering on native modes for gen2/3
<smb> al-maisan, Given that the kernel was uploaded only yesterday there may not be "known" too much. But I don't follow those things not that closely. I could potentially build you a kernel with that one patch removed to test this for sure
<apw> al-maisan, no it is not known
<apw> smb, i don't think that commit is very likely
<al-maisan> smb: ah, I see .. well, if you make such a kernel available I would certainly give it a try.
<apw> it changes a dithering order bit in the GPU ... removing some banding
<apw> al-maisan, why do u pick that one commit as likely ?
<apw> the word restore in that commit is not related to resume from suspend
<al-maisan> apw: I am just guessing .. I had i915 related resume freezes with the maverick kernels .. burnt child syndrome :P
<apw> hmmm 
<apw> al-maisan, can you confirm that this is repeatable, that it is every resume with the new kernel ?
<al-maisan> it occurred twice this morning .. let me reboot into 2.6.38-3.30 and try it one more time
<al-maisan> biab
<al-maisan> apw: ok .. the resume freeze is "reliable" and repeatable .. tried it two more times in a row .. froze both times
<al-maisan> nothing in /var/log/syslog
<al-maisan> resumes with the 2.6.38-2.29 kernel still work fine
<apw> al-maisan, hmmm
<apw> i'd ask you to file a bug, but ... launchpad is in a heap
<al-maisan> ouch ;)
<apw> al-maisan, assume this is an x86 of some sort
<al-maisan> x86_64
<apw> ok i have a 64bit install on the -3.30 kernel which is ok ... hmmm
<apw> al-maisan, what graphics do you have ?
<al-maisan> I have an integrated i915 and a discrete nvidia chip (which I turned off via the bios)
<apw> 831d52b x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm
<apw> al-maisan, you have 64 bit yes?  if i do you a test kernel you available to test it ?
<al-maisan> apw: yes and yes
<apw> almaisan-away, sorry for the delay ... i lost the first build: http://people.canonical.com/~apw/amd64-resume-natty/
<apw> almaisan-away, could you test that and report back please
<apw_> almaisan-away: did you get a chance to test? lost my scrollback
<al-maisan> apw: will do!
<apw> al-maisan, hows it lookin
<al-maisan> apw: I need to finish a piece of work .. will let you know in 20 minutes .. sorry for the delay.
<apw> al-maisan, heh no worries, just impatient like all techies :)
 * al-maisan knows the feeling ;)
<al-maisan> apw: booting into the kernel you prepared now ..
<tgardner> sconklin-gone, why aren't my linux-fsl-imx51 kernels getting pocket copied from the c-k-t PPA ?
<rsajdok> Where is correct link to a git repository contains this patch?
<rsajdok> http://kernel.ubuntu.com/git?p=manjo/ubuntu-maverick.git;a=commitdiff;h=refs/heads/lp712174
<apw> rsajdok, git://kernel.ubuntu.com/manjo/ubuntu-maverick.git i believe
<al-maisan> apw: that kernel behaved the same unfortunately .. freeze on resume .. not a single peep in /var/log/syslog
<apw> al-maisan, well thats perplexing
<al-maisan> yeah
<apw> al-maisan, can you test the v2.6.38-rc4 mainline build please
<apw> if its in mainline then i can start a bisect on it
<al-maisan> apw: where would I find that kernel?
<al-maisan> the mainline one
<apw> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.38-rc4-natty/
<apw> that is in theory the same as the -3 you tested but without the ubuntu sauce
<apw> if that fails (and i would expect it to then we can bisect -rc3 -> -rc4
<jpds> Would anyone happen to know what could be causing bug #709457 ? The dkms.log file isn't really helpful.
<ubot2> Launchpad bug 709457 in oss4 "package oss4-dkms 4.2-build2002-2 failed to install/upgrade: oss4 kernel module failed to build" [Undecided,Confirmed] https://launchpad.net/bugs/709457
<apw> jpds, nothing there to work with is there
<apw> jpds, i think you can run the build by hand with like dkms build (and a few version options)
<apw> and it'll give you the make command it uses
<apw> there may also be a longer log in the output directory somewhere
<apw> jpds, look in /var/lib/dkms for output directories
<jpds> apw: More than http://paste.ubuntu.com/565862/ ?
<apw> jpds yea
<apw> /var/lib/dkms/bcmwl/5.100.82.38+bdcom/2.6.37-12-generic/i686/log/make.log
<apw> as an example i have that in mine for a wireless module, and it has the output of the actual make
<apw> note your output even tells you to looki at that file
<apw> Consult the make.log in the build directory 
<apw> /var/lib/dkms/oss4/4.2-build2002/build/ for more information. 
<apw> even telling you where to find it
<jpds> I looked at /var/lib/dkms/oss4/4.2-build2002/build/main.log, I'll check make.log.
<jpds> apw: Actually, http://paste.ubuntu.com/565870/ is the entire contents of make.log.
<apw> not much use is it
<jpds> Not really.
<apw> jpds which kernel are you using ?
<apw> jpds, can you paste cat /proc/version_signature
<apw> and can you also paste ls -l /lib/modules/2.6.32-28-generic/source/include/linux/limits.h
<jpds> apw: 2.6.32-28-generic
<apw> jpds, and the other two
<rsajdok> apw: After that: git log --grep="Manoj"
<rsajdok> apw: I cannot see this patch: http://kernel.ubuntu.com/git?p=manjo/ubuntu-maverick.git;a=commitdiff;h=refs/heads/lp712174
<apw> jpds, ok i've updated the bug
<apw> jpds, i am suspicious that the file will not exist ...
<jpds> apw: Excellent, thanks.
<apw> jpds, perhaps you could also check they have the headers installed for their kernel
<jpds> apw: I believe that they're also using VirtualBox with DKMS.
<apw> could easily be a bad assumption in this dkms package
<apw> al-maisan, oh could you file a bug with ubuntu-bug linux when running the -3 kernel ... and let me know the bug number
<al-maisan> apw: will do.
<al-maisan> apw: when running the ubuntu variety of the -3 kernel. Right?
<apw> yeah if you could, then it'll put the right version inforamtion on the bug
<al-maisan> no problem, will do.
<rsajdok> apw: any sugestions?
<tgardner> ogra, what is the appropriate list to send ARM kernel upload announcements? ubuntu-mobile has bounced for me.
<ogra> we usually use ubuntu-devel, but i guess -kernel would work as well, given that all people interested in kernel uploads of the arm team are subscribed there
<apw> ogra, ok they are going there anyhow
<tgardner> ogra, works for me
<apw> (kernel-team@)
<ogra> right, i dont think we need separate notification
<apw> rsajdok, looking myself
<apw> rsajdok, worked for me
<apw> either git clone that URL or add it as a new remote in a maverick tree
<apw> then you should have like origin/lp712174 in there which is the same as that patch
<apw> apw@dm$ git show manjo/lp712174
<apw> commit 58835356c5542d623a1110ed40a089e83388f4ab
<apw> Author: Jens Taprogge <jens.taprogge@taprogge.org>
<apw> Date:   Mon Aug 9 23:48:22 2010 -0300
<apw>     thinkpad-acpi: Add KEY_CAMERA (Fn-F6) for Lenovo keyboards
<al-maisan> apw: could not report the bug "ubuntu-bug linux" says "This is not a genuine Ubuntu package" :/
<al-maisan> apw: the mainline kernel exhibits the same behaviour FWIW .. freeze upon resume
<apw> al-maisan, ok thanks, just file a bug against any old runnable kernel then ... sigh
<al-maisan> oh, the command is right because I am running "2.6.38-3-generic #30amd64resume201102111045" right now.
<apw> ahhh damn yes
<al-maisan> I think the original -3 ubuntu kernel has been overwritten
 * al-maisan looks for it
<apw> just use +filebug, and don't worry about apport info
<al-maisan> ok
<apw> its me who will whine at your for no apport info, and i'll tell me not to
<al-maisan> hmmm :)
 * smb grumbles about annoying LP features
<smb> tgardner, could you get my own nomination accepted on https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/717177
<ubot2> Launchpad bug 717177 in linux-ec2 "Import missing stable update changes into Lucid-ec2" [Medium,In progress]
<tgardner> smb, done
<smb> tgardner, ta
<al-maisan> apw: please see bug #717189
<ubot2> Launchpad bug 717189 in linux "thinkpad t410 freezes reproducibly upon resume from suspend" [Undecided,New] https://launchpad.net/bugs/717189
<al-maisan> apw: I managed to make "ubuntu-bug linux" by reinstalling the ubuntu -3 kernel i.e. you should have full info there.
<tgardner> apw, jjohansen: why are we considering disabling filename encryption in Natty if long filename support doesn't land in time? IMHO we're no worse off then we've been for Lucid/Maverick.
<apw> tgardner, i don't think we should be, but people in the peanut gallary were shouting and screaming about how bad it is if you use evolution or something something else
<apw> tgardner, so i take the view that we should review it in the open with the release team.  my recommendation is status quo
<tgardner> apw, frankly, it would be a total regression if we disabled the feature.
<apw> kirkland i think was of the same mind, others differed
<apw> tgardner, it would have to be for new installs only indeed, else my shit would break
<tgardner> absolutely
<apw> so i don't think its trivial, or indeed sensible to regress, but it was reuqested, and that decision is above my head
<apw> kate can figure it out :)
<tgardner> apw, perhaps we could make it an installer option?
<tgardner> I'd be OK with that.
<jdstrand> I think what was discussed was new installs would not have it, but upgrades would not change
<apw> i think to do so we'd need some engineering to mke it optional, jj would know if that exists already
<jdstrand> it is hard to know what is going to fail
<tgardner> apw, FNEK is already optional, its part of the mount command
<apw> tgardner, oh ok thats good intel
<jdstrand> for example, launchpad scripts die and so I have symlinked out of my encrypted home some launchpad dot directories
<apw> jsalisbury, i assume you are a proponent of turning it off
<tgardner> jdstrand, I feel your pain.
<apw> jdstrand, even
<jdstrand> tgardner: it is, but there is no way to adjust it via pam and the tools, aiui
<jdstrand> and once you have it, there is really no easy way to turn back
<apw> so basically it would be a foundations effort to make it optional
<tgardner> jdstrand, no indeed. its a one way street
<apw> jdstrand, i guessi a cp -rp could be used to fix it
<tgardner> apw, yeah, its not really a kernel bug per se
<jdstrand> apw: sure, that is what you need to do. use a pivot copy
<apw> a "make new; cp contents, unmount old, mount new'
<apw> ok ... so if we can fix it, then thats good, but i think someone needs to decide
<jdstrand> but that is a pretty scary operation to automate for people
<apw> what the if we can't fix it in time fall back is
<tgardner> apw, jjohansen already has it working.
<apw> 1) do nothing, 2) disable by default, 3) disable by default and offer migration back
<jsalisbury> apw, :-)  bad tab completion 
<tgardner> at least on xattr enabled file systems
<apw> jsalisbury, sorry i hate tab completion :)
<jdstrand> I was always very, very surprised it was on by default with no pam/tools configurability
<apw> tgardner, the last version i saw still had limitations in the face of long name hard links
<jsalisbury> apw, I'm a proponent for turning off bad tab completion lol
<apw> jdstrand, you'd have to talk to kirkland about the default i recon
<jdstrand> apw: I already did
<apw> and what did he say :)
<apw> pthththth ?
<jdstrand> apw: you do see the current default, no?
<jdstrand> :)
<jdstrand> tbh, I don't think the problems were known at the time the default was set
<tgardner> apw, even with the hard link limitation, we'd better off then we are now
<jdstrand> I mean, the limit was known, but not the affect on the users
<apw> tgardner, though until its upstream we are risking generating incompatible on disk stuff that we have to live with
<apw> so we need to be really sure what he is doing will go upstream with the same on disk format, before we enable it
<tgardner> apw, true enough
<jdstrand> ideally, I would see filename encryption as opt in and configurable via pam. default off in the installer (without an option in the installer). when filename encryption works right, we can default to on in the installer. upgrades don't change
<apw> release meeting ... gah
<jdstrand> s/via pam/via pam and the tools/
<jdstrand> apw: not sure you saw my opinion above wrt ecryptfs ^
<apw> jdstrand, yep see it now ...
<jdstrand> apw: on a totally unrelated note, I noticed this change in the other-n-security-apparmor bp:
<jdstrand> - Work items:
<jdstrand> + Work items for ubuntu-11.04:
<jdstrand> apw: may I ask why you did that?
<jdstrand> (ie, should we be doing something differently?)
<apw> jdstrand, cause the blueprint didn't have a milestone and nor did the items themselves
<apw> so they fall in the none bucket ... which is bad ... 
<apw> you can fix either by setting them in the main blueprint, or as i did therre
<apw> but if you do the former someone can just change that and you loose any idea where they were before
<apw> and all your planning is affected
<jdstrand> ah
<apw> so ... i generallyu move them to the release milestone
<jdstrand> I see it is accepted for natty as the series, but yes, no milestone target
<apw> and hope that the owner will notice and fix :)
<jdstrand> apw: ok, thanks for the info
<apw> those burny charts cause me loads of pain :)
<apw> sorry if i freaked you out 
<jdstrand> apw: our team tries our best to do the right things wrt to those, but since we only commit to essential bps, we don't live and die by the burndowns and we may miss process updates, etc
<jdstrand> apw: please feel free to call me on it if you are messing you up
<jdstrand> hehe
<jdstrand> if we* are messing you up :)
<apw> :)
<apw> JFo, hey ... can you drop the 'kernel-tracking-bug' bugs from the tag search ... they are no use to the stable team so lets drop them
<JFo> on it
 * apw realises he has been talking to you on mumble ... without you being therre
<bjf> JFo, i'm looking at "run-hotlist.sh", it would be nice if there was a comment above each line which indicated who asked for that tag to be tracked and what the tag means
<JFo> apw, heh sorry :-/
<JFo> bjf, apw, do you guys still want the revert and reapply tagged bugs there?
<JFo> or no?
<JFo> bjf, ok
<bjf> sconklin, ^ thoughts ?
<bjf> JFo, there should be very few of them, and i think it would be nice to see, so i guess keep them
<sconklin> thinking
<JFo> k
<sconklin> I think we can leave them, although I don't think we'll do anything automated with them any time soon
<JFo> ok
<bjf> jjohansen, you having problems with the mumble server ?
<jjohansen> bjf: I have been kicked a few times, and sometime it doesn't log in for a while (say 10+ min)
<jjohansen> so yeah
<bjf> jjohansen, same here
<tgardner> must be something between the states and Canonical
<jpds> An ocean?
<bjf> JFo, there appears to be a problem with the script that is generating the report, the timestamp is 17:11 which is roughly 45 minutes ago
<bjf> JFo, i see that a new hostlist was generated
<bjf> s/hostlist/hotlist/
<JFo> bjf, it runs every hour
<bjf> JFo, ah! that explains it, was thinking it was every 15 minutes
<JFo> heh :)
<bjf> jfo, still a problem, in "run-hotlist.sh" you are still cat-ing the SRU_TRACKING_BUGS file into HOTBUGS even though you are not updating SRU_TRACKING_BUGS and the old one still exists
<JFo> ah, forgot that bit
<JFo> fixing now
<JFo> fixed
<bjf> JFo, can you run the scripts by hand so we get a new report ?
<JFo> sure
<bjf> thanks
<JFo> my pleasure :)
<apw> bjf, it takes like 15 mins to run
<bjf> apw, do we want it to run faster or are we ok with it taking that long
<JFo> bjf, it is up now
<bjf> JFo, thanks, that cut 14 off the list
<JFo> np
<JFo> <-food
 * tgardner --> lunch
 * bjf -> lunch
<JFo> smb, you still around?
<apw> bjf, well personally i hate anything that inefficient ... i fyou can think of tricks to speed it up ... then go for it
<bjf> apw, if we're happy running it once an hour and if it takes 15 minutes then there are plenty of other things to work on, i've not really looked at it to see if there is anything obvious
<JFo> I could see about running it every 30 minutes if you think that is better
<bjf> JFo, if the length of time it was taking to run was keeping us from running more frequently or doing more of what we wanted i'd look at it
<bjf> JFo, however, if we're happy with it the way it is (and i'm not saying i'm not) then i have no problem just ignoring it
<JFo> heh, ok
<JFo> I'm good either way
#ubuntu-kernel 2011-02-12
<ogra> apw, did you guys drop linux-headers-2.6.32-410-dove from the archive (my images fail to build not finding that package, if you removed it the meta needs to go too)
<wzj> .........
<ImGangsta> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<ImGangsta> Im invinsible I am on a sexy train with wifi in 6 couches!
<ImGangsta> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<ohsix> any of the fwts people about?
<ImGangsta> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
#ubuntu-kernel 2011-02-13
<hcfd> Hi. I'm trying to solve a problem with a multiport serial card. I had it working under latest Ubuntu 10.10, stock kernel but under 10.04LTS, latest kernel, I cannot get it configured and working properly. I am using kernel parameter 8250.nr_uarts=8 to allow me use of both onboard ports and the 6 on a PCI card. I tried to replicate my 10.10 setserial config under 10.04 and no joy at all. Could this be a kernel issue?
<hallyn> latest 2.6.38-3 kernel seems to not create good ad-hoc networks.  booting 2.6.27-12 works.  Gotta try a few more times to be sure it's the kernel, but so far it seems to be
<hallyn> (that is separate from an apparent inability of the free broadcom brcm80211 driver to do ad-hoc, which is in itself unfortunate - is the b43 driver really meant to be blacklisted or was that my fault in the past?)
<hyperair> probably your fault. it doesn't look like it's blacklisted on my system
<hyperair> and i don't have a broadcom chip
<ohsix> i'll just edit them in place, thankfully it's only a pin for firefox and aptitude so far; and i don't see having more than 8 or so ever
<ohsix> that's it, moving this channel to its own window :D
<kumaanki> hi everyone..
<kumaanki> which package contains the header files linux/init.h ?
<mjg59> The kernel source
<mjg59> Are you trying to build userspace or a kernel module?
<kumaanki> i have downloaded the kernel source and now i was trying to build a single funsoft driver file..
<kumaanki> so how should i build it?
<mjg59> If you want to build it against your current kernel then you need linux-headers
<mjg59> Don't try to build it against unconfigured kernel source unless you're building your own kernel as well
<kumaanki> can i not compile individual modules from kernel source..?
<mjg59> Not in any meaningful way
<ohsix> copying the config for the running kernel and using the same compiler isn't enough? (i've never had it work the few times i tried, never looked into why)
<kumaanki> hmm...ok. i mean say if some of the drivers are updated in upcoming kernels, will i have to re-install the whole kernel( i mean building the whole kernel itself?)
<mjg59> Typically, yes
<mjg59> Unless the driver has been backported to an older kernel
<kumaanki> oh ok.
<ohsix> mjg59: any idea why it doesn't work? need the deps in tree? it says symbols are missing, typically; even if you run depmod and use the same config
<ohsix> is it because patches are missing or something, cuz i tried it out of the apt-get source tree once; didn't use the debian/* stuff to build it though
<kumaanki> mjg59: even after installing the linux headers, the linux/init.h file is not found.
<mjg59> kumaanki: What, precisely, are you trying to do?
<kumaanki> I am inside the kernel source dir ubuntu-maverick/drivers/usb
<kumaanki> i am inside the kernel source directory ubuntu-maverick/drivers/usb
<mjg59> That's not going to work
<kumaanki> why..?
<mjg59> Because the build system doesn't work that way
<kumaanki> but it should be able to build it if the linux headers are present
<mjg59> To a first approximation, you can't build drivers from different kernel versions
<kumaanki> the funsoft.c file does not demand anything else than linux headers from the current kernel
<kumaanki> the source code is for the same kernel version
<mjg59> So why isn't it included already?
<kumaanki> the kernel headers might not be part of standard installation i guess
<ohsix> i think he means the funsoft module
<ohsix> ie. why do you need to build it yourself
<kumaanki> ohsix: yes.
<kumaanki> was trying to learn how the driver code builds and compiles and the code for funsoft seems understandable so thought of compiling it
<ohsix> ah
<ohsix> well it's not straight forward if you don't start with your own kernel already
<mjg59> You can't just gcc a kernel module
<mjg59> You need to use the kernel buildsystem
<mjg59> So, from the top of the kernel source tree, you can do make drivers/usb/serial/funsoft.ko
<mjg59> And that will build the kernel module against the configuration of the source tree
<kumaanki> oh, let me try this then.. )
<mjg59> Which may not match the configuration of the kernel you're running
<mjg59> So you may end up with a module you can't load
<kumaanki> ok. i want to try my hands on kernel code.
<ohsix> you might want to play with qemu and your own kernel tree :D it can run images directly, and it's a virtual machine; less disruptive
<kumaanki> cool. i am able to build the .ko file now. but the insmod on the generated funsoft.ko fails. probably that's because of the mismatch in kernel versions
<mjg59> dmesg will tell you what the failure is
<mjg59> If you want to build against a kernel with a longer version string, then you'll need to do something like make EXTRAVERSION=-2-686 drivers/usb/serial/funsoft.ko
<kumaanki> dmesg does not log any messages pertaining to the error in insmod 
<kumaanki> i checked the output of dmesg
#ubuntu-kernel 2012-02-06
<apw> ikepanhc, is that patch enabling the actual letter P key ?
<apw> *boggle*
 * ppisati is reading the OMAP thread of death on the arm lkml
 * apw pokes ikepanhc
<smb> apw, Thought more it might be the magic ctrl-p or whatever is used by bios engineers instead of hotkey switch screens
<apw> smb, it may be that, but if it is then its much less serious and the description is utter pants
<smb> apw, Somehow I read it in a less-urgent way
<smb> And I don't know why it needs such special urgency then
<ikepanhc> apw: no, its an hotkey for acer laptops
<apw> ikepanhc, a special key with a P on it ?
<smb> Even a special p key
<apw> ikepanhc, as the way the description is read, it is hard to see it meaning anything other than the regular P key is affected
<apw> ikepanhc, what does it look like ?
<ikepanhc> apw: according to the bug reporter, its a definable hotkey. The function on Windows would be to start some acer boatware, and in acer-wmi, there were other scancode registered for P-Key on other acer machine
 * ikepanhc googling the pic
<apw> http://images.anandtech.com/doci/3631/acer-5740g-17-keyboard.jpg
<ikepanhc> apw: yes, the right upper key..
<ikepanhc> http://www.notebookcheck.net/uploads/tx_nbc2/581743-2.jpg
<ikepanhc> the key besides power key
<brendand> man, that's some bad hardware design
<brendand> press the P key
<brendand> which one?
<ikepanhc> apw: smb: I am sending for oneiric SRU, do you suggest we wait for merged into Linus' kernel? I can revise the patch and add CC  stable in the patch
<cking> its one way to P people off
<cking> having > 1 P key
<apw> cking, :)
<apw> ikepanhc, we generally like to at least have a stable upstream sha1 before we commit things if we can, then they arn't likely to change
<ikepanhc> apw: ok, got it
<apw> if there is some reason things are on fire without the patch do let us know of course
<ikepanhc> apw: no, its not, not urgent thing. I sent because I thought its harmless
 * ppisati -> out for lunch
<diwic> apw, does one require special launchpad powers to split things into distribution versions? I'd like to mark bug 857206 as "Incomplete" for Oneiric and "Fix Released" for Precise.
<ubot2`> Launchpad bug 857206 in linux "(Realek alc887-vd) Speaker and headphones get the same dac" [Undecided,Triaged] https://launchpad.net/bugs/857206
<apw> diwic, yes you do, i've approved it for you
<diwic> apw, thanks
<herton> vanhoof, linux-backports-modules-3.0.0 (16.9) is now on -proposed with the iwl fix
 * ogasawara back in 20
<ev> does /var/crash/vmcore being written absolutely mean that the kernel has completely ground to a halt, or are there circumstances from which it can recover and keep going?
<ev> I'm asking in the context of the dialog we want to display when apport sees one of these, whether it should say that the system has crashed previously, or not make that assumption.
<tgardner> apw, arges ^^ Isn't vmcore written after the kexec crash kernel has taken over ?
<apw> tgardner, right, thats after the kernel has been replaced
<tgardner> ev, so yes, I think you can assume things have completely ground to a halt.
<apw> ev, a proper vmcore from 'crash' definatly means the kernel stopped and was replaced
<ev> cheers guys!
<mpt> Hi folks, I'm writing the error message that comes up when Ubuntu restarts after a kernel oops
<mpt> So I have a question or two
<mpt> When there is an oops, do you have to restart the computer manually (by holding down the power button?), or does it restart by itself?
<tgardner> mpt, it depends on the severity of the oops. its really quite random.
<mpt> hmm
<mpt> tgardner, is it possible to tell, from the oops file, whether it did?
<tgardner> holding down the power button is the only sure fire way to restart, but it can be hard on file systems
<mpt> (whether it did restart by itself, I mean)
<tgardner> mpt, I guess you could look in syslog to see if there is a boot message after the oops.
<tgardner> that is, assuming the oops made it to syslog
<tgardner> mpt, very few oops will cause an automatic restart. only the most severe triple faults would do it AFAIK
<tgardner> plus, its a bit arch dependent
<ev> tgardner: could we not force a magic sysrq + r e i s u b?
<ev> given that they're going to hold down the power button anyway
<tgardner> ev, possibly, but what if you're having a boot oops? then you're in a never ending reboot cycle
<ev> (or the rough equivalent)
<ev> well, that's the less likely case.  And I think it's more reasonable to expect those people to hold down the power button than those in the general case
<ev> and you'd hit the grub menu handler in that case
<mpt> I'm not preferring one or the other, this is just to tweak the text
<tgardner> ev, mpt: so what problem are you attempting to solve? I'm not getting the use case.
<ev> since the computer would start and the magic grub bit wouldn't be set
<mpt> tgardner, the problem I'm attempting to solve is explaining what happened. Either it's "Ubuntu has restarted after something bad happened", or it's "You restarted the computer after something really bad happened"
<mpt> that's all at the moment :-)
<tgardner> mpt, ok. I'd leave it at "Ubuntu has restarted after something bad happened"
<tgardner> regardless of _how_ it got restarted
<ev> (apols, I had jumped in and tried to solve the problem of the computer sitting there doing nothing, which is confusing.)
<ev> ceding the floor back :)
<mpt> My next problem is that the error message has no useful advice to give
<mpt> "Ubuntu has restarted after experiencing an internal error. We hope you took this opportunity to get up and stretch your legs."
<mpt> "If the problem happens again, cross your fingers while restarting."
<tgardner> mpt, direct the user to file a bug?
<mpt> tgardner, the project that's prompting this redesign exists partly (though only partly) to save people from having to report bugs
<tgardner> ah, you have my sympathies, and are quickly losing my interest. I live to solve bugs, but if there is no report, then there is no bug.
<ev> eep, no more bugs please
<ev> the UI will file a crash report without further user interaction (after they click continue, that is)
<tgardner> seriously, you've gotta file a bug with pertinent info or we can't do much about it.
<ev> the end goal is to be able to collect the pertinent information without disturbing or confusing the user
<ev> further down the road, this means server side hooks for things to collect on filing a new crash report
<ev> (without dialogs asking the user a bunch of questions)
<ev> for the moment, regular launchpad bug reporting will continue during the development cycle
<mpt> A convenient side effect is that you'll get better coverage of how often which errors are occurring, rather than just the sort of errors that alpha testers report
<ev> but as before that part will be turned off once the release is out the door
<ev> people will still file bug reports
<ev> and we'll have a way to link crash reports to bug reports
<ev> in the cases where you really do want someone to explain step by step what happened
<tgardner> ok. not sure what more I can contribute...
<ev> apologies again, I'm pulling us away from the conversation at hand
<ev> matthew's computer appears to have crashed though
<ev> so it may be a moment before he comes back
<ohsix> a tool to populate perf buildid stuff with -dbgsym files would be sweet
<tgardner> ogasawara, ok if I rebuild gomeisa precise chroots ?
<ogasawara> tgardner: yep
 * tgardner -> lunch
 * tgardner bounces tangerine in 5 minutes for kernel update
 * cking notes that exhaustive testing of the cpu governor across a batch of systems is rather time consuming
<ohsix> is that for the power stuff? hasn't intel already said that the one that goes really fast and stop saves the most power? :D
<cking> ohsix, that's very true, and my data is showing that
<cking> which is a relief
<ohsix> something about an order of magnitude less power at the low/idle states making it not worthwhile to even step through the middle ons
<cking> but which governor is best? conservative or ondemand for a given mix of use cases
<ohsix> well when i can't avoid cpu usage and i don't care how long it is, i set the cpu speed manually; otherwise ondemand
<cking> you win
<cking> :-)
<cking> yep, my data shows you are making the right choice :-)
<cking> we suspected this was true, but it's good to have the data to back this up across a range of machines
<ohsix> there's something about user directed actions causing bursts of cpu usage, and otherwise being idle
<cking> run fast, get work done quickly, then spend as long as you can in deep C states is the win
<ohsix> there's probably a cpu or working set out there that doesn't follow, but you'd probably sooner change the working set to increase your economy
<ohsix> were you able to test a machine with an amd cpu?
<ohsix> kind of curious about the power usage in the different sleep states, eg. how much lower the deeper states are vs. intel
<JanC> cking: what test results are you referring too (I guess maybe I lost that while my ISP reset my connection)?
<cking> JanC, some extra data I'm collecting right as we speak
<JanC> cking: not published yet?
<cking> JanC, not yet, I'm collecting it with a whole bunch of tests now - it should be ready some time over the next week when I get time to fully analyse the data and sanity check it
<JanC> nice, looking forward to it  âº
<cking> I think the current policy may be fine for most use cases, so no big surprises
<ohsix> on my netbook the return-to-idle can take a while, but i don't think anything is more optimal
<ohsix> considering how little power it uses when going full blast ...
<cking> lets face it, if you want a low power machine, move to ARM ;-)
<ohsix> or a lithium polymer battery that takes up most of the innards of the notebook
<ohsix> lipo is magic, but it's a bit dangerous to have it as a user replacable or removable part :[
<cking> any form of chemistry seems like magic to me
 * cking kicks of some longer tests and slips offline for a while
<tgardner> ogasawara, pushed rebase to v3.2.5 which dropped the SAUCE patch for 'PCI: Rework ASPM disable code' as well as the 2 v3.2.4 reverts
<ogasawara> tgardner: awesome, thanks.  was just about to do the same.
 * ogasawara checks that one off the list
<tgardner> ogasawara, guess we can all quit early.
<ogasawara> the weather is way too nice here today, it's getting hard to stay focused
<tgardner> ogasawara, it sucks here. we had our sun this weekend. now its back to wretched.
 * tgardner received a dreamplug today and is off to read about it.
<jono> jsalisbury, hey, pal
<jono> I saw you put together a test kernel at http://people.canonical.com/~jsalisbury/lp911059/
<jono> but I am running x86, do you have an image for x86 that I can test?
<jsalisbury> hey, jono, yes one second.
<jono> thanks jsalisbury
<jsalisbury> jono, hmm, the x86 kernel didn't build.  I'll build it now and post a link in the bug.
<jono> thanks jsalisbury
<jono> so I tested the other kernel you wanted me to test and the bug is not present
<jono> it seems like we may be narrowing down on it
<jsalisbury> jono, cool, thanks.
<jono> br
<jono> bbrb
<jsalisbury> jono, these test kernels will be a bisection to narrow down the commit that introduced the regression.
<GrueMaster> bjf: Can you look into bug 921473 and find out why it stalled?  Also, I didn't see an imx51 kernel (linux-imx51) update during this SRU cycle.  Until IS gets the babbages out of the build pool, we still need to maintain SRU kernel support afaik.
<ubot2> Launchpad bug 921473 in linux-mvl-dove "linux-mvl-dove: 2.6.32-422.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/921473
<GrueMaster> (not that I need the extra work).  :P
<bjf> GrueMaster: it's "stalled" waiting for an archive admin to copy it to -proposed
<GrueMaster> Ah.
<jono> jsalisbury, hey
<jono> any luck getting that kernel to build?
#ubuntu-kernel 2012-02-07
<nidsub> hi there :)
<nidsub> hola, i hope there someone out there who could help me :)
<nidsub> im sorry ,but im really new to irc
<nidsub> should i just post my problem here?
<nidsub> im trying to build linux kernel
<nidsub> here is the error i get,please  point out what did i do wrong
<nidsub> nidsub-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ sudo make ARCH=arm
<nidsub> scripts/kconfig/conf --silentoldconfig Kconfig
<nidsub>   CHK     include/linux/version.h
<nidsub>   UPD     include/linux/version.h
<nidsub>   CHK     include/generated/utsrelease.h
<nidsub>   UPD     include/generated/utsrelease.h
<nidsub>   Generating include/generated/mach-types.h
<nidsub>   CC      kernel/bounds.s
<nidsub> cc1: error: unrecognized command line option â-mlittle-endianâ
<nidsub> cc1: error: unrecognized command line option â-mno-thumb-interworkâ
<nidsub> kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch
<nidsub> kernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch
<nidsub> make[1]: *** [kernel/bounds.s] Error 1
<nidsub> make: *** [prepare0] Error 2
<nidsub> sorry but i dont understand the error
<nidsub> please :(
<nidsub> here the detail on the step i took ..from this webpage
<nidsub> http://wiki.xilinx.com/zynq-linux
<nidsub> please help me guys :(
<nidsub> im stuck here
<RAOF> nidsub: It looks like that's trying to use the armv5 ABI; we don't support that.
<RAOF> What are you actually trying to do?
<nidsub> hi,thanks for replying :)
<nidsub> generally im planning to some embedded linux on xilinx arm cortex 9
<nidsub> now im  trying to prepare the set of toolchain ready
<nidsub> http://wiki.xilinx.com/zynq-linux from this page i would like to build a linux kernel for zynq qemu
<nidsub> im sorry that if my explanation isnt complete,
<RAOF> So, it looks like that kernel build is trying to use an (old) architecture that we don't support.
<nidsub> ohh that why
<RAOF> I think the answer might be that you can't build that kernel on Ubuntu, unless you can find a cross-compiler for armv5.
<nidsub> thank you ,now im really confuis why would xilinx put an old kernel tree in git.xilinx
<nidsub> git.xilinx.com/linux-2.6-xlnx.git
<nidsub> just to be clear the problem here is bcoz of the kernel provide by xilinx right?
<RAOF> That would seem to be the case.
<RAOF> It's not an old kernel tree, it's a different arm architecture.
<RAOF> (There are *lots* of ARM architectures)
<RAOF> It seems to be trying to build an armv5t kernel; we don't support that instruction set, so I don't think our gcc knows how to build that instruction set.
<nidsub> thats true :)
<nidsub> thanks a lot RAOF, i was stuck here for one week..
<nidsub> now it make sense
<nidsub> i followed all the guideline by xilinx but they screwed me,hahah
<nidsub> Thank you very much
<nidsub> :) :) :)
<RAOF> No problem.
<nidsub> have a nice day :)
<apw> GrueMaster, fsl-imx51 is off support, so we are only applying CVEs which are exploitable in the buildd environment, or fixes needed for buildds.  probabally there was nothing applied this cycle on that tree as a result
<apw> bjf, ^^
<ppisati> apw: right
 * ppisati notes is so cold here, that the weather indicator sometimes crashes
<diwic> "yo mama so fat, she won't fit in the message indicator"?
<apw> ppisati, heh ... perhaps -NN is too wide
 * cking acquires a replacement battery for an old Dell 1525 laptop. Not bad price, just hope it arrives and works..
<tgardner> cking, I wonder if AMD processors will show CPU governor results similar to Intel.
<cking> tgardner, hard to tell w/o AMD h/w.  Got any spare?
<tgardner> cking, no desktop kit, just a large server cabinet
<cking> maybe I should ask HWE
<tgardner> hmm, maybe an older sempron. thats likely not worth shipping to the UK (especially since its mine)
<cking> tgardner, no worries, I will see what vanhoof can get me
<tgardner> cking, how about a Lenovo x120e with the duo-core AMD. that would be a good test platform, plus they are cheap
<cking> at ~$465 sounds like an idea  
 * cking suspects Windows is a significant chunk of the price
<tgardner> cking, yeah, I think I remember paying the Windoze tax for mine.
 * smb thinks the Dell 1721 may be amd, too. Ok, it currently has no hd and the keyboard and probably the wireless are toasted...
<cking> smb, sounds like trash can fodder then
<smb> cking, I mainly keep it because it could probably still yield a few spare parts
<cking> like screws?
<smb> Think the ram is ok
<apw> and you think anything will take ram that old?  i think not
<smb> The 1521 I also have like will do :)
<apw> and whihc bits of that are missing?  cna you even make one good machine out of them, doesn't sound like it
<jwi> cking: did you enable rc6 when testing the x220?
<cking> jwi, not for the last batch of tests
<jwi> cking: the increased thermal headroom should allow ondemand/performance (and to a lesser extent conservative) to spend more time in turbo P states
<cking> jwi, ok, good point, however I just wanted to look at the current "out of the box" config for Precise at Alpha 2. I probably can fit in some time to re-test with rc6
<cking> but as things stand, "ondemand" as Intel has stated, is optimal
<tgardner> cking, seems like it would all be relative on the same platform.
<cking> tgardner, yep, one would think so
<diwic> cking, I have an AMD laptop, Dell Inspirion M101z IIRC
<cking> diwic, thanks, but I think we've got one sorted now
<diwic> cking, ok, cool
<jwi> cking: thanks - i figured you would do another round of testing with the final release. now let's hope those turbo states don't turn out to be horribly inefficient... :)
<apw> ogasawara, heads up ... i have a trio of patches for P, which are likely the majority of the solution for a trio of CVEs, these need testing in P so we can confirm they are a complete soln. ... will be pushing 'em if they build :)
<ogasawara> apw: ack
<ogasawara> apw: I'll probably start prepping an upload shortly after you push
<apw> ogasawara, ack, did we get todays stable update already ??
<ogasawara> apw: v3.2.5?  yep, tgardner got it yesterday.
<apw> ogasawara, thats the one, it did seem very odd to have another stable quite so soon.  especially after the previous one not even compiling
<apw> one can rely on the tgardner monster to drop a pile of stable in your lap on a regular basis :)
<Beret> hey guys, I commented on https://bugs.launchpad.net/bugs/926310 and marked it confirmed - I apologize if that wasn't the correct workflow
<ubot2> Launchpad bug 926310 in linux "USB failing" [Undecided,Confirmed]
<tgardner> apw, there was no effective or functional difference. the rebase merely dropped the ASPM SAUCE patch that came down via stable
<Beret> the bot had previously marked it incomplete
<apw> tgardner, well indeed for us yes, but, i was more commenting on the randomness of the stable process these days
<tgardner> apw, yeah, some days there appears to be no rhyme or reason
<tgardner> apw, it also applied to Oneiric (the ASPM thingy)
<tgardner> in the 3.0.y stable update
<apw> yep, i assume we didn't have it there yet, so getting it there will make 4ironiX spuzz
<tgardner> or it could break shit
<apw> no it can't break shit, else stable would never have taken it, their manefesto says so, so net
<apw> ner
 * apw waits for flames to pour out of -proposed
 * tgardner is skeptical
<apw> they are very trustworthy, it says that too
<tgardner> apw, its one of those patches that skirts the grey area between being a bug fix and being a new feature.
<apw> heh, indeed
<tgardner> I'll ask herton and bjf to drop it from Oneiric at the first sign of regression.
<apw> they'll do that anyhow :)
<tgardner> well, drop it with prejudice ?
 * tgardner goes to find packaging for cking's new/old AMD laptop
<cking> much appreciated tgardner
 * amorphous feels like precise is faster than oneiric on his laptop
<cking> subjective or real?
<apw> cking, i had teh exact same reaction the day i upgraded.  i cirtainly felt that chromium was getting to the page quicker
<apw> as to what is improved, or if its real, ... ymmv
<cking> just the facts - no wishy washy feely stuff here
<cking> ;-)
 * apw has none to offer
 * apw feels a new WI for cking
<cking> noooooooooooooooooo
<apw> [cking] figure out if apw has lost his mind, of it precise _is_ faster
 * ogasawara back in 20
<GrueMaster> apw: Thanks for the info (mx51).  I'm just trying to stay on top of everything.
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> GrueMaster, np
<apw> jsalisbury, gah
<jsalisbury> apw, :-)
<apw> ogasawara, ok those are pushed, note the tree as is needs an abi bump, but i am assuming you have one pending anyhoo
<ogasawara> apw: yep, thanks
<tgardner> apw, mumble meeting ?
 * apw takes unity crashing his X server as a sign, and calls it a day
<cking> apw has all the fun
 * tgardner -> lunch
<ogasawara> hrm, that's not good.  precise master-next test build causes boot to fail on i386
 * ogasawara suspects the procfs patches
<apw_> ogasawara: rip em
<ogasawara> apw: ack. will let you know if it succeeds then.
<apw_> cking: oi you off NOW
<cking> heh, yep, will do
<apw_> ck
<apw_> cking: NOW
<cking> indeedy do
 * cking -> EOD
<tgardner> apw: re: HPA. why is the no-partition issue file system specific ? 
<tgardner> I'd think the solution is to leave HPA alone of there is no partition table.
<tgardner> if*
<apw_> to know how big the thing  inside thinks it is, to know if it overlaps
<tgardner> apw_, right now the ata layer enables HPA based on native size v.s readsize. it doesn't really take partition tables into account, does it?
<apw_> we may,be able to cope with most external media in userspace
<tgardner> apw_, what about lvm and device mapper volumes ?
<apw_> it bounds checks the partirion, and if it spans hpa then we diaablw
<apw_> ifs not clear we can ttell
<tgardner> yeah, raid disks likely won't have a partition table
<apw_> me drinks more wine
<psusi> are the config files for the various kernel flavors in the git repo somewhere?  I can't seem to find them
#ubuntu-kernel 2012-02-08
 * smb wonders what a "strut" is...
<Kano> hi apw 
<Kano> apw: would you update aufs when you get simply instructions to do so? already verified with an iso image using aufs3?
<Kano> apw: also ndiswrapper 1.57 compiles with 3.2 kernel, why dont intergrate that?
<ohsix> bleagh
 * ppisati -> reboot
<snadge> who looks after the 3.3 shit? :p
<snadge> kernel.ubuntu.com
<snadge> ooo theres an rc2 now ;)
<snadge> rc1 wasnt booting on an amd zacate system of mine
<snadge> but it does on bulldozer 8150
<apw> 1276852736
<reisei> Hi, all. I'm using ubuntu-oneiric kernel on the ARM device. There is a problem: when I halt the system it have a segfault after unmounting file system... please, advice, how can I fix it?
<tgardner> ppisati, ^^
<ppisati> reisei: kernel version?
<reisei> ppisati: 3.0.13
<ppisati> reisei: i'm checking, hold on
<ppisati> reisei: uname -a
<reisei> ppisati: 
<reisei> Linux omap4430-panda 3.0.13 #0 SMP PREEMPT Wed Jan 25 13:16:31 MSK 2012 armv7l GNU/Linux
<ppisati> reisei: did you build it by yourself?
<reisei> ppisati: yep
<ppisati> reisei: then it's unsupported
<ppisati> reisei: btw, do you have musb enabled?
<reisei> ppisati: :-( Even, you can't suggest what's wrong?
<reisei> ppisati: yes.
<ppisati> reisei: ok, disable it, it causes panic at shutdown
<ppisati> reisei: i swa some fixes for it upstream, but never ehcked if they hit -stable
<reisei> ppisati: thanks! I'll try it.
<reisei> ppisati: yes, it works.
<ppisati> reisei: ok then, either you update to a more recent -stable version of you r kernel
<ppisati> reisei: or you could look for "musb shutdown fixes" on the arm lkml ml
<apw> tgardner, did ogasawara confirm it was the procps patches that were her boot problem do you know ?
<ogasawara> apw: I did
<ogasawara> apw: I yanked em
<tgardner> apw, no, I do not know for sure
<tgardner> ah, nm
<apw> ogasawara, oh heh hi
<apw>  it early there isn't it ?
<reisei> ppisati: ok. Thanks a lot... Can't solve that problem for a week.
<ogasawara> apw: it is, but it's my normal start time anyways
<ogasawara> apw: I try to squeeze in as much time while the nugget is asleep
<ogasawara> apw: I tested on i386.  it would appear to boot properly, but then hang and vomit an oops for a null pointer dereference
<apw> ogasawara, not good.  will have a play with it and try and figure that one out
<ogasawara> apw: I can try booting it again here and get more detailed info
<ogasawara> apw: hrm, except I didn't save the bad build nor the patches.  you have them somewhere so I can re-create?
<apw> ogasawara, i have em, but don't worry i'll play with em
<apw> commit 633b45454503489209b0d9a45f9e3cd1b852c614
<apw> Author: Eric Paris <eparis@redhat.com>
<apw> Date:   Tue Jan 3 14:23:08 2012 -0500
<apw>     audit: only allow tasks to set their loginuid if it is -1
<apw> ogasawara, i'll let you investigate that one, which is a new tunable for systemd systems whcih we may need to be aware of
<ogasawara> apw: ack
<ppisati> ok, configuring /etc/asound.conf to use pulse made audio in flash video work again
<brendand> my flash sound is coming out the internal speaker instead of the usb headset, even though any other sound is coming out the headset
<ppisati> brendand: out of curiosity, what's thje content of /etc/asound.conf for you?
<brendand> ppisati, eh - it doesn't exist? any other place it could be?
<ppisati> cat ~/.asoundrc
<brendand> ppisati, nor that
<ppisati> brendand: than i don't know, i had to do all this crap to make it work
<brendand> ppisati, not sure why i don't have those files
<ppisati> brendand: what i read around is that if you don't get any noise out of flash is beacuse the audio is nit routed through pulse-audio
<ppisati> brendand: in fact, without it, i don't see any flash-stuff in the consumer list of pulseaudio (Sound Settings -> Applications)
<brendand> ppisati, i think i have a different problem. i'll need to find exactly what's going on when i get a chance. probably a reboot will fix it though
 * ppisati -> coffee, brb
 * cking -> pick up kid from school, back in 25 mins or so
<apw> ogasawara, am i correct in thinking you are using master-next in ubuntu-q ?
<tgardner> apw, I created master-next in that repo
<ogasawara> apw: I am
<ogasawara> apw: I need to sync it up again with the latest precise master-next though
<apw> ogasawara, yeah am starting to wonder if i should be building against it
<apw> ogasawara, actually that came up recently, should we be uploading that regularly, like we do the pre-proposed heads ?
<ogasawara> apw: for q?  I don't think it's necessary at this point in time
<ogasawara> apw: for precise master-next maybe
<apw> ogasawara, yeah we cirtainly can add precise to the mix there, if it is helpful.  there is no obvious reason not to
<apw> now that PPAs work
<ogasawara> apw: yah, that seems reasonable.  I think maybe once we hit kernel freeze for precise, then q would be reasonable to start building etc.
 * ogasawara back in 20
<cking> tgardner, is that AMD laptop en-route to me now?
<apw> ogasawara, ok, done, precisise should now be pushed from tommorrow
<tgardner> cking, yep, went out yesterday afternoon
<cking> tgardner, thanks!
<ogasawara> apw: ack, thanks!
<ogasawara> apw: so for this systemd loginuid patch, did you just see this in passing or is there another source which triggered this investigation, ie a LP bug?
<apw> ogasawara, i was looking through the patches against fs/proc to see why the poo i pushed yesterday was exploding on you, and that one jumped out at me
<apw> ogasawara, so no, nothing other than randomly bumping into it, no idea what we even have that set to
<apw> ogasawara, i assume its an 'affecting Q' think now I think about it
<ogasawara> apw: I assume it is something we'd want to toggle on, I'd have to double check Q to make sure we did.
<ogasawara> apw: I'm actually running the Q kernel on my of my machines here
<ogasawara> config.common.ubuntu:460:CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
<apw> ogasawara, actually i have no idea what way it needs to be, upstart (i assume) may be compatible with it being systemds way or not
<apw> ogasawara, so i don't even know it is exposed hrrmmm ... perhaps we should be referring it to jhunt
<ogasawara> apw: from reading the commit message and Kconfig details, it does say that it should be toggled on for systems which use systemd or similar central process services which I would interpret to be upstart
<apw> ogasawara, so probabally we just should tell jhunt about it, and possibly security as it only affects what i think of as a security id for yourself
<ogasawara> apw: yep
<apw> jjohansen, ^ one for your endless todo list ... this option may affect us in Q
<brendand> ok, i definitely have a new bug in precise. no matter what i do audio from the browser always comes out of the external speaker. it's verrrry annoying
<brendand> pacmd list-sink-inputs doesn't list anything when browser audio is playing
<brendand> hmmm. wonder if it's just chrome
<brendand> nope
<brendand> ppisati, does this sound more like what you were seeing?
<cking> ogasawara, https://wiki.ubuntu.com/Kernel/Reference/fwts/s3 and https://wiki.ubuntu.com/Kernel/Reference/fwts/s4
<ogasawara> cking: awesome, thank you!
<cking> and fwts is in universe, so it's all ready to go.
<ogasawara> cking: sweet
<ppisati> brendand: nope, for me it was just flash-audio not working
<brendand> ppisati, sure just flash? i thought it was as well, but noticed while in a g+ hangout that the voice audio was coming through the headset fine (because it's coming from the gtalk plugin) whereas the audio effects in the hangout were coming out of internal
<ppisati> brendand: yep, it was just flash
<ppisati> tgardner: you din't get this one - http://static.1wt.eu/img/articles/guruplug-slow-heater/guruplug.jpg - right?
<smb> jsalisbury_, Maybe that might be interesting de47a4176c532ef5961b8a46a2d541a3517412d3
<tgardner> ppisati, nope. gimme a sec
<tgardner> ppisati, http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx
<ppisati> tgardner: http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx?
<ppisati> ok
<apw> ppisati, which is better :)
<ppisati> well, the one i posted is a fire hazard
<ppisati> http://1wt.eu/articles/guruplug-slow-heater/
<ppisati> that's why i asked for the fan
<tgardner> ppisati, one interesting feature of the dreamplug is that it also has wifi built into it and comes up as an AP by default
<ppisati> tgardner: ah, nice, but for my LAN i opted for this one: http://pcengines.ch/alix2d13.htm
<brendand> raised: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/928980
<ubot2> Launchpad bug 928980 in pulseaudio "Browser generated audio comes out the wrong sink" [Undecided,New]
<tgardner> ppisati, yeah, I've used a lot of PC Engines boards in another life.
<brendand> diwic - any idea why this could be happening?
<brendand> diwic - seems like pulseaudio won't manage the browser audio
<diwic> brendand, yes.
<diwic> brendand, if TheMuso does not fix it tonight I'll fix it tomorrow, since it seems to hit a lot of people
<diwic> brendand, I think the same as pgraner, that it was related to ALSA 1.0.25
<ppisati> diwic: does it apply tp flash stuff too?
<ppisati> ah k, you just answered
<diwic> ppisati, it applies to anything using the alsa-plugin bridge to pulseaudio
<diwic> ppisati, which Flash does. As for other apps, it differs.
<brendand> diwic - i'm guessing it's a duplicated then. do you have a master bug number?
<diwic> brendand, no, just saw it on the mailinglist.
<brendand> diwic, ok. thanks!
<diwic> (and can replicate here, I believe)
<ohsix> cking: i happened to be running inotifywait -m -r / for something last night and noticed ibus opens and reads an svg every time the focus changes, lots of icons are read all the time and .cache/indicator-applet*.log is written to pretty often, if you're still looking for things that wake up the disk there might be something to see
<jjohansen> apw: hrm thanks
<cking> ohsix, can you file a bug and add "Also affects project" to ubuntu-power-consumption - that way it will get some love and attention
<ohsix> hm maybe, i'm on natty though; don't know how easily i can test the latest versions of things, just thought it was worth mentioning as a source of more data to look at
<ohsix> plus the .svg reads even if they're redundant should hit the disk cache, unless you're already under memory pressure then it just makes the situation a tinytinytiny bit worse :p
<cking> ohsix, thanks, lemme put that down on a list of things to eyeball next
<ohsix> before latencytop got a fancy ui it'd pretty readily tell you about file access
<bdmurray> apw: what is the status of bug 882147?
<ubot2> Launchpad bug 882147 in linux "overlayfs does not implement inotify interfaces correctly" [High,Triaged] https://launchpad.net/bugs/882147
<cking> yep, some tools just overstep themselves
<apw> bdmurray, in progress, its not entirly obvious we can fix it at the moment
<apw> bdmurray, i've tried telling userspace that inotify doesn't work on that filesystem and that just makes it puke errors violently
<bdmurray> apw: so inotify might not be available then?
<ohsix> it still says "press F to" check out the file in latencytop (paraphrasing) but it doesn't do anything; they just didn't change the string :P
<apw> bdmurray, i just don't know at the moment, its much harder than i had hoped thats for sure
<apw> i am about to start an upstream converation on what the heck we can do
<bdmurray> apw: okay, I'm really interested in seeing that work
<apw> bdmurray, yep, and its not clear that the current structure lets that work
<apw> o
<apw> ogasawara, ok i've managed to reproduce some kind of panic with the procps changes, though not until i tried to change the options ... it booted just fine for me ...
<apw> though of course it may depend what you have installed on the system in question
<ogasawara> apw: I'd tested with the latest precise and what was on master-next
<apw> ogasawara, yeah, there is definatly somethign screwey, just it didn't reproduce instantly for me, but i am looking at this problem and that may be what you hit
<ogasawara> apw: ack.  let me know if you want me to help test anything.
<apw> ogasawara, so once i've fixed it i'll get you to retest :)
 * ogasawara nods
 * ogasawara back in 10
<apw> ogasawara, ahh this is completley broken, and only luck lets me boot if anyone looks in /proc/mounts
<apw> ogasawara, ok sorted i think, i've now pushed out some replacement patches fixing the issue i think you were seeing
<ogasawara> apw: cool, I'll pull and test
<apw> ogasawara, basically any boot was a random tossup, so your positive testing was just as much luck as mine
<apw> ogasawara, a change of parameters to the show_options superblock options
 * tgardner -> lunch
 * cking -> EOD
 * tgardner relocates
<bjf> bdmurray: you see any recent breakage wi LP api? on Precise, task.date_created seems to be returning 'unicode' object instead of 'datetime' object
<bjf> bdmurray: doesn't have to be LP api. there are several places it could be broken
<bdmurray> bjf: haven't noticed
<bjf> bdmurray: i don't run LP scripts on precise very often so I'd not seen it
<bdmurray> bjf: just tested and yeah it looks like unicode
 * bdmurray cries a little
<ogasawara> apw:  test machine boots fine with the latest set of patches (have done 3 reboots so far, all successful)
<apw> ogasawara, sounds good, it was an obvious flaw when i found it
<ogasawara> apw: how urgently do we need these to go up, do we need an upload today or can I wait till tomorrow/fri?
<apw> ogasawara, no urgency really, we need them so security can test whether they are enough of a fix, but they arn't going to get to that in short order, and if they do, well they can make their own
<apw> ogasawara, just wanted them on their way
<ogasawara> apw: ack
<apw> tgardner-afk, just found a new shortcut in unity launcher (not listed on the help) super-tab, does alt-style round your launchapplication
<apw> bjf, jsalisbury, i note that the meeting summary that got sent out this time is missing the links i put in ... am i doing them in the wrong format ?
<jsalisbury> apw, hmm.  Let me take a look.
<jsalisbury> apw, your format during the meeting is ok.  I must have improperly formatted the moin file.
<apw> jsalisbury, well i'd not sweat about sending out another version or anyting, just see if we can figure out what occurs for next time
<jsalisbury> apw, sure thing.  I'll be sure it's fixed for next meeting.  The script to generate the moin file stripped the links, but I'll fix it.
 * apw calls it a day ... have fun
<scientes> http://paste.ubuntu.com/834410/
<scientes> ^^^^^
<scientes> make-kpkg broken?
<vanhoof> apw: super + ` was a cool find for me :)
<scientes> or does it not work with mainline sources?
<vanhoof> apw: same w/ apt + `
<vanhoof> er alt
<scientes> this is holding up my work, can someone look at how make-kpkg is not working?
<scientes> hmm, this time it seemed to work, i guess nvm
<apw> vanhoof, what does super+` do for you, doesn't seem to be a key binding here ?
#ubuntu-kernel 2012-02-09
<vanhoof> apw: press and hold it
<vanhoof> apw: brings up the how to menu
<vanhoof> apw: http://ubuntuone.com/295An59g2Db88LurQlMtEb
<RAOF> vanhoof: You sure you don't mean just hold <super>?
<vanhoof> RAOF: well ill be damn'd
<vanhoof> RAOF: lol
 * vanhoof walks away innocently
<vanhoof> guess i've just never held it that long
<vanhoof> total press and hold operation
<jono> jsalisbury, any more luck with a kernel I can test?
<jsalisbury> jono, not test kernel as of yet.  The commits that the bisect is reporting to run have a bug in them that cause the pae kernel build to fail.  I'll let you know as soon as I get it figured out.  It should be sometime tomorrow at the latest.
<jono> jsalisbury, no worries
<jono> do you think you have the problem nailed down with what is causing the bug I reported?
<jsalisbury> jono, thanks for being patient :-)
<jono> thanks for helping jsalisbury
<jsalisbury> jono, not yet, that is the primary purpose of the bisect, to figure out the offending commit.
<jono> gotcha
<jsalisbury> jono, too bad someone else isn't hitting this bug that is running amd64.  That kernel builds just fine.
<jono> ahhh bummer
<jsalisbury> jono, I'll take a good look at the changelog and code that is causing the build failure.  I'll make it my priority in the morning ;-)
<jono> thanks jsalisbury!
<jsalisbury> jono, np, should have something for you shortly.
<jono> :-)
<poolie> hello all
<poolie> i think i identified the fix for bug 745112 
<ubot2> Launchpad bug 745112 in xserver-xorg-video-intel "[arrandale] desktop is messed up with external monitors (x86_64)" [Medium,Confirmed] https://launchpad.net/bugs/745112
<lifeless> poolie: run windows ? :P
<lifeless> (boom tish)
<poolie> i was wondering what to do to get a SRU starting
<poolie> perhaps just commenting on the bug is enough
<poolie> lifeless, ironically from stuff on the web lots of windows drivers have similar problems
<poolie> or perhaps are randomly failing for other reasons, who can tell
<poolie> but i bet the odds of an apple laptop driving an apple monitor are pretty good :/
<lifeless> poolie: yeah, I'd say they are
<RAOF> I suspect the apple firmware devs are less divorced from the apple hardware devs than for most OEMs.
 * ogasawara yells at launchpad to load faster
<ogasawara> poolie: that bug sounds familiar to me, did I build a test kernel for it?
<ogasawara> poolie: I can take a better look at it in the morning
<poolie> ogasawara, you built a kernel for a similar bug and it also fixes this one
<poolie> but not if you boot in recovery mode, for some reason
<poolie> no huge rush
<Kano64> hi, did you notice that ndiswrapper -ma/-mi is broken for kernel 3.0 to 3.4?
<Kano64> just tested a 3.2.0 kernel with updated ndiswrapper code
<Kano64> but the userspace is broken by definition when you want autoload with alias/install directives
<snadge> whut theres a 3.4 now? :p
<Kano64> in utils/ndiswrapper
<Kano64> if (`uname -r` =~ /(\d+)\.(\d+)\.(\d+)/) {
<Kano64>     if ($2 > 4) {
<Kano64> should be more like
<Kano64> if (($2 > 4) | ($1 > 2)) {
<snadge> lol the finger service has been shut down on kernel.org :P
<snadge> ok its 3.3 rc3
<snadge> im not unlucky enough to have to use ndiswrapper.. thats probably why it hasn't been noticed until now Kano64
<Kano64> the 3.2 kernel does not have got a working ndiswrapper, but you only need to change the makefile in one line to update it to 1.57
<snadge> that blows
<Kano64> well when you replace the rest of course
<Kano64> the makefile is from ubuntu
<snadge> ahh okay so its not upstream yet
<Kano64> well it is upstream
<Kano64> but in the kernel was ubuntu/ndiswrapper
<Kano64> and the makefile there is not from upstream
<Kano64> http://kanotix.acritox.com/files/kernel/kanotix-kernel-acritox.bash
<Kano64> acritox made a nice script to update your kernel 
<Kano64> latest aufs3 + ndiswrapper
<Kano64> please apply it
<Kano64> aufs+ndiswrapper are tested
<Kano64> i dont think it could be more easy for you
<snadge> im not an ubuntu kernel maintainer :/
<snadge> was just rebooting and stuff
 * ppisati -> back in 10
 * cking -> back in ~60
 * reisei back in black --__--
 * ppisati -? goes out for some grocery
<tgardner> apw, before I go hassle the security guys, any idea why apparmor would deny named read access to /sys/devices/system/cpu/online ? Especially when its world read accessible.
<cking> tgardner, this is much like bug 819479 where apparmor was incorrectly stopping reads to /sys/devices/system/cpu/present
<ubot2> Launchpad bug 819479 in firefox "Apparmor denies access to /sys/devices/system/cpu/present" [Low,Fix released] https://launchpad.net/bugs/819479
<tgardner> cking, so this would be a bind9 profile ?
<cking> tgardner, no idea :-(
<cking> see also: https://lists.ubuntu.com/archives/apparmor/2011-September/001537.html - this seems to indicate /sys/.../online should be readable
<smb> tgardner, Would sudo apparmour_status shed some light somewhere
<smb> ?
<tgardner> smb, sudo: apparmour_status: command not found
<smb> tgardner, Forgive my bad spelling
<smb> apparmor_status
<apw> tgardner, there was an issue exposed by overlayfs in apparmour as merged
<apw> tgardner, wherein sometimes it cannot find the pathname, jj has a fix
<tgardner> apw, this is on an installed server. overlayfs shouldn't be in the mix
<tgardner> smb, 3 processes have profiles defined.
<tgardner> 3 processes are in enforce mode.
<tgardner>    /usr/sbin/dhcpd (2188) 
<tgardner>    /usr/sbin/named (2027) 
<tgardner>    /usr/sbin/ntpd (2012)
<apw> tgardner, if you could paste the error as reported by aa in dmesg at the time we should be able to tell if its the same
<apw> tgardner, yeah it can affect any virtual filesystem depending how it makes its names
<tgardner> apw: type=1400 audit(1328792253.861:29): apparmor="DENIED" operation="open" parent=1933 profile="/usr/sbin/named" name="/sys/devices/system/cpu/online" pid=1952 comm="named" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<tgardner> where are profiles stored ?
<apw> tgardner, ok so not the same issue as the name is known
<apw> tgardner, /etc/apparmor.d i think, they are paths converted to filenames in there
<tgardner> yep, just found them
<tgardner> apw, updated the profile and restarted both apparmor and bind9. no errors. rebooting to make sure.
<tgardner> apw, of course it picked this boot to fsck a 3 TB drive.
<apw> heh
<smb> It had to. :-P Is named only now looking at the online cpu map?
<snadge> i think i see that message too
<tgardner> smb, it must be spawning a number of threads based on how many CPUs are online ?
<snadge> type=1400 audit(1328794066.931:27): apparmor="DENIED" operation="open" parent=2792 profile="/usr/lib/telepathy/mission-control-5" name="/sys/devices/system/cpu/online" pid=2796 comm="mission-control" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<smb> tgardner, That would be my guess too. Just wondering whether we just missed that before
<tgardner> ok, it finally booted. no error
<snadge> is that the same thing?
<tgardner> snadge, it is, but a different package
<tgardner> well, I've got the apparmor source, but where in the hell is the profile for bind9 ?
<tgardner> hmm, maybe its deliverd in bind9
<tgardner> ah, bind9 debian/apparmor-profile
<jdstrand> tgardner: it is 929531. this was caused by the new eglibc
<tgardner> jdstrand, wanna patch ?
<tgardner> jdstrand, actually, the bug is against the wrong package
<tgardner> it should be bind9
<jdstrand> tgardner: it should be in the apparmor base abstraction
<jdstrand> tgardner: it is in basically everything. introduced in this glibc commit http://repo.or.cz/w/glibc.git/commitdiff/84e2a551a72c79b020694bb327e33b6d71b09b63
<tgardner> jdstrand, uh, whatever that means. why would a library change expose this ?
<jdstrand> tgardner: because rather than just looking at /proc/stat, it is also looking at /sys/devices/system/cpu/online
<tgardner> ah, I see
<jdstrand> anyhoo, I will have it fixed in a few minutes
<jdstrand> tgardner: did you file a bug already?
<tgardner> so its not just bind9, its everything that uses this library call
<jdstrand> yes
<tgardner> jdstrand, nope, was still working on tracking down root cause
<jdstrand> which so far I have see with evince, gwibber, empathy, telepathy, etc
<jdstrand> and now you mention bind9
<jdstrand> ah, lets add evolution to the list :)
<jdstrand> anyhoo, fixing
<tgardner> jdstrand, cool, thanks for the heads up
<jdstrand> np
<ogasawara> smb: thanks for doing meta
<smb> ogasawara, no problem. it was all well prepared. all I had to do was to pray I still know how to upload. :-P
 * cking considers frying an egg on the CPU of this old AMD laptop
<tgardner> cking, I think the HD gets pretty hot too
<cking> smokin'
<smb> Amazing the thing still survives
<cking> so the "powersave" CPU governor should be renamed to "heatsave" as it keeps the temp down but doesn't actually really save power
<cking> "powersave" aka "don't burn your lap" governor
 * smb is reminded of his limitcpu script for his old tp
<smb> Basically using ondemand but telling it "no 2GHz is not good for your health"
<cking> it depends on where you place the laptop I suppose.
<smb> Oh I was thinking of the laptops health more. Usually do not really usem on my lap anyway
<smb> Especially that one was heavy still. :)
 * ogasawara back in 20
<arges> tgardner, ogasawara : looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/804281 . I see that ogasawara did apply this fix to the maverick backport kernel, wondering if a lucid SRU is even possible? thanks
<ubot2> Launchpad bug 804281 in linux "Ubuntu 10.04 does not detect and install NIC driver for Intel 82579LM" [Undecided,Fix released]
<tgardner> arges, as ogasawara pointed out in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/804281/comments/6, it doesn't seem likely.
<ubot2> Launchpad bug 804281 in linux "Ubuntu 10.04 does not detect and install NIC driver for Intel 82579LM" [Undecided,Fix released]
<ogasawara> arges: indeed not likely for the main Lucid distro kernel.  If you really need it in lucid and an LTS backport kernel won't suffice, you might pursue providing it in linux-backports-modules which is an elective install.
<tgardner> ogasawara, an LBM module won't help for the netboot use case
<arges> ogasawara, yea was just going to say this is on a lucid alternate CD install
<ogasawara> ah, so scratch that
<tgardner> arges, but, they could use the Lucid point release DVD
<ogasawara> oh yah, won't that have the newer kernels?
<arges> tgardner, ack. asking about that now
<tgardner> ogasawara, .3 has maverick, .4 will have the rest up through Oneiric
<manjo> tgardner, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/929636 looks like a regression 
<ubot2> Launchpad bug 929636 in linux "[12.04] BUG: unable to handle kernel NULL pointer dereference at 00000000000000f0" [Undecided,New]
<tgardner> manjo, it would be helpful to know from which version this has regressed
<manjo> tgardner, I did not see it with the last kernel, and I am uptodate on a daily basis
<tgardner> manjo, is it reliably repeatable ?
<manjo> tgardner, yeah I am going to test it again 
<manjo> tgardner, will let you know if I can repeat it 
<tgardner> manjo, the correct answer is "I don't know, I'll try it repeatedly"
<tgardner> manjo, be sure to reboot after every oops
<manjo> yep I have already rebooted 
<manjo> I formatted my usb around 10 times and did not happen... so I am coping large amounts of data to it now and will try to format it .. I create usb install disk around 5-6 times a day so I am bound to hit this if it is repeatable 
<tgardner> manjo, try removing the partition table first.
<manjo> tgardner, does not repeat ... ok will update the bug when I get some where with this 
<tgardner> manjo, I guess its kind of racy.
<manjo> yep that is what I think too 
<manjo> would be nice to be able to recreate that race condition 
<tgardner> manjo, however, its not clear that this is a recent regression. it could have been lurking for several kernel versions.
<manjo> nothing else was connected to my USB ports except for this stick .. and the mouse 
<manjo> on and keyboard
<manjo> I guess while my disk was formatting I was typing on IRC... so my usb keyboard was in use .. I guess I should plug in 2 usb sticks and format them at the same time ... or some test like that 
<manjo> I have to go take care of something else of higher priority .. I will come back to this later 
 * ppisati -> back in 10mins
 * cking kicks off 25 vlc power measurement tests, its kinda annoying hearing the same 1 minute video clip 25 times
<tgardner> cking, earplugs ?
<cking> i've heard it 100+ times already, so I'm now immune to it really
<cking> it's not like when I was working on mpeg2 optimisation where I saw the same videos over and over for ~1 year
 * pbuckley gives cking some mad respect for making the world a better place for us media freaks
<cking> unfortunately that was on proprietary code for set-top-boxes, but hey ho
<pbuckley> ah.. well im sure it made someones life better ;)
<cking> paid the bills
<tgardner> cking, I did a sound driver once where I listened to the same KD Lang clip about a thousand times. She has such a clear voice that it was easy to hear artifacts
<cking> tgardner, yep, now I can't watch any digital TV w/o seeing all the artifacts 
<tgardner> cking, it sucks to be the digital literati :)
<cking> heh
<cking> hrm, Tuxera POSIX truncate tests take forever and a day to complete on ecryptfs 
<tyhicks> cking: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a261a03904849c3df50bd0300efb7fb3f865137d
<tyhicks> cking: It should be coming down the stable pipe
<tyhicks> cking: As of 3.3-rc2, all tuxera tests should pass except for 2 rename tests, I believe
 * tgardner -> lunch
<cking> tyhicks, that is an accomplishment!
<tyhicks> cking: Are you seeing a lot of failures?
<cking> tyhicks, well, I was going to compare Lucid vs Precise vs 3.3-rcX (where X is current) and see if there any really important fixes that should be backported
<tyhicks> Hrm, I don't know what to expect from the Lucid results
<cking> a bit of carnage
<tyhicks> :)
<tyhicks> Feel free to pass the results by me for patch suggestions since I would have either wrote the fixes or committed them
 * tyhicks might be able to remeber that far back
<cking> well, I'd like to do the survey, collate results and compare to results with say ext3/4 as well 
<tyhicks> Makes sense - although I don't think I remember ext3/4 ever failing one of those tests
 * ogasawara lunch
<ohsix> anyone know offhand when CLOCK_MONOTONIC stops and starts before suspend and after resume?
<ohsix> or a more direct question, i guess; is there a flag or something to detect when a suspend has occured? there's a canary thread in rtkit that slips on suspend and demotes all the threads when it's not supposed to
 * tgardner -> EOD
#ubuntu-kernel 2012-02-10
 * smb is now nearly past his first coffee
<apw> smb, already so soon, you will be high as a kite
<smb> apw, Nah, I can stop anytime I want... Really!
 * smb starts cup #2
 * apw looks jelous
<smb> apw, I'd share if you would sit closer...
 * apw puts the kettle on
<apw> bah there is yet another pulse update in my queue ... sigh
<bryce> apw, one week til FF, everyone's hurrying to finish breaking everything
<apw> yeah, great fun this week is going to be
<smb> go with the challenge
<apw> 210M of updates for me today, i guess i misses yesterday on this machine ... thats what a full 1/4 of everything installed
<smb> Must be related to Friday...
<diwic> I'm trying the latest i386 live-cd on my (older) laptop, and I get the error message that it misses the "pae" feature.
<diwic> Is there anything I can do to boot a Live-CD off this one, or is it just not supported anymore?
 * ppisati -> out for lunch
<apw> diwic, i suspect that that image is no good for you
<diwic> apw, so assume I want to install precise on this laptop; which I'm currently IRCing from, btw.
<diwic> apw, how would I do? Could I use the alternate install CD or is that also booting a pae kernel?
<apw> diwic, you know i have no idea.  i would have to refer you to cjwatson on what cds have which kernels ... hmm
<apw> tgardner, hey ... on this hyper-v thing, do you know its the ata_piix driver which is picking them up or was that just an assumption ?
<tgardner> apw, um, I think it was in the email. lemme recheck
<apw> tgardner, thanks, i want to do the right one as i can't test myself
<tgardner> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917135/comments/3
<ubot2> Launchpad bug 917135 in linux "Hyper-V: enable all hv drivers and export them in the initramfs" [Medium,Triaged]
<apw> tgardner, thanks, there it is
 * apw pops to get a sandwich, i am famished
<tgardner> apw, are you using x86_hyper_ms_hyperv.detect(), or is there a better way ?
 * tgardner hates hardy openvz
<apw> tgardner, there is a standard idiom used in xen where you check x86_hyper == &xxx
<smb> xen/hyper/openvz
<smb> ?
<apw> tgardner, see chinstrap:~apw/P
<tgardner> apw, looks about right
<apw> tgardner, the naming is a bit ass, but hey.  will put some kernels up for them to test i guess and see what they say
<tgardner> apw, do you think its upstreamable ?
<apw> well the current situation is that you have to either use blacklisting or link order to determine which gets priority
<apw> which to me is utter pants, so unless it has something like xen
<apw> where you can backchat to the hypervisor and remove the disks from sata
<apw> then i suspect this is the sort of thing one would want
 * smb shudders
<tgardner> apw, how can you blacklist ata_piix when its built-in ?
<apw> so ... they will not like it, but i think its a sensible solution
<apw> tgardner, well indeed, you can't so then you have to use link order
<apw> and build them both in, and as it is staging you arn't going to do that
<apw> but ... even if it was a full driver, that link order or blacklisting is needed
<tgardner> nope, doesn't seem sensible to build in a staging driver
<apw> that cannot be a good situation
<apw> and so i think some way to chose via the command line, with a logical default that works
<apw> regardless of order, regardless of which are builtin is needed
<apw> and this is that at least
<apw> will get them to test it and see
<tgardner> apw, so how are you gonna suggest they load their staging drivers in the initrd ? /etc/modules ?
<apw> tgardner, i think i saw their modules are discoverable, there is some bus they have id's on
<apw> so as long as they are in there they should load
<tgardner> apw, hmm, will we need to get them in udebs ?
<apw> tgardner, i have that on my list too yes, to put them in the initrd and in di in both cases in the same place as the xen modules
<smb> apw, Well, we built those in now, remember? :)
<apw> heh yeah, but the configuration is still there in both cases just in case we ever can take them out again
<smb> yeah, one never knows
<smb> tgardner, Oh btw, about testability of that hardy cve: need to try, but it sounds like it should be possible by trying a mknod
<tgardner> smb, the patch seems like the right thing to do. at the very least, I don't think we can make things any worse then a BUG()
<smb> tgardner, Yes, but you are right. I'll set up a vm and see if we cann get some more proof as well
<smb> And no, BUG seems the worst possible way of a falltrhough
<cking> one wonders how such code exists in the first place really
<tgardner> cking, it seems like forgotten debug code, or was considered a possibility that could never happen (but just to be safe we'll BUG)
<cking> glad automotive firmware isn't like that 
<tgardner> cking, or aeronautics software :)
<cking> perhaps I'll take a boat next time I travel..
 * tgardner works on hardy build breakage
<tgardner> cking, just not one of those cruise ships that sail too close to the reef
<cking> hrm, maybe telecommuting is the only way forward after all
<apw> cking, is rather risk averse today
<cking> apw, kids made me that way
<apw> heh, you should have been more adverse earlier 
<smb> tgardner, Ok, no clue how whether there is a way to exploit or not. I cannot make the stupid thing allow me to do any real mknod on nfs4 and fail that way...
<tgardner> smb, were there any instructions on mitre.org about how to exploit it ?
<smb> tgardner, hell there is not even a single piece of any info there
<tgardner> smb, I'm wondering if this is one of those theoretical exploits. maybe we can just ignore it.
<apw> have you tried looking for the lkml thread on the patch that fixed it ?
<apw> as if it was theoretical it seems odd that they would bother fixing it
<tgardner> apw, I'm wondering if it applies to 2.6.24 at all. the upstream patch is ginormous
<smb> Well I am pretty sure there, they just used an opportunity to change that as well
<tgardner> BenC, hardy openvz was such a bad idea. how did we ever get roped into that ?
<smb> apw, But there is no thread pointed to directly
<smb> apw, Just a rh bugzilla and you know how useful those are
<BenC> tgardner: we were swooned by a sharp tongue 
<BenC> tgardner: does anyone actually use it?
<tgardner> no doubt. where are they now? maintenance is a huge pain in the ass
<smb> apw, But maybe I misread the description. They talk of mknod() as the C function and ordinary files
<smb> apw, So I may need to have something compiled to check
<tgardner> BenC, I'm seriously considering discontinuing openvz maintenance.
<apw> tgardner, was it ever anything other than a port ? 
<tgardner> apw, its always been a community supported flavour, as was xen
<smb> There was a community? or just zul ? ;-P
<apw> tgardner, so perhaps it is time to ask for a volunteer or lose it
<zul> best community ever :)
<tgardner> actually, at the time, there was a fairly rabid bunch of openvz dudes
<apw> yeah, but is there any chance they are still on .24
<tgardner> apw, bjf - I'm gonna float the idea of dropping openvz on ubuntu-devel
<apw> it is a vast heap of crap sitting on the top
<tgardner> apw, either that, or flatten the development tree like we discussed a few months ago and simply not apply some CVEs. I dunno which is better.
<apw> tgardner, i have those patches sitting in my hardy tree.  meant to talk about them at rally and we never got round to it
 * apw will dig them out
<tgardner> apw, I'm just gonna hit this with a big hammer. I don't care how big the damn repo gets
<apw> tgardner, ok
<apw> smb, this squid thing, have you used it in the context of a chroot build ?
<smb> apw, No in the context of cobbler installs first, and now actually as a current replacement for apt-cacher-ng
<apw> but you haven't converted your chroots to use it
<smb> (so for all other things) but not yet used it to feed a schroot setup
<apw> bah i was hoping to not be first runnign down this road
<smb> The problem with the schroots was that the did not work wekk with normal proxy config. I used (maybe only a feature of apt-cacher-ng) the way to have it act as a mirror
<BenC> tgardner: wasn't there a company that was supporting it?
 * smb wonders whether precise-desktop will become installable before the weekend
<tgardner> BenC, too long ago, can't remember
<smb> tgardner, apw Ah, it seems I got a reproducer now
<apw> smb, sounds good
<apw> smb, i think i have found a way to do the configuration in a chroot as well, not using avahi
<apw> smb, not sure if i can use it when buildign or not, but maybe able to frig that using 'http_proxy'
<smb> apw, MAybe, just remember it was not straight forward using the mirror argument to debootstrap as that wanted a real mirror not a proxy
<apw> yeah, i remember using that special form that apt-cacher-ng groked
<apw> smb, i suspect that setting http_proxy will do the trick too though
<apw> will try it next time
<smb> apw, Would be interesting to know
<apw> it is an http proxy after all, if you think about it
<smb> apw, Sure, I just wonder whether debootstrap honours that variable
<smb> at least for the initial setup
<apw> i guess we'll find out shortly
<apw> it would be stupid if it didn't really
<apw> you still have to hand configure it inside of course afterwards
<smb> tgardner, If you succeed in un...
<smb> err correct hardy repo, let me know
<tgardner> smb, yeah, it'll take a bit yet
<apw> tgardner, you gonna turn them back into patch stacks sitting on diffent parts of the directories ?
 * smb remembers something about unpacked additional subdirs
<tgardner> apw, to start with I'm just gonna flatten openvz and implement some checks to make sure patches applied to root sources have also been applied to flattened sources. likely at insertchanges time
<apw> tgardner, ok, we'll maybe want a way to not do so
<apw> i guess we can put a fake commit down of course
<tgardner> apw, right, an exceptions list
<tgardner> it might be a bit of a pain in the ass, but certainly less of one then the way we're doing it right now
<smb> pop
<apw> tgardner, so you gonna like look for patches in pairs, or that each patch if its not in debian, that its got components in 'main' and 'openvz'
<tgardner> apw, dunno, haven't gotten that far yet.
<apw> tgardner, if we did the latter, then we could do the exceptions by simply editing openvz/exceptions and it would pass
<apw> tgardner, would it help if i spin you a 'patch' validate to do that ?
<apw> tgardner, i have a framekwork here which does something similar to categorise patches for the reconcile stuff leann uses
<tgardner> apw, isn't it beer time for you yet?
<apw> tgardner, not for a couple of hours yet
<apw> tgardner, i'll put a prototype together, you can make what you will of it
<apw> tgardner, where are you putting the non-main flat trees in the main tree as it were
 * ogasawara back in 20
<tgardner> apw: debian/binary-custom.d/$*/src
<apw> tgardner, ok in chinstrap:~apw/validate-patch-range is a perl thingy which will look at a list of commits ... those not marked Ignore: yes and which affect outside debian; it checks that each affects files in each of the places mentioned in '@ports'
<apw> tgardner, this fits with the 'one patch for all ports at once' approach
<tgardner> apw, does it accept a range of SHA1s ? it shouldn't check anything before Ubuntu-2.6.24-30.98
<apw> tgardner, it takes a sha1 pair, and uses them to make foo..bar for checking
<apw> tgardner, i envisioned you using it in printchanges ... which has those two at least in precise
<tgardner> apw, ok, I'll get it in a couple. I just got the build working.
<tgardner> the falttened
<tgardner> the flattened build*
<apw> tgardner, sounds good
<apw> i suspect the following added to 'insertchanges:' will do teh trick
<apw>         perl -w -f debian/scripts/misc/validate-patch-range Ubuntu-$(release)-$(prev_revision) $(HEAD)
<apw> it should exit appropriatly
<tgardner> apw, git://kernel.ubuntu.com/rtg/ubuntu-hardy.git custom-binary
<tgardner> bbias, need breakfast
<ogasawara> apw, tgardner: I was planning an upload today, but there's a gcc update coming down the pipe.  So I'll probably wait till monday to load since there's nothing critical.  If there is anything you want included, shove it in the tree.
<apw> ogasawara, yay ...
<tgardner> ogasawara, ack. that'll give us time to finish the azure changes
<apw> apw@dm$ fdr insertchanges
<apw> 7bce357ca6063903b2061d31a78080575abeb9d6: not ported to openvz
<apw> make: *** [insertchanges] Error 1
<apw> tgardner, git://kernel.ubuntu.com/apw/ubuntu-hardy.git custom-binary
<bjf> brendand: still testing 3.0.0-16.28 ?
<brendand> bjf - pretty much done. one problem system
<apw> tgardner, that works pretty well
<bjf> brendand: ack, thanks
<apw> tgardner, though i am going to need more disk space for the working-directory :/
<tgardner> apw, a bit more, yes
<apw> tgardner, is this going to tripple the size of the sourcepackage ?
<apw> tgardner, or do you render it to a patch still for the upload
<tgardner> about, but it got pretty ;arge when it was copied to the build dierctory anyways
<tgardner> large*
<apw> the build is less of a problem than the src package itself as that is 'real'
<tgardner> apw, no, I took the simple approach and flattened it. the source package will get much larger.
<tgardner> but its all compressed
<apw> tgardner, one option would be to exclude the */src directories, and make insertchanges build the diff between the top and the each src and add it as 0000-everything.patch
<apw> but i'll let you see how much bigger they get, as you say they are comprssible
<tgardner> apw, yeah, developing a patch at package time is a possibility
<apw> tgardner, so how big is a src package right now without doing that
<apw> tgardner, as the ones in precise are of the order of 90M already anyhow
<tgardner> apw, dunno yet
<apw> and i think hardy was a lot smaller at base, so we have some space to play with
<tgardner> apw, I'll run a quick package phase to see.
<tgardner> after first getting the orig tarball
<apw> tgardner, i worry that as we have an orig for hardy that what will happen is the diff will become the size of the original tarball as it cannnot share the identicle files
<tgardner> apw, I think the diff will be twice the size of the orig
<apw> tgardner, we won't be popular :/
<tgardner> I'll look at building a patch at package time. I'm still working out build issues.
<apw> tgardner, i guess if you do that you don't need to change the build support then, you can just use the existing, making 0000-patch
<tgardner> apw, 
<tgardner> -rw-rw-r--  1 rtg rtg 4.7M Jan  3 01:06 linux_2.6.24-30.98.diff.gz
<tgardner> -rw-rw-r--  1 rtg rtg 2.9K Jan  3 01:06 linux_2.6.24-30.98.dsc
<tgardner> -rw-rw-r--  1 rtg rtg 121M Feb 10 10:09 linux_2.6.24-31.99.diff.gz
<tgardner> -rw-rw-r--  1 rtg rtg  57M Jan 13  2011 linux_2.6.24.orig.tar.gz
<apw> tgardner, ow
<tgardner> yeah. I'll finish up the build fixes, then look at packaging
<apw> tgardner, well that was my point, if you decide you are making patches
<apw> tgardner, then ... you don't need any build changes, just zap the patches we have
<apw> tgardner, and place the generated one in the same place
<tgardner> apw, how is that any different then what we had before ? you're still working on a patch of a patch. I'd rather generate the final patch at package time.
<tgardner> from the flattened sources
<brendand> bjf, all ready to go
<apw> tgardner, ok so what do you think about adding the hyper-v modules to the virtio-modules udeb
<tgardner> apw, that I'm OK with. I just didn't think we should build 'em in
<apw> yeah, they are not stable enough to be definatly initialised on everyones machine, yack
<tgardner> apw, they are going mainline with 3.3, so maybe we can pull 'em back to 3.2
<vanhoof> bjf: ping
<vanhoof> bjf: usb 3 device has arrived
<vanhoof> bjf: whatever you need done, happy to do
<vanhoof> bjf: I am running Oneiric though, but can do a fresh install of Precise if needed
<tgardner> vanhoof, you could just install the precise kernel. no need to wreck your user space
<bjf> vanhoof, plug it in, don't choose "remove safely", just pull it out
<vanhoof> tgardner: complete test machine, so I dont care to reinstall
<vanhoof> if you'd like "pristine" testing done :)
<bjf> vanhoof: then plug it in and see if the port is "dead"
<vanhoof> bjf: also do you have a preference of native uefi or legacy bios mode?
<bjf> vanhoof: not that i know of
<vanhoof> bjf: ok, let me pxe boot this thing and get precise installed
<cking> vanhoof, perhaps UEFI to start with
<vanhoof> bjf: any conditions around fs on the device?
<bjf> vanhoof: oneiric
<vanhoof> vfat/ext3
<vanhoof> bjf: oh you want this on oneiric?
<bjf> vanhoof: yup
<vanhoof> bjf: would you like me to move back to the -15 abi kernel?
<vanhoof> currently running this -16 build ogasawara put together for me
<vanhoof> for this: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=35970f2894ffe2ecbddfa776995883a96a828fe0
<bjf> vanhoof: any oneiric should do
<bjf> vanhoof: this is to verify an existing, non-fixed bug does indeed exist
<vanhoof> bjf: ok doing so now
<vanhoof> one sec
<vanhoof> plugged it, it automounted
<vanhoof> pulled it out, it dissappered from my screen
<vanhoof> plugged it back into the same port, it automounted
<bjf> huh
<bjf> vanhoof: i'll forward the email to you to make sure you read it the same as I do
<vanhoof> http://ouwish.com/~vanhoof/pickup/bjf/
<vanhoof> -1 is just when I plugged it in and a few other tidbits, -2 is full dmesg
<ogasawara> bjf, vanhoof: I think you had to "eject" or unmount from the command line, then remove the device to trigger it?
<bjf> vanhoof: ogasawara is correct
<vanhoof> bjf: same manufacturer, but diff device
<vanhoof> i bought 
<vanhoof> http://www.amazon.com/Patriot-Memory-Direct-Supersonic-PSF16GXPUSB/dp/B005EWB17A/ref=pd_vtp_e_4
<vanhoof> since it was a lot cheaper than the one linked in the email
<bjf> vanhoof--
<vanhoof> ok
<vanhoof> so you want me to plug it in
<vanhoof> eject /media/foo
<vanhoof> then pull it out, pop it back in and see it it works?
<vanhoof> is that right?
<vanhoof> i just yanked it out w/o ejecting it
<vanhoof> bjf: works for me
<vanhoof> bjf: plug in (it automounts); eject /media/foo; unplug it; plug it back into the same usb 3 port; it automounts; I can write to it just fine
<vanhoof> http://ouwish.com/~vanhoof/pickup/bjf/bjf-3.txt
<vanhoof> dmesg from that test
<cking> didn't fail after a S3 or was that me making things up?
<bjf> vanhoof: thanks, i think that is the right sequence
 * vanhoof wonders if bjf is pulling his leg
<vanhoof> :)
<bjf> vanhoof: would i do that?
<vanhoof> bjf: yes :)
<vanhoof> ogasawara: let me go back to -15
<vanhoof> for fun
<vanhoof> brb
<bjf> vanhoof: you are using the USB3 port right? and the "bios" has USB3 enabled?
<bjf> vanhoof: the dmesg looks like it is
<vanhoof> bjf: yes :)
<vanhoof> the pretty blue one
<vanhoof> and have used the same port each time
<cking> smb, http://www.youtube.com/watch?v=K_BX6GB-b00
<vanhoof> bjf: this might be interesting
<vanhoof> http://ouwish.com/~vanhoof/pickup/bjf/bjf-4.txt
<vanhoof> notice when I eject, the error that spits out
<vanhoof> but its not listed as mounted anymore, and I pulled it out and plugged it back in and its fine
<vanhoof> http://ouwish.com/~vanhoof/pickup/bjf/bjf-5.txt [ full dmesg ]
<bjf> vanhoof: thanks for testing, not sure what to say at this point
<ogasawara> bjf, vanhoof: I think it was mentioned the bug might only triggered for a specific device or system, so you might not have the right combination
<vanhoof> ogasawara: well you know which system I have for sure :)
<vanhoof> ogasawara: on the latest bios as well, and the upgrade kit
<vanhoof> ogasawara: so maybe this isnt that big of a deal if i cant reproduce with a run of the mill usb 3.0 stick from the same manufactorer
<vanhoof> ogasawara: bjf: if they come back w/ anything else lmk
<vanhoof> bjf: ogasawara: if either of you want shell access to it I can set that up too
<bjf> vanhoof: thanks but that won't be necessary
<apw> ogasawara, tgardner, ok i have the fixes for the hyper-v stuff all ready, am wainting on the requstor to test the combination
<apw> ogasawara, i will push the d-i bits shortly so that they definatly make the next upload
<vanhoof> anyone know of any good benchmarks for usb devices?
<vanhoof> i'd like to see exactly what kinda performance increase this thing has to offer
<ohsix> dd? :O
<vanhoof> (and can you even boot from usb3 yet) ... last I checked you couldnt
<ogasawara> apw: ack.  I just pushed one last patch, so you may need to rebase.
<vanhoof> ohsix: I thought there was something the Linaro folks had, flash-bench or something like that
<vanhoof> i cant recall
<ohsix> i just use the benchmark thing in palimpsest
 * smb is now know as done-for-the-week
<apw> ogasawara, ok pushed that piece, waiting now for confirmation of the other bits
<ogasawara> apw: ack
 * apw calls it a day ... will be vague at best from here on out
 * tgardner -> lunch
<hrw> hi people
<hrw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/930340 - how can I help to check it?
<ubot2> Launchpad bug 930340 in linux "WiFi usage makes kernel panic" [Undecided,New]
<vanhoof> ohsix: I have too as well :)
<vanhoof> http://people.canonical.com/~vanhoof/random/sdp-ssd-read-perf.png
 * vanhoof loves that picture
<jsalisbury> hrw, I just posted some comments to bug 930340
<ubot2> Launchpad bug 930340 in linux "WiFi usage makes kernel panic" [Undecided,New] https://launchpad.net/bugs/930340
<hrw> ok
<jsalisbury> hrw, basically a request to test the latest mainline kernel, and to confirm that the latest Oneiric kernel does not have the issue.
<hrw> jsalisbury: the problem is that this bug is not reproductible
<hrw> I was able to work 6h without oops
<jsalisbury> hrw, Hmm, so did it only happen once, or does it happen randomly, but will eventually happen.
<hrw> but also I got 3 oopses during 10 minutes
<hrw> fetching mainline one anyway
<jsalisbury> hrw, great thanks.  It would be good if you could run that kernel for some time and see if the panics still happen.
<hrw> sure
<jsalisbury> bbiab
 * tgardner -> EOD
#ubuntu-kernel 2012-02-11
 * popey tickles cking
<popey> who isnt here, bump
 * popey tickles apm instead
<popey> or apw âº
<popey> I am sat at a LUG meeting with someone who wants to install 12.04 on his Thinkpad X40 laptop. Seems a reasonable thing to want to do.
<popey> Sadly 12.04 now doesn't "do" non-pae CPUs, and his laptop is a Pentium M class device - 1.6GHz, and I can't get past the installer. 
<popey> I have seen https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034399.html this thread, and wondered if 'orphaned' is really the response for him?
<JanC> popey: according to that mail only old Pentium M (400 MHz) should be affected?
<popey> well I'm looking at the boot screen of ubuntu 12.04 i386 ISO and it says unable to boot and cites pae as the reason
<JanC> popey: BIOS setting?
<jwi> bug 930447
<ubot2`> Launchpad bug 930447 in linux "Unable to Install Ubuntu 12.04 on Pentium M x86 Laptop due to PAE kernel" [Medium,Confirmed] https://launchpad.net/bugs/930447
<JanC> I guess I should try precise on our event box hardware one of these days
<JanC> which is mostly IBM thinkpads with Pentium M's...
<mjg59> JanC: 400MHz FSB
<mjg59> JanC: Which includes the 1.6GHz ones in the X40
<JanC> ah, so that mail was not really good at describing what would be affected
<JanC> hm
<popey> hmm
<popey> soooo, should i file a bug that this machine doesn't boot, is it expected to?
<popey> or tell the guy 'tough'
<JanC> we have R51 laptops mostly, I think
<popey> oh, so from what mjg59 says this is expected to fail?
<mjg59> popey: The CPU doesn't support PAE and the kernel in Precise has deliberately be changed to require PAE
<popey> bummer
 * popey reluctantly puts mint on a USB stick
<popey> thanks chaps
<mjg59> It's really unclear why Intel didn't implement PAE on those
<popey> those linked bug reports do kinda give the impression that we're losing non-PAE in 12.10 not 12.04
<popey> specifically the cut/paste from the techboard meeting in december
<mjg59> /Looks/ like precise still builds generic and generic-pae packages
<popey> but the iso has only got pae on it
<popey> may be able to install off mini iso
<popey> or upgrade from 11.10
<mjg59> And git implies that the generic config still disables pae
<mjg59> So sounds like the iso's been built with pae, but the kernel still supports non-pae
<popey> thanks for looking
<JanC> popey: should be possible to make a non-PAE remix too
<JanC> (although maybe not useful immediately at the LUG meeting ;) )
<JanC> seems like there Thinkpad R51 have a non-PAE Pentium M too...  :-/
<JanC> *these*
<apw> popey, we are supporting non-pae on 12.04, but defaulting to -pae on 32bit, including the cds
<apw> popey, but if more cpus than we had been told are affected the cd default may be wrong
<popey> apw: i was kinda surprised a mainstream device like a thinkpad would be 'broken'
<apw> popey, indeed.  you should get a bug filed with teh machine spec, to add to the decision for the cd default
<apw> popey, what is annoying is that if you support pae, then a pae kernel saves power
#ubuntu-kernel 2012-02-12
<aroman> sforshee: ping
<lamont> 01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 8400 GS] (rev a2)
<lamont> I wonder if those are known to not work with the current precise kernel
<lamont> bug 930828 for the sad face
<ubot2`> Launchpad bug 930828 in linux "3.2.0-15-generic fails to boot with Nvidia GT218/GeForce 8400GS" [Undecided,New] https://launchpad.net/bugs/930828
<apw> lamont, i think i have an 8500 which is also showing problems, those however are only graphical, with the display hung, is the machine available on the network (mine is)?
<apw> lamont, also, which is the previous known good kernel in this case
<lamont> apw: updated 930828 - still maybe a bug, but not a kernel bug afaics
<lamont> so I left it open...  if you have a better place to throw it, feel free.  otherwise it's closable
#ubuntu-kernel 2013-02-04
<ppisati> moin
 * apw waves to ppisati
 * smb waves to apw and ppisati 
<apw> moin
 * apw notes that mounting encrypted drives is "not allowed again" and mumble is broke, and until my update completes i cannot reboot for either
<smb> apw is truly in Monday hell
<apw> truly indeed
<apw> though i have tea, so something is ok
<apw> things _seem_ to be working ok
<smb> (famous last words)
<apw> all true
<ppisati> brb
 * henrix -> lunch
<ogra> apw, bug 1113396
<ubot2> Launchpad bug 1113396 in linux-nexus7 (Ubuntu) "syslog spammed with cpu_up/cpu_down messages after upgrade to linux-nexus7 3.1.10-9.24" [Wishlist,New] https://launchpad.net/bugs/1113396
<ogra> not sure if there is an easy way to quieten it
<apw> ogra, i am not sure i would expect to see the kernel turning its own cpus on and off
<ogra> well, i dont think the interactive giovernor is a mainline thing 
<apw> ogra, and which version was this ok in ?
<ogra> none, we only switched to interactive pretty recently
<apw> ogra, as i was runing .24 and it was not saying it, i rebooted to run .25 and it is ...
<apw> ok so this is triggered by a userspace change
<ogra> the governor code itself is noisy, i assume android simply de-routesd the messages into their own log or so
<ogra> right, it is triggered by actually activating the governor
<ogra> (interactive means there is userspace config, we only put that into place recently (it is identical with teh android setup now))
<ogra> see /etc/init.d/ondemand on an up to date nexus7
<apw> ogra, so all of these messages are at standard low levels, so they won't appear on the console
<apw> ogra, but they will be logged to dmesg, and then to syslog indeed
<ogra> yes, but they make dmesg unreadable 
<ogra> and syslog, yeah
<apw> those messages are key messages during boot so one knows that your CPUs have come up right
<ogra> its the dynaminc "core up/down" messages that are noisy
 * ogra  doesnt care about boot ... but about readable logs :)
<apw> you will if it doesn't
<ogra> heh, indeed
<apw> and this has a measurable difference in something which makes it worthwhile
<ogra> definitely 
<ogra> with all other governors i have a constant system load above 1.0
<ogra> its the only way to get the CPU to behave sanely it seems
<apw> other than load, which could well just be a lie
<ogra> battery life definitely is extended (i didnt measure exactly how much yet, but it is noticeable)
<apw> ok i'll have a think about it
<ogra> i marked it as wishlist for a reason though ... its not super high prio
<ogra> (i guess you can filter with grep/sed/whatever if actually needed)
<brendand> henrix, when are you spinning the next -proposed kernels?
<henrix> brendand: a new SRU cycle just started
<henrix> brendand: so, we should have new kernels in -proposed by EOW
<brendand> henrix, so the testing week will be 18th to 22nd?
<henrix> brendand: yes, i believe so
 * infinity eyeballs the oneiric SRU...
<infinity> henrix: I thought we were taking an SRU break? :P
<henrix> infinity: i believe that break is now over :)
<infinity> Huh.  Time flies.
<infinity> Though we're still skipping this one for P/Q, I guess?
<henrix> infinity: we skiped one cycle only, so... a new one starts this week
<infinity> Or just queueing things up in the PPA, but not accepting them.
<infinity> So as to not disrupt 12.04.2
<henrix> infinity: no, i believe we're rolling all the kernels this cycle. we have a bunch of stuff already in master-next branches. time to flush, i believe :)
<henrix> but i may be wrong :/
<henrix> bjf: any thoughts? ^^^
<infinity> Well, precise is frozen until release, so you can roll what you want, but it's not going anywhere.  That's all.
<infinity> (And it releases in 10 days)
<infinity> So, that may be decent timing anyway.  I can do the PPA->proposed copies as soon as the release is out.
<henrix> infinity: makes sense to me. but i'll confirm this with bjf once he's around. he may prefer to skip P again
<infinity>    * ext4: quiet 'unused variables' compile warnings
<infinity>      - LP: #1071314
<infinity>      - CVE-2012-4508
<ubot2> Launchpad bug 1071314 in linux (Ubuntu Hardy) "CVE-2012-4508" [Medium,New] https://launchpad.net/bugs/1071314
<infinity> ^-- How on earth does that warrant a CVE?
<henrix> infinity: where are you seen that?
<infinity> henrix: Your changelog.
<henrix> infinity: right, but in which kernel?
<infinity> Probably just a copy-and-waste oops.
<infinity> henrix: oneiric.
<henrix> infinity: ok, let me check...
<henrix> infinity: ah! so, the prob was that the fix for that CVE required some adjustments (this was commit dee1f973ca341c266229faa5a1a5bb268bed3531)
<infinity> henrix: Stacked commits, fair enough.  Still seems like an odd way to attribute the bug, but I don't really care either. :P
<henrix> infinity: so, the CVE fix contains 2 commits
<henrix> infinity: yeah, i just added that to track the commit. i should probably add a note next time...
 * ogasawara back in 20
<bjf> infinity, unless something happens, I think we are skipping P and Q again this cycle. it means the following cycle is going to have a crapload of commits in those kernels.
<infinity> bjf: That sounds fair to me.
<bjf> hggdh, brendand, vanhoof ^
<brendand> bjf - oh ok. so we're not looking at new P and Q until the beginning of march?
<bjf> brendand, that's what it's looking like
<brendand> bjf - what's the motivation exactly?
<infinity> brendand: Not disrupting the point release.
<bjf> brendand, if you read more of the scrollback you can see the discussion. it's about getting the .2 release out and not allowing P kernels into -proposed until .2 is released
<infinity> bjf: To be fair, we COULD do the cycle as normal and let the kernels into -proposed, and just not promote them until post-release.
<infinity> bjf: I'm open to that option too, since I'm the one who tends to do all the archive side anyway.
<bjf> infinity, not promote them to where until post-release?
<infinity> bjf: To updates/security.
<bjf> infinity, they shouldn't go to updates/security until the following week anyway
<brendand> bjf - ah yeah. i forgot that's delayed until next week
<bjf> infinity, i thought you did all the point release "work up" in -proposed
<infinity> bjf: We'll be switching image builds to -updates only pretty soon now.
<bjf> infinity, when will that switch happen? what is "pretty soon now"?
<infinity> Like, this week, maybe today or tomorrow.
<bjf> bah!
<bjf> henrix, hggdh, vanhoof, brendand I take it all back, we are turning the crank on everything.
<bjf> infinity, if i can get into -proposed by next monday, that's good enough for us
<hggdh> bjf: ack :-)
<infinity> bjf: Alright.  I may artificially delay for a few days to make sure all our point release ducks are in a row, but "by next Monday" seems entirely reasonable.
<henrix> bjf: ack
 * bjf feels much better only skipping a single cycle
 * infinity is reminded that he needs to do a d-i upload to precise for the last SRU round...
<antarus> yes please don't forget poor little precise ;p
 * ppisati -> gym
<bjf> ogasawara, i'm starting to look at the release notes for 12.04.2. have you done anything there yet?
<ogasawara> bjf: not yet, but it is on my todo list for today
<bjf> ogasawara, so i can just ignore it :-P
<bjf> ?
<ogasawara> bjf: yah, let me take a first stab at it.  I'll probably ask you to review/edit tomorrow.
<bjf> ogasawara, wfm
<ohsix> where do i get me a vmlinux for perf nowadays, last time i had to do it it was ugly and it didn't end up in /boot and stuff
<jsalisbury> apw, ogasawara should 3.8.0-4 have a linux-tools package?  I see the latest one available is linux-tools-3.8.0-2 .  bug 1115047 was opened for this
<ubot2> Launchpad bug 1115047 in linux (Ubuntu) "perf tool missing for Linux 3.8.0 (raring)" [Medium,Confirmed] https://launchpad.net/bugs/1115047
<apw> jsalisbury, i think i would expect us to be able to make one, it was off because it needed libraries from universe, but i thought tim fixed that
<jsalisbury> apw, Actually, I think I see it here: https://launchpad.net/ubuntu/raring/amd64/linux-tools-3.8.0-4
<apw> jsalisbury, indeed we do seem to be building one
<jsalisbury> apw, and it seems accesible from https://launchpad.net/ubuntu/raring/+source/linux
<ogasawara> commit fdfb1fd6dccabf8ff4f4979d01d4f47b47fc5994
<ogasawara> Author: Tim Gardner <tim.gardner@canonical.com>
<ogasawara> Date:   Thu Jan 10 12:41:32 2013 -0700
<ogasawara>     UBUNTU: [packaging] Add macro to selectively disable building perf
<ogasawara>     
<ogasawara>     Fixes FTBS until libaudit-dev is promoted to main.
<ogasawara>     
<apw> so the report must be wrong now at least
<ogasawara>     Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
<apw> ogasawara, i think the right thing to do is not MIR anything, but to pull tools out of the main kernel package
<apw> ogasawara, i did start looking at it, or more specifically looking at the version in debian where they do the same thing
<apw> and i think it is probabally viable, at least then it can link to anything
<ogasawara> apw: makes sense to me to separate it
<apw> jsalisbury, ok so we have a package, but no perf in it, so the bug is technically correct
<jsalisbury> apw, ok, thanks
<apw> jsalisbury, can you assign that bug to me, and i'll try and make a proper determination tommorrow
<apw> jsalisbury, as to whether we can just rip it out
<jsalisbury> apw, will do.
<jsalisbury> ogasawara, apw, thanks!
<vanhoof> bjf: wasnt attached to  this session, turning the crank due to regression?
<bjf> vanhoof, all good here. we are turning the crank on everything this week. 
<vanhoof> wont change 12.04.2 will it?
<bjf> nope
<vanhoof> gotcha
<apw> diwic, i have a n7 wh
<apw> diwic, which is refusing to make noises
<diwic> apw, did you see today's update to bug 1068804 ?
<ubot2> Launchpad bug 1068804 in ubuntu-nexus7 "sound only works after suspend/resume cycle" [Critical,In progress] https://launchpad.net/bugs/1068804
<apw> diwic, that is the kernel i am running
<apw> and it doesn't work before or after a s/r now
<diwic> apw, so you're running a kernel with the patch from comment 31?
<apw> diwic, yes, that is why i am whining at you
<ogra> diwic, works fine for me ...
<ogra> but andy seems to suddenly have sound issues (though that looks more like userspace)
<apw> 1/2 isn't a good balance
<diwic> so ogra and apw have both independently compiled their own kernels with the patch from comment #31, with completely opposite results?
<apw> ogra, can i have your asounds.state ...
<apw> diwic, no i made the kernel for both of us
<ogra> diwic, nah
<ogra> i was lazy
<ogra> http://paste.ubuntu.com/1610080/
<diwic> how about the alsa-store.conf override/disable, are both apw and ogra running that?
<ogra> apw, ^^
<apw> diwic, no idea what that is, so assume not
<ogra> diwic, oh, i removed the override files :P
<ogra> apw, whats the version of your ubuntu-defaults-nexus7 package
<apw> 0.50
<ogra> that doesnt have the override files
<ogra> so we should be on the same page 
<ogra> ls -l /etc/init/*.override
<ogra> just to be sure
<diwic> well, if the asound.state has become wrong it will be kept wrong without the overrides, that's a feature
<ogra> yeah
<apw> ls: cannot access /etc/init/*.override: No such file or directory
<ogra> great
<ogra> thats what we want
<diwic> apw, let's have a look at your alsa info
<apw> why don't we ship that damn script with the machine?
<diwic> apw, /usr/share/alsa-base/alsa-info.sh
<ogra> apw, because the driver needs to DTRT
<diwic> IIRC
<ogra> apw, the script is generated on first boot ... thats like asking why we dont ship 1G of different initrds on the CD for all possible machines
<ogra> :)
<diwic> are we talking about the alsainfo script or the asound.state script?
<ogra> the state file
<apw> diwic, i was talking about the one you showed me _was_ installed :)
<apw> http://paste.ubuntu.com/1610099/
<apw> diwic, ^^
<diwic> apw, your speaker is muted
<apw> great, its a shame none of the UI elements tell em that
<diwic> apw, try muting and unmuting and see if it helps
<apw> diwic, ok my speaker is no longer muted, but its still mut
<apw> mute
<diwic> ok
<diwic> I've seen this happen a couple of times actually; the speaker alsamixer control spontaneously mutes itself. Probably some powersave feature or something
<apw> diwic, damn this thing has a lot of mutes, any idea which of the 100s to try next?
<ogra> int spk
<apw> that is already 00
<diwic> apw, don't try manipulating the 100s of mutiee
<diwic> mutes, it's more likely to screw something up.
<apw> oh any i twiddle i am putting back
<apw> not that i have tried many
<diwic> apw, instead try: delete asound.state and move away /etc/init/alsa-store.conf
<ogra> you can cause pretty nasty results with that
<diwic> apw, then power off the nexus7, wait a little while and put it back on.
 * ogra remembers a full day with a squeeking n7 next to him until he got it back to a sane state 
<diwic> hopefully that brings it into a sane state
<ogra> and you couldnt adjust the volume ... and it started when the driver was initialized 
<apw> diwic, ok will try that
<diwic> ogra, what do you mean "couldnt adjust the volume"?
<diwic> ogra, I mean, if it's muted it's muted
<ogra> diwic, that was before you entered the project :) i played randomly with the mixer and got into such a state 
<ogra> not even muting solved it 
<diwic> ogra, aha, ok
<ogra> the driver was just caught in a feedbackish squeek
<ogra> i probably routed some random stuff to some other random stuff that should never have been connected :)
<apw> diwic, ok now i have the volume plips, and the 'alert sound' previews back, but nothing for 'test sound'
<ogra> just like hrw, i just didnt fry my speakers ;)
<diwic> ogra, maybe we should hide more of those controls, all that we don't know what they do
<diwic> apw, try pressing 'test sound' a few times
<ogra> yeah, but thats extra work
<ogra> theoretically people shouldnt touch alsamixer if pulkse works
<ogra> or they should know what they do ...
<apw> diwic, nothing obvious, i get the 'tink' to say i've hit Test, but no actual speaking bit
<diwic> apw, yeah, for some reason the 'test sound' is sometimes a 'blupp' and sometimes 'front left'. Both count as success.
<apw> diwic, really, thats ... not obvious
<diwic> apw, I haven't investigated them.
<apw> totem can't play an mp3 either
<apw> even though it did install *-bad first time
<diwic> apw, btw, speaking of funny alsamixer controls. Did you know what the one I disabled did? It was no regular control. It was a debug feature to set/get individual codec registers. Left channel was the codec register address, right channel was the data to get/set.
<apw> heh now that is, er nice
<diwic> apw, you can imagine what happens when alsactl tries to save/restore that kind of stuff.
<apw> it is not going to end well for sure
<apw> diwic, neither can rhythmbox even though it knows what it is
<diwic> (especially as codec register address 0 was the default, and that likely causes some kind of codec reset. Not that what it does is really documented, just a guess.)
<apw> so whatever those apps use is not connected to anywhere
<diwic> apw, does rythmbox show up under applications in sound settings when it's playing something?
<apw> yep, and full volumn
<diwic> but no sound
<diwic> ?
<apw> that is correct
<diwic> apw, while it plays back, try the test speaker feature again in sound settings, is it still working?
<apw> diwic, nope
<diwic> apw, can you go into alsamixer and see if "speaker" has muted itself again?
<apw> diwic, alertsound still works
<apw> diwic, as does plip on volume change
<diwic> apw, so you have volume change 'plip' but not test speaker 'blupp'?
<apw> correct
<diwic> now that's a combination I've never seen before.
<apw> diwic, speaker not muted
<apw> diwic, i can only assume it is s/w somehow
<diwic> apw, 'pactl list' output?
<diwic> 'pacmd list'
<apw> http://paste.ubuntu.com/1610165/
<apw> http://paste.ubuntu.com/1610166/
<apw> ok since running those two, if i start playback again i get like a nice chainsaw
<apw> which is volume controlled
<diwic> apw, yeah, it looks like it's constantly reconnecting to pulseaudio or something. Or that's my guess, given that rythmbox is "sink input #82" and I doubt that you've started 81 other clients before
<diwic> but ogra has working rhythmbox?
<ogra> i havent tried rb
<ogra> i played a webm video, tried the test sound and have the plop from the volume up/down here
<apw> client: 27 <Rhythmbox>
<apw> diwic, ^
<ogra> diwic, playing the HBR1 ambient station from RB now 
<apw>     index: 111
<ogra> works fine
<apw> diwic, and quitting and restarting rb has gone back to silence
<bjf> apw, your kernel is working for me
<diwic> ogra, maybe we should add more alsamixer controls, put them first and call them "WARNING" and "DO NOT TAMPER" to avoid more people frying their speakers :-)
<ogra> haha
<apw> diwic, ahhh got it, i had to install -ugly
<apw> diwic, when you try the first time it tells you to install -bad
<apw> after you do that, it never says another thing
<diwic> apw, now what do we think of RB doing that? Is it bad, or just ugly? :-)
<apw> but without, it is just silent
<apw> diwic, well it doing something dumb is ... ugly
<apw> diwic, thanks ... and bjf thanks as well
<diwic> apw, anyway, you got successful playback of mp3 files now?
<apw> diwic, i do thanks, once you fixed my plips i was fixed
<diwic> yw
<bjf> apw, it seems to always come up "mute" when i reboot
<apw> bjf, i thought we had a saver for that.  i'll give it a go next
<diwic> bjf, is that with or without the alsa-store.conf override?
<bjf> diwic, i've not done anything special other than install apw's kernel
<ogra> sudo rm /etc/init/alsa*.override
<apw> ls /etc/init.d/*.override
<bjf> yes, those exist
<ogra> remove them
<ogra> they need to go away once the kernel is in
<diwic> interesting, so then they do have a purpose
<diwic> I was thinking pulseaudio was enough with storing/restoring volume
<diwic> it should have been
<ogra> it seems to store the volume here 
<ogra> but still comes up muted
<ogra> it is at full volume if i had it there and unmute after a reboot
<diwic> maybe it has something to do with the spontaneous mutes of alsamixer controls, haven't really figured out why that happens and what to do about it
<bjf> ogra, indeed, that seems to have "fixed" it. i rebooted and it came up in the same state (un-muted)
<ogra> so the only bit left is the muting
<diwic> apw, bjf so it looks like my patch actually fixes the no-sound-before-s3 problem, can I trust one of you to apply it to the official nexus7 kernel?
<apw> diwic, yep i have applied it already, i'll be uploading it once i am happy the other fixes are good
<apw> ogra, were you happy with dmesg
<diwic> apw, thanks
<ogra> apw, absolutely 
<diwic> ok, got to do some laundry now, happy evening everyone
<ogra> you too, and thanks !
<diwic> :-)
<diwic> bye!
<ogasawara> bjf: I've taken a first pass at https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop
<ogasawara> bjf: specifically the "LTS Hardware Enablement Stack" and "Ubuntu Kernel 3.5.0-23.35" sections
<ogasawara> bjf: I still need to scrub the known kernel issues section
<ogasawara> bjf: but let me know what additional edits I should make or info I should add
<bjf> ogasawara, ack
<vk1266> can anyone please suggest how I should check whether a particular LP bugfix has been applied to the mainline kernel?
<bjf> vk1266, which LP bugfix are you referring to?
<vk1266> LP: #1040557
<ubot2> Launchpad bug 1040557 in linux (Ubuntu) "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Fix committed] https://launchpad.net/bugs/1040557
<bjf> vk1266, i can tell you that bugfix (or a variant of it) is in Linus' tree and was part of 3.8-rc6
<vk1266> so I guess I am reasonably safe to try the mainline kernel on my Samsung, right?
<bjf> vk1266, you are building the kernel from the sources yourself?
<vk1266> no, I need to install deb's to verify if another bug still persists in the mainline kernel
<bjf> vk1266, are they ubuntu debs?
<vk1266> yes
<bjf> vk1266, so for that bug you can see that the fix was released for oneiric, precise and quantal. so if you are installing a recent kernel from one of them you should be fine.
<vk1266> bjf - perfect, thank you, that's what I needed to know. Now I am off to installing the mainline kernel for my Samsung and checking that other bug!
<bjf> vk1266, wait!
<vk1266> yes...
<bjf> vk1266, there is a difference between an ubuntu kernel and a "mainline" kernel
<bjf> vk1266, which "mainline" kernel are you installing? where did it come from?
<vk1266> http://kernel.ubuntu.com/~kernel-ppa/mainline
<bjf> vk1266, which mainline kernel are you going to install?
<bjf> vk1266, that patch just went into mainline late last week
<bjf> vk1266, if you are installing the v3.8-rc6-raring you should be ok
<bjf> vk1266, is there a specific bug that you are testing that kernel for?
<vk1266> I have quantal; I guess I cannot try v3.7-rc2, it is dated 20-Oct-2012 - must stick with 3.5.7.4
<vk1266> I need to run the test for LP: #1114856
<ubot2> Launchpad bug 1114856 in linux (Ubuntu) "power button not working when Samsung laptop is booted in CSM mode; works fine in EFI mode" [Medium,Confirmed] https://launchpad.net/bugs/1114856
<bjf> vk1266, ok, hold off while i look at that
<vk1266> Considering that 3.8 kernel is not yet available to my quantal installation, and that my current kernel is 3.5.0-23.35, I am wondering how much value will be in checking out 3.5.7.4
<bjf> vk1266, i would not test a mainline kernel for that case. i'm going to add a comment to that effect.
<bjf> jsalisbury, still around?
<vk1266> thank you bjf! maybe I should try installing raring on my Samsung, but for just checking one bug it may be a little too much
<bjf> vk1266, if you can wait, there will be a new Quantal kernel in -proposed by next week that might help
<vk1266> sure I can -- if the LP bug waits for me
<bjf> vk1266, i think there is a good chance it will still be around
<vk1266> bjf, thank you - I will keep checking -proposed
<vk1266> bjf, I am going to make a note in the LP bug to that extent
<bjf> vk1266, sounds good
<vk1266> bjf, I have posted a note to LP: #1114856 - thank you, I will now be checking -proposed and the mainline kernel ppa
<ubot2> Launchpad bug 1114856 in linux (Ubuntu) "power button not working when Samsung laptop is booted in CSM mode; works fine in EFI mode" [Medium,Confirmed] https://launchpad.net/bugs/1114856
<bjf> vk1266, ack, thanks
<jsalisbury> bjf, hey
<bjf> jsalisbury, hey, if you read the scrollback you get some indication of what i was going to mention
<jsalisbury> bjf, ok
#ubuntu-kernel 2013-02-05
<bjf> jsalisbury, so basically we just have to be careful asking for "mainline" kernel testing with samsung laptops and efi mode
<jsalisbury> bjf, ack.  I'll be sure to note the model for future requests.  I requested v3.8-rc6 for that particular bug, but I'll hold off on asking for any mainline testing on Samsungs until the patch lands in all the releases.
<jsalisbury> bjf, better be safe than sorry
<jsalisbury> bjf, thanks for the heads up
<bjf> jsalisbury, np, i saw that you gave the correct kernel version. i just worry people might miss that in a rush to test.
<jsalisbury> bjf, agreed
<bjf> ogasawara, i reviewed the release notes and what you have so far looks good to me
<ppisati> moin
<smb> ciao
 * apw whines
<smb> Same procedure as every day...
<herton> ppisati, will be ti-omap4 branch removed from raring (along with the packages in the archive)?
<ppisati> herton: if everything goes as planned, yes
<ppisati> herton: but we can't do that now
 * ppisati is exactly tracking down a BUG() in -omap that affects omap4 boards
<ppisati> then ill have to fix cpufreq and drm
<herton> ppisati, ack. I disabled yesterday ti-omap4 bug tracking opening from the bot for raring.
<ppisati> and after those, if everything is ok, we will flip the switch
<ppisati> herton: ack
<ppisati> brb
 * henrix -> late lunch
<didrocks> apw: hey, how are you?
<apw> didrocks, ok thanks, you ?
<didrocks> apw: I'm good, thanks! :)
<didrocks> apw: I think you know about that issue, as the hardware is pretty common, but with a wifi card Intel Centrino Advanced-N 6205 (2x2 AGN), the connexion has always been pretty poor
<didrocks> for the past 3 weeks though, it's even worse, and I have regular connexion drop
<didrocks> tjaalton is experiencing the same
<didrocks> (raring)
<didrocks> not really sure from where to start, I found bug #937118 which can be similar
<ubot2> Launchpad bug 937118 in linux (Ubuntu) "8086:0084 Wireless stops passing packets" [High,Expired] https://launchpad.net/bugs/937118
<tjaalton> yeah I've had it with t420s since I got it
<didrocks> popey has the same card IIRC
<apw> so has it ever worked, the norm is to try and find somewhere it did
<apw> and try then to find when it went south
<didrocks> apw: it worked, but the reception always have been borderline, not sure for tjaalton?
<rtg_> also, think about what might have changed in your environment. new access point ?
<didrocks> rtg_: if you look at this card with "ubuntu", you will find a lot of similar cases, so I doubt it's something due to the environment
<tjaalton> it works, just that for instance ssh connections tend to get stuck for a while etc
<rtg_> didrocks, I'm well aware of the issues. we've had this problem for quite awhile. you could try disabling 802.11n
<tjaalton> I've had the same issue with both of my access points (old buffalo, new asus rt-n66u)
<didrocks> rtg_: any guide how to do this? I guess I don't need the n norm yeah
<sforshee> didrocks, it's controlled by the 11n_disable flag to the iwlwifi module
<rtg_> ddiyeah, what sforshee said
<rtg_> didrocks, ^
<Sarvatt> didrocks: 3.7.0-7 still works properly if you need something working, intel wifi is just busted in 3.8
<didrocks> I just set that in /etc/modprobe.d/iwlwifi.conf and at next module reload, it should be disabled, right?
<sforshee> didrocks, yes
<didrocks> Sarvatt: oh, interesting to know, at least, there is a starting point to know when it did work :)
<Sarvatt> https://patchwork.kernel.org/patch/2007911/
<didrocks> (and a workaround)
<Sarvatt> most likely that
<sforshee> a lot of folks have been having problems for a while now
<didrocks> Sarvatt: yeah, probably, thanks for the link!
<tjaalton> "driver channel switch failed, disconnecting", that's what my dmesg seems to have
<rtg_> sforshee, oh, isn't that background scanning ? I've always thought that was a lousy feature.
<xnox>  dlm-pcmk was dropped in precise, yet when I try to start cman, it tries to $ modprobe dlm which fails with FATAL: Module dlm not found.
<xnox> where do I get dlm module from?
<sforshee> rtg_, it might be. Intel wireless does background scanning in hw though
<sforshee> didrocks, tjaalton, Sarvatt: you're all getting the "channel switch failed" message? I'll follow up on the upstream thread to let them know there are more people seeing this.
<sforshee> I should test with some of my kit as well
<xnox> aha, why is dlm module not included in the linux-image-virtual flavour?
<sforshee> I think this must be a new problem separate from the other iwlwifi problems people have been seeing for a while now
<Sarvatt> checking my logs, I don't remember seeing any error, just unusably slow wifi
<didrocks> sforshee: no, I don't get that message in dmesg, however, it seems to happen indeed when it's scanning
<Sarvatt> its been a problem since 3.8-rc1 here
<tjaalton> sforshee: just noticed it, looks like it's not a common error message here.. just one match zgrepping through syslog.*
<sforshee> the commit from the mailing list thread is from 3.8-rc4
<sforshee> so probably not the same problem
<tjaalton> what seems more common is "deauthenticating from ... by local choice (reason=3)"
<sforshee> tjaalton, is that new? Or have you been getting it for a while?
<tjaalton> sforshee: goes back to Jan 24th, that's the oldest remaining logfile I have around
<Sarvatt> sarvatt@tangerine:~/linux-2.6$ git describe f590dcec944552f9a4a61155810f3abd17d6465d
<Sarvatt> v3.8-rc1-2-gf590dce
<Sarvatt> i'll try reverting it just in case
<sforshee> Sarvatt, do 'git describe --contains'
<sforshee> that will tell you the first tag containing the commit, which came out 3.8-rc4 for me
<Sarvatt> oops :)
<Sarvatt> bisect it is
<sforshee> for any problems which started in 3.8, bisecting is a good idea
<tjaalton> sforshee: oh, kern.log has older entries
<sforshee> we've known of problems with iwlwifi for a while, the problem is that testers haven't been reliable and bugs have gotten flooded with a variety of different problems
<tjaalton> ok, so we can create private bugs to track individual bugs without attracting too many me-too'ers? :)
<sforshee> yes, you can create a private bug and assign to me and we can start trying to work through things
<tjaalton> cool
 * sforshee is seeing poor iwlwifi performance in 3.8 too
 * ogasawara back in 20
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<rtg_> apw, was looking at one of your work items re: switch ureadahead to new in kernel interfaces.  isn't that already done ? or did you just backport the old interface to the kernel ?
<apw> rtg_, i fixed the old ubuntu patch indeed
<apw> rtg_, and with the backports this is probabally a good thing
<rtg_> apw, indeed
<rtg_> guess I should pump up a new raring backport
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 12th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<davmor2> hey guys,  I have a lenovo ideapad y580 and after a lot of research via google it seems the only way to have the bluetooth operational is to dual boot it with windows and then enable it in windows and then it just works in Ubuntu/Linux   I ws wondering if you guys knew anything that might have the same effect, without the need for windows
<rtg_> davmor2, that sounds like a bluetooth firmware issue. 
<davmor2> rtg_: quite possible
<rtg_> davmor2, I think there are issues with some BT firmware being redistributable. is there anything in your dmesg that complains about not finding it ?
<davmor2> rtg_: paste.ubuntu.com/1613446
<rtg_> davmor2, hmm, kind of looks like it started up correctly. have you 'dmesg|grep -i firmware' ?
<davmor2> rtg_: paste.ubuntu.com/1613456
<rtg_> davmor2, I guess I'd suggest you start an LP bug, then email the bluetooth developers list.
<davmor2> rtg_: thanks will do
<rtg_> henrix, herton: need to reboot gomeisa for kernel update
<henrix> rtg_: ack
<herton> rtg_, ack
<rtg_> bjf, quantal has 372 commits since the last release
<bjf> rtg_, yup
<ohsix> damn i didn't even know about ec_sys and nobody mentioned it while i was debugging my backlight freezing problems, i can diff the EC memory and see what happened
<sforshee> didrocks, tjaalton, Sarvatt: so it looks like the iwlwifi problems I'm seeing in 3.8 are caused by the commit referenced at https://patchwork.kernel.org/patch/2007911/
<sforshee> I've got a test build with the patch reverted, let me post it somewhere so you all can test it as well
<Sarvatt> sforshee: it's highly possible i'm mistaking -rc1 with 3.8.0-1 which was rc4
<Sarvatt> which would make sense :)
<sforshee> Sarvatt, I tested the 3.8-rc1 mainline ppa build and it was fine for me
<sforshee> my problem appeared in -rc4
<sforshee> I've already responded on the mailing list thread, so I'd expect them to revert the patch for -rc7
<Sarvatt> revert is already queued too
<sforshee> oh it is?
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-fixes.git
<sforshee> Sarvatt, okay it's already in wireless-testing but not yet in wireless-next
<bjf> rtg_, number of commits applied since release: lucid (3308) oneirc (3035) precise (2341) quantal (835)
<sforshee> ah no, it wouldn't be in wireless-next
<sforshee> rtg_, is gomeisa still rebooting?
<Sarvatt> tjaalton: http://kernel.ubuntu.com/~sarvatt/iwlwifi/ kernel with that revert if you want to try it too
<rtg_> sforshee, otp
<sforshee> Sarvatt, thank. My build is on gomeisa and I can't connect atm.
<tjaalton> Sarvatt, sforshee: ok thanks, I'll give Sarvatt's build a go
<Sarvatt> i built that first thing but hadn't tried it yet, was still bisecting. go figure :)
<Sarvatt> takes about 20-30 minutes to reproduce here
<sforshee> well, since you guys have a build to test now I'm going to grab some lunch
<jsalisbury> rtg_, do you happen to know if gomeisa is down?
<rtg_> jsalisbury, otp, I'll get to it in a bit
<jsalisbury> rtg_, ok, thanks
<Sarvatt> sforshee: this is working great for me as well, thanks!
<tjaalton> I get a sustained 11MB/s copying large files to devnull on another machine hooked on gigabit ethernet
<rtg_> jsalisbury, sforshee: working on getting gomeisa power cycled
<jsalisbury> rtg_, cool, thanks.  I just moved over to tangerine for now ;-)
<rtg_> gomeisa should be cycling. I'll be back after a quick lunch.
<dhanasekaran> Hi guys Adaptive RX it's not properly set using ethtool
<apw> dhanasekaran, define 'not set properly', and on what device
<dhanasekaran> apw: driver: igb  version: 3.2.10-k
<apw> and how are telling it doesn't work
<dhanasekaran> apw: I want enable Adaptive Rx ethtool -C eth0 adaptive-rx on ; ethtool -c eth0 | grep 'Adaptive RX'
<dhanasekaran> I tried Adaptive RX not enable after set
<dhanasekaran> I am using 3.2.0-37-generic
<dhanasekaran> apw: any help
 * ogasawara lunch
<apw> dhanasekaran, are you sure that device supports it?  i see that if you set options in that set and they are not supported they are silently ignored
<apw> dhanasekaran, it seems to understand the rx_coalesce_usecs and tx_coalesce_usecs
<apw> but i don't see anything about the adaptive stuff
 * rtg_ -> EOD
<BarkingFish> Good evening :)  jsalisbury - is there any chance I could grab you for a quick word please concerning the bug you're helping me to track down please? 1113048, concerning the ar5523 driver?
<BarkingFish> I've got the 3 rc kernel candidates you asked me to install, installed - now, ndiswrapper is building in rc2 which is where I am now, so at least I can get on the net.  From what I can find though, the ar5523 module doesn't appear in any of the 3 kernels. 
<BarkingFish> I've tried to modprobe it, since it's not picking up on boot - and it just pops up "Fatal: module ar5523 not found"
<scientes> is there any repo of just the packaging stuff?
<scientes>  /debian
<scientes> i want to package an out-of-tree kernel
<scientes> that has special bootstrap/install stuff
#ubuntu-kernel 2013-02-06
<BarkingFish> ok guys, well I'm gonna have to head out. jsalisbury - if you see this, I'll stop by some other time - but I'm needed in ER, so I'm out for the night. See ya
<jussi> hrm, Im on 12.10 and a kernel update is giving me issues. tbh, I quite scare to restart the machine...  paste of apt-get install -f http://paste.ubuntu.com/1615272/
<jussi> its way too early in the morning, so forgive me if it is something simple
<ashwini_> Can any one tell me the default stack size for kernel 3.x and 2.6.y (y < 31)???
<ppisati> good morning Viet^W^W^W^Wworld
 * jussi hugs ppisati and bribes him with coffee and breakfast for some help :D
<ppisati> jussi: what's up?
<jussi> [08:53:39] <jussi> hrm, Im on 12.10 and a kernel update is giving me issues. tbh, I quite scare to restart the machine...  paste of apt-get install -f http://paste.ubuntu.com/1615272/
<jussi> [08:54:36] <jussi> its way too early in the morning, so forgive me if it is something simple
<ppisati> jussi: gzip: stdout: No space left on device
<jussi> ppisati: errr? this is my laptop... is that /boot ? or just my HDD  is full (shouldnt be...)
<ppisati> jussi: dunno, df -h will tell you
<ppisati> jussi: but i guess is /boot
<jussi> /dev/sda1                   228M  226M     0 100% /boot
<jussi> yep
<jussi> right...
<jussi> so I guess old kernels need moving on then? 
<ppisati> dpkg -l | grep linux-image
<jussi> http://paste.ubuntu.com/1615707/
<ppisati> jussi: i think you know what to do from here
<jussi> ppisati: yeah, I think so. --purge them, right? 
<ppisati> jussi: except for the running one, yes
<jussi> ppisati: what are the -extra images? 
<ppisati> jussi: stuff that was moved out of linux-image
<ppisati> jussi: dpkg -L will tell you
<jussi> thanks ppisati, much appreciated.
<caribou> where is the linux-meta package maintained ? In launchpad or somewhere in the kernel tree ?
<smb> caribou, neither. In a git repo seperate to the kernel
<caribou> smb: and how one propose a patch ? (can you see the linux-crashdump dependency on kdump-tools coming ;-) ) ?
<smb> caribou, Right, I actually was thinking of submitting that soon
<caribou> smb: ok, then, I won't bother
<caribou> smb: afaik, once this is done, kdump-tools should be pulled in main
<caribou> smb: since linux-crashdump will depend on it, and the makedumpfile source is already in main
<smb> caribou, Not sure how strict dependency issues are for a meta package but it sounds reasonable to have those things that are core functions in main
<caribou> smb: don't know about meta package either, I can check 
<ashwini_> any clue regarding default stack size in the kernel 3.x and 2.6.28+ ?
<smb> caribou, Talking to apw it sounds like having the dependency in meta will require some parts to be in main. Just not sure whether this can only be the source package or not. So maybe that should be resolved before changing the meta package.
<smb> caribou, Just as for what needs to be in main and what would that mean (mostly security updates? and would we think there are?)
<caribou> smb: I just pinged pitti in #ubuntu-devel; he seems to think so
<caribou> smb: well, the security updates would make it in from makedumpfile which is already in main anyway, isn't it ?
<smb> caribou, From that side yes. Guess the only thing I can think of right now is the tools placing dumps with not enough limited access...
<apw> ashwini_, i belive they can be either 4K or 8K on x86 I believe we use 8K but i am struggling to find the confirmation
<apw> ashwini_, THREAD_SIZE is the relevant define
<ashwini_> apw: THREAD_SIZE is 8k, I belive in new kernels the stack size is 4k instead of 8k. just want to confirm once. Any way Thanks
<apw> ashwini_, in v3.8-rc's it seems unchanged
<ashwini_> apw : is STACK size 8k ? or THREAD_SIZE 8k ? any link?
<apw> THREAD_SIZE is 8K, which is the kernel stack size, which is documented in kernel source in Documention/x86/x86_64/kernel-stacks and obviously set in the arch specific headers in the source
<apw> arch/x86/include/asm/page_32_types.h:#define THREAD_SIZE_ORDER  1
<apw> arch/x86/include/asm/page_64_types.h:#define THREAD_SIZE_ORDER  1
<apw> here defined in allocator order, 0 == 4K 1 == 8K on x86
<ashwini_> apw : Thanks, your help and pointers much appreciated
<ashwini_> apw: it resolved my lot of doubts
<ogra_> apw, one for us to test (later today) http://nv-tegra.nvidia.com/gitweb/?p=chromeos/kernel.git;a=commitdiff;h=b50bf5979036750891461a5824bb12273f04fe16 ... from bug 1080789
<ubot2> Launchpad bug 1080789 in ubuntu-nexus7 "Corruption around mouse cursor when dragged, particularly around Dash, Indicators, window chrome" [Low,Confirmed] https://launchpad.net/bugs/1080789
<apw> ogra_, sigh
<ogra_> apw, no hurry for that one, itr only exposes if you have a mouse attached to the tablet, thats rather low prio and can well wait until the next upload happens anyway
 * ppisati notices there's sun outside and goes out for lunch
<smb> sun... lucky bastard
<apw> ogra_, that patch looks to be from a completely different kernel version, cirtainly none of the things it changes seem to exist
<apw> ogra_, after a fair bit of looking i cannot trivially find anything remotly similar to apply it by hand
<ogra_> apw, ok
<apw> ogra_, i recon it would be appropriate to do the testing as recommended in the bug
<apw> ogra_, it can only eliminate something
<AlexMG> Hi guys, I was trying to use the fetch=url parameter, to netboot filesystem from the ubuntu-livecd. But it seems as the fetch parameter is just ignored. Are changes needed inside the initrd or do I just use the wrong kernel options? KERNEL-Options loaded from iPXE: kernel http://192.168.1.50/httpboot/ubuntu-x64-live/vmlinuz boot=casper config fetch=http://192.168.1.50/httpboot/ubuntu-x64-live/filesystem.squashfs
<ogra_> well, the kernel patch is for consoles, which dont work at all anyway (you cant switch to console once X is up, restriction of the driver )
<ogra_> so i guess we can as well skip it
 * henrix wanders if something killed a ppc build or it was a genuine build failure
<rtg_> herton, henrix: did you notice the Quantal PPC FTBS ?
<rtg_> https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4277902/+files/buildlog_ubuntu-quantal-powerpc.linux_3.5.0-24.36_FAILEDTOBUILD.txt.gz
<henrix> rtg_: yep, i was just complaining about that :)
<henrix> rtg_: no idea what went wrong there...
<henrix> i guess i'll just retry
<herton> henrix, it's a build failure in alx driver
<rtg_> henrix, looks like a bonafide linker error
<henrix> hmmm?
<herton>  /build/buildd/linux-3.5.0/ubuntu/alx/alx_main.c: In function 'alx_alloc_rings':
<henrix> herton: oh, crap! you're right
<henrix> looks like its failing only on ppc. amd64, i386 and armhf are fine
<henrix> which doesnt' make sense
<apw> henrix, could be believeable if it is a locking primative or similar which was changed between working and not; those are arch specific
<apw> henrix, and have arch specific external symbol requirements
<henrix> apw: yep. i'm rebuilding it in gomeisa as i deleted the build logs, just to make sure.
<apw> henrix, or indeed that driver may be only on in PPC
<apw> henrix, and isn't that a driver which was applied like only Feb 04
<henrix> apw: yep, that's the one
<apw> henrix, i don't see how this is valid on any release
<apw> as it blatently uses vzmalloc without includeing vmalloc.h
<henrix> apw: yeah, so maybe you're right: it may be built only for ppc. i'm investigating
<henrix> apw: so, my theory is that one of the headers included by the alx driver will bring net/ip6_checksum.h and linux/vmalloc.h on some archs but not for powerpc
<henrix> apw: if you look at the buildlogs for amd64 for example, the driver compiles successfully
<henrix> apw: i'll test a patch on a ppc box that will just include these 2 headers (that should be in the driver anyway)
<rtg_> henrix, I think perhaps you could just disable the alx driver build for all but x86'en
<henrix> rtg_: well, that's another solution. would you prefer that? i guess it will be useless in ppc anyway
<rtg_> henrix, Its the simplest.
<henrix> rtg_: ack, will do that then. thanks
 * henrix -> errand
 * ogasawara back in 20
<henrix> rtg_: fyi i'm going to apply the alx patch to Q master-next
<rtg_> henrix, already did
<henrix> rtg_: heh, cool. thanks
<rtg_> jjohansen, henrix, rebooting tangerine for kernel update
<henrix> rtg_: ack
<jjohansen> rtg_: okay, give me one minute
<jjohansen> hehe, or not
<rtg_> jjohansen, go ahead
<jjohansen> rtg_: no I'm good, I just wanted to make sure my editor was closed and saved, but I had already done that
<slangasek> hi, can anyone here tell me if there's more debugging info that would be useful from the running process on bug #1117499, before I kill with fire?
<ubot2> Launchpad bug 1117499 in linux (Ubuntu) "killall -9 firefox fails to work in raring" [Critical,New] https://launchpad.net/bugs/1117499
<slangasek> bjf: ^^ any thoughts on this madness?
<ohsix> would want to see the process state and wchan
<slangasek> ohsix: shown how?
<ohsix> /proc/<pid>/wchan, top displays it i think
<ohsix> if it's waiting on something in the kernel it will have a name, it wouldn't be unkillable unless it's in a syscall that won't exit
<slangasek> well, seems to be state 'R' - not state 'D' which is what I would normally expect to see for an unkillable process?
<slangasek> so I guess the next question is, can I kill the X server or is it similarly wedged
<ohsix> there's no transitive property of signal-undelivery between firefox and X or any other process i know of
<slangasek> sure
<ohsix> what's perf top say firefox is doing
<slangasek> but the firefox and X processes seem to be in a similarly useless state
<slangasek> (using lots of CPU according to top, but not using it for anything I would like it to)
<slangasek> ohsix: I don't have perf installed and apt offers me two choices - linux-base and linux-tools-common.  Does it matter which I take?
<slangasek> oh, looks like one of these might be a ghost and linux-tools-common is the right one
<ohsix> it's in linux-tools-common
<rtg_> slangasek, should be linux-tools-common
<slangasek> er, except it isn't in fact
<slangasek> packaging bug?
<ohsix> i got that same offer after a reinstall, didn't look into why it suggested linux-base; there's a wrapper script and a versioned binary to go with the kernel, i'm guessing they moved around a little
<infinity> slangasek: linux-tools-$(uname -r)
<ohsix> perf_<tab> :)
<slangasek> $ dpkg -L linux-tools-common | grep perf
<slangasek> /usr/share/man/man8/x86_energy_perf_policy.8.gz
<slangasek> /usr/bin/x86_energy_perf_policy
<slangasek> infinity: ta
<infinity> Err, or not.
<slangasek> infinity: minus the -generic :)
<infinity> linux-tools-3.8.0-4
<infinity> Yeah.
<infinity> There's a "linux-tools" metapackage that deals with that. :P
<slangasek> er, that doesn't have it *either*
<infinity> No, it sure doesn't... Did we disable perf again, due to libaudit deps?
<rtg_> slangasek, infinity - I think so due to build issues. lemme recheck it
<slangasek> linux (3.8.0-0.2) raring; urgency=low
<slangasek>   * [packaging] Add macro to selectively disable building perf
<slangasek>   * [packaging] Cannot depend on universe package libaudit-dev
<infinity> It may be high time for us to just MIR audit.
<rtg_> infinity, right, that kind of fell off my radar.
<slangasek> infinity: it's been requested before but stalled for some reason I don't recall... I think I talked to jdstrand about it a while ago, maybe sync with him?
<slangasek> I think we do want to get audit into main though, yeah
<infinity> Yeah, there's been more than one MIR attempt for audit, IIRC.
<infinity> But a ton of stuff depends on it these days.
<infinity> (even glibc)
<slangasek> pam wants it too
<slangasek> and systemd of course
<infinity> https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1026852
<ubot2> Ubuntu bug 1026852 in audit (Ubuntu) "[MIR] audit (pulls in libprelude)" [Undecided,New]
<ohsix> so you can't run perf? that's awesome
<infinity> So, yeah, that's been stalled.  I'll poke the relevant folks.
<ppisati> guess what?
 * ppisati -> gym
<slangasek> Penn and Taler
<slangasek> hmm
<slangasek> so, firefox finally saw fit to die on its own
<slangasek> X is still frozen though
<ohsix> if it really was not responding to SIGKILL, it finally was able to exit whatever syscall it was in _if_ thats' what it was, there's not much else you can do to keep SIGKILL from being delivered
 * rtg_ burns a couple hours catching up with LKML
 * rtg_ -> lunch
<zequence> I have a problem with my debian/rules file. Meaning to update linux-lowlatency for precise. This is what happens:
<zequence> fakeroot debian/rules clean
<zequence> debian/rules.d/0-common-vars.mk:10: *** first argument to `word' function must be greater than 0.  Stop.
<zequence> Been googling a bit, but I might need more stuff to go through all of it
<zequence> apw: Something with the debian folder in lowlatency seems to be wacky. What would be the best way for me to circumvent this problem
<apw> zequence, i think that might be caused by a corrupt versionlog
<apw> zequence, check debian.lowlatency/changelog hasn't got wacked any
<apw> zequence, ahh are you using the fixed version i published ?  
<apw> zequence, i had to remove a blank line from your changelog to be able to upload it
<apw> commit 9a282dd2cd0f7c85f62dea5fe8221940e26a0612
<apw> Author: Andy Whitcroft <apw@canonical.com>
<apw> Date:   Mon Jan 28 09:31:19 2013 +0000
<apw>     UBUNTU: fix up blank lines in changelog
<apw> zequence, i bet it is that which is breaking you, pull from the 'public' repo: git://kernel.ubuntu.com/apw/ubuntu-precise-lowlatency.git
<zequence> apw: Oh. Thanks. Will try that
<zequence> apw: Hope I didn't cause you too much trouble. I baked in your commit, updated, and pushed linux-precise-lowlatency
<apw> zequence, sweet
<apw> will look at it later thanks
<infinity> apw: Your linux-lowlatency is missing a build-dep on openssl
<infinity> apw: (Master has it, you might want to double-check if anything else is missing)
 * rtg_ -> EOD
<apw> infinity, thanks
<infinity> apw: I'd have pointed it out when I fixed powerpc, but I didn't realise lowlatency was similarly broken. :P
#ubuntu-kernel 2013-02-07
<dns53> is there anyone around that knows anything about booting of efi?
<ppisati> moin
<Laney> I assume you're aware of the upgrade failure ;-)
<Laney> bug #1118071 fyi :>
<ubot2> Launchpad bug 1118071 in linux (Ubuntu) "package linux-image-3.8.0-4-generic 3.8.0-4.8 failed to install/upgrade: trying to overwrite '/lib/modules/3.8.0-4-generic/kernel/drivers/ata/ahci_platform.ko', which is also in package linux-image-extra-3.8.0-4-generic 3.8.0-4.8" [Undecided,Confirmed] https://launchpad.net/bugs/1118071
<ppisati> brb
<Kano> dpkg-source: error: syntax error in linux-3.8.0/debian/control at line 13: first block lacks a source field
<Kano> hi, what build-deps are needed?
<Kano> btw. it would be nice when you add
<Kano> http://kanotix.com/files/dragonfire/linux-3.8-rc6/0001-Bluetooth-Add-support-for-AR3012-0489-e04e.patch
<zequence> There seem to be two trackaing bugs for linux-lowlatency worked from bug #1117492
<ubot2> Launchpad bug 1117492 in Kernel SRU Workflow "linux: 3.5.0-24.37 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1117492
<zequence> Bug #1118292 and Bug #1118282
<ubot2> Launchpad bug 1118292 in linux-lowlatency (Ubuntu) "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1118292
<henrix> zequence: ok, my fault. i've exec'ed the bot manually and forgot the bjf's cron job could start running
<ubot2> Launchpad bug 1118282 in linux-lowlatency (Ubuntu) "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1118282
<henrix> zequence: let me fix that for you
<zequence> henrix: oki
<henrix> zequence: ok, so the valid one is bug #1118282 (tagged the other as duplicate)
<ubot2> Launchpad bug 1118282 in linux-lowlatency (Ubuntu) "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1118282
<rtg> henrix, should I have expected an email about the recent Raring upload from bug #1117673 ?
<ubot2> Launchpad bug 1117673 in Kernel Development Workflow "linux: 3.8.0-4.9 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1117673
<rtg> it was not an ABI bump
<henrix> rtg: well, you would have but there's something wrong with the bug.
<henrix> rtg: 'prepare-package-*' tasks should have been set to 'in-progress'
<rtg> henrix, any idea about how I might have messed it up?
<henrix> rtg: when you uploaded the pkgs, did you set the 'prepare-*' tasks to 'in progress'?
<henrix> rtg: this is how the bot will know it has to check the packages were built
<rtg> henrix, I was under the imppression that everything was automatic, so no, I didn't set anything.
<henrix> rtg: ok, you need to manually set the 'Prepare-package' and 'Prepare-package-signed' to 'in progress'
<henrix> the bot will then set it to released when the build is complete
<henrix> and send the email
<rtg> henrix, herton: couldn't the bot detect when the linux package goes to 'released' and just DTRT ?
<herton> rtg, yes, I was implementing this, but didn't finished yet, involves some rewriting and testing of things in the bot
<rtg> herton, well, here is your chance on a real live bug :)
 * henrix -> lunch
<herton> I'll take a look today at it
<zequence> henrix: thanks
<rtg> apw, why is the client stalled while 'Auto packing the repository for optimum performance' ? Does this stop other client threads from accessing the repo whilst auto-packing ?
<apw> rtg, i don't think it does stall others no it is just doing it in the foreground
<apw> rtg, you can just turn it off in your global config, which is what i do mostly
<apw> rtg, so i get to do it at my convienience
<rtg> apw, I wonder why it can't detach and just DTRT without hanging on to my client instance.
<apw> it probabally should indeed.  as far as i know it is done in a safe way, but i have never tried
<rtg> apw, what is the client option ?
<apw> to confirm now i think about it, overall it should just tell you but not do it
<apw> gc.auto = 0
<rtg> apw, thanks
<apw> git config --global gc.auto 0
<apw> rtg, i think this is what you need to do
 * ppisati goes out to enjoy some fresh air... back later...
 * ogasawara back in 20
<henrix> apw: after updating linux-overlay in kteam-tools, do i need to manually update the git repo somewhere, or is that automatic?
<apw> iirc the repo is auto consumed, but it might take a couple of hours to get in sync
<apw> henrix, ^^
<henrix> apw: ah, ok. i've commited it some time ago, but not hours :)
<henrix> apw: thanks
<apw> henrix, the repo is sucked every hour i think, and the runs are hourly but not in sensible alignement with it i suspect
<henrix> apw: ack. i'll check later if it did what i expected :)
<apw> thanks
<sforshee> rtg, I just got an error when trying to install a build from the raring master branch. Both linux-image and linux-image-extra are trying to install ahci_platfrom.ko. I'm guessing this must be due to your recent CONFIG_SATA_AHCI=m patch?
<rtg> sforshee, yep, I just ran into that myslef.
<rtg> sforshee, the inclusion list is supposed to be smarter then that. I'll get it fixed shortly
<sforshee> rtg, actually it looks like the version in the -extra package is from the previous kernel version
<rtg> sforshee, I don't understand that.
<sforshee> dpkg: error processing linux-image-3.8.0-4-generic_3.8.0-4.9~lp000000v201302071541_amd64.deb (--install):
<sforshee>  trying to overwrite '/lib/modules/3.8.0-4-generic/kernel/drivers/ata/ahci_platform.ko', which is also in package linux-image-extra-3.8.0-4-generic 3.8.0-4.8~lp000000v201302062151
<sforshee> rtg, ^
<sforshee> the file in 3.8.0-4.9 is overwriting a file from 3.8.0-4.8
<rtg> sforshee, its likely the inclusion list reg-ex is not sufficient. I'll get it figured out shortly.
<antarus> is linux-firmware shipped with the kernel cadence, or is it released separately?
<rtg> antarus, separately
<antarus> excellent
<sforshee> rtg, it seems to me that the problem is that it moved from linux-image-extras to linux-image, and when linux-image is installing it tries to overwrite the version from the old -extras package, which is still installed
<rtg> sforshee, ah, well that makes sense
<rtg> so I need an ABI bump
<sforshee> yep
<smb> Hm, maybe we always incidentally had an abi change when doing that before
<rtg> frick
<rtg> coming right up
<rtg> sforshee, pushed. I'll get an upload started.
<rtg> herton, what knobs should I be twisting in bug #1118568 ?
<ubot2> Launchpad bug 1118568 in linux (Ubuntu Raring) "linux: 3.8.0-5.10 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1118568
<henrix> rtg: usually you set all the 'prepare-package-*' tasks to 'in progress' and the bot should handle the bug
<henrix> rtg: unless herton has already done the changes to the bot (i didn't check)
<rtg> henrix, well, why doesn't it just start out that way ?
<rtg> so, I have to add this tracking bug to the meta and signed packages as well ?
<henrix> no, the bot will figure out when the -meta and -signed packages are built and will update the tracking bug
<henrix> there's a task in the bug for each pkg you need to prep
<henrix> rtg: i can't think of a good reason for having the initial manual step other than to kickstart the bot activities on the bug
<henrix> rtg: the bot won't start looking for built pkgs if the corresponding task is set to 'in-progress'
<rtg> henrix, I guess my point is that if I've just created the tracking bug then I'm obviously 'in progress'
<henrix> rtg: yeah, i understand what you're saying. i understood herton is changing the bot to assume that
<rtg> ok, cool
<infinity> rtg: You're using release tracking bugs for the devel distro now?
<rtg> infinity, yep, they emit the ABI upload update email automagically
<bjf> infinity, one process to rule them all
<infinity> I assume pretty much all the tasks are being greyed out, then? :P
<infinity> Seems like a bit of process waste, but to each their own.
<herton> rtg, yep, I'm in progress of testing and fixing bugs, soon the bot will be more smarter, and also we can make create-release-tracker set everything to in progress too
 * rtg -> lunch
<jsalisbury> rtg, apw, ogasawara fyi, bug 1084783 has a ton of dupes 
<ubot2> Launchpad bug 1084783 in linux (Ubuntu) "[Regression] SATA reset failing since Linux 3.6" [Medium,Triaged] https://launchpad.net/bugs/1084783
<jsalisbury> rtg, apw, ogasawara seems like it may be resolved already though
<jsalisbury> just wanted to give you a heads up
<apw> jsalisbury, where is it resolved
<jsalisbury> apw, it sounds like if you refresh the apt db a second time, the issue goes away
<ogasawara> am I looking at the right bug?
<apw> jsalisbury, this is a sata reset issue
<apw> jsalisbury, so either wrong bug, or wrong comment ;)
<jsalisbury> ogasawara, apw, sorry, its bug 1118071
<ubot2> Launchpad bug 1118071 in linux (Ubuntu) "package linux-image-3.8.0-4-generic 3.8.0-4.8 failed to install/upgrade: trying to overwrite '/lib/modules/3.8.0-4-generic/kernel/drivers/ata/ahci_platform.ko', which is also in package linux-image-extra-3.8.0-4-generic 3.8.0-4.8" [Undecided,Confirmed] https://launchpad.net/bugs/1118071
<jsalisbury> copy/paste error :-/
<sforshee> I think rtg has already committed a fix
<apw> jsalisbury, on the previous bug, it sounds like ther might be something we should be changing in the config there, worth finding the reference they mention
<apw> jsalisbury, and yeah on that one, it is being fixed now, rtg has it
<apw> rtg can even use the bugnumber :)
<jsalisbury> apw, great, thanks.  
<rtg> jsalisbury, already did the upload
<jsalisbury> rtg, thanks!
 * jsalisbury should have scrolled back on IRC :-)
<zequence> apw: quantal is done too
 * rtg -> EOD
<apw> zequence, thanks
#ubuntu-kernel 2013-02-08
 * shuduo is away: auto-away
 * shuduo is back (gone 00:07:21)
 * shuduo is away: auto-away
 * shuduo is back (gone 00:17:53)
<RAOF> !away > shuduo 
<ubot2> shuduo, please see my private message
<ppisati> moin
 * apw yawns widly
<smb> morning
<apw> morning
<ppisati> herton: when you are awake, can you tell me if shank bot changes that yopu mentiond in the email are already effective? IOW, shall i fiddle with "upload to ppa" or "prepare pkg" for the already opened tracking bugs?
<herton> ppisati, just change upload-to-ppa, bot should be running with the changes now
<apw> herton, oh i have to change upload-to-ppa still
 * henrix -> late lunch
<herton> apw, yep, but it's not a big issue, the bot just ignores it for now and will move tasks forward independent of it
<rtg_> apw, so I saw in a recent status that you decided the parallel boot patches were no longer helping, right ?
<apw> rtg_, that is possibly unfair, i think they are contributing a very small proportion compared to what they did in precise
<apw> rtg_, but of the order of a low enough amount as they are it may not really be worth the risk
<rtg_> apw, do you think they are worth the effort anymore then? 
<apw> rtg_, i intend to get back to that and confirm, and make a proposal, probabally early next week
<rtg_> I'd vote no unless they make a substantial difference
<apw> rtg_, they may not be really, but for very time critical platform they might
<rtg_> do we have one of those ?
<apw> we may, not sure
<rtg_> hmm
<rtg_> back in a sec
<apw> rtg_, they have become ineffective because people have (correctly) added a lot of modprobes in drivers
<apw> rtg_, and we have to sync the initramfs immediatly in that case, which essentially undoes most of the potential savings
<apw> rtg_, my investigation was about whether some of those are essentially async and could thus avoid holding up the mainline
<apw> rtg_, as in many cases they are 'we might need this sometime, probe it just in case' style modprobes
 * rtg_ -> eye doc appt
<ppisati> brb
 * ogasawara back in 20
 * apw calls it a day
 * smb decides thats a good idea
<kamal> rtg_: so...   CONFIG_ALX *did* break the quantal build, eh?:   UBUNTU: [Config] CONFIG_ALX=m for x86 only
<rtg_> kamal, yep, but we don't expect you to airlift beer to us.
 * ppisati -> goes for some pain
<ppisati> IOW -> EOW
<kamal> rtg_: ok but how come the same "for x86 only" fix applied to raring too?
<kamal> *sigh*
<kamal> how come the same fix is *not* also applied to raring, I mean.
<rtg_> kamal, it was PPC that failed. we don't build PPC for raring
<kamal> rtg_: good answer
<rtg_> which is why it would have been hard for you to detect
<kamal> um... *yeah* that's the ticket!  ;-)
<rtg_> don't sweat it. the process is working.
<kamal> and somehow bjf didn't come after my head over this?  *sweet*!
<rtg_> I put the stinkeye on him. I've got your back :)
<bjf> kamal, nope, didn't reach for the shank
<kamal> rtg_: my hero!
<kamal> thanks bjf!  ("no regressions, guaranteeeeeed!")
<bjf> kamal, noone cares about PPC
<kamal> *cough*
<rtg_> except BenC (and some other folks)
 * henrix realises pubs are closing in < 9 hours. better run!
 * rtg_ -> lunch
 * ogasawara lunch
 * rtg_ -> EOW
<sconklin> ogasawara: ping
#ubuntu-kernel 2013-02-09
<infinity> apw, ogasawara: audit MIR is going through now, if someone wants to re-enable perf in linux-tools.
<penguin42> re bug 1093217    comment #44 seems to be suggesting a commit that might be relavent; I've pushed them to do the bisect; but  I wondered if there is already enough info now to move to triaged
<ubot2> Launchpad bug 1093217 in linux (Ubuntu) "Ubuntu 12.04 10-20min boot delay (From 3.2.0.29->3.2.0.30) [Lenovo IdeaPad Z580]" [High,Incomplete] https://launchpad.net/bugs/1093217
<penguin42> it's a pity there isn't an easy mech for end users to do bisects
<ogra_> end users ?
<ogra_> surely you wouldnt ask your MOM to do a bisect whatever easy mexh there would be, would you ?
<ogra_> (and would *she* actually want to ...)
<penguin42> ogra_: Well I'd agree but that seems to be the recommended path for what we tell users on kernel bugs
<penguin42> ogra_: Personally I'd take that bug to triaged when it was between two releases; but Christopher has asked them for a bisection - see #28
<penguin42> ogra_: But there again it shouldn't in principal be that hard to have a ppa like system that provided intermediate builds and walked through you a 'did that work? No? then try this one.'
<ogra_> well, launchpad is open, feel free to implement it ;)
<penguin42> hehe yes, well I was thinking of trying to set up a local lp vm
<ogra_> i heard that isnt to hard (never did it myself though)
<penguin42> might not even need to actually be in lp, a bot driving a ppa and the bug system; but then the starter would be a hack that would build a given git rev in the ppa 
<ogra_> well, thats how prototypes are :)
#ubuntu-kernel 2014-02-03
 * apw yawns
* pratchett.freenode.net changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 4th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<zequence> infinity: Did you guys discuss including -lowlatency in master yet?
<cjwatson> Anyone feel like working out whether bug 1265551 is verification-done for precise or not?  I need to close out the updates for 12.04.4 ASAP
<ubot2`> Launchpad bug 1265551 in linux-firmware (Ubuntu Precise) "linux-firmware: Add Brocade FC/FCOE Adapter firmware files" [Undecided,Fix committed] https://launchpad.net/bugs/1265551
<cjwatson> (There's another bug fixed by that update: bug 1265550.)
<ubot2`> Launchpad bug 1265550 in linux-lts-saucy (Ubuntu Precise) "linux-firmware: iwlwifi: add firmware for 7260 / 3160 devices" [Undecided,In progress] https://launchpad.net/bugs/1265550
<fish_> apw: it happended with 3.11 as well
<fish_> but it *seems* it was harder to reproduce it there
<apw> fish_, so i would recommend filing the bug, and going back through the 3.8.x kernels for one which it didn't happen
<apw> as this seems to be a new phenomia
<apw> we can use that to try and identify the introducing commit
<fish_> apw: not sure sure it's new, I had to restart ~10 containers about 40 times until it crashed this time
<fish_> and I can't reproduce it in a vagrant vm
<apw> fish_, well you never noticed it before, and you managed to reproduce it in the original kernel you reported, so something hcanged
<apw> fish_, so it makes sense to go back to whatever you had where you never noticed it and try and reproduce it there, now you know how
<fish_> apw: the infrastruture is new so I haven't upgraded. could be possible that it happens with older kernels as well. but I'll try an older kernel as wlel
<zequence> apw: Did you come to some sort of conclusion on including -lowlatency into master
<apw> zequence, check out -6
<apw> zequence, and indeed, could you test it ;)
<zequence> apw: cool :)
<zequence> linux-lowlatency is going to be maintained by Canonical from now on :)
<apw> maintained by you, updated and uploaded by us as we do stable etc
<apw> ie we'll do the security bits etc as a part of our normal work flow
<zequence> apw: Alright. So, I supply you with patches? There's only one thing I'd like to change right now. It's to include a couple of kernel configs, to enable the boot parameter "threadirqs"
<zequence> http://paste.ubuntu.com/6867381/
<zequence> I would rather do it by adding a config file somewhere. So far, I only know of adding it to /etc/default/grub, which is not optimal, I think
<zequence> Perhaps it can be done in /etc/sysctl.d/?
<zequence> In that case, I could create a meta package, called ubuntustudio-kernel, break the dependency to rtirq for linux-lowlatency, and add it to ubuntustudio-kernel instead, with a supplied config to enable threadirqs
<apw> zequence, the lowlatency flavour has that switched on in the config by defualt, in theory
<zequence> apw: I need to test it, but I think it is only made available, and still needs a boot parameter for it to be activated
<apw> of course it might not be working but it is on there
<apw> +__read_mostly bool force_irqthreads = IS_ENABLED(CONFIG_IRQ_FORCED_THREADING_DEFAULT);
<apw> in theory that is set to the (new) config optiont CONFIG_IRQ_FORCED_THREADING_DEFAULT
<apw> and i have set that for your config
<zequence> Ah, ok, I mixed it up with CONFIG_IRQ_FORCED_THREADING
<zequence> That should in deed take care of it :)
<apw> i have not looked to see if it works, it looks sane, but i have no idea how you can tell on a booted system which mode it is in 
<apw> i assume something you do makes it obvious if it is working, either by checkng something or by your programs working "better"
<apw> otherwise you'd not bother setting it
<zequence> the rtirq script needs it to work, and that's how I see whether it is working
<zequence> It sets priorities for audio devices, or tries its best to do that - helps some machines that have shared IRQs between things like their firewire port and their wifi (when using a firewire audio device)
<zequence> So, it's very audio specific, and not something everyone will gain from
<zequence> This is why I was considering breaking that part (threadirqs and rtirq) into a meta package, which would be more specified towards audio, but I suppose it's not that critical
 * zequence is leaving for home
<apw> smb, ...
<smb> apw, yeah here maybe :)
<apw> seems you might be in the lucky minority now
<smb> apw, I hope script kiddies cannot spell :)
<apw> smb, heh indeed
<fish_> apw: same error in 3.5 - but I figured out that softlockup_panic=1 will cause the kernel to print a stack trace
<fish_> so bug report is coming soon 
<apw> fish_, great, get us a stack trace in the bug and let us know the bug #; also try and give us something we can reproduce it with
<fish_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275809
<ubot2`> Launchpad bug 1275809 in linux (Ubuntu) "(docker/lxc) container restart causes kernel to lockup" [Undecided,New]
<apw>  bug 1274987
<ubot2`> Launchpad bug 1274987 in linux (Ubuntu) "can't boot with new lowlatency kernel" [High,Confirmed] https://launchpad.net/bugs/1274987
<arges> smb: sforshee : hey running that openstack bug repoducer, any new news?
<smb> arges, Not from my side. But I had a quick email exchange with Salvatore today and he tries to come up with something that does not require devstack
<arges> smb: ahh just after I got it all working : )
<smb> Though he was away for Friday and this morning. 
<arges> well i just started the tests a bit ago... maybe i'll get lucky and reproduce
<smb> arges, You can use that knowledge at least. :)
<smb> arges, Right
<smb> arges, There was also a comment in the bug referring to another one. But I am not sure this is separate or another piece of the puzzle. That was something that made the injection of data fail with some obscure ext2 error
<rtg> apw, I'm here now
<bjf> o/
<apw> jsalisbury, rtg, ok ... yeah PREEMPT is a three way 'choice' so ... zap the ones in there with PREEMPT in their name and do an updateconfigs
<jsalisbury> apw, I see that CONFIG_PREEMPT_VOLUNTARY is not set in the lowlatency, should I also re-enable that one?
<apw> jsalisbury, if you rip the one thats there, you should get the little menu to chose and can pick the _VOLUNTARY one
<apw> which akes all the other Y/N options go the right way too
<jsalisbury> apw, ok, so just rip out the CONFIG_PREEMPT_VOLUNTARY and re-run update configs?  The menu will do the right thing and unset the other two PREEMPTs?
<apw> jsalisbury, right
<apw> it'll ask you, pick the right one, and it sets the "set" as a set appropriatly
<jsalisbury> apw, cool thanks.  I'll build a kernel and post it to the bugs.
<apw> do tell 'em its a diagnostic kernle, not a fix
<jsalisbury> apw, ack
<jsalisbury> apw, I assume I select option two:
<jsalisbury> Preemption Model
<jsalisbury>   1. No Forced Preemption (Server) (PREEMPT_NONE)
<jsalisbury>   2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY) (NEW)
<jsalisbury> > 3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT)
<apw> yep thats wahts on on the others
<jsalisbury> apw, thanks.  Just wanted to make sure I got it correct :-)
<apw> ack
<apw> jsalisbury, if i am reading the comments bug 1275116 right (comments #25ish to #30ish) then it is possible the noirq thing is working for them
<ubot2`> Launchpad bug 1275116 in linux (Ubuntu) "lowlatency-flavour crashes and locks up alot" [High,Confirmed] https://launchpad.net/bugs/1275116
<apw> so the testing we want is the right testing
<jsalisbury> apw, Yeah, a second bug commenter stated it worked for them, but the original bug reported says it did not.
<apw> usual dogpile, anyhow, we're doing The Right Thing(tm)
<jsalisbury> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275116/comments/24
<ubot2`> Launchpad bug 1275116 in linux (Ubuntu) "lowlatency-flavour crashes and locks up alot" [High,Confirmed]
<jsalisbury> apw, Kernel is building now, I'll let you know the testing results.
<apw> jsalisbury, thanks, appreciated
<jsalisbury> apw, np.  thanks to you as well
<apw> rtg, did you rip that smb patch ?
<rtg> apw, yep
<rtg> apw, mess you up ?
 * apw rebases ... again
<smb> apw, You should learn not to mess with rtg 's tree after lunch... 3:-P
<rtg> its just the way I roll.
<apw> smb, oh i've learned ... just some days you cannot avoid it
<apw> just was confirming thats why i had a "..." in my world, can cope
<smb> apw, Hehe, man you love the pain, do you. 
 * apw practices grabbing his ankles ... good for the flexibility don't you know
<smb> apw, Unfortunately that reply from upstream just came in... or I just saw it recently
 * smb tries to squeeze a late between the dots
<apw> "carry large changes out of tree for as little time as possible" is reinforced by an "active" upstream
<apw> rtg, ok i've pushed the split for hyperv
<smb> True. Even more if the deviation is only needed because of some config setting which upstream silently declares as unstable
<apw> now i can go an look at pulling in heap of new bits which need to go in there
<rtg> apw, ack
<apw> rtg, i've pushed the matching -meta changes also
<rtg> apw, ack
<cristian_c> Hello
<cristian_c> I've submitted a bug report (regarding a kernel bug) on launchpad almost two years ago
<cristian_c> recently, the bug status has been set to Triaged and I was told to read this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
<cristian_c> I've read it but I've got some doubts yet. A dev has told me to contact the kernel team for preparing a faultless upstream report
<cristian_c> the first question:
<cristian_c> 1) Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
<cristian_c> I do not know what I have to use between two different kernel since they cause different problems
<apw> cristian_c, what is your bug number, so we can see what the original request actually was
<cristian_c> ok, I'll post immediately
<cristian_c> apw, #972604
<apw> bug #972604
<ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged] https://launchpad.net/bugs/972604
<jsalisbury> cristian_c, The mainline kernel you tested was 3.13-rc5, which is very old now.
<jsalisbury> cristian_c, It might be best to test the latest mainline kernel before opening an upstream bug report.
<jsalisbury> cristian_c, Otherwise, upstream will just ask you test test the latest first anyway.
<apw> yeah they get all whiney if there is a 10th of a commit on top of what you tested
<apw> there should be a 3.14-rc1 now  i guess
<jsalisbury> cristian_c, You can get 3.14-rc1 at: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc1-trusty/
<cristian_c> jsalisbury, the last kernel I tried ha made worse the things
<cristian_c> *has
<cristian_c> jsalisbury, I'd like to solve the original bug
<jsalisbury> cristian_c, those new issues that made things worse could be resolved now, which is the reasoning for testing 3.14-rc1.  
<cristian_c> new kernel change deeply the bug
<cristian_c> *kernels
<cristian_c> jsalisbury, ok
<cristian_c> I'll try the new kernel
<jsalisbury> cristian_c, based on the testing results from 3.14-rc1, we can decide what to do next.
<cristian_c> ok
<cristian_c> second question:
<cristian_c> 2) While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
<apw> man what language is that in
<apw> i think that means "tell me how to reproduce it in the mainline kernel, if you cannot there i don't care"
<apw> "do not tell me how to reproduce it in ubuntu's kernel as i will stop listening"
<cristian_c> apw, yes, but I'm referring to the commit
<cristian_c> Is it the number of commits that introduced the latest regression?
<cristian_c> *commit
<apw> oh, so they mean if you know it does work in a specifc older kernel (mainline only) then they do want to know where you were when it worked perfectly
<apw> i suspect in your case it probabally has never worked
<apw> in whihch case it is not a regression, just broken
<cristian_c> apw, exactly, I've opened the report for a specific bug
<cristian_c> I've tried mny kernels, but only when I tried the 3.13.0, the bug is changed
<cristian_c> *many
<cristian_c> I can try the 3.14-rc1
<cristian_c> to see if it's broken yet
<cristian_c> :)
<cristian_c> apw, thanks
<cristian_c> :)
<apw> np
<rtg> sforshee, here is a good one for you to have a look at: bug #1275879
<ubot2`> Launchpad bug 1275879 in linux (Ubuntu) "Kernel panic " [High,Incomplete] https://launchpad.net/bugs/1275879
<sforshee> rtg: ack
<rtg> sforshee, the stack trace has xen-netfront BUG line
#ubuntu-kernel 2014-02-04
<miseria> "las palabras se las lleva el viento, el vendaval no podra llevarse los secretos mentales escritos en un papel" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<ppisati> moin
 * apw waves to ppisati
<apw> seems freenode is in one piece again
<smb> Morning. Hm, I should change back my bip config then
<mwhudson> apw: hey, are you planning on updating http://people.canonical.com/~apw/arm64/kernel/ ?
<mwhudson> i have one built from 3.13.0-6.23 now if you want that :)
<apw> mwhudson, that is a good point, i always meant that to be "automatic"
<mwhudson> apw: i think it's safe to say it's not at the moment :)
<apw> mwhudson, that is very true :)
<apw> mwhudson (for the logs), ok i have updated the kernel to the -6.23 version in my people blob
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ppisati, about 20 seconds early ;-)
<apw> bjf, did we decide to move to the official upstream fix for CVE-2014-0038
<bjf> apw, yes
<apw> bjf, ok thanks, i'll go and thnk about how we represent "either" being good enough
<antarus> this is in #ubuntu-meeting?
<antarus> or did I miss it...(again?)
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 11th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jsalisbury> antarus, yeah, it was in ubuntu-meeting and was a quick meeting.
<apw> antarus, it was in #ubuntu-meeting on the hour yes
<apw> though as they people who would be in there are all in here, you shouldn't feel entirely limited by its bounds
<antarus> haha
<antarus> are any of you running the saucy backport stack?
<antarus> or are you on T now? :)
<kamal> jsalisbury, idea:  change your 5-minute warning announcement to say "Kernel team meeting in 5 minutes in the #ubuntu-meeting channel".
<jsalisbury> kamal, good idea
<apw> no to ""Kernel team meeting starting in 5m and ending in 9m in #ubuntu-meetin
<apw> g, get your skates on"
<apw> antarus, most of us are all T, though one or two do opt for P+S
<antarus> I was merely curious
<antarus> we have some new hardware, and we are testing P+S and seeing weird issues, I hope to have actual bug reports in a day or so
<antarus> (issues like, 'external monitors do not work anymore'
<antarus> but if most people are running T, it is unlikely you would necessarily catch it on your end
<apw> ok kernel side we tend to be bleeding edge, other people in other bits not so much
 * antarus nods
<jsalisbury> apw, The issue still seems to exist after disabling PREEMPT for bug 1275116  I'm going to install the lowlatency kernel on some of my machines to see if I can reproduce the bug.
<ubot2`> Launchpad bug 1275116 in linux (Ubuntu) "lowlatency-flavour crashes and locks up alot" [High,Confirmed] https://launchpad.net/bugs/1275116
<jsalisbury> apw, any other things you think I should try?
<apw> jsalisbury, well there is only the irq's really
<apw> jsalisbury, otherwise it is a HZ change you could revert that
<apw> basically then it ought to be the "same"
<jsalisbury> apw, Ok, I can give that a try, just to make sure the bug doesn't exist with all those options un-set
<jsalisbury> apw, It was confirmed that the bug still happens with nothreadirqs, so yeah, only the HZ changes are left.
<apw> hrm
<apw> bjf, was i ok repurposing the .24 tracking bug for .25 as it hadn't even built ?
<bjf> yes
<wget> Hi guys. On Ubuntu and derivatives, I noticed that the symbols defined at /proc/kallsyms are all zeroed when read as a standard user, but are the right location when read from root. Do you have applied a patch for that.
<wget> I checked with distributions and even compiled a kernel by myself and noticed all the symbols (or most of them) are readable by a standard user on these distributions.
<wget> You have thus enabled some extra to hide these symbols, noh?
<mwhudson> wget: well, unless it's a config thing
<wget> mwhudson: Mmh ok let's see. I'm gonna compile a 3.13.1 using the same .config.
<xnox> i find it confusing that Tim's launchpad id and declared irc nicknames do not match =)
<mwhudson> apw: \o/
#ubuntu-kernel 2014-02-05
<smb> morning
<ppisati> moin
<smb> ppisati, Hah! One time beat you to it. :)
<ppisati> smb: my bad, these days i'm really slacking... :)
<smb> ppisati, Meh, I really had to work hard to not do the same. :)
<apw> xnox, most peoples don't ...
<xnox> apw: hipsters =)
<xnox> apw: in other news, why is my intel graphics / uefi boot is so flickerfull ?! also is the grub generating a "malevich black square" with "aubergine frame" for you?
<apw> xnox, i don't think my efi boxes do that, though i can check after i have updated
<xnox> apw: hm.... i'll do photographs then, or maybe video cause the boot is fast.
<apw> it cirtainly isn't intentional
<xnox> argh! kernel patch spam! =)
<henrix> heh
<henrix> xnox: just use the 'X-Extended-Stable:' header to solve that spam prob :)
<xnox> henrix: if only gmail had custom header support. and i seem to fail configuring imapfilter to filter stuff inside labels =(
<henrix> xnox: i haven't been using imapfilter for a while, but i'm pretty sure it supported that.  regarding gmail... never used ;)
<apw> xnox, i use imapfilter against gmail labels no problem
<apw> xnox, and i think smb uses it exclusivly
<smb> apw, huh?
 * smb is not on gmail
<apw> oh never mind then, my mixup
<apw> smb, https://bugs.launchpad.net/ubuntu/+source/protobuf/+bug/1276531
<ubot2`> Launchpad bug 1276531 in protobuf (Ubuntu) "ABI regression" [Critical,Fix committed]
<smb> apw, Thanks
<smb> apw, Ok, I also got a desktop back. Though I had to restart lightdm once to get a version which accepts keys... Might be random fluke though. 
 * smb reboots that laptop again
<smb> Hm, again
<smb> Just this time something seems to have unwedged it without restarting
<smb> apw, Do you get something liek that?
<smb> Seems initially not accepting keystrokes in the pw dialog box.
<smb> But when I open and close the reboot menu with the mouse, then the password box accepts keys suddenly (with a bit of an initial lag)
<seb128> hey
<seb128> is there a known issue with linux-image-3.13.0-7 i386 in trusty? my laptop wlan0 (dell laptop, i5) stop being listed after today's update 
<smb> seb128, Did you manually upgrade libprotobuf8? 
<seb128> smb, no, I stayed away from that abi change
<seb128> it makes compiz not start
<seb128> smb, booting kernel -6 makes my wifi work
<smb> Yeah, we went through that
<smb> Hm, not that I know of some wifi issue. What type of wifi hw?
<seb128> it's a dell latitude e6410 with intel card, where can I see the exact model for it?
<seb128> [    9.465536] iwlwifi 0000:02:00.0: Detected Intel(R) Centrino(R) Advanced-N 6200 AGN, REV=0x74
<seb128> smb, ^?
<smb> lspci
<smb> But I think the numbers posted should be enough
<seb128> 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)
<smb> seb128, Is that from the -6 kernel? If so does it show up in dmesg with -7, too or not
<seb128> smb, http://people.canonical.com/~seb128/kern.log
<seb128> smb, the Feb  5 12:32 boot is with -7
<seb128> the 12:35 one with -6
<seb128> smb, I'm at a sprint but I can find an eth cable and reboot on -7 to debug more if needed
<smb> seb128, Ok, let me read through this. 
<seb128> smb, thanks
<seb128> smb, seems like I'm missing linux-image-extra-3.13.0-7-generic if that makes a difference (did some partial upgrade to avoid the new libprotobuf)
<smb> seb128, Ah, so you should really install that
<seb128> smb, sorry for the noise, I'm going to upgrade after lunch (new protobuf should be in) and reboot and see how it goes
<smb> seb128, ok
<rtg> apw, do we have a bug for the CVE patch you applied ? 'x86, x32: Correct invalid use of user timespec in the kernel'
<rtg> hmm, bug #1274754
<ubot2`> Launchpad bug 1274349 in linux (Ubuntu Trusty) "duplicate for #1274754 Fix-compat_sys_recvmmsg-on-x32-archs" [Critical,Confirmed] https://launchpad.net/bugs/1274349
<henrix> rtg: i believe what you're looking for is bug #1274349
<ubot2`> henrix: Error: Could not gather data from Launchpad for bug #1274349 (https://launchpad.net/bugs/1274349). The error has been logged
<rtg> henrix, ack
<apw> bug #1274349    
<rtg> apw, I'm fixing up the commit log for trusty
<apw> a pox on you launchpad
<apw> rtg, to get that one to close ?
<rtg> yep
<apw> not necessary, it is a CVE bug, the tracker will close it
<rtg> apw, is it in the correct format ? it does not look like it to me
<apw> if the cherrypicked from XXX is there it will be handled
<rtg> ah, ok
<apw> the cve-autotriager will see the commit sha1 and move the tracker to 'pending' and 'released <XXX>'
<apw> and that is picked up by the kees scripting which jjohansen1 runs and that closes the bugs
<apw> not that putting it in there as a BugLink: is an issue, it will work just fine
<rtg> apw, I'll push it anyways so it is easier to find the bug from the commit log
<rtg> sforshee, can you give https://bugs.launchpad.net/intel/+bug/1265436/comments/9 a quick test ?
<ubot2`> Launchpad bug 1265436 in intel "Saucy SRU: update firmware for 7260 / 3160 devices (Wilkins Peak) " [Undecided,New]
<sforshee> rtg: sure, let me wrap something up then I'll try it out
<rtg> no rush
<apw> rtg, 3.13.2 is looking like a monster
<rtg> oh, I'm sure. 100+ ?
<apw> 140 already
<rtg> apw, thanks for fixing my upload FTBTS by the way. I just ran out of time to figure it out.
<apw> rtg, np, typical orig tarball carnage
<rtg> ah, that is why my test builds succeeded
<henrix> apw: and it doesn't include all the stable patches from -rc1 ;)
<apw> rtg, yeah, the empty kbuilds i made get lost, i've fixed it in a better way in the tip
<sforshee> rtg: that linux-firmware update was essentially a noop. The 22.1.7.0 files were unchanged, and the new files aren't used by saucy's kernel.
<rtg> sforshee, hmm, I thought it used the .8 API  - perhaps I misremembered
<sforshee> rtg: .8 is only 3.13+
<rtg> ok
<rtg> sforshee, didn't a stable update enable the .8 API ?
<sforshee> rtg: the verification-done tag was already on the bug though, so I'm not sure if I need to do anything so the sru team will know it's been verified
<infinity> apw: Hrm.  Now that lowlatency is in master, would it be a reasonable thing to suggest that maybe we should produce a linux-signed-image-$(ABI)-lowlatency from linux-signed?
<infinity> apw: (And obviously push the required bits to the EFI tarball to make that possible)
<jsalisbury> henrix, Is there a script that builds the kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/linux-3.11.y.z-queue/ ?  Or do you do it manually?
<henrix> jsalisbury: that's the same build scripts used to build mainline kernels
<henrix> jsalisbury: they are built automagically
<jsalisbury> henrix, Do you know the name of it off hand?  I'm wondering how it handles the case of a patch not applying?  Does it just skip it, and then you have to go back and backport or skip it manually?
<henrix> jsalisbury: i believe they are in kteam-tools, in mainline-build
<henrix> jsalisbury: but they use the git tree directly, the scripts don't apply the patches 
<henrix> jsalisbury: they use git://kernel.ubuntu.com/ubuntu/linux.git
<henrix> jsalisbury: (and the corresponding -queue and -review branches)
<jsalisbury> henrix, ack.
<jsalisbury> henrix, Is there a script that updates the linux-3.11.y.z-queue branch?
<henrix> jsalisbury: that branch is updated manually, i.e., that's where i push the patches for the next stable release
<henrix> jsalisbury: this means that the 3.11.10.4 will be what's in that branch ;)
<henrix> jsalisbury: everything from v3.11.10.3 the HEAD in that branch will be included in the next release
<jsalisbury> henrix, Ahh, ok.  So that's where the heavy lifting is done ;-)  So you follow the stable mailing list and apply anything that comes in with the stable cc.
<henrix> yep, correct :)
<henrix> that branch already contains everything you're looking for
<jsalisbury> henrix, cool, now I understand.  Thanks.
<henrix> no prob
<jsalisbury> henrix, so do you actually compile a list of the patches from the stable mailing list, or do you pull in what lands in the stable-queue repo?
<henrix> jsalisbury: i pick patches from linus tree that are tagged for stable (i.e., that contain the 'Cc: stable' on the SOB section)
<henrix> jsalisbury: and additionally, i pick patches from the stable mailing list
<henrix> jsalisbury: let me get you an url...
<jsalisbury> henrix, Ok, so the stable-queue repo(git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git) is just GKH's repo for his kernels?
<henrix> jsalisbury: yep, those the the official stable kernels
<jsalisbury> henrix, ok, got it.
<henrix> jsalisbury: here's a detailed description of the process we follow for stable maintenance (in case you're bored and want to find out more :) )
<henrix> jsalisbury: https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable/Maintenance
<jsalisbury> henrix, awesome, thanks again!
<henrix> jsalisbury: no prob
<henrix> jsalisbury: anyway, if you want to create saucy kernel with the 3.11.10.4 patches, you just need to get them from our stable git tree (with e.g. git format-patch), and apply them on top of the latest ubuntu saucy tree
<henrix> jsalisbury: and this is where some of them may fail to apply (e.g., they have already been included)
<jsalisbury> henrix, Ok, thanks for the info.  Just wanted to understand the way we do upstream stable maintenance.  The wiki you pointed to has all the details :-)
<henrix> jsalisbury: yeah, i guess its all in there
<apw> bjf, how would i figure our which kernel the current 2.6.32 kernel when 12.04.3 was released 
<bjf> apw, mainifest file? don't know if that has the version #
<apw> bjf, it seems that edubuntu doesn't use the hwe kernel
<bjf> huh
<rtg> apw, was that a mistake or a conscious decision ?
<apw> they chose it deliberatly as they have a lot of h/w which is non-pae
<bjf> apw, i'll see if i can tell
<apw> the manifest has 3.8 (raring lts) cause it is the master not the slave arrrgle
<bjf> apw, so you'd have to install the .3 release of edubuntu to know what they used?
<apw> maybe, or someone is confused what it contains
<bjf> i'd think stgraber would be able to tell us
<apw> bjf, sorry yes, and he is over on #ubuntu-release 
<bjf> apw, http://cdimage.ubuntu.com/edubuntu/releases/12.04.3/release/edubuntu-12.04.3-dvd-amd64.manifest says it was raring
<apw> yeah seems the ltps bit is shipped as a damn squashfs so you cannot tell without extracting it, win
<ogasawara> apw: how much to you know about apt?
<apw> some, whatsup
<ogasawara> apw: I've got a question coming from one of our support dudes, which I'm not sure I know the answer
<ogasawara> so....
<apw> forward it over
<ogasawara> apw: ack, thanks
<ogasawara> apw: sent
<apw> ogasawara, got it, thanks
<seb128> smb, I just rebooted, wifi works, so it was my fault for partial upgrading, thanks!
<jsalisbury> apw, I see there is a linux-image-extra package for 3.13.0-6, but I don't see one with "lowlatency" in the name.  Does the lowlatency kernel not need the linux-image-extra package, or does it just use the same one as the -generic kernel?
<rtg> jsalisbury, there is no extras package for lowlatency. 
<jsalisbury> rtg, ok, thanks
<rtg> jsalisbury, the extras package is for the virt server. 
<jsalisbury> rtg, cool. 
<Prf_Jakob> Hey
<Prf_Jakob> We (VMware) would like to backport some hw enablement code to the 14.04 kernel.
<rtg> Prf_Jakob, is this code already in Linus' upstream kernel ?
<Prf_Jakob> rtg: yeah
<Prf_Jakob> I think the wrong version tho
<bjf> Prf_Jakob, are you looking to get it in before the 14.04 release?
<Prf_Jakob> you are going to use 3.13 right?
<rtg> how about sending the list of commits to the kernel team mailing list ?
<Prf_Jakob> That would be nice
<rtg> yep, 3.12
<rtg> 3.13*
<Prf_Jakob> Kay
<Prf_Jakob> Good to know
<Prf_Jakob> I'll let Thomas know
<Prf_Jakob> Where is that list btw?
<rtg> kernel-team@lists.ubuntu.com
<Prf_Jakob> thanks
<bjf> rtg, http://pastebin.ubuntu.com/6880938/ is a kern.log from a CI system that is running apparmor tests on a Trusty kernel
<jjohansen> bjf: which kernel?
<bjf> jjohansen, 3.13.0-7.25
<bjf> jjohansen, the latest
<jjohansen> bjf: okay, I believe I might have the patch for that one
<rtg> jjohansen, 2 occurrences of apparmor="KILLED" have a stack dump right afterwards
<bjf> jjohansen, i'm seeing errors when i run the test but not the same panic that CI is seeing   http://kernel.ubuntu.com/testing/test-results/rizzo__3.13.0-7.25__2014-02-04_22-48-00/ubuntu_qrt_apparmor/results/ubuntu_qrt_apparmor.test-apparmor.py/debug/ubuntu_qrt_apparmor.test-apparmor.py.DEBUG.html
<bjf> psivaa, ^
<jjohansen> bjf: yep, this looks like bug 1268727
<ubot2`> Launchpad bug 1268727 in linux (Ubuntu Trusty) "AppArmor changehat regression in 3.13.0-2.17-generic" [High,Confirmed] https://launchpad.net/bugs/1268727
<psivaa> bjf: thanks
<jjohansen> bjf: patch incoming, its only had light testing
<bjf> jjohansen, it's not my kernel yet :-)
<jjohansen> hehe
<apw> smb, just a heads up stgraber has identified his issue as being 'test bed' related, which kinda hints at a KVM networking issue ... which sounds ominious
<apw> rtg, if you are gonna flip that config over for the lts-backport-raring, there is some machinary we use in lowlatency for that
<apw> smb, heads down, stgraber has found his issue a local MTU issue on his kvm host
<rtg> apw, what are you talking about ? that config option was for trusty
<rtg> the AA config option, I assume
<apw> rtg, i assume it becoming an option so you can turn it on on trusty and off on lts-trusty
<rtg> apw, yep, already done
<rtg> apw, I am gonna upload trusty to fix an AA oops in CI testing. no ABI bump this time.
<apw> rtg, ack
<apw> rtg, these config updates you are doing CONFIG_FOO=n ought to not work, it ought to be putting in # CONFIG_FOO is not set
<rtg> apw, which one in particular ?
<apw> rtg, all of the ones in the rebase script for lts-raring
<apw> lts-TRUSTY
<rtg> apw, no, which config ?
<apw> in the scripty bit where you switch them from y to n, you just make =y into =n, but the format is # XXX is not set for =n
<apw> sed -i 's/CONFIG_SECURITY_APPARMOR_AA3_SEMANTICS=y/CONFIG_SECURITY_APPARMOR_AA3_SEMANTICS=n/' ${DEBIAN_TARGET}/config/config.* ${DEBIAN_TARGET}/config/*/config.*
<apw> and the similar ones above
<rtg> apw, doh! - you're right. I wouldn't have noticed that until this next rebase.
<rtg> apw, actually, that will work when going from =y to =n 'cause updateconfigs is run right after that
<apw> well only if there is a default and it don't then ask, as your =n ought to do nothing, ie be invisible
<apw> i wish =n did work, it would make most of my scripting simpler
<rtg> updateconfigs always rewrites it as '# CONFIG_FOO is not set'
<apw> rtg, i am not sure it does make =n -> not set, i believe it makes as if you have no setting at all
<apw> rtg, which may mean it defaults to n or not
<rtg> apw, I'll check for sure
<infinity> zequence: Will you have a chance to do a quick lowlatency/saucy rebase to pick up the latest changes there?
<zequence> infinity: Sure. I'll look at it first thing tomorrow
<infinity> zequence: Cool, thanks.
#ubuntu-kernel 2014-02-06
<esnyder> hi all. i'm struggling to get crashdump working on ubuntu 13.10 running as a virtualbox guest on a mac. trying to follow https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
<esnyder> i found someone having similar problems at https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1235616
<ubot2`> Launchpad bug 785394 in grub (Ubuntu Saucy) "duplicate for #1235616 Hard-coded crashkernel=... memory reservation in /etc/grub.d/10_linux is insufficient" [Medium,In progress]
<esnyder> anyone have advice for me? should this work, and i need to just keep futzing, or are there known issues?
<ppisati> yaaaaaaaaaaaaaaaaawwwwwnnnn... :)
 * ppisati goes for a lot of coffee...
 * smb joins the cup-ride
<apw> smb, so i have simple-f cause i am on -5
<apw> E: DRIVER=simple-framebuffer
<apw> i'd not see that if i updated you say yes ?
<smb> apw, yep
<apw> ok
<apw> then all is good
<smb> apw, It was the updated kernel that caused me to fight efi-framebuffer (as simple was gone)
<apw> ahh heh
<apw> anyhow when that version hits, i would like to know if that works ok on your radeon box
<apw> or whether i need to fix vesafb
<smb> apw, So I ran with that changed locally and this makes vesafb still load but the idev event has not the primary env var set
<smb> probably what we expect
<smb> Still comes up, got that weird login bug again... but that could be fluke
<apw> well thats something
<apw> rsalveti, hey ... mako, we have just gotten a security team patch set for this kernel, but there is a version just sitting in our PPA for your testing, shuld i just replace it and we reset from there or do you want to do something with it first
<smb> apw, So a qemu uri for virsh is "virsh -c qemu+ssh://<user>@<host>/system
<rsalveti> apw: better to just replace it with the security fix, and rebase the tree with the current changes
<rsalveti> apw: as we're not done yet with android 4.4
<apw> rsalveti, this is bringing in yama not a security fix, so i don't need to drop it on wahts in the archive at all
<apw> rsalveti, i was more thinking shall i update the 4.4 version in the PPA with it
<rsalveti> apw: oh, then yeah
<rsalveti> that would be better
<rsalveti> and easier
<apw> ok ... thanks will do that
<rtg> jjohansen, I don't think the config patch for bug #1270215 is doing the right thing according to the bug reporter.
<ubot2`> Launchpad bug 1270215 in linux (Ubuntu Precise) "kernel 3.13.0-4.19~precise1-generic: no internet via ethernet or WiFi" [High,Confirmed] https://launchpad.net/bugs/1270215
<rtg> bjf, did that Trusty AA oops go away in CI testing ?
<bjf> rtg, don't know for sure http://ci.ubuntu.com/sru/trusty/version/3.13.0-7.26-generic/
<rtg> bjf, is the dashboard accurate now ?
<bjf> psivaa, have you seen that panic with the new trusty kernel?
<bjf> rtg, no, but it tells you that the tests ran to completion and results got posted
<rtg> ok
<psivaa> bjf: not yet, there was a temp archive issue and cobbler in the morning. the tests are running on amd64 machines now. 
<bjf> psivaa, cool thanks
<psivaa> yw, i'll keep you posted if i see that again
<bjf> psivaa, appreciated. you can let me or any of us know in this channel
<psivaa> bjf: ack
<DW-10297> Does anybody know if the kernel in the netboot package for 12.04.4 will finally have support for the Intel I210/I217 NICs?
<DW-10297> those drivers have been available forever
<DW-10297> That would make life soo much easier for folks that have gigantic clusters of boxes with those NICs in them
<apw> DW-10297, if you can tell us what the driver for that is, we can check
<rtg> indeed, we ought to be able to netboot an Intel NIC
<DW-10297> yeah when those nics came out 18 months ago i requested this and i was told to shove it =D
<DW-10297> and several releases of the netboot package came and went
<apw> DW-10297, did you file a bug about it?
<apw> and if so what was the number, so i can see what happeneed to it
<apw> it might have been helpful to test the beta images a couple of weeks ago, then we could have made sure
<DW-10297> Intel(R) PRO/1000 Network Driver - 2.1.4-k in 13.04 sees the target NICs
<apw> what does lsmod say is bound to it
<DW-10297> it says used by 0
<DW-10297> but in dmesg when the kernel starts its indicating that it's using that driver for the NIC
<DW-10297> on a supermicro server board that has Intel Corporation I210 Gigabit (lspci) it uses igb 5.0.5-k (in centos)
<DW-10297> so i guess as long as it has at least 2.1.4-k of e1000e and igb 5.0.5-k (or whatever) it should work fine
<DW-10297> by the way here is the bug that someone else filed for this a lonnggg time ago
<DW-10297> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1182878
<ubot2`> Launchpad bug 1182878 in linux (Ubuntu) "i210/i217 unsupported by igb / e1000e driver in precise" [Medium,Invalid]
<DW-10297> and it was marked invalid
<DW-10297> for no reason
<DW-10297> apparently this should've been fixed in 12.04.3
<DW-10297> but i can confirm it doesnt work
<DW-10297> at least not in the netboot kernel
<DW-10297> even the jan 10 release of the netboot package
<bjf> DW-10297, according to comment 7 of that bug, the person that filed the bug says it is working for him and it's no longer valid
<DW-10297> it might work if you install it from a cd
<bjf> DW-10297, that was done june of last year. if you disagreed, you could have commented on the bug or opened your own
<rtg> DW-10297, it would sure help if you would start a bug and attach a dmesg to it so we can start looking at some specifics. Intel typically has really good support for their drivers.
<DW-10297> its not a problem with intel's drivers, it's that the kernel in http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/ doesn't have the right driver
<rtg> DW-10297, a 3.2 kernel likely _won't_ have the right driver. if you have the same HW as in bug 1182878, then you'll need at least a 3.5 kernel, i.e., 12.04.2
<ubot2`> Launchpad bug 1182878 in linux (Ubuntu) "i210/i217 unsupported by igb / e1000e driver in precise" [Medium,Invalid] https://launchpad.net/bugs/1182878
<DW-10297> rtg: Okay, i'm not arguing that. I'm trying to figure out why the netboot images aren't kept up to date with whats going on in the actual kernel
<DW-10297> I asked #ubuntu-installer, they told me to ask you guys
<rtg> DW-10297, ok, I'm just researching that. I admit I've never net booted 12.04.2
<rtg> in fact, I rarely netboot at all
<DW-10297> its slightly useful in clouds
<DW-10297> I just found it odd that there was just a new release of ubuntu installer netboot on Jan 10 and it still didnt include support for Haswell
<rtg> DW-10297, I'm sure there is a way to do it, but it may require you to configure your own Cobbler or MAAS servers
<apw> it is likely missing from the d-i configuration, the upstream peeps just love to change the names of their drivers for shits and giggles, and then they get lost
<DW-10297> I think Debian 7 may actually have the driver in their installer as well. I can check if it helps
<DW-10297> anyway I will just cross my fingers and hope that the 12.04.4 netboot works =D
<apw> if you could test that and if it does not file a bug against 'linux' (ubuntu-bug linux) and put all the details in it, which driver it is using etc then we might be able to fix it
<DW-10297> i will just see if 12.04.4's install fixes it first, if not i'll try it on debian and see how that goes
<DW-10297> .4 should be out sometime soon i would hope
<bjf> DW-10297, today is the release day for .4
<bjf> DW-10297, and why a bug report before today would have been helpful
<DW-10297> yeah I knew that but i didnt want to be like.. if they ever publish it to the mirrors haha =)
<DW-10297> I guess I just assumed that it would make sense to refactor the kernels used in the installer every once in awhile to add new drivers
<DW-10297> even RHEL does that
<DW-10297> (surprisingly)
<arges> smb: hello
<arges> smb: i'm still unable to reproduce bug 1273386 , i was running those scripts in a loop
<ubot2`> Launchpad bug 1273386 in neutron "Neutron namespace metadata proxy triggers kernel crash on Ubuntu 12.04/3.2 kernel" [Critical,Triaged] https://launchpad.net/bugs/1273386
<arges> smb: i have the devstack setup in a VM i could give access to somebody who may have more experience with setting it up, maybe i'm missing some condition
<smb> arges, I just started to deploy a devstack setup to one of my VMs. In parallel do you want to remind Salvatore we might have better chances with some independent reproducer he said he may provide?
<arges> smb: antoher option is to give him access to the VM to get it set up properly
<arges> smb: cause all we care about is getting a proper crash dump
<smb> arges, Yeah true
<arges> i did get to learn a bit about devstack which was fun : )
<smb> :)
<arges> smb: blah my vm got filled up... need to fix that
<arges> maybe that's why it never reproduced
<chiluk> ogasawara, such charts ... so pretty..  https://wiki.ubuntu.com/Kernel/Support     https://imgflip.com/i/6p4hs
<rtg> chiluk, makes it pretty clean, huh ?
<rtg> clear*
<chiluk> yeah ogasawara did an awesome job.
<ogra_> chiluk, you should try her pizza !
<arges> heh
<ogasawara> chiluk: hehe, "very schedule", "so color"
<rtg> ogra_, that was _my_ pizza by the way.
<chiluk> ogasawara, glad I could make you smile
<ogra_> :D
<ogasawara> rtg: isn't that was great managers do, take all the credit :)
<chiluk> now we just need a translation into japanese
<rtg> jjohansen, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1270215/comments/33
<ubot2`> Launchpad bug 1270215 in linux (Ubuntu Precise) "kernel 3.13.0-4.19~precise1-generic: no internet via ethernet or WiFi" [High,Confirmed]
<jjohansen> rtg: is he using the lts-backport kernel?
<rtg> jjohansen, indeed
<jjohansen> okay, I'll look. I did test that it was working before I sent you a pull request
<Sarvatt> DW-10297, apw: pretty sure http://us.archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/saucy-netboot/ is what you actually want
<rtg> jjohansen, I checked that the config option is 'no' and that he has the right kernel
<jjohansen> rtg: okay, I'm installing it
<Sarvatt> that should be the enablement stack netboot for 12.04.4 there
<Sarvatt> i've never used it but thats what the release notes say at least
<rtg> Sarvatt, but that will give you a saucy user space
<rtg> Sarvatt, oh, nm
<Sarvatt> rtg: it's in precise, they refresh them for the hwe kernels
<Sarvatt> that'd be nice to have on http://cdimage.ubuntu.com/netboot/ eh?
<rtg> Sarvatt, right.
<rtg> I knew that stuff had to bethere somewhere
<psivaa> rtg: bjf: the kernel panic that we saw with trusty kernel in our systems is not occurring with 3.13.0-7.26
<rtg> psivaa, cool, thanks for the note
<rtg> jjohansen, ^^
<psivaa> https://jenkins.qa.ubuntu.com/view/Trusty/view/SRU/ (the green balls knowingly lie because there are test failures in the console logs)
<ricotz> rtg, hi :), are you aware of the broken headers package of the 3.13 precise kernel builds? "linux-headers-3.13.0-7_3.13.0-7.26~precise1_all.deb (5.2 KiB)"
<rtg> ricotz, broken how ?
<ricotz> like being empty ;)
<rtg> checking...
<ricotz> iirc it has been for all 3.13 builds for precise so far
<ricotz> referring too https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages
<rtg> I could swear I checked them once.
<rtg> indeed, totally vacant.
<ricotz> rtg, thanks for looking
<sforshee> smb: do you know if it's possible to get crashdumps out of ec2?
<smb> sforshee, yes ... no
<sforshee> smb: that's too bad
<rtg> ricotz, fixed the headers problem. next upload ought to correct it.
<rtg> guess I'd better check foranything else I've missed
<ricotz> rtg, great :), may i ask when this upload will happen?
<rtg> ricotz, I imagine 3.13.2 will publish today, so we'll likely upload tomorrow
<ricotz> rtg, alright, thanks!
<rtg> apw, I suspect I don't need do_tools_hyperv=true for armhf, right ? (Trusty LTS)
<apw> rtg, right amd64 only, they don't do 32 bit
<rtg> apw, tilting at lttng in trusty
<apw> rtg, heh good luck with that :)
<rtg> apw, I had the most problems with armhf last time. something about the compiler version that it hated.
<apw> deep joy indeed
<apw> rsalveti, ok the updated -mako is built in the ckt ppa
<apw> rsalveti, security would like this added to all your 3.4 kernels, so i would like to spin them all, presumably to the PPA as well?
<rsalveti> apw: yeah
<apw> rsalveti, ok cool, i'll let you know when they are in there
<rsalveti> apw: great, thanks
<apw> bjf, am i right in thinking that we have stables outstanding on saucy and raring? that we didn't respin with those in
<bjf> apw, correct, i only respun with the upstream fix for the critical CVE
<apw> bjf, ta, trying to make sense of the inbalance in the cve tracker
<bjf> apw, is LP all better today?
<apw> bjf, i'd say i have had a regular level timeouts again, so i guess its "ok"
<bjf> ack
<hallyn> anyone here well-versed in the memory cgroup's memory.swappiness contraints?
<hallyn> Documentation/cgroups/memory.txt says you can't set it if you have use_hierarchy set and (a) you're not root or (b) you have children.  Seems like that pretty much means you can't set it if you're using hierarchy, at all.
<hallyn> ok code confirms it... nm i guess
<jsalisbury> cking, just had a crash due to overheat on my x201.  I'm not sure if thermd had crashed or not though.  I'll apply the latest updates and keep an eye on it.
<cking> jsalisbury, i'll email you some more notes on how to tweak this
<hallyn> hm, thermd?  maybe something i could use
<jsalisbury> cking, cool, thanks
<jsalisbury> heh, cool, no pun intended ;-)
<cking> hopefully it will be cool(er)
<zequence> infinity: saucy uploaded, and awaiting build
<infinity> zequence: \o/
<infinity> zequence: Let me score those up so we can get some results.
<arges> rtg: hey
<rtg> arges, yo
#ubuntu-kernel 2014-02-07
<hallyn> sforshee: stgraber: apw: so sadly with this trivial patch http://paste.ubuntu.com/6889340/ I can create an overlayfs container clone, and sort of start it, but I can't write to anything.
<hallyn> oh wait
<hallyn> heh i see why, being silly
<hallyn> right, works fine.  o/  course then we have the memory limit concerns
<hallyn> as for the mknod-if-devicens-restricted idea, that's not feasible without an explicit "this cgroup is now ok" blessing from root.
 * apw yawns mightily
<ppisati> Friday morning
<apw> are you sure ?
<eagles0513875_> hey apb1963
<eagles0513875_> i mean apw
<apw> hi
<rbasak> smb: am I right in thinking that all our kernels support hotplugging on Xen (via xenbus and its block devices)? Is it OK to make it a requirement that our kernel will continue supporting this in the future?
<rbasak> The background here is an attempt to establish a standard for interoperability between distros for VM images in the ARM world. So we want Ubuntu cloud images to work on some other distro's OpenStack deployment, for example, which might be Xen based.
<smb> rbasak, Maybe you could explain a bit more what exactly you expect to work. Adding new devices after boot or unplugging to replace the emulated disks by paravirt ones
<rbasak> Sorry, lost connection.
 * rbasak tries again
<rbasak> smb: am I right in thinking that all our kernels support hotplugging on Xen (via xenbus and its block devices)? Is it OK to make it a requirement that our kernel will continue supporting this in the future?
<rbasak> The background here is an attempt to establish a standard for interoperability between distros for VM images in the ARM world. So we want Ubuntu cloud images to work on some other distro's OpenStack deployment, for example, which might be Xen based.
<smb> rbasak, Maybe you could explain a bit more what exactly you expect to work. Adding new devices after boot or unplugging to replace the emulated disks by paravirt ones
 * smb repeats re-question
<rbasak> smb: AIUI, Cinder expects to be able to hotplug a block device
<rbasak> So adding new devices after boot, I believe.
<rbasak> BTW, my connection is flaky. I may go again :-/
<smb> rbasak, I would have to try that with virsh directly. I think virt-manager refuses to try
<rbasak> smb: this might not be with libvirt necessarily.
<smb> rbasak, what other way would openstack have to talk to xen?
<rbasak> I thought it had a more direct nova driver?
<smb> rbasak, afaik there is none. There was that xapi stuff that basically is gone for the time being)
<rbasak> Oh yes.
<smb> So to my knowledge libvirt is what is used (according to jamespage)
<rbasak> Hmm. I'm not thinking specifically about Ubuntu here though.
<rbasak> It's more in theory for any distro, since the currently proposed spec mandates that guest kernels support both pci(-e?) and xenbus hotplug.
<rbasak> I just wanted to make sure that we won't have an issue with that requirement.
<smb> rbasak, To know whether the whole chain of things work you probably should ask someone from the server team. ;)
<psivaa> jdstrand: bjf: precise kernel sru regression testing for 3.2.0-1630.42 on armadaxp is throwing failure for test_010_proc_maps in our run. 
<psivaa> would you mind taking a look: http://pastebin.ubuntu.com/6890443/
<smb> rbasak, I can do some experiments with libvirt. Though I have not tried to do that before
<fish_> any ideas how I can help fixing/debuggin this issue? https://bugs.launchpad.net/bugs/1275809
<ubot2`> Launchpad bug 1275809 in linux (Ubuntu) "(docker/lxc) container restart causes kernel to lockup" [High,Triaged]
<rbasak> smb: I'm just asking you about the kernel piece :)
<rbasak> smb: am I right in thinking that we have relevant config options turned on?
<fish_> since it's not trivial to reproduce I'm worried that anyone will pick it up :)
<smb> rbasak, We have at least xenbus in there and if there is a way the managing entity can add things there (this would be xm/xl/virsh from dom0) the kernel handles hotplugging of disks in general
<rbasak> smb: I think that's good enough for me - thanks. Assuming you won't want to drop xenbus in the future.
<smb> rbasak, Not as long as upstream does not :)
<rbasak> smb: OK. Thanks :)
<apw> fish_, so you couldn't test 3.14, did you try a trusty 3.13 kernle (which would have aufs)
<fish_> apw: good point, I'll try that
<fish_> apw: should I try 3.13.2?
<fish_> apw: btw, will trusty still contain aufs?
<apw> the trusty kernels including the backports ones do yes, not the mainline kernels
<fish_> looks like 3.13.2 doesn't include aufs
<fish_> apw: hrm, so this one should have it, right? http://packages.ubuntu.com/trusty/amd64/linux-image-generic/download
<fish_> eh, that's just a meta deb
<fish_> http://packages.ubuntu.com/trusty/kernel/linux-image-3.13.0-7-generic <- this one, right?
<fish_> well, I'll just try it
<smb> fish_, You will need linux-headers (all), linux-headers (arch) and linux-image (arch) and linux-image-extra (arch)
<smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-headers-3.13.0-7_3.13.0-7.26_all.deb
<fish_> smb: hrm, but linux-image should be enough if I just need to boot it and see if I can reproduce my issue, right? I'm not building anything against the kernel headers
<smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-headers-3.13.0-7-generic_3.13.0-7.26_amd64.deb
<smb> if there are no dkms packages
<fish_> no, no dkms
<smb> but you need at least the -extra package too
<fish_> for firmware and stuff?
<smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-extra-3.13.0-7-generic_3.13.0-7.26_amd64.deb
<smb> No for most other modules
<fish_> ah okay
<caribou> Is 3.13 still the target kernel version for Trusty ?
<apw> caribou, yes
<caribou> apw: ok, thanks
<fish_> apw: looks pretty good so far
<fish_> apw: system still hasn't crashed
<apw> fish_, well that is encouraging, as that will be the latest LTS backports kernel after the next release
<bjf> psivaa, you only see that on armadaxp?
<psivaa> bjf: for precise, yes.  i have not tested that with pandaboard
<psivaa> bjf: and this was not seen in the previous kernel on armadaxp
<bjf> psivaa, jdstrand let me update my snapshot and put out a new release of the autotests. i know some work was done on that test recently
<psivaa> bjf: just checked an amd64 precise run that just completed and the failure is seen there too
<bjf> psivaa, ack, give me 30 min. to get you a new release
<psivaa> bjf: ack
<bjf> psiva, releae email sent. this updates all the QRT snapshots as well as fixes the issue with the results for the dashboard (i hope)
<rtg> jjohansen, kamal, ppisati: rebooting tangerine for kernel update
<jjohansen> rtg: ack
<stgraber> hallyn: what kind of memory limit concerns for unprivileged overlayfs? does overlayfs actually keep that much stuff in memory instead of storing to the writable layer (which should respect memory quotas if it's a tmpfs)?
<apw> open directory listings, other than that most things occur on the underlying filesystems which is kinda the point
<hallyn> stgraber: that's why i was vague - i remember someone mentioning a concern last week, but couldn't remember exactly what it was
<hallyn> Perhaps I'll send the patch to kernel-list for discussion
<hallyn> really if it's a vfsmounts-in-kernmem concern, we already have that problem with unprivileged bind and tmpfs mounts
<hallyn> in fact, tmpfs mounts are a bigger concern
<stgraber> would be great. I'd very much like to have a final yes/no on this ASAP as we need to update upstream LXC to allow snapshotting and ephemeral containers if we can start using overlayfs unprivileged.
<hallyn> ok will send it today.  all 5 lines :)
<caribou> apw: want me to handle the SRU for bug 1259570 ?
<ubot2`> Launchpad bug 1259570 in linux (Ubuntu Precise) "kexec should get a disabling sysctl" [Medium,New] https://launchpad.net/bugs/1259570
<apw> caribou, tyhicks is working out which ones this is needed for
<caribou> apw: ok, fine thanks
<rtg> apw, I assume we can drop the trusty ppc64el branch now ?
<apw> rtg, from the main repo?  ues
<apw> yes
<rtg> yup
<apw> jsalisbury, one for your "keeping a vague eye on" list: 1277165
<jsalisbury> apw, ack
<rtg> apw, I've set annotations to 'CONFIG_CC_STACKPROTECTOR                       p policy<(arch amd64 i386 armhf &/ value y) | value n>', but I'm still getting enforcer errors.
<rtg> apw, I've pushed unstable
<infinity> rtg: Is this a workaround for toolchains that don't have SSP?
<infinity> rtg: If so, ppc/ppc64el have SSP too, only arm64 doesn't...
<infinity> (arm64 is almost there...)
<rtg> infinity, not according to 3.14-rc1.
<rtg> git grep HAVE_CC_STACKPROTECTOR arch
<rtg> arch/Kconfig:config HAVE_CC_STACKPROTECTOR
<rtg> arch/Kconfig:   depends on HAVE_CC_STACKPROTECTOR
<rtg> arch/arm/Kconfig:       select HAVE_CC_STACKPROTECTOR
<rtg> arch/mips/Kconfig:      select HAVE_CC_STACKPROTECTOR
<rtg> arch/sh/Kconfig:        select HAVE_CC_STACKPROTECTOR
<rtg> arch/x86/Kconfig:       select HAVE_CC_STACKPROTECTOR
<rtg> perhaps more arches will get enabled throughout the series
<infinity> Curious.
<rtg> yeah, seems like a step back
<apw> rtg, did you sort your enforcer errors or are they stull there
<rtg> apw, they are still there. I don't understand that arcane language
<rtg> I'm too stupid I guess
<apw> rtg, ok i'll have a look shortly
<rtg> apw, thanks
<apw> rtg you were mixing annotations and enforcement, need to sort that split out
<apw> rtg pushed something which workes for now
<rtg> apw, hmm, ok
<rtg> apw, are you working on grouper yama ?
<rtg> apw, actually, you should be off drinking a beer by now. go away.
<apw> rtg, grouper == 3.1 yes ?
<rtg> apw, yup, just pushed it
<apw> rtg, tyler was going to do it, but i am sure he won't mind if you have
<rtg> apw, he sent patches on the mailing list
<apw> oh ok, cool.  i am in the midst of uploading the others
<apw> (to the PPA)
<rtg> apw, there is also an interest patch proposal from hallyn on overlayfs that you ought to have a look at
<apw> rsalveti was happy for them to be applied and pushed there
<rtg> interesting*
<apw> rtg, the usespace mount thing one?  i have been having discussions with security about it indeed
<rtg> apw, I'll button up grouper and upload it to the PPA
<apw> rtg, i have the others "in progress"
<rtg> ok
<apw> i'll do them shortly before chugging some beer
<rtg> apw, grouper uploaded
<apw> rtg, ack
<rtg> apw, thats the only 3.1 kernel, right ?
<apw> rtg, yep, maguro was 30
<apw> 3.0
<rtg> cool
<apw> and i hope is dead
<apw> rsalveti, i believe that is all of the touch kernels fixed up with the yama bits i was talking about, and all building/built in the CKT PPA; if you could let us know when you want something else done with them
<rsalveti> apw: great, thanks
<jsalisbury> apw, rtg Do you guys know of a way to get "git am" to format failures similar to when "git cherry-pick" fails?  For example, when git cherry-pick fails, the file it was modifying has a block with the HEAD and what the patch was trying to do.  
<jsalisbury> apw, rtg 
<jsalisbury> A git am failure leaves the file it was modifying unchanged and just lists the patch in .git/rebase-apply/patch
<rtg> jsalisbury, when git am fails I usually just 'patch -p1 < 0*' and then fix it up by hand, then 'git am --resolved'
<jsalisbury> Just looking for an easier way to do a diff to see why it failed
<jsalisbury> rtg, hmm, yeah that sounds like it would help.  Let me give that a try
<jsalisbury> rtg, does 'git am --continue' have the same effect as 'git am --resolved' ?  Seems like it from the man page but just wanted to check.
<rtg> jsalisbury, it might I guess if you are importing multiple patches
<rtg> you might have to --resolved first, then --continue
<jsalisbury> rtg, cool, thanks.
<jsalisbury> rtg, awesome, 'patch -p1 < patchname.patch' actually fixed the issue without me having to fix anything :-)  That's definitively the way I'll do it when I get a 'git am' failure from now on.
<rtg> jsalisbury, patch is a little less anal about context, though you wanna look closely to make sure its done the right thing. you can likely get git am to be a little less restrictive too, but I've always just used patch
<apw> git am -C1 gives you the same as patch
<jsalisbury> rtg, apw, great, thanks!
<bjf> jsalisbury, i do exactly what rtg does
<jsalisbury> bjf, apw, rtg, for context, I'm just practicing turning the crank.  I'm applying the latest 3.11.10.4 patches from henrix's -review branch to a saucy tree.  I'm was just looking for the most efficient way to resolve a patch failure.
<bjf> jsalisbury, i think there are upstream stable release, you could pick one and apply the commits, they all need to be processed
<jsalisbury> bjf, is there a list or way to tell which ones have been done already?  For Saucy, do we wait until 3.11.10.4 goes from the linux-3.11.y-review branch to linux-3.11.y to apply them to saucy master-next?
<bjf> jsalisbury, we don't apply them until they have been "released"
<jsalisbury> bjf, ack
<bjf> jsalisbury, you just go from stable branch/tree to stable branch/tree and see what has been applied in the related ubuntu tree
<bjf> jsalisbury, sconklin and i are the only others that apply them so it's easy enough to know if someone is working on one already
<bjf> jsalisbury, and if we know you are handling it, we'll just stand back and watch :-)
<sconklin> waaay back :-)
<jsalisbury> heh
<sconklin> here, hold my beer
<jsalisbury> bjf, sconklin, so how do I tell which stable release is ready?  Do you get that from one of the mailing lists?
<sconklin> the maintainer announces, and there's also typically a release commit at the tip
<jsalisbury> got it
<jsalisbury> bjf, sconklin, Do you recommend which one I should start with?  I don't want to step on one you've already started.
<bjf> jsalisbury, we're not working on any of them right now
<sconklin> I don't have any in progress
<bjf> jsalisbury, start with precise and work you way through saucy
<jsalisbury> bjf, sconklin So there is nothing to do for Saucy yet, because 3.11.10.4 is still in review, correct
<bjf> jsalisbury, that's what i normally do
<sconklin> jsalisbury: you can always go ahead and apply to master-next. If a release gets held up or respun, everything has to be manually sorted and/or rebased anyway, and what's another few hundred patches, more or less? :-)
<jsalisbury> bjf, sconklin Ok, I'll give precise a go.  I'll push what I do to my git location on zinc and send a pointer for you guys to review
<sconklin> jsalisbury: perfect
<jsalisbury> bjf, sconklin, It looks like the latest 3.2 stable kernel is 3.2.54.  Looking at the Precise master-next branch, it looks like it may have already been applied:
<jsalisbury> e7ebafbdb203bed536102c184198bcf4f8f71d4f Linux 3.2.54
<jsalisbury> I see a tracking bug as well: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1266546
<ubot2`> Launchpad bug 1266546 in linux (Ubuntu Precise) "Precise update to 3.2.54 stable release" [Undecided,In progress]
<bjf> jsalisbury, that's likely. upstream stable for that is benh and there's quite a period between upstream stable releases for 3.2
<jsalisbury> bjf, should I give Quantal a try then?
<bjf> jsalisbury, like i said, i just work through them all to check .. i'm looking at Q right now
<jsalisbury> bjf, ack
<Teduardo> Ah, there was no new netboot image put in for 12.04.4.. bummer
<Teduardo> yes, build a 50,000 node cloud with no nic drivers =)
<Teduardo> you win internets
<Sarvatt> Teduardo: http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/saucy-netboot/
<jsalisbury> bjf, So we apply all the latest upstream updates to master-next.  How do those updates then make it into all the various flavors, or does that all happen by the builder?
<Teduardo> the saucy netboot will install precise?
<Sarvatt> yep, its in precise, uses the saucy kernel just like 12.04.4 does
<Sarvatt> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/raring-netboot/ for 12.04.3, etc
<Teduardo> so if that works why not just make that the netboot image that comes up in the main precise thing
<infinity> Teduardo: "the main precise thing"?
<Teduardo> http://cdimage.ubuntu.com/netboot/ -> click on 12.04
<Teduardo> wouldn't it make sense to put the one with the most driver support right there in front?
<infinity> Teduardo: Right, I was just going to edit that today.  Though "12.04" will still point to the one with the 3.2 kernel, I'm just going to at the HWE kernel options at the bottom.
<Teduardo> so people aren't like.. zomg why doesnt ubuntu support NICs that were released in 2012
<infinity> s/at/add/ .. Brain/finger disconnect.
<Teduardo> So just to be clear, the 'saucy-netboot' in the precise tree, doesn't actually install the 3.8 kernel on OS right? it just uses it during the install?
<Teduardo> the actual kernel that is installed is the regular thing that comes with 12.04.4?
<rtg> Teduardo, yes
<Teduardo> cool, thanks for your help. i get to go home now!
<Teduardo> wheeeeeeeeee....
<infinity> Teduardo: It doesn't use a 3.8 kernel at all...
<infinity> Teduardo: It both boots with and installs a 3.11 kernel.
<infinity> I'm so renaming those images for trusty to be less confusing.
<bjf> jsalisbury, yes, we just update master-next and building multiple arches/flavours from the same branch/repo makes it all work
<antarus> qq, do signed kernel modules require secure boot?
<antarus> or is the kernel using some other model of trust for them?
<infinity> antarus: Not related to secure boot at all, no, it's the kernel that does the checking.
<antarus> infinity: hrm
<antarus> infinity: so for modules built with dkms...
<antarus> signing seems...like it would be difficult?
<antarus> although, building modules on the localhost seems insane if you don't trust localhost
<antarus> so perhaps not so much ;p
<infinity> It's a bit of an unsolved problem, yes.  We discussed this at plumbers a while ago and no one had any bright ideas.
<antarus> well in my proposal users can only run specific kernels, so we could in theory precompile modules for them
<antarus> and sign those
<infinity> You'd need to update the keyring to include your signing key too.
<infinity> Since the signing key we use for our kernel binaries is generated and thrown away during the build process.
<antarus> yeah
<antarus> we will probably be stuck building our own copy of your kernel sources anyway ;p
<antarus> so might as well use our own keys to sign
<infinity> I'd like to solve this more elegantly, so "just rebuild the kernel" isn't the go-to option.
<infinity> But other than that one session at plumbers when we all agreed it was too hard and we'd think about it later, I've not put much thought into it.
<antarus> this is all pie in teh sky stuff right now
<antarus> we have a summit internally in a few weeks
<antarus> and I'm trying to think up ideas that we could do
<antarus> particularly if we started over
<antarus> and aborted the legacy mess we had today ;p
 * marrusl wanders in
<infinity> marrusl: Shoo.
<infinity> marrusl: Whenever you're around, it seems to generate work.
<marrusl> infinity, only "seems"?
<infinity> antarus: So, yes, in a nutshell, the dkms-on-localhost use-case assumes that you trust localhost once it's booted, so you use a local signing key and scream "la la la, this doesn't feel right".  It's the centrally-distributed extra modules use-case that's more interesting (as that can be better locked down), and I'd like to come up with a sane solution for that.
<jsalisbury> bjf, sconklin Just did a bunch of clones to my home systems that I can --reference for future clones :-)
<jsalisbury> sconklin, bjf, I see that Quantal only has up to 3.5.7.27
<jsalisbury> sconklin, bjf, So it looks like it needs 3.5.7.28 and 3.5.7.29 updates.  I can give that a go.
<sconklin> jsalisbury: I generally reference Linus's upstream repo, as the vast majority of everything else is also in there
<jsalisbury> sconklin, bjf Where there are two upstream releases to apply, do we do them one at a time, and create a seperate stable tracker bug for each?  Or can I apply all the patches from each in one shot?
<bjf> jsalisbury, i do what sconklin said
<sconklin> jsalisbury: apply the ones from the upstream maintainer's tree. I usually create a single tracking bug even if there are multiple upstream releases
<sconklin> just make sure that the list of commits in the bug includes all the ones in both upstream updates, and that every commit in your branch has the bug id added
<sconklin> jsalisbury: you know about maint-modify-patch, right?
<jsalisbury> sconklin yes
<bjf> jsalisbury, again i do the same as sconklin
<jsalisbury> sconklin, that makes it easier to do them in one pass instead of two :-)
<sconklin> good. You can expect it to throw errors on patches with unicode in people's names. This should really be fixed in the script but I have been just going back to verify that it did the right thing.
<sconklin> and the way I do that is - say I was adding my SOB. I just "grep -v sconklin *patch" and it'll list any without my sob
<sconklin> You'll know it if you see it :-)
<jsalisbury> sconklin, looks like 200 patches for 3.5.7.28 and 3.5.7.29: 
<jsalisbury> git log --pretty=oneline v3.5.7.27... | wc
<jsalisbury>     200    1773   19309
<sconklin> not surprising.
<sconklin> builds character :-)
<jsalisbury> heh :-)
<jsalisbury> sconklin, do I add my sob when running the 'git format-patch' in the upstream tree, or does the maint-modify-patch do it for me?
<sconklin> I just extract all the patches using "git format-patch -k tag.." and then add SOB and tracking bug number using maint-modify-patch
<jsalisbury> sconklin, got it.  thanks!
<jsalisbury> sconklin, Here's the tracking bug: https://bugs.launchpad.net/bugs/1277722  I'll add the subjects of all the patches.  Going to apply them now, and tackle the failures :-)
<ubot2> Launchpad bug 1277722 in linux (Ubuntu Quantal) "Quantal update to v3.5.7.29 stable release" [Undecided,New]
<sconklin> cool.
<jsalisbury> sconklin, what is the format for --sob when passing it to the maint-modify-patch script?  
<jsalisbury> sconklin, seems to fail for me.  I don't have an .kteam.rc file on my system.  Maybe I need one?
<sconklin> yeah, you have to copy that rc file to your home dir and add your own name/email/nick
<sconklin> you can add those to the kteam-tools sample version of that rc file, too if you want
<jsalisbury> cool, thanks.  Looks like the script told me that, heh: ** Error: No aliases found, the required configuration file may be missing. Copy the file kteam-tools/maintscripts/doc/example_kteam.rc to ~/.kteam.rc.
<sconklin> I think I added that error message in a rage one day
<jsalisbury> sconklin, hmm, I get the unicode warning with the maint-modify-patch script:
<jsalisbury> /home/jsalisbury/src/kteam-tools/maintscripts/maint-modify-patch:253: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
<jsalisbury>   if expanded not in existing_sobs:
<bjf> jsalisbury, just ignore it
<sconklin> yeah, that's the one
<jsalisbury> Ok
<sconklin> you can verify that your SOB was applied to all the patches using grep -v, if you want to double check
<jsalisbury> Yeah, looks like it did the right thing :-)
<jsalisbury> sconklin, do you have a grep or something to pull the subject out of the patches, while dropping the "Subject" text, which I'll put in the bug tracker?  If not, I can figure one out. 
<sconklin> I generally concoct a line something like this in the upstream maintainer's tree:
<sconklin> git log --oneline <tag>.. | cut -b 47- > patchlist.txt
<sconklin> and then I edit that and prepend " * ", or whatever the line beginning should look like (can't remember atm)
<sconklin> adjust the 47 to suit, and you may need other options to git log. Lemme see if I have that in a script
<sconklin> jsalisbury: I apparently have not saved that anywhere
<jsalisbury> sconklin, Ok, I can figure out some sort of grep/awk combo.
<jsalisbury> sconklin, If a patch fails because it's already applied, and I skip it, do I still add it to the bug tracker?
<sconklin> I don't worry about that too much. If I already have the list in the bug I don't bother removing it
<jsalisbury> sconklin, sweet, only two patches failed, and that was because they were already applied :-)
<sconklin> best case scenario.
<sconklin> You're more likely to run into conflicts with older kernels, as there may be patches which conflict with the context because they aren't in the upstream stable tree. That's not common, but it happens, and most of the time, it's only context, and for things like PCI id's in a driver or lists like that
<jsalisbury> sconklin, I came up with this to pull the subject out of all the patch files:
<jsalisbury> cat * | grep Subject: | awk '{first = $1; $1 = ""; print $0}'
<jsalisbury> sconklin, but it seems to drop some subject text if a subject has a carriage return in it
<sconklin> jsalisbury: dunno, I take the text from a git log in the upstream maintainer's tree, not from the patch files
<jsalisbury> sconklin, heh, yeah I guess I could make it easy and just get it from git
<jsalisbury> sconklin, cool, looks like I just need --pretty=%s:  
<jsalisbury> git log --pretty=%s v3.5.7.27... > subjects
<jsalisbury> sconklin, Thanks for all the help!
<jsalisbury> sconklin, I'll finsh up the tracking bug, push to my tree on zinc and send an email with a pointer to you and bjf
<sconklin> awesome! Yeah, git is your friend in a lot of ways, there are a ton of formatting options for logs
<jsalisbury> sconklin, Thanks again!  Enjoy your weekend
#ubuntu-kernel 2014-02-09
<cristian_c> Hello
<cristian_c> I've submitted a bug report (regarding a kernel bug) on launchpad almost two years ago
<cristian_c> recently, the bug status has been set to Triaged and I was told to read this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
<cristian_c> I've read it but I've got some doubts yet. A dev has told me to contact the kernel team for preparing a faultless upstream report
<cristian_c> 1) Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
<cristian_c> I've tested the 3.14-rc1 kernel too
<cristian_c> 2) While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
<cristian_c> there is a regression compared to previous kernels I've tried
<cristian_c> this is not the original bug anymore
<cristian_c> What can I do? Any ideas?
#ubuntu-kernel 2015-02-02
<eren> I've compiled ubuntu-vivid kernel, I successfully booted it and I now have debug symbols at /usr/lib/debug/. when i try to use iperf with -k /usr/lib/debug/boot/vmlinx... option, it reports vmlinux cannot be used
<eren> sorry, iperf = perf
<eren> I compiled perf in tools/perf/ directory, btw
<eren> oh sorry, it was compiled without drawf support, my bad
<eren> just installed required dwarf libs and it's now ok :)
<ChrisP1948> Since kernel version after 3.13.0-35 my system has been hanging after about 1 1/2 days with kernel: [106482.820016] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle at first I thought it was totally locked up but on further inspection I noticed that all background processes continued to run. I've filed two bugs, one on Launchpad and added to another at freedesktop.org, https://bugs.launchpad.net/
<ChrisP1948> ubuntu/+source/linux/+bug/1402331 and https://bugs.freedesktop.org/show_bug.cgi?id=75394. 
<ubot5> Freedesktop bug 75394 in DRM/Intel "System hangs randomly with error message: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Critical,Needinfo]
<ChrisP1948> For the Ubuntu report I've been asked to do a 'kernel bisection' I've got the directions but really not sure still after reading how to go about it.
<tseliot> apw: the nvidia packages that I'm going to upload soon seem to be working fine with 346. I need to figure out a few more (unrelated) details before I upload though
<apw> tseliot, rocking 
<tseliot> :)
<hallyn> sforshee: hey, just checking, has there been any discussion anywhere about your ext4-userns patchset?  
<sforshee> hallyn: I haven't posted them yet, I'm currently in the process of auditing vfs and lsm code to find everything which needs to be change there.
<sforshee> I hope to have something fairly well tested later this week
<hallyn> sforshee: cool.  i'll play as soon as you say they're ready :)
<sforshee> hallyn: I'll welcome the testing :-)
<sforshee> just lots of nooks and crannies to go through
<hallyn> sforshee: maybe i'm too tired for this, but how do you use them right now?  you pass loopback into the userns?
<sforshee> hallyn: yep, I make a loopback device and bind mount it into a container
<hallyn> ok, so if this goes anywhere i guess it may become rationale for a real loop fix
<hallyn> thanks sforshee - ttyl
<ChrisP1948> I need to build kernel version 3.13.0-35 so I can run a kernel bisection to try and debug this issue I and others are having. In the instructions for building a kernel is says "sudo apt-get build-dep linux-image-$(uname -r)" do I put the version I want to build in place of uname-r?
#ubuntu-kernel 2015-02-03
<TJ-> ChrisP1948: I guess you figured it out by now
<aeoril> ChrisP1948: aeoril@ubuntu:~$ echo $(uname -r)
<aeoril> 3.13.0-32-generic
<ChrisP1948> I know this is the kernel I'm running 3.13.0-45-generic but I need to build 3.13.0-35 and go from there to find where this bug has been injected
<ChrisP1948> Think I've got it now, thanks
<Free99> Hello all. I tried building a 3.18.4 kernel with no patches on my ubuntu 14.04 system after copying the latest 3.13 config into the kernel directory
<Free99> Everything goes great right up until X needs to startup
<Free99> I have an intel HD4400 powered laptop, with an external display connected via displayport
<Free99> does anyone have any idea on how to fix the X server crashing?
<Free99> Xorg.0.log says that "screens were found, but none have a useable configuration"
<apw> Free99 (N,BFTL), I think your config is likely too old for that kernel, perhaps try the one from utopic or vivid
<smoser> apw, does my request at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1415634 seem like complete nonsense ? 
<ubot5> Launchpad bug 1415634 in linux (Ubuntu) "RFC: replace linux-virtual with linux-server / tune kernel packages" [High,Confirmed]
<smoser> i'm looking for finger-in-the-wind guess as to size of a "linux-server" that had reasonable hardware support.
<apw> smoser, calling that discussed :)  and we'll get together to eval same
<smoser> yp
<smoser> yep
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ChrisP1948> Still having issues with building 3.13.0-35 which is the last kernel that did not cause the system to 'freeze' with this error kernel: [106482.820016] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle. Using this command sudo apt-get build-dep linux-image-3.13.0-35-generic which is found at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel it downloaded 3.13.0-45 the newest instead of *-35. How do
<ChrisP1948>  I get *-35? 
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 10th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<ChrisP1948> Note-on my previous question about building kernel 3.13.0-35 I've already filed a bug report on this issue https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402331 and have been asked to do a kernel bisection which I'm attempting to do
<ubot5> Launchpad bug 1402331 in linux (Ubuntu) "System will periodically lockup with [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Medium,Incomplete]
<ChrisP1948> There has also been one filed here - https://bugs.freedesktop.org/show_bug.cgi?id=75394
<ubot5> Freedesktop bug 75394 in DRM/Intel "System hangs randomly with error message: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Critical,Needinfo]
<eren> I need to bisect the kernel and I am only interested in bnx2x driver. Is it possible to only build modules in ubuntu kernel git repository?
<ChrisP1948> Curious if no one has an idea as to what I'm doing wrong in my earlier post about trying to build kernel 3.13.0-35
<apw> ChrisP1948 (N,BFTL), you are asking for the build-deps for linux, not for the source for that version... so you get the latest bits
#ubuntu-kernel 2015-02-04
<ChrisP1948> Using this command sudo apt-get build-dep linux-image-3.13.0-35-generic which is found at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel it downloaded 3.13.0-45 the newest instead of *-35. How do I get *-35? I need to bisect *-35 as it's the last good kernel before I stated having issues reported at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402331
<ubot5> Launchpad bug 1402331 in linux (Ubuntu) "System will periodically lockup with [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Medium,Incomplete]
<apw> ChrisP1948 (N,BFTL), you are asking for the build-deps for linux, not for the source for that version... so you get the latest bits
<apw> as you are never there to hear the answer, and indeed are not reading backscroll, i am sure you will not see this either
<shadeslayer> So, I'm using overlayfs and I'm seeing weird errors like failed to whiteout 'CMakeLists.txt
<shadeslayer> any ideas how I can investigate what's going wrong
<apw> shadeslayer, on what version of the kernel
<apw> shadeslayer, what exact string
<shadeslayer> apw: moment
<shadeslayer> apw: Linux rassilon 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<shadeslayer> [ 1288.304277] overlayfs: ERROR - failed to whiteout 'CMakeLists.txt'
<shadeslayer> that's one of many strings it's failing on
<apw> shadeslayer, how full is the upper layer
<apw> shadeslayer, and is this on the livecd use case, or on a post install overlay
<shadeslayer> apw: it's on a AWS EC2 instance
<shadeslayer> I'm mounting a jenkins workspace dir inside a schroot using this script : http://paste.ubuntu.com/10056383/
<shadeslayer> and : /dev/xvda1      493G  131G  341G  28% / < seems like there's plenty of space 
<Free99> Hello all, I have ubuntu 14.04 running on an HP Revolve 810 G2. Having an issue where the stylus moves only diagonally no matter where the stylus actually is on-screen.
<apw> shadeslayer, and what are you doing to the upper layer which is failing ...
<Free99> I was able to fix the issue by compiling a kernel but editing a line in hid-input.c to force it to be relative vs absolute
<Free99> downside is, it messes up X autodetection pretty badly
<apw> shadeslayer, and ... could you file a bug "ubuntu-bug linux" and shove all this detail in it, so it doesn't get flushed
<Free99> any idea on how to do this fix on a regular ubuntu kernel?
<shadeslayer> apw: ok
<apw> shadeslayer, shove the bug # in here for me, so i can think about it
<shadeslayer> apw: I /think/ it's the underlying cause for http://dci.pangea.pub/job/plasma/job/kservice_source_unstable/13/consoleText
<apw> Free99, if you have a way to make it work like that, again a "ubuntu-bug linux" to get the h/w details, and put as much detail in it ... then we can look and see if we cna make it work for you and not break everyeone else
<Free99> ok, sure thing apw
<Free99> apw by the way I upgraded my kernel to utopic, but this still applied on 3.13-x as well
<Free99> think that'll be an issue?
<apw> Free99, if it affects the one you are reporting against, no that is fine
<shadeslayer> apw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418123
<ubot5> Launchpad bug 1418123 in linux-lts-utopic (Ubuntu) "overlayfs fails to whiteout CMakeLists.txt" [Undecided,New]
<shadeslayer> apw: do you need anything else?
<apw> shadeslayer, will update the bug if not
<shadeslayer> apw: cheers
<shadeslayer> I'll just redesign my schroot setup
<Free99> apw, https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418130
<ubot5> Launchpad bug 1418130 in linux-lts-utopic (Ubuntu) "Kernel doesn't respond to stylus properly" [Undecided,New]
<Free99> apw thanks for the advice
<Free99> question though: if I build something with DKMS, will it follow through kernel upgrades?
<Free99> I ask because of https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418134
<ubot5> Launchpad bug 1418134 in linux-lts-utopic (Ubuntu) "Alps TouchPad not recognized by kernel" [Undecided,New]
<apw> Free99, should do
<Free99> apw you mean it ought to follow kernel upgrades, or that first bug report was detailed sufficiently?
<apw> Free99, i mean dkms would get rebuilt for each kernel upgrade
<apw> Free99, not looked at the bug yet
<Free99> apw great, just trying to clarify what you meant :)
<Free99> thanks again
<kfir> Hello, i'm developing a small kernel module and i'm getting the following error: module verification failed: signature and/or  required key missing How can I bypass this for my module?
<blahdeblah> Hi all, is there a PPA or similar repo for tracking mainline builds? I'm currently on 3.19.0-031900rc3-generic trying to see if it solves https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1384342, and I'd prefer to keep tracking those builds for now.
<ubot5> Launchpad bug 1384342 in linux (Ubuntu) "kernel messages intel_crtc_wait_for_pending_flips correlate to compiz hang" [High,Triaged]
<blahdeblah> I had a read through https://wiki.ubuntu.com/Kernel/MainlineBuilds and it seems to say that it's necessary to track http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D and manually install - is there an alternative?
<kees> so... anyone around familiar with UEFI -> kernel path? Does UEFI call startup_64 or startup_32 when loading the kernel?
<kees> I guess I mean shim and grub...
<apw> kees, it calls a specific efi entry doesn't it ?
<kees> apw: unclear to me. doesn't Ubuntu's UEFI thingy call shim, which calls grub, which calls the kernel?
<apw> kees, yeah, but it either calls "as normal" when not secure i think, and calls a special entry with boot services "available"
<kees> efi_pe_entry in the kernel seems to call startup_32.
<kees> oh hm, there's also efi64_stub_entry
<apw> kees, yeah there is two of 'em
<kees> I'm investigating a report of a corner case of a corner case... XD isn't enabled on some person's machine, and I'm looking at paths where that could happen.
<kees> it looks like any 64-bit kernel entry points skip fixing XD, since paging has already been started.
<kees> I wonder if 64-bit could drop to 32-bit temporarily, fix XD, rewrite the page tables, and switch back....
<apw> ugg, nasty
<cristian_c> apw, I've collected the info in kernel.org format
<cristian_c> apw, as requested
<cristian_c> apw, I'd like to know if they are correct
<cristian_c> I ca paste them on pastebin
<cristian_c> *can
<mjg59> kees: The answer is "it depends"
<mjg59> kees: "linux" will call startup_32
<mjg59> "linuxefi" will call either the 32 or 64 bit offset in the stub, depending on the architecture of the firmware
<kees> mjg59: yeah, it sounds like I need to move this code into the common boot path
<kees> mjg59: and I don't think it'll require a 64->32->64 to do it. a TLB flush should DTRT...
<mjg59> kees: So the current situation is that jumping into the 64 bit EFI stub skips XD?
<mjg59> Or just startup_64?
<kees> mjg59: all the non-32-bit paths skip the bit of code I wrote to fix broken BIOSes that mask out XD support.
<kees> ("XD_DISABLE")
<kees> mjg59: so if you have a 64-bit boot on an especially crazy BIOS, you don't get NX support. :(
<mjg59> kees: Oh, ok, so in the common case it's fine. That makes sense.
<kees> yeah, in the common case, the boot loader did all the right things when setting up paging.
<kees> but some seriously brain-dead boot firmware out there is setting XD_DISABLE _and_ booting 64-bit. O_o
<mjg59> grub doesn't set up paging in the linuxefi case
<kees> in the 32-bit efi boot case? right.
<mjg59> 32 or 64
<mjg59> That gets left up to the kernel
<kees> AIUI, 64-bit boot requires an identity mapped paging setup before starting the kernel.
<mjg59> Either that's getting set up by the EFI boot code in the kernel, or that's what the firmware is setting up
<mjg59> grub never touches page tables in the linuxefi case
<kees> right, if the boot firmware loads grub in 64-bit mode it must have set up identity mappings too
<kees> (i.e. grub doesn't need to)
<mjg59> Yeah
#ubuntu-kernel 2015-02-05
<tjaalton> I'm debugging a weird swap issue on my main desktop, where the swap is fully allocated not long after a fresh reboot though smem shows it's not the apps using it
<tjaalton> so I wonder if btrfs is to blame, I have a four disk raid on it
<tjaalton> swapoff takes an eternity, making shutdown really slow
<tjaalton> running vivid
<tjaalton> but it was the same on trusty too
<tjaalton> the box has 16GB of ram, and usually ~10G is for cache
<tjaalton> so there's plenty of ram to use
<tjaalton> swap is only 4G, running swapoff now and it's halfway done and cache amount has not changed
<tjaalton> um, actually it increased, free ram is constantly around ~160M
<tjaalton> guess I'm better off without swap, disabled it for now..
<nemo> So... Nexia, someone who plays the game I help dev (Hedgewars) has a card that is an rt5390
<nemo> When he reluctantly reboots to ubuntu from Windows, he gets disconnected all the time
<nemo> I found several bugs and forum threads from 2013 indicating a patch exists that fixes the 64 bit support in the driver...
<nemo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173759/comments/14  for example
<ubot5> Launchpad bug 1173759 in linux (Ubuntu) "Ubuntu 13.04 can detect wi-fi but can't connect" [Low,Expired]
<nemo> (that link is corrupted btw)
<nemo> the patch link is good though, so I'm hoping it works on ubuntu's version of the driver
<nemo> so... I was wondering. since he clearly has a semi-functional card now in 2013, did this patch never make it upstream?
<nemo> or is it only an incomplete fix?
<nemo> BTW, all the bugs I could find in launchpad were closed for various reasons like "inactivity" or "the laptop you happened to report this against was recalled (even though the card is common enough)"
<nemo> er. s/now in 2013/now in 2015/
<Aram> Hi: 
<Aram> dpkg-deb: building package `linux-image-3.19.0-rc6-uprobes-dbg' in `../linux-image-3.19.0-rc6-uprobes-dbg_3.19.0-rc6-uprobes-1_arm64.deb'.
<Aram> It's been 40 minutes now and it's not finished. There doesn't seem to be any file I/O on the generated file. Is it stuck? What to do?
<Aram> Thanks.
<Aram> dpkg-deb uses 100% CPU.
<Aram> straceing it looks liek it's doing lots of 4k reads and writes
<Aram> oh, it either finished or my attempts to debug it killed it
<Aram> it generated a 330MB file
<data> hi, did something in the build process change between 3.16.0-28 and -29? My servers do not boot with -29 due to not being able to mount the rootfs, and the busybox rescue does not have the necessary drivers to support iDRAC or a USB keyboard
<Aram> ok, so my arm64 machine does not boto with this kernel
<Aram> boot
<Aram> http://sprunge.us/OfFV
<Aram> I don't see any output from the kernel
<apw> data, not knowingly
<apw> nemo, if someone can test, then you should (sadly) file a new bug with "ubuntu-bug linux" and add the info on the patch to that, and we can get someone to build a test kernel for it.  do paste the new bug number here.
<apw> Aram, no idea what that kernel source is, nor whether i would expect it to boot ubuntu
<Aram> it's an experimental patch that implemented uprobes on arm64, but that is not very relevant as I tried with vanilla kernel too, and that doesn't boot either on this machine.
<Aram> and that boot log is complete, there is no kernel output at all.
<Aram> I also tried earlycon= options
#ubuntu-kernel 2015-02-06
<Free99> Hello all. Is it normal that I cannot spoof my Wifi MAC address?
<Free99> I'm using network-manager on my 14.04 desktop
<cristian_c> tseliot, I've collected the info in kernel.org format
<cristian_c> tseliot, as requested
<cristian_c> tseliot, I'd like to know if they are correct
<cristian_c> tseliot, I ca paste them on pastebin
<cristian_c> *can
<tseliot> cristian_c: what was the problem with the kernel?
<cristian_c> tseliot, I've posted a bug report on launchpad
<cristian_c> tseliot, I should open an upstream report
<cristian_c> and also a regression report
<tseliot> apw: ^^
<cristian_c> tseliot, so, before opening the upstream report, I should show you if the information collected (following the ubuntu wiki) are correct
<cristian_c> for kernel.org format
<dikzy> hi this is dikzy, i wanted to know if AODV-UU works for kernel 3.13.* ?
<apw> dikzy (N,BFTL), the project page is not at all clear on the subject i am afraid
<cristian_c> apw, can I paste the information collected?
<apw> cristian_c, which information for what?  is it in the bug?  if so what bug was that?
<cristian_c> apw, I've collected the info in kernel.org format, as requested
<cristian_c> apw, I'd like to know if they are correct
<apw> cristian_c, pastebinit perhaps
<cristian_c> apw, before opening an upstream report, I collected the info described to the ubuntu wiki page
<cristian_c> apw, ok
<cristian_c> apw, http://pastebin.com/TVmxXzUZ
<dikzy> hey , can anyone tell me does AODV-UU work with kernel  3.13.*?
<nemo> apw: mmm was afraid of that. shame one of the many others can't just be reopened, since, well, they already have people on the watch list who would be perfect for testing
<nemo> apw: esp since the close reasons weren't very good
<apw> nemo, feel free to point those bugs at it indeed, bot trying to separate, just to have clean history for this fix
<nemo> well. trying to get the guy suffering from it to actually file the bug
<nemo> I've been poking him about it repeatedly.
#ubuntu-kernel 2015-02-07
<kees> so, interesting thing I noticed with 3.16: unix sockets now appear to be "vulnerable" to an old socket issue where write(); close(); may lead to losing the last write's data.
<kees> so clients talking to servers that send data and immediately hang up may not see the entire data written. (this manifested for me in cyrus-sasl2)
<kees> e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777349
<ubot5> Debian bug 777349 in cyrus-sasl2 "intermittent "size read failed" (clients can lose response data from server)" [Normal,Open]
#ubuntu-kernel 2016-02-08
<apw> zkanda, which series are you trying to run it, what is your root disk stored on?
<zkanda> apw:  model is UX501VW, the root disk is on one for the partition. But have a weird naming scheme. Not the usual sda.
<apw> zkanda, what does you disk get named as ?
<apw> and which series of ubuntu are you installing on it
<zkanda> Wait, let me look at it.
<zkanda> apw: disk get name as something like  this: nvme0n1p2, latest 15.10 ubuntu.
<tjaalton> you'd need newer initramfs-tools
<tjaalton> nvme module location changed, so 4.4 and up won't boot since the initrd doesn't include it
<zkanda> tjaalton: How do I do that? Just a link where I could follow is good. Searching didn
<zkanda> 'didn't yield good information.
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1524879
<ubot5`> Launchpad bug 1524879 in initramfs-tools (Ubuntu) "initramfs-tools, Xenial is missing NVME kernel driver" [High,Fix released]
<tjaalton> apw: looks like it regressed something
<apw> tjaalton, do we know zkanda is even running xenial ?
<apw> zkanda, what version of initramfs-tools is installed on your system (dpkg -l initramfs-tools)
<tjaalton> apw: using mainline kernels on any release has the same bug
<tjaalton> it's 15.10
<tjaalton> mainline kernels 4.4 and up that is
<apw> tjaalton, right .. then then we would expect mainline 4.4 to not work on anything before 16.04
<tjaalton> yep
<zkanda> Ok, any advice what should I do from this? Sorry I'm not too familiar on how this things work. :(
<tjaalton> you could just modify the hook manually
<apw> i suspect that is the "simplest" as you are unlikely to be able to install initramfs-tools from xenial without a bunch of pre-requisites
<apw> i seem to remember merging up a bunch of stuff to make that work
<zkanda> tjaalton: How do I do that? Don't know how hook works.
<zkanda> Can I just try Xenial Alpha then? Would that work? I actually tried the Xenial Mate, but it didn't boot either.
<zkanda> I forgot the actual error when trying it out though.
<tjaalton> edit /usr/share/initramfs-tools/hook-functions, add what's on the first comment on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807000
<ubot5`> Debian bug 807000 in initramfs-tools "initramfs-tools: module nvme not included in block modules on kernel > 4.2" [Normal,Fixed]
<tjaalton> then run update-initramfs -u -k all
<apw> tjaalton, i don't think they want to us -k all
<apw> until they know they ahve done _one_ right
<tjaalton> 4.2 still boots
<tjaalton> or -k $whatever
<tjaalton> dunno what it would be for some random mainline
<zkanda> Ok, I'll try that later, still at work so I can't experiment around. haha
<xnox> apw, we really should backport that change.... all the way back to trusty?
<xnox> apw, are we doing kernel-lts-xenial for trusty?
<apw> xnox, yes, we are, infact vrey much now ...
<apw> xnox, i'll file a bug for that now ... as it owuld be a pre-requisite for that indeed
<apw> xnox, i've added a task to LP: #1524879 ... note the fix got refixed in a later upload, anyhow will put it on my todo
<ubot5`> Launchpad bug 1524879 in initramfs-tools (Ubuntu Trusty) "initramfs-tools, Xenial is missing NVME kernel driver" [High,Triaged] https://launchpad.net/bugs/1524879
<zkanda> tjaalton: That didn't seem to fix the issue, disk still not found
<tjaalton> zkanda: did you run update-initramfs?
<zkanda> Yes I did.
<zkanda> Note this is kernel 4.5
<tjaalton> doesn't matter
<zkanda> tjaalton: is there anything I can look to verify that the nvme module is updated?
<tjaalton> zkanda: unpack the initrd to see it's there. if it isn't you didn't fix hook-functions enough
<jjohansen> apw: So the lockinng patchbomb, is at git://kernel.ubuntu.com/jj/ubuntu-xenial.git patch-bomb
<jjohansen> It has the mount patch that tim reverted with a fixup: patch for it that fixes an rcu locking problem that the original patch had. I haven't folded that fixup in yet so you guys could easily see the diff
<apw> jjohansen, ack
<jjohansen> I haven't managed to get to cleaning up the full queue yet, there are several fixups that need to be folded into other patches a few bug links to add etc.
<jjohansen> apw: if you want to just pull the mount patch + fixup, its the 2nd and 3rd patches in the queue
<jjohansen> the 1st one is for a minor mount auditing issue
<jjohansen> the audit patch does slightly change the mount sleep fix patch, I should have probably changed the ordering
<jjohansen> apw: its passed my testing but I haven't run stgraber's tests nor have I tested on anything but amd64 yet
<apw> jjohansen, 39 patches, ugg
<rtg> jjohansen, wow, you want all of these ?
<apw> you've got a lot of unannotated titles in there (no apparmor prefixes) is that expected ?
<jjohansen> apw: like I said I need to clean it up yet
<apw> jjohansen, oh ok ... rtg ^
<jjohansen> rtg: sadly yes, its all backported fixups to locking and ref counting, and fallout around it
<jjohansen> it fixes kees's bug
<apw> rtg, if we applied the cleaned version to something and uploaded it to unstable, we could get the adt tests for lxc etc run against it
<rtg> jjohansen, well, we can wait until you are ready. no use in doing this twice.
<rtg> apw, yeah, could do that
<jjohansen> rtg: if you want we could cherry-pick out the mount patch + its fixup and just apply that atm,
<rtg> jjohansen, that is the one causing problems right now, correct ?
<jjohansen> rtg: yes, its the fix you reverted, patch #3 is a fixup to that patch
<apw> sounds like we should take that one for master-next, and shove the whole thing on a test kernel
<rtg> jjohansen, 'fix-up: kern_mount fail path should not be doing put_buffers()' I presume
<jjohansen> rtg: yes
<jjohansen> rtg: give me a minute to rebase the patch series, as it stands patch1 causes a conflct with #2 and #3 so you can clean cherry-pick them
<rtg> jjohansen, yeah, I was just noticing that
<rtg> jjohansen, just holler when you are ready
<jjohansen> rtg: ok repushed with -f , the mount patch and its fixup are now the 1st and 2nd patch in the queue, and the old patch #1 gets completely dropped because it turns out to be superfluous with the reorder
<rtg> jjohansen, got it. I'll upload the whole pile to our unstable PPA for some testing.
<rtg> and cherry-pick just the 2 for master-next
<jjohansen> rtg: okay, thanks. I'll work on cleanup the commit messages and folding some of the patches together. No point in keeping fixups to patches in the queue
<jjohansen> that is fixups separate
<rtg> jjohansen, agreed
<rtg> jjohansen, in fact, would it hurt if I just squashed those 2 ? it might prevent a bisect problem for jsalisbury  sometime in the future.
<jjohansen> rtg: no, I would squash them, I just kept them separate so you and apw could see what the fix was
<rtg> cool
<jdstrand> ogasawara, cking: thanks!
<cking> jdstrand, my pleasure, I'll wait to see what the upstream developer thinks
<jdstrand> cking: ack. let me know if you need anything
<cking> jdstrand, ok, I may ask you to test the fix at some point
<jdstrand> sure thing
<manjo> rtg, when I cross build on tangerine for arm64 .. /lib/modules/$(uname -r)/build/scripts/<blah> are all built for x64 .. is there a way to force to build everything arm64?
<rtg> dpkg-buildpackage -d -aarm64
<manjo> yep that was my cmd line 
<rtg> manjo, within the right chroot ?
<manjo> yeah within xenial chroot 
<manjo> wily/xenial does the same thing 
<rtg> manjo, you could try '/usr3/ubuntu/kteam-tools/buildscripts/ukb-make --release=$RELEASE --arch=$ARCH --branch=$BRANCH --clean --repo=`pwd`'
<rtg> which is how I do all of my builds
<manjo> rtg, so I don't need to dchroot blah .. just run this on the pwd ie kernel source 
<rtg> yup
<manjo> what is branch ? 
<rtg> the branch in your local repo. I assume you are developing on master
<manjo> ah yes master 
<manjo> so if I drop --branch it would use master ? 
<rtg> manjo, can't remember
<manjo> ok I will figure out 
<manjo> rtg, oops that script won't work if I did a dpkg-source -x extract of a dsc ... 
<rtg> manjo, only works from a repo
<manjo> rtg, do you have an arm64 cross compiled headers-generic  package I can use? I want to see if your script builds stuff under linux/scripts correctly
<manjo> rtg, I think that makefile might not support cross compile flags 
<manjo> probably that is the right thing to do ie build those x64 when you are building on x64 ?
<rtg> manjo, y'all ain't makin' no sense to me - wtf are you trying to do ?
<ogra_> dont you need to set ARCH= and CROSS_COMPILE= too ? 
<manjo> âº there are a bunch of tools under linux/scripts/*.c which gets built as x64 when I cross compile for arm64... from looking that makefile May be it does not support cross compile
<manjo> and it could be the right thing to do ie .. build them for the native platform coz some of theose tools are used for the build itself 
<ogra_> iirc "dpkg-buildpackage -d -aarm64" isnt enough
<rtg> I've specifically disable tools generation when cross compiling. its just too much of a PITA
<ogra_> yeah, the deps will bite
<rtg> manjo, if you want tools, then you'll have to upload to a PPA for a native build
<manjo> yeah that is a PITA âº coz it takes like 3hrs on native PPA 
<rtg> I can't help that
<ogra_> get a dragonboard ;)
<manjo> I know .. just saying 
<rtg> jsalisbury, are you pursuing bug #1540731 with upstream now that you've identified the regression ?
<ubot5`> bug 1540731 in Mir "SocketMessenger::update_session_creds() fails to get client PID, causing "[ FAILED ] PromptSessionClientAPI.client_pid_is_associated_with_session" on kernel 4.4 (but kernel 4.3 works)" [Critical,Confirmed] https://launchpad.net/bugs/1540731
<jsalisbury> rtg, yes.  I have an email to respond to
<jsalisbury> rtg, and there is a new patch to replace the revert, so I can get it tested
<rtg> jsalisbury, cool
<melodie> hello
<melodie> I am looking for hardware supported info, especially the Intel CPU Skylake : either i5 or i7 (4 brands AFAIK)
<melodie> I read here: http://www.phoronix.com/scan.php?page=news_item&px=intel-skl-prelim-support
<melodie> it's of last summer, how is it now?
<melodie> can we have accelerated/3D and all working well?
<melodie> I have to help someone build the specs of his new machine and his favorite distro is Kubuntu. He does current office work and reworks his pictures (gimp mostly). He wants it to be very snappy. (the machine will have 8 GB ram to start with)
<melodie> what do you think?
<melodie> no one around at this time, for insights about hardware?
<Pithegorus> hye how do i customize ubuntu kernel?
<melodie> KillerSingam by recompiling it
<melodie> hi garrettr 
<melodie> do you have knowledge about the intel CPUs and the kernels available at Ubuntu? I'm told that for a i5 or i7 Skylake I would need a Xenial  and I wonder if there is another way to get a 4.3 or 4.4 kernel image in let's say, Wily?
<melodie> I have to provide a machine to a friend who uses Kubuntu (and a good machine)
<melodie> he knows not about hardware and software, but I have to give him the best and stable possible because he also uses it for his work
<melodie> what do you think?
<melodie> (I asked around here one hour ago, and no answer so far)
<KillerSingam> how do i recompile my kernel
<melodie> KillerSingam you seek for the documentation first
<melodie> https://help.ubuntu.com/community/Kernel/Compile
<melodie> thanks to Qwant, the search engine. ;)
<KillerSingam> qwant?
<melodie> https://www.qwant.com/
<melodie> yes, I've qwanted for you
<KillerSingam> can i use that qwantum  for my girlfriend?
<melodie> this is not a bouquet of flowers, nor a perfume. It's a search engine
<melodie> so go compile your kernel now! what are you waiting for,
<melodie> ?
<KillerSingam> if i did compile my kernel.. how do i install it
<arges> melodie: Xenial works just fine on a skylake i7 for me. Basing on an LTS release (like xenial) would provide the most stable path depending on your timeframe.
<melodie> arges how stable is Kubuntu Xenial is something I should test, I guess
<arges> melodie: of course, and also release the actual release isn't until April
<melodie> my timeframe is not large, if you are referring to how long to I have to build the specs for this tower. A couple days, then it has to be ordered
<melodie> I know it's not before April, however I have upgraded my own custom edition (Bento Openbox Remix) and it works fine (it was better with nouveau than with the nvidia driver, but my tower is an old box)
<melodie> arges the person for whom I'm building the specs needs it for his daily work, which is common current work, and also to edit pictures, he makes photos and edits them with Gimp
<melodie> he will have the machine start with 8 GB RAM and we can add more if needed. Just now I'm not quite sure which version Kubuntu and which version processor I should pick up
<melodie> I was looking here: http://ark.intel.com/fr/products/88192/Intel-Core-i7-6600U-Processor-4M-Cache-up-to-3_40-GHz
<melodie> and to the latest here:
<melodie> http://ark.intel.com/fr/products/family/88392/6th-Generation-Intel-Core-i7-Processors#@Desktop
<melodie> arges may I continue?
<arges> melodie: I'm not entirely sure which works best. But if you do run into issues please file bugs. : )
<melodie> arges I don't get to provide specs and use, I only provide specs and the end user will have to get the perfect choice :D
<melodie> this is why the choice is difficult (where would be the fun otherwise?) XD
<melodie> http://www.ldlc.com/informatique/pieces-informatique/processeur/c4300/+fb-C000000192+fv579-5524+fv160-13685.html
<melodie> I have been shown the first one on the list, then when the guy said "Skylake" I thought omg! that's new! how is that with the kernel?
<melodie> :)
<melodie> and after I did a search I thought the best would be asking the chans for insights
<arges> melodie: I understand. And yes, I was mainly trying to answer 'does the Ubuntu kernel support Skylake CPUs?'
<melodie> arges now I'm going to grab a Kubuntu Xenial, install it on a box (I have enough computers to give it a try on bare metal) and see how it goes.
<melodie> arges I thank you for your kindness
<arges> melodie: good luck
<melodie> :)
<melodie> thanks!
<KillerSingam> melodie
<KillerSingam> hi
<KillerSingam> melodie how to recompile my kernel where do i get the source
<melodie> KillerSingam you read the page that I pointed you to, then you follow the first link you find in it. surely you know how to read? https://help.ubuntu.com/community/Kernel/Compile
#ubuntu-kernel 2016-02-09
<ppisati> cking: ./stress-ng --aggressive -a0 --maximize --metrics-brief
<ppisati> cking: http://pastebin.ubuntu.com/15002159/
<ppisati> cking: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.4.0-1004-snapdragon_4.4.0-1004.4_arm64.deb
<ppisati> cking: stress-ng --aggressive --sequential 0 --maximize --metrics-brief
<cking> yep, the latter is good :-)
<smoser> apw, around ?
<smoser> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#initramfs-tools
<smoser> i know you poked at that some. there is one marked 'Regression'
<smoser> i need that into archive with that change i made. what can i do to help?
<apw> smoser, the ppc64el linux regression is an linux realted issue and not related to initramfs-tools
<apw> smoser, i asked for a retry as it is a intermittent (separatly reported)
<apw> smoser, buut with the perl transition dropping 2k tests on the adt queue it will take a fair while to even start
<apw> smoser, if you want to ask for it to be waved trhough based on that, i would support that
<smoser> in the theory that we'd put it in and then deal with it if it fell out
<apw> i know for sure the issue in that test is there with older initamgs-tools, it is not new
<apw> it appears about 1/3 linux tests on ppc64el regardless of trigger
<smoser> nice
<smoser> apw, can you help me in ubuntu-release then ?
<apw> smoser, what does your fix fix ?
<smoser> the last merge from debian broke mounting of vfat filesystems
<smoser> as vfat depends on nls_ and nls_somesillyname got dropped from the list of modules to include.
<smoser> and it wasn't automatically included because there is no 'vfat' module (as we build that in... not sure why we do that)
<smoser> ie, 'vfat' is listed, and if it were a module it would have read modules.dep and pulled in the others (i think)
<smoser> but because its not a module, it doesn't know to get the other things.
<apw> vfat is built in to handle efi and the like, so you are sure you can write your kernel to where it needs to be
<smoser> not sure though if nls_*  is explicilty a dependecny or not.
<smoser> then maybe you should also build in the nls things
<smoser> because you can't actually mount vfat
<apw> that is entirely possible
<smoser> https://bugs.launchpad.net/curtin/+bug/1540522
<ubot5`> Launchpad bug 1540522 in initramfs-tools (Ubuntu) "vfat support broken in initramfs" [High,Confirmed]
<apw> smoser, ok request made, you could chip in
<smoser> apw,  i dont know that the kernel ever could actually mount vfat without the nls module.
<smoser> really odd.... at least it can't do that for any vfat authored by a modern (probably anything ever produced by a Ubuntu mkfs.vfat) 
<smoser> modern mkfs.vfat
<apw> smoser, perhaps we use a different charset by default, 437 rings a bell
<apw> the majority of those are likely bios made
<smoser> apw, well, the original change, that i put back in included
<smoser>  vfat nls_cp437 nls_iso8859-1
<apw> right, but i think cp437 is builtin, which makes vfat useful
<smoser> yeah. you're right.
<apw> (in a limited set of cases)
<smoser> so vfat would not actually depend on those anyway.
<smoser> right ? (from a modules.dep perspective)
<apw> likely not
<apw> cirtainly it owuld not pull them all in
<apw> smoser, migrated
<smoser> apw,  thanks.
<webdaford> I'm having trouble figuring out how to report a configuration problem in the latest 4.4.1 kernel builds.  I'll describe below.
<webdaford> I have a new laptop that only has an NVME SSD drive.  The ubuntu supplied 4.4.1 kernel is configured to add support for NVME block devices as a modulue.
<webdaford> CONFIG_BLK_DEV_NVME=m
<apw> webdaford, yes
<webdaford> I can install, but when I boot, the drive can't be accessed because there's not support.
<webdaford> I've built my own 4.4.1 kernel and am able to boot (with other issues) by setting CONFIG_BLK_DEV_NVME=y
<apw> webdaford, it depends which series you are running, as mainline renamed hte NVME drivers and so initramfs-tools needed to change to support them
<webdaford> I poked around trying to figure out how to report this, but without much success.
<apw> webdaford, it is already reported, and indeed fixed in xenial i beleive
<webdaford> I've taken the configuration from the daily (yesterday) build ubuntu 4.4.1 kernel and am building with the module included.  I expect it to boot. 
<webdaford> hmm, not from yesterday
<apw> webdaford, it is not the kernel that changes to fix the issue, it is initramfs-tools
<webdaford> ah.  (I'm new :-)  any suggestions on how to proceed?
<apw> which version of ubuntu do you have installed
<webdaford> I've played around a bit, I think the latest I can boot (with problems) is 15.10, I was trying to go to the 4.4.1 kernel to get suport for a wireless card.
<webdaford> just confirmed 15.10
<apw> support in 4.4.1 only or in any 4.4 ?
<apw> only xenial has initramfs-tools fixes for that as yet, as 4.4 isn't a supported kenrle in wily
<webdaford> I have a new Dell xps13 (9350) with a new Broadcom wifi card, I believe support is in 4.4.*
<webdaford> I've tripped across a few blogs with people running 15.10 and upgrading to the latest ubuntu kernels and having success.
<apw> webdaford, yep in principle it works, because you have an NVME root, you need to upgrade
<apw> initramfs-tools as well
<webdaford> hint?
<apw> erm, if you have a 4.4* kernel on 15.10 you need the initramfs-tools from xenial in order for the initramfs to find your root disk
<webdaford> any suggestions on what to google so I can find instructions on how to accomplish that?
 * apw goes see if initramfs-tools will build in wily
<webdaford> I did try an install of 16.04 (latest), but that failed to boot as well
<lamont> 4.4.0-2 hates my second display
<lamont> 4.3.0-7 and earlier find it just fine
<lamont> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
<lamont> 00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
<lamont> only one of those is there in 4.4.0-2... known?
<apw> webdaford, would depend when the image was produced, the fix for initramfs-tools is prety fresh
<apw> lamont, you have two intel display controllers in the same machine ?
<lamont> mebbe
<apw> lamont, i'd say file a bug with the full dmesg from working and not working kernels, and jsalisbury can perhaps look at the delta
<lamont> apw: will do
<webdaford> checking it (16.04) was built yesterday.  I got it from here: http://cdimage.ubuntu.com/daily-live/current/
<jsalisbury> apw lamont I can review
<apw> jsalisbury, thanks
<lamont> jsalisbury: it's 2 connectors on the MB - dvi and vga
<lamont> 4.4 hates the dvi
<lamont> jsalisbury: I'm going to give you kern.log, rather than rebooting the broken kernel
<webdaford> I'll try again with today's 16.04
<jsalisbury> lamont, kern.log from the broken kernel?
<lamont> both kernels
<lamont> you'll love them - they're full of network csum fault spam too
<jsalisbury> lamont, ok.  can you also post the apport data to the bug?  It should collect it automatically, depending on how you open the ub
<lamont> jsalisbury: sure... do you care which kernel is running when I file it?
<jsalisbury> lamont, the bad kernel would be better, since it will collect dmesg, etc.
<lamont> FINE
<lamont> brb
<jsalisbury> lamont, thanks
<apw> webdaford, ok i've just backported the NVME fixes to wily and uploaded a test package to my ppa:apw/ubuntu/initramfs-tools (https://launchpad.net/~apw/+archive/ubuntu/initramfs-tools/)
<apw> webdaford, when that finishes buildnig you could try adding that PPA and see if it works better for you
<lamont> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1543683
<ubot5`> Launchpad bug 1543683 in linux (Ubuntu) "Fails to detect (second) display" [Undecided,New]
 * lamont reboots back to 4.3.0-7, to restore his user experience.
<jsalisbury> lamont, thanks for opening the bug, I'll give it a review
<webdaford> apw, many thanks
<jsalisbury> lamont, can you post 'lspci -vvvnn' on the good kernel and post it in the bug?  
<webdaford> apw, to make life difficult, my laptop has no network access....that's what I'm trying to acomplish with the 4.4.* kernel update.  Hmm..
<apw> webdaford, any other machines? you could put the .deb's on a memory stick
<webdaford> yes, this one (wily)
<webdaford> I see them on the web site
<webdaford> newbie question: is it possible to download the deb's from the ppa website?
<lamont> jsalisbury: done
<jsalisbury> lamont, thanks
<lamont> thanks for jumping on it
<webdaford> I found the tar file for initramfs-tools_0.122ubuntu3.tar.xz, is that the one I want?
<jsalisbury> lamont, I'll review the diffs for the two kernels, but we may end up having to perform kernel bisect.  That would require testing about 7-10 kernels
<lamont> jsalisbury: oh, joy...
<lamont> worst case, gimme a pointer to the tree, and the good/bad checkins, and remind me of the joy of building, and I'll be "happy" to drive it.
<lamont> :/
 * lamont hasn't built his own kernel in a looong time.
<jsalisbury> lamont, I don't mind building the kernels for you.  I have access to a nice build machine that can do in 20 minutes or so
<lamont> jsalisbury: wfm
<lamont> I might even break out the laptop for the testing time
<jsalisbury> lamont, it's testing the kernels that takes the time.  Let me first take a look at the i915 changes and see if anything sticks out between the kernels
<lamont> jsalisbury: any benefit to me trying anything in between those kernels (that's already packaged, that is)
<jsalisbury> lamont, sure.  There are over 400 i915 changes between those two kernel versions, we probably want to narrow it down more.  I'll post some links to kernels in the bug
<lamont> I was figuring on just bysecting the fullpubhgistory
<lamont> otoh, 4.4.0-1.15 seems to have left the building
<jsalisbury> lamont, it would be best to also test the upstream kernels during the bisect.  that will tell us if the bug is Ubuntu specific.  I'm writing up a comment to the bug now.
<lamont> cool
<lamont> jsalisbury: I may need to be a total slacker - need to write some code for a demo that happens tomorrow...  so I may be 24 hours laggy :(
<jsalisbury> lamont, ok, posted.  It's a pain to bisect, but it's usually the best approach with so many changes.
<jsalisbury> lamont, that's no problem at all, as I usually multi task as well :-)
<lamont> jsalisbury: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc2-wily/ looks very boring and usleess
<lamont> (just fyi)
<lamont> jsalisbury: I'm assuming that a simple "good/bad" indicator is sufficient, and that you don't care too much about capturing the various bits
<jsalisbury> lamont, yes
<jsalisbury> lamont, once we know the last good and first bad, we can start the bisect to identify the commit.  Or it may just stick out in the git logs
<lamont> ack
 * lamont will happily play the "clueless" card rather than look at the logs
<apw> webdaford, nope that is one of the source packages
<apw> webdaford, assuming you are 64 bit, then you want th two .debs on: https://launchpad.net/~apw/+archive/ubuntu/initramfs-tools/+build/8989012
 * lamont reboots a few times.. brb
<tjaalton> apw: the nvme-not-in-initrd seems not fixed
<apw> tjaalton, hrmm
<tjaalton> I just installed a build of 4.4.0-4
<apw> what is a man to do, testing results seem to mean nothing
<tjaalton> and it fails to boot like before
<tjaalton> heh
<apw> tjaalton, what version of initramfs-tools
<tjaalton> 0.122ubuntu1
<tjaalton> I see it's in hook-functions under block)
<apw> tjaalton, can you like: zcat /boot/initrd... | cpio -it | pastebinit
<tjaalton> or update-initramfs -v?
<tjaalton> I have both
<apw> lib/modules/4.4.0-2-generic/kernel/drivers/nvme
<apw> lib/modules/4.4.0-2-generic/kernel/drivers/nvme/host
<apw> lib/modules/4.4.0-2-generic/kernel/drivers/nvme/host/nvme.ko
<apw> my initramfs has the nvme drivers in it
<tjaalton> hmmm
<apw> which is a 0.122ubuntu1 version i believe
<tjaalton> ok then, sorry
<tjaalton> I see them too now :P
 * apw regenerates
<tjaalton> but I don't understand why cryptsetup fails again
<tjaalton> guess I just need to debug it further..
<apw> tjaalton, well its a big merge, somethign else could be broken pretty easily
<tjaalton> last time the reason was nvme missing
<apw> break=bottom or something and see if you have a/
<apw> yeah a rebuild has the drivers at least
<tjaalton> so mainline 4.4.0 works, -2/-4 doesn't. rebuilt the mainline initrd so it's not due to that
<apw> tjaalton, so the initramfs-tools bits must be good if mainline 440 works
<tjaalton> yeah
<tjaalton> jumped the gun there, it's something else
<apw> tjaalton, np, its good to know we're making some kind of progess
<lamont> jsalisbury: bug updated (rc4 is fail, rc2 is missing)
<tjaalton> apw: ha, unlocking root works without splash
<tjaalton> actually
<lamont> jsalisbury: and with that, I'm done rebooting until I get my code finished
<tjaalton> aaah of course
<tjaalton> it was all my fault.. the initrd doesn't include i915_bpo (again) :)
<lamont> tjaalton: I hate days like thyat
<jsalisbury> lamont, thanks for the testing.  We should rc3 or rc1 next.  I can post links in the bug
<apw> tjaalton, oh how did that fall out, did i do that /
<tjaalton> so the splash pwd dialog doesn't work, bah
<apw> ?
<apw> tjaalton, i could believe i lost something
<tjaalton> apw: I'm not sure if it was added to mainline
<tjaalton> but yeah that should be kept as it's kinda coming back every year :)
<apw> mainline wouldn't have more than ur stuff
<apw> our stuff
 * lamont bets he can guess what they are. :p
<lamont> jsalisbury: i'll poke you when I have an update... expect ~20+ hours from now
<jsalisbury> lamont, thanks
<tjaalton> apw: oh right I meant our mainline and not vivid/trusty
<tjaalton> as in the current tip
<apw> tjaalton, but yes, ubuntu/ in xenial doesn't have *_bpo ...
<tjaalton> yep
<apw> tjaalton, surely by now that must be upstream ...
<lamont> jsalisbury: for further giggles, rc1 is missing kernels, too
<lamont> I'll test rc3 once I get code happy
<apw> lamont, is that 4.4-rc1/2 ?
<apw> lamont, if so check out the +cod1 variants
<tjaalton> apw: what is?
<tjaalton> the old i915_bpo bits are, but now we need newer crap for KBL and BXT and tbh for SKL still..
<lamont> apw: it is.  will do
#ubuntu-kernel 2016-02-10
<rtg> kamal, bug #1541907 is a good candidate for stable
<ubot5`> bug 1541907 in linux (Ubuntu Wily) "qeth: layer2 reports unknown state to network tools." [Undecided,In progress] https://launchpad.net/bugs/1541907
<kamal> rtg, I'll get it queued up.  that bug doesn't list lts-Utopic, but shouldn't that need it also?
<rtg> kamal, I guess that makes sense
<manjo> rtg, I noticed that if /boot is empty kernel install fails before update initramfs expect to see an initrd.img-<version> in /boot .. is that a know issue?
<manjo> s/before/because
<rtg> manjo, haven't the faintest idea
<smoser> hey
<smoser> silly question.
<smoser> https://bugs.launchpad.net/maas/+bug/1519470
<ubot5`> Launchpad bug 1519470 in maas-images "Trusty Deployment w/ RAID storage config fails because Trusty images do not contain RAID kernel modules" [Undecided,Confirmed]
<smoser> is complaining about lack of raid modules in the initramfs
<smoser> the initramfs there is basically just 'update-initramfs' output as installed by a kernel
<smoser> why wouldnt raid*.ko be in there ?
<apw> smoser, if it is 4.4, they might have changed location or something
<apw> smoser, have you checked your laptop's initramfs ?
<apw> lib/modules/4.4.0-2-generic/kernel/drivers/md/dm-raid.ko
<apw> lib/modules/4.4.0-2-generic/kernel/drivers/md/raid456.ko
<apw> ^^ in my initramfs
<apw> /lib/modules/4.4.0-2-generic/kernel/drivers/md/raid0.ko
<apw> /lib/modules/4.4.0-2-generic/kernel/drivers/md/raid1.ko
<apw> /lib/modules/4.4.0-2-generic/kernel/drivers/md/raid10.ko
<apw> /lib/modules/4.4.0-2-generic/kernel/drivers/md/raid456.ko
<apw> ^^ in lib/modules
<smoser> apw, it didnt have mdadm installed
<smoser> when the intiramfs was created.
<apw> that might make a difference indeed
<apw> smoser, ok confirmed it is the mdadm initramfs-hook which triggers those to make it into the initramfs
<smoser> apw, yeah. it was smoser fail.
#ubuntu-kernel 2016-02-11
<rtg> kamal, bug #1543980 indicates a possible table regression
<ubot5`> bug 1543980 in linux (Ubuntu Trusty) "Kernel 3.13.0-77 crashes (can be triggered by Samba)" [High,Confirmed] https://launchpad.net/bugs/1543980
<manjo> apw, I think ppa requires amd64 for indep builds... can't find a way around it .. if you simply force to build only arm64 it just ignores indep packages 
<manjo> apw, you would think they would have the condition if no other arch builds enabled build everything for the supported arch
<kamal> rtg, ack re: bug #1543980.  I'll watch the LKML thread -- looks like there's already a proposed patch to fix it
<ubot5`> bug 1543980 in linux (Ubuntu Trusty) "Kernel 3.13.0-77 crashes (can be triggered by Samba)" [High,Confirmed] https://launchpad.net/bugs/1543980
<opny> Hello, I'm trying to build an ARM kernel out of 4.4 on ubuntu 15.04. I get an error like this one ./arch/arm/vdso/vdsomunge: Failed to map arch/arm/vdso/vdso.so.dbg: Invalid argument
<opny> Any suggestion of what is going wrong?
#ubuntu-kernel 2016-02-12
<phillw> yikes!!.. Well, back in 14.04 kernel time when I built a non-pae kernel it worked, but would not work under "LiveCD" install. I was told about 'aufs' and we did build successful kernel http://phillw.net/isos/non-pae/  is there a link for the 4.4 kernel ?
<apw> phillw, link for what exactly?
<phillw> apw: That link will build a kernel and stuff, but there was something to do with aufs that was needed. I'm really sorry that I have updated / changed my computer and I do not keep the inks on the wiki page. 
<apw> phillw, sadly i don't think i know waht that means ..
<phillw> apw: have a look at   http://aufs.sourceforge.net/
<phillw> it has the list
<apw> phillw, i don't understand what you are asking?  our 4.4 kernel has aufs applied
<phillw> the AUFS is required to have an ISO that can run from CD / DVD / USB
<phillw> apw: that was the question!!!
<utlemming> hey guys...I'm using the mainline 4.5 kernel (i915 is unstable on 4.2). I've noticed high load on the 4.4 and 4.5 kernels for my Intel Mobile processor. I just filed https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1544798
<ubot5`> Launchpad bug 1544798 in linux-meta (Ubuntu) "high load with 4.4 and 4.5 kernels for Intel Mobile processors" [Undecided,New]
<apw> phillw, overlayfs is required for the iso
<apw> phillw, but clearly whatver is needed is in our kernel else our iso's would not boot
<phillw> apw: so, if I take the ubuntu 4.4 and knock it back to non-pae what does it need
<apw> phillw, it needs PAE configuration turned off
<apw> in the config
<phillw> apw: the kernel would boot, I apologise as I'm going back to 3.13 which was 14,04
<utlemming> just thought that I would let you guys know to get this on the radar for 16.04
<apw> utlemming, well its filed againsts the wrong package, so a good job you did bring it up
<apw> are we sure this isn't the load being reported higher becuase the cpu is being clocked slower to save power that cking investigated though
<apw> jsalisbury, ^ a bug for investigation perhaps, and moving to linux
<jsalisbury> apw, ack, I'll take a look
<utlemming> apw: whoops, and thank you :)
<phillw> apw: I have that part, it worked well, but the kernel so produced needed aufs - that part of the instructions I have lost over the last couple of years. I know that non-pae is not high on the list and I reckon I could still manage that, but the aufs for live CD boot I'm 2 years behind on.
<apw> phillw, iso does not require aufs, it requires overlayfs, but both of those are in the ubuntu 4.4 kernel and enabled
<apw> phillw, so i still do not know what you are asking me
<phillw> apw: would you be so kind as to look over https://wiki.ubuntu.com/phillw/non-pae and either write a long list of where things have changed, or have an edit. It's not the biggest job. 
<phillw> apw: I'll buy you coffee :D
<apw> it looks close enough
<phillw> apw: so, we do not need to add in aufs now.. it is in the main kernel? ... I'm starting to remember that it was actually a bug back then :)
<apw> phillw, all of our kernel sources have the bits they need to make an ISO work, and it all enaled
<apw> enabled
<phillw> apw: I owe you coffee.. please email me your ppal name to phillw@linuxpadawan.net 
<apw> phillw, no need
<phillw> apw: do we still turn off the CONFIG_DEBUG_INFO
<apw> phillw, if you are building out of PPA yes, in PPA no
<phillw> apw: Why does a local build produce such enormous packages?Â Our build includes CONFIG_DEBUG_INFO in order to produce linux-debug-image packages. We then manually strip the modules after build.
<apw> it is about those being 5GB in size
<phillw> maybe a little large for a cd :)
<phillw> hehe... thanks a lot. i will be honest, I was expecting "you want to do WHAT?!!", instead you have told me that I can at least have a 1st roll of the 4.4 kernel
<phillw> apw: last big ask... what is the link for xenial 4.4 as opposed to Â https://launchpad.net/ubuntu/trusty/+source/linux/3.13.0-8.27/+files/linux_3.13.0.orig.tar.gz ?
<apw> phillw, you should work from the git repo, apply the config delta, then you can rebase it later
<phillw> apw: that will make more sense to a padawan who wants to learn deeper kernel, But with others sniggering in other channel as I explain I do not understand. could you explain "you should work from the git repo, apply the config delta, then you can rebase it later" to some one who does not use git ?
<phillw> wxl: and it appears that aufs is now enabled by default, instead of what melodie and my self had to do with the  3.13 kernel for 14,04
<apw> phillw, git is a version control system, i am suggsting you get your source from our master git repo
<apw> do the configuration edit in that tree
<apw> and then commit that, as that is then rebasable
<phillw> apw: all I need to do is alter the "Â High Memory Support" from 64GB to 4 GB and then respin the kernel.
<apw> sounds abut right
<phillw> the requirement for non-PAE kernel is growing smaller, but as lubuntu and other teams do support older kit.. I do make available such a kernel for community repsins.
<apw> phillw, it woul dmake sense to do that via a PPA imo
<phillw> apw: Well, I'd have to ask for help on that... it is an area well out of my known stuff..... But, I do have a guy who knows c, etc building debs etc and would like to get to understand kernel building a lot more.
<phillw> It is actually having him as a padawan that reminded me that I may may be due to make a new 4.4 kernel (at least ubuntu and kernel are back in sync)
<apw> phillw, all you need to do is apply the delta change, and build a src package as normal (you do that already for other packages) and upload that to a ppa
<phillw> okies, great!!
<rui1> \exit
<ppisati_> smb: it's me, for real!
<ppisati_> ppisati: who are you? liar!
<smb> ppisati_, suffering from (net) split personalities
<cristian_c> jsalisbury: hi
<lamont> jsalisbury: 4.4.0-040400rc1-generic == FAIL
<lamont> jsalisbury: holler when you have your first kernel in the bisect series for me?
<jsalisbury> lamont, I'll start the build now
<lamont> kewl
<lamont> jsalisbury: curious -- how long is your buildtime?
<jsalisbury> lamont, probably about 20 minutes
 * lamont as an appt that he will be leaving for in about 5 minutes, back in about 2 hours or so..
<jsalisbury> lamont, there will be about 10 of them to test, so I'll just keep posting links in the bug
<lamont> which is to say, I'll test it when I get back...
<lamont> jsalisbury: works for me
<cristian_c> jsalisbury: hi, again
<jsalisbury> cristian_c, hey
<cristian_c> jsalisbury: I've read your question in launchpad
<cristian_c> jsalisbury: sorry, I've never created a patch file
<jsalisbury> cristian_c, that's not a problem.  I can submit it, I wasn't sure if you discussed the fix with upstream or not.
<cristian_c> jsalisbury: ok
<lamont> jsalisbury: empty directory at your lin
<lamont> link
<jsalisbury> lamont, ok, let me check
<jsalisbury> lamont, ok, they are there now.
<lamont> yep
<lamont> jsalisbury: updating the bug: good kernel
<jsalisbury> lamont, great, I'll build the next one
<lamont> bonus points if you put it somewhere I can rsync...
<lamont> will this next one be 4.3.0-040301?
<lamont> or should I clear out the test each round?
<jsalisbury> lamont, the script used to build the kernels puts a date stamp in the name, and it could start with 4.4 as it bounces back and forth between good and bad kernels.
<lamont> ack
 * lamont clears out the cruft, just to be sure
<jsalisbury> lamont, The next kernel is building.  I just scp the .deb files to that public web server.  I can scp them anywhere you want, as long as I have access.
<lamont> jsalisbury: mombin.c.c:~/lamont would be a fine target
<jsalisbury> lamont, is that accessable from the Canonical network?  I can't seem to get there
 * lamont is going over the vpn, but it should otherwise be reachable
<lamont> alternatively, sftp to people.u.c
<lamont> which doesn't help me..  so nm people.u.c
<jsalisbury> lamont, I can get to mombin, so I'll put them in your home directory
<lamont> ~/lamont, not ~lmaont
<lamont> that is, toss 'em where you can put them (write perms being such), and I'll pul from your home dir
<lamont> we have read access to each other's directories, but not write
<jsalisbury> lamont, ok, I'll just put em in my home dir
<jsalisbury> lamont, looks like my build server can't get to mombin or people, but my desktop can.  The next kernel is ready so I'll just scp it to kernel.ubuntu.com and see if I can figure out a way for you to rsync
<lamont> sure
<lamont> jsalisbury: from the land of hahaha lamont, I have a login on kernel.u.c, beacuse of kernel-team
<lamont> rather, kernel_devs
<lamont> so definitely just throw it somehwere there
<jsalisbury> lamont, ok, next kernel is there.  I posted to the bug to, so I can keep track of where we are in the bisect and what kernels were good/bad
<lamont> yep
<lamont> jsalisbury: good.  updated.
#ubuntu-kernel 2016-02-13
<if_gaga0> hello all, can you tells me right way for: building own Xen-kernel image with that patch applied: http://www.gossamer-threads.com/lists/linux/kernel/2316294 . I'm already see https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel how-to, but i'm need XEN-4.5 functionality
<if_gaga0> (15.04)
<nusch> Hello, where should I start to debug this issue: "[64251.873821] INFO: task kworker/2:1:17383 blocked for more than 120 seconds.
<nusch> it results in frozen screen, with moving cursor and working SSH
<nusch> I tried install latest linux-drm-intel-nightly from kernel PPA, but stuck with "W: Possible missing firmware /lib/firmware/i915/skl_guc_ver4.bin for module i915
<nusch> is it avaliable somewhere or not needed ?
#ubuntu-kernel 2016-02-14
<CarlFK> I am having trouble with the net installer - the kernel finds the SD card reader (with no card in it) first, gives it sda, which breaks preseed d-i partman-auto/disk string /dev/sda
<CarlFK> wily install uses 4.2.0-25-generic, finds the spiny disk first.  
<CarlFK> wily installer uses 4.2.0-16 , xenial installer uses 4.4.0-4, both find the card reader first 
<CarlFK> is there a param that will blacklist the card reader ?
#ubuntu-kernel 2017-02-07
<alkisg> Why is linux-image-4.4.0-62-generic_4.4.0-62.83~14.04.1_i386.deb just 19 MB while linux-image-4.4.0-62-lowlatency_4.4.0-62.83~14.04.1_i386.deb is 53 MB?
<alkisg> Have the kernel modules been separated to different packages recently?
<alkisg> Like, linux-image-extra-4.4.0-62-generic ?
<alkisg> Looks like that was the case for -virtual previously, and -image was started in 14.04 too... 
#ubuntu-kernel 2017-02-08
<White_Light> are there any thoughts on moving to blk-mq eventually? I'd love it if it was at least an option once bfq is added ontop of blk-mq
<gentoo> how can update-initramfs be found in the packages 
<gentoo> send a memo if offline
<rcj> kamal: backport or cherry-pick will be too late for releasing images next week.  sorry I didn't understand the impact before announcing images
<rcj> Should we delay the custom image or revert to stock driver in the interim?
#ubuntu-kernel 2017-02-09
<apw> tseliot, we have a bcmwl sru fix outstanding in xenial/yakkety which is causing a real problem for the point release
<apw> tseliot, its been in the queue for 62 days 
<tseliot> apw: apparently, nobody tested that
<tseliot> and I don't own a Cisco 3800
<apw> tseliot, i am right in saying that the hwe kernel yakkety's kernel requires it
<apw> or the base version that is, without the ack fix at least (assuming it is a fix even)
<apw> and we are spinning ISOs like now ...
<tseliot> looking at the changelog, that's a nobrainer. I had completely forgotten about it 
<tseliot> I can test that here, and then maybe tjaalton can approve it
<tseliot> apw: it turns out I have used that release on my laptop for a couple of months with zero problems :)
<tseliot> tjaalton: I have just added a comment, please approve LP: #1647036 in -proposed
<ubot5> Launchpad bug 1647036 in bcmwl (Ubuntu Yakkety) "Client does not ACK auth/assoc responses from Cisco AP3800" [High,Fix committed] https://launchpad.net/bugs/1647036
<tjaalton> tseliot: mark it verified
<tseliot> tjaalton: done
<infinity> tseliot: Did you verify it builds and inserts on both 4.4 and 4.8?
<infinity> (builds, inserts, and works, ideally)
<tseliot> infinity: I use it on 4.4. Let me check 4.8
<infinity> tseliot: With uploads to trusty, xenial, and yakkety, one can't just say "yeah, I use this driver" and v-done for all three.
<infinity> tseliot: Needs to be tested on trusty (with 3.13 and 4.4), xenial (with 4.4 and 4.8) and yakkety (with 4.8), but for Right Now, xenial is what's blocking me.
<tseliot> infinity: actually, I take back what I said, as I use that in Zesty too
<tseliot> it will work on yakkety for sure, but let me double-check
<infinity> tseliot: xenial (with both kernels) is today's immediate concern.
<infinity> tseliot: We can leave it unverified on trusty and yakkety while that gets sorted, but xenial is point releasy right now.
<tseliot> infinity: ok, let me test the backported kernel on xenial
<infinity> tseliot: Enable proposed and grab linux-generic-hwe-16.04
<infinity> (It'll be in updates shortly, but don't wait for me to do that)
<tseliot> ok
<tseliot> infinity: it works well. I have added a comment in the bug report
<tseliot> yakkety will be exactly the same
<infinity> tseliot: Ta.
<infinity> tseliot: When you get around to explicitly testing trusty and yakkety, update the bug, but I'm happy releasing xenial right now.
<tseliot> infinity: ok
<javier4> Hi all. I'm trying to port ubuntu touch on android device. The system boots, but i have a lot of problems. The log shows a bunch of these erros.
<javier4> E/NetlinkListener( 1226): recvmsg failed (I/O error)
<javier4> I don't get it on android, do you think they could be due to defconfig modifications?
<javier4> The two different pids of the errors refer to vold and netd.
#ubuntu-kernel 2018-02-05
<s10gopal> what should i do ?   https://bugzilla.kernel.org/show_bug.cgi?id=198665
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
<oursland_> apw, I have uploaded my checkout and build scripts along with the build log containing the error to: https://gitlab.com/snippets/1696811
<s10gopal>  https://bugzilla.kernel.org/show_bug.cgi?id=198665 can be fixed?
<s10gopal> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646
<ubot5> Error: Could not parse XML returned by bugzilla.kernel.org: ('The read operation timed out',) (http://bugzilla.kernel.org/show_bug.cgi?id=198665&ctype=xml)
<ubot5> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,Triaged]
<s10gopal>  https://bugzilla.kernel.org/show_bug.cgi?id=198665 can be fixed?
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
#ubuntu-kernel 2018-02-07
<gopal> https://bugzilla.kernel.org/show_bug.cgi?id=198665
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
<apw> gopal, thanks
<apw> b 7
<gopal> anyone online ?
<gopal>  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646 
<ubot5> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,Triaged]
<gopal> https://bugzilla.kernel.org/show_bug.cgi?id=198665
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
<alkisg> gopal: I'm sure that ubuntu devs here have seen it, you posted it like 100 times :)
<alkisg> Needinfo means you need to answer to the bug there
<gopal> alkisg: already did
<alkisg> Cool, now patience. Sometimes it takes a lot of time for bugs to get solved, from days, weeks, to even months
<sforshee> tseliot: I can't remember if I pinged you about this before, but bug #1737750 has a patch attached to fix build errors in nvidia-304 with 4.15
<ubot5> bug 1737750 in nvidia-graphics-drivers-304 (Ubuntu) "nvidia-graphics-drivers-304 304.137-0ubuntu2 ADT test failure with linux 4.15.0-1.2" [Medium,In progress] https://launchpad.net/bugs/1737750
<tjaalton> 304 should be removed
<tjaalton> it's dead upstream
<apw> tjaalton, in bionic?  file a removal bug with that information in it
<tjaalton> yep
<tjaalton> bug 1748000
<ubot5> bug 1748000 in nvidia-graphics-drivers-304 (Ubuntu) "Remove from the archive: this legacy driver is unmaintained upstream" [Undecided,New] https://launchpad.net/bugs/1748000
<tjaalton> nice #
#ubuntu-kernel 2018-02-08
<ricotz> sforshee, thanks for keeping up with the recent kernel releases
<sforshee> ricotz: just doing my job ;-)
<ricotz> sforshee, heh
<gopal> anyone online ?
<alkisg> gopal, devs here have seen your bug
<alkisg> If they don't have anything new to add to it, they won't just idly chat...
#ubuntu-kernel 2018-02-09
<oursland> Hi all, I get a build error when following the wiki on rebuilding the kernel.  The error seems to be due to SPL/ZFS.  The error and my build scripts are available: https://gitlab.com/snippets/1696811  Any advice on getting the kernel to build?
<apw> oursland, are you building from a mainline builds source ?
<apw> oursland, if so those don't even have zfs applied so you can only build those with do_zfs=false
<apw> oursland, and tools always build into a 'one pre architecture' package, but the primary kernle build should build a linux-tools-*-<flavour> with links in it
<frickler> we are having multiple servers going oom in a couple of days reproducibly after upgrading to 4.13-hwe kernels. they are running fine with 4.10-hwe (did so for a year and do again after booting with the older kernel again). has anyone seen similar things? this also happens with older 4.13-0.19, so likely not related to recent pti/meltdown stuff
<apw> frickler, i do not think i have heard of anything like yet as yet ... coul dyou file a bug against the kernle please
<apw> frickler, and put as much detail about how you are triggering that
<frickler> apw: https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1748408 I'm testing with upstream kernel now
<ubot5> Ubuntu bug 1748408 in linux-hwe (Ubuntu) "Servers going OOM" [Undecided,New]
<apw> frickler, great, if you can find somewhere not affected that is always good
<frickler> apw: well, 4.10 is fine, but I don't know whether a bisect from 4.10 to 4.13 would be feasible
<apw> frickler, well if you are able to test the mainline builds if they are full featured enough
<apw> you might well be able to work through 4.11 4.12 and 4.13 mainline
<apw> to see which of those work, then we move to the -rc builds, and then we can bisect in that gap
<frickler> apw: at least one system is running now with 4.15, will need to wait a couple of hours to see how it behaves
<apw> frickler, i've passed the bug on to someone who can help with a bisect when you get to that point
<frickler> apw: I just noticed that the mainline kernels are lacking aufs support, so docker won't run properly, giving less confidence in my testing results for these kernels. is it missing intentionally?
<apw> frickler, they are mainline kernels, they can only have things which are mainline
<frickler> apw: yeah, I found out in the meantime that aufs has been removed after having long been deprecated, working to replace that now
<apw> aufs was never upstream, so it isn't in any of the mainline builds
<frickler> apw: hmm, strange, not sure why it is being used by default then in our setup. but anyway, can't be too bad to move away from it. would be even nicer if it turned out to have caused my original issue ;)
<apw> heh
<oursland> apw: do_zfs=false fixed my problem.  Thanks!
#ubuntu-kernel 2018-02-10
<s10gopal> anyone online?
<etyrnal> does trying to learn/understand linux, the  kernel, ubuntu, and drivers, using a virtual machine version of ubuntu provide a relatable experience to trying to learn how to kludge ubuntu/linux onto devices like SBCs such as banana pi m3, and raspberry pi, etc?
#ubuntu-kernel 2018-02-11
<etyrnal> what's the general process for finding a driver for a particular chip that will be compatible with the banana pi m3, ubuntu, the kernel, etc?  Say you know the bpi-m3 has a AP6212 wireless chip, how does one go about finding a driver and incorporating it into the kernel etc?
<snadge> i just installed 18.04 thinking i would see a 4.15 kernel.. and that expectation lead to immense disappointment ;)
<snadge> proposed.. got it.. i'll pretend that didn't happen
<apw> snadge, our kernels were delayed some because of all the effort diverted into meltdown/spectre
<s10gopal> can anyone plz help me , after installing ubuntu 14.04.05lts my problem is solved , but i want to report that bug properly , what more info should i post ? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646
<ubot5> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,Triaged]
<s10gopal> can anyone plz help me , after installing ubuntu 14.04.05lts my problem is solved , but i want to report that bug properly , what more info should i post ? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646     SOS report of ubuntu 14.04.05LTS added
<ubot5> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,Triaged]
<s10gopal> i'm on 4.4.0-31-generic . I tried to install old kernel in ubuntu 16.04 (it was 4.10 ,4.11 and 4.8) but my laptop became super laggy . random processor was going to 99% use in use.
<s10gopal> apw, 
<s10gopal> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646 UPDATED
<ubot5> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,Triaged]
#ubuntu-kernel 2020-02-04
<apw> https://launchpad.net/bugs/1861837
<ubot5> Ubuntu bug 1861837 in linux (Ubuntu) "machine doesn't come up after suspend and re-opening the lid" [Undecided,Incomplete]
#ubuntu-kernel 2020-02-06
<hggdh> hello, regarding bug 1844245 
<ubot5> bug 1844245 in linux-azure (Ubuntu) " Integrate Intel SGX driver into linux-azure" [Undecided,In progress] https://launchpad.net/bugs/1844245
<hggdh> We found that doing dist-upgrade on servers that depend (for work) on the SGX module on 18.04 resulted in non-functional server (because the module is blacklisted by 1844245)
<hggdh> (this is on Azure). Why is the module blacklisted for Azure? We are expecting many bugs opened as a result of this (as customers upgrade and fail)
<apw> hggdh, i didn't think that module didn't exist prior to the upgrade, and there is an opt in loader systemd job for it
<hggdh> apw: it did not. The project had instructions and used to download the source/build/install. But with the automatic blacklist... they went south
<mhcerri> hggdh, does the server still boot?
<hggdh> the questions are (1) why is it blacklisted on Azure (2) is it possible to remove the blacklist
<mhcerri> hggdh, there's a systemd service shipped with this version that should load the sgx module
<hggdh> right now they are scrambling to let actual users of the service know they will all go down if they install the new kernel
<apw> which is disabled by default
<hggdh> yes. and They *depend* on SGX
<mhcerri> hggdh, sgx is can potentially cause security issues, we started to ship it but we decided to ship it disabled by default
<hggdh> mhcerri: I am finding out right now. We just got the Sev A bug
<apw> mhcerri, do you have an incantation to tell the systemd to enable the job to load it
<mhcerri> hggdh, enabling intel-sgx-load-module.service should load the module
<hggdh> mhcerri: thank you. But, meanwhile, any of the service customers will first have to boot, fail to join the enclave, then systemctl enable/start the module
<hggdh> correct?
<apw> hggdh, they could enable it beforehand i assume
<apw> hggdh, as for removing the blacklist; even if we did that and redid the kernle, the one they have installed now would still blacklist it
<mhcerri> hggdh, yes. but that could potentially happen in any kernel update if you are building the module by yourown. any abi change can break the module
<hggdh> apw: indeed, sorry. Install the update, systemctl enable the service, remove the blacklist, reboot
<hggdh> mhcerri: I believe they are using dkms
<apw> you don't need to rmeove the blacklist, as the service handles your intent to laod
<hggdh> *they *were* using dkms
<hggdh> apw: perfect
<apw> hggdh, though you should test that if you have a test-bed
<mhcerri> hggdh, dkms packages will usually have a bunch of ifdef's to cover most of the scenarios, but still they are not flawless.. for the dkms we support in the archive we have to test them against any new kernel release to ensure they are still working
<hggdh> mhcerri: yes, I understand. I believe the developers were doing so (and in fact, they were the ones that opened the bug)
<hggdh> mhcerri: could you please expand on "security issues" on SGX? The developer is asking
<mhcerri> hggdh, nothing specific, but it's new techlogy that isn't fully tested and wasn't accepted upstream yet
<mhcerri> hggdh, please let us know if enabling the service actually works around the issue. that might be useful information for us
<hggdh> mhcerri: I will. I am asking the devs to try it (add in the blacklist, unload the mod, enable the service, reboot)
<hggdh> Perhaps the major point here is adding the SGX mod was nice, but unilaterally disabling it... directly hits whoever actually (and currently) uses the kernel. I mean, changes should minimise impact, but this one (in this aspect) ONLY impacts those that already use the module
<apw> the problem is we cannot know or test the impacts of changes on completely out of archive objects like this
<apw> which is why people are encouraged to get things into the archive so they can be tested and regressions like this detected
<hggdh> apw: I understand. But, at the moment, this looks really like a regression. I will check if they have already opened a bug on LP for it
<hggdh> mhcerri: you need to enable and *start* the service. Just enabling will load the module on next reboot. But it works, and keeps working after reboot
<mhcerri> hggdh, ah perfect. sorry, yes that what I meant
<mhcerri> hggdh, so it doesn't seem the sgx module is needed during the initramfs step, right?
<hggdh> mhcerri: I don't know *yet*. I tested on a common instance of 18.04, not under the ansible environment the application needs. I am asking them to check on it now. The WantedBy=multi-user.target also worries me...
