#ubuntu-kernel 2005-03-20
* #ubuntu-kernel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
<fabbione> anybody alive?
* fabbione sighs
<fabbione> guy the enable-inotify patch is kinda of horrible
<fabbione> it would have been enough to modify the inotify-*-optional patch
<fabbione> instead of adding a 3rd one on top
<fabbione> YAYAYAAYYA
<fabbione> inotify doesn't crash anymore!
<fabbione> it will be in 2.6.10-26 and no ABI change :P
<fabbione> FUCK NO
<fabbione> it crashed on the second removal
<fabbione> hmmmm
<zul> hey
<fabbione> hey zul
<zul> hey fabbione how is it going?
<fabbione> good and bad
<zul> oh?
<fabbione> i merged inotify 0.20 from 2.6.11-3 into 2.6.10
<zul> and?
<fabbione> and i managed to unplug my usb device without crashing the kernel once
<fabbione> it dies the second time
<zul> lol
<zul> i think we should take out rml
<fabbione> now i am cleaning up the patch mess from inotify-*-optional and enable-inotify
<fabbione> so that there is one good patch
<fabbione> and that's it
<zul> good
<fabbione> and leave inotify disabled by default
<zul> ill have to see the patch once its done so i know what to do next time if this pops up again
<fabbione> well it's pretty simple
<zul> did you get the inode error when compiling?
<fabbione> see the original inotify patch
<fabbione> it changes the dnotify entries in fsnotify entries
<fabbione> zul: no but that's becaused i used a more recent patch and the error is easily fixable
<zul> yeah
<fabbione> parse the calls to fsnotify to see what are the inotify_ calls
<fabbione> that leads to 5 functions
<fabbione> inotify_inode_queue_event
<fabbione> inotify_dentry_parent_queue_event
<fabbione> inotify_inode_is_dead
<fabbione> inotify_super_block_umount
<fabbione> inotify_get_cookie
<fabbione> so basically inside inotify.c in these 5 functs
<fabbione> you add the check
<fabbione> if (!inotify)
<fabbione>  return;
<zul> ah ok
<zul> so no need to push my inotify stuff to you in the next patchset from me
<fabbione> nope
<fabbione> i am going to commit it to baz in a few minutes
<fabbione> i only need to do a test build
<fabbione> and see if it works as expected
<zul> btw when do you want my stuff by
<fabbione> asap?
<zul> sure
<zul> i can put them up when i get home tonight am at work right now
<fabbione> ok
<fabbione> we are not going to upload today
<fabbione> preview release is still ongoing
<zul> yeah thats what i thought
<zul> alsa is messing some people up when they upgrade because of the alsa driver for their winmodem
<fabbione> i know...
<fabbione> atleast
<fabbione> i heard
<zul> heh its the kamion kult
<lamont> zul: the question is, does alsa provide a working modem then??
<zul> lamont: i think i dont have a modem havent had one in the past 10 years :)
<lamont> ah sure you do... it's just not plugged into a phone line...  any semi-modern laptop will do... :-)
<zul> if i had a phone line...i just have a cell phone
<lamont> ah,opk
* lamont can accept that. :-)
<zul> i like making things dificult for you lamont :)
* lamont throws things
<fabbione> there are serial cables for cell phones
<lamont> fabbione: if you can tell me how to make the DKU-5 work with linux and my nokia phone, I will buy you _3_ beers
<lamont> (no linux driver last I knew)
<fabbione> i have an ericsson phone that has an internal modem
<fabbione> i just plug the serial cable and do ATZ
<lamont> DKU-5 is a usb cable
<lamont> and vendor id isn't recognized.
<lamont> OTOH, the last time I tried was 2.6.8 timeframe...
<fabbione> hmmm
<fabbione> i have the usb version too
<fabbione> and i see the cell phone as a usb-serial
<fabbione> same story.. minicom -> ATZ
* lamont will play with his phone today
<zul> *sigh* why do people have to use cheap kvm switches
<lamont> zul: because they're _poor_, of course.
<zul> heh...duh...it was rhetorical
<lamont> heh
<fabbione> http://x3.putfile.com/videos/6608573980.wmv
<fabbione> AHAHHA
<fabbione> it's work/wife safe :)
* lamont tries to think of something that's not canonical-work safe...
<fabbione> well if you have some emploies watching your shoulders ;)
<lamont> heh
<zul> lol!!!
<lamont> fabbione: heh
<lamont> but you notice he had it pointed in a safe direction...
<fabbione> he still managed to hurt himself
<lamont> yeah - had on the slide while you pull the trigger is kinda stupid...
<lamont> note also that "accidents" like that always involve empty guns
<lamont> first rule is: it's always loaded until I see the inside of the chamber
<fabbione> yeah
<lamont> that's like when people ask if a concealed-carry gun is loaded.  duh!
<zul> hey jbailey 
<lamont> morning jbailey 
<fabbione> hey jb
<jbailey> Heya Chuck
<jbailey> G'morning Lamont, G'd afternoon Fabio.
<fabbione> T-None:
<fabbione> debian/ext3-modules-2.6.10-4-itanium-smp-di lib/modules/2.6.10-4-itanium-smp/kernel/fs/mbcache.ko
<fabbione> debian/ext2-modules-2.6.10-4-itanium-smp-di lib/modules/2.6.10-4-itanium-smp/kernel/fs/mbcache.ko
<fabbione> some modules are in more than one package
<fabbione> command exited with status 255
<fabbione> make: *** [binary-udebs]  Error 2
<zul> gah?
* lamont wonders what an mbcache is
<fabbione> wth is that module?
<fabbione> these errors are coming out after we fixed the build system
<fabbione> i386/amd64 are ok
<fabbione> ppc is building
<fabbione> ia64 dies with that error
<lamont> at least one of those builds with either ext2 or 3 =y
<fabbione> it means that eitehr there is an error in kernel-wedge
<lamont> or both
<fabbione> or that module needs to be shared
<fabbione> lamont: right...
<fabbione> which one should we compile in? ext2 is my best bet
<zul> lowest common demoniator
<lamont> yeah
<lamont> ext2 is what's on the livecd, so we know we need it. :0)
<lamont> and it's small
<lamont> ish
<fabbione> ok
<fabbione> but i also rememeber that changing to y has other implications
<lamont> hrm..
<lamont> no clue
<fabbione> i need to figure what
<fabbione> like updating some d-i/ stuff
<lamont> the other alternative is a shared package or something
<fabbione> yes
<fabbione> if there is a fs-common something
<fabbione> anyway that's T-Bone decision
<zul> yay perl is almost done
<zul> crap more changes
<zul> wtf?
<fabbione> dude.. i am not kidding
<fabbione> that machine is IDE
<fabbione> and it has been until yesterday
<fabbione> nobody here was in my office other than me
<fabbione> either i updated it in my sleeps
<fabbione> or something is really WEIRD
<zul> *sigh* could it be hotplug?
<fabbione> no
<zul> grr...i hate it when something breaks
<fabbione> read #u-d
<fabbione> either i misread partitioner
<fabbione> or it did change
<fabbione> in the latter case it IS an issue
<zul> ok if that is the case how can we fix it mandrake has libata_enable_atapi
<fabbione> i need to check again first
<zul> ok
<zul> time for lunch
<zul> yay...i was having a little heartattack
<zul> ok lunch
<zul> ok what the hell is going on?
<fabbione> zul: libata_enable_atapi is broken
<zul> fuck..
<zul> it was ripped straight from mandrake and when we tested it worked
<fabbione> ok the problem is not the ATAPI
<fabbione> but the PATA change
<fabbione> static struct pci_device_id piix_pci_tbl[]  = {
<fabbione> #ifdef ATA_ENABLE_PATA
<fabbione>         { 0x8086, 0x7111, PCI_ANY_ID, PCI_ANY_ID, 0, 0, piix4_pata },
<fabbione>         { 0x8086, 0x24db, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich5_pata },
<fabbione>         { 0x8086, 0x25a2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich5_pata },
<fabbione> #endif
<fabbione> this means grabbing old IDE controllers and treat them as SATA
<fabbione> sorry PATA
<zul> oh crap..
<fabbione> the fact that a patch is taken directly from Mandrake or Suse or Gentoo means nothing
<fabbione> if they did apply other patches on top to fix this stuff
<fabbione> or have older code than us
<fabbione> so now we have 2 options
<zul> ok im sorry it wont hapen again
<fabbione> either we kill the PATA and we see how it goes
<fabbione> or we figure if in newer libata versions it works as it should
<fabbione> clearly this has very very high priority
<jbailey> Is this undoing the SATA fix?
<jbailey> SATA CDrom fix, rather?
<fabbione> zul: nothing to be sorry.. it could have happen to me
<zul> jbailey: yes
<fabbione> jbailey: now it's giving I/O corruption on piix chipsets
<jbailey> Oh.  Joy.
<fabbione> so either we get the fix NOW
<fabbione> or we revert the change
<zul> rever the change on pata
<jbailey> In the face of corruption definetly revert.
<fabbione> zul: let's divide the tasks instead
<jbailey> But we'll have to reopen the bug with an explanation as to why.
<fabbione> zul: do you have such chipset somewhere?
<fabbione> or jbailey ?
<zul> fabbione: no i dont but jbailey does i think
<fabbione> (it's 12 hours and more than i am here and i need to rest)
<jbailey> I do, yes.
<fabbione> jbailey: i urge you to test and see if you can reproduce the problem
<fabbione> it's enough to boot the live cd
<jbailey> It's in a data centre three time zones from here.
<fabbione> the installer will fail
<fabbione> jbailey: well.. when i ask if you have it.. i mean handy :)
<jbailey> sabdfl also has hardware to match it.
<fabbione> yeah but he quite not around
<fabbione> and i can't ask him to build/test kernels
<fabbione> what i don't understand is why a kernel upgrade didn't show the problem
<zul> i can build a kernel without the pata enabled
<jbailey> It's handy in the sense that I can test kernels if we're somewhat confident it won't eat the system, and I can get all sorts of status information about the box.
<fabbione> why on an upgrade it didn't switch to sda?
<fabbione> jbailey: the problem seems to affect only cdrom
* T-Bone whispers 'hppa.u.c' at lamont... :)
<fabbione> since i could boot from such machine
<zul> T-Bone: not a good time
<T-Bone> fabbione: WTF is that mbcache crap in the backlog? :P
<fabbione> T-Bone: not a good time
<T-Bone> oh
<T-Bone> because there is such a thing as a "good time" ?
<fabbione> jbailey: but i can't ask you to risk on a machine that far
<jbailey> fabbione: Is it any piix driver or just the ata_piix driver?
<jbailey> fabbione: The laptop I'm on has piix.
<fabbione> jbailey: for what i can see is any
<fabbione> i have 2 machine with piix and both fails
<fabbione> jbailey: using the livecd is ok
<fabbione> it won't touch your hd at all
<fabbione> it will stop much earlier than that
* T-Bone is trying to figure out what's going on...
<fabbione> T-Bone: I/O corruption from cdrom with the new libata changes
<jbailey> Hmm, I wonder if I have a CD here.
<jbailey> Ugh, teenagers.  Looks like the local school is having a field trip to the local coffee shop.
<jbailey> (first time I looked around)
<fabbione> cdrom only *APPARENTLY*
<T-Bone> fabbione: sweet, how comes this made it in?
<lamont_r> jbailey: I was here for one of those too.
<T-Bone> s/this/this shit/
<fabbione> T-Bone: the same way people are already complaining about the ppc LED turned on
<lamont_r> well, time to go retrieve my latin scholar
<T-Bone> i see
<jbailey> fabbione: Is there anything I can test from my running system
<fabbione> patch -p1 < somefancystuff.diff
<T-Bone> we've been too laxist on the mergein policy
<lamont_r> so who checked in the ppc changes, anyway?
<fabbione> jbailey: no. you need to boot the livecd
<fabbione> not me
<T-Bone> part my fault
<fabbione> i was approx 20000KM or 12000NM from any pc
<T-Bone> but otoh i must blame zul for that one
<fabbione> NO TIME TO BLAME
<fabbione> we need a fix
<T-Bone> disable it
<fabbione> and who can test the fix
<jbailey> fabbione: Lemme pull down a livecd then.  Lesse how good the net connection at this web caf really is. =)
<fabbione> jbailey: ok.
<T-Bone> revert to pre-25
<fabbione> jbailey: to verify:
<fabbione> boot on the liveCD
<fabbione> and the installer should fail with "unable to load installer components" or something like that
<fabbione> check dmesg
<fabbione> and /proc/partition to verify that your hardware is actually recognized as scsi
<lamont_r> T-Bone: need -25 for kickstart for kamion. Don't think we can revert
<fabbione> probably checking the PCI id from above should be enough to know if it will happen or not
<lamont_r> and I'm inclined to call this 25.1, since we already have -26 in the works...  thoughts?
<T-Bone> lamont_r: how comes we couldn't revert the libpata diff (which is 2 lines btw), since it was working just fine before except for a few users with specific hardware??
<lamont_r> T-Bone: that's what we need to do.
<fabbione> few = a lot dude
<fabbione> piix is quite common intel hw
* lamont_r read 'revert to pre-25' to mean 'use -24 on the preview'.  which is much different than reverting that patch
<T-Bone> fabbione: hell, your call. If you prefer more supported user with broken implementation...
<T-Bone> lamont_r: yeah sorry i wasn't clear enough
<jbailey> fabbione: array6 is fine for the livecd, right?
<jbailey> Or do I need something more recent?
<fabbione> jbailey: dunno.. it needs to have -25
<T-Bone> if we need a minute-made fix, the only solution is reverting that patch
<lamont_r> I prefer some unusable implementations to silent data corruption anywhere
<jbailey> Do you have the URL for a mor recent snapshot handy?
<T-Bone> we wouldn't have enough time to test any other invasive change
<T-Bone> and would introduce potential new bugs that way
* lamont_r really must run and fetch the kid - back online in about 40-45 minutes
<T-Bone> lamont_r: same here, hence my comment. Trying to fix both 'support more users' and 'fix data corruption' would go against our safe commit policy
<T-Bone> but that's just my 2 cents
<jbailey> fabbione: I'm getting 60k per second to cdimage.ubuntu.com  3 hours to download at this rate. =(
<T-Bone> ouch
* T-Bone can't help. No x86 hw around
<zul> i have a pentium 3 where i can build a 686 kernel if you want to test
<jbailey> The question got missed in #u-devel, Is this only for cases where ata-piix intead of piix gets loaded for pure pata systems?
* T-Bone needs to run out
<T-Bone> i'll be back in ~30'
<zul> im building a kernel for 686 that disables undef pata again
<T-Gone> zul: that's a no-go alas. We don't have time to rebuild a full set of kernels...
* T-Gone runs off anyway
<zul> im only building 686
<jbailey> zul: Do you know whether it's only for cases where ata-piix gets loaded instead of piix?
<zul> im not sure
<jbailey> I've been running that kernel on my laptop for a while with no problem, and I've been using that kernel on a sata system that does a couple emails a second with no problem.
<jbailey> I'm still sitting at 40k/sec for this livecd download, though.
<jbailey> My laptop does the cdrom no problem.
<jbailey> So I'm not sure where he's seeing the issue.
<zul> do a hdparm on the cdrom
<jbailey> 16 bit, a pile of offs, readahead 256, HDIO_GETGEO failed.
<jbailey> afk a sec.
<jbailey> back
<zul> fabbione: is that the same  message that jbaileiy got?
<jbailey> zul: I think thats' pretty normal for hdparm'ing a CDROM.  I don't htin it provides the geometry info.
<zul> k
<jbailey> My guess is that what he's seeing is that the controller is being detected as ata_piix intead of piix.
<jbailey> It wouldn't affect upgrades because initrd-tools isn't that bright.
<jbailey> Is that PCI ID add that you pasted here the only change with that patch?
<fabbione> no
<fabbione> it also enables another thing
<jbailey> fabbione: Is my assumptions right so far?  That you're running off of ata_piix instead of running off of piix?
<fabbione> i need dinner
<fabbione> bbl
<jbailey> Mm, lunch sounds like a good idea too.
<jbailey> I'll finish this first.
* lamont_r sits on the "neighbor"'s front porch, leeching bandwidth
<lamont_r> "neighbor" is about 3.5 miles away
<T-Bone> lol
<T-Bone> would that mean anything good for me? :}
<lamont_r> fabbione: from a logistical standpoint, whatever fix we do should probably just happen on mainline, and then we can merge it over to -pre26, and then think about renaming said branch... :0)
* T-Bone ducks
<zul> ok im building the linux headers for 2.6.10 with #undef pata
<T-Bone> zul: what are you trying to do?
<zul> im trying to get a test kernel going
<zul> or...trying to help out
<T-Bone> zul: actually, any solution involving a kernel rebuild is mostly ruled out, afaict
<T-Bone> zul: actually it turns out that I just said crap. Forget it :P
<zul> i have a linux-image with pata turned off again if you want to test
<T-Bone> zul: i'd love to. Don't have the hw :P
<jbailey> zul: Did you revert the whole patch or just the extra PCI ids?
<zul> just the pci ids
<jbailey> I could test the kernel here just to make sure it doesn't load both anymore.
<zul> -#undef ATA_ENABLE_ATAPI                /* define to enable ATAPI support */
<zul> +#define ATA_ENABLE_ATAPI               /* define to enable ATAPI support */
<zul>  #undef ATA_ENABLE_PATA         /* define to enable PATA support in some
<zul>                                  * low-level drivers */
<T-Bone> zul: tel kamion/fabbione what you're doing on #u-devel, seems they're not aware...
<T-Gone> dinner time, bbiab
<fabbione> i am preparing 25.1
<zul> ok
<T-Bone> lamont: how are you going to integrate 25.1 into the baz archive?
* T-Bone tries to return to the adequate channel
<lamont> T-Bone: simple.  grab source, apply diff, commit to mainline
<lamont> then branch it to -2,6,10-25,1
<lamont> merge to --pre26, and commit there
<T-Bone> woot
<T-Bone> seems so simple :)
<lamont> T-Bone: that's why we don't work on the mainline branch... :-)
<lamont> alternatively (if we had already checked in -26 on mainline), then it would go in as a patch on the -25 version branch
<T-Bone> ic
<T-Bone> btw. what about the issue that would possibly be solved today? Will it have to be postponed? (just asking, mind you :)
<lamont> which issue is that?
<lamont> oh. that.  nfc
<T-Bone> heh
<T-Bone> i feared such an answer :|
<zul> right ill be back later tonight...going to go play some soccer and ill be in pain later :)
<lamont> step 1: preview release ships.  step 2: figure out status of everything else, act accordingly
<T-Bone> heh
* T-Bone has gone for a 'nobody cares' policy on ia64
<zul> later
<T-Bone> zul: have fun
<zul> oh i will
<T-Bone> hehe
<Mithrandir> T-Bone: nobody (read HP) has cared enough to send me an ia64 yet, so.. ;P
<T-Bone> Mithrandir: heh. Otoh you've got full access to mine...
<Mithrandir> T-Bone: true enough.
<T-Bone> Mithrandir: more access would be "physical" at that point :)
<Mithrandir> I could use one, it's cold up here in Norway.
<T-Bone> lol
<T-Bone> Mithrandir: btw if you need it right wrt lib32gcc1... I can let it on 24/7 if needed :)
<Mithrandir> T-Bone: I'm going home now.  If gf is sleepy, I might fix it now so it's ready when preview freeze is over.
<Mithrandir> I'll let you know in 30-ish minutes
<T-Bone> perfect
<T-Bone> thx alot :)
<Mithrandir> T-Bone: ok, home, Karianne is already in bed, so I can hack the ia32-libs stuff.
<T-Bone> hehe ok
<T-Bone> hold on, booting the beast
<T-Bone> there it goes. Give it 2' and it'll be all yours :)
<T-Bone> feel free to dist-upgrade if needed
<Mithrandir> shouldn't need to
<T-Bone> whatever you want :)
* lamont notes that t-bone has turned into the 'willy switch'
<T-Bone> lamont: huh? :)
<lamont> I used to have willy walk over and power-cycle my A500 in my cube in 5L.
<lamont> hence, willy switch.
<lamont> far better than X10. :-)(
<lamont> more expensive, too
<T-Bone> lol
<T-Bone> damn you :)
<lamont> oh where oh where is fabbione...
<T-Bone> to bed
<T-Bone> not necessarily sleeping, mind you ;)
* T-Bone ducks
#ubuntu-kernel 2006-03-13
<fbond> hi
<fbond> i see the dpatch system has been dumped for the ubuntu kernel
<fbond> what is the new method?
<infinity> We're maintaining it directly in git now.
<fbond> right
<infinity> https://wiki.ubuntu.com/KernelGitGuide
<fbond> i guess I can assume git is not much like other version control systems
<infinity> Are any of them like the others? :)
<fbond> heh
<infinity> It's a distributed revision control system, perhaps like arch/baz/bzr, but not at all like them at the same time. :)
<fbond> hmm
<fbond> I found the old system convenient
<fbond> to package a custom-patched kernel
<infinity> (But git is what's used by kernel.org, so it's simplest for us to also use it to do rapid merging and cherry-picking of patchsets)
<fbond> i just needed to add a patch to the debian/patches dir
<fbond> ok
<fbond> I guess I'll go learn that then
<infinity> It speeds up our development a fair bit to be able to track upstream changes without doing it all manually.
<fbond> this makes sense
<fbond> upstream releases diffs though, too, eh?
<fbond> :)
<infinity> Massive monolithic diffs.
<infinity> If you want to track small changesets, or one specific branch of a driver, you either get to do it all by hand, or you do it with git.
<fbond> i see
<infinity> With git, we get branch history (and tracking) for free, so we can udate a specific driver to current, or cherry-pick a fix here and there without worrying about patch conflicts and other craziness.
<fbond> ok ok i'm sold enough
<fbond> :)
<fbond> infinity
<fbond> okay, i'm back
<fbond> I'm looking at this git stuff, and wondering how I can use it to git the diff from vanilla 2.6.15 to ubuntu 2.6.15?
<fbond> er not git the diff ... get the diff
<fbond> or generate it, anyway
<dilinger> that's a nice rally cry.  git the diff!
<fbond> yes, well git is complex enough that i can't relate to your positivity here
<fbond> svn diff -r 0:HEAD seems easy
<fbond> git diff ??? HEAD ?
<fbond> what is ???
<fbond> if I want to have a diff from 2.6.15 to Ubuntu's 2.6.15?
<infinity> If you want to generate the diff with git, you need to know the tag that represents 2.6.15
<infinity> Alternately, you could just diff against a tarball. :)
<fbond> hmm, well I can see how git makes it easier to apply patches, but it certainly doesn't make it very easy to figure out what's already been applied, unless I'm missing something
<fbond> and I should think the tag representing 2.6.15 would be fairly standard info to want...
<fbond> and I can't seem to find it anywhere
<dilinger> v2.6.15?
<fbond> brilliant
<fbond> with dpatch, it was clear what each incremental patch accomplished
<dilinger> more likely, you want v2.6.15.5 or something
<dilinger> http://kernel.org/git/?p=linux/kernel/git/chrisw/linux-2.6.15.y.git;a=summary
<fbond> how can I see the incremental patches that were applied by the ubuntu devs?
<mjg59> BenC_: Sent
<BenC_> thanks
<mjg59> BenC: Argh. ipw3945 requires newer ieee80211
<BenC> usual story :/
<mjg59> I'll send a patch anyway
<BenC> is that the new intel pro wireless driver?
<BenC> the one that requires a binary-only daemon?
<mjg59> Yeah
<mjg59> That'll need to go in restricted somewhere
<BenC> probably just add it to restricted-modules package so we don't have to create a new package
<fbond> Hi
<fbond> Shouldn't the ubuntu kernel be maintained as a separate branch in git?
<fbond> in other words, shouldn't master be upstream?
<fbond> it's very difficult to isolate the ubuntu changes in a meaningful way
<fbond> c
<BenC> doing it in a branch wouldn't help
<fbond> I'm having a bit of a hard time working with git to do what I want
<BenC> you can always git-fetch the mainline kernel into a local branch of an ubuntu-2.6 clone
<BenC> that's what I do
<fbond> okay
<fbond> and then do git diff to see the differences?
<fbond> but that creates a VERY large diff
<BenC> git-diff-tree
<BenC> git-log, and look for UBUNTU
<BenC> all of our changes have UBUNTU in the summary
<fbond> there's one pretty severe complication, I think
<fbond> back when dpatch was the norm, I could easily see the differences between 2.6.12, and 2.6.12-ubuntu
<fbond> now, that's difficult because the git repo includes ubuntu changes made prior to 2.6.15
<BenC> all the git changes were done during 2.6.15 development
<fbond> ok
<fbond> will ubuntu sync with upstream's git repo at every new minor version?
<BenC> it's not really the intention of the repo to make it easy to disect each individual patch between our kernel and mainline
<fbond> i figured that out already
<BenC> yes, after dapper, we will move on to 2.6.17-git
<fbond> I had packaged an alternative kernel (-ck) on breezy
<fbond> it was much easier then
<BenC> most of the local changes will be rebased (so deltas are against newer changes)
<BenC> why is it so hard now?
<BenC> you apply a diff, and recompile
<fbond> not really
<fbond> with larger patch sets it's likely you will have two incompatible patches
<fbond> or more than two
<fbond> it's nice to be able to selectively remove patches
<fbond> for instance, try to package an -mm kernel using the ubuntu git repo
<fbond> that is more complicated than anything i'm doing
<BenC> our repo isn't really meant for that type of thing
<fbond> yeah... using dpatch it was much easier.  what approach would be the closest approximation, using the new git repo?
<BenC> using dpatch was much harder for us
<fbond> i can see that
<fbond> it makes sense ultimately, given the priorities
<BenC> right, it was stricly a maint decision
<BenC> plus being able to interoperate with upstream was a huge bonus
<fbond> yes, I understand the benefits.  Trying to do what I'm trying to do is maddening, though.
<fbond> Any advice you might have as to how I can simplify this would be appreciated.
<BenC> what sort of patches are you incorporating?
<fbond> I had done -ck on breezy.  This is is a patchset for reducing latency.
<fbond> Now I'm looking at -rt, which is more aggressive.
<fbond> It's a fairly significant patch set
<fbond> And needs to be applied before the Ubuntu changes, IMO
<fbond> Otherwise, resolving conflicts is very difficult, and likely to lead to a broken kernel
<BenC> IMO, that -rt patch is not a good idea against our kernel at all
<BenC> it touches a lot of drivers, and all of our non-stock drivers would be left broken
<BenC> IMO, it would be best to have it against a stock kernel
<BenC> 2.6.15.5 for example
<fbond> hmm
<fbond> perhaps -ck is a better choice in the first place, then
<BenC> I looked at that patch before, and it was not trivial at all
<fbond> No.  But if it was, it wouldn't be worth creating an alternative package for :)
<BenC> you could use stock 2.6.15.5, copy our configs, and rebuild for generic systems (i386, k7, 686, smp)
<BenC> using make-kpkg
<fbond> Well, my ultimate goal is to keep as many non-stock drivers as possible
<fbond> You do a great job creating a kernel package with extremely good compatibility
<fbond> I want to preserve that work ,if possible
<fbond> My breezy machine at home runs 2.6.12-ck6, and it runs extremely well.  Almost all Ubuntu changes to stock 2.6.12 are preserved.  Splash screen works still.  Etc.  It's much more ideal than creating an anti-Ubuntu -rt kernel package.
<fbond> And it builds just like the Ubuntu packages.  apt-get source linux-source-2.6.12-ck6 ... dpkg-buildpackage -rfakeroot ...
<BenC> the only thing I can suggest is just fixing the failed patch chunks and rediffing
<BenC> I mean, we haven't create a lot of incompatible changes to our kernel, so your most likely problem is just patch offsets, or slight variations in portions of the code
<fbond> hmm.  ok.  for the record, i disapprove. :)  thanks for your help.
<jbailey> BenC: ping?
<BenC> jbailey: pong
<jbailey> BenC: Do we have a wiki page on the Right Way to build your own drivers from source?
<jbailey> Like, with all the packages that need installing, etc?
<BenC> not that I know of, but basically it involves installing the linux-headers-2.6.15-VER-FLAVOUR you want to build for
<BenC> apt-get install build-essential linux-headers-`uname -r`
<BenC> that should do it
<BenC> probably don't even need build-essential, but it helps cover things
<jbailey> 'kay.  The sets up the /lib/modules/`uname -r'/build links and everything?
<BenC> yep
<jbailey> Without build essential, they won't get far anyway. =)
<BenC> probably not
<BenC> I don't think linux-headers depends on gcc, binutils, or make
<jbailey> BenC: Got a sec to preview: https://wiki.ubuntu.com/KernelSourceDriver ?
<BenC> jbailey: ..
<jbailey> BenC: I'd like to be able to point them at a web page that has the instructions.  That way it's something a little warm and fuzzy.  Documentation almost always feels cuddly.
<BenC> looks good
<makx> jbailey: ubuntu uses the smp alternatives patch for x86 and amd64 surprises me that you speak of up/smp flavours
<makx> thought they would only be left for ppc
<jbailey> makx: Think breezy.
<makx> ok.
<jbailey> I guess I could make that more clear, though.
<jbailey> I mostly want to drill into people that "Integration is good.  Try hardest to do that.  Life will suck less."
<BenC> jbailey: drill it more that they should go upstream to linus instead of "can you include this in ubuntu"
<BenC> like use an impact chisel to pound it in :)
<BenC> we, (dist kernel developers) usually catch a lot of flack from upstream for including non-stock drivers in the dist, because it prolongs the driver from getting into upstream
<jbailey> BenC: Refresh and reread the top part?  I'm wondering that that change is enough.
<makx> only missing the review part of the submission cycle
<BenC> * Getting your driver integrated into upstream means it will not break because of kernel API changes, it also means all of your users (single and distribution) will always have access to the latest version.
<makx> but i guess that's what those are afraid of
<BenC> that's a separate doc that I am writing
<BenC> jbailey: that kind of combines two of your other points, so feel free to ignore it :)
<jbailey> Does upstream commit to fixing your driver on api changes?
<jbailey> ACtually, I think it's probably enough.  Most people will probably just ignore that section anyway.
<cjb> jbailey: In general?  Yes, the proposer of a new API is expected to patch drivers using the old one.
<jbailey> Ah, interesting.
<cjb> "The Kernel ABI can change from time to time." # What does this mean, syscalls?
<jbailey> Driver ABI
<cjb> Syscalls don't change during a kernel series.  The API can change, but that's the whole point.  You might want to link to Documentation/stable_api_nonsense.txt .
<jbailey> Well, IIRC syscalls are simply supposed to never change.
<BenC> cjb: ABI is not syscalls
<BenC> ABI is any function that is EXPORT_SYMBOL'd for use by modules
<BenC> if the calling conventions change, then the driver/module ABI changes, which means modules have to be recompiled
<BenC> it's the whole basis for the linux-image-2.6.15-ABI-ARCH naming
<cjb> I see.
<cjb> BenC: Did you know that the driver maintainer document you just posted to lkml has broken wrapping?
<mkrufky> BenC: cI just saw your LKML documentation update ..... it's difficult to review it in blob form though... Is this a new document, or a new version of an already existing one?
<mkrufky> (i thought Ive seen this before, but not compeletely sure)
<BenC> cjb: my email client probably wrapped different then my editor
<BenC> mkrufky: update of a document I posted previously
<BenC> mkrufky: it's never been included anymore, so it's basically "new"
<BenC> s/anymore/anywhere/
<mkrufky> ah, ok makes sense... i'll read it over then... i'll rreply if i have any comments
<mkrufky> thanks
<Mithrandir> BenC: it seems like readahead and unionfs aren't too friendly, especially not in vmware.
<BenC> Mithrandir: that's the unionfs/squashfs oops that's been occuring all along on ppc
<Mithrandir> BenC: I see it on i386 too, though
<BenC> mkrufky: thanks
<BenC> Mithrandir: yeah, it's a condition that isn't ppc specific, it's just racey and arbitrary
<Mithrandir> unsure if it's there on real hardware or not, but it's definitively there under vmware, to the point of having the live cd unusable with readahead.
<Mithrandir> any chance we can get it fixed or should I disable readahead?
<BenC> I have a bug report about it on actual x86 hw
<BenC> Mithrandir: just use squashfs 3 :)
<BenC> that fixed it on ppc
<BenC> other than that, the squashfs author is looking into why unionfs and squashfs are acting like this
<BenC> s/acting/interacting/
<Mithrandir> yeah, it'd be nice to have it resolved
#ubuntu-kernel 2006-03-14
<allee> [17:21]  <allee> Sun Galaxy X4100: mpt* drivers in dapper.  Two (or one) simple disk are detected during installation. When 2 disk configured as RAID1 in the LSI controller, kernel fails to detect the disk
<allee> [17:22]  <allee> scsi0 : ioc0: LSISAS1064, FwRev=01040000h, Ports=1, MaxQ=511, IRQ=169
<allee> [17:22]  <allee> Is this a limitation of the driver or a bug?
<allee> [17:23]  <allee> SLES9 has no problem with the RAID1 of the LSI controler.  And uses it as sda.
<allee> [17:28]  <allee> SLES9 uses: Fusion MPT SAS Host driver 3.02.62sus
<allee> [17:28]  <allee> ubuntu uses:
<allee> [17:28]  <allee> Fusion MPT SAS Host driver 3.03.04
<svenl> hi guys ...
<svenl> is it true that you guys dropped the mkvmlinuz support for the dapper linux-image kernel ? 
<svenl> i heard a report claiming it was because "nobody uses oldworld machines anymore", which seems likevery clueless ...
<mjg59> We've never supported oldworld machines
<mkrufky> what is 'oldworld' ?
<mjg59> mkrufky: Pre-imac and blue and white G3s
<mjg59> When those were introduced, Apple went to a new Open Firmware version
<mjg59> So the ended up being called "old world" and "new world" macs
<svenl> mjg59: yeah, but the mkvmlinuz support patch was not there for oldworld, but for chrp machines, including IBM chrp and genesis's pegasos machine.
<mkrufky> ah, okay
<svenl> mjg59: and genesis was just added recently as a ubuntu partner, so i doubt that sabotaging the pegasos support this way is the right thing to do.
<mjg59> svenl: If you are going to describe it as "sabotaging", then this conversation is over
<svenl> mjg59: well.
<fabbione> mjg59: ++
<makx> thanks
<svenl> mjg59: oh well, i will let my hierarchy handle this with the ubuntu hierarchy, but this is a repeat of what happened for the breezy release, so i am not overly sympathetic, especially since the ubuntu kernel guys are making noises about unification of the ubuntu kernel with the debian kernel on public forums and such.
<mjg59> Drive-by svenning
<fabbione> uh?=
<fabbione> what noise?
<fabbione> when?
<fabbione> wth is he talking about?
<mjg59> No idea
<fabbione> neither do i
<dilinger> sorry guys, that was probably my fault
<mjg59> I don't think Sven can ever be anyone else's fault
<dilinger> the fact that he's re-evaluating ubuntu-kernel, that is
<dilinger> heh
<mjg59> Have you kicked him off debian-kernel yet?
<dilinger> no, i just angered him.  i intend to get him ejected from the project completely.
<fabbione> dilinger: LOL
<dilinger> fabbione: btw, you have any pointers to architecture/design of ocfs2?
<fabbione> dilinger: the code?
<fabbione> it's the "usual" clustered FS
<fabbione> all transactions needs to go trough the DLM
<fabbione> it's journaled like ext3 (same backend)
<dilinger> fabbione: a coworker's evaluating cluster filesystems (pvfs2, gfs, ocfs2, etc)..  i had was hoping for something to pass along for him to read
<dilinger> since he can't seem to find details about ocfs2
<fabbione> dilinger: you can check on oss.oracle.com
<fabbione> the project is hosted there
<fabbione> but the concept behind each clusterFS is the same
<fabbione> and that's where the real power of FS comes frok
<fabbione> from
<fabbione> the Distributed Lock Manager
<fabbione> performance of the FS are highly dependent on that
<fabbione> also.. ocfs2 is the simplest one around.. at least that i have seen
<fabbione> it's really basic clustering
<fabbione> a more complete suite is the GFS/RH cluster
<dilinger> fabbione: simplest in terms of implementation?  features?
<fabbione> features
<fabbione> in my experience:
<fabbione> - ocfs2 is faster, but needs more manual tuning to handle the timeouts between nodes properly. It does "only" cluster FS
<fabbione> - gfs/rh cluster suire is generally slower, no need of manual tuning, it offers a complete suite for clustering, from shared IP, switching services, etc.
<dilinger> ok, thanks
<BenC> damn, I missed sven and his FUD
<torkel> dilinger: Lustre might be interesting for him to take a look at too; http://www.clusterfs.com/
<dilinger> yep
<dilinger> i've been following lustre development ever since the clusterfs people abandonded intermezzo
<torkel> would be nice to see it in Ubuntu :-)
<dilinger> yea
<dilinger> i was going to package it for debian ages ago
<dilinger> but decided not to based on their release policy
<dilinger> they've changed it since, but i haven't had time to look at it again
<dilinger> i may still package it
<dilinger> i think mrvn took over my ITP
<torkel> a co-worker did a quick-a-dirty package of it last week
<torkel> not sure how far he got though
<dilinger> i'd be interested in seeing it
<dilinger> like i said, my coworker's evaluating different cluster filesystems; if we decide to go w/ lustre, i'll probably end up maintaining packages
<dilinger> quick-and-dirty packages makes it that much easier for him to try out
<torkel> he is on vacation this week, but if you send me a mail (otherwise I will forget it) I can ask him to get in touch with you
<jbailey> BenC: Around?
<BenC> jbailey: yeah
<jbailey> BenC: Are you packaging newer kernels at all for testing?
<jbailey> I thought I saw some reports of some threading stuff fixed in newer kernels.  If you've already got a set built, I might poke my head into them.
<jbailey> threading and signals.
<BenC> jbailey: haven't had a chance to start merging to newer kernels yet
<jbailey> No worries.  I'll try to remember how to build one myself for the test.
<jbailey> None of it's a regression from previous, but on some arches there are weird nptl responses and such.
<fabbione> jbailey: jumping from .15 to .16 is a big step due to all the mutex changes
<fabbione> merging back is difficul
<fabbione> +t
<jbailey> fabbione: Right, I'm not expecting to backport anything, more just curious if these are the problems refered to.
<jbailey> fabbione: I'm trying to figure out what the path to actually getting clean glibc results is.
<bronson> Anybody here able to boot in recovery mode?
<bronson> Regular mode works fine.
<bronson> Recovery mode kernel panics pretty early on.
<bronson> Dunno when this started...  I don't go into recovery much.
<bronson> Just wondering if this is a me-only thing, or are other people seeing it too?
<bronson> (dapper, upgraded last night)
#ubuntu-kernel 2006-03-15
* infinity curses his upstream.
<infinity> ~30 mins until LRM is uploaded.
<infinity> BenC: Are we going to see updates to all the ipw drivers?  (mjg59 has pinged me about the craziness we have to go through to get ipw3945 in)
<infinity> BenC: I'm pretty keen on the idea that my ipw2915 may actually stop resetting the firmware every 5 seconds (and occasionally hanging the card, just for fun)
<BenC> yeah, I plan to try
<BenC> the only showstopper would be any major problems with the ieee80211 update
* infinity nods.
<infinity> But that'll be needed for 3945 anyway, which we apparently "ARE SUPPORTING", however painful that is.
<infinity> Or so I've been told. :)
<infinity> After unpacking 331MB disk space will be freed.
<infinity> But I didn't have a bunch of obsolete kernels installed or anything...
<BenC> openoffice removal?
<infinity> No, seriously.  That was kernels.
<infinity> Only 4 of them.
<infinity> -13- -14- -15- and -16- and the matching LRM for each.
<mjg59> Yeah, Mark's keen on new Centrinos being supported (even though we have no test hardware)
<infinity> TBH, I'm pretty keen on it too.
<infinity> I'd LIKE to get some test hardware before release, but I have a feeling my dreams of a new T60 won't be fulfilled until a few weeks AFTER release, sadly.
<infinity> Maybe Mark's X60 will come in the mail soon.
<mjg59> Haha
<infinity> Entertainingly, we'll be 0 for 2 on wireless on new Thinkpads right now.
<infinity> Since, if you order with "Intel Wireless", you'll get a 3945, and if you order "IBM Wireless", you'll get a new Atheros that requires madwifi-ng.
<BenC> mjg59: Mark ok'd me to expense a PCIE version of the 3945, so I can test it
<mjg59> BenC: It's only available in mini-PCIE form-factors, to the best of my knowledge
<BenC> mini == the 1" long PCIE slot?
<mroth> FWIW, while I'm not doing any dev for you guys currently, I have a X60 with the 3945 thats supposedly arriving next week, so I can run some tests on it.
<mjg59> BenC: No, one that looks like an so-dimm socket
<BenC> do you know of any product names with the chipset?
<infinity> I doubt anyone except Intel makes them.  Intel's not known for allowing 3rd party board manufacturers to make shoddy network cards with their chipsets.
<BenC> nm, google found some for me
<BenC> yeah, I see that now :)
<BenC> http://www.dreamhardware.com/store/product/index.php?product_id=500437
<BenC> that looks close to what my short PCIE slot looks like
<BenC> nm, I see what you mean now
<BenC> it sort of lays into the slot and clicks down
<mjg59> Yeah
<mjg59> It ends up parallel with the motherboard
<BenC> right
* BenC listens to the "happy happy joy joy" song
<BenC> any chance that make an adapter board that fits a normal PCIE slot and can take the mini-PCIE card?
<infinity> Ahh, Stimpy, we hardly knew ye.
<mjg59> BenC: No idea, I'm afraid
<BenC> "I told you I was going to shoot, and you didn't believe me...WHY DIDN'T YOU BELIEVE ME!?"
<infinity> My T43 might be mini-PCIe, you could just have it sent to me.
<infinity> I'd have to crack it open to prove this theory, though.
<mjg59> T43 will be mini-PCI
<infinity> Yeah, so a quick Google tells me.
<infinity> I knew bits of it were PCIe internally, so it was worth a shot.
<BenC> crazy...some sells a PCIe serial card with ONE 9pin serial connection
<BenC> for 90 fucking dollars
<infinity> Yay progress.
<BenC> http://www.cdw.com/shop/products/default.aspx?EDC=915856
<BenC> "High speed UART, up to 230Kbps"
<infinity> We went from "serial is always onboard", so "if you want a spare port you can get it on an ISA card for 5 bucks", to "make that PCI for 15 bucks", to "a USB dongle for 25 bucks?", and now "PCIe for 90!!"
<BenC> super duper
<infinity> s/so/to/
<mjg59> USB's not good enough for debugging
<BenC> like, PCIE is really adding performance to a 230Kbps serial connection
<mjg59> Whereas with PCIE, you can decode legacy addresses and just have stuff outbing
<infinity> Sure, but is that 90 dollars worth of debugging potential? :)
<mjg59> If you've got no other way of debugging the damn thing, probably
<infinity> I think the answer here is to pick up an old macihne that still has an ISA bus. :)
<BenC> or by a PCIe mobo with built-in serial
<mjg59> And when you're debugging your new PCIE laptop? :)
* infinity was rather miffed to discover the lack of serial port on his Thinkpad...
<BenC> mjg59: your laptop has a PCIe slot like a desktop? :)
<infinity> BenC: If it has built-in serial, it probably has an ISA bus. :)
<mjg59> "Microsoft revealed today that it will not support EFI booting for Windows Vista on its launch. The news will be a shock for owners of Intel Macs who had hoped they would be able to dual-boot between Windows Vista and OS X."
<mjg59> BenC: Oh, real PCIE?
<mjg59> Fuck that, then
<infinity> I'm pretty sure my girlfriend's machine still hangs the PS/2 ports, parallel and serial all off a legacy ISA bus stapled to the rest of the system.
<mjg59> Well, they'll all be in a superio chip that's probably integrated into the southbridge
<infinity> (Which consists of an ISA bus, a PCI bridge, and some other goodies, on one chip)
<BenC> well, I can find mini-PCI-to-PCI adapters, but not PCIE
<infinity> So, what you need now is a mini-PCIe to mini-PCI bridge, and you're set!
<BenC> hehe
<infinity> (Or, find someone who actually has one of these laptops already)
<infinity> I see them on eBay with next day shipping, oddly enough.
<tseng> is there a reason there is a linux-image-amd64-server and not linux-image-amd64-xeon-server?
<BenC> tseng: yeah, because the higher end supports both configurations
<tseng> BenC: so which kernel would I ideally be using on a bunch of 2 way HT Xeons with emt64?
<tseng> adm64-server?
<BenC> for desktop, xeon, for server, just -server
<tseng> great, i noticed -xeon had preempt and other desktop weirdness
<tseng> thanks.
<BenC> np
<crimsun> BenC: I can attempt to set up a server, but I don't have access to rookery/people (I don't think so, at least?)
<crimsun> (lacking a server is pretty much the sole reason I've had to use git-format-patch)
<crimsun> BenC: two of those messages are awaiting moderation, the huge one for patch_realtek.c and a smaller one for patch_analog.c
<BenC> ok
<BenC> crimsun: you are an @ubuntu.com right?
<BenC> aka a Canonical emplyee? :)
<crimsun> BenC: because of MOTU, yes
<crimsun> no, not an Canonical employee
<BenC> ah, ok
<BenC> bad assumption on my part then
<infinity> Tsk.
<infinity> BenC: Know thy coworkers.
<infinity> BenC: For instance, I got fired 5 months ago, but I'm sure you didn't know.
<tseng> infinity: he needs to play the distro team game
<BenC> lol
<zul> heylo
<crimsun> heya
<netzmeister> hello
<netzmeister> where is my "/proc/config.gz" ?
<netzmeister> or where can i find my actual kernel config to build a newone..
<mjg59> /boot/config-`uname -r`.gz
<mjg59> Sorry, no .gz
<netzmeister> yes, at this moment i found it.. o_O
<netzmeister> thx
<dilinger> hm
<dilinger> Called the General Parallel File System (GPFS), the technology allows for high-speed access to files across multiple nodes of a Linux or AIX cluster.
* dilinger wonders if it's Free
<torkel> dilinger: it's not free
<jbailey> Anyone here played with Xen?  I'm wondering if it's possible to expose that we're in a Xen guest through a HWCAP.
<jbailey> I've been thinking that we could, with Dapper+1 provide a Xen-safe glibc that doesn't do the slow TLS accesses.
#ubuntu-kernel 2006-03-16
<dilinger> torkel: do you know what their plans are for it?
<dilinger> jbailey: horms has been hacking on xen at work
<dilinger> jbailey: might wanna talk to him
<jbailey> dilinger: Thanks.
<debugger> hello
<debugger> I have linux-image-2.6.12-10-686, but the latest available sources is kernel-source-2.6.11.   where is the 2.6.12 sources package?  or its build from the .11?
<torkel> dilinger: unfortunately not 
<jepler> Hi.  I'm trying to change the kernel on the live cd, but 'kernel-wedge gen-control' doesn't seem to create a proper control file.  A subsequent 'dpkg-buildpackage' says 'error: control file must have at least one binary package part'
<aquarius_sxsw> are the bcm43xx drivers in dapper ok? I'm having no luck getting the card to actually connect, although it's recognised and configurable.
<mjg59> aquarius_sxsw: Try dropping your rate to 11M
<aquarius_sxsw> mjg59: have done
<aquarius_sxsw> with a post-up in /e/n/interfaces
<aquarius_sxsw> and iwconfig says it agrees
<mjg59> Hm. Odd.
<aquarius_sxsw> yep ;(
#ubuntu-kernel 2006-03-17
<jdahlin> (re-asking question asked in #ubuntu-devel) Was CONFIG_KPROBES recently turned on in ubuntu kernels?
<BenC> jdahlin: it's disabled on all our architectures
<jdahlin> BenC: just curious, do you know why?
<BenC> because it's meant for kernel testing and debugging
<BenC> and generally if you are doing debugging and testing of the kernel, you are compiling your own
<jdahlin> developers are also ubuntu users
<jdahlin> I'm mainly asking, because I'd like to run systemtap
<jdahlin> and I'm not really interested in recompling my kernel
<BenC> it isn't a matter of developer....kernel developers are building their own kernels
<BenC> what is systemtap?
<jdahlin> 'dtrace for linux'
<jdahlin> http://www.google.com/url?sa=t&ct=res&cd=3&url=http%3A//www.redhat.com/magazine/011sep05/features/systemtap/&ei=LX4TROzjAZ6wqQKb7oWYDQ&sig2=Wov4CjGvzajGwoweaSbqtQ
<jdahlin> oops
<jdahlin> http://www.redhat.com/magazine/011sep05/features/systemtap/
<BenC> KPROBES is also marked experimental
<BenC> isn't dtrace a kernel level tracing tool?
<jdahlin> are experimental features generally turned off in stock kernels?
<jdahlin> yes, but useful for monitoring applications
<BenC> yes, generally, unless enough demand warrants it
<jdahlin> fedora might have turned on by default
<BenC> but this is only the first request
<jdahlin> systemtap seems pretty new, I haven't actually managed to use it (since it requires a kernel recompilation)
<BenC> it's a little late in dapper cycle to enable it, maybe propose it for dapper+1
<jdahlin> but assuming it can do useful things, it should probably be turned at some point (when both kernel and user space matures)
<jdahlin> sure, I'm not proposing turning it off just yet
<jdahlin> err, on
<jdahlin> BenC: sounds good. I'll investigate the tool and file a bug for turning on CONFIG_KPROBES for dapper+1 iff it turns out to be useful
<triceratops> Will the needed fglrx kernel modules be in dapper to fix bugs #32332 and #34314?
<nhaines> Hello, everyone.  :)
<nhaines> It's quiet here, so I'll check back later.  Good bye, all.
<lotu5> hello all...
<lotu5> i'm having a little trouble building the softmac module to get my airportextreme card working... can anyone help a bit?
<lotu5> specifically, i'm getting this error: make[1] : Entering directory `/lib/modules/2.6.15.1/build'
<lotu5> make[1] : *** No rule to make target `modules'.  Stop.
<lotu5> anyone here?
<ppd> hi. building lirc modules doesn't work in dapper. is that known?
<zyga> does standard dapper kernel omit any soundcard drivers?
<ppd> hello, I was sent here from ubuntu-desktop with that question. Can it be that the ingain channel is missing on dapper for c-media soundcards?
<netzmeister> anybody in da house? :-D
<netzmeister> anybody in da house? :-D
<netzmeister> how can i use ioperm in my kernel modul?
<netzmeister> Warning: implizite declaration of function ioperm
<mjg59> netzmeister: You can't. It's a userland call.
<netzmeister> any alternatives?
<mjg59> Why do you need it?
<mjg59> The kernel can read/write any io ports it wants
<netzmeister> i develop a kernel modul to read my uGuru MainBoard controller.. (CPU temp etc..)
<netzmeister> mjg59:  That's nice to hear.. ;-)
<netzmeister> do you've any code example for me?
<mjg59> No
<netzmeister> :-(
<mjg59> You can just use inb and outb
<netzmeister> okay
<netzmeister> yes it works..
<netzmeister> i convert a "userland" source in a kernel module source..
<netzmeister> i do not need the ioperm function..
<netzmeister> '/* ioperm......    */ and all is fine. ;)
<netzmeister> mjg59:  Are you there?
<mjg59> netzmeister: Hi
<netzmeister> hi
<netzmeister> one question..
<netzmeister> i have two source files..
<netzmeister> one.c  and   two.c
<netzmeister> in one.c i use some functions which are in two.c
<netzmeister> but i don't know how i should create the makefile
<netzmeister> (i will create a kernel module)
<mjg59> netzmeister: If it's a kernel module, you need to look at the makefiles in the kernel
<mjg59> The only supported way of producing kernel modules is to use the kernel build system now
<mjg59> (Even if you're building outside the kernel)
<netzmeister> kernel build system?
#ubuntu-kernel 2006-03-18
<netzmeister_> mjg59:  The problem  further  exists :-(
<netzmeister_> all the examples are with one file..
<mjg59> Just list both files
<netzmeister_> uguru.c    ugurufunc.c
<mjg59> No, in the makefile
<netzmeister_> how? ;-)
<netzmeister_> obj-m += uguru.o
<netzmeister_> uguru-objs := ugurufunc.o
<netzmeister_> all:
<netzmeister_> 	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
<netzmeister_> cleanall:
<netzmeister_> 	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
<netzmeister_> sorry for spamming..
<netzmeister_> thats my makefile
<mjg59> uguro-objs := ugurufunc.o uguru.o
<netzmeister_> i have the problem...
<netzmeister_> yeah...
<netzmeister_> uguru.c  must renamed to uguru_core.c (or anything else..)
<netzmeister_> yes baby..
* netzmeister_ is dancing like Usher...
<netzmeister_> mjg59:  Can i create a procfs File in a usermode programm?
<netstar> interested?
<netstar> I was speaking to benh about it the other day, I was kinda hoping windfarm would be working for dapper, but if not this could be a temporary solution
<BenC> the daemons are already on the system
<netstar> they are?!?!?
<BenC> or installable, I would guess
<BenC> no, there is pmu
<netstar> this is different
<netstar> pmu is older macs
<BenC> I know that
<BenC> no, it's not
<BenC> my brand new powerbook has pmu
<netstar> :P okay my bad
<BenC> if there are tools, find out what they are and make sure it works as you expect
<netstar> I have 6 months testing with it
<netstar> It's not quite as quiet as windfarm
<netstar> what should I do then?
<netstar> file a report?
<BenC> you could start by telling me the name of the tool and where you got it from :)
<netstar> OKay this is a problem, I got it from ppc mailing list AGES ago.. The author's name is long gone (sadly) even benh has no recollection of it, but it;s a python script named simpleTemp.py
<netstar> would you like a copy?
<netstar> google now has no references to it
<BenC> hmm, ok
<netstar> it works VERY well
<netstar> even turns on the light :P
<fabbione> hey guys
<netstar> How should I send it to you?
<fabbione> BenC: can you please pull from me?
<fabbione> BenC: i have only the linux-kernel-devel meta package
<fabbione> we should also get git-core in main
<BenC> ok
<netstar> BenC: Found it!
<netstar> http://ozlabs.org/pipermail/linuxppc64-dev/2005-September/005307.html
<fabbione> BenC: thanks dude
<BenC> netstar: thought you said "AGES ago" :)
<netstar> :P
<netstar> I'm new to this kernel timeline
<BenC> hehe
<Petaris> does the x86 kernel support smtp and greater then 4 GB of ram?
<Petaris> er, smp not smtp
<netstar> it can support 64GB
<netstar> "CAN"
<netstar> newer models anyway, but I think it's a complete hack
<Petaris> I'm downloading drapper 5 for an edubuntu ltsp server
<Petaris> I have a dual opteron box with 8 GB ram
<Petaris> will it work out of the box?
<mjg59> Petaris: The server kernel supports more than 4GB of RAM
<mjg59> The others don't
<Petaris> ok
<Petaris> Are there any issues with building a custom kernel?
<mjg59> As long as you keep much the same config, no
<Petaris> ok, cool
<Petaris> thanks, I might be asking more questions in a bit
<Petaris> mjg59J: I assume the server kernel also supports smp?
<mjg59> Petaris: Yes
<Petaris> ok, thanks
<ppd> hi. can it be that current lirc-modules-source cannot be compiled with the current kernel?
#ubuntu-kernel 2006-03-19
<stoat> guys, got a small problem on a ppc laptop
<stoat> trying to plug in a prism card. I'm getting error that there's no driver, it looks to be looking in wrong place
<fbond> hello
<fbond> how does build/linux-source-XXX/conf.vars get built?
<fbond> anyone know?
<fbond> i'm mostly interested in changing the value assigned to APPEND_TO_VERSION
<fbond> but I can't figure out where to do that
<fbond> nevermind, found it
<fbond> I find asking others is sometimes the best self-motivation for finding the answer yourself
<fbond> strange...
<heatxsink_> hello all, anyone in here familar with mounting an ipod over firewire via a Sound Blaster Audigy's Firewire port?
<fabbione> BenC: ping?
<fabbione> .12:
<fabbione> Mar 14 13:30:46 baldios kernel: [4294673.021000]  Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
<fabbione> .15:
<fabbione> Mar 14 13:35:21 baldios kernel: [4294669.419000]  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
<fabbione> ^^ testing a fix for the poor guys, like me, that spend a day trying to figure why on earth they can't see their serial ports anymore
<ppd> hello, are there any news about the lirc modules issue in dapper?
<fabbione> BenC: please pull from me. update configs to fix a serial regression from .12
<BenC> ok
<ppd> again: will lirc-modules-source be fixed until the release?
<zul> heylo
<fabbione> BenC: thanks dude
<ppd> hi. lirc sources cant be compiled with current dapper kernel. is that likely to be fixed until the release?
<crimsun> as in upstream or lirc-modules-source/universe?
<ppd> lirc-modules-source doesn't compile (bug already exists). upstream doesn't compile; complains about bttv being too old
<crimsun> honest answer: It Depends.
<crimsun> time is extremely tight for all of us
<ppd> but it can't be that the whole infrared stuff doesn't work in a final release?!?!?
<crimsun> if you have time, we welcome your debdiffs
<ppd> https://launchpad.net/distros/ubuntu/+source/lirc/+bug/5343
<ppd> that's the bug
<bddebian> Hey folks, sorry to barge in but I am having an issue booting a server install of Flight-5 on a Compaq Proliant ML350.  It hangs after Freeing initrd ram
<bddebian> I have tried the following boot options:  acpi=off pci=noacpi noapic DEBCONF_DEBUG=5 BOOT_DEBUG=2
<zul> no idea..you arent using any special devices to boot are you?
<bddebian> Just a CD
<zul> not sure..
<bddebian> I don't know if anyone can help or cares, but I get pretty much the same thing booting Breezy:
<bddebian> 4294668.821000 ACPI: Looking for DSDT... not found!
<bddebian> 4294668.921000 not found!
<bddebian> Hang
<bddebian> I'm following you jbailey :-)
<jbailey> bddebian: Sure. =)
<jbailey> Stalker.
<bddebian> :-)
<bddebian> jbailey: Since you don't want to look at my ugly code, how are you at troubleshooting my boot problem? :-)
<jbailey> bddebian: I'm on the phone with a client at the moment, dude.
<bddebian> Oh, sorry
<zul> i think you might have to pay jeff :)
<bddebian> OK
<bddebian> :-
<bddebian> )
<jbailey> Only in sexual favours, though.
<jbailey> Got to make it good.
<zul> somehow i knew you were going to say that
* bddebian breaks out the whips and chains
<jbailey> Ugh.  The pilates class I want to take is in 30m.
<jbailey> I don't think I'll be off this call.
<jbailey> Ah well.
<zul> do you have like a headset to use?
<jbailey> It's in the shop. =(
<jbailey> I need to go pick it up today.
<zul> ah..
#ubuntu-kernel 2007-03-12
<zul> hey
<zul> BenC: I was talking abou the 2.6.20 xen not the paravirt xen, the problem with the paravirt-xen stuff is kernel-package, it see CONFIG_XEN and it treats the kernel as a subarch
<BenC> zul: so you were saying it was slow with xen + stock 2.6.20 ubuntu kernel?
<zul> yep
<fabbione> kylem: still around?
<joumetal> I am willling to help with bug 89380. 21-rc3 vanilla boots but 20-10.17 doesn't.
<Tm_T> Joujou
<zul> yo
<mrec> hmm what's the latest ubuntu kernel that comes with installation cds?
<mrec> the current one boots but doesn't detect the sata drive (kernel 2.6.17)
#ubuntu-kernel 2007-03-13
<elcasey> anyone home? I've got a pretty serious issue with Feisty
<jdong> I am accompanying elcasey on this one
<elcasey> yay! I have an escort to the danc...never mind
<jdong> possible Feisty kernel regression, kernel appears to hardlock when probing his chipset
<jdong> (storage chipset)
<jdong> hence system doesn't boot
<jdong> reproduced with Feisty LiveCD
<elcasey> initally I upgraded from Edgy, but LiveCD won't boot, either
<jdong> the chipset reportedly worked fine in Edgy
<jdong> elcasey: do you know what your storage chipset is?
<elcasey> no, lemme find out
<elcasey> it's Gigabyte brand
<elcasey> the spec sheet just says "GIGABYTE SATA II Controller"
<elcasey> so it's not Promise or anything
<jdong> elcasey: can you get on a Edgy or something and lspci?
<elcasey> I don't have an Edgy liveCD
<elcasey> I have full access to all my partitions from Windows, though
<jdong> elcasey: do you have any kind of Linux LiveCD?
<jdong> (that can boot up)
<elcasey> cool, found my Edgy Live
<elcasey> i'll reboot and come back...I don't know if my NIC will work from a LiveCD, though, certainly not from Edgy
<elcasey> it's a serious process to get this Ralink working
<elcasey> wait, I have the hackin9 live distro!
<jdong> elcasey: anything that can get you back here, with a mountable hard drive and a lspci command :D
<elcasey> anyway, lemme try the two livecds and see if any of them work
<elcasey> worst case, I'll install Solaris 10 and try that...I have a spare 10GB partition
<elcasey> jdong: I managed to boot 2.6.17-10 in recovery mode
<elcasey> it hung at the bootsplash earlier today
<elcasey> but I have the lspci info
<jdong> elcasey: I can't believe that worked
<elcasey> neither can I
<jdong> Feisty's not supposed to boot with edgy kernels.
<elcasey> for all I know, Feisty will boot now
<jdong> hehe hope for it
<elcasey> BUT, the hackin9 livecd didn't boot, it got the same error(s) when it tried to load the drives
<jdong> wow
<jdong> hmm
<elcasey> and it uses a 2.6.17-11
<jdong> that's real interesting
<elcasey> it's also Debian-based...and just like my install with -11, it dumped me to a BusyBox/ash prompt
<elcasey> I started to think it was everywhere, but *everything* works in Windows
* elcasey shrugs
<elcasey> shall I try booting feisty?
<jdong> meh give it a shit
<jdong> shot*
<jdong> ugh
<elcasey> heh, 10-4
<elcasey> if it fails, I'll go back to XP and send/pastebin you my lspci.log?
<elcasey> I just piped the output to a file
<elcasey> no dice with either version of 2.6.20-9
<jdong> what kind of error do you get booting up?
<jdong> that would be useful
<jdong> i.e. a recovery mode screencap
<elcasey> is there any way to force it to output all the startup stuff a logfile?
<elcasey> it doesn't give me errors, it just halts and all my HDDs spin down.
<jdong> umm, the boot messages stop somewhere.
<jdong> that's what I mean by error
<elcasey> It seems like it halts on discovering USB devices, but even if I unplug my USB HDD, it still halts
<jdong> no you can't log stuff before the system boots
<elcasey> I mean that it's not giving me a *specific* error message or code
<elcasey> it just...stops
<jdong> elcasey: yeah, screencap WHERE it stops.
<elcasey> how? Just PrtScr?
<elcasey> well whatever I cap with PrtScr will be gone when I reboot
<jdong> digital camera
<elcasey> lol
<elcasey> ok
<jdong> or patience and a keyboard :D
<jdong> or Vista wreck ignition
<elcasey> I think I'll take some photos
<elcasey> I'll try to pause it and see if I catch anything else
<elcasey> brb
<elcasey> jdong: I booted full-on into 2.6.10, but it's got "issues"
<jdong> heh what kind?
<elcasey> sda1 (Windows) doesn't mount and Beryl doesn't run at all (not concerned about that, currently)
<elcasey> it's just a bit "off"
<elcasey> presumably because the new kernel and some package replacements jacked some stuff around
<elcasey> but here's my lspci output - http://paste.ubuntu-nl.org/10112/
<jdong> well old kernels aren't supposed to work in Edgy
<jdong> err feisty
<jdong> I am totally shocked that it boots at all
<jdong> can you apt-get update and apt-get install ubuntu-desktop and apt-get dist-upgrade?
<elcasey> lemme check
<elcasey> it's hitting the repos, and they all say "feisty"
<elcasey> i'll definitely be doing a fresh install after my get my new HDD, but it'll be nice to have a working Linux system in the meantime (assuming tonight' kernel update makes some progress and/or old kernel keeps working)
<elcasey> dist-upgrade works, too
<elcasey> it's downloading quite a few packagaes
<jdong> elcasey: yikes jmicron chipset
<elcasey> jdong: you still need those screenshots?
<jdong> BenC can probably enlighten you more on the state of jmicron
<jdong> elcasey: but do file a bug report and attach the screenie
<elcasey> which screenshot? It doesn't always hang in the same place
<jdong> then attach two :)
<elcasey> ok...I think I took like five :P
<elcasey> jdong: what package should I report the bug in?
<jdong> linux-souce-2.6.20
<elcasey> thanks
<elcasey> jdong: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/91797
<jdong> elcasey: your eyes need to re-train
<jdong> look at your 00004.jpg
<jdong> look about 8 lines down
<elcasey> one sec
<jdong> bug 84964
<elcasey> ah ha
<elcasey> checking out the forum thread now
<elcasey> sheesh, not exactly an isolated problem
<elcasey> all-SATA + USB = Feisty hates you?
<jdong> no
<jdong> it's a JMicron controller regression as it seems
<jdong> but it's a confirmed critical bug.
<elcasey> any way for me to delete/retract my report?
<crimsun> reject it
<kylem> mark it as a dupe of 84964
<jdong> I already did
<elcasey> ok, thanks
<Mithrandir> BenC: I have an UVF request for git-core 1.5 ; do you have any thoughts on that?
<fabbione> Mithrandir: it's probably good to have new git
<fforw> hi..
<fforw> what would be the best place to report problems with a new kernel?
<BenC> fforw: launchpad
<fabbione> hey BenC 
<zul> hey guys
<abogani> BenC: May i disturb you for two very simple and fast questions about my spec (https://wiki.ubuntu.com/RealTime)?
<BenC> abogani: Sure
<abogani> I want to release all necessary packages to offer a complete solution for RT-Preempt in Ubuntu.
<abogani> 1) If i release all source packages of the all binary packages i'm ok with license (in particulary with restrcited-modules), right?  2) I should change name to my packages: What is, in you opinion,  better name? realtime-image (realtime-headers, realtime-source, realtime-restricted-modules etc) or linuxrt-image (linuxrt-headers, linuxrt-source, linuxrt-restricted-modules etc) ?
<abogani> BenC: Do you have any suggestions?
<BenC> abogani: 1) Yes, 2) Use a specific flavour like -realtime
<BenC> your suggestion is probably too confusing for users, plus I doubt you really want to build linuxrt-image-{generic,386,server,server-bigiron,lowlatency}
<BenC> So you'd have linux-image-2.6.20-10-realtime
<BenC> probably best to base it on the -generic config
<BenC> abogani: It would also mean you could do something intelligent like build-dep on linux-source-2.6.20 to build your kernels, just apply a patch for real time, and create the deb's (like what xen source does in universe)
<BenC> makes it easier to rebuild against newer kernel source too
<abogani> BenC I understand (i already use this flavours like naming), i cloned you git repositary and build my kernel with a AUTOBUILD=1 fakeroot debian/rules binary-debs flavours="realtime" :-)
<zul> scarey....since when xen became the model ;)
<abogani> BenC: My problem are (naming) source packages that not should conflict with official source packages.
<BenC> abogani: If you do as I suggested, you wont have a full linux tree source package
<BenC> but if you must do that (and I strongly suggest you don't :) then yeah, linux-rt-source-2.6.20 is a good name, but I wouldn't carry that name to the packages
<abogani> BenC: Ok. If i want to follow your suggestion (and thus not release a linux-rt-source-2.6.20) how i set source field in the my kernel package? I set this to linux-source-2.6.20 as like official kernel? People don't expect to find all source in source package (in this case you package don't have RT-preempt source obviously)? I don't break package policy? Sorry Ben i'm a stupid person. :-(
<BenC> abogani: Download the xen source package and check it out. You still have a source package, but it does not include the entire linux source tree. It build-depends on linux-source-2.6.20, unpacks it during build, applies the rt patches, and builds a -realtime flavour from it
<mrec> BenC: do you directly take the v4l-dvb repository from linuxtv.org for the ubuntu kernel?
<BenC> mrec: No, we use stock, unless there some important fixes which we might git-cherrypick from that repo
<BenC> In the past mkrufky has collected fixes for us into a repo we've pulled from
<abogani> BenC: I will do it, thank you very much!
<BenC> abogani: Np
<BenC> abogani: If you feel like writing a wiki howto for people who want to do kernel flavours like this, I can link it from the KernelTeam pages
<mrec> BenC: regarding my problems with some devs there, did you do anything? seems like the post of another developer calmed done the whole story at least
<mrec> the other question I have is regarding the ubuntu installation CD is there any installation CD with a recent kernel out there?
<mrec> it simply doesn't detect the SATA drive for that testmachine.
<abogani> BenC: Ok
<crimsun> BenC: thanks for the merges
<BenC> crimsun: Np, thanks for the patches
<Mithrandir> BenC: if you could ack or nack a new git-core, that'd be nice.  I don't really mind either way.
<BenC> Mithrandir: makes no difference to me, but I can't see it hurting anything
<Mithrandir> BenC: ok.
<kylem> BenC, git 1.5 changes the format of the .git dir...
<Mithrandir> kylem: not by default.
<BenC> kylem: does it change existing dir's?
<kylem> no.
<Mithrandir> at least not by default from how I read the LWN article
<kylem> Mithrandir, ah, it does it on hera.
<kylem> Mithrandir, which is how i found out about it when some of my scripts stopped working. :)
<BenC> kylem: Do we need new git to work with hera repo's?
<kylem> no.
<kylem> i still say we should have 1.5 in feisty tho.
<kylem> might as well be current.
<Mithrandir> I've approved the UVFe request, so we should get it
<kylem> ok.
<zul> right Im off to have a baby see you guys later..
<fabbione> it sounds like zul is going to give birth and not his wife....
<Lure> fabbione: ;-), probably the first
<BenC> crimsun: I have a build failure in one of your patches
<crimsun> BenC: patch_analog?
<crimsun> or hda_intel, hmm
<BenC>         ucontrol->value.integer.value[0]  = ac97->spec.ad18xx.swap_mic_linein;
<BenC> swap_mic_linein isn't defined, and neither is ad18xx
<crimsun> gah, let me pull that
<BenC> crimsun: Want me to push my current tree to have a look?
<crimsun> yes please
<BenC> planning an upload tonight, so trying to get some test builds done
<crimsun> ok
<BenC> crimsun: BTW, would sabdfl's sound being broken in -10 (regressed from -9) be fixed with the patches you sent?
<crimsun> BenC: possibly, though I don't remember Mark's SSIDs
<crimsun> I _think_ he used AD1986A?
<crimsun> oh wait, did Matt Z report that one?
<crimsun> Maybe I'm looking under the wrong reporter
<crimsun> right, bug 69529
<BenC> crimsun: pushed to kernel.org
<crimsun> BenC: thanks
<crimsun> BenC: do you know which hardware sabdfl was referring to for his sound regression in 2.6.20-10.17?
<BenC> crimsun: trying to find out
<crimsun> thanks
<BenC> crimsun: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio
<crimsun> BenC: can you get the subvendor and subdevice, please?
<kylem> it's an X60, iirc
<BenC> crimsun: I'm worried that he's gone missing...I'll keep trying
<crimsun> BenC: thanks.
<BenC> crimsun: How soon do you think before I can at least get the compile fix?
<crimsun> just emailed to you
<BenC> crimsun: Thanks
<crimsun> sorry for the thinko
<BenC> np
<BenC> crimsun: Do you have difficulty test compiling these patches?
<crimsun> BenC: not normally. I was up late. :/
<BenC> It's only like once in a blue moon you send me a thinko, so it's not a huge deal, but if you could just do a test SUBDIRS=sound compile it might help
<crimsun> sure, I'll use SUBDIRS=sound from now on, thanks
<BenC> crimsun: usually I do "mkdir /tmp/build; cat debian/config/i386/config{,.generic} > /tmp/build/.config; make O=/tmp/build oldconfig; make O=/tmp/build prepare; make O=/tmp/build SUBDIRS=foo modules"
<BenC> then you can just rm -rf /tmp/build when you're done and not add cruft to your src tree
<crimsun> noted.
<BenC> crimsun: Any chance alsa is considering moving to git still? :)
<crimsun> BenC: not likely
<BenC> crimsun: Would make it so much easier for us to just pull their tree :/
<BenC> wonder if we can make a strong enough case for it that they might do it...I would think the effort they spend getting the patches to Linus would have been enough
<crimsun> well, Jaroslav does have linux/kernel/git/perex/alsa.git
<crimsun> I think you've pulled from that one before
<BenC> is there a branch in there that is stable enough to keep in sync with?
<BenC> I think last time i messed with it, I just copied the entire tree instead of actually pulling
<crimsun> I don't see one that seems updated
<mrec> does anyone here work on the installation cds?
<mrec> the default kernel which comes with the cds simply doesn't support the hardware we have here, it would be nice to support it out of the box
<BenC> mrec: would be nice to know what hardware that is
<mrec> BenC: sorry took a while, I'm booting it and dumping the hardware list
<ivoks> i noticed a regreesion with bluetooth since edgy :/
<ivoks> like... i can't turn it on :D
<BenC> ivoks: I have no bluetooth to test...is it maybe an rfkill thing?
<BenC> is it showing up in lsusb?
<ivoks> i'm in 2.6.17 now
<ivoks> it works here, it's software switch
<ivoks> it shows up in lsusb here
<ivoks>       bInterfaceSubClass      1 Radio Frequency
<ivoks>       bInterfaceProtocol      1 Bluetooth
<BenC> ivoks: Let me know if it doesn't show up under feisty
<ivoks> i'm rebooting right now :)
<ivoks> no, it doesn't show up
<mrec> BenC: http://rafb.net/p/nUlDLa61.html
<BenC> mrec: That doesn't tell me which hw isn't working :)
<mrec> harddisk isn't recognized :)
<mrec> sorry
<BenC> Assuming this is the ATI IDE?
<mrec> yes
<BenC> and it worked in edgy?
<BenC> Can you send the dmesg from edgy?
<mrec> it didn't work
<mrec> I didn't go on with it but I'm interested in getting it supported out of the box
<mrec> BenC: what do you need of dmesg?
<johanbr> mrec: I have a very similar controller in my laptop (possibly identical) and it works fine in Feisty.
<mrec> johanbr: the problem is I cannot go on with the installation since the harddisk isn't detected
<BenC> mrec: All of it
<BenC> mrec: So neither edgy nor feisty works with it?
<johanbr> mrec: Oh, I see. My installation is upgraded from Edgy (or maybe even Dapper, don't remember).
<mrec> BenC: the installation cd is supposed to be edgy
<BenC> mrec: Can you test if feisty works, just so I can see if it's something that can be backported?
<mrec> where can I get feisty?
<stgraber> cdimage.ubuntu.com/releases/feisty/
<mrec> ok grabbing it
#ubuntu-kernel 2007-03-14
<poolie> hi, is anyone around?
<poolie> i'm really blocked from using one machine by bug 90689
<poolie> would love some help
<crimsun> bug 90689
<Amaranth> ubugtu isn't here
<Amaranth> why not?
<poolie> fabbione: ok, interesting 
<poolie> now i have
<poolie> ata1: failed to recover some devices, retrying in 5 secs
<poolie> and again, with 
<poolie> qc timeout, failed to set xrefmode err mask 4 
<fabbione> ok...
<fabbione> was that with or without options?
<fabbione> you could also try to add: pci=routeirq
<poolie> that was 9, which is currently installed, with nosmp noreplacement
<poolie> do you want me to try the dvd, or the installed image with those options?
<fabbione> before you change kernel, please try to add pci=routeirq too
<fabbione> then jump to 2.6.20-10 or -11
<fabbione> (not sure -11 has been uploaded yet)
<fabbione> start without options
<fabbione> and add them one at a time to see which one changes behavioy
<fabbione> behaviour
<fabbione> i suggest you also take note of these tests and add the results to the bug
<poolie> ok
<poolie> good idea
<dade`> the new kernel does not even boot on my macbook
<dade`> gives an ata bad status when setting the xfer mode
<\sh> guys, dapper, edgy and feisty herd5 have problems booting on a HP DL320s server
<\sh> it always stops loading the kernel after recognizing the PS/2 Keyboard port...no oops nothing...how can I try to gather more debug information for a bug report? :)
<\sh> funny thing, too, booting an iso via ilo2, doesn't bring this lock, but runs into an endless loop for udev finding many times the same usb hub for the virtual mouse/keyboard of ilo2...(dapper)
<poolie> \sh: assume you've tried removing 'quiet' and adding 'verbose' to the boot parameters?
<\sh> poolie: yepp
<fabbione> BenC: latest git fails on sparc:
<fabbione> ld: cannot open linker script file ubuntu/net/wireless/.tmp_wext-common.ver: No such file or directory
<fabbione> make[5] : *** [ubuntu/net/wireless/wext-common.o]  Error 1
<fabbione> make[4] : *** [ubuntu/net/wireless]  Error 2
<fabbione> make[3] : *** [ubuntu/net]  Error 2
<fabbione> make[2] : *** [ubuntu]  Error 2
<fabbione> make[2] : *** Waiting for unfinished jobs....
<poolie> fabbione: hi, still no luck with the current -10
<fabbione> poolie: did you try all the options*?
<poolie> fabbione: where do the device files come from in initramfs? i have no sda1
<poolie> just going to try pci=routeirq
<fabbione> poolie: they are generated by udev
<fabbione> and there is a bug about it
<poolie> ok, it also oopses with pci=noroute added
<poolie> but i also get, earlier, mdadm: No devices listed in conf file were found. / failed to assemble all arrays 
<poolie> which i guess is why it can't mount root, which is on raid
<\sh> fabbione: do you know anyone from HP who is an ubuntu geek, best location uk or europe in general? :)
<fabbione> poolie: cat /proc/partitons .. does it show the devices?
<poolie> it's empty
<fabbione> \sh: try one of our sysadmins...
<fabbione> poolie: ok if that's empty there is no way to assemble a raid out of thin air... it means that disks have not been found at all
<poolie> right
<\sh> fabbione: elmo or znarl?
<fabbione> and that's mostlikely related to the block subsystem OOPSing
<fabbione> \sh: any of the sysadmins
<poolie> that's what i thought
<fabbione> poolie: we need to wait for ben/kyle
<fabbione> i am not sure what else to try
<fabbione> feh
<fabbione> <fabbione> poolie: we need to wait for ben/kyle
<fabbione> * poolie (n=mbp@ppp112-44.static.internode.on.net) has left #ubuntu-kernel ("parted")
<fabbione> <fabbione> i am not sure what else to try
<fabbione> <fabbione> feh
<poolie> fabbione: ok, at least i have a laptop
<poolie> thanks 
<fabbione> no problem
<poolie> i'm too used to ^w for delete-word :)
<poolie> fabbione: strangely enough the current daily cd does boot just fine in recovery mode, brings up md and lvm automatically
<fabbione> poolie: hmmm so you mean it boots but then install doesn't?
<lifeless> well he has an install :)
<lifeless> poolie: try chrooting into your system now
<poolie> from the boot cd
<poolie> ok, will take a while to come back up
<lifeless> poolie: you could also try setting root= during the boot
<poolie> to what?
<poolie> oh i see
<poolie> while booting from cd 
<poolie> yep worth a shot
<poolie> i wonder why the recovery mode needs you to set a hostname?
<poolie> oh ffs
<fabbione> BenC: that linker script error seems to show up only when forking the build with CONCURRENCY_LEVEL
<poolie> lifeless: i'm chrooted into my root from the installer kernel, what did you want me to try?
<lifeless> well you should be able to upgrade your kernel, udev, now
<poolie> yeah, that's what i did
<poolie> so the good news is i have a way to get updates on; but they don't fix it yet
<lifeless> ok
<lifeless> so the installer has the same kernel as you now, and udev. So it might be another package
<poolie> well, the installer actually uses -9, which is quite a bit older the current one in the distro
<poolie> or it may be starting things up in a different order from userspace that avoids this
<poolie> but for now i will wait for guidance from benc i think
<Mithrandir> poolie: try installing -9 from the repositories and see if that boots correctly?
<poolie> i have, though maybe they updated -9?
<poolie> do you know when it gets a new -9 number rather than a -9.1?
<lifeless> yes
<lifeless> the -X is the ubuntu serial number for all intents and purposes
<Mithrandir> poolie: grab the correct set of binaries off https://beta.launchpad.net/ubuntu/+source/linux-source-2.6.20 ?
<poolie> lifeless: but sometimes there are several uploads of -9?
<poolie> Mithrandir: will that be different to what's in the archive?
<Mithrandir> poolie: if you grab the one marked "removed", yes.
<Mithrandir> poolie: -9 is the ABI version, it's only bumped when the upload changes the ABI.
<Mithrandir> there was two uploads of -9
<poolie> i see, thanks 
<poolie> Mithrandir: and which do you think is correct?
<poolie> it's broken in -7; it's broken in -10
<Mithrandir> 2.6.20-9.16, probably.
<poolie> ok, and you think that might work because it's the one used by the installer?
<Mithrandir> yes
<poolie> ok thanks
<Nafallo> LP #92202 might be a beta target? :-)
<Mithrandir> it should be easy enough to fix, at least.
<Mithrandir> BenC: ^^ ; are you planning a kernel upload before beta freeze?
<BenC> Mithrandir: planning one in about 1 hour
<Mithrandir> ok
<Nafallo> BenC: with qc-usb? :-)
* Nafallo holds of rebooting then :-P
<BenC> Nafallo: Yeah, I got 92202 up and I'll get the source in so long as it builds :)
<Nafallo> kewl! :-)
<fabbione> BenC: do we have the atyfb fix for davem in the tree=?
<BenC> fabbione: Yeah, I think I put it in after -10, so it will be in -11
<fabbione> BenC: yeah it's there
<fabbione> BenC: i am still a bit puzzled by that sparc FTBFS with CONCURRENCY_LEVEL
<fabbione> it was reproducible only one
<fabbione> once
<BenC> fabbione: All of my sparc test builds are done with -j10
<fabbione> hmm ok
<fabbione> i did fire -j128
<fabbione> but i am ok if it works for you
<BenC> we'll blame that on you being plain evil to your boxes :)
<fabbione> nah evil was -j4096 on davem's machine :)
<fabbione> <davem> it works! it works at -j32!
<fabbione> <fabbione> gimme a sec..
<fabbione> <davem> sure
<fabbione> <fabbione> OOPS.. it crashes at -j4096...
<fabbione> <davem> screw you
<BenC> fabbione: lol
<BenC> fabbione: Tim and I did a plain -j on a 64Gig 2 x Quad Xeon box
<BenC> some 10k processes
<BenC> only used like 7gigs of mem
<BenC> 4.5 minutes for bzImage AND ~1800 modules, MODPOST and all
<BenC> doing -j12 actually finished 4 seconds faster
<BenC> fabbione: let that be a lesson to your hw abusive ways :)
<abogani> Mithrandir: May i disturb you?
<Mithrandir> abogani: sure, what's up?
<abogani> Mithrandir: About my spec (https://wiki.ubuntu.com/RealTime)....
<abogani> I have created a linux-patch-realtime-preempt package. This package contain only the Ingo Molnar's patch (and not all linux kernel source) adapted to Ubuntu linux kernel (i use dh-kpathes method). Users can build kernel follow this http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-getting     
<abogani> It is a right way? Now exist a possibility that this package will be accepted in universe? What i should do for achieve this objective?
<BenC> abogani: get someone to review it, and sponsor the upload, then buy Mith a few pints
<BenC> abogani: That's something you'd want to check #ubuntu-motu for
<Mithrandir> abogani: your approach seems sane, yes.
<abogani> BenC, Mithrandir : Ok Thanks :-)
<BenC> abogani: and if it helps, I'll give a nod for the package, considering you were very open to packaging suggestions and quick to change the entire build process to suit it
<Amaranth> wouldn't it be better to do like Xen and have the package pull in the kernel source, apply the patch, and build a kernel for the binary package?
<BenC> Amaranth: That's what he did
<Amaranth> oh, i thought he was saying the end user would have to build the kernel
<BenC> oh, maybe he did, I misread
<BenC> I suggested using the xen method yesterday :)
<abogani> BenC: I already seen Xen packaging approach.. but xen-source package contains a complete linux source copy! It is also _vanilla_ kernel! ...... Ok i'm confused. :-| .... What is exactly the xen package that i should use as example?
<BenC> abogani: The 2.6.17 one in edgy
<BenC> the one in feisty might be full source
<abogani> BenC: Ahhhh
<Mithrandir> uh, please don't do that.  It's deprecated and I will reject any new packages doing that.
<Mithrandir> you're free to have a package that build-depends on the appropriate kernel source, includes a patch and builds linux-image-$whatever binaries, though
<abogani> BenC: thank you for the patience :-)
<BenC> Mithrandir: that's the approach he's working towards
<Mithrandir> BenC: ok, good.
<fabbione> BenC: the kernel doesn't fork more than 3500 or there about... there isn't enough source code :)
<BenC> fabbione: We went from 120 procs to 10100 or so
<BenC> top verified this number :)
<BenC> fabbione: this was full ubuntu tree, so almost all modules turned on
<BenC> $ find -name \*.c | wc -l
<BenC> 9198
<BenC> figure up gcc+cc1+as forking, plus some make procs
<BenC> seems feasible
<fabbione> hmmm oh right it was crap86
<fabbione> we were on sparc
<BenC> fabbione: I don't think sparc uses -pipe, so there's more forking on x86 builds
<TheMuso> c
<TheMuso> damnit
#ubuntu-kernel 2007-03-15
<jml> hello
<jml> fwiw, the new kernel seems to hang on boot on my macbook.
<jml> I haven't had time yet to do the proper diagnosis and file a bug report, but looking around on LP I didn't find any that matched.
<jml> it seems partly related to bug 84359. 
<jml> just mentioning in case anyone has more detailed info to hand.
<BenC> jml: Probably more like bug #84964
<jml> BenC: yeah
<jml> BenC: so I guess the kernel team doesn't have much in the way of mac hardware for testing?
<BenC> jml: Actually kyle has a macbook
<BenC> and he doesn't see the problem
<BenC> I doubt it's macbook specific, sounds more like an issue with missing PCI ID's
<jml> BenC: is it a Core Duo or a Core 2 Duo?
<BenC> Core2
<jml> interesting.
<BenC> jml: Can you show me your lspci -n?
<jml> BenC: http://rafb.net/p/Q1sPvk35.html
<BenC> jml: "lspci" too please
<BenC> so I don't have to cross reference a dozen id's :)
<jml> oh, right.
<jml> http://rafb.net/p/ZWR47724.html
<BenC> jml: Sweet, I just found the bug
<jml> BenC: neat.
<BenC> simple typo, so piix (the ide module) was trying to operate the device, and kept ata_piix (the libata module) from handling it like it's supposed to
<BenC> damn, wish I had found this about 2 hours ago, could have included it with the upload
<jml> well, it will get uploaded eventually. And once that happens, and ndiswrapper gets updated, I'll be able to run a 2.6.20 kernel again!
<jml> oh. maybe it did get updated.
<jml> interesting.
<michup> hi, libGL warning: 3D driver claims to not support visual 0x5b
<michup> glxgears: intel_ioctl.c:62: intelEmitIrqLocked: Assertion `((*(int *)intel->driHwLock) & ~0x40000000U) == (0x80000000U|intel->hHWContext)' failed.
<michup> Aborted
<michup> is it something about allocated memory by chipset to RAM?
<michup> [17179586.408000]  Linux agpgart interface v0.101 (c) Dave Jones
<michup> [17179586.496000]  agpgart: Detected an Intel 915GM Chipset.
<michup> [17179586.496000]  agpgart: Detected 16124K stolen memory.
<michup> [17179586.512000]  agpgart: AGP aperture is 256M @ 0xd0000000
<dade`> is there any plan to make macbooks sleep ?
<BenC> dade`: Like "sleep with the fishes" kind of sleep, or real computer suspend/resume sort of stuff?
<BenC> if the former, talk to fabbione :)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-11.18 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 281 Open, 55 Unconfirmed, 165 Unassigned
<dade`> sleep -> suspend to ram
<mjg59> dade`: What's the bug?
<mjg59> It works fine on my pro
<dade`> not on mine
<dade`> not on non-pro
<mjg59> Running what?
<dade`> ubuntulog, both feisty and edgy
<dade`> ubuntu
<mjg59> How does it fail?
<dade`> the HD powers off
<dade`> the screen gets black but backlight is ON
<dade`> and does not sleep
<dade`> the led does not pulse
* mjg59 shrugs
<mjg59> This is from a clean install?
<dade`> i tried even booting with init=/bin/bash
<dade`> then sleeping by echoing mem > /sys/power/state
<mjg59> Core or Core 2?
<dade`> core duo
<dade`> not 2 core duo
<mjg59> Ok. File a bug
<dade`> can't get any useful information, it would not be useful i think.. i'll see if there is something already
<Keybuk> Evgeniy Polyakov, the author of the kevent patches, has not been sitting still while these patches have gone around. His proposal is called eventfs; it is a special filesystem which offers the ability to bind events to file descriptors. The first version of the patch only handles signals, via a system call named (yes) signalfd():
<Keybuk> -- 
<Keybuk> oh yes, give me one more special kernel filesystem
<Keybuk> we don't have enough yet
<kylem> is that lwn?
<Keybuk> yes
<Whoopie> Hi, is it allowed to open a bug reports with a collection of some patches I'd like to have in ubuntu kernel? Or do I need to open a bug report for each patch?
<JanC> Whoopie: I think you best separate things into "problems" ?
<Whoopie> JanC: ok
<JanC> that's just my opinion, and it is how I would do it  :)
<JanC> to solve this problem  use this patch (or these patches if a combination is needed)
<Whoopie> e.g. KVM and VirtualBox have problems with by default enabled NMI. but 2.6.21-rc there's a patch for disabling it by default: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8ce5e3e45e01ffab38a9f03900181132b9068543
<JanC> Whoopie: I'm not a kernel dev  :)
<crimsun> Whoopie: file a bug against linux-source-2.6.20 and reference that commit hash
<Lure> BenC: can you review proposed patch from bug 75398 and consider including it - it looks like it fixes problem for many hp laptops
<Lure> BenC: see also bugs 89779 and 74877 (probably duplicates)
<Whoopie> crimsun: done, thanks!
<zul> hey
<fabbione> zul: you shouldn't be here.. really :)
<zul> fabbione: im not really here...really :)
#ubuntu-kernel 2007-03-16
<mjg59> crimsun: Are there still patches from you pending?
<mjg59> Still no MBP audio love for me
<neuralis> mjg59: by the way, is "ec kills touchpad after resume" a known bug for hp's latest laptop series, including the nc4400 and at least one of the nxes, and if not, do you need bugs filed and information provided?
<fabbione> hey Ivan
<lifeless> hola neuralis 
<neuralis> hey folks! long time no see
<neuralis> fabbione: how's the little dude?
<fabbione> neuralis: you mean that fat-o-saurus rex? he is good :)
<neuralis> lifeless: don't know if you heard yet; we're currently using bzr as the vcs we ship and integrate with the laptop's built-in IDE
<neuralis> fabbione: haha.. fatosaurus rex is a good name
<lifeless> neuralis: yes, I think thats fantastic
<fabbione> http://people.ubuntu.com/~fabbione/pics/chris/swimming.jpg
<fabbione> neuralis: ^^
<lifeless> neuralis: we just got a 100% performance boost for you for 0.15
<lifeless> (for local ops)
<neuralis> fabbione: he has that scary look of a kernel hacker :)
<neuralis> lifeless: nice! we'll have to pull that in.
<fabbione> neuralis: ahahha
<neuralis> lifeless: we're still trying to figure out how to reconcile the "we keep everything in git, but we want to ship bzr" asymmetry, but hopefully we can work something out there. input appreciated, certainly.
<lifeless> neuralis: well, you could convert to bzr :)
<lifeless> neuralis: more seriously, I'd be happy to provide guidance on finishing the git foreign branch plugin for bzr, so you could just do 'bzr pull' to pull your git branch into bzr
<neuralis> that sounds reasonable. we can't go all-bzr since we deal with kernel trees and maintaining two vcses seems suboptimal. presumably with the git fb plugin, we could automate maintenance of a bzr mirror for all our git trees?
<lifeless> yup
<lifeless> I dont have time to finish it myself at the moment unfortunately.
<neuralis> worry not, i have summer interns.
* neuralis laughs evilly
<lifeless> lp.net/bzr-git
<fabbione> BenC: ping?
<TheMuso> c
<Mithrandir> BenC: please make sure to grab my building fix to linux-backports-modules and not just blindingly blast over it like you did on this last upload (causing it to fail to build..)
<tumbleweed> https://launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/65827
<tumbleweed> we've hit this with a lab of 50 ubuntu PCs
<tumbleweed> can someone please look into it.
<crimsun> mjg59: yes, to differentiate between 1st- and 2nd-gen macbook pros
<fabbione> pkl_: ping?
<pkl_> fabbione: pong
<fabbione> pkl_: hey dude.. are you busy? otherwise i would like to steal 10 minutes of your time
<pkl_> nope, never busy :)
<fabbione> ehhehe
<BenC> Mithrandir: I had no idea it failed, or that you had fixed it
<Mithrandir> BenC: it ended up in depwait since you uploaded with ancient debian/control; doesn't kernel-team get upload notifications for uploads of those packages?
<BenC> Mithrandir: I've no idea
<BenC> debian/control probably isn't being rebuilt when the clean target is run
<Mithrandir> it's not, no
<BenC> Mithrandir: is it going to be a problem if a kernel I upload today bumps ABI?
<BenC> it really needs to be there for beta
<kylem> BenC, can you revert my libata-hpa patch for now?
<Mithrandir> BenC: if it's needed, it's needed.  I'm not happy about it, but rather now than later.
<kylem> apparently it's the cause of the macbook failing to boot.
<kylem> though i haven't the foggiest idea why
<BenC> kylem: don't you have a macbook?
<BenC> kylem: Are you sure it's not caused by the piix problem?
<kylem> BenC, no... mjg59 said blacklisting piix didn't help
<BenC> Mithrandir: thanks, I'll get it up as soon as possible
<fabbione> hey BenC 
<fabbione> BenC: queued one more change for you
<fabbione> it's in the usual repo on people
<BenC> fabbione: Thanks
<fabbione> BenC: when i re-enabled ocfs2/gfs* in the generic kernels i forgot to add Provides: rhcs-modules...
<fabbione> BenC: this makes the cluster suite installable on any of our kernels
<BenC> kylem: Do you have a commit sha I can revert?
<kylem> a0e61542121a0519bfbe9f6e43980ec96a16156e
<kylem> should revert cleanly
<dade`> re
<dade`> I filled a bug, with a mistake on the title I don't feel proud of
<kylem> might want to revert upstream:8ce5e3e45e01ffab38a9f03900181132b9068543 too if you haven't already (the watchdog thing someone complained about yesterday.)
<dade`> is there anything I can do ?
<fabbione> dade`: edit the description
<dade`> hm
<dade`> done, thx
<dade`> I thought it was not possible
<BenC> kylem: So we want to enable NMI by default again?
<kylem> no.
<kylem> "    Disable NMI watchdog by default properly
<kylem>     This reverts commit 6ebf622b2577c50b1f496bd6a5e8739e55ae7b1c and
<kylem>     replaces it with one that actually works.
<kylem> "
<kylem> from linus
<BenC> Should we revert 6ebf622b2577c50b1f496bd6a5e8739e55ae7b1c then? :)
<kylem> oh. er.
<kylem> don't revert, cherry-pick
<kylem> sorry, early morning and such. :)
<BenC> ah, makes much more sense now :)
* kylem needs coffee.
<BenC> git-diff-tree wasn't telling me that wasn't in my HEAD
<mjg59> crimsun: Ok - let me know when it should work and I'll letyou know if it does :)
<BenC> kylem, mjg59: BTW, I cherry-picked ide-acpi from upstream last night
<mjg59> BenC: That's only for drivers/ata
<mjg59> Uh.
<mjg59> drivers/ide
<mjg59> I need to port it to libata
<BenC> right, is there one for drivers/ata too?
<mjg59> Not yet. I need to write it.
<BenC> mjg59: Don't suppose it will be done in 1 hour? :)
<BenC> mjg59: After this upload, We're probably doing only one more after beta, just before RC
<dade`> http://en.wikipedia.org/wiki/Latent_inhibition
<dade`> sould be perfect english
<dade`> right ?
<dade`> should :P
<mjg59> BenC: No chance
<BenC> mjg59: Ok, guess it will wait for RC. Do you have any idea what bugs, if any, would be caused by not have libata-acpi?
<mrec> BenC: the disk problem was a false alarm, it works well.
<BenC> mrec: Good to hear, thanks
<mrec> not sure if you're still interested in the em28xx driver, people are testing the latest version now
<mjg59> Failure to resume on various machines
<BenC> mjg59: ugh, sounds like 5% of our bug reports :/
<mrec> BenC: are you still willing to include it in upcoming versions?
<BenC> mrec: I have one kernel upload today for next weeks beta, and one (unless something horrible happens) after that for RC, and hopefully release, so it looks like it wont make it for feisty
<mrec> ok
<BenC> mrec: Unless you can give me a quick patch to drop into the ubuntu-2.6 tree
<mrec> BenC: the patch needs some more testing, it has around 8500 lines now
<mrec> and it affects parts of the dvb-core framework, so it touches quite alot
<BenC> mrec: Ah, definitely no chance then
<mrec> yes, it's better to keep it out for now
<mrec> is there any schedule for the next version?
<BenC> mrec: If you find the feisty release schedule, basically you can take that and adjust it 6 months out for the next release (no guarantee, but it's close)
<BenC> we'll most likely be 2.6.22 based, but no guarantee there either
<mrec> BenC: do you directly compile any v4l/dvb support into the kernel or just as modules?
<BenC> mrec: All modules
<mrec> maybe a solution would be to provide deb packages
<mrec> modules would be fine
<BenC> mrec: Yeah, that sounds like a good idea
<BenC> mjg59: Any comments about this patch: http://bugzilla.kernel.org/attachment.cgi?id=9254&action=view
<BenC> wait wait, I already have that one
<BenC> *sigh*
<BenC> guess I can leave the other one out, doesn't seem to be needed
<BenC> mjg59: FYI, I already had libata-acpi in our tree, but I'm syncing with the one in upstream now to make sure we have all the features
<bluffer_> i need some instructions to get a network card driver can some one point me what would i need 
<bluffer_> compile a network card sources
<bluffer_> i installed dapper drake 6.06.01 from alternate cd
<bluffer_> this does not detect my network card which is 3c905c-tx from 3com
<BenC> bluffer_: That card should be detected
<bluffer_> thanks benc for replying but no it is not detected (neither in edgy nor in drapper)
<BenC> bluffer_: what's the vendor/device ID of the card (as shown in lspci)?
<bluffer_> i m telling this from windows device manager ( i havent booted dapper vm yet)
<bluffer_> 3com 3c920 integrated fast ethernet controller 3c905c-tx compatible)
<bluffer_> i would try to compilesome of these sources if i can http://support.3com.com/infodeli/tools/nic/linuxdownload.htm
<bluffer_> or hold on ill boot the vm now 
<BenC> bluffer_: I'd need to know the PCI vendor/device ID's to help you any
<BenC> I'm more interested in finding out why it's not working with edgy/dapper
<BenC> because it definitely should
<bluffer_> ok no problem im booting the dapper vm
<bluffer_> i had lots of problem installing this distro (edgy live cd never went farther than the splash screen kernel panic edgy alternate went all the way till grub install and failed to install either grub or lilo dapper alternate installed only text mode (no x ) some fine people at ubuntu ardchoille especially helped me install ubuntu-desktop)
<bluffer_> from commandline 
<bluffer_> and all these distros never detected my ethernet card
<bluffer_> i always said them to continue without network 
<bluffer_> now ihave a working installation im trying to find how i could get network on it 
<bluffer_> ok vm is on ( open a terminal and did a lspci this is the output
<bluffer_> bluffer@ubuntu:~$ lspci
<bluffer_> 0000:00:00.0 Host bridge INtel corporation 440BX/ZX/DX -82443bx/zx/dx host bridge (agp disabled) (rev 03)
<bluffer_> 0000:00:07.0 ISA bridge intel corporation 82371ab/eb/mb
<bluffer_> pIIx4 ISA (rev 01)
<bluffer_>  im typing it to as i see so its late to paste all info there are five more lines
<kylem> just type the 3com line
<bluffer_> 0000:00:07.1 IDE interface Intel corporation 82371ab/eb/mb PIIX4 IDE (rev 01)
<bluffer_> there is no 3 com line
<bluffer_> there is an ethernet controller line shall i type it ? first
<bluffer_> 0000:00:0a.0 Ethernet controller: Digital Equipment Corporation Decchip21140 [fasternet]  rev 20)
<bluffer_> this is the ethernet controller line
<kylem> that's a tulip.
<bluffer_> hold on ill image shack this screen
<BenC> bluffer_: Get another one of the "lspci -n" output so we can see the numeric ids
<bdmurray> sorry to interrupt but before I forget you might want to check out bug 92792
<BenC> bdmurray: crappy...guess I'll revert rt61 and others back to rt2x00-legacy
<BenC> bdmurray: thanks for the heads up
<bdmurray> BenC: no problem
<kylem> BenC, can't we ship both? :P
<bluffer_> sorry for the delay im on a super low memory machine (128 mb in host running a ubuntu vm with 44 mb on vpc)
<emefei> hi
<BenC> kylem: I could remove the module aliases and leave it in
<lfittl> hmm, I am currently trying KVM on AMD64, but somehow it seems to think I want a 32bit guest system, how can I change that?
<lfittl> qemu offers qemu-system-x86_64, which works, but there is nothing like qemu-kvm-x86_64
<bluffer_> damn image shack is too loaded :( ill upload the screen shot some where else
<bluffer_> http://www.geocities.com/blufferisme2/lspci.PNG
<bluffer_> here it is
<bluffer_> you want lspci -n ok 
<bluffer_> ill upload it too
<BenC> bluffer_: virtual PC on your machine does us no good
<BenC> bluffer_: We need ubuntu booted directly on that box
<bluffer_> i see then i think ill have to live like this :(
<bluffer_> i cant boot it from my machine coz i have just 128 mb memory live cd of edgy doesnt go farther than the spalash screen
<BenC> bluffer_: Use alternate CD, it installs ubuntu-desktop just like the livecd
<BenC> bluffer_: In fact, you don't need to install Ubuntu to get the lspci output we need, just boot the alternate, switch to VT2 (Alt+F2) and type the commands
<bluffer_> i dont have a cd rom on this machine its too much trouble :(
<bluffer_> i can provide you those details if windows provides it can you tell me or shall igoogle
<bluffer_> or i if it of any consolation i can boot dsl (damn small linux) it detected my card without problems ?
<bluffer_> if this result willsatisfy you ?
<bluffer_> http://www.unliterate.net/lspci/
<bluffer_> its a windows exe 
<bluffer_> dont know if it works or not :) but av says no virus so ran it andi get C:\>"Documents and Settings\deep\Desktop\lspci.exe"
<bluffer_> PCI BIOS Call reveals that the PCI BIOS is not installed
<bluffer_> C:\>
<bluffer_> i downloaded belarc advisor and ran it 
<bluffer_> the result
<bluffer_> 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible) 
<bluffer_>  primary   IP Address:  192.168.1.51 / 24 
<bluffer_>  Gateway:  192.168.1.254 
<bluffer_>  Physical Address:  00:06:5B:2F:01:C5 
<bluffer_> 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible) - Virtual Machine Network Services Driver 
<bluffer_> 
<bluffer_> Networking Dns Servers:  202.54.10.2
<bluffer_> 203.197.12.42 
<bluffer_> BenC  still wanna help ?
<BenC> bluffer_: I need the actual numeric PCI id's for at least the device ID
<BenC> 3C920 claims to be supported by the 3c95x driver, but I can't be sure unless I see the device ID
<bluffer_> if you dont mind can you tell me will this get you what you need ?
<bluffer_> http://support.microsoft.com/kb/311272
<BenC> bluffer_: probably
<bluffer_> is this ok
<bluffer_> PCI\VEN_10B7&DEV_9200&SUBSYS_00FE1028&REV_78\4&2DA278D3&0&60F0
<bluffer_>     Name: 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible)
<bluffer_>     Hardware ID's:
<bluffer_>         PCI\VEN_10B7&DEV_9200&SUBSYS_00FE1028&REV_78
<bluffer_>         PCI\VEN_10B7&DEV_9200&SUBSYS_00FE1028
<bluffer_>         PCI\VEN_10B7&DEV_9200&CC_020000
<bluffer_>         PCI\VEN_10B7&DEV_9200&CC_0200
<bluffer_>     Compatible ID's:
<bluffer_>         PCI\VEN_10B7&DEV_9200&REV_78
<bluffer_>         PCI\VEN_10B7&DEV_9200
<bluffer_>         PCI\VEN_10B7&CC_020000
<bluffer_>         PCI\VEN_10B7&CC_0200
<bluffer_>         PCI\VEN_10B7
<bluffer_>         PCI\CC_020000
<bluffer_>         PCI\CC_0200
<bluffer_> ROOT\CNTX_VPCNETS2_MP\0000
<bluffer_>     Name: 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible) - Virtual Machine Network Services Driver
<bluffer_>     Hardware ID's:
<bluffer_>         Cntx_VPCNetS2_MP
<bluffer_> ROOT\MS_PSCHEDMP\0000
<bluffer_>     Name: 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible) - Packet Scheduler Miniport
<bluffer_>     Hardware ID's:
<bluffer_>         ms_pschedmp
<bluffer_> those are the results from devcon hwids * matching 3com
<bluffer_> C:\Documents and Settings\deep\Desktop\devcon\i386>devcon find pci\*
<bluffer_> PCI\VEN_10B7&DEV_9200&SUBSYS_00FE1028&REV_78\4&2DA278D3&0&60F0: 3Com 3C920 Integ
<bluffer_> rated Fast Ethernet Controller (3C905C-TX Compatible)
<bluffer_> PCI\VEN_8086&DEV_2410&SUBSYS_00000000&REV_02\3&172E68DD&0&F8: Intel(r) 82801AA L
<bluffer_> PC Interface Controller
<bluffer_> PCI\VEN_8086&DEV_2411&SUBSYS_24118086&REV_02\3&172E68DD&0&F9: Intel(r) 82801AA B
<bluffer_> us Master IDE Controller
<bluffer_> PCI\VEN_8086&DEV_2412&SUBSYS_24128086&REV_02\3&172E68DD&0&FA: Intel(r) 82801AA U
<bluffer_> SB Universal Host Controller
<bluffer_> PCI\VEN_8086&DEV_2413&SUBSYS_24138086&REV_02\3&172E68DD&0&FB: Intel(r) 82801AA S
<bluffer_> MBus Controller
<bluffer_> PCI\VEN_8086&DEV_2415&SUBSYS_01081028&REV_02\3&172E68DD&0&FD: Intel(r) 82801AA A
<bluffer_> C'97 Audio Controller
<bluffer_> PCI\VEN_8086&DEV_2418&SUBSYS_00000000&REV_02\3&172E68DD&0&F0: Intel(r) 82801AA P
<bluffer_> CI Bridge
<bluffer_> PCI\VEN_8086&DEV_7120&SUBSYS_00000000&REV_03\3&172E68DD&0&00: Intel(r) 82810 Sys
<bluffer_> tem and Graphics Controller
<bluffer_> PCI\VEN_8086&DEV_7121&SUBSYS_01081028&REV_03\3&172E68DD&0&08: Intel(r) 82810 Gra
<bluffer_> phics Controller
<bluffer_> 9 matching device(s) found.
<bluffer_> C:\Documents and Settings\deep\Desktop\devcon\i386>
<bluffer_> for pci
<bluffer_> is there something usefull ?
<BenC> bluffer_: Dude, please do not paste that into a channel
<BenC> pastebin was created for a reason
<bluffer_> ok ill be idling here i have to quit now ill talk to you tommorow around same time 
<bluffer_> thanks for trying to help me out 
<BenC> bluffer_: That device is supported by the 3c95x driver, if it doesn't work, then the driver is broken
<bluffer_> i see so no solution for me yet isnt it ?
<bluffer_> thanks anyway if there is some news for me ill gather it tommorow ill be idling here till then hope its ok
<bluffer_> cyal l8r
<BenC> bluffer_: bottom line is, if you want help with this, you need to install ubuntu
<eean> my intel audio, after upgrade to 2.6.20-11, dmesg gives hda_codec: Unknown model for ALC660VD/ALC861VD, trying auto-probe from BIOS...
<eean> so sound no longer wokrs
<eean> works
<eean> with -10 it did all work
<eean> this is the snd_hda_intel module
<BenC> crimsun: ^^
<eeanm> well I'll submit a bug
<eeanm> https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/92909
<crimsun> eeanm: looking. Please be aware that I'm traveling this weekend and have intermittent Internet access.
<eeanm> ok
<crimsun> Realtek, correct?
<crimsun> Please attach ``lspci -vvn'' to the report, though I believe I can guess.
<crimsun> eeanm: ^^
<eeanm> crimsun: ok
<crimsun> thanks.
<eeanm> lspci -vvn | grep Real turns up nothing
<eeanm> I'll make the attachment
<crimsun> you just need ``lspci -vvn''
<crimsun> I can tell by the SSID who manufactures the codec
<crimsun> not to mention the dmesg bit says
<eeanm> crimsun: its attached
<eeanm> after about 4 tries on launchpad ;)
<crimsun> this is a fairly serious regression from -8 if it's what I think it is; likely it's completely broken upstream, too
<eeanm> I'm pretty sure it worked in -10
<eeanm> I can reboot and double check
<crimsun> yeah, it's broken upstream
<crimsun> please do, though I'm fairly certain -10 should be broken (albeit only slightly less broken)
<eeanm> there were already reports about a regression in -9 from -8
<eeanm> ok, brb
<crimsun> -8 should have been the last one to actually produce "normal" audible sound
<eeanm> haha, maybe I have dog ears then
<crimsun> it's using the wrong model, for starters
<crimsun> should definitely be using ALC861_TOSHIBA instead of ALC*6*VD*
<crimsun> lovely, there goes my weekend
<eean> my sound works fine now
<eean> Linux gomashio 2.6.20-10-generic #2 SMP Mon Mar 12 00:02:49 UTC 2007 i686 GNU/Linux
<crimsun> ok, by fine do you mean "only barely audible" or "audible with nearly the same perceptive loudness as in $another_os"?
<eean> as loud as in edgy yea
<eean> sounds fine
<crimsun> man, these Toshibas suck
<eean> oh, but its so cute
<crimsun> yours "works", but half a dozen others with the same SSID break
<eean> lol
<crimsun> ok, can you confirm something in both -10 and -11 for me?
<crimsun> please modprobe -r snd-hda-intel && modprobe snd-hda-intel model=toshiba
<stgraber> crimsun: I've solved my problem with my Toshiba :), I've just bought an all new HP laptop :)
<eean> boo
<crimsun> stgraber: (great, more troubles, *grumble* :)
* eean used to work at a Help Desk
<stgraber> crimsun: with working snd-hda-intel on -11 :)
<eean> seemed like HP's had all the trouble
<eean> could of been their users though ;)
<crimsun> eean: all laptops are moderately broken, some more severely than others [audio-wise] 
<eean> yea
<eean> I put off getting a laptop for a while
<crimsun> eean: anyhow, please test the above model=toshiba under both -10 and -11
<eean> ok
<crimsun> you'll need to close/kill all apps using the sound dev, certainly
<eean> [  461.840000]  si3054: cannot initialize. EXT MID = 0000
<crimsun> stgraber: which model?
<eean> lets see if audio works
<stgraber> crimsun: Compaq nx7400
<eean> yea audio still works
<crimsun> eean: ok, so that's correct, since that's what -10 defaults to. For shites and giggles, please post your current dmesg to the bug report and label it for -10, thanks.
<crimsun> stgraber: what's the class 0403 SSID for your machine?
<eean> crimsun: heh um do you have its URL handy?
<crimsun> https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/92909
<eean> thanks
<stgraber> crimsun: 00:1b.0 Audio device [0403] : Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8]  (rev 01)
<crimsun> stgraber: one line further down, please
<stgraber>         Subsystem: Hewlett-Packard Company Unknown device [103c:30a2] 
<eean> ok, back to my audioless computer
<crimsun> stgraber: yep, AD1981_HP
<crimsun> or the silly conexant equiv, which would likely be 5047 something
<stgraber> at least it works :)
* stgraber remembers of his old laptop with a good Sound Blaster soundcard and absolutely no sound problem :)
<eean> crimsun: the model=toshiba didn't do anything
<eean> same errors as before on -11
<crimsun> eean: ok, thanks, that helps.
<eean> cool
<crimsun> eean: I'll likely need you to test something in an hour(ish) if you're still around
<eean> well I'll be around for hourish
<johanbr> I never realized audio support was such a royal pain in the butt. I guess I've just been lucky.
<eean> I've never had a problem before
<eean> not since the Bad Old Days
<crimsun> eean: please also attach /proc/asound/card0/codec* contents to the bug
<eean> ok
<eean> crimsun: its up there now
<crimsun> eean: ok, if you're in -11, please try model=6stack-digout
#ubuntu-kernel 2007-03-17
<crimsun> eeanm: repeating in case you missed it: ok, if you're in -11, please try model=6stack-digout
<eeanm> crimsun: yes I still am, ok
<eeanm> oooh
<eeanm> looks healthy in dmesg
* eeanm opens amarok
<eeanm> crimsun: yea sound works now
<crimsun> eeanm: awesome. Please test headphone jack sense and mic recording if possible.
<eeanm> well mic recording didn't work before
<eeanm> probably since alsa levels are whacked up
<eeanm> I'll get my headphone 
<crimsun> well, one step at a time. Do the speakers mute when the headphones are plugged in, and do they unmute when the latter are disconnected?
<eeanm> crimsun: oh yes, works fine with the headphone
<eeanm> I didn't know that was a alsa driver thing :)
<crimsun> eeanm: brilliant. And may I know the make & model of this laptop, please?
<eeanm> hmm
* eeanm turns it over
<eeanm> crimsun: Toshiba Satellite M115 - S3094
<crimsun> thanks!
<crimsun> bug 92909
<crimsun> eeanm: (fix emailed to Ben.)
<zul> hey
<kylem> heydude, congrats again
<kylem> how's the offspring & missus?
<zul> thanks pics are up now
<zul> they are good, baby is trying to pull out the tubes and stuff..
<kylem> hehe
<zul> will be a real hell raiser one day
<zul> http://www.flickr.com/photos/94043086@N00/
<kylem> coo
<zul> yep surgery on tuesday though
<kylem> nod
<kylem> at least it's pretty soon after birth
<zul> yep thank god...he is pretty healthy right now though
<kylem> that's good to hear
<zul> heh I passed out on Thursday watching the game
<johanbr> "pull out the tubes" ? He's messing with your internet connection? :)
<zul> uh...ok
<johanbr> Feeble attempt at a joke. Sorry.
<kylem> come on, we all know it's not tubes
<kylem> it's messenger pigeons
<kylem> just like al gore defined in rfc0001.txt
<bluffer_> i see thanks Benc ill come back here when i'm in a position to install ubuntu on the real pc till then i ll have to satisfy myself with netless ubuntu 
<bluffer_> BenC thanks again 
#ubuntu-kernel 2007-03-18
<jml> At the moment, 2.6.20-11.18 isn't booting on my macbook.
<jml> answered my own question. never mind.
<jml> out of curiosity, how do you get dmesg output out of a kernel that doesn't boot?
<crimsun> digital photos, handscrawls, whatever it takes
<jml> right. I can imagine that makes responding to bug reports kind of tricky :)
<jml> I'm being bitten by bug 84964. Is the fix supposed to be in 2.6.20-11?
<jml> (rather, I _think_ I'm being bitten by #84964)
<crimsun> wait for 2.6.20-12.19
<jml> will do.
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.19 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 281 Open, 55 Unconfirmed, 165 Unassigned
<Mithrandir> BenC: -12.19 FTBFS on ia64, fyi.
<fabbione> hmmm annoying failure
<BenC> Mithrandir: saw that, I'll fix it for post beta
<BenC> might try pre-beta
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-12.19 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 369 Open, 83 Unconfirmed, 208 Unassigned
<frey> During boot, when fsck is running, I see some messages from udev, e.g. "specified group "nvram" unknown". Is this the right channel to ask or where else should I ask?
<kylem> #ubuntu
<frey> (I'm using feisty, so #ubuntu+1?)
<kylem> sure.
<frey> h
<frey> thx
<kylem> /etc/udev/rules.d/40-permissions.rules:89:KERNEL=="nvram",                      GROUP="nvram"
<kylem> hmm
<kylem> although i guess udev is our responsibility now.
#ubuntu-kernel 2008-03-10
<kraut> moin
<Tonio_> hi there
<Tonio_> cking_: hey, I just wanted to report a little issue with latest kernel update
<Tonio_> cking_: you included my patch for bug 87253
<ubotu> Launchpad bug 87253 in linux "internal speakers do not work on MacBook Pro" [Medium,Fix committed] https://launchpad.net/bugs/87253
<Tonio_> cking_: for some reason I can't figure out, the sound broke on macbook pro....
<Tonio_> cking_: I'm re-reading the patch and I must say I can't figure out why..... that's should work as crimsun's old one...
<tjaalton> Tonio_: bug 200338
<ubotu> Launchpad bug 200338 in linux-ubuntu-modules-2.6.24 "no sound hardy kernel 2.6.24-12 " [Critical,Confirmed] https://launchpad.net/bugs/200338
<Tonio_> tjaalton: so that's maybe more general issue than just my patch then ?
<Tonio_> tjaalton: then I would understand :)
<tjaalton> maybe yes, affecting everyone ;)
<cking_> Tonio_: Looks like a more generic sound problem.
<Tonio_> tjaalton: oki ;)
<Tonio_> tjaalton: thanks for the info :) I really felt guilty with proposing a crackfull patch ;)
<Tonio_> cking_: okay
<cking_> Tonio_: Once the generic problem is resolved, I suggest trying again...
<tjaalton> Tonio_: np, haven't noticed that myself yet, but saw the bug
<Tonio_> cking_: sure
<cking_> Tonio_: Once I reboot my laptop with the latest 2.6.24-12.18 updates I am bound to experience the same problem.
<Kano> hi, does anybody get sound with a hardy snapshot
<Kano> i dont think that disabling sound in the kernel options helps..
<infinity> No, sound's busticated.
<infinity> There's a bug with a billion "me too"s.
<infinity> Check dmesg, unresolved symbols galore in snd_* modules.
<Kano> well thats because somebody thought disabling sound is a great idea
<Kano> i know that
<infinity> Yeah. :)
<infinity> I'm pretty sure it's "known" is my point. :)
<infinity> (It looks like an attempt to move sound/alsa wholesale from linux-image to l-u-m, but breaking it along the way)
<Kano> well i know this even before it was released, exactly when i saw the patch...
<Kano> minimum CONFIG_BLK_DEV_AMD74XX=m should be disabled
<Kano> that gives only problems
<Kano> you can not blackist it without breaking old kernels on mixed installs
<Kano> as soon as update-initramfs would be triggered then you could not boot an older kernel
<BenC> Good morning able bodies
<amitk> BenC: in case you haven't seen see the bug yet - bug 200338
<ubotu> Launchpad bug 200338 in linux-ubuntu-modules-2.6.24 "no sound hardy kernel 2.6.24-12 " [Critical,Confirmed] https://launchpad.net/bugs/200338
<BenC> amitk: isn't that a case of "install lum please" ?
<amitk> BenC: we have installs w/o LUM?
<BenC> amitk: default install is with lum...linux-image-generic depends on it
<BenC> anybody changing that is taking on their own problems...but this looks like something different anyway
<amitk> besides these things are being triggered from LUM modules - see comment 15, for example
<BenC> right...have you updated your install?
<BenC> I'm updating mine to get a good look at the problem
<amitk> BenC: doing it as we speak
<BenC> Hopefully we wont have to delay beta
<cking_> BenC: There certainly is a lot of missing sound related symbols...
<cking_> ..anyhow, you are up early today Ben. 
<amitk> be back after a reboot
 * BenC is rebooting too
<BenC> Ah, CONFIG_SND being disabled makes alsa not able to load
<BenC> stupid
<BenC> I wonder if this can be overcome in lum or if we have to do something in the kernel and re-upload
<cking_> BenC: I suspect it needs to be done in the kernel rather than the lum.
<BenC> cking_: I fear that too, but I'm hoping we can overcome that somehow :)
<BenC> It's very odd though...the lum build should have failed in this case
<BenC> cking_: I think we may be in luck...those missing symbols are defined in and exported from sound/sound_core.c in alsa
<BenC> just need to figure out why it wasn't compiled in
<cking_> BenC: Yep, I am just looking at that. Perhaps turning on CONFIG_SOUND will do the trick... perhaps
<cking_> BenC: Not sure what the difference between CONFIG_SND and CONFIG_SOUND is.
<cking_> BenC: I see know, SOUND for sound core, SND for ALSA.
<BenC> hmm...why isn't soundcore.ko being built...CONFIG_SOUND=m in the build
<amitk> BenC: hmm.. I wonder if I was facing the same problem - obj-$(BLAH) wasn't getting interpreted correctly. See my latest commit for Marvell
<BenC> "To enable ALSA support you need at least to build the kernel with
<BenC> primary sound card support (CONFIG_SOUND).  Since ALSA can emulate OSS,
<BenC> you don't have to choose any of the OSS modules."
<cking_> BenC: Just run a i386 generic build and no soundcore.ko built - looked at: config.generic --> # CONFIG_SOUND is not set
<BenC> cking_: that's the kernel
<BenC> cking_: I was talking about the alsa-driver build in lum
<cking_> BenC: Ah. I see what you mean.
<BenC> I've set CONFIG_SOUND in the kernel and am preparing a new upload though
<BenC> pushed my changes in case you guys want to give it a test run
<BenC> I'm doing a -generic build to make sure all is good
<BenC> Going to drink some coffee while this is going on
<BenC> recompiling the kernel with CONFIG_SOUND works for me
<BenC> No ABI bump, so all clear for an easy upload
<BenC> rebooting to be on the safe side, brb
<BenC> [   26.570791] snd: no version for "unregister_sound_special" found: kernel tainted.
<BenC> a recompile of lum to fix that will be nice though
<siretart> could some kernel hacker please comment on bug #197006? it hits the 'fai' pretty serverly (like in reders it close to unusable) :(
 * allee seconds siretart wish.   Ubuntu kernel have unfortunately a bad charma respect to fai :(
<alex_joni> ubotu: bug 197006
<alex_joni> ubotu: bug #197006
<tjaalton> ubotu is just feeling groggy
<alex_joni> seems like it :)
<BenC> probably hasn't had his coffee
<tjaalton> yeah, rough weekend most likely
<BenC> siretart: got a pretty good response for that...use aufs
<BenC> the unionfs in hardy is a dumbed down 1.4 version, just enough for a working live-cd
<BenC> it doesn't have the NFS support in it
<siretart> BenC: I tried aufs as well, but that crashed for me even earlier
<BenC> siretart: "crashed" is a loose word in this context, since unionfs didn't crash either
<BenC> siretart: what exactly happened when you tried to use unionfs (in what way did it fail)
<BenC> aufs I mean
<siretart> I have to admit that I can only tell from memory. I gave it a quick shot, and on the first glance, it looked like aufs wouldn't work with NFS at all
<BenC> If we can give you an updated aufs to resolve this, we can do that...but updating unionfs to work with NFS is not going to happen
<siretart> hm. I see
<BenC> siretart: how hard is it for you to download and build latest aufs with our kernel headers and test it for fai?
<siretart> depends. what package do I need to recompile?
<BenC> not a package, just the aufs source, and replace current aufs.ko with the one you build
<BenC> or you can update the aufs source in linux-ubuntu-modules-2.6.24 and rebuild that, but it will take longer
<siretart> BenC: ah, that sounds easy to do. Where can I find the latest aufs source?
<BenC> aufs.sf.net
<siretart> ok. will try that. thanks!
<allee> BenC: thx from my side too!  Seems there is a bit of hope again.
<ubotu> Launchpad bug 197006 in linux "NFS over Unionfs prevents updating existing files" [Undecided,Won't fix] https://launchpad.net/bugs/197006
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-12.20 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 11, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<amitk> BenC: planning on re-uploading LUM too?
<BenC> amitk: yeah
<BenC> smb: Can you check on the SB600 USB stress test failure patch that Shane Huang just updated us on?
<BenC> smb: I'd like to get that into the kernel...most likely post-beta though
<smb> BenC: Yes I can do. I was looking at the kernel bug when the first patch came in and it sounded as the problem there had not finally be resolved. But I will have a look at the latest patchset
<BenC> smb: thanks
<BenC> We have the rest of this week to work out any remaining serious issues we want for Beta, but we need to make sure we commit nothing that isn't critical
<BenC> Actually, we only have till Wed. since freeze is Thu
<BenC> Any ABI bumps should be considered a no-go unless agreed upon in advance
<smb> BenC: Ok, I am currently also checking something else towards that and will send that around on the kernel mailing list as soon as I have something.
<amitk> BenC: wrt. LUM, I've got a couple of changes in git now that I'd like to get in today. Or were you planning only a 
<amitk> ...'give back'
<BenC> amitk: No, I was doing an upload from git...I'll pull in your changes too
<amitk> BenC: great, thanks.
<dantalizing> BenC: I was just wondering what the status on the openvz patches is.  I understood they would be loaded last friday.
<dantalizing> just curious
<abogani> cking: Are you around? Are you already working on #177634?
<abogani> cking: I'm already working on it: Can i assign this bug to myself?
<cking> abogani: I've only just assigned myself on it .. 
<cking> ..not sure if you can assign yourself to it.
<abogani> cking: Yes i can. 
<cking> abogani: Ok then, take it from me. :-)
<abogani> cking: Thank you! :-)
<cking> abogani: no problem, you are doing me a favour!
<abogani> cking: It is my little contribution. ;)
<cking> abogani: every little helps
<abogani> :-
<abogani> :-)
<abogani> cking: https://lists.ubuntu.com/archives/kernel-team/2008-March/002198.html
<cking> abogani: is it tested? :-}
<abogani> cking: Yes.
<cking> abogani: thanks!
<abogani> cking: I enabled lzma kernel module on i386 and amd64 only.
<cking> abogani: yes, should it be broadened to all supported architectures?
<abogani> cking: Sorry! I can test it only on i386/amd64 platforms. There Isn't exotic hardware here. :-(
<cking_> abogani: I walk on the safe side, maybe we'll see if BenC OK's it on all architectures.
<abogani> Good night guys! :-)
<BenC> cking_: It's a little late for that sort of patch
<BenC> cking_: Don't want to introduce anything that can especially affect live-cd
<cking_> BenC: OK - won't pull it then.
<sioux> hi :-)
<sioux> no one help me with saa7134_alsa: disagrees about version of symbol snd_pcm_new
<sioux> ?
<sioux> this is my kernel 2.6.24-11-rt
<sioux> hey no one is up?
<_MMA_> Or everyone's busy.
<_MMA_> sioux: Best to file a bug though as the -rt maintainer is gone for the evening.
<_MMA_> Oh. He left.
<sioux> :-)
<sioux> :-D
<_MMA_> sioux: Before you left I said its best to file a bug though as the -rt maintainer is gone for the evening.
<Nilbus> someone said they had /sys/power/pm_trace on a 64 bit kernel?
<Nilbus> oh, hmm
<Nilbus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/145860
<ubotu> Launchpad bug 145860 in linux "x86_64 kernel not compiled with PM_TRACE option" [Undecided,Fix released] 
<Nilbus> x86_64 kernel not compiled with PM_TRACE option
<Kmos> hi
<Kmos> the latest kernel update on hardy killed my sound :(
<Kmos> 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 40)
<_MMA_> Kmos: Known. Use -11 for now.
<Kmos> the -11 worked fine
<Kmos> _MMA_: it's an known issue? nice.. do you know when there is an update for it?
<_MMA_> Apparently it hit Fedora as well. No clue about a update.
<stgraber> Kmos: I saw a new linux-image building tw hours ago
<stgraber> *two
<Kmos> stgraber: nice :)
<Kmos> i'll wait so =)
<Kmos> thanks for the info
<stgraber> https://launchpad.net/ubuntu/+source/linux/2.6.24-12.20/+build/536089 "Enable CONFIG_SOUND at least, so alsa build in lum works
<Kmos> nice
<TheMuso> Wow, it hit fedora as well? Ouch.
<[diablo]> hi
<[diablo]> BenC, ok thanks.. right the problem is:
<[diablo]> I've put 8.04 on my laptop, and im experiencing a weird problem that is I seem to need to hold a key like ALT to keep it booting, and also sometimes in Gnome aswell
<[diablo]> I found that if I do an acpi=off
<[diablo]> it works well, no key holding, the neg being that my MadWifi drivers don't detect any AP's
<[diablo]> any ideas please?
<BenC> [diablo]: try using irqfixup, irqpoll, or biosirq for kernel command line
<[diablo]> with the acpi=off ?
<rico42955> is there a channel to ask about the kernel and drivers?
<_MMA_> rico42955: What's up? Sound issues?
<_MMA_> ie: No sound with new kernel?
#ubuntu-kernel 2008-03-11
<rico42955> well i'm not using the latest kernel, just the gutsy 7.10 generic one
<rico42955> and i'm trying to update my dvb cards driver
<rico42955> in hopes to solve some issues i'm having with it
<_MMA_> rico42955: Thats a support issue. #ubuntu, #ubuntuforums and the forums themselves are the best places.
<rico42955> understood thanks
<Nilbus> how can I get ndiswrapper kernel module to automatically load on boot?
<_MMA_> Nilbus: Add "ndiswrapper" to /etc/modules.
<_MMA_> (without the "")
<Nilbus> _MMA_, thanks
<kraut> moin
<abogani> Is there a Ubuntu Bug Control Team member here?
<tseliot> tjaalton: AMD changed the version of the fglrx driver into 8-3 (instead of 8-03). How will you deal with this issue? (so that 8-3 is not overwritten by 8-02)
<tjaalton> tseliot: no problem there, 8-3 > 8-02
<tseliot> tjaalton: I asked since a user complained about the fact that the package made by EnvyNG was overwritten by Ubuntu's 8-02
<tseliot> read here:
<tseliot> http://albertomilone.com/wordpress/?p=164#comment-3833
<tjaalton> tseliot: hm ok, I'll check it out later today
<tseliot> tjaalton: ok, thanks
<abogani> ogasawara, bdmurray : Are you around?
<thomax> hello
<thomax> can you give me a quick answer on this: is there a preemtive kernel in the gutsy repository?
<abogani> thomax: What level of preemption? NONE, VOLUNTARY, DESKTOP or RT
 * thomax sighs
<abogani> :-?
<abogani> Is there a Ubuntu Bug Control Team member here? :-(
<amitk> abogani: what do you need?
<abogani> amitk: Set bug #177634 to "Won't Fix" and comment this with "As reported here https://lists.ubuntu.com/archives/kernel-team/2008-March/002201.html We are in Kernel Freeze and we can't add necessary modules.", please.
<abogani> amitk: Thanks!
 * abogani like to became part of that Team...
<tjaalton> abogani: just join it
<tjaalton> I'm sure no-one objects ;)
<Kano> could somebody update aufs? i still have some strange effects with it in some cases, like when i use qemu
<zul> abogani: you might want to check on #ubuntu-bugs but yeah just join it
<amitk> abogani: done
<abogani> amitk: Thanks!
<abogani> zul, tjaalton: Ok! Thanks!
<amitk> Kano: I read from the archives that someone from the community is going to report his finding with upstream aufs. If the findings are positive, we will upgrade aufs.
<Kano> is there interest in a new webcam module for lum?
<Kano> ov51x-jpeg
<amitk> Kano: from the website for the driver: "To be clear, JPEG decompression should be considered 'evil' inside the kernel, and the normal way is to handle it in userland, so the original author was right doing what he did."
<Kano> well it is available as debian source package, maybe put at least that in u
<Kano> the latest version
<amitk> Kano: this one: http://packages.ubuntu.com/hardy/ov51x-jpeg-source ?
<Kano> well pretty much outdated, 1.5.6 is required for 2.6.24
<amitk> Kano: ok. Make a request on #ubuntu-devel to grant a freeze exception. There is not much we can do about it.
<Kano> or just add it to lum
<amitk> Kano: that is unlikely to happen, given the warnings on the project's webpage and our freeze status
<Kano> its even in debian extra modules
<BenC> We're a little late in the game to include new modules
<BenC> kernel freeze is in affect
<Kano> did you disable CONFIG_BLK_DEV_AMD74XX? that config option is really bad
<Kano> you have a much better pata driver already
<Kano> pata_amd works for same ids, it would be stupid to blacklist it only because if you add a blacklist and run update-initramfs -uk old-kernel
<Kano> then a 2.6.22 kernel is not bootable
<Kano> not fully sure about via, but this module is really annoying
<Kano> best would be of course a modified initramfs-tools package which allows to write a custom-blacklist before the integrated udev is started
<ubotu> Launchpad bug 177634 in linux "squashfs kernel module does not support lzma" [Medium,Won't fix] https://launchpad.net/bugs/177634
<maks_> Kano: debian initramfs-tools has a blacklist boot param
<maks_> isn't yet propagated after init but helps in race cases
<Kano> must be new
<maks_> no
<maks_> 0.87 - Mon, 16 Apr 2007 20:21:30 +0200
<Kano> hmm not in etch then...
<maks_> sure things move on after etch
<maks_> you are real annoying Kano
<Kano> and also not in ubuntu!
<maks_> that is their fault
<Kano> sure
<Kano> will check that newer sid initramfs
<maks_> thanks to cjwatson_ klibc is uptodate
<Kano> fine,but initramfs is ol
<Kano> d
<maks_> yep lazy kernel team getting paid for nothing :D
<Kano> i guess i just patch the blacklist to the older version...
<maks_> it's basicaly just an appropriate hook that modprobe blacklist
<maks_> inside of initramfs
<maks_> see commit 878b47192bc92fcfe78f34134a8aea70afc161f5 Kano
<Kano> but i never found a hook that was executed always before udev..
<Kano> maks_: is there a webgit?
<maks_> git.d.o
<maks_> bootparam is blacklist=module1,module2,module3 and so on..
<Kano> funny for kanotix i added exactly the same blacklist parameter
<Kano> for the old way without initramfs
<Kano> i just use custom-blacklist not initramfs ;)
<Kano> with a shortcut nousb2 for the ehci_hcd module
<Kano> are you sure that this hook is always before udev?
<Nilbus> I installed a custom kernel, and the update manager constantly tells me there is a kernel update.  How can I add that to a list of exclusions?
<Kano> blacklist it?
<Kano> err put it on hold, the linux meta package
<BenC> Nilbus: is your kernel the same package name as the ubuntu one?
<Nilbus> BenC, yes, the latest ubuntu kernel
<BenC> Nilbus: first off, we don't suggest doing this simply because you miss out on automatic security updates, but I suspect you would rather name your custom kernel a different flavor (IOW, not -generic)
<Nilbus> oh..
<Nilbus> sorry, I thought you were talking about something different
<Nilbus> but the answer is still yes.. I built the ubuntu sources so that I could use CONFIG_PM_TRACE
<Kano> maks_: why is the blacklist not copied to rootfs??
<BenC> Nilbus: Then that sounds like you only want that temporarily...so maybe just ignore update-manager for awhile?
<Nilbus> BenC, I put a hold linux-image-2.6.22-14-generic. Since that includes the version, won't the updates with a different version number come thorough?
<Nilbus> I'm only guessing
<BenC> You'll also want to hold linux-image-generic
<BenC> Nilbus: why are you running CONFIG_PM_TRACE with gutsy kernel?
<BenC> Nilbus: even if you find a suspend/hibernate bug, it wont get fixed in gutsy, and may in fact already be fixed in hardy
<maks_> Kano: how?
<Kano> after mounting rootfs
<maks_> ro, yeah
<maks_> easiest thing would be to m-i-t init script to check for that boot param
<maks_> and blacklist too
<Kano> but then for executing real udev
<Kano> or you add that in init from udev
<Nilbus> BenC, oh, is that right...
<Kano> maks_: do you get me? the blacklist in initramfs is ok, but later udev is started and does not know about it
<Nilbus> BenC, where would I look to find out if my suspend bug is fixed in Hardy?
<Nilbus> well, I guess that's hard to say
<Nilbus> seeing as I don't know what's causing it
<BenC> Nilbus: upgrade and test it, basically
<BenC> amitk, cking, smb: Basically, the kernel that is in the archive now is what we will have for Beta, unless there's something critical that we need to fix now
<BenC> Anything like that going on?
<amitk> BenC: I could use a new upload of LUM so that the beta corresponds to a UME milestone
<Kano> maks_: still awake?
<BenC> amitk: Ok, please prepare that upload with what you want in it, and I'll sign it
<maks_> Kano: did you read my responses?
<cking> BenC: what about the current weekly list of bugfixes?
<Kano> maks_: well why is that missing?
<maks_> what?
<Kano> you need it before udev starts
<Kano> the blackist in rootfs
<smb> BenC: nothing critical
<BenC> cking: we need to be much more stringent on what we will and wont fix for Release-Candidate after beta
<BenC> cking: if it isn't keeping people from booting the live-cd and/or their installed system, and isn't breaking upgrades, we are probably going to mark it wont-fix for hardy
<cking> BenC: like smb then, nothing critical then.
<Kano> maks_: how about patching udev startup?
<smb> BenC: The FTBS thing with the elf lib has a workaround 
<maks_> Kano: i'm not the udev maintainer but you are right that the init of udev would be a good target, sure
<BenC> smb: the palo ftbfs?
<smb> BenC: yes
<BenC> smb: mark it wont-fix for the linux target...it's non-critical to me
<Kano> maks_: it would be pretty much the same code just a rm -f before
 * BenC needs much coffee
<smb> BenC: ok. 
<cking> BenC: I've put two minor patches in over the last 24 hours - they should be OK.
<smb> BenC: I did one critical (I believe) and one minor
<BenC> any of those critical for beta?
<BenC> smb: what's the critical one?
<smb> BenC: x86: Clear DF before calling signal handler
<BenC> smb, amitk, cking: And as a reminder, no commits should be done without a bug link...we need launchpad bugs to justify breaking freeze
<BenC> smb: Ok, we've had that bug (from upstream) for some time now, so it can wait till after beta
<cking> BenC: mine were not critical, one fixed the toshiba_acpi.c to version 0.19a, another fixed UDMA for Acer 1694 Wlmi
<BenC> cking: excellent, that's the one I had on my plate to do before release
<BenC> toshiba acpi may be critical for beta though...considering the testing people will be doing
<smb> BenC: If you uploaded this morning it would be in
<BenC> I didn't, I uploaded yesterday
<BenC> only thing I uploaded this morning was lum and linux-meta
<cking> BenC: The toshiba 0.19a needed adding your previous patch + minor merges from current.
<smb> BenC: Ok, so it is for after beta. np
<tjaalton> mjg59: ideas how to make backlight adjustment working again post -10, something in -11 broke it and possibly the change tagged as "Rationalise ACPI backlight implementation", this is bug 197929
<mjg59> tjaalton: On Thinkpads? Revert the other one
<mjg59> The first patch is fine
<Kano> bbl
<tjaalton> mjg59: so revert the "Ignore ACPI video devices that aren't present in hardware"?
<mjg59> Yes
<tjaalton> I'm just confused :)
<tjaalton> mjg59: ok, I'll try
<ubotu> Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Medium,Triaged] https://launchpad.net/bugs/197929
<amitk> ubotu seems to take 10 minutes to make up its mind about displaying the bug
<smb> amitk: lazy bot
<alex_joni> probably crawling to the catalog, and searching manually through the entries
<tjaalton> zul: did you actually try to build nvidia against xen? it still fails here
<zul> tjaalton: yep Ill take a look
<tjaalton> zul: thanks
<tseliot> tjaalton: the nvidia driver needs a patch in order to work with xen
<dantalizing> exit
<tseliot> tjaalton: the patch is available in this package made by Mandriva: http://rpmfind.net//linux/RPM/mandriva/2007.1/x86_64/media/non-free/backports/dkms-nvidia97xx-169.12-1mdv2007.1.x86_64.html
<alex_joni> tseliot: are you sue about that link?
<alex_joni> sure*
<tseliot> alex_joni: what's wrong?
<alex_joni> doesn't open here
<alex_joni> "It seems that you typed in an incorrect URL, or were redirected to an outdated HTML page by a search engine|
<alex_joni> tseliot: I think it's missing from their second transparent mirror
<tseliot> alex_joni: get to http://rpmfind.net/ , type "dkms-nvidia" in the name field and "mandriva" in the System field
<alex_joni> http://fr.rpmfind.net//linux/RPM/mandriva/2007.1/x86_64/media/non-free/backports/dkms-nvidia97xx-169.12-1mdv2007.1.x86_64.html
<tseliot> tseliot: the results of the search will give something like dkms-nvidia97xx-169.12-1mdv2007.1.x86_64.html
<alex_joni> tseliot: it opens fr2.* here, so the steps you mention produced the same result (no dkms-nvidia found), but adding the fr. before rpmfind.net made it work
<tseliot> alex_joni: good
<tjaalton> tseliot: there is a patch already
<tseliot> tjaalton: ah, ok
<Nilbus> BenC, Were many cases of resume-after-suspend bugs fixed in the Hardy kernel?
<BenC> Nilbus: lots, yes
<Nilbus> nice
<smb> BenC: irc meeting?
<BenC> smb: hmm...missed it, damn clocks
<BenC> amitk, smb, cking: Sorry, got caught up in some bugs...I'll email for a reschedule
<amitk> alright... 
 * amitk signs off for the day
 * cking cking bails out too
 * smb goes for lunch
 * abogani go to Muay Thai coaching :-)
<Mikey>  "Ubuntu kernel development discussion ONLY" I can't ask for any help :(
<dashua`> Will Dell 1505 n wireless cards be supported in 8.04?
<kraut> how often does sf.net synch their mirrors?
#ubuntu-kernel 2008-03-12
<tjaalton> mjg59: reverting the patch you mentioned made my backlight work again, thanks
<abogani> Please guys don't forget my request pull about -rt conf files (https://lists.ubuntu.com/archives/kernel-team/2008-March/002204.html). Thanks a lot! :-)
<AnAnt> I got an nVidia graphics card, and when I boot using kernel 2.6.24-12, the virtual console is blank (can only see the cursor), and Xorg doesn't work, nor does sound, I use nvidia-glx-new. So I have to use the 2.6.24-11 kernel & downgrade nvidia-glx-new in order to make my laptop work
<tjaalton> AnAnt: install linux-generic
<AnAnt> tjaalton: is that supposed to bring in another package ?
<AnAnt> tjaalton: both linux-image-generic & linux-restricted-modules-generic are up to date
<rzr> asac: I am the one who is quotted on this thread : http://thread.gmane.org/gmane.linux.acpi.devel/27726
<tjaalton> AnAnt: ok, so file a bug
<AnAnt> ok
<AnAnt> tjaalton: btw, there is a bug I filed a year ago, and it still didnt get fixed (bug #146151)
<ubotu> Launchpad bug 146151 in linux-source-2.6.24 "pcspkr module causes hangup on HP Pavilion dv6391 when system beeps" [Undecided,New] https://launchpad.net/bugs/146151
<asac> rzr: hi.
<asac> thanks
<asac> rzr: do you know about an ubnutu bug about this?
<AnAnt> so, is there something I should do (subscribe someone or put some tag) to make developers look at it ?
<asac> rzr: maybe include the link to that thread in your mail.
<rzr> asac: this patch is included in kernel package i think
<asac> ah ok.
<rzr> mailed
<asac> thx
<rzr> but andrew morton help to get it upstream
<rzr> btw, ubutunu violated debian policy when the accepted a patch upstream refused :)
<rzr> asac: 
<rzr>   * acpi: DSDT from initramfs patch
<rzr>     - GIT-SHA 7b650b00d82ec5c80452b2f99de1cfdbae2a465b
<rzr> most /usr/share/doc/linux-image-2.6.20-16-386/changelog.Debian.gz
<rzr> that's this one
<tjaalton> AnAnt: that bug is less than six months old
<AnAnt> tjaalton: oh, yes I meant that I filed it in 2007, sorry
<AnAnt> tjaalton: so, is there anyone looking at that bug or not ?
<BenC> Good morning peeps
<tjaalton> AnAnt: don't know, I'm not :)
<cking> Morning BenC
<amitk> BenC: http://thread.gmane.org/gmane.linux.acpi.devel/27726
<zul> morning
<BenC> amitk: that rocks!
<BenC> yay for intrepid not needing us to carry that patch around any more
<maks_> that patch is a bugger, see discussions with hch rzr
<maks_> and seens when does ubuntu ever care about upstream quality of a patch rzr :P
<BenC> Len's suggestions for fixes are a good idea too
<AnAnt> BenC: regarding bug #146151 , I suspect that the problem is actually connected to apic
<ubotu> Launchpad bug 146151 in linux-source-2.6.24 "pcspkr module causes hangup on HP Pavilion dv6391 when system beeps" [Undecided,New] https://launchpad.net/bugs/146151
 * BenC wonders why things are assigned to linux-source-2.6.24
<BenC> that src doesn't even exist
<AnAnt> BenC: what should it be assigned to then ?
<BenC> linux, like it already is
<BenC> the linux-source-2.6.24 target is invalid
<AnAnt> ok
<BenC> AnAnt: hmm...pcspkr being loaded isn't terribly uncommon...what is uncommon is that the system beep uses pcspkr instead of your built-in audio
<AnAnt> BenC: well, I don't mind that the system beep uses pcspkr, since my laptop seems to have a PC speaker somehow
<BenC> AnAnt: It's not a matter of you minding, it's that it shouldn't by design :)
<AnAnt> BenC: the problem is that if I boot without 'noapic' this pcspkr causes a freeze when used
<BenC> AnAnt: Ok, that sounds like a completely different issue then...can you pastebin /proc/interrupts (when booted without noacpi)?
<AnAnt> BenC: sure, I'll have to reboot though
<AnAnt> BenC: anything else ?
<tjaalton> BenC: I've got a new l-r-m ready with fglrx 8-3, should it need some FFE handling?
<tjaalton> fixes at least two bugs from the list
<BenC> tjaalton: No, go ahead and upload
<tjaalton> BenC: thanks, will do
<BenC> tjaalton: thanks
<BenC> tjaalton: just make sure it is well tested because it will be in beta :)
<AnAnt> BenC: rebooting...
<tjaalton> BenC: people have tried it and confirmed that those bugs are fixed, but surely it'll have some issues still (as always) :)
<AnAnt> BenC: I booted without noapic, here's /proc/interrupts: http://pastebin.com/m71747744
<BenC> AnAnt: nothing jumps out...I'd suggest trying some of the acpi debug stuff that can be found on the wiki
<AnAnt> BenC: what wiki ?
<BenC> wiki.ubuntu.com of course :)
<AnAnt> acpi debug or apic debug ?
<AnAnt> BenC: acpi debug or apic debug ?
<BenC> might as well check both
<AnAnt> I can't find anything about apic debug
<BenC> AnAnt: you could boot with apic=debug and pastebin that dmesg output
<BenC> AnAnt: also (separately) you could try booting with nolapic and see if just that fixes the problem
<AnAnt> ok
<AnAnt> BenC: dmesg output when booting with apic=debug : http://pastebin.com/m75254cb
<AnAnt> BenC: when I use nolapic, Xorg doesn't work (I use an nvidia-glx-new)
<AnAnt_> BenC: sorry, laptop crashed
<AnAnt_> BenC: I booted now with noapic to avoid that
<AnAnt_> BenC: did I miss anything ?
<NthDegree> does Ubuntu have any intention of using POSIX Filesystem Capbilities
<NthDegree> since it's a now mainline feature and can reduce the amount of applications needing root durastically... it only seems logical to have it set up by default
<NthDegree> yet:
<NthDegree> mhare@inspire:~$ cat /boot/config-2.6.24-12-generic | grep FILE_CAPABILITIES
<NthDegree> # CONFIG_SECURITY_FILE_CAPABILITIES is not set
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-12.21 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 11, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<BenC> NthDegree: that's a better question for the security team
<NthDegree> BenC: ah.. #ubuntu-security i'm guessing right?
<BenC> yeah
<NthDegree> btw if I managed to get it to compile as a module could I theoretically compile it from the Ubuntu source and load it into an Ubuntu-packaged kernel?
<NthDegree> as in so that I can have the nice supported Ubuntu kernel but have the extra feature still
<BenC> security caps can't be modules anymore, IIRC
<NthDegree> oh yeah... that's why Dazuko is having problems
<NthDegree> forgot about that :$
<NthDegree> BenC: thanks =]
<BenC> np
<AnAnt> BenC: so what else should I do ?
<aspushkin> hello, can anybody help me with the following: when i attach to process via  ptrace(PTRACE_SETOPTIONS,...) the process i attached to hangs up completely
<aspushkin> i have following options set: int options = PTRACE_O_TRACEFORK | PTRACE_O_TRACEVFORK | PTRACE_O_TRACEEXEC | PTRACE_O_TRACECLONE | PTRACE_O_TRACEVFORKDONE ;
<aspushkin> when i exit my tracer program, the process i attached to resumes normal operation....
<geos> hello
<geos> someone here?
#ubuntu-kernel 2008-03-13
<WorkingOnWise> I have an Averatec laptop, 7170EH-1. It has a very hacked BIOS that does NOT play well with the Ubuntu Gutsy Kernel, or Hardy for that matter,during bootup  except the recovery kernel. On the genaric kernels, the display switches to a funky white  fine lined display, and then switches to a good picture after the nvidia drivers load. on the vga, vesa, and nv drivers, the display never goes to a readable state. On the 
<kraut> moin
<AnAnt> Hello, regarding bug #129910 , I used a workaround to fix it, and it worked untill I upgraded to linux kernel 2.6.24-12
<ubotu> Launchpad bug 129910 in linux "Blank ttys when using vesafb (vga=xxx)" [Medium,Fix released] https://launchpad.net/bugs/129910
<AnAnt> the workaround was commenting out the framebuffer modules in blacklist file, and adding vesafb & fbcon to /etc/initramfs-tools/modules~
<AnAnt> s/~//
<AnAnt> now I am getting blank ttys
<ln-> kick?
<kraut> please
<kraut> lol, he is an ubuntu-member...
<ln-> so?
<tjaalton> hardly critical if someone changes his nick ten times in an hour
<kraut> anyhow how often somebody changes his nick, away-nicks are senseless and annoying.
<tjaalton> :)
<ln-> tjaalton: is it ok if i start doing that ten times in an hour?
<alex_joni> ln-: might be easier to ask 
<alex_joni> ln-: might be easier to ask \sh directly to switch that off
<mjg59> \sh: Please don't keep changing your nick on away in low-volume channels - it's very distracting
<ln-> \sh: Please don't use an away nick at all, it's silly and pointless.
<\sh> mjg59: tell my ubuntu to not play fool with me...so irssi is staying on my proxy :(
<mjg59> \sh: ?
<\sh> mjg59: this installation was crashing all the time...and my dircproxy is changing the nicks when the irc client disconnects...:(
<\sh> now everything is back to normal...
<BenC> Good morning fellow monkeys
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-12.22 | Latest news: 2.6.24 Release in Hardy | Next meeting: Mar 11, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<abogani> BenC: Good Morning, Ben.
<BenC> We just made 2.6.24-12.22 into the archive before beta freeze...that's pretty much what's going out in beta, so if you had plans for it, you missed out :)
<BenC> (that's to everyone)
<zul> nooo...i wanted to get in $RANDOM patch ;)
<johanbr> cking: Hi. I just wanted to ask if you've had a chance to look at bug #183033 ?
<ubotu> Launchpad bug 183033 in linux-source-2.6.22 "Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1" [Undecided,Confirmed] https://launchpad.net/bugs/183033
#ubuntu-kernel 2008-03-14
<kraut> moin
<abogani> kraut: Morning
<kraut> morning abogani 
<AnAnt> BenC: ping
<Kano> could somebody disable 2 usb ids for sn9c105
<Kano> the driver is loaded but not working
<Kano> 0c45:60fe does not work - i dont know any other driver for that yet
<Kano> but
<Kano> 045e:00f5 does not work with sn9c105 - the also installed gspcs driver works
<Kano> please disable both
<Kano> 045e:00f5 Microsoft Corp.
<Kano> 0c45:60fe Microdia
<Kano> the ms cam is just a bit yellow tainted *g*
<alex_joni> Kano: wonder if that can be done in freeze
<Kano> well if you cant, i can do for my kernels
 * alex_joni is not part of the kernel team.. so I don't know..
<Kano> well i compile the kernels for etch/kanotix
<mario_limonciell> BenC, are you going to be joining?
<BenC> mario_limonciell: Yes, sorry, lost track of time
<BenC> mario_limonciell: calling in now
<smb> BenC: I just pushed linux-meta (hardy) and put .dsc to sign on zinc:~smb/2sign. I removed lrm dep for virtual and fixed the descriptions.
<smb> mjg59: Could you help me with your opinion on bug 107929. Do you have an idea why the patch to remove non-existent hw causes troubles with backlight?
<ubotu> Launchpad bug 107929 in reconstructor "[needs-packaging] reconstructor" [Wishlist,Invalid] https://launchpad.net/bugs/107929
<smb> mjg59: sorry wrong number
<smb> mjg59: bug 197929
<ubotu> Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Medium,Triaged] https://launchpad.net/bugs/197929
<smb> BenC: ping
<MiHu> Hi everybody. A few days ago I reported bug #201197. On 2007-05-17, Ben Collins removed my driver called "MXB" from the list of modules to be build. I think there was a misunderstanding which of my drivers supports which kind of hardware. Is anybody willing to discuss this issue with me now?
<ubotu> Launchpad bug 201197 in linux-ubuntu-modules-2.6.22 "Driver for "Multimedia eXtension Board" (MXB) missing" [Undecided,New] https://launchpad.net/bugs/201197
<mjg59> smb: BecauseThinkpad weirdness
<mjg59> I haen't had time to root-cause it yet
<smb> mjg59: Ok, so I guess it is better to wait a little bit before reverting anything. As I can say from my thnkpad, not all models are broken.
#ubuntu-kernel 2008-03-15
<pwnguin> is there a gitweb of the ubuntu kernel?
<pwnguin> aha
<pwnguin> fun. which one of these branches should i be looking at as a base?
<pwnguin> ubuntu/ubuntu-hardy.git?
<pwnguin> ah; i guess the usbgecko would be the console one logs in with?
<bullgard4> What is the function of the bash script /usr/lib/pm-utils/funcrtions?
<bullgard4> What is the function of the bash script /usr/lib/pm-utils/functions?
<AnAnt> Hello, regarding the blank ttys bug #129910 , is there any further info I should provide ?
<ubotu> Launchpad bug 129910 in linux "Blank ttys when using vesafb (vga=xxx)" [Medium,Fix released] https://launchpad.net/bugs/129910
<AnAnt> Hello ?
<pwnguin> opinions on including the following patch in hardy?
<pwnguin> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2008.0/kernel-2.6/current/PATCHES/patches/DB35_mmc_power_up_delay.patch?view=markup&pathrev=114631
<pwnguin> reports suggest it fixes bug #137686
<ubotu> Launchpad bug 137686 in linux-source-2.6.22 "[gutsy] [regression] (regression from edgy to feisty and to gutsy) tifm_sd module not working and not producing any message in logs" [Low,Triaged] https://launchpad.net/bugs/137686
#ubuntu-kernel 2008-03-16
<shenki> im the reporter of bug 200057, and was wondering who i needed to poke about it
<ubotu> Launchpad bug 200057 in linux "HP / Compaq laptops crash with port 0x80 delay write" [Undecided,New] https://launchpad.net/bugs/200057
<shenki> it's an issue that will occur with any kernel before 2.6.25, resulting in hard locks galore for owners of affected laptops
<Lure> shenki: it might be harder to get kernel developer here over weekend
<Lure> shenki: I would suggest to write to ubuntu-kernel mailing list, or try tommorow
<shenki> Lure: yeah, i figured
<shenki> i've put off doing something about this for long enough, i thought i'd atleast make a start this weekend
<pwnguin> sadly, theres a bit of a mismatch between volunteering your weekend to test / fix ubuntu
<pwnguin> and being paid to work weekdays fixing the kernel
<maks__> ACPI: Remove ACPI_CUSTOM_DSDT_INITRD option
<maks__> http://marc.info/?l=linux-kernel&m=120560901809175&w=2
<alex_joni> are there any instructions on building custom kernels?
<alex_joni> I just built a kernel based on the latest hardy one, but I'm not sure how to build the lum package
<kraut> moin
<eradicus> moin kraut
<jdi9> Sup.  Can someone clue me in on why ALSA and OSS are still in the virtual kernel flavor (since removed from generic)?
#ubuntu-kernel 2009-03-09
<doctormo> JanC: So I've managed to get it working one way, I've been picking apart the serial code coming out of the wine program, but that isn't being sent to the usbtty0 correctly by slsniff
<JanC> I only found those 2 using google, have no experience with them  ã
<JanC> also, from what I've read from somebody using cu & tee on a BSD system (which could work too, in theory), it's not always easy to get timing right with serial devices
<JanC> BTW: I googled for "linux serial tee"
<JanC> there might be more to find if you do
<JanC> doctormo: ^^^
<doctormo> JanC: Thank you so much for your help
<doctormo> JanC: I remeber back in the past using a program which would output any and all open file handles.
<doctormo> Perhaps that would work in the case, but I forget what the program was called.
<JanC> lsof ?
<doctormo> JanC: sort of but it worked a bit like xargs, where you'd specify the command to execute as an arg
<JanC> probably a wrapper script or something?
<JanC> based on lsof -p ?
<doctormo> JanC: it was probably lsof with some specific options
<Lure> do we cherry-pick also from non-linus git's? there is one quirk in sound-2.6.git - see bug 285834
<ubot3> Malone bug 285834 in alsa-driver "Audio out on x200/x200s dockingstation doesn't work" [Undecided,New] https://launchpad.net/bugs/285834
<apw> Lure, as a general rule we try and pick stuff which is in or definatly going to linus' tree
<apw> if the quirk is likely to go upstream and is clean and self-contained we do consider them at times
<Lure> apw: will first test in ppa and then talk with audio guys what they think
<Lure> apw: thanks for info
<wgrant> Can we get a more recent aufs into Jaunty?
<apw> the maintainer was talking about updating it
<elmargol> I have found a ubuntu related regression. Is there a tag or something in order to mark the bug?
<Keybuk> apw: floppy patch accepted upstream into -mm
<apw> Keybuk, good news indeed
<smb_tp> elmargol, several, depending on where the regression is. For a regression between releases regression-release, if its in a -proposed pocket regression-proposed or regression-update if the regression made it into updates
<apw> i am likely to sru that to intrepid today, as it has lots of good positive feedback
<apw> smb_tp, or regression-potential if its in jaunty (i believe)
<elmargol> smb_tp: it is a gregression between the ubuntu intrpid kernel and the mainline kernel
<Keybuk> apw: I'm going to fire off the rest of the alias patches today
<Keybuk> Kay and I found a few more
<smb_tp> apw, Was about to ask
<smb_tp> elmargol, Hm, is it working in Hardy?
<apw> awsome indeed.  i am guessing we'll sru the ones people find a problem wth now for intrepid
<Keybuk> they've all gone from modprobe conf files
<Keybuk> so there's only a regression if you delete them ;)
<Keybuk> my big goal for today is to get m-i-t 3.7 pre finally uploaded
<elmargol> smb_tp: No. 2.6.27-11-generic is affected 2.6.27-02062719-generic <- works perfect bug #103210
<ubot3> Malone bug 103210 in linux-ubuntu-modules-2.6.22 "ipw3945 Wifi connection is very slow" [Undecided,Confirmed] https://launchpad.net/bugs/103210
<smb_tp> I would tend to call that not a regression. Since for a regression it must have worked before with a Ubuntu release kernel.
<elmargol> The short descripton is. I connec to a wireless network and starty downloading a file... After 100-200MB de downloads drops from 1,7MB/s to 100kb/s... If I reconnect I get 1.7MB/s for another 100MB
<smb_tp> If it was working well in Hardy but got worse with Intrepid it would be regression-release
<elmargol> Isn't it still worth investigating? since it works using the mainline kernel?
<smb_tp> elmargol, sure might be that
<smb_tp> commit 742dfb34af298ee2308c9df22d677bc733e277cb
<smb_tp> Author: Tomas Winkler <tomas.winkler@intel.com>
<smb_tp> Date:   Mon Oct 6 16:05:29 2008 +0800
<smb_tp>     iwlwifi: scan correct setting of valid rx_chains
<smb_tp> which came in with 2.6.27.19, otherwise the -proposed kernel for intrepid has the stable fixes up to 2.6.27.18. 
<smb_tp> So probably if you try proposed and it works not, then it is pretty much cornered for that. If you can update the bug with that info, we can get a test kernel that has this additional patch and you could verify this helps
<elmargol> smb_tp: it chould work on jaunty?
<smb_tp> lemme see
<smb_tp> That patch went into Jaunty, so it should work there, too
<elmargol> Ok. i try the alpha and let you know
<smb_tp> elmargol, but the patch itself is simple and should be easy to SRU, with a test kernel to try.
<smb_tp> elmargol, Would it be possible for you to have the kernel and lrm from proposed enabled and installed? Then I could provide a test kernel based on that
<elmargol> lrm?
<elmargol> smb_tp: if you point me to a build i chould try i can do that
<smb_tp> elmargol, linux-restricted-modules (since the kernel from -proposed has a different abi it requires some dependant packages to be upgraded). Actually you could activate my ppa to get the right base and then replace the kernel later by a test version.
<smb_tp> My PPA is at https://launchpad.net/~stefan-bader-canonical/+archive/ppa
<elmargol> smb_tp: sure... give me the ppa and i try it
<elmargol> smb_tp: sure... give me the ppa and i try it
<smb_tp> elmargol, The PPA is the one above 
<smb_tp> as a base.
<elmargol> please repost I had a disconnect
<smb_tp> updated kernel will follow as soon as compiled
<smb_tp> ah ok
<smb_tp> <smb_tp> My PPA is at https://launchpad.net/~stefan-bader-canonical/+archive/ppa
<elmargol> smb_tp: there are only linux* packages?
<smb_tp> elmargol, correct. Just to get an updated Intrepid kernel
<elmargol> ok installing now
<smb_tp> elmargol, It seems that patch is already in there.
<smb_tp> Came in as a SRU for bug 330902
<ubot3> Malone bug 330902 in linux "[Intrepid] Update kernel to Linux 2.6.27.18" [Medium,Fix committed] https://launchpad.net/bugs/330902
<smb_tp> Ah, sorry. That was fixed in stable 2.6.27.18, so try that. If that works it is already in progress of being released
<elmargol> ok i download the packages from your ppa and reboot
<smb_tp> k
<elmargol> smb_tp: i monitor this a day and report back to you
<elmargol> have to go to work now
<smb_tp> elmargol, ok, cool. thanks
<heywood123> hello all
<heywood123> anyone here particularly familiar with hyperthreading?
<heywood123> i'm trying to figure out the difference between passing "noht" to the kernel at boot time...
<heywood123> and putting something like "echo 0 > /sys/devices/system/cpu/cpu1/online" in rc.local
<heywood123> are these equivalent?
<anubhav> heywood123:noht  is no longer supported
<heywood123> anubhav: that's very useful -- thanks. do i have the syntax of the other command correct?
<heywood123> if so i'll just do some testing with it on and off to see if it makes any difference
<elmargol> smb_tp: your kernel seems to fix my network problems... 
<anubhav>  heywood123:yup
<heywood123> @anubhav: sweet. thanks for the clarification!
<smb_tp> elmargol, Great. One less to go. Can you update the bug with your results (which kernel worked) and I do the rest?
<anubhav> :)
<elmargol> smb_tp: i copy one more file to be sure and comment to the bug
<smb_tp> Ok, sure. Thanks
<elmargol> it did only take 1,5 years in order to fix this problem xD
<smb_tp> heh, quite a long time
<emgent> hallo
#ubuntu-kernel 2009-03-10
<TheMuso> pgraner: Have you managed to try the patch I attached to bug 331589 yet?
<ubot3> Malone bug 331589 in alsa-utils "system beep in jaunty is the most annoying sound known to man" [Medium,Fix released] https://launchpad.net/bugs/331589
<Yasumoto> hey guys, I'm trying to build a vanilla kernel (from the git repo) using make-kpkg, and seem to be running into issues running make http://paste.ubuntu.com/129064 
<Yasumoto> Should I be applying ubuntu-specific patches for this? I'm not sure if this is a typically supported method of compiling
<dtchen> Yasumoto: see CONCURRENCY_LEVEL
<dtchen> (in the appropriate man page version at http://manpages.ubuntu.com/cgi-bin/search.py?cx=003883529982892832976%3A5zl6o8w6f0s&cof=FORID%3A9&ie=UTF-8&q=make-kpkg&titles=Title)
<Yasumoto> dtchen: will do, thank
<Yasumoto> *thanks
<Yasumoto> oh wow, I set it to N by not reading https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<Yasumoto> dtchen: thank you
<Yasumoto> I think I assumed N=no or something
<foxbuntu> Hi all. I am working on a few dev issues surrounding MythTV on the Mythbuntu project and one is HDMI audio on my ALC1200, I am curious if someone can enlighten me why alsa 1.0.19 can't be included for 9.04 release? (asking nicely please dont take offense, I really dont know the reasons)
<dtchen> TheMuso: looks like http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h=ed3da3d9a0ef13c6fe1414ec73c9c1be12747b62 is worth looking over
<TheMuso> dtchen: thanks looking
<dtchen> foxbuntu: 1) are you positive the enablement patch(es) can't be backported? 2) Alsa-kernel generally requires a corresponding bump in userland [Alsa-lib].
<TheMuso> dtchen: hrm thats a big diff. I think we will have to put a good argument to get it in.
<dtchen> TheMuso: yeah, i'm not positive it's a winner yet, but i'll test it locally this week. it's not as vital given we've disabled glitch-free in PA by default.
<foxbuntu> dtchen, I have not looked at the patches being back-ported yet, I was just curious from the kernel standpoint why it isn't going to be done
<TheMuso> dtchen: right
<dtchen> (anyhoo, Z -> work)
<foxbuntu> dtchen, the 1.0.18 in A5 + patches does not work with my ALC1200 however 1.0.19 does, thats why I was asking
<JanC> foxbuntu: we're in version freeze, so new versions must bring clear advantages and (almost) no disadvantages (that's why)
<foxbuntu> JanC, well, thats a pretty clear reason right?
<foxbuntu> :)
<foxbuntu> so back-ports it is
<foxbuntu> thanks guys
<JanC> foxbuntu: extra hardware works = advantage, but can you prove no disadvantage (like breaking other hardware) ?  ã
<foxbuntu> JanC, at this point, no I need the extra hardware to test on, and/or spend some time looking at the patches
<apw> foxbuntu, generally because if we can keep the kernel the same as upstream we gain advantages when fixes come along, and from the testing that was and is being done on that kernel as a unit, plus there are kernel/userspace dependancies to keep in sync which are not necesasrily possible
<apw> the more delta we carry the more work it is for us rather than the general kernel community to carry
<riham> hi all , anybody here with experience in Kernel AIO .. I have been trying to work it out using libaio but I dont get enhancement in performance 
<riham> hi all , anybody here with experience in Kernel AIO .. I have been trying to work it out using libaio but I dont get enhancement in performance
<cj> hey all.  bryce recommended that I report suspend/resume issues here.  anyone want to have a crack at it?  I'm dist-upgrading to jaunty now, but it didn't work in intrepid.
<cj> http://rafb.net/p/2Q6UwD92.html
<Keybuk> mjg59: I notice a 10s boot speed difference between the "ondemand" and "performance" scaling governors
<Keybuk> mjg59: is this to be expected?
<cj> Keybuk: which way?  performance 10s less?
<Keybuk> in the obvious way
<anubhav>  Keybuk:what are the available freq's for the cpu?
<Keybuk> anubhav: 1600000, 1333000, 1067000, 800000
<anubhav> imo most of the boot time is due to IO i can't see a connection,but maybe bootchart can be helpful
<Keybuk> yes, thankyou
<Keybuk> I'm past all that and now at the "err, Matthew" stage of debugging
<Keybuk> :p
<johanbr> For some reason, the ondemand governor is really slow to trigger for me in recent kernels. Even when compiling, it goes back and forth between highest and lowest frequencies.
<johanbr> Maybe that's what's happening to you too?
<anubhav> in that case the stats would also help
<Keybuk> what stats would you like?
<anubhav> cpufreq/stats
<Keybuk> do you know much about the cpu frequency scaling part of the kernel?
<Keybuk> ie. can you fix the problem?
<anubhav> wrote a driver once
<anubhav> johanbr:maybe you can tweak the "up_threshold" parameter within "/sys/devices/system/cpu/cpu0/cpufreq/ondemand"
<johanbr> anubhav: sure, I'll try that, thanks
<johanbr> initial stats: http://pastebin.ca/1357538
<johanbr> stats an hour or so later, just after compiling a program: http://pastebin.ca/1357539
<anubhav> whats the current "up_threshold"
<johanbr> 95
<anubhav> ohh
<anubhav> no wonder
<johanbr> that's not good?
<anubhav> try 30
<johanbr> I'll give that a try. Thanks again. :)
<mjg59> Keybuk: No, not in the slightest
<mjg59> Keybuk: For certain workloads you'll see reduced io throughput with ondemand, but not significant
<Omegamoon> anyone here with experience with the sharp zaurus?
<Omegamoon> I'm trying to get the 2.6.28 kernel working for some time now on spitz
<Omegamoon> I finally got the device to suspend when pressing the on/off key
<Omegamoon> but it won't resume after doing a suspend, no matter what I do
<Omegamoon> I have to do a hard reset to get the device back to life
<Omegamoon> any clues?
<anubhav> Omegamoon: can you get a console on the device
<Omegamoon> anubhav: yes, no problem
<Omegamoon> 99% works just fine, only suspend/resume has problem(s)
<anubhav>  Omegamoon: are you using some distro?
<Omegamoon> ubuntu jaunty
<anubhav> so you can check the kernel logs and get some hints
<Omegamoon> I'll check again... one moment
<Omegamoon> anubhav: last line is "apm-power: Requesting system suspend"
<anubhav> Omegamoon: whats the output of " cat /sys/power/state"
<Omegamoon> anubhav: mem
<anubhav> on the device do you have a serial console?
<Omegamoon> yes I do
<anubhav> are you sure that the device suspends successfully ?
<Omegamoon> ehm, how can I check, it turns off
<anubhav> some devices have blinking LEDs 
<Omegamoon> the zaurus has leds, but they aren't used for that kind of things
<anubhav> also on the serial console you can check the output of "echo  mem > /sys/power/state "
<anubhav> do you get some messages on the console after issuiing that command?
<Omegamoon> no, unfortunately not
<anubhav> does it go to sleep after that command?
<Omegamoon> yes, it does
<anubhav> unfortunately its like permanent sleep :)
<Omegamoon> but after that it's dead, no resume :-(
<Omegamoon> verrrry sleepy, like me actually :-)
 * Omegamoon is resetting the zaurus again
<anubhav> can you try "echo 7 > /proc/sys/kernel/printk" before  "echo  mem > /sys/power/state "
<Omegamoon> rebooting, 1 moment
<Omegamoon> anubhav: zaurus is dead again, have to reset, reboot and check the kernel log
<anubhav> Omegamoon:Chk this http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-02/msg09570.html
<Omegamoon> anubhav: the 'echo 7...' doesn't show up anything
 * Omegamoon is checking the link
<Omegamoon> anubhav: I saw that one earlier. It has a follow-up too (http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-02/msg09934.html)
<anubhav> Omegamoon: so it seems that with newer kernel suspend got broken
<Omegamoon> anubhav: yeah, there was a huge clean-up
<anubhav> Omegamoon: after suspend does it wake up if you insert the charger?
<Omegamoon> anubhav: believe me, back-porting is not a good plan
<anubhav> Omegamoon: suspend/wakeup stuff is difficult to debug.
<Omegamoon> anubhav: it doesn't wake up when inserting the charger
<anubhav> Omegamoon: i think you should get in touch with Pavel and find out if he is looking  into this issue.
<Omegamoon> anubhav: I'll do that
<Omegamoon> anubhav: thanks for your help, I have to go now
<anubhav> Omegamoon: sure :)
<bdmurray> rtg: http://qa.ubuntu.com/reports/bug-fixing/canonical-kernel-team-jaunty-fixes-report.html
<lool> Does someone know whether the lpia kernel config was changed similarly to the i386/amd64 ones for cpufreq modules?
<lool> (I'd like to drop powernowd from the mid seed)
<lool> The same changes were done, great
#ubuntu-kernel 2009-03-11
<Maahes> are there known issues with kernel 2.6.27-13 generic and all versions of the Nvidia binary drivers?
<Maahes> because I am getting....beyond bad issues with all versions thereof. like binary information being written out on config files
<Maahes> interspersed with strings in german, for some reason
<Maahes> in any event, so far as I can tell 2.6.27-13 is broken for Nvidia binaries 177.82-0ubuntu0.1 and 173.14.12-1-0ubuntu5.1
<Maahes> whether installed via envyng or restricted manager
 * Maahes decides to revert to 2.6.27-12 for awhile
<purentropy> WHen I try to boot from the live CD my system HANGS at [ 97.125547] ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15  
<purentropy> never gets to the desktop
<purentropy> i can't run any terminal commands because i never get to the livecd desktop.  Can anyone make any sense of this message?
<purentropy> I have Nvidia Nforce 630i chipset.  WDC 500GB SATA HDD.  Using 8.10 LiveCD. No externals plugged in besides monitor,keyboard,mouse,ethernet
<n2diy> purentropy: ask the whole question in #ubuntu, the Nvidia stuff is important, and not kernel related.
<davmor2> Guys I just completed a 64bit Ubuntu install from netboot mini.iso and am greeted with a nice little window that says....  Kerneloops-ui  Your system had a kernel failure
<davmor2> What logs do you need is it just /var/log/kern.log?
<davmor2> I'm having to carry on testing so I've put logs here:  http://www.davmor2.co.uk/kern.log  http://www.davmor2.co.uk/debug.log  http://www.davmor2.co.uk/dmesg.log
<smb_tp_> davmor2, I am at a loss about what kerneloops is complaining. There is nothing apparent in the log files...
<davmor2> smb_tp_: No idea either.  I finished the install rebooted and was greeted by 2 kerneloops windows one behind the other.  I'm doing a kubuntu install so I'll check if it happens again
<smb_tp_> davmor2, ok. I'll peek at the package in the meantime
<davmor2> smb_tp_: It wouldn't be because it is a netboot install and part that it wanted was missing could it?
<davmor2> if so I'll have a look in the installer folder and see if there is a kern.log in there too which might help
<smb_tp_> I wouldn't rule out this at the moment since I am not sure what it looks for exactly. At least it sounds unlikely that it found something in the dmesg
<smb_tp_> Except it take the WARNINGs as something bad, which would be bad
<davmor2> it only affects 64bit to 32 bit worked fine
<smb_tp_> davmor2, The ui is IIRC triggered by a file being  in /var/crash... Maybe that has some info
<davmor2> smb_tp_: if I get it again in kubuntu (which I'm guessing I should)  I'll have a look and see if there is anything in there for you
<smb_tp_> ok
<ia> hello. maybe it's wrong place for this question, but i don't know, where else i can ask about it. I use jaunty with latest updates at 2.6.28-9.29 kernel. during boot i get a few (~10) messages with modprobe usage text and when gnome starts, it shows warning that kernel can't use cpu frequency scaling. at 8.27 and earlier everything was fine. I just intresting to know, does anybody else have the same strange issue?
<davmor2> smb_tp_: Can't reproduce at the moment might just of been an install issue If it does come back up I'll post any crash logs too :)
<smb_tp_> davmor2, Ok, sure. Lets see
<wmat> ia: ensure you're system has the latest BIOS
<wmat> ia: then review the Launchpad bugs for fpu frequency scaling as there's been a few
<wmat> ia: s/fpu/cpu
<sconklin>  have we ever considered pulling the upstream video4linux directly into a distro? The reason I ask is that there's a good bit of device enablement in the delta between what we have in jaunty and what's upstream in v4l
<smb_tp_> I do not remember this being discussed before...
<smb_tp_> But I could think this increases the burden when syncing. rtg knows the pain for wireless
<sconklin> I'm looking at a patch now that fixes an open bug, but it's against upstream. Still not too hard to backport, but I wondered whether it was worth the risk to take the whole pile. I think I'd be willing to serve as the go-between for our kernels. I think it's too late for Jaunty in any case.
<rtg> smb_tp_: it all depends on how often we sync. we could think about it for Karmic.
<sconklin> Like wireless, it would take someone following upstream, syncing bugs, etc.
<rtg> sconklin: sprint topic?
<sconklin> rtg: sure, if there are any open slots. I'd be happy to moderate
 * smb_tp_ nods
<rtg> sconklin: surely we could find an hour out of 3 days to chat about it
<sconklin> ok, I'll ask pgraner to schedule it is he can. If he can't I'll just be opportunistic about bringing it up
<sconklin> if he can
<rtg> Keybuk: Re: [PATCH 29/31] esp: Auto-load esp module when device opened. Alan Cox says "NAK - the default esp behaviour is to do unsafe ISA probes to find the ports. We don't want it autoloading therefore.". I tend to agree with him when it comes to ISA probing.
<Keybuk> sure
<Keybuk> in fact, I'm of the opinion that all of these patches should be dropped for the next ubuntu kernel if they haven't been merged upstream
<Keybuk> thus I realise they shouldn't have been "SAUCE"
<Keybuk> the whole sauce non-sauce thing confuses me a little ;)
<Keybuk> the important thing is that we had an alias to auto-load that driver
<Keybuk> we turned it into the kernel patch
<Keybuk> and someone upstream said it was wrong
<Keybuk> which means our alias was wrong too
<Keybuk> so it's fine for both to go :p
<rtg> Keybuk: OK, I'll revert at least the esp patch.
<Keybuk> I'd probably wait until karmic, unless you feel a pressing need
<Keybuk> simply on the basis that there may be people who've been testing jaunty so far and relying on it working
<Keybuk> it's less rude to break such things at the start of a release
<rtg> Keybuk: that patch has only existed for the last couple of uploads. Probing of ISA ports is a bad thing.
<Keybuk> right, but we had a modprobe.d alias before
<Keybuk> which had the exact same effect
<rtg> so, you're saying its always been loaded automagically?
<Keybuk> right
<Keybuk> I'm quite happy to drop that on Alan's word that it shouldn't be
<Keybuk> but wishy-washily-vaguely leaning towards doing that drop when we rebase for karmic rather than right before jaunty beta :p
 * JanC wonders why an extra-sensory-perception module has to do isa-probing  :P
<cj> hmm?  esp?  isa?  are you talking about ipsec?
<anubhav>  cj: ithink its http://lxr.linux.no/linux+v2.6.28.4/drivers/char/esp.c
<cj> ah, not Encapsulated Security Payload / Internet Security and Acceleration
<anubhav> johanbr: did the "up_threshold" param solve your issue?
<johanbr> anubhav: I've been pretty busy so I haven't actually tried it yet. But I'll keep it in mind next time I compile something.
<anubhav> johanbr: oh okay :)
<porq69> hi
<Lure> I am using https://wiki.ubuntu.com/KernelBugFixing to try one upstream fix, but the build in PPA fails with ABI error
<Lure> http://launchpadlibrarian.net/23761073/buildlog_ubuntu-jaunty-lpia.linux_2.6.28-9.29~lure~lp285834_FAILEDTOBUILD.txt.gz
<Lure> is something missing regarding ABI in the wiki page?
<TheMuso> Lure: You need to fetch the abi files for a previous kernel if there were any, otherwise you need to disable ABI checking.
<TheMuso> I'm guessing this is the first kernel you are building, so disabling the abi check is probably the best option.
<TheMuso> if its your ppa only
<Lure> TheMuso: how can I disable ABI check in package?
<TheMuso> Lure: probably the easiest way is to add something like "skipabi = true" and "skipmodule = true" to the top of debian/rules.d/0-common-vars.mk
<TheMuso> actually, add those two lines exactly to the top of that file, and things should be ok.
<Lure> TheMuso: thanks - will try now
<Lure> TheMuso: you are audio guy, right?
<TheMuso> Lure: yes
<Lure> TheMuso: can you comment how likely is to get quirk fix from sound-2.6.git into Jaunty - I am talking about bug 285834
<ubot3> Malone bug 285834 in alsa-driver "Audio out on x200/x200s dockingstation doesn't work" [Undecided,New] https://launchpad.net/bugs/285834
<Lure> I plan to test it first and hopefully it will work for me and other reporters...
 * TheMuso checks to see whether the commit needed is in 2.6.29
<TheMuso> Lure: it is not in 2.6.29 yet, and I don't think rtg et al like pulling commits from anywhere else but upstream, and its a rather big diff, so I am not sure if the kernel team would be comfortable merging it.
<TheMuso> Upstream here being Linus' tree.
<Lure> TheMuso: ok, will check back only if we have positive testing reports
<Lure> otherwise I may maintain custom kernel in ppa
<Lure> TheMuso: thanks a lot for you help
<TheMuso> Lure: np
<rtg> TheMuso: I just replied to email about missing commits
<rtg> to your email
<TheMuso> rtg: right
<dandel> ><; any ideas on where i can get generic 2.6.25 and 2.6.26 series of mainline in binary?
<rtg> dandel: I tarted a mainline build for 2.6.25, watch the kernel team mailling list for completion
<rtg> started*
<dandel> RTG, that's good to know... i'll be looking for it then.
#ubuntu-kernel 2009-03-12
<dandel> rtg, i see that they are ready, i'll boot those 2 kernels up asap.
<dandel> rtg, it seems that the mainline 2.6.25 kernel is unbootable for me.
<dandel> it gets stuck at boot, but is not a kernel panic ( flashing capslock key )
<JanC> they key flashes?   :P
<dandel> hmm... might be wrong on that one... either way, waited until just now to reboot after trying 2.6.25 again.
<dandel> !bug 338701
<ubot3> Factoid bug 338701 not found
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
<dandel> either way, i've limited the bug down to an acpi patch in 2.6.26.
<dandel> Ncommander, can you look over bug #338701 and tell me what else i should probably submit to that?
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
<Mez> Hey. my kernel seems to be crashing aon a t1500 celeron dual core, last message is marking tsc unstable due to tsc halts in idle
<Mez> I can get it working with "apci=ht noapic" 
<Mez> but that's exactly the best solution, seeing as it's a laptop
<Mez> any suggestions?
<aboSamoor> I filed this bug 341625 , what is the info needed ?
<ubot3> Malone bug 341625 in linux "Hard disk I/O operation freezes the system" [Undecided,New] https://launchpad.net/bugs/341625
<aboSamoor> any ideas ?
<ia> hello. I have a kernel config, which i use for compilation each new jaunty linux kernel. On previous versions (before 8.27) cpu freqency scaling works fine, but at later kernels this feature unavailable (i use asus eeepc 901). But at generic kernel scaling still works fine; so, looks like that for enabling this feature in my custom kernel i should enable some other (new?) option in config, but what exactly option? I will be very appreciate for any clues.
<ia> or, in any words, i would like to know, which exactly config option/module enables in latest kernels cpu frequency scaling feature for eee pc 901 hardware?
<amitk> ia: What processor does the eeepc have?
<ia> amitk: intel atom n270
<amitk> ia: do you need the custom config for other reasons or only for cpufreq?
<ia> amitk: for other also :-)
<amitk> ia: there were some changes made in cpufreq configs between -8.27 and the current -9. We are reviewing those changes now
<amitk> ia: what is the current governor set to?
<amitk> and the current driver to?
<amitk> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
<ia> amitk: >what is the current governor set to? // "performance" ; >scaling_driver // "acpi-cpufreq" ; and here section from my config with cpufreq related info - http://paste.ubuntu.com/130113 ; i've looked into generic config - there CONFIG_X86_ACPI_CPUFREQ have set as "Y"; so, maybe in this problem - i should try to change m to y in my config, but in my "make gconfig" configuration ACPI_CPUFREQ available only as module - y unavailable (maybe because some r
<ia> elated for y-option modules disabled)
<Mez> Question: if I put in nolapic, my system only shows 1 cpu, but i have dual core. Does this mean I'm only using one core??
<amitk> ia: could you boot with -8.27 and check the values of scaling driver and scaling governor?
<ia> amitk: well, i've just run sudo modprobe acpi-cpufreq, and scaling started working. I've added acpi-cpufreq in /etc/modules, reboot system, and frequency just works now. It's strange, that at previous versions scaling works without adding module in /etc/modules. However, sorry for worrying and thanks you very much for help :-)
<ia> amitk: and another small question about this topic - so, if system uses acpi-cpufreq module, so can i safely remove from config X86_SPEEDSTEP_* modules?
<amitk> ia: that is what is done in the -9 kernels. acpi-cpufreq is built-in (not a module) and given more precedence over SPEEDSTEP
<amitk> check commit 495f78bd6d8f7a5e35dd962031eb6e639d83e438 in the git tree
<lod_> hi, i've just noticed that there's no more /etc/modprobe.d/aliases
<lod_> in jaunty devel
<lod_> is there any replacement?
<lod_> is it safe to rename aliases.dpkg-bak to aliases.conf ?
<IntuitiveNipple> /etc/modprobe.d/arch/ ?
<lod_> no arch
<lod_> only .conf 's
<IntuitiveNipple> oh yeah - that's in the initrd :)
<lod_> i've got basic info on initrd
<lod_> no knolege to mess with it
<lod_> also another Q.
<lod_> i've noticed that upon reboot, the system only reload fresh kernel
<lod_> no BIOS or hardware reboot
<lod_> please, how to use full reboot, not only kernel reloading
<lesshaste> hi all
<kees> apw: is there a specific bug for tracking the issue you brought up here: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027366.html
<smb_tp> kees, apw won't listen today
<kees> smb_tp: ah, dang.  does anyone else know?  ogasawara maybe?
<smb_tp> kees, maybe. not sure
<ogasawara> kees: I think there exists a bug for it, lemme search around and get back to you
<kees> ogasawara: cool, thanks
<dandel> ogasawara, ya still there?
<dandel> you said you'd help a bit with describing how to do a git cross-section examination done, right... it's pertaining to bug #338701
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
<IntuitiveNipple> bug #292381
<ubot3> Malone bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,In progress] https://launchpad.net/bugs/292381
<kees> IntuitiveNipple: ah! thanks
<IntuitiveNipple> oh - was that OK? I thought you'd only just asked then after posting the link realised my IRC client had been disconnected for 1/2 hour :)
<sashimi> Hello guys. I hope my question is not to much out of scope of the topic : does the ubuntu kernel (does the vanilla kernel) have eSata hot plug capability ?
<VaSavoir> Hello, is there a place to discuss about event and so on on ubuntu, i want to catch event to detect partition changed, mount change, i already detect disk connection/deconnection, thank for your help
<lesshaste> hi
<Kano> hi, i have got a major issue with that ignore-hpa preset in -9 kernel
<Kano> my raid does not work when this is default
<Kano> on reboot without poweroff it even shows offline members
<Kano> and what is also critical: ignore_hpa=0 does not work to set the default behaviour, at least it did not for me, maybe i missed some prefix.
<Kano> please tell the users who currently need that hack to set the jumpers correctly - in many cases they are just set wrong
<Kano> with 32 gbyte limit
<Kano> and revert the change
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=0d3c04214230d4340345a7a5d5353883b3299d9f
<Kano> this is critical
#ubuntu-kernel 2009-03-13
<Kamping_Kaiser> ah goody. bug 292381 . Ill suscribe myself
<ubot3> Malone bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,In progress] https://launchpad.net/bugs/292381
<Quintasan> Can anyone tell me will the ext4 fix (scheduled to release with 2.6.30) will be backported to Ubuntu kernel?
<rtg> Quintasan: Jaunty is following stable updates wrt ext4
<Quintasan> wrt?
<rtg> Quintasan: 'with respect to'
<dandel> rtg, did the 2.6.25 kernel build mess up or something?
<dandel> it's completely unbootable on 1 of my boxes.
<rtg> dandel: I only received notification that it built. Have to tried 2.6.26 as well?
<amitk_> dandel: it is an automated build
<dandel> i have tried 2.6.25 and 2.6.26 against bug #338701
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701
<dandel> 2.6.26 and 2.6.27 both have the same error
<dandel> as for 2.6.25 i put the exact stop point up on the bug report 
<dandel> it appears that the start_secondary integration might of been what knocked out my acpi.
<rtg> amitk_: so, you don't like that VFP patch, huh?
<amitk_> amitk_: 1 down, 1 to go :)
<Quintasan> rtg: thanks
<amitk_> rtg: The remaining one has been around for over a year. I don't like applying patches that upstream might have rejected
<Kano> hi rtg 
<Kano> rtg: did you read my mail about hpa
<rtg> Kano: just working through the list. I was traveling yesterday
<Kano> rtg: could you revert the hpa change?
<Kano> i can do that for my kernel packages, but i dont want to have offline members of my raid when i test u
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=0d3c04214230d4340345a7a5d5353883b3299d9f
<Kano> revert this please
<soren> Kano: What's the problem with it?
<Kano> the problem is that i have got hds with hpa which are raid members (using dmraid)
<Kano> if hpa is unlocked it is not working. another problems war boards which store bios backup information
<Kano> at the end of a hd
<Kano> then that hd is locked by hpa and it should not be overritten
<Kano> this is known for some new gigabyte boards
<Kano> i wrote the same to the mailinglist
<Kano> that feature is called virtual dual bios
<soren> Kano: Wouldn't the same problem happen to people who are used to having hpa disabled by default, then?
<Kano> soren: dmesg|grep HPA
<Kano> no output -> no error
<soren> Eh?
<Kano> soren: most systems do not use hpa
<soren> If someone is used to having HPA disabled and have RAID members configured like that, and we suddenly don't disable it by default anymore, /they/ are going to be screwed, aren't they?
<Kano> soren: the motherboard raid seems to rely on it
<Kano> it is impossible that you have to unlock it. windows does not unlock hpa
<Kano> only 1 user even had issues from disabling hpa and that was definitely his own fault
<Kano> because he used the 32 gbit limit jumper. he did not do that by purse, i guess he just looked at the jumper picture the wrong way
<Kano> thats a very clear error then, when fdisk -l reports a 32 gb partition only
<Kano> ata2.00: HPA detected: current 66055248, native 312581808
<Kano> thats how it looks
<soren> How is it impossible that I have to unlock it? I've most certainly had systems before where the BIOS wanted me to not see parts of the hard drive and had the kernel fix that up for me.
<Kano> in dmesg
<Kano> soren: you can still force it,but do not disable hpa by default
<soren> Correct me if I'm wrong, but disabling HPA has been the default in Ubuntu for a long time, hasn't it?
<Kano> it was default for 8.04
<Kano> but not for 8.10
<rtg> soren: /etc/modprobe.d/options:options libata ignore_hpa=1
<Kano> maybe in the options, but i do not use those options
<Kano> but if that was the option, then the override would be libata.ignore_hpa=1 if somebody needs it
<soren> Kano: Well, pardon me, but how are your defaults our problem?
<rtg> Kano: so, Jaunty behavior has not changed. we removed the modprobe option and made ignore_hpa=1 the default in the module.
<Kano> rtg: it is still the wrong. the kernel default is better
<rtg> Kano: feel free to add the option to your modprobe options
<Kano> they do not matter when you statically build it
<rtg> grub is your friend
<soren> Kano: That really depends on how you define "better".
<Kano> soren: i define it less problematic. if you have got a raid and when you boot linux and then you see all are offline members, then you can get panic
<Kano> only full power off works
<soren> Kano: Yes, but if you installed your system with ignore_hpa=1 and it's suddenly =0, then you have the same problem.
<Kano> soren: only in the case that hpa was used! thats a very rare case
<soren> ...and since we've had ignore_hpa=1 for a while now, sticking with that will cause least problems for /our/ users.
<Kano> not correct
<Kano> it will force problems for NEW users
<Kano> with gigabyte boards
 * soren finds something else to do...
<soren> It's not my decision anyway.
 * Daviey wonders what LTS -> LTS upgrade will bring
<rtg> Daviey: IIRC, ignoring HPA has been the default since Feisty
<Daviey> Oh
<Daviey> < Kano> it was default for 8.04 <-- confused me 
<Kano> soren: what do you win when you unlock hpa, next time the bios writes its backup again there an then data of the last partition at the end is overwitten
<rtg> Daviey: can't tell you how we'll handle Dapper upgrades
<Kano> Daviey: it was a kernel config setting for hdX devices (legacy code), but now ide legacy is not used anymore
<johanbr> anubhav: Changing up_threshold for the ondemand governor made a big difference. Thanks!
<anubhav> johanbr:cool :)
<johanbr> For the Ubuntu kernel devs: up_threshold for the ondemand governor was set to 60 in Intrepid, but in Jaunty it's 95.
<johanbr> This makes the ondemand governor very slow to trigger. What's the reason for this change?
<anubhav>  johanbr: laptops will run much cooler i guess
<JanC> anubhav: shouldn't that be set depending on laptop vs. desktop then?
<anubhav> amitk : For the Ubuntu kernel devs: up_threshold for the ondemand governor was set to 60 in Intrepid, but in Jaunty it's 95.This makes the ondemand governor very slow to trigger. What's the reason for this change?
<anubhav> amitk: This question was asked by johanbr.Do you have any idea?
<amitk> anubhav: I am not aware of the reason for the change. Is it different from the value that upstream uses?
<rtg> amitk: it is the upstream code, but it changed a bit from Intrepid.
<mjg59> No, it's what upstream uses when you have microaccountin
<anubhav> mjg59: By upstream do you mean the kernel?
<rtg> anubhav: by upstream we mean Linus' repository
<mjg59> Yes
<anubhav> so the driver by default sets to 95?
<anubhav> let me check the code
<mjg59> MICRO_FREQUENCY_UP_THRESHOLD is the relevant define here
<anubhav> yeah got it,but in the Documentation its mentioned that 80 is default
<anubhav> http://lxr.linux.no/linux+v2.6.28.4/Documentation/cpu-freq/governors.txt
<mjg59> The documentation is out of date
<mjg59> It's 80 if you don't have support for idle microaccounting
<mjg59> Because there's less certainty about the true workload
<Unggnu> hi all
<Unggnu> How can I activate/use the Ubuntu kernel staging drivers?
<Unggnu> like the ones listed under https://lists.ubuntu.com/archives/jaunty-changes/2009-January/003537.html
<davygrvy> what are the kernel options to reserve irq 3, port range 210-21F and dma 1 ?
<davygrvy> something I'll be running in dosemu will need them
<mjg59> Simply don't bind a driver to them
<davygrvy> all that boot stuff is automatic
<mjg59> Which driver is taking them?
<davygrvy> don't know yet, I want to be prepared
<davygrvy> in the older hardware the pccard redirector took 3
<mjg59> The kernel isn't responsible for IRQ routing. If there's hardware that's decoding that irq and io port ranges then simply getting the kernel to ignore them won't make things magically work for you
<davygrvy> is there a how-to for irq, port, and dma conflicts?
<davygrvy> some stuff is programmable, though.  the pci video card could do three irqs
<mjg59> Programmable by the bios, yes
<davygrvy> well, if this bios let me in :)  but that's another story about old IBM thinkpad lame-o bios
<mjg59> What, precisely, are you trying to do?
<davygrvy> what are the kernel options to reserve irq 3, port range 210-21F and dma 1 ?
<mjg59> That's not a useful question for you to ask
<davygrvy> iow, disallow it being used
<davygrvy> why?
<mjg59> Because dosemu isn't going to pay any attention to whether or not the kernel has allocated them anyway
<mjg59> Why are you trying to prevent them being used by the kernel?
<davygrvy> because the specail ISA data aquisition card for this old DOS app uses them
<mjg59> Ok.
<mjg59> But the kernel doesn't allocate IRQs, the BIOS does. And if the BIOS gives IRQ 3 to something else then reserving it in the kernel won't help.
<davygrvy> In that respect I see, but would be nice see a nice error message telling me that
<davygrvy> I'm sorry, the port redirector for PCCards is on 3, can not continue.. or whatever
<davygrvy> what are the kernel boot options to reserve irq 3, port range 210-21F and dma 1 ?
<mjg59> You can prevent the kernel using IRQ 3 for PCI by passing irqmask=0xfff7
<davygrvy> where is that mask documented?
<mjg59> Documentation/kernel-paramaters.txt
<davygrvy> looks to be ~(0x0003)
<davygrvy> ahh
<davygrvy> that you
<davygrvy> err
<davygrvy> thank you
<davygrvy> that took alot of words to get there
<mjg59> But that doesn't reserve irq 3
<mjg59> Or the port range or dma port
<mjg59> There's the pnp_reserve_* arguments, but again those will only help if the device is being configured by pnp
<mjg59> In the general case what you're asking for is impossible
<davygrvy> armed with the boot options I expect to find success,  at least in the debugging area
<davygrvy> pci=irqmask=0xMMMM
<lesshaste> hi
#ubuntu-kernel 2009-03-14
<Kamping_Kaiser> kees, hi, if you come back before heading to bed, can you check pm?
<Kamping_Kaiser> kees, on the off chance - ping?"
<Kamping_Kaiser> shot in the dark
 * Kamping_Kaiser heads off
<stephenr82> hi guys, im having a problem with the jaunty kernel. i reckon its my config. i have my wireless drivers working fine with 8.10 but using make oldconfig with the 2.6.28 sources, im not getting them working
<aboSamoor> is alsa-kernel part of the kernel ?
<dandel> i'd report the issue in this section, if it's wrong, they'll just redirect it... https://launchpad.net/ubuntu/+source/alsa-driver
<stephenr82> could it not just be my configuration? Or should make oldconfig be guaranteed to provide the same behaviour as the old kernel
<aboSamoor> I have problem [regression] with my alsa-kernel driver. Bug 278648. Any idea to solve ?
<ubot3> Malone bug 278648 in linux-ubuntu-modules-2.6.24 "[regression]snd-hda-intel sound input does not work at all with Conexant CX20549 (Venice) chips " [Undecided,New] https://launchpad.net/bugs/278648
<calc> maybe i am missing something... does laptop mode delay sync calls?
<calc> otherwise if all these apps are supposed to be calling sync() to make sure they are in a consistent state wouldn't that essentially break laptop mode and make battery life really suck on laptops
<calc> so you could either have known consistent state of files or working laptop mode? that is what i am confused about
<dtchen> dandel: they're almost always to be filed against linux, not alsa-driver.
 * calc doesn't know if anyone has presented that line of questioning to tytso, perhaps i am misunderstanding how sync and laptop mode interact though
<dtchen> dandel: i.e., very few people actually use module-assistant with alsa-source
<dtchen> aboSamoor: it's known and being fixed
<mjg59> calc: No, it doesn't delay sync
<calc> mjg59: so then there is a real need of tracking meta data on a per file basis as was requested in the lp bug report, but that tytso indicated was hard/impossible(?) to do
<calc> if there isn't a way to delay sync then it should only be used in critical writes and not as a form of meta data barriers as tytso has previously suggested
<calc> at least in my understanding of the issue
<calc> and in fact probably should have sync calls removed from more code rather than added so that hd's can sleep longer
 * calc wonders if the sync's were at least part of the cause of the spin count issue on laptop hdds
<calc> esp with the firefox sync calls that at least used to happen
#ubuntu-kernel 2010-03-15
<dyek> Hi! I added a bunch of CONFIG_* that I thought was necessary for Xen DomU support in Ubuntu linux-image kernel package in debian.master/config/i386/config.flavour.generic file. After "debian/rules updateconfigs" and created the .deb package, much of those added CONFIG_* disappeared from the package's config-* file. Are they disappearing because I added it to the wrong flavor config file? Or are they simply not supported by the kernel source from
<dyek>  the package? I'm getting "Error: (2, 'Invalid kernel',..." when I launch the kernel as DomU. It seems to me that it is hopeless to try to recompile the Ubuntu kernel package hoping that it will fix the Xen DomU support. Does that sound correct?
<dyek> I suspect that these CONFIG_* (CONFIG_XEN, CONFIG_XEN_BLKDEV_FRONTEND, CONFIG_XEN_NETDEV_FRONTEND, CONFIG_XEN_KBDDEV_FRONTEND, CONFIG_HVC_XEN, CONFIG_VIRTIO_CONSOLE, CONFIG_XEN_FBDEV_FRONTEND, CONFIG_XENFS) are likely needed to enable Xen DomU support. Any comment on that? I can't seem to effectively add these CONFIG_* though. They were reset (disappeared) after creating the kernel .deb package.
<dyek> I tried that CONFIG_M586TSC and CONFIG_M686 isn't the real issue -- discussed in https://lists.ubuntu.com/archives/kernel-team/2010-February/008716.html.
<kengyu> dyek, guess the missing CONFIG_* are in debian.master/config/config.common.ubuntu
<dyek> kengyu: Thanks! Glad to know that. That makes it sounds hopeful again. So, I need to figure out why then those CONFIG don't appear in the final config-* file in the linux-image*.deb package. I have been trying to add them into the generic flavor, but I guess there are build scripts that would insist that they appear only in some flavor?
<dyek> Even the generic-pae flavor doesn't have those Xen CONFIG_* in the resulting config-* file.
<apw> dyek, if you added them to -generic only then they would not be set on generic-pae, and as i recall XEN needs M586TSC at least turned on, so xen cannot be enabled in the current generic kernel configuration, those items are incompatible with the CPU level.  if you add them to the config.common.ubuntu, and then run fakeroot debian/rules updateconfigis ... do they remain enalbed?
<dyek> apw: I added them to -generic, hopefully to get a custom -generic package that works as DomU kernel. It doesn't need to be in generic-pae if that works.
<apw> the -generic kernels cpu selection is not high enough to allow XEN to be enabled
<dyek> apw: I tried with M586TSC and also M686; they appear in the final config-* file, but the problem remains.
<dyek> apw: Is there a way to change that?
<apw> can you pastebin the fragment of options you are trying to set
<dyek> apw: For my local package, that is.
<apw> so i can see the exact options you are trying to enable
<dyek> apw: But they are not in the final config-* file, or are they, in your case?
<apw> dyek, without knowing exactly what you are setting i have no idea, if you pastebin the enable fragment you are adding then i can try and reproduce
<dyek> apw: I added a bunch of CONFIG_, mostly listed here: CONFIG_M686, CONFIG_HAVE_INTEL_TXT, CONFIG_XEN, CONFIG_XEN_SAVE_RESTORE, CONFIG_XEN_BLKDEV_FRONTEND, CONFIG_XEN_NETDEV_FRONTEND, CONFIG_XEN_KBDDEV_FRONTEND, CONFIG_HVC_XEN, CONFIG_VIRTIO_CONSOLE, CONFIG_XEN_FBDEV_FRONTEND, CONFIG_XENFS, CONFIG_XEN_COMPAT_XENFS, CONFIG_X86_CMPXCHG64, CONFIG_X86_MINIMUM_CPU_FAMILY=5, CONFIG_X86_PAE, CONFIG_IEEE802154_FAKEHARD, CONFIG_XEN_BALLOON, CONFIG_XEN_DEV_
<dyek> EVTCHN.
<dyek> I'll pastebin.
<dyek> apw: Here you go: http://pastebin.ca/1841032 ; Note that I am only experimenting with these CONFIG_* hoping to get a Ubuntu kernel running as DomU kernel. I have no idea if these constitute a fix for the problem. Thanks for working on reproing it!
<apw> dyek, as the -pae kernel does have xen enabled, have you tried just using that kernel?
<dyek> apw: Yes, I tried. No -pae kernel worked. The latest version I tried was released on Feb. 8th, 2010. Did someone find the -pae kernel working as DomU?
<apw> dyek, the fixes to enable that in lucid was only commited on the 9th feb
<dyek> apw: I didn't find other newer packages. So, I ended up adding CONFIG_* and built it myself, which didn't work too...
<dyek> apw: I was trying out lucid kernel for karmic, but a lot of dependencies are getting in the way.
<apw> dependancies on binutils?
<dyek> Yes. I tried upgrading binutils, but it didn't work for me. (vaguely...)
<apw> smb, do we not expect XEN domU to work in karmic PAE kernels?
<apw> dyek, the depenancy there will go away again after the freeze, iit is triggeed by an inbuilt binary which we are pulling out
<smb> apw, I think we would for uploads containing the changes to the m586 option.
<dyek> apw: OK!
<smb> I am not sure this in now or will be in the next upload to proposed
<apw> smb, yeah not sure either, may well still be pending
<smb> apw, dyek Its still pending
<dyek> apw, smb: However, I did make a local build off the linux-image source package after adding just CONFIG_M586TSC=y. The CONFIG was added successfully, but that didn't do the magic for me.
<apw> smb, is there a pre-proposed kernel up which has it in
<smb> Yes
<apw> dyek, that change was made against -pae which has other otptions changed ...
<smb> Should be in what is currently in the pre-proposed PPA of kernel-ppa
<apw> dyek, i would recommend testing the pae kernel from the pre-proposed PPA, and see if that works
<apw> thtat is expected to have Xen support enabled for domU use
<dyek> Is there a link to a pre-release package that I can try?
<smb> https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<smb> dyek, ^
<apw> smb, are we intending to keep all of the series up to date in there?
<smb> apw, Yes, more or less. But usually its the latest that has the worst backlog
<JFo> apw, thank you for weighing in on that vserver issue. That is precisely what I thought. :)
<apw> its a humongous patch set, you might well want to close it Won't Fix
<dyek> smb: Thanks! I'll give this package a try: https://launchpad.net/~kernel-ppa/+archive/pre-proposed/+build/1525835/+files/linux-image-2.6.31-21-generic-pae_2.6.31-21.58~pre1_i386.deb
<smb> dyek, Ok. Yes, that should include the change.
<JFo> apw, will do
<dyek> This package's config- file does look much hopeful...
<dyek> apw, smb: The -pae kernel worked as DomU! I can login to VNC desktop successfully. The mouse cursor is not at the right coords., but at least, DomU is working! Thanks so much.
<apw> amitk, so i see you handed some of your stuff over to cnd, which things went there
<amitk> apw: the 'porting' of laptop-mode-tools script to pm-utils
<amitk> everything else should be postponed
<apw> amitk, is the 'investigate the ones in l-m-t' one now complete?  as you were at the getting patches working and reviewed i assume so?
<amitk> apw: correct
<apw> amitk, but that is the one which has been pushed out to beta-2 and the 'implement' one is postponed to M
 * apw looks a little confused
<apw> amitk, any idea what cnd has been asked to do there?
<amitk> apw: pgraner was talking to cjwatson about the tasks. I am distracted by another phone call on Friday
<amitk> apw: cnd should be fixing the 'implementation'
<amitk> s/am/was
<apw> ok will get with them and sort out whats really left
<apw> amitk, what did we decide to do about SECCOMP on arm ?
<amitk> apw: we decided to fix it, I have a patch, need to free up some time to test
<apw> ok ... so when do we think we might have that?  sometime after freeze i assume
<amitk> apw: it didn't seem like a burning priority, so yes
<apw> amitk, works for me thanks
<tgardner> apw, can't parse some of this commit log, "This patch adds the kernel EXTRAVERSION to /proc/version_signature and though that also to the kernel version banner."
<apw> the kernel version banner includes the same output as /proc/version_signature, its in () at the right end
<apw> dmesg | grep Linux\ version
<tgardner> apw, I get the patch, I just don't get your commit log line.
<_ruben> s/though/through/ probably? :)
<apw> ahh yeah what _ruben says
<apw> text and i do not mix well
<_ruben> hehe
<tgardner> apw, ah, perhaps you could correct that before committing?
<apw> tgardner, yeah a good plan
<apw> fixed in my tree
<tgardner> apw, thats, I'll uncross my eyes now :)
<tgardner> thanks*
<tgardner> can't damn type this morning
<apw> neither can i apparently :)
<cnd> amitk: if we remove the echo into /dev/dsp in ac97-powerdown, will the script stlil work right?
<cnd> will the sound card power down now, or wait until the next audio bits are pushed?
<amitk> cnd: it'll wait until the next audio bits is my guess, but i don't have the HW to be sure.
<cnd> amitk: so why are we removing it? just cause it looks bad?
<cnd> amitk: is there a thread of comments somewhere so I can figure out how some of these decisions were made?
<amitk> we don't even know if the echo works, e.g. on my machine it says the device is busy
<cnd> oh, ok
<amitk> cnd: most of the are adaptations for the laptop-mode-tools scripts
<amitk> have a look at the source of that package
<cnd> amitk: so I see where you took your scripts from, but where are these comments to change the scripts coming from
<amitk> cnd: what comments?
<cnd> amitk: the comments you sent me in the email
<cnd> the list of things you think should be changed
<amitk> cnd: my own comments for the sched-mc/mt scripts
<amitk> cnd: ohh, that
<amitk> we reviewed them on IRC
<cnd> who's "we"?
<amitk> pitti and me
<amitk> I
<cnd> ok, so basically I should be interfacing with pitti about any issues?
<amitk> cnd: what are those issues?
<cnd> for example, the ac97 powerdown, I think we should still be trying to push a few bits to enable it, since that's what laptop-mode-tools does
<cnd> but it pipes stderr to /dev/null, so you don't get any warnings
<cnd> so I figured we'd do the same
<amitk> cnd: have you tried writing to /dev/dsp on your machine?
<cnd> I just did
<cnd> it seemed fine, though it output a little blip
<apw> cnd, echo "" >/dev/dsp works here, and comes with a click ... echo -n is silent 
<amitk> cnd: then leave it in there but find a way to log failures IMO
<cnd> amitk: this is the comment from laptop-mode-tools:
<cnd>                         # This can fail if the audio device is busy.
<cnd>                         # Since this failure is non-fatal (worst case is that the timer changes
<cnd>                         # don't get activated), we don't bother if it was successful or not
<cnd>                         #(exec 2>/dev/null; echo 1 > /dev/dsp;)
<cnd>                         # Better way
<cnd> so I don't think we need to log anything
<cnd> apw, echo -n "" > /dev/dsp gave me issues
<cnd> nm
<cnd> seems to work now
<amitk> cnd: so the change might be enabled or not?
<apw> may not work of course if it sends nothing
<cnd> apw, yeah, I'm going to look into that
<cnd> amitk: it should work, unless someone else is holding onto /dev/dsp, in which case they will likely take care of it anyways
<amitk> cnd: ok
<crimsun> wow, that's crufty
<crimsun> (laptop-mode-tools)
<cnd> amitk: have to done any tests to see if you can change hda power_save at runtime and have it take effect?
<cnd> the driver code looks like it only takes effect on device probing
<cnd> so it wouldn't have any effect unless you reloaded the driver with the new value
<amitk> cnd: it does work at run-time, crimsun should be able to help with HDA power save
<cnd> oh, I think I just found where it would change it at runtime
<crimsun> cnd: no, you can echo 1 > /sys/class/sound/hwCfoo/reconfig
<amitk> he did the patch for HDA audio
<cnd> crimsun: now that I look further, I'm confused
<crimsun> cnd: granted, the same caveat as with ac97; no processes can have /dev/{dsp,snd/*,seq,...} open
<cnd> crimsun: so we have to echo 1 > .../power_save
<cnd> then we have to echo 1 > .../reconfig?
<crimsun> cnd: it depends on the driver's current config
<cnd> crimsun: true, but if it had power_save disabled before, the reconfig would be necessary?
<crimsun> cnd: presuming you meant power_save_controller -> N before, yes
<cnd> crimsun: I'm meaning just power_save for now
<cnd> crimsun: can you explain the difference between power_save and power_save_controller?
<crimsun> cnd: if power_save_controller == N, then to effect changes you need to echo into reconfig
<crimsun> cnd: if power_save_controller == Y, then you don't need any echo into reconfig
<crimsun> cnd: sure, power_save is the idle timeout in seconds; power_save_controller affects whether the controller is reset coming out of power_save
<crimsun> note that you can generally get away with not doing a reconfig, but it can be iffy
<cnd> crimsun: so if power_save == 0, then the chip is never powered down right?
<crimsun> cnd: correct
<cnd> crimsun: ok, then my question is: how is a power_save change handled in the driver
<cnd> I see power_save set for the chip in azx_max_codecs
<cnd> which is called from the device probe functions
<cnd> so if I change power_save through a sysctl, how does that have any effect?
<cnd> crimsun: I think I see where I was getting confused
<cnd> crimsun: so, if you change power_save through a sysctl, do you need to push some bits through /dev/dsp to enable the change, like is done in laptop-mode-tools?
<crimsun> cnd: a reconfig will work; pushing bits through /dev/dsp should work, too
<cnd> crimsun: which makes the most sense to you: echo 1 > /dev/dsp or echo 1 > .../reconfig?
<crimsun> cnd: presuming nothing in userspace is still active in /dev/{dsp,snd/*,seq,...}, the former
<cnd> crimsun: we can't guarantee that though, so does it change your answer?
<crimsun> cnd: no
<cnd> k, thanks
 * BenC bids good morning to everyone
<amitk> morning BenC 
<smb> BenC, morning
<apw> moin BenC 
<manjo> apw, no regression call today ? 
<tgardner> pgraner, I have not checked in the past two weeks, but prior to that plymouth was the culprit on nVidia.
<apw> akgraner, you have 25 hangs a day i hear, is there a bug number?
<pgraner> tgardner: this happens on akgraner's m1330, just random freeze mouse works ut nothing else
<akgraner> apw, nope
<pgraner> akgraner: ubuntu-bug linux
<akgraner> apw, I try to file a bug through apport and it tells me I can't because I am not up to date grrrrr
<apw> akgraner, does it tend to occur when you arn't using it activly
<apw> akgraner, i know same happens to me all the time
<akgraner> apw -it happens when I am using multiple applications launched by the messaging indicator/notifier (what ever you call the envelope) 
<apw> akgraner, one thing to try would be to try booting with i915.powersave=0 ... have heard rumors that issues still occur with other i915 chipsets, and i'd guess the m1330 would fall into that category
<apw> idle here would be a few seconds at most, so you might not 'be' idle per-see
<akgraner> apw, hmm I'll pay closer attention, and make some detailed notes for ya if that will help?
<apw> well if its 25 times a day we should know in less than a coupld of hours if the option helps, that'd be my first test
<Sarvatt> what's the right way to force firmware into the initrd? some people want to try using the blob ctxprogs firmware for nouveau instead of the runtime generated ones that could be causing issues using the ctxfw module option but its not getting packed into the initrd because the module doesn't say it needs it
<pgraner> cking: are you running lucid on your HP mini?
<cking> pgraner, yes, but not used it for 5+ weeks now
<pgraner> cking: Check your dmesg and see if the sky2 has this: sky2 0000:02:00.0: unsupported chip type 0xff
<cking> will do
<pgraner> cking: if so we should kick apw....
<tgardner> pgraner, just send it to Hemminger with instructions to 'plsfx"
<pgraner> tgardner: it was working a few weeks ago, we regressed in one of the stable updates /methinks
<tgardner> pgraner, do you have version boundaries?
 * cking goes into the loft to get the machine
<pgraner> tgardner: nope, I don't use it that often, I used it to do a rsync off my server about 3 weeks ago and it worked fine. But it did work
<tgardner> ok, about -15 perhaps
<pgraner> tgardner: the whole snippet is:
<pgraner> [  204.826365] sky2 driver version 1.25
<pgraner> [  204.826456] sky2 0000:02:00.0: enabling device (0000 -> 0003)
<pgraner> [  204.826482] sky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
<pgraner> [  204.826516] sky2 0000:02:00.0: setting latency timer to 64
<pgraner> [  204.826651] sky2 0000:02:00.0: unsupported chip type 0xff
<pgraner> [  204.826687] sky2 0000:02:00.0: PCI INT A disabled
<pgraner> [  204.826712] sky2: probe of 0000:02:00.0 failed with error -95
<tgardner> pgraner, lucid, right? 2.6.32-13.18 - 'sky2: Fix oops in sky2_xmit_frame() after TX timeout' was the last change
<pgraner> tgardner: yep
<pgraner> nice apport won't let me file a bug... "Can't connect to the crash database, please check you internet connection"
<tgardner> pgraner, hmm, thats early, early init and brain dead simple. Have you checked that it didn't get turned off in the BIOS?
<pgraner> tgardner: I'll look.
<pgraner> tgardner: should rfkill show me all the devices in my system? bt, wifi & wired?
<pgraner> i.e. rfkill list all?
<tgardner> just rfkill list IIRC
<pgraner> pgraner@zorak:~$ rfkill list
<pgraner> 1: hci0: Bluetooth
<pgraner> 	Soft blocked: no
<pgraner> 	Hard blocked: no
<pgraner> tgardner: I'm not seeing wifi (its working cuz I'm using the box for irc to type this)
<pgraner> tgardner: and not seeing wired
<tgardner> pgraner, wl ?
<tgardner> pgraner, the driver has to register with rfkill before its displayed as an rfkillable device.
<mjg59> pgraner: Try loading hp-wmi
<pgraner> mjg59: that did it now I get hp-wifi & whp-bluetooth & hci0 but no wired 
<mjg59> Oh, right. This is an hp mini?
<mjg59> They do something odd in the bios where if you boot without ethernet connected, it powers down the phy
<mjg59> And then you get to read lots of 0xff rather than data
<pgraner> mjg59: nice
<tgardner> mjg59, thats a sky2 ?
<mjg59> rfkill doesn't cover wired, so that won't help (and hp's bios interface doesn't give you access to wired state as far as I know)
<akgraner> apw, ok I just rebooted in i915.powersave=0  what do you want me note if it happens again?
<apw> akgraner, yeah ... intrested to know if that is the trigger
 * cking starts installing - back in a while
<manjo> JFo, apw, how do I get to the arsenal scripts?
<manjo> is there a wiki some place ? 
<manjo> apw, https://launchpad.net/~arsenal-devel is that the same ? 
<apw> manjo, no, its a branch under canonical-kernel-team i think
<ogasawara> manjo: https://code.edge.launchpad.net/~canonical-kernel-team/arsenal/kernel
<JFo> manjo, https://code.edge.launchpad.net/~canonical-kernel-team/arsenal/kernel
<JFo> dang
<ogasawara> I win :)
<JFo> just missed it ;)
 * manjo uses ogasawara 's link 
 * JFo gives ogasawara more cake
<JFo> dude, I am totally ordering a cake for your birthday ;)
<JFo> heh
 * manjo has a cake in his fridge 
<JFo> <-jealous
<manjo> bzr is freaking slow !
<manjo> JFo, should I do as the README says ? ie install those dependencies ? 
 * JFo doesn't remember the readme
 * JFo goes to look
<manjo> JFo, how do I start running these scripts ? 
<JFo> dunno what you mean manjo 
<JFo> ./<scriptname> [-r (if this is to be a realtime and not dryrun)] <package to run against>
<manjo> JFo, I bzred the source for arsenal scripts... the readme says I need to resolve some dependencies ... I installed the packages
<manjo> for dependency 1. launchpadlib there are no instructions
<JFo> manjo, if you are only running the scripts in contrib/linux/ then you don't need the dependencies
<manjo> ah ic 
<JFo> well, you need that one
<JFo> launchpadlib I mean
<JFo> but not the others I think
<JFo> manjo, I've never gotten launchpadlib to successfully work on this machine
<JFo> so I have been using cranberry (which is a qa machine)
<JFo> I don't know lplib is installed on any others
<manjo> JFo, what I want to do is triage all the latest suspend/resume bugs
<JFo> manjo, I'm already doing that for all bugs
<JFo> unless I miss your point
<manjo> JFo, oh coz I have an item on my blueprint where I said ... I will look at the latest suspend/resume bugs and close/respond etc 
<JFo> I see
<JFo> well, these run against all bugs currently
<manjo> JFo, https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-suspend-resume
<JFo> so I am triaging, but not specific to any issue
<JFo> right
<manjo> ok
<manjo> JFo, [manjo] Review current filed bugs for general trends:INPROGRESS
<JFo> so if they are old, I am asking for updated testing etc.
<manjo> JFo, what I do is get a list of the bugs searching lp, then I have some scripts that will extract the attachments etc and do some processing .... but I thought arsenal was a better way .. coz you are using it 
<manjo> but now looks like it is a little more complicated than my simple shell scrips...
<manjo> JFo, I want to look for patterns in the bugs
<JFo> yeah, I am not currently doing any of that
<JFo> they are a bit intense
<JFo> :)
<manjo> JFo, don't know if bjf 's webpage does that or not 
<JFo> I doubt it does manjo 
<JFo> but string parsing and pattern match is something that I am keen to add to some scripts
<JFo> mainly for duplicate detection
<manjo> JFo, so using the script I downloaded if I wanted to a listing of the latest 100 suspend resume bugs what should I do ? 
<JFo> what script?
<manjo> aresnal
<JFo> I actually don't know 
<manjo> :)
<manjo> ok
<JFo> I have only used the stuff we have in contrib/linux so far
<JFo> so that I can work against all of our package bugs
<JFo> but I suspect it is a 'roll your own' type of framework given what I have seen
<JFo> and how we have used it in the scripts I have been adjusting
<manjo> k. which obviously needs python knowledge 
<JFo> yep
<bjf> manjo, what types of string matching are you trying to do, are you searching titles or attachments (or both)?
<manjo> bjf, attachments
<bjf> manjo, which attachments specifically?
<cking> pgraner, my sky driver2 is working fine on my HP mini with today's daily ISO:
<cking> [    1.339845] sky2 driver version 1.25
<cking> [    1.340044] sky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
<cking> [    1.340112] sky2 0000:02:00.0: setting latency timer to 64
<cking> [    1.340252] sky2 0000:02:00.0: Yukon-2 FE+ chip revision 0
<cking> [    1.340882]   alloc irq_desc for 26 on node -1
<cking> [    1.340890]   alloc kstat_irqs on node -1
<cking> [    1.340976] sky2 0000:02:00.0: irq 26 for MSI/MSI-X
<cking> [    1.343348] sky2 eth0: addr 00:24:81:3a:e0:7a
<cking> even works when cable is plugged in after a boot - which seems to be a fix
<cking> (and unplug does not panic the kernel now either)
<apw> cking, hmmm not sure i am expecting that to be fixed really, but yay if it is
<cking> apw, cannot argue with my results - it's always been dodgy until I just tried it with today's ISO image
 * cking wonders why pgraner is having issues with the same H/W
<apw> cking, yeah not quite sure how its better tho.  new firmware perhaps
<cking> apw, is the "unsupported chip type 0xff" message from pgraner's machine due to a H/W fail or difference in firmware? It's hard to tell
<mjg59> cking: That's from the chip being powered down
<crimsun> apw: procedural question: should I submit a request-pull to kernel-team@ if the upstream maintainer has Acked a patch to stable@kernel? (The patch in question most probably will be in 2.6.32.11; http://kernel.ubuntu.com/git?p=dtchen/ubuntu-lucid.git;a=commitdiff;h=329fdbbd27cf3cff4a27b436b57637dd2e5417e4)
<apw> if it can wait until .11 releases we'll get it naturally from there, if its a bit of blocker we can apply it as a pre-stable patch if we know its going there
<cking> mjg59, that's a useful insight - so what's doing that?
<mjg59> cking: The bios does it depending on the initial cable state, iirc
<crimsun> apw: well, it's quite low importance (no audio without a snd-hda-intel option), so I suppose it's best to wait. Cheers.
<apw> crimsun, cool.  if it was a very common platform we might want to tkae it
<cking> mjg59, i would have agreed with that diagnosis, however, I've powered of the hpmini, removed the ethernet cable, removed the battery, put power back in, powered up and the driver detects OK
<crimsun> bjf: is it ok to add a tag to your set of triaging ("lpib")? It would normally be attached to stuttering HDA.
<cking> apw, 'tis a mystery
<apw> cking, yeah ... working is so good
<bjf> crimsun, yes
<crimsun> bjf: cheers
#ubuntu-kernel 2010-03-16
<bgamari> Does anyone know where the sata-sil24 driver can be found in the Karmic kernels?
<bgamari> I can only find it in the -ec2 kernel
<BenC> good morning
<smb> Good morning BenC 
<Q-FUNK> howdy!  could someone tell me what was the URL to Ubuntu packages of vanilla kernels?
<tgardner> Q-FUNK, http://kernel.ubuntu.com/~kernel-ppa/mainline/
<Q-FUNK> tgardner: thanks!
<apw> bouncy tgardner 
<tgardner> apw, at least mine rebooted OK
<apw> maybe that is why keybuk is missing, he can't boot
<smb> This time it rebooted as well
<apw> smb, hrm ... not another race
<tgardner> I should go back and retry the Tylersburg with bind mounts. Its pretty much guaranteed to hang.
<smb> apw, Gah, and it would be nice if this would not always put sda6 into mtab when I am on sda8
<apw> hrm
<amitk> ericm_: wrong list
<smb> apw, Ok, at least that strangeness is solved. It does not matter what uuid you have in fstab for root as long as the grub line is correct. But mtab will get confusing if you do
<smb> apw, Bringing up gfx seems to be racy. With plymouth it seems to get stuck at some point. Without I sometimes get text login and sometimes it wors
<smb> works
<smb> Hm, seems to be having the "enter" drop to gdm problem
<smb> apw, Are you aware of issues like "after suspend-resume, screen on i915 may go completely blank at random times"
<apw> smb, is this something you are seeing?
<apw> smb, does suspend/resume fix it
<smb> apw, or not seeing my contents, yes
<apw> smb is this an older i915 chipset ?
<smb> apw, Let me try after the upgrade I do over ssh is done
<smb> apw, likely
<apw> if all the above are yes ... then reboot with i915.powersave=0 and let me know if that fixes it
<smb> apw, Its the Aspire one
<smb> apw, Ack
<apw> akgraner is meant to be reporting back today as she was seeing randomness too and was trying powersave off for older kit ... ak ?
<smb> apw, I usually get a screen goes crazy for a few seconds warning slightly before
<apw> smb seen the same on my atom as well, think older less featureful i915 still needs powersave
<akgraner> apw, hey- yeah I need to figure out who to right it up? :-(  without using words like the "thingy" the "watchchacallit" and such :-)
<akgraner> s/who/how :-)
<apw> Sarvatt, you were mentioning this i915.powersave=0 requirement for older i915
<akgraner> but it only locked up once and I think it has to do with the mouse
<apw> Sarvatt, i think i was hoping for a bug from you with the 'whihc ones are still afected' boundary
<apw> akgraner, well thats a vast improvement over 25 times in a day ... so i think you qualify as fixed for the original bug with powersave=0
 * apw will hastle Sarvatt to find out if they know the split
<smb> apw, Is 945GME considered old?
<akgraner> apw - I am happy and it wasn't so locked up that I had to reboot that time
<apw> smb, i don't think its old in terms of age but older in terms of technology, lile 965 and newer powersave works and 945 and older does not ... but i don't have the exact boundary to add the switch
<apw> will hastle graphicy people to find out
<akgraner> apw, this is one time I am going to sit down with pgraner and reproduce this problem had seek some help  from him on documenting this for you
<apw> akgraner, the powersave one?
<smb> apw, Ok, and I test here. Powersaving sounds quite reasonable. It seems to put contents up. Though backlight is still on (and gets affected by inactivity and typing)
<smb> I mean to put no contents up
<akgraner> apw, yep - I don't know how to file bugs without using apport and well it didn't work for this particular problem
<apw> smb, powersave at that level doesn't do anything visible, it down and up clocks the output dacs on activity in the framebuffer
<apw> akgraner, just find the +filebug link and file it manually
<apw> just say "i915: graphics hangs with i915.powersave=1 on some cards"
<smb> apw, Well powering down all clocks _is_ somewhat visible
<apw> and let me know the number
<tgardner> akgraner, http://bugs.launchpad.net/ubuntu/+filebug
<apw> smb, its not meant to turn them all off
<akgraner> tgardner, thanks :-)
<akgraner> apw, I'll do this now :-)
<smb> apw, If that helps anybody:
<smb> Interrupt enable:    00028c53
<smb> Interrupt identity:  00000000
<smb> Interrupt mask:      fffd73ae
<smb> Pipe A stat:         00000000
<smb> Pipe B stat:         80000302
<smb> Interrupts received: 1009
<smb> Current sequence:    3186277
<smb> Waiter sequence:     0
<smb> IRQ sequence:        3186019
<apw> smb, if it stays like that thats a gpu hang
<smb> apw, It does
<apw> specifically the current and irq sequence numbers
<apw> then we need to get a GPU hang dump off it
<apw> and a bug, blah blah blah
<smb> I think waiter sequence 0 is not very good at all. Let me collect and if powersave fixes it put it there
<apw> smb ta
<akgraner> apw, I think I did this right :-)  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539609
<ubot3> Malone bug 539609 in linux "i915.powersave causes desk top to hang." [Undecided,New] 
<BenC> I wonder if powersave is what is killing my d420
<akgraner> tgardner, the link you gave me redirects to this page - https://help.ubuntu.com/community/ReportingBugs - didn't know if you knew that  or not  :-) 
<BenC> [35198.621213] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
<BenC> [35198.621232] render error detected, EIR: 0x00000000
<JFo> what link was it akgraner?
<BenC> akgraner: do you get that in your kernel log at all?
<tgardner> akgraner, hmm, it doesn't do that for me. the Launchpad folks are making it really tough to submit a bug that doesn't conform to one of their categories
<akgraner> apw - for the can you reproduce this bug" - I put no, b/c the was no maybe button however I think I can.
<akgraner> JFo, http://bugs.launchpad.net/ubuntu/+filebug
<apw> akgraner, s'ok in this case as i know what the bug is and how to fix it, just need input from X on which cards are affected
<JFo> heh, no maybe button... you kill me
<akgraner> BenC, is there a GUI for getting to the kernel log?
<BenC> akgraner: I just did "dmesg" from a terminal
<BenC> akgraner: also, /var/log/kern.log
<akgraner> BenC, not I don't seem to have that message
<akgraner> s/not/nope
<smb> BenC, For what its worth, I got that neither
<akgraner> JFo, well I think there should be a "maybe" and a "several times a day" button :-)
<JFo> heh
<akgraner> JFo, but seeing as how I am just now learning how to file bugs - it might just be me :-)
<BenC> smb, akgraner: Ok, guess I have a diff problem, but I'm going to test the powersave disable anyway :)
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<BenC> right now I've left it in low graphics mode and haven't had a lockup or resume failure in a few days
<manjo> apw did you do an upgrade on your 10v today? 
<apw> manjo, nope ... always risky around now
<apw> problems?
<manjo> apw, after I upgrade and reboot I just got the logo spinning and no progress...
<apw> smb, sound like your issue?
<manjo> apw, looks like my root was mounted readonly and I had a ton of uread ahead messages 
<smb> Yeah could be
<manjo> my 10v has ssd 
<smb> manjo, Does pressing "s" help?
<manjo> smb, trying again 
<manjo> now its searching for disk errors ... I will let it complete .. 
 * BenC plays the wait-and-see game now
<manjo> hmmm disk check is taking for ever at 73% 
<apw> heh BenC do what i am doing, wait till smb et al stop whining :)
<apw> ok missive on built-in modules on the kernel-team list ...
<apw> ok missive on built-in modules on the kernel-team list ...
 * tgardner suspects apw is mumbling to himself out load again.
<smb> apw, ?
<cking> won't be the first time either
<smb> cking, tgardner Guess he wanted to draw some attention to some mail
<BenC> hehe
<manjo> apw, how come we are reviewing this now ? 
<smb> apw, Keybuk Seems there is something still not quite right with plymouth. I get see the splash screen turn to one with the 4 dots lightened and then have a crash report for plymouthd and a daemon I cannot kill together with X running. I was able to kill X, this caused the plymouthd to end and gdm to start
<smb> At that point in time I could ssh in, but mouse and keyboard locally were not responding
<Keybuk> smb: got the crash report?
<Keybuk> a segfault of plymouth tends to be quite catastrophic thanks to this bit of the kernel being written by spastics
<smb> Keybuk, Its still there
<Keybuk> "it" ?
<smb> Keybuk, Uploading, just a sec
<smb> Keybuk, It is bug 539655
<ubot3> Malone bug 539655 in plymouth "Boot screen locks up while X starts" [Undecided,New] https://launchpad.net/bugs/539655
<Keybuk> you see all four dots fill?
<Keybuk> does it jump to all four dots?
<smb> Keybuk, yes
<Keybuk> ok
<Keybuk> that means X should be starting
<smb> Keybuk, It was running
<smb> Just not displayed
<Keybuk> you said there was a segfault?
<smb> Keybuk, maybe not correctly stated. I meant the report in /var/crash
<Keybuk> that's unrelated
<Keybuk> you're on Ubuntu not Kubuntu right?
<smb> Right
<smb> When I logged in plymouthd was in state D
<Keybuk> But ssh login works and shows a plymoutd process (in state D), the call to stop it and an X process running.
<Keybuk> ..
<Keybuk> could you attach this "ps" output to the bug
<Keybuk> also I don't suppose you could gdb attach to plymouthd and get a backtrace?
<smb> Let me try whether it gets into the same state again.
<smb> Those things tend to go away when one looks too close
<smb> Grr, disk check
<smb> Hm, seems the similar fate.
<smb> Goes to 70% and then there is a flicker
<smb> Then it comes back with 70% but stops moving
<smb> Keybuk, Hm, not using gdb too often... How would I break to a gdb command line after attaching to the process
<Keybuk> does it not break?
<Keybuk> ooh, kernel bug
<Keybuk> strace instead of gdb?
<smb> No it just tells me attached to process x and stays there
<manjo> Keybuk, I see the same issue 
<smb> I don't think it will show much as it seems to be stuck
<Keybuk> yikes
<Keybuk> right, it's stuck in a syscall
<Keybuk> which syscall?
<manjo> init: plymouth main process (318) killed by SEGV signal 
<Keybuk> manjo: can you get that segfault?
<manjo> Keybuk, trying ... I tried to switch VT and it seems to be frozen ... restarting 
<Keybuk> yes, you'll need to ssh in etc
<manjo> s**t looks like I messed up my filesyste ... now I cannot seem to mount my / 
<Keybuk> manjo: I've done that about twice a day for the last two weeks :p
<smb> Keybuk, strace seems to lockup too, but maybe /proc/x/wchan = nouveau_gem_ioctl_cpu_fini helps?
<manjo> Keybuk, how did you manage to fix ? I don't seem to be able to fsck it ... tried init=/bin/bash and fsck but does not fix 
<BenC> Xorg restarting randomly is a painful experience
<Keybuk> manjo: oh, I just blast and reinstall the machines
<manjo> heh!
<Keybuk> smb: oh, yes, that helps :D
<Keybuk> smb: that helps a lot
<smb> Keybuk, Likely you can now point at the kernel :-P
<Keybuk> oh yes
<Keybuk> that's a card hang
<Keybuk> iirc
<Keybuk> it's waiting for a command response from the gpu I think
<smb> Keybuk, Well not completely
<smb> As I can kill -9 X and then everything works
<Keybuk> yeah it's X that's hanging here not plymouth afaict
<Keybuk> if you see all four dots, plymouth is gone
<Keybuk> well, other than waiting to close the drm connection once X has it
<Keybuk> if X hangs, plymouth will just be waiting for X to go
<smb> Seems plymouthd waits for some final drm response while X already started up somewhat but the screen rendered is the plymouth screen and keys seem to go not to X as well
<Keybuk> no, not that I know of
<Keybuk> plymouth is just trying to close the drm file descriptor
<Keybuk> actually
<Keybuk> sorry
<Keybuk> I'm talking crap
<Keybuk> you're on nouveau
<Keybuk> you have just one monitor right?
<smb> right
<Keybuk> so there should be no DRM involved here
<Keybuk> I'll have to check the code in a sec, but I'm pretty sure plymouth just uses the frame-buffer renderer on single-monitor nouveau
<Keybuk> plymouth doesn't really like GEM
<apw> plymouth is pretty damn picky
<smb> Keybuk, OK, and I attach the ps-ax and wchan info to the bug for completeness
<Keybuk> please
<Keybuk> apw: not really, GEM is pretty crappy to program
<Keybuk> it's harder than just writing to the frame buffer
<Keybuk> and slower
<Keybuk> so on GEM drivers, plymouth writes to the frame buffer
<Keybuk> unless you have multi-head, in which case it grudgingly deals with GEM so it can use each native resolution
<Keybuk> oh, right
<Keybuk> and there's no way to do the "leave what I just had on the screen" with GEM
<Keybuk> so you always get a black screen
<Keybuk> (that's probably half of the reason it avoids GEM actually)
<apw> ahh ... i found external screens even on intel sucked with plymouth
<apw> triggering all sorts of resolution changes
<Keybuk> huh
<Keybuk> that shouldn't be the case
<Keybuk> Intel is TTM
<Keybuk> Plymouth likes TTM
<apw> plymouth did nice things, purple on main, and black on external (with the logo)
<Keybuk> huh
<Keybuk> it's supposed to be purple on each
<apw> and then gdm got pissed off and reset the resolution and mirrored t
<Keybuk> each in their native resolution
<Keybuk> logo centered on each
<Keybuk> oh, maybe gdm sucks ;)
<apw> to both ... and then on login it switched back
<Keybuk> plymouth is doing pure DRM + FB
<Keybuk> so it's more like wayland than X
<apw> i couldn't see purple under the external screen logs
<apw> logo
<Keybuk> neat test of plymouth multi-head
<apw> Keybuk, oh i did wonder on the purple background, could it be made to stop one 'character' from each side?
<Keybuk> while running X :
<Keybuk>   sudo plymouthd; sudo plymouth --show-splash
<apw> to avoid the cursor cuttting holdes in it
<Keybuk> apw: you shouldn't see the cursor
<apw> Keybuk, that didn't work at all well
<Keybuk> apw: what version of plymouth are you running?
<apw> ii  plymouth                                          0.8.0~-12                                              graphical boot animation and logger - main p
<apw> i got both the splashes on my left monitor, at about 1/4 natural resolution
<Keybuk> eeeeeep
<Keybuk> yeah don't run that on that version of plymouth ;)
<Keybuk> right, that's what you should see - it just makes two X windows of different sizes to test that themes scale and centre properly
<Keybuk> anyway your plymouth is awy out of date
<Keybuk> you have the buggy crap plymouth
<apw> oh ok then it worked :)
<Keybuk> unfortunately, you're about to lose your X server
<Keybuk> :D
<apw> i have a plymouth thats is sufficinetly old that boot works for me
<Keybuk> no, you have the one before I fixed it all
<Keybuk> it always generally worked on intel though
<apw> i am waiting for smb to stop whining his boot doesn't work at all with your new stuff
<apw> before i install it :)
<Keybuk> from the sound of it, smb's problem is nouveau related
<smb> :-P
<Keybuk> talking of nouveau
<Keybuk> I have a laptop here with an nvidia card in it
<Keybuk> how do I install?
<apw> yep, ...
<apw> nouveau is default
<Keybuk> yes
<apw> either it works or it doesn't
<Keybuk> and I get a screen full of crap and corruption
<smb> Sounds my last ati install
<apw> noodeset help at all?
<apw> nomodeset ?
<Keybuk> how do I add that now we don't have a boot menu?
<apw> Keybuk, now you'd have to ask someone in foundations about that :)
<Keybuk> :D
<smb> There is one if you press escape
<apw> hold shift i assume?
<apw> oh hrm a different button?  most unintuitive
<Keybuk> this is on the installer - SYSLINUX :p
<apw> gurgle
<apw> beep
 * Keybuk changes the config on the USB key :p
<apw> your call could not be connected at this time
<apw> though it sounds like ESC is worth a shot, i suspect smb has been using it a lot
<smb> While doing the kvm tests, yes
<smb> The picture you see is very much _not_ intuitive
<Keybuk> does nouveau work on *anything* ?
<apw> Keybuk, and where is my x-server going?
<Keybuk> apw: well, when you get bored and run "sudo plymouth quit"
<apw> Keybuk, i have been told by bryceh yes
<Keybuk> apw: save your work first
<Keybuk> really?
<smb> Speaking of intuitivity, the [SM] on mountall is another example :-P
<Keybuk> because I have two nvidia machines
<apw> Keybuk, oh i went for killall plymouthd, seemed to work
<Keybuk> and I have never seen nouveau work :p
<Keybuk> apw: ah ;P
<Keybuk> apw: you might be lucky there
<apw> seems i was lucky :)
<smb> Keybuk, It worked before todays update
<Keybuk> smb: mountall likes pain
<apw> bryceh, hey ... where are our testing results for Nouveau
<apw> i am sure we have some around here somewhere
<Keybuk> fortunately these machines are all Dells
<Keybuk> and we don't have any kind of relationship with Dell
<apw> sadly i have nothing but intel h/w so i cannot test myself
<smb> Keybuk, And it works mostly when I disable plymouth. *grrr*
<Keybuk> and Dell would never ship an NVIDIA card or chip anyway
<Keybuk> <g>
<apw> Keybuk, i soooooo wish
<apw> need to know if nomodeset works on them if modeset does not
<apw> and if so we need to record that and blacklist them
<apw> have patches to allow blacklisting, just no list of black
<Keybuk> smb: does it work if you remove "splash" from the cmdline?
<apw> <johanbr> hmm... with the latest nouveau bits from the ppa, the boot hangs at the plymouth splash screen, just before switching to gdm
<apw> <johanbr> booting without splash works
<apw> someone else on #u-x bitching about something changing
<Keybuk> meh
<Keybuk> I really need some hardware for this
<smb> Keybuk, Yes, well mostly, sometimes X does not start, but other times it does
<Keybuk> *all* of our reported problems are nvidia now
<apw> as nouveau hasn't changes for ages... i suspect that there is something else at work here
<apw> smb, yours worked until today right?
<apw> yesterday and the day before?
<smb> Right
<apw> and the kernel has not changed
<smb> But I cannot say when my last update was
<Keybuk> until today ?!
<apw> so ... whatever it is its not the nouveau driver
<apw> smb, your logs will tell you when yo last updated before that
<apw> and see if the kernel changed in the pile
<Keybuk>  /var/log/dpkg.log ftw
<Keybuk> also see if plymouth or X changed
<smb> But at least I had either your franken kernel or -16
<Keybuk> or gdm for that metter
<smb> apw, Keybuk Seems at least linux-image-2.6.32-16.25 was installed today as well.
<apw> smb what did you have before kernel wise
<Keybuk> grep "update linux-image" /var/log/dpkg.log
<Keybuk> err
<Keybuk> grep "upgrade linux-image" /var/log/dpkg.log
<smb> That seems to be the meta package numbers...
<smb> upgrade linux-image-generic 2.6.32.15.16 2.6.32.16.17
<smb> Strangely dpkg -l tells me -15.22 was last but I am pretty sure I did apw's preview kernels there for testing
<apw> was that with the nouveau backport?
<apw> as in with LBM
<smb> Once with LBM, but also your drmbackport version in kernel
<smb> But that package were -15.21~xxx
<smb> so got replaced in between
<apw> smb, ahh yes would have
<Keybuk> so nouveau was changed today
<Keybuk> and things started breaking today? :p
<smb> Keybuk, I had the same version of nouveau before. Just as a testing kernel.
<smb> Keybuk, But to be honest, plymouth was turned of before because of the press enter to die bug on 64bit. I turned it back on as there was a problem that looked like mountall waiting for something but not telling issue
<Keybuk> *sigh*
<smb> Some days you forget where you started because every step takes you to another issue
<Keybuk> yes, I understand :-/
<Keybuk> but this is a problem we really need to fix
<Keybuk> it's a bit disheartening actually
<Keybuk> I have a large pile of hardware here
<Keybuk> and the only machines that can boot right now are the Intel ones
<Keybuk> (pure Intel)
<Keybuk> Intel with ATI graphics => won't boot
<Keybuk> Intel with NVIDIA graphics => won't boot
<Keybuk> AMD64 with NVIDIA graphics => won't boot
<Keybuk> etc.
<Keybuk> from my, admittedly limited, testing pool, I've come to the conclusion that this will be our worst release ever for hardware support
<smb> Probably we need to find out whether it needs a step back and not have splash for anything than intel helps
<Q-FUNK> karmic wasn't too good either.
<Keybuk> Q-FUNK: karmic at least works on all of the machines here
<Keybuk> smb: but it isn't just splash
<Keybuk> like this one I'm trying to install right now
<Keybuk> Dell Latitude D620
<Q-FUNK> Keybuk: not here.
<Keybuk> this is pretty much one of our bread-and-butter machines
<JFo> Keybuk, my D620 is working fine
<Keybuk> a lot of us have Dell Latitude Dx[23]0
<Keybuk> JFo: with nvidia or intel graphics?
<JFo> but then I did an upgrade
<JFo> nvidia
<Keybuk> it works with modeset?
<JFo> is is exactly as installed
<Keybuk> because all I got when trying to boot today's daily was a corrupt screen
<JFo> I have made no boot mods
<Keybuk> modeset=0 seems to work, but with the wrong resolutions
<JFo> Keybuk, let me reboot and I will let you know if today's update causes any problems
<JFo> brb... either here or on my mini
<bjf> ## 
<bjf> ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting
<bjf> ##
<JFo> Keybuk, the only issue I am seeing is that the font for the splash is not correct
<JFo> it isn't the new style
<Keybuk> font?
<JFo> yeah, the new looking ubuntu font 
<Keybuk> what font? :p
<JFo> heh
<Keybuk> could you describe the splash screen for me? <g>
<JFo> :-P
<JFo> it is purple
<JFo> <EOM>
<JFo> :)
<Keybuk> and what does it have written on it?
<JFo> Ubuntu 10.04
<Keybuk> see
<Keybuk> I knew you had mode setting disabled
<Keybuk> and I, again, adore the fact that we fooled you
<JFo> it isn't anything I myself have done then
<JFo> and it is new, because it was working before
<JFo> about 2 days ago it changed to that
<Keybuk> working before > you had an ubuntu logo before?
<JFo> yes
<JFo> and the nice new font :)
<lamont> hey, what do you know
<JFo> nice hat lamont :)
<Keybuk> JFo: sounds like someone blacklisted your card maybe?
<Keybuk> dunno
<Keybuk> but yes
<Keybuk> what you have there is just a plain text splash screen :p
<JFo> Keybuk, maybe, but it wasn't me
<JFo> came in by way of updates
<Keybuk> it only looks a bit like a real one, because I discovered how to reprogram the VGA palette so I could have purple backgrounds and orange text :p
<lamont> bjf: totally not my problem now.
<JFo> ah hah!
<Keybuk> those "."s that are animating are just printf (".") :p
<JFo> I see
<Keybuk> and that's just printf ("Ubuntu 10.04") :p
<JFo> so I wonder why it changed
<Keybuk> that, I don't know
<JFo> it looked very nice just a few days ago
<Keybuk> are you using xorg-edgers ? :p
<JFo> nope
<JFo> do I need to be?
<JFo> 01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)
<JFo> that is my card ^^
<JFo> bryceh, do you know of any blacklisting on that card? ^^
<Keybuk> that's the same one I have here
<JFo> anything that would have been added recently?
<JFo> hmmm
<Keybuk> which is unsurprising
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
 * jjohansen here
<smb> but not there
<jjohansen> hehe, thanks
<smb> Keybuk, Without splash it seems to be a 50:50 chance X comes up. If it does not I get a 
<smb> (EE) PreInit returned NULL for ""Macintosh mouse button emulation""
<Keybuk> JFo: grep -r nouveau /etc/modprobe.d
<JFo> Keybuk, sorry for the delay
<JFo> jfo@jfo-lappy:~$ grep -r nouveau /etc/modprobe.d
<JFo> /etc/modprobe.d/nvidia-graphics-drivers.conf:blacklist nouveau
<JFo> /etc/modprobe.d/nvidia-graphics-drivers.conf:blacklist lbm-nouveau
<Keybuk> so you're using nvidia-glx :p
<JFo> hmmm
 * JFo did not know that
<JFo> how can I change it back?
<Keybuk> do your windows have drop-shadows and 3D madness?
<bryceh> JFo, to my knowledge we have not blacklisted any cards.  apw can correct me
<smb> Not normally I gues
<apw> yeah i think that means he has binary drivers installed
<JFo> bryceh, I think Keybuk just showed me the way to the promised land
<bryceh> JFo, hmm you know it would probably be good for both me and you to know exactly where to look in the kernel for the list of blacklisted kms cards
<JFo> :)
<JFo> bryceh, yessir
<Keybuk> bryceh: since you're here
<bryceh> JFo oh you found it
<JFo> heh
<Keybuk> and I happen to have that exact same card
<bryceh> wait no
<Keybuk> and are having issues with it
<Keybuk> (which is how we got onto the whole thing in the first place)
<bryceh> yeah we need to find where in the kernel the blacklist lives now
<Keybuk> how would I find out why modesetting is crap
<apw> modesetting blacklist is in my tree only as all of the lists are empty
<smb> Keybuk, For that "working mostly" here. Do you think there could be a boot race on the stupid macintosh mouse emulation device?
<bryceh> Keybuk, because nVidia does not release their documentation?
<JFo> heh
<Keybuk> bryceh: no, I mean how to debug it or improve it
<Keybuk> this laptop just gets crap on the screen if modeset is on
<Keybuk> smb: can't see why - X does hotplug of input devices now
<Keybuk> you can rip out that kernel drive and plug it back later, and X will deal
<smb> Keybuk, (EE) PreInit returned NULL for ""Macintosh mouse button emulation""
<smb> Just because that is the error on failures
<bryceh> Keybuk, bug#?  Did you take a photo of the crap?
<Keybuk> smb: that's a bryce bug
<Keybuk> bryceh: I don't have a bug# - is there a different set of nouveau drivers I can try
<Keybuk> what package should I file a bug on?
<bryceh> Keybuk, xserver-xorg-video-nouveau
<bryceh> RAOF is the man with the plan for nouveau and can follow up from there
<bryceh> but general X bug rules apply...  ubuntu-bug xserver-xorg-video-nouveau, and attach a photo showing the corruption
<Keybuk> ok
<Keybuk> what about trying later drivers, is that possible?
<bryceh> if the system is frozen too, usually a gpu dump is needed but I don't know how to collect that on nouveau
<Keybuk> system seems mostly fine
<bryceh> Keybuk, well what you need is probably kernel stuff
<bryceh> Keybuk, so running mainline might make sense
<Keybuk> xorg-edgers won't help then?
<bryceh> no, it's a kms driver and so almost certainly a bug in the kernel side of things
<Keybuk> that makes sense actually
<Keybuk> since this doesn't work for plymouth either
<bryceh> I mean, I don't know exactly what the issue is, "crap" is insufficiently descriptive
<Keybuk> err, just crap
<Keybuk> whatever was at that particular memory address
<Keybuk> changes a bit if you move the mouse or try and VT switch
<Keybuk> but just crap :p
<bryceh> Keybuk, all I can think of is you must have a feces flinging monkey as a pet or something
<Keybuk> lol
<Keybuk> if said monkey threw pixels at the screen, you'd have what I see
<bryceh> another thing that can be done is to force it to use fbdev via your xorg.conf
<Keybuk> won't help
<bryceh> if that's still buggy then that points the finger more strongly at kms issues
<Keybuk> even fbcon has the same crap
<Keybuk> yeah, I suspect this is entirely kernel side
<bryceh> ok then :-)
<bryceh> yeah xorg-edgers would be of no help then
<bryceh> Keybuk, and you tested and found that the issue goes away if nouveau.modeset=0 ?
<Keybuk> so when you boot with nouveau.modeset=0, what driver gets used?
<Keybuk> yes
<bryceh> that turns off kms.  -nv would be used in this case
<Keybuk> ah right
<bryceh> or in theory it would be -nv.  It might go to -vesa.  Check Xorg.0.log
<bryceh> btw did you mention if X hung as well when getting the corruption?
<Keybuk> vesa by the looks of it
<Keybuk> hard to tell whether X is hung or not
<bryceh> oh, well if you can get a photo of the screen, it really does help.  the developers can discern where in memory the fault is happening by the style of corruption and length of lines (if any)
<Keybuk> filed bug #539730 for you
<ubot3> Malone bug 539730 in xserver-xorg-video-nouveau "Nothing useful on screen.  Dell Latitude D620.  nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]" [Undecided,New] https://launchpad.net/bugs/539730
<Keybuk> it has a photo
<bryceh> great
<manjo> ogasawara, can I use arsenal scripts to give me a list of all the suspend/resume bugs opened in the last 2 weeks ? 
<Keybuk> stupid observation
<Keybuk> but when plymouth is running, the screen is differently distored
<Keybuk> it almost looks like it might be sideways
<Keybuk> like that photo, if you imagine that the strange white bar is the top and bottom panels
<ogasawara> manjo: I don't think date based searches are available, you'd have to sort of brute force it checking the date created field
<Keybuk> when I render to the fb with plymouth, I get a blotch of white, near the left of the screen
<Keybuk> which could almost be the logo, screwed up
<manjo> ogasawara, in arsenal/kernel/contrib/ which script can I use to do that ? 
<Keybuk> maybe I'll add that photo to the bug
<smb> bryceh, Just a quick check, do these sound like you seen those before?
<smb> (EE) AIGLX error: dlopen of /usr/lib/dri/nouveau_dri.so failed (/usr/lib/dri/nouveau_dri.so: cannot open shared object file: No such file or directory)
<smb> (EE) AIGLX: reverting to software rendering
<smb> (EE) PreInit returned NULL for ""PS/2 Logitech Mouse""
<smb> (EE) PreInit returned NULL for ""Macintosh mouse button emulation""
<bryceh> smb, yeah I've seen those lots and lots
<ogasawara> manjo: but you can get a rough idea if you just search bugs tagged suspend and resume and sort by newest first
<bryceh> smb, I suspect they're innocuous.  I see them in systems that are otherwise functioning fine.
<ogasawara> manjo: you don't exactly need a launchpad lib script
<bryceh> smb, but I don't know for certain.  If they're innocuous it might make sense to suppress them to avoid confusion but I've not had time to look into it
<smb> bryceh, Hm, ok. Probably I should check the working case then. It seems I get X not starting in some cases
<bryceh> Keybuk, ok looking at the photo it sort of looks like just a modeline construction bug
<JFo> pgraner, when you get a sec, who was the Launchpad guy (Malone) that you and I talked about?
<cnd> what do I need to do to make a karmic linux deb? I've run fdr binary-generic, but it stopped after building everything (it didn't do any packaging)
<Keybuk> bryceh: but this affected fb too
<bryceh> Keybuk, I've got a nouveau kms system here with a similar problem (different result on screen - the picture cycles like vertical hold is broken)
<bryceh> Keybuk, but exactly
<bryceh> Keybuk, KMS is what constructs modelines now, so the algorithm may be buggy
<bryceh> Keybuk, when they move code into the kernel they've had a tendency to rewrite the modeline construction logic (guess it needed a cleanup or something) and it's not quite the same as with UMS
<bryceh> this is just a guess though... but we ran into a spate of these kinds of bugs with -intel
<bryceh> a common situation is typically its something like it doesn't quite grok the monitor's edid so enters a fallback logic case, which differs in the kms implementation vs the ums implementation
<ogasawara> manjo: if you're really wanting to script it, it doesn't look like arsenal/contrib/linux has any good examples for what you're wanting, better to just use the apidoc - https://launchpad.net/+apidoc/
<Keybuk> http://launchpadlibrarian.net/41045879/photo.jpg
<Keybuk> that's what plymouth gets on the screen
<JFo> wow
<JFo> that is new and exciting Keybuk 
<manjo> ogasawara, looking .. I was using LP "brute force find me latest bugs" method... thought arsenal was more sophisticated search 
<bryceh> Keybuk, interesting to see you're using -pae for the kernel...  I've seen several other bug reports from people with -pae
<smb> bryceh, Ok, the EE's are in there all the time. The only difference in non-working seems to be a "(II) NOVEAU(0): NVLeaveVT is called". And strangely I just had a "enter drops you out of X to gdm" but splash is disabled...
<bryceh> (II) NOUVEAU(0): Manufacturer: LPL  Model: e0  Serial#: 0
<bryceh> interesting, we had a number of quirks for LPL's
<bryceh> smb, NVLeaveVT sounds like it could be shutting off the vt.  Does vt switching bring it back?
<Keybuk> I can try not using PAE too if that helps
<smb> bryceh, Forgot to try that. Let me try to let it fail again
<bryceh> Keybuk, well it could help isolate if it is unique to -pae code
<bryceh> like if there were differences in the drm between the two kernels that might be useful to know
<Keybuk> sure
<Keybuk> btw, wasn't there supposed to be some kind of backports module package installed?
<bryceh> Keybuk, we ended up bagging that and just pulled all the new drm into the lucid kernel
<Keybuk> is it still called lbm-nouveau though?
<bryceh> Keybuk, which had the blogs all aflutter
<bryceh> no, afaik there should be no lbm-nouveau bits left.
<Keybuk> so I can drop those patches to support that name? ;p
<bryceh> Keybuk, check with RAOF on that
<bryceh> Keybuk, with -vesa loaded can you run `xrandr --verbose` and attach to the bug report?
<Keybuk> sure, just going to try two other kernels as well
<Keybuk> they're installing atm
<Keybuk> but will reboot to non-pae
<Keybuk> then to pae with vesa
<Keybuk> then to mainline
<bryceh> hmm
<bryceh> apw, is there a better place to look for a kernel log with details about mode selection?
<apw> than dmesg ?
<bryceh> apw, we're collecting dmesg which has a few lines from the drm code but nothing about modeselection (at least not in keybuk's case)
<apw> bryceh, ca
<apw> can't say i have looked for that info anywhere lese
<bryceh> also is there some way to force the modeline selection like we used to do in xorg.conf?
<apw> i wonder if it is expsed on sysfs
<apw> bryceh, i think we asked you that, and to my knowledge there is not
<apw> which seems like a major fook up to me
<apw> didn't you suggest where it might be added
<bryceh> yeah
<bryceh> hrmble
<Keybuk> bryceh: xrandr --verbose added to debug
<bryceh> I like how upstream rolls out code with no provisions for working around problems.  "Lalala I live in a perfect world"
<apw> bryceh, you can work round it using xrandr
<apw> as in you can add modes and then select them using that
<apw> i doubt that is much use though
<bryceh> Keybuk, Oho!
<bryceh> 0mm x 0mm
<bryceh> but that's weird, Xorg.0.log definitely sees the dimensions properly
<bryceh> Keybuk, can you run `get-edid | parse-edid` (from the read-edid package) and attach that
<Keybuk> in -vesa again?
<mjg59> My recollection is that the edid block in -vesa doesn't actually get hooked up to randr
<apw> bryceh, so i think there is support in there for adding basic modes ... if no edid is found we add 1024x768 for instance.  but the interface i've seen doesn't have the other numbers, the frequency ranges ... so not sure if that is going to do the trick even if we exposed it
<tgardner> cnd, what're you thinking about bug #513848? I just can't see that it looks like a bug.
<ubot3> Malone bug 513848 in linux "[karmic] CPU load not being reported accurately" [Low,New] https://launchpad.net/bugs/513848
<Keybuk> could I run get-edid | parse-edid from the nouveau side?
<Keybuk> I can ssh in ;)
<bryceh> mjg59, ah that explains that
<bryceh> Keybuk, yeah read-edid seems to work even if X is not running
<Keybuk> bryceh: have pasted to bug
<Keybuk> it has errorz
<Keybuk> The EDID data should not be trusted as the VBE call failed
<Keybuk> Error: output block unchanged
<bryceh> but it can give different results from what X sees... which can be good or bad
<bryceh> mm
<bryceh> Keybuk, this was run as root?
<Keybuk> bryceh: yes
<bryceh> apw, any chance the kernel provides a dump of EDID in sysfs?
<bryceh> man I suck at debugging in this new kms world
<apw> bryceh, me too
<apw> bryceh, /sys/class/drm has lots of fun in it
<apw> including the edid for each port
<bryceh> ooh
<apw> apw@dm$ cat /sys/class/drm/card0-LVDS-1/modes
<apw> 1920x1200
<apw> and on my external vga port it has all the possible modes
<bryceh> ok so the binary edid is there
<bryceh> now how do we turn that into something we can read...
<apw> there is a program isn't there?
<apw> one we use to get them from the raw device
<apw> bet it can read them
<Keybuk> it can
 * apw installs something to see
<apw> apw@dm$ parse-edid </sys/class/drm/card0-VGA-1/edid
<apw> parse-edid: parse-edid version 2.0.0
<apw> parse-edid: EDID checksum passed.
<apw> bryceh, ^^ and lots and lots of poop
<apw> in a nice monitor section
<Keybuk> pasted what I see to bug #539730
<ubot3> Malone bug 539730 in xserver-xorg-video-nouveau "[G72M] Screen corruption when using KMS.  Dell Latitude D620 / Quadro NVS 110M/GeForce Go 7300" [Undecided,New] https://launchpad.net/bugs/539730
<bryceh> heh I was just about to paste that myself ;-)
<bryceh> Keybuk, great
<apw> apw@dm$ cat modes
<apw> 1280x1024
<apw> 1280x1024
<apw> 1024x768
<apw> 1024x768
<apw> 1024x768
<apw>  
<apw> [...]
<apw> i note that there are more than one of each and no explanation as to why ... presume other parameters changing which arn't shown
<Keybuk> mainline kernel DOES NOT WORK at all! :p
<tgardner> sbeattie, are you happy with the resolution of bug #454827? the confile states 'Conflicts: hotplug (<< 0.0.20040105-1), linux-image-2.6.31-21-server' for -virtual.
<ubot3> Malone bug 454827 in linux "linux-image-2.6.31-14-server and linux-image-2.6.31-14-virtual don't list a conflict with each other, but both provide vmlinuz-server on amd64" [Medium,In progress] https://launchpad.net/bugs/454827
<Keybuk> mmm PANIC
<tgardner> confile --> debian/control
<apw> with lucid userspace?
<smb> bryceh, Damn, that took a while to get it again. Yes, switching terminals brings up X. And then enter drops out of it to gdm. (I thought that was related to plymouth)
<Keybuk> apw: yes
<Keybuk> apw: I don't think I'm even reaching userspace
<apw> nice, whats the panic
<Keybuk> somewhere under do_initcalls
<Keybuk> the panic is > 25 lines
<smb> apw, Just on the positive side, up to now I had no blank-out in i915 until now. But I try to give it a bit more work.
<apw> smb, is that with powersave = ?
<smb> apw, powersave = 0
<Keybuk> apw: just mailed it you
<bryceh> smb, enter->crash does sound like the standard plymouth crash, but I thought that was fixed
<Keybuk> hah
<Keybuk> mainline kernels don't have nouveau anyway, do they? :p
<bryceh> mainline 2.6.33 does
<bryceh> not .32
<smb> bryceh, Right. And I boot without 'splash' anyway
<Keybuk> ah
<Keybuk> 34 doesn't
<mjg59> Keybuk: Does
<mjg59> I mean, *your* mainline kernels might not
<Keybuk> I blame apw
<Keybuk> he's probably using the edgy kernel config or something
<apw> what now?  /me self flagilates
<apw> yes the mainline kernels are all poop as they are karmic kernels
<apw> as in built for karmic.  i am testing the fixes to allow us to generate them for
<apw> multiple releases right now ... indeed the first -lucid one was done today
<apw> but until we get the perf patches reviewed and into the archive they don't build cause of perf
<apw> so we still don't have them ... /me hopes smb will review those linux-tools patches 
<smb> apw, More review. *sigh*
<apw> smb sorry man, and it debian rules changes ... always popular
<sbeattie> tgardner: #454827> yes, that would be the resolution I'd like to see on amd64 
<smb> apw, But I think for mainline .32 kernel they are always without drm .33 because they are mainline
<apw> right
 * Keybuk wonders how long it'd take to get to South London so he can punch apw in the face
<Keybuk> :D
<apw> its the .33 kernels hwich build with the wrong ones
<tgardner> sbeattie, I think that _is_ the current control file content in karmic
 * apw thanks Keybuk for his concern
<Keybuk> apw: so do you have a .34-rc1 anywhere with the lucid config? :p
<Keybuk> or a .33 even
<apw> Keybuk, not at the moment
<apw> as lucid builds don't work on mainlne ... they will shortly i ho[e
 * smb goes loking for those perf changes
<sbeattie> tgardner: has -21- been published anywhere? I don't see it.
<apw> hope, i need to pull out perf ... and those patches are the ones
<JFo> well, that was interesting. Evolution just tried to fry my machine
<JFo> my load average was 15
<JFo> looks like it got hung up trying to send a message
<tgardner> sbeattie, I'm thinking its been there much longer then -21. Still looking.
<smb> tgardner, Are you talking about a Karmic abi number=
<smb> ?
<tgardner> smb, no, the conflicts statement in the -virtual package definition
<sbeattie> tgardner: it'snot the case for -19 or -20's amd64 image.
<sbeattie> (it's not, even)
<tgardner> sbeattie, its only in -virtual
 * smb shuts off then
<tgardner> they don't mutually conflict
<sbeattie> tgardner: sorry, yes, that's what I mean.
<Keybuk> apw: so no kernel I can try to see whether nouveau issues are fixed upstream>
<sbeattie> tgardner: http://paste.ubuntu.com/396310/
<sbeattie> (output from apt-cache show linux-image-2.6.31-{19,20}-virtual)
<tgardner> sbeattie, wtf? amd64 conflicts with linux-image-2.6.31-19-generic-pae
<tgardner> looks like bogus logic in the control file construction
<sbeattie> tgardner: hence the bug report.
<tgardner> hmm, I'll keep digging. what about the complainers in the LP report that don't tlike the conflicts? Do I just tell them tough?
<smb> How useful, the battery indicator blinks away when I unplug AC...
<sbeattie> tgardner: yeah, the packages will attempt to install the same vmlinuz file and thus apt-get will break.
<sbeattie> so there needs to be a conflict there.
<tgardner> sbeattie, right, the logic implies that there _should_ be a conflicts, but its putting in the wrong one and I'm not quite sure why.
<tgardner> I'll get it figured out in a bit
<manjo> apw, I am running a bunch on wgets downloading attachements from a 50 or so bugs, and causes my system to slow down a lot, xorg uses 90% of my cpu 
<manjo> apw, bryceh any idea why ? 
<bryceh> manjo, nope
<manjo> bryceh, its has started to kill some processes like firefox etc randomly 
<manjo> bryceh, after my script is one ... xorg takes 10-30% where as it was taking 90-100% of my cpu earlier, making switching workspace and refreshing windows very slow. 
<manjo> strange 
<bryceh> manjo, high X cpu issues are hardly ever actually a bug in X
<bryceh> the X server is a server, so it is usually client process which drive X cpu load
<bryceh> (see Ubuntu-X wiki for detailed explanation + troubleshooting advice)
<manjo> bryceh, wow I have a ton of  ===>rt_ioctl_giwscan. 2(2) BSS returned, data->length = 20 in my dmesg
<manjo> apw, ^
<manjo> bryceh, looks like my wireless driver was crapping out 
<manjo> [   19.898140] --> Error 2 opening /etc/Wireless/RT2860STA/RT2860STA.dat
<manjo> followed by the message above 
<tgardner> manjo, that looks like a staging driver.
<manjo> tgardner, yes
<tgardner> manjo, perhaps you should figure out if its already fixed upstream, and send a patch if not.
<manjo> tgardner, I am on it 
<tgardner> manjo, I assume you suspect this is the reason for your high load average?
<manjo> tgardner, yes I that is my guess...
<manjo> but not sure why X was at 100+ %
<manjo> tgardner, it was really really crappy slowness I experienced
<manjo> it was killing any apps that I had opened like the 5 firefox sessions I had 
<tgardner> not too surprising
<manjo> switching workspace took for ever 
<manjo> and I am on a Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz
<manjo> tgardner, ^
<manjo> it was dog bleeping slow 
<tgardner> mayhap you should use a different wireless gizmo
<manjo> :) heh
<manjo> tgardner, /etc/Wireless/RT2860STA/RT2860STA.dat is that fw ? 
<tgardner> manjo, no, IIRC one of the RT drivers was trying to read a settings file
<manjo> there is no such  file 
<tgardner> its pure bogosity
<manjo> smb, around ? 
<gnarl> no he is off
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || SRU period for Karmic ends mid February || Ubuntu Kernel Team Meeting - Mar-16 - 17:00 UTC
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - Mar-16 - 17:00 UTC
<manjo> JFo, I want to add a common comment to a list of bugs .. how do I do that ? 
<JFo> add it as you process through them individually. I know of no way to do it in bulk either via LPlib nor the web interface
<ogasawara> manjo: I've got a stock reply script, just a sec
<manjo> ogasawara, this is a monkey script ? 
<ogasawara> manjo: arsenal
<ogasawara> manjo: look at arsenal/contrib/linux/stock-reply-bugs-with-patches.py for an example
<manjo> ogasawara, got it... does it take a listfile or just list the bugs on command line ? 
<manjo> ogasawara, sorry I am py ignorant 
<bjf> manjo, I can put something together for you pretty quick (i think)
<manjo> bjf, cool
<bjf> manjo, let me look at the script ogasawara pointed you at, I've got it here
<manjo> bjf, stand alone script ? not sure how to run the script thro arsenal framework
<manjo> ogasawara, ^
<manjo> bjf, we got no wiki magic on arsenal currently 
<bjf> manjo, np, I use the arsenal_lib, I'll get you setup
<ogasawara> manjo: you'll likely want to tweak the script to just run without any params
 * manjo notes that he MUST learn py
 * manjo moves it to the top if his list 
<Q-FUNK> hm. is there some magic trick to be able to run lilo inside a chroot that's on a compact flash?
<Q-FUNK> I was revisting https://bugs.launchpad.net/ubuntu/+source/linux/+bug/241307 and tried installing a new kernel.  it fails, so now I have to restore the old kernel.
<ubot3> Malone bug 241307 in linux "kernel oops during bootup in LTSP" [High,In progress] 
<Q-FUNK> the only problem is, this is an antiquated system with a non-BIOS that only boots off a deprecated version of lilo.
<Q-FUNK> now, I would somehow need to be able to run lilo from the outside
<mjg59> lilo -R
<mjg59> Wait, no, not that one
<mjg59> lilo -r
<mjg59> -R is remember, -r is root
<bjf> manjo, still there?
<Q-FUNK> ah, yes.  that did the trick
<Q-FUNK> mjg59: thanks
<Q-FUNK> and now for something completely different:  how would I disable IDE DMA on kernel 2.6.23 ?
<Q-FUNK> I thoguht that nodma=ide0 would be it, but it doesn't seem to have any effect.
<Keybuk> RAOF: damnit, can't find quiet channel
<Keybuk> 'twas the night before beta ...
<Keybuk> so right
<Keybuk> lbm-nouveau
<Keybuk> what is that used for today? what will it be used for once lucid is released?
<RAOF> lbm-nouveau is not used in Lucid at all.
<RAOF> lbm-nouveau *is* used in the testing PPA, which is there to allow users to easily test more current nouveau when they run into bugs.
<RAOF> So, it's slightly convenient to have lbm-nouveau patches in Lucid, but ask for them to be dropped and I'd be happy to do so.
<Keybuk> right
<Keybuk> but we'll want to use that PPA even once lucid is released
<Keybuk> and once m is current right?
<RAOF> Yes.
<RAOF> But it wouldn't be hard to drop lbm from the PPA and instead upload a full kernel with a different drm backported.
<Keybuk> sure, sure
<Keybuk> but it's harder than what you're doing now, right?
<Keybuk> I was only tidying up, and noticed we now put nouveau in the kernel
<Keybuk> so wondered whether the patch was still needed
<Keybuk> if we're still using lbm-nouveau, then I'll keep the patch :)
<RAOF> Ok.  Yeah, it does make it a little easier to just build lbm-nouveau.
<Keybuk> so let's keep it :D
<Keybuk> so, other question on that PPA
<Keybuk> if I'm having issues with nouveau on a particular card, does that contain an updated kernel with updated KMS bits?
<RAOF> Yes.  lbm-nouveau contains the updated kernel KMS bits.
<Keybuk> ok
<Keybuk> and those are > lucid right now?
<Keybuk> also *grr* our kernel doesn't have mmiotrace enabled
<RAOF> Yup.  It adds some overhead, even when not being used.
<Keybuk> it does?  I thought it was enabled/disabled through the tracing infrastructure now
<RAOF> They are > lucid right now; they're current as of a couple of days ago.
<Keybuk> don't suppose you have an mmiotrace-enabled kernel nearby?
<RAOF> I don't; that's something else I want in a PPA.
<Keybuk> bleh
<Keybuk> ok
 * Keybuk opens a window
<RAOF> I did investigate whether to request we turn on mmiotrace in the default kernel; upstream said that there was still some overhead involved, so I dropped it.
<Keybuk> Mmiotrace feature is compiled in by the CONFIG_MMIOTRACE option. Tracing is
<Keybuk>   25 disabled by default, so it is safe to have this set to yes.
<Keybuk> from mmiotrace.txt in the kernel source
<Keybuk> but anyhoo
<Keybuk> my room is too warm anyway
<Keybuk> ok
<Keybuk> how the hell do I disable kernel flavours now ?!
<Keybuk> ah, right
<Keybuk> debian.master
<Keybuk> https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
<Keybuk> now I sha'n't forget every damned time
#ubuntu-kernel 2010-03-17
<Keybuk> RAOF: I forgot to ask, where is the hallowed lbm-nouveau PPA?
<RAOF> ppa:xorg-edgers/nouveau.
<RAOF> Keybuk: If you want to try with bonus OpenGL, ppa:xorg-edgers
<Keybuk> nah
<Keybuk> this is just about "does it work with a more recent nouveau?"
<Keybuk> probably not, but worth trying at least once
<RAOF> Yeah.
<RAOF> The 3D works surprisingly well, actually, no matter how much upstream shouts âunsupported!â.
<RAOF> I haven't noticed any commits that would be likely to fix things for you, though, and I keep an eye on the nouveau commits.
<Keybuk> I doubt there are any
<Keybuk> since darktama is asking for mmiotrace output of nvidia-glx on this board
<RAOF> Ah.
<RAOF> Man, I didn't think there was much mmiotracing left to be done, based on how infrequently it's asked for in bug reports.  Otherwise I would have prioritised making a mmiotrace kernel available.
<Sarvatt> building a new lbm-nouveau now if you can copy it to xorg-edgers/nouveau when its done RAOF
<RAOF> Sarvatt: Ta.
<Sarvatt> ddx will have to wait for tomorrow, it has a significant amount of changes from your git branch and I have to do it manually
<Sarvatt> so maybe dont copy it yet, not sure if that nv50: fix texturing from >=4GiB mark requires the accompanying kernel commit
<Sarvatt> nevermind, will just add it as a patch :)
<RAOF> Sarvatt: It can wait for tomorrow :)
<Sarvatt> already uploaded both, now if they work is another question because I dont have a nouveau machine atm and it required extensive changes :)
<RAOF> This sounds like a job for Ein!
<BenC> [39022.116166] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
<BenC> [39022.116186] render error detected, EIR: 0x00000000
 * BenC really wishes this would go away
<RAOF> Is that the i915.powersave dies-sometime-after-resume bug?
<BenC> No, I have i915.powersave=0 and this still happens
<BenC> this is i915 dies after susped/resume
<BenC> Xorg crashes and gives me the "low res mode" warning screen, and if I just keep it in low-res, it works fine until I reboot
<BenC> compiz is enabled
<Sarvatt> yeah RAOF thats not the needs powersave=0, that one hangs with a solid color a few minutes after resume, another suspend/resume cycle fixes it for awhile again, and it doesn't actually hang the GPU it just gets stuck busy doing framebuffer compression. BenC: Can you file a bug and subscribe Sarvatt to it so I can check out your logs tomorrow? Sounds like an issue that needs to be forwarded upstream
<Sarvatt> BenC: file it after the issue occurs and you're in failsafe so the right info is in the logs preferably :)
<Sarvatt> BenC: also it would be useful if you could try with this ppa -  https://launchpad.net/~xorg-edgers/+archive/ppa to see if the problem still exists with the newer libdrm/intel
<BenC> Sarvatt: done
<BenC> Sarvatt: I'll try the ppa tomorrow
<Sarvatt> thanks BenC, looks like it was duped to another bug that I assumed was just an apport script screwup too
<apw> Keybuk, so is the plymouth in the archive wonderful?  is it safe to update?
<amitk> apw: I've got config changes for ti-omap that should be uploaded ASAP
<amitk> do I need to open a bug?
<apw> amitk, ok get them onto our list, offically we would need a bug ... 
<apw> one for the lot would be sufficient i suspect
<apw> enabled new cpu or whatver the broad aims are
<amitk> apw: ack
<amitk> apw: I don't see your config changes having any bug attached to them
<apw> dammit ... amitk saw me
<apw> smb assume you don't have a bug for that SG V4 thing
<amitk> apw: I can remove my buglinks too ;)
<smb> apw, No, there have been a few others, but I assumed somewhat until release we don't need bugs for everything. Just acks
<apw> hrm
<smb> Or have I been telling otherwise before
<apw> smb, they are your rules, just tell me what they are
 * smb needs to read his own rules
 * apw waits for clarification
<amitk> smb: Just FYI, I'm going to have several patches and patchsets for omap till release while we beat it into shape. So having a bug attached for each might not be practical
<apw> i care not about hoop jumping as long as know which hoops i am meant to jump
<smb> apw could go and see whether he finds something written down
 * apw is sure smb will tell him if he just waits ... la la la
<apw> amitk, well you could use the same one over and over :)
 * smb slaps apw
 * apw can't hear dyou
<amitk> hehehe
<smb> I'd would say we should allow for exceptions as there might be things just tuned. Execept if the committer is apw. In that case we need full SRU justification with two carbon copies which need to mature for 3years at least.
<amitk> smb: sounds like a plan
 * apw burns the new SRU policy for heat
<apw> ok amitk so i missinformed you ... osunds like you don't need a bug ... 
<smb> apw, You wanted a new one
 * amitk re-amends his commits
<smb> Well lets say, we should prefer having a bug, but there might be some changes that are done without
<apw> yep ... i am going to assume that the review will say 'oi where is the bug' and if it doesn't then we can apply it for now
 * amitk halts after 2 re-amends to wait for smb's final say
<smb> I probably should do one for the stable update, just that its referenced in a better way
<smb> amitk, You have a bug going with it?
<amitk> smb: AFAICT, we never had bugs until release
<amitk> smb: yes, bug 540146
<ubot3> Malone bug 540146 in linux-ti-omap "Enable omap kernel to boot on beagleboard" [Undecided,New] https://launchpad.net/bugs/540146
<smb> amitk, So just put it in
<amitk> smb: two acks would do just fine
<smb> Why leave a reference out if there is one
<amitk> ok
<amitk> apw: pull request for you on the mailing list
<apw> amitk, thanks
<apw> cking, how do identify which disk driver is handling my disk if they are all builtin
<smb> apw, you might see which one is handling your adapter in lspci -vvvnn
<apw> smb, of course ... thanks, and the fact that ata_piix appears in my bootcharts should have been a clue
<amitk> apw: lshal | grep driver ?
<apw> amitk, ENOHAL
 * amitk keeps forgetting!
<cking> me thinks..
<cking> apw, will perf show you anything useful?
<apw> cking, ahh smb sorted it for me, lspci has the driver even if its builtin
<cking> yeah, of course, that's the most straight forward way. doh
<apw> JFo, about?|
 * apw waits for that to appear on smackeral so i can find it next time
<smb> apw, The stable updates change one symbol because a driver selects a different submodule. What would be your favorite method of handling this: a) abi bump or b) ignore file. I tend to a) to have a fallback kernel
<apw> yeah i am all for more bumping, if its a bump bump it
<apw> and for huge stable updates, bump it anyway is my feeling
<smb> apw, yessir. agree
<apw> amitk, in this update you pull out CRAMFS to a module, is it bad if it remains in?  i thought we only recently made it builtin on arm cause it was used for older initramfs
<amitk> apw: in that case it can stay builtin. Which older initramfs are we talking about?
 * apw is fuzzy on it, just has it in mind, if you have boot tested it i am happy anyhow
<apw> but we may need to revisit it
<amitk> apw: I've only boot tested w/o initramfs
 * apw asks on #u-arm
<apw> ok seeems it was a herring rouge
<apw> so igore me
<apw> amitk, in our ti-omap branch you have selected out of tree source build, do you know we need that?  suspect we don't as its mostly virgin
<amitk> apw: I have?
<apw> amitk, heh in that case i'll test it without
<Q-FUNK> for some reason, 'dpkg-reconfigure linux-image-foo-bar' no longer re-generates the initrd.img or run the bootloader scripts.  I seem to recall some update-initramfs option causing this to happen but not how to restore it. anyone?
<Q-FUNK> I first thought thta it was the -t option, but apparently not
<smb> Q-FUNK, I don't use dpkg-reconfigure for that. update-initramfs -u seems simpler for the usual case I need it
<Q-FUNK> smb: that works, but it makes the package non-updatable, should an updated kernel ever be pushed.
<Keybuk> apw: the plymouth in the archive is the best plymouth yet
<smb> Q-FUNK, I am a bit doubting that. Its never part of the package, so why should it affect the package
<smb> Keybuk, So this one works with nouveau?
<Keybuk> smb: only if nouveau works
<Keybuk> but should do, yes
 * Keybuk has a patch from darktama for his LVDS issue
 * smb goes booting up his testbox
<apw> Q-FUNK, isn't that now done via dpkg triggers?
<Q-FUNK> apw: yes, when running 'dpkg-reconfigure linux-image-foo-bar' but it no longer works after somethin else touched the initrd.img 
<apw> now i am confused, you mean that the reconfigure does update t
<apw> the initramfs as long as its not been changed?
<apw> that sounds like its doing what you want, except it got changed somewhen in the past
<Q-FUNK> as long as initrd.img hasn't been changed, dpkg-reconfigure works.  the day it has, it no longer does.
<apw> ok that sounds like what i would want it to do
<Q-FUNK> sure
<apw> how did it get changed otherwise?
<Q-FUNK> but how do you return control to dpkg-reconfigure after something else modified it by running update-initramfs outside the dpkg realm?
<apw> perhaps force reinstalling the image might do it
<smb> apw, huh? If you ran update-initramfs, you still want a kernel update regenerate it, wouldn't you?
 * apw is looking for the trigger handling right now
<apw> smb, no if i did something outside the correct way, then i'd expect it to be left alone
<apw> (assuming dpkg-reconf is the right way, and i suspect it is)
<smb> apw, I would disagree with you there
<apw> dpkg generally does not change files you changed outside its control
<apw> it generally leaves them be, or throws a merge request to you
<apw> it cirtianly doesn't replace them without comment
<apw> why should the initramfs be different
<Q-FUNK> the correct debuntu way would be to make whatever modification in /etc/initramfs-tools/* then dpkg-reconfigure the kenrel.
<smb> but initrd is a build thing,
<apw> right ... and that works as i hear it
<apw> the only issue is something outside touched it, and we don't know how to day
<apw> say "look take it back and look after it"
<smb> Its always just generated. Whether you use update-initramfs or reconfigure a package
<apw> yes, but dpkg cannot know that, all it knows is it changed
<apw> if i cpio it out munch it and put it back, it looks the same to dpkg ... changed without its knowledge
<apw> and therefore something to avoid stamping on i'd say
<apw> bah how _do_ triggers work anyhow
<smb> update-initramfs -u
<smb> update-initramfs: Generating /boot/initrd.img-2.6.32-16-generic
<apw> Q-FUNK, can you pastebin the output of doing the reconfigure please ... all the way to the end
<smb> apt-get --reinstall linux-image-2.6.32-16-generic
<smb> Unpacking replacement linux-image-2.6.32-16-generic ...
<smb> Setting up linux-image-2.6.32-16-generic (2.6.32-16.25) ...
<smb> Running depmod.
<smb> update-initramfs: Generating /boot/initrd.img-2.6.32-16-generic
<apw> smb, yeah i can't see any checks in here that would stop it generating it
<Q-FUNK> smb: yes, that's what it normally does, as long as the initrd wasn't touched
<smb> Q-FUNK, I have touched the initramfs by running update-initramfs
<apw> Q-FUNK, so do the same on yours and pastebin it so we can see the difference
<Q-FUNK> do we have our own pastebin here?  I'd rather avoid flodding the channel
<apw> i use the command pastebinit
<Q-FUNK> ah, that's a new one to me.  just a sec.
<apw> Q-FUNK, seems we have paste.ubuntu.com as well
<smb> Keybuk, FWIW, the best plymouth for now, seems still to get into some trouble here. :( But at least in this case it is in S state and waits for ep_poll
<Keybuk> smb: it shouldn't get into any trouble
<Keybuk> please describe what you see
<smb> purple
<smb> The screen with the 4 dots, X is started
<Keybuk> ubuntu logo or "Ubuntu 10.04" ?
<smb> Ubuntu logo
<Keybuk> so you see mouse pointer?
<Keybuk> lies
<Keybuk> if you see 4 dots, you see Ubuntu 10.04 :p
<Keybuk> so you're lying to me about one of those two facts :p
<smb> Keybuk, Ok, sorry 5 dots
<Keybuk> :D
<Keybuk> the variations in the number of dots is deliberate :p
<smb> Aha. :)
<Keybuk> debugging aid through splash screen theming :-)
<Keybuk> ok, so you're on nouveau
<Keybuk> single head or multi-head?
<smb> sinle
<smb> single
<Keybuk> so your 5 dots are all orange
<Keybuk> X has started
<Keybuk> you see a mouse pointer?
<smb> Right, its running in ps output
<smb> no
<Keybuk> ok
<Keybuk> can you paste the X cmdline for me
<smb> attached keyboard is dead as well
<Keybuk> enter doewsn't kill X ?
<smb> 1018 tty7     Ss+    0:00 /usr/bin/X :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-QbNPCm/database -nolisten tcp vt7
<Keybuk> smb: and /proc/1018/wchan ?
<smb> ttm_bo_wait_cpu
<Keybuk> hah
<Keybuk> right
<Q-FUNK> http://paste.ubuntu.com/396725/
<Keybuk> Not a plymouth bug, sorry
 * smb does not like the sound of "hah"
<Keybuk> nouveau/X has crashed your card
<Keybuk> just to be sure
<Keybuk> plymouth --ping && echo "ok"
<smb> Keybuk, Sorry, did a kill -9 1018
<smb> This ends plymouth and restarts gdm
<Keybuk> yup
<Keybuk> plymouth set the screen to black ok?
<Keybuk> you get failsafe X now?
<smb> A short period of black and now gdm greeter is up
<Keybuk> right
<Keybuk> isn't a plymouth bug then
<Keybuk> all plymouth is doing on your card is using /dev/fb0
<Q-FUNK> apw: http://paste.ubuntu.com/396725/   normally, that update-initramfs hook would run at the end of the dkpg-reconfigure.
<Keybuk> in plain old Linux framebuffer mode
<Keybuk> so it's just writing pixels to the framebuffer
<Keybuk> it's not talking directly to nouveau
<Keybuk> nor is it talking to the drm/dri layer
<Keybuk> what's crashing for you is something inside TTM when X starts
<Keybuk> since plymouth didn't go near that, meh
<Keybuk> if plymouth can cause that, it's still a kernel bug, since plymouth is only writing to the framebuffer
<smb> Keybuk, Oh well. :-P Its just the fact that plymouth and X run at the same time that seems odd. And killing X to cause plymouth to end
<Keybuk> that's because killing X is reaped by gdm
<Keybuk> and gdm talks to plymouth
<Keybuk> plymouth and X running at the same time is so we can do smooth transition on Intel/GEM cards
<Keybuk> we have to hold the drm/dri connection open so that the kernel doesn't replace our own crtc buffer with the fbcon buffer
<Keybuk> it's otherwise inactive
<Keybuk> it's closed down various fds, and removed watches on others, etc.
<smb> Hm, ok. So something on the first start of X goes wrong. plymouth does not get talked to and X is stuck somewhere. And it seems to work on subsequent starts
<apw> Q-FUNK, what the heck release is this with 2.6.23 ?
<Q-FUNK> apw: currently hardy. cannot upgrade to anything newer than 2.6.23 because of bug #241307 
<ubot3> Malone bug 241307 in linux "kernel oops during bootup in LTSP" [High,In progress] https://launchpad.net/bugs/241307
<Q-FUNK> had to build my own kernel package based on the gutsy config just to keep this host remotely up-to-date and up-and-running.
<apw> Q-FUNK, whats in your /etc/kernel-img.conf (pastebin that too)
<Q-FUNK> apw: http://paste.ubuntu.com/396731/
<apw> think you gotten hit by the bug where the triggers get lost
<apw> postinst_hook = update-grub
<apw> postrm_hook   = update-grub
<apw> i have those in mine
<Q-FUNK> and yes, this runs LILO, because GRUB cannot work without some console (on the host or serial) while lilo can be told to blindly boot whatever.
<Q-FUNK> yup.  got that on my normal  hosts running grub too.
<apw> i wonder if you'd need an equivalent or not hrm
<apw> perhaps that is a herring rouge too
<Q-FUNK> i didn't need to until I somehow stupidly issued an "update-initramfs -u -k all
<smb> Well a lot might be different in Hardy anyway
<apw> well i would try force reinstalling the kernle .deb
<apw> and see if that resolved it, seemed to for smb
<Q-FUNK> it didn't
<smb> apw, I was looking on Lucid
<Q-FUNK> something in update-initramfs wants to play smart pants and decide that the image was updated so it doesnt get updated.
<apw> well i can't see anying in my lucid copy doing anything smart
 * smb tries to remember whether there were hook dirs...
<apw> Q-FUNK, i'd start by confrming it gets called by renaming it .real and adding a log script
<Q-FUNK> apw: mind you, you're using grub, which is a lot more fault-tolerant and doesn't require updating the bootsector when installing a new kernel.
<manjo> apw, ping
 * apw is here
<smb> Keybuk, Have been distracted and its probably not relevant as this seems to be in nouvau, but "plymouth --ping && echo ok" does print nothing when in wedged state
<Keybuk> ok
<apw> smb, interesting to see that someone from ksplice is following your trees
<smb> apw, Was that the mail asking for the cve updates this morning?
<apw> yeah note the email addy on that one
<smb> apw, I have not, usually hidden by my mailer. But yes, interesting.
<smb> apw, Well probably as they offer to patch for security things on the fly...
<apw> probabally as a paid for service ...
<JFo> Keybuk, mind taking a quick look at bug 539787
<ubot3> Malone bug 539787 in linux "Plymouth won't show up while booting, I get messages" [Undecided,Triaged] https://launchpad.net/bugs/539787
<Keybuk> yes, sorry
<Keybuk> your bug won't cause us to cancel beta 1
<Keybuk> frankly plymouth not showing up is common
<Keybuk> and not a bug
<Keybuk> well
<Keybuk> it's a kernel bug ;)
<Keybuk> make the graphics drivers load faster
<JFo> heh
<JFo> thanks for looking
<JFo> :)
<Sarvatt> Keybuk: they used to load a lot sooner, when plymouth was removed from the initrd and things were serialized more they started loading a lot later
<Keybuk> yes, but in the initrd they were critical path
<Keybuk> so we spent several seconds waiting for them
<Keybuk> so while you had a splash screen for longer, your boot took much longer
<Sarvatt> the console changes 3 times before plymouth starts now, looks kind of funky.. ugly vgacon that shows the fsck messages, then console-setup changing the fonts on that, then the drmfb loading
<Keybuk> fast > pretty
<ogra> hmm, i seem to have plymouthd die on boot since the recent upgrade ... and also a heavy flicker on shutdown
<ogra> whoops, i didnt realize i'm in -kernel ... that was supposed to go to -devel
<Keybuk> ogra: video please
<ogra> Keybuk, i assume you are already aware of the crash on boot ? 
<Keybuk> no
<ogra> ok
 * ogra reboots
<tgardner> apw, 2.6.32-17-server works good for me
<apw> tgardner, the igb bits yes?
<tgardner> apw, yep
<apw> tgardner, cool
<apw> thanks for the feedback on that
<cnd> rtg, thanks!
<cnd> tgardner: thanks too!
<cnd> so we don't do lpia builds anymore right?
<tgardner> cnd, not for Lucid
<cnd> I'm curious why we started to, and no longer make them?
<tgardner> its a long and sordid story
<cnd> did they just not provide enough benefit to be worth it?
<tgardner> essentially. moorestown never really materialized.
<cnd> tgardner: I figured lpia was also for atom stuff, but that's not the case?
<tgardner> there was some thought that LPIA flags could improve performance and power consumption, but it never really made much difference.
<tgardner> atom seems to work fine as a regular 'ol 386
<cnd> ok
<cnd> I thought that by changing the changelog version (i.e. to 2.6.32-16~lp555555) that I would get a vmlinuz with the extra string appended as well
<cnd> but recently my kernels haven't been built with the string appended
<cnd> am I forgetting something?
<apw> cnd, the packages are generated with the versions on them
<cnd> apw, correct, but what about the vmlinuz and initrd files?
<apw> cnd, but the binary files are abi and flavour specific only
<cnd> I could have sworn I had vmlinuz files with the version appendage too, but maybe I'm wrong
<apw> for the mainline builds the ABI number is unique to the release
<apw> vmlinuz-2.6.32-02063208-generic
<manjo> JFo, how do you fix ImportError: No module named arsenal_lib ? 
<bjf> manjo, are you running from the arsenal directory?
<JFo> I used a link
<JFo> to the relevant script under contrib/
<manjo> I ran a script from kernel/contrib/linux
<manjo> ./mass_reply.py
<manjo> JFo, where do you run the script from ? 
<JFo> from contrib/linux/
<JFo> but I have a softlink in contrib/linux/ back to contrib/arsenal_lib.py
<manjo> hmm that is what I did ... cd to contrib/linux and ran the script
<manjo> ah ic 
<manjo> JFo, cool thanks a ton tha tworks 
<JFo> manjo, no sweat :)
<bryceh> JFo, yeah we need to make arsenal_lib.py get installed or something
<bryceh> my python packaging skillz are anemic
<JFo> heh
<JFo> mine are non-existent
<bryceh> JFo, apw, btw I'm sure you already have a report that shows your milestoned / nominated bugs, but I did up one for the desktop team in arsenal
<Sarvatt> tgardner: might have something to do with the lpia toolchain being changed to optimize for pentium-m instead of backporting the gcc atom support patches back in early jaunty to account for celeron netbooks, that killed LPIA for me.. lucid+1 with gcc 4.5 that has -march=atom support and the kernel now having atom optimizations would have been rocking :(
<bryceh> JFo, e.g. http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/milestone-bugs.html
<bryceh> JFo, also in JSON for import to bughugger - http://www2.bryceharrington.org:8080/X/Data/ubuntu-x-swat/milestone-bugs.json
<JFo> very nice
<JFo> that is yet another thing I need to get conversant on is the JSON building
<Sarvatt> -Os -march=core2 -mtune generic seem to be the best flags for atom without -march=atom support
<bryceh> yeah that's actually the part of arsenal I'm most happy with
<JFo> I'm sure bdmurray is getting tired of carrying me
<JFo> may have a look at what you have built there and see what I can pillage for a kernel report :-D
 * JFo is a code pirate
<bryceh> sure, and happy to explain the bits
<JFo> excellent
<bryceh> the only part I'm unhappy with is the report generator chokes on unicode, and launchpad is thick with it.  
<bryceh> but I'm banging on that today so we'll see
<JFo> mind if I take a bit of your time next week to discuss best practices for launchpadlib stuff?
<bryceh> I might change templating systems if I can't fix it easy
<bryceh> JFo, sure
<JFo> thanks :)
 * JFo needs a bigger plate to put things on
<bryceh> same
<JFo> <- headed over to the new place to move furniture, see you all tomorrow. :)
<cnd> if anyone is running lucid right now, can they tell me what is output from this (should be a 0 or a 1): cat /sys/kernel/debug/tracing/tracing_on
<sbeattie> cnd: 1 here
<cnd> sbeattie: can you check tracing_enabled too?
<sbeattie> cnd: 1 also 
<cnd> sbeattie: thanks
<sbeattie> sure. 
<cnd> ahhh, I see why that's ok, current_tracer is nop
<apw> bryceh, sounds good where can i see the output of that
<bryceh> apw, e.g. for X http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/milestone-bugs.html
<manjo> bjf-afk, your script worked wrt to adding the note but failed to change state to incomplete
<manjo> bjf-afk, had to do that manually
<bryceh> manjo, did it show an error message?
#ubuntu-kernel 2010-03-18
<amartin> hello, I'm compiling new stable kernel 2.6.33.1 on ubuntu karmic, but encounterd this error: http://pastebin.com/G1Gi1yre
<amartin> can someone please tell me wthat to do with it??
<tgardner> cnd, what the 3c59x driver needs is a threaded interrupt handler.
<amitk> apw: when can we expect 500.2 omap to hit the archive? (monday?)
<apw> i would hope the freeze will lift today late, so will start building then
<apw> we should be able to stroke it through tommorrow then i'd hope
<amitk> so definitely by Monday with all the NEW'ing
<apw> if it gets released tonight our time, then it should be built morning our time
<apw> so we might get it stroked through during our day tommorrow
<cking> anyone see that coming out of S3 the printk timestamp is ridiculously big on some CPUs?
<chrisccoulson> JFo, are you sure that bug 509547 is a kernel issue? ivanka asked me to look at a similar issue, so i just purchased a 3G dongle and can recreate it too. but if i restart network-manager, I can get the dongle to appear correctly....
<ubot3> Malone bug 509547 in linux "[lucid] (option) 3G USB modem unusable if inserted from boot" [Medium,Triaged] https://launchpad.net/bugs/509547
<chrisccoulson> JFo - in my case, it appears to be a race with modemmanager and network-manager...
<rafiyr> I've just submitted a bug report (bug #541453).  The post 2.6.32 kernel updates for hid-ntrig.c are necessary for proper conventional (pen and single touch) operation for contemporary firmwares found in N-Trig touch screens.
<ubot3> Malone bug 541453 in lucid "basic ntrig functionality broken in lucid" [Undecided,New] https://launchpad.net/bugs/541453
 * apw looks
<micahg> I think I found a kernel bug in upstream bugzilla, could I get someone to confirm before I add it to the LP bug
<micahg> I'll post it to the bug and if someone gets a chance, please set as upstream if appropriate, bug 517807
<ubot3> Malone bug 517807 in linux "iwlagn: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 free buffers remaining." [Undecided,New] https://launchpad.net/bugs/517807
#ubuntu-kernel 2010-03-19
<crimsun> sigh, cs46xx hardware is largely broken :(
<crimsun> I suppose we can reprobe the register until it appears to return valid data
<bladernr_> anyone around who can answer a question about filing a bug ?
<bryceh> bladernr_, don't ask if you can ask.  bad irc etiquette
<bryceh> better to just ask your question straight off, then people can answer or ignore as appropriate ;-)
<bryceh> bladernr_, also you probably should ask on #ubuntu or #ubuntu+1, as this is more a developer-oriented channel
<bladernr_> bryceh:  sorry... was talking in other channels too ... I know better :/
<slackguru> Hey! Is there a working PPA?
<slackguru> 2.6.31-20-generic-pae is killing me.
<slackguru> Slowest kernel I've seen in a long time.
<slackguru> Memory consumption is off the charts and I am actually swapping...
<slackguru> If not, I am going to give a little script I wrote a try to see if I can successfully make synaptic think kernel.org and its change log is a valid ppa
<slackguru> Out of 93 people nobody is awake?
 * hyperair compiles his own kernels
<hyperair> isn't PAE supposed to have some pretty bad performance, though?
<jjohansen> well it depends on what you are doing
<jjohansen> PAE does have a penalty
<jjohansen> memory consumption off the charts just seems wrong though
<slackguru> Well, I am building a 2.6.33 right now on the laptop that crashed and see if its any better, but my ubuntu box, I want to stay with something known not to mess with the tool chain, I am building my own tool chain and all on the crashed laptop
<slackguru> I don't want to have to do that for my main box and frankly I don't even know how pae got on here, I only have 512MB of ran and I didn't go looking for pae so it should be the vanilla generic kernel, but it is not
<slackguru> The only added repositories I have in my source.list is for the ubuntu debugging symbols.
<jk-> slackguru:  https://launchpad.net/~kernel-ppa/+archive/ppa has builds of mainline kernels
<jk-> and you should be able to just install the linux-image-*-generic to replace the pae one
<slackguru> Number of packages:
<slackguru>     0 source packages (0 bytes)
<slackguru>     0 binary packages (0 bytes)
<slackguru> Repository size:
<slackguru>     0 bytes (0.00%) of 8.0 GiB
<jk-> i'd try the generic before installing a mainline one from that PPA.
<slackguru> that repo is dry
<jk-> yeah, odd
<slackguru> nothing there.
<jk-> anyhow, try -generic
<slackguru> I am actually thinking of switching to -rt
<jk-> and if that doesn't work, file a bug
<jk-> -rt that may improve latency, but not performance
<jk-> http://kernel.ubuntu.com/~kernel-ppa/mainline/ for the builds
<jk-> but still, try -generic first.
<slackguru> thanks jk- 
<jk-> np
<slackguru> I am actually looking for a ppa that has stable development releases, kernel.org has 2.6.33 and ubuntu has only caught up to 2.6.32
<jk-> you're probably best off using the default kernel, it's had the most testing with the ubuntu userspace.
<slackguru> with 2.6.31-20 I feel like I am the testing ground
<slackguru> let me know if their is a daily ppa if you hear anything.
<slackguru> thanks
<RAOF> There is an upstream kernel build, but it's not a great idea to switch kernels.
<RAOF> There's a lot of GPU work going on in the kernels, and you'll hit a poorly-tested version combination quite quickly with different kernel versions.
<psurbhi> hie! i am looking at bug 537465
<ubot3> Malone bug 537465 in ttf-sazanami "package ttf-sazanami-mincho 20040629-2ubuntu2 failed to install/upgrade:  (dup-of: 533609)" [Undecided,Incomplete] https://launchpad.net/bugs/537465
<ubot3> Malone bug 533609 in mono "package mono-runtime 2.0.1-4ubuntu0.1 failed to install/upgrade: " [Undecided,Incomplete] https://launchpad.net/bugs/533609
<psurbhi> and in the lspci output attached by apport
<psurbhi> i cannot seem to see any driver module against the VGA compatible controller
<psurbhi> any guesses why this might be happening?
<psurbhi> will this be an in kernel compiled driver?
<ogra> amitk, psurbhi, http://paste.ubuntu.com/397697/ has the first two panics i get with the omap kernel
<amitk> ogra: dmesg?
<smb> psurbhi, the lspci -vvvnn output would list a driver attached to the device even if it is build-in
<ogra> amitk, the board hangs hard, no way to get to dmesg at that point
<psurbhi> ogra, any snap possible?
<ogra> amitk, but i assume you should see the same on your board if you have other ways to get data
<cking> apw, have you delved into acpi debugging your dell after s/r w.r.t the temp sensor issue?
<apw> cking, nope not had a second to look at it other than to be annoyed by it
<apw> you can teach me when i get back
<pmatulis> a netxen (10 Gb) network adapter (NC522SFP) is not having it's module (netxen_nic) loaded automatically on hardy.  what to do?
 * cking appreciates apw's daily kernel builds - makes bisecting so much easier
<apw> cking, cool
<tgardner> apw, at least smb will have something to do whilst we're gone. I see a bunch more .32 stable updates in the pipe
<apw> tgardner, yeah wouldn't want him to be bored now would we
<smb> and for extended self flagellation he even tries to add to them
<tgardner> smb, IIRC there was an igb patch you can skip
<smb> tgardner, I think I saw some drop thing. But I usually check with whats really in the queue anyway
<smb> tgardner, Btw, have we been having problems with tg3 based cards?
<tgardner> smb, nothing thats attracted my attention
<smb> Ok, might just be my imagination by half seeing things passing by
<tgardner> smb, the tigon driver is quite popular, and generally stable
<smb> Just because that is in the queue "tg3: Fix 5906 transmit hangs"
<smb> and another on on that
<smb> tg3: Fix tg3_poll_controller() passing wrong pointer to tg3_interrupt()
<tgardner> smb,  perhaps its a rare circumstance
<smb> Quite possible. Usually the commit message does not say how high the probability of an issue is
<psurbhi> hey, does anyone know what the bcdDeviceMin, bcdDeviceMax parameters in the UNUSUAL_DEV macro in drivers/usb/storage/usb.c signify?
<smb> psurbhi, IIRC those were version numbers
<psurbhi> ok, so how do you aquire those?
<smb> Like device version/firmware version x to y
<smb> lsusb -v
<psurbhi> aah, ok :) thanks
<smb> psurbhi, Of course you only get one number for the device and version you actually have
 * psurbhi checks
<smb> psurbhi, so the limits usually grow over time or were gathered by asking around
<psurbhi> so then is it safe to put the min as 0x0000 and max as 0xffff?
<psurbhi> as i see for other entries?
<smb> psurbhi, Only if you assume all are broken. So not safe
<psurbhi> ok..
<smb> The safe approach is only to use the one you have (or a range if you have that)
<psurbhi> so then safer is to be specific and put it for the specific version that lsusb gives
<smb> right
<psurbhi> smb, ack! thanks
<smb> psurbhi, btw its the bcdDevice entry
<psurbhi> smb, thanks a lot! just when i was searching :)
<smb> And I believe it was a bcd encoding used for the integer
<smb> so a bcdDevice = 6.01 woule be 0x0601, but better check that
<psurbhi> which is why the name has a bcd om ot
<psurbhi> ok..
<psurbhi> s/om ot/in it
<smb> psurbhi, Yeah, actually true :)
<psurbhi> smb, i have the hal output.. and am hoping the lshal entry "revision_bcd" is the same
<smb> psurbhi, You could check with a usb device you got?
<psurbhi> yeah
<psurbhi> got that :) thanks smb!
<smb> np :)
<KB1JWQ> Found a bug that affects me that I'd like to pitch in on.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374 -- comment 21 and 22 shows where we're stalled, and I suspect it's something I can overcome with a bit of guidance.
<ubot3> Malone bug 532374 in linux "[Lenovo 2537AD3, 2537AB8] one successful suspend/resume per boot" [Undecided,Confirmed] 
<KB1JWQ> ubot3: You just scared the crap out of me.  Don't do that. :-)
<ubot3> KB1JWQ: Error: I am only a bot, please don't think I'm intelligent :)
<KB1JWQ> Specifically, the question becomes "how do I compile a kernel 'The Ubuntu way' with ACPI_PROCESSOR as a module.
<KB1JWQ> The docs for kernel recompilation on Karmic seem a bit outdated for Lucid; is there a pointer to fresher documentation on this than https://help.ubuntu.com/community/Kernel/Compile ?
<tgardner> KB1JWQ, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<slackguru> RAOF, how can I find it? I wouldn't be asking if I didn't understand what I was getting myself into.
<KB1JWQ> tgardner: Thanks!
<alexmoldovan> Hello everybody, I'm currently an intern @ Canonical's office in Montreal and I have some questions about the kernel's ACPI management.I want to be able to wake up the computer after a period of time, and I use the following script to do it: http://pastebin.ubuntu.com/397848/, with pm-hibernate of poweroff on the last line. We have over 60 laptops in the lab and I've tested most of them. Last week, a machine, woke up just from  poweroff stat
<alexmoldovan> e and not from pm-hibernate. This week, it wakes up from both states. It happens alos with several others machines. My question is  Were there some changes in the kernel in the last week that are related to this issue? If yes, please point me into the right direction to further investigate. Thanks!
<smb> alexmoldovan, It might help to say which kernel (series) you are using. Lucid?
<alexmoldovan> yes
<alexmoldovan> I'm testing lucid in the lab
<johanbr> alexmoldovan, kernel freeze was March 11, so if your results have changed since then, it's related to userspace changes
<BenC> alexmoldovan: IIRC, the wakeup is mostly hardware induced (IOW, no kernel changes affect whether it wakes up or not)
<BenC> it's a case of the ACPI alarm working or not (if it's software related, then it's a case of access to the ACPI alarm, not so much kernel really)
<BenC> alexmoldovan: if it's a case of the kernel not working on wakup, then it's unrelated to the alarm itself, and just a suspend/resume issue
<BenC> alexmoldovan: do your tests show that a forced wakeup works, and just that the alarm isn't waking the system up?
<alexmoldovan> the wake from the power button works fine
<alexmoldovan> but not with the alarm
<BenC> Ok, then it sounds like that the ACPI alarm just isn't triggering, which is usually a bug in BIOS more times than userspace/kernel
<smb> The power button is a different source for wakeup.
<BenC> alexmoldovan: do these systems have a BIOS setting where you can set the alarm in setup?
<alexmoldovan> I'll check if some of them have, but the netbooks have a very limited BIOS options
<BenC> if you test that, and it works, then it sounds like userspace just isn't setting the alarm properly
<cking> Here is some thing that may be helpful: http://smackerelofopinion.blogspot.com/2009/08/acpi-wake-alarm-bugs.html
<BenC> alexmoldovan: it's been awhile since I messed with setting the wakeup alarm...does the script verify that the alarm was set by reading back the value?
<smb> cking, I think you also had some test script
<JFo> chrisccoulson_, given your explanation, I am not entirely sure, it sounds like a network manager issue.
<cking> it references a test script in the blog 
<alexmoldovan> the one I use is taken from chackbox : http://pastebin.ubuntu.com/397848/
<cking> http://kernel.ubuntu.com/git?p=cking/scripts/.git;a=blob;f=acpi-wakealarm-test/wakealarm.sh;h=a1674689dc49d0ffbea8f3bf76e529cfe445901c;hb=c88cec173caa995d3737437a82082152e34a46fc
<JFo> chrisccoulson_, I'll look at the bug a bit deeper
<chrisccoulson_> JFo - yeah, possibly. although I can't recreate it today ;)
<JFo> hmmm
<JFo> fun :)
<chrisccoulson_> but, i'm sure the issue i saw yesterday was not kernel related
<cking> alexmoldovan, perhaps those links may be useful for resolving your bug
<JFo> chrisccoulson_, yeah, I agree
<alexmoldovan> We want to find a way to automatize the tests in the lab even further. So far, we have to manually start up each machine from the power button.
 * BenC thought that's what interns were for ;)
<alexmoldovan> Thanks for the quick response to everyone!
<amitk> BenC, reminiscing your internships? :)
<BenC> hehe, a little grunt work never hurt anyone
<cking> well, that's the theory, anyhow
<alexmoldovan> I like it, though it would save time. So far we have ~70 laptops, but we'll have more in the future.
 * JFo suggests a long stick with a pencil taped to the end :-P
<JFo> j/k
<cking> alexmoldovan, well, checkout that blog article and see if it helps. If not, it's probably a ACPI/BIOS issue :-(
<alexmoldovan> I thought we could buy a trained monkey from a circus. After that our only worry will be buying bananas
<BenC> alexmoldovan: and banana peels on the lab floor...
<cking> not very appealing
<JFo> alexmoldovan, that and cleaning up monkey poo that he slung at you :-)
<JFo> nice one cking 
<alexmoldovan> I'd like to thank those who worked on the core i5 with graphics integrated in the CPU, we have one of those in the lad and in lucid it works flawlessly
<cnd> JFo: are you running amd64 or i386 on your mini 10?
<cking> isn't the mini 10 an Atom?
<JFo> cnd, i386
<JFo> cking, it is
<cking> which case it can only do i386
<JFo> yup
<bjf> x
<Sarvatt> apw: do you have a mmiotrace enabled kernel anywhere by any chance?
<Sarvatt> tseliot needs it to make a dump so his nva3 GPU can get supported by nouveau, they've been trying to find someone with one to do a dump for months
<apw> Sarvatt, its possible that one you are testing has it
<Sarvatt> oh let me check
<Sarvatt> sweet it does, thanks!
<apw> Sarvatt, yeah it should have ... yay
<Sarvatt> apw: what did you change in the disable FBC on i915GM/i945GM patch I sent you for this kernel you built?
<apw> Sarvatt, i didn't reformat the layout of the options at the top when removing the .has_fbc options
<apw> as that makes the end stay the same, where new options are likely to appear
<apw> reducing the likelyhood of collision with other patches
<apw> Sarvatt, second i changed the bit where it assigned the fbc functions instead of removing the bits down there, i added HAS_FBC to the surrounding if
<apw> the first change to reduce collissions if we have to carry it, the second cause it seemed safer in the future as it reminds us that bit is about FBC
<apw> Sarvatt, make sense?
<Sarvatt> i'm not sure about the change to the latter hunk, I think its the way it is to account for some other devices
<apw> though those functions are only for fbc
<apw> they are called _fbc and only called from places which check for fbc as far as i can see
<apw> all of the MOBILE things have FBC until we stop some of them
<apw> my main reason to change it was i felt we lost information, which fbc routines when with those cards
<apw> but i can be persuaded
<apw> ...
 * apw has to run to another location, will check in later
<KB1JWQ> Ooh, kernel bug!  http://pastebin.com/DZm70xam Note the end, causes ndiswrapper to die
<KB1JWQ> I'm open to suggestions besides "return the USB wireless card"
<Sarvatt> apw: guess it doesn't matter unless they add something later with has_fbc and  is_mobile and doesn't use i8xx_fbc-* for setup and is checked after that part
<Sarvatt> ironlake-m FBC support that'll be coming in any time now is checked before if (IS_GM45(dev)) so thats safe
<Sarvatt> just about to hit the 4 hour mark of stability with disabled FBC post resume and powersave=1 on my 945 \o/
#ubuntu-kernel 2010-03-20
<noaXess_netubu> hi all
#ubuntu-kernel 2010-03-21
<lamont> CIFS VFS: Unexpected lookup error -26 <-- what's that mean?
<Sarvatt> smb: mini 10v has a PIIX, but i've been using a patch on my aspire one whenever I build kernels for the past year and a half to quirk it over to AHCI mode - http://www.sarvatt.com/git/cgit.cgi/linux/commit/?h=AA1&id=b5a19a3fff2236e6f75c0b0c8931c34a45524c66
<Sarvatt> that fails spectacularly with the PATA CFA SSD's in AOA110 models though :)
<MTeck> ok... I compiled this kernel and now I can't login with sudo
<MTeck> that's odd :P
<MTecknology> Why does the generic config use NL80211_TESTMODE? The hint even says "Say N."
<MTecknology> Just curious why things like this are selected By default
<czr> hey all. was directed here by Ian_Corne from #ubuntu+1. trying to figure out the right way to get one small change from 2.6.33 to be included in the lucid kernel.
<czr> basically, hp mini 5102 (netbooks) have no connectivity with lucid kernel now. internal WLAN needs restricted drivers, and the internal NIC is not recognized by sky2-driver (there's a small patch that enables the latter at least).
<czr> what would be the most correct way of requesting such a change to the lucid kernel?
<czr> well, I've made a bug report for now: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543314
<ubot3> Malone bug 543314 in linux "no connectivity (WLAN or LAN) with HP mini 5102 (netbook)" [Undecided,New] 
<dupondje> Can some dev check https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543314 ?
<ubot3> Malone bug 543314 in linux "Frequently used NIC (Marvell Technology Group Ltd. Device 4381) not supported" [Undecided,Confirmed] 
<dupondje> eventually I can make a debdiff if needed
<czr> I volunteer for testing if necessary (I might be afk for a bit now and then though)
<dupondje> czr: i'll check if I can push a package to my ppa later today with the fix included so you can test
<czr> dupondje, cool, drop me a privmsg if you don't mind
<IMoM> can I place a working kernel and modules from another distro on an Ubuntu install? the normal kernel has "features" I don't want and my other kernel works.  anyone tried this?
<IMoM> or, is there a way to compile the Ubuntu kernel so it dosn't mess up my display ?
<BenC> IMoM: we'd much prefer figuring out what about our kernel is messing up your display
<IMoM> BenC,  so would I..  first, I am using a P3 with a VIA chipset.  the Video chipset is Chips and Technologies.  The kernel starts to load, still running through initrd before the root partition is loaded, looks like about the time the font changes where the screen locks up and starts to "white out"
<BenC> IMoM: boot without splash on the kernel command line
<BenC> sounds like an invalid mode is being set
<IMoM> that is what I do..  even single user mode
<BenC> single user mode does it as well?
<IMoM> yes.. event single user mode, I attempted to recompile the kernel on another P3 cutting out what I thought might be loading.
<BenC> IMoM: is the system still alive? do you have a CRT (non-lcd) you can connect to the system?
<IMoM> I do not have a way to get VGA on this.. :( or a CDROM.  but yes it is still alive..  I can Ctrl-Alt-Del to reboot
<IMoM> oddly enough, Fedora kernels do not work either.  but the latest CentOS does
<BenC> IMoM: if you could (blindly) do "dmesg > dmesg.txt" and "lsmod > lsmod.txt" while it is in that state, and put those files up for me to look at, we might be able to get a little further (do this while booted without splash and into single user)
<BenC> IMoM: what version of ubuntu are you using?
<IMoM> 9.04 I think..  I am attempting to install LinuxICE
<IMoM> it will take me a while to reinstall on my laptop and transfer over to the problem box
<IMoM> actually, I might be able to redirect to a serial to capture the output...
<IMoM> let me get it installed and I'll ping you..
<IMoM> won't take too long, its from a live CD
<IMoM> just confirmed 9.04, starting install process now
<BenC> IMoM: so the livecd works without problems?
<IMoM> BenC, I am not able to get a CDROM on the suspect box.  I have to install on another P3 and move the HDD over
<dupondje> whats a clean way to make an own kernel package ? fetch source / patch / make-kpkg ?
<dupondje> czr: you have 32 or 64 bit ?
<czr> dupondje, 32-bit
<IMoM> BenC, do you know if console over serial is compiled into the kernel?  
<IMoM> dosent matter..  I got network connection.  didn't think of that before
<IMoM> BenC, I was able to ssh to the box.. I have the files...  where would you like me to place them?
<IMoM> BenC, both files on in http://pastebin.ca/1848405
<_iTroll> hey guys, trying to use 2.6.33 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33/. This kernel appears to not include the aufs module, which I have on my standard karmic install, is that expected?  If so, is there a method for me to build this out of tree?
<crimsun> instead of 2.6.33.1?
<_iTroll> just the 2.6.33 based kernel 	linux-image-2.6.33-020633-generic_2.6.33-020633_i386.deb
<ali1234> _iTroll: If you re-used the existing configuration, note that Ubuntu kernels build with debugging information on, which makes the resulting kernel modules (*.ko files) much larger than they would otherwise be. To turn this off, go into "Kernel hacking"; then, under "Kernel debugging", turn OFF "Compile the kernel with debug info".
<ali1234> just noticed that on the kernel build page
<ali1234> that's why we got huge kernel packages :)
<ali1234> should read things properly :)
<_iTroll> ali1234: thanks, sounds good.  Still wondering if I can get away with getting aufs for 	linux-image-2.6.33-020633-generic_2.6.33-020633_i386.deb without rebuilding...
<ali1234> possibly but packaging it might be a pain
<_iTroll> ali1234: not so worried about the packaging for this purpose
<ali1234> having said that i'm not sure a mainline kernel will work for a livecd anyway
<_iTroll> ali1234: i've made quite a few with remastersys, it works fine.  However linux-image-2.6.33-020633-generic_2.6.33-020633_i386.deb is missing aufs.ko, which makes building a livecd with remastersys impossible
<IMoM> since BenC is busy, is there anyone else that would be able to assist with my kernel boot video problem?
<IMoM> I have the same issue with the frame buffer disabled on boot
<_iTroll> why do the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ not contain any modules in /lib/module/`uname -r`/kernel/ubuntu ?
<ali1234> because they're mainline?
<crimsun> because they're mainline kernels.
<crimsun> that is, no Ubuntu sauce.
<_iTroll> crimsun: damn, I thought they were ubuntu sauced. that would explain a lot.
<_iTroll> does there exist another source or ppa for newer ubuntu kernels?
<crimsun> the definitive sources are in git
<_iTroll> i see
<IMoM> are there any developers out there?
<crimsun> clarify, please
<IMoM> crimsun, I seem to have a kernel issue that looses video while booting
<crimsun> what graphics chipset?
<IMoM> Chips and Technologies F69000 HiQVideo
<crimsun> ugh
<IMoM> I know...
<IMoM> but still, I have no terminal access 
<IMoM> not even single user
<mjg59> Plausibly a vga16fb issue.?
<IMoM> I don't see any errors in dmesg, all seems to be detected
<IMoM> the last thing I see on the screen is an audit message right after the nForce2 chipset detection
<IMoM> I am open to any suggestions at this time, just to get something on the screen
<IMoM> mjg59, i disabled the frame buffer on the kernel boot.. no change
<BenC> IMoM: disabling splash doesn't disable framebuffer
<IMoM> no, but vga=normal nomodeset and nofb should
<IMoM> got those from searching the forums and such...
<BenC> I don't think those do what you want
<BenC> disabling framebuffer would be forcing vga16fb and vesafb to not be loaded
<BenC> IMoM: if fb was disabled, you would not get a mode switch at all, and your text mode would be unchanged through out the boot process
<IMoM> did I mistype the option?
<BenC> No, nofb doesn't seem to exist and nomodeset appears to be a no-op
<IMoM> I just tried vga=ask  and selected 0  no change
<IMoM> what about fb=false ?
<IMoM> tried it, nothing
<IMoM> is there anything else I can try?
<IMoM> short of placing another disto kernel on there...
<Sarvatt> IMoM: try blacklist=vga16fb?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543314 => is there any chance to get it into Lucid ?
<ubot3> Malone bug 543314 in linux "Frequently used NIC (Marvell Technology Group Ltd. Device 4381) not supported" [Undecided,Confirmed] 
<IMoM> Sarvatt, as a kernel boot option ?
<Sarvatt> yeah
<IMoM> nope..  same result
<johanbr> Sarvatt, is "blacklist=" implemented by an ubuntu patch? according to the upstream kernel docs, it doesn't seem to exist
<Sarvatt> initramfs-tools
<Sarvatt> see /usr/share/initramfs-tools/init and /usr/share/initramfs-tools/scripts/init-top/blacklist
<IMoM> does that suggest that it is not in the 9.04 default kernel?
<johanbr> ahhh, I see :)
<IMoM> I am preparing a known working distro kernel and going to try that..
#ubuntu-kernel 2011-03-14
<fairuz> Hi, Can I use request_irq in user space?
<apw> fairuz, don't believe there is an interface for that no
<fairuz> apw: so the irq number, how can I know it exactly? i assume that it's different for each arch?
<mjg59> fairuz: the irq number for what?
<fairuz> for PL310, a L2 cache controller
<fairuz> it says in the TRM, the irq for this device is on MA_IRQ_0
<fairuz> just wondering does it mean irq number = 0 in linux?
<fairuz> apw: is there a way to know the irq number for each irq source?
<mjg59> fairuz: Depends on your architecture
<mjg59> fairuz: There's no real mechanism for delivering IRQs to userspace - you'll need something in kernel anyway
<fairuz> mjg59: yes, i'm writing in kernel space right now
<fairuz> just dont really understand the irq number that I should put
<mjg59> fairuz: You'll need to work out how your architecture wires stuff up
<fairuz> mjg59: just need a confirmation, does irq number 0 in linux means the hard wired 0 in interrupt controller?
<mjg59> No, there can be offsets due to the architecture
<fairuz> mjg59: o
<fairuz> mjg59: ok
<mjg59> fairuz: There's already some amount of PL310-related code in the omap and tegra trees
<fairuz> mjg59: I dont found any that touches the interrupt part (or maybe it's me who's not look hard enough)
<mjg59> fairuz: What hardware are you using?
<fairuz> omap4430
<mjg59> #define OMAP44XX_IRQ_PL310                      (0 + OMAP44XX_IRQ_GIC_START)
<mjg59> Where OMAP44XX_IRQ_GIC_START is 32
<mjg59> So that's probably the IRQ you want!
<fairuz> yes!!!!
<mjg59> Look at arch/arm/plat-omap/include/plat/irqs-44xx.h
<fairuz> i doubt it, I found SPIs start at ID32 and PL310 hard wired to IRQ 0
<fairuz> mjg59: Thanks
<fairuz> mjg59: I'm still familiarise myself with all those searching in the kernel tree -.-
<fairuz> mjg59: one stupid question, in the kernel tree, any file in any include folders can be included right? e.g #include <plat/irqs-44xx.h> ?
<fairuz> regardless where the include folder is
<fairuz> :D
<mjg59> fairuz: Yes, the paths get set appropriately
 * ogasawara waves
<JFo> o/
<tgardner> ogasawara, hey there. kinda early for you, isn't it :)
<ogasawara> tgardner: according to the lil guy it's not :)
<ogasawara> tgardner: so I figure I'll start my days about now from now on
<tgardner> ogasawara, hence the smiley.
<tgardner> ogasawara, does your mumble client still work?
<ogasawara> tgardner: yep, just gotta dig for my headphones
<cooloney> ogasawara: long time no see, welcome
<ogasawara> cooloney: thanks
<cooloney> ogasawara: how's going? don't work too hard, -:)
<JFo> apw, care to have a look at bug 715330 ?
<ubot2> Launchpad bug 715330 in xserver-xorg-driver-ati "Freeze after login with KMS enabled on Radeon HD6310" [Medium,Confirmed] https://launchpad.net/bugs/715330
<JFo> you may already have a patch req for it.
<apw> JFo, looks like we already have that coming, will handle
<apw> JFo, abou ?
<apw> about ?
 * apw slaps his '' key
<apw> grrrr
<JFo> heh
 * ogasawara back in 20min
<JFo> <-grabbing lunch
<tseliot> mjg59: are you around?
<mjg59> tseliot: Hi
<tseliot> mjg59: hi. Do you know how to debug the lack of a backlight device after backlight_device_register() succeeds? This is with 2.6.32
<mjg59> No
<mjg59> If that's succeeded then you should have a device
<mjg59> When you say it's succeeded, you know it returns ERR_PTR and not NULL on error, right?
<tseliot> mjg59: that's what I was about to ask
<mjg59> So if you're just checking against NULL then you'll think you've succeeded when in fact you've failed
<tseliot> mjg59: so, shall I test it with "if (IS_ERR(backlight_device))" ?
<mjg59> Yes
<tseliot> mjg59: well, that's the way the poulsbo driver checks it if(backlight_device), that is
<tseliot> I guess it's ok, as it's psb...
<tseliot> ;)
<tseliot> mjg59: so my next question would be, how would you debug a failure there?
<tseliot> mjg59: is there any documentation I can have a look at?
<mjg59> tseliot: drivers/video/backlight/backlight.c
<mjg59> You should be able to work it out from the failure cases there
<tseliot> mjg59: right. Thanks a lot
<apw> tgardner, indeed ... finger trouble
<tgardner> apw, do you remember if we decided mpt's macbook had a drive hardware issue?
<apw> i think we decided it was possible, but we had no evidence
<apw> we asked him to collect something when it happened again
<tgardner> apw, k
<apw> tgardner, though waht i now forget
<tgardner> maybe he'll remember
<Kano> hi, why is CONFIG_HZ_250 for 32 bit and CONFIG_HZ_100 for 64 bit?
<mjg59> I think a better question is arguably why they're not both HZ_1000
<apw> mjg59, cause that costs you 10% of performance
<Kano> sure,best would be 1000 hz for both
<apw> actaully 10-17% depending on load
<mjg59> apw: It's very dependent on what your definition of performance is :)
<apw> mjg59, indeed, overall throughput in this context
<Kano> but at least it should be the same for 32+64 bit or not?
<apw> Kano, no it was a deliberate split
<Kano> how to change the config to update the files in debian.master?
<apw> Kano, in normally use vi to change the option i want, then use updateconfigs target to propogate
<Kano> ah
<apw> Kano, the source is all included in the tree
<Kano> will check it out
<davek> hello kernel folk
<davek> does anyone know the estimated release of ubuntu using 2.6.38 stable?
<apw> davek, we are waiting on final from linus, w
<Kano> there is no .38 stable kernel yet
<apw> though i would expect it would be in the next day or two
<davek> okay
<davek> how long would it take after release?
<apw> thoguh we are struggling with compiler issues
<davek> for ubuntu to add it?  (im kindof a noob here)
<davek> i recently purchased a very new motherboard and am looking forward to support for drivers within 2.6.38
<apw> davek, if they arn't in the current kernels based on the 38-rcN releases you are likely not goting to get it in any furhter kernel we upload
<davek> from what i read there should be Zacate support in there
<davek> so would one run Natty to get this kernel, or could i do a trick with Maverick to install it?
<davek> (in the future)
<apw> davek, well they arn't adding any new features to .38 everything is bug fixes
<apw> so if a ntty kernel doesn't have what you want now, its not likely to later
<davek> okay
<davek> im running Maverick 10.10 presently
<davek> will that pick up 2.6.38 too? 
<apw> we do backports for lucid, but you can hand install them on maverick.  they won't update on maverick tho.
<tgardner> davek, you can test also natty by adding this PPA: https://launchpad.net/~kernel-ppa/+archive/pre-proposed?field.series_filter=natty
<davek> okay..  wow thanks for the response guys
<davek> you rock
<davek> thanks apw and tgardner
 * tgardner --> lunch
<Kano> bye
 * jjohansen -> lunch
<rupert_millard> Hi. It's my first time ever on IRC! On my new laptop, I am getting an intermittent kernel panic within about a minute of powering up. I installed "linux-crashdump" so I can give you a proper bug report, but although it seems to dump a load of data on the panic, I can't find it anywhere when I boot up. So I've got two problems - what (is/am I doing) wrong with linux-crashdump, and how do I give you the best bug report I can? I do have 
<rupert_millard> a photograph of the screen showing the panic.	
<charlie-tca> rupert_millard: You can file a bug by opening a terminal and typing "ubuntu-bug linux" without the quotes
<rupert_millard> yes but is that very useful to you?
<rupert_millard> i really wanted to include a dump, but linux-crashdump doesn't seem to work for me
<charlie-tca> ubuntu-bug provides most of the needed logs, and is a very useful method of filing bugs
<rupert_millard> ok
<rupert_millard> charlie-tca: what's the point of linux-crashdump then?
<charlie-tca> You can look in /var/log for the linux-crashdump, but I don't know if it will be there
<rupert_millard> charlie-tca: should I file a bug against it too?
<charlie-tca> rupert_millard: no idea, I don't know what it is, myself
<charlie-tca> Is there anything in /usr/share/docs that explain it?
<rupert_millard> charlie-tca: https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
<charlie-tca> The LKCD utility is not designed to gather helpful information in the case of a hardware caused panic or a segment violation
<rupert_millard> what constitutes a hardware caused panic?
<charlie-tca> ubuntu-bug should pick it up
<rupert_millard> well my computer completely locked up - i had to power cycle it
<charlie-tca> hm, maybe there is a crash log in /var/crash ?
<rupert_millard> there's no /var/crash directory
<charlie-tca> then there is no crash report available. 
<Zelozelos> anyone wanna help out w gwinwrap, im trying to get the videos to play again. the -wid option is causing an error 
<charlie-tca> Perhaps it is panicing before it can save it
<rupert_millard> well since installing linux-crash, there is a load of activity - the second kernel seems to be doing something
<rupert_millard> i think init might be starting swap up before kdump has a chance to inspect that partition for a dump
 * jjohansen heads out for a bit, back on later
#ubuntu-kernel 2011-03-15
<fairuz> Hi, morning. I have a question about interrupt handler. In my current interrupt handler, I disable the interrupt, do the treatment and reenable the interrupt. Is that the correct way to do it? Because it didn't work. It just recall the handler function again and again.
<diwic> fairuz, afaik interrupts are already disabled in an interrupt handler, so don't reenable them.
<fairuz> diwic: so I dont need to disable and reenable them? how about clearing interrupt flag?
<diwic> fairuz, no you don't. I'm not an expert but I'd say that if there is some driver magic you need to do to tell the device that the interrupt has been handled, that should be done in your handler.
<jjohansen> not needed
<jjohansen> the kernel handles the disabling/reenabling of interrupts
<jjohansen> when you register your handler you specify the type
<jjohansen> whether all interrupts are disabled on the current processor, or just the one irq while your interrupt is being handled
<jjohansen> your handler will need to set any bits on the hardware that may need to be twiddled because of the interrupt
<jjohansen> and when done you return IRQ_HANDLED if you handled the interrupt
<jjohansen> the LDD3 has a pretty good description of all this in chapter10
<diwic> jjohansen, just as I thought then. Thanks.
<jjohansen> diwic: yep your right, the kernel responds to the apic but the driver has to do any extra device specific twiddling
<fairuz> jjohansen: diwic: ok i will try it and tell you guys the outcome
<fairuz> request_irq(OMAP44XX_IRQ_PL310, pl310_irq_handler, IRQF_DISABLED, "pl310", NULL) as for my interrupt install, looks ok to you guys?
<bullgard> After Maverick coldstarts it writes to the virtual console 1 : "System information as of Sat Mar 12 15:51:57 CET 2011. System load, Temperature, Usage of /home, Processes, Memory Usage, Users logged in, Swap usage, IP address for eth0. -- What program prints this information?
<jjohansen> fairuz: for what little I know of what your doing it looks reasonable
<fairuz> jjohansen: I still need to clear the interrupt flag?
<jjohansen> fairuz: if the hardware has an specific bits to twiddle you will need to handle that, the kernel with ACK the apic and handle enabling/disabling of interrupts
<jjohansen> so no you do not handle the interrupt flag
<fairuz> jjohansen: so basically i just do what i want the handler to do and thats all? no extra code..that what we call magic
<jjohansen> fairuz: pretty much
<fairuz> jjohansen: no luck for me..i got this [  612.033447] BUG: soft lockup - CPU#0 stuck for 61s! [migration/0:4]
<fairuz> [  612.040313] BUG: soft lockup - CPU#1 stuck for 61s! [irqbalance:827]
<fairuz> and the kernel basically freezes
<jjohansen> fairuz: are you taking any locks in your handler?
<fairuz> nope, i just put a line of code (printk)
<fairuz> jjohansen: irqreturn_t pl310_irq_handler(int irq, void *dev_id, struct pt_regs *regs){
<fairuz> 	printk(KERN_INFO "pl310 : interrupt 0x%x!\n", readl(pl310_base + L2X0_EVENT_CNT1_VAL));
<fairuz> 	return IRQ_HANDLED;
<fairuz> }
<fairuz> jjohansen: so maybe the magic can't be applied here or something like that? 
<jjohansen> fairuz: hrmm, start by disabling the printk see if you get the lockup with just an empty handler
<fairuz> jjohansen: just tried with an empty handler and still no luck
<fairuz> jjohansen: got the same lockup message
<fairuz> jjohansen: what's the soft lockup anyway? 
<apw> fairuz, that is telling you that the thread in question is not completing in a timly manner
<apw> normally cause something is in the way
<jjohansen> fairuz: you are likely going to need some extra flags in requesting your irq
<jjohansen> there are two other possibilities, wrong interrupt number messing things up for some reason, or you need to twiddle something on the device because not doing so is messing something up
<jjohansen> arm socs are a little different than x86, so I am not sure there
<jjohansen> but the kernel should be reenabling interrupts for you when your handler exits
<fairuz> jjohansen: ok i will check first on the interrupt number. Just to confirm it
<jjohansen> fairuz: I am thinking the second case is more likely, maybe the device will reraise the interrupt until some bit is twiddled so the kernel never gets to leave the interrupt handling code
<fairuz> jjohansen: i will look on it too, i will start by modifying one bit of the interrupt registers
<fairuz> jjohansen: apw: I think I found the culprit. Apparently, the counter (the hardware that I'm using) does not reset itself if it overflowed. So the value if always 0xFFFFFFFF and maybe it's that who always regenerate the interruption. 
<jjohansen> fairuz: sounds likely
<jjohansen> rebooting
<fairuz> jjohansen: it works now. thanks
<jjohansen> fairuz: glad to hear its working for you
<jjohansen> rebooting
<ogasawara> morning
<bullgard> After Maverick coldstarts, it writes to the virtual console 1 : "System information as of Sat Mar 12 15:51:57 CET 2011. System load, Temperature, Usage of /home, Processes, Memory Usage, Users logged in, Swap usage, IP address for eth0. -- What program prints this information?
<soren> landscpape-sysinfo
<soren> err...
<soren> landscape-sysinf
<soren> landscape-sysinfo, even.
<soren> Wow. That was difficult.
<bullgard> soren: Thank you very much for your help.
<sladen> Hello all, I'm trying to answer this question, which has been outstanding for a little while:
<sladen> http://askubuntu.com/questions/28047/where-can-i-get-the-natty-kernel-config-file/30486#30486
<sladen> so far I've pointed them towards /boot/config-`uname -r`
<sladen> but now re-reading they're asking for an online location of the Kconfigs
<sladen> should I post something like  http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=blob;f=arch/x86/configs/i386_defconfig;h=6f9872658dd2d66e80d8025eb7f8c40ee86b958f;hb=HEAD
<jjohansen> sladen: that will work, or they can download the source and reconstruct it
<sladen> jjohansen: yeah, they're specifically (from re-reading) asking for something that doesn't need downloading the whole lot
<smb> I would say the git is not that good. It is not the config used
<smb> but the parts that get assembled
<jjohansen> right, you have to reconstruct
<sladen> smb: presumably "the config" is only constructed dynamically at the point of build
<smb> sladen, correct
<roadmr> Hey all! I used to be able to get X memory usage info from /proc/dri/0/gem_objects, but as of kernel 2.6.38-6 (Natty recent dailies) it's gone - where can I get that information now? 
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
 * ogasawara back in 20min
<fairuz> what is the difference between ioctl call and a normal fwrite/write for communication between user space and kernel space
<JFo> bjf, we have an hour, yes?
<bjf> JFo, yes
<JFo> think I want to address my need for lunch :)
<JFo> thank you sir
<JFo> bbiab
<Kano> hi, why is there no .38 final kernel in the mainline dir only .37.4?
<Kano> hmm now it is there
<apw> fairuz, they both serve to carry data across the kernel boundary, but write is intended to be used for payload data, and ioctl for control data.  overall though we sometimes use additional files to use write to carry control information etc.  its about which is most natural for the use case
<roadmr> Sorry for asking again - I used to be able to get X memory usage info from /proc/dri/0/gem_objects, but as of kernel 2.6.38-6 (Natty recent dailies) it's gone - where can I get that information now? 
<bjf> ##
<bjf> ## Kernel team meeting in 20 minutes
<bjf> ##
 * JFo preps his notes
<JayFo> well that is good to know
<JayFo> if I pull the USB dongle for my headset out, my machine poops itself
<vanhoof> JFo: does it panic?
<JFo> dunno
<vanhoof> JFo: I want to say I saw Cody having the same problem
<vanhoof> JFo: theres a bug somewhere :)
<JFo> Logitech dongle
 * JFo will grab dmesg after the meeting
<apw> JFo, which kernel, latest one /
<JFo> this is a MAverick machine
<apw> oh :)
<JFo> the one I am working from
<JFo> :)
 * JFo eats the dog food on his nettop
<roadmr> Actually, where did /proc/dri go?? 
<JFo> but I haven't seen that on there
<vanhoof> JFo: https://launchpad.net/bugs/715318
<ubot2> Launchpad bug 715318 in linux "Disconnecting USB headset while audio playing results in kernel panic" [Undecided,Fix released]
<apw> roadmr, on which release? seems tob be there on my natty box
<JFo> this is without audio playing
<JFo> but may be the same
<JFo> thx vanhoof :)
<apw> JFo, if mumble is runinng then 'audio input is recording' all the time
<vanhoof> JFo: np
<JFo> ah hah
<JFo> so that may be exactly it
<roadmr> apw: 2.6.38-5.32 has no /proc/dri, on 2.6.38-6.34 it's there, but /proc/dri/0/gem_objects is not <- this is what I ultimately need
<JFo> I didn't think of that
<roadmr> apw: so I apologize, you're right that /proc/dri is there in latest kernels
<apw> roadmr, they appeat to be in the debugfs inforamtions
<apw> roadmr, possibly the information you are looking for is now in /sys/kernel/debug/dri/*/i915_gem_objects
<roadmr> apw: oh yes, /sys/kernel/debug/dri/0/i915_gem_objects, thanks - is that likely to work on non-intel chipsets? like with nvidia or ati gpus?
<apw> roadmr, no idea, not with an i915_ prefix ... you'd need to see if its even the same info or not
 * smb would highly doubt that
<apw> roadmr, according to the commit that moved the file to i915 specific the stats were wrong and missleading for others anyhow
<apw> commit 73aa808f10effc280e6eb70267314542a7c29426
<apw> Author: Chris Wilson <chris@chris-wilson.co.uk>
<apw> Date:   Thu Sep 30 11:46:12 2010 +0100
<apw>     drm: Move the GTT accounting to i915
<apw>     
<apw>     Only drm/i915 does the bookkeeping that makes the information useful,
<roadmr> apw: that commit info is really useful, thanks !! it'll let me redefine the test that relied on gem_objects
<roadmr> I really appreciate it, thanks :)
<wendar> Bug #735601 (requested by apw)
<ubot2> Launchpad bug 735601 in linux "[STAGING] Eee PC 1015PEM unstable on 2.6.38-6-generic" [Undecided,New] https://launchpad.net/bugs/735601
<apw> wendar, any idea what 'crap' you have loadded ?
<wendar> apw: it's a pretty bare install
<wendar> started as a fresh Maverick 10.10 in Dec
<apw> wendar, sorry your panic is taineded 'crap' which means you have staging drivers loaded
<wendar> what would fall under 'crap'? Broadcom wireless drivers?
<apw> wendar, the proprietry drivers taint you 'P' which you are also so tainted
<wendar> where would I look for 'crap'?
<apw> wendar, i think you have something odd going on
<apw> as you have wl(P) and brcm80211(C) both listed in your modules
<wendar> that would be nice
<wendar> (if it's unique to this install)
<apw> hmmm mine is the same and no issues.
<apw> wendar, ok ... so is it always in intel_idle when it tanks ?  see the RIP: line in your dump
<wendar> I'm not sure (haven't been taking screenshots each time), but I suspect so
<apw> wendar, if that is a common one you could try booting with intel_idle.max_cstate=0 a
<apw> and see if that helps
<wendar> do you recommend adding that to /etc/default/grub?
<apw> wendar, well if it works you will only be booting once more forever :)  but likely so
<wendar> okay, will try, thanks
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-22 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<ogasawara> apw, bjf: intel patsburg device id patch pushed to natty master-next
<bjf> ogasawara, thanks
<apw> ogasawara, AceLan_ 
<apw> ogasawara, ack even
<apw> ogasawara, drop after .38 :)  fixed it up
<ogasawara> apw: bah, thanks
 * apw is about to upload a .38 final kernel, anyone got anything else they think is pending for natty
<smb> apw, There should be a fix for the fix (polarity for irq0) but that seems still underway and not in upstream
<apw> smb, got any pointers to that?
<smb> apw, There was a mail submitted which I could fw to you
<smb> apw, sent
<apw> smb thanks
<cking> smb, that was a quick turnaround, - was that a fix from AMD
<smb> cking, Yep, someone on linux-acpi posted his regression and Andreas fixed it up
<smb> cking, So yes, AMD
<cking> yay
<apw> smb, is there any discussion that that is not final?  it sounds pretty ready
<smb> apw, Well, it was only tested to solve the regression
<apw> smb, whats your recommendation, in or out for the next upload ...
<smb> apw, I would rather tend to in. There was some more xplanation on the linux-acpi thread and is seemed good. Without it you got a regression of fans being always on
<apw> smb, OUCH yep i'll suck that up me thinks
<mjg59> Turns out HP still can't write firmware
<mjg59> This bug's been there since *2005*
<smb> Some cannot set the irq override correctly the other mess up with the polarity. Writing firmware that complies to the acpi spec seems really hard
<apw> mjg59, why does that not supprise me
<mjg59> apw: They have code that explicitly reads the pin 2 config from the apic and then changes the thermal trippoints
<apw> nnng
 * apw decides the right to bear arms may have its uses
<cking> heh
<mjg59> apw: Amazingly, they're considerate enough to set the trip temperature to the minimum temperature that Windows 98 will accept without red screening
<cking> mjg59, so you refer to "they have code that explicitly reads the pin 2 config" - you disassembled the firmware to find this out?
<mjg59> In the ACPI table, yeah
<mjg59> So less heroic
<cking> oh - that's not so bad ;-)
<apw> mearly enough to make you need a shower
<cking> if I got a dollar for each DSDT I read...
<apw> cking, you might be able to afford half your extension ?
<kamal> cking: ... the DSDT would be buggy and you'd only end up getting $0.10.
<cking> heh
<JFo> .10 more than he had :)
<bjf> apw, your push to talk appears to be stuck
<cking> it's very enlightening
 * jjohansen -> lunch
<apw> bjf, yeah its not so much stuck as i forget that skype doesn't need it :/
<bjf> apw, hehe
<apw> not a conversation i wanted to be having at all, let alone in public :)
<kamal> apw: approximately when will the natty 2.6.38 final kernel be pushed to master?  (today or not today?)
<apw> kamal, oh whats there (master-next) is at most one commit short i think, once my builds complete i'll be pushing it to master
<kamal> apw: oh I'll just wait for the "official" master push then ... thanks.
<TeTeT> apw: will the new version also make it to the lucid backports ppa?
<apw> TeTeT, yep, it should, the last one didn't make it cause of compiler issues
<TeTeT> apw: great :) Eager to test it. Even though on desktop machines ...
<jbicha> hi I was trying to troubleshoot my laptop's hotkeys, several of which don't work but I can't even get the scankey produced to show up
<sforshee> jbicha, it depends on the specific driver whether or not scancodes are reported
<sforshee> do you happen to know what driver is used for your machine's hotkeys ?
<jbicha> sudo /lib/udev/findkeyboards reports AT keyboard: input/event3
<sforshee> does anything get reported for your working hotkeys on that device ?
<jbicha> yes, I get codes when I do sudo /lib/udev/keymap -i input/event3
<sforshee> but nothing at all for the non-working keys? Or are the keycodes just wrong?
<jbicha> I get nothing for the "media player" button and I get Alt and F7 for the brightness-up button for instance
<jbicha> *I mean Fn and F7
<jbicha> oops, I get nothing for the non-working Fn combinations either
<sforshee> I'm a little confused -- do the media player and brightness up buttons work or not ?
<sforshee> sometimes there's a secondary device for hotkeys, and sometimes the hotkeys even show up on two different devices
<jbicha> no, they don't work and I haven't been able to figure out the scankey they produce
<sforshee> jbicha, what machine is this ?
<jbicha> Toshiba Satellite L305
<sforshee> jbicha, does 'lsmod | grep toshiba_acpi' give anything ?
<jbicha> sforshee: no
<sforshee> hrm, that's funny, because the AT keyboard driver seems to normally emit scancodes
<jbicha> should I try to enable toshiba_acpi ?
<sforshee> no, I just suspected that's where the key events were coming from
<sforshee> this is probably a bit much to debug over irc, I'd suggest opening a bug in launchpad if you want to pursue further
<sforshee> one other thing you could try is grepping dmesg for lines containing "Unknown key", which the AT keyboard driver will sometimes produce
<sforshee> jbicha, iirc keymap ignores scancode without a keycode, so that might actually be why you don't see anything
<sforshee> input-events (from the input-utils package) dumps all the events from the device, so it might be more informative
<jbicha> dmesg hasn't produced any output for keypress and input-events doesn't show anything for the nonworking keys either
<sforshee> okay, filing a bug is probably your best bet then
<jbicha> thanks for your help, filed as bug 735756
<ubot2> Launchpad bug 735756 in linux "Toshia Satellite L305 hotkeys not working" [Undecided,New] https://launchpad.net/bugs/735756
<lool> apw: Hey, I was wondering whether you plan to switch to the upstream linux tarball for future linux uploads now that .38 is released upstream?
#ubuntu-kernel 2011-03-16
<Kano> hi, is the linux-meta 7 package already done
<fairuz> HI, morning
<apw> loic yes, we should be using orig from now, i didn't bother for the last upload for expediency
<fairuz> Hi, I do #include <plat/omap44xx.h> in kernel space and it recognizes it, but it did't recognizes it in user space. Is it normal ? 
<apw> fairuz, yep, those are kernel headers, only a select few are exported to userspace in the linux-libc-dev package and they are primarily for libc use
<fairuz> apw: ok thanks
<ppisati> ericm|ubuntu: ping
<ericm|ubuntu> ppisati, pong
<ericm|ubuntu> ppisati, what's up dude?
<ppisati> ericm|ubuntu: i can't get any audio out of mvl-dove, did you?
<ericm|ubuntu> ppisati, I used to - but not really sure if that's still the case
<ppisati> ericm|ubuntu: uhmmm...
<ppisati> ericm|ubuntu: i mean, a vanilla 10.04 installation was enopugh to get sound? or do i have to tweak anything?
<ericm|ubuntu> ppisati, I don't think so
<ericm|ubuntu> ppisati, wait
<ericm|ubuntu> ppisati, I seem to remember a alsamixer thing to get it work but I'm not really sure
<ericm|ubuntu> ppisati, did you check the gnome-volume-control?
<ppisati> ericm|ubuntu: volemu control seems ok
<ericm|ubuntu> ppisati, hrm.... did you do a search on LP?
<ppisati> ericm|ubuntu: i'm hoovering all the mvl-dove bugs
<ppisati> ericm|ubuntu: there are 2 audio-related bugs for mvl-dove
<ppisati> ericm|ubuntu: the first is about the headphone not recognized (while in a LSP update there was specific mention about it)
<ppisati> ericm|ubuntu: the second is about an alsa config
<ppisati> wait...
<ppisati> ericm|ubuntu: headphones: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/551249
<ubot2> Launchpad bug 551249 in linux-mvl-dove "Audio driver fails to detect Headphone insertion/removal." [Wishlist,Confirmed]
<ppisati> ericm|ubuntu: alsa config: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/651281
<ubot2> Launchpad bug 651281 in linux-mvl-dove "Need alsa configuration files for Dove A0 SOC platform" [Undecided,New]
<ericm|ubuntu> ppisati, the 2nd one is suspicious
<ppisati> the second one, looks like you need a specific config file to get any audio out of this board
<ppisati> yep
<ericm|ubuntu> ppisati, I didn't really ever check the audio difference between X0 and A0
<ppisati> but since i _guess_ you (i mean the mvl-dove team) tested the audio
<ppisati> ahhh
<ppisati> so you did all the stuff on X0?
<ppisati> and i got an A0, right?
<Kano> hi, how to disable the modules check globally
<apw> Kano, add the ignore.modules file
<apw> to the abi for the flavour, see the check-modules script
<Kano> and globally?
<Kano> the funny thing is, i only increased the version and changed the hz value
<Kano> but it failed with modules
<Kano> also it still builds too much
<Kano> http://paste.debian.net/110848
<Kano> it builds tools and i dont want tools
<Kano> i already added a skip abi check
<Kano> did i forget something after increasing the version with dch -lxxx
<Kano> as there are no modules for 7.35 only 6.34
<Kano> how to increase version correctly?
<Kano> hmm there is a skipmodule too
<apw> when you start a new release you need to provide abi information for the previous version
<Kano> how to do that?
<apw> this is all documented in how to bump the abi information
<apw> the getabis script handles the body of the work
<Kano> you call that manually?
<apw> after the builds complete yes, you run that and it sucks down the abi info from the archive
<apw> then that gets commited to allow checking of following builds
<apw> but you have been building kernels for years, so not sure why this is a new problem for you
<Kano> but that means you have to build it before you can put it into pbuilder
<Kano> well the last year i just used your mainline kernels
<Kano> i just began with .38rc6 again recompiling your kernels because i needed aufs
<apw> no cause you are always using the previous builds stuff
<apw> the abi is never for the new kernel, its for the one before, which by definition is already built
<Kano> your getabis script tries to dl from a server
<Kano> i think i just try skipmodule in arch.mk
<Kano> the last kernel with heavy mods i which i compiled using pbuilder was 3 years ago. using the custom flavour options
<apw> Kano, yep but it shows you how the abi stuff is meant to extract the info if you care.  otherwise you can skip it
<Kano> is there a linux-meta 38-7?
<lool> apw: Oy
<lool> apw: Re: armhf
<lool> apw: Essentially, this is the future for ARM support; this effort started perhaps about 6 months ago from a Genesi initiative using first Ubuntu armel and then introducing a real Debian armhf port, which is not an official Debian port yet but will eventually be one
<lool> apw: On the Ubuntu / Linaro side, we want to eventually switch to this port instead of armel as it provides strictly better performance, but it has to be bootstrapped as it changes ABI
<lool> apw: We had a good UDS session on this port but we were lacking buildds for very long
<apw> lool, ok so when are we going to need this support, natty or O ?
<lool> Now, I think we might have buildds, but it's clear that we wont have time to bootstrap armhf for Ubuntu before 11.04, still we're trying to merge as many support patches now rather than later
<apw> oneiric (sp?)
<lool> apw: I've just asked a couple of days ago for a FFE to merge sourceful fixes in the relevant packages
<lool> apw: IOW, we're trying to have the packages be buildable with -aarmhf, but we don't expect Ubuntu to carry binaries this cycle
<apw> lool, ok so i should wait for the FFE to be approved before merging them?  otherwise they ahve no operational effect in theory at least
<lool> Most of the time, it's a matter of either fixing rules/control to check for both armel and armhf rather than just armhf, or to fix upstream configures which might not support the new triplet (arm-linux-gnueabihf instead of just arm-linux-gnueabi for armel)
<lool> apw: You could opt to wait for the FFE, or decide that they are unintrusive  :-)  if you find there is a chance for breakage, then maybe wait for the FFE
<apw> lool ok, will have a look see if they work ok in my cross env here
<lool> apw: What's the best to rev one patch?  I'd like to update armhf.mk to also skipabi=true and skipmodules=true, but it feels heavy to resend the series just for that
<apw> lool do you need to do that, can't you just include the ignore/ignore.modules in the abi directory
<apw> when you inject the configs etc
<lool> apw: I decided to not add any config or ABI data as to not pollute the kernel tree with armhf churn
<lool> that is, I figured you wouldn't want to see a lot of armhf in the diff, when you are not actually building these packages
<apw> right, but you must be injecting the configs etc when you build, you could just inject those at the same time?
<apw> yeah you are spot on there
<lool> I'm not building any kernel ATM; I'm bootstrapping so I just need libc-dev
<apw> ok then just send the skip stuf as anohter patch, make make it a reply to the one it need squishing into
<apw> and i'll squish it when applying
<lool> apw: Ah one important thing I should also mention: the different is only userspace ABI; it's the same kernel ABI, so that armel kernels can run an armhf userspace and vice-versa
<lool> *difference
<apw> right, as there is no fp in the kernel (in theory at least)
<Kano> apw: you tagged the linux-meta but the package is not created?
<apw> Kano, not created ?
<Kano> or not uploaded or whatever
<apw> right, you cannot upload the meta until all the builds are completed and accepted by an AA
<apw> else the architecture becomes uninstallable, and cd builds fail, and kernels get de-installed from systems
<apw> but you run a debian based distro, you must have the same problem
<Kano> sure,but i upload all the same time
<Kano> i upload prebuild packages
<Kano> usually i fetch the packages from ubuntu which are not critical
<apw> that leave dist-upgraders at risk of partial installs, and most resoltions are fatal for meta packages
<Kano> i decide when i update the index
<apw> you have an advantage i don't have then, hense its 
<apw> not uploaded in ubuntu
<Kano> well you only need to upload source
<apw> i can't upload the source, as that will build and upload the binaries, and they are not held for AA review
<Kano> http://kanotix.com/files/hellfire/ubuntu/ubuntu-kernel-build-only-generic.txt
<apw> so they will swan past the binaries, and leave us in a heap
<apw> which is why we don't do it
<apw> we don't do our work in this order to make it hard for you, we do it cause it is right for our users
<Kano> oh no, i got past the modules error but now: http://paste.debian.net/110856
<Kano> dpkg-gencontrol: error: install new files list file: No such file or directory
<Kano> what is that
<apw> no idea, never seen that phase forget in all the builds i've done, and its a lot
<Kano> i use kernel-wedge from ubuntu but rest is debian
<Kano> but it has got an error, maybe it is related
<Kano> http://paste.debian.net/110857
<apw> the error is a rename failure, renaming a file it made from foo.new to foo 
<apw> not something i'd expect we'd trigger really
<Kano> do you get this error too?
<apw> Kano, those are normal, they are related to empty lines IIRC
<apw> and yes we get them
<apw> i'd check you arn't out of inodes or something
<apw> rename("$fileslistfile.new", $fileslistfile) || syserr(_g("install new files list file"));
<apw> is what barfed on you
<Kano> 17 gb free just for generic+generic-pae
<Kano> http://kanotix.com/files/hellfire/ubuntu/kanotix-kernel-changes.txt
<Kano> is there something major missing?
<Kano> those are changes against your package
<Kano> first i use the other script to disable parts of the build
<fairuz> I do request_irq in kernel space, but is it possible to have the handler code in user space?
<mjg59> fairuz: No
<fairuz> mjg59: ok
<mjg59> fairuz: I mean, you could generate a netlink event or something on interrupt and have userspace do something as a result
<mjg59> But that's going to end up racy
<fairuz> mjg59: yup, I will stick on kernel space then
<fairuz> whats writel or readl equivalent in user space?
<apw> lool, this nls_cp437 patch seems to have an incorrect bug number in it
<lool> apw: indeed, should be 732046
<lool> I'll blame it on Chromium's paste buffer handling  :-P
<lool> I wonder where I picked the other bug id from, it's private
<lool> apw: Do you want me to resend?
<soren> lool: * (drop after 2.6.38) ahci: AHCI mode SATA patch for Intel Patsburg SATA RAID controller - LP: #735240
<soren> lool: From an older changelog entry.
<lool> Ah, right, I probably forgot to update it after pasting then, thanks
<soren> np
<smoser> lool, thank you for pushing on bug 735240
<ubot2> smoser: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/735240)
<lool> smoser: np
<apw> lool, nope i can correct it now i know, thanks
<smoser> i think it would be quite generally useful if kernel build process created a -extra-modules with the non-whitelisted files whenever the inclusion-list was used
<apw> bug #732046
<ubot2> Launchpad bug 732046 in linux "Missing filesystem modules in -virtual package" [Undecided,Won't fix] https://launchpad.net/bugs/732046
<lool> smoser: I agree with Stefan that the packaging changes aren't trivial, but this would also be my preference
<apw> lool and how did you set linux back to new, without natty going back to new ... you've unconjoined the pair somehow
<lool> ?
<lool> Oh
<lool> I think you can do that as soon as the development task is closed
<smoser> and generally, that list culd use some attention (i am probably at least partially responsible for doing so)... it has net/wireless/* in it.
<lool> For some value of the bug field
<apw> lool well you learn something new and odd about launchpad every day
 * ogasawara back in 20min
 * apw giggles at ogasawara 
<apw> smoser, so it does ... hrm ... probabally something for O now
<smoser> yeah, i dont really care, but the mac80211 is also there... porobably not that important :)
<smoser> i suppose we could do a session on it in uds-o or at least you and smb and i and jj-afk could discuss
<fairuz> Hi, all variables in a kernel module will stay until rmmod is made?
<apw> fairuz, a module can rely on its memory existing until the end of its destructor
<fairuz> apw: destructor == module_exit?
<apw> fairuz, believe so yes
<fairuz> apw: thanks
<smb> smoser, apw sounds reasonable... hopefully we will have again any sensible layout for sessions
 * apw overlaps with tgardner :)
 * smb tries to picture that...
<tgardner> apw, uh, sorry. I was just grinding through the list
<apw> tgardner, nope no problem, you carry on
<apw> tgardner, i am only seeing the fat change, not the others, yet email says its pushed?
<tgardner> apw, which changes are missing?
<apw> tgardner, oh ignore that, they moved, and i confused two threads
<apw> tgardner, i'll handle updating ubuntu-debian, if thats ok, i want to resync them anyhow
<tgardner> apw, I figured you would.
<apw> tgardner, i think lool wants this stuff in natty so they can do early testing, much as we have already elsewhere
<lool> apw: Should I have sent a series against ubuntu-debian instead?
<lool> I vaguely remembered the existence of this repo, but wasn't quite sure which one to send against
<apw> lool, nope, its half and half for your use case
<apw> i'm sorting it out now
<tgardner> ppisati, I was just chatting with ikepanhc about OEM mvl-dove kernels. He's still consuming CVEs and stable updates from the distro kernel. could add 'rebase to master' to your todo list for mvl-dove and send me a pull request?
<ikepanhc> tgardner: IIRC the mvl-dove lucid branch is maintained for 18mo?
<ppisati> tgardner: isn't the -proposed kernel already rebased against the lastest-ish?
<tgardner> ppisati, hang on a sec. otp.
<tgardner> ppisati, I can't remember, but I think its a ways behind. I'm sure you can figure it out.
<tgardner> ikepanhc, the mvl-dove branch only gets 18mo worth of love
<ppisati> tgardner: anyway, ok, i'll do that
<ikepanhc> tgardner: ok, I need to inform PM this
 * apw_ is off the sir, internet in a heap
<tgardner> apw: did you mean "off the air" ?
<apw_> indeed, touch screns 
<apw_> make lousy keyboards
<bjf> ogasawara, you got a sec ? 
<ogasawara> bjf: yep
<bjf> ogasawara, i just uploaded a linux-ubuntu-modules-2.6.24 to the canonical-kernel-team ppa
<bjf> ogasawara, the builds for it all failed: Missing build dependencies: linux-headers-2.6.24-29-generic
<bjf> ogasawara, however -29 is in proposed
<bjf> ogasawara, i'm don't get it
 * ogasawara tries to remember if it'll pull build deps from -proposed
<apw_> no it won't it is security only
 * smb thinks only updates/security and ppa itself
<apw_> one reason to not delete kernrl till all drps built
<apw_> remember that is why wr have the ppa, to build against security only
 * tgardner is enjoying apw's gibbers typing
<apw_> grrrr
<apw_> bjf you may be able to copy kernel back from proposed
<bjf> apw_, ogasawara ok, so i'm getting feedback that the hardy kernel in -proposed can't be installed due to ubmet dependencies. 'linux-ubuntu-modules-2.6.24-29'
<tgardner> apw, bjf: why don't I just upload LUM to the archive?
<bjf> apw_, ogasawara so i uploaded a new LUM to fix this issue
<bjf> tgardner, you want my src pkg ?
<apw_> but if kernel not still in ppa, it wont build
<tgardner> bjf, I'll just build from the repo. I assume its what you want?
<apw_> assume someone cleaned itvout
<apw_> we needcit built in ppa
<tgardner> apw:  2.6.24-29.87 is in -proposed. LUM should build against that OK.
<bjf> tgardner, will that work ? I want it for both -security and -updates. that's why we use the ppa
<ogasawara> bjf: I'd assume you'd need to also upload the headers package to the ppa to get it to build ok
<apw_> sobir can be copied to security  too
<ogasawara> bjf: once it builds successfully then you could just delete the headers package from the ppa?
<apw_> we should notbe deltingbhr
<ogasawara> wha??
<bjf> we should not be deleting the ppa packages
<ogasawara> ah
<smb> I would agree with apw (though he sounds like he ran against a wall with his nose)
<tgardner> until all dependencies are built
<apw_> the headers come from the kernel source
<smb> Everything should be first in the ppa and then copied
<bjf> smb, thats all well and good except when you forget something, it sucks being human
<apw_> i suspect to fix youll have to do a no changecupload of the kernel
<apw_> tovthe ppa, then lum
<smb> Then the kernel package need to be uploaded and the cleaning mechanism should only delete packages that are superseded in the ppa itself
<apw_> and get ourchecklist sorted so it includes lum etc
<tgardner> apw: in this particular case, Is ee no reason why we can't just upload LUM to -proposed.
<smb> apw_, Could be that the version needs to be tweaked a bit because the real one had been in the ppa already
<apw_> ivf the compiler is the same likely itll work
<tgardner> apw: I'm not too worried about that. gcc for Hardy hasn'
<bjf> apw, tgardner, smb, i'm tempted to just ignore the one that is currently in -proposed and just upload the kernel for the new cycle, then the matching lum
<tgardner> hasn't changes in a bit
 * smb wonders how long it would take if we only uploaded to our ppa and requested more disk-space until lp learned to auto-clean ppas...
<tgardner> bjf, have you had any complaints about folks not being able to upgrade their LUM packages? I assume the meta package in -proposed is pointing at a LUM that does not yet exist.
<bjf> tgardner, bug 725138 comments 2 & 3
<ubot2> Launchpad bug 725138 in linux "linux: 2.6.24-29.87 -proposed tracker" [Undecided,Fix committed] https://launchpad.net/bugs/725138
<bjf> tgardner, don't know why QA hasn't run into this
<tgardner> bjf, 'cause LUM is an elective install
<bjf> tgardner, that just occurred to me
<bjf> tgardner, it's only an issue if you have installed it and then are trying to update
<smb> tgardner, I am not so sure about the electiveness of LUM
<smb> (as it has all the sound of hardy)
<tgardner> smb, , oh it LBM and LRM that were elective?
<smb> I think so. 
<tgardner> right, so I think all those packages need to get uploaded to -proposed.
 * smb is surprised to see his lucid ec2 branch building after all he has done to it...
<tgardner> bjf, so I assume Hardy LBM/LRM/LUM are now all on your dependencies checklist for ABI bumps? Hardy is a significant pain in the ass wrt ABI bumps. LBM/LRM are still currently lagging the ABI update.
<bjf> tgardner, yes, i'll work on straightening this out today
<apw> damnable broadband is still in a heap, at least i have a keyboard now though
<smb> apw, Did you buy one for your phone ?
<apw> heh, no but i also have a data stick for emergencies, which i've just activated
<smb> apw, Ah :) Actually I guess you could have used the phone for that
<apw> i can but it sucks up my allowance pretty quick, this is 'unlimited'
<smb> They did not promise unlimited speed... Though its hard to get unlimited data with a speed near to zero
 * bjf[afk] heading out to deal with a passport issue
<ogasawara> so how are CVE's being handled now?  Does the security team still ping us to process a batch of public CVE's or do we just pick them up when we have time or are there dedicated days to work on CVE's?
 * ogasawara just noticed the list of CVE's is growing
<tgardner> ogasawara, its been kind of jit and miss. most of us try to get to at least one CVE per week. you can coordinate on https://spreadsheets.google.com/a/canonical.com/ccc?key=0AgFTUDTDyXredE92dFdsVGkxN1FMMWJabS0wZENLRWc&hl=en&ndplr=1#gid=0
 * tgardner --> lunch
<bjf> tgardner, ogasawara https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs
<kristian-aalborg> hi ppl
<kristian-aalborg> which is the smallest/fastest ubuntu installation that will let me build a kernel.deb?
<apw> kristian-aalborg, i don't think any of them will let you do that without installing additional stuff
<kristian-aalborg> yup, I'm aware
<apw> apt-get builddep linux or similar will sort you on any
<kristian-aalborg> but would Server Edition do?
<apw> yeah as long as you have the builddeps you are good, there is not impediment
<kristian-aalborg> would this be true for debian as well?
<kristian-aalborg> I have an ultra modest machine that I plan to build kernels on - would love as little "fluff" as possible and there's only 2 gigs to spare
<jjohansen> kristian-aalborg: uh you are aware that kernel builds suck up lots of space
<kristian-aalborg> yes, painfully aware... I'm thinking of doing the building itself on an usb stick
<kristian-aalborg> then I can just throw the Eee 2g surf (!!) in a corner and check it every few hours ;)
<jjohansen> kristian-aalborg: so a minimal debian would work as long as all the proper build deps are installed, but the build deps are actually pretty weighty
<jjohansen> several hundred megs, /me doesn't remeber the exact figures
<kristian-aalborg> yes
<apw> you do need about 5GB plus 1GB per flavour you build
<kristian-aalborg> I have two eight gb sticks
<jjohansen> kristian-aalborg: while you can do builds on a stick you will want them to be fast sticks and you can burn them out pretty quick
<kristian-aalborg> no need to burn, I'll just move the stick over
<kristian-aalborg> the perfect crime ;)
 * jjohansen -> lunch
<kristian-aalborg> I see that ubuntu NetInst with the debs is 1,2 gig
 * kristian-aalborg has settled for Server Install and is about to give it a try
 * bjf -> lunch
<JFo> stepping away for a bit. call my cell if you should need me  
<JFo> (not that I expect you will need me)
 * vanhoof calls JFo for fun
<ogasawara> heh
<kristian-aalborg> by the way, is there somewhere you can get a pre-built kernel with APM support (i.e for old hardware)?
<tgardner> kristian-aalborg, every release since Dapper has CONFIG_APM=m
<kristian-aalborg> tgardner: I was thinking of something app-gettable?
<kristian-aalborg> a project somewhere for freaks like me running old machines ;)
<tgardner> kristian-aalborg, I'm not really sure what you're asking then. Every _kernel_ we've released supports APM to some extent. Have you tried 'sudo modprobe apm' ?
<kristian-aalborg> yes
 * kristian-aalborg needs to boot up another machine to do it live (like O'Reilly puts it)
<kristian-aalborg> FATAL: error inserting apm, no such device
<kristian-aalborg> however, the file is very much there
<mjg59> kristian-aalborg: apm will fail if acpi is running
<kristian-aalborg> so, the vanilla ubuntu kernel supports apm?
 * kristian-aalborg has to shop for cigs, brb
<njin> hello to all, in a system with a pae kernel installed, can i suggest to install the ppa kernel?
<apw> njin, depends on the PPA ... but normally there are generic and generic-pae flavours in a ppa
<kristian-aalborg> mjg59: which flags in grub? apci=off and apm=on ?
<mjg59> kristian-aalborg: That would probably be a start
<njin> apw: i know only http://kernel.ubuntu.com/~kernel-ppa/mainline/, there's another ppa?
<kristian-aalborg> I'd swear I tried any and possible flags...
<apw> the mainline builds, we don't build just -generic ones
<apw> i mean we do just build -generic there
<njin> and where i can find the pae then?
<apw> of mainline kernels, we don't make those i am afraid
<apw> they are not designed for running regularly, they are for testing only
<njin> ah, i understantand, so better not suggest to try the mainline in a machine with a pae kernel?
<kristian-aalborg> hurm, same error with those flags
<kristian-aalborg> to clarify, this is the kernel that came with the install
<kristian-aalborg> 2.6.32-27-generic
<mjg59> You're sure that the machine has an APM BIOS?
<kristian-aalborg> pretty much
<kristian-aalborg> http://www.thinkwiki.org/wiki/Category:770
<mjg59> Yeah, ought to work
<mjg59> What does dmesg say after modprobe apm ?
<njin> Kernel driver in use: i915 and intel ips 0000:00:1f.6: CPU power or thermal limit exceeded is a linux issue ?
<kristian-aalborg> aha
<njin> bug 728579
<ubot2> Launchpad bug 728579 in linux "Imagen in external VGA monitor trembles" [Undecided,New] https://launchpad.net/bugs/728579
<kristian-aalborg> http://pastebin.com/V5Wrtxzf
<mjg59> kristian-aalborg: Ok, I blame the code that's meant to set up the APM data
<mjg59> Should probably just file a bug
<kristian-aalborg> hurm
<kristian-aalborg> as I understood it, apm has to be compiled into the kernel to work now?
<mjg59> Shouldn't
<kristian-aalborg> ok, that's good
<lool> Does someone have a recipe for doing a PPA upload of an Ubuntu kernel?
<lool> basically I'd like to apt-get source linux, do some changes, push to my PPA, but I keep running into issues; I did rename the ABI dir last time around, but now I'm getting module hashes mismatches
<lool> sorry symbol hashes
 * lool is going to try with a custom ABI name
<kamal> lool: hi, I publish kernel PPA's quite regularly -- maybe I can help.  took me several iterations to finally whip the ABI and module check issues into submission also :-)
<lool> kamal: Happy to hear your tricks  :)
<lool> I could obviously set skipabi and skipmodules on all arches, or touch the ignore files, but if I could keep the changes to a minimum and keep the safety nets, that'd be nice
<kamal> lool: the secret is to disable the ABI check *and* the module check
<kamal> lool: ah, so you know about the ignore files already -- that's the big "trick" :-)   always works for me, 100%
<lool> kamal: Ever tried uploading your own ABI?
<kamal> I used to worry about the "safety net" also, but have found that none of my PPA "customers" ever have any trouble with my published kernels -- I don't worry about it any more, I just shut those ABI and module checks right off and don't think twice about it.
<lool> kamal: Also, what version number do you use, and do you update both debian.master/changelog and debian/changelog?
<kamal> lool: no, I've never tried uploading my own ABI
<jjohansen> lool: generally debian.master
<jjohansen> debian/changelog should be copied from debian.mast/changelog
<lool> But when you prepare the source, tools usually poke debian/changelog e.g. dpkg-source -b
<kamal> lool, jjohansen: yes, I always edit *both* as jjohansen describes
<lool> so I end up editing both -- if I edit only debian/changelog it gets replaced during build, and that doesn't end happily
<jjohansen> lool: fdr clean, setups up debian/changelog
<kamal> lool: yes, correct -- you must keep them in sync for any sort of sanity to occur.
<jjohansen> yep
<kamal> jjohansen: but beware!...   fdr clean only gets run *after* you've produced the source package!...
<kamal> jjohansen: so if you don't *manually* copy debian.master/changelog to debian/changelog before you produce that source package, it will get produced with a bogus version number.
<kamal> (doesn't matter for git-push-and-build, but does matter very much for PPA uploads).
<jjohansen> kamal: ah, yeah that is a problem, /me has always done fdr clean before making the source package
<kamal> jjohansen: ah, I don't do that -- I *just* "cp debian.master/changelog changelog"
<jjohansen> kamal: well I wasn't sure what other bits might be needed, so I figured it was safest
<kamal> jjohansen: that's the only one needed.   I've thought about trying to fix up our packaging system to resolve that issue also (since I built an awful lot of mis-versioned packages before I figured out the reason).
<jjohansen> lool: as for the abi stuff its an absolute pain, I suggest you just follow kamal's suggestion of disabling
<jjohansen> kamal: its the abi stuff that killed me originally, I was preparing the package from a tree where I had done test builds, but the test builds had generated the abi files I needed incrementally, so they were available locally but didn't become part of the upload, and hence the ppa builds would fail
<kamal> jjohansen, lool: yes, I used to tear my hair out over build failures due to ABI ... but having never experienced any problem with just disabling the check.
<lool> Thanks all
<kamal> lool: you also asked about version numbers...  I've settled on a "+kamal~suchandsuch" scheme so if I'm publishing a build of "the foobar fixes" on top of say 2.6.38-7.35, then I'll use a version number of "2.6.38-7.35+kamal~foobar~fixes".  ...
<kamal> IMHO, its good to have my name there for easy blame^Widentification by uname -a.   The "+" sorts correctly and conveys some useful meaning and is a legal character.  The "~" is also a legal character (which does have another special meaning, not relevant here).   Note that neither "-" nor "_" are acceptable characters for you to add on to the string.
<kristian-aalborg> mjg59: might you be interested in helping me file a bug report later?
<kristian-aalborg> I'd want to do it properly, if I should do it
#ubuntu-kernel 2011-03-17
<bryceh> is apw gone on holiday now?
<jjohansen> bryceh: hrmm I am not sure which day it starts he left it off the calendar
<bryceh> jjohansen, ok thanks
<bjf> bryceh, he should be around all this week (i think)
<bryceh> bjf, aha good, I'll email
 * apw waves morning ...
<jjohansen> good morning apw
<apw> jjohansen, morning, hows it going today
<jjohansen> heh, not bad, at least not yet we will see how the night goes :)
<smb> It should be dark, quiet and you probabaly sleeping. :)
<apw> jjohansen, heh out of sync as usual i see
<jjohansen1> wheee: shutdown now -r in the wrong terminal
<apw> jjohansen, you are tired!  time for bed
<jjohansen> apw: hehe, no I'm really not.  The terminal had been connected to the test box, but it was one that had dropped.
<tumbleweed> hi. anyone know the state of core i3 (intel hd) graphics on lucid? Got a new box that'll boot with a Maverick kernel, but not lucid.
<jjohansen> I know because all the terminals in that workspace were
<smb> ipmitool -Ilanplus -Hjjohansen power off
<jjohansen> hrmm, if only /me could take a hint :)
<apw> heh
<jjohansen> tumbleweed: where does the boot fail
<apw> ipmitool -Ilanplus -Hjj-house power off
<apw> ipmitool -Ilanplus -Hjj-state power off
<smb> apw, I guess we would have to add a -Uspouse
<jjohansen> aw shucks my ups lasts about 1 min
<tumbleweed> jjohansen: kernel BUGs... http://paste.ubuntu.com/581502/
<tumbleweed> oh, whoops, multiple boots in there
<jjohansen> apw, smb don't worry I won't be here all night, but I need a few hours to settle down from exercising
<apw> Mar 17 10:53:06 aa-bok-3 kernel: [    7.888543] [drm:i915_gem_object_bind_to_gtt] *ERROR* Attempting to bind an object larger than the aperture
<apw> isn't that an indication of a BIOS setting the AGP aperture smaller than graphics memory
<apw> Mar 17 10:53:06 aa-bok-3 kernel: [    7.888422] [drm:i915_driver_load] *ERROR* Detected broken video BIOS with 262140/262144kB of video memory stolen.
<apw> Mar 17 10:53:06 aa-bok-3 kernel: [    7.888468] [drm:i915_driver_load] *ERROR* Disabling GEM. (try reducing stolen memory or updating the BIOS to fix).
<apw> indeed, the kernel hates your BIOS with a pasion
<tumbleweed> heh
<tumbleweed> I'll try a static share rather than "auto"
<apw> smb, i have just realised that 5 years at an abi bump every 2 weeks (worst case) will bust the 0-99 range we have for abi on lucid master
<jjohansen> apw: are we doing an abi bump every time?
<jjohansen> yes /me knows they have been changing, just whether we expect them to always change
<apw> jjohansen, well they tend to pretty often, its not 100% guarenteed of course but worst, worst case we can double bump in a 2 week period due to reverts ... so i still think we'll be pressing in on 99 
<apw> might be prudent to increase spacing for natty and above
<jjohansen> oh yikes /me wasn't thinking of double bumps
<jjohansen> definitely
<tumbleweed> apw: thanks reducing it to 128M did the trick. /me kicks himself for not following the suggestions from the kernel first
<apw> tumbleweed, hrm, not sure that that isn't a bug however ... the rest boots ok now?
<tumbleweed> apw: yeah
<tumbleweed> it cerntainly works out the box with the maverick kernel, so the issue has been fixed / worked around
<apw> ahh good point
<smb> apw, jjohansen I guess worst case we will have to to a magic bump into the higher regions
<apw> smb, yeah probabally so
 * apw reboots to test a patch
<apw> (this is my only affected work station, of course)
<smb> Farewell friend...
<smb> apw, Successful?
<apw> it boots at least
<apw> so far seems to suppress the terminal corruption i was seeing too
<smb> sounds not too bad then
<smb> apw, Was that the sort of corruption that suddenly would garble the contents of your window but go away when you scrolled or refreshed?
<smb> vi
<apw> smb, yeah thats the one, though the commit is really expected to make it better not worse
<smb> apw, sounds like the thing I noticed somewhat on my aspire one. Though I usually put it to bad hw
<apw> yeah, if you look close its 'previous screen contents' dithered and mixed with the current screen
<jjohansen> apw: does that happen to you in other windows than a terminal, that bug seems to hit pigin, chromium, and mumble for me
<jjohansen> or perhaps its just a bug that is similar
<apw> jjohansen, i cannot say i have ever seen it anywhere else, but the bug is in copy operations on areas of screen not particularly text related
<apw> i rarely scroll anything but terminals and chrome
<jjohansen> sounds like it
<jjohansen> hrmm, but I see corruption without scrolling
<jjohansen> but perhaps its because of switching workspaces
<tumbleweed> apw: ah, you ran into the same corruption bug I reported. I see it most in curses programs, but scrolling is a sure way to trigger it too.
<tumbleweed> I've very occosionally seen corruption in other windows (often notfy-osd), but that may be unrelated
<jjohansen> tumbleweed: now that you mention it I do usually see the corruption in other window under where notifications displayed
<apw> tumbleweed, yeah am trying to debug it now, its very annoying, upstream has offered some things to try
<apw> tumbleweed, i may have a fix for that corruption bug, i will be pushing some kernels for testing shortly; are you able to test?
<tumbleweed> apw: certainly
<apw> be about half hour, i'll poke you when they are up
<lesshaste> hi I just installed apt-get install linux-headers-2.6.38-7-generic linux-headers-2.6.38-7 on lucid
<lesshaste> but weirdly, I can't actually find vmlinuz-2.6.38-7-generic
<lesshaste> any idea what is going on?
<lesshaste> oh oops
<Ntemis> hi
<Ntemis> finally i have found the sweet spot on my server
<Ntemis> all kernels <2.6.38 where freezing my system randomly because of my eth0 r8169
<Ntemis> with 2.6.38 problem seems gone :)
<Ntemis> thanks guys
<Ntemis> for the mainline repo
<Ntemis> btw is a 8111E realtek
<apw> there was something for r8169 very recently
<Ntemis> hi apw
<Ntemis> i was here before some days posting my kernel logs
<Ntemis> you remember me?
<Ntemis> nothing found on the logs
<apw> seems it was in -rc8
<Ntemis> seems the caveat was my 8111E gbit lan 
<Ntemis> it was freezing the server randomly
<Ntemis> no ssh access
<Ntemis> why they remove the firmware from 8111D? from 2.6.38
<apw> cirtianly the latest have some fixes for ASPM killing r8169's dead and nothing in the logs
<apw> Ntemis, not sure i saw them removing firmware, though most migrates into the firmware package when pulled out
<Ntemis> that one was in the 2.6.37.4 but server still freezed
<Ntemis> is not the aspm the problem
<Ntemis> problem gone for good on 2.6.38
<Ntemis> something else changed on r8169 driver
<Ntemis> i thing they got the realtek driver and used some code from it
<Ntemis> port it over
<Ntemis> 8.0.0.19
<Ntemis> something
<Ntemis> now i have the latest kernel and samba 3.5.6 will i need to update to natty?
<Ntemis> or i am ok to stay as it is?
<Ntemis> server is used for torrenting, news groups downjloading and cifs/samba, nfs jbod
<Ntemis> am pleased as it doesnt crash now
<Ntemis> also now coretemp works ok on 2.6.38
<Ntemis> but is showing some weird stuff
<Ntemis> coretemp-isa-0000
<Ntemis> Adapter: ISA adapter
<Ntemis> Core 0:       +9.0ÃÂ°C  (crit = +100.0ÃÂ°C)                  
<Ntemis> coretemp-isa-0001
<Ntemis> Adapter: ISA adapter
<Ntemis> Core 1:       +8.0ÃÂ°C  (crit = +100.0ÃÂ°C)
<Ntemis> what do you thing about this output?
<apw> bah boiler man has killed the boiler instead of fixing it
<apw> tumbleweed, dunno if you saw but those kerenels are up
<smb> apw, Maybe you should have asked for the boilerrepairman instead
<apw> smb, don't get me started, i am going to strangle the next contractor who lets me down
 * smb fears there won't be many left after that
<apw> smb, you aware of the xen TSC running away issues ?
<apw> bug #727459
<ubot2> Launchpad bug 727459 in linux "TSC is not reliable under Xen on some Intel CPUs" [Undecided,New] https://launchpad.net/bugs/727459
<smb> apw, I heard of so many time problems....
<smb> Is that lucid, hardy or later...?
<apw> lucid
<smb> Ok, yes it might give wrong utimes of processes probably. I'll see how much of those problems are left when I am done with the tree
<smb> If it still runs then
<apw> :)
<tgardner> apw, I just updated the tangerine natty schroots. have a look at the gcc segfaults in dmesg.
<apw> tgardner, no not more compiler fallout ... bloody hell
<apw> tgardner, are they all since you updated ?
<tgardner> apw, can't tell when they happened. looking in syslog...
<apw> tgardner, i'll bang a build in and see if we get some more
<tgardner> apw, hmm, not showing up in syslog. I was hoping time would be normalized with the segfault message
<tgardner> apw, bang away
<apw> tgardner, i386 builds don't seem to be triggering it
<tumbleweed> apw: I'm not seeing any corruption yet
<apw> tumbleweed, good news indeed
<apw> if you could feed back on the bug when you are happy
<apw> i can get that back to upstream and get that progressed
<tumbleweed> sure
<apw> tumbleweed, i don't seem to be able to reproduce your other corruption in unjity there... can't tell if thats unity or the same sort of bug ... unity being a little volatile
<apw> tumbleweed, would you agree its a major improvement?
<tumbleweed> apw: unity moves very fast, yes. I haven't even used it in a while
<tumbleweed> sorry just sorting out stuff for a meeting I'll comment on bugs in an hour and a bit
<jcrigby> apw, tgardner: quick question,  I've been asked to turn on CONFIG_PNP_IP in linux-linaro-omap to allow setting ip config on command line.
<jcrigby> all the other linaro flavours all ready have it on because their configs came from kernel source defconfigs
<jcrigby> but omap came originally from ubuntu kernel
<apw> jcrigby, those are totally separate from our omap arn't they?
<jcrigby> apw, yes just drawing on your wisdom
 * apw can't even find such an option in natty
<apw> or maverick or lucid
<jcrigby> I may have spelled it wrong
<jcrigby> CONFIG_IP_PNP
<jcrigby> CONFIG_IP_PNP and CONFIG_ROOT_NFS are very useful for embedded development
<apw> they don't sound like dangerous things to enable to me
<jcrigby> ok, just checking if there was some historical or other reason, thanks
<tumbleweed> yay just caused a total lockup by running impressive (GL)
<apw> jcrigby, the description implies they are only needed for your kind of use case, so i can see why they would be off in our world
<jcrigby> right
<tgardner> apw, I think CONFIG_IP_PNP could cause unhappy things. I'm concerned about the connection table getting populated  with stuff you may not necessarily want.
<apw> tgardner, yeah cirtianly wasn't proposing we enable it in any of our images
<tgardner> apw, upgraded from maverick to natty on the HP mini. seems to have gone pretty well.
<apw> tgardner, yeah we are past the absolute worst of unity cratering every 10s
<apw> i am using it here on this netbook without whining
<apw> now that most things seem to work i am working up to upgrading on my dekstop
<tgardner> apw, gsettings-data-convert crashed a couple of times, but now seems to have stopped.
<apw> though it gives me butterflys
<tgardner> apw, I'm quite happy with Lucid on my desktop :)
<apw> tgardner, heh a sound plan indeed
<apw> but .. if i don't use it every day on my boxes they stop working!
<tgardner> apw, looks like you need a Natty meta package update.
<apw> tgardner, ahh has the main packages finally gone through, i've got it ready to upload
<tgardner> checking...
<tgardner> looks like all arches have built
<apw> tgardner, yeah they were built, but still New this mornign, they were menat to be done last night, but something got delayed
<apw> uploaded
<tgardner> apw, ack
 * apw shifts location
 * JFo needs foodage... bbiab
 * apw returns ... shaken but not stirred
<smb> apw, How many olives?
<kamal> apw: I'm curious why you didn't upload a linux_2.6.38.orig.tar.gz this time... isn't it ready for that now?
<apw> kamal, yes it is ready for it, but i didn't have one at hand or the time to ensure it was the right one before, as i had to hit betweeen two compiler uploads
<apw> kamal, is it somehow causing a problem?
<kamal> apw: not at all!
<kamal> apw: just makes PPA uploads take forever and consume more PPA space -- not at all critical.
<tgardner> kamal, it goes fast from tangerine
<kamal> tgardner: yup, sure does :-)
<apw> kamal, or from zinc
<kamal> apw, tgardner: I do all my own test builds on tangerine, but I upload (the fully tarball, in absence of a .orig) to PPA to publish
<apw> kamal, as do i, but push the branch to zinc and package it there, and upload it from there
<kamal> apw: ah yes, I just clued in to what you guys meant there.
<apw> kamal, anyhow, it will have one shortly, as i have to reupload for the next comp change
<kamal> apw: you remotely sign the package on zinc?  (debsign -r or something)?
<apw> yep
<apw> uploads in a about 8s
<apw> the debsign only does the tiny files, life is good
<kamal> apw, tgardner: wow, okay, I'll try that procedure (at least when I need to upload the full tarball).  thanks much guys.
<apw> kamal, i do it that way always now, it rocks
<tgardner> bjf, do you have an official channel for getting kernels pocket copied from the c-k-t PPA ? I need Lucid linux-mvl-dove and linux-meta-mvl-dove pocket copied into -proposed.
<bjf> tgardner, no official channel yet, just ping pitti
<tgardner> bjf, Has Clint been activated in that role yet? I suspect Martin is gone for the day
<bjf> tgardner, don't know, maybe ping skaet ?
<skaet> tgartner, bjf - not sure if the training's happened or not yet.   
<skaet> probably best to ask clint directly at this point.  
<skaet> if he's not comfortable yet, possibly colin can help (if he's still around) if pitti's gone for the day.
<bjf> ogasawara, did you use "create-cve-tracker" to create the bug for CVE-2010-4342 ?
<ubot2> bjf: The aun_incoming function in net/econet/af_econet.c in the Linux kernel before 2.6.37-rc6, when Econet is enabled, allows remote attackers to cause a denial of service (NULL pointer dereference and OOPS) by sending an Acorn Universal Networking (AUN) packet over UDP. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4342)
<ogasawara> bjf: I did
<bjf> ogasawara, odd, it doesn't look right
<ogasawara> bjf: it did give me some message that I'd have to update some parts by hand for some reason
<tgardner> bjf, since she's special, perhaps the nominations got fubared ?
<ogasawara> bjf: so now I'm trying to open the nominations by hand but lp keeps failing
<apw> launchpad not right?  never
<bjf> tgardner, could be, the nominations don't look right and the tag is missing
<ogasawara> bjf: I keep getting a timeout error when trying to open the nominations so I suspect the script may have hit the same?
<bjf> ogasawara, just sent email about what to do about timeouts, we got this from jml in london
<ogasawara> bjf: cool thanks
<ogasawara> bjf: heh, now it is no longer timing out
 * bjf running an errand, brb
 * tgardner --> lunch
<Martiini> elou. any ubuntu devels hang out here ??
<Martiini> question about ubuntu kernel .. kernel seems to configured not as well as some other distros
<Martiini> howcome .. ?
<tgardner> bjf, https://launchpad.net/~kernel-ppa/+archive/ppa
<Martiini> tgardner, is that .. backport kernel .. 
<Martiini> I can test that of course
<tgardner> Martiini, are you testing for some particular behavior ?
<Martiini> no .. opensuse kernel just work as the best .. out of all distros Ive tried .. dmesg, etc etc .. is no help .. simple things .. like acpi, boottime .. work best in opensuse on all laptops Ive tried .. so .. wanted to know why
 * ogasawara back in a bit
<cnd> bryceh, ogasawara, bjf: I'm coming to portland!
<bjf> cnd, sweet!
<bjf> cnd, i take it ohsu got selected ?
<cnd> yep
<cnd> it was our top choice too
<tgardner> the world needs a larger portland mafia
<bryceh> cnd, wow congrats!
<bjf> cnd, i know of a row house within walking distance of ohsu that is for sale :-)
<bjf> cnd, or will be very soon (i hope)
<cnd> bjf, that might be handy :)
<cnd> I'll probably be making a trip out soon to look at things
<cnd> we'll be moving in early-mid june I believe
<bryceh> cnd, be prepared for having endless advice about finding where to live ;-)
<cnd> heh
<cnd> so much to do in so little time now...
<bryceh> on the plus side, it's a buyer's market here
<bjf> bryceh, in some areas, i was surprised when two houses in my neighborhood went on the first day for full price
<cnd> things seem volatile right now
<cnd> it's hard to gauge things
<cnd> but one would assume that even if we didn't buy at the absolute bottom things are likely to go up from here
<bryceh> cnd, yep.  Like bjf says, while there's a lot of houses available, finding the real gems can take some luck
 * sbeattie would probably rent first
<bryceh> sbeattie, yeah, I've heard of others take that approach with good results
<sbeattie> best to get to know the area first, to figure out where you'd like to buy.
<sbeattie> cnd: and cool, glad you're becoming one of us! :-)
<cnd> sbeattie, thanks!
<Martiini> ok, so .. what is linux-image-generic-lts-backport-natty , linux-image-generic-pae-lts-backport-natty
<kristian-aalborg> hi all
<kristian-aalborg> would it be possible to make a "generic" pre-2000 hw kernel?
<bjf> JFo, can you accept the nominations for bug 737124 ?
<ubot2> Launchpad bug 737124 in linux "Support workstations with greater than 64 cores" [Undecided,New] https://launchpad.net/bugs/737124
<JFo> bjf, yessir
<JFo> bjf, done
<bjf> JFo, thanks
<JFo> my pleasure :)
<JFo> and now I must step away for a while and pretend I am Irish. (well, more than I already am) :-)
<vanhoof> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=drivers/idle/intel_idle.c;h=3013e8f82fa82655efb2d5bac27ce20e7c6bafa9;hb=d827cf03495bdab2743f82f28fbe67b21048fe77
 * bjf is heading out for some air
#ubuntu-kernel 2011-03-18
<jj-afk> back on later
<apw> smb`, morning
<apw> smb`, any idea what is going on on bug #634487
<ubot2> Launchpad bug 634487 in linux "t1.micro instance hangs when installing java" [High,Confirmed] https://launchpad.net/bugs/634487
<apw> tumbleweed, about?  i have just pushed a new test kernel for bug #717114 ... it seems the previous one was triggering some blocking and slowness
<ubot2> Launchpad bug 717114 in xorg-server "[i945gm] Screen Corruption with new Xorg stack with terminal programs" [Critical,Confirmed] https://launchpad.net/bugs/717114
<apw> tumbleweed, see if that one works as well ... seems to for me
<tumbleweed> apw: ah I was going to ask you if you would, thanks
<apw> tumbleweed, i have it here on my test box, and it seems to work well
<tumbleweed> apw: LGTM
<apw> tumbleweed, excellent
<tumbleweed> apw: and now there's another patch...
<apw> tumbleweed, another patch?  whats the subject
<tumbleweed> Fix tiling corruption
<tumbleweed> oh that was just for trunk, the previous one was for stable
<fairuz> I built a kernel from linaro tree
<fairuz> when I boot, i got this modprobe: FATAL: Could not load /lib/modules/2.6.38-00509-g47dc59f/modules.dep: No such file or directory
<fairuz> any idea? thanks
<TeTeT> on Natty with the recent -7 kernel I tried to transfer a large file (~100 GB) via clonezilla and it stopped after 12G. Only a hard reset was possible, the log contains these messages over and over again: http://pastebin.ubuntu.com/582056
<TeTeT> is the r8169 driver broken for large data transfer?
<fairuz> I got this error http://pastebin.com/CGD220mH when I tried to boot my compiled kernel
<ogra_> doesnt look like your kernel package was properly installed 
<ogra_> usually the postinst runs the necessary commands (i.e. depmod to create modules.dep)
<fairuz> ogra_: any suggestion to fix this? What I do is just clone the git tree, then compile it using a defconfig
<fairuz> ogra_: It should work I suppose?
<ogra_> no idea if that will work, usually we build packages in ubuntu ;)
<fairuz> ogra_: sorry a stupid question..what's you call a package :D
<ogra_> the missing modules.dep shouldnt stop you from booting
<ogra_> a .deb file
<ogra_> which cares for regenerating the initrd, call the right commands etc after installing the files
<fairuz> ogra_: I see the initrd in my boot partition but no idea what it is :D
<fairuz> ogra_: I just replace the old uImage with the new one
<fairuz> ogra_: maybe that cause the problem?
<ogra_> on a sidenote i'm not sure how linaro handles the configs, they might be genereated from multiple files during buld
<ogra_> so defconfig might or might not work
<fairuz> ogra_: hmm that's frustrating to hear :D
<ogra_> look at the kernel area on the ubuntu wiki, there are hints how to build proper kernel packages
<ogra_> or talk to the linaro guys about their kernel tree and how to build it, it might differ from ubuntu
<fairuz> ogra_: I'm confused. =) Actually I want to build a kernel for my Ubuntu
<ogra_> for what arch ?
<fairuz> ogra_: arm
<ogra_> heh
<ogra_> what arm architecture is that ?
<ogra_> board/SoC
<fairuz> ogra_: Pandaboard Omap4430
<ogra_> why dont you use one of the existing kernels then ?
<fairuz> ogra_: there is one for 2.6.38?
<ogra_> in natty, yes
<fairuz> ogra_: damn, i'm wasting time compiling then :D
<ogra_> https://launchpad.net/ubuntu/natty/+source/linux-ti-omap4/2.6.38-1204.5
<fairuz> ogra_: you save my life :D
<ogra_> note that there is no HDMI driver for .38 yet
<fairuz> ogra_: ah ok, I use ssh then
<ogra_> you need to use DVI and set the omapfb comdline args (same options as for a beagleboard)
<ogra_> indeed, or use ssh ;)
<fairuz> ogra_: I dont really need the display actually
<fairuz> ogra_: actually the reason i want a new kernel build is that before, i use 2.6.35 and i want to apply some patch
<fairuz> ogra_: to appy patches, we have to recompile?
<fairuz> ogra_: if you say no, i will kill myself
<fairuz> :D
<ogra_> indeed you have to recompile to apply a patch ;)
<fairuz> ogra_: :D
<fairuz> ogra_: so I think why not use a more recent kernel that already have all the patches
<fairuz> ogra_: what's the difference from the TI omap kernel in natty than the upstream kernel?
<fairuz> ogra_: the compile steps is different?
<ogra_> it has additional patches from TI
<ogra_> the package is built like any other ubuntu kernel package
<fairuz> ogra_: being lazy. Did they put an already built kernel image there? :D
<ogra_> yes, click on the armel build on the link i gave you above
<fairuz> ogra_: I click here https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.38-1204.5/+buildjob/2313441
<ogra_> just copy back your original kernel, boot your panda, log in, wget the .deb file and run dpkg -i on it
<ogra_> yaou want linux-image... and probably linux-headers... and linux-tools...
<fairuz> on the *.udeb file?
<ogra_> no the .deb files
<ogra_> udeb are special packages used by debian-installer
<fairuz> ogra_: I don't see any .deb files
 * ogra_ sees them at the link
<fairuz> ogra_: 
<fairuz> ogra_: :D
<fairuz> ogra_: I see a list of bonary packages and a list of built files 
<fairuz> ogra_: and on built files list, all of them are .udeb
<fairuz> ogra_: I see them now . Sorry\
<fairuz> ogra_: anything I should backup apart from the old kernel image>
<fairuz> ?
<apw> ogasawara, about ?
<ogasawara> apw: yep
<lil_pete> hi guys. im trying to modprobe a driver module (ath6kl, wifi-driver for toshiba folio 100 tablet), but i get the error message "unknown symbol in module", dmesg reports "unknown symbol outer_cache". anybody an idea what went wrong? 
<ogasawara> tgardner, apw: whenever you both are free, lets mumble and circle the wagons
<tgardner> ogasawara, ok. I'll be off the phone in awhile.
<apw> tumbleweed, about still?
<apw> heh actually forget that, abject failure on my machine
<kees> apw: what's your kernel upload schedule looking like? I have yet another yama ptrace fix for chrisccoulson. I wanted to prioritize sanely...
<tgardner> kees,  you should be talking to ogasawara who will replace apw whilst he's off on vacation.
<kees> tgardner: oh! cool, thanks. ogasawara: same question ;)
<apw> kees, well we need an upload today for the compiler change, and i hope to slp in an i915 fix if its not an abi bumper
<apw> then its leaans call, freeze is thursday so it would likely be monday or not
<tgardner> apw, yet another compiler change? whats getting twiddled now?
<apw> there have been two uploads for multi-arch this week which has caused a lot of kaos
<apw> this time not a compiler payload change, more where things go etc
<ogasawara> kees: indeed, I'd prefer not to have to do an additional upload beyond what andy does, but if we need to, monday would likely be the latest.
<apw> (for beta)
<ogasawara> kees: how quickly can you get the patch to the mailing list?
<apw> ogasawara, you thinking what i'm thinking?
<kees> ogasawara: right, it's not critical. I just wanted to catch it if going today. i'll send the patch to the list today
<apw> that if its small and not a bumper i could get it in
<kees> it's 2 lines
<ogasawara> apw: yep, was thinking that :)
<apw> kees, got it 'now' ?
<apw> so i can see if its a bumper
<kees> apw: gimme 10 minutes?
<apw> np
<kees> apw: okay, sent to list
<apw> kees, looks pretty small and non-bumperish
<kees> apw: should be yeah.
<kees> stupid threads :)
<tgardner> kees, needs a bug report for Maverick SRU
<kees> tgardner: okay, i'll open it with the reproducer and reply on list
<apw> let us know the LP#
<ogasawara> tgardner: bug 728746 was on the release meeting agenda and seems like a quick fix by just adding some symlinks to the broadcom firmware files.
<ogasawara> tgardner: do you prefer a pull request against the the linux-firmware git repo or a merge request for the bzr tree?
<ubot2> ogasawara: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/728746)
<tgardner> ogasawara, linux-firmware isn't in a bzr repo
<tgardner> this is for natty?
<kees> apw: 737676
<ogasawara> tgardner: yah natty.  hrm, I thought I saw a bzr repo on launchpad.
<ogasawara> tgardner: but that answers my question :)
<tgardner> ogasawara, it might already be fixed upstream: linux-firmware: wl12xx-Update STA firmware ?
<apw> ogasawara, you get bzr branches from the uploader, it pushed the uploads into a branch
<tgardner> ogasawara, nm. its nor
<tgardner> not*
<tgardner> ogasawara, doh! this should be linux-firmware-nonfree
<tgardner> ogasawara, ok, I'm just being a dope. it _is_ in linux-firmware, so just send a pull request.
<ogasawara> tgardner: ack
<bjf> tgardner, you have time to review an lts-backport-maverick branch? this is my first time running the script and i want to make sure things went as expected
<tgardner> bjf, can do
<tgardner> did it run clean?
<bjf> tgardner, yes, and it built
<tgardner> bjf, then its likely correct
<bjf> tgardner, zinc.canonical.com:/srv/kernel.ubuntu.com/git/bradf/ubuntu-lucid lts-backport-maverick
<tgardner> k, gimme a bit
<bjf> tgardner, the changelog "looks odd" 
<bjf> tgardner, mostly the version numbers
<tgardner> bjf, looks right. before uploading you'll probably wanna make sure all of the bugs referenced in the changelog have a  linux-lts-backport-maverick package entry.
<bjf> tgardner, huh
<tgardner> bjf, some of the bugs were likely created before some of your tools.
 * tgardner --> lunch
<bjf> tgardner, do you use an orig.tar.gz when packaging lts-backport-maverick ?
<tgardner> bjf, nope.
<bjf> tgardner, thanks
<kristian-aalborg> hi all
<kristian-aalborg> jjohansen: ping
<jjohansen> hey
<jjohansen> kristian-aalborg: ^
<nelhage> Hey, I'm looking at the latest Maverick git, and I have a question about the commits you backported.
<nelhage> I see you backported d281da7ff6f70efca0553c288bb883e8605b3862 ("Make tiocgicount a handler"), but not 0bca1b913 or 0587102cf, which actually convert drivers to use the new handler.
<nelhage> Am I missing something, or does that not actually fix the bug?
<kristian-aalborg> jjohansen: I'm setting up a *third* machine shortly to try to build, I might have some questions
<jjohansen> kristian-aalborg: ok
<kristian-aalborg> I have a transcript of the chat the other day, I hope it's not going to be necessary - but always nice with someone around who's familiar with what you're trying to do
#ubuntu-kernel 2011-03-19
<kristian-aalborg> jj-afk: ah nm, it got too late
<kristian-aalborg> morning
<edgimar_> Could anyone give me tips on debugging a kern.log entry -- I am seeing a "bad: scheduling from the idle thread; Pid: 0, comm: swapper Not tainted 2.6.32-29-generic #58-Ubuntu; Call Trace: ..." about every 2-3 microseconds -- and the logs (kern.log, syslog, and messages) are getting HUGE (as in around 20GB each).
<edgimar_> Here's a snippet from the syslog which could be relevant: http://pastebin.com/m3tUashf
<kristian-aalborg> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel 
<kristian-aalborg> the dependencies you get with the command listed here (sudo apt-get build-dep linux-image-$(uname -r)) are way too heavy - who's to "blame"?
<kristian-aalborg> not the quatiation marks, nobody is to blame of course :) but this could probably be fixed
<AnAnt> Hello, anyone knows what happened to open_sem function in kernel ?
<AnAnt> was it replaced by something else ?
<kristian-aalborg> there should be some kind of lottery where you got a ticket each time a kernel build failed ;)
<AnAnt> sorry, I meant DECLARE_MUTEX
<kamal> kristian-aalborg: I'd be sooooo rich.  ;-)
<kristian-aalborg> speaking of errors, ah few is nothing to worry about, right?
<kamal> kristian-aalborg: actually, any *error* will stop your build dead.    perhaps you just mean warnings?   post an example of one of the "errors" you're worried about.
<kristian-aalborg> kamal: yup, I was thinking warnings
<kamal> kristian-aalborg: yeah, the kernel build spews lots and lots of warnings for sure...  don't worry about them, as long as your build keeps rolling along.  
<kristian-aalborg> it would be cool if you could just upload your .config and then get the .deb
<kristian-aalborg> bugger, it quit again
<kristian-aalborg> I got it to build finally, installing now :)
<kristian-aalborg> hurm, dependency problems
<kamal> kristian-aalborg: which .deb(s) did you build and install?  If you build "binary-headers" and "binary-generic" you should end up with 3 .debs (one linux-image-...deb and two linux-headers-...deb).  That set of 3 .debs should be installed as a group.   That help any?
 * kamal notes that the wiki page https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel fails to mention binary-headers :-(
<kristian-aalborg> kamal: likely
<kamal> kristian-aalborg: try this instead of just 'binary-generic':    fakeroot debian/rules binary-headers binary-generic
<kamal> then verify that you end up with 3 .debs -- dpkg -i them all together -- should help.   I'll see about fixing the wiki.
<kristian-aalborg> kamal I was following some instructions I got on this channel recently more than the wiki
 * kristian-aalborg facepalmed and got some more coffee... is ready again now
<kamal> kristian-aalborg: oh yes, I should have mentioned...  strong coffee is another prerequisite for the kernel build ;-)
<kristian-aalborg> hurm, I actually only have two .debs - linux-headers and linux-image
<kristian-aalborg> I got the missing modules error, then tried again with the ignore-missing (or such) flag
<kamal> kristian-aalborg: ignoring module checks and abi is fine.  I suspect you need that third .deb, which you'll get if you build 'binary-headers'
<kamal> FYI, the complete set of 3 will look something like this:
<kamal> linux-headers-2.6.38-6_2.6.38-6.34_all.deb
<kamal> linux-headers-2.6.38-6-generic_2.6.38-6.34_amd64.deb
<kamal> linux-image-2.6.38-6-generic_2.6.38-6.34_amd64.deb 
<kristian-aalborg> ok
<kristian-aalborg> so, fakeroot debian/rules binary-headers
<kamal> kristian-aalborg: yes
<kristian-aalborg> how "heavy" is that, compared to the others?
<kamal> very light
<kristian-aalborg> cool
<kristian-aalborg> who's doing the wiki, btw?
<kamal> the wiki pages are maintained by the Ubuntu kernel team (and the community in general)
<kristian-aalborg> it could use a little touching up, although I really like that it's rather short
<kristian-aalborg> btw, ubuntu.com is looking real pro these days - probably the neatest OS website I have seen
<kamal> kristian-aalborg: there have been various versions of the "how to build a kernel" instructions, some too long, some too short.   its tough to come up with one document that works well for everybody.
<kristian-aalborg> sure
<kristian-aalborg> there's just a point where it gets so detailed that users can be intimidated to never try, imo
<kamal> kristian-aalborg: absolutely true -- I like the "short instructions" for that reason, but perhaps they've been trimmed down just a bit too much.
<kristian-aalborg> yes, it is a very hard balance to find
<kristian-aalborg> there's also a point where you keep users in the dark by insisting that they do things the "easy" way
<kristian-aalborg> something is happening now... this might work
<kristian-aalborg> kamal: using apmd?
<kamal> kristian-aalborg: nope
<kristian-aalborg> erm, my new kernel reboots the box
<kristian-aalborg> also in recovery mode
<kamal> kristian-aalborg: did you apply any patches, or is the source unmodified?  What version exactly did you build, and what Ubuntu version are you running?
<kristian-aalborg> I'm running 10.4 - I did a make localmodconfig and then tweaked it
<kamal> kristian-aalborg: I suggest that you try building a plain unmodified kernel as a sanity check.
<kristian-aalborg> I got it via git
<kristian-aalborg> yeah, that's probably what I should do
<kristian-aalborg> something weird is that I called it ~custom, but it seems to have installed as -generic
<kamal> kristian-aalborg: so are you building the ubuntu-lucid (10.04) kernel on a lucid system, and then installing it on a lucid system?  Or something more fancy (i.e. installing a newer-than-lucid kernel on a lucid system?)
<kristian-aalborg> I'm building on Lubuntu 10.4 which should be the same, then installing on 10.4
<kristian-aalborg> wut
<kristian-aalborg> aptitude wants to install tzdata and similar things
<kamal> kristian-aalborg: ok, nothing too fancy then.   I don't understand what you mean by "called it ~custom" vs. "installed as" though...  Sounds like you modified debian{.master?}/changelog and didn't get the result you expected.  post the specifics if you need help unraveling that.
<kristian-aalborg> might fix things... lemme see
<kamal> kristian-aalborg: tzdata gets updated often -- probably not related to your kernel build/reboot issue.
<kristian-aalborg> yeah, I was thinking of BzImage
<kristian-aalborg> I edited debian/changelog to have a name that'd be different from my other kernels
<kamal> kristian-aalborg: good plan, but ...
<kristian-aalborg> this reflects in the names of my .debs, so weird it's not showing upon install
<kamal> kristian-aalborg: note that debian/changelog gets overwritten (copied from) debian.master/changelog during the "fakeroot debian/rules clean" phase ...
<kristian-aalborg> I did it before 
<kamal> kristian-aalborg: I'd say, double-check debian/changelog *now* to make sure it still has your ~custom tag in there -- does it?
<kristian-aalborg> one moment, I have to fire up another pc then
<kamal> kristian-aalborg: oh wait...   do you mean just that you expected to see "~custom" in the GRUB boot loader menu?  it doesn't show it there (sadly)!
<kristian-aalborg> ah, that's okay
<kamal> kristian-aalborg: yeah, it shows up in 'uname -a' (but it sounds like you're rebooting/crashing long before getting to a login prompt, yes?)
<kristian-aalborg> yes
<kamal> kristian-aalborg: likely all is fine then -- when you build your "unmodified" test kernel, you may want to go ahead and *still* mark it with a special version string, just so you can verify that its really your kernel with 'uname -a' once you do get it to boot.
<kamal> kristian-aalborg: I often build test kernels with a "~unchanged" version string addition.
<kristian-aalborg> I fooled around with dpkt and apt-get to try to "fix" the .deb that would not install
<kristian-aalborg> I seem to have locked linux-generic in the process, unwise as I am
<kamal> kristian-aalborg: I don't know what state you're in there, but      apt-get install -f          may help (or at least tell you what the problem is).
<kristian-aalborg> they say "dependency hell" as if there is a "dependency heaven"... sigh
<kristian-aalborg> I'm wondering... since this is from git, could it be partly unmet by the repos?
<kamal> kristian-aalborg: unlikely -- the git repo's "master" branch should always produce a kernel that builds and installs properly.
<kristian-aalborg> ok
<kamal> kristian-aalborg: I wonder if you have some leftover bits installed from your first failed installs.  try this:
<kamal> dpkg -l | grep "~custom"
<kamal> this should list all packages that you have installed which have "~custom" in their name
<kristian-aalborg> I still have all of it
<hyperair> kristian-aalborg: dependency issues? how about a paste of the errors?
<kristian-aalborg> hi hyperair 
<hyperair> hi
<hyperair> so how about pastebinning your errors
<kristian-aalborg> these issues were my own fault... I was missing a .deb
<kamal> you could remove (with dpkg) all of your "~custom" packages to clean up.
<kristian-aalborg> I'm trying once more now the dependencies seem fixed
<kristian-aalborg> ah, enough for now
<kristian-aalborg> but thanks for helping out, ppl... I believe I will have this sorted in the foreseeable future
 * kristian-aalborg is back
<kristian-aalborg> kamal: ping
<kristian-aalborg> fakeroot debian/rules clean
<kristian-aalborg> fakeroot debian/rules binary-generic
<kristian-aalborg> only these two commands needed for the "sanity check"?
<Kano> hi, would somebody update kernel-wedge to be newer than current squeeze/sid version?
<kamal> kristian-aalborg: I always do:   fakeroot debian/rules binary-headers binary-generic    (building and installing the headers along with image is quick enough, and never hurts)
<kristian-aalborg> I'll do that as well, then... although not in that order
<kristian-aalborg> btw the system I'm building on is Lubuntu 10.4, not Ubuntu... but should not matter, I think
#ubuntu-kernel 2011-03-20
<kristian-aalborg> kamal: ping
<kristian-aalborg> good news, the vanilla kernel built without any problems
<kristian-aalborg> ... and I just installed it without a hitch
<kristian-aalborg> thus I conclude my custom .config is to blame
<s0u][ight> why did you guys remove config_brcm80211_pci=y from the config file with newer builds of mainline 2.6.38?
<jero-> hello
<jero-> I'm experiencing a major network performance regression since i've been using the natty kernel, using the ath9k driver on an Atheros AR9280 Rev.2 chipset. I can fix the problem just by running maverick's 2.6.35 kernel in place of natty's.
<Specialist> Hi there. I am currently trying to debug bug #698160. pm_trace did not yield any usable results. I am currently compiling a kernel with CONFIG_PM_ADVANCED_DEBUG and CONFIG_PM_VERBOSE. Is there anything else that would make sense trying to isolate the issue?
<ubot2> Launchpad bug 698160 in nvidia-graphics-drivers "Natty: Kernel 2.6.37 - suspend broken" [Undecided,New] https://launchpad.net/bugs/698160
#ubuntu-kernel 2012-03-12
 * apw watches 100s MB of updated download
<smb> Which was even there yesterday...
<smb> including just a new gcc... nothing to worry about...
<apw> smb, was that my '100s MB of updates' you are talking about ?
<apw> are you seeing "waiting for network configuration" as a plymouth message during boot?
<smb> apw, Only when my network is bust usually
<smb> So by now its a bad sign to me if I see it
<apw> smb, this is on everything and on multiple networks all of a suddent
<smb> Hm, strange. But then you don't see the waiting 60s more message?
<smb> And your network is up when you log in?
<smb> apw, ^
<apw> yep just a single message
<smb> The question now is whether it is always there and just now long enough for you to notice or whether it gets printed when network setup is delayed for a certain time
<smb> any way, something seems slower for you
<apw> i don't normally see any messages on the boot screen other than whn its doing an fsck
<apw> this message i have never seen before, and indeed i thought networks were done after you logged in
<smb> apw, No that changed a while ago
<smb> Even with nm, your network was running even you being on the lightdm or gdm screen
<apw> ok, still never ever seen that message with network or without
<apw> and its all of a sudden on both my main machines and with two different network setups
<smb> ok, so something became slower. I assume just this mornings update (if one can say just to that)
<smb> apw, Hm, finished updating a test laptop and I do not see that message in my environment
<apw> smb, hrm, will do the same in a bit
<smb> apw, ok
<smb> cking, we are talking to you
<apw> cking, we heard you, a bit at least
 * cking gives mumble a kick
<ppisati> brb
 * apw loses mumble too
<apw> wtf is with this stuff these days
<ogra_> its all hangouts now anyway :(
<apw> bah
<awe> cking: ping
<cking> awe, pong
<awe> hi
<awe> so my machines has shutdown on me a few times in the last week
<awe> I tracked it down to excessive CPU temp
<awe> I was going to enter a bug against the kernel this morning, but noticed a new kernel was released
<awe> should I wait to hit the bug again before reporting?
<awe> ( also can it really be considered a kernel bug? )
<cking> awe I'd say file a bug so at least we can track this
<cking> you are not the first to report this
<awe> ok
<awe> thanks
<awe> is there already a bug?
<cking> awe, file a new bug, as I expect your H/W is different
<awe> right
<awe> will do
<cking> awe, I have a bunch of things for you to try, which will help me corner this issue
<awe> ok
<awe> I'm in crunch mode right now, but will file a bug today
<cking> ack
<awe> ttyl
<pgraner> sforshee, ping
<sforshee> pgraner, hi
<pgraner> sforshee, hey, so I think the mystery of the dropping wifi is solved
<sforshee> really! what's causing it?
<pgraner> sforshee, I checked yesterday and running up2date precise kernel it happened twice yesterday on that netbook
<pgraner> I found https://bugs.launchpad.net/ubuntu/+source/linux/+bug/937118  
<ubot2`> Launchpad bug 937118 in linux "Wireless stops passing packets" [High,Confirmed]
<pgraner> and  mainline 3.3.0-030300rc6-generic  has made it work
<jsalisbury> pgraner, sforshee yeah, the  linux-backports-modules-cw-3.3-precise-generic package solved that bug because the bug was fixed upstream.
<pgraner> looks like its a dd-wrt issue and I'm guessing whatever it is exists on the cisco fw we use at events
<pgraner> sforshee, Its been running now for over 8 hours and no issue
<pgraner> sforshee, I could trigger it here in a matter of 2-3 hours
<sforshee> pgraner, interesting. I use dd-wrt on one of my routers, but it wasn't the one I was using to test that machine.
<sforshee> we may want to bisect then to see what fixed it so we can backport it to precise
<pgraner> jsalisbury, sounds like a job for you my friend :-D
<jsalisbury> pgraner, sforshee will do.  I think it may be this that fixed it: eea79e0713d94b02952f6c591b615710fd40a562
<jsalisbury> pgraner, sforshee But I didn't do an actual bisect yet.  I came up with that commit after reviewing the git log.
<sforshee> jsalisbury, that's a merge commit, so it's not _the_ fix
<sforshee> it's just when the fix got merged to linus's tree
<jsalisbury> sforshee, ahh right.  So a bisect of the merge commit will need to be done.
<cking> awe, can you boot with an oneiric kernel and see if the overheating re-occurs?
<awe> cking, let me catch you in a few minutes...
<awe> cking, I've only hit it twice in the last week...
<awe> unfortunately it's not reproduce on demand.  ;(
<cking> awe, well, I can write up a bunch of things to try once you've file a bug ;-)
<awe> cking, ok cool
<akgraner> apw, cking - still no crash today - and I've been stressing my machine pretty hard over the last couple of days - the fan thing seems to have fixed it
<cking> akgraner, that wasn't a fix, it was step #1 in me seeing what the problem could be - I've updated the bug - can you try the next step as instructed
<akgraner> cking, sure 
<cking> thanks!
<akgraner> sorry I didn't see it sooner - I thought I would get an email when someone comments on it...weird
<cking> akgraner, LP email isn't instantaneous at times
<akgraner> cking, I didn't need to update a filter :-)
<akgraner> ugh
<akgraner> I meant - I did  get it - just need to update my filters - English and typing fail today it seems
<cking> ah, no worries
 * ogasawara back in 20
<ericm|ubuntu> sforshee, bug 952698
<ubot2`> Launchpad bug 952698 in linux "Backlight no longer works on Macbook Pro5,5 with EFI boot" [Undecided,Incomplete] https://launchpad.net/bugs/952698
<ericm|ubuntu> sforshee, backlight actually works with nouveau driver w/ EFI boot
<ericm|ubuntu> sforshee, and backlight is controlled by the nouveau driver instead of apple_bl
<ericm|ubuntu> sforshee, backlight used to work w/ BIOS compatible mode, I'll need to test again
<sforshee> ericm|ubuntu, apple_bl doesn't work on all macbooks, nouveau might be the only way to change it
 * cking -> back in 20min
<ericm|ubuntu> sforshee, apple_bl works sometimes as I remember but not reliable
<ericm|ubuntu> sforshee, there is a small issue w/ nvidia-current though, when de-activating it in jockey, it makes nouveau un-usable, I have to purge it to get nouveau back again
<sforshee> ericm|ubuntu, it may be that it only works in bios-compatibility, or that it needs changes to work with efi boot. I'm not sure.
<ericm|ubuntu> sforshee, I believe it's nvidia-current black-listed nouveau
<sforshee> that's nasty, probably need to file a bug for that
<ericm|ubuntu> sforshee, yeah I doubt the I/O ports are still valid w/ EFI boot - brightness control never seems to be reliable to me
<sforshee> ericm|ubuntu, adjusting via the graphics card is probably your best bet then
<ericm|ubuntu> sforshee, yes
<sforshee> the backlight situation on macbooks is horrendous
<ericm|ubuntu> sforshee, and we won't have it w/ nvidia-current I guess
<sforshee> ericm|ubuntu, no, and there's nothing we can do about it
<ericm|ubuntu> sforshee, there is a backlight driver in mactel ppa - but that's a bit hackish
<ericm|ubuntu> sforshee, one other problem w/ nvidia-current + EFI boot, I cannot seem to find my framebuffer consoles
<sforshee> ericm|ubuntu, hackish yes, and I don't know what happens if you have it installed and try to use the nouveau driver
<sforshee> EFI boot still has lots of issues to iron out
<sforshee> graphics is the biggest one
<sforshee> most of the drm drivers rely on having access to the vbios, which doesn't seem to be possible in EFI boot
<mjg59> Sure it is
<ericm|ubuntu> sforshee, yeah that's one issue
<mjg59> But Apple don't provide it on Radeon-based machines for reasons that are unclear
<mjg59> You can work around this by grabbing it out of the firmware during boot services and handing it off to the kernel
<mjg59> I've a patch for grub that does that, but haven't forward-ported it to grub2 yet
<sforshee> mjg59, thanks for the explanation. I confess I haven't looked into it much yet.
<mjg59> But yeah nvidia is going to work badly on EFI Macs
<mjg59> nouveau is a much better choice there
<awe> bjf, any idea who I talk to about problems with ubuntu-bug?  I tried to run 'ubuntu-bug -p linux' and it just returns on my system...
<awe> I have a power-mgmt problem which I guess I'll report directly via LP, and then try to apport attach...
<bjf> awe, i think pitti knows more about ubuntu-bug than anyone 
<Sarvatt> awe: its ubuntu-bug linux
<awe> Sarvatt, someone should fix: https://wiki.ubuntu.com/Kernel/Bugs
<awe> cause that's where I got the command-line from
<awe> '$ ubuntu-bug -p linux'
<Sarvatt> sorry about that, fixed the wiki
<Sarvatt> -p linux is for apport-collect
 * ppisati -> brb
<philipballew> If i install a mainline upstream kernel to fix a bug, does that mess up updating from the repos or will it detect my newer kernel?
<apw> o
<apw> ogasawara, the enforcer deliberatly uses the enforcer file on master ... so that the rules are consistant on all branches
<ogasawara> apw: just saw your email
<apw> ogasawara, and it has expressive power in theory at least to allow different rules to be expressed for different flavours
<ogasawara> apw: will yank the patch from master-next
<apw> ppisati, you gave the arm peeps a way to test with an initramfs-less kernel didn't you, using the overlapping partition tables with puid fields ... right ?
<GrueMaster> apw: being one of those arm peeps directly involved with testing, I have heard nothing yet.
<jsalisbury> cking, another overheat related bug reported, bug 953205  Looks like the same type of hardware as bug 751689 so it may be a duplicate.
<ubot2`> Launchpad bug 953205 in linux "System shuts down due to CPU temp exceeding critical thresh-hold (100C)" [Medium,Confirmed] https://launchpad.net/bugs/953205
<ubot2`> Launchpad bug 751689 in linux "ThinkPads overheat due to slow fans when on 'auto'" [Critical,In progress] https://launchpad.net/bugs/751689
<cking> jsalisbury, cool, I was talking to tony about that early
<cking> earlier
<jsalisbury> cking, ahh, ok.
<ohsix> are the fans on the thinkpad not managed by acpi or are the thermal zones just wrong?
<cking> ohsix, they can be managed by the firmware or by the thinkpad_acpi driver (by prodding the EC memory if I recall correctly)
<ohsix> interesting
<ohsix> also strange that even if you can do it with thinkpad_acpi, TMM1/2 don't work; or the critical thermal zone in acpi doesn't overrule it
<cking> it's all in the thinkpad_acpi driver if you want to see the gory details 
<ohsix> okie dokie
<cking> jsalisbury, I hacked up some code to monitor what's going on so I can get an idea of what's causing the grief
<jsalisbury> cking, cool.  I can reproduce an overhead pretty quickly on my x201, so I can do some testing if needed.
<cking> jsalisbury, so is this happening more with precise than oneiric? 
<ohsix> burnmmx ftw
<jsalisbury> cking, In my case, I would say it happens the same.  My laptop will overheat and hit 100C shortly after kicking off a kernel build.
<jsalisbury> cking, That was also the case in Oneiric
<cking> jsalisbury, ok - that's bad, but not looking like a glaring regression.
 * cking --> EOD
#ubuntu-kernel 2012-03-13
<vindex> hello
<vindex> ive built a vanilla 3.2.10 kernel with perf enabled, since i wnated to use the performance counters for a personal project
<vindex> with make-kpkg i get the different deb packages, however the perf tool consistently fails the symbol test
<vindex> if i boot the same kernel with qemu and into a debian/ubuntu qemu image, the perf tool works fine
<vindex> can the linux-tools packages get built through make-kpkg as well?
<bullgard4_> '~$ nmon' > r prints: " Linux: Linux version 2.6.32-38-generic (buildd@zirconium)." Is Â»builddÂ« the username of a computer named Â»zirconiumÂ«? What kind of user is that?
 * apw yawns ... another 80MB of updates
<ppisati> moin
<apw> ppisati, morning
<smb> morning... lots of fun to look forward to
<apw> smb, a shiney new unity ... i wonder what fun that brings ... any guess where the keys are today
 * smb needs to install the shiny thing to know...
 * apw watches it install ... excitemente
<smb> apw, At least nothing gets removed... I think I saw in the upload mails that this will be famous 5.6 we have all been waiting for... 
<apw> yeah what did 5.6 contains that we needed ?  was that the alt not being annoying one ?
 * ppisati loves the smell of apw's positivty wrt to unity in the morning :)
<smb> apw, yes I think so (or generally the "even without multitouch you can press two keys at once, now stop giving me the help screen on super+something"
<apw> new flash it seems in the bargain
<amitk> apw: hehe. Over on this side of the fence, work has ground to halt as everyone upgrades the galaxy s2 phones to Android 4.x and deals with the consequences :)
<apw> heheh ... that sounds fun
 * ppisati -> reboot
<apw>     - Dash - update Dash keyboard shortcuts so the 'CTRL + TAB' switches
<apw>       between Lenses and 'TAB' by itself moves the focus between categories
<apw> new keybindings ...
<apw>     - Alt+Tab default delay of 150ms is too long (LP: #888636)
<apw>     - Numbers on Launcher icons sticking (LP: #942359)
<ppisati> so far, so good
 * apw reboots to get the new shiney
 * smb wonders whether you need fps experience to have the reflexes required to operate it...
<ppisati> unity2d: works here, still no overlay shortcut text and (thanks God) still no launcher on the second screen (with that bloody sticky edge)
 * smb ready to do the same (reboot)
<apw> well i was able to reboot and login ...
<apw> glad to see they havent fixed the help 
<smb> at least it does not come up when you press super+alt...
<ppisati> btw, did you see that the unity/UX/usability/$something_team is running a poll about multi screen setup + multi launcher setup?
<apw> ppisati, nope, where is that as i want to be chosing
<ppisati> you can even vote AGAINST sticky edge on the second screen and multi panel setup
<ppisati> hold on
<ppisati> nope
<apw> ppisati, though asking me to chose when i can only try one of them is a bit daft
<ppisati> actually the poll is "omg ubuntu" made for the unity team
<ppisati> big cockup... :P
<apw> oh so that won't have any input then
<ppisati> yep :(
 * ppisati curls in sadness in a corner, you can't stop the sticky screeny edge, they will assimilate us...
<apw> heheh
<smb> Hm, still got the issue that clicking on an existing app in launcher moves the app and not the viewport... :/
<smb> at least for some of them
<apw> smb, i still get launcher and help on pressing super-alt together if super is the first key that closes ... however short a time
<smb> apw, Yes, true. same here
 * apw also notes the resize space round a window has stopped working so you have to hit the 1px again
<jk-> alt+right drag?
<smb> apw, hm there seems to be some space to left and bottom at least
<apw> jk-, oh i know how to get round it, but i doubt its expected to have gone
<apw> smb, not for me
<smb> to the right as well if only that stupid hidden scrollbar would not be
<smb> top is only 1px...
<apw> not any side for me, i have 1px and 1px only everywhere
<smb> apw, the special apw settings ...?
<apw> perhaps so .. sigh
<smb> apw, Or maybe... is that on a external screen?
<apw> nope all of 'em
<smb> Just was wondering whether the issue rises because there is more than one screen, which I do not have
 * apw doesn't really care ... i have it ... and so a bug i will file
<smb> Given the speed of updates one feels like the white rabbit... I am too late for updates... I am too late for updates...
<ppisati>  /msg smb ping
<ppisati> ops
<smb`> apw, For fun I did bug 953858
<ubot2`> Launchpad bug 953858 in unity "Selecting running app in launcher moves app not viewport" [Undecided,New] https://launchpad.net/bugs/953858
<apw> oh thats oss as it does not do that smb` 
<apw> (for me)
<apw> heh .. that looks odd indeed
<apw> mention the bug on #ubuntu-unity
<smb`> apw, Since you said you do not use multiple desktops that much, you would less likely. And it does not seem to happen with all applications
<apw> oh dear thats most odd, oh yeah and i would have to start using them to hit it
<apw> ppisati, in your precise/ti-omap4 rebase i see two commits i am not expecting ... right at the bottom of your delta ... 
<apw> ppisati, UBUNTU: SAUCE: ata_piix: defer to the Hyper-V drivers by default
<apw> ppisati, UBUNTU: ubuntu: nx-emy - i387: NX emulation
<apw> ppisati, i am not expecting either of those to be in your delta
<apw> ppisati, if you concur i can just rebase them out of existance
<ppisati> apw: let me check
<apw> sudo aa-disable sbin.dhclient
<ppisati> apw: go ahead with those two commits, seems i rebased on master 
<ppisati> apw: and these were there
<apw> ppisati, so drop them yes
<ppisati> flag
 * apw takes that as a yes
<ppisati> apw: yes
<apw> ppisati, ok uploaded ...
<apw> ppisati, and i've prepared linux-meta ready for when its built
<ppisati> apw: cool
 * ppisati fails to understand poll() and decides it's time for lunch()
<apw> cking, about ?  your ecryptfs patches presumably are for arm too
<cking> apw, yep and yep
<apw> cking, applied and applied
<cking> ta
 * apw lunches
<ogasawara> apw: just fyi, I've rebased master-next to v3.2.10 which happened to also include the fix for CVE-2012-1146 you pushed
<ubot2`> ogasawara: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1146)
<brendand> if i have a 2GB DIMM installed on a system and /proc/meminfo is only reporting 1653076 kB for MemTotal, what accounts for the lost megabytes?
 * ogasawara back in 20
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> jsalisbury, thats in 2 hours from your announcement right 
<jsalisbury> apw, correct.
<jsalisbury> apw, it's an hour later in the US now due to the recent daylight time change.
<smb> weeks of confusion have begun :)
<apw> jsalisbury, thought so ... just checking you were on the same page as me
<smb> bjf, uploading :(
<bjf> smb, heh
<arges> jsalisbury, did I lose audio?
<jsalisbury> arges, I don't think so
<henrix> apw: still under analysis, but i would say bugs 922906 and 924400 are the same
<ubot2`> Launchpad bug 922906 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c" [Medium,In progress] https://launchpad.net/bugs/922906
<ubot2`> Launchpad bug 924400 in linux "kernel NULL pointer dereference at 00000000000001f0" [High,Incomplete] https://launchpad.net/bugs/924400
<henrix> apw: (can't speak on mumble!!!)
<henrix> apw: i've been looking at these bugs, and they seem to be a common issue w/ unmount and inotify
<apw> smb, whats your trick for fixing speaking on mumble
<smb> either restart
<smb> or change output from pulse to alsa and back
<henrix> heh i'll try that one. actually, it looks like my push-to-speak keys are not working...
<apw> umount and inotify ... hmm ... that rings a bell, i wonder if there was someting committed to linus recently
<apw> henrix, ahh did you add a keyboard since mumble started, that can break PPT keys
<smb> henrix, That sometimes seems to be because mumble tries to play something but cannot
<henrix> well, it's working now!
<henrix> thanks
<apw> its basically a frigile POS ...
<apw> bjf, i see a small formatting error in 'eCryptfs: Copy up lower inode attrs after setting lower xattr'
<apw> bjf, and i'd like to rebuild tip to fix it (buglink is missing prefix)
<bjf> apw, wfm
<bjf> apw, master or master-next ?
<apw> this is master-next
<bjf> apw, series?
<apw> master is 'tough its done'
<bjf> apw, you can do anything to master-next :-)
<apw> bjf, i need to check lucid natty and oneiric
<apw> just you are pushing too :)
<bjf> apw, we should be done now, i fixed a commit for colin this a.m. and am done
<apw> bjf, ahh i see now, its actually an upstream link so its as intended... 
<apw> cking, ok your patches for bug #926292 didn
<ubot2`> Launchpad bug 926292 in linux "automake distdir.test fails because of an EPERM error" [Medium,Fix committed] https://launchpad.net/bugs/926292
<apw> didn't have a proper buglink, most are already past the point of fixing, so you'll have to move them Fix Released manually ...
<cking> ack
 * apw gets blinded by the sun ... gah
 * ogasawara throws a snowball at apw
 * apw gets snow blinded as well
 * smb doubts it would hit apw at all (being melted before ;-))
 * apw lobs an iceburg in smb's direction
 * smb wonders how that castle looks like
<smb> (burg being castle in de) 
<apw> heavy and inbound
<apw> ogasawara, do they even build test upstream stable ... 
<ogasawara> apw: apparently not
<smb> apw, sometimes it feels like "he" claims he does
<apw> so much for the claims of testing it
 * jussi hides from the snow fight...
 * apw gets out big digger and uses it to heave a 25 tonne snow drift onto jussi
<smb> apw, Question is what config is used (something like make alldontcareconfig)
<apw> allnoconfig perhaps
<ogasawara> heh
<apw> if it wasn't so hard to consume they could let us autobuild the -rcs for stable
<jussi> apw: be nice! :(
<apw> oh no, that might be seen as contributing and he cannot be seen letting us to do that
<smb> apw, The trigger may be hard. Though the queue is applicable when the review starts
<smb> git quiltimport --patches=<foo>
<apw> if it was a git repo like it is once it is released then the current autobuilder could be pointed at it
<smb> Right, that would be too simple
<apw> /home/apw/COD/linux/drivers/mfd/wm8994-core.c:260: error: 'WM1811_JACKDET_MODE_MASK' undeclared (first use in this function)
<apw> that said the mainline builds built the tag and barfed instantly as above
<ohsix> broooooooonie
<apw> smb if they just pushed the -rc1 things he does, we could send him the reports ... sigh
<smb> apw, Problem seems to be that he seems to be unable to handle branches. Or he is just a je... One or the other
<henrix> cking: about bug #926292, i've tagged it verification-needed-oneiric. although the commit is queued for stable, i guess you'll want to test it, right?
<ubot2`> Launchpad bug 926292 in linux "automake distdir.test fails because of an EPERM error" [Medium,Fix committed] https://launchpad.net/bugs/926292
<cking> henrix, yep, I'd like to hand verify it 
<henrix> cking: ok, cool. just to confirm that
<cking> I'm just preparing a machine to test it as we speak, so good timing ;-)
<henrix> heh
<henrix> no hurry! :)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Mar 20th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<desrt> hi.  does anyone know what the status of ext4+'discard' (ssd TRIM) support is?
<desrt> is this stable enough to be considered a best standard practice for use with SSDs at this point?
<cking> henrix, verification complete :-)
<henrix> cking: cool, thanks!
<apw> ogasawara, you will be pleased to know there is now a 3.2.11 which builds
<ogasawara> apw: nice
<ogasawara> apw: I'll get 'er rebased
<apw> ogasawara, the mainline builder just announced it, and it seems built ok on all arches
<johanbr> Hmm... it appears brcmsmac stopped detecting my wifi card some time after 3.2.0-12
<johanbr> 3.2.0-12 works, 3.2.0-18 doesn't
 * jsalisbury is updating bios.  Back in a bit.
<bullgard4> '~$ nmon' > r prints: " Linux: Linux version 2.6.32-38-generic (buildd@zirconium)." Is Â»builddÂ« the username of a computer named Â»zirconiumÂ«? What kind of user is that?
<apw> bullgard4, buildd is the user under which builds in ubuntu are 
<apw> built on the buildds
<bullgard4> apw: Thank you very much for your help.
<ah-> hi, i'm playing with kernel development on ubuntu and i'm wondering what's the best way to do incremental compiles
<ah-> at the moment i'm compiling my kernel according to http://blog.avirtualhome.com/2011/10/28/how-to-compile-a-new-ubuntu-11-10-oneiric-kernel/ and https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<ah-> my problem with that is that after i change something "skipabi=true skipmodule=true fakeroot debian/rules binary-mbp" doesn't include my changes if i don't do "fakeroot debian/rules clean"
<ah-> before
<ah-> but cleaning and doing a full build on every change takes a lot of time
<pbuckley> distcc is your friend
<ah-> so it's not possible to do incremental builds?
<ah-> i fear even with distcc/ccache it'll take ages
<pbuckley> i prefer to do full builds.. i think of it as safer
<pbuckley> i think if you do the plain old make
<pbuckley> you can do incremetal builds
<ohsix> if you're working on a module you can use the regular linux build stuff to test it
<pbuckley> ^^
<ah-> i'm doing that for a part of it but that doesn't work for everything
 * cking hammers ecryptfs with a kernel build and calls it a day, /me --> EOD
<apw> ah-, you can remove the build stamp in debian stamps to get an incremental build
#ubuntu-kernel 2012-03-14
<bryceh> ogasawara, almost hate to mention it but I got my hands on a system that dislikes rc6 - lp #954660
<ubot2`> Launchpad bug 954660 in linux "Intel DH67GD board w/ i5-2405S cpu fails to boot with rc6 enabled" [Undecided,Confirmed] https://launchpad.net/bugs/954660
<ah-> thanks a lot apw that's exactly what i was looking for
<ogasawara> bryceh: thanks, I'll contact eugeni
<smb> Another 70M since yesterday... yay...
<apw> smb, 70 ... sigh
<apw> smb, 77 for me, and another new unity
<smb> Must have some different packages and/or other things installed. Btw, we should have another kernel. The last one is so long ago... :-P
<ppisati> moin
<smb> ppisati, ciao
<apw> smb, so last week
<ppisati> 90 new pkgs
<ppisati> cool
<smb> "thank you for joining the mozilla test pilot team"?!? wtf!
<apw> smb, oh i saw that on one of my test boxes yesterday evening too.  thought i'd clicked something by mistake ... perhaps not
<smb> apw, No I guess because they gave us a beta version... bah
<apw> why so i want a beta version in an LTS
<smb> because you can?
<apw> oh sorry silly me, rules don't apply to everyone, lets upload 3.3-rc7 today
<smb> apw, There are rules? rules are so last week... :-P
<apw> so last cycle
<apw> smb, interesting, just started firefox here (not my normal browser) and not such popup
<smb> apw, The test pilot thing was a tab, but weird anyway
<smb> !#$&, do I only have to reboot to apply the changes or did they steal alt-tab
<ubot2`> smb: Error: I am only a bot, please don't think I'm intelligent :)
 * smb reboots to see whether that brings back alt-tab
<apw> well i guess it boots
<smb> It seems to...
<smb> alt-tab is lost though
<jjohansen> apw: how would you like updated apparmor kernel patches? tree with reverts, and patches that match versions that I am push upstream, or just the diffs.  There will be a rebase against what gets upstream coming at some point too
<apw> jjohansen, for P i think reverts and new patches is simplest then we can rebase the old ones out of existance
<apw> anything shiney in this one ?
<jjohansen> apw: that is what I figured, nothing shiny just bug fixes and changes based on upstream review
<jjohansen> the shiny stuff will all be in M
<apw> jj M ?
<apw> jjohansen, ^^
<jjohansen> apw: haha, oops, I sorry I was looking at a maverick security/sru stuff when I wrote that
<jjohansen> apw: P+1, so Q
<jjohansen> :)
 * ppisati -> lunch
<jdstrand> jjohansen: wowo, 'M'. That is the *long* view :)
<jjohansen> jdstrand: well I like to plan ahead
<jdstrand> 'wowo'?
<jdstrand> jjohansen: :)
<ogra_> apw, poke
<ogra_> apw, i ran into bug 954243 yesterday, do you think it would be possible to make devtmpfs mount /dev/pts ?
<ubot2`> Launchpad bug 954243 in linux-ti-omap4 "booting pandaboard without initrd dies with "init: no available ptys"" [Undecided,New] https://launchpad.net/bugs/954243
<ogra_> (or tgardner ^^^)
<apw> ogra_, right ... it assumes you setup your environment before upstarts runs, it _assumes_ you have an initrd
<ogra_> exactly
<ogra_> that makes initrdless boot impossible
<apw> all this to save .1s
<ogra_> heh
<ogra_> did you measure ?
<apw> when boot currently is in the 50-70 range cause of a bunch of problems
<apw> no, but frankly it cannot be more than 5s
<ogra_> on arm its more like 15s
<apw> out of what 4m ?
<ogra_> given the bootloader needs >10s to read and shuffle the initrd in ram
<ogra_> my ac100 currently boots in 25s
<ogra_> omap4 is rather like 90-120s though
<ogra_> thanks to the slow bootloader and bad IO on SD cards
<apw> ogra_, ok ... acdording o jodh then if you add --no-log to the command line upstart should stop using pts and in theory you should be able to boot, can you test that for me?
<ogra_> apw, sure
<ogra_> will take a moment as my current install is totally trashed
 * ogasawara back in 20
<ogra_> apw, seems to help 
<tgardner> ogasawara, rebooting gomeisa for kernel update
<ogasawara> tgardner: ack
<tgardner> lets hope it comes back this time. I ran update-initramfs by hand
<ogasawara> hrm, am I really the only one in the mumble channel
<apw> ogasawara, nope you arn't in mine
<apw> cking, whats the story with your thinkpad fan investigation
<tgardner> ogasawara, are really there even now ?
<cking> apw, ongoing 
<apw> cking, james hunt is also seeing issues, he might be able to test
<tgardner> ogasawara, we can hear you
<ogasawara> tgardner, apw: we still looking to drop non-smp powerpc flavor?  If so, I best craft an email asap and try to get it dropped in the next upload.
<tgardner> ogasawara, yeah, please do
<tgardner> bjf, did cobbler_web get hosed on your servers after a recent update ?
<bjf> tgardner: no, i can update today and see if that changes
<bjf> tgardner: fully updated, still cobblering
<tgardner> bjf, hmm.
<GrueMaster> ppisati: Did something change with the 3.2 omap kernel after Beta1 that would screw with the serial console?  I am not getting much output after kernel boot, and it doesn't appear to start oem-config.
<tgardner> bjf, do you remember where cobbler/orchestra keeps its local mirror setting ?
<smb> tgardner, The ocherstra_proxy snippet?
<tgardner> taht might be it
<tgardner> smb, ok, where the hell is the proxy snippet? orchestra and cobbler have their bits splattered evrywhere.
<smb> tgardner, I normally go there via web but I guess you said its broken right now
<smb> give me a sec
<tgardner> yeah, for some reason
<smb> tgardner, Sorry took a bit. /var/lib/cobbler/snippets
<GrueMaster> ppisati: The problem seems to appear with 3.2.0-18.28.  The ubuntu-server 20120304/precise-preinstalled-server-armhf+omap.img.gz works, 20120305/precise-preinstalled-server-armhf+omap.img.gz fails.  Only difference is the kernel according to the manifests.
<GrueMaster> See http://paste.ubuntu.com/883454/
<tgardner> jsalisbury, henrix,jj: rebooting tangerine for kernel update
<GrueMaster> http://paste.ubuntu.com/883465/ is a good boot log.
<henrix> tgardner: ack
<ppisati> GrueMaster: ok, let me check
<ppisati> GrueMaster: so, what was the first kernel with this regression?
<GrueMaster> Note that this appears to be serial console specific and omap specific.  omap4 images work fine, as does the omap desktop images.
<GrueMaster> 3.2.0-18.28
<GrueMaster> linux-image-3.2.0-18-omap
<GrueMaster> here's the manifest diff.  http://paste.ubuntu.com/883486/
<ppisati> GrueMaster: ah, so it's an omap3-only think
<ppisati> *thing
<ppisati> ok
<GrueMaster> yes.
<ppisati> ok, i
<ppisati> ll take a look
<jodh> hi - I mentioned to apw earlier that bug 751689 is still impacting me on precise with 3.2.0-18-generic-pae kernel.
<ubot2`> Launchpad bug 751689 in linux "ThinkPads overheat due to slow fans when on 'auto'" [Critical,In progress] https://launchpad.net/bugs/751689
<apw> cking, ^^
<jodh> If I fire up say 4 kvm instances or try to build eglibc, the machine just performs a controlled shutdown. It's been freaking me out a little actually as I didn't realize it was this kernel issue re-occuring.
<cking> apw, /me on the phone
<jsalisbury> cking, I was able to overheat and crash my system.  I'll send you the data.
<jodh> This is on a Lenovo T410 thinkpad with Nvidia graphics. FTR, I have not touched the BIOS since I bought it (around October 2010).
<jodh> dmidecode says BIOS version is "Version: 6IET72WW (1.32 )" dated 08/27/2010.
<cking> jodh, let me send you an email with a description of a tool to try out to capture the failure mode
<jodh> cking: that'd be great, thanks.
<cking> jodh, once we've got some data I can see what's going on and feed this back to Lenovo
<jodh> OK. It looks like the kernel emits an acpi netlink event when the less critical "hot" state is reached - should some other part of the system be handling that and popping up a window explaining to the user, or maybe trying to forcibly ramp fans, etc?
<jodh> Having the system just die on you is kinda alarming ;-D
<apw> jodh, wuss
<jodh> maybe the kernel needs a OOT killer - shutdown the processes that are chewing too much power to try and avoid the forced system shutdown?
<tseliot> apw, cking: any ideas as to why trying to build a drm module out of the tree would result in "make" ignoring the driver's makefile? I'm getting this "make -f scripts/Makefile.build obj=/var/lib/dkms/drm-dkms/3.2/build/staging/cdv" and then "(cat /dev/null; ) > /var/lib/dkms/drm-dkms/3.2/build/staging/cdv/modules.order"
<tseliot> apw, cking: full output http://paste.ubuntu.com/883504/
<apw> tseliot, what is missing ?
<tseliot> apw: cdv should build as the gma500 module does (they're both in staging and enabled in the config file)
<apw> can we see the Makefile
<tseliot> apw: my staging/Makefile: http://pastebin.ubuntu.com/883554/
<apw> and in the cdv directory ?
<tseliot> apw: the main Makefile: http://pastebin.ubuntu.com/883557/
<tseliot> apw: staging/cdv/Makefile: http://paste.ubuntu.com/883561/
<tseliot> apw: ignore the default target, I get the same error without it
<apw> obj-$(CONFIG_DRM_INTEL_CDV) += cedarview_gfx.o
<apw> try making that line obj-y +=
<tseliot> ok
<apw> you may not have that config set in the third level
<apw> as they normally come in via the config, and you are cheating i think
<tseliot> apw: same result. And it's a bit weird to see that I can enable gma500 in my Makefile but it won't work with cdv
<cking> jodh, I suspect we should handle that event and crank the fan up to full tilt
<apw> tseliot, can i have the fma500 Makefile too pls
<apw> cking, there is a framework for acpi events to shell commands which could do it, but its not very reliable compared to doing it in the kernel
<tseliot> apw: staging/gma500/Makefile: http://paste.ubuntu.com/883572/
<tseliot> apw: and I'm building with "sudo make KERNELRELEASE=3.2.2-030202-generic all KVER=3.2.2-030202-generic V=1"
<apw> and what does this do on its own:
<apw> make -f scripts/Makefile.build obj=/var/lib/dkms/drm-dkms/3.2/build/staging/cdv
<apw> and indeed this:
<apw> make -f scripts/Makefile.build obj=/var/lib/dkms/drm-dkms/3.2/build/staging/gma500
<apw> tseliot, ^^
<tseliot> apw: make: scripts/Makefile.build: No such file or directory
<apw> oh you'd need to run those in /lib/modules/`uname -r`/source
<apw> or is it /build
<tseliot> apw: right, /lib/modules/3.2.2-030202-generic/build/scripts/
<apw> tseliot, ok my next debug attempt would be to mv cvd cvd-keep; cp -rp gma500 cdv
<apw> and see if it builds 
 * henrix will be out for ~20min
<tseliot> apw: sudo make -f scripts/Makefile.build obj=/var/lib/dkms/drm-dkms/3.2/build/staging/gma500 doesn't seem to do anything (I created a link to the path to scripts)
<tseliot> ok
<apw> tseliot, perhaps :%s/psb_gfx/psb_gfx2
<apw> so you get two different modules
<tseliot> apw: ah, ok
<apw> tseliot, that should tell us if its the subdir that the issue, or the staging levle
<tseliot> right
<tseliot> apw: yes, the module was built in ./staging/cdv/psb_gfx2.ko
<tseliot> so I guess it's just the subdir
<apw> ok so its something to do with the makefile in cvd then
<apw> so i'd start deleting bits of it now
<apw> you got rid of default: already yes
<tseliot> apw: yes
<apw> tseliot, check the filenames are sensible ... i am a little worrried that the ENVDIR etc might need $(src)/ on the front
<apw> i am unsure what would happen if none of the filenames point anywhere in ceadaview_gfx-y ... that might do nothing
<tseliot> apw: good point, let me try
<tseliot> apw: nothing seems to have changed and I added a staging/cdv prefix to those variables: http://paste.ubuntu.com/883613/
<tseliot> I could've used $(INCDIR) but it shouldn't change much
<jodh> cking: agreed. I've raised bug 955287. Am running tp-thermstat now...
<ubot2`> Launchpad bug 955287 in acpi-support "Ubuntu should handle "hot" CPUs by taking preemptive action and warning users" [Undecided,New] https://launchpad.net/bugs/955287
<cking> jodh, ack, let me see what else we can do in the driver too
 * ppisati -> goes out to get some stuff
<tseliot> apw: thanks for your help
<apw> tseliot, did you win ?
<apw> ccccccbgbcivibcrdlbefnuhnilivbfndklfhuigdbvd
<tseliot> apw: no, but you tried to help and at least now I can exclude one case
<ogra_> apw, manually generating md5sums ?
<tseliot> :D
<apw> ogra_, heh no playing with a password generator
<ogra_> use a cat on the kbd ... gets you the safest PWs in the world ;)
<apw> and unity is helping out by letting my output go to the most annoying window
<tseliot> hehe
<tseliot> apw: progress!!! I had to change  the last line to obj-m
<apw> tseliot, erp
<apw> oh you wanted a _module_ of course
<apw> so you want the FOOO=y -> FOOO=m
<apw> the CONFIG_xxx_CDV=m
<tseliot> apw: yes, I don't know why I haven't thought about it before
<apw> tseliot, cause it is tooo obvious
<tseliot> apw: good point :D
<ogasawara> tgardner: I'm out tomorrow and friday, but I'll still plan to upload sometime friday.  Andy's going to cover the release meeting for me.  Could you however keep an eye on that powerpc thread for me.
<tgardner> ogasawara, can do.
 * ogasawara lunch
 * cking --> EOD
 * tgardner -> EOD
#ubuntu-kernel 2012-03-15
<smb> morning
<cking> morning smb
<ppisati> cool, last dist-upgrade broke empathy :(
<smb> ppisati, Isn't that the "normal" behavior?
<ppisati> brb
 * apw reboots for 37M of new shiney bits
<alexbligh1> is it intended to have a precise-backports kernel for lucid, the same way as we have a oneiric-backports and a natty=backports?
 * ppisati -> out for lunch
<apw> alexbligh1, no, we are not intending to make that combination
<smb> herton, You reckon it is ok to also apply the changes for the cve to maverick master-next, even with a chance that it won't get released in case there is nothing urgent? I sort of completely managed to not read the announcement carefully enough that it should slowly go out of updates.
<smb> Otherwise I'd go ahead and apply them (hopefully not clashing with tgardner )
<tgardner> smb, I've not started, so you've got the ball
<herton> smb, hmm, may be we should wait, unless the CVE is critical enough to have a release
<smb> tgardner, Okay will do
<smb> herton, It is maybe in between
<smb> Not really critical but on the other hand allows a normal user to crash a kvm guest (32bit)
<smb> herton, But given it is unclear, I'll leave out M for now
<herton> smb, ok, we have to see, if security thinks it should be released, I think bjf mentioned jj should do a review of CVEs that still are pending and should go
<smb> herton, Yes, he did. Ok then, pushing all but M
 * apw is unclear why we would not apply the thing and include it _if_ there is another upload
<apw> its most likely to get lost if you don't apply it, and if we have it, and we do another upload, i cannot see why we would not include it
<apw> the review with jj is about which ones we can not bother with the effort to do them, if its no effort or already done ...
<apw> plus you can always rebase them out of existance
<herton> I don't see any problem as well in applying too, if no one bothers that may be what is in master-next will not be released
<herton> yes, it could be rebased/removed later
<smb> herton, apw Ok, so that means I should apply it and it can be decided later to drop it? (just wanting to confirm,)
<herton> smb, yes, just apply it, in the worst case we can remove it from master-next later
<smb> allrighty then
<cba123> I'm getting random freezes, on 11.10 (3.0.x kernel).  In my logs I recall seeing "rcu_sched_state detected stall on CPU 0" which I've seen other people have too.  They say they went to 3.2.x and the issue seems to have cleared.  Can I go to the Precise repo for the kernel and go back, or is there an Oneric backport kernel repo I don't see?
<apw> cba123, those may well show up in syslog so you might look there.  there is no official 3.2 kernels for oneiric no
<cba123> apw, Yes, so I'd imagine that the rcu is the effect not the cause?
<apw> yep, its just telling you something got stuck somewhere... though the stack trace can often help
<apw> you might be able to get a stack trace with sysrq when it does hang
<cba123> What do I use for a stack trace, or sysrq?
<desrt> good morning
<desrt> who is the curator of all things drm?
 * desrt is testing http://lists.freedesktop.org/archives/intel-gfx/2012-March/015486.html
<bullgard4> 'man apt-cache': "blue lines are pre-depends, green lines are conflicts." How are Â»pre-dependsÂ« defined?
<lamont> if I throw a 3.2 kernel on lucid, how much breaks?
<tgardner> lamont, shuold work
<tgardner> lamont, we've got 3.0 kernels on Lucid
<lamont> well, I know there are userspace things that git a tad bit annoyed at != 2.6.X, no?
<lamont> or is that mostly just build time issues
<lamont> ?
<tgardner> lamont, mostly build time issues, though IIRC there was a user space package that complained.  Maybe DKMS ?
<lamont> cool.  I may try that step, or I may just shove the box into precise
<smb> Though wasn't the problem more of a "who stole the third digit"?
<apw> tgardner, are you or leann handling the upload the end of this week ?
<tgardner> apw, leann said whe'd be around tomorrow long enough to do it.
<lamont> Mar 15 08:53:21 wfg-gw kernel: [244607.623349] nf_ct_sip: dropping packetIN=eth0 OUT= MAC=00:0e:0c:5c:1c:78:00:0c:85:be:5a:85:08:00 SRC=192.168.133.192 DST=192.168.133.1 LEN=591 TOS=0x10 PREC=0x40 TTL=64 ID=57781 PROTO=UDP SPT=51374 DPT=5060 LEN=571 
<lamont> mostly, I want to stop having logs full of that
<tgardner> lamont, ah, you're still having that issue.
<lamont> 72MB/day of that issue
<lamont> 2.6.32-39-generic-pae
<tgardner> well, 3.2 is worth a try
<apw> lamont, i think ps will start moaning a bit about the kernel version
<apw> lamont, mostly it was package building which was a bit suspect in that combination
<lamont> right.  upgrade it is then
<apw> lamont, builds with checks for 2.6.x and similar in them
<apw> there is a personality flag, which allows the kernel to report itself as 2.6.39+N i think it is
<lamont> yeah
<lamont> so lets say I have / on /dev/md2 (swraid1), and I want to migrate to having it on an LVM volume on the same thing... Can I: remove one drive from the array, mdadm create -f on it, pvinit it, pvcreate, vgcreate, lvcreate, mount, sync, reboot onto the half-there md3, and then mdadm --add the other drive and be all shiny and happy?  or is that crazytalk?
<lamont> (yes, backup first, because I care)
<lamont> s/sync/rsync/
<tgardner> lamont, AFAIK each of those steps ought to work, though I think you'll be pioneering....
<lamont> tgardner: heh
<lamont> my biggest concern is making sure that the *^)*^( swraid doesn't decide that it wants to readd the second drive backinto the original raid and trash all my work
<lamont> but if it's already a new array, there's little risk of that
<lamont> if lvm is installed, and root is not on lvm, does lvm get all its pretty hooks into the initrd still?
<lamont> because not having lvm in the initrd on that reboot would suck
<tgardner> lamont, that I can't tell you. I've mostly used mdadm.
<lamont> np
<smb> lamont, I think it is in there when it is installed
<lamont> just one more thing to verify before the reboot
<lamont> smb: that would be suitable for my interests
<bullgard4> [solved]
<smb> lamont, Actually my local machine is done that way. So you should be ok. (after all those test installs I cannot remember reliably what I have done where)
<desrt> So I filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/956046 and built a kernel package with the patch.  It fixes the issue.
<ubot2`> Launchpad bug 956046 in linux "intel driver fails to use dual-link LVDS if lid is down at boot" [Undecided,Confirmed]
<desrt> not sure if it causes other issues, of course.... :)
<ppisati> GrueMaster: 3.2.10 (that's in master-next) fixes the serial problem we have with omap3
<GrueMaster> Cool, thanks.
<hrw> hi team
<hrw> can someone take a look at http://pastebin.com/LwtJ6jzm patch to kernel packaging? first hunk disables build of tools for cross compilation (we do not have all libraries multiarched for it yet), second is irrevelant now but will be needed when we will be able to cross build tools
 * ppisati -> out
<tgardner> hrw, email it on kernel-team@lists.ubuntu.com where it'll likely get a bit more attention.
<Laibsch> Can somebody please accept the lucid nomination for the critical bug 745836?  This has caused data corruption and frequent crashes in essential pieces of software like OOo.org for more than a year now.  Patch is available and landed in natty and beyond.
<ubot2`> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed] https://launchpad.net/bugs/745836
<tyhicks> The bug Laibsch is talking about was actually an eCryptfs bug, despite the confusing bug title.
<tyhicks> It was a pretty simple patch, but I don't know how it applies to a kernel as old as Lucid's
<ohsix> if it's a known bug, patch and SRU shouldn't be hard
<Laibsch> ohsix: do you have upload rights to the kernel?  My experiences with "patch served on a platter" for even highly important bugs has been less than good.
<ohsix> eh, you mean important by your own criteria; or your own SRU requests?
<Laibsch> highly important as in "mass-market netbook without wifi support for more than half a year" even though upstream kernel had a patch after two days
<Laibsch> no amount of bugging and begging got anyone's behind moving :-(
<ohsix> was there an SRU
<ohsix> or was it discovered before a release
<Laibsch> that was for lucid at the time it was in development
<Laibsch> January 2010
<Laibsch> ohsix: will you also answer my question now: do you have commit rights?
<ohsix> that question isn't relevant, but no; what would it even mean to have "commit rights", to the bzr on launchpad? people don't just shove things in there to get them into packages ...]
<tyhicks> Laibsch: To be fair to the kernel team, this one was extremely hard to debug. IIRC, it wasn't known that it was an eCryptfs issue for quite some time and then once that was determined and I was notified, it took me quite a while to debug it and fix it upstream.
<tyhicks> Reading back through the report, it seems that I stumbled upon the fix after removing some crufty code and noticed that the problem went away. That led me to the actual cause.
<Laibsch> ohsix: if you consider commit rights irrelevant I'm not even sure there's a point to talk.  That question is so obviously relevant, there's no need to discuss.  tyhicks would fix the issue if he had the powers, but he doesn't.
<cking> tyhicks, so this just needs backporting to lucid and testing then? I can look at that one
<ohsix> heh why is there still so many random encrypt-x things in use when you can use dm
<tyhicks> cking: It sounds like it
<ohsix> Laibsch: there's a process, it doesn't sound like you know it; that might be a component of why something so important seemed ignored
<Laibsch> tyhicks: I remember the troubles in pinpointing that problem.  And I'm not faulting anyone for 745836.  I'm just afraid that lucid might experience a repeat of the sluggish, non-response I've seen in other problems earlier.
<cking> tyhicks, OK - I will slap it on my todo list then
<tyhicks> cking: A couple helpful links...
<ohsix> just because cking was here this time ... !
<tyhicks> A description of the problem: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836/comments/86
<ubot2`> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed]
<cking> nice, I can even write a testcase and add it to the ecryptfs tests
<tyhicks> cking: A simple patch which should fix it in old releases if you don't want to backport the upstream changes that luckily solved the problem: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836/comments/87
 * tyhicks remembers that he needs to merge cking's latest test suite changes sometime this week
<cking> OK - I will see if I can get around to this tomorrow or monday
<ohsix> cking: but do you have commit rights?!?!!1111
<cking> I can do the SRU work, do the testing etc, I've been doing ecryptfs SRU's over the past few weeks, so it's my bread-n-butter
 * cking will give it the love it requires
<ohsix> nice, but i can't make the joke i was going to had you said yes
<ohsix> well, thanks for speaking up; maybe i was explaining things poorly but it didn't seem to be getting any traction
<cking> glad you mentioned it, somehow I missed that one, and I've looked a a bunch of these over the past few weeks
<cking> tyhicks, is it OK just to use the simple patch in comment 87 rather than backport the other two patches?
 * cking being lazy
<tyhicks> cking: Let me take another look at those two patches. My mind is going almost completely blank on this bug...
<ohsix> who would have thought where you store your pages would be important
<tyhicks> cking: Yes, it sounds like I was pretty confident that the simplified patch in comment 87 was the real fix and the upstream commits just covered everything up. I _know_ that I wouldn't have attached that patch without testing.
<cking> sure - thanks for checking
<lamont> tgardner-lunch: missing step: update mdadm.conf to reflect the new array, so that the vg is found
<lamont> \o/
<tgardner-lunch> lamont, yeah, I always have to go to the wikipedia page for mdadm to remember that.
<lamont> yeah, nothing quite like not finding the root partition
<hrw> tgardner: sent
 * tgardner -> EOD
<_ruben> EOD .. that's the dutch abrev for the bomb squad .. guess he hadda run ;)
<unwired> Hi, just found a bug in kernel 3.0.0-17.30 from onieric-proposed, but I'm not sure where to report it...
#ubuntu-kernel 2012-03-16
<bullgard4> [Linux T61 3.0.0-16 server #29-Ubuntu SMP] Why does '~$ nmon' > m state "Slab=119,1 MB" but /proc/meminfo is empty?
<infinity> cooloney: In fact, the only thing that's saved jani's ac100 kernels from not overlapping due to ABI conflicts is that he was versioning as 3.0.19 instead of 3.0.0. ;)
<infinity> cooloney: I've already asked him to switch to 3.2.0-foo when he revs to 3.2.0, so he'll need a unique ABI range too.
<infinity> cooloney: So, yeah.  A table in the wiki (or maybe even in the base git packaging templates?) that defines the out-of-tree-flavour to ABI-range mappings would be nice.
<cooloney> oh, that's interesting
<infinity> cooloney: Grandfathering in the ones we already have (omap4, armadaxp, highbank, and some linaro kernels)
<cooloney> apw: hey, andy, do we have a wiki page about ABIs like infinity said
<infinity> cooloney: And making it clear to people that those ranges belong to the out-of-tree flavours, and they shouldn't CHANGE (like they did for omap4...)
<cooloney> infinity: yeah, we need document it
<infinity> (Not that changing is a problem in itself, just that it eats more namespace, and soon all the flavours will be using ABI versions in the tens of thousands) :P
<cooloney> infinity: if we enable ubuntu kernel for every ARM stuff, it will explode soon
<infinity> Heh.
<infinity> A bit, but such is life.
<smb> Life... don't tell me about life... :-P
<cooloney> smb and ppisati do you guys know whether do you have a wiki page about abi numbers.like ti-omap4 is 1400
<smb> cooloney, yes
<cooloney> since we are going to use 1600 for armadaxp 
<cooloney> and 1800 for highbank 
<smb> Now to find it (again) is a different issue
<cooloney> this 2 kernel will maintained by pes for a while
<cooloney> smb: heh, that's a big issue
<smb> cooloney, https://wiki.ubuntu.com/Kernel/Dev/TopicBranches (I believe)
<cooloney> smb: thanks a lot, so if we are going to use 1600 for armadaxp and 1800 for highbank
<cooloney> smb: is there any process i need go through to apply such numbers, 
<smb> cooloney, You should talk to Brad or Herton as they do stable
<apw> infinity, we change the numbers where some fool is going to use the same version of a krnel in two releases, as often happens with ARM
<apw> infinity, and as smb says they are documented in https://wiki.ubuntu.com/Kernel/Dev/TopicBranches and allocated by the stable team
<cooloney> apw: infinity probablly sleep now. 
<cooloney> apw: just sent out an email about that, oh, forget you.
<cooloney> apw: let put you in the loop
 * smb is afraid to start the update check
<cking> smb, go for it, see what happens, what could go wrong? 
<smb> cking, brzzz buzzz
<apw> can anyone hear me
<cking> nope not in irc
<apw> *slap*
<apw> diwic, hey ... i have a set of usb speakers and would like to construct a pactl command line to swtich between internal speakers and usb speakers ... is that even possible
<diwic> apw, try "pacmd set-default-sink <name of usb speakers>"
<diwic> apw, "pacmd list-sinks" will give you the name to choose
<apw> diwic, doesn't seem to change anything
<apw> alsa_output.usb-Logitech_Logitech_Speaker-00-ker.analog-stereo
<apw> assuming that is the right sort of name
<diwic> apw, hmm, it could be that setting the default sink does not move the streams, only puts new ones on the USB speakers, can you verify?
<apw> diwic, nope, a new rhythmbox is still on internal
<diwic> apw, can you check with "pactl stat" if the default sink has been changed?
<apw> Default Sink: alsa_output.usb-Logitech_Logitech_Speaker-00-Speaker.analog-stereo
<apw> yep is indeed, does
<apw> doesn't seem to mean anything :/
<apw> diwic, is it me or is pa designed to make your head hurt 
<diwic> apw, then maybe there is an application level override that makes rhythmbox always go the internal speakers
<apw> and how would i have made that, and indeed see that, so i can change it
<diwic> apw, have you used the playback tab in pavucontrol, chances are you have one
 * apw hankers for the old days of ... sound cards
<apw> diwic, how can i find out if i do have one
<diwic> apw, you can remove all your application overrides by deleting ~/.pulse/ (in particular the device-volume and stream-volume files)
<apw> and that is the only way i can even see i have them?
<diwic> apw, analysing a pulseaudio verbose log would also reveal that information I believe
<apw> diwic, oh well i think its reached "too much effort" level even for me ... i feel sorry for users
<apw> they have no chance what so ever to understand this spagetti
<diwic> apw, well, that's why gnome-volume-control never exposes that functionality
<apw> diwic, that reminds me ... many mornings i have to kill pulseaudio to get mumble to work, and i'd say that more than one of us has this issue
<apw> diwic, anything you have heard of ?
<diwic> apw, nope. Kill permanently or just once and let it respawn?
<apw> diwic, killall pulseaudio and let it respawn then start mumble again
<apw> it seems to get stuck when trying to 'send' the first time, so i guess when it opens the mic channel, but not idea how to be sure
<diwic> apw, on Lucid I always had to start the "Audio wizard" to make audio work. 
<diwic> apw, let me start mumble and check
<apw> the visual symptom is the red lips don't work on push-to-talk
<smb> To me it seems to get locked playing something (which would also look like stuck lips)
<diwic> apw, smb, edit /etc/pulse/default.pa and add "set-log-level 4" last in that file
<cking> apw, pie: http://www.geekologie.com/2010/04/omg-omg-omg-314-in-a-mirror-sp.php
<Laibsch> cking: thank you for taking a stab at bug 745836. You are not in a position to accept the SRU process for the ticket?
<ubot2`> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed] https://launchpad.net/bugs/745836
<Laibsch> IOW, accept the taks
<Laibsch> task, even
<cking> Laibsch, it needs to be ACK'd by kernel devs and it will work through the process in due course
<Laibsch> yeah, that was kind of my question, if you are an "official" kernel dev
<Laibsch> I think apw is ;-)  Would you mind having a look at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836/comments/111 and accepting the lucid task?  Would be much appreciated.
<cking> Laibsch, I can't and won't do that - there is due process ;-)
<ubot2`> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed]
<cking> Laibsch, it will get looked at, don't worry
<Laibsch> well, I do worry.  This is fairly troublesome.  And my previous experiences with kernel bugs was less than stellar.
<cking> the process can only go so fast
<Laibsch> basically, it already fallen through the cracks until I revisited the issue yesterday.  It's been my experience that until a task for a release is accepted it's off the radar if ubuntu+1 is not affected.
<cking> and I did get up at 7am to do this ;-)
<Laibsch> much appreciated!
<apw> Laibsch, in the kernel process accepting the lucid task has no real meaning, it does not imply we will accept the sru if the patch is rejected
<apw> anyhow approved the nom
<Laibsch> apw: I know that.  But acceptance puts it on the radar.  The issue shows up in searches, etc.
<Laibsch> apw: cool, thanks.
<apw> if cking has sent stuff the kernel-team@ list then its on our highest radar
<cking> :-)
<Laibsch> good bye
<ppisati> next time i pull request something not_mandatory from upstream, beat me with a club
<cking> ppisati, will do
<ppisati> smb: which flight do you take from AMS to SFO?
 * ppisati is evaluating the options and is gonna flight on Sat too
<smb> ppisati, 9:50 kl605
<ppisati> smb: ok, it's part of one of my options but i was wondering: i've 1hr when i arrive there... uhmm...
<ppisati> smb: since we are entering the US, don't they have to check us again?
<smb> ppisati, Yeah, 1 seems tight with AMS
<tgardner> ppisati, thats not really enough time, is it ?
<ppisati> tgardner: right
<smb> At least to my experience there is that huge passport portal you have to go through, which takes time
<ppisati> tgardner: problem is that almost all my options have ~1hr as buffer between coindidences
<ppisati> grrr...
<smb> ppisati, IMO it helps to get back and state this
<ppisati> smb: will do
<tgardner> ppisati, did you see the ti-omap4 email from ricardo salveti ?
<ppisati> tgardner: yep, i'm preparing the new kernel
<tgardner> ppisati, ack
<ppisati> tgardner: i'll answer to the email later
<jsalisbury> cking, I'll respond to Peter with my system data.
 * apw lunches ...
 * ppisati lunches too
<rsalveti> ppisati: cool, thanks, will you send the pull request today still?
<rsalveti> once the new kernel lands I'll try to also push the sgx driver to the archive 
<rsalveti> ppisati: can you also check bug 956693 after the kernel update/
<ubot2`> Launchpad bug 956693 in linux-ti-omap4 "Broken perf with Ubuntu-3.2.0-1408.11 at Pandaboard" [Medium,Confirmed] https://launchpad.net/bugs/956693
<ppisati> rsalveti: i'll send the pull req in a minute
<rsalveti> ppisati: awesome, thanks
 * apw is tired
<cking> apw, been swimming then?
<smb> oh dear... /me forgot about the abi changing for lucid-natty...
<cking> jsalisbury, thanks - I think we may get some response by middle of next week - that's the kind of timescale they work at
<jsalisbury> cking, ok.  I thought I had to wait to reboot and go into the BIOS, but it looks like I can get the data with dmidecode
<smb> herton, that kvm change had been causing hashes to change. are you already looking into it or do you want me to insert abi bumps?
<cking> jsalisbury, yep, the guys an lenovo don't realise that there are tools to do this ;-)
<jsalisbury> cking, heh
<herton> smb, I fixed natty already, lucid I think we already had bumped the abi before some days ago
<smb> herton, Ah ok, cool. Just saw that build failure
<smb> then remembered I had been forcing some of my test builds 
<herton> smb, hmm, lucid hadn't an ABI bump, I'm going to check and do one
<smb> herton, OK, unfortunately I had been more concentrating on the testing. So I would not remember where exactly I had used ignoreabi. But since the x86_emulate_ops struct changes in all releases it requires a bump too (if not already havin one)
<apw> is there any way we can get the gnome volume control to not "shrink back" when an application goes away ... as for me its full then every time pidgin makes a noise it connects and disconnects from PA which makes the gnome volue thingy get bigger <bing bong> and then smaller
<herton> smb, pushed the abi bump to lucid now
<jcastro> jsalisbury, nuts, I missed the bugmail where you prod me for the new kernel for the x220 wireless, testing now, sorry about that!
<apw> cking, yeah went swimming ... lest i end up chair shaped
<jsalisbury> jcastro, np, thanks again for helping out!
 * cking goes and does some paper work - yawn
<smb> apw, If we would be as slim as our chairs there might be some good in that
<smb> cking, Oregami? :)
<cking> smb, nah, if only
<smb>  *sigh* that keybinding for semi-maximise would not be as bad if I had more than a pixel to hit in order to undo it when accidentally done...
<apw> heheh
<apw> anyone know if any of the thinkpads have hybrid graphics ?
<mjg59> apw: Some do
<apw> mjg59, hmm then that might explain some reports of "port X works but not port Y"
<apw> thanks
<hrw> apw: thx for reply to my patch mail. suihkulokki filled bug with a bit more expanded version: bug 957028
<ubot2`> Launchpad bug 957028 in linux "Fix cross-compiling kernel" [Undecided,Incomplete] https://launchpad.net/bugs/957028
<ogasawara> apw, tgardner: could one of you do me a favor and do a quick  boot test the i386 3.2.0-19.30 kernel I've built on gomeisa (in my home dir under precise-i386/)
<tgardner> ogasawara, your wish is my demand
<apw> ogasawara, can i check that the upload you plan includes the d-i fix for hyper-v
<ogasawara> tgardner: thanks
<apw> ogasawara, ps the meeting is now, so i'll be busy for a bit
<ogasawara> apw: yep, I've pushed to master-next what will be in the upload
<ogasawara> apw: ack
<ogasawara> apw: ah, I thought the meeting would be an hour from now.  in that case I can sit in if you like.
<apw> ogasawara, they got all confused over the time change in teh US of course, i have been listening so don't bother
<herton> smb, I'm gonna revert the ABI bump on lucid, the kvm changes didn't trigger abi-check complaints
<smb> herton, Oh.. a bit surprising (and I though I had to force abi there). But if there were not any compaints...
<tgardner> ogasawara, ubuntu@precise-i386:~$ uname -a
<tgardner> Linux precise-i386 3.2.0-19-generic #30 SMP Fri Mar 16 05:39:35 UTC 2012 i686 i686 i386 GNU/Linux
<ogasawara> tgardner: sweet, thanks
<tgardner> ogasawara, no complaints with AA in dmesg
<herton> smb, yeah, I was trying to hunting down how changing struct x86_emulate_ops affected struct kvm_vcpu, as this seems to have triggered the hash changes, but there is a lot of underlying structs to check
<herton> on natty
<tgardner> herton, smb: don't you guys do full builds to check ABI ?
<herton> tgardner, usually I do, just we expected this time to lucid have gone of the way of natty
<smb> tgardner, well I did full builds to get test kernels, but there were plenty of those and I usually use skipabi to get things done
<smb> And then forget details.. :(
 * ppisati disapperas for ~30mins
 * ogasawara reboots
<apw> ppisati, where are we at with pending fixes for ARM for 3d ?
 * apw pops out to get some supplies
<ogasawara> tgardner: non-smp powerpc linux-meta package, I assume we'll want to just point that to the powerpc-smp flavor for a smooth update/upgrade path
<tgardner> ogasawara, that seems right to me
<tgardner> ogasawara, I've got a test build that is _still_ running on davis
<ogasawara> tgardner: I did a full test build last night
<tgardner> ogasawara, on master-next ?
<ogasawara> tgardner: yep
<tgardner> ogasawara, cool, then I'll kill mine
<tgardner> ogasawara, did I actually get it right the first time ?
<ogasawara> tgardner: it looked right to me, powerpc-smp and powerpc64-smp udebs were built and powerpc went away.
<tgardner> ogasawara, woot!
<ogasawara> tgardner: I've still got it on davis if you wanted to take a quick peek
<ogasawara> tgardner: in my home dir under precise-powerpc
<tgardner> ogasawara, nah, I'll take your word for it :)
<ppisati> apw: the new kernel has all the needed bits
<ppisati> apw: ricardo will roll a new sgx driver when this kernel hits the archive i guess
<ppisati> rsalveti: ^^
<cyphermox> hey; just to make sure you are aware of this issue with WPA on ad-hoc: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/905748
<ubot2`> Launchpad bug 905748 in network-manager "Create WPA2 adhoc is Open, not encrypted" [High,In progress]
<cyphermox> there's a linux task as well ^
<tgardner> cyphermox, is there a reason for the linux task ? seems like its nm or wpa-supplicant at fault, though I have not read the bug report.
<cyphermox> tgardner: yes, it's reproducible on various drivers, with NM or just wpasupplicant, and the kernel displays the network as WPA 1 in iw dev wlan0 scan; but on a different system (or on an android phone) it gets seen as open.
<cyphermox> tgardner: any way I can help debugging this and ensuring it's really not wpasupplicant?
<tgardner> cyphermox, I've not used wpa_supplicant from the command line, but I believe sforshee has.
<cyphermox> tgardner: that's how I was testing it
 * smb thinks this Friday has went far enough...
<tgardner> cyphermox, are there any clues in syslog that indicate encryption is or isn't in use ?
<tgardner> cyphermox, you might also ask how to debug this on linux-wireless@vger.kernel.org
<cyphermox> tgardner: thanks. so no, not really anything to suggest it is or isn't in used, though in all honesty I wasn't running wpasupplicant in debug more when I tested it; and should have
<cyphermox> I'll try that again after lunch
<tgardner> cyphermox, yeah, if wpa_supplicant thinks its starting an encrypted session, but other clients see it as open, then it likely is a kernel issue
<cyphermox> tgardner: what leads me to believe it's kernel is especially how when it's set up on my system 'iw dev wlan0 scan' lists it as WPA protocol 1; but android sees it open (and so do other systems)
<tgardner> cyphermox, that makes sense
<cyphermox> I've seen another ubuntu machine have iw report security, but NM happily connects to it with any passphrase, traffic passes without issues
<cyphermox> all these fun things
 * tgardner relocates
<cking> hrm downloading a kernel .ddeb is taking ages
<ogra_> yeah, we should stop putting all these symbols into them to make the download faster :)
<apw> cking, used up your whole years allowance i expect
<cking> apw, too right
 * cking -> EOD
<rsalveti> ppisati: yup, once it lands I'll try to push the sgx driver in
<ppisati> rsalveti: k
<cyphermox> tgardner: I went pretty verbose on that one, but I updated the bug (bug 905748) with debug logs from wpasupplicant and other tests I could think of
<ubot2`> Launchpad bug 905748 in network-manager "Create WPA2 adhoc is Open, not encrypted" [High,In progress] https://launchpad.net/bugs/905748
<tgardner> cyphermox, that looks like enough info to send an email to upstream
<cyphermox> tgardner: should I read this as "please contact upstream" or do you have contacts? :)
<tgardner> cyphermox, the former. 
<cyphermox> alright :)
<tgardner> cyphermox, this bug is well beyond my knowledge of the protocol code
<cyphermox> tgardner: no problem, just trying to be thorough because this is kind of stupidly broken
<cyphermox> tgardner: as stop-gap I was trying to disable creating ad-hoc WPA via NM, but my patch didn't work as expected, upstream NM says they'll look into it
<cyphermox> tgardner: what upstream version is the current precise kernel equivalent to?
<cyphermox> ( I see 3.2.0 but also 3.2.9 in proc/version_signature)
<tgardner> cyphermox, 3.2.11 (I think). lemme check for sure
<tgardner> cyphermox, 'UBUNTU: Rebase to v3.2.11'
<cyphermox> ah, thanks
<tgardner> cyphermox, that is what was just uploaded a couple of hours ago. your version may perhaps be older
<cyphermox> on, in that case yeah just a bit older -- Ubuntu 3.2.0-18.29-generic 3.2.9
<cyphermox> actually, just noticed something interesting, a link error message from nl80211
<cyphermox> tgardner: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/905748/comments/45 ; or just tell me to shut up if you don't care ;)
<ubot2`> Launchpad bug 905748 in network-manager "Create WPA2 adhoc is Open, not encrypted" [High,In progress]
<tgardner> cyphermox, that looks like a good clue.
<tgardner> cyphermox, I'm EOD and gotta blast off.
 * tgardner -> EOD
#ubuntu-kernel 2012-03-17
<infinity> linux and linux-ti-omap4 are both accepted through NEW, if someone wants to rev the metas.
<infinity> apw: ^
<apw> infinity, ack
<apw> infinity, done
<infinity> apw: My hero.
<apw> infinity, heh ... far short of that 
<infinity> apw: I'm easily impressed.
<riderplus> hi. i want to use volume control from within mp3blaster. since /dev/mixer is missing, that's not possible. is there a work around?
#ubuntu-kernel 2012-03-18
<riderplus> hi. what can i use instead of /dev/mixer?
<infinity> apw: In your coworkers' haste to rid the world of powerpc, they didn't turn on udeb-generation for powerpc-smp, so no more d-i. :/
<apw> infinity, gah
 * apw looks
<infinity> apw: I'd be shaming Tim directly, but he doesn't seem to be around. :P
<infinity> apw: Or he's undergone another nick change, and I can't keep up.
<apw> infinity, heh not in a weekend, i'm not here either ... except
<apw> infinity, its a trivial change so i'll poke it now
<infinity> Shiny.
<infinity> I'm still miffed that all my UP PPC32 machines have just gotten spinlocks for no reason, but I seem to have lost the argument in the name of ZOMG FASTER BUILDS.
<infinity> apw: I don't suppose anyone's ever looked to see if the spinlock->noop runtime rewrite magic from x86 is even remotely portable to other arches?
<apw> infinity, i think the feedback when i asked the same was, noone cares about single cpu machines now, as most stuff is smp now
<apw> infinity, in theory at least he did try to switch the udebs:
<apw> -powerpc        PKGVER-ABINUM   powerpc                 PKGVER-ABINUM-powerpc           -       
<apw> +powerpc        PKGVER-ABINUM   powerpc-smp                     PKGVER-ABINUM-powerpc-smp               -       
<apw> fs-secondary-modules-3.2.0-19-powerpc-smp-di 3.2.0-19.30
<infinity> apw: Failure on kernel-wedge's part to rewrite control or something?  I didn't actually check the build log.
<apw> infinity, and the build seems to have made various udebs ^^
<infinity> apw: Err, it did?  Okay, I'm blind.  Maybe.  *looks again*
<apw> the packages seem to exist?
<infinity> apw: Oh, feh.  I'm blind.  Ignore me.
<infinity> apw: Visual parsing skipped right over them, I guess.
<apw> infinity, are you updating d-i to 3.2.0-19 ?  i assume so
<infinity> Move along, nothing to see here.
<infinity> Yeah, I revved d-i to -19-, haven't yet done the ppc-smp thing, cause I could have sworn there were no udebs.
<apw> infinity, i hate that feature of the human eye/brain combo, when one is sure of somethign it is what you see regardless of reality
<infinity> I blame St Paddy's drinking.
<apw> infinity, ahhh thats great, we might get good isos for monday 
<infinity> Yeah, I was doing d-i over the weekend specifically to have sane stuff for the Foundations installer hacking sprint next week.
<infinity> Which, to be fair, won't involve much PPC stuff, but I should fix PPC anyway.
<apw> be nice indeed to be able to test 'e
#ubuntu-kernel 2013-03-11
<ohsix> so, i have a problem i'm trying to find in a program; it seems to happen when only certain pages need to be faulted in, i can sort of provoke it by setting vm.swappiness=100 and doing echo 1 > /proc/pid/clear_refs and waiting an arbitrary amount of time, what i need is something that can evict a page to swap with high likelyhood, is there something in /sys or /proc i can poke to do that?
<ohsix> the program can be modified if madvise or something can be close to forceful (like with DONTNEED) but basically invoking the path taken for the process for hibernate would be perfect
<ppisati> moin
<smb> morning
<smb> apw, -ENOHEAR
<ppisati> brb
<apw> tseliot, i had a long chat with the rcu maintainers about the issue we worked on in the binary shim
<apw> tseliot, it does seem like there should be some kind of locking accessor for those
<tseliot> apw: do you mean additional locks?
<apw> tseliot, no i mean some kind of wrappers which expose that functionality, so more like a _get _put pair for the iee data which does the right thing
<apw> tseliot, i am thinking about how they might look at the moment
<apw> tseliot, for now i would advise ignoring it for us, and lets see if we can fix this upstream for everyone else
<tseliot> apw: ok but it's not really a lot of work to workaround locally. I'll also have to fix a few more things for 3.8 in the broadcom driver anyway
<apw> tseliot, ok cool
 * ppisati hopes for a 'changeset' feature in git, sooner or later...
<apw> ppisati, meaning ?
<apw> bjf, we still have tips which have the wrong series in them, i've just fixes quantal-signed, but this is a timebomb waiting to bite someone
<ppisati> apw: 'changeset' a way to group together bunch of related patches
<apw> ppisati, in a way to email them?
<ppisati> apw: i'm backporting overlayfs to nexus7, picking stuff from 3.2, and i noticed after the 3rd try
<ppisati> apw: that i actually needed 8/9 patches
<ppisati> apw: with a 'changeset' we could group together all those patches under the same sha
<ppisati> apw: and say 'pick the overlayfs changeset'
<ppisati> apw: fixes could go in later, but when yo cherrypick the changeset, you get all the stuff
<ppisati> apw: perfore has it
<ppisati> *perforce
<apw> ppisati, that is called a branch
<apw> ppisati, you put all the fixes etc on the branch
<apw> an then you merge the branch repeatedly into 'master'
<ppisati> apw: yep, but when you feature enter master, how do you extract it?
<apw> you never do, you always have the original branch to refer to to find teh patches
<xnox> rebase.
<ppisati> apw: but we don't have topic branches many times
<apw> ppisati, we never do
<ppisati> apw: that was my point
<xnox> also git merge-base, can later find the merge commits and sub-branches. to see what got merge into where/when.
<apw> ppisati, no our desire to maintain a simple history does not make it easy
<apw> ppisati, we have proposed it, but it would make maintenance a lot higher for everything else
<ppisati> apw: i see
 * ppisati notes it doesn't compile yet...
<ppisati> apw: anyway, git lg | grep overlayfs was enough to get all the dependencies
<apw> ok
<ppisati> apw: so adding "$feature" to the subject is a good thing IMO
<apw> ppisati, we deffo try to do that for anything we count as an 'ubuntu' drvier
<ppisati> apw: that's good
<apw> ppisati, mostly to stop tim from losing the patches when he rebases us :)
<ppisati> apw: yeah, let's put all the blame on rtg :)
<xnox> ppisati: if you have overlayfs capable nexus7 kernel, I'd be happy to be an early tester. I know how to use abootimg and flash custom kernels onto my nexus7 ;-)
<ppisati> xnox: i'll ping you later
<xnox> =)
 * rtg_ grumbles about daylight savings time
<apw> rtg_, you guys fiddling with your clocks at the wrong time agian ?
<rtg_> it always seems to be the wrong time of year  for messing with the clocks
<apw> there is that
<rtg_> apw, aren't you guys this coming weekend ?
<apw> rtg_, i think we are a couple of weeks behind, having aligned with your old dates
<apw> rtg_, i think it was two weeks either end you lot added
<ogra_> yeah, will be a few weeks of gcal fun again
<rtg_> I read that DST is basically useless now
<ogra_> was it *ever* useful ?
<rtg_> not in my opinion
<apw> there are lots of claims it saves oil, seems unlikely
<rtg_> it causes jet lag for sure
 * ogra_ thinks it was just a bad joke of george washington when he had too much weed one night 
<ogra_> (iirc he invented it, didnt he ?)
<rtg_> seems a bit before his time. we didn't start it in the states until the fifties
<apw> ogra_, wikipedia says it was a george, but not that one
<rtg_> http://en.wikipedia.org/wiki/Daylight_saving_time
<ogra_> heh, k
<apw> seemingly the first people to do it were the germans :)
<ogra_> but an new zealander invented it ... 
<ogra_> probanly to be closer to the rest of the world for a few days :)
<apw> indepenandanly invented it, it seems, before the interwebs
<ogra_> *probably
<ppisati> ogra_: after i dpkg -i a new kernel on the nexus7, what do i need to run to "flash it" on the boot partition?
<rtg_> ppisati, is this the desktop image ?
<ppisati> rtg_: phablet
<rtg_> ppisati, hmm, dunno about that one. flash-kernel runs on the desktop image and DTRT
<ppisati> rtg_: i guess i'll have to reflash it then...
<ogra_> ppisati, phablet has nothing implemented to handle kernels, it uses androids update.zip method (or is supposed to)
 * ppisati goes reflashing...
<ogra_> technically you should be able to just use abootimg though
<ogra_> since that works on n7 (just not in the other pagblet setups)
<ogra_> *phablet
<ppisati> ogra_: can you reflash the desktop img over the phablet? or do i need to go back to android first?
<ppisati> ogra_: *can i
<ogra_> you can, just go into fastboot and flash it 
<ppisati> ogra_: using today's daily, screen is REALLY dark
<ppisati> ogra_: but i can see the normal installation process going on
<ogra_> k
<ppisati> ogra_: isn't is supposed to be a preinstalled img?
<ogra_> yes
<ogra_> it uses oem=config to do the initial configuration 
<ogra_> *oem-config 
<ppisati> ogra_: but it's unusable
<ppisati> ogra_: it's uninstallable actually
<ppisati> i'ts *not* installable
<ogra_> i had several positive reports for the last image
<ppisati> ogra_: do you connect it to an external screen?
<ogra_> how exactly is it not installlable ... does it unpack the tarball and you get into X/oem-config ?
<ppisati> ogra_: i can't see what's going on the screen
<ppisati> ogra_: it's so dark, i can barely see some shadow
<ogra_> you use landscape mode, right ?
<ogra_> hmm
<ogra_> not for me 
<ogra_> are you sure your backlight isnt broken ?
 * ogra_ starts a download of todays image
<ppisati> ogra_: it was working wit the phablet img
<ppisati> i can try to reflash it
<ogra_> i wonder if the android kernel caused that 
<ogra_> s/android/cyanogenmod/
<ogra_> i.e. setting soem HW register that makes it go darker than usual
<ppisati> ogra_: i rebooted it
<ogra_> i havent tried phablet on a tablet, only ported it to my galaxy S2 and run it there so far
<ppisati> ogra_: ok so
<ppisati> ogra_: during boot, i see the "google" logo and plymouth "ubuntu" is ok
<ppisati> ogra_: bright as always
<ogra_> ok
<ppisati> ogra_: but when the installation starts, it goes in TOTALLY power save mode
<ogra_> but you can still see something through that ?
<ppisati> ogra_: today's daily is unusable for me
<ppisati> ogra_: nope
<ppisati> ogra_: only a very very very pallig img
<ppisati> *pallid
<ogra_> that doesnt sound like power save mode but like ubiquity having a start up issue ... is that todays image ?
<ogra_> so it *is* showing something, just not with bright enough backlight ?
<ppisati> ogra_: right
<ppisati> ogra_: i see the installer
<ogra_> do you have a lamp near you ? 
<ppisati> ogra_: choose language, timezone, etcetc
<ppisati> ogra_: uhm
<ogra_> can you hold it with the top part of the display directly under the lamp ?
<ppisati> ogra_: no :)
<ppisati> ogra_: let me first reflash it, just in case...
<ogra_> it looks to me like the phablet kernel redefined the minimal brightness 
<ogra_> so that the luxd script (which just shorcuts the ambient sensor to the brightness control) gets you a too dark setting
<ppisati> rebooting after reflash...
<ogra_> to check the luxd script you would need a lamp and hold it close to the ambient sensor
<ogra_> the display should adjust automatically 
<ppisati> ogra_: again, night mode...
 * ppisati goes trying the "last-good-image'
<ogra_> that one definitely works, i tested it myself 
<ogra_> (but then i didnt have phablet installed ever on my n7 ... i really think its something with the pahblet kernel)
<ppisati> ogra_: let's see
<ogra_> yeah
<ogra_> download will still take 20/30min here 
 * ppisati goes for an apple...
<ogra_> ppisati, pad or book ?
<ppisati> ogra_: fruit :)
<ogra_> ... so nostalgic :)
<ppisati> ogra_: even with the good img i had the same problem, i'm back to android now
<ppisati> ogra_: and it's ok
<smb> ogra_, I suppose not too many will note the fun double meaning of the "pahblet" image... ;-P
<rtg_> sforshee, I don't think the efivarfs fixes you were anticipating made it into -rc2
<sforshee> rtg_, I think 123abd76edf56c02a76b46d3d673897177ef067b is the one we're looking for
<sforshee> git describe --contains 123abd76edf56c02a76b46d3d673897177ef067b
<sforshee> v3.9-rc2~14^2^2~1
<rtg_> sforshee, doh, of course.
<rtg_> sforshee, prolly need that in raring as well
<rtg_> it is marked stable
<sforshee> rtg_, yep, the bug came into raring via the stable updates
<ogra_> smb, lol
<ogra_> ppisati, so there is definitely something wrong with our kernel or userspace wrt backlight handling 
<ppisati> ogra_: dunno
<ogra_> ppisati, and since i dont see it here its is also definitely caused buy the phablet android kernel
<ppisati> ogra_: now it seems i can't even get to the installer :(
<ppisati> ogra_: i'm back to android for the secondo time
<ogra_> (and you are actually the first one to report it at all)
<ppisati> ogra_: and it's ok, again
<ogra_> yes, i got that
<ogra_> so our nx7 kernel does something weird 
<ppisati> ogra_: http://askubuntu.com/questions/259369/ubuntutouch-mako-nexus-4-black-screen-after-install
<ogra_> (whatever that is)
<ogra_> thats totally unrelated 
<ogra_> it happens on phablet if the userspace unpacking failed 
<ogra_> not related 
<cking> hrm, does that mean we now have askubuntu.com + LaunchPad to check for bugs?
 * jsalisbury reboots
<ogra_> cking, since a while already ... though the ask moderators are usually clever enough to point people to LP for real bugs
<ogra_> cking, its kind of supposed to replace the LP questions api that nobody really uses
<cking> ogra_, yup, it's just *another* thing to scan for "the world is on fire" bugs
<ogra_> yeah 
<ppisati> ogra_: ok, i officially give up with the desktop img
<ppisati> ogra_: if anyone feels brave enough, here is a kernel with overlayfs
<ppisati> http://people.canonical.com/~ppisati/linux-image-3.1.10-9-nexus7_3.1.10-9.27~overlayfs_armhf.deb
<apw> cking, na another thing to ignore until ogra_ tells you the world is on fire :)
<apw> ppisati, i have desktop on mine ... i can try later
<ogra_> xnox, ^^^
<ogra_> he wanted to be beta tester for it :)
<xnox> =)))))
<xnox> \o/ awesome
 * ogasawara back in 20
<ppisati> ogra_: and for the records, i'm back to the phablet img and it works fine
<ogra_> ppisati, yes, i belive you 
<ogra_> ppisati, so our nexus7 kernel has a bug 
<ogra_> which i cant trigger here at all
<ppisati> ogra_: is there an old img somewhere?
<rtg_> ogra_, I'd guess its more likely a difference in config options
<ogra_> rtg_, or that, yeah
<ogra_> ppisati, just FYI, todays desktop image works absolutely flawless here 
<ppisati> ogra_: :(
<ogra_> so i suspect android sets some HW register or so that causes the brightness lowlevel to be lower than usual
<ppisati> ogra_: that is weird
<ppisati> ogra_: after so many reflashes, it shouldn't bother anymore
<ogra_> ppisati, well, if we dont set that same register back it indeed wont work
<ogra_> ppisati, i think the actual darkening happens through our luxd script though .... i'll drop that from the settings package and the next image will then just rely on kernel stuff for brightness
<ogra_> so i would ask you to try that one (once it is out) to see if the issue is gone 
<ppisati> ogra_: if i press the volume down button, i see all the services starting
<ppisati> ogra_: but after apparmor
<ppisati> ogra_: the screen goes black, and never resumes
<ogra_> how long did you leave it sitting like that ?
<ogra_> ubiquity is *very* slow starting
<ogra_> can take a minute or a bit more
<ppisati> ogra_: some minutes
<ogra_> k
<ogra_> then its not ubiquity
<ppisati> still black
<ogra_> and you tried that with todays image ? 
<ppisati> yes
<ogra_> 100% sure ?
<ogra_> we had a bug about a week ago where whoopsie would cause a black screen after plymouth
 * xnox will be trying soon with my automatic preseeding of wifi & user config, but with added custom kernel as well ;-)
<ppisati> [flag@luxor ~]$ md5sum ~/Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.bootimg 
<ppisati> f68e802b866f2b73b54c0890a8138005  /home/flag/Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.bootimg
 * ogra_ is in the last stages here ... oem-config-remove already running 
<ppisati> [flag@luxor ~]$ md5sum ~/Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.img.gz 
<ppisati> 4f6f33be6ef8671f1b5a45ab3e467c6d  /home/flag/Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.img.gz
<ogra_> lets compare the unzipped image 
<ogra_> ogra@anubis:~/Desktop/images/raring/20130311$ md5sum raring-preinstalled-desktop-armhf+nexus7.img
<ogra_> 5b5e69daa5c2238cc2c8221483d8eb50  raring-preinstalled-desktop-armhf+nexus7.img
<ogra_> (i never keep the gz around ... pointless :) )
<ppisati> Mar 10 16:13?
<ogra_> yep
<ogra_> does your unzipped image match mine ? 
<ogra_> probably your gzip is screwed ?
<ogra_> :P
<ogra_> (unlikely indeed :) )
 * ogra_ is at the freshly installed desktop
<ppisati> [flag@luxor ~]$ md5sum Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.img 
<ppisati> 5b5e69daa5c2238cc2c8221483d8eb50  Downloads/UbuntuNexus7/raring-preinstalled-desktop-armhf+nexus7.img
<ogra_> hmm, yeah, its the same
<ppisati> ogra_: mine is a...
<ogra_> weird that mine works flawless then
<ppisati> ogra_: 8G nexus7 FWIW
<ogra_> same here
<ogra_> first model goodle sold
<ogra_> *google
<ppisati> ogra_: did you upgrade android to the latest version?
<ppisati> ogra_: i didn't
<ogra_> i didnt
<ppisati> :(
<ogra_> my device only had android on it for some hours
<ogra_> never seen it again
<ogra_> you flashed the .img, not the .img.gz, right ?
<ppisati> ogra_: the installer did for me
<ogra_> i never used the installer :)
<ogra_> so much overhead for two commands
<ogra_> yay, and the nautilus bug is fixed
<ogra_> fastboot flash boot raring-preinstalled-desktop-armhf+nexus7.bootimg
<ogra_> fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img
<ogra_> fastboot reboot
<ogra_> thats what i use
<ogra_> to be on the safe side i often also do: fastboot erase boot ; fastboot erase userdata ... before running that though
<ppisati> ogra_: what's different between erase and format?
<ppisati> ogra_: "******** Did you mean to fastboot format this partition?"
<ogra_> dunno if there is one :)
<ogra_> its moot anyway, since we flash a new filesystem 
<ogra_> i just like to be sure its empty before flashing ... but theoretically fastboot flash does it already
<brendand> bjf, henrix - if someone is running the 3.5 kernel in precise (i.e. they installed 12.04.2), does that mean that they get -proposed kernels from quantal?
<rtg_> brendand, no, they get official LTS kernels from the precise archive
<rtg_> from -updates
<apw> which in theory are identicle, but not quite
<bjf> brendand, works like all the rest. we produce a lts-hwe-quantal kernel, run it through -proposed etc. if they enable proposed they would get that
<brendand> bjf, - but it follows this tracking bug, right? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1133429
<ubot2`> Launchpad bug 1133429 in kernel-sru-workflow/verification-testing "linux: 3.5.0-26.40 -proposed tracker" [Medium,In progress]
<bjf> brendand, look at comment #1
<bjf> brendand, "linux-lts-quantal (precise) - bug 1133589"
<ubot2`> Launchpad bug 1133589 in Kernel SRU Workflow prepare-package "linux-lts-quantal: 3.5.0-26.40~precise1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1133589
<brendand> bjf - does that kernel follow the same SRU process as the other ones?
<bjf> brendand, yes, haven't you been testing it?
<brendand> bjf - it seems to be marked invalid for us
<bjf> brendand, i think that is correct
<brendand> bjf, we've been testing the 3.5 kernel, but with quantal userspace
<brendand> bjf, on systems that we certified with quantal
<bjf> brendand, that makes sense
<brendand> bjf, we want to start testing systems we certified with 12.04.2
<bjf> brendand, that's fine, but you also have to keep testing Precise
<brendand> bjf, and we will
<brendand> bjf, we'd kind of like to not test quantal either, since we aren't certifying systems with quantal
<bjf> brendand, you must test the previous release and all LTS releases
<brendand> bjf - ok, well assuming we continue to test quantal. how do we go about getting in the loop for the backports kernels such that we know when they're ready and can start testing them with 12.04.2?
<bjf> brendand, the process should work exactly the same. we can fix the tracking bugs so that cert. testing is no longer invalid
<brendand> bjf - but is the backports kernel following a different cadence then? at the moment the one you linked to is in 'prepare-package'
<bjf> brendand, same cadence. i'm looking at why that bug is stuck in "prepare-package"
<bjf> brendand, however, please note that we are respinning that kernel due to a regression
<brendand> bjf, ok
<bjf> brendand, that was not the correct tracking bug. bug 1135219 is the correct one
<ubot2`> Launchpad bug 1135219 in Kernel SRU Workflow verification-testing "linux-lts-quantal: 3.5.0-26.40~precise1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1135219
<rtg_> apw, do you have time to look at overlayfs in 3.9 ? looks like the dentry_open function has morphed into atomic_open with way different parameters.
<apw> rtg_, yeah will do, i think we was expecting something like that
<rtg_> apw, I updated aufs 
<apw> rtg_, great, does it still work :)
<apw> (now work)
<rtg_> apw, dunno. you have a test for it IIRC ?
<apw> i would rather say i know how to basically touch test it
<rtg_> apw, well, I know basically how to compile it :)
<cking> kirkland, test results in your inbox
<rtg_> cking, aes-ni ?
<cking> rtg_, yep, wanna  copy of them?
<rtg_> cking, please
<cking> rtg_, bottom line,  if you have a fast device (SSD) you will see some excellent improvements, HDD probably not (depends on usecase)
<ppisati> cking: how long does it take before it blows up?
<ppisati> cking: anyhow, i'll leave it running
 * ppisati -> workout
<ppisati> cking: anyhow
<ppisati> Test Summary:
<ppisati> 23 passed
<ppisati> 1 failed
<ppisati> enospc                  FAIL
<ppisati> all the rest was ok
<ppisati> cking: tell what i need to do after
 * ppisati is out for real now
 * cking ponders why all the tests fail in the QA lab
<infinity> apw: *poke*
<apw> infinity, hi
<infinity> apw: Your linux-signed upload to quantal is crufty.
<apw> oh what did i knob on that
<infinity> Had a local tree with junk in it?
<infinity> https://launchpadlibrarian.net/133709453/linux-signed_3.5.0-26.40_3.5.0-26.42.diff.gz
<infinity> apw: To avoid having to do weird version number bumps, if you want to fix that and upload directly to the archive instead of the PPA...
<infinity> apw: (And make sure it was just your local system with junk, not git)
<apw> infinity, toss ... ok
<bjf> apw, are you doing the signed pkgs or is the stabel folks?
<apw> bjf, i was doing it originally because steve didn't do it
<apw> and i was asked for it over the weekend
<apw> i don't want to do it :)
<apw> but as i ballsed it up, i should clean up my own mess
<bjf> i think it could have waited til today
<apw> perhaps so
<bjf> sconklin, ^ don't do the quantal signed pkgs, it seems that apw is doing it
<sconklin> bjf: ack
<tseliot> apw: can you think of any reasons why I'm getting a warning about "rcu_read_unlock_special" being undefined even though I included <linux/rcupdate.h>?
<apw> tseliot, isn't that RCU TINY only ?
<tseliot> apw: __rcu_read_unlock uses that in rcupdate.c
<tseliot> apw: and I can see this in linux/rcupdate.h : extern void rcu_read_unlock_special(struct task_struct *t);
<apw> the code there is only included if CONFIG_PREEMPT_RCU is enabled
<apw> in both header and main .c file
<tseliot> apw: right, and that's enabled in our lowlatency flavour
 * rtg_ -> lunch
<infinity> apw: Want to nudge me when that fixed linux-signed is uploaded?
<infinity> apw: Or I can do it myself and get you to double-check git later.
<infinity> apw: Either works for me.
<apw> infinity, will do it shortly just on the phone trying (trying trying) to order broadband
<infinity> Heh.
<apw> infinity, ok in the pipe, hopefully right this time, direct to quantal-proposed
<infinity> apw: That looks much cleaner, thanks.
<apw> infinity, phew i did one thing right today
<apw> the second time ... :(
<infinity> apw: Heh.
 * rtg_ -> EOD
#ubuntu-kernel 2013-03-12
<ppisati> moin
<mlankhorst> anyone here understands mmaps and stuff in the kernel? :>
<ohsix> in what respect
<smb> there is a lot of stuff in the kernel...
<mlankhorst> just mm in general, I'm trying to make forced drm unbinding work, and the part that's missing now is tearing down all mmaps
<smb> mlankhorst, Hm, not deeply familiar with it but from the interface I'd say the using side is responsible to remember what mappings where done...
<mlankhorst> ofc, but the fun is figuring out how to make the user side kill and free everything :P
<ohsix> let them fault in a canary page
 * ppisati tries again the install ubuntu on his nexus7...
<ppisati> brb
<tseliot> apw: what's the point of having rcu_read_unlock_special defined in kernel/rcutiny_plugin.h and defined as a function prototype in include/linux/rcupdate.h? Is it private?
<apw> tseliot, it may be a left over remnant of some older time, things in that code have moved a lot recently as two of the implementations have merged
<tseliot> apw: hmm... I see
<apw> tseliot, it sounds very much like it has moved inline, and not had its prototype removed to me
<tseliot> apw: that would make sense
<apw> and i don't think it would cause any issues this way, as essentially it becomes just a prototype, though you might expect to get a warning
<tseliot> apw: yes, I'm getting a warning but what happens at runtime?
<apw> tseliot, the right thing as it has only that one definition
<apw> but for completeness paste the warning
<tseliot> apw: WARNING: "rcu_read_unlock_special" [/var/lib/dkms/bcmwl/6.20.155.1+bdcom/build/wl.ko] undefined!
<apw> hmmm, that is less what i expected as a warning
<tseliot> apw: the whole log: http://paste.ubuntu.com/5607386/
<apw> tseliot, i would be supprised if you can load that module with that warning
<tseliot> apw: I can't do it from my chroot since modprobe insists on looking for modules.dep.bin in /lib/modules/$(uname -r)
<tseliot> I'll test it on a real system
<apw> yeah
<lilstevie> tseliot, there is always insmod if you haven't run depmod :p
<tseliot> lilstevie: you don't say... ;)
<lilstevie> :)
<tseliot> apw: yes, it errors out: ERROR: could not insert 'wl': Unknown symbol in module, or unknown parameter (see dmesg)
<tseliot> apw: wl: Unknown symbol rcu_read_unlock_special (err 0) (from dmesg)
<apw> it actually seems like one of the combinations is just broken right now in that kernel then
<apw> or is this with you 'transplanting' code
<tseliot> apw: I simply copied rcu_lock and unlock locally and the unlock function calls rcu_read_unlock_special 
<ppisati> ogra_: still completely black screen with today's img
<tseliot> apw: here's the patch http://paste.ubuntu.com/5607457/
<apw> tseliot, and against which version is it failing ... 3.8 right ?
<tseliot> apw: yep 3.8
<apw> tseliot, so dispite these being in .h's they are not in .h's really
<apw> tseliot, they are just being vile.  they are actually just included into rcutiny.c and rcutree.c ...
<apw> and those in that context are then real externals and not exported at all
<apw> this needs to be fixed properly upstream, as it is unreasonable to export the interface without being able to use the locking.  i have discussed an acceptable solutuion with the rcu maintainer
<apw> but it won't help existing instances or you ... sigh
<tseliot> apw: yes, that's what I was afraid of...
<tseliot> apw: right, so I can't fix it unless I copy a lot of code from rcutiny_plugin.h (i.e. rcu_read_unlock_special and its dependencies)
<apw> tseliot, which is getting rediculous.  now for us i could spin some accessors, given my discussions i think might be reasonable upstream and we could try those out
<apw> but that doesn't help other kernels in the short term
<apw> tseliot, i assume it is jsut the lowlatency kernel which is in trouble right nwo ?
<tseliot> apw: yes, it's just that flavour
<apw> tseliot, and only in raring, so for this monent i think there is little panic at least
<tseliot> apw: true, at least for now
<apw> tseliot, zap me the bug number and i'll have a poke at what we might do to fix it kernel side
<tseliot> apw: let me file one
<tseliot> apw: I still need to write a proper description but here it is: bug #1154036
<ubot2> Launchpad bug 1154036 in linux-lowlatency (Ubuntu) "rcu_unlock_special is undefined" [Undecided,New] https://launchpad.net/bugs/1154036
<snadge> i updated to 13.04 from 12.10 .. stock kernel wont boot.. but if i select the 3.5 kernel, it will
<snadge> intel atom acer aspire one d260
<apw> snadge, "won't boot" what actually happens when you attempt to boot that kerenl
<apw> snadge, as that is about the most common box around and one we have things which are very similar to in regular use on 13.04
<snadge> i was seeing kernel panic .. its not on the screen now.. i've installed 3.8.0-12-generic.. and its now booting
<snadge> but theres an unrelated broadcom wireless driver problem
<snadge> !bug 1110139
<ubot2> Launchpad bug 1110139 in linux (Ubuntu) "Broadcom BCM4313 wireless card driver not working" [Medium,Confirmed] https://launchpad.net/bugs/1110139
<ppisati> xnox: btw, did you try my overlayfs kernel?
<rtg_> ppisati, did you take that over from apw for 3.9-rc2 ?
<ppisati> rtg_: nope, nexus7 kernel - 3.1.X + overlayfs from precise
<rtg_> ack
<xnox> ppisati: sorry, not yet, got tangled up in things. Are you pondering to upload?
 * henrix -> lunch
<ppisati> xnox: nope until anyone give it a spin
<ppisati> my nexs7 is busted, so can't do myself
<xnox>  /o\
<xnox> ok. will get to it, as soon as i can. mine was working finish last time i tried.
<apw> rtg_, i am just playing with it at the moment in fact
<rtg_> apw, cool
<apw> rtg_, ... and of course ... there was an overlayfs update over night ... pulling in now
<rtg_> apw, timing is everything ...
<apw> i wish i had been even more lax yesterday
<rtg_> apw, sometimes it is righteous to be a slacker
 * smb wished he could use that in the goals...
<mlankhorst> you don't say you're a slacker, you have to make it sound like you're putting work into avoiding work :)
<rtg_> mlankhorst, ok, I am actively pursuing slackerdom :)
<mlankhorst> again it's how you bring it :)
<ohsix> gotta try selling pap smears of famous people
<apw> :q
<mlankhorst> Bad way: "I want to slack off". Good way: "increase testability and reduce time needed to isolate problems". Note that in the good way you do some work, to prevent more work. :-)
<ohsix> make it your job to make iteration times lower but spend all your time testing
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<chiluk> Hey everyone, the nvidia binary blob has decided to destroy itself all over my logs... should I open the bug against kernel, x.org, or something else?
<rtg_> chiluk, talk to tseliot
<tseliot> chiluk: what do you mean?
<chiluk> tseliot let me get a pastebin for you.
<chiluk> tseliot check out http://paste.ubuntu.com/5607938/
<chiluk> that 20k lines of log is only the first hour of issue...
<tseliot> chiluk: yes, please file a bug report
<tseliot> chiluk: against whatever nvidia driver you're using
<chiluk> I'm on latest proposed precise kernel.
<chiluk> and let me check nvidia blob.
<chiluk> 310.14
<chiluk> just started happenning, and it only seems to happen in the early morning after the machine has been idle a whiel.
<chiluk> I hit the same issue yesterday, but passed it off to being an power issue from the storm I had.
<slangasek> jsalisbury: hey, so I just caught bug #1152736 in action here again, this time on 3.5.0-9
<ubot2> Launchpad bug 1152736 in linux (Ubuntu) "system swapping itself to death in raring for no good reason" [Critical,Confirmed] https://launchpad.net/bugs/1152736
<slangasek> jsalisbury: this one wasn't as dire - it sorted itself out in mere seconds, instead of eating my laptop alive for a half hour - but kswap0 was definitely pegging the CPU
<jsalisbury> slangasek, thanks for the update.  So it doesn't seem to be a regression.  Can you also run on additional test with the latest 3.9-rc2 kernel?  Just to confirm it is in mainline as well.
<slangasek> jsalisbury: sure.  Remind me where to find the package?
<jsalisbury> slangasek, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc2-raring/
<jsalisbury> slangasek, I can post it to the bug as well.
<roadmr> hey folks! I think I found a regression for the bcmwl-kernel-source driver that's in precise-updates (6.20.155.1); on a Dell 15R with BCM4312 it fails to connect to any networks. If I downgrade to the 5.100.82.38 version it works fine
<chiluk> tseliot, pad.lv/1154153  has been openned 
<tseliot> chiluk: thanks
<chiluk> it really might be a power issue, as I just noticed  NVRM: GPU at 0000:01:00.0 has fallen off the bus.
 * ppisati needs to reboot, brb
<chiluk> tselliot can you think of any other reason it would "fall off the bus?"
<brendand> rtg_, we're doing some SRU testing here and encountering what seems to be an incompatibility issue between the new broadcom driver and the 3.2 kernel
<brendand> rtg_, 6.20.155.1+bdcom-0ubuntu0.0.1 doesn't work with 3.2
<apw> retired/CVE-2012-2372: break-fix: 639b321b4d8f4e412bfbb2a4a19bfebc1e68ace4 local-2012-2372
<brendand> rtg_, it works with 3.5
<rtg_> brendand, its possible that it doesn't work with a retrograde kernel. tseliot is the owner.
<tseliot> brendand: what's the error?
<brendand> tseliot, roadmr has more details, i'll hand you over
<tseliot> ok
<brendand> tseliot, he may take a bit to respond - otp apparently
<tseliot> brendand: ok, no hurry
<apw> rtg_, ok i have pushed an update to overlayfs to the unstable-3.9 branch, i have also tested aufs and overlayfs (minorly) and they seem to at least let me do basic operations
<rtg_> apw, coolk
<rtg_> cool*
<roadmr> tseliot: ok, I'm here now, sorry! this system does see the wireless networks but is unable to connect to them with the 6.x driver. With the 5.100.x driver, it can connect to b/g networks only, n networks are visible but can't be connected to
<tseliot> roadmr: it sounds like a regression in the driver
<roadmr> tseliot: yep! I'm currently testing the proposed kernel, but the 6.x driver also fails with older kernels (i tested 3.2.0-29)
<rtg_> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1147678/comments/6 ?
<ubot2> Launchpad bug 1147678 in linux "kernel 3.5.0-26.40-generic oops immediately when doing schroot w/overlayfs" [Medium,Fix committed]
<tseliot> roadmr: yes, I don't think it's a kernel issue. 6.x can be buggy on some chipsets
<roadmr> tseliot: yep. What to do? file a bug? we're also concerned that this will hit people who apply the driver updates and will suddenly find their wireless not working :/
<tseliot> roadmr: yes please, we should probably revert the upload
<roadmr> tseliot: ok, I'll start by filing a bug
<tseliot> roadmr: thanks
<cking> kamal, the photo does not show any  < > brackets around the oopsing opcode, which is strange, also I'd like to see the objdump with the opcodes so we can correlate that with the one in the photo
<kamal> where/what is the "oopsing opcode" that you expect to see <> around?
<kamal> cking: ^^
<sforshee> kamal, that's the stuff in the line prefixed with "Code:"
<sforshee> normally the kernel will put angle brackets around which part of that output corresponds to the oopsing opcodes
 * cking wonders if it fell off screen on the right
<kamal> sforshee, cking: ok, well the lack of <> matches up with my observation that the RIP doesn't line up with the instruction boundaries I guess
<cking> maybe so, yes
<kamal> cking, sforshee: do you happen to know the objdump flag to make it include the opcodes?
<cking> kamal, I normally variations of objdump -d
<kamal> --show-raw-insn maybe -- I'll try it
<jsalisbury> ##    
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##  
<jsalisbury> ## Meeting starting now 
<jsalisbury> ##  
 * smb is off
<kamal> cking, sforshee: ok I have added a dump with opcodes (objdump --show-raw-insn) to bug 1136699 ...  aaaaand I'm still confused.  just fyi!
<ubot2> Launchpad bug 1136699 in linux (Ubuntu) "xserver crash in drm_vblank_count_and_time" [High,Triaged] https://launchpad.net/bugs/1136699
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 19th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<rtg_> apw, is this the first request for inclusion ? '[PATCH 00/13] overlay filesystem: request for inclusion (v16)'
<apw> rtg_, i got it from his git repo ... google wasn't showing that one when i searched
<rtg_> apw, it was 20 minutes ago
<apw> oh missread, no i think this is the third time he has asked for inclusion
<rtg_> apw, has Al formally responded in the past ?
<apw> "wait wait wait until atomic_open is in"
<apw> which it now is
<rtg_> well then, maybe it'll happen this time
<apw> doubtful... he will have some other objection i am sure
<apw> but ... its worth a shot
 * rtg_ -> lunch
<joshhunt> i have a question about which git tree i should be pulling from to stay current with the latest quantal kernel updates. when looking at the quantal tree I do not see a tag for 3.5.0-25.39, however looking at my precise tree I do. where tree should i be using?
<bjf> joshhunt, one sec checking on that tag, however, you should be using the quantal tree
<joshhunt> bjf, thanks
<bjf> Ubuntu-3.5.0-25.39
<bjf> joshhunt, i see the tag in the tree
<joshhunt> hmm
<joshhunt> bjf, from git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git ?
<apw> joshhunt, git fetch --tags origin ... perhaps
<bjf> joshhunt, yes, i'm in that exact tree right now
<joshhunt> bjf, ok running git tags now i have: Ubuntu-3.5.0-25.38 Ubuntu-3.5.0-26.40 Ubuntu-3.5.0-26.41
<joshhunt> apw, i will try that
<joshhunt> apw, ok that seems to have added the tag
<apw> joshhunt, i have that tag in my tree
<bjf> joshhunt, and i just did a new clone and it's there
 * bjf -> brb
<apw> bjf, if that tag was somehow not in the main branch you can miss it if you don't pull every day ... though they should be linear in that tree
<joshhunt> i cloned this a while back and have been doing pulls. another person in my group has the same problem. however, the fetch tags thing worked
<joshhunt> apw, do i need to do 'fetch tags' in addition to periodic pulls?
<apw> ok looking at the history there is some inconstancy in the order, someone has rebased it
<apw> you shouldn't in a tree like this, as it should not be being rebased
<apw> bjf, somehow we rebased .39 off the mainline when making .40 ...
<joshhunt> apw, ok cool thanks
<apw> bjf, joshhunt, it may have been embargoed at the time, and that might explain the shenanegins
<joshhunt> apw, what's that mean?
<apw> that .39 carried a very high profile security fix, which may have had unusual handling which may account for the discontinuity
<apw> which means when you pull 'days apart' you don't see .39 as something which is reelvant and you don't get the tag
<apw> without --tags
<joshhunt> apw, gotcha. thanks for your help.
<joshhunt> apw, how could you tell that it had been rebased? just so i can better understand when something like this happens in the future.
<apw> joshhunt, it is most obvious if you use gitk. ... if you use: gitk origin/master-next Ubuntu-3.5.0-25.39
<apw> and scroll down till you see .39 you will see that it is off the main branch
<joshhunt> apw, ahh i should install gitk... :)
<apw> gitk origin/master-next Ubuntu-3.5.0-25.39 ^v3.5
<apw> joshhunt, ^^ use that to avoid it making your machine swap
<joshhunt> apw, thanks
<joshhunt> apw, really appreciate the help
<bjf> back
<bjf> apw, odd, i remember struggling with it a bit but not rebasing it
<bjf> apw, we rebase master-next onto it
<xnox> ppisati: testing overlayfs kernel. seems to work ok, but I am getting some failures with direct write from upstart test-suite.
<xnox> will investigate further.
<apw> bjf, somehow in that rebase the three commits reposenting it also got rebased
<apw> bjf, you can see it in the gitk graph: gitk origin/master-next Ubuntu-3.5.0-25.39 ^v3.5
<bjf> apw, it was obviously me
<apw> bjf, *shrug* it is in the past, and no great shakes as the intent is definatly not lost in the mainline
<bjf> apw, agreed, though i try to make sure master never gets rebased like that
<bjf> i'll buy everyone a beer at the next vUDS
<apw> yeah it is clear you were trying to achieve the opposite, to stack the master-next on top, quite what is different between the two i am unsure
<apw> nope they are identicle, so it must be metadata somehow
<apw> bjf, the onlyh difference is the dates, and that is odd as you would expect a rebase even asked to be done from the wrong spot, to note the first few were the same and just leave them be.  very odd
<bjf> apw, what can i say, it's a gift 
<ppisati> xnox: nice, let me what's the outcome
 * ppisati would love to have a working nexus so he could do by himself... :(
 * infinity grumbles about someone removing sbsigntool from the kernel PPA.
<apw> infinity, i thought that sbsigntool was now in precise (not that i would have removed it)
<infinity> apw: It's in precise-updates, the PPA builds without pockets, because of security.
<apw> infinity, then it should be in -security else the pockets as they are in the release won't build the kernel
<apw> infinity, though to get it in the PPA i simply pocket copied it in from -updates in the first place 'with binaries'
<apw> infinity, so it is easy to fix
<infinity> apw: This is a fair point, actually.
 * ppisati bails out
<infinity> apw: Hold off on copying it to the PPA, I *should* copy it to -security so the kernels aren't technically FTBFS.
<infinity> apw: And your PPA does build against security, so that will fix it.
<infinity> apw: Thanks for talking sense into me.  Should be fixed shortly.
<xnox> ppisati: red herring, fails in the same way on amd64, I guess the test-suite is too strict again. So from my point of view it's good to go =)
 * xnox should email that.
<apw> infinity, np
 * rtg_ -> EOD
<zequence> I realized it might be smarter to put the kernels into a ~ubuntustudio-kernel owned PPA, so just created one, and uploaded to ppa:ubuntustudio-kernel/linux-lowlatency-sru
<zequence> apw: ^
<zequence> apw: I could do the metas too from now on
<bjf> back
<bjf> infinity, if someone puts something in *my* ppa without letting me know, i just might be tempted to clean it up some time
<bjf> just sayin
<bjf> infinity, however, i don't remember deleting it cause i didn't know what it was for
<infinity> bjf: S'all good, it doesn't need to be there anymore anyway.
<infinity> bjf: But I suspect it went away when henrix was doing his spring cleaning.
<bjf> infinity, it could have been me, i just don't remember doing it
<henrix> bjf: so, what's missing?
<bjf> henrix, heh, the sbsigntool got deleted, but it is no longer an issue
<infinity> Anyhow, it highlighted a bug anyway, so all good.
 * henrix reads backlog
<henrix> i can't remember deleting anything, but i have fat fingers so...
<bryce> ogasawara, sforshee would one of you mind rolling a kernel with the proposed patch for bug #1153302 if you have a chance?
<ubot2> Launchpad bug 1153302 in xserver-xorg-video-intel (Ubuntu) "[g33] Non-locking GPU lockup EIR: 0x00000010 PGTBL_ER: 0x00000002 IPEHR: 0x54f00006" [Undecided,New] https://launchpad.net/bugs/1153302
<bjf> bryce, i'll spin you one
<bjf> bryce, amd64, i386 or both?
<bryce> bjf, thanks.  amd64.
<bjf> bryce, http://people.canonical.com/~bradf/lp1153302/
<bryce> bjf, thanks
#ubuntu-kernel 2013-03-13
<ppisati> moin
<xnox> ppisati: morning. Yeah, overlay works fine here afterall =)
<ppisati> xnox: thanks, i saw your email
<ppisati> xnox: i'll send a pull req today
<xnox> kk.
<ppisati> xnox: thanks for testing :)
<xnox> \o/ awesome.
<ppisati> i realy would like to get my nexus7 back in shape
<xnox> ppisati: well, there is a way to repack .bootimg & add preseed and wifi config with the hope for it to come up with wifi network and ssh server installed.
<ppisati> xnox: any doc around?
<xnox> as i understand it's the screen brightness that is preventing you from installing?
<ppisati> xnox: yesterday i played a bit with .img
<ppisati> xnox: modified it, repacked and reflashed
<xnox> ppisati: http://blog.surgut.co.uk/2013/02/flash-nexus7-like-rock-star.html
<ppisati> xnox: but flash didn't go well
<xnox> that auto packs a presseed (modify as wanted) & copies network-manager's wifi config.
<xnox> this does not have a success-command to install ssh server though. I'll try to add that today for you ;-)
<ppisati> lp1126836
<ppisati> uh?
<ppisati> bug 1126836
<ubot2> Launchpad bug 1126836 in ubuntu-nexus7 "The error "df: warning: cannot read table of mounted filesystems: No such file or directory" is shown. Splash screen appears, then black screen." [Wishlist,Confirmed] https://launchpad.net/bugs/1126836
<ppisati> this is exactly my problem
 * smb yawns
<xnox> ppisati: ouch, I flashed with 11th march image last, and it was fine here with a 16gb wifi model here.
<smb> ppisati, You sound like having fun with the n7... not
<ppisati> smb: eh
<ppisati> xnox: did you try the phablet img?
<xnox> ppisati: yeah, that works fine as well.
<ppisati> xnox: here too
<ppisati> xnox: i can go back to android or to the phablet img
<ppisati> xnox: the only one NOT working, is the ubntu desktop one :(
<ppisati> xnox: anyhow, coffe, overlayfs pull req and than i'll play with your script
<apw> ppisati, how far does it get
<ppisati> apw: desktop img on nexus?
<apw> ppisati, yes
<ppisati> apw: dies after plymouth
<ppisati> apw: completely black screen
<ppisati> exactly like in lp1126836
<apw> ppisati, so the kernel is up and working, does serial work at that point ?
<apw> bug 1126836   
<ubot2> Launchpad bug 1126836 in ubuntu-nexus7 "The error "df: warning: cannot read table of mounted filesystems: No such file or directory" is shown. Splash screen appears, then black screen." [Wishlist,Confirmed] https://launchpad.net/bugs/1126836
<smb> apw, or even ssh (remember the fb fun)
<ppisati> apw: yes, but there's no user defined
<ppisati> apw: that's why i need to roll a custom img and flash it
<ppisati> apw: it's still an unconfigured ubuntu installation
<apw> didn't rtg complain about the same thing, and say that 1/10 reboots it worked and then he could customise it, and then it was fine ?
<ppisati> apw: dunno
<apw> worth a try
<apw> smb, yeah it does feel a little like that, but i don't think we have an old framebuffer in these devices to tickle the issue
<smb> apw, true. just something about the symptoms. though clearly can be anything else after and in the bug report ppisati mentions the title sounds like the fs is a problem and mountall
 * smb tries to understand the sentence he just wrote
<apw> heh
<ppisati> back in a bit
<apw> ppisati, ok i have my n7 up and working with the latest kernel
<apw> ppisati, on the ubuntu desktop image
<ppisati> apw: nice
<apw> so it must be an installation issue i think
<apw> which fits with rtg's experience
<ogra_> whats rtg's experience ?
<ogra_> apw, ^^
 * ogra_ still looks for somoebody that can reproduce ppisati's black screen issue
<ppisati> ogra_: rtg has it
<ogra_> ppisati, did he also have phablet installed before ?
<ppisati> ogra_: dunno
<ppisati> ogra_: let's see when he awakes if he can confirm those issues
<ppisati> ogra_: btw, people reported it in the past, i asked if they experience it with latest images
<ppisati> ogra_: let's see if they respond
<ogra_> i'll prepare an initrd for you with init=/bin/bash so you can set a rootpw 
<ogra_> i saw your comment on the whoopsie bug, yeah
<ogra_> i highly doubt thats related to your issue
<tseliot> apw: do you think it would be wrong if I made kmod treat "alias $module_name off" as a "blacklist $module_name"?
<tseliot> apw: as it would solve bug #1073062
<ubot2> Launchpad bug 1073062 in kmod (Ubuntu) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Undecided,Confirmed] https://launchpad.net/bugs/1073062
<tseliot> apw: I guess it wouldn't be the same...
<apw> tseliot, hmmm, thinking
<apw> no i don't think it would be the same at all
<tseliot> apw: I think we should just make sure that the installation command is set to /bin/true when alias is set to off, as the old module-init-tools did
<apw> that might work
<apw> we should fix kmod ... sigh
<apw> i have a patch here somewhere as well
<ogra_> ppisati, use fastboot flash to flash http://people.canonical.com/~ogra/tegra/nexus7/boot-bin-bash.img ....  have a keyboard attached and set a root pw ... then use fastboot flash with http://people.canonical.com/~ogra/tegra/nexus7/boot.img and log in via serial to debug
<apw> ogra_, could we not have a default user on these images which is removed when oem-config does its thing
<ogra_> apw, no, that woould mean lots of ugly extra hackery
<ogra_> apw, oem-config actually drops you to a root shell if it fails so you can do everything you need ... but if you dont have a display at all thats tricky (but also a very special case ... and ut of about 20 people doing installls the last days onlly ppisati (and now rtg)  seemed to have that issue
<ogra_> )
<apw> bjf also reported it iirc, he was the one who said "keep rebooting it" to solve it
<ogra_> how would keep rebooting fix the display ... 
 * ogra_ is confused
<ogra_> it seems nobody who only had installed the desktop image can reproduce it so i'm still blaming the phablet images until someone reports to see it who only ever had the desktop image installed
<ogra_> but lets see what ppisati finds :)
<apw> ogra_, that seems unlikely give we zap both flashes with new stuff
<apw> ogra_, but as you say ... we'll see
<ogra_> well, i suspect the phablet kernel or surfaceflinger get the device in a state that either our kernel or xserver dont get along with
<apw> ogra_, even though we go through a flash and full reboot?  i am sceptical
<apw> i would love to be able to blame phablet obviously
<ogra_> are you 100% the device is completely been powered off ?
 * ppisati is reflashin with today's img
<ogra_> a reboot will likely not clear everything 
<ppisati> and will try to reboot 10 times in a row
<ogra_> ppisati, well, it would have been nice if yoou used the above boot.img's to debug the issue with the broken image you had ... 
<apw> is there any way to pwoer down that device if you cannot boot it
<ogra_> zep, from the bootloader
<ogra_> *yep even
<ogra_> phablet doesnt power it down completely 
<ogra_> even with reboot -p it will still drain the battery as if it fully runs (see the release notes)
<apw> quality
<ogra_> android :)
<smb> lets take the battery out for 5 minutes... oh wait ...
 * ogra_ hands smb a hammer
<ogra_> nothing we couldnt fix ;)
<smb> ogra_, Luckily I am blessed with _no_ pahblet
<tseliot> apw: the solution to the problem is much much easier than I thought
<apw> tseliot, oh, which is
<tseliot> apw: modprobe looks for the module (which in this case is aliased as "off") in /sys and raises an error if it doesn't find it
<tseliot> apw: and I wouldn't expect to find anything like "off" in /sys...
<tseliot> apw: assert(kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN);
<tseliot> apw: and we shouldn't do this if the alias is "off"
<tseliot> that's it
<apw> tseliot, right the fix for kmod is pretty simply i think, we should do it for 'null' and 'off'
<apw> as those are both official aliases for not doing anything
<tseliot> apw: ah, null? Where is it documented?
<tseliot> apw: ah, here: http://ccrma.stanford.edu/planetccrma/man/man5/modules.conf.5.html
<tseliot> apw: ok, let me rework my patch and then I'll send it upstream to debian
<tseliot> apw: shall I do it for things like "alias iso9660 isofs" too?
<bjf> apw, since we respun quantal, we need a new lowlatency spun
<bjf> ppisati, same for ti-omap4
<ppisati> bjf: ack
<zequence> apw: Just a reminder: new quantal kernel in ppa:ubuntustudio-kernel/linux-lowlatency-sru
<apw> zequence, thanks
<apw> tseliot, great thanks
<ppisati> ogra_: both in userdata, right?
<ogra_> ppisati, no, boot
<ogra_> fastboot flash boot boot-bin-bash.img
<ppisati> ack
 * ogasawara back in 20
<rtg_> apw, Linus is pushing Al to include overlayfs
<apw> rtg_, yeah i saw indeed.  al seemed to be saying bring them alll on it
<rtg_> aufs includes :)
<rtg_> included*
<rtg_> though I don't think _that_ will happen soon
<apw> no i suspect there was more than a little irony in there
<rtg_> apw, ah, dentry_open is a new handler. That is why I couldn't figure it out yesterday, I thought it had morphed into atomic_open
<apw> rtg_, they did add atomic_open but it has odd semantics
<ppisati> ogra_: (WW) TEGRA(0): LVDS-1: Error querying display modes: No such device.
<ogra_> no prob
<ppisati> ogra_: it's the only warning i see in X
<ogra_> thats normal 
<ppisati> X is up&running
<ppisati> still i got a blackscreem
<ppisati> n
<ogra_> sudo service luxd stop
<ppisati> yep
<ogra_> (you still dont have a lamp in your house i suppose ?)
<ppisati> nope
<ppisati> [compiz] <defunct>
<ogra_> aha !
 * ogra_ wonders if italians go to bed early then ... no lamps at all ... scary
<ppisati> ogra_: not really, but i don't need lamps :)
<ogra_> so try something like rm /etc/init/luxd.conf
<ogra_> then reboot and see if that changes anything
<ogra_> (so we can rule out the backlight from the issue)
<ppisati> ogra_: guess what? :()
<ppisati> ogra_: :)
<ogra_> works ?
<ppisati> yes :)
<ogra_> ok
<ogra_> so that means after phablet was installed 0 is actually 0
<ogra_> while with our kernel 0 is actually 40% or so
<ogra_> (for the brightness)
<ogra_> so something redefines that value in a weird way
 * ogra_ will drop luxd for a start ... but thats a bug we need to inspect deeper
<ogra_> definitely something between the two kernels
<ppisati> mv /etc/init/luxd.conf /etc/init/foorbar.conf
<ppisati> reboot
<ppisati> and it worked
<ogra_> yes
<ppisati> i shall try to put it back
<ppisati> and see what happens
<ogra_> that means the 0 value is different after you installed phablet
<ogra_> or the ambient sensor doesnt work anymore 
<rtg_> ogra_, is there a config option for the ambient sensor driver ? perhaps it isn't enabled.
<ogra_> well, it definitely is, else luxd would never have worked
<ogra_> luxd is a dumb script that just shortcuts the two devices
<ogra_> ambient -> some computation  -> brightness
<jamon> any BTRFS folks around? I have an impossible to rm file on a BTRFS volume
<ogra_> rtg_, http://paste.ubuntu.com/5610989/ 
<jamon> btrfsck sees the file and references to others that were deleted, but this one won't go
<ogra_> rtg_, if you never used the phablet image that works just fine 
<rtg_> ogra_, yeah, I've yet to install it.
<ogra_> i assume after you use the phablet image /sys/bus/i2c/drivers/al3010/2-001c/show_lux returns 0 
<ogra_> constantly 
<ogra_> (just a theroy though)
<ogra_> i would suspect there is a firmware in android that triggers this 
<ogra_> behavior
<rtg_> ogra_, lemme look at teh driver to see if it requests firmware
<ogra_> since italians have no lamps its hard to get some values from ppisati though ... to see if the value changes if you apply some bright light 
<rtg_> ogra_, maybe we don't pay him enough to own a lamp ?
<ogra_> ah that might be it 
<ogra_> should i mail leann to ask about giving him a $10 bonus to buy a desk lamp ?
<ogra_> :)
<rtg_> ogra_, no firmware, but there is a calibration file: "/data/lightsensor/AL3010_Config.ini"
<ogra_> ah
<ogra_> so it gets recalibrated then
<rtg_> looks like it scans a single integer, 'sscanf(buf,"%d\n", &calibration_value);'
<rtg_> ppisati, maybe you can disk around with that ? See calibration_regs in drivers/hwmon/al3010.c
<rtg_> dick*
<ppisati> rtg_: i'll do
<jamon> is there anywhere else i should go to report/debug issues with BTRFS?
<rtg_> ppisati, though it looks like the defaults ought to work.
<ppisati> well, i can reinstall phablet
<ppisati> see what it reportas
<ppisati> *reports
<ppisati> reinstall desktop and compare
<rtg_> ppisati, you can get a console under android ?
<ppisati> rtg_: yes
<xnox> jamon: #btrfs ?
<ppisati> rtg_: sshd and i cant access / from there
<ogra_> rtg_, yup, adb :)
<ogra_> or you can install ssh ... 
<xnox> jamon: their mailing list is very good for low level debugging and fixing stuff. See their homepage for details.
<jamon> that's an idea, hope they don't send me back here, but thanks, will take the slow and deliberate debugging approach
<jsalisbury> bjf, fyi, I'm chatting on #is about our broken bots/scripts on cranberry.  Seems they did some python updates this morning.
 * ppisati -> gym
<ppisati> back later
<apw> jsalisbury, yay for updates
<jsalisbury> apw, \o/
 * rtg_ -> lunch
<apw> zequence, this package seems to have been built without the .orig.tar.gz
<apw> is that intentional
<apw> zequence, 25.25 seems have been with
<apw> zequence, plus when you build the source one should use -v<version in -release/-updates> to get the full changelog
<apw> zequence, yeah -26.26 also used and orig.  so perhaps we should rebuild a -26.28 which is built using the orig and the -v3.5.0-17.18
<zequence> apw: Ok. My bad. Going to rebuild it then.
<apw> zequence, it will upload a heck of a lot faster with an .orig as well
<apw> zequence, let me know when the source is in as i do not need the binaries for our purposes
<zequence> apw: I'm wondering about how I should do with the changelog. Should I just change the upload number on the current last entry,  make a git commit and the rebuild, or do I need to create a new entry in the changelog completely?
<zequence> ..since I'm not really changing anything in the source other than the changelog
<apw> zequence, i would normally make a new section none the less, and just put like
<apw>  * no change rebuild with .orig.
<zequence> ok, will do
<apw> zequence, don't forget the -v<version> on the dpkg-buildpackage -S
<zequence> apw: Haven't used that one before. Changes before version? Last version, or the last orig version?
<rtg_> zequence, the last version in -updates
<zequence> Aha
<zequence> Learning debian packaging fully is on my todo list. This is really awful
<apw> zequence, last version in -updates indeed
<zequence> Ok, so I need to use versione each time we do an non ABI update
<zequence> apw: It's in the ppa now
<rtg_> zequence, you should do it every time you upload
<zequence> rtg_: But, if the previous upload ended up in -updates?
<rtg_> zequence, the rule is simple. every time you package for an upload you specify the version of the package in -updates. that is what creates the diff in launchpad.
<zequence> ok
<manjo> apw, patch upstreamed .. thanks for pointing that out 
<manjo> apw, patch upstreamed .. and you are cced too 
<apw> manjo, cool
<manjo> rtg_, trying to speak but mumble is not working 
<manjo> mumble sucks
<rtg_> manjo, its more likely to be pulseaudio
<manjo> I need to try my laptop ... might be the mic on the webcam 
<ohsix> thankfully the desktop mixer shows sources and levels!
<antarus> infinity: ping
<infinity> antarus: Sup?
<antarus> so apt-get autoremove
<antarus> is that supopsed to work...?
<antarus> it wants to remove weird stuff on my system
<antarus> and my debian developer co-workers are all like 'oh that thing is totally unsafe'
<infinity> It's supposed to work, yes.  Define "weird stuff".
<antarus> it wants to remove rake
<antarus> but I hav epuppet and rails installed, which depend on rake
<antarus> also my precious linux-tools-package (that installs the kernel 'perf' binary)
<antarus> I'm fairly sure is just a 'recommends'
<antarus> infinity: basically for the kernel pruner, they inquire as to why we do not just prune the packages directly, instead of marking them for autoremove
<infinity> Erm, I'd want to see the output of that.  autoremove can't remove anything that's depended on, unless it also removes the other package.
<infinity> And, indeed, I see rails -> ruby-rails-2.3 -> rake here as a dependency chain.
<infinity> Now, if rails itself was never marked manually installed (was it a dep of something else that you've since removed?), then autoremove is doing its job if it pulls out rails.
<antarus> it is a dep of puppet
<infinity> No it's not.
<infinity> And there's no reason it should be.
<antarus> s/dep/suggest/
<antarus> our puppet is extra special, probably
<antarus> ;p
<antarus> i   puppetmaster        Depends  puppetmaster-common (= 2.7.18-2gg21)
<antarus> i A puppetmaster-common Suggests rails (>= 1.2.3-2) 
<antarus> see ;p
<antarus> I'm guessing we do not always trigger 'manual installs' properly
<antarus> so we just cannot trust apt-get autoremove at all
<infinity> Possibly not.  Shame.
 * antarus has no idea how manual isntalls work
<infinity> Well, you could duplicate the same logic in the autoremove-kernels snippet to just do it yourself.
<antarus> yeah
<antarus> we probably will
<infinity> Things are marked manually installed if you either manually install them (say, apt-get install foo) or if they're a direct dependency of something in the "metapackages" section.
<infinity> Any dep pulled in lower than that is marked auto.
<antarus> so dpkg debs are not manual?
<antarus> because dpkg and apt don't chat with each other?
<MoPac> Hello; I'm looking for some help with configuration of hooks or modules when creating initrd images for my kernel.  After repairing a kernel from a live USB, the boot process "forgot" that it needed to open my LUKS container to find the boot partition.  I have restored an old kernel image that works, but I'm worried that this is going to happen again on next kernel upgrade / image build.  What do?
<rtg_> MoPac, I think everything in /etc/modules gets bundled into the initrd.
<MoPac> So do I just add lines that say "dmcrypt" or "cryptsetup" or somesuch?  No need to actually direct it to a particular drive or make a script to open a given container?
 * rtg_ -> EOD
<electronplusplus> Hi. I'm learning unix and kernel programming. One thing the I want to do is to code a complete unix command. my question is: What kind of command, that are useful, are missing in linux?
#ubuntu-kernel 2013-03-14
<ppisati> moin
<rtg_> ogra_, is dropping luxd all that it took for the ambient light sensor to start working ?
<ogra_> rtg_, well, there is definitely also a kernel issue .. but without luxd it wont be exposed as easily (i bet though that you end up with a black screen when moving the brightness slider to zero
<ogra_> )
<rtg_> ogra_, you probably also lose the automatic adjustment ?
<rtg_> I find that it annoys the hell out of on Android 'cause it never gets it right and is always hopping around.
<ogra_> well, yeah, but that was supposed to be moved into gnome-settings-daemon anyway, luxd was a hackish interim 
<rtg_> ogra_, so ppisati N7 wasn't really broken ?
<ogra_> well, there is an issue for sure ... in that our kernel behaves differently once phablet was installed 
<ogra_> something redefines the 0 value
<ogra_> but you will atm only hit it if you use the brightness slider and pull it to 0 i guess
<ogra_> would be good if ppisati could check that 
<rtg_> ogra_, sounds pretty low priority unless he's got no other N7 bugs to work on.
<ogra_> yeah
<ogra_> it might even be that g-s-d catches that and sets it to 1 instead of 0 ... so a test would be welcome 
<ogra_> with luck userspace shields us from the bug 
<ogra_> (which would make it a non issue for now)
<ppisati> ogra_: got a new high priority task assigned, put n7 work on the back burner
<ppisati> rtg_: ^
<ogra_> well, could you at least do that one test (open the brigfhtness GUI and slide all the way down) ?
<ppisati> ogra_: android? phablet? desktop?
<ogra_> desktop
<ogra_> if the screen doesnt turn fully black with that, we're fine and there is no further work required anyway
<ppisati> ogra_: ok, i'll do
<ogra_> thx
<ppisati> ogra_: ok so
<ppisati> ogra_: i pulled the slide down to 0
<ppisati> ogra_: and i've a black monolith
<ppisati> ogra_: now
<ogra_> lol
<ppisati> obviously the chance i'll hit the slide again
<ogra_> right, so its still serious
<ppisati> and bring the brightness to a normal level are 0 now
<ogra_> you can indeed do it from cmdline 
<ogra_> echoing something into the brightness setting in sysfs
<ppisati> ogra_: neee
<ppisati> ogra_: i was able to find it again
<ogra_> haha, lucky guy
<ogra_> well, move on to your important thing ... we can take care later ... 
<ppisati> i could still see some shadow on the screen
<ogra_> sad, i was hoping we can put it to death
<ppisati> ogra_: did you drop luxd in today's img?
<ogra_> yes
<ppisati> ogra_: nice
<ogra_> it was an interim solution anyway ... 
<ogra_> gnome-settings-daemon will get that functionality 
<bjf> ppisati, did you turn the crank on quantal ti-omap4 after our respin?
<ppisati> bjf: not yet
<ppisati> bjf: i'll do it now
<ppisati> git log -p
<ppisati> ops
<ogra_> "not a branch"
 * ogasawara back in 20
<rtg_> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1154917/comments/5
<ubot2> Launchpad bug 1154813 in initramfs-tools "duplicate for #1154917 Boot broken with initramfs-tools 0.103ubuntu0.5b1 - wait-for-root doesn't wait" [Critical,Fix released]
<ppisati> bjf: done
<bjf> ppisati, thanks
<jsalisbury> rtg_, ack, thanks for the info
<sconklin> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1097315
<ubot2> Launchpad bug 1097315 in xserver-xorg-video-intel "Xorg hangs in drm_helper_connector_dpms" [High,Triaged]
<sconklin> https://bugs.launchpad.net/utah/+bug/1092924
<ubot2> Launchpad bug 1092924 in utah "Cobbler install of recent raring-desktop images failing" [High,Triaged]
 * ppisati goes out for a bit
 * rtg_ -> lunch
<tjaalton> ogasawara: hey, how about rebasing i915_hsw to 3.8.x, yea/nay? the current version is showing it's age already :/
 * cking -> food
<rtg_> tjaalton, confused. what are you referring to ?
<tjaalton> rtg_: the drm driver for haswell on the quantal kernel, currently based on 3.7-rc6
<rtg_> tjaalton, oh, you mean rev the haswell driver in Quantal up to current Linux 3.9-rc2 upstream ?
<tjaalton> rtg_: well, to 3.8.x for starters, going further would probably mean (more) issues with drm_*
<rtg_> tjaalton, would the fix some specific issues ?
<rtg_> would tah*
<rtg_> frick
<tjaalton> :)
<rtg_> thats 325 patches
<tjaalton> yes, and enable backporting newer fixes
<tjaalton> 3.9rc would be some 250 more :)
<rtg_> tjaalton, how about if you just wait for the 3.8 LTS kernel ? or is it Quantal user space you need ?
<tjaalton> that's one option yes
<tjaalton> so raring kernel + quantal xorg stack
<gQuigs> does mtrr_cleanup serve a purpose on a server machine?  is it even still relevant on deskops?
<rtg_> tjaalton, I don't think there is _any_ chance that we could SRU 325 patches back into Quantal
<gQuigs> related askubuntu question: http://askubuntu.com/questions/244473/how-and-why-should-i-specify-mtrr-gran-size-mtrr-chunk-size
<tjaalton> rtg_: well, it is unreleased hw, i915_hsw is only used on hsw
<rtg_> tjaalton, except that the haswell fixes are all intertwined with the rest of the i915 driver code
<ohsix> if you have a processor that can do PAT, mtrr's aren't very relevant
<tjaalton> rtg_: umm, no? it's a separate module in ubuntu/i915
<rtg_> tjaalton, lemme refresh my memory. haven't looked at it in awhile
<mainerror> ohsix, are there still CPUs there PAT isn't available? I mean it should be available since P3.
<mainerror> s/there/where/
<rtg_> tjaalton, ok, now I remember. ogasawara copied the whole haswell mess into ubuntu/i915 and restricted the PCI IDs
<tjaalton> yep
<rtg_> tjaalton, so there are no haswell based systems out there in the real world yet ?
<tjaalton> rtg_: nope
<rtg_> tjaalton, ok, that makes it easier.
<ohsix> mainerror: i have one somewhere, but that was the intent of mentioning it :]
<ogasawara> rtg_, tjaalton: so one concern I do have is I pulled the updated driver from an intel specific branch which only contained the patches we supposedly needed for haswell
<rtg_> ogasawara, one would assume that all landed in 3.8 ?
<ogasawara> rtg_, tjaalton: so I'd be concerned what else we'd get if we pulled the driver directly from v3.8.2.  I'm not opposed to it though since it is pretty well quarantined to just those pci id's
<tjaalton> i've created a dkms package and tested that it at least builds against the quantal headers, so rebasing it should be doable
<ogasawara> rtg_: yes, I would assume all those patches are in the current 3.8
<ogasawara> rtg_, tjaalton: and we do at least haswell platforms to test on
<rtg_> tjaalton, does your DKMS driver actually fix some problems ?
<gQuigs> ohsix: mainerror:  docs say it's still used as a workaround for X, but I'm not sure that's still true
<gQuigs> ohsix: mainerror: if you check both of your dmesgs the current patern is that one of you would have an mtrr error
<ohsix> gQuigs: on machines without PAT, and MTRRs that are set up poorly by the bios that might be true; kms may have implications for mtrrs too, id unno
<ohsix> \m/ [    0.000000] PAT not supported by CPU.
<Sarvatt> rtg_: yeah, the SDP's are decentish but real hardware is coming back with lots of problems fixed in it, especially eDP ones (no surprise)
<rtg_> Sarvatt, ok, I'll have a look to see what can be done.
<gQuigs> ohsix: :(.. what's your CPU?
<tjaalton> ogasawara: yeah, aiui the branch was based on 3.7-rc6, and since you only pulled i915 the rest of the branch churn was likely irrelevant
<tjaalton> yeah I was about to mention the eDP issues..
<tjaalton> also, powerxpress with fglrx
<ohsix> gQuigs: it's an old P3; but it doesn't matter :>
<tjaalton> rtg_: there are some issues with the nightly mainline kernel where it just boots up with a blank screen, so testing with them is worthless atm until the issues are fixed. the dkms package allows updating just the module we want to test
<tjaalton> 3.8 definitely fixes some issues
<tjaalton> with ivb + eDP for instance
<tjaalton> i915_hsw won't help there
<rtg_> tjaalton, I think ogasawara must have gone a bit further. the last commit in ubuntu/i915 'UBUNTU: SAUCE: i915_hsw: move i915_hsw_enabled symbol to intel_ips' appears to be 68d18ad7fbc16288aa230ec0ffb4416fd4363c87 upstream, which is v3.8-rc2~13^2~7^2~17
 * gQuigs didn't realize P3s were still supported
<tjaalton> yeah it has some additional fixes
<rtg_> or rather 'UBUNTU: SAUCE: drm/i915: set the LPT FDI RX polarity reversal bit when needed'
<ogasawara> rtg_: lemme know if you'd prefer I take a first stab at this i915 rebase
<rtg_> ogasawara, can you really rebase it? I was just extracting all 52 patches and was gonna apply them mostly by hand.
<tjaalton> 52?
<rtg_> tjaalton, in the 3.8.2 tree, 'git format-patch 68d18ad7fbc16288aa230ec0ffb4416fd4363c87..HEAD -- drivers/gpu/drm/i915/'
<tjaalton> ah
<ogasawara> rtg_: I'd go the route of applying by hand
<tjaalton> well what I tried was: copy i915/*, re-apply the SAUCE patches by hand, and fix the conflicts
<tjaalton> then commit that as the rebase, and any additional ones as new SAUCE patches
<tjaalton> for instance, drm_mm_hsw.{c,h} needs a refresh :/
<rtg_> tjaalton, but you lose the history
<tjaalton> rtg_: true
<tjaalton> but only of the rebase
<tjaalton> i mean, the first commit didn't carry the history either
<ogasawara> rtg_: the other way is you'd have to revert all the patches, copy i915/* like tjaalton said, and then reapply all the sauce patches and fix any conflicts
<tjaalton> you don't need to revert them either :)
<ogasawara> rtg_: I'd assume it's just as much work as just applying the new ones by hand
<tjaalton> although it's probably cleaner/safer to re-do those steps
<rtg_> tjaalton, you might be right
 * ogasawara lunch
<rtg_> tjaalton, though I am loathe to rebase bjf stable tree. we generally don't do that after its released, so there are gonna be lots of messy reverts.
<tjaalton> well, you can avoid the reverts if you just copy/re-appy sauce/fix conflicts, then commit the result as le grande rebase
<rtg_> yeah, I'll mess with it a bit.
<tjaalton> if you want to do it that's fine, but I know what api changes happened in 3.8 so when you give up I can give it a go ;)
<rtg_> tjaalton, if you're jonsing to do it. just remember that it can't be a rebase, it has to be a linear application of patches (which may include reverts)
<tjaalton> rtg_: ok, I'll keep that in mind
<tjaalton> rtg_: but with this approach it's easy to spot the issues, so I'm not stopping you (the kernel team) to do it the right way :)
<rtg_> kamal, git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
<kamal> rtg_: thanks
<tjaalton> rtg_: so, I'm good either way, just let me know
<rtg_> tjaalton, go ahead and try it your way. I'm still grovelling around in it.
<rtg_> though I gotta take off soon
<tjaalton> rtg_: heh, ok something for tomorrow
<rtg_> tjaalton, seems that there are some new functions; drm_mm_insert_node_in_range_generic() and drm_mm_insert_node_generic().
 * rtg_ -> EOD
#ubuntu-kernel 2013-03-15
<autoditac> hey everyone. is this the right question to ask questions regarding nfs on ubuntu?
<autoditac> s/question/channel
<xnox> autoditac: #ubuntu-server sounds more appropriate channel.
<autoditac> xnox, thanks!
<ppisati> moin
<Eimann> https://lwn.net/Articles/542664/
<henrix> rofl
<Eimann> :)
<rtg_> ogasawara, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1011449/comments/7
<ubot2> Launchpad bug 1011449 in linux "[Feature] Include support for Intel Bordenville chipset (i2c (SMBUS), Watchdog timer and PCI IDS)" [Medium,Fix committed]
<ogasawara> rtg_: ack, thanks
<rtg_> ogasawara, also https://bugs.launchpad.net/intel/+bug/1031162/comments/2
<ubot2> Launchpad bug 1031162 in linux "[Feature] Haswell-ULT UART DMA support" [Undecided,Fix committed]
<rtg_> ogasawara, prolly time for an upload today
<ogasawara> rtg_: indeed
<rtg_> now that I've attached  a giant bag of shit to our kernel
<ogasawara> hehe
<rtg_> I'll get some boot testing done first
<ogasawara> ack
 * ppisati back in ~20
 * ogasawara back in 20
<dhanasekaran> Hi Guys How to debug glic package
<infinity> plars: You've had a regression-testing task for linux/lucid open for 12 days.  Did it get forgotten?
<plars> infinity: no, I commented about the bug that I opened, last I talked to john I wasn't clear if this was a bug in the tests or in one of the patches from the CVE. He's still trying to hunt it down.
<plars> infinity: I can go ahead and just mark it failed if that makes things go easier
<plars> infinity: this is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136526 you are talking about right?
<ubot2> Launchpad bug 1136526 in kernel-sru-workflow/regression-testing "linux: 2.6.32-46.105 -proposed tracker" [Medium,In progress]
<infinity> plars: Ahh, I didn't notice it was blocking on another bug.  All good.  I'll let jjohansen deal with it.
<ppisati> guess what?
 * ppisati -> gym
 * rtg_ -> lunch
 * henrix -> EOD
 * cking -> EOW
 * smb -> EOW
 * rtg_ -> EOW
 * ogasawara lunch
<kirkland> is it possible to force usb down to usb1 only?
<kirkland> I have a device that's not cooperating with usb2
<kirkland> and I don't see an ehci_hcd module
<JanC> kirkland: you can blacklist USB2 modules of course
<kirkland> JanC: and what's that module called?
<sforshee> much of the core USB stuff is built-in for stock ubuntu kernels
<kirkland> sforshee: yeah, that's what it's lookin' like
<JanC> hm, maybe it's still possible to disable USB2 for particular devices using udev?
<sforshee> JanC, not sure. I don't think it's as simple as turning off a piece of software.
<sforshee> iirc negotiation between full- and high-speed USB starts way down at the signaling level
<JanC> sforshee: I know in the past you could disable it
<JanC> but maybe not on a per-device level  :-/
<JanC> also, USB 1.0 or 1.1 are quite different AFAIK
<JanC> USB 1.1 devices should be compatible with USB 2.x & 3.x
<JanC> USB 1.0 OTOH...
<sforshee> kirkland, I'm not finding anything other than rebuilding with ehci_hcd as a module and blacklisting it, of course then you lose high-speed usb for all ports
<JanC> or maybe finding an usb 1.0 controller
<kirkland> sforshee: okay, thanks
<kirkland> sforshee: yeah, I understand
<kirkland> sforshee: this is for debugging, mainly
<kirkland> sforshee: I'll get a debug kernel together;  cheers!
<sforshee> kirkland, np
<JanC> kirkland: is this device listed in e.g. usb-devices output?
<kirkland> JanC: oh, yeah, absolutely;  it's just the communications are wonky and I've read by some that they've had better success when disabling usb2
<kirkland> fwiw, I'm debugging a long standing problem i've had with irregularaties reading solar data from my PV inverter
<JanC> so in theory it's at least USB 1.1, I suppose
<JanC> or 1.10 or whatever
<mjg59> stgraber: Oh hey all my woes today turn out to be your fault
<mjg59> Makes a change :)
<mjg59> stgraber: Oh, I tell a lie
<mjg59> stgraber: It's actually James Leddy's fault
<wmp> hello, i kabe installed 3.8.3 on 12.10 from packages, how to install nvidia drivers on this kernel?
<stgraber> mjg59: what happened? :)
<mjg59> stgraber: https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/1155780
<ubot2> Launchpad bug 1155780 in trousers "Postinst fails in chroot environments" [Undecided,New]
<stgraber> mjg59: ah, sounds like it's still my fault for having introduced that code in the dev release even if I wasn't the one SRUing it...
<stgraber> mjg59: can you confirm that the following works: http://paste.ubuntu.com/5617788/
<stgraber> mjg59: that's the logic in current trousers. If that works, we should get that uploaded to 12.04 and 12.10
<mjg59> stgraber: Hrm. I /suspect/ that that would still trigger in the chroot
<mjg59> stgraber: We're actually building images, so udev will have been installed
#ubuntu-kernel 2013-03-17
<__dan__> having 100% repeatable kernel panic with an lsi megaraid card using megaraid_mbox driver
<__dan__> tried with latest ubuntu precise kernel 3.5.x and latest 3.8.3 kernel from kernel.org, getting same problem
<__dan__> also tried throwing some boot flags (pcie_aspm=off disable_msi=1) with no effect
<__dan__> ran out of ideas :/ card is known good, working for years on win2003 server
<__dan__> was wondering if this patch http://bugs.centos.org/view.php?id=5383 has made it upstream yet
<__dan__> or sidestream or whatever
<__dan__> heh
<Jef91> So I'm trying to compile the 3.8 kernel sources from raring on Precise, it compiles fine on 64bit Precise, but on 32bit precise I get this compile error related to turbostat -> http://paste.debian.net/242346/ any ideas/suggestions?
#ubuntu-kernel 2014-03-10
<ppisati> moin
<smb> ppisati, morning
<ppisati> smb: hey
 * apw yawns ....
<rsalveti> apw: hey, so I got a branch for hammerhead (nexus 5) at https://code-review.phablet.ubuntu.com/gitweb?p=ubuntu/kernel/trusty.git;a=shortlog;h=refs/heads/hammerhead, and was planning to get it uploaded, but was wondering if this branch could be part of our official trusty git tree
<rsalveti> infinity also asked the same thing when he approved the FFe yesterday
<rsalveti> this device is not officially supported by us, but still useful as people can't necessarily buy nexus 4 anymore
<apw> rsalveti, i kinda don't want anything we arn't supporting then agian, thats all of them, so ...
<apw> rsalveti, we must be dropping some which have no 4.4 bases right?
<rsalveti> apw: for now we're just dropping maguro
<rsalveti> apw: right, as in theory none is "supported" :-)
<rsalveti> but we're still changing them all together when we get a security fix, apparmor rebase and so on
<apw> rsalveti, no none are supported, they arn't getting any updates
<rsalveti> right
<apw> i mean you imply we are doing security on them there ... noone is
<rsalveti> well, someone did already a few times
<jjohansen1> oh? we are still rebasing those? rsalveti does that mean for my next apparmor pull request I should give you a version for maguri
<rsalveti> jjohansen1: don't need to care about maguro anymore
<apw> jjohansen1, are we expecting new AA before release?
<jjohansen1> apw: yes
<apw> jjohansen1, how long from now?
<jjohansen1> apw: all too long. It will be next week at earliest
<rsalveti> jjohansen1: and we're also dropping grouper, so we'll be always based on 3.4+ (manta, mako, flo)
<jjohansen1> rsalveti: okay, thanks
<jjohansen1> apw: on the up side it will drop the stupid backport config
<rsalveti> infinity: would it be fine to keep the hammerhead tree separately then?
<jjohansen1> it does auto detection instead
<apw> rsalveti, so i think if we can reap magura and grouper then hamerhead prolly can replace them
<rsalveti> apw: sounds like a deal
<infinity> rsalveti: I'm happy with whatever makes most sense to apw and rtg, I just wanted to make sure they were in on the decision.
<rsalveti> infinity: sure, cool
<apw> we'll have a think, and confirm
<rsalveti> alright, thanks
<apw> rsalveti, hey what happened to goldfish
<rsalveti> apw: sorry, that's still needed
<rsalveti> but also 3.4 based at least
<rsalveti> jjohansen1: ^
<jjohansen1> rsalveti: 3.4 based is good, that is a much easier backport than 3.0
<apw> jjohansen1, so the AA update is for master-next and 3.4 as well for this quintette
<jjohansen1> apw: yeah
<jjohansen1> apw: I will be leaving the stupid config for the saucy backport
<apw> jjohansen1, ok
#ubuntu-kernel 2014-03-11
<phillw> Hi good people.. I've just pulled in an update to my 14.04 machine... graphics have gone to lower resolution... but, I also lost networking. As there is no network, it's pretty hard to file bugs... But, I'm a n old hand at bugs - so if you say what you think it may be, I'll go set up a VM and get you good peop,e some some good data.
<phillw> config-3.13.0-16-generic
<phillw> is the one that breaks... config-3.13.0-11-generic still works fine with all of the rest of the updates.
<apw> phillw, well i have no specific expectations of that, so i would say get all the ones in between and try those to find the latest one which worked (-12 to -15)
<miseria> "el pasado son todas las cosas reales de la vida que planeamos y otras que se dieron en el futuro de nuestro pasado" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<TheDrums> apw: You seem most active here and have access, can you  /msg chanserv op #ubuntu-kernel   then  /mode +b-o *!*@CPEc8d3a35a59fe-CM000f9fa607d2.cpe.net.cable.rogers.com apw   to stop that daily spam? :)
#ubuntu-kernel 2014-03-12
<marvin24> ppisati: sorry to bother you again, I ask some days ago about applying http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/tegra20-paz00.dts?id=5816898b9592b877209e91c493db946ab275d825 to the unstable (3.14..) branch of the ubuntu kernel
<marvin24> are you still planing to do it?
<Llynix> I'm having problems with the latest few kernels, they don't seem to boot properly.  I've had to go back to 3.5.0-44 in order to get my computer booted.  Would like to know how to properly file a bug report or perhaps find one already open for my problem.
<ppisati> marvin24: i though the outcome of that discussion was: this patch is gonna enter enter 3.15 and we are going to move unstable to 3.15 ASA it's out, so...
<ppisati> marvin24: IIRC
<marvin24> ppisati: I'm not sure what happens with unstable
<marvin24> my guess was it becomes stable at some point
<marvin24> thus keeping version 3.14
<ppisati> marvin24: nope
<ppisati> marvin24: unstable it's just a sandbox right now
<ppisati> marvin24: i mean, yeah, it's going to be the stable branch in the future (for U)
<marvin24> ah, maybe you can still apply it, because I want to play with the kernel package (and the installer)
<ppisati> marvin24: but wasn't your patch entering upstream?
<marvin24> yes, but only in 3.15
<marvin24> if ubuntu every releases a 3.14 kernel for trusty, I want to make sure that this patch is in
<marvin24> not sure how to accomplish this ...
<ppisati> marvin24: nope
<ppisati> marvin24: we'll never release a 3.14 kernel for T
<ppisati> marvin24: unstable will go to 3.15, maybe .16, etcetc and at some point we'll say "ok, U will release with this version" and it'll become the U kernel
<marvin24> ppisati: ok, thanks for explanation
<marvin24> I think I'll apply it locally then and play with it a bit later
<Llynix> Where are Ubuntu kernel bugs filed?
#ubuntu-kernel 2014-03-13
<ppisati> yo
<cristian_c> Hi
<cristian_c> I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
<ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
<cristian_c> I was told to open an upstream bug report
<cristian_c> I've read it, but I've got some doubt:
<cristian_c> for example: Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
<cristian_c> What kernel does it refer, exactly?
<cristian_c> And then: While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
<cristian_c> How can I find the commit?
<cristian_c> Any ideas?
<smb> cristian_c, Mainline kernel packages you can find at http://kernel.ubuntu.com/~kernel-ppa/mainline/ and about the regression part; if you never saw that working, then I would just assume this is not a regression. 
<cristian_c> smb, it's not a regression
<smb> So, you just should clearly say that when doing an upstream bug report. And for confirmation try the latest mainline kernel (3.14-rc6) to see it has not been by chance fixed.
<cristian_c> smb, I was told that a new bug report would be open for the regression, instead
<smb> Which regression ?
<cristian_c> smb, th regression that I found trying 3.13.0-031300rc5
<cristian_c> smb, the orginal bug never has been resolved in many years
<cristian_c> *original
<cristian_c> smb, then, should I assume 3.14-rc6 kernel in the upstream bug report?
<smb> Ah ok. So you would check with 3.14-rc whether that regression still happens (as well as in theory the leds thing). But if wireless works otherwise and its just the led I would not have too high hopes for ever getting them to work.
<cristian_c> smb, but the workaround worked
<cristian_c> before
<cristian_c> smb, but reversed
<cristian_c> and the there is the regression too
<cristian_c> *then
<cristian_c> smb, I've tried the 3.14 and the regression is confirmed
<smb> cristian_c, So whatever the regression is (I have not read through the whole old report), you should open a new report for that and first try to resolve this in that report. For that you should try to figure out roughly when this happened (you could use the mainline kernels for that, too)
<cristian_c> smb, ok
<smb> cristian_c, Joe should be around on this channel a bit later. I see he had been working on the bug
<cristian_c> smb, he has told me to open an upstream bug report
<cristian_c> *that I should open
<cristian_c> smb, I can open a new bug report for the regression
<cristian_c> smb, but always in launchpad?
<cristian_c> or upstream?
<smb> cristian_c, Ultimately upstream as you verified its still a problem in 3.14. Though one also can open a launchpad bug, too and link that to the upstream bug (can be done later, too). Depends a bit on how Joe would like to handle it
<smb> cristian_c, So just something in general. I must admit I have some difficulties understanding all the leds and buttons, expected behaviour and what the regression is. Might be just me as a non-native speaker but it general keep it as simple as possible and assume the reader has no clue how your laptop looks like. ;)
<cristian_c> smb, the laptop has got a button with led
<smb> By the way you can add a bit more info (and/or debug a bit more) by adding info what is in /sys/class/leds (that should have all the available leds). Also cat of trigger inside a led dir gives the available triggers.
<smb> cristian_c, In the bug, irc is a bad media for info
<cristian_c> it has got two states: enable/disabled , shown respectively with blue/red lights
<cristian_c> smb, ok
<cristian_c> smb, but I've already explained it in the report
<smb> Also when you have written "none" to the trigger, you could manually play around with brightness. max_brigtness has the upper value
<cristian_c> :)
<cristian_c> smb, I'll try to add info about /sys/class in the report
<cristian_c> *more info
<smb> cristian_c, Sure and I understand you expect that led to be red when off (could be only if the radio is off or no transmition)
<smb> and green when transmitting something
<cristian_c> smb, workaround works, but lights are reversed, then there isn't a brightness problem
<cristian_c> with workaround
<smb> The workaround looks like you let the radio trigger the rx led (receive) instead of the tx (transmit)
<cristian_c> <smb> cristian_c, Sure and I understand you expect that led to be red when off (could be only if the radio is off or no transmition)
<cristian_c> smb, exactly, the led should look red when wifi is off, and blue when wifi is on, but situation is inverted -> red light with wifi on and blue with wifi off
<cristian_c> after performing the workaround, obviously
<cristian_c> smb, before performing workaround, led i blinking
<cristian_c> as it was related to network activity and not to wifi status
<cristian_c> *led is
<smb> cristian_c, So I am just guessing from the names of the led files phy0::tx and rx, the intention for those is signalling sending and receiving. I cannot tell whether there is more of them
<smb> Like I said you could examine a bit what they do (colorwise) (its just one physically?) when you disable all triggers and write values into brightness
<cristian_c> smb, there is only a led button
<cristian_c> *wifi
<cristian_c> then, there are the classic leds for laptops
<cristian_c> *little leds (without buttons): power, hard disk, wifi, ...
<cristian_c> smb, I've already tried to change values
<cristian_c> and play with triggers, but I've never found a trick
<cristian_c> It needs only the color reverse
<smb> Ok, so the ath5k driver (or whatever) exports multiple logical leds for the same one (as it seems). Assuming a kind of multicolour led. Activating one end makes it glow red, the other blue. I am not really sure what the phy0radio trigger relates to, and whether there maybe is another phy0... one. A lot of these things only show up with the right modules loaded which gets triggered by the specific hardware found.
<apw> ppisati, hey about ?  this led thing, is there any reason to build that in for anything other than arm* ?
<ppisati> apw: nope AFAIK but i built-in in every arch just for coherence among them
<ppisati> apw: if you prefer an armhf only, i'll do
<apw> ppisati, i think that makes a little more sense yeah, and note i have pushed a start new release
<apw> ppisati, i am happy to apply it manually as well
<ppisati> apw: ok, i'll refresh the patchset
<apw> ack
<cristian_c> smb, I'll control these and I'll add more info in the launchpad bug report
<smb> cristian_c, Thanks
<smb> cking, apw btw, bug 1291930
<ubot2`> Launchpad bug 1291930 in unity (Ubuntu) "Menus do not work while VNC screen of virt-manager is active" [Undecided,New] https://launchpad.net/bugs/1291930
<cking> smb, i've confirmed it too
<cking> rtg, https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues
<infinity> .win 58
<apw> missed
<mjg59> sforshee: I have a pile of patches for switcheroo and gmux that work for me here
<mjg59> sforshee: http://www.codon.org.uk/~mjg59/retina_patches/
<sforshee> mjg59: that url isn't working for me
<mjg59> sforshee: Sorry, http://www.codon.org.uk/~mjg59/tmp/retina_patches/
<slangasek> apw, ogasawara: is there a wiki page I can refer to that explains the support cycle for the HWE stacks?
<ogasawara> slangasek: yep, just a sec
<ogasawara> slangasek: https://wiki.ubuntu.com/Kernel/Support
<ogasawara> slangasek: that's got a few different views
<ogasawara> slangasek: depending on the level of granularity you want
<ogasawara> slangasek: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<ogasawara> slangasek: and that is the horribly verbose version
<slangasek> ogasawara: thanks
<sforshee> mjg59: ah, you're using switcheroo to pass the edid to i915. Good idea.
<sforshee> mjg59: so I no longer have the machine with gmux and lvds that I could test this with. I gave it to mlankhorst, not sure if he still has it.
<sforshee> but he isn't in this channel. I'll check with him.
<infinity> BenC: New SRU round for you.
<infinity> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1291125
<ubot2> Launchpad bug 1291125 in Kernel SRU Workflow "linux-ppc: <version to be filled> -proposed tracker" [Medium,In progress]
<BenC> infinity: ACK
<infinity> zequence: New lowlatency rebases for you for Q and S, nothing for P this time.
#ubuntu-kernel 2014-03-14
<ppisati> yo
<apw> moin, /me reboots to get a lockscreen that actually locks
<apw> man a whole new lock screen a whole new set of bugs
<ogra_> yay
<ogra_> that goes hand in hand with the non-centered new wallpaper ;)
<apw> it shows a lot about the testing rigor that the bugs are so obvious
<ogra_> i dont have any bugs with mine yet 
<cking> it depends on how one defines rigor
<apw> i have tended to have an unfortuanate interpretation of it, one you might recognise cking
<apw> ogra_, try interacting with the top right menu
<ogra_> i did already 
<ogra_> no issues on my XPS13 ... might be a graphics driver issue 
<cking> i like the way one can start up the character map on the user's desktop when they are locked
<cking> and one can shut the machine down too
<ogra_> well, my GF likes that she can mute it now when i'm not around :)
<smb> That seems to be fixed this morning
<cking> ah, progress :-)
<smb> ogra_, Could be that feature is gone
<smb> Or its a new bug
<smb> Who can say
<ogra_> did they disable the indicators ? 
<smb> They look to be there but I could not drop any action menues down
<smb> So solely "indicators" in the literal meaning
<ogra_> well, they work fine for me 
<smb> ogra_, when did you upgrade?
<ogra_> yesterday
<smb> see
<smb> I did this morning
<ogra_> havent been at my laptop today 
<smb> Yesterday they behaved as you say
<smb> Today is another day
<ogra_> oh my
<smb> infinity, Somewhat I feel less and less guilty about any issues I may cause with replacing Xen...
<tjaalton> was the raring kernel git repo removed?
<tjaalton> ah, moved
<smb> tjaalton, No more Raring. Only as a HWE branch in the Precise tree
<tjaalton> smb: so it gets abi bumps there?
<tjaalton> that'd explain it then
<smb> tjaalton, Yes, it only will get updated there as long as the version is supported for LTS HWE
<tjaalton> right
<smb> tjaalton, A pity you only handle the binary-gfx drivers. Otherwise I would have a victim to whine about dual-screen experience in T. But I will have to wait for Sarvatt for that. :)
<tjaalton> I don't touch the blobs, it's tseliot land :)
<smb> Oh bugger, mixed up the people starting with t... :/
<tjaalton> just whine on a bug report against xserver-xorg-video-intel and ickle will whine back :)
<smb> Was about to file that next :)
<tjaalton> but the first thing would be to <drumroll> try 3.14 ;)
<tjaalton> assumed it's an intel issue
<smb> Heh, likely
<smb> At least could make sure its still there. Not exactly sure its driver or handling of it. Looks to be a problem with lightdm trying to be helpful and arrange screens side-by-side breaking 3D support as that gets wider than 2048
<tjaalton> ah
<tjaalton> well that's not really a driver bug then
<tjaalton> maybe lightdm shouldn't enable both output
<tjaalton> s
<tjaalton> on older hw
<smb> Well it could be as it does not start accdelerating even when I change the setup to something sensible
<smb> Yeah, or do mirror mode instead of side-by-side
<tjaalton> right
 * cking not getting any success with qemu-system-ppc and the trusty ppc image. anyone else got it to work lately?
<apw> cking, can't say i have no
<apw> rtg, i have just slammed head to add a buglink to an older commit
<rtg> apw, ack
<rtg> dannf, don't bother with build testing amd64/i386. I've got that figured out. I'd rather see some testing on the Mustang platform.
<dannf> rtg: ok, will do. is the fix already in your branch, or do you think the build fix is irrelevant enough that it doesn't also need testing?
<rtg> dannf, it has been pushed to that branch and was just a packaging fix.
<dannf> ok, cool
<rtg> I'm comfortable that it is righteous
<ppisati> henrix: do you use git intergration with emacs? if yes, wich package do you use? git.el? magit? what else?
<henrix> ppisati: no, not really. i've tried magit but didn't convinced me
<ppisati> henrix: ok
<ppisati> henrix: but then, how do you handle when e.g. you edit a buffer, write it down, git commit using cli
<ppisati> henrix: and when you go back emacs complain about "file changed on disk" etcetc
<henrix> ppisati: hmm... that doesn't happen too often i guess :)  and when it does i just re-read it
<henrix> ppisati: but why would you have your buffer externally modified after a commit?
 * henrix thought ppisati was a vi user btw
<ppisati> henrix: actually i was an emacs user who switched to vi cause it was somewhat faster
<henrix> :)
<rtg> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1292400 looks like your baby
<ubot2> Launchpad bug 1292400 in linux (Ubuntu) "task systemd-udevd:1906 blocked for more than 120 seconds." [Undecided,Confirmed]
<psivaa> bjf: hello
<bjf> psivaa, hi
<psivaa> bjf: the saucy xen (amd64 kernel on 64 bit machine) kernel sru is hung on test_stack_collision (__main__.KernelASLRCollisionsTest)
<psivaa> bjf: and the kernel log is http://paste.ubuntu.com/7091031/ 
<bjf> looking
<psivaa> bjf: this is the first run though.. if you think i should rerun to confirm.. i could do that
<bjf> psivaa, is just the test hung? how long?
<psivaa> bjf: for 5 hrs now
<bjf> psivaa, retry it and it shouldn't take longer than 1 hr. max, i would think
<psivaa> bjf: ack, yea the test just hung.. i dont see any other issues with the machine 
<bjf> psivaa, if it hangs again i'll as sbeattie to look at it
<rtg> apw, I pushed 'Add VID:DID for Lenovo OneLinkDock Gigabit LAN' for bug #1291890
<ubot2> Launchpad bug 1291890 in linux (Ubuntu) "Add Lenovo ThinkPad OneLink GigaLAN USB ID to ax88179 driver" [Undecided,Confirmed] https://launchpad.net/bugs/1291890
<psivaa> bjf: ack, rerunning. thanks
<apw> rtg, ack thanks
<rtg> dannf, any progress to report ?
<apw> rtg, this hyper-v thing looks like an ABBA deadlock in memory hotplug between the balloon driver and udev online
<dannf> rtg: not yet; just de-meeting'd, build starting
<apw> rtg, i guess i'll pass it upstream and see what they say
<rtg> apw, ick!
<dannf> rtg: built fine; but initramfs boot fails. looks like the sata driver is correctly waiting postponing probe until the phy is available, but the phy mod doesn't autoload. retesting w/ just XGENE_PHY=y, XGENE_AHCI=m
<rtg> dannf, ack, sounds right
<dannf> rtg: looks good w/ that caveat, I replied on list. taking off early today, but i'll sync up w/ the thread monday if not sooner.
<rtg> dannf, ok. I'm adding the enet driver patches now. I'll send an update on the list.
<dannf> rtg: cool. just note that enet relies on the qmtm engine
<rtg> dannf, yeah, I was just figuring that out
#ubuntu-kernel 2014-03-16
<melodie> hi, I would like to ask for an information and advice about setting up an custom remix in 64bits : are there specific packages needed if we want to install to a I7 machine with Intel 64bits inside?
<melodie> I ask because I have done this custom Ubuntu inside a machine with AMD Athlon and on a machine (Alienware core i7 intel 64 in vbox it yells about the 64bits arch missing)
<melodie> should I install ia32 packages in the distro, or the kind?
<infinity> melodie: You should install amd64, not i386...
<melodie> infinity is "amd64" the name of a package?
<melodie> because you see, I am the person who is trying to create a custom x86_64 version, and it happens to need something special to work on that system
<melodie> so if you tell me advice, could you try to provide it in a way that it can be indeed used?
<melodie> my custom install works for me, in an amd64bits machine ; it does not work properly in a machine Alienware with i7 64bits : what is missing?
<melodie> thanks
<infinity> melodie: amd64 is the architecture.  As in ubuntu-*-amd64.iso versus ubuntu-*-i386.iso
<infinity> melodie: The first is for 64-bit machines, the second is for 32-bit (but also runs on 64-bit).
<melodie> infinity I think you are mistaking somewhere : I thank you and I am perfectly aware what goes where!
<melodie> infinity please read here:
<melodie> http://linuxvillage.org/en/2014/03/bento-64bits-rc1/
<melodie> and here:
<melodie> http://forum.linuxvillage.org/index.php?topic=645.msg3847#msg3847
<melodie> (please stop thinking I am a moron... )
<miseria> "los derechos humanos, se escribieron para proteger al pueblo y no para incrementar la burguesia y su tirania" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2015-03-10
<witchmaster> Hi there.
<witchmaster> We had some trouble with the tg3 driver in 3.19 last week. Joseph Salisbury has finally fixed it. But when will these changes end up in the package repository? I just want to avoid updating and end up with a non-working system :-)
<apw> witchmaster, if there is a bug filed for this, that would have progress of the commit, if you tell me that i can check too
<witchmaster> It's Bug Bug 1428111. Status is: committed ...
<ubot5> bug 1428111 in linux (Ubuntu Vivid) "Kernel crash on Dell Latitude 5530 (tg3 driver involved)" [High,Fix committed] https://launchpad.net/bugs/1428111
<witchmaster> I haven't seen if there's a new linux-image package on the repository. I think it's still the old, buggy one ...
<apw> witchmaster, is that vivid only?  if so it appears to be applied and pending the upload which is occuring "now"
<witchmaster> yes, only vivid. So, then I will wait and see when the new package arrives. Thanks for the information
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<caribou> apw: remember the openafs dkms fix of last week ?
<apw> caribou, only vaguly
<caribou> apw: no need to be specific : I'm trying to identify the type of testing we do for dkms packages
<caribou> apw: you might recall last week discussion with slangasek during the Foundation meeting
<apw> caribou, i probabally will if you remind me :)  but testing wise we mostly are ensureing they build and load
<caribou> apw: on trusty, openafs failed to build following a dentry change that was backported to 3.18
<caribou> apw: so when latest trusty kernel got installed by update, openafs dkms rebuild failed
<apw> caribou, yes, that is true, and it got fixed i think now yes ?
<apw> caribou, so i assume the question is how to stop that happening again
<caribou> apw: yep. you uploaded the fix for me :)
<apw> ok so this is more about how we can gate things on the dkms results
<apw> and that depends on britney knowing they depend on each other, and the tests failing in the dkms packages
<caribou> apw: yes, I suppose
<apw> caribou, just trying to find the right players
<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 March 17th, 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.
<cyphermox> jsalisbury: hey. I'm looking at bug 1359689 
<ubot5> bug 1359689 in linux (Ubuntu Vivid) "cryptsetup password prompt not shown" [Critical,Triaged] https://launchpad.net/bugs/1359689
<cyphermox> now that we have 3.19; it's still not working, even though things are looking fine on 3.19-rc1
<cyphermox> (I mean, 3.19-rc1 vanilla)
<apw> cyphermox, does it look ok on v3.19.1 vanilla?
<jsalisbury> cyphermox, so it regressed now from 3.19-rc1 to 3.19 final?
<jsalisbury> cyphermox, comment #31 seems to indicate 3.19 final works on an Utopic install.  Does it not for you?
<cyphermox> jsalisbury: I'll try it again, what I'm saying was that for me, it didn't seem to work with our 3.19.0-7-generic
<jsalisbury> cyphermox, can you try the 3.19 vanilla kernel to see if it's related to something Ubuntu specific, and 3.19.1 as apw suggests?
<apw> 3.19.0-8.8 is building and is 3.19.1 based
#ubuntu-kernel 2015-03-11
<calc> has anyone reported yet that the drm-intel-nightly builds are broken?
<calc> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/
<calc> it started back up yesterday but the build.log indicates its not finding the git commit for checkout
<apw> calc (N,BFTL), seem so indeed, will investigate
<Odd_Bloke> I'm running the ubuntu_ecryptfs tests in a pristine VM (using ./runner ubuntu_ecryptfs) and I'm seeing "/bin/bash: make: command not found" for every test it is running.
<Odd_Bloke> Is there an expectation that make/build-essential will already be installed, or is the test missing some setup?
<cking> Odd_Bloke, i believe build-essential is assumed, but I'm not sure what the ./runner is doing or meant to expect for the minimal install config 
<cking> Odd_Bloke, if you want to just run the eCryptfs tests, perhaps the following notes are useful: http://smackerelofopinion.blogspot.co.uk/2012/08/testing-ecryptfs.html 
<Odd_Bloke> cking: I'm working on running the kernel tests on cloud instances, and just chose one at random.  I'll ensure build-essential is installed. :)
<cking> Odd_Bloke, have you also considered hammering it to death with stress-ng? http://kernel.ubuntu.com/~cking/stress-ng/
<Odd_Bloke> cking: I haven't, but I will now. :)
<cking> it can make the vm subsystem cry
<bjf> Odd_Bloke, when running the tests i have a separate step for installing all the dependent pkgs
<Odd_Bloke> bjf: Cool, noted.  I'm working on tooling around the kernel tests; are there any tests that run particularly quickly (so I can have a quick turn-around while testing Jenkins job wrappers etc.)?
<bjf> Odd_Bloke, ubuntu_qrt_kernel_security
<Odd_Bloke> Thanks!
<cmagina> so, the latest utopic-proposed kernel, 31.43 does not contain any of the stability fixes (specifically the arm64 fix), when can i expect those to land?
<cmagina> they all appear to be in the 32.42 tag
<infinity> cmagina: 32.42 and 31.43 will be merged into 32.44 (or similar), and the SRU cycle will continue.  This was a single-commit security update that superseded the SRU.
<cmagina> infinity: i figured as much, just checking on a possible time table, thanks
<mozmck> I would like to build a kernel with the preempt-rt patch and make .debs that would be widely compatible with ubuntu 14.04 systems.  Can I copy the debian and debian.master directories to a mainline kernel that is supported by preempt-rt patches and use that?
<mozmck> Or would it be better to use make-kpkg?
<mozmck> I would like to have the .config be as close to the same as the ubuntu kernel as I can.
<DalekSec> apw: Hello, I'm unsure where to make the proposal, but can you add linux-initramfs-tool as an alt dep in the kernels to "fix" bug 1109029?
<ubot5> bug 1109029 in linux (Ubuntu) "Depend on linux-initramfs-tools" [Wishlist,Triaged] https://launchpad.net/bugs/1109029
<apw> DalekSec, that is likely a viable thing to do, though i'd need to discuss the packaging ramifications before one could commit, which series would that affect??
<apw> mozmck, we copy in the debian and debian.master from a "close" version when we make mainline builds for this
<apw> mozmck, so it hsould be viable
<infinity> apw: It's not a particularly useful thing to do, as nothing in userspace has changed, but that also means it's entirely harmless for you to do. :P
<DalekSec> apw: Devel (vivid) would make the most sense, and FWIW I stripped out initramfs-tools, added dracut which regenerated the initrds, and rebooted.  Kernel worked.
<infinity> (Since any normal Ubuntu system will pretty much be forced to have initramfs-tools, regardless of the kernel's alt dep)
<apw> infinity, yeah i assumed this was to allow playing with dracult rather than a plan for us to change any time soon
<apw> and that its just vivid seems ok for testing then
<DalekSec> infinity: There's not all that much preventing it from functioning, plymouth needs a few things merged from Debian and just some alt deps missing.  I'm going to try in an encrypted LVM soon and see how badly that breaks. :D
<infinity> DalekSec: I'm sure it more or less works, but we won't support it.  That's no reason to actively block people using it, however.
<DalekSec> infinity: Excatly my thought, glad you agree.
<infinity> DalekSec: I will confess, I'll never understand people's obsession with replacing working software with something else, though.  *shrug*
<infinity> And, no, "it integrates with systemd" is not an argument, because a full-featured init in your initrd and pivoting back to your initrd because clean shutdowns are "hard" aren't features.
<apw> infinity, because "someone" tells their s/w is the one and only way
<infinity> apw: Harald hasn't typically had much of an ego about dracut, he and I have had many good talks about the differences between the two.  But it does seem that getting caught up in the systemd vortex has changed how lots of other people see it.
<DalekSec> infinity: It's like playing with systemd before it's in Ubuntu.  Do I plan to play with dracut?  Sure.  Would it be interesting to see what one can do with it?  Sure.  Would I put it on a production system?  Heck no.
<retabell> apw: will you have a look at 1426113, maybe it was the wrong place where i filled a bug
<retabell> ?
<apw> bug #1426113
<ubot5> bug 1426113 in linux (Ubuntu) "devel: vbox drivers introduce symlinks which prevent use of orig.tar.gz" [High,Fix released] https://launchpad.net/bugs/1426113
<apw> retabell, ? that is a bug i filed, and fixed
<retabell> yes, i posted a patch, maybe wrong place..
<retabell> check if symlink exist
<apw> retabell, ok, that fix got applied separatly when it blew up for me later, whats in the repo now should have the same effective form
<infinity> apw: Why does "[ ! foo ] && action" always bug me so much?
<apw> retabell, let me know if not, in general when you find a new issue like that a new bug and mentioning it in the old is good
<apw> infinity, becuase it is totally vile, but its short
<infinity> apw: I know POSIX ignores failure in a pipe like that, so it's fine, but it feels like it's missing the "else".
<infinity> apw: Yeah, I prefer the inverted (and shorter) form: "[ foo ] || action"
<apw> infinity, i should have done it as a loop with a fully formed if in the thing
<apw> then all of us would have been happy ... and i should have made that script read the debian/foo file which has the list in too
<apw> and ... life shouldn't suck and it hsould cope with bloody links
<infinity> apw: I wasn't at all arguing for readability or verbosity, just a serious OCD issue on my part with a pipe that obviously has a false evaluation in it and *should* fail, if POSIX wasn't broken. :P
<retabell> apw ok thx
<apw> retabell, thanks for reporting, if we hadn't noticed (because it was so severe) i would have been more appreciative :)
<retabell> i think this only happens when build the source with quilt
<retabell> rules clean seems to be called twice
<apw> retabell, or if you clean your tree twice and make a tarball indeed
<retabell> yes
<apw> which is how i noticed it, someone here had a proceedure which did so, cleaning, then -S without -nc
#ubuntu-kernel 2015-03-12
<ohsix> infinity: what do you do to unmount a / that you're currently using, just dont? mount it ro and hope it doesn't fail?
<ohsix> the 'reason' things are copied to an initramfs at all is because you need them to prepare /, you also need the same tools to 'unprepare' it; having them somewhere in the / you eventually mount is the same problem that you have an initramfs for in the first place, finding the things to mount /
<ohsix> pivoting back just keeps the entire responsibility for it in the initramfs, it can also unmount things cleanly because it's still not on /
<ohsix> and even disregarding network or weirder filesystems for /, any given local filesystem is going to vary in how cleanly remount -o ro / is going to be at shutdown, so you depend implicitly on the behaviour of any existing and future filesystem behaviour
<ohsix> i like the term vortex rather than some allusion to a force that can't exist, btw
<ohsix> there are a lot of people being introduced to these problems for the first time, and not many of them are choosing to know or care about them
<mozmck> apw: thanks for the information.  so I'm guessing the vivid kernel at the v3.18.7 would be the closest to 3.18.9?
<mozmck> preempt-rt has a patch for 3.18.9 and one for 3.14.34, as well as some older ones, but I would like to use the latest patch.
<taihsiang> henrix, the kernel version looks weird if I enable -proposed to try to run few SRU test
<taihsiang> henrix, for example:
<taihsiang> henrix, 3.13.0-46-generic #79~precise1-Ubuntu SMP Tue Mar 10 20:25:33 UTC 2015
<taihsiang> henrix, 3.13.0-47-generic #78~precise1-Ubuntu SMP Thu Mar 5 15:38:11 UTC 2015
<taihsiang> henrix, 3.13.0-47 is not there anymore, and 3.13.0-46 has newer built stamp
<taihsiang> henrix, this issue block me to perform certification part of SRU
<henrix> taihsiang: correct, that's because 3.13.0-46.79 was a security fix kernel.  we had to respin early this week
<henrix> taihsiang: this should be fix soon, i'm currently working on respinning the kernels again
<henrix> taihsiang: the -47.78 kernel had to be dropped from -proposed and replaced by the security fix kernel
<taihsiang> henrix, ok, that sounds great. one more question: so only precise(lts-trusty-backport) and trusty has such security fix and respinning?  
<henrix> taihsiang: no, *all* the kernels have that fix
<taihsiang> henrix, e.g. how about precise(3.2) and utopic?
<taihsiang> henrix, oops, understood, thanks!
<henrix> taihsiang: np
<taihsiang> henrix, are we going to skip  the certification test of the upcoming security-fixed kernel because the kernel team may want to  release the security-fixed kernel as early as possible?
<taihsiang> henrix, or the kernel team would like to release the security-fix kernel as the original SRU cycle date? (21 Mar) Then the certification team could have time to have certification test.
<henrix> taihsiang: the security kernel has been released already; i believe certification testing will run on the kernels that will be in proposed later this week, for this SRU cycle
<taihsiang> henrix, I see, thanks.
<infinity> zequence: There's a new precise kernel spinning up shortly, FWIW.
<infinity> zequence: You'll have a bug number later tonight, I suspect.
<ricotz> sforshee, hi :), is there an eta for trusty-backport of 3.16.0-33.44?
<henrix> ricotz: the utopic 3.16.0-33.44 is still building, so it will take a while.  i would say that tomorrow it will be in -proposed
<cking> amitk, is a new tag'd version of idlestat coming out soon?
<ricotz> henrix, ok, thanks
<amitk> cking: I've been thinking about tagging this one. I need to run a few more tests to ensure it is stable enough
<amitk> cking: we've already added several new features
<cking> even it it's a 0.5.1 or something, it looks kinda useful with the new features and man page
<cking> *if it's
<amitk> cking: ack, let me do some more testing over the weekend and I'll tag it next week
<cking> that's great, no rush
<smb> infinity, Do you know from the top of your head what apt is doing when it "configures" a package as opposed to "unpacking" it? I am having a peek on fixing the false dkms failures and finding it a tad more complex than initially thought. I would imagine configuring runs a package post-inst. Or is there more? 
<infinity> smb: configure is "postinst configure", yes.
<smb> Ok, so I have to check what magic the headers do there... thanks
<infinity> smb: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
<infinity> smb: See 6.6 for the ordering.
<smb> infinity, cool. ta
<smb> infinity, Hm... one starts to wonder why there is a hook for dkms in kernel/postinst.d at all... The one in header_postinst.d probably should be enough...
<infinity> smb: Probably.  Are you looking into the bug we were talking about the other day?
<smb> infinity, yeah (with other day being last week)
<infinity> smb: I still think the fix I suggested should be made anyway.
<smb> infinity, So I looked today at the term.log of an upgrade that produced false positives. And saw that basically those fails all came from kernel postinst runs
<infinity> smb: But you may be right that the hook doesn't need to live in both places.
<smb> The problem is that the headers are unpacked at that stage, so the checks for existing directories fail to detect anything wrong
<smb> The check we miss by exec is actually done in the dkms script again... so any echo is a duplicate. The only advantage would be that then the exit would be the rc code from the echo... 
<smb> but then the only sucessful run is the one in the headers_postinst... so *shrug*
<infinity> smb: Yeah, perhaps just removing the kernel image one is enough, then.
<smb> infinity, yep, typing a patch as we type..err speak
<smb> infinity, btw, we are past the "magic" time
<infinity> smb: \o/
<infinity> smb: Time to find my decapulator.
<zequence> infinity: Alright, thanks.
<absk007> does the standard kernel support Flash file systems? https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems
<absk007> i want to run lubuntu in microSD card without wearing it out
<absk007> which flash FS is good?
<infinity> zequence: http://launchpad.net/bugs/1431501 is your new bug, FWIW.
<ubot5> Ubuntu bug 1431501 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
#ubuntu-kernel 2015-03-13
<unixist> I'm trying to add an additional x509 key to the system keyring, but in order to do so, the new key must be signed with the old key. How do I do this? You can read https://www.kernel.org/doc/Documentation/module-signing.txt and / for "keyctl padd" to see what I'm trying to do
<unixist_> I d/c'd. Did anybody answer my question about signing and inserting additional public keys into the kernel's system keyring
<free1> hello #ubuntu-kernel
<free1> infinity: can you fire a sniper rifle?
<smb> tseliot, So I filed bug 1431753 as a result of my tests with dkms (in case you have not seen, yet). Turns out the slightly over-eager dkms builds do help to let the nvidia driver get away with bad behaviour. 
<ubot5> bug 1431753 in nvidia-graphics-drivers-340-updates (Ubuntu) "Nvidia binary driver FTBS due to DKMS layer violation" [High,Confirmed] https://launchpad.net/bugs/1431753
<tseliot> smb: I've just had a look at it. bbswitch-dkms is not part of the nvidia sources
<smb> tseliot, Ah ok, minor lapse on my side. It is just always there when I have nvidia driver installed.
<smb> Probably should have guessed since the version number differs
<tseliot> smb: as for UVM, what you suggest might cause some trouble packaging-wise as UVM is only available on amd64 (no armhf or i386), at least in the 346 series
<tseliot> yes, the nvidia packages recommend bbswitch for hybrid graphics
<infinity> tseliot: Why would it only being available on amd64 matter?
<infinity> tseliot: If you package nvidia as a single driver instead of two, the Makefile can surely be smart enough to DTRT for the kernel it's building for.
<infinity> Single dkms package, that is.
<tseliot> infinity: it would add even more complexity to the packages. I don't know if you remember what the packaging is like... ;)
<smb> infinity, I think because you can not declare it only for one arch in the dkms.conf
<infinity> tseliot: It would reduce complexity...
<smb> Still one might just do a dummy thing 
<tseliot> I can definitely look into it but we can probably lower the bug priority
<smb> tseliot, But touching other modules private parts as you do now is as bad :)
<tseliot> smb: I'll get back to you on this. I really need to have a look at the code first though, as I really don't remember how it works
<smb> tseliot, Ok, right now we are lucky to have working installs most of the time as the multiple dkms autoinstall runs get things done eventually (most of the time). You just can expect appart to go on bitching at you
<smb> apport even
<infinity> Hrm, all this needs is for DKMS to export $kernel_arch, and we're set.
<tseliot> smb: ok, I definitely don't need apport to complain any more than it already does ;)
<infinity> Since dkms.conf is a shell script.
<infinity> And it might exist as $arch, despite the manpage not documenting it.
<smb> infinity, What might not be there is something to tell it a module only will be there for $ARCH==x. Right now I think there is only an array of module name and some where to put those
<infinity> So, it might be as simple as doing this:
<infinity> if [ "$arch" = "x86_64" ]
<infinity> BUILT_MODULE_NAME[1]=
<infinity> DEST_MODULE_NAME[1]=
<infinity> ...
<infinity> fi
<infinity> smb: Yeah, if $arch is there, the other bit is easy.
<smb> infinity, Ah I see what you mean
<infinity> You only add to the array if the arch matches, done.
<tseliot> I can try that
<infinity> Make that proper shell syntax (; then), etc.
<infinity> Not sure if $arch is the right thing, mind you.  This source is messy. :P
<tseliot> maybe I won't even need that
<tseliot> but yes, I can see what's wrong in the sources now
<tseliot> I'm not sure I wrote that code though
<tseliot> smb: that seems to be an upstream (i.e. NVIDIA) choice. I should probably talk to them before making any changes
<smb> tseliot, hm ok. Likely behaves as bad for everyone but just we happen to trigger apport if dkms fails. :/
<tseliot> smb: right
<infinity> tseliot: Upstreams aren't always right, and this is clearly wrong.
<infinity> tseliot: If the dkms packaging comes from them, by all means, tell them they're wrong, but don't do something just because they say so either.
<tseliot> infinity: I know. Since we use (more or less) the same packaging scripts, I think it makes sense for me to ask them first. I'm not asking permission. It's about collaboration.
<rbasak> ppisati: we're looking for an equivalent of rdtsc on armhf for porting issues
<rbasak> ppisati: found http://blog.regehr.org/archives/794, but that needs enablement of access to the CPU's cycle counter from kernel space
<rbasak> ppisati: do you know why we don't do this by default anyway, given that INtel permits it? Is there any particular reason, or could we get upstream to enable this by default universally?
<rbasak> jamespage, ogra_, smb: incidentally the cross-distro list might be a good place to ask, if nobody knows here.
<ogra_> yeah "
<rbasak> Many ARM people there, and the patch would only be useful to ceph upstreams if all the distros do the same thing here.
<rbasak> IIRC there's also a Launchpad project to track arm porting issues.
<smb> Yeah, there might be a reason but I don't know ...
<ppisati> rbasak: why don't you use the perf infrastructrue for that?
<ppisati> rbasak: i mean
<rbasak> ppisati: doesn't that involve a system call?
<rbasak> In that case we could just use clock_gettime(2)
<rbasak> jamespage did find http://neocontra.blogspot.co.uk/2013/05/user-mode-performance-counters-for.html which talks about how to use perf
<rbasak> But if that was suitable the original code would be using that instead of rdtsc
<rbasak> I presume the system call overhead is too high
<ppisati> ah
<ppisati> but did you read the comment about that piece of code?
<ppisati> "Setting the V bit also allows userspace to access the System Validation Operations Register. Among other amusing effects this allows any userspace process to schedule a hard reset of the CPU in N cycles time."
<rbasak> Oh
<rbasak> So that'll be the reason then.
<rbasak> Thanks!
<rbasak> jamespage: ^^ so that'll be the reason it's not enabled by deafult then :)
<ppisati> rbasak: dude, but i would be interested to hear some more comments on this
<ppisati> rbasak: so, if you wanna send a msg to the cross distro ml or linux-arm, i'm all for it
<ppisati> rbasak: i think anything an rdtsc that doesn't involve a syscall might be useful for many people
<ppisati> just my 2 cents
<rbasak> ppisati: yeah, but not at the cost of allowing userspaces process to hard reset
<ppisati> rbasak: of course, but there might be another way
<ppisati> rbasak: anyhow yes, that thing doesn't sound good :)
<pkern> Hey. Would it be possible to push https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1314653 for trusty as well, for compatibility with the utopic lts backport? Having the governor set to performance makes for a bad experience on laptops with the new kernel.
<ubot5> Ubuntu bug 1314653 in sysvinit (Ubuntu Trusty) "sysvinit: default cpufreq governor to powersave for intel-pstate driver" [High,Confirmed]
<ogra_> pkern, the governor is always forced to ondemand 
<smb> Problem seems to be that ondemand is not available with intel_pstate
<ogra_> unless pitti broke that with the switch to systemd (it is still a sysvinit job, not sure he ported that)
<ogra_> oh
<smb> It does not sound unreasonable... not sure why we initially said no...
<smb> I try to remember to ask Colin on Monday ... maybe he remembers
<ogra_> is that code even still used with systemd ? 
<smb> ogra_, it is in Trusty :)
<ogra_> ah
<pkern> ondemand is gone with intel-pstate on trusty with the utopic kernel.
<pkern> smb: Yeah, it was a bit sad not to see a rationale.
<pkern> I guess because it wasn't urgent at the time with the trusty kernel, only with 3.16+ it's now relevant.
<smb> pkern, Agreed. And since the additional powersave is lower prio in the case statement it should not harm the other cases
<pkern> smb: ACK.
<pkern> smb: That might sound weird, but mind to take the issue in the meantime or assign it? ;-)
<smb> pkern, Totally weird. Why would I want to do that. :-P Yeah, done
<pkern> smb: Thanks!
<zequence> infinity: currently building
<infinity> zequence: I saw, thanks. :)
<free1> Do you retain logs?
<Pwnna> does anyone know how the configs from the mainline builds are generated?
<apw> Pwnna, yes, i do
<Pwnna> apw: we left off of the CONFIG_MEMCG discussion. i had to go sleep
<Pwnna> specifically http://pastebin.ubuntu.com/10582239/
<unixist> I'm trying to add an additional x509 key to the system keyring, but in order to do so, the new key must be signed with the old key. How do I do this? You can read https://www.kernel.org/doc/Documentation/module-signing.txt and / for "keyctl padd" to see what I'm trying to do
<mozmck> What is different between the vivid kernel and the trusty lts-backport-vivid kernel?
<infinity> mozmck: Very little, except for the repository it's published in and the name of the metapackages.
<infinity> unixist: You can't, not without rebuilding the kernel.  The key we use to sign modules is generated and thrown away during the build.
<apw> unixist, yep, waht infinity said, the key never persists, it is gone
<mozmck> infinity: thanks.  Now how do I find the closest release to 3.18.9 in the repository?  I see commits like "Ubuntu-lts-3.18.0-14.15~14.04.1", but the makefile at that point says 3.19.x
<infinity> mozmck: That's a question for apw, though it seems odd that a 3.18 tag would be 3.19
<free1> mislabeled?
<apw> mozmck, ok they moved the MEMCG things into a new section RESOURCE_COUNTERS which defaults off ... so we default it off
<unixist> apw: hm?
<apw> mozmck, and that makes the others go away
<apw> the "things which are new" logic is very simplistic in the test build generator
<free1> apw: Who is "they" that moved the memcg?
<apw> upstream
<apw> they moved that option and a few others under a new menu option, and that new option defaults off
<apw> and so they get lost
<apw> because the config doesn't come with a schema migration plan, like it needs
<free1> apw: any identity for "upstream"?
<infinity> free1: Not everything is a conspiracy theory.
<infinity> Shockingly.
<Pwnna> hm
<infinity> unixist: Maybe you missed my response that apw was referring to...
<infinity> unixist: You can't, not without rebuilding the kernel.  The key we use to sign modules is generated and thrown away during the build.
<apw> mozmck, in theory this list http://people.canonical.com/~kernel/info/kernel-version-map.html has the upstream to ubuntu mapping
<apw> mozmck, and if i checkout that tag, i get:\VERSION = 3
<apw> PATCHLEVEL = 18
<apw> SUBLEVEL = 7
<apw> a 3.18.7 based kernel ?
<tseliot> smb: I've just spoken with upstream, and I'm ready to make the required changes. Just FYI
<free1> infinity: Is it possible there is no crime involved? Then it is not a conspiracy.
<unixist> infinity: My question happens to pertain to custom-built kernels. If the key were maintained, then how would sign and add subsequent keys?
<apw> unixist, in the packaging we manually re-sign our own packages so you should be able to do the same if you keep the key
<infinity> unixist: So, for custom-built kernels, you just want to use a real key for the master signing key, not a throwaway.  And then use that to sign subsequent keys.
<apw> i doubt we let you do that, but hey :)
<unixist> infinity: apw: Gotcha. My question is how exactly to do that. I tried using something like: scripts/sign-file sha512 old.key old.x509 new.x509
<unixist> to no avail
<mozmck> thanks for the info.  I see that tag, but I was also seeing the other commits which I don't understand.  Anyhow, I'll try the 3.18.7 tag.
<infinity> apw: By "we", you mean the Ubuntu packaging?  Almost certainly not.
<apw> infinity, indeed that
<infinity> Might be friendly to allow one to plug in path-to-key in debian/rules or some such.
<infinity> And use it if it's set.
<apw> mozmck, well to be honest you might as well just resign everything with your own key and not have a magrathea key at all
<free1> I only ask if there is an identity.
<free1> Why sign kernel "downstream" for identity or just for nothing?
<apw> infinity, and yes we should
<infinity> unixist: ^ :P
<mozmck> apw: I think you are talking to unixist about that?
<infinity> mozmck: He was.  He's old, he forgets.
<apw> i might be, i think i should just put both your names on everything and let you filter, cause i am not getting them right at all
<mozmck> haha!  me too and I'm not that old.  tab completion messes me up sometimes.
<apw> infinity, old enough to forget your birthday i am sure
<free1> Of course if there were only 1 committing the crime it is neither conspiracy. That is called meditation.
<infinity> free1: Do you honestly believe any of this is a useful contribution to the conversations taking place?
<unixist> apw: This is for key rotation. If the signing key is compromised, I'm screwed until I rebuild and deploy to the entire fleet. That takes lots of time
<unixist> I read somewhere in the key retention service's documentation about revocation. I plan to read more about that since part of what I want to do is predicated on being able to revoke the initial signing key
<free1> Yes. Why do you want to identify anything?
<infinity> unixist: So, the kernel always has at least one key baked in.  That's the only way it can validate subsequent keys.
<infinity> unixist: If you lose that one, you pretty much have to shut down the world and roll out new kernels.  So, uhm, don't do that.
<apw> infinity, it has one ca chain built in ... right, so it could have the master master key in it, and veryify the chains from there
<apw> i think
<infinity> Right.
<apw> and use "this months" kernel siging key
<apw> signed with that, or something
<infinity> But that top master either needs to be ephemeral or super secret.
<unixist> infinity: gah I see. the problem would then be a race to revoke-and-replace-original-key
<apw> but ... given your h/w and your bootloader are about as secure as a wet paper bag, this is mostly moot
<free1> IBM was the first to sell identity systems to nazi germany. So the story goes.
<free1> Crackheads break into your house.
<free1> Identify them?
<infinity> And if it's ephemeral, you could use it to sign a subsequent rotating module key at build time before you throw it away, and roll out revocations of THAT key.
<apw> a master master key shouldn't exist in one part "ever"
<free1> Everywhere.
<apw> so it cannot be stolen
<free1> No need to key anything.
<free1> Just look out the window.
<free1> Sodomites everywhere.
 * unixist ignores free1 ;)
 * unixist ignore free1
<infinity> apw: Sure a proper CA master in fragments that produces chained authorities that sign kernels works fine.  But you still can't revoke the key embedded in the kernel without also disabling signed module loading.
<apw> infinity, well you can't reall revoke it either because well it doesn't have any way to get the revokation into the kernek
<unixist> infinity: you could insert-new-and-revoke-old in a single operation
<apw> module signing is almost as badly designed as secure boot
<infinity> unixist: Honestly, I'd just go lockdown in a suspected compromise situation.  "echo 1 > /proc/sys/kernel/modules_disabled" and call it done.
<infinity> apw: Exactly.
<apw> infinity, and you should be there after boot on all your critical boxes, and living on the moon in a steel cage
<infinity> apw: I *am* living on the moon in a steel cage, are you not?
<apw> infinity, you arn't in my cage, i hope
 * infinity elbows apw.
<apw> infinity, but if you are in that cage you forgot to disconnect those insecure network thingies
<infinity> unixist: In theory, that would be lovely.  In practice, I don't think that's possible.
<unixist> infinity: bleh that's hawrd. rebooting all boxen after such a case is infeasible. Admittedly what I'm looking for is to walk the thin line between productivity and security. Therein lie the difficult and fun problems
<infinity> unixist: And as long as the attackers can trigger a reboot, you've lost anyway, because baked in is baked in.  Any modifications you do to the in-memory keyring at run time are, well, in memory.
<unixist> infinity: true. I guess I'd have to treat reboot as a "reprovision" during lockdown
<infinity> (And it's usually much easier to trigger a reboot than to gain enough privs to insert a module)
<unixist> and that pre-supposes that I always know when I'm compromised
<unixist> infinity: ya totally
<infinity> I haven't really looked into what improvements have gone into signed modules since the Plumbers two years ago when we had a nice long BoF about how much it sucked, but it really feels like it was just implemented as a bullet point feature with not much attention to actual security.
<infinity> Sadly.
<infinity> But with good key management practices, you can make it still be useful.
<infinity> The pain point is that your signing key can't be fragmented, because you need to sign all your kernels with it, so a bit of a catch-22 on the "good key management" front.
<infinity> Erm, well, maybe not.  I guess you could have a CA key fragmented, dump the public key in the keyring, sign an ephemeral key with that, and use it for all your module signing, and push revocations to live machines.  But then you lose all your modules, even the ones you kinda like.
<infinity> So, you'd need to build everything in that you actually need at runtime.
<infinity> At which point, why are  you allowing module loading at all?
<unixist> infinity: lose all the modules? they'd just have to be re-signed, right?
<unixist> I mean, not fun, but not lost
<infinity> unixist: Sure, you'd have to re-sign them all and push the new ones along with your revocation.  That's starting to look like almost as much work as just rebuilding a kernel and pushing it, though.
<unixist> infinity: what I want to avoid is a reboot
<unixist> infinity: that means cold rolling cache, minutes of downtime for each host, very slow across many hosts, etc.
<infinity> unixist: Fair.  I suspect you're optimising for a weird attack vector, though.  But no criticism here for wanting to cover your bases.
<infinity> unixist: So, yes, a "key of the month club", signed by your fragmented CA that you assemble only to sign those monthly keys would do the trick.
<infinity> Modules get signed by key-of-the-month on the build machine, cert chain is put in the keyring, and  you can revoke the subordinate key.
<infinity> Assuming the kernel keyring actually supports revocation. :P
<infinity> Which I'd like to think it should.
<unixist> infinity: word
<infinity> That said, if I can access your build machine to get your subordinate key, I can also poison your builds.
<infinity> So you'd have to make sure you have backups and signed hashes and the like, or you're re-signing trojans and pushing them out.
<unixist> There'd have to be something like signed version control and two-factor auth'd build kickoffs
<unixist> sounds like amazing pain^H^H^Hlan
<infinity> unixist: Yes.  I've been considering a nice career in the field of NOTHING TO DO WITH COMPUTERS for a while now.
<unixist> infinity: :)
<mjg59> infinity: Or just go with an HSM rather than fragmented keys
<free1> jsalisbury: when did you become op?
<jsalisbury> free1, a few years ago
<free1> jsalisbury: and how do you identify freenode?
<jsalisbury> free1, I'm not sure I understand the question
<free1> when is the last time a cop jumped in front of a bullet for you?
<free1> jsalisbury: do you just sign on and assume that it is the same freenode you signed on to the last session?
<free1> do the cops pro-kick you?
<free1> jsalisbury: answer the question
<infinity> free1: None of those is on topic for #ubuntu-kernel.  At all.
<free1> What about at one?
 * hggdh waits for the hammer
<free11> jsalisbury: still connected?
#ubuntu-kernel 2015-03-15
<bcowan> on kernel 3.19 i915 segvs on my macbook...patched in 4.0rc2 but at much degraded performance
<bcowan> also kernels >3.16 have several patches to sbs(smart battery) for apple that add regressions to older macbooks because of some assumptions by author
<bcowan> who should i file bugs with
<bcowan> the sbs causes a race condition which runs cpu load over 100%
<bcowan> both are present for 15.04
#ubuntu-kernel 2016-03-14
<apw> stgraber, more lxc test regression fun for you: LP: #1556931
<ubot5> Launchpad bug 1556931 in lxc (Ubuntu) "lxc: adt testing failing across the board on ppc64el" [Undecided,New] https://launchpad.net/bugs/1556931
<dsmythies> on my 16.04 test server, and as of maybe a day or two now, I can not compile "perf" (tools/perf). At the   "LINK     perf" step there is an error: "/usr/bin/ld: cannot find -liberty".  I haven't been able to figure out what package or whatever is missing. I successfully compiled perf just 48 hours ago, on March12th, but have done updates and some cleanup in between. Any ideas?
<apw> dsmythies, sounds like a lack of build-deps ? libiberty-dev or something ?
 * dsmythies goes off to check stuff...
<dsmythies> apw: Yes, I agree, but I haven't been able to figure out what exactly is missing. By the way, compiling the kernel (mainline) is working fine. 
<apw> dsmythies, well -liberty is "give me library iberty, which is libiberty.so et al
<apw> have you checked libiberty-dev was installed ?
<dsmythies> apw: It wasn't. And with it, now compiles fine. Thanks. Still do not understand: There is no "/usr/lib/x86_64-linux-gnu/liberty.so"; Why it worked 2 days ago, but not now. Anyway, thanks very much.
<apw> libiberty.so
<dsmythies> apw: yes, but I didn't know to look for that, my only clue was "/usr/bin/ld: cannot find -liberty" which I thought meant liberty.so. Anyway it was autoremove that didn't realize I needed it and removed the package: "2016-03-13 13:02:21 remove libiberty-dev:amd64 20160215-1 <none>". Conclusion: My mistake (like that is a surprise to anyone reading this).
<apw> dsmythies, well your build-deps are defined in debian/control in the package, so you should be building in a chroot with all those deps installed to match what the code is expecting
<dsmythies> apw: I never build that way. I only build mainline and only use, for example, "time make -j9 olddefconfig bindeb-pkg LOCALVERSION=-test"
<apw> dsmythies, right, so then you get to work out your build-deps using the "extreme pain and guesswork" way
<apw> as you are finding, though if it was me, i would install the build-deps for the ubuntu kernel into a chroot, and build my mainline ones in that chroot
<dsmythies> apw: I have never had much success with that method. I also seem to get better error reporting with the way I do it (which is similar to: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild ) or so I think (it has been years since I did your method).
<stgraber> apw: fine to ignore, we don't have ppc64el images on images.linuxcontainers.org right now
<apw> stgraber, ack thanks, i'll hint those
<jdstrand> jsalisbury: hey, you gave me a new kernel for bug #1547619, but I'm not 100% sure 4.3.0-040300-generic (#201603101009) doesn't have the bug
<ubot5> bug 1547619 in linux (Ubuntu Xenial) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Medium,In progress] https://launchpad.net/bugs/1547619
<jdstrand> jsalisbury: my comments today were saying that the I needed an ubuntu kernel for overlayfs, so tried the latest xenial when doing that and it had the bug. I am back to testing 4.3.0-040300-generic (#201603101009) now
<jdstrand> I suspect it doesn't have the bug, but I'm not sure yet
<jsalisbury> jdstrand, ack
<jsalisbury> jdstrand, I'll remove that kernel and reset the bisect
<cristian_c> jsalisbury: hi
<jsalisbury> cristian_c, hello
<cristian_c> jsalisbury: I'd like to know if upstream has received the patch
<cristian_c> *wether
<jsalisbury> cristian_c, not yet, I'll send it today
<cristian_c> ok
<jdstrand> jsalisbury: sorry for the confusion
<jsalisbury> jdstrand, np 
<melodie> hi
<melodie> to install the 4.4 kernel on a Kubuntu Wily, is that the right place to get the packages and the only one? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-wily/
<apw> those are only debug kernels, they have no ubuntu sauce
<melodie> hi apw
<melodie> "ubuntu sauce" ?
<melodie> which packages do I need and where should I get them from?
<melodie> http://linuxdaddy.com/blog/install-kernel-4-4-on-ubuntu/
<apw> there are no official packages for wily of 4.4
<melodie> what this gui said: would that be ok?
 * apw bets that is the guy who tells you to wget foo | sudo bash
<melodie> kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.4-wily/  ?
<apw> that well known security plan
<apw> those are debug kernels, with no ubuntu additional patches, no stable updates, no bug fixes etc
<apw> no updates
<melodie> I need 4.4.x kernel and headers for someone who buys a machine with the latest Intel Skylake CPU
<melodie> he will be aware that it will be a temporary solution 
<melodie> already aware...
<melodie> and will need to upgrade to Xenial later
<melodie> he will also be aware how to unlock the kernel thing and make it the "linux-image" and "linux-image-generic" rules in his package manager
<apw> why not just upgrade him to xenial anyhow
<apw> anyhow iirc skylake is not stabled with 4.4
<melodie> last time I wanted to install Kubuntu Xenial in virtualbox the installer just didn't work there (in Mate, it did though)
<apw> i seem to recall we have like a 100 commits on top of 4.4 in xenial just for skylake and broadwell
<melodie> ok, so do we stick with the kernel that's in Wily by default?
<apw> if it was me i'd upgrade to xenial, warts and all
<apw> i mean i run it on all my kit, and its been pretty good
<melodie> I can't afford to take the risk
<apw> which risk
<melodie> Kubuntu?
<apw> runnign a kernel with no security is a hell of a risk
<melodie> I'm one hour and half far from this man's office 
<melodie> and he is just a user
<apw> i can probabally find 3-4 root exploits in 4.4
<apw> just by reading the changelog
<sbeattie> did the 4.4.0-12.28 tag not get pushed to the xenial git tree?
<melodie> I believe you, just if he can use the actual kernel that's in Wily, I'm ok with that
<melodie> I run Xenial in my own machine (upgraded from former installs) and I have 4.4.0-12-generic #28-Ubuntu
<melodie> sbeattie is that the one version you are talking about?
<apw> sbeattie, i have it in my tree, have you git fetch --tags origin that repo
<apw> sbeattie, as we are rebasing some in some cases you can miss tags if we wen from 11 -> 13 before you fetch
<apw> (without --tags)
<sbeattie> apw: ah, it's there, just not on master 
<apw> right, a little rebase in there somewhere
<melodie> I'll be doing the install next thursday. Can I have a 4.3 or a 4.4 that's ok for an end user who has high demands? :) (and has been using Ubuntu boxes only since several years!)
<apw> if he has skylake i think he is out of luck for reliablity before xenial, or lts-xenial
<sbeattie> melodie: sorry, my question was unrelated to yours, was trying to figure out which commits are in that kernel, and which are in the next one.
<apw> sbeattie, yep
<melodie> apw the store where they put the computer together tried Kubuntu Wily on it and they said as live it booted fine
<melodie> sbeattie yes sure
<apw> melodie, then he shouldn't need 4.4
<melodie> sbeattie now the users out there, at "askubuntu" and such all seem to agree to use the 4.3 or 4.4 in Wily, while Xenial is being worked on to reach the final
<apw> xenial is pretty much stablised now, we're not making huge changes any more, we are past FF and on the home straight
<apw> xenial seems pretty stable in the main to me
<melodie> apw boot is one thing, then he does image processing with very high resolution (and the machine besides Skylake has a good asus mobo, 8 GB Ram)
<melodie> what is FF ?
<melodie> is it a beta now?
<apw> feature freeze, change gets much harder to apply now that is past
<melodie> ok let me grab one :)
<apw> we've produced some betas yeah
<melodie> apw from my former experiences, LTS used to be stable after the first version of the new edition, for Xenial it would be 16.04.1 ^^
<sbeattie> melodie: if kubuntu is needed, I'm unsure what the state of kubuntu/xenial is. you might ask sgclark in #kubuntu-devel, as she's been doing a lot of the packaging work for kubuntu.
<melodie> ok, I'll head there right now, thanks for the info
<melodie> I'll grab one anyway to give it a whirl
<melodie> my iso is feb 8th. can someone remind me what is the zsync command line to update the ISO?
<melodie> this is the link to the actual iso: http://cdimage.ubuntu.com/kubuntu/daily-live/current/xenial-desktop-amd64.iso
<apw> zsync -o <file> <url.zsync>
<melodie> apw thks!
<melodie> starting! nice! :D
<dsmythies> melodie: There are always example commands ( I use rsync and can never remember) on the daily testing page at : http://iso.qa.ubuntu.com/qatracker/milestones/351/builds/114631/downloads which in turn I got to from http://iso.qa.ubuntu.com/qatracker/milestones/351/builds
<stgraber> apw: hey, so looks like powerpc (not 64el) isn't booting with current 4.4 from xenial
<stgraber> apw: smoser may have some more details for you, all I know is that I dist-upgraded my ppc VM and it stopped booting, smoser had to reboot me into 3.19 manually
<apw> stgraber, which versoin number is that ?
<melodie> dsmythies thanks but that would be even worse for me to remember, just now I realised what the structure of the command line is, and as for the -o option, I guess a "zsync --help" will remind it to me next time
<stgraber> ii  linux-image-4.4.0-12-powerpc64-smp    4.4.0-12.28                     powerpc      Linux kernel image for version 4.4.0 on 64-bit PowerPC SMP
<apw> stgraber, and do you have one which did boot before that, in 4.4 ?
<smoser> 3.19 booted
<apw> stgraber, i think we need a bug and i'll get jsalisbury to get this bisected
<apw> i just realised we don't run adt on power, sigh
<stgraber> apw: nope, I upgraded from trusty to xenial so it's the first 4.4 I try
<smoser> qemu cmdline that results in "cant find root" looks like this
<smoser> qemu-system-ppc64 -name rockne-01 -echr 0x05 -enable-kvm -M pseries -cpu host -smp cores=2,threads=1 -m 8G -net nic,macaddr=52:54:00:00:42:01 -net tap,script=no,downscript=no,ifname=tap4201 -device spapr-vscsi -drive file=/var/lib/libvirt/images/shared/rockne-01/disk1.img -drive file=/var/lib/libvirt/images/shared/rockne-01/eph0.img -drive file=/var/lib/libvirt/images/shared/rockne-01/save.img -nographic -vga none
<jsalisbury> apw, I'll watch for the bug to come in
<smoser> where disk1.img has the root filesystem on it.
<stgraber> apw: the issue is storage related, smoser got dropped into a shell with no block listed in /proc/partitions
<smoser> only ram disks.
<apw> stgraber, we may have lost a storage driver from the initrd, this is all new initramfs-tool
<apw> s
<apw> jsalisbury, this might also not be the kernel, this might be initrafs-tools
<jsalisbury> apw, ack
<apw> i wonder if its possible to downgrade initramfs-tools on there to wily and see if that boots
<apw> stgraber, ^
<apw> to eliminate that
<stgraber> there doesn't appear to be any storage related module loaded on the 3.19, so I'm assuming it was all built-in then
<stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557130
<ubot5> Launchpad bug 1557130 in linux (Ubuntu) "Current 4.4 kernel won't boot on powerpc" [Critical,Triaged]
<apw> ok so going back won't help
<stgraber> pseries_rng             3547  0
<stgraber> rtc_generic             2711  0
<stgraber> autofs4                53194  2
<stgraber> ibmveth                29947  0
<apw> stgraber, does that have a dmesg, i might be able to tell from that
<stgraber> that's all I've got loaded on 3.19, none of them sound storage related
<stgraber> apw: it doesn't as I don't have access to that, smoser may be able to get it if I reboot back into the busted kernel
<apw> stgraber, a dmesg from the good kernel is what i want
<stgraber> ah
<apw> so i can see waht driver has the device
<stgraber> that I can give you
<stgraber> apw: http://paste.ubuntu.com/15386280/
<smoser> well, 
<smoser>  http://bazaar.launchpad.net/~smoser/+junk/powerkvm-install/view/head:/README
<smoser> i did:
<smoser>  http://cdimage.ubuntu.com/ubuntu-server/daily/current/xenial-server-powerpc.iso
<infinity> apw: The first port of call here would be diffing configs from ppc64-smp and generic/ppc64el, since they're meant to be identical minus endian flip and some Mac drivers.
<smoser>  ./ubuntu-boot-iso ./ubuntu-14.04.3-server-powerpc.iso sda.img --stuff-preseed=ubuntu.preseed
<apw> infinity, and indeed as far as i know they are
<smoser> which works to isntall trusty
<smoser> and that fails loading usb drivers with xenial iso
<infinity> apw: Lemme tear apart the debs and look.
<stgraber> apw: so ibmvscsi it looks like
<apw> infinity, i'll look see if this dmesg tells me the driver name
<smoser> running ^ shows:
<smoser>  Error while running 'modprobe -v usb-storage'
<stgraber> oh, could it be as simple as me missing the -extra package?
<apw> smoser, well its now a module
<apw> if you have no extras, you are likely in a hole
<stgraber> I just did a package diff between the ppc64el and powerpc box and they don't have the same set of kernel packages installed...
<apw> as you have no hardware drivers
<infinity> stgraber: There is no extra for ppc64-smp
<infinity> It's not split.
<stgraber> infinity: ah
<apw> oh, heh, except that
 * apw checks this is in the initrd, might not be
<apw> and it was builtin in W so you'd be fine
<infinity> It would also be a bug if the virt drivers were in extra, of course. ;)
<apw> heh yeah
<smoser> well, it seems to me that powerpc at least under qemu and '-device spapr-vscsi' -cdrom needs some love)
<apw> but a _differnet_ one
<apw> ok this is most likelyu an initramfs-tools issue
<smoser> after a while, it fails saying:  Detect and mount CD-ROM ... could not be mounted
<stgraber> root@1ss-powerpc:~# lsinitramfs /boot/initrd.img-4.4.0-12-powerpc64-smp | grep ibmvscsi
<stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi
<apw> as this moved =y -> =m
<stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi/ibmvfc.ko
<stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi/ibmvscsi.ko
<stgraber> so the module is in the initrd apparently
<apw> oh hrm
<apw> that is less expected
<smoser> and yeah, no disk device there either
<smoser> so seems iso shows same failure that stgraber is hitting.
<apw> smoser, if you boot that to the initramfs prompt, does ibmvscsi appear in lsmod, and if not does modprobe ibmvscsi make the disks appear
<apw> maybe we have a missing device alias
<smoser> i just killed it. but i tried modprobing it and not there. 
<smoser> i can get it back to the iso failure quick enough
<apw> ack
<smoser> apw, exactly zero modules loaded in the initramfs
<smoser> er... in the installer environment
<apw> and if you attempt to load them by hand ?
<smoser> ~ # modprobe ibmvscsi
<smoser> modprobe: ERROR: could not insert 'ibmvscsi': Unknown symbol in module, or unknown parameter (see dmesg)
<apw> wtf
<smoser> dmesg | tail -n 4
<smoser> [   12.006176] ibmvscsi: Unknown symbol mcount (err 0)
<smoser> [   12.016503] ibmvscsi: Unknown symbol mcount (err 0)
<smoser> [   13.070630] usb_storage: Unknown symbol mcount (err 0)
<smoser> [  125.209403] ibmvscsi: Unknown symbol mcount (err 0)
<smoser> so it did try to load it.
<stgraber> so missing dependency it looks like
<apw> i thought the kernel rewrite the mcount bits 
<smoser> also 
<smoser> [    0.839630] ibmvscsi: module verification failed: signature and/or required key missing - tainting kernel
<apw> ?
<infinity> Oh!
<infinity> That's a bug I knew about already but hadn't had time to look at.
<infinity> Silly me for not having 48 hour days.
<apw> infinity, happenign in all ppc kernels, or just this one
<apw> smoser, can you get an entire dmesg off there somehow ?
<infinity> apw: Hard to say, this is the one most people exercise.
<smoser> http://paste.ubuntu.com/15386345/
<infinity> apw: But for weird reasons, only happening on big-endian.
<infinity> apw: Maybe due to the CPU support being different between powerpc and ppc64el, leading to different optimised routines and submodules.  Hadn't had a chance to look.
<smoser> you want anything else there?
<apw> i am sure mcount is -g stuff, and i have this feeling the kernel uses that and rewrites it for ftrace, or something vile
<apw> so i am not expecting to see mcount in there
<infinity> apw: I'll get a VM booted into that kernel with some violence so we can examine it a bit better.
<apw> infinity, oh not it is called mcount, we do use that we just supply an mcount which does ftrace and not counting
<apw> so perhaps ftrace is busted on there
<smoser> you can probably boot it in qemu-system-ppc64 on intel
<smoser> in lightning fast speed. https://gist.github.com/smoser/7a07d9f8929dc11b4ed9
<smoser> oh well, attempt at that failed
<infinity> apw: Huh.
<apw> infinity, i might have found it
<infinity> apw: So, I happened to have a very old xenial ISO.
<apw> infinity, go ahead
<infinity> apw: And this broke between 4.2.0-16.19 and 4.2.0-17.21
<infinity> Which is curious.
<infinity> Since nothing changed there...
<infinity> Maybe that's a red herring, and it's actually how the initrd was built that broke.
<apw> there is a fix after 4.4, which could account for this 
<infinity> apw: Yeah, but that doesn't account for why wily.iso works and xenial.iso with almost the same kernel doesn't. :P
<apw> oh no we have it in via stable
<apw> yes, it would if the compiler changes, what gcc are we using in x
<infinity> It must be a userspace thing...
<infinity> Not a compiler issue.
<infinity> This kernel was built in wily.
<infinity> With the same toolchain as the working one.
<infinity> https://launchpad.net/ubuntu/+source/linux/4.2.0-17.21
<infinity> That's the delta between working and not.
<infinity> So I don't think it's the kernel's fault.
<apw> infinity, ok ... not that then
<infinity> I need to tear apart these initrds.
<melodie> hi infinity o/
<apw> infinity, kmod ?
<apw> no you say in wily, hrm
<infinity> apw: The kernels were both built in wily.  The userspace for the second is xenial.
<infinity> apw: Which is, I'm sure, the key.
<apw> well what else does one use other than kmod to load a kernel
<apw> module, and fial in this case
<apw> i guess any depedency libraries
<infinity> 20151021 -> 20151203
<infinity> That's our date range for breakage.
<infinity> Based on the two ISOs I have here.
<apw> infinity, and kmod is almost the same
<apw> last year, so before kmod
<apw> but, we use very little in userspace in initramfs
<infinity> apw: No difference in file lists in the two initrds.
<apw> phththt
<apw> infinity, and you have the same mcount oddness
<apw> infinity, and this regression is in the wild on wily, argle
<infinity> apw: I don't think it is.
<infinity> apw: I think it requires xenial userspace to be fucked.
<apw> oh i see, but
<infinity> apw: But I could install wily and upgrade to be sure.
<apw> i don't thnk that isnecessar
<apw> y
<apw> as we are clear the same kernel is broke with xenial
<apw> so what is in the initrd that is not busy box
<apw> to load a module we just map it and offer it to the kernel
<infinity> Hahaha.
<infinity> I thought I was going to be clever by using virtio to work around the issue so I could get installed.
<infinity> [   16.884617] isofs: Unknown symbol mcount (err 0)
<infinity> So, no ISO for me.
<infinity> Time for netboot.
<apw> infinity, can you install any modules at all, or are tey all broken
<infinity> apw: Some work.
<infinity> apw: Switching to virtio for both nic and scsi is getting me tooling along, luckily.
<infinity> Oh Em Gee, d-i has a "show password" toggle now!
<infinity> apw: Install grinding along decently now.  Will revisit in a bit and we can investigate on a live system with the issue.  Might make more sense there than trying to unwind the code blind.
<apw> infinity, indeed
<infinity> Man, I've been spoiled by live-installer on the server ISOs.  A full netinst is much slower.
<infinity> Reminds me that I wanted to publish those base images and use live-installer for netinst too.
<infinity> Probably too late to wedge that into xenial. :/
<apw> infinity, when quilt 3.0 applied patches it is meant to barf if they have any fuzz right ?
<infinity> apw: Fuzz, yes, offsets no.
<infinity> (Thankfully)
<apw> ahh ok, then that makes more sense
<infinity> You can feed it some extra options to make it reject on offset mismatches too, if you're paranoid about code blocks migrating.
<apw> infinity, i am getting an odd behaviour on debdiff where the diff is not including the applied patches, which ... it should
<melodie> infinity seeing you makes me think, I'd like to ask if you remember having considered adding a conf file for zram-config in the next LTS?
<apw> and yet when you unpack it it is applied ok
<infinity> apw: The debdiff shouldn't show patches applied.
<apw> thats stupid
<melodie> infinity one allowing to setup / choose the size of blocks and the number?
<infinity> You say stupid, I say working as intended. :P
<infinity> melodie: It would be lovely to do, but I can't commit any time right now.  Maybe after Beta2.
<infinity> melodie: My life is remarkably hectic right now.
<melodie> infinity I just wanted to remind you about it, to be sure you didn't forget our discussion a few months ago and for you to try to stick it to some kanban somewhere. :)
<melodie> the users of zram-config would all really appreciate, especially the long time users :)
<infinity> apw: If debdiff showed patches applied, you'd get the diff twice, essentially.
<apw> i guess, hrm
<apw> still makes my head hurt :)
<infinity> apw: Alright, on a full system, it still can't probe it.  So it's not just a missing dep in the initrd.
<apw> infinity, no can't be that i can see
<apw> if you are running modprobe foo, and it fails there are not a whole heap of things involved
<apw> kmod and the kernel, and a teensy bit of libc
<apw> infinity, and that is the same kernel that works in wily
<apw> and indeed libc is its only library
<infinity> Well, not the same kernel now, I installed with 4.4.0-12
<infinity> But I can downgrade to wily's for a proper comparison.
 * infinity gets all sciency.
<apw> heh
<infinity> ARGH.
<infinity> WHAT.  THE...
<infinity> apw: 4.2.0-16.19 (wily's ship kernel) works fine.
<infinity> On xenial userspace.
 * infinity tries -17 again to see if he's insane.
<infinity> apw: is toolchain stuff in the .deb somewhere, or do I have to scrub build logs?
<apw> if it does, work forward to find the last one
<apw> build logs i would think
<apw> we should record that, oh we must record the compiler in /boot somewhere
<apw> not anything else though
<apw> infinity, ^
<apw> infinity, oh no, we grep it out of the kernel
<rtg> apw, don't we record it in the .deb ?
<apw> infinity, rtg, we record it in every .ko, which is how i check it apparently
<apw> readelf -p .comment "$ko"
<infinity> Okay, now I'm going to lose my mind slightly.
<infinity> 4.2.0-17-powerpc64-smp, which failed on an old xenial server ISO, works fine on my installed system.
<apw> well that is more believeable, can you hop skip and jump forward
<apw> looking for the first bad
<apw> as you've just eliminated userspace i assume
<infinity> apw: It's more believable, but why did that ISO show the problem?  It's asking more questions than it answers. :P
<apw> shhhh it'll hear you and change
 * infinity goes to find an early 4.3.0
 * apw puts a small bet on 4.4.0-3.17 as the first bad
<infinity> apw: Any particular reason?
<infinity> apw: Is that where the commit you thought was the "fix" was introduced?
<apw> there is only one fix to the module scraper, fixnign a gcc-6 thing in the tree
<apw> and i want it to be that
<infinity> apw: Was that pulled into 4.2.0 stables too?
<apw> it looks benign but ... maybe its not
<infinity> (I have no access to the librarian here, it's much easier if I can pull from the archive. :P)
<apw> infinity, looks like it was
<infinity> apw: Tags?
<apw> Ubuntu-4.2.0-28.33 was the first one with in 4.2
<apw> Ubuntu-4.4.0-3.17 in 4.4
<apw> dunno if that is it of course, but it is a worry
<apw> though if you can test one of those version brackets i guess it might eliminate easily
<apw> Ubuntu-4.2.0-27.32 is prev on 4.2 and Ubuntu-4.4.0-2.16 on 4.4 if that helps any
<infinity> 28 and 29 don't exist, grabbing 30.
<infinity> Must have been respin hell.
<apw> oh yeah, probabally, we did a lot back there
<apw> oh we don't reap nbs in -updates, handy for you here
<infinity> Quite.
<infinity> Booting 27.
<infinity> That seems fine.
<apw> these are the "first sane" looking 4.3 and 4.4s Ubuntu-4.3.0-1.10 Ubuntu-4.4.0-1.15
<infinity> -30 is also fine.
<apw> ok so not that then, pup
<apw> your search continues then
<apw> of course you will get to -12 and it will work
<apw> such is the nature of the world
<infinity> Yeah, I'm worried about that myself.
<infinity> apw: Well, at least 4.4.0-12 still fails.  So, I'm not completely insane.
<infinity> I'm going to have to mirror a bunch of kernels and scp them up to test more interim ones.
<apw> ack
 * apw wonders how it is going
<Beret> man
<Beret> unplugging a usb key from my xenial machine just hard locked it
<nusch> how to get broadcomm wireless driver (bcmwl-kernel-source) working with mainline(4.5) kernel to test for some bug?
<apw> nusch, i doubt that anyone has made one yet
<nusch> @apw would would you then suggest to debug this https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1545320 ? I need wireless to reproduce this bug. Use 4.4? Or somehow backport only relevant functionality of i915 ?
<ubot5> Launchpad bug 1545320 in xserver-xorg-video-intel (Ubuntu) "Dell XPS13 with i915 hangs with only mouse cursor and SSH working" [Medium,Incomplete]
<apw> nusch: i am not sure why you need wifi for a graphics bug, could you use an ethernet or wifi usb dongle
#ubuntu-kernel 2016-03-15
<melodie> good night
<infinity> apw: Going through the xenial history ended up being one of those bisects we hate:
<infinity> linux-image-4.2.0-19-powerpc64-smp_4.2.0-19.23_powerpc.deb -- good
<infinity> linux-image-4.3.0-0-powerpc64-smp_4.3.0-0.9_powerpc.deb -- bad
<infinity> apw: So, yay, that's a huge chunk to drill through between them still.
<apw> man o man that is a lovely one
<apw> we likely have mailine builds in between but it will turn out to be -rc1
<infinity> Probably.
<infinity> I still need to understand why that ISO didn't work.
<infinity> Or maybe I don't need to, because it doesn't make sense.
<infinity> apw: https://git.kernel.org/linus/f15838e9cac8f78f0cc506529bb9d3b9fa589c1f
<infinity> apw: Please to cherrypick, thanks.
<infinity> apw: Pretty please.
<infinity> Based on the CC, I'd assume it'll come in via Greg's tree "sometime", but I'd rather that be now. :P
<hallyn> lol i've not had a /. account in 15 years, but they found me for their we 've been bought ut email
<hallyn> but so i guess my thought wasn't to paper over bugs in the lxc monitor, but rather to make sure you can still list containers and figure out what's going on
<hallyn> all right lemme set up a clean system and see if the guy's recipe works for me.  (thogh it seems unlikely)
<hallyn> guess i'll leave this running for a few hours.  no hang so far.
<stgraber> hallyn: I think you meant for ^ to go to #lxc-dev :)
<hallyn> doh
<hallyn> my channels done moved
<apw> infinity, ack
<apw> b 7
<caribou> apw: from what I can gather, DASD kernel dump is not triggered automatically but requires operator intervention
<apw> caribou: ahh ok, such is life then
<cpaelzer> caribou: apw: https://github.com/qemu/s390-tools/blob/master/etc/sysconfig/dumpconf
<cpaelzer> caribou: apw: I don't know if we have this in our s390-tools/utils package yet
<cpaelzer> caribou: apw: but in genereal one can set dump-on-panic instead of operator intervention
<apw> cpaelzer, oh thats better indeed
<cpaelzer> apw: yeah, testers usually configure that as step #1 to capture anything that might happen
<apw> caribou, did you get access to that s390x instance yet ?  if so would you be able to get me a dmesg off it (for an unrelated bug)
<caribou> apw: I should still have access to xnox's instance, lemme check
<caribou> apw: just emailed it to you
<apw> caribou, thanks
<Odd_Bloke> When will linux-hwe-{generic,virtual}-trusty stop pointing at linux-image-{generic,virtual}-lts-utopic?
<apw> Odd_Bloke, weeeeel it should alread point to -lts-vivid, but perhaps that ship has sailed
<apw> bjf, ^ we should prolly make a plan on how that changes, what the criteria is
<apw> xnox, as this could be host tools fooking up the key or the kernel fooking up the key, i have built a cross compiled kernel which would therefore have used the x86 userspace to build the key... would you be able to boot the s390x kernel here sometime:  http://people.canonical.com/~apw/master-next-xenial/
<infinity> apw: It should probably change at the same time as point releases go out (since that's when we officially recommend people use the newer HWE stack), but clearly that's not been happening. :P
<apw> infinity, right i think the same official position, which did not occur for -v
<infinity> apw: Nor -w.
<apw> oh yeah, whoops
<xnox> apw, BAD
<xnox> [    0.687893] Problem loading in-kernel X.509 certificate (-74)
<xnox> Linux DEVAC02 4.4.0-14-generic #30~masternext201603151358 SMP Tue Mar 15 13:59:23 UTC 2016 s390x s390x s390x GNU/Linux
<apw> ok so not likely to be userspace tools breaking it as those were HOST compiled in that build
<xnox> apw, i have rhel system that loads the keys fine...
<xnox> apw, here is the config from it http://paste.ubuntu.com/15393512/ if that at all relevant.
<xnox> i don't see anything....
<apw> xnox, no indeed, i'll start adding debug, i can see nothing obvious
<xnox> apw, anyway i can make things faster for you? would you want an ubuntu libvirt-qemu VM or some such?
<apw> xnox, if you are happy to test kernels that works for me
<xnox> apw, ok =)
<xnox> apw, any point in me fetching and trying an older kernel (e.g. 4.3) to check if things used to work back then?
<apw> xnox, yep, thats is a good idea, find me a first broke if you can
<apw> and i'll add some printks
<apw> xnox, ok first debug: http://people.canonical.com/~apw/lp1557250-xenial/
<xnox> apw, call trace at http://paste.ubuntu.com/15393871/
<xnox> load_system_certificate_list
<xnox> or do you want more things from console too?
<apw> [    0.678674] preparse -> ret=-74
<apw> that is the info i wanted, the call trace it the new bits tim added, so we find out this is happening in the wild if it comes back
<apw> rtg, your warn_on_once is working
<rtg> apw, getting some stack traces ?
<apw> rtg, yep, on s390x where we know it is broke
<rtg> apw, did you find any encryption configs that need enabling ?
<apw> rtg, nope, still debugging it with xnox
<xnox> rtg, yeah no configs diff that we can spot (i compared with e.g. rhel config where certs are loaded)
<xnox> apw, is there any vanilla kernel i can try, to see if things are dire upstream? (but i guess we kind of know that now...)
<apw> xnox, for s390x ?  no
<xnox> ok, i got to go =(
<xnox> apw, talk to you later.
<apw> xnox, no worries, i'll shove you a new debug kernel and you can get to it when you do
<TJ-> is there any plan to include trim/discard support in the zfs driver?
<apw> TJ-, is there a bug associated with that ?
<apw> so i can check
<TJ-> on Launchpad, or on the ZFSonLinux project?
<TJ-> I've been following the upstream work and the merge proposal *finally* looks to be ready: https://github.com/zfsonlinux/zfs/pull/3656
<apw> xnox, there is a new debug kernel in the same place ... have fun
<apw> TJ-, if its not a standard feature i am not expecting it to be something on our radar at this time, this being the first lts with this in, its not clearly its a good plan to have anything experimental in there
<TJ-> apw: right; it might be worth flagging up in prominent docs about lack of discard/trim support for those that are intending deploying it to SSD systems
<TJ-> especially as a major use-case appears to be for supporting containers etc.
<apw> TJ-, i am sure anyone buying into zfs would know, but possible i guess
<jdstrand> jsalisbury: fyi, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547619/comments/28
<ubot5> Launchpad bug 1547619 in linux (Ubuntu Xenial) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Medium,In progress]
<jdstrand> jsalisbury: that is *not* the one you mentioned in #27, but rather the one from #24
<jsalisbury> jdstrand, thanks for the update.  I'll build the next test kernel
<jdstrand> thanks!
<smoser> hey
<smoser> how much do we care ?
<ohsix> 4
<smoser> out of 9 ohsix 
<smoser> http://paste.ubuntu.com/15395889/
<smoser> how much do we care about the stacktrace above ^
<smoser> coupled with host kernel dmesg http://paste.ubuntu.com/15395901/
<smoser> that is trusty on xenial through vagrant. 
<smoser> in the guest this would cauase a hang: cat /proc/8248/cmdline
<smoser> rtg, ^ ? i suspect its "not much".
<apw> smoser, is taht really on 3.13.0-32 ?  thats like 50 releases behind
<rtg> smoser, it is hard for us to do much with vbox
<apw> and we had known issues with vbox back in the old days
<apw> smoser, why is it booting such an old kernel anyhow ?
<smoser> apw, that is a good point.
<smoser> the user was booting that old kernel because they did an iso instll (through a tool called packer) 
<smoser> and the only isos that install a 3.13 get you that level
<apw> hrm, so they may have a bit of a chicken/egg issue
<smoser> yeah, could be. but in this case it wasnt the intsaller trying to install a newer kernel. the vagrant box that was published had the very old kernel there.
<apw> and this is why the pre-canned binary form for things is not a good idea
<apw> tjaalton, isnt broadwell supposed to used thei915 you added ??
<apw> tjaalton, does not on my lappy
<infinity> Is it?  I thought the i915 backport was for skylake.
<apw> i think i saw tjaalton say it was for more than skylake
#ubuntu-kernel 2016-03-16
<tjaalton> apw: the one on xenial is skl/kbl/bxt
<apw> tjaalton, hmm i don't think i know what those three all are; skylate, erm
<smb> If one would not know better one would guess keyboard failure
<tjaalton> apw: heh, kabylake and broxton (aka apollo lake)
<apw> tjaalton, those i have not even heard of
<apw> tjaalton, ok so i am seeing lockups on resume in what feels like graphics and some visual corruption occasionally in icons in firefox, on broadwell
<apw> tjaalton, with the xenial kernel -12 at least, i just upgraded to -13 and have not been on it long enough to know if it is sad too
<tjaalton> apw: ok, is the corruption right from the start, or only after a resume or such? check dmesg if so
<tjaalton> there could be a gpu hang and recovery isn't complete
<apw> tjaalton, you know how these bugs are you are never quite sure till they happen a few times, i currently feel, only after a resume
<tjaalton> right
<apw> but i'd not want to swear to it in court.  i will check dmesg if i see such corruption again on -13
<tjaalton> cool
 * apw wonders if xnox has tested his second debug kernel yet
<xnox> apw, not yet
<xnox> apw, i did not hit any of those printk... http://paste.ubuntu.com/15400970/ unless i'm not collecting them at all.
<apw> xnox, literally none of them, which is perplexing
<apw> xnox, that is the generic kernel not an apw build
<apw> [    0.008770] Linux version 4.4.0-13-generic (buildd@z13-012) (gcc version 5.3.1 20160225 (Ubuntu 5.3.1-10ubuntu2) ) #29-Ubuntu SMP Fri Mar 11 19:30:41 UTC 2016 (Ubuntu 4.4.0-13.29-generic 4.4.5)
<xnox> boom
<xnox> apw, http://paste.ubuntu.com/15400999/
<xnox> apw, btw the .debs are suspiciously the same as I tested yesterday, you didn't bump version number timestamp at all?
<apw> xnox, yes, they would have had new times
<xnox> it downloaded for me as linux-image-4.4.0-14-generic_4.4.0-14.30lp1557250v201603151737_s390x.deb.1 hence i don't think so.
<xnox> http://people.canonical.com/~apw/lp1557250-xenial/ has timestamps 17:41 from yesterday, which is from before i left, no?!
<apw> xnox, i mean i cannot make a build with the same time, so if it is the same time, that is not a new build, its is ... erm ... wrong
<apw> xnox, ok something is screwey, the only safe thing for me to do is rebuild it
<apw> xnox, oh i think i may have built a wrong branch and pushed binaries but useless ones for another bug, sigh, be 10m
<xnox> more coffee
<apw> xnox, ok some actually new binaries pushing, sigh, sorry about the confusion there, should be up in ... now
<xnox> ack
<xnox> apw, http://paste.ubuntu.com/15401110/
<xnox> [    0.734265] Loading compiled-in X.509 certificates
<xnox> [    0.734266] x509_cert_parse called
<xnox> [    0.735100] x509_check_signature -> -448754944
<xnox> [    0.735101] preparse -> ret=-74
<apw> xnox, ta ...
<apw> xnox, ... and again
<xnox> apw, 
<xnox> [    0.715208] Loading compiled-in X.509 certificates
<xnox> [    0.715209] x509_cert_parse called
<xnox> [    0.715230] APW: crypto_shash_finup 0
<xnox> [    0.715231] APW: RSA_verify_signature called
<xnox> [    0.716088] APW: public_key_verify_signature ret=-74
<xnox> [    0.716089] x509_check_signature -> -74
<xnox> [    0.716090] preparse -> ret=-74
<xnox> http://paste.ubuntu.com/15401110/
<xnox> wrong paste.
<xnox> i mean
<xnox> http://paste.ubuntu.com/15401255/
<xnox> (yeah thats the 1234 build)
<apw> xnox, ok making progress, its tricky to add all teh debug we need in one run
<apw> xnox, as we jump through callbacks where there are 3-4 options
<apw> RSA_verify_signature was one of those
<tyrog> Hi guys, do you think Kernel 4.5 is still coming as default for Ubuntu 16.04?
<ogra_> no
<tyrog> ogra_: I know for now it is on Kernel 4.4, can that decision change until Final?
<ogra_> nope ... 4.4 is an LTS kernel ... 
<tyrog> ogra_: ok, tnx :)
<ogra_> there will be hwe kernels later ...  like you can alwas use newer kernels on ubuntu LTS releases... 
<tyrog> ogra_: 3.13 on 14.04 wasn't a LTS kernel too...
<ogra_> yeah, that means that the ubuntu kernel team needs to maintain this version for 5 years themselves
<ogra_> if you can have a kernel that is upstream maintained instead it means you free developers for other work
<tyrog> I see
<tyrog> yes, then probably the right decision is to keep 4.4 :D
<ogra_> it will just make the 4.10 (or whatever will be current at 16.10 release) hwe kernel better ;)
<apw> tyrog, yeah waht ogra said
<tyrog> apw: Fine as 4.4 should be very stable when 16.04 Final is released ;)
<apw> tyrog, yeah we try and hold back a bit for these lts' than we would in an interim one, and that upstream is doing stable for 4.4 is a major boon
<apw> xnox, another test kernel for you, i hope
<xnox> tyrog, if you want things in 16.04 kernel, make those things to be backported to 4.4. into stable tree, or other trees. Backports of bits & pieces of 4.5 drivers are in our 4.4 kernel...
<xnox> or e.g. bugfixes should be taken into stable tree.
<xnox> apw, http://paste.ubuntu.com/15402573/
<xnox> 1424 kernel
<apw> xnox, another one uploading ...
<xnox> apw, off by one?! http://paste.ubuntu.com/15403281/
<apw> xnox, hrm ... odd ... indeed
<xnox> there is extra garbage on non-s390x? because it's using.... weird encoding?!
<xnox> anyway, i should stop guessing and go back in fixing something useful.
<apw> i'll poke seom more indeed
<apw> xnox, antoher kernel pushing, this one might work or it might explodes, that will be interesting
<xnox> apw, thank you for powerpc kernel?!
<apw> xnox, the last s390x is the same one, that is for someone else :)
<apw> is the same contents as the ppx
<apw> ppc
<xnox> ack.
<xnox> will test 1848 kernel
<apw> ta
<xnox> fail
<xnox> http://paste.ubuntu.com/15403933/
<xnox> missing prefix, hence off-by-one?
<xnox> did we check by the way that e.g. powerpc loads the cert fine?
<xnox> i guess we don't have powerpc (big endian) machines to test the kernels on, do we?
<apw> yes, a powerpc BE also fails in the same way
<apw> bah this is an endian issue, and i need to think about how to fix it ... prolly will punt it at anton :)
<xnox> because the cert is read in host-endian order, rather than little-endian order.
<xnox> we should be able to find upstream regression too.
<xnox> cause we had powerpc forever.
<apw> xnox, its not quite like that, its handled in an endian sensible way, its not handling the packing right it seems
<apw> debugging it is tricky
<xnox> https://bugs.launchpad.net/ubuntu-mate/+bug/1541151
<ubot5> Launchpad bug 1541151 in ubuntu-mate "16.04 PPC, unable to boot: "Problem Loading in-kernel X.509 Certificate (-74)"" [Undecided,New]
<apw> why would that not be able to boot
<apw> that does not prevent booting
<xnox> also
<xnox> https://lists.debian.org/debian-powerpc/2016/02/msg00010.html
<apw> i don't believe the mate issue is actually related, but ...
<xnox> it's a data point that in alpha the bug was present.
<apw> i don't believe that is the reason the system does not boot
<apw> but it is clearly there for a long time
<xnox> should i open kernel.org bug?
<apw> which we would never notice because it is benign
<apw> xnox, for the moment no, i am working on it
<xnox> ok.
<infinity> apw: antonb and benh should be around (and maybe even awake shortly) ... mpe might already be, I can never remember where he lives.
<apw> ack
<apw> xnox, another one pushing now for testing if you are about
<xnox> apw, patch looks plausible.
<apw> xnox, yeah, plausible, but i bet wrong again :)
<apw> xnox, fun ?
<xnox> apw, http://paste.ubuntu.com/15404387/
<xnox> not sure about the size length reversion.
<apw> xnox, so made no differance at all ?
<xnox> apw, well we don't know. you have reverted the size compare, so we don't know if a later [1] check succeeds or not.
<xnox> i'd like a kernel without the 0008 patch
<apw> ack
<apw> xnox, uploading now ...
<apw> ... and done
<xnox> apw, so your fix didn't help as per previous stuff. it may have helped with something/somewhere else.
<xnox> http://paste.ubuntu.com/15404438/
<apw> hmmm
<apw> xnox, ok i need to dump the thing en-toto
<xnox> apw, in the mean time, i win - LD [M]  /home/ubuntu/linux/debian/build/build-generic/zfs/module/zfs/zfs.ko
<apw> xnox, heheh, if you have it building, we might have some tests somewhere
<xnox> apw, can you test-build s390x kernel proper for me with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519814 ?
<ubot5> Launchpad bug 1519814 in linux (Ubuntu Xenial) "spl/zfs fails to build on s390x" [Medium,Triaged]
<apw> xnox, yep in a few
<xnox> i only got it to do ./debian/rules build to complete. And i have tried to fake the patch to mimic other commits you people do in a strange way.
<apw> ok
<apw> as it is zfs i'llneed to upload it to a PPA
<xnox> yeap.
<xnox> i bet abi checker or some such will tell me to shove my zfs back were it was
<apw> xnox, likely
<apw> xnox, ok pushing a possible fix found for the signature problem ifyou could test
<apw> and done
<xnox> i just don't want to even know anything about limbs in the kernel
<xnox> [    0.678605] Loaded X.509 cert 'Build time autogenerated kernel key: 8d0653ca20551eb8f7822151a14011cc64a15ed4'
<xnox> we are good.
<xnox> http://paste.ubuntu.com/15404698/
<xnox> apw, ^
<infinity> \o/
<apw> xnox, sweet, i'll apply that then for the next upload
<apw> xnox, and i'll upload your zfs to a ppa
<xnox> apw, cooling having that 509 and zfs fixed would be nice for the beta next week.
<xnox> apw, which / where is the ppa upload?
<xnox> or shall i call it a night
<apw> xnox, i am uploading it now, will send you a link
<apw> xnox, https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+packages
<xnox> tah
<apw> should be about 30m
<apw> xnox, ok that sig fix now pushed to master-next for the upload, i'll wait on your testing for the zfs one
<apw> xnox, ok its uploading binaries now
<apw> xnox, well the linux-image has the .ko's you would want to find in there ...
<apw> xnox, let me know if it explodes in your face or not
<xnox> why do we have zfs-dkms and zfs in the kernel?
<xnox> shouldn't we retire zfs-dkms package from zfsutils package?
<xnox> apw, the module loads
<apw> xnox, we make the kernel modules from the dkms package
<xnox> huh?!
<apw> and the kernel provides that package, so we can drop it from the kernel
 * xnox is confused.... anyway.
<xnox> the module loads.
<apw> xnox, we need to fix this in the -dkms package to do this right, and update the kernel from it
<apw> but that is all deatails, if it works that would be interesting to us
<xnox> ok.
<xnox> well, i have upstream pull request open too.
<apw> yeah so that is good
<xnox> Package zfsutils-linux is not available,
<xnox> right.
<apw> yes, that will be a problem
<xnox> apw, do kernel people manage zfs-linux or may i upload it?
<apw> xnox, cking nominally looks after the delta to debian
<apw> xnox, bug i don't see any problem uploading a simple delta like enabling s390x for it
<xnox> why do we only compile on 64-bit arches?
 * xnox thought upstream totally supports 32bit arches....
<apw> xnox, mostly for support coverage, if you are using zfs it is unlikely to be 32bit
<xnox> apw, well, the question did come up as to why it's not available on 32bit.
<xnox> uploaded into https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages
<xnox> with arch:any, to see what happens.
<xnox> dkms module is arch:all, so no reason not to attempt to compile the user space tools.
<xnox> plus e.g. i hope that 32bit tools, can be used on 64bit kernel, for example.
<apw> yep
<apw> lets hope that
<apw> xnox, kaboom
<xnox> apw, so..... this is not module building is it?
<xnox> but tools exploading?!
<apw> yep the tools going blammo, something about VTOCs
<xnox> oh i think i am meant to either define _SUNOS_VTOC_8 or _SUNOS_VTOC_16
#ubuntu-kernel 2016-03-17
<xnox> apw, could you for shits and giggles try a build of zfs=true everywhere? e.g. all the 32bit platforms too.
<xnox> looking the disk-layout code, the structure on disk is arch intendant as far as i can see.
<xnox> independant
<apw> xnox, its meant to be very kva agressive and not recommended for use on 32bit, iirc the discussion 
<apw> xnox, which is why we didn't enable it there
<xnox> apw, and we are a nanny state? =)
<rlaager> I'm looking to bisect a kernel bug. I've narrowed it down to two mainline kernel packages, but now I need to build my own packages with intermediate commits. I have a checkout of the mainline sources with patches applied per: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-rc7-wily/README
<rlaager> How do I actually build this thing? The usual `debuild -uc -us` I would use fails because there is no debian/changelog. There's both a debian/ and debian.master directory after applying the patches.
<apw> rlaager, you need to clean the tree to get debian/control ... fakeroot debian/rules clean
<rlaager> apw: Thanks. I'm mid-build using a different set of instructions, so hopefully they work sufficiently for this attempt. I'll try that on the next build.
<tamil> Hi all,i am just a beginner ...i want to know how to develop our own ubuntu....
<apw> tamil, your own ubuntu en-toto or a specific piece
<tamil> specific piece....
<tamil> i want to develop a kernel
<tamil> sorry for my wrong words...
<tamil> how to simulate that ....
<apw> arple
<AndreeeCZ> join #zeromq
<AndreeeCZ> sry
<apw> heh, happens to the best of us about 3 times a day
<Skuggen> At least it wasn't a password :P
<apw> having the same spot be the command line for your irc client and where you type to send, is dumb
<apw> done that more than once too
<xnox> apw, ship it, it looks good.
<apw> xnox, what where when why ?
<xnox> userspace tooling and dkms have migrated
<xnox> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519814
<ubot5> Launchpad bug 1519814 in linux (Ubuntu Xenial) "spl/zfs fails to build on s390x" [Medium,In progress]
<apw> xnox, ok next week being beta is a big worry for this, so i am going to propose we pump the kernel with that enabled (and i will try and make ppc build too, a packaging bu)
<apw> xnox, and use the beta freeze week to get cking to hammer one or both to death, if they pass his scruitiny then we apply it and upload as the freeze ends
<xnox> ack.
<tseliot> rtg, apw: when do you plan on pulling in v4.4.6 ?
<apw> tseliot, depends on beta as much as anything, but expect it likely in the next upload
<apw> tseliot, what you needing from it
<tseliot> apw: 53e609099daa023ad7771ec8351202f2a7bee1c1 and 6f0679556b563bcd3d433d5781454123f1d134c5 should be already there. I would need to add f8456804460f5c232f097e72051beea063f16074 on top of that
<tseliot> (fixes for amdgpu, all from linux-stable)
<apw> you are saying that even with .6 applied you need to request one more fix ?
<apw> tseliot, ^
<tseliot> apw: yes, it seems like it
<apw> rtg, ^ (as you are likely already applying it)
<apw> tseliot, perhaps yuo could file a bug for that new one, so we can track it
<tseliot> apw: sure
<apw> now we are past ff we do need to be keeping better track of what we are applying and bugs are good for that
<tseliot> I'll link it to the upstream report too https://bugzilla.kernel.org/show_bug.cgi?id=113891
<ubot5> bugzilla.kernel.org bug 113891 in Video(DRI - non Intel) "[radeon] Display jitter" [High,Assigned]
<awreece__> When I run iostat -x, the disk utilization (and await, and queue size, etc) reported for md0 (my raid0 device) are all 0. Is this expected, and if so, why?
<tseliot> apw, rtg: https://bugs.launchpad.net/linux/+bug/1558656
<ubot5> Launchpad bug 1558656 in linux (Ubuntu) "[radeon] Display jitter" [High,Triaged]
<apw> awreece__, that i assume is s/w raid, so all the real devices are underneath no ?
<tseliot> apw: do I need to send the patch myself or is the bug report enough?
<awreece__> apw: yeah, I assume so
<awreece__> I believe md0, etc all are software raid
<apw> tseliot, you would expedite the world if you send it
<tseliot> apw: pull request or a simple patch?
<apw> simple patch is fine
<tseliot> ok, good
<mamarley> apw: How often do those uploads occur?  I hadn't noticed any sort of pattern, and https://wiki.ubuntu.com/Kernel/StableReleaseCadence doesn't seem to have information about development releases.
<tseliot> apw: actually, never mind, that patch seems to be included too. Sorry for the noise
<tseliot> rtg: ^
<lamont> jsalisbury: latest kernel  makes me want to ask for another one...
<lamont> jsalisbury: can I get the commitreverted kernel with the fix as-landed added?
<lamont> jsalisbury: what I see now is that if the screen blanks (may require locking, but mine always locks before it blanks...), then anything on the right side of the top left workspace magically moves to the left side of the workspace to the right... This is not success, but I want to figuyre out if it's part of the original bug, or something new.  (I expect that it's the former)
<jsalisbury> lamont, So you want the kernel from comment #29 with the fix that just went into Xenial?
<lamont> jsalisbury: that exactly
<jsalisbury> lamont, sure, I'll build one and send you a link
<lamont> ta
<lamont> jsalisbury: my suspicion: with the just landed fix, the X server believes (sometime after screen blank, or maybe when it unblanks...) that we shifted from dual-head to single-head and then back
<lamont> which would mean "still not done"
<lamont> and I hope it's that, because bisecting it would be a royal PITA
<jsalisbury> yeah
<lamont> since it's "bisect and then add the just-landed commit" for each time
<lamont> jsalisbury: thanks for the kernel -- it'll be tomorrow before I can test it
<lamont> will advise in the bug
<xnox> sbeattie, please stop!
<xnox> sbeattie, you are doing too much!
<xnox> sbeattie, from IBM we have two architectures: ppc64el and s390x. One is with powerpc64le tag the other is s39064.
<xnox> sbeattie, s390x only exists in xenial, it's a brand new arch.
<xnox> sbeattie, thus any bugs from "skipper" team or with tag architectures-s39064 or tag s390x do _not_ need any SRUs or backporting at all.
<xnox> e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1556141
<ubot5> Launchpad bug 1556141 in linux-raspi2 (Ubuntu Xenial) "s390/mm: four page table levels vs. fork" [Medium,New]
#ubuntu-kernel 2016-03-18
<infinity> xnox: Those tasks are added by a script that the security team uses to track CVEs.  They tend to prefer if others don't touch them. :P
<infinity> xnox: Also, we maintain some kernels upstream (3.13, 3.16, 3.19, 4.2), and we absolutely apply CVE fixes for arches we don't ship in our upstream stable trees.
<infinity> xnox: (Not everything is about contracts)
<xnox> infinity, oh.
<xnox> sbeattie, in that case i probably did more harm than good.
<xnox> sbeattie, i'm sorry if i messed things up.
<sbeattie> xnox: yeah, sorry, script on autopilot. I don't think you did any harm (well, it'll gripe at me about the deleted tasks, but that just means it goes on a list of other bugs that have the same issue)
<xnox> =/
<tjaalton> is there a known issue with the keyboard getting stuck on resume?
<tjaalton> hmm, maybe it's just with my test versions.. I blame libinput
<apw> tjaalton, not seen that here
<tjaalton> i have that on two systems, it's actually hard to resume if it's suspended by hotkey.. since it keeps suspending a number of times
<tjaalton> and that then seems to break iwlwifi, nice
<apw> tjaalton, sounds about right to me :)
<tjaalton> i really don't understand those who demand intel wifi.. it's been nothing but crap on all my systems
<apw> tjaalton, but at least it is open source crap ... i have much worse experiences with things that needed wl
<tjaalton> that's true, but then there's the fw component too
<apw> yep, we get regular updates for iwlfw, it is clearly a work in progress
<apw> and if you are holding the suspend button down, i am sure that is ripping and reinstalling and ripping the h/w out every time
<apw> which is bound to push the races in teh driver to their limit
<tjaalton> right, iwlwifi seems to crap itself on it's own though, after a few cycles. but then again this is intel sdp so all bets are off as always
<apw> and that
<netikras> Hello boys
<netikras> Is this the right channel for queries regd http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<netikras> Whichever 4.x version I try to install (.deb), I get a few error messages: due to -Werror virtualbox-client and ndiswrapper fail to install
<netikras> I can dump logs here or I could fill-in a bug report. I just can't find where to register a new bug.....
<apw> nelhage, those are mainline kernels, they are for testing only, it is highly likely they are ahead of teh supported versions in dkms packages ...
<kernelbug> Could someone do a bisection between 3.18.26 and .27 ?????
<kernelbug> I think I found a bug.
<kernelbug> I use Mint and .27 hangs on the logo screen, .26 works fine.
<kernelbug> http://expirebox.com/download/b57059eb53fedc4d8fd6f85da506a242.html
<kernelbug> Here are the dmesg files.
<kernelbug> I guess they won't help but anyway.
<kernelbug> Am I in a wrong channel?
<ogra_> for mint questions ? perhaps ...
<kernelbug> I'm using Ubuntu mainline kernel!
<kernelbug> FFS!
<ogra_> mainline ?
<ogra_> or ubuntu ? 
<mamarley> I think there may be a regression in suspend functionality for the Thinkpad T530 between Wily and Xenial.  On Wily, suspend works great but on Xenial if I suspend more that two times, it hangs while suspending.  I am about to try the 4.2 mainline kernel on Xenial and see if that makes a difference.
<kernelbug> These... http://kernel.ubuntu.com/~kernel-ppa/mainline/
<ogra_> (the mainline build is completely unsupported ... )
<ogra_> (it is just to verify bugs)
<kernelbug> Hehheh...
<kernelbug> I need to verify a bug then. :)
<ogra_> also pleaae watch your language 
<kernelbug> What language? Check all the three-letter acronyms and their meanings... :)
<ogra_> against which ubuntu kernel are you verifying ?
<kernelbug> Between 3.18.26 and 3.18.27... .27 is which fails.
<ogra_> there is no ubuntu version in that list 
<ogra_> you seem to compare one mainline build against another ?
<kernelbug> Yes.
<kernelbug> I use mainline kernels in Mint.
<ogra_> yes, you said so ... 
<apw> why 3.18 of all versions ?
<kernelbug> They won't support those kernels either. ;)
<ogra_> and i said mainline kernels are not supported ... they exist to veryfy bugs against the ubuntu kernels 
<kernelbug> I prefer stability.
<kernelbug> 3.18 is LTS anyway.
<kernelbug> That's another selling point for me. :)
<apw> why not use an ubuntu kernle which is an lts
<kernelbug> I'm using Mint.
<apw> and mint uses ubuntu kernels right ?
<kernelbug> It's a modified Ubuntu kernel anyway.
<kernelbug> Yes, slightly modifies ones.
<ogra_> apw, i dont think tehy do ... 
<kernelbug> Yes they do.
<ogra_> they hack them up like theyy hack up half of the libs (while keeping versions and sonames)
<kernelbug> ogra don't ruin this conversation
<kernelbug> you are not very helpful
<kernelbug> go to hockey game if you want brainless entertainment :)
<ogra_> kernelbug, this channnel is about ubuntu kernels ... you came here, cursing and trolling about stability to get support with a mainline build that isnt supported, what do you expect ? 
<kernelbug> I need your help with the bisection.
<kernelbug> In other words how to do a git-bisect to generate Ubuntu mainline kernels to test bugs ?????
<ogra_> https://wiki.ubuntu.com/Kernel/KernelBisection
<kernelbug> OK.
<apw> kernelbug, you need to pull the .config out of your current version and use that to build kernels using those two tags as bisect end points
<kernelbug> Maybe it's "userspace" issue though.
<kernelbug> apw, OK. :)
<kernelbug> Lots of work anyway.
<kernelbug> I'm already burning out.
<kernelbug> I'm too old for this shit! ;)
<kernelbug> Gotta talk with the Mint folks now.
<kernelbug> Sorry. ;)
<ogra_> (they will probably tell you to use a mint kernel :) ... you are kind of between the worlds)
<mamarley> Looks like I am going to have to bisect a kernel too.  Mainline 4.2.8 (and Wily 4.2) has working suspend support on my T530, but Xenial 4.4 has broken suspend support.  Now I shall try 4.3...
<kernelbug> ogra_ yeah...
<kernelbug> Like a child from a dysfunctional family, which I am...
<apw> mamarley, if that is an ubuntu kernel you should file a bug, and someone will likely be able help
<mamarley> apw: I will once I isolate when it was introduced a bit more.  I am about to try 4.3 to see if the bug was introduced in 4.3 or 4.4.
<apw> sounds good.  let us know the bug# here when you do
<mamarley> Sure.  I don't need someone to build the kernels for me though; I have a pretty beefy box that I can do it on.
<mamarley> I suppose I should probably try the 4.4 mainline kernel as well so I can figure out if the regression was introduced by something backported from 4.5.
<apw> mamarley, if you are able to do it yourself, all the better
<mamarley> It wouldn'
<mamarley> t be the first time :)
<kernelbug> apw, you could help me too...
<kernelbug> apw, even if it's mainline ;(
<apw> it wouldn't be me, it would be someone who does those kinds of things when he finds bugs to work on
<mamarley> The regression is definitely between 4.3 and 4.4 in mainline.
<kernelbug> mamarley, we have similar problems.
<mamarley> kernelbug: No, we do not.  Your login screen fails to display, my laptop fails to suspend.  I am running 4.4, you are running 3.18.  I am running Ubuntu Xenial, you are running Mint.
<kernelbug> mamarley, how can you know?
<kernelbug> mamarley, maybe the same bug applies to 4.4. :)
<mamarley> The only similarity between our problems is that both require a bisect.
<kernelbug> hehe
<kernelbug> bisection sounds brutal
<mamarley> It isn't fun.
<mck182> hi, I wanted to give a try to the latest mainline kernel to debug some issues I have with suspend, but it appears that installing it fails on compiling i915 dkms - http://paste.ubuntu.com/15416510/ - I'm not entirely sure how to proceed from here - is there any way to fix that issue?
<apw> mck182, it is common for mainline kernels beyond ubuntu devleopment versions to break dkms packages and those won't get updated until the kernel moves forward in YY most likley
<mck182> ah
<mck182> apw: so no way for me to test the latest kernel until the intel driver is available for YY?
<apw> depends what the dkms package is
<mck182> I don't even know tbh
<apw> then you might not be using it
<apw> it might be cruft
<mck182> I do have it loaded, I would assume it's the graphics driver
<apw> mck182, hmm, that is an i915 driver ... i have literally no idea where that has come from
<apw> mck182, can you tell me the package name ?
<apw> though i would say you don't need it with later kernels ... probaballyu
<mck182> apw: which package? the kernel? or the dkms?
<apw> the dkms package which is exploding, i assume it has i915 in its name
<mck182> apw: i915-4.0.4-3.19-dkms
 * mck182 looks for where it came from
<apw> so i'd say that is redundant with any kernel after 3.19, but its not an archive package as far as i know
<apw> is this a dell by any chance ?
<mck182> apw: ah, then it may have come from the intel-linux-driver-installer thing...or the xorg-edgers
<mck182> apw: no, macbook pro
<apw> tjaalton, is thatone of yours ^ ?
<apw> mck182, it has to be very old compared to xenial and later kernels
<apw> so i would just rip it for those
<tjaalton> no intel provided dkms's at one point
<mck182> apw: I'm runing wily fwiw
<apw> tjaalton, they did?  woh, how do i not know this ... :/
<tjaalton> ignorance is bliss
<apw> tjaalton, are they in a PPA somewhere or off in intel.com somewhere
<tjaalton> 01.org
<tjaalton> their quarterly stack
<apw> ugg
<mck182> so, if I reboot into the newly installed mainline kernel (4.5), I should be fine without that dkms?
<mck182> actually
<mck182> that error I posted above is related only to the dkms, not the kernel itself, right?
<apw> i'd say anything above 3.19 from the name
<apw> looks to be yes
<mck182> alright
<mck182> well I'll just try :)
 * mck182 reboots
<tjaalton> looks like they still ship a dkms.. https://download.01.org/gfx/ubuntu/15.10/main/pool/main/i/
<mck182> hah, yeah, it works without any problem :)
<apw> tjaalton, i thought we were sorting that for them via the i915_bpo nightmare we are carrying in everything
<tjaalton> they have this DIY-thing for users
<tjaalton> and we're doing this for oem's not intel
 * mck182 still has a wonky suspend...so much for trying newer kernel
 * mck182 still has a wonky suspend...so much for trying newer kernel
<apw> mck182, 100% wonkey or randomly so
<mck182> apw: no change from the stock ubuntu kernel; my laptop wakes up after 4 seconds of suspend
<mck182> is there any way to get the wakeup reason?
<mck182> I'd like to know what is causing the wakeup
<apw> mck182, there might be info in the order of the words in the dmesg output
<apw> mck182, i would check the rtc alarm
<apw> windows tends to set that to wake up the machine now and again so it an check the battery and make it hibernate harder
<mck182> apw: there's nothing :S I also tried the pm_trace, but that hangs the wakeup altogether and says /base/power/main
<mck182> the only interesting thing from dmesg is "xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI" when suspending
<mck182> which is in line with /proc/acpi/wakeup
<mck182> but I have no devices connected to this laptop
<mck182> so must be something internal
<apw> what does the rtc alarm say
<mck182> apw: that's /sys/class/rtc/rtc0/wakealarm right?
<apw> that sounds believeable, i think you can cat it
<mck182> apw: so that's empty
<apw> likely not that then
<mck182> well then there's /proc/driver/rtc
<mck182> which has some stuff http://paste.ubuntu.com/15416793/
<mck182> but I've no idea what that means or if it's relevant
<mck182> also, rtcwake -m show says "alarm: off"
<apw> that sounds definative to me
<mck182> unless it is set by something at suspend time
<mck182> which would be strange
<mck182> disabling the XHC1 wakeup disables the open-lid-wakeup -.-
 * mck182 wonders how did apple design this thing
<apw> with as little h/w as possible to make it cheap
<mck182> looks like this bug btw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1391476
<ubot5> Launchpad bug 1391476 in linux (Ubuntu) "[MacBookPro11,1] Laptop wakes up while lid closed" [Medium,Expired]
<apw> mck182, sounds liek there is at least something to try in there
<apw> mck182, the echo thing, if that works then you could encode that in the pmsuspend world somewhere i am sure
<mck182> apw: yeah it suggests disabling XHC1 from wakeup
<apw> which sounds rather similar to your problem
<mck182> apw: but as I sad above, that also breaks lid-open wakeup for me ( ._.)
<apw> well presumably you open lid and hit function and win
<apw> or app or whatever dumb name the clover-leaf is called
<apw> but it may well be a programming the h/w problem, a problem that is hard to fix because the h/w is undocumented
<mck182> indeed
<apw> delbieratly by apple to make sure their own os is better
<mck182> although disabling the XHC1 also disables keyboard wakup
<mck182> so the only way is to hit the power button...no big deal but...
<apw> its prolly the touchpad, the screen touching it and waking the machine
<apw> you prolly have to turn the touchpad off somehow, and not the keyboard
<mck182> hmmm
<apw> to get the mac behaviour
<apw> but they are renound for randomness, like to use the SD card slot
<apw> you have to power up the phy for the ethernet
<mck182> lemme test suspending without the lid closed and pressing the touchpad if that actually wakes it
<apw> good idea
<mck182> well, didn't even have to get close to the touchpad, it wakes up all on its own without touching anything
<apw> not that then, but to be honest you are likely to never have a fix for that unless someone gets epically lucky
<mck182> yeah, I guess
<apw> such is the fate of those who buy macs :(
<apw> shame they are so nice
<mck182> well fwiw I do have a 2011 mac as well and that one works 140% great
<mck182> but true, they did design these new ones from scratch
<apw> the only way to keep ahead of linux :)
<mck182> heh
<mamarley> I don't even consider them nice.  They are impossible to work on and have everything soldered down on the mobo.
<mck182> the latter is a real downside, but working on them...never had a problem really
<mck182> and the touchpad is awesome
<mamarley> Kernel bisection sucks.  This is going to take all weekend. :/
<apw> mamarley, that sounds about right, builds are not quick
<apw> even with an enormous hoover
 * mamarley has an i5-6600K box with an SSD.
<mamarley> It can definitely heat up the room when I compile stuff.  I am glad I am not actually there right now. :)
<apw> mamarley, how long does a build take ...
<mamarley> apw: Not sure, my last one got interrupted because the terminal application crashed.  I am measuring this one.  I will try -j8 instead of -j4 on the next one and see if that makes a difference.
<apw> mck182, i've moved that bug back to Confirmed as you asre still seeing it
<apw> mck182, feel free to add some info there
<mck182> apw: yeah, the mainline 4.5.0 kernel definitely still has it
<mck182> I can share my findings in there, sure
<mck182> if I can remember my login... :P
<mck182> ok done
<martink3> tested the latest xenial iso on a file server featuring a ARC1882 RAID controller - got weird timeout issues.
<martink3> Found out that mailine 4.4 features a buggy arcmsr driver, which "supports" the 1882, but not really... Areca seems to have managed to get a fixed driver into mainline 4.5
<martink3> any chance that the xenial kernel could backport that driver before release? what is the policy for that? it seems to be a small patch on arcmsr.h and arcmsr_hba.c ...
<apw> martink3, file a bug against the linux package, and put the infomration and proposed patches in there, and let me know the bug # here, and i'll get someone to make formal test kernel and if that works we can submit the patches for inclusion
<martink3> will do tonight, thx!
<mamarley> apw: This build took 43m4.491s, though a good half of that it spent building the -dbg package.
<mamarley> Is there perhaps some way I can tell it not to build that particular package?
<apw> yep do_debug=false or something grep for debug in debian/rules
<mamarley> OK, thanks!
<mamarley> Except there is no debian/rules here, I am building the mainline kernel with deb-pkg...
<mamarley> Wait nevermind, there is a debian directory.
<mamarley> But it is very minimalistic and doesn't have anything about debug in it.
<mamarley> It doesn't really matter.  -dbg is the last thing it builds, so I can just kill it after it builds the packages I actually need.
<apw> ahh ok
#ubuntu-kernel 2016-03-19
<kernelbug> problems with bisection...
<kernelbug> what if the kernel is not listed here? http://people.canonical.com/~kernel/info/kernel-version-map.html
<kernelbug> how i'm supposed to map anything then? :)
<kernelbug> i ran mainline-build-one and got errors...
<kernelbug> fatal: invalid reference: Ubuntu-3.18.0-7.8
<kernelbug> vivid-amd64: chroot not found (::,)
<mamarley> apw: So I figured out the cause of my problem.  It wasn't actually a regression in the kernel, it is the "watchdog" service.  If I stop that service, suspend works perfectly.  Odd...
<ogra_> wow
<ogra_> there is an option in /etc/default/watchdog to disable it permanently 
<ogra_> (and please fil a bug too)
<mamarley> I want to try it on another box first to see if it has the same problem there.
<ogra_> good idea
<mamarley> I actually had to add an [Install] section with a WantedBy to get it to work at all, so I am afraid any bug I file would be invalid anyway.
<kernelbug> so? :)
<kernelbug> why errors?
<kernelbug> :<
<mamarley> I just tried another system with the iTCO_wdt device and watchdog enabled.  It does not seem to suffer from the same issue.
<kernelbug> am i ignored or are you just busy? :)
<apw> or perhaps, maybe, it is the weekend?  the first error implies you are not in the appropriate git repo, the second that you do not have build chroots created
<kernelbug> apw, hmm
<kernelbug> apw, maybe it's morning somewhere ;)
<kernelbug> apw, well i followed the instructions
<kernelbug> https://wiki.ubuntu.com/Kernel/KernelBisection
<kernelbug> apw, "HEAD is now at 32ac5b4... UBUNTU: Ubuntu-3.19.0-56.62"
<kernelbug> apw, why 3.19? :)
<kernelbug> well, see you later...
<alkisg> Hi guys, post the 3.2 kernel I'm getting a 10-second delay at boot: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1259861
<ubot5> Launchpad bug 1259861 in linux (Ubuntu) "5-10 second delay in kernel boot" [Medium,Confirmed]
<alkisg> The weird thing is that it happens in some real hardware and under virtualbox, but I was not able to reproduce it under KVM
<alkisg> I'm guessing there's some "wait up to 10 seconds for that event" code somewhere, but how can I pinpoint it to help in solving the issue?
<alkisg> It's Ubuntu specific, I haven't seen it in any vanilla kernels so far
<TJ-> alkisg: does a boot with 'debug' indicate where the delay is by the last messages before the delay?
<alkisg> TJ-: no, I tried with debug and it made no difference in dmesg
<alkisg> And booting with various clients, the messages I see around the delay are not the same
<alkisg> TJ-, it's possible that it happens on your PC as well, you could run dmesg and see...
<apw> alkisg, hmmmm, there must be a pattern
<apw> citainly i do not have a 10s that i can see
<TJ-> alkisg: which exact Ubunt kernel version do you see it on first (after 3.2) - we can go back through the commits from that
<TJ-> alkisg: no, it doesn't happen for me :)
<alkisg> I think that if I run the stock ubuntu live cds in virtualbox, it always happens
<alkisg> So I can test with e.g. 12.04.1 (it doesn't), 12.10, 12.04.2...
<alkisg> Will that help?
 * alkisg has something running in kvm and can't use virtualbox right now, but will try it in half an hour or so when it finishes
<alkisg> One dmesg from 16.04 on some i5, netbooted with LTSP: http://paste.debian.net/417051/
<alkisg> The delay is before the initramfs gets loaded, at 2 => 12 sec
<ogra_> different compressions ?
<infinity> That kinda looks like you have a sleep 10 in your initrd. :P
<infinity> Which would be a local thing (or a weird package), cause I've never seen it.
<infinity> alkisg: rgrep sleep /usr/share/initramfs-tools/ | pastebinit
<alkisg> infinity: the delay is before the initramfs gets loaded
<alkisg> But weird as it sounds, I tried removing the "ip=" parameters from the cmdline
<alkisg> And the delay seems to go away
<infinity> On what are you basing "before the initramfs"?
<alkisg> ip= is normally processed by the initramfs, but in this case it's also causing 10 sec delay before the initramfs
<alkisg> infinity: because the delay happens before e.g. break=top
<ogra_> you mean "before the initramfs writes to logs" ... 
<TJ-> alkisg: have you considered its due to system delays in loading/decompressing the initrd.img, as ogra_ hinted at?
<ogra_> how do you know it doesnt operate 
<infinity> TJ-: No way that machine would take 10s to load an initrd unless it was a several hundred megs.
<ogra_> ... it simply doesnt print for 10sec ... it might as well process something 
<alkisg> TJ-: I think it is indeed because somehow ip=xxx is processed by the kernel (so same initrd and compression methods etc)
<alkisg> Give me 5 mins to check
<TJ-> alkisg: if the mass storage device has bad sectors there may be I/O errors going on
<ogra_> infinity, well, a 25MB xz compressed initrd (typical ubuntu initrd nowadays) on a 600MHz single core CPU can surely take a while 
<ogra_> (indeed this isnt a 600MHz single core :) )
<alkisg> Yup, ip= is what's causing it
<alkisg> So, my test so far is:
<infinity> Indeed.  And it's obviously not the issue if removing cmdline args "fixes" it.
<infinity> Nor is it I/O issues, etc.
<ogra_> yeah
<alkisg> I put break=top. I get to the initramfs prompt in 2 secs.
<alkisg> I put ip=dhcp break=top. I get to the initramfs prompt in 12 secs.
<alkisg> And of course ip= is processed long after "top" by the initramfs
<ogra_> is the NIC driver builtin ? 
<alkisg> No idea, but udev hasn't ran yet at that point...
<alkisg> Let me reboot to see which nic it has
 * ogra_ was more interested in modprobe than udev
<infinity> Indeed, nothing *should* be doing much with IP before break=top
<infinity> But that doesn't stop people from being silly.
<infinity> (note that conf/conf.d is sourced, so one can have code in there, for instance)
<alkisg> I can put a custom init inside the initramfs if that'll help in proving that initramfs isn't to blame
<alkisg> Hmm or I could just not use an initramfs and check the time of the kernel panic
<infinity> Sure, just 'ln sh init'
<alkisg> ogra_: 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c
<alkisg> Stock 16.04, I suppose that's not builtin, right?
<infinity> Or drop the initrd, yes.
<ogra_> right,, not builtin ... 
<ogra_> could be the module loading (or the firmware loading) that slows you down
<infinity> Nah.
<infinity> The modules are loaded after his delay.
<infinity> dmesg is pretty clear on that.
<infinity> I suppose the kernel could be attempting to configure a nonexistent device for 10s, but that seems pretty amazingly silly if it is (and seems like a bug people would have yelled about earlier)
<ogra_> how would ip= work without a network device ?
<infinity> ogra_: The initrd processes it later.
<ogra_> so it times out til it notices there is no NIC yet ? 
<alkisg> So, without initrd. (1) without ip= â kernel panic in 0.58. (2) with ip= â kernel panic in 12 sec.
<alkisg> I think that rules out the initramfs issues
 * alkisg tries various ip=xxxx parameters, to see if "none" or something bypasses it...
<infinity> It's entirely possible the kernel is blocking with ip=dhcp because there's no interface yet, but man, that seems braindead.
<alkisg> There's a way to have the kernel assign an ip
<alkisg> It needs some CONFIG_XXX lines and the module to be included
<alkisg> But those aren't there by default in Ubuntu kernel builds
<TJ-> net/ipv4/ipconfig.c is responsible for processing the "ip=" internally, dhcp is going to result in a delay if the DHCP server doesn't respond. Have you tcpdump-ed the network link?
<infinity> TJ-: The dhcp server can't respond, there's no interface. :)
<infinity> (nothing to tcpdump)
<alkisg> TJ-: and also in my initial try, I was putting a static ip=x:x:x:x: there, that too caused a delay
<alkisg> (IPAPPEND 3 in pxelinux)
<TJ-> infinity: that'll not help :)
<ogra_> just go for https://sourceforge.net/projects/ubuntubsd/ ... i heard BSD is a lot better for network stuff *g*
<alkisg> Haha
<TJ-> alkisg: try enabling dynamic debug during boot for the ipconfig handler to begin with:   ... "ddebug_query=file net/ipv4/ipconfig.c +pflm" ...
<alkisg> TJ-: I just put that part in the cmdline? Thanks, trying...
<TJ-> alkisg: depending on the age of the kernel that may need some modification since things have changed alot with both the key and the pr_debug call sites
<alkisg> Stock 16.04, vmlinuz-4.4.0-14-generic i386
<alkisg> Linux 4.4.0-14-generic #30-Ubuntu SMP Tue Mar 15 13:02:52 UTC 2016 i686 i686 i686 GNU/Linux
<TJ-> ok, you may need to replace 'ddebug_query=' with 'dyndbg='
<TJ-> see Documentation/dynamic-debug-howto.txt for more detail
<alkisg> I tried both, but I didn't see any changes. Would I be seeing more output in the screen, or does it go to some internal files e.g. under /sys, /proc or whatever?
<TJ-> you will see it in the dmesg output
<alkisg> Nothing there... are you sure that's the correct file? Isn't that from klibc which goes inside the initramfs? Is that same file included in the kernel as well?
<TJ-> there are a lot of pr_debug() sites in ipconfig.c so if you've set "ip=dhcp" i'd expect to see something. I seem to recall the kernel will stop processing the options after a "--" so make sure its before that if it occurs
<TJ-> net/ipv4/ipconfig.c is the source file where the code for 'ip=' lives
<alkisg> I have ip=some:static:ip, and no "--"... I'll try with ip=dhcp as well
<TJ-> it is possible, if there's no network device, that code never gets called. in which case you'd need to identify which part of the code is responsible for 'looking' for network devices and looking for pr_debug() call sites there, then putting them on the command line as well
<alkisg> No difference with ip=dhcp.
<alkisg> The good thing is that now it's very easily reproducible
<alkisg> Anyone can just put ip=dhcp in his cmdline and reproduce it
<alkisg> (maybe not in kvm though, maybe the kernel handles virtualized networking differently)
<infinity> alkisg: VIRTIO_NET is builtin on that kernel.
<infinity> alkisg: Which helps the argument that the kernel is blocking when there's no device to configure.
<alkisg> Looks like it... there are also several timeouts in ipconfig.c that may match what I'm seeing
<alkisg> ip=none doesn't cause the issue
<alkisg> ip=10.161.254.61:10.161.254.11:10.161.254.1:255.255.255.0:pc61::none does cause it
<TJ-> alkisg: you might want to add to that existing dyndbg this: ... "; file drivers/net/virtio_net.c +pflm"...
<alkisg> Thank you TJ-, trying...
<TJ-> basically, in the source tree once you identify a location (in the built-in source at this point) do a "git grep 'pr_debug' path/to/files" to see if there are dyn-debug sites to make use of
<alkisg> I think that I will need to debug ipconfig.c though, and that only has "ifdef IPCONFIG_DEBUG" there, no pr_debug...
<alkisg> And since the driver is realtek, I'm not sure that debugging virtio will help
<alkisg> Maybe all that means I'll have to build the kernel myself, while setting IPCONFIG_DEBUG there? :-/
<alkisg> Virtualbox with virtio instead of intel nic emulation, doesn't have the delay
<alkisg> (it takes 3 minutes to load the kernel/initrd via the network with virtio under vbox, but ok that's completely unrelated, it just makes debugging that way suck)
<alkisg> Hrm, I can't see any debug messages with virtio either
<alkisg> So yesterday booting LTSP clients in 16.04 took 45 seconds, now with this and 2 other delays I got rid of caused by the initramfs, it got down to 20 seconds :)
<kbug> anyone awake? :)
<kbug> still issues with the bisection...
#ubuntu-kernel 2016-03-20
<martink3> apw: finally got around to file #1559609 regarding arcmsr timeouts with ARC1882 RAID controllers... hope the bug report is useful enough to get things going
<alkisg> I'm continuing trying to troubleshoot https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1259861
<ubot5> Launchpad bug 1259861 in linux (Ubuntu) "5-10 second delay in kernel boot" [Medium,Confirmed]
<alkisg> My plan is to do a small bisection by using the kernels from the mainline ppa, and see when it broke
<alkisg> It was after 3.2 and before 3.8, I'll pinpoint it better in a while
<alkisg> Then I'm planning to compare the configs of those two kernels, because I'm thinking it might be a config issue and not a source code (ipconfig.c) issue that caused it
<alkisg> If you guys have some better suggestion, please ping me :)
<alkisg> Erm, do the mainline ppa kernels use a different config from the ones shipped in the ubuntu archives + live CDs?
<alkisg> Trying with Ubuntu 12.04 and the stock kernels,
<alkisg> 3.5 does not have the issue, while 3.8 does
<alkisg> So the problem was somewhere after Ubuntu 12.10 and before 13.04
<alkisg> I'll compare the configs now
<alkisg> 3.5: # CONFIG_IP_PNP is not set
<alkisg> 3.8: CONFIG_IP_PNP=y
<alkisg> CONFIG_IP_PNP_DHCP=y
<alkisg> Is it reasonable to ask that to be reverted?
<alkisg> Also, can I find the Ubuntu config commit for that, so that I can read the reasoning behind it?
<alkisg> E.g. maybe it's needed for some ARM devices, if so it could be conditionally enabled only on those arches...
<alkisg> I think this is the relevant upstream commit: https://github.com/torvalds/linux/commit/c1b362e3b4d331a63915b268a33207311a439d60#diff-364c3610ebc6899c22148ba10636c71c
<alkisg> So, Ubuntu and openSUSE have CONFIG_IP_PNP=y and experience the issue
<alkisg> Debian and Fedora don't have it
<apw> alkisg: put that info in the bug, needs thinking about indeed
<alkisg> apw, I did put it
<alkisg> Thank you :)
<apw> ok so the real issue is that the initramfs and kernel option overlap
<alkisg> Well, it's the same option, it can be handled in 2 places
<alkisg> So if the kernel was smart enough to avoid the delay if it can't initialize the NIC, all would be fine
<alkisg> Or if the Ubuntu kernel didn't include CONFIG_IP_PNP/ipconfig.c when it doesn't need it
<alkisg> (does anyone need it? or was it put there by just copying the new upstream kernel defaults?)
<alkisg> I think it would be best to unset CONFIG_IP_PNP in Ubuntu, like Debian and Fedora do, and also report the ipconfig.c issue upstream to the kernel, to be fixed by whoever maintains it, without any hurry...
<apw> it would likely sound useful and get enabled
<alkisg> I imagine that it's only useful when the modules are built-in, so if someone is building their own kernel, they may as well set CONFIG_IP_PNP themselves...
<alkisg> Now it would only be useful in virtio environments, right? (and I'm not sure if all the NFS support is configured...)
<alkisg> ogra_: have you ever needed to netboot any boards without using an initramfs? I.e. has CONFIG_IP_PNP=y ever been useful to you?
<alkisg> (it's causing 10 sec delay to ltsp clients)
<ogra_> no, never
<alkisg> Ty :)
<ogra_> which doesnt mean there are no people using it like that indeed
<alkisg> Sure, but if we can't find anyone, maybe it'd be better to disable it like other distros do
<alkisg> Our initramfs now is close to 40 MB, it doesn't help to include all options...
<ogra_> iirc (apw might remember better) there was once a task "make ubuntu bootable without initrd" ... not sure if that has ever been mandatory or was just a nice-to-have thing 
<alkisg> And I'm not sure it even works; I put ip=dhcp under kvm, with virtio drivers built-in, and it does nothing
<ogra_> well, i'm pretty sure our cloud setup uses it that way
<alkisg> Without an initramfs?
<ogra_> no
<ogra_> kvm based netboot
<alkisg> The clould setup doesn't use an initramfs?!
<ogra_> (with initrd, but it surely does more than nothing ;) )
<alkisg> When an initrd is present, the ip=xxx and other netbooting options are handled there...
<ogra_> right
<alkisg> So the cloud people don't need CONFIG_IP_PNP either
<ogra_> oh, you meant you used kvm without initrd and virtio builtin 
<alkisg> I'm just trying to see if CONFIG_IP_PNP actually works or if anyone's using it, because if it doesn't, the easiest solution would be to disable it
<alkisg> (it is disabled in other distros and it was disabled up to 12.04.1)
<ogra_> if you are lucky there is some papertrail about why it was enabled
<alkisg> ogra_: https://github.com/torvalds/linux/commit/c1b362e3b4d331a63915b268a33207311a439d60#diff-364c3610ebc6899c22148ba10636c71c
<alkisg> I think we just followed hpa's upstream commit
<ogra_> thats more like 8.10 though
<ogra_> quite old
<tjaalton> xenial server image doesn't support usb keyboards? that's a surprise :)
<ogra_> if we had it disabled til 12.04 it sounds like some decision on your side
<ogra_> tjaalton, yeah, convergence ... its all touchscreen or nothing now :P
<tjaalton> bummer
<apw> ogra_, we did a full review and enable a lot of stuff, so it may not have been a specific decision on that option as much as part of a general cleanup
<apw> but if the initramfs does this and does it better, we may well be wrong in having it enabled
<ogra_> apw, well, thats the decision i mean5t then ;)
<ogra_> if we know it just came in with housekeeping it is easy to decide to disable it again 
<alkisg> Note that we still have CONFIG_IP_PNP_BOOTP and CONFIG_IP_PNP_RARP unset, which is different from upstream, so yup some thought went into that
<alkisg> Is there a bazaar branch for the kernel config, where we could pinpoint that commit and read the commit message?
<ogra_> has always been kernel.ubuntu.com i think 
<alkisg> apw, comparing upstream with our config, I see e.g. CONFIG_E1000=y in upstream while CONFIG_E1000=m in ours. Same for realteks and other common NICs.
<tjaalton> trying to install a gen8 hp microserver, 1404/1510 images just have syslinux output "boot error", and xenial has no usb.. oh well
<alkisg> apw, so I don't think CONFIG_IP_PNP helps us if we don't also include those...
<apw> alkisg, yep, and if one is not building those in, it is likely IP_PNP is an error, especially as initramfs will sort them out
<alkisg> apw, cool, who do you ping to remove it? could you do it? I can do whatever tests are needed... :)
<alkisg> *do we
<apw> alkisg, oh i have the power, i need to think about it and check feature parity
<apw> remind me of the bug #
<alkisg> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1259861
<ubot5> Launchpad bug 1259861 in linux (Ubuntu) "5-10 second delay in kernel boot" [Medium,Confirmed]
<apw> that is confirmed as "with kernel command line ip= option
<apw> right ?
<alkisg> Right
<apw> and i think it is also confirmed as a 12s delay 
 * apw fixes the title
<alkisg> It's from 2 to 12
<alkisg> So maybe it's 10
<alkisg> I don't know if it's started at 2 or at 0 though (in which case it would be 12)
<alkisg> Maybe it's this one:   #define CONF_CARRIER_TIMEOUT	120000	/* Wait for carrier timeout */
<apw> anyhow, its all about feature parity, if initramfs-tools does more than the kernel we are good we can just wack the option
<apw> if not we may have to get more creative
<alkisg> initramfs-tools certainly does more than the kernel
<alkisg> It also supports other protocols that the kernel doesn't, e.g. NBD
<ogra_> only if you have the module 
<apw> alkisg, yeah its if it does less in any way that someone could be using
<ogra_> (i dont think it is there by default)
<apw> that is really the only thing that matters
<alkisg> AFAIK the initramfs ip= handling is in all cases superior to the in-kernel ip= handling
<alkisg> The only case that I imagine someone would prefer the in-kernel one, is if he didn't use an initramfs at all
<alkisg> apw, thank you for working on this
 * alkisg waves, later...
<TJ-> for reference, that change to the common config was introduced by 3166c8772 in March 2010
<TJ-> (for Quantal)
<TJ-> before that it was only used for armhf highbank arch
<TJ-> correction, 301b4bb in 13.10 (Saucy)
<tjaalton> 14.04 desktop works on ths microserver, so there must be some usb diff with server/desktop kernels that cause non-working usb with server image.. and I'm not the only one it seems
<tjaalton> is usbhid included in base kernel?
<tjaalton> doesn't look like it
<tjaalton> https://blog.al4.co.nz/2014/12/ubuntu-14-04-no-usb-keyboard-after-upgrading-kernel/
<tjaalton> so that's why 14.04.1 works and newer ones don't
<tjaalton> filed a bug
<apw> tjaalton, whats the number ...
<apw> tjaalton, that blog post says that a server won't work without linux-image-extra which is correct
<apw> tjaalton, -extra is for hardware support essentially, beyond what is in a virt image
<apw> alkisg_away, ok ... i think i can see no reason to not turn this off for sure in xenial, so i have done that for the first upload after beta
<apw> alkisg_away, if that does not throw regressions then we can consider it for sru, do remind me in a week or so
<alkisg> apw, thanks a lot, I'll do so
<apw> that means it will be off in linux-lts-x in trusty as well when that propogates back, so not the next one but the one after
<alkisg> Will it reach even precise-lts-trusty in the long run?
<tjaalton> apw: so server image has -extra too? then my bug description is all wrong :)
<apw> tjaalton, yes, we only have linux-generic and linux-virtual, servers use linux-generic
<tjaalton> ok
<apw> the only way to install akernle without linux-image-extra and get updates is to use linux-virtual
 * alkisg managed to get down the 16.04 ltsp client boot process from 45 seconds to 12 seconds, same as in 12.04... there were 4 unrelated timeouts involved :)
<apw> linux-server points to linux-generic
<apw> alkisg, nice
<tjaalton> bug 1559692
<ubot5> bug 1559692 in linux (Ubuntu) "usbhid missing from main kernel package" [Undecided,Incomplete] https://launchpad.net/bugs/1559692
<tjaalton> hehe
<tjaalton> can't update it right now
<tjaalton> if there's something to try on cmdline i'll give that a go later
<apw> tjaalton, are you saying the live desktop images work ok for xenial images but d-i ones do not ?
<tjaalton> apw: i didn't try xenial live, had only trusty available
<apw> it is more likely that there is something missing from a udeb if live works and server images not
<apw> but we'd want to compare liek with like
<apw> xenial live with xenial server
<tjaalton> sure, that's what i'll test next
<tjaalton> in about six hours from now :)
<martink3> bug 1559609
<ubot5> bug 1559609 in linux (Ubuntu) "arcmsr times out with ARC1882 RAID card" [Undecided,Confirmed] https://launchpad.net/bugs/1559609
<martink3> apw, this is the bug I filed upon your suggestion
<apw> martink3, is that the one where there is a couple of small 4.5 ocmmits which might make it work ?
<martink3> yes, exactly. it should be sufficient to take the 4.5 commits regarding arcmsr.h and arcmsr_hba.c, and then it should work.
<martink3> I was about to try to see if the current xenial kernel compiles with just these two changes, but then I had some dependencies issues for the build chain. I am trying it again using a recent xenial to build a -test1 with those changes
<apw> martink3, i should be able to make you a test kernel if you can test it
<martink3> apw, happy to do so!
<apw> martink3, that (btw) is not two changes, that is the diff from v4.4 to v4.5 for those two files, which is 6-8 changes
<apw> martink3, kernels will be here in a few mins, they are pushing now -- http://people.canonical.com/~apw/lp1559609-xenial/
<martink3> apw, you are right. I didn't see it this way, but you are right, it's a couple of driver versions higher in areca's version numbering scheme, and they (areca) had some trouble getting anything accepted in mainline for some time
<apw> upstream always resists, it is their job
<martink3> I agree, and the driver became more readable, too
<martink3> apw, I think all files arrived now, I will get them now...
<apw> martink3, still pushing -extra, don't be fooled
<apw> martink3, and you only need the arch you are, i386 or amd64
<apw> likely just linux-image and linux-image-extra for that arch
<apw> ugg my uplink sucks today
<martink3> but for downlink, traffic is no consideration, right? If so, then I will just wget your whole lp1559609-xenial/ folder ...
<apw> martink3, you can hammer my fileserver all you want
<apw> the amd64 bits look complete, i386 -extra is still pusin
<martink3> amd64 is what I need. will try it in a virtual machine first, and then I hope I can get my hands on one of the real fileservers soon for this test
<apw> martink3, push complete
<apw> martink3, please report your testing in the bug, and let me know here you did so
<martink3> apw, got the files, will do, thanks so far!
<lamont> jsalisbury: updated 1543863 for our sadness
<apw> lp: #1543863
<ubot5> Launchpad bug 1543863 in phpmyadmin (Ubuntu) "package phpmyadmin 4:4.0.10-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/1543863
<lamont> apw: also, I fail at typing bug numbers
<lamont> lp: #1543683
<ubot5> Launchpad bug 1543683 in linux (Ubuntu Xenial) "Fails to detect (second) display" [Medium,Fix released] https://launchpad.net/bugs/1543683
<lamont> yeah that one
<lamont> jsalisbury: 1543683 that is
<tjaalton> apw: confirmed, xenial desktop image has working input devices and server doesn't
<apw> tjaalton: ack could you update the bug to that effwct pls
<tjaalton> done
<tjaalton> i checked the obvious udebs and they look fine
#ubuntu-kernel 2017-03-13
<emk2203> HOW and WHERE do I file a bug in the latest ubuntu mainline kernel 4.11.0-041100rc2-generic, which was not present in 4.10.0-041000?
<tjaalton> kernel bugzilla?
<apw> emk2203, they are mainline so if it is a functaionality bug, probabally in the upstream bugzilla
<apw> emk2203, things are often in early -rc2 and get resolved before we have to take the kernel
<lamont> Apparently the HP Proliant DL20 has a 361T dual port nic, which I'm told needs a HP-provided binary-blob driver to do what $PERSON wants... anyone know aanything about that?  They say that RHEL and SUSE drivers are available from HP
<emk2203> apw, thanks, I monitor the coming rcs then. But it's fairly major - loss of my external USB devices with this kernel.
<bjf> lamont, i don't know about that. do you have a particular series that you are looking for support in?
<lamont> bjf: not actually sure... Let's go with 16.04 as a stake in the ground.  It's supported in 16.04, but it would seem that $PERSON does bleeding-edge things that the provided-by-ubuntu driver doesn't support.  (No further details on what)
<bjf> ogasawara, ^
<ogasawara> bjf, lamont: ack, thanks.  I'm trying to chase down an HP contact who would hopefully have more info for us.
<lamont> ta
#ubuntu-kernel 2017-03-17
<cyphermox> fyi; https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1673350
<ubot5> Ubuntu bug 1673350 in multipath-tools (Ubuntu) "dm-queue-length module is not included in installer/initramfs" [Critical,Triaged]
<cyphermox> not sure who to assign this to, but I would need dm-queue-length added to multipath-modules
<smb> cyphermox, I thought there was some talk about that for s390x... 
<smb> cyphermox, ok, I assigned myself and added yakkety. likely should do the udeb changes there as well
<xnox> smb, there was this s390x ticket https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1634161
<ubot5> Ubuntu bug 1634161 in multipath-tools (Ubuntu) "Default multipath policy is round-robin, shows considerably worse read throughput compared to using service-time" [Low,Confirmed]
<xnox> smb, if you can include service time modules into udeb that would be nice for that ticket.
<smb> xnox, Ah could not remember the number but yes service-time now is in the list and I just sent a patch to add queue-length as well
<smb> That should be all known ones
<smb> xnox, so service-time was added since xenial (or should be, I did not look at the udeb, only the file that should create it)
<xnox> ack, let me look at the build-log and the .udeb contents files. one sec.
<smb> xnox, -rw-r--r-- root/root     10158 2017-03-08 20:06 ./lib/modules/4.4.0-67-generic/kernel/drivers/md/dm-service-time.ko
<xnox> yeap looking sexy.
<xnox> cyphermox, would you be able to change defaults to service-time? https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1634161
<ubot5> Ubuntu bug 1634161 in multipath-tools (Ubuntu) "Default multipath policy is round-robin, shows considerably worse read throughput compared to using service-time" [Low,Confirmed]
<xnox> in multipath-tools, or shall i?
 * xnox is not sure if we should be doing this this close to release.....
<apw> xnox, i doubt anyone will have specific testing before now using the existing default, it is a pretty nieche thing
<xnox> apw, what do you mean? as far as I understand upstream multipath-tools default is service-time; yet we switch to round-robin. And there is some tests/benchmarks done in the bug report indicating that service-time is better.
<xnox> so which testing are you referring to?
<xnox> as in testing service-time to make sure it is better?
<smb> xnox, apw I would think that the mainframe people have a good history of using dm-queue-length (initially at least) or dm-service-time. Those both would generally be better handling variations in IO time on different paths. While round-robin dumbly switches every 1000 requests
<apw> or testing it either way
<apw> i mean changing is not so bad imo
<smb> Yeah I would not really expect too horrific issues
<smb> IIRC it should be possible to change the balancer even post-installation via multipath.conf...
<xnox> correct. but we should use sane default
<cyphermox> xnox: I'll look at it, there's another fix I need to do in multipath-tools anyway
<cyphermox> ah, I see
<cyphermox> yeah, it was round-robin only because service-time wasn't available in wily
<xnox> i think consensus above it to just drop the patch; such that we use the upstream default of service-time by default. it is in udebs at least in xenial-release and up.
<cyphermox> yup
<cyphermox> the fact that it's still round-robin instead is a bug
<cyphermox> I'll fix this while also fixing queue-length
<cyphermox> smb: does dm_emc still exist anywhere?
<cyphermox> (IIRC it doesn't, but trying to make sure)
<smb> cyphermox, hm... don't think so... though maybe you mean the device handler... give me a sec
<smb> cyphermox, scsi_dh_emc.ko
<cyphermox> nah, really "dm-emc"
<cyphermox> it used to be a module, and I think I removed it in d-i already
<smb> cyphermox, cannot even remember that
<cyphermox> yep
<cyphermox>     - Remove dm-emc from the multipath modules, since it's gone since
<cyphermox>       2.6.27.
<cyphermox> if I didn't lie when I wrote that
<smb> heh
<smb> cyphermox, though I really think that if dm-emc was multipath related then it likely was what scsi-dh-emc is now (and those are at least in scsi modules)
<cyphermox> yup, I agree
<cyphermox> the SRU for service-time is going to be yucky
<cyphermox> xnox: fyi, will upload in a minute just being careful and building locally first.
<xnox> cyphermox, why would SRU for service-time be yucky? no change to kernel or udebs.... just a flip of default.
<cyphermox> yeah, a flip of default which will flip running systems.
<cyphermox> ie. you could get better throughput or explosions.
#ubuntu-kernel 2018-03-12
<jmux> klebers: I saw you applying SRU patches to Xenial/backlog.
<jmux> klebers: My SRU is from the beginning of February, so I wonder, if it was missed: https://lists.ubuntu.com/archives/kernel-team/2018-February/089892.html (lp#1745130)
<klebers> jmux, hi. We are still going over the backlog of patches from the mailing list and we will review it for inclusion on the SRU cycle starting this week.
<jmux> klebers: Ok. Thanks.
<BitByBit> Hello to all, please give a hint. I think I miss something in the kernel configuration. Im integrating a qmi interface for a modem. I use libqmi to control the interface. When I try to get or set data format I get error whatever I do. I think I miss a module. could you help?  
<BitByBit> This is the error I get.. Us this related to a missing module in the kernel? error: cannot get expected data format: Expected data format not retrieved properly: Failed to open file '/sys/class/net/wwan0/qmi/raw_ip': No such file or directory
<apw> have you confirmed the module has autoloaded for the device ?
<BitByBit> apw, thanks for answer. Sorry could you help me to see how to check this?
<apw> lsmod would show your module loaded
<BitByBit> I get any answer
<BitByBit> I have to say that this is an ARM kernel.. I don't know if this could influence the behavior 
<apw> not sure i know what you are telling me, are you saying lsmod says nothing, or that your module is not listed
<Moral_> BitByBit: lsmod | grep qmi 
<Moral_> or w/e the module name is instead of qmi
<BitByBit> Moral_, sorry but no module ar showed, only the header. I think this kernel doesnt have this feature
<apw> BitByBit, then you do not have the module loaded ?
<apw> if you are building your new bit as a module then you might need to modprobe the module
<BitByBit> I boult the kernel from source using make menuconfig and compiled with the suggested ARM copiler.
<cascardo> BitByBit: you should go to #kernelnewbies on OFTC
<cascardo> you should find better help on kernels you built yourself there
<BitByBit> cascardo, ok.. thanks for suggestion.
<cascardo> BitByBit: make sure you have CONFIG_USB_NET_QMI_WWAN in your config
<BitByBit> cascardo, Ok I will verify, but I'm sure that in menuconfig I enabled all the requested features
<BitByBit> cascardo, CONFIG_USB_NET_QMI_WWAN=y
<BitByBit> Let see I just compiled the kernel and I got the image. Is there a way to see if the module is present in the image?
<cascardo> BitByBit: if you've enabled /proc/config.gz, you can check in there
<zyga-ubuntu> hey, my system just crashed
<zyga-ubuntu> how can I report a kernel bug with meaningful debug?
<zyga-ubuntu> I see this in my journal
<zyga-ubuntu> https://www.irccloud.com/pastebin/He7J19GJ/
<zyga-ubuntu> this is from journalctl -b -1 (last boot)
<AlexAvadanii> zyga-ubuntu: https://wiki.ubuntu.com/Kernel/Bugs
<zyga-ubuntu> thanks
<zyga-ubuntu> trying
<zyga-ubuntu> reported as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755270
<ubot5`> Ubuntu bug 1755270 in linux (Ubuntu) "Linux crashes when using network sharing over usb-c to iPhone 6s" [Undecided,New]
<AlexAvadanii> I joined this channel to ask when hwe-edge will switch to 4.15 in Xenial. not sure I want that now :)
#ubuntu-kernel 2018-03-13
<juergh> klebers, if I'm not mistaken the master-next-backlog branch is now fully merged into master and/or master-next for xenial, right?
<klebers> juergh, for xenial yes
<klebers> juergh, for the other series we'll be doing it during this week 
<juergh> klebers, ack
#ubuntu-kernel 2018-03-14
<xcyclist> Ubuntu kernel builds appear to put out a bunch of stuff, .deb files, .udeb files, and a .tar.gz file, that I don't see specified in a document accurately.  Is there a document I SHOULD  be reading, or can I help updating one that is old?
<xcyclist> I have been using https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, and for instance it says I should see 3 .deb files instead of dozens of files.
<xcyclist> Please advise how I can be most helpful in either asking a question, reading other documents, or updating inaccuracies.
<xcyclist> I apologize.  I lost my connection.
<juergh> xcyclist, running 'fakeroot debian/rules binary' (from the wiki page you reference) simply does a build of the binary packages for your currently running architecture (which results in 3 debs). A full official build will result in a whole lot more packages: binaries for all the supported architecture, indep packages, source package, ...
<apw> udebs for the installer and for x86 a signing tarball
<tjaalton> sforshee: ping bug 1752507
<ubot5`> bug 1752507 in linux-firmware (Ubuntu Artful) "add i915/glk_dmc_ver1_04.bin" [Undecided,New] https://launchpad.net/bugs/1752507
<thresh> hello.
<thresh> I'm on 4.13.0-36-generic, backported to 16.04, and see this crash/lockup ocasionnally: http://thre.sh/stuff/v05.crash.txt
<thresh> does that sound similar to something already known?
<sforshee> jjohansen, tyhicks: either of you have any ideas about this? https://paste.ubuntu.com/p/JBHVsV9SsZ/
<sforshee> it's happening during adt, but only on ppc64el
<tyhicks> sforshee: hey - what's being tested when that's happening?
<sforshee> tyhicks: I don't think we know, cascardo?
<cascardo> I am not sure, but it might be apparmor
<tyhicks> that sounds reasonable
<cascardo> or something way before that, cause we don't know exactly when it starts
<tyhicks> it looks like something is testing/fuzzing the /proc/<PID>/attr/current interface
<sforshee> the audit backlog messages start about 1.5 minutes later, possibly these two things aren't related
<tyhicks> the "AppArmor: change_hat: ..." messages don't go through the audit subsystem
<tyhicks> so they're unrelated in the sense that they're not causing the audit backlog issue
<tyhicks> but it is still possible that AppArmor is generating the audit messages that are causing the audit backlog issue
<cascardo> I would disagree
<cascardo> [121737.681674] audit: type=1400 audit(1520969595.539:16276): apparmor="DENIED" operation="setprocattr" info="current" error=-22 profile="unconfined" pid=7572 comm="bash"
<cascardo> but, yeah, I also agree that might be a red herring
<tyhicks> cascardo: to be clear, I suspect that something is testing apparmor and apparmor is generating a bunch of audit messages
<tyhicks> what problems is it causing? is the testbed failing because of this?
<sforshee> tyhicks: the test does fail, we're not sure that it's related to all of those messages but it's one of the few leads we've got right now
<sforshee> rather the vm seems to get hung somehow
<sforshee> but I'm also now suspecting that it may be that a test is trying to suspend/resume the vm and that it's dying there
<tyhicks> neither of those sets of error messages (the ones from AppArmor nor the ones from audit) indicate a dire situation that would take the vm down
<tyhicks> they're error conditions for sure but they're handled error conditions
<sforshee> ok, thanks tyhicks
<cascardo> from my little experience with autopkgtest, sometimes the backend will look for the login prompt on the console
<cascardo> and I thought that was the problem, that so many errors on the console would prevent it from finding it
<cascardo> but maybe the nova backend is not that broken
<tyhicks> that's possible
<tyhicks> I'd argue that the apparmor error message is mostly useless and should go away
<tyhicks> the audit message is important and can't go away
<tyhicks> so, getting a clear console might not be possible
<cascardo> that's okay
<cascardo> I think the problem here is how it would generate that so many messages in that small amount of time
<cascardo> when trying to sigstop auditd, I couldn't get that to happen even when writing to attr/current in a loop
<tyhicks> huh, why is auditd running in the VM?
<tyhicks> that's surprising to me
<cascardo> I got a slightly different behavior as well, a "lost" message as well
<cascardo> ah, I am not saying it was
<tyhicks> oh, I see what you're saying
<cascardo> that's just the only thing I thought would have caused those backlog messages
<cascardo> like: there need to be an open auditd socket, right?
<tyhicks> the audit subsystem forwards to the syslog when an auditd hasn't registered itself with the kernel
<tyhicks> that's the default configuration on ubuntu
<tyhicks> I would expect that the test runners would be in that configuration (auditd isn't installed by default)
<cascardo> but how does it forward that? by the kernel log/printk only?
<tyhicks> yeah, forwarding is in-kernel
<cascardo> okay, so I got that same TAP13 message as from the ADT log
<cascardo> right after running the step_after_suspend_test
<cascardo> and my VM can't respond anymore
<cascardo> what is supposed to be waking it up, by the way?
<cascardo> and nothing seemed to have changed on that test, either from our last kernel or on the testing repos
<cascardo> more likely, we broke suspend on ppc
<apw> or worse we made it do something, and the wake up does not work
<apw> i have this odd feeling we don't run those in adt in some sense
<cascardo> I could just test it with the older kernel and see how it behaves
<apw> yeah, the problem is we modify the kernel self tests etc to turn them off, and that can stop working
<apw> has done before
<cascardo> just have to set it up all over again, cause this openstack is broken
<cascardo> I looked it up, we didn't just turn it on again recently
<cascardo> so, it should have been running before
<cking> hrm, i'm confused, I was sure it was disabled for x86
<apw> cking thinks we haven;t turned it back on
<apw> well this is ppc which is breaking on suspend
<cking> maybe I'm mistaken, a lot changes around here
<apw> so i am suspicious we should not be running it there either
<apw> as an unrelaible to wake up test
<apw> in a VM environment
<cking> it maybe that the RTC wakeup is broken in a VM, or it the RTC wakeup is too short, or a bunch of other reasons
<cascardo> hum... it was commented out on 4.15.0-10.11
<cascardo> and clone didn't work on 4.15.0-11.12
<sforshee> from a previous log which did run to completion, I don't see that test being run
<sforshee> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/linux/20180221_002951_88802@/log.gz
<cascardo> okay
<cascardo> that file has changed
<cascardo> and the sed line is not working anymore
<cascardo> it's not a += anymore, it's a :=
<sforshee> \o/
<cascardo> I am fixing that on the testsuite, then will retrigger it
<sforshee> awesome, thanks cascardo 
<cascardo> gotta make sure I write something that will work on new and old kernels
<cascardo> thank you for making me look past the audit backlog thing
<tyhicks> nice!
<cascardo> now, let's hope the only problem we see is the kallsyms one
<juergh> apw, can you please accept the nomination for #1755817?
<cascardo> juergh: approved
<juergh> cascardo, thanks
<xcyclist> Thank you juergh.  Is there a document with the taxonomy of the different build combinations, both setups, and product files?
 * apw doubts we have anything that detailed ... the intent of packages is one thing and one thing only to build in the defined debian/ubuntu build environment
<sforshee> cascardo: your ppc64el retry finished, the only failure is the expected kernel_symbols_missing
<sforshee> I'll add a hint for that, then we should be in good shape to promote
<sforshee> apw: the testing for our bionic kernel is all in order but it looks like we need to clear NBS
<apw> sforshee, i think i did that already, about 15:30 my time
<apw> but as it is 17:50 i am suspicious
<sforshee> apw: the adt matrix still shows it is NBS
<apw> sforshee, hmmm, should be resolved there soon, cirtainly britney is now showing it only held by the bug
<sforshee> ack, ta
<cascardo> sforshee: thanks!
#ubuntu-kernel 2018-03-15
<apw> cking, yo ... zfs ... specifically zfs-dkms looks to have a Recommends of zfs-dkms which is trying to pull that into main, i suspect ti should be a Suggests: as we have it in kernel
<cking> apw, ah, good catch, I'll fix that
<Slashman> hello, I have an issue with the HWE kernel for xenial "linux-image-4.13.0-37-generic", it's freezing my server some minutes after the boot, is this a known issue?
<Slashman> no issue with 4.13.0-32-generic
<apw> Slashman, hard hangs which are reapeatable, i'd not say that was something i at least am aware of
<TJ-> Slashman: have you tried disabling the spectre and meltdown fixes? "nospectre_v2" and "nopti" 
<TJ-> apw: We've seen a few recently reported in #ubuntu but as it's a freeze there's very little in the way of evidence
<Slashman> I'll try to disable the spectre and meltdown fixes
<rbasak> There's bug 1746806 which I think is a current reported hard hang.
<ubot5`> bug 1746806 in linux-aws (Ubuntu) "sssd appears to crash AWS c5 and m5 instances, cause 100% CPU" [Critical,In progress] https://launchpad.net/bugs/1746806
<apw> rbasak, i thought that one exposed as an ssshd burning cpu and not doing its work
<rbasak> apw: 100% CPU reported via the host AIUI, but still a hard hang.
<apw> Slashman, also you say -32 is good, have you tried any of the ones between that an -37 ?  there is definatly a -36
<apw> rbasak, i know someone or other is looking at that one
<Slashman> TJ-: I'm on 4.13.0-32-generi currently and all spectre and meltdown are already in: https://paste.ubuntu.com/p/zGCqvwsPzb/
<apw> Slashman, there is also a -38 in -proposed which is worth confirming is also broken
<TJ-> Slashman: right, I'm suggesting you *turn it off* to find out if those fixes are causing the issue
<Slashman> apw, I have -36, I can try that, but I can't test everything, the server take some time to reboot and I will need it online and running
<apw> Slashman, a problem indeed if you don't have a devleopment environment to test updated before deployment
<Slashman> TJ-: is there any launchpad report about a similar issue so I can look if it's similar?
<TJ-> Slashman: you can search for 'freeze' but that's so generic I doubt it'll be helpful
<apw> Slashman, in a perfect world you would be trying to get a crashdump off the box
<apw> i am sure that is what support would recommend in this case
<Slashman> hm, I think the issue may be related to a BIOS update in the end, I'll test with a rollback of the BIOS
<apw> Slashman, what is in the new bios update 
<Slashman> one sec
<apw> i hope that isn't the new supposedly ok intel microcode
<Slashman> The syslog/dmesg shows this multiple time: https://paste.ubuntu.com/p/SxTjMbCR5T/
<apw> that is -32 which is 'ok'
<Slashman> that's microcode from intel indeed...
<Slashman> http://www.dell.com/support/home/en/us/frbsdt1/drivers/driversdetails?driverId=NMF8F
<Slashman> apw: those fuckers, is there any source I can send to dell with the issue that the microcode update does?
<cking> apw, re the zfs-dkms recommends, I can't see what you are referring to in the kernel (as I was just cross referencing what you said about the Suggests in the kernel package)
<apw> cking, i am referring to the Recommends present on zfsutils-linux (i think it is) which is pulling zfs-dkms into main
<cking> apw, gotcha
 * apw watches the auto test-builds suffer because of our recent -backlog policy
<apw> and worse i cannot fix the worst egregious issues without the queue draining
<prophecy04> hello.  I was wondering if I can get some help with understanding the kernel to my system better
<Slashman> TJ- , apw: postmortem: it was the BIOS with the intel microcode, latest kernel works perfectly with the rollbacked BIOS, thanks for your help
<TJ-> Slashman: Ouch! Is that the revised Intel microcode ?
<TJ-> Slashman: the earlier update in January was withdrawn, so if this is the new release, that isn't good
<Slashman> TJ-: I'm not sure, the last update of the BIOS is 26 Feb 2018, so I'll say yes
<TJ-> Slashman: have you notified Dell?
<Slashman> I've called dell because I have an issue on an other server where I have a memory issue and they told me to update the bios and it seems like they already know, but that's not very clear
<Slashman> those technician are outsourced in Morocco (I'm in France) so they are not the brightest
<TJ-> Slashman: it might be worth sending an email FAO one of the Dell kernel engineers, asking them to pass on the info/your contact details to whoever is responsible internally. E.g: Mario Limonciello <mario.limonciello@dell.com>
<Slashman> TJ-: you are right, I'll send an email to him
<apw> Slashman, hrm, lets hope it was the old microcode, and not the new
<apw> but if you do find out, it would be good to find out
<Slashman> we'll see... it's either that or some other undocumented changes in their BIOS I guess
<TJ-> From the various Dell updates it appears to be the late January / early February revision 
<JanC> sounds like there better be an easy way to prevent microcode loading when the new ones get included in the OS...
<TJ-> I dumped and extracted the update, it's own Version.txt says "January 08, 2018"
<TJ-> which to me sound like the /original/ microcode
<JanC> yeah, who says newer ones won't crash some "random" hardware/software combinations which Intel didn't test?
<JanC> but who*
<JanC> (if even some quite popular combinations aren't tested...)
<TJ-> These are Dell updates; I'd expect Dell would test them
<JanC> right, but maybe they did and it worked with some other OS/kernel version, etc.
<JanC> and when you include it in the OS, Canonical can't test more than a fraction of all hardware out there
<Slashman> TJ-: incredible, thank you for looking inside the BIOS archive itself
<Slashman> TJ-: how did you extract the "R730-020701C.hdr" file to find the readme?
<TJ-> Slashman: "mkdir Hack; cd Hack; wget https://downloads.dell.com/FOLDER04787858M/1/BIOS_NMF8F_LN_2.7.1.BIN; chmod +x BIOS_NMF8F_LN_2.7.1.BIN; fakeroot BIOS_NMF8F_LN_2.7.1.BIN --extract ./ ;"
<Slashman> "/usr/bin/fakeroot: line 178: BIOS_NMF8F_LN_2.7.1.BIN: command not found"
<Slashman> last command seems incorrect
<Slashman> ok, I just did "./BIOS_NMF8F_LN_2.7.1.BIN --extract ./"
<TJ-> I used fakeroot to avoid needing to be root user 
<Slashman> TJ-: I extracted it inside a temporary lxc container
<TJ-> Slashman: :D
<TJ-> Slashman: I'm disassembling the UEFI image now, might be able to isolate the actual microcode update itself and use icode-tool on it
<prophecy04> what is fakeroot?
<Slashman> prophecy04: from what I understood, it's to make a program use the current dir as "/", avoiding in this case the binary to extract stuff at /opt/dell and instead extract at ./opt/dell
<TJ-> Slashman: no, that's chroot; fakeroot makes programs think they're running as uid 0
<Slashman> oh ok
<ycyclist> https://paste.ubuntu.com/p/t9TXwjNZNR/
<ycyclist> Sorry.  I left out that I had a successful bionic build recently, and now this fail from fresh clone.
<ycyclist> All up to date.  
<ycyclist> https://paste.ubuntu.com/p/FFf6qD9dnk/
<apw> ycyclist, yep, those tests are too stringent right now ... feel free to ignore them
<apw> we should have a better abi check for that in the next couple of days
#ubuntu-kernel 2018-03-17
<mispp> hey all, trying to find if 18.04 supports pxe boot over http, or in other words is there alternative to nfsboot in the for of http?
<mispp> brb
#ubuntu-kernel 2019-03-13
<ogra> hrm ... has anyon complained that SD crad support is broken in the last 4.15 kernel yet ? 
<ogra> it worked on the weekend ... stopped working today out of the blue (but there was a kernel update since) 
<ogra> [  356.652128] mmc0: error -110 whilst initialising SD card
<ogra> thats all i get now
<ogra> (same microSD in the same adapter worked on sunday)
 * ogra reboots to former kernel to check
#ubuntu-kernel 2019-03-14
<dsmythies> With the pending kernel 5.1-rc1, and already in the Ubuntu mainline daily, there will be a new Timer Events Oriented (TEO) idle governor.
<dsmythies> Currently, and in today's mainline daily, the related kernel configuration does not include this governor:
<dsmythies> # CONFIG_CPU_IDLE_GOV_TEO is not set
<dsmythies> Whereas it would be great, and allow users that do not compile the kernel for themselves to be able try try the new governor if it could be included. i.e.:
<dsmythies> CONFIG_CPU_IDLE_GOV_TEO=y
<dsmythies> What is the appropriate procedure to request this change to the Ubuntu mainline kernel configuration?
<TJ-> I suspect poking apw since I think he's generally in control of those builds
<apw> dsmythies: normally we get it fixed in disco, then rebuild it
<apw> as that is where the mainline kernel builds gets its config
<dsmythies> apw: How do I go about getting it "fixed in disco", which I don't know what that means?
<apw> sforshee, ^
<sforshee> apw, dsmythies: if that's a new option in 5.1 we can't enable it in disco. But we should rebase unstable to 5.1-rc1 next week and can enable it then
<dsmythies> sforshee: O.K. thanks. Then I'll watch for it for it in mainline 5.1-rc2, and maybe dailys before that.
#ubuntu-kernel 2019-03-15
<tjaalton> klebers: hi, you marked 1818049 as invalid for trusty, but the sru queue has an upload for it to fix the dkms build?
<klebers> tjaalton, hi. Initially I have submitted the patches to fix only the packages that seemed to be supported with the 4.4 kernels by the ADT matrix. virtualbox seems to be not installable alongside linux-lts-xenial on trusty. But probably LocutusOfBorg made an upload with that build fix along with a security fix
<tjaalton> klebers: ok, I've asked him why there are multiple uploads on the queue, I'll just wait his reply :)
<tjaalton> +for
#ubuntu-kernel 2020-03-11
<zx2c4> apw: in case you're tired of dkms stuff,
<zx2c4> i backported wireguard properly to 5.5 using upstream commits
<zx2c4>  https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip
<zx2c4> that applies ontop of 5.5.8
<zx2c4> i did this for Debian's upcoming kernel
<zx2c4> if you guys want to do the same instead of the dkms thing with wireguard-linux-compat, there are the patches
<zx2c4> cc kerneltoast 
<zx2c4> however, if you want to keep the same mechanism for focal as you do for older ubuntu releases, then the dkms approach might be more uniform and easier to deal with throughout
<zx2c4> i have no opinion either way, but thought i'd let you know about the option
<apw> zx2c4: thanks, we are most likely to stay as we are, at 5.6 it is moot
<zx2c4> apw: cool
<zx2c4> how's it coming with backporting it to 18.04 andwhatnot?
<rbasak> Is there a quick reference table of which kernel versions are in which release, including the HWE options?
<rbasak> Extracting this information out of packaging information seems painful.
<rbasak> Oh, just https://wiki.ubuntu.com/Kernel/LTSEnablementStack?
<rbasak> But that seems out of date.
<sarnold> rbasak: I've found this very handy https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html
<rbasak> sarnold: that's just what I needed. Thanks!
#ubuntu-kernel 2020-03-13
<sub526> Hi all, I'm having the Ubuntu 18.04 (4.15.0-88-generic) kernel. When I tried to build out-of-tree drivers, I'm getting "include/linux/string.h:343:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter" error.  Can someone let me know, does 18.04 kernel has the fix for this?
<sub526> https://lore.kernel.org/patchwork/patch/818208/
<bjf> ^ trudd (someone should look at this)
<trudd> got it bjf
<klebers> bjf, trudd: that fix never got accepted upstream and I saw no other fix that seems to be related to it
<klebers> that's likely an issue with the 'memcpy' caller
<klebers> the external module that calls it might have some issue
<trudd> ack, thanks klebers
<sub526> Hi all, I'm having the Ubuntu 18.04 (4.15.0-88-generic) kernel. When I tried to build out-of-tree drivers, I'm getting "include/linux/string.h:343:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter" error. Can someone let me know, does 18.04 kernel has the fix for this?
<sub526> https://lore.kernel.org/patchwork/patch/818208/
