#ubuntu-kernel 2005-07-11
<fabbione> morning
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,4--2.6.12 |
<chmj> morning 
<zul> heylo...
<zul> im offically un-employed again ;)
<fabbione> ehhe
<chmj> hmmm ?
<fabbione> zul: congratulation
<zul> thanks :)
<zul> ....and i have accepted the position
<fabbione> ehhe
<zul> chmj: i recently started a new job and got an offer and accepted it for a higher paying job somewhere else...hence im un-employed again 
<zul> in theory
<chmj> oh I see 
<zul> fun isnt it
<chmj> zul: in that case congratulations !
<zul> thanks :)
<fabbione> zul: when you start at the new place?
<zul> monday
<zul> ...long weekend for me ;)
<zul> but i have another doctor's appointment tomorrow
<fabbione> ehhe
<zul> world domination is mine....ahahaha
<zul> hey jeffarino
<jbailey> Heya Chuck!
<zul> how goes it?
<jbailey> Good.  The place still looks like it was hit by a bomb. =)
<jbailey> Plugged in the IP phone a couple minutes ago, so we have phone service again.
<jbailey> Can't find the wireless router, so I'm limited to one computer at a time (it's also my switch)
<fabbione> hey jeff
<fabbione> fix glibc double simbols for sparc otherwise i can't compile gnome. kthxbye :)
<fabbione> oh he is not here
<fabbione> crap
<fabbione> hey jeff
<fabbione> fix glibc double simbols for sparc otherwise i can't compile gnome. kthxbye :)
<doko> fabbione: the unionfs ice tarball lacks the .i file and the command line used to compile
<jbailey> double symbols?
<jbailey> AKA, bugzilla #?
<jbailey> or other text of error?
<fabbione> doko: i told you before.. there was no .i
<fabbione> doko: and the log is in the tarball
<fabbione> jbailey: i did send you an email
<doko> hmm
<fabbione> according to doko it's a symbol exported twice in glibc
<fabbione> doko: let me check again the build dir
<fabbione> i didn't trash it
<fabbione> but the command line is there
<jbailey> Eh?  HTF did you wind up with two PLTs?
<jbailey> And why can you compile anything else?
<fabbione> jbailey: dunno...
<fabbione> me idea has none
<fabbione> doko:
<fabbione> find . -name "*.i"
<fabbione> ./null.i
<fabbione> ./asm-offsets.i
<fabbione> that's all
<doko> ugly
<fabbione> doko: i can try to rerun... 
<fabbione> no idea why..
<fabbione> did you find the build log in there?
<jbailey> Oy, Fabio.  Is 2.6.12 the default now?
<fabbione> jbailey: yes
<ogra> jbailey, bah, you are far behind
<fabbione> since a while
<ivoks> hi
<ivoks> we have a nasty bug
<jbailey> ogra: This is my first working day in the past 5 or 6 =)
<fabbione> doko: ok.. cleaned all *.i and *.s
<fabbione> ivoks: bugzilla please
<ivoks> fabbione: i did
<fabbione> we only discuss development here
<doko> I'm away now, back at 22:00 UTC
<fabbione> ivoks: than it will be processed with all the other
<fabbione> s
<fabbione> doko: just ONE sec..
<ogra> jbailey, you didnt use a wlan equipped moving van ? tsk
<fabbione> it doesn't take long
<ivoks>  Opened: 2005-04-17
<ivoks> and it's dos
<ivoks> by user
<jbailey> ogra: No, and sadly, I can't find my WAP either.  Buried in a box somewhere.
<ogra> meh
<ogra> moving is odd
<fabbione> doko: i confirm.. there is NO .i
<fabbione> ivoks: bug number+
<ivoks> 9830
<ivoks> it seems it is a kernel bug, despite my comment
<ivoks> or isn't :)
<ivoks> confused :)
<fabbione> it's not a kernel bug.. there is even an extra reference to the debian bts
<ivoks> did you read it?
<ivoks> i referenced
<ivoks> The kernels 2.4.28+ and 2.6.9+ with IPv4 and ATM-CLIP enabled have bugs
<fabbione> it's not a kernel bug....
<ivoks> ok
<fabbione> you cannot run these commands as user
<fabbione> and if the userland is fool enough NOT to do the proper uid checks.. well...
<ivoks> you can
<fabbione> ain't a kernel problem ;)
<ivoks> i agree
<fabbione> no you can't
<fabbione> 'ip addr flush dev eth0' enters an endless loop
<fabbione> this is an admin command
<ivoks> yes
<fabbione> you need sudo
<ogra> fabbione, you cann, they just dont do what they should
<ivoks> sorry, it isn't a kernel bug
<ogra> (i.e. failing gracefully)
<fabbione> ogra: exactly.. it's a non command if you are not root
<ivoks> but it is a bug, nasy one...
<fabbione> and if it fails in a loop.. it's a bug
<fabbione> definetely not in the kernel
<ogra> ivoks, its just wrong exectutable rights ;) 
<ivoks> in breezy there is no bug
<fabbione> ivoks: ip has been updated in breezy iirc
<ivoks> i know
<ivoks> that's why there isn't a bug :)
<ivoks> ok, my comment was right on bug, it isn't a kernel bug... sorry for bringing alarm to this channel :)
<ogra> ivoks, now that you are here, fix some kernel bugs ;) 
<ivoks> :))
<ivoks> i have exam tomorrow
<ivoks> i should be looking at notes and books :)
<ogra> so fixing kernel bugs is a good excus then *g*
<ivoks> well, profesor uses linux :)
<ogra> you see :)
<ivoks> if i tell him i spent all my time fixing linux, maybe i'll pass :)
<ivoks> sorry... this class is very important, human lives depend on it, no passing here if you aren't brilliant :/
<ivoks> next wed i'll work all time on bugs
<jbailey> Dammit, no fridge in hand.
<jbailey> It took 2 hours to return the u-haul.
<lamont> ew
<jbailey> The new udev wants a kernel >2.6.10.  How do we force kernel upgrades to go first?
<jbailey> I could use preinst love...
<jbailey> Not a terribly good test, but it's worked so far for glibc.
<jbailey> Feh.  Can we just make a generic "linux" package, which is the minimum guarnateed version to be on the system?
<jbailey> It can be from the same family as linux-power* and depend on a sane working one for a given arch.
<jbailey> If the user happens to replace it and point his bootloader to something else, then fine, but we don't support them in those cases anyway.
#ubuntu-kernel 2005-07-12
<lamont> jbailey: because on some architecture families (ppc, hppa) there isn't _one_ kernel that works on all supported instances of the architecture.
<jbailey> Okay, so discard that concept then and it can depend on an either or.
<jbailey> We really need versioned provides.
<jbailey> Hmm, it could depend on hppa32 | hppa64 or something.
<jbailey> but still be made by linux-meta so that we have something we can depend on as the installed version.
* jbailey gets ready for another attempt to buy appliances.
<fabbione> morning
<chmj> fabbione: have you started backporting ipw2100, are u sticking with that solution for now ?
<fabbione> chmj: i am working on it right now...
<fabbione> i need to dig into some stuff first
<chmj> ok 
<fabbione> ok i found a matching set
<fabbione> ipw2100-1.0.0 with ipw2200-1.0.1
<fabbione> they share the same ieee subset
<fabbione> after that release the ieee has been changed a lot
<fabbione> that could explain the mess
<chmj> seems like it 
<jbailey> fabbione: *poke*
<chmj> fabbione: ipw2100 failed 
<fabbione> chmj: how?
<chmj> strangely 
<chmj> when I boot, dhcp fails 
<fabbione> chmj: i already received 3 reports of it working
<chmj> it just assigns to a 192.168.0.195 
<fabbione> chmj: that's not a kernel bug clearly...
<fabbione> what happens if you do dhcp manually?
<chmj> when i run dhclient again, it works 
<fabbione> than it's a dhcpd problem or an AP problem
<fabbione> the driver works
<chmj> but after I use it for a while, it looses the IP address 
<fabbione> yeah.. dhcpd problem
<fabbione> check the server
<fabbione> they are not talking properly
<chmj> all kern.log says it "no ipv6 routers found"
<fabbione> yeah.. that's ok.. it means you are not in an ipv6 network
<chmj> strange becouse it work fine with .10 
<chmj> no problems whatsoever 
<Lathiat> Hey Guys, is there any chance of inclusion of the host skas3 patch in ubuntu's kernel?
<fabbione> no
<fabbione> all this kind of patches are unmaintanable in the long run
<Lathiat> right
<Lathiat> i wonder if the evil module hack is still maintained :)
<jbailey> Last year, there was a guy who had moved the IDE drivers into userspace at OLS.
<jbailey> I wonder if that's gotten anywhere?
<Lathiat> uh, why?
<Lathiat> one thing thatd be nice to have in userspace is ppp
<jbailey> Because once you can get something as key as your IDE driver efficiently into userspace, you've got a reasonable model for alot of things.
<Lathiat> doesnt that mean that your goign to be context switchign all over the joint tho?
<jbailey> Read in the word 'efficiently'
<Lathiat> sure, but how can you do it efficiently?
<jbailey> His tests showed a speed improvement over in-kernel IDE drivers.
<jbailey> Dunno, he was still doing the research on why it was faster.
<jbailey> I know how it works in the L4 world, where context switches are cheap.
<jbailey> On Linux I'm not sure how it would work.
<Lathiat> so speed improvement in L4 or speed improvement in linux?
<jbailey> It was entirely in Linux.
<Lathiat> hm
<jbailey> The only research *i've* done on userspace drivers was in the context of Hurd and L4.
<Lathiat> What are the benefits of having this in user space?
<jbailey> IDE drivers?  Very little.  Drivers in general?  Fewer needs for custom kernels.
<Lathiat> right
<Lathiat> itd be nice to have things like ppp in userspace
<Lathiat> so things like the mpppe kernel module dont need to exist
<jbailey> Yup.
<Lathiat> and then morton doesnt need to sneak them in with other stuff ;)
<jbailey> I can see it being possible that the speed up was from some user->user buffer optimisation with userspace file system so that context switch penalty is negated.
<jbailey> But that wouldn't do anything for streams/character devices.
#ubuntu-kernel 2005-07-13
<fabbione> morning
<lamont> fabbione: 2051 Needs-Build
<fabbione> hehe cool
<fabbione> i saw the big flush in the archive
<fabbione> i also found a user for you :)
<lamont> yeah.  much suckage
<fabbione> lamont: one of the redhat developers has an hppa waiting for you be installable ;)
<lamont> fabbione: cool
<fabbione> lamont: yeah eheh
<lamont> it's debootstrappable now, I believe (hoary, from my archive on people.u.c)
<lamont> but I want to get the rest happy
<fabbione> lamont: make sense
<lamont> anyway, off to bed for me.
<fabbione> good night dude :)
<fabbione> hey JaneW 
<JaneW> hi fabbione
* chmj gets a headache from git tool s
<jbailey> fabbione: around?
<fabbione> jbailey: more or less....
<jbailey> fabbione: Two questions.
<jbailey> 1) Did you look at that list?
<fabbione> jbailey: yes
<jbailey> 2) Do you know any way of getting a log out of the kernel of the hotplug events that it sends?
<fabbione> 2) yes....
<jbailey> 1) Sweet!  Any thoughts?
<fabbione> let's take one at a time because i have a huge headacke
<jbailey> 2) Fabulous?  Can you point me how?
<jbailey> 'k
<fabbione> 1) the list looks incomplete to me, specially for the network drivers, but i didn't really check all of it in a deathmatch 
<fabbione> for hotplug
<fabbione> just read /sbin/hotplug
<fabbione> and use a generic rul in /etc/hotplug.d/default/
<jbailey> Okay, so I need to modify the script to collect the information and post it.  No worries.
<jbailey> I was hoping for something like dmesg.
<fabbione> basically what you do is something like /etc/hotplug/*.hotplug
<fabbione> no no.. you need to add one
<fabbione> check on of the scripts in /etc/hotplug/
<fabbione> you put a similar script in /etc/hotplug.d/default/
<fabbione> in which you just enable the debugging
<fabbione> and do something like:
<fabbione> #/bin/sh
<fabbione> shift;
<fabbione> meh
<fabbione> without shift
<fabbione> echo HOTPLUG DEBUGGING: $@ >> /var/log/$whatever_log_file
<jbailey> Cool.
<fabbione> or use the debugging infrastructure that's in place
<fabbione> it's very very simple really
<jbailey> Yeah.  I was mostly hoping that there was already stuff there, no big deal I can take it from here.
<fabbione> jbailey: there is a set of functions to debug
<fabbione> but it's basically a wrapper to echo
<jbailey> fabbione: For the initramfs list, I'll start with that for now, things can always be added as we get testers.
<jbailey> I'll start by adding all of those into the modules in the initramfs and then we can move that to the kernel afterwards.
<jbailey> We'll have to make sure that we still usefully support custom kernels, I guess.
* jbailey has trouble having sympathy.
<fabbione> jbailey: we don't have much time to play with the kernel...
<fabbione> if want them in the kernel it needs to be asap
<zul^> you think they would turn off my computer at the old place i was working
<fabbione> otherwise we can move it in breezy+1
<fabbione> ahhaha
<fabbione> hacker
<zul^> i wouldnt do that..
<zul^> they still havent paid me yet
<zul^> ;)
<jbailey> fabbione: Hopefully, I'll have stuff to you for next week for moving it.
<jbailey> The week after I'm away at OLS.
<zul^> jbailey: you are a glutton for punishment arent you?
<fabbione> jbailey: ok.. next week is going to be a kernel marathon
<zul^> fabbione: wha?
<jbailey> zul^: Nah, my liver has had a year to recover.
<fabbione> so if we can we should get it in next week
<jbailey> fabbione: In ubuntu?
<fabbione> zul, jbailey: yes.. in ubunut = for me
<jbailey> Ah. =)
<fabbione> i need to fix udeb creation... some other stuff
<zul^> jbailey: yeah but you are going to be in ottawa though thats punishent enough
<fabbione> try to do some bug triage
<jbailey> Cool, so we'll call that the time for all the initramfs integration and stuff too.
<fabbione> and see if i can finally merge zul work without crashing my balls
<jbailey> zul^: It's almost walking distance to get there now!
<fabbione> jbailey: exactly
<zul^> fabbione,: :P
<zul^> you can take the voyager bus :)
<zul^> right i have to get ready for work
<fabbione> jbailey: if we schedule it properly, i can shift my working hours to overlap with you
<jbailey> zul^: It's longer than a 2 hour bus ride, so I won't do it.
<fabbione> jbailey: like i can start around 1/2 am UTC
<jbailey> fabbione: Yeah, I'll have to figure this out, since I wanted to be available for dilinger and his initramfs in debian hacking too.
<fabbione> well dilinger is in NY
<jbailey> .fi
<fabbione> ah
<fabbione> ok
<fabbione> so you are the only one out of EU sync...
<fabbione> tough luck jb
<jbailey> Right.  Well, you get up at silly hours of the day, though.
<fabbione> you are going to stay awake with us :)
<jbailey> And he's likely to stay up all night and hack.
<jbailey> I can adjust my hours to match you, though. =)
<fabbione> btw.. did they open any #debconf channel yet?
<jbailey> Should be, I imagine.
<fabbione> brb
<jbailey> yup, on freenode
<fabbione> re
<zul^> cool...so there is a foundation now
<fabbione> yeah.. i wonder how it's going to work exactly
<jbailey> fabbione: I started a questions page on the internal wiki
<jbailey> fabbione: Feel free to populate it/
<fabbione> jbailey: yes i saw it
<zul^> i didnt ;)
<zul^> phew i need to have a shower
<tvo> hi
<tvo> will the kernel supplied with breezy support inotify?
#ubuntu-kernel 2005-07-14
<infinity> Meh.  My new intel a/b/g wireless NIC works great... Until I try to pump some data through and it drops connection completely.  Joy.
<infinity> Takes an rmmod ipw220 && /etc/init.d/hotplug restart to bring it back again.
<infinity> Guess I should upgrade to breezy and do some testing.
<jbailey> infinity: ipw220 is apparently fubar on recent breezy kernels,stick with 2.6.10 or so for now.
<jbailey> Except that the next udev update requires 2.6.12
<jbailey> JOY JOY JOY
<infinity> jbailey : It can't be much more fucked than this, really.
<infinity> jbailey : Besides, I'm apparently on the kernel team, so it's time to start doing something useful for it (like hacking that driver to work with my new laptop)
<jbailey> What, your wife out of town again?
<jbailey> =P
<infinity> No, in fact I have a date to do some photography with her in about 20 seconds.
<infinity> But then I go back to nerdy things.
<infinity> Well, that's neat.  2.6.12 works much better for me.
<sivang> infinity: whom are you photographing ? :-)
#ubuntu-kernel 2005-07-15
<dilinger> fabbione: ping
<dilinger> ubuntu doesn't use linux-tree at all, right?
* dilinger notices the hoary version of linux-tree doesn't actually have a proper ltversion
<dilinger> fabbione: fyi, we're changing the packaging names in debian; they pretty much match ubuntu's packaging naming, except that the source package name is different
<dilinger> linux-source-2.6.10 (ubuntu) vs linux-kernel-2.6.12 (debian).  and actually, that might further change to linux-kernel-2.6, after a bit of discussion
<fabbione> dilinger: tbh i can't remember about linux-tree .. i will need to check.. iirc we generate it
<fabbione> dilinger: but we are not going to rename the kernel package.. too many troubles..
<fabbione> for no real gain
<fabbione> doko: fix gcc-4.0.1. kthxbye
<fabbione> doko: i did send you a mail with the FTBFS log
<fabbione> anyway i need a shower...
<fabbione> dilinger: the main issue right now is that breezy is already past UVF and in less than 3 weeks (for my packages) feature freeze
<fabbione> i don't think we will ever manage to sync in 3 weeks
<fabbione> just to be completely hounest...
<fabbione> i am afraid this will be breezy+1 task
<fabbione> but we can talk about it again tomorrow
<fabbione> it's sunday :)
* netjoined: irc.freenode.net -> kornbluth.freenode.net
#ubuntu-kernel 2005-07-16
<fabbione> morning
<fabbione> lamont: you around by any chance?
<fabbione> jbailey: ping?
<fabbione> Inconsistency detected by ld.so: rtld.c: 1075: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
<fabbione> AMEN
<fabbione> JaneW morning 
<JaneW> morning fabbione - good week-end?
<fabbione> JaneW: it was ok... nothing spectacular.. and you?
<JaneW> fabbione: ok, mine was great thanks - didn;t touch a computer once ;)
<fabbione> ehhe i almost didn't :)
<TheMuso> 
<chmj> ?
<TheMuso> apologies. Flicking through Irssi windows and bumped some other keys. :(
<lamont> fabbione: ack
<fabbione> lamont: i need kernel-wedge 2 installed in the hppa chroot
<fabbione> i am going to do some heavy build orgies tomorrow
<mx|gone> who takes care of the linux-wlan-ng patch?
<lamont> fabbione: will a simple dist-upgrade do the trick?
<lamont> 119 upgraded, 11 newly installed, 0 to remove and 6 not upgraded.
<fabbione> lamont: if you have enough breezy pkgs yes.. but you can just install that specifically.. it's a _all.deb
<fabbione> mx|gone: it depends...
<lamont> The following packages have been kept back:
<lamont>   apt dselect html2text libosp4 sp tetex-bin
<mx|gone> fabbione: who would I ask to update the patch to a recent svn snapshot?
<fabbione> mx|gone: no svn snapshots.. only releases..
<lamont> hrm... ew.
<mx|gone> fabbione: damn... the last release has some problems that are fixed in the snapshot...
<lamont> what gcc are we using to build the kernel?
<fabbione> mx|gone: but usually you file an "enanchement" bug
<fabbione> lamont: gcc-3.4
<lamont> dpkg -l gcc-3.4
<lamont> No packages found matching gcc-3.4.
<lamont> hrm... gonna fix that
<lamont> the only thing bothering me is that the gcc-3.4 we have generally available for hppa is from hoary (3.4.3-9ubuntu3)
<fabbione> well for hppa there is gcc-3.4-hppa or something..
<lamont> so don't do any user-space builds. :-)
<fabbione> i am not going to :)
<fabbione> i need to build the kernel
<lamont> devel/linux-source-2.6.12_2.6.12-3.3: Uploaded by buildd+bld-18 [optional:out-of-date] 
<lamont> but seems to need NEW love
<mx|gone> fabbione: ok, later today I'm going to submit a patch to the linux-wlan-ng guys that will make it work with iwconfig completely... if that gets accepted, would you guys still need a release?
<fabbione> mx|gone: yes
<mx|gone> suck, ok
<lamont> fabbione: dist-upgrading now
<fabbione> lamont: no rush.. i am done for the day
<fabbione> and i will crash it tomorrow :)
<lamont> hehe
<lamont> dist-upgrade included kernel-wedge_2.05ubuntu1, iirc
<fabbione> you probably want to warn your friends that i am going to push the cluster a bit :P
<fabbione> just in case nagios will make the machines look redish ;)
<fabbione> jbailey: i have been doing more thinking about initramfs modules shipped directly by our kernel
<fabbione> jbailey: i don't think it's a good idea to do it
<fabbione> or better.. there are some cons i didn't think about
<fabbione> like enlarging the package of N MB
<fabbione> that's seems to be quite a lot
<fabbione> in order to make these initramfs files we will need to change make-kpkg...
<fabbione> becuase at least custom compiled kernels should have the same treatment
<fabbione> but than you hit a bigger issue
<fabbione> what if driver foo in our kernel is either compiled in or not available in custom kernel?
<fabbione> what the initramfs creation tool is going to do in that case?
<fabbione> (since we feed it with some lists)
* jbailey sharpens a stick and goes on a rampage against all those with custom kernels.
<fabbione> jbailey: i agree with you, but there are some cases i am thinking of custom kernels where the user actually might want to be able to add drivers to the initramfs
<fabbione> we need to try to make these operations simpler
<fabbione> instead of more complicated
<jbailey> Right.
<jbailey> Adding drivers to the initramfs is as easy as adding modules.
<jbailey> err
<jbailey> names to /etc/mkinitramfs/modules
<jbailey> But it doesn't solve the annoyance of having to add to make-kpkg
<fabbione> exactly
<fabbione> i am really not 100% sure what's the best in the long run, but i think for breezy it's better we keep initramfs as close as possible to initrd
<fabbione> it will give people time to look at it and see 1) what problems it has 2) how it can evolve
<fabbione> 3) and clearly how much better it is compared to initrd ;)
<lamont> jbailey: in other news. ../net.c:948: error: field `nl' has incomplete type
<lamont>  on at least 2 architectures
<fabbione> same here :)
<fabbione> lamont: what package?
<fabbione> i remember i have seen it... i don't remember where
<lamont> strace
<lamont> and others
<fabbione> yeah
<fabbione> ../net.c: In function 'printsock':
<fabbione> ../net.c:948: error: field 'nl' has incomplete type
<fabbione> ../net.c:950: confused by earlier errors, bailing out
<fabbione> same on sparc
<fabbione> lamont: do you know if elmo did setup logs@ ???
<lamont> and i386, ppc, and ia64.  not sure what the story is with amd64...  guess I could go look
<jbailey> lamont: Sorry, which package?
<fabbione> strace
<lamont> ah, building on crested, which is down...
<lamont> that could explain it
<fabbione> lamont: amd64 is fucked for other reasons too
<lamont>  /usr/include/resolv.h:110: error: field `nsaddr_list' has incomplete type
<fabbione> (see ocfs2-tools FTBFS)
<jbailey> lamont: I fixed hfsplus, haven't done the other two yet.
<lamont> that's iputils, fwiw
<fabbione> it's also missing iptables
<fabbione> and iproute
<lamont> iptables has need of some love, iirc
<lamont>  /usr/include/linux/config.h:1:2: #error "Compilation aborted. Please read the FAQ for linux-libc-headers package."
<lamont>  /usr/include/linux/config.h:2:2: #error "(can be found at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/doc/)"
<fabbione> i have seen a bunch of those in universe too
<jbailey> Right, those are all broken applications.
<jbailey> I'll fix iptables, and do up a FAQ sheet for the universe bits.
<lamont> woot
<jbailey> Including config.h is bad.
<fabbione> including kernel headers in apps is BAD
<fabbione> full.
<jbailey> Mmm..  I only half agree.
<jbailey> If you're using kernel facilities directly, using kernel headers makes sense.
<jbailey> If only the kernel would provide a decent set.
<fabbione> jbailey: linus doesn't agree with you :)
<fabbione> even for that half
<fabbione> and i tend to agree with him :)
<jbailey> Right.  Linus has said that there's no promises in the userspace to kernel space ABI, which is a bit frightening.
<fabbione> exactly.. kernel headers changes a lot
<fabbione> so it might build today
<fabbione> tomorrow is broken again
<jbailey> Should - who should provide the headers then?
<jbailey> Certainly not glibc, it's not providing the facility.
<fabbione> glibc ?
<jbailey> Also, that doesn't allow for systems using other C libraries.
<jbailey> The only thing might be if glibc were to provide a wrapper for every syscall that iptables, iproute and friends want to call.
<fabbione> anyway.. it's time to go and start preparing dinner
<jbailey> But that's a bit excessive.
<jbailey> Enjoy your dinner. =)
<fabbione> jbailey: tbh this is one of the few things i don't really care...
<fabbione> given that different userland upstreams can keep up with the kernel..
<fabbione> when they break i blame upstream for userlend
<fabbione> land even
<jbailey> fabbione: Right.  But this is where the conflict is.  We can't say that including kernel headers is bad until someone is stepping forward to say "Link against library FOO with headers FOO instead" and noone has done that.
<fabbione> jbailey: i am not sure.. i think linus and other did that.. but after the usual 2/3 messages out of the endless thread i get bored and delete the thread
<fabbione> it's a topic that shows up at least once a month on lkml
<jbailey> I haven't seen anyone doing that.  I wish they would.  All I see is a hot potato being tossed around.
<fabbione> :)
<jbailey> Mmm potatoes.
* jbailey is getting hungry.
<fabbione> yesterday i did grill peppers, obergine and squash...
<fabbione> with a bit of garlic and oil of olive...
<fabbione> (on top)
<jbailey> We finally got a stove on friday.
<jbailey> It's hard to cook in 30 weather.
<jbailey> Hopefully we'll get a bbq this fall for grilling.
<fabbione> today i am up for tomatoes with rice and meat with cheese topping...
<fabbione> but i think you can make easily a vegan variant out of it
<jbailey> I'll probably do a fruit salad and a tofu scramble for lunch.
<jbailey> Sure. =)  I'm good at those.
<jbailey> We'll have to have you over for dinner next time you're in Montral. =)
<fabbione> jbailey: can you actually eat rice, can't you?
<jbailey> Yup
<jbailey> I usually have rice at least once a day.
<fabbione> than do this:
<fabbione> take the tomatoes, open only the top
<fabbione> empty it and keep the inside
<fabbione> boil some rice
<fabbione> fry some mushrooms...
<fabbione> mix the rice, the mushrooms and the inside of the tomatoes
<Lathiat> take some frogs legs
<fabbione> mix them very well
<fabbione> and fill the tomatoes again with that
<fabbione> put in the oven....
<fabbione> enjoy
<jbailey> Any spices in with the mixture?
<fabbione> the best would be with mozarella on top, but well...
<fabbione> jbailey: you can use rosmarine and basilicum
<jbailey> Cool.
<fabbione> perhaps i would put rosmarine together with the rice mix
<fabbione> and fresh basicilum on top (instead of the cheese)
<jbailey> Angie dislikes mushrooms, but I suspect that diced aubergine might be nice in there.
<fabbione> jbailey: i am pretty sure you can use whatever veggy you like best in the mixture...
<jbailey> That sounds terribly good. =)
<fabbione> try and let me know :)
<fabbione> i eat them with meat, this is a fast omnivor2vegan regexp ;)
<fabbione> but it might actually work :)
<fabbione> and with this i am going to cook...
<fabbione> later fellas
* fabbione &
<jbailey> 'bye Fabio. =)
<lamont> fabbione: gsyprf11's chroot updated
<lamont> fabbione: btw, redhat-cluster-suite links shared libs with ld instead of gcc.  bad R-C-S.  Either that needs to be fixed, or you need to buy jbailey a pallet of his favorite, which might _still_ not be enough to fix the issue.
<jbailey> fabbione: 
<jbailey> missing module eata_pio
<jbailey> command exited with status 1
<jbailey> make: *** [binary-udebs]  Error 2
<jbailey> This doesn't sound like the bug you're reporting.
<jbailey> Any chance of a more reduced testcase?
<jbailey> Or do you have something poisoned in your ccache somehow?
<fabbione> lamont: yes i know it does, but linking with gcc seems to create non-PIC code
<fabbione> jbailey: i have no idea why it works for you
<fabbione> but definetely it doesn't for me
<fabbione> i can try to flush the ccache..
<lamont> fabbione: it shouldn't....
<lamont> linking with ld means that it needs to be aware of whatever additional libraries gcc sticks on the ld command line, if it wants to work.
<fabbione> lamont: apparently it does :)
<lamont> specifically, hppa needs an extra lib passed to ld for shared libs to work
<fabbione> lamont: we did try to use gcc
<fabbione> and it ended up with lintian/linda complaning about non-PIC libs
<mxpxpod> fabbione: it looks like linux-wlan-ng is going to make a release this week :)
<fabbione> mxpxpod: ok
<mxpxpod> fabbione: do you want me to let you know when it happens since I keep up on it?
<fabbione> up to you. we have an automatic tool that goes around and check for us
<mxpxpod> ah, ok
#ubuntu-kernel 2005-07-17
<fabbione> morning
<jbailey> lamont:   * Do not include linux/socket.h in configure.  There are
<jbailey>     no parts in here that we use. (Closes# One of LaMont's rants)
<lamont> ;p;
<lamont> heh
<lamont> hrm.. gotta work on that keyboarding hand-position
<fabbione> ehehe
<fabbione> lamont: i suspect the hppa patch needs an update...
<fabbione> do you pull it in directly from cvs or do you apply extra love on top of it?
<lamont> the only extra love is to remove the Makefile patch
<fabbione> ok.. that's easy enough :)
<fabbione> http://cvs.parisc-linux.org/ ??
<lamont> you gonna do it, or you want me to>?
<fabbione> i can't remember the full url...
<fabbione> i can do it...
<lamont> cvs.parisc-linux.org/download/linux-2.6 ???
<fabbione> there we go :)
<lamont> yeah - that's it./
<fabbione> 2.6.12-pa2 looks like a good candidate :)
<lamont> note that -pa0 is always a 'we merged it but haven't booted it yet' tag.
<lamont> -pa1 is the first one that boots.
<lamont> for 2.6.12, you want -pa2
<fabbione> exactly what i said :)
<fabbione> i wonder what's the status with C++ apps in universe
<fabbione> they are stalling a lot of other stuff for me
<fabbione> jbailey: did you have any time to look at that FTBFS i did send you?
<fabbione> with the duplicate _LINK_ thingy?
<fabbione> it's stalling quite a bunch of packages in main atm
<lamont> fabbione: I just added a check to my upload process so that I don't upload anything that Depends libstdc++5 :-)
<fabbione> lamont: eheheh
<fabbione> do i need something like that?
<jbailey> fabbione: Remind me which package that was?
<jbailey> Rception de: 2 http://archive.ubuntu.com breezy/main iptables 1.3.1-2 (tar) [1283kB] 
<jbailey> 1284ko rceptionns en 4s (310ko/s)
<jbailey> dpkg-source: error: unrecognised file suffix `.tar'
<jbailey> eh?
<fabbione> jbailey: there are 2 or 3.. but i did send you only one email
<fabbione> ok.. forwarded another one :)
<fabbione> jbailey: iptables seems to be native package
<fabbione> if so you can't have the deb version -2
<fabbione> it needs to be changed
<jbailey> Stupid rule.
<fabbione> yes i agree
<jbailey> I use - versions in all of my native packages for a reason.
<jbailey> iptables is about to be a good example of one.
<fabbione> lamont: did you hear anything about breezy-auto-rebuild-test?
<fabbione> if they keep postponing it, the MOTU's will NEVER manage to upload 500 pkgs in time
<lamont> fabbione: have heard nothing new
<lamont> it's ready to go on my end
<jbailey> I love figuring out new build systems.
<jbailey> Anyone here hacked the iptables package before willing to help me shave 30 minutes off of learning this thing?
<fabbione> jbailey: i did twice.. after that i did run away screaming...
<fabbione> if you can give me 10 minutes i will help you
<fabbione> gotta wake up my wife
<jbailey> Sure, or I'll ask you in the morning.
<fabbione> or you can tell me what to look for and i can hack on it ;)
<jbailey> fabbione: Find all instances of #include <linux/config.h> and prune.  Find out what defines they're looking for and hardcode them in a local <config.h> or something.
<jbailey> "config.h" rather.
<jbailey> ROAR
<jbailey> iputils includes custom versions of glibc headers.
<fabbione> re
<fabbione> jbailey: sounds simple enough
<jbailey> Oh well, bed time.
<jbailey> See you in a few hours.
<fabbione> jbailey: good night
<lamont> gnight
<fabbione> jbailey: i don't think removing linux/config.h is exactly an option for iptables :)
<fabbione> grep "<linux/config.h>" * -r | wc -l
<fabbione> 202
<fabbione> it has a full local copy of kernel-headers in the package
<fabbione> uhuh the fix seems to be MUCH easier :)
<fabbione> libipq/libipq.c:376: error: 'union <anonymous>' has no member named 'vwmark'
<fabbione> HMMMM
<fabbione> JEEEEEEEEEEEEEEEE
<fabbione> the iptables maintainer should burn in hell
<Lathiat> rusty? ;p
<fabbione> he applies patches that require kernel patching
<fabbione> otherwise they are completely pointless
<fabbione> lamont: are you still around?
<fabbione> lamont: i need ccache and distcc on the hppa chroots....
<fabbione> lamont: and idiot-tg3 iodine-tg3 are still there or they have been removed?
<fabbione> i was told i could use them as distcc clients
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<fabbione> hey mjg59 
<fabbione> mjg59: patch applied...
<fabbione> thanks
<mjg59> No problem
<mjg59> Now I just need to sort out the SATA resume stuff...
<mjg59> fabbione: What exactly did Jeff Garzik say about the sata suspend/resume patch?
<fabbione> that it breaks at least scsi 
<fabbione> that means a lot of stuff
<fabbione> and it was "experimental"
<mjg59> I'm struggling to see how it breaks the SCSI layer
<mjg59> Though it certainly doesn't provide suspend/resume support for SCSI
<fabbione> i dunno.. he says that it breaks hard.. 
<mjg59> Hrm.
* infinity now has a laptop with SATA, so would like to get in on this whole SATA resume business..
<zul> hey
<lamont__> yeh?
* jbailey hands some hay to Chuck
<zul> meh..
<zul> healthcare it is fun..
<jbailey> You live in Ontario, I don't think you have that anymore.
<zul> heh
<zul> yeah we do its called pay as you go
<lamont__> zul: healthcare is more fun when you're the one _doing_.
<zul> later...
<dilinger> so, uh
<dilinger> anyone know where linus' git tree went?
#ubuntu-kernel 2006-07-10
<zul> hey infinity 
<infinity> Hey.
<ajmitch> morning infinity 
<zul> hey
<mag_> Hello... I've got this serverworks/broadcom sata chip on a server motherboard that doesn't get detected by the dapper install. Is there any easy way to get or create a installer with a newer kernel that recognizes the new pciids?
<mag_> It's the ht1000 sata device
<mag_> Is the kernel that ubuntu installer uses a normal kernel or is it patched in any special way?
<mag_> bye, thanks for the support :)
<zul> later
#ubuntu-kernel 2006-07-11
<zul> BenC: why the hell does it try to make xen-xen0-2.6.16 when i have xen-image in my control file?
<BenC> no idea...something in make-kpkg
<zul> yeah...is it possible to merge all of kernel-package since there might be some breakage with xen stuff that we dont know about from the patch
<zul> since kernel-package also breaks xen on amd64 as well according to the changelog
<zul> pretty please ;)
<BenC> I'll work on it this week
<zul> thanks
<zul> hmmm...kernel-package wants to set i_package to $(INT_STEM)-xen0-$(version) when CONFIG_XEN_PRIVILEGED IS set which i dont want it to do..
<zul> im so tempted not to use kernel-package for xen-linux
<ivoks> km, km, vmplauer-kernel-modules need rebuild :)
<ivoks> vmware-player-kernel-modules
<zul> eh?
<ivoks> vmware-player-modules are still for -23 kernel
<zul> ah ok the abi bumb
<ivoks> right
<zul> ill let Ben know
<allee> zul: can't openafs-modules-source be added to the list of to-rebuild pkgs too? ;)
<zul> allee can you open a bug please im at work right now
<allee> 'k, 1st ssh-krb5 crash, then openafs-modules wish
* allee steps into too mmany AFS pitfalls 
<Keybuk> BenC: ping?
<zul> BenC: vmware-palyer needs to be version bumped
<BenC> Keybuk: pong
<BenC> zul: Ah, want to upload that again?
<Keybuk> BenC: so, talk to me about linux-kernel-headers vs. linux-headers
<Keybuk> what's the plan for edgy?
<BenC> I included the patch for hdrinstall2 in edgy kernel
<BenC> just waiting on jbailey to see if the kernel headers are able to be used, and if so, I'll be building linux-kernel-headers out of edgy's kernel build
<Keybuk> ok, and how will that differ to the linux-headers package?
<BenC> the only difference between linux-kernel-headers and linux-headers-2.6.17 (which is binary-arch as well) will be the installed location
<BenC> oh wait, no that's wrong
<BenC> the hdrinstall actually removes a lot of the files and file contents (removed everything wrapped in #ifdef __KERNEL__)
<BenC> so there's a lot of difference
<Keybuk> ok
<Keybuk> so if this works, we'll be able to drop the linux-kernel-headers source package entirely?
<BenC> yeah
<Keybuk> cool
<Keybuk> BenC: btw, do you plan to merge kernel-wedge and kernel-package today?
<BenC> within the next few days
<BenC> kernel-wedge should be easy, but kernel-package isn't
<Keybuk> there's only one day left until UVF
<Keybuk> when all merges need to be completed by
<BenC> considering they both only really affect linux-source, can I get an exception? :)
<BenC> I'm working on them today, but I can't guarantee I'll be able to test kernel-package fully
<Keybuk> ok
<Keybuk> try and at least get an upload before thursday
<zul> BenC: sure i can do it tonight
<BenC> ok, no problem
<BenC> zul: thanks
<zul> your welcome :)
<jbailey> BenC: If you need a tester with the kernel nULL pointer dereference problem, my laptop has it.
<BenC> I have a feeling 5.7 will fix it
<zul> what are we at now for abi for dapper?
<zul> 26?
<jbailey> BenC: 'kay.  If you have a build for i386, I'll test it anytime. 
<jbailey> Otherwise I'll grab it when you upload.
<BenC> kernel-dailys has a -5 build
<BenC> zul: 26
<BenC> jbailey: that should have the fixes
<jbailey> BenC: Cool, thanks.
<astraw> I'm trying to apply a patch to the git kernel tree for dapper. The problem is I bump the version in the changelog (e.g. from 2.6.15-26.44 to 2.6.15-26.44.ads1) so my .debs supercede previous .debs but are replaced by future .debs, but then I get an ABI error: "Missing .../abi/2.6.15-26.44/i386/386 file". I've worked around this by generating the old .debs, then applying my patch, then re-generating, but this takes a long time.
<jbailey> update-grub didn't seem to get run when I installed the daily.
<jbailey> Nope, I'm on crack.
<jbailey> I wget'd the deb and didn't install it.
<jbailey> BenC: The daily from July 8th appears to be working.
<BenC> sweet
<astraw> BTW, the only reason I'm doing this is to fix bug #41228 (incorrect timestamps in video1394), so if that could get rolled into the next bugfix release, that'd be great.
<BenC> astraw: Please read KernelGitGuide in topic for the best way to submit patches (especially since you have a git tree to do it from)
<astraw> BenC: will do. Also, I just found the AUTOBUILD=1 setting. Gotta run now.
<BenC> people really need to read more thoroughly
<BenC> it specifically says that it is only useful in 2.6.17/edgy kernel
<jbailey> USer's don't read. =)
<zul> huker on phonics wurked for me
<BenC> zul: feh, it's FONICKS
<BenC> even I know that
<zul> im canadian eh?
<BenC> oh, sorry, eh :)
<zul> lol
<BenC> jbailey: do you know the bug number for that oops?
<jbailey> BenC: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/51488
<jbailey> No ubugtu here?
<jbailey> Hmm, weird.
<zul> nope
<jbailey> BenC: It occurs to me that with lkh merging into the kernel, that you have to be part of edgy +1 toolchian roadmap.
<jbailey> In the sense that the new lkh should be uploaded with glibc/gcc at the start of the release.
<BenC> that sucks :)
* BenC was trying to stay away from the toolchain thingy
<kylem> :)
#ubuntu-kernel 2006-07-12
<jbailey> BenC: MWAHAHAHAHAH
<jbailey> I mean.
<jbailey> It's all good. =)
<chuck_> who...xen-image-2.6.16-1-xen-686_2.6.16-1_i386.deb
<jbailey> Nice!
<jbailey> Next I should make libc6-xen not suck.
<jbailey> Hmm
<jbailey> Maybe later this week.
<jbailey> Still one more merge to do tomorrow.
<zul> hey
<zul> hey BenC 
<BenC> hey
<BenC> kernel-wedge is done, finishing up kernel-package
<zul> cool...
<BenC> infinity, jbailey: ping
<zul> whoo...lunch time
<jbailey> BenC: pong, about to go for lunch
<BenC> jbailey: nm, I'll ask adam about initramfs-tools
<Keybuk> ask him which?
<BenC> I want to sync it with debian along with kernel-{package,wedge}
<jbailey> BenC: I'm doing initramfs-tools
<jbailey> Don't sync it.
<jbailey> It would break alot of things.
<BenC> ah, ok
<jbailey> Like, anyone who needs a framebuffer to work. =)
<BenC> I'm really surprised that kernel-package isn't using update-initramfs now that it's in debian's initramfs-tools
<fabbione> jbailey: while you are at it can you also look at the bug i did open today?
<BenC> anyone know how debian is doing this...I recall they had a smimilar tool now
<BenC> Keybuk: kernel-wedge uploaded
<BenC> kernel-package is almost done
<Keybuk> cool
<jbailey> BenC: Debian still supports yaird.
<zul> yaird?
<Keybuk> yet-another-init-rd
<zul> ah ok
<jbailey> Creative naming and all. =)
<zul> hehe..
<makx> BenC: mkinitramfs-kpkg
<makx> wrapper around mkinitramfs
<makx> Manoj wanted to stay on old style calling convention of initrd/initramfs generators
<makx> yaird is dead water doesn't have decent uuid support
<BenC> where's that script come from?
<jbailey> makx: Does yaird's author consider it dead yet?
<jbailey> makx: Are do we still have to crush it with proper dep support in initramfs-tools.
<makx> jbailey mia since end of last year
<makx> proper dep support is on my TODO list
<BenC> let's see how badly I screwed up this kernel-package sync
<makx> but i'd prefer to have klibc only initramfs before
<makx> that is much higher priority
<makx> BenC: yaird is a perl vodoo
<jbailey> makx: infinity said that he thought dep mode should be easy enough to do with the infrastructure in there.
<BenC> makx: No, I want to know where mkinitramfs-kpkg comes from :)
<jbailey> But that klibc-only meant that you need to have some ability to detect when it's going to need more and then go all glibc/busybox.
<makx> BenC: initramfs-tools
<jbailey> Oh?
<jbailey> I haven't started the merge yet, is that something I need to bring into Ubuntu?
<makx> jbailey: busybox needing boot scripts put an echo "BUSYBOX=y" in /usr/share/initramfs-tools/conf.d/<package>
<Keybuk> jbailey: which merge haven't you started yet ?
<jbailey> Keybuk: initramfs-tools. 
<Keybuk> jbailey: !!
<jbailey> Keybuk: I'm not doing any other merges.
<makx> jbaley: depends on your kernel-package
<jbailey> Keybuk: What, there''s still 4 hours left in my workdayu.
<makx> uups evident typo
<Keybuk> jbailey: hehe, you think you can do it in 4 hours? :p
<jbailey> Keybuk: I sponsor almost every upload to Debian.
<Keybuk> fair enough
<jbailey> Keybuk: That's why I still know the code as well as I do. =)
<Keybuk> a klibc-only initramfs always seems like a waste of effort
<Keybuk> you have to compile everything twice, once for klibc and once for glibc
<makx> nack
<Keybuk> and then you find something that doesn't work with klibc, and *boom* you may as well just go back to glibc again
<BenC> if it was done right, it'd be awesome though
<Keybuk> sure, if we didn't need evms, lvm, etc. I'd love it
<makx> you get a much smaller initramfs
<jbailey> Keybuk: Given that klibc's on the running system, for anythign appropriate, you should just compile it once with klibc.
<Keybuk> jbailey: disagree,  you can't debug things compiled with klibc
<BenC> yeah, having klibc+glibc in initramfs isn't so bad
<jbailey> Keybuk: I've used gdb on klibc binaries.
<Keybuk> BenC: except it somewhat defeats the point of compiling things additionally against klibc in the first place ... at that point you may as well just compile them against glibc
<makx> Keybuk: more and more things will get klibc ready
<Keybuk> makx: really?
<BenC> klibc+glibc in corner cases isn't that bad, if we can make most installs klibs only
<Keybuk> given that the udev upstream has abandoned all attempts to make it work with klibc, I'd challenge that
<Keybuk> likewise the modprobe upstream
<jbailey> Isn't modprobe and udev upstream the same person? ;)
<Keybuk>             ^ new
<Keybuk> no, modprobe upstream is Jon Masters (now) and previously Rusty Russell
<fabbione> Keybuk: well because klibc was not entering linus tree
<fabbione> it is on its way now
<Keybuk> I'm all for a klibc-ONLY initramfs, don't get me wrong
<makx> kpartx works already
<fabbione> Keybuk: oh i was just explaining what will push upstreams to work with klibc
<BenC> eh, we should strive to get rid of glibc even on the running system and do klibc only :)
* Keybuk makes BenC stand in the corner
<Keybuk> that's almost Tollef levels of evilness
<jbailey> BenC: Spoken like a former glibc maintainer. =)
<fabbione> BenC: then we will see klibc growing up to libc7
<BenC> if you all continue to blame everything on the kernel, then I have no choice but to put everything in it :)
<fabbione> BenC: let's merge gcc and glibc into the kernel source
<fabbione> boot strap of death
<BenC> hehe, a bootstrap with real reboots :)
<jbailey> They proposed merging a c compiler in at one point.
<Keybuk> can we get X merged into the kernel too?
<fabbione> jbailey: there is already a bootloader that can build the kernel at boot time
<Keybuk> jbailey: tcc?
<jbailey> Keybuk: I don't remember which one, but it was along the lines of "We don't trust the optimisers anyway, so why not just use our own compiler?"
<cjb> Keybuk: X already *is* in the kernel, silly.
<BenC> X is just a kernel extension anyway...why give it a life of it's own
<fabbione> BenC: yeah right.. why all this drm/dri sync issues.. let's just add mesa and server and drivers to the kernel
<BenC> hmm...new kernel package screws up my automated build scripts
<Keybuk> actually, if we stick everything in the kernel, it'll stop them being evil and thinking about putting partition detection into userspace
<Keybuk> or filesystems into userspace, etc.
<BenC> or proposing perl/python/c++ kernel modules
<jbailey> Keybuk: Partition detection is *already* in userspace.
<jbailey> Keybuk: We just need to get the last dregs out of the kernel.
<Keybuk> I know, and I hate it
<BenC> like the part that reads the partion map? :)
<jbailey> BenC: If you use evms, and (I think) LVM, all of that is redone by a userspace daemon anyway.
<BenC> partition map could be done in userspace now, I think
<Keybuk> thank god evms and lvm are gone from our default install
<jbailey> Did we pitch lvm?
<BenC> using stuff like loop devices to point to block offsets on a drive
<Keybuk> jbailey: yeah, it's something that shouldn't be in by default
<Keybuk> if people want it, it can be installed
<jbailey> Keybuk: lvm is Good And Right, dude. =)
<Keybuk> no, it, is, not
<jbailey> Keybuk: The problem with just doing things on raw partitions is that it's hard to do anythign useful later on.
<jbailey> You can't just add a drive and span the partition, or add a drive and mirror.
<BenC> lvm doesn't scale well
<Keybuk> the idea might be cute, but the implementation is from the dark ages
<BenC> try creating > 800 logical volumes, and then restart lvm (if you actually get them created)
<BenC> you'll see what I mean
* jbailey tries to imagine a system where 800 LVs would be a good idea.
<BenC> office fileserver
<BenC> where each user has his own logical volume
<jbailey> To overcome how badly the quota system sucks? =)
<BenC> does away with silly quota stuff
<BenC> :)
<BenC> I actually used it in a commercial produce (www.swissdisk.com) so each customer has an encrypted filesystem
<BenC> s/produce/product/
<jbailey> Ah, I could see that.
<BenC> I had to man handle the meta-data areas
<jbailey> Although if you're doing that, you really want to make sure that it doesn't pre-allocate all the space for each user.
<BenC> hack the hell out of the userspace tools, just to keep things limping along
<BenC> the main problem is that it takes 20 minutes to start lvm
<BenC> rebooting the e4500 takes 10 minutes already...requiring 30 minutes for a reboot cycle minimum
<maswan> Yeah. I can see that sucking. Transparently migrating and extending filesystems does rock though. One of my favourite parts of AIX is the everything-on-lvm bit.
<BenC> yeah, the whole idea of lvm kicks ass
<BenC> but I agree with Keybuk, the implementation sucks ass
<Keybuk> all you really want is the ability to tell the kernel to create a block device, based on other block devices
<Keybuk> e.g. "foo1" is "sda1 from block 512 to block 1000" and then "sda2 from block 0 to block 1024"
<Keybuk> and have the kernel map foo1 block requests to the underlying physical blocks
<Keybuk> then you could set the block maps from udev
<Keybuk> and as foo1 would have a kobject in the block subsystem, udev would also know about virtual block devices
<BenC> dpkg-gencontrol: error: package linux-headers-2.6.17-5-g3611c20c-dirty not in control info
<BenC> kernel-package is really whacked out on this
<jbailey> BenC: Noone's really working on a better lvm, are they?
<BenC> "they seem me rollin', they hatin', patrollin' and trying to catch me ridin dirty"
<BenC> jbailey: not that I know of
<Keybuk> actually, it strikes me that the above would not be difficult to implement
<maswan> I still remember the painful migration to lvm2
<maswan> It would be good if someone got it right, really right. :)
<makx> fedora does default lvm installs irc
<makx> didn't knew that the ubuntu default installs no longer do it
<cjb> Nah, not default, just easy to add.  There's an lvm button.
<makx> without lvm2 even more args for klibc initramfs-tools: faster boot
<Keybuk> makx: not much faster
<Keybuk> it's all in RAM anyway
<Keybuk> cjb: that's the same theory we're taking, if someone clicks "LVM" in the installer, we can always add it
<BenC> Keybuk: kernel-package looks ok, but I want to do a full 6-arch build with it to make sure
<BenC> probably upload in a few hours
<Keybuk> okey dokey
<mdz> Keybuk: that's exactly what device-mapper does
<Keybuk> mdz: except that device mapper is its own subsystem, and doesn't just use the block subsystem
<Keybuk> and device-mapper isn't kobjectified
<Keybuk> etc.
<BenC> anyone familiar with the debconf voodoo?
<BenC> new kernel-package image postrm script calls purge() and it seems to be causing the postrm script to fail for some unknown reason (even though it "exit 0"'s at the end)
<BenC> if I comment out "my $ret = purge();", the script finishes and dpkg is happy
<BenC> excuse me, the script finishes no matter what, but with the purge() dpkg gets a non-zero exit
<cjb> Perl implicitly returns the last scalar evaled as a ret value.
<cjb> So if the exit 0 isn't in the path, I'd say that purge() is failing and it's being passed on.
<cjb> But I don't know the code.  Just letting you know that there's an implicit 'return $ret' on the end if that's the last assignment in the sub.
<BenC> so $ret is special?
<cjb> No, the last assignment of a sub is special.
<BenC> my $ret = purge();
<BenC> ....
<BenC> exit 0;
<cjb> Ah.
<BenC> the .... is mainly a var and a for loop
<cjb> Dunno, then.
<cjb> You're sure it's hitting exit 0, rather than an exit 1 inside purge() or something?
<BenC> yeah
<BenC> I placed warn's all the way down to just before the exit
<zul> later
<jbailey> Uh oh, someone from BC..
<Keybuk> jbailey: yeah, I've sent the boys around to find out what's happened to initramfs-tools :p
<jbailey> Keybuk: Hmm?
<jbailey> Oh, lol =)
<Keybuk> ya know what, I'm going to entirely abandon our n-m packages
<Keybuk> and just fix the Debian ones
<crimsun> that sounds entirely reasonable.
<jbailey> Keybuk: You could rejoin Debian and hijack the package ;)
<Keybuk> that would involve touching n-m :)
<johanbr> jbailey: Yes, watch out for us coffee-drinking hippies.
#ubuntu-kernel 2006-07-13
<zul> hey
<jbailey> Wow, really musn't leave this long between merges of initramfs-tools
<zul> oh dear i have the hiccups
<jbailey> The merged version only has 908 lines of diff now.  *sigh*
<zul> only?
<Keybuk> heh
<Keybuk> that's quite an improvement
<Keybuk> what are the major changes?  did we take the /etc/mkinitramfs => initramfs-tools change?
<jbailey> Yup
<jbailey> Alot of it was that they went through and cleaned up quoting.
<jbailey> We pushed hook scripts out to various packages.
<jbailey> (I've taken all of the quoting changes now.  yay debdiff)
<Keybuk> cool
<jbailey> Alot of the stuff that's in the Debian version is actually things from us.
<jbailey> So while there would be subtle things like quoting changes.
<jbailey> Or places where tab/8 spaces was different, they code was the same.
<Keybuk> ok, so we shouldn't expect much to change?
<jbailey> Right.
<jbailey> There's a new noresume feature.
<jbailey> And whee, the machine booted fine.
* jbailey reviews the ubuntu-old to ubuntu-new debdiff.
<jbailey> Keybuk: An interesting change is that rather than doing touch /dev/.initramfs-tools, it now does > /dev/.initramfs-tools
<BenC> kernel-package uploaded aswell
<jbailey> So you can always fetch more info from there.
<jbailey> Also, it fixes the ramdisk size for /dev at 10M
<jbailey> Adds cryptroot support
<jbailey> Apparently works with lilo better now.
<BenC> zul: I'd be interested to know if the new kernel-package handles your xen stuff well
<BenC> zul: I can send you a .deb if you need it
<zul> BenC: it doesnt work that great with the patch that we had, it didnt make the vmlinuz and when i tried making the kernel-image it wanted to make linux-xen0
<zul> debian doesnt use kernel-package for the xen0 kernels
<zul> other than that i been doing make and make install for the modules and vmlinuz
<jbailey> whee, accepted.
<jbailey> Off to spend the rest of the evening with my wife and sister-in-law.
<zul> if the kernel-package sees CONFIG_XEN then it wants to build the linux-xen0 image
<BenC> zul: I didn't port the xen stuff, just relying on the support already in kernel-package 10.x
<zul> BenC: i know :)
<BenC> you could just install the debian kernel-package, and for xen, it should be same
<BenC> ok :)
<zul> true...i havent tried the kernel-package since 
<DarkMageZ> can anyone confirm if r8169 exists in dapper's k7-26?
<crimsun> /lib/modules/2.6.15-26-686/kernel/drivers/net/r8169.ko
<crimsun> I don't see why -k7 would differ.
<cjb> likewise /lib/modules/2.6.15-23-k7/kernel/drivers/net/r8169.ko
<cjb> (which is k7 but not 26.)
<DarkMageZ> yeah, i did test the box against -23 (which it still has hanging around). hmm, i'll have to do more testing when i get back to work... thanks
<crimsun> -rw-r--r-- root/root     37174 2006-07-07 14:24 ./lib/modules/2.6.15-26-k7/kernel/drivers/net/r8169.ko
<DarkMageZ> yeah, i brought one of those cards yesterday and it just didn't work. i'll check over for me making noob mistakes and try again :) cyas
<cjb> Speaking of this stuff, is there a reason I'm not getting grub runs after kernel installs, after upgrading to edgy?
<cjb> .. or initrds made.
<zul> er....known bug
<cjb> Ah, thanks. 
<fabbione> BenC: i think we are going to readd gfs1 to the kernel together with gfs2
<fabbione> RH just realized that they can't kill one for the other without at least a 5 years overlap for transitioning :)
<zul> heh...redhat
<BenC> fabbione: ok
<fabbione> BenC: in any case i will do the merge if required
<fabbione> so you don't need to worry about it really...
<zul> bbl...im going back to bed
<Keybuk> anyone awake?
<Keybuk> who cares about ia64?
<lifeless> heh
<lifeless> academically, or pragmatically ?
<Keybuk> either :p
<lifeless> well, I care, not that I ever do anything about it ;)
<fabbione> Keybuk: what's the problem?
<Keybuk> fabbione: asm/errno.h is missing from l-k-h
<fabbione> Keybuk: that would be jbailey's fault..
<Keybuk> in fact, /usr/include/asm is missing entirely
<fabbione> Keybuk: i have not time to fix it right now. Neither i have my machine up at the moment
<fabbione> i have to finish the rh-c-s merge first
<zul> hi ho
<mjg59> BenC: Keybuk: Someone's complaining that since the dapper kernel update, the kernel can't find their root filesystem
<mjg59> Oh, scratch that, he's being confusing about timing
<msemtd> mjg59: I'm confused!
<mjg59> msemtd: Ah, you're in here too
<mjg59> Excellent
<msemtd> yup - looking for Keybuk!
<mjg59> Right
<mjg59> So was the machine running the released version of dapper previously?
<msemtd> yes - it's been dapper for a few weeks
<msemtd> I upgraded from breezy
<mjg59> msemtd: Ok. There have been no udev updates during that time period.
<mjg59> So it's certainly not a udev issue.
<msemtd> the upgrade went well
<msemtd> I was assuming my rpoblem was simillar to some of the others' who report a simillar hang
<zul> is it sata?
<msemtd> ...although I only have a single IDE HDD with / & swap
<mjg59> msemtd: The "hang" is what happens when you don't have a device node for your root file system
<mjg59> There are various reasons why that could happen
<mjg59> It could be udev fucking up, or it could be the kernel fucking up
<mjg59> In this case it sounds more like a kernel issue than a udev one
<msemtd> ...or both! :)
<msemtd> yeah - it followed a kernel upgrade
<msemtd> but now the older kernels won't find root either
<msemtd> I could keep trying different root=/dev/xxx from grub
<msemtd> mjg59: should I boot with break=top ?
<mjg59> msemtd: That would be a good start
<msemtd> what to I need to do to load the device driver module following that?
<mjg59> modprobe module_name
<msemtd> I suppose that's IDE
<mjg59> Depends on what sort of controller you have
<mjg59> There's probably a specific module
<mjg59> What sort of motherboard chipset?
<msemtd> it's onboard ide SiS
<mjg59> Ah, hang on
<mjg59> Do break=premount
<mjg59> Rather than break=top
<mjg59> Then the module should be loaded
<mjg59> Sorry, break=mount
<mjg59> Then go into /dev and see what hd* nodes there are
<msemtd> ok, break=mount - look in /dev - goddit
<msemtd> hmm, will I have a shell by then?
<msemtd> BusyBox?
<msemtd> ...from initrd?
<Keybuk> mjg59, msemtd: hmm?
<mjg59> msemtd: Yup
<msemtd> Keybuk: sorry - I thought my boot problem was udev
<msemtd> I have the root file system not found following linux-image-2.6.15-26-686 upgrade
<msemtd> ...hangs at "Waiting for root file system" then gives up on /dev/hda1 and gives me a BusyBox shell
<msemtd> tried acpi=off noapic irqpoll etc (my usual workarounds :) )
<msemtd> tried reinstalling older kernels but whilst chrooted from a knoppix 2.6 kernel so dunno if that'd screw things up
<msemtd> why would older kernels (that previously worked) fail to boot when reinstalled? I sit because grub is pointing to a different udev device?
<msemtd> s/I sit/Is it/
<mjg59> Grub's configuration won't have changed
<msemtd> the apt-get install will have run grub-update won't it?
<mjg59> Yes. That doesn't change the grub configuration.
<mjg59> Unless your config was already broken before you installed the kernel
<msemtd> I think the grub config is fine - each new kernel I apt-getted whilst under knoppix got added
<mjg59> But until you do the test, we're going to have no idea
<msemtd> true - I'll be trying tonight
<msemtd_> mjg59: ok, at home now - I did break=mount and there are no hd entries at all
<mjg59> msemtd_: can you cat /proc/modules and look for anything with sis in?
<msemtd_> ok one mo...
<msemtd_> no, nothing with sis in it
<BenC> anything with ata in it?
<msemtd_> um, no - we have commoncap and capability, softcursor, etc.
<msemtd_> is there something I could modprobe? 
<msemtd_> ide_generic?
<mjg59> You could try that
<msemtd_> wahay! I now have /dev/hdaxxx
<mjg59> Right
<mjg59> Can you do
<mjg59> grep 0x0101 /sys/bus/pci/devices/*/config
<mjg59> Sorry
<mjg59> grep 0x0101 /sys/bus/pci/devices/*/class
<mjg59> And then go to the directory with a match and do
<mjg59> cat vendor
<mjg59> cat device
<msemtd_> sorry, mjg59 I'll have to get back to this one - got to sort the kids out
<mjg59> Ok
<Keybuk> BenC: we're not going with .18, right?
<msemtd_> vendor is 0x1039 device is 0x5513
<BenC> Keybuk: no
<mjg59> msemtd_: Hm. Odd. sis5513 should bind to that
<mjg59> msemtd_: Can you do rmmod ide_generic; modprobe sis5513
<Keybuk> BenC: GregKH has some more random sysfs changes happening, I assume those are for .18 or .19 and didn't go into .17
<BenC> nothing scary in .17 that I'm aware of
<Keybuk> aye, /sys/class in .17 is still just class_dev
<msemtd_> mjg59: hmm, says "neither ide port enabled"!
<mjg59> msemtd_: Right. Interesting.
<msemtd_> mjg59: ah it seems ide0 and ide1 are taken!
<mjg59> msemtd_: Is ide_generic unloaded?
<msemtd_> sorry - i'll get back to this later
<mjg59> Ok
<Keybuk> BenC: any particular reason for the conservative kernel choice?  bad experience with dapper?
<mjg59> Keybuk: We have no especially good idea when 2.6.18 will be released
<BenC> Keybuk: not only that, but I didn't want to be chasing upstream kernel bugs+fixes for most of the release cycle
<BenC> when we did dapper, .15 was opened right before dapper started, and I knew we'd have 3 months of settling after .15 was released
<BenC> .18 was opened shortly after edgy started, and we'd probably only have 6 weeks max after .18 was released before edgy released
<Keybuk> seems fair
<jbailey> BenC: And that's assuming that any work gets done in August on 2.6.18, which I think unlikely.
<jbailey> Summers are great for development when it's mostly students.  Crap when it folks with spouses, kids, and vacation time who hack for a living.
<BenC> jbailey: Sorry, I missed most of what you said...was outside in the swimming pool with my kids, and then played some volleyball  ;)
<Keybuk> BenC: we're so not fooling for your "I have a life outside of work" pretence
<zul> heh
<jbailey> BenC: *lol*
<BenC> hehe
<BenC> no sign of Mith, but I'm sure he will allow an exception for a new kernel, given that the current kernel wont boot after install
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-5.7 uploaded, let's hope the new kernel-package is ok | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<mdz> BenC: did you re-enable that workaround for my VIA sound IRQ problem?  I can't use 2.6.17 until that's back
<BenC> mdz: crap, I forgot to include it before upload...I'll get it in and have a pre-knot-1 kernel for you
<BenC> 309M    .xchat2/xchatlogs/
<BenC> think maybe I need to prune that
<zul> a bit
<BenC> sweet
<BenC> fabbione: New pbbuttonsd handles keyboard backlighting on my pb now!
<fabbione> BenC: yes i saw it!
<BenC> it's using a different hueristic than macosx does though
<BenC> on osx, if you were in complete darkness, the keyboard lights were actually a bit dimmer than if you were in partial light
<BenC> it got brighter, then dimmer as the light decreased
<fabbione> BenC: yes, there is a sensor on the keyboard that enable/disable backlight automatically in MacOS
<fabbione> yeah
<fabbione> MacOS was either on/off or manual
<fabbione> the new psbuttunds is more smooth
<BenC> macosx was smoother for me
<fabbione> hmmm
<BenC> it was automatic
<fabbione> i will check again...
<fabbione> it's rare i work in the dark anyway
<BenC> same here, but it's nice when the light is as the threshold where the black-on-grey keys are hard to read
<fabbione> ehhe yeah
<fabbione> i am off to watch a movie.. later :)
<BenC> jbailey: ping
<BenC> later
<BenC> jbailey: dpkg-deb: building package `linux-kernel-headers' in `../linux-kernel-headers_2.6.17-5.7_powerpc.deb'.
#ubuntu-kernel 2006-07-14
<BenC> lamont: ping
<zul> hey
<lamont> BenC: running out for about 4 hours
<BenC> lamont: any idea what's up with ia64's toolchain?
<BenC> userspace stuff is failing to compile because it can't find stuff in /usr/include/ia64-linux-gnu/asm/
<zul> can you  overide kimagedest with kernel-package or the package name?
<BenC> should be able to...check the manpage
<zul> hi mdz
<mdz> zul: hi
<lamont> BenC: dunno - I'll look into it tomorrow or this weekend
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-5.9 uploaded, Jinxed, kernel-package borked everything, fixed it all up, and now we also have linux-kernel-headers | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<jbailey> BenC: Oooo, cool.
<jbailey> BenC: Lemme know when eyou're around, I'd love to talk a bit more about lkh
<fabbione> jbailey: hey dude.. Kamion is looking for you about the mesa stuff...
<zul> hi
<jbailey> Heya Chuck
<zul> Hey Jeff
<_kylem> jeffx0r.
<jbailey> kyled00d
<_kylem> that's all i've got.
<_kylem> ;-)
<zul> jeffarino
<zul> BenC: i have a couple of questions for you when i get back later
<_kylem> BenC, ok. i reproduced your bug.
<_kylem> BenC, something like this:
<_kylem> Loading ramdisk 4516272 bytes @ 3fba0000...
<_kylem> Branching to kernel entry point 0x00100000.  If this is the last
<_kylem> message you see, you may need to switch your console.  This is
<_kylem> a common symptom -- search the FAQ and mailing list at parisc-linux.org
<_kylem> ************* SYSTEM ALERT **************
<_kylem> BenC, i'm going to rebuild your tree with my .config and see if it's a configuration problem, or some patch you merged.
<_kylem> BenC, my config boots fine.
<_kylem> mostly... for some reason it didn't mount /
<jbailey> _kylem: This is with an Ubuntu initramfs?
<_kylem> no.
<_kylem> i don't build modular kernels.
<jbailey> modules are cuddly. =)
<_kylem> jbailey, hmm. it didn't detect any of the disks at all.
<_kylem> but sym2 got probed.
<_kylem> curious.
<jbailey> iirc, sym2 is heavily patched in the parisc-linux tree.
<_kylem> hmm. true.
<_kylem> so while i make oldconfig'd i noticed there was this 'speakup console' thing...
<_kylem> i think if you guys have patches that muck with console support it might cause this.
<jbailey> Yeah.  Now as it's booting you can have your machine talk to you:
<jbailey> "On my way up!"
<jbailey> "On my way up!"
<_kylem> or rather, cause what benc.
<jbailey> "Uh oh"
<_kylem> ...
<jbailey> "This isn't good"
<jbailey> "FOR THELOVE OF GOD!"
<jbailey> "You didn't need that data did you?"
<jbailey> "Checking your filesystem."
<jbailey> "Does CTD mean anything to you?"
<_kylem> jbailey, fwiw, there's no sym2 patches outstanding to 2.6.18-rc1 that should effect this.
<_kylem> jbailey, i don't know where 2.6.17 stands on this.
<jbailey> "I can see this conversation can serve no further purpose.  Goodbye."
<doko> BenC: please join #ubuntu-toolchain when breaking lkh. kthxbye :p
<BenC> kylem: So you think the speakup stuff broke hppa?
<BenC> I can certainly attempt to confirm that
<_kylem> BenC, it's possible. i can probably build faster so i'll test it until i find it.
<_kylem> i need to go look through the diff and look for any clues.
<mdz> Recommended packages:
<mdz>   BOOTLOADER
<mdz> BenC: is that intentionally in all caps?
<mdz> BenC: also, is 2.6.17-5.9 safe to install on the architectures where it did build successfully?
<BenC> the kernel is safe, it's just linux-kernel-headers that is broken
<BenC> and I've no idea about the BOOTLOADER thing
<BenC> interesting...I forgot to fill in the bootloader stuff
<BenC> lol
<BenC> my screen brightness affects my keyboard backlighting
<BenC> so if I switch to my evo desktop, the keys go black, but if I switch to my terminals (blackback ground), the keyboard lights up
<cjb> Nice.
<BenC> _kylem: I almost have a build done with speakup disable, so I can test it soon
<BenC> mdz: let me know if 5.9 or later fixes your via problem
<mdz> BenC: your keyboard lights up?
<mdz> I'll boot -5.9 now and see
<[g2-build] > BenC, I've pulled the git tree. There used to be a newbiehow for building the kernel has that gone away ?
<BenC> g2: see links in topic
<BenC> mdz: Yeah, the pb has a backlight for the keyboard and sensors so it can automatically adjust to ambient light in the room
<BenC> it even dims the lcd backlight the darker it is in the room (since it doesn't need so much contrast)
<[g2-build] > BenC, I've got the ubuntu GIT tree from the link above, and the CategoryKernel doesn't seem to have the howto that was there a month ago or so
<[g2-build] > clearly I'm missing something
<BenC> oh wow
<BenC> some ripped out my KernelCustomBuild, and moved it to help.ubuntu.com
<BenC> so now it doesn't show under the wiki
<BenC> https://help.ubuntu.com/community/Kernel/Compile
<[g2-build] > BenC, thx :)
<BenC> I'm not sure why this page was moved to help.ubuntu.com and also removed from wiki.ubuntu.com
<BenC> that makes no sense
<BenC> re-added to wiki, so it's there if yu need it
<BenC> _kylem: rebuilt with speakup disabled, and still no luck
<BenC> checked the code, and with it disabled, the console code is basically stock
<zul> crap its nearly 4 already?
<crimsun> BenC: that wiki.uc->help.uc migration was part of the docteam stuff
<BenC> crimsun: But the doc I had linked to other docs that were not migrated
<BenC> so it was kind of broken
<crimsun> lovely :/
<[g2-build] > bbiab
<[g2-build] > BenC, ok I've got my first Ubuntu kernel built :) it's stock 386 from the git tree
<[g2-build] > do I need to build the module-init-tools from source to work around the dependency issue ?
<[g2-build] >  linux-image-2.6.17-5-38fa6a-386 depends on module-init-tools (>= 3.2.2-3ubuntu2); however:
<[g2-build] >   Version of module-init-tools on system is 3.2.2-1ubuntu7.
<BenC> yeah, unless you want to upgrade libc6 with it (I assume you are running dapper)
<[g2-build] > yeah dapper latest
<BenC> you could just copy the blacklist-pata to /etc/modprobe.d/ and do "dpkg --force-depends -i linux-image..."
<BenC> but proper would be to rebuild module-init-tools
<[g2-build] > proper is good
<[g2-build] > I'm not in a super hurry, I'd like to get thing "right"
<[g2-build] > where do I need to point for the later version of the source ?
<[g2-build] > getting source gets the current version :)
<BenC> add "deb-src http://archive.ubuntu.com/ubuntu edgy main" to /etc/apt/sources.list
<BenC> sudo apt-get update
<BenC> apt-get source module-init-tools
<[g2-build] > now that you mention it it just makes too much sense :)
<[g2-build] > thx
<_kylem> BenC, i'll try it on another box and see if i can be more persuasive.
<BenC> _kylem: I got a successful boot with 2.6.17.3 stock + a500_debconfig
<BenC> trying ubuntu source + a500_defconfig 
<_kylem> ok.
<[g2-build] > rebooting
<BenC> _kylem: ubuntu code + a500_defconfig gets me to a "couldn't mount root" panic, I think because scsi_mod wasn't compiled in
<BenC> let me check the config
<_kylem> ok.
<_kylem> that's the same thing i got with my a500 config + ubuntu kernel
<BenC> CONFIG_BLK_DEV_SD=y
<BenC> hmm, it should have gotten the rootfs
<BenC> I know the sym2 driver loaded
<_kylem> yeah. it didn't see the disks at all though.
<_kylem> do you have any changes to sym2 that upstream doesn't have?
<BenC> just the stuff from pa6
<_kylem> ok.
<_kylem> i'm confused now then.
<[g2-build] > uname -a
<[g2-build] > Linux tom-server 2.6.17-5-38fa6a-386 #1 Fri Jul 14 15:28:47 EDT 2006 i686 GNU/Linux
<[g2-build] > wheee ! my first ubuntu kernel
<[g2-build] > BenC, any ETA on building the restricted modules ?  I'm running with vesa instead of nv 
<[g2-build] > no pressure, just curios
<[g2-build] > thx for all the help btw -- you guys (Ubuntu) have the process in nice shape
<BenC> g2: lrm for what?
<BenC> dapper should have lrm built for it
<mjg59> BenC: 2.6.17 isn't in dapper
<[g2-build] > hey mjg59 
<BenC> g2: you'll have to rebuild lrm yourself
<[g2-build] > mjg59, are there any restricted modules required for the mac mini ? I'd guess the atheros
<BenC> apt-get source linux-restricted-modules-2.6.17
<BenC> edit debian/rules and find the ABI, set it to 5-38fa6a
<mjg59> [g2-build] : Correct
<BenC> you'll have to add restricted to the deb-src line first
<[g2-build] > BenC ok I'd like to walk through this and then I can have a draft update for the wiki
<[g2-build] > I'll building the nv modules for the desktop first for this kernel is a good thing
<[g2-build] > well good as in a good test
<[g2-build] > BenC do you mean linux-restricted-modules-386 ?
<BenC> that's how you build it, yes
<BenC> but the package you just mentioned is just a meta-package
<[g2-build] > right but in edgy main there's no linux-restricted-modules-2.6.17
<[g2-build] > src that is
<[g2-build] > and dapper is very unaware of that
<mjg59> It ought to be in restricted
* [g2-build]  starts to get a clue
<[g2-build] > so i need to add deb-src http://archive.ubuntu.com/ubuntu edgy main restricted 
<[g2-build] > to sources.list
<[g2-build] > Does this mean they were just uploaded yesterday ? https://launchpad.net/distros/ubuntu/edgy/+source/linux-restricted-modules-2.6.17
<[g2-build] > and is "+source" a different place ?
<BenC> the source doesn't change when I upload for a new kernel
<BenC> it's just a change in the ABI
<BenC> not to mention even if I upload, you can use it, since your kernel ABI is different
<BenC> you have to build it anyway
<BenC> you can't use it, I mean
#ubuntu-kernel 2006-07-15
<BenC> _kylem: Yeah, only patch to sym53c8xx_2/ is the pa6 patch (just checked it)
<_kylem> ok.
<_kylem> i'll spend some time trying to find the cause on my workstation
<_kylem> since it has a front panel lcd to tell me what the erorr is
<BenC> I'll try to find out why console isn't working on the ubuntu configs
<_kylem> i read through the config you told me to generate but couldn't find anythign that looked suspicious
<BenC> obviously it's the config, since a500_defconfig has working console
<_kylem> hmm true.
<BenC> I don't know enough about the parisc console settings to make since of it though
<BenC> s/since/sense/
<_kylem> ok
<BenC> _kylem: FYI, I was having this problem before applying the pa6 patch
<_kylem> there's nothign of consequence in the parisc patchset in the last litle while, iirc
<BenC> allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
<BenC> SCSI subsystem initialized
<BenC> _kylem: hmm...maybe found something there
<_kylem> the vmalloc thing shouldn't be a problem.
<_kylem> that's just because a500 have really really big DAC regions
<_kylem> (dual address cycle, >4G)
<_kylem> hum.
<_kylem> is SYM53c8XX using MMIO?
<BenC> Linux hippo 2.6.17.3-ubuntu1 #3 SMP Fri Jul 14 23:16:58 UTC 2006 parisc64 GNU/Linux
<BenC> interesting...sym2 and sd as modules works
<_kylem> er. how'd you manage that? :)
<BenC> I think the problem is that sym2 2.2.3 doesn't block during the scsi bus reset
<_kylem> ok. i'll look through the patch set. i'm beginning to think it's async scanning.
<BenC> and it's not ready when the kernel tries to mount the rootfs
<BenC> is that async related?
<_kylem> yeah.
<_kylem> if async scanning is enabled, you'll see soemthing like this
<BenC> makes sense
<_kylem> IPv6 over IPv4 tunneling driver
<_kylem> NET: Registered protocol family 17
<_kylem> scsi: waiting for bus probes to complete ...
<_kylem>   Vendor: HP 18.2G  Model: MAN3184MC         Rev: HP04
<_kylem>   Type:   Direct-Access                      ANSI SCSI revision: 02
<_kylem> [..] 
<_kylem> actually. that looks /exactly/ like what's happening.
<BenC> doesn't explain the brokeness using the ubuntu config, but atleast I know things should work now
<_kylem> sym0: <896> rev 0x7 at pci 0000:00:01.0 irq 19
<_kylem> sym0: PA-RISC Firmware, ID 7, Fast-40, LVD, parity checking
<_kylem> sym0: SCSI BUS has been reset.
<_kylem> scsi0 : sym-2.2.3
<_kylem> sym1: <896> rev 0x7 at pci 0000:00:01.1 irq 20
<_kylem> sym1: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking
<_kylem> sym1: SCSI BUS has been reset.
<_kylem> sym1: SCSI BUS mode change from SE to SE.
<_kylem> sym1: SCSI BUS has been reset.
<_kylem> scsi1 : sym-2.2.3
<_kylem> ^-- from a /working/ boot.
<_kylem> that's a big hint that something is wrong in drivers/scsi.
<BenC> the async problem isn't a big deal for us because our initramfs scripts will wait
<BenC> I really need to figure out what's up with the config now
<_kylem> righto.
<_kylem> gimme a while to grab some food and i'll take a look with you
<mdz> BenC: do I understand correctly that linux-source started building linux-kernel-headers just recently?
<mdz> BenC: I think the l-k-h produced thereby may be somewhat sub-optimal
<mdz> http://librarian.launchpad.net/3419820/buildlog_ubuntu-edgy-i386.totem_1.5.4-0ubuntu1_FAILEDTOBUILD.txt.gz
<mdz> BenC: filed bug #53028
<_kylem> back.
<BenC> mdz: Yeah, that's the issue that I'm trying to get infinity to help me with
<BenC> linux-source needs lkh to build, so I need some sort of overrider to use the old lkh so I can produce new ones
<mdz> BenC: how about re-uploading the old l-k-h source package with a  higher version number, then overriding it?
<mdz> it's saturday for infinity
<BenC> hmm, I could try that
<BenC> it doesn't use anything in the toolchain to build the package
<BenC> mdz: done
<mdz> BenC: cool, thanks
<mdz> BenC: by the way, the VIA workaround seems to have taken
<mdz> I closed the bug accordingly
<BenC> good deal, thanks
<BenC> I need to get this kernel squared away before the weekend is over so I don't hold up Mith any longer than I already have
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-5.12 uploaded, fixes linux-kernel-headers debacle | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<crimsun> guh, 34831 strikes again?
<BenC> yeah, I saw that
<crimsun> man, this one's ugly. Gonna have to look at it in Edgy with the dump mechanism
<BenC> next upload In do in edgy will have the kexec/kdump stuff...I hope
<crimsun> I'm not entirely convinced it's not a hardware issue
#ubuntu-kernel 2006-07-16
<infinity> BenC: headers are still broken in the latest kernel build, LRM is FTBFS looking for stuff in asm/
<crimsun> feeling better, infinity?
<infinity> Not so much, but I'm working anyway.
<infinity> I think it's called "corporate guilt".
<crimsun> :/  feel better soon, then.
<fabbione> pool/main/l/linux-source-2.6.17/linux-image-debug-2.6.17-5-386_2.6.17-5.12_i386.deb
<fabbione> ????
* fabbione looks towards BenC 
<pperez> Hello everyone
<pperez> I am trying to understand, who creates/generates the /boot/abi-* files
<pperez> I would like to learn how to create them when I compile my own kernel using kernel.org sources.
<pperez> I have seen these files in ubuntu/kubuntu images, and I have yet to learn how to create them.
<pperez> I have visited debian,ubuntu, and kubuntu websites, but my search have not been very productive.
<pperez> Any help would be greatly appreciate it.
<pperez> Thanks in advance.
<crimsun> look at the debian/rules file
<pperez> ok, I will check that out. Thanks crimsun 
<fabbione> oh fucktastic
<fabbione> new l-k-h is hutterly broken
<fabbione> BenC: i need you to fix l-k-h by yesterday... it's missing a bunch of includes even on i386
<fabbione> it's missing stuff like dlm* that was there previously
<fabbione> that's required to build libdlm and lvm stuff
* Starting logfile irclogs/ubuntu-kernel.log
* Starting logfile irclogs/ubuntu-kernel.log
* #ubuntu-kernel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* Starting logfile irclogs/ubuntu-kernel.log
<BenC> fabbione: Fixed, but I have to get abi files, and then I'll upload
<fabbione> BenC: ok i did workaround it for now. Let's do it properly once we get the ABU
<fabbione> ABI
<fabbione> there are also some gfs2_ headers that we need to export to userland
<BenC> dlm in lkh, or in linux-headers?
<BenC> hmm, don't remember those being in lkh package from before
<BenC> it only had linux and asm*
<fabbione> BenC: they were added by jbailey the upload before you took over the package :)
<fabbione> BenC: the redhat-cluster-suite needs these headers. They were "upstream" before linux-k-h being integrated into the kernel
<fabbione> so either i start depending on l-h-$version-$abi
<fabbione> or we export the headers properly via l-k-h 
<fabbione> the latter ++
<fabbione> BenC: do you know if ia64 is usable in edgy=
<fabbione> ?
<BenC> it is for me
<infinity> BenC: Did you fix whatever's causing LRM to FTBFS?
<infinity> BenC: (missing asm/ stuff in l-h-kver, I assume)
<BenC> yeah, was a bad asm symlink in l-h-*
<infinity> Kay, cool.
<BenC> fabbione: where are these dlm headers?
<BenC> in the kernel tree that is
<infinity> I know it's Sunday, but any chance of getting that uploaded soon, so I can shove back LRM in the morning when I start work?
<BenC> infinity: as soon as I get a build for ia64 so I can grab ABI files, it will be uploaded
<fabbione> BenC: somewhere in include/linux
<infinity> BenC: Err, a build of the new source, or the previous?
<infinity> BenC: The previous built on ia64...
<fabbione> just do a find . -name "*dlm*"
<fabbione> BenC: there are 2/3 files iirc
<BenC> dlm.h and dlm_device.h?
<fabbione> there is one more..
<fabbione> holdon
<fabbione> lock_dlm_plock.h
<fabbione> i am pretty sure about these 3
<fabbione> i dunno if they pull in more stuff
<BenC> should they be sanitized (e.g. unifdef'd for __KERNEL__)?
<fabbione> dunno
<fabbione> i don't think so
<fabbione> gfs2_ondisk.h is another good one to have
* infinity goes to bed.
<fabbione> infinity: good night
<BenC> good night infinity
<infinity> BenC: If I see a new linux-source when I wake up, I'll be so happy I'll vomit.
<BenC> almost makes me want to upload 3 or 4 new kernels :)
<fabbione> vomit++
<BenC> fabbione: I added all 4, and unifdef'd them, and it passes headers_check
<fabbione> BenC: ok.. i don't know what unifdef does, but included as they are from userland works
<fabbione> so i assume if they come out the same or very close, it should just work
<fabbione> let see .17 on ia64
<fabbione> today i cleaned up the rack
<fabbione> removed an old 15" monitor for a 1U monitor/kvm set
<fabbione> so i had all the space to add the second SAN switch and readd some stuff like ia64
<fabbione> Setting up linux-image-2.6.17-5-itanium-smp (2.6.17-5.12) ...
<fabbione> meh
<fabbione> doesn't boot
<BenC> weird, it's booting for me on my i2k
<fabbione> it stalls after loading initrd
<fabbione> but i had to fix a couple of errors in /usr/sbin/elilo
<fabbione> so i might have actually fucked up something else
<BenC> does that to me too, but I thought it was because my machine was hot
<BenC> might have to cold boot it
<jb_> ndiswrapper of interest here? If so, ndiswrapper-1.21 (from source) works for me.
<crimsun> works for what hardware? man, those statements are befuddling.
<BenC> yeah, it's like "did ndiswrapper in the kernel not work?"
#ubuntu-kernel 2007-07-09
<shriram> Hi guys, I have a pointer to a struct page in the physical memory. I'm trying to read a string whose offset in the page is known. How do I do this? 
<kraut> moin
<calc> BenC: is there anything special i need to do when patching something in the kernel to keep from needing to run clean and have it pick up the change?
<calc> BenC: when i last worked on the realtek stuff last week i think i was having to run clean to have the build system pick up the change i made the patch_realtek.c
<holst> less and less people in the channels that Im joining
<holst> that must mean that im closing in
<holst> I am trying to make a m-a package out of perfctr kernel module
<Nafallo> hehe
<holst> however, the src needs to patch the kernel directory
<holst> how can I accomplish this with m-a?
<holst> or rather- any good howto about this?
<holst> hello? =D
<zul> holst: you can try making a patch against the current git tree and submitting the patch to the kernel-team mailing list
<holst> why current git tree?
<holst> I dont get that part
<zul> because its not likely that we would be accepting new drivers for feisty
<zul> anyways check the wiki 
<holst> aha, you mean that it could be a kernel module?
<zul> 14:23  * ScottK activates his "Somebody else's problem" field and gets back to coding.
<holst> thats a bit more than I was thinking
<zul> doh https://wiki.ubuntu.com/KernelTeam
<holst> I was thinking a less agressive assult on the problem using m-a
<Nafallo> module-assistant
<holst> yes
<holst> So now I have a patch that works without problem against linux-source-2.6.20. Can I work with that? is #ubuntu-kernel the wrong forum for this sort of questions?
<johanbr> module-assistant usually builds modules out-of-tree, so it depends on whether your kernel module supports that. If it doesn't, things get uglier.
<holst> thats what I mean
<holst> is there a framework inside m-a to build this type of modules?
<johanbr> What do you mean by "this type"? Out-of-tree modules? If so, the answer is yes.
<holst> hmm, I have been talking about, "the src needs to patch the kernel directory"
<holst> so out-of-tree modules doesnt seem to fit the description
<holst> if tree is the kernel directory
<johanbr> So the module needs to depend on some specific version of the kernel source package. Which defeats the whole purpose of packaging the source.
<Dante123> hi all....looking at installing ubuntu on a Celeron 800 mhz (basically Pentium iii) is this feasible
<bje> Dante123: yes, ofcourse
#ubuntu-kernel 2007-07-10
<TheMuso> c
<TheMuso> ugh
<kraut> moin
<_StefanS_> hi there
<_StefanS_> BenC: ping?
<_StefanS_> BenC: would you consider adding the port multiplier patches to the current 2.6.22 kernel? They greatly improve the experience with controllers that take advantage of multiple sata devices on one cable. I've been testing the patch(es) for Tejun Heo.
<BenC> _StefanS_: not likely
<_StefanS_> BenC: I know he's submitted them to inclusion in 2.6.23
<_StefanS_> BenC: but it would be rather cool to have that support, given that many installation might be using cheap sata arrays
<BenC> _StefanS_: then we'll get it for gutsy+1
<_StefanS_> BenC: yes I know..
<_StefanS_> BenC: but would be great to have it now :D
<BenC> _StefanS_: But we have to take the chance that it may break things considering it hasn't gotten upstream testing :)
<_StefanS_> BenC: well, yes..
<_StefanS_> BenC: I find it very stable, but ofcourse the stuff requires some wider testing i imagine... atleast I tried :D
<BenC> _StefanS_: np, I love to hear about stuff like this, and if it was the case of adding a "we have to have this" type feature, then maybe, but otherwise we tend to stick with stable code
<_StefanS_> BenC: for me I see it as a competitive advantage, since more and more people are moving away from usb devices, and on to eSata. The current libata in stock 2.6.22 isn't really working with that.
<_StefanS_> BenC: (for multiple devices I mean)
<BenC> isn't working, or just isn't performing well?
<_StefanS_> BenC: port multiplier is there, but doesn't recognize more than one disk on the cable. I guess the performance is about the same with or without the patches
<_StefanS_> BenC: I imagine it was a cool feature just out of the box on ubuntu server for instance
<BenC> _StefanS_: hmm, slightly different than I understood...can you send the patch to kernel-team@lists.ubuntu.com for review?
<_StefanS_> BenC: sure
<_StefanS_> BenC: there you go.
<BenC> _StefanS_: thanks
<_StefanS_> BenC: my email is waiting approval before entering the list, just so you know it
<BenC> _StefanS_: ah, ok
<_StefanS_> BenC: yea, I wasn't subscribing to it ;)
<BenC> it's very low volume, if you're interested :)
<_StefanS_> BenC: well yes, I could probably push for stuff earlier in the process hehe
<_StefanS_> BenC: there's a little thing with ipr.c and ipr.h when compiling with the patch applied, but tejun is going to fix that very soon. He's planning to release a patchset for the final 2.6.22 kernel soon
<RAOF_> Is it possible for someone not on the kernel team (ie: me) to help with bug 120943
<jbailey> Heya!  I notice that -8.15 has been uploaded without the hppa ftbfs fix that I sent to malone over a week ago.
<jbailey> Is there something more I should do to make sure that ports patches go in?
<jbailey> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/123178
<zul> jbailey: i guess it was overlooked might want to ping amitk 
<jbailey> Right, but I'm wondering if there's something I should do to keep it from getting overlooked.
<zul> send the patch directly to the kernel-team mailing list
<jbailey> The ports stuff is always going to be weird, since it's targets that the kernel team isn't expected to test.
<jbailey> You mean as well as posting the bug?  Won't that just mean more noise, and then in a place where it can't be tracked?
<zul> good point..
<lamont> I think I might have git-tree abilities these days, I should check on that once BenC is bored.
<jbailey> That would be nice.
<jbailey> Then I'll just bug you. =)
<amitk> jbailey: I had (still don't) no knowdlege of these changes. I will talk to kylem and try to put it into the next upload
<jbailey> amitk: kylem is not involved with the Ubuntu hppa port.
<amitk> jbailey: then who is?
<jbailey> LaMont and I.
<jbailey> kyle's doing upstream hppa kernel stuff, so he's still a reasonable person to ping for these, but IIRC he prefers to stay away from it in Ubuntu to avoid any work/non-work confusion around it.
<jbailey> amitk: But in general, if filing a bug isn't the best way to make sure the kernel team sees a patch, what is?
<amitk> jbailey: Besides filing a bug, it definitely helps sending email + patch to kernel-team ML. Someone is then bound to review and ack the patch
<jbailey> Okay.  Doesn't filing a bug automatically email everyone, though?
<jbailey> I would've thought that redundant.
<amitk> jbailey: I currently have 1046 emails from bugs.launchpad.net in my mailbox. A majority of these aren't triaged yet. We do try to go over bugs that have a patch attached, but sometimes we might miss one.
<amitk> jbailey: kernel-team ML is directed towards any patches that we are seriously proposing to incorporate into the next release
<jbailey> 'kay.  Is there a launchpad account I can just subscribe to it, or should I just sent the same email to the mailing list?
<jbailey> I'd prefer not to be subscribed to yet another mailing list that goes into an unread folder.
<lamont> ii  git-core       1.1.3-1ubuntu1 content addressable filesystem
<lamont> well.. that explains my pain.
<amitk> you need to subscribe to the ML AFAIK.
<jbailey> That seems a bit excessive.
<amitk> lamont: I share your pain
<lamont> jbailey: send the mail, I'll add you
<lamont> to the unsubed but allowed list
<jbailey> lamont: Thanks.
* lamont is list admin for kernel-team you see...
<jbailey> Ah, handy. =)
<TheMuso> c
<TheMuso> ugh
<lamont> mind you, replies may or may not go to you, depending on whether or not the responder includes you in the recipients....
<jbailey> I'll be sure to indicate in the message that comments should be posted in the bug or I won't see them.
<jbailey> lamont: kernel-team@lists.ubuntu.com ?
<lamont> sounds right
<amitk> jbailey: how about cc'ing the bug id. That way reply-all would collect all comments, right?
<jbailey> Ah, interesting thought.  I haven't tried that before.  I'll try it when I send this one.
* lamont addresses his pain by building git 1.5.2.3
<lamont> jbailey: 99% of the time, I actually catch the non-spam and forward it along.  when I recognize the sender, I add them to accepts.
<lamont> and then there's that other 1% of the time... :(
<jbailey> lamont: What, you're not using Gusty yet?
<jbailey> weak. =)
<lamont> dude.  hppa box
<lamont> overrides file is managed in git, on bld-3.
<lamont> amitk: so is the conversation here enough to get this patch in to 8.16? or should I send mail to the ML?
<amitk> lamont: I have added it to my list of pending patches. I will push it to 8.17.
<maswan> hey, this came up over in -mirrors, are there any (implemented) plans to get rid of the silly dmesg stuff like "TCP: Treason uncloaked!" and so?
<Nafallo> maswan: I think the IPv6 one was much more weird :-)
<maswan> the "IPv6: sending pkt_too_big to self" one?
<maswan> yeah, that's also on my list of annoying messages that makes interesting stuff harder to see
<Mithrandir> amitk: I presume you're aware your upload FTBFS?
<amitk> mithrandir: yes. I am uploading a fix
<Mithrandir> yay fixxxes
<lamont> amitk: awesome
<amitk> mithrandir: I forgot to update modules.ignore for 'blink'
<zul> lol "EE: Missing modules (start begging for mercy)"
<amitk> BenC: could you re-submit the kernel to the buildd?
<BenC> amitk: yes, getting it now
<BenC> amitk: uploaded
<amitk> anybody who is waiting... go get a beer or something :)
#ubuntu-kernel 2007-07-11
* ..[topic/#ubuntu-kernel:crimsun] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-8.16 | Latest news: -rt and -xen kernels removed, failures in patch | linux-meta uploaded for gutsy 2.6.22 kernels. | New Kernel Team machine: http://kernel.ubuntu.com/
<kraut> moin
<tepsipakki> hey, there's something wrong with reporting quotas on feisty.. exactly the same calls and mounts on dapper are fine, but on feisty it get's wrong paths
<tepsipakki> someone here pointed out that fscache was added in 2.6.18/19, and maybe that could have something to do with it?
<tepsipakki> I tried with the kernel from gutsy, still the same
<tepsipakki> now I'll go get .17
<tepsipakki> it works there
<tepsipakki> filed bug 125235
<imbrandon> BenC, arround ?
<BenC> imbrandon: sort of
<login_> Hi guys , i have a question for the developers, I am making an ubuntu deriative but i came into troubles when i compiled my own kernel . My pc needs to do acpi=off to boot but ounce i boot , no usb slots are detected . This happens on every other OS except ubuntu , I wanted to ask what patches are you added t othe kernel or what did you do to it to make it not have to do acpi=off or make it detect my usb 2.0
<login_> [11:34]  <login_> slots?
<login_> Hi guys , i have a question for the developers, I am making an ubuntu deriative but i came into troubles when i compiled my own kernel . My pc needs to do acpi=off to boot but ounce i boot , no usb slots are detected . This happens on every other OS except ubuntu , I wanted to ask what patches are you added t othe kernel or what did you do to it to make it not have to do acpi=off or make it detect my usb 2.0
<login_> slots
<JanC> login_: I'm sure you can find the location of the kernel patches on the kernel-related wiki pages...
<login_> thank you
#ubuntu-kernel 2007-07-12
<superm1> Hi guys, what format do you want patches in when submitting to the mailing list?  (what arguments to get-format-patch)
<TheMuso> c
<TheMuso> ugh
<superm1> TheMuso, trying to detect the pattern, at 20:23, i saw the same c, ugh in another channel now :)
<TheMuso> superm1: Its to do with a few things. My kvm, and a program I use to read the screen to me.
<superm1> ah
<pipo> hi! are there someone spanish that can help me ? :P
<pipo> my english is very bad >_<
<Nafallo> pipo: #ubuntu-es probably
<pipo> hi nafallo ;)
<pipo> i try explain my problem in english, but i think that you don't understand me 
<Nafallo> pipo: the problem is about current Ubuntu  developmment then?D[D[D[D[D[D[D
<Nafallo> ehrm. I hate my PC.
<pipo> is about the kernel of linux
<pipo> i need to apply a patch (perfctr) to use the program PAPI
<Nafallo> sure, but  is about the current development version of the distribution Ubuntus kernel?
<pipo> I apply the patch correctly and recompile the kernel, but when i reboot the system and select this kernel, it don't run ...
<pipo> i'm recompiling the 2.6.18 kernel version
<pipo> in next versions the patch can't be applied
<Nafallo> sorry then. this is not a channel for user questions really. you should use #ubuntu or #ubuntu-es :-)
<pipo> oh sorry :P
<Nafallo> no problem
<pipo> do you now some channel for this ??
<pipo> know >_<
<Nafallo> "#ubuntu or #ubuntu-es :-)"
<pipo> ok thanks ;)
<\sh> hmmm...looks like I found a bug in the work between large partition sizes and eit/gpt tables in latest feisty kernel
<byzzyb> hello everyone. I have a question. I tried fedora linux but it froze after boot right after loading initrd.img becouse of my ALi SATA/RAID M5289 Controller... at #ubuntu-installer they said I'll have to ask my questions here. So: Will and x64 Ubuntu work on my PC?
<byzzyb>  Will x64 Ubuntu work on my PC?
<byzzyb> *correction
<byzzyb> hm... any ideas?
<zul> yee haw im going home in an hour
#ubuntu-kernel 2007-07-13
<bronson> I have a Thinkpad T61 tablet with Intel WiFi Link 4965 AGN ...
<bronson> Anyone know if the Gutsy kernel should work with this?
<crimsun> yes, it should.
<bronson> That's what I thought...   I'm getting no love.
<bronson> scanning dmesg...
<Nafallo> baah. and I bought the earlier since I didn't thought it would :-P
<Nafallo> I should have asked.
<Nafallo> but then again... DRAFT-N ;-)
<bronson> Right...  I was hoping to get lucky since the Intel guys had already released working code.
<bronson> Guess I'm not THAT lucky....
<bronson> Overall, I'm pretty impressed with how well Gutsy works on this 2 week old laptop.
<bronson> Just the pesky wireless...  and the backlight.
<crimsun> oh, sorry, misparsed that~
<crimsun> actually I have no idea how I misparsed that as 3945, but whatever.
<bronson> Yeah, quite different.
<bronson> Intel apparently released a working driver though.
<mjg59> iwlwifi /should/ drive 4965
<mjg59> With luck I'll have test hardware in a couple of weeks
<bronson> OK, I scoured dmesg.  It doesn't look like the kernel tries to even probe the card.
<mjg59> bronson: It's quite possible we don't have a recent enough iwlwifi available
<mjg59> (If we have it at all yet)
<bronson> Module iwlwifi not found?
<mjg59> Do you have linux-ubuntu-modules installed?
<bronson> Couldn't find package linux-ubuntu-modules
<mjg59> linux-ubuntu-modules-2.6.22-7-generic
<bronson> sorry, I see.
<bronson> right.  :)
<mjg59> We seem to be lacking a metapackage :)
<bronson> Yes, I do.
<bronson> mjg59: pretty late where you are?
<mjg59> bronson: 1AM
<bronson> oh, not that bad.
<mjg59> Supposed to be in an office at 9:30, though
<mjg59> So should really sleep soon :)
<bronson> doh.  That's suboptimal.
<bronson> At Canonical?
<bronson> hm, why don't the arrows and tab key work in Gutsy's root shell?  (just idly wondering)
<mjg59> bronson: How have you got to the root shell?
<mjg59> Yeah, I'm visiting the London office this week
<bronson> sudo sh
<bronson> Ah, plain old su works.
<crimsun> apparently the microcode for 4965AGN isn't in the l-u-m tree yet.
<mjg59> Yeah, sh is dash
<bronson> Surprised there's a difference. 
<bronson> Oooooh.  Yeah, that makes sense.
<mjg59> su runs root's shell, which isbash
<mjg59> (sorry, dodgy space bar)
<bronson> I'll have to get in the habit of 'sudo bash'
<mjg59> sudo -s is the best bet
<mjg59> Or alternatively, sudo su
<bronson> erm, what's the l-u-m tree?
<mjg59> It's linked off kernel.ubuntu.com/git
<bronson> Think it's worth my time to try to add Intel's code and send a patch?
<bronson> Or are they going to get to it next week...?
<bronson> (or soon)  do you suppose?
<mjg59> Should be merged at some point soon
<mjg59> Like I said, I should have test hardware soon :)
<bronson> OK, I'll be patient.
<bronson> What test hardware?
<mjg59> HP 2510p
* ..[topic/#ubuntu-kernel:crimsun] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-8.18 | Latest news: -rt and -xen kernels removed, failures in patch | linux-meta uploaded for gutsy 2.6.22 kernels. | New Kernel Team machine: http://kernel.ubuntu.com/
<bronson> 2.8 lib wxga?  groovy.
<bronson> mjg59: thanks for your help.  Hope you get the device soon.  :)
<mjg59> crimsun: Looks like we need an alsa update for new Thinkpads :(
<crimsun> ok, right.
<crimsun> I'll look tonight when I get home.
<mjg59> Thanks!
<mjg59> How much longer do we have you for?
<zul_> crimsun: leaving?
<JanC> <mjg59> sudo -s is the best bet
<JanC> sudo -i  :)
<kraut> moin
<abogani> lamont: May i disturb you?
<abogani> BenC_: ping
<BenC_> abogani: yes?
<abogani> BenC: No way to send a msg to kernel-team list. It is over-sized. May i send you this directly?
<BenC> abogani: can you put it somewhere to download from and send the email with the URL to kernel-team?
<abogani> BenC: Sure! I'm stupid... :-)
<xivulon> mjg59: re wubi hibernation issues, I was reading http://kerneltrap.org/node/11756 , am I right that if that is implemented it may fix the issue in coming releases?
<BenC> abogani: nah, you're good :)
<mjg59> xivulon: In the long run, yeah
<xivulon> cool
<xivulon> mjg59: is it realistic to have suspend-to-ram working with fuse root fs in gutsy?
<mjg59> xivulon: I'll look into it
<mjg59> It /might/ be
<xivulon> mjg59: thx a lot, since we loose suspend-to-disk while we wait for kexec, it would be nice to keep suspend-to-ram at least
<mkrufky> again... i dont want to be a pest....  but this bug that i files months ago is causing a tech support nightmare for v4l
<mkrufky> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/99107
<mkrufky> s/files/fileD
<mkrufky> is there a different place i should go to get some attention on this?
<mkrufky> i am aware that ubuntu folks spoke to hauppauge to get these licensed firmwares.... but ubuntu is using the OLD firmware, and it causes problems with the current drivers, which use the *official* firmware
<mkrufky> hauppauge did not license the old fw that ubuntu is shipping
<apt_get> Hi people
<lamont> amitk: out of curiosity, eta for -8.17?
<amitk> lamont: next week
<mikmorg> hello.
<tsmithe> i just tested http://people.ubuntu.com/~bcollins/kernels/linux-image-2.6.22-8-rt_2.6.22-8.18_i386.deb, and it works quite well (apart from the lack of lum). however, i did have an issue with my i915
<tsmithe> lots of unknown symbols for drm: "[  118.858742]  i915: Unknown symbol drm_release" and suchlike in dmesg
<lamont> amitk: next week == monday, or friday?
<mikmorg> hello all
<mikmorg> Does anyone know when the 20-16.30 kernel is coming out?
#ubuntu-kernel 2007-07-14
<Nafallo> http://www.linuxpowertop.org/results.php
<Nafallo> if you guys haven't seen this :-)
<Amaranth> Nafallo: too bad the bit about gnome-power-manager is full of crap :/
<Nafallo> indeed.
<Nafallo> I hope they push patches ;-)
<mikmor1> can anyone tell me where the linux-image debian {post,pre}{inst,rm} scripts are located / generated? I downloaded the ubuntu-feisty.git repo, and can't find them.
<kraut> moin
<zorglu_>  q. i want to do oprofile/sysprofile on the kernel on ubuntu feisty, can i do that without recompiling the kernel ? like by using existing packages ? if so wich one ?
#ubuntu-kernel 2007-07-15
<lamont> Jul 14 20:42:10 mix kernel: [ 3106.816000]  APIC error on CPU0: 40(40)
<lamont> how do I get rid of those, I wonder...
<bronson> boot with no-apic?  :)
<bronson> er, noapic.
<kraut> moin
#ubuntu-kernel 2008-07-07
<Grackle> Hi, I have a new driver for a realtek device, and I'd like to add it to the ubuntu repositories.
<Grackle> It's an RTL8187SE. The driver was released (well, procured) yesterday. It's GPL'd. I made some modifications to compile it for the ubuntu hardy kernel
<Grackle> It now works... so... yeah.
<Grackle> I've never done any work in a linux distribution development process, much less ubuntu's
 * Grackle is looking for some help and guidance
<TheMuso> Grackle: I think it also wouldn't hurt sending an email to the kernel team mailing list, kernel-team@lists.ubuntu.com so your message is seen.
<stgraber> Looks like my custom dsdt isn't loaded on Intrepid, is it a known issue ?
<stgraber>  /proc/acpi/dsdt doesn't match the one in /etc/initramfs-tools/DSDT.aml
<stgraber> causing my fans to go crazy with Intrepid (that's something I changed in my custom DSDT)
<stgraber> Filed bug 246222
<stgraber> -ENOBOT :(
<alex_joni> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246222
<noelferreira> to eliminate the keys getting stuck and key repeat bug: https://bugs.launchpad.net/ubuntu/+bug/124406 - i disabled ACPI in my boot loader. However without ACPI my computer is always changing this brightness level (like every second). So now i can't complete work with or without ACPI. My system is completely unstable. This happens since i upgraded to hardy heron beta. Even if i change Gconf-editor in order not to automaticall
<noelferreira> y change brigthness level  this happens. Please let me now a workaround for this. I used Ubuntu since 'always' and i don't want to change distro now. please let me now a workaround for this. thanks
<Kano> hi BenC , rtg 
<Kano> rtg: still working on hardy?
<rtg> Kano: yep
<Kano> rtg: http://kanotix.com/files/kernel/unused-patches/linux-ubuntu-modules-2.6.24-2.6.24.uvcvideo.medion-e1210.patch
<Kano> thats for hardy
<Kano> this is the medium variant of the msi wind netbook
<Kano> for the integrated webcam, needs a similar hack like all other hacks for some cards
<Kano> [ 4348.883617] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0141)
<Kano> when you use it
<Kano> Medion Akoya mini E1210 is it called
<Kano> http://www.aldi-sued.de/de/html/offers/2827_7018.htm
<Kano> boots only with hardy .1
<rtg> Kano: how about sending a patch to akpm for the E1210? It should be in the uvc_ids[] array in drivers/media/video/uvc/uvc_driver.c
<Kano> it is in that array, look at the patch
<Kano> just an added entry with different id + comment
<Kano> rtg: did you notice that uvcvideo is in 2.6.26-rc9?
<rtg> Kano: See previous comment: ' It should be in the uvc_ids[] array in drivers/media/video/uvc/uvc_driver.'
<rtg> Kano: that is the path in the kernel sources.
<Kano> rtg: well that patch was for hardy lum
<rtg> Kano: I realize that, but I also noticed when uvc was included in the main kernel.
<lamont> rtg: btw, apt-get build-dep linux-source-2.6.26 fails on intrepid/sparc
<Kano> rtg: do you know when rc9 will be merged?
<rtg> lamont: whats missing? BenC has been doing the Intrepid stuff lately.
<lamont> makekerneldump ish
 * lamont doesn't have the error in front of him atm
<rtg> Kano: when BenC gets to it. He  was on holiday this weekend.
<lamont> E: Build-Depends dependency for linux cannot be satisfied because the package makedumpfile cannot be found
<rtg> lamont: iirc, its waiting on a MIR.
<Kano> lamont: wow you found that too ;) i had to fetch it from launchpad
<lamont> rtg: universe is in the list though...
<rtg> lamont: thats outside my area of expertise. we'll have to get BenC to comment.
<BenC> lamont: makedumpfile was built on sparc it seems, and moved to main recently
<BenC> lamont: oh wait, main linux package wont build on sparc anyway
<BenC> it's not meant to
<lamont> ah, ok
<BenC> -rc9 is rebased and pushed
<Kano> BenC: did you remove ubuntu/uvcvideo?
<Kano> if not,please do
<Kano> BenC: can you adopt this patch on your own: http://kanotix.com/files/kernel/unused-patches/linux-ubuntu-modules-2.6.24-2.6.24.uvcvideo.medion-e1210.patch
<Kano> just a different -p option needed
<Kano> in the right dir
<BenC> "EE: 4181 symbols changed hash and weren't ignored"
<BenC> rc8 to rc9...something core in the kernel must have changed
<rtg> BenC: ABI bump time
<zul> is it just me or this little weird in the server config file:
<zul> CONFIG_XEN=y
<zul> CONFIG_XEN_BLKDEV_FRONTEND=m
<zul> CONFIG_XEN_NETDEV_FRONTEND=m
<BenC> zul: you don't think people would use a xen guest as a server?
<BenC> well, everything from lum is now in intrepid kernel, with the exception of lirc
<zul> BenC: no I wasnt expecting it :)
<Kano> hi, it seems you are adding now extra drivers. do you want to add gspca too and maybe the ralink draft-n drivers (rt2860/rt2870)
<Kano> gspca should the easy
<BenC> gspca is already there
<Kano> hmm, will look again
<BenC> ubuntu/misc/media/gspcav1/
<mkrufky> BenC: did you have to patch au0828 / au8522 / xc5000 ?  afaik, there was only 1 xc5000 patch that didnt make it into 2.6.26
<BenC> mkrufky: uh...what are those? :)
<mkrufky> they're in hardy LUM
<mkrufky> heh
<mkrufky> if you didnt port them to the intrepid kernel, that's fine ////  i'll submit them again when i get around to it
<mkrufky> BenC: ^^
<mkrufky> BenC: so, those three are in the Hardy LUM ubuntu/media/au0828
<mkrufky> BenC: and afaik, 2.6.26 will have the same versions, except missing 1 change on the xc5000
<BenC> mkrufky: No, they must have showed up after I snapshot lum for intrepid
<mkrufky> ah, that would explain it
<mkrufky> so, i would say dont bother with the those three above....   if need be, i can port the missing change, but it shouldnt matter
<mkrufky> and the other driver i added to LUM, sms1xxx -- that one i would also wait on merging to intrepid.  once sms1xxx gets into mainline, i'll send you a pull request
<Kano> BenC: http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.26-uvc_driver-medion-e1210.patch
<Kano> uvc patch for 2.6.26 and medion webcam
<Kano> could you please add it
<mkrufky> Kano: its added already
<Kano> mkrufky: when?
<mkrufky> now, seriously.....  if you just sent it to uvcvideo, it would have been done by now
<mkrufky> and you wouldnt have had to ask a thousand times
<mkrufky> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=cdca2d54267cf74787b8ff59b20a9c8fcfcca7d0
<mkrufky> done
<Kano> mkrufky: that patch is for intrepid
<mkrufky> anyway, i am just a developer -- i dont represent ubuntu
<Kano> of course same patch, just differnt file
<Kano> BenC: gpsca is not enabled
<Kano> 100%, just compiled
<Kano> there is no module gspca
<tormod> I saw prism2_usb just got back into Intrepid. Can you please update it, as per bug 245026?
<Kano> tormod: you are the one with the xserver repo, right
<tormod> Kano: yes
<Kano> do you package the normal ones too?
<tormod> no, that would be tjaalton (on #ubuntu-x)
<Kano> BenC: do you want some more fimeware to add? 
<Kano> http://machts.net/Cinergy_HT_USB_XE/xc3028-v27.fw
<Kano> http://www.linuxtv.org/downloads/firmware/dvb-usb-dtt200u-01.fw
<Kano> these are definitely missing
<mkrufky> Kano: when you locate the distribution license for the xceive firmware, please send me a copy
<Kano> no idea where to find, maybe ask terratec
#ubuntu-kernel 2008-07-08
<BenC> I really wish Kano would look before speaking
<BenC> that dvb fw is already in lrm
<bullgard4> How does a 'kernel variable' differ from a 'kernel parameter'?
<BenC> bullgard4: I've never heard of a kernel variable, but I assume it refers to a kernel parameter
<bullgard4> One exmple: /usr/src/linux-headers-2.6.24-18/include/linux/timex.h Line# 191
<BenC> bullgard4: that's a kernel global variable, in the programming sense...not a kernel parameter
<bullgard4> Ah! Thank you for explaining.
<Kano> does gspca build for somebody with 2.6.26?
<Kano> it seems it is missing in ubuntu/Makefile
<Kano> hmm no, it is much simpler...
<Kano> obj-$(GSPOCA) is below...
<Kano> could somebody fix the typo
<Kano> remove the O please...
<amitk> Kano: fixed the typo
<Kano> good, now only my uvcvideo hotfix is needed ;)
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.26-uvc_driver-medion-e1210.patch
<Kano> thats what i use - already added to hardy lum
<Kano> well the gscpa module still does not compile, even with that fixed typo
<Kano> did somebody else try to compile the kernel?
<amitk> Kano: I am doing it...
<Kano> did the module build for you?
<amitk> no
<Kano> any ideas why it does not build?
<Kano> maybe CONFIG_ is missing in front
<Kano> 2 errors in same line it seems *g*
<amitk> Kano: really fixed now and it compiles
<Kano> i am still compiling with that change *g*
<Kano> hopefully it works, the standard makefile has some extra options enabled i think
<Kano> i can not test it, but at least i know some
<BenC> Good afternoon (morning, evening, whatever)
<BenC> Time for our weekly IRC meeting
<smb_tp_> hi
<cking> hi
<BenC> Basically we just want to review the progress for intrepid so far
<BenC> as of this week, a -rc8 based kernel is in the archive, and we have rebased to -rc9 in the git repo
<BenC> The current kernel in the archive is the one that will be in alpha 2
<BenC> most of the drivers from hardy linux-ubuntu-modules are now in the intrepid kernel tree
<BenC> lirc being the only exception
<cking> BenC: Is lirc scheduled to be included later?
<BenC> cking: if we can get it to compile
<BenC> ï»¿The linux-ports tree seems to be lagging right now...
<BenC> That's a nudge to the community to step up :)
<BenC> That's about all I have
<BenC> anyone have anything to add or ask?
<BenC> rtg: want to give an update on hardy SRU's?
<rtg> I'm doing 'em.
<rtg> hehe
<BenC> concise, I like it :)
<rtg> I'm working on getting the next batch uploaded as soon as the Hardy -security release is done.
<rtg> Hopefully later this week.
<BenC> rtg: any notable updates in that batch?
<rtg> Its an ABI bumper.
<BenC> rtg: anything we can do to prevent an ABI bump?
<smb_tp_> Not do the SRUs
<rtg> There are a couple of significant ACPI updates courtesy of smb
<rtg> can't remember what else, 'cause there a bunch stacked up
<BenC> rtg: are these SRU's in a tree where we can review them and investigate reworking the patches to prevent ABI bump?
<rtg> BenC: they are all in the working Hardy git repo
<rtg> I've also been building in my PPA all along
<rtg> Hence, my question earlier today about getting Hardy daily builds into the kernel PPA
<BenC> Ok...I might give it a once over today to see if we can do a test run of not bumping the ABI
<smb_tp_> The ones from ACPI unfortunately can't be different and after one bum the others won't hurt
<rtg> frankly, I have pretty strong opinions about why its a good idea to bump the ABI, I just have not taken the time to write 'em down. 
<rtg> I think there are at least 3 ABI bumpers.
<rtg> thats all from me.
<smb_tp_> Wasn't there one also from security?
<rtg> nope
<BenC> well, bumping the ABI is required if there is an actual reason to bump it...but if we can avoid it, all the better...it'd be a good exercise at the very least
<BenC> rtg: thanks
<BenC> Anyone else?
<smb_tp_> BenC, sure. have fun. :)
<rtg> smb_tp_: the security patches added a new public interface, but that doesn't cause an ABI bump
<smb_tp_> BenC, Nope
<smb_tp_> rtg, Ok, I might well be I remoember incorrectly
<BenC> Ok, meeting adjourned..have a great week and see you next Tue, same time, same place
<BenC> Oh, reminder, next week there will be no IRC meeting as we'll be at sprints
* 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.26-3.8 |  Latest news: 2.6.26 kernel is in Intrepid | Next meeting: July 22, 16:00 UTC | 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.26-3.9 |  Latest news: Please test last-good-boot, now in intrepid (grub/module-init-tools) | Next meeting: July 22, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<mkrufky> is intrepid safe for use yet, as a developer who doesnt mind hitting a small bug now & then?
<BenC> mkrufky: I can't say for sure...the kernel is pretty damn stable for me, but I am mostly hardy in userspace
<BenC> I know the intel/vesa Xorg was busted somehow and is getting fixed today
<mkrufky> ah, cool
<mkrufky> so, how do i try that?  (using interepoid kernel with hardy userspace)
<mkrufky> and, i dont want to waste your time with that kind of explanation -- if there's a howto or wiki page that would do just fine
<BenC> add intrepid to apt's sources.list, update and "sudo apt-get install linux-image-generic"
<BenC> may also want to install new linux-restricted-modules-common (which is where all the firmware went)
<mkrufky> then i would have to disable the intrepid repos afterwards to prevent from getting userspace stuff?
<BenC> "EE: 1401 symbols changed hash and weren't ignored"
<BenC> rtg: that's for the current hardy build :/
<rtg> BenC: thats almost like an ABI bump, huh?
<BenC> rtg: Just wonder how so many things changed
<BenC> that's about the same that I get when going from rcX to rcY
<BenC> and I mean the low rc's, not like rc8 to rc9 :)
<rtg> BenC: when there is that many changes its usually a fundamental macro, like when we went from SCHED_USER to SCHED_CGROUPS on -generic
<smb_tp_> BenC, If you change a basic struct that has a lot of dependencies. And maybe the ACPI stuff is basic enough
<BenC> I can't see how acpi can cause changes to a good chunk of the net core
<smb_tp_> BenC, Hm, no unlikely
<smb_tp_> BenC, might be something sounding harmless (like CONFIG_NETDEVICES_MULTIQUEUE=y)
<BenC> smb_tp_: agreed...your acpi change for cpuidle doesn't cause an ABI bump that I can tell
<smb_tp_> BenC, no the one sure candidate was that for the irq descriptor sizes
<rtg> BenC:  CONFIG_NETDEVICES_MULTIQUEUE is a likely culprit
<smb_tp_> BenC, I can't remember exactly either there was something before that irq descripttor size patch or it was that patch that bumbed the abi and after that we lost slightly track
<BenC> ok, MULTIQUEUE accounts for almost all of the abi changes
<BenC> cpuidle accounts for 19 changes
<BenC> rtg: what did we need multiqueue for again?
<rtg> wireless-testing in LBM needs it for 802.11n support
<rtg> BenC: or rather, compat-wireless
<BenC> rtg: will it compile without it?
<rtg> BenC: there was a period where it would not, but I have not checked lately. I figured it was as good a time as any to add an ABI bumping change since there were already some SRU changes that caused an ABI bump.
<BenC> Yeah, the two acpi changes cause an ABI bump as well
<BenC> ok, as long as we can account for the need for an ABI bump, I'm fine...the acpi fixes seem pretty serious (oopses)
<rtg> BenC: you don't think I let them in for free do you? I made smb_tp_ work hard for them :)
<BenC> hehe
<smb_tp_> Oh yeah... :)
<BenC> I trust your judgment, but I was hoping we could work them out somehow
<geser> Is the fix for bug 218516 already in the intrepid kernel? As I see the same problem with the intrepid kernel
<BenC> bug #218516
<BenC> hmm...why isn't ubotu in here :-/
<rtg> sadly, ubuntoid seems missing in action
<geser> http://launchpad.net/bugs/218516 [hardy] key events are delayed under circumstances
<gnomefreak> BenC: ubotu left with seveas 
<BenC> geser: doesn't seem to have made it upstream, so no, it's not in intrepid
<gnomefreak> ubottu is the new bot
<BenC> I wonder about the patch, since it didn't get accepted into 2.6.26
<_MMA_> rtg: Has Alessio talked with you regarding any upstream issues that are holding him up with -rt?
#ubuntu-kernel 2008-07-09
<TheMuso> c
<fabbione> BenC: ping?
<gabbs> linux-headers-2.6.24-20-openvz depends on linux-headers-2.6.24-20 however Package linux-headers-2.6.24-20 is not installed.
<gabbs> any idea guys how to fix that? can I build that headers deb seperately?
<smb_tp> gabbs, you need the basic headers which can be build with the binary-headers target
<smb_tp> fakeroot debian/rules binary-headers
<gabbs> cheers smb_tp 
<smb_tp> gabbs, np :)
<rtg> wow, only 2 days to get a patch in Linus's tree. that has to be the fastest ever. '[PATCH] uvcvideo - Add support for MEDION E1210 webcam'
<cking> rtg: that's speedy
<rtg> cking: yeah, it should make Kano happy.
<cking> rtg: and all MEDION E1210 webcam users too
<cking> rtg: Are you hammering the Intrepid kernel on any of your boxes?
<rtg> cking: nope. I've been totally focused on Hardy LTS issues.
<rtg> why?
<BenC> fabbione: ?
<cking> rtg: I upgraded my server and had a whole load of ssh lockups - fortunately the current git has a fix for this bug. Good way to waste 2 hours figuring out the problem
<rtg> cking: which network driver?
<rtg> or was it in the network stack?
<rtg> BenC: can you take a look at davis dmesg and tell me what you think?
<cking> rtg I suspect it was this : http://bugzilla.kernel.org/show_bug.cgi?id=10903
<rtg> cking: ah, you have a wireless interface on your server?
<cking> rtg: yep - cause I'm sick.
<rtg> cking: perhaps its better then drilling holes for a cable :)
<cking> rtg: it's a cheep RaLink RT2561/RT61 802.11g PCI - does the trick though
<rtg> cking: I'm thinking of doing the same for this SuperMicro cabinet I received last week. Its so shrill I can't stand to have it in the house.
<cking> rtg: yep - this was I can shove the box into the loft. It's just a pain when it goes wrong when I fowl up an upgrade 
<rtg> cking: crawling on hands and knees in the attic?
<BenC> rtg: davis dmesg?
<cking> rtg: fortunately my attic is very high
<rtg> BenC: davis.canonical.com is ill since the LTS upgrade.
 * cking thinks "Liberate tutemet ex inferis" should be "Liberate tutam me ex inferis"..
<BenC> rtg: could you point me to what exactly I am looking for?
<BenC> found it
<rtg> end of dmesh.
<rtg> blah, can't type
<BenC> No thoughts on that right this sec, but I'll check into it later
<rtg> BenC: its the second time davis has had problems, but this one looks different.
<rtg> I wish I'd have kept the first one. Maybe Ng has it squirreled somewhere.
<Ng> rtg: the thing I captured is davis:/home/rtg/cmsj-dmesg.txt
<rtg> BenC: ^^
<BenC> Ng: thanks
<Ng> np, it's the same file that's been there since before, so all I did was check its filename ;)
<BenC> Maybe I should break out my G5...but I suspect this is an smp issue and I'm UP
<rtg> BenC: it takes awhile, usually I have to thuimp it pretty hard with some kernel builds.
<rtg> cking: what package runs when a new ABI kernel is installed in the grub menu? 
<cking> rtg: Urrmm... not sure.
<rtg> cking: hmm, it has to be a post install hook. Michael Fey is having issue with a netbook.
<rtg> s/Fey/Frey/
<cking> rtg: This is an area where my knowledge is distinctly lacking
<rtg> cking: buried somewhere in debian/control-scripts/postinst is the answer
<cking> rtg: ah.. more layers of stuff
<rtg> cking: standard debian packaging cruft
<cking> rtg: ..as I said, "more layers of stuff" :)
<rtg> I wonder if update-initramfs does it?
<maks_> no
<maks_> it does try to call lilo to not fuck you up although
<rtg> maks_: but what builds the new entry in grup? 
<maks_> update-grub
<BenC> rtg: it's probably /etc/kernel-img.conf stuff?
<rtg> is grub smart enough?
<rtg> ah, maybe update-grub
<maks_> if it is indeed given as hook in /etc/kernel-img.conf
<maks_> not maybe rtg :)
<rtg> OMG thats an ugly script.
<cking> it appears that /etc/kernel-img.conf  have hooks for update-grub
<rtg> yep
<BenC> rtg: yeah, it was ripped from kernel-package, and I actually diluted it down a bit
<BenC> rtg: it could use a rewrite, but I've been of the opinion that "it works, leave it alone"
<rtg> you'll get no argument from me.
<cking> BenC: ..even if it is a maintenance nightmare in waiting
<BenC> cking: feel free to step up to the plate :)
<cking> BenC: Maybe when all the bugs are fixed :-)
<cking> ..and the sun has turned into a lump of coal
<gabbs> when I compile the target "custom-binary-openvz", which config do I have to alter ?
<rtg> gabbs: debian/binary-custom.d/openvz/config.*
<gabbs> and my selection of the processor type will decide if its i386 or amd64?
<gabbs> hmm ... no, that cant be lol - so which one gets taken? and whats figuring that out?
<rtg> gabbs: it depends on your platform, but dpkg-architecture tells the build which one to use. You can spoof it using a chroot wherein you can build 32 bit targets using a 64 bit host.
<gabbs> ah, cheers for that information! ã
<fabbione> BenC: drbd module doesn't load in 2.6.26-3
<fabbione> BenC: just a plain modprobe will fail.
<BenC> fabbione: the only error path I see for that is -EINVAL, which means "connector" cn exists
<gabbs> /root/openvz/debian/build/custom-source-openvz is not clean, please run 'make mrproper'
<gabbs> what does that mean?
<gabbs> I run make mrproper, rerun AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules custom-binary-openvz and it fails again
<rtg> gabbs: are you using the spurce package, or have to cloned the git repo? mrproper removed the debian directory
<rtg> s/spurce/source
<gabbs> I cloned it from the git repo, yea
<gabbs> then edited with make menuconfig the config file and tried to build the packages
<BenC> fabbione: fixed in git
<rtg> gabbs: ok, 'git checkout -f' to recover, but it will also blow away any local changes
<gabbs> rtg, those local changes thou (changes config) seem to cause this?
<rtg> dunno, depends on what changes you've made.
<rtg> can you at least build without any local changes?
<gabbs> well, literally only a make menuconfig, selected the debian/binary-custom.d/openvz/config.i386, exited - agreed to save, started build
<rtg> make sure you have a stable build environment first. see if 'debuild -b' will at least start. it ensures that all build deps are satisfied.
<gabbs> hmm .. whats debuild ?
<rtg> install devscripts
<rtg> sudo apt-get install devscripts
<gabbs> well, I am getting an output here
<gabbs> This package has a Debian revision number but there does not seem to be an appropriate original tar file or .orig directory in the parent directory;
<gabbs> (expected linux_2.6.24.orig.tar.gz or openvz.orig)
<gabbs> I assume thats ok if I got it from git ?
<rtg> that fine. what command did you run?
<gabbs> oh damn, I did a -d instead of -b
 * gabbs blushes
<gabbs> well, I did not confirm the "continue anyway?"
<rtg> ok, try 'debuild -b'
<gabbs> dpkg-buildpackage -rfakeroot -D -us -uc -b failed
<gabbs> should I switch to a non-priv user first?
<rtg> it should be bitching about unmet build dependencies
<rtg> you can also build from a standard user login
<gabbs> oh, I missed that one! kernel-wedge
 * gabbs loads it
<rtg> gabbs: once 'debuild -b' has gotten opast the first few lines you can kill it and run ' fakeroot debian/rules clean custom-binary-openvz'
<gabbs> so I don't have to meet all deps?
<gabbs> because some seem a bit excessive
<gabbs> ah, works now
<rtg> gabbs: thats what deps are all about. if you don't meet them, then you're on your own
<gabbs> the above command will start compilation, right?
<gabbs> because I'd need to modify the config still
<rtg> gabbs: make sure you can build from the repo _first_, then make modifications.
<gabbs> rtg, good point - thou when I execute the command, I get the same error msg
<gabbs> the weird part is, I did compile a kernel like that roughly 4 hours ago
<rtg> soren: is there a secret to installing kvm on Hardy? 'apt-get install kvm' produces "FATAL: Error inserting kvm_intel (/lib/modules/2.6.26-4-generic/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported"
<rtg> soren: never mind. I booted the Intrepid kernel.
<rtg> gabbs: what is the error message?
<gabbs> does any of this give you an idea what might be wrong rtg: http://rafb.net/p/RwgOKt39.html ?
<gabbs> I notice the "silentoldconfig" - could that cause problems?
<rtg> gabbs: 'make mrproper;git checkout -f'
<gabbs> afterwards issue the command for compilation again?
<rtg> fakeroot debian/rules custom-binary-openvz
<gabbs> without AUTOBUILD=1 NOEXTRAS=1 ?
<rtg> yes - without AUTOBUILD=1 NOEXTRAS=1
<gabbs> ah, seems to compile now
<gabbs> should I stop it and try with a changed config or let it run?
<rtg> let it finish
<gabbs> hm, thats gonna take an hour or so, but ok
<gabbs> btw, does anyone know what a halted boot sequence after "Checking 'hlt' instruction... done." ?
<BenC> fabbione: you will need to get drbd utils to build-dep on the new linux-libc-dev (>= 2.6.26-4.10) so that it can pick up the correct linux/connector.h where CN_{IDX,VAL}_DRBD are defined
<BenC> fabbione: and make sure to undef the internal ones (idx is conflicting with uvesafb)
<BenC> connector idx sync between kernel/userspace is pretty dumb...I would think there would be a way to do connectors by name, but I can't seem to find that mechanism
<gabbs> how do I use "make oldconfig" and make it write to debian/build-custom.d/openvz/config.i386 ?
<BenC> gabbs: mkdir build; cp debian/build-custom.d/openvz/config.i386 build/.config; make O=`pwd`/build oldconfig; mv build/.config debian/binary-custom.d/openvz/config.i386
<BenC> rm -rf build
 * powitsjj waves
<powitsjj> anyone home?
<Pizzaboy192> good morning
<Pizzaboy192> i need some hardware support
<powitsjj> lol...that doesnt help pizza, we ended up in the same place
<Pizzaboy192> bummer
<powitsjj> yeah
 * powitsjj shoots pizza in the face
<Pizzaboy192> (eats 6 year old chocolate)
<powitsjj> pwned
<Pizzaboy192> i should make an irc channel
<Pizzaboy192> #windows-dhould-die
<Pizzaboy192> chocolate is better when it is aged
<Pizzaboy192> it seems to get a more "firmented" taste to tit
<Pizzaboy192> *it
<powitsjj> hmm
<Pizzaboy192> lol
<Pizzaboy192> i wont say what i said, but you can see i said it
<Pizzaboy192> lol
<Pizzaboy192> im gonna go
<Pizzaboy192> ****************** talk to me on aim thelastwacker@aim.com
<the-fafa> hello. what does preemt mean for a kernel?
#ubuntu-kernel 2008-07-10
<soren> What's the magic I need to do to get my git branch to show up on gitweb?
<amitk> soren: Put it under /srv/kernel.ubuntu.com/git/soren on zinc and twiddle your fingers till the next run the script that publishes it
<soren> Oh!
<soren> I forgot to twiddle my thumbs.
<amitk> should happen withing the hour, IIRC
<soren> That's why you're the one who's on the kernel team, and not me.
<soren> Oh, it's there now. \o/
<amitk> i know.. we're good at twiddling ;)
<soren> amitk: By the way: Do you happen to know if it's cool for me to use zinc for hosting non-kernel git trees?
<amitk> soren: I don't think we are going to bitch about non-kernel git trees in the short term, but if you (and others) are going to require it over the longer term it might makes sense to talk to IS. Afterall, zinc == kernel.ubuntu.com
<soren> Cool, that's what I thought. Thanks.
<rtg> soren: zinc is so underutilized right now that I doubt anyone would even notice.
<soren> rtg: Heh :)
<amitk> soren: these kernel git trees you published, are they for the virtual flavours?
<soren> amitk: No.
<soren> amitk: I want to get the packaging sorted out first. that's on my list for the sprint next week.
<amitk> soren: are you going to have a different source pacakge or are you planning to build-dep on linux?
<soren> b-d on linux-source.
<amitk> rtg: any idea what is wrong here:
<amitk> II: Checking ABI for lpia...
<amitk> WW: Explicitly asked to ignore ABI, running in no-fail mode
<amitk> EE: Previous or current ABI file missing!
<amitk> soren: so you will maintain everything as patches?
<soren> amitk: I think so.
<rtg> amitk: I think I broke current git build last night , I'm working on it
<soren> amitk: There are a few options... Neither appeal to me very much.
<amitk> rtg: No.. this in in my lpia tree that is based off the main tree
<smb_tp> amitk, might be at least the modules list and maybe the abi files for the last release are not there. Fatal even if abi changes are ignored
<amitk> soren: same here. I am building an lpia tree and I don't want to maintain it as patches.
<soren> amitk: I can either maintain a completely separate tree, and rebase off of your now and then... That's probably the easiest, but will force me to move around *huge* source packages.
<soren> or
<amitk> smb_tp: but I explicitly asked for abi to be ignored by adding debian/abi/ignore
<rtg> amitk: you have to add it in each arch
<soren> I can try to maintain patches and separate configs.... That gives me small source packages, but if you rebase, and my stuff fails to apply, I have to work that out rather manually, AFAICT.
<amitk> soren: I am leaning towards the same solution
<rtg> debian/abi/lpia/ignore
<smb_tp> amitk, It seemed to me changes are ignored but the files must be there
<smb_tp> amitk, I tend to just create the files by copying some older directory to the name it wants for the old abi
<soren> amitk: The idea solution would be to have a separate git tree, and make it able to generate the needed patches on the fly, but... I don't know.. It's just a hassle.
<soren> I'd hate to have to maintain a completely new kernel build system for this.
<rtg> soren: in essence, that is what amitk is doing for lpia
<amitk> soren: I should have lpia done this week. I'll try to whip up scripts to automate the rebasing. We should collaborate...
<soren> amitk: Totally. I didn't know you were in the same boat.
<amitk> smb_tp: I have ignore and module.ignore files in every orifice of debian/abi/<version>/lpia :-/
<soren> amitk: How are you dealing with ABI checks?
<soren> Just ignoring them?
<amitk> soren: currently planning to have a different abi for lpia. Need to discuss with rest of the kernel-team though...
<soren> That's my intent as well.
<soren> If I have to maintain my own kernel, I want to actually have the freedom to mess it up any way I please (including changing core ABI stuff).
<smb_tp> amitk, I also thought this should be enough but recently I was force to just put the files with the modversions there as well until the abi checker was happy. :(
<rtg> soren: which is why lpia went to its own tree, freedom to release on their schedule with changes of their choosing.
<amitk> rtg: smb_tp: I have reset the abi to -1 in debian/changelog, renamed the source package to linux-lpia, regenerated contro.stub. So it is as good as the first upload. But ABI is failing...
<amitk> smb_tp: then something is broken....
<soren> rtg: I see.
<amitk> soren: exactly. the lpia kernel will be rebased occassionally (2-3 times during the release cycle). So we won't see too many abi bumps.
<smb_tp> amitk, the message itself is also a bit unclear. it would be more helpful if it would state whether ther old or new files are thought to be missing. 
<soren> amitk: Cool.
<rtg> amitk: debian/scripts/abi-check is pretty straightforward. instrument it to see why its bitching.
<soren> amitk: Well, if you've almost got it worked out, I won't spend any time on it until next week.
<soren> amitk: Oh.... You're in... London?
<soren> Yes, there was the visa thing. I remember.
<soren> I
<amitk> soren: I hope to push out the git tree before the week is out
<soren> 'm in Lexington, but at least there's some overlap in working hours anyway.
<soren> amitk: Cool!
<rtg> soren: know anything about file systems? Is there any file system faster at removing lots of small files then ext3? 
<soren> rtg: I though ext3 was supposed to be really fast at that?
<amitk> rtg: IIRC, xfs and jfs are better at smaller files.
<smb_tp> soren, no ext3 is slow ext4 should get better
<smb_tp> xfs is what I heard too
<rtg> soren: deleting a fully built kernel directory takes minutes.
<smb_tp> rtg, did you mount that with noatime?
<soren> xfs is slow at deletes.
<smb_tp> rtg, got the feeling it is faster now...
<rtg> smb_tp: relatime,errors=remount-ro
<rtg> smb_tp: standard mount magic
<amitk> rtg: 'rm -rf linux-dir &' :-p
<rtg> amitk: yeah - but my scripts want to reuse the directory. maybe I should rename, then 'rm -rf'
<smb_tp> rtg, I recently made myself a seperate fs for compiling (ok, its striped as well) and use notatime for that
<amitk> rtg: mv linux-dir linux-foo; rm -rf linux-foo &
<rtg> smb_tp: what does noatime do?
<smb_tp> rtg, does not put an access time to a file. which is otherwise updated everytime you access a file
<alex_joni> rtg: http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec73.html
<smb_tp> rtg, modification time is updated though
<soren> rtg: reiserfs is quite fast at deletes, too, but that sort of has maintainability issues now..
<rtg> soren: I have a reiserfs partition that I use daily for several years, in fact I created it using SuSE 6.x
<soren> rtg: So that's reiser... 3?
<soren> rtg: Oh, tmpfs is also rather fast at deletes.
<soren> !
<rtg> soren: whatever is current in Hardy must be backward compatible.
<soren> Certainly, but if the metadata format is ancient, the benchmarks, I'm looking at might be completely wrong.
<soren> (remove commas as needed)
<smb_tp> rtg, when we are at the real "good" advices why not ry ext2. who needs a journal for compiling... ;-)
<rtg> soren: well, the real performance issue is on this screaming fast server I got from Intel. It must havea _really_ slow disk.
<soren> smb_tp: Good point. ext2 is much faster than ext3 in this respect.
<cking> rtg: I use ext3 with noatime,nodiratime,reservation,relatime 
<rtg> cking: on /home ? or a separate partition?
<cking> rtg: on nearly everthing except boot
<amitk> ohhh all your geeks :)
<rtg> cking: the default install doesn't create  a /boot partition
<cking> amitk: seriously, it makes 2.347 nanoseconds difference :-)
<cking> rtg: yeah - I do my own custom kind of thing
<amitk> cking: now that _would_ be noticeable :)
<alex_joni> hardy does realatime by default afaik
<rtg> cking: how do I figure out what kind of hard drive is in this server, and how fast it is (relative to other hard drives) ?
<alex_joni> rtg: hdparm -tT /dev/foo is your friend
<cking> rtg: and dd is a quick way of benchmarking file I/O
<alex_joni> works on software RAID too: root@main:~# hdparm -tT /dev/md0
<alex_joni>  Timing cached reads:   8770 MB in  2.00 seconds = 4390.51 MB/sec :-)
<cking> rtg: ..don't twiddle hdparm -X unless you are prepared to screw up your data.
<rtg> /dev/sda1:
<rtg>  Timing cached reads:   13124 MB in  1.99 seconds = 6578.94 MB/sec
<rtg>  Timing buffered disk reads:  314 MB in  3.00 seconds = 104.56 MB/sec
<rtg> alex_joni: that doesn't look nearly as good as yours.
<cking> rtg: That's twice than what I get
<rtg> cking: actually, its twice what I get on my dev box as well.
<rtg> cking: alex_joni must be doing it against a tmpfs :)
<cking> rtg: This is where having 64Gb of 800Mhz DDR2 and the whole of the git source cached in there is a good thing
<rtg> cking: this box has 18GB. you would think that's almost enough.
<amitk> rtg: thats twice what I get
<smb_tp> rtg, maybe you should really use tmpfs for compiles...
<rtg> amitk: it literally takes 4-5 minutes to delete these directories. I think I'll reformat for ext2 with noatime.
<cking> rtg: ..I have some runes that I use:
<smb_tp> rtg, maybe first try noatime only. thats just a reboot/remount
<cking> I use tune2fs -O dir_index /dev/sdaX, e2fsck -D -f /dev/sdaX and mount /dev/sdaX with noatime,nodiratim,reservation
<cking> make that nodiratime
<soren> I haven't been paying much attention to the kernel during intrepid yet... How often do you roll new releases? Weekly-ish?
<rtg> cking: what are the relative merits of tmpfs? google has some entries where folks are mounting /tmp to tmpfs. 
<Tophat> has the new DNS security vulnerability been patched ?
<smb_tp> It's a ram-disk...
<rtg> smb_tp: I know that, but will it grow as large as it needs to?
<cking> rtg: It's fast - and if you have lots of memory it's useful. I suggest doing a build in a tmpfs mounted directory and it should fly.. 
<smb_tp> rtg, yes it should grow
<amitk> rtg: you still have the lag of copying the whole kernel tree to tmpfs
<cking> amitk: yeah.. how long will that take? 80 seconds?
<smb_tp> rtg, http://en.wikipedia.org/wiki/TMPFS
<rtg> cking: drat, it appears that its burned in. now I'm gonna have to haul that noisy thing in here where I can get at it. it least its not in my attic.
<amitk> cking: I've never felt a kernel compile to be very IO-bound, except for the final linking.
<smb_tp> amitk, there seem to be times in between when cpu usage goes down...
<cking> amitk: vmstat 1 seems to show a lot of I/O activity - I suppose with -j 4 or more, then it will be more CPU bound and any waits on I/O will be filled by CPU activity in the build
<soren> Tophat: http://www.ubuntu.com/usn/usn-622-1
<cking> amitk: at the end of the day it's either memory, CPU or disk I/O bottlenecking somewhere.. :-)
<amitk> cking: true..
<Tophat> soren - have you seen any POC on this attack?
<soren> no
<soren> Besides, this is off-topic here.
<soren> Try in #ubuntu
<Ng> is alsa 1.0.17 likely to be in intrepid?
<Ng> the kernel drivery bits, I mean
<rtg> Ng: if not in the kernel, then we'll likely backport it in LBM
<Ng> where "in the kernel" means in LUM? or is it moving to linux-image?
<Ng> not that that really matters, so long as it's available, my fellow x300 users will be spared having to worry about getting sound support. thanks :)
<amitk> Ng: LUM is no more, everything is in the main git tree now
<rtg> Ng: ALSA is part of the core kernel. Actually, when we backport 1.0.17 (if its a superset of core kernel) it will end up in the Intrepid equivalent of LUM.
<Ng> aha
<Ng> atm my x300 specific LUM with an rc of 1.0.17 is a horrific mess that happens to just about work ;)
<pgraner> rtg: who is the v4l driver SME?
<rtg> pgraner: dunno. whats an SME?
<rtg> souce maintainer extraordinaore?
<pgraner> rtg: Subject Matter Expert
<rtg> pgraner: ah, a new TLA
<pgraner> rtg: specifically the em28xx driver
<rtg> pgraner: maybe talk to jono and find out who did the filming at UDS?
<rtg> em28xx being what your handy cam supports?
<pgraner> rtg: no its a tv tuner....
<smb_tp> maybe mkrufky might be of help
<pgraner> rtg: I'm using a Mac for the video at the sprint just for speed.
<rtg> smb_tp: yeah - mkrufky is trhe hauppage dude.
<mkrufky> i am back
 * mkrufky catching up on backlog
<mkrufky> ok, yeah i am the guy
<mkrufky> what is the question?
<pgraner> smb_tp: cool.... I have a Bus 005 Device 038: ID 2040:6513 Hauppauge and I can't get hardy to recognize it
<mkrufky> btw, i am moreso "the guy" because of my linuxtv affiliation rather than my hauppauge affiliation
<mkrufky> hary does not support 2040:6513 out of the box
<mkrufky> but it will be supported in intrepid
<mkrufky> ... but you will need to grab the xc3028-v27.fw image
<mkrufky> if you want to run it in hardy, you may use the mercurial repository hosted at http://linuxtv.org
<pgraner> mkrufky: cool. Is the support in the alpha1/2? 
<mkrufky> i do not plan on backporting this one to hardy LUM
<rtg> pgraner: I thought you were expressing intrepid upgrade woes the other day.
<mkrufky> pgraner: it's in the 2.6.26 kernel...  i have not been tracking interpid, but intrepid has 2.6.26, so thats what u need
<pgraner> pgraner: I got the sound fixed, which was the big issue other than no changelog
<mkrufky> TLA ?
<smb_tp> three letter acronym
<mkrufky> :-) ok cool
<pgraner> rtg: I had to blacklist the snd_pcsp module and the cracking went bye bye
<rtg> pgraner: my somewhat oblique point being, support for your device is already in Intrepid
<mkrufky> ironically, however, the next gen version of the 950 is in hardy LUM
<pgraner> mkrufky: what does a *** unknown tvp3e04 chip detected *** Rom ver is 12.0 mean?
<mkrufky> that depends on the context
<mkrufky> where did you see said message?
<mkrufky> i'll assume you saw it in dmesg log
<mkrufky> if so, can you paste it with some context on a pastebin somewhere ?
<pgraner> mkrufky: /var/log/messages after loading the module em28xx tells me that if found a Hauppague WinTV HVR 950
<mkrufky> context ... pastebin ...
<mkrufky> please show me dmesg | tail -n100
<pgraner> mkrufky: one sec different box
<mkrufky> k
<mkrufky> pgraner: if you do " lsmod | grep tvp " and you do NOT see tvp5150, then thats your problem
<pgraner> mkrufky: its there
<mkrufky> how many users ,... 1 or 0 ?
<pgraner> mkrufky: http://pastebin.com/m7750bdbf
<mkrufky> pgraner: tvp5150 0-005c: tvp5150am1 detected.
<mkrufky> pgraner: please try a different usb port
<pgraner> mkrufky: just did
<pgraner> mkrufky: dmesg is still telling me the tvp3e04 is unknown with i2c i/o errors
<mkrufky> did you try it?  does it work?
<pgraner> mkrufky: its channel scanning now
<mkrufky> the error message is coming from the analog video decoder driver
<mkrufky> it looks like its complaining, then attaching correctly
<mkrufky> i have not seen this before
<pgraner> mkrufky: ok working now, I'm seeing channels during the scan
<mkrufky> it might work anyway
<mkrufky> but seems strange
<mkrufky> yeah, the tvp thing would not affect digital tv
<mkrufky> only analog
<pgraner> mkrufky: no audio as of yet
<mkrufky> what do you mean , no audio?
<mkrufky> if you're watching digital TV, then the audio is part of the mpeg2 stream
<pgraner> mkrufky: no audio, I can play mp3s, hear the lovely login music, but nothing from the tv tuner. I'm messing with alsa settings now
<mkrufky> are you watching digital tv or no?
<mkrufky> if you're watching analog tv and have no audio, then i can tell you what to do
<pgraner> mkrufky: I'm watching tv, don't know how to tell if its digital or not.
<mkrufky> HOW are you watching tv?
<mkrufky> what app?  what channel?
<pgraner> mkrufky: tvtime channel 5 (CSPAN)
<mkrufky> ok
<mkrufky> you're watching analog tv
<mkrufky> in order to get audio, google "arecord aplay tvtime"
<mkrufky> or google, "sox tvtime"
<mkrufky> there is no TV application that does this right, unfortunately, except for mythtv
<mkrufky> note: ANALOG
<mkrufky> digital tv "JustWorks(tm)"
<pgraner> mkrufky: ok the aplay trick worked
<pgraner> mkrufky: how do I get the digital then?
<mkrufky> we are sooooo off topic
<pgraner> mkrufky: yea, I'll google
<mkrufky> just real quick:
<mkrufky> first, scan for channels using scan from dvb-apps
<mkrufky> (dvb-utils from apt)
<mkrufky> then azap CHANN_EL -r    (-r is important)  ...  leave that running
<mkrufky> open a new shell, run: mplayer /dev/dvb/adapter0/dvr0
<mkrufky> thats is for a basic test
<mkrufky> google will give you more detailed info
<mkrufky> oh, you need to drop that channels.conf file (from your scan) into ~/.azap
<pgraner> mkrufky: got it thanks
<mkrufky> you're welcome
<mkrufky> for future reference, #linuxtv is a better venue for these questions
<mkrufky> im usually in there, but i am not right now
#ubuntu-kernel 2008-07-11
<doko> rtg (and BenC): are you ok having dkms in main?
<rtg> doko: pitti probably has the best opinion.
<rtg> he's had (by far) the most experience with it.
<rtg> doko: the kernel team has been promoting dkms as a solution for external module ABI issues. Two of the LRM drivers have been moved to dkms for Intrepid.
<fafa_> i get kernel panic with hypervisor_callback stuff. who knows what to do to debug or fix this? its a kernel from the repository
<sourcemaker> how can I disable the martian source  kernel check???
#ubuntu-kernel 2008-07-12
<CMDL1N3> hello.
<CMDL1N3> i am now booting off of the linux-generic kernel for SMP and it is very unstable.  any ideas?
<IntuitiveNipple> Is anyone familiar with the process for PPA uploads of the kernel to *personal* archives for bug-fixing purposes? I've looked at prepare-ppa-source and tried it but it doesn't handle the required changelog versioning.
<mkrufky> i just noticed....  in Hardy LUM, sms1xxx is selected in i386, amd64 and lpia
<mkrufky> xc5000 au0828 and au8522 should also be selected in lpia
<mkrufky> (currently only enabled in i386 and amd64)
<mkrufky> i dont think there's any reason not to enable all of the above in all arch's ....   but i have only tested personally on i386, amd64 and lpia
#ubuntu-kernel 2008-07-13
<planofish> for a kernel update you dont need a reboot do you
<planofish> unles it's kexec isnt it
<crimsun> you do need to reboot to effect it.
<planofish> so for kexec the kernel has to have support for that.. I don't think it can be done as a module, either can it?
<crimsun> I'm not up to speed WRT kexec, sorry, but you definitely need to reboot for the supported Ubuntu releases.
<planofish> ok
<planofish> ubuntu doesnt ship with kexec, apparently 
<planofish> The program 'kexec' is currently not installed.  You can install it by typing: apt-get install kexec-tools
<planofish> crap
<planofish> another thing
<planofish> drivers/crypto/Kconfig:51: can't open file "arch/s390/crypto/Kconfig"
<planofish> make[1]: *** [menuconfig] Error 1
<planofish> friggin annoying
<planofish> i'm trying to see if ubuntu compiles that option into its kernel but it obviously does
<planofish> I know I have support for it
<planofish> I've had this problem with the packaged stock kernel on both i686 and x86_64 incarnations of ArchLinux
<planofish> anyone around?
<planofish> if i get menuconfig working, it's under "processor type and features -> kexec system call" the config symbol is ermmm CONFIG_KEXEC
<planofish> doesn't allow it to be a module?
<planofish> i'm not even on an s390 box,  this S/390 crypto thing chokes and won't allow me to run make menuconfig.
<planofish> Anyone around?
<crimsun> (it's 9 PM localtime on the weekend.  You won't find many Canonical kernel employees lurking.)
<planofish> seems like it
<planofish> Since this is kexec related not your forte
 * planofish sighs
<planofish> where is TJJJJJJJJJJJ
<planofish> :P
<planofish> Later
<zbrown> Hi, you guys have any clues on the DMA issue with dvd/cd drives in Hardy?
<zbrown> specifically this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/228624
<fafa_> what do i have to enable in my config, and what is to be done after the build and install to use device-mapper?
<CMD_L1N3> i need some help reinstalling a kernel
#ubuntu-kernel 2009-07-06
<thrice`> hi all; I can't, for the life of me, find updated kernel packages for jaunty; I know they are on kernel.ubuntu.org *somewhere* :>
<saispo> hi
<saispo> have you planned to sync the kernel git with the latest update ?
<saispo> (for hardy LTS)
<smb> saispo, yes, give me a bit to verify everything is ok
<smb> should get pushed in the next few hours
<saispo> smb: ok thanks :)
<ogra> help !!!
<ogra> http://paste.ubuntu.com/211129/
<ogra> i see that since my last kernel upgrade 
<ogra> and have lots and lots of filesystem issues all of a sudden
<souphorn> In ubuntu, is there any way that I can write actionscript and release swf file?
<ogra> apw, any idea what changed in the ACPI code that could cause this ? i see there are more ACPI issues in my dmesg
<apw> ogra, hrm nothing specific springs to mind, but it was exploding for some people so they are clearly fiddling
<ogra> hrm, i'd love to keep my filesystem though
<apw> there is an all new shinier kernel coming today, its already uploaded and built, just waiting for binary new
<ogra> seems it slowly falls into pieces
<apw> hrm comments there on acpi, as for filesysystems which one you useing?
<apw> and ogra whats the version (cat /proc/version_signature)
<ogra> Ubuntu 2.6.31-1.14-generic
<ogra> using ext3 
<ogra> sata laptop disk 
<ogra> through AHCI
<apw> so pretty much what i am running generally
<apw> what sort of filesystem errors you seeing
<ogra> my mtab content showed up in /etc/xdg/compiz/compiz-manager for example
<ogra> i had a corrupted binutils lib 
<apw> thats definatly not well for sure
<ogra> no
<ogra> but no oopses, no fs errors in the logs or anything
<apw> i am running ext3 with karmic kernels here and not seeing such fookage
<ogra> all i see is the ACPI stuff in dmesg
<apw> smb, you running any karmic kernels anywhere, ogra seems to have ext3 badness
<ogra> well, i suspect its rather ahci 
<ogra> below filesystem ... and the filesystem stuff just being a fallout
<smb> apw, On my aa1, yes
<smb> but that has no ahci as well
<ogra> [    1.261087] ata1.00: _GTF unexpected object type 0x1
<ogra> ^^^ just discovered that one
<apw> ogra, when did you notice this new 'behaviour'
<apw> v=what version was ok?
<ogra> after this mornings dist-upgrade
<ogra> and i think my last one was thu or fri
<ogra> system worked flawless over the weekend 
<apw> what version did you have before
<apw> apt logs in /var/log should tell you 
<ogra> dpkg.log you mean ? 
<apw> probabally
<ogra> 2009-07-03 17:15:07 status installed linux-image-2.6.31-1-generic 2.6.31-1.14 
<ogra> thats when i had a kernel upgrade it seems
<ogra> 2009-07-02 14:36:26 status installed linux-image-generic 2.6.31.1.11
<ogra> hmm
<ogra> 2009-07-02 14:35:56 status installed linux-image-2.6.31-1-generic 2.6.31-1.13
<apw> so before the period of stability
<apw> 13 to 14 was almost 0 change
<ogra> well, there are definately filesystem issues, sadly i didnt check dmesg the recent times
<ogra> (we should really put /var/log/dmesg in logrotate so you can compare)
<apw> ogra, well i'd suggest getting the -2.15 kernel asap, as thats an -rc2 rebase
<ogra> sure, as soon as its there
<apw> we are waiting on an admin to binary new it in
<ogra> there was also a new binutils snapshot upload 
 * apw is also running it now
<ogra> it might as well be binutils
<ogra> but i wouldnt know why i see ACPI errors in demsg 
<apw> bin utils should not be able to feck your fs really if it didn't clean it
<apw> that is likely an acpi fookup and hopfully separate
<ogra> well, a f*cked binutils lib can break a lot of stuff :)
<ogra> but indeed not cause acpi errors
<apw> ogra, if you want a preview of the kernel its in my /daily PPA
<ogra> "Development Kernel Snapshots" ?
<ogra> ah, yeah, i see 2.6.31-2.15
<apw> ogra, yep thats the one
<ogra> WARNING: Couldn't open directory /tmp/mkinitramfs_VL4D8S/lib/modules/2.6.31-1-generic: No such file or directory
<ogra> FATAL: Could not open /tmp/mkinitramfs_VL4D8S/lib/modules/2.6.31-1-generic/modules.dep.temp for writing: No such file or directory
<ogra> geez
<ogra> same ACPI errors
<ogra> ah... and that one is likely responsible for my CPU not scaling below 1GHz anymore
<ogra> [    0.541865] ACPI Warning: Invalid throttling state, reset 20090521 processor_throttling-843
<apw> puch
<apw> ouch
<\sh> dear kernel devs of ubuntu...I have some BL465c servers here...and jaunty kernel complains about not correctly understandable acpi tables...I should tell upstream and my distro kernel team ;) what do you need to analyze it?
<smb> \sh, your pants, your jacket and your sunglasses... or file a bug with the dmesg out put and the output of 'sudo acpidump -o acpidump.txt' with a description of which things the kernel complains. Usually you will be asked to try a more recent kernel (e.g. from https://wiki.ubuntu.com/KernelMainlineBuilds) to see whether this already got fixed.
<\sh> smb: k, but sadly I can't test any other kernel then jaunties ;) looks like that it only has to do something with new world order of HP blade series
<smb> \sh, That sounds bad. Be sure to add this to the bug report, too.
<\sh> smb: especially power management ... not the same as with dl365G5 (which should be the rackmountable of this type)
<DawnLight> hello. can anyone please take a look at #389992 and give me a hint on what's going wrong?
<levonshe> good day all, Whuy kernel versions from site ftp://ftp.ubuntulinux.org/ubuntu/pool/main/l/linux/ do not match Makefile exrtaversion, for example  linux-source-2.6.28_2.6.28-13.45_all.deb has Makefile extraversion=9 and no 13 ??
<primes2h> ogasawara_: are you around here?
<smb> levonshe, The extraversion number in the makefile just reflects the upstream stable number which the kernel is based on. The -13 refers to the number of ABI changes and is not related.
<kklimonda> how suitable is server kernel for desktops?
<ogasawara> primes2h: what's up, need something?
<primes2h> ogasawara: Hello, could you have a look on this please? bug #352765
<ubot3> Malone bug 352765 in linux "Logitech webcam doesn't work (v4l2 support needed)" [Medium,Confirmed] https://launchpad.net/bugs/352765
<primes2h> sorry foosorry for the mess about upstream bug but I couldn't change the link.
<primes2h> ogasawara: sorry for
<primes2h> ogasawara: do you think it's a kernel issue?
<primes2h> it's hard to figure out.
<ogasawara> primes2h: don't suppose you tested booting back into the hardy kernel on your friends' laptop?
<primes2h> ogasawara: I tested and it works...
<primes2h> ogasawara: I had it just for few minutes unfortunately...
<DawnLight> i'm willing to pay for a fix for bug #389992
<ubot3> Malone bug 389992 in linux "failing to connect using sierra aircard 880e" [Undecided,New] https://launchpad.net/bugs/389992
<primes2h> ogasawara: I submitted an hardware test about that laptop. You can find it here https://edge.launchpad.net/+hwdb/+submission/b87cad4fd5ae659cd83acf099e7ac9d1
<ogasawara> primes2h: awesome, thanks
<ogasawara> primes2h: I'll get it on the team's bug list for this week
<levonshe> smb, thanks, By upstream stable number upu mean kernel.org number ?
<primes2h> ogasawara: That's nice. Tell me if you need something, maybe I could have that laptop this weekend to work on.
<ogasawara> primes2h: will do
<smb> levonshe, kernel.org, yes. And it gets increased when stable (e.g. 2.6.28.y) releases are done
<primes2h> ogasawara: ok, thank you very much.
<ogra_> does anyone know a status of mount --union ? the ltsp folks are heavily suffering from 5minute thin client boots with unionfs-fuse and nag me regulary when a better solution will happen
 * ogra jumps up and down and waves
 * smb sees ogra but has no answer
<ogra> heh
<jjohansen> ogra: union mounts have some known problems for our use but the devs haven't been able to get to them yet
<ogra> jjohansen, do you know if they might get to it in time for karmic ? 
<ogra> ltsp is pretty screwed with unionfs-fuse but i dont see any better solution atm 
<jjohansen> ogra: I don't, I pinged jan last week and he said he had to do some locking rework because he had messed that up and it was his current top todo
<ogra> hmm, k
<ogra> thanks for the answer at least even though there is no light at the end of the tunnel yet :)
<holzmodem> hi, my laptop need a fixed dsdt file. is it true, that the kernel > 2.6.30 no longer support loading custom DSDT file thru initramfs?
<Kano> hi apw , you know that device mapper is broken with 2.6.31-rc2?
<Kano> http://patchwork.kernel.org/patch/33534/mbox/
<Kano> that does fix it
<Kano> before my raid was gone...
<Sarvatt> darn, dmraid update makes powerpc fail to build
<TheMuso> Sarvatt: Yeah, and I think it can be turned off for powerpc as well.
 * TheMuso preps a request pull for the kernel guys
<billybigrig> can anyone suggest how i contact the gspca maintainer?
<billybigrig> or find out who maintains is?
#ubuntu-kernel 2009-07-07
<Kano> TheMuso: you know that dmraid only needs the hd meta data? you can use hds with it even on systems which do NOT have got a raid bios at all. At least when you are not requried to boot from it.
<Kano> TheMuso: so basically you could use a ppc to access hds from a pc raid too.
<Kano> but that all would only work with a working dm
<Kano> and that is broken
<Kano> http://patchwork.kernel.org/patch/33534/
<Kano> without all with dm is useless
<TheMuso> Kano: I know that. The module is only used for RAID 5 arrays, and teh likelyhood of users using powerpc to access such arrays is very low. Most macs for example would require at least 2 E-Sata cards to allow people to connect the minimum of 3 drives needed for a RAID5 array.
<Kano> and the space requirement for that module is so big ;)
<Kano> why did nobody test dm functionality at all?
<TheMuso> Well, the code builds on other architectures, and the code looks ok, so no idea why gcc on powerpc complained about it.
<TheMuso> Kano: I don't know, you will have to ask the kernel team. I am only helping out with powerpc, because its a ports architecture I care about.
<lifeless> TheMuso: can't you daisy chain sata?
<TheMuso> lifeless: not afaik.
<TheMuso> lifeless: You're probably thinking of firewire.
<TheMuso> In which case, a user could set drives up with firewire, once they were in docks/caddies that supported firewire.
<TheMuso> in any case, I think for most users to use ppc for dmraid stuff, it would be too much effort. There is also endianness issues that may yet need resolving.
<lifeless> actually, fibrechannel I think is what I was thinking of
<smb> That would be my believe as well. sata being 1-1 only
<smb> fibrechannel? isn't that a san topology?
 * TheMuso learns something new.
<TheMuso> I knew of fibre channel, but didn't know it could be chained.
<smb> I neither, but my knowledge could be patchy too
<smb> TheMuso, Ok, seems with arbitrated loop layout you seem to be able to daisy chain the devices 
<Kano> well you can use port mulitpliers for sata
<TheMuso> I'm not sure how well those would work.
<cking> apw, the fan overheating bug -  I will double check this on my other laptops now.
<cking> to see if is generic rather than related to specific models.
<apw> cking, thats great.  if you confirm its hibernate which triggers the behaviour then we can ask whether that is a common thread on the bug
<apw> also have you tested suspend too?
<cking> not yet. I woke up at 3am this morning and it hit me that hibernate was the only thing I've done in both cases where I have done this over the past few months.
<cking> ..so I've only just tested hibernate
<apw> cking, you should be sleeping when the clock has those kind of times on it
<cking> eh?
<cking> oh, yeh.
<cking> You know how it is, you sleep on a problem then bingo at 3.00am you wake up with a solution
<jjohansen> or you could just be an insomniac
<amitk> like jjohansen 
<amitk> jjohansen: do you ever sleep?
<jjohansen> weekends
<amitk> heh
<cking> not sleeping wrecks the memory 
<jjohansen> cking: yep
<jjohansen> actually I do usually sleep, I just have a tendency to work until 2 or 3 in the morning
<apw> jjohansen, stop confusing me
<jjohansen> apw: ?
<apw> by being awake allt he time
<jjohansen> apw: is that a not so subtle hint?
<apw> heh ... you are a little time challenged ... 
<apw> cjwatson, we seem to have a further bug relating to the bnx2 firmware loading stuff; we are missing firmware.sh to do the actual load (see bug #394783).  i've pushed up a bzr branch up a bzr branch on that bug which should fix it.  perhaps you could have a look when you are not busy [sic]
<ubot3> Malone bug 394783 in udev "Broadcom BCM5708 "SIOCSIFADDR: No such device"" [Medium,In progress] https://launchpad.net/bugs/394783
<cjwatson> apw: you need to copy 50-firmware.rules as well
<cjwatson> apw: I'd also remove the mention of udebs in the initramfs - that isn't really relevant here and it's confusin
<cjwatson> g
<cjwatson> apw: Keybuk should sign off on this really
<Keybuk> we've generally tried to avoid having firmware in the initramfs *sigh*
<apw> cjwatson, ahh ok ... of course.  doh
<apw> Keybuk, heh yeah, but we have firmware and no way to load it.
<apw> will update the branch and hastle Keybuk instead :)
<Q-FUNK> howdy!
<Keybuk> apw: err, hang on
<Keybuk> back up a *LOT*
<Q-FUNK> is there anything else I need to provide for bug #396286 ?
<ubot3> Malone bug 396286 in linux "kernel 2.6.31-generic oops after loading initramfs" [Undecided,New] https://launchpad.net/bugs/396286
<Keybuk> why are you talking about adding firmware to the initramfs for a *network* card ?!
<Keybuk> a network card isn't critical to mounting the root filesystem
<apw> Keybuk, it is if its on a netowkr?
<Keybuk> apw: so we should add wpa_supplicant to the initramfs as well, just in case they want to NFS mount over a WPA-secured wireless network?! :p
<apw> nfsroot i assume in this case, cjwatson was involved in the changes to bring the firmware to a udeb, and may know the use model
<Keybuk> when we originally added the netroot support, we decided we'd only support sensible cards
<Keybuk> wired network cards that didn't need firmware
<Keybuk> also the bug doesn't sound like the user is trying to netboot from it
<apw> i am suspicious that we have brought in the bnx2 card to fix something, and that has broken general bnx2 support
<Keybuk> it sounds like they have a problem that the module doesn't work even after the system is fully booted
<Keybuk> which is more likely a module bug than a udev one
<Keybuk> since udev will just supply the firmware later
<cjwatson> apw: I was involved in adding firmware to the *udeb*, not to the initramfs, FWIW
<apw> for the installer, yes, i am conflating
<Keybuk> I would guess that this is a module bug
<Keybuk> it's probably setting some insanely stupid timeout for firmware
<Keybuk> "if I don't get firmware within 500 ms I'm going to lobotomise myself"
<apw> looks like 60s per card in this case yes
<Keybuk> 60s should be long enough to boot
<Keybuk> but if they have scsi drives, it might not be
<apw> but the issue seems to be if it fails, then the driver is loaded, and does not get loaded
<cjwatson> we could just take bnx2 out of the initramfs ...
<Keybuk> wait, back up again!
<apw> cjwatson, that would work i suspect in this case
<Keybuk> stop trying to ride the rollercoaster of assumptions
<apw> but but but we like that game its loads of fun
<Keybuk> there is a wonderful system called "uevents" tied with this thing called the "/sys filesystem"
<apw> yep
<Keybuk> when a module wants firmware, it creates a kobject in the firmware class
<apw> yep
<Keybuk> so if a module is calling out for firmware, there will be an entry in /sys/class/firmware for it
<cjwatson> (FWIW I'm not assuming anything about the problem here other than "why is bnx2 in the initramfs in the first place, since it needs firmware to work")
<Keybuk> cjwatson: well, yes that I'd agree with - I was talking to apw ;)
<Keybuk> apw: now, if the module calls out for firmware and just *waits*
<apw> my only assumption was that the bug was real and needed fixing :)
<Keybuk> then when we run udevadm trigger while booting the full system
<Keybuk> udev will see that there's the outstanding firmware request
<Keybuk> and
<Keybuk> ...
<Keybuk> *supply the firmware*
<Keybuk> so, all you should need to do to fix this is make the module more patient
<Keybuk> arguably it's also a bug that after it fails to get firmware it stays loaded
<Keybuk> it should fail to load
<apw> but at that point the kernell is waiting 
<Keybuk> no
<Keybuk> the kernel isn't waiting
<Keybuk> the module is waiting
<apw> indeed, but the boot process is waiting for the load
<Keybuk> no it isn't
<apw> so we get a full 2 minute delay for giggle in this case
<Keybuk> no we don't
<apw> dmesg dissagrees with you
<Keybuk> right
<Keybuk> that's exactly my point
<Keybuk> this is a buggy module
<Keybuk> it's doing firmware wrong
<Keybuk> it's most likely sitting in a loop going "Dude, where's my firmware?"
<apw> well request_firmware interface is the standard way, and thats its semantic
<apw> get the firmware and wait for it to occur
<apw> so there are three ways forward
<apw> 1) fix loading firmware in initramfs
<apw> 2) stop loading bnx2 somehow
<apw> 3) fix bnx2 somehow
<Keybuk> but why is request_firmware() a problem here?
<apw> because its a blocking interface
<Keybuk> it should only block that one module's _init()
<apw> and will that not block modprobe
<Keybuk> also request_firmware_nowait() 
<Keybuk> though not much uses that
<Keybuk> it'll block modprobe
<Keybuk> oh, duh
<Keybuk> sorry, I was going on a "but we don't call udevadm settle in the initramfs" line
<Keybuk> but we do now
<Keybuk> to fix a different bug
<Keybuk> ok, I concede your point ;)
<Keybuk> the way we do the initramfs means you'll block waiting for that modprobe to complete - and it can't
<apw> heh ... at least i am not completley mad
<Keybuk> yeah, so just don't ship that module in the initramfs ;)
<apw> ok ... what decides whats in there i wonder
<ogra> auto_add_modules() in /usr/share/initramfs-tools/hook-functions iirc
<Keybuk> ogra: correct, it's a hardcoded list there
<cjwatson> yes, I have it fixed in my tree
<cjwatson> I'll upload now if folks are ok with that
<apw> why is bnx2 in there now?
<apw> is that a manual list of modules without firmware?
<cjwatson> we added lots of random network modules
<cjwatson> keen though I normally am to find the reasons why things are as they are right now, I think you ascribe too much thought to that code
<apw> hehe ... :)  probabally
<apw> ok so i'll shove this bug over to initramfs-tools then
<cjwatson> aye
<Keybuk> cjwatson: of course, we should probably address the whole needing firmware thing
<Keybuk> that code isn't exactly fluffy
<Keybuk> if you want to do netroot, we could apply much more common sense to it
<apw> is it so bad to just include the firmware loader for that (when and if we decide to so support)?
<apw> seems to be two files and the firmware
<apw> wihch mostly used to be in the kernel and is sliding out into files
<Keybuk> apw: yes, because then we'll suddenly need all the firmware in the initramfs
<Keybuk> 11M	/lib/firmware
<Keybuk> which is larger than the initramfs itself!
<ogra> surely compresses good :P
<Keybuk> ogra: why, it's binary blob?
<apw> i am never quite sure why we don't only put in the ones we need
<apw> into the initrd
<ogra> Keybuk, thus the ":P"
<apw> given it is rebuilt for every machine
<Keybuk> apw: because the kernel never bothered to add any header to a module to list the associated firmware files? :)
<Keybuk> so we can't actually *tell* what firmware files we need
<Keybuk> and instead would have to maintain a list by hand, to go with the by-hand list of modules
<apw> heh now thats a valid arguemnt if there ever was one
<cjwatson> apw: we've also long had a general design goal to make disks portable across hardware - that is, if you replace some components in your computer, your Ubuntu installation shouldn't fail to boot, and you should even be able to boot the system on a totally different computer to some reasonable extent - think USB disks
<cjwatson> apw: which is why we don't use the MODULES=dep initramfs building mode by default
<apw> i have wondered at times if it would make sense to use the current mode for the recovery boot, and a =dep mode for the initrd for the default entry
<apw> loading the initrd is pretty slow generally
<Keybuk> apw: not really, the fallback case isn't pretty
<Keybuk> ie. if we can't mount the filesystem, then we can't write the magic that tells grub to try recovery mode next time
<apw> indeed it would be manual i guess
<Keybuk> more interesting would be if grub could somehow set that itself
<Keybuk> ie. after any menu selection, it remembers that the *next* time it must always use the equivalent recovery mode
<Keybuk> a successful boot overrides that
<apw> the problem is storing that needs
<rtg> apw: are you dropping EXTRA_CFLAGS from Karmic ubuntu/compcache/Makefile ?
<apw> i hadn't looked at them, that does seem odd
<apw> want me to do that
<rtg> apw: I forgot to look at the package from the buildd, but did compcache actually get compiled?
<apw> no cause i missed half the fix when committing somehow
<apw> its in there as of 1 minute ago and is build tested
<rtg> apw: ok, as long as you're mucking around in it, why don't you also fix EXTRA_CFLAGS
<apw> yep will do, and i'll shove it into my PPA to build test
* smb changed the topic of #ubuntu-kernel to: Karmic Kernel Plan: 2.6.31 -- Kernel Team Bug Day https://wiki.ubuntu.com/KernelTeam/BugDay/20090707
<rtg> apw: doh! CONFIG_TLSF. what a dunce I am. 
<apw> how stupid do i feel having seen it, then not noticed it was missing from the commit
<rtg> apw: I'll bet I spent an hour messing with that Kconfig
<apw> its in the one above ... which is confusing
<amitk> the power of 20-20 hindsight
<Keybuk> apw: it looks to me like *everything* exploded
<Keybuk> I'm going through that "out of warranty" vs. "not fit for purpose" battle :)
<apw> Keybuk, heh ... been connecting mains to the wrong end again?
<apw> always loads of fun indeed
<Keybuk> of course, I've already found and bid on a replacement unit on ebay
<Keybuk> but I like arguing with companies
<apw> waht was it before it exploded, it looks very industrial
<Keybuk> apw: Creative/Cambridge SoundWorks S750
<Keybuk> THX 7.1 amp
<apw> wow ... you must like your sound
<Keybuk> this is the baby for the office
<Keybuk> I have a real amp connected to the tv/blu-ray downstairs :)
<Keybuk> my neighbours ... do not like my sound
<apw> heh uk houses are not well designed for anything over a pin drop often
<apw> Keybuk, you tested that devramfs thing and it worked iirc, is that coming downstream?
<Keybuk> apw: it worked well enough that we found udev bugs as a result ;)
<Keybuk> ie. devtmpfs is better than udev
<Keybuk> it's in gregkh's tree at the moment
<apw> heheh
<Keybuk> I may ask you to pull it early if it doesn't look like it'll hit .31 but definitely .32
<Keybuk> it's self-contained enough that it shouldn't be a problem
<apw> yeah its pretty self conftained, though i guess it'd be in .31 if it was going to be
<apw> its not exactly a bug fix :)
<Keybuk> I'm never sure how the merge window works
<apw> in theory once the window closes (when -rc1 ships) no new functionality should be commited
<Keybuk> right, which means it's already not in .31 right?
<Keybuk> I never quite understand how things work wrt mm
<Keybuk> if a patch is "added to the mm tree", how does that then end up in Linus' tree?
<amitk> Keybuk: *maybe*, if it is baked for enough time and gets ACKs from some key developers.
<apw> yeah on the flip side it _was_ in linux-next
<apw> and that means it was meant tomake .31... so hard to tell
<amitk> there have been instances of stuff being dropped from -mm after a while
<apw> can tell cause steven is bitching that its still there
<apw> and -next should in theory go to 0
<Keybuk> apw: steven ?
<Keybuk> I assume that "its still there" => devtmpfs?
<apw> rothwell who runs linux-next, yep devtmpfs is still in the meant for the release pile
<apw> yet not merged
 * Keybuk wonders how Jan and Val are getting on
<apw> last conversation i saw, there was a serious locking issue which needs a rearchitect to fix.  so i am not expecting it to be ready any time soon frankly
<apw> we need to start thinking about a fallback position
<apw> i am guessing we still have aufs support out there in our tools
<Keybuk> we have the unionfs fuse implementation
<Keybuk> that seems to vaguely work
<apw> i thought performance was poor
<Keybuk> sure
<Keybuk> poor performance > nothing
<Keybuk> especially if we know we have something better still down the line
<Keybuk> one day I'll meet the guy who came up with /var/run/utmp and /var/log/wtmp
<Keybuk> and if I'm lucky, I will have a chainsaw
<ogra> you think he is a lumberjack and need some device to start a conversation ? 
<apw> Keybuk, was it you who has the machine that had particularly sucky performance under very high IO load?
<Keybuk> yes
<apw> if so you might want to test the 31-2.16 kernel, as i have it on my machine and it seems much better.  there are some reclaim changes which are supposed to help keep binary pages in core
<apw> which is fingered for the huge 'delays' where apps grey out under compiz
<Keybuk> apw: Kay seems very confident that devtmpfs will be in for .32
<Keybuk> oh, interesting
<Keybuk> is that on the archive now?
<apw> yes, any of those on the archive has the fix (for karmic)
<apw> i am building in the background here and not spitting feathers
<Keybuk> ok installing
<rtg_> Keybuk: is the gateway command in /etc/network/interfaces still valid in Jaunty? Mine seems to have stopped working, yet all of the other static address setup commands are correct.
<Keybuk> rtg_: don't see why not
<rtg_> damn, its the last statement in the file. I've tried several times to get it to set a default route. wonder what gives?
<bjf_afk> >
<bjf_afk> > Ubuntu Kernel Team Meeting Announcement
<bjf_afk> > Today at 17:00 UTC in #ubuntu-meeting
<bjf_afk> >
<cjwatson> Keybuk: grub/recovery mode> that should be feasible with grub2
<cjwatson> Keybuk: there are load_env, list_env, and save_env commands; you give them a preallocated file to scribble in
<Keybuk> sure, but that only works once you've got a file to scribble in ;)
<Keybuk> if you can't mount the root filesystem, how do you scribble?
<cjwatson> right, this only works if grub itself can mount the root filesystem
<cjwatson> but if you can't mount the root filesystem, recovery mode is no use anyway!
<cjwatson> and there are certainly cases where grub can manage to load the kernel but the initramfs fails for some reason
<apw> right, if the file is in the /boot directory we know grub can handle that dir, else it cannot load either itself nor the kernek
<bjf> >
<bjf> > Ubuntu Kernel Team Meeting Announcement
<bjf> > Starting now in #ubuntu-meeting
<bjf> >
<ogra> scary
<ogra> :)
<apw> cjwatson, the majority of the recommendations on that ssd blueprint was to use ext4 which you have already done, the other part was about partition alignment
<cjwatson> yes, partition alignment is fairly non-trivial
<cjwatson> I'm familiar with the issue from a previous mail thread
<cjwatson> mostly it depends on a newer parted that's unlikely to be released in time for karmic
<cjwatson> using fdisk is totally unacceptable
<cjwatson> (in the installer at any rate) - it's very dependent on parted
<cjwatson> I'd like to deal with the alignment thing, certainly, just not sure when we can
<Sarvatt> an ext4 no journal option would probably be a good thing to add to the installer for SSDs
<cjwatson> Sarvatt: is that a mke2fs or mount option?
<cjwatson> and is it supported with the kernel/e2fsprogs combination we have?
<Sarvatt> mkfs.ext4 -O ^has_journal
<Sarvatt> yeah its supported by karmics, not jaunty's though of course
<cjwatson> hmm, there's nothing generic I can hook into, will take a bit of work
<Sarvatt> it was introduced just after e2fstools 1.41.4
<cjwatson> somebody should file a bug on partman-ext3 for it I think
<Sarvatt> http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commit;h=a90f5391dda78f7bc4a8196a78355584ace0adf5
<Sarvatt> its nice that e4defrag works now on .31, just defragged 700k files on a drive i converted from ext3
<cjwatson> apw,cking: unionfs-fuse is I think barely acceptable, but I'd *much* rather have something in-kernel
<cjwatson> it's very much a last resort in my book
<apw> cjwatson, ok ... thanks for the input
<kdub> kernel bug day?
<ogra> apw, unionfs-fuse isnt acceptable for ltsp (where we use union mounted squashfses as well)
<ogra> apw, it puts thin client boots into a 4 - 5 min zone 
<apw> ogra, thanks for that also
<JFo> hi ogasawara sorry it took me so long to get here
<JFo> :)
<ogasawara> JFo: what's up, glad you made it
<JFo> just busier than I thought I would be today
<JFo> glad to be here
<ogasawara> JFo: have you had a chance to browse through the bug day list - https://wiki.ubuntu.com/KernelTeam/BugDay/20090707
<JFo> so I see the bug list and I assume that the name above each group is the assigned engineer for those particular bugs?
<JFo> I have :-D
<ogasawara> JFo: correct, there is a community section towards the bottom for anyone else interested in helping
<JFo> ok
<ogasawara> JFo: we can also go through some simpler types of bugs first though if you like
<JFo> that sounds good
<JFo> I'd like to understand a bit more before I dive in
<ogasawara> JFo: right, gimme a sec to get a list of good starter bugs
<JFo> ok :)
<JFo> interesting, I logged in to Launchpad, but it looks like I am not logged in when I view the kernel bug pages
<JFo> I suspect that may be due to some permission I lack
<JFo> or team that I am not yet a part of
<JFo> hmmm
 * JFo goes digging
<ogasawara> JFo: no, it's because I stole the lp template for the bug page
<JFo> ah hah :-)
<JFo> everything becomes clear
<JFo> this is a listing you have created just for this purpose I assume?
<ogasawara> JFo: correct
<JFo> that explains the missing icons
<JFo> :)
<ogasawara> JFo: ok, lets just start with bug 177026
<ubot3> Malone bug 177026 in linux "palm z22 won't sync" [Undecided,New] https://launchpad.net/bugs/177026
<JFo> ok
<ogasawara> JFo: what happened recently is we transitioned quite a bit of bugs from linux-meta to the linux package
<JFo> I see
<ogasawara> JFo:  You'll see that the bug was reported quite some time ago (2007-12-17)
<JFo> indeed
<JFo> so we need the standard response to check this against Jaunty?
<ogasawara> JFo: yes!
<JFo> or am I skipping ahead?
<JFo> cool
<ogasawara> JFo: so, if you want, go ahead and post a comment asking them to test Jaunty
<JFo> ok
<ogasawara> JFo: I think the bug day page may have a stock reply you can use
<ogasawara> JFo: of course you'll then set the status to Incomplete at the same time
<JFo> right
<JFo> the bug page does have a reply
<JFo> first one I believe
<ogasawara> JFo: that's the one, go ahead and just copy and paste it
<JFo> got it.
<JFo> where do I set as incomplete?
<JFo> Update description/tags?
<ogasawara> JFo: if you click on the current status on the Status column it should expand for you
<JFo> ah
<ogasawara> JFo: in there you can add your comment and update the status all at the same time
<JFo> excellent
<ogasawara> JFo: since you are not a member of ubuntu-bugcontrol yet there are some Status' you will not have the permissions to set
<JFo> done
<JFo> I see, what are those?
<ogasawara> JFo: for ex Won't Fix and Triaged
<JFo> ah, ok
<JFo> that makes sense
<JFo> ready for the next one :)
<ogasawara> JFo: cool, lets just make the next logical progression and handle some Incomplete bugs
<JFo> ok
<ogasawara> JFo: take a look at bug 84898
<ubot3> Malone bug 84898 in linux-source-2.6.20 "After resume, video playback is order of magnitude slower than normal" [Medium,Won't fix] https://launchpad.net/bugs/84898
<JFo> got it
<ogasawara> JFo: I forgot one thing, if we can backtrack just a sec
<JFo> sure
<ogasawara> JFo: when a bug is set to Incomplete it obviously indicates it needs more info
<JFo> right
<ogasawara> JFo: when I set a bug to Incomplete I usually also subscribe to the bug
<JFo> ah, good point
<ogasawara> JFo: that way when they do provide the information, I'll be notified
<JFo> and that bug can be moved forward
<ogasawara> JFo: right.  I usually just tick the checkbox "Email me about changes to this bug report"
<JFo> I see that
<JFo> ok
<ogasawara> JFo: alternatively you can click on the "Subscribe" link on the right hand side of the bug
<JFo> ok
<ogasawara> JFo: ok, no onto the next bug
<JFo> k
<JFo> I see this one is a WontFix
<JFo> for one package 
<JFo> and Incomplete for another
<ogasawara> JFo: right, a while back the kernel package naming convention changed from "linux-source-2.6.xx" to just "linux"
<JFo> so this one may still be WontFix?
<ogasawara> JFo: actually it was Won't Fix against the 2.6.20 kernel (because it's past it's End of Life)
<JFo> I should have seen that
<ogasawara> JFo: it could very well still exist against the current kernel
<JFo> ok, so for the new version of the Kernel we need it tested against the Jaunty release
<JFo> I see
<ogasawara> JFo: right
<JFo> ok
<JFo> so same as before?
#ubuntu-kernel 2009-07-08
<ogasawara> JFo: not really, take a look at comment 19
<JFo> hmmm
<JFo> ok, so we have apport data for Jaunty...
<ogasawara> JFo: yup, so they've provided the requested info
<JFo> excellent
<ogasawara> JFo: the only thing it seems they did not do was test the latest upstream kernel
<JFo> so this one needs to be sent upConfirmed for Jaunty, Test Upstream
<ogasawara> JFo: right
<JFo> excellent
<JFo> sorry, I keep saying that
<ogasawara> JFo: actually just a reminder to test upstream if they could
<JFo> so, standard response from the bug jam page
<ogasawara> JFo: since it was already asked if they could test upstream in comment 19
<JFo> right
<ogasawara> yup
<JFo> ok
<ogasawara> JFo: we can actually remove the "needs-kernel-logs" tag since they ran the apport-collect command
<JFo> ok
<ogasawara> JFo: unfortunately removing the tag is a separate step from posting a comment and updating status
<JFo> ah
<JFo> ok
<ogasawara> JFo: if you look at the bug description you'll see the list of "Tags"
<JFo> I see them
<ogasawara> JFo: click on the little yellow pencil icon at the end of the list
<JFo> and the 'edit' icon :)
<JFo> heh, right
<JFo> just removing needs-kernel-logs, yes?
<ogasawara> JFo: yup
<JFo> ok
<ogasawara> JFo: so one last thing, setting the Importance
<JFo> ok
<ogasawara> JFo: for the most part, bugs usually fall under the Medium Importance
<JFo> I can't change that
<JFo> ok
<ogasawara> JFo: hrm, must be a bugcontrol thing.  I'll change it
<JFo> ok
<JFo> yeah, permission related as the tool tip tells me
<JFo> or hover text or what have you
<JFo> :)
<ogasawara> JFo: once you feel comfortable enough triaging bugs, you'll want to apply for membership to ubuntu-bugcontrol
<JFo> ok
<JFo> sounds good
<ogasawara> JFo: it requires a small application process where you submit 5 bugs you triaged in order to prove you know what you're doing
<ogasawara> JFo: ok, lets move to the next bug
<ogasawara> JFo: bug 307780
<JFo> I'm with you
<ubot3> Malone bug 307780 in linux "Suspend/Hibernate Not Working" [Undecided,Incomplete] https://launchpad.net/bugs/307780
<ogasawara> JFo: this is another Incomplete bug, but you'll see they never responded to the last inquiry for information
<JFo> so we need to ping them again?
<ogasawara> JFo: actually, if they don't respond after 6weeks, I close them
<JFo> ah
<JFo> good call
<JFo> so this one is well over that
<ogasawara> JFo: I post a comment why we're closing it and let them know they are free to reopen the bug at any time
<ogasawara> JFo: https://wiki.ubuntu.com/KernelTeam/BugDay/20090623#Old Incomplete
<ogasawara> JFo: that's a typical stock reply that I'd use for that scenario
<JFo> great 
<ogasawara> JFo: you probably can't set it to Won't Fix, so go ahead and set it to Invalid
<JFo> so technically they don't get closed, they just get set to WontFix?
<JFo> ok
<ogasawara> JFo: Won't Fix, Invalid, and Fix Released are all considered closed states in launchpad
<JFo> ok
<JFo> but able to be reopened
<JFo> I see
<ogasawara> right
<JFo> done
<ogasawara> JFo: I think we're ready to tackle some of the bugs on the bug day list now
<JFo> ok
<ogasawara> JFo: I know we can look at the community sections, but lets steal some from Tim Gardner's list (he's away on vaca)
<JFo> heh
<JFo> I'm ready
<ogasawara> JFo: bug 352484
<ubot3> Malone bug 352484 in linux "Wireless network not working, System lock-ups with Intel 4965 wireless" [Undecided,New] https://launchpad.net/bugs/352484
<ogasawara> JFo: so as you read, the focus of the developer's list of bugs are wifi related bugs
<JFo> I see that
<ogasawara> JFo: for some drivers, like the iwl4965 driver, there are a few extra things they can test
<JFo> k
<JFo> so they have tried backports
<JFo> do we need kernel logging for this too eventually?
<JFo> or is this separate
<ogasawara> JFo: we'll want to ask a bunch of things.  even though they tested linux-backports-modules-intrepid, we need them to test the newer Jaunty release
<JFo> ok
<ogasawara> JFo: if the issue remains in Jaunty, they should also try linux-backports-modules-jaunty
<JFo> right
<ogasawara> JFo: then run apport-collect to get debug files
<ogasawara> JFo: also, I usually like to request they also confirm against the latest upstream compat-wireless stack
<JFo> k
<JFo> makes sense
<JFo> so, standard response from the bug jam page for backports
<ogasawara> JFo: it's sorta a lot to ask the bug reporter, bug if you make it a simple multi-step process it's much easier
<JFo> looks like
<ogasawara> JFo: so we'll likely want to mix and match some of the stock replies
<JFo> I see
<ogasawara> JFo: basically combining the "Test Jaunty" and "Test linux-backports-modules-jaunty" stock replies
<JFo> ok
<ogasawara> JFo: whenever I ask someone to test the latest upstream compat-wireless stack I tag the bug "compat-wireless"
<JFo> right
<ogasawara> JFo: likewise if I ask them to run apport-collect, I tag "needs-kernel-logs"
<JFo> makes sense
<JFo> done.. very straightforward
<JFo> see what you think
<JFo> :)
<JFo> all I did was add the backport stuff before the 'let us know' bit and added an 'Also,'
<ogasawara> JFo: looks great.  one small nit pick is when I paste the apport-collect command, I usually insert the actual bug #
<JFo> ah
<JFo> I didn't see that
<JFo> <- slack
<JFo> enabling them to copy/paste the command
<ogasawara> JFo: no worries.  it's usually not an issue until you run into the bug reporter that copies and pasts verbatim and complains apport-collect crashes
<JFo> I should have seen that
<JFo> heh
<ogasawara> JFo: lemme see if I can find another good example under the Community section before I turn you loose to do a few on your own
<JFo> heh, ok
<ogasawara> lets look at bug 21344
<ubot3> Malone bug 21344 in linux-source-2.6.22 "Hang when loading ipw2100" [Undecided,Won't fix] https://launchpad.net/bugs/21344
<JFo> wow 2005
<ogasawara> JFo: it's an oldie
<ogasawara> JFo: so one thing I want to start preventing is Triaged bugs which stagnate
<JFo> I can certainly understand that
<ogasawara> JFo: as you pointed out, this was reported way back in 2005 and the most recent comment was back in Dec of 08
<JFo> I see that too :-/
<ogasawara> JFo: and that was from the janitor no less, so the last real comment was back in Sep 08
<JFo> yeah
<JFo> do we need a 'Check for Jaunty' here?
<ogasawara> JFo: Triaged to a developer should indicate a bug is up to date ready to be worked on
<JFo> or is there something more
<JFo> ah hah
<JFo> ok
<ogasawara> JFo: yup, so pretty much go through the same motions of asking the test against the latest release
<JFo> but this is ooooold version
<JFo> ok
<JFo> cool
<JFo> kick back to incomplete as well, yes?
<ogasawara> JFo: yup
<JFo> cool
<ogasawara> JFo: so you'll notice a lot of triaging can be pretty redundant sometimes
<JFo> yeah
<JFo> but very necessary
<ogasawara> JFo: there are some shortcuts, to make that easier :)
<JFo> nice :)
<ogasawara> JFo: first I'd point you to the launchpad greasemonkey scripts (noted in the bug day page)
<JFo> scripts or built in LP tools?
<JFo> ok
<ogasawara> JFo: both
<JFo> :)
<ogasawara> JFo: I'd direct you specifically to the stockreplies gm-script as well as the karma suffix
<JFo> ok
 * JFo needs to unpack his Jaunty Lappy
<ogasawara> the stockreplies will allow you to save canned responses, like test jaunty, test linux-backports-modules, and inject them automatically with a single click
<JFo> oooh
<JFo> I likey
<ogasawara> the stockreplies gm-script is also capable of also setting the status and importance
<JFo> very nice
<ogasawara> JFo: I'm even lazier though and will often revert to using launchpadlib to knock out a whole list of bugs
<JFo> hahahaha
<JFo> I like that even more :)
<ogasawara> JFo: but I'll save the launchpadlib stuff for a later date
<JFo> ok
<JFo> this is good ofr now
<ogasawara> JFo: best to make you triage old school first
<JFo> I need to understand first
<JFo> yes :)
<JFo> how often do you generate the list of bugs for the devs?
<ogasawara> JFo: I generate them every 2 weeks
<JFo> for instance, if I wanted to look over some of these this weekend...
<JFo> ok good :)
<ogasawara> JFo: but I'd be happy to generate some custom lists for you if you like
<JFo> well, if it isn't too much trouble
<JFo> I'd like to have a good list to tackle if you think I am up to it
<ogasawara> JFo: definitely.  let me put together a few groups of bugs for you to work on.  I'll email you it tomorrow.
<JFo> wonderful
<JFo> I look forward to it
<ogasawara> JFo: hope this quick triage session helped
<JFo> immensely
<ogasawara> JFo: obviously feel free to ping/email me with any additional questions
<JFo> I'm glad to see that I will be able to help quicker than I thought
<JFo> ok, will do
<JFo> well, thank you for that excellent training ogasawara 
<JFo> I'll hold off for today on the bugs until I see the list tomorrow
<ogasawara> JFo: sounds good.  thanks for helping out
<JFo> maybe I can help tackle some of the backlog
<JFo> no problem at all :)
<ogasawara> JFo: indeed, that would be great
<\sh> how can we get rid of klibcs ipconfig inside the initramfs really fast...it's a nightmare in enterprise environments using PXE/NFS rootfs mounts
<bullgard4> What does 'mmc' stand for in /usr/src/linux-source-2.6.28/drivers/mmc/core/sd.c?
<ogra> multimedia card
<smb> bullgard4, multi media controller? 
<ogra> (SD cards)
<smb> as far as I know its those controllers supporting multiple card types
<ogra> yeah, or rather contrller :)
<ogra> (damned i'm constantly using o's since a few days ... and cant find where they go)
<smb> ogra, o's?
<smb> overdose on style guide consumption?
<bullgard4> ogra, smb Thank you for explaining.
<Ng> is rfkill likely to be somewhat broken in 2.6.31 atm?
<smb> Ng, Assuming on the fact there has been a rewrite: maybe
<Ng> it's just that i noticed that in 2.6.30 the gnome bluetooth thing showed two killswitch tickboxes for my thinkpad's internal bluetooth adapter which correctly disabled it, but they don't in 2.6.31
<apw> there is a likelyhood of rfkill horkage yes
<apw> thought you should report it
<Ng> ok
 * apw notes that his machine is much happier under build loads with the latest karmic kernels
<james_w> apw: I'd agree about the latest kernels and performance under I/O load
<apw> its been a revelation, i can no build a kernel in the background wihtout need for ionice
<james_w> I've got two parallel builds going, with the UI much more responsive than before
<james_w> shame my disk is still really slow, but it's definitely an improvement
<apw> i've not seen a single compix fade out since i've been running 31-* kernels, was normal before with heavy load
<james_w> I thought I was seeing a little improvement with .31, but the -2.16 seems to be a lot better again
<apw> smb, whatever happened to your mmc patch?
<smb> Pierre thinks there might be a better solution and wanted to investigate that
<apw> any sign of the better soln?
<smb> But I have not heard of something better
<smb> No
<apw> maybe worth a poke as we are carrying your patch
<smb> You certainly can change the block layer to carry additional references
<smb> I did poke (not sure how long ago) to get the answer above
<apw> ok good enough then
<apw> the worry is if its a differnt soln. we may get it without a collission with yours and carry both
<smb> apw, Found it, the answer is from first of Jul
<apw> so pretty recent then
<smb> right. His answer was "I plan to have a closer look at this first. I believe your solution is
<smb> a workaround and doesn't solve the real issue. As such, I want to have
<smb> one more go at finding and fixing the real problem before committing
<smb> this. Your analysis should help a lot in that effort.
<smb> "
<apw> cking_, i am pushing your first bisect kernel now, should be about 15 mins
<cking_> cheers!
<apw> cking_, http://people.ubuntu.com/~apw/cpu-bisect/
<cking_> apw.. nearly tested
<apw> nearly?
<cking_> yeah.. double checking to be sure
<apw> positive or negative?
<cking_> I will let ya know in a jiffy
<cking_> first time the hibernate screwed up
<cking_> hrm and 2nd time around hibernate gets loads of I/O errors...
<apw> bah so hibernate may not work at all
<cking_> looks hosed to me
<apw> will make a bisect tricky
<cking_> let ,me do one more test
<apw> is it an amd?
<cking_> Nope, Intel 
 * cking_ wastes time fsck'ing disc after screwed up hibernate :-(
<cking_> this is annoying. some times it works, some times it does not.
<cking_> makes testing more time consuming.
 * smb can't stand the tension any longer and leaves for a happy place...
<cking_> have a nice beer time smb
<smb> cking_, ta :)
<apw> cking, any luck?
<apw> cking, what is a sonoma processor?  we have an old patch for them in your name
 * cking tries to recollect
<cking> what's the commit id?
<cking> some kind of pentium M I believe
<cking> 2nd gen Centrino
<cking> apw, http://en.wikipedia.org/wiki/Centrino#Sonoma_platform_.282005.29
<apw> odd we are carrying a patch for it
<cking> why odd?
<mjg59> Is this for cpufreq-centrino?
<cking> cpufreq/speedstep-centrino.c
<mjg59> Yeah
<mjg59> The issue there was that the different Sonoma models need different frequency/voltage tables
<mjg59> So you have to get the information from ACPI, but some machines were missing it
<mjg59> You could patch it to add one table, but there was no way to know which you should use
<cking> The freq/voltage tables can be selected from from the cpu id info, and max cpu setting.
<cking> it's not pleasant, put it that way.
<cking> s/max cpu/max freq/
 * cking suspect apw is working his way through a gazillion patches
<apw> cking, its odd cause we are still carrying it so long after
<apw> and yeah a lot of reading
<cking> hrmph. phase of the moon bug this one.
<cking> 2.26.27*18  FAIL, OK, OK
<cking> 2.6.27*10 OK, OK
<cking> 2.6.27*14, FAIL, OK, OK
<cking> 2.6.27*12, OK, OK
<cking> apw, ^^ it's not easy to reproduce 100% of the time.
<cking> gonna take a break, neck is killing me.
<apw> cking, hrmmm ... bottom
<cking> Gonna revist this again later when it's cooler and my neck  is under some pain killers
<apw> cking, it'll wait
<JFo> hi ogasawara 
<ogasawara> JFo: hiya, just getting your list of bugs I promised put together
<JFo> excellent :)
#ubuntu-kernel 2009-07-09
<JFo> ogasawara, you are way too good to me :-)
<JFo> I'll work on these a bit and hit you up with any questions as needed via e-mail
<JFo> thanks
<ogasawara> JFo: sounds good, thanks
<ogasawara> JFo: I'm hoping you'll get some responses from those bugs so then we can work on triaging those with responses
<JFo> ok, got some from the ones yesterday
<JFo> do we need to do more to them?
<ogasawara> JFo: cool, can you email me back the list of ones that got feedback?
<JFo> sure
<ogasawara> JFo: I'll take a look and see if we need to do anything else
<JFo> ok
<ogasawara> JFo: I'm gonna step away for a little bit but I'll check email later this evening
<JFo> ok, thanks again :)
<roey_> //hello/
<roey_> question...
<roey_> I'm trying to install a proproietary ATI driver and I get issues with dpkg not being able to find kernel sources (even though I've apt-got installed linux-source-2.6.8)
<roey_> what gives?
<roey_> hi NCommander 
<NCommander> hey roey_ 
<roey_> HI
<roey_> question
<roey_> first off, anyone here?
<roey_> NCommander: I'm getting problems with a package I'm trying to build; the make system keeps complaining that it cannot find the kernel sources under /lib/modules/(kernel version)/build or (kernel version)/source
<roey_> NCommander: for the life of me I cannot figure this one out
<roey_> bbiab.
<roey_> 
<sn9> i'm curious as to how it is that bug 374122 gets an sru, but bug 341735 doesn't; randomness of the universe?
<ubot3> Malone bug 374122 in linux "add two hercules webcam models to gspca devlist" [Medium,Fix committed] https://launchpad.net/bugs/374122
<ubot3> Malone bug 341735 in linux "jaunty webcam not working: 3Com HomeConnect" [Undecided,Confirmed] https://launchpad.net/bugs/341735
<chrisATberlinINg> sorry for spamming you, but i want to know: is there any reason why maineline kernels in the mainline kernels archive are only build for amd64 and not for i386 like it is described on the website? see: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc2/
<sn9> that's less spammy than what i typed
<sn9> nobody responded
<hoban> hello. can someone please direct me to some documentation on how to configure kdump for ubuntu to capture a kernel dump on panic?
<Sarvatt> chrisATberlinINg: because they fail to build on i386, pretty sure the fix is upstream now so it should pick back up at 2.6.31-rc3
<chrisATberlinINg> ok thank you Sarvatt
<Sarvatt> there was a problem compiling the i915 module on older gcc's that the machine that builds those uses for a bit there making it fail
<sn9> Sarvatt: and what i said?
<Sarvatt> ?
<sn9> [Thu 09 Jul 2009 08:42:49 AM PDT] <sn9> i'm curious as to how it is that bug 374122 gets an sru, but bug 341735 doesn't; randomness of the universe?
<ubot3> Malone bug 374122 in linux "add two hercules webcam models to gspca devlist" [Medium,Fix committed] https://launchpad.net/bugs/374122
<ubot3> Malone bug 341735 in linux "jaunty webcam not working: 3Com HomeConnect" [Undecided,Confirmed] https://launchpad.net/bugs/341735
<Sarvatt> i have no idea, chrisATberlinINg just asked a question I knew the answer to so I answered..
<sn9> :(
<hoban> hello all. I've got a reproducible kernel panic that I'd like to report. I'm looking for the best way of providing useful output. I got some output by appending "no_console_suspend" to the kernel like of grub and triggering the panic, but I don't think it's complete. I can show it to anyone who is interested though
<sn9> if it's reproducible on a machine with a serial port, i'd send the console there
<hoban> http://imagebin.ca/view/mldpclrA.html
<hoban> sn9: there is no serial port
<hoban> (nor do I have access to a machine with a serial port and bluetooth)
<sn9> there is no backtrace for some reason
<hoban> what other option do I have?
<hoban> kdump?
<sn9> netconsole is also possible; i never saw kdump, but it sounds better'
<sn9> but none will help if the panic dump has no backtrace
<hoban> right
<hoban> ok, I'll give netconsole a try. thank you!
<Kano> hi, where is the last 2.6.30 u package?
<Kano> ar9170.fw still missing
<Kano> http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/LICENSE
<Kano> http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/ar9170.fw
#ubuntu-kernel 2009-07-10
<dtchen> Kano: ar9170usb isn't enabled in the Ubuntu builds AFAIR; i've been using compat-wireless with the firmware from linux-firmware.git.
<Kano> you are lying
<dtchen> is it enabled now for karmic?
<Kano> http://packages.ubuntu.com/search?searchon=contents&keywords=ar9170usb.ko&mode=exactfilename&suite=karmic&arch=any
<Kano> they are of course in the image
<dtchen> ah, good
<dtchen> apw: would you sync the ar9170usb config (=m) in the c-o-d builds, too?
<Kano> where are the 2.6.30 source packages
<dtchen> canonically? they're gone; karmic is using 2.6.31-git. you'll have to use launchpadlibrarian for older source packages (e.g., https://edge.launchpad.net/ubuntu/+source/linux/2.6.30-10.12).
<Kano> you dont used a orig file?
<dtchen> it doesn't appear so
<Kano> no errors about dm with 2.6.31 in launchpad?
<Kano> that's definitely broken
<dtchen> i can't speak for karmic's source package at the moment; i'm using a c-o-d build (2009-07-09)
<Kano> c-o-d?
<dtchen> "crack of the day" builds: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/
<Kano> i see
<Kano> wenn i can not use those, i do not use ubuntu as base. i always have to apply some patches before building
<dtchen> are you patching pristine upstream? those are upstream kernel.org sources.
<Kano> no some config settings
<Kano> i enable the wireless legacy code and some other things on the fly, also i correct known bugs
<Kano> somehow u likes to have some bugs, prefer to fix em
<dtchen> :-)
<Kano> like my kernel has working dm, comedi s626 only loading for one special device not generic, and some other changes
<Kano> http://kanotix.com/files/excalibur/linux-2.6.31-generic/source/
<Kano> i even have got aufs2
<Kano> also i use lzma compression
<Kano> for vmlinuz
<sn9> which lzma patch did you choose? there are several
<Kano> no patch
<Kano> thats one config setting
<Kano> CONFIG_KERNEL_LZMA=y
<Kano> i compress kernel + initrd with lzma, u uses lzma compression for initrd only in live mode it seems
<Kano> but they still did not compress the kernel image with lzma
<apw> smb it is possible that it can be allowed to be interrupted
<apw> as the semantic is likely 'when complete all cpus must have flushed the tlb'
<smb> Hm, ok. Cause in that one case it looked like
<smb> from the printk's I saw the printk before calling the function (after changing the attrs) and the BUG trace is from some acpi code
<smb> but I have two more printk's in global_flush_tlb
<apw> there is no guarentee they have not been 'printed' and not yet flushed out
<apw> which acpi code is blammoing
<smb> wouldn't it with the BUG statement? Something generic called from thread helper: autoremove.wake.function->...>acpi.os.execute.deferred
<apw> depends on the output device, all printk does is queue it for printing in the dmesg buffer and then wake up the drivers
<apw> some drivers are more immediate than others
<apw> serial for instance definatly is not
<apw> smb what is the specific panic, do you have a picture?
<smb> Hm, currently using vga with smal font
<smb> apw, yes
<apw> there must be more information in there, can you get the picture up somewhere
<smb> null pointer dereference
<apw> hrm
<apw> if the remapping was gone correctly then it would not make any difference if the flush has occured or not
<smb> http://www.krikkit.de/aa1debug/07100001.JPG
<smb> http://www.krikkit.de/aa1debug/07100003.JPG is a bit better
<smb> https://pastebin.canonical.com/19558/
<apw> that is bugging twice
<smb> That would be the code snippled called
<apw> the stack is not from the original bug by the looks
<apw> and the first one is between your two debug statements
<smb> apw, Oh it is only one. Just two pictures of it
<apw> need to find our where that first EIP is on line 4
<smb> But the rest yeah
<apw> smb, no in the second picture there are two panics
<apw> one on lines 4-6
<apw> and one on 7-
<apw> the stack is as likely to be from the second one
<smb> Oh, right. The Null pointer and then Oops: 0003
<apw> need to translate c0105550 on your kernel
<smb> Just a second. Booting the build machine
<smb> Hm, c0105550 -> device_not_available
<smb> apw, Oh actually I just noticed the between printing the eip of the first oops and the BUG, the flush_map(...) is from within global_flush_tlb
<smb> One of the debug statements I added
<apw> yeah saw that
<smb> Hrm, missed it on the camera and on the screen :/
<apw> are interrupts turned off during the conversion to r/o?
<apw> do you know if the other cpu threads are awake when that code runs?
<smb> a) I don't think so, just spinlocks while taking lists out afaik. b) not sure but checking
<apw> smb, ok the first panic is very odd as its panicing on the stack push
<smb> b) it is after bringing up the hyperthreads
<smb> apw, dumb question, how do I see this?
<apw> so its possible the other thread is losing its stack or similar
<apw> ENTRY(device_not_available)
<apw>         RING0_INT_FRAME
<apw>         pushl $-1                       # mark this as an int
<apw>         CFI_ADJUST_CFA_OFFSET 4
<apw>         pushl $do_device_not_available
<apw>         CFI_ADJUST_CFA_OFFSET 4
<apw>         jmp error_code
<apw>         CFI_ENDPROC
<apw> END(device_not_available)
<apw> it the eip is exactly device_not_available ... then it is pushing a frame
<smb> Ok, yes it is. As the next eip is exactly the entry of call_function_interrupt
<apw> smb, i don't understand
<apw> phone?
<smb> ok
 * apw watches his fan turn on and off correctly on his thinkpad .. amazing
<sahil_> hey all, got a bit of an issue, when i boot with acpi=off everything boots but of course acpi does not work, when i boot with nolapic acpi works but wireless does not, any ideas?
<apw> why are you booting with either of those?
<primes2h> ogasawara_: I have again the laptop I told you some days ago. Tell me if you need something.
<primes2h> ogasawara_: Ehm, Hello, first of all... ;)
<maco> 2.6.31-2: does it include the fix for tun interfaces?
<rgz> Is there a generic problem with the 2.6.28-13 kernel build on i386?
<smb> rgz, It runs for me
<smb> What problem do you have?
<rgz> smb:  It first gives off some error about my resolution bindings, after grub's loaded; says that 307 doesn't exist, I change the splash resolution, it boots up gdm but all I/O devices don't function.
<rgz> I'll get a log as soon as I can, just wondered if anyone else experienced something similar.
<smb> rgz, It does not ring a bell immediately. Hm, 307 might be a resolution but why this affects IO devices. HAve you once tried removing splash?
<rgz> smb:  Yeah, I looked through the logs, might be something to do with nvidia drivers, but I'm not entirely sure.
<rgz> It's a pain; but I'll come back when I have the logs in check.
<smb> rgz, Just to enlighten me. ;-) Did using splash or not make a difference. Ok
<nanomad> Can anyone have a look at #21367 it can be fixed in (at most) 5 minutes
<rgz> smb:  No, no difference.
<smb> rgz, ok thanks
<jdstrand> there is a newer version of firmware for ipw2200 than what's in linux-firmware (bug #357968). license in the tarball is the same. would I be stepping on anyone's toes if I uploaded an updated linux-firmware to karmic?
<ubot3> Malone bug 357968 in linux-firmware "Please update ipw2200 firmware to version 3.1" [Undecided,Triaged] https://launchpad.net/bugs/357968
<smb> jdstrand, I would not believe so. I believe the names were incremental (so old ones stay there), right?
<jdstrand> smb: I don't understand your question. it is a native package, I would adjust the version appropriately
<smb> jdstrand, It is rather about the version of the firmware file. I just believe those get adapted, sod the old firmware files stay
<jdstrand> smb: linux-firmware simply has the untarred files in firmware/ipw2200. I figured I'd put the new ones there instead
<jdstrand> is that not the proper way?
<jdstrand> all the filenames are the same
<jdstrand> the LICENSE is the same
<smb> Oh I see I confused that with other wireless firmaware which has version numbers in the filename and the driver loads just the highest supported
<smb> So here it is just a replacement as it looks
 * jdstrand nods
<smb> There has been a request to upgrade the iwl4965 just today. I wonder whether it will make sense to get that done with one update
<smb> oh.. forgott, jdstrand ^
<jdstrand> smb: I don't know anything about iwl4965. I can say preliminary testing shows the ipw2200 driver works fine on 2.6.28 (haven't tested on karmic)
<smb> apw, Would you feel being stepped on something when the firmware package gets done?
<jdstrand> I'm happy to do an ipw2200 only upload
<jdstrand> otherwise, the details are in the bug for ipw2200
<smb> jdstrand, Ok, for simplicity. Lets do one by one
<jdstrand> alright, consider it done :)
<apw> smb, jdstrand the only thing about firmware is legal issues, i would just touch based with pgraner to make sure he is happy
<jdstrand> apw: the license in the new tarball is the same as in firmware/ipw2200 of linux-firmware
<apw> then that sounds fine to me, i would just let pgraner know you are updating it, as there is a review ongoing
<pgraner> jdstrand: then it good
<jdstrand> thanks guys-- will test on karmic and upload
<pgraner> apw, jdstrand: I have it noted. Thanks for the heads up
<nanomad> jdstrands, Can anyone have a look at #21367 also?
<jdstrand> nanomad: not really my jurisdiction, sorry
<nanomad> jdstrand, np, thanks anyway
<jdstrand> nanomad: and that isn't linux-firmware, bug linux anyway
<nanomad> yes, i noticed that :)
<apw> bug #21367
<ubot3> Malone bug 21367 in linux "Wifi-enabled led is not lit on ipw2200 cards" [Low,Confirmed] https://launchpad.net/bugs/21367
<smb> The question is really why upstream did not change the default. It might be work on many but just not on all. Pragmatically I got a ipw2200 and my led works without...
<apw> nanomad, whats the question with it?
<nanomad> apw, it got disabled in karmic
<apw> it was fixed in Jaunty if I understand things
<nanomad> since it is not fixed upstream
<nanomad> it got lost from jaunty -> karmic
<nanomad> if i manually modprobe ipw2200 with led=1 it works
<smb> Hm, ok. So we had it with the other default in Jaunty
<nanomad> smb, looks like that
<apw> smb can you accept the nom for jaunty for me on that bug
<apw> and i'll sort out the states
 * smb wait for lp
<smb> ok
<nanomad> actually, it would be nice to report it upstream. Or we will have the same bug at the next kernel bump
<apw> smb, ok thats been applied to jaunty since the karmic fork and all the commits there are on my list to review
<smb> apw, We should check to get it upstream this time,...
<smb> nanomad, yep
<smb> Either we will know why not or wo't loose it agian
<apw> smb yep.  will do that as its been on for 3 months
<smb> apw, ok, quickly scanned the ipw2200 bugs and it did not look like there was one of "suddenly broke"
<apw> smb, might be worth rejecting the nom for karmic on that bug as it means nothing
<apw> smb, thanks for that
<smb> apw, Yeah, will reject that. You are not on it nw?
<apw> i've assigned it me and added it to my list to close when karmic has it
<smb> apw, ok, nomination rejected
<apw> smb, thanks
<nanomad> apw, smb, thanks guys.
<jdstrand> apw: I uploaded linux-firmware 1.14 to karmic. I tried to git clone http://kernel.ubuntu.com/git-repos/ubuntu/linux-firmware-karmic.git/ but got:
<jdstrand> fatal: http://kernel.ubuntu.com/git-repos/ubuntu/linux-firmware-karmic.git//info/refs not found: did you run git update-server-info on the server?
<apw> its meant to get run on every commit magically
<jdstrand> apw: I uploaded the new source package to /home/jamie/uploads/karmic on chinstrap
<jdstrand> apw: I looked around for docs on how to update linux-firmware, but nothing popped up
<jdstrand> apw: if you point me at it, I'll do it, otherwise you can get the source package on chinstrap or wait for LP
<apw> ack
<wip> hi people, i've been using jaunty for months, but the RT-kernel is still not updated. it's full of bug. any release date? is someone working on it?
<wip> example, worst bug for me: https://bugs.launchpad.net/ubuntu/+source/linux-rt/+bug/374026
<ubot3> Malone bug 374026 in linux-rt "Kernel threads using 100% on one of the two CPUs" [Undecided,Confirmed] 
<smb> apw, Is there actually a git for linux-firmware...?
<apw> smb dunno, wanna try and find out and sort that for me
 * apw is snowed
<wip> still undecided...
<smb> wip, The rt kernel is community maintained. Don't know the status
<smb> apw, can do
<wip> smb: thanks for the information, it
<wip> smb: but it means that i should recompile my kernel... ouch...
<Q-FUNK> hello
<Q-FUNK> could anyone help me with LP bug #396286 ?
<ubot3> Malone bug 396286 in linux "kernel 2.6.31-generic oops after loading initramfs" [Undecided,New] https://launchpad.net/bugs/396286
<Q-FUNK> apw: I beleive that you were the one who replied to LP bug #241307 earlier.  I think that we managed to narrow down the source of the problem.  is there anythign else I can add?
<ubot3> Malone bug 241307 in linux "kernel oops during bootup in LTSP" [High,In progress] https://launchpad.net/bugs/241307
<apw> Q-FUNK, looks like you have some significant update there
<apw> i need to read what you've said and comment, busy right now, will look next week
<Q-FUNK> apw: at least, it looks like wwx and leio/mraudsepp (freenode) have done a good job of narrowing down the cause.
<Q-FUNK> apw: wwx pointed out that with early releases of kernel 2.6.23, it was still possible to revert the change with an easy patch, but not anymore.
<Q-FUNK> alright.  I'll wait for your followup, then. :)
<apw> yeah probabally futzed by the merge of 32 and 64 bit x86
<apw> on my list for next week
<Q-FUNK> is that what the code that replaced the old ia32 init code in ASM does?  attempt to combine init code for x32 and x64 into one?
<apw> no i mean that is what likely futses reverting the patch
<apw> the previous bug you mention sounds liek a very early panic, normally we take piccies of those with a digitcal camera and attach those to the bug
<Q-FUNK> I'd gladly take a pic (as I previously did for the 2.6.24 kernel bug), but not much core dump fits on the default 24-line VGA screen.
<Q-FUNK> yes, it indeed feels like an early kernel panic.  I'm just not sure what causes it
<apw> if you add vga=ask to the kernel command line it lets you pick a smaller font
<Q-FUNK> yup.  but the max still is 80x60.  we cannot quite fit the whole kernel dump
<Q-FUNK> anyhow.  attached.  hope it helps.
<vitovt> Hi everybody! I need more recent kernel like 2.6.29. I installed it from http://kernel.ubuntu.com/~kernel-ppa/. But there is no restricted extras. Where I could get config of existing kernel (like 2.6.28) including RESTRICTED EXTRAS. How could I buld new kernel very similar to default ?
<maco> vitovt, um, restricted extras packags just have like...flash and java and mp3
<vitovt> ow. sorry. i mean restricted-modules
<vitovt> it's too late in my country and I sleeppy now :)
<vitovt> 2
<vitovt> 3
<vitovt> 4
<vitovt> 5
<vitovt> 6
<vitovt> 7
<vitovt> 	
<vitovt> I have a big problem with 2.6.28 kernel in mainline. 
<vitovt> When i'm out of RAM - swap usage allmost impossible.
<vitovt> There are a lot of errors in syslog (Error allocating memory).
<vitovt> I used kernel 2.6.29  from (http://kernel.ubuntu.com/~kernel-ppa/). It works great. But miss some important modules for me. 
<vitovt> Also I need to make some modification (framebuffers support)
<vitovt> How I can build restricted extras for 2.6.29 and make configuration allmost similar to 2.6.28-generic ?
<vitovt> Sorry for possible flood
<dtchen> vitovt: clone the git tree; see kernel.ubuntu.com/git/
<dtchen> vitovt: see the knowledgebase on the kernel wiki for pointers to build it against the appropriate kernel headers
#ubuntu-kernel 2009-07-11
<xMrKrnlx> Does anyone know if karmic will use the noveau driver, and if it will have KMS support?
<jjohansen> xMrKrnlx: noveau will be supported, and I believe even be the default driver for nvidia
<xMrKrnlx> jjohansen: cool, do you think KMS will be supported on all possible cards - like Fedora 11?
<jjohansen> xMrKrnlx: as for KMS, I know there is working on that but I don't know what it state is, or whether it will make karmic
<xMrKrnlx> jjohansen: thanks!
<sn9> nouveau did not work for me when i tried it a couple of months ago; maybe i should try it again
<xMrKrnlx> sn9: i heard its still in pretty hefty development - i'll probably wait for karmic and see how it works then
<Sarvatt> if you want to play with nouveau KMS on karmic -- https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
<Sarvatt> dont need the kernel there, just nouveau-kernel-source and xserver-xorg-video-nouveau
<Sarvatt> well and the libdrm
<bullgard4> [Jaunty] I have got a loadable kernel module 'snd'. Is the associated source code file /usr/src/linux-source-2.6.28/sound/oss/msnd.c?
<bullgard4> Its object code file is /lib/module/2.6.28-13-generic/kernel/sound/core/snd.ko
<sn9> no
<sn9> sound/core/ comes from sound/core/, not sound/oss/
<daidoji> is this ubuntu specific or can you help with linux kernel questions?
<Keybuk> I know it's the weekend, but anyone around today?
<Laney> Hey, is there any reason why I can't modprobe dm_snapshot on karmic?
<Keybuk> Laney: it's probably built in
<Laney> could be, that would be a change though
 * Laney checks
<Keybuk> CONFIG_DM_SNAPSHOT=y
<Keybuk> looks like it was built-in on jaunty too
<Laney> actually, it might have been that long since I did mk-sbuild-lv
<Keybuk> there's a proposed fix upstream to record the built-in modules so that modprobe will exit 0
<Laney> sounds reasonable
<Keybuk> I'm pretty sure I've found a regression in inotify() in karmic
<mjg59> Keybuk: It's been effectively rewritten, so that's not entirely surprising
<Keybuk> mjg59: indeed
<Keybuk> just bisecting at the moment to make sure it is fanotify
<Keybuk> the regression being that it's just not returning all deletes ;)
<Keybuk> mjg59: are you running 31-rc ? if so, could you try my test case as well to check it's not just the ubuntu tree
<mjg59> Not right now - there's a suspend regression I need to track down first
<Keybuk> np
<Keybuk> http://people.ubuntu.com/~scott/inotify_test.c if you do get a chance, if not, no worries
<Keybuk> it should just exit if everything's ok - I see it get stuck expecting events that never come
<billybigrigger> hey all
<billybigrigger> im trying to compile a daily kernel, and im getting this error when i run sudo fakeroot make-kpkg --initrd --append-to-versio=-dz1 kernel_image kernel_headers
<billybigrigger> http://paste.ubuntu.com/215764/
<billybigrigger> this is my first time trying to compile my own kernel, what am i doing wrong?
<billybigrigger> i have downloaded and installed the headers and source from the kernel mainline daily 7-11
<Sarvatt> i think it needs a config change to build right now billybigrigger, theres no debs
<billybigrigger> never mind, just need a patch :P
<billybigrigger> http://patchwork.kernel.org/patch/35137/
<billybigrigger> building myself
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=373c0a7ed3ea3b34efedb7c83ffb521adff7c894
<Sarvatt> start from linus's source, git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
<billybigrigger> whoa, now im heading into really unknown waters haha
<Sarvatt> i use CONCURRENCY_LEVEL=3 INSTALL_MOD_STRIP=1 fakeroot make-kpkg --initrd -append-to-version=-sarvatt kernel_image kernel_headers kernel_source >buildlog.txt 2>&1
<billybigrigger> should i let this one keep going?
<billybigrigger> it seems to be working fine for now
<Sarvatt> its already fixed upstream, might as well grab the latest source 
<billybigrigger> so source from mainline is no good?
<Sarvatt> you need to make-kpkg clean between errors unless you're using kernel-package 12.x btw
<billybigrigger> oh
<billybigrigger> i didn't do that between errors
<billybigrigger> but it's gotten past the error
<billybigrigger> after i patched mmcontrol.c
<billybigrigger> Sarvatt, are you using daily kernel?
<Sarvatt> nope i build my own
<billybigrigger> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
<billybigrigger> from that ^^
<billybigrigger> ?
<Sarvatt> yeah
<billybigrigger> hmm
<billybigrigger> and still no working cam eh?
<Sarvatt> then cp /boot/config.whatever .config while in the linux-2.6 directory
<Sarvatt> i havent built one since just before rc2
<billybigrigger> k i stopped that other kernel compile
<billybigrigger> from /usr/src i run that git clone line?
<Sarvatt> clone it, copy your config to .config then make oldconfig, then make-kpkg clean, then CONCURRENCY_LEVEL=3 fakeroot make-kpkg --initrd -append-to-version=-dz1 kernel_image kernel_headers kernel_source
<Sarvatt> nah do it somewhere in your home directory
<billybigrigger> haha, i was just about to type all that out
<billybigrigger> high five Sarvatt
<billybigrigger> my first kernel compilation!!! :)
<Sarvatt> if you get an error, make menuconfig and disable whatever you need to then make-kpkg clean and try again
<billybigrigger> k
<Sarvatt> probably want to change CONCURRENCY_LEVEL though
<billybigrigger> and i should copy my config from 31-2 to my ~ ? or ~/linux-2.6/.git?
<billybigrigger> it will read config from .git right?
<Sarvatt> cd linux-2.6 && cp /boot/config-2.6.31-2-generic .config
<billybigrigger> im glad kernel.org is fast :P  1998 KiB/s
<Sarvatt> cd linux-2.6 && cp /boot/config-2.6.31-2-generic .config && make oldconfig && make-kpkg clean && CONCURRENCY_LEVEL=3 fakeroot make-kpkg --initrd -append-to-version=-dz1 kernel_image kernel_headers kernel_source
<Sarvatt> would work
<billybigrigger> 2373 KiB/s
<billybigrigger> :)
<Sarvatt> just take the defaults if theres new stuff during the make oldconfig
<billybigrigger> hmm...git only utilizes 1 core eh?
<billybigrigger> :(
<billybigrigger> Sarvatt, option m for defaults right?
<Sarvatt> just hit enter
<billybigrigger> OSD object-as-blkdev support (BLK_DEV_OSD) [N/m/?] (NEW)
<billybigrigger> oh ok
<Sarvatt> default is N in that one
<billybigrigger> ya, so isn't that NEW?
<Sarvatt> the one in caps, just hitting enter picks the first thing
<billybigrigger> CONCURRENCY_LEVEL=3 fakeroot make-kpkg --initrd -append-to-version=-billybigrigger kernel_image kernel_headers kernel_source
<billybigrigger> we're off and running :P
<billybigrigger> now any app crashes i won't be able to report to LP will i?
<billybigrigger> ahh nice to see both cores maxed :)
 * billybigrigger goes to brew a cup of tea
<Sarvatt> just make-kpkg clean afterwards and later you can just git pull from the linux-2.6 directory and do it over again to update it
<billybigrigger> git pull instead of using git clone?
<billybigrigger> then it just grabs anything thats changed?
<Sarvatt> yep it'll just grab the new changes
<billybigrigger> nice
<billybigrigger> how long does it take you to compile Sarvatt ?
<Sarvatt> hmm, ubuntu stock configuration is like a little more than an hour that way
<billybigrigger> what kinda cpu?
<Sarvatt> i do it on a remote server, AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
<billybigrigger> oooh
<billybigrigger> x2 7750 here, oc'd to 3.0ghz
<billybigrigger> i shouldn't see much of a difference then
<Sarvatt> yeah you should, thats a good deal faster
<billybigrigger> whats the clock speed of your 4200?
<Sarvatt> this thing is 2.2ghz plus its virtualized and shared with other people
<billybigrigger> ahhh
<billybigrigger> i had a 5000+ that was 2.4 i think
<billybigrigger> you have heat issues with that cpu at all?
<billybigrigger> i have mine still
<Sarvatt> its a VPS i use as a web server, i dont have any kind of access to the machine where i could know that :D
<billybigrigger> bought this kuma instead, although that brisbane chip oc'd like a bastard, i think i had it from 2.4ghz to 3.1ghz stable, with decent temps
<billybigrigger> haha
<Sarvatt> i'm about to buy a 7850 for my htpc, just picking out a mobo right now
<billybigrigger> i have an am2 5000+ if you want with 2gb ddr2 800
<billybigrigger> spare
<billybigrigger> interested? :)
<billybigrigger> i actually need a cheap mobo&case and i'd i have another box altogether
<Sarvatt> darn, you're making me want to compile a new kernel but its been 7 days since rc2 and i'm sure he'll release rc3 hours after i do it like last time :D
<billybigrigger> haha
<billybigrigger> usually about a week between rc's eh?
<billybigrigger> buidling package now
<billybigrigger> Sarvatt, you have a timestamp on when i said i started?
<billybigrigger> <billybigrigger> CONCURRENCY_LEVEL=3 fakeroot make-kpkg --initrd -append-to-version=-billybigrigger kernel_image kernel_headers kernel_source
<billybigrigger> <billybigrigger> we're off and running :P
<billybigrigger> i think something stalled
<billybigrigger> /home/billybigrigger/linux-2.6/debian/linux-source-2.6.31-rc2-billybigrigger/usr/share/doc/linux-source-2.6.31-rc2-billybigrigger/Buildinfo
<billybigrigger> tar cf - $(echo * | sed -e 's/ debian//g' -e 's/\.deb//g' ) |         \
<billybigrigger> 	(cd /home/billybigrigger/linux-2.6/debian/linux-source-2.6.31-rc2-billybigrigger/usr/src/linux-source-2.6.31-rc2-billybigrigger; umask 000; tar xspf -)
<billybigrigger> oops, thought that was 1 line
<billybigrigger> or is it just tar'ing the image?
#ubuntu-kernel 2009-07-12
<billybigrigger> can someone take a look at this error?
<billybigrigger> http://pastebin.ca/1492112
<Sarvatt> its a problem with kernel-package with nvidia-common thats been around for a looong time billybigrigger
<Sarvatt> were there changes to usb in 2.6.31 that need updated userland support or something? been having alot of problems with usb devices after 2.6.30
<billybigrigger> my camera, ipod, and videocamera all work good
<billybigrigger> its just the webcam
<billybigrigger> but that could probably because they're all recognized as mass storage
<Sarvatt> i see usbfs moved over to CONFIG_EMBEDDED, dont know if we use that before
<Sarvatt> my webcam and android phone stopped working
<billybigrigger> Sarvatt, no dice
<Sarvatt> thanks for checking
<billybigrigger> its there
<billybigrigger> but webcam not working
<billybigrigger> billybigrigger@cabo:/proc/bus/usb$ ls
<billybigrigger> billybigrigger@cabo:/proc/bus/usb$
<billybigrigger> empty, but its there
<Sarvatt> oh so usbfs was used in .30 where it was working before?
<Sarvatt> hmm
<billybigrigger> funny thing, i have sound in flash on this kernel :P
<johanbr> my Android phone works fine with 2.6.31
<johanbr> my webcam behaves a bit funny though, but I'm not sure if that's the kernel's fault
<Sarvatt> i get a flood of error messages in dmesg while its plugging in without enabling mass storage on the phone (like when i'm just charging it)
<johanbr> seems to work for me
<johanbr> the webcam is definitely screwed up, though: http://nullinfinity.org/tmp/screenshot6.png
<johanbr> (I am actually not a smurf)
<billybigrigger> johanbr, nvidia user?
<johanbr> yep
<billybigrigger> looks like the nvidia hue -1000 bug
<billybigrigger> :)
<johanbr> oh
<johanbr> do you have a launchpad link?
<billybigrigger> yup lemme dig it up
<Sarvatt> yeah change the saturation under 0 in nvidia-settings then save, then back up to 0 and save
<billybigrigger> Sarvatt, funny thing was, i was affected by it, and my hue was at 0
<billybigrigger> just -1000 in vlc
<Sarvatt> they changed the xv saturation ranges in the driver and our old nvidia-settings doesnt copy with it
<Sarvatt> yeah because it isnt really at 0
<billybigrigger> so it might be on an app to app basis
<johanbr> billybigrigger, you're absolutely right
<johanbr> thanks
<billybigrigger> ooooooh
<Sarvatt> it thinks its at 0 but its really at 4096 from the old ranges
<johanbr> I hadn't noticed that regular video had funny colours too
<billybigrigger> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/395476
<ubot3> Malone bug 395476 in totem "nvidia sets HUE to -1000" [Low,Triaged] 
<Sarvatt> things that use their own saturation settings arent affected but things that use nvidia-settings ones are
<billybigrigger> bugabundo started that one, but im pretty sure it should be against nvidia-glx-180 and not totem
<billybigrigger> Sarvatt, that makes sense
<billybigrigger> Sarvatt, will i be able to file bugs under my custom kernel?
<billybigrigger> or will they have to be done upstream to the package maintainers
<Sarvatt> just file the bug on the ubuntu kernel since its the same
<billybigrigger> ok
<thrice`> I have a question; any reason 2.6.30.1 hasn't shown up in the mainline PPA ?
<billybigrigger> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
<billybigrigger> Sarvatt, that is where i pulled the latest kernel source
<billybigrigger> so when i want to update it...
<billybigrigger> git pull from the same source right?
<thrice`> "git pull"
<billybigrigger> 10-4
<billybigrigger> there is life in here! :P
<billybigrigger> thrice`, and that won't compile just the new stuff
<billybigrigger> it will pull whatever is new, and recompile the whole shebang again right?
<thrice`> yep
<thrice`> compiling is not related to obtaining of the source
<billybigrigger> no, thats separate
<billybigrigger> fatal: Not a git repository (or any of the parent directories): .git
<thrice`> are you inside the dir?
<billybigrigger> no, was one above it
<billybigrigger> ok now i get an error that i didn't tell git what branch i wanted to merge with
<billybigrigger> http://pastebin.ca/1492879
<thrice`> just do "git pull"  on its own
<billybigrigger> oh
<thrice`> ooh, 2.6.31.1 seems to break jfs booting from grub1 :(
<thrice`> that's probably why it's not in the PPA :>
<sn9> thrice`: wrong
<sn9> that has been broken since at least hardy
<sn9> and probably gutsy
<thrice`> huh?
<thrice`> 2.6.29 boots my jfs just fine, as does 2.6.30
<sn9> it is not a kernel issue
<sn9> grub1 is bitrotted
<thrice`> of course :)
<sn9> if grub cannot read the fs, the kernel is never loaded, regardless of version
<thrice`> i'm trying to say that 2.6.30.1 introduced a specific failure
<sn9> it did not; that failure has been there for some time
<reto`> hey... I wanted to ask what I can do about the following problem:
<thrice`> you know which I'm talking about sn9 ?
<sn9> it is why i have an ext3 /boot on this laptop
<reto`> with the new kernel it seems to
<reto`>         support cpufreq for the via cpu... but in a strange
<reto`>         way... before it was always at max speed... now it
<reto`>         looks like it changes speed but I think it's not... I
<reto`>         can't even get it to run at full speed
<reto`>         anymore... compared the performace with the two
<reto`>         kernel versions
<reto`> oops... sry for the line breaks
<thrice`> sn9: I am specifically referring to:  http://bugs.archlinux.org/task/15416
<sn9> reto`: is the same governor used?
<thrice`> git commit 206f0f05bdc291a9358ba59248e2bc44e8b3127d
<reto`> sn9: uh... the old kernel doesn't support cpufreq
<sn9> reto`: which via? c7?
<reto`> sn9: I can try any governor or freq setting with the new kernel
<reto`> sn9: it doesn't change anything
<reto`> sn9: c7-m
<sn9> thrice`: the bug report is wrong; jfs has been unreadable by grub for quite some time
<thrice`> what are you talking about???
<thrice`> I boot jfs from 2.6.29.6 right now
<sn9> thrice`: how big is the fs?
<reto`> sn9: should I report this somewhere or how is the situation with the VIA?
<thrice`> size does not matter
<sn9> reto`: are you using the longhaul driver, or e_powersaver?
<sn9> thrice`: then why has jfs booting consistently failed for me on every machine after feisty?
<thrice`> I don't know.  I promise that it works with 2.6.29.x , and even 2.6.30 :)
<thrice`> the bug I mentioned was a specific change to 2.6.30.1 regarding the creation of an initrd
<reto`> sn9: hmm... I think the longhaul... it's displaying some message about that one though on boot
<sn9> the grub people told me this bug has been there since 2004
<sn9> reto`: check through the /sys tree
<thrice`> ok, i'm not really interrested in arguing :(  My system booted just fine this morning with jfs on /
<sn9> thrice`: the real solution would be for ubuntu to take the bold step of dumping grub1 as a default
<thrice`> or lilo :>
<reto`> sn9: it's using the longhaul... but I think it's displaying an error message on boot about that... just didn't know what it is...
<sn9> reto`: HTH
<sn9> thrice`: lilo would actually work
<reto`> sn9: ok, let me fetch that
<reto`> sn9: the message is: APIC detected. Lonhaul ist currently broken in this configuration.
<sn9> what about e_powersaver?
<reto`> sn9: I would have to try... how can I disable the longhaul?
<sn9> is it a module?
<reto`> sn9: how can I find out?
<sn9> sudo rmmod longhaul
<sn9> if there's no error, try loading e_powersaver
<reto`> module isn't found
<reto`> it's in the kernel then?
<sn9> must be
<reto`> I can load e_powersaver with the old kernel though
<sn9> unless it just didn't load
<sn9> modinfo longhaul e_powersaver
<reto`> it din't find the longhaul but e_
<sn9> does it load?
<reto`> no I get an error
<reto`> longhaul seems to be loaded somehow but not working correctly
<reto`> wonder why it is loaded when it knows "it is broken"
<sn9> bug?
<reto`> looks like longhaul went into the kernel with .31
<sn9> karmic fail
<reto`> can I disable it somehow?
<sn9> not without another kernel build
<sn9> OTOH, there is "noapic"...
<reto`> yeah... hmm... might try that one
<reto`> hmm... no use... it still loads longhaul
<reto`> ah well... at least the machine is not hollering at full speed
<infinity> reto`: echo "blacklist longhaul" > /etc/modprobe.d/die_longhaul_die && update-initramfs -u && reboot
<infinity> reto`: That should stop it from being loaded.
<sn9> infinity: no; it's compiled in, not a module, rendering that useless
<infinity> sn9: Oh.  Didn't notice that.  Seriously, though
<infinity> ?
<infinity> We shoudln't be compiling any of that in. :/
<sn9> as i said:
<sn9> [Sun 12 Jul 2009 11:33:01 AM PDT] <sn9> karmic fail
<reto`> ok... I've checked it out... with e_powersaver the scaling is working... I'm not 100% sure but I think longhaul has been in the kernel even before .31 (.28) but with 31.2 there seems to be a bug where longhaul is loaded even when it is detected to be broken
<reto`> I'm writing a bug report on launchpad for this problem. Any suggestions?
<sn9> just that it should not be a module
<sn9> i mean
<sn9> just that it should not be not a module
<reto`> :) ... ok
<billybigrigger_> Sarvatt, ping
<billybigrigger_> what other optimizations can i make when compiling kernel?
<billybigrigger_> besides not compiling for intel
<billybigrigger_> i seen there was some more v4l2 stuff changed today
<billybigrigger_> thought i'd give it another go
<billybigrigger_> anyone built today's kernel?
<billybigrigger_> i get this error
<billybigrigger_> http://pastebin.ca/1493055
<billybigrigger_> when trying to compile from git
<billybigrigger_> ill just remove wireless modules from menuconfig then :P
<billybigrigger_> thanks guys :P
<billybigrigger_> no need on a desktop anywho
<billybigrigger_> where can i find my make log from my last compile? do i have to specify one for it to be outputted?
<hyperair> make-kpkg blah > log?
<billybigrigger_> CONCURRENCY_LEVEL=3 fakeroot make-kpkg --initrd -append-to-version=-billybigrigger kernel_image kernel_headers kernel_source > make.log
<billybigrigger_> does that look right?
<Sarvatt_> you probably want to call it billybigrigger2 because you already have a billybigrigger and use >whatever.log 2>&1
<Sarvatt_> do it in screen and control+a d the tail -f whatever.log to watch it :)
<billybigrigger_> tailing it now
<billybigrigger_> and have it named billy-07.12
<billybigrigger_> :P
<billybigrigger_> thanks though
 * billybigrigger_ crosses fingers :P some more v4l2 stuff updated today
<billybigrigger_> Sarvatt, you till convinced its udev and usb problems though?
<billybigrigger_> drivers/net/wireless/wl3501_cs.c:384: note: âtmpâ was declared here
<billybigrigger_> make[1]: *** [drivers] Error 2
<billybigrigger_> :( still wireless driver errors, i didn't include any wirelss modules though
#ubuntu-kernel 2010-07-12
<apw> morning
<smb> morning
<cooloney> apw: and smb morning
<smb> cooloney, Heya
 * apw waves
 * amitk waves
 * jk- plays 'find the terminal attached to this  screen session'
<apw> jk-, can't you just reconnect to it with 'disconnect the other one'
<apw> and not care ?
<jk-> i can reconnect to it with -x
<jk-> but yeah, that's a good idea :)
<apw> -d -r looks to be the incantation
<jk-> yup
<amitk> jk-: I name my screen sessions with -S
<jk-> amitk: i ony have one running, so the problem isn't finding the right session
<jk-> just that I've lost the attached terminal :)
<amitk> jk-: aah, in that case apw's suggest is best
<kraut> moin
<apw> moin
<lamont> zinc upgrade in about 25 minutes, fyi
<cking> lamont, ok, looks like extended lunchbreak for some of us then :-)
<lamont> in my fantasy land, it's much less than 2 hrs of downtime
 * cking hopes reality matches fantasy land
<lamont> kernel-ppa has a build going on zinc atm, which may or may not finish before the upgrade kills it.  just fui
<lamont> fyi, even
<apw> config PARPORT_PC
<apw>         tristate "PC-style hardware"
<apw>         depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
<apw>                 (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
<lamont> zinc back to all y'all.
<lamont> cking: enjoy
<cking> ta
<apw> lamont, ta
<gnarl> lamont, thanks
<lag> What's the address to send patches upstream?
<apw> lag the get_maintainers script tells you
<apw> it uses the MAINTAINERS file to work it out
 * lag "find"s get_maintainers script
<lag> apw: get_maintainer.pl :)
<lag> Found it
<lag> Thanks
<apw> yeah thats the one ... sorry was distracted
<lag> Wow! I like this
<apw> lag, you do need to take its output with a grain of salt
<apw> it sometimes includes random people who changed the file but are not interesting
<lag> Well I'm using the email address it provided me with
<apw> Andrew Morton <akpm@linux-foundation.org>
<cking> http://smackerelofopinion.blogspot.com/2009/08/compilers-dragon-book.html
<apw> gnarl, should be ok now
<gnarl> apw, yep looks good 
<JFo> you got a great deal cking :)
<cking> JFo, I just need to read it now ;-)
<JFo> I need to find me a copy
<JFo> haven't seen my last one in years
<JFo> plus I never got 'round to finishing it
<lag> apw: How does this look "depends on (SPARC64 && !PCI) || (M68K && !ISA) || X86"
<lag> There doesn't seem to be an AMD64
<lag> depends on PARPORT && (!SPARC64 || PCI) && (!SPARC32 || BROKEN)
<apw> depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
<apw> 		(!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && !ARM
<apw> this original can be striped of all the architecture bits as it would be on X86 say ... and then i believe you get
<apw> depends on PCI && ISA
<apw> bibble
<lag> depends on (PCI || ISA) && ((SPARC64 && !PCI) || (M68K && !ISA) || X86)
<apw> yep that what i was angling at
<lag>  * We don't actually have real ISA nor PCI buses, but there is so many 
<lag>  * drivers out there that might just work if we fake them...
<lag>  */
 * JFo goes for some coffee
<manjo> JFo, couple of successful results from firewire testing 
<JFo> saw that :)
<JFo> very cool
<JFo> so far I have seen no negative feedback
<apw> smb, did we build in i2c in lucid do you remember ?
<smb> I would say so.
<smb> All the edid stuff at least uses i2c
<smb> Oh you mean built in or module?
<apw> yeah i was wondering if it went to built-in
<smb> Hm, i2c_algo_bit at least is a module
<smb> Seems CONFIG_I2C=y but the rest of the specific drivers is modules
 * apw screams at the intense slowness of his disk ... ARRG
<smb> apw, ^
<apw> smb, thanks .... yeah its just built so they should be able to use the kernel command line
<apw> ogasawara, i've just linked bug #589439 to the configuration blueprint.  seems to be a bunch of requests recommendations in there we should think about for maverick
<ubot2> Launchpad bug 589439 in linux (Ubuntu) "configuration gotchas with Maverick 2.6.35 kernel... (affects: 1) (heat: 105)" [Medium,Triaged] https://launchpad.net/bugs/589439
<ogasawara> apw: ack
<apw> ogasawara, also bug#592495 ... that one may well come out in the wash from the M686 changes coming from the tool-chain changes iff they have finally documented wtf we are menat to be doing there
<apw> bug #592495
<ubot2> Launchpad bug 592495 in linux (Ubuntu) "CPU for generic-pae kernel should be raised to M686 (affects: 1) (heat: 109)" [Undecided,Triaged] https://launchpad.net/bugs/592495
<ogasawara> apw: indeed.  seems the spec still needs drafting so still no idea what our work items will entail
<apw> ogasawara, got a pointer to the spec there ?
<ogasawara> apw: https://wiki.ubuntu.com/FoundationsTeam/Specs/Maverick686DefaultCompile
<ogasawara> apw: robbiew re-targeted to alpha3 due to the missing work items
<apw> ogasawara, thanks i'll go poke him
<robbiew> missing work items from doko, i believe
<apw> ogasawara, we arn't going to want to change the kernel config at that fundamental level after alpha-3
<ogasawara> apw: agreed
<apw> robbiew, well if they don't sort out whats going to happen on that one before long we are going to have to punt on it
<apw> we can't be making that level of change after a3
<apw> and if they haven't changed the compilers yet, they are making all the archive rebuild tests moot
<apw> none of which sounds like a good thing (tm)
<robbiew> apw: ack
<apw> smb, what time is the bug meeting ?
<smb> apw, half an hour by my clock.
<smb> Not that I had any time to prepare for anything
<apw> smb, i know i am punching self in the face as it is
<smb> apw, Well likely go there and make smug comments without being prepared. :-P
<doko> apw, ogasawara: ping
<doko> do you use explicit cpu flags for kernel builds?
<apw> doko, yes we completely override all compiler flags
<apw> that is the nature of the builds, as we build 3-4 different flavours
<doko> apw: but you already did drop the i386 build, did you?
<apw> doko, yes we already dropped the explicit i386 builds
<apw> but our generci builds are hovering around the 586 level
<doko> apw: and how is the default build on i386 built?
<doko> apw: why i586?
<apw> cause that is what lucid supported and its not be changed to match your documentation on where we are going, as its not yet documented
<apw> the only info i have seen was scotts announcement at uds ... "we are going move up to M686 + CMOV" but ... i've no idea if thats been done
<doko> apw: hmm, did we do document i586 as supported? the default was i486 in lucid
<doko> apw: it's in the archive since uds
<apw> doko, right in userspace that is correct.  if you wanted to use i486 you had to use the i386 flavours ... which were actually i486 minimum
<apw> the generci ones are a middle m586, ie m586 + some specific features
<doko> there is one guy who is keen on geode lx support
<apw> doko, ok ... meaning?
<apw> doko, i guess this is the discussion that we need to get written down in the spec, so that we can make an informed decision
<doko> apw: that you should not pass -Wa,-mtune=i686 to the assembler
<apw> doko, so have we changed the compiler flags to do that generally ?
<doko> apw: no
<doko> but some packages do pass this *explicitely*, and if you pass everything explicitely ... and no, not known when discussing this spec, just later when a user complained
<manjo> JFo, ping 
<manjo> JFo, bug chat ?
<JFo> yep
<JFo> one sec
<JFo> http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
<JFo> tgardner, ^^
<JFo> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=ker
<JFo> nel-candidate&field.tags_combinator=ALL&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_no_branches.used=&search=Search
<JFo> gah!
<JFo> sorry
<apw> https://wiki.ubuntu.com/Kernel/Tagging
<JFo> this one is the one that I looked at fr overall needs-review: http://bit.ly/9AdcPG
<apw> sconklin, hey ?  meeting ?
<sconklin> apw sorry, off by an hour
<manjo> tgardner, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/556872
<ubot2> Launchpad bug 556872 in linux (Ubuntu) "[lucid] [nouveau] blank screen on Dell Latitude E6410 (NVS 3100M [10de:0a6c]) (affects: 7) (dups: 1) (heat: 54)" [High,Fix committed]
<apw> anyone got any usb-1.0 devices in their posession?  hearing rumours that all 1.0 devices fail on connect on maverick kernels
<smb> Hm, I think I got an old stick
<apw> smb, any chance you could shove it in something with a maverick kernel on it ?
<smb> Not that I currently have any Maverick on anything yet
<smb> But I likely need to set up some installations anyway
<apw> smb, i only have the lts-backports kerenl installed that would do as this is slated to be kernel issue
<smb> apw, I'd rather have it tried on a separate installation. Might do one tomorrow if that is soon enough
<apw> smb, yep thanks
<bjf> apw, i just tried the oldest stick I have and it worked, i have to believe it's 1.0
<apw> bjf you can tell from dmesg, by which driver claims it
<apw> ohci == 1.0
<manjo> ogasawara, Bug #533784 looks like the comment #17 says the current lucid kernel / and your backport kenrel both fix the issue, the other -22 errs people are seeing has already been moved to a diff bug #557266. Since you have done a lot of work on this one, can you close this bug and ask people to follow the 557266 for the other issue ?
<ubot2> Launchpad bug 533784 in debian (and 3 other projects) "[Radeon kernel module] drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream (affects: 15) (heat: 104)" [Unknown,Confirmed] https://launchpad.net/bugs/533784
<ubot2> Launchpad bug 557266 in linux (Ubuntu) (and 1 other project) "[Radeon kernel module] drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream (affects: 13) (dups: 1) (heat: 70)" [Undecided,Confirmed] https://launchpad.net/bugs/557266
<ogasawara> manjo: ack, will do
<bjf> apw, dmesg didn't tell me anything usefull http://pastebin.ubuntu.com/462616/
<tgardner> sconklin, can you finish review of http://patchwork.ozlabs.org/patch/57702/ and get it committed ?
<apw> bjf does lsusb tell you ?
<sconklin> tgardner: I'll have a look
<apw> [183485.561355] usb 6-1: new full speed USB device using uhci_hcd and address 2
<apw> bjf, thats telling you i think
<bjf> hmmm
<apw> bjf, i think thats telling us yes it is a slow device, but you have uhci in your machine which is not the failing case ... i believe
<smb> lsusb -v should tell
<apw> but that uhci works with slow devices is good information, thanks
<manjo> smb, Bug #539655 
<ubot2> Launchpad bug 539655 in linux (Ubuntu Lucid) (and 2 other projects) "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini (affects: 2) (heat: 44)" [High,Triaged] https://launchpad.net/bugs/539655
<bjf> apw, lsusb for the device: http://pastebin.ubuntu.com/462617/
<smb> bjf, looks like usb 1
<smb> bcdUSB               1.10
<apw> yeah i concur.  thanks bjf
<smb> apw, Did they have usb 1.0 hubs in that case?
<apw> the tester i have problems with has usb1.1 devices ... old memory stick and a using ohci as interface
<apw> looks like the only combination affected
<smb> apw, But that could be ohci from a usb 2.0 hub (the companion hub) or a real usb 1.0 only hub, couldn't it?
<apw> smb, yes it could no way to tell, the only info i have is they have ohci
<apw> so i am assuming its a modern controller with a companion (as the machine is modern)
<smb> right
<bjf> apw, just fyi i tested on: 2.6.35-7-generic
<apw> bjf, thanks thats excellent info
 * manjo getting lunch will be back soon
<bjf> http://www.swampbuggy.com/
<bjf> http://www.youtube.com/watch?v=ADovhUcaZpo
<JFo> I always wanted to drive one of those
 * tgardner lunches
<jjohansen> -> Lunch
 * ogasawara lunch
<kees> tgardner: thanks for working out a proper fix for that AGP issue.  It sounds like a lot of other people have been hitting it, but it's a really hard bug to report (since it just stalls the system completely).
<tgardner> kees, I found at least one other guy for whom it fixed his boot.
<kees> excellent :)
<tgardner> haven't heard anything back from upstream (otehr then Rafael)
 * kees nods
<tgardner> kees, if -rc5 comes out without this obvious regression fix, then I'll put the full court press on Arlie et al
 * kees hugs tgardner
<kees> I've been utterly baffled why they've been seemingly ignoring it.
<tgardner> kees, hard to say, but maybe they are just busy
 * kees nods
<tgardner> kees, maybe you could attach the patch to the BZ report (I don't have a login there)
<kees> tgardner: sure I can do that.
<tgardner> kees, thanks, it'll help them to not forget.
<kees> heh
<squarebracket> why wasn't the wacom kernel module included in the latest kernel update? (for lucid)
<tgardner> squarebracket, there are 3 wacom modules. which one do you think is missing?
<tgardner> input/tablet/wacom.ko, input/touchscreen/wacom_w8001.ko, hid/hid-wacom.ko
<squarebracket> the first one.
<squarebracket> searching for wacom.ko at packages.ubuntu.com it doesn't look like it's included in the latest kernel
<tgardner> squarebracket, find /lib/modules/`uname -r` -name wacom.ko
<tgardner> /lib/modules/2.6.32-24-generic/kernel/drivers/input/tablet/wacom.ko
<squarebracket> yeah, i haven't done that yet... i compiled my own kernel module from the linuxwacom source but i'm looking into why my friend's tablet isn't working, and he didn't have the kernel module loaded; i assumed it was a missing kernel module
<tgardner> squarebracket, maybe its a new and unsupported device
<squarebracket> i've written a batch script to look for it, if not compile it from source... but he's at work right now
<squarebracket> it's not
<squarebracket> it worked before the kernel update
<squarebracket> (which is -23 i think)
<tgardner> squarebracket, he's running the -proposed kernel, right?
<squarebracket> he's running just vanilla ubuntu, i figured it would be -generic?
<tgardner> squarebracket, no, I meant which pocket is he subscribed to, e.g., -updates or -proposed. 
<squarebracket> oh! that's a good question, i'm not sure.
<squarebracket> should be whatever defaults
<tgardner> squarebracket, get him to run 'ubuntu-bug linux' so we get the pertinent details.
<squarebracket> sure, will do, i'll throw it into the bash script and pipe it to a file.
<tgardner> squarebracket, uh, you only need to run it once, preferably using the kernel version that fails to load the tablet driver.
<squarebracket> tgardner, yeah, it's a bash script to just check for wacom.ko / load one i compiled / compile if that doesn't work. it'll only run once.
<squarebracket> tgardner, but considering there was no wacom.ko loaded when i did an lsmod, and wacom.ko isn't in linux-image-generic, i figured it was a missing module.
<squarebracket> i'll file a bug in launchpad once i know for sure what the problem is. thanks for your help!
<virtuald> my gpu froze and i got this in dmsg: http://pastebin.com/hdcuBa46
<virtuald> anyone care to take a look?
<virtuald> #
<virtuald> [31584.658139] BUG: unable to handle kernel NULL pointer dereference at 00000080
<virtuald> on line 819
<sconklin> I'm getting some strange behavior from kernel.ubuntu.org, anyone else notice anything today?
<apw_> Test
<apw_> It was upgraded today ...
<apw_> sconklin: ^^
<sconklin> apw_: ok. It looks like the message I had never seem before is something seen in other places when git garbage collection is triggered during a push, and is harmless
<sconklin> but I was unable to fetch one of rtg's trees as a remote but was able to clone it outright
<tgardner> sconklin, yeah, I had it happen to me today as well. its a newer git that is causing it
<sconklin> tgardner: thanks. The errors that really threw me were:
<sconklin> fatal: protocol error: bad line length character: Remo
<sconklin> error: error in sideband demultiplexer
<sconklin> but I think they are OK
<apw> i wonder what thats the start of ... remove perhaps
<tgardner> sconklin, thats exactly what I got. don't make a lot of sense, does it?
<apw> i bet it is the first four chars of something longer ... but git is not meant to do that
<apw> its meant to negociate levels between the ends and dumb itself down
<apw> sconklin, w
<sconklin> no, and my brain kept trying to parse "sideband demultiplexer" in a radio context and failing
<apw> what did you try to clone ... i'd like to as well
<apw> sconklin, heh ... git protocol carries more than one channel ... so that you can get remote messages as well as the data you want
<apw> thats how it does the percentages pulled down for example... its a bit like CD
<sconklin> the above errors came from a puch on the ubuntu-lucid master when garbage collection got triggered.
<sconklin> git://kernel.ubuntu.com/rtg/ubuntu-lucid-lbm is the one I can clone but not fetch as a remote
<sconklin> apw ^^
<sconklin> btw the push to lucid master was apparently ok, and now it matches my tree and looks ok
<tgardner> apw, looks like we have alucid chroot on zinc now
<tgardner> apw, do you have a moment to help with bzr commits?
<tgardner> jjohansen, rtg@lochsa:~/maverick/ureadahead/ureadahead$ bzr commit -m"restore buffer_size_kb on exit"
<tgardner> bzr: ERROR: Cannot lock LockDir(lp-70455952:///~scott/ureadahead/trunk/.bzr/branchlock): Transport operation not possible: readonly transport 
<jjohansen> tgardner: http://doc.bazaar.canonical.com/latest/en/user-guide/index.html
<bjf> sbeattie, i'm trying to run test-kernel-security.py from qa-regression-testing/scripts and am getting "getpcaps missing (please install libcap-bin)". this is on lucid
<bjf> sbeattie, libcap-bin is not available?
<sbeattie> bjf: replaced by libcap2-bin
<bjf> sbeattie, thx
<sbeattie> bjf: sure thing. The # QRT-Packages and # QRT-Alternates meta information should describe what needs to be installed.
<bjf> sbeattie, they do, I just blindly cut and pasted without thinking that they were different release versions
#ubuntu-kernel 2010-07-13
<manjo> JFo, can you regenerate your top 50 list ?
<manjo> JFo, I did a bunch of work but it does not reflect on that list, if You can refresh it, I can see what else I need to look at 
<manjo> bjf, in case JFo is out for the day... is this something you have access to ?
<ogasawara> manjo: I might be able to run in locally and post the html page, gimme a sec
<bjf> manjo, nope
<manjo> ogasawara, thanks
<manjo> bjf, np
<ogasawara> manjo: http://qa.ubuntu.com/reports/ogasawara/tmp/kernel-buglist-top50.html
<manjo> ogasawara, thanks
<ogasawara> manjo: let me know if that doesn't look correct
<manjo> ogasawara, looks good thanks 
<JFo> fwiw, it runs every hour
<JFo> so it will refresh every hour
<fbond> Hi, the linux-input maintainer is ignoring my patch. Does Ubuntu have any interest in it? https://patchwork.kernel.org/patch/102708/
<fbond> I'm not sure if there's something more appropriate for me to do with it.  If there is, I'd appreciate advice.
<fbond> E-mailing Linus seems like a rocky proposition. ;)
<fbond> The patch may very well be bone-headed.  I'm just trying to get it submitted to help out folks with that hardware.
<fbond> It seems that no good deed goes unpunished.
<RAOF> Hm.  That looks like you've pinged at appropriate intervals.
<RAOF> I'm not familiar with the input side of the kernel, though, so I'm not sure what secret handshakes, if any, are expected.
<fbond> RAOF: Yeah, I've never dealt with linux-input before.
<fbond> RAOF: I'm not sure if perhaps the issue is that I mentioned that the device manufacturer recommends the fix; perhaps
<fbond> that introduces copyright concerns?
<RAOF> No.  That patch is too small to be copyrightable.
<fbond> That's what I figured.
<fbond> RAOF: Is it something I should submit to ubuntu-kernel?
<fbond> Or is that useless given upstream's disposition?
<RAOF> You could bring it to the list.  I don't think that we're likely to apply it without some indication that it'll go upstream, but perhaps someone on the ML will know the secret handshake.
<fbond> RAOF: Okay, thanks.
<achiang> fbond: dmitry can be... unresponsive at time
<achiang> s
<achiang> fbond: did you cc him directly?
<fbond> achiang: Yes, my last message was sent directly to him.
<achiang> fbond: yeah, i've had a really hard time in the past getting dmitry to respond. i'd say ping again, direct mail + public list Ccs?
<achiang> fbond: sorry, not very helpful, i know
<fbond> achiang: Oh, wait ... I sent it to Jiri.
<fbond> Who's dmitry?
<achiang> fbond: dmitry torokhov is the input maintainer
<achiang> erm, not sure i got the spelling right
<fbond> achiang: Jiri is listed as the HID CORE LAYER maintainer.
<fbond> I guess hid-input.c changes should go to dmitry?
 * achiang reads patch again
<achiang> fbond: sorry, you are right, i saw "input" and thought dmitry. jkosina is indeed the correct maintainer
<fbond> achiang: No problem.  Any help is welcome.
<achiang> fbond: pinging jiri on irc now, give me a sec
<fbond> achiang: Oh, thanks.
<achiang> fbond: it's entirely possible that he's on holiday too. how long did you wait between the mails?
<achiang> oh wow
<achiang> a long time
<fbond> Yeah. ;)
<achiang> well, between 7/8 and today is only 4 days
<fbond> Although I only sent mail to him directly once.
<fbond> True.
<achiang> you know europeans, with their 26 weeks of holiday per year... ;)
<fbond> achiang: Ah, yes, I've heard of this before. ;)
<smb> morning
<cooloney> smb: morning, man
<cooloney> i've pinged GrueMaster to test the security updates for fsl-imx51
<smb> cooloney, Ok, cool
<cooloney> smb: will you bring beer to prague this time? haha
<smb> cooloney, I generally just send the mails your and ericm|ubuntu 's way as sort of fsl and mvl authorities. Sorry man, I am flying. :-P
<smb> Anyway it would be wasted anyway. Theirs is good and cheap
<ericm|ubuntu> smb, ok
<cooloney> smb: no problem, German beer is always good
<kraut> moin
<smb> RAOF, Are you around?
<TeTeT> smb: might you be available for some help with building a kernel in a PPA tomorrow? I've tried now several times and always failed with the ABI. I now copied older ABIs to the most recent kernel name and wonder if that helps. Just in case it doesn't, would you be available?
<smb> TeTeT, I guess I should be available. Give me a sec, maybe we got a page that is helpful
<TeTeT> smb: I found the kernel for idiots page already :)
<TeTeT> smb: it has been very helpful so far
<smb> TeTeT, That is good. but there is one where we documented abi check avoidance
<maxb> TeTeT: kernel for idiots? link please? :-)
<smb> https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
<TeTeT> maxb: ^
<TeTeT> thx smb
 * maxb bookmarks
<smb> TeTeT, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
<smb> TeTeT, I would think option 2. for ABI and modules would be what you want
<TeTeT> smb: ok, if my new build fails I'll try it tomorrow
<TeTeT> smb: problem is I'm on the road and only have UMTS for new uploads, otherwise I'd parallelize it
<smb> TeTeT, I will be around. If you can have things in a place I can access them
<TeTeT> smb: I'll place the needed patch on chinstrap if need be, thanks
<smb> TeTeT, It might be worth having your repo pushed to zinc and do the upload and packaging there
<TeTeT> smb: it's really only a patch, for the Esprimo E bug, 586325
<smb> bug 586325
<ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 88)" [Medium,Confirmed] https://launchpad.net/bugs/586325
<TeTeT> smb: customer wants a production kernel before the SRU lands, so they can do their roll out in time
<smb> TeTeT, Ok, They just should be aware to be careful with updates until a fix is really in updates
<TeTeT> smb: agreed, but they run their own repo - I'll tell them to not sync kernel updates until the patch made it into mainline
<smb> TeTeT, Ok then
<ShapeShifter499> hi
<ShapeShifter499> I'm tryin to install the e100 driver with no luck via the "make install" command any help?
<apw> ShapeShifter499, as in modifying an ubuntu version?
<ShapeShifter499> well I don't know....I'm trying to get my ethernet port working, currently wifi is only working
<apw> so where are you getting the source code you are trying to install from
<ShapeShifter499> I'm getting the source from intel's website
<apw> ShapeShifter499, which release kernel are you trying to add it to
<ShapeShifter499> no wait....
<ShapeShifter499> e100 is all ready on my system
<ShapeShifter499> it just wasn't being loaded for some reason
<ShapeShifter499> just got it up and running via modprobe 
<ShapeShifter499> brb just need to test the port
<ShapeShifter499> eh its not working
<ShapeShifter499> but I g2g bye
<TeTeT> smb-afk: my PPA will fail again, see https://pastebin.canonical.com/34554/ and https://pastebin.canonical.com/34555/ for the contents of the abi directory. I'll send you the patch now
<smb> TeTeT, Is it possible for you to have a differently name PPA or are there other packages already there that require you to keep it? I am asking because you started to upload with a incremented ABI number which I rather would avoid. But I you have to stick to that PPA we cannot go back
<TeTeT> smb: I can simply erase all packages there, no problem. or even delete the PPA and start from scratch
<smb> TeTeT, I believe deleting the packages does not help against needing incremental numbers. But if you can use a different PPA I can create a src package for you with the numbering being better (at least IMO)
<TeTeT> smb: that would be great. I called the first package I tried 2.6.32-24~lvm0, but it did not build. Can you simply put any PPA in place and upload the src there so it builds? I really only need the resulting PAE package and headers, not much else
<apw> smb, i think if you delete and then wait 'long enough' a ppa can at least have stuff which is only newer than the archive
<smb> TeTeT, i would place a srcpkg on zinc for you to sign. You can copy it and then use debsign -r for that and then upload from zinc
<smb> apw, Hm ok. In most cases I did not wait long enough then
<TeTeT> smb: do I have access to zinc?
<smb> TeTeT, The version number you used seems to miss the upload number so that would not work
<smb> TeTeT, Hm maybe not. Maybe upload from chinstrap works the same
<TeTeT> smb: ok, I guess I did something wrong
<smb> TeTeT, I would usually use a version number like 2.6.32-24.38+xxx
<apw> smb, know anything about WPA/WPA2 support ... and whether there is card support required for them ?
<smb> apw, Not really much. I think you would need card support for it done in hw but the wpa_supplicant would do it otherwise. But that might be wrong
<TeTeT> smb: the + to make it newer? So far I used ~ to make it smaller
<smb> TeTeT, Yeah, depends what you base version is. As I base the package on 2.6.32-24.38 it is sort of newer. If I'd use 2.6.32-24.39 it would need to be smaller
<smb> apw, tgardner 15m until TB meeting
<tgardner> smb, ack
<tgardner> apw, did anyone ever take a serious stab at getting psurbhi's async rootfs/boot patches upstream?
<psurbhi> apw, have you sent your patch upstream?
<apw> tgardner, psurbhi, that is on my list of things to do ... i noticed they have a couple of warnings which need cleaning up in them
<apw> perhaps i'll do that at sprint, as we'll be off the grid
<psurbhi> apw, thanks :)
<apw> psurbhi, yeah they need to go as a set as they don't make sense without so i'll do them together if that works for you ... obviously your signoffs are on your ones
<psurbhi> apw, yes sure it does :)
<hrw> hi
<hrw> apw: any suggestions to patch from bug 603087 (stage1 support)?
<ubot2> Launchpad bug 603087 in linux (Ubuntu) "Allow to build just linux-libc-dev (affects: 1) (heat: 12)" [Wishlist,In progress] https://launchpad.net/bugs/603087
 * ogra wonders if tgardner's recent ureadahead fix in lucid might be the magical fix for Bug 600359 ... somehow smells related
<ubot2> Launchpad bug 600359 in ureadahead (Ubuntu Maverick) (and 1 other project) "ureadahead generating oom messages during boot. (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/600359
<bjf> ##
<bjf> ## Kernel team meeting in two hours
<bjf> ##
 * abogani waves After Zinc upgrade I receive this error (http://paste.ubuntu.com/462958/) pushing new stuff into my git tress. Is it something which I should care?
<apw> abogani, you need to mark that as a bare repo on zinc ... bare = true in config
<tgardner> abogani, the new git version complains if you don't have a bare repository.
<smb> Depending whether it is a bare repo
<smb> You also could have one with a working tree, and then would need to set that config mentioned
<manjo> sconklin, iirc you made a presentation about video at one of the sprints, where can I start learning about video?
<manjo> sconklin, if you can point me in the right dir ... very much appreciated 
<sconklin> manjo: let me look. That was based on the years I spent writing device drivers, I'm not sure where you could get a good overview of the whole pipeline.
<abogani> apw, tgardner, smb: Thanks!
<manjo> sconklin, thanks. wish I had made notes that day :)
<achiang> fbond: just pinged jiri; our theory that he was on holiday was correct
<achiang> fbond: he said he'll get around to processing his backlog "soonish" after responding to his inbox
<fbond> achiang: Ah, okay, thanks.
<sconklin> manjo: all the stuff I talked about is interesting, but mostly not related to the parts of the linux drivers that cause the most pain. Still, it's useful to know in general how things work
<smb> TeTeT, Ok, source package parts are now in my home dir on chinstrap for you to copy, resign and upload. I believe with the right config there you can directly upload from there
<manjo> tgardner, I think its bzr launchpad-login
<TeTeT> smb: thanks, let me see how far I get
<TeTeT> smb: would you happen to know how resign the packages on chinstrap? debsign is not installed on chinstrap
<smb> TeTeT, You likely want to use debsign -r from you local machine
<smb> That downloads only the .dsc and changes
<smb> TeTeT, debsign -k<yourkey> -r <host>/<dir>/*.changes
<TeTeT> smb: ok, giving it a try
<smb> TeTeT, Actually debsign -k<yourkey> -r <host>:<dir>/*.changes
<tgardner> apw, bzr: ERROR: Cannot lock LockDir(lp-70455952:///~scott/ureadahead/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
<ogra> tgardner, its owned by Keybuk accroding to the URL
<ogra> i'd create my oen branch and file a merge request
<ogra> *own
<ogra> if there isnt an ubuntu-core-dev one
<tgardner> ogra, yeah, I've just followed that route
<ogra> though i wonder, is that the branch thats mentioned in debian/control ? 
<ogra> it should point to a public one
<tgardner> ogra, its a bit weird because ureadahead is the upstream repository and is not a debian package
<ogra> yeah
<ogra> the branch should be ubuntu-core-dev owned 
<apw> ogra, isn't that the packaging branch .... which should be
<apw> including the debian directory
<ogra> looking at debian/copyright and debian/control it doesnt even mention any upstream location
<ogra> bad bad Keybuk !
<ogra> apw, we dont separate upstream development and debian branches anymore for native ubuntu packages
<apw> ogra, what about packages which arn't just native ubuntu packages
<ogra> things like casper, livecd-rootfs etc that are native ubuntu stuff usually have the debian dir included
<apw> ie ones like upstart which are in debian as well but not sync'd
<ogra> for these you usually have two branches, yeah
<apw> so i think thats what he has here, an ubuntu packaging one, which he merges this one into
<ogra> either way copyright and/or control should mention the actual upstream location
<apw> i think ... not htat i have a clue how you'd find it should you need to update it if he was away
<apw> indeeed
<ogra> ogra@osiris:~/Devel/branches/jasper-initramfs$ grep Bzr debian/*
<ogra> debian/control:Vcs-Bzr: lp:jasper-initramfs
<ogra> thats the usual way to point to an upstream source
<apw> ogra, yep but which one, the upstream upstream, or the one with the debian packaging
<ogra> depends 
<apw> see and therein lies the uslessness of the thing ... we cannot ever find the right branch even if its listed
<ogra> jasper for example carries the debian dir in it 
<ogra> (my above example)
<ogra> it isnt usable without images built in the ubuntu infrastructure
<ogra> for rootstock where i'm upstream upstream i have a separate packaging branch, and no Vcs-Bzr: in control, but the location of the upstream branch in copyright
<apw> ogra, i wonder if it is allowed to have two in there, that would make some sense
<apw> pointing to both the packaing and the code branches
<ogra> sure
<ogra> you can do that, i think they are different Vcs-Bzr tags 
<TeTeT> smb: uploaded the sources to a new PPA, thanks! fought a little bit with dput on chinstrap :) will report to you tomorrow if the build run well, going to the hotel now
<ogasawara> JFo: I just realized you have an ubuntu dev week session tomorrow on kernel triage
<JFo> yep
<JFo> :)
<apw> jfo what time is that going on ?
<smb> JFo, And there is a kernel bug day?
<JFo> planned to go over the new tagging scheme etc
<JFo> smb, indeed
<smb> JFo, Btw, can you add that to kernel-team calendar?
<JFo> smb, I can indeed
<apw> JFo, presenting the "triage levels 1-3" ?
 * JFo digs the time up for apw
<smb> JFo, Thanks :)
 * apw cracks the whip
<JFo> apw, looks like 9PM your time
<apw> gah
<JFo> it is 4PM EST
 * JFo adds the triage session to the kernel cal
<smb> Definitely beer o clock my time
<apw> JFo, then you'll have to hastle other kernel peeps to keep you company!
<JFo> no sweat apw
<JFo> I hadn't actually planned to pester you guys
<JFo> I think I have more than enough to discuss :)
<JFo> plus I gave an intro to the kernel on Saturday
<JFo> for Ubuntu User Days
<JFo> k smb, it should be there now
<smb> JFo, The triage session is. Though I am sorry to have been unclear (that one is good too) but there was aksing to have the kernel team bug day effort there as well to remind people
<JFo> oh hah! :)
<JFo> I'll add that too :)
<smb> JFo, Many thank yous :)
<JFo> my pleasure
<bjf> JFo, when do you take off for prague?
<bjf> ##
<bjf> ## Kernel team meeting in 30 minutes
<bjf> ##
<JFo> I'm leaving Thursday morning for Dallas to hit a meeting, then leaving Friday for Prague
<smb> poor meeting
<ogasawara> heh
<JFo> ogasawara, is the kernel bug day showing up right for you on the cal?
<JFo> smb :-P
<smb> JFo, Its showing on mine. Thanks
<JFo> should be 8 AM
<JFo> cool sm
<JFo> err smb
<bjf> JFo, so you get into prague Saturday and have a intro to the kernel meeting that day
<ogasawara> JFo: yep, showing 8am-11am for me
 * smb feels a bit sm
<JFo> no, the intro was this past sat bjf, sorry for the confusion
<JFo> ogasawara, cool
<JFo> smb, heh :)
<bjf> JFo, was thinking you were more insane than usual
<JFo> oh no, no more... no less
<JFo> :-D
<JFo> heading to CLT tomorrow since my flight on Thursday is early
<simar> JFo, Hi i have been working on triaging bugs related to touchpad xserver-xorg-input-synaptics. I have folowed your class in Ubuntu OPen week but now don't know where to start. I know how to package but where should i start and what should i do now??
<JFo> simar, have you read the wiki documentation we have so far on bug triage?
 * JFo gets the link
<JFo> simar, these pages https://wiki.ubuntu.com/Kernel/BugTriage ?
<JFo> keep in mind that they are being reworked so they may not be complete as yet
<simar> JFo, I have not but i will that by tomorrow ..
<JFo> cool
<JFo> let me know if yo uhave questions as you read :)
<JFo> or if something makes no sense
<JFo> I want to get them as clear as possible
<JFo> thanks simar :)
<simar> JFo, Ok
<JFo> simar, we are about to have our weekly meeting in #ubuntu-meeting. You are welcome to join us and see what all we discuss in these meetings
<JFo> if you are interested, that is
<simar> JFo, Now i can really see a way to contribute ... I hope so :)
<JFo> I hope so too :)
<simar> JFo, one general question. Is there any diagnose tool that can display information right from touchpad ie from the kernel driver in 'as is' form , when i produce events like touch .. currently what i know of is evtest?
<JFo> simar, the best person to talk to would be cnd, but I don't know off the top of my head :)
<simar> JFo, ok, so should i ask him now?
<simar> JFo, i think he's online
<JFo> well, it is entirely likely that he is busy
<JFo> as he does a lot of hardware work
<JFo> it may be a better idea to send an e-mail to the kernel list and ask there.
<JFo> that way he can answer as he gets the time
<sconklin> severe tstorms here, if I drop that's why
<JFo> k, keep the grounding rod handy sconklin :)
<simar> JFo, thanks i see some more ways ..
<JFo> cool :)
<simar> JFo, I 'm already joined the kernel mailing list ..
<simar> :P
<JFo> excellent! :)
<simar> JFo, thanks.. 
<JFo> my pleasure
<cnd> simar, I can answer here
<simar> cnd thanks
<bjf> ##
<bjf> ## Meeting about to start
<bjf> ##
<simar> cnd  Is there any diagnose tool that can display information right from touchpad ie from the kernel driver in 'as is' form , when i produce events like touch .. currently what i know of is evtest?
<cnd> simar, yes, I use evtest for that purpose
<simar> cnd but it doesn't do it in a live manner .. like xev do for x drivers
<cnd> simar, I'm not sure what you mean
<cnd> when I use it, I touch on the touchpad and I get events spit out
<simar> cnd actually i get some properties and in the end theres a message Testing ... (interrupt to exit) . I want to use it for touchpad ..
<cnd> simar, what kind of device is it?
<cnd> some of the x drivers lock the evdev interface from the kernel
<cnd> if you jump to another VT you should be able to see events for those devices
<simar> cnd, sorry i dinn't get VT
<simar> cnd synaptics touchpad .. I want to fix the multitouch support which is not recognised by kernel . it shows SYnaptics Capabilities 10100 ..
<simar> cnd though it is multitouch capable . There are a lot of bugs filed about this always ...
<cnd> simar, to switch to a different VT, use ctrl+alt+<number>
<cnd> X normally resides on VT 7
<ogra> depends how insane your distro is :)
<ogra> (some use vt1 nowadays )
 * cnd hopes simar isn't trapped in another VT and can't find his way back :)
<ogra> maps.google.com ;)
<simar> cnd is still dinn't get it. Seems to be something new for me . I will google it . You could resume with your imp work and thanks for your generous support ...
<cnd> simar, np
<simar> cnd, thanks again
 * JFo goes to grab grub.
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - July-27 - 17:00 UTC
<bjf> lag, if you'd use "*" instead of "-" for your status, i'd appreciate it, that makes it a straight cut and paste for me
<smb> bjf, Maybe I should convert to that too
<bjf> smb, there is no hope for your status :-)
<smb> :-P
<bjf> smb, if you can make it look reasonable in moin that would be fantastic, but don't go to any great effort
<smb> Lets see for next time
<apw> bjf do you have a table conversion in your scripting ?
<apw> smb's stuff is essentially a table, but || ppo || bar || is very ugly
<bjf> apw, been working on one, so yes, partial
<apw> though i guess as long as he spaces it out nicely it would look ok on here
<smb> Well I should be able to make it directly into one
<apw> || karmic          || v2.6.32-rc1       || 5 pending ||
<bjf> apw, right, needs to look sane in text, convertible to moin and convertible again to html (for blog)
<apw> gah ... bibble, to hard
<bjf> the sane in text is just for the meeting, if you've noticed the email i send out it's straight moin and I don't care how it looks :-)
<bjf> so if you can make it moin, that doesn't look too bad in the meeting, that's fantastic for me
<apw> yeah i recon a moin table, but with the internal spacing so it lines up in IRC
<lag> bjf: No problem
<bjf> lag, thanks
 * manjo getting lunch will be back soon
<NCommander> Ping, is there anyone around who can help sort out kernels with marvell? I need to upload the latest SRU kernel to maverick to use as a base
<NCommander> pgraner: ping, do you have any objections if we copy the lucid SRU kernel to maverick?
<ripps> The wacom driver in the kernel is out of date. I made a dkms package that builds a new wacom module from upstream using dkms, but when I tried to submit the package to debian, they said that I was just working around the kernel development process. Does anybody know how I can patch the kernel wacom source to new version?
<ripps> The new module is needed for the Wacom Bamboo Pen & Touch models to work.
<apw> NCommander, which kernel what ?
<apw> smb, ^^
<smb> apw, Don't know what is in Maverick (mlv-dove wise)
<NCommander> apw: smb: lucid release kernel :-/
<apw> NCommander, you proposing a pocket copy ?
<NCommander> apw: yeah, from lucid-updates -> maverick
<apw> NCommander, are we expecting a kernel update for mvl-dove before release ?
<apw> as .32 is damn far behind userspace
<apw> NCommander, as we already have a .32 kernel in maverick and the one you are proposing to copy is at least better security wise it doens't seem like a bad idea.  i don't think we can make any guarentees about it working with maverick userspace though
<smb> As the current mvl-dove for Maverick is a pocket-copy either, I cannot see much harm
<NCommander> apw: that's fine, I'll hold onto both pieces should they break in two
<NCommander> :-)
<apw> NCommander, but tell me there is a plan to update the kernel
<NCommander> apw: there is a plan being planned
<apw> jjohansen, yo ... did that AA push go out
<jjohansen> not yet been doing the server team meeting
<apw> ahhh doh :)
<apw> smb, http://people.canonical.com/~apw/misc/fbcon-handoff2.ogv
<smb> apw, Looks quite smooth and a nice addon effect seems to be to retain messages on the vt that were there on boot
<apw> right, as they really are there on the VT its just not updated
<apw> and that is why they dissappear ... cause we switch to VT7 which doesn't have them
<smb> right
<jjohansen> -> Lunch with kids
<JFo> enjoy :)
 * ogasawara lunch
<JFo> ^^ with kid ;)
<manjo> JFo, can you add the bug mumble tomorrow to our calendar ?
<JFo> bug mumble?
<manjo> bug review that we are supposed to have tomorrow morning ?
<JFo> oh, it isn't a bug review
<JFo> and it is already on the calendar
<JFo> it is a Team bug day
<JFo> for about 3 hours in the channel here
<kees> ogasawara: are you back this week?
<ogasawara> kees: yep
<kees> ogasawara: cool.  I sent https://lists.ubuntu.com/archives/kernel-team/2010-July/011633.html earlier today, but I've since added another patch on top of those for another bug.  Should I send a separate pull request, or will you pull everything since 78e9e77809943546ba9db28bfacce07ecfaecfe0 in that tree anyway?
<ogasawara> kees: I can just pull everything since 78e9e77
<ogasawara> kees: I'd actually already pulled the first two patches, so I'll just pull the last one you've added
<kees> ogasawara: okay, cool, sounds good.  I'll leave that tree alone now.  ah, perfect, thanks.
#ubuntu-kernel 2010-07-14
 * jjohansen heads out for a bit, back on in 20
<bjf> pgraner, http://kernel.ubuntu.com/~bradf/table.html
<bjf> pgraner, that is with a better dataset, just lucid bugs
<bjf> pgraner, still very simple algo. none of the code you sent to me
<ogasawara> kees: have you boot tested that last yama patch you added?  "UBUNTU: SAUCE: Yama: verify inode is symlink to avoid bind mounts"
<ogasawara> kees: I'm getting an oops/panic on two test systems I've tried (one's i386 the other amd64)
<ogasawara> kees: if I back out just that last patch, the systems boot fine
<ogasawara> kees: I posted some test kernels on tangerine in my home directory under yama/
<ogasawara> kees: the "good" debs are of the latest ubuntu-maverick tip http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=summary which contains just the first 2 yama patches you originally submitted
<ogasawara> kees: the "bad" debs are the latest ubuntu-maverick tip plus that last yama patch you added
<ogasawara> kees: for now I'm only going to apply the first 2 patches and do an upload upload since I rebased to 2.6.35-rc5 and want to get it uploaded for testing asap
<Dawgmatix> how do i add directories to the module search path ?
<jk-> Dawgmatix: i don't think you can
<Dawgmatix> ok
<jk-> oh, you can add -d to the modprobe command line
<jk-> but I don't think you can specify it for other invocations of modprobe
<Dawgmatix> hmm looks like you can change modules.conf to add paths too
<jk-> I don't see a configuration parameter to do that
<Dawgmatix> I was going by http://pwet.fr/man/linux/formats/modules_conf 
<Dawgmatix> that has a path parameter that you can set
<jjohansen-afk> back on later
<jk-> Dawgmatix: my modprobe isn't trying to read any /etc/modules.conf file though
<jk-> (sudo strace -e trace=open,stat modprobe pretend-module-name)
<Dawgmatix> yeah i just realised ubuntu doesnt come with a modules.conf 
<kraut> moin
<kees> ogasawara: I did; I functionally tested it, in fact.  You can see my tree on tangerine.  :(
<kees> ogasawara: ah, no, I totally lied.
<kees> ogasawara: one sec, I will fix.
<kees> ogasawara: I had a slightly different version.  :(
<ogasawara> kees: no worries, just push the fixed version to your tree and I'll pull it
<ogasawara> kees: it'll make the next upload
<kees> it's really loopy having my pristine yama source, the security-next tree and the maverick tree.  :P
<ogasawara> kees: just for good measure, go ahead and send the pull request to the mailing list
<kees> ogasawara: okay.  is the tree with the other two pushed already?  I can rebase my maverick tree if so.
<ogasawara> kees: I've already applied and uploaded the other two
<kees> okay, I'll rebase
<lag> apw, smb: http://www.amazon.co.uk/dp/B003HIWHN0
<hrw> lag: class2?
 * lag shrugs
<lag> I thought SDHC was class 4?
<smb> There are class 6 of those as well, though that kind of triples the price
<hrw> lag: class2/4/6/10 maybe class8 too
<lag> @ 32GB?
<lag> The HTC Desire's specification says: "microSDâ¢ memory card (SD 2.0 compatible)"
<lag> Does that mean classes >2 won't work?
<hrw> lag: I did not know that 32GB microsd exists 
<apw> lag, don't think so, think thats specification 2.0
<lag> That's what I was bringing to apw and smb's attention 
<hrw> lag: that mean that it support microsd
<lag> How does that differ to class 2?
<hrw> class 2/4/6/8/10 is just speed 
<apw> classes are simply speed specifications
<apw> presumably minimum speeds in some sense
<hrw> sd 2.0 is specification of SD standard version 2.0
<lag> k
<hrw> so things like "suport for 1/4/8 bits, sdio support things"
<hrw> 1
<ripps> What would be the best way to get a patch into the kernel? I basically just need to drag'n'drop the wacom module source files into the kernel.
<ripps> The kernel wacom source is out of date and doesn't support the wacom bamboo pen & touch series.
<ripps> I've figured out the the source files in drivers/input/tablet/wacom* are the same as those in the linuxwacom package, so a simple drag and drop of the files should work. Can someone give me some advice on this.
<smb> ripps, Upgrading a whole driver is usually rather frowned upon for released kernels, at least if that brings a log of changes. And the other question would be whether it needs some userspace update as well?
<smb> One thing might be to have the updated driver included in linux-backports-modules
<ripps> smb: I've already confirmed that the only the kernel module needs update. I've currently been pointing people to use a wacom-dkms package in one of my ppas
<smb> s/a log/a lot/
<ripps> yeah, linux-backports-modules sounds like a good idea
<ripps> The problem is in lucid too, would it be possible to backport the driver there, as well?
<smb> If you say Lucid, too. Is the other release Maverick? Ultimately for Maverick it would be a goal to update the driver upstream as well. Though it might be a bit late for that. And yes, for Lucid I think it would be reasonable to have that backport there as well. Maybe needs thinking of having a seperately grouped binary package, like linux-backports-input
<ripps> sounds good to me.
<ripps> although, the kernel input api is different between the lucid kernel and the maverick kernel, so the maverick version of the wacom source needs to be tweaked
<ripps> Is there a guide out there on how to make a linux-backports package?
<smb> ripps, So I would say the best approach is to bring the issue and proposal up in a mail to kernel-team@lists.ubuntu.com and let it be discussed/documented  there
<smb> ripps, We do the l-b-m package and sadly I guess to make that extension is rather well undocumented and probably complex. 
<tseliot> apw, smb: I've found a regression in the kernel from 2.6.32 to 2.6.35 which affects the radeon driver. How do you suggest that I start bisecting? I cloned the maverick branch but obviously it doesn't contain an Ubuntu-2.6.32 tag
<apw> tseliot, thats triciker
<tseliot> apw: how tricky is that?
<apw> tseliot, i would try the mainline kernels and see if the issue is in there
<tseliot> ah
<apw> as thats much easier to bisect
<apw> and you can use the mainline builds in between to narrow your search
<tseliot> apw: and shall I rely on the date the kernel was built and look it up in the linus tree?
<apw> tseliot, how to map an ubuntu kernel into a mainline version is a question in the kernel FAQ :)
<apw> https://wiki.ubuntu.com/Kernel/FAQ#Given an Ubuntu kernel package version how do we find the exact mainline release it is based on?
<apw> which points you here: http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html
<tseliot> apw: thanks, I'll RTFM ;)
<apw> :)
<ripps> did the kernel-team mailinglist get my linux-backports-input proposal?
<smb> ripps, Did not yet see anything but it might be stuck in moderation until the right half of the planet is awake
<TeTeT> smb: thanks for your kernel source, it was built yesterday evening and we test it today :)
<smb> TeTeT, Good to hear
<apw> pgraner, how is your machine which was grinding till we freed the buffers ... how many more cycles has it managed
<pgraner> apw, its done 35 and was doing fine until I started copying data to the usb disk, now even mumble is dead, I had to switch to my netbook
<pgraner> apw, same box is showing the I/O issues
<apw> pgraner, ok
<apw> 35 would be counted as success me thinks on the original issue
<pgraner> apw, yep I would agree, so tgardner's patch should do the trick
<apw> pgraner, fingers crossed
<andreserl> hi all. I was wondering how can I know which cn_idx number I should use for DRBD. Where can I find that #?
<apw> andreserl, you might have better luck asking that on #ubuntu-server as they do more with DRBD than we do
<andreserl> apw, yeah but afaik the cn_idx is the number related to the kernel. But will try asking there :) THanks
<andreserl> (I mean the number that the module uses in the kernel)
<apw> andreserl, its just not a kernel feature most of us would routinely use, they might and might answer sooner (or indeed at all :)
<andreserl> apw, ok :)
<andreserl> thanks
 * apw cirtanly has no idea what the cn_idx even is :)
<smb> apw, Guess we can guess what the idx part is but cn... :)
<tgardner> smb, cn == channel number ?
<andreserl> connection index
<smb> Could be a lot without knowing. So andreserl might know more than us here
<andreserl> smb, I just know I need to now the cn_idx for the DRBD kernel module and make the change in the drbd8 package before uploading :/
<apw> what does cn_idx stand for even
<apw> idx presumably is the index ... 
<smb> apw, I think we were at connection index
<andreserl> apw, connection index
<smb> But server is likely the guys. Given they provide the kernel module as dkms
<andreserl> smb, The drbd kernel module is included in the kernel starting from 2.6.33,
<andreserl> so there's no longer the need to use dkms
<andreserl> and even so, when using dkms, we also specify the cn_idx
<smb> andreserl, ok, I might be backwards there. Last thing I remember was making it dkms because we had it in seperate modues and too often behind what was needed
 * apw is looking for it
<andreserl> smb, ummm what I know is that in drbd module was in hardy kernel, after that, it wasn't. And for what I understand, from now on, the DRBD module will be in the kernel starting from 2.6.33
<andreserl> http://www.drbd.org/download/mainline/
<andreserl> in the drbd8 source package, in debian/dkms.conf we specify the cn_idx: "MODULES_CONF[0]="options drbd cn_idx=7"
<andreserl> in hardy, Intrepid, I believe it used to be 6
<andreserl> in debian is 4
<andreserl> so now in maverick, I don't really know which one is it
<apw> include/linux/connector.h:#define CN_IDX_DRBD                   0x8
<andreserl> apw, awesome! thanks :)
<amitk> tgardner: looks like you're the person with the IGEPv2 OMAP board
<tgardner> amitk, oddly enough, I am just in the process of turning it on this morning. I've never encountered a web site that is quite so bad (http://www.igep-platform.com)
<amitk> heh :)
<amitk> tgardner: some folks are interested in knowing if it is well-supported in ubuntu. My suspicion is that it'll required only a few patches to get it well supported.
<tgardner> amitk, the default image isa 2.6.28 kernel, but I see they alaso have up to 2.6.33 on their web site
<hrw> tgardner: I would just try to boot default ubuntu omap3 kernel
<tgardner> amitk, perhaps I should just try a Lucid omap3 rootfs?
<amitk> tgardner: just boot with lucid
<amitk> including the kernel
<tgardner> amitk, easier said then done. still figuring out how to do that.
<amitk> the only thing I have no idea about is the bootloader on there.... so keep what they ship with.
<tgardner> amitk, I think it'll boot from micro SD
<amitk> tgardner: keyword: ogra 
<amitk> tgardner: but yes, micro-sd is the quickest way
<tgardner> amitk, gotta find the rootfs first. somewhere on ubuntu.com ?
<amitk> tgardner: http://cdimage.ubuntu.com/ports/releases/10.04/release/
<tgardner> amitk, try the omap server install?
<amitk> tgardner: yes, unfortunately we don't provide premade rootfs yet 
<amitk> you can create your own rootfs with rootstock scripts
<tgardner> amitk, so if it boots from SD, where does it install? External USB driver?
<mpoirier> tgardner: you'll have to use netboot to get your setup on SD card.
<amitk> yes, USB drive/HDD
<mpoirier> tgardner: I'm running into the same problem install  lucid UNR on beagleboard.
<tgardner> mpoirier, on the phone, hang on.
<apw> tseliot, about ?
<tseliot> apw: yep
<apw> wondering if you knew what plymouth did when it is started ... whether it clears the VT it is selecting for instance
<apw> in broad terms its activity while owning the VT
<apw> tseliot, ^^
<apw> tseliot, can i get plymouth to tell me what happened to it during a boot for instance.  interested to know (as an example) if it gets a resize event on drm load
<tseliot> apw: plymouth gets its own "screen" that it swaps in with a black screen (at the beginning)
<tseliot> ah, a resize event? Why do you need to know that?
<apw> well i am trying to work out when plymouth has control over the screen and what it does during the time
<apw> it being the one which switches VT is interesting
<tseliot> apw: if you want some good answers you can join #plymouth and ask halfline (i.e. the author). He's very helpful
<manjo> JFo, are we having the bug chat this morning ?
<JFo> no, we are having the team bug day in this channel
<JFo> there was no plan for a bug chat
<JFo> just coordination to keep from duplicating effort
<manjo> JFo, my cal says 10am-1pm .. could my cal is misbehaving 
<JFo> nope, that is correct
<JFo> 3 hour block per tgardner to solely work on bugs
<smb> manjo, Mine says from 5pm to 8pm, yours is in the wrong tz. ;-P
<JFo> nicely blocked out on the cal by request of smb
<JFo> :)
<smb> Right, at least we won't forget it then
<manjo>  yeah don't know why my cal is always messed up
<manjo> we need utc google cal 
<JFo> hmmm, your times may be off. tgardner wants it to start at 8AM PST
 * smb hopes manjo recognizes a joke when it passes by
<JFo> heh
<manjo> smb, wrong tz... ah you got me !
<smb> sorry could not resist
<bjf> manjo, the time is now 8:12 PST
<manjo> smb, yeah easy target
<JFo> 12 minutes past the start of the bug day
<tgardner> JFo, your search URL in the calendar event doesn't produce many items
<smb> apw, JFo So there one or the other where at least some issues are understood but whether there is a fix is unclear and also how much other issues are mixed
<smb> like bug 563156
<ubot2> Launchpad bug 563156 in linux (Ubuntu) "[ATI Graphics][Lucid] laptop runs hot, shorter battery life, fan always on (affects: 31) (heat: 179)" [High,Triaged] https://launchpad.net/bugs/563156
<JFo> tgardner, search url?
<tgardner> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-proposed+karmic&field.tags_combinator=ALL
<JFo> ugh
<JFo> wrong link
<manjo> tgardner, http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
<JFo> I'll fix
<smb> tgardner, I replied to his mail with the right link
<smb> I hope to the right mail
<amitk> JFo: what group membership gets all that bug mail? (I want to remove myself from the group). kernel-bugs doesn't seem to be it.
<JFo> tgardner, changed it now
<tgardner> amitk, ubuntu-kernel-team ?
<amitk> tgardner: aah, it is kernel-team?
<manjo> amitk, arnt you *supposed* to be subscribed to get all bug mails ?
<JFo> smb, I had a bad link in the calendar item
<JFo> so I fixed it
<JFo> sorry for leaving it out of the e-mail
<amitk> manjo: nope, everyone in a _certain_ group gets all bug mail filed against the linux package
<smb> JFo, Oh calendar. :) Good. I saw that there was only a [1] in your mail
<JFo> got in too big a hurry
<tgardner> amitk, I get 'em because of 'You received this bug notification because you are a member of Canonical Kernel Team'
<bjf> tgardner, i think amitk is saying he no longer wishes to be "a member of Canonical Kernel Team"
<tgardner> bjf, I'm not sure he gets a choice there.
<JFo> heh
<bjf> tgardner, maybe he is giving notice :-)
<amitk> bjf: I've got 24871 emails in my ubuntu-bugs folder (and growing). But yes, that'd be a nice subtle way to give notice ;)
<tgardner> amitk, weren't you the one promoting server side procmail ?
<JFo> don't do it amitk! think of the children! ;)
<amitk> tgardner: it is all filtered away nicely, but it is an eyesore
<jjohansen> bjf: http://launchpad.net/kslm
<bjf> jjohansen, thanks
<jjohansen> bjf: also www.headinthecloud.net
<bjf> jjohansen, am i missing something, that launchpad link is little more than a title
<jjohansen> bjf: nope, that is all I have
<jjohansen> well that and the headinthecloud.net
<bjf> pgraner, http://kernel.ubuntu.com/~bradf/table.html
<jjohansen> bjf: from what I gathered kslm doesn't do atop functionality yet "KSLM which may add similar capabilities to the kernel but in a  more elegant way"
<jjohansen> bjf: from looking around I am not sure it does anything yet, I've asked SpamapS if he has anymore info
<bjf> jjohansen, from the comment on the mailing list and the lack of other information, it's vaporware
<jjohansen> yeah, that is my impression
<bjf> JFo, is there a wiki page with your "standard replies"?
<JFo> there isn't one with the kernel specific ones yet
<JFo> there is for regular bug comments
<JFo> but I assume you want the kernel specific ones
<bjf> JFo, ack
<manjo> sconklin, he is deafend 
<JFo> actually, I seem to recall there being one in KernelTeam bjf
<sconklin> manjo: no biggie. 
<JFo> I remember ogasawara pointing me to it
<bjf> JFo, i'll hunt a bit
<ogasawara> lemme dig it up, just a sec
 * manjo gets some coffee
<sconklin> JFo: I've seen a bunch of "Pulse audio crashes when I play something" and "PA crashes when I configure inputs for recording" bugs lately - there are patches for some of those in the pile that's waiting in stable, which will get queued after the next security update for Lucid.
<JFo> excellent
<JFo> thanks for the heads up sconklin 
<sconklin> it'll be a couple of weeks at least until they hit preproposed
<sconklin> possibly less
<ogasawara> bjf: https://wiki.ubuntu.com/Bugs/Responses but I don't think that has our kernel stock replies listed
<tgardner> amitk, is there a Freenode ARM channel?
<ogra> tgardner, bing it to the sprint and we'll get the board running maverick :)
<ogra> *bring even
<tgardner> ogra, I've got the Lucid image on SD, but can't figure out how to get it to boot it. 
<amitk> tgardner: #ubuntu-arm, #armlinux, #linaro
<amitk> take your pick
<tgardner> amitk, ack
<ogra> tgardner, lucid only includes bootloader binaries for bagelboards
<ogra> *beagle ... (they dont have a hole :P )
<ogra> tgardner, its likely that you need another bootloader binary 
<bjf> ogra, bagelboards, if they don't boot you can eat em
<tgardner> ogra, this gizmo has x-boot and u-boot, though I don't know what is actually installed
<ogra> tgardner, so you end up in a serial u-boot prompt if you fire it up ?
<tgardner> ogra, nope, its got a 2.6.28 kernel that brings up X. 
<ogra> hmm
<tgardner> using on-board flash that came with it pre-programmed
<ogra> well, you should see the boot process on the serial console somehow
<tgardner> ogra, I don't have the serial adapter, Loic is bringing it
<ogra> and usually u-boot has an option to stop the boot so you can input bootloader cmds
<ogra> ah
<ogra> yeah, without it gets tricky
<tgardner> ogra, the monitor goes white until too late. by then the kernel has booted.
<ogra> i'm hoping linaro finds a way to add framebuffer console support to u-boot some day
 * ogra hates serial consoles with passion
<tgardner> ogra, yeah, this one requires the usual square pin header
<ogra> ah, i'll have mine with me 
 * apw notes that * psurbhi is now known as csurbhi-afk
<bjf> JFo, ogasawara https://wiki.ubuntu.com/Kernel/BugTriage/Responses
<JFo> awesoem, thanks bj
<JFo> sigh
<JFo> bjf that is
<JFo> I am not a keyboard cowboy today\
<JFo> see ^
<bjf> JFo, i just worked bug 494476 a bit
<ubot2> Launchpad bug 494476 in linux (Ubuntu) ""Smbd","kjournald2" and "rsync" blocked for more than 120 seconds while using ext4. (affects: 5) (heat: 32)" [Medium,Incomplete] https://launchpad.net/bugs/494476
<ogasawara> smb: can you refresh my memory...when sending a patch to stable, should I CC everyone who signed off on the patch or just CC the maintainer?
<ogasawara> smb: I'm basically looking at upstream commit 68f194e027ecfbbc8d5515bc40787e542eed59e9 for bug 544740
<ubot2> Launchpad bug 544740 in linux (Ubuntu Lucid) (and 1 other project) "fix for iSight cameras not being recognized (affects: 3) (heat: 20)" [Medium,Triaged] https://launchpad.net/bugs/544740
<JFo> that is an interesting bug bjf
<ogasawara> smb: and I assume stable is still accepting patches for 2.6.32.y?
<smb> ogasawara, I usually cc all on sob
<smb> ogasawara, Yes, still open. Usually if it applies to all in stable it gets applied to all. Currently .32, .33 and .34
<smb> Not sure how long .33 goes on
<ogasawara> smb: cool.  yah my main concern is .32 for Lucid
<smb> ogasawara, As it would be mine. :)
<bjf> cnd, ping
<tseliot> apw: do we have a kernel 2.6.35 without maverick's patches in the mainline repository?
<apw> we have 2.6.35-rcN in there yes
<tseliot> I'm asking because I can't find any: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<apw> tseliot, look to be there to me
<tseliot> apw: I can see v2.6.35-rc5-maverick
<apw> thats the one yes
<tseliot> apw: but isn't that based on maverick's tree?
 * smb sees a faq question coming up
<tseliot> yes, I know that mainline kernels are supposed to come from upstream
<apw> smb, its already in the faq
<apw> tseliot, that is the release from which the configuration came
<smb> apw, I know. I should have probably said sees the pointer to faw coming
<tseliot> oh, "Why do mainline kernel builds have a -<series> suffix?"
<apw> heheh yeah
 * manjo getting lunch will be back soon
<tseliot> my sight is not good when my blood pressure is low, sorry
<smb> tseliot, No worries. Being a bit silly which I attribute to the heat
<tseliot> it's really too hot here in Italy
<smb> Same here in Germany
<apw> tseliot, whats the temp today?  is a nice 20c here
<tseliot> lucky you, it's more than 32Â° here...
<tseliot> and it's humid
<smb> apw, In the sun it seems to be near 40 here
<tseliot> I heard they have 40Â° in Venice...
<smb> But 34 is probably more realistic
 * apw likes the .uk
 * smb will ask again when apw is drowning in rain
<tseliot> apw: in what part of the UK?
 * bjf notes it is currently 17 C here in portland
 * ogra is envious
<tseliot> Portland - Oregon?
<bjf> tseliot, yes
<apw> smb, indeed :)  tseliot in london near wimbledon tennis
<tseliot> ah
<tseliot> is Portland as rainy as London (I've never been to London or to the UK)
<tseliot> ?
<bjf> tseliot, we have had a *lot* of rain this last 12 months
<ogra> if you want to see real rain go to bergen in norway
<tseliot> I noticed that when I visited Portland in January
<ogra> they have umbrella vending machines on every corner
<tseliot> hehe
 * tseliot reboots
 * smb thinks he did enough damage for today and relocates somewhere closer to cool drinks
 * jjohansen nees to run an errand for 30 min
<ogasawara> JFo: I just noticed a small typo in the KernelBugListTop50.py script which I think is preventing the Won't Fix bugs from showing up under the Closed Bugs section on the web page
<JFo> hmm, I hadn't even noticed
<ogasawara> JFo: line 217, there's as bit to check bug_task.status == "Won't Fix "
<JFo> ah the space
<ogasawara> JFo: yep
<ogasawara> JFo: I'd fix it myself, but I don't have permissions to commit it to the canonical-qa-tracking tree
<JFo> k, no sweat
<JFo> ogasawara, fixed
<ogasawara> JFo: sweet, thanks
<JFo> np
<JFo> may take a bit for it to pull and run
<jjohansen> bjf: just got confirmation that KSLM is pie in the sky vaporware atm
<bjf> jjohansen, nice!
<Keybuk> People who include the mouse cursor in screenshots should be killed
<Keybuk> *glares at cking*
<apw> ogasawara, are you looking at bug#589123
<ogasawara> apw: I was just digging into that, but it seems it's dependent on addition config options
<apw> ogasawara, ok i'll move on
<tgardner> Keybuk, I sent a merge request for ureadahead. did I get it right this time?
<Keybuk> tgardner: will look later
<Keybuk> oh, no, it's right in front of me
<Keybuk> yes, that looks right :p
<apw> ogasawara, so this top 50, i think we want to elide the closed bugs from the top table now don't we
<tgardner> Keybuk, how do I test it? I installed an updated package and rebooted, but the trace buffer size is still 1408. Can I exercize ureadahead without rebooting?
<ogasawara> apw: I thought the original consensus was to keep them there, but it's an easy tweak to omit them
<apw> i th
<Keybuk> tgardner: sure, just run ureadahead
<Keybuk> ;)
<Keybuk> w/ --force-trace etc.
<ogasawara> apw: I prefer them not showing at the top as they're displayed at the bottom as closed anyways
<apw> ogasawara, it not clear quite how we can count the active ones if the closed ones are in the top
<Keybuk> I think 1408 kB is the default
<Keybuk> wing-commander scott% cat /sys/kernel/debug/tracing/buffer_size_kb 
<Keybuk> 7 (expanded: 1408)
<Keybuk> no idea what that expanded stuff means
<Keybuk> probably the minimum size ~1.5MB
<jbarnes> arg
<jbarnes> make install from my kernel tree *still* doesn't work in 10.04
<tgardner> Keybuk, well, regardless of what the initial value should be, ureadahead appears to be restoring it.
<Keybuk> cool
<Keybuk> it should
<Keybuk> it always used to, until I deleted that code ;-)
<tgardner> Keybuk, shall I upload it again for Lucid?
<Keybuk> for lucid, I'll be uploading ureadahead2 soon enough
<tgardner> Keybuk, just to be clear, ureadahead2 is for Maverick only?
<Keybuk> yes
<apw> jbarnes, did we break you ?
<jbarnes> apw: yeah I think it worked briefly
<jbarnes> but somehow /sbin/installkernel lost its mkinitramfs and update-grub calls
<tgardner> apw, debian commonization?
<apw> tgardner, not sure we even supply that file
<apw> nope its part of debianutils
<tgardner> oh, I thought it was part of post-init
<apw> tgardner, yep we do it there as well for our kernels
 * tgardner is feeling stupid, must need lunch.
<apw> jbarnes, seems to be a direct sync from debian, so i guess they are borked too
<jbarnes> yeah maybe, I haven't tried regular debian
<jbarnes> maybe you should use the fedora bits :)
<apw> jbarnes, heh thanks
<ogasawara> JFo: sent you email with a patch to the KernelBugListTop50.py script to omit showing the closed bugs at the top, since we already display them at the bottom
<JFo> cool, thank you
<apw> JFo, so how is the bug 'hours' going ?
<apw> are we going to get stats like we do for normal bug days ?
<apw> with little up and down arrows ?
<JFo> hmm, I didn't set that up for this, but I should get that going
<JFo> I actually forgot all about it
<JFo> haven't been doing it for the Bug Days either
 * JFo fail
<apw> JFo, ogasawara, btw currently 'Won't Fix' is not a closed state ... which is is
<ogasawara> apw: it's a closed state, should be fixed with the patch I just sent JFo
<apw> ogasawara, cool thanks
 * apw has hit 5 at least ... in two hours ... hrmph
<ogasawara> JFo: I'd found one other place where there was an additional whitespace inserted
<JFo> k
<apw> JFo, does that mean its too late to get the before numbers ?
<JFo> apw, most likely
<JFo> the only thing that could be possible...
<JFo> one sec.. let me check something
<apw> JFo, it nice to be able to see if anyone bothered
<ogasawara> JFo: it might be possible to extract the before numbers by looking at http://qa.ubuntu.com/reports/jfo/kernel-buglist-Top50-archive/kernel-buglist-2010-07-13.html
<JFo> yep was just looking at that
<jjohansen> -> lunch
<sabdfl> hello all
<sabdfl> who's the right person to look into https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/554099
<ubot2> Launchpad bug 554099 in linux (Ubuntu Maverick) (and 3 other projects) "[PATCH] Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken in 10.04 (affects: 45) (dups: 4) (heat: 274)" [High,Confirmed]
<sabdfl> common 3G device that doesn't work with lucid but needs to
<sabdfl> pgraner: ^?
<bjf> jfo, lets get this bug ^ on our top 50 and i'll at least start looking at it
<bjf> sabdfl, that ok?
<JFo> yep, sorry, was off reading the bug
<JFo> it will be added, chatting with pgraner about it now
<bjf> JFo, sabdfl looks like there are patches attached the bug, i'll look at them
<JFo> thanks bjf 
<JFo> sabdfl, I've made pgraner aware of the issue. He was taking care of an errand before travel this week.
<JFo> I have added the bug to our "hot list"
<JFo> bjf, looks like it is no issue for MAverick
<bjf> JFo, ack, though i'd like to see more testing there to be sure
<JFo> I agree
<JFo> tgardner, you around?
<tgardner> JFo, yo
<JFo> any experience with gobi_loader?
<tgardner> nope
<JFo> per the bug mentioned by sabdfl above
<JFo> hmmm
<tgardner> looking
<JFo> thank you
<JFo> :)
<tgardner> JFo, looks like smb has already been working on the Lucid solution via LBM. bug #592046
<ubot2> Launchpad bug 592046 in linux-backports-modules-2.6.32 (Ubuntu Lucid) (and 3 other projects) "Lenovo x201 WWAN module in Lucid kernel (dup-of: 554099)" [Wishlist,In progress] https://launchpad.net/bugs/592046
<ubot2> Launchpad bug 554099 in linux (Ubuntu Maverick) (and 3 other projects) "[PATCH] Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken in 10.04 (affects: 45) (dups: 4) (heat: 274)" [High,Confirmed] https://launchpad.net/bugs/554099
<JFo> ah, great news
 * JFo loads those bugs
<JFo> or rather that bug, since I have the other open already
<JFo> ah, now I remember why this is familiar
<tgardner> JFo, I suggest dropping a note to smb requesting that he git 'er done.
<JFo> I was just thinking that
<bjf> JFo, i/we need to get with smb and get the bug updated (the one sabdfl pointed at)
<bjf> :-)
<JFo> tgardner, do you think it worthwhile to copy over smb's request for testing?
<JFo> bjf, you read my mind :)
<tgardner> JFo, couldn't hurt
<JFo> k, will do
<bjf> JFo, tgardner if this is something that has lagged because of smb's load, i'll work with him to get 'er done
<tgardner> bjf, I'm sure he won't mind
 * smb get red ears
<smb> tgardner, The request itself had been dropped as the customer in question moved to a different hw but I have the patches prepared (but not tested)
<jbarnes> apw: I'll trade you fixes: patch for fdo bug #28739 for a fix to installkernel :)
<ubot2> Launchpad bug 28739 in mythplugins (Ubuntu) "--enable-exif (heat: 2)" [Medium,Fix released] https://launchpad.net/bugs/28739
<jbarnes> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/578673 is the corresponding lp bug
<ubot2> Launchpad bug 578673 in linux (Ubuntu) "[arrandale] Resume doesn't work on a Latitude E6410 (affects: 25) (dups: 2) (heat: 143)" [Critical,Confirmed]
<bjf> smb, read the scrollback for another related bug sabdfl pointed us at
<JFo> smb, is that package still there?
<tgardner> smb, sounds like at least one _big_ customer is still interested.
<smb> JFo, I did not delete it
<JFo> ah good
<JFo> I have asked for further testing of it in the related bug
<JFo> if that makes sense to you
<smb> JFo, tgardner One thing to note is that there is no firmware which is required
<JFo> I saw that it seems to work in Maverick
<JFo> is that due to these patches?
<JFo> or rather it seems to work
<smb> JFo, The kernel parts have gone upstream
<JFo> bjf and I agree that more testing is probably warranted
<JFo> cool
<smb> JFo, But there is the fw-loader and the fw
<JFo> I see
<smb> mjg59, has done the loader but cannot provide fw
<JFo> due to licensing
<smb> as that is qualcom licensed
<smb> Yeah
<tgardner> smb, we could always drop it into the non-free package
<smb> tgardner, The advice I've seen was to extract from win packages. So maybe fw cutter
<mjg59> The firmware is not only non-free, it's non-distributable
<JFo> ugh
<mjg59> The license on the firmware packages expressly prohibits distribution
<JFo> do we know someone at Qualcomm we can yell at? :-) j/k
<mjg59> I've yelled at everyone in Qualcomm I've found without any joy
<JFo> tgardner, is that an option?
<JFo> or would we open ourselves to issues
<tgardner> smb, well then, perhaps a README with instructions for how to get the firmware.
<tgardner> why does Maverick work ?
<JFo> good question
<JFo> hence my thought that more testing is needed
<smb> tgardner, Yes I hope I already copied the original one from mjg59 into the packaging
<smb> But it was a quick job
<smb> I wanted to know first whether the packaging in general works
<mjg59> I suspect Maverick works because the tester rebooted from Windows
<JFo> ah, good point
<tgardner> ah, the 'ol softboot ...
<JFo> this is why i vaguely recalled this issue
<mjg59> Using Windows as a glorified firmware loader is obviously an option, but a kind of expensive one
<JFo> and not at all desirable
<JFo> :)
 * JFo starts getting ready for his classroom session
<pgraner> tgardner, the bug sabdfl pointed out said it worked in Karmic, how was that the case if the firmware is a legal nightmare?
<mjg59> I know that there's several companies who have contracts with Qualcomm to distribute the firmware internally
<tgardner> pgraner, well, we did do a bunch of firmware cleanup
<mjg59> Pre-Lucid,they'd just need to drop in the firmware and things would work. In Lucid, the kernel is broken
<pgraner> tgardner, I did that during Jaunty/Karmic and I don't remember that one, and if we had it in linux-firmware, we moved it to -non-free
<tgardner> pgraner, mjg59 points out that the driver in Lucid is just broken
<pgraner> mjg59, ture, the reported didn't mention if they cut the fw and dropped it in
<pgraner> tgardner, we should look in non-free and see if its there just in case
<tgardner> pgraner, doesn't look like it is in non-free
<pgraner> tgardner, ok then my guess is that they cut the fw and dropped it in
<tgardner> pgraner, wou'dn't be surprised
<pgraner> there goes the neighborhood... jcastro just arrived
<jcastro> I am trying to figure out the main developer of a certain feature in the kernel (fscache), I have deduced from the upstream mailing list that it's probably David Howells @ Red Hat. Is there a way I can find out for sure without checking out the entire kernel?
<jcastro> also, hi pgraner, good to see you too. :D
<tgardner> jcastro, FS-CACHE: LOCAL CACHING FOR NETWORK FILESYSTEMS
<tgardner> M:      David Howells <dhowells@redhat.com>
<tgardner> L:      linux-cachefs@redhat.com
<tgardner> S:      Supported
<tgardner> F:      Documentation/filesystems/caching/
<tgardner> F:      fs/fscache/
<tgardner> F:      include/linux/fscache*.h
<jcastro> tgardner: thank you very much!
<simar> Good Luck JFo , for the current session :)
<JFo> thanks :)
<pgraner> just  like a community guy drop in here only when they need something....
<pgraner> jcastro, ^^^^^^^^^
<jcastro> pgraner: I am waiting on your guy to finish the docs so I can finish my forum work item. :p
<JFo> I'm headed to #ubuntu-classroom for those who'd like to join me
<JFo> jcastro, :-P
<simar> cheers for JFo !!!
<bjf> JFo, i love a good train wreck :-P
<JFo> heh
<achiang> jcastro: if you're trying to avoid pulling the entire git tree, you can just look online http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree
<sabdfl> bjf: thanks much, sorry was afk
<bjf> sabdfl, no prob. looks like smb already has most of a solution
<pgraner> sabdfl, looks like we have a patch, the issue with this card is the firmware, it is non-redistributable :-(
<sabdfl> mjg59: we could try reach Qualcomm through another route
<sabdfl> are there a whole bunch of different firmwares from QC we should ask about, or just this one?
<mjg59> There's a generic GSM firmware, a generic CDMA firmware and then at least 10 carrier-specific firmwares
<solarion> sabdfl: hey
<ogasawara> JFo: good session
<JFo> thanks ogasawara :)
<bjf> JFo, good job
<JFo> thank you bjf
<pgraner> JFo, good one
<JFo> thanks pgraner 
<JFo> hope i covered the items clearly
<sconklin> yeah JFo I caught the end, it was good
<JFo> cool, thanks sconklin 
<pgraner> jjohansen, any news on AA upstreaming?
<jjohansen> pgraner: just running checkpatch on my patches
<jjohansen> ended up doing a bug fix yesterday
<pgraner> jjohansen, cool, ping me when you send it upstream pls
<jjohansen> pgraner: do you want a CC on the header email?
<pgraner> jjohansen, whatever is easiest for you
<jjohansen> pgraner: ack
<pgraner> jjohansen, thanks
 * pgraner is outta here for the day, gotta pack travel tomorrow... later
<JFo> same here
<JFo> see you chaps
 * manjo heads out to get some exercise 
#ubuntu-kernel 2010-07-15
<penguin42> I'm seeing black screen off a boot of the maverick 2.6.35-7 on a machine just upgraded from Lucid (i7 with Radeon 4350 graphics), if I remove the load_video and set gfxpayload=keep  from the grub text I at least see a panic (related to interrupt mapping) - should removing the load_video and set gfxpayload=keep be safe?
<penguin42> failsafe is just as broke
<penguin42> works with nointremap
<achiang> https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/030995.html
<achiang> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/605614
<ubot2> Launchpad bug 605614 in grub2 (Ubuntu) "Maverick's grub-pc package (1.98+20100710-1ubuntu1) causes unbootable system (affects: 2) (heat: 12)" [Undecided,New]
<penguin42> achiang: It's not just the gfxpayload though, taking those out gets me a panic about interrupt remapping
 * penguin42 is just writing a bug report
<achiang> penguin42: a stack trace would help
<penguin42> achiang: Just give me 3 mins to finish the bug report - it includes a lot of detail
<achiang> heh, ok. /me was just drive-by triaging, i'm actually in the middle of something else.
 * penguin42 taps flippers as he waits for launchpad
<penguin42> ok, what have I missed on bug 605686
<ubot2> Launchpad bug 605686 in linux (Ubuntu) "[maverick] noioremap needed - Blocked an interrupt request due to source-id verificiation failure (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/605686
<achiang> penguin42: can you reproduce that with upstream?
<penguin42> achiang: Havne't tried yet, and I'm about to go to bed (it's 2:20am :-) )   - but will upstream be much different from a maverick 2.6.35 ?
<achiang> penguin42: not that much different, but i was going to suggest a bisect. the kernel shouldn't be panicing like that
<penguin42> achiang: Well, a bit of googling suggests it could always be broken bios data structures - although I thought this was a pretty popular mbd
<achiang> penguin42: are you running some unreleased bios?
<penguin42> no
<achiang> the stuff in your DMI table looks a little funky
<achiang> dmi.chassis.vendor: To Be Filled By O.E.M.
<penguin42> achiang: That's normal ; that's what you get if you buy a motherboard rather than buying a whole machine
<achiang> penguin42: i mean, even if your bios is broken, 2.6.32 worked, right? so that means 2.6.35 shouldn't be choking
<penguin42> yeh except they've turned on a new feature in .35 that wasn't previously used
<penguin42> see http://old.nabble.com/-PATCH-1-2---Maverick--UBUNTU%3A--Config--Enable-CONFIG_INTR_REMAP%3Dy-to28966711.html#a28971597
<achiang> right, so maybe the kernel needs a quirk for your bios
<penguin42> yeh maybe; of course the interesting question is what % of bios actually work!
<achiang> i'd expect that to work well on any server class machine. on a home machine... not so much
<penguin42> why?
<achiang> because as you've discovered, it needs the bios to be written correctly
<penguin42> nod; you're hoping that the server ones are better written - that's being optimistic!
<achiang> in my experience, server BIOSes are written by actual engineers. PC BIOSes seem to be a collection of random bits gathered by Arecibo and shoved into the motherboard
<penguin42> hehe
<achiang> in my past life, i was a kernel developer on server class machines, and had quite a lot of interface with the firmware teams
<achiang> suffice to say, when i occasionally talked to the laptop guys, i didn't get the same level of confidence from their bios guys
<penguin42> nod
<achiang> penguin42: anyhow, if you have the time to do a bisect, i think that'd be great. otherwise, your bug report looks fine
<penguin42> achiang: I'm fairly sure it's the intremap - it was turned on 23rd June according to that series of posts
<achiang> penguin42: right, i mean to say, there's probably something wrong in the intremap code; a bisect will help figure out what it is
<penguin42> that assumes that there is a working version in the remap case though - I'm not sure there is
<jjohansen-afk> be back on later
<penguin42> right, anyway, it's 2:36am and time for bed, I can look forward to figuring out all the other alpha fun tomorrow
<penguin42> oops - just spotted typo in title of that bug - did say noioremap, changed to nointremap
<penguin42> right, bed
<smb> morning
<cking_> morning
<cooloney> smb: cking_ morning
<cooloney> smb: GrueMaster tested security updates for fsl-imx51. boots fine
<smb> cooloney, Yes, saw his email this morning
<smb> cooloney, thanks to all guys testing
<cooloney> smb: no problem, man
<kraut> moin
<insider> please help,  i use Ubuntu 9.10 with splash screen off and when i boot i see this message "udevd [1815] CONFIG_SYSF_DEPRECATED option udev ..." how to fix it?
<insider> without reinstalling system because it works fine
<insider> Linux 2.6.34 #1 SMP Thu Jul 8 19:41:21 EDT 2010 i686 GNU/Linux
<apw> insider, those are just warnings arn't they
<insider> yes but they slow down my booting speed
<apw> they indicate your kernel and userspace are out of sync, which they are as you are not running the matched kernel
<smb> I would think those are. And probably unavoidable with a newer kernel
<insider> how can i disable CONFIG_SYSFS_DEPRECATED option?
<insider> would it cause more problems?
<apw> insider, you could try that, no idea if it would work not something i've tried
<apw> how much time are you losing here, about .5s totoal ?
<insider> about 15 seconds
<apw> how many of those messages are you getting printed in totoal ?
<apw> it would have to be a heck of a lot to account for 15s of boot time
<insider> my laptop is Fujitsu V5535 with 2Gb Ram, Intel core 2 Duo 2ghz and boot time is 1.5-2 minutes
<apw> how many of those messages are you getting printed in totoal ?
<insider> i think they appear 2 or 3 times not less then 2
<apw> printing 3 messages is not adding 15s to your boot
<insider> previous version of Ubuntu 9.10 that i used booted at 45 seconds
<apw> insider, so can you pastbin the dmesg of the slower boot
<insider> can you explain how to do it or where to find logs?
<insider> i'm newbie
<apw> type 'dmesg > FILE' to collect the data (in a terminal window)
<insider> ok
<apw> and then use pastebinit to send it up to the pastebin
<insider> wht is pastebinit?
<insider> i haven't it installed
<insider> i've already read
<apw> pastebinit is a command to send a file to a pastebin and tell you the url to paste in here
<apw> so that we can see the file contents
<smb> or use http://pastebin.com/ ?
<insider> thanks i'm installing it
<insider> http://pastebin.com/R2LUWbBK
<apw> insider, there is exactly one of those messages reported by the kernel
<apw> insider, i assume this is your own configuration as the dmesg is lacking the normal timestamps which might allow one to find out whether it is taking a long time and which bit
<apw> [    0.000000] Initializing cgroup subsys cpuset
<apw> from my dmesg ^^
<insider> strange
<apw> why are you running a 2.6.34 kernel anyhow?
<insider> i upgraded it from 2.6.30
<insider> how to configure dmesg to show time?
<apw> CONFIG_PRINTK_TIME=y
<insider> thanks
<apw> insider, why are you needing to run a custom kernel at all ?
<smb> 2.6.30 was never a release
<smb> Jaunty: 2.6.28
<smb> Karmic: 2.6.31
<apw> what userspace are you running all these on, as 2.6.30 was never a release ...
<apw> heh jinz
<apw> jinx
<insider> 2.6.30.9
<insider> intrepid
<smb> That was 2.6.27
<apw> you are running a kernel which is newer than lucid on an intrepid userspace ... no wonder its having compatibility issues
<apw> insider, is there some reason you cannot just update the whole thing ?
<insider> now i'm running karmic
<insider> apw: i updated system
<insider> apt-get update && apt-get upgrade won't help
<apw> upgrade-manager ?
<insider> didn't try
<insider> apw: where to past it? 
<apw> past ?
<insider> paste
<apw> to paste what ?
<insider> this command upgrade-manager or it is not a command i misunderstood you
<apw> sorry its update-manager ... normally use the menu when i use it
<insider> only skype updates)))
<apw> insider, what are you trying to do by running these kernels, are you just trying to get later stuff so a full update is acceptable
<apw> if so you can use update-manager -d which will offer you the later releases as upgrade destinations
<apw> without -d it wil only update your current release
<insider> will try now
<apw> if you need to keep the older release userspace but want thekernel i would suggest taking the kernels from the later releases directly instrad of making your own
<insider> thanks for help going to reboot
<amitk> any way to exclude a certain path from a git-diff ? I'm doing 'git diff --dirstat  v2.6.34..' and want to exclude the ubuntu/ directory
<ikepanhc> want to know too.... listening
<apw> amitk, don't know of any way to do that inversion no
<amitk> bummer
<apw> as file lists can be directories would something like
<apw> git diff --dirstat  v2.6.34.. -- `ls -d | grep -v ubuntu`
<apw> approximate what you wanted
<apw> ls -1d strictly
<apw> (thats a one)
<apw> amitk, ^^
<amitk> apw: 'grep -v ubuntu' takes away the offending directories from display but not from the end result (% of code in various directories among changes I care about).
<apw> amitk, not from the result, i am using the directories as file limits so it should onlly report the diff for the directories not ubuntu and same with the overall results
<amitk> apw: doesn't seem to work. http://paste.ubuntu.com/463985/
<apw> git diff --dirstat v2.6.34.. -- `ls -1d * | grep -v ubuntu` 
<apw> try that instead
<apw> amitk, ^^
<amitk> apw: yeah, that seems more sensible.
<apw> git diff --dirstat v2.6.34.. -- `ls -1 | grep -v ubuntu` 
<apw> or indeed that probabally works too
<apw> yeah the last is the simplest
<amitk> apw: yup, that seems to DTRT
<amitk> tgardner: are we there yet? :) (IGEPv2)
<tgardner> amitk, not quite. I at least git it to do something different on boot but I don't have the right serial cable. Loic is bringing one to Prague
<tgardner> amitk, so, what else do we need for omap4 in mainline Maverick other then the config options?
<amitk> tgardner: that itself will enable omap4 + one board based on omap4 (sdp). But Bryan will pull 1-2 patches from the tree slated for 2.6.36 merge to add support for the panda board that ARM team already has access to
<amitk> that = applying my config patch
<tgardner> amitk, cool. will that be sufficient such that we can drop the ti-omap4 branch altogether?
<amitk> tgardner: :-D
<amitk> you're kidding right?
<tgardner> amitk, well, no.
<amitk> tgardner: that branch has over 700 non-mainlined patches.
<tgardner> we'll have 2 packages that both support omap4 ?
<tgardner> guess I was too naive
<ogra> FSVO *support*
<amitk> tgardner: yes, one that is the whole works (-omap4 only) and one that is mainline-only with multi-omap support (omap3 and 4) in a single binary
<apw> amitk, waht use if the multi-omap one if it doesn't work ?
<tgardner> amitk, *sigh* - you've just dashed my hopes. maybe next release?
<amitk> apw: it gets you the serial port on omap4
<apw> amitk, ahh i see
<amitk> and the same kernel gets you almost everything on omap3
<amitk> so one small step to show kernel consolidation
<amitk> tgardner: next release - hopefully a big chunk but not everything
<apw> akgraner, hey you about ?
<akgraner> apw, I am - what's up?
<apw> akgraner, looks like the wireless link into your house might be sick
<akgraner> hmmm - let me investigate - brb
<apw> akgraner, your other link must be up
<akgraner> it is  - I'm online  ;-)
<apw> akgraner, could you try and telnet to hellhawk.shadowen.org for me from you rmachine
<apw> then we can find out the IP addy of the link and see if its avail both ways
<penguin42> does anyone understand the check_timer interrupt checking code?
 * penguin42 is wondering if it could just disable interrupt remapping rather than panicing, there appears to be an iommu_disable_intr_remapping that sounds promissing
<tgardner> penguin42, have you seen https://launchpad.net/bugs/605686 ? Same problem?
<ubot2> Launchpad bug 605686 in linux (Ubuntu) "[maverick] nointremap needed - Blocked an interrupt request due to source-id verificiation failure (affects: 1) (heat: 6)" [Undecided,New]
<penguin42> tgardner: Yeh, that's my bug
<penguin42> and my mail :-)
<penguin42> tgardner: But I was just wondering if it could actually fall back rather than panicing
<tgardner> penguin42, ah, you're cloaked so its hard to tell.
<penguin42> I am?
<penguin42> hmm I should fix that
<tgardner> penguin42, I'll bug Intel about this driver. Its quite complex.
<penguin42> tgardner: Yeh, the interrupt handling on modern machines is scarily complex
<cnd> http://git.kernel.org/?p=linux/kernel/git/acme/linux-2.6.git;a=shortlog;h=refs/heads/perf/core
<akgraner> apw, you around?  
<apw> akgraner, yep talking to pete
<akgraner> ok the server is back online now
<apw> akgraner, ok thanks ... will check it out
<ogasawara> cking_: your work item to investigate intel graphics drivers on EFI, can I mark that done?
<ogasawara> cking_: I saw no response from the email you sent
<lag> akgraner: Do you know what the issue was?
<akgraner> lag, I don't know exactly what happens with that particular server - I just know what to do when it hangs :-/   
<lag> akgraner: But it happened to both servers? Unless there is a sever in between them?
<akgraner> lag, you'll have to ask pgraner about that when he is online again... sorry :-/
<lag> No worries :)
<lag> Thanks for sorting it in any case
<akgraner> lag, I'm the NTEU :-)  but happy to help when and where I can.
<lag> :-)
<tgardner> ogasawara, https://launchpad.net/bugs/605686
<ubot2> Launchpad bug 605686 in linux (Ubuntu) "[maverick] nointremap needed - Blocked an interrupt request due to source-id verificiation failure (affects: 1) (heat: 6)" [Undecided,New]
<penguin42> Sanity check; I'm following https://help.ubuntu.com/community/Kernel/Compile  ; if I've got the source archive and want to patch it then do I just patch the directory that's checked out there - what do I need to do to make sure it gets a name unique from the standard ubuntu kernel version?
<penguin42> will the AUTOBUILD do that ?
<tgardner> penguin42, edit the debian.master/changelog and add '.my_version_here' to the stuff in parens
<penguin42> ah ok, thanks
<tgardner> penguin42, don't forget to rerun the 'clean' target afterwards
<penguin42> tgardner: OK, so do whatever edits I wanted, update the changelog, then do the clean thing and then the binary-whatever ?
<tgardner> penguin42, sounds right
<penguin42> ok, thanks
<tgardner> mpoirier,  http://cdimage.ubuntu.com/ports/releases/10.04/release/ubuntu-10.04-server-armel+omap.img
 * manjo getting lunch will be back soon
<jjohansen> mpoirier: move ureadahead.conf to ureadahead.conf.disabled
<mpoirier> jjohansen: fantastic thanks.
<jjohansen> -> Lunch
<pgraner> ogasawara, ping
<ogasawara> pgraner: pong
<pgraner> ogasawara, thought you might like to keep an eye on this since you just rebased
<pgraner> ogasawara, https://bugzilla.kernel.org/show_bug.cgi?id=16401
<ubot2> pgraner: Error: Could not parse XML returned by bugzilla.kernel.org: The read operation timed out (https://bugzilla.kernel.org/xml.cgi?id=16401)
<pgraner> ogasawara, ext3 corruption at random 
<ogasawara> ogasawara: thanks, I'll put it on my radar.  bugzilla seems to not want to load at the moment
<pgraner> ogasawara, yea I caught it on the ext upstream list
 * ogasawara lunch
<akgraner> bjf, ping
<bjf> akgraner, pong
 * penguin42 wonders where dch put my changelog entry
 * penguin42 does a 'wow - it boots'
 * penguin42 attaches a gratuitous hack patch to bug 605686 - it seems to work, but I wouldn't put much more confidence in it
<ubot2> Launchpad bug 605686 in linux (Ubuntu) "[maverick] nointremap needed - Blocked an interrupt request due to source-id verificiation failure (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/605686
<jjohansen> running an errand
<LLStarks> ogasawara, maverick kernel now has built-in ndiswrapper modules, right?
<ogasawara> LLStarks: it's not built-in, enabled as a module
<ogasawara> LLStarks: config.common.ubuntu:2750:CONFIG_NDISWRAPPER=m
<LLStarks> thanks ogaswara, still need to pick juliank's brain about his dkms package
#ubuntu-kernel 2010-07-16
<kuyanatan> can someone help me? have a computer that freezes when waking from sleep, does not respond. only does this when i close laptop lid, not choose suspend from the menu.
<kuyanatan> someone from ubuntu-beginners said i should come here. is this the wrong place for this problem?
<kuyanatan> ...
<paultag> cnd: poke :)
<johanbr> kuyanatan, see https://wiki.ubuntu.com/DebuggingKernelSuspend for instructions on debugging suspend/resume bugs
<kuyanatan> johanbr: thanks!
<johanbr> you're welcome
<johanbr> when you're done with those steps, you can either ask here or file a bug by doing "ubuntu-bug linux" (or both)
<kuyanatan> ok
<kuyanatan> thank you!
<johanbr> no problem :)
<cnd> paultag, hey, what's up?
<paultag> cnd: mind if I throw a PM your way?
<cnd> paultag, sure
<lag> apw: http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=commitdiff;h=652d0096e4cc7361db47b6efbebac28f7663bfc0
<kraut> moin
<apw> moin
<csurbhi> apw, morning!
<apw> morning
<cooloney> apw: csurbhi morning
<cooloney> csurbhi: long time no see
<csurbhi> hie cooloney :)
 * apw waves manically
<csurbhi> cooloney, how are you doing?
<cooloney> csurbhi: good, we will meet in Prague, right?
<csurbhi> cooloney, yes, we will
<kermiac> I just noticed bug 606139 from a member of the VMware QA Team. I re-assigned to the "linux" package but thought I would mention it here too as it seemed important
<ubot2> Launchpad bug 606139 in linux (Ubuntu) "Request to disable vmwgfx driver in default config (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/606139
<ademmer> kamal: greetings! I stumbled upon your patch, fixing the broken ACPI backlight control for i915
<ademmer> kamal: do you know, when you could submit your patch to the upstream kernel?
<apw> ademmer, kamal is normally awake much later in the day
<ademmer> apw: which timezone is he in? thx for the info! :)
<cooloney> ademmer: i think kamal is based in CA, US
<ademmer> cooloney: thx!
<Daviey> Hi.. Has the flurry of e1000e patches from upstream landed in maverick yet?
<apw> Daviey, maverick is at v2.6.35-r5 if that helps
<apw> rc
<Daviey> ah, ha - perhaps! 
<cooloney> apw: one quick question, when will our M kernel be freezed?
<cooloney> we might got some big patches for ti-omap4 in Sep
<apw> *might* ?
<cooloney> yeah, their montly release
<cooloney> apw: September 16th, right? for kernel freeze
<apw> cooloney, yes 16th is the cut-off, though our freeze date will likely be 9th or 10th as we have to prepare them
<cooloney> apw: thx, i got it. so if we got about 200 patches before Sep 9th and we prepared the new ti-omap4 branch
<apw> upload them, wait for them to build, fix them, repeat
<cooloney> it is ok for mergeing right?
<apw> is what ok for merging where?
<apw> cooloney, ^^ ?
<cooloney> oh, merging into Maverick ti-omap4 tree. 
<cooloney> i am afraid that they will get us a big volumn patches just at our kernel freeze time.
<apw> as long as its tested before then i guess its ok, but its the mobile team who have to test them
<cooloney> or close to
<cooloney> yeah, thx. we will work on that. 
<apw> it would be better to get stuff much earler as you are making all the testing done at A3 and Beta pointless
<cooloney> apw: yeah, i am trying to push that. 
<cooloney> but bascially, their relese at the first half part of every month
<apw> so how many patches did we get this month
<cooloney> i was told there will be 200 at least for our .34 kernel
<apw> we need to get buy in from mobile that they are ok with it changing things that late i guess
<cooloney> but just one month later, we will move to .35 ti-omap4 kernel
<cooloney> so i don't wanna merge too many things,
<apw> have we had the july patches yet?
<cooloney> no
<apw> so we're not likely to get them in time are we
<cooloney> we got 200 more patches in July
<apw> we 'have got' or 'will get'
<cooloney> we are discussing these. 
<cooloney> actually they have 900 patches in July relese
<apw> but have they released the july release to us yet ?
<cooloney> and sebjan is helping to pick up some for our Ubuntu usage
<cooloney> apw: no, they released internally 
<cooloney> but sebjan is helping to pick up some and release for us
<apw> so the likelyhood is that the august from is not going to arrive in time then
<apw> august patch drop
<cooloney> i was told it will be 200
<cooloney> next month, August they will release a new branch based on .35
<cooloney> we have to redo lots of work 
<apw> right ... and then the september drop is the one you care about
<cooloney> and replace our current .34 branch
<cooloney> yeah, 
<cooloney> correct
<apw> and that isn't likely to be done in time 
<cooloney> because september drop is similar to this month
<cooloney> i think so
<apw> as they haven't got the july one out before the 16th
<cooloney> right.
<apw> if it doesn't make the 10th they'll have to wait till after release i suspect
<cooloney> exactly,
<apw> and you can fight the sru team to get it through :)
<cooloney> lol,
<cooloney> just wanna let them know the tight schedule
<apw> yep tell them the 9th
<cooloney> yeah, already told sebjan about that. 
<apw> that gives us a week to integrate and build them before we can no longer upload
<cooloney> but he is not sure about that
<cooloney> yeah, that will be perfect.
<apw> then they miss the release
<apw> time waits for no man
<cooloney> don't miss the perfect 10/10!!
<cooloney> apw: are you all set for the trip?
<apw> cooloney, 10/10>  yeah something like that
<apw> trip> heh not really, i've got my computers mostly ready to go, but nothing to wear at the moment
<apw> cooloney, how about you? 
<cooloney> apw: just exchanged some euros today.
<apw> cooloney, do they use euro in prahah ?
<apw> i thought it was crowns
<cking_> check crowns
<apw> czech crowns
<cking_> doh, yep
<cooloney> apw: yeah, we cannot exchange for that CZ currency in China
<cooloney> so euros is ok, 
<apw> oh what a pain that is for you
<cooloney> then we exchange euros to CZ there
<apw> mad .. not going to cost you a fortune no way
<cooloney> in their airport, maybe
<cooloney> but i was told, they also accept euros
<cooloney> as well as their own currency
<cooloney> how long is your flight then?
<apw> 1.5 hours or something
<apw> yours?  20 ?
<cooloney> 15 maybe, from shanghai to moscow
<cooloney> then moscow to there
<cooloney> but backwards it will be faster.
<apw> moscow ... wow
<cooloney> apw: hehe, why so exciting?
<cooloney> we were comrades before
<cooloney> RU and CN
<apw> dunno, one of those dangerous and exciting sounding places, one that i've yet to go to
<cooloney> yeah, transfer there is faster than transfer in westen europe hub
<apw> speak any russian ?
<cooloney> a little, my father and mother studied that when they are in high school.
<apw> handy if you get lost in the airport
<cooloney> Ð¢Ð¾Ð²Ð°ÑÐ¸Ñ
<cooloney> ok, apw and cking_ i gonna head out for dinner
<apw> see ya
<cooloney> see you this Sunday
<apw> yarg
 * apw lunches
 * apw_ works on the agenda for next week ...
<cking_> apw_, perhaps I should do a firmware test suite spot
<apw_> Sure why not. I am working on the page offline, so will add it here
<tseliot> mjg59: is it ok to set usbcore.autosuspend=1 when using recent kernels?
<apw_> TSELIOT isn't that something powertop recommends?
<tseliot> apw_: powertop says to enable autosuspend but it doesn't say how
<apw_> TSELIOT doesn't it print the command if you wait..  thought it did
<tseliot> apw_: it does that with other suggestions not with autospend though
<tseliot> autosuspend
<apw_> Hrmm ok... that's annoying
<tseliot> indeed
<cking1> hrm, laptop overheated :-(
<penguin42> if Apparmor loads a profile in Complain mode (apparmor_parser -Cr) should it change the behaviour of the application at all?
 * penguin42 has a chromium profile that breaks it even in complain
<apw_> Jjohansen ^^
<jdstrand> penguin42: it should not affect it, but the '-r' reloads it and that is not always what you want. I suggest doing 'apparmor_parser -R...' followed by 'apparmor_parser -Ca'
<jdstrand> penguin42: that is a full remove followed by add. you will have to restart chromium though
<penguin42> jdstrand: Hmm, closer but not quite - I don't get any fonts with it like that
<penguin42> but they reappear with -R
<jdstrand> that should not be happening
<jdstrand> penguin42: what does aa-status show?
<penguin42> jdstrand: Let me paste bin it
<penguin42> jdstrand: http://paste.ubuntu.com/464540/
<penguin42> jdstrand: I get the feeling chromium has an odd way of doing its sandboxes which is where the null-numbers come from
<jdstrand> penguin42: the null profiles do result from the sandboxes, but they are in complain mode anyway, so it shouldn't matter
<jdstrand> penguin42: does dmesg provide any output?
<jdstrand> (on the denial)
<penguin42> it gives a few moans; I'll pastebin them
<penguin42> jdstrand: http://paste.ubuntu.com/464546/
<penguin42> jdstrand: This is on 2.6.35-8, on Lucid I used to get a lot more moaning in complain mode, but it worked
<penguin42> mind you, there were some moans that I never got to the bottom why they were there
<penguin42> jdstrand: http://www.treblig.org/debug/usr.lib.chromium-browser.chromium-browser   is the profile
<jdstrand> penguin42: well, profiling with complain mode is different than profiling in enforcing. eg, in enforcing an actual denial will cause a different code path than a complain which didn't deny
<jdstrand> penguin42: anyhoo, I think we need jj to take a look. I don't see anything that should make chromium not work in complain mode
<penguin42> jdstrand: OK, thanks
<apw> bdmurray,you about ?
<komputes> Can someone please have a look at the following bug and suggest the next step to take. https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/605465
<ubot2> komputes: Error: Bug #605465 is private.
<komputes> ^ that is incorrect
<smb> Maybe just bug 605465
<ubot2> Launchpad bug 605465 in linux (Ubuntu) "Dell XPS M1330 CPU scales down to 800 MHz (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/605465
<komputes> that works
<apw> thats a common machine to be having issues ...
<smb> Generally the answer to force a certain frequency limit is no. Not automatically
<smb> Second it would be interesting to check what the current freq scaling parameters are when this happens
<smb> grep . /sys/devices/system/cpu/cpu?/cpufreq/*
<smb> Actually the above command done with sudo
<smb> Oh, I see this is in mycpuinfo
<smb> komputes, but from that file I cannot see the described problem.
<smb> komputes, We need some real indication on that problem. If you ask the reporter to run and collect the output of "sudo powertop -d -t30" while doing a tight loop like "while true; do false; done" in another terminal when he thinks he has the problem?
<komputes> smb: I will suggest this, thank you
<apw> cking1, about ?
<cking1> yep
<hyperair> what rc is 2.6.35-7 based off?
<apw> hyperair, thts a faq question :)
<hyperair> apw: hmm? and where's this faq?
<apw> https://wiki.ubuntu.com/Kernel/FAQ
<hyperair> ah cool thanks
<apw> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html
<apw> leads you to that link
<apw> hyperair, you can also tell from /proc/version_signature if it is booted
<hyperair> apw: yeah i just saw on the faq. thanks.
<apw> hyperair, heh the faq has been developed a lot recently to actually have some of the frequently asked questions in it :)
<apw> !faq
<ubot2> A list of common questions and answers about Ubuntu: http://help.ubuntu.com/community/CommonQuestions - Official documentation: http://help.ubuntu.com
<apw> hrm
<apw> !help
<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. :-)
<hyperair> lol
<hyperair> i think it's !faq is blah blah
<hyperair> but i'm not sure if it will change faq on other channels as well.
<apw> !kernel-faq is Common Kernel questions can be found here: https://wiki.ubuntu.com/Kernel/FAQ
<apw> it reported in on me to #ubuntu-irc for trying to talk to it ... sigh
<apw> !kernel-faq is Common Kernel questions can be found here: https://wiki.ubuntu.com/Kernel/FAQ
<komputes> smb: are you sure the command is powertop?
<smb> komputes, yes, why
<komputes> smb: I am unable to find that executable
<smb> komputes, Maybe install it?
<komputes> smb: package name?
<smb> powertop
<komputes> done, thx, wonder why it didn't propose it ;)
<apw> cause you used sudo ?
<komputes> apw: that would be it
<komputes> apw: smb: Could you guys suggest a kernel option to increase the delay Ubuntu waits to see the drives? 
<bryce2> jfo, bjf: if lp #567007 sounds like a useful launchpad feature, mind clicking 'Affects me too'?  The more people marked as it affects them, the more likely it'll be to get on the Launchpad team's planning list when work starts on search improvements
<ubot2> Launchpad bug 567007 in malone "User-specific default tag search parameters (affects: 1) (heat: 3)" [Low,Triaged] https://launchpad.net/bugs/567007
<smb> Hm, wasn't that root_delay= ? All other mount are being waited infinitely by mountall
<kees> komputes: kernel command-line for that (it's the initramfs scripts that parse it) is "rootdelay".  i.e. rootdelay=30 will wait 30 seconds for the root filesystem to become available.
 * ogasawara bails, back in a few hrs
<dupondje> [   34.007768] BUG: unable to handle kernel NULL pointer dereference at 00000000000003c0 => already reported ?
<jjohansen> dupondje: maybe, but that isn't enough information to know
<manjo> dupondje, could you paste bin dmesg ?
<akgraner> apw, ping
<dupondje> http://paste.ubuntu.com/464629/
<manjo> dupondje, is that a maverick kernel ? 
<dupondje> yea
<sconklin> ls
<sconklin> doh
<manjo> dupondje, might be a good idea to open a bug on that one 
<apw> akgraner, pong
<manjo> dupondje, ubuntu-bug -p linux 
<dupondje> https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/606244 => this seem to be related. As whith the kernel error, I get that issue also
<ubot2> Launchpad bug 606244 in libdrm (Ubuntu) "X doesn't find a screen and is not starting due a race condition (affects: 2) (heat: 12)" [Undecided,New]
<dupondje> without, everything works great
<akgraner> apw - remember when you said - "Don't worry if you don't write code - if you see the instructions are wrong - don't be afraid to fix it!"  - I wanted to say thank you for your encouragement!   - check out http://www.amazon.com/Official-Ubuntu-Book-Benjamin-Mako/dp/0137081308 (the acknowledgements page :D)
<akgraner> you all are the coolest kernel team ever  - well minus pgraner that is :-P
<apw> akgraner, see was i wrong ?
<akgraner> no you weren't - if you hadn't said just keep writing about stuff - I don't think I would have been asked to be a technical editor on this edition - so Thanks ya'll :-)
<penguin42> dupondje: Do you have a backtrace below it?
<dupondje> penguin42: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606393
<ubot2> Launchpad bug 606393 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 00000000000003c0 (affects: 1) (heat: 6)" [Undecided,New]
 * akgraner leaves on that note  - thanks again!
<virtuald> Aha
<virtuald> wrong channel
 * manjo signing out early... 
<chazn85> hey all, could someone enlighten me to the kj-triage tag?
<bjf[afk]> chazn85, it's used by the kernel team, just ignore it
<chazn85> ok will do, as an aspiring member currently being tutored by JFo was just curious to what it was
<jjohansen> chazn85: kj is kernel janitor
<jjohansen> basically its a tag used by the arsenal kernel janitor scripts
<jjohansen> its not even documented in the tags for people to add
<jjohansen> https://wiki.ubuntu.com/Kernel/Tagging
<jjohansen> you can find it mentioned in here
<jjohansen> https://wiki.ubuntu.com/specs/KernelKarmicBugHandling
<chazn85> i thought it was automated as i hadnt seen that one as yet 
<jjohansen> yep, to really know what it does you need to look in the arsenal scripts
<bjf[afk]> chazn85, the scripts add it and then check for it so the same bug isn't processed multiple times for the same reasons
<chazn85> thanks guys, all part of the learning curve, ill ignore them for the time being 
<bjf[afk]> chazn85, it's not a bad idea to take a look at the scripts, there's a lot going on in them
<chazn85> bjf[afk, i might just do that
<bjf> chazn85, if you have questions, feel free to ask, i've been through most of them quite a bit
<bjf> chazn85, i recommend you *don't* try to run them without talking to jfo first though
<chazn85> im cautious at the moment, so no chance of that!
#ubuntu-kernel 2010-07-17
<MTecknology> so.. there was a website for testing the load of your website. I have an account at it - but forgot it's name. I'm pretty sure it was a Drupal based website up front too... Any ideas what it is?
<lamont> hrmpf.  I want USB_SERIAL_WWAN in a lucid kernel.
<achiang> i want to understand bzr branches
<jjohansen> achiang: bzr branches aren't that bad, each directory is a branch
<achiang> jjohansen: yeah, i got straightened out in #launchpad
<jjohansen> okay
<achiang> jjohansen: it's a little different from how i'm used to working in git, where i keep all the branches in a single directory
<jjohansen> yeah
<achiang> why can't launchpad just support git as a backend and be done with it? ;)
<jjohansen> would make life easier for kernel devs :)
<hyperair> because nobody who knows git well enough has the time and interest to code support for it into launchpad.
<hyperair> unfortunately.
<achiang> meh. another bzr papercut.
<achiang> bzr diff doesn't seem to generate a patch that you can apply with patch(1)
<hyperair> doesn't it?
<hyperair> none of the $vcs diff tools have given me any trouble with that
<achiang> no, that's PEBCAK
<achiang> i was applying with the wrong -p level
<lamont> hrm... can I run a maverick kernel with a lucid user space?
<lamont> Picking 'linux-meta' as source package instead of 'linux'
 * lamont screams
<lamont> fortunately, wget is love
<soren> lamont: apt-get source linux-image-`uname -r`
<soren> lamont: But yeah, it's a bit unintuitive :)
<lamont> soren: only if I have deb lines in the sources.list in question
<soren> lamont: True.
<soren> lamont: The binary package linux is not built from the source package linux which makes for some interesting quirks sometimes :)
<soren> Like this.
<lamont> "interesting quirks" heh
<lamont> the real question is, after the 2.6.35-9.14 kernel builds on i386 in my ppa, will it actually work with the lucid userspace I'm going to stick it under?
<penguin42> lamont: There are a few apparmor oddities that will upset a few things I suspect, but they're a bit upset with the maverick userspace anyway, but other than I don't see why not
<lamont> cool
<MTecknology> penguin42: what's wrong with maverick userspace?
<penguin42> MTecknology: Just lack of getattr stuff in apparmor profiles I think isn't it?
<MTecknology> oh
<penguin42> so what happens with a bunch of bugs that look related? e.g. a bunch of oops's that are all in fb_release; I know we aren't duping kernel bugs - but what else happens?
<penguin42> e.g. bug 606377, bug 606546, bug 606545 and maybe bug 606469
<ubot2> Launchpad bug 606377 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/606377
<ubot2> Launchpad bug 606546 in linux (Ubuntu) "BUG: unable to handle kernel paging request at 0000031500000323 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/606546
<ubot2> Launchpad bug 606545 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at (null) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/606545
<ubot2> Launchpad bug 606469 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 00000013 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/606469
<penguin42> and maybe bug 606189 ?
<ubot2> Launchpad bug 606189 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 0000026c (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/606189
<zykes-> question: why is "loop" built in ?
<zykes-> on lucid.
<cwillu_at_work> zykes-, as opposed to being a module?
#ubuntu-kernel 2010-07-18
<ogasawara> apw: thanks for investigating that kernel-wedge build issue
<ogasawara> apw: I saw all my builds failed but then had to leave for the airport
<ogasawara> apw: we missed our connection and are stuck in AMS til this evening
<ralphcor> Hi, CONFIG_MEMTEST isn't defined by default.  I know of memtest86+ but memtest.c gives a memtest=N kernel parameter that runs N tests every boot, maps out bad memory, and being __init disappears later.  memtest86+ runs until killed, although its tests are better.
<ralphcor> Would a wishlist bug for CONFIG_MEMTEST be the way to go?
<ralphcor> memtest.c gives the paranoid the ability to "run a few tests every boot".
<penguin42> ralphcor: What does it do when the test fails?
<ralphcor> penguin42: printk KERN_INFO and reserve_early().  http://lxr.linux.no/#linux+v2.6.34.1/arch/x86/mm/memtest.c#L32
<penguin42> I guess you could also do something that watched for those and told the user if it survived that long, or spotted them in reported oopss
<manjo> apw, ping
<ralphcor> penguin42: I suppose so, but just being able to look at dmesg post-boot and see if memtest.c was happy would be useful.  I'm finding the in RAM copy of files can have four bytes, spaced 16 apart, differ from the on disc file after a day or two of uptime.  But translating the virtual address of that file+offset into physical RAM address can't be easily done, AFAICS.  And memtest86+ is happy, as I say.  So CONFIG_MEMTEST would be another option.
<penguin42> ralphcor: Nasty; you're assuming that's a RAM problem
<penguin42> ralphcor: Are they always at the same offset into any 512byte block?
<ralphcor> penguin42: True, I am, but then a userspace memory tester has also, once, come up with the same symptom after a few minutes, but never again, which seems to rule out the hard drive -> RAM route.  So it's probably happening to other pages of RAM too, it's just the output of lsof is a handy list of files to check.
<ralphcor> penguin42: No.  Here's one where the four RAM bytes are corrupted to become 0x00.  http://dorset.pastebin.com/KgLM9jtU
<ralphcor> penguin42: And a second that shows a more complex corruption.  http://dorset.pastebin.com/GsGYGAD6
<ralphcor> Ignore the commentary in the first, it was before I cottoned on to the RAM copy being duff, and not my copy of the root partition.
<penguin42> ralphcor: Wow, those are weird - I've not seen things vertically changed like that - 4 bytes in a row isn't too unusual
<ralphcor> penguin42: Me neither.  Although 16 bytes is 128 bits which may be a cache line length on this 64-bit arch?  That the offset within the 16-bytes differs is strange though.
<ralphcor> Who knows, perhaps if memtest=N was easily available we'd see more detection of RAM problems helping to point the finger for some of these random kernel crashes.
<penguin42> yeh
<penguin42> ralphcor: I can imagine if one chip in a DIMM wasn't getting write enabled some of the time or a bad connection then I guess you might see something like that - but it's still odd
<ralphcor> I was also wondering out of interest if memtest86+ uses all available cores.
<ralphcor> penguin42: Agreed.  If I could get physical address for every fault then I could look for such a pattern.  But not being able to do that from userspace is a hamper.  memtest=N would report physical addresses, I hope.  It's walking through e820 areas.
<penguin42> yeh
<lamont> so about these getattr calls that apparmor is denying... what's the change to the profile to make them happy again?
<pavolzetor> https://bugs.launchpad.net/gnome-power/+bug/257827
<ubot2> Launchpad bug 257827 in linux (Ubuntu Intrepid) (and 3 other projects) "brightness changes twice when using hotkeys (affects: 7) (dups: 1) (heat: 70)" [Medium,Fix released]
<pavolzetor> can you hep me
<lamont> so.. maverick kernel (just linux-image-2.6.35-9-generic), lucid userspace:  what am I missing that it no longer finds access points?
<lamont> meh.  broadcom wireless nic seems to be getting ignored
<ripps> whoa... I thought I had a good understanding of packaging, but than I took a look at the l-b-m packaging... 
<lamont> that's one seriously complicated package.
#ubuntu-kernel 2011-07-11
<panda|ac100> jk-: ping :)
<jk-> panda|ac100: pong
<ohsix> hey, does anyone know what mlockall does when the rlimit for mlock doesn't cover all of it? does it preserve the hottest pages? (would be magic, but also nice)
<ohsix> wow, addpart/delpart is neat
 * smb thinks apw stuggles to get online
<apw> struggling with unity actually which is about to get removed if it doesn't detect my screen without crashing
 * apw is not finding it acceptable that pluging in an external screen now causes unity to crash
<smb> apw, Must be a scary screen
<apw> this is a natty regression
<RAOF> As in: a regression in natty, or a regression from natty?  That said, I find unity in Oneiric is exactly as terrible at handling multiple monitors as in Natty :/
<ppisati> back in 10mins...
<apw> RAOF, as in i believe it used to work in natty ... or its better with hdmi than vga not sure yet
 * RAOF finds it hard to believe unity's monitor hotplug has got *worse* from natty.
<apw> RAOF, no it has gotten worse in natty in my experience
<cking> progress... but not in the right direction
<RAOF> Once it's sufficiently broken it'll look fixed?
<apw> RAOF, i had to reboot with the monitor attached to have a hope of logging in without unity crashing in a heap
<RAOF> Oh, yeah.  Who doesn't?
 * cking has to walk downstairs *again*, working from the loft conversion is getting me super fit
 * smb thinks they are in danger of "when it is sufficiently broken, nobody cares whether it gets fixed". Because all use something else
<RAOF> It *very* occasionally works without restarting unity.
<smb> cking is becoming the step-master
<cking> just training to walk all the stairs in millbank without dying
<smb> Though I think they stopped doing that... But anyway, always good to have some exercise.
<amitk> smb: they stopped? any particular reason?
<smb> amitk, Thought they had. But don't know of a specific reason. Maybe just got bored.
<smb> amitk, Not hearing much of you lately. How are you? 
<amitk> smb: i know :-/ Been a busy summer so far. Too many thing happening in the PM working group in Linaro keeping me busy. Plus some home renovations..
<amitk> smb: how was Dublin?
<smb> amitk, Yeah, there usually is no lack of something to do. The usual hive of bees (though no mankini incidents). Surprisingly I seem to have succeeded in looking at the things I planned to (which does not always happen).
<smb> Must be because the moved out all those noisy HWE guys to a different room. ;-P
<amitk> smb: same hotel?
<smb> amitk, Yep, which I had no memories any more about the lack of AC in the rooms. Which we could have used this time
<amitk> smb: hehe. They must've posted guards to avoid the mankini incidents :)
<smb> Well, those probably would not have been as bad as before as there were no horse show people but Bon Jovi fans around. They are much less likely to worry about such a thing. :)
<apw> more likely to be doing it themselves frankly
<jussi> Hrm, http://wstaw.org/m/2011/07/11/2011-07-11_10-24-33_21_Oulu.jpg
<jussi> :(
<apw> why would you be running a 3.0.0-rc3 kernel anyhow ?
<apw> jussi, ^^ ? 
<Tommeh> -rc6 maybe.
<Tommeh> But 3.0.0 for radeon r600+ does give some nice performance increases in gnome-shell/unity
<apw> yeah i am asking why he is running an out of date mainline kernel
<jussi> apw: because I was told here to try it. (a couple of weeks ago). I thought the trace may be of use, so I posted the screenshot. If its useless, I will throw it away :)
<apw> jussi, i would update to the latest and see if its still there, as thats quite early 3.0.0
<jussi> apw: ok. have we been building 3.0's for natty yet? or should I still be trying the oneiric builds? (as mentioned here before)
<apw> we don't build them for natty, we have some for lucid as we do backports to there, otherwise its oneiric ones
<jussi> apw: ok. could you again link me to the site with all the debs? I seems to have misplaced it :(
<apw> http://voices.canonical.com/user/76
<apw> ARRRG WHY DOES X HAVE TWO PASTE BUFFERS ..> WHY
<apw> https://launchpad.net/ubuntu/+source/linux
<ppisati> any debian package expert around?
<ppisati> basically, my omap4 kernel package refers to the wrong module directory
<ppisati> (wait for the pastebin...)
<ppisati> http://pastebin.ubuntu.com/641814/
<ppisati> any idea where i should look for?
<ppisati> i know it's something in debian/*
<ppisati> but i don't know what's exactly...
 * apw looks
<smb> ppisati, I would guess it would be somewhere in rules.d. Either defining a version string wrongly in 0-* or using a wrong one in the binary rules...
<apw> that + on the end is classicly added by the kernel itself when it is unsure of its own version number
<apw> we normally override that in rules however
<apw>         LOCALVERSION= localver-extra=
<apw> i have that on my kmake variable in debian/rules.d/0-*
<apw> does your have that ?
<apw> cirtainly the main kernels are at those version numbers and do not suffer this problem
<apw> ppisati, ^^
<ppisati> apw: [flag@newluxor ubuntu-oneiric]$ grep -R LOCALVERSION debian/rules.d
<ppisati> debian/rules.d/0-common-vars.mk:        LOCALVERSION= localver-extra=
<apw> ppisati, is your branch up to date on ti-omap4-next
<ppisati> apw: this morning i rebased the new stuff from TI on top of oneiric/master-next
<apw> ppisati, oh one thing do you have updated module init tools installed ?  for the 3.0 prefix bug
<ppisati> previous to your 3.0.0-rc6 push
<ppisati> uhm no
<apw> that might explain the error as you may be using the running kernel version in error then
<apw> though note if you rebase to the latest tip the version number moved to 3.0.0 anyhow
<apw> and the problem is removed
<ppisati> so i can try to do another rebase
<ppisati> ok, i'll do
 * ppisati goes for a dist-upgrade, kiss me goodbye...
<apw> ppisati, see you
<nigelr> I'm getting an oops caused by uvcvideo and I think it might be related to the problem fixed by this patch: https://lkml.org/lkml/2011/7/8/87
<nigelr> any chance of it being included in the stable natty kernel? :)
<nigelr> I'm just trying it out now
<vish> i'm trying to bisect and build a kernel, I see the following error during sub-make : http://paste.ubuntu.com/641831/ and the kernel does not build. how do I fix this?
<vish> when i check the directory, i see no file named "..debian/stamps/stamp-build-generic"
<vish> just have ../debian/stamps/stamp-prepare-generic and ../debian/stamps/stamp-prepare-tree-generic
<smb> vish, The real error is actually somewhere above that. The stamp file would just be created if the build went ok
<vish> hmm, /me looks 
<apw> nigelr, if a simple patch like that fixes an obviously triggered oops then its possible to SRU it
<apw> vish, the error would have been much before the end of the log as we build in parallel, search back for 'error'
<vish> hmm, looks like there are quite a few "errors"
 * ppisati -> reboot
<vish> bah, i dont think i see anything related to 'stamp' and 'error' , maybe I'm not looking at the right thing.. could someone check what went wrong? Â» http://paste.ubuntu.com/641841/
<smb> apw, Not sure, wasn't git bisect skip the thing probably needed if a certain revision just is not buildable but you would not want to say bad or good?
<apw> vish, pastebin the output, you'd not see a stamp file as that only gets made if the make is successful, which it is not
<smb> /home/vish/ubuntu-maverick/fs/ceph/msgpool.c:173: error: implicit declaration of function âkref_setâ
<vish> smb: /em has no clue what that means :D
<vish>  */me
<smb> vish, That was the error that caused the build to fail
<vish> smb: k, how do I fix it?
<smb> Apparently there is no previous definition of kref_set
<apw> vish if you cannot build a revision then saying git bisect skip will ask it to find another to test without taking this one as good or bad
<smb> cauld be either a missing include or the patch that introduced it came in the wrong order
<vish> apw: k, great! :) will probably have to do that, if i cant fix this..
<vish>  bleh, finding the include or patch, might just take longer when I have no clue.. /me skips! 
<lamont> why does my machine wish to schedule while atomic?
<smb> Naughty developers...
<ohsix> lamont: do you have an intel video card?
<ohsix> theres a 4500mhd regression in mesa that causes a panic; and switching the tty to display the panic triggers the scheduling while atomic panic
<ohsix> it's fun ;]
<smb> lamont, Very generically somthing allows disruptions (interrupts) where it should not. But some info around it might be useful...
<ohsix> lamont: do you have an intel video card?
<lamont> 01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9500 GT] (rev a1)
 * lamont tries a maverick kernel to see if that's any better
<lamont> the latest failure was in netfilter code, "kernel stack corrupted"
<lamont> I'll get the jpgs somewhere and file a bug later today
<apw> oooh nasty
<lamont> something like that
 * apw needs to find someone who has played with ipv6 tunnels
<ppisati> apw: smb: btw, moving the pkg to a 3 digits 3.0.0-x kernel pkg _seems_ to have fixed my problem... let's see...
<apw> ppisati, good stuff
<tgardner> bjf, where is that bug repo you were talking about at the rally ? the one with clear text files, etc.
<bjf> tgardner, on zinc at /x/bradf/lp-data.git
<tgardner> bjf, ack
<apw> bjf, you should so symlink that into your home
<bjf> apw, done
<dupondje> http://paste.ubuntu.com/642025/ => could this be a kernel bug or surely hw issue?
<dupondje> i'm on oneiric btw
<jjohansen> rebooting
<jjohansen> oneiric update this morning, made my machine none functional, it doesn't appear to be a kernel issue (tried previous oneiric and natty kernels) if other people start complaining
 * tgardner --> lunch
 * bjf -> lunch
 * lamont manages to land on bug 809000
<ubot2> Launchpad bug 809000 in linux "kernel stack corrupted in 2.6.38-8" [Undecided,New] https://launchpad.net/bugs/809000
<tgardner> lamont, its suspicious that both traces involve network functions. I think you also have the accursed r8169 ethernet driver.
<lamont> I do
<lamont>  lsmod | grep 8169
<lamont> r8169                  39714  0 
<lamont> mii                     5237  1 r8169
<tgardner> lamont, it has undergone serious renovation for 3.0.0, perhaps you could try the Oneiric kernel
<lamont> I do have room and a spare network card that I could kill 8169 with fire and see if it makes any difference
<lamont> or I could do that
<lamont> how stable otherwise is oneiric's kernel?
<tgardner> lamont, It seems to be doing pretty well. we're all using it on various platforms
<tgardner> lamont, of course, knowing you, you'll have some bizarre HW that borks it right away
<lamont> well... there is a vlan bridge on the box
<lamont> Build needed 08:08:03, 1618388k disk space
<lamont> I know that's a total lie, since I saw it up over 20GB of footprint sometime during that build
<lamont> did we lose the patch that removed the intermediate build trees again?
<lamont> (on a different note, that is)
<tgardner> lamont, not that I know of. lemme check
<tgardner> lamont, was this an oneiric build ?
<lamont> dist-upgraded the machine to  natty over the weekend
<lamont> worked around the "3 crashes in 20 minutes" feature by tossing the maverick kernel on the box
<tgardner> lamont, um, I was talking about the build space issue.
<lamont> oh build-space
<lamont> yeah
<lamont> that was the 3.0.0-4.5 build
<tgardner> lamont, the patch that removes intermediate files is still in the oneiric rules
<dupondje> http://paste.ubuntu.com/642025/ => could this be a kernel bug or surely hw issue?
<lamont> the machine in question had some old cruft in someones home directory that resulted in a disk space alarm that made me (1) boggle, (2) look at the build tree and boggle, and (3) clean out said homedir's cruft
<lamont> tgardner: ok.  I'll check into it more sometime, don't worry about it
<lamont> at least not for a week or 3
<tgardner> lamont, ok, holler if it gets too annoying
<lamont> well, it's more "if we release and it really is that big, it may well be that it doesn't build in a (virtualized) ppa".  that would suck
<tgardner> lamont, I'll have a closer look at it. every release accrues more modules, more drivers, more stuff
<lamont> yeah
<lamont> pretty soon, there could be a valid complaint of "bloat"
<tgardner> herton, keep an eye on bug #809000. Its another lamont special. I'm suspecting the root cause is r8169
<ubot2> Launchpad bug 809000 in linux "kernel stack corrupted in 2.6.38-8" [Undecided,In progress] https://launchpad.net/bugs/809000
<lamont> I'm still trying to understand how my last one somehow wound up closed as invalid
<lamont> that one at least has the 82546EB chipset
<herton> ok. lamont, isn't this on the same machine which had the NAT issue?
<lamont> herton: no
<jwi> tgardner: uh - bad time to ask about enabling some experimental drivers/configs? :)
<lamont> it's a tower which hosts a kvm guest that lives on a different vlan than the primary IP of the box, while also having an IP on that subnet too, since it doesn't like to talk to the guest via the router
<tgardner> jwi, as a matter of policy we generally do not enable drivers that are EXPERIMENTAL
<jwi> right, but there's still a whole bunch of them enabled
<tgardner> jwi, I acknowledge that there have been exceptions. I'm mostly not interested in supporting (or taking bugs for) experimental drivers and features. we've already gotten bit by network name spaces in 2.6.32
<jwi> RTL8192CU seems like a good candidate, considering its experimental rtlwifi siblings are enabled
<tgardner> staging is different then experimental.
<jwi> its not in staging
<jwi> i saw the network name space issue, the ones i was thinking about really are "experimental or no device driver at all" cases
<tgardner> jwi, shit, all the rtlwifi drivers are experimental. how;d they get enabled ? (I probably did it)
<tgardner> hmm, we probably got them for free when they moved out of staging.
<jwi> i don't think they ever have been in staging - rtlwifi is a new "project"
<tgardner> jwi, the config option wasn't though. I think it got reused.
<jwi> urgh, that might be true
<tgardner> jwi, ok, committed 'UBUNTU: [Config] CONFIG_RTL8192CU=m'
<tgardner> now, back to what I was doing...
<jwi> ty - now hold on, that wasn't the only one ;)
<tgardner> jwi, that looks like it was the only one not enabled for x86en
<jwi> if you got the time, see bug 238208 for MEMSTICK_R592 - it seems like it got quite some testing
<ubot2> Launchpad bug 238208 in linux "Need MemoryStick driver Ricoh R5C592 (part of R5C832/822chipset)" [Wishlist,Confirmed] https://launchpad.net/bugs/238208
<tgardner> jwi, looks like it went in 2.6.39 ?
<jwi> yep
 * herton --> eod
 * tgardner --> eod
<Q-FUNK> howdy!  is left_control+K mapped to some SysReq key on ubuntu?  every time I press these, the CPU kills all power immediately without proper shutdown.  it's annoying since control-K is "cut" in 'nano'.
<charlie-tca> Q-FUNK: according to the shortcuts lists, it shouldn't be
<charlie-tca> http://askubuntu.com/questions/28086/unity-keyboard-mouse-shortcuts/28087#28087
<Q-FUNK> I'm not using unity.
<charlie-tca> http://www.techdrivein.com/2011/04/31-useful-ubuntu-1104-unity.html
<Q-FUNK> and the issue also affects vcons operation.
<charlie-tca> Still shouldn't be, without SysReq key also
<Q-FUNK> hmm.. ok
<Q-FUNK> another issue I have:  on my ubuntu+1 host, kernel 3.0.0 makes the CPU overheat.  it has become a significant issue that I've had to go back and run 2.6.38 instead.
<Q-FUNK> is this a known feature of current 3.0 kernels?
<jjohansen> Q-FUNK: In general the 3.0 kernel should be better than .38, a couple bugs have been found that fix some problems with the scheduler keeping the processor for entering into lower power states
<jjohansen> Q-FUNK: you can try booting with pcie_aspm=force  as a kernel parameter and see if that reduces your power problems, but I doubt it will as .38 should suffer from that problem as well
<Q-FUNK> it's just that since .38 the whole casing is burning hot. I've kept an older kernel  (.36 IIRC) and going back to that significantly reduces the temperature.
<jjohansen> Q-FUNK: and no left-ctrl-K is not mapped to sysrq in Ubuntu
<jjohansen> Q-FUNK: ah then pcie_aspm=force might just work for you
<jjohansen> it was introduced in .38
<jjohansen> that is the problem, before linux was ignoring the bios which wasn't really correct, but some buggy bioses see significant power regressions because of the newer behavior
<jjohansen> passing pcie_aspm=force restores the old pre .38 behavior for those systems
<jjohansen> Q-FUNK: I am not sure what to say about your left ctrl-k behavior besides open a bug, it shouldn't be happening and doesn't happen for me
<Q-FUNK> mind you, that red-hot host doesn't have any pcie bus
<Q-FUNK> didn't I read somewhere that kernels since after 2.6.32 consume a heck of a lot more power and that it's a known issue, though?
<jjohansen> Q-FUNK: I think you are thinking of the phoronix article
<Q-FUNK> could be
<jjohansen> his figures don't really back up some of his assertions about power usage
<jjohansen> he did find a regression see the pcie_aspm=force from above
<jjohansen> but as I said that is really more of a bios issue
<jjohansen> there are other regressions, like the scheduler one I mentioned
<Q-FUNK> afaik he was quoting some upstream developer as knowing that the increased power consumption was introduced some time back, but wasn't seen as such a priority issue
<jjohansen> that should be fixed in the latest kernel
<jjohansen> Q-FUNK: hrmm, there have been things that increased power consumption but where not major regressions
<jjohansen> an hence were not high priority
<Q-FUNK> well, considering that my +1 host is suddenly burning hot but never was before, I'd have to doubt that assumption
<jjohansen> part of the problem with power is every machine is different so it is hard to test for regressions
<jjohansen> that is it works for me and on my machines ...
<jjohansen> Q-FUNK: not claiming you aren't seeing a major regression, just the general picture as seen by the kernel community
<Q-FUNK> also, since recent kernels, 'dpkg' regularly manages to segfault.  it doesn't occur if I boot into an older kernel.
<Q-FUNK> ok, fair enough :)
<jjohansen> Q-FUNK: that sounds like a processor overheating
<Q-FUNK> yup
<Q-FUNK> but again, doesn't happen if I reboot into ... was it 2.6.38
<jjohansen> Q-FUNK: well we can try bisecting the problem
<Q-FUNK> 2.6.38-8-generic
<jjohansen> but that is going to take installing more than a few kernels
<Q-FUNK> it started happening sometimes during 2.6.39, but it was not too frequent.  now, with 3.0.0, it's nearly at every update
<Q-FUNK> ... at every 'apt-get upgrade'
<jjohansen> Q-FUNK: the tighter the range you can provide the better.  If you want me to bisect this, open a bug and subscribe me to it/point me to it
<jjohansen> I can provide you kernels to test, I need to know a known good point and a known bad
<Q-FUNK> jjohansen: that sounds good. I'm away from my +1 host this week, but I could return to the issue during the weekend and add you then.
<jjohansen> Q-FUNK: okay, I'll keep an eye out for it
<Q-FUNK> the control-k issue is on my natty laptop, though.  I haven't seen if it affects my +1 host too or not.
<jjohansen> that one is just bizarre, I've never heard of such a problem
<Q-FUNK> well, it could also be triggering some model-specific key combination.  this laptop is a dell, if it helps any.
#ubuntu-kernel 2011-07-12
 * abogani waves all
 * apw yawns
<RAOF> Time for the bees!
 * apw giggle insanly
<smb> apw, Has there been back in 20mins mentioned?
<apw> sadly not
 * smb wonders what made apw loose control. :)
<apw> its just going to me one of those days
<abogani> ogasawara: ping
<RAOF> Bah.  Bluetooth, why do you suck so?
<ppisati> CFLAGS+=-DENABLE_GPIO_RADIO_CTL
<ppisati> ops
<ppisati> http://pastebin.ubuntu.com/642447/
<apw> ppisati, ok seems i've pushed an update to lucid master-next which should sort you out
<apw> no idea why i didn't think it applied to lucid
<ppisati> apw: cool, btw disabling that driver fixed the compilation
<ppisati> apw: when available, can you open CVE-2010-4805? thanks
<ubot2> ppisati: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.35 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service by sending a large amount of network traffic, related to the sk_add_backlog function and the sk_rmem_alloc socket field.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2010-4251. (http://cve.mitre.org/cgi-bin/cvename.c
 * ppisati -> out for food
 * apw lunche
<herton> smb: natty is failing on QA for -virtual flavour, because CONFIG_DEBUG_RODATA is disabled for it (bug 802464)
<ubot2> Launchpad bug 802464 in linux "linux: 2.6.38-10.46 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/802464
<herton> smb: we don't remember now if it was you which was going submit a patch for it, as it was reported before, but I can do it in any case
<smb> herton, wtf. Thanks, though I would have thought that Natty should not be able to get built without...
<smb> The last one it was not would have been hardy
<herton> ah... ok, natty seems to require the same fix then
<smb> I thought we had that in the big mean config checker, but I need to have a look at that
<tgardner> smb, its in the enforcer, but looks like virtual is excluded
 * smb wonders whether there was a case where that broke ec2
<tgardner> herton, why is that failing now ?
<smb> tgardner, Guess because now we are really really testing
 * smb will have a look and see whether it can be turned on and still boots on ec2
<herton> it seems we got this reported in June, but was forgotten (https://lists.ubuntu.com/archives/ubuntu-kernel-sru/2011-June/000158.html)
<tgardner> smb, in the meantime I suggest we get an exception so it doesn't hold up everything else. its not like its a regression.
<tgardner> herton, ^^
<smb> +1
<herton> tgardner: yep, I agree
<smb> herton, tgardner I think the problem should now be fixed through stable but we deliberately have been disabling that for i386 (see 0b111980fe515c5ab24bf21aca5aebd24c70f605)
<smb> But I'll better get it tested to be sure
<tgardner> smb, herton: so an exception should be acceptable since we made the change with malice aforethought.
<apw> ppisati: did someone do this for you: CVE-2010-4805
<ubot2> apw: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.35 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service by sending a large amount of network traffic, related to the sk_add_backlog function and the sk_rmem_alloc socket field.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2010-4251. (http://cve.mitre.org/cgi-bin/cvename.cgi?n
 * smb has not
<herton> yes, +1 on that, it isn't a regression from the released natty kernel
 * ogasawara drowns in email
<tgardner> ogasawara should never take vacation again
<ogasawara> I miss anything exciting?
 * apw votes for ogasawara to not have any too
<smb> ...ctrl-a del
<apw> ogasawara: na things went ok for the milestone
<ogasawara> apw: I thought you'd pushed over the top of linux-meta to drop versatile?
<apw> ogasawara: i did i thought  /me checks
 * tgardner defers UDS registration until August in case the dates change again.
<apw> ogasawara: i think its on master-next
<apw> i think we need to shift that back
<apw> ogasawara: let me look maybe i've bust it
<tgardner> apw, you should drop an example of MSS clamping in that IPv6 wiki page.
<apw> tgardner: will do ...
<ogasawara> apw: yep, looks like it's on master-next.  I'll get master updated.
<apw> ogasawara: yeah i think its time to lose master-next
<apw> (from meta)
<ogasawara> apw: yah, I'll drop that branch too
<ogasawara> apw: I assume you have the commit for 3.0.0-5.6 for linux-meta in your tree then?  care to just push that to master?
<apw> ppisati: https://bugs.launchpad.net/bugs/809318
<ubot2> Ubuntu bug 809318 in linux-ti-omap4 "CVE-2010-4805" [Undecided,New]
<ogasawara> apw: nm, looks like it's tgardner who's got it
<apw> ogasawara: ok ... get him to shove
<tgardner> ogasawara, what am I shoving? apw did the last meta upload.
<ogasawara> tgardner: am trying to find the commit which closed out linux-meta for 3.0.0-5.6
<ppisati> apw: 10x
<tgardner> ogasawara, well, I don't think anyone has done it yet. 5.6 isn't finished building.
<apw> ppisati: i am going to assume thats positive
<ogasawara> tgardner: ack, you're right
<tgardner> ogasawara, I just got it uploaded about 10P your time.
<ogasawara> I'll keep an eye on the builds and then get linux-meta uploaded/updated 
<tgardner> ogasawara, I've nothing unpushed in my natty-meta repo, so feel free to hack and slash
<tgardner> bjf, given that you are the resident python expert, how about reviewing sforshee's patch lest he become discouraged? https://lists.ubuntu.com/archives/kernel-team/2011-July/016142.html
<bjf> tgardner, roger, roger
<sforshee> tgardner, bjf: at this point it doesn't seem to matter much since we've switched back to 3 numbers in the version
<apw> i recon we should fix them anyhow
<sforshee> it would be simpler if we could assume a '-' between the upstream version and the ABI, but right now it looks for '.' or '-'. I assume that's for legacy reasons?
<apw> sforshee, per
<abogani> ogasawara: ping
<apw> sforshee, perhaps for meta as well
<apw> which uses the . . . . form
<sforshee> I see
<ogasawara> ogasawara: pong
<ogasawara> heh
<ogasawara> abogani: pong
 * apw giggles at ogasawara
<smb> one of those days...
<abogani> ogasawara: Could you renew me in bugcontrol, please?
<ogasawara> abogani: sure, just a sec
<abogani> ogasawara: Thank you 
<ogasawara> abogani: done, renewed for another year
<abogani> ogasawara: Thanks again 
<bjf> sforshee, yes the '.' is to support meta
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<apw> bjf, again, so soon ?
<bjf> apw, we could go to once a month, no-one would notice
<apw> :)
<ogasawara> apw: aside from the 3.0.0-5.6 upload, anything else happen I should mention in the meeting?
<apw> ogasawara, no i don't think so, we were all quiet.  of course you should mention 3.0.0 change
<ogasawara> apw: right, will add that
<apw> sconklin, i see a lot of our master-nexts have not 
<apw> been rebased, its making the pre-proposed kernels come out with funny old version numbers
<tgardner> apw, we can fix that
<tgardner> the rebase, I mean
<apw> tgardner, i wanted to check he hasn't done them already
<apw> tgardner, i guess as they are rebasable i can jstu do them and not care
<apw> sconklin, scream now if you don't want them rebased
<tgardner> apw, he could be screaming, but his pulse-audio has died.
 * smb would sort of expect some "hold now" and "go" to know when one should be careful on touching -nexts
<apw> smb, well you can tell if you push over someone so ... its entirly safe, just hard-ish to un-fook when you do overlap
<smb> apw, Just don't like to find out by the time I would push, I guess
<sconklin> apw: I have no issues with fixing up the -next branches, I just usually don't use a rebase to do it. 
<sconklin> For reasons we discussed at the rally
<smb> we did?
<smb> Ah well
<apw> sconklin, i am using the term rebase in its literal form, to move the base of the branch to the tip of master, not implying what you use to do it
<smb> Its not really the rebase but the need to have a sensible (higher) version number
<sconklin> There was a long discussion of why I prefer to cherry pick all the new commits from -next to the last tag, and force push that over master-next
<sconklin> it amounts to the same thing.
 * smb remembers now
<apw> sconklin, right i don't care how one choses to do it, what i a complaining about is it not being dne
<sconklin> Want me to do it, or does apw have it under control?
<apw> sconklin, and if you haven't the time to do it i can do it, just say
<sconklin> agreed. It's "yet another thing that doesn't have a checkbox that's enforced and gets forgotten"
<apw> sconklin, i'll just go ahead and move them up then
<sconklin> I can easily get it done today, probably in the next couple of hours including the meeting
<sconklin> whatever
<apw> sconklin, ok i'll let you
<sconklin> ack
<apw> (and i am complaining cause the pre-proposed kernels are getting dumb versions not cause i inherantly care)
<sconklin> no, I understand
<apw> sconklin, are we close to releasng any of these -proposed kernels?
<sconklin> afaik, it's all in qa and cert now. So the answer is a provisional yes
<sconklin> I'm compiling that information now for the meeting
<apw> sconklin, cool, i am getting bored waiting for the lts-backport for natty to arrive 
<sconklin> did you prep and build that? I'm not sure we did
<sconklin> It ftbfs a while back and I don't think I got back to it
<apw> i suspect i did originally
<sconklin> I'll have a look
<apw> it ftbs's on everything other than x86 and x86_64, but that is an archive error
<apw> as we only target those two architectures, it is not even meant to start on the others
<apw> i have been assured its not our fault
<apw> that the control file is right and does not specify those other arches, but it goes there anyhow
<sconklin> then it may just be sitting and waiting to be copied out of the ppa. I'll check
<herton> yes, the script probably didn't get the build status as FULLY_BUILT because of the other arches which failed
<herton> thus it didn't set the prepare-package to fix released for the lts-backport tracking bugs
<herton> (script = shank bot)
 * apw will once more try and get to the bottom of whether we can fix this
<micahg> are you aware that the new 3.0.0-x kernel is showing up under the 3.0-x kernel in grub1?
<apw> micahg, under? as in appearing 'lower' in version ?
<micahg> apw: yes, options 3 and 4 :)
<apw> micahg, why the heck is grub1 still on anything ?
<micahg> I've been upgrading since hardy on that machine I think :)
<micahg> I can file a bug, I just wanted to make you aware
<apw> cjwatson, do we care a
<tgardner> micahg, delete the 3.0-x kernel ?
<apw> cjwatson, do we care any more about grub1 ?
<micahg> tgardner: I can't be the only one with the issue ;)
<tgardner> micahg, perhaps, but I'm not sure its something we'll fix 'cause 3.0-x was temporary
<smb> apw, Just fwiw, you may encounter similar code in pv-grub on ec2
<apw> ok confirmed that grub2 is at least ordering them right
<apw> smb, nnng, well as we will release with a 3.0.0 i don't think we should hit it right ?
<tgardner> apw, right. its a developer issue
<smb> apw, no, you are right. 
<micahg> it's ascii ordering instead of version ordering
<apw> micahg, but do file a bug
<micahg> k
<apw> at least that way people will stumble on it, and we can document removing the old ones as a work-around
<micahg> apw: bug 809401
<ubot2> Launchpad bug 809401 in grub "grub is ascii ordering instead of version ordering kernels" [Undecided,New] https://launchpad.net/bugs/809401
<bjf> ##
<bjf> ## Kernel team meeting in one hour
<bjf> ##
<cjwatson> apw: we've never auto-upgraded people, so yes we do slightly care
<cjwatson> also I thought the sorting in GRUB Legacy was the same as that in GRUB 2 ...
<cjwatson> hm, perhaps not
<cjwatson> anyway, it's my responsibility to fix, not yours
<cjwatson> and it's not just ascii-ordering, it's more complicated than that
<cjwatson> I'll have a look
<tgardner> cjwatson, its really only a developer issue, i.e., only folks that had 3.0-x installed are affected. the normal upgrade from Natty to Oneiric should be fine.
<cjwatson> tgardner: it's a bug, and should be fixed
<cjwatson> sure, not very high priority :)
<lamont> tgardner/herton: 3.0.0-4.5 seemed to fix that.  what are the chances of getting a r8169 driver backport to natty?
<tgardner> lamont, hmm, I can check into it. perhaps an LBM backport ?
<tgardner> on the other hand, the in-kernel driver is so broken that maybe I should just SRU a replacement
<lamont> tgardner: I'd prefer to run "a natty kernel"  I have absolutely no care as to how we define that
<tgardner> lamont, I've forgotten. Is there an existing bug no this r8169 issue?
<lamont> 809000 is the best candidate
<tgardner> lamont, ack
<lamont> I haven't proven it - turns out that my spare network card has more pins on its edge connector than the mobo has pins in the slot
<lamont> :(
<lamont> the plan for today is to go drop $20 on a network card on my way ome
<lamont> home. even
<tgardner> ogasawara, given our policy of not modifying user space for backports, how do I note in the KernelOneiricUbuntuDeltaReview that we'll continue to carry a patch, likely in perpetuity ?
<tgardner> in particular 'UBUNTU: Sony laptop: Some Sony Vaia laptops do not enable wwan power by default.'
<ogasawara> tgardner: add a note to the wiki, and on the next rebase I can munge the commit message to note "SAUCE: (no-up)" so we know we'll carry it going forward
<herton> lamont: hmm ok, would be good indeed to check with another network card still
<tgardner> ogasawara, ack
<sconklin> apw: The natty backports kernel needs to be respun, since we dropped some regressions out of Natty since it was made
<apw> sconklin, excellent let me do it
<apw> sconklin, as i think i have the fix for the erroring foun
<sconklin> I suspect that the same is true of Maverick, checking
<apw> foudn
<apw> sconklin, i will do both if they need it ... let me know
<herton> yes, maverick is the same
<herton> we reverted two patches (1 failed verification, the other is the tlb regression)
<sconklin> and - it's difficult to determine exactly what Natty the backports kernel is based on, because when we drop the patches and respin Natty and only change the upload number, that doesn't get propagated into the backports version or log that I can see
<apw> sconklin, the version of the backports is identicle to the one is it based on
<apw> sconklin, with ~lucid1 on the end
<sconklin> oh, well then perhaps it does contain the reverts and is up to date
<sconklin> one sec
<sconklin> Yes, it appears that what's in the PPA for natty backports reflects the latest natty (.46), so it only needs copying to -proposed.
<sconklin> apw: I get it now, thanks
<apw> sconklin, ok and i think i have the erroring out crap sorted for next time, pushed to natty and maverick backports branches
<sconklin> excellent
<sconklin> apw, smb, tgardner: who is qualified to make a decision about whether it's OK to ship Natty with the CONFIG_DEBUG_RODATA issue? As it is it's stopped based on the QA testing failure, and we need to know whether to override that or respin (please be the former).
<tgardner> sconklin, we talked about that earlier this morning. its not a regression so shouldn't hold up this release. smb is investigating....
<smb> sconklin, We had been disabling that because of some i386 ec2 problem
<tgardner> it _used_ to cause ec2 issues, but has perhaps been fixed in the interim
<smb> sconklin, So its not a regression. But it seems based on my current test that it could get enabled again
<smb> sconklin, Is there a bug open for it already?
<sconklin> ok, I'm going to consider that two acks for releasing what we have
<sconklin> smb: Not that I'm aware of. herton may know
<herton> I think there is no bug open for that
<smb> Ok, so I will open one for submitting the patch to enable it again when I am done with all the tests I wanted to do
<bjf> sconklin, as stable mgr. i think it's your call
<sconklin> bjf: Updating the bug now to ship it.
<sconklin> I just wasn't clear on the technical implications.
<sconklin> apw: when do the build run on the master-next branches?
<sconklin> builds
<bjf> sconklin, new tag: "let 'er buck"
<sconklin> bjf: http://en.wikipedia.org/wiki/File:Slim-pickens_riding-the-bomb_enh-lores.jpg
<ppisati> don't we have the meeting now?
<bjf> ppetraki, was daydreaming
<smb> bjf, nice the tags listing sort of is just the right start point to look for some of my tags of interest
<bjf> smb, if there are other spins/mappings you'd like to see, let me know, i plan on adding more that I think are of value
<apw> sconklin, as in when is pre-proposed uploaded?  09:00 UTC
<tgardner> bjf, how about a graph showing the number of comments in a bug? or the number of subscribers, or the number of 'affects me', etc
<apw> though i have been thinking it should be checked hourly and uploaded if its more than 24 hours since it last was uploaded and different
<sconklin> ok, I am commencing fixup of the -next branches
<bjf> tgardner, i'll put that on the list
<tgardner> bjf, just thoughts on how to gauge what bugs are really pissing people off
<apw> heat ?
<bjf> tgardner, apw, "kernel gravity"
<bjf> tgardner, apw, "bitch factor"
 * smb thinks bugs against dapper, gutsy and feisty at least should be targets to kill...
<apw> heh i meant there is already a heat
<bjf> smb, yes, a script is on my list
<bjf> smb, "won't fix" all unsupported series
<smb> bjf, nice :)
<apw> bjf, i may have the bones of that already, in the bugs/proc-cve-bugs
<apw> which works out the same equasion, is this package supported on this release
<smb> apw, There is definitely heat... oh you meant the bug heat :-P
<sconklin> heat index is 105F here
<apw> 18.9c here, which is nowhere near that, less than 70f
<smb> 28Â°C -> 82Â°F in my room...
<apw> smb, man you need to smash some windows
<mjg59> apw: That'll just let the heat in
 * smb hopes the distant grumble means coolness
<apw> mjg59, without aircon, its almost cirtain that his machine heavy room is hotter than outside
<smb> apw, Was suppusedly 30 outside
<apw> smb, you need to move
<apw> (slowly :)
<smb> apw, Was about to say that moving makes me feel even warmer
<smb> :)
<bjf> smb, the high for the next 10 days is 26C, mostly 18 - 23
<smb> bjf, I hope they are right
 * tgardner reboots to test CVE-2010-4251
<ubot2> tgardner: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.34 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service (memory consumption) by sending a large amount of network traffic, as demonstrated by netperf UDP tests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4251)
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - July-19 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<tgardner> sconklin, when a Q/A test fails do they stop testing right away?
<sconklin> tgardner: good question. I assumed not because the bug said something like "18 tests, 1 fail", but there may have been 30 tests total. I don't know.
<tgardner> sconklin, likely worth following up on before setting a Q/A to released
<tgardner> a Q/Q task*
<tgardner> bah
<sconklin> yeah, probably too late for this one, but good question. bjf, do you know? ^^
<tgardner> sconklin, I know cert baila on the first failure
<tgardner> bails*
<sconklin> that's not terribly useful
<tgardner> doesn't seem like it to me either
<bjf> sconklin, from what i've seen, it depends on the failure
<bjf> hggdh, ^^ thoughts?
<hggdh> sconklin: no, I do not stop on first failure
<hggdh> the failure may be localised, or other archs/kernels may show different failures, so I consider it worth the time to keep on
<hggdh> what I do is warn I found a failure, tag the bug accordingly, and keep on
<hggdh> bjf: ^ 
<bjf> hggdh, thanks, i think that is what we'd like to see done as well
<bjf> sconklin, tgardner ^^
<tgardner> ack
<sconklin> hggdh: thanks!
<hggdh> specifically to the QRTs, all unit tests on each module are run to the end
<sconklin> hggdh: did you see that I overrode your QA failure?
<hggdh> sconklin: yes, I did see. I had just ended with the KVM tests, so all is kosher
<sconklin> hggdh: Thanks!
<hggdh> sconklin: and this is actually what I expect to happen. I should not decide on overriding or not
<hggdh> so... Lucid and Natty done. bjf, sconklin, a specific version you would like me to work on now, or anyone left is good?
<sconklin> hggdh: ok, thanks. We'll have to modify processes as appropriate as QA gets more integrated and automated.
<sconklin> Maverick is important for some folks. It may not be back in -proposed yet, let me check - hold on
<hggdh> aye. Hoiw do you want go to forward on this error (Natty EC2 m1.small/i386 CONFIG_DEBUG_RODATA)? Pass the next one, or still mark as failure?
<sconklin> still mark as failure, because we should have it fixed in the next release. Force me to override it if needed ;)
<hggdh> :-) a pleasure to, er, help ;-)
<sconklin> hggdh: Maverick is still awaiting copy to -proposed, and as soon as that is done we will mark it verification complete because it is simply a respin with some reverts.
<sconklin> So in the meantime, grab something else . . .
<hggdh> sconklin: roger wilco
 * tgardner --> lunch
 * jjohansen -> lunch
<njin> hello, there's someone experiencing Error insetingpadlock_sha in 3.0.0-4 ? any workaround to restore system?
<njin> Error inserting padlock_sha
<tgardner> njin, is it the right kind of CPU ? 
<tgardner> this is not typically a fatal error
<njin> tgardner, is the yesterday update, system is locked at login screen, nothing working, no panic
<tgardner> njin, thats likely something other then a crypto engine failure
<njin> encrypted /home cannot be mounted, no mouse or console, only sysrq
<njin> unfortunately no thing in the log files
<tgardner> njin, and 3.0-3 consistently works ?
<njin> 3.0-3 yes fine
<tgardner> njin, boot 3.0-3 and run 'ubuntu-bug linux' with a description of the problem. 3.0.0-5.6 is almost ready as well (-rc7)
<njin> tgardner, many thanks, i'll do it
<bjf> jjohansen, ok as roomie for orlando?
<tgardner> ogasawara, oneiric is done building. would you like me to upload -meta ?
<ogasawara> tgardner: go for it
<jjohansen> bjf: yep
<bjf> jjohansen, ok, i've entered it into the write-only registration system
<jjohansen> bjf: ugh, I can't believe we have to use that system again
<tgardner> ogasawara, uploaded and announcement sent
<ogasawara> tgardner: awesome, thanks
<ogasawara> tgardner: I'll post a blurb to voices.c.c too
<tgardner> ogasawara, hmm, did ubuntu-mobile@lists.ubuntu.com go away? I got a bounce message
<ogasawara> tgardner: it bounced for me as well so I quit sending to it
<tgardner> ogasawara, I guess I'll fix the wiki
<hggdh> smb: there still?
<jjohansen> hggdh: hopefully not, its 22:22 for him
<hggdh> jjohansen: heh. I had to try... will ping him tomorrow, then, thank you
<jjohansen> hggdh: anything I can help with?
<jjohansen> hggdh: I could also rely a message when he comes on in the morning
<hggdh> jjohansen: this is related to bug 790712 -- smb asked for a syslog. But a debian-installer "syslog" shows much of the installer activities, and almost nothing else...
<ubot2> Launchpad bug 790712 in linux "20110531 i386 server ISO: order 5 allocation failure during install" [High,Confirmed] https://launchpad.net/bugs/790712
<hggdh> jjohansen: so I added a d-i syslog to the bug, but I am unsure on what he will find there...
<jjohansen> hggdh: can you add the kernel log as well
<hggdh> jjohansen: there is no kernel log
<jjohansen> hggdh: no kernel log?  How about dmesg?
<jjohansen> is it possible to retrieve that
<hggdh> hum
<hggdh> not directly -- the install never ends, so we do not have control/access to the VM. But I can run it manually here, reproduce the error, and collect it (I hope)
<jjohansen> hggdh: if its doing order 5 allocations, it isn't surprising that it is failing
<jjohansen> hggdh: worth a try
<hggdh> I do not disagree. The thing is 480M should be enough to install an i386 kernel... and it does not happen always
<ogasawara> apw: just fyi, I'm able to post to voices.c.c/kernelteam
<manjo> ogasawara, in delta review Manoj Iyer
<manjo> Quirk to fix suspend/resume on Lenovo Edge 11,13,14,15
<manjo> UBUNTU: SAUCE: (drop after 2.6.38) add ricoh 0xe823 pci id.
<manjo> those two patches can be dropped as they should be in stable already
<manjo> ogasawara, the 3rd one has original author as Timo so I have emailed him to report the status
<bjf> manjo, did you add your comments to the blueprint like everyone else?
<manjo> bjf, not yet ... this was just brought to my attn so going to do that next .. thought I will tell ogasawara 1st 
<bjf> manjo, and actually its the spec at: https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview
<manjo> bjf, thanks yes I know
<manjo> bjf, just updated blueprint
<manjo> bjf, I think ogasawara needs to mod the wiki? 
<ogasawara> manjo: thanks, if you can just make a note of this in the wiki under your section that'd be good.  I'll revert the two patches for now and then drop them upon the next rebase.
#ubuntu-kernel 2011-07-13
 * smb yawns and reads scrollback...
<smb> hggdh, Have not yet looked back at the bug bug mainly I am looking for a full set of messages from wherever you extracted the order 5 messages. Maybe seeing oom killer going for something and/or at least showing memory levels at that point.
<smb> At the time of the order 5 messages it seems like only being bad for higher level allocations but still some reserves for lower orders. Can be related or just a side effect. It is not clear what exactly happens later.
<ppisati> guys, what's the debian/rules "action" to just unpack the kernel and do the config?
<apw> ppisati, as in to make the debuan/build/build-<flavour> with the .config in it?
<apw> ppisati, thats fdr prepare-<flavour>
<ppisati> ok
 * ppisati needs a fdr cheatsheet
<ppisati> btw, there's a clash between one of our option and the TI BSP
<ppisati> basically, i get a solid freeze on boot for some reason
<ppisati> and i'm trying to find what's wrong without copying opver the entire TI .config
<apw> ppisati, if what you are really interested in is the final config then fdr genconfigs makes configs in CONFIGS/* in your tree
<ppisati> isn't .config the final config?
<apw> ppisati, yes, but i am saying if all you wanted was the config then genconfigs makes the same .config contents in CONFIGS/<names>
<ppisati> ok
<ppisati> from time to time pusleaudio goes berserk and i get a "nice" metallic/robotic output... :)
<apw> ppisati, yep, it does do that, good isn't it
<ppisati> yep
 * apw cries at the state of launchpad, even worse than normal
<apw> (Error ID: OOPS-2020DR100)
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=2020DR100
<apw> (Error ID: OOPS-2020DR100)
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=2020DR100
<bryceh> apw, they just did a rollout a few hours ago
<apw> bryceh, i know, and as usual its completely broken for everything i need to use
<apw> literally everything i touch just times out, all my scripting is exploding, i can't nominate bugs, other than that it is purfect
<bryceh> apw, ouch
<apw> yeah they decided to do a h/w change wherein we'll be running on the slave server for a day in parallel to a s/w update
<apw> so they have no idea if the issues are the new code or just the slave not being up to the job
 * apw knows which bucket he would put that decision
<apw> ppisati, ok as we can't use launchpad for CVE coordination ... i am looking at 2011-1010
<apw> ppisati, oh and be warned that http://people.canonical.com/~kernel/reports/kernel-cves.html stopped updating at 7:30 UTC as well
<ppisati> apw: no prob, i'm all for linaro2ubuntu stuff these days
<ppisati> and btw, i just noticed that even the linaro kernel hangs/panics/etcetc on boot
<ppisati> so the issue is somewhere else...
<ppisati> uhmm...
<bastik_> Hi, after automatic upgrade to 2.6.38-10 on natty, my Graphics card (ATI Mobility Radeon X600) stops working. Shall I file a Kernel bug on launchpad?
<apw> bastik_, yes
<bastik_> ok, bye
<smb> ...also point out when filing the bug whether you where using the binary (fglrx) or open source driver (radeon)
<herton> bastik_: also file the bug from the affected machine using 'ubuntu-bug -p linux' (see https://wiki.ubuntu.com/Kernel/Bugs)
<bastik_> thanks for the hints, I have xserver-xorg-video-radeon, this should be the open source package
<bastik_> do you need diagnostic, when old kernel is booted (all is fine then)?
 * ogasawara back in 20
<sforshee> cking, here's a fun problem. Your stap script indicates that the machine hangs in acpi_hw_write_pm1_control() on the way out of s3. Any ideas? bug 708286
<ubot2> Launchpad bug 708286 in linux "Resume after suspend not working - Toshiba Tecra R700" [High,Confirmed] https://launchpad.net/bugs/708286
<cking> sforshee, actually it indicates that we've written to the PM1 control register(s) and the machine suspended. that was the last thing we saw. If it did not come out of resume I suspect we did not re-enter the kernel
<sforshee> that does make more sense
<sforshee> cking, so is there anything more to try with that machine? or is it a hopeless case?
<cking> sforshee, we can see if it enters the kernel.
 * bjf -> dr. appt.
 * herton --> lunch
 * smb -> pint
 * apw looks at smb with envy
 * smb drinks one for apw
<apw> jjohansen, flys like a rocket ship ...
<jjohansen> hehe, well we are getting to the end of the pastable text
<ppetraki> smb, yeah, that bug isn't resurfacing. what I think happened is I continue to run proposed kernels  in response to the s4 video corruption bug I found. Then kernel was upgraded since my return from Dublin and that bug is either fixed or covered up
<ppetraki> smb, 100 s3, no fault found
<tgardner> kees, what was the name of the tool that removed the U3 partition from a SanDisk Cruzer USB stick ?
<kees> tgardner: u3-tool :)
<tgardner> kees, ah, cool. thanks.
<kees> tgardner: specifically u3-tool -p0 /dev/whatever
<kees> (the raw device, not a partition, iirc)
<tgardner> yep
<kees> ogasawara: pcap issue is 810022 (I still need to check it out). kptr issue I addressed with procps 1:3.2.8-10ubuntu5, and hggdh didn't hit it in his testing, so I think we can ignore that for now.
<kees> ogasawara: if there is a CONFIG option for kptr, it'd be nice to turn it on, though.
<kees> ogasawara: but I don't think there is
<ogasawara> kees: cool.  I'll investigate if there's a config for kptr.  I know the commit message mentioned setting it in /etc/sysctrl.conf if distro's wanted in enabled by default
<kees> ogasawara: yeah, unless it went in the last month, I don't think there is, which is fine. procps will cover it
 * bjf -> dentist
<mjg59> apw: I thought 83ccc92aa7bc9b9d47fc31a7b54e663fb9a3d992 wasn't supposed to end up being shipped?
<mjg59> (natty, cd1c7d22c84faf5513e53d0e5618c9b9a3e3824f in oneric)
 * jjohansen lunch
<tgardner> sforshee, tangerine is back
<sforshee> tgardner, cool, thanks
 * tgardner --> EOD
<chrismsnz> Hi guys, I have a question about bug #586897 - apparently the patch has been released and merged into mainline kernel, is this appropriate for lucid kernel backport and next install media update for lucid?
<ubot2> Launchpad bug 586897 in linux "stex driver (Promise SuperTrak 8350/4650,etc) produces drastic I/O errors/corruption with 10.04 or later" [Undecided,Confirmed] https://launchpad.net/bugs/586897
<chrismsnz> it's regarding a popular piece of RAID hardware
<jjohansen> chrismsnz: maybe, we will have to look at the patch etc, but if the patch is upstream and fixes a real problem for lucid it is something we do want to evaluate
<jjohansen> chrismsnz: whether it goes into the lucid kernel or just the currently supported backport kernel will depend
<bjf> chrismsnz, the kernel for the next lucid point release has already been uploaded so that patch won't make it in
<chrismsnz> jjohansen: good to hear - is this done as part of a process that will happen on it's own or do I need to follow up?
<chrismsnz> bjf: i see
<jjohansen> chrismsnz: lucid has a long life, there are also the backport kernels.  With the patch going into 2.6.36.3 this should be automatically picked up in our newer kernels as long as it doesn't coincide with anything causing regressions.
<bjf> chrismsnz, looking into the git repo to see if it has already been picked up
<jjohansen> chrismsnz: their should be a natty backport kernel to lucid that will have this, if its going to go into the Lucid kernel there will have to be more followup
<chrismsnz> jjohansen: ok - is there a supported way to use a backport kernel on the install media? The nature of this bug is such that it will install a completely broken system
<jjohansen> hrmmm, no that is a problem.
<jjohansen> chrismsnz: it would be possible to create a custom usb/iso but that isn't a generic solution
<chrismsnz> probably the best solution is to install 9.10 and upgrade to Lucid, then install backported kernel before rebooting
<jjohansen> chrismsnz: yeah, the next lucid point release is scheduled for  July 29, 2011
<jjohansen> chrismsnz: so the patch is already in the natty kernel
<chrismsnz> righto - looks like a karmic -> lucid upgrade, then install the natty backported kernel is the best way to get this system running lucid
<chrismsnz> it's running karmic at the moment so no biggie
<chrismsnz> I'll update the bug
<bjf> chrismsnz, that patch is already in the lucid kernel
<chrismsnz> bjf: that's surprising news - was the work done under another bug?
<bjf> chrismsnz, looking
<chrismsnz> bjf: also, does that mean the new lucid install media being released July 29th will contain the fix?
<bjf> chrismsnz, it was picked up as a regular stable update patch set in january, yes it will be on the next media
<bjf> chrismsnz, bug 705045
<ubot2> Launchpad bug 705045 in linux "Lucid update to 2.6.32.28+drm33.12 stable release " [Medium,In progress] https://launchpad.net/bugs/705045
<chrismsnz> that is excellent news
<chrismsnz> thank you both for your help, I'll update the bug and suggest it for closure once I can test it
<psusi> ok, I need someone to either talk me off the cliff, or join me in my crusade:  seriously, it is 2011 and the Linux kernel still can not handle surprise removal of a drive/media.  discuss.
<chrismsnz> surprise removal of a non-hotswap drive?
<psusi> eject a cdrom even
<psusi> put a cdrom in, open a file on it ( maybe just cd a terminal to a directory on it ) and eject it... shit hits the fan
<psusi> specifically, the fs can't be unmounted because it has open files, so it is lazily unmounted, which means it is just removed from the fs namespace... but still remains mounted as long as the open fd(s) exist... then you drop in a new cd, and you can not mount it because the old one is still mounted
<psusi> things get even worse when you actually unplug a disk ( think usb flash stick ), especially if it has a raid or lvm on it
<psusi> the kernel underwent a serious transition where the device driver layer got reworked to the bus/driver model that supports plug and play, but the block layer is still living in a non plug and play world
<psusi> you remove a device ( echo 1 > /sys/block/sda/device/delete ) and the device vanishes from the namespace, but is not actually deleted until it is no longer in use... it can't signal to a fs or md or dm driver on top of it that it needs to go away now, stop using me
<chrismsnz> D:
<chrismsnz> I guess I've been conditioned after so many years of Linux use just to not attempt those things
<psusi> so there it sits, in a zombie state, not there as far as you can see, but not gone until the last reference is dropped
<psusi> it is really easy to forget if you have rhthmbox playing an mp3 on a cd, and hit X and it just gets rid of the window, but doesn't actually close.. if it was on pause and still has the mp3 open, everything looks cool so you eject the disk... but it's very much not cool
<psusi> the system really needs to be able to deal with surprise removal in a post plug and play world
<psusi> and the whole plug and play revolution started with windows 95... it's more than 15 years later and linux still isn't there... urgh...
<psusi> must fix this...
<psusi> 15 years.... crap now I feel old.
<jjohansen> psusi: it started long before win95, and yes its unbelievable that this isn't handled well still
#ubuntu-kernel 2011-07-14
<psusi> jjohansen, so let's figure out how to handle it ;)
<psusi> the kernel needs some way of notifying the clients ( fs, md, dm, blockdev ) of the block device that it either wants to be , or already has been ( requested or surprise ) removed so they can release the bdev pointer.  that seems a wee bit problematic by the fact that multiple clients can have references...
<jjohansen> psusi: yes its problematic
<apw> mjg59, the original was pulled as it was generic, that one is restricted to two models of dell where the touchpad doesn't work at all with alps, thats my memory anyhow ... causing issues ?
<smb> morning
<apw> morning
<jk-> hey smb & apw
<smb> hey jk- 
<cking> yawn
<apw> cking, morning
<cking> apw, hiya
<apw> cking, hows it going ...
<cking> fine
<mjg59> apw: Well, it still doesn't work at all with alps in any real way
<mjg59> apw: You're still just changing one non-configurable setup for another
<apw> mjg59, the patch as commited only applies to those specific models but yes its crap
<apw> mjg59, i am told that alps refuse to disclose how to enable the touchpad correctly as a touchpad
<mjg59> You end up with something where you can't turn off tap to click, which may or may not be preferable to the original state
<apw> mjg59, yeah i get you, cause its not a touchpad that option doesn't exist, sigh
<mjg59> Right
<mjg59> ALPS seem to believe that their multitouch protocol is a massive trade secret
<mjg59> And it's annoyingly inconvenient to trace PS/2
<apw> i can only call the whole mess, well a mess
<apw> yeah ... we are pushing vendors to use something else for their linux enabled stuff, they are just too painful to talk to
<mjg59> But Dell aren't willing to push ALPS because that patch exists and is carried by Ubuntu
<apw> mjg59, great indeed
<mjg59> So kind of an awkward situation for everyone
<mjg59> I should look into whether I can work out the init sequence using qemu, really
<apw> if you have the kit yeah that would be a good plan me thinks
<ogasawara> hrm, anyone recall if bjf had a script which closed a bugs task that has a nomination which is EOL
<ogasawara> I'm particularly looking at https://bugs.launchpad.net/ubuntu/karmic/+source/linux
<tgardner> ogasawara, seems like he's been running something lately since I've seen a bunch of those kind of closures.
<apw> ogasawara, if not it should be a trivial one to write
<ogasawara> apw: indeed, was just hoping to save myself the 10min since I'm lazy
<ogasawara> I'll just wait till he comes online
<ogasawara> I'm thinking that whatever creates the CVE bugs should also drop adding karmic as a target, if it's not already fixed that is
<apw> ogasawara, ok i've finally rememberd to add that section to the config review, with the modulular things which are not modular
<apw> ogasawara, i believe we already have stopped adding karmic for cves
<apw> ogasawara, and my script should be closing them out, do you have an example of a non-won't-fix one ?
<ogasawara> apw: I actually meant to say if the script wasn't already fixed, it should be
<apw> ogasawara, i believe it is suppressed by the karmic being mark Supported: false
<apw> ogasawara, https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricConfigReview#Non-modular_modules is the full list which needs review.  not sure how we should handle the review part, prolly needs a wi
<ogasawara> apw: cool.  I'll add myself a work item to start sifting through them.
<apw> ogasawara, last week we found a page which had your report on it for the bugs for the meeting, since then the link seems to have gone dead in th
<apw> the readme, did it move ?
<ogasawara> apw: can you point me to which README?
<apw> kteam-tools/irc-meeting/README
<ogasawara> apw: hrm, I'd been using http://reports.qa.ubuntu.com/reports/ogasawara/kt-meeting.txt but I do recall I should have move it from my own personal directory to the kernel-ppa/reports
<apw> ogasawara, would it run on people? as most of the reports are there
<ogasawara> apw: I don't see why know, I'll move it there for consistency and update the README
<ogasawara> wow, s/know/not/
<bjf> ogasawara, we talked about adding it to the Makefile that generates all the reports
<ogasawara> bjf: yep, makes sense
<ogasawara> bjf: also before I forget, didn't you say you had a script which closes out a bug task for a nomination that is not EOL
<bjf> ogasawara, if that did/does happen, I'll need to update the copy of kteam-tools in people/~kernel
<ogasawara> bjf: i was looking at https://bugs.launchpad.net/ubuntu/karmic/+source/linux
<bjf> ogasawara, i was "won't fix"ing bugs last night that were filed against dapper, feisty, and intrepid
<bjf> ogasawara, i don't have one that changes nominations for tasks that are EOL (but I should)
<apw> ogasawara, let me know when you are done fiddling with kernel i have something to add too
<ogasawara> bjf: ok no worries, I'll whip up a script to close out EOL nominations
<ogasawara> apw: ack
<apw> bjf, i assume the "plan" is to check everything into team-tools, and then rsync it over the one in ~kernel ?
<ogasawara> bjf: I assume I can edit the Makefile the same as I did when I added my CVE report
<hggdh> bjf: just confirming, the only other kernel for us (QA) to test now is Hardy, correct?
<bjf> apw, yes, that's how I do it
<bjf> ogasawara, yes
<apw> bjf ok cool
<bdmurray> apw, ogasawara: I've uploaded a new version of kerneloops which should *not* report WARNINGs.  I'm working on the driver tagging today.
<ogasawara> apw: go ahead and add whatever you need to kernel, I have to tweak my script I think
<bjf> ogasawara, look at mark-unsupported-wont-fix in kteam-tools/bugs 
<bdmurray> apw, ogasawara: so if you happen to see any Oopses with warnings in them let me know.
<bjf> hggdh, you have to ask sconklin 
<ogasawara> bdmurray: awesome, thanks
<bjf> bdmurray, are you prefixing the driver tags with "kernel-" or anything, or is it just the driver name?
<bdmurray> bjf: just the driver name
<bdmurray> I gave ogasawara a list of the existing oopses I tagged
<bjf> bdmurray, if ogasawara and apw agree, I think it should be prefixed with "kernel-driver-"
<ogasawara> bjf: that's fine with me, I just had bdmurray originally tag by driver name just for simplicity
<bjf> ogasawara, since we are prefixing all our other tags with "kernel-" and since I think it makes it more clear what that tag is for, it would be nice to have the prefix
<ogasawara> bjf: makes sense
<bjf> ogasawara, i can also put together a report based on just "kernel-driver-*" bugs at some point
<bdmurray> I guess it would be easier to find new ones too
<ogasawara> bjf: that would be nice
<bdmurray> rather than if something just got tagged e1000
<herton> hggdh: not only hardy, including it these bugs are waiting for QA: 801636 806586 808934
<bdmurray> bjf: I'll try and find whatever I wrote to tag the existing Oopses and retag them with kernel-driver-fglrx (or whatever)
<bjf> bdmurray, that would be great, thanks
<bjf> bdmurray, maybe after whatever changes you make this time and after this run of it, we should take it into our tools repo and maintain it ?
<hggdh> herton: thanks. I was not aware we were doing backporting tests also
<herton> hggdh: I'm not sure what is done about lts-bakckport packages also regarding QA
<bdmurray> bjf: so the plan is to modify apport so that oops are tagged kernel-driver-drivername when the oops is being submitted.  This is just cleaning up the already reported stuff so really should be a one time thing.  Additionally, its a mess of parsing Oops reports that I've downloaded
<bjf> bdmurray, ah! ok, that makes sense
<hggdh> <sigh/>
<bjf> bdmurray, disregard my earlier comment, still waking up
<herton> hggdh: steve mentioned that for backport packages teams have to sign-off on them also, so I guess it is up to you, but better confirm with him later
<hggdh> herton: I just wish I got to be informed of things that affect QA
<apw> hggdh, don't the tasks in launchpad tell you things you need to be concerned with ?
<hggdh> apw: not enough of a warning, if you add in unplanned-for work
<apw> hggdh, so what sort of warning are you looking for
<hggdh> apw: something like 'hey QA, we are going to add backporting tests to your expected work load, how about getting ready to it?' <- in advance
<apw> hggdh, are we talking about lts-backport-foo here ?
<hggdh> apw: bugs 806586 808934
<ubot2> Launchpad bug 806586 in kernel-sru-workflow/security-signoff "linux-lts-backport-natty: 2.6.38-10.46~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/806586
<ogasawara> bjf: do by chance know if lplib has a way of retrieving a list of current supported releases, so I don't have to maintain a hardcoded list like "releases = ['oneiric', 'natty', 'maverick', 'lucid', 'hardy']"
<bjf> ogasawara, in kteam-tools look at ktl/ubuntu, also look at the script i mentioned earlier, it calls a method to determine "support"
<ogasawara> bjf: cool
<bjf> ogasawara, basically, we already maintain a master list and it's in ktl/ubuntu.py
<apw> hggdh, ahh my understanding of why we are passing those your way, is cause you were signed up to do them
 * herton -> lunch
 * ogasawara back in 20
<apw> ogasawara, where can i find your current report, want to look at the format
<paultag> Hey kernel-ers. I've been testing btrfs for the cycle, and it's gotten to the point of horrid IO times, to the point where bootup is taking much longer then it should (2.6.38-8-generic-pae) -- has anyone heard anything about IO speeds on the +1 kernel, or upstream?
<paultag> It feels like I'm back in 2004 :)
<apw> paultag, nothing specific other than a general feeling that as they fix consistancy issues in btrfs it is losing its performance edge
<tgardner> paultag, have you tried oneiric? a lot of work has gone into btrfs this cycle
<paultag> tgardner: I have not, I'm still on natty. Should I consider it?
<paultag> apw: well that's good anyway :)
<paultag> Is there any way I can dump some sort of profile or set of statistics that might help development upstream?
<tgardner> paultag, absolutely. you can run the oneiric kernel without having to change your user space.
<paultag> tgardner: sure, sure :)
<paultag> Also, I do have one other, perhaps related, issue. Once in a while, after the screensaver's been on and DPMS shuts off the screen, the kernel locks up (not sure if btrfs blocks or fails a read, and it's stuck waiting for IO, or if it's kernel it's self, but I don't recall this with ext4), and will only respond to a REISUB. Does anyone have advice on how to debug this, and put together a sane report?
<paultag> it's fairly reproducable, and it always happens when I need my machine in a bad way :)
<paultag> (then I have to put up with a horrid boot time, welcome to my hell)
<apw> paultag, is it always when DPMS has triggered, there was/is a problem with vsync not restarting and breaking compiz
<ogasawara> apw: http://people.canonical.com/~kernel/reports/kt-meeting.txt
<paultag> apw: I seem to recall one time seeing the screensaver frozen, but that could have been some sort of race condition. I also have two monitors if that helps debug anything
<paultag> apw: should I upgrade a package or two and test if it is vsync?
<apw> paultag, i guess i'd wnat to know if you can login remotly, that'd be the first test
<paultag> apw: good point. I'll install ssh and wait for it to happen, then let ya'll know. Since I REISUB, I'm guessing the kernel's online, and it does not look like a panic, so it *should* work
<paultag> apw: cheers, thanks!
<apw> np
<ogasawara> bjf: how often does the cron on lillypilly run for the kernel reports?
<ogasawara> bjf: nm, every 30
<apw> bjf, is this in a tabalable form for the irc converter: http://people.canonical.com/~apw/cve/pkg/CVE-linux.txt
<bjf> apw, yes, any "moin table" format can be handled
<apw> at rally we talked about reporting something in the weekly meeting on CVEs and that seems like the sort of thing, what you think
<bjf> apw, that looks good to me
<apw> ok will get that into the readme while i am at it, if you could add to the agenda
<apw> probabally belongs in the 'stable' section
<bjf> apw, ack
<bjf> apw, who should i put as the reporter? you for now?
<apw> bjf sure
<ogasawara> what are the devel and mainline branches of kteam-tools?
<bjf> ogasawara, ignore "devel", i think sconklin created it
<apw> ogasawara, yeah i work against the master always ... ps i just updated the README for irc so we are likely to collide
<apw> bjf, i've added moveing the CVE stats and the CVE report over to ~kernel for my 'next week' todo list
<ogasawara> apw: ack, I'll rebase and push
<bjf> apw, ack, added agenda item to wiki page and to the runes
<ogasawara> apw: did you push your bits up yet?
<apw> ogasawara, yep
<apw> feel free to just merge it and fix the README
<apw> we are used to a mergetastic history
<ogasawara> apw: I'm not seeing your bits on kteam-tools master
<apw> ogasawara, brad found them, merged with them and pushed again
<apw> so i assume they are up there
<ogasawara> apw: ah that makes sense then, I was looking for you as the author
<herton> ogasawara: devel is some experimental things we have been playing with (changes to sru workflow), just ignore it for now
<apw> bjf, ubuntu.supported_serieses ?? really, is not the plural of series series ?
<bjf> apw, yes, thanks for pointing out i can't spell
<apw> bjf, heh its bad if i spell better than thou
<bjf> apw, i blame being drunk but I know you wouldn't believe that
<ogasawara> hehe, I saw that too and chuckled
 * smb decides to end the day
 * apw cracks a cold one in sympathy
 * tgardner yanks the power to a noisy fan
 * apw calls it a day ... see your all next week
<jjohansen> have a good weekend apw
<tgardner> apw, what is the derby thing ?
 * tgardner --> lunch
<vanhoof> hey guys -- quick question :)
<vanhoof> latest oneiric kernel brought in the isci driver for newer intel sas controllers
<apw> tgardner, fun is all
<vanhoof> is there a process i should follow to request they be pulled into the initrd for installs?
<apw> tgardner, updated it ... better ?
<vanhoof> disregard my question :)
<bdmurray> bjf: I'm to lazy to remove the existing tag so I'll just add kernel-driver-ipaq and leave ipqa
<bdmurray> er ipqa
<bdmurray> wtf ipaq
<bdmurray> there!
<bjf> bdmurray, ok
<bjf> apw, did you pick a usb drive? i just picked up a Patriot Rage XT (8G). Avg. read rate: 31.6MB/s Avg write rate: 5.8 MB/s   
<ohsix> did natty stop logging to /var/log/messages? :O my confings didn't change but theres no messages in there since march
<ohsix> nm
#ubuntu-kernel 2011-07-15
<hggdh> kees, sconklin: please see bug 810807 on the Maverick backport to lucid
<ubot2> Launchpad bug 810807 in linux-lts-backport-natty "kernel-test-security multiple errors on backported Maverick kernel" [Undecided,New] https://launchpad.net/bugs/810807
<kees> ohsix: yeah, it moved to /var/log/syslog iirc
<kees> hggdh: oh, er, yeah. they are inverted tests. it's checking the release not the kernel
<kees> hggdh: e.g. CONFIG_DEBUG_SET_MODULE_RONX is enabled (a good thing) when it wasn't expecting it for lucid.
<kees> hggdh: let me work on that and get the tests updated. that's going to take a bit of work...
<paultag> apw: poke, if you're about
<paultag> apw: my desktop dropped back into the failure mode. I was able to ssh in, and check up on it. Turns out compiz is taking up 100% of one core, and xorg is taking up 100% of another.
<paultag> apw: is this what happens with the vsync bug?
<paultag> process (compiz) is stuck in state "Rl"
<RAOF> If you're thinking of âdisconnecting outputs can cause vblank events to be missedâ, then, no, it's not that bug.
<paultag> Ah, thanks RAOF. He suggested that as what might be going on with my box.
<paultag> humm, it looks like compiz is just oustandingly borked
<RAOF> The symptom of that bug is that compiz is not taking up CPU because it's waiting in the kernel for a vblank event that will never arrive.  It can do that quite efficiently :)
<paultag> RAOF: gotcha. Not kernelspace at all :)
<paultag> RAOF: cheers, thanks for the help, I'm outa here!
<hggdh> kees: cool, no problem
<bliss> kees: better start brainstorming on how to give users the option of opting in to mainline PAX_USERCOPY, which has a 6-9% performance hit on some benchmarks :-/
<bliss> vasiliy is making some good headway i think
<kees> bliss: yeah, been watching that. :)
 * smb yawns
<jk-> hey smb
<smb> heya :)
<tk`> can someone help me setup kdump on ubuntu
<tk`> kdump doesnt seem to start after panic. crash kernel loads though
<tk`> i'm running maverick 2.6.35-28
<awilkins> #776964 : compiling my own kernel again. Frowny face.   ;-P
<hggdh> good morning to all. If I may ask, why isn't there a Natty backport for server-i386?
<smb> hggdh, if you mean a flavour -server? That would be generic-pae...
<ogasawara> awilkins: just posted a comment to your bug regarding status of the patch
<awilkins> OOh, ta
<ogasawara> awilkins: it took us a little longer to get the first natty update out the door due to regressions, but your patch should land in the next round of updates.
<awilkins> It's ok, my local build has finished... discovered a workaround in the process of patching it also, so wasn't a showstopper, used HDAanalyzer to tweak the pin config parameter so I could use sound card today
<awilkins> But at least now I won't have to build another kernel
<ogasawara> sconklin: do you guys keep a list of bugs to shove in the changelog when you close a release so it gets auto closed by the janitor when you upload?  or would you prefer I just add the BugLink to the commit and re-push to the repo.
<ogasawara> re: bug 776964
<ubot2> Launchpad bug 776964 in linux "p5n32e-plus HDA Nvidia AD1988B microphone input not working" [Low,Fix committed] https://launchpad.net/bugs/776964
<sconklin> ogasawara: we don't actually have any defined process for getting bug numbers into the changelog if they don't get put into the SRU request. This is mostly because we don't have a good way to associate fixes with existing bugs. This is a problem that needs solving. We usually just leave it to the reporters to close them.
<sconklin> ogasawara: but the worst part of all that is that reporters don't get notified when something is in -proposed that might fix their issue
<ogasawara> sconklin: right.  do the scripts which shove a comment into the bug regarding testing, I assume it parses the changelog?
<sconklin> actually, no. I think It only hits bugs which are tagged as needing verification. And this isn't all that well scripted and requires manual work. In the case of upstream patches we get via a longterm release, there's only one bug open for all those patches, and we don't associate other bugs like the one you linked
<ogasawara> sconklin: ah
<sconklin> This whole area is probably the next big area we need to focus on
<sconklin> We had a similar problem determining when upstream commits close CVEs, but the security team handles that now afaik
<ogasawara> seeing as this patch came to us through stable, so I supposed I could mark it as a duplicate of the master bug which covered the pull from stable
<sconklin> that will get it closed, it won't result in messages to the bug. But - good idea
<sconklin> and that's a really good solution until we do something better
 * ogasawara back in 20
<tgardner> sconklin, herton: I'm pushing a change to the LTS branches in Lucid that fix some udeb/firmware problems reported by Etienne.
<herton> tgardner: ack
<tgardner> herton, be sure to commit the new files that are copied by debian.maverick/etc/update-from-maverick-master:
<tgardner> debian.maverick/d-i/exclude-modules.amd64-virtual
<tgardner> debian.maverick/d-i/exclude-modules.i386-virtual
<tgardner> same with natty
<herton> hmm ok, yeah I remember we had to add some extra files to commit already, we will note this ones as well
<herton> perhaps the script could do git add on them automatically
<tgardner> herton, it does automatically add files that are under git control, but doesn't typically add new files. this is a one time thing (for now)
<herton> yep, it could do the add of required new files, if possible (don't remember the exact details, I think it's possible to do)
<ogasawara> anyone else notice launchpad throwing away their comment if setting status and importance at the same time?
<cking> more pain, less gain
<tgardner> herton, there really shouldn't be that much churn with the backports from released kernels, so I'm not sure its worth the complexity in the update script.
<johanbr> cnd: I read you've developed some clickpad patches. In your opinion, what's the proper way to support clickpads (bug 582809) ?
<ubot2> Launchpad bug 582809 in linux "Synaptics Clickpad touchpad buttons are not working" [High,Triaged] https://launchpad.net/bugs/582809
<johanbr> Seems like there's a divergence of opinion on whether kernel patches are needed.
<tgardner> ogasawara, do you know how to change the focus in a bug report from the upstream package to the Ubuntu package so one can make release nominations ?
<tgardner> e.g., bug #509180
<ubot2> Launchpad bug 509180 in ecryptfs "ecryptfs sometimes seems to add trailing garbage to encrypted files" [High,Fix released] https://launchpad.net/bugs/509180
<ogasawara> tgardner: I usually hand edit the url
<tgardner> ogasawara, hmm, I tried that. what you you change it to ?
<ogasawara> use https://bugs.launchpad.net/ubuntu/+source/linux/+bug/509180
<ubot2> Ubuntu bug 509180 in ecryptfs "ecryptfs sometimes seems to add trailing garbage to encrypted files" [High,Fix released]
<tgardner> ah, I missed the +source
<tgardner> ogasawara, shit, what a ginormous pain in the ass that is.
<ogasawara> tgardner: totally
<ogasawara> tgardner: not intuitive at all
<herton> kees: I think you wanted to change Security-signoff to Invalid in bug 806586, instead of "linux-lts-backport-natty (Ubuntu)" ?
<ubot2> Launchpad bug 806586 in kernel-sru-workflow/security-signoff "linux-lts-backport-natty: 2.6.38-10.46~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/806586
<ogasawara> ppisati: have you had a chance to investigate https://bugs.launchpad.net/ubuntu/+source/linux/+bug/806113
<ubot2> Ubuntu bug 806113 in linux "Series of segfaults early in the kernel boot process on omap." [Undecided,New]
<ogasawara> ppisati: it was just raising in the release team meeting
<ogasawara> s/raising/raised/
<ppisati> ogasawara: nope, let me see
<kees> herton: thanks! I don't know how I managed to click that :( fixing
<cnd> johanbr, it's been a while since I've looked into clickpads in detail
<cnd> off the top of my head I think there really doesn't need to be any extra kernel patches to get the functionality people want
<cnd> it can more easily be handled in xserver-xorg-input-synaptics
<johanbr> right
<cnd> but that's really off the top of my head
<cnd> so don't hold me to it if I'm forgetting an important detail :)
<cnd> it appears anything to do with synaptics and multitouch is a big pita
<johanbr> for the synaptics driver, something like https://patchwork.kernel.org/patch/92435/ I guess
<johanbr> I think I'll try building a synaptics driver with that patch for testing, then bug the X guys
<johanbr> thank you!
<cnd> johanbr, that kernel patch has been thrown around a lot
<cnd> I think there's good reason why it's not in the upstream kernel tree by now
<cnd> but I couldn't tell you what that reason was
<cnd> I can only guess that people thought it was better handled in userspace
<johanbr> sorry, wrong URL... I meant http://patchwork.freedesktop.org/patch/3160/
<ppisati> ogasawara: just tested latest oneiric/master and booted ok
<ppisati> ogasawara: i guess latest rebased to -rc7 solved it
<ppisati> s/rebased/rebase/
<ogasawara> ppisati: cool, care to just post a comment and close out the bug
<ogasawara> ogra_: ^^
<ogra_> awesome !
<ppisati> done
 * ogra_ loves self-resolving bugs
<ppisati> :)
<cnd> johanbr, yeah, that looks like a good starting point :)
 * ppisati -> gym
<ppisati> have a nice weekend
<ppisati> see you
<hggdh> sconklin: all tests on bug 806586 are failing the same way; this seems to be a test script issue. If kees agrees to, I can mark the QA task complete and qa-testing-passed
<ubot2> Launchpad bug 806586 in linux-lts-backport-natty "linux-lts-backport-natty: 2.6.38-10.46~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/806586
<sconklin> hggdh: looking. Let's not force a pass unless we understand what's happening
<sconklin> hggdh: is it only the security tests which are failing?
<hggdh> sconklin: indeed, this is why I stated 'if kees agrees'. With no postion from him I will tag it failed
<hggdh> sconklin: yes
<sconklin> ok, I agree that it's his call (kees)
<kees> hggdh: I'm so close to having it fixed. been working on it all morning
<hggdh> kees: I am ok on waiting
<kees> hggdh: I've got it down to 2 failures, and should have it finished soon.
<kees> hggdh: cool, thanks.
<kees> hggdh: okay, it's a really massive change, but I've tested on all my KVM instances and on the natty backport kernel. I haven't retested on ARM or weird stuff (xen, etc) so there might still be some subtle fixes needed, but qrt rev 1347 should work for the backport kernel now
<hggdh> kees: thanks, I will update the tarball and try again (including xen)
<kees> hggdh: thanks! let me know if anything looks weird. I think I've got the nastier of the corner-cases already (mostly relating to kptr_restrict and its change)
<hggdh> kees: certainly will ;-) as an aside, all 8 failures were indeed due to checking on ubuntu version?
<bliss> kees: so, what do we do about inet_diag (re: kptr_restrict)
<kees> hggdh: yeah
<kees> bliss: magic randomized id numbers?
<bliss> specifically, getting david miller to accept that
<kees> I thought that was his idea?
<bliss> he seems resistant to the whole thing
 * herton --> eow
<hggdh> kees: seems to work perfectly on xen also :-)
<hggdh> kees: thank you, sir
<bjf> ogasawara, around?
<ogasawara> bjf: yep
<bjf> ogasawara, seems like this team should probably die: Ubuntu Kernel ACPI Team  https://launchpad.net/~ubuntu-kernel-acpi
<ogasawara> bjf: wow, didn't even know we had such a team
<bjf> ogasawara, exactly
<ogasawara> bjf: you'll probably have to get Tim to delete the team since he looks to be the admin
<hggdh> sconklin: OK. Almost ready to end on bug 806586. Xen i386 shows http://pastebin.ubuntu.com/645023/ which, I guess, is sort of expected. But I want confirmation on it, if you do not mind
<ubot2> Launchpad bug 806586 in linux-lts-backport-natty "linux-lts-backport-natty: 2.6.38-10.46~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/806586
<sconklin> hggdh: yes that's expected for this release. The fix is already committed for the next release
<sconklin> so that's a pass
<hggdh> sconklin: roger. Thank you. Tagging it a pass.
<kees> hggdh: \o/
<hggdh> kees: again, thank you :-)
<kees> hggdh: you bet, thanks for doing the testing :)
<lool> Hey, I'm trying to narrow what regressed in linux to cause https://bugs.launchpad.net/ubuntu/+source/linux/+bug/811214 but I don't think I can bisect across Ubuntu rebases, and I'm not sure how to generate a config sensible for mainline
<ubot2> Ubuntu bug 811214 in linux "Hangs while suspending with iwlagn on Intel Corporation PRO/Wireless 5350 AGN [Echo Peak]" [Undecided,New]
<lool> any advice on setting things up?
<lool> hmm apparenlty bisect will take the tree as a base
<lool> ok, it is not working simply because I need the packaging stuff to build .debs
<lool> because I have LVM, I need an initrd and that makes things rather painful to iterate over
#ubuntu-kernel 2011-07-16
<slava__> Hello!
#ubuntu-kernel 2011-07-17
<omry> hi, how do I change the size of /dev/shm ?
<hyperair> try mount -o remount,size=blah /dev/shm
<dupondje> Should vga_switcheroo work for all devices with dual vga?
<dupondje> Got a Nvidia/Intel combo, but switcheroo doesn't seem loaded
<jwi> http://xorg.freedesktop.org/wiki/RadeonFeature <-- see note 6, i would assume that there's similar MUXless designs by nvidia
<dupondje> what kernel version is the current natty kernel based on ?
#ubuntu-kernel 2012-07-09
 * smb yawns
<_ruben> good idea
<cooloney> smb: morning
<smb> cooloney, morning
<TomGLU> hi I came across a ext4 bug (returning too large d_off values) in the 3.4.4 kernel
<TomGLU> where should i report this?
<smb> TomGLU, start a report by running "ubuntu-bug linux". From there it depends ... If you got something that can produce the error on demand, make sure to describe it as well as possible.
<TomGLU> its something we cam across that trigger problems in glusterfs
<TomGLU> one of there developers could replicate it on a KVM iameg using the same kernel
<TomGLU> because we used linux-image-3.4.4-030404-generic not precise it saids "The problem cannot be reported:"
<TomGLU> *not=on
<TomGLU> "This is not an official Ubuntu package." but we got the image from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4.4-quantal/
<_ruben> those aren't official ;)
<_ruben> when it comes to support that is
<smb> Right, it should be reproducible with the official one
<smb> Though it can be that it might become a regression. Any reason to run mainline kernels? Those should only be used to narrow down issues...
<smb> TomGLU, Anyway you should try to reproduce it with a current quantal kernel
<smb> (which would also make sure it is still there)
<TomGLU> used because we needed a libvirt kernel bug fix that wasn't included in the default precise kernel
<TomGLU> and i don't need support I just want to let the ubuntu kernel team know so it might be fixed or can be checked in more recent versions
<TomGLU> so were do I submit this so I can detail what the issue is and maybe others can reproduce in other versions
 * apw yawns
<smb> Support here rather as in what kernel versions to considered as supported. There is already a lot of complexity trying to maintain the official kernels. Its just impossible to consider self-compiled ones. Thanks for telling us about it. It would be great if you (or whoever did reproduce it in a kvm) could do the same with  a quantal install with the up-to date official kernel and report this.
<smb> As said before, that would allow to see whether this is possibly already fixed upstream (as the quantal kernel is really close to that)
<smb> apw, Morning
<cking> morning apw
<TomGLU> I'll try if i can do it on a VM as we can't try it on the original machine, 
 * apw waves
<TomGLU> and ubuntu-bug linux is the only way to report it or si there an bug system i can submit the issue manually?
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<smb> TomGLU, Sure, that would be awesome. And also it would allow the ubuntu-bug submission. It is also possible, but ubuntu-bug also automatically gathers a lot of machine information and log files.
<apw> in an emergency you can file it that way, but the bots willhastle you for lots of information
<smb> But you can do manually as apw says
<TomGLU> ok I'l investigate it in a VM first then and try to report it with ubuntu-bug
<smb> Thanks. I did a quick glance over the recent ext4 commits and (while certainly not in depth) it did not look as something similar was worked on. So I would believe that it would still exist.
<cooloney> apw and cking, morning
<ppisati> moin
<cooloney> ppisati: morning
<apw> cooloney, ppisati, moin
<apw> recursive hello death
<apw> smb, xen-blkfront breaks in -rc6 something to do with the compute node performance thing we are carrying for EC2, it looks easy to fix but it will need a test after i push it
<smb> apw, Hm yeah, that was something we wanted to look at anyway. But sure I can test it when you have a kernel (or I do one after the push)
<apw> it looks trivial to fix, so i suspect it'll be fine, but knowing we've tested and are alive is always good
<smb> Oh I agree. You never know what else broke...
<cooloney> apw: if an config option's policy is =m, but we found this config option is mostly useless, can we change the policy? like CONFIG_GPIO_EM
<cooloney> it is 'Say yes here to support GPIO on Renesas Emma Mobile SoCs'
<apw> cooloney, if it is patenty useless on everything i can annotate it so
<apw> sounds liek something which should be just 'n' across everywhere indeed
<caribou> smb: morning
<smb> caribou, Hey Louis
<cooloney> yeah, for CONFIG_GPIO_EM is only for Renesas ARM Emma Mobile SoCs, so we are safe to set it as =n for everyone
<caribou> did you get any further with your kdump issue ?
<apw> cooloney, yes for things which are useless building a module nothing can load is definatly dumb
<caribou> smb: I'm downloading the Quatzal daily to test on the latest version
<apw> cooloney, want me to annotate that =n now ?
<cooloney> apw: yeah, thanks, i just found it is red in our review wiki page. 
<cooloney> and it because the policy is =m, but we got everyone =n as we expect
<smb> caribou, Right, I just tried with crashkernel=128M and that seems to solve the problem 
<apw> cooloney, CONFIG_GPIO_EM right ?
<smb> caribou, The current cmdline would only use 64M as I got only 2G
<caribou> smb: cool. I will still need your help to explain to me how this crashkernel memory is populated
<caribou> I have a case where, even with 384Mb reserved, the kernel still doesn't load & OOM kicks in
<smb> caribou, Knowing that to be the problem I can look at that more closely now
<cooloney> apw: yeah, that's it
<caribou> smb: my guess is that, depending on which module gets loaded, the memory requirement inflate
<apw> caribou, it is populated in two parts, 1) by kexec in the normal running kernel which loads an executable kernel into the gap, and 2) it represents the whole memory space for that kernel once we have jumped into
<smb> caribou, I had the feeling I saw a slight textual corruption on boot on my machine. Maybe things load into places that may be used differently
<cooloney> apw: and for CONFIG_GPIO_SYSFS, our policy is =n because it is experimental. only highbank =n, others are all =y. looks like it is quite usefule
<cooloney> *useful
<caribou> apw: yeah, I got that part figured out, what I'm missing is what gets loaded in as the kernel boots up
<cooloney> oh, powerpc also set it as =n.
<apw> caribou, it is a full kernel boot, in that limited space, so whatever normally loads during early boot
<smb> apw, So basically faking a full mem of xM
<caribou> apw: then the more modules gets loaded, the more memory will be required. 
<dileks> hi
<apw> mostly we don't start much just get the disk mounted and then run the memory copier, then reboot
<smb> apw, The other question I see is: what region gets used for that xM actually and may it hit bios reserved memory?
<apw> smb, in theory its a chunk out of bootmem, and again in theory taken after the reserved regions are taken
<caribou> apw: this goes back to the /etc/initramfs/initramfs.conf MODULES= setup that you once told me about
<dileks> apw: any progress on ovl-v13 against 3.5-rcX as rc6 is released (in your overlayfs.git repo)?
<apw> caribou, right, a very small initrd is preferable as that is extracted into the memory space reserved
<smb> apw, Right, so that was where I thought I should look more closely. IT surely seems to be placed as high (as in the end of bootmem)
<caribou> smb: afaik, it fits above the first 32M of RAM
<apw> smb, i suspect that is more about it being aligned than anything, its probabally maximally aligned ie aligned at its size
<smb> apw, Hm, so maybe the unpack could have some issue as well. 
<smb> caribou, apw In my case its placed at 800M (or 7xx with crashkernel=128M)
<apw> smb, well in the past we had a massive initrd, so you need the kernel, the packed inird, and the unpacked initrd in the space for a short period and that can go pop
<apw> no idea if that got fixed or not, but we should be using an '=needed' type initrd for kexec
<smb> apw, Ok, that explanation makes a lot of sense
<smb> The compressed initrd is 14M...
<smb> uncompressed 38M
<smb> ... and the kernel code alone about 7M
<TomGLU> just tested it in a KVM with Ubuntu 12.10 (Quantal Quetzal) Alpha 2 and still high d_off
<TomGLU> which ubuntu image should i use though cause it still says:
<TomGLU> *** Problem in linux-image-3.5.0-2-generic
<TomGLU> This is not an official Ubuntu package
<apw> i am sure we got someone to test using =needed or whatever it is and that helped a lot, someone need to make kexec actually do that
<smb> TomGLU, Hm, weird though it could be because the latest 3.5 kernel was 3.5.0-3 or even -4 (there is a lot of change in the development release, so it is always a good idea to run update/dist-upgrade after installing)
<TomGLU> ok i'll try the diet-upgrade
<smb> Saying its not official is a bit confusing, though
<TomGLU> indeed
<TomGLU> its distupgrading to 3.5.0-3 now
<TomGLU> ok now it is sending the report
<smb> TomGLU, Great. If you can post the bug number here we can have a look
<TomGLU> smb: 1022500
<smb> TomGLU, Thanks, hm you might add how to easily obtain those values. I would not immediately know. debugfs?
<dileks> http://www.heise.de/open/news/foren/S-Castle-of-AArch64/forum-232679/msg-22087233/read/
<dileks> http://www.youtube.com/watch?v=GEcvSq4SDkc
<dileks> I would tend to arm64 than aarch64
<smb> Never to miss the opportunity to refer to the Pythons...
<dileks> aah monty pythons
<TomGLU> smb: got a small C script from the cluster developer that prints the d_off for a given directory
<TomGLU> *cluster=Gluster
 * ppisati -> lunch
<apw> ogasawara, pushed a v3.5-rc6 rebase for you, had to fix 'UBUNTU: SAUCE: Improve Amazon EBS performance for EC2' so we need to get smb to test that functionality.
<smb> apw, ack will have a look
<ogra_> diwic, yo, do you happen to be around ?
<diwic> ogra_, let me check....yes, I actually am!
<ogra_> haha
<ogra_> diwic, so i built myself this new desktop machine ...  shiny thing with hda soundcard onboard and two ati graphics cards ...
<ogra_> and apparently the cards both have hda intel codecs on board ... i know sound worked at some point during my fiddling (but i constantly used a BT headset ...) yesterday i though i should try to make analog sound  work and set up my 2.1 system but somehow i'm not able to squeeze the smallest sound ou of the system
<diwic> ogra_, okay, se let's start with an alsa-info: https://wiki.ubuntu.com/Audio/AlsaInfo so I know what kind of hardware you got
<ogra_> diwic, any idea what that could be ? pavucontrol shows all three devices with alsamixer -c1 i can see all hda controls for the analog audio 
<ogra_> ok
<ogra_> diwic, http://paste.ubuntu.com/1082642/
<ogra_> i wouldnt be unhappy if the HDMI devices didnt show up at all btw
<diwic> ogra_, hmm, that ALC892 is unusual, I remember there was someone with that codec also who had some problems with it
<ogra_> well, i know i did a smoke test at some point during assembling that thing and sound worked just fine back then 
<ogra_> (about a week ago or so)
<diwic> ogra_, so if you run "speaker-test -c 2 -D plughw:PCH -t wav", do you get any sound out of either headphones or line out?
<ogra_> is teher any way to tell the driver to ignore the two hdmi cards ?
<ogra_> nope, from neither 
<diwic> ogra_, I guess the easiest way would be to blacklist snd-hda-codec-hdmi, but I'd be surprised if that solved the problem
<ogra_> that i did already for a test 
<ogra_> didnt change a thing
<ogra_> (well, apart from pavucontrol not showing the graphics cards anymore)
<diwic> I guess you can also work with the pci unbind stuff, which I hardly know how to do 
<diwic> if you want to ignore it even more
<caribou> smb: FYI, I'm not able to get Quantal to trigger a kernel dump. kexec doesn't wanna kick in
<ogra_> oh, thats something i didnt think about yet 
<ogra_> well, i'd like to keep the graphics output :)
<diwic> ogra_, hmm but I think the audio has a separate PCI ID
<ogra_> yeah, it should
<diwic> ah wait, the other one was a ALC898, not ALC892. Still unusual codecs though
<ogra_> well, its all pretty new HW
<smb> caribou, Ok, so that needs more investigation then. Thanks for the info. I guess this should go into some new bug then to keep track of it. Feel free to assign it to me
<caribou> smb: ok, I want to check a few more things, then I'll create a bug
<smb> caribou, Ok, sure and thanks
<diwic> ogra_, a quick grep through the reports for ALC892 show plenty of people having playback issues, but not all.
<ogra_> hmm, ok
<diwic> ogra_, I did have a look at the alsa info but nothing popped out as being wrong in the setup.
<ogra_> right, i can even see the meters in pavucontrol work once i play back the test sound from the gnome sound applet 
<ogra_> it just doesnt come out of the speaker
<diwic> ogra_, hmm, it looks like automute is enabled so make sure headphones are not plugged in when you're testing the speakers
<ogra_> yep
<diwic> ogra_, that said there should still be sound in the headphones...
<ogra_> i also tested with automute disabled before just for the record
<diwic> ogra_, you said the last time it worked was during assembly.
<ogra_> i have some humming in the speakers (electric noise) and get a crackling sound on plug/unplug so there is definitely power 
<ogra_> well, i'm still in assembly, since last weekend 
<ogra_> it worked some time through the last week
<diwic> ogra_, based on that, would there be any difference if you unplug the HDA front cable from the motherboard?
<diwic> ogra_, or rather, do you know if it was connected when it last worked?
<ogra_> it was connected before i powered up for the first time 
<ogra_> but i added the second graphics card only later 
<ogra_> bug 982635 looks intresting
<ubot2> Launchpad bug 982635 in alsa-driver "Playback working randomly with Intel ALC892" [Undecided,New] https://launchpad.net/bugs/982635
<ogra_> though with that i would assume to have at least once sound in 50 reboots or so
<ogasawara> apw: ack, thanks
<diwic> ogra_, out of curiousity, what is the mainboard's name?
<ogra_> asus P8 H67-M Pro
<diwic> ogra_, there is bug 1002480 for P8P67
<ubot2> Launchpad bug 1002480 in pulseaudio "[Asus P8P67, Realtek ALC892, playback] Underruns, dropouts or crackling sound" [Undecided,Confirmed] https://launchpad.net/bugs/1002480
<ogra_> heh, that somewhat assumes you have some sound to hear it become crackly :)
<diwic> ogra_, according to that report removing .pulse directory helped, but, a test with "speaker-test -D plughw:PCH" should have disabled anything pulse so...
<ogra_> yeah, i removed ~/.pulse like 100 times already
<diwic> ogra_, seems like you've tried it all! :-)
<ogra_> i even deinstalled it to play plainly with alsa 
<ogra_> i aslo think on the pluse side everything is fine 
<diwic> ogra_, hrm, did you update alsa drivers also? 
<ogra_> must be some lower layer
<ogra_> from the PPA ? 
<ogra_> not yet
<diwic> ogra_, the dkms drivers could be worth a try, but I was also making sure that you haven't tried home-compiling them. That could be a source of error as well
<ogra_> ah, no
<ogra_> i tried an upstream fglrx package but even that one is reverted to the archive one now
<diwic> ogra_, btw, you have uninstalled pulseaudio you say, but still you have ~/.asoundrc.asoundconf pointing to it.
<ogra_> well, i used -D plughw in aplay for testing
<diwic> ogra_, btw, I saw somebody trying different jacks and were able to get sound that way - could you try, while running "speaker-test -D plughw:PCH -c 2 -t sine", the other rear jacks as well?
<diwic> ogra_, maybe there is sound in the grey jack or something.
<diwic> ogra_, and try the DKMS drivers in ubuntu-audio-dev ppa.
<diwic> ogra_, that's my long shots at the moment.
<ogra_> all jacks tried, nothign 
<ogra_> i'll try the dkms drivers ... 
<ogra_> its not the end of the world if i have to go on using BT for a while, but it would be nice to get it working some day
<diwic> ogra_, btw, you should turn off "Line Playback Volume", that's for line-in to line-out loopback
<ogra_> ah, k, i was wondering what that is :)
<diwic> you probably don't want that, just leads to background noises in worst case
<ogra_> (doesnt make any difference if its off or on)
<diwic> ok
<ogra_> what do you want me to try, just the PPA or the alsa-daily stuff ?
<diwic> https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS
<ogra_> ah, daily :)
 * ogra_ reboots
<ogra_> diwic, no change with the dkms modules ... if i have a lazy day i'll try to remove both grapics cards and see what changes then ...
<ogra_> for now i'll juts live with BT
<ogra_> *just
<diwic> ogra_, yeah, I wonder what's with those cards really. It does look like an unusual amounts of ALC892 fail in one way or the other
<diwic> ogra_, or if I'm just seeing patterns where there aren't any.
<ogra_> well, i'm pretty surprised to see the cards using the intel driver really
<ogra_> i thought there was a special radeon driver for that ... 
<diwic> ogra_, all hdmi audio use snd-hda-intel + snd-hda-codec-hdmi drivers these days.
<ogra_> ah, k 
<ogra_> well, i found some bugs where people were told to boot with radeon.autio=0 or so
<ogra_> *audio
<ogra_> so i thought the radeon driver somehow manages audio too
<diwic> radeon.audio=0 is the default for kernels >= 3.0
<ogra_> right
<ogra_> (doesnt help with fglrx though)
<ogra_> i tested with a quantal livedcd too already ... same result 
<ogra_> s/livecd/live udb key/
<ogra_> *usb 
<diwic> they had too many problems with audio=1 (people getting visual problems) so they turned it off
<ogra_> *sigh*
 * ogra_ wants to learn typing one day
<rtg> apw, 'UBUNTU: [Config] built-in CONFIG_MICREL_PHY as other PHY drivers for all flavours' is going to cause build failures for the arches that have a module go missing, e.g. "git grep micrel debian.master/abi"
<apw> rtg, bah yeah will sort it n
<rtg> apw, I did an update locally already. shall I just push it ?
<apw> sure
<apw> its going to be a rough week alreadyb
<rtg> apw, done
<apw> rtg, thanks ... sigh
<rtg> jsalisbury, bouncing gomeisa for kernel update
<jsalisbury> rtg, is it ok to use gomeisa now?
<rtg> jsalisbury, yeah, its back
<jsalisbury> rtg, cool, thanks
<smb> apw, ogasawara Ok, on a quick (5 iterations) bonnie test on 32 and 64 bit PV guests I did not see any problems with the rc6 rebase + apw's blockfront fixups
<ogasawara> smb: great, thanks
<apw> ogasawara, feel free to squash that fix sometime, perhaps after the next upload
<ogasawara> apw: ack.  I'm hoping to get in an upload today after wading through my inbox.
<apw> ogasawara, sounds good, let me know when you have a tag and i'll get ll together over it
<ogasawara> jsalisbury: any progress on bug 1018020 by chance?  it's apparently affecting most of the QA team.  holler if you need help.
<ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,Confirmed] https://launchpad.net/bugs/1018020
<jsalisbury> ogasawara, just tested -rc6 and it still exists.  I'm still bisecting.  I ran into a few test kernels that would panic and a few commits that would not build, but still making progress.
<ogasawara> pgraner: ^^ just fyi
<jsalisbury> ogasawara, it's my top priority for today, and I have hardware to reproduce.
<jsalisbury> ogasawara, pgraner, I confirmed this bug was introduced in v3.5-rc1, just working on finding the exact commit.
<pgraner> jsalisbury, cool let me know when you have a kernel I'll run it on my boxes that are failing
<jsalisbury> pgraner, will do
 * ogasawara back in 20
<ogasawara> rtg: bah, stupid permission denied build error again on gomeisa.  it seems to always trigger in the i386 chroot.
<rtg> ogasawara, paste it ?
<ogasawara> ccache: FATAL: Could not create /home/ogasawara/quantal-i386/ccache/8/2/1834a73ab5ad0e3ffbed95e7a26d38-1830488.o.tmp.stdout.gomeisa.3990 (permission denied?)
<ogasawara> make[7]: *** [drivers/net/ethernet/intel/ixgb/ixgb_main.o] Error 1
<ogasawara> make[6]: *** [drivers/net/ethernet/intel/ixgb] Error 2
<ogasawara> make[6]: *** Waiting for unfinished jobs....
<rtg> ogasawara, but amd64 works OK ?
<ogasawara> rtg: yep.  amd64, armhf, and amel were all ok
<rtg> ogasawara, have you tried without ccache ?
<ogasawara> rtg: I haven't
<rtg> ogasawara, this doesn't seem like a chroot issue
<ogasawara> rtg: lemme clean things up and try again
<rtg> ogasawara, I think you're better off without ccache. I found that it took longer to resolve the hash then it did to just recreate the file, especially when you have several thousand files.
 * ppisati -> gym (see u later)
 * herton -> lunch
 * henrix -> brb
 * henrix -> EOD
<bjf> arges: issue #1 on why a hotfix should be used it true means that you are going to be the sole supprt for that kernel and all future versions of it ? seems like at that point you should engage with OEM.
<bjf> arges, also you are re-inventing the build instructions. you should look at the stable team build instructions and all you need to do is hae a different version string
 * rtg -> EOD
<jsalisbury> ogasawara, pgraner, I'm pretty close on the bisect for bug 1018020 I should have a test kernel withing an hour or two.
<ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,Confirmed] https://launchpad.net/bugs/1018020
<ogasawara> jsalisbury: awesome, thanks for digging into it
<jsalisbury> ogasawara, np.  It was a good learning one.  Plenty failed kernels during the bisect that needed fixing up :-)
<jsalisbury> The early release candidates can be a pain to bisect :-)
<pgraner> jsalisbury, coolio
<jsalisbury> pgraner, I'll update the bug and send email when the test kernel is ready
#ubuntu-kernel 2012-07-10
<smb> morning
<ppisati> moin
<cooloney> morning guys
 * ogasawara back in 20
 * cking reboots
<henrix> cking: *g* 1 min to reboot? cool! :)
<cking> 7 seconds boot time on my SSD ;-)
 * henrix needs to get one of those!
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<dileks> hmm, looks like I cant use brightness here with .27 kernel
<dileks> battery-mode
 * henrix -> brb
<dileks> 3.2.0-26 is OK
<apw> ogasawara, so are we routinly using -proposed in quantal for kernels now ?
<ogasawara> apw: I do when it's an ABI bump since I'm lazy and want to shove both packages up at the same time
<ogasawara> apw: however, I don't think it's been mandated by the release team
<ogasawara> apw: cjwatson informed me in #ubuntu-release that we can likely copy our own kernels from quantal-proposed to the release pocket
<ogasawara> apw: I'll have to give it a try on the next upload
<apw> ogasawara, its still in there now isn't it?
<ogasawara> apw: he just copied it for me
<ogasawara> apw: but he then gave me the instructions on how to do so in the future
<apw> ogasawara, ok i'll push ll in there and see what happens
<apw> ppisati, you in the middle of anything config related on ti-omap4 ?
<ppisati> apw: not now
<ppisati> apw: regenerating the config matrix?
<apw> ok cool, have a simple twiddle to set, and also that yes
<apw> ppisati, http://kernel.ubuntu.com/~kernel-ppa/configs/quantal/reviews/Portland.html looking better indeed
<mpage> @abogani: I've been trying to compile your realtime kernel
<mpage> Here is what I have been doing http://hackmemory.wordpress.com/2012/07/09/kernel-compiling-to-add-phc-support/
<mpage> It works but it doesn't apply the patches
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 24th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * henrix -> EOD
 * cking reboots
 * rtg -> EOD
<stgraber> is it reasonable for me to think that this is a bug: http://paste.ubuntu.com/1085255/ :)
<stgraber> bug 1023174
<ubot2> Launchpad bug 1023174 in linux ""ip -6 addr flush" flushes much more than just the addresses" [Undecided,New] https://launchpad.net/bugs/1023174
#ubuntu-kernel 2012-07-11
<jjohansen> bjf: who was working on the backport for CVE-2012-1601?
<ubot2> jjohansen: The KVM implementation in the Linux kernel before 3.3.6 allows host OS users to cause a denial of service (NULL pointer dereference and host OS crash) by making a KVM_CREATE_IRQCHIP ioctl call after a virtual CPU already exists. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1601)
<unixpro1970> I am noticing a high interrupt count in /proc/interrupts followed by an eventual system crash is this a known issue with 3.0.0-12?  Can someone point me to a forum or link that discusses ubuntu kernel bugs and related issues? thanks
<unixpro1970> This occurs on 11.10
<unixpro1970> I am looking at kernel.org does anyone have an ideas
<unixpro1970> any
<jwi> unixpro1970: maybe start with updating your kernel, the latest one from -updates for 11.10 is 3.0.0-22.36
<unixpro1970> just what i thought, i found this in topic in 3.0..13 " genirq: Fix race condition when stopping the irq thread"
<unixpro1970> sound like it might be related
<unixpro1970> sounds
<bjf> jjohansen: can't remember, it may have been me
<bjf> jjohansen: looking at it, it doesn't look familiar though
 * apw yawns
<cooloney> apw: hey, morning
<apw> cooloney, moin
<cooloney> apw: i sent out several patches to our kernel team mail list, did you receive them
<cooloney> i didn't get those emails sent out by the mail list, weird
 * apw looks
<smb> cooloney, Hm, I don't seem to see them immediately 
<smb> got some subject for me to search
 * apw neither
<cooloney> so weird. but it's in the achive
<cooloney> https://lists.ubuntu.com/archives/kernel-team/2012-July/thread.html
<cooloney> please find them at the end of this page
<cooloney> [PATCH 0/9] [Quantal/master-next] update configs   Bryan Wu
<cooloney> [PATCH 0/3] [Quantal/ti-omap4] update configs   Bryan Wu
<cooloney> smb and apw ^^
<smb> cooloney, Those don't seem to have been synced over to me...
<apw> cooloney, nope don't seem to have them either
<cooloney> smb: me neither, so weird. looks like mail man stops working
<smb> Well I got the mails from Tim and Herton above
<smb> Seems anything after that is still missing
<smb> Just weird it went into the archive
<apw> ok they are not in the moderation queue, which makes sense as they are in the archive
 * apw moves to #is
<cooloney> smb: yeah, me. mails from rtg and herton are my last emails from our mail list
<ppisati> moin
<dileks> I yesterday reported that I cant control brightness with 3.2.0-27 but 3.2.0-26 works well. known issue? (this is on a sandy-bridge ultrabook)
 * henrix -> lunch
<e11bits> I have this linux device driver for Realtek Ethernet controllers that I placed in /usr/src and added to dkms. If I use dkms manually the module gets built and installed and everything is fine. But if I download a new kernel image installation hangs when dkms kicks in. Where can I see what's happening? I'm pretty sure there is something wrong with my dkms.conf file: http://paste.ubuntu.com/1086041 (feel free to point me to a more 
<e11bits> appropriate channel)
 * cking reboots
<fresh-nes> Can somebody help me to defer initcalls of the boot, as explained here : http://elinux.org/Deferred_Initcalls . But for the kernel 3.3 please
<ppisati> diwic: this morning i realized i can't play any audio file if i'm not logged in via GUI
<ppisati> diwic: i mean, if i ssh into the box and execute 'mplayer foo.mp3' i don't get any output
<ppisati> diwic: until i login via lightdm
<ppisati> diwic: why?
<diwic> ppisati, a VT should do as well, but not SSH - consolekit have not assigned you the right to use the card
<rtg> ppisati, ecryptfs ?
<diwic> ppisati, see https://wiki.ubuntu.com/Audio/TheAudioGroup for a workaround and the problems with using that workaround
<fresh-nes> What technics exist in order to fasten the boot of the kernel ?
<abogani> e11bits: I don't remeber exactly but dkms should put the log file in /var/lib/dkms/PACKAGE_NAME/PACKAGE_VERSION/KERNEL_VERSION/ARCH/log/make.log
<abogani> fresh-nes: Depends on how many time you want spend in this effort. The simplest is build custom kernel.
<fresh-nes> abogani : That's what I do. I build my own 3.3 kernel for my pandaboard.
<abogani> fresh-nes: So this is ths wrong channel. Ubuntu never had released a 3.3 kernel ;)
<pgraner> jsalisbury, that kernel fixed that webcam and headset issue, commented in the bug
<abogani> fresh-nes, In your shoes I'm trying to ping in #beagle
<fresh-nes> abogani : you're right, I use linaro distro... sorry and thank you
<abogani> fresh-nes: No problemi I'm a Ubuntu-over- BeagleBone user ;)
<jsalisbury> pgraner, thanks for the update.
<jsalisbury> pgraner, there still may be an issue with that patch.  there are reports upstream that the webcam may crash after a long period of use.  I'm testing that now.
<pgraner> jsalisbury, ok, I don't have a lot of calls today, but I do tomorrow so I'll get to exercise it then
<jsalisbury> pgraner, great, thanks.  I'll let you know if I have a new test kernel.
<e11bits> abogani: Ah, will have a look. Thanks!
<arges> apw, hello. was wondering why the natty kernel abi was changed from 2.6.38-15.62 to 2.6.38-15.64 (pad.lv/1019992) recently
<rtg> arges, build screwup
<arges> rtg, ahh the ppa ddeb thing
<rtg> right
<apw> arges, yep, thats when ... that thing, its same bits 62->64
<arges> why was it +=2 ?
<rtg> arges, note that its only a version change, not an ABI change
<apw> arges, i screwed up the rebuild, so i had to do it twice
<arges> apw, gotcha. ah yes the second number is build number ok
<apw> but it was only a no-change rebuild between those two numbers
<arges> cool
<apw> inded the .63 never built
 * ogasawara back in 20
 * ppisati needs a preamplified mic...
<pgraner> josepht, see bug 1018020
<ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,In progress] https://launchpad.net/bugs/1018020
<josepht> pgraner: me or jsalisbury ?
<jsalisbury> pgraner, thanks.  I'll let upstream know.
<pgraner> jsalisbury, I had it running about 15 min
<pgraner> josepht, sorry dude, to many Joe's now
<jsalisbury> pgraner, ok, I'll let you know when the next test kernel is available.
<pgraner> jsalisbury, ack
<Kano> hi apw , could you update kernel-wedge? it is older than wheezy now
<Kano> hi tseliot 
<tseliot> hi Kano
<Kano> did you package fglrx 12-6-legacy
<tseliot> Kano: no, not yet
<Kano> how will you do that? fglrx-legacy package or some other way?
<tseliot> Kano: yes, I'll probably call it fglrx-legacy
<Kano> did the 12-6 beta you had in the repo work with your quantal xserver 1.12? for 12-6 beta/final i had to patch libpciaccess on 64 bit. i tried your patches for kernel 3.5 without success with the 12-6 final
<Kano> most likely i will try 12-6 legacy + patch for kernel 3.5 on wheezy
<tseliot> Kano: sorry, I haven't even tried the beta yet
<Kano> well you best use the control+signature from fglrx 12-4 for the legacy package
 * ppisati -> gym
<jjohansen> herton: you need to update the attribution on that patch, Sasha Levin actually found it, I just passed the info on
<herton> jjohansen, ah ok, what should be the reported-by?
<jjohansen> herton: Reported-by: Sasha Levin <sasha.levin@oracle.com>
<herton> ack
<rtg> herton, that patch also needs updates for the custom binaries
<herton> rtg, indeed, I just forgot to run the script to integrate it
 * henrix -> EOD
 * cking -> EOD
<bjf> ogasawara: bug 1021718
<ubot2> Launchpad bug 1021718 in linux "Ubuntu Precise ISO test failed in Jenkins due to debian installer failed to get debconf answer 'base-installer/kernel/linux/initrd'." [Critical,Confirmed] https://launchpad.net/bugs/1021718
<bjf> skaet, I just got pinged w.r.t. bug 1021718
<ubot2> Launchpad bug 1021718 in linux "Ubuntu Precise ISO test failed in Jenkins due to debian installer failed to get debconf answer 'base-installer/kernel/linux/initrd'." [Critical,Confirmed] https://launchpad.net/bugs/1021718
<skaet> bjf,  good.   Was going to be pinging you myself shortly ;)
<bjf> skaet, you bumped it up to "Critical". Seems like it would have been a good idea to reach out to someone on the kernel team and let us know about that.
<bjf> skaet, we had to re-upload almost all our packages last week, this issue should have been fixed days ago
<skaet> bjf,  I just copied the status that was there, when I targetted it correctly.  
<skaet> it was targetted against quantal when I looked at it, so, understandable you didn't see it. 
<bjf> skaet, ah, it's gema i should be "discussing" this with
 * skaet nods
 * rtg -> EOD
#ubuntu-kernel 2012-07-12
 * smb -> BOD
<ppisati> moin
 * ppisati -> reboot
 * ppisati -> out
 * henrix reboots
<Eimann> hmm, I still need to troubleshoot why 3.4.0-030400rc5-generic works fine on my thinkpad x220 but 3.4.4-030404-generic and 3.5 do not
<jsalisbury> pgraner, I posed a new kernel to bug 1018020  This should be the final patch
<ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,In progress] https://launchpad.net/bugs/1018020
<pgraner> jsalisbury, ok otp will be in about 20 min
<jsalisbury> pgraner, thanks.  just wanted to let you know the kernel is available in case you had some video meetings today.
<pgraner> jsalisbury, I have them all day
<jsalisbury> pgraner, cool, your a great test subject then :-)
 * ogasawara back in 20
<jokerdino> hey guys. i recently upgraded to quantal from precise and i had graphics issues.
<jokerdino> i then had to install the inux-image-extra-3.5.0-3-generic to fix the issues.
<jokerdino> i am wondering why i have to manually install it when it seems quite necessary?
<smb> jokerdino, Upgrading with either update-manager or do-release-upgrade should pull in that package automatically. Though update-manager had some other issues yesterday (at least). do-release-upgrade did pull in extras though.
<jokerdino> smb: thanks for your response. i upgraded earlier and i didn't have it installed through do-release-upgrade
<jokerdino> i mean, i upgraded through the command line and it didn't work as you say
<smb> jokerdino, If neither update-manager nor do-release-upgrade would work (though those are preferred as they do a bit more than just switch to the new sources), then the best way to ensure the kernel packages are complete is to install a meta package. Like "apt-get install linux-generic". Those should give you header files, the kernel itself and anything else
<jokerdino> i understand that. but keeping QA testing in mind, this is not ideal is it?
<smb> Well QA testing should upgrade using the supported methods. Though if you say, you used do-release-upgrade and it did not work, that would have been a bug, but it seems at least as of yesterday it was ok
<jokerdino> i upgraded on Tuesday IIRC
<jokerdino> http://chat.stackexchange.com/transcript/201?m=5297694#5297694 
<jokerdino> i am quite sure it wasn't auto installed.
<smb> And just to be sure, you say "using the command line" and that was do-release-upgrade?
<jokerdino> yes that.
<jokerdino> can i look for logs that might be useful for you?
<smb> Hm, yeah. you should probably file a bug then as well. 
<jokerdino> you do suggest it is not a problem anymore though?
<jokerdino> and this answer on Ask Ubuntu suggests installing extra is not being done for quantal? http://askubuntu.com/a/153033/25798
<jokerdino> "As far as I know, the above approach has not been taken for the Quantal kernels -- only -virtual is affected as usual. "
<rtg> ogra_, whats the normal way to install a new kernel on an ARM board if it can u-boot ? the usual 'dpkg -i linux-image*' doesn't update /boot/uImage
<ogra_> rtg, hmm,. that would be a bug 
<smb> jokerdino, For quantal the virtual and the generic kernel are the same packages. Only the virtual meta-package does not install extras while the generic one does.
<rtg> ogra_, well, its a linaro kernel deb
<ogra_> if you used a proper image the bootloader setup should take care
<ogra_> oh, linaor
<ogra_> well, try to run sudo flash-kernel manually
<ogra_> see what happens
<rtg> ogra_, that won't wreck the SPI NOR ?
<ogra_> might be that linaro (once again) broke the subarch naming convention
<jokerdino> smb: alright then. i'll chat with balloons regarding this then.
<ppisati> rtg: ogra_ there's today discussion about incompatibilities between our flash-kernel and their kernels
<ogra_> ppisati, if they follow the debian and ubuntu naming scheme its fine 
<ppisati> rtg: ogra_ Re: Problem with flash-kernel script on PandaBoard with Ubuntu image and Linaro kernel
<ppisati> rtg: on ubuntu-devel
<ogra_> i.e. the mx5 kernel which does this, just works 
<ppisati> ogra_: they actually wanted to patch our flash-kernel to support their stuff
<ogra_> ppisati, yes, i saw that
<rtg> ogra_, this is the mx6 on a sabrelite board
<ogra_> they should patch debians
<ogra_> rtg, well, then it most likely isnt even in the flash-kernel database yet 
<ogra_> is that quantal ?
<rtg> oneiric
 * ogra_ prays that it is
<ogra_> OMG !
<rtg> ogra_, I'm working on a 3.2 kernel to bring it up to precise
<ogra_> k, so you need to hack up flash-kernel ... that version had all HW data for all boards hardcoded directly in the flash-kernel script
<ogra_> take a look :)
<smb> jokerdino, Ok. If the upgrade path still fails to install extras for you, then please file a bug. And in that case the installer logs hopefully help to find out why it did not happen.
<ogra_> it will not be an easy task (compared to the quantal flash-kernel) to add all the functions you need
<jokerdino> smb: okay. thanks for your help
<ogra_> rtg, any chance you could use a quantal userspace ? 
<rtg> ogra_, eventually, but I thought I'd get the kernel working first.
<rtg> imx_flash_kernel()  ?
<ogra_> well, no idea how that board actually boots without having played with it ...
<ogra_> imx_flash_kernel is for the mx5 
<ogra_> if the mx6 didnt change wrt booting, that should work
<ogra_> but you need the match for the "hardware" entry from /proc/cpuinfo
<rtg> ogra_, it boots from u-boot by loading /boot/uImage, which looks kind of like the mx5
<ogra_> (must be somewhere in the middle of the code)
<ogra_> k, sounds good
<ogra_> so try to add a line for the cpuinfo output and make it match for the imx_flash_kernel function and you should be good
<rtg> ogra_, I'm assuming if the u-boot command is 'ext2load mmc ${disk}:1 10800000 /boot/uImage && bootm 10800000 ;', then I should set IMX_KERNEL_ADDR= 10800000 in flash-kernel ?
<ogra_> heh, thats a good question
<ogra_> i dont think this directly translates to the address from boot.scr, but i'm not sure
<rtg> well, the worst it can is not boot. I've got an image of the original SD card.
<rtg> can do*
<ogra_> ah
<ogra_> original wasnt linaro i suppose ?
<ogra_> (else you should be able to look up that address)
<ogra_>        "Freescale i.MX6 Quad (Device Tree)")
<ogra_>                 check_subarch "mx6"
<ogra_>                 IMX_KERNEL_ADDR=0x10008000
<ogra_>                 imx_flash_kernel
<ogra_> heh
<ogra_> my copy of flash-kernel already has an entry for the mx6 here 
<ogra_> (flash-kernel-2.28ubuntu42 is the last copy of the old cruft i have around here)
<rtg> ogra_, so, where would I find a Quantal image ?
<ogra_> no idea, linaro might have one already 
<ogra_> oh, quantal
<ogra_> sorry
<rtg> I haven't been able to find anything newer then oneiric
<ogra_> ubuntu-core would be a good start probably
<ogra_> but that needs some manual tinkering (networking and a rootpw at least)
<rtg> maybe I should hassle Eric Miao who has done all the work on this
<ogra_> well, if it boots you should at least see a kernel panic now (not finding a rootfs)
<ogra_> if you got that far, just creating a second partition on your SD and unpacking ubuntu-core to it should get you a booting system (no login though without passwd indeed)
<rtg> ogra_, bummer, what ever flash-kernel did trashed u-boot. 
<ogra_> ignore flash-kernel then, do it manually 
<ogra_> do you have a boot.scr from the original SD ?
<rtg> ogra_, I'm not even getting the u-boot serial startuop. how do I recover from that ?
<ogra_> ugh, no idea
<rtg> shit
<ogra_> we dont support any boards in ubuntu that dont boot from SD :)
<ogra_> i.e. all boards we support atm are unbrickable
<ogra_> hard to tell if the mx6 has any option to force boot from SD only 
<rtg> well, this does boot from SD, but I think the initial startup is in SPI NOR which then loads u-boot from SD
<ogra_> ah, then its fine 
<ogra_> does the original SD have two partitions ? 
<rtg> not taht I know of, but I didn't look too clase. lemme reimage it.
<ogra_> yeah, take a look
<ogra_> usually uboot systems have an ext2 or vfat partition as the first part on SD and read their bootloader stuff from there
<ogra_> (though indeed not all of them :P )
<rtg> re-imaging, could take awhile...
<bjf> bug 1023214
<ubot2> Launchpad bug 1023214 in linux "bogus utime and stime in /proc/<PID/stat" [High,Confirmed] https://launchpad.net/bugs/1023214
 * apw notes there is a s/r fix coming in v3.5-rc7
<apw> commit dc332fdf9f373a87b1e2f423b5b004b2a3c37e1a
<apw> Author: Jonathan Nieder <jrnieder@gmail.com>
<apw> Date:   Sun Jul 8 21:55:14 2012 +0200
<apw>     ACPI / PM: Leave Bus Master Arbitration enabled for suspend/resume
<smb> bjf, jsalisbury I pushed git trees (which you can look at for reference) to lucid-* directories on gomeisa and started builds. This basically reverts one (I believe rather SAUCE though it does not say so) patch and replaces it with two upstream changes. We always were thinking of backporting but since it is so hard to verify never actually did.
<bjf> smb, thanks
<smb> bjf, jsalisbury Just assuming you will be longer around today than me to have the bug updated. Btw, I looked at the Maverick repo again and that already seems to carry the other two and not the one reverted. So it seem it was about that time it got changed. I believe there also has been something else concerning load values but much later...
<bjf> smb, ack
 * rtg -> lunch
<jsalisbury> smb, ack
<ogasawara> jsalisbury: for your patches for 1018020, following the alsa-devel thread it sounds like the first patch isn't needed.  Did you want to re-test really quick with only the second patch before I apply.
<jsalisbury> ogasawara, sure, sounds like a good idea.  I can test here, and post a new kernel to the bug.
<ogasawara> jsalisbury: ack
 * smb -> EOD
<pgraner> jsalisbury, all is good with that kernel on two boxes been in use for a few hours and still chugging
<cnd> arges: I just replied on https://bugs.launchpad.net/ubuntu-advantage/+bug/1015824
<ubot2> cnd: Error: <Bugtracker.plugin.Launchpad instance at 0xa2d980c> bug 1015824 not found
<cnd> will you be able to follow up as I suggested?
<jsalisbury> pgraner, great.  I'm actually posting one more test kernel.  It shouldn't have any issues, just some code removed that is not needed.
<pgraner> jsalisbury, cool, I'll watch the bug and test it once it comes out
<jsalisbury> pgraner, I'm uploading them now.  Should be here in a minute: http://people.canonical.com/~jsalisbury/lp1018020/
 * ogasawara lunch
<jsalisbury> pgraner, they are there now.  The have 'v3' in the .deb file name.
<jsalisbury> pgraner, when you test the latest v3 kernel, can you see if there is a delay at the login screen?  
 * rtg -> EOD
 * cking --> EOD
<arges> cnd, yes
<cnd> arges: thanks!
<arges> : )
#ubuntu-kernel 2012-07-13
 * smb -> BOD
<dileks> hmm, this colord again crashing #934308
<RAOF> Urgh, libdbus again.
<dileks> that bugs seems not to exist?
<dileks> https://bugs.launchpad.net/bugs/934308
<ubot2> dileks: Error: <Bugtracker.plugin.Launchpad instance at 0xa2d980c> bug 934308 not found
<dileks> hehe. that bug-# was displayed in that crash-report whatever app
<RAOF> It's a private bug which is why the bugbot can't scrape it.
<dileks> whats a "private bug"?
<dileks> a # generated by the crash-reporter-app?
<RAOF> A private bug is one marked as private; all apport-reported bugs start as private, because they contain coredumps that may contain sensitive data.
<dileks> OK
<dileks> looks like ...
<dileks> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=dc332fdf9f373a87b1e2f423b5b004b2a3c37e1a
<dileks> ... fixing 3.5-rc6 ...
<dileks> http://paste.ubuntu.com/1089450/
<dileks> happened after suspend+resume*
<caribou> smb: morning
<smb> caribou, about right... :-P
 * smb is still tired
<caribou> smb: can I ask you a quick question about the bisecting of the kexec issue ?
<smb> caribou, dunno, you may try... :) yes.
<caribou> smb: though I don't plan to do it myself, but I'd like to learn how to do it
<caribou> smb: this would be too long to build the kernels on my laptop
<caribou> smb: but here is the question
<smb> caribou, No I don't do that either
<caribou> smb: since we identify that it's between v3.4 and v3.5-rc1, I wanted to learn the commands to bisect
<caribou> smb: so I got the Quantal git clone, then did :
<caribou> smb: git bisect start v3.5-rc1 v3.4
<smb> caribou, Ok, so basically I take an upstream kernel tree (our trees, especially development trees are not that good since they are rebased)
<caribou> smb: well I followed https://wiki.ubuntu.com/Kernel/KernelBisection
<caribou> smb: so I picked git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git
<caribou> smb: then which one should I take ?
<smb> caribou, ...slow down... its morning
<caribou> smb: hehe, sorry I was up early today :)
<smb> Not sure what the wiki say, so I need to look...
<caribou> smb: I just see something weird in my git environment : after the git bisect start, I am no longer in a branch
<smb> caribou, no that is correct, you are somewhere in the middle of things
<caribou> smb: I think there is a step needed after the git bisect to get the bisected code back into my branch
<smb> no
<smb> Can we go back to tree selection? 
<caribou> smb: sure
<apw> if you need a branch name on the bisect commit to get it built (for example to use a remote machine to build it) then i just do a 'git branch buildtmp' which makes a branch pointing to 'here'
<smb> So after we release you could use our tree for bisection as it is not rebased anymore (the master branch), but more often we need to bisect something in mainline
<smb> Then as I said you take the upstream tree, "cp -a <ourtree>/debian/* ." and be sure debian.master/config/enforce(r?) is empty
<smb> PRobably git bisect start good bad works too, though I like to be single stepped as I am single minded... :-P
<smb> So git bisect start
<smb> git bisect good <version>
<smb> git bisect bad <version>
<smb> This throws your tree roughly into the middle of good and bad
<smb> I usually edit the debian.master/changelog to have some indicator (version numbering) of which kernel build this is
<caribou> smb: yes, this mostly what is described in the Wiki
<smb> and then you run the build (usually skipabi=true skipmodule=true fakeroot debian/rules binary-generic)
<caribou> smb: what puzzles me is that, after the bisect good/bad, I'm no longer in a branch and don't have the debian.master directory etc
<smb> This normally asks some config questions, I try to just hit enter and use default version
<smb> caribou, You will have one 
<caribou> and 'git branch' tells me "*(no branch)"
<smb> if you had before
<smb> but you clearly are *not* on any branch anymore
<smb> Of course
<apw> caribou, that is normal mid-bisect, as it is mid-rebase
<apw> you are on a 'diconnected HEAD'
<caribou> apw: yes, I got that far.
<caribou> apw: so is there anything else to be done at that point to get from the mid-bisect disconnected HEAD to some branch in order to build
<caribou> ?
<smb> caribou, No, it means you are at a point between version but still this is what you want to build
<smb> caribou, And if you do the bisect on an upstream tree and copy the debian files in, those remain untouched by you moving forward through the bisect
<smb> (since for the upstream tree those are not part of the repo)
<apw> so you can use the term HEAD to refer to there, and as i said before to get a name attached to here you can just "git branch NAME" which will attach that name to wherever HEAD is
<caribou> smb: yes, that's clear to me. 
<caribou> apw: ok, that was the missing bit I was after !
<smb> caribou, But that you actually don't need
<smb> After you proceed through bisection, you will end up at a point where git tells you this commit (sha1) is what should be the offending one
<cking> if you've done it right ;-)
<smb> you can use that sha1 to look at the commit (or do whatever else is appropriate)
<smb> cking, Yeah... minor thing... :)
<caribou> smb: yes I figured that part out. I was only puzzled by the "disconnected HEAD" situation
<smb> ok
<cking> juist don't interrupted and make a mistake is my advice ;-)
<apw> and i recommend you keep a copy of 'git bisect log' every now and again as that can be used to get you back to where you are when you break your tree
<apw> or lose track or say good when you meant bad, or similar
<smb> right
<caribou> smb: when I use one of our trees to test, after the "git bisect start", I was in a disconnected HEAD and the debian.master bits were no longer there
<smb> and sometimes one also needs a "git bisect skip" to say neither good nor bad, it just failed to build
<apw> yep as our debian bits are near the tip of the tree at all times
<apw> so any bisect which drops you way down into mainline commits won't have them
<smb> caribou, Ah, ok. That is true as long as start is before a final release
<caribou> ok thank very much guys. this is all very useful information to me
<caribou> smb: which is the case with the Quantal tree
<caribou> smb: I should test with a stable tree
<smb> caribou, Quantal is not release, so yes
<caribou> ok, thanks for your time guys !
<_ruben> got a hardy box on which i need to mount a ext4 disk, guessing the easiest way to make that possible is by using a mainline kernel? any recommendations for a specific version(range)?
<apw> _ruben, blimey.  i think if it was me, i would try a lucid kernel
<apw> though that combination likley has not been tested
<smb> though between hardy and lucid I think there was some incompatibility with lvm userspsace
<smb> (iirc because /sys/block became links)
<_ruben> sounds scary, tho i might've found a different solution by means of virtualization
<apw> that sounds safer indeed
<cking> apw, ping
<psusi> is there not a -dbg build of the kernel so you can get gdb some debug symbols?
 * ogasawara back in 20
<herton> psusi, you can get dbgsym packages directly from http://ddebs.ubuntu.com/pool/main/l/linux/, there is also a general guide on the wiki about dbg packages: https://wiki.ubuntu.com/DebuggingProgramCrash/#Debug_Symbol_Packages
<psusi> herton: thanks... hrm... it seems that gdb needs me to specify the base address to add-symbol-file.. how can I figure that out?
 * jsalisbury back after another x201 overheat crash :-/
 * ppisati -> goes packing stuff
<psusi> aha!  there we go... just use file instead of add-symbol-file...
 * cking reboots
<jsalisbury> pgraner, just wondering if you had a chance to test the v3 kernel for bug 1018020 ?
<ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,In progress] https://launchpad.net/bugs/1018020
<pgraner> jsalisbury, not yet, give me 5 and I'll let you know
<jsalisbury> pgraner, great, thanks.
<pgraner> jsalisbury, ok looks good with a quick 3 min camera run
<jsalisbury> pgraner, cool.  And you didn't notice any delay at the login screen, when trying to enter your password?
<pgraner> jsalisbury, not really, let me try on my other box for sanity
<pgraner> jsalisbury, no noticeable speed issues on my i7 or i5 box
<jsalisbury> pgraner, great news!  Thanks for testing.
<jsalisbury> ogasawara, ^^^ I've had good feedback from a couple of people that the single patch(2/2) fixes bug 1018020
<ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,In progress] https://launchpad.net/bugs/1018020
<jsalisbury> ogasawara, want me to repost to the list with just the single patch?
<ogasawara> jsalisbury: cool thanks.  I think tim applied both so I'll just drop patch 1/2.  no need to reply to the list, I'll just send a note out that I've dropped it.
<jsalisbury> ogasawara, cool, thanks
<jsalisbury> ogasawara, this patch should land in mainline soon too
<ogasawara> jsalisbury: ah, nice.
<jsalisbury> ogasawara, Takashi applied it to his tree, so whenever Linus pulls that it should land
<skaet> ogasawara,  there are alot of bugs sticking around in fix committed state on http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html for multiple weeks,   is there possibly a janitor processing glitch,  or its just waiting for a specific drop to land?
<ogasawara> skaet: I'll have to take a look, might just be waiting for something to move out of -proposed
<skaet> thanks ogasawara 
<ogasawara> skaet: ah, those are for CVE's.  likely never auto-closed by our bot for Quantal.  I'll go through and clean them out.
<skaet> thanks ogasawara   :D
<ogasawara> skaet: is there a reason there is a separate "linux" section in that report?
<skaet> ogasawara,  report is oriented around teams,  and packages in the team's responsibliity areas.
<ogasawara> skaet: I'm still a bit confused then as that would indicate that section should contain then all the bugs against the "linux" package, but really it's all the linux-armadaxp bugs
<ogasawara> skaet: and I'm not sure why linux-armadaxp is then special to have it's own section when we group all the other kernel related packaged, eg linux, linux-ti-omap4 under the "kernel" section.
<skaet> ogasawara, yeah,  I agree what's emerged has become confusing.... time for some cleanup.   I'm guessing its because of vanhoof's team involvement in the armadaxp board.   I'm fine with it all being lumped under kernel.
<skaet> if that makes it clearer
<ogasawara> skaet: that's fine, at least I'll be sure to see it then
 * skaet adds it to the TODO list ;)
 * henrix -> EOD
<mdz> what is the difference between linux-image and linux-image-extra? the package descriptions look identical
<ogasawara> hiya mdz, with quantal we eliminated the need for having a separate virtual flavor by splitting the kernel package into a paired down linux-image package and linux-image-extra to contain everything else not included in linux-image.  ie install linux-image for a paired down offering, install linux-image + linux-image-extra for a complete offering.
 * ogasawara has to run, back in a bit
<mdz> ogasawara, thanks. maybe the package description could be updated to clarify this?
<mdz> maybe mention the categories of modules which are in linux-image vs. -extra
<mdz> -extra looks like it has many (but not all) network, sound, input, media, etc.
<mdz> about half the modules my system uses are in -extra, interesting
<jjohansen> herton: you around?
<herton> jjohansen, yep
<jjohansen> herton: For the hardy bug that I had you change the attribution on (3d3e740d89b3267ceb0ef19fd741aeb0b75c1f47) the commit text still needs to be modified.
<jjohansen> It still has "John Johansen reported"
<herton> jjohansen, hmm... yeah. reported by is correct though. But the patch I resent to the mailing list was right, I guess someone when applied modified by hand the first patch. I think it can go this way now... anyway, you two were involved I guess
<jjohansen> herton: yeah the patch is right, and reported-by is right, just want to make sure that all the credit goes where its due, as I wouldn't want to upset an active contributor
<herton> jjohansen, it will cause some hassle to fix this now, since went to master and the update is ready. And since the reported by is correct, I don't think it's too bad
<herton> jjohansen, I guess the better action would be to apologize to him through mail, since it wasn't intentional, just to avoid any misjudgments
<herton> jjohansen, I can write up one if you want
<jjohansen> herton: no I can write one up if we go that route
<herton> bjf ^, what do you think?
<jjohansen> herton: okay, I think we will go that route with this one
<bjf> herton, jjohansen, email is the way to go, worst case we will revert the patch and reapply a different one with the correct attribution
<bjf> herton, jjohansen, but that seems kind of extreme
<jjohansen> bjf: yeah email has already been sent
<bjf> jjohansen: thanks, really sorry about that
<jjohansen> bjf: heh it happens I should have caught it sooner
<bjf> jjohansen, are you planning on sprinting with us at all?
<jjohansen> bjf: yep, a couple days. is looking like Wed, Thursday for me atm
<bjf> jjohansen: cool
#ubuntu-kernel 2012-07-14
<deffrag> Hello! Is <sudo cat /dev/sda5 | md5sum> the right way to get md5sum for sda5 partition? Or what exactly will the command do?
<ryant5000> how would I go about building a 3.4 kernel on/for Amazon EC2? i'm on Precise, and I grabbed a clone of the git repo, but i don't see how to build the "virtual" flavour
<bjf> ryant5000, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel , down in the "Building the Kernel" section substitute "binary-virtual" for "binary-generic"
<bjf> ryant5000, i just kicked one off myself, if that doesn't work, i'll know in a little bit
<ryant5000> bjf: hm, i tried that, but it said it couldn't find binary-virtual
<ryant5000> bjf: where did you get your sources?
<ryant5000> bjf: i was building from a tag in git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
<ryant5000> bjf: i got the impression that somehow the sources i had didn't include a virtual flavour
<bjf> ryant5000, i did: fakeroot debian/rules clean; fakeroot debian/rules binary-virtual
<bjf> ryant5000: and it's building as we speak
<ryant5000> hm, ok; and was your source from that same git repo?
<bjf> ryant5000: i am building precise which was cloned from the ubuntu precise repo
<ryant5000> bjf: ok, i guess maybe it was a mistake to check out a tag; i'll give it a try from master
<bjf> ryant5000: which tag did you use ?
<ryant5000> bjf: i don't recall exactly, but i think it was the latest tag with a 3.4 version number
<bjf> ryant5000: that should work
<bjf> ryant5000: um, actually ... 3.4? precise is based on 3.2
<ryant5000> bjf: right :) i was hoping to upgrade
<ryant5000> bjf: i'd like to use a couple of features from the new kernel
<bjf> ryant5000: so you have a different option, use the "lts backport" kernel which is a quantal kernel built to run on precise userspace
<ryant5000> bjf: ah, ok; i think i recall seeing that branch
<bjf> ryant5000: it's not really a "backport" just what we call it
<ryant5000> bjf: right; makes sense
<bjf> ryant5000: there's one all built
<bjf> ryant5000: it is built everytime the regular quantal kernel is built
<ryant5000> bjf: oh, can i just grab the deb? i'm not trying to do anything fancy, just a stock 3.4 or later kernel
<ryant5000> (i did try searching for it, but I wasn't able to find it)
<bjf> ryant5000: yes, or it's in a ppa ... one sec
<bjf> ryant5000: https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<bjf> ryant5000: there are other packages there but you want "linux-lts-quantal"
<ryant5000> ok, cool
<ryant5000> bjf: thanks; i'll give that a shot
<bjf> ryant5000: easier than building your own (though that isn't too bad)
<ryant5000> bjf: yeah, definitely; the build process is way easier than the last time i tried (years ago)
<ryant5000> bjf: so, that backports ppa doesn't seem to have the -virtual packages either
<ryant5000> bjf: if i'm going to build myself, should i be building out of the precise or quantal repositories?
<bjf> ryant5000: in quantal the virtual flavour was eliminated
<ryant5000> bjf: hm; so i guess i'll have to tell pv-grub to take the generic flavour
<ryant5000> bjf: it says something about ignoring the generic kernel when it updates grub
<ryant5000> maybe i'll just run on the quantal daily for a while
<dileks> hi
<dileks> I used a quantal kernel-config as base for my linux-next kernel
<dileks> diff: http://paste.ubuntu.com/1091987/
<dileks> now there are new variables CONFIG_MEDIA_*_SUPPORT to sort camera|tv|radio|rc
<dileks> what I did was a 'yes "" | make oldconfig'
<dileks> as CONFIG_MEDIA_*_SUPPORT=n turned off all dvb|radio|rc|camera modules/built-in stuff
<dileks> any other magic make-option where I can keep old media-configs?
<deffrag_> Hello! I've a question related to ARM. As mentioned in line comment 23-28 here - http://lxr.free-electrons.com/source/arch/arm/kernel/kprobes-common.c - R15 gives PC+8 in the first cycle of an instruction then PC
<deffrag_> Oops! R15 gives PC+8 in the first cycle of an instruction then PC+12 in subsequent cycles. What is the reason for that?
#ubuntu-kernel 2012-07-15
<scientes> i had a problem when in emergency mode
<scientes> where the terminal display was on vt 7
<scientes> but i had to be in vt1, seeing nothieng, to input keyboard strokes to it
<scientes> using the 3.5 precise-backport/enablement kernel
<vikram> hii .... I completed Linux Kernel Development by Love ....... now where should i go ?
#ubuntu-kernel 2013-07-08
<disdi> I am currently working upon ubuntu 13.04....I needed some help with overlayfs introduced in 3.10 kernel,can some one help?
<disdi> I am currently working upon ubuntu 13.04....I needed some help with overlayfs introduced in 3.10 kernel,can some one help?
<disdi> I am currently working upon ubuntu 13.04....I needed some help with overlayfs introduced in 3.10 kernel,can some one help?
 * smb is not very happy with the general current quality of gnome-control-center (actually its subtasks) in S...
<ppisati> brb
<smb> Gah! Why do new releases always steal useful keybindings
<apw> smb, you didn't need 'em, you are just using the thing wrong
<smb> Yeah I know. Same as I am completely wrong trying to modify the time-date indicator's appearance
 * henrix -> lunch
<rtg> apw, cking: I'm applying the Lucid CVE patches in case you were in the middle of reviewing them.
<cking> rtg, ok, I'm not reviewing them at the mo
 * ppisati would like a 'focus follows mouse' in unity...
<ogra_> just enable it 
<apw> ppisati, yeah and once enabled enjoy pasting your password into the wrong window ... all the time
<apw> rtg, thanks
<ppisati> apw: already happens now when i've to manually set the focus to the new window with an explicit click
<rtg> apw, just pushed rebase to pre 3.11-rc1 to unstable
<ppisati> ogra_: do you know that 3.11 mandates dtb?
<rtg> ppisati, we have to a user space package for that, right ?
<rtg> we have to have *
<ppisati> rtg: so far dtbs are part of the kernel package
<ppisati> rtg: but people have to deal with them manually
<ppisati> rtg: since flash-kernel doesn't know how to pick the correct dtb
<ppisati> rtg: i'm worried about 2 things:
<ppisati> 1) people upgrading from older releases
<ppisati> 2) people with a modern release but no dtb installed
<ppisati> we probably need a disclaimer at the end of kernel installation, saying 'looks like you are not using DTB, the installatio process aborts here, follow the instruction at http://wiki.ubuntu.com/$somethingdtb'
<rtg> ppisati, I assume you'll be pursuing those issues ?
<ppisati> so they can manually fix their setup
<ppisati> rtg: yep
<ppisati> rtg: i was waiting for 3.11 to come out
<rtg> ppisati, cool. you should get ogasawara to add a work item (or you could just do it yourself)
<ppisati> rtg: i'll do
<ogra_> ppisati, well, i guess thats more a thing for server ... on the client (or phone wehere i work now) side we dont use such modern kernel stuff 
<ppisati> ogra_: right, mobile is not affected
<ppisati> ogra_: desktop and server are
<ogra_> nor are any desktop images
<ogra_> (panda is the only desktop image we have)
<ppisati> ogra_: if you install a 3.11 kernel on a omap, imx6 or vexpress
<ppisati> ogra_: you are affected too
<ogra_> we dont officially support any of these, do we ?
<ogra_> well, vexpress for qemu perhaps 
<ppisati> brb
 * bjf -> dr. appt.
<infinity> ppisati: Fixing DTB handling in flash-kernel shouldn't be too much effort, we should talk about it (and possibly JFDI) at the sprint.
<infinity> ppisati: Also, it's a non-issue for real "servers", as those have DTs burnt into firmware.  Only people without firmware/u-boot support for DTs need to worry about this.
 * rtg -> lunch
<rtg> jjohansen, I ended up dropping 'UBUNTU: SAUCE: (no-up) apparmor: Sync to apparmor 3 dev stable snapshot' when rebasing saucy unstable to 3.11
<jjohansen> rtg: okay, I'll get a 3.11 version together
<jdstrand> does that mean that our kernels no longer have apparmor 3 support?
<jdstrand> seems it wasn't uploaded yet...
<rtg> jdstrand, this is only for the 3.11 unstable branch. I won't upload to saucy for several more RC candidates
<jdstrand> ah, cool. I was scared for a sec :)
<rtg> rather, we won't switch from 3.10 to 3.11 for awhile
 * jdstrand nods
<hallyn_> rtg: any chances i could pursuade you to install mosh on tangerine?
<rtg> hallyn_, in a chroot ?
<hallyn_> on the host
<hallyn_> (for mosh-server, not for the client)
<rtg> hallyn_, the host is running precise
<rtg> ah
<hallyn_> rtg: if you're not comfortable with it that's fine.  i just walk between two networks from one side of the hosue to the other and it gets old :)
<rtg> hallyn_, installed
<hallyn_> rtg: thanks!
<rtg> hallyn_, we may have actually had mosh installed originally, but tangerine got rebuilt 12 months or so ago and likely did not get reinstalled
<hallyn_> rtg: actually i'm an idiot.  i forgot about the ssh forwarding.  i'd need to do nc tunnels for the mosh udp streams
<rtg> I wondered about that a bit
<rtg> I've never used it myself
<hallyn_> i've spent time before trying to get that to work, but it never did so reliably
<rtg> I mostly use screen to preserve sessions across network breakages
<hallyn_> rtg: yeah i still use tmux/screen, but with mosh i save myself having to manually reconnect, and survive suspend/resume
<hallyn_> so please feel free to drop it again - sorry :(
<rtg> hallyn_, np
 * rtg -> EOD
<tlipcon> hey folks. I'm using the 3.9.9 kernel 3.9.9-030909-generic from the mainline PPA, but cant seem to find the corresponding linux-tools package
#ubuntu-kernel 2013-07-09
 * apw yawns
<psivaa> apw: Updated bug #1195710 with some more information, not sure it will help. Have time to look into it?
<ubot2`> Launchpad bug 1195710 in linux (Ubuntu Saucy) "'Kernel bug - invalid opcode: 0000 [#1] SMP' is reported at 'Preparing linux-image-extra-3.10.0-0-generic' stage of multi-lvm installations of amd64 saucy server " [High,Confirmed] https://launchpad.net/bugs/1195710
<apw> psivaa, oh hmmm, increasing memory helped ...
<apw> psivaa, as neither smb nor I could reproduce it, but 1G is my default size
 * ppisati -> reboot
<psivaa> apw: isn't 512 the minimum allowed for server?
<apw> psivaa, oh quite probabally, i just mean the default in the box when i make new instances
<smb> By default I use 1G but I probably have done 512 as well
<smb> Cannot remember right now
<apw> is 1G and that sems 'small' and therefore wasn't going to hit it ... doh
<apw> /srv/images192.0.2.0/24(ro,sync,no_subtree_check)
<apw> /srv/images 192.0.2.0/24(ro,sync,no_subtree_check)
<apw> Error creating pool: Could not start storage pool: cannot open path '/var/lib/libvirt/images/iso': Permission denied
<psivaa> apw: is this one of the utah errors in trying to reproduce the above bug?
<apw> psivaa, oh no, this is me trying to export some images so i can start some new vms with less ram
<apw> psivaa, i am chatting with smb about how retarded libvirt is and how much i would like to meet its mother
<psivaa> apw: ack :)
<apw> (with and axe)
<apw> psivaa, do you have the whole preseed you are using for this install ?
<psivaa> apw: it's here: http://bazaar.launchpad.net/~ubuntu-server-dev/ubuntu-test-cases/server-tests-raring/view/head:/preseeds/multi-lvm.preseed 
<psivaa> attached to the bug as a file as well now
<apw> psivaa, brilliant ..
<apw> smb, ok so using the preseed manually is pretty easy, just change the kernel command line and remove the file=fooo.preseed and replace it with like url=http://192..../foo.preseed
<apw> psivaa, ok with that i was able to repro this, i think ... thanks
<psivaa> apw: ack, thank you
<apw> psivaa, will see what i can find
<apw> psivaa, ok yeah made it do it twice, seems to happen later without utah, utah must be consuming a chunk of memory i recon
<psivaa> apw: that's probable. I always used utah. the client logs are saved in there before retrieving to the server
 * ppisati -> out for lunch
 * henrix follows ppisati
<jjohansen> rtg: so I have a branch with the aa3 sync against pure upstream 3.11, so it doesn't have the ubuntu configs as part of it. Do you want a pull request using this or do you want to point me to your 3.11 rebase?
<rtg> jjohansen, a pull request agsint the saucy unstable branch would be nice
<jjohansen> rtg: ah, got it. I'll have that for you in a few minutes
<rtg> jjohansen, no rush. we won't transition to 3.11 until about rc3 or 4
<jjohansen> rtg: ack
<jjohansen> rtg: okay, I've pushed it to my saucy tree on zinc, I'll do some build testing etc, before sending out the request
<rtg> jjohansen, ack
<FernandoMiguel> howdy
<FernandoMiguel> ever since kernel  3.9.0-7, I haven't managed to get a proper CPU scheduler management 
<FernandoMiguel> 3.10 only offers two states
<FernandoMiguel> and seems to use much more battery
<rtg> sforshee, re: bug #1190225. Is that in drivers/power/smb347-charger.c ?
<ubot2`> Launchpad bug 1190225 in linux-grouper (Ubuntu) "opening /sys/devices/platform/tegra-i2c.4/i2c-4/4-006a/reg_status (as user) causes immediate reboot" [Undecided,New] https://launchpad.net/bugs/1190225
<Sarvatt> FernandoMiguel: update again, i think that was fixed a few weeks ago?
<FernandoMiguel> Sarvatt: every kernel I get, I boot into it, and all are the same
<Sarvatt> or boot with intel_pstate=disable
<sforshee> rtg: looking
<rtg> sforshee, I'm pretty sure that it
<rtg> root@ubuntu-phablet:/# dmesg|grep charger
<rtg> [    2.096531] smb347_charger: [smb347_init] project_id=0, pcba_ver=3, dock_in_gpio=164
<rtg> [    2.098920] [charger] Disable AICL, retval=93 setting=83
<rtg> [    2.099397] [charger] set cahrger limmit, limit=900 retval =73 setting=73
<rtg> [    2.099802] [charger] re-enable AICL, setting=93
<rtg> [    2.627268] smb347_charger: [cable_type_detect] Reg39 : 0x10
<rtg> [    2.627539] smb347_charger: [cable_type_detect] Reg3F : 0xc0
<rtg> [    2.627681] smb347_charger: [cable_type_detect] USB_IN
<rtg> [    2.627949] smb347_charger: [cable_type_detect] Reg3E : 0x0c
<Sarvatt> apw: didn't you make that default to off? i'm not seeing it in the changelog
<apw> Sarvatt, yeah that was disabled in the 3.9 kernel, the rumours were that 3.10 was 'better'
<rtg> Sarvatt, also NO_HZ_FULL=n
<apw> Sarvatt, so it wasn't switched there, on the assumption we would never ever test it there
<apw> Sarvatt, unless it was on, ... are we seeing issues now we are in 3.10
<Sarvatt> oh 3.10 made it start working on ivybridge too and it was bad here once that kicked in
<apw> Sarvatt, so still shit in 3.10 yes
<Sarvatt> yeah, 15C higher idle even in power save mode :(
<apw> if so i can pull that change up to there, and leave it off in 3.11 which rtg is managing
<apw> Sarvatt, well i call that tested in the negative ... 
<FernandoMiguel> Sarvatt: what will that parameter do ?
<sforshee> rtg: looks like it is smb347-charger
<apw> Sarvatt, what the heck was the bug number
<rtg> sforshee, yep
<FernandoMiguel> apw: so it's a known bug/limitation ?
<Sarvatt> i think they expect you to use that intel thermal management daemon to control fans if you use intel_pstate (https://01.org/linux-thermal-daemon)
<FernandoMiguel> cause with 40Âºc here, I can't just leave it in 3.10 Power Save ... it will kill kittens
<apw> pstate_idle being pants, it is 'known of' in 3.9, and now 3.10 yeah
<apw> FernandoMiguel, sounds fun indeed
<FernandoMiguel> apw: it works fine in 3.9.0.7
<apw> FernandoMiguel, and pstate_idle=off or whatever Sarvatt said it was, did the trick for you
<FernandoMiguel> and all before that
<apw> FernandoMiguel, well it was
<FernandoMiguel> the few after and 3.10 broke 
<apw> FernandoMiguel, well it was not enabled for some your kit at all in 3.9 
<FernandoMiguel> there was a 3.10.1 that worked too. but broke again on .2
<FernandoMiguel> so the advice is to pass a kernel option for 3.10 till this is improved, correct?
<FernandoMiguel> any bug # I can track?
<Sarvatt> hmm its not on https://bugs.launchpad.net/~adconrad/+reportedbugs so it must have been closed
<Sarvatt> FernandoMiguel: still trying to find it..
<FernandoMiguel> thanks
<apw> Sarvatt, found it ... bug #1188647
<ubot2`> Launchpad bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,Fix released] https://launchpad.net/bugs/1188647
<FernandoMiguel> GRUB_CMDLINE_LINUX="intel_pstate=disable"
<FernandoMiguel> how will this affect 3.9.x kernels?
<FernandoMiguel> thanks guys!
<apw> FernandoMiguel, if you arn't using there they won't notice it
<FernandoMiguel> apw: the bug is fix released, but it's not fixed in 3.10.x
<apw> rtg, i have pulled that pstate_idle change up to master-next, but _not_ applied it to unstable as per discussion above
<apw> FernandoMiguel, reload the bug
<FernandoMiguel> ah :9
<sforshee> rtg: the offending function is smb347_reg_show. One thing that is obvious is that it's reading more data than what its buffers are sized for.
<FernandoMiguel> apw: need any info on my system to help triage it ?
<apw> FernandoMiguel, the fix was deliberatly applied and releasd against the v3.9 kernel but not applied to unstable (v3.10 based) at the time
<apw> FernandoMiguel, nope, i have turned it off, we suspected it was not ready for mainstream in v3.10 and your confirmation that is sucks is sufficient for me to just disable it pending it getting less crap
<rtg> apw, so 3.11 should work better ? 
<apw> rtg, i think the bigger question is "is v3.11 any better", for v3.10 we left it not applied in unstable so we would find out, i am proposing the same for v3.11
<FernandoMiguel> apw: how many users actually even change schedulers, like I do ?
<apw> rtg, as infinity as an avid user of affected kit we find out pretty smartly if it is utter crap
<rtg> apw, ack.
<apw> FernandoMiguel, heh dunno, but this is a default change so anyone with the kit is getting it by default
<apw> it is new and shiney and meant to give you yet more performance for less power consumption
<apw> which it clearly fails dismally to do
<FernandoMiguel> on battery, it sure changes a lot 
<FernandoMiguel> I've gonne from 5h+  to 2h
<sforshee> rtg: that function has so many things wrong with it
<FernandoMiguel> and that's ondemand
<rtg> sforshee, off by one everywhere
<FernandoMiguel> now I need to track down unity folks.... unity service is hogging a core.... :\
<apw> FernandoMiguel, heh only one, you are lucky
<FernandoMiguel> bye! if you need any update or testing, I'm subbed to the bug and can be found on #+1
<rtg> sforshee, do you suppose it _ever_ worked ?
<sforshee> rtg: I doubt it
<FernandoMiguel> apw: $ killall -9 unity-panel-service 
<FernandoMiguel> that's how I've been surviving 
<FernandoMiguel> everytime I hear the fans go crazy
<rtg> sforshee, well, I'm gonna hack on it to see if I can get it to stop faulting
<sforshee> rtg: I added a comment to the bug, definitely looks like stack corruption
<rtg> sforshee, agreed
<apw> FernandoMiguel, hopefully the peeps on #ubuntu-unity have it covered
<FernandoMiguel> thanks
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<Quintasan> Hi, I've recently discovered that my system stopped reading blanks DVDs. Since I didn't want to open up a new bug without any searching I did some digging around and last time anyone had a problem with it was Lucid. I did check the disk itself on another PC and it's blank for sure. I also did check it on Windows, blank there too. Output of `sudo /lib/udev/cdrom_id --debug /dev/sr0` is  http://paste.ubuntu.com/5858658/ and output of `sudo 
<Quintasan> strace -vvfo /tmp/cdrom_id_new.trace -s 1024 /lib/udev/cdrom_id --debug /dev/sr0` is http://paste.ubuntu.com/5858660 . The bug I found was bug #561585
<ubot2`> Launchpad bug 561585 in udev (Ubuntu Lucid) "Blank cd/dvd not recognized [LUCID] " [High,Fix released] https://launchpad.net/bugs/561585
<rtg> jdstrand, I'll have a look
<jdstrand> rtg: thanks! :)
<rtg> jdstrand, hmm, I would have expected all netfilter options to have been enabled. I'll look closer.
<jdstrand> yeah
<rtg> its not like the LOG target is new
<Sarvatt> apw: so I'm on 3.10.0-0 that has # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y, i'll verify intel_pstate is still crazy on -2 now
<apw> rtg, grouper was missing a few last i looked, that was one of the patches i did, out of date now of course
<Sarvatt> ah 3.10.0-2 still has that combo, someone responded on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/comments/6
<ubot2`> Ubuntu bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,Fix committed]
<rtg> apw, I thought I normalized all netfilter config options. 'UBUNTU: [Config] Enable and modularize all netfilter matches'
<rtg> jdstrand, CONFIG_NETFILTER_XT_TARGET_NFLOG=y for mako
<apw> rtg, ahh so you did
<jdstrand> rtg: [    0.000000] Linux version 3.4.0-3-mako (buildd@tritons) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-5ubuntu2) ) #13-Ubuntu SMP PREEMPT Tue Jun 25 17:07:54 UTC 2013
<jdstrand> rtg: is that too old? ^
<rtg> jdstrand, nope, thats current
<rtg> jdstrand, maybe I'm looking at the wrong option. 'CONFIG_IP_NF_TARGET_ULOG is not set'
<jdstrand> this isn't ulog
<Sarvatt> i'm building a kernel with CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ_FULL=n CONFIG_NO_HZ_FULL_ALL=n to test that guys theory
<jdstrand> ufw doesn't support ulog. I was going to, then no one did it for ipv6 and said it was bad or something, and so I said forget it
<jdstrand> rtg: my desktop generic kernel has:
<jdstrand> CONFIG_NETFILTER_NETLINK_LOG=m
<jdstrand> CONFIG_NETFILTER_XT_TARGET_LOG=m
<jdstrand> CONFIG_NETFILTER_XT_TARGET_NFLOG=m
<rtg> jdstrand, yeah, looks like I missed some
<jdstrand> CONFIG_NETFILTER_XT_TARGET_LOG is what we want I'm quite sure
<jdstrand> NFLOG is the successor for ULOG
<rtg> jdstrand, 'This option adds a `LOG' target, which allows you to create rules...'
<jdstrand> ok, cool
<ogasawara> apw, rtg: bug 1196597, I've a one line patch to shove in for Saucy, I'll submit the SRU for Raring
<ubot2`> Launchpad bug 1196597 in linux (Ubuntu Raring) "nic-modules udeb does not contain the qlcnic driver for Qlogic" [Medium,In progress] https://launchpad.net/bugs/1196597
<rtg> ogasawara, ack
<rtg> ogasawara, get it in both master-next and unstable for saucy
<ogasawara> rtg: just want to make sure I won't mess anyone up if I shove this up
<ogasawara> rtg: ack
<apw> ogasawara, not touching anything here, shove away
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 16th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati -> gym
 * rtg -> lunch
 * henrix -> EOD
<rtg> bjf, is there a Raring bug for 'UBUNTU: [Config] CONFIG_ARM_ERRATA_643719=y' ? Shall I do the same for saucy ?
<bjf> rtg, i didn't create a bug. it was a FTBS fix :-(
<rtg> huh
<rtg> because of a stable update ?
<bjf> rtg, yes
<bjf> rtg, i forgot to run updateconfigs before submitting
<bjf> rtg, i'd have to go look at where it came it
<rtg> bjf, no big deal. I just wanna be sure saucy is consistent
<bjf> ack
<bjf> rtg, it came in the 3.8.13.4 upstream stable release  bug 1199100  "ARM: 7752/1: errata: LoUIS bit field in CLIDR register is incorrect"
<ubot2`> Launchpad bug 1199100 in linux (Ubuntu Raring) "Raring update to 3.8.13.4 stable release" [Undecided,New] https://launchpad.net/bugs/1199100
<bjf> just fyi
<rtg> bjf, I've got it set in both saucy branches
 * rtg -> EOD
<hallyn_> apw: just fyi, that sigchld delivery weirdness?  I can't reproduce it in 3.2, 3.5 or 3.7.  (mind you what we found before was a usage bug, but fixing that in lxc didn't help - so it looks like i ws facing one kernel and one userspace bug)
<hallyn_> hopefully i don't offend when i say that bisecting ubuntu kernels is something i like to avoid
<apw> hallyn_, it is something we all like to avoid
<hallyn_> "Bisecting: a merge base must be tested"
<hallyn_> so i'm just sort of manually bisecting by Ubuntu-3.7.0-7.15 versions, then i'll try and do upstream git commit (when i can nail down a reasonable ubuntu-ified config)
<hallyn_> actually i guess i must be just about there.  3.7..3.8 shouldn't require too much config wrangling
<apw> hallyn_, sounds sane
<xnox> so grouper kernel is old, such that avahi doesn't work out of the box, and needs it's parameters tweaked for kernels << 3.9.4 or something like that.
<ohsix> what.
<ohsix> since when does avahi have 'parameters', and since when does it do anything but very basic network access
#ubuntu-kernel 2013-07-10
<apw> xnox, grouper with avahi really?
<smb> morning .*
<apw> smb, moin
<smb> apw, Today's S at least lets you change time+date and privacy settings... win. :)
<apw> smb, sounds like a big improvement :)
<smb> Absolutely. I won't turn mad being in a different tz than my installation is. :-P
<RAOF> Does anyone else find their kernel hanging processes in schedule() for minutes at a time?
<RAOF> Ah. Probably not, because no one's crazy enough to btrfs.
 * henrix_ -> really late lunch
<apw> rtg, turns out it is linux-signed skew ... cause i cannot make one of those to match ... arrgle
<rtg> apw, hmm, gotta love that. how come there is skew ?
<apw> cause i am making a test kernel, and i cannot make a real signed one, ever
<rtg> ah, doh! does it work OK with an archive kernel ?
<henrix> rtg: bjf: the EFI patchset is now queued for 3.5.y. i'll probably be sending it out for review tomorrow or friday, so early next week i should have a release with them
<rtg> henrix, ack
<bjf> henrix, ack, sounds good
<ppisati> bjf: no more -proposed for SRU kernels, just series name, right? (e.g. precise instead of precise-proposed)
<bjf> ppisati, correct
<ppisati> bjf: and, did you do any modification to kteam-tools/maintscripts/verify-release-ready?
<bjf> ppisati, it should be fixed so that it doesn't require -proposed any longer
<ppisati> bjf: but it complains here in another way
<ppisati> bjf: http://paste.ubuntu.com/5861831/
<bjf> ppisati, seems pretty obvious from that error message what your problem is :-)
<ppisati> bjf: "Error: n"? :)
<bjf> ppisati, which kernel are you working on ?
<ppisati> bjf: i'm rebasing lucid/omap4 on top of lucid/master
<bjf> ack
<bjf> ppisati, when was the last time you worked on that?
<ppisati> bjf: last release
<ppisati> bjf: ~two weeks ago
<bjf> not lucid
<ppisati> bjf: sorry, i meant precise
<bjf> ppisati, it "just works" for me
<ppisati> bjf: let me try again
 * apw has to run and do some family bits in about 5 m ... laters
<rtg> ppisati, are you building bootable kernels for armhf with saucy gcc-4.8 ? None of the nexus kernels are being built with gcc-4.8
<ppisati> rtg: actually i had problems yesterday with a kernel not booting, but i thought it was my mistake in the .config since i was compiling vanilla
<rtg> ppisati, perhaps you should step back to gcc-4.7 ?
<ppisati> rtg:  i can give it a try
<zequence> apw: reminder about -lowlatency :)
<ppisati> rtg: you are right, same kernel src&.config
<ppisati> rtg: with 4.7 it boots, with 4.8 it hangs
<rtg> ppisati, works with 4.7 ?
<rtg> OK
<ppisati> rtg: yep
<ppisati> rtg: but my 4.7 was armel
<ppisati> [    0.000000] Linux version 3.6.11 (flag@luxor) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #21 SMP Wed Jul 10 18:15:43 CEST 2013
<ppisati> this is what i have:
<ppisati> [flag@luxor linux-2.6]$ dpkg -l | grep gcc-arm-linux-gnueabi
<ppisati> ii  gcc-arm-linux-gnueabi                         4:4.7.2-1                                  amd64        The GNU C compiler for armel architecture
<ppisati> ii  gcc-arm-linux-gnueabihf                       4:4.8.1-1                                  amd64        The GNU C compiler for armhf architecture
<rtg> ppisati, can you build with 4.7 armhf ? do you have the right HW ?
<ppisati> rtg: if i can find the toolchain, yes
<rtg> I'm pretty sure there is a 4.7 armhf in saucy
<ppisati> funny
<ppisati> [flag@luxor linux-2.6]$ which arm-linux-gnueabi-gcc
<ppisati> /usr/bin/arm-linux-gnueabi-gcc
<ppisati> [flag@luxor linux-2.6]$ dpkg -S /usr/bin/arm-linux-gnueabi-gcc
<ppisati> gcc-arm-linux-gnueabi: /usr/bin/arm-linux-gnueabi-gcc
<ppisati> [flag@luxor linux-2.6]$ arm-linux-gnueabi-gcc -v
<ppisati> ...
<ppisati> gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
<ppisati> 4.7.3 gcc in a 4.7.2-1 gcc-arm-linux-gnueabi package
<hallyn> apw: GAH!  middle of a git bisect upstream between 3.7 and 3.8, it suddenly dumped into a 3.1 version.  <rage>
 * hallyn looks at git bisect log and tries to restart with last known good+bad
<rtg> ppisati, so, does that mean the 4.7 cross compiler is not a hard float compiler ? does it matter for the kernel if its armel or armhf ?
<ppisati> rtg: IIRC we are still using armel on mobile
<ppisati> ogra_: ^
<ogra_> ?
<ogra_> the armel builds live in their own universe 
<ogra_> (and use a bionic toolchain)
<ogra_> i dont think we have any glibc armel cross compiler anymore 
<ogra_> (there is gcc-arm-linux-androideabi, but thats not something anyone should use)
<BenC> apw, rtg: This config check is failing on powerpc saucy 3.10.0
<BenC> check-config: FAIL: (arch armel armhf &/ value CONFIG_GPIO_TWL4030 y) |   value CONFIG_GPIO_TWL4030 m |   !exists CONFIG_GPIO_TWL4030
<rtg> BenC, I wonder why ? that option shouldn't even exist for ppc, does it ?
<BenC> I've set CONFIG_GPIO_TWL4030=m to get around it, but it appears to be faulty nonetheless
<BenC> Setting it to y/n gives the check failure though
<rtg> BenC, right. start a bug and assign apw to it. the config checker uses a completely (to me) inscrutable language.
<BenC> rtg: It prompts for all four flavours, but I wanted to set it to "is not set"
<BenC> config checker is black magic that I fail to comprehend as well
<rtg> BenC, you could always just patch that line out of the config checker. its not like it changes that much.
<BenC> I'm perfectly happy not having to touch the enforce file, even if it means having a useless module enabled :)
<rtg> yeah, it wouldn't ever get insmod'd anyways
<xnox> ogra_: i believe we have all three cross-toolchains.
<ogra_> xnox, i belive armel was dropped for arm64 
<ogra_> (there might be a toolcahin, but i think there is no gcc for it anymore)
<xnox> ogra_: right there is no 4.8 armel cross.
<xnox> rtg: ppisati: ogra_: i believe that kernels for mobile are compiled natively using armhf toolchain, android userspace is compiled using armel-v5-bionic based toolchain. We have armel/armhf/arm64 4.7 cross compilers in saucy, and 4.8 armhf/arm64
<xnox> https://launchpad.net/ubuntu/+source/gcc-4.7-armel-cross
<xnox> https://launchpad.net/ubuntu/+source/gcc-4.7-armhf-cross
<xnox> https://launchpad.net/ubuntu/+source/gcc-4.7-arm64-cross
<xnox> ... and matching for 4.8
<xnox> for mobile we are sticking with 4.7 for now, as kernels fail to boot / userspace gets borked with 4.8.
<ogra_> yeah
<rtg> xnox, the native gcc-4.8 armhf compiler does not produce a bootable kernel for any of the Nexus devices.
<xnox> rtg: correct. so 4.7 one is used instead.
<rtg> xnox, actually, we use 4.6 on at least one device
<xnox>  /o\
<xnox> rtg: it's a shame....
<rtg> xnox, are we just gonna end up ignoring the fact that 4.8 is broken for this dev cycle ?
<xnox> rtg: android open source project / cynogenmod / linaro should first make a toolchain & bring up bootable kernels with gcc-4.8. Until that happens, there is no intension to invest any engineering effort in doing this bring up.
<xnox> rtg: linaro is supposedly working on 4.8 bring up, but they are still default to gcc4.7 across the board for "stable" stuff.
<rtg> xnox, ppisati has pointed out that we can't use it for the distro kernels either.
<rtg> distro armhf kernels*
<xnox> rtg: well.... all of our distro armhf kernels are at various stages of decay. Is any one of those flavours at the same major version as amd64/i386 kernels?
<rtg> xnox, of course. the omap series, vexpress, and some others. mostly those that use device tree blobs
<xnox> rtg: "ignoring the fact that 4.8 is broken for this dev cycle" sounds a bit weird to me. "ignore the fact that old kernels do not support building with gcc-4.8, and target devices are not ported to newer kernels, and instead frozen in-time by their manufacturers"
<rtg> damned if I know if they even work, though
<xnox> rtg: I guess we should care to build armhf generic most recent kernel for calxeda and friends.
<rtg> xnox, exactly. I think calxeda _does_ work, though I'd have to make sure with ppisati first.
<xnox> rtg: we have two rigs available and before they go into production, could test kernels on them, I guess.
<xnox> rtg: but i think, everyone now knows that it's fact of life that ac100/panda/$(nexus devices) are shipping old kernels and cannot be build with gcc4.8.
<ppisati> rtg: correct, 4.7 arm[el|hf] are ok, 4.8 armhf is bad
<rtg> xnox, agreed. Then I'm gonna mark ricardo's bugs complaining about gcc-4.8 "won't fix"
<ogra_> it needs to be armhf in any case 
<ogra_> we dont have an armel archive anymore :)
<rtg> ppisati, gcc-4.8 fails even on calxeda ?
<ogra_> you would have to do a lot of tricks to actually cheat that into the archive 
<ppisati> rtg: didn't test calxeda, omap4 only
<ogra_> what do you do with omap4 anyway ?
<ogra_> we still use the quantal kernel for it 
<ppisati> ogra_: i test toolchain :)
<rtg> ppisati, well, I guess it makes no difference if it works or not. it fails on omap, so we have to use an older compiler regardless.
<ogra_> and that wont change
<ogra_> ah
<ppisati> ogra_: btw, [flag@luxor ~]$ arm-linux-gnueabi-gcc -v
<ppisati> ogra_: gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
<ogra_> yeah, 4.7 
<ppisati> [flag@luxor ~]$ dpkg -S arm-linux-gnueabi-gcc
<ogra_> we dropped armel from 4.8 for arm64 
<ppisati> gcc-arm-linux-gnueabi: /usr/bin/arm-linux-gnueabi-gcc
<ppisati> ogra_: so we have bot armel and armhf for 4.7
<ogra_> right
<ppisati> ogra_: and armhf only with 4.8
<ogra_> yeah
<xnox> yes.
<ppisati> ok so
<ppisati> both 4.7 are good
<ppisati> 4.8 armhf is bad
<xnox> (and arm64 with both 4.7 & 4.8)
<xnox> rtg: where is that bug? =)
<rtg> xnox, bug #1176255 and #1181046
<ubot2`> Launchpad bug 1181046 in linux-manta (Ubuntu) " linux-manta keeps rebooting when built with gcc 4.7 or 4.8" [Undecided,New] https://launchpad.net/bugs/1181046
<ubot2`> Launchpad bug 1176255 in linux-mako (Ubuntu) "linux-mako fails to boot when built with gcc 4.8" [High,New] https://launchpad.net/bugs/1176255
<rtg> I don't we bothered making a bug for the other platforms
<ogra_> hmpf
<ogra_> someone could at least have added the ram console dump 
<xnox> rtg: mark those bug as affecting project "gcc-linaro" =)
 * ogra_ needs to write a wikipage how to debug android boots without serial console 
<rtg> I'll create a meta bug, make those other duplicates, and reference all of the relevant packages.
<rtg> but first, I'm gonna eat lunch 'cause I'm starving.
 * rtg -> lunch
<ogra_> a ram console dump is the least bit that should be attached to kernel boot bugs
<infinity> ppisati: Building the ARM generic kernel with 4.8 breaks, or do you mean that ti-omap4/3.5.0 breaks?
<infinity> ppisati: The latter seems entirely reasonable, the former would be a bug.
<ppisati> infinity: buidling a vanilla kernel (3.6 omap2_defconfig in this case) hangs on boot when cross compiled with 4.8 armhf
<ppisati> infinity: same src & .config with 4.7 is ok
<infinity> ppisati: I don't much care about 3.6, we've moved on to 3.10...
<infinity> ppisati: Hence why I asked about the "ARM generic kernel".
<ppisati> infinity:  i do care about a toolchain that can't compile a kernel, dunno about you
<infinity> Old kernels need old compilers is not a new situation.  And could be cherry-picked to hell to fix, if we're still shipping ancient kernels in an LTS.
<infinity> ppisati: Can't compile a kernel we don't ship?  We have no 3.6 omap kernels in the archive, last I checked.
<infinity> No toolchain can compile all kernel sources.  The kernel plays pretty fast and loose with GCC misfeatures, and they tend to need to be of a similar vintage to be happy.  This has been true for literally decades.
<ppisati> infinity: someone else reported that it can't compile a supported kernel with 4,8, isn't it enough?
<xnox> ppisati: no.
<infinity> ppisati: If we need to keep 4.6 to compile our crappy old Android kernels, so be it.
<infinity> ppisati: If 3.10 compiles and boots fine with 4.8, that sort of proves the bug has been addressed upstream, and if we cared, we could cherrypick the kernel fixes to our Android kernels.
<infinity> So, the question is, do we care?
<infinity> In almost no way does any of this constitute a GCC bug.
<ogra_> no, we dont 
<ogra_> (for the android kernels)
<infinity> ogra_: doko may disagree. :P
<ogra_> then he can ask for it 
<ogra_> from a phonedations POV we dont :)
<xnox> ppisati: supported means - we will make a package available that will work. supported - doesn't mean we will backport frankenstein changes from recent kernels back to something 6 kernel releases back make it compile with optimized 4.8 toolchain, do benchmarks and conclude that it doesn't gain us anything.
<xnox> infinity: doko, had a sad moment that 4.8 didn't work with kernels, and went on to upload 4.7 point release update into saucy.
<infinity> Now, it's probably entirely valid that if the only toolchain that can cross these old kernels is 4.6, we might need to reintroduce the 4.6-cross packages.
<xnox> infinity: well most work with 4.7 fine, one seems to need 4.6 (the oldest kernel).
<infinity> Meh.  Kay, if it's just the one, people can suffer and build that natively.
<infinity> I assume that's the platform still stuck on 3.1, for whatever reason.
<xnox> infinity: it's not like that kernel will ever change though.... so it has already been build once......
<infinity> xnox: You don't watch rtg's uploads, clearly.  He seems to upload Android kernels more often than mainline. :P
<xnox> maguro: 3.0.0; grouper: 3.1.10; manta/mako 3.4.0
<infinity> (But I suppose once the config syncing and other bits are sorted, he'll stop)
<ogra_> infinity, 3.1 ? modern stuff :P
<ogra_> maguro (omap4) uses 3.0 
<ogra_> root@ubuntu-phablet:/# uname  -r
<ogra_> 3.0.0-3-maguro
<xnox> infinity: i guess it might make a little sense to poke the 4.6 one and see if can be patched up to use 4.7 (maybe somebody in cynogenmod et al did it already)
<infinity> Ironic, given all the years we supported omap4.
<ogra_> yeah
<ogra_> well, its alll about the binary blobs
<xnox> ogra_: by the way, I solved my fetching sources problem with: chdist + python-apt magic
<ogra_> haha
<ogra_> hacks FTW :)
<ogra_> nice one though 
<xnox> ogra_: it's slightly better than PULL_LP_BIN 
 * ogra_ hopes nobody ever looks deeply into ubuntu-touch-initrd-generic 
<ogra_> it does funny things too 
<xnox> ogra_: cause, my hacks should work on the distro builder as well.
<xnox> infinity: one can always compile those kernel in the last release that had gcc-4.6-cross and then copy up.....
 * xnox hides
<hallyn> apw: I plead for help.  http://paste.ubuntu.com/5862473/   
<hallyn> does the fact that it was testing a merge point confuse git-bisect afterward?
<hallyn> (I tested that on tangerine as well as my precise builder, so it's not just the git version)
<rtg> hallyn, you can't bisect across a non-linear space. 
<rtg> at least, not very easily
<hallyn> I thought Linus' tree was supposed to always be bisectable
<rtg> hallyn, Linus's tree is, but not Ubuntu
<hallyn> ok - I'll take a different approach.
<hallyn> this is on Linus' tree
<rtg> hallyn, what is HEAD in your example ?
<hallyn> at which point?
<hallyn> right nwo it is c5482bbd9607bf38cbc952eacaa429e6ba3160a0
<rtg> the starting value for 'git bisect start'
<hallyn> rtg: that shouldn't matter right?  it's been different, but with the same result - it takes the git bisect good and bad values to start with
<rtg> I guess it makes no difference really.
<rtg> right
<hallyn> all right - was hoping there was some magic pixie dust i didn't knwo about to fix it.  i guess i'll just focus on changes to kernel/{exit,signal}.c, which are few
<hallyn> I've got my eye on af4b8a83add95ef40716401395b44a1b579965f4 pidns: Wait in zap_pid_ns_processes until pid_ns->nr_hashed
<rtg> hallyn, maybe its because those SHA1 IDs are merge commits
<hallyn> rtg: I just would expect git bisect to DTRT...  (maybe it *did* do the right thing, but that's not how I see it)
<rtg> hallyn, sometimes git still surprises me
<hallyn> s/surprises/disappoints/ in this case :)
<hallyn> rtg: thanks.  i'll track it down by hand - ttyl
<hallyn> i was right, that's the bad commit.  
<hallyn> apw: ^ the signal weirdness was introduced there (af4b8a83add95ef40716401395b44a1b579965f4 pidns: Wait in zap_pid_ns_processes until pid_ns->nr_hashed)
<hallyn> just fyi, since i KNOW you're losing sleep over it :)
<FernandoMiguel> apw: Sarvatt: FYI been running 3.10 with intel_pstate=disable, so far no major problem detected and heat, cpu management , battery back to previous values
<FernandoMiguel> thanks
<Sarvatt> FernandoMiguel: I've been running a kernel using intel_pstate with the changes on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/comments/6 and not having any problems -- http://kernel.ubuntu.com/~sarvatt/intel_pstate/
<ubot2`> Ubuntu bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,Fix committed]
<Sarvatt> but i haven't been tracking battery usage, just heat
<hallyn> ah, maybe i see the problem
 * rtg -> EOD
 * cooloney waves at apw ogasawara smb bjf vanhoof
<vanhoof> hi cooloney 
<vanhoof> cooloney: bu yao! :)
<cooloney> vanhoof: how's going? you're a busy man!
<vanhoof> cooloney: not too bad, busy as always :) ... how about you?
<cooloney> vanhoof: very good. i'm working on V4L2 camera stuff on Tegra.
<cooloney> vanhoof: hope to meet you guys somewhere
<vanhoof> cooloney: I'll be in the bay area later this month I think
<vanhoof> cooloney: come pick me up from sfo :)
<cooloney> cool, let's hangout.
<vanhoof> +1
<cooloney> sure, i will drive my lamborghini
<vanhoof> cooloney: gucci leather?
<manjo> cooloney, does the camera work ? 
<manjo> cooloney, I hear Lamborghini's don't have AC ... 
<cooloney> oh, manjo, you are always ask the key question
<ohsix> they do
<cooloney> vanhoof and manjo, you know, I mean there is a bus from SFO named Lamborghini, not that one you guys expect
<manjo> lol
<vanhoof> cooloney: don't toy with my emotions :)
<manjo> why drive a 250k car when you can ride in a 1/2 mil bus
<manjo> cooloney, now I see the logic in your v4l camera device 
<cooloney> also I have bike named Maserati, if you guys wanna ride
<manjo> motor or foot powered ? 
<vanhoof> cooloney: with pedals?
<vanhoof> :)
<manjo> does it go ding ding ? 
<cooloney> oh, one pedal works and the other not 
<cooloney> manjo: it always goes dingding except the bell.
<manjo> cooloney, you are always full of surprises !  
<cooloney> manjo: will you come with vanhoof this time?
<manjo> vanhoof, am I going with you to CA ?
<manjo> cooloney, peons don't get to go I think ... 
<manjo> cooloney, are you going to plumbers in NO this sept ? 
<cooloney> manjo: probably not. if it is in bay area, i might go.
#ubuntu-kernel 2013-07-11
<RAOF> We now return you to your regularly-scheduled multi-minute btfrs hissy fit.
<Sarvatt> RAOF: sorry you chose to inflict that pain upon yourself :P
<RAOF> Sarvatt: But it's soooooo shiny!
<Sarvatt> kind of amazing how long you've had btrfs problems actually
<Sarvatt> pre-nouveau getting merged upstream!
<RAOF> That hasn't been one continuous btrfs annoyance 
<RAOF> It's generally alternated between hating btrfs and running ext4, wondering whether btfrs will be different this time 
<ohsix> sounds like an abusive relationship
 * smb shuffles in
<ppisati> smb: plenty of space here, welcome :)
<smb> ppisati, Good morning. :)
 * apw yawns slowly
 * RAOF pours the bees from the pot.
<apw> RAOF, you are the man
 * apw shows his age
<apw> RAOF, lush
 * apw hopes he has covered it up
<RAOF> Bask in my self-inflicted pain: http://paste.ubuntu.com/5864165/
<apw> heh btrfs, that is a good idea
<ppisati> brb
 * ppisati -> out for lunch
<rtg> jsalisbury, bouncing gomeisa for kernel update
<smoser> smb, ping
<smb> smoser, pong
<smoser> https://bugs.launchpad.net/lansing/+bug/1199151
<ubot2`> smoser: Error: ubuntu bug 1199151 not found
<smoser> could you build me a kernel with that ? i know i can build one too...
<smoser> plan would be to test on a raring instance, as there'd be no easy way to get the kernel *onto* a saucy instance.
<smoser> ah. never mind, smb. 
<smb> smoser, huh? bit lost (was looking away for a second)
<smoser> never mind. i subscribed you to that bug, but utlemming just reported it that the patch was in our kernel
<smb> Ah
<rtg> apw, apply your ext4 patch and I'll upload this morning. there is enough good stuff on tip to warrant an upload
<apw> rtg pushed, do give it a good test
<rtg> ppisati, rebooting tangerine for kernel update
<jsalisbury> apw, Is it not possible to boot the mainline kernels on a Hyper-V host?  Does the kernel need drivers that are included in Ubuntu and not Mainline?  I'm referring to these Mainline kernels:http://kernel.ubuntu.com/~kernel-ppa/mainline/ 
<infinity> ppisati: Your ti-omap4 upload had a sad.
<infinity> bjf: Well, technically yours, I suppose. :P
<ppisati> infinity: sad moment? :)
<ppisati> infinity: which one?
<infinity> ppisati: quantal
<infinity> ppisati: https://launchpadlibrarian.net/144713745/buildlog_ubuntu-quantal-armhf.linux-ti-omap4_3.5.0-228.41_FAILEDTOBUILD.txt.gz
<infinity> Looks like merging the configs needed you to sort out some fallout.
<cking> http://wompwompwomp.com/
<infinity> Wow, someone forked sadtrombone.com
<ppisati> infinity: crap
<ppisati> infinity: wait a sec
<rtg> apw, anything in particular I should do to test your ext4 patch ? 
<apw> jsalisbury, a good question, i am not sure i can think of anything in the later ones ... for recent releases
<rtg> I've booted it on an 8.8T file system
<infinity> ppisati: Given the unlikeliness of having ath9k on omap4, the path of least resistance is probably just to revert that one config change from master in your merge.
<apw> rtg, i think if we can use it and not lose our filesystems
<apw> liek if you can build a kernel i am happy its not regressing
<rtg> I'll do a build...
<ogra_> cking, CFQ vs deadline could be an MMC wearout thing 
<jsalisbury> apw, cool, thanks
<ogra_> (i doubt it matters much in reality, but deadline might be minimally better here)
<apw> jsalisbury, the only thing they might not have is a valid hvp daemon, not sure how to handle that
<cking> ogra_, who knows
<ogra_> :)
<jsalisbury> apw, ok, thanks.  I was wondering, so I know if a bisect can be done on Hyper-V using mainline kernels.
<apw> we would have to get signidicantly better merg
<apw> merging to have any obvious delta in writes per flash block
<cking> ogra_, i'm more concerned about  the wear causes by excessive logging by unity8 at the mo
<cking> *caused
<ogra_> cking, thats a temporary thing :)
<ogra_> phonedations is aware ... we'll cuto down logging massively before release
<cking> ogra_, it's darn hard to make sensible measurements when some processes are telling us what's going on all the time
<cking> is there a way to shut it up? 
<ogra_> oh, you complain about the processes themselves 
<ogra_> hmm, not really ... what we plan to do for release is to quieten syslog as much as we can and to do the same for upstart 
<cking> ogra_, well, run fatrace -c from / and you will see lots of happy processes writing away 
<ogra_> but that wont prevent the processes themselves from talking to the logging entity
<cking> I guess I symlink it to /dev/null and I'm happy
<ogra_> symlink what to /dev/null ?
<cking> the various log files
<ogra_> ah, yeah, per logfile will work
<ogra_> just dont like the whole of /var/log ... some apps expect nodes there :)
 * cking nods + sighs
<ppisati> bjf: how do i trigger a reupload?
<ppisati> bjf: lp1199276
<ppisati> bug 1199276
<ubot2`> Launchpad bug 1199276 in Kernel SRU Workflow prepare-package "linux-ti-omap4: 3.5.0-228.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1199276
<bjf> ppisati, are you saying that you've made additional changes to your branch and you want me to pull that now ?
<ppisati> bjf: yep, the building was broken 
<ppisati> bjf: https://launchpadlibrarian.net/144713745/buildlog_ubuntu-quantal-armhf.linux-ti-omap4_3.5.0-228.41_FAILEDTOBUILD.txt.gz
<bjf> looking
<bjf> ppisati, i'm looking at your branch. it has the same version and the history looks the same did you make a change and then just rebase it away?
<ppisati> bjf: i did an updateconfigs, then i 'git rebase -i HEAD~5', moved it before the new release
<ppisati> bjf: deleted the old tag, retagged, etc
<bjf> ppisati, that ship has sailed, you can't do that
<ppisati> bjf: ok then, shall i start a new release&c?
<bjf> ppisati, yes please
<ppisati> bjf: shall i change the version in the bug title too?
<bjf> ppisati, yup
<infinity> ppisati: It didn't need yet another ABI bump.
<infinity> ppisati: 228.42 would have been fine.
<bjf> i can fix that part
<bjf> though it would be better if ppisati did it and built it
<ppisati> infinity: the new startnewrelease script now automagically bumps upload and ABI number
<bjf> ppisati, yes, but you can still edit the changelog and back that out
<ppisati> bjf: well, if we do it blindly at every upload now, this is just one of them
 * infinity shrugs.
<infinity> The inflation isn't a big deal, it just seems silly for a kernel that no one could possibly have had installed.
<bjf> ppisati, is your branch all ready?
<ppisati> bjf: one sec
<infinity> (For the record, you could have reused the version too, if we'd deleted the old one and waited for it to get reaped)
<ppisati> infinity: that's what i did first
<infinity> I think we proved this theory a few weeks ago.
<infinity> ppisati: I know.
<infinity> ppisati: But I wasn't looking when Brad chewed you out for that. :)
<infinity> (Plus, sitting around waiting for LP to scrub all knowlege of the previous upload is annoying)
<infinity> (And not worth the effort)
<ppisati> bjf: ready to go
<bjf> ppisati, thanks
<bjf> ppisati, uploaded
<ppisati> bjf: thanks
<rtg> apw, just pushed unstable. could you review 83d2cc37d009ec5dfdc3bb05410677b3deba6c6c and make sure the call to ddebug_dyndbg_module_param_cb() is correct.
 * apw looks
 * rtg -> lunch
<infinity>   * Build armhf using gcc-4.7
<infinity> rtg: ^-- I thought we'd established that 3.10 was fine with gcc-4.8, and it was only the older kernels that needed older compilers?
<infinity> At least, that's how I interpreted yesterday's discussion.
<apw> rtg, i think you need to check the all and return 0 if all is set as in pass_unknown_bootoptions()
<BenC> rtg, infinity, apw: linux-ppc-3.10.0 uploaded for saucy
<infinity> BenC: \o/
<apw> for that new routine as it is expecting to only see the unknown ones, we don't want it erroring out there
<BenC> infinity: If you could test ppc32/ppc64 for me when you get a chance, I'd appreciate it. I'm holding off on linux-meta until then
<infinity> BenC: I'm nowhere near any such machines right now, but I might have a POWER7 in front of me sometime next week.
<infinity> BenC: I'm not rebooting anything on my home network from across the ocean.
<BenC> infinity: Hmmâ¦well, I may just upload meta then and wait for the fallout :)
<BenC> I don't expect any problems though
<infinity> BenC: How big is your patchset against master these days?
<infinity> BenC: If you're getting closer to mainline, I imagine POWER and old skool PowerPC will be fine.
<BenC> infinity: about 10 sauce patches, 95% only affects my hardware though
 * infinity nods.
<infinity> Probably won't be problematic.  Shame I can't test my home machines until August, though.
<infinity> BenC: May as well just push the meta now, and let the chips fall where they may.
<BenC> infinity: done
<BenC> infinity: For reference, I didn't create a new repo, just a new saucy branch in meta git tree
<infinity> BenC: Alright.
<infinity> BenC: Your kernel was FTBFS anyway. :P
<BenC>  /bin/sh: 1: bc: not found
<BenC> Odd new build-dep there
<infinity> You might want to double-check against master.
<infinity> It has that build-dep for sure, but you may be out of sync with others.
<BenC> I added python-dev too
<rtg> infinity, ppisati reported that gcc-4.8 would not compile a bootable kernel for a 3.10 omap, but that 4.7 was OK. its not clear if calxeda failed with gcc-4.8.
<infinity> rtg: Hrm, in the discussion, I thought his omap mentions were 3.5/3.6, not 3.10 ... But I'm nowhere near hardware to test right now, so meh.
<rtg> infinity, he's gone until Tuesday.
<infinity> rtg: We can always revisit again later.  It's not like reverting the compiler will hurt anything, until doko starts getting annoyed with everyone who won't let him remove old versions. ;)
<rtg> indeed
<infinity> BenC: Is 0.2 on its way, or are you testbuilding first out of paranoia?
<infinity> BenC: Ahh, there it is.
<infinity> BenC: And failed again.
<infinity> BenC: Looks like char signedness breakage (which is all over the kernel source, sadly), and a driver that builds with -Werror by default.
<infinity> Oh, or just building with -Werror=pointer-sign, which seems sane.
<infinity> I wonder why that didn't blow up on ARM.
<infinity> Maybe that driver's not built.
#ubuntu-kernel 2013-07-12
<BenC> infinity: /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory
<BenC> infinity: That's during one of the last "make silentconfig"s in the ppc build
<BenC> Some sort of passive failure?
<BenC>  /build/buildd/linux-ppc-3.10.0/scripts/gcc-version.sh: line 29: printf: #: invalid number
<disdi_> I am facing with porting  a driver from a 2.6.18 kernel to )3.8.3 kernel(Ubuntu 13.04). Apart from the APIs and functions that have changed which I have more or less replaced), the system call implementation has changed.
<disdi_> Can some body help?
<disdi_> I am facing with porting  a driver from a 2.6.18 kernel to )3.8.3 kernel(Ubuntu 13.04). Apart from the APIs and functions that have changed which I have more or less replaced), the system call implementation has changed.
<disdi_> Can some body help?
<infinity> BenC: You probably wanted gcc-multilib (or g++-multilib) instead of a direct dep on libc6-dev-ppc64, so you don't have to worry about what libs -m64 does and doesn't need.
 * smb pretends to be awake
<infinity> zequence: I assume lowlatency SRUs will be a weekend thing for you?
<xnox> ogasawara: http://pad.lv/1023645
<ubot2`> Launchpad bug 1023645 in ndiswrapper (Ubuntu Quantal) "ndiswrapper-dkms 1.57-1ubuntu1: ndiswrapper kernel module failed to build [error: âstruct kernel_statâ has no member named âcpustatâ]" [High,Triaged]
<xnox> looks like there is ppa with fixes.
<xnox> or does kernel team not have cycles for dkms modules?
<ohsix> dkms exists to make them their own entity
<ohsix> so no, and you'll find that ndiswrapper hasn't worked for a long time
<xnox> ohsix: well i did fix it up a few times. but i'm not on top off all the linux-lts kernels in precise, that's for sure.
<zequence> infinity: Yes, I will have it done before the weekend is over
<infinity> zequence: Cool.  I'll stop nagging, then.
<zequence> infinity: it's ok :). I have about a week from when the bug reports come out?
<infinity> zequence: To be on the same cadence as Canoical kernels, you have about a week, yeah.  But it's a bit simpler for you because your regression/QA bits don't take you two weeks. :P
<infinity> zequence: So, you can be late.  I'll just nag every so often.
 * henrix -> late lunch
<BenC> infinity: Ok
<apw> rtg, fyi an official fix for that ext4 bug turned up, and was the same so we are good, i have reverted and replaced on the tip of master-next but we don't have to react
<rtg> apw, ack
<apw> rtg, and am now working with utlemming on hyper-v issues we have outstanding
<rtg> apw, and I am fiddling with firmware. blech!
<rtg> apw, that isn't in Linus' repo yet, right ?
<apw> right it isn't, it is queued for the merge window, you thinking SAUCE
<rtg> no, just confirming. everything on master-next is gonna get blown away when we switch to 3.11 anyways
<apw> right
<rtg> but not for a few rc releases
<apw> it only afects fs's with 1k block sizes, ie very small ones, so its not likely hit anywhere other than our multi-lvm layout anyhow
<apw> which explains why we didn't see it
 * rtg -> lunch
 * henrix -> EOW
#ubuntu-kernel 2013-07-13
<oakwhiz> Hey guys... I found a mildly hilarious bug
<oakwhiz> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1200817
<ubot2`> Ubuntu bug 1200817 in linux (Ubuntu) "UDF filesystem shows negative disk space used in df command" [Undecided,Confirmed]
#ubuntu-kernel 2014-07-07
<apw> trippeh, if you filed a bug against udev there, i would be interested in the number so i can poke someone to deal with that
<rtg> henrix, you're picking up the patch from bug #1337516, right ?
<ubot5> bug 1337516 in linux (Ubuntu Trusty) "hpsa driver needs more Gen9 PCI ID's" [Undecided,Confirmed] https://launchpad.net/bugs/1337516
<henrix> rtg: yes, i am
<rtg> henrix, and that will definitely make 14.04.1 ?
<henrix> rtg: yep
<rtg> henrix, cool
<rtg> henrix, ok, milestoned as such
<henrix> rtg: ack
<rtg> henrix, I tagged Michael Miller for testing on that.
<henrix> rtg: cool, thanks.  i hope to have the T ready later today (need to deal with a few other things, such as merging, picking upstream fix for cve, etc)
<rtg> henrix, understood
<rtg> henrix, I'm sitting across from bjf, so am rapidly getting updated from my week away.
<henrix> rtg: heh, ok :)
<mlankhorst> henrix: so did you find out if precise is affected?
<henrix> mlankhorst: nop, didn't had the time to look at it yet
<mlankhorst> ok
<jdstrand> jjohansen, rtg_ (and ogasawara): hey-- jjohansen did a pull request for some apparmor updates a week and a half ago or so. seems you pulled it, but I don't see that the changes were pushed to the images (eg, linux-mako hasn't had an upload since april)
<arges> rtg_: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/249746
<ubot5> Ubuntu bug 249746 in linux-meta (Ubuntu) "Kernel doesn't have latencytop support" [Undecided,Fix released]
<jdstrand> rtg_ (ogasawara, jjohansen): when do you expect to do the uploads for the touch kernels?
<rtg_> jdstrand, all of the touch kernels are in the ckt PPA
<rtg_> jdstrand, https://launchpad.net/~canonical-kernel-team/+archive/ppa
<rtg_> I usually don't pocket copy those kernels until rsalveti or someone has vetted them.
<rsalveti> on my list for today
<rsalveti> will validate them all
<rtg_> rsalveti, cool, thanks.
<jdstrand> rtg_, rsalveti: ah, great. thanks!
<rtg> ogasawara, silbs is using the new setup (display port -> HDMI) which appears to have fixed her issue (so far). bjf is returning with her VGA adapter to send to kamal.
<ogasawara> rtg: awesome, thanks
<ogasawara> rtg: it may be best to ship that entire setup to mlankhorst
<rtg> ogasawara, it requires a sputnik laptop. it might actually be just a flaky adapter, though she did say it didn't start to misbehave until she installed 14.04.
<kamal> yeah, just send me the adapter -- I'll sort it out
<mlankhorst> a bisection would be useful then
#ubuntu-kernel 2014-07-08
<mlankhorst> ogasawara: I think a bisection might be useful then, morning :)
<mlankhorst> if saucy worked
<rbasak> Is there any easy way to get the kernel to no-op every fsync-type request? A command line parameter would be nice.
<rbasak> I can use eatmydata, but it's particularly awkward when for example I want to speed up what juju is doing inside a container that it created.
<apw> rbasak, i can't see anything specific in the general paths
<rbasak> OK, thanks for looking.
<apw> hallyn, what union solution are you using for containers 
<apw> henrix, there is a potential format change coming here for overlayfs which will have painful consequences
<apw> stgraber, ^^
<apw> hallyn, ^
<stgraber> apw: we support both overlayfs and aufs
<stgraber> apw: format change as in the overlay won't be stored in the same way and any existing overlays will cause chaos when mounted again?
<apw> stgraber, whiteouts won't be represented in the same way indeed
<stgraber> fun...
<stgraber> and they didn't care about backward compatibility (being able to read the old whiteouts)?
<stgraber> (note that this won't only affect LXC but also everyone using a persistent Ubuntu USB stick, which may be far more common)
<rtg> stgraber, only if they upgrade their kernel to 3.16
<stgraber> rtg: indeed. I'm not sure how many people are crazy enough to dist-upgrade one of those, so hopefully this won't be a big problem :)
<rtg> seems like a rare enough use case
<apw> stgraber, there is a conversion script (one way at least) i am not sure if that helps us any
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> didn't we cancel that ?
<hallyn> apw: ffs, they can't recognize and honor the old whiteouts whiel using the new ones?
<apw> hallyn, they don't currently; this is not a version in ubuntu yet
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - CANCELED Today 
<jsalisbury> **
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 15th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<kdeuser56> how I can fetch the kernel config for a specific kernel release?
<kdeuser56> suppose I have a variable in shell script called KERNEL_VERSION and I want that script to fetch the ubuntu config?
<apw> kdeuser56, those are included in the binary packages for a kernel, so y9ou would have to download the binary package "linux-image-*" for that version and extract the /boot/Config-* 
#ubuntu-kernel 2014-07-09
<Eisbrecher_xnox> 3.13.0-31-generic is my new favorite =)
<zequence> infinity: I'll be away between Fri-Thu, and will not be reachable, so if ou
<infinity> zequence: Before then, would you rebase your current trees for saucy (last one!) and precise?
<zequence> infinity: Yes, I did that already :)
<infinity> zequence: Oh, so you did.
<infinity> zequence: Will review and copy.  Awesome.
<infinity> zequence: If you have time to smoketest before Friday, cool.  If not, I'll catch you when you get back.
<zequence> infinity: But, the changelog? It only has the changes since last -proposed, not -updates. Is that a problem?
<zequence> Or, the diff, that is
<infinity> zequence: Yeah, I'm not concerned about the changelog being a bit goofy.  Rebase kernels are always a bit goofy anyway.
<zequence> Ok, great.
<infinity> zequence: As long as the code itself is correct, which I'm checking now.
<infinity> zequence: saucy looks good.
<infinity> zequence: And precise looks good.  You win.
<zequence> The god of faulty RAMs is not against me then
<infinity> zequence: I think that particular deity has started pestering kamal instead.
<kamal> geez, ya flip *one* bit and infinity never forgets it!  ;-)
<infinity> ;)
<infinity> zequence: Alright, copied to the kernel PPA and building.  Will get them in -proposed ASAP.  If you have time to test tomorrow, awesome.
<infinity> zequence: If we break your world while you're gone, apw and I will handle it.
<infinity> apw: FYI, zequence is out next week, so it we have another emergency respin (man, we'd better not), it's up to us.
<infinity> s/so it/so if/
<zequence> infinity: Great. I'll test them tomorrow then.
<apw> infinity, ack
#ubuntu-kernel 2014-07-10
<bjf> xnox, any progress on that "installer bug"?
<xnox> bjf: yes and no. Haven't reproduced the failure.
<xnox> bjf: and my local utah setup, no longer at all works.
<cking> xnox, has utah changed (again?)
<xnox> cking: there was stable release in june this year. and i'm assured that's what running in production, however it no longer provisions VMs in my local setup as it used to.
<xnox> cking: also
<xnox> bjf: cking: "<plars> Eisbrecher_xnox: looks like I can produce this problem on VM with latest trusty now that we have them"
<xnox> bjf: it's not utopic unique. (at least in terms of guest)
<bjf> xnox, ack
<bjf> xnox, i'm also confused by the "now that we have them" part of that statement and wonder "why didn't you have them before?"
<xnox> bjf: for some time we didn't have trusty dailies built (due to contention with precise dailies, it's first time we have .5 release) thus at first it was blocked on to moving building cds from nusakan into launchpad.
<xnox> bjf: the launchpad bit is complete, and all images are build by launchpad buildd farm now.
<bjf> xnox, ah, ok, makes sense
<xnox> bjf: however, UTAH was searching for /daily-live/trusty-desktop-amd64.iso
<xnox> bjf: whereas stable dailies are published in /trusty/daily-live/trusty-desktop-amd64.iso
<xnox> bjf: top-level /daily-live/ is for devel series only, that is utopic now. And hence utah didn't pick up the new images when they started to be generated.
<xnox> bjf: (well there is an extra subdir for image build number & current)
<bjf> xnox, what do you need at this point to make progress? do you need help from plars and nuclearbob for the utah side?
<xnox> bjf: i don't know if nuclearbob works on utah. I've been directed at ev, psivaa, plars, doanac.
<xnox> bjf: in the mean time, I am investigating how to provision and run tests without UTAH in between.
<bjf> xnox, if you would like utah help, i'm happy to go have a chat with evan
<xnox> bjf: e.g. using a simple pxeboot provisioning and test provision/collection. Which should work with VMs and bare-metal alike.
<xnox> bjf: i don't care much about utah. The hard-pressing thing is that: (a) bootspeed tests are not executed (b) power tests are not executed (c) utopic desktop daily tests has not run since 20th of May (thus not migrated from pending -> current)
<cking> xnox, the weakness does seem to be at the utah side of things
<bjf> xnox, i agree with you. i would hope that you could repro the issue outside of utah but if you can't we should get them involved
<bjf> xnox, is there any additional information they can provide to you which would help debug this? if they provided you with access to a system in this particular state?
<xnox> bjf: access to utah server, from which i can trigger utah provisioning runs would be useful, yes. Since my local utah setup is non-operation (as in it doesn't get as far as ci.ubuntu.com utah runs get to)
<xnox> bjf: and it's not like current utah production server does anything useful =) given all tests timeout and don't run.
<xnox> it's interesting that trusty 14.04.0 test run today, shows the in-ability to unmount /target ( https://jenkins.qa.ubuntu.com/job/trusty-desktop-amd64-smoke-default/163/artifact/log/utah-24420-install.log/*view*/ )
<xnox> based on artifacts there, i believe the machine did install and reboot was requested.
<xnox> but the target machine never showed up with working ssh server open.
<xnox> https://jenkins.qa.ubuntu.com/job/trusty-desktop-amd64-smoke-default/163/artifact/log/utah-server-ssh.log/*view*/
<psivaa> xnox: just going through the backlog.. re: 'current utah production server does anything useful =) given all tests timeout' we have server iso installations running ok 
<psivaa> xnox: the issue we are facing is only pertainning to desktop iso's
<psivaa> xnox: the issue only started when we upgraded the production servers from precise-> trusty
<bjf> psivaa, that's a completely different story than we have been getting
<bjf> psivaa, we've been told that the problem is with the installer when installing on the test system
<bjf> psivaa, it sounds like you are saying that after you updated your infrastructure it started failing
<psivaa> bjf: well as you know the 'failing' has been for quite a long time and there was one or two installer issues two in between
<psivaa> bjf: when i checked last time, it wasn't alone the installer thats at fault.
<psivaa> bjf: and that was a couple of weeks ago 
<bjf> psivaa, how do we all come together on this and get the tests running again?
<psivaa> bjf: manual installation went fine. and i tried a preseeded installation too and that worked too, outside of utah
<bjf> psivaa, so how did the finger get pointed at the installer?
<psivaa> bjf: as i said there were installer bugs too in between even with manual installation. but i *think that got fixed now
<psivaa> (the finger pointed earlier might not have folded :))
<bjf> psivaa, so what is the current issue(s) that need to be addressed to get the tests running again?
<psivaa> bjf: the current issue was (when i checked about a week and half ago) that utah installation of desktop goes on a loop on trusty production servers and instead of  rebooting to login screen after the install, it starts the installation again. 
<bjf> psivaa, and where do you believe that issue exists? is it utah?
<psivaa> bjf: i'd start from utah for a fix. but not ruling out any changes in the installer side that could make utah server to think that the installation is complete
<psivaa> s/complete/not complete/
<bjf> psivaa, ok, lets start with utah. who works on utah these days?
<psivaa> bjf: so I think utah is now basically in  maintenance mode awaiting deprecating, in light of the ci-airline development. doanac, plars and myself in our team do the fixes as we see fit. 
<psivaa> this appear to be a complicated issue and there fore outside my capability
 * cking wonders how many infrastructure development iterations are required to get something working for at least 2 cycles w/o breaking
<apw> psivaa, i thought we used the same framework for the SRU validation, is this going to cause issues qualifying .5 ?
<psivaa> apw: for kernel SRU, we dont use utah. for precise iso testing we dont use utah either. so should not affect precise .5. Not sure if anyone is using it for SRU validation of the other packages
<jdstrand> rsalveti (and rtg): did the apparmor signal/ptraces patches make it into phone images yet?
<rsalveti> jdstrand: yes
<jdstrand> rsalveti: I was looking at https://launchpad.net/ubuntu/utopic/+source/linux-mako, but didn't see it in the changelog. is that expected?
<jdstrand> oh, I see it in 3.4.0-5.30
<jdstrand> rsalveti: nm, thanks!
<jdstrand> it got hidden due to the ftbfs entry
<jdstrand> rsalveti: thanks for that testing btw :)
<rsalveti> jdstrand: np!
<awe_> sforshee, could you or someone on your team take a look at: https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753
<ubot5> Ubuntu bug 1337753 in wpa (Ubuntu) "[mako] can not create an ad-hoc network" [Medium,Incomplete]
<xevious> This isn't a kernel development question, but regarding internal kernel operations: when would it be necessary to manually use the sync command line utility? Shouldn't any pending writes be flushed when I run `losetup -d /dev/loopX` or `dmsetup remove exampledevice`? What types of operations could a user perform that the kernel wouldn't automatically sync? Can you provide examples of when I would need to run the sync command?
#ubuntu-kernel 2014-07-11
<apw> xevious, in normal operation no you should not need to add addition sync commands
<agm> henrix, I used your -proposed kernel
<agm> it seems to fix the nfs issue
<agm> how do I appropriately report my success?
<henrix> agm: is there a 'verification-needed-trusty' tag in that bug?
<agm> yes
<agm> I mean, do I just say it seemed to work and tag it
<agm> or is more information required
<henrix> agm: then, just replace that tag by 'verification-done-trusty' :)
<agm> Ok, I just made my launchpad.net account today
<agm> thanks
<henrix> agm: of course you can add more relevant info to the bug, that could eventually help other people testing
<agm> ok, I'll describe my setup
<henrix> agm: and thanks for testing and reporting back!
<agm> thanks for fixing it! I just saw the issue last night, googled what I was seeing, saw the bug, and saw your fix
<agm> fast!
<henrix> yeah, sometimes that approach works :)
<xnox> my processes tell me that they no longer can initialise inotify
<xnox> did i run out of watches/discriptors, or i have something rougue running on my system, or is kernel buggy? or how do i check that?
<agm> Do I add a tag just by appending that text to the bottom of a post?
<agm> oh nevermind found it
<xevious> apw: Can you think of an operation that would require manually running sync?
<apw> xevious, a full sync, no
<awe_> sforshee, ogasawara, can someone on the kernel team take a look at a WiFi adhoc driver bug for us?
<awe_> https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753
<ubot5> Ubuntu bug 1337753 in wpa (Ubuntu) "[mako] can not create an ad-hoc network" [Medium,Incomplete]
<sforshee> awe_: ugh, if android doesn't use ibss then there's a good chance that it isn't well-tested in the driver
<awe_> yup 
<sforshee> I'll try to take a peek at the code a little later today, but that driver makes my eyes bleed
<awe_> sforshee, same problems with bq; although different driver
<awe_> sforshee, this may be endemic of Android Wi-Fi drivers
<awe_> that said, Wellark also claims that bq doesn't have "ap" support either
<awe_> ( which is what I think we should be using for hotspot )
<awe_> sforshee, one last comment... in the syslog, I see reference to a qcom platform drive that NM thinks is the WiFi driver;  it's not clear to me if the actual N4 WiFi driver is a blob or not...
<sforshee> awe_: yeah, if android doesn't require ibss support then we probably need to assume that we can't rely on it when we're using those drivers
<sforshee> awe_: I don't think the n4 wifi driver is a binary blob, but I'll double check
<awe_> sforshee, well...the driver claims support, and without, we're missing the underlying framework to support hotspots
<sforshee> awe_: but if android is using ap mode then that's the code that we know is tested and _should_ work, so why wouldn't we use that for hotspots instead?
<awe_> so...we have existing code in Ubuntu to support hotspot, and it's tied to adhoc unfortunately.  I document why this isn't optimal in: https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753
<ubot5> Ubuntu bug 1337753 in wpa (Ubuntu) "[mako] can not create an ad-hoc network" [Medium,Incomplete]
<awe_> sorry...https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753/comments/5
<sforshee> awe_: okay ... so it's easier to go fix every android driver which has sub-par ibss support than to change our hotspot code?
<sforshee> and based on that comment, there are other compelling reasons to use infrastructure mode rather than ibss
<awe_> I haven't yet had this discussion with others
<awe_> NM apparently does support AP-mode hotspot, but the discussion hasn't been had yet
<sforshee> awe_: so as far as I can tell the options are a) continue with adhoc, create a lot of extra work, and have an overall crappy hotspot experience, or b) switch to infrastructure mode for hotspots and have fewer driver problems and a better user experience
<sforshee> the answer seems pretty obvious to me
<awe_> sforshee, also not all of the drivers we're interested in support ap mode
<awe_> sforshee, it depends on how much code is involved
<sforshee> awe_: then these same devices don't support hotspots under android I assume?
<awe_> in theory, that's correct
<sforshee> what about in practice?
<awe_> ;)
<sforshee> because if android doesn't support hotspots on those devices it seems unreasonable to demand that we should
<awe_> agreed
<awe_> sforshee, just asked abeato for the 'iw list' output for krillin
<sforshee> awe_: so honestly I don't feel inclined to invest much effort at all in tring to fix adhoc on the n4 if it seems likely we'll just switch to ap mode anyway
<sforshee> and to me that seems like the far more reasonable solution, all things considered
<awe_> sforshee, we can't make a decision till we've looked at all the pieces...  I'd like at least some opinion from you or someone from the kernel team as to why fixing the driver is too much effort
<awe_> it might be something obvious like building the driver with p2p support might conflict with adhoc mode
<sforshee> awe_: okay, I'll take a look this afternoon
<awe_> I *will* have the conversation re: adhoc mode today
<awe_> thanks
<awe_> don't spend a lot of time on it
<sforshee> I don't plan to ;-)
<awe_> cool
<awe_> thanks much!
<kdeuser56> how would I get the ubuntu kernel config file for a specific version from commandline?
<infinity> kdeuser56: If you mean for the installed/running kernel, it's /boot/config-$(uname -r)
<kdeuser56> infinity: not an installed one
<kdeuser56> infinity: I was looking for the .config of any kernel ubuntu ever played with
<kdeuser56> infinity: is there some archive?
<infinity> I don't think anyone's bothered to extract the configs from every binary package and archive them, no.
<infinity> But if you know which binary package you're interested in, you can download and unpack it.
<infinity> Our git trees show the changes on a more granular level, but there's no .config in there, as it's broken into pieces and constructed at build time.
<BLZbubba> hi guys, I'm trying to build 3.15.4 using "fakeroot debian/rules binary-headers binary-generic" and it builds just fine
<BLZbubba> however, the deb only inculdes about 600 modules whereas the binary on kernel.ubuntu.com has over 3000
<BLZbubba> i started looking at the generic inclusion list but it seems to match the one on the standard 3.13 kernel.  any idea where to look to make it include the correct set of modules in the kernel binary deb?
<Sarvatt> BLZbubba: look in the linux-image-extra deb, if you want to build it all into one deb you'd want to fakeroot debian/rules do_extras_package=0 binary-headers binary-generic
<trippeh> also might want to consider 3.15.5
<BLZbubba> but there is no extras deb here: kernel.ubuntu.com/~kernel-ppa/mainline/v3.15.4-utopic/
<BLZbubba> i'm just curious how to build the packages exactly the same way as these
<BLZbubba> Sarvatt: you're right, extras had the missing ko files for useful things like the keyboard
<BLZbubba> so how are they doing it differently for the images published to kernel.ubuntu.com?
#ubuntu-kernel 2014-07-12
<wyatt_earp> greets, i'm looking to see where i can recommend a patch to the kernel
<wyatt_earp> part of the patch was implemented in the 14.04 3.16.0-3.8 release, but it's still missing some items and affects at least one more bug
<wyatt_earp> also, launchpat.net seems to be choking hard on the trying to report an error in the "linux" package because it matches so many things
#ubuntu-kernel 2014-07-13
<wyatt_earp> so ... anyone feel like adding a 1 line change the kernel? it'll be cool, i swear :)
<wyatt_earp> alright ... well, hopefully reporting the bug to the "linux" package will get it fixed ... since i can't seem to find a package for ideapad_laptop
<hallyn> stgraber: apw: filed bug 1341364.  100% reproducible with the testcase in description.  
<ubot5> bug 1341364 in linux (Ubuntu) "cgroupfs rmdir race (regression)" [Undecided,New] https://launchpad.net/bugs/1341364
<hallyn> stgraber: trying to decide whether to make cgmanager sleep(1) and retry if it gets -EBUSY... but i'd rather not work around buggy kernel in the daemon, so will probably just disable the testcase for 3.16 kernels
#ubuntu-kernel 2015-07-07
<bjf> stgraber, have you had a chance to run the lxc tests on the 4.0 kernel in -proposed?
<dannf> kamal: fyi, this might be stuck in moderation - but since i see you're adding patches to 3.13.y atm: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471892/comments/4
<ubot5> Launchpad bug 1471892 in linux (Ubuntu) "[arm64] Kernel panic while running coreutils testsuite" [High,In progress]
<kamal> dannf, thanks for the heads up there!  I'll look at that immediately
<dannf> kamal: let me send you the e-mail so you don't have to scrape...
<kamal> dannf, thanks for that too
<dannf> kamal: sent
<kamal> dannf, ok, so that was clearly my bad -- thanks for fixing it!  I'm queuing it up for 3.13-stable right now.  you'll submit the patch as trusty SRU request also, yes?
<dannf> kamal: i can, sure - wasn't sure if that was needed or if it would just go in via a 3.13.x release
<kamal> dannf, well, yes, it will make it into trusty in due course, but since it's invokes a panic we should SRU it to ensure that it lands in trusty ASAP
<dannf> kamal: ack, will do. thanks kamal !
<kamal> dannf, thank *you*!
<infinity> dannf: Ahh, nice catch.  Thanks.
<infinity> bjf: What are the odds of my being able to get that in the current SRU cycle? :/
<infinity> bjf: Being unable to build coreutils is a bit embarrassing.
<dannf> well, local DoS.. maybe through security if not through SRU?
<bjf> dannf, same diff for the kernel
<infinity> Except for urgency, of course, and I feel no urge to special-case this.
<dannf> *nod8
<bjf> dannf, just for trusty?
<dannf> bjf: yeah
<bjf> it's tue. and we've only had to respin one so far ... why not make it another
<bjf> infinity, we'll fit you in
<bjf> kamal, dannf, can i get an sru patch request for it sent to the ML please?
<dannf> bjf: already did
<infinity> bjf: My hero.
<infinity> bjf: This current cycle already has another critical fix for my arm64 buildds, so as soon as it's built and in proposed, I'll upgrade them all and hammer them for verification.
<bjf> dannf, ok, don't see it yet ... google must be looking at it
<infinity> dannf: Thanks for the turnaround on that.  I owe you.  Perhaps that pending grub2-signed merge of yours will be on my TODO tonight.
<dannf> hey, if i get a get out of jail free card for that, i'll save it for something else ;)
<infinity> Hah.
<dannf> bjf: forwarded you a copy
#ubuntu-kernel 2015-07-08
<bjf> kamal, i'm including an ACK for you on that patch
<kamal> bjf, yes please
<bjf> dannf, i'm going to adjust the commit subject just a little (drop the [3-13-stable only])
<dannf> bjf: oh, sure
<kamal> bjf, fyi here's the version I applied to 3.13-stable http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linux-3.13.y-queue&id=eef5d05f530ba16df8f758f6ae72f62e4ac7a503
<bjf> infinity, dannf trusty uploaded
<awe> cking, around?
<cking> awe, just about
<awe> so I just had a recent utopic kernel update land on my macair, and it nuked by rEFInd install...
<awe> thankfully I was able to boot, by powering on with the Option key pressed
<awe> this is the first time I've ever had an Ubuntu update nuke it
<awe> ( it's usually the other way around )
<awe> just wondering who I should bug about this?
<awe> ( no pun intended )
<awe> I'm also gonna shoot an email to rodsmith
<awe> ( rEFInd maintainer )
<cking> awe, yeah, I've got zero know-how with rEFInd
<awe> I thought you wuz the EFI king?
<awe> ;)
<awe> np
<awe> maybe I'll see what rod has to say, then come back and ask for more help
<cking> awe, I try to keep away from macs
<awe> why, cause you love where lennovo is these days?
<awe> ;/
<cking> awe, heh, I'm more into file system and ACPI at the moment
<awe> I try and stay away from dell ( for obvious reasons )
<awe> ( mostly personal )
<rtg> awe, I think there was a mishap with a grub update this morning. perhaps cjwatson could elaborate.
<awe> ah...
<awe> that sounds like a smoking gun for sure
<rtg> rbasak noticed it
<awe> thanks rtg
<rtg> awe, if you do another update then you ought to get another grub package (if that was indeed your problem)
<awe> ok
<rbasak> awe: thank you for the report. Please let us know if this did fix your issue. I wasn't sure how many people were affected, but if it's been picked up this quickly perhaps we should adjust SRU processes to make sure it can't happen again.
<rbasak> (since at the moment it depends on SRU team members knowing about it)
<awe> trying now...
<awe> be right back ( hopefully )
<awe> rbasak, so I updated grub to 0.97-29ubuntu66; rebooted and rEFInd still doesn't load.... I need to power up with the Option key pressed in order to trigger EFI Boot
<apw> awe, that doesn't sounds like a kernel issue though, hmmm
<awe> apw, rtg mentioned earlier that there was a grub mishap this morning, and rbasak had asked it that cleared it up
<awe> apw, totally agree it's not a kernel issue
<awe> just originally thought it might be related
<rbasak> awe: thanks. I'm not particularly familiar with the signed grub stuff, just that I know that they need to be updated in lockstep.
<awe> np
<rbasak> Are we absolutely sure that your failure isn't a consequence of the failure this morning?
<awe> no idea
<awe> I applied an update, and didn't pay too much attention to the involved packages, other than there was kernel update included.  Things failed on the reboot
<rbasak> smb: you're probably gone for the day but maybe you can look into this with awe in the morning please? My concern is that we released grub2 to -updates this morning without doing grub2-signed, until cjwatson fixed it later on after I noticed. I'm wondering what impact this might be having on users.
<smb> rbasak, I am still here... well if you are not careful apt-get dist-upgrade will put the signed part on the "will be removed" list
<rbasak> smb: ah, so so awe, do you have the package grub-efi-amd64-signed installed still? Or is it removed?
<smb> update-manager warns about partial upgrade but command line is quite easy to miss
<awe> nope
<awe> and there was no error from update-manager
<rbasak> Nope you have it installed still, or nope it's not there? :)
<awe> nope it's not there
<rbasak> Ah, that'll be it. Please install it.
<awe> k
<rbasak> Hopefully that'll resolve the problem.
<awe> so before I pull the trigger, it says it'll install: grub-efi-amd64 grub-efi-amd64-signed grub2-common
<awe> and remove: grub
<awe> is that correct?
<rbasak> Hmm
<rbasak> I'm not sure.
<rbasak> So please don't do it on my account. We're right on the edge of my knowledge, sorry.
<awe> np
<smb> at least that seems to be missing on my side
<smb> grub-common, grub-efi-amd64, grub-efi-amd64-bin, grub-efi-amd64-signed, and grub2-common is what is installed here
<awe> k
<rbasak> awe: if you look at /var/log/apt/history.log, can you see what was removed this morning?
<awe> smb, when someone earlier mentioned a mishap with grub
<awe> I ran an apt-get install grub
<awe> thinking I was updating something
<awe> I'll go ahead an apply this
<rbasak> awe: you should be able to check history.log and figure out exactly what you need to undo from there.
<awe> k
<rbasak> You basically want the same set of packages installed that you had yesterday ;)
<awe> and where do I find history.log?
<smb> awe, ok, yeah. might be even grub is grub 1
<rbasak> /var/log/apt/history.log
<smb> at least grub-efi-amd64 seems to conflict by purpose with grub
<smb> hm now... but anyway... I think its ok
<smb> now/no
<smb> Oh bah. yes it is. To much text on my terminal for the hour. So grub is grub 0.97...
<awe> yea, I think I'll be OK after this.  lemme try again
<rbasak> I need to go.
<awe> thanks for your help rbasak!
<rbasak> awe: np, sorry for the issues.
<smb> awe being back might be a good sign
<awe> nah
<awe> I think I might need to 're-bless' rEFInd from OS X
<awe> I'll try and follow up with rodsmith
<awe> I can boot w/the Option key pressed... and that allows me to start the EFI Boot
<smb> Ok, unfortunately I would not be of much help with anything that says Mac on it
<awe> np
<awe> but something definitely broke, so it'd be nice to find out what, so we can prevent in the future
<awe> ( or at least understand it )
<smb> Yeah, as far as I got it its the signed versions problem (independent package but version depending). So need more care when uploading. 
<smb> Otherwise it requires paying close attention on what the upgrade dialogue tells you
#ubuntu-kernel 2015-07-09
<Odd_Bloke> bjf: Heads up: argyle is running in PS4 at the moment, and we've been asked to move it to PS4.5 by the end of the week.
<Laney> did aufs go away in our 4.0?
<Laney> my schroots broke :(
<Odd_Bloke> bjf: apw: Oh, it's not by the end of the week, it's by July 15 (next Wednesday).
<Odd_Bloke> bjf: apw: I've redeployed the service, and opened RT #82789 to open up the same firewall holes as we have for the PS4 deployment.
<infinity> Laney: Erk, it sure did...
<infinity> apw: Where'd aufs go?
<infinity> Laney: You can s/aufs/overlay/ for now (or downgrade).
<Laney> infinity: Ya, done that, thanks.
<apw> infinity, it was meant to be there, i am sure tim updated it
<infinity> apw: I'm sure modinfo tells me I don't have it.
<infinity> Althought, CONFIG_AUFS_FS=m ...
<infinity> Wha?
<apw> infinity, yeah its disabled in the makefile, seems to build just fine, so i am proposing to do a non-abi bumper with it enabled
<infinity> apw: If it works, that seems reasonable.
<bjf> Odd_Bloke, so our "cloud provider" has asked us to move to a new cloud but it's up to us to do that? and i suppose any/all firewall exceptions are also up to us to tell them about?
<rbasak> awe: do you mind posting your /var/log/apt/history.log somewhere from yesterday's grub2 incident? I'd like to see what exactly did what when your system originally broke to understand the issue better.
<awe> rbasak, in a mtg, and just about to join a standup; I'll ping you when I free up
<rbasak> OK, thanks.
<Odd_Bloke> bjf: Something like that, yes.
<Odd_Bloke> bjf: But they have at least been fairly responsive; new rabbitmq is at 162.213.33.247 and the firewall holes should have been punched.
<Odd_Bloke> (In their defense, all I had to do was say "copy the PS4 firewall rules", so hopefully they should all be correct)
<bjf> Odd_Bloke, since we access it via ip addr, it will require code changes
<Odd_Bloke> bjf: Yeah. :(
<bjf> Odd_Bloke, from what you are telling me. the new one is in place and i should be able to switch over right now if i wanted ... correct?
<Odd_Bloke> bjf: That's my understanding; but check first?
<bjf> Odd_Bloke, ok ... i'll do a little checking and if it goes well, make the switch
<bjf> apw, ^^^^ i'll do some testing to make sure the msgq service is working for the systems we want it 
<apw> bjf, sounds good, as i will need to shock-and-awe on the dashboard
<awe> did someone say my name?  ;)-
<apw> :)
<apw> infinity, ok just enablnig aufs seems to work just fine, soooo ... i'll get that uploaded
<apw> ogasawara, seems we are missing aufs in the kernel we just did, so i am proposing to do a non-abi bumper for it
<awe> rbasak, http://pastebin.ubuntu.com/11848708/
<ogasawara> apw: ack
<infinity> apw: Works for me.
<infinity> apw: I can never decide from minute to minute if my schroots should be overlay, aufs, or lvm, but hey, it's nice to be spoiled for choice.
<infinity> apw: (I still wish overlay could paper over the one or two things that make me keep turning to aufs...)
<rtg> apw, the 4.0 Wily upload is missing AUFS ?
<infinity> rtg: Yep.
<infinity> rtg: It's in the config, but apparently disabled in the Makefile.
<infinity> (oops)
<rtg> infinity, oh, damn
<rtg> sure is
<rtg> better check the 4.1 branch
<rtg> looks like that one is OK
<rbasak> awe: thanks!
<infinity> rtg: Misplaced your cowboy hat in between versions?
<awe> np
<infinity> rbasak: So, that totally has apt-get being the culprit, not update-manager.  We can stop panicking.
<infinity> rbasak: As in, *someone* got impatient that grub wasn't upgrading and ran "apt-get install grub" and said "sure, remove everything" when it prompted.
<infinity> In fact, wait.  That's grub1, even.
<infinity> awe: So, that was totally self-inflicted.
<infinity> awe: Your manual installation of grub1 removed grub2, and you said "yes".
<rbasak> infinity: AIUI, awe had a problem after the update, and he tried to fix it by installing grub
<rbasak> infinity: but yes, the problem wasn't cause because the grub2 signed package got removed. Must have been caused by some other thing.
<infinity> rbasak: Well, there are no removals until that point.
<rbasak> Right
<awe> infinity, I only did the manual install of grub *after* my system stopped rebooting correctly
<awe> and yes, it was a mistake
<awe> but didn't really worsen or improve anything
<infinity> awe: Check.  What are/were the symptoms of "not booting correctly"?
<apw> rtg, yes, you ripped aufs out and switch the way it was updated for v4.1
<awe> I'm dual-booting a macair osx + utopic
<awe> after yesterday morning's update
<rtg> apw, right, I'm using the upstream mechanism
<awe> my machine no longer booted into rEFInd
<awe> I got a "Your screwed screen"
<awe> ( ie. do you wanna re-install OS X from TimeMachine backup, fresh install, go online for help, or bring up disk tools )
<apw> rtg, indeed, i mean that is why the disablement didn't get carried over, one was against ubuntu/Makefile, the other against fs/Makefile
<rtg> apw, yup
<awe> so now on restart, I need to do an Option+Pwr boot, and then select EFI boot
<awe> the other options being the two OSX recovery partions
<infinity> awe: Curious.  I don't know much of anything about rEFInd, but since rbasak's been trying to be helpful, I'll let him keep at it. :P
 * awe heads to yet another mtg
<awe> thanks infinity
<rbasak> Well, I'm not sure any more :-/
<rbasak> Not sure how much more helpful I can be. I was concerned yesterday that there might be a grub2-signed breakage problem, and so when awe's problem appeared, was concerned that it was that.
<rbasak> But it wasn't, so perhaps my concern isn't as big of an issue (that's the trouble with a sample size of 1). But that doesn't help at all with awe's actual problem, of which I have no idea.
<arges> rodsmith: hey, awe had some issues with rEFInd. Maybe you can help?
<rodsmith> Hi. I'm told somebody has a rEFInd question. I'm the current maintainer. What's the question?
<rtg> apw, there are significant changes to overlayfs in 4.2; perhaps you could add to your TODO list to forward port "UBUNTU: SAUCE: overlay: add backwards compatible overlayfs format support V3"
<apw> rtg, ack
<rtg> apw, in unstable master
<apw> master or master-next ?
<awe> rodsmith, rbasak, I just joined a planning meeting; short version... I updated yesterday, and my macair no longer boots into rEFInd
<rtg> apw, I think I'm gonna drop unstable master-next 'cause it really isn't very useful. what do you think ?
<awe> now, I have to do an 'Option' + Pwr, and select "EFI Boot" every time
<awe> not sure if I re-bless from OS X would fix this?
<awe> This is the first time an Ubuntu update has broken things for me
<rodsmith> awe: Can you get into both OS X and Ubuntu via the Option key?
<awe> I get to rEFInd via the option key, and have only booted Ubuntu from there since
<awe> haven't checked OSX
<rodsmith> awe: If you can get into OS X, try re-installing rEFInd.
<awe> without the option key
<awe> I get a "Do you want to re-install or fix things" screen
<rodsmith> awe: The Ubuntu update probably tried to install/re-install GRUB, which messed things up.
<awe> right
<awe> I'll try a re-install from OS X and see if that fixes things
<rodsmith> awe: The "re-install or fix things" prompt sounds like APT didn't quite set everything up right.
<awe> right
<awe> thanks
<rtg> manjo, smb: I see that dm-raid45 hasn't been updated since April 2009. We are carrying it as a SAUCE driver. Do you think it is still relevant ?
<manjo> rtg, wow... I will need to look coz I am not sure who is using that 
<smb> rtg, depedns on how many people use a non-Intel fakeraid in bios mode... 
<smb> Intel MSM and DDS should be handled by mdadm nowadays
<smb> rtg, Sure we will notice (after release) when you rip it out for now
<rtg> smb, well, I haven't ripped it out yet. I'm just reviewing SAUCE patches
<manjo> smb, wasint there an issue where softraid was not write able ? 
<manjo> smb, May be that issue with mdadm is already fixed 
<smb> manjo, at some point long time ago. but afaict Trusty works without dmraid
<manjo> rtg, will that impact backport kernels for lts ? 
<rtg> manjo, yup
<manjo> ugh
<rtg> maybe it should wait until after 16.04 to be removed
<manjo> when does precise sunset? /me does the math
<manjo> 12.04 .. so 17.04? 
<rtg> yup
<manjo> s**t 
<smb> rtg, Might be that is what we said before T... But with a crisp memory like mine and we should have written it down... but then maybe we did and I just forgot where
<rtg> smb, its no big deal. so far maintenance has been easy, but I wanted to be sure the driver actually still worked
<TJ-> rtg: If it's any help I can do some tests with a Promise controller; which kernel/ubuntu release would you want testing?
<smb> rtg, I doubt I ever tested the other module ever again after mdadm worked for Intel... and none of my other hw would have fakeraid beyond levels 1
<manjo> rtg, also people using vmware stuff might still need that module on precise 
<rtg> ok, I'll defer removing the driver
<apw> rtg, we if we are removing it in 16.04 we should disable it in the main build and re-enable it in the lts-backport
<rtg> apw, I was thinking _after_ 16.04
<apw> then you might need to support it in the backports up to and including 18.04 in 16.04 even if it is disabled in those releases
<apw> because it _is_ enabled in 16.04
<rtg> apw, 16.04 is the last backport for 14.04. perhaps we should only enable dm-raid45 in the backport and not in 16.04 proper
<apw> rtg, that was my suggestion indeed
<infinity> rtg: I concur with apw (and you).  If you intend to drop drivers, do so in 16.04, but add them back to the lts-x kernel.
<rtg> infinity, now I just gotta remember to do it
<infinity> rtg: Though, you could also drop them in wily and add them back to the lts-w kernel too.
<infinity> rtg: Which gives people some time to get used to the idea.
<rtg> yup
<infinity> rtg: Makes an argument for maintaining lts-w starting around, oh, now, though.  So you don't end up with 73 post-its detailing "stuff that needs to happen on top of the backport". :)
<rtg> thats just too logical
<unixabg> Greetings, does the 15.04 kernel have multi-layer overlayfs support? (multi-layer meaning more than 2)
<apw> unixabg, that is a feature of later kernels, so wily may have it iwth the very latest kernels
<unixabg> apw: humble appreciation for response.
<apw> unixabg, i don't think 3.19 had it, but i am not 100% sure
<unixabg> apw: would you know what version would have such support?
<unixabg> I ask since I am wanting to test it some and I need partial .squashfs files for service packs.
<apw> unixabg, looks like v4.0 was the first upstream release with it in
<apw> so only wily very latest kernel would have it
<unixabg> apw: thank you and I will work on testing with that then.
<unixabg> apw: what is the shortest route to install and test the 4.x kernel?
<apw> well other than running wily, you could install that kernel from the archive by hand
<unixabg> apw: thank you for the assistance I will download from http://cdimage.ubuntu.com/daily-live/current/
<dsd> hi, i read that Ubuntu Wily might be based on Linux 4.1. is there a Ubuntu kernel git tree for that already?
<rtg> dsd, ultimately Wily will release with 4.2
<dsd> i see
<dsd> and have you started the process of moving the patches from 3.19 to a newer kernel like that?
<dsd> or is that going to happen a bit later
<rtg> dsd, All 4.1 work is happening here until 4.2 is released: git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily master-next
<dsd> thanks!
<unixabg> apw: have you worked on casper? I ask since I see an apw there on a commit message.
<apw> unixabg, only in a very peripheral way, but the last upload was in my name in trusty yes
<SturmFlut> Good midnight! Anybody still awake?
#ubuntu-kernel 2015-07-10
<apw> SturmFlut, i am sure someone was somewhere in the world
<sturmflut> Haha
<sturmflut> I've debugged most of the problem and filed a bug report in the meantime, looks like the original problem is in ModemManager, but might affect the kernel as well in the end.
<ogra_> sturmflut, but not a kernel anyone in here maintains :) 
<sturmflut> ogra_: Shouldn't the cdc_acm module of my desktop kernel blacklist that specific USB ID, because it will never work anyways and just confuse the russians?
<ogra_> dont underestimate the cleverness of the russians :) 
<ogra_> and i'm not sure its a kernel thing ... did you check that modemmanager doesnt ship udev rules that cause the loading ? 
<sturmflut> Hmm, now how does this udev stuff work with systemd...
<ogra_> heh, te same as with other init systems :) 
<ogra_> (i dont think systemd comes into play here ... but i guess modemmanager ships udev rules that react to uevents related to serial) 
<sturmflut> ModemManager ships some rules, not to load the module for this device, but to tell itself to blacklist a lot of similar cases. So the simple solution would be to at least add the device there, then cdc_acm gets still loaded and fails, but ModemManager does no longer claim the device.
<sturmflut> Not pretty, but I can live with that.
<rtg> apw, ogasawara_ upstream discussion on CONFIG_VM86 http://thread.gmane.org/gmane.linux.kernel/1991020
<rtg> kees suggests we turn it off
<apw> rtg, yeah someone claims we have it off already, but it looks to be on to me
<rtg> yup, their claim was erroneous
<apw> rtg, it sounds like a security disaster in the making, so ripping it in wily and seeing if anything explodes seems good
<ogasawara_> rtg: ack, do you already have a patch to push to wily to turn it off?
<rtg> ogasawara_, I was just disabling it in unstable
<rtg> ogasawara_, I can do wily master-next as well
<ogasawara_> rtg: ack
<infinity> Didn't we just turn that on in an SRU a few months back or something?
<infinity> It seems awfully familiar.
<infinity> Maybe I'm thinking of something else with a similar-sounding name.
<rtg> infinity, not finding any CONFIG_VM86 changes in trusty
<infinity> rtg: Ahh, yeah, I was thinking of CONFIG_X86_16BIT, nevermind.
<infinity> So, VM86 seems scary and evil as all hell, I'm inclined to agree, but we need to make sure we don't need it for any old skool X drivers (vmware, vbox, etc)
<infinity> Oh, but if it doesn't even work on x86_64, my carefactor just went down.
 * infinity catches up on the rest of the thread.
<rtg> infinity, it was 32 bit only in our configs
<infinity> rtg: Yeah.  I'd be inclined to say we should disable it across all stable kernels too, then, as a pre-emptive security feature.
<infinity> rtg: If no one was hunting for holes in it before, you can bet that thread will make grey hats start looking.
<infinity> rtg: There are one or two X drivers that are i386-only.  If we can verify that they don't need VM86, I'd say the impact is minimal-to-none and worth the risk.
<rtg> infinity, agreed, though the attack surface is much smaller given that it is only applicable to 32 bit machines. 
<rtg> infinity, I'll run this by jjohansen and tyhicks as well
<rtg> perhaps 32 bit cloud VMs are vulnerable
<infinity> rtg: 32-bit still has an astoundingly large install base.
<infinity> rtg: And certainly true going back to precise, where it was still our recommended image download.
<rtg> yeah, I'd be willing to bet there are a lot of 32 bit instances in the cloud
<infinity> rtg: Probably fewer than there should be (ie: I'd argue that most "tiny" and "small" instances should be i386, even if backed by amd64 hardware), but yeah, there are certainly some.
<rtg> infinity, working on an SRU
<infinity> rtg: I think we need a userspace impact analysis before we SRU it, but my hope is the impact is "none".
<infinity> rtg: My only concern is ancient X drivers that haven't seen significant work in the last decade, and I think we only ship a couple of those.
<rtg> infinity, it seems our choice is to orphan some vanishingly rare drivers, or expose possible vulnerabilities to every 32 bit user.
<rtg> orphan -> regress
<infinity> rtg: Hrm.  And vbetool.  That might need a looking at as well.
<rtg> I'll make that part of the SRU discussion
<infinity> rtg: But yes, we're on the same page.  I think the goal should be disabling VM86, we should just sort out the impact and see if we can minimize damage.
<infinity> rtg: http://codesearch.debian.net/results/sys%2Fvm86.h
<infinity> rtg: and http://codesearch.debian.net/results/asm%2Fvm86.h
<infinity> rtg: Some might be false positives that we don't enable, others are probably build-time detected and would be broken if we regress the kernel support.
<rtg> infinity, I guess Linus will howl if Lutomirski starts breaking user space
<infinity> rtg: Well, it's never been a required kernel option, so it doesn't break userspace to disable it by default, by Linus's definition of break.
<infinity> rtg: But distributions need to be aware of impact on already-shipped software if they disable features they used to enable.  That's where it gets sticky.
<rtg> infinity, is userspace supposed to fall back into an emulation mode ?
<infinity> rtg: I'd have to look at the glibc syscall wrapper.  It's possible that people using the abstracted sys/vm86.h are safe.
<infinity> rtg: People using asm/vm86.h directly, though, are definitely broken if they don't have their own fallbacks in place.
<infinity> rtg: I highly doubt we have an 8086 emulator in glibc though (in fact, I'm sure we don't), so in either case, if people are relying on the syscall without a fallback option, they'd explode regardless, I think.
<rtg> infinity, would they explode at runtime or build time, or both ?
<infinity> rtg: I'd assume just runtime, if the headers are still exposed when the option is off.
<infinity> rtg: If the headers go away completely, then build time, but given the number of things that include the headers, I suspect that's not intended to happen.
<rtg> thank you LP for blowing up and _not_ accepting my bug report.
<infinity> rtg: LP is suffering some major infra mojo right now.
<rtg> infinity, bug #1473447
<ubot5> bug 1473447 in linux (Ubuntu) "linux: VM86 should be disabled" [Undecided,New] https://launchpad.net/bugs/1473447
<rtg> infinity, we've got it disabled in Wily (4.1+), so we can experiment with the fallout
<infinity> rtg: Yeahp, that seems like the safe approach for now.  We can abuse wily userspace a bit, cross-referencing with codesearch (which should have 100% coverage for what we care about, I'd be VERY shocked if we ship anything Ubuntu-only that uses vm86), and then sort out conclusions.
<infinity> rtg: codesearch's only failure here is that it's only search unstable, so doesn't give us a clear view of the possibility that precise might be more broken than trusty or wily.
<infinity> rtg: But it's a start anyway.
<infinity> I really think we need to set up an Ubuntu codesearch instance that covers all supported series'... It's crazy useful.
<rtg> infinity, seems like we should certainly have it disabled by 16.04, so experimenting on 15.10 makes sense
<infinity> rtg: Yeahp, and in 15.10/16.04, I have zero issues with the idea that if some bits of userspace break without it, we can just deprecate/remove them if they're not fixable.
<infinity> rtg: But that's a harder pill to swallow for precise and trusty.
<rtg> agreed
 * cking wonders why the watchdogs are going nuts: https://pastebin.canonical.com/135040/
<infinity> cking: That's... Impressive.
<infinity> cking: I've never seen a kernel try so hard to starve userspace.
<cking> infinity, it did have some repercussions: https://pastebin.canonical.com/135045/
<pointertonullval> Hey guys I'm building my own embedded device and it will connect over usb to a computer. How I can start writing a linux driver? Is a kernel level problem or more high level? Thanks
<apw> usb is interesting because there is a userspace library interface iirc, so you can write things out of the kernel
<TJ-> pointertonullval: Look at the USB 'gadget' interface
<pointertonullval> apw, TJ- thanks! something like this? http://www.linux-usb.org/gadget/
<unixabg> apw: it appears that casper does not like the multiple squashfs files on boot. But i am fairly 
<unixabg> confident that is sees them since it does make the mount points and then fails (I think on 
<unixabg> getting the overlay right).
<apw> it is possible that casper is trying to lay down multiple layers of overlayfs and not using the multiple layer support
<apw> for which there likely is no way to figure out if the functionality exists in the kernel ... hmm
<infinity> apw: Does casper have support for multiple layers at all?  That would seem odd, if it's a new kernel feature.
<apw> infinity, it has some support in the sense they are layerable, ie mount the bottom two together, then mount the results with the next layer up
<apw> though you soon hit the stack depth limit in the kernel, so i think we bust on overlayfs at two mount layers, ie 3 layers
<apw> unixabg, how many layers are there ?
<infinity> apw: Anyhow, sorting out if functionality exists should be a non-issue, casper isn't the sort of tool one uses "blindly".  It should just do what you ask it to do, and if you're using a kernel that can't support that, you get to keep both pieces.
<apw> thoug in a sense we have some way to do it two ways with differnet limits in each case
<apw> and the second way only if you have a newer kernel, which doesn't tell you it can do it, though i guess for casper at least we kinda know what its built with
<infinity> apw: If it's a question of mount options changing to support way 1 and way 2, and there's a distinct upstream version cutoff to go from 1 to 2, you could case uname -r.
<infinity> Or, not case, but convert-and-compare, probably.
<unixabg> apw: on my test with wily it fails by just adding a second layer. It may be helpful if I outline
<unixabg> how I am testing, I basically am doing a quick remaster and I am generating my partial squashfs
<apw> infinity, ugg you are not putting me in my happy place
<unixabg> files with live-partial-squashfs-updates:
<unixabg> http://live.debian.net/gitweb/?p=live-tools.git;a=blob_plain;f=bin/live-partial-squashfs-updates;hb=refs/heads/debian-next
<infinity> apw: Do I ever?
<unixabg> once I generate a partial-squashfs-update (psu) against the filesystem.squashfs then I button
<apw> infinity, those days you offer to take me to the pub, yes
<unixabg> the image back together and boot it. But it is not working. I did test one layer was working on 
<unixabg> linuxmin17.1 I think, mom to check that,
<unixabg> yes that is correct, but any more than filesystem.squashfs and psu1.squashfs caused failure.
<unixabg> Let me run one more quick test, since late yesterday and I had many tests going I do believe that now
<unixabg> I can not even stack on one psu.squashfs. Be back in a short bit...
<unixabg> apw: ok wily failed when I tried to add only one psu.squashfs along with filesystem.squashfs, next testing
<unixabg> linuxmint17.2
<apw> unixabg, can't look at it right now, but it would be good to get a dmesg if you can to see if it is throwing a depth limit in there somewhere
<apw> report any testing here and i'll see if i can figure it out
<unixabg> apw: humble appreciation. Ok now I just booted linuxmint17.2 + 1psu.squashfs and it is ok.
<unixabg> s/and/and remastered and booted live,/g
<apw> unixabg, whihc kernel does that have in it
<unixabg> apw: uname -r produces 3.19.0-20-generic
<unixabg> apw: dmesg in an image: http://fyeox.com/downloads/20150710-loop1fail-wily.png
<unixabg> It could be that it does not have the correct kernel version or something. Anyhow I am willing to
<unixabg> assist however I can. I want the multiple squashfs to work well.
<brainwash> cking: hey, I noticed bug 1470845 too. should this be forwarded somewhere upstream?
<ubot5> bug 1470845 in systemd (Ubuntu) "systemd on wily desktop generating short lived threads every second in a quiet system" [Undecided,New] https://launchpad.net/bugs/1470845
<brainwash> installed forkstat some minutes ago
<cking> brainwash, I was hoping it would get some triaging and attention on the ubuntu side of things, it maybe the way it's configured at the moment and is a temporary issue
<brainwash> cking: it? what could be misconfigured?
<cking> brainwash, i don't know, that's why I filed the bug
<brainwash> ok :) sadly, I only have access to ubuntu wily right now
<brainwash> and I've never used forkstat before
<infinity> cking: Did that happen before 222?
<cking> infinity, I don't know either
<brainwash> 222 was pushed just recently
<cking> it's the "oh, I've noticed something that looks suspect and I don't know why or when it happened" kinda bug
<brainwash> yeah, I don't understand this, but it made me wonder
<kees> (rtg offline?) apw: in the past, usplash needed VM86, but it shouldn't be hard to deal with if that still an issue
<infinity> kees: usplash was many, many years ago. :P
<mjg59> Yeah sorry about that
<ogra_> lol
<jdstrand> ogasawara: hey
<jdstrand> $ cat /proc/version_signature 
<jdstrand> Ubuntu 4.1.0-1.1~dogfoodv1-generic 4.1.0
<jdstrand> ogasawara: mic does not work
<jdstrand> ogasawara: for a data point, 4.0 that is in wily with the two commits I mentioned yesterday does work
<smoser> hey. question on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1473527
<ubot5> Launchpad bug 1473527 in cloud-init (Ubuntu) "module ssh-authkey-fingerprints fails Input/output error: /dev/console" [Undecided,New]
<smoser> is there any reason that that should happen ? (IO error on /dev/console)
<smoser> where cmdline: console=ttyS1,115200
<smoser> and the ttyS1 is seemingly fine (watching it from an ipmi)
<smoser> anyone think of some reason that such a thing would occur 
<ogasawara> jdstrand: care to file me a bug for tracking?  I think that sforshee on my team (possibly even ppisati) have your same system.  I'll see if they can reproduce.  If not, I'll have jsalisbury walk through a bisect with you when he's back on Mon.
<jdstrand> ogasawara: ok
<jdstrand> ogasawara: ubuntu-bug linux?
<ogasawara> jdstrand: yes please
<jdstrand> ogasawara: is it worth updating linux-firmware to what is in wily too?
<ogasawara> jdstrand: I don't believe so, has it even been updated for wily?
<jdstrand> yes
<jdstrand> it doesn't look like there is anything in there that would help this, but there are some other things. I'll update, reboot, retry and file
<jdstrand> ogasawara: hrmm, it said it wasn't an official Ubuntu package. how do people normally report against these ppa kernels?
<ogasawara> jdstrand: ah shoot, we don't typically have high volume of bug reports against the kernels we push to that ppa
<ogasawara> jdstrand: I'd say run the 4.0 kernel which was working to run ubuntu-bug linux (just to gather the system details)
<ogasawara> jdstrand: and in the description note the regression with 4.1
<jdstrand> actually, I see there are some files in /etc/apport for firefox. let me try a few things
<jdstrand> well, my 4.0 would fail too I think (I recompiled it with those two patches)
<jdstrand> but yeah, I'll figure out how to report this thing :)
<ogasawara> oh right
<ogasawara> jdstrand: if all else fails, manually file and I'll still make sure we get eyes on it
<jdstrand> ok, thanks
<jdstrand> ogasawara: heh, after reading the apport source: APPORT_DISABLE_DISTRO_CHECK=1 ubuntu-bug linux
<jdstrand> ogasawara: it still throws up a message about how it is unofficial, but it opens the browser to create the report
<ogasawara> jdstrand: oh nice, I'll have to remember that.  I assume it does indeed attach the standard logs to the bug?
<jdstrand> it says it will. I'll know in a moment once I finish the description
<jdstrand> ogasawara: looks like it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1473560
<ubot5> Launchpad bug 1473560 in linux (Ubuntu) "microphone regression on 4.1" [Undecided,Confirmed]
<ogasawara> jdstrand: great, thanks.  I'll take it from here.
<jdstrand> ogasawara: thanks!
<kees> infinity: yeah, totally, but just in case there were other sneaky things like that still floating around
<infinity> kees: As noted in the bug, codesearch.debian.net certainly shows a fair few references to vm86.h, the question is how many have fallback modes or are ifdeffed to oblivion, etc.
<infinity> kees: So, it needs a bit of investigation.
<kees> infinity: yeah. fwiw, dosemu is fine. ;)
<lamont> http://paste.ubuntu.com/11858310/ <-- lazy brain question... is that trace consistent with a "DO NOT BLOCK" kmalloc call?
<lamont> trusty kernel
 * lamont stands answered
#ubuntu-kernel 2015-07-11
<JanC> several i386-only video drivers don't work half of the time anyway...
<JanC> because of broken video BIOS'es with no updates available (anymore), etc.
<JanC> SiS being a good example
<cristian_c> hi
<cristian_c> about regression I talked here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
<ubot5> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
<cristian_c> I tested the last test kernel and I reported results a monthnago
<cristian_c> month ago
<cristian_c> where can I find the upstream revert request?
#ubuntu-kernel 2016-07-11
<memguy> ok so i insmod every single oss .ko module i could http://pastebin.com/VsiPgkWJ   then i created the dsp  device file major 14 minor 3 character device then tried to uses it nothing said  No such device or address 
<memguy> How does the /dev/dsp module get associated with the oss modules  from the lsmod seems like everything depends on osscore but not sure on why the device file is not working would have thought one of the LKM would register /uses /dev/dsp i mean what creates this or links this to usable device file
<mjg59> memguy: Why are you trying to use the oss drivers?
<memguy> I know i may have installed the modules in the incorrect order or didn't pass parameters so maybe thats the issue. in dmesg i do have a lot of  
<memguy> oss_ali5455: Unknown symbol ac97_spdifout_ctl (err 0)
<mjg59> If all you want is /dev/dsp, then use alsa and load the OSS compatibilty module
<memguy> ...etc so maybe its those issue... though i am spining my head on what modules and what parameters to uses with this audio hardware 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
<memguy> I just want to uses the old oss as opposed to the alsa stuff for right now
<mjg59> If the alsa driver is loaded then OSS won't be able to bind
<memguy> well this kind of sucks i am trying to remove the alsa module or all the snd.* LKM but i get Module snd is in uses 
<memguy> humm so first off how does one locate dependencies or process currently using an LKM  so i can terminate these resources so i can modprobe -r snd.* all away
<memguy> Thats my first issue my second issue is what .ko to load to get oss sound working  mjg59 you mentioned using the alsa loading the oss compatiblity module what name would that be for the .ko what location
<memguy> ya kind of sucks seems if i kill pulseaudio or hd-audio it just recreates the process something so those are not the root process
<memguy> so i am kind of stuck not able to unload these lkm's and not able to kill the sound audio process that probably uses these LKM 
<mjg59> memguy: load snd_pcm_oss
<mjg59> That'll give you /dev/dsp
<memguy> where would that .ko file be located /lib/modules/???
<mjg59> Why?
<memguy> doing a find for it gave me nothing
<mjg59> Just do modprobe snd_pcm_oss
<memguy> modprobe: FATAL: Module snd_pcm_oss not found.
<mjg59> Oh hm. I haven't actually checked whether that's still built.
<memguy> either way my more general issue is how to uninstall all the snd LKM's rmmod with out getting dependency issues or module in uses
<mjg59> Try installing osspd instead? That uses CUSE to emulate /dev/dsp
<memguy> ya i will give that a try some time but really rather then using some software  character driver analogy to FUSE .. i want to understand how to load and unload the different sound modules properly from scratch
<ohsix> why?
<memguy> because to me understanding how to load and unload proper lkm's for devices you have more control in the end of troubleshooting and getting hardware to work
<ohsix> that doesn't follow but OK
<memguy> Plus to me this is the missing piece in understanding what creates the /dev/dsp what LKM's and how they are associated to an LKM the device files them selfs
<memguy> Ideally i would have like to uninstall /rmmod/modprobe -r all the snd.* modules i had from lsmod ... then  go to the oss .ko and insmod/ modprobe them to create the /dev/dsp ...etc devices
<memguy> And the other important thing to understand would have been how to trace down what is holding some LKM from not unloading 
<memguy> any help would be great on the uninstalling in use modules how one can remedy this
<memguy> so i guess if rmmod -f doesn't work because kernel wasn't compiled with the ability to force modules to unload then one would have  to track down all dependencies by hand and kill those... and if there is circular dependencies then  the only way i can see it is a reboot with blacklisting 
<memguy>   483 ?        00:00:00 pulseaudio
<memguy>  1442 ?        00:00:00 hd-audio0
<memguy>   387 ?        00:00:00 indicator-sound
<memguy> does anybody know how to kill these process because they get like recreated
<memguy> and i am thinking that these are part of my problem of not being able to rmmod -f the snd.* LKM
<memguy> ok well i got it down to  1442 ?        00:00:00 hd-audio0
<memguy>   removing pulseaudio because it auto regenerates so trying to figure out this last one
<memguy> never mind figured it out  after i removed rmmod -f  in the correct order from 0 dependencies onward i finally was able to remove all the snd.* based modules which when i looked took care of the ps 1442 process. Which this all was held up by pulseaudio being installed. I am curious of one thing when i relooked at /dev/snd all the devices pretty much disappeared but i am left with seq and  timer so curious maybe there is still
<memguy>  an LKM that is for audio just not named snd.* that i am missing?
<memguy> Or why are these 2 devices left behind
<apw> memguy, or that is from something which is built in
<ricotz> apw, hi, isnt that essential for the 4.7 mainline builds? https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=a3b42405327c946274fe8ee0e737a27b396ce7bf
<apw> ricotz, i am not sure what you are asking
<ricotz> apw, I have a "missing-symbols" problem of nvidia dkms module with the 4.7 mainline kernel
<apw> ricotz, with which one
<apw> ricotz, these are only debug builds, they not intended for long term use
<ricotz> apw, sorry, currently can't say with exact symbol it was
<apw> ricotz, no which version of the mainline build ... as they are built with whatever tim applies
<apw> so any which are newer than when he applied that will have that
<ricotz> 4.7rc4 worked, none after that
<apw> ricotz, which is the latest you have tried
<ricotz> rc6
<apw> -rc7 built at 5 UTC this morning which would have been after so it should be "fixed" if that is your issue
<ricotz> the initrd size shrunk by over 1MB with it
<apw> symbol tables are big
<ricotz> -rw-r--r--  1 root root 45060130 Jul 11 12:29 initrd.img-4.6.0-8-generic
<ricotz> -rw-r--r--  1 root root 43939988 Jul 11 12:28 initrd.img-4.7.0-040700rc6-generic
<apw> so i guess test -rc7 if that resolves the issue, then it may be worth rebuilding 5 and 6
<ricotz> will reinstall rc4/rc5 in a bit
 * apw is confused, but will let you report whatever you do
<ricotz> I just want to double check the old kernels and having the dkms module with the current toolchain
<ricotz> apw, btw, the rc7 build doesnt include the mentioned commit
<apw> ricotz, it wouldn't need to include a commit
<apw> ricotz, the changelog is dropped in wholesale
<ricotz> ok
<ricotz> apw, https://paste.debian.net/plain/780375
<apw> ricotz, with which version
<ricotz> seems rc7 is more complete compared to rc5/rc6 and grepping the Symbols.map listings matches the rc4 one
<ricotz> 367.27
<ricotz> this was from a log of rc5
<ricotz> e.g. "grep -r _smp_call_function$ System.map-*"
<ricotz> apw, looks like the rc7 build works again with nvidia here
<apw> ricotz, ack
<ricotz> apw, was this a known issue with those missing symbols like  *_smp_call_function ?
<apw> ricotz, upstream added an option to remove redundant exports from the symbol tables to save space, this broke out of tree modules using any of them
<ricotz> ok
<rtg> dannf, I think the only kernels we're accepting patches for are P,T,LTS-U,X, and Y. V and W are now EOL. kamal - correct me if I'm wrong.
<dannf> rtg: yeah, already sync'd with kamal - W is EOL, but V isn't for some reason
<rtg> dannf, ack
<kamal> rtg, the ones that just went EOL are   LTS-U and W   (V is still alive)
<rtg> kamal, ack
<memguy> is /dev/pcm0,1,2 and /dev/pcmin0,1 the oss device files for speakers/lineout and mic/line in if so how do you know which device file is associated to which device without trial and error
<memguy> O never mind ossinfo tells me everything i need to know except i still don't get what /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0 devices is for is this some kind of digital in/out port or something
<memguy> i imagine 
<memguy> SPDIF seems as it for an output port also digital but never used it of all the other port i think this and midi are the ones i never used
#ubuntu-kernel 2016-07-12
<mowthegrass> Hi There - Anyone facing issues with 3.19 /4.2 kernel, All DELL servers running on 3.19/4.2 kernel on reboot does not boot and gets stuck with message random: LVM unrandom read with 33 bits of entropy available 
<mowthegrass> is it a BUG 
<apw> mowthegrass, i'd say it is likely a bug indeed.  that last message doesn't look to be anything other than a warning about early use of entropy before it is really very random; from my reading it is not a blocker
<apw> mowthegrass, well it _might_ indicate we are triggering transfer of ral randomness into urandom, so it might indicate a block, very hard to be sure
<apw> mowthegrass, do the machines come out of it after some time? 
<apw> mowthegrass, but either way, you should file a bug "ubuntu-bug linux" and add the details
<mowthegrass> apw:No they dont come up 
<apw> mowthegrass, do they come up from cold, or do you have to boot an older kernel
<mowthegrass> it just drops to switched clocksource tsc
<mowthegrass> apw,Thanks on your input 
<fg_> afaict, xenial's kernel is not affected by CVE-2016-6187 (the apparmor setprocattr oops) because the causing commit bb646cdb12e75d82258c2f2e7746d5952d3e321a is not contained in the 4.4 stable kernels - is that correct?
<arges> https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-6187.html looks like it
<fg_> arges: thanks, I only looked at / knew about http://kernel.ubuntu.com/reports/kernel-cves.html (which does not list CVE's that don't affect)
<fg_> arges: although your link also says "needs-triage" for some of the entries (e.g., source: linux) ;)
<arges> tyhicks: ^^^
<tyhicks> fg_: hello
<tyhicks> fg_: that's correct (xenial is not affected)
<fg_> tyhicks: thanks!
<tyhicks> fg_: since I populated the break-fix line with the git hashes of the commit that introduced the flaw and the commit that fixed the flaw, a bot will come through and update the status of all the kernels
<tyhicks> fg_: I left it as 'needs-triage' intentionally because of that
<fg_> tyhicks: okay - that sounds reasonable ;) thanks for clearing it up!
<tyhicks> no problem :)
<dmj_s76> is it still possible to get a patch for a nasty bug in the nouveau driver?
<dmj_s76> in time for the kernel cycle on the 16.04.1 iso?
<apw> dmj_s76, is it in the kernel itself ?  the last kernel has been uploaded (in theory)
<apw> dmj_s76, though depending on severity and recoverablility, you never know
<dmj_s76> apw: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/tree/drivers/gpu/drm/nouveau/nouveau_drm.c
<apw> dmj_s76, what is the bug number
<dmj_s76> apw: It prevents installation and booting until you install the nvidia proprietary drivers with Pascal (There is a workaround, but it involves the user knowing about modelines and vga modes)
<dmj_s76> apw, looking that up now
<dmj_s76> apw: couldn't find a bug report so filed one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1602340
<ubot5> Launchpad bug 1602340 in linux (Ubuntu) "nouveau: boot hangs at blank screen with unsupported graphics cards" [Undecided,Incomplete]
<apw> dmj_s76, and is there a fix yet ?
<apw> dmj_s76, i assume the code thinks it supports those cards
<dmj_s76> apw: I believe so.  Ben Skeggs worked on one yesterday, which I'm planning to test today.
<apw> dmj_s76, could you add any information you have on the fix to the bug as well pls
<dmj_s76> apw: https://github.com/skeggsb/nouveau/commit/11fcd1624b0a1c73fe3b2fa15c3cc45816da0470
<dmj_s76> apw: added
<apw> dmj_s76, thanks ...
<apw> dmj_s76, and ... keep that bug updated with your testing too pls
<dmj_s76> Will do, really hoping to get this in the iso, since it's an issue that will make most users consider Ubuntu uninstallable if they have a recent GPU.
<apw> dmj_s76, i assume you have a range of affected and non-affected GPUs you could test this on to make sure it does not regress older kit
<apw> dmj_s76, would a test kernel help your testing ?
<dmj_s76> apw: Yes, we have 9 series and 7 series to test for regression
<apw> dmj_s76, cool, could you document that in the bug as well
<kamal> dmj_s76, I've built a Xenial test kernel with the nouveau patch applied: http://people.canonical.com/~kamal/lp1602340/ ... does that advance your testing efforts?
<dmj_s76> apw: Thanks for the build.  I've tested the patched kernel on our hardware and it allows clean installs to boot into unity without trouble.
<dmj_s76> No regressions on the older nvidia hardware we have.
<apw> kamal, ^
<dmj_s76> kamal: thanks for the build...fixes boot issues with current gen nvidia gpus nicely
<dmj_s76> If we can get that into the iso, it'll save quite a bit of systems from being effectively uninstallable.
<kamal> dmj_s76, yes, saw your feedback, thanks -- we are indeed going to get it into the Xenial ISO for ya
<dmj_s76> kamal: Thanks...that'll really help make the Ubuntu install experience better.
<kamal> dmj_s76, we agree!  thanks very much for your work on this.
#ubuntu-kernel 2016-07-13
<memguy> ok i have installed oss  where alsa has been but i have noticed the only problem i have with it is when i turn the ossxmix up all the way i don't get the  loudness range i did with ALSA. Maybe i am missing some mixer amplifier thing but i don't think so. Anybody know if this is fixable?
<RAOF> There's presumably some reason you're using the deprecated-for-nearly-a-decade OSS rather than ALSA?
<memguy> I just wanted to try it . Main reason was understanding of LKM loading the correct ones and getting device files working with the drivers... Thats the more general and important question i had figured out. But as a result of figure this all out i now notice only one setting is really noticeable it is the  loudness level just curious what is causing this?
<RAOF> I'm honestly surprised you could get it to work at all, and that we're still building it.
<memguy> I do have an additional unrelated question. It is  .. is there any program ,command , or  file to look up which device files are associated to which module if any. I know each LKM doesn't necessarily  have a /dev device file as well as each dev file doesn't have to be linked to a driver (could be just user created). But it sure would be nice of a way to list what device files are associated with what LKM
<memguy> to know which ones are created by which lkm's. I have a few ways of going about this none of which i like yet
<memguy> lsmod simple just opens /proc/modules so nothing revealing that i can uses to leverage how to get the associated device files
<memguy> yet
<memguy> /proc/devices seem to give mostly all device files names to some extent but there is no good way i can figure out yet on how to linking I am wondering if anybody knows of an ioctl or function one can pass the name of the device file that would tell it what LKM .ko it is registered with
<memguy> There are ways like grepping the source for open(/dev/ occurrences in the LKM source code one by one but this isn't really nice or fast way just to find out about an LKM. I purpose that LKM writters embed in the modinfo strings the device files  it creates if any . They all have Author , parameters ,...etc why not include the device files it uses in general
<mjg59> The name of the device file is determined by udev, not the driver
<mjg59> So the kernel has no idea what htey're called
<memguy> wait LKM can create device files 
<mjg59> They can, but they shouldn't
<memguy> why not
<mjg59> Because that's up to udev
<mjg59> Anyway
<mjg59> You can figure it out by looking at the major and minor numbers on the device node
<memguy> why do the want to uses udev i mean i get udev is for plug in play kind of detection which loads the LKM needed
<mjg59> And then look for the dev file under /sys which has those major and minor numbers in it
<memguy> So its like udev creates the device file then loads the LKM for it 
<mjg59> Then walk from there to the driver
<memguy> mjg59 not sure what you mean. I know how to find the device files major and minor number
<memguy> but how do you know which device file is associated to which LKM
<memguy> are you saying that the sysfs has a way to associate the LKM with a device file because i have a number of way to  figure out a device files major and minor numbers... but no way to know what device files are associated to which LKM if any. There could be one associated to an LKM or several or none. I just don't understand by major and minor number how one can determine what LKM its on 
<memguy> seems looking up a list of hardware to major and minor numbers is not a good way to do this as ever evolving LKM and device files one would have to have a list for his version he is on
<mjg59> There are files in /sys called "dev" which conain a major and minor number pair
<mjg59> That will allow you to associate the device node with a sysfs device
<mjg59> Then just follow the driver symlink
<kamal> dmj_s76, hi -- we've just deployed Xenial 4.4.0-31.50 including the nouveau patch in the -proposed archive -- can we get you to do one more quick smoke test of it for verification?
<kamal> dmj_s76, hi -- we've just deployed Xenial 4.4.0-31.50 including the nouveau patch in the -proposed archive -- can we get you to do one more quick smoke test of it for verification?
<dmj_s76> kamal: sure...I'll work on that this morning
<kamal> dmj_s76, thanks a bunch -- just a sanity check on any one of the GPU's should be sufficient
<dmj_s76> kamal: Just tested it...everything works right once the installer pulls in the proposed kernel.  (Still have to do some nasty workarounds to get to the installer, but that should be fixed once the kernel hits the daily iso)
<kamal> dmj_s76, excellent, thanks again for all this
<dmj_s76> My pleasure, makes the Ubuntu experience better and removes a huge support burden from us.
<lamont> does ipv6 autoconf truly not work through a (xenial, 4.4.0-28-generic) bridge?
<apw> lamont, are you saying the work around you had no longer works ?
<lamont> there wasn't a bridge involved in that...
<apw> lamont, there wasn't?  i remember it as bridge related
<lamont> this issue is that I boot a vm on a subnet that only has ipv6 (libvirt qemu-kvm), and I see the router solicitation go from the vm to ff02::2 on vnet0, but not on eth0.3 (the other interface in the bridge)
<lamont> oh.
<lamont> two different problems:
<lamont> 1) br0 (eth0.2 and actually nothing else atm), didn't get an ipv6 autoconf on the host, because of multicast_snooping being enabled.
<lamont> turns out that (I think), just enabling mutlicast_querier on that bridge is sufficient to get things happier, as a less invasive workaround
<lamont> the new issue is on br1 (which I've been poking at for way too long now...)
<lamont> current config is identical to br1, only with eth0.3 instead of eth0.2
<lamont> and the issue is that the VM doesn't get ipv6 autoconf
<lamont> at one point, I had radvd installed on the host, advertising to eth0.3, and it seemed that broke autoconf for br0...  but I didn't fully dive down that rathole.
<lamont> so I brought up eth0.3 on the host that has radvd for eth0.2, and...
<lamont> the host for the vms now autoconfs on both br0 and br1, and none of the vms do.
<lamont> having said that, /proc/sys/net/ipv6/conf/$IFACE/mc_forwarding would seem to be HIGHLY relevant to my needs, but utterly lacking in documenation as to how to configure it to forward all traffic bound for ff02::/64
<lamont> end rant
<lamont> http://paste.ubuntu.com/19288160/ <-- tcpdump -ni br1 icmp6
<lamont> ...:89:57 is hte vm
<lamont> and yes, when I actually get this mess working, there's a blog post in it.
<lamont>  grep -ve ^# -e ^$ /etc/smcroute/startup.sh 
<lamont> mgroup from eth0.3 source fe80::1 group ff02::1
<lamont> mroute from eth0.3 source fe80::1 group ff02::1 br1
<lamont> it hurts, but it configures ipv6 on the guests
<memguy> does any body know what the equivalent of configfs is in new linux is this info found somewhere in /sys sysfs?
<apw> lamont, hrm
<lamont> apw: which gets me to the next issue, where I see ipxe on the vm poke ff02::16 a couple times, and then fail over to ipv4 boot
<lamont> hitting ctl-b for the ipxe command line doesn't help either
<lamont> something tells me it may be time to bring in another box and see how it does booting with something like a real firmware interface
<lamont> apw: mind you, that's still totally ignoring the router solicitations
<lamont> ultimately, I suspect that I need dhcp6 queries from ipxe
<bbuccianti> Hi!
<bbuccianti> i don't want to interrupt anything
<bbuccianti> but i have a problem and i can't resolve alone
<bbuccianti> my kernel is booting to slow, or i think so
<bbuccianti> look at my systemd-analyze
<bbuccianti> systemd-analyze
<bbuccianti> Startup finished in 16.145s (kernel) + 7.476s (userspace) = 23.622s
<apw> bbuccianti, that does seem quite high, though not world ending
<bbuccianti> i agree with you
<bbuccianti> but i want to learn
<bbuccianti> and reduce boot time
<bbuccianti> can you give me some resources?
<memguy> i got a question on vdso how does this actually speed up syscalls . I know it maps a page for each program with the vdso.so lib but doesn't each still at the lowest level have to call sysenter/exit or int instructions? Or is it speeding it up by remapping a complete syscall handler function into vdso.so userspace page?
#ubuntu-kernel 2016-07-14
<memguy> i don't understand one thing if udev creates/destroys the mknod device file and loads/unloads the LKM for new devices . The what links the LKM to the device file when one does say cat  something > /dev/xxx  
<memguy> From what know the LKM has to register the /dev devices and provide the structure like cdev methods read,ioctl,write,..etc
<memguy> So udev may create the device files and load the LKM but it would be in the LKM that the linking of the device file would be. If there is no LKM code for the device file then it is useless only  useful for user defined stuff but not like to any system char or block device
<memguy> and when bash executes the code like cat something > /dev/xxx ... it must translate into a execv syscall or something which then  some how reaches the LKM code that is my issue the bash to the LKM and back for device files ... haven't got real into it yet but if anybody know let me know. My first thing is using debuggers or strace utility 
<memguy> right now i just don't see how the cat /dev/sda gets link to say the LKM for the ata hdd driver code. Get it translates to execv command but from there not sure at some level it must call a read function that some how calls the LKM
<mjg59> The driver registers a major and minor number, and the kernel dispatches the access to the driver
<memguy> its the &fops in the register_chrdev for example that will control what read function is called for a device file but how does the actual read() user level function get to that
<memguy> LKM
<mjg59> The kernel dispatches it to whatever registered that major and minor number
<memguy> read( fd , , ) takes a file descriptor number so how does that call get to the correct LKM
<memguy> after its at the LKM then i get from the fops will call the correct read function for the device file.
<memguy> plus the file descriptor doesn't even have to corrospond to a /dev/xxx file in the first place so i am assuming the userland code has tons of checks on what type of file descriptor this corrosponds to. And if it is  a /dev/xxx file it dispatches it to some syscall to dispatch it to the correct LKM code ... this is my guess mjp59 if you know more then by all means 
<mjg59> The kernel dispatches it to whatever registered that major and minor number
<mjg59> I don't really know how else to explain it
<mjg59> The kernel knows that the file descriptor refers to a device node
<mjg59> It knows the major and minor numbers of that device node
<mjg59> It knows what registered those numbers
<mjg59> And so it calls that code
<mjg59> Userland doesn't need to do anything special
<memguy> so read converts or looks up if the file descriptor fd has a major and minor number  from inode or filesystem info then how does userland know about the registered device thought only kernel level knows about that
<memguy> it would have to syscall with a major and minor number or something
<mjg59> Userland doesn't need to care
<memguy> for the read function at some level
<mjg59> The kernel created the file descriptor
<mjg59> It knows what it refers to
<memguy> O so the open () function requests this int fd  from kernel  not at userspace when opening a file it fd is created in the kernel
<memguy> never mind kind of stupid should have thought thanks for clearing that up
<memguy> so then it is always in the LKM or built into the kernel the code for linking a device file with the read, writting, ioctl ,...etc . And all udev is doing is mknod and insmod LKM plug in play wises
<memguy> But it is the LKM that gives the device file life
<memguy> class_create ,device_create ,register_chrdev and from these the kernel can associate the fd , major/minor , and  LKM methods to call
<MoPac> Hello. I'm trying to understand more about (kernel-level?) control of CPU freq in this era of intel_pstate. My CPUs keep (at random-ish intervals) getting stuck at 800MHz until I suspend/resume or restart. But there's nothing obvious happening in kern.log/syslog/dmesg/thermald, and the governor's available frequencies always show the correct range (unlike old issues Googling shows).
<MoPac> Am I even correct in thinking this is a kernel issue?
<MoPac> (It's 16.04 /i7-4510U)
<apw> NoPac (N,BFTL), that is cirtainly non-trivial to determine
<Evlb> hey
<Evlb> any1 here a tomoyo ninja?
<apw> Evlb, always best to just ask your question, we might know, we might not
<Evlb> In my case, i need to be able to disable tomoyo to be able to install updates, how ever, down-time is not feasible in this project.. So the question really is how to be able to install new software/updates without restarting the hardware? I am not able to install updates as of now due to Tomoyo
<Amine_> Hello all, I am running a Linux kernel version 3.14.32 under a remote Ubuntu 14.04 LTS linux machine. After a recent upgrade and a reboot the machine refused to boot and freeze at some point. I was able to reboot the machine in system rescue and also read the content of /var/log/dmesg to see what happened.
<Amine_> here is the dump of dmesg http://codepad.org/llFGvb62
<Amine_> can anyone help me please to interpret what's going on ?
<apw> Amine_, that pastebin doesn't look to be a dump from the failure that looks to be a failsafe boot
<apw> Amine_, is this a grsecurity kernel ?
<Amine_> apw, hmmm 
<Amine_> apw, are you sure ?
<apw> init: failsafe main process (1130) killed by TERM signal
<Amine_> I am a true newbie where can I found such logs please ?
<apw> logs for a previous boot are normally in syslog
<Amine_> apw, hmm ok
<apw> assuming of course they got there before the machine imploded beyond begin able to write
<Amine_> but I just monted a var partition where the logs has been recorded so I don't see if it concerns the mode rescue 
<Amine_> the current dmesg that I dumped was here
<Amine_>  /mnt/var/log/dmesg
<Amine_> the dmesg of the current rescue mode is in /var/log/dmesg
<jtaylor> hi perf is broken in xenial due to the binutils update :(
<jtaylor> includes the -31 in proposed
<jtaylor> needs a rebuild to pickup the new libbfd soname
<jtaylor> apw: I think you handled that last time ^
<apw> jtaylor, that might imply we need to promote the libbfd update to -security or something
<apw> jtaylor, could you file me a bug so i can track it
<jtaylor> k
<apw> jtaylor, and we might not be able to fix kernels already released either, hrm
<apw> jtaylor, i assume you are saying if you downgrade binutils to the version in -security it starts working ?
<jtaylor> apw: probably, the libbfd library changed named with the update
<jtaylor> 2.26 to 2.26.1
<jtaylor> don't know if that change really broke abi
<apw> bah, really they should not be allowed to do that
<infinity> Erk.
<apw> erk indeed
<infinity> That means a transition in xenial, other things depend on that too.
<infinity> How annoying.
<jtaylor> if it did not updating binutils to add a compat symlink might work
<apw> jtaylor, which was the first kernel you noticed this with
<jtaylor> apw: 28, but it should be all where perf links with libbfd
<jtaylor> which probably goes back to before xenial release
<jtaylor> don'T remember when exactly we fixed this (the link is needed so perf can demangle c++)
<infinity> Depends: binutils (>= 2.26), binutils (<< 2.27)
<infinity> So, that's a lie.
<infinity> And it's binutils' fault.
<infinity> The fix belongs there, if it's still compatible.
<jtaylor> so should I file a bug against binutils instead?
<apw> jtaylor, that was prolly when we first compiled against that version of binutil
<infinity> jtaylor: Yeah.  Either the SONAME shouldn't bump, or the shlibs need to change to (>= 2.26.1), (<< 2.26.2)
<infinity> jtaylor: In the latter case, we need a transition in -updates for all the rdeps. :/
<jtaylor> apw: when bug 1248289 was closed I think, so 4.4.0-24.43
<ubot5> bug 1248289 in linux (Ubuntu Yakkety) "Missing libunwind support in perf" [Medium,Fix released] https://launchpad.net/bugs/1248289
<infinity> slangasek: ^-- FYI
<infinity> It's not just a perf issue anyway, there are several packages that depend on binutils for libbfd.
<infinity> IIRC.
<apw> jtaylor, ok
<apw> infinity, ok those deps come from ${misc:Depends} how are those calculated
<infinity> apw: shlibs:Depends, from binutils' shlibs file.
<apw> ok so either way it is binutils... sigh
<infinity> Yeah, you've done nothing wrong here.
<infinity> It's all doko.
<infinity> Who's on VAC for a week or two. :P
<apw> infinity, oh derp, thats helpful
<jtaylor> I guess best option is to run the abi tool on libbfd and if its still compatible add a symlink
<jtaylor> its probably reasonably likely this minor release did not break the abi
<jtaylor> fwiw perf does not explode if you simply use the new soname ;)
<infinity> ABI tracking on binaries is an inexact science, mind you.
<apw> infinity, it does look from the way the shlibs is contructed that the lib name is not meant ot need to change for X.Y.Z Z++
<infinity> There's no way from the binary to know if a symbol is compatible, only if it was dropped or added.
<jtaylor> infinity: I mean this tool that looks at the source code
<infinity> jtaylor: Yeah, the header mangling tools are more exact, to be sure.  Just a pain to use.
<infinity> jtaylor: If you feel the urge, please do?
 * infinity is meant to be out today with a head-exploding cold, but was here for a meeting happening in parallel.
<slangasek> infinity: so the problem is we have a new bfd soname in 2.26.1, and a shlibs there which appears to be correct, but the previous binutils package declared a broader versioned dep which is no longer applicable?  Oh, and also this binutils was SRUed into xenial, brilliant
<infinity> The other "simple" way could just be to diff the header files manually and look for prototype changes.
<infinity> They could be identical.
<infinity> slangasek: Is the new shlibs correct?
<slangasek> infinity: it's "correct" in that it matches the files in the new package
<slangasek> I don't know if it's correct that the soname should have changed
<infinity> Oh, so it is.
<infinity> slangasek: Right, I meant the former.
<infinity> So, that's been "fixed", but in fixing it, doko didn't consider it meant a transition.
<infinity> \o/
<slangasek> so we basically need rebuilds + a binutils with Breaks: added
<infinity> Alternately, if they *are* compatible, we could fix it in a hurry with a symlink, then unwind the mess.
<slangasek> yeah, I can look at that
<infinity> apw: None of that should prevent promotion of your current kernel, nothing's more broken than it was before.
<apw> infinity, agreed
<apw> slangasek, thanks
<apw> jtaylor, would you file a bug if you haven't on binutils and let us know the number so we cna track this
<slangasek> apw, infinity: there's a single symbol dropped between 2.26 and 2.26.1 libbfd, "_bfd_elf_strtab_restore_size", which looks like an internal symbol name that shouldn't impact ABI. and libopcodes has no changed symbols.  I can dig a little deeper to make sure none of the symbols have changed ABI, but it looks like a compat symlink is going to be the aswer
<slangasek> jtaylor: ^^
<jtaylor> apw: bug 1603137
<ubot5> bug 1603137 in binutils (Ubuntu) "libbfd changed name without transition" [Undecided,New] https://launchpad.net/bugs/1603137
<apw> slangasek, it does feel like we are switching to a stable branch which might explain the .1 suffix on the overall version
<infinity> slangasek: In that case, changing the shlibs to (>= 2.26), (<< 2.26.2) along with the symlink addition would avoid the breaks-and-rebuild mess.
<jtaylor> slangasek: grepping perf code it uses no symbol starting with _bfd
<jtaylor> slangasek: only a small handful of bfd_ functions
<slangasek> yes, _bfd is a strong indicator that this is an internal symbol that should be ignored for ABI
<apw> infinity, then we get the same problem with the next one ?
<slangasek> apw: next one we stand at the entrance to the SRU queue with canes and make the SRUer get it right before it's accepted ;)
<infinity> apw: Yeah, but at least we'll know, because the deps will be correct. :P
<slangasek> right, someone know where I should look for binutils upstream VCS?
<slangasek> since debian/copyright points me at cvs://:pserver:anoncvs@sources.redhat.com:/cvs/src and I desperately want that to not be correct
<apw> infinity, right but if the intent was never to change the .so, then we _do_ have to rebuild everything with the tight restriction
<infinity> slangasek: That symbol doesn't show in the headers, so I concur with your internal-only assessment.  Vaguely entertaining that the binutils maintainers don't know how to make private symbols hidden. :P
<infinity> slangasek: https://sourceware.org/git/?p=binutils.git;a=summary
<infinity> Err, no.
<infinity> That's dead.
<slangasek> https://www.gnu.org/software/binutils/ says git://sourceware.org/git/binutils-gdb.git instead
<infinity> Ahh, it moved, yes.
<infinity> Found it when you did.
<infinity> apw: Well, kernels will rebuild organically but, indeed, we'd need to transition other rdeps if we want to keep the right restriction.  Point made.
<jtaylor> or we convince upstream to not release point releases which break abi anymore
<jtaylor> then the restriction could stay correct
<infinity> It may well be that's upstream's intent already, but because it's a private library with a full-ver SONAME, they fail even when they succeed.
<infinity> Would be tempting to submit patches to both make it a proper shared library and mark all the internal symbols hidden.
<infinity> But I suspect the first would be rejected, and the second would be an annoying amount of fiddly work.
<infinity> Especially if the first wasn't considered.
<slangasek> I, too, am often tempted when I see a rathole to get out my yak clippers
<infinity> slangasek: I'm going to go find chickens and oranges.  If you need an emergency SRU review later for this mess, text me, and I'll show up if I'm not out like a light.
<unixabg> apw: Greetings, we talked about a year ago about overlayfs and casper. I am trying to add additional partial.squashfs to live media
<unixabg> so a filesystem.squafhs and a partial.squashfs file.
<unixabg> I believe I see what the issue is and I am testing with 16.04. Should I test and work with 16.10 daily to do more debug
<unixabg> work. The issue (or so I think) is that the partial.squashfs file gets mounted but does not get added to the lowerdir
<apw> unixabg, blimey, that was a long time ago, but yes, i remember vaguely
<unixabg> stack. 
<unixabg> here http://install.fyeox.com/scripts/live-partial-squashfs-updates is how I make my partial updates.
<unixabg> This is probably a better link to share: https://github.com/unixabg/live-medium-install-tools/blob/master/scripts/live-partial-squashfs-updates  
<apw> unixabg, you should work on the yakkety one yes, as we can rotate that quicker to get fixes in
<unixabg> Not sure where in casper that happens but in my partial squashfs update script PSU, I am appending see line 35-37 on link from githup.
<unixabg> s/githup/github/g
<unixabg> Ok my time is like vapor just as I suspect yours is. Ok to just download daily.iso and start from there ?
<unixabg> I would like to get to where you can have the prestine original filesystem.squashfs and a psu.squashfs for easy
<unixabg> remaster and a clean path of updates.
<unixabg> s/updates/updates for custom iso/g
<apw> sounds reaosnable indeed
<dmj_s76> kamal: So I've tested the patch, and it fixes the installer in uefi mode.
<dmj_s76> kamal: Bios mode seems a little more complicated.
<dmj_s76> There's a difference in behavior regarding vga modes at install time vs first boot
<kamal> dmj_s76, the ISO kernel just went out the door so if there are further issues we'll have to tackle them in the next cycle
<kamal> dmj_s76, so pls start up a fresh bug report to track that, when you get to that point
<apw> kamal, indeed, they are publishing right now
<kamal> apw, launchpad has been flooding my inbox with the news :-)
<apw> kamal, i bet ... :)  mine is deluged too
<dmj_s76> kamal: Well, it's a huge improvement
<dmj_s76> kamal: Might not be a kernel specific issue either
<kamal> dmj_s76, my favorite kind of issue: not the kernel's problem ;-)
<dmj_s76> kamal: ...seems that bios mode only works if you set a vga mode manually
<dmj_s76> (in the live install)
<dmj_s76> (first boot doesn't need a vga mode set)
<unixabg> apw: Ok just a bit of overlayfs mounting help? When I setup overlay for partial squashfs creation, I compose a list and mount all
<unixabg> in one. In casper it looks like it wants to sort of compose them together one at a time. So I am not sure about that. Is there
<unixabg> somewhere I can read to help me better understand how to mount overlay in on top of $rootmnt ?
<unixabg> mount -t overlay overlay -olowerdir="${_LSTACK}",upperdir=./psu_overlay_rw,workdir=./psu_overlay_work ./psu_overlay
<unixabg> is what I am used to using and I have the ${_LSTACK} confiured with all the mounts in the correct order.
<apw> unixabg, so i think we didn't use to be able to mount multiple underlays, can ou do that now with overlay ?
<apw> if so then the code is suboptimal as it is
<unixabg> apw: well I do it so, I will say yes. Can you take a quick look at my utility script to create psu and rejoin work?
<unixabg> https://github.com/unixabg/live-medium-install-tools/blob/master/scripts/live-partial-squashfs-updates
<unixabg> It is not long and it does work, so I _think_ it not a large jump to just compose the lower mount list and 
<unixabg> pass that for a single mount command. Or at least that is what I _think_.
<unixabg> casper currently does mount the partial-squashfs-update.squashfs file, but it just does not get mounted in 
<unixabg> the lower stack. I hope this helps apw and I am willing to test.
<slangasek> infinity, jtaylor, apw: I've satisfied myself that the only ABI change in 2.26.1 is the dropped "internal" symbol (not exported in headers); will take care of fixing up the backwards-compatibility
<apw> slangasek, excellent news
<memguy> I am wondering if the is a file in /proc/pid that tells you stuff about the fs_struct locks for a particular process i know there is /proc/locks or lsof one can uses but was just curious if on dumped that info into each process folder seems it should be there but haven't found it
<memguy> /proc/pid/fd tells you what files via file descriptors but not anything about the file locks or file attributes of the descriptor
<memguy> /proc/locks is the only thing i really see for locks was thinking it would be under each process the locking for a process in each pid folder as well 
<memguy> as /proc should contain all the info for any process so i may just be forgetting where to look for this anybody know
<memguy> Seems to me proc is missing alot of info on things that have to do with locks there should be for each process a memlocks , filelocks , process_locks /thread_lock files ( maybe the latter of the 3 should be broken down into semephores, mutex, spinlocks info files )
<apw> memguy, not everything is out there indeed
<memguy> well it seems /proc should contain anything held in the task_struct and substruct info that one could view and in most cases it does just right now not really good with locks
<memguy> at least for me that is
<infinity> memguy: /proc/<pid>/fdinfo/<fd> maps to /proc/locks.  Same info, different view.
<memguy> well that tells you the filenames and descriptors the process uses but where does it tell you what region is locked , what type of lock,...etc
<infinity> memguy: http://paste.ubuntu.com/19406450/
<infinity> For example.
<memguy> hum weird i only get pos:	0
<memguy> flags:	01 maybe its something with my lock because i get it showing up in /proc/locks
<memguy> Another thing though is this is just for file locking where does one get the info for thread/process locks 
<memguy> for memory locks i have similar to file locks map_files and maps which i imagine the 
<memguy> b751b000-b76c4000 r-xp 00000000 07:00 3792       /lib/i386-linux-gnu/libc-2.19.so
<infinity> By thread locks, you mean pthread_mutex_lock()?
<memguy> r-xp  p means protected memory  
<infinity> Cause I can't see how or why that would be exported in /proc
<memguy> I mean all of the locks spinlock , semphores , or the binary ones called mutex all of it would depend on the process to say i was looking at kernel level kworker or 
<memguy> normally it would just be mutex i get that but i it also on the rare occasion provide the things when spinlocking or other semephores occur
<apw> the kernel does not export info on its internal locks no
<infinity> You're unlikely to find ways to introspect that without gdb and a knowledge of how those bits are implemented on your platform.
<infinity> It's a libc/kernel tag-team, and very hard (impossible on some platforms, I'd suggest) to export.
<memguy> ok but for pthreads and userlevel multitasking that needs to lock parts of code i imagine it is mostly all done with mutex or semephores not so much busy waiting spinlocks so is there a file to look up that info for those for each /proc/pid/xxx
<apw> those are implemented with futex's normally, no idea if they are exposed in uspace, though by definition you only get half the story
<apw> as they only implement the "not spinning and wasting cpu" parts
<memguy> how about more on the memory attributes  r-xp "p or s " tell me its shard but nothing about if it is locked or other attributes that the MMU imposes on it?
<memguy> I know i could write an LKM to create a file in each /proc/pid printing any info i want from task_struct or sub structures so in theory i can do it all but if its already there i would be reinventing the wheel plus my point of view right now is understanding how to trouble shoot any problem that could happen with a process/scheduler, filesystem , or MMU . Think of it more like I am finishing up with super sysadmin and moving 
<memguy> back to developer soon. I fluctuate between software engineer/program to sysadmin.
<unixabg> apw: ok I think this is the answer of support of multiple lower layers:
<unixabg> https://kernelnewbies.org/Linux_4.0#head-2274894c6e481a014a984600daeb55d8e5d6d91a
<unixabg> Which in fact is similar to what my script does. Now how to move casper in to this format I think is in the
<unixabg> setup_unionfs function line 385. 
<memguy> also what is futex its seems like it is a type of mutex at the syscall level all most. But is it only for processor locking or can it do memory locking and file locking because kind of confused about this and flock or mlock where they all stand
<memguy> never mind its for process's /code /shared memory locking 
<memguy> fast user space mutexes
#ubuntu-kernel 2016-07-15
<unixabg> apw: Please consider this patch for casper http://fyeox.com/downloads/casper.patch
<unixabg> It takes advantage of the ability to mount multi-lower layers (I only tested with a couple) but it does work
<unixabg> and I think is a good update to casper. I also tested a couple of installs, which the support of multiple .squashfs
<unixabg> files does not appear to break normal installs. s/couple/couple of extra .squashfs files located along side 
<unixabg> the filesystem.squashfs inside casper dir.
<memguy> O just got a way with pagemaps file to figure out what parts of memory attributes are set for pages and memory regions like mlocks , ...and many other memory things. And i have a way to determine all file locks so the last thing is a way to get the info from /proc for process locks or code locks or thread locks , mutex, semphores,  spinlocks ,..etc
<memguy> I don't think it exists but i can definitely add a temp LKM to give me the extra task_struct substructure info for process locks, signal, syscalls, or any other thing i thing is missing . I think syscall and signal files are there though so maybe only locks
<memguy> ok so initrd initramfs,...etc would be only need if the drivers are not compiled into the kernel. I.E initrd and other names for it is nothing more then a ramdisk that is initial mounted so that one can load the right LKM drivers to mount the real root file system that the /sbin/init is executed to kick off a usable OS.
<memguy> But why does compiling in make the kernel bloaty ?
<memguy> The other option is your using memory for a ramdisk and loading the drivers as LKM so how is that less bloaty
<memguy> I get the purpose of a ramdisk like initrd , initramfs, squashfs (compressed version) ,..etc are useful if you want the OS not to uses any secondary storage but not for huge sizes increases
<memguy> Also if one compiled the drivers needed like ext4 into the kernel all one would need i think would be to tell grub where  the kernel images is and then the kernel would do the rest as a single self contained application 
<infinity> memguy: Not everyone has the same computer or the same filesystem, etc.
<infinity> memguy: Compiling in *all* the modules bloats the kernel immensely.
<infinity> memguy: For your own personal builds, it's indeed plausible to build a monolithic kernel without any loadable modules, and you won't need an initrd if you don't need userspace tools (lvm, mdadm, luks, etc) to find and mount root.
<memguy> yes but if you know the file system the kernel is going to be on then compiling that one file system driver into the kernel not as a Module M would not increase the size all that much. I am just saying if you already " know the filesystem its going to uses"
<infinity> memguy: Like I said, for your own personal non-distro builds, that's fine.  Distro kernels can't make assumptions, so we opt for maximum flexibility with minimal footprint.
<infinity> And it's not about what filesystem the kernel is on, grub handles that, it's about what filesystem root is.
<infinity> And we don't tell people how they have to format root.
<memguy> ok i get that but your assumption that LKM won't be available is wrong they will be after the  file system is mounted and chroot or pivot root occurs 
<infinity> The kernel modules live on the root filesystem.  You need modules to mount the root filesystem.  That's the whole point of the initrd.
<Martiini> is there anyone here who works for ubuntu/canonical
<memguy> then /sbin/init and onward if one has modprobe, insmod will beable to load LKM you just need the file system driver stuff built in 
<infinity> memguy: You're talking in circles here.  For *you*, that works.  For people with zfs, xfs, lvm, raid, etc, etc, it doesn't.  Not unless we build everything in.  Nevermind all the SCSI controllers and the like we need to build in to even find the disks.
<infinity> memguy: Trust me, we didn't decide to have an initrd just cause it's hip and cool.
<memguy> And i get that for a distro you don't want to assume ext4 but if you already know that then you should beable to get rid of initrd , initramfs, squashfs  , casper,,...etc
<infinity> memguy: Even if we assume a filesystem and enforce that (which we won't), you're missing device drivers.
<memguy> Ya so if your using that many layers up then i agree there would be alot of built in module that would bloat it i see now
<memguy> zfs ,lvm,..etc
<infinity> memguy: The bootloader loads the kernel and initrd using Very Slow BIOS/EFI/etc calls, then the kernel flips to protected mode and can't call back into that.  We need real drivers for every SCSI/ATA/etc device you may have your root disk on.
<memguy> well not ever just the one your machine uses but for a general distro i get you cann't make that assumption
<infinity> memguy: Better way to look at this.  Look at the size of your initramfs on disk.  If we built literally everything into the kernel to find every root, that's how much bigger your kernel would be, and that memory would never be freed.
<infinity> memguy: Anyhow, like I said, for specific people and usecases, an initrd isn't necessary.  You're right.  But no point bringing it up in a distro kernel channel, where we absolutely need one.
<memguy> Ok there reason why i asked is that with grub i after i compile the kernel and give it the initrd or ramdisk  path i get it kernel panicing cann't find initrd and the path is clearly correct
<infinity> Martiini: Probably.  The general rule of public channels is "don't ask to ask, just ask".  That probably applies to what you're not asking.
<infinity> memguy: I'd say the path clearly isn't correct, or it's not a valid ramdisk.
<infinity> memguy: It's grub's job to load the initrd you ask for into RAM, then the kernel unpacks it and execs init from it, like it would any other root filesystem.
<memguy> Maybe because i am using grub2 and i edit the config file directly like regular grub thats the issue i should rerun the grub programs
<infinity> memguy: So, either it's broken, or you fed grub the wrong location.
<memguy> to built the new menu item for the kernel
<infinity> update-grub is generally how Ubuntu's grub2 likes to update itself.
<memguy> I was pretty good with grub so maybe it was the grub2 changes that screwed things up.
<Martiini> I've had this idea - makeing of device specific compiled kernels, similar to android kernels on phones - custom made made kernels for all laptops etc .. Is it possible
<infinity> Martiini: It's not going to happen for the distro, no.
<memguy> Also do you need a different initrd intramfs ,..etc for different kernel x86 or x64 or different arch's
<infinity> Martiini: It's certainly "possible" to do yourself, but good luck QAing 200 kernels.
<infinity> memguy: The initrd contains kernel modules matching your exact kernel, and userspace bits matching your root.  Extrapolate your answer from there.
<Martiini> what if every distro would compile/download for each laptop/device specific kernel 
<infinity> Martiini: Then we'd have no way to support the result.
<memguy> so you need a unquie initrd or ramdisk for each different kernel compiled 
<infinity> Martiini: Not sure why you think this would be any better than a generic kernel with a bunch of driver modules.
<infinity> memguy: Yes.
<memguy> Does it matter if the arch is the same but the version is different for the kernel?
<Martiini> I just noticed that phones run faster with custom built kernels
<infinity> memguy: It has to be exactly the same (or, to be fair, ABI compatible, but usually you break ABI when mangling a kernel build)
<infinity> Martiini: Apples and oranges.  x86 laptops aren't ARM phones.
<Martiini> yes
<infinity> Martiini: And in the ARMv7 phone case, it's not that you *can* have a custom kernel, it's that you *must* have a custom kernel with the vendor's device-specific goop.
<infinity> Martiini: A generic ARMv7 kernel that actually has all the right bits for 7 devices works great on those 7 devices and doesn't magically get faster if you drop support for 6 of them.
<memguy> ok that is probably my issue and the fact i edit the configuration file that said don't edit this config file uses some grub2 utitlty program
<infinity> (Gets a bit smaller, but not faster)
<infinity> Martiini: Unless the way you're measuring "speed" is boot times.  Then, yes, a very generic kernel can take a second or three more to boot as it probes for hardware you don't have, etc.  But once it's running, it's just a tiny bit of wasted memory, and otherwise a non-issue.
<memguy> but the path was correct probably not the correct path to the correct initrd maybe. Or the config if when editing but some char in that shouldn;t have been added
<memguy> thanks
<infinity> And given that, before Google started doing monthly updates, my phone had an uptime of 9 months (and how it's one month at a time), boot time seems irrelevant.
<Martiini> ubuntu and archbang are fastest distros, but I guess it's not because of kernel 
<memguy> If i create another LKM since i am at the kernel level can i just read any memory location like if i open /dev/mem  will have have no access restrictions like i do in userspace programs with open /dev/mem
<memguy> Or am i still going to get page fault or other errors if the page that i am reading isn't mapped 
<memguy> I know i am not making sense but what i mean to figure out is how /dev/mem is allowing one to read physical memory without virtual address
<memguy> I guess i just want know is how /dev/mem read physical memory because everything to a program is virtual memory even at the kernel level once page tables/paging is setup for it
<memguy> does the first bytes at offset zero of /dev/mem corrospond to the physical memory 0x0000000 onward... or does it corrospond to the first page mapped in the page table 
<memguy> not necessarily  placed at physical address 0x0000000. reading from it in user space seems from seeing bios info and grub info that its reading true physical but i just don't understand how this /dev/mem is doing this what is the driver or LKM for it that would shed light on it?
#ubuntu-kernel 2016-07-16
<memguy> O i see /usr/src/linux-headers-3.13.0-32/include/uapi/linux corrosponds to /usr/include/linux directory 
<memguy> user space api
<memguy> and for the kernel header download not much in any of those  directories other then  include or script directories everything else is left over Kconfig or Kbuild or Makefiles that where not stripped out with the .c files in all the folders 
<memguy> though there are a few py scripts in the tools subdirectories but thats about it
<memguy> So the next step i think for me is to go thru all these header files in the include subdirectories as best i can  catting as many together to see if i can understand a 90 % chunk of the definitions and naming of things. The from there go to source code c files when need if an issue occurs.
<memguy> Adding a .h or .c or a menuconfig option isn't so bad any more
<memguy> to the linux source code
<memguy> its totally do able leaving off the arch folder .h which are the macro or asm code for the different arch's that gcc embeds in when compiling most of the arch where written more as macro's the regular asm instructions probably to make it more portable doing alot of those ifdef ifndef checks to include the right asm for the arch when compiling
<memguy> so its not as easy to get even if your pretty good with asm code you still have to be familar with the macro's so that may take a little while
<memguy> thats if i was going for arch  porting but i like how if you leave off those arch specific things then the code is really totally distinct from an arch 
<memguy> And since the code is distinct from an arch at that level its not as difficult to imagine porting to a completely new arch would be just adding macro's and ifdef/ifndef definitions to the arch folder (obviously a little more difficult then that for sure)
<memguy> Because one would need to know what arch files are important for adding a new arch on to and which ones are just helper asm .h files for a particular arch 
#ubuntu-kernel 2017-07-10
<PaulePanter> Hi. Following https://launchpad.net/~kernel-ppa/+archive/ubuntu/ppa for Ubuntu 17.04, I get an error.
<PaulePanter> Fehl:6 http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu zesty Release            
<PaulePanter>   404  Not Found
<PaulePanter> Iâd like to easily test Linux 4.12.
<PaulePanter> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa as third hit in a Google search, but also doesnât seem to provide Linux 4.12.
<PHLin> PaulePanter, hi there, to correct ppa from Canonical kernel team should be the last link you pasted here
<PHLin> PaulePanter, but yes, it only provides 4.11, if you want to test 4.12, you can fetch the mainline kernel here http://kernel.ubuntu.com/~kernel-ppa/mainline/
<PaulePanter> PHLin: Thank you. Iâll try that later.
<PHLin> PaulePanter, no problem
<hfaleiros> Hi, linux-headers-4.9.36-040936_4.9.36-040936.201707050932_all package is broken, see http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.36/BUILD.LOG
<hfaleiros> dpkg-deb: building package 'linux-headers-4.9.36-040936' in '../linux-headers-4.9.36-040936_4.9.36-040936.201707050932_all.deb'. dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory tar: -: Cannot write: Broken pipe tar: Error is not recoverable: exiting now dpkg-deb: error: failed to write filename to tar pipe (data member): Broken pipe dh_builddeb: dpkg-deb --build debian/linux-headers-4.9.36-0
<gpiccoli> Hi folks, is there any good suggestion about sending patches to ubuntu kernel list?
<gpiccoli> Idon't have a LP opened, but we do have an internal bugzilla...The patch is present in v4.7+, but we want it ot backported to Xenial 4.4 if possible
<gpiccoli> so, leitao suggested me to send the patch directly to the list
<gpiccoli> I backported myself. Any tags needed, like [SRU] ?
<gpiccoli> apw, ^
#ubuntu-kernel 2017-07-11
<ziviani> hello everybody! I'd like to cherry-pick the commit 460df4c1f (KVM: race-free exit from KVM_RUN without POSIX signals) into zesty (master-next)
<ziviani> but such commit changes arch/mips/kvm/mips.c, which leads to a huge amount of files to be ported
<ziviani> AFAIK, Ubuntu doesn't support MIPS so I don't know if it's worth, what do you guys recommend?
<cascardo> ziviani: then, you can try a backport that does not include those changes, and document it in your sru request, then cross your fingers that reviewers will ack it  :-)
<ziviani> cascardo: I hope they do, otherwise it will be more than 50 commits (MIPS) to be send :-D
<ziviani> cascardo: thanks for the hint, I'll do it!
#ubuntu-kernel 2017-07-12
<manjo> apw, smb is artful could end up with 4.13? 
<xnox> manjo, as per leanne v4.13 is the current target for artful.
<manjo> xnox, oh cool! thanks 
<sforshee> manjo: yes assuming no major hiccups we hope to land on 4.13 for artful
<manjo> sforshee, nice.. I have some patches from 4.13 backported to 4.10 .. so that is good to know that I need to make only one pull req ie for zesty and artful will automatically get those patches 
<sforshee> manjo: I'm generally applying anything for zesty to artful anyway, it it's in 4.13 it just gets dropped when we rebase
<manjo> sforshee, in this case .. you might not be able to do that .. coz there are a few heavy backports from .13 to .10
<sforshee> manjo: ack
<manjo> sforshee, but I will try and cherry-pick those from .13 to artful and send you 2 pull reqs 
<sforshee> manjo: you probably only need to worry about 4.12 in unstable, if we don't apply it to 4.11 it's not a big deal
<manjo> sforshee, ah yes I can do unstable instead of 'artful' 
<sforshee> manjo: it shouldn't be long before unstable becomes artful/master-next anyhow
<manjo> sforshee, is that happening this week ? 
<manjo> currently on .11 10.24 tag I think 
<manjo> coz I can wait to send both pull reqs at the same time if that is the case 
<sforshee> manjo: probably not this week I'm guessing, but maybe next week
<manjo> sforshee, yeah I can wait till next .. coz you are in the test phase etc for the next sru cycle for zesty 
<sforshee> manjo: no need to wait on my account, I'll make sure it gets to the appropriate branch either way
<cascardo> well, the deadline for next sru cycle are patches acked by Friday
<cascardo> if you miss it, then it's another 3 weeks
<manjo> cascardo, yeah I won't be done coz I am still testing my patches .. and it is going to be done on multiple arches etc .. 
<manjo> sforshee, ack .. I will most likely send it your way early next week .. 
#ubuntu-kernel 2017-07-14
<spoonless[m]1> hello, is ubuntu linux associated with the african ubuntu socialism?
<apw> spoonless[m]1, ubuntu linux is associated with the african concept/word ubuntu
<spoonless[m]1> I'm a bit confused about the philosophy, it seems inherently racist - "From the 1970s, the ubuntu began to be described as a specific kind of "African humanism". Based on the context of Africanisation propagated by the political thinkers in the 1960s period of decolonisation, ubuntu was used as a term for a specifically African (or Southern African) kind of socialism or humanism found in blacks, but lacking in
<spoonless[m]1> whites, in the context of the transition to black majority rule in Zimbabwe and South Africa. "
<spoonless[m]1> https://en.wikipedia.org/wiki/Ubuntu_(philosophy)
<apw> spoonless[m]1, yeah but that is unrelated to the sentiment of the Ubuntu word which has no english equivalent, but "a quality that includes the essential human virtues; compassion and humanity" is how google translates it
<apw> spoonless[m]1, it is that "togetherness" that the project is meant to espouse, and why it has that name
<spoonless[m]1> but it is a kind of socialism/communism?
<apw> no it is literally a word like "happy" or "sad"
<apw> it means that kind of "having some humanity"
<apw> we don't seem have needed that word in english, so we don't have a direct word for it
<spoonless[m]1> the wiki article states it is to do with communitarian socialism. I would have thought that the African definition would be the definitive one
<spoonless[m]1> have you read the wiki article?
<apw> spoonless[m]1, yes, the first paragraph tell you the meaning of the word, and the second tells you "it has come to mean"
<apw> spoonless[m]1, it is the first meaning that the project is related to
<apw> not what it has come to mean
<spoonless[m]1> so that is the current definition then
<spoonless[m]1> yet, ubuntu linux was started after the 1970s, when the meaning had changed
<apw> spoonless[m]1, this word has two meaning in time and space, i am telling you as a member of the project the first one is the one the project espouses
<apw> very much the second wording of the meaning of the actual word, the bit about sharing
<apw> and i would argue it has gained a second meaning, not the meaning "has changed"
<apw> as the second paragraph says "has come to be used", that does not negate its original meaning
<spoonless[m]1> so it's a bit like calling a project communist, but it has nothing to do with redistribution of wealth?
<apw> no, it is like calling a project "be nice to people and share with them" but using a shorter zulu work for it
<apw> like calling the free-office suite libreoffice because it sounds cool
<apw> it does not make it french
<spoonless[m]1> well, ubuntu doesn't seem to be working out very well in Zimbabwe under Mugabe. They redistributed the White owned farms and now they are starving
<spoonless[m]1> and in South Africa they are singing songs about murdering the Whites. Not to mention the murder rate is shockingly high there
<apw> spoonless[m]1, yes people a inherantly dangerous things which often do very dumb things, to each other
<apw> spoonless[m]1, that doesn't change the meaning of the word, those things simply arn't ubuntu
<apw> spoonless[m]1, much as they arn't nice
<apw> spoonless[m]1, if "ubuntu" was called "nice" you wouldn't say it was a silly name because people arn't nice
<apw> though you would have plenty of other reasons to think it was a bit daft
<spoonless[m]1> www.etymonline.com/index.php?term=nice
<spoonless[m]1> "late 13c., "foolish, stupid, senseless," from Old French nice (12c.) "careless, clumsy; weak; poor, needy; simple, stupid, silly, foolish," from Latin nescius "ignorant, unaware"
<spoonless[m]1> anyway, ubuntu seems a bit anti-White to me. Especially with it being espoused by convicted terrorist Mandela
<cking> Alice in Wonderland: "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to meanâneither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be masterâthat's all."
<apw> spoonless[m]1, the political movment maybe so, the project not so much
<JPelletier> Hello everyone, I'm experiencing a random system HANG on reboot right after GRUB. I tried to print more logs with "earlyprintk=efi" and it's freezing right after "[    0.00000] bootconsole [earlyefi0] disabled"
<JPelletier> Do you think it could be a Kernel bug?
<JPelletier> I don't have a lot of experience with linux
<JPelletier> Anyone can help me with my reboot HANG issue? I have no more ideas and I am a little desperate
<tomreyn> JPelletier: i'd try getting support in #ubuntu first of all
<tomreyn> oh you did. well try serial console or netconsole
<JPelletier> tomreyn: Will try that next week, never did it before
<magiclin-> Hi, i have some strange problems with the kernel/module ata_piix and the intel ICH9R controller (since i'm updatet to 16.04 - kernel 4.8)
<magiclin-> https://pastebin.com/zMyH467S
<magiclin-> https://pastebin.com/L7rC6A7a
<magiclin-> can someone help?
<tomreyn> magiclin-: if disabling IOMMU as a temporary workaround is an option for you, then give that a try. is it reproducible? does it only happen after suspend?
<tomreyn> the klernel you are using is not the default 16.04 kernel version. is it the HWE one?
<magiclin-> Linux sparks 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26 18:08:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
<magiclin-> not modified 
<magiclin-> it's not direct reproduciable , the error occurs  after some hours 6-24h of runetime 
<magiclin-> sometimes with the damage of the filesystem 
<tomreyn> so this is the HWE kernel, ok https://packages.ubuntu.com/xenial/linux-image-4.8.0-58-generic
<magiclin-> yout mean, i should rebould the kernel with the config entry CONFIG_INTEL_IOMMU=n ?
<magiclin-> rebuild
<tomreyn> no, i was suggesting to disable it at kernel boot. but a better option is probably to just increase swiotlb as discussed here https://bugzilla.redhat.com/show_bug.cgi?id=1256281
<ubot5> bugzilla.redhat.com bug 1256281 in kernel "swiotlb buffer is full/Out of SW-IOMMU space errors" [Unspecified,Closed: currentrelease]
<tomreyn> if it leaks memory, however, you'll have the same effect - it will run full later for you, too.
<tomreyn> at this point it's unclear whether it leaks or it just needs more addressable memory, though.
<tomreyn> also, i know very little about this stuff, you'd be better talking to someone who is actually into this.
<magiclin-> ok thank you, i will try it with the kernel command line to 
<tomreyn> magiclin-: see the IOMMU (and thus swiotlb) documentation at https://www.kernel.org/doc/Documentation/x86/x86_64/boot-options.txt - I am assuming this is x86_64 here, not i686.
<tomreyn> so iommu=off was my initial suggestion, but i'm not actually sure this would improve things more than it would break.
<magiclin-> i compared the working and the not working kernel configuration 
<magiclin-> https://pastebin.com/h1V6NDQY
<magiclin-> there is only a difference in CONFIG_INTEL_IOMMU_SVM=y ?
<tomreyn> the options i discussed are to be passed to linux during boot, on the kernel command line
<tomreyn> i.e. edit /etc/default/grub and run update-grub
<tomreyn> you are comparing two entirely different kernel versions there
<tomreyn> 3.13.0 -> 4.8.0 is a HUGE diff
<magiclin-> thats clear , you mean i should increase the swiotlb size ? and i'm asking if the problem eventually relatet to the iommu shared memory option too
<jack__> hey guys, I'm running out of ideas and I'm wondering if you can help me, someone on #lubuntu reckoned this would be the place. I need kernel 4.12 or newer for the audio chip in my laptop, does anyone have a recommendation for an ubuntu/debian-based distro with that kernel?
<magiclin-> ok initial you suggested to disable die IOMMU , after that to increase the loadbalancer size - sorry that's not my native language
<magiclin-> @tomreyn https://cateee.net/lkddb/web-lkddb/INTEL_IOMMU_SVM.html
<tomreyn> magiclin-: yes, that's what i suggested. swiotlb, however, is not a load balancer, but the 'SoftWare Input Output Translation Lookaside Buffer '
<tomreyn> magicline: i understand that you are considering to rebuild your kjernel with IOMMU disbaled, I don't understand why you're considering a rebuild if you can just disable it using an oiption, however,
<magicline> " ok thank you, i will try it with the kernel command line too"
<tomreyn> okay ;)
<magicline> :-)
<tomreyn> i didnt spell this out but... AFAICT IOMMU without shared memory is of not much use, so disabling that is effictively as rigorous a measure as disabling iommu entirely.
<tomreyn> (but i may be wrong there)
<magicline> however , i will try the options - otherwhise i need a other HBA or mainboard :-/
<spoonless[m]1> African Communism
#ubuntu-kernel 2018-07-09
<frickler> klebers: do you have some more reference regarding the issue found with 4.15? I have some recently installed xenial machines running with it and would like to assess whether it would be better to downgrade
<klebers> frickler, we are not sure exactly when we are going to -updates the fix for the random number generator, probably during the next couple of weeks. In the meantime you can either downgrade it or install the kernel from -proposed (which is not guaranteed yet to be completely stable)
<frickler> klebers: is there a bug tracking "fix for the random number generator"?
<klebers> frickler, https://bugs.launchpad.net/bugs/1779827
<ubot5> Ubuntu bug 1779827 in linux (Ubuntu) "failure to boot with linux-image-4.15.0-24-generic" [Critical,In progress]
<frickler> klebers: great, thanks. so iiuc once the machine has haveged running, there should be no further issue
<klebers> frickler, sure! yeah, it seems it works around the issue for most users
<frickler> klebers: o.k., I was just worried that there might be some security related issue when running with that kernel. so I guess in my case just keeping the servers running until there is a newer version in -updates seems fine
<bluj> hello. i'm rebuilding a ubuntu kernel via instructions in https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel . one of the things it mentions to do is to change the version string in debian.master/changelog so i can tell i'm running the intended kernel etc.  this is not taking effect though- my resultant .deb's just have the version without my appended string. anyone know why?
#ubuntu-kernel 2018-07-10
<kisak> anyone have trouble with http://kernel.ubuntu.com/~kernel-ppa/mainline/ builds 4.17.3 to 4.17.5 and debuild not completing when it gets to packaging irda modules?
<kisak> 4.17.2 is fine and it looks like 0001-base-packaging had a significant update from debian?
<kisak> (update with 4.17.3)
<apw> kisak, as in building them 'myself' ?
<kisak> apw: built on ubuntu's build farm for my PPA, https://launchpad.net/~kisak/+archive/ubuntu/steamvr/+build/15102209
<apw> kisak, ahh d-i exploding, because a udeb has become empty ... we don't build d-i for the dirty builds
<kisak> after that build last night, I did some local tests and just commented out the irda modules entry in package.list
<apw> right that would be the correct fix for it
#ubuntu-kernel 2018-07-15
<xedniv> how would someone go about setting up an automatic build system (ex. from git) to build kpkgs?
<xedniv> we have to include some patches internally and would like to track the ubuntu server kernel package sources. apply our own patchsets to a branch, and then have a separate system produce built packages from that repo
<xedniv> i found no documentation about doing this
<fooctrl> are there any news when kernel will be updated in Cosmic to i.e: 4.18? it's still on 4.15
<fragile> What should KW_DEFCONFIG_DIR be set to when building a new kernel from here? https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel In a fresh 16.04 Server VM, `fakeroot debian/rules clean` just works, but in my 18.04 host it explains that the environment variable is mandatory and isn't set. 
<fragile> I've tried setting it to /usr/share/kernel-wedge , but this leads to a "No such file or directory" error of some kind in /usr/share/kernel-wedge/commands/gen-control , inside the read_package_list subrouting I think. Where `die "package-list: $!";" is.
<fragile> Don't know enough perl to really make sense of what's happening around there
<fragile> Made sense of the error now. Creating an empty package-list file fixed my problem, after finding the README.gz doc. But is package-list supposed to be optional (like in the documentation) or not?
#ubuntu-kernel 2019-07-08
<apw> aiena (N,BFTL), you can remove the build stamp and the build become incremental
<dsmythies> aiena: (actually you seem to be gone): ` make deb_pkg`  has not worked for me for a long time. I use `bindeb-pkg` . I almost always to incremental builds. Full command: `time make -j9 olddefconfig bindeb-pkg LOCALVERSION=-stock`
<dsmythies> apw: The Ubuntu mainline kernel PPA build is broken again, for amd64 and i386. The build log complains about the kernel configuration, but I don't know if that is the root cause or not. Reference: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2/
<apw> dsmythies, looks rather to be complaining about compiler hardening flags when building host tooling; hrm
<dsmythies> apw: O.K. yes, but ealrier it complains about the config file, so I thought maybe that was the cause. Anyway, just thought to let you know.
<apw> dsmythies, no this is a bug introduced by the compiler hardening options being turned on by default
<dsmythies> apw: O.K. thanks. It compiles fine for me. I used the Ubuntu lowlatency kernel config from 5.2-rc5 (I missed the -RCs in between). 
<apw> dsmythies, the compiler has changed very recently
<dsmythies> apw: Yes, I am using quite an old compiler version, because my test server is still 16.04. (Compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609)
<tomreyn> https://bugs.launchpad.net/bugs/1835809
<ubot5> Ubuntu bug 1835809 in systemd (Ubuntu) "AMD Ryzen 3000 series fails to boot" [Undecided,New]
<tomreyn> ^ with patch
#ubuntu-kernel 2019-07-09
<dsmythies> apw: I made an 19.10 VM server and tried to compile the mainline there, using the exact same kernel config file. Indeed, it fails as per the Ubuntu mainline PPA. (Compiler: gcc (Ubuntu 9.1.0-6ubuntu2) 9.1.0) Which is no news for you, but for my own education.
<apw> right the compiler has some new options enabled by default.
#ubuntu-kernel 2019-07-10
<Nakato> Where do I file a bug report for https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/Makefile
<Nakato> I've been trying https://bugs.launchpad.net/ubuntu/+source/linux-snap/+filebug but I'm making launchpad error.
<apw> Nakato, erm not sure there is a sensible place to file a bug for those
<apw> Nakato, what is the issue
<tomreyn> Nakato: there's also https://bugs.launchpad.net/ubuntu/+source/snapd
<tomreyn> and https://bugs.launchpad.net/snapd for non Ubuntu specific snapd bugs.
#ubuntu-kernel 2019-07-12
<gpiccoli> hey sub526, do you have deb-src enabled in /etc/apt/sources.list?
<gpiccoli> One way is to use "apt-get source", the other is git
<gpiccoli> there is a good guide here: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<gpiccoli> for your specific demand, you'll need to set "IRQSOFF_TRACER=y" in my understanding
<gpiccoli> sub526 ^
<tomreyn> sub526: be sure to also install any pending updates, your system lacks security + bug fixes.
<tomreyn> (the community provides support in #ubuntu)
#ubuntu-kernel 2019-07-13
<sub526> tomreyn : How to install any pending updates?
<sub526> gpiccoli: Tried git clone git://kernel.ubuntu.com/ubuntu/Ubuntu-xenial.git, but it fails as "fatal: remote error: access denied or repository not exported: /ubuntu/Ubuntu-xenial.git"
<tomreyn> sub526: sudo apt update && sudo apt full-upgrade
<tomreyn> you can also configure unattended updates
<tomreyn> sub526: git urls may be case sensitive, maybe try git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git
<tomreyn> here's the web view of this repo: https://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/
<dupondje> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2/
<dupondje> don't know if we can get them rebuild? :)
<sub526> tomreyn: Thanks , I'm able to clone the xenial kernel git. To build the mainline kernel, I followed "make menuconfig", "make" and "make module_install". Does the same sequence can be used to build the Ubuntu kernel too?
<tomreyn> sub526: did you read the wiki gpiccoli pointed yuo to, yet?
<sub526> tomreyn: Yes followed that wiki. While running "fakeroot debian/rules editconfigs" I got "*** ERROR: 13 config-check failures detected", Can this be ignored?
<sub526> tomreyn: While building the kernel it failed with "debian/rules.d/4-checks.mk:24: recipe for target 'config-prepare-check-generic' failed"
#ubuntu-kernel 2019-07-14
<sub526> Hi All, I am trying to build the ubuntu-xenia for x86_64 PC using the steps mentioned in https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel .
<sub526> But at the end of âfakeroot debian/rules editconfigsâ after I edited the configuration for amd64/config.flavour.generic to disable CONFIG_CC_STACKPROTECTOR_STRONG and enabled IRQSOFF tracing, I get the following errors(â*** ERROR: 13 config-check failures detectedâ): https://pastebin.com/8mEvS16Z
<sub526> How to solve this, any help is appreciated?
<sub526> Hi all, I want to build the ubuntu-xenial kernel after changing CONFIG_CC_STACKPROTECTOR_STRONG to normal. But it fails with âcheck-config: FAIL (n != y): CONFIG_CC_STACKPROTECTOR_STRONG policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'i386': 'y'}> mark<ENFORCED>â. Is there any method to solve this issue?
<apw> sub526, change the annotations file to match, in debian.master/configs/annotations
<sub526> apw: It has CONFIG_CC_STACKPROTECTOR_STRONG                 mark<ENFORCED>, so what needs to be changed?
<apw> sub526, did you change the value for hte architecture you are changing to match
<sub526> apw: Yes 
<sub526> After running "fakeroot debian/rules editconfigs" where it creates .config? Actually I checked in source root directory but could not find it.
#ubuntu-kernel 2020-07-08
<lynxis> How do you release kernel versions? Is there a written process about it? I've a regression in 16.04/xenial which was introduced in the upstream stable 4.4.x, but also fixed later in upstream and wonder how long I've to wait to be settled down into linux-image-4.4.
<sarnold> lynxis: the dates for the sru cycle are on https://kernel.ubuntu.com/ and you can see the progress per package on https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html
<mathnewb> hi. i am new to kernel development. i am compiling focal using the master branch here: git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal and i notice that the master branch is at version 5.4.41, while a fresh install of the focal release image is at version 5.4.44. Why the discrepancy?
<mathnewb> Or am I reading it wrong? Sorry. I am learning.
<cascardo> mathnewb: the master branch is outdated, possibly some tooling or process problem. but don't confuse corresponding upstream stable releases and our ABI versioning
<cascardo> so, we release a package that is versioned like 5.4.0-40.44
<cascardo> the important bit here is 5.4.0 and -40, ignore the .44 after -40, which we call upload number and increase for every upload, trying to couple with the ABI, which is -40
<cascardo> unfortunately, to add some confusion, that kernel has mostly all patches that are included in upstream 5.4.44
<cascardo> the version that is included in the ISO would be 5.4.0-26, with upstream patches up to 5.4.30
<cascardo> mathnewb: does it make sense?
<mathnewb> cascardo: I was just eating some dinner. Thank you for writing back. I will read it now.
<mathnewb> Ok. I think it makes sense, yes. In my VM (which I updated to latest after installing) a `uname -r` returns `5.4.0-40-generic`. the master branch is outdated, and building it gives me linux-*-5.4.0-39-generic*, which I believe squares with your explanation (master is slightly out of date).  
<mathnewb> and if I am understanding correctly, there is no exact "1-1" correspondence between an upstream ("mainline"?) kernel and an ubuntu release
<mathnewb> the upload number just happens to coincide at the moment
<mathnewb> (which tricked me into thinking there was a relation there that doesn't exist)
<mathnewb> Does that seem correct?
<sarnold> it's certainly confused me in the past :)
<mathnewb> Haha, I'm glad I am not the only one!
#ubuntu-kernel 2020-07-09
<LocutusOfBorg> hello, do you have any ETA (if it will happen) to see src:linux point to version 5.5+?
<LocutusOfBorg> stuff like libgpiod is BD failing because it needs kernel 5.5
<sforshee> LocutusOfBorg: it will happen, it's been slow to due to some missing pieces which got delayed due to other urgent work
<sforshee> I don't have a good estimate for you, I'd hope we'd have something in -proposed at least in the next couple of weeks
<LocutusOfBorg> thanks
#ubuntu-kernel 2020-07-10
<ogra> juergh, have you seen my last comments on https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1881623 ? seems it is actually not related to modules at all but to the fact that USB is completely off with the 5.3 kernel on pi4/8GB while it works just fine with 5.4
<ubot5> Ubuntu bug 1881623 in linux-raspi2 (Ubuntu) "USB support missing in initrd makes booting core with writable on USB impossible" [Undecided,Confirmed]
<ogra> (this is why my own build of teh focal tree works well an switching to the pi-kernel snap breaks the world ut seems)
<juergh> ogra, yeah. waveform just notified me yesterday that it's a problem specific to the pi4 rev1.4.
<ogra> well, are there plans to go for 5.4 eventually ? it seems to work just well
<ogra> (for core18 i mean indeed, given that UC20 is still far out)
<juergh> ogra, yes. but we don't have a kernel snap upgrade story yet due to DTB incompatibilities.
<ogra> i thought the gadgets can do that now ... (it is indeed an issue with roll-back in case your update fails)
<juergh> ogra, unfortunately no. there's an ordering issue with gadget and/or kernel snap refreshes you might end up rebooting into a new kernel with old DTBs or the other way around.
<juergh> we'll have a 5.4 uc18 kernel snap in edge soon.
<ogra> yeah, i know the issue, but i had hopes the new gadget update machanism could at least handle the forward path nowadays ... too sad :/
<juergh> we talked about this yesterday and a plan is being worked on.
<ogra> (the lockstep mess between kernel and gadget is an old issue ... )
<ogra> ah, cool
 * juergh is surprised we haven't been bitten before
<ogra> because we never updated ;)
<juergh> well. kernel snaps are refreshed and even within the same kernel version the DTBs might break.
<ogra> it could be fixed by simply adding dtb load support to u-boot ... and not load the dtb from ram
<ogra> i think that should work nowadays (it didnt when i initially developed the first pi images though, you had to use what the bootloader gave you in ram but i think u-boot evloved)
<ogra> not sure if that would have any bad effects on GPU stuff though ...
#ubuntu-kernel 2020-07-11
<Kon> I have no idea where to report bugs for proposed updates
<Kon> 5.4.0-42 in Focal-proposed seems to have broken onboard Intel Wifi and Bluetooth controller on Gigabyte B450 Aorus Pro Wifi motherboards. 5.4.0-41 (proposed) and -40 (updates) continue to work fine.
<Kon> Not even my system though, just helping a friend troubleshoot. Thought I should mention it
<juergh> @Kon, https://bugs.launchpad.net/ubuntu/+source/linux/+filebug would be a start
<Kon> Didn't think proposed would go there, but okay
<Kon> Honestly that category is such a mess this channel probably has more visibility
<juergh> @Kon, just mention the kernel version in the description so that we have it on file.
<juergh> we have bots that troll launchpad so we'll notice new bugs that are filed against the kernel. stuff tends to get lost in IRC.
