#ubuntu-kernel 2005-06-27
<fabbione> morning
<jbailey> Fabio!
<jbailey> fabbione: I have kernelish things to pester you about too re: initramfs. =)
<fabbione> jbailey: sure.. go ahead
<jbailey> Part of what I want to do is have the kernel ship bundles of things to be included in the initramfs - Like a collection of ide drivers in a cpio file, or scsi drivers, or net/nfs drivers, etc...
<fabbione> hmmm ok
<fabbione> why do you need it shipit in a special way?
<jbailey> I want to take the logic of choosing the drivers to include out of the hands of the initramfs and have it assemble the initramfs from bundles that exist on the system.
<jbailey> The eventual goal is that grub or whatever bootloader should be able to assemble them at runtime.
<jbailey> So there's no work to be done by mkinitramfs at all on each kernel install.
* fabbione scratches his head
<jbailey> Remove the generation step completely.  That's a future.
<jbailey> Have you looked at the initramfs stuff at all?
<fabbione> i am not sure i understand ....
<fabbione> just give me a sec... brb
<jbailey> Sure, or I can come back in 6 hours to talk then.  I should go to sleep. =)
<fabbione> re
<fabbione> no i didn't look at initramfs at all yet
<fabbione> i know you need modules.. that's crystal clear :)
<fabbione> what i don't understand is why the kernel should select them for you
<fabbione> it sounds a lot like creating a udeb
<jbailey> Which I also think the kernel package should do...
<jbailey> But yes, along the same lines of it.
<fabbione> and how do you want me to ship what?
<jbailey> Basically gzip'd cpio files.
<jbailey> Of the modules that would be interesting for booting.
<fabbione> yes ok.. but what modules?
<jbailey> That's the part that I have to work out with you. =)
<fabbione> ah ok
<jbailey> I have some guesses. =)  I need more eyes on the problem to get it right.
<fabbione> ok..
<fabbione> because it sounds like a subset of udeb modules
<jbailey> It might be, or it might be the same set, and there might be a sane way of merging the two ideas.
<jbailey> Colin and I chatted a bit about the idea that udebs should just be cpio files in Sydney.
<jbailey> If that were the case, they could be merged perfectly.
* fabbione smells good crack
<jbailey> I don't expect we'll get it right for Breezy, but I'm hoping we can get it close. =)
<fabbione> let's plan a meeting between the 3 of us?
<jbailey> Tomorrow (my tomorrow, later today for you..) I'll get a new initramfs-tools up that does all the IDE and SCSI detection correctly, in which case I think the setup should be good for anyone not using lvm or evms.
<fabbione> ok
<jbailey> I don't have either of those running here, so I need someone else to help me test those setups before I inflict them on the world.
<fabbione> i can create test boxes for that
<fabbione> that's easy for me
<jbailey> Cool.
<fabbione> given that probably the default install will be on lvm
<jbailey> Really?
<jbailey> Wow.
<jbailey> Means I should probably learn it. =)
<fabbione> it's simple really.. don't be so scared
<jbailey> I suspect a simple diagram of how physcial volume, to logical volumes, to device nodes all map together would solve it all for me.
<fabbione> sure...
<jbailey> It also doesn't help that the PPC installer pretends to support LVM but doesn't really.
<jbailey> (Missing parted support before)
<jbailey> So the time I spent trying to learn LVM was on a setup that couldn't work.
<fabbione> hda* -> each of them add becomes a pv
<fabbione> all pv are aggregated into one or more vg
<fabbione> you create lvm volumes out of a vg space
<fabbione> lvm volumes are like block devices
<fabbione> pv is basically a tag that sais device hda1 is part of a vg (volume group)
<jbailey> Always aggregated, or sometimes raidN?
<fabbione> you can think of a volumegroup as an aggregation of pv
<fabbione> always.. you don't see them as devices
<fabbione> a vg exports the overall space to lvm
<jbailey> Okay, so an md setup would be on top of the vg?
<fabbione> than you create the "real" device with lvm
<fabbione> i use the other way around
<jbailey> or on top of the volume?
<fabbione> it makes more sense to have lvm on top of raid
<fabbione> but you can do both
<jbailey> Creepy. =)
<dilinger> i thought you could only do it one way
<dilinger> ?
<jbailey> Autodetecting that in the initrd will really suck.
<fabbione> indeed
<fabbione> nah
<dilinger> lvm over raid
<fabbione> let's make an example:
<fabbione> you have 2 partitions... sda1 and sdb2
<jbailey> Well, I will have to recurse through detecting and assembliung until I eventually get something with a filesystem on it. =)
<fabbione> jbailey: it's possible to detect it.
<fabbione> with a very simple C program
<jbailey> Oh good. =)
<fabbione> i can possibly write it for you
<jbailey> Even if you pseudocode if for me, I'd appreciate it.
<fabbione> but there are already tools to do that
<jbailey> That would do too.
<fabbione> jbailey: well basically both lvm and md use metadata on the disk
<jbailey> Although a simple C program might be better to keep the size of the stuff on the initramfs down.
<fabbione> so you just need to recurse a couple of times to undertsand the layoyt
<fabbione> the best way is always to try to detect md before lvm
<jbailey> 'k
<jbailey> Will you be around in 6 hours?
<jbailey> I'm starting to fade.
<fabbione> i will be around till 13:00 UTC
<fabbione> than i need to go out for a couple of hours
<jbailey> Lovely, so I'll have 3 or 4 hours with you.
<fabbione> but i can come back .. that's for sure
<jbailey> Well, this doesn't have to all happen today, but if I can get started on lvm support that would be lovely.
<fabbione> i need to take my wife to the doctor..
<jbailey> I want to put out a wider call for testers.
<fabbione> so i really can't postpone it
<jbailey> jdub is now using initramfs-tools to boot his system. =)
<fabbione> ehhehe
<jbailey> He pointed out some ide booting issues, but after that, I'm guessing that most of the systems out there could sanely boot with the initramfs without touching their configs.
<fabbione> jbailey: i need to get .12 final out.. but i plan to switch to initramfs asap
<jbailey> No worries.
<jbailey> It needs to be the default for .13
<jbailey> I have no intention of fixing initrd-tools to work without devfs.
<jbailey> I'm off to pass out.
<fabbione> jbailey: i am going to kill devfs in .12 soon
<fabbione> we won't get .13 in breezy
<jbailey> dilinger: I'll try to look at the cdbs testsuite email you sent tomorrow.  Failing that, I'll do it while at the summit.
<jbailey> There's enough talks there that I truly just don't understand, I should have hack time. =)
<fabbione> jbailey: let's talk about it later when you wake up :)
<fabbione> good night
<jbailey> g'n =)
<dilinger> jbailey: i committed some small debug changes
<jbailey> away "Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit..."
<dilinger> that were attempts at a cleanup
<dilinger> but alas, bash stupidity kept me from committing the rest
<jbailey> dilinger: Ugh.  Feel free to commit with stuff hardcoded to ${Andres-favourite-shell}
<jbailey> I'll mop it up after.
<jbailey> Zzzz...
<dilinger> good night
* ..[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,1--2.6.12 | if baz merge doesn't work.. your code is ok.. use baz merge --star-merge .. deprecated algo that actually does the right thing
<fabbione> (new playground.. kill the abi number from the branch name)
<fabbione> hey chmj 
<chmj> hye 
<fabbione> chmj: i have started swithing the external-driver to passed.kwatch
<fabbione> and cleaned up the overall
<fabbione> if you want to checkout the playground as in topic :)
<fabbione> it would be nice if you could finish the conversion from external-drivers to passed.kwatch
<chmj> ok 
<chmj> have just been fiddling with sf.net urls 
<chmj> becouse of the way they use mirrors 
<fabbione> chmj: ok there is a way to access always the same as reference.. i just can't remember how
<chmj> fabbione: is there? 
<fabbione> chmj: ?
<fabbione> chmj: is there what?
<chmj> I mean, a way to access specific files 
<chmj> without using the mirrors 
<fabbione> chmj: you can just use always the same mirror
<fabbione> that should be safe enough
<chmj> thats what i'm trying 
<zul> hey
<fabbione> hey zul
<zul> how goes it?
<fabbione> it's going good
<fabbione> working on .12
<zul> i noticed
<fabbione> i think this will be one of the fastest kernel release we will ever make :)
<fabbione> there is not a single patch that doesn't apply
<zul> i did some work on lnsm this weekend
<fabbione> and guess what?
<zul> nifty
<fabbione> NO ABI CHANGE!
<zul> wohoo!
<fabbione> MUHA MUHA
<fabbione> but i am still updating the external drivers
<fabbione> so that might take more time
<zul> heh
<zul> i did some work on non-supported-modules this weekend...almost had it working
<fabbione> ah neat
<doko> fabbione: misdn update?
<fabbione> doko: there is no misdn in the kernel :)
<fabbione> i will look at it after i get .12 final out of the door
<doko> " but i am still updating the external drivers"
<doko> fabbione: thanks
<fabbione> doko: misdn is not even there
<fabbione> doko: so it's not question of updating.. but adding ;)
<thom> fabbione: make ipw2100 work ;-)
<zul> its in restircticed-modules isnt it?
<fabbione> thom: did you test what i asked you?
<fabbione> zul: not all of it
<thom> no, couldn't get it to build
<fabbione> uh?
<zul> fabbione: http://zulinux.homelinux.net/lnsm-rules
<zul> its just me testing kind of
<fabbione> ok :)
<fabbione> you scared me for a second :)
<zul> any comments though
<fabbione> i will need to look at it in details..
<fabbione> and test it..
<zul> sure
<fabbione> why don't you put in baz?
<zul> its doesnt work yet though
<fabbione> so i can check the branch...
<zul> i was going to get it to partially work today then put it in baz
<jbailey> karlheg: My x-chat is full anyway, freenode won't let me join more channels.
<jbailey> Module arguments, good.
<jbailey> It's one of the things I hadn't thought through yet.
<karlheg> It's fairly easy to do.  Instead of a 'for x in ...' it does 'cat file | while read mod args'
<karlheg> I'll send you the patch.
<karlheg> (give me a few minutes)
<karlheg> It's not tested; I've not ever tried to run it, but it's pasted with small edits from a script I know is working.
<jbailey> Cool.
<jbailey> Do you have any questions about the hook scripts?
<karlheg> In mkinitramfs, I'm thinking of .'ing in the 'functions' script, then calling 'run_scripts /etc/mkinitramfs/mkinitramfs-hooks' just before the call to cpio.  what do you think?
<karlheg> I've added 'local-bottom' and 'nfs-bottom' directories to the 'dirs' file also.
<jbailey> If you do that, you should do both /etc/mkinitramfs/mkinitramfs-hooks and /usr/share/initramfs-tools/hooks
<jbailey> Packagies needing to do things should probably drop things into /usr/share rather than /etc...
* jbailey thinks about this.
<jbailey> I guess the package can decide if it's something the user ought to edit or not....
<jbailey> THe trick to remember is that almost all decisions should be deferred until runtime.
<karlheg> Ah, right, so packages can drop in non-conffile ones.
<jbailey> So I'm reluctant to encourage people to write build-time hooks mostly because I'm moving towards the ability to have one initramfs do *everything* needed to boot.
<jbailey> I know it's not completely realistic. but I'd rather people think more in terms of "my module might be always included, and that's a good thing"
<jbailey> And then provide a way for that to be included or not and have those decisions deferred to boottime.
<Mithrandir> jbailey: problem with "this does everything" solutions is that the space covered by "everything" is ever-growing.
<jbailey> Mithrandir: Right, that's why I want to the bootloader to eventually be able to assembly the modules dynamically.
<jbailey> So then the decision to include or remove functionality is left as late as possible and allows for a potentially more recoverable system.
<Mithrandir> jbailey: yeah, and as we discussed in .au, that should be an easy fix for grub.
<karlheg> Software Suspend 2 needs the userui binaries installed in the initramfs, and also needs a hook to run before any file systems are mounted.
<Mithrandir> jbailey: lilo is probably a lost cause, since it doesn't understand file systems.
<jbailey> Right.  So in this case what I'd like to see is suspend2 providing a .cpio.gz file that gets dropped into some useful location that mkinitramfs will (right now) just assemble into the initramfs.
<jbailey> karlheg: Are you aware of how the cpio unpack magic works in the kernel?
<karlheg> So the /etc/mkinitramfs/hooks/ is needed for that.  At hibernate time, it needs it in PATH, at resume, in the initramfs or initrd.
<karlheg> I think it can unpack a series of cpio, each successive one potentially overwriting the one before it?
<jbailey> Right
<jbailey> And you can just cat the .cpio.gz files together to assemble them.
<karlheg> The hook script will copy the needed binary to the TMPDIR, I thought.
<jbailey> So I'd rather that the package just provide the cpio.gz file all bundled together already.
<jbailey> Then the decisions can be made at boot time.
<karlheg> Ah.
<karlheg> ? At boot time?  How does that work?  Wouldn't the decision about what cpio are in the initrd loaded by the bootloader be made at kernel-install time or at mkinitramfs time?
<Mithrandir> karlheg: if the boot loader did concatenate the cpio files, there wouldn't be a need for mkinitramfs.  It would happen when you booted.
<jbailey> Right now, in the legacy case, mkinitramfs has to cat the modules together.
<jbailey> But I don't want any logic around it - I'd really like it to be "You have this package installed, so we include it"
<karlheg> Patch is in the mail.
<karlheg> I just don't like the idea of having to install both a cpio.gz and the binary itself, when all that's needed in the initramfs is the binary and a very short script.
<karlheg> That script would go in /etc/mkinitramfs/local-top or local-premount.
<jbailey> karlheg: We'll probably be doing it for a bunch of other things.
<karlheg> usplash
<karlheg> The hook script approach allows custom logic behind what gets put into the initramfs.  The cpio.gz does not... the hooks are run via 'run_scripts', and are dependancy ordered.  How would you determine the order of catenation of cpio.gz, in case one is meant to shadow another?
<karlheg> Perhaps that catenation should be managed by hook scripts, perhaps using a 'functions' API to simplify the client code?
<jbailey> That would work.
<jbailey> I haven't thought that through beyond my dream that mkinitramfs eventually goes away.
<karlheg> catenate_cpiogz /path/to/my/cpio.gz
<karlheg> ... with the depends stuff above it, and maybe some custom logic too.
<karlheg> how will that work?  The bootloader is already an OS...
<fabbione> jbailey: i think waldi gave me the solution for the kernel problem on new glibc
<fabbione> testing now the linking crap
<jbailey> fabbione: Do tell?
<karlheg> The catenation can be done that way, via a function, and before the TMPDIR cpio is created.  The function will create a temporary cpio.gz, and after the main one is made, will catenate that onto the end.
<karlheg> Then the hooks are there for either method, and don't have to be segregated into pre-cpio, post-cpio.
<karlheg> ?
<karlheg> If that is acceptable, I will implement it if you like.
<karlheg> Coffee beckons...  I shall return \aprox 20 min.
* jbailey chews on the idea.
<jbailey> Sometime you'll have to explain to me why you're up at 5 am. =)
<jbailey> karlheg: +++ scripts/functions 
<jbailey> @@ -1,3 +1,5 @@
<jbailey> +# -*- shell-script -*-
<jbailey> Is that emacs-fu?
<Mithrandir> jbailey: yes
<jbailey> 'k
<Mithrandir> it means shell-script-mode will be active for that file.
<jbailey> Cool.  Been awhile since I used emacs. =)
<Mithrandir> similary, you can have # -*- shell-script; coding: utf-8 -*- to force it to be treated as utf8.  vim has about the same thing, iirc.
<jbailey> I tend to disable all that crap for vim - it tends to guess things poorly for me.
<Mithrandir> which is why you can set it explicitly in the file.
<jbailey> *shrug* apathy.  But if it's useful for him, I'll include it in the patch.
<zul> fabbione: ping
<fabbione> zul: pong
<zul> did you put the .12 on your webpace?
<fabbione> zul: only the orig
<zul> ok..
<zul> can you put up the rest? :)
<fabbione> done
<fabbione> usual rule apply.. get the baz archive after
<zul> thanks
<karlheg> I've got an Ubuntu linux-source-2.6.12 patched up with Software Suspend 2, 1Gb-lowmem, and madwifi.  It builds; I have not booted it.
<karlheg> Q: Why one monolithic patch for Ubuntu linux-source, rather than split patches like the Debian kernel?  (and I wonder how they maintain that.)
<fabbione> A: read the sourse Luke.
<fabbione> all the patches are there ... one by one
<fabbione> you want apt-get source linux-source-2.6.12
<fabbione> not apt-get install linux-source-2.6.12
<karlheg> sure, but in one patch file, rather than split out.  I just wonder whether you find that eaier to maintain, or what?  I've little experience with that kind of work, at this point.
<fabbione> karlheg: the patches are all separated.
<fabbione> karlheg: you are mixing 3 different packages
<fabbione> the source
<fabbione> the install linux-source-2.6.12
<fabbione> and the linux-ubuntu-patch-2.6.12
<fabbione> you want the source
<karlheg> Ah.  Let me try that.  Perhaps it would have been less work to do the patch-up I did yesterday to add Suspend2.
<fabbione> apt-get source linux-source-2.6.12
<zul> uh...ok...suspend2
<fabbione> we won't include it anyway
<karlheg> What tools do you use to maintain a kernel source package with associated patches?
<zul> vim mostly..:)
<karlheg> I know; I think it should be the one used.
<fabbione> karlheg: apt-get build-dep linux-source-2.6.12
<karlheg> I like it a lot better than the default.  Have you tried it?
<karlheg> (recently, with userui?)
<karlheg> Ok...  I'm running 'apt-src install linux-source-2.6.12' right now.
<fabbione> no
<fabbione> apt-get source linux-source-2.6.12
<karlheg> I like apt-src better.  Have you tried it?
<fabbione> no..
<fabbione> i usually edit stuff directly in the .diff.gz
<fabbione> i rarely need to get the unpacked source
<thom> fabbione: why does 2.6.10-34.2 not have any of the abi stuff and why isn't it in arch? :P
<fabbione> thom: it's in arch
<fabbione> and the abi is named with the previous version
<fabbione> thom: you just baz mv that dir to the version
<zul> *sigh* guinea pig is making a mess
<thom> fabbione: 34.1 is in arch, i can't see 34.2
<fabbione> thom: just baz mv 34.1 to 24.2
<fabbione> meh
<fabbione> 34.2
<karlheg> fabbione, wow, and with 'echo' and 'cat', right?  You would never use 'ed' or any of those other sissy tools.
<fabbione> the abi files for 34.2 are generated at build time. since there was no abi change, you can safely copy the old ones
<thom> fabbione: dude. there's  kernel-debian--mainline-2,6,10-34,1--0/  ; no 34,2
<fabbione> karlheg: sed is my friend
<thom> this is what i mean
<fabbione> ops
<karlheg> (reads fast, doesn't need 'more')
<fabbione> thom: i think i might have forgot to tag it?
<thom> tsk tsk
<fabbione> thom: gimme a sec...
<fabbione> thom: did you get the last mail from pitti?
<karlheg> Anyone ever thought of trying to load a software speech synth in the initramfs or initrd... will that work with 'speakup'?  I wonder how feasable that is.
<jbailey> karlheg: Easy.  Add an audio module to the initramfs, and a binary to do the console to speech work.
* fabbione falls asleep on baz
<jbailey> karlheg: I don't see that as any more annoying, really, than the fact that usb keyboards aren't built in.
<jbailey> (And I suspect that frame buffers will eventually go into the initramfs too)
<thom> fabbione: todays one? yes
<fabbione> thom: ok
<zul> inotify updated
<jbailey> zul: You just like pain, don't you?
<zul> i live in ottawa dont i? :)
<jbailey> Right.
<jbailey> Are you coming to gcc summit?
<karlheg> There seems to be some relatively new code concerning support for usb-legacy mode?
<fabbione> zul: slow down boy... i am working on updating drivers too
<jbailey> I've just finalised my ride up there tomorrow and back on Saturday.\
<karlheg> Does that give Linux usb-legacy via BIOS or something?
<zul> jbailey: i wish..dont have the money
<fabbione> zul: please keep working on the l-n-s :)
<zul> meh..
<zul> :)
<jbailey> karlheg: Dunno.  I install the drivers, and I hope it works. =)
<fabbione> zuk: i will merge the inotify but i need to do some other stuff before that
<karlheg> I'd rather use HID of course...  I did not look at it long; still reading prereq to really comprehend it.
<fabbione> s/zuk/zul
<zul> uh someone changed external-drivers on me
* karlheg is a Junior CS student.
<fabbione> zul: no shit.. i told you i was updating everything
<fabbione> zul: external-drivers is dieing
<fabbione> read the changelog
<zul> :P
<fabbione> we are switching to passed.kwatch that will take a more decent named after we finish the conversion
<zul> k cool
<fabbione> i also have some changes pending here that i can't commit until concordia is up and running again. they need to be test-builded
<fabbione> so leave the drivers alone until i am back in 2 hours :)
<zul> noooooo..:)
<zul> jbailey: but we will have to have lunch when you come up
<jbailey> Cool. =)
<fabbione> thom: almost done... baz is on slow crack today
<fabbione> thom: kernel-team@ubuntu.com--2005/kernel-debian--pre34,3--2.6.10 <- all the abi/changelog/00list files work is done. you only need to add the patches, build, test and upload.
<fabbione> i need to run
<fabbione> bbl
<thom> fabbione: ah, rock. thanks
<zul> ewww...thats a big lass http://www.thepowerteam.com/roster/jclark.htm
<thom> zul: i don't even want to know how you found that
<zul> it was on tv
<karlheg> Where can I read brief wrt 'abi' ?
<karlheg> My guess is it has to do with glibc builds and sys_* ?
* jbailey blinks
<jbailey> Wha?
<jbailey> karlheg: Which abi are you refering to?
<zul> karlheg: uh not exactly..
<zul> *sigh* stop upload gcc...its hurts :)
<jbailey> this sentence no verb.
<jbailey> try again?
<zul> man...i need breakfast...bbl
* jbailey hands a couple uppers to chuck.
<zul> that would do nicely
<karlheg> :-)  I'm looking at the kernel source debian/abi and rules.
<karlheg> 'read' <-- verb.
<jbailey> zul: I think it's interesting that we tend on a legalisation side of downers: codeine, alcohol, marijuana.
<jbailey> zul: But the only upper we allow is caffeine.
<zul> i havent had any caffine in like a week
<jbailey> Nice!
<zul> not really..
<jbailey> I haven't had any in a decade and don't miss it now.
<jbailey> The first two weeks were hell, though.
<zul> its not by choice ;)
<zul> my wife is evil
<zul> i dont think she loves me sometime ;)
<jbailey> My wife passed by, read over my own shoulder and commented that it's probably for your own good.
<jbailey> (She has a coffee in her hands)
<zul> :P
* karlheg raises my cup to jbailey's wife.
<jbailey> karlheg: So do you stay up all day too? =)
<karlheg> Sure.  Or else I won't sleep all night again.
<karlheg> My clock is off from weekend all-nighters.
<jbailey> Ah.  I was thinking that perhaps you were an overnight sysadmin at the school.
<karlheg> No.  Just a wanna-bee programmer...  It's the beginning of summer break, and I've finally got enough free time to get after some things I had no time for during school term.
<karlheg> I have more projects than I can finish over the summer...  and a pile of books I need to read.  I wanted a new kernel, to try latest Suspend2 and started working on that.  I learned about initramfs when I tried fbsplash, along with the fbsplash support in Suspend2 and it's fb userui.
<jbailey> Right, I understand.
<jbailey> I can't remember the last time I had fewer projects than spare time. =)
<karlheg> I wonder how you folks go about creating and maintaining all of those dpatch files?  Do you work with multiple kernel source directories, or what?  Is there a writeup?
<karlheg> I'll look in dpatch doc...
* dilinger feels the caffeine start to take effect
<jbailey> g'm Andres. =)
<zul> karlheg: there is a README.NMU in the debian directory start there
<karlheg> Check (done)
<zul> and then look at an example dpatch
<dilinger> jbailey: 'morning
<lamont> mooorning
<jbailey> Heya LaMont!
<zul> hey lamont 
<zul> hmmm...reports of 2.6.12 haning on udev
<jbailey> Eh?
<jbailey> udev is just an app, how would it hang?
<zul> http://lkml.org/lkml/2005/6/18/19
<jbailey> Dear user, learn to use strace, figure out what's hanging.  udev has no magic in it.  kthxbye.
<zul> heh
<zul> or http://lkml.org/lkml/2005/6/18/41
<zul> fabbione: the baz stuff is in my arch
<zul> er...the non-supported modules stuff
<fabbione> zul: ok
<fabbione> jbailey: apparently 2.6.12 final needs a version of udev that's not even in sid.
* netjoined: irc.freenode.net -> orwell.freenode.net
<fabbione> zul: out of curiosity... before updating inotify.. did you actually check the there are already 3 versions more out?
<zul> yeah...i got -10
<fabbione> and there is -13 out :)
<zul> bugger
<fabbione> ahhaha
<fabbione> ok don't worry... keep working on the lnsm stuff
<fabbione> i will take care of the drivers :)
<fabbione> (also because i want to try to avoid to bump the abi this time ;))
<thom> fabbione: can you quickly verify something for me; i don't think can-2005-1764 is applicable to hoary; changeset is here: http://tinyurl.com/aq3zr
<fabbione> thom: checking
<zul> fabbione: i have a lnsm-install-686 i was wondering how to create a deb out of it
<fabbione> zul: hint: instead of doing the work in debian/build...
<fabbione> add the linux-n-s-m in debian/control
<fabbione> meh right
<zul> cp the files to the linux-n-s-m
<fabbione> nevermind
<fabbione> dpkg-deb is what you need but there is more that needs to be done there
<zul> you need to remove the drivers from linux-image as well though
<fabbione> exactly..
<zul> bag
<fabbione> that's why i need to look at it in details
<zul> bah..even
<fabbione> thom: it looks to me that hoary is not affected.
<fabbione> thom: apparetntly somebody did a mistake across the development
<fabbione> thom: and reverted adding a - 4096 instead of the value of TASK_SIZE we have in hoary
<fabbione> probably the one in git is more readable..
<thom> yeah
<thom> thanks for the confirm, i'm leaving well alone then :-)
<fabbione> thom: i think that's the same bug Herbert says it doesn't apply in warty
<thom> fabbione: it is, yes
<fabbione> thom: but i am pretty sure i did forward the mail to you
<fabbione> perfect
* fabbione ^5s thom
<thom> thanks dude
<zul> meh...another one today
<fabbione> interview?
<zul> yeah PHP developer
<dilinger> my condolences
<zul> thanks...they think my starting pay is high...well see...
<fabbione> Dear PHP Developer, die. kthxbye
<zul> hey!
<dilinger> Dear PHP Developer, please fork php and make it not suck.   Thank you.  Sincerely, Everyone Who's 
<dilinger> Ever Dealt With PHP
<fabbione> haha
<Mithrandir> dilinger: a) kill it off b) kill all the developers who've ever touched it.
<dilinger> Mithrandir: c'mon, there are plenty of developers that touched it that didn't  mean to.  they were drunk.  or young and naive, and stupid.  or both.
<Mithrandir> dilinger: ok, excuse those, but kill the rest.
<dilinger> good plan
<Mithrandir> dilinger: and I did (at first) intend to just kill those who've touched php's code, not php code.
<zul> dilinger: *ahem* im none of the above
<karlheg> zul, have you ever used or looked over HTML::Mason ?
<karlheg> (OT)
<karlheg> jbailey, I've got only a little more to go on that, and I'll send you another patch.  Have you made changes today?
<karlheg> If not, I'll just send a replacement diff.
<karlheg> ... for your review and approval.
<jbailey> I have not, I just got back from a meeting that I've been at for the last 3.5 hours
<karlheg> Question: When the run_init is called, the /dev filesystem is mounted in /, right?  And run_init nukes the ramfs /, then chroot chdir / into the new rootfs... but where is /dev now?
<jbailey> /dev isn't mounted, it's just a directory.
<jbailey> Since / is a tmpfs, there's no need for a seaparate /dev
<karlheg> I'm confused about the semantics of the MS_MOVE mount, I guess.
<jbailey> MS_MOVE literally moves the mount of the /root filesystem on top of /
<karlheg> So the run_init will remove the /dev directory and contents?
<jbailey> Right.
<karlheg> How can it do that if anything has a device open?
<jbailey> There's nothing left on the / filesystem at that point.
<jbailey> Nothing is holding the inode in /deb open at that point.  It's all in-kernel
<jbailey> So the kernel doesn't care if I remove the deivce node, it's got everything it needs.
<karlheg> But there may be running processes that have devices open... ?  Hmmm... I supposed that something like usplash can simply close the fb before the run_init.
<jbailey> Right.  Haven't got as far as usplash yet.  It would probably have to do something like that, though.
<karlheg> Ah, the refcount goes down, it's still there, but invisible?  But won't it keep the file system busy?
<karlheg> "standing on it"?
<jbailey> Nope, the kernel doesn't go through the filesystem to talk to its own devices - that would be inefficient.
<karlheg> "literally moves" means what?  cp -a ?
<karlheg> I think I'll have to UTSL to "get" this one.
<jbailey> Umm, how to describe.
<jbailey> The effect of the MS_MOVE is that the filesystem is now as if it were mounted on / instead.
<jbailey> Apparently overmounting like this makes it so that kernel threads that do rely on the filesystem don't have to have crazy magic applied to them.
<karlheg> Uhh... so if anything has /dev/console open on it's stdin / stdout, the device inode has a refcount.  Even if you rm the device file, it's still "there", I think.
<jbailey> It depends.  For userspace applications, yes.
<jbailey> If something inside the kernel is using the device, it's no big dealk.
<karlheg> Oh!  That's what it is when I see that /dev/root stuff and there's two mounts shown for / in /proc/mounts?  So that /dev can just stay there until it's closed?  But what about freeing the ramfs... I guess when it's empty, it's free anyhow.
<jbailey> So for right now, no process is accessing those devices, so we can delete them and their refcount is zero.
<jbailey> Right.  The kernel will reduce the memory used for the ramfs with no penalty.
<jbailey> But ideally nothing should keep a ref open to something in /dev.  The FB and /dev/console are the two things I can think of, and hopefully those can be released for long enough to fire up run-init, and start their stuff once udev is running on the other side of init.
<karlheg> Perhaps /dev should be a mount point and move mounted into the real root under a different name, say, "/tmp/initramfs-dev",, and then a later-in-the-boot sequence script can clean it up when all procesess that had devices there open are done.
<jbailey> That's a possibility that hasn't been necessary so far.
<karlheg> Any new opens will happen in /dev, which is shadowed by udev's ramfs anyhow...
<karlheg> Perhaps the 'refcount' I'm thinking of does not really happen with device inodes?  I'd better look at the kernel source and learn how that works.
<karlheg> If the move mount of /dev happened, it would anyway get shadowed by udev just as the hard-drive /dev does, I think.  Perhaps the devices open from inside initramfs /dev can be shadowed in a similar way...
<karlheg> They can remain open, but are no longer visible to 'ls'.  The leakage of resources is probably very minor, like a few pages of virtual memory at most, and the physical pages would get reclaimed soon enough anyhow?  or a struct for that ramfs that never can go away, or can it?  What happens to it when we MS_MOVE mount on top of it?
<zul> heylo
<zul> whoa...one of my patches made it into 2.6.12
#ubuntu-kernel 2005-06-28
<jbailey> zul: Which one?
<zul> it was included in the kernel-janitors patchset
<jbailey> Cool.
<jbailey> Has someone come up with a full changelog yet? =)
<jbailey> I don't actually care enough to assemble it myself, but I usually learn alot from them.
<zul> yeah there is one in the debian directory
<jbailey> Ah.  I haven't done an upgrade since Friday.
<zul> i think fabbione added it this morning though
<TheMuso> /cl/cl
<zul> wheee...install breezy under qemu
<karlheg> Naptime... and turn on the AC.  qemu on my laptop burns 100% CPU and is slow as molasses in January.
<karlheg> I wonder if it can run faster?  It totally emulates, even on native CPU, right?
<zul> uh huh
<karlheg> Bummer.  It would be cool if it did not have to emulate every instruction.
<karlheg> Xen sounds promising.  I've yet to take the time to try it.
<jbailey> Oh, I didn't know qemu fully emulated.
* jbailey wonders whatever happened to the bochs+plex86 combo.
<karlheg> jbailey, dunno.
<karlheg> jbailey, Hey, I'm wading through the kernel right now, learning about the file system and such;
<karlheg> http://www.win.tue.nl/~aeb/linux/lk/lk-8.html
<karlheg> ... to find the answers to the questions I had earlier wrt what the move mount does.
<jbailey> Cool.  Did it help?
<karlheg> I should have a patch for you by the end of the evening nonetheless.
<karlheg> Yes, but I'm not there yet.
<jbailey> =)
<karlheg> And, it's gym time.  I'm going to take an hour off to go lift weights and think about it.
<karlheg> You don't get to be a giant on cake and coffee... so it's barbells and a steak, then back to reading.
<karlheg> Any ideas before I run?
<jbailey> Other than the immediate one of, "Steak? Eww...."
<karlheg> Ah, sorry.  ^H
<jbailey> =)
<jbailey> I keep forgotting that there are non-vegans in Portland. =)
<karlheg> s/Steak/Solid Food/g.
<jbailey> So so many wonderful vegan restaurants. =)
<karlheg> Sure.
<karlheg> I'm omnivorous.
<karlheg> That means I eat both meat and potatoes.
<karlheg> :-)
<jbailey> *lol*
<karlheg> L8r on.
<zul> jbailey: http://zulinux.homelinux.net/Screenshot.png
<fabbione> morning
<fabbione> BAH
<fabbione> no wonder there was no ABI difference....
<fabbione> the ABI checker didn't realize we were working on the same version but a different revision
<chmj> fabbione: mirror suppport for uscan-modules done gonna push the last update to kwatch as soon as I finish updateing the url's 
<fabbione> chmj: cool
<zul> hola
<chmj> bonjour chuck 
<zul> hey chmj how goes it?
<fabbione> hey zul
<zul> hey fabbione 
<zul> so udev hasnt entered experimental yet?
<chmj> zul, good u ?
<zul> tired...just got up
<fabbione> nope
<zul> meh..
<zul> how are the drivers coming?
<fabbione> zul: working on them.. but not top priority
<zul> cool
<fabbione> zul: specially because i figured 2 problems.. the abi checker was not checking and the udev stuff
<zul> yeah the udev stuff is going to be fun...i blame foobar
<fabbione> ok.. Md did shed some light
<fabbione> we can upload .12 with our udev
<fabbione> the only results are slow down at boot
<zul> yay! :)
<fabbione> once we get the new version of udev, everybody will have to upgrade to kernel .12
<fabbione> because it's not backward compatible
<fabbione> so we don't have too much time to fix the overall
<zul> crappers
<fabbione> score!
<fabbione> 8 FTBFS fixed :)
<chmj> sweet 
<jbailey> Feh.  Everyone repeat after me:
<jbailey> Don't include linux/config.h in userspace applications.
<zul> wtf? :)
<jbailey> Relying on what you think is included in the kernel is a bad idea in a distribution.  always do runtime tests.
<fabbione> jbailey: iptables?
<jbailey> fabbione: Yes.
* fabbione sighs
<chmj> ftbfs 
<jbailey> Rception de: 2 http://archive.ubuntu.com breezy/main iptables 1.3.1-2 (tar) [1283kB] 
<jbailey> 1284ko rceptionns en 15s (83,8ko/s)
<jbailey> dpkg-source: error: unrecognised file suffix `.tar'
<jbailey> WTH?
<jbailey> I don't drink enough for this.
<chmj> jbailey, dpkg is broken 
<fabbione> ./uscan-extmod --report --watchfile passed.kwatch .
<fabbione> Processing ./passed.kwatch ......
<fabbione> uscan-extmod: Malformed file url mangler
<fabbione> chmj: ^^
<jbailey> chmj: Is there a suggested work around?  Like, will I be able to build packages?
<chmj> <Kamion> probably best wait for the dpkg fix, or get the patch off Keybuk and test it
<chmj> fabbione, oh yes, the file format changed a little 
<fabbione> chmj: well.. you need to update the passed.kwatch too dude...
<fabbione> or tell me exactly how it did change
<chmj> hold on 
<jbailey> chmj: Yar.
<jbailey> fabbione: I'll try and do iptables a bit later then.
<fabbione> jbailey: no hurry...
<fabbione> i am more concerned about gcc* on ppc at the moment
<fabbione> doko: you around?
<doko> yes
<fabbione> ok
<fabbione> i guess you both remember the mail i did send to you about unionfs for ppc
<fabbione> i did try with gcc-4.0 and it is another ICE
<chmj> fabbione, just remove any spaces after the version number, for each line 
<fabbione> jbailey, doko: i suggest that one of you guys look at it directly...
<doko> fabbione: nice :)
<chmj> jbailey: you gonna get the patch off Keybuk? or ask doko if he didn't do it earlier 
<fabbione> on breezy/davis chroot there are all the kernel build-deps
<doko> chmj: ???
<jbailey> chmj: I'm leaving for Ottawa in an hour, I'll just grab it from the archive tomorrow.
<fabbione> you only need to enable CONFIG_UNIONFS to get the ICE
<fabbione> chmj: i am pretty sure i removed all the spaces, but i will check again
<zul> bbl
<chmj> doko: jbailey wanted to know about any workaround for dpkg 
<chmj> fabbione: works, if you remove the spaces 
<fabbione> ok
<doko> fabbione: I'll have a look at it tomorrow morning
<fabbione> doko: ok
<jbailey> doko: If there's anyone I should poke tomorrow, lemme know. =)
<fabbione> jbailey: run the build during a talk.. steal the overhead projector cable and yell: "MY KERNEL MAINTAINER SAYS THAT YOU ALL SUCK! SEE?!?!?"
<jbailey> I'd be scared of pissing of richard henderson.
<zul> yeah then they have riots in the bytowne
<jbailey> He wears steel toe boots to his talks.
<fabbione> ahahah
<chmj> hahahaha
* thom fires off the hoary kernel build
<fabbione> cool
<chmj> fabbione, have you made changes to kwatch ?
<fabbione> chmj: yes.. i removed the spaces as you told me to
<fabbione> and updated a few versions
<fabbione> (hit: running baz update before starting changes is a life saver)
<chmj> yeah, I know, I updated before changing, but that was a while ago 
<fabbione> chmj: second hint: commit more often :)
<chmj> fabbione: sure, I have a reaaaaalllllyyy slow connection 
<fabbione> so do i.. only 2M/512k
<fabbione> i need to get that 100Mb connection to the 10GB city ring
<fabbione> anyway i am off for a while
<fabbione> i am too tired to keep going
<chmj> 2MB, and you complaining ?
* chmj rolls eyes 
<brodmann> i'm trying to extract a .run file, but everytime it extracts to the folder, when it's finished, it deletes that tmp folder
<karlheg> Anyone know how I can get source to jbailey's udev-klibc?  'apt-src' cannot find it.
<karlheg> He's marked away, in transit to conferences.  I'll check his website.
#ubuntu-kernel 2005-06-29
<zul> http://fun.sdinet.de/pics/flamingdrink.gif
<fabbione> morning
<zul> morning
<chmj> morning chuck 
<zul> morning charles
<fabbione> morning chmj 
<fabbione> zul: already up?
<zul> yeah nervous
<zul> call back today
<fabbione> get laid and go back to sleep :)
<fabbione> the former helps for the latter ;)
<zul> that was last night :)
<chmj> hehe
<fabbione> .12 final is almost ready to go out
<zul> cool...mind doing a merge with me if you havent done so...i think im stuck..
<fabbione> zul: what changes do you have pending?
<zul> just the basic lnsm support
<fabbione> zul: i need to release this one today
<fabbione> i will merge for the next one
<zul> ok..
<zul> its not builiding the linux-non-supported-modules deb when i do a debuild
<fabbione> zul: ok. i will merge it after.. i can't break the build now
<zul> i know
<fabbione> AMEN
<fabbione> i think i just got sodomized by a baz bug
<zul> it built
<zul> i think you should do alias baz='cvs'
<fabbione> ah no
<fabbione> pheeew
<zul> okie dokie...http://fun.sdinet.de/pics/flamingdrink.gif
<zul> doh...wrong url
<zul> http://lists.ubuntu.com/archives/ubuntu-devel/2005-June/008364.html
<fabbione> WTF....
<fabbione> AHHH
<Seveas> *ouch*
<fabbione> i don't get it
<fabbione> i apply a patch.. and i can't remove it
<fabbione> if i do it manually works
<fabbione> dpatch fails
<zul> i blame foo
<fabbione> zul: i can't release without that working
<fabbione> and i don't understand wth is wrong
<fabbione> the patch is ok
<fabbione> tested manually
<zul> what is it?
<fabbione> hostap
<fabbione> grab the last baz
<zul> gimme a sec..
<fabbione> edit patches/00list-1.1
<fabbione> remove everything after hostap
<fabbione> make monolith clean
<fabbione> it will fail to remove the same patch it applied as last
<fabbione> that is NOT normal
<zul> god my computer is slow
<zul> im getting the same
<fabbione> yeah i think i got an idea of why
<zul> i did an strace
<zul> stat64("/usr/lib32/libfakeroot/libfakeroot-sysv.so.0", 0xbf98a5c4) = -1 ENOENT (No such file or directory)
<fabbione> i don't see how that can be a problem?
<fabbione> what about all the other patches than...
<zul> i know me either
<zul> there is a couple of *.rej in drivers/net/wireless
<fabbione> that's after it tries to unapply
<fabbione> the thing is that if you do a monolith
<fabbione> and than try to unpatch manually.. it works
<zul> gimme a sec..
<fabbione> ok i am getting closer
<fabbione> the patch is fine
<fabbione> it's make-kpkg clean that mangles something
<fabbione> and makes the patch uninstallable
<zul> ah hah
<zul> crap i need to get ready...back this afternoon
<zul> wish me luck :)
<fabbione> DOH!
<fabbione> 3 files get removed
<chmj> fabbione: is that .12 building ? 
<fabbione> yes
<fabbione> chmj: i solved the problem.. there was somehow 3 files leftover from upstrem
<fabbione> that hitted the patch
<chmj> cool 
<fabbione> last build on ppc and we are done for the day
<fabbione> we only need a name
<chmj> erm 
<chmj> janeW is not here ? 
<fabbione> nope
<zul> grumbling gerbils
<fabbione> chmj: don't you work in the same office with Jane?
<fabbione>   The "$(we don\'t have a name)" release.
<dilinger> what's the naming theme?
<fabbione> dilinger: it was nuts for 12rcX 
<fabbione> so we can start with everything we want
<fabbione> since this is stable
<dilinger> Flying Spaghetti Monster
<chmj> fabbione: janeW said "petulant poppy seed" 
<chmj> for the name
<chmj> I do, but she is not here, she is in jhb 
<chmj> jhb = johannessburg (far north )
<fabbione> dilinger: ahhaa
<fabbione> dilinger: yeah i am reading that too
<fabbione> chmj: meh too long :)
<fabbione> let's make it the Flying Spaghetti Monster
<thom> +1
<fabbione> that's
<fabbione> FSM will be on the way soon
<dilinger> all hail the coming of FSM
* dilinger gets on his knees and worships
<thom> now we just need more pirates
<thom> and the world will be safe again
<fabbione> thom: .12 final should also fix ia64 boot
<thom> oh, sweet
<thom> of course, that actually means reinstalling
<thom> oh, wait
<thom> it's my sparc that won't boot, not the ia64
<thom> i remember now
<fabbione> sparc is no go yet
<fabbione> but at least now i am not the only one with the problem
<fabbione> also debian has the same linking issues
<dilinger> this is the -fstandalone stuff that waldi mentioned, right?
<chmj> hahaha 
<chmj> is it safe to upgrade to breezy ?
<dilinger> i remember yelling at him for filing an RC bug on it for 2.6.8 a while back.  probably would be good to get around to fixing that ;)
<fabbione> he gave him another option the other day
<fabbione> -ffreesomething
<dilinger> yea
<dilinger> freestanding
<dilinger> i forget the actual option
* dilinger checks bugs
<fabbione> i am not sure where to apply that option anymore
<fabbione> but i did add it to sparc64 CFLAGS and verified that was used at build time
<fabbione> but it didn't solve crap
* dilinger sighs.  the debian bts is worthless for kernel bugs
<fabbione> hmm interesting
<fabbione> 2.6.12-2.1 has a free ABI bump :(
<fabbione> oh well 
<fabbione> better one more than one less
<dilinger> there it is, #282269
<fabbione> ah crap
<fabbione> i forgot -sa
* fabbione rbuilds
<fabbione> GET THE CRACK
<fabbione> -2 minutes for katie to run
<Micksa> you've been setting your CPU clock negative again haven't you
* ..[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,1--2.6.12 | if baz merge doesn't blame GTK!
<zul> heylo
* ..[topic/#ubuntu-kernel:zul] : 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,2--2.6.12 | if baz merge doesn't blame GTK!
<jbailey-gcc> zul: Did I miss you at the pub last night?
<zul> jbailey-gcc: nope...last night was my 2 year wedding aniversarry so i couldnt go
<zul> wifey reminded me :)
<zul> ...in a bad way...
<jbailey-gcc> Bwhahahah
<jbailey-gcc> Poor sod.  Far better than if you had actually made it to the bar, though. =)
<zul> yeah but we made up :)
<jbailey-gcc> Luckily, I'm the one who usually remembers our aniversaries. =)
<jbailey-gcc> mmmm..  make-up sex.
<jbailey-gcc> err.
<jbailey-gcc> umm
<jbailey-gcc> How 'bout those Canucks?
<zul> they suck...go sens go
<jbailey-gcc> Traitor. =)
<zul> bah...i been in ottawa nearly a decade
<zul> sooooo...go sens go..
<jbailey-gcc> So being here really does eat your soul after a while?
<zul> yeah...try rideau center
<jbailey-gcc> Rideau Centre doesn't take "a while" to eat your soul.
<zul> no but its immedate :)
<zul> my brain is mush
<jbailey-gcc> So...  Do we attempt to drag you out to lunch, then?
<zul> who is we?
<zul> the debian mafia? :)
<jbailey-gcc> Excellent question. =)
<jbailey-gcc> I'm rooming with a couple Debianers, and a random student at NITI.
<jbailey-gcc> You should be warned that we're an evil group.
<zul> i could go for a beer at elephant and castle
<jbailey-gcc> Simon was still drunk when he got up this morning.
<zul> heh
<jbailey-gcc> By the look in his eyes, I think he's *now* hung over.
<zul> i havent been drunk like that since university
<jbailey-gcc> Well, he made the mistake of saying that Vodka is a tonic.
<jbailey-gcc> So we bought him a gin and tonic.
<zul> lol
<zul> so caring
<jbailey-gcc> That was neither the start nor the end of the evening.
#ubuntu-kernel 2005-06-30
<Micksa> df
<Micksa> er.
<fabbione> morning
<fabbione> morning JaneW
<JaneW> hi fabbione 
<chmj> morning 
<fabbione> morning
<chmj> fabbione: how do i change my tree to the new playground? other than to check out again from scratch? 
<thom> baz switch
<Micksa> oooh, you can do that?
<Micksa> neat
<zul> hehe...http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7abaa27c1c54208bd76fa8bae55839c034aebfb2
<chmj> cool 
<TheMuso> lucky you zul 
<TheMuso> BTW speakup will actually be a while coming. Since the console code in 2.6.12 has been largely rewritten, speakup is not yet ready for it.
<zul> yep i know..
<TheMuso> You on the speakup mailing list or something? :)
<zul> no i have a look at it from time to time
<chmj> kernel mailing list = heavy traffic = isp complained 
<dilinger> gmane holds the answer.  look deep within.
<zul> or even lkml.org
<dilinger> sure, there's no shortage of web archives
<dilinger> but nntp archives?  that's key ;)
<zul> to each to his own ;)
<lamont__> where can one find linux-source_2.6.12-2.6.12.orig.tar.gz, I wonder
<zul> need a copy?
<zul> or you can just do apt-get source
<jbailey-gcc> dilinger: nntp archives good.  Non-sucky nntp-readers..  I wish.
<Mithrandir> jbailey-gcc: gnus.
<Mithrandir> jbailey-gcc: but it runs in emacs which I think you'll find a bit hard.
<jbailey-gcc> I haven't actually tried using gnus for news reading.  I did try it for mail once, which I didn't enjoy.
<Mithrandir> it takes a little while to get used to, but it rocks.
<jbailey-gcc> Huh, cool.
<dilinger> jbailey-gcc: i like pan
<jbailey-gcc> dilinger: Oh, I had forgotten about that one.
#ubuntu-kernel 2005-07-01
<zul> fabbione: you around? probably not..
<infinity> zul : He's taking a long weekend.
<zul> yeah i figured that..
<zul> well im going to bed
<infinity> 'Night.
<mahmoud> hello...I'm recompiling the kernel to add support to the "perfctr" module...it builds and installs fine, but when it boots it complains about a missing "/lib/modules/2.6.10/modules.dep" although it's there...any idea?
<fabbione> did i ever mention NOT to close the door of the office in the summer because the room OVERHEAT!
<chmj> hahahaha
<zul> no i dont think you did
<chmj> yeah, never 
<zul> fabbione: oh yeah i start work tuesday
<fabbione> cool
<fabbione> congratulation
<zul> so i have monday to relearn php 
<zul> thanks..
<zul> now you dont get to hear me whine anymore...well less
<fabbione> don't even think to disappear you little tiny bastard :)
<zul> i wouldnt do that to you :)
<fabbione> good boy
<fabbione> ;)
<zul> :P
<zul> i hanged out with jbailey-gcc on friday aswell
<fabbione> ah nice
<fabbione> did you get to do keysigning?
<zul> nah..he had to go back to the gcc summit
<zul> i had to go get drunk with some college friends
<fabbione> well jeee it takes 1 minute to exchange fpr
<zul> meh...we didnt think of it
<chmj> yeah, beer does that to people 
<zul> actually it was vodka
<chmj> same
<chmj> hehehe
<zul> fabbione: i stole a whole bunch of patches from head this week
<fabbione> zul: i will look at them during the week
<fabbione> i am back only to restore my server
<fabbione> and i am seriously running away screaming from the pc'
<fabbione> today
<zul> im just testing them now they should be in my arch by the end of the day
<zul> hehe
<zul> no hurry
<fabbione> i am off to unload the car while the RAID resync
<fabbione> it failed once already and that's not good
<zul> neato
<zul> i probably wont be around much next weekend since its canada day
#ubuntu-kernel 2005-07-02
<fabbione> morning
<Mithrandir> hiya
<Mithrandir> on a freshly-installed hoary box, I get a loadavg of 6.0 with a set of kernel threads stuck in D
<Mithrandir> : tfheen@rho / > ps ax | grep D PID TTY      STAT   TIME COMMAND 139 ?        D      0:00 [khubd]  182 ?        D      0:00 [kswapd1]  183 ?        D      0:00 [kswapd0]  774 ?        D      0:00 [kseriod]  953 ?        D      0:00 [md1_raid1]  954 ?        D      0:00 [md1_resync] 
<Mithrandir> argh, that was totally unreadable
<Mithrandir> anyhow, khubd, kswapd1, kswapd0, kseriod, md1_raid1, md1_resync.
<Mithrandir> anybody got any bright ideas why they're stuck and how I can get them to unstick themselves?  Rebooting doesn't seem to help
<fabbione> Mithrandir: what arch is that?
<fabbione> it looks like there are disk I/O problems and the raid rsync dies
<Mithrandir> amd64
<fabbione> raid sync
<Mithrandir> /proc/mdstat seems happy
<Mithrandir> hmm
<fabbione>              D      0:00 [md1_resync] 
<Mithrandir> raid1: raid set md0 active with 2 out of 2 mirrors
<Mithrandir> hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
<Mithrandir> hdd: packet command error: error=0x54
<fabbione> that can be a reason
<fabbione> try to disable DMA, make it boot
<fabbione> and see if it works
<Mithrandir> hm, that's the CD-ROM. :-P
<Mithrandir> this is a pure SATA box
<fabbione> hmmmm
<fabbione> can try using the SATA compatibility mode in the BIOS?
<Mithrandir> it doesn't have one, afaik.
<Mithrandir> this is a server, not a toy. :-)
<fabbione> a real server uses SCSI
<fabbione> not SATA :P
<Mithrandir> http://err.no/tmp/dmesg is the dmesg
<Mithrandir> SATA is the new SCSI
<fabbione> a real server uses OLD and WORKING SCSI
<fabbione> devfs_mk_dir: invalid argument.<4>devfs_mk_dev: could not append to parent for /disc
<fabbione> wtf
<Mithrandir> it uses LVM too.
<fabbione> Stopping tasks: ===<6>md: md_do_sync() got signal ... exiting
<fabbione> ==<6>md: checkpointing recovery of md1.
<fabbione> =
<Mithrandir> hmm
<Mithrandir> so twiddling to get around that should fix it?
<fabbione> what controller is that?
<Mithrandir> sii3114
<fabbione> i am not sure.. but clearly the devfs_mk stuff is not normal
<Mithrandir> fwiw, I see the same on a similar box which does not have the problem with load.
<Mithrandir> hmm, I'll try rebooting it now that the raid is synced and such.
<Mithrandir> ok, so _something_ funks up the resync
<Mithrandir> I'm not sure what, but the reboot made it resync one of the raids
<fabbione> is it still stucked?
<Mithrandir> nope, but it resyncs the raid now.
<Mithrandir> if you look at the previous dmesg, it does:
<Mithrandir> Stopping tasks: ===<6>md: md_do_sync() got signal ... exiting
<Mithrandir> ==<6>md: checkpointing recovery of md1.
<Mithrandir> = stopping tasks failed (1 tasks remaining)
<fabbione> yup
<Mithrandir> while the last restart worked.
<fabbione> hey jbailey
<jbailey> Heya Fabio!
<fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=12040
<fabbione> jbailey: unfortunatly it is an initrd-tools problem
<fabbione> i am going to add info on it, but we need it fixed asap
<jbailey> fabbione: I don't have enough info here to see what the problem is....
<jbailey> Is it the usual round of glibc fuckage?
<fabbione> i just added them :)
<fabbione> nope..
* jbailey reloads
<jbailey> Sure, this is just another driver alias thing.
<fabbione> jbailey: remember that the megaraid still remains..
<fabbione> the driver has been splitted in 2
<fabbione> old and new...
<fabbione> but i dunno how to fix that in mkinitrd
<jbailey> There's a massive sed table in /usr/sbin/mkinitrd
<Mithrandir> fabbione: I need to see if I can reproduce this problem, but it went away after the fully-synced system had booted.
<fabbione> jbailey: yes, but this is not a rename or an alias
<fabbione> Mithrandir: it's rather strange because i do usually test installs on raid
<Mithrandir> fabbione: and LVM?
<fabbione> yup
<jbailey> fabbione: Oh, sorry, I see.
<Mithrandir> fabbione: hmm, anyhow, I'll see if I can reproduce it
<fabbione> Mithrandir: i do all kind of stuff here :P
<jbailey> Sorry, I thought you mean megaraid for old kernels and megaraid_mbox for new ones.
<fabbione> Mithrandir: lvm is not related to that
<jbailey> I'm still sleepy. =)
<fabbione> jbailey: ehehe no
<fabbione> we splitted the driver
<fabbione> so that all the cool stuff is from the new one
<fabbione> the only 2 old controllers are supported by the old one
<fabbione> (since the new one doesn't)
<jbailey> Should I just modprobe the new one first and the old one second?
<fabbione> jbailey: that would be fine.. yes
<fabbione> we also have a test box...
<jbailey> Lovely.
<fabbione> so if you want we can test the fix
<jbailey> When I've cleared the cobwebs out of my head, I'll make a test package.
<jbailey> Was up very late for a city-wide party last night.
<fabbione> ehhe
<fabbione> it's enough you give me the modified mkinitrd file
<fabbione> we can package it later :)
<zul> jeua
<zul> doh...heya
<zul> fabbione: when you get around to it can you do a merge kthxbye
<fabbione> zul: fix your archive. kthxbye
<fabbione> baz abrowse zulcss@gmail.com--2005
<fabbione> ^^stall
<zul> fudge
<dilinger> i have serious slowdowns switching between workspaces in hoary's X.  not sure if this is xorg or kernel being crap :(
<dilinger> fabbione: ubuntu-kernel list
<dilinger> Subject:      [ghall@research.dfci.harvard.edu: Re: qlogic] 
<fabbione> dilinger: yes.. we just started compiling it again
<fabbione> it's in the vanilla kernel
<dilinger> fabbione: it's not actually distributable
<fabbione> it might not be DFSG free...
<dilinger> http://wiki.debian.net/?KernelFirmwareLicensing
<dilinger> (i need to update that wrt to qlogic, but i've talked to their lawyers a bunch, and they're going to dual license the firmware.. gpl/bsd)
<fabbione> dilinger: well the point is simple
<fabbione> there are some kernel developers that are making real crusades towards non GPL code
<fabbione> so if it is still there, i think it's usable
<dilinger> no
<dilinger> this is a different matter
<dilinger> this is GPL'd firmware
<dilinger> the GPL defines source as "preferred form for modification"
<fabbione> is the firware within the kernel?
<dilinger> which binary firmware is not
<dilinger> yes
<dilinger> qla2300_fw.c
<dilinger> and friends
<dilinger> that's why we strip it out of the kernel
<dilinger> along w/ tg3
<dilinger> and a few other drivers
<dilinger> tg3 is cleared up in 2.6.12; we worked w/ broadcom
<dilinger> we're working w/ qlogic, and qla2xxx should be good to go soon
<dilinger> the other 6 drivers we strip are looking hopeless
<dilinger> but they
<fabbione> well i am already shipping them..
<dilinger> 're not as widely used
<fabbione> tg3/qla
<dilinger> ok, well..
<fabbione> also the drm stuff
<dilinger> drm?
<fabbione> mga (drivers/char/drm):
<fabbione> ^^drm
<dilinger> ok, that's fine
<dilinger> that's a different issue
<dilinger> DFSG-compatibility is the reason why that's listed there
<fabbione> anyway.. i will look at it again another day
<fabbione> i am way too tired to think about licence and firmwares
<dilinger> this isn't about DFSG-ness, this is about undistributable code
<dilinger> ok
<fabbione> they should all just die
<dilinger> 'night
<dilinger> heh
<fabbione> :)
#ubuntu-kernel 2005-07-03
<zul> gday
<fabbione> morning
<chmj> morning 
<fabbione> zul: the external-drivers-net-usb_zd1211 is broken
<fabbione> zul: the external-drivers-net-usb_zd1211 was broken
<zul> fabbione: ok...you didnt include any patches that i stole from git?
<fabbione> zul: no. because they are all pending in 2.6.12.2
<zul> ah ok
<fabbione> i am fighiting with alsa now.. because it breaks
<zul> what breaks?
<fabbione> docbook creation. there was a wrong macro in include/sound/pcm.h
<fabbione> already fixed.. but it requires a full rebuild for testing
<fabbione> food
<fabbione> :)
<zul> ok dont know if im going to be around much today...first day of work
<fabbione> zul: have fun
<fabbione> i am going to upload the kernel and do some gardening afterwards
<zul> gardening?! hehe
<fabbione> the emperor^W^Wmy wife decided that she doesn't like elephant grass
<chmj> I'm trying not to ask what elephant grass is/looks like 
<fabbione> bamboo
<chmj> oh, no such think in za :) 
<chmj> s/think/thing/
<jbailey> <abentley> jbailey: any idea why the standard Ubuntu kernels don't include the intel8x0m module?
<jbailey> <jbailey> abentley: The 'm' is the modem module, right?  I think there's an alsa driver that's supposed to cover for that instead.
<jbailey> ANything else I should add?
<fabbione> it's there by default
<fabbione> if he wants the oss version he needs to do some magic
<fabbione> snd-intel8x0.ko and snd-intel8x0m.ko
<fabbione> the latter is the modem support
<fabbione> for audio he wants the first one
<jbailey> Yeah, it's the modem he wants, thanks.
* ..[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,3--2.6.12
<fabbione> (it's not there yet.. it will be in a few minutes)
<jbailey> Bah, I need to install topicdiff again.
<fabbione> changed the playground and removed the baz thingy
<fabbione> ok last commit signed.. i am off
<fabbione> later
<zul|work> hey
#ubuntu-kernel 2006-06-26
<nigel_c> BenC: Suspend2 git tree is up: http://www.kernel.org/git/?p=linux/kernel/git/nigelc/suspend2-2.6.git
<fabbione> nigel_c: i suggest you send him a mail
<fabbione> at this time he is probably asleep
<nigel_c> Ok. Ta.
<fabbione> no problem
<fabbione> it's just a more reliable way to make sure he will get the message :)
<nigel_c> :)
<jbailey> BenC: Any feel as to whether or not hpa's klibc patch is likely to make it into Linus' tree?
<jbailey> It's in -mm now, and I'm wondering if klibc should get integrated into the kernel builds as well.
<fabbione> jbailey: you can ask hpa directly
<jbailey> hpa will be a bit biased, won't he? =)
<fabbione> he is a nice guy :) try #linux-cluster here or you know where
<jbailey> Sure, I've spoken to him lots.
<jbailey> But I *know* that he thinks it's going into Linus' kernel.
<fabbione> plus nothing stops us to pull it in indipendently of what linus does
<jbailey> I'm looking for other people's opinions. =)
<jbailey> Sure, but we've already got it as anindependant package.
<jbailey> The only advantage of merging it early for us is to keep it up to date as part of the upstream merges anyway.
<jbailey> Otherwise it's just adding more work for ben unecessarily.
<fabbione> git pull is hardly extra work
<zul> hey
<fabbione> hey zulligno
<zul> hey fabbionito how is it going?
<fabbione> i am fighting with openais framework
<jbailey> fabbione: Sure.  But since it's not me doing the work, I'm asking Ben. =)
<jbailey> That whole being polite thing. =)
<fabbione> jbailey: yeah yeah...
<fabbione> A L L   E X C U S E S
<zul> quebecers are so polite...until they want to seperate :)
<zul> oh hey jeff 
<jbailey> zul: Yeah yeah, you can complain.  But remember - the reason you don't have problems with 18 year old drunks in Ottawa is because we import them from you. ;)
<zul> lol
<zul> keep 'em
<jbailey> Meh.  I'm getting old enough that 18 year olds don't look so cute anymore.
<zul> dirty dirty old man
<jbailey> Or at least, not once they open their mouths to talk...
<jbailey> ;)
<zul> crap...i have to head off to work...bbl
<stefg> Just a quick yes/no question: I got nothing but trouble with the current dapper-kernel (2.6.15-15-k7), so I'm willing to try one of the daily builds. Since there are no 'restricted' -packs available for that: Will I be able to get an Nvidia-driver installed with module-assistant?   
<stefg> *(2.6.15-25-k7) that is, of course *
<zul> hey
<zul> BenC: i have some patches for you ill send tonight
<zul> just 4 more days until the long weekend
<BenC> zul: ok, thanks
<zul> some bug fixes and enhancements for both dapper and edgy
<zul> oh you know the thing we were talking about if there is an oops tell the user to open a bug in launchpad? thats partially done as well
<zul> however im not sure how to test it
<fabbione> hey BenC 
<fabbione> BenC: did you see that mail from bubba?
<BenC> yeah, are we messing the PCI ID's that you added in breezy?
<fabbione> BenC: probably.. but i didn't check
<fabbione> he is wining on lwz about mysql stuff too
<fabbione> but his installation is nuts
<fabbione> he did a noninteractive distupgrade from warty to dapper or something
<fabbione> and the world did fall down a bit
<fabbione> i am off
<fabbione> cya later
<bubba> BenC: you there?
<BenC> bubba: yeah
<BenC> bubba: I'm checking the PCI id's in dapper against breezy, I should have it straightened out next kernel (couple of days)
<[g2] > has anybody tried the SD support in 2.6.17 ?
<bubba> BenC: you rock, as usual
<bubba> should i have megaraid or megaraidlegacy in mkinitramfs/modules ?
<nigel_c> Schwarzer's earning his pay.
<nigel_c> Oh. Wrong channel. Sorry :)
<nigel_c> The first attempt didn't get through, so I'll go slow :)
<nigel_c> Bah. Again :)
<nigel_c> Maybe I should go to bed :)
<zul>  hey mdz 
<zul> BenC: ping
<zul> meh...im off home..
#ubuntu-kernel 2006-06-27
* Starting logfile irclogs/ubuntu-kernel.log
* Starting logfile irclogs/ubuntu-kernel.log
<zul> yo
<chmj> yo
<zul> hey chmj how goes it?
<chmj> I'm good 
<chmj> and busy 
<TheMuso> c
<zul> BenC: ping
<BenC> zul: pong
<zul> BenC: did you have a look at pitti's email? i could handle the security updates if you want
<BenC> zul: I'll do the dapper ones if you want to handle the other two
<zul> sure
<zul> and ill send you my patches tonight, i got sidetracked by xen stuff
<zul> the 2.6.16.13 version almost builds ;)
<BenC> infinity_: ping
#ubuntu-kernel 2006-06-28
<zul> hey
<zul> wohoo...vmlinux with xen
<zul> now i just have to figure out how to make the debs
<BenC> infinity: I have a linux-source-2.6.17/l-r-m-2.6.17/linux-meta trifecta to upload
<BenC> I updated nv-legacy to the latest 7182 binaries
<BenC> haven't done the madwifi thing yet, but I want to get this upload out in the wild
<infinity> BenC: Whoa, they released a new legacy?  Be still, my beating heart.
<BenC> finally included all the patches that were floating around
<infinity> BenC: Does it include any of the new binaries/libs that were in -new but not -legacy?
<BenC> not sure
<infinity> Would it be much trouble to ask you to throw that at me (or chinstrap) instead of the archive, and I can poke it and upload it?
<infinity> (Paranoid, you see)
<infinity> I'm working for the next few hours, so I have the time.
<BenC> wont be uploading till tomorrow
<BenC> need sleep, and finishing a final test build
<infinity> Well, give it to me now, then, and I'll have it ready for you.
<infinity> (Or I can just upload and let it dep-wait)
<BenC> I can start the upload, but remember, I have a slow connection, so it's going to take awhile :)
<BenC> d81716b1b6c7c53efd6e7afe17032dfa  linux-restricted-modules-2.6.17_2.6.17.1-1.diff.gz
<BenC> f5d398b98efdc81a7e5ac83c1b083ac9  linux-restricted-modules-2.6.17_2.6.17.1-1.dsc
<BenC> 80a08bb242fc53e5ded5fa0df2e7bd59  linux-restricted-modules-2.6.17_2.6.17.1-1_source.changes
<BenC> 9294ffe306aa4a51531905e55a5d3f52  linux-restricted-modules-2.6.17_2.6.17.1.orig.tar.gz
<BenC> going to chinstrap now in my ~/
<infinity> Well, if the only change to the orig is to add the new NVIDIA binaries, you can just send the diff and dsc, and I can recreate the orig.
<BenC> I believe that was pretty much it
<BenC> .diff.gz/.dsc is done
<BenC> tarball I'll leave uploading just in case you need it after I go to bed
<BenC> ETA on the tarball is about an hour
<infinity> Oh, I can wait an hour.
<infinity> I'm not THAT impatient.
<BenC> it's showing about 30 minutes left, I'm off to bed
<BenC> you wont be able to build it against -2 most likely, FYI
<BenC> but if you check ronne:~/bcollins/edgy-i386 in an hour or so, there will be some .deb's you can try (change the ABI in lrm to -3-xxxxxx to match the packages)
<BenC> those are pretty much what I am going to upload
<fabbione> morning guys
<chuck> heylo
<yvan_> hello
<yvan_> this questions must have been asked many times but I am sorry I could not find any answer. Could you tell me if there is a place where I can download a wen-kernel for Dapper?
<zul> wen-kernel?
<zul> do yo mean xen?
<yvan_> hi sorry
<yvan_> Xen yes of course
<zul> no there isnt you can do the binary install in the wiki
<zul> er..instructions are in the wiki
<yvan_> Trying to find the wiki
<yvan_> I was on a Sourceforge article
<yvan_> instead
<yvan_> thanks I'm gonna look at it
<infinity> BenC: "having a life" took precedence over "working late" today, so no LRM.  If you want to get it in when you're up, go ahead, or I'll do it tomorrow.
<zul> hey infinity
<BenC> infinity: Ok, I have 2.6.17 ready, so I'll drop lrm with it
<BenC> I honestly didn't change much
<infinity> BenC: Cool.  Works for me.  I'll just do a -2 (well, probably a .1-1, since it'll be a new orig) tomorrow, based on your work.
<infinity> I don't expect to touch it much after this anyway, it's just hard to "let go" when you have a "few last things" to do. :)
<BenC> I know the feeling :)
<mdz> BenC: so we'll be able to update linux-meta soon then?
<BenC> yep
<BenC> I have it ready to upload too
<BenC> matter of fact, linux-source is about to meet lftp in a minute or two
<mdz> you use lftp rather than dput or dupload?
<BenC> I upload linux-source from ronne at the DC, and I delete it immediately afterwards..
<BenC> well, after I get the ACCEPT email :)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-3.3 uploaded, lrm and linux-meta really will come with this one | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<zul> uh...i have a spec assigned to me so should i show up to the distro team meeting tomorrow?
<Keybuk> zul: please
<zul> ok
#ubuntu-kernel 2006-06-29
<zul> hey
<roh> uh
<zul> sorry for patch bombing the ml there is a couple more
<crimsun> I think I might take the prize for patch-bombing, so don't worry ;)
<zul> only 8 patches ;)
<crimsun> :)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-3.4 uploaded, lrm and linux-meta really will come with this one | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<Mithrandir> BenC: around?
<Mithrandir> BenC: I have a jprobe which would be nice to have enabled in the kernel build.  Where should I put it?
<zul> hey
<BenC> Mithrandir: So you're going to send me a patch? :)
<Mithrandir> BenC: sure.  I just want to agree on a place in the tree.
<Mithrandir> rather than just making kprobes/ as a top level one right away. ;-)
<BenC> what is jprobe?
<Mithrandir> a kind of kprobe.
<Mithrandir> which is the instrumentation framework.
<BenC> is it invasive?
<Mithrandir> http://www.redhat.com/magazine/005mar05/features/kprobes/ 
<Mithrandir> the probe itself?  No, it's a < 100 line module.
<Mithrandir> oh, sorry, I added the GPL boilerplate so it's 101 lines now. :-P
<BenC> leave the GPL out
<Mithrandir> it's not supposed to be in random .c files in the tree?
<BenC> or do you mean the copyright at the top of the file?
<Mithrandir> not the full GPL, just the "this is under the gpl, yatta, yatta"
<BenC> ok
<BenC> is it a single file?
<Mithrandir> yes, plus a makefile
<BenC> is it arch-indep?
<Mithrandir> should be, unless I've fucked up.
<BenC> ok, just add it under kernel/, and add the Makefile/Kconfig entries there
<Mithrandir> ok, thanks.
<BenC> insert the module in one commit
<Mithrandir> I'll do that in a little bit, need to pop out to the store for a bit.
<BenC> then run "debian/rules updateconfigs" and enable it everywhere, and make the next commit the config updates + changelog entry
<BenC> thanks, just ping me for a pull when it's ready
<BenC> and please do a single build (debian/rules binary-debs flavours=386) to make sure it's not causing any failures
<Mithrandir> it'll probably be flavours=k8, but yeah.
<zul> BenC: just wondering if you had a look at my patches
<BenC> zul: Some of your mail headers are dupes and mismatched to the patch, but the attachments are all good :)
<BenC> Mithrandir: then =amd64-k8 :)
<zul> BenC: heh...i think i was doing several things at once
<BenC> zul: Are these all dapper or edgy?
<zul> i think they can be both..
<BenC> ok, if I put them in dapper, they will get into edgy as well
<zul> ok
<BenC> thanks
<BenC> I'll ping you when they are in git so you can mark all the bugs "fix committed"
<zul> im mostly concentrating on dapper recently
<zul> ok
<zul> hey jeff
<jbailey> Heya chuck
<zul> how goes the battle?
<jbailey> I'm not sure who's winning.
<jbailey> DAYLIGHT COME AND ME WANT TO GO HOME!
<ajmitch> heh
<ajmitch> hello jeff
<jbailey> hi Andrew
<BenC> zul: you need to set some env vars so your commit's look right
<BenC> GIT_AUTHOR_NAME=Ben Collins
<BenC> GIT_COMMITTER_NAME=Ben Collins
<BenC> GIT_COMMITTER_EMAIL=bcollins@ubuntu.com
<BenC> GIT_AUTHOR_EMAIL=bcollins@ubuntu.com
<BenC> like that
<BenC> crimsun,zul: Latest patches are in git now
<BenC> thanks
<zul> thanks
<zul> ah...suckage
<infinity> BenC: You suck at LRM. :P
<infinity> BenC: http://librarian.launchpad.net/3184793/buildlog_ubuntu-edgy-i386.linux-restricted-modules-2.6.17_2.6.17.1-1_FAILEDTOBUILD.txt.gz
<BenC> bah, LRM sucks on me :P
<BenC> wtf is that bullshit
<BenC> BFD: debian/nvidia-glx/usr/lib/stekNdpL: warning: allocated section `.bss' not in segment
<BenC> BFD: debian/nvidia-glx/usr/lib/tls/st2EQALJ: The first section in the PT_DYNAMIC segment is not the .dynamic section
<BenC> I blame the buildd for that...worked fine on my system :)
<infinity> BenC: Did you use binutils 2.17, or the older one?
<infinity> BenC: Could be new breakage.
<BenC> let me check
<BenC> ii  binutils            2.16.1cvs20060117-1 The GNU assembler, linker and binary utilities
<BenC> ii  gcc-4.1             4.1.1-2ubuntu3      The GNU C compiler
<BenC> I'll upgrade and see if I can reproduce it
<BenC> wow, things are totally bombing on me now
<BenC> I can't even get as far as the buildd did
<BenC> pwd: couldn't find directory entry in `../../../../../../../..' with matching i-node
<BenC> pwd: couldn't find directory entry in `../../../../../../../..' with matching i-node
<BenC> that looks like something else entirely
<BenC> infinity: it is a binutils bug...elmo confirmed a debian bug report about nvidia pre-built libs and 2.17 binutils/strip
<BenC> infinity: I'm doing a -2 that -X's the problematic stuff for dh_strip
#ubuntu-kernel 2006-06-30
<BenC> crimsun: ping
<crimsun> BenC: pong
<BenC> crimsun: With linux-meta uploaded now, we need to talk about how to best handle alsa
<crimsun> BenC: ok.
<BenC> I don't want to start getting a bunch of regression bug reports for stuff that was fixed in dapper, but itsn't in edgy any more
<BenC> is there a good alsa driver release I can patch into 2.6.17?
<BenC> or maybe a git tree I can pull from?
<BenC> one thing I notice is that there is now a snd_aoa which takes over a lot of stuff on powerpc, and I want it badly :)
<crimsun> BenC: http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa-current.git;a=summary
<crimsun> BenC: -current tracks -mm I believe
<BenC> so it's against 2.6.17 still?
<zul> would people bitch if there was a 686 only for xen for x86?
<crimsun> BenC: believe so.
<BenC> zul: doubt it
<crimsun> BenC: http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa.git;a=summary   is for Linus's
<zul> sweet..
<BenC> zul: anyone running a virtual host/client system like that needs at least a 686 cpu, IMO
<BenC> I couldn't imagine running it on a 486
<zul> cool...because CONFIG_M386 is giving me grief
<crimsun> BenC: I was going over the patches we have in Dapper's tree, and the only really outstanding thing is the Jack Sense blacklist (sound/pci/ac97/ac97_patch.c)
<crimsun> BenC: that's pretty much the only thing that needs to be forwarded from Dapper->Edgy
<BenC> crimsun: can you find the sha commit I need to cherry-pick?
<crimsun> BenC: I'll work on that tonight and send you a list
<BenC> next kernel is forcing an ABI bump already, so I might as well get alsa in there ASAP
<BenC> crimsun: great, thanks
<BenC> going to attempt a pull from -current
<crimsun> BenC: if you get conflicts due to xxx_t types (forwarded from Dapper's tree), take Jaroslav's tree as authoritative
<BenC> I'm already sitting at stock 2.6.17 code in sound/* anyway
<BenC> except for ppc toonie
<crimsun> ok
<BenC> only 278 objects pulled, that's a good sign I guess
<crimsun> -current git lags http://hg-mirror.alsa-project.org/alsa-kernel by a day or so, sometimes longer
<BenC> then again, I fetched linus' tree earlier, so I have all the objects already
<zul> BenC: alot of the security updates doesnt apply to hoary..
<BenC> zul: don't apply, or aren't relevant?
<zul> both...there is no posix-cpu-timers.c in hoary ;)
<crimsun> all the official work seems to be done in hg and pushed to git via tailor
<BenC> I read "don't apply" as maybe meaning the patch just chokes :)
<BenC> crimsun: good enough
<BenC> zul: ok, note that when you reply to pitti
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-3.4 uploaded, lrm and linux-meta done as well | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<zul> BenC: i have xen building i just need to figure out how to package it ;)
<BenC> ripping the linux-source-2.6.17 build system would be a good start :)
<BenC> at least it would be familiar to anyone messing with both
<zul> getting there
<zul> it unpacks it, builds it...??? profilt 
<BenC> crimsun: badness...alsa git is pulling in all sorts of junk
<crimsun> BenC: -current?
<BenC> yeah
<crimsun> BenC: ok, what about http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa.git ?
<BenC> I'll try that next
<crimsun> ok.
<BenC> wondering if I could just grab sound/* include/sound/* from 2.6.18
<BenC> or from alsa.git
<BenC> wish I knew the command that would show me the commits between alsa.git and linux-2.6.git
<BenC> revlist doesn't look big enough...did alsa merge in .18?
<crimsun> I don't believe so
<crimsun> last I know of was in .17
<BenC> there's only 20 commits in the rev-list from alsa.git to linux-2.6
<crimsun> probably pushed from akpm, then
<crimsun> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob;h=4f0e65808cf1a29e39757244ce15509b756e39b0;hb=cc1930c5813356d664c160a8fb1db9284580cae7;f=include/sound/version.h  looks fairly current
<BenC> I know that some of the stuff I pulled from dapper actually applied to the current tree, but I just kept reverting those portions
<BenC> let me do a diff and see exaclty how much is different
<BenC>  255 files changed, 22575 insertions(+), 5237 deletions(-)
<BenC> that's the diffstat on sound/* between our tree and alsa-current
<crimsun> can't pull atm, sorry
<BenC> using alsa is not much different
<BenC> alsa is strictly sound/* and include/sound/* isn't it?
<crimsun> yep
<BenC> A direct copy of alsa-current seems to be build just fine, for powerpc at least
<BenC> I may do this for the next upload
<crimsun> I see no prob w/ that
<BenC> snd_aoa may be the best thing to happen to linux-ppc audio since it was introduced
<crimsun> now that we're not juggling mutex/xxx_t typedefs, it should be much easier.
<crimsun> yep
<BenC> yeah, definitely
<BenC> crap, one driver is looking for a media/v4l2-dev.h include
<BenC> hmm, removing the include lets it build...hope that's ok :)
<johanbr> join #suspend2
<BenC> crimsun: that sync with sound/* include/sound/* seems to have gone pretty well
<BenC> doing a 6-arch build now to see if there's any other quirks
<crimsun> BenC: excellent
<BenC> the only thing I have in sound now that isn't stock is bt-sco
<BenC> wish alsa would pick that up at some point
<crimsun> I'll poke takashi about it
<sivang> morning
<nigel_c> Hmm.
<sivang> hi all
<sivang> I can't boot edgy's kenrel on my laptop,
<sivang> I get:
<sivang> Bad EIP Value
<sivang> EIP:[<0000000>] 
<sivang> _stext+0x3feffd68/0x8
<sivang> SS:ESP 0068:dfd81f08
<sivang> Any idea what could have went wrong?
<zul> hey
<BenC> sivang: which version, -3?
<mjg59> sivang: The rest of the dump is likely to be necessary
<sivang> BenC: let me check
<sivang> BenC: linux-image-2.6.17-3-686 , so yes
<BenC> sivang: can you take a photo of the screen with the crash on it?
<sivang> BenC: I'll do that, but this is the exact string I saw when it crashed
<mdz_> BenC: I just got a hard freeze on my desktop running 2.6.17-3.4
<mdz_> it was in X, so I don't think I can do much useful with it before I reset, but thought I'd ask
<mdz_> it doesn't even respond to sysrq
<mdz_> no lights on the keyboard
<mdz_> wasn't doing anything particularly interesting at the time; had just closed gnucash and switched desktops over to xchat
<mdz_> same box ran solid since Dapper on the Dapper kernel
<mdz_> and for a short time on 2.6.17-1
<mdz_> I'm leaving town this afternoon, so I'm reverting to 2.6.15-23-k7 to be safe
<BenC> mdz: Sorry, was up in the barn
<BenC> mdz: hopefully when I get kdump uploaded, you can reproduce it
<BenC> we can grab the freeze with that
#ubuntu-kernel 2006-07-01
<zul> hey BenC 
<BenC> hey zul
<zul> BenC: this is weird it says i have sda but i dont have scsi
<BenC> pata
<zul> yeah
<BenC> what kernel are you using?
<zul> 2.6.17
<zul> latest one
<BenC> -3?
<zul> yep...i have ata_piix
<BenC> or like a daily build
<zul> -3
<BenC> wasn't like that in dapper?
<zul> nope...i was able to boot ;)
<zul> running 2.6.15 right now
<zul> at least i know the new grub didnt brick it ;)
<BenC> so 2.6.15 says hda, and 2.6.17 says sda
<zul> correct
<BenC> eventually initramfs finds it and boots, right?
<zul> i didnt wait that long
<BenC> it should after 2-3 minutes
<zul> lemme try again
<crimsun> I think shaya potter mentioned the pata stuff appearing as sdX last night in -devel
<BenC> that will get fixed when base-files includes the conversion script to update fstab and such to UUID instead of device
<crimsun> BenC: working on the commit list now
<zul> cool...well my grub merge works now i can upload it on to the world
<zul> well im at a busybox shell now
<BenC> crimsun: excellent
<zul> crimsun: did he have a fix?
<zul> besides not using edgy yet..
<crimsun> zul: I mentioned having to change something to sda
<crimsun> s/I/he/
<crimsun> BenC: sent
<crimsun> zul: should be in yesterday's/today's #ubuntu-devel irclog
<crimsun> zul: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-devel-2006-06-30.html, about 1/4th down
<crimsun> shaya [n=spotter@user-0ccetig.cable.mindspring.com] 
<crimsun> d'oh
<ajmitch> morning crimsun 
<BenC> crimsun: thanks, I'll have them in -4
<yfox> can anyone help me install madwifi-ng on xubuntu ?
<zul> BenC: is there i have to do so when i run a clean it doesn delete my debian directory
<marcreichelt> hiho
<marcreichelt> I tried to install Kubuntu 6.06 on my new AMD64 PC
<marcreichelt> (exactly: AMD Athlon64 2800+)
<marcreichelt> during the installation the system "hangs up" (but it is no kernel panic)
<marcreichelt> after 3 tries (and the same problem, sometimes at 19%, sometimes at 49%) I did a tail -f /var/log/messages
<marcreichelt> and there are some errors listed
<marcreichelt> one of it is:
<marcreichelt> [ some numbers]  VFS: brelse: Trying to free free buffer
<marcreichelt> [ some numbers]  Badness in __brelse at fs/buffer.c:1279
<marcreichelt> are there any known problems here?
<marcreichelt> (there are _large_ call traces there, but I didn't want to type them in my computer)
<marcreichelt> currently I'm downloading the alternate AMD64 install cd to look if the problem is there too
<thuglife> hi
<thuglife> is here anyone who is working on ia64?
<marcreichelt> anyone here?
<marcreichelt> to my problem with VFS: my Athlon64 seems to have problems with squashfs
<thuglife> it seems that everyone is slacking
<marcreichelt> hehe
<marcreichelt> hmm
<marcreichelt> it doesn't seem to be a problem with Linux
<marcreichelt> it seems to be a problem with the hardware (IDE)
<marcreichelt> I tried to install Kubuntu with the Alternate Install CD, and there the /var/log/syslog says that there are errors reading from the dvdrom device
<marcreichelt> funny...
#ubuntu-kernel 2007-06-25
* #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
<kraut> moin
<xivulon> Hi mjg59, are you back?
<xivulon> We talked a few days back about hibernation issues in wubi
<shawarma> BenC: I've a question about the build system we're using for the kernel..
<shawarma> I was debugging  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/121815 earlier today, and I did the "AUTOBUILD=1  NOEXTRAS=1 fakeroot debian/rules binary-debs flavours=server" as instructed on the wiki. When I altered the driver, and  ran that command again, I expected it to be rebuilt, but it wasn't..
<shawarma> I ended up doing a 'debian/rules clean' so that the entire thing was rebuilt, but I suspect there's a way to just have  it rebuild what's changed..
<\sh> guys, there is a problem with cciss drivers and mounting logical volumes > 2TB on feisty (regarding P800 and P400i) 
<\sh> mounting a device with a eit/gpt partition table on feisty with >2TB partition manually is working, but rebooting the server result in a bad superblock....putting the fs directly on the block device without any partitiontable works as well...
<\sh> this behaviour is not only to found in feisty, but as well with actual cciss drivers from HP for e.g. sles10 or sles9
<zul> can you open a bug report because I dont thinnk alot of the kernel devs are awake
<shawarma> \sh: Have you seen it working with similar storage systems using another driver?
<\sh> but it looks like that patches like http://lkml.org/lkml/2006/9/11/242 and http://lkml.org/lkml/2006/9/11/245 are already in (3.6.14 is actual in 2.6.21.5) 
<\sh> shawarma, yepp, with areca raid 6 controller it works flawlessly
<shawarma> \sh: ok
<\sh> shawarma, right now, I have two machines in our testlab (hp dl365 with p800i and external msa60 storage (12x750GB) and hp dl320s with p400i and 12x500gb internal hds) 
<\sh> right now, it's a riddle to me, what can cause this...when it's not the cciss driver...
<shawarma> \sh: Alright. The patch also strongly suggests it's a driver issue. I just thought it might be in another layer.
<BenC> shawarma: check the stamps in debian/stamps/
<BenC> there a build stamp for each flavour
<BenC> shawarma: ccache also helps in these situations :)
<\sh> shawarma, I just have a source tree of 2.6.21.5 handy here..and when I compare the patch on lkml and in this source tree, it's already in the vanilla kernel...so my stomach tells me it's somewhere else
<shawarma> BenC: Removing the stamp will do what? Cause the source to be copied to the build tree again? 
<shawarma> BenC: hopefully maintaining timestamps and such so I don't have to rebuild everything? Or is that why you're bringing ccache up?
<\sh> shawarma, there is one error message (sorry, I have to type it from my mind), while mounting the devices during boottime, that something is requesting around 4billion and is only getting 2billion (whatever measurement) ... and then the mount of the big storage fails 
<\sh> .oO(when I redo the installation from scratch I'll save all the logs)
<shawarma> \sh: Alright. I'm not the one who's going to fix it, so you should probably put all of this into a bug report.
<\sh> shawarma, against what? ,-) kernel? udev? mount? 
<BenC> shawarma: removing the build stamp will cause it to be rebuilt
<BenC> but not from scratch
<BenC> just like running make again
<shawarma> BenC: Oh, ok. I thought it was trying to be clever by moving the source around and so on, but it seems not.
<BenC> shawarma: gutsy uses kernel O= out-of-tree build setup
<BenC> so no source copying
<shawarma> Ah, ok. It been quite a while since I've looked at the kernel... Lots of things have changed :)
<shawarma> BenC: Yay! That seems to be doing exactly what I wanted it to. \o/
<shawarma> BenC: Thanks!
<BenC> shawarma: np
<BenC> shawarma: if any info you get here seems to be useful, feel free to add it to our kernel maint wiki somewhere
<shawarma> BenC: Already on it :)
<BenC> shawarma: you da man
<shawarma> BenC: The wiki says the debs will land in ubuntu-2.6/debian/build. Mine land in the parent directory... Am I experiencing a bug, or is the wiki not up-to-date?
<BenC> not up-to-date
<BenC> shawarma: is that custom build page?
<BenC> trying to move stuff to KernelMaintenance
<shawarma> BenC: Oui.
<lamont> BenC: not to be a pest or anything....  wondering when that kernel with the latest (rc5) hppa fixes will arrive in the archive...
<BenC> lamont: today, uploading for tribe-2 freeze
<lamont> rock
<zul> BenC: for the vserver patch should I send to pkl and cc kernel-team again?
<BenC> zul: yeah, thanks
<zul> gah #122116
<xivulon> mjg59: did you have a chance to check hibernation in wubi?
<mjg59> xivulon: Just back home - need to catch up on stuff tomorrow, probably later tis week
<jmg> wubi should have a Colinux target.
* ..[topic/#ubuntu-kernel:crimsun] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-7.14 | 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/
<crimsun> (-> 7.14)
#ubuntu-kernel 2007-06-26
<xivulon> mjg59: pls use this link, wubi-installer.org
<xivulon> mjg59: no rush whatsoever of course
<xivulon> ps I do not follow this channel that often, we use mostly use the forum http://ubuntuforums.org/forumdisplay.php?f=234
<xivulon> thanks a lot in advance
<xivulon>  jmg: it should not be too difficult to adapt a wubi disk image for colinux, but I did not have much time for that
<xivulon> there are good reason why emulators are not our first target though
<xivulon> not least that we try to provide an installation as close as possible to a real one, with full hw access, and without being "slave" of the host os
<alex_mayorga> hello all, can anyone help me get trough Bug #121111
<crimsun> bug 121111
<crimsun> oh, right.
<crimsun> can you wait for Tribe 2?  It's slated for this week end.
<crimsun> (either week end or weekend, literally)
<alex_mayorga> I guess I can wait
<alex_mayorga> would it be fixed for sure?
<crimsun> "for sure"?  No.
<crimsun> however, it's better to test against a daily or daily-live
<alex_mayorga> crimsun, where do I snotch those, sort of newbie in all this devel stuff
<crimsun> http://cdimage.ubuntu.com/
<alex_mayorga> I'll give it a spin
<alex_mayorga> crimsun, this one http://cdimage.ubuntu.com/daily-live/current/gutsy-desktop-i386.iso
<shriram> I need to access a string whose physical addresss is known. How can I do this in Linux?
<jmg> kernelnewbies.org
<shriram> jmg, i couldn't find an answer there :(
<jmg> #kernelnewbies
<kraut> moin
<TheMuso> 'c
<TheMuso> ugh
<zul> BenC: ping (very interesting) http://codemonkey.ws/kvm-xen/
<BenC> zul: would be nice if xen started getting vmx support
<zul> yeah I know
<zul> BenC: http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00844.html
<zul> ill see if its already there tonight
<zul> meeting today isnt it?
<Daviey> Hi, can somebody help me with bug 122102
<Daviey> bah, no ubotu :)
<Daviey> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/122102
<geser> BenC: re your last comment to bug #114855: I know that gutsy is work-in-progress but do regression from feisty to gutsy count as "some functionality may not exist yet"?
<geser> BenC: you also write "The majority of prism2 and prism54 are already supported". Which is the current module in gutsy for prism54 based wlan cards?
<okaratas> hello
<okaratas> how are you channel ?
#ubuntu-kernel 2007-06-27
<kraut> moin
<xhaker> BenC, http://xhaker.wordpress.com/2007/06/14/1-2-3-testing/
<xhaker> Could you please take a look?
<BenC> xhaker: Sure, but not really able to do much about it like this
<BenC> launchpad is much better than wordpress :)
<xhaker> BenC, sure. Just thought it might be more widespread and already known
<xhaker> I will install tribe2 later and report the bug accordingly
<xhaker> BenC, I should ask you this too.
<xhaker> BenC, how should I debug a machine (laptop) that hardlocks randomly
<xhaker> apparently
<xhaker> i've tryed the debug methods on the wiki
<xhaker> latest feisty kernel
<jbailey> BenC: There's something special about looking at http://kernelnewbies.org/known_regressions and seeing one of mine in there ;)
<zul> gives you a warm fuzzy feeling?
<jbailey> Yes, especially since ben and I found a work around after I reported it. =)
<calc> BenC: http://www.theinquirer.net/default.aspx?article=40567
<calc> BenC: is that being fixed in a new kernel update (or already has been)?
<xhaker> My problem might be this one Subject    : acpi_pm clocksource loses time on x86-64
<xhaker> References : http://lkml.org/lkml/2007/4/17/143
<xhaker> thanks for that regressions page jbailey 
<jbailey> xhaker: np
<zul> hmmm...its kind of hot outside (feels like 42C)
<jbailey> That's a *bad* kind of hot.
<jbailey> Feels like 35C here.  It wasn't that bad in the shade.
<kylem> feels like 22degC here. :)
<zul> yeah I dont have air coniditioning at home
<kylem> loss.
<bdmurray> helo?
<bdmurray> I was looking at bug 121601 and have no idea how it is related to  the upstream bug
#ubuntu-kernel 2007-06-28
<calc> BenC: i noticed something a bit off with my laptop, may be common though, it works fine for resume in i386 but won't in amd64 when it tries to resume it looks like it almost comes back but the xserver doesn't come up and i can't get to different tty's, i see the resume kernel(?) messages though on the screen
<crimsun> BenC: could we build the OSS/Free opl3{,sa{,2}} sound drivers?  Because libasound2-plugins (containing the OSS alsa-lib plugin) is in main, we can easily let users with that hardware use Ubuntu apps
<crimsun> no one's stepping forward to fix snd-opl3sa2, so the sabdfl's "have sound work out of the box" may be resolved most easily in this manner
<BenC> crimsun: ok, can you file a bug please?
<BenC> calc: odd, haven't seen that before
<calc> BenC: perhaps i'll let you look at it in London :)
<BenC> calc: ok
<xipietotec> hey, is there a known issue with suspend and hibernate with the low-latency-kernel?
<bremenbeck> hiya... daft question that causes me a whole pile of grief
<bremenbeck> I think I'm up to date with the patches and all.. and I know how to edit boot code
<bremenbeck> root@harold:~# uname -a
<bremenbeck> Linux harold 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux
<bremenbeck> so then this gets in the boot...
<bremenbeck> root@harold:~# grep -i default /boot/grub/menu.lst | egrep 'kernel|Ubun' | grep -v \# | head -1
<bremenbeck> title           Ubuntu, kernel 2.6.18-028test007 Default
<bremenbeck> and not the  2.6.20-16-386
<bremenbeck>   /boot/grub/menu.lst seems to always break
<bremenbeck> I have to have missed something... but every time I apt-get update, the kernel comes up on that pesky 2.6.18-028test007
<bremenbeck> no matter what I do
<bremenbeck> I'll try and delete it *again*...  wish me luck
<\sh> hmm...why is hugetablefs in feisties kernel not enabled
<\sh> ?
<\sh> it could be important, if ubuntu server wants to be a good java server platform :) (new feature of java6 largepages support)
<\sh> #122800
<kraut> moin
<bje> good day!
<bje> I'm trying to compile linux-kernel-di-i386
<bje> But I get "missing module ide-core"
<bje> when I do a "fakeroot debian/rules binary"
<bje> any hints?
<bje> cjwatson: you about?
<cjwatson> bje: linux-kernel-di-i386 doesn't work with Ubuntu kernels; the Ubuntu kernels build the udebs themselves
<cjwatson> (besides, even linux-kernel-di-i386 in upstream d-i svn was designed for 2.4 kernels; there's a -2.6 variant for 2.6 kernels; but you don't want that either on Ubuntu for the reason above)
<bje> cjwatson: I build my kernel like this: 'fakeroot make-kpkg --append-to-version="-claranet" kernel_image kernel_headers', I do not get any udebs.  What am I doing wrong then?
<bje> cjwatson: this is the actual problem I'm trying to solve: https://lists.ubuntu.com/archives/ubuntu-server/2007-June/000493.html :)
<cjwatson> bje: the udeb building is done by debian/rules, not make-kpkg
<cjwatson> so you would need to use the Ubuntu kernel source with 'debian/rules build-images' or similar
<cjwatson> (or whatever the rune is on dapper; but it won't involve make-kpkg)
<cjwatson> 2.6.20 is going to be extremely hard to make work with dapper; IIRC there were incompatible changes affecting things like udev
<kylem> right.
<bje> cjwatson: suggestions then for making my RAID controller work with Dapper?
<cjwatson> sorry, I am but a humble installer guy; if the kernel doesn't work I tend to punt to these guys
<bje> Ah ok, cool. I'm in the right channel, though?
<kylem> for the installer, you're kind of boned.
<bje> So what exactly is the point of running a LTS then? :)
<kylem> custom kernel for your hw + empty udebs is probably the easiest thing.
<cjwatson> bje: the only reason we can manage to support dapper for 5 years is that we *aren't* trying to upgrade the kernel constantly ...
<bje> I see.
<cjwatson> so yes, support is sometimes confined to hardware where it worked at time of release
<cjwatson> there has been some talk of possibly backporting a newer kernel to dapper in future
<cjwatson> because obviously a number of people have this kind of issue
<cjwatson> but that's not in place yet
<cjwatson> bje: if you have to have 2.6.20 on dapper, it would probably be less painful to work via the live CD
<cjwatson> that way you can experiment more easily with upgrading other components like udev, and you won't have to mess around with udebs
<cjwatson> and yes, that would involve a process other than PXE boot / kickstart
<cjwatson> (more like install once and clone the disk)
<shawarma> kylem: We're getting more and more people in #ubuntu-server asking for backported drivers for various new raid controllers and that sort of thing.. What happened to the the 2.6.15-50.whatever kernel?
<kylem> shawarma, i have Real Work(tm) to do...
<kylem> that and it became clear after the first time i did it that it was a Really Really Bad Idea.
<shawarma> kylem: Erm? Oh, I didn't know it was kind of a personal experiment. I thought it was a serious stab at trying to provide updated drivers.
<kylem> it was the first time we'd ever done it.
<shawarma> kylem: Right. Let me rephrase: I thought that it itself constituted "real work(tm)"..
<shawarma> kylem: but no?
<kylem> well, nobody has assigned it to me to do again, so...
<kylem> besides, if we don't respin the installers, what's the point?
<shawarma> None.
<shawarma> I would expect new installer CD's, too.
<shawarma> I'll take it up at the meeting today.
<kylem> yes, well, you can do the backports then. :P
* shawarma screams and hides behind the door
<kylem> you learn quick.
<zul> lol
<shawarma> What's the idea going forward, then? The issue is only going to get worse. More frequent LTS's?
<shawarma> That's going to cost us even more time.
<kylem> not my place to say; i'm just relaying my experience.
<BenC> shawarma: backporting drivers is tedious and usually not very helpful without CDs...unfortunate as well that we don't have driver-updates feature in dapper
<BenC> shawarma: as cjwatson said, we are seriously considering a kernel backport to dapper, but it's very tedious as well
<BenC> we have to look at what userspace backporting we'll also need to do
<kylem> "lots"
<kylem> i think even python updates end up in the dep chain unless we fork packages.
<fabbione> never mind the installer bits to cope with the other user land changes
<kylem> somehow hal needs the new python version...
<fabbione> it's probably easier to take feisty and turn it LTS
<shawarma> How does RedHat cope with this?
<kylem> shawarma, uh, hundreds of engineers.
<fabbione> with big $$$
<fabbione> :)
<shawarma> kylem: I see.
<kylem> well, certainly more than 5.
<zul> heh need more community people then ;)
<kylem> heh. while i certainly value the community, i don't think we could convince them to work on something so tedious and menial.
<zul> kylem: been there done that
<kylem> especially not when all the fun is to be had on ubuntu+1
<shawarma> kylem: Yeah. Ubuntu-3 is nowhere near as fun :)
<Daviey> Can a ninja help me with a kernel bug?
<bdmurray> kylem: ping
<kylem> yo
<bdmurray> Is it just me or is bug 121601 unrelated to the upstream bug?
<kylem> dunno
<kylem> looks unrelated at first glance
<bdmurray> They don't seem to be the same ata driver do they?
<xivulo1> mjg59, did you have a go at wubi by any chance? 
#ubuntu-kernel 2007-06-29
<kraut> moin
<xivulon> mjg59: just a reminder about wubi, sorry if I keep bothering you, but sorting out hibernation/suspend is one of the few things holding back our final release
* netjoined: irc.freenode.net -> kubrick.freenode.net
<Zelda[] > what is those strange numbers in the kernel during the boot?
<Zelda[] > e.g [17179608.216000]  Bluetooth: RFCOMM ver 1.7
<mikmorg> Hello
<Zelda[] > hi
<mikmorg> Does anyone know what could be automatically load a module in /lib/modules, even though it is not instanced in modprobe configs?
<mikmorg> The reason I ask, is that I inserted a new module in the updates folder, and without having to probe it, it is found on boot.. However, I don't see that hotplug is installed (which I was told may do that for me by scanning PCI IDs).
<jbailey> Checking ABI for hppa32...previous or current ABI file missing!
<jbailey> I have enough patches to make this thing build now.  Is there an easy way to work around this?
<Nafallo> Intel 4965AGN <-- supported in kernel yet?
#ubuntu-kernel 2007-06-30
<defendguin> i had a regression in edgy when you guys rolled out that update to restricted modules to fix some madwifi deal now when i return from suspend my wireless id dead i have to rmmod and modprobe ipw3945 to get my wireless to work
<defendguin> is dead*
<defendguin> bug #123172 dmesg output is attached
<okaratas> hello
<okaratas> hello
<jmg> hey all
<jmg> where is the debian/rules file for linux-source-2.6.22?
<jmg> aieeeeee
<jmg> BenC: i installed the gutsy kernel on my feisty box and now i cant mount any usb drives at all!
<jmg> they lie, they lie and we have to be merciful to those who lie.
<jmg> i am getting lots of [  709.597011]  device-mapper: table: 254:2: linear: dm-linear: Device lookup failed
<Mithrandir> remote the evms package, unless you're using it
<jmg> remove?
<jmg> how is that breaking mounting?
<jmg> mount("/dev/sdb1", "/media/EXTERNAL/", "vfat", MS_MGC_VAL, NULL) = -1 EBUSY (Dev
<jmg> ice or resource busy)
<jmg> the device isnt busy
<jmg> sigh.
<jmg> this is bullshit
<Mithrandir> removing evms will get rid of the dm-linear messages, it won't fix anything else.
<jmg> yeah
<jmg> it helped a lot
<jmg> but using the gutsy kernel doesnt fix my issue any more
<jmg> must have been a regression
<kraut> moin
<jerome_> hello all
<jerome_> i don't know if this is the right place but i don't get any answer on ubuntu-bugs
<jerome_> i want to know if bug 123173 is really a kernel issue
<jerome_> or an alsa, ... one ?
<jerome_> thx if you can help me
<xivulon> hi mjg59
#ubuntu-kernel 2008-06-23
<BenC> It's funny that there isn't even an ext4 filesystem yet...the fs and module are called ext4dev
<lifeless> wow, that dude was nuts
<wgrant> Wow.
<wgrant> That was impressive.
<wgrant> That jdong impersonation... wtf.
<emma> w 30
<BenC> cking: would you be interested in seeing if there's some way we can pass info to grub about whether a boot failed or not?
<mjg59> BenC: You were looking for me on Friday?
<BenC> cking: I was thinking of something like "grub goes to boot, set dirty boot flag, OS clears flag"
<BenC> mjg59: yeah, in regards to uvesafb and if there's reason not to use it as opposed to vesafb?
<mjg59> None that spring to mind
<BenC> cking: and if grub comes up and that dirty flag is still set, default to last-good-boot entry
<BenC> mjg59: I guess the main question is...could it be used as the default? (I have v86d packaged and ready to upload)
<mjg59> Default? I wouldn't encourage it
<mjg59> Using it instead of vesafb should be entirely safe, though
<BenC> That's good...at least then we can ditch the modular vesafb patches
<cking> BenC: I will put it on my grub "to do list".
<BenC> rtg, pgraner, smb: New abi-check script in git...check the git-log for description
<BenC> I think you guys will like it
 * BenC says goodbye to diff based abi checks
<zul> BenC: is there a flavours git repo open yet?
<pgraner> BenC: rock on....
 * pgraner runs to pull the latest
<BenC> pgraner: I can easily add per module whitelist/blacklist now
<pgraner> BenC: nice...
<BenC> pgraner: so if we only want to fail(aka abi-bump) only for certain portions, we can
<pgraner> BenC: would be nice to get folks like vmware to give us the list of symbols they are using
<BenC> brb, rebooting
<kirkland> rtg: hey, i'm doing most of my ecryptfs work against intrepid
<kirkland> rtg: this fix is already in 2.6.26
<kirkland> rtg: but there's a corner case where this problem can cause data loss on an ecryptfs mount in Hardy
<rtg> kirkland: data loss == bad
<kirkland> rtg: right, so the test case looks like this....
<kirkland> rtg: mount an encryptfs dir, any kind, any key, any algorithm
<kirkland> rtg: write some data at least 8KB (looks to need to be 1-2 pages)
<kirkland> rtg: *don't* read that data
<kirkland> rtg: unmount the dir
<kirkland> rtg: re-mount, and append some data to it
<kirkland> rtg: then try to read
<kirkland> rtg: that file has gone boom
<kirkland> rtg: fixed by this patch, you can probably see how
<rtg> kirkland: seems clear enough. is there an LP report open against Hardy for this?
<kirkland> rtg: nope; want me to open one?
<rtg> kirkland: that would be nice. thanks.
<BenC> rtg: Oh, and the new ABI checker will _always_ fail if one of the ABI files is missing :)
<kirkland> rtg: https://bugs.edge.launchpad.net/linux/+bug/242448
<BenC> we really have no excuse to not have ABI's in the tree anymore (no post hppa and ia64)
<rtg> kirkland: cherry picked 2.6.26-rc7 has some conflicts, but I see its also in 2.6.25 stable. I'll work on getting it backported. Since I use ecryptfs, I am quite interested :)
<kirkland> rtg: thanks ;-)  I thought you might help advocate this
<kirkland> rtg: on the flip side, i'm interested in learning some of your processes on the kernel side
<kirkland> rtg: so if there's more I can do to help, or more I can learn, please keep me posted
<rtg> BenC: did your script check for missing ABI files if 'ignore' exists? 
<kirkland> rtg: I set the importance to "Medium" and targeted it for 8.04.2
<rtg> BenC: does it matter?
<rtg> kirkland: that works. I'll write the SRU justification in a bit.
<kirkland> rtg: thx
<BenC> rtg: considering we shouldn't uploading without ABI files (now that we are doing to 2x2 flavours), it fails now when an ABI file is missing, even if ignore exists
<BenC> I actually should just remove the blanket ignores
<BenC> they aren't terribly useful either
<rtg> BenC: they're pretty handy when you have an FTBS for only one arch.
<BenC> rtg: even in that case, we have better ways to recover than blanket ignores
<rtg> BenC: like a locally built ABI set?
<BenC> rtg: well, more like forcing the checker to use the right previous ABI
<BenC> e.g. if 3.5 exists, and you upload 4.6, and it fails to build
<BenC> the checker should be comparing 3.5 and 4.7 on the next upload
<BenC> not just ignoring the ABI all together
<rtg> BenC: hmm, I was thinking of the case when you've just had an ABI bump, but one arch FTBS's.
<BenC> isn't that what I described?
 * BenC checks his example
<rtg> BenC: when you've had an ABI bump, what use is comparing the ABI files from the previous ABI version? Only the modules check makes sense.
<BenC> Yeah, so if you upload 4.6, which contains the 3.5 ABI, and amd64 fails, the 4.7 upload should still compare with 3.5
<BenC> rtg: to track things
<rtg> BenC: so, the tracking new.
<BenC> the ABI files should exist and be checked...and in all cases show up in the build (the comparison)
<rtg> s/tracking/tracking is/
<BenC> rtg: right, we need to retain history on what/why the ABI bumped
<rtg> BenC: ok, well that makes more sense.
<BenC> rtg: so now, even if the result of the check is ignored, the check is still performed and results shown in the build (before, on ignore, the check didn't run at all)
<BenC> Sorry, my explanation of the importance of that feature was a little slim on the first try :)
<rtg> BenC: of what use is this information? Just to keep track of why ABI checks are failing?
<rtg> or rather, why ABI bumps are being forced upon us?
<BenC> right
<pwnguin> I see greg k-h is at it again...
<BenC> pwnguin: ?
<BenC> brb, need to crash my laptop
<pwnguin> BeC, he's got a petition to nobody that people are signing
<BenC> pwnguin: hey...what were you referring to with greg k-h?
<SEJeff> BenC, Probably the Position statement on closed source kernel drivers greg released
<BenC> SEJeff: where's that at?
<SEJeff> Just a sec, it was on lwn this morning
<SEJeff> http://www.linuxfoundation.org/en/Kernel_Driver_Statement
<BenC> I notice Linus's name is not on the list
<SEJeff> http://lwn.net/Articles/287056/#Comments Read through those
<SEJeff> It isn't an overall thing. It is gregkh doing what he does best
<SEJeff> Try to put his views onto other people
<mkrufky> ...pasting 4 lines:
<mkrufky> Oh, one further thing, you will note that Linus's name is not on this statement.  He said that he does not sign public statements like this, but in the email thread about it, he did say to one kernel developer who was thinking that closed source drivers are ok, "Binary drivers really _are_ bad for us. No untruths." 
<mkrufky> ok, so it was 1 line :-P
<BenC> Oh, I don't disagree with the premise at all
<BenC> I disagree that proprietary drivers are suddenly more of a problem now than they were a few years ago, or even one year ago
<doko> BenC: is gcc-4.2 still needed to build the kernel in intrepid?
<BenC> doko: not for our primary linux...if it's needed for linux-ports, the port maintainers will have to fix it up
<doko> BenC: who are the port maintainers for these archs (powerpc, hppa?)?
<pwnguin> BenC: well, I don't like closed binaries, but the license is fairly clear that there are exceptions
<mjg59> pwnguin: It is?
<pwnguin> hmm. i thought I had read it in the COPYING, but theres only the obvious note that the syscall API is not grounds for derived works, but clearly I was wrong. all I can find is a thread where torvalds mentions the limits of derived works might not be as clear cut as "modules are derived works"
<mjg59> pwnguin: Right, which is almost certainly true
<mjg59> But given that it's almost impossible to write a Linux kernel module without including chunks of GPLed code (in the form of macros and inline functions)...
<pwnguin> ah, thread went on to declare that even the syscalls were some form of linking / derived work, at which point torvalds broke out estoppel that I do recall
<BenC> mjg59: I honestly think the kernel devs screwed themselves when they created EXPORT_SYMBOL_GPL()...it infers that other exported symbols are open to use
<mjg59> BenC: The stated policy has alwaysbeen clear
<mjg59> Which was "Consult a lawyer before you make decisions based on there being a difference here"
<BenC> mjg59: years of no-action hasn't helped either...as in, they've taken no action against companies creating or providing closed source drivers in source or binary form
<mjg59> BenC: My recollection is that there's a reason l-r-m is distributed in the way it is now :)
<BenC> source form obviously can't be attacked legally (#include <linux/module.h> isn't copyright infringement)
<BenC> mjg59: I don't see how it helps though...just the .o's are still binary, and the non-GPL wrapper's are still compiled with GPL macros and inline's embeded
<BenC> even if it isn't linked to the binary blob
<mjg59> BenC: Well, it was apparently enough of a difference to remove the immediate problem
<BenC> and vmware is distributing binary modules (linked and ready to run) for all of their vm products
<BenC> I guess I'm just frustrated at the indifference of it all...they're bad, yes...can copyright owners sue distributors of binaries compiled against their linux kernel headers? probably...will they? probably not, because then you can't be selective
<pwnguin> i think l-r-m gets a pass since technically the user is the one doing the linking?
<pwnguin> at any rate, I think effort is better spent improving nouveau than suing nvidia or users :)
<BenC> or signing meaningless redundant public statements :)
<mjg59> BenC: You're pretty free to be selective
<pwnguin> So is drm2 anticipated to stabilize in time for intrepid?
<mjg59> I suspect that to an extent the concern is losing a case
<BenC> mjg59: as in if they tried to sue and lost, it was set precedent for other vendors?
<mjg59> Yeah
#ubuntu-kernel 2008-06-24
<mjg59> You'd want a pretty definitive case before going to court
<BenC> makes sense
<BenC> plus, it would ripple all over the place
<BenC> kernel headers in glibc (LGPL) come to mind
<Kano> hi, you did not add gspca yet
<Kano> when will you do so for 2.6.26
<BenC> Kano: when we get to it
<BenC> really, asking us questions like that is like trying to predict the weather
<Kano> well the driver works, should be really easy to add
<BenC> Kano: It will get done, just priorities is all
<kirkland> rtg: i see you have committed a fix for https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/242448
<kirkland> rtg: is there a kernel built that I can install/test this?
<rtg> kirkland: not yet. I'll upload to my PPA and get it built today.
<kirkland> rtg: cool, update that bug with a pointer to your PPA.  myself and hallyn are willing to verify the fix for you.
<kirkland> rtg: we're both subscribed
<rtg> kirkland: it'll likely take a few hours.
<kirkland> rtg: that's fine... no rush, whenever
<kirkland> rtg: also, you might be interested that mhalcrow is working on a pretty small, simple patch to ecryptfs that would give sort of a "root_squash" capability
<kirkland> rtg: you'd add an option to the mount params, like ecryptfs_exclusive_access_uid=1000 or something, and the kernel would check that on all reads/writes to the mounted files
<kirkland> rtg: i think you were asking about something like this earlier
<rtg> kirkland: which addresses my concern about root visibility on multi-user machines?
<kirkland> rtg: yup
<kirkland> rtg: the 5-minute patch he threw together when I asked him about it looks like: http://halcrow.us/~mhalcrow/patches/ecryptfs-excl-access-20080623.txt
<kirkland> rtg: i'm hoping he'll get something like this into mainline soon....
<kirkland> rtg: are we sticking with 2.6.26 for intrepid?
<rtg> kirkland: 2.6.26 is the target version
<rtg> kirkland: of course, we can cherry-pick some upstream fixes like this one.
<kirkland> rtg: that's sort of what i was asking
<kirkland> rtg: okay, let's see it get upstream first
<rtg> kirkland: instead of "root_squash" capability, it looks more like "exclude foreign euid" capability. Can't root get around the UID issue by running a script in the context of the UID?
<kirkland> rtg: yeah, this idea spun off the "root_squash" idea, and is intended to be even more specific
<kirkland> rtg: but as you say, root can change his uid.....
<rtg> kirkland: while this mount option would keep other users out, it only makes it slightly more difficult for root to go snooping.
<kirkland> rtg: true...  hmm, ultimately, this should be key-based
<rtg> kirkland: kees might be a good guy to ask about this. perhaps there is an AppArmor or SMACK approach the is not vulnerable to root snooping.
<kirkland> rtg: well, there's certainly an SELinux approach
<kirkland> rtg: add some SELinux hooks to ecryptfs is a long term goal of the ecryptfs developers
<kirkland> rtg: but that's non-trivial, IIUC
<kirkland> rtg: i'm not sure about AppArmor or SMACK
<kirkland> rtg: you'll get a kick out of this....
<kirkland> rtg: ->  mhalcrow: could we prevent root from running a script as that user and accessing the data?
<kirkland> <mhalcrow> Yes. It's called SE Linux
<rtg> kirkland: well, I guess that makes sense :)
<kirkland> rtg: <mhalcrow> If you don't want root to be root, that's what you really need.
<SEJeff> label based security does things path based security can't
<kirkland> rtg: if you have a minute, i'd like to invite mhalcrow here.  i'd like to decide whether or not it's of value to do the exclusive_uid thing, or not, and i'd like your opinion on the kernel matter at hand
<rtg> kirkland: the patch doesn't look so bad, but it doesn't really solve the root snooping issue, so is it worth it? It does keep unprivileged users from looking around.
<kirkland> rtg: true for unprivileged users, but that can be handled just by normal DAC, chmod +700
<rtg> kirkland: is that the default mount permissions?
<kirkland> rtg: not a mount issue; ownership on the mountpoint/device itself
<rtg> kirkland: right, thats what I meant
<rtg> kirkland: so, unless there is a good use case, it doesn't seem that worthwhile.
<kirkland> rtg: okay, we'll need to look into the proper way of squashing root priv's with apparmor/selinux
<rtg> kirkland: that seems like the right approach.
<kirkland> rtg: okay, i'll confer that over, thanks for the sounding-board
<rtg> kirkland: in fact, its likely the same problem the folks at the NSA tried to solve with SELinux. They didn't want their admins looking at security stuff.
<kirkland> rtg: yup
<kirkland> mhalcrow: rtg and I talked this over, and we don't think this is going to gain us anything over DAC (as you mentioned)
<kirkland> mhalcrow: other than basically being able to specify the DAC at mount time
<kirkland> mhalcrow: and not worrying so much about file/dir permissions
<mhalcrow> Right. It would just be a lazy way to apply blanket dac on the mount.
<kirkland> rtg: do you see any value to that?
<mhalcrow> I have always had a policy of not introducing redundant access control, because that tends to increase complexity and opportunities for unintended consequences.
<rtg> kirkland, mhalcrow: seems like a false sense of security to me. really, this is an issue on a multi-user machine, so we need a bigger hammer then just UID protection.
<mhalcrow> Keyring perms, ugo/rwx, capabilities, and SELinux provide everything you need for any access control model you have in mind.
<rtg> mhalcrow: ok, then the current ecryptfs solution using SELinux is sufficient to prevent root snooping, correct?
<mhalcrow> Correct.
<mhalcrow> Keys can be labeled.
<rtg> I'm good with that.
<mhalcrow> And eCryptfs passes through lower xattr's
<mhalcrow> So the label on the lower file propagates to the eCryptfs mount.
<rtg> kirkland: so the SELinux ball is in your court. I assume this is something you'll have to add to ecryptfs-utils?
<kirkland> mhalcrow: do you know if anyone's worked with ecryptfs+AppArmor?
<mhalcrow> Seems trivially circumventable with a --bind mount, but I'd have to look more closely at AppArmor for eCryptfs mounts.
<kirkland> rtg: sure, i'll take that one.  no promises that i'll solve the root-snoop problem by Intrepid, but i'll keep working it
<leche> hey, i found a bug in the kernel, which was allrdy fixed and confirmed by the devs of lm-sensors. Hows the procedure, to get this into the ubuntu kernel?
<mjg59> leche: What's the bug?
<leche> mjg59: http://rafb.net/p/VAgiQx37.html
<mjg59> leche: Ok. File a bug on launchpad.net, attach that patch and include a pointer to the upstream discussion thread.
<leche> ok, thx
<leche> mjg59: https://bugs.launchpad.net/ubuntu/+bug/242761 is the description complete or is something missing?
<rtg> leche: its fine
<mjg59> leche: Looks ok
<leche> what do you mean with upstream discussion thread?
<mjg59> Ideally a link to the thread where it was discussed
<rtg> leche: what mjg59 means, was there any discussion of this patch on LKML? If so, then include a pointer to the start of the discussion.
<leche> rtg: no there wasnt, this was solved in irc and the lm-sensors mailing list
<rtg> leche: I thought as much. the patch looks reasonable and straightforward, so its not controversial.
<leche> rtg: ok, whats the procedure now? im just asking cause im interested
<rtg> leche: it'll eventually show up as an SRU request. The kernel won't be out much before mid-July.
<leche> thats good to hear, so i dont have to apt-pin the actual kernel
<leche> thx guys
<rtg> leche: it will also be on my PPA by tomorrow morning. http://ppa.launchpad.net/timg-tpi/ubuntu
<leche> thx alot guys
#ubuntu-kernel 2008-06-25
<emgent> heya
<osmosis> how come this link doesn't show  linux-image-.2.6.24-19-server ?  http://packages.ubuntu.com/hardy/linux-image
<crimsun_> because it doesn't pull from hardy-proposed.
<osmosis> crimsun_: I dont see that im pulling from  hardy-proposed either in my source.list. But  linux-image-2.6.24-19-server  is the latest.
<crimsun_> right, because it's now in hardy-updates
<crimsun_> once packages.u.c executes its crontab (on whatever frequency), it will be listed.
<osmosis> okay
<osmosis> crimsun_: thanks for the clarification
<crimsun_> yw
<osmosis> crimsun_: is there any other way for me to view the chanelog, besides  packages.ubuntu.com
<crimsun_> aptitude changelog linux-image-2.6.24-19-server
<osmosis> saweet
<crimsun_> you can also view https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-19.34
<lamont> zinc (kernel.ubuntu.com) will be offline starting in about 18 minutes for an upgrade
<lamont> officially it'll be down for < 4hours, practically speaking, it should be less than that by quite a bit
* lamont 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-2.6 |  Latest news: Intrepid plans open: https://wiki.ubuntu.com/KernelTeam/UDS/May2008 | Next meeting: June 24, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com | kernel.ubuntu.com dist-upgrade in progress
* lamont 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-2.6 |  Latest news: Intrepid plans open: https://wiki.ubuntu.com/KernelTeam/UDS/May2008 | Next meeting: June 24, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<lamont> kernel.ubuntu.com upgrade is complete.  enjoy.
<osmosis> is a daemon required when using speedstep ?
<berzerka> how is the CAP_SYS_RAWIO capability handled in ubuntu? i am developing a userspace USB driver and read with ioctl from /dev/bus/usb/*/*. on my gentoo machine, no problem. on ubuntu i get "Operation not permitted" and the only thing i can imagine is that the RAWIO capability is disabled. on the other hand, it doesn't even work using sudo. any ideas?
<pwnguin> capability?
<pwnguin> as in ACL, or as in kernel config?
<berzerka> i think as in ACL
<berzerka> i do raw io to device files, and read in the kernel USB documentation that i need the CAP_SYS_RAWIO capability.
<pwnguin> afaik, ubuntu doesn't enable acls by default
<pwnguin> check mount
<berzerka> i am using the device files provided by udev, not usbfs.
<berzerka> so what to look out for?
<pwnguin> usually some option like acl
<berzerka> udev on /dev type tmpfs (rw,mode=0755)
<pwnguin> (im not sure udev has acls)
<berzerka> this line? no acl...
<pwnguin> the only time i bothered with ACL was when i was trying out a ThinkFinger patch
<berzerka> well do i _need_ ACL when i want to do raw device io?
<pwnguin> I don't know =(
<berzerka> the strange thing is that it also doesn't work when i am superuser
<berzerka> and i think i read the uid 0 has all capabilities set.
<pwnguin> is it possibile that your feature is a gentoo patch?
<berzerka> no, definitely not.
<berzerka> i will try on a RHEL system, hang on...
<berzerka> (will take ~5 minutes, have to go to the lab..)
<berzerka> okay it took a bit longer.
<berzerka> (had to fix some things first..)
<pwnguin> im still here . might not be any help though
<berzerka> result: on RHEL, it doesn't work too.
<pwnguin> well I feel better
<berzerka> hehe i thought so..
<berzerka> hm okay i think i will have to read up on ACL and capabilities in general
<berzerka> i will keep you informed..
<Kano> hi BenC ,did you see this: http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.26-rc8
<BenC> Kano: yes, I did see it
<Kano> fine
<mkrufky> quick question ...  i have a driver in LUM (as of last week) and i've since fixed a number of trivial things, like codingstyle compliance, some small compiler warnings, changed all functions to static and other small things like that.  So I have a quilt series of a few patches that would update the driver in LUM.  Meanwhile, none of these fix actual bugs, so filling out a big report for each of them would be tedious and annoying.  What is the poli
<mkrufky> er, bug report, i meant
<BenC> mkrufky: if it doesn't fix bugs, then we generally don't want it in stable
<rtg> BenC: its a new driver.
<mkrufky> meanwhile, when real bug reports DO come in, i will fix them in my dev tree, which will end up merging to 2.6.27
<mkrufky> and i will not want to backport each change to the older version
<BenC> rtg: has it been released yet?
<mkrufky> (im talking about sms1xxx)
<mkrufky> sms1xxx is in LUM, but it is not in _any_ upstream kernel tree
<mkrufky> its only in my dev tree on linuxtv.org
<rtg> mkrufky: just send the updates on the kernel team mailling list. once its actually been uploaded, then we'll have to go through the SRU process.
<mkrufky> i had to push it to LUM because Dell needed it for testing
<rtg> BenC: sms1xxx is in LUM git, but not yet uploaded.
<mkrufky> "once its actually been uploaded"  <-- what are you refering to?
<mkrufky> oh, you mean released in a deb package?
<rtg> mkrufky: right. once it hits the -proposed/-updates repo its gonna be subject to SRU policy.
<mkrufky> so, does that mean that it is not subject to that policy yet?  
<rtg> mkrufky: correct
<mkrufky> ...in other words, am i best off just sending in a "sync to dev tree" patch now before it is uploaded?
<rtg> mkrufky: yes
<mkrufky> ok, in that case i have some merging to do ... bbiab :-)
<BenC> mkrufky, rtg: Ok, if it's not uploaded, then updating it is ok
<BenC> well, s/ok/fine by me/ :)
<mkrufky> thanks
<rtg> mkrufky: I won't upload LUM before about July 7.
<mkrufky> ah, i didnt realize there was that much lead time... ok, cool
<rtg> mkrufky: the point release is scheduled for Jult 3, and I'm off rafting through the 6th.
<mkrufky> OK
<mkrufky> also, looks like i will end up getting all the hvr950q performance tweaks into 2.6.26, so we will most likely not need it in intrepid LUM at all
<BenC> mkrufky: nice
<BenC> Ok, I stopped being a lazy bastard and rebased to -rc8 and pushed
<Kano> nice boy
<Kano> and you disabled XEN, nice for nvidia
<zul> BenC: fyi redhat pushed their xen pvops/dom0 tree to 2.6.26 as well 
<exodos> In some situations it is needed to run 32bit userland with 64bit kernel (we're running hardy under xen like this). Now you have to download deb packages and manually issue dpkg -i --force-architecture *.deb. In debian, in 32bit repositories they have package called linux-image-2.6-amd64, which is installing the latest 64bit kernel. Would it be possible to add similar funcionality to ubuntu kernel? 
<mjg59> Only if you want certain things to break in bizarre ways
<exodos> mjg59: what do you mean?
<mjg59> CPUs in 64-bit mode aren't perfectly compatible with CPUs in 32-bit mode
<exodos> mjg59: can you point me to more infos about this issue?
<mjg59> exodos: The prime issue is that vm86 mode doesn't exist in 64-bit mode. That's probably not a huge problem
<mjg59> exodos: The other one (which is a bug, but not always trivial to track down) is that ioctls need to be thunked from 32-bit to 64-bit
<mkrufky> some (but not all) provide a compat_ioctl32 wrapper to handle that compat
<mkrufky> oops, some but not all kernel subsystems, that is
<BenC> usb printer I think is the main one that doesn't
<BenC> but that may have changed recently
<exodos> we're running it under xen, so now real hardware there...
<BenC> exodos: but if I make a 64-bit kernel available to 32-bit userland, people wont use it just under xen :)
<BenC> exodos: what purpose do you have of running 32-bit userland under a 64-bit kernel?
<exodos> I would say its their problem
<exodos> we have to use 64bit kernel with latest xen
<exodos> 32bit kernels are just simply not working with it
<exodos> and 32bit domU is used as a terminal server (LTSP)
<BenC> well, you have an easy work around, so I say go with it :)
<exodos> you mean with wget and dpkg ?
<BenC> exodos: it would be pretty simple to automate dpkg-deb to convert the deb to amd64, and create a local repo to add to sources.list
<BenC> some shell scripting from a cron job would ease your burden
<BenC> which, to put it bluntly, is acceptable to me compared to the burden we would get from users trying to run a 64-bit kernel in 32-bit userland :)
<exodos> ok, so to summarize: i shouldn't expect mentioned funcionality in interpid. Am I correct?
<BenC> that's correct, but then maybe intrepid's 32-bit xen kernel will work better for you
<exodos> thx for help, bye
<kirkland> rtg: I'm running your linux - 2.6.24-20.35ubuntu kernel, but it doesn't appear to fix the ecryptfs issue
<kirkland> rtg: can you confirm that that kernel has the cherry picked fix I identified?
<kirkland> rtg: 2.6.24-20.35ubuntu3, to be precise
<rtg> kirkland: I am ' dget http://ppa.launchpad.net/timg-tpi/ubuntu/pool/main/l/linux/linux_2.6.24-20.35ubuntu3.dsc' which has the last commit SHA1 noted in the changelog entry. However, I believe it has the ecryptfs commit: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=6f137e40d6d2456fd23b0f2f342eabd44c50656a
<rtg> I'll know in a couple of minutes.
<rtg> kirkland: last commit in that upload was 12c0aa7d1af0468d5c8941ee30056bc3e74c2c07, so the ecryptfs commit is definitely there.
<kirkland> rtg: :-/
<kirkland> rtg: bummer
<kirkland> rtg: what kind of shape is the 2.6.26 kernel for intrepid it?  is it ready to run/boot?
<rtg> kirkland: yep -  I think BenC has been running it for awhile.
<kirkland> rtg: what about in a KVM?
<kirkland> rtg: i've had no success running intrepid + 2.6.26 in a kvm
<rtg> kirkland: likely, but I couldn't say for sure.
<voicu> Hi, i have the kernel linux-2.6.24-19-generic and i'm trying to install vmware tools. they need to be compiled and require the headers
<voicu> when configuring starts it says that the files in /usr/src/linux-headers-2.6.24-19-generic/include don't match the kernel
<voicu> any ideas besides vmware's fault?
<voicu> uh, is my question offtopic? :D
<rtg> voicu: I think vmware supplies the binaries, so they should be providing an update any day now.
<voicu> so they are in the repositories or something?
<rtg> voicu: right, one of the partner repositories iirc.
<voicu> rtg: what should i look for? xserver-xorg-video-vmware?
<voicu> That's already installed
<voicu> But the system doesn't work as fast as it used to when I had the compiled vmware-tools
<rtg> voicu: dunno, I've not used vmware in a couple of years.
<voicu> rtg: anyway, any ideas on the kernel version thing?
<rtg> I have to do pretty much all of my work on bare metal.
<voicu> I might need to compile stuff later too
<rtg> voicu: I notified the right person at Canonical about the ABI change a couple of weeks ago (who should have contacted vmware). I guess you'll have to wait until vmware produces an ABI compatible package.
<voicu> aham...
<voicu> any way to change that? can't i put something in include/linux/version.h?
<voicu> *quickfix
<rtg> voicu: I have no idea. feel free to go exploring.
<voicu> ok then, thanks for the info
<BenC> rtg: know anything about the heci driver in lum?
<rtg> uh, what is heci?
<rtg> BenC: its an Intel driver, is it already upstream?
<rtg> guess not.
<BenC> Doesn't look like it
<BenC> it's the AMT_HECI
<rtg> BenC: something related to http://www.intel.com/technology/platform-technology/intel-amt/ ?
<BenC> yeah
#ubuntu-kernel 2008-06-26
<osmosis> Can anyone tell me what this from my dmesg is being caused by? http://dpaste.com/59176/   2.6.24-19-server
<Kano> hi BenC , i wanted to compile, but then o gut makedumpfile - command not found. what is that tool and whats the package name?
<Kano> i do not even find a makedumpfile package for intrepidÃ
<Kano> ok, found it in launchpad, but not with packages.ubuntu.com
<saftsack> hi
<saftsack> i tested 2.6.26-rc8 and i get tty_wakeup errors on connecting through the connect.sh script
<Kano> BenC: in lrm you made one space too less in the changelog
<Kano> also dont forget -3
<BenC> Kano: -3 isn't going out until alpha 1 is out
<BenC> Kano: and I'd appreciate if you didn't bark out orders to me
<BenC> Kano: makedumpfile is in universe, and it's used to create a vmcoreinfo file so that we can easily capture crashdumps without have a full linux-debug-image installed
<Kano> could you fix lrm
<Kano> BenC: dont you think it has to be in main when you use it for the kernel?
<BenC> Kano: it has to get moved by an archive admin, which is in-progress
<Kano> well i put it in my repository
<Kano> now i only want to be able to comple lrm to try it
<BenC> what are you talking about in lrm?
<Kano> the changelog
<Kano> a) you missed one space
<Kano> in the ABI Bump line in front of the *
<Kano> also i still did not get why you need a tab in front of all?
<Kano> last change would be a 2nd abi bump
<Kano32> well it seems i have to disable that uvesafb, i dont know how to use it...
<Kano32> CPU[Dual Intel Core2 6600 @ clocked at 1600.000 Mhz]  Kernel[Linux 2.6.26-3-generic i686]  Up[-11min-]  Mem[-115.7/2023.4MB-]  HDD[-760GB(13%used)-]  Procs[-150-]  Client[Konversation 1.0.1]
<Kano32> make sure that the v86d helper is installed and executable
<Kano32> hmm
<Kano32> is there a package with it?
<Kano32> or how to you use uvesafb?
<Kano> gspca still missing
<Kano> also how to build only the firmware package from lrm?
<Kano> ok, found it myself, binary-indep...
<Kano> hmm using the /lib/firmware dir creates bad dependency problems
<Kano> conflicts with ivtv-utils, or did you strip the firmware out of it?
<Kano> hmm looks like
<Kano> why does the package with the firmware depend on binutils-static?
<Tophat> what IDE do most of you use?
<Tophat> ..if any.?
<bdmurray> BenC: ping
<BenC> bdmurray: yo
<bdmurray> BenC: Its not clear to me why my PS3 won't boot 2.6.24.  I can't find any bug reports or anything but vague forum posts.
<BenC> bdmurray: I know it wont, but I forget why...ps3 guys are working on intrepid (linux-ports) though
<BenC> bdmurray: mine is still running gutsy
<bdmurray> I successfully upgraded to Hardy just can't run that kernel.  I'm not sure what to do with Ubuntu on it anyway though.
<BenC> bdmurray: download the cell enabled distributed.net client and crank out some hashes :)
<BenC> ps3 is really only useful as a cell development platform, IMO
<bdmurray> BenC: heh, I'd have to fight with the kids for access to it
<BenC> my ps3 mostly just sits on the folding@home client
<BenC> and some guitar hero III every now and then
<BenC> I use it as a blueray player more than anything else :)
<bdmurray> I haven't gotten the remote yet, do you need it?
<BenC> Nope, just use the controller
<bdmurray> Oh, sweet!  You think I would have just tested it.
<BenC> buying blueray movies means I have the benefit of telling people no when they ask to borrow movies now
<BenC> that will only last but so long though
<bdmurray> heh
<lapo> hi
<lapo> is there a kernel patchset somewhere to better support intel atom processors? (frequency scaling for example)
<rtg> lapo: send a note to Oliver Grawert ogra@canonical.com. He has recently been working on an Atom based unit.
<lapo> rtg: thanks I'll do it
<BenC> doesn't mid better support atom?
<Tophat> so lemme get this right, is MID gonna be for mobile phones/smartphones someday?  almost an alternative to windows mobile?
<rtg> Tophat: MID is targeted towards netbook class devices, e.g., those with a somewhat smaller display. 
<Tophat> eeepc type deal?
<rtg> right, displays that require reformatting of applications.
<Tophat> right on. thanks mate
<Tophat> is there any plans to do an ubuntu for phones?
<rtg> Tophat: there is an Ulta-mobile project, but don't think its targeted at phones because of the telco stack required.
<Tophat> rtf - excellent ty mate
<Tophat> rtg - you use any IDE for kernel stuff?
<rtg> Tophat: other then vi?
<Tophat> sure
<rtg> Tophat: the only other editor I occasionally use is Visual SlickEdit 
<rtg> but no IDEs per se
<Tophat> right, i was just hoping to find a GUI editor for working on the wireless b43
<rtg> Tophat: well, vs is pretty good, but it does cost money.
<mkrufky> what are you looking for in an IDE?  if all you want is codingstyle enforcement, kwrite, gedit, emacs, anything will do the job given the proper configuration
<Tophat> mkrufky - something with a side panel that i can have multiple files open and easy to navigate them all.  something easier than having a million terminal windows open
<mkrufky> gedit supports tabs
<Tophat> right on thanks mate. dunno why i haven't tried it before... ><
<mkrufky> :-)
<mkrufky> I been using gedit for this stuff a lot more now that I've basically moved most of my machines to Ubuntu
<mkrufky> On a KDE machine I might use kwrite instead
<mkrufky> and i always use emacs when Im in a text shell over ssh
<mkrufky> kwrite is nice, it lets you expand and collapse functions, prototypes, structures, #defines, etc
<BenC> mkrufky: so does vim :)
<mkrufky> yes, i never really used vim much ...  
<mkrufky> but i hear its the best
<JanC> SciTE can do the expand/collapse stuff too  ;)
<lifeless> hi
<lifeless> what kernel should I run on my old pentium firewall:) I was running -386 but the hardy one doesn't.
<rtg> dapper
<rtg> lifeless: what does that mean, the hardy one doesn't?
<lifeless> uhm, I'm not entirely sure - something about 'cannot read system configuration' or 'no configuration found' 
<lifeless> then it appears to go away into lala land
<lifeless> I've just plugged a monitor and keyboard in, so I can dig further - but I'll go offline during reboots :)
<rtg> lifeless: what is the latest release that works?
<lifeless> I booted 2.6.15-23-386 #1 PREEMPT Tue May 23 13:49:40 UTC 2006 i586 GNU/Linux
<lifeless> and it worked
<lifeless> its the most recent kernel before the one the hardy upgrade installed
<lifeless> (that is on the machine)
<rtg> lifeless: then why wouldn't you stay with dapper?
<lifeless> rtg: dappers old, hardies shiny
<rtg> lifeless: dude, this is a firewall.
<rtg> if it works, then don't fix it.
<lifeless> rtg: yes, which is why it was still on dapper; but isn't dapper about to go out of support?
<Nafallo> lifeless: wasn't released five years ago yet :-)
<rtg> lifeless: 2 more years yet. I'm actively maintaining it as we speak.
<lifeless> anyhow, I figured I may as well be one of the pre '8.4.1 is a candidate upgrade' folk
<Nafallo> hmm. warty wasn't released five years ago :-O
<lifeless> rtg: I'm not stressed by this, there is no urgency - I've changed the default kernel. But if its not my machine, or if -386 is expected to load on a model name      : Pentium 75 - 200
<lifeless> then I can potentially save other folk some grief when they do upgrade
<rtg> lifeless: I think I have some machines of that vintage. 
<rtg> lifeless: you leave your firewall alone and I promise to do some -386 testing. After all, we'd miss your shiny presense if it gets trashed :)
<lifeless> rtg: :)
<lifeless> rtg: thank you ; if you want any sort of tests run by me just let me know
<rtg> lifeless: in the meantime dapper is scheduled for some CVE updates.
<lifeless> rtg: should I file a bug at this point? (I'm guessing not as I have no real data to give ...)
<lifeless> rtg: kernel ones?
<rtg> lifeless: yeah - unless you can capture a screen or something, the bug report won't be worth much
<lifeless> rtg: [apt is pointing at hardy now; but I can grab dapper kernels...]
<rtg> lifeless: yes - kernel updates. still several days away.
<lifeless> rtg: I'll keep an eye out. Unless its remote-exploit its low stress for me on this box
<rtg> lifeless: are you running hardy userspace with a dapper kernel?
<lifeless> rtg: I think so
<rtg> lifeless: huh, I'm surprised udev works.
<lifeless> rtg: imagine me chortling
<lifeless> rtg: it was my 'oh damn it doesn't boot; ok lets try a previous kernel' reaction
<rtg> lifeless: seems like a reasonable approach.
<lifeless> I'll install the dapper upgrade when it comes out, and take a photo of the hardy fail at the same time
<lifeless> thanks heaps
<rtg> lifeless: k
<kirkland> rtg: hey
<rtg> kirkland: dude
<kirkland> rtg: you wanna quit sending kernels to your ppa long enough for me to get one installed?  :-)
<rtg> kirkland: its like a daily event :)
<kirkland> rtg: :-)
<kirkland> rtg: it takes FOREVER to build
<rtg> I deleted all the kernel packages while this one  is building.
<kirkland> rtg: so I've tested the Intrepid kernel, and it does NOT suffer from the ecryptfs bug
<kirkland> rtg: yeah, I know ;-)
<kirkland> rtg: i'm still trying to verify that cherry picked fix
<rtg> kirkland: ok, I'll upload the other packages as soon as the kernel build is done.
<kirkland> rtg: i tried it yesterday, and it didn't look like it solve the problem, but I'm not sure I if I pulled the right package or not
<rtg> kirkland: I suspect you did.
<rtg> kirkland: I know for sure one has that patch
<kirkland> rtg: i mean, would that fix have been in the linux-image-generic package, or one of the LUM (and friends)?
<rtg> s/one/this one/
<kirkland> rtg: ie, ecryptfs is built as a module
<rtg> linux-image-generic, its a core kernel patch, wasn't it? yes - i'm sure it  was.
<kirkland> rtg: it was for the ecryptfs filesystem, which is built as a module
<rtg> kirkland: built as a module, but part of the kernel package
<kirkland> rtg: ah
<kirkland> okay
#ubuntu-kernel 2008-06-27
<ceekay> trying to understand how kexec/kdump works and hoping someone might be able to help me out... when i try to kexec -p /vmlinuz --initrd=/initrd --append=root=/dev/sda1, i get "locate_hold failed" anyone able to point me in a direction? cat /proc/iomem shows that i have an entry for "Crash Kernel" (i booted with the crashkernel=64M@16M option)
<ceekay> sorry "locate_hole_failed", not "hold"
<mkrufky> BenC: fyi, hermann tends to speak to the list in his emails moreso than to those in the to: field  ;-)
<BenC> mkrufky: I gathered :)
<mkrufky> hehe
<BenC> ceekay: on intrepid, just install linux-crashdump-generic
<BenC> ceekay: reboot, and all is good
<ceekay> benc: I'm trying to backport to 7.04 if that is at all possible :\
<ceekay> rather, trying to understand if it is possible
<ceekay> just pulled the source pkg kexec-tools (20070330-4ubuntu3) from hardy
<BenC> ceekay: IIRC, 7.04 kexec is broken :)
<ceekay> it compiles and installs... but i guess the question i'd need to ask here, is does the kernel support it or how can i find out
<BenC> kexec and/or the kernel
<ceekay> eek
<ceekay> there a way i can check?
<BenC> the kernel supports it, but it's not working
<BenC> ceekay: if you get the above error, then it doesn't work
<BenC> ceekay: the kernel supports it, else you wouldn't see the entry in /proc/iomem
<ceekay> so is a newer kexec-tools not going to resolve this issue? it's broken in 2.6.20-16?
<ceekay> rather in the kernel itself, not just the kexec tools
<BenC> right
<ceekay> quick way to find out i guess... i just ran kexec -p..etcetc... using the new kexec tools package, i didn't get the "locate_hole_failed" error... hit alt+sysrq+c and it appears to have just re-execed the kernel
<ceekay> would seem to me that it worked
<ceekay> and i now have an 80MB living in /proc/kcore
<ceekay> BenC: did i just prove that it works? (i don't want to get too excited here)
<ceekay> probably a stupid question- how can i get the vmlinux file for a released kernel package (i.e. 2.6.20-16)? do i have to download+extract the kernel source package, copy my /boot/config-2.6.20-16 to /usr/src/linux, then make?
<ceekay> linux-image-debug seems to have the uncompressed vmlinux but it doesn't appear to match the regular kernel
<rtg> kirkland: everything is built in my PPA
<BenC> ceekay: sounds good to me
<BenC> ceekay: apt-get install linux-image-debug-generic
<BenC> ceekay: installs the vmlinux with debug symbols that matches the kernel
<ceekay> BenC: hm... the program "crash" didn't seem to like it...something about mismatched banners
<ceekay> interesting... using the /etc/init.d/kdump defaults, kexec isn't happy... i think it's the irqpoll option on my system that causes it to get stuck in an infinite loop
<ceekay> sorry the warning was about linux_banner, but crash seems to error out saying that /boot/vmlinux-2.6.20-16... and /var/crash/kernel.0 (dump that i copied from /dev/kcore after causing a dump)
<ceekay> don't match
<BenC> ceekay: probably your kernel is not the latest one, run apt-get update
<ceekay> BenC: both packages say 2.6.20-16.35 :\
<ceekay> i know 2.6.20-17 is out, but as long as these two packages match versions seems like it should work
<BenC> ceekay: sounds like you have something askew on your system
<ceekay> quite probable
<BenC> ceekay: the -debug package is the vmlinux that was used to build the standard vmlinuz kernel
<BenC> it's not even a separate build, it's an exact match
<ceekay> BenC: one last question for you.. looking at https://launchpad.net/ubuntu/+source/kexec-tools it appears that you did the scripts to copy the dumpfile somewhere... if i'm looking to backport this to 7.04, is this something that's only in the 8.10 initrd's?
<BenC> ceekay: you will need kexec-tools, grub and makedumpfile from intrepid
<ceekay> noticing the boot flag kdump_needed that gets added by /etc/init.d/kdump to the kexec on panic APPEND line
<ceekay> ah, hadn't realized makedumpfile is a package
<BenC> it's in universe in intrepid only
<ceekay> gotcha
<ceekay> is the new grub really necessary?
<BenC> yeah
<ceekay> 7.04 seems to do the crashdump option correctly
<ceekay> BenC: any specifics on what the new grub does differently?
<ceekay> last changelog entry i see seems to have been in 7.04 timeframe
<ceekay> by you :)
<BenC> ceekay: the crashdump= is handled differently
<BenC> automatically added
<ceekay> BenC: crashdump=1 seems to be handled the way i'd expect it to be currently... i set it to 1, run update-grub and then i get a new alt boot option that has the crashkernel64M@16M option appended to it
<BenC> ceekay: that is removed
<BenC> but you're free to figure it out on your own :)
<ceekay> gotcha :)
<ceekay> thanks so much for you help on this... looks like i have a working backport of current kexec-tools to 7.04...
<ceekay> only thing i really had to change was removing "irqpoll" from the append list in /etc/init.d/kdump
<ceekay> BenC: oh and btw... my debug image does seem to work... i think i had a funky crash dump... just did a clean reboot + sysrq/alt/c, then cp /proc/vmcore /var/crash/kernel.0, now crash reads the dump file just fine :)
<Kano> hi
<Kano> did somebody notice that the latest 2.6.26 snapshot (and rc6 i tested before) have got problems with dell vostro 1000?
<Kano> it only boots when acpi=off - a bit brutal for a laptop
<Kano> amd chipset with integrated Xpress 1150 gpu
<penfold_99> is anyone here working on kvm?
<zul> penfold_99: #ubuntu-virt
<rtg> kirkland: have you talked to upstream about ecryptfs and the fact that the 'eCryptfs: remove unnecessary page decrypt call' patch did not fix the issue?
<kirkland> rtg: i have a 10am meeting with them today
<kirkland> rtg: that's tops on the list ;-)
<rtg> kirkland: cool. I looked through subsequent commits for 2.6.25 and 2.6.26, but didn't see anything that might make a difference.
<kirkland> rtg: yeah, this is bothering me
<Kano> rtg: could you add gspca to 2.6.26
<rtg> mdomsch: so how long should a BIOS update take on an Inspiron 1420? A00 --> A08. Its been at the 'Performing BIOS Update...' screen for over 10 minutes.
<Kano> rtg: also uvcvideo
<Kano> rtg: dos mode?
<rtg> Kano: why are you asking me? BenC is the Intrepid dud right now. I'm working on Hardy stability issues.
<rtg> s/dud/dude/
<Kano> but why do you change it then?
<Kano> when you look at changelog
<rtg> Kano: because we have changed roles.  Look at who has made the last dozen Intrepid commits.
<Kano> the last was you
<Kano> when you really look there..
<Kano> ok before it was benc
<rtg> Kano: forward porting a Hardy fix doesn't count.
<Kano> ;)
<mkrufky> Kano: can you please lobby the gspca and uvcvideo folks for an upstream merge?
<rtg> Kano: besides, it would be a hell of a lot easier to keep track of what is missing if you sent an email, or better yet a web page somewhere. IRC logs just get lost.
<mkrufky> Kano: if they finally merge into upstream, this issue will be solved for _everybody_
<Kano> sure, just kanotix users already test you kernels ;) and they missed em *g*
<mkrufky> Kano: especially us v4l/dvb folks, who are constantly (incorrectly) getting support requests for those two drivers
<Kano> one system - dell vostro 1000 - does not boot it without acpi=off, any idea
<rtg> not off-hand. turn off the splash screen during boot and see where it croaks.
<mdomsch> rtg, not sure, I haven't tried on one of those
<Kano> well you dont see much
<mdomsch> rtg, generally not quite that long though; several minutes, but not 10+
<rtg> mdomsch: its still flashing. drat. I hope its not toasterized.
<Kano> i guess it has already problems to access hd
<Kano> due to missing irqs
<johanbr> I updated the bios on my 1420 and it didn't take long at all. I didn't time it, but it didn't seem to be longer than a minute.
<rtg> mdomsch, johanbr - this is one of the original prototypes, so maybe it has other issues.
<rtg> well, it power cycled OK, but its still at A00.
<rtg> guess I'll leave it be.
<BenC> Kano: already said those drivers will get into 2.6.26, then the priority is there
<Kano> well whats your priority?
<BenC> Kano: bugging us about it doesn't make it happen any faster
<BenC> Kano: my priority is getting the tree stable...and I can't even make an upload till after alpha 1, so there's no rush
<Kano> when is alapha1 planned?
<BenC> Kano: priority right now is stability and required drivers for booting and testing
<BenC> Kano: was supposed to be by today, but I haven't been updated on the progress in a few days
<Kano> i already made a live cd with 2.6.26, no problem booting
<BenC> Kano: as we've explained before, our criteria for a milestone CD != the same priority for yours
<BenC> we have milestoned bugs that need to get fixed first, and we have way more testing to do than "boots for Kano"
<mkrufky> BenC: when should I plan to have my LUM stuff for intrepid ready to pass on to you?
<BenC> mkrufky: if by lum you mean ubuntu/ in the main tree, then give me something to pull from :)
<mkrufky> i'm imagining i have a month yet before it matters at all
<Kano> mkrufky: i thought it is just patched now in like in 2.6.22?
<mkrufky> Kano: correct, i said LUM by accident
<BenC> mkrufky: just be aware of the milestones and freezes
<BenC> mkrufky: initial code drop should be soon, easier to justify patches late in the cycle than full drivers
<mkrufky> BenC: ok, in that case, is it OK if I wait for 2.6.26 upstream release first?  If my hvr950q performance tweaks get in to 2.6.26, then it will be less changes that I'll have for you
<BenC> mkrufky: Sure, I would think 2.6.26 release would be within a couple weeks timeframe
<tseliot> ï»¿Kano: why don't you use DKMS with gspca and ï»¿uvcvideo (with the sources from upstream) until the kernel team updates the drivers? It should be trivial to do so.
<mkrufky> yes... hopefully within the week.  Linus took a vacation (i think) and he hopes to not push out another -rc
<mdomsch> rtg, you might try using 'biosdisk' from http://linux.dell.com/projects.shtml#biosdisk, and an EXE from support.dell.com
<rtg> mdomsch: k.
<Kano> tseliot: i use something else, just mentioned that these driver are not there where i expected em
<tseliot> Kano: ah, ok
<Kano> but as they easyly compile they should be simple to add, not really much time consuming i think
<Kano> you discuss longer then it actually takes time
<BenC> Kano: it's not the time, it's working on something that isn't as important as the other things I'm working on
 * BenC stops explaining priorities to Kano
<BenC> Let's make it simple, if I worked on everything that everyone pointed me to that was "simple and quick" it would probably take me 3 weeks to complete all those "simple and quick" tasks
<BenC> all the while, the difficult, and more important things wouldn't get done
<Kano> when i do the patch,will you add it?
<BenC> Kano: it will take me the same amount of time to import your patch as it would for me to cp -a the driver over and add it to the build, so no
<UlfJack> hi
<UlfJack> what's the right way to debug a freeze? i've searched on google, but havn't come up with anything definitive. kern.log is empty and the crashdump kernels don't seem to do anything either...
<rtg> UlfJack: perhaps minimize the number of devices that you have active?
<UlfJack> memtest passes, and xp seems to run stable as well...
<rtg> UlfJack: since your IRC sessions comes and goes, I suspect you have a wireless device.
<UlfJack> i've had to reboot because it freezes
<rtg> UlfJack: 'it' being a wireless device?
<UlfJack> no, i'm connected via cable
<UlfJack> the laptop has a built-in wireless card, but that never worked, so it's switched off in the bios
<UlfJack> no overclocking, no restricted drivers, i'm trying to narrow it down, but i'm totally stumped
<UlfJack> i'm not doing anything specific, it just freezes randomly - it doesn't seem to make a difference if i'm using firefox, openoffice, freecell, or just a console
<BenC> UlfJack: running what version of Ubuntu?
<UlfJack> 8.04
<UlfJack> it happens with the -17, the -19, and the -rt kernels
<UlfJack> hmm, maybe i should reinstall -18 to see if it freezes too
<BenC> UlfJack: likely wont help
<UlfJack> compositing is disabled, too
<BenC> UlfJack: try running with no network for a bit
<UlfJack> it also crashes when the network cable is disconnected (in my experience, i didn't just pull the cable ;)
<UlfJack> i had it crash on me spectacularly when i tried to give a presentation the other day :(
<BenC> odd
<BenC> is it a solid lock, or do the caps/num lock leds blink?
<BenC> BTW, anyone interested, 2.6.26-3.7 is about to be uploaded
<UlfJack> i'm sorry for the load of join/quit messages, but i have to reboot every 5 min it seems :(
<johanbr> What's your laptop model?
<BenC> UlfJack: ï»¿is it a solid lock, or do the caps/num lock leds blink?
<UlfJack> it's an old lifebook s60, 1 GHz, 512 MB
<UlfJack> they don't blink, it just stops (no change on the screen) and ignores alls keyboard/mouse input
<johanbr> Have you found *any* kernel that's stable?
<UlfJack> iirc 7.10 was running stable
<BenC> UlfJack: have you tried switching to console and waiting to see if the hang still occurs? Maybe get some output that way
<BenC> make sure to boot without the quiet kernel option
<UlfJack> does quiet make a difference for console output on crash/freeze?
<UlfJack> of course now it doesn't freeze :(
<UlfJack> oh well, off to bed
<Kano> hi rtg , BenC , do you want to see a pic with the error of the vostro 1000?
<ceekay> BenC: after all that advice yesterday (and my excitement that it was working), i can't seem to get kdump working on another one of my systems running (the one i _need_ it to work on)... seems to kernel panic when loading the capture kernel... i see "unknown_bootoption" in the stack trace and everything else above that seems to sound like initial filesystem sync/load. guess i may have to take back my "kdump works on 7.04" statement... any thoug
#ubuntu-kernel 2008-06-28
<ceekay> BenC: looks like kdump/kexec is OK on 7.04... the kernel i was using for the crash capture had PAE enabled and VM_SPLIT was modified to 3G kernel / 1G user. I'm guessing one of those two didn't like loading via kdump. Used a  stock 2.6.20-16-generic kernel and it seems ok.
<ivoks> hi guys
<ivoks> did anyone reported tcp problems while connecting to solaris?
<ivoks> i mean... i can't download this one:
<ivoks> http://student.mef.hr/TEST.jpg
<ivoks> with hardy, but i can with dapper
<ivoks> every communcation dies after ~40kbytes
#ubuntu-kernel 2008-06-29
<baconbits> hi i have a question about a kernel driver fix avilability in a netboot image
<baconbits> is this the right place for this type of question ?
<user_> hmm, why cant i find linux source 2.6.24 on ubuntu launchpad package search? does it exist?
<JanC> user_: search for linux...
<user_> JanC: i can find linux-source for 2.6.22, but not for .24. still thats what is running, if you have updates installed.
<user_> i firefox-strg-f in all pages for 24. nothing.
#ubuntu-kernel 2009-06-22
<zeroprog> hey guys....im having a problem...i read the first 4 chapters of allesandro rubini driver book and still have no clue how to use what ive learned  or how to apply it to my device...is there a simple source in the kernel that i may be able to decipher
<samir_> hello there, i just wanna downgrade my kernel to 2.6.26*
<samir_> so i just have to install linux-image-2.6.26* ??
<anubhav> samir_: that should work
<samir_> anubhav : plus, that will install 2.6.26 modules for me? that's what i'm interested in
<anubhav> samir_: yes 
<anubhav> samir_: but i am not sure if .26 is present in the ubuntu repository
<samir_> anubhav maybe in packages.ubuntu.com
<apw> NCommander, am looking at the ports issue
<apw> bah all the configs are in the toilet
<apw> TheMuso, you about?
<StevenK> apw: Given the time, TheMuso is probably dinner-ing
<apw> yeah, i have a handle on the mess now thankfully
<StevenK> apw: This will be another .30?
<StevenK> apw: You should also be aware that i386 failed to upload (there's a new state for you) due to version number fun
<apw> is that the linux-doc breakage?
<StevenK> Yup
<apw> yeah can't fix that until rtg gets in as he has the tree, but we are aware
<apw> rtg the GEM/PAE changes we were testing seem good, and indeed airlied has merged them already.  in theory that makes 2.6.31-rc1 capable of KMS on PAE too
<rtg> apw: I have a test system. where have you stashed test kernels? your PPA?
<apw> yeah in a ppa .... https://edge.launchpad.net/~apw/+archive/red
<apw> (gah edge is slow today)
<apw> rtg i note that the effect of pulling all the ports kernels back into our kernel has slipped the 386 kernel over to non-ports status
<rtg> mdz: if I respun linux-meta and uploaded linux-meta_2.6.30.9.9 (with your linux-doc patch), then the existing linux-doc package would eventually get reaped, right? That should clear up any conflicts in case there is another 2.6.30 kernel upload (which I think we should do)
<mdz> rtg: did you see my message to kernel-team@ from yesterday?  that's #2 out of the 3 options I suggested for how to fix it.  the trouble is that the old linux-doc package wouldn't get reaped right away, and might require manual Launchpad hackery, so Colin was (understandably) not thrilled with that idea
<rtg> mdz: why would it need manual intervention?
<mdz> rtg: when a source package stops building a binary package, Launchpad doesn't just delete the old one.  it hangs around for a grace period
<mdz> "didn't get built" has different semantics from "was explicitly removed"
<mdz> rtg: this is because it's hard for LP to tell the difference
<mdz> "maybe this source package doesn't built that binary package anymore, or maybe it just hasn't built yet"
<mdz> s/built/build/
<rtg> mdz: what is the grace period? a couple days?
<mdz> rtg: I think it's on the order of days, but I can't say for sure. cprov or bigjools or somebody could tell for sure
<soren> Really? They get automatically deleted eventually?
<soren> I thought they always had to be explicitly removed by an archive admin.
<rtg> mdz: how about if I just restore the kernel package naming convention for linux-doc for now, then deal with the new linux-doc package name when we update to 2.6.31 next week?  In the meantime, I'll respin linux-meta and let the reaper do its thing.
<mdz> rtg: fine with me
<mdz> rtg: I just followed up to the list with a suggestion for the upload order
<rtg> mdz: cool, I'd really like to get the new i386 pae flavour propagated.
 * Keybuk is having strange behaviour today
<Keybuk> nc -q0 ip port | dd of=/dev/sda bs=1M
<Keybuk> just hangs eventually
<mdz> Keybuk: on the network side or the sda side?
<Keybuk> sda side
<Keybuk> seems to be hung deep inside the io scheduler
<rtg> apw: care to review ubuntu-karmic-meta.git for me before I upload it?
 * apw looks
<apw> rtg, i see 9.9 at the tip?
<rtg> apw: yes
<Keybuk> wow
<Keybuk> it really looks like it screwed the scheduler
<apw> so this is just the meta change for mdz's change
<rtg> apw: correct. next week you'll have to bumop the ABI when you do 2.6.31
<rtg> apw: now, back to your comment about 386 becoming a non-ports package. Isn't that a function of the archive admin overrides?
<apw> so the plan is to drop it from meta, but not add it to the kernel yet
<rtg> correct
<apw> then when its cleared the archive, add it back into the kernel?  with the next abi update
<rtg> correct
<apw> sounds reasonable, and appears ok to me
<apw> as for the ports comment i was more referring to the fact it ends up being updated
<apw> config wise with the other x86 flavours
<rtg> oh
<apw> as the ports split we end up with is basically by architecture
<apw> we'd need to do a bit more work to make the different
<apw> thought perhaps thats not a negative thing overall
<apw> as there is probabally some benefit to us at least updating the configs for distro and ports at the saem time
<apw> always taking defaults for ports, and reporting them to the ports maintainers
<apw> else they will always fail to build
<apw> with a dirty config, if we don't
<rtg> after looking at your 'family' [atch, its not clear that 386 would build at all. there is no '386' flavour.
<apw> hmmm ... so have i lost it or did the ports fixes lose it?
<rtg> apw: methinks the ports fixes lost it, [PATCH 1/2] UBUNTU: split out the ports configs into their own family
<apw> hmm but the family changes are just at the top level
<apw> by which i mean the arch level
<apw> there is no config.flavour.386 at all in this origina commit:
<apw>     UBUNTU: [Config] ports - Add configuration files for ports architectures
<apw> so i think we never brought it over
<rtg> apw: that is the conclusion I was just coming to as well.
<apw> want me to sort that out?
<apw> i suspect it just got forgotten
<apw> inserting a new complete config into the split configs is an interesting game, which i just did for the ports ones
<rtg> apw: yeah, go ahead and sort it out. I've just pushed one more commit (reverting the linux-doc patch)
<rtg> apw: can you make 386 it's own arch?
<apw> it does appear the kernel arches are not the same as build arches right?
<rtg> apw: hmm, I think 386 gets built on an i386 chroot
<apw> will have a play
<apw> rtg what we care about is keeping 386 merging with ports configs 
<apw> otherwise its fine?
<rtg> apw: I dunno if its fine, but yeah, 386 should be part of the ports family of configs.
<mvo> hello! I noticed that there is a linux-image-debug-`uname -r` package on ddebs.ubuntu.com - but it appears to be not part of the Packages.gz file - is that intentional (the deb is pretty big)
<rtg> mvo: I believe so. It keeps the mirrors from picking it up.
<mvo> ok, thanks 
<rtg> apw: the original patch set from Luke simply didn't contain a 386 config
<apw> yeah or indeed anything about 386 at all
<rtg> apw: ok, I'd say just drop him a note about it and lets move on with other work
<apw> can do that, i feel the 386 ports port is the one that is worth a tiny bit of our attention just cause its an x86.  but you are likely sensible there
<apw> i t
<apw> rtg ok one question, if its a flavour of x86 and it gets built on i386, i suspect that will make it part of the common i386 build and therefore that one can have greater dammage to our build process than the other builds
<rtg> apw: it could, but I'm gonna let Luke figure it out
<apw> ok
<apw> rtg ok, i've emailed him and copied u-k-t
<rtg> apw: so, to test the KMS/PAE combination with your test kernels, I want https://edge.launchpad.net/~apw/+archive/red/+files/linux-image-2.6.30-9-server_2.6.30-9.10kms9_i386.deb, right?
<apw> rtg yeah thats the one that should exhibit it
<apw> i've personally tested some of the other combinations, which still work at least but would never have been affected
<rtg> apw: I take it these are upstream cherry-picks?
<apw> rtg, the patches on that kernel, one was direct from lkml from airlied and the other was mine.  since the equivalent of both has merged into what will be .31-rc1
<apw> i think dave got sick of them and just merged them
<rtg> apw: well, can we easily cherry-pick from Linus tree, or should we just ignore the PAE problem until 2.6.31 ?
<apw> the only urgency is if we are pushing people to -pae at all during upgrades, if not then there is none
<apw> i saw the whole testing of gem and pae and these two patches as a response to the 'blocker' if we were pushing people to -pae by default.  i cannot recall the outcome, or indeed if there was an outcome without this infrmation
<rtg> apw: fresh installs will have the problem if > 4GB RAM. Otherwise, upgrades ought to be OK.
<apw> so i think ... they can sensibly fall into the 'will wait for upstream to have them' bucket to my eye
<rtg> apw: works for me. I'm gonna package and upload then.
<apw> ok
<apw> that should get us at least an upload with the new flavours me thinks
<rtg> thats my goal
<Keybuk> rtg: can I ask a question?
<rtg> Keybuk: always
<rtg> whether I can answer...
<Keybuk> rtg: I have an image file
<Keybuk> and I'm trying to write it to the disk
<Keybuk> but every time, the kernel hangs inside the I/O scheduler
<Keybuk> is there a simple way to change that so I can use a different I/O scheduler
<Keybuk> (and worry about filing the bug later :p)
<rtg> Keybuk: yeah, there is a way to change the I/O scheduler dynamically. just need to remember how.
<Keybuk> rtg: what's a good "just do it" I/O scheduler?
<rtg> deadline?
<rtg> Keybuk: find /sys|grep sched
<rtg> cat /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/queue/scheduler
<rtg> This is a server install, so the default is deadline.
<Keybuk> ok
<Keybuk> great
 * Keybuk tries that
<rtg> Keybuk: try noop also, which is the simplest
<rtg> IIRC
<noptys> anyone familiar with recent changes to the e1000 driver?  It seems that in gutsy (2.6.22-14-generic), the 82573 wouldn't support jumbo frames, but with jaunty (2.6.28-11-generic), it lets you enable jumbo frames, but gets swapper allocation failures under network load
<rtg> noptys: perhaps you should email Jesse Brandenburg about that
<noptys> can do
<Keybuk> rtg: the deadline scheduler worked
<rtg> Keybuk: is Ingo the I/O scheduler dude?
<rtg> Keybuk: maybe Jens Axboe <axboe@kernel.dk> (block/cfq-iosched.c)
<apw> ingo is cpu scheduler to my mind
<rtg> apw: Jens did the CFQ scheduler
<apw> rtg he is also the maintainer of BLOCK in general, so a good starting point
<wjblack> Hello!
<wjblack> So I recently backported the 2.6.30 version of the r8169 driver to 2.6.28 and am wondering how to go about packaging it for e.g. a PPA.  The actual "how to put it in a package" details aside, I want to make sure I don't step on anyone's toes.  Should I just call it "r8169-backport-driver-2.6.28....*" or similar?
<wjblack> Am I going about this the wrong way entirely?
<rtg> wjblack: is it a DKMS based package?
<wjblack> Nope.  Modified vanilla kernel.org.
<wjblack> Literally, it's a patch to the 2.6.30 r8169.c that allows it to compile/run on 2.6.28
<wjblack> (the 2.6.30 version has a slightly different api but a fix for a rather nasty MSI bug)
<rtg> wjblack: the best way to package it so that you don't have to deal with ABI dependencies is to use DKMS
<wjblack> Hmm.  Okie-dokie.  Is there an Ubuntuish way to do that, or do I do generic dkms stuff?
<wjblack> (never used DKMS before, obviously ;-) )
<rtg> wjblack: there is a bit of a learning curve, but its not too bad once you grok things. here are some good example driver packages, e.g., bcmwl.
<rtg> s/here/there/
<wjblack> Aah, so the bcmwl package that's available via apt-get somewhere uses dkms?  Excellent.
 * wjblack learns best by example ;-)
<rtg> wjblack: yes, the maintainer is Alberto Milone (tseliot)
<rtg> wjblack: in Karmic its called bcmwl-kernel-source
<wjblack> I'm thinking this particular backport will have an effective lifespan of, er, rather short since >=2.6.30 should be in the main distro at some point...
<wjblack> Right on.  I'll give it a looksee.  Thanks!
<rtg> wjblack: 2.6.30 is in the Karmic archive right now, 2.6.31-rc1 soonish
<wjblack> Hmm.  Still might be nice to have a PPA for Jaunty.  I'll check out this rabbit hole and see if I can handle its depth. ;-)
<bullgard4> Update Manager differentiates 'distriution updates' and 'security updates'. What is the difference? Does every single DE program package have a flag for that?
<bullgard4> s/DE/DEB/
<_ruben> not every bugfix relates to security issues
<bullgard4> _ruben: Yes. --  So it depends solely on the maintainer's judgement?
<zeroprog> hey guys im a little confused as to what a module can do other than a device driver(which i cant figure out either)...could somebody explain to me some of the more useful modules
<johanbr> a module can do pretty much anything
<johanbr> think of it as a plugin for the kernel
<zeroprog> johanbr: i get that but....i dunno im having trouble understanding what modules do what....like i want to look at specific device drivers(webcam, audio, anything i can find) but i dont know which source does what 
<zeroprog> in the module programming guide they said we can write a module that says "Hey that tickles" everytime i delete something....but how would i do that you know what i mean?
<johanbr> look at the kernel source for sth simple
<zeroprog> ok
<zeroprog> do you know where thats located?
<dtchen> zeroprog: www.kernel.org, git.kernel.org, kernelnewbies.org, kernel.ubuntu.com/git
<dtchen> zeroprog: see also #kernelnewbies on irc.oftc.net
#ubuntu-kernel 2009-06-23
<bgamari> how does one update a single module without repackaging the entire kernel
<bgamari> I'm currently getting errors along the lines of: [    8.967377] dell_laptop: no symbol version for dcdbas_smi_request
<bgamari> [    8.967380] dell_laptop: Unknown symbol dcdbas_smi_request
<Kano> hi, could you disable commedi? the s626 module always locks up on my systems with saa7146 dvd card
<Kano> 05:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146]
<Kano> alias:          pci:v00001131d00007146sv*sd*bc*sc*i*
<Kano> is in s626
<Kano> and that locks up the system
<Kano> usally controlled by budget-av
<apw> sounds bad, that sounds like it needs a bug to remind me!
<Kano> as all my systems have got dvb cards none will boot ubuntu
<Kano> i prefer # CONFIG_COMEDI is not set
<apw> may well be something a lot of people hit
<apw> let me know the bug number and i'll have a look
<Kano> maybe there is another solution, like a complete alias with 4 ids
<Kano> just mailed the author
<apw> cool
<Kano> this is definitely too generic
<Kano> all i can do is to disable it
<Kano> sv*sd* is generic
<apw> yeah it does seem rather overarching
<Kano> CONFIG_HAVE_KERNEL_LZMA=y
<Kano> how about using that? would not hurt at all
<Kano> so rebooting to try without comedi
<Kano> it of course boots without s626. but how about updateing ndiswrapper to 1.54
<Kano> still 1.53 in there
<apw> ndiswrapper is on the list for review
<apw> kernel LZMA would potentially affect slow machines
<apw> a
<apw> and would need testing on those platforms to check for regressions
<Kano> nobody mentioned that
<Kano> i used that for -9 kernel for kanotix and really nobody metioned that it would be slower
<amitk> Kano: how many users does Kanotix have?
<Kano> not that many than ubuntu, but enough for me
<amitk> Kano: I was just curious. The larger the test base, the better.
<Kano> 118 kernel updates in logfile
<amitk> I bet the majority of your users are very technical.
<Kano> no
<Kano> they just like better support
<Kano> i provide support for fglrx for every kernel for example
<Kano> nvidia of course too
<Kano> also there are test image downloads with -9 kernel: 114 - 32 bit, 20 - 64 bit, 873 - combined, nobody mentioned slow loading speed
<Kano> it is interesting that these images are not officially announced ;)
<Kano> but rt2500usb seems to be really problematic
<Kano> any launchpad entries for that yet?
<Kano> i could fix one issue with removing ids from rt2500usb to use rt73usb for some cards, but those which are only in rt2500usb are still broken it seems
<Kano> thats the only reason that somebody would downgrade currently
<TheMuso> /c/c
<Kano> http://bugzilla.kernel.org/show_bug.cgi?id=12309
<ubot3> bugzilla.kernel.org bug 12309 in Block Layer "Large I/O operations result in slow performance and high iowait times" [High,Resolved: insufficient_data] 
<Kano> what do you think about this bug
<Kano> so added the cfq-ioshedul patch
<Kano> http://kanotix.com/files/excalibur/linux-2.6.30-generic/source/
<Kano> you find all used patches there
<Kano> one patch seems to miss there
<Kano> to cp ieee headers
<Kano> so now it is there...
<apw> can anyone tell me which key the sysrq tag is on on a standard keyboard?  none of mine have it marked ... BAH
<lifeless> apw: laptop?
<Kano> print
<lifeless> apw: printscreen button probably
<apw> lifeless, all and every one of my keybaords oddly
<apw> thanks both
<lifeless> fn-f11 for my dell laptop that is in front of me
<apw> very odd isn't it, having no label on the keyboard, and its not something you can play with once yo uneed it
<apw> bugger, found it ... shame i chose 'b'
<smb> lol, yeah s might be better :)
* smb changed the topic of #ubuntu-kernel to: Karmic Kernel Plan: 2.6.31 -- Kernel Team Bug Day https://wiki.ubuntu.com/KernelTeam/BugDay/20090623
<ncopa> could someone please help me find the build script source for linux-headers-*-generic package?
<ncopa> want to look how they make that nice symvers, .config and symlinks to header dirs
<rtg> ncopa: debian/rules.d/2-binary-arch.mk in the kernel git repo
<ncopa> thanks
<nixternal> anyone having issues with 2.6.30-10? black screen of death here...anything I can do to help triaging let me know..haven't found a bug yet concerning what I am seeing
<amitk> nixternal: KMS enabled?
<amitk> what graphics card, etc."
<amitk> ?
<nixternal> you are on the right track :)   intel
<nixternal> and yes it is a kms problem
<nixternal> I just did i915.modeline=0 and it works
<rtg_> nixternal: KMS doesn't work with PAE
<rtg_> (yet)
<nixternal> gotcha
<nixternal> hopefully that is planned
<rtg_> its in 2.6.31
<nixternal> groovy
<nixternal> maybe a blog post should go out to prevent frustration from people who will be upgrading in karmic in the next day or so?
<rtg_> nixternal:  upgrades should not encounter the issue, unless you're running -server with desktop installed.
<nixternal> I am not running -server, it is -generic
<amitk> curious
<rtg_> nixternal: 2.6.30-10.11 ?
<amitk> nixternal: cat /proc/version_signature
<nixternal> 2.6.30-10.12
<nixternal> Ubuntu 2.6.30-10.12-generic
<amitk> nixternal: so PAE isn't enabled
<rtg_> amitk: but KMS _is_ now enabled by default.
<amitk> rtg_: true, but this particular case isn't because of a PAE/KMS conflict
<amitk> nixternal: ubuntu-bug xorg
<rtg_> nixternal: I wonder if your Xorg package is not up to date?
<nixternal> very well could be
<rtg_> nixternal: they have to be in sync
<nixternal> xorg is 7.4~5ubuntu21 from the beginning of June
<nixternal> this issue happened right before it came time to enter my 3rd encryption password
<nixternal> after entering the 2nd password, the screen went black
<Unggnu> hi all
<Unggnu> Is there a reason why the sound driver power management is enabled per default in Karmic?
<amitk> nixternal: you are running karmic kernel and xorg on jaunty?
<nixternal> no, this is all karmic
<amitk> Unggnu: to save power? :)
<Unggnu> If you use headphones you really getting deaf through the clicking noise when it is enabled again
<amitk> nixternal: please upgrade your entire system and if it still persists, file a bug using 'ubuntu-bug xorg'
<Unggnu> Please don't do this automatically.
<amitk> Unggnu: please file a bug to help us fix it.
<Unggnu> ok
<amitk> Unggnu: you can disable it in your /etc/modprobe.d options
<Unggnu> I have disabled it through proc
<Unggnu> or sys
<amitk> Unggnu: You can also disable it /etc/modprobe.d/alsa-base.conf (line saying options snd-hda-intel power_save=10)
<nixternal> amitk: I did a dist-upgrade already, got everything that is available right now
<Unggnu> ok
<nixternal> I will yell at Bryce and see what he is up to
<amitk> hehe... ok
<amitk> bjf_afk: having trouble compiling your kernel...
<Unggnu> amitk: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/391182
<ubot3> Malone bug 391182 in linux "Please disable Kernel sound power saving per default [Karmic]" [Undecided,New] 
<amitk> Unggnu: do you use a laptop?
<Unggnu> Sure
<nixternal> hahaha, amitk and rtg_: I didn't get the new initramfs-tools
<Unggnu> I have also tested it in the past but disabled it because of this clicking
<amitk> Unggnu: if so, the power savings can be quite substantial. In some cases almost 30-40mins of extra battery life.
<nixternal> I just updated and got them and everything is working, though usplash is really small :)
<Unggnu> amitk: Because of the sound card?
<amitk> Unggnu: yes, the amplifiers, codec, etc.
<Unggnu> amitk: My system uses not much power but the only important parts are cpu und display.
<Unggnu> which really have an measurable impact if I remember correctly
<Unggnu> and wlan of course
<nixternal> I spoke to soon, at least I can hit all 3 encryption passwords now, but x is still dead
<Unggnu> amitk: You can test it with powertop I guess
<amitk> Unggnu: true. But try running your battery flat with and without the sound power savings.
<Unggnu> I give it a shot :)
<amitk> Unggnu: please post the battery life numbers to the bug, to allow us to judge how much the impact is
<Unggnu> amitk: Anyway my ears would be more important for me than 1 W but I am testing :)
<Unggnu> 7.6 W with sound power saving
<Unggnu> amitk: 7.6W with sound power saving and ~8 W without but the higher cpu usage might be also a reason
<Unggnu> or 7.9W something around
<amitk> cool
<Unggnu> Everyone who needs this little difference can enabled it on his own. A gui entry would be the best of course :)
<amitk> Unggnu: I'll leave it to dtchen to decide that. But in general if we can simply blacklist the ones that don't work that would be nice.
<bjf> amitk, I'm trying to clear up the last of the config differences between Jaunty and Karmic w.r.t. imx51
<Unggnu> They work but there is  a reaction coupling if it gets enabled again which is very loud with head phones
<bjf> amitk, I have not tried building for a bit, not surprised there are problems right now
<amitk> bjf: ack
<amitk> bjf: what I meant was it doesn't even start building. Asks me to run 'make mrproper'. Need to figure out what got hosed.
<bjf> amitk, have not had that problem... however
<bjf> amitk, I wonder if this is part of the config changes that were recently implemented
<rtg_> amitk: isn't that 'cause you have cruft in your build root ?
<bjf> amitk, in my working tree git says that I have made changes to other arch / flavour config files (I have not commited them)
<amitk> rtg_: right. And I hard reset my tree. But no go
<nixternal> amitk and rtg_: if I set 'nomodeset' by editing grub on bootup, everything works fine...fyi
<rtg_> nixternal: I thought you said all worked fine after updating initramfs-tools?
<nixternal> it started to work fine, but died when firing up X
<nixternal> KDM
<amitk> bjf: could you try 'debian/rules binary-generic' on your tree
<bjf> amitk, i am having the same problem
<jaro> Hi there. Is there any suitable channel to ask questions related to quite old (2.4) kernel? I'm fighting with waitpid() not working correctly in a multithreaded process
<jaro> and would like to find out if there is any known solution for this
<bjf> amitk, the way I got pat it is I did 'debian/rules editconfigs' and just answered 'yes' when exiting to saving the config
<amitk> jaro: google would be your friend for such an old kernel
<bjf> amitk, I could build after that
<bjf> amitk, should I run updateconfigs?
<jaro> amitk: i did use it and found out one discussion thread that proposes that there is no way how to fix it
<bjf> just did that, let me commit those configs
<jaro> amitk: I'd like to make sure that it is that way
<bjf> amitk, ^^
<amitk> bjf: yes, running updateconfigs is a good idea
<bjf> amitk, ok, updates pushed
<amitk> jaro: no one here will be able to help with a 2.4 kernel
<bjf> amitk, wasn't expecting imx51 changes to ripple into the other config files
<amitk> bjf: it should only touch the common arch files and common ubuntu files if it find the same options set in other arches
<jaro> amitk: ok I thought so :-/
<rtg_> amitk: 'missing' is also a matcvh
<amitk> rtg_: aah, right. With apw's new patches
<apw> whats up?
<apw> bjf yeah if you make changes to any arch config it could trigger changes in other arch common files
<apw> if they now collapse to the same value or the inverse
<apw> bjf if you are worried about what its doing shove the diff into a pastebin and i can see if i think its mental
<bjf> apw, no worries, just unexpected
<rtg_> apw: it shouldn't make changes in other arch common configs. armel should only affect config.common.ubuntu, right?
<apw> rtg_, no it can affect other commons, if it stops something being common to all arches
<apw> or if something becomes common to other arches
<apw> like turning on staging or something
<apw> then they will drop from the commons and move up to the ubuntu, or visa versa
<apw> all depends on the actual value
<rtg_> apw: ah, right. I was thinking more about missing features.
<apw> yeah its likely something more generci he has changed, rather than something imx specific, which yes should just gently slide up to ubuntu level without affecting the other arches.  if its not then its bust
<bjf> apw, rtg_, I've emailed you both the patch just so you can see what changed
<rtg_> bjf: I was just looking at the commit in your git repo
<bjf> rtg_, you could do that also :-)
<rtg_> apw: its interesting what happened to some of the configs. for example, CONFIG_CHARGER_PCF50633 was removed from config.common.ubuntu and was added to the various x86 configs. If it was missing in armel, why didn't it stay in the common config?
 * apw waits for the email ... grrr
<apw> it should have stayed ... which kernel is he based on?
<apw> bjf, whats your current baseline?
<apw> sha1 is fine
<bjf> apw, it's off of karmic but probably a week old
<apw> ok then you have amitk's changes and not mine so the effect will be different
<apw> you may have trouble if you are not at the tip
<apw> as the config split has changed
<bjf> apw, so I'll need to rebase at some point and the another "updateconfigs"?
<rtg_> bjf: ah, you definitely need a rebase.
<apw> hopefully you have nice clean mods and only one updateconfigs in thee
<apw> there
<rtg_> yeah, drop the updateconfigs commit
<bjf> rtg_, right
<rtg_> before rebasing. 'rebase -i' is your friend
<apw> if you find the rebase is a nightmare for the configs we may be able to do something clever using the generated configs
<apw> as the configs are in the standard format in the middle of a split and we can compare those with some little mods
<dupondje> the new kernel in Karmic is broken (2.6.30-10) ?
<Sarvatt> <Sarvatt> dupondje: intel graphics and no /etc/X11/xorg.conf file by any chance? :D
<dupondje> nvidia
<dupondje> and a xorg.conf :p
<Sarvatt> sorry, real common problem in the past hour :D whats wrong? no problems with it here
<dupondje> well after grub2 loads
<dupondje> it starts the kernel, and then I only get a "_" :p
<dupondje> a blinking underscore :p
<dupondje> brb, going to eat now :)
<Sarvatt> i'm seeing the short flood of sleep: invalid number '0.1' on boot too
<Sarvatt> oops wrong channel
<bullgard4> I would like to make a proposal to improve the apport program somewhat. Where to dircet such a proposal?
<bullgard4> s/dircet/direct/
<amitk> bullgard4: get hold of pitti on #ubuntu-devel
<amitk> bullgard4: I suspect you will be asked to create a blueprint on launchpad
<bullgard4> amitk: I am not afraid of creating such a blueprint. --  Thank you.
<amitk> bullgard4: i didn't mean to imply you were afraid, just that I am not completely sure. pitti is the person to talk to.
<amitk> :)
<bullgard4> amitk: I understood it just like this at the outset.  --  No worries.
<dupondje> guys, initramfs-tools is broken
<dupondje> nobody awake here ?
<dupondje> cjwatson:  ?
<dupondje> need him badly
<MellowDude> hi i got a question about kernels 
<dupondje> shoot
<MellowDude> i have a amd Athlon 64  cpu and i have ubuntu 32 bit os installed i was wondering what Kernel should i use the k7 or the k7-smp
<ubot3> MellowDude: Error: Could not parse XML returned by Ubuntu: not well-formed (invalid token): line 378, column 84
<dupondje> lol :)
<maco> pdflush is going bonkers on my cpu. i hear that when this happens on ext4 it means "brace yourself for data loss" ...that true?
<dtchen> maco: no.
<freinhard> hi!
<dtchen> freinhard: your best bet is to file a bug and e-mail the list
<freinhard> dtchen: hey, didn't say anything concerning that yet ;)
<freinhard> bug 384268, if desirable, i can take some time and do a debdiff
<ubot3> Malone bug 384268 in linux-firmware "Firmware update for p54 and kernel >= 2.6.28 suggested" [Undecided,New] https://launchpad.net/bugs/384268
<Nafallo> oh hai! I think KMS got the resolution for my eeepc wrong. I guess the kernel is to blame more than X? :-)
<dtchen> freinhard: debdiff wouldn't be as helpful as a git changeset reference; see http://kernel.ubuntu.com/git?p=ubuntu/linux-firmware-karmic.git;a=summary and http://kernel.ubuntu.com/git?p=ubuntu/linux-firmware-jaunty.git;a=summary
<freinhard> dtchen: any suggestion where i should host the repo so you can pull from?
#ubuntu-kernel 2009-06-24
<ppurka> hi all.. i want to know whether it is possible to get the ubuntu-specific kernel patches for 2.6.30
<dhendrix> hey everyone... i'm trying to use make-kpkg to package kernels, but I keep getting annoying interactive warning messages when I try to install a fresh kernel package. I've set "do_initrd = yes", "warn_initrd = no", "clobber_modules = yes", and "silent_modules  = yes" but I still get warnings about installing an initrd kernel and writing over an old /lib/modules/$version directory.
<dhendrix> has anyone else seen this?
<maxb> Hi, the Karmic ABI 10 kernel results in gnome-power-manager not being able to set/get laptop panel brightness - Acer Aspire One, Intel graphics - any thoughts on what I need to put in a useful bug report?
<smb> maxb, It would be interesting to see what is in (and under) /sys/class/brightness. I am not really sure what caused that ever to work. The acpi interface seems not to work and the acer-wmi is supposed not to...
<maxb> Actually it works pretty horridly without KMS also
<maxb> But KMS makes it actually give errors, rather than just behaving bizarrely, so something has changed
<smb> I know. From the 1000 (not really but felt) levels the OSD suggested in Jaunty, only the first 7 or 9 were real.
<smb> Hm, errors in dmesg?
<maxb> And I don't seem to *have* a /sys/class/brightness !
<maxb> I'm booted without KMS at the moment, I'll comb dmesg after my next reboot.
<smb> That is what I would expect. With all the experience with the aa1 it seems it does most things internally in the hw
<maxb> But KMS itself seems to be working fine, and VT switching is so slick now :-)
<smb> True :)
<smb> I currently booted an 8.9 kernel with kms and can change the brightness with the hotkeys, but without any osd feedback
<mvo> hello. I was wondering if anyone if familar with "crash" and knows if there is a way to get a backtrace without the linux-image-debug package?
<smb> mvo, I would not say I am familiar with crash, so I cannot say whether it will do anything without files with symbol information. But in general a backtrace of a kernel stack without cannot tell which function name an address belongs to. And that is unlikely useful
<mvo> smb: thanks, it was a small hope I had, the debug pakage is just so huge
<smb> mvo, If you compile locally, you could take the vmlinux produced there
<mdz> l-r-m is no longer, right?
<asac> during boot and in syslog i am seeing: [69908.676578] end_request: I/O error, dev fd0, sector 0
<asac> is that known? bugid?
 * asac does not have a floppy drive
<amitk> mdz: correct.
<mvo> asac: I see this as well (and I have no floopy) - IIRC it was a devicekit issue and is already reported
<asac> mvo: hmm. ok. but that happens really early during boot
<asac> something like "testing for hardware ..." ...
<asac> and then that takes ages and it spits out those messages
<mvo> oh
<mvo> asac: maybe its something else then
<maxb> If killing devkit-disks-daemon stops it, it's likely the already reported issue
<pgraner> ogasawara_: ping
<pgraner> ogasawara_: unping /me forgot your in PST
<zhoujingrui> hi
<rtg> apw: are you familiar with the grub2 --no-floppy borkage?
<apw> rtg no not heard anything about that
<apw> where is that being discussed
<maxb> Since updating to karmic abi 10, on some boots intermittently, my touchpad intermittently gets reported as a 'PS/2 Synaptics TouchPad' instead of a 'SynPS/2 Synaptics TouchPad', causing hal to miscategorise it as a mouse.... any thoughts on what to dig into?
<rtg> maxb: IIRC there was a reset patch, or perhaps an unusual device patch for that.
<rtg> that was in Jaunty, so it ought to still be in Karmic
<maxb> This problem is new in karmic abi 10
<rtg> maxb: hmm, almost all of the work from ABI 9 to 10 was config stuff. Is there some config option that has disappeared or changed?
<apw> rtg as i recall the configs were mostly unchanged
<rtg> apw: that was my observation as well
<JFo> ogasawara, thanks for being willing to guide me. I'll pester you after I have read up more on the information you gave me :-)
<ogasawara> JFo: great, thanks for wanting to help!
<JFo> no problem
#ubuntu-kernel 2009-06-25
<dhendrix> does anyone have a pair of kernel-img.conf and kernel-pkg.conf files set up for kernel packages with completely non-interactive setup (using make-kpkg)?
<sunnydrake> hi can someone explain me - will ubuntu distro work wihout problems with "original" kernel(i wish to check unified kernel patches on ubuntu liveusb system) ?
<lifeless> yes, and there are packages built with the vanilla kernel specifically for testing
<lifeless> however, you may find the live system isn't supported by the vanilla kernel, or some hardware 
<kdub> hey all, i'm good with kernels, and would like to contribute, where can i start?
<smb> kdub, You might want get familiar with the workflow. See Leann's mail to Jeremy at https://lists.ubuntu.com/archives/kernel-team/2009-June/006170.html
<smb> If you think you want a go, there is a community section of bugs if you follow the link on the topic
<zeroprog> hey guys  im trying to edit the module that colors the ubuntu layout....anybody know what folder those files are located in?
<kdub> smb: thanks, i know its annoying when people ask "how can i start" questions, but i really think i can help out a lot if someone helps me get my foot in the door
<smb> kdub, No problem. We really can use a few people out in the community helping out with the work
<kdub> i'll read the links in that email, and ping back with any questions i have
<smb> zeroprog, Are you sure, the kernel is the right place to look for that?
<kdub> but i have decent experience with embedded systems, kernels, drivers, all that jazz
<smb> kdub, Sure. Thanks for joining in
<zeroprog> smb: not at all....i was hoping to write a simple module that says something stupid everytime you delete something but i cant find where that folder is either
<zeroprog> the names linux uses are short and sweet but not so much descriptive 
<zeroprog> the only things i can figure out are crypto, acpi and a few others 
<smb> zeroprog, my problem might just be to get the connection between that and something that colors the ubuntu layout. Heck, I am not even sure I understand what you mean with ubuntu layout. ;-)
<zeroprog> ergh...curse my explanatory skills
<zeroprog> ive been trying to look for a use for modules that im able to do....drivers are too complicated for some reason plus i have no real devices i wish to use...maybe ill just learn the nokia n800 deal
<smb> Hm, not sure I can help there. The modules I look at are either drivers or part of a bigger stack. If I saw something simple I probably forgot it. :-/
<apw> hrm i thought there was a config option for tickless
<smb> nohz?
<apw> hrm no longer an option for it
<kdub> smb: im a bit overwhelmed with all these configuration caveats...
<smb> apw, NO_HZ
<apw> debian/config/config.common.ports:CONFIG_NO_HZ=y
<apw> debian/config/config.common.ubuntu:CONFIG_NO_HZ=y
<smb> kdub, which one exactly?
<apw> well i assume its on then :)
<smb> apw, I guess so
<kdub> if i want to build a standard i386 kernel, the .config lives in debian/config/i386?
<cking> apw, I suggest asking for powertop output first, e.g. powertop --dump to see if there is anything insane causing CPU heat
<smb> kdub, It is split into a generic part and a part for the generic kernel. Karmic will be even more split
<smb> kdub, But usually you will not have to care that much if you compile with "fakeroot debian/rules binary-arch" or "debuild -b"
<kdub> i'm not so comfortable with fakeroot/deb building stuff just yet...
<smb> kdub, For releases up to Jaunty, you get the used config by cat'ing together debian/configs/i386/config{,-generic}
<kdub> and jaunty? cat all 3 together
<smb> kdub, Jaunty is the same as above. The new stuff will come with Karmic
<apw> there are common configs at the top level and at each arch plus config deltas per flavour in karmic
<kdub> smb, sorry, i meant karmic
<lesshaste> I have been told to enable boot logging and post the output ( https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/389930 ) but this feature has not worked for ages and does nothing in jaunty
<smb> kdub, As apw said. :)
<ubot3> Malone bug 389930 in grub "grub menu skipped after shutdown" [Low,New] 
<lesshaste> can anyone tell me, do they secretly mean /var/log/dmesg?
<kdub> oh there we go, its 3 configs combined together
<apw> cking, i've asked them to identify the exact kernels which are good and bad, then for those that do that i will give them a tragetted set of mainline kernels to test to give us a bisection
<apw> i guess thats a start
<cking> meanwhile, let me install intrepid + jaunty on one of my spare lappies and see if there is anything obviously different
<apw> cking, thanks
<smb> apw, I will do a karmic installation on a laptop here, that might give additional data points
<kdub> and once this gets done compiling, do you guys usually run in a vm, or as the running kernel?
<kdub> eg, what is more useful to do?
<apw> yeah kirkland is complaining about a thinkpad
<apw> kdub, bit of both depending on the change
<cking> apw, 64 or 32 bit machines?  64 will bang more gate transistors :-)
<smb> kdub, depends, a vm is good to see it boots at all. real hardware might be the only way to find other things
<kdub> apw: alright
<apw> cking, hehe always been 64 bit here
<smb> kdub, And for some stuff, we have to ask the reportes as we don't have the hw at all
<cking> me too. 
<apw> 135 wakeups per-second sounds like a lot to me
<cking> apw, that sounds typical to me.
<smb> apw, Got 240 on hardy here
<smb> (given without tweaking)
<apw> heh then i guess i shoul be happy :/
<kdub> well, i guess i'm up off the ground, so to speak. next up is, what, looking for bugs?
<cking> I will also measure power consumption using my little meter gizmo
<apw> i guess when your keyboard is showing up ... that you don't have that many ints
<apw> kdub, did you see the triaging stuff that leaan emailed out?
<cking> turn down the beacon interval on your access point :-)
<apw> i _think_ smb may have pointed you at it
<smb> I passed the link to her email 
<smb> And if that feels ok. The link to the bugday is on our channel topic :)
<kdub> apw: i did, it didnt make a whole lot of sense though
<cking> 66 wakeups/sec on my karmic dell6400
<apw> yeah.  most people who start getting involved in the kernel stuff, start with helping out on the bug triage
<apw> that gets you used to the bug handling, which is a little odd
<apw> then generally one ends up touching a few which need actual work and can start to make a difference
<apw> easing in gentle like
<lesshaste> is there any way of disabling a fingerprint reader without doing it through the bios ? I get A USB device is active 100.0% of the time:
<lesshaste> in powertop
<apw> some devices have a power control separatly
<apw> in /sys
 * kdub still doesnt really know what to do next
<kdub> go through launchpad?
<smb> maybe unbinding (for testing purposes) might work as well
<apw> kdub, if you want to get a feel for our bug process, then reading the triage doc, then helping out with the community section of the bug day page is a good start
<smb> kdub, In the end all goes through launchpad. I don't know, but I believe it helps to go ttps://wiki.ubuntu.com/KernelTeam/BugDay/20090623 there
<apw> many of those will just be simple closes, but the ones which are not, will need some investigation
<smb> kdub, and then to Bugs, there is a link to a table with bugs
<apw> commonly involving finding likely fixes and building test kernels etc
<smb> One section is community bugs. 
<apw> when you find those too easy, we have plenty of other bugs to move up to
<smb> The bug numbers are selectable and take you to launchpad
<kdub> alright, so i pick one bug, and see what i can do to help with it, i guess
<smb> kdub, Yep, same we do. ;-)
<apw> kdub, the process docs give you more idea what states to put things in when you do things with them
<lesshaste> kdub, you could start with mine :)
<kdub> smb: but unlike you guys, i don't have a lot of experience with this :P
<apw> and the bug day page has some help on the sorts of things its reasonable to say with old bugs and which states to use 
<apw> so the use knows why we are closing them out etc
<apw> then the interesting one you get to make up ways to test, look for patches, etc etc
<apw> when you find fixes and stuff come back and we can help you get them in
<apw> as in tell you the process there, not to overwhelm you now
<smb> kdub, Sure, but we all started at some point. It just takes a bit time to get into it
<apw> kdub, heh don't worry if things are too hard, leave them, feel free to pick things you think you can solve, help with, make a difference with
<apw> kdub, realise that even if you only did some triage work and helped weed out the old crappy bugs, the ones already fixed, and make sure the right info is obtained, that is all valuable work to do
<apw> as it reduces the work the rest of us have to do, so we get to more of the bugs.  if you actually fix bugs as well thats the cherry on top
<apw> but either way its appreciated, as it helps everyone get more done
 * apw watches the merge window slam shut ...
<cking> klunck!
<kdub> apw: my general goal is to be less trouble than i'm worth :)
<apw> kdub, then you have the right attitude!  really any work you do correctly is a win for us, we are a small team, probabally about the equivalent of 8 people
<apw> kdub, welcome aboard.  please do come back here and ask questions on anything you are unsure about, anything that seems mad (and there will be a lot of mad stuff) etc... ask, we are pretty approachable
<smb> kdub, mostly. (joking). Yes, welcome
<kdub> thanks, everyone
<kdub> and mailing list?
<apw> there is mailing list assosiated with the ubuntu-kernel-team in launchpad (i believe
<kdub> do people use it?
 * apw checks its the right one
<apw> Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
<apw> is the one we use, we review all patches and there is a fiar bit of discussion on that one
<apw> https://lists.ubuntu.com/mailman/listinfo/kernel-team
<kdub> alright, thanks. i subscribed
<apw> smb, when we rebase across version i assume the -ABI number reverts to -1 ? yes?
<Kano> hi apw, do you want to update ndiswrapper toady?
<Kano> i got a patch from the s626 author, i am just not fully convided that the patch is needed in that form. i would have guessed adding the id would be all needed
<Kano> he added a bit more
<[plane]> anybody here??
<mok0> I have a regression on my netbook, the latest kernel upgrade to 2.6.28-13-lpia made the wireless go away
<AceLan> mok0: whick wireless chip do you use?
<mok0> AceLan: bcm4315
<mok0> AceLan: I used to have it visible in jockey, but no more
<mok0> AceLan: "Broadcom STA wireless driver"
<AceLan> mok0: do you remember the version of the original kernel?
<mok0> AceLan, 2.6.28-11-lpia
<mok0> AceLan: It was a recent update from jaunty-updates
<AceLan> mok0: do you know the module name of the wireless driver?
<mok0> AceLan: yes, it's "wl.ko"
<mok0> wl I guess
<Kano> thats in restricted
<Kano> well i made a dkms script
<mok0> The old driver is in  /lib/modules/2.6.28-11-lpia/volatile/wl.ko
<AceLan> mok0: so, the w1 module doesn't exist now?
<mok0> Kano: yes it's restricted
<mok0> AceLan: no
<mok0> AceLan: wasn't included in the upgrade for some reason
<mok0> AceLan: ... or something happened during the installation... I guess it is built on installation
<smb> mok0, Yes it is. The binary parts come with linux-restricted-modules and it is linked on boot
<mok0> OK, makes sense
<smb> mok0, Could it be lrm was not upgraded at the same time?
<mok0> smb, I can check
<mok0> smb, aargh out of battery & no charger here
<mok0> I will check when I get home
<smb> mok0, bad. ok
<mok0> Justed wanted to hear if you guys knew about a problem
<smb> Not right of my head. I tested Jaunty wl driver from lrm on amd64 and that worked
<mok0> smb: ok, I have not heard from other mini 10 owners about anything either
<smb> mok0, So we'll have to find out what went wrong with yours.
<mok0> smb: ok, I'll let you know... or perhaps turn up here in panic
<mok0> :)
<smb> mok0, either way :)
<cjwatson> rtg: grub2 --no-floppy> on my list to fix (I think there's an upstream patch for it)
<rtg> cjwatson: cool, it bit me on my laptop.
<rtg> Is there an LP bug already? I got distracted and didn't file one
<cjwatson> rtg: yeah
<cjwatson> rtg: bug 391044
<ubot3> Malone bug 391044 in grub2 "grub2 update adds --no-floppy to "search " lines" [Undecided,Confirmed] https://launchpad.net/bugs/391044
 * hyperair wonders if anybody can boot the 2.6.31 kernel from the kernel-ppa?
<cjwatson> rtg: I've uploaded the necessary bits for the installer to use -generic-pae in the same way it used to use -server; will need to be refined I expect, this is just basic support
<rtg> cjwatson: noted.
<cjwatson> ... and corresponding cdimage and seed changes
<apw> hyperair, never tried
<hyperair> apw: didn't you compile that, though?
<apw> hyperair, the mainline kernels, they come out of my automation yes.  doesn't mean i boot them
<hyperair> aha, heheh
<hyperair> i se
<mok0> smb: I solved my wireless problem
<hyperair> +e
<hyperair> hello mok0 =)
<mok0> hyperair!!!
<hyperair> mok0!!!
<mok0> hehe
<hyperair> =p
<rtg> apw: I've booted the mainline 2.6.31-rc1
<hyperair> rtg: oh it worked for you? =\
<hyperair> it hangs at modprobe for me
<rtg> hyperair: amd64, dual quad-core
<hyperair> i'm on a dual core
<hyperair> amd64
<mok0> smb, I had to run lrm-manager and let it form a proper initrd.img file
<hyperair> what does lrm-manager have anything to do with initrd? O_o
<mok0> hyperair: it builds a new one
<mok0> hyperair: after the modules have been installed
<hyperair> ah
<hyperair> i see
<mok0> But it does so for the running kernel
<mok0> which means that if you install the restricted modules under another kernel, it will not be the right one
<hyperair> that.. doesn't sound nice
<mok0> ... therefore the drivers wont take effect when the new kernel starts up, and you become very confused
<hyperair> heheh
<hyperair> i see
<hyperair> i thought that the restricted drivers were loaded after root was mounted though
<mok0> I don't understand why that is allowed to happen
 * hyperair doesn't either
<mok0> hyperair: well, I _think_ this is what has happened in my case...
<hyperair> what i do know, however, is that my dvd drive suddenly detected a blank dvd around 30 minutes after i inserted it.
<hyperair> heheh
<hyperair> which driver were you using?
<mok0> hm, at least it came around
<hyperair> heh if only it would come around each time
<hyperair> it's a blank dvd and i can't burn into it
<mok0> hyperair: the wireless driver
<hyperair> mok0: i meant which wireless driver 
<mok0> :(
<hyperair> my dvd drive's whacked up for some reason. it can only detect and burn to cds
<hyperair> =(
<mok0> ah, its for the broadcom wireless chip
<hyperair> ah broadcom
<hyperair> nasty one that is X_X
<hyperair> i avoided that one like plague when i was shopping for my notebook
<mok0> it's the broadcom proprietary dirver, called "wl"
<hyperair> wl?
<hyperair> not b43?
<mok0> no
<hyperair> wait, i think i saw that in some guy's notebook during malaysia's osconf
<hyperair> except his issue was much simpler--he turned off the rf kill switch and couldn't figure out why it wouldn't work
<mok0> it really should use dkms
<hyperair> indeed it should
<mok0> I might file a bug against it
<hyperair> dkms is a seriously cool package =p
<mok0> indeed
<hyperair> go file it then! =p
<mok0> I should learn more about it though
<mok0> ... tomorrow
<mok0> :-)
<mok0> hyperair: did you make uuc btw?
<hyperair> mok0: yeah i did =) thanks for your endorsement
<mok0> nice, congrats
<hyperair> thanks =)
<mok0> hyperair: next step is motu
<hyperair> indeed
<mok0> hyperair: you should start getting your application together
<hyperair> =O now?
<hyperair> i thought i'd bide my time until i'd gotten more stuff done
<mok0> hyperair: yeah, start adding stuff to your journal with stuff you do
<hyperair> hmm yeah
<mok0> hyperair: so you can apply for the karmic cycle
<mok0> karmic+1 
<hyperair> yeah
<mok0> hyperair: after the summer
<hyperair> well i'll see how it goes =)
<CarlFK1> why does "sudo reboot" sometimes reboot the hardware (back to POST) and sometimes use kexec to reload the current kernel? 
<NCommander> CarlFK1, if kexec-tools are installed, it will use it if possible
<CarlFK1> NCommander: um... -tools installed, but it is not doing it right now
<CarlFK1> juser@dhcp216:~$ apt-cache policy kexec-tools ...   Installed: 20090000-2.0.0ubuntu3.1
<nick_schembri> ls
<CarlFK1> pretty sure this is a firewire module thing: 1041.217340] dvgrab[6370]: segfault at 7f2911245c88 ip 00007f29184700a1 sp 00007f29111a2fa8 error 6 in libc-2.9.so[7f29183ec000+168000]
<CarlFK1> trying under gdb now
<nick_schembri> cjwatson: Do you have a link to the new live cd remaster process for 9.10 +
<ccheney> ogasawara: is bug 392288 a proper kernel backtrace it looks a bit different from what i remember them looking like
<ubot3> Malone bug 392288 in linux "dd extremely slow writing to usb key without oflag=dsync" [Undecided,New] https://launchpad.net/bugs/392288
<CarlFK1> http://dpaste.com/59783/ #7  0x00007f6027e97fcd in clone ()     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 No locals. 
<cjwatson> nick_schembri: there's a new process?
<nick_schembri> At south east linux fest Creg talked about the aufs being removed from 9.10
<nick_schembri> oops Pete Graner
<ogasawara> ccheney: probably because it's not an oops/panic message that you're probably used to seeing.  was that an ext4 fs?
<ogasawara> ccheney: 2.6.31-rc1 was recently build, would be good if you could test and confirm with that kernel - http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc1/
<ccheney> ogasawara: it was writing directly to the device
<ccheney> ogasawara: ok will take a look after my system update is done
<Sarvatt> is there a reason memory stick support isnt enabled in the kernel? just curious as to what problems it might have that might have led to it being disabled
<dtchen> hmph, quite a few things FTBFS against the 2.6.31-rc1 headers, which isn't surprising
<dtchen> nvidia, bcmwl, vbox, ...
<hyperair> vboxdrv worked
<hyperair> not vboxnetflt though
<Sarvatt> vbox 3.0 beta 2 compiles fine on 2.6.31-rc1
<dtchen> not in a position to test 3.0b2 yet
<Sarvatt> http://www.virtualbox.org/ticket/4264
<Sarvatt> fix there
<Sarvatt> (for 2.2.4 too)
<hyperair> cool
<hyperair> now if only i could boot that kernel =p
<ccheney> ogasawara: i tried the 31 kernel and it wouldn't even boot into gdm for me
<ccheney> ogasawara: it just went black after loading the kernel, i think at the point it tried to start gdm
<ogasawara> ccheney: well that's no good
<ccheney> ogasawara: i tried both with and without nomodeset option
<ccheney> the current karmic kernel gets my resolution wrong so i use nomodeset on it
<ogasawara> ccheney: yah, I've seen similar bugs for the resolution issue
<cjwatson> nick_schembri: that doesn't affect customisation
<cjwatson> nick_schembri: the bulk of the live CD is still in a squashfs
<hyperair> the .31 kernel hangs running modprobe for me =\
<cjwatson> nick_schembri: the only difference relevant to customisation that I know of is that the live CD initramfs is now LZMA-compressed - that's just a matter of decompressing initrd.gz, recompressing it with 'lzma -9c', and writing it to initrd.lz
<hyperair> it appears to load iwlagn, hda-intel, and some other module, then hangs when it should bel oading i915.
<cjwatson> try loading intel-agp first?
<hyperair> hmm i should try that.
<hyperair> cjwatson: but shouldn't modprobe automatically load intel-agp first?
<cjwatson> there was a driver bug that meant it didn't
<cjwatson> I believe it's been fixed upstream
<hyperair> i see
<cjwatson> cf. https://bugs.freedesktop.org/show_bug.cgi?id=22358
<ubot3> Freedesktop bug 22358 in Driver/intel "Performance regression:  Sluggish text scrolling, 100%CPU after upgrade from 2.7.1 (UXA bug)" [Major,Resolved: fixed] 
<hyperair> so how would i go about getting intel-agp loaded before i915?
<cjwatson> stick it in /etc/initramfs-tools/modules?
<hyperair> eh..
<hyperair> it panicked when i had that
<cjwatson> actually, a current karmic initramfs should load intel-agp for you automatically
<cjwatson> initramfs-tools 0.92bubuntu32
<hyperair> that's my initramfs version, yes
<cjwatson> dunno, then
#ubuntu-kernel 2009-06-26
<Sarvatt> dtchen: got a patch for nvidia on 31 too that works for me -- http://www.nvnews.net/vbulletin/attachment.php?attachmentid=37305&d=1245688007
<nick_schembri> cjwatson: thank you for looking that up. Will keep testing until it fails. . :)
<dtchen> Sarvatt: site seems very sluggish ATM
<kdub> do we even care about bugs filed for dapper?
<hyperair> not if they don't apply anymore
<kdub> oh, so check to see if they still apply
<hyperair> mmhmm
<hyperair> basically check if it exists on karmic
<smb> kdub, Only if they are critical
<smb> But if the bug still persists in karmic we try to get it fixed in upstream and karmic
<hyperair> i thought dapper's support period ended?
<smb> hyperair, No, dapper is LTS, so it is still in support. But the acceptable changes are somewhat limited. But it still gets security updates
<smb> Actually support for Desktop ends this month... :)
<dme> account on
<smb> hyperair, Server goes till 2011
<kdub> a fair amount of bugs say "this one piec of hardware doesnt work". is there any way to look into that w/o that hardware?
<hyperair> smb: i see. that sure is long indeed. O_o
<dme> ng
<smb> kdub, That is the harder part. Mostly the approach is to let them try latest kernel versions (mainline builds) to see whether it does then
<smb> kdub, If it does, find the part/driver which supports it and see what changed there
<smb> If not, could it be a missing id or something simple. Otherwise it might need an upstream bugzilla. And all depends on how much information it is possible to get from the reporter
<smb> hyperair, It is. Squeezing (backporting) some of the security updates gets harder by time...
<hyperair> smb: i can imagine.
<apw> there are a bunch of deprecated interfaces in ndiswrapper whihch just got dropped finally so its a bit hosed
<apw> (at least the version we have) 
<mdz> apw: since we aren't using lrm anymore, can it be removed from karmic?  it seems to still be in the archive
<rtg> mdz: was it automatically copied when the archive was opened?
 * apw is beaten to it
<rtg> mdz: regardless, it can be removed.
<mdz> rtg: when we start working on a new release, it starts off containing all the same things that the previous release had
<mdz> once a package is in the archive, it stays there unless someone removes it
<mdz> rtg: instructions for how to request that it be removed are at https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages
<apw> <apw> rtg whats the status of karmic linux-meta, i think i heard you changing it?
<rtg> apw: no, I was working on the meta package backport to Hardy
<rtg> Karmic meta should be OK
<apw> ahh nice ... then i am clear to update karmic meta etc.
<rtg> AFAIK
<infinity> rtg: Don't bother filing a bug, I'm removing it right now.
<apw> i think my rebase is good, compiles for me on i386, amd64, lpia and armel
<rtg> infinity: thanks
<apw> so i'll push the git repo on that pretty much now, and perhaps you could give it the once over visually
<infinity> rtg: Done.
<mdz> RIP
<infinity> Indeed.
<rtg> long live LRM !
<infinity> The number of hours of blood, sweat, and more blood that I put into LRM will not be soon forgotten. :P
<infinity> On the other hand, good riddance to binutils-static.
<mdz> hmm, does this mean that the Ubuntu CD is now 100% free software again?
<rtg> infinity: and run-time linking
<rtg> mdz: we still seed binary blobs in DKMS packages
<rtg> nVidia, etc
<mdz> rtg: what are the names of the binary packages?
<infinity> nvidia-180-kernel-source, for instance, but that's not on the CD.
<infinity> Pretty sure we've kicked restricted off the CD, no?
<rtg> infinity: its not? oh.
<rtg> mdz: ok, maybe I'm all wet. 
<infinity> I see no nvidia junk seeded anymore.
<apw> so we now see the free drivers as good enough for testing and the installer at least
<infinity> Or I'm blind, which is possible while distracted with meetings. :)
<mdz> there are some on the DVD still
<infinity> apw: nouveau and radeon are much-improved lately.  I still run nvidia, but I'm a 3D game junkie.
<apw> yeah, not that nouveau is likely to be in the kernel
<rtg> apw: you pushed Karmic yet? I'm getting close to blasting off
<apw> its pushing as we speak, uplink is not as hot as it could be
<rtg> apw: nor is mine. damned asymmetric links
<apw> yeah, and here my down is a bit pants today too, seems there was a lot of noise when the adsl sync'd and theres no button to resync it without rebooting my router
<cwillu_clone> mainline site doesn't seem to have any recent x86 builds
<cwillu_clone> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-06-19/, the 31-rc1, etc
<cwillu_clone> Sarvatt, which kernel did you want me to download from your site again?
<TheMuso> apw: I do not expect you to update ports configs, thats why it was all separated in the first place.
#ubuntu-kernel 2009-06-27
<Sarvatt> so, what else fails to build against 2.6.31-rc1 besides bcmwl, vbox, nvidia and fglrx? :)
<apw> TheMuso, i know you don't expect me to, but if i don't update them and there are any new options thats guarentees that ports kernels will _not_ build at all
<apw> so it seems better for the process to be to update them taking whatever defaults we feel sensible, even if its just whatever is offered
<apw> as that at least will compile, and therefore produce some kerenl, then you are of course free to change those choices 
<apw> the key is trying to maintain some level of compiling for the ports kernels in this very turbulant time for the kernel, where new options are appearing in every release
<apw> (that is why i carefully documented the options i chose :)
<TheMuso> apw: Right, BTW the powerpc FTBFs at least has a fix upstream, however I'm not sure when the next RC is due.
<keshav> i m a newbie, so please pardon for asking this - what is the use of crashdump option in menu.lst for grub?
<keshav> nyone,  there?
<freinhard> hi!
<freinhard> updated some firmwares for prism54 chipsets: http://gitorious.org/ubuntu/linux-firmware-karmic/commits/update-prism54
 * hyperair wonders if acpi-cpufreq will be made into a module as opposed to compiled into the kernel again =\
#ubuntu-kernel 2009-06-28
<eshaase> i'm testing out one of the ubuntu kernel team's 2.6.30 kernels and it works great except I don't have any audio, can someone steer me in the right direction please?
<eshaase> (I have a "Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller")
 * hyperair groans
<hyperair> why, oh whyyyyyy can't the kernel find init?!
<hyperair> hmm for some reason it only happened when i called make-kpkg with --initrd. maybe i should try without
<lesshaste> when you remove a kernel using apt-get remove the system says it needs to restart which is just silly
<eshaase> i'm testing out one of the ubuntu kernel team's 2.6.30 kernels and it works great except I don't have any audio, can someone steer me in the right direction please?
<eshaase> (I have a "Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller")
<hyperair> mine's ICH8 =\
<hyperair> 82801H
<hyperair> looks like one generation after
<hyperair> do other kernels have it?â§
#ubuntu-kernel 2010-06-28
<smb> Morning
<smb> cking, \o
 * cking waves o/
<cooloney> smb and cking moring *.eu
<smb> Hi cooloney 
<ikepanhc> good morning .eu \o/
<smb> ikepanhc, morning .asia :)
<lag> \o/
<abogani2> morning all!
<lag> cooloney: Has anyone managed to get HDMI on the Panda working yet?
<cooloney> lag: oh, i don't think so.
<lag> Despite placing vram=8M omapfb.vram=0:8M on the Kernel cmdline I still get "omapfb omapfb: failed to allocate framebuffer"
<cooloney> sebjan told me he has no HDMI device. 
<lag> Who were we speaking to the other day?
<lag> Was it Rob?
<lag> And someone else?
<cooloney> i think Nicolas?
<lag> Possibly
<cooloney> i didn't meet Rob before
<lag> What time do they normally turn up?
<lifeless> rob who ? :)
<cooloney> i think they should be on line soon, but not sure about that
<lifeless> <- a Rob
<cooloney> lag: why not mail out, please cc me, hehe
<lag> cooloney: I don't know anyone's addresses
<lag> Can you mail me them?
<cooloney> lag: oh, forget that. no problem,
<TeTeT> smb: I'll visit our customer this week, hope we get some testing done with your lbm for x201 wwan
<cooloney> lag: just wanna confirm, is this bug #592295?
<ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/592295
<smb> TeTeT, That would be good. To see whether it is working or not. hard to tell without the hw. :)
<lag> Yes
<lag> cooloney: It was RobClark and prpplague
<lag> Chatting with ogra and I
<TeTeT> smb: agreed :)
<cooloney> lag: ok, i don't have robclark's email. i will mail to sebjan and nico
<lag> Is prpplague == nico?
<cooloney> lag: no
<cooloney> lag: it should be nedc or sth.
<cooloney> hehe
<cooloney> lag: and how do you think sebjan's solution in the LP of this bug?
<cooloney> lag: it looks like a workaround to me
<lag> cooloney: All it does it stops the message from printing out and swapping the console
<lag> cooloney: I already did that with a 'static int'
<lag> cooloney: Hence, I haven't used sebjan's 'solution'
<cooloney> lag: right, and you still don't get anything on you HDMI display. 
<cooloney> lag: yeah, understand
<lag> Correct
<lag> cooloney: I am currently building the very latest ti-omap4 branch
<lag> I'll let you know if anything changes regarding this bug
<cooloney> lag: thanks man. hehe
<lag> No worries 
<ogra> lag, it needs to be vram=32M and dont set omapfb.vram at all
<ogra> cooloney, prpplague's nick is prpplague ;)
<lag> ogra: How did you find that out?
<ogra> lag, trial and error :)
<ogra> i know we have three output devices enabled in omap4, and i know each needs at least 8M
<lag> Well done
<cooloney> yeah, so for the HDMI issue, we maybe can fix it in videoram code
<lag> What console is it?
<lag> ogra: -^
<ogra> lag, ??
<lag> HDMI still doesn't work for me
<ogra> lag, you mean the kernel cmdline ? 
<ogra> root=/dev/mmcblk0p2 rootwait ro mem=463M console=ttyO2,115200n8 console=tty0 vram=32M
<lag> Are you using a full desktop?
<ogra> thats what i used to get screen output
<lag> I'll try it
<ogra> no, just tty atm and the rootfs is screwed 
<lag> That's completely different to mine
<lag> I have a working rootfs if you'd like it?
<ogra> it should even work without setting conole options
<ogra> naj, i'm working on the images anyway 
<ogra> i have plenty of rootfses around just not on that SD
<lag> ogra: http://paste.ubuntu.com/456301/
<ogra> are you using a plain HDMI monitor (no DVI or adapters)
<lag> Nope
<lag> HDMI -> HDMI
<ogra> http://paste.ubuntu.com/456302/
<jk-> smb: could you take a look at comment 28 on https://bugs.launchpad.net/oem-priority/+bug/557742 ? looks like a symbol versioning issue between kernel modules & l-b-m
<ubot2> Launchpad bug 557742 in linux-backports-modules-2.6.32 (Ubuntu) (and 2 other projects) "Lenovo Thinkpad X201 & T410 & W510 not autoswitching to input mic jack in 10.04 (affects: 9) (dups: 1) (heat: 70)" [Undecided,New]
<jk-> the symbol version magic in l-b-m shouldn
<jk-> 't be different, right?
<smb> jk-, Let me check. They should not be different
<smb> jk-, But with thinkpad's and alsa there is an unsolved problem with thinkpad-acpi providing a mixer and alsa from lbm having different alsa versions
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/94b8f28fa6ffd56ba13b88b6e8d98c7b540b61de-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb
<ccheney> tgardner, ok will take a look in a min
<tgardner> ccheney, this is the upstream response. I updated the bug
<ccheney> cool
<ccheney> booting into it now
<ccheney> tgardner, its looking good so far
<tgardner> ccheney, done yet?
<ccheney> tgardner, it passed the register image test, so i think its fixed
<ccheney> when i tried to run an image it didn't work but i'm still looking into that
<tgardner> ccheney, k
<ccheney> it passed the full 10 loop test
<ccheney> tgardner, works
<ccheney> tgardner, just needed to reboot my node apparently
<tgardner> ccheney, cool. I'll bug ttx about whether he wants a new kernel image. it'll completely piss off ogasawara.
<ccheney> heh ok
<ccheney> ttx, ^ :-)
 * ttx doesn't want to piss off ogasawara :)
<tgardner> ttx, can you live with a day-1 kernel update if she uploads right after A2 freeze islifted?
<tgardner> is lifted*
<ttx> tgardner: we would need to have a PPA with a kernel to allow some testing of eucalyptus during ISO testing
<tgardner> ttx, thas easy enough
<ttx> tgardner: I just don't want UEC untested on A2, if the test is: "you will hit that one, just do this to workaround it, then continue your testing" I'm ok with it
<tgardner> ttx, ok, then lemme get you a PPA kernel building.
<ttx> (also allows to validate the kernel upgrade, fwiw)
<ttx> kirkland: does that work for you  ? ^^
<cnd> apw, ogasawara: it looks like amd64 ddebs aren't getting published: http://ddebs.ubuntu.com/pool/main/l/linux/
<Keybuk> apw: thanks for the init cmdline patch; it works perfectly
<Keybuk> tgardner: you remember the iwl3945 problems I was having?
 * tgardner notes that apw is on vacation this week
<tgardner> Keybuk, sort of
<Keybuk> tgardner: seems it's definitely an upstream kernel issue, there's traffic on LKML about others experiencing it
<tgardner> Keybuk, 'iwlwifi: cancel scan watchdog in iwl_bg_abort_scan' just went into Linus' tree
<tgardner> as well as 'iwlwifi: serialize station management actions'
<tgardner> Keybuk, actually, there are a couple of i3945 specific fixes.
<Keybuk> yeah the updates pulled in seem to be the ones people have tested and say fixes it for them
<tgardner> Keybuk, so, we''ll get 'em as soon as Linus declares -rc4
<tgardner> Keybuk, you could always apply just the iwlwifi updates to an -rc3 Maverick kernel to see if it fixes your problems.
<Keybuk> yeah will try that
<Keybuk> the workaround suggested works for me too (ifconfig wlan0 promisc)
<ogra> so with the init comdline patch, do i need to use the vars in a literal way or are they capitalized by default ? 
<ogra> i.e. do i have root= as root= available in initramfs scripts ? or do i need to check for ROOT ?
<ogra> (i'm assuming the initramfs init has the vars globally available as well as upstart does)
<Keybuk> ogra: the patch does not affect such things
<Keybuk> all the patch changes is that, previously, the kernel would only pass unknown arguments to init (splash, frobmybar, etc.)
<ogra> what does it affect then ? i thought the vars get exported to the init environment
<Keybuk> with the patch, the kernel now passes all arguments to init, including those it knew what to do with
<Keybuk> basically, in the default install, it means that instead of just getting "splash" on its command-line, init now gets "ro quiet splash"
<ogra> ah, so i still need to parse the cmdline if i want to look for root= in an initramfs script ? 
<Keybuk> no
<Keybuk> just look at $root
<ogra> ah, sweet 
<ogra> thats what i'm looking for 
<Keybuk> anything with an = in has always, and is still, placed as an envvar in init's environment
<Keybuk> that is unchanged
<Keybuk> (indeed, much of the /proc/cmdline parsing in initramfs is entirely pointless for this reason)
<ogra> hmm, i thought that depended on an export in the /init script 
<Keybuk> nope
<ogra> ok, great
<Keybuk> the initramfs /init script is largely wrong, it makes a $ROOT by parsing /proc/cmdline
<Keybuk> when $root was always there all along
<ogra> right, i mistook it and used the same parsing routine in my initramfs scripts
<ogra> which apparently is a waste :)
<ogra> good to know
<ogra> i guess there are a lot of scripts that can drop such routines now ... the framebuffer handling parses /proc/cmdline too iirc
<ogra> ogra@osiris:~/Devel/branches/livecd-rootfs/livecd-rootfs-1.125$ grep -r cmdline /usr/share/initramfs-tools/scripts/*|wc -l
<ogra> 12
<Keybuk> "now" is irrelevant, as I said
<Keybuk> the patch doesn't change whether or not you need those routiens
<Keybuk> you've *never* really needed them for the = ones
<Keybuk> but you do currently need them to parse out keywords
<ogra> yeah, but there are a bunch that still parse the = ones 
<ogra> brltty, bootchart, blacklist and framebuffer definately do
<ogra> cnd, its pointelss to aks for imx51 or dove bugs to be confirmed fixed in maverick ... we should rather drop these packages from the archive 
<ogra> *ask
<amitk> ogra: cnd: I don't see any imx51/dove branches. What packages are being created?
<cnd> amitk: ogra is talking about bug 423767
<ubot2> Launchpad bug 423767 in linux-fsl-imx51 (Ubuntu Karmic) (and 3 other projects) "please enable rt2800usb and disable rt3070sta in the imx51 kernel (affects: 1) (heat: 26)" [Low,Fix released] https://launchpad.net/bugs/423767
<ogra> amitk, no packages, i just got bugmail for an ancient bug where cnd asked to check if its fixed in maverick
<cnd> so I'll just close it up as won't fix
<ogra> amitk, we dont remove binaries from the archive without someone asking for it, they still idle around in the archive atm
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - June-29 - 17:00 UTC
<ogra> cnd, well, might be an SRU thing, not sure
<ogra> cnd, though for that specific one its likely something to just close, i doubt anyone will actually put time into it
<cnd> ok
<cnd> I'm just trying to clear out crufty linux-firmware bugs :)
<ogra> yeah, i got that watching -devel :)
<ogasawara> tgardner: for the UEC bug, you're already handling pushing the fix to a PPA correct?
<ogasawara> tgardner: I'll get the kernel ready for upload and coordinate with the release team for the 0-day upload
<tgardner> ogasawara, yep, I'll feed you a pull request presently as well.
<ogasawara> tgardner: sweet
<tgardner> ogasawara, Changli says Jens Axobe hasn't acked it yet, so I think we'll carry it as an Upstream patch until it gets resolved.
<ogasawara> tgardner: ack
<ogasawara> cnd: not sure why the amd64 ddebs aren't getting published.  I'm not familiar with what magic is involved but I'm guessing pitti might?
<tgardner> ogasawara, its an archive admin issue
<ogasawara> tgardner: so pitti would be a good person to nudge
<tgardner> ogasawara, indeed, he is always a good person to nudge
<ogasawara> cnd: I'll ping him about it in #ubuntu-devel
<cnd> ogasawara: thanks!
<ogasawara> RAOF: just saw your common bug tag email for X and kernel.  I definitely agree we should converge on a common set of tags.
<ogasawara> RAOF: But ideally I'd like to wait to have this conversation when JFo and apw are around (both are on holiday this week).
<cking> another day, another BIOS check
 * cking reboots
<ogasawara> cnd: pitti will check on the ddeb issue tomorrow morning
<ogasawara> ok dudes, we've got 3 remaining Alpha2 work items.  I just want to get a status check if they'll be done by thurs or if I should bump them to Alaph3.
<ogasawara> jjohansen: "Refresh Xen patchset and get xen version of EC2 kernel working in Maverick".  I assume you're still working that.  Should I bump to A3?
<ogasawara> manjo: "blacklist old firewire stack & enable new stack", seems that's still in progress?  Should I bump it to A3?
<jjohansen> ogasawara: yeah, I thought I had done that already
<ogasawara> jjohansen: oh, if it's done, I can just close it
<jjohansen> ogasawara: no, I meant moved to alpha3
<jjohansen> when I talked to tim and andy last week
<jjohansen> hrmm, must not have saved
<ogasawara> jjohansen: hrm, I'll double check it and if it's not moved to A3 I'll move it
<ogasawara> cking: "Investigate situation with Intel graphics drivers on EFI".  Think you'll squeeze this in by Thurs or should I bump this to Alpha3?
<cking> ogasawara, I'm discussing this with Intel. Still open - I got a response today, I need to follow it up though. Maybe A3 is better
<ogasawara> cking: ok cool, I'll move it
<jjohansen> ogasawara: oh, I have to thursday for kernel alpha2 items?  I should have it done by then, if so should I mark it DONE and move it back
<ogasawara> jjohansen: yah, if you get it done by Thurs, just move it back and mark it DONE.
<jjohansen> okay will do
<tgardner> ttx, https://bugs.edge.launchpad.net/eucalyptus/+bug/588861/comments/38 (when its done building)
<ubot2> Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,In progress]
<ogasawara> tgardner, ttx:  I'm just waiting for armel to finish building so I can get the abi and start the next release.  Will apply the patch and have a kernel ready for the 0-day upload after that.
<manjo> ogasawara, I submitted the patch to ubuntu kenel mailing list 
<manjo> ogasawara, tgardner supposed to pick it up, and pgraner was going to submit more test results 
<ogasawara> manjo: right, but it doesn't look to be packaged and uploaded.  And since we're on the verge of the A2 freeze I assume it'll have to wait till A3.
<manjo> ogasawara, ok. tgardner any chance you will pick this one up for A3 ? 
<pgraner> manjo: I can't get it working
<tgardner> manjo, I've sent Keybuk a review request. Lemme find it.
<pgraner> manjo: none of the fw cards I have are detected under maverick, they are on lucidc
<Keybuk> tgardner: ah, well nagged
<Keybuk> fwiw, I'm maintaining module-init-tools using the new standard bzr model
<Keybuk> bzr branch lp:ubuntu/module-init-tools
<Keybuk> we don't use Vcs-Bzr for those
<pgraner> manjo: I just got a lap top (StinkPad X410) that maverick does see the fw card so I'll test today
<tgardner> Keybuk, I use bzr so seldom that its a half day learning curve each time
<manjo> pgraner, ok 
<Keybuk> tgardner: I would tend to NAK that patch
<Keybuk> can you not make acct=1 the default in the nf_conntrack module?
<pgraner> manjo: whats the link to the fw testing page again?
<tgardner> Keybuk, upstream is gonna make it 0
<Keybuk> yes, so we should patch that to be 1 in our kernel if we want that to be the default
<tgardner> Keybuk, well, I don't know that we do, but how is that related to firewire ?
<Keybuk> tgardner: ? firewire?
<Keybuk> I'm looking at your NF_CT_ACCT mail
<Keybuk> which is the most recent thing you mailed me to review
<tgardner> thats the review request I was referring to
<manjo> pgraner, just a sec 
<tgardner> Keybuk, hmm, lemme get my shit sorted out
<Keybuk> I don't have anything about firewire
<tgardner> keybugok, I remember now. I haven't written the firewire stack blacklist patch yet. I was waiting on results from pgraner. the  NF_CT_ACCT patch is a different issue, and may well be moot at this point.
<Keybuk> right
<manjo> pgraner, https://wiki.ubuntu.com/Kernel/SwitchFirewireStack
<Keybuk> firewire is just a matter of switching stacks, no?
<tgardner> Keybuk, yes
<Keybuk> unblacklist the new one, blacklist the old one
<Keybuk> and pick a date that we stop building the old one
<manjo> tgardner, won't the patch I sent to ubuntu kernel list work ? it was a bzr patch?
<manjo> Keybuk, we will build both ... just black list the old modules 
<Keybuk> right, and we should pick a day where we stop building the old one and drop support for it
<Keybuk> e.g. after 12.04
<manjo> ah
<manjo> if we don't see problems in maverick we could drop it altogether in M+1 
<Keybuk> not sure whether or not we need udev rules for it
<maks_> lol on Ubuntu for having old firwire :P
<maks_> Keybuk: you had the tradition to hire the wrong linux-2.6 hackers :)
<Keybuk> maks_: I didn't hire any hackers
<maks_> well i remeber the big press release when BenC got hired
<maks_> and the Ubutntu kernel put on kernel.org
<manjo> Keybuk, https://ieee1394.wiki.kernel.org/index.php/Juju_Migration
<Keybuk> Ben left before the new firewire stack was even written
<maks_> no i had been in the channel when he loled on us switching
<maks_> and leaving his rotten code.
<Keybuk> manjo: what I mean is that the rules already seem to be in upstream udev
<manjo> Keybuk, ack
<pgraner> manjo: ok, video works with both dvgrab & kino, will check the sbp2 stuff in a bit
<manjo> pgraner, ack... thanks
<maks_> the security implications of the old dma stack is fun
<maks_> makes it easy to poke anywhere.
<Keybuk> which is why we always locked it down to root-only
<manjo> maks_, and your point is ? 
<maks_> manjo: fun to see that you have an LTS with the old stack
<maks_> although your userspace back then already supported juju.
<Keybuk> it's always easier to support an older known stack for a long time than a shiny new one
<Keybuk> the new one was always there and was a simple config change for anyone to switch for it
<manjo> maks_, next LTS will have the new stack ... if that makes you happy
<manjo> maks_, like Keybuk said 
<cking> manjo, you're back from your travels?!
<manjo> cking, yes 
<manjo> cking, back and pretty tired 
<cking> much appreciate you going on the trip.  I'd like to catch up and get some feedback sometime, but when you're ready
<manjo> cking, yep we can mumble tomorrow ? 
<cking> manjo, yeah, good plan. I need to go in a mo, so tomorrow is good for me.
<jcastro> I bought a new laptop and the nic only works in maverick kernels, I suspect at some point the driver goes into lbm, when we do LTS point releases do those drivers end up updated on the media?
<tgardner> jcastro, compat-wireless in LBM shod be the solution. Those drivers will not show up i a point release
<jcastro> ok so I suppose that means this laptop won't be kickstartable for me with lucid
<jcastro> are normal NIC drivers in compat-wireless too?
<tgardner> jcastro, there are a few, but its mostly wireless drivers
 * tgardner lunches
<jjohansen> -> Lunch
 * ogasawara lunch
<Frode_Haugsgjerd> hey, i have an issue with xchi on my brand new hp 8540p, when i connect my nokia n900, syslog quicly grows with messages like this: "WARN urb submitted to disabled ep" 
<Frode_Haugsgjerd> i have of course searched the fine web, but only found the kernel code that emits this message
<Frode_Haugsgjerd> ok so i guess my question is, has anyone heard of this before?
<kees> ogasawara: will you be able to revert f1befe71fa7a79ab733011b045639d8d809924ad for the next kernel (bug 597075)?
<ubot2> Launchpad bug 597075 in linux (Ubuntu) (and 1 other project) "2.6.35 hangs at boot due to regression in i915 or intel_agp (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/597075
<ogasawara> kees: the only fear I have with reverting is it could then cause regressions for others
<ogasawara> kees: has there been any progress with upstream?
<ogasawara> kees: I saw the comments to the upstream bug report, but didn't seemed to present a solution, just more questions
<kees> ogasawara: they have no solution.
<kees> ogasawara: and reverting it would be the same as lucid's behavior.
<ogasawara> kees: I'm still debating :)  your point is valid that it does bring us back to lucid's behavior and you can at least boot.
<ogasawara> kees: I've got a 0-day Alpha2 kernel upload that's gonna take precedent and won't contain the reverted patch
<ogasawara> kees: so at best I'd like to maybe wait till we rebase to -rc4 and then revert if there's no better solution by then
<kees> okay
#ubuntu-kernel 2010-06-29
<RAOF> ogasawara: Hah.  Excellent timing for my email then!  Yeah, I'll wait for them to get back :)
<ogasawara> RAOF: cool.  just didn't want you think it was getting ignored.
<jjohansen> -> back on later
<bullgard5> What is the function of the phy0 process on my Ubuntu 10.04 computer?
<smb> bullgard5, Just a guess but phy* usually relates to network cards, so I would suspect a certain network driver to create it.
<bullgard5> smb: I see. Thank you for commenting.
<chetnick> Hello everyone. I would like to add support for few things in kernel without losing current configuration. I am on the default Ubuntu install/kernel right now. How do I do that? Would make oldconfig do the thing?
<mpoirier> ogra ?
<bjf> ##
<bjf> ## Kernel team meeting in two hours
<bjf> ##
<manjo> bjf, the meeting does not show on the canonical cal
<manjo> bjf, does it show for you ? 
<bjf> manjo, yes it does
<manjo> bjf, strange
<ogra> mpoirier, whats up ?
<mpoirier> ogra: I had questions but got in touch with Sebastien @ TI - all good.
<ogra> oki
<cking-afk> back in 15
<bjf> ##
<bjf> ## Kernel team meeting in 14 minutes
<bjf> ##
<ogasawara> tgardner, smb, apw:  just fyi , cjwatson  moved the kernel upload permissions to be attached to the ubuntu-kernel-uploaders team.  If this breaks anything (either upload permissions for any of us, or the ability to target bugs to releases), then please let him know
<smb> ogasawara, ok, will do as soon as I notice anything
<ogasawara> tgardner: you actually might not be affected as you're motu I think
<smb> ogasawara, sconklin, bjf FYI, if yo not already know this: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<sconklin> now ~that~ is a handy thing
<smb> sconklin, If you see a red bug number at the side of a kernel package, run! :)
<tgardner> smb, the SRU verification team must hate the kernel packages.
<smb> tgardner, They surely do. Even with the hundreds of patches hidden in one tracking bug, we cause quite a bit a work...
 * bjf has to run an errand will be back asap
<manjo> cking, around ? 
<manjo> cking, interested in uefi banter?
 * tgardner lunches
<kees> sure is nice to have a 64-way builder :)
<smb> kees, Surely beats my 4-way :-P
<manjo> cking, ?
<cking> manjo, I'm kinda tied up doing some OEM work and putting the kids to bed
<jjohansen> -> lunch
* 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-06 - 17:00 UTC
<shadeslayer> hi,is there a way to delay the boot,and to get it to go step by step? 
<shadeslayer> like each process is loaded one at a time and not getting it multi threaded
<kees> shadeslayer: there is not yet.  I really want something like this, though, it's very painful to debug at the moment.
<shadeslayer> :)
<shadeslayer> kees: were discussing a problem over at #ubuntu-x,its related to something between the boot and the part where gdm has to start up
<shadeslayer> X starts up,but g/kdm hangs
<kees> ew
<kees> smb: okay, so you have your local u-c-t branch, with one commit, and you want to merge the recent upstream u-c-t changes?
<smb> right. this is my current local head.
<smb> revno: 2796
<smb> committer: Stefan Bader <smb@maximegalon>
<smb> branch nick: ubuntu-cve-tracker
<smb> timestamp: Tue 2010-06-29 18:55:13 +0200
<smb> message:
<smb>   Assigned smb to CVE-2008-7256
<ubot2> smb: mm/shmem.c in the Linux kernel before 2.6.28-rc8, when strict overcommit is enabled and CONFIG_SECURITY is disabled, does not properly handle the export of shmemfs objects by knfsd, which allows attackers to cause a denial of service (NULL pointer dereference and knfsd crash) or possibly have unspecified other impact via unknown vectors.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2010-1643. (http://cve.mitre.
<smb> Oh shut up
<kees> heh
<kees> we should train ubot2 to only respond to CVEs if we specifically say !CVE....
<smb> That might be helpful
<kees> smb: alright, so if you do "bzr pull lp:~ubuntu-security/ubuntu-cve-tracker/master/" what happens?
<kees> who controls ubot2?
<smb> bzr: ERROR: These branches have diverged. Use the missing command to see how.  
<smb> Use the merge command to reconcile them
<kees> okay
<smb> kees, maybe someone in IS does?
<kees> so, now if you do "bzr missing" it should say 1 (yours) and 1 (marc's)
<smb> That says nothing as my change is pushed to my remote 
<kees> oh, sorry, "bzr missing lp:~ubuntu-security/ubuntu-cve-tracker/master/"
<smb> Basically I bzr branches from lp:~canonical-kernel-team...
 * kees nods
 * smb waits for bzr
<smb> ok says I am missing one change
<shadeslayer> kees: btw if you have any idea,head over to ubuntu-x :P
<kees> shadeslayer: I don't; I had been fighting bug 597075 which caused a much earlier hang
<ubot2> Launchpad bug 597075 in linux (Ubuntu) (and 1 other project) "2.6.35 hangs at boot due to regression in i915 or intel_agp (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/597075
<kees> smb: alright, so "bzr merge lp:~ubuntu-security/ubuntu-cve-tracker/master/" should pull down marc's change and apply it.
<shadeslayer> kees: ow
<kees> smb: and when you go to commit, you'll make a "merge" commit.
<shadeslayer> kees: when you have time,bug 593041
<ubot2> Launchpad bug 593041 in linux (Ubuntu) "New 2.6.35 kernel keeps toggling bluetooth radio and wireless radio (affects: 1) (heat: 192)" [Undecided,Triaged] https://launchpad.net/bugs/593041
<shadeslayer> its very annoying
<smb> kees, Well it pulls down the changes, yes and I can commit them, but then there is no evidence about those changes made by him
<smb> I think
 * shadeslayer didnt know it had 192 heat
<kees> smb: it's visible if you do "bzr log --include-merges"
<Kano> hi, why does my i5 run with 1200 mhz with lucid?
<Kano> then i installed powernowd and it went to 3334
<Kano> tested with load
<smb> kees, How obvious. :-P I am beginning to feel the urge of apw-like rants...
<kees> smb: now you know how I felt learning git when I already knew bzr.  :P  *head explodey*
<kees> tgardner: btw, I learned how to do a moving rebase when maverick gets rebased.
<kees> git rebase --onto maverick commit-of-old-maverick-head-in-my-maverick-topic-branch my-topic-branch
<smb> kees, Did you have to concentrate as much as I need to not to type git everytime I mean bzr. :)
<kees> smb: I still type "bzr" instead of git about 1/4 of the time.  :)
<smb> kees, hehe
<kees> though I'm now getting very angry that "bzr log" doesn't automatically use the $PAGER env var.  :P
<smb> Right that is very useful. As it is rare that you want to know about the first comit
<kees> no kidding :)
<kees> heh, maximegalon.
<smb> kees, Oh well, I still don't know how to override the local hostname with something sensible. :)
<kees> ~/.bazaar/bazaar.conf
<kees> [DEFAULT]
<kees> email = Kees Cook <kees.cook@canonical.com>
<kees> launchpad_username = kees
<smb> Ohhh, no BZR_EMAIL? :-P But thanks
<kees> and you can do individual overrides in ~/.bazaar/locations.conf
<kees> hm, looks like both $EMAIL and $BZR_EMAIL are respected, actually (so says "man bzr")
<jaminc> looking for some help tracking down the cause of an oddity... changing only the system's kernel version results in libvirt being unable to write to VM disk images unless the images are owned by root.  I've ruled out apparmor interactions as apparmor is uninstalled and the behavior persists
<jdstrand> jaminc: is this on maverick?
<smb> kees, Ok, guess i try to implement something of that in my scripts, as they also take some of that
<jdstrand> jaminc: actually, I was thinking it was something else, but you ruled out apparmor
<jaminc> jdstrand, not on maverick, but I guess I could give it a shot... Lucid's stock kernel works fine, but mainline's 2.6.34 and 2.6.35 exhibit the problem
<jaminc> had to move to mainline to fix a periodic kernel crash/reboot that appears to be related to the wireless
<jaminc> chatting with the libvirt folks, indications are that the write failure is some sort of kernel issue.  Considering that simply booting to an older kernel alleviates the issue, I'm inclined to agree, but not sure how to pin it down...
 * ogasawara late lunch
<dandel> i caught a regression between 2.6.35-rc1 and 2.6.35-rc5... however, i'm not sure what to classify the bug as.... the bug is that onboard keyboard and mouse on my laptop stopped responding to all input, however i can reboot the machine with a usb mouse.
<dandel> ** 2.6.35-rc3 (latest git revision)
<kees> how do I specify a branch in the request-pull ?
<kees> oh, duh [end]
<smb> kees, Yeah, sorry slow
<smb> kees, the name of the branch refers to the HEAD of it
<kees> I keep getting an error, though
<kees> warn: No branch of git://kernel.ubuntu.com/kees/ubuntu-maverick.git is at:
<kees> warn:   7bc505d: SAUCE: security: unconditionally chain to Yama LSM
<kees> warn: Are you sure you pushed maverick-yama there?
<kees> oh man, it must be time for lunch
<kees> I see the problem
<jjohansen> kees: something like
<jjohansen> git request-pull c2e8d51100f22433062a86ec36383b549b7eb191 git://kernel.ubuntu.com/jj/ubuntu-maverick.git atop
<jjohansen> using git:// is important
<kees> jjohansen: yeah, I was aiming at the wrong repo.  *hang head*
<smb> kees, Hah, this looks ok. Thanks for the hints
<kees> smb: okay, great
<smb> kees, Now it will get interesting if you ever pull things back. I *am* very confident of bzr as you see. :)
<kees> smb: heh
<kees> smb: this is why I like "bzr missing" it's kind of handy
<smb> kees, I won't go into the how this likely can be done with git just the same (or is not needed that much). Its too late here...
<jaminc> is there a place to report bugs found in kernels from the mainline-ppa?
<jjohansen> jaminc: https://bugzilla.kernel.org/
<jaminc> guess I'm a bit confused, are the mainline builds essentially just the kernel.org versions?
<jjohansen> yes
<jjohansen> just built into a deb for testing
 * jaminc slaps himself
<jaminc> thank you
 * smb Thinks its time to call it a day
<jaminc> Bug 16316 filed
<ubot2> Launchpad bug 16316 in debian (and 1 other project) "ximian-connector: FTBFS: Cannot find evolution libs (heat: 1)" [Unknown,Fix released] https://launchpad.net/bugs/16316
<jaminc> ubot2 got it wrong... https://bugzilla.kernel.org/show_bug.cgi?id=16316
<ubot2> jaminc: Error: I am only a bot, please don't think I'm intelligent :)
<ubot2> bugzilla.kernel.org bug 16316 in kvm "VM's started through libvirt can't write to disk image files unless the file is owned by root" [Normal,New]
<Kano> btw. i tested a lucid install, my i5-680 runs with 1200 MHz by default and does NOT scale up
<Kano> same with maverick
<Kano> is that normal...
<bullgard4> What does the message "ath5k_pci 0000:02:00.0: registered as 'phy0'" mean in http://www.ureader.de/msg/12564876.aspx? (My Ubuntu 10.04 dmesg produces the same message.)
<mjg59> It means that the atheros 5000-series wireless device at pci address 02:00.0 has been associated with the wireless core and given the name phy0
<ogra> Kano, its called green computing :P
<Kano> no its called stupid
<ogra> well, rather buggy i'd guess
<bullgard4> mjg59: What programs will use the name 'phy0' thereafter? '~$ iwconfig' only lists Â»loÂ«, Â»eth0Â«, Â»irdaÂ« andÂ»wlan0Â«.
<mjg59> bullgard4: It's not a network interface
<mjg59> iw will use the phy name for some things
<bullgard4> mjg59: In order to establish this association you spoke about, does the kernel just run a process called 'phy0'? (My Ubuntu 10.04 computer does run a kernel process called 'phy0'.)
<mjg59> No, that's just the kernel workqueue associated with the phy
<bullgard4> mjg59: Thank you very much for your explanations.
<Kano> i just tested a few things, ondemand does nothing with that i5, performance is 100% and conservative works too
<Kano> it scales up/down
<Kano> on demand does definitely not scale
#ubuntu-kernel 2010-06-30
<jjohansen> back in a bit
<kees> rock.  Yama is in security-testing-2.6#next
<ogasawara> kees: nice, congrats!
<kees> thanks, now for the next set of crazy patches...
<ogasawara> kees: I saw your pull request, will try to get it applied after I upload the 2.6.35-6.9 kernel
<kees> ogasawara: cool; no big rush, but I wanted to get it in so the /proc/sys paths can get normalized in other packages for when it does appear (I assume next week due to milestone)
<jcrigby> cnd: around?
<cnd> jcrigby: yep
<cnd> what's up?
<jcrigby> I have a dumb question
<jcrigby> got assigned to do kernel packaging for linaro some time ago
<jcrigby> just started looking into it today
<cnd> heh
<jcrigby> the dumb question is what crank to a turn to create the debian source pkg from a checked out kernel git tree
<cnd> yeah...
<jcrigby> I just want to understand how the ubuntu kernel works before tweaking for linaro
<cnd> our packaging can seem rather obtuse from the outset :)
<cnd> we're trying to document stuff on our wiki
<cnd> let me find the right page
<jcrigby> I did search the wiki but not much success
<jcrigby> I did try do_source_package=true do_full_source=true full_build=true fakeroot ./debian/rules printenv install-source
<jcrigby> but that just made the kernel source tarball
<cnd> jcrigby: https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
<jcrigby> ahh
<jcrigby> thanks
<cnd> oh, do you just need to know how to create the src package?
<cnd> that you can upload to a ppa or archive?
<cnd> if so, check out: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Preparing an upload
<cnd> (note the spaces in the url)
<cnd> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Preparing%20an%20upload
<jcrigby> thats what I happen to be looking into right now yes
<jcrigby> thanks again
<cnd> sure
<LLStarks> yo
<LLStarks> ndiswrapper isn't playing nice with 2.6.35 on ubuntu
<LLStarks> dkms loops
<LLStarks> ogasawara, apw. you around?
<lag> LLStarks: apw is not around
<lag> LLStarks: And I would have thought that ogasawara would still be in bed :)
<RAOF> Gah!  Go *away* vga16fb!
<RAOF> I've got a perfectly cromulent inteldrmfb providing fb0!  Your services are not required!
<RAOF> Weren't we going to stop binding vga16fb to everything?  Is that still happening?
<smb> RAOF, Depends on how quick the other fb driver is. I got an older system where it unfortunately is not
<cooloney> smb: how to compile a -pae kernel. there is no such target in fdr, binary-generic-pae
<cooloney> smb: thanks in advance
<smb> cooloney, Hm, must admit i have not selectively tried that. But it get produced with binary as a target on i386
<smb> cooloney, And the binary-generic-pae works here. Just tried
<smb> cooloney, Are you calling it on amd64?
 * smb pokes cooloney 
<cooloney> oh, it is i386
<smb> It is
<cooloney> let me try
<smb> On 64bit you don't need PAE 
<cooloney> $ fdr binary-generic-pae
<cooloney> make: *** No rule to make target `binary-generic-pae'.  Stop.
<smb> cooloney, uname -m ?
<cooloney> oh, need i build it in chroot?
 * smb slaps cooloney 
<smb> Always
<cooloney> smb: my bad. sorry man
<smb> No problem :)
<cooloney> smb: thanks man, building now. 
<smb> cooloney, You are welcome. just never tell me you are not using a chroot to build again. ;-P
<cooloney> smb: i remember. hehe, I play cross compiling for a long time
 * smb cries over the concept of history in bzr
<tgardner> smb, whats the story with the ext4 patchset that bjf proposed last week? Is it gonna make it into pre-proposed anytime soon?
<smb> tgardner, Though proposed is about to be moved kees was asking for security and guess what will win
<tgardner> smb, hmm, lets work with kees on that. is there a real kitten killer out there?
<smb> tgardner, Unfortunately there is the point release sort of soon and I fear time will run out
<smb> tgardner, I have not looked at the cves itself yet. They seem medium to low
<smb> tgardner, Actually there is another scary series which potentially should go into the point release
<tgardner> smb, scary series of CVEs ?
<smb> tgardner, I just prepared test kernels that got the writeback patch series (12patches)
<smb> tgardner, No not cve
<smb> Thats about our long time on sync or unmount
<tgardner> smb, ok. then I think you should ask kees about deferring these CVEs until after the point release so we can get some bug fixes in.
<smb> tgardner, I try to look at the complexity of the cves. If there is change to release them next week, this would be enough time for another proposed baking
<tgardner> smb, I'd sure like to see your writeback and bjf's ext4 fixes get into a pre-proposed kernel soon. it needs some exposure
<smb> tgardner, Steve and Brad did some test runs which sounded quite promising (no seen regression, against some fails before)
<tgardner> smb, are they running that XFS test suite? I think that is how some of the issues were originally found.
<smb> And I hope to get feedback on the writeback stuff from kees and some reporters with the test kernels
<smb> tgardner, yes they do
<cking> is "relatime" a defaulted mount option with Lucid? 
<tgardner> cking, I think you have to specifically turn it off.
<cking> tgardner, that came in when? Karmic, Lucid?
<tgardner> cking, I just remember seeing it as an install option, but don't remember exactly when. I think its been there since at least Hardy
<cooloney> tgardner: sorry for the confusing. i just assume wanna review the patch from TI's tree. -:)
<tgardner> cooloney, nope, I want 'em prequalified from you.
<cooloney> tgardner: as soon as i got updates from sebjan,  i will pull them into my tree after i reviewed them.
<cooloney> tgardner: yeah, understood
<bullgard4> What is the filename of the source code file associated with the driver file /lib/modules/2.6.32-22-generic/kernel/drivers/net/wireless/ath/ath5k/ath5k.ko for the loadable kernel module ath5k?
<bullgard4> Has ath5ko been compiled from several source code files? 
<bullgard4> s/ath5ko/ath5k.ko/
 * bjf is off to the dentist
<salvarane> hello
<ogasawara> LLStarks: I'm guessing you're seeing bug 590090
<ubot2> Launchpad bug 590090 in ndiswrapper (Ubuntu) "package ndiswrapper-dkms 1.56-1 failed to install/upgrade: ndiswrapper kernel module failed to build (affects: 8) (dups: 2) (heat: 181)" [Medium,Confirmed] https://launchpad.net/bugs/590090
<ogasawara> LLStarks: which is due to the upstream commit:
<ogasawara>   commit 22bedad3ce112d5ca1eaf043d4990fa2ed698c87
<ogasawara>   Author: Jiri Pirko <jpirko@redhat.com>
<ogasawara>   Date: Thu Apr 1 21:22:57 2010 +0000
<ogasawara>     net: convert multicast list to list_head
<salvarane> I have followed this guide http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ but , in the record "skipabi=true skipmodule=true fakeroot debian/rules binary-core2" I receved this "make: ** Nessuna regola per creare l'obbiettivo <<binary-rtai>>. Arresto "
<ogasawara> cnd: ddebs should be trickling in according to pitti
<cnd> ogasawara: cool, thanks!
<ogasawara> LLStarks: I'm curious as to why you're installing the dkms package for ndiswrapper though, we already roll it in the Ubuntu kernel
<salvarane>  hello
<salvarane>  I have followed this guide http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ but , in the record "skipabi=true skipmodule=true fakeroot debian/rules binary-core2" I receved this "make: ** Nessuna regola per creare l'obbiettivo <<binary-rtai>>. Arresto "
<vanhoof> salvarane: what did you name your flavor
<vanhoof> salvarane: did you name it core2 as well?
<salvarane> config.flavour.rtai
<vanhoof> salvarane: skipabi=true skipmodule=true fakeroot debian/rules binary-rtai
<salvarane> not found
<salvarane> I change the name for you
<salvarane> the real name is skipabi=true skipmodule=true fakeroot debian/rules binary-rtai
<vanhoof> salvarane: i followed those instructions this morning, and everything is building happily
<vanhoof> salvarane: maybe pastebin everything you did to compare
<salvarane> ok
<salvarane> I have followed this guide http://wiki.linuxcnc.org/emcinfo.pl?Ubuntu10.04Notes
<salvarane> step by step
<tgardner> salvarane, that looks basically correct. I would have run 'fdr updateconfigs' after 'fdr editconfigs'
<tgardner> there is lots of good stuff at https://wiki.ubuntu.com/Kernel
<salvarane> ok
<salvarane> I followed the guide http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ but I changed the name core2 into rtai
<salvarane> I following your link  https://wiki.ubuntu.com/Kernel thanks
<LLStarks> ogasawara, ndiswrapper-common is pulling in the dkms package
<ogasawara> who's the maintainer of that dkms package?  I actually didn't even know it existed till yesterday.
<salvarane> can I  use kernel vanilia into ubuntu lucid ?
<kaushal> hi
<kaushal> I am running a Ubuntu generic kernel on all the hosts running 8.04 server. is there a way to install server kernel on this host ?
<kaushal> We have found a bug on the automated install 
<kaushal> Please suggest/guide
<tgardner> kaushal, there should be a meta package called linux-image-server
<kaushal> tgardner, ok
<kaushal> so if i install it i should be having server kernel ?
<tgardner> yep
<kaushal> also do i need to reboot it ?
<kaushal> i think yes
<tgardner> i think yes
<kaushal> the issue is that we have this issue on all the 300 production servers
<kaushal> is there a easy way to do it ?
<tgardner> kaushal, I suggest you consult with your IT guys.
<kaushal> tgardner, Thanks
 * bjf is back
<jjohansen> rebooting
<Azoff> Hello folks
<Azoff> Just talked to NthDegree in #ubuntu about some strange lockups on one of our servers with raid5 and xfs as the fs.
<Azoff> I found a thread on the xfs ML about an race window in the xfs code.
<Azoff> From what I can tell, the Ubuntu Lucid kernel source is based on 2.6.32.11 and I think those xfs fixes were introduced in 2.6.32.12
<Azoff> atleast there's a hole bunch of xfs commits there.
<Azoff> NthDegree told me that there were a PPA for the mainline kernel, however he didn't know if any of the >.11 kerneles were stable enought to give a try.
<Azoff> What's you oppinion on this?
<Azoff> The only info I could get from the tech on site (server co-located) were this: Kernel Panic - not syncing: xfs_fs_destroy_inode: cannot reclaim 0xdc50efe4
<tgardner> Azoff, the kernel in -proposed is based on 2.6.32.14
<smb> Azoff, just today a Lucid update went out which brings in ... as tgardner says
<Azoff> oki, great!
<Azoff> Sorry, I'm kinda unfamiliar with Ubuntu pakages. How does this -propused package get into main tree?
<Azoff> Or can I try it without it being in the tree?
<smb> Azoff, Proposed is just an archive pocket which you have to opt in
<Azoff> ah, I see.
<smb> Packages go there before they are moved to the place where you will get them normally
<Azoff> how long before it will be moved (approx)?
<smb> Aprox -3 hours
<smb> IOW it has been done
<smb> You should see kernel updates when you check now
<tgardner> Azoff,  http://launchpad.net/ubuntu/+source/linux tells you the current status
<Azoff> no, I won't :(
<Azoff> I guess I have to wait a couple of hours... thanks for your help!
<sconklin> http://news.bbc.co.uk/2/hi/technology/10466317.stm Half a million Vaios 'recalled' for overheating - "But Sony said that this is "not a recall" and that the problem can be rectified with a software patch."
 * tgardner lunches
<kees> ogasawara: I just made a small update to my yama pull-request commits, so if you pulled already I can prepare a separate commit. otherwise, pretend nothing happened, and pull normally whenever you're ready.  :)
<ogasawara> kees: I haven't pulled yet, so I'm good
<LLStarks> ogasawara,  Julian Andres Klode <jak@debian.org>
 * ogasawara lunch
<jjohansen> lunch
<ogasawara> kees: for the yama pull request, should the following also be reverted?
<ogasawara> commit 066cf0cf62729b6107d9b6bda195f4346b1607e7
<ogasawara> Author: John Johansen <john.johansen@canonical.com>
<ogasawara> Date:   Thu Jun 24 08:12:55 2010 -0700
<ogasawara>     UBUNTU: SAUCE: fs: block hardlinks to non-accessible sources AppArmor portio
<ogasawara>     
<ogasawara>     This is the AppArmor portion of
<ogasawara>     commit 069cb89e17c6dc5b2a1de2469746bc42935850fb
<ogasawara>     Author: Kees Cook <kees@ubuntu.com>
<ogasawara>     Date:   Wed May 12 09:03:08 2010 -0700
<ogasawara>     
<ogasawara>         UBUNTU: SAUCE: fs: block hardlinks to non-accessible sources
<ogasawara>     
<ogasawara>     Applied on top of the current upstreaming version of AppArmor
<kees> ogasawara: if you're doing the reverts manually, yes.  if you're just pulling from my repo, no.  (I had to handle the "conflict" of that patch already)
<ogasawara> kees: ok cool
<kees> Yama and AppArmor should only be running into eachother in security/Kconfig and security/Makefile now, but I dealt with that in the first Yama commit.  everything else should be separate.
<kees> ogasawara: just to make sure we're on the same page, the top of my tree is 9578dd34c5949d41a1237d2ad080bcf438d963e7
<ogasawara> kees: yep, that's what I have
<kees> okay, rockin'
<kees> ogasawara: do you want me to re-organize my commit messages to include the cherry pick comments, or have you already pulled?
<ogasawara> kees: I haven't pulled yet, will probably do it tomorrow
<ogasawara> kees: I'm too lazy to build across all archs to get the abi's so I'm just gonna wait till I upload within the hour and then grab the abi's in the morning
<kees> ogasawara: okay, so should I re-do all the commit messages to include the cherry pick comment syntax you recommended?
<ogasawara> kees: that'd probably be best
<ogasawara> kees: just for tracking purposes
<kees> ogasawara: okay, I'll do that
<kees> ogasawara: since Yama adds a new CONFIG option, how should I record that in the git tree?
<ogasawara> kees: usually I just do something like "UBUNTU: [Config] Enable CONFIG_FOO=y" or something similar
<kees> ogasawara: if this is good, it'll be waiting for you tomorrow too: http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=commitdiff;h=12c65e02eed1309d24f6288e6bc7914857942af3
<ogasawara> kees: yep, looks good
<LLStarks> ogasawara, i'm still waiting for juliank to expain the required ndiswrapper dkms package.
<LLStarks> it doesn't work on the current maverick kernel
<ogasawara> LLStarks: ok thanks, keep me posted
<ogasawara> LLStarks: it actually might be preferred to go the dkms route rather than us maintaining it in the kernel
<ogasawara> LLStarks: we do the same for the broadcom drivers, ie use DKMS
<ogasawara> LLStarks: but that's something I can raise on the kernel-team ml
<LLStarks> would the module installation loops be a kernel problem or ndiswrapper problem?
#ubuntu-kernel 2010-07-01
<ogasawara> LLStarks: not sure on that, do you have some logs you can point to?
<LLStarks> one sec.
<ogasawara> LLStarks: just post them to a bug report for the time being, easier to track and share that way
<LLStarks> btw, i'd use the mailing lists, but i'm terrible about being bureaucratic.
<ogasawara> LLStarks: as long as you have evidence to support your opinion and not just ranting most people are understanding
 * ogasawara bails for a few hours, back on later
<warewolf> hey guys, I'm triyng to get my evtouch touchscreen on my asus t91mt working; it looks like the hid-mosart module isn't "finding" the touchscreen.
<warewolf> I'm using the xorg-edgers/multitouch PPA, and I see the device in lsusb, but the kernel doesn't want to attach a driver to it.
<jk-> warewolf: what's the usb vendor:device id in lsusb?
<warewolf> what they're supposed to be 0185 and 0486 (I may have those flipped, they're from memory)
<warewolf> lemme grab the eeepc, 1 sec
<warewolf> agh, it didn't resume correctly from suspend to ram
<warewolf> Bus 004 Device 002: ID 0486:0185 ASUS Computers, Inc. 
<jk-> looks good
<warewolf> this is under lucid btw
<jk-> warewolf: what do you mean by 'doesn't want to attach a driver'? you're looking for the driver link in sysfs?
<warewolf> jk- there's no device in /dev/input, and xorg doesn't recognize it as an available input device.
<warewolf> jk- oh, and the mosart driver doesn't seem to get loaded, and when I do load it, I don't see any messages in the kernel saying that it loaded and found a device.
<jk-> it doesn't look like it should print anything on module init / probe
<warewolf> hrm ok
<jk-> could you remove the module, `ls /sys/class/input`, modprobe the module, and do the ls again?
<warewolf> how do I tell udev to reload the rules and reevaluate them to kick off actions?
<warewolf> j- same number of entries in there before and after loading the module.
<jaminc> could use a bit of help here, I found a bug with a few of the kernels from the mainline ppa... I asked where I should file the bug report and was directed to https://bugzilla.kernel.org... so, I filed my report: https://bugzilla.kernel.org/show_bug.cgi?id=16316... however the response says to file it with Ubuntu's bug tracker...
<ubot2> bugzilla.kernel.org bug 16316 in kvm "VM's started through libvirt can't write to disk image files unless the file is owned by root" [Normal,New]
<lag> cooloney: ping
<apw> morning ...
<smb> apw, Argh a ghost :)
<ghostcube> -.-
<ghostcube> huhu
<smb> apw, It is not Friday, therefor you cannot be here
<cking> it's apw re-incarnated
<lifeless> smb: its nearly friday.
<apw> smb, really?  if you're sure
 * smb panics mildly
<lifeless> 3h23 to go IIRC the eastmost tz correctly.
<smb> lifeless, Looking at it that way, the weekend is near
<lifeless> smb: absolutely!
<lifeless> smb: 27h23m
<smb> \o/
 * amitk sets the count-down timer
 * apw whines about the disk io performance on his laptop
<apw> completely kills interactivity
<smb> apw has not yet found out about his sound problems
<lifeless> aren't you like a kernel guru? physician, heal thyself ?
<apw> wow 3 minutes from typing that to getting it in the window
<lifeless> _wow_
<apw> i am sure its the new fsync orieiented dpkg extract
<apw> basically eats your machine
<RAOF> apw: Yup.  Btrfs seems particularly ill-suited to fsync heavy workloads.
<smb> RAOF, Oh while you're around and I remember. Did you have a chance to ask some people to try the oversampling i2c patch for i915
<RAOF> smb: I haven't yet, no.  I just managed to rescue that mail from my spam filter today!
<smb> RAOF, Don't tell me you consider my lovely mails as spam. :-P
<RAOF> No, but bogofilter seemed to.
<RAOF> I've been rifling through the badly-encoded text and random phrase generator that is my spambox to rescue the ham.  And hit bogofilter with it.
 * smb wonders his mails are sometimes sounding like random phrases. Especially those written late or before the first coffee
<RAOF> :)
<RAOF> It also ate some perfectly well-behaved launchpad bugmail.  I don't think it's got a trigger on EDID or anything like that :)
<TeTeT> RAOF: horrible!
<TeTeT> smb: there was once a new maintainer wikipage telling people like me how to effectively create a new kernel from git. Do you happen to know where this is?
<RAOF> Oh, I've got it.  I just need to build away like a madman.
<smb> TeTeT, I think
<smb> TeTeT, Does this help https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
<TeTeT> smb: yes, that's it, fakeroot debian/rules binary-generic
<apw> smb, where can I find your 32.x.y tree ?
<smb> http://git.kernel.org/?p=linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git;a=summary
<smb> apw, git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git
<smb> Daviey, Was it you that wanted to send a SRU patch to the kernel-team mailing list?
<Daviey> smb, yep!
<smb> Did that happen? Cannot remember but maybe missed it...
<Daviey> smb, I've been checking linus' tree to see if it was committed there
<smb> Ah ok, so still waiting on that
<apw> oh is today alpha-2 ?
<smb> maybe
<smb> or it was yesterday if its Friday today
<apw> its thursday luckily
<Daviey> FYI, regarding the pad block issue - the fixed kernel is on our i386 image and the amd64 should be apt-get dist-upgrade away.
<lpd79> Hi
<lpd79> I'm trying to recompile (without any customizations) linux-image-2.6.31-10-rt from lucid
<lpd79> In the past I could just run skipabi=true skipmodule=true fakeroot debian/rules binary-rt
<lpd79> Now it's asking me some configuration questions
<apw> sounds about right, what fails with that
<lpd79> I want to reproduce the exact configuration that ships with Lucid
<lpd79> so it shouldn't ask me any oldconfig-style questions
<apw> indeed if the source had any it would not build
<lpd79> sorry, "if the source had any" what?
<apw> if the source needed configuration option answered it would not build in the build system
<lpd79> Right, that's what I thought, it would not be batch-compilable
<lpd79> Is there another step I forgot, e.g. copying a config file somewhere?
<apw> shouldn't be no, normally a binary-<flavour> does everything needed
<apw> where did you get the source
<lpd79> dget http://archive.ubuntu.com/ubuntu/pool/universe/l/linux-rt/linux-rt_2.6.31-10.153.dsc
<lpd79> Then dpkg-source -x, cd to the directory and skipabi=true skipmodule=true fakeroot debian/rules binary-rt
<lpd79> As a regular user, not as root
<lpd79> That dsc link is from http://packages.ubuntu.com/lucid/linux-image-2.6.31-10-rt
<apw> yep
<apw> lpd79, ok try doing an 'fakeroot binary/rules applypatchset' then do the build
<lpd79> Thanks, lemme try that
 * apw tries build without that
<apw> (with it a binary-rt worked for me without erroring)
<apw> yeah without it, errors on the config
<apw> not sure _how_ that gets done automatcially though
<lpd79> You mean debian/rules applypatchset...
<apw> i meant debian/rules apply-patchset
<apw> _ahh_ 
<apw> fakeroot debian/rules clean
<apw> that applies the patches, which the build ssytem does first
<apw> so
<apw> fakeroot debian/rules clean
<apw> fakeroot debian/rules binary-rt
<apw> should do the trick
<apw> no actually its more subtle than that
<apw> so you would need to do
<apw> fakeroot debian/rules clean
<apw> fakeroot debian/rules apply-patchset binary-rt
<lpd79> You're looking at the rules code I presume
<apw> yep
<lpd79> OK, that seems to get rid of the oldconfig questions.
<lpd79> Thanks
<lpd79> It's surprising that something as straightforward as re-building the kernel package isn't really documented anywhere
<lpd79> I mean, without creating a new kernel flavour etc
<apw> lpd79, it is for the normal kernels, but this is the RT kernel which is community supported
<apw> smb would i expect to see ddebs for your -proposed kernels in lucid ?
<lpd79> Thanks a lot apw. Bye!
<Daviey> Hi, Was the Intel NIC issue fixed in Maverick?
<Daviey> the e1000 issue
<apw> i suspect 'the' issue is not specific enough, i know of a number in the past which have been fixed, whether the one you mean is fixed i am unsure without knowing more
<Daviey> apw, intel e1000 didn't work in Maverick.. I was only aware this was a single issue.  I didn't realise there were multple ones.  I assumed you would be familar with it, so didn't state a bug number as i don't have it to hand.
<apw> the only one i remeber there was pending a firmware update on the machine in question
<Daviey> Ah, bug 591707
<ubot2> Launchpad bug 591707 in linux (Ubuntu Maverick) (and 1 other project) "After upgrade lucid -> maverick eth0 interface is gone (affects: 1) (dups: 1) (heat: 175)" [High,In progress] https://launchpad.net/bugs/591707
<apw> Daviey, yeah thats the one ... still waiting on the reporter to test a bios upgrade as far as i can see
<Daviey> This issue broke just before A2.. Is the best solution really to ask end users to bios upgrade?
<Daviey> Seems like a lotta users will have no net access post upgrade.
<apw> Daviey, i don't believe we know what the underlying issue is, Intel themselves suggest the update so one assumes its a firmware issue being glossed over by the kernel somehow
<apw> but without the reporter doing the work we're a bit hosed, cirtainly i do no have the H/W affected
<Daviey> apw, I have canonical owned hardware with the issue infront of me.
<apw> i also believe that people who do have this h/w do no see the issue, so its not clear how far this issue penetrates
<apw> then you are in a position to try the update, do you have more than one ?
<Daviey> I can do the firmware upgrade to try and follow through.. but i'm wondering if it's "better" to leave it on this for future fix
<apw> depends if you have more than one
<Daviey> apw, Sorry, i only have the one box with this
<apw> i'd need to confirm with rtg, but i believe he has more than one which are not showing the issue
<apw> could you attach the lspci output for your machine showing the issue, and indicate it also shows the issue
<Daviey> apw, well for further info.. this ISN'T the e1000 - it's the 82566DC.. But it's my understading that it uses the e1000 kernel foo.
<Daviey> apw, i'll attach that now
<apw> well if you attach the output, we can confirm if its even supported by the same driver or not
<Daviey> on it
<Daviey> apw, bug updated.. If your team wants me to try upgrading the bios - can you let me know please :)
<Daviey> annoyingly, this bug is blocking me :(
<apw> tim has the point on that bug, so i'll try and remmber to tell him you have the h/w
<apw> Daviey, what does lsmod | grep 1000 say
<Daviey> one mo
 * Daviey needs a KVM switch
<Daviey> e1000e      149486 0
<Daviey> apw, ^
<apw> Daviey, ta
<apw> Daviey, and thats in some other kernel yes?  as i believe the failure mode is to not see the card at all
<Daviey> apw, no.. that is A2 amd64 server iso, clean install - no updates
<apw> if you have eth0 mentioned in your dmesg then i don't hink you have the same issue
<apw> when your network is not working
<Daviey> apw, Ok.. it seems it's a different issue then
<Daviey> I have tried two cables, PXE boot works, but i die as soon as linux comes into play.
<Daviey> apw, should i raise another bug?
<apw> whats in your dmesg related to ethX ?
<Daviey> apw, dmesg is attached
 * smb is back
<Daviey> [    2.642747] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:19:d1:5d:e3:0f
<Daviey> [    2.642751] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
<Daviey> [    2.642770] e1000e 0000:00:19.0: eth0: MAC: 6, PHY: 6, PBA No: 1021ff-0ff
<apw> Daviey, does it appear in ifconfig  ?
 * Daviey does the monitor cable dance
<Daviey> apw, no, lo and a bridge
<apw> hrm, so perhaps it is the same, i'll have to get tim to look and confirm as i don't have enough context to know
<Daviey> apw, Okay, thanks for your help..   I'm sure tim will know he can hilight me when he comes about.
<apw> but i  don't see ethX in the reporters .35 boots, so i think its different at least
<Daviey> apw, scrub that about ifconig - that's because i couldn't configure at DHCP time during d-i.. so it's not in /etc/network/interfaces... However, eth0 does show in /proc/net/dev
<apw> Daviey, ok thanks, does ifup eth0 do anything
 * Daviey checks
<Daviey> Ignoring unknown interface eth0=eth0
<apw> though i think its not seen the link
<apw> [   18.731191] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
<apw> i don't see that in yours
<apw> worth looking to see what the lights are saying on the card and the other end of the cable if you have them
<Daviey> FWIW, the amber led is flashing 1 sec on, 1 sec off.  I don't know if that means anything :)
<Daviey> switch lights = off
<apw> hrm, so perhaps a PHY recognision issue 
<apw> i suspect getting your own bug filed is a good plan, get all we have discussed here in there
<Daviey> apw, ok.. will do that today
<Daviey> thanks apw 
 * apw lunches
<tgardner> lag, git log HEAD..FETCH_HEAD
 * apw bounces to take a kernel
 * abogani waves
<pgraner> sconklin: kernel is installed and running, I should know shortly if the problem gets resolved
<sconklin> cool
<pgraner> sconklin: looks like part of the Canonical infastructre is down, can't get to mumble or iso.qa.ubuntu.com
<sconklin> pgraner: mumble appears to still be working for me
<tgardner> pgraner, you ought to quit logging some of the inbound IP traffic. its pretty noisy
<smb> pgraner, chinstrap seems to be ok
<smb> but a lot of other things not
<pgraner> tgardner: yea I'll fix that up once I get this other issue worked out
<ogasawara> apw: around?  or drowning in emails from vaca
<pgraner> smb: yea something is up 
<tgardner> pgraner, well, its like obscuring oops in dmesg
<apw> ogasawara, both ... wassup ?
<pgraner> tgardner: yea, I know
<ogasawara> apw: I'm actually away starting tomorrow, wanted to double check if you could stand in for me at the release meeting tomorrow (and next fri as well)
<ogasawara> apw: I can email the bits to cut and paste tomorrow
<apw> ogasawara, sure no worries
<apw> is the agenda up yet?
<ogasawara> apw: thanks.  no agenda yet.
<ogasawara> apw: I'll wait for them to send it and then get you the bits
<smb> ogasawara, As long as it involves just talking apw can stand in anytime. :-P
<apw> ogasawara, whatever works for you :)
 * apw adds that to the 'why i bashed smb' list
<ogasawara> heh
 * smb knows it must be long :)
<smb> apw, And I could not resist to reply to that text message either. :)
<apw> smb, heh yeah, i deserved that :)
<apw> luckily for me you meet argentina next, whome we hate even more, so i can now support .de :)
<apw> though i suspect a fiver on spain is the sensible plan
<smb> Sounds reasonable. Its gonna get hard for sure
<apw> ogasawara, commit aabef8b240880439b91574c9a9e33dcc44bfd8c7 looks to fix the bnx2 compilation issues ... should be in -rc4
<ogasawara> apw: sweet
 * ogasawara makes a note
<ogasawara> apw: should -rc4 land next week, don't feel the need to rebase.  I'll do it when I get back.
<apw> ogasawara, ok :)
<apw> ogasawara, will there be an upload post freeze before you go ?
<ogasawara> apw: I did one last night, with the blessing of the release team.
<apw> ahh good stuff, so we'll not be so behind then
<ogasawara> apw: so my plan today is to the start the next release and pull in Kees' yama patches
<apw> and let that bake in pre-proposed ?
<ogasawara> apw: indeed, wanted to get it in and available for testing
<apw> sounds like a sound plan to me
<pgraner> ogasawara: I just canceled tomorrows release meeting FYI
<ogasawara> pgraner: oh cool
<ogasawara> apw: ^^
<apw> pgraner, heh you were doing the meeting ?
<ogasawara> haha
<pgraner> apw: no, I got a message from rick last last night asking me to do so since he and robbiew are on holiday
<apw> cking, about ???  commit b681f7d9ab4d697a214fa4428795790c3a937a89 (acpi change in linus tree) looks interesting for your sort of problems
<pgraner> apw: and its the day after A2
<ogasawara> I figured it'd be uneventful anyways following A2
<apw> pgraner, most excellent
<cking> apw, sorry, I'm multitasking in a conf at the mo, lemme have a look
<cking> apw, more "windows compatability" getting into the code ;-)
<apw> cking, VILE isn't it, but sounds like something you might test when seeing 'oddness' with new biosen
<cking> apw, I think it's possible to do some semantic analysis on the AML to do things. mmm..
<apw> cking, this one limits Sleep() in aml to 2s: 9cbfa18e8a7b34a32eddbd914a07f085962f50a8
<cking> apw, yeah, I was just reading that one
<apw> 2a6b69765ad794389f2fc3e14a0afa1a995221c2 cking more windoze compatibility
<apw> love it, windows is saving the ACPI non-volatile state in suspend to ram :/
<cking> apw, shoot, I thought it was only used for S4. Dammit
<apw> cking, thats what the spec says, not what windows assumes, you can imagine what bioses therefore do
<cking> Mad
<cking> that will slow down S3 marginally
<apw> as the symptoms are 'second suspend/resume failes' that sounded of interest to you
<cking> apw it's very interesting. Explains a lot
 * cking adds it to the growing list of S3 weirdnesses
<cking> apw, thanks for alerting me to these changes
<apw> sadly that means my jerky mouse is not fixed :(
<cking> haven't you fixed that yet?
<apw> i hoped someone would while i was on holiday ... sadly no joy
<mjg59> apw: Jerky approximately once every 5 seconds?
<apw> mjg59, nope the whole time, well thats unfair for periods of minutes while my kslowd's slog it out eating my cpu
<apw> they are 'happy' at the moment so things are ok, soon enough they will change their mind and bash each other a bit more
<mjg59> apw: Intel graphics?
<apw> mjg59, yeah, looking to be a bug in the output polling support
<mjg59> Yeah, hotplug interrupt breakage
<mjg59> Dave Airlie found a couple of issues
<apw> someone recons they solved it by reverting fbf81762e385d3d45acad057b654d56972acf58c
<apw> though i cannot yet confirm that this was enough to fix it
<apw> mjg59, got any pointer to the discussion, its not on my kslowd thread
<mjg59> intel-gfx, I think
<mjg59> He only dug it up yesterday though, so it may not be posted yet
<apw> ahh ok thanks
<apw> normally when i just find i have time to find a bug, and get it nailed is when the patch comes down from upstream, so about on target
 * apw wonders where dave hangs out
<apw> mjg59, if you are talking to him i have a solid reproduce on my system
<mjg59> He's on Brisbane time, so his working day starts literally as mine ends
<apw> mjg59, heh lovely location at least
<appelflap> hi, what git tree is ~kernel-ppa/mainline/daily built on? is it linux/kernel/git/torvalds/linux-2.6.git ?
<appelflap> also, is that what they call 'mainline'?
<ogasawara> appelflap: yes and yes.
<appelflap> ogasawara: thanks. there's a bug with "Please don't close it until the problem is fixed in the mainline." and it's closed, while the patch isn't in mainline yet. so i guess it's reasonable to ask them to reopen the bug
<ogasawara> appelflap: what's the bug#?  sometimes it's reasonable to close the bug in ubuntu even if it exists in mainline still, for ex if it's against Intrepid which is EOL.
<appelflap> ogasawara: https://bugzilla.kernel.org/show_bug.cgi?id=16235 is the upstream bug, which has a wrong conclusion (for now)
<ubot2> bugzilla.kernel.org bug 16235 in network-wireless "[REGRESSION] [IWL3945] Broadcast is broken?" [Normal,Closed: code_fix]
<appelflap> https://bugs.launchpad.net/linux/+bug/591016 is the corresponding launchpad bug
<ubot2> Launchpad bug 591016 in linux (Ubuntu) (and 1 other project) "DHCP does not work with iwl3945 (affects: 2) (heat: 12)" [Undecided,Triaged]
<ogasawara> appelflap: the ubuntu bug still looks to appear open.  the upstream bug does look a bit confusing based on the last comment but I'm wondering if that was just a mistake/typo?
<ogasawara> appelflap: http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=4d23e4e5eb50431426facf192354ad2506e2dd40 seems like the fix?
<appelflap> ogasawara: indeed
<ogasawara> appelflap: I'd say leave the upstream bug as is, since the commit is in the iwlwifi-2.6.git tree
<appelflap> ogasawara: ok, that will likely just be merged?
<ogasawara> appelflap: yep, we can leave the ubuntu bug open until the patch makes it's way into Linus' tree and we rebase
<appelflap> ogasawara: ok, cool, thanks!
<ogasawara> appelflap: I'll post a comment to the bug to explain it's not in Linus' tree which is why it's not in the daily mainline builds
<apw> sconklin, hey ... i think you worked out you could turn on drm debug ... how does one do that
<sconklin> one sec while I look it up :)
<sconklin> apw: echo 4 > /sys/module/drm/parameters/debug 
<sconklin> 4 is for mode setting debug, other bits are different
<apw> sconklin, where is that documented ?
<sconklin> apw: I documented it on the blueprint page, I think it's in kernel docs or maybe a header file, looking now
<sconklin> it's in include/drm/drmP.h
<sconklin> apw ^^
<apw> sconklin, thanks ... just found it too
<apw> [ 7127.610872] [drm:i915_driver_irq_handler], hotplug event received, stat 0x00000800
<apw> [ 7131.004211] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08000b00
<apw> [ 7131.010882] [drm:i915_driver_irq_handler], hotplug event received, stat 0x00000800
<apw> [ 7134.404340] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08000b00
<apw> [ 7134.411197] [drm:i915_driver_irq_handler], hotplug event received, stat 0x00000800
<apw> sconklin, getting constant hotplug events it seems
<sconklin> apw: Hmmm. Seems like there was a patch for that a while back, is this in Maverick?
<apw> yep maverick
<sconklin> that's not good
<apw> sconklin, any idea how to decode the numbers, i am suspicious its powersaving
<sconklin> apw: sorry, I don't know
<manjo> cking, in UEFI banter 
<apw> [ 7300.770314] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08400000
<apw> [ 7300.790073] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08400000
<apw> [ 7300.810302] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08400000
<apw> [ 7300.830308] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08400000
<apw> sconklin, and when it goes mad, its those ones which differ i see
<apw> sconklin, so thats saying 'digital port D' and a bit which is not defined ... 'has triggered hotplug'
<apw> presumably as we do not handle it ... bad shit happens
<sconklin> apw: back in the late Karmic/early Lucid time frame there were problems with phantom events from inputs which were not physically connected on the board, and some patches to fix that. I have not heard of it since, but this sounds similar
<apw> sconklin, this could easily be a connector not connected, as it claimed i have to display port connectors that have no external ports
<sconklin> let me take a glance at the upstream mailing list
<apw> sconklin, can you send me that list address so i can sub my gmail to it
<sconklin> apw: sure, there are two you are probably interested in. dri-devel and intel-gfx
<apw> mjg59, your suggestion it might be bad hotplug seems to be born out ... i am getting what appear to be undocumented bits set in my HOTPLUG status
<mjg59> Hurrah Intel
<apw> no comment
<apw> mjg59, any idea where the intel guys hang out ...
<mjg59> #intel-gfx
<apw> mjg59, thanks again
<sconklin> apw: http://lists.freedesktop.org/mailman/listinfo/intel-gfx and http://lists.freedesktop.org/mailman/listinfo/dri-devel
<sconklin> apw: is it a GM45?
<apw> sconklin, how do i tell, its something like that
<sconklin> lspci
<apw> its a 2a42
<sconklin> there is a mail on the list about a hotplug regression
<apw> got a pointer to it ?
<sconklin> working on it
<apw> ta
<apw>         INTEL_VGA_DEVICE(0x2a42, &intel_gm45_info),
<apw> sconklin, so yes it is a GM45
<appelflap> ogasawara: thanks for the reply in lp bug 591016! i'm not really in a hurry, so (if you haven't done it already) you don't need to build a test kernel for me.
<ubot2> Launchpad bug 591016 in linux (Ubuntu) (and 1 other project) "DHCP does not work with iwl3945 (affects: 2) (heat: 12)" [Medium,In progress] https://launchpad.net/bugs/591016
<sconklin> for now I'll forward the email, still looking
<apw> sconklin, ack
<ogasawara> appelflap: too late :)  it's no problem.
<ogasawara> appelflap: I just kick it off on one of our build boxes
<apw> dang it it is hard to hit the right box when its doing it
<appelflap> ogasawara: cool, thanks :-)
<sconklin> apw: mail on the way, and here's the archive link:
<sconklin> http://lists.freedesktop.org/archives/intel-gfx/
<kees> pgraner: you said you cancelled the release meeting?  is that kernel-team specific or did you mean the whole friday release meeting?  (I ask since the security team is figuring out who will cover for jdstrand at the meeting while he's on vacation)
<sconklin> apw - http://lists.freedesktop.org/archives/intel-gfx/2010-June/007077.html
<sconklin> "hotplug storms still here"
<kees> (pgraner: oh, nm, just saw the ubuntu-devel email.)
<sconklin> apw: I don't see a clear resolution in the threads
<ogasawara> kees: just fyi, I'm gonna tweak your yama commit msgs (to drop the sha1 id's per tim's comments in the thread)
<ogasawara> kees: hope that's ok, since I'm the one who told you to put them there :)
<apw> sconklin, yeah the fix they suggest trying is already in
<sconklin> pgraner: tomorrow there should be a kernel in Lucid preproposed which has all the ext4 patches plus the various stable ones which are queued. lbm and meta should be there too unless I screwed it up
<kees> ogasawara: heh, I don't mind at all -- I just wanted it in whatever state you were most happy with.
<manjo> smb, which is the upstream stable tree then ?
<smb> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git
<smb> manjo, Thats one of them
<smb> apw, Here we go 23/149/164/200
<apw> smb ?
<smb> apw, That are the number of patches in the reviews for 2.6.27,32,33 and 34 o_O
 * apw closes his eyes, logs off, and opens a beer ... madness
 * ogasawara lunch
<bjf> pgraner, just looked at your comment to bug 588069
<ubot2> Launchpad bug 588069 in linux (Ubuntu) "Lucid kernel is missing a large number of important ext4 bug fixes (affects: 4) (heat: 26)" [High,In progress] https://launchpad.net/bugs/588069
 * apw wanders out to the balcony ... smb ?
<bjf> pgraner, not sure it is relevant to that bug, can you open a new bug on that issue :-)
<apw> ogasawara, hey ... why has u-m got branches for fsl-imx51 etc ?
<bjf> apw, i just looked it doesn't
<bjf> apw, not on zinc anyway
<apw> bjf, hrm, somehow it _has_ in the past but not now and i'd not pruned them ... very odd indeed
<ogasawara> apw: that is quite odd as I don't ever recall creating any topic branches for maverick
<pgraner> bjf: that kernel fixed the issue
<bjf> which kernel?
<bjf> pgraner, i thought you said my test kernel didn't fix the problem you were seeing
<pgraner> bjf: it did, the issue I had was user error on my part, I've been running now for over 4+ hours, where before I couldn't run more than 30 mins
<pgraner> bjf: earlier issue that is, I knocked the power supply out of the drive on my desk and didn't realize 
<bjf> pgraner, that's very good to know
<pgraner> bjf: woould have told you sooner but had to run to an eye appt.
<bjf> pgraner, can you update the bug with that info, thanks
<pgraner> bjf: yep right after this call I'm on :)
<pgraner> bjf: done
<kees> ogasawara, sconklin: I've sent a patch, based on some limited discussions and debugging with upstream, to deal with my i915 hangs.  can I convince you to take it at least as a temporary work-around so I don't have to keep building my own custom maverick kernels?  :)
<sconklin> kees: maverick or lucid?
<kees> sconklin: maverick.  lucid has the old logic
<sconklin> ok, then ogasawara will have to make the call
<kees> sconklin: i.e. lucid is prone to https://bugzilla.kernel.org/show_bug.cgi?id=15733 but not https://bugzilla.kernel.org/show_bug.cgi?id=16294
<ubot2> bugzilla.kernel.org bug 15733 in Video(DRI - Intel) "Crash when accessing nonexistent GTT entries in i915" [Normal,New]
<kees> originally, I had asked that f1befe71fa7a79ab733011b045639d8d809924ad be reverted, but that would have re-introduced https://bugzilla.kernel.org/show_bug.cgi?id=15733.  The new patch fixes the G33 behavior, so the result leaves both bugs fixed.
<sconklin> kees: I think we've reached bug equilibrium in the 915 driver. You can't remove one without adding another
<kees> sconklin: heh
<ogasawara> kees: I'm out for the week starting this evening and am not planning another upload before then.  Not sure if apw or rtg will do an upload while I'm gone.
<ogasawara> kees: so I probably won't apply it before I take off to give them a chance to review as well
<ogasawara> kees: but they have the proper permissions to commit it in my absence
<kees> ogasawara: okay cool; I'm just hoping to get it in before the next upload so I don't rebreak my machine.  ;)
<ogasawara> kees: ack
<manjo> hughhalf, available for a short chat ? 
<jono> hi all
<jono> quick q
<manjo> hi jono
<jono> what is the best way of checking if my machine is 64-bit? cat /proc/cpuinfo?
<jono> hey manjo
<manjo> jono, whether you are running 64bit install or if the cpu is 64bit ? 
<jono> manjo, if the CPU is 64-bit
<manjo> proc cpu info
<jono> riht
<jono> manjo, what am I looking for?
<jono> uname -a says I am running: 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux
<jono> which would suggest this is a 64-bit machine
<mjg59> Or magic
<manjo> so you are running 64bit kernel which means you have 64bit ok
<mjg59> But the former is more likely
<jono> LOL
<manjo> jono, sorry I was chatting with hughhalf ... 
<manjo> jono, flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority
<manjo> where lm == long mode 
<manjo> long mode is for 64bit cpus
<manjo> and Protected Mode is 32-bit CPU
<manjo> jono, ^^
<jono> thanks manjo :)
#ubuntu-kernel 2010-07-02
<apw> kees, can you point me at the bug and patch so we can look it over
<kees> apw: bug> https://bugzilla.kernel.org/show_bug.cgi?id=16294 patch> https://lists.ubuntu.com/archives/kernel-team/2010-July/011457.html
<ubot2> bugzilla.kernel.org bug 16294 in Video(DRI - Intel) "[Q35 bisected] hang at init of i915 driver" [High,New]
<kees> what does this mean in /proc/cpuinfo ?
<kees> address sizes	: 36 bits physical, 48 bits virtual
<warewolf> jk-: any bright ideas on getting my t91mt touchscreen working?
<dandel> apw and ogasawara can ya confirm this bug (it's about the ubuntu 10.04 configuration and the newest kernel releases, along with a fix) https://bugzilla.kernel.org/show_bug.cgi?id=16325
<ubot2> bugzilla.kernel.org bug 16325 in Input Devices "i8042 input regression" [High,New]
<bullgard_> What does the verb "to checkpoint to" mean? As in /usr/src/linux-source-2.6.32/drivers/platform/x86/thinkpad_acpi.c
<jk-> bullgard_: 'save', i guess
<dandel> bullgard_, another guess would be the intended destination.
<bullgard_> jk-: I will accept your proposal as a working hypothesis.  --  Thank you for your help.
<bullgard_> dandel: I did ask for the meaning of a verb. I know the meaning of the noun "checkpoint" in programming.
<cooloney|dell> ls
<amitk> make nconfig feels a lot nicer than make menuconfig
<smb> cking, \o 
 * apw yawns
 * abogani waves
 * cking yawns, i was coding at 5.30am
 * smb waves back in generic directions
<Daviey> Gooooooood morning kernel team!
<apw> cking, bad cking 
 * apw waves
<smb> Daviey, Just replied to your request. Its upstream now, though in two parts. But I have split the patch in your name
<Daviey> The kernel patch mentioned in: https://lists.ubuntu.com/archives/kernel-team/2010-July/011460.html has now been applied to linus' 2.6 tree.. Does this change anything that i should be doing?
<Daviey> smb, heh
<smb> Daviey, Only nearly beat you to it. :)
<Daviey> smb, Thanks.. appreciated your work on this
<RAOF> Good morning smb, apw :)
<smb> RAOF, morining
<amitk> apw: could you remove me as admin of kernel-team ML? I seem to have misplaced the password to do it myself.
<apw> amitk, i may be able to
 * apw waves to lag-mobile 
<amitk> apw: thanks
<apw> amitk, ok i think you should no longer get spammed by the list
<amitk> super
<kraut> moin
<ogra> hmm, no lag and no mpoirier yet
<smb> ogra, lag has network issues
<ogra> ah
 * ogra has kernel issues :P
<smb> We are the team with a kernel problem. :-P
<ogra> well, it pays off, doesnt it ? 
<smb> Literally. :)
<ogra> heh
<ogra> argh !
<ogra> why is the omap4 metapackage named linux-*ti*-omap4
 * ogra sighs
 * ogra guesses he has to wait until tgardner gets up for that to be fixed :/
<apw> ogra, wassup?
 * apw pokes ogra 
<ogra> apw, well, a) the package doesnt follow the general naming scheme we have 
<ogra> and b) a 2.6.35 meta package depends on a 2.6.34 image
<ogra> see #ubuntu-devel
<ogra> lag_, so you are back and stable ? 
<ogra> lag_, we found i little prob with the omap3 kernel yesterday, seems the NAND driver vanished between lucid and maverick
<lag_> ogra: No, I am using my mobile phone ... Eeek!
<ogra> ouch
<lag_> ogra: I can't help you with NAND - BBXM doesn't have any
<ogra> you dont have the C4 ? gah, i always forget who has what
<ogra> i'll wait for mpoirier 
<ogra> i suspect its just a config skew
<lag_> ogra: No problem - sorry I couldn't help
<amitk> ericm|ubuntu: dude! 
<yao> amitk: I am here, :)
<amitk> ericm|ubuntu: I'd like you to introduce you to yao who works for CodeSorcery and is based in Beijing
<amitk> er, CodeSourcery
<ams_cs> sorcery and sourcery are not entirely overlapping fields ...
 * apw waves to yao 
<yao> apw: hello, 
<apw> welcome to our little club :)
<yao> apw: thanks, my pleasure...
<amitk> ams_cs: IMO sourcery and sorcery is one and the same for you compiler writers :-p
<apw> anything which takes longer to build than the kernel is a black art by definition
<ams_cs> apw: black art doesn't need compiling - that's done in assembler
<apw> so very true
 * lag_ has his internet-net in tow and it going to bag some cloud (going to buy an internet dongle)
<apw> lag_, lag just reappeared
<lag_> =:-0]
<lag_> But I have my internet-net ready and everything!
 * lag_ takes his jeans off and puts back on his 'comfy pants'
<cking> too much detail
<lag_> I was just uploading pictures to Photobucket - you don't want the link?
<apw> *slap*
<apw> lag_, you sound like you are under water
 * cking has all sorts of issues with maverick - wifi not working, X chewing up CPU, machine running at 85 degrees C
<apw> cking, is that a real maverick install or just the kernel ?
<cking> just done a full upgrade and regrettingit
<lag_> apw: Yeah, I think the internet is still not quite right
<lag_> But at least it's up
<apw> yeah i expect they have some damn string papered over the crack
<lag_> And not wet it yet?
<apw> right, they always forget to spit on it
<tgardner> but it'll short out if it gets wet
<lag_> Yum
<apw> tgardner, yeah but its pretty while its working :)
<tgardner> cking, there is no going back. now you have to fix it :)
<cking> hrm, when I stop moving the cursor it vanishes
<cking> urgh
<tgardner> cking, thats the new surprise feature. its always a surprise when it reappears
<cking> very amusing
<tseliot> cking: that's "unclutter"
<tseliot> the name of the program which does that, that is..
<cking> that's an intentional feature?
<ericm|ubuntu> yao, hi - nice to meet you
<yao> ericm|ubuntu: me too, good evening, :)
<ericm|ubuntu> yao, so you are the 2nd employee here in China of CodeSourcery?
<ericm|ubuntu> yao, did you ever meet Jie?
<yao> ericm|ubuntu: right, jie si the first one,
<yao> ericm|ubuntu: nope, :(
<ericm|ubuntu> yao, cool - guess we will find chances to meet together
<yao> ericm|ubuntu: Yes, we should, 
<ericm|ubuntu> yao, so are you working on CS toolchain?
<yao> ericm|ubuntu: I see your photo in linaro wiki yesterday,
<yao> ericm|ubuntu: yes,
<ericm|ubuntu> yao, cool - now I know who to harass should there be issues in toolchain ;-)
<yao> ericm|ubuntu: oh, absolutely,
 * cking may go offline, CPU is at 85 degrees and I'm not happy about it overheating
<smb> Neither the CPU I guess
<cking> heh
<cking> it's smokin'
<komputes> I'm looking at Bugs #561926, #425264 & #550401 concerning Thinkpad X31 suspend/resume issues. Would anyone in #ubuntu-kernel be able to offer a fix for this issue?
<ubot2> Launchpad bug 561926 in linux (Ubuntu) "Thinkpad X31 fails to resume after suspend (affects: 6) (heat: 62)" [Undecided,Incomplete] https://launchpad.net/bugs/561926
<ubot2> Launchpad bug 425264 in linux (Ubuntu) "[IBM 2673PXG] Thinkpad X31 suspend/resume failure (affects: 6) (heat: 38)" [Undecided,Triaged] https://launchpad.net/bugs/425264
<cking> that's better
<tgardner> komputes, I think there are some patches coming via stable updates in Lucid that might help this. You could have them try the Lucid kernel in http://ppa.launchpad.net/kernel-ppa/pre-proposed/ubuntu (if it ever builds)
<komputes> tgardner: thanks tim, so this is something that will be included in maverick kernels
<tgardner> komputes, yep
<komputes> tgardner: sweet, thanks
<cking> Hrm, Lenovo "Rest in Peace". It's dead jim
<tgardner> cking, did you manage to let the smoke out of your Lenovo?
<cking> it's not a happy bunny
<cking> normally the thermal trip kills it at 80 degrees C, it got to 95 and it's not happy
<cking> ho hum
<smb> Time for the fridge?
<cking> time to get reserve H/W out of the box
<cking> df
<cking> heh, plenty of H/W to chose from
<apw> cking, testing your machines to destruction again?
<cking> not by choice
<cking> I think my lenovo's days are looking numbered
<apw> was that running maverick ?
<cking> yes, for about 10 mins
<cking> cooked it
<cking> X was maxing out one CPU
<apw> not had any issues with stuff running maverick kernels overheating ...
<komputes> cking: my friends laptop runs at ~100c and HP says it's "normal"
<apw> hp is full of doo-doo if they think anything will live long at 100c
<cking> komputes, my lenovo usually hits thermal trip at 80
<komputes> agreed
<cking> I don't want a machine that can boil water
<cking> ;-)
 * cking will get the screwdriver out over the weekend and poke around
<johanbr> my last HP laptop had some weird multi-threaded ACPI setup, and it took a while before a kernel came out that could understand that
<johanbr> I smelled really hot metal once, and I think it got to 105 degrees before it shut itself down. It still runs, though.
<cking> it's when one sees blue puffs of smoke you know you are in trouble
<apw> bonkers ... how can that heat hope to stay away from ones groin ... scorching
<cking> it's a laptop not a nut cooker
<apw> cking, :)
<ogra> apw, hmm, seems we still get a linux-ti-omap4 binary ... http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-meta-ti-omap4/
<tgardner> ogra, the source package is still names ti-omap4, but the binaries it produces should be just -omap4. I don't see any incorrect 901.2 packages yet 'cause I think its still pending a build.
<apw> ogra, none of the binary packages have even been NEWd so the ones there are likely old
<cking> pgraner, ping
<ogra> apw, oh, indeed, i'm confused because the former ones also ended up in universe 
<lag_> tgardner: What's the difference between doing "git diff HEAD..FETCH_HEAD" and "git diff HEAD FETCH_HEAD"?
<apw> ogra, indeed only the source is in there, the binaries are not there at all
<ogra> i was just reacting on the new dir that showed up suddenlx
<apw> lag_, i would expect them to be identicle
<ogra> tgardner, the build finished a while ago
<lag_> What's the .. all about then?
<ogra> tgardner, https://edge.launchpad.net/ubuntu/+source/linux-meta-ti-omap4/2.6.35.901.2/+build/1850527
<cking> it works like a set operator
<tgardner> ogra, oh. I would have expected the binary packages to end up in main
<apw> lag_, the <x> <y> and <x>..<y> forms are synonymous
<ogra> sorry for the confusion, there is indeed a linux-omap4
<ogra> tgardner, that needs some admin fiddling for new packages 
<ogra> tgardner, but its all sorted
<lag_> kk - thanks
<apw> ogra, the binaries should end up in the source packages directory right?  and that has ti- in it still as its the branch name which is not changes
<apw> lag_, the first form is the original form, the second is there as that has become the common form for other commands, and it allows understanding of the <x>...<y> form as well
<ogra> apw, right, NEW is the issue here
<apw> ogra, indeed, and they are new packages cause they changed names, so all is as expected
<ogra> yep
<ogra> confusion was on my side 
<ogra> my brain is fighting the heatwave here 
<pgraner> cking: pong
<cking> pgraner, earl send me a couple of laptops but they are stuck in customs - I got a demand for Â£143.09 to pay the tax and release them
<cking> do I pay this and we extract the expense from earl later or what?
<m4tr1x> hi
<m4tr1x> what's the correct way to commit a kernel patch to ubuntu?
<apw> m4tr1x, normally we look at patches sent tot he kernel-team email list, details can be found in the FAQ: https://wiki.ubuntu.com/Kernel/FAQ#Can I get a patch included in the Ubuntu Kernel?
<m4tr1x> ok
<dandel> apw, make-kpkg has a few problems on ubuntu 10.04 and making sure the i8042 driver is built into the kernel in the latest torvalds git repo.
<m4tr1x> thanks
<m4tr1x> i fix the problem with marvel 9123 sata3 controller
<apw> m4tr1x, sounds excellent, thanks for looking at it ...  is there a bug report open for that ?
<m4tr1x> i think yes
<apw> dandel, yeah not many of the kernel team use the make-kpkg so i can believe it could have bit-rotted for our use
<apw> dandel, whats the problem with i8042 ?
<dandel> latest kernel git doesn't include it at all.
<dandel> however, i tested against 2.6.35rc1, 2.6.35rc2 and so forth
<apw> dandel, ??
<dandel>  it's not built at all
<dandel> https://bugzilla.kernel.org/show_bug.cgi?id=16325 (i made a kernel report about it)
<apw> for maverick kernels or for the mainline kerenls
<ubot2> bugzilla.kernel.org bug 16325 in Input Devices "i8042 input regression" [High,New]
<dandel> mainline
<dandel> i used make-kpkg to make it easier to clean up after each bisect (but it took an insane time to build)
<m4tr1x> apw, https://bugzilla.kernel.org/show_bug.cgi?id=14543
<ubot2> bugzilla.kernel.org bug 14543 in Serial ATA "AHCI SATA: hard link reset on controller power management change" [Normal,New]
<m4tr1x> :D
<apw> m4tr1x, sounds bad ... thanks
<dandel> i already identified the patch which is causing the chaos though: namely commit: 0b28bac5aef7bd1ab213723df031e61db9ff151a
<apw> make sure you mention that in the bug report
<apw> dandel, i wonder why our maverick kernels are not affected
<apw> being 35-rc3 based
<dandel> anyways, how do i get make-kpkg to let me customize the config params then.
<m4tr1x> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539467
<ubot2> Launchpad bug 539467 in pm-utils-powersave-policy (Ubuntu Lucid) (and 4 other projects) "SATA link power management causes disk errors and corruption (affects: 19) (heat: 139)" [Undecided,Fix released]
<apw> dandel, if i am fair i never have used it
<apw> dandel, i use the normal build system as i care if that works for my uploads
<dandel> either way, the patch changes the default setup by explicitly disabling i8042 input driver whenever the X86_MRST flag is set
<apw> dandel, we have _MRST turned on
<apw> debian.master/config/config.common.ubuntu:CONFIG_X86_MRST=y
<apw> debian.master/config/config.common.ubuntu:CONFIG_SERIO_I8042=y
<apw> and seem to have 8042 enabled too ?
<dandel> yes, and i8042 is required for the test machine.
<dandel> without it, i have no mouse and keyboard
<apw> right, but i have both turned on in a 35-rc3 kernel there i believe
<dandel> it's post -rc3 commit.
<apw> dandel, ahh ok, so we are about to get mooshed by it ... hrm
<apw> do yo have a fix, or just the offending commit ?
<dandel> no fix, just unroll the offending commit
<dandel> i'm trying to find the i8042 driver in the config file of default kernel t ho
<apw> dandel, i thought this was familar
<apw> we hit the bug he is tryign to fix, namely that the serial must be =y if atkbd=y
<dandel> and i'm not able to find the i8042 driver in the input devices on the latest config.
<apw> but we fixed the config, but his change seems wrong
<dandel> i'm expecting it to be under device drivers -> input device support -> keyboards (at keyboard has a star)
<mjg59> You can;t modify the i8042 settings unless CONFIG_EMBEDDED is on, IIRC
<dandel> however, i8042 is missing.
<apw> yep, and its not allowed to be if the other one is on under the new
<apw> config as he did it
<dandel> either way, it's best to know of the bug and squash it before you get the whack from it.
<apw> yep, thats just plain the wrong change as far as i can see
<apw> did you only report it in the bugzilla or also email randy ?
<dandel> bugzilla only
<dandel> either way it's a high priority bugfix.
<apw> be best to email him direct and CC: lkml and mention the issue, feel free to copy our team list too
<mjg59> It's been discussed upstream already
<apw> mjg59, ahh ok
<mjg59> And a patchset to replace it with a boot-time check has been psoted
<apw> ok so hopefully we can suck that up instead
<dandel> the if statements that that guy setup explicitly makes it impossible to even set that as a loadable driver also.
<apw> mjg59, i won't ask how you can keep abreast of the whole of lkml
<apw> dandel, yeah we need to find the upstream discussion
<dandel> apw, where's the conig option for embedded at?
<apw> dandel, i normally just edit the configs with VI
<dandel> oh and sad part, the patch is from oracle ><;
<dandel> the fix for that should have been in code, not kconfig.
<apw> dandel, heh its easy to say once you have messed up everyones machines :)
<apw> dandel, randy suggests reverting that patch regardless of whether they ahve a fix
<apw> so i suspect they will at least do that for -rc4
<dandel> that will be good, anyways, i think that the i8042 chips are super common for laptops.
<apw> dandal thanks for bringing it to our attention :)
<dandel> found the thread and post.
<dandel> jun 9th is when the patch hit the mailing list.
<apw> yeah that looks like a foundation for a solution
<smb> Actually the i8042 is super common for all intel based machines I know of
<dandel> apw, also, this bug report is now fixed (just waiting for the patch to make it into mainline) https://bugzilla.kernel.org/show_bug.cgi?id=14736
<ubot2> bugzilla.kernel.org bug 14736 in Config-Interrupts "Toshiba P305D unhandled ACPI Interrupt" [Normal,Resolved: code_fix]
<dandel> as of 35-rc1 the suspend is working nicely (except for memory corruption errors on suspend/resume that is caused by radeon kms)
<apw> joy for bad biosen
<dandel> yea, it's a pheonix bios
<kees> smb: for CVE-2010-1643 you have upstream marked as not-affected.  should that be "released" instead?  (there an upstream patch)
<ubot2> kees: mm/shmem.c in the Linux kernel before 2.6.28-rc3, when strict overcommit is enabled, does not properly handle the export of shmemfs objects by knfsd, which allows attackers to cause a denial of service (NULL pointer dereference and knfsd crash) or possibly have unspecified other impact via unknown vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1643)
<kees> *there's
<smb> I guess that would be better. I usually tried to mark it as released
<smb> kees, Sorry if that one went wrong
<kees> smb: yeah, everything else looks great.
<kees> smb: oh, no worries at all.  all the rest are fantastic.  :)
 * kees loves  "git tag --contains SHA1"
<smb> kees, Yeah. Hm, I am a bit confused atm. Give me a sec I have the feeling I did not work on that
<kees> smb: well, that upstream commit shows up in 2.6.28, so the rest of the triage on that CVE looks accurate.
<smb> kees, Something strange. I cannot find the update to that in the cve tracker
<smb> out branch
<kees> ?
<smb> Oh
<smb> I realize
<smb> Sorry
<smb> That one I did a few days ago
<smb> So its just not in the right sequence
<smb> kees, Its the one that is for some reason related to the 2008-... one
<smb> kees, That would also explain why I did things differently then. :-P
<kees> heh
<sconklin> I'm uploading a test build
 * tgardner lunches
<sconklin> yes
 * manjo out early
<simar> Please help me triaging the bug 566543. In this the synaptics module is not loaded after the kernel upgrade for ALPS touchpad. Wheather the support has finished or is it a new bug ???
<ubot2> Launchpad bug 566543 in snort (Ubuntu) "RFE: Support for variables like $eth0_ADDRESS in debconf script (affects: 1) (heat: 52)" [Undecided,New] https://launchpad.net/bugs/566543
<simar> Please help me triaging the bug 565543. In this the synaptics module is not loaded after the kernel upgrade for ALPS touchpad. Wheather the support has finished or is it a new bug ???
<ubot2> Launchpad bug 565543 in xserver-xorg-input-synaptics (Ubuntu) "horizontal scrollbar does not work in VAIO VPCEB15EL touchpad. (affects: 9) (heat: 54)" [Undecided,New] https://launchpad.net/bugs/565543
<simar> Sorry for the wrong bug no above...
<warewolf> argh
<warewolf> anyone here willing to help me figure out why my touchscreen won't work?
<jono> hey all
<jono> I need to get the digital in on a M-Audio Fast Track working and I saw http://alsa.opensrc.org/index.php/M-Audio_FastTrack_Pro
<warewolf> jk- was helping before, but no matter what I do the hid-mosart driver doesn't "attach" to the device.
<jono> I am not entirely sure what I need to do, can someone help?
<jono> it seems it is possible to turn it on if you pass args to the module
<jono> but I am not sure what to pass and whether the Lucid kernel includes the driver
#ubuntu-kernel 2010-07-03
<johanbr> jono, it is included... try "sudo modprobe snd-usb-audio vid=0x763 pid=0x2012 device_setup=0x9 index=5 enable=1"
<jono> johanbr, awesome, so what I am stuck on is what I pass it to turn on the 0x10 as documented in http://alsa.opensrc.org/index.php/M-Audio_FastTrack_Pro
<johanbr> you add up the values in hex
<johanbr> for instance, 0x01 + 0x08 + 0x10 = 0x19
<jono> ahhh
<jono> johanbr, when I modprobe it, I don't see any input channels for the device
<pgraner> johanbr: alsa mixer
<jono> in alsamixer it says the soundcard doesnt have any controls
<jono> when I switch t use the card
<johanbr> try without the "digital input" flag, maybe?
<jono> hmmm
<jono> this guide at http://www.joegiampaoli.com/blog/?p=462 recommended vid=0x763 pid=0x2012 device_setup=0x09 index=5 enable=1
<jono> and I still get no controls
<jono> just to be sure, this is what I am running:
<jono> jono@system76-pc:~$ sudo modprobe -r snd_usb_audio
<jono> jono@system76-pc:~$ sudo modprobe snd-usb-audio vid=0x763 pid=0x2012 device_setup=0x09 index=5 enable=1
<jono> johanbr, not sure if that helps
<johanbr> hmm... then I'm out of ideas, I'm afraid
<johanbr> except maybe trying a different kernel
<jono> are we sure this patch is in the kernel?
<johanbr> oh, I thought when you said "the driver" you meant snd-usb-audio
<johanbr> I didn't read properly... my apologies
<jono> no worries
<johanbr> whether that specific patch is in, I don't know
<jono> no I mean this specific patch, outlined on http://www.joegiampaoli.com/blog/?p=462
<jono> is there a way in which we can check?
<johanbr> look at http://kernel.ubuntu.com/git I guess
<johanbr> and see if the lucid kernel has the changes
<jono> pgraner, is this something you can help with?
<warewolf> can someone explain to me how to add the kernel-ppa mainline to apt so I can download a 2.6.34 source package and recompile it?
<johanbr> jono, it's not included
<jono> johanbr, ahhh ok
<jono> thanks
<johanbr> no problem
<jono> I guess I am SOL then
<jono> no worries, thanks!
<johanbr> you're welcome
<m4tr1x> apw, are you in?
<MTecknology> Any of you happen to know what kernel module dm_mod comes in?
<bullgard> What does "stripped" mean in '~$ file /usr/bin/make; /usr/bin/make: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped'?
<virtuald> strip (1)            - Discard symbols from object files.
<m4tr1x> some of you have Marvel 9123/9128 sata3 controller
<m4tr1x> on motherboard?
<bullgard4> virtuald: You missed the target: I did not ask for an object file.
<virtuald> bullgard4: exes still have symbols if not stripped
<lapion> hello
<lapion> I have been having problems with i855 hangcheck-freezes until I tried the maverick backported kernel: Linux axion-laptop 2.6.35-6-generic #9~lucid1-Ubuntu SMP Wed Jun 30 11:34:29 UTC 2010 i686 GNU/Linux
<lapion> only problem I have with that kernel is that is doesn't give oss-dsps
<lapion> *it
<lapion> how do I get oss-dsps with this kernel ?
<bullgard> virtuald: Thank you very much for your help.
<simar> what is the purpose of the driver package kbd, evdev, mousedev are these part of kernel or x??
<bullgard> http://lwn.net/Articles/21835/ speaks about "the top Makefile." What directory contains "the top Makefile"?
<jpds> bullgard: The source root?
 * warewolf cries
<warewolf> why can't I get hid-mosart working!?
<bullgard> How can I determine the source code file name of the kernel process 'pm'?
#ubuntu-kernel 2010-07-04
<hallyn> apw: https://bugzilla.kernel.org/show_bug.cgi?id=16111   is this something that'd be considered for lucid kernel?
<ubot2> bugzilla.kernel.org bug 16111 in network-wireless "hostap_pci: infinite registered netdevice wifi0" [Normal,Closed: code_fix]
<m4tr1x> apw, ping
<m4tr1x> any one with this problem?
<m4tr1x> pkg-deb: control directory has bad permissions 2755 (must be >=0755 and <=0775)
<m4tr1x> i try to make ubuntu-maverick kernel from source
<LLStarks> apw, are you there?
<diwic> Is there any reason linux-preempt is not built for i386?
<diwic> (lucid)
#ubuntu-kernel 2011-06-27
<rufian> my linux laptop sometimes crashes when I leave it idle. I get a blank screen and the fans working at full speed
<herton> lamont: about?
<lamont> yessir
<herton> lamont: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791512/comments/12
<ubot2> Ubuntu bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New]
<lamont> herton: will do, it may be later today before I can do that though
<herton> lamont: yep, no problem. Hope with this one we finally track it down.
<amorphous> Hello folks. Does anyone know how to disable hyper-threading for Intel CPU's? I tried 'noht' boot option and it didn't work.
<jpds> amorphous: Isn't that something done on a BIOS level?
<amorphous> Yes. But I don't know how to turn if off if there's no BIOS setting for that
<amorphous> some manufacturers use BIOS versions that are locked down. (very few options available)
<amorphous> jpds, so no other way to disable it if BIOS option is missing?
<jpds> amorphous: Not that I know of.
<hrw> apw: check http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking for omap4 code for 3.0 kernel
<jwi> narf - could someone with the required permissions reset the maverick status of bug 790754 to 'committed'? it's part of -30.55, not -30.54. sorry about that, manjo :/
<ubot2> Launchpad bug 790754 in linux "[NATTY] RICOH [1180:e823] unable to read MMC cards" [Undecided,Fix committed] https://launchpad.net/bugs/790754
#ubuntu-kernel 2011-06-28
<eruditehermit> hi
<eruditehermit> is there a ppa for natty upstream linux kernels?
<dtchen> eruditehermit: meaning kernels specifically with natty's kernel config, or...?
<eruditehermit> dtchen, like kernel 3.0 rc5 that works with stuff in natty like module-init-tools etc
<eruditehermit> dtchen, m-i-t and gcc might have changed in oneiric and so their kernels don't work with natty
<dtchen> eruditehermit: well, the mainline ones work fine in natty
<dtchen> (in fact, that's my biggest headache currently: the versioning of oneiric's kernels now don't allow some external modules to compile)
<eruditehermit> dtchen, they won't install because module-init-tools in natty is too old
<weidong> Hello, This is weidong zhou from Shanghai, China
<weidong> I am new to ubuntu netbook distribution
<weidong> and right now I am working on a ubuntu porting project for beaglebaord-xm ubuntu natty 11.04
<weidong> we use a 7" 800x480 resolution TFT LCD for beagle board in this project so we have to revise the linux kernel DSS drivers to support it
<weidong> my question is how can I get the specific linux kernel source for beagleboard natty 11.04?
<weidong> I can only find the pre-built images on your distribution site.
<weidong> but I can not find any links for source code
<weidong> Any one can help?
<Slayerman> Hello
<Slayerman> I would like to know if there is a fix/patch for lucid for this bug : XHCI (USB 3.0) kernel Module Prevents Suspend (Bug #522998) ? Thx
<ubot2> Launchpad bug 522998 in linux "XHCI (USB 3.0) kernel Module Prevents Suspend" [Medium,Fix released] https://launchpad.net/bugs/522998
<Slayerman> Yes, I already am on this page, but it's said "Won't Fix" for lucid! Is there a way to get usb3 suspend working on lucid ?
<tjaalton> Slayerman: comment #50 should explain why that is
<Slayerman> So I need to have kernel 2.6.37 in order to get usb3 suspend working ? but is there linux-image-2.6.37 for lucid ?
<tjaalton> Slayerman: there probably is the natty kernel for lucid, which is based on .38.y
<Slayerman> I just need to add ppa repo and then sudo apt-get install linux-headers-generic-lts-backport-natty linux-image-generic-lts-backport-natty ?
<tjaalton> yeah, looks like it's not in the lucid repo yet
<tjaalton> like the maverick kernel is
<Slayerman> wich repo I need to use ?
<Tommeh> Slayerman: is it not in the backports repo at all?
<Slayerman> I don't know, I found this howto get 2.6.37 on lucid : http://ubuntuguide.net/install-latest-kernel-2-6-37-2-6-38-in-ubuntu-10-04-from-ppa is it the right way to do it ?
<tjaalton> Slayerman: https://launchpad.net/~kernel-ppa/+archive/ppa?field.series_filter=lucid
<Slayerman> Thank you very much !
<ogasawara> bryceh: if you have a free moment, can you swing by the kernel room?
<RAOF> ogasawara: Bryce isn't actually here; would I do?
<ogasawara> RAOF: shoot, that's right.  Yes, if you're free that'd be great.
<ogasawara> RAOF: just want to quickly chat about graphics bug workflow with respect to the kernel
<RAOF> K.  I'll fire off a mesa build and wander down.
<ogasawara> RAOF: cool, thanks
<smoser> http://paste.ubuntu.com/634266/
<lamont> herton: did you see my update on bug 791512?
<ubot2> Launchpad bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New] https://launchpad.net/bugs/791512
<herton> lamont: yes, can you test the new kernel I posted there? tgardner suggested another change, so we can confirm it's not related to af_unix at all
<lamont> sure
<manjo> pgraner, if you are not terribly busy can I come bug you for 15 20 mts ? 
<cjwatson> jcrigby,lool: do you know what happened to most of the linux-linaro-{mx51,vexpress} udebs?  it looks like the kernel suddenly became a lot less modular or something - was that deliberate?  (I'm reviewing stuff in NEW)
<jcrigby> cjwatson, for the new cycle we radically reduced the number of enabled CONFIG_* to start with
<jcrigby> cjwatson, as time goes on we will see what stuff we really want to turn on
<cjwatson> I'm just wondering whether d-i will actually build with that few udebs
<cjwatson> vexpress in particular just has kernel-image ...
<cjwatson> http://paste.ubuntu.com/634416/
<jcrigby> cjwatson, good question, we have yet to actually build an image with these new stripped kernels
<cjwatson> compare with http://paste.ubuntu.com/634417/
<cjwatson> but if it's intentional, I can accept them as long as you guys commit to fixing the d-i build failures
<jcrigby> we will fix them
<jcrigby> we just wanted to start minimal and build up and begining of new cycle was good time to break things
<lool> cjwatson: In my memory, all udebs are marked as "?" (optional) in d-i; which most should be because in Ubuntu we often build things in the kernel which Debian would build as modules
<lool> cjwatson: In any case, I'm happy to look after d-i build failures
<cjwatson> jcrigby,lool: ok, thanks
<eruditehermit> hey, is there a ppa for mainline kernels on natty?
<eruditehermit> the oneiric kernels require an upgraded module-init-tools from the version in natty
#ubuntu-kernel 2011-06-29
<woken> w
<apw> ppisati: 40e10d19ac8c08d42167ddf8e5cd61289ffa15c4
<apw> ppisati: CVE-2010-3859
<ubot2> apw: Multiple integer signedness errors in the TIPC implementation in the Linux kernel before 2.6.36.2 allow local users to gain privileges via a crafted sendmsg call that triggers a heap-based buffer overflow, related to the tipc_msg_build function in net/tipc/msg.c and the verify_iovec function in net/core/iovec.c. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3859)
<Guest45327> hi, apt-get build-dep linux is not responding while trying to customize the Ubuntu kernel. Is there any alternate steps we can do in order to download the package? 
<Guest45327> Hi, could anyone help me to fix the issue of kernel 2.6.35? 
<stgraber> I seem to have some pretty funny ps output on my laptop lately, mostly when it comes to CPU usage. I was wondering if someone in here has a clue of what's happening.
<stgraber> Example:
<stgraber> root      1170 10916096  0.3 155000 29488 tty7 Ss+  Jun27 33927094:03 /usr/bin/X :0 -auth /var/run/lightdm/authority/0 -nolisten tcp vt7
<stgraber> where 10916096 is supposed to be the CPU usage
<splnet> Hi is there a list of patches somewhere that ubuntu uses against the vanilla kernel?
<apw> splnet: the patches we carry are listed in the ubuntu git repos
<splnet> apw: ok where is the git repo located?
<splnet> wait is this it: http://kernel.ubuntu.com/git?p=acelan/ubuntu-lucid.git;a=summary
<jk-> splnet: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git
<jk-> (for natty)
<jk-> ubuntu-lucid.git for lucid, etc
<splnet> jk-: ok got it. Now what subdir are the patches located?
<apw> https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2BAC8-FAQ.2BAC8-DevKernelSource.Where_can_I_find_the_Ubuntu_Kernel_source_code.3F
<splnet> I'm assuming /ubuntu?
<jk-> splnet: no, the patches are listed in the 'shortlog' section
<jk-> ie, they're commits in the git history
<splnet> jk- ok thx
<snadge> the kernel ppa is empty at the moment.. has the name changed to something else?
<snadge> i cant find the 2.6.39 kernel i need to install amd fusion drivers (latest catalyst)
<dtchen> snadge: more context, please?
<snadge> https://launchpad.net/~kernel-ppa/+archive/ppa
<snadge> is meant to have packages like "linux-headers-2.6.39-0" and others
<dtchen> snadge: sorry, I meant: do you need just headers or both headers and vmlinuz?
<snadge> but it appears to be empty
<snadge> headers and the image itself
<dtchen> snadge: moreover, for which Ubuntu release will this be?
<snadge> after installing that.. then i install catalyst.. natty
<dtchen> snadge: and, do you want a mainline/vanilla kernel?
<snadge> this is to get hardware video acceleration working on amd hardware.. via this guide: http://forum.xbmc.org/showthread.php?t=99154
<dtchen> snadge: (vice a kernel with Ubuntu "sauce")
<snadge> im not sure, its whatever was in that repository before it disappeared
<snadge> i followed these instructions on another pc and it worked.. but it appears the packages have only recently disappeared
<dtchen> snadge: you probably will find it @ kernel.ubuntu.com/~kernel-ppa/mainline
<snadge> hmm.. natty only appears to have up to rc4
<apw> snadge: the kernel-ppa contained early development release builds and were expired
<snadge> that leaves me wondering what i can install instead?
<hallyn> seem to be having trouble with /usr/share/systemtap/runtime/alloc.c in lucid.  When I try to use the euid() function it spews out errors...
<snadge> upgrade to oneiric?
<dtchen> snadge: eh? I see 2.6.39.2.
<snadge> for natty?
<dtchen> snadge: sure. the release suffix refers to the kernel config used in said release.
<snadge> ok i'll use 2.6.39 and hope that works
<snadge> im assuming thats equivalent to the one i was using that just expired?
<snadge> in the kernel ppa
<snadge> 2.6.39-0-generic #5~20110427
<jwi> no, it's not. 2.6.39-0.5~20110427 was based on 2.6.39-rc5
<snadge> oh well hopefully thats close enough
<bliss> wow, i had no idea this channel existed
#ubuntu-kernel 2011-06-30
<ppisati> apw: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=blob;f=net/unix/garbage.c;h=736e6f94c282d7b271b6cd17a7eb9cf7739fceb9;hb=refs/heads/fsl-imx51
<ppisati> apw: http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=9915672d41273f5b77f1b3c29b391ffb7732b84b
<ppisati> apw: CVE-2010-4160
<ubot2> ppisati: Multiple integer overflows in the (1) pppol2tp_sendmsg function in net/l2tp/l2tp_ppp.c, and the (2) l2tp_ip_sendmsg function in net/l2tp/l2tp_ip.c, in the PPPoL2TP and IPoL2TP implementations in the Linux kernel before 2.6.36.2 allow local users to cause a denial of service (heap memory corruption and panic) or possibly gain privileges via a crafted sendto call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4160)
<ppisati> apw: this is in our maverick/ti-omap4 tree: d428c4f08e29958d3d9dd3a2ea846ef5fce0366d
<ppisati> apw: and it's actually the cve fix: 9915672d41273f5b77f1b3c29b391ffb7732b84b
<bliss> i remember that bug
<ppisati> bliss: good memories are hard to fade out :)
<bliss> ha
<bliss> the fix was putting in upper bounds on maximum iovec sizes in the sendmsg syscall path
<bliss> so that's the fix that should be backported, not just the corrections to the l2tp code
<bliss> should prevent a bunch of other undiscovered vulns
<bliss> let me peek at those commits
<ppisati> bliss: i mispsated the CVE number, we are referring to 2010-4249 actually
<bliss> heh
<bliss> that's the unix socket DoS?
<bliss> that one looked like a pain to fix
<ppisati> bliss: unic gc
<ppisati> unix
 * ppisati today is unable to type anything correctly...
<bliss> heh, no worries
<alkisg> Hi, I have a kernel regression with a CDROM device (worked on lucid, doesn't work on maverick/natty). On the other hand, sandy bridge doesn't work on lucid, so I'm stuck with either the CDROM or the network adapter not working
<alkisg> How can I try the oneiric kernel to my lucid box?
<alkisg> I tried the latest from http://kernel.ubuntu.com/~kernel-ppa/mainline but module-init-tools version is incompatible
<alkisg> Can I install module-init-tools from oneiric to my lucid, or will that break something else?
<alkisg> Ah, no, dpkg version incompatible there
<herton> lamont: were you able to test this one?: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791512/comments/15
<ubot2> Ubuntu bug 791512 in linux-meta "tcp connections hang in forwarding machine" [Undecided,Invalid]
<alkisg> I tried with the latest oneiric live cd: Linux ubuntu 3.0-2-generic #3-Ubuntu SMP Fri Jun 24 19:09:43 UTC 2011 i686 i686 i386 GNU/Linux
<alkisg> The regression is still there, i.e. the CDROM drive that is recognized in Lucid, is no longer recognized in Maverick, Natty and Oneiric.
<alkisg> Where would I file a bug for that?
<alkisg> And, I'm not the one having the problem, I'm remote-supporting a fellow teacher, so I'd better gather any needed data now, I don't think he'll be able to do it himself later...
<sbte> hi all, what's the reason all packages were pulled from the kernel ppa on launchpad?
<sbte> is there a new suggested way for updating to 2.6.39+? (i'm on natty)
<slicks> Hey guys. Could Ypu help me? I don't know how to apply Ubuntu-specific patch on vanilla kernel. Downloaded linux-source-2.6.38.deb, installed it. In /usr/src/linux-source-2.6.38 I have folders: debian, debian.master and vanilla kernel archive: linux-source-2.6.38.tar.bz2. How should I proceed? Please help. I know only how to patch kernel with diff's :(
<slicks> Could You*
<apw> sbte: those were just testing kernels, preparitory to those being then in the real archive
<kees> if only I had used askubuntu.com sooner. http://askubuntu.com/questions/4653/how-do-i-get-rid-of-u3-system-on-my-usb-drive
<and> hi, I was trying to grab a package from the kernel team's PPA but looks like the page is currently empty (https://launchpad.net/~kernel-ppa/+archive/ppa), thus apt-get ignoring to update the repository. Any clue on how I can move forward? (I am on Lucid LTS)
<apw> and: those were just testing kernels, preparitory to those being then in the real archive
<apw> and: the lts has official packages that replace those
<and> apw, ok, but I am actually running on 2.6.32-32, is there a way to download/install 2.6.38 for example?
<and> should I grab them on http://kernel.ubuntu.com/~kernel-ppa/mainline/ and manually install?
<manjo> ogasawara, were you looking for me ? 
<ogasawara> manjo: no, cking was
<ogasawara> manjo: he's just left to go find you
<manjo> ogasawara, ok thanks 
<sbte> apw, sorry, xchat crashed. In reply to you: I know, but is there a different suggested way to update to a newer version of the kernel? I need it because 2.6.39+ has builtin wifi drivers for my card that don't cause kernel panics
<vish> Hi, I'm trying to bisect a kernel and while building, apart from the bisect, I change only the changelog with numbers ~bgo1234vish0 , ~bgo1234vish1  and so on.. but when I check using $uname -a  after booting into the newly build kernel, it only shows as ~bgo1234vish0 , the first build version number while the package number is the right one. 
<vish> is that OK, or am I not building the right version?
<vish> or how do I fix that numbering which displays in $uname -a ?
<bryceh> heya, I've been helping Stefan Stasik with a kernel bug on arrandale - lp #758785
<ubot2> Launchpad bug 758785 in xserver-xorg-video-intel "[arrandale] Display flickers or blank on login (x86_64)" [Undecided,Invalid] https://launchpad.net/bugs/758785
<bryceh> he's in the process of bisecting, and has a patch flagged that he's going to try and test (which I've linked on the bug)
<bryceh> I've tagged the bug kernel-handoff-graphics, but also pinging here since I think the bug may be close to solution and could probably benefit from a kernel engineer's attention
#ubuntu-kernel 2011-07-01
<cbx33> Hi all
<cbx33> can someone tell me when https://bugs.launchpad.net/ubuntu/+source/linux/+bug/765082 this fix will be released to the repos?
<ubot2> Ubuntu bug 765082 in linux "[ips-monitor] is in state 'D'" [Medium,In progress]
<ogasawara> _jmp_: https://launchpad.net/+apidoc/1.0.html
<_jmp_> ogasawara: \o/ thanks!
<ogasawara> cbx33: looks like 2.6.38-10.46 just went to natty-proposed, so it'll probably be a few days till it's promoted to natty-updates
<cbx33> ahhh ok
<cbx33> ogasawara, ahhh - I notice you were in the bug comments
<cbx33> so can i install it from natty-proposed?
<ogasawara> cbx33: indeed, if you wanted to install from natty-proposed it should pull in the updated kernel for you to run
<cbx33> ok
<cbx33> tank you ogasawara - will it affect my currently install kernel?
<cbx33> i obviously don't want to kill my machine
<cbx33> maybe I should just wait for a few days :)
<ogasawara> cbx33: no your existing kernel should remain installed and able for you to fall back to should you choose
<cbx33> ok
<cbx33> i am actually trying to "build my own + patch"
<cbx33> just to make sure I can :)
<cbx33> if I was compiling the kernel from the ubuntu source package - i copy the config from the /boot/ dir
<cbx33> do i need to rename the file at all?
<hrw> hi
<hrw> are suspend-to-disk/resume operations faults thing for you to check or should I just ignore and do not use s2disk on my laptop?
<hrw> cking: do you have few minutes to look at fail-to-resume-from-disk problem?
<cking> hrw, sure, I'm in the kernel team room at the moment
<hrw> ok, will be there in few then
<ronin___> hi please help me!
<ronin___> first step for be a member of ubuntu-kernel developer?
<anonymous_> does anyone know why the kernel-ppa is empty all of a sudden?
<chadhogg> I am trying to perform a kernel bisection and following http://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, but I do not have a debian/ directory with which to execute `fakeroot debian/rules binary-headers binary-generic`
<chadhogg> can I just run `make defconfig; make` and get a .deb file?
<anonymous_>  
<jakemp> Howdy, I am running 11.04 and I need the 3.0 kernel. Is there something that has already been packaged? I previously used one of the packaged 2.6.39 kernels, but all of the 3.0 kernel packages seem to be for Oneric
<vish> jakemp: you can use that, but why d'you "need" it? 
<jakemp> I'm using xorg-edgers, and it recently broke. The folks in #intel-gfx xsay the problem is fixed in 3.0, along with many other snb fixes.
<vish> k..
<Guest84971> is "https://launchpad.net/~kernel-ppa/+archive/ppa" broken? it appears to be empty.
<lmn123> There is a component which emits error like the following in dmesg. 
<lmn123> [609815.333802] submanager[6578]: segfault at 3d8b6504 ip 000000000824fca8 sp 00000000f5ac2a08 error 4 in submanager-edge[8048000+366000]
<lmn123> where/how should I get the info about those symbols / addresses ?
<bliss> if the application isn't PIE, then the IP should be static across invocations, so you can just attach to it (or start it fresh) with gdb and take a peek
<bliss> if it's PIE, it's really unhelpful :p
<bliss> by IP i mean EIP
<bliss> and by EIP, i mean .text
<lmn123> let me try gdb. Thanks bliss
#ubuntu-kernel 2011-07-02
<erle-> natty does not seem to have execshield in 32 bit edition
<erle-> does it have a different type of protection?
<erle-> (i have to get rid of it)
<ohsix> why do you have to get rid of it?
<erle-> security experiments
<ohsix> well you can change the page attributes if you are writing the software; or disable the flag you want in the elf header if you aren't
<erle-> this means not every program is protected now by default?
<ohsix> you can boot with noexec=off too
<erle-> ok, thanks
<erle-> its a VM
<erle-> i will do that
<ohsix> by default only specialized applications mark pages executable, for code they generate
<erle-> yes, but with third party software you never know, right?
<ohsix> well sort of, you can look at it's elf header, and you could always use strace to see if it's making mprotect calls
<erle-> the code i want to execute is placed in an array on stack, and it tells me "illegal instruction"
<ohsix> i think theres a place in /proc/$pid/ that has the page flags too; so you can just grep it
<erle-> but i am pretty sure that i have done it rightly
<erle-> jumping to a random line in code section works perfectly well
<ohsix> your stack will be marked noexec by default, you need to tell the linker not to, or edit the header with something
<erle-> i will disable noexec completely on that VM
<ohsix> most exploits love the ease at which code can be run from the stack :] that's why it's a mitigation
<erle-> yeah, i totally understand that
<erle-> i would not disable that on my sacred host system :)
#ubuntu-kernel 2011-07-03
<Laibsch> I managed to break my initramfs (https://answers.launchpad.net/ubuntu/+source/initramfs-tools/+question/154973) for an encrypted lvm.  On reboot, I'm now being dropped to a busybox shell every time.  Is there somebody around who can help me fix this?
<ohsix> update-initramfs -c -k all
<ohsix> (create, for all versions)
<Laibsch> I think I did this
<Laibsch> I'll retry
<Laibsch> thanks
<ohsix> if it still breaks after that a package may still be missing, and not one i'd know the name of :P
<ohsix> if all else fails you can read the scripts put into the initramfs then search the package repos
<sbte> hi, anyone here who can tell me the suggested way to install 2.6.39+ on natty?
<CarlFK> I want to test a patch on vanilla and ubuntu's - What's the easy way to get source, patch, build, install?
<CarlFK> guessing apt-get something...
<CarlFK> the patch is coming from a module dev, so I am guessing it will apply cleanly against vanilla 2.6.38
<CarlFK> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel  this looks like what I want
#ubuntu-kernel 2012-06-25
<mendalon> anybody know if the new (2.6.35+) rc-core-based kernel modules can by used to do ir blaster stuff? i want to transmit ir codes through a homebrew serial ir blaster without using lircd.
<ppisati> moin
<smb> ppisati, morning
<cking> ppisati, good morning!
<_jmp_> morning ppisati smb cking 
<apw> moin
<cking> more coffee...
<mendalon> anybody know if the new (2.6.35+) rc-core-based kernel modules can by used to do ir blaster stuff? i want to transmit ir codes through a homebrew serial ir blaster without using lircd.
 * ppisati is melting...
 * abogani is wondering about where exactly ppisati is melting ..
 * ppisati -> lunch
<arges> herton, hello
<herton> arges, hi
<arges> herton, about the systemtap bug. you mentioned using --only-keep-debug, would this be for reducing the size of the ddebs or for another purpose?
<herton> arges, just for reducing the size. I think we don't strip the debug .ko's at the moment, I did a quick look and didn't found anything
<arges> herton, ok maybe that's something to do for future work. i think its a good idea since the ddebs are very large.
<herton> arges, yes, I agree, just noticed we could be stripping and keeping only the debug symbols while looking at that change
<arges> ok
 * ogasawara back in 20
<smoser> ok everyone, its that time of the day again, where smoser exposes his grave ignorance!
<smoser> i'm thinking about bug 1016695
<ubot2> Launchpad bug 1016695 in cloud-init "add console=tty0 to cloud-image kernel boot parameters" [Wishlist,New] https://launchpad.net/bugs/1016695
<smoser> summary is that upstart messages (and stdout of 'console output' jobs it starts) go to the /dev/console device.
<smoser> and getting that console device set to the right place is kind of difficult if you're targetting a one-size-fits-all image (like the cloud-images).
<smoser> i can think of 2 possible ways of making this nicer.
<smoser> a.) some kernel "tee device" that would take writes to /dev/console and just write to multiple devices (ie, what 'tee file1 file2 file3' would do)
<smoser> b.) some way to more intelligently set where writes to /dev/console end up.
<smoser> smb, any thoughts?
<smb> smoser, Yes, I think that I need to think about it but feel like saying no-way to a) 
<smoser> yeah, kernel tee device probably isn't the right place, as we could probably get the same with a user-land fifo. it just takes another process.
<smb> smoser, The early boot messages probably not (until any user-space is up). But from looking last and some experiments, through you can have console= multiple times, the kernel has some "preferred" console concept and that likely is there for a reason.
<smoser> smb, right. multiple console= is acceptable and nice.
<smoser> and it generlly selects the last entry in the parameters to tie to /dev/console
<smoser> i'm not sure what happens if hte last entry is non-existant (ie, 'console=ttyS0' when there is no ttyS0. i think it probably does at least somethign sane).
<smoser> so basically... the kernel does a pretty good job, but after init is started its more complex.
<smoser> (this is where you probably say to me "not my problem"  :) )
<smb> Heh, probably. Well, I wonder what could be done in syslog config... I believe there is now a single line for it, but maybe that could also become multiple... Though I would want to play around before I boldly state such a thing
<smb> smoser, Hm, ok, so reading this through more carefully it sounds more like something that whatever carries on with console output from init/upstart would need the concept of multiple consoles. syslogd is no good there and the kernel handles it that way (just /dev/console is always just one console)
<smoser> smb, right. bsaically, init (upstart) would have to hook the processes' stdout, stderr to something that it  (or some other "tee like thing") then wrote to multiple places.
<smb> smoser, Otherwise the only other option would be to make cloud-init test various options and then modify the command line for the next boot. If having the first boot not show then is acceptable
<smoser> next boot is useless.
<smoser> but yeah, that is easy[er]
<cking> hrm, libreoffice spreadsheet kinda chokes on > 90K samples in a graph, need more memory :-)
<rtg> cking, you should use something more powerful then an Atom.
<smb> Not sure whether that part of upstart could be more knowledgable than to just go for console. But then there will always be cases (ok maybe not with images on the cloud) where ttyS0 is present but unused...
<cking> rtg, I'm using an i5 @ 2.6GHz with 6 GB
<smoser> smb, well, present but unused is fine.
<rtg> cking, that seems like it ought to be enough
<cking> not for the graphs I'm crunching
<smoser> ie, i dont really care about writing to additional places. just, ideally, want to make sure that if someone goes looking for messages, they see them.
<smb> smoser, I guess not when you have a Xen guest with a serial defined... You still would want to use hvc0
<smoser> yeah, its difficult.
<smoser> :)
<smoser> i think that the best thing to do would be to write a bunch of places, basically anything likely to be watched that is available.
<smoser> and to have init mimic that basic behavior
<smb> smoser, Yes, true. Which at the current state of things really would make me say not so much my problem because the kernel messages do go multiple ways. I know that is evasive... ;)
<smoser> smb, well, the only issue ihave with the kernel behavior is that i have to load up the command line manually with a bunch of "likely" places.
 * cking spots a trend which means he has to re-do a bunch of tests, *sigh*
<smoser> and i'm not aware of the behavior if the last one in the list happens to be non-existant.
<smoser> ie: 'console=tty0 console=ttyS0 console=hvc0' without a hvc0
<smb> smoser, probably does the right thing (though it should be tested). One drawback is that the more you have there more load/delay there may be. But then you cannot make this work for everyone in all cases. 
<smb> smoser, Even assuming this can be changed at some point from user-space, it is probably only the guest configuration on the host that would be able to say what the console is and I am not sure all possible virtualisation types would provide some way to find out...
<smoser> smb, yeha. i didn't htink there was any clear simple way to get this right.
<smoser> but, thanks for your input.
<apw> rtg, any idea how to list subsribed multicast groups ?
<rtg> apw, not from memory
<rtg> apw, would there be anything in dmesg ?
 * apw finds it by luck
<apw> rtg, ip maddr does it
<rtg> apw, makes sense
<ev> apw: hi. Did you happen to see my email about kernel oopses a little while back?
<apw> ev, do we normally get cores from crashes, that'd not be a common config
<apw> and something we'd not want to be sending anywhere somewhere i suspect
<ev> ah, interesting. What are you looking for, and what would be a reasonable algorithm for the signature of it?
<apw> there is a common oops format in dmesg/messages 
<apw> we are sending those in already though right, in the apport enabled world
<ev> oh I'm misreading my own email
<ev> right
<ev> indeed, we are sending oopses through
<ev> but we don't have a signature for them
<apw> i'd assume signatures could be done the way you do them for any other C style applkication
<apw> the only special is there are ? entries which generally can be ignored
<ev> thus my proposal of ext4_get_acl+0x80/0x210:d_splice_alias+0x40/0x50:ext4_check_acl+0x4a/0x90:acl_permission_check+0x97/0xa0:generic_permission+0x25/0xc0:inode_permission+0x99/0xd0 for https://launchpadlibrarian.net/79771442/OopsText.txt
<ev> right
<apw> you might also want to include the type of the blammo
<apw> so thats a 'kernel paging request'
<ev> apw: okay, will do. And you're happy with the rest of that as a signature?
<ev> with the type included, that is
<apw> ev, yeah i think until we try it we're not going to see what triggers overly commonisation or over differntiation
<ev> fair point
<apw> ev, when you do other C things do you include the +xx parts ?
<ev> apw: until we have a fully retraced stacktrace, yes: http://people.canonical.com/~ubuntu-archive/apport-duplicates/address/_usr_bin_Thunar_6
 * ppisati -> gym
<ev> apw: out of curiosity, why don't we want to capture VmCore files?
<apw> its not a simple thing to do, and not enabled by default
<apw> as your machine has to crash and reboot to do it, we normally try and hang one and keep going, for least supprise
<ev> ah, understood
<apw> and the chances of the vmcore not having something sensitive in it is very small
<ev> apw: thanks for all the advice
<apw> ev thanks for looking at it
<cking> apw, I've now collected and graphed way too much data for the low-latency kernel and I'll try and get it written up tomorrow. I find the data still rather perplexing
<apw> cking, that sounds 'bad'
<cking> the results kind of match what we expect in some cases, but not in others, which I find perplexing
 * ppisati -> out for dinner
<laserbled> Hi, how do i disable a option in config file for compiling...is it a 'n' or a '0" or a m ?, also can someone help me with fixing up a config file for minimum size vanilla version
<apw> laserbled, its # CONFIG_FOO is not set
<laserbled> apw, great, do I have to comment it out using # too ?
<laserbled> ok, I am assuming that doesn't resolve as a comment then
<apw> # CONFIG_FOO is not set 
<apw> is a specific syntax meaning =n
<laserbled> apw,  yes, got it. can you tell me what does a m stand for ? 
<apw> modular
<laserbled> apw, great. thanks a lot for the info.
<apw> np
 * rtg -> EOD
<skaet> ogasawara, do you have the bug number for the arm fix we may try to include?
<ppisati> skaet: didn't fill them yet
<ppisati> skaet: i'll do it now
<skaet> thanks ppisati :)
<ppisati> skaet: bug 1017717
<ubot2> Launchpad bug 1017717 in linux "Severe filesystem corruption on beagle board" [Undecided,New] https://launchpad.net/bugs/1017717
<ppisati> skaet: bug 1017718
<ubot2> Launchpad bug 1017718 in linux "Usb hub not working on beagle board" [Undecided,New] https://launchpad.net/bugs/1017718
<ppisati> ogasawara: ^^
<skaet> thanks ppisati.   What should the priorities be for these?
<ppisati> first one is already fixed (i've the patch here) for the second one i'm still investigating one thing (and i hope to clear it ASAP...)
 * skaet noticing Undecided, New and figures they're probably In Progress , High
<ppisati> ah right, forgot the status
<ppisati> right
<ppisati> in progress, high is good
<skaet> ppisati, have noted it on the bugs.
#ubuntu-kernel 2012-06-26
<smb> Morning
<brendand> cking - hi
<cking> brendand, hiya
<brendand> cking - it seems (without my knowledge) we've recently started using fwts for suspend testing. now the problem is we're using --s3-device-check and it's generating failures
<brendand> http://paste.ubuntu.com/1060316/
<brendand> cking, i'm going to assume those errors aren't that severe - in that they won't stop anything from working
<cking> brendand, first rule of computing, assume nothing
<cking> let me look at those errors
<cking> if we just run a test, and it produces and error and we just assume its OK then why do we bother testing? ;-)
<cking> s/and error/an error/
<cking> brendand, file a bug as it looks like a bug with the way the APIC is being handled, which could be a problem
<brendand> https://bugs.launchpad.net/ubuntu/+bug/1017841
<ubot2> Ubuntu bug 1017841 in ubuntu "[Thinkpad Edge 15] register is already in use for vector 0xf9 on another cpu" [Undecided,New]
<brendand> cking, any idea if it's something we have even the smallest chance of getting an imminent fix for? or is it a fw issue and we'll have to live with it for now
<brendand> ?
<cking> brendand, from a cursory view of the kernel source I believe it's a firmware issue
<brendand> cking, okay thanks. that affects how we'll have to deal with this issue, so good to know
<brendand> cking, the problem we have is that other certification tests depend on the suspend test to run and pass, so unless we're going to consider this issue has enough to fail certification, it's sort of scuppering our testing
<brendand> cking, we may just have to change the test definition to something less strict
<brendand> cking, any idea how to ignore those kinds of failures?
<cking> how about "fwts --test-and-pretend-it-is-okay"?
<brendand> cking, i understand and at a fundamental level agree with what you're saying
<cking> brendand, as it is, the kernel is complaining that the firmware is broken, so it is a fault.  Do you want a S3 test pass to me "it suspends and resumes and we don't care about kernel error messages?"
<cking> s/me/with/
<cking> bah, what's wrong with my brain today
<brendand> cking, well we don't want to be ignoring potentially serious issues, but at the same time we don't want to be failing systems left and right because of some shoddy bios engineering
<brendand> cking, we have certain things that need to work and if they do then it's certified
<brendand> cking, unless that changes then we can only be so strict
<cking> it depends on one's definition "of need to work"
<brendand> cking, it certainly does! tell me about it
<cking> for fwts, it is to catch all stupid errors, and pick up any errors that the kernel warns about.
<cking> ..so it is geared up for the enablement engineers to be really pedantic
<brendand> that's good
<brendand> we're a lot more liberal over here in certification land
<brendand> so to answer your earlier question, if the system resumes and all the functionality which is required for certification is working then yes, we should consider the suspend was succesful
<cking> even though the kernel was screaming about some failed APIC config?
<cking> gawd help us
 * apw blinks
<brendand> just for kicks, what's a potential manifestation of this problem - user side
<brendand> ?
<cking> brendand, no idea, I've not got enough data in the bug report yet, and this needs some effort to look at
<ppisati> moin
<brendand> cking, ok. i hope you understand that i'm not in disagreement with you, but the definition of certification is not made at my level so there are other people to convince
<cking> brendand, sure, I understand, somebody needs to make a value-judgement on this
<brendand> information such as 'these errors could cause X' is helpful
<cking> sure, but for this kernel message, I've not seen it before, so fwts can't advise automatically
<cking> hence it flagged it up as something that should grab somebody's attention to look into
<apw> henrix, you dissappeared
<brendand> cking, just heads up that i don't seem to be able to hit launchpad from the system. i'll get you the logs some way or another asap
<cking> ack
<brendand> cking, oh and since the bug is package-less and you're asking for apport-collect, is that going to work? or would you like me to put it to the linux package?
<cking> true, can you attach the kernel log, and output from "sudo acpidump" to the bug report?
<brendand> cking, that'll be easier
<brendand> cking, i'm on it
<xnox> I am reading KernelUpdates page and I didn't understand this: $DEITY 
<xnox> what does $DEITY mean?
<apw> xnox, your god of choice
<xnox> apw: ah, marvin from hitchhicker's guide to galaxy. Ok.
<apw> there you go :)
<xnox> Any chance of me intruding kernel-ppa with hardware enablement SRUs? =)
<xnox> In particular mdadm with support for DDF and Intel Matrix Raid?
 * xnox is going via SRU currently, as it is 'user-space'. But I am pondering, if kernel-ppa is a better match
<xnox> and updates to the e2fsprogs
 * smb would not think this to be appropriate for the kernel-ppa. 
<apw> xnox, the kernel-ppa doesn't avoid the SRU process, I think the document you are reading is the one which defines the pre-approved variance of the common SRU policy for the kernel
<apw> but that was taken to the DMB for those specific packages
<xnox> hmmm
<smb> And frankly I was not really happy with how the mdadm support worked with the versions I saw... Usually the raid seems to come up read-only.. :/
<xnox> I am working on ReliableRaid spec and bugs
<xnox> I want to push these bugs: https://bugs.launchpad.net/ubuntu/precise/+source/mdadm
<smb> xnox, Isn't that targeted for Quantal?
<xnox> as an SRU
<xnox> smb: not if update-initramfs segfaults on precise & udev rules lack picking up Intel Matrix Raid and DDF formats and other things
<xnox> look at the bug list: https://bugs.launchpad.net/ubuntu/precise/+source/mdadm
<xnox> Me and slangasek kind of agreed that critical stuff should be SRUed for 12.04.1
<smb> xnox, Yes, that is sort of why we still cling to dmraid
<xnox> and we shouldn't.....
<xnox> Intel itself recommends to use mdadm with their raid format......
<smb> Agreed if we can really replace it
<xnox> well, it's too early to replace it =) since I didn't fix it all yet ;-)
<xnox> So shall I upload into precise-proposed and see what the SRU team says, or will you, kernel team, are interested in taking this update for testing in the kernel-ppa
<smb> Yes, and also I was never sure whether IMSM and DDF are all that is out... compared to formats that dmraid would probably know
 * xnox doesn't know what type of users you have.
<smb> xnox, Yes, for SRU approach the ppa would not help you any way
<xnox> ok.
<xnox> To be honest I haven't looked at the state of dmraid yet.
<xnox> I am expecting a small can of worms =)
<smb> Heh, well I am certainly not doing exhaustive tests there, but at least it does allow me to access an MSM raid5
<smb> But since the user-space relies on a not-really-supported anymore kernel module it is the right path to go forward with mdadm
<xnox> Hmm... the new mdadm udev rule with try to assemble Intel Matrix Raids......
<xnox> Which is part of this upcomming SRU.....
<smb> So I may be early to notice when having -proposed enabled
<smb> (which I should do)
<smb> (if I have not already)
<smb> xnox, Btw, last time I tried with Q there was an issue of the installer accessing the md raid and blowing up because at that time the array was read-only and the kernel did not like that
<smb> I wanted to get back at it but got disctracted then
<xnox> hmmm... I didn't hit that in my testing
<xnox> mdadm is not in proposed yet. I'm just hovering over debsign && dput right now
<xnox> still need to do some more testing first.
<xnox> oh, no I don't. I did that yesterday
<smb> xnox, sure, just for reference bug 1008479
<ubot2> Launchpad bug 1008479 in linux "kernel BUG at /build/buildd/linux-3.4.0/drivers/md/md.c:6958" [Medium,Triaged] https://launchpad.net/bugs/1008479
<smb> And for me there was also the problem that mdadm seemed to have set up the raid even before the installer asked about it. But I need to go back there with a2
<xnox> smb: partman-auto-lvm (43) unstable; urgency=low
<xnox>    [ dann frazier ]
<xnox>    * Call update-dev --settle between creating lvs and accessing them
<xnox> .... workaround or fix?
<xnox> this is merged and will be part of alpha2. So if you could test there it would be wonderful
<xnox> also the new mdadm is in alpha2 as well
<xnox> which should work with IMSM, which I do not have access to
<xnox> smb: well not the installer setup raid, but udev rules kicked in is my guess
<smb> xnox, Hm, potentially not related. I must admin I am not really understanding why the raid is ro at that moment. It seems in a odd way related to be brought up in initrd. When I (hopefully in the same way) do it later it ends up in auto-ro which autimatically because rw later...
<smb> *admit
<smb> Oh bugger, my fingers do not seem to type what I think...
<smb> *automatically become rw later
<smb> xnox, But any way, it is likely the udev rules, just somewhat in an unexpected way. Probably needs some thought in the installer too
<smb> Since back then this cause the question to be futile. Even when I said no, mdadm had set up the raid and caused the bug
<smb> I try to keep that tracked as bug 1008423
<ubot2> Launchpad bug 1008423 in debian-installer "Activate Serial ATA RAID devices dialog likely not working as expected" [Undecided,New] https://launchpad.net/bugs/1008423
<xnox> smb: well I can't say anything about bug 1008423
<ubot2> Launchpad bug 1008423 in debian-installer "Activate Serial ATA RAID devices dialog likely not working as expected" [Undecided,New] https://launchpad.net/bugs/1008423
<xnox> let me check the upload history
<smb> xnox, Yeah, I did not expect you to. Just as a pointer, while you are working on that topic... And maybe something to have in mind when doing tests...
<xnox> smb: well the new mdadm with ISMS udev rules was uploaded on 2012-06-22 21:03:50 BST, but you filed the bug before that.
<smb> It could be something that happened before since I usually updated the machine and did not reinstall. And there also was the "bug" of the dmraid kernel module not being build
<xnox> is there any way I can get remote-hands access to ISMS to do some installer testing / interaction? 
<xnox> or are you going to be testing alpha2 on the ISMS
 * xnox ISMS or IMSM well I bet you understood ;-)
<smb> xnox, Sure. :) Yes, I plan to get back to that testing with a2. Fingers crossed and knocking on head
<xnox> good luck & don't forget your towel ;-)
<apw> (arch armel & value y) | value m
<apw> (arch armel & / value y) | value m
<apw> (arch armel & cur & value y) | value m
<smb> xnox, :) One always needs to know where that is...
<apw> (arch armel & ^ & value y)
<apw> (arch armel ^ value y)
<apw> (arch armel &^ value y)
<apw> (arch armel / value y)
<apw> (arch armel &/ value y)
 * xnox please stop serving alphabet soup to apw. he's had enough!
<apw> heh
<dhana013> Hi
<dhana013> Hi Guys I accidentally deleted my .config for my kernel configuration on Linux, and seem to remember there was a way to retrieve the kernel configuration via the proc filesystem somehow.
<dhana013> In debian filesystem /proc/.config 
<dhana013> i can't see the .config in /proc directory please guide me 
<ppisati> brb
<henrix> dhana013: if you're kernel has been configured to include it, it should be /proc/config.gz
<henrix> dhana013: there's also a script that allows to extract that info from a kernel image
<dhana013> henrix, I am using ubuntu 10.04 not seen /proc/config.gz file 
<henrix> dhana013: are you running a customised kernel? or the 10.04 kernel?
<dhana013> henrix, please tell the script name, give script download location
<dhana013> henrix, no
<ogra_> dhana013, it is in /boot by default 
<ogra_> at least if you use an ubuntu packaged kernel 
<dhana013> ogra_,  soory I accidentally deleted
<dhana013> ogra_, /boot/config file
<henrix> dhana013: ok, so probably the easiest way is to just re-install the kernel pkg
<ogra_> you could just "apt-get install --reinstall  linux-image-$(uname -r)" ... and it will magically come back
<dhana013> thanks henrix ogra_ i try
<dhana013> henrix, any script available find extract info current kernel
<henrix> dhana013: yes, it's available on the kernel sources, in the scripts directory
<henrix> dhana013: but to use it your kernel has to be built with a specific config option (can't remember the option atm)
<dhana013> henrix, thanks I see the script directory lot of script there, I find out
<brendand> cking, this issue is interesting because it's happening across lots of different BIOSes : http://paste.ubuntu.com/1060586/
<xnox> random question: why does lsmod | grep ipv6 doesn't output anything?
<xnox> or is the ipv6 module 'built-in'
<henrix> xnox: if you grep the config file, you get CONFIG_IPV6=y
<henrix> xnox: you're grep will probably return some output if you have NF modules loaded
<xnox> henrix: ok, just hunting down an ipv6 bug in one package's testsuite
<dhana013> Guys any documentation available understand linux kernel configuration
<apw> dhana013, henrix, there is an option to burn the config into the kernel, but it just wastes memory given we can just ship it in /boot, as ogra_ says you can just reinstall your kernel package from /var/apt/cache and get it back
<dhana013> apw, I want to do custom kernel configuration any documentation available understand linux kernel configuration
<ogra_> apw, heh, your memory arg is funny .... the platforms with the lowes memory have the feature on in ubuntu (arm)
<apw> dhana013, not really, every option is documented in the kernel itself, in the help options
<apw> ogra_, you do?  why would you do that, thats mad
<ogra_> userfirendlyness ... many complained in the arm world that their scripts dont work without it etc 
<apw> they are so full of poo
<ogra_> though thats quite a while ago
<apw> ogra_, what is the option even called
<ogra_> we could try again to switch it off 
<ogra_> ugh, dont remember
 * ogra_ checks
 * apw either sigh
<apw> debian.master/config/config.common.ubuntu:# CONFIG_IKCONFIG is not set
<apw> ogra_, i think its not on any more
<apw> CONFIGS/armhf-config.flavour.omap4:CONFIG_IKCONFIG=y
<apw> CONFIGS/armhf-config.flavour.omap4:CONFIG_IKCONFIG_PROC=y
<apw> oh it is on omap4 ... sigh
<apw> but not on omap3
<ogra_> ogra@panda:~$ ls /proc/config.gz 
<ogra_> /proc/config.gz
<ppisati> it's been like this since M/omap4
<ogra_> even before i think
<ppisati> and no one complained
<ogra_> no, they complained that it wasnt there before :)
<apw> thats cause we have never done a proper config review for omap4 ... obviously
<ogra_> but nowadays they can take linaro kernels if they want such extra options
<apw> n
<apw> Inconsistent policy=n not required as configs in /boot
<ogra_> so i think we can disable it for quantal
<apw> indeed now i have omap4 in the config review matrix, it even throws and error :)
<ogra_> throw it back :P
 * ppisati is doing the config review for omap4, but didn't met that option yet...
<apw> ppisati, yep its a year of your life and no mistake
 * ppisati preps another coffee...
<ppisati> ogra_: btw, just sent last round of patches for omap3, after these kernel should be back in shape
<ogra_> yay
<ogra_> will there be another upload before the milestone ?
<apw> i beleieve we are holding waiting for those patches indeed
<ogra_> awesome !
<apw> they'd better work tho :)
<apw> ppisati, do you really want your gmail addy in that commit ?
<ppisati> apw: wait
<ppisati> apw: i'm subscribed to lkml&c with my personal address
<rtg> apw, its just his Reported-by: address 
<apw> ppisati, yep, just wondering if you wanted that in the history as it is right now
<apw> rtg, indeed, he might not want it there, just checking
<rtg> I can always fix it up and repush
<apw> yep, and it was just to get him to decide that i brought it up :)
<ppisati> no problem
<apw> ogasawara, as we have scheduled a config review post v3.5-rc1 at sprint i've closed that 'schedule config review' WI
<ogasawara> apw: you read my mind :)  was on my list to tick off today.
<ogasawara> apw: am just getting one last Alpha2 fix in for bug 1017879, and will pull in ppisati's patches then quick build/boot test and upload
<ubot2> Launchpad bug 1017879 in debian-installer "External USB keyboard stops working when d-i starts" [Critical,Confirmed] https://launchpad.net/bugs/1017879
<rtg> ogasawara, um, I think I already pushed them
<rtg> runnign armhf build test right now
<cking> yay, ISO testing time again
<ogasawara> rtg: awesome, thanks
<ogasawara> rtg: did that schroot issue on gomeisa ever get sorted
<rtg> ogasawara, um, which one? my memory is only 2 days long.
<ogasawara> rtg:  where builds would fail with some permission denied error
<rtg> ogasawara, uh, maybe. I think I reinstalled since then.
<rtg> ogasawara, I'm sure you'll tell me if its still an issue :)
<ogasawara> rtg: I seem to have just hit it again
<rtg> ogasawara, drat. lemme check
<ogasawara> rtg: full build log in my home dir under quantal-i386/build.log
<rtg> ogasawara, hmm, I wonder if messing about with sbuild might have done it. apw - are you using sbuild on gomeisa ?
<apw> rtg, at this instant no
<rtg> apw, ok, I'm gonna scrub sbuild and the chroots and start over
<apw> rtg works for me
<apw> we had that bad sbuild version installed for a while didn't we
<rtg> apw, thats good :) 'cause its mostly gone....
<rtg> apw, yeah, I removed sbuild and am rebuilding the quantal chroots
<smb> sforshee, Hm, could it be that we caused some weird result in our competing updates to the blueprints? This looks a bit weird...
<sforshee> smb, that one's been weird. I think my last update only changed the part that I wanted it to though...
<smb> sforshee, I believe the overall sequence caused me to have two items now with the same name... /me wonders whether rtg suffered from that multiple times...
 * rtg suffers from an excessive number of duplicates
<sforshee> smb, when I tried to update it a couple of weeks ago it kept adding new items for rtg
<smb> Yeah, 10 reviews without any more detail seems a lot...
<sforshee> it seems to be behaving a bit better now
<smb> I would try to reduce it to 1 if nobody else is on it right now...
<sforshee> go for it
 * smb finds the lack of locking a bit tedious
<sforshee> you find locking-via-irc to be less than ideal?
<smb> ok... hope its fixed now
<smb> sforshee, its racy ... :-P
<smb> rtg, You should have put "get rid of duplicate work-items" into your goals... ;)
<rtg> smb, I could have looked like a hero for doing all that work :)
<smb> exactly... hehe...
<apw> ogasawara, did i see you upload into -proposed there ?
<ogasawara> apw: yep
<ogasawara> apw: as instructed by the release team
 * rtg uploads Quantal LTS....
<apw> ogasawara, we're not frozen yet are we ?
<ogasawara> apw: I thought we were as of 2100 UTC yesterday?
<smb> Quantal LTS sounds so wrong...
<apw> ogasawara, oh have they moved it out ... sigh
<bjf> smb, but not scary
<ogasawara> apw: I'm not sure if that's official for all milestones now, but was the time I was told yesterday when I asked about a pending late upload
<smb> bjf, Not? Oh, well just another release to support for 5 years... ;-P
<apw> ogasawara, bah ... i'll hold lowlatency for after then
<rtg> apw: did it FTBS ?
<rtg> oh, the rebase. never mind.
<apw> rtg, nope, i was going to rebase it to -2.2 to match mainline
<rtg> apw: I don't think low-latency has any impact on the release team does it ?
<apw> rtg its on an official release CD so i assume we'll be spinning them for A2
 * rtg wonders how ubuntu-studio survives without a community
 * ogasawara back in 20
<brendand> cking, so it seems like even if we don't use --s3-device-check those errors are still registered and cause a failure...
<cking> brendand, yep, --s3-device-check just checks if a bunch of devices disappear between S3 iterations
<brendand> cking - hmm, certainly if devices are disappearing we'd want to know 
<apw> sounds like a real problem then
<cking> otherwise S3 testing would be pointless ;-)
<brendand> cking, would device check failures be considered critical?
<apw> if bits of your machine were there before s/r and not after, i think you'd think it was important, no ?
<cking> brendand, like video not working, or audio or webcams disappearing, yes
<cking> fwts takes a pragmatic approach - if it fails the test, it marks it as failed
<brendand> cking, if the system failed to suspend that would be marked as critical too, right?
<cking> it's definitely a fail isn't it?
<apw> a non-working s/r really aught to fail a s/r test
<brendand> cking, you said assume nothing :)
 * cking punches himself
<cking> brendand, https://wiki.ubuntu.com/Kernel/Reference/fwts/s3
<brendand> cking, i don't see anything about the severity levels of the different issues
<brendand> cking, anything available on that? or just read the source?
<cking> I didn't document the 983 different failure messages in the wiki, so it is an omission
 * cking looks it up
<brendand> cking, understand that i'm trying to establish if we can use 'no critical errors' as a criteria for passing the test for the purposes of certification
<cking> brendand, the severity is more tuned to the engineers in HWE
<cking> ..and it may change 
<brendand> cking, ok. our only other alternative then is to ignore them. we're going to go along with 'no critical errors' for now, it's better than nothing
<cking> so, critical means "holy smokes it's going to catch fire or possibly will fry your CPU", which may not be the case for S3 failure
<brendand> cking, right i see
<brendand> cking, so if it tries to suspend but can't that might just be high?
<cking> it probably should be
<brendand> cking, so it sounds like if you're going to consider both not suspending in the first place and kernel error messages (which we don't know exactly what they mean) as the same severity, then fwts is not matching with our definition of S3 testing
<cking> no, cert is not matching the HWE definition of a working S3
<brendand> cking, indeed it isn't
<cking> brendand, what is the cert criteria of a S3 pass?
<brendand> cking - if the system suspends and resumes then the actual suspend/resume functionality is considered passed. but we do also check all of the functions seperately again after S3, e.g. video, wifi, media cards, usb, bluetooth etc
<cking> but you don't scan the kernel log to see if it is wetting itself over broken drivers etc?
<cking> or randomly oopsing?
<cking> or if devices come back misconfigured?
<cking> or if resume took too long?
<cking> or got stuck on AMD C1E idle state?
<brendand> no, we weren't
<cking> well, we either test thoroughly or we are just kidding ourselves that our process is good enough
<brendand> cking, i know that. but what i'm getting here is that you may only consider issues such as those to be high severity, along with the issue described in the bug i raised - which as far as we know does not actually impact on anything
<brendand> of course it could be we can link it to some functional failure in which case i stand corrected
<brendand> we need to be able to say okay, high severity failure == cert blocker
<brendand> for sure
<brendand> i think part of the problem here is that we have shifted the scope of certification which we don't normally do
<brendand> so if we could honestly go back and say all systems which fail the s3 test with it's new criteria don't pass cert then we'd do that
<cking> yep
<ricotz> hello, did someone here by mistake uploaded  "linux-lts-quantal - 3.5.0-2.2~precise1" to ppa:xorg-edgers/ppa?
<bjf> ricotz, it was intentional, that ppa is being used for "LTS backport" testing work
<rtg> ricotz, no accident
<tjaalton> wrong ppa, this is edgers :)
<ricotz> bjf, don't mistake ppa:~ubuntu-x-swat/q-lts-backport with ppa:xorg-edgers/ppa
<tjaalton> but maybe someone copied it there by hand
<rtg> tjaalton, it was likely apw's automagic...
<tjaalton> ok it was manually copied
<rtg> ogasawara, take another run at gomeisa
<ogasawara> rtg: ack
<cking> sforshee, thee machine with the dodgy battery info was a Toshiba Portege M200, so it is so old I think it's beyond fixing
<sforshee> cking, the machine I just got is also a Portege, so it's may be the same ODM. Let me check it ...
<cking> apparently it "works with windows" 
<sforshee> cking, battery state updates okay on this machine and looks reasonable enough
<arges> cking, http://apps.linuxaudio.org/wiki/jack_latency_tests   fyi
<cking> arges, I was looking at: http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2latency_8c-example.html
<arges> ah nice
<cking> but got stuck because my laptop doesn't have working audio input
 * cking hunts for a different machine
<Sarvatt> it looks like linux-image-generic-lts-quantal is missing a depends on linux-image-extra-${kernel-abi-version}-generic
<ricotz> Sarvatt, the backport kernel package doesnt create a extra package
<rtg> Sarvatt, yeah, it should all be in one blob
<Sarvatt> ah right indeed, sorry for the noise
<rtg> Sarvatt, gonna upload the meta package in a couple mins
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 3rd, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> rtg not my magic, not that one
<smb> jsalisbury, arges So it seems that bug 1013199 is actually not hw related. I just think that the way they define the bridge, eth0 is left as down and so the bridge is down as no ports are up. I added my proposal for setup to the bug
<ubot2> Launchpad bug 1013199 in linux "be2net driver used by HP BL460c bridge networking not working" [High,Confirmed] https://launchpad.net/bugs/1013199
<jsalisbury> smb, great.  thanks for the feedback!
 * cking saunters off
 * smb is blinded by the sun sideways... (may as fell wander off to enjoy it)
 * ogasawara lunch
<arges> smb, thanks
<vanhoof> ogasawara: hi
<ogasawara> vanhoof: heya
<vanhoof> ogasawara: time to chat?
<ogasawara> vanhoof: for you, of course
<vanhoof> ogasawara: :D
 * rtg -> EOD
<arges> ogasawara, just got my kit! : )
<ogasawara> arges: sweet
#ubuntu-kernel 2012-06-27
<diwic> apw, ping
 * apw yawns
<apw> diwic, hi
<diwic> apw, you're the maintainer of checkpatch, aren't you?
<diwic> or at least a frequent contributor
<apw> diwic, indeed
<diwic> apw, I'm getting what I think is a false positive
<apw> diwic, you won't be the first :)
<diwic> apw, could I send the patch to you to double check that I'm not completely stupid?
<apw> of course
<diwic> apw, sent
<brendand> cking - hi
<cking> brendand, hiya
<brendand> cking, i just have a new data point for you in the fwts/suspend saga. you know the device-check can be foiled by xinput reordering the list of devices?
<brendand> cking, everything's still there, but swapped around
<brendand> to illustrate : http://paste.ubuntu.com/1062206/
<cking> brendand, nope, I didn't know that, I'll filed a bug and get that sorted out
<cking> brendand, I suggest not using the --s3-device-check flag until the fix lands in V0.25.05
<brendand> cking - thanks for looking at it
<cking> I'm working on a fix right now
<cking> thanks for identifying this issue -  looks like it's not been exercised much
<brendand> cking, thanks for looking at it. one of the advantages of having such a wide variety of hardware at our disposal is that we have the 'privilege' of finding out about all the quirks
<cking> yep, I've only tested it on ~5-10 machines here
<apw> xinput reordering its inputs through suspend, fun ... i bet its usb things which move
<cking> I overlooked this - doh
<brendand> cking, to be honest, there's so much stuff going on that you can overlook that it's not worth worrying about
<brendand> just have to take them as they come
<cking> yep, thanks for spotting this, I've got a fix written now, just testing it..
<brendand> cking, what i don't understand is that the id stays the same, so why doesn't xinput just id order?
<cking> because it likes to make our lives difficult?
<brendand> cking, that's the correct answer! you win a prize
<dhana013> Hi Guys, I have doubt in 32 bit linux kernel and 64 bit linux kernel
<dhana013> my machine already working with 32 bit kernel. I have 64 bit kernel , I change my kernel as 64.
<dhana013> bit, it's possible do this. I can do install 64 bit packages 
<dhana013> please guide me guys
<apw> you can in theory install a 64 bit kernel on an i386 userspace if it has 64bit support in the CPU
<apw> depending how much ram you have its not always a good idea though
<apw> cking, does the 'you may wish to read the release notes' link for work you on the installer?n
<cooloney> apw: hey, andy, i'm going to start to do config review for common ARM drivers
<apw> cooloney, ok sounds "fun"
<cooloney> apw: so a silly questions, actually what's common ARM drivers config or where is it?
<cooloney> apw: is it the common config file for armel and armhf?
<apw> heh ... thats a question, finding out whats 'h/w' specific options is pretty hard
<apw> i have never approached commonising config from that side just for that reason
<cooloney> apw: hah, i just start and found it's hard to find them indeed
<cooloney> apw: but i saw your email several weeks about ARM config. 
<apw> well i was fighting arm configs which differed in non-arm things, things like filesystems, right ?
<ppisati> cooloney: you'll find a lot of arm (and even omap-only) related crap even in config.common.ubuntu
<dhana013> apw, I have i5 processor in my machine how to configure custom kernel please guide 
<cooloney> ppisati: oh that's bad
<cooloney> apw: i remember some USB host configs were mentioned in your email
<dhana013> how to utilize the hole hardware to my linux kernel 
<ppisati> cooloney: yes it is, unfortunately
<ppisati> cooloney: it would be nice if we could push all the hw-agnostic stuff in config.common
<ppisati> cooloney: and leave arm details in config/<arch>/config.*
<ppisati> cooloney: but i think it's a lot of work, and a lot of shuffling stuff around
<ogra_> but it will make the future so much easier :)
<ppisati> yes, but whenever i moved any option out of that file, it reappeared in all the arch specific config file after an updateconfigs
<cooloney> i didn't imagine the work is so hard before
<ppisati> i think the logic is someghing like "can i have that option? good, then i put it in config.common"
<ppisati> "is that option any different in any ach specific config file? cool, then i remove it from config.common and push it one level down"
<ppisati> i think the real problem is *why* arm and omap specific options are not binded to any CONFIG_ARCH_ARM or stuff like that
<ppisati> in that case they won't appear in config.common i guess
<ppisati> so the proper fix is to make an arch specific option depends on another arch specific option that only appear in an arch specific config file (this way updateconfigs won't push it inb the config.comm file)
<ppisati> i hope i got it right...
<ppisati> somehow...
<cooloney> ppisati: oh wait, looks like this is an updateconfigs script issue
<ppisati> cooloney: no no
<ppisati> cooloney: wait, let me show you an example
<cooloney> ppisati: yeah
<ppisati> cooloney: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=blob;f=debian.master/config/config.common.ubuntu;h=40c77e1f9a2a8f7c8ac49edb19ac55cecdc19e82;hb=HEAD
<ppisati> cooloney: take for example an omap option
<ppisati> cooloney: like...
<ppisati> cooloney: CRYPTO_DEV_OMAP_AES
<ppisati> cooloney: it shouldn't be here
<ppisati> since it's arm (and even omap in this case) specific
<cooloney> ppisati: yeah
<ppisati> so it should go in config/arm[hf|el]/config.flavour.omap
<ppisati> now, if you move it here, ALL the other other configs file will get this option replicated
<ppisati> let me try...
<apw> cooloney, ppisati, the config optimiser takes no account of which arch something ocmes from as it does not really know
<cooloney> ppisati: I know what you mean here now. 
<cooloney> i found 11 OMAP config in common.ubuntu config
<apw> and its dangersous to try anyhow because armhf and armel are 'separate' configuration options
<apw> s/options/arches
<apw> but they need to be mostly common
<apw> cooloney, any specific option being in common.ubuntu just means it has a common setting in all configurations for which it is present
<apw> where something is in the config hierachy isn't important really, whats important is when its set it is set appropriatly
<apw> which is where the configuration checker comes in
<apw> https://wiki.ubuntu.com/KernelTeam/Specs/QKernelConfigReview/Alpha2
<apw> which is what we use to review and fix options normally
<apw> CONFIG_CRYPTO_DEV_OMAP_AES if you look at that one for instance, it is m on omap and - on everything else, so that is ok and we don't care where it goes in the hierachy
<cooloney> apw: right, so if an option is the same for all arches, it goes into top common config
<apw> yes it will roll up to th
<apw> to the top
<cooloney> apw: and if is the same for all the armhf arch, it goes into common.armhf.config.
<apw> if tis the same for all armhf configs but not for other arches, then yes its in common.armhf only
<cooloney> ppisati: so as apw said, some OMAP configs in common.ubuntu.config show up because they are the same for all the arch configs
<apw> right and that is expected, its a side effect of the algorithm
<cooloney> apw: yeah, exactly
<apw> to be honest its utilitity, the commonisation is less important now we have a proper config comparitor
<apw> as the human can look at the rows in the wiki much better than understanding where in the config hierachy an option ended up
<ppisati> what i wanted to say is that, it would be nice to have options separated by their usage: common non-arch specific options go in config.common, armhf specific go in armhf/config.common.armhf, omap-only options go in armhf/config.flavour.omap, ectect
<ppisati> this way adding a new flavour equals adding a new config leaf
<ppisati> file
<apw> ppisati, that would be nice, but thats not quite how it works
<ppisati> e.g. armhf/config.flavour.highbank
<ppisati> apw: yes
<apw> ppisati, generally to add a new flavour you can just dump a full config down in that file
<apw> and fdr updateconfigs will clear out the common stuff and make a mess of the configs of course
<cking> apw, re: installer, not yet got around to that, will be testing in 20 mins
<ppisati> apw: i think i did during the omap4 review (and last omap3 config bisection)
<ppisati> apw: and updateconfigs badly messed up the config
<ppisati> anyway
<ppisati> cooloney: in any way, have fun! :)
<apw> ppisati, well yes if your config is differnt it has to change the balance to maintain your config
<ppisati> cooloney: sun is shining, it's summer time, and all that solar crap... :)
<apw> ppisati, it doesn't override any of the configs, which is what you want
<ppisati> apw: i don't know, maybe i had a dream/nightmare
<ppisati> apw: but during the...
<apw> i have a bunch of overrides documented now though for next time, which i did to fix highbank up
<ppisati> apw: 3.5 rebase, to me it looks like omap3 "imported" some options that weren't there before
<apw> as from an ubuntu commonisation point of view its the non-arch crap i want right, the h/w stuff should be board specific
<apw> ppisati, well if you took the non-3.5 config and used that yes, you should really have put the config a 3.5 tree and did make oldconfig on it first
<apw> to get asked about the new things
<apw> then used that one in the ubuntu tree
<ppisati> IMVHO we could drop updateconfigs, and mantain config.common manually
<ppisati> apw: could be, don't rememebr when i had that impression
<ppisati> (but i know it won't happen)
<apw> ppisati, the utility of updateconfigs for changing configs is less than it was
<apw> now we also have OVERRIDES to inject changes across the board
<apw> getting from where we are to where you suggest is very hard, but it would be a better place
<ppisati> i know, a lot of shuffling around
<ppisati> and you can't do that in one pass
<ppisati> it's an iterative process
<apw> ppisati, the biggest issue is there is hierachy we cannot express currently like
<apw> ubuntu -> arm -> armel/armhf
<ppisati> right
<apw> and till we can do that its tricky, and the layout of the configs is tied to other layouts currently
<ppisati> well, truth be told that's becasue we use ABIs instead of arch
<ppisati> are we going to support...
<apw> so its not easy.  but i will think on it as what you want makes a lot of sense, its what we all want
<ppisati> the 32/64 bit hybrid
<ppisati> what was the name...
<cooloney> apw and ppisati, i think basically i can start that from the URL for kernel config review. 
<ppisati> n32
<apw> "ubuntu needs X" "x86 needs Y" "x86/server needs Z"
<apw> cooloney, yep anything you find out of sync _either_ needs making in sync, or you need to let me know so i can annotate it as correct
<apw> for example arm needs vfat builtin and thats right, so it has an annotation
<ppisati> no, it's not n32...
<cooloney> apw: sure, i will and try to change the status of this task from TODO to IN PROGRESS 
<ppisati> x32!
<cooloney> apw: and can never mark that as DONE. heh
<apw> cooloney, which task?
<cooloney> apw: review common drivers for ARM
<ppisati> http://en.wikipedia.org/wiki/X32_ABI
<ppisati> this one would use 64bit regs in a 32b address space
<apw> cooloney, sounds good, and even a rough pass is better than nothing
<ppisati> i don't think we are going to support it
<apw> ppisati, yep its probabally what amd64 should have been
<ppisati> but in case we do, we will find ourself in the same situation with armhf/armel
<ppisati> with x32 and i386
<cooloney> apw: np, 
<apw> ppisati, indeed, well we already are, as i386/amd64 already has this commonality
 * apw will play with that before sprint
<cooloney> ppisati: so the first one, why CONFIG_MSDOS_FS should be =y instead of =m for omap4?
<apw> cooloney, we have vfat_fs set for the other arm ones but not msdos_fs, but only someone with the h/w would know if that is needed or not
<ppisati> cooloney: because, for example, if you install a new kernel with same rev as the old one (3.5.0-666~foo will put modules in /lib/modules/3.5.0-666 just like the original 3.5.0-666 would do)
<apw> ppisati, is that msdos or vfat though, we have vfat builtin on omap3 et al for that purpose, perhaps they are wrong?
<ppisati> cooloney: but if the old one has no dos/8859-1 support compiled in, you will end up with modules overwritten (so no chacne to load msdos support) and no ability to mount /dev/mmcblk0p1 where uImage should be copied
<cooloney> ppisati: but for omap3 we use =m as others
<ppisati> cooloney: don't we have vfat set?
<apw> ppisati, we have VFAT_FS set for all arm ports, we have MSDOS_FS set on ti-omap4 only
<ppisati> ah
<ppisati> so it's a mistake
<apw> so i suspect we either need both on all or only vfat on all
<cooloney> ppisati: VFAT=y for all arm stuff, 
<ppisati> cooloney: that should be...
<cooloney> VFAT=m for others like i386 and amd64
<ppisati> btw
<ppisati> so what's the diff between vfat and msdos? fat16 vs vat?
<cooloney> so i think MSDOS_FS should be =m for omap4, right?
<ppisati> i thought they were synonyms
<apw> different drivers indeed.  someone needs to investigate which we needed really on all of them
<cooloney> ppisati:  vfat will allow you to use long file names.
<ppisati> cooloney: got for vfat then
<cooloney> ppisati: yeah, i guess built in VFAT is enough, but not sure right now
<apw> cking, smb, do the indicator menus look ok to you, about half of mine have wrong colours
<apw> ppisati, can you not work out which one is in use by looking at the mount once mounted
<smb> apw, not far enough yet to see them...
<apw> smb, also got a jockey popup to offer me drivers, which appears to have done so to offer me 'pc speaker'
<smb> apw, I assume you speak of quantal...
<apw> smb, indeed is it not ISO testing day
<smb> apw, It is. Just my alternate vm installs are not far enough for gfx
<smb> The kubuntu on real hardware is doing bad enough not to be able to autoreport bus and the server install on that laptop fight s with enabling b44
<smb> Just one of these days...
<cooloney> apw, smb, cking and ppisati, do you guys know where will we stay durning our portland sprint?
<cooloney> or not decided yet
<ppisati> cooloney: nope
<ppisati> brb
<smb> cooloney, We assume but do not know for sure
 * ppisati -> out for lunch
<apw> ppisati, can you tell me which of the two hdmi ports on a panda is the right one?
<apw> ppisati, have you tested the omap4 images for A2, i am struggling to get output from them, even though they seem to do the right kind of booting 
<apw> ppisati, also do i expect to see anything serial side?
<ogra_> apw, i have the same issue
<apw> ogra_, ok so no output on hdmi then?  which port is normally live
<ogra_> apw, bug 1010009
<ogra_> no output at all on many monitors
<ogra_> i found a workaround for mine though
<ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,New] https://launchpad.net/bugs/1010009
<apw> ogra_, not convinced i can plug it in later either
<ogra_> apw, works here 
<ogra_> in the DVI port with hdmi->dvi cable here 
<ogra_> ppisati, bah, the penguins are back !
<apw> ogra_, if i want to change the kernel comamnd line can i do that somewhere either on the image or the serial ?
<ogra_> on the SD
<apw> oh oh where where
<ogra_> plug it into a PC, copy boot.scr from the first partition, open it with vi, remove the binary junk from the start and save it as boot.script
<ogra_> then run: sudo mkimage -A arm -O linux -T script -n 'Ubuntu Boot Script' -d boot.script /mnt/boot.scr
<ogra_> (given your SD was mounted on /mnt)
<ogra_> oh, and mkimage is in the u-boot-tools package 
<ogra_> (for all arches available)
<ogra_> (note the binary stuff only spans half the first line, the rest are proper commands)
<ppisati> apw: hdmi is the one close to the usb/eth thing
<ogra_> right
<ogra_> with the options i added to the bug i get proper output 
<ppisati> apw: copy the text part of boot.scr into a new file (boot.cmd)
<ogra_> well, usable ooutput 
<ppisati> apw: delete quiet and splash
<ogra_> proper would have been 1080p ;)
<ppisati> apw: add console=ttyO2,115200n8
<ppisati> apw: then execute "mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Ubuntu 10.10" -d ./boot.cmd ./boot.scr"
<ppisati> apw: next boot you'll get serial output
<apw> ogra_, ok ... seems to be the same as yours then
<apw> [   64.306365] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays disabled
<apw> [   74.342163] omapdss error: HPD IRQ request failed
<ogra_> right
<ppisati> apw: video is flaky
<ppisati> apw: can you try booting with hdmi cable conncted on both ends
<ogra_> its stable if i add video=HDMI-A-1:1280x800@60
<ppisati> apw: and monitor turned on
<ogra_> but that doessnt mean it works for any other monitors
<ogra_> (and is no option for a default anyway)
<ppisati> just booted today daily and it works here
<ppisati> i mean video oiutput
<ogra_> yeah, you seem to be the only one :)
<ogra_> i wonder though ...
<ogra_> you always boot with console= set ?
<ogra_> on all images ?
<ppisati> nope
<ogra_> ah, k 
<ppisati> this one is a plain daily
<ppisati> i dd-ed to the sd card
<ppisati> booted
<ppisati> and that's it
<ogra_> i'm still wondering if there is a plymouth issue in the game as well
<ppisati> now i'm on the Welcome screen
<ogra_> but if it works for you, it should be fine
<ppisati> System configuration -> language, ectetc
<ogra_> hmpf
<ogra_> well, i havent found anyone else for whom it works yet
<ppisati> benq 20"
<ogra_> your board or your monitor must be special :)
<ppisati> monitor is an lcd from...
<ppisati> 2005?
<ppisati> maybe
<ogra_> though it used to work before here on the very same screen i use atm
<ogra_> and as you know downgrading to the precise kernel fixes it for me
<ppisati> panda es?
 * ogra_ just hopes for the next TILT dump
<ogra_> yep ES
<ppisati> uhm
<ogra_> well, the dvi.debug=7 cmdline option really helped here 
<ogra_> and picking a mode from the debug output and forcing it on cmdline makes everything work
<ppisati> uhm
<ogra_> i just cant seem to use 1080p
<ogra_> but i guess the driver defaults to 1080p since the monitor reports it wworking
<ogra_> so i wonder if its a video ram issue
<ogra_> but it doesnt seem to matter what i put into vram
<ogra_> ppisati, hmm, according to the ML you submitted the fix for the logo on june 6th ... why am i still seeing penguins
<ogra_> must be the drugs :P
<ogra_> ppisati, argh, now i see ... your commit was on the 6th ... the last upload of the omap4 kernel was on the 5th though
<ppisati> ogra_: yes, we are still using alpha1 kernel
<ogra_> ah, k
<ppisati> ogra_: btw wait
<ogra_> so there cant be a kernel difference between live and preinstalled then
<ogra_> good
<ppisati> ogra_: btw, i just booted another image
<ppisati> ogra_: and it works here (video i mean)
<ogra_> well, what shall i say, it doesnt here :)
<ppisati> ogra_: do you have abn installed system?
<ogra_> yup, but with the video= options added
<ogra_> *option
<apw> man these heartbeat leads take some time to start, its all scarey
<ogra_> apw, yep, fixed in the tree already
<ogra_> (they are modular and initramfs-tools dont pull them into the initrd, so you only get them once the rootfs is there)
<apw> ogra_, likely we should just build 'em in
<apw> the board loooks sooooo dead without 
<ogra_> yep, paolo already changed that
<ogra_> just not uploaded yet
 * apw wonders how long he has to wait before ramming his HDMI in
<ogra_> if the hearbeat is up, you should be fine
<bjf> ikepanhc, do you know of more highbank patches coming?
<ikepanhc> bjf: I do not know that yet.
<ikepanhc> robher: any idea? I think you are the best man to answer this
<robher> bjf, ikepanhc: there's always more coming ;) It should only be fixes at this point.
<apw> we probabally errd having it in master
<bjf> robher, though true, i was looking for a little more insite into what you know is actually in the pipeline heading our direction in the next 3 weeks
<apw> ppisati, whats the URL to the working one for you
<bjf> s/insite/insight/
<ppisati> apw: http://cdimage.ubuntu.com/daily-preinstalled/current/
<ppisati> apw: http://cdimage.ubuntu.com/daily-preinstalled/current/quantal-preinstalled-desktop-armhf+omap4.img.gz
<ogra_> http://cdimage.ubuntu.com/daily-live/current/ are the new images ... just FYI ... wont change a thing about the kernel issue
<apw> ppisati, indeed the ones i tested, and not working at all for me
 * ogra_ grabs his beagleXM and starts an omap test
<robher> bjf: There's 2 issues I'm working. I've figured out the root cause of "TEMP: force DMA buffers to non-bufferable on highbank", so this can be reverted/dropped. However, doing so breaks reboot cmd. The other issue is that power key driver doesn't really work because without a desktop, nothing in userspace will handle pwr key. On x86 it is handled by acpid...
<ppisati> ogra_: leave your panda there
<ogra_> ppisati, i wont throw it away :)
<brainsmoke> hi
<brainsmoke> I would be really happy if https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=2e57ae0515124af45dd889bfbd4840fd40fcc07d
<brainsmoke> oops
<brainsmoke> could be backported to LTS
<brainsmoke> since right now those are really handy non-ASLR gadgets exposed in every process
<apw> brainsmoke, you are saying there are security ramifcations ?
<ogra_> ppisati, fyi, omap works :)
 * ogra_ has screen output ... 
<brainsmoke> It makes it easier to write an exploit, given that a program contains a bug
<ogra_> though the font is all blue
<apw> sconklin, ^^
<brainsmoke> you basically only need one (or if you are lucky no) extra gadget for your return oriented programming exploit
<brainsmoke> so I'd say it is an exploit mitigation patch
<ppisati> ogra_: did you get an orange screen while booting?
<ogra_> yes, thats normal
<ppisati> ok
<ogra_> hardcoded in u-boot 
<ogra_> but it stopped booting with squashfs errors :(
<apw> brainsmoke, yeah sounds something worth looking into, you could file a bug with that information in against linux package, and give me the number
<apw> and i'll get it to the right people
<ppisati> ogra_: ???
<apw> ogra_, damn this heap of crap is booted i recon and there is nothing enabled anywhere to let me login, this is stupid
<ogra_> ppisati, zlib infalte errors
<ogra_> *inflate
<ogra_> apw, the live image ? 
<apw> ogra_, any reason we don't ship serial.conf in the image?
<apw> ogra_, yes 
<ogra_> bug 702574
<ubot2> ogra_: Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable (https://launchpad.net/bugs/702574)
<apw> i do not want to have to unpackage and rebuild this damn squashfs to debug this
<ogra_> and https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/add-serial-console/+merge/46191
<ogra_> its being discussed since 2 yeras
<ogra_> *years
<apw> good god
 * apw gives up, its just too hard
<apw> people who are willing to put up with this level of pain should not be allowed to produce software for others
<ogra_> apw, use a server image :)
<ogra_> doesnt need any screen, all serial
<apw> ogra_, bad the tracker points to preinstalled images for server too
<apw> frankly its too hard to help to do any testing on these images
<ogra_> apw, thats because Daviey is such a slacker
<ogra_> server stays preinstalled for now :)
<ogra_> until the x86 server images stzart using squashfs
<ogra_> ppisati, hmm, so i see the squashfs errors (and hang) every other boot here ... i now have a working installer on the screen, but that required a few reboots
<ogra_> (omap beagle XM that is)
<ppisati> ogra_: image/
<ppisati> ogra_: ?
<ogra_> http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-armhf+omap.img
<ogra_> the most recent beagle one
<ogra_> seems like something is flakey with either the MMC or the squashfs driver
<ppisati> ogra_: kernel version?
<ogra_> the latest as well
<ogra_> one sec
<ogra_> 3.5.0-2.2
<ogra_> i think
<ogra_> yup, verified
<pgraner> ppisati, yo man, omap4 and monitors wtf?
<brainsmoke> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018415
<ubot2> Ubuntu bug 1018415 in linux "Backport vsyscall=emulate behaviour to 12.04 LTS as exploit mitigation measure" [Undecided,New]
<ogra_> pgraner, we will get a new code drop from TI that will fix it, not worth to put to much time of paolo into it 
<ogra_> (there was hope to have that drop before A2 but apparently that failed)
<pgraner> ogra_, when do we expect it to drop?
<ogra_> ask ppisati :)
 * ogasawara back in 20
<pgraner> ogra_, so the arm desktop image is not getting tested for A2?
<ogra_> it works fine here 
<ogra_> with either changing the cdmline or booting without monitor plugged in
<ogra_> beyond that it has no issues at all it seems ...
<ppisati> ogra_: actually for the next kernel we won't get any code drop from TI, we'll use vanilla + stuff from Linaro as needed
<ppisati> pgraner: ^
<ogra_> urgh, scary
<ppisati> ogra_: there was an email circulating about it on the kernel ml
<ppisati> ogra_: TI won't support 3.5
<ogra_> well, what are they working on atm ? i thought there was a future kernel planned
<ppisati> ogra_: they stay on 3.4
<ogra_> beyond the rock solid 3.4 one that ndec's team has
<ogra_> oh
<ogra_> well, switching is pretty scary, did linaro actually tell that they will have no regressions wrt what we had in 12.04 ?
<apw> cking, if those tests are easy to 'run' it might be worth comparing the P kernels too, to see if its broken in Q
<cking> apw, it's easy but bloomin' time consuming
<ppisati> ogra_: no no, we won't use linaro
<ppisati> ogra_: i'm picking stuff from tilt, not the entire kernel
<apw> ppisati, so we are running a head of ti ?
<ogra_> apw, ... and will suffer badly ...
<ppisati> apw: if we want to have ti-omap4 on 3.5
<ppisati> apw: else it'll be another topic branch with a different kernel
<pgraner> ppisati, can you or someone from the kernel team drop a bug number for the video issue in ubuntu-release and give skaet an eta on the fix pls. 
<ppisati> pgraner: did you tryu the image? because i've video output
<ogra_> bug 1010009
<ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,New] https://launchpad.net/bugs/1010009
<ogra_> it is already tagged with iso-testing
<apw> ppisati, oh i see our ti is 3.4 i missunderstood
<ppisati> FWIW i've a 3.5 omap4 kernel here
<ppisati> with working video
<pgraner> ppisati, yes on 4 different monitors .... no video
<ogra_> ppisati, well, you should have uploaded it last week then :P
<ppisati> ah
<ogra_> if you have it working already ... 
 * ppisati has the opnly monitor in the world where it works...
<ogra_> yep
<apw> do we want a 3.5, if tey arn't going to support us
<ppisati> if not, it's another topic branch to mantain by ourself
<ppisati> cve, sru, ectect
<apw> bah rock meet hard place
<ogra_> ppisati, well, whats missing in your 3.5 ?
<ppisati> ogra_: freq scaling
<ppisati> ogra_: hdmi
<ppisati> ogra_: didn't test the wifi tough
<ppisati> ogra_: agreen has 1300+ commits on top of 3.4
<ppisati> to support omap4 and omap5
<ogra_> ah, well, if we can get fixes for these and audio works too, then we'll be fine
<ogra_> though the alsa patching will be a pain i guess
<ppisati> i'm doing freq scaling now
<ppisati> /proc/asoud/cards reports 2 cards
<ppisati> panda and hdmi
<ppisati> didn;t test tough
<ppisati> firs one should be ok
<ppisati> secondo don't think so
<ogra_> yeah, i remember there were a bunch of patches that added UCM support
 * ppisati has started today to assemble it...
<ogra_> without it we wont have the devices in pulses gui
<ogra_> but there is enough time before release to fix that i suppose
<skaet> ogra_, actually not...   Based on the time it took yesterday,  I think we're out of runway for A2.   Getting it fixed and in the next set of dailies should be done.
<ogra_> skaet, if i say release i mean release ;)
<ogra_> not milestone ;)
<ogra_> the images we have atm look fine for A2, no need for respins or changes
<skaet> ogra_  the workarounds are pretty ugly.
<ogra_> skaet, boot with no monitor attached until the LEDs blink wildly ? 
<ogra_> (or you are sure that X is up)
<ogra_> i dont think thats to hard as a workaround
<cking> arges, some rough notes on their way to you + a hacked version of jack_delay
<kees> apw: please don't backport 2e57ae0515124af45dd889bfbd4840fd40fcc07d -- it doesn't play well with seccomp.
<kees> apw: if anything, vsyscall should be "none" -- it's entirely deprecated.
<skaet> ogra_, can you please add how this image needs to be worked around to the TechnicalOverview right now,  and given where the issue is happening,  we should probably add this to the notes on the top of the ISO tracker by these images at least.
<ogra_> skaet, will do, its noted in the bug along with another way that worked for me 
<bjf> kees, huh, can you comment on the bug? i was already working on it.
<skaet> ogra_,  yeah, but getting people to know about the bug an read it, as well as instructions for how they should interoperate with these new style images is going to be needed.
<apw> bjf, i've referred that whole thing to security
<bjf> apw, ack
<ogra_> skaet, indeed, though i expect the users to show up in #ubuntu-arm if they cant get along anyway :)
<skaet> yeah,  but give them some clues and pointing them there, is only polite ;)
<apw> ogra_, for you if you plug hdmi in at the point when the flashies start and you are good ?
<ogra_> apw, right 
<apw> definatly does not work at all for me
<ogra_> i use an HDMI->DVI cable ... with the HDMI side attached to the HDMI port of the panda
<apw> same as here
<ogra_> hmm, it cant really fail since booting without monitor forces it into a hardcoded mode 
<apw> ogra_, and what is the mode
<ogra_> unless your monitor cant do the 800x600 or 1024x786 or whatever that default is
<apw> is a 1080p monitor, so it can emulate both of those, it did to my main box when i was fiddling just recently
<ogra_> apw, i have to boot into a broken setup again to find out, currently my beagle has all the stuff plugged in, will test the mode later
<apw> diwic, ok that patch does have an = in the if so the report is valid, the form you have however is likely also valid so feel free to ignoew ir
<ogra_> RAAAH !
 * ogra_ goes mad ... who decided to add that silly microSD slot on the beagle at a place where i alwas accidentially rip it out of the slot
 * ogra_ starts the same install for the third time 
<diwic> apw, aha, it does, I just didn't see it because it complained on another line than the actual =
<apw> yeah you can ignore it, that construct is getting no simpler thats for sure
<ogra_> ppisati, so my omap install failed again and it looks to me like there are USB issues, i get lots of dropped event messages from the NIC driver and the copying of the OS to USB key fails at some point (sadly without any error)
<ogra_> oho !
<ogra_> ubiquity: page allocation failure
<ogra_> there we go
<apw> add more swap
<ogra_> heh
<ogra_> it has 700M
<ppisati> ogra_: i'll try the omap image later
<ogra_> ppisati, k, not watching TV today ?
<ogra_> :)
<ppisati> ogra_: who said i'm not going to watch the match? :)
<ogra_> heh
 * ogra_ cant work if its an exciting one :)
<ppisati> well, spain vs portugal, who knows
<ppisati> portugall will be covered for 90m + 30m 
<ogra_> i guess spain will do it 
<ogra_> tomorrow is more exciting though :)
<ogra_> germany never managed to beat italy ... 
<ppisati> ogra_: you will
<ppisati> ogra_: first because your team is better this year
<ogra_> well, i fear our players are scared by the fact 
<ppisati> really?
<ogra_> and might make mistakes due to it
<ogra_> but yeah, they are better, but its football, its not always the better team that wins
<ppisati> consider that Italy had just 3 days to recover from the previous match + prepare the new one
<ppisati> right
<ogra_> and your guys still have an awesome talent to confuse the other team 
<ogra_> so catching a goal or two is very likely for germany.... the question is how they handle that 
<ppisati> no no
<ppisati> less rest
<ppisati> less time to prepare
<ppisati> a couiple of key players out (De Rossi and Chiellini)
<ppisati> it'll be a suffering tomorrow
<ogra_> i doubt that, i think it will be an exciting game with well balanced out results 
<ppisati> well, we will see
<ogra_> i would be less worried to see them play against spain than against italy
<ppisati> but i would be *really* surprised if Italy can make it
<ppisati> really?
<ogra_> well, they made it this far 
<ppisati> you must be kidding
<ppisati> i mean
<ogra_> spain is visibly in a very bad condition
<ppisati> uh?
<ppisati> are we watching the same stuff?!?!? :)
<ppisati> i mean
<ogra_> they didnt deserve a single win they had this EURO
<ppisati> well
<ogra_> they do their show etc but dont manage to shoot goals 
<ppisati> anyone playing against Spain should just pray they put in Torres
<ppisati> he is so unable to score
<ppisati> since he had that injury
<ppisati> bah
<ppisati> git am -s 
<ogra_> heh
<ppisati> wrong window
<ppisati> ogra_: do you remember 2006 semifinal?
<ppisati> ogra_: it was one of the "best" match i've ever seen
<ppisati> ogra_: well balanced
<ogra_> ++
<ppisati> ogra_: and with a good ending :)
<ogra_> haha
<ppisati> ogra_: don't worry, you'll get your revenge this time
<ogra_> we'll see, i will belive it tomorrow night 
<ogra_> would be fun if portugal kicked out spain though 
<ppisati> i've a frind who bets against Italy
<ppisati> so
<ppisati> if Italy passes, he's kind of happy
<ogra_> heh
<ppisati> if it looses, he's still happy! :)
<ppisati> it's a win-win condition
<ogra_> i heard about betting on germany from several people 
<ogra_> anyway, i need some food and then need to write some notes for kate before the game 
 * ogra_ is off for a bit
<cking> apw, the 3.2.0-23 low latency kernel has almost identical behaviour as the 3.5.0-1 low latency kernel, so no major screw ups there
<kees> bjf: which bug number is it? I think I can solve both issues by setting vsyscall to "none".
<bjf> kees, bug 1018415
<ubot2> Launchpad bug 1018415 in linux "Backport vsyscall=emulate behaviour to 12.04 LTS as exploit mitigation measure" [High,Triaged] https://launchpad.net/bugs/1018415
 * cking --> EOD
<bjf> kees, apw said he has punted it to the security team
<kees> bjf, apw, mdeslaur: I've added comments to 1018415. I think "= NONE" is the right way to go.
<mdeslaur> kees: ah, interesting...thanks
<mdeslaur> kees: watch, it's going to break java or something :)
<kees> mdeslaur: well, if "none" doesn't work out, I still say that "emulate" isn't the right solution.
<kees> mdeslaur: anyone concerned with it can just boot with vsyscall=whatever-they-want, too. :)
<pgraner> apw, ping
<pgraner> apw, ogra_ tells me your having the work around for the video issue fail on panda (bug https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1010009)
<ubot2> Ubuntu bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,Confirmed]
<pgraner> apw, can you add some data about configs etc... to the bug
<apw> pgraner, indeed, i have infinity's older board, the one we had at the release sprint
 * rtg -> EOW
<vanhoof> pgraner: apw: have a panda-es running quantal in front of me, headless atm though if you'd like me to test something
<apw> vanhoof, does the head work
<pgraner> vanhoof, yea run todays desktop image and see if you get video out of hdmi
<pgraner> vanhoof, if you don't try the workaround in bug https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1010009
<ubot2> Ubuntu bug 1010009 in linux-ti-omap4 "omapdss only works on some monitors in quantal" [High,Confirmed]
<pgraner> and comment in the bug with your results
<vanhoof> pgraner: can I just dist-upgrade, or need to be a fresh install?
<pgraner> vanhoof, fresh
<pgraner> vanhoof, just an sd card bro go for it
<vanhoof> pgraner: yeah got a few laying around here :)
<vanhoof> pgraner: apw: no dice, will update the bug
<hyperair> hmm, i don't seem to be seeing any autogroup-created cgroups in /sys/fs/cgroup/cpu. is it supposed to be invisible?
#ubuntu-kernel 2012-06-28
<bullgard6> What is the preferred term? Â»inux kernel moduleÂ« or Â»loadable Linux kernel moduleÂ«?
<bullgard6> +L
<jk-> the first is fine.
<bullgard6> jk-: Thank you.
<bullgard6> '~$ modinfo bch; filename:   /lib/modules/3.2.0-25-generic/kernel/lib/bch.ko; description:    Binary BCH encoder/decoder.' What does  Â»BCHÂ« stand for? For Â»A forward error correction technique with low-overhead,often used for videoconferencing as in H.261Â«?
<smb> morning
<bullgard6> '~$ modinfo bch; filename: /lib/modules/3.2.0-25-generic/kernel/lib/bch.ko; description:  Binary BCH encoder/decoder.' What does  Â»BCHÂ« stand for? For Â»A forward error correction technique with low-overhead,often used for videoconferencing as in H.261Â«?
<philipballew> Do I report broadcom bugs with the kernel or are they separate?
<ehw> bullgard6: http://en.wikipedia.org/wiki/BCH_code
<bullgard6> ehw: Thank you very much for your help.
<ehw> bullgard6: np :-)
<ppisati> ogra_: http://people.canonical.com/~ppisati/linux-image-3.4.0-202-omap4_3.4.0-202.7_armhf.deb
<ppisati> ogra_: test it and tell me if it fixes the video problem for you
<bjf> brendand, is the precise kernel done with testing?
<brendand> bjf - pretty much. i'm just getting our report updated and updating the bug
<ogra_> ppisati, oh, thanks, will do
<ppisati> ogra_: thanks
<ogra_> ppisati, pgraner, the above kernel boots for me but i have a completely black screen until X 
<ogra_> so there is still an issue with plymouth ... but it looks a lot better already
<ogra_> ppisati, i assume we should add the link to the bug so all these other peple can test it too (since the former kernel seemed to behave differently on a total random base)
<apw> ppisati, is the changed part in the kernel or in a module ?
<ogra_> likely in kernel
<ogra_> yep
<apw> knowing which tells me 
<ogra_> no module there
<apw> how little of the image i have to fook with
<apw> ok cool
<ogra_> use the server image 
<ogra_> that way you can do the install via serial
<ogra_> then you just need to dpkg -i the kernel
<apw> i thought that you didnt' get output till X started
<ogra_> well, until plymouth ends i should probably have said
<ogra_> i have all tty's
<apw> ok cool
<ogra_> so i guess there is a plymouth issue alongside the kernel prob
<apw> yay fun
<ppisati> apw: ogra_: i pulled all the new code from tilt-tracking (TI landing tree)
<ppisati> kernel is still a 3.4 though
<ogra_> thats fine
<ppisati> plus ubuntu sauce, etcetc
<ogra_> still better than having to roll back to precise 
<ogra_> which was what was requested yesterday
<ppisati> no one told me that
<ppisati> here is the code:
<ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-quantal.git;a=shortlog;h=refs/heads/ti-omap4-next
<vanhoof> ogra_: what'cha want me to test out?
 * vanhoof just saw your mention in #ubuntu-release
<ogra_> vanhoof, do a server-preinstalled install (which is fully serial console based) then install paolos package and see if your tty comes up on next boot
<ogra_> http://people.canonical.com/~ppisati/linux-image-3.4.0-202-omap4_3.4.0-202.7_armhf.deb
 * vanhoof downloads
 * ppisati -> gym (back in ~2hrs)
 * ogasawara back in 20
<cking> phew, it's hot and muggy here in the UK
<ogra_> cking, not better in germany 
<apw> cking, in better news my new 'silent laptop fan' is both pretty damn quiet and dropped the temp on my router/firewall from 53 to 40c.
<cking> apw, you did a fan upgrade?
 * ogra_ just bought a Â´super silent desktop fan ... huge thing !
<apw> cking, no this is a usb connected 8in fan in a laptop stand, which its not standing on
 * cking opens the office roof windows a bit more
<apw> ogra_, in better news ppisati's kernel sorted my panda out too
<ogra_> apw, well, stgraber just reported failure in -release
 * apw can see VT1 for the first time, so its better here
<apw> though the hdmi output is on the other connector to the one i was told it would be
<apw> that said its the first time i've ever seen output so i have no idea if its different
<stgraber> so, I have a whole bunch of tcp_recvmsg related oops, then I ran into an OOM kill
<ogra_> its written next to the socket if you are in HDMI or DVI 
<ogra_> get your glasses ;)
<apw> ogra_, this board has two hdmi ports
<ogra_> never
<ogra_> HDMI next to the USB and DVI-D next to the corner
<ogra_> ands that should also be written next to them on the PCB
<apw> hmmm, ok ... so you are right, the connectors are both hdmi
<ogra_> right
<apw> and the one which is working is dvid
<ogra_> funny, for me HDMI works here 
 * ogra_ tries to boot plugged into the DVI one
<apw> so his kernel has fixed that one
<ogra_> yep
<stgraber> sadly that seems to have fixed itself and I can't get any proof of it but I think I saw most of my memory being used while nothing in userspace was using it, kind of looked like the kernel was buffering a bit too much or something like that
<ogra_> do you have quiet and splash on your cmdline ?
<ogra_> apw, ^^^
<ogra_> i would like to know if enabling splash changes anything for you 
 * ogra_ suspects we also have a plymouth bug 
<apw> ogra_, whatever the default is for server i've not changed it
<ogra_> ah, yeah, that should have splash 
<apw> and now i have his kernel i have lost serial ?
<apw> or maybe i never had it after reboot after install hmmmmm
<ogra_>  /usr/share/flash-kernel/bootscript/bootscr.omap
<ogra_> fix it there and run sudo flash-kernel
<apw> yeah like i can get to it without serial, or avahi to tell me its addy ... 
<apw> why do we make it _so_ _hard_ by default
<ogra_> thats a bug 
<ogra_> server should have serial on by default 
<ogra_> but preferably upstart should take care and not a hacked up boot.scr
<ogra_> the bug for this is only open since three years now
<apw> ogra_, we could just upload the fix then
<stgraber> oh, found the source of my OOM :) /var/log/syslog got so big that the system no longer had any free memory
<apw> given we have been shipping the serial.conf with arm for much of that time
<apw> df
<ogra_> https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/add-serial-console/+merge/46191
<apw> poke jhunt in the eye about it
<apw> i will cirtainly be finding him and whining about debugability
<ogra_> i do, every time we meet ... and every time some nipicker kicks in right before the upload and screams "stop"
<apw> can't we put "arch == arm" in it to appease them
<ogra_> its not as easy as it seemt to get a patch into ubuntu :P
<ogra_> *seems
<apw> ogra_, whats my tty for serial ttyS0 ?
<ogra_> O2
<apw> ogra_, ok with quiet splash removed my HDMI port now works too
<ogra_> wow, weird
<ogra_> both ports should behave identical 
<apw> perhaps there is some boot randomness in here
 * apw tests that theory
<ogra_> if you have quiet and splash enabled, do you actually see a splash on boot ?
<ogra_> for me thats just a black screen until lightdm shows up
<apw> ogra_, no idea, as getting it to stay on dvi is hard on this monitor as i use it for my other machines on vga
<ogra_> i do the same here 
<ogra_> get a better monitor :)
<apw> ogra_, send me some euros :)
<ogra_> haha, i know who was betting on germany winning the EURO2012 ... if we win i will point you to him 
<apw> can really say whats going on, hdmi is not reliable, plugging into dvi seems to work better
<ogra_> for me both ports work reliable 
<ogra_> but without any splash output ... only on shtdown i get it
<apw> ok yeah black all the way to the prompt same here
<ogra_> great+
<ogra_> so our bug was a combo ... it could well be that epople actually had a proper booting system, but casper (behind the spalsh) takes around 5min to get you to the desktop
<apw> ogra_, yeah and without serial you cannot tell that you have life
<ogra_> right
<apw> all my boots had heartbeat, which i now know means root is moutned and working
<ogra_> well, from next upload on it will beat from initrd again :)
 * apw thinks it would be nice if it beat different in each half :)
<ogra_> heh
<ogra_> its easily programmable through GPIOs
<apw> cking, down to 39c, thats pretty good
 * cking grabs a bite to eat
<vanhoof> ogra_: apw: new kernel got me to a tty on both hdmi and dvi-d
<ogra_> great
<ogra_> ppisati, so it seems to be good to upload that fix :)
<vanhoof> ogra_: I did have to remove quiet and splash though and rebuild my boot.scr
<ogra_> can you re-add both and try again ?
<ogra_> you should still end up at a login prompt but the boot will likely be black
<vanhoof> sure
<vanhoof> ogra_: black as expected, seemed to take a bit longer, might just be boredom of me looking at the screen :)
<ogra_> but you get a login prompt at the end ? 
<ppisati> so, do i pull req?
<ppisati> ogra_: ^
<shadeslayer> question, any reason why CONFIG_DRM_I915 is not set as y ?
<shadeslayer> it's currently compiled as a module
<ogra_> ppisati, yes, lets get that thing uploaded
<ppisati> ack
<vanhoof> ogra_: i do
<ogra_> awesome, so bug 1018907 is valid too
<ubot2> Launchpad bug 1018907 in plymouth "plymouth in quantal on arm does only boot with black screen" [Undecided,New] https://launchpad.net/bugs/1018907
<infinity> bjf: So, linux-firmware hasn't historically ever been updated in -security, only in -updates.  Given that Tim updates it to match drivers in backports-modules, which we copy to security, perhaps firmware should also be copied to security?  Opinion?
<infinity> ogasawara: ^
<infinity> jdstrand: ^
<bjf> infinity: makes sense to me
<ogasawara> infinity: copying to security would seem to make sense to me too
<infinity> jdstrand: Do you have a Security Team position for me on the linux-firmware updates business?
<ogra_> you want to change teams ?!?
<ogra_> :)
<infinity> ogra_: "A position from the Security Team"? :P
<ogra_> *g*
 * infinity dies a little inside after having a German point out the ambiguity in his English.
<ogra_> lol
<ogra_> come on i had a beer already in football preparation :)
<apw> it is toooo hot to be doing this ... /me wanders outside
<ogra_> ppisati, sooo ... good luck for your team, may the better one win ;) 
 * ogra_ is off ... 
<infinity> bjf / ogasawara: Kay, so I had a chat with mdeslaur about linux-firmware, and I'll be pushing the SRUs to security when I do updates.  I think (prompted by his comments) that we should probably try to formalise linux-firmware updates a bit to make sure they stay in sync better, though.
<ogasawara> infinity: ack, I will add it as a topic for our team sprint
<infinity> ogasawara: Danke.  It's a bit sad how out-of-date these firmware updates are.  Part of that falls on the SRU team, to be sure, but some more input from you guys wouldn't hurt.
<infinity> Anyhow, I'll tidy that situation up as best I can today, and we'll see if we can improve process later.
<infinity> bjf / ogasawara: Alright, I've released all the pending linux-firmware packages (based on either the firmware being completely new, or on the new version of firmware being confirmed to fix a bug) to updates/security.  No idea if you guys watch l-f as closely as you watch the kernel for regressions, but please keep an eye out for scary. ;)
<ogasawara> jsalisbury: can you keep an eye on linux-firmware for a bit? ^^
<infinity> bjf: And I think that clears our your team's entire SRU backlog, except for the aforementioned ARM kernels.
 * cking calls it a day, too hot
<infinity> cking: Didn't apw just say the same thing?
<infinity> cking: You guys need to move to a cooler climate.
<cking> heh, this is the first hot day of the UK summer, we can't hackit
<infinity> cking: Don't worry, it'll rain soon.
<cking> infinity, that is for sure in the UK
<bjf> cking, you'll be in the pacific-nw soon, will be cooler then
<bjf> infinity: ack, thanks
 * cking opens all the windows to try to simulate air conditioning
<infinity> bjf: Sprinting in Portland?
<bjf> infinity: yup
<infinity> bjf: And no one thought to invite me?  For shame.
<infinity> ogasawara: </3
<ogasawara> infinity: I thought you had a restraining order against me after our last encounter :)
<infinity> Oh, I'm mostly over that. ;)
<infinity> Mostly.
<infinity> *stare*
<ogasawara> heh
<shadeslayer> ok, so I'm compiling the stock 3.5 rc4 kernel with a custom config and make-kpkg, and I get this : dpkg-gencontrol: error: illegal package name 'linux-image-3.5.0-rc4stock-ARCH': character 'A' not allowed
<shadeslayer> ideas?
<shadeslayer> command I used was :  fakeroot make-kpkg --initrd --append-to-version=stock kernel-image kernel-headers  
<shadeslayer> halp?
<jsalisbury> ogasawara, ack
<dileks_> shadeslayer: seen link in topic?
<dileks_> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<shadeslayer> dileks_: ok, and could you point me to the rc4 source with the debian packaging?
<kirkland> can overlayfs use blockdevices for lower and/or upper?
<kirkland> or does it have to use a filesystem?
<ogasawara> ppisati: I take it the ti-omap4 3.4.0-202.7 need uploading as well?
<dileks_> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=summary
<dileks_> http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D
<dileks_> shadeslayer: ^^
<shadeslayer> aha
<shadeslayer> ok
<shadeslayer> thanks dileks_
<jdstrand> infinity: sorry I wasn't available when you asked (I'm on holiday today). I see you and mdeslaur talked, and I'll defer to his decision
<infinity> jdstrand: Good deal.
#ubuntu-kernel 2012-06-29
<elops> Hello. can yo think of any thing bad about adding splassert(IPL_NONE) to pmap_enter() ?
<palsa> Hello, I found a bug in the gma500_gfx module. How can I obtain the sources?
<palsa> Never mind, sorry for the stupid question.
<apw> ppisati, i have updated the summary-matrix with your latest upload: http://kernel.ubuntu.com/~kernel-ppa/configs/quantal/reviews/Portland.html
<ppisati> apw: still a lot of sh*t to be synced, thanks
<apw> ppisati, now you know my highbank pain
<guest1337> if i update kernel 3.4.2+ my wireless card does not work anymore. uses ath9k driver. anyone knows what i can do?
<apw> guest1337, does it report anything in dmesg when you use that level of kerenl, it may be needing newer firmware for instance
<guest1337> wlan controller is not shown at all
<apw> thats odd indeed, whats the pci ids for it, as ath9k still exists in later kernels
<guest1337> 02:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01)
<apw> if you use lspci -nnvv it will include some numbers for it (xxxx:yyyy) sort of thing
<guest1337> 02:00.0 Network controller [0280]: Atheros Communications Inc. AR9485 Wireless Network Adapter [168c:0032] (rev 01)
<guest1337> 	Subsystem: AzureWave Device [1a3b:2086]
<guest1337> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
<guest1337> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
<guest1337> 	Latency: 0, Cache Line Size: 64 bytes
<guest1337> 	Interrupt: pin A routed to IRQ 17
<guest1337> 	Region 0: Memory at dea00000 (64-bit, non-prefetchable) [size=512K]
<guest1337> 	Expansion ROM at dea80000 [disabled] [size=64K]
<guest1337> 	Capabilities: <access denied>
<guest1337> 	Kernel driver in use: ath9k
<guest1337> 	Kernel modules: ath9k
<apw> guest1337, presumably thats from an
<apw> guest1337, presumably thats from an older kernel
<guest1337> yes thats a working kernel
<apw> and where did you get your 3.4.x kernel
<guest1337> you need the output of an non working kernel?
<apw> not sure about that yet
<guest1337> you only need that output? have to reboot
<apw> i am wondering where the 3.4 kernel came from first
<apw> so i can check the config
<guest1337> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<apw> which one specifiically
<guest1337> 3.4.1 works
<guest1337> 3.4.3 tested does not work
<guest1337> and 3.4.4 also not working
<guest1337> all 3.5.x also not working
<guest1337> i did not test 3.4.2
<apw> well that would be worth testing indeed to work out which jump is the issue
<apw> why are you using 3.4 kernels?  any reason, or just for fun
<guest1337> part fun
<guest1337> other
<guest1337> tochpad is correctly recorganized in 3.4.1
<guest1337> if i use the stock one touchpad is show as mouse etc
<apw> which touchpad out of interest
<guest1337> Sentelic Touchpad
<apw> sforshee, ^^ may be an interesting data point for you
<guest1337> also scrolling is working with 3.4.1
<apw> there is exactly one ath9k patch between those two versions, which is also present in v3.4.2, so if you could test that version that would help work out if it is that commit
<apw> it sound somewhat unlikely
<guest1337> ok brb 5min 
<dupondje> BLKSSZGET should return new disk size when I resized a disk, and did a rescan ?
<dupondje> Did: echo 1 > /sys/bus/scsi/devices/0\:0\:1\:0/rescan
<dupondje> dmesg shows new size, but for example fdisk not (which uses BLKSSZGET)
<apw> if dmesg shows the new size then the disk ought to have changed, is the overall size in the partition table too?
<dupondje> [57013390.810115] sd 0:0:1:0: [sdb] 2147483648 512-byte hardware sectors (1099512 MB)
<dupondje> and fdisk: Disk /dev/sdb: 536.8 GB, 536870912000 bytes
<apw> hmmm you might strace fdisk and see what was returned there
<apw> if i am reading the current code right it should be returnign the samem number
<guest1337> here i am again
<guest1337> srry took bit longer
<guest1337> apw: 3.4.2 also not working
<apw> guest1337, there does only seem to be one commit .1->.2 which could possibly affect ath9k
<guest1337> another problem which i forgot
<guest1337> whole usb ports do not work anymore
<guest1337> on top of that
<dupondje> apw: ioctl(3, BLKSSZGET, 0x7fffffffd31c)     = 0
<dupondje> fdisk does a BLKSSZEGET, which seems to return wrong size
<apw> that does seem broken, i assume this is a VM of some sort given you can change the size of the disk ?
<dupondje> blockdev --getsz /dev/sdb also returns old value
<dupondje> yep
<dupondje> virtual machine, extended disk, rescanned disk
<dupondje> but now I can't extend partition because of this
<guest1337> apw: found a difference in lspci -nnvv : 	Interrupt: pin A routed to IRQ 17 (with working kernel) and 	Interrupt: pin A routed to IRQ 5 with non working. from network controller
<apw> dupondje, presumably a reboot of the vm will resolve it
<dupondje> apw: indeed, but thats what we want to avoid ofc :)
<guest1337> ath9k driver and module is not loaded at all in non working
<smb> dupondje, Sorry I just saw and still read this, I am not sure the scsi rescan attribute works the way ... have you tried to use 'blockdev --rereadpt'?
<dupondje> BLKRRPART: Device or resource busy, its mounted ofc :(
<apw> guest1337, ok not sure how any change in .1->.2 could cause that, but there is an ath init change so that seems suspicious as a first cut
<apw> guest1337, will see about getting a build with that on top of .1 to see if that it, will take me a few
<guest1337> ok
<smb> dupondje, Yes, none of the device old partitions or the device itself should be opened by anything at that point. And sometimes its near impossible to find out what keeps it busy. :/
<ohsix> fuser?
<smb> More often not that it does in that case
<smb> dupondje, Hm, what kind of virtual machine and how did you resize the disk? Just to get a bit more context
<dupondje> smb: ESXi host
<dupondje> resized in the vmwware interface
<dupondje> its just annoying imo :) resize2fs can do live resizes
<dupondje> vmware can do live resize of disk
<dupondje> and then your stuck just with extending the partition :)
<smb> dupondje, Well don't know much about the internals of vmware. But I guess they just change the disk itself. To some degree this has been noticed by the kernel, but whatever makes the rereadpt fail prevents the gendisk info to get updated.  And as long as that doesn't get done the rest fails too
<smb> I assume rebooting is not an option otherwise you'd probably done it long ago...
<dupondje> well its an option
<smb> None of the partitions on that disk are currently mounted?
<dupondje> as last resort :)
<dupondje> Well they are mounted ...
<dupondje> alot of services running on the disk, so reboot/unmount is last option
<dupondje> But I guess its just not possible to resize without a reboot/umount
<smb> At least not without unmounting. You would certainly not be happy if someone stole the chair you are sitting on, even if it gets replace by a bigger one...
<dupondje> feature request ? :p
<dupondje> guess it should be possible?
<dupondje> disk can be live resized, new size is mostly seen by the kernel after a device rescan and filesystem can be live resized.
<dupondje> so just missing the fdisk/partition part :)
<apw> guest1337, http://people.canonical.com/~apw/mainline-3.4.2-debug-quantal/
<smb> Well "just" the partition part has a potential to move around any mapping the kernel is using (while mounted). To allow that is not sane feature in my world...
<guest1337> apw whats that?
<apw> guest1337, a .2 with teh ath change reverted
<dupondje> smb: you mean if you have like 2 partitions, and second partition gets deleted it would fuckup ? :)
<guest1337> ok ill give it a tyr
<guest1337> try
<smb> dupondje, Certainly, I would. :-P 
<guest1337> apw: restarting and testing
<dupondje> smb: but still, there could be a check that it for example only resizes partitions, and never add/delete ? :)
<smb> dupondje, Feel free to add that and get it accepted upstream. 3:)
<dupondje> challenge ... oh wait :)
<guest1337> re
<guest1337> apw: not working.
<Daviey> smb: hey, is http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commitdiff;h=4b727361f0bc7ee7378298941066d8aa15023ffb;hp=e1ac50f64691de9a095ac5d73cb8ac73d3d17dba not applied to precise?
<smb> Daviey, That points to a net staging tree. Should it? Certainly this normally would need to be upstream _and_ marked cc stable...
<Daviey> smb: I'm just vaguely looking into.. bug 997978 .. which is a set of https://bugzilla.kernel.org/show_bug.cgi?id=42829
<ubot2> Launchpad bug 997978 in qemu-kvm "KVM images lose connectivity with bridged network" [High,Confirmed] https://launchpad.net/bugs/997978
<ubot2> bugzilla.kernel.org bug 42829 in kvm "KVM Guest with virtio network driver loses network connectivity" [Blocking,Resolved: code_fix]
<smb> Daviey, But checking upstream, this was in Linus tree at 3.2 time...
<smb> And it is in Precise
<Daviey> smb: I thought it would have been applied, which is why i am confused
<Daviey> smb: I guess that commit is unrelated to the Ubuntu bug?
<smb> Daviey, Well it was in from the beginning
<smb> That patch went upstream v3.2-rc1
<Daviey> smb: So why no worky?
<smb> Daviey, Some other problem? Why should I know? ;)
<Daviey> smb: you smart guy.
<smb> Daviey, Maybe, but not almighty. ;-P
<smb> nor omnipresent
<Daviey> smb: Oh, i see. I looked at you as an oracle for all things.
<smb> Daviey, Where did you find the reference to that upstream commit? In that bug of ours of rh bugzilla?
<Daviey> smb: community member correlated them on IRC.
<smb> Daviey, Omm. I think I found it. Its in the upstream bug before the comment saying 11.10 (Oneiric) looks good...
<Daviey> smb: Oh sorry, i thought you meant.. what linked the kernel.org bug to LP
<smb> Daviey, No more in the sense how or why do we assume this would be the fix. It is a bit confusing in the upstream bug report. It say "I assume it got fixed" but nothing really definitve and the next comment probably only means with a certain argument...
<smb> Daviey, I wonder. In our bug report, is there anything said about the host? I only see guest versions but may miss something
<guest1337> apw: just tried quantal live build wit 3.5.0.2 and it works.. Oo
<Daviey> smb: I only started looking at this briefly before i pinged out.. hallyn has been closer to it.
<ogra_> wow, ogasawara made it into the german IT news
<ogra_> http://www.golem.de/news/ubuntu-zweite-alpha-von-quantal-quetzal-erschienen-1206-92862.html
<smb> Daviey, So guess it needs more reading. The change you asked for definitely is in. So whatever the issue is in PRecise it would be different. Or maybe something that has to be changed in a driver running in the host space...
<guest1337> can someone watch up xserver-xorg-video-intel current version in 12.04 pls?
<brendand> is there a particular package i need to install to get the quantal xorg packages on precise?
<brendand> looking at dpkg -l i don't have them, despite that the ppa is enabled
<Daviey> smb: okay, thanks muchly
<[yates]> hi, where can i find a changelog of precise's linux-image-3.2.0-25-generic and linux-image-3.2.0-26-generic?
<henrix> [yates]: in the package itself. take a look at /usr/share/doc/linux-image-3.2.0-25-generic/
<[yates]> ahh yeh, nice, thanks :)
 * apw looks for an archive admin to stroke a linux-lowlatency kernel in quantal
 * apw tries to remember where the udev persistant naming db is
<apw> and finds them in the first place he looks, yay
<smb> apw, network devices?
<apw> yeah, adding a 3rd nic to my firewall
<smb> Now you can do a network packet 3-way merge...
<apw> heh... 4 way as i have a tunnel too
<arges> cking, hello
<cking> arges, hiya
<arges> cking, finally getting around to the jack_delay testing (its been a fun  week)
<arges> cking, where did you get jack/jack.h headers from?
<cking> arges, something like libjack*-dev - I can't recall of the top of my head
<arges> ah there we are
<arges> cking, thanks
<cking> libjackdev2-dev I think
<cking> nope, libjack-jackd2-dev
<arges> libjack-jackd2-dev
<arges> yea
<arges> wrong version causes issue
<cking> yep, it causes all kinds of woes
<arges> cking, ahhhh. i have it playing back via headphones and monitors... whoops
<cking> arges, its not the most helpful of test tools
<arges> cking, i see no variance at all ... i can't even tell my terminal is scrolling anymore
<cking> arges, yep, I only got variance when the buffer settings were very small
<cking> ..and on a slow machine
<cking> but if you load it with tools like "stress" you may see some jitter
<arges> cking, ok i may run a stress/unstressed test
<arges> as another variable
<cking> arges, if you see my data, I had lots of variables :-/
<arges> cking, do you have particular stress settings you used?
<cking> arges, I ensured all the CPUs were loaded, and followed the defaults otherwise
<cking>  arges, for my 2 CPU laptop, I used: stress --cpu 2 --io 4 --vm 2 --vm-bytes 128M 
<arges>  stress --cpu `grep -c processor /proc/cpuinfo` --io 4 --vm 2 --vm-bytes 128M --timeout 60s
 * cking nods
<arges> cking, also are you testing on quantal or precise?
<arges> i know the ll is quantal
<cking> Q
<arges> hmm
<cking> and I compared the low-latency kernel Q against P, and they behaved the same
<arges> cking, the maximum schedule delay... where di dyou find htis?
<cking> arges, its on the qjacktql messages window - just near the XRUN count
<cking> but only shows up if you get XRUNs
<arges> cking, ah
<arges> cking, lowest latency settings just crashed jackd 
<arges> : )
<cking> arges, yep, I get that too, it may work after a reboot, but it was really flakey
<arges> cking, yea i wrote a 'kickSoundcard.sh' script that just removes all the firewire modules, kills jackd, kills pulse,  and reinserts and loads everything up again
<arges> because this stuff happens fairly frequently
<cking> basically it's fragile like eggshells
<cking> arges, it took me forever to collect multiple sets of reliably looking data for different kernels, different loads, different buffer size configs
<arges> cking, i still don't see max sched delay in the qjackctl window... is it somewhere else?
<cking> arges, urm, I need to fire up the box that I tested this on just to re-remind myself, lemme dig it out of the pile
<arges> cking, i see it
<arges> cking, messages->status
<cking> arges, that's the one
<arges> cking, did you notice if the -ll kernel was anymore stable?
<arges> w.r.t. to audio latency / jack not crashing
<cking> arges, nope, both were flakey
<arges> well its time to reboot my machine
 * ogasawara back in 20
<josepht> after rebooting a preinstall-server image on my panda, /proc/cmdline contains only 'ro quiet splash'
<ppisati> brb
<ogra_> josepht, quantal ? 
<josepht> ogra_: yes
<ogra_> thats normal
<josepht> ogra_: okay, thanks
<ogra_> in the new world order the boot config lives now in /usr/share/flash-kernel/bootscript/ in case you want to change it ... the root= stanza isnt necessary anymore, flash-kernel installs an initramfs hook that reads it from fstab now
<cking> arges_, so what was your conclusion? anything of substance?
<arges_> cking, getting data now, but had a call so getting back on task
<cking> arges_, ah, no sweat :-)
<arges_> cking, hmm i think this test is invalid because something called 'unity-music-daemon' started slamming my harddrive
<cking> arges_, :-/
<josepht> ogra_: I still need to run flash-kernel right?
<ogra_> yep
<ogra_> that hasnt changed
 * ppisati goes to buy some food
<arges_> cking, so really >= 32 frames I'm not getting XRUNs with jack_delay and one channel + stress test
<arges_> anything else I should be adding to test perhaps 8 channels etC?
<cking> arges_, well, it may be your CPU is just fast enough
<arges_> cking, yea perhaps test on my other machine
<arges_> but i'll add that data to the study so we have it
<cking> we could set the max freq lower and re-test
<arges_> cking, one thing is that the stress maxes the CPU
<arges_> cking, but harddrive operations will cause xruns
<cking> yep, well run the bonnie test and see if that causes xruns too
 * henrix -> EOD
 * cking --> EOD
 * bjf -> lunch
<cking> apw, I've just sent you the 32/32 32/64 64/64 combo results
<cking> no big surprises
<apw> cking, hey thanks, will look at the tommorrow when i am more with it
<cking> whenever reallty
<apw> cking, which side of 32/32 is 32/64 better or worse 
<cking> it depends on what you're looking for :-)
<apw> that means its better for soemthing :)  i shall look forward to reading
<cking> lets chew it over on monday when I've not got the kids pestering me 
<infinity> Performance-wise, I can't see how 32/64 would be any better than 32/32 (since the userspace is too stupid to know it has access to native atomics and other fun stuff), but the obvious benefit of having a 64-bit kernel on your 64-bit CPU seems worth it.
<infinity> Assuming, of course, that your "32" is i386.  If the 32 is x32, that's a different can of worms, since you just bought yourself more registers and instructions and such.
<mjg59> Or even if your 32 assumes the presence of sse
<infinity> Which ours doesn't.
<cking> like always, it's a mixed bag
<infinity> Though, it has runtime selection here and there.
 * cking -> REALLY EOD
<infinity> s/D/W/
<apw> infinity, well bear in mind that your system calls we in 64bit so it could easily be faster for some operations, and hotter, and eat more battery
<apw> *will be in
 * apw calls it a wrap too, i smell some lovely spagbol in my future
<infinity> You people and your living in the future.
<apw> its better than the now in most cases ...
<infinity> Is this why Australians always seem so unjustifiably happy?
<palsa> Anyone still awake?
#ubuntu-kernel 2012-06-30
<ailo> I'm trying to learn how to upload a kernel using kteam-tools, specifically build-mkppa
<ailo> What I'm wondering about is patches
<ailo> I want to patch config files mostly, but how will build-mkppa know where to apply them?
<ailo> Butteee, I should probably read more about patching anyway
<ailo> I guess I need to know how to create the patches and what to think about when putting them in <kernel>-ppa/patches/
<ailo> I guess a diff between two complete sources would do then..
<ailo> Hi, I'm looking for some tips on uploading a customized kernel to PPA
<ailo> I want to edit the configs, and change the ABI
<ailo> I'm able to upload fine, but the build fails because of the edited configs
<ailo> Here's a failed build log https://launchpadlibrarian.net/109017347/buildlog_ubuntu-quantal-i386.linux_3.5.0-2.3-lowlatency_FAILEDTOBUILD.txt.gz
<ailo> I think what I'm stuck at is making changes to the source, and have the changes buildable
<ailo> I would like to add that I know very little about Debian packaging
<ailo> But I'm only really interested in being able to test different configs for the kernel at the moment, so I'd rather skip learning for now
#ubuntu-kernel 2012-07-01
<ohsix> wacky, got my first 419 mail at my launchpad address :o
<dhana013> Hi guys I new child for kernel compilation, I have to compile i5 processor and pae support please guide me..
<dhana013> what is linux-generic-pae    linux-headers-generic-pae witch is kernel package linux-generic or linux-headers
#ubuntu-kernel 2013-06-24
 * apw yawns ...
 * ppisati enjoyes the morning breeze...
<apw> ppisati, forget to get dressed this morning ?
<nikolark> Hi, I'm looking to specify the right package for bug #1172852 . USB keyboard and mouse does'nt work on clean 13.04 usb-install. Got it working by chrooting in after and installing linux-image-extra. But this package is intentionally left out by the ubuntu-installer said a friendly guy in #ubuntu-bugs.
<ubot2> Launchpad bug 1172852 in linux (Ubuntu) "USB keyboard and mouse don't work" [High,Incomplete] https://launchpad.net/bugs/1172852
<nikolark> should the needed drivers be in the main package instead of linux-image-extra? 
<apw> nikolark, installing onto a real system?
<apw> nikolark, installing onto a real computer i would expect linux-image-extra to get installed, as i would expect linux-image-generic to be installed which pulls it in
 * henrix -> lunch
<apw> nikolark, so this was on a desktop install.  could you check on that system whether you have linux-image-generic installed please: run 'dpkg -l | grep linux-image'
<nikolark> apw: desktop install on a real system
<nikolark> linux-image-generic is installed
<apw> nikolark, so it is odd that -extra would be missing then as that is dependant on it
<apw> nikolark, could you get me 'apt-cache show linux-image-generic  | grep Depends:'
<nikolark> i might have installed it after..
<apw> nikolark, ok could you attach /var/log/installer/syslog and /var/lib/dpkg/status to the bug please
<nikolark> yup, apt-cache reports linux-image-generic depends on linux-image-extra (and firmware)
<nikolark> sure apw :-)
<nikolark> apw: attached.
<apw> nikolark, ok thanks, seems this is ubiquity issue, and maybe known, will update the bug
<nikolark> thanks :-)
<nikolark> apw: could you see anything in the installer-syslog?
<apw> the installer guys think this is an instance of bug 1070427
<ubot2> Launchpad bug 1070427 in ubiquity (Ubuntu Quantal) "Ubiquity removes kernel headers, fails to build nonfree drivers" [High,Triaged] https://launchpad.net/bugs/1070427
<xnox> nikolark: the installer log points that Quantal image was used, yet at the top of the bug report it says "13.04".
<apw> yeah that is rather inconsistant...
<rtg_> apw, I wonder what kind of reception 'UBUNTU: SAUCE:' patches will receive upstream ?
<apw> rtg_, indeed, i replied to it with the title update ... stupid error
<rtg_> ah, hadn't seen the reply
<apw> but yeah, /me == dork
<rtg_> I chuckled and prepared to watch some fireworks
<apw> i'll send up another couple today, and try to not re-dork myself
<apw> rtg_, i pushed up a fix or two for overlayfs to our unstable tree
<apw> rtg_, and in the process of closing it for upload to the PPA
<rtg_> apw, saw that. now we have a packaging error that I need to go figure out (as soon as I'm done cruising LKML)
<apw> rtg_, packaging issue?  i'll leave closing it be then and let you do that
<rtg_> apw, have you done a full build yet ?
<rtg_> ack
<apw> rtg_, i've only done binary-generic's for testing
<rtg_> something goes awry when packaging headers. can't e too complicated.
<rtg_> be*
<apw> hmm i think i've made headers though
<apw> rtg_, oh but they appear to be empty headers :)  have fun
<rtg_> uh huh. thanks :)
<nikolark> apw: xnox: I just realized the logs are from when I reinstall with 12.10, after 13.04 did'nt work out of the box
<nikolark> sorry about that
<rtg_> apw, I think the saucy unstable packaging failure is because of the aufs update. missing ubuntu/include/linux/Kbuild and ubuntu/include/uapi/linux/Kbuild. test building now.
<apw> rtg_, doh, check those in as an UBUNTU: ubuntu: AUFS3 -- fix' and we can merge them down later
<rtg_> apw, I think I'll just fold it into the aufs update so that there is no bisect build error. seem reasonable ?
<apw> rtg_, no cause they are framework not the update
<apw> rtg_, oh actually it just depends what is in them
<apw> if they are actually full of stuff then yes, they need to go in the update
<apw> bah, i need to revisit the updater once you are done there
<rtg_> apw, The Kbuild files have a single line that mentions aufs-type.h
<apw> probabally the update then, and i'll take a todo to check into that at next update
<rtg_> apw, I put some whammy on saucy master-next. shall we take it for a spin for the day before uploading ?
<bjf> rtg_, let me know when you have some debs to test
<rtg_> bjf, ack
<apw> rtg_, sounds good
<rtg_> bjf, apw: http://kernel.ubuntu.com/~rtg/3.10.0-0.6/
<rtg_> bjf, also, I pushed a patch to kteam-tools to update the development kernel version from 3.9 to 3.10
<bjf> rtg_, ack
<bjf> rtg, so far your kernel is running fine. heat looks normal
<rtg_> hmm, [   12.911676] BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
<rtg_> [   12.911691] IP: [<ffffffff8156e572>] od_set_powersave_bias+0x92/0xc0
 * rtg_ -> lunch
<apw> rtg_, wifi per
<apw> rtg_, wifi perhaps ?
<rtg_> apw, huh ?
<apw> id_set_power_bias sounded wifi'y to me
<rtg_> od_set_powersave_bias
<apw> oh no cpufreq ... ooops
<rtg_> cpu govenor
<rtg_> apw, I sent a debug patch upstream showing what was NULL
<rtg_> apw, look for 'od_set_powersave_bias: NULL pointer dereference' in LKML
<apw> ta
<rtg_> apw, 3.10.0-0.6 uploaded. I'm outta here a few minutes early for an appt.
 * rtg_ ->EOD
#ubuntu-kernel 2013-06-25
 * apw yawns
 * RAOF pours in the bees.
<hyperair> D=
<hyperair> remind me never to piss RAOF off.
<RAOF> hyperair: apw loves his steaming hot cup of bees in the morning!
<apw> always ... who wouldn't
<hyperair> ._.
 * apw has another
 * hyperair mentally substitutes bees with honey and gets back to work.
 * smb looks worried at the backlog
<apw> heh ... you need another cup, all will be well
<smb> apw, Not with bees
<hyperair> heheh
<apw> smb, no stamina
<ppisati> something like this?
<ppisati> ipmitool -U admin -P admin -I lanplus sol deactivate -H 10.193.36.223
<ppisati> Error: Unable to establish IPMI v2 / RMCP+ session
<ppisati> Error: No response de-activating SOL payload
<ppisati> Shard or Sauron's black tower?
<ppisati> http://i.dailymail.co.uk/i/pix/2013/05/25/article-2330926-035AC82700000514-219_634x358.jpg
<ppisati> if you search for sauron black tower, one of the result is this one:
<ppisati> https://www.google.it/search?q=sauron+black+tower&um=1&ie=UTF-8&hl=en&tbm=isch&source=og&sa=N&tab=wi&authuser=0&ei=2lXJUbDyHYfbOc7XgegN&biw=1680&bih=938&sei=3VXJUZn8NoK9OcDKgdgN#facrc=_&imgdii=_&imgrc=rBh7xQc1NTrk0M%3A%3BPjQwtlrVfPEppM%3Bhttp%253A%252F%252Fi.imgur.com%252FuEXRuQx.jpg%3Bhttp%253A%252F%252Fwww.reddit.com%252Fr%252Fpics%252Fcomments%252F17v41h%252Fnew_tower_of_sauron_in_warsaw_poland%252F%3B640%3B360
<ppisati> brb
 * ppisati -> out for lunch&c
 * cking reboots
<rtg_> apw, updated saucy master to Ubuntu-3.10.0-0.7
<apw> rtg_, thanks .. bad andy
<rtg_> apw, noticed it when rebasing saucy LTS
<apw> rtg_, it was all stuck in britney land, but as it is stuck there for the alpha, we figured it was worth re-uploading it anyhow
<rtg_> wfm
<apw> rtg_, good point, not sure if we autopkgtest those or not
<rtg_> apw, so far I'm just uploading saucy LTS to a PPA
<rtg_> https://launchpad.net/~ubuntu-x-swat/+archive/s-lts-backport
<apw> rtg_, yeah i shuld have done it ... got distracted trying to work out why my
<apw> gpg password is not being forgotten
<rtg_> no worries. are you at blue fin today ?
<apw> rtg_, not today, i think i am going to be thurday
<rtg_> apw, hmm, I thought the boss would be there by now
<apw> i think late today, but i don't have the data now i think about it
<rtg_> apw, did you get a response from miklos on your overlayfs patch ?
<apw> none
<apw> i am going to be sending the other two up in a sec, i'll batch them up together and send 'em again
<apw> without the prefix :)
<apw> i find him completly non-responsive, often it ends up in his tree all attributed right
<apw> but without any sign of comment
<rtg_> huh
<apw> yeah he is not the best at responding
<apw> i'll re-send a nice stack and see what he does
<apw> i suspect his attitude is one reason it has not gotten in already
<rtg_> does not play well with others :)
 * rtg_ relocates. back on in a bit.
<apw> rtg_, i see jj has dropped his pull requests on the list ... are you or am i handling them
<rtg_> apw, I can do it if you're working on something.
<apw> rtg_, i am not overly busy, so you decide
<rtg_> apw, split 'em. I'll do grouper/maguro. you do mako/manta ?
<apw> rtg_, ACK
<apw> rtg_, OMG have you seend the SIZE of these things
<rtg_> apw, of the AA patch ? not yet.
<apw> rtg_, one um-heap-big-patch representing some 70 patc
<apw> patches for mako ... 
<rtg_> apw, yeah, well he did say he'd glommed them all into one patch.
<apw> rtg_, oh i am sure it makes sense for this use case, but uggg it is massive
<rtg_> its not like we have to worry about regression. it'll either work or it won't.
<apw>  40 files changed, 5927 insertions(+), 1017 deletions(-)
<apw> rtg_, oh i agree, and thank $god for that give the epic nature of the change
<rtg_> apw, note that he said its completely untested, so buyer beware :)
<apw> jjohansen, hey ... if i add this apparmor patch and upload it, whats the likelyhood it'll keep working :)
<apw> rtg_, FYI jj has bust the UBUNTU SAUCE prefix (missing a :) in the one i have here
<rtg_> apw, ack
<jdstrand> apw: fyi, the mako one we both tested a lot. I am testing the 3.1 right now and will do 3.0 after that. jj tested all these a bunch (he is afk atm, so I'll let him respond when he gets back)
<rtg_> apw, I finally got tired of fixing the changelog by hand, so I went and figured out why insertchanges wasn't working.
<apw> rtg_, i assume they are all fixed, given it is working for me
<rtg_> jdstrand, well, that sounds pretty good.
<apw> (what was it)
<apw> jdstrand, sounds above averagly checked, so we can build test it, perhaps do a dirty boot test on the devices and upload it
<rtg_> apw, an insufficient regex and looking in the wrong changelog
<apw> rtg_, nice ...
<jdstrand> rtg_: the grouper kernel is 3.1. create_socket(socket.AF_BLUETOOTH, socket.SOCK_DGRAM, None) (in python) fails with 'socket.error: [Errno 93] Protocol not supported'. is that intended or should I file a bug?
<jdstrand> rtg_: heh, I meant to say 'the grouper kernel is 3.1, right?'
<rtg_> jdstrand, yep, it is 3.1.10
<jdstrand> sorry
<jdstrand> well, that wasn't the actual python call (I can give it if you wish), but the question is the same
<rtg_> jdstrand, heck if I know. is bluetooth even supported on the N7 ?
 * jdstrand shrugs
<jdstrand> ogra_: ^
<apw> rtg_, thanks for fixing cross on these braches as well ... beam
<ogra_> rtg_, jdstrand, yep n7 has BT
<jdstrand> k, I'll file a bug then
<ogra_> yeah
<ogra_> tell cyphermox about it 
<rtg_> ogra_, what is the BT device then, BT_HCIUART ?
<ogra_> i'm sure he'll like to know
<ogra_> rtg_, iirc ttyHS2 
<jdstrand> rtg_: oh, if you are just going to fix it now, do you need a bug?
<rtg_> jdstrand, yep, lest I forget :)
<jdstrand> k
<ogra_> note that it needs to be initialized by android with some broadcom tool iirc
<ogra_> (brcm_patchram...)
<cyphermox> mako or maguro?
<ogra_> grouper
<ogra_> :)
<cyphermox> ahh yeah I just saw
<jdstrand> jjohansen: fyi, 3.1 tested fine (except for the above 'network bluetooth' failure due to the kernel config)
<cyphermox> I expect it's BT_HCIUART yes, with ttyHS2
<rtg_> cyphermox, CONFIG_BT_HCIUART=y for grouper
<cyphermox> yes
<rtg_> jdstrand, so this may not be a kernel problem
<cyphermox> so do you mean you still don't have bluetooth after running brcm_patchram_plus?
<rtg_> jdstrand, ^^
<jdstrand> this was what failed: http://paste.ubuntu.com/5798585/
<cyphermox> jdstrand: you can install brcm-patchram-plus-nexus7 to get the right binary and config, it should start with upstart
<cyphermox> right
<cyphermox> without running that firmware patching utility, you won't have a bluetooth device
<jdstrand> I see
<ogra_> well, the android contaianer should do that
<jdstrand> ogra_: it may. I was actually testing said kernel and config compiled for amd64
<jdstrand> so like rtg_, sounds like there is no bug\
<jdstrand> s#\##
<ogra_> you were what ?!?
<ogra_> you built the grouper kernel for amd64 ?
<jdstrand> ogra_: fun huh? I didn't, jj did so we could test his apparmor backport for said kernels so that we didn't have to rebuild phablet images to test the kernel
<jdstrand> his bits weren't hardware specific
<ogra_> you can just use abootimg to put the zImage in place
<jdstrand> jjohansen: ^
<ogra_> no need to rebuild anything 
<jdstrand> ogra_: but, that doesn't help when we don't have maguro or manta hardware
<ogra_> indeed
<jdstrand> anyway-- it was just a way to test the non-hardware specific code
<jdstrand> rtg_, ogra_, cyphermox: thanks
<rtg_> apw, you know the -d trick for dpkg-buildpackage, right ? 'dpkg-buildpackage -d -B -aarmhf -us -uc' in an amd64 chroot.
<apw> rtg_, yep i do pretty much the eqivalent, but it only works so easy now you have fixed the CROSS_COMPILE bits
<apw> rtg_, do we have 4.6 crosscompilers ?
<rtg_> apw, thank infinity for that little pearl. I'm building grouper under precise since that is the last release of the gcc-4.6 arm cross compiler
<apw> rtg_, oh ick :)
<rtg_> or maybe it was slangasek, I forget.
 * apw notes that the two 3.4 based bracnhes use different compilers
<rtg_> yep
<apw> that seems, unexpected
<rtg_> well, rsalveti figured it out by regressing the compiler until it produced a bootable kernel.
<apw> rtg_, yeah i am more expecting them both to have had to be 4.6
<apw> i am not supprised tis the compiler at all
<apw> rtg_, now mako == N4, and manta == N10 yes ...
<rtg_> apw, well, grouper builds so I think I'll just upload it. phablet.ubuntu.com is my decoder
<apw> i am sooo scared of dumping them on the wrong devices
<rtg_> apw, oh, you're actually gonna boot test ?
<apw> rtg_, i am not convinced it is necessary, but i have the device right here
<rtg_> apw, so do I. *sigh*, I guess I ought to DTRT.
<apw> rtg_, as much as anytrhing i am doing it to make sure this laptop has the requisite bits to do the do
<rtg_> oh, I've flashed mine a bunch of time
<apw> rtg_, yeah so have i using the other laptop, but i lost a battery and am on a differnt one
<rtg_> apw, it always takes 30 min or so to download a new image. I'm not lucky enough to have fiber to my front door like you Brits. I still live in a 3rd world country (Inet wise)
<apw> heh ... it does for me now we have ipv6 at cdimage ... sigh
<apw> rtg_, ok both of mine boot just fine on those new kernels
<rtg_> apw, just now test booting grouper
<rtg_> seems happy enough
<rtg_> apw, does AA print a banner in dmesg ?
<apw> rtg_, there is toooo much vomit on mine to know, i h
<apw> i have init crap in my whole dmesg
<rtg_> as do I
 * apw will blame jj if its not enabled :)
<rtg_> I'll go with that.
<apw> rtg_, see if you have /sys/module/apparmor
<rtg_> yep
<apw> rtg_, right ... pushed to the repo
<apw> rtg_, uploading next 
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jdstrand> rtg_: is https://bugs.launchpad.net/touch-preview-images/+bug/1191197/comments/7 a kernel thing of an image thing?
<ubot2> Ubuntu bug 1191197 in touch-preview-images "kernel config does not support ufw firewall" [Undecided,Confirmed]
<jdstrand> s/of an/or an/
<rtg_> jdstrand, likely an image thing since all ufw support is module based.
<ogra_> yeah, we have no way to ship modules 
<jdstrand> hrm
<ogra_> well, we probably do under /vendor ... but our tools would have to learn about that
<jdstrand> ogra_: even on a flipped image?
<ogra_> we imply dont have a kernel package installed
<ogra_> *simply
<jdstrand> ogra_: what would be the right package to file this against?
<ogra_> jdstrand, can you file a bug ? we might be able to do some linking or so
<ogra_> https://bugs.launchpad.net/touch-preview-images/+filebug
<ogra_> assign it to me
<jdstrand> ogra_: I was thinking of adding a task to that bug, since it is all related
<jdstrand> https://bugs.launchpad.net/touch-preview-images/+bug/1191197 (has a touch-preview-images task)
<ubot2> Ubuntu bug 1191197 in touch-preview-images "kernel config does not support ufw firewall" [Undecided,Confirmed]
<ogra_> well, putting the modules into place has to happen on the android side during android image build
<ogra_> not sure how we can reflect that in a task :)
<jdstrand> ogra_: so, different bug?
<jdstrand> ok, new bug
<ppisati> brb
<apw> ogra_, do we not have a project or package for the android side we can use
<ogra_> not atm, xnox works on packaging the android bits then we'll have a package 
<apw> ogra_, if he has ever put that in a PPA we have a package we could use :)
<ogra_> until then, just a toplevel bug on touch-preview-images must do
<ogra_> we dont even have the toolchain in the archive i doubt there is a PPA :)
<apw> heh
<xnox> ogra_: well, atm i'm pretty certain that our cross-toolchain doesn't build anything useful, whilst linaro-4.8 cross-toolchain does. trying to figure out how the two are different.
<ogra_> isnt our cross toolchain based on the linaro 4.8 one ?
<xnox> there is a toolchain in ~ubuntu-toolchain-r/test
<ogra_> yes, the one doko did 
<ogra_> i thought that was the right one 
<xnox> ogra_: it is, but busybox build with linaro-4.8 prebuild -> runs in a adb shell, with doko's it segfaults =)
<ogra_> oh
<xnox> (where linaro gcc-4.8 prebuild, is the one I downloaded /imported locally into phablet tree same way linaro-4.7 was)
<ogra_> you indeed test that in recovery mode not in a flipped image :)
<xnox> ogra_: good point. i think it was adb normal boot of an unflipped image.
<ogra_> good
<ogra_> dont try on flipped :) 
<ogra_> no android accessible there 
<xnox> yeah....
<xnox> at the moment, i'd like to rebuild toolchain from scratch and see busybox not segfault.
<xnox> otherwise there isn't much to do really.
<jdstrand> ogra_: fyi, bug #1194549. adjust summary/description as necessary as I may not have captured it in the best way
<ubot2> Launchpad bug 1194549 in touch-preview-images "netfilter module support is missing on phablet images" [Undecided,New] https://launchpad.net/bugs/1194549
<ogra_> i made the title a bit more generic
<rtg_> apw, do you remember which TRACE config option ureadahead needs ? Is it CONFIG_FUNCTION_TRACER=y ?
<apw> rtg_, gawd i would think so, but i ahve never had to be sure
 * rtg_ wonders why CONFIG_FUNCTION_TRACER=n for armhf
<rtg_> apw, hmm, needs PATH_DEBUGFS "/tracing" for sure
<apw> b sconklin 
<ppisati> rtg_: performance hit? wild guess
<rtg_> ppisati, dunno
<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 June 25th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 2nd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * rtg_ -> lunch
 * ppisati -> gym
<ppisati> back later
 * rtg_ -> EOD
#ubuntu-kernel 2013-06-26
 * henrix -> (early) lunch
 * ppisati -> out for lunch
<apw> rtg_, are we applying ABI always bump to the nexus kernels btw 
<rtg_> apw, nope, but I also don't expect any DKMS drivers on those platforms either.
<apw> figured not as we don't do in place updates as yet either
<rtg_> apw, another reason not to worry about ABI bumps
<apw> cking, http://sourceforge.net/mailarchive/message.php?msg_id=27424447
<ppisati> back in 10
<apw> http://comments.gmane.org/gmane.linux.kernel.containers.lxc.general/1806
<gQuigs> NFS debugging was enabled in kernel 3.2 in precise.  Why is it disabled in more recent kernels?  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1127319
<ubot2`> Ubuntu bug 1127319 in linux (Ubuntu) "rpcdebug: /proc/sys/sunrpc nodes do not exist" [Wishlist,Triaged]
<rtg_> gQuigs, CONFIG_SUNRPC_DEBUG does not even exist in Precise (v3.2.47)
<apw> rtg_, perhaps the things under that were on by default before the option
<apw> gQuigs, if they are under _DEBUG we would tend to turn those off unless they are requested on the assumption they have no value and are likely to be costly
<rtg_> apw, 'git grep SUNRPC_DEBUG' does not exist
<apw> rtg_, i was wondering (only) whether the code was there before and 'removed' and put under that new config later
<apw> (in later releases)
<rtg_> apw, oh, perhaps
<gQuigs> in 3.2 if you don't turn the kernel debugging flags on it does nothing.. 
<gQuigs> AFAIK
<rtg_> apw, ok, it appeared in Quantal
<rtg_> apw, hmm, we should likely turn that on in 3.5 plus subsequent kernels
<apw> rtg_, works for me, we can wack it on in saucy and see what implodes
<rtg_> apw, little chance if regression since its not enabled until a sysctl is tickled.
<gQuigs> awesome, thanks! 
<apw> rtg_, i have pushed a config change to grouper, but will hold it pending the resolution on this AA thing from jjohansen 
<rtg_> apw, ack
<hallyn_> apw: hey, offhand to you see any glaring problem with http://people.canonical.com/~serge/0001-procfs-add-pidnr-file.patch ?  
<apw> hallyn_, sounds and looks reasonable to me
<apw> hallyn_, though TMPBUFLEN sucks in general
<hallyn_> apw: yea if it wasn't already there i wouldn't have used it
<apw> hallyn_, it smells :)
<hallyn_> suppose I could so something like log_10(MAX_UINT) + 1 :)
<hallyn_> but i'm averse to having a patch die a languishing slow death because of extraneous changes, no matter how well intentioned
<hallyn_> hm, i didn't add the original one did i?
<hallyn_> wow, pre-dates git.  but i'm pretty sure that was janak
<hallyn_> <cringe>
<hallyn_> apw: this is too funny.
<hallyn_> https://lkml.org/lkml/2005/1/27/181
<hallyn_> maybe i'll send a separate patch to fix that up
<hallyn_> cking: hey, regarding the email you just sent, the patch I just pasted above gives you mapping of pids outside of containers :)
<hallyn_> http://people.canonical.com/~serge/0001-procfs-add-pidnr-file.patch that is
<hallyn_> I'm about to send it to lkml
<cking> hallyn_,  that's darn useful - thanks!
<hallyn_> (will reply in a few mins, my muttrc isn't properly expanding aliases on this laptop.   sigh)
<cking> ack
<hallyn_> d'oh.  Missed a " at the start of a name
<rtg_> ppisati, tangerine is going offline soon for a rack change
<ppisati> rtg_: ack
 * rtg_ -> lunch
 * rtg_ -> EOD
<srwarren> Is there a location in source control for Ubuntu packaging of the kernel, or are only the *.dsc files available for download from launchpad?
<srwarren> I'm hoping to just "git clone" (or perhaps "bzr clone") some URL, and get the source for https://launchpad.net/ubuntu/saucy/+source/linux/3.10.0-0.7, or at least a history that contains that
<bjf> srawarren, which series? git clone git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
<bjf> srawarren, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<srwarren> bjf, ah - that sounds like what I want, thanks
#ubuntu-kernel 2013-06-27
<bps> i have a realtek nic (lspci: https://dpaste.de/MZXfY/ ) that silently stops working after use, and i found a patch that worked ( https://lkml.org/lkml/2013/4/8/28 ) only the fix doesn't appear to be in the kernel: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/realtek/r8169.c#n4192
 * ppisati -> out for lunch
<skaet> rtg,  for Alpha 1 are there any highlights that should be mentioned with the current kernel version?
<skaet> rtg_, ^
<rtg_> skaet, you're still on a 3.9 kernel, right ?
<rtg_> https://www.linux.com/news/software/linux-kernel/716624-6-key-new-features-in-linux-39
<rtg_> http://www.phoronix.com/scan.php?page=news_item&px=MTM2MDU
<skaet> rtg_, The Alpha 1 Saucy Salamander snapshot includes the 3.9.0.7 Ubuntu Linux kernel which is based on the the upstream v3.9.7 Linux kernel. 
<skaet> or at least that's my understanding.
<rtg_> that is true
<rtg_> apw, note that, when next you rebase saucy, there will be  a conflict against drivers/net/ethernet/atheros/alx (which was just merged in Linus' repo)
<skaet> rtg_,  if there's nothing specific that the kernel team wants to highlight, will choose a couple of highlights from those links then
<rtg_> apw: I had been carrying a linux-next patch for that
<rtg_> skaet, thats fine with me. 3.9 was temporary. we're ultimately gonna end up on 3.11
<skaet> rtg_, gotcha.  thanks
<apw> rtg_, ack thanks
<apw> rtg_, i did an upload on manta today to disable aa by default; seems they have no control over the command line in that boot loader [sigh].  something to keep in mind
<rtg_> apw, ack, saw that
<ppisati> brb
<Kano> hi, can somebody update linux-firmware against firmware.git
 * rtg_ -> lunch
<infinity> smb: Your current linux-ec2 appears to have two changes beyond just the rebase.  You want to go about verifying that those do what you wanted them to do, and set the verification testing task on the tracking bug so it can progress?
#ubuntu-kernel 2013-06-28
<infinity> BenC: When you get a chance, can you test the new ppc kernel on one or two of your freescale platforms?  Seemed happy on my IBM kit.
<smb> infinity, I may do when I could stop holding my breath for some progress by others on other things. Bah!
 * apw yawns
 * ppisati reboot
<ppisati> almost
<apw> smb, heads up ... luks encrypted partitions seem to have a size ... so when you have an fs in an ecrypted lvm one needs to resize the volume, the luks, and the fs
<smb> apw, nifty
<apw> i had assumed that it would be 'sizeless' that it would be encrypt data, write to block number +1
<apw> and not care how big it is, seems not
<smb> Hm, there seems to be a resize for cryptsetup plain... not found anything obvious for luks prefix yet
<xnox> apw: it is sizeless, but it needs a tiny bit of header padding in the beginning.
 * xnox did a successfully shrank encrypted lvm without causing data loss.
<apw> xnox, there is a 'resize' command at the cryptsetup which 'collected wisdom' (read googling) implies you should run that, so e2fsresize smaller, cryptsetup resize smaller, lvm resize smaller
<apw> xnox, but it sounds like you missed the middle step and still have your data :)
<apw> smb, do you know what happens if you snapshot an LV and then resize the original smaller
<smb> apw, no
<apw> smb, i assume there is a way to take a snapshot and promote it to a full LV with its own blocks ?
<xnox> well I had: partition -> crypt -> lvm -> volumes. So yeah, i did e2fsrezise, vgresize, and partition resize. I guess i should have used cryptsetup resize =))))))
<smb> apw, Sure you can dd it...  :-P
<smb> xnox, vgresize ? not lvresize?
<smb> hm, eh probably implies
<xnox> smb: implies, i had enough spare extends.
<xnox> or whatever lvm measures it's vgs in.
<smb> xnox, just was wondering about one of the things sounding odd without being clear which. If all volumes are in the vg and that has enough spare extents, one would not need to resize any fs
<xnox> smb: depends where physically extends are allocated for used volumes. So for me i had ||||||||________|||____|| so I had to move extends in the VG to make it look like |||||||||||||___||______ and then I was able to shrink it to |||||||||||||___||
<smb> apw, For that dreaded vg on loop and dd on snapshot bug I would be glad if there was a quick snapshot to full lv (or actually any). But as the snapshot is reference to origin plus delta it is not that simple
<smb> xnox, Sure that just needed to ensure that all lvs only use extends before the parts you want to reduce. If there is enough free that is just moving some blocks and making the mapping a bit more complex. As long as the lvs can stay the same e2fsresize is not needed. So you had the dm device that crypt produces as a pv for lvm?
<smb> (just wondering whether that did not also require a crypt resize)
<xnox> i believe yes. just the default encrypted install which d-i / ubiquity produce.
<smb> Ah, hm that may actually have been part->lvm->lvs->crypt... (though I would need to do an install again to be sure) Somehow I think it was a bit hard(er) to convince lvm to expect pvs in device-mapper volumes... 
<xnox> smb: there is a single crypt device which contains one vg which has volume for rootfs and a volume for swap.
<xnox> that's how d-i/ubiquity does it in automatic partitioning.
<xnox> but one can in the manual partitioning setup the scheme you described.
<apw> rtg_, i am just prepping a saucy upload, as there is some doubt over the overlaysfs fixes, so i am reving it to v18
<apw> (as overlayfs is key for the CDs)
<rtg_> apw, ack
<apw> rtg_, it'll carry your debug change as well
<rtg_> that one wasn't all that important
<apw> nope but it may as well go in, otherwise there is nothing and that is probabally good, so i can just touch test this
<rtg_> apw, did 3.10.0-0.7 break the dailies ?
<psivaa> hello, I reported bug #1195710 that is impacting multi-lvm saucy server installations of today's image
<ubot2`> Launchpad bug 1195710 in linux (Ubuntu) "'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 " [Undecided,Confirmed] https://launchpad.net/bugs/1195710
<apw> rtg_, i don't think it did, but rather than there be any risk of it being wrong i think i'll update it
<psivaa> a failed installation is active in one of our servers, aldebaran if anyone would like to look into
<psivaa> this appears to happen during kernel installation stage
<apw> psivaa, have we had any good installs on anything today ?
<psivaa> apw: yes, apart from multi-lvm on amd64 server images, the other server installs are good
<psivaa> apw: desktop had some other ubiquity issues though
<apw> psivaa, ok good thanks
<apw> psivaa, and this only happens  on complex lvm installs, what does multi-lvm mean in this context
<smb> funnily most of that backtrace is about ext4
<apw> smb, i know odd isn't it, odd that it only appears on lvm
<rtg_> seems like an indirect op's pointer got corrupted ?
<smb> psivaa, It might help us a lot if you could elaborate in the bug what multi-lvm actually means in the way of setup
<apw> smb, and only on 64 bit as well
<psivaa> smb: ok, ill try to include that info
 * henrix -> back in 15 mins
<apw> there is only one BUG in that routine
<apw> so i guess it has to be that one, which implies we found non-preallocate space on the list to free
<psivaa> apw: so it appears that this is occurring in i386 as well, saw that on the second attempt. ill update the bug
<apw> psivaa, but only on lvm, very odd
 * apw can see no way overlyfs could be in involved in that error at least
<apw> psivaa, in hte i386 failure, the same stack trace ?
<psivaa> apw: yes to my eyes, but please see http://pastebin.ubuntu.com/5807755/
<apw> it may be hinting at one layer deeper, but feeling related
<apw> a slightly different manifestation, but here we are complaiing that osmething on the never allocated list is marked as deleted
<apw> psivaa, and nothing like this on non lvm testing
<psivaa> apw: i'm running a couple of more tests just to confirm that. will update once the tests finish
<rtg_> apw, want me to wrap up Ubuntu-3.10.0-1.8 while you are messing with that LVM bug ?
<apw> rtg_, i have pushed the tag, and built some test kernels
<rtg_> ok, np
<apw> and have it ready to upload, so prolly i can just ocmplete it
<rtg_> fireaway
<apw> i have the source package ready to go now, just do this boot test, and touch test overlayfs
<rtg_> hallyn, USER_NS seems to be getting close in 3.10. Only XFS_FS is left in the UIDGID_CONVERTED dependencies. Perhaps by 3.11 ?
<ppisati> brb
<hallyn> rtg_: perhaps.  Dwight at oracle is actually trying to get that done right now, but the xfs folks have some problems...
<hallyn> most of all, they're wondering what to do with bulkstat
<rtg_> hmm, well its getting close to the 3.11 merge window.
<hallyn> yeah :(
<hallyn> does anyone here have terrific insights into xfs?
<hallyn> and its peculiarities?
<apw> rtg_, do you have saucy linux-meta sitting unpushed ?
<rtg_> apw, checking
<apw> rtg_, ta
<rtg_> apw, ok, pushed
<apw> rtg_, thanks
<psivaa> apw: no other server installations see this bug not even single lvm. only multi-lvm tests installations are failing. Incidentally only the failing (multi-lvm) installations use "d-i base-installer/kernel/override-image	string linux-generic-pae"
<psivaa> all the other installations (which pass) use linux-server
<apw> psivaa, but in both of those cases linux-generic-pae and linux-server are meta packages to linux-generic, so there sould be no difference in the version running
<apw> (in saucy)
<apw> psivaa, so multi-lvm just means use LVM and to split root into various partitions
<psivaa> apw: yes as far as i understood.
<psivaa>  "d-i partman-auto/choose_recipe select Separate /home, /usr, /var, and /tmp partitions" in multi-lvm as opposed to "d-i partman-auto/choose_recipe select All files in one partition (recommended for new users)"
<apw> which doesn't sound overly differnet really
<psivaa> ok, i have run the latter a number of times, 6 in total but could not see the failure
<apw> and of the multi-lvm ones whats the failure rate there
<psivaa> apw: 3 out of 4
<apw> o.O is all i can say to that
<apw> psivaa, which image are you testing, so i can test the saem one, and do i see you testing in kvm yes?
<psivaa> apw: yes that's in kvm and today's saucy server images (20130628)
 * smb -> EOW
 * henrix -> EOW
 * rtg_ -> lunch
 * rtg -> EOW
<phillw> Hi, a very quick question... Someone installs 10.04 via the netboot / mini.iso from, say, http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-i386/current/images/netboot/ and then drops a DE onto it. They will get no security updates for the DE, but they will they still get kernel updates?
#ubuntu-kernel 2013-06-30
<jxself> Any idea why this change in the 3.9.8 mainline build? http://home.romanrm.net/pics/2013/2013-06-30T165006Z-ll398.png
<jxself> PARAVIRT_GUEST is only the root option
<jxself> Turning it off also disabled lots of dependant features all over the .config
<jxself> Caused some downtime on a number of Xen VPSes
#ubuntu-kernel 2014-06-23
<amitk> cking: just reading about stress-ng. In CPU compute, can it generate %loading that is frequency invariant? IOW, 50% load at 2GHz != 50% load at 1GHz
<cking> amitk, it's not intelligent like that, it just breaks the load into time slices of idle and loaded, so it ignores the clock freq
<amitk> cking: ok, we've modified cyclictest for that behaviour and are current modifying rt-app to do the same
<amitk> cking: but the memory load might be interesting, I'll check it out
<cking> amitk, if you see any niches where I can add more stressors let me know, I'd like to make stress-ng more useful over time
<amitk> cking: sure, I'll play around a bit. Our focus hasn't been finding the boundaries (stressing) but more about making it easy for sched maintainers to be able to simulate typical mobile (android) behaviour on a std. linux distro - e.g. mp3 playback, web browsing.
<amitk> cking: but i can see stress-ng being useful to setup thermal constraints, for example 
<cking> amitk, indeed, stress-ng was more like "how can I fully load a machine and see how much I can make the CPU and cache toasty"
<cking> and the old stress tool wasn't really useful enough for what I was playing with
<cking> mainly because I was also tinkering with thermald and I wanted to see if I could make that kick on a hot intel box
<rbansal1> Hi
<rbansal1> Dose someone know, when I am trying to compile Linux 3.14 kernel I get the following error : ERROR: modinfo: could not open /lib/modules/3.14.0/modules.dep 
<rbansal1> Why this error is coming ? I tried on Ubuntu and CentOS and on both I get almost similar error
<rbansal1> Any clue on this issue will be helpful. 
<rtg> apw, I pushed the rebase to 3.16-rc2. I guess we ought to start doing some testing this week.
<apw> rtg, yeah, it must be getting close, we should get it in the CKT PPA soon so jibel can test against it
<rtg> apw, ah, right. I'll do that today.
<rtg> BenC, don't forget to give some love to powerpc64-emb
<BenC> rtg: Right, on it, thanks
<rtg> BenC, do you think you'll get it figured out this morning ? I'll wait on the first upload if so.
<BenC> rtg: Iâm hoping so. Iâll know more withing about 15-30 mins
<rtg> BenC, cool, will wait for a bit then
<BenC> rtg: This is a compile error, correct?
<rtg> BenC, yup.
<rtg> BenC, link error IIRC
<BenC> rtg: Any chance you already have a log of the error?
<rtg> BenC, hmm, probably not. all of my local build tests are fairly ephemeral. it wouldn't take but 10 minutes or so to recreate it.
<BenC> rtg: I have a build startedâ¦
<BenC> rtg: I have the fixâ¦one-liner and only affects 85xx (freescale)
<rtg> BenC, cool, thats the best kind. I'll probably look at it and think, "Why couldn't I have figured that out ?"
<BenC> rtg: The error you saw related to smp_(give|take)_timebase, correct?
<BenC> *smp_generic_(give|take)_timebase
<rtg> BenC, yup, thats the one
<BenC> rtg: Patch sent to kernel-team
<apw> smb, hey ... we pulled a lot of VIRT* things =y is that still appropriate
<smb> apw, I would assume yes. At least as long as we want to have boot essentials in for virt and bare-metal at the same time.
<smb> apw, Of course you could ask me to do that part of the conf review. :)
<apw> smb, heh no as long as they are needed i am happy
<smb> apw, At least I am under the impression they were. Though things can silently change, so I would not want to bet money on it
<infinity> smb: I'm willing to bet a lot of that stuff can be modular, but that requires more than just IRC handwaving. :P
<infinity> Like, actual testing.  On multiple arches.  Ick.
<smb> infinity, A lot _can_ be modular. The problem with them was that (again at least at some point) there was nothing that would trigger them auto-load
<infinity> smb: Well, being auto-loaded is implied in my "can be modular" statement.  If something needs to be manually loaded, that's a no-go.
<smb> infinity, Ah ok. So yeah. Some may have changed but agreed, I neither would want things to change without very well tested well.  
<infinity> "very well tested well".
<smb> textual deja-vu
<smb> Or not remembering the word one typed a second ago
#ubuntu-kernel 2014-06-24
 * apw yawns
<smb> apw, morning
<smoser> hi. rtg how sure are we that 3.15 is the version number for utopic kernel.
<smoser> ie, is it possible at all that that would be 3.16 as major.minor ?
<smoser> just curious as i'm writing 3.15 somewhere.
<apw> we are sure it won't be 3.15
<smoser> bah.
<rtg> smoser, have you been living in a cave ?  :) we've been advertising 3.16 for several months.
<smoser> i do live in a cave, yes.
<smoser> and uname -r gave me bad information ;)
<smoser> htanks for setting straight.
<rtg> smoser, we have a 3.16 kernel staged in ppa:canonical-kernel-team/ppa
<smoser> well, uname didn't tell me that.
<infinity> smoser: uname isn't a good predictor of the future.
<smoser> patches welcome
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 1st, 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.
<marvin24> just testing  3.16.0-0-generic_3.16.0-0.2 on arm, and f2fs refuses to load from initramfs
<marvin24> submit_bio and blkdev_issue_flush symbols are missing somehow
<marvin24> all other modules load fine
<marvin24> I compiled 0.1 locally a few days ago and all worked fine
<marvin24> the 0.2 is from the ppa
<marvin24>  depmod -aev -F /boot/System.map-3.16.0-0-generic 3.16.0-0-generic | grep f2fs shows nothing
<marvin24> stupid marvin24 loaded the old kernel 8-|
#ubuntu-kernel 2014-06-25
<geekintime> Where would I direct this: Having extremely long waits returning from pcap_findalldevs.  Lookup of system interfaces is taking a LONG time.  tcpdump is also seeing this problem.  
<geekintime> What would cause the pcap_findalldevs function to take >60 seconds to return? Seeing this in my own application and tcpdump.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<ubuntu-harrassed> please introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.
<hyperair> ubuntu-harrassed: if you've gotten a valid ISO, there isn't really a chance for a MITM attack while installing ubuntu
<hyperair> also, spamming a channel (and the wrong one at that) isn't going to get you anywhere
<ubuntu-harrassed> http://packetstormsecurity.com/news/view/24247/2012-RCE-Bug-Is-Still-Highly-Exploited-In-Targeted-Attacks.html
<ubuntu-harrassed> hyperair
<ubuntu-harrassed> http://packetstormsecurity.com/news/view/24238/NCA-Gameover-Zeus-Malware-Fix-Deadline-Passes.html
<ubuntu-harrassed> http://packetstormsecurity.com/news/view/24164/National-Crime-Agency-Warns-About-Botnet-Epidemic.html
<ubuntu-harrassed> scammer hyperair
<ubuntu-harrassed> #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA vvv
<ubuntu-harrassed> #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA 
<ubuntu-harrassed> #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA 
<ubuntu-harrassed> #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA 
<ogra_> !ops
<ubot5> Help! lamont, zul, T-Bone, mdz, or jdub
<ogra_> ah, to late 
<ogra_> (and that ops list should be updated)
<rtg> tseliot, there is a 3.16 kernel in https://launchpad.net/~canonical-kernel-team/+archive/ppa for you to test against.
<tseliot> rtg: thanks, any chance we can run automated tests against it first. My plate is kind of full now. apw ^^
<smb> rtg, Good morning. Do you remember how AMD cpu microcode happened to end up in linux-firmware? At least in Trusty there now seems the problem that linux-firmware does not come with the scripts to cause the microcode to load and installing amd64-microcode will get rid of not only linux-firmware but also the meta-packages related (linux-generic, etc)
<rtg> smb, AMD ucode is in the upstream repo
<smb> rtg, ok, so we "just" inherited the problem :/
<rtg> smb, plus amd64-microcode is a multiverse package. 
<smb> rtg, Same as intel-microcode
<rtg> right.
<rtg> which I sort of keep up to date.
<smb> That why I am surprised the AMD files are in linux-firmware
<rtg> I suppose 'cause AMD requested it, and provided the right licensing
<rtg> IIRC the Intel ucode is not licensed so that it can be included in main
<rtg> smb, so you're saying the AMD ucode doesn't load from a udev rule ?
<smb> Just a pity that the firmware files alone aren't helping. As for as I can see one needs initramfs hooks to copy them there and then do some sysfs magic
<smb> At least the seperate package comes with those. But let me make sure before whining too loud
<smb> rtg, Unfortunately my AMD server currently is busy in Xen...
<rtg> tseliot, automated test builds are already happening: https://jenkins.qa.ubuntu.com/view/DKMS/view/U%20KT-PPA%20-generic/
<infinity> rtg: To be fair, the AMD microcode license doesn't look main-compatible either.
<infinity> rtg: There's no explicit right to modify, only to copy.
<rtg> infinity, I've never read it for content. my eyes start to bleed
<infinity> rtg: It's short. :P
<infinity> rtg: Anyhow, if we want to operate under the assumption that people might want the multiverse packages because of the initramfs hooks (ie: they actually do something), we might want to strip the files from linux-firmware and drop the P/C/R.
<rtg> IIRC Intel's license limitation is that it is a click-thru 
<rtg> infinity, lets make sure that it really _isn't_ working first. 
<infinity> rtg: Well, unless the kernel somehow loads it...
<rtg> there is that early load mechanism
<tseliot> rtg: ok, thanks I'll have a look at them soon
<smb> infinity, rtg, I am not sure AMD and Intel use the same mechanisms. If I understand the script right on AMD its echoing a 1 into /sys/devices/system/cpu/microcode/reload
<infinity> smb: Yeah, I just got there too.
<infinity> smb: Same mechanism for both, just checked.
<smb> thats nifty... and kind of unexpected... but good
<infinity> smb: So, it doesn't NEED to be in initramfs, since you can patch a live system, it could just as easily be an init script.  But it needs to be *something* that triggers the reload when the files are available.
<smb> Right, so the hook could be supplied in a generalized way. When being careful not to clash with what the Intel package provides right now
<rtg> looks like the intel-microcode package has an initramfs hook
<infinity> rtg: They both have identical hooks, except for the intel/amd check.
<infinity> Which makes sense, since it's the same maintainer.
<rtg> so, why are the AMD bits in linux-firmware ?
<infinity> rtg: That's what we were asking you. ;)
<rtg> well, I didn't put 'em there
<smb> Prolly because the debian maintainer for that is not the same?
<rtg> we could dump the bits from linux-firmware and fix the packaging for amd-microcode such tat its doesn't remove the world.
<infinity> The versions in linux-firmware and amd64-microcode are identical, I just checked.
<smb> rtg, its actually in linux-firmware
<rtg> smb, the conflicts ?
<infinity> rtg: amd64-microcode does nothing wrong, it's just linux-firmware's conflict that breaks it.
<smb> rtg, yes I assume so
<rtg> well, thats easy enough to fix.
<smb> since the other package only conficts with intel-microcode
<infinity> Well, the P/C/R, all three should be dropped.
<infinity> smb: It only conflicts with an old version of intel-microcode.  They can co-exist now.
<rtg> thats twice you've mentioned P/C/R. wtf is that ?
<smb> infinity, Ah yeah the <<2
<infinity> rtg: Provides/Conflicts/Replaces
<infinity> rtg: Sorry, Debian shorthand.
<rtg> packaging weenies.
<rtg> I'm happy to just rip out all the AMD bits in favor of the external package that carries the right hook scripts.
<infinity> rtg: That sounds like the sane plan to me too.
<rtg> alright, gimme a bit. smb - is there an existing bug moaning about amd-microcode conflicts with linux-firmware ?
<infinity> rtg: FWIW, both licenses are about the same as far as restrictions (except the Intel one also says you can't disassemble it).
<infinity> rtg: Either would be fine for restricted, if we ever decide to go that route, neither is fine for main.
<smb> infinity, I think that says the other too
<smb> rtg, No not yet 
<smb> but I can make one
<rtg> smb, please do and I'll follow up
<infinity> smb: Oh, you're right, the AMD one also whines about disassembly, I skipped that line. :P
<smb> infinity, So rtg was right about the blurring effect. :)
<rtg> which is a good reason to get it out of main
<infinity> rtg: Right, I think we should tear it out for licensing reasons, the fact that it also fixes the multiverse package is just a happy accident. ;)
<rtg> serendipitous indeed
<infinity> rtg: I seriously can not picture you saying "serendipitous" out loud.
<rtg> in truth it was muttered under my breath with a bit of sarcasm
<smb> rtg, Actually it seems there already might be one: bug 1181145
<ubot5> bug 1181145 in linux-firmware (Ubuntu) "linux-firmware conflict with amd64-microcode" [Undecided,Confirmed] https://launchpad.net/bugs/1181145
<rtg> smb, seems like I've already stuck my foot in mouth in that bug
<smb> rtg, Heh, yeah I was just noting that fact
<smb> :)
<rtg> and recently even.
<smb> Meh, last year
<tseliot> rtg: fglrx-updates is a false failure, in that it succeeded but it was reported as a failure
<rtg> tseliot, have you bugged jibel about it ?
<tseliot> rtg: I'll check them all first
<infinity> rtg: I think that bug was about file overlaps, and you fixed it (but without closing it) by adding the P/C/R. At least, that's how I read it.
<infinity> rtg: But reusing it to remove the offending files and the P/C/R seems fine by me. ;)
<infinity> Err, wait.  That last comment is two days ago.
<infinity> Weird.
<infinity> Whatever.
<rtg> yeah, Richard Laager has a point
<infinity> Oh.  It's people running precise, that's why.
<smb> infinity, Meh, you know people suddenly coming back 
<rtg> infinity, this should probably ripple back to Precise as well.
<infinity> rtg: precise has the file overlap without the Conflict, which is admittedly even worse than the trusty situation.
<infinity> So, yeah, let's add us some tasks here...
<rtg> refresh
<infinity> Which I can't do because someone added and removed some in the past, breaking LP's tiny mind.
<infinity> Oh, or you added them while I was clicking.
<infinity> Hah.
<jibel> tseliot, fglrx-update fails because PACKAGE_NAME is not defined in dkms.conf
<jibel> tseliot, it is set to PACKAGE_NAME="#DRIVERNAME" 
<jibel> well, it is defined but not the name of the module
<tseliot> jibel: that would be in the dkms.conf.in though, the dkms.conf should be fine, or dkms wouldn't work
<rtg> infinity, https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1181145/comments/5
<ubot5> Ubuntu bug 1181145 in linux-firmware (Ubuntu Utopic) "linux-firmware conflict with amd64-microcode" [Undecided,In progress]
<infinity> rtg: Heh, I beat you to the same comment, it looks like.  Whee.
<rtg> infinity, get out of my bug and go do something else
<rtg> like reviewing openipmi for precise
 * smb whistles the high noon theme
<infinity> rtg: Done and rejected.
<rtg> ah, thanks for being so gentle
<infinity> rtg: Rejected for the version number, but the rest looks a bit messy too...
<jibel> tseliot, /usr/src/fglrx-updates-13.350.1/dkms.conf has #DRIVERNAME in it
<rtg> infinity, I couldn't figure out how to not generate config.sub et al
<jibel> tseliot, I don't use BUILT_MODULES_NAME[#] because it is not always defined
<infinity> rtg: Build without cleaning, if debian/rules clean is doing that.
<rtg> it is
<infinity> rtg: Add '-nc' to your dpkg-buildpackage/debuild.
<rtg> seems obvious in retrospect. duh!
<tseliot> jibel: if so, that would be a bug, and dkms should fail. I'm downloading the deb package to check
<tseliot> jibel: it is indeed a bug. I'm surprised that even works. Let me fix that
<jibel> tseliot, good, I'm glad the test found a bug :)
<tseliot> jibel: exactly, thanks
<tseliot> jibel: will you have to run the test against the new release or will it happen automatically?
<jibel> tseliot, it's automatic when there is a new kernel or a new version of a dkms module
<jibel> tseliot, if it doesn't, let me know and I'll check
<tseliot> jibel: this is just a new package revision i.e. 2:13.350.1-0ubuntu3 (vs the ubuntu2 rev)
<tseliot> ok
<jibel> tseliot, that's fine it should be automatic
<tseliot> jibel: great
<jibel> tseliot, https://jenkins.qa.ubuntu.com/job/dkms-utopic-release_canonical_kernel_team_ppa-generic-fglrx_updates/15/ passes on amd64 but fails on i386
<jibel> FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol '__static_cpu_has_safe'
<tseliot> jibel: hmm... maybe the made a symbol GPL only... I'll look into that, thanks
#ubuntu-kernel 2014-06-26
<rtg> tseliot, did you and jibel ever figure out the build issues with 3.16 and fglrx-updates ?
<tseliot> rtg: yes, and I fixed that issue yesterday, although there are more issues I need to take care of
<rtg> tswas just looking at the jenkins dashboard. i386 is still red.
<rtg> tseliot, ^^
<tseliot> rtg: yes, exactly. It's an issue with a GPL only symbol. I'll figure that out
<rtg> ok
#ubuntu-kernel 2014-06-27
<tseliot> apw: hey, apparently c6b406919288a617815f710175da20f3fca72065 (which fglrx includes) makes fpu-internal.h use static_cpu_has_safe() which is gpl only -> fglrx fails to build... Any ideas?
<apw> tseliot, use static_cpu_has directly ?
<apw> and cross your fingers
<tseliot> apw: I wish it were that simple... it probably comes from a call to __save_init_fpu(), and maybe  static_cpu_has_safe() is called somehow by it
<apw> i am not sure what to think at that point
<tseliot> it must be use_xsave
<tseliot> apw: so __save_init_fpu-> save_init_fpu -> use_xsave -> static_cpu_has_safe -> BOOM
<tseliot> apw, jibel: fglrx (i386) seems to fail too but it's misreported as successful
<jibel> tseliot, I'll restart it, it's probably the bug with ssh I fixed 2 days ago
<tseliot> jibel: thanks
<jibel> tseliot, now it fails
<tseliot> jibel: perfect
<tyhicks> rtg: hey - I saw you just applied jj's patches to the touch kernels
<tyhicks> rtg: I wanted to let you know that I have a few more config changes coming your way in a couple hours
<rtg> tyhicks, yup.
<rtg> k
<rtg> no rush, I won't upload this pile until next week
<tyhicks> ok
<tseliot> rtg: I think I've fixed nvidia-304-updates, fglrx, fglrx-updates, so now nvidia-173 is the only package left for me to port (which I'll do next week)
<rtg> tsok, I'm gonna wait on -rc3 anyways and test some more. I've had somestrange FS corruption on 2 machines with -rc2
<rtg> tseliot, ^^
<tseliot> rtg: ok, even better then
<tseliot> jibel: please make sure that nvidia-304-updates, fglrx, fglrx-updates are tested
<rtg> apw, wasn't this your fix ? https://bugs.launchpad.net/ubuntu/+source/linux-lts-quantal/+bug/1269053/comments/26
<ubot5> Ubuntu bug 1269053 in linux (Ubuntu Saucy) "IBM Domino 'bindsock' cannot bind to ports <1024 since recent kernel 3.5.0-45.68" [Medium,Fix released]
<jibel> tseliot, ok, I'll check that.
<tseliot> thanks
<apw> rtg it cirtainly rings a bell
<rtg> apw, kinda hate to see that regress after you worked so hard to fix it
<apw> rtg, no that was fixed upstream in fact ... hmmm
<apw> rtg, i'll have a look at it
#ubuntu-kernel 2015-06-22
<sturmflut2> cking: Ping
<cking> sturmflut2, hiya
<sturmflut2> cking: Hey, I ran into an oddity while running eventstat on arale: sometimes the "[swapper]" kernel task shows up as PID 1. Any idea about how that is even possible?
<cking> sturmflut2, is that running in a container?
<sturmflut2> cking: Not that I know of, and that wouldn't explain it. Strangely enough this is even present in the in-kernel Documentation, https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/timer_stats.txt#n56
<cking> sturmflut2, well, since eventstat uses /proc/timer_stats that's where i'm getting this info from, so it's coming from the kernel and not eventstat per se
<sturmflut2> I've never seen it on my Ubuntu 15.04 desktop, but on arale (3.10.x kernel) it's always there
<cking> sturmflut2, no idea of the top of my head
<cking> s/of/off
 * cking has a poke around at the source
 * ogra_ finds the etra used/reported memory even more curious than that PID thing
<ogra_> *extra
<ogra_> since that will for sure have some heavy impact
<cking> hrm,  the timers_stats code hasn't radically checked between those kernels, so  I really don't know.
<cking> s/checked/changed/
<cking> doh
<cking> I suspect the comm field (that contains the short process name) for init has been cached after it got created before the process could change it. so just ignore it, it's definitely the correct pid
<ogra_> cking, well, probably it sees the swapper from the lxc container (where another init runs that is presented as PID1 inside the container (and outside with a different PID to the host system)
<cking> ogra_, that too, event most probably has issues with containers
<cking> ..mainly because it has to go on what timer_stats provides as the pid
<cking> which can be different for the pid inside the container, argh
<ogra_> fun, aint it ? :)
<cking> but the cached comm field probably explains the mismatch as shown in the documentation
<cking> when dealing with /proc, it's going to be racy :-/
<JinqiuYu> hi, there.  I try to compile stree-ng on my cent os host,  and I get " perf.c:77: error: âPERF_COUNT_HW_REF_CPU_CYCLESâ undeclared here (not in a function)"  errors , how can I fix it ? 
<sturmflut2> cking, ogra_: But the swapper is an in-kernel process. It's the kernel scheduler. It is not part of a container, and I just now found a couple of boxes here at work that don't even run containers, but also show a swapper as PID 1
<cking> sturmflut2, as I mentioned earlier, "I suspect the comm field (that contains the short process name) for init has been cached after it got created before the process could change it. so just ignore it, it's definitely the correct pid"
<sturmflut2> cking: Yes, something like that probably. But my fear is that if something like this happened and nobody noticed the mismatch, can we trust the rest of the output on arale's kernel
<cking> sturmflut2, what do you mean "rest of the output"? that's a wide statement
<sturmflut2> cking: If there is one location in the kernel where something allocates a timer, and at this place the wrong information is put into a data structure, can we be sure that it happens only at exactly this one place?
<sturmflut2> cking: I too think it's just this one, but it raises a bit of suspicion
<cking> sturmflut2, the wrong info is not cached, just that it changes after it got cached. the PID is sane, just the cached comm field my be out of date. but really, since we key off the PID anyhow, it's academic on the name, since the PID is what matters
<sturmflut2> cking: I don't think it's the PID that's sane, the full entry in my case is the following
<sturmflut2>     1.00     1 [swapper/0]     start_bandwidth_timer     sched_rt_period_timer
<sturmflut2> start_bandwidth_timer and sched_rt_period_timer are actual kernel functions in the scheduler
<sturmflut2> if the PID is sane, then all of "Task", "Init function" and "Callback" are wrong
<sturmflut2> cking: And PID 1 is upstart, which doesn't seem to register a single timer
<sturmflut2> cking: I'll have a look at the kernel source code, maybe I can find a definitive answer
<cking> sturmflut2, if I had 36 hours in a day, I'd look into it, but for now, this does seem just like a minor issue compared the the other stuff ogra was mentioning
<sturmflut2> cking: :)
<cking> if there was a process that was eating 50+ wakeups per second, I'd sweat over it
<sturmflut2> cking: Let's combine your 24 hours and my 12 hours a day, then we can do it ;)
<cking> why not your 24 and my 12 :-)
<sturmflut2> cking: Well, Canonical does not (yet) pay for my services ;)
<sturmflut2> So I need this thing called "real work"
<cking> sturmflut2, ok, me too, canonical pays me at the moment to do some higher priority kernel file system related work ;-)
<ogra_> cking, just tell them snappy uses ext4 only anyway :P
<ogra_> who needs other filesystems :P
<cking> ogra_, the server and cloud folk perchance
<ogra_> pfft 
<manjo> apw, you know how on tangerine when you schroot it lets you build directories in your home dir ? How was the chroot home linked to user home dir ? 
<infinity> manjo: It's a bind mount.
<manjo> infinity, thanks.. yes I figured out what I was missing in my profile 
#ubuntu-kernel 2015-06-23
 * chmj walks in
<chmj> so I bought a Dell XPS 13 (9343) without checking linux compatibility
<trippeh> YOLO
<chmj> gives me a reason to get back to hacking though 
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<cread> Morning all - I think I've just been bitten by an XFS bug in the 3.13 line...
<cread> http://paste.ubuntu.com/11762693/
<cread> Seen this twice in the last 24 hours on two seperate machines
<cread> So it's probably not hardware...
<cread> They've been running for ages on 3.8.0-44 without a problem, started doing this right after I upgraded to 3.13...
<apw> cread, have you filed a bug against the kernel with that detail ?
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 30th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
<cread> apw, not yet - could not find anything matching, thought I'd check here first...
<cread> Off to file the bug...
<mwenning> hi kernel guys, I'm trying to find the version of megaraid_sas module for ubuntu 14.04, 14.10, etc.   
<mwenning> Is there somewhere that has the modinfo info for each release?
<arges> mwenning: I think that information is only contained in the built ko. But if you just want the MEGASAS_VERSION, you could just look at the source
<arges> mwenning: so either look at the source, or modinfo on the module.
#ubuntu-kernel 2015-06-24
<Martyn> Hello all.
<Martyn> network interface issue I'm having : 	When you have a network interface and an aliased interface ( e.g. bond0 and then bond0:0 ) and then put a service on... what determines which interfaces "answers" the call from another machine?
<Martyn> I have the address 10.90.1.1 on bond0 ( netmask 255.0.0.0.0 ) and 10.90.0.1 on bond0:0 ( mask 255.255.0.0 )
<Martyn> when I have a service bonded to all interfaces, how does the kernel determine which interface "answers"?
<Martyn> and is there a way to tell ubuntu to prefer the bond0 interface over the aliased one?
#ubuntu-kernel 2015-06-25
<oere> Dear all, I followed the steps described at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel but I was not able to modify it so the generated kernel debs have an append local version extension ... I'm using pdebuild --use-pdebuild-internal and used 'dch --local +test' before building it ... is there any other usable documentation ... the background is to patch the kernel to support Beignet on Haswell (https://01.org/zh/beignet/download
<arges> infinity: so for bug 1454687, the nx 842 module needs to be loaded in the initramfs to enable usage with zswap. If modules=most doesn't set that in initramfs-tools, is there an 'ubuntu' way to append to that anywhere?
<ubot5> bug 1454687 in linux (Ubuntu Vivid) "add NX 842 hw compression patches" [Medium,In progress] https://launchpad.net/bugs/1454687
<infinity> arges: Except that we enable zswap after we pivot, not in the initramfs.
<infinity> arges: This is another case of "bug submitter doesn't use Ubuntu, and assumed we do it the same way as RedHat".
<arges> infinity: yea. i got that part when I saw dracut
<arges> : )
<infinity> arges: We do have an initramfs zswap hook but, confusingly, we only use it in the installer.  And I've been meaning to consolidate it with zram-config.
<infinity> arges: But if these need to be loaded pre-zswap (but otherwise, not necessarily loaded at all), they belong conditionally in zram-config.
<arges> infinity: ok
<infinity> arges: Err, assuming zram and zswap are the same thing.  Maybe they're not.
<arges> infinity: the other thing is the bug commenter said he's working on patch to make it change it requireing to be done at boot time
<arges> so maybe wait for those patches
<infinity> arges: Ahh, zswap != zram.  How confusing.
<infinity> arges: Okay, so, maybe the compressors do need to be in the initrd for this, much like lz4 is.
<infinity> arges: So, I'd grep initramfs-tools for lz4, and add these in the same spot.
<arges> infinity: ok i'll target that package too
<infinity> Which, of course, is being pulled in as a dep, so isn't mentioned at all in the source. :P
<infinity> arges: Anyhow, it'd be the auto_add_modules function.
<arges> infinity: ok i see it
<infinity> arges: Don't worry about arch-restricting, it ignores modules that don't exist, IIRC.
<infinity> arges: Though, easy to test my assertion on an x86 machine.
<arges> infinity: yup. was going to ask. 
<arges> infinity: does this seem reasonable? http://paste.ubuntu.com/11775115/
<infinity> arges: Probably.  You'll need to do some testing to make sure that (a) it's needed, and (b) it actually does something.
<infinity> arges: I, however, might sleep.  I've been up since yesterday morning.
<arges> infinity: ok
#ubuntu-kernel 2015-06-26
<bjf> arges, i'm looking at the commits for LP: #1448269 ... there's no comment that testing of the change has been positive
<ubot5> Launchpad bug 1448269 in linux (Ubuntu Utopic) "qemu guest hangs on nested kvm startup with host kernel oops" [Medium,In progress] https://launchpad.net/bugs/1448269
<arges> bjf: i tested it on my own machine
<arges> bjf: i'll comment on the bug
<bjf> arges, has hallyn_ been able to verify your fix?
<arges> bjf: i don't think he's had the time to try it yet
<hallyn_> no i have not.  i trust if it fixed it for arges it'll work for me
<bjf> hallyn_, ack
<hallyn_> well, i should be able to do it today (no long-running tests going on that server right now)
<bjf> hallyn_, we'll want it verified when it goes into the kernel for the next cycle
<hallyn_> when will htat be
<bjf> hallyn_, in approx. 2 weeks
<cyphermox> hi, could I convince someone to enable shipping dm-service-time as well in multipath-modules? I'm merging multipath-tools 0.5.0  and it seems to have changed the default path selector to that
<arges> cyphermox: is this another udeb package you're requesting?
<cyphermox> it's a udeb but it wouldn't be a new one
<cyphermox> arges: I think adding dm-service-time alongside dm-round-robin in multipath-modules would be sufficient, even if it slightly bumps the size
<cyphermox> (I can deal with the increased since in d-i, if the change is significant enough to break the image building)
<arges> cyphermox: ok. can you file a bug for this so i can track it?
<cyphermox> arges: certainly
<cyphermox> do you agree with shipping both in general, or would you rather shipping just one?\
<arges> cyphermox: i would have to look at it, but I think it would be worth discussing with smb too when he's around. As he's been looking at multipath stuff more
<cyphermox> ok
<cyphermox> arges: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1469240
<ubot5> Launchpad bug 1469240 in linux (Ubuntu) "Please ship dm-service-time in multipath-modules" [Undecided,New]
<arges> cyphermox: and i take it this needs to end up in vivid too at some point 
<arges> cyphermox: or is this just for wily
<cyphermox> arges: wily only, we're not yet at pushing a new multipath-tools on vivid.
<arges> cyphermox: ok great
<arges> cyphermox: ok sent patch to ML. let everybody review it there
<cyphermox> arges: cool, thanks.
#ubuntu-kernel 2016-06-27
<i915> is there away in ubuntu to enable kernel debugging kdb ? If so how do you run it 
<i915> I just am curious if ubuntu's kernel enables this feature or does it take a recompiling to uses on ubuntu
<apw> i915, yes we have kgdb enabled in the kernle
<i915> how does one execute this
<i915> or get the kernel debugger to run on apt-get i have downloaded before the kgdb package but it was just a front end gui like DDD for gdb. Couldn't get it to run or do anything with the kernel like set breakpoints ,..etc
<apw> normally you need to talk to the kernel like over a serial console
<apw> or a network console, so you are talking to it from "outside"
<apw> to debug from inside you usually use ftrace and family
<i915> What i want to do is step thru the kernel code first locally thru the asm . I know if i want to debug kernel with c language code showing i will need to recompile the DWARF in but thats for later trying now just to focus on setting up kgb to attach to the kernel and set a break point to step thru the asm code
<apw> right so you need to do that from outside
<i915> i cann't run a debugger on the same computer and attach to the kernel vmlinuz directly or set a break point in memory at  01000000-01660531 : Kernel code
<i915>   01660532-019b3e7f : Kernel data
<i915>   01a96000-01b7cfff : Kernel bss
<i915>   
<apw> what would it run "on" if the kernel is stopped waiting for you
<i915> from user mode gdb allows me to attach to any ps -A process pretty much so i was assuming you could just find the  function in kallsyms and attach from there
<apw> i915, but a userspace process has somewhere to run separatly from your gdb
<apw> you are asking to stop the entire kernel, to do that you need to do it from somewhere that isn't under the control of the kernel
<apw> which is why mostly we debug using ftrace as you can do that from inside
<i915> O will its not built in to the kernel that the debug registers would have a seperate kernel debugger program that ran with the kernel... now i am confused about how remotely debugging would work the kernel would still break so there has to be an external kernel program to send it remotely and step thru the kernel itself
<apw> there is a shim in the tty code which is very very thin which can control the kernel
<apw> i think you need to go read some background on how this stuff works, there must be google resources on this
<i915> like a gdbserver program equivalent running at kernel level ... and if that was the case why couldn't it just print to the local monitor instead 
<apw> that isn't really how things work, it is not impossible it could, but i don't beleive it does
<apw> it isn't something people actually do very often
<apw> so you'd not want to dedicate space for such a thing
<i915> Also i have seen it done where somebody presses a special sysrq key in there terminal and it goes to a blue screen kdb debugger how is that working or setup because it looks like it debugs the kernel on userland?
<i915> Ok if i do it remotely where do you configure the remote settings to add a remote 192.168.1.102:7893 so that i can have my remote machine talk to this debugging network service
<i915> I would imagine in grub 
<apw> i915, i would imagine on the kenrel command line indeed
<i915> because its got to run as soon as the kernel is booting from grub
<apw> not something i have done in a very long time
<i915> ok i am just going to stick with virtual machine kernel debugging until i can figure out how to get it on the bare hardware to run remote kernel debugging. My problem is now getting grub to boot the kernel into a workable os... i always get kernel opps for initrd or init process issues or the extra stuff the kernel needs to boot workable... but i have everything where it should be so confused still working thru that issue.. onc
<i915> e i get that issue taken care of i think i will beable to set up kernel debugging thru serial or network tcp/ip just thru settings in grub or the bootloader
<cyphermox> I'm trying to run an install from a yakkety server daily iso; modprobe -v usb-modeswitch complains that the key is not available -- did we somehow break loading all modules, fail to sign stuff for the udebs, and is that a known issue?
<apw> udebs may well not be signed ...
<apw> that sounds like a problem
<apw> will think about that tommorrow
<i915> i915 is the kernel driver for the graphics card but now it is also the driver that the /dev/fb0 uses i can uses fbset to set the mode and configuration for /dev/fb0 ...so kind of wondering if this settings going to affect my X11 env or other graphical env i thought /believe /dev/fb0 is used by X11 as well
<mjg59> i915: No, X doesn't use the framebuffer interface (unless you're using the fbdev driver)
<mjg59> i915: the drm layer exposes its own modesetting interface that X uses
#ubuntu-kernel 2016-06-28
<i915> well the one i am using is using i915 for it kernel driver
<i915> so ya my special case it is 
<i915> also my cases if probably no ware near as general as others have it
<i915> weird question when compiling a module the make file uses path /lib/modules/$(shell uname -r)/build which points to /usr/src/linux-headers-3.13.0-32/ looking to the Makefile you see lines like this  obj-$(CONFIG_VGA_ARB)  += vgaarb.o
<i915> obj-$(CONFIG_VGA_SWITCHEROO) += vga_switcheroo.o  
<i915> I get what those make files are doing just including object files.... but where are these object files cann't find them anywhere so i am thinking they are zipped up in .a file or something
<i915> The kernel headers are not worth anything without the object files to link against... i do see alot of .ko files under the /lib/module/... but those are for the already built modules that can be insmod 
<mjg59> i915: The .o files aren't shipped, because they're just intermediates between the .c and the .ko files
<mjg59> The headers give you the information you need to build modules from source
<i915> so why do the Makefiles have them in there or is that just left behind makefiles for the kernel itselfs code
<i915> Yes but the headers need to be associated with some type of kernel level library to build the modules that the header file uses?
<mjg59> Those are the makefiles from the kernel, yes
<i915> or another words what are these o files for. Because if the modules are just using the .ko files that see and the top level makefiles for target modules searches the .ko file directory then what was the .o files 
<mjg59> There is no kernel level library
<mjg59> The .o files are generated from building the .c files. A single .ko may include several .o files.
<mjg59> They're just an intermediate during the build process
<i915> yes but for building just modules you could remove all those makefiles with .o and you should still beable to build your LKM
<mjg59> Sure, but ensuring that you remove those makefiles while not removing any that are required for the build process isn't really worth it
<i915> LKM from what i am gathering is just using the .ko files in the /lib/modules/3.13.0-32-generic/kernel/ subdirectories
<mjg59> Yes
<i915> well then one could archive .ko into one big allmodverion3.6.2.a then take your module header files and integrate it with user land functions i would imagine as well 
<mjg59> No
<i915> unless the insertion insmod the output would fail or the structure of the LKM 
<mjg59> Kernel code can't be executed in useland
<mjg59> It calls into functions that only exist in the kernel itself
<mjg59> And which can't be reimplemented in userspace
<i915> yes so when insmod tries to install the LKM even if it was to compile with user land header/library functions it would fail to install into the kernel level
<i915> because the user land libraries wouldn't work with kernel LKM
<i915> i am guessing thats the reason but i see no reason why a LKM cann't load a .so or a kernel level  program call a user land library  is there no load library  that it can uses
<i915> Maybe it has to do with the way the LKM and its resources are loaded into memory that it cann't access user land libraries but to me it seems the kernel should have a method to call any function ,process, or program in memory... hell it can get a task or runqueue to access any program resources 
<i915> So i am still left wondering what the real reason is why LKM or any kernel level program cann't get access or uses userland libraries or functions... in my eyes the kernel has complete control of memory and thus all it needs to do is locate the function in it... it also has complete control of the process so there you go you should beable to call upon anything in memory
<i915> Maybe because the userland users a loader program for the .so and so since its lower then the loader program it would need to go thru the loader first to dynamically load the userland libraries thats my only guess
<i915> But if the libraries where user libraries where specifically loaded for the LKM start up then you should also thru LKM or kernel functions beable to access the loaded library in memory by passing the loader
<i915> bypassing
<i915> and thus being able to call upon userland libraries from kernel mode
<i915> Of course the only problem would be the mapping of the .so file functions to proper address maybe this part would actually take a page allocated , many other things that essentially would be just creating a loader at the kernel level for user land libraries
<i915> Also the .got .plt ,...etc parts of the .elf for userland would have to be workable so you would need to somehow port a ld.so or some mechanism for that...
<i915> this is probably the issue to
<i915> maybe like the __jump_table section cann't be easilly converted to the got plt
<i915> curious i was think again about LKM and if one statically compiled in user library function to it why would this not work the user land functions would be self contained in the LKM no dependences on .so
<apw> if the module includes all of the code no reason any not, but most libraries assume they are running on top of the standard C library and expect to link to those kinds of things
<apw> so most userpsace libraries would never find their deps
<apw> not that it is clear why you would want to include all this userspace in a kernel module in the first place
<ogra_> modprobe gnome 
<ogra_> ;)
<JanC> well, there used to be a kernel module that implemented a http server because supposedly it was slightly faster than userspace http servers
<JanC> it was also incredibly bad for security ;)
<ogra_> who cares about security anyways .. thats so last century ... 
<i915> curious i see alot of kworker/u8:1 based stuff in ps -A are these workqueues created by the kernel
<i915> or are they tasklets created by the kernel I would imagine tasklets and softirq won't show up in ps -A on workqueues because workqueues are truely the pthreads version of the kernel i imagine
<apw> kworker are the kernel contexts for work queuesyes
<i915>  kthreadd , ksoftirqd, kworker ,khelper kind wondering what the difference in purpose of these and where these all created by workqueues
<arges> https://github.com/0xAX/linux-insides/blob/master/interrupts/interrupts-9.md has some good info about these topics
<i915> ksoftirqd looks like it is a queue of interrupts when the interrupts come in to fast to process . But is there a way other then workerqueues to create a kernel process or is workqueues / tasks they way kernel threads are made in general
<i915> No forget it apparently i am wrong kthread functions with task_struct is the equivalent of pthreads .When would one uses workqueues over kthreads then ?
<i915> ok well i get a way to filter out kernel threads and user threads ps -fHuroot | awk '$3!=2' or ps -fHuroot | awk '$3==2' so i can distinguish between user and kernel threads provided the pid didn't change for your linux you can to or do it by the symlink -->exe in proc dev. Of course now my question is determining what the purpose of these different kernel process are . Next step is /proc/pid for them but not sure yet if it wil
<i915> l give me a way to figure out what they are meant for
<i915> Hum i am wondering if LKM are part of the kthreads process it looks like some are there but the names are different maybe they are contained with in the kernel threads trying to link the distinction of kthreads with LKM's
<i915> so its like kthreadd spawns all kernel threads i.e kworker threads but there is additional ones i still have to look into later tonight to get them all down would be nice to know where the LKM's leave in which on of these kernel threads/process if any.
<i915> because the insmod insertion into the kernel so i thought it would be a process/thread but maybe its just a fixed static code block that is hooked with irq hander routines to call the module functions. Or maybe the modules are normally just to set up irq for a callback handler that does the device driving not fully sure of all this yet
#ubuntu-kernel 2016-06-29
<i915> Just rambling main question is does anybody given a task_struct know how to distingish a kernel task from a user task /process
<Laibsch> considering bug 1529917 how are trusty users supposed to install the mainline kernel?
<ubot5> bug 1529917 in linux (Ubuntu) "mainline kernel fails to install in trusty" [Medium,Triaged] https://launchpad.net/bugs/1529917
<Laibsch> Trusty gcc 4.8 lacks fstack-protector-strong
<apw> not even waiting half an hour ...
<ricotz> apw, hi, while yakkety is targetting 4.8, will there still be a 4.7 kernel packages?
<apw> ricotz, likey briefly yes
<ricotz> apw, I see
<apw> much as there is meant to be 4.6 ones too, though we have yet to achieve that
<ricotz> apw, yeah currently using "inux - 4.6.0-7.8" which could need an update to 4.6.3
<apw> ricotz, yeah i think someone is doing that "now"-ish
<ricotz> ah, alright :)
#ubuntu-kernel 2016-06-30
<rsalveti> apw: opened bug 1597573 and bug 1597574 for amd overdrive, including the patches
<ubot5> bug 1597573 in linux (Ubuntu Yakkety) "Network installer fails to detect network on AMD Overdrive (ARM64)" [Undecided,Confirmed] https://launchpad.net/bugs/1597573
<ubot5> bug 1597574 in linux (Ubuntu Yakkety) "Config: missing AMD Seattle platform support" [Undecided,Confirmed] https://launchpad.net/bugs/1597574
<rsalveti> still testing if something else is still missing
<lamont> 4.4.0-24-generic kernel (xenial), trying to talk ipv6 through a firewall running 3.13.0-91-generic (trusty), and it unearths issues with ipv6 neighbor discovery??  http://paste.ubuntu.com/18170606/ (on the firewall, I see the icmp6 echo reply come in, which tells me that's why were doing neighbor solicitation)  the trace is from the xenial host
<lamont> apw: ^^ was it you who said you saw something similar?
<lamont> and with ipv6 hurting, google is not talking to me.
<apw> i have been seeing some oddness, but it all seems to have gone happier for me recently
<lamont> just don't reboot the firewall....
<apw> my firewall is not ubuntu so i won't see that any more
<lamont> ah.. this is one that happens to me everytime I reboot the (trusty) firewall, and then it's broken until I start really poking at it to debug it, and then it starts working for reasons unknown until I reboot again
<lamont> apw: neighbor discovery, the last 4 of the ff02:: address have bit 3 flipped?
<apw> i am not sure what the algoithm for workgin out the multicast group to broadcast at is
<apw> lamont, no that is correct, you just happen to have fexx:yyyy as your address, but the multicast group addres is :ffxx:yyyy
<apw> it is only dropping in three octets worth
<apw>       Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
<lamont> ah, ok
<lamont> 'twas a headscratcher there.
<apw> lamont, had me going for a bit there, especially as you have to follow through like 3 rfcs to find the info
<lamont>     inet6 2601:282:8100:3500:24c:40ff:fe1a:c570/64 scope global mngtmpaddr dynamic 
<lamont>        valid_lft 299sec preferred_lft 119sec
<lamont> apw: ^^ fwiw, that's the addres line on the host that's ignoring the solicitations
<apw> where are these solicitations passing to from ?
<apw> you are implying they are through the firewall i think ?
<lamont> apw: the firewall is attempting to solicit the host, so that it can send the icmp6 echo reply
<lamont> you ready for how to fix it?
<lamont> on the affected host: ip link set promisc on dev br0; sleep 1; ip link set promisc off dev br0
<lamont> which is to say, 4.4.0-24-generic (and others, sooo many others) are sometimes failing to correctly set a multicast address on the nic
<lamont> 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
<apw> hrm, how can you tell whether the multi-cast address is set ?
<lamont> damn fine question there
<apw> i wonder if ethtool can tell
<lamont> http://paste.ubuntu.com/18173670/
<lamont> of note: br0 is a bridge containing the eth0.2 interface
<lamont> presumably this would be a bug to file against the linux ubuntu source package?
<apw> yeah i guess so
<lamont> it also fails on another box which has br0 ontaining eth0
<apw> interesting, that must be the trigger somehow
<lamont> Setting the bridge to promisc and turning it back off works around the issue.
<lamont> Tcpdump on the underlying eth0.2 does not.
<apw> lamont, lets get allllll that in a bug
<lamont> yep
<lamont> that was cut-n-waste from my bug window
<lamont> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597806 <-- apw
<ubot5> Launchpad bug 1597806 in linux (Ubuntu) "ipv6 neighbor discovery broken (on a bridge)" [Undecided,New]
<lamont> apw: for additional hilarity, I have some windows 10 users on the network, who also experience the issue
<apw> sounds liek the same problem
<lamont> yep
<lamont> win 8.1 aparently, not 10
<apw> lamont, https://www.v13.gr/blog/?p=378 i wonder if this helps any ... tl;dr disable igmp snooping on the bridge
<lamont> ip neigh <-- TIL
<lamont> cat /sys/devices/virtual/net/br0/bridge/multicast_snooping
<lamont> 1
<lamont> iface br0:ipv6 inet6 auto
<lamont>   up ip addr add fe80::2/64 dev $IFACE
<lamont>   up ip addr add fdd7:308c:d9cf::20/64 dev $IFACE
<lamont>   down ip addr del fe80::2/64 dev $IFACE
<lamont> ^^ my eni
<apw> if tis reproducible, itmight be good to try turning her off
<lamont> apw: and if it fixes it, it would be likely a good thing to JFD in the kernel...
<apw> lamont, right ... and it is a good starting point to understand as well
<lamont> comment added
<lamont> apw: bug updated
<apw> lamont, nice, is that definitaive proof that helps then, or do we need to wait a bit for confirmation
<lamont> positively fixes the issue
<lamont> what's missing from the comment is that the ping started working once the neighbor advertisement hit
<lamont> (duh)
<apw> cool.  then we need to decide if we just turn that off by default on bridges
<lamont> I would recommend either turning that off, or ipv6 off. :p
<apw> :)
<lamont> just sayin'
<lamont> apw: I think actually, the preferred answer is (c) make multicast_snooping not break neighbor discovery
<lamont> I suspect it's just nomming on too much
#ubuntu-kernel 2016-07-01
<LocutusOfBorg> hi folks, anybody can help in verifying LP: #1566221?
<ubot5> Launchpad bug 1566221 in linux (Ubuntu Wily) "linux: Enforce signed module loading when UEFI secure boot" [Undecided,In progress] https://launchpad.net/bugs/1566221
<LocutusOfBorg> I would like to, but I don't know the best and easiest way to test it
<apw> LocutusOfBorg, we have some strategies for that, other than actually installing on secure bot systems.  the person i'd normally dump that on is off this week, so i might punt that till the get back
<apw> i don't think it is holding anything up, as they only hit proposed in the last day or so
<LocutusOfBorg> thanks, so I can forget about it?
<apw> that one needs some coordinated testing with the userspace stuff it goes with, so i would hope they have a proper testing story
<tych0> hi guys, so i think i have some sort of deadlock w/ the freezer cgroup and NFS
<tych0> i was running a benchmark and then started to freeze the container it was running in, and, http://paste.ubuntu.com/18261018/
<tych0> i'm pretty sure i can't reproduce this reliably, as i've never seen it before and this stress test has been workign for a while, but i'm on the host where it happened with the hung task
<tych0> so i'm curious if there's anything else ic an collect that would be useful before i file it
<hallyn> tych0?  tych0?  tych000000?
#ubuntu-kernel 2017-06-27
<brocktice> hi, I am having a strange ipv6 problem only in 4.4.0-81, I suspect the kernel, what is the best way to verify. Boot an earlier kernel?
<apw> brocktice, yep that is definatly a first port of call
<Lachezar> Hey all. X-Posting from #ubuntu as instructed:
<Lachezar> I got bit by what seems to be a kernel bug: Java programs crash with SIGSEGV. However the bug seems to have been fixed in 3.16.43-2+deb8u2 and 4.9.30-2+deb9u2, but I'm on Ubuntu's 4.10.0-24-generic.
<apw> Lachezar, likely fallout from the stackclash updates ... there are new kernels dropping into -proposed pretty much now, you might test one of those and see if it resolves your issue
<Lachezar> apw: I have zesty-proposed enabled. Is "apt-get dist-upgrade" sufficient?
 * apw wonders if zesty is yet built ...
<ogra_> Lachezar, no, that brings in all newer packages from proposed ... you most likely only want to cherry pick one package and then disable proposed again 
<ogra_> proposed tends to have test packages that could be severely broken
<Lachezar> ogra_: I see. So I do not enable proposed, but download and 'dpkg -i' them?
<ogra_> (indeed dist-upgrade usually has a (Y/N) question, so you could stop it)
<apw> Lachezar, zesty is still building anyhow, it is one of the later ones in the list it seems, coming "soon"
<ogra_> Lachezar, no, enable proposed but install via packag name 
<ogra_> not just through some "update all" command
<apw> something like .... enable proposed; apt-get update; apt-get install linux-generic; disable proposed; apt-get update
<Lachezar> apw: Ah. OK.
<Lachezar> ogra_: thanks.
<apw> but as i say, we are in the process of spinning kernels (or is it plates) now
<Lachezar> Kernels would be in proposed/main right? Not universe, multiverse etc.
<apw> Lachezar, depends on the kernel, but for the primary ones for desktop/server etc yes, those would be in main
<hallyn> all right, so confirmed, 4.8 kernel appears to cause my t440s screen to flicker every few minutes.  hasn't happened since downgrading to 4.4
<hallyn> the random flicker was strangely stressful - may as well have been an electric shock
<apw> hallyn, you know the drill ... bug please
<hallyn> apw: well, this was intended as a datapoint in case you've heard other reports;  i need to get harder data to file a bug :)
<hallyn> i'll keep my eye on it, boot back and forth, etc.
<apw> hallyn, not heard of it no, though i guess i didn't run 4.8 very long
<hallyn> i have to stay on xenial so i can keep running upstart :)
<hallyn> mind you 4.8 seemed better with batt usage than 4.4
<apw> hallyn, i think we did feel the same on battery
<apw> hallyn, well you have the option of a 4.10 in xenial ... linux-hwe-edge
<hallyn> so i'll boot back into that tomorrow and file a bug
<hallyn> ah, i'll try that, thx
<hallyn> (after tomorrow)
<apw> heh yeah, and keep us informed
<hallyn> will do
#ubuntu-kernel 2017-06-28
<brocktice> I figured out my ipv6 problem, it seems the bridge multicast snooping behavior changed recently?
<brocktice> when it changed I haven't figured out yet
<apw> brocktice, changed in what way (if you know), i wonder if it got fixed, i think it has been suspect for some time
<xkern> hi again.
<xkern> i asked some things related to debugging.  and i'll ask again. 
<xkern> if someone debugged ubuntu 16.0.4 lts  before ,  it can help me.
<xkern> i'll wait here if you know something , you can write to board and i notice.
<apw> a lot of people have debugged a lot of things, but you haven't really given them anything to work with to know if they know
<apw> if you have a specific question i would ask that
<xkern> okay one minute i'll write my question in details.
<xkern> my host machine is x86-64 kali linux  and my guest machine is ubuntu 16.0.4 lts.
<xkern> i use virtual box as emulator.
<xkern> i use kgdb for debugging.
<xkern> if i put breakpoint anywhere , virtual machine doesnt stop.
<xkern> i guess i wrote question in details . i hope i didnt write something wrong.
<apw> those are good details, lets someone reading think about if this is somethign they know about
<leitao> sforshee, good morning. We would like to have this patch on 4.4 kernel. Is this something you would grab automatically with the 4.4 rebase, or, should we ask explicit? https://patchwork.ozlabs.org/patch/779346/
<LocutusOfBorg> hello, what is your plan for the .12 kernel in artful?
<LocutusOfBorg> weeks, days?
<LocutusOfBorg> just to know for virtualbox
<apw> smb, ^
<apw> LocutusOfBorg, we're stuggling to get 4.11 to pass things, so i would say not days
 * smb claims to know nutting about artful states
<apw> smb, the 4.4 thing
<LocutusOfBorg> wonderful
<LocutusOfBorg> in the meanwhile somebody will release the new vbox then
<LocutusOfBorg> and I'll ask you to sync patches
<smb> leitao, Either to ask for it or if that goes upstream stable it comes over time
<leitao> smb, right, I will raise a bug then. Thanks!
<apw> smb, if i am reading this right, greg applied it today stables
<smb> apw, oh maybe... I have not looked there today
 * smb pulls upstream stable
<sforshee> leitao: we apply all of Greg's stable updates, so yes we will get it automatically
<leitao> sforshee, right, so, just waiting is enough now?
<leitao> since the patch is already on greg's tree.
<sforshee> leitao: waiting is enough unless the stable hasn't been released and you need it right away
<smb> leitao, So yes, it looks to be in the queue right now
<smb> So maybe releases next week and then could make it into the next sru cycle after the current one. so roughly applied in 3 weeks and release in 6. If life does not present us with more emergencies
<leitao> sforshee, smb: right. Let's follow the usual process then, and we wait the rebase to grab the patch. thank you!
<leitao> smb, sforshee: What about 4.8 kernel? This patch is needed for 4.8 kernel also.
<smb> leitao, for 4.8 we would need a request/bug report as ther eis no upstream stable any more
<leitao> smb, ok, I will raise it then. Thanks!
<xkern> btw , i'm new graduated  and how can i find job related to kernel hacker/developper  ? because my country is so poor for that.
<chiluk> xkern, how are you connecting kgdb to your virtual machine?
<chiluk> last time I used kgdb I used two separate machines, and connected them via serial and network.
<chiluk> xkern how are you setting your breakpoints?
<chiluk> xkern something you might try is to try solving some bugs on https://bugzilla.kernel.org/ or https://bugs.launchpad.net/ubuntu/+source/linux  this is not an easy profession to break into.
<chiluk> good luck xkern... Unfortunately I haven't used kgdb in quite some time..
<xkern> installed ubuntu kernel version is 4.8.0-36 generic on my pc.
<xkern> i want to download same version from kernel.org but i didnt find.
<apw> xkern, that is an ubuntu specific version number it will not be at kernel.org
<xkern> how can i find it ? 
<apw> that by the way is a very out of date version of 4.8 kernel
<xkern> if i  download  4.8 from kernel.org, then is it problem for debugging ? i guess my debugging problem is based version.
<xkern> because of that i want to download correct version for debugging.
<apw> xkern, yes the kernel.org 4.8 is rather different from what is in our kernel
<xkern> hmm
<apw> if you want the debug information you likely want the ddeb's from ddeb.ubuntu.com
<apw> the primary source for any release is in our public git repositories
<apw> https://wiki.ubuntu.com/Kernel/SourceCode as all the details
<xkern> thanks apw
#ubuntu-kernel 2017-06-29
<d3ll> my ubuntu 16.04 not shutting down properly. It stucks at splash screen with ubuntu logo and then it stays forever. To shut it down, I manually have to long press the power button. 
<d3ll> help ??
<apw> d3ll, that happened to me on the last reboot too, not sure that is going to be a kernel issue
<apw> d3ll, might be worth mentioning on #ubuntu as well
<d3ll> there might be some kernel services which are inhibiting the poweroff process
<apw> d3ll, there might, but then most of shutdown is systemd's domain, have you tried hitting ESC as the dots start, i think it goes away and you can see what systemd is doing
<apw> d3ll, last time i had this it was VMs running which triggered the delay, it waited 2m for each or somethign
<d3ll> apw, thanks mate... will do it
<xkern> https://askubuntu.com/questions/930253/kernel-debugging-with-virtualbox
<xkern> it's my question if can give more details , please say me.
<hallyn> apw: aptitude search linux-hwe | grep edge   doesn't show anything like linux-hwe-edge-generic .  does something exist for xenial?
<apw> linux-generic-hwe-edge ?
<apw> linux-generic-hwe-16.04-edge
<apw> keep forgetting it has a base version in it for upgrades
<apw> hallyn, ^
<hallyn> doh
<hallyn> didn't think to split linux and hwe up :)  thanks
<JPelletier> I'm investigating a random Black Screen after reboot (like 1/30 reboots). I can reproduce it with my USB Installer (made with Rufus)
<JPelletier> I tried to set earlyprintk=efi in my grub.cfg and I reproduced the issue after an hour rebooting my system, but it freeze right after [    0.00000] bootconsole [earlyefi0] disabled
<JPelletier> It's an Intel NUC6CAYS with Kernel 4.10 (Ubuntu Server 17.04)
<JPelletier> What should I try now?
<JPelletier> I'm really not a Linux expert and I'm digging this issue for a week now, searching and trying new stuff every day. It's driving me crazy
<JPelletier> I tried with earlyprintk=efi,keep but it's REALLY slow
<JPelletier> it start to be slow after Freeing SMP alternatives memory: 32k
<JPelletier> I have to disconnect, if you can help me: https://askubuntu.com/questions/929714/ubuntu-server-17-04-nuc6cays-random-freeze-after-grub   Thanks guys!
#ubuntu-kernel 2017-06-30
<ioria> hi....  having issues booting 4.4.0-83-generic  with nouveau ...  any pointing ? (booting in text modes stops witha kernel panic)
<alinefm> Hi all, Does anyone know when kernel will be updated to 4.11 on Ubuntu 17.10 ?
<apw> alinefm, likely early next week now
<alinefm> apw, thanks
#ubuntu-kernel 2018-06-25
<michael-vb> Hello.  I have just noticed that the Ubuntu kernel has adopted David Howells' lockdown patch and was wondering how one is supposed to detect that the kernel will only load signed modules.  Somewhat confusingly, /sys/module/module/parameters/sig_enforce says "N".
#ubuntu-kernel 2018-06-26
<jhg_> well, I copied the initrd.img from /boot and that still didn't fix the issue, so I am a bit mystified as to why one kernel can find root and the other cannot.
<jhg_> (copied the working one to the non-working variant)
<jhg_> I suspect it is a .config difference resulting in the driver availability for the HP ProLiant DL360 Gen10 hardware.
<jhg_> Specifically, aacraid.
<jhg_> Are there any git repo mirrors? I am finding launchpad to be rather slow.
<chiluk> jhg_: which kernel are you wanting to know about?
<chiluk> nm ... reading backscroll.
<jhg_> chiluk: 4.18.0-rc2+
<chiluk> did you make oldconfig using the ubuntu config?
<jhg_> It smells like a driver. Looking for differences in .config for kernel build. I expect something to get baked into the ubuntu kernels which would make those work while my homemade kernel build does not (or has it as a module).
<jhg_> looking... need to finish checking out from launchpad git repo. =)
<chiluk> jhg_: you might have better like running make oldconfig from one of the 4.15 kernels.
<chiluk> jhg_: git clone --reference linux  ... if you have a local clone of linus' tree
<jhg_> ah... that would save some time.
<chiluk> yep..
<chiluk> and lots of disk space... 
<jhg_> the list of drivers to look at is finite. lspci -k | grep module | awk '{print $3}' | uniq >> https://hastebin.com/ahaseqomes.rb
<chiluk> make modules ; make modules install
<chiluk> then rebuild your initramfs
<chiluk> mkinitramfs
<chiluk> just throwing out ideas here.
<chiluk> sometimes a rubber duck can be useful.
<chiluk> jhg_: if you don't need to be developing on a bleeding edge kernel you could be playing with the ubuntu trees...
<chiluk> rubber ducking ->https://www.youtube.com/watch?v=huOPVqztPdc
<jhg_> =)
<chiluk> jhg_: those are available http://kernel.ubuntu.com/git/?q=ubuntu%2F
<jhg_> oh, one more thing: my custom kernels work in virtualbox, but not on the bare metal.
<chiluk> that's probably because all the configs are set up to run on virtual machines without the need for modules.
<jhg_> which is why I suspect it's a .config driver issue.
<jhg_> right
<chiluk> yep.
<chiluk> alright sounds like you are on the right track...
<jhg_> thanks, chiluk! =)
<chiluk> I don't always pay attention to this channel since I'm no longer full-time Ubuntu dev... so good luck.
<jhg_> chiluk: what are you up to these days?
#ubuntu-kernel 2018-06-27
<chiluk> jhg_: I'm a Linux platform engineer for indeed.com 
<sforshee> jjohansen: any updates on the socket mediation fixes?
<jjohansen> sforshee: yeah, I can point you at patches. Give me a sec
<jjohansen> sforshee: https://paste.ubuntu.com/p/jJZsRmzZ98/
<sforshee> jjohansen: thanks!
<jjohansen> I can send that to the list if you want
<sforshee> no that is fine, we don't need acks for the devel kernel
<sforshee> jjohansen: one of those patches points at bug 1778646, which I can't see. Is that the correct bug number?
<ubot5> Error: Launchpad bug 1778646 could not be found
<jjohansen> sforshee: yep, its apparently marked private security atm
<sforshee> ok, thanks
<jjohansen> sforshee: you are now subscribed, I am probably just going to make it public, but will talk to chris and tyler about doinng so first
<sforshee> jjohansen: ack, ta
#ubuntu-kernel 2018-06-28
<tjaalton> have there been issues with zfs/grub on xenial lately? I'm not able to boot my server anymore, claims that the device doesn't exist. it's a 4 disk mirrored pool, data is fine since I can get to it via a live session
<tjaalton> and running grub-install didn't help
<jhg_> and not objtool is not getting installed. hmm
<tjaalton> hrm, trying to access the disk from grub rescue shell says "unknown filesystem"
<jhg_> tjaalton: I had an issue which I was unable to isolate. it seemed like different drivers were builtin to the kernel, which caused initrd stage to not find the disks (hw raid array).
<tjaalton> I reinstalled grub-pc, looks like it failed to install grub to one of the disks, because the disk-id had an extra comma appended
<jhg_> hmm... 
<tjaalton> last of the four
<tjaalton> grub-probe etc all pass fine
<jhg_> and older kernels work?
<tjaalton> it doesn't get past grub..
<jhg_> when did it break
<tjaalton> I had to shut it down two weeks ago
<jhg_> what would have changed?
<tjaalton> had it running for months before that
<tjaalton> beats me
<tjaalton> updates are installed automatically
<jhg_> well, there's that. not sure I can really help at this point.
<jhg_> good luck
#ubuntu-kernel 2019-06-24
<Glorious729> Is there a bug for how 4.18.0-22.23's CVE-2019-11478 fix breaks Steam from ever connecting to Valve's network because of its use of a very low SO_SNDBUF value?
<Glorious729> oh nevermind, it's not actually in -stable yet 
<Glorious729> is it policy to apply that as a remediation to a security patch though?
<Glorious729> oh no it is in
<sbeattie> Glorious729: regression updates are in progress. Not sure if there's a bug report about it.
<salty-horse> hi. I'm running disco. The kernel patch introduced with 5.0.0-17.18 breaks Steam, and a fix was introduced in 5.1.14 - "tcp: refine memory limit test in tcp_fragment()". Is there a timeline to when the disco kernel will include this patch? If it's not planned, how should I file a request about it? (I'm unfamiliar with the process)
<TJ-> salty-horse: would you be related to the ibus-uniemoji github repo?
<tyhicks> salty-horse: hi - we're aware of the bug and we are fast tracking kernel updates to address it
<salty-horse> TJ-, yes, but I'm not the original author. just the current maintainer
<TJ-> salty-horse: I realise that, but wondered if I could ask you a couple questions about it. Installed on 18.04 today and not had it work but not sure what to expect 
<tyhicks> salty-horse: I think it is reasonable to expect 5.0.0-20.21 to enter -proposed later today
<tyhicks> salty-horse: I can't quite give you an accurate timeline on when it will be officially released but mid-week is probably a safe assumption
<tyhicks> salty-horse: you'll be able to install it from disco-proposed in the meantime to get steam working again
<Glorious729> does this apply to the 18.04.2 LTS 4.18 kernel?
<Glorious729>  as in, it'll also be in proposed and then officially released midweek or so?
<tyhicks> Glorious729: yes, it will be on the same timeline as the 5.0 based kernels
<Glorious729> nice, thanks!
<Glorious729> someone just said "regressions updates were in progress earlier"
<tyhicks> Glorious729: Xenial 4.4 based kernels might lag a little behind but it is too early to say for sure
<Glorious729> that's fine
<Glorious729> I mean, for me ;)
<tyhicks> Glorious729: yeah, we're all heads-down trying to prepare updates so status is changing on the fly
<Glorious729> well I mean this is just steam so lol it's not like my billion dollar datacenter is affected
<Glorious729> but thanks
<tyhicks> some non-Steam applications are also affected, unfortunately
<Glorious729> yeah :(
<Glorious729> I knew it was serious when linus is coming into a steam support thread
<Glorious729> saying "try this patch"
<Glorious729> All I meant was I'm fine with your current prognosis when it comes to me personally, as I don't need anything more exact than that and I was just happy to hear any sort of timeline
<Glorious729> thanks
<tyhicks> no problem
#ubuntu-kernel 2019-06-25
<midnightmagic> mainline-crack v5.2-rc6 build seems to fail due to: install: cannot stat '/soft/mainline-crack/debian/build/tools-perarch/tools/perf/libperf-jvmti.so': No such file or directory, when attempting to build on a ppc64le host.
<midnightmagic> is there a sneaky/easy way to fix this?
 * midnightmagic forces jvmti to false in debian/rules and rebuilds..
<apw> hmmmm
<midnightmagic> build complete. no obvious errors.
<midnightmagic> Host is: Talos II, 4.19.0-041900rc8-generic #201810150631 SMP Tue Oct 16 17:40:37 PDT 2018 ppc64le ppc64le ppc64le GNU/Linux, export DEB_BUILD_OPTIONS='parallel=144', cpuinfo shows 144 threads; this is a dual 18-core POWER9 system; currently 234GB mem by "free" but I think there's actually 256 installed.
<TJ-> A user has reported a regression since 4.15.0-45, kernel OOPS and failure of i915 Bug #1834177
<ubot5> Error: Could not gather data from Launchpad for bug #1834177 (https://launchpad.net/bugs/1834177). The error has been logged
<TJ-> bug #1834177
<ubot5> bug 1834177 in linux (Ubuntu) "regression: between 4.15.0-45 and 4.15.0-50 - i915 vmalloc_fault" [Undecided,Confirmed] https://launchpad.net/bugs/1834177
<TJ-> potential regression commit 7fa1a35564b2
<Glorious729> any update on when linux-signed-hwe in proposed will be 4.18.0-25.26 ?
<apw> i am not sure that version will ever make the day
<Glorious729> any idea about when it'll go official then, by any chance?
<apw> what are you looking to land
<Glorious729> fix for the CVE-2019-11478 regression on low value SO_SNDBUF
<Glorious729> AKA steam won't connect
<tsimonq2> Would someone with familiarity with sysdig be able to look at bug 1826845? It's in the sponsorship queue, and the two patches proposed are authored by sforshee and Colin Ian King.
<ubot5> bug 1826845 in sysdig (Ubuntu) "Unable to build sysdig module on 5.0 kernels" [Medium,In progress] https://launchpad.net/bugs/1826845
<trinar> Hi all, i have stupid question about https://bugs.launchpad.net/ubuntu/+bug/1767992. Any plans for backport? (Currently solved it with custom kernel and hwe-edge). Thanks.
<ubot5> Ubuntu bug 1767992 in Ubuntu "Linux md raid-10 freezes during resync" [Undecided,Confirmed]
<tqinli> is this channel good for discussing issues with the linux-tools-* package? I am hitting core dump wiht the perf excutable from linux-tools-4.15.* for 18.04 LTS. Based on the core dump, it is very likely fixed in 4.19-rc kernel upstream, patch here: https://lore.kernel.org/lkml/20180810133614.9925-1-bevers@mesosphere.com/
<tqinli> I am currently building privately with that patch above to see if the issue is fixed. but would like to know the right process to get the fix in 18.04 LTS
<apw> tqinli, report a bug in launchpad against the linux package; and email the patch in to kernel-team@lists.u.c
<tqinli> cool, will verify and get that started...
#ubuntu-kernel 2019-06-26
<dqx> hi. does anyone understand why when building a custom kernel `make deb-pkg` always cleans everything before packing? this is _so_ time consuming. am I doing something wrong?
#ubuntu-kernel 2019-06-29
<LocutusOfBorg> sforshee, FYI I syncd gost-crypto from Debian, the delta seems now upstream
#ubuntu-kernel 2019-06-30
<Kon-> Does the Ubuntu kernel make any changes to latency? I've seen a fair number of people comment on how Debian gives them audio skipping while Ubuntu does not
<JanC> Kon-: Ubuntu has an optional low-latency kernel, which is used in e.g. Ubuntu Studio
<JanC> it should only be relevant for audio production or such, I think, not for just playing some music...
